From xen-devel-bounces@lists.xenproject.org Mon Dec 02 06:11:01 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 06:11:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846253.1261428 (Exim 4.92) (envelope-from ) id 1tHzdn-0006c9-JW; Mon, 02 Dec 2024 06:10:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846253.1261428; Mon, 02 Dec 2024 06:10:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tHzdn-0006bs-EX; Mon, 02 Dec 2024 06:10:39 +0000 Received: by outflank-mailman (input) for mailman id 846253; Mon, 02 Dec 2024 06:10:38 +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 1tHzdm-0006bl-4O for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 06:10:38 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on20607.outbound.protection.outlook.com [2a01:111:f403:2413::607]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 21198c8d-b074-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 07:10:29 +0100 (CET) Received: from SJ0PR05CA0040.namprd05.prod.outlook.com (2603:10b6:a03:33f::15) by PH7PR12MB7844.namprd12.prod.outlook.com (2603:10b6:510:27b::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.17; Mon, 2 Dec 2024 06:10:21 +0000 Received: from CO1PEPF000044F4.namprd05.prod.outlook.com (2603:10b6:a03:33f:cafe::a8) by SJ0PR05CA0040.outlook.office365.com (2603:10b6:a03:33f::15) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.9 via Frontend Transport; Mon, 2 Dec 2024 06:10:21 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CO1PEPF000044F4.mail.protection.outlook.com (10.167.241.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Mon, 2 Dec 2024 06:10:20 +0000 Received: from cjq-desktop.amd.com (10.180.168.240) 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; Mon, 2 Dec 2024 00:10:17 -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: 21198c8d-b074-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDE6MTExOmY0MDM6MjQxMzo6NjA3IiwiaGVsbyI6Ik5BTTEwLURNNi1vYmUub3V0Ym91bmQucHJvdGVjdGlvbi5vdXRsb29rLmNvbSJ9 X-Custom-Transaction: eyJpZCI6IjIxMTk4YzhkLWIwNzQtMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTE5ODI5LjI0MjU4NCwic2VuZGVyIjoiamlxaWFuLmNoZW5AYW1kLmNvbSIsInJlY2lwaWVudCI6Inhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZyJ9 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Li5u9gNCJBAK/9rVv0aKPTFOAEU+miZcmDLJAThxhS8ib3hLVh7GQyDd02uqMglNBkULq87VTKXTiNe4N5CIVHxk5BQTSIaxwbK/7NvqfOEmMh7o9u0QN9KVwpMK1cMKP3zGyWCFlUWmiVP0y7vQnyxCT3/RvPW33mh99bw8GcFgQDn+k1Vw57IU64DWQgC7Jyv5oKkMQ3jZFPMs78T/6eA322JvxdrjY6eel5eehsoOPE+4/UF/6mFV1GXMV05SqQQqBtO3cSDqz6GpnInNxKPvudaMkT//QrkovgeHNQYoRWFiWMglfgE5n4jnzvbjIkGaB6lRL5D3NoNZmvJf9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pr/xcnCn01iQipf3fHerV2YiaNHwJ6ELh6VWKXooNqM=; b=LTaR7l93bsQsNEZAtjs+zkKhFHHtul9pFYN0nRwbEduxwU249imfFPpqWdIN7cnsc1CHY9rrnNr0mCH15kVfw9ikz2l6zqXT9x1KQE0RkLpAhbTTMHEvwG/zqtk9SRtgqm9fA/naMhlPJSLiZ4BfprdU6sl5c96GY3mEoxi76VnyzvDmMmYdt8b/rn5sl6XQbO3+yakg3vOhqdL8QJGdFxJJ//sG4MU/c45KvHDzajr3Q4xOe/dmaqGrcGVOapKZVgnxdMWO9KLFJHEypLtbLHw6eX83cD4iYg4IliU8lbKnSM5aZgwgpf8p1WXNqWiA++LeJROPL+abVRzHefbkkg== 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=pr/xcnCn01iQipf3fHerV2YiaNHwJ6ELh6VWKXooNqM=; b=YoydUe4Yk9DF5s1obTC/J+KZXTEChK4kKpyWBqOS2BalJyNRvymvZiWQaotvdwKHXJMWbk9ledeuBUAqgNSBkIr9svYrqg509AUdOd9AtHTKClFU3maoezZDYrZ+KSigW4p8nDP/2wwB+AI8GGC6ByAHsqyRkr+kFCIiK8ZM2fI= 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=SATLEXMB04.amd.com; pr=C From: Jiqian Chen To: CC: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Huang Rui , Jiqian Chen Subject: [PATCH v2 1/1] vpci: Add resizable bar support Date: Mon, 2 Dec 2024 14:09:56 +0800 Message-ID: <20241202060956.1124162-1-Jiqian.Chen@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PEPF000044F4:EE_|PH7PR12MB7844:EE_ X-MS-Office365-Filtering-Correlation-Id: 1b93b764-fdb0-4a0e-0da8-08dd12980016 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|82310400026|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?kgxXR6+cewt5ibLeavB4neUpsXg38QYTdiXJPLC7XDjOr4+YQxPbaeL4x3dw?= =?us-ascii?Q?3faJpsMwSgjg8BBemApqXi/eRb6cO9+dnCMdOX+sckNuAvCBb4Kt282YXaoq?= =?us-ascii?Q?3f+fjBsOMOpWxb0kn6/mM07Ari8erNJzdFU5uR/SLtM49l17oCuLFCXZLVs7?= =?us-ascii?Q?wXnH/w0dVz4zcnViz+oLLFiGwcuugV813BxkrVu/jUv7Sho/pU7LqVtSkyc3?= =?us-ascii?Q?tlgZotrcKMPMuLD32sKz9L1VE0c4PvUbuNl4W05to0ZchSaKeMFQH3EvGItq?= =?us-ascii?Q?/ZIi9f5ZV0YKsk3MiO9eaLxJYr29KD6684B12qppGSDOvwPO1mjT1GHC95Pd?= =?us-ascii?Q?rk0r7Z40YNw67q6wvuTfw6EpTiAeZ0qXklS5Zt4vn/TFshBTMaFCSmtBZJB9?= =?us-ascii?Q?J0Cd5Q0f47vKzUhioTPHdhJLSSJIQINIoS5yIl6y9TI0FG8hHQLQ1H5kNjB+?= =?us-ascii?Q?4X6JSgsnLGiC/vVhqqqzHNLnckFuvio12/w5ZyfW3qSWWIj4+DnB2qCw5cHA?= =?us-ascii?Q?9ieKzRNDDOE2j7syP8J9YN1ZxxqYqs+gasSlxheCWXRXhg/qonT+CMabGZ77?= =?us-ascii?Q?zZ0px8r7T9Xx1IGcLHNHXP4967J6N7L3ClBhtrxi7YxLhp4uk0cPW3i9Z1Mk?= =?us-ascii?Q?u7I+jBYNDvqKdvCTbL1uHRK3HnoGMC6pqY+yDsDoivH7zRn+qtEGXqqg07eo?= =?us-ascii?Q?ttys6muQsHa/7/TloYkYWvDe41rjX6PT2gOweG7ImDqq/E+3TtGZ0LM6EMga?= =?us-ascii?Q?BDzsAaggJPiT2avG/B7vBqb7NsP1LygPaPG72zBhq/FzzjkNcnyNDA97p4OL?= =?us-ascii?Q?Cjr5JDtnNw/Y5leRgsqy1Y1TgSps78L2qVbNlE7kkFVJJUR08mgB4yzatFYs?= =?us-ascii?Q?+zAWn9H7YH7kaibiRfdydGkV1fIu0wSCTgU6DSKVGRnrCZhhNicARcz4/CCI?= =?us-ascii?Q?vVtn26xZ6qGSWI6426HujTKpuHP712vd4k6yQSjoxzmj8U7EYbRCEgnw+/DG?= =?us-ascii?Q?TWF7fEX8hTd7aVUqDj4AVNu5OGUa90cGr1+SDEvaETP80AX3uZahiQ+q6HJo?= =?us-ascii?Q?1ENOS8zw0BLv3q+g7iST0lYke9kz68/CrEPUMgQTeaPquTpXY1q1dtpDUYVC?= =?us-ascii?Q?q56OjC5Ilq7n06NPV2Qr5saS5kF35ve7uMS+ikkNvotwyMAB8e0OioeLjKp3?= =?us-ascii?Q?7h8F8vAyX/Yw7mkJ27K7UCyDe52GS3JgkNc2JHrQauHE2vQUrDY/+DTlxxGq?= =?us-ascii?Q?D63V9jrbf8idc380mnMU1HyY5M6liP6cM5yqGANhgTUI4VgRnY7gSX1j7Ols?= =?us-ascii?Q?390jDZfFD51qOSvM1eNjEK8GLrS1QVpBF0hiOKWAx8Eap+VWcnQ9wXKBjwRM?= =?us-ascii?Q?XB25SrdFxqECYy7IRdByjKWzpDePJ0njp4KJaHmAzTBf5se2gZY4teja1R31?= =?us-ascii?Q?Lyi8ei+dnp3f7x9JSemOE+h11wdFAu4n?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Dec 2024 06:10:20.0533 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1b93b764-fdb0-4a0e-0da8-08dd12980016 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CO1PEPF000044F4.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7844 Some devices, like discrete GPU of amd, support resizable bar capability, but vpci of Xen doesn't support this feature, so they fail to resize bars and then cause probing failure. According to PCIe spec, each bar that supports resizing has two registers, PCI_REBAR_CAP and PCI_REBAR_CTRL. So, add handlers for them to support resizing the size of BARs. Signed-off-by: Jiqian Chen --- Hi all, v2->v1 changes: *In rebar_ctrl_write, to check if memory decoding is enabled, and added some checks for the type of Bar. *Added vpci_hw_write32 to handle PCI_REBAR_CAP's write, since there is no write limitation of dom0. *And has many other minor modifications as well. Best regards, Jiqian Chen. --- xen/drivers/vpci/Makefile | 2 +- xen/drivers/vpci/rebar.c | 93 ++++++++++++++++++++++++++++++++++++++ xen/drivers/vpci/vpci.c | 6 +++ xen/include/xen/pci_regs.h | 11 +++++ xen/include/xen/vpci.h | 2 + 5 files changed, 113 insertions(+), 1 deletion(-) create mode 100644 xen/drivers/vpci/rebar.c diff --git a/xen/drivers/vpci/Makefile b/xen/drivers/vpci/Makefile index 1a1413b93e76..a7c8a30a8956 100644 --- a/xen/drivers/vpci/Makefile +++ b/xen/drivers/vpci/Makefile @@ -1,2 +1,2 @@ -obj-y += vpci.o header.o +obj-y += vpci.o header.o rebar.o obj-$(CONFIG_HAS_PCI_MSI) += msi.o msix.o diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c new file mode 100644 index 000000000000..156e8d337426 --- /dev/null +++ b/xen/drivers/vpci/rebar.c @@ -0,0 +1,93 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* + * Copyright (C) 2024 Advanced Micro Devices, Inc. All Rights Reserved. + * + * Author: Jiqian Chen + */ + +#include +#include + +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev, + unsigned int reg, + uint32_t val, + void *data) +{ + uint64_t size; + unsigned int index; + struct vpci_bar *bars = data; + + if ( pci_conf_read16(pdev->sbdf, PCI_COMMAND) & PCI_COMMAND_MEMORY ) + return; + + index = pci_conf_read32(pdev->sbdf, reg) & PCI_REBAR_CTRL_BAR_IDX; + if ( index >= PCI_HEADER_NORMAL_NR_BARS ) + return; + + if ( bars[index].type != VPCI_BAR_MEM64_LO && + bars[index].type != VPCI_BAR_MEM32 ) + return; + + size = PCI_REBAR_CTRL_SIZE(val); + if ( !((size >> 20) & + MASK_EXTR(pci_conf_read32(pdev->sbdf, reg - 4), PCI_REBAR_CAP_SIZES)) ) + gprintk(XENLOG_WARNING, + "%pp: new size %#lx for BAR%u isn't supported\n", + &pdev->sbdf, size, index); + + bars[index].size = size; + bars[index].addr = 0; + bars[index].guest_addr = 0; + pci_conf_write32(pdev->sbdf, reg, val); +} + +static int cf_check init_rebar(struct pci_dev *pdev) +{ + uint32_t ctrl; + unsigned int rebar_offset, nbars; + + rebar_offset = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_REBAR); + + if ( !rebar_offset ) + return 0; + + ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL); + nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK); + + for ( unsigned int i = 0; i < nbars; i++, rebar_offset += PCI_REBAR_CTRL ) + { + int rc; + + rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32, + rebar_offset + PCI_REBAR_CAP, 4, NULL); + if ( rc ) + { + printk("%pp: add register for PCI_REBAR_CAP failed (rc=%d)\n", + &pdev->sbdf, rc); + break; + } + + rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write, + rebar_offset + PCI_REBAR_CTRL, 4, + pdev->vpci->header.bars); + if ( rc ) + { + printk("%pp: add register for PCI_REBAR_CTRL failed %d\n", + &pdev->sbdf, rc); + break; + } + } + + return 0; +} +REGISTER_VPCI_INIT(init_rebar, VPCI_PRIORITY_LOW); + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c index 1e6aa5d799b9..3349b98389b8 100644 --- a/xen/drivers/vpci/vpci.c +++ b/xen/drivers/vpci/vpci.c @@ -232,6 +232,12 @@ void cf_check vpci_hw_write16( pci_conf_write16(pdev->sbdf, reg, val); } +void cf_check vpci_hw_write32( + const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data) +{ + pci_conf_write32(pdev->sbdf, reg, val); +} + int vpci_add_register_mask(struct vpci *vpci, vpci_read_t *read_handler, vpci_write_t *write_handler, unsigned int offset, unsigned int size, void *data, uint32_t ro_mask, diff --git a/xen/include/xen/pci_regs.h b/xen/include/xen/pci_regs.h index 250ba106dbd3..3fa6a9f8cad1 100644 --- a/xen/include/xen/pci_regs.h +++ b/xen/include/xen/pci_regs.h @@ -459,6 +459,7 @@ #define PCI_EXT_CAP_ID_ARI 14 #define PCI_EXT_CAP_ID_ATS 15 #define PCI_EXT_CAP_ID_SRIOV 16 +#define PCI_EXT_CAP_ID_REBAR 21 /* Resizable BAR */ /* Advanced Error Reporting */ #define PCI_ERR_UNCOR_STATUS 4 /* Uncorrectable Error Status */ @@ -541,6 +542,16 @@ #define PCI_VNDR_HEADER_REV(x) (((x) >> 16) & 0xf) #define PCI_VNDR_HEADER_LEN(x) (((x) >> 20) & 0xfff) +/* Resizable BARs */ +#define PCI_REBAR_CAP 4 /* capability register */ +#define PCI_REBAR_CAP_SIZES 0xFFFFFFF0 /* supported BAR sizes */ +#define PCI_REBAR_CTRL 8 /* control register */ +#define PCI_REBAR_CTRL_BAR_IDX 0x00000007 /* BAR index */ +#define PCI_REBAR_CTRL_NBAR_MASK 0x000000E0 /* # of resizable BARs */ +#define PCI_REBAR_CTRL_BAR_SIZE 0x00001F00 /* BAR size */ +#define PCI_REBAR_CTRL_SIZE(v) \ + (1UL << (MASK_EXTR(v, PCI_REBAR_CTRL_BAR_SIZE) + 20)) + /* * Hypertransport sub capability types * diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h index 41e7c3bc2791..72992e93cece 100644 --- a/xen/include/xen/vpci.h +++ b/xen/include/xen/vpci.h @@ -78,6 +78,8 @@ uint32_t cf_check vpci_hw_read32( const struct pci_dev *pdev, unsigned int reg, void *data); void cf_check vpci_hw_write16( const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data); +void cf_check vpci_hw_write32( + const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data); /* * Check for pending vPCI operations on this vcpu. Returns true if the vcpu -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 07:25:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 07:25:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846263.1261437 (Exim 4.92) (envelope-from ) id 1tI0nw-0006QP-LF; Mon, 02 Dec 2024 07:25:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846263.1261437; Mon, 02 Dec 2024 07:25:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tI0nw-0006QI-I6; Mon, 02 Dec 2024 07:25:12 +0000 Received: by outflank-mailman (input) for mailman id 846263; Mon, 02 Dec 2024 07:25: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 1tI0nu-0006Q8-Tg for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 07:25:11 +0000 Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [2a00:1450:4864:20::642]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8c758711-b07e-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 08:25:04 +0100 (CET) Received: by mail-ej1-x642.google.com with SMTP id a640c23a62f3a-aa560a65fd6so668629366b.0 for ; Sun, 01 Dec 2024 23:25:04 -0800 (PST) Received: from ?IPV6:2003:e5:872e:b100:d3c7:e0c0:5e3b:aa1c? (p200300e5872eb100d3c7e0c05e3baa1c.dip0.t-ipconnect.de. [2003:e5:872e:b100:d3c7:e0c0:5e3b:aa1c]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5997d5651sm478928666b.60.2024.12.01.23.25.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Dec 2024 23:25: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: 8c758711-b07e-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo2NDIiLCJoZWxvIjoibWFpbC1lajEteDY0Mi5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjhjNzU4NzExLWIwN2UtMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTI0MzA0LjI4OTQ2LCJzZW5kZXIiOiJqZ3Jvc3NAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733124304; x=1733729104; 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=UWoShG7di6vkn4Jos4Z2jQDm+QslUzISpyuQRzKKTfQ=; b=RH8gI9iQo56g0KHP8Dp6LNpiwS9ObltMQznUwrAQnbV49pmpUHYlqy0z8iRE2fWx3K cXzP+DBYFItpMHkio6ZdlOhLiKjvK3bi9PPYurFXDNEVhgV4poGyIAVJDU6aUrBEa5ps xyblG7w5KVhNrjiRROO/PxL4sAMQkF8AEznPrz0gqN/75VfESN7d8iQprjdYnqkt/aNK 5U4TE5wSuw6ixGy0aHr/SgPEPw3zZe1J2SF/39+H785skaV8x0nCQK75d6hMbNjz3ANp itXiljFsChBPLQUoHs4RcJ+uQz89wzMxkWnefeSok18wQs5DM/w5LvEc7E+HjhAPF0mT hpAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733124304; x=1733729104; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UWoShG7di6vkn4Jos4Z2jQDm+QslUzISpyuQRzKKTfQ=; b=I0DqUsbiPozpzonkO4fzrogDB1IfwYaTaFM+GlxN4wWhbnvOw/dUEX9V4wZdGFIIhP v9yG6KjYe3XHznwfkFeoCuKhS0cwkhuYOHfe9SFqNEpiW+y5yiaiEqmu2bQIYZngUb40 ccd8Iz3IotDFRxsLvUQJ/RmXiJ4nbicAWk+Bcpr36U2bMxDf2M/Tt6svt1V+DsOizKQc USuK5GOfSkcgCRkTEXHDSgxiaWO9+wgdXnmCeSGISJoxwL5+kz9/sD6LbtUM7VMlNGx4 SiDcLCav78nVKkF6A5QDJr+rPM80ObzotrgIZ2UAQGp4r5BMVAfjUor/n5riSzEFx6yG xWNw== X-Gm-Message-State: AOJu0YwcV6K/MbV1Ni4lgXzmNP3gvlXIbhEy0RC1GPzfYenife6Mu6MA 03h5vWEeWqHx1O/SRRHgRhK0B2wViXP81+bRKSqLFu2UyLE4E7FBM6OLTukZTZrW6z8AaUSsnpK pe7xkmw== X-Gm-Gg: ASbGnctJsRCMYYreee5IjNo8sTp6rtfRtUOzIa0uQWVsbLSPjXi/melwNfXqg9VH+kR zOw9hojY8rvqtf2jc+9fTKTFV3Fck1fHCwzdM0qY9SOd6WpBRW6/gEpQtwtxGb9/RRWRG07vlYd Am7geBPwo1DeCBm1mlEQHMwr6mmnSHUMQ0dIBYhoDAFmmDy5cmvZA7H1UpbJceECPQIzWt5pi8O 1236Fbl984H5+Se8dOJRw1EVa3nkCFiMrs/3DSGJvYw2FWj0k8ccyigOdxaHA6xh6jgkzYNi/qa JETE76XD7CYi87SSgCD0xFq+8jJ/QeFDkSss1KyPEoBoz+FjVq1372FW3wuB9svlxxIF3nmPYFI = X-Google-Smtp-Source: AGHT+IGGRIJJFu2oB4RxYndCUd1sEmix/B9K2dHgLUuXs4xX0HRCcfQ4fHiUjQFYmjB2mt+SJ5uLWw== X-Received: by 2002:a17:906:d54b:b0:aa5:3fe7:4475 with SMTP id a640c23a62f3a-aa59453454fmr2311817866b.11.1733124303615; Sun, 01 Dec 2024 23:25:03 -0800 (PST) Message-ID: <24b4d5a6-be4b-47fb-9190-fa8171b7a892@suse.com> Date: Mon, 2 Dec 2024 08:25:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/6] tools/libs: add a new libxenmanage library To: Anthony PERARD Cc: xen-devel@lists.xenproject.org References: <20241023131005.32144-1-jgross@suse.com> <20241023131005.32144-5-jgross@suse.com> <1846da14-f942-4414-8776-d76019fba37f@suse.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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------G4NJzX6KXWrFPXj98gh0rRYI" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------G4NJzX6KXWrFPXj98gh0rRYI Content-Type: multipart/mixed; boundary="------------kkU0bUC1tb6PYQa9jLHIz0PU"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Anthony PERARD Cc: xen-devel@lists.xenproject.org Message-ID: <24b4d5a6-be4b-47fb-9190-fa8171b7a892@suse.com> Subject: Re: [PATCH 4/6] tools/libs: add a new libxenmanage library References: <20241023131005.32144-1-jgross@suse.com> <20241023131005.32144-5-jgross@suse.com> <1846da14-f942-4414-8776-d76019fba37f@suse.com> In-Reply-To: --------------kkU0bUC1tb6PYQa9jLHIz0PU Content-Type: multipart/mixed; boundary="------------6vHj0p8lLX6AI0WaOghXwSRU" --------------6vHj0p8lLX6AI0WaOghXwSRU Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjYuMTEuMjQgMTc6NDQsIEFudGhvbnkgUEVSQVJEIHdyb3RlOg0KPiBPbiBGcmksIE5v diAyMiwgMjAyNCBhdCAwNDoxMjoyNVBNICswMTAwLCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0K Pj4gT24gMjIuMTEuMjQgMTQ6NTUsIEFudGhvbnkgUEVSQVJEIHdyb3RlOg0KPj4+IE9uIFdl ZCwgT2N0IDIzLCAyMDI0IGF0IDAzOjEwOjAzUE0gKzAyMDAsIEp1ZXJnZW4gR3Jvc3Mgd3Jv dGU6DQo+Pj4+IGRpZmYgLS1naXQgYS90b29scy9pbmNsdWRlL3hlbm1hbmFnZS5oIGIvdG9v bHMvaW5jbHVkZS94ZW5tYW5hZ2UuaA0KPj4+PiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0KPj4+ PiBpbmRleCAwMDAwMDAwMDAwLi4yZTZjM2RlZGFhDQo+Pj4+IC0tLSAvZGV2L251bGwNCj4+ Pj4gKysrIGIvdG9vbHMvaW5jbHVkZS94ZW5tYW5hZ2UuaA0KPj4+PiBAQCAtMCwwICsxLDk4 IEBADQo+Pj4+ICsvKg0KPj4+PiArICogQ29weXJpZ2h0IChjKSAyMDI0IFNVU0UgU29mdHdh cmUgU29sdXRpb25zIEdlcm1hbnkgR21iSA0KPj4+PiArICoNCj4+Pj4gKyAqIFRoaXMgbGli cmFyeSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IN Cj4+Pj4gKyAqIG1vZGlmeSBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBMZXNzZXIg R2VuZXJhbCBQdWJsaWMNCj4+Pj4gKyAqIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5IHRoZSBG cmVlIFNvZnR3YXJlIEZvdW5kYXRpb247DQo+Pj4+ICsgKiB2ZXJzaW9uIDIuMSBvZiB0aGUg TGljZW5zZS4NCj4+Pj4gKyAqDQo+Pj4+ICsgKiBUaGlzIGxpYnJhcnkgaXMgZGlzdHJpYnV0 ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwNCj4+Pj4gKyAqIGJ1dCBX SVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5 IG9mDQo+Pj4+ICsgKiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNV TEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQ0KPj4+PiArICogTGVzc2VyIEdlbmVyYWwgUHVi bGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4NCj4+Pj4gKyAqDQo+Pj4+ICsgKiBZb3Ug c2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgTGVzc2VyIEdlbmVyYWwg UHVibGljDQo+Pj4+ICsgKiBMaWNlbnNlIGFsb25nIHdpdGggdGhpcyBsaWJyYXJ5OyBJZiBu b3QsIHNlZSA8aHR0cDovL3d3dy5nbnUub3JnL2xpY2Vuc2VzLz4uDQo+Pj4NCj4+PiBTaGFs bCB3ZSB1c2UgU1BEWCB0YWdzIGluc3RlYWQgb2YgdGhpcyBib2lsZXJwbGF0ZT8NCj4+DQo+ PiBNeSB0aGlua2luZyB3YXMgdG8gYXZvaWQgdGhhdCBmb3IgIm9mZmljaWFsIiBoZWFkZXIg ZmlsZXMsIGFzIHRob3NlIG1pZ2h0DQo+PiBiZSBjb3BpZWQgdmVyYmF0aW0gdG8gb3RoZXIg cHJvamVjdHMsIHdoaWNoIG1pZ2h0IG5vdCB1c2UgU1BEWC4gU28gaGF2aW5nDQo+PiB0aGUg bGljZW5zZSB0ZXh0IHZlcmJhdGltIGF2b2lkcyBhbnkgcHJvYmxlbXMgaW4gdGhpcyByZWdh cmQuDQo+IA0KPiBXZWxsLCB0aGlzIGhlYWRlciBpbiBwYXJ0aWN1bGFyIHdvdWxkIGJlIGZh aXJseSB1c2VsZXNzLCBJIGJlbGlldmUsIGlmIGl0DQo+IHdhcyBjb3BpZWQgaW50byBhbiBv dGhlciBwcm9qZWN0LCBpdCBkZXNjcmliZWQgYSBsaWJyYXJ5IHNvIG5lZWQgdG8gYmUNCj4g ZGlzdHJpYnV0ZWQgYWxvbmcgc2lkZSB0aGUgbGlicmFyeS4gU2Vjb25kLCB0aGlzIGlzbid0 IHRoZSB0ZXh0IG9mIHRoZQ0KPiBsaWNlbnNlIGJ1dCBzb21ldGhpbmcgZGVzY3JpYmluZyB3 aGljaCBsaWNlbnNlIGlzIHVzZWQgYW5kIHdoZXJlIHRvDQo+IGZpbmQgdGhlIHRleHQgZm9y IGl0LiBBbiBTUERYIHRhZyBkb2VzIG5lYXJseSB0aGUgc2FtZSB0aGluZywgYnV0IGNhbg0K PiBhY3R1YWxseSBiZSBwYXJzZSBieSBhIGNvbXB1dGVyLg0KPiANCj4gT2ZmaWNpYWwgaGVh ZGVycyB0aGF0IHdvdWxkIGJlIHVzZWZ1bCB0byBiZSBjb3BpZWQgaW50byBvdGhlciBwcm9q ZWN0DQo+IGFscmVhZHkgZXhwb3NlIHRoZSBTUERYIHRhZ3MsIG1hbnkvYWxsIHRoZSBoZWFk ZXJzIGluDQo+IHhlbi9pbmNsdWRlL3B1YmxpYywgYXMgd2VsbCBhcyBoZWFkZXJzIGNyZWF0 ZWQgYnkgYG1raGVhZGVyLnB5YCBpbiB0aGlzDQo+IGRpcmVjdG9yeSAodG9vbHMvaW5jbHVk ZSkuDQo+IA0KPiBJJ3ZlIHRha2VuIGEgbG9vayBpbnRvIG15IGRpcmVjdG9yeSAiL3Vzci9p bmNsdWRlIiwgYW5kIHRoZXkgYXJlIHBsZW50eQ0KPiBvZiBoZWFkZXJzIGhhdmluZyB0aGUg U1BEWCB0YWcuDQo+IA0KPiBTbyBvdmVyYWxsLCBJIHRoaW5rIHdlIGFyZSBmaW5lIHRvIHVz ZSBTUERYIHRhZ3MgaGVyZSBhcyB3ZWxsLiA7LSkNCg0KT2theSwgSSdsbCBzd2l0Y2ggdG8g U1BEWC4NCg0KDQpKdWVyZ2VuDQo= --------------6vHj0p8lLX6AI0WaOghXwSRU 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----- --------------6vHj0p8lLX6AI0WaOghXwSRU-- --------------kkU0bUC1tb6PYQa9jLHIz0PU-- --------------G4NJzX6KXWrFPXj98gh0rRYI 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/Ey8FAmdNYM4FAwAAAAAACgkQsN6d1ii/Ey8J rgf+NJFjrsOVZ5W8Gj9caCUiRO7uTEOtNEMu4V4aQiESLlnDq9ZSCDmsEDCN+tSE5QxvtbL6wwKH TIlWEhoJ4Vw9VpKOtnJ49cgyhv/rARqkd9sEkacI3QjNljocscJI2hmsed635ORiO8fBWC9wiXcu YrojCClxlHgpxC2kp5y71y/b/NSCj+B8k0rhfplAOWYdIwEiSyIFt5aWnCgtWwfat/T7POsAganQ WiIczkk8LK0nOCksNqTCBfhS95Abeado5BrKTXsvk7B77mx4oV3Nrjq0SV09FfGLtAmQ0DAF18Po OGHouC+aPvQCdA+8KC8DWguN5m6U3Lz5P4b+7ID40w== =ir8N -----END PGP SIGNATURE----- --------------G4NJzX6KXWrFPXj98gh0rRYI-- From xen-devel-bounces@lists.xenproject.org Mon Dec 02 07:32:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 07:32:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846277.1261448 (Exim 4.92) (envelope-from ) id 1tI0uZ-00084Q-Fa; Mon, 02 Dec 2024 07:32:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846277.1261448; Mon, 02 Dec 2024 07:32: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 1tI0uZ-00084J-Ce; Mon, 02 Dec 2024 07:32:03 +0000 Received: by outflank-mailman (input) for mailman id 846277; Mon, 02 Dec 2024 07:32: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) id 1tI0uY-00084D-LP for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 07:32:02 +0000 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 820d8b95-b07f-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 08:31:58 +0100 (CET) Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Dec 2024 23:31:55 -0800 Received: from black.fi.intel.com ([10.237.72.28]) by orviesa007.jf.intel.com with ESMTP; 01 Dec 2024 23:31:49 -0800 Received: by black.fi.intel.com (Postfix, from userid 1000) id B58773B2; Mon, 02 Dec 2024 09:31:47 +0200 (EET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 820d8b95-b07f-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjE5OC4xNzUuNjUuMTUiLCJoZWxvIjoibWdhbWFpbC5pbnRlbC5jb20ifQ== X-Custom-Transaction: eyJpZCI6IjgyMGQ4Yjk1LWIwN2YtMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTI0NzE4LjM3Mjg2NSwic2VuZGVyIjoiIiwicmVjaXBpZW50IjoieGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnIn0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1733124718; x=1764660718; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=M15az0QjHwqSnaRdQ3vhhyKn2F1zyuHqY37H2ln+rKo=; b=L/nFC4rEUW6tJk1jHMPrscqJdngXKXCChJF9fHyEv5ARsr4WVDaM7DRE O2r6KXb8os7C/0OFHGf01/HMUOrHr09vl24aMjuR/5OXjdwT7KD/NEdnO a60GXroQmIvzlKoHC222F2vcjXyeyQDGbotNbHZRbi7GKHbraQzjWE8Iy edIQxQpRetgdhsBG0D0IucVQhI48WL0dCzLwPJkkEY81ZpVEBENgfevmZ uGuhUtqFR1h16DwqQJE9Sax2rNWcEE3Bc4zrpu8S5YGMKkD9atZKgFjZe EkXtvJoZSjbCkw4JDMvytBzrTVXw6K94w/LGRm4Yx65eE3n5EyTNIy/ks w==; X-CSE-ConnectionGUID: yTYMf//0RhytFFbgfzDa3Q== X-CSE-MsgGUID: jj0/r0M4RxaBoTTXTWnX0g== X-IronPort-AV: E=McAfee;i="6700,10204,11273"; a="36943338" X-IronPort-AV: E=Sophos;i="6.12,201,1728975600"; d="scan'208";a="36943338" X-CSE-ConnectionGUID: 5gTE3+swTUCPaC+Chly83w== X-CSE-MsgGUID: 9RWjv968Rkar/vBJ99Abxw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,201,1728975600"; d="scan'208";a="93408303" From: "Kirill A. Shutemov" To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org Cc: "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , "H. Peter Anvin" , Paolo Bonzini , Vitaly Kuznetsov , Juergen Gross , Boris Ostrovsky , "Kirill A. Shutemov" , Gaosheng Cui , Michael Roth , Tom Lendacky , Ashish Kalra , Kai Huang , Andi Kleen , Sean Christopherson , Xiaoyao Li , linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org, Dave Hansen Subject: [PATCH, RESEND] x86/mtrr: Rename mtrr_overwrite_state() to guest_force_mtrr_state() Date: Mon, 2 Dec 2024 09:31:39 +0200 Message-ID: <20241202073139.448208-1-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.45.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Rename the helper to better reflect its function. Signed-off-by: Kirill A. Shutemov Suggested-by: Dave Hansen Acked-by: Dave Hansen --- arch/x86/hyperv/ivm.c | 2 +- arch/x86/include/asm/mtrr.h | 10 +++++----- arch/x86/kernel/cpu/mtrr/generic.c | 6 +++--- arch/x86/kernel/cpu/mtrr/mtrr.c | 2 +- arch/x86/kernel/kvm.c | 2 +- arch/x86/xen/enlighten_pv.c | 4 ++-- 6 files changed, 13 insertions(+), 13 deletions(-) diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c index 60fc3ed72830..90aabe1fd3b6 100644 --- a/arch/x86/hyperv/ivm.c +++ b/arch/x86/hyperv/ivm.c @@ -664,7 +664,7 @@ void __init hv_vtom_init(void) x86_platform.guest.enc_status_change_finish = hv_vtom_set_host_visibility; /* Set WB as the default cache mode. */ - mtrr_overwrite_state(NULL, 0, MTRR_TYPE_WRBACK); + guest_force_mtrr_state(NULL, 0, MTRR_TYPE_WRBACK); } #endif /* defined(CONFIG_AMD_MEM_ENCRYPT) || defined(CONFIG_INTEL_TDX_GUEST) */ diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h index 4218248083d9..c69e269937c5 100644 --- a/arch/x86/include/asm/mtrr.h +++ b/arch/x86/include/asm/mtrr.h @@ -58,8 +58,8 @@ struct mtrr_state_type { */ # ifdef CONFIG_MTRR void mtrr_bp_init(void); -void mtrr_overwrite_state(struct mtrr_var_range *var, unsigned int num_var, - mtrr_type def_type); +void guest_force_mtrr_state(struct mtrr_var_range *var, unsigned int num_var, + mtrr_type def_type); extern u8 mtrr_type_lookup(u64 addr, u64 end, u8 *uniform); extern void mtrr_save_fixed_ranges(void *); extern void mtrr_save_state(void); @@ -75,9 +75,9 @@ void mtrr_disable(void); void mtrr_enable(void); void mtrr_generic_set_state(void); # else -static inline void mtrr_overwrite_state(struct mtrr_var_range *var, - unsigned int num_var, - mtrr_type def_type) +static inline void guest_force_mtrr_state(struct mtrr_var_range *var, + unsigned int num_var, + mtrr_type def_type) { } diff --git a/arch/x86/kernel/cpu/mtrr/generic.c b/arch/x86/kernel/cpu/mtrr/generic.c index 7b29ebda024f..2fdfda2b60e4 100644 --- a/arch/x86/kernel/cpu/mtrr/generic.c +++ b/arch/x86/kernel/cpu/mtrr/generic.c @@ -423,7 +423,7 @@ void __init mtrr_copy_map(void) } /** - * mtrr_overwrite_state - set static MTRR state + * guest_force_mtrr_state - set static MTRR state for a guest * * Used to set MTRR state via different means (e.g. with data obtained from * a hypervisor). @@ -436,8 +436,8 @@ void __init mtrr_copy_map(void) * @num_var: length of the @var array * @def_type: default caching type */ -void mtrr_overwrite_state(struct mtrr_var_range *var, unsigned int num_var, - mtrr_type def_type) +void guest_force_mtrr_state(struct mtrr_var_range *var, unsigned int num_var, + mtrr_type def_type) { unsigned int i; diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.c b/arch/x86/kernel/cpu/mtrr/mtrr.c index 989d368be04f..ecbda0341a8a 100644 --- a/arch/x86/kernel/cpu/mtrr/mtrr.c +++ b/arch/x86/kernel/cpu/mtrr/mtrr.c @@ -625,7 +625,7 @@ void mtrr_save_state(void) static int __init mtrr_init_finalize(void) { /* - * Map might exist if mtrr_overwrite_state() has been called or if + * Map might exist if guest_force_mtrr_state() has been called or if * mtrr_enabled() returns true. */ mtrr_copy_map(); diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c index 21e9e4845354..7a422a6c5983 100644 --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -983,7 +983,7 @@ static void __init kvm_init_platform(void) x86_platform.apic_post_init = kvm_apic_init; /* Set WB as the default cache mode for SEV-SNP and TDX */ - mtrr_overwrite_state(NULL, 0, MTRR_TYPE_WRBACK); + guest_force_mtrr_state(NULL, 0, MTRR_TYPE_WRBACK); } #if defined(CONFIG_AMD_MEM_ENCRYPT) diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index d6818c6cafda..633469fab536 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -171,7 +171,7 @@ static void __init xen_set_mtrr_data(void) /* Only overwrite MTRR state if any MTRR could be got from Xen. */ if (reg) - mtrr_overwrite_state(var, reg, MTRR_TYPE_UNCACHABLE); + guest_force_mtrr_state(var, reg, MTRR_TYPE_UNCACHABLE); #endif } @@ -195,7 +195,7 @@ static void __init xen_pv_init_platform(void) if (xen_initial_domain()) xen_set_mtrr_data(); else - mtrr_overwrite_state(NULL, 0, MTRR_TYPE_WRBACK); + guest_force_mtrr_state(NULL, 0, MTRR_TYPE_WRBACK); /* Adjust nr_cpu_ids before "enumeration" happens */ xen_smp_count_cpus(); -- 2.45.2 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 07:34:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 07:34:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846284.1261458 (Exim 4.92) (envelope-from ) id 1tI0wU-0000BI-RN; Mon, 02 Dec 2024 07:34:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846284.1261458; Mon, 02 Dec 2024 07:34: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 1tI0wU-0000BB-Nh; Mon, 02 Dec 2024 07:34:02 +0000 Received: by outflank-mailman (input) for mailman id 846284; Mon, 02 Dec 2024 07:34: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 1tI0wT-0000B5-N9 for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 07:34:01 +0000 Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [2a00:1450:4864:20::143]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cade6ae7-b07f-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 08:33:58 +0100 (CET) Received: by mail-lf1-x143.google.com with SMTP id 2adb3069b0e04-53de8ecb39bso4382113e87.2 for ; Sun, 01 Dec 2024 23:33:58 -0800 (PST) Received: from ?IPV6:2003:e5:872e:b100:d3c7:e0c0:5e3b:aa1c? (p200300e5872eb100d3c7e0c05e3baa1c.dip0.t-ipconnect.de. [2003:e5:872e:b100:d3c7:e0c0:5e3b:aa1c]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-385ea9c5952sm4613112f8f.67.2024.12.01.23.33.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Dec 2024 23:33: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: cade6ae7-b07f-11ef-a0d2-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjoxNDMiLCJoZWxvIjoibWFpbC1sZjEteDE0My5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6ImNhZGU2YWU3LWIwN2YtMTFlZi1hMGQyLThiZTBkYWMzMDJiMCIsInRzIjoxNzMzMTI0ODM4LjQ1NDAyMSwic2VuZGVyIjoiamdyb3NzQHN1c2UuY29tIiwicmVjaXBpZW50IjoieGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnIn0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733124838; x=1733729638; 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=JEdQzfmHvFud2pyDc69tUs6vmsVBEXrSpmtr+dhUAh0=; b=CCmBUGSJCLiVEaz9uy0D7aOeIOqNDqbmB4j+ONzEqhAN2ZzmZogtzGpsyvZQUwQtpU XHMPbBPcY1g4Y5KesjVKP87bbT8mf41wYz+U3x9HletsTn3ljs4yURzI8PPtMvC8rj5f EOHW+ObbIeeSQvc+5lrGraq1dXi8fZmbl/8olBQKIyCTZfk7ebJcbcd5x7A4oxNGHjQC IQjQPjZUnun/aMxbngndaycjqSUg9Sf9Fo65vS4sCGVAGfOgqS66xm/d9Q1BJFrvYA9n jLYl1LGLbbKANGY/Dd69W7AOsQHmi7yRkonij0YdfTb6hZl3sHhkTbXNARirbBo6qYGV LLLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733124838; x=1733729638; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=JEdQzfmHvFud2pyDc69tUs6vmsVBEXrSpmtr+dhUAh0=; b=L0LRKmUxPRSCG563ZJPvWbPc6xQdbBwkx4+t5Dk0oxcB472w7N0/bRprgW2DGBITir LRqLfDCAr+V9+sZC7lrZUVEfz5BAKngbvEG6eFDJoXLPLBRSjkb7RD4sY5vzTH58dO9+ rpEXDNE1BaHv5pEm4MgJSEal26STuRs8gQdRnB3s3zKVrVXIBB6mSqMfldD/LQYz91nc 1SAbcOoOSf2pW2EN+GgNe9LoHYnOhSEPKWWVv8NlGlpI/gBVnrssO4b3fg2bd694G5F3 gBYkVRENTd7v1O9IqLvcdBEJGjzloCXgOkHoj6WAOiQj0Bwk66OcIuRZu6EFjEbr5f1u 50ZA== X-Gm-Message-State: AOJu0YwSJy4j+ca8Im6lcZqF+PZihiIBIl9scnXrqlSA/HswI6KflzfF IvTJnAJJjLPj7fdSqxPi1Ejc4Boq/Spde/WPyauQW/zZat3O5TZWCJD5uL9eUPvFgQea3/LsiR9 KC40NpA== X-Gm-Gg: ASbGnct8rEGa4EDZ692t1IzHzIsd6ixdwPuOcBm0L6j+jYPvYMNOC40m30GehRx0pZj Ql+2+ILb6GrkNF2OAD84zEUcb8nnaEJYqdBH09O1QnBMpKfsqrVrW+0bCAvUPD02TqMyfGH7f3r Uk2Hepac7W2HqVsgXQa9z2COYsHTj1yWZMuc+mlCyVqE5phgz8HASl4H1sR63BAVjb3EPNsFokb EaBy1pGyWVTf/huKU40utbxHRHEnsweK9w9dtm/lQmtbFuq9+VvG0XYnn4IFBYHvMlZNtJVH98A nbeRxTZtAAdnJCc3T7qC812ZYqjngqjnglNzEAj3KWGMFdCp7NA3vbShbYm4CgZGlo7c/r7Gev4 = X-Google-Smtp-Source: AGHT+IGjdQ2Dvw5Bf3yb024ca0Zj+Xhx3qyGkeWka9xgiYBPQC/kf4Qa3SCSUxz7PiVf7dYEQlnqUg== X-Received: by 2002:a05:6512:3ba2:b0:53d:eec4:2bfa with SMTP id 2adb3069b0e04-53df0104777mr10774537e87.37.1733124837643; Sun, 01 Dec 2024 23:33:57 -0800 (PST) Message-ID: <4aff0928-87a1-4010-8ec9-efef5845294f@suse.com> Date: Mon, 2 Dec 2024 08:33:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 5/6] tools: add a dedicated header file for barrier definitions To: Anthony PERARD Cc: xen-devel@lists.xenproject.org References: <20241023131005.32144-1-jgross@suse.com> <20241023131005.32144-6-jgross@suse.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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------MaXpSxldNgaGWHt8hq0M0r0c" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------MaXpSxldNgaGWHt8hq0M0r0c Content-Type: multipart/mixed; boundary="------------TIsd6CCfmgEDaj4gI8KaK636"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Anthony PERARD Cc: xen-devel@lists.xenproject.org Message-ID: <4aff0928-87a1-4010-8ec9-efef5845294f@suse.com> Subject: Re: [PATCH 5/6] tools: add a dedicated header file for barrier definitions References: <20241023131005.32144-1-jgross@suse.com> <20241023131005.32144-6-jgross@suse.com> In-Reply-To: --------------TIsd6CCfmgEDaj4gI8KaK636 Content-Type: multipart/mixed; boundary="------------LXDEvQWQ67wW0lsueoREevNY" --------------LXDEvQWQ67wW0lsueoREevNY Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjYuMTEuMjQgMTg6MjgsIEFudGhvbnkgUEVSQVJEIHdyb3RlOg0KPiBPbiBXZWQsIE9j dCAyMywgMjAyNCBhdCAwMzoxMDowNFBNICswMjAwLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0K Pj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2luY2x1ZGUveGVuLWJhcnJpZXIuaCBiL3Rvb2xzL2lu Y2x1ZGUveGVuLWJhcnJpZXIuaA0KPj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQNCj4+IGluZGV4 IDAwMDAwMDAwMDAuLjYyMDM2ZjUyOGINCj4+IC0tLSAvZGV2L251bGwNCj4+ICsrKyBiL3Rv b2xzL2luY2x1ZGUveGVuLWJhcnJpZXIuaA0KPj4gQEAgLTAsMCArMSw1MSBAQA0KPj4gKy8q KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioNCj4+ICsgKiB4ZW4tYmFycmllci5oDQo+PiArICoN Cj4+ICsgKiBEZWZpbml0aW9uIG9mIENQVSBiYXJyaWVycywgcGFydCBvZiBsaWJ4ZW5jdHJs Lg0KPiANCj4gRG9lcyBpdCBuZWVkcyB0byBiZSBwYXJ0IG9mICJsaWJ4ZW5jdHJsIiA/IDot KSBTaW5jZSB0aGUgZ29hbCBpcyB0byBiZQ0KPiBhYmxlIHRvIHVzZSB0aGUgaGVhZGVyIHdp dGhvdXQgeGVuY3RybC4NCg0KWWVhaCwgYnV0IGl0IHdhcyBwYXJ0IG9mIGxpYnhlbmN0cmwg dW50aWwgbm93Lg0KDQpTbyBpdCBuZWVkcyB0byBiZSBkaXN0cmlidXRlZCB0b2dldGhlciB3 aXRoIHhlbmN0cmwuaCwgb3RoZXJ3aXNlIHdlJ2QNCm5lZWQgYW5vdGhlciBkaXN0cmlidXRp b24gdW5pdCBsaWJ4ZW5jdHJsIGhhcyB0byBkZXBlbmQgb24uDQoNCj4+ICsgKg0KPj4gKyAq IENvcHlyaWdodCAoYykgMjAwMy0yMDA0LCBLIEEgRnJhc2VyLg0KPiANCj4gSSdtIG5vdCBz dXJlIHRoaXMgY29weXJpZ2h0IGxpbmUgaXMgZW5vdWdoLCBsb29raW5nIGF0IGBnaXQgYmxh bWVgLg0KPiANCj4gS2VpciBpbnRyb2R1Y2UgeGVuX2JhcnJpZXIgbWFjcm8gaW4gMjAxMiwg aW4NCj4gOGQzZjc1NzMyOGUxICgibGlieGM6IFVwZGF0ZSBybWIvd21iIGZvciB4ODYuIikN Cj4gU3RlZmFubyBpbnRyb2R1Y2VkIHRoZSBBcm0gbWFjcm8gaW4gMjAxMiwgaW4gZGFhMzE0 ZmUxOTM4ICgiYXJtOiBjb21waWxlDQo+IGxpYnhjIiksIGFuZCBJYW4gaW4gMjAxMyBpbiBh ZTRiNmYyOWE5ODMgKCJ0b29sczogbGlieGM6IGFybTY0DQo+IHN1cHBvcnQiKS4NCj4gVGhl cmUncyBiZWVuIGEgbW9kaWZpY2F0aW9uIGJ5IEFuZHJldyBpbiAyMDIwLCBzbyBDaXRyaXgg Y29weXJpZ2h0LA0KPiBpbiBkZTE2YThmYTBkYjcgKCJ4ODY6IFVzZSBMT0NLIEFERCBpbnN0 ZWFkIG9mIE1GRU5DRSBmb3Igc21wX21iKCkiKS4NCj4gDQo+IFNvIG92ZXJhbGwsIHdlIHBy b2JhYmx5IHdhbnQ6DQo+IENvcHlyaWdodCAoQykgMjAwMy0yMDEyLCBLIEEgRnJhc2VyLg0K PiBDb3B5cmlnaHQgKEMpIDIwMTItMjAyMCBDaXRyaXggU3lzdGVtcywgSW5jLg0KDQpIbW0s IEkganVzdCBjb3BpZWQgdGhlIENvcHlyaWdodCBmcm9tIHhlbmN0cmwuaCwgd2hlcmUgSSB0 b29rIHRoZSBjb250ZW50cw0Kb2YgdGhlIG5ldyBoZWFkZXIgZnJvbS4NCg0KSSBjYW4gc2Vl IGEgcmVhc29uIGZvciBhZGRpbmcgdGhlIENvcHlyaWdodCBmb3IgQ2l0cml4LCBidXQgSU1I TyB0aGlzDQpfc2hvdWxkXyBoYXZlIGhhcHBlbmVkIHdoZW4gdGhlIGNoYW5nZXMgd2VyZSBh cHBsaWVkIGluIDIwMjAuIEFuZCBJJ20gZmVlbGluZw0KYSBsaXR0bGUgYml0IHVuZWFzeSB0 byBhZGQgYSBDb3B5cmlnaHQgZm9yIGEgY29tcGFueSBJJ20gbm90IHdvcmtpbmcgZm9yLiBI b3cNCmRvIEkgcmVhbGx5IGtub3cgQ2l0cml4IGlzIHdhbnRpbmcgdGhhdCBDb3B5cmlnaHQg dG8gYmUgYWRkZWQ/DQoNCj4+ICsgKg0KPj4gKyAqIFRoaXMgbGlicmFyeSBpcyBmcmVlIHNv ZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3INCj4+ICsgKiBtb2RpZnkg aXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgTGVzc2VyIEdlbmVyYWwgUHVibGljDQo+ PiArICogTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRh dGlvbjsNCj4+ICsgKiB2ZXJzaW9uIDIuMSBvZiB0aGUgTGljZW5zZS4NCj4+ICsgKg0KPj4g KyAqIFRoaXMgbGlicmFyeSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdp bGwgYmUgdXNlZnVsLA0KPj4gKyAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91 dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mDQo+PiArICogTUVSQ0hBTlRBQklMSVRZ IG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBHTlUNCj4+ ICsgKiBMZXNzZXIgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLg0K Pj4gKyAqDQo+PiArICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUg R05VIExlc3NlciBHZW5lcmFsIFB1YmxpYw0KPj4gKyAqIExpY2Vuc2UgYWxvbmcgd2l0aCB0 aGlzIGxpYnJhcnk7IElmIG5vdCwgc2VlIDxodHRwOi8vd3d3LmdudS5vcmcvbGljZW5zZXMv Pi4NCj4+ICsgKi8NCj4+ICsNCj4+ICsjaWZuZGVmIFhFTkJBUlJJRVJfSA0KPj4gKyNkZWZp bmUgWEVOQkFSUklFUl9IDQo+IA0KPiBXaXRoIGFuIGV4dHJhICdfJyBmb3IgdGhlICctJyBp biB0aGUgaGVhZGVyIGZpbGVuYW1lPw0KPiAgICAgIFhFTl9CQVJSSUVSX0gNCg0KT2theS4N Cg0KPiBPdGhlcndpc2UsIHRoZSByZXN0IG9mIHRoZSBwYXRjaCBsb29rcyBmaW5lIHRvIG1l LCBldmVuIHdpdGhvdXQgdGhlIHJlc3QNCj4gb2YgdGhlIHNlcmllcy4NCg0KVGhhbmtzLA0K DQoNCkp1ZXJnZW4NCg== --------------LXDEvQWQ67wW0lsueoREevNY 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----- --------------LXDEvQWQ67wW0lsueoREevNY-- --------------TIsd6CCfmgEDaj4gI8KaK636-- --------------MaXpSxldNgaGWHt8hq0M0r0c 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/Ey8FAmdNYuQFAwAAAAAACgkQsN6d1ii/Ey+x Uwf/Q0LkQSNI1sYcNTd+uwQQWOWC0OSLrk/7irE+tvIRWbBlRkT4dn9fXWwyALwsxt1kVNVed5dk lU8EwtJs6uuRjy/U6LWA2eqPXbpCh7q6OyB/kjrSCWH9o0bitlVWw789j+Uvk8zhJOAmq9aMgSSr 8qJqUcfhIEjNpQEDsXG1nulAHRdROnJeyh8KnsP5mVrmF0RVdvw2ElGkbdTjcG5IYy+SGsmgoSHr 1o3lXL1XoVs9VjouTPXN3yD/Usth4pdjU4JuYzhfz98VnBvKg2+Ky5IbyzpKuea3ZE2ZXQoROyP9 ui+ynAEr++kUSccdgWrwj+9mkpVo5VfMGUi/Ze3ltg== =9xYK -----END PGP SIGNATURE----- --------------MaXpSxldNgaGWHt8hq0M0r0c-- From xen-devel-bounces@lists.xenproject.org Mon Dec 02 07:52:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 07:52:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846298.1261469 (Exim 4.92) (envelope-from ) id 1tI1E8-00035a-B4; Mon, 02 Dec 2024 07:52:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846298.1261469; Mon, 02 Dec 2024 07:52: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 1tI1E8-00035T-6Y; Mon, 02 Dec 2024 07:52:16 +0000 Received: by outflank-mailman (input) for mailman id 846298; Mon, 02 Dec 2024 07:52: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 1tI1E7-00035N-7s for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 07:52:15 +0000 Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [2a00:1450:4864:20::129]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 569d48db-b082-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 08:52:11 +0100 (CET) Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-53df6322ea7so6322913e87.0 for ; Sun, 01 Dec 2024 23:52: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 a640c23a62f3a-aa5996c11b4sm475657566b.7.2024.12.01.23.52.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Dec 2024 23:52: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: 569d48db-b082-11ef-a0d2-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjoxMjkiLCJoZWxvIjoibWFpbC1sZjEteDEyOS5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjU2OWQ0OGRiLWIwODItMTFlZi1hMGQyLThiZTBkYWMzMDJiMCIsInRzIjoxNzMzMTI1OTMxLjc4NTA5Mywic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733125931; x=1733730731; 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=eYJcoq7J1jS9DVNCfMAeodJSCSDwO0i5nsagRkXfgvc=; b=Fa/T024bbn9LbgRIyLoLO1Bu+UZ23w2MnsSNrh/NkXvVoDysvUr0ZtOaYh9lgtBmZp q7u2RQGgZqhbxhHSG/qYsLziSqw8XQg8LKWYZxLc8UNDPKbLgqM0UJ/nh/AJxr9tqmxo a53K9mgKtN68k8+8ii4jwxC1th304X2zrkIytm9SjoB1E9EknnUnJ0STvIOHqahoioH3 I+G2CvXKvL4eSmrNi1EEWBfcLXEQ/4oPImyP4S9CFktq6V1yvAUoOU6wv/e7pbnC9j9l tFBZuQeVDm1YWiax6padCZAOEjwYY+XAtlzCKr5j7SCBboBlbuCQkzvpZOjaA5FkRncE r0lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733125931; x=1733730731; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=eYJcoq7J1jS9DVNCfMAeodJSCSDwO0i5nsagRkXfgvc=; b=kEqPeaTtm9sjx1LBkrHr8j4uvp8pFe/MOYCGlfTemkzAW3elpyrd9DK+RaHKEyTs6s s+KM7+BZ9hm/5cnsNNo15dR1tt3V36nZwcAdS55JfQcaLB/7QE0AH5GaKjXwBIeNR90v fMHCPJCBzmIN0Y2Huh1kbjijyhvZJGeYqk6uU7yI75IdVW9XjiqNGyZg/6bJNWTNxnPr UCkDuMHb6VSrH3uutoDdk5bcr0pumgCtFa1mqzqztTtSyZpAksz6Bqyj19yJZQSiFu3U 1W+yUdz52n3SdZQESPQPecaUF0OzNl6zN257HUrrcpjvoUkF416GCYJIA7FGdIIZq3sh V7jw== X-Forwarded-Encrypted: i=1; AJvYcCUlGUroK7vi7Nj395jm/abXzyE5kV39l36SNPdQvKuW/68W1y04UsvTmbYcvr89QlpXu7fAuSR+JIE=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyz/XtmsKfhxvF2aq6B9PuhLpMzQNDjPDZoOYlh1UWAskqpUQ2h g0q0Wrqpb3AKrxxP9jxbhOrnMm5fbXLzdwap47L3CsqtTWMPOHqB5cQb/4J7Dr8lgGvKtY4iR8I = X-Gm-Gg: ASbGnctaQ/G2XvP13mq+2CqG2IUK5B+Mk6N/mz/2825OmOCcBW2zxgcdRLjLKv18HYD yhsz2UorNun2J1x8csNsa59dmR4YQP7hsgAMjvCBHmXnkcnaexwGO15OIJ3EDMgqgiOeuhR2BiC qkEUwBQhSJRwASTee3Tvt6Gs6LaYwYjhebt0q8GIoJ1tyoepOgbvzHnxH3PgGNYaOLIcqmqulp4 A+OUIwqV/eqeCgAOKOiJZckRQwIwcDOYvI+VM1AOT2qzLMj2H2XCijuDFTcZ2v99UUQ8+da3adl SP3Nr8YFIXnof03PLU8P6fpgK1LUWf2W/sA= X-Google-Smtp-Source: AGHT+IG7FaBiVcySqAkI69JjtQh1oVB9uBi5GCCVV6P/xJRkwEzSjj+fUGnadUdpp5uSQt9zV0HY1Q== X-Received: by 2002:a05:6512:3d24:b0:53d:e5c0:b9bf with SMTP id 2adb3069b0e04-53df011716dmr16421166e87.52.1733125931125; Sun, 01 Dec 2024 23:52:11 -0800 (PST) Message-ID: Date: Mon, 2 Dec 2024 08:52:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/5] build: arm64: provide -target and -march if using clang To: Julien Grall , Volodymyr Babchuk Cc: Andrew Cooper , Stefano Stabellini , "xen-devel@lists.xenproject.org" , Anthony PERARD References: <20241129014850.2852844-1-volodymyr_babchuk@epam.com> <20241129014850.2852844-4-volodymyr_babchuk@epam.com> <87iks5bsgd.fsf@epam.com> <8df584b8-fb23-4db4-af87-903fde91e42e@xen.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: <8df584b8-fb23-4db4-af87-903fde91e42e@xen.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.11.2024 18:15, Julien Grall wrote: > On 29/11/2024 22:12, Volodymyr Babchuk wrote: >> Jan Beulich writes: >>> On 29.11.2024 02:49, Volodymyr Babchuk wrote: >>>> --- a/config/arm64.mk >>>> +++ b/config/arm64.mk >>>> @@ -5,6 +5,10 @@ CONFIG_XEN_INSTALL_SUFFIX := >>>> >>>> CFLAGS += #-marm -march= -mcpu= etc >>>> >>>> +ifeq ($(clang),y) >>>> +CFLAGS += -target aarch64 -march=armv8-a >>>> +endif >>> >>> Why is this dependent on (just?) $(clang), not (also?) $(llvm)? >> >> Because this parameter is handled by clang only. There is no harm in >> providing it explicitly. When building on arm64, value of this parameter >> will match the default value for the platform. When building on x86, we >> need to tell clang that it should generate arm64 code anyways. There is >> no reason in trying to make ARM build with x86 instruction set. >> >>> Also >>> this affects both toolstack builds and hypervisor. Is applying -march >>> like this actually appropriate for the toolstack? >> >> This is a good question. I can't see why this can't be appropriate for >> toolstack. I.e. what bad can happen when building the toolstack. > > In the future, we may want to build the tools for Armv8-M. So I think > the -march should also applies for the toolstack. Perhaps I don't know enough of the Arm world, but: Wouldn't it be possible to build a tool stack suitable for a wide range for Arm64 flavors, while requiring more targeted hypervisor binaries? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 08:06:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 08:06:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846315.1261479 (Exim 4.92) (envelope-from ) id 1tI1S4-0005Tr-O2; Mon, 02 Dec 2024 08:06:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846315.1261479; Mon, 02 Dec 2024 08:06: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 1tI1S4-0005Th-JJ; Mon, 02 Dec 2024 08:06:40 +0000 Received: by outflank-mailman (input) for mailman id 846315; Mon, 02 Dec 2024 08:06: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 1tI1S3-0005Tb-HJ for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 08:06:39 +0000 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [2a00:1450:4864:20::12b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 59d8c449-b084-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 09:06:36 +0100 (CET) Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-53e0844ee50so830963e87.0 for ; Mon, 02 Dec 2024 00:06:36 -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-385d80a77a0sm10120305f8f.58.2024.12.02.00.06.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 00:06: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: 59d8c449-b084-11ef-a0d2-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjoxMmIiLCJoZWxvIjoibWFpbC1sZjEteDEyYi5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjU5ZDhjNDQ5LWIwODQtMTFlZi1hMGQyLThiZTBkYWMzMDJiMCIsInRzIjoxNzMzMTI2Nzk2LjI5MjU3Nywic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733126796; x=1733731596; 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=PNkBisc0H7d3OdIXOLo+yVp58Nm+CYdzw1NpzqAOANY=; b=gb/MhobbSWdiTC8uuSoueyIcfnriKhtP7Sk0h4UA7kBRfY7XoHxg7jhX+T/C0zd6b2 GoH/1kdaHr5KMsHpiTLrNSpL0iVUivqQs1+TPmaMjYFjyycQN7hXvpeVGflB9Qf+JBHm yX7a0W18sIjAZc7K//JvDk9jkogjYuk4Nton31F6gh1R2KZqzex11eOgmGOgz0CEZ6GW pgQer0Kem9pFnhC3eUsBHxidJy+9y1D+V502Nen7BHozZP4aiRyfc/xp6a08hGVq3cuQ 5lBRcawHW8LP47hXR5r4UGkLfNdhWPHGckcPJ2ybbmVhpVY3u+f7g4ZZudHEY7G3GgUi Y5Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733126796; x=1733731596; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PNkBisc0H7d3OdIXOLo+yVp58Nm+CYdzw1NpzqAOANY=; b=A99UC7OTOo5sXsMJrQC+EYQLmtkO7AmZj1HHNHvq1Jxwz3ZWftlPpBl3tgURlamoGY QJkRcb1XHjrok6ngX4dXL7k48ynjboW0fEZezv0tVfmQ4hKVxdOhsVANKIoigmoWxQty Pr7JY6JFmru0wb1sKjwQ3ksGsMQxX22tG6VUaDn96R5KaOXZiq6B0AVxg6mEry/MFQ5Q 8fUMKKQ+lqPXeeYxlR6g3gd/YjJ/WEyJiNfaRuULUju+Z+mjHOzd24UgdC+/4DTEaDfP hfXPvjbtoluscomd6EEue5aJvbiBZjPjngYapqrHMulPBR53HTo5wYqBlKwxu3bjGDHA QdSQ== X-Forwarded-Encrypted: i=1; AJvYcCV/6lBElbD/zYD5546tSJh46q0h1Ybd+Cuxy5xqXS1hpqkuaYGhXXdcJMIl5Nl2j7aVuJRe6pfcpNU=@lists.xenproject.org X-Gm-Message-State: AOJu0YwlT4OU3VmYimwERxXIRaPgZjX5rWR82Va7xxOUN/DY8gNtOf6h YeIcJdJeZRP25RSsUfH8G0+iN9pqvb0My9zR+9sO9U/de0bADjZyowXFfDkwYA== X-Gm-Gg: ASbGncv+Q0r7JOL6R38etjFU92/vskZm8GN4AxmdKWeSZDZYTNM4eGfuW2J2PKadLYO ktwqGYX3zDsvRdOiZ9iQpYcr21OtmUVWN2BTOL35Pk+UktCBTtWgAmP0WV8LMqpSFH3k21TI4xX j7LU1YrSlINkqpfM63BiKqddMgAsUnRnSsifk2xzcjKLZGdSJVw0eFd++TvhkbYBxBroIY/azen Lf9JnuHaRdTI0ABzTVI/SVzTu9rF2GXI5tgj+CugVWfRb/GspFsrqBxG8FZL5sKZCf8UiJetT8O sx1oIqgWi0cFHZ+1Q9EG8HASGkKAny8lQso= X-Google-Smtp-Source: AGHT+IEaJRhlMkMcSvBtTqqy9L/QuW0U3PEUk1gZ8RoEEdCgJmXI9NG1ljF5Owm9BtzT9fEyOgQfCw== X-Received: by 2002:ac2:5399:0:b0:53d:f1d1:13c5 with SMTP id 2adb3069b0e04-53df1d11418mr9649074e87.16.1733126795653; Mon, 02 Dec 2024 00:06:35 -0800 (PST) Message-ID: <56f5cf93-33fc-4314-8d38-93d9e0026429@suse.com> Date: Mon, 2 Dec 2024 09:06:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/4] common: remove -fno-stack-protector from EMBEDDED_EXTRA_CFLAGS To: Volodymyr Babchuk Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Samuel Thibault , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <20241130010954.36057-1-volodymyr_babchuk@epam.com> <20241130010954.36057-2-volodymyr_babchuk@epam.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: <20241130010954.36057-2-volodymyr_babchuk@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.11.2024 02:10, Volodymyr Babchuk wrote: > This patch is preparation for making stack protector > configurable. First step is to remove -fno-stack-protector flag from > EMBEDDED_EXTRA_CFLAGS so separate projects (Hypervisor in this case) > can enable/disable this feature by themselves. s/projects/components/ ? > --- a/stubdom/Makefile > +++ b/stubdom/Makefile > @@ -54,6 +54,8 @@ TARGET_CFLAGS += $(CFLAGS) > TARGET_CPPFLAGS += $(CPPFLAGS) > $(call cc-options-add,TARGET_CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) > > +$(call cc-option-add,TARGET_CFLAGS,CC,-fno-stack-protector) > + > # Do not use host headers and libs > GCC_INSTALL = $(shell LANG=C gcc -print-search-dirs | sed -n -e 's/install: \(.*\)/\1/p') > TARGET_CPPFLAGS += -U __linux__ -U __FreeBSD__ -U __sun__ > --- a/tools/firmware/Rules.mk > +++ b/tools/firmware/Rules.mk > @@ -15,6 +15,8 @@ $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) > > $(call cc-option-add,CFLAGS,CC,-fcf-protection=none) > > +$(call cc-option-add,CFLAGS,CC,-fno-stack-protector) > + > # Do not add the .note.gnu.property section to any of the firmware objects: it > # breaks the rombios binary and is not useful for firmware anyway. > $(call cc-option-add,CFLAGS,CC,-Wa$$(comma)-mx86-used-note=no) > --- a/tools/tests/x86_emulator/testcase.mk > +++ b/tools/tests/x86_emulator/testcase.mk > @@ -4,6 +4,8 @@ include $(XEN_ROOT)/tools/Rules.mk > > $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) > > +$(call cc-option-add,CFLAGS,CC,-fno-stack-protector) Is use of cc-option-add really necessary throughout here, when ... > --- a/xen/Makefile > +++ b/xen/Makefile > @@ -432,6 +432,8 @@ else > CFLAGS_UBSAN := > endif > > +CFLAGS += -fno-stack-protector ... is isn't needed here? Iirc the compiler version ranges supported don't vary between components. Then again afaics $(EMBEDDED_EXTRA_CFLAGS) is used by x86 only right now, and with cc-options-add, so perhaps it (a) needs using cc-options-add here, too, and (b) it wants explaining why this needs generalizing from x86 to all architectures. Quite possibly hypervisor use of $(EMBEDDED_EXTRA_CFLAGS) may want generalizing separately, up front? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 08:13:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 08:13:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846325.1261487 (Exim 4.92) (envelope-from ) id 1tI1YC-0007BB-BL; Mon, 02 Dec 2024 08:13:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846325.1261487; Mon, 02 Dec 2024 08:13: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 1tI1YC-0007B4-8V; Mon, 02 Dec 2024 08:13:00 +0000 Received: by outflank-mailman (input) for mailman id 846325; Mon, 02 Dec 2024 08:12:59 +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 1tI1YB-0007Ay-Po for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 08:12:59 +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 3c2ebfde-b085-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 09:12:56 +0100 (CET) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-aa539d2b4b2so709550966b.1 for ; Mon, 02 Dec 2024 00:12: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 a640c23a62f3a-aa5997d560asm483236366b.61.2024.12.02.00.12.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 00:12: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: 3c2ebfde-b085-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo2MzYiLCJoZWxvIjoibWFpbC1lajEteDYzNi5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjNjMmViZmRlLWIwODUtMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTI3MTc2LjA0NTg4LCJzZW5kZXIiOiJqYmV1bGljaEBzdXNlLmNvbSIsInJlY2lwaWVudCI6Inhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZyJ9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733127175; x=1733731975; 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=FLXkon0/5OI7F409SH4juRRBgE//vYxhx5brzVnUDEw=; b=bwQ0G95H0WMVpM21qkecCXnGE2o7C0DkNTOB9ZkRK2g7QnQvwP6yZsdN9bSWUJ9XsS t29BYN1rPe/Ke/VdW2BDA/3gNkiLMOnrbwPIRUVdFBBScxXcBSNd1fFxJdojORBtmDRU cgu1aljJm8+q1aXeCTKIsCzuom+Glmftc9mGBrBg0V13VKKwqAS2N5MZvtScXlX0olW4 d0KFcvvpcEx+PWsdNXCL3vaZFd6/WzgOVmz6ryWSm5sKVfjWBHSB6ai1IfB+0M/03GRg MsVC43OfwQXJf2AXecN0Ut5+oiwuubxV6WBsLoy9QoXDO7w5/xJzwYsCQx2NPt51ug2a 5/Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733127175; x=1733731975; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=FLXkon0/5OI7F409SH4juRRBgE//vYxhx5brzVnUDEw=; b=SfWGiwTQH/aA6sVUwh4ThqYnMl3K+f5RoaSDIMcCLgfzuIf0zQQy0XAQcH583kqmaa rr7A9wg2hiU7Xe+LkQ2Uaiagc+6fNb8sVkHDhjdxgTOr099cq7OKrHIERDyZL7O9Et3J tNiY+MO/j7XJIn6PupOfwyfTVh1n+kT/WoUkbbIrMe4yyzPmeLO8PSWAuyId9iEC9rwi 1rM9PP69Zgybih/vOLh6TsuXGdpRwSHltNQZjF3YoKd1VwQS3Wt7Vi0/Nm630PK1s7KH k/0JXqxgRKn0T95vSlmZF4qFw1PmNXWSl+fRVs1OKFTsNUxIrdYxxMcALmMaAHfur6UG gE0w== X-Forwarded-Encrypted: i=1; AJvYcCXYWmGKmhJ+V59FdMT+LcmXPJW0xChMsPnoFCc7c2eeHPzJLlQXN7pTLGNCuR6issvTGeJ+OOK931A=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyp4I/ELN57OCBaQQbDwRxdosyV97R7NuO9NuDMi921ffoZgXLx uHEZkCNzS0eDZ5fykZFViS3R0i8MN+NIreP42v1bzraF2BDhGDauPiYCrh7M0g== X-Gm-Gg: ASbGncs1AuH6jViJ2LR0pxsU5PxQhScYjb23O4TP2nk+5tFQ17jvVdg5q1l81dI36o2 WY+t3bP+VAzfT6Nga5yRx2TgZOKv1NtcwecdxML6VO/oHkDzXcYoaECefROiaeiP/peILdZ7GwS c2C1WB8ZZM3J9i1plLwhZhBssvV0CXUW7NgggSVmOUwtN80Lzg9frsP/o56vwzsB6jH82LFvLPR eCnnZBVV7qqakG2sGqiQavWdxF68+ppNIS+L8aO8JkiYdHnsELN6V6F9aBwrBtbhskZ5FFXdENh l67zwWh8/6+VkU+U72FC/BEA1ATs2PfNXBA= X-Google-Smtp-Source: AGHT+IHtWNnfCfnKovmgUSatXq2H2lh2lW5WUlzJSgkDuVpOsRrMk4y2n+5+xIkUHTlo1Ty0a2uETQ== X-Received: by 2002:a17:906:3d21:b0:aa5:427e:6c7a with SMTP id a640c23a62f3a-aa594670126mr1658386066b.25.1733127175403; Mon, 02 Dec 2024 00:12:55 -0800 (PST) Message-ID: <2f92aeb0-bb1f-49d0-9655-8ff93fee8837@suse.com> Date: Mon, 2 Dec 2024 09:12:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/4] xen: riscv: enable stack protector feature To: Volodymyr Babchuk Cc: Alistair Francis , Bob Eshleman , Connor Davis , Oleksii Kurochko , Andrew Cooper , Julien Grall , Stefano Stabellini , "xen-devel@lists.xenproject.org" References: <20241130010954.36057-1-volodymyr_babchuk@epam.com> <20241130010954.36057-5-volodymyr_babchuk@epam.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: <20241130010954.36057-5-volodymyr_babchuk@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.11.2024 02:10, Volodymyr Babchuk wrote: > Enable previously added CONFIG_STACK_PROTECTOR feature for RISC-V > platform. Here we can call boot_stack_chk_guard_setup() in start_xen() > function, because it never returns, so stack protector code will not > be triggered because of changed canary. > > Signed-off-by: Volodymyr Babchuk > Tested-by: Oleksii Kurochko Isn't this premature? For ... > @@ -57,6 +58,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id, > if ( !boot_fdt_info(device_tree_flattened, dtb_addr) ) > BUG(); > > + boot_stack_chk_guard_setup(); ... this function's use of get_random(), either arch_get_random() needs to be implemented, or (as Julien also pointed out for Arm64) NOW() needs to work. Yet get_s_time() presently expands to just BUG_ON(). Given this it's not even clear to me how Oleksii managed to actually test this. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 08:28:16 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 08:28:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846335.1261498 (Exim 4.92) (envelope-from ) id 1tI1mg-0000c3-JY; Mon, 02 Dec 2024 08:27:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846335.1261498; Mon, 02 Dec 2024 08:27: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 1tI1mg-0000bw-Ft; Mon, 02 Dec 2024 08:27:58 +0000 Received: by outflank-mailman (input) for mailman id 846335; Mon, 02 Dec 2024 08:27: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 1tI1mf-0000bq-3V for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 08:27:57 +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 5283f8ed-b087-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 09:27:52 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-385d6e36de7so3472549f8f.0 for ; Mon, 02 Dec 2024 00:27:53 -0800 (PST) Received: from ?IPV6:2003:e5:872e:b100:d3c7:e0c0:5e3b:aa1c? (p200300e5872eb100d3c7e0c05e3baa1c.dip0.t-ipconnect.de. [2003:e5:872e:b100:d3c7:e0c0:5e3b:aa1c]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-385ed8dee66sm3853882f8f.104.2024.12.02.00.27.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 00:27: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: 5283f8ed-b087-11ef-a0d2-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo0MzMiLCJoZWxvIjoibWFpbC13cjEteDQzMy5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjUyODNmOGVkLWIwODctMTFlZi1hMGQyLThiZTBkYWMzMDJiMCIsInRzIjoxNzMzMTI4MDcyLjc3ODYyOSwic2VuZGVyIjoiamdyb3NzQHN1c2UuY29tIiwicmVjaXBpZW50IjoieGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnIn0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733128072; x=1733732872; 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=rgmP7IRPapdyM00KytQd+l/oRf7Nj76V9zYC2A411XM=; b=dXKLmo0EJT+Pbtv9E1TQ5JUd7U8HayzNsL8U13+JToVSzHw5uF29C1Gp5B+mtOC3Jt BK8cnUNrMAx+AarN0iRwcWieneKEZwozZf1CGoWCUDAn9s9SAe6gicsp7hXchC0El+bM GLk3uImVpaWIFQgkM7s2BFNoYzA3umF0S5HlTzAfVdH/GcKdkloY1Iq+C5GqyMjHSfFv 0JLIbfOYobI+hlpQB2Z8XHqpcKYDu0qH3qeZQyDMOkw2YZCvChCagQbFQOrZgeG97MLF C0/tHRhdeQ9Hen8sw+zpg4CZvPRUElEuk5QpnXbYUL8GgdvSwshaz53ispxtXSKNWy3m utow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733128072; x=1733732872; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=rgmP7IRPapdyM00KytQd+l/oRf7Nj76V9zYC2A411XM=; b=NxHlPpfER+A12E+hqAoLvGo26SXemTwdjKn74NogiB7bIc2T27qJM1ETWEoNS9Vlf7 IUY1HkpKf6q5ZKi0wdAYyHZhD8ls6DRKNDXSWbznixKvZ+fdmlJXjFaCnAfXLt7D0emZ 8dmf82a0xqF5PrQqJxGDBnYQAuOlsvO9eLk6Kzv8SRLXfiHL51mSwM+xi9yKbn/+45im qHt7fpS7zXGuKIXTrvSnprHCBinIjBYgxBBFYyEkB97weT5KE9Kj+7RbyTzbn+U3W1rL M4vgxAT5yggW9ImizT+htWzUSpZHvrDVZssCaGesTi7NDyJer4Dh3px5EDhy+2uMYOFt Es6A== X-Forwarded-Encrypted: i=1; AJvYcCVecmdJejjTfrLUBVZN3ZVBoACaBMui4IP5/dzQ0wSW2I4uD0IEkWbFRXbROllWqfBwgVx1FJbvJNc=@lists.xenproject.org X-Gm-Message-State: AOJu0YzCB9Ztzamu/I5Hcm8YMDgqViaPsXgnzaZ805230KJpeSlFkmW3 wCeNg/dYt8jgkC0XzzmVU24wITlYyWcsQ4508K//w2W7d3K8yM1iIAHh6wWMf4U= X-Gm-Gg: ASbGncu4gIf6Icq9lJiGDHsuuHrhBFdWMarqX8FAvKw26Oxks1OvwJ6M05VPJ0MSWDc A2hAVGHWLKisSd+RLQdIU22yuDqLkbZp6RknZ330DpGJRo5Xuye+yiYy5EdZ+hNClcDnXCOCNUF k9xCoxxCxWbG32si3+aj8H2nE4WnHfsmqr/aPYjG8ypi9aCEzgtywc3ETjA6d8zY/1X+ionGgLX r14p9jL3BmHUCL5FOOtIw1YMltMtGrElSm8dij2LMC5kWecC9S42Do0F2GxmXibRJgFjfaZ6Z1a b1ksNWnDTw+5xKleW/wL2/73dCQbays8w43unS6QmFpIOgcJempzqyAke811QTsgPbET4gDqkrA = X-Google-Smtp-Source: AGHT+IHCew4p32M0fnntOLTxvXn5rhPcZ/Oxoj8redCrFVYAiUiu7LZghywbN0mQOwwTkZ319CdZ2g== X-Received: by 2002:a5d:5f43:0:b0:385:f66a:4271 with SMTP id ffacd0b85a97d-385f66a4481mr1226523f8f.4.1733128072319; Mon, 02 Dec 2024 00:27:52 -0800 (PST) Message-ID: <2d4fd45a-2461-441e-a116-3b6cff18ee9e@suse.com> Date: Mon, 2 Dec 2024 09:27:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] xen/swiotlb: add alignment check for dma buffers To: Thierry Escande , linux-kernel@vger.kernel.org, iommu@lists.linux.dev Cc: Stefano Stabellini , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, jbeulich@suse.com References: <20240916064748.18071-1-jgross@suse.com> <20240916064748.18071-2-jgross@suse.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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------cqzeUayVGoZI9y6WbVrHfeVr" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------cqzeUayVGoZI9y6WbVrHfeVr Content-Type: multipart/mixed; boundary="------------YLCLZf9pp80BxTgr2PYG6yMv"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Thierry Escande , linux-kernel@vger.kernel.org, iommu@lists.linux.dev Cc: Stefano Stabellini , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, jbeulich@suse.com Message-ID: <2d4fd45a-2461-441e-a116-3b6cff18ee9e@suse.com> Subject: Re: [PATCH v2 1/2] xen/swiotlb: add alignment check for dma buffers References: <20240916064748.18071-1-jgross@suse.com> <20240916064748.18071-2-jgross@suse.com> In-Reply-To: Autocrypt-Gossip: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------YLCLZf9pp80BxTgr2PYG6yMv Content-Type: multipart/mixed; boundary="------------u48cR0db4DRmFDg6gYOPKEyz" --------------u48cR0db4DRmFDg6gYOPKEyz Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjkuMTEuMjQgMTg6MzYsIFRoaWVycnkgRXNjYW5kZSB3cm90ZToNCj4gSGksDQo+IA0K PiBPbiAxNi8wOS8yMDI0IDA4OjQ3LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gZGlmZiAt LWdpdCBhL2RyaXZlcnMveGVuL3N3aW90bGIteGVuLmMgYi9kcml2ZXJzL3hlbi9zd2lvdGxi LXhlbi5jDQo+PiBpbmRleCAzNTE1NTI1OGE3ZTIuLmRkZjViMWRmNjMyZSAxMDA2NDQNCj4+ IC0tLSBhL2RyaXZlcnMveGVuL3N3aW90bGIteGVuLmMNCj4+ICsrKyBiL2RyaXZlcnMveGVu L3N3aW90bGIteGVuLmMNCj4+IEBAIC03OCw5ICs3OCwxNSBAQCBzdGF0aWMgaW5saW5lIGlu dCByYW5nZV9zdHJhZGRsZXNfcGFnZV9ib3VuZGFyeShwaHlzX2FkZHJfdCBwLCBzaXplX3Qg c2l6ZSkNCj4+ICAgew0KPj4gICAJdW5zaWduZWQgbG9uZyBuZXh0X2JmbiwgeGVuX3BmbiA9 IFhFTl9QRk5fRE9XTihwKTsNCj4+ICAgCXVuc2lnbmVkIGludCBpLCBucl9wYWdlcyA9IFhF Tl9QRk5fVVAoeGVuX29mZnNldF9pbl9wYWdlKHApICsgc2l6ZSk7DQo+PiArCXBoeXNfYWRk cl90IGFsZ24gPSAxVUxMIDw8IChnZXRfb3JkZXIoc2l6ZSkgKyBQQUdFX1NISUZUKTsNCj4+ ICAgDQo+PiAgIAluZXh0X2JmbiA9IHBmbl90b19iZm4oeGVuX3Bmbik7DQo+PiAgIA0KPj4g KwkvKiBJZiBidWZmZXIgaXMgcGh5c2ljYWxseSBhbGlnbmVkLCBlbnN1cmUgRE1BIGFsaWdu bWVudC4gKi8NCj4+ICsJaWYgKElTX0FMSUdORUQocCwgYWxnbikgJiYNCj4+ICsJICAgICFJ U19BTElHTkVEKG5leHRfYmZuIDw8IFhFTl9QQUdFX1NISUZULCBhbGduKSkNCj4+ICsJCXJl dHVybiAxOw0KPiANCj4gVGhlcmUgaXMgYSByZWdyZXNzaW9uIGluIHRoZSBtcHQzc2FzIGRy aXZlciBiZWNhdXNlIG9mIHRoaXMgY2hhbmdlLg0KPiBXaGVuLCBpbiBhIGRvbTAsIHRoaXMg ZHJpdmVyIGNyZWF0ZXMgaXRzIERNQSBwb29sIGF0IHByb2JlIHRpbWUgYW5kDQo+IGNhbGxz IGRtYV9wb29sX3phbGxvYygpIChzZWUgWzFdKSwgdGhlIGNhbGwgdG8NCj4gcmFuZ2Vfc3Ry YWRkbGVzX3BhZ2VfYm91bmRhcnkoKSAoZnJvbSB4ZW5fc3dpb3RsYl9hbGxvY19jb2hlcmVu dCgpKQ0KPiByZXR1cm5zIDEgYmVjYXVzZSBvZiB0aGUgYWxpZ25tZW50IGNoZWNrcyBhZGRl ZCBieSB0aGlzIHBhdGNoLiBUaGVuIHRoZQ0KPiBjYWxsIHRvIHhlbl9jcmVhdGVfY29udGln dW91c19yZWdpb24oKSBpbiB4ZW5fc3dpb3RsYl9hbGxvY19jb2hlcmVudCgpDQo+IGZhaWxz IGJlY2F1c2UgdGhlIHBhc3NlZCBzaXplIG9yZGVyIGlzIHRvbyBiaWcgKD4gTUFYX0NPTlRJ R19PUkRFUikuDQo+IFRoaXMgZHJpdmVyIHNldHMgdGhlIHBvb2wgYWxsb2NhdGlvbiBibG9j ayBzaXplIHRvIDIuMysgTUJ5dGVzLg0KPiANCj4gIEZyb20gcHJldmlvdXMgZGlzY3Vzc2lv bnMgb24gdGhlIHYxIHBhdGNoLCB0aGVzZSBjaGVja3MgYXJlIG5vdA0KPiBuZWNlc3Nhcnkg ZnJvbSB4ZW5fc3dpb3RsYl9hbGxvY19jb2hlcmVudCgpIHRoYXQgYWxyZWFkeSBlbnN1cmVz DQo+IGFsaWdubWVudCwgcmlnaHQ/DQoNCkl0IGVuc3VyZXMgYWxpZ25tZW50IHJlZ2FyZGlu ZyBndWVzdCBwaHlzaWNhbCBtZW1vcnksIGJ1dCBpdCBkb2Vzbid0IGRvDQpzbyBmb3IgbWFj aGluZSBtZW1vcnkuDQoNCkZvciBETUEgbWFjaGluZSBtZW1vcnkgcHJvcGVyIGFsaWdubWVu dCBtaWdodCBiZSBuZWVkZWQsIHRvbywgc28gdGhlDQpjaGVjayBpcyByZXF1aXJlZC4gQXMg YW4gZXhhbXBsZSwgc29tZSBjcnlwdG8gZHJpdmVycyBzZWVtIHRvIHJlbHkgb24NCnByb3Bl ciBtYWNoaW5lIG1lbW9yeSBhbGlnbm1lbnQsIHdoaWNoIHdhcyB0aGUgcmVhc29uIGZvciB0 aG9zZSBjaGVja3MNCnRvIGJlIGFkZGVkLg0KDQpQb3NzaWJsZSBzb2x1dGlvbnMgaW5jbHVk ZToNCg0KLSByaXNpbmcgdGhlIE1BWF9DT05USUdfT1JERVIgbGltaXQgKHRvIHdoaWNoIHZh bHVlPykNCi0gYWRkaW5nIGEgd2F5IHRvIGFsbG9jYXRlIGxhcmdlIERNQSBidWZmZXJzIHdp dGggcmVsYXhlZCBhbGlnbm1lbnQNCiAgIHJlcXVpcmVtZW50cyAodGhpcyB3aWxsIGltcGFj dCB0aGUgd2hvbGUgRE1BIGluZnJhc3RydWN0dXJlIHBsdXMNCiAgIGRyaXZlcnMgbGlrZSBt cDNzYXMgd2hpY2ggd291bGQgbmVlZCB0byB1c2UgdGhlIG5ldyBpbnRlcmZhY2UpDQotIG1v ZGlmeSB0aGUgbXB0M3NhcyBkcml2ZXIgdG8gc3RheSB3aXRoaW4gdGhlIGN1cnJlbnQgbGlt aXRzDQotIG9ubHkgZ3VhcmFudGVlIHByb3BlciBtYWNoaW5lIG1lbW9yeSBhbGlnbm1lbnQg dXAgdG8gTUFYX0NPTlRJR19PUkRFUg0KICAgKHJpc2tpbmcgdG8gaW50cm9kdWNlIGhhcmQg dG8gZGlhZ25vc2UgYnVncyBmb3IgdGhlIHJhcmUgdXNlIGNhc2VzIG9mDQogICBzdWNoIGxh cmdlIGJ1ZmZlcnMpDQoNCg0KSnVlcmdlbg0K --------------u48cR0db4DRmFDg6gYOPKEyz 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----- --------------u48cR0db4DRmFDg6gYOPKEyz-- --------------YLCLZf9pp80BxTgr2PYG6yMv-- --------------cqzeUayVGoZI9y6WbVrHfeVr 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/Ey8FAmdNb4YFAwAAAAAACgkQsN6d1ii/Ey8i owf/TcDODvWNKhz2VeRgdGyE7HG1+otkteHBaLk+f4aNs23ObF6X7Eravdqcc39HkM7V+U1KRQba j0VvZVkgmnrnvbWVNmvDXvlrcWfAurH+29rJUNHZWTtiPPpQ6Y+yYeCfhhvtweoKSY4wY//7sfSK LdmmrXyQMhyFGF8VMhbcpXtp+3Ep7ChdpJnlQxo2TchCzYW75cV+SwkCOM3+F7MknUlcYIwPTmxD 2ODvXeNIWVZsOjeXB3pxsrn0szX4c0OVf4LnmbdE0ZfY42oRNtKB3pafJIBAk71wdgS7/Pf/tut5 fotoeuKAermUDfRksDgHxVMYeJgV0CXVXx24/bgpHA== =A3ah -----END PGP SIGNATURE----- --------------cqzeUayVGoZI9y6WbVrHfeVr-- From xen-devel-bounces@lists.xenproject.org Mon Dec 02 08:29:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 08:29:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846346.1261507 (Exim 4.92) (envelope-from ) id 1tI1oP-0001DM-0P; Mon, 02 Dec 2024 08:29:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846346.1261507; Mon, 02 Dec 2024 08:29: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 1tI1oO-0001DF-UE; Mon, 02 Dec 2024 08:29:44 +0000 Received: by outflank-mailman (input) for mailman id 846346; Mon, 02 Dec 2024 08:29: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 1tI1oN-0001D7-JO for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 08:29:43 +0000 Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [2a00:1450:4864:20::129]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 930004c8-b087-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 09:29:40 +0100 (CET) Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-53df67d6659so5624811e87.3 for ; Mon, 02 Dec 2024 00:29: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 a640c23a62f3a-aa5997d55eesm481814466b.80.2024.12.02.00.29.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 00:29: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: 930004c8-b087-11ef-a0d2-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjoxMjkiLCJoZWxvIjoibWFpbC1sZjEteDEyOS5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjkzMDAwNGM4LWIwODctMTFlZi1hMGQyLThiZTBkYWMzMDJiMCIsInRzIjoxNzMzMTI4MTgwLjU3NzUwOCwic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733128180; x=1733732980; 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=YBnG0jgYVPf8aIoX2AG24CNnm8979480L+azcJ+l19o=; b=JcEr3vuDSg8qYpGpw6+GWtbXxiVuQfkMsIU1LSsVwJH+S9nJI3L+TuWNK17xQMO1J/ Bo7U8CkTq3eQrfVcawadX2Jd9O7DDMQavRQzUatehlDYEUov1QpKUzMPbV5IMNCGw2m8 urf5yq3zpjQk6Q9Kc6X+mPAkbB8iKWIF/yUIfZKIPmHCQrYHeCCaRQWCtH8qGEhBmslt dMrtiwm/rPmii7ytM49pmfgtvXd8ni7LVQz0zcX5pKPookCn7K7fabiMrOCsbodkF/D9 BL9WOj3QmaSXgPBmmpn+2OA9WvHk3imIU8qzvpiYNgjz4xqROKhYca4l8BDX0U1SXV0+ k1+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733128180; x=1733732980; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=YBnG0jgYVPf8aIoX2AG24CNnm8979480L+azcJ+l19o=; b=dNNU7O+k5oKJJ8oWgoFuh+9DA7jjfUQpXSrRcy9QCNPN66sQs4miWmzLh2ZIh4p3fK dPCTVsILaIMeD2zfzSRWTZATtjFf28F+FP2TfV6KDjEBX0lMtJOc1Cww3MEyTPluM17N 4X3eDbND+c0NUv1Tw/TPrzJShf/ftV5vXZq1RxIJ1yykWRFYJibA9L4n8DCmZbMx4c18 xYddIcTKRUxsqhwQHM8yVGx97TtsX+VarSthN2VpWanGzXBL6x3MFZ6Q9Ea/SpYdPjNS BB6PVR6cS1wpMozhW54gdSc/q89Ni9EVDdWcXvU4KNJR9uc3ldqil/7CCHvb3CQBUSHU ICxg== X-Forwarded-Encrypted: i=1; AJvYcCVZSsGiwhSaJ7yLGH9cKbVO2p7mcLYlSBTTsdY+69LGQaWVNdv0D85yBn51TTDissUnTbVVCNU9wp0=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywi+uj/0s2rpTF6p6FAQ6/dluNTwxWIS6suO6PV1K+M8LAsg7uB rz5kmtAYQhZKRZr0F4NV5xgjsaVMX6U7mHKuJiCVUCin9bGrsQun5MeNoAYK5w== X-Gm-Gg: ASbGnctZq3AddZoVfV1a30Oz+WKBR84FHRFcVjq24ugFoIBjfnoulGkItcHe0kw38PR WJIZ98savKhMfMdw2iTxo8V+IXPSoKLrJE8i5gEMHIc+c1shPjBfXZ+mILDJ6EZ0c61ThGURQMT lGA8iqzZvz8eUsNSKuIp4R1oyaJpeQiurIbrK81gNWwi4jtCJxtWN7hBKvmx7dLwZD3q3CVwAuK ZdJTaHeRmQdUfIRCkRl8gDd0hB6I55may5aHEfe1WhZi7Ti8//rXq9Y8SvtBkBCDGVco5pdyZYW baPxZhegEe5lYr+7lsavxXxuyASD1W7A7dU= X-Google-Smtp-Source: AGHT+IHmVda+hYlUcPppcnC9b39ra8GFvlKGc8JKvNVBW8NCXEfbAq8pABFez3hRE40xd6tFdyJh5w== X-Received: by 2002:a05:6512:3d87:b0:53d:ecfc:306d with SMTP id 2adb3069b0e04-53df00cf62dmr13460297e87.19.1733128180426; Mon, 02 Dec 2024 00:29:40 -0800 (PST) Message-ID: Date: Mon, 2 Dec 2024 09:29:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/4] xen: common: add ability to enable stack protector To: Volodymyr Babchuk Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , "xen-devel@lists.xenproject.org" References: <20241130010954.36057-1-volodymyr_babchuk@epam.com> <20241130010954.36057-3-volodymyr_babchuk@epam.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: <20241130010954.36057-3-volodymyr_babchuk@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.11.2024 02:10, Volodymyr Babchuk wrote: > --- /dev/null > +++ b/xen/common/stack-protector.c > @@ -0,0 +1,10 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +#include > +#include > + > +unsigned long __ro_after_init __stack_chk_guard; > + > +void __stack_chk_fail(void) > +{ > + panic("Detected stack corruption\n"); > +} That's very little information that'll end up in the log to understand what has gone wrong. > --- /dev/null > +++ b/xen/include/xen/stack-protector.h > @@ -0,0 +1,29 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#ifndef XEN__STACK_PROTECTOR_H > +#define XEN__STACK_PROTECTOR_H > + > +#ifdef CONFIG_STACKPROTECTOR > + > +extern unsigned long __stack_chk_guard; > + > +/* > + * This function should be always inlined. Also it should be called > + * from a function that never returns or a function that with > + * stack-protector disabled. > + */ > +static always_inline void boot_stack_chk_guard_setup(void) > +{ > + __stack_chk_guard = get_random(); > + if (BITS_PER_LONG == 64) > + __stack_chk_guard |= ((unsigned long)get_random()) << 32; > +} The hard tabs here make it look like Linux style, when - unless there's a specific reason - new files want to be Xen style. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 08:53:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 08:53:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846357.1261518 (Exim 4.92) (envelope-from ) id 1tI2BR-0005e0-SC; Mon, 02 Dec 2024 08:53:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846357.1261518; Mon, 02 Dec 2024 08:53: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 1tI2BR-0005dt-Ox; Mon, 02 Dec 2024 08:53:33 +0000 Received: by outflank-mailman (input) for mailman id 846357; Mon, 02 Dec 2024 08:53: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 1tI2BQ-0005dn-JB for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 08:53:32 +0000 Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [2a00:1450:4864:20::42d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e5e691c9-b08a-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 09:53:28 +0100 (CET) Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-385e3621518so1364011f8f.1 for ; Mon, 02 Dec 2024 00:53: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-385dfb2d7e0sm8703660f8f.44.2024.12.02.00.53.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 00:53: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: e5e691c9-b08a-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo0MmQiLCJoZWxvIjoibWFpbC13cjEteDQyZC5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6ImU1ZTY5MWM5LWIwOGEtMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTI5NjA4LjI4NDg2OCwic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733129608; x=1733734408; 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=eHwGe0iie1X8zSQpM1na0u6g//5QLMPxvpkm6VnnP+s=; b=C2hVsaY45m96fXc1A4j/mQ9zV1PxQpmN5/1nHPml+wpy4vn5ErbehwmCs6Hk46zZn7 IYcu6ASqElKjmDgHE3/Xirs7VcdEMPO3k+PDy4UuHexqHbmH3vw57vAuuwDcsdxVgDnA J91H4oP4Rf3JWhexxWxjdUKzksqKZKJbkdhb3Nch4CwFBfW4STeq58G4c6ea7fAVkv+A fGMGaAcmMjvY62cAxVxgCpxnrCNlTBe7Kv7PqrdteJCHOi+wMTAFCdNj/msZC/8Wb1eR w8NNsQsoPP8GHjiP6Ai+ZitC4VLZYdeNm2d+2+0PSQvb9xQ7pHnuzmZrUAOIxEorwsVK WNbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733129608; x=1733734408; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=eHwGe0iie1X8zSQpM1na0u6g//5QLMPxvpkm6VnnP+s=; b=qVBl2JObXOYbflej+VsqGEl8YtMCxYlEXJxvY5nv2wxAsYSyjQePSDhas1PT1yWZ6y YGprMINkLQKIeD8v9Nv8VEqEhKXxI0j+qfwmaHavqB2NbBz8TfiR+agQrxNaAOwOCgTr 9znfESYqKGUfI8htx+vL0F05OYX+vo6+O00wq5X7IoP1HijA4bPGPCNrEGFvW+exFRbv Z0d+gN+zpMCxE6JdMfxPmX7jlgiSDPFrA87442J4Vc/nbO/EEaFD+qgU9otV0ZMmsvBF QbtzaMsmI04Y0SrAxTdkg84PWKQyhgL2AFJGDDk+Ow2aliHcv2kWwMAQSsvu7XuAXOjq OOhQ== X-Gm-Message-State: AOJu0Yzl3cfWLb2uL6VoVQyo+kgc2RCdU9P5JYyP/gUe7jook8vSKNJo DJwFIgfpmoX580KbHnfn5cyCYb0ejJRVm1neSxhfoAYspmCrZHUZkSCTClcxhw== X-Gm-Gg: ASbGncsYQtFibrIwf2JOsplefDKnMhpzRIXWhjA76Lmh70fwMz2odR4yCaJZulbc45L F+d26ceoxn1l417i02JZyO4FBtaQFdLtmBs+5EhHI1zwGheaBLjxhmRR5nGJwUJoz71/NicrMD4 59Gt9XRdHJ+OsvxKdUTrJCq6tDcgOnNE96jEAkZ2ooqKBIhdEwEOSBwdE19wiYv1xWut37hbDaT 56WUu91zRUJblqAJA9vMZFotGWTP51vVnuD1znOfzQJ69Y8bRlcgZtbzCPR+mh491EQlpBJff+y dyuDP4ARl5MfwUhBbWGB6/eUXwiPGGvRPzA= X-Google-Smtp-Source: AGHT+IGVew6GaD1esGkYvevWZtkzCQ0h2rtWln06y+MyoFrYTedF8dpo8R7J9URPPxWhKk0OXR7MbA== X-Received: by 2002:a05:6000:1fac:b0:382:5aae:87ac with SMTP id ffacd0b85a97d-385c6ec0c37mr17966537f8f.32.1733129607697; Mon, 02 Dec 2024 00:53:27 -0800 (PST) Message-ID: <95754086-9c90-4765-b386-299baf2b5f94@suse.com> Date: Mon, 2 Dec 2024 09:53:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] xl: Keep monitoring suspended domain To: Anthony PERARD , Jason Andryuk Cc: xen-devel@lists.xenproject.org References: <20241126171941.170897-1-jason.andryuk@amd.com> <20241126171941.170897-2-jason.andryuk@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 28.11.2024 17:45, Anthony PERARD wrote: > On Tue, Nov 26, 2024 at 12:19:40PM -0500, Jason Andryuk wrote: >> When a VM transitioned to LIBXL_SHUTDOWN_REASON_SUSPEND, the xl daemon >> was exiting as 0 = DOMAIN_RESTART_NONE "No domain restart". >> Later, when the VM actually shutdown, the missing xl daemon meant the >> domain wasn't cleaned up properly. >> >> Add a new DOMAIN_RESTART_SUSPENDED to handle the case. The xl daemon >> keeps running to react to future shutdown events. >> >> The domain death event needs to be re-enabled to catch subsequent >> events. The libxl_evgen_domain_death is moved from death_list to >> death_reported, and then it isn't found on subsequent iterations through >> death_list. We enable the new event before disabling the old event, to >> keep the xenstore watch active. If it is unregistered and >> re-registered, it'll fire immediately for our suspended domain which >> will end up continuously re-triggering. >> >> Signed-off-by: Jason Andryuk > > Reviewed-by: Anthony PERARD While committing I was wondering: Does this want/need backporting (and hence was it perhaps lacking a Fixes: tag)? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 08:54:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 08:54:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846363.1261527 (Exim 4.92) (envelope-from ) id 1tI2CD-00068h-3q; Mon, 02 Dec 2024 08:54:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846363.1261527; Mon, 02 Dec 2024 08:54: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 1tI2CD-00068a-0p; Mon, 02 Dec 2024 08:54:21 +0000 Received: by outflank-mailman (input) for mailman id 846363; Mon, 02 Dec 2024 08:54: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 1tI2CC-00068L-5L for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 08:54:20 +0000 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [2a00:1450:4864:20::62d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 029d491b-b08b-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 09:54:16 +0100 (CET) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a9a0ef5179dso591487666b.1 for ; Mon, 02 Dec 2024 00:54:16 -0800 (PST) Received: from [192.168.219.191] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5998e6a7bsm488238766b.104.2024.12.02.00.54.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 00:54: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: 029d491b-b08b-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo2MmQiLCJoZWxvIjoibWFpbC1lajEteDYyZC5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjAyOWQ0OTFiLWIwOGItMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTI5NjU2LjQyMTM1Niwic2VuZGVyIjoib2xla3NpaS5rdXJvY2hrb0BnbWFpbC5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733129656; x=1733734456; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=dZUijcyDzNV98iY9ZbR4bomJkysKQdUxcq1edYarO/8=; b=neks+QJT5U1jm7vaRHeZqDlFZ3ZRGeMV0bcS2i9wUTpU/b5EB1Y9pM34NcpmcEVSKG Pp2rO9/qjurxYt1iaSm9J8KTTzOcshi3j/rjmb/o0hVaVA4fQUWqJ5KCQMCA2i/PrVbE b1s9Efn727BBazCWpnHu1ExHrBWlabAp+hm3IYYqEz7fIrAnUdsAU409IBdG4Kcc6MXl hnCxfje5ooy0Ebf6DJ8FdIXD0iMzkO9krLbPtLQNgzNGEEDIQlLnZP9kcq2yeFQUQcD+ YDtzTLg/ew0FBEsM71a3DxAc9xL3Qti6GXs1UAG8yVdshKC6ebvdSZyVdMkxqt/elQ6F FkfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733129656; x=1733734456; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=dZUijcyDzNV98iY9ZbR4bomJkysKQdUxcq1edYarO/8=; b=LhMzJZjfPULo94L7ZPG7QkW1hdSkfsl6I3RN36nvsrG1I4X6P+TcIx4M5Vm/Z9jUiB MykIKm6kRaErsvezPaRvTNUjJz+E2zpQOj8eS+52KIsJh7ALg7P1F1A8yGfK3kcokH0L 1ueEHAtYYNeA0IWPZv10ObwpJZl6DH+/cv4AJcojWQYV3wJzOkbwu2+I/w8RzG3yEggO erdMV+puN7YMI7LhvLvcwDSiSwwMxja7chb1sgEGr2IQcXPuIaW0dZhLihat8AgNnyrI 2OTlnt+ovHuL7Bq1jJJCx9I0uOtxJtD7MZdKK6ZJXx1kBlrUFFr00Ku3GrCEYv91y3F3 DR9w== X-Forwarded-Encrypted: i=1; AJvYcCUqvhuTouZdNN/senxCfVOgkIYBpu9a5HescNhKyTLHYEyH4EIVxe+BwFiXzUyDBfAGhTlpSVa8/g8=@lists.xenproject.org X-Gm-Message-State: AOJu0YzMs2MaKa6b8WbNlRN6FR2p4vpaAYtDITUbhtzMsEBcxX9S+eAx 85BhCH5Hr8FNukn+4wCgdmHEMjbyMd7ijrEHzXUSqZGcI7W08HCn X-Gm-Gg: ASbGncvoJI0/NA9mWugXs6Jy5cwvE+UnoyCi83YuCRNHx//x1cxy3TnO66O8hVlwHOs ao/ulCmEFjafx04IlWS/yn0Tmvf1KINjztUjs9ohKUjloc14M4Lt+CtSfAuToJpmDiFFWZ5/jg+ itpb6gUpguHa71GQPcEnAkKGBkW3wYitRRUUKVYjO7urxh02InAYsUMDh5HMqwUja+U1YFPFTZf L5mWTRaOmQtYfDx9BUsW+arh40dghJikzT6YTWbFjktyghOZHDK1DZMgJa+yYU= X-Google-Smtp-Source: AGHT+IHhQUM71YH2xe8wwkyNg4QGHUT24oGw+VzvMsf3VwEiL36j1tLIvMGgYHfjG5FmeBgd55xVXw== X-Received: by 2002:a17:906:1baa:b0:aa5:470d:c95d with SMTP id a640c23a62f3a-aa58102833fmr1510949466b.37.1733129655646; Mon, 02 Dec 2024 00:54:15 -0800 (PST) Message-ID: <567b703b80d13bf6412f48e5f06e1f5d9733e0ac.camel@gmail.com> Subject: Re: [PATCH v2 4/4] xen: riscv: enable stack protector feature From: oleksii.kurochko@gmail.com To: Jan Beulich , Volodymyr Babchuk Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , Julien Grall , Stefano Stabellini , "xen-devel@lists.xenproject.org" Date: Mon, 02 Dec 2024 09:54:14 +0100 In-Reply-To: <2f92aeb0-bb1f-49d0-9655-8ff93fee8837@suse.com> References: <20241130010954.36057-1-volodymyr_babchuk@epam.com> <20241130010954.36057-5-volodymyr_babchuk@epam.com> <2f92aeb0-bb1f-49d0-9655-8ff93fee8837@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 (3.54.1-1.fc41app1) MIME-Version: 1.0 On Mon, 2024-12-02 at 09:12 +0100, Jan Beulich wrote: > On 30.11.2024 02:10, Volodymyr Babchuk wrote: > > Enable previously added CONFIG_STACK_PROTECTOR feature for RISC-V > > platform. Here we can call boot_stack_chk_guard_setup() in > > start_xen() > > function, because it never returns, so stack protector code will > > not > > be triggered because of changed canary. > >=20 > > Signed-off-by: Volodymyr Babchuk > > Tested-by: Oleksii Kurochko >=20 > Isn't this premature? For ... >=20 > > @@ -57,6 +58,8 @@ void __init noreturn start_xen(unsigned long > > bootcpu_id, > > =C2=A0=C2=A0=C2=A0=C2=A0 if ( !boot_fdt_info(device_tree_flattened, dtb= _addr) ) > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BUG(); > > =C2=A0 > > +=C2=A0=C2=A0=C2=A0 boot_stack_chk_guard_setup(); >=20 > ... this function's use of get_random(), either arch_get_random() > needs > to be implemented, or (as Julien also pointed out for Arm64) NOW() > needs > to work. Yet get_s_time() presently expands to just BUG_ON(). Given > this > it's not even clear to me how Oleksii managed to actually test this. I will double check that but it worked for me ( I didn't face BUG_ON() ). ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Dec 02 09:00:20 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 09:00:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846379.1261553 (Exim 4.92) (envelope-from ) id 1tI2Hu-0007s7-RY; Mon, 02 Dec 2024 09:00:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846379.1261553; Mon, 02 Dec 2024 09:00: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 1tI2Hu-0007s0-Ov; Mon, 02 Dec 2024 09:00:14 +0000 Received: by outflank-mailman (input) for mailman id 846379; Mon, 02 Dec 2024 09:00: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 1tI2Ht-0007ru-8G for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 09:00:13 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on20623.outbound.protection.outlook.com [2a01:111:f403:200a::623]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d0ecfe85-b08b-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 10:00:04 +0100 (CET) Received: from CH5PR02CA0023.namprd02.prod.outlook.com (2603:10b6:610:1ed::24) by CY5PR12MB6345.namprd12.prod.outlook.com (2603:10b6:930:22::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Mon, 2 Dec 2024 08:59:58 +0000 Received: from CH2PEPF00000144.namprd02.prod.outlook.com (2603:10b6:610:1ed:cafe::76) by CH5PR02CA0023.outlook.office365.com (2603:10b6:610:1ed::24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.17 via Frontend Transport; Mon, 2 Dec 2024 08:59:58 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by CH2PEPF00000144.mail.protection.outlook.com (10.167.244.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Mon, 2 Dec 2024 08:59:58 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 2 Dec 2024 02:59:57 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) 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; Mon, 2 Dec 2024 02:59:57 -0600 Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Mon, 2 Dec 2024 02:59:55 -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: d0ecfe85-b08b-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDE6MTExOmY0MDM6MjAwYTo6NjIzIiwiaGVsbyI6Ik5BTTEyLU1XMi1vYmUub3V0Ym91bmQucHJvdGVjdGlvbi5vdXRsb29rLmNvbSJ9 X-Custom-Transaction: eyJpZCI6ImQwZWNmZTg1LWIwOGItMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTMwMDA0LjAzODk3Miwic2VuZGVyIjoibWljaGFsLm9yemVsQGFtZC5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FBd6ADSQXbKsXgLZlwVy6g1vJOxSp5J2taU0/sEi0AWgpnxIgZTxsGWafcDz89Hp1FYEtspsRHvY/As+vfJmvdrNJxzvejotdqT5JNQDPClk8C3rq/1ZzWZRt+YHOmxjSNgbXDTGBSJ/NWcJv1THwcPmk9actKm922QbbLuS6yF8kZUBQawsPY6nTBRQI5qT1P+mI5jXV93RcxcAkdm0NSqjegJrBG5dK5YhPLNXd657Cg2dXOsZMxmjzcMNQxcGSMXosAeLsCXm5WD6gWiWG9uZRDzcRqOGXmxfxWcGhtvBfTZG1K/9norttTfIuHhbsHmE7zKlMVuo3fHZzfk9rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gp/U1v6+FQ6/1wXETDAFYDJzqNc3x2DplBj5uXrEDyg=; b=WP+l1d2ksuSJxKLANCkc2olHsYIoOjvKbW+L/VlbC48xACQFCSuHC+cQcNuLhMQTmcK07fc78apuWZDPYrJQzdGz/Vo0QuwYaEZ0/wViMUEngdH68rzXkRmkcFbf/57G7RgisqWXga+YoVh0RmDkPTBNb4KU919CfwsWn3PGUWyth9achTCrk1/KRtY6SyhIdiypRhVFhs5FNrhCC5ARkbqPMPpxBPey8coqQPx3aSD6bQqKDYAIswqE3RkCG3PV+Cnv0amZlWdc+Eot7pis+DBWIm/G2ZFTihTtXpBnQwYxgadqEMd7C1MSJUjP2VsOazqATHg5xI0IGxJd4D9Gsg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=minervasys.tech smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gp/U1v6+FQ6/1wXETDAFYDJzqNc3x2DplBj5uXrEDyg=; b=hkGj8d07NwFEnrYXxyNmdB073TaRPGLGi7NWTK3WPgOtoKIXsJVRHnuOvJApZniZ4Z2rwePfZgOj6Ur7cfIeAd+2g2nyjb+VDCbHjZiWxx//wgwGmn+Z58p4wf1XADcb7qU5oq1DseAK5yA32iJLXbS0YjjuiuDmMirp+a/42L0= 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=SATLEXMB03.amd.com; pr=C Message-ID: Date: Mon, 2 Dec 2024 09:59:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v10 11/12] xen/arm: make consider_modules() available for xen relocation To: Carlo Nonato , CC: , , "Stefano Stabellini" , Julien Grall , "Bertrand Marquis" , Volodymyr Babchuk References: <20241119141329.44221-1-carlo.nonato@minervasys.tech> <20241119141329.44221-12-carlo.nonato@minervasys.tech> Content-Language: en-US From: Michal Orzel In-Reply-To: <20241119141329.44221-12-carlo.nonato@minervasys.tech> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PEPF00000144:EE_|CY5PR12MB6345:EE_ X-MS-Office365-Filtering-Correlation-Id: 7c4aa6ea-0467-41cc-3d29-08dd12afb2a1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?MjNLdHk1SU9GSGhWQVA0S2FvR1pLYlVTNEhXUE40YlBmRjRYQzJRYlZYaVJR?= =?utf-8?B?MWx1THcxaDREYXJRNUpYWFFMYUF1a1poYVhoMFkrSEpCOWRteDhJMUdIZ0No?= =?utf-8?B?clZhNFpKVGJyR0J0THBQR1ZTQzA1dUlNT00wakExV3l5aERybHlGRGtHbHp4?= =?utf-8?B?ZEZNUDFFaU5weXRPamJnb0lIZ29UeElJdGU5TUhReVNGMU0rNHFROWVLVkcx?= =?utf-8?B?VSs1d0Mva0k4NUN2NllQZGNDcytraG1GMjdHOWhTc082dzVQVTRXekx1ZEVQ?= =?utf-8?B?M0t3VUl6LzdhampKazNFY2tPcnVqbmI5NFVXa0ZKMmEvcldwSWdCaEQyMjFP?= =?utf-8?B?dlREeWF2c1ZtZ05KS25qRy9FczMvZEZ5Q0w0aWRhQVhxNlhSS0JQbmZqQVYy?= =?utf-8?B?cW4wZE9tUURGeGNNWjVVeThuNHRTQThWcHVHdWdkb25ZRGlDaXRJMldXTDB0?= =?utf-8?B?UTlWaDZyajNrMEZXTllrbUU5SzMveEpQdzROa2NBNlRZK0tZbHE5SDc4YzEv?= =?utf-8?B?TTF6QUlCVnlQc29NWWZvUjZhSFhITHlzaXVSbnNya1A4anRrbm5nL29YNU9D?= =?utf-8?B?bUZsK05tQWIrdXFZZkNFNEhtMDFaYnJiRCtjMkhaUmIyQkhqd0h0V2QxaElS?= =?utf-8?B?Y3dQMDAxNlQ5S0FjVVMveTczWmRUZjlYbWlFSGUyTG1WOUFPeDIvdmJudzI3?= =?utf-8?B?WXJiZ1QrY2kwbFUyNWpuRTZkejFMVTE2eXUyNGM5NEFUNnRGZUFVa21valg3?= =?utf-8?B?SVVDbkVHa3Z0bTVrTmV4dHRwWCtwYmttYWcrdjFJM0RkWGRxQVREdjhrWFhD?= =?utf-8?B?U29QZld3K0p6ZnJmanVOOTM4NUt5TkorN2VyNTdlZ1FqSWljckRPQVJNNE9v?= =?utf-8?B?ektTay9sWEFIUnBNbFdkMk5DeGhFZ2IyQmVWejZpa3VkejNJMnRBUjVKVkF0?= =?utf-8?B?Z2s0VFdvWUhJSGNldkxoL0c0K3hBSDhjb25oY1U2Y05RcmZCelNDaXgyS1hE?= =?utf-8?B?K3craUZRb0FVYnZhNkFQQlA4UHVGVlpWSmhLWmUzNzZTcHpQdFY4Sk94RHBr?= =?utf-8?B?YTV3cmxWUHJUWU1MZmlRYVg2NDN5dVFKUW1ERXF0aXE2WDlyV0tOTE5DK0Ir?= =?utf-8?B?WVFjUTl1dlAvTUthc2d2WXMxRjZ5SEFnd3FBOEx3OUlHb3dBWWZxRitYdDRM?= =?utf-8?B?bStmNHlCVmNBU3M1MjNmSTNyTjdoaG5PbG45bG9ySGpQeGtyNTNUOFNRQ0xx?= =?utf-8?B?aEIxNTZkQndjQlFLYlN4U0w1S0hFMEp1NURnQXRrSlV3UG9VMDFnZ3Z5QlIr?= =?utf-8?B?VklsV0NlRUxNTFlvZ0l1WmdyYjVnYVNvMHpFZEkzN2hZY1N1OEI1dU9EdlNn?= =?utf-8?B?RW90ejJVcW1yU1VVMExnc3FkWWFlT2tKOWlTc1RNaDVFckdVWWV0UTAwSnpB?= =?utf-8?B?QVcvQXlYQ2FqVGpBc0ZoNlNkMEpGL2FEdTBQZWtSWXdleFB6WXNHTlVqM1N0?= =?utf-8?B?TnJjT3dVRW1MZzJWeGhGTlRHSVh1cDkvR3ZqV1hTT1dyMGtndGx1VFFmeVo0?= =?utf-8?B?NnJrQm9ITnZQOE1qblBMc0RTdUVidmw2YTUzdUNRS0doSDJaZWpLK01tOHhs?= =?utf-8?B?UUxtWjZPZ3czcXA1QXUyaFI0bXd0MWNaNVVzSFN0clYvS3V1Qm5EL3plR2NG?= =?utf-8?B?UzduT3gxS3FqakZuSHRJbDZ5SDFHcHJod2ZIM0ptbnJIaDJNYjlxMWd4cUFB?= =?utf-8?B?MkJuTS9wUEpZMFlvTTcxWElFcy85UnN6cUIxUXRiQ3dRa09ndmhRWjNxb3gy?= =?utf-8?B?dTNOVnBKMTV5VGs5Mzg5VkxWdis5eDdlYXllaEd0T2ZUOHVId2hFOE5xbVIy?= =?utf-8?B?eGdrWG1QRVhOQWRucDJIL1pLamY3M2xGeEFMdzFkN2w2eWV0ZmVXVzZ2anRV?= =?utf-8?Q?gZmGl6mAunQBE9nIAqsYC+70SjLpZ2es?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Dec 2024 08:59:58.1029 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7c4aa6ea-0467-41cc-3d29-08dd12afb2a1 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=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH2PEPF00000144.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6345 On 19/11/2024 15:13, Carlo Nonato wrote: > > > Cache coloring must physically relocate Xen in order to color the hypervisor > and consider_modules() is a key function that is needed to find a new > available physical address. > > 672d67f339c0 ("xen/arm: Split MMU-specific setup_mm() and related code out") > moved consider_modules() under arm32. Move it to mmu/setup.c and make it > non-static so that it can be used outside. > > Signed-off-by: Carlo Nonato > --- > v10: > - no changes > v9: > - no changes > v8: > - patch adapted to new changes to consider_modules() > v7: > - moved consider_modules() to arm/mmu/setup.c > v6: > - new patch > --- > xen/arch/arm/arm32/mmu/mm.c | 95 +------------------------------ > xen/arch/arm/include/asm/setup.h | 3 + > xen/arch/arm/mmu/setup.c | 97 ++++++++++++++++++++++++++++++++ > 3 files changed, 101 insertions(+), 94 deletions(-) > > diff --git a/xen/arch/arm/arm32/mmu/mm.c b/xen/arch/arm/arm32/mmu/mm.c > index 063611412b..c5fcd19291 100644 > --- a/xen/arch/arm/arm32/mmu/mm.c > +++ b/xen/arch/arm/arm32/mmu/mm.c > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include Sort alphabetically. > > static unsigned long opt_xenheap_megabytes __initdata; > integer_param("xenheap_megabytes", opt_xenheap_megabytes); > @@ -31,100 +32,6 @@ static void __init setup_directmap_mappings(unsigned long base_mfn, > directmap_virt_end = XENHEAP_VIRT_START + nr_mfns * PAGE_SIZE; > } > > -/* > - * Returns the end address of the highest region in the range s..e > - * with required size and alignment that does not conflict with the > - * modules from first_mod to nr_modules. > - * > - * For non-recursive callers first_mod should normally be 0 (all > - * modules and Xen itself) or 1 (all modules but not Xen). > - */ > -static paddr_t __init consider_modules(paddr_t s, paddr_t e, > - uint32_t size, paddr_t align, > - int first_mod) > -{ > - const struct membanks *reserved_mem = bootinfo_get_reserved_mem(); > -#ifdef CONFIG_STATIC_SHM > - const struct membanks *shmem = bootinfo_get_shmem(); > -#endif > - const struct bootmodules *mi = &bootinfo.modules; > - int i; > - int nr; > - > - s = (s+align-1) & ~(align-1); > - e = e & ~(align-1); > - > - if ( s > e || e - s < size ) > - return 0; > - > - /* First check the boot modules */ > - for ( i = first_mod; i < mi->nr_mods; i++ ) > - { > - paddr_t mod_s = mi->module[i].start; > - paddr_t mod_e = mod_s + mi->module[i].size; > - > - if ( s < mod_e && mod_s < e ) > - { > - mod_e = consider_modules(mod_e, e, size, align, i+1); > - if ( mod_e ) > - return mod_e; > - > - return consider_modules(s, mod_s, size, align, i+1); > - } > - } > - > - /* > - * i is the current bootmodule we are evaluating, across all > - * possible kinds of bootmodules. > - * > - * When retrieving the corresponding reserved-memory addresses, we > - * need to index the reserved_mem bank starting from 0, and only counting > - * the reserved-memory modules. Hence, we need to use i - nr. > - */ > - nr = mi->nr_mods; > - for ( ; i - nr < reserved_mem->nr_banks; i++ ) > - { > - paddr_t r_s = reserved_mem->bank[i - nr].start; > - paddr_t r_e = r_s + reserved_mem->bank[i - nr].size; > - > - if ( s < r_e && r_s < e ) > - { > - r_e = consider_modules(r_e, e, size, align, i + 1); > - if ( r_e ) > - return r_e; > - > - return consider_modules(s, r_s, size, align, i + 1); > - } > - } > - > -#ifdef CONFIG_STATIC_SHM > - nr += reserved_mem->nr_banks; > - for ( ; i - nr < shmem->nr_banks; i++ ) > - { > - paddr_t r_s, r_e; > - > - r_s = shmem->bank[i - nr].start; > - > - /* Shared memory banks can contain INVALID_PADDR as start */ > - if ( INVALID_PADDR == r_s ) > - continue; > - > - r_e = r_s + shmem->bank[i - nr].size; > - > - if ( s < r_e && r_s < e ) > - { > - r_e = consider_modules(r_e, e, size, align, i + 1); > - if ( r_e ) > - return r_e; > - > - return consider_modules(s, r_s, size, align, i + 1); > - } > - } > -#endif > - > - return e; > -} > - > /* > * Find a contiguous region that fits in the static heap region with > * required size and alignment, and return the end address of the region > diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h > index 64c227d171..0c560d141f 100644 > --- a/xen/arch/arm/include/asm/setup.h > +++ b/xen/arch/arm/include/asm/setup.h > @@ -89,6 +89,9 @@ struct init_info > unsigned int cpuid; > }; > > +paddr_t consider_modules(paddr_t s, paddr_t e, uint32_t size, paddr_t align, > + int first_mod); > + > #endif > /* > * Local variables: > diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c > index 9664e85ee6..1cf62390e3 100644 > --- a/xen/arch/arm/mmu/setup.c > +++ b/xen/arch/arm/mmu/setup.c > @@ -6,7 +6,10 @@ > */ > > #include > +#include What's in lib.h that consider_modules() requires? > #include > +#include Why? AFAICS, this header defines fdt_get_mem_rsv_paddr() which is not used in this file. > +#include Why? There's nothing LLC related here at this point. With the header inclusions sorted out: Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Mon Dec 02 09:09:53 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 09:09:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846392.1261564 (Exim 4.92) (envelope-from ) id 1tI2R7-0000W3-QD; Mon, 02 Dec 2024 09:09:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846392.1261564; Mon, 02 Dec 2024 09:09: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 1tI2R7-0000Vw-NS; Mon, 02 Dec 2024 09:09:45 +0000 Received: by outflank-mailman (input) for mailman id 846392; Mon, 02 Dec 2024 09:09: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 1tI2R6-0000Vq-BL for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 09:09:44 +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 298b7d86-b08d-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 10:09:40 +0100 (CET) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-5d0bde80b4bso3386461a12.2 for ; Mon, 02 Dec 2024 01:09:40 -0800 (PST) Received: from [192.168.219.191] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5999734ccsm484474466b.204.2024.12.02.01.09.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 01:09: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: 298b7d86-b08d-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo1MzEiLCJoZWxvIjoibWFpbC1lZDEteDUzMS5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjI5OGI3ZDg2LWIwOGQtMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTMwNTgwLjczMTE2NCwic2VuZGVyIjoib2xla3NpaS5rdXJvY2hrb0BnbWFpbC5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733130580; x=1733735380; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:date:cc:to:from :subject:message-id:from:to:cc:subject:date:message-id:reply-to; bh=K0LcNt8SeuLBMBvyvO/3O96yWkcgQXYTF/AS5scqEEA=; b=g8Z/K3U+s/t2ijVeY8SqKod3n2NrVGPqcG2IF6/yqDCqSq1vdUKV3yau6xxaJjfDCA ulsZX9isSOqPl9wmfElAxnhajDf86A5pR/u96DmPh2IKu6JiazsWl6fFmxFoGkRVzrW3 mdU3xNV9w7+17h3ggQyaDV8um67RU/rsezLrP3ce28AazgwMO3cJ8rwuCD4riRxKtLVe Rum1IJ2Y8oJFU2fXHmJVc2+tUEKFlzkcZuePiFizLgOTnrPjIzr0u2xNAfrZCIk8w2Rm ns98d+RjmNzasio7HrRatV3vAaUQh+y3cqiOiXanLcA1uaMjqWPmwTHvTGzIPrTfXErc DkUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733130580; x=1733735380; h=mime-version:user-agent:content-transfer-encoding:date:cc:to:from :subject:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=K0LcNt8SeuLBMBvyvO/3O96yWkcgQXYTF/AS5scqEEA=; b=f9MYnQVKzZ7aeoPWEVeQMgDo641QyipB8k3dz6gOcvMFWRy5Cb9y61E2abY4GIVUCU jre5UNDS6EpVSilYbVWxB5Z5xnRbptP83WmeSZUJiiRoLEntvw/0xlIXdEkedHeqXsWC Ygb/37fLB1IlrGKk9x2ypR2uJVG3Yxjms3otXO36xF4lIaAlAVwH6KrU0Gfnku4YYzVr P2ZNn0XqJ+r1dU6kFWhEa2Wv9t5EzsUetO738ZuUXrhA37eyZYOos7OcubRqFrwBSxfy +RD1sv1B/FCqh4p8YD7qHbHT/APGEvUlzOiof7WewWWzo8Jb0PgF09/xsOMPj1CJI26z J8UA== X-Gm-Message-State: AOJu0YyprD06rPW+RemCM+D40Qsjiyx3jky4SvoTybhlDFy3hecQfj9e 94qHdaGLmU+jWCleaGHuKur57fNWMntgMEm0c1dAaCLfytJfLTLz78mqRA== X-Gm-Gg: ASbGncszp58lRkd6Ct3IM5n7al7dPMwXLiF8RS0MeApLOGep+yO3vz08HjV7LHyJxeM 8L5DlW0IXUyH/YXKLbFnNahgTym2H2h/M/YgjHjfNrU5dD0JkE79n+7Y35qA9LL9/q/jrXr79yS tN7O7F1Aw0YsvJjYTbT9JRSYePGZsevkXLa0O3f0+F0NnLEGaw2DrnMHSmLgXtUab5I+3GxHl0w gBJt+9Ez4oDDT+B65c7ZJR/yfkW4rlkNR8jkPQHFNHscT45/u60bX2M1bt89+s= X-Google-Smtp-Source: AGHT+IGHlEUcn8Jzy9vnJx9f03wmAYCNxrRani5Sp1IUD7XRRO77Q+Q3RgvoauMhe7jfXiRBwMzNbg== X-Received: by 2002:a17:906:b392:b0:a9a:f82:7712 with SMTP id a640c23a62f3a-aa5810664dfmr1849803066b.52.1733130579679; Mon, 02 Dec 2024 01:09:39 -0800 (PST) Message-ID: Subject: Feature freeze date for Xen 4.20 is Fri Dec 20, 2024 From: oleksii.kurochko@gmail.com To: Xen-devel Cc: Community Manager , "committers @ xenproject . org" Date: Mon, 02 Dec 2024 10:09:38 +0100 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 (3.54.1-1.fc41app1) MIME-Version: 1.0 Hello everyone, The feature freeze date for Xen 4.20 is December 20, 2024. Patches adding new features must be committed by this date. Straightforward bug fixes may continue to be accepted by maintainers beyond this point. If you would like your features included in this release, please ensure they are committed by the deadline. Thank you in advance, and have a great week! Best regards, Oleksii From xen-devel-bounces@lists.xenproject.org Mon Dec 02 09:18:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 09:18:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846405.1261573 (Exim 4.92) (envelope-from ) id 1tI2Za-0002Of-K1; Mon, 02 Dec 2024 09:18:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846405.1261573; Mon, 02 Dec 2024 09:18: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 1tI2Za-0002OY-HW; Mon, 02 Dec 2024 09:18:30 +0000 Received: by outflank-mailman (input) for mailman id 846405; Mon, 02 Dec 2024 09:18: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 1tI2ZZ-0002OS-GX for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 09:18:29 +0000 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [2a00:1450:4864:20::536]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 62f6d26e-b08e-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 10:18:26 +0100 (CET) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-5d0bde80b4bso3394805a12.2 for ; Mon, 02 Dec 2024 01:18: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 a640c23a62f3a-aa59997354bsm485983066b.199.2024.12.02.01.18.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 01:18: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: 62f6d26e-b08e-11ef-a0d2-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo1MzYiLCJoZWxvIjoibWFpbC1lZDEteDUzNi5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjYyZjZkMjZlLWIwOGUtMTFlZi1hMGQyLThiZTBkYWMzMDJiMCIsInRzIjoxNzMzMTMxMTA2LjU0NDIzOSwic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733131106; x=1733735906; 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=CTMYv9d3cfWh0HEUPIB/Gr79MfSWy56vdEWuAXD2450=; b=Xfdu54RIJ2tiQHik+k80onf7V4doj/tOSZdCkce02aadlh/N0fN3pK4ejtfEST9IUm cI3jTBI1l9JY1bzFC+513k6hcywSebyoyXpoDjQZdroguVxkIxwPE2zt1T7kqBo8YI3E fJkJkwz1eovRsVRcc2ruWFYexZX8nqtI/7Y/USdwvIE/SpSs8Vd+jtSzvzOtwTNWxHgX eJVp41/ApTS2fa6u+vad1p4c/PsIAQXYQmKNLjmg7ISOxAKtq/y5keN8bDLf0e+XA3h/ 286MHI9soaMVodERxdikS+zEieXCtnTtZLtsDDzhnYGcGyVzQzqNa4QwlY0VRxyDwVff /TaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733131106; x=1733735906; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=CTMYv9d3cfWh0HEUPIB/Gr79MfSWy56vdEWuAXD2450=; b=rk2LtYY2DKhYpAfKt0/root3V+bzExLeBufTr1fda88mFxEzwEpP6udEuhkrm2B4AD eXHweg5nVZCmSK3PME4n7CZacNoKybD4NFdxjrDl/AgKq/bi7oLU1YNHvXQx83C0BSrS xdfZLxW/+RhHLy6FJn2i/PwUmL/a2aF6Sp3d8QMDGu55/xtuPoc4QCmwl7u0zIiI3UHe sdK8pTe5EUOYK+R/drPyW2X2v3Ov2tVTwVICvuGGk+zSyxKEpyeJRWy7Y6IkClC2oTIE 6PgLUQL1FQGE1TWAcYGFIIVL/Rn/l2fLPQzyPf8CRzvi3h1tsgoi/GHbM6cFHrq21NP3 DWAQ== X-Forwarded-Encrypted: i=1; AJvYcCXiyYNCHT2CE0g+zL2f+GgmD99Eo5w7326jR7WnKKw8pTnIgg3U3ItvjyBiZYKBPs1GhsgPbOBAZsg=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy9tFBf02lcb1WSFVguGOYiBHyXVQtZ6lkZtbjmHXplz4BBMxRx R+rA0KNCNDf+ojivc5A5pX3RDdKCzP9XytwjWb59E7Yqum5XrZCE6p5+ipIMAg== X-Gm-Gg: ASbGncsKVKtYZ1IXAWTkkMta0xHIjntKsogQqfsOmqDGoRPEpNOh/PkSmdZo4NENVYz 5v0hM2XDp+dvYnLAoCtJzj6Rp52O4BbtaBuGwPuQgACY4gR4dRq9HLxDtTUSWRFcmJtYfvGYnbt 5KCFe5MhoVKkH0hqBNNmUW7AtkR/eWxBUbqcY5N1gLtSzTI5kG9uIjpEdTR4bPSJ0ISqYr2L6Lf 1GRVxAU1CucRrausJlTDa+rXcW39P9Z7VZPCPbVwMpbifqTU6jjptYxQUkhNF0ldUXK285Xne96 h2u1Sx44d0KSaNXxDaXkKQCiwZ4QmMGqXgM= X-Google-Smtp-Source: AGHT+IGdwjydmASO6XyecgOzDtfEZv+XzVTtvZifyY2weKVOs6/99qmciU7P+Hwgb2R748e0jAkXrw== X-Received: by 2002:a17:907:7852:b0:aa5:2edf:2795 with SMTP id a640c23a62f3a-aa580f1b90emr1981589166b.20.1733131106349; Mon, 02 Dec 2024 01:18:26 -0800 (PST) Message-ID: Date: Mon, 2 Dec 2024 10:18:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 10/10] tools/x86: Synthesise domain topologies To: Alejandro Vallejo Cc: Anthony PERARD , Juergen Gross , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241021154600.11745-1-alejandro.vallejo@cloud.com> <20241021154600.11745-11-alejandro.vallejo@cloud.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: <20241021154600.11745-11-alejandro.vallejo@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 21.10.2024 17:46, Alejandro Vallejo wrote: > Expose sensible topologies in leaf 0xb. At the moment it synthesises > non-HT systems, in line with the previous code intent. > > Leaf 0xb in the host policy is no longer zapped and the guest {max,def} > policies have their topology leaves zapped instead. The intent is for > toolstack to populate them. There's no current use for the topology > information in the host policy, but it makes no harm. How does this (and hence ... > @@ -619,6 +616,9 @@ static void __init calculate_pv_max_policy(void) > recalculate_xstate(p); > > p->extd.raw[0xa] = EMPTY_LEAF; /* No SVM for PV guests. */ > + > + /* Wipe host topology. Populated by toolstack */ > + memset(p->topo.raw, 0, sizeof(p->topo.raw)); > } > > static void __init calculate_pv_def_policy(void) > @@ -785,6 +785,9 @@ static void __init calculate_hvm_max_policy(void) > > /* It's always possible to emulate CPUID faulting for HVM guests */ > p->platform_info.cpuid_faulting = true; > + > + /* Wipe host topology. Populated by toolstack */ > + memset(p->topo.raw, 0, sizeof(p->topo.raw)); > } ... these, at least comment-wise) fit with Dom0 also needing some data there? Also nit: Multi-sentence comments want full stops after every sentence. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 09:22:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 09:22:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846414.1261584 (Exim 4.92) (envelope-from ) id 1tI2dY-0004AE-44; Mon, 02 Dec 2024 09:22:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846414.1261584; Mon, 02 Dec 2024 09:22:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tI2dY-0004A7-15; Mon, 02 Dec 2024 09:22:36 +0000 Received: by outflank-mailman (input) for mailman id 846414; Mon, 02 Dec 2024 09:22: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 1tI2dX-0004A1-IF for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 09:22:35 +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 f58d6c2e-b08e-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 10:22: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 C80C5211F1; Mon, 2 Dec 2024 09:22:31 +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 911FB139C2; Mon, 2 Dec 2024 09:22:31 +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 RHN4IVd8TWdHOgAAD6G6ig (envelope-from ); Mon, 02 Dec 2024 09:22: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: f58d6c2e-b08e-11ef-a0d2-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjE5NS4xMzUuMjIzLjEzMCIsImhlbG8iOiJzbXRwLW91dDEuc3VzZS5kZSJ9 X-Custom-Transaction: eyJpZCI6ImY1OGQ2YzJlLWIwOGUtMTFlZi1hMGQyLThiZTBkYWMzMDJiMCIsInRzIjoxNzMzMTMxMzUyLjY0MzUyMiwic2VuZGVyIjoiamdyb3NzQHN1c2UuY29tIiwicmVjaXBpZW50IjoieGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnIn0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733131351; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=qpiY/YjV5AcAYFaVLok5p+W5lfMC8aUHhfe1uc41ffU=; b=TOysMNkCBAN7rOQN7WNtY+Wfmu8OyrzuFMuQWim9uE+XFyRVF0lAmVG7vP/zI2PILoP4lX tzcKVdfIF6NENP+zN8CF7v4p8EPf121AzEGK/PkHv+qcbIc21hdvvPAES3+lpvs0rT7OK8 uIT06x0n4tdBZDXhuSfI6bhzraZYMpY= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733131351; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=qpiY/YjV5AcAYFaVLok5p+W5lfMC8aUHhfe1uc41ffU=; b=TOysMNkCBAN7rOQN7WNtY+Wfmu8OyrzuFMuQWim9uE+XFyRVF0lAmVG7vP/zI2PILoP4lX tzcKVdfIF6NENP+zN8CF7v4p8EPf121AzEGK/PkHv+qcbIc21hdvvPAES3+lpvs0rT7OK8 uIT06x0n4tdBZDXhuSfI6bhzraZYMpY= Message-ID: Date: Mon, 2 Dec 2024 10:22:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: pcpu: remove unnecessary __ref annotation To: =?UTF-8?Q?Sergio_Migu=C3=A9ns_Iglesias?= , archjgross@suse.com Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org References: <20241202085910.5539-1-sergio@lony.xyz> 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: <20241202085910.5539-1-sergio@lony.xyz> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------06s0E0OvlCP0jdUwYeEJjsag" X-Spam-Score: -6.20 X-Spamd-Result: default: False [-6.20 / 50.00]; BAYES_HAM(-3.00)[99.99%]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_BASE64_TEXT(0.10)[]; MIME_UNKNOWN(0.10)[application/pgp-keys]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[epam.com:email,imap1.dmz-prg2.suse.org:helo,xenproject.org:email,suse.com:mid,suse.com:email,lony.xyz:email]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; HAS_ATTACHMENT(0.00)[] X-Spam-Flag: NO X-Spam-Level: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------06s0E0OvlCP0jdUwYeEJjsag Content-Type: multipart/mixed; boundary="------------OTyEuE50VdINXPgtW04PufLB"; protected-headers="v1" From: Juergen Gross To: =?UTF-8?Q?Sergio_Migu=C3=A9ns_Iglesias?= , archjgross@suse.com Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Message-ID: Subject: Re: [PATCH] xen: pcpu: remove unnecessary __ref annotation References: <20241202085910.5539-1-sergio@lony.xyz> In-Reply-To: <20241202085910.5539-1-sergio@lony.xyz> --------------OTyEuE50VdINXPgtW04PufLB Content-Type: multipart/mixed; boundary="------------r6vxhtX8XDSjal0JDofEYOGH" --------------r6vxhtX8XDSjal0JDofEYOGH Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDIuMTIuMjQgMDk6NTksIFNlcmdpbyBNaWd1w6lucyBJZ2xlc2lhcyB3cm90ZToNCj4g VGhlIF9fcmVmIGFubm90YXRpb24gaGFzIGJlZW4gdGhlcmUgc2luY2UgdGhlIGJlZ2lubmlu ZyBvZiB0aW1lLCBidXQgbm8NCj4gY2FsbHMgdG8gX19pbml0IGZ1bmN0aW9ucyBleGlzdCBp bnNpZGUgaXQsIGFuZCB0aGUgY29tcGlsYXRpb24gb2YgdGhlDQo+IFhlbiBkcml2ZXIgZG9l cyBub3Qgb3V0cHV0IGFueSB3YXJuaW5ncyB3aGVuIHJlbW92ZWQuDQoNClRoZSBfX3JlZiBh bm5vdGF0aW9uIHdhcyBhZGRlZCB3aXRoIGNvbW1pdCA2Yzg0NzQwMmUxYzYsIGJ1dCBJIHRo aW5rIHRoZQ0KbmVlZCBmb3IgaXQgd2VudCBhd2F5IHNvbWUgdGltZSBsYXRlci4NCg0KPiAN Cj4gQ2M6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4NCj4gQ2M6IFN0ZWZhbm8g U3RhYmVsbGluaSA8c3N0YWJlbGxpbmlAa2VybmVsLm9yZz4NCj4gQ2M6IE9sZWtzYW5kciBU eXNoY2hlbmtvIDxvbGVrc2FuZHJfdHlzaGNoZW5rb0BlcGFtLmNvbT4NCj4gQ2M6IHhlbi1k ZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZw0KPiBDYzogbGludXgta2VybmVsQHZnZXIua2Vy bmVsLm9yZw0KPiBTaWduZWQtb2ZmLWJ5OiBTZXJnaW8gTWlndcOpbnMgSWdsZXNpYXMgPHNl cmdpb0Bsb255Lnh5ej4NCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0Bz dXNlLmNvbT4NCg0KDQpKdWVyZ2VuDQo= --------------r6vxhtX8XDSjal0JDofEYOGH 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----- --------------r6vxhtX8XDSjal0JDofEYOGH-- --------------OTyEuE50VdINXPgtW04PufLB-- --------------06s0E0OvlCP0jdUwYeEJjsag 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/Ey8FAmdNfFcFAwAAAAAACgkQsN6d1ii/Ey+N dQf/YVvdtS4TcuLxvCii6lwwk9UU7QXRnvqndcRCTpuz1b55JjOoLeA6w4btn6AQlNgGfUpUfnkY 1ZW2FsK9M+qJKWIFQq7cBVfv6rRD2JvGBDjpKxE0g9gWPmpIJ28+WdkIcS4VPsERLTFRPl/MQr32 jctjaqBhlEhgzTh3HCX47bBFiZFpOt4hyVz4V++dnJgdPF/TcDZEhztHrd84unlt7QEXUQlU9GDu ZcaG/UCZ063JajcR/1Lo7PbFXPei2FWuRANRI5p9aioK9zc15u6xVz7MZf+UXcY8ic1NGUyNfgM5 /egsVxgNLDjUNv1oDT5HbwdMPSdxfz0dvHsxZFsTkQ== =xc4K -----END PGP SIGNATURE----- --------------06s0E0OvlCP0jdUwYeEJjsag-- From xen-devel-bounces@lists.xenproject.org Mon Dec 02 09:28:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 09:28:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846423.1261594 (Exim 4.92) (envelope-from ) id 1tI2im-0004l9-MQ; Mon, 02 Dec 2024 09:28:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846423.1261594; Mon, 02 Dec 2024 09:28:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tI2im-0004l2-JZ; Mon, 02 Dec 2024 09:28:00 +0000 Received: by outflank-mailman (input) for mailman id 846423; Mon, 02 Dec 2024 09:27:59 +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 1tI2il-0004kw-Ap for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 09:27:59 +0000 Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [2a00:1450:4864:20::22b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b6141ff2-b08f-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 10:27:55 +0100 (CET) Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-2ffdbc0c103so53326171fa.3 for ; Mon, 02 Dec 2024 01:27:55 -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 a640c23a62f3a-aa5998e64a8sm485083066b.130.2024.12.02.01.27.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 01:27: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: b6141ff2-b08f-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjoyMmIiLCJoZWxvIjoibWFpbC1sajEteDIyYi5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6ImI2MTQxZmYyLWIwOGYtMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTMxNjc1LjQ1MjY0NSwic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733131675; x=1733736475; 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=gBsGkaw40T4YY5XjpuiMoX/ong7PRVrTp6oRrXduUTI=; b=IcgWd/YrW0vqkiwUHHRRmEPj5vWwdvdjiTD48/V4DmaAeZI4AC3DXYTnhXGps0Dkv1 E6BfjXOz+jms1Mt0bmMA9SOzUYDUKTc5LV/B+RStVagWFnfdMfgyDfbu67tTygg8sjtt q3X9Iw+51zHge/900syFmFDi3LjRKsyOHx4sxrbk/fv7YzZJOAwCC22eHEJT3ygtJD9c R9KaJuikzEJ7bsb8SDJoyOAdiLMVZDrQBeTALmBy9RwZrKKV+z4b+IVHGBPFsT4XEy+o xMLEHx2axaMSeWeZmcl59lhm46tOnNTOL82alOX5FAXmjuyytMSR2ZGKsu7tJBiTRGzX WKhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733131675; x=1733736475; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gBsGkaw40T4YY5XjpuiMoX/ong7PRVrTp6oRrXduUTI=; b=VEjRBwWIFLrH7/DYUgGxgqLnOOTYO9E07pJP9rFq0wJsQ0VIrUGow2rC+3dePphsG1 U7IPTmzpZFwBh6wh05F/B8PGdKF+ekH/3ulwRQvunIC46oxZ9M+pueMlGzTswafwXC/+ nEERLeXh7OzEv/DTMvBcALNtoWsvHYIXLSz5xitY6c8/f2sSJib0E+CdLe1BIk5Qa/0w lzvPp4D+XxpnY9Qtk/1K5mFO1GinWwPpbzMQf8nW/PRt1W5INIll4zbDSIPc3Mawdtaj u/HXW+lkPL8znhQJOZjXSWMvFojG0aJEnY7uXOVosQSO4sd9zL0oXGYMq5+BiStQ7tds 4m+A== X-Forwarded-Encrypted: i=1; AJvYcCVQICGFKSqKAwwMVOqS7wumrLoFvb/kY97OeIh2UQKTyPhTEmKS6q3a5LLzltB9SxXrPDvmwMxig44=@lists.xenproject.org X-Gm-Message-State: AOJu0YwhlhnxNjiZOddkmGeek9ukD2VYf4MynWEZh7DJnN6yA9VPNska fLxM60WA9V0xUt+X8+I6jFHrt4aodLQrwgq2qkmfigTC1ULQgLh82b6sIKk1iA== X-Gm-Gg: ASbGncte8Owtn93ZwKE3X9njupZAuQUzMlMRRXYsiOJLjrNxyCuLCkPtpvUBJyxe9Jf jkBIXMctjNVuhIj+7FhcDT+oNXfzsaHhIePO8oRygjXnUncnz3H5yzjDEZrTTVcLTFIH3C4uFKz k6Zbb730Y3oWczv926eFATqDOF2CdYLYn/Z8V1LZVdkJyl+5tyS2Dg3lRipKliNB+C7pP1u5sNk sQg8UOJ10I59kQ28MfBP2Fl/kwTZc0q0+KIBfUEHfZUj59mxSg7vA+nOosfx+l1AywESdO031un kbplCLKP/OsdIX7+hgIiiiIkvHtr+X4jkXM= X-Google-Smtp-Source: AGHT+IHhsy9Ofx7px4webTuziN26cw2W0bcMEx+CkXKmWzD4z+MsjScWLRMGHYcQpDpRhbi+iDqeOg== X-Received: by 2002:a05:651c:b24:b0:2ff:c4b2:496b with SMTP id 38308e7fff4ca-2ffd5fcc1c9mr152392771fa.7.1733131674871; Mon, 02 Dec 2024 01:27:54 -0800 (PST) Message-ID: <11a0bc21-4e48-4dac-858a-a1dda512b99f@suse.com> Date: Mon, 2 Dec 2024 10:27:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 03/10] xen/x86: Add supporting code for uploading LAPIC contexts during domain create To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241021154600.11745-1-alejandro.vallejo@cloud.com> <20241021154600.11745-4-alejandro.vallejo@cloud.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: <20241021154600.11745-4-alejandro.vallejo@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 21.10.2024 17:45, Alejandro Vallejo wrote: > A later patch will upload LAPIC contexts as part of domain creation. In > order for it not to encounter a problem where the architectural state > does not reflect the APIC ID in the hidden state, this patch ensures > updates to the hidden state trigger an update in the architectural > registers so the APIC ID in both is consistent. > > Signed-off-by: Alejandro Vallejo Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Dec 02 09:36:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 09:36:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846439.1261604 (Exim 4.92) (envelope-from ) id 1tI2qg-0006hC-Ko; Mon, 02 Dec 2024 09:36:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846439.1261604; Mon, 02 Dec 2024 09: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 1tI2qg-0006h5-H0; Mon, 02 Dec 2024 09:36:10 +0000 Received: by outflank-mailman (input) for mailman id 846439; Mon, 02 Dec 2024 09:36: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 1tI2qf-0006gv-At for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 09:36:09 +0000 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [2a00:1450:4864:20::634]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d864f676-b090-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 10:36:02 +0100 (CET) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-aa51b8c5f4dso591857866b.2 for ; Mon, 02 Dec 2024 01:36:02 -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 a640c23a62f3a-aa599953c81sm490983466b.184.2024.12.02.01.36.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 01:36: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: d864f676-b090-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo2MzQiLCJoZWxvIjoibWFpbC1lajEteDYzNC5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6ImQ4NjRmNjc2LWIwOTAtMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTMyMTYyLjU3NjI3NSwic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733132162; x=1733736962; 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=ncVPVMFQselSNH82zaKBtknHPQnp5qdgaOeaIudmg2c=; b=BmPu7z82HPknDZvHy97v947tjHrpX4m0sWolvSx00uhBj83g4egXbIPw2yXm2rsAUk msuSoTG2WBpqL2Sgzu/Nz1IJLcarPApAQ4I87nbPokoohZlLPI7CJdh54ujm7n2oUKWn nsAwefzMIW72rImu2wwkRt0xARexBKFsgNP7OjaW5eD89nA8JIE6hcUO5BJ3wDa1WcUb kuKbd+E5vNxjRX8jkHKmQnBbBphUN3PgtJXrMVbu7wMQ8CHdg3XMcGqJfUrivh6jCrXB 8B3CzZIYBrjy8m+cKgwCByT3f7K9uTbr20KLQPmAC+lMfEEto2XCYVnqyMyfqKPz6I2h Gy2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733132162; x=1733736962; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ncVPVMFQselSNH82zaKBtknHPQnp5qdgaOeaIudmg2c=; b=uo2r5UssXQbMvaoq2AdF7yIzbZzo2ufqy1ZjfByX2WelLVT0mobr3BV3LwKWFM8JLU u78ZCyOWKBAYYYGWGGwgkt73/3ycYCqXI6DbhNt4FBHLkaFyhqB/P6KLXhedi6LQiDcm Iaz0o19tsjmLdre6Y/Tc1Ssr3hiZNqTu9FUnOBGlLa6QXEO3kO3DQV4tr0SuDNslXD1i NGJsX3WOdTmuPxL8ZiK7fQtv18mMzoS+pkT363LGUS4+Gfv7RLO89wXmA3DHLZLPeEzz O78bGPFUZrgCFKUY4TRx12V4eDAjCFhYFR/xx0VrV5euy4et6TMe26vAmqgcAkVN5cWt Xwpw== X-Forwarded-Encrypted: i=1; AJvYcCV/ZmUJckhWVIAVmEhAoRd43N/6awA/2DFPdoM6k58UHkVnihAf7QRGJ6VHgl8uaCf1g53VTc7EZNM=@lists.xenproject.org X-Gm-Message-State: AOJu0YzdP5HkWHPZ7q8qArbYQQJVeClTKFd+GrUXVLGT3bT6mzLOdUPs p8Hl7o0PB73jGDyVeITde1KmABOWGjOLHNrkQrmAZS1Pa/sJoUCG3/krwyNaLQ== X-Gm-Gg: ASbGncvM6FYVYjBlv59u2oVeMqVcQEgQL+LfyNLc1fTgpCBRmw0+MkVKsTuubOg1E9z Ww31pQDiVI/4xdCJKNsUq8CLuLmQc9hARxwLk4nUuTR3/eXRhdcnmbG/rcbPX2MpMXhiKPjwunM YseeDJzMczpkfz+8BLu4IOPOnGh33ChUHTtH3voEO4YvCI50nFQL6ABsRHzcbkisntN/K3bboMv YMQyczTZYGI3fD925yUFo19zzY53YAtw2htxdY3+Sd/G45opRbu8/BGcsB7T4H5qB6Xh0PKLU7n 7FphVAZbHju6rcahloAI/bqVuZqgwpdLWm4= X-Google-Smtp-Source: AGHT+IEiPWT8Q61tvpFGosJkm2vcUyjrwxJ5nbL4xZDoImDYb5tV0zVyhSuiBj/DYRIgG2BseUGeAg== X-Received: by 2002:a17:906:318d:b0:aa4:9ab1:1982 with SMTP id a640c23a62f3a-aa580ecfcf0mr1979870166b.4.1733132161944; Mon, 02 Dec 2024 01:36:01 -0800 (PST) Message-ID: <31a61fa0-0e3c-4a81-9004-593608b2199a@suse.com> Date: Mon, 2 Dec 2024 10:36:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 04/10] tools/hvmloader: Retrieve (x2)APIC IDs from the APs themselves To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , xen-devel@lists.xenproject.org References: <20241021154600.11745-1-alejandro.vallejo@cloud.com> <20241021154600.11745-5-alejandro.vallejo@cloud.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: <20241021154600.11745-5-alejandro.vallejo@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 21.10.2024 17:45, Alejandro Vallejo wrote: > --- a/tools/firmware/hvmloader/hvmloader.c > +++ b/tools/firmware/hvmloader/hvmloader.c > @@ -224,7 +224,7 @@ static void apic_setup(void) > > /* 8259A ExtInts are delivered through IOAPIC pin 0 (Virtual Wire Mode). */ > ioapic_write(0x10, APIC_DM_EXTINT); > - ioapic_write(0x11, SET_APIC_ID(LAPIC_ID(0))); > + ioapic_write(0x11, SET_APIC_ID(cpu_to_x2apicid[0])); > } In uses like this or ... > --- a/tools/firmware/hvmloader/mp_tables.c > +++ b/tools/firmware/hvmloader/mp_tables.c > @@ -198,8 +198,10 @@ static void fill_mp_config_table(struct mp_config_table *mpct, int length) > /* fills in an MP processor entry for VCPU 'vcpu_id' */ > static void fill_mp_proc_entry(struct mp_proc_entry *mppe, int vcpu_id) > { > + ASSERT(cpu_to_x2apicid[vcpu_id] < 0xFF ); > + > mppe->type = ENTRY_TYPE_PROCESSOR; > - mppe->lapic_id = LAPIC_ID(vcpu_id); > + mppe->lapic_id = cpu_to_x2apicid[vcpu_id]; ... this one (and also in acpi_lapic_id()), I consider the "x2" in the name actively confusing, despite ... > --- a/tools/firmware/hvmloader/smp.c > +++ b/tools/firmware/hvmloader/smp.c > @@ -29,7 +29,37 @@ > > #include > > -static int ap_callin; > +/** > + * Lookup table of (x2)APIC IDs. > + * > + * Each entry is populated its respective CPU as they come online. This is required > + * for generating the MADT with minimal assumptions about ID relationships. > + * > + * While the name makes "x2" explicit, these may actually be xAPIC IDs if no > + * x2APIC is present. "x2" merely highlights that each entry is 32 bits wide. > + */ > +uint32_t cpu_to_x2apicid[HVM_MAX_VCPUS]; ... the commentary here. > +/** Tristate about x2apic being supported. -1=unknown */ > +static int has_x2apic = -1; Why is this a tristate? Prior to the variable having been set, ... > +static uint32_t read_apic_id(void) > +{ > + uint32_t apic_id; > + > + if ( has_x2apic ) > + cpuid(0xb, NULL, NULL, NULL, &apic_id); ... this is bogus anyway. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 09:40:46 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 09:40:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846455.1261618 (Exim 4.92) (envelope-from ) id 1tI2v8-0008Tj-5S; Mon, 02 Dec 2024 09:40:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846455.1261618; Mon, 02 Dec 2024 09:40:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tI2v8-0008Tc-2g; Mon, 02 Dec 2024 09:40:46 +0000 Received: by outflank-mailman (input) for mailman id 846455; Mon, 02 Dec 2024 09:40: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 1tI2v6-0008TV-Kn for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 09:40:44 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7e68b748-b091-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 10:40:41 +0100 (CET) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-aa535eed875so640280066b.3 for ; Mon, 02 Dec 2024 01:40: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 a640c23a62f3a-aa5998e63b8sm492733666b.123.2024.12.02.01.40.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 01:40: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: 7e68b748-b091-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo2MzAiLCJoZWxvIjoibWFpbC1lajEteDYzMC5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjdlNjhiNzQ4LWIwOTEtMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTMyNDQxLjA5MzI5Miwic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733132440; x=1733737240; 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=vw2wXZocv82RCPx217CPnuB34VXjsc0CsGzUZrn5t5Y=; b=Pj/ftNYSnPN+mjYpfdQ2opiHgq7fxTav5iW4JJDezro7n9CWgsawe8oUkT+n8dpCUe LyRwe7aERS80yML6nxc8tyarnWJGe5CAlWj0sXbKgB1QZipAEGnPQAm6K/XPnDPatIqK nT/x51V2O/K3JZ+Z0i0Aa5nW/urwhn1t82r20ezPoIf/IJYngdTUnDhy2KcwFV7fPC3C oezpLjT5kYj9muz7m1/w2xgqx3SOtZ35eR9YH0/Gn6Dup3x+7VkMnzUlFqSgeV2HhYEM mm2OraB+LGJC+6tjo+4EaJgkjFmBKDnboD7OCYBMnKWAmSMqfvwyz0M8JNbwLoGzZa6C 6RKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733132440; x=1733737240; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vw2wXZocv82RCPx217CPnuB34VXjsc0CsGzUZrn5t5Y=; b=Vohmrf67PKYxSjNOpbIGDigwaZxymJSWUqBRNZ5lMxxX5J8t+7wA8UBENE5HiNwtMp h7s7lGy+pl6Too79a75l7HaUBeg5JBhnA664we9WnPdhEagjUOk/ClvdMHFxntC0gBA0 UNHaL5o7Igjw1nbr+c9K5wJKjfmoBe2UbJWtam2H5W6grmPmX8B3lv9JatABwz5afkp5 Z6MavH/ZyofXC/U1N2wb7TcGCezVmqQe80s7lpmgbrkkPk/tRR91l9VfZ+ljNLB2BeEf hYTUdDrT4utQc88FkNRZ7VqUHKOTete/Fi9UNz7X5kRaBvii6tSrBIfWutAgVYIbp9K7 jDkA== X-Forwarded-Encrypted: i=1; AJvYcCXqkA00xqt5wq/K677ss6Y1kFLcbP/dTyyifRi886cDde3jZed7ddJ77RmtjNzbPsiQGRUA6Hhmfyg=@lists.xenproject.org X-Gm-Message-State: AOJu0YxDsA4zW1Yh6CJtpxZNNo7M5Kc8jDoQfDrZBeIaL0fzaKQaKV6Y jJCOHvsJDjdXMPBxJeW8xU8YzpCB2UPi2hGqh8eKD/0NlYYO5mf3yhdJB55DhA== X-Gm-Gg: ASbGncvmfwaTla9/Mo25PmqF3nPdblBqXRs9ibNCFMOd4cUInsWmxNFEkp54OiR9mic 2DUrLQslMWfdeywCnHHJ6wAwch7khDb0ty6QBrJH/A40glHYc64KednJFZGZXZcX6sN8MSh1ZoH eLwJbSIyR3ANnqv9kIXzZEK+6abFNeuihCl4k+kb2vupncH261ddbczaZnNVPMgUgQxcUI3G3lz KmVnY6aliIGyiQmFhE46lcJ6BEnwd9CmoVNNPTj7UiFahHsFtMnKqYA/mfv3l2NrAu7aHrcTfZX nk54F/U+uQZ7bEmMl8vamUIEttbr1vTHHDU= X-Google-Smtp-Source: AGHT+IHhOQ+l7Wal0CzZCSp2o+Fwge5D5zZ1E1U1j1IdO9o2Z9YW4MzX++V5tAxOULQsKyK/yfUSzA== X-Received: by 2002:a17:907:2d25:b0:aa5:274b:60eb with SMTP id a640c23a62f3a-aa581059879mr2310470766b.44.1733132440563; Mon, 02 Dec 2024 01:40:40 -0800 (PST) Message-ID: <6e19dd6c-c270-4faa-b739-1f024d958f0b@suse.com> Date: Mon, 2 Dec 2024 10:40:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 05/10] tools/libacpi: Use LUT of APIC IDs rather than function pointer To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Juergen Gross , xen-devel@lists.xenproject.org References: <20241021154600.11745-1-alejandro.vallejo@cloud.com> <20241021154600.11745-6-alejandro.vallejo@cloud.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: <20241021154600.11745-6-alejandro.vallejo@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 21.10.2024 17:45, Alejandro Vallejo wrote: > Refactors libacpi so that a single LUT is the authoritative source of > truth for the CPU to APIC ID mappings. This has a know-on effect in > reducing complexity on future patches, as the same LUT can be used for > configuring the APICs and configuring the ACPI tables for PVH. > > Not functional change intended, because the same mappings are preserved. > > Signed-off-by: Alejandro Vallejo > --- > v7: > * NOTE: didn't add assert to libacpi as initially accepted in order to > protect libvirt from an assert failure. If such an assertion can trigger, doesn't that suggest a problem with the corresponding caller? I.e. isn't omitting the assertion merely trading a noisy failure for a silent (and possibly hard to understand) one? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 09:49:16 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 09:49:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846465.1261628 (Exim 4.92) (envelope-from ) id 1tI33G-0000pB-V1; Mon, 02 Dec 2024 09:49:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846465.1261628; Mon, 02 Dec 2024 09:49:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tI33G-0000p4-Rw; Mon, 02 Dec 2024 09:49:10 +0000 Received: by outflank-mailman (input) for mailman id 846465; Mon, 02 Dec 2024 09:49: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 1tI33F-0000oy-CR for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 09:49:09 +0000 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [2a00:1450:4864:20::635]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ab399091-b092-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 10:49:05 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-a9f1c590ecdso682402766b.1 for ; Mon, 02 Dec 2024 01:49: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 a640c23a62f3a-aa5996c195bsm489707066b.1.2024.12.02.01.49.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 01:49: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: ab399091-b092-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo2MzUiLCJoZWxvIjoibWFpbC1lajEteDYzNS5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6ImFiMzk5MDkxLWIwOTItMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTMyOTQ1Ljc3OTU3OSwic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733132945; x=1733737745; 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=2WuL8BGgzlV0OtH+XWvK2eVFhlKFA5J+gVnjKDUTz7M=; b=EpPSY1aLWJu9rNhh76C1txx3KHwuE8uVBqkpzW+QjRvTx3VllfB4T7OZVx4i023CF0 Hx3YNb/9LwwAZXt/PYDxwTi9AqXHGeXzeqdgfFDJB2S6j/iB/DZRVVi+r4iA19wBUg9J E+tzEKv3iw3dU+hTeXZ3+f3HJu/uwIGI+6+hijt6TeDNahS88rcGrYP3WLyeUxlSZ2E4 5cRNF+jGAGOvOq00teyveGFwLTIjJN50aIZk+et/l5CsAPZyTdETvUA1krbXJkDMHXt7 K9+/lB60ipep7RZq4ZS8yh6tjdkC8fhgMN3VcEw/2vfRiutGy24576aT5aqJG2+1a2va R9dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733132945; x=1733737745; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2WuL8BGgzlV0OtH+XWvK2eVFhlKFA5J+gVnjKDUTz7M=; b=GNCyq79peGU95HBPeqAGv95WrUf7Qmw/gtoUSX4Iu988xUI69qIo4UP+gU64Y07oLw Pq424H1nkjOgsFBphOY0CgKwPaNMS1VdsxQQE2qJsWt18WLSm07Pxle5H2IVppkgdcMq 1NHaXtZalvDhMF677rNAido6CwDaCTTNxJXkeEc30XHRaUDS3VzAlPoZKoUZkUs9O/jQ iswx6CBGbxdzQLz/EOwROsz/cczbjizxhCHQmerJ2LVuBXDek/kCxMzvnUPh+yeX/NLN Oi3x3m/UjIfalOBFRCxQpLEgAfy2kq20zfygT2c1OsK9igKMJSOE1IYRfgdQbpVnat79 aw+w== X-Forwarded-Encrypted: i=1; AJvYcCWyAiRoiguT0DQMRnZRDyOlX9p/aTuRqZS0WZIgUl7vJQNe+hJ3SOBeftKFvBNSZoAZlrIRiImekto=@lists.xenproject.org X-Gm-Message-State: AOJu0YymiBIia+K2y93Dr9Pi2bF7lpYLLRzQAgOBcuiAv5AqLsh480GH ddkwFoSSmqh2nz8Yb0VNjj7WK0Lb5DZT90+r/1h75KyehR4TAkqg8DMAhg4XTA== X-Gm-Gg: ASbGncuaKMfTU2qGbmOMoGZ1AmQS7v8EsdQ2OEZNpzxb354X+AotV5Xf8HnrZOb3rIj yKjn8pNuFlf0ega7y6nI4PrWeM0qrYTQPnLrX7sS0c7QLA5qbCdKCLYE7lFGwDZOOO/iQbsYiSt lTooZkFVbO8nju8QaYy5Id5qIkc0AFTZPWv9OgBj4a2q8suASiiXkaBesor6BepigMAnlN3w+1W ZpSMoZyJnBgeQETpIff6s8M20kN+x/UetH0uiLUHD+Evtm9LY+2EEu9vLNiZ74V5EIa0Em6XkjL nKpo09heGjU9mn2RUgOUMqScxNU4bjcXZ/I= X-Google-Smtp-Source: AGHT+IHsXCuH4g/AxQVzKRcDoQNXR5BhPAPXcfYjlftkeFCxsf/6NwqQWcDyiCZ//dQ1LRM9Znq9Fg== X-Received: by 2002:a17:907:7748:b0:aa5:7d7e:7b7b with SMTP id a640c23a62f3a-aa580f1d7e4mr1761104966b.24.1733132945225; Mon, 02 Dec 2024 01:49:05 -0800 (PST) Message-ID: <43ce0519-5717-4d59-922d-10dc2c663747@suse.com> Date: Mon, 2 Dec 2024 10:49:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 03/15] x86/boot: add cmdline to struct boot_domain To: "Daniel P. Smith" Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com, stefano.stabellini@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241123182044.30687-1-dpsmith@apertussolutions.com> <20241123182044.30687-4-dpsmith@apertussolutions.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: <20241123182044.30687-4-dpsmith@apertussolutions.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.11.2024 19:20, Daniel P. Smith wrote: > --- a/xen/arch/x86/hvm/dom0_build.c > +++ b/xen/arch/x86/hvm/dom0_build.c > @@ -644,9 +644,11 @@ static bool __init check_and_adjust_load_address( > } > > static int __init pvh_load_kernel( > - struct domain *d, struct boot_module *image, struct boot_module *initrd, > - paddr_t *entry, paddr_t *start_info_addr) > + struct boot_domain *bd, paddr_t *entry, paddr_t *start_info_addr) > { > + struct domain *d = bd->d; > + struct boot_module *image = bd->kernel; > + struct boot_module *initrd = bd->ramdisk; > void *image_base = bootstrap_map_bm(image); > void *image_start = image_base + image->headroom; > unsigned long image_len = image->size; > @@ -1304,14 +1306,12 @@ static void __hwdom_init pvh_setup_mmcfg(struct domain *d) > int __init dom0_construct_pvh(struct boot_domain *bd) > { > paddr_t entry, start_info; > - struct boot_module *image = bd->kernel; > - struct boot_module *initrd = bd->ramdisk; > struct domain *d = bd->d; > int rc; > > printk(XENLOG_INFO "*** Building a PVH Dom%d ***\n", d->domain_id); > > - if ( image == NULL ) > + if ( bd->kernel == NULL ) > panic("Missing kernel boot module for %pd construction\n", d); > > if ( is_hardware_domain(d) ) > @@ -1351,7 +1351,7 @@ int __init dom0_construct_pvh(struct boot_domain *bd) > return rc; > } > > - rc = pvh_load_kernel(d, image, initrd, &entry, &start_info); > + rc = pvh_load_kernel(bd, &entry, &start_info); > if ( rc ) > { > printk("Failed to load Dom0 kernel\n"); None of this looks command line related - do these changes rather belong into patch 1? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 09:49:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 09:49:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846466.1261638 (Exim 4.92) (envelope-from ) id 1tI33S-000164-6V; Mon, 02 Dec 2024 09:49:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846466.1261638; Mon, 02 Dec 2024 09:49: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 1tI33S-00015x-2m; Mon, 02 Dec 2024 09:49:22 +0000 Received: by outflank-mailman (input) for mailman id 846466; Mon, 02 Dec 2024 09:49: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 1tI33R-00015h-PL for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 09:49:21 +0000 Received: from mail180-27.suw31.mandrillapp.com (mail180-27.suw31.mandrillapp.com [198.2.180.27]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b156f50c-b092-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 10:49:16 +0100 (CET) Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail180-27.suw31.mandrillapp.com (Mailchimp) with ESMTP id 4Y1zWt2mcPz6CQWq6 for ; Mon, 2 Dec 2024 09:49:14 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 5b8a2aa0c92547d784c63cf2f1c94b70; Mon, 02 Dec 2024 09:49: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: b156f50c-b092-11ef-a0d2-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjE5OC4yLjE4MC4yNyIsImhlbG8iOiJtYWlsMTgwLTI3LnN1dzMxLm1hbmRyaWxsYXBwLmNvbSJ9 X-Custom-Transaction: eyJpZCI6ImIxNTZmNTBjLWIwOTItMTFlZi1hMGQyLThiZTBkYWMzMDJiMCIsInRzIjoxNzMzMTMyOTU2Ljk0MDc1MSwic2VuZGVyIjoiYm91bmNlLW1kXzMwNTA0OTYyLjY3NGQ4MjlhLnYxLTViOGEyYWEwYzkyNTQ3ZDc4NGM2M2NmMmYxYzk0YjcwQGJvdW5jZS52YXRlcy50ZWNoIiwicmVjaXBpZW50IjoieGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnIn0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1733132954; x=1733393454; bh=ucqGhHnOiz/ZBpgQgGjtVLuUnH2uZLJRFuH6QWW+l5E=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=mRd1V+VnH1rD/XqyLLcip/Fp0fCzZRVKQP3MJHQFOHVo1xrtQWR9mHUelwO+3ji+W CyB+5JYno3x7W/gyXSSKAtweTcD8cKbfg+85GSpprAEx4coalBi8P/KHl9LkdVf0JZ ptaO5wZC2Psvu0S3uEzCPApX/H+23jbUtW96cM5+JC4A7VNf1DpwCrW1YnJzVxMyhV BsQLabd+AN4CeW55pldKWnkDyzNRZWAGUVF+khv7qabXPlkRQUtazSrJmV6vvGg4g3 PSPoPPTX+3hmI9y5Z5iIyr3RWVkQE3eiL2qQfiIJQRoJmTeZuRa0rLUH7SW5JA7zF9 /A/Vlg55IyVZg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1733132954; x=1733393454; i=teddy.astie@vates.tech; bh=ucqGhHnOiz/ZBpgQgGjtVLuUnH2uZLJRFuH6QWW+l5E=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=A8l/Q1xeAZk2B3wRWBBLp8UAeUsxSg1H6y66f2qvSqlJFuX8Z3n57kFybm4b9yUJ7 3bckRJJB5t0EkeeA07lPkOQTpdvG4YdzPGVv3YU+nMBEpalMQM0jhjN+O0TgaBsAma Jr4EdxR+89XmigYbpztNouGfEhwEsYrcgr2tzR4HPjusKpuxo/bEDx6PXG8WuOVoeu uMXyS4jTesJnT+bQS9THG+tQ6YUMiZcliRFCCRte+NGY1gecoDKoCWw3Vz0wXlXJ07 SuLJ029IJdGlolZ46Tts0iqxycIxr1tpHhnZwppm5Si5c7JPtbaVVcIaZmNkGkDXZc 8Hfdy4vG09cfA== From: "Teddy Astie" Subject: =?utf-8?Q?[XEN=20PATCH=20v2]=20x86/hvm:=20Use=20constants=20for=20x86=20modes?= X-Mailer: git-send-email 2.45.2 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1733132953401 To: xen-devel@lists.xenproject.org Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , =?utf-8?Q?Roger=20Pau=20Monn=C3=A9?= , "Paul Durrant" 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.5b8a2aa0c92547d784c63cf2f1c94b70?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20241202:md Date: Mon, 02 Dec 2024 09:49:14 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit In many places of x86 HVM code, constants integer are used to indicate in what mode is running the CPU (real, vm86, 16-bits, 32-bits, 64-bits). However, these constants are are written directly as integer which hides the actual meaning of these modes. This patch introduces X86_MODE_* macros and replace those occurences with it. Signed-off-by Teddy Astie --- v2: Formatting changes (alignment, ...) Renamed v86 to vm86. (Jan) --- xen/arch/x86/hvm/emulate.c | 18 ++++++++++-------- xen/arch/x86/hvm/hypercall.c | 13 +++++++------ xen/arch/x86/hvm/viridian/viridian.c | 9 +++++---- xen/arch/x86/hvm/vmx/vmx.c | 9 +++++---- xen/arch/x86/hvm/vmx/vvmx.c | 5 +++-- xen/arch/x86/include/asm/hvm/hvm.h | 6 ++++++ 6 files changed, 36 insertions(+), 24 deletions(-) diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c index f2bc6967df..9721fd8d4d 100644 --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -2433,14 +2433,15 @@ static void cf_check hvmemul_put_fpu( switch ( mode ) { - case 8: + case X86_MODE_64BIT: fpu_ctxt->fip.addr = aux->ip; if ( dval ) fpu_ctxt->fdp.addr = aux->dp; fpu_ctxt->x[FPU_WORD_SIZE_OFFSET] = 8; break; - case 4: case 2: + case X86_MODE_32BIT: + case X86_MODE_16BIT: fpu_ctxt->fip.offs = aux->ip; fpu_ctxt->fip.sel = aux->cs; if ( dval ) @@ -2451,7 +2452,8 @@ static void cf_check hvmemul_put_fpu( fpu_ctxt->x[FPU_WORD_SIZE_OFFSET] = mode; break; - case 0: case 1: + case X86_MODE_REAL: + case X86_MODE_VM86: fpu_ctxt->fip.addr = aux->ip | (aux->cs << 4); if ( dval ) fpu_ctxt->fdp.addr = aux->dp | (aux->ds << 4); @@ -2952,11 +2954,11 @@ static const char *guest_x86_mode_to_str(int mode) { switch ( mode ) { - case 0: return "Real"; - case 1: return "v86"; - case 2: return "16bit"; - case 4: return "32bit"; - case 8: return "64bit"; + case X86_MODE_REAL: return "Real"; + case X86_MODE_VM86: return "v86"; + case X86_MODE_16BIT: return "16bit"; + case X86_MODE_32BIT: return "32bit"; + case X86_MODE_64BIT: return "64bit"; default: return "Unknown"; } } diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c index 81883c8d4f..dd5b017fd1 100644 --- a/xen/arch/x86/hvm/hypercall.c +++ b/xen/arch/x86/hvm/hypercall.c @@ -11,6 +11,7 @@ #include #include +#include #include #include #include @@ -112,23 +113,23 @@ int hvm_hypercall(struct cpu_user_regs *regs) switch ( mode ) { - case 8: + case X86_MODE_64BIT: eax = regs->rax; fallthrough; - case 4: - case 2: + case X86_MODE_32BIT: + case X86_MODE_16BIT: if ( currd->arch.monitor.guest_request_userspace_enabled && eax == __HYPERVISOR_hvm_op && - (mode == 8 ? regs->rdi : regs->ebx) == HVMOP_guest_request_vm_event ) + (mode == X86_MODE_64BIT ? regs->rdi : regs->ebx) == HVMOP_guest_request_vm_event ) break; if ( likely(!hvm_get_cpl(curr)) ) break; fallthrough; - default: + case X86_MODE_VM86: regs->rax = -EPERM; return HVM_HCALL_completed; - case 0: + case X86_MODE_REAL: break; } diff --git a/xen/arch/x86/hvm/viridian/viridian.c b/xen/arch/x86/hvm/viridian/viridian.c index 21480d9ee7..0e3b824bf0 100644 --- a/xen/arch/x86/hvm/viridian/viridian.c +++ b/xen/arch/x86/hvm/viridian/viridian.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include @@ -933,13 +934,13 @@ int viridian_hypercall(struct cpu_user_regs *regs) switch ( mode ) { - case 8: + case X86_MODE_64BIT: input.raw = regs->rcx; input_params_gpa = regs->rdx; output_params_gpa = regs->r8; break; - case 4: + case X86_MODE_32BIT: input.raw = (regs->rdx << 32) | regs->eax; input_params_gpa = (regs->rbx << 32) | regs->ecx; output_params_gpa = (regs->rdi << 32) | regs->esi; @@ -1038,11 +1039,11 @@ int viridian_hypercall(struct cpu_user_regs *regs) switch ( mode ) { - case 8: + case X86_MODE_64BIT: regs->rax = output.raw; break; - case 4: + case X86_MODE_32BIT: regs->rdx = output.raw >> 32; regs->rax = (uint32_t)output.raw; break; diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index b6885d0e27..eee1d4b47a 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -886,14 +886,15 @@ int cf_check vmx_guest_x86_mode(struct vcpu *v) unsigned long cs_ar_bytes; if ( unlikely(!(v->arch.hvm.guest_cr[0] & X86_CR0_PE)) ) - return 0; + return X86_MODE_REAL; if ( unlikely(guest_cpu_user_regs()->eflags & X86_EFLAGS_VM) ) - return 1; + return X86_MODE_VM86; __vmread(GUEST_CS_AR_BYTES, &cs_ar_bytes); if ( hvm_long_mode_active(v) && likely(cs_ar_bytes & X86_SEG_AR_CS_LM_ACTIVE) ) - return 8; - return (likely(cs_ar_bytes & X86_SEG_AR_DEF_OP_SIZE) ? 4 : 2); + return X86_MODE_64BIT; + return (likely(cs_ar_bytes & X86_SEG_AR_DEF_OP_SIZE) + ? X86_MODE_32BIT : X86_MODE_16BIT); } static void vmx_save_dr(struct vcpu *v) diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index 78135ca23b..c267b101d1 100644 --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -411,7 +411,7 @@ static int decode_vmx_inst(struct cpu_user_regs *regs, } else { - bool mode_64bit = (vmx_guest_x86_mode(v) == 8); + bool mode_64bit = (vmx_guest_x86_mode(v) == X86_MODE_64BIT); decode->type = VMX_INST_MEMREG_TYPE_MEMORY; @@ -2073,7 +2073,8 @@ int nvmx_handle_vmx_insn(struct cpu_user_regs *regs, unsigned int exit_reason) if ( !(curr->arch.hvm.guest_cr[4] & X86_CR4_VMXE) || !nestedhvm_enabled(curr->domain) || - (vmx_guest_x86_mode(curr) < (hvm_long_mode_active(curr) ? 8 : 2)) || + (vmx_guest_x86_mode(curr) < (hvm_long_mode_active(curr) ? X86_MODE_64BIT + : X86_MODE_16BIT)) || (exit_reason != EXIT_REASON_VMXON && !nvmx_vcpu_in_vmx(curr)) ) { hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h index 02de18c7d4..dbc37e8b75 100644 --- a/xen/arch/x86/include/asm/hvm/hvm.h +++ b/xen/arch/x86/include/asm/hvm/hvm.h @@ -26,6 +26,12 @@ extern bool opt_hvm_fep; #define opt_hvm_fep 0 #endif +#define X86_MODE_REAL 0 +#define X86_MODE_VM86 1 +#define X86_MODE_16BIT 2 +#define X86_MODE_32BIT 4 +#define X86_MODE_64BIT 8 + /* Interrupt acknowledgement sources. */ enum hvm_intsrc { hvm_intsrc_none, -- 2.45.2 Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Mon Dec 02 09:55:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 09:55:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846487.1261648 (Exim 4.92) (envelope-from ) id 1tI38y-0003Kk-T1; Mon, 02 Dec 2024 09:55:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846487.1261648; Mon, 02 Dec 2024 09:55: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 1tI38y-0003Kd-Pm; Mon, 02 Dec 2024 09:55:04 +0000 Received: by outflank-mailman (input) for mailman id 846487; Mon, 02 Dec 2024 09:55: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 1tI38x-0003KX-By for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 09:55:03 +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 7e1b726b-b093-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 10:54:59 +0100 (CET) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-aa545dc7105so640074666b.3 for ; Mon, 02 Dec 2024 01:54: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 a640c23a62f3a-aa5998e63b8sm494046266b.123.2024.12.02.01.54.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 01:54: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: 7e1b726b-b093-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo2MmEiLCJoZWxvIjoibWFpbC1lajEteDYyYS5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjdlMWI3MjZiLWIwOTMtMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTMzMjk5LjYwMjIwNiwic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733133299; x=1733738099; 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=BZK2qZfdEmLMjT4c1bLV/XnCJB4xOa3Dj0kZfp4EIfU=; b=DqTcuUnVWYFT/bGEdy+A4U5JyudVc47rfXKvvMiLNHp4aY7xasLreJgMdu5zHSxEHk Hb0CORRp0ZYfP+udX5raUCrpMKJ/ZfdezyRUPFseNdc1m+8jHz7MizOHlriE7pwYkhNl Rl9Vbp7ki+9w+uMQHtAc1jOWzluGMMl9n+qK0BdlUiqDxLlqygtwdo5FjuEGBocFROJ+ ZuuX+jof9XDhAxrIpHpbY1MlV8+XF52WGz3F3KLWHR43uI3KE6MjofyleKqZWBHXdx4m lw5f6T53PtHgYmJ1YU8ub0HtmUqdZK0/G0zRvvfNkJ5zzUz1q7uf7zHTPjAJ80UH8RqB vQOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733133299; x=1733738099; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=BZK2qZfdEmLMjT4c1bLV/XnCJB4xOa3Dj0kZfp4EIfU=; b=lxGm+gM8sHphMB55tKhpm3RtsDsgpHqTXg14sELx7thwOa51nJ9vwTp1igMRe/0Vfe gJ8IgRzhtqlSLXEiMLacJqrQKMPB4P6ViPwuaMAnjiQrIn5u6QpwnzJX4iNHDPD385dU jVu/LuRkybiKt7nOCC/6tIjNnQt9mqx32zYRuX7gdsnIOzIbImefxSDm4Lah3lKAUCYj 0Mo+k2NIkH33hArJxdUe4Ei8ldzVPtvVh79EFWeKaz3//xeHs6qBXdWo10XJJvyyDh5S 1g825YO9gDXBk5NoUYpLoCL/itfQY0XI4okeUPSEDo1rrvuHuqcPWZ2/kfRxorFQf4+o Umyg== X-Forwarded-Encrypted: i=1; AJvYcCXTt11JA1LcNcJgRIJRHdVcTEZxicySeMw9RexbFREq4UZMP4jp03r8rVMsQrdJtW2RmRyHnJtxdbo=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyd6h14WC2BGkyF7lRJpR0/l7nVJpMxF2hftF5WTLahB3hKJ7H1 RHqTPSPy0n0jQOMVJBVhBnUsF2g2H4dR923SXPSIf0h6Uca9SqEhJfL8SxVczBIiK5opswYjYMg = X-Gm-Gg: ASbGncuBjjHbBxuDG0gFzP5dfKZ0rGhZmuAhO+Si18/NnyC/hZCunDiQJgsa/OOWWEd l3+AJ9gXG/aCma7ihatVsNj+T7NaO8LHHHgC5Uq9ojSmDY9rtlSLc1aUQTfE75B948yeuH/gbYV 0a9L1yatf3BtAthJrFmxJHTy/611AMD+FsjOtJbwt5TC2KGwrrjA/IGb2LRGlSaAjsyagbo06W/ V+NjWgQ/ANgSsnANE3zLgG+XB8io9vcMQPZw/qHW8jWtvCBz/0AD5joxtw9phVuJvBBH5XQaEV6 rhd2w203Jsvegq4c6aJidvt+/n/Ptovxhqo= X-Google-Smtp-Source: AGHT+IHXo7HZ9Y+0GIFiPZxjMQeKw9kOm5Oy6FYJ8yS/lGo+P0pDukWKbfw9we7f558liDlA89y8Dg== X-Received: by 2002:a17:906:3147:b0:a99:5f16:3539 with SMTP id a640c23a62f3a-aa580b3188emr1782042766b.0.1733133299031; Mon, 02 Dec 2024 01:54:59 -0800 (PST) Message-ID: <7ca79382-251c-403a-9d1c-9afd778bb203@suse.com> Date: Mon, 2 Dec 2024 10:55:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/15] x86/hyperlaunch: introduce the domain builder To: Jason Andryuk , "Daniel P. Smith" Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241123182044.30687-1-dpsmith@apertussolutions.com> <20241123182044.30687-7-dpsmith@apertussolutions.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 25.11.2024 18:52, Jason Andryuk wrote: > On 2024-11-23 13:20, Daniel P. Smith wrote: >> --- /dev/null >> +++ b/xen/arch/x86/domain_builder/fdt.c >> @@ -0,0 +1,38 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> +/* >> + * Copyright (C) 2024, Apertus Solutions, LLC >> + */ >> +#include >> +#include >> +#include >> +#include >> +#include /* required for asm/setup.h */ > > Should asm/setup.h just be changed? Why would it need changing (and why's that #include needed)? It has a proper forward decl of the struct tag, and I can't see why it would need anything else. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 09:56:10 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 09:56:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846493.1261657 (Exim 4.92) (envelope-from ) id 1tI3A2-0003pg-5f; Mon, 02 Dec 2024 09:56:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846493.1261657; Mon, 02 Dec 2024 09:56: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 1tI3A2-0003pZ-2X; Mon, 02 Dec 2024 09:56:10 +0000 Received: by outflank-mailman (input) for mailman id 846493; Mon, 02 Dec 2024 09:56: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 1tI3A1-0003pF-3Y for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 09:56:09 +0000 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [2a00:1450:4864:20::134]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a5ecf1a2-b093-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 10:56:06 +0100 (CET) Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-53de035ea13so4048231e87.0 for ; Mon, 02 Dec 2024 01:56:06 -0800 (PST) Received: from [192.168.219.191] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-53df643117fsm1406013e87.24.2024.12.02.01.56.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 01:56: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: a5ecf1a2-b093-11ef-a0d2-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjoxMzQiLCJoZWxvIjoibWFpbC1sZjEteDEzNC5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6ImE1ZWNmMWEyLWIwOTMtMTFlZi1hMGQyLThiZTBkYWMzMDJiMCIsInRzIjoxNzMzMTMzMzY2LjM1NzExMSwic2VuZGVyIjoib2xla3NpaS5rdXJvY2hrb0BnbWFpbC5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733133366; x=1733738166; darn=lists.xenproject.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=jfgslfg5iTPo990WOheGYmdRdC6SYQqGZeK6vQ3ydwo=; b=Al6l0Uo04ecfk7wqW9ycUbxBVwNKUqXa5Rs3HgVXa9EjqnhP+eLBZYWexfZrXBkpea wuxsX7AEpkErFPfKHRtR6Hsl6KtI/p6ChKN9gaXne1OX4uzpmyDY3jTOwy4Ly0Exe2f1 nnNV1Xdhl4powPo++NJPY0vNFvlD6EcqM3JB9ptTKViYXNz1cY0h5NxodGY655lFfhYs 22oaNNbro82cNdS5ORgFNFPmlzvh6OfQgimJXb7k6Y+mqBZYNMoyIeviJHPHY5+35C4S Ihv9RDGxUw51kxsn2xQsQSA2ot9PaOkRFVblZIglyNAtyRzeBCjKJQ7iMRZ31yeMTmQW QoqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733133366; x=1733738166; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=jfgslfg5iTPo990WOheGYmdRdC6SYQqGZeK6vQ3ydwo=; b=YXqGfrFQt/bLXGjU07XI0w/YcgZyHz2zagYxHPVG54FsPhNqmXIiunGf/jc0e+ebMZ PtUpECr/snmSIGUR25OhyDAgN7bT7P+7vAtJKW4/ACebgikV6YRAX5mArDfsU7+3VhIF xnG8251l74aDGNpPKNN2nBIJmWvmUs3XQ5+nOdUOP2rPEed13ZdPOHpAPxR6CTXIsXKw l+cPktp8lBT4uR8H96+mvqYPHCJgq7GYg6huuv/iXKFIAy/uWNl82hnDYVPBWDvrDaxF ogcBcXmsXYOg3WCE+IrE/FiITp3iMM525xYSaCI0Y5zLb6aNXod8jM4TSL5t+xka6O/e 0Z8w== X-Forwarded-Encrypted: i=1; AJvYcCWyo/5ep2Wa3fFQV2ttbmNjZPPvGnPqWg667Kp38mawFHsu+V88kv+svOeU3gLPJk7LVAcSSlRfv38=@lists.xenproject.org X-Gm-Message-State: AOJu0YxmjimBHp+NTqaVH54ATmMS1MxTmO56IgKZexDZsEvAdGDYcbyB TcWLHbl9D5iRpy9opFj3UfCzCT6uqZbgrfHuSVjo8Dw/JzFQnA4W X-Gm-Gg: ASbGncv+AunY/S7YvkYvAOhri9sC98L5QllLsUZb9109AFhSTwEdW++uuHYvuhyeNYl LIJHbizLtyPYysokn5BtaNvO4RT9QMkhdDKVOBHK+7f9nS106UtgclxO0Bp/TmXJsUNk5pddxFT n+AFBukngfL4f2GS3LGUeg/J8OdeK+ut3O1OXjnpkbvNEW56ahEi5L9mE02fidKqv+9R9t19hKO f5RJcN0aO1yzGEdSTuzc4WQWJvICPqQFfYrT4KwE1tzuGlW055sNNNsIoQMQxA= X-Google-Smtp-Source: AGHT+IGIF264bOjdVGsJejtpU2uhQT4s97Y9QPUGSQIMo9shCVmVBzsxDjWzOli1cpbXL8BBzs4O1w== X-Received: by 2002:a05:6512:400f:b0:53d:ed75:6f0 with SMTP id 2adb3069b0e04-53df0106bdcmr12963476e87.35.1733133365367; Mon, 02 Dec 2024 01:56:05 -0800 (PST) Message-ID: Subject: Re: [PATCH v2 4/4] xen: riscv: enable stack protector feature From: oleksii.kurochko@gmail.com To: Jan Beulich , Volodymyr Babchuk Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , Julien Grall , Stefano Stabellini , "xen-devel@lists.xenproject.org" Date: Mon, 02 Dec 2024 10:56:04 +0100 In-Reply-To: <2f92aeb0-bb1f-49d0-9655-8ff93fee8837@suse.com> References: <20241130010954.36057-1-volodymyr_babchuk@epam.com> <20241130010954.36057-5-volodymyr_babchuk@epam.com> <2f92aeb0-bb1f-49d0-9655-8ff93fee8837@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 (3.54.1-1.fc41app1) MIME-Version: 1.0 On Mon, 2024-12-02 at 09:12 +0100, Jan Beulich wrote: > On 30.11.2024 02:10, Volodymyr Babchuk wrote: > > Enable previously added CONFIG_STACK_PROTECTOR feature for RISC-V > > platform. Here we can call boot_stack_chk_guard_setup() in > > start_xen() > > function, because it never returns, so stack protector code will > > not > > be triggered because of changed canary. > >=20 > > Signed-off-by: Volodymyr Babchuk > > Tested-by: Oleksii Kurochko >=20 > Isn't this premature? For ... >=20 > > @@ -57,6 +58,8 @@ void __init noreturn start_xen(unsigned long > > bootcpu_id, > > =C2=A0=C2=A0=C2=A0=C2=A0 if ( !boot_fdt_info(device_tree_flattened, dtb= _addr) ) > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BUG(); > > =C2=A0 > > +=C2=A0=C2=A0=C2=A0 boot_stack_chk_guard_setup(); >=20 > ... this function's use of get_random(), either arch_get_random() > needs > to be implemented, or (as Julien also pointed out for Arm64) NOW() > needs > to work. Yet get_s_time() presently expands to just BUG_ON(). Given > this > it's not even clear to me how Oleksii managed to actually test this. Okay, I think I found what is the problem and why my testing on staging wasn't really correct. In xen/include/xen/stack_protector.h ( https://patchew.org/Xen/20241130010954.36057-1-volodymyr._5Fbabchuk@epam.co= m/20241130010954.36057-3-volodymyr._5Fbabchuk@epam.com/ ) CONFIG_STACKPROTECTOR is used for ifdef-ing so the stub version of=20 boot_stack_chk_guard_setup() is used and there is no need for get_random() implementation: 1. Shouldn't it be /s/CONFIG_STACKPROTECTOR/CONFIG_STACK_PROTECTOR ? 2. CONFIG_STACK_PROTECTOR isn't set in case of RISC-V, at least: grep -Rni "STACK_PROTECTOR" xen/.config=20 38:CONFIG_HAS_STACK_PROTECTOR=3Dy 76:# CONFIG_STACK_PROTECTOR is not set =20 Shouldn't it be default HAS_STACK_PROTECTOR ( or something similar ) for 'config STACK_PROTECTOR': diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 0ffd825510..f3156dbb9a 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -521,6 +521,7 @@ config TRACEBUFFER =20 config STACK_PROTECTOR bool "Stack protection" + default HAS_STACK_PROTECTOR depends on HAS_STACK_PROTECTOR help Use compiler's option -fstack-protector (supported both by GCC =20 With these changes, I can confirm Jan's statement that the BUG_ON() occurs due to the absence of the get_random()/NOW() implementation. My second test (on my downstream branch) wasn't relevant because get_s_time() and NOW() are implemented there. Aside from the changes I mentioned above, I can re-send this patch when I submit the patch enabling get_s_time() and NOW() for RISC-V. If you, Volodymyr, are okay with that, we can proceed in this way. Best regards, Oleksii From xen-devel-bounces@lists.xenproject.org Mon Dec 02 09:57:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 09:57:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846505.1261667 (Exim 4.92) (envelope-from ) id 1tI3Au-0004Nw-EI; Mon, 02 Dec 2024 09:57:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846505.1261667; Mon, 02 Dec 2024 09:57: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 1tI3Au-0004Np-BN; Mon, 02 Dec 2024 09:57:04 +0000 Received: by outflank-mailman (input) for mailman id 846505; Mon, 02 Dec 2024 09:57: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 1tI3As-0003pF-K5 for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 09:57:02 +0000 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [2a00:1450:4864:20::62f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c6106198-b093-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 10:57:00 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a9a68480164so566658366b.3 for ; Mon, 02 Dec 2024 01: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 a640c23a62f3a-aa5996c11c0sm488748466b.35.2024.12.02.01.56.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 01: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: c6106198-b093-11ef-a0d2-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo2MmYiLCJoZWxvIjoibWFpbC1lajEteDYyZi5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6ImM2MTA2MTk4LWIwOTMtMTFlZi1hMGQyLThiZTBkYWMzMDJiMCIsInRzIjoxNzMzMTMzNDIwLjI5MzEzNywic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733133420; x=1733738220; 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=itCBYJ2tSnP3SFzDDju7SCugxJgCPiwpzoFYH3qzQW4=; b=BhurNz2Ag+ldwopoj53u0pgGdpaxahFeXy4xCsUTZ9aYjBkrV8PI9gMz2SExjCsowN 2Parm/b8adRcw37Qf5LFofJwdADDvARBind+28q75lckFg+d7dS7GyI8Akyf6H2d1aaK VAJ+uCW96Up0SoNE/nXlGHIRlQReqbIRqKHNsSQy/1fnZ1IWvoPeA0K5upvo3xfh9wTC GvIzHF1gDfTytQv7ObgCQS4XBFtGS1DpJbZ5/a8+FF6feAIPXIupfsV5xaUTf4na7Iti ghFr0sHibQJaVsaFAX2krx+PK6gM73uIV8iWzDK/mSTbjr6BW2qsskbKjq8MNFUZQfCv khXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733133420; x=1733738220; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=itCBYJ2tSnP3SFzDDju7SCugxJgCPiwpzoFYH3qzQW4=; b=b6SIOX72L0gXxbHHnUIrx+bgeagd5nmsHIanHLGptWq9/ulpR8Dfth/4CGu/xpho5D lSPZlkmmNzQg49g+cndRTCWq8XSy5+f8TFzTYaARt/4wVg8f2RDUD7/XqNQTFiv1yn1f wTxyWgQcYFKzGPT4ogogBplMamqrkSpeHuyWnO7WTQuSmXRmo1/2pDHSgFXDSXFqYuq0 /aJWvV8jNhTGaD0OdWa1SouzSsgt57sxlsQsHRZQrWrPzROMJLy6LKoffl68GzOD6xKK P5V+uVZwIRdI06P40OQrp9fNMIZC8BNNiRTcTvqgmdUDW55l297639AW2aVOJlvH5jVw 7g4w== X-Forwarded-Encrypted: i=1; AJvYcCXSxhBHkCMtondOTaN8mmSYMT2/OtjbNkajtPAgyIiejIeoZftNuKSJ+QeCf1GWAo4Oj405n6+7hk8=@lists.xenproject.org X-Gm-Message-State: AOJu0YwWKXrB8GJrgDNign3ToWy7bw/AIlZndbcH+1X6bisQFK0xYkPf SXdRppPzPLq2jecuLJgjsFhQcatAFX15iCjglKECRnnZGjDWYIm3J+gfAirBMw== X-Gm-Gg: ASbGnctru2Wla4sNexsY3CpyHJPnM1Hjotn5IMp9mlBY562CBfY04s8tdKLpgjjV83w XIwkrVi7/Ta5/er/Q3n3mG17MsEuxT5CsWjhjGjwezwPiGDzEOOqhsXTZFn9vaf2r2LmZ2Idhs/ Qqi2ql6IBIo3Jz4sUQGYd25ZY9/16dUvcOLnDB69WycZCq/XQhIezcz//7mS21amOHX+cBxK17B PIU5mH3uQtrHwivVaFEBSrO8P/nwDRi6oQ62MoIl6wKMvvbIgwu4CFQT5Di7u0QgPrab9vpe6DN Pj8ahX8x/ougJDpy9QuKTHFO/0Gs94qJzQY= X-Google-Smtp-Source: AGHT+IH+NkQ8zdXgS8azURKS7JwAfg1YGPe7opRdV2fr9aEHXcofK+7UguTQwlyK46XEft1KC2ZdRw== X-Received: by 2002:a17:907:abb:b0:aa5:308c:3489 with SMTP id a640c23a62f3a-aa58108aa75mr1815818566b.58.1733133419695; Mon, 02 Dec 2024 01:56:59 -0800 (PST) Message-ID: Date: Mon, 2 Dec 2024 10:57:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 01/15] x86/boot: introduce boot domain To: "Daniel P. Smith" Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com, stefano.stabellini@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241123182044.30687-1-dpsmith@apertussolutions.com> <20241123182044.30687-2-dpsmith@apertussolutions.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: <20241123182044.30687-2-dpsmith@apertussolutions.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.11.2024 19:20, Daniel P. Smith wrote: > To begin moving toward allowing the hypervisor to construct more than one > domain at boot, a container is needed for a domain's build information. > Introduce a new header, , that contains the initial > struct boot_domain that encapsulate the build information for a domain. Why does this need to be a per-arch header? Wasn't one of the goals to unify things as much as possible? > --- a/xen/arch/x86/include/asm/dom0_build.h > +++ b/xen/arch/x86/include/asm/dom0_build.h > @@ -13,9 +13,9 @@ unsigned long dom0_compute_nr_pages(struct domain *d, > unsigned long initrd_len); > int dom0_setup_permissions(struct domain *d); > > -struct boot_info; > -int dom0_construct_pv(struct boot_info *bi, struct domain *d); > -int dom0_construct_pvh(struct boot_info *bi, struct domain *d); > +struct boot_domain; > +int dom0_construct_pv(struct boot_domain *bd); > +int dom0_construct_pvh(struct boot_domain *bd); I'm wondering: Just a few commits ago you moved these to boot_info. Now you move them to boot_domain. Why the extra churn, and what further transformations are to be expected? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 10:10:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 10:10:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846517.1261678 (Exim 4.92) (envelope-from ) id 1tI3O7-0007gS-J8; Mon, 02 Dec 2024 10:10:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846517.1261678; Mon, 02 Dec 2024 10:10:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tI3O7-0007gL-G4; Mon, 02 Dec 2024 10:10:43 +0000 Received: by outflank-mailman (input) for mailman id 846517; Mon, 02 Dec 2024 10:10: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 1tI3O6-0007gF-1d for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 10:10:42 +0000 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [2a00:1450:4864:20::532]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ad5c121a-b095-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 11:10:37 +0100 (CET) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-5d0e75dd846so1387477a12.3 for ; Mon, 02 Dec 2024 02:10:37 -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 a640c23a62f3a-aa5996dbf31sm493652166b.47.2024.12.02.02.10.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 02:10: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: ad5c121a-b095-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo1MzIiLCJoZWxvIjoibWFpbC1lZDEteDUzMi5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6ImFkNWMxMjFhLWIwOTUtMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTM0MjM3Ljg1NTI1Nywic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733134237; x=1733739037; 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=o2n9k1fhN9P3/o67X3PSacLZ7WGYwV/ZLouRvWA0zN0=; b=QsSeKtPvoGBG2L+VXRSU7palxWheKSxqykTku/Ctc0csB5a6vmiho1Nc0k1sS77fnx G4/r+f69JW+UZwnMGuFOyjLk90+3RgE1HE30LDRuDs9T6dY8w2yNzFZuL5ma4FXwyb0u dbol1P0pF6IkITrg8Pf20oEYTiz9mPQQK1kJbdRYeuFnDzF6a6YsxYNVKGH/AFOxQW6V 32sO0b3JKq4OcFphxTw3rsswtj6fe8zqDTVTWPAsAu79+t2Cxmz80mxd/yXCfivC9GwU FmWFsXr9WIyqkKNF8xj5QY9sxF3VheS8BctfFgG6GAQCE0Zzp4uSagPfz4sLqlx8Stmw tSVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733134237; x=1733739037; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=o2n9k1fhN9P3/o67X3PSacLZ7WGYwV/ZLouRvWA0zN0=; b=klv71dA6kSQfIpMNU1S9B1DHlbJD34uKP6TiUkVRp0fSDHiNodO0gzNM10AFI4cAL3 KujninIf4clYjRQF611/Myrw9KVXezqL/xEP8WM9/jJxRbDFrxyAyzHoL0r4rgu6r1iP lkhLfVq8aPpi3+B/xDJ8M/6sSNE+HaZ5y4h+z4OAGrhsIKXzxRbQ9JxZXxXVYFJfL5wh WUDvMA66BzdBxIqf9vO1ZTn+9FyICRmHsNlvt5WneNErPlmJQkhXDe609NQRme9Wk0lf GpfA0duWByKdbcZSxdEFdtDg0PgIJY4ZvFiuG1sUTsT3FsAX0EFLvJ7/vlF7gkCW2/lZ FIsg== X-Forwarded-Encrypted: i=1; AJvYcCVPSDb+V+njcvSQ/CWWCIzSc01RwXc9u35f2OZCztIzsmIhk4F73gYGScf3kxxJj1a33vYO9/Q8B70=@lists.xenproject.org X-Gm-Message-State: AOJu0YyC0ii5yHPT403zgGRtMIslV/SO9PLpJh/l+wPmT+GtRRhYuKdV ynHj6zUlwDOvP7kpUeYAMuOW8Bj2eQB4bd/nppCl0ZG/PL+L8VDfSO3uSUsnxg== X-Gm-Gg: ASbGncvO1VF2NZP1e89G2eHjk4MWxjMz4CyPAOAjwTkNn8zyPpV0KLvtpq2nBTNnO5b RZ9aPSoP2z3M6OQ8akeIeNhkyIbtRBUvRNR5i1wsDtGKmIGxdwJoFfDDcKZwFtPtP4G6F4zaykV lfs66uXmX6BQJHD/SUVB1lZDKd4ExXYDfBTn3fR2EjKA5CuIKSbyazWlUmUdMhSjBHXvc7h4oaS +f7CVPG6s+uGACQHF14zKYlNzE8v/MbILaDp0oqWk970s0BWx7hlX4j8KF79wvm/LIawwBVtwbe C2uzC/jYnObXeBFdvABEQxKdJLEWbHyp41s= X-Google-Smtp-Source: AGHT+IE7kS8BCw7GoeM7M2zsR9xDbP8wAFQK3Ns7Mi2uel5yg7h0SxhZ/cIhgsXl+I81EDDX1ChP3A== X-Received: by 2002:a05:6402:358a:b0:5d0:81af:4a43 with SMTP id 4fb4d7f45d1cf-5d081af8571mr21465304a12.0.1733134237215; Mon, 02 Dec 2024 02:10:37 -0800 (PST) Message-ID: Date: Mon, 2 Dec 2024 11:10:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/15] x86/hyperlaunch: introduce the domain builder To: "Daniel P. Smith" Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com, stefano.stabellini@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241123182044.30687-1-dpsmith@apertussolutions.com> <20241123182044.30687-7-dpsmith@apertussolutions.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: <20241123182044.30687-7-dpsmith@apertussolutions.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.11.2024 19:20, Daniel P. Smith wrote: > Introduce the domain builder which is capable of consuming a device tree as the > first boot module. If it finds a device tree as the first boot module, it will > set its type to BOOTMOD_FDT. This change only detects the boot module and > continues to boot with slight change to the boot convention that the dom0 > kernel is no longer first boot module but is the second. > > No functional change intended. > > Signed-off-by: Daniel P. Smith > --- > xen/arch/x86/Makefile | 2 + > xen/arch/x86/domain_builder/Makefile | 3 ++ > xen/arch/x86/domain_builder/core.c | 55 ++++++++++++++++++++++++ > xen/arch/x86/domain_builder/fdt.c | 38 ++++++++++++++++ > xen/arch/x86/domain_builder/fdt.h | 21 +++++++++ > xen/arch/x86/include/asm/bootinfo.h | 3 ++ > xen/arch/x86/include/asm/domainbuilder.h | 8 ++++ > xen/arch/x86/setup.c | 18 +++++--- > 8 files changed, 142 insertions(+), 6 deletions(-) > create mode 100644 xen/arch/x86/domain_builder/Makefile > create mode 100644 xen/arch/x86/domain_builder/core.c > create mode 100644 xen/arch/x86/domain_builder/fdt.c > create mode 100644 xen/arch/x86/domain_builder/fdt.h As I'm sure I indicated before: Dashes instead of underscores please in new files' names. > create mode 100644 xen/arch/x86/include/asm/domainbuilder.h Why is there no separator in this file's name? Similar question as on an earlier patch: Why is all of this x86-specific, when a goal was generalization? > --- /dev/null > +++ b/xen/arch/x86/domain_builder/core.c > @@ -0,0 +1,55 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Copyright (C) 2024, Apertus Solutions, LLC > + */ > +#include > +#include > +#include > +#include > + > +#include > + > +#include "fdt.h" > + > +void __init builder_init(struct boot_info *bi) > +{ > + if ( IS_ENABLED(CONFIG_DOMAIN_BUILDER) ) > + { > + int ret; > + > + switch ( ret = has_hyperlaunch_fdt(bi) ) > + { > + case 0: > + printk("Hyperlaunch device tree detected\n"); > + bi->hyperlaunch_enabled = true; > + bi->mods[0].type = BOOTMOD_FDT; > + break; > + case -EINVAL: > + printk("Hyperlaunch device tree was not detected\n"); > + bi->hyperlaunch_enabled = false; > + break; > + case -ENOENT: > + fallthrough; No need for this. > + case -ENODATA: > + printk("Device tree found, but not hyperlaunch (%d)\n", ret); > + bi->hyperlaunch_enabled = false; > + bi->mods[0].type = BOOTMOD_FDT; > + break; > + default: > + printk("Unknown error (%d) occured checking for hyperlaunch device tree\n", > + ret); > + bi->hyperlaunch_enabled = false; > + } Nit: Misra demands "break" at the end of default as well. Blank lines between non-fallthrough blocks would also be nice. > + Nit: Excess blank line. > --- /dev/null > +++ b/xen/arch/x86/domain_builder/fdt.c > @@ -0,0 +1,38 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Copyright (C) 2024, Apertus Solutions, LLC > + */ > +#include > +#include > +#include > +#include > +#include /* required for asm/setup.h */ > + > +#include > +#include > +#include > + > +#include "fdt.h" > + > +int __init has_hyperlaunch_fdt(struct boot_info *bi) > +{ > + int ret = 0; > + void *fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]); const void *? > @@ -1277,9 +1278,12 @@ void asmlinkage __init noreturn __start_xen(void) > bi->nr_modules); > } > > - /* Dom0 kernel is always first */ > - bi->mods[0].type = BOOTMOD_KERNEL; > - bi->domains[0].kernel = &bi->mods[0]; > + builder_init(bi); > + > + /* Find first unknown boot module to use as Dom0 kernel */ > + i = first_boot_module_index(bi, BOOTMOD_UNKNOWN); > + bi->mods[i].type = BOOTMOD_KERNEL; > + bi->domains[0].kernel = &bi->mods[i]; Better latch the result here into a separate local variable, for use ... > @@ -1466,8 +1470,9 @@ void asmlinkage __init noreturn __start_xen(void) > xen->size = __2M_rwdata_end - _stext; > } > > - bi->mods[0].headroom = > - bzimage_headroom(bootstrap_map_bm(&bi->mods[0]), bi->mods[0].size); > + i = first_boot_module_index(bi, BOOTMOD_KERNEL); > + bi->mods[i].headroom = > + bzimage_headroom(bootstrap_map_bm(&bi->mods[i]), bi->mods[i].size); > bootstrap_unmap(); > > #ifndef highmem_start > @@ -1591,7 +1596,8 @@ void asmlinkage __init noreturn __start_xen(void) > #endif > } > > - if ( bi->mods[0].headroom && !bi->mods[0].relocated ) > + i = first_boot_module_index(bi, BOOTMOD_KERNEL); > + if ( bi->mods[i].headroom && !bi->mods[0].relocated ) > panic("Not enough memory to relocate the dom0 kernel image\n"); > for ( i = 0; i < bi->nr_modules; ++i ) > { ... in these two places? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 10:32:47 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 10:32:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846535.1261704 (Exim 4.92) (envelope-from ) id 1tI3jH-0002vt-H3; Mon, 02 Dec 2024 10:32:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846535.1261704; Mon, 02 Dec 2024 10:32:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tI3jH-0002vm-Dy; Mon, 02 Dec 2024 10:32:35 +0000 Received: by outflank-mailman (input) for mailman id 846535; Mon, 02 Dec 2024 10:32: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 1tI3jG-0002vc-2z for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 10:32:34 +0000 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [2a00:1450:4864:20::444]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ba4dccf5-b098-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 11:32:28 +0100 (CET) Received: by mail-wr1-x444.google.com with SMTP id ffacd0b85a97d-385e1fcb0e1so1070568f8f.2 for ; Mon, 02 Dec 2024 02:32:28 -0800 (PST) Received: from [192.168.86.29] ([90.240.255.120]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-385df15e1e7sm9439970f8f.40.2024.12.02.02.32.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 02:32: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: ba4dccf5-b098-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo0NDQiLCJoZWxvIjoibWFpbC13cjEteDQ0NC5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6ImJhNGRjY2Y1LWIwOTgtMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTM1NTQ4LjA5MTM1LCJzZW5kZXIiOiJhbmRyZXcuY29vcGVyQGNsb3VkLmNvbSIsInJlY2lwaWVudCI6Inhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZyJ9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1733135547; x=1733740347; 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=ZGi6JQX5Ir8Avtbk5xcbxGZZF4WpItgDBposOI+fT0M=; b=fY003xQ8Xh0wa9M9IRIQDKPGhRYS+BFIuEOxjPYFDv+8eyO4jz2GgzoT41QnrsArrM MGxTwe6rYxlaCfDnCDTozj4h4vsBr6U5gJLaC8h2Y9bJiOjtVEuU8l7E/25fkQ+fhFdb MLgnf3ObrXC3Nl/gzxOXPE1jwSqTN+EUBa3v0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733135547; x=1733740347; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ZGi6JQX5Ir8Avtbk5xcbxGZZF4WpItgDBposOI+fT0M=; b=iDEaOFkSQlO9j/z00IxqL51ozHIABqv0qrO4BEsLbCLE/vITtr9Li4pr/dGn3HYcPQ o3nWP77KU4o1v4KuLBYzyQc4MVKUOKvot0lZLSal79JWMKxVIanYjq32dsbejH2V3vZ8 918mIhAcvJU3ny4hYWoA70MAAOTkr3c1IIEKWQi1UZj6FcUCcSz882/LLkpIPBE7Zmr0 d4RYOPatPMbF5z3lDj//jsUm4EsWUJ5qQw1CyOnzzIDP59BiMb5Pr2COdIEx4t79xnR4 ojSHstGuXyc75Xu4XO/P04t2Uk3ASlfD3b3i4vsIwaVqtc3U+Cr6mked8B8nLeLXocYY gB0w== X-Forwarded-Encrypted: i=1; AJvYcCXCTjJ6+FqzZlfMCgPTZq57ri+0svUFZ3fymJRg/LqueSDH1cTEs/EUFY5iSwgpG5gNvCWUw5JVg0Y=@lists.xenproject.org X-Gm-Message-State: AOJu0YzPRWaVA2KlL7bZ0G4IOZEim7ZaXimQWYv1/ogPfiQ4Ms/5VyXX HSjeOzGaYfz0/CLgmS9yf2GUxZvTkLXNwAEJMPanhd1PdMZb2C/9ZxFlIp2mrfs= X-Gm-Gg: ASbGncu//eqxqUDy4sfY2z5rIncN1EQ+zF05Jx7RQdZLZ13dHoZgaXjK96xAb5tJfqb eu/xrqiBPBw2KTf1rPa8KntJX9ly/dx5lQ2xFKoz3V93R7yvYpBo3Mv+VvibpbMj7+1anxIGOXL SsPkOKjMfLcvv8tZy6tXUY8vwUb9VMqcuiomajeZ/goCFn/b3WTEQfxQvpcllUCmQcIrQpP1B2e l+Avz7dBsSXLlDxexFkLIHLzZShutgfP+ApgtLQrPzuBKmvzQT+U+dgRjH2r+Q= X-Google-Smtp-Source: AGHT+IFqe8aSc+XYv+N3ydO51n0afa0lqeamRD8iLQEQFlNbDRpaLjw8MjkIiCtrH6A/UGcyA7J/Dg== X-Received: by 2002:a05:6000:188c:b0:382:5010:c8de with SMTP id ffacd0b85a97d-385c6edd539mr20491028f8f.46.1733135547445; Mon, 02 Dec 2024 02:32:27 -0800 (PST) Message-ID: <9577c54c-7c6e-4411-9db9-c7070e13ebde@citrix.com> Date: Mon, 2 Dec 2024 10:32:26 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/4] common: remove -fno-stack-protector from EMBEDDED_EXTRA_CFLAGS To: Jan Beulich , Volodymyr Babchuk Cc: Julien Grall , Stefano Stabellini , Anthony PERARD , Samuel Thibault , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <20241130010954.36057-1-volodymyr_babchuk@epam.com> <20241130010954.36057-2-volodymyr_babchuk@epam.com> <56f5cf93-33fc-4314-8d38-93d9e0026429@suse.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <56f5cf93-33fc-4314-8d38-93d9e0026429@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 02/12/2024 8:06 am, Jan Beulich wrote: > On 30.11.2024 02:10, Volodymyr Babchuk wrote: >> This patch is preparation for making stack protector >> configurable. First step is to remove -fno-stack-protector flag from >> EMBEDDED_EXTRA_CFLAGS so separate projects (Hypervisor in this case) >> can enable/disable this feature by themselves. > s/projects/components/ ? > >> --- a/stubdom/Makefile >> +++ b/stubdom/Makefile >> @@ -54,6 +54,8 @@ TARGET_CFLAGS += $(CFLAGS) >> TARGET_CPPFLAGS += $(CPPFLAGS) >> $(call cc-options-add,TARGET_CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) >> >> +$(call cc-option-add,TARGET_CFLAGS,CC,-fno-stack-protector) >> + >> # Do not use host headers and libs >> GCC_INSTALL = $(shell LANG=C gcc -print-search-dirs | sed -n -e 's/install: \(.*\)/\1/p') >> TARGET_CPPFLAGS += -U __linux__ -U __FreeBSD__ -U __sun__ >> --- a/tools/firmware/Rules.mk >> +++ b/tools/firmware/Rules.mk >> @@ -15,6 +15,8 @@ $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) >> >> $(call cc-option-add,CFLAGS,CC,-fcf-protection=none) >> >> +$(call cc-option-add,CFLAGS,CC,-fno-stack-protector) >> + >> # Do not add the .note.gnu.property section to any of the firmware objects: it >> # breaks the rombios binary and is not useful for firmware anyway. >> $(call cc-option-add,CFLAGS,CC,-Wa$$(comma)-mx86-used-note=no) >> --- a/tools/tests/x86_emulator/testcase.mk >> +++ b/tools/tests/x86_emulator/testcase.mk >> @@ -4,6 +4,8 @@ include $(XEN_ROOT)/tools/Rules.mk >> >> $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) >> >> +$(call cc-option-add,CFLAGS,CC,-fno-stack-protector) > Is use of cc-option-add really necessary throughout here, when ... > >> --- a/xen/Makefile >> +++ b/xen/Makefile >> @@ -432,6 +432,8 @@ else >> CFLAGS_UBSAN := >> endif >> >> +CFLAGS += -fno-stack-protector > ... is isn't needed here? Iirc the compiler version ranges supported don't > vary between components. Then again afaics $(EMBEDDED_EXTRA_CFLAGS) is used > by x86 only right now, and with cc-options-add, so perhaps it (a) needs > using cc-options-add here, too, and (b) it wants explaining why this needs > generalizing from x86 to all architectures. Quite possibly hypervisor use > of $(EMBEDDED_EXTRA_CFLAGS) may want generalizing separately, up front? EMBEDDED_EXTRA_CFLAGS uses cc-*-add because some options are (/were) not accepted by compilers.  Notably -fno-stack-protector-all (found from v1 of this series), and prior to that, -no-pie which as I recall is an LD option not a CC option. All supported compilers know -fno-stack-protector (found when checking -fno-stack-protector-all) so it can be added to plain CFLAGS everywhere, not only in xen/ ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Dec 02 11:20:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 11:20:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846545.1261714 (Exim 4.92) (envelope-from ) id 1tI4Tr-0001E6-3P; Mon, 02 Dec 2024 11:20:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846545.1261714; Mon, 02 Dec 2024 11:20: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 1tI4Tq-0001Dz-Vb; Mon, 02 Dec 2024 11:20:42 +0000 Received: by outflank-mailman (input) for mailman id 846545; Mon, 02 Dec 2024 11:20: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 1tI4Tp-0001Ci-FP for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 11:20:41 +0000 Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [2607:f8b0:4864:20::22d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 73fc5383-b09f-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 12:20:37 +0100 (CET) Received: by mail-oi1-x22d.google.com with SMTP id 5614622812f47-3e916196023so2188008b6e.3 for ; Mon, 02 Dec 2024 03:20: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: 73fc5383-b09f-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjI2MDc6ZjhiMDo0ODY0OjIwOjoyMmQiLCJoZWxvIjoibWFpbC1vaTEteDIyZC5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjczZmM1MzgzLWIwOWYtMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTM4NDM3LjI0ODg2MSwic2VuZGVyIjoiZnJlZGlhbm8uemlnbGlvQGNsb3VkLmNvbSIsInJlY2lwaWVudCI6Inhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZyJ9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1733138436; x=1733743236; 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=8q3BqTTS/DY5CM3HSTkJwixHERLzBJLNnWQsaoYXLNs=; b=TyZEgiIkM15Ln5nfYii6fP+VvLu3LwzXiEUmHZHtYWXiu8Bpw1IHuH0vAJddZiqJgr gEnqnEiyaPTRTFqVDRFnoTRIO3i0AMV7Bt+HN3OXp5YGhwaiSXBSGMH8nudcH/0VMhzK p3rG12q766YrNilIxXOqRDVa+GTHsppFQy+Ug= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733138436; x=1733743236; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8q3BqTTS/DY5CM3HSTkJwixHERLzBJLNnWQsaoYXLNs=; b=NLRauNVRvu09nWCi/CY5vY34aYJNxiHswtT0dNQWH+0/L4ZvP32W9F8YvAeQttaet7 ZezydkfQNTvAH+hj564MHpBNh9MxMA5t+d4g5ZdWaAIBCoW/o613eCHaLtyuAIEm6ggk VNcYqSzWd+nnrpF75AOB6hstFKx/CgX70ajKut9IwbiDoeT58Zk455k04xtkHWbRsFDJ qSVo5NfhmAhF3kwTvjzrChoom4H5R/m20xuLh8A2G0ixIg6/mSnA5nNR2YQMvKzl+A97 3w9gRyZiWC/L8gu9Vg6ggHXNVb2PE6qXLvlsC+0IrRPulpNJdKfRaNx1sFi6+pkZ9rOB rB5Q== X-Gm-Message-State: AOJu0YwTdo/GLNjyFGcOv6j1ZjdZGu+b75fUZD3/m/M83mhV57beJmHq 0LJno8EkF7efQlIRYz9JsOJWqN5h9sARaI3XFbhqYLcFaDOxZeQBb9GGYuCDHLOM8XAFEs00BhJ rWdZh2iuT+geZow7qBKt3M5yZ9zQ3CA7CpqLf7p/31wziUZQ2 X-Gm-Gg: ASbGncs5nXOT594QgV7Ne0u/Eqw9deIUMQKdfXD1AnEDxhq0VQ9/EehMpWbjBdDAwT/ E7mPDKwoMXpxPwVks4E7WGJfu1kqADJ8= X-Google-Smtp-Source: AGHT+IFQE/MZL95ZhLtnMvGMdgvyoF3uL8JzkV8bwhrR+wFU+FtGKLXym+v7kUJxwL2ngNivfKjyJFj6H9i95X+m15c= X-Received: by 2002:a05:6808:210d:b0:3e6:6005:e36f with SMTP id 5614622812f47-3ea6db6082bmr20151715b6e.5.1733138435772; Mon, 02 Dec 2024 03:20:35 -0800 (PST) MIME-Version: 1.0 References: <20241122093358.478774-1-frediano.ziglio@cloud.com> In-Reply-To: <20241122093358.478774-1-frediano.ziglio@cloud.com> From: Frediano Ziglio Date: Mon, 2 Dec 2024 11:20:24 +0000 Message-ID: Subject: Re: [PATCH v2 0/4] Move some boot code from assembly to C To: xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ping On Fri, Nov 22, 2024 at 9:34=E2=80=AFAM Frediano Ziglio wrote: > > As a continuation of this series start sorting out the issue of headers > not compatible with 32 bit. > Instead of having to change headers which are almost only used for 64 bit > allows to override headers or move reusable definitions to new shared > headers. > This results in less changes. > > Changes since v1: > - rebased (with conflicts). > > Frediano Ziglio (4): > Use an include/boot directory to override headers for boot code > x86/boot: Use header to allows inclusion of public xen.h header > x86/boot: Move some settings to C > x86/boot: Use external symbols from cmdline_parse_early > > xen/arch/x86/boot/Makefile | 2 +- > xen/arch/x86/boot/build32.lds.S | 4 ++++ > xen/arch/x86/boot/cmdline.c | 14 ++++++++++-- > xen/arch/x86/boot/head.S | 19 +-------------- > xen/arch/x86/boot/reloc.c | 28 ++++++++++++++++++----- > xen/arch/x86/boot/trampoline.S | 2 +- > xen/arch/x86/include/asm/guest/pvh-boot.h | 1 + > xen/arch/x86/include/asm/setup.h | 2 ++ > xen/arch/x86/include/boot/public/xen.h | 28 +++++++++++++++++++++++ > xen/arch/x86/include/boot/xen/cpumask.h | 1 + > xen/arch/x86/include/boot/xen/string.h | 10 ++++++++ > 11 files changed, 83 insertions(+), 28 deletions(-) > create mode 100644 xen/arch/x86/include/boot/public/xen.h > create mode 100644 xen/arch/x86/include/boot/xen/cpumask.h > create mode 100644 xen/arch/x86/include/boot/xen/string.h > From xen-devel-bounces@lists.xenproject.org Mon Dec 02 11:32:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 11:32:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846557.1261724 (Exim 4.92) (envelope-from ) id 1tI4er-0002yk-1B; Mon, 02 Dec 2024 11:32:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846557.1261724; Mon, 02 Dec 2024 11:32:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tI4eq-0002yd-UU; Mon, 02 Dec 2024 11:32:04 +0000 Received: by outflank-mailman (input) for mailman id 846557; Mon, 02 Dec 2024 11:32: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 1tI4ep-0002yX-HB for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 11:32:03 +0000 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [2a00:1450:4864:20::12b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0ae618fd-b0a1-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 12:31:59 +0100 (CET) Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-53df7f6a133so4344850e87.3 for ; Mon, 02 Dec 2024 03:31: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-434b0f32837sm151757135e9.33.2024.12.02.03.31.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 03:31: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: 0ae618fd-b0a1-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjoxMmIiLCJoZWxvIjoibWFpbC1sZjEteDEyYi5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjBhZTYxOGZkLWIwYTEtMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTM5MTE5LjIwOTAzNCwic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733139118; x=1733743918; 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=7W6yN9rr3CDp87MekTNE2ZiQgK62p8TOhOvutuhiLzA=; b=Wy/sKZt3NXLUU4CAUxNaFHKc9aPpbLAev9oV0xFfF67Td54NkXbreo2GhGSBlNFqn+ 8vfob89YXTtTkdRvuvdVvMHF8fotAvuXbki+NuMLZR5mkwqwaluax/jIXpeVuFFFpqNX fquVzvlUlLK5ulHLMnqpCoXCUYQ00e/v8aurf95m804hRMc30KtZTdwP7/p5BGEfbuev Qd44k7KqC2p4eExIO/wgbgSaRLmVPWq/RTfPzTPm9h0oHjRC4XTMpAT8fWWKWa0cpQF3 eJcFs6OC92fUr/RLxfu44DhrX0sCDwN7Vapb+es2TuerJi2Rsox6LqlZRQLXr3MH3bUf c7Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733139118; x=1733743918; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7W6yN9rr3CDp87MekTNE2ZiQgK62p8TOhOvutuhiLzA=; b=VvMPpoYFR/92LaK0cpMYwVXq3QYUStXFlqy86C2zki31z6J+4o8GIqksSSM4aqdXOy UYWaLoxCGUmq1wXMFxPWtd2/XS9OyJ2HhYQAxA/Am1nCBcmC5QJeVMhZGDsBZJK7n+EO 6/RFHx4hHgCg3FNk0IJ+zPfAYZv8jMP8BUSKH3FTpbMy0zeAi4i8rTLwEA/45niAZuoP mvzJSLRpF2AFP0B3rzY4EqkVeWMN7jRCTwdsvY3mdkFrngy972T3O060iGKpV2cZGjpV n4ozOvioGLpOt6UU+lvx2pow/YkAUgwhCvGKb+Fy5G2px+RX+Gxf7jWQKRmqqK/L06D1 lh/w== X-Forwarded-Encrypted: i=1; AJvYcCXF0LNVv+P9UDl8tuAdtzrp/i0Yj3kWx2MPnNbnotbFpmt2I9cVvQhU+//AJiDrdvEBigvXQWfIBcw=@lists.xenproject.org X-Gm-Message-State: AOJu0YzrnwNcGjERUGuD6UCWuTHnp3trVLlm/PtUK8IOE2aUnooweByI 1qFNcgX3ZCJS04QGNq5jQqktiDYLLL/QB/j/45oaPtF7td1iH2WSorelzZ2H7A== X-Gm-Gg: ASbGncub7FB90+HE7jWG0il+u+t295/YAncbpWJudbpIO/xLkSy/Zzfxe7l5ULo462W Rqx3zVeSlQIjo91iOt94Xt+s5tz1p0hGUfy4rrf4V+cZwWx1pXUfYGEwHXlv1s16vgB8B1ywmpS iI0KIvLn6i7BpmfnaXso/7ZimxsqLthwaJl8o59Lv6Q5T8ualYud9T3wrppLTKdE0oltfZVIe/q FcQhAhSCXGnfP6t3WnvplisdngRzgVn6+4GfUGMUt2s/1VsVOutUGsUH11HLNWXO7whLPPbY4rk E8kIxuE0dDPaq2VCRxzhwff6eBh5g3osjJI= X-Google-Smtp-Source: AGHT+IFvKFyDupidQRSg9AzsJwhmta/oSD0PQSMX15ucz9Cy0E/RELT2g7pr2BinlzgxH6Qto3czdw== X-Received: by 2002:a05:6512:3b9e:b0:53d:ed7f:8154 with SMTP id 2adb3069b0e04-53df00d11a7mr10257611e87.21.1733139118573; Mon, 02 Dec 2024 03:31:58 -0800 (PST) Message-ID: <26418af7-0b5b-495c-8815-ce7305951beb@suse.com> Date: Mon, 2 Dec 2024 12:31:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/4] common: remove -fno-stack-protector from EMBEDDED_EXTRA_CFLAGS From: Jan Beulich To: Volodymyr Babchuk Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Samuel Thibault , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <20241130010954.36057-1-volodymyr_babchuk@epam.com> <20241130010954.36057-2-volodymyr_babchuk@epam.com> <56f5cf93-33fc-4314-8d38-93d9e0026429@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: <56f5cf93-33fc-4314-8d38-93d9e0026429@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 02.12.2024 09:06, Jan Beulich wrote: > On 30.11.2024 02:10, Volodymyr Babchuk wrote: >> This patch is preparation for making stack protector >> configurable. First step is to remove -fno-stack-protector flag from >> EMBEDDED_EXTRA_CFLAGS so separate projects (Hypervisor in this case) >> can enable/disable this feature by themselves. > > s/projects/components/ ? > >> --- a/stubdom/Makefile >> +++ b/stubdom/Makefile >> @@ -54,6 +54,8 @@ TARGET_CFLAGS += $(CFLAGS) >> TARGET_CPPFLAGS += $(CPPFLAGS) >> $(call cc-options-add,TARGET_CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) >> >> +$(call cc-option-add,TARGET_CFLAGS,CC,-fno-stack-protector) >> + >> # Do not use host headers and libs >> GCC_INSTALL = $(shell LANG=C gcc -print-search-dirs | sed -n -e 's/install: \(.*\)/\1/p') >> TARGET_CPPFLAGS += -U __linux__ -U __FreeBSD__ -U __sun__ >> --- a/tools/firmware/Rules.mk >> +++ b/tools/firmware/Rules.mk >> @@ -15,6 +15,8 @@ $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) >> >> $(call cc-option-add,CFLAGS,CC,-fcf-protection=none) >> >> +$(call cc-option-add,CFLAGS,CC,-fno-stack-protector) >> + >> # Do not add the .note.gnu.property section to any of the firmware objects: it >> # breaks the rombios binary and is not useful for firmware anyway. >> $(call cc-option-add,CFLAGS,CC,-Wa$$(comma)-mx86-used-note=no) >> --- a/tools/tests/x86_emulator/testcase.mk >> +++ b/tools/tests/x86_emulator/testcase.mk >> @@ -4,6 +4,8 @@ include $(XEN_ROOT)/tools/Rules.mk >> >> $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) >> >> +$(call cc-option-add,CFLAGS,CC,-fno-stack-protector) > > Is use of cc-option-add really necessary throughout here, when ... > >> --- a/xen/Makefile >> +++ b/xen/Makefile >> @@ -432,6 +432,8 @@ else >> CFLAGS_UBSAN := >> endif >> >> +CFLAGS += -fno-stack-protector > > ... is isn't needed here? Iirc the compiler version ranges supported don't > vary between components. Then again afaics $(EMBEDDED_EXTRA_CFLAGS) is used > by x86 only right now, and with cc-options-add, so perhaps it (a) needs > using cc-options-add here, too, and (b) it wants explaining why this needs > generalizing from x86 to all architectures. Quite possibly hypervisor use > of $(EMBEDDED_EXTRA_CFLAGS) may want generalizing separately, up front? Correction: Except for PPC all architectures consume $(EMBEDDED_EXTRA_CFLAGS) right now. So the moving is less of a generalization than I first thought. I still need to get used to passing -R (rather than -r) to grep, to find all instances I'm after ... Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 11:37:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 11:37:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846567.1261734 (Exim 4.92) (envelope-from ) id 1tI4kN-0003ZS-KF; Mon, 02 Dec 2024 11:37:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846567.1261734; Mon, 02 Dec 2024 11: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 1tI4kN-0003ZL-HB; Mon, 02 Dec 2024 11:37:47 +0000 Received: by outflank-mailman (input) for mailman id 846567; Mon, 02 Dec 2024 11:37: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 1tI4kM-0003ZF-7z for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 11:37:46 +0000 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [2a00:1450:4864:20::634]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d8153ec3-b0a1-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 12:37:43 +0100 (CET) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-aa5b0d8bd41so481542266b.2 for ; Mon, 02 Dec 2024 03:37:43 -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 a640c23a62f3a-aa5996c19e4sm498515666b.6.2024.12.02.03.37.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 03:37: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: d8153ec3-b0a1-11ef-a0d2-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo2MzQiLCJoZWxvIjoibWFpbC1lajEteDYzNC5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6ImQ4MTUzZWMzLWIwYTEtMTFlZi1hMGQyLThiZTBkYWMzMDJiMCIsInRzIjoxNzMzMTM5NDYzLjU4MTgwOSwic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733139463; x=1733744263; 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=GjxuSy+YvMaH29RWgfUAV0MhXCaTgb3PMGWtIgTsvVo=; b=d3Zf2FmLg8SY2I82i+kkd3fnib2OZuxDYmLGxi+WLCgQm3nX5WzSNScMVtQwxy6tYo tBfvtwf4PUStl+8bP9PzLm4D+ms82mDROyfQcJRC96hBxjiZxM7fTZmqblc7F3n5/syN HNo6jCwDsm99uhVZdPNy0oSD8IKk2Bot469LQDBzSkQ9vCEfi3GAcZdMTfksgA6ZL6Ir C8pPoFB57DstIme0ViO1fsbjCA0wGqngVOfd52QdyMju/UYD2NdJrtV3FjemHReQE16W 7rUG8NX36y1hRJyTKIueUvH1e5QTdrZVefHB9DMglAhU2EAUU2Yim2ena94mT0XpnQeG fTKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733139463; x=1733744263; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=GjxuSy+YvMaH29RWgfUAV0MhXCaTgb3PMGWtIgTsvVo=; b=JJmjJIxwHHLyDvkHRx7XlvqRyqDMdYChlRvCnFOnOww7mNAbWtSLCMXDXuNu3YLq3F 74spZJnRPM4DILqvp8zR4M2x+Komm4vV7JuMZsKO/kSHC3c1xuyXfYxoVjXlMdyHos/h 8P0Ax0Vt1ozKhEVX045vQIzFZh7z47Q6TybF0VFLqagI2h7U7aJmxK+3LGyINRg0Lpdx u7WuP9jcdSINd7SDbGispWH2z78qYelYX9paSQkW43hsBB1URkjKDs+7kd89ORmHbBEp trvaAYB/Oe9QkYkOZPhyFKFCsIf5WKc3CUI7C754M1/jrRI9JJjQSkalOuzCQtFmwtXq gnOg== X-Forwarded-Encrypted: i=1; AJvYcCXKJx5289pfKyff1OzTHREbDvV2VS0+pQ9+emKHWKN/iXC6591dgAq+LQSreTcByrOO5kpsxmM+PrE=@lists.xenproject.org X-Gm-Message-State: AOJu0YxCQK5brQb+hWbCmlONKP5XoSFbob0U14dCc1x+OagP9l9GYnu/ JhSdYtp4IfLAKsUtdgq2vGY3xYcWcOgEWrSTY5xu2VRMrCHzZwF78AhKX/F7/Q== X-Gm-Gg: ASbGnct7C2Z65GiOuhntCVI419Od/LaN5duqF6tStI3R7zUXqeyIGyZyBPvGT0p1TEO jVehHz+hhkWweK0jtaDU5O0XDnMmWQb00zxfMjSgFmNWEiCMQmzo6ZjIv7l+XLVQWhw3znYutXH zGfKp7HoqkF3GYnRp0G7uE0FdlyQ1ZqJ+eAd4drVUg9o/F3O1lk5jrrUC1WAo4w5qsvaJdjjxq/ pB/Tnx5sfqJz4NY5AojbyH6yFtYR445LCS5mF8uNUoyJiNHML+NC+06xy8XUZjHW33uPT2GMsKz nLdunQ55SK/dBFXjvryld0DCdLpSSoEivzc= X-Google-Smtp-Source: AGHT+IGwWgGP1ISgsJUe3TTbnNTysw/3gMlqVeigeNzAmSS7//7zn0sZqGn+hOz0ou9pTnwmYrX+wg== X-Received: by 2002:a17:907:7856:b0:aa5:27a8:4cbc with SMTP id a640c23a62f3a-aa580f266c6mr1954870266b.15.1733139462860; Mon, 02 Dec 2024 03:37:42 -0800 (PST) Message-ID: Date: Mon, 2 Dec 2024 12:37:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 07/15] x86/hyperlaunch: initial support for hyperlaunch device tree To: "Daniel P. Smith" Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com, stefano.stabellini@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241123182044.30687-1-dpsmith@apertussolutions.com> <20241123182044.30687-8-dpsmith@apertussolutions.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: <20241123182044.30687-8-dpsmith@apertussolutions.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.11.2024 19:20, Daniel P. Smith wrote: > Add the ability to detect both a formal hyperlaunch device tree or a dom0less > device tree. If the hyperlaunch device tree is found, then count the number of > domain entries, reporting if more than one is found. "reporting" reads like informational logging, when comment and printk() in walk_hyperlaunch_fdt() indicate this is actually an error (for now). > --- a/xen/arch/x86/domain_builder/fdt.c > +++ b/xen/arch/x86/domain_builder/fdt.c > @@ -14,14 +14,76 @@ > > #include "fdt.h" > > +static int __init find_hyperlaunch_node(void *fdt) > +{ > + int hv_node = fdt_path_offset(fdt, "/chosen/hypervisor"); > + if ( hv_node >= 0 ) Nit: Blank line between declaration(s) and statement(s) please (also elsewhere). > --- a/xen/arch/x86/domain_builder/fdt.h > +++ b/xen/arch/x86/domain_builder/fdt.h > @@ -11,11 +11,16 @@ > > #ifdef CONFIG_DOMAIN_BUILDER > int has_hyperlaunch_fdt(struct boot_info *bi); > +int walk_hyperlaunch_fdt(struct boot_info *bi); > #else > static inline int __init has_hyperlaunch_fdt(struct boot_info *bi) > { > return -EINVAL; > } > +static int __init walk_hyperlaunch_fdt(struct boot_info *bi) inline? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 11:53:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 11:53:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846601.1261756 (Exim 4.92) (envelope-from ) id 1tI4zS-0006jj-5V; Mon, 02 Dec 2024 11:53:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846601.1261756; Mon, 02 Dec 2024 11:53: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 1tI4zS-0006jc-1Z; Mon, 02 Dec 2024 11:53:22 +0000 Received: by outflank-mailman (input) for mailman id 846601; Mon, 02 Dec 2024 11:53: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 1tI4zQ-0006jW-Lc for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 11:53:20 +0000 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [2a00:1450:4864:20::62b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0496534d-b0a4-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 12:53:17 +0100 (CET) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-aa5b0d8bd41so483578166b.2 for ; Mon, 02 Dec 2024 03:53: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 a640c23a62f3a-aa5998e6a4csm506173866b.106.2024.12.02.03.53.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 03:53: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: 0496534d-b0a4-11ef-a0d2-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo2MmIiLCJoZWxvIjoibWFpbC1lajEteDYyYi5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjA0OTY1MzRkLWIwYTQtMTFlZi1hMGQyLThiZTBkYWMzMDJiMCIsInRzIjoxNzMzMTQwMzk3LjMxNDg1OSwic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733140396; x=1733745196; 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=5DoJVkRDl7xqQfr3XVSjHuo8s60t3A5HPd+qP0iUR2M=; b=Ph0XTUPt9AUR8w8z8LXWGegtDGwsNsqj9GBjp0ahnaLLEAyAx6FLTIwQ9lXesfOztA LKf21ybY4KgVODmRY4/1QxA9LR2StRH/rFS/e793U6smHCdjPrIGeWYHr0YF7lxq3/Db ZiYLOOVj7g8FPfpokhwheA3yTjj/Iu/rP6RbJrVICiE7r7lwMLA1H0Qsh6PS6LqTQLM1 xHJ4IQx1aNZLELM6y8ZNgormw8aBGk9ih4qOckQmkwucc0DxNWSuV4Q3ynnoWcVuim6Q D4rV5cUdKyHdrbvTgJIeaIlJctftU8JTNIJsgvjhdPlKgJc4cDahY/wKuUeP6vSKCBMw 82vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733140396; x=1733745196; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5DoJVkRDl7xqQfr3XVSjHuo8s60t3A5HPd+qP0iUR2M=; b=byiNrKew2MYRjcJliJ659SsnVQ+4yxSLi3EnJfRtTJXgiPQD4AR5ioQDFD6fQZBYw/ 3E04/fup7ELqe4QgnF32H+zHU6+uIn/KesBfqfBLupyfsJ/7gWKPdU+S0xIiRZX8vhTF mxsN5ElYh39YC6dXl7lyM/3WmzoJrwhPT2zi3QwNXmNwk9dVJefmlF/efxI4LfzW+P/r dnQnzPVgT5DDjj3Fas+sdbLaZkZbPmgjjKlouq9gk0a1r52k+7WaQFzbVwnJQ6ItebHV t0j9Qd+ubc3PfZib1N0UCUzLTnQnhDAjTquMX6tYo5Ma5ipF6UD4ohnM12qNmUXE7sEA CXIw== X-Forwarded-Encrypted: i=1; AJvYcCUNTYzGqau10JiynPM4JiwWYNtZwvucZpJqYg21h2cjF18mdIUwA8yGMmzxN9sUKAOkvnXP8H74138=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw7AJY0bp1qs108VeVlPXx9jDfa1sewvCWcI1+8m4tAFjceY8kB CfE98OfsLXu+YAk1k6LFZDp2cW1z8Mdqp6MexGXZmui2N3BJf9q1GXYg8Qh58g== X-Gm-Gg: ASbGnctaLSVSpuiu2WveB3Vv8r9SORnAeYjW8EZsXtWtDwPWtAOFKUQcWk8EyV46Kio qy8bXqDJtWZVKd38TJJQdy+IaiBdHvpbi3xpfik6jXtCVgFNa87jiT4m3PlFMVk2+Fra56W+xOI ihD0tF775yW5EwoKJBT1y//KOqknpllKGlq9Slmp8dzwmCQnh1mRR5/uvQdatqYSe549wQFxpSn KME4NpYHvi7iVJMd683PWg1rrWEuBPd8R2+1QYWrIyr119Gbz+m6rWAY6nhw/pjczsaqNJ6Gcuf uHWUgQZNoH0lC1A5i56HSghkc9dHOxTOkao= X-Google-Smtp-Source: AGHT+IEZqItffRhnEE3Z99JLOePc9SGQCNLZJThczJcrs8fxacPAWKXR4tL2LSp7bTQ8l3GVRfdsGw== X-Received: by 2002:a17:906:1bb1:b0:a9a:1739:91e9 with SMTP id a640c23a62f3a-aa580f26c3bmr1864896366b.24.1733140396515; Mon, 02 Dec 2024 03:53:16 -0800 (PST) Message-ID: <91e6d4e7-b4ff-4e13-8814-95eaac891cf4@suse.com> Date: Mon, 2 Dec 2024 12:53:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 08/15] x86/hyperlaunch: locate dom0 kernel with hyperlaunch To: "Daniel P. Smith" Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com, stefano.stabellini@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241123182044.30687-1-dpsmith@apertussolutions.com> <20241123182044.30687-9-dpsmith@apertussolutions.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: <20241123182044.30687-9-dpsmith@apertussolutions.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.11.2024 19:20, Daniel P. Smith wrote: > Look for a subnode of type `multiboot,kernel` within a domain node. If found, > process the reg property for the MB1 module index. If the bootargs property is > present and there was not an MB1 string, then use the command line from the > device tree definition. Why specifically MB1? > --- a/xen/arch/x86/domain_builder/core.c > +++ b/xen/arch/x86/domain_builder/core.c > @@ -56,6 +56,18 @@ void __init builder_init(struct boot_info *bi) > > printk(XENLOG_INFO " Number of domains: %d\n", bi->nr_domains); > } > + else > + { > + int i; Plain int when ... > + /* Find first unknown boot module to use as Dom0 kernel */ > + printk("Falling back to using first boot module as dom0\n"); > + i = first_boot_module_index(bi, BOOTMOD_UNKNOWN); > + bi->mods[i].type = BOOTMOD_KERNEL; > + bi->domains[0].kernel = &bi->mods[i]; > + bi->nr_domains = 1; > + } ... it's used as array index (and there's no check for the function return value being negative)? > --- a/xen/arch/x86/domain_builder/fdt.c > +++ b/xen/arch/x86/domain_builder/fdt.c > @@ -14,6 +14,122 @@ > > #include "fdt.h" > > +static inline int __init fdt_get_prop_as_reg( What does "reg" stand for here? > + const void *fdt, int node, const char *name, unsigned int ssize, > + unsigned int asize, uint64_t *size, uint64_t *addr) > +{ > + int ret; > + const struct fdt_property *prop; > + fdt32_t *cell; > + > + /* FDT spec max size is 4 (128bit int), but largest arch int size is 64 */ > + if ( ssize > 2 || asize > 2 ) > + return -EINVAL; > + > + prop = fdt_get_property(fdt, node, name, &ret); > + if ( !prop || ret < sizeof(u32) ) > + return ret < 0 ? ret : -EINVAL; > + > + /* read address field */ > + cell = (fdt32_t *)prop->data; > + > + if ( asize == 1 ) > + { > + uint32_t val; > + fdt_cell_as_u32(cell, &val); > + *addr = (uint64_t)val; No need for a cast here nor ... > + } > + else > + fdt_cell_as_u64(cell, addr); > + > + /* read size field */ > + cell += asize; > + > + if ( ssize == 1 ) > + { > + uint32_t val; > + fdt_cell_as_u32(cell, &val); > + *size = (uint64_t)val; ... here? > + } > + else > + fdt_cell_as_u64(cell, size); > + > + return 0; > +} This whole function reads very much like a library one. Does it really need adding here, rather than to the FDT library code we already have? In any event there's nothing x86-specific about it, afaics. > +static int __init dom0less_module_node( > + void *fdt, int node, int size_size, int address_size) Three times plain int, when ... > +{ > + uint64_t size, addr; > + int ret = fdt_get_prop_as_reg(fdt, node, "reg", size_size, address_size, ... two get converted to unsigned int in the course of the function call here? > + &size, &addr); > + /* An FDT error value may have been returned, translate to -EINVAL */ > + if ( ret < 0 ) > + return -EINVAL; > + > + if ( size != 0 ) > + return -EOPNOTSUPP; Not knowing much about DT: What does 0 represent here? > + if ( addr > MAX_NR_BOOTMODS ) > + return -ERANGE; > + > + /* > + * MAX_NR_BOOTMODS cannot exceed the max for MB1, represented by a u32, > + * thus the cast down to a u32 will be safe due to the prior check. > + */ > + return (int)addr; Comment and cast contradict one another. DYM u32 (really: uint32_t), or plain int? If you mean to return a plain int (for the sake of the -errno values further up), MAX_NR_BOOTMODS needs to stay below 2**31. > +static int __init process_domain_node( > + struct boot_info *bi, void *fdt, int dom_node) > +{ > + int node; > + struct boot_domain *bd = &bi->domains[bi->nr_domains]; > + const char *name = fdt_get_name(fdt, dom_node, NULL); > + int address_size = fdt_address_cells(fdt, dom_node); > + int size_size = fdt_size_cells(fdt, dom_node); > + > + if ( address_size < 0 || size_size < 0 ) > + { > + printk(" failed processing #address or #size for domain %s)\n", > + name == NULL ? "unknown" : name); > + return -EINVAL; > + } > + > + fdt_for_each_subnode(node, fdt, dom_node) > + { > + if ( fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 ) > + { > + int idx = dom0less_module_node(fdt, node, size_size, address_size); > + if ( idx < 0 ) > + { > + printk(" failed processing kernel module for domain %s)\n", > + name == NULL ? "unknown" : name); > + return idx; > + } > + > + if ( idx > bi->nr_modules ) > + { > + printk(" invalid kernel module index for domain node (%d)\n", > + bi->nr_domains); > + return -EINVAL; > + } > + > + printk(" kernel: boot module %d\n", idx); > + bi->mods[idx].type = BOOTMOD_KERNEL; > + bd->kernel = &bi->mods[idx]; > + } > + } What if you find two? > --- a/xen/arch/x86/domain_builder/fdt.h > +++ b/xen/arch/x86/domain_builder/fdt.h > @@ -3,6 +3,7 @@ > #define __XEN_X86_FDT_H__ > > #include > +#include > > #include > > @@ -10,6 +11,22 @@ > #define HYPERLAUNCH_MODULE_IDX 0 > > #ifdef CONFIG_DOMAIN_BUILDER > + > +static inline int __init fdt_cell_as_u32(const fdt32_t *cell, uint32_t *val) > +{ > + *val = fdt32_to_cpu(*cell); > + > + return 0; > +} > + > +static inline int __init fdt_cell_as_u64(const fdt32_t *cell, uint64_t *val) > +{ > + *val = ((uint64_t)fdt32_to_cpu(cell[0]) << 32) | > + (uint64_t)fdt32_to_cpu(cell[1]); > + > + return 0; > +} Basic library routines again? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 12:00:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 12:00:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846613.1261766 (Exim 4.92) (envelope-from ) id 1tI56G-0008KS-V3; Mon, 02 Dec 2024 12:00:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846613.1261766; Mon, 02 Dec 2024 12:00: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 1tI56G-0008KL-SB; Mon, 02 Dec 2024 12:00:24 +0000 Received: by outflank-mailman (input) for mailman id 846613; Mon, 02 Dec 2024 12:00: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 1tI56E-0008KB-Uz for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 12:00:22 +0000 Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [2a00:1450:4864:20::42c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 00c392a8-b0a5-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 13:00:20 +0100 (CET) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-385e25c5d75so1432099f8f.1 for ; Mon, 02 Dec 2024 04:00:20 -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-385f8448d32sm824502f8f.96.2024.12.02.04.00.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 04:00:18 -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: 00c392a8-b0a5-11ef-a0d2-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo0MmMiLCJoZWxvIjoibWFpbC13cjEteDQyYy5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjAwYzM5MmE4LWIwYTUtMTFlZi1hMGQyLThiZTBkYWMzMDJiMCIsInRzIjoxNzMzMTQwODIwLjI4Mzk0NCwic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733140819; x=1733745619; 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=4b96tTSo18/UJ5vXpie39GiiFQDkPf0RfaBo0sXQzKE=; b=PmmFNDU30Z/ig/hwEWDZYDft5mO6W8YzNEVnRI0GR0t+CdLJ5nkrir89StuJx7c6pN G6ds4Dder7NfYttydjdZK7tWPM7nYakk0PsyNvX+jFykHmlfcmcJVziAP6mu7Qmj0pXO 7pKlSs8zVnNW8WrGTVtiNvShguKn9Yd0bcovpxBRXC78GPpOSkJxfB3BVrB3Vz+NXmCD m6xJ8j37dnxKl989qmOJD3gHRFV7QdMrzd0h+t1Qry9Z6mRQYbGvnf3hvM87N/PvyqQ/ PTY1u+4G4HQMNPF0fa26Ou8P1BV6r16s8bepVlIpl5uJoS/v+Y3ldqvdtdIBYU0TqLAq TkLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733140819; x=1733745619; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4b96tTSo18/UJ5vXpie39GiiFQDkPf0RfaBo0sXQzKE=; b=uWnE8nUOjJRl9MY2pL50kLmR5DuNg4D+d770Gr+Hiw5OTph/P0Ea1h4NVDXK8vNPid KZsXn5hiObRbotMPGBFLljYLOP5osn/784Z4tabSRXuVNmH/jVVPrOeJ0GbrhXKO8Ftg bxuic4RWN4cqhROejEqUdHVtVS9zgaEY1pGXhtZGN6iNqOH32OMPe1J3Nc5oKHH+tEA2 hIVLsYl7/SI0W7P4OeNeepm5/fLxReY+JOvLuJDLHeU4GyWMlguI8BoxOk5HeuQt6xGc OzoJHxuopMis6HmDTYO7sVGhhn+Upcgid6Ltm/8QVq0U6DbJRUhooNrqKOPX5kJpc59A 5/Cg== X-Forwarded-Encrypted: i=1; AJvYcCW0ylp+VRm7DSHXXcEC/75lvxY79bXYnazSiFcikeB4M6xschXs5gYw2fu2mtow52mXRaKvKfN5Bi8=@lists.xenproject.org X-Gm-Message-State: AOJu0YxhHjVAmAvuihUduu4zX8XTKY3rIUrWTjF/8IMK5vqDbDamd55w e2yjawzYnBvfS2E/XrB8Br47iUwFx4P2esFNSmRbrov0GJ4Ult+kuxCQKd43DQ== X-Gm-Gg: ASbGncsWw51ue2MLYmbs0dnevqQZGDpKY5hQh0rgF3u0bO9pRza+YLo4CdxJtZxVBQz fps/1YpCuwaBF8fyTxwXs7pSV6xR4CzleXXrlB6y52w7TUSRQDAEwyZxMMY0rp/3LY7BUrv3gjn Ln7u8piPGdqanvfYzurhyR3eQ5gjdZEGdZi/qNzR3bm+lBStV3r/jsR2lS+yQ2/S4xUSwvAXbTf AZnpcE6vxosgDbW1naecRt7OnMvk2FbJ1rpRU7XkNEpnqjoBctgDTXeL2sl3IoGbpIorKM5fN1A 08yy7yywIczjB3K2YXdobId7ju5i7B2Gus8= X-Google-Smtp-Source: AGHT+IFAy7vm/qZ68W05kBIAmoDwdHgtnv6bA9nn1qAC3gFO+DCF18Cuu2KyjmKkTX0U6TZNWVGKOg== X-Received: by 2002:a5d:6f09:0:b0:385:eecb:6f02 with SMTP id ffacd0b85a97d-385eecb7143mr4456149f8f.28.1733140819629; Mon, 02 Dec 2024 04:00:19 -0800 (PST) Message-ID: <4dbd5882-0724-4023-9c0e-43c82eba2b80@suse.com> Date: Mon, 2 Dec 2024 13:00:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 11/15] x86/hyperlaunch: add domain id parsing to domain config To: Jason Andryuk , "Daniel P. Smith" Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241123182044.30687-1-dpsmith@apertussolutions.com> <20241123182044.30687-12-dpsmith@apertussolutions.com> <99177823-38d9-4aca-af84-150ae6f37a25@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: <99177823-38d9-4aca-af84-150ae6f37a25@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.11.2024 00:45, Jason Andryuk wrote: > On 2024-11-23 13:20, Daniel P. Smith wrote: >> @@ -186,6 +209,12 @@ static int __init process_domain_node( >> return -EFAULT; >> } >> >> + if ( bd->domid == DOMID_INVALID ) >> + bd->domid = get_initial_domain_id(); >> + else >> + if ( bd->domid != get_initial_domain_id() ) > > single line "else if"? Yes. >> + printk(XENLOG_WARNING "WARN: unsuported booting not using initial domid\n"); > > "unsupported" > > Maybe "Booting without initial domid not supported"? Plus the line then wants splitting after XENLOG_WARNING. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 12:02:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 12:02:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846622.1261776 (Exim 4.92) (envelope-from ) id 1tI58T-0000iy-A1; Mon, 02 Dec 2024 12:02:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846622.1261776; Mon, 02 Dec 2024 12:02: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 1tI58T-0000ir-7E; Mon, 02 Dec 2024 12:02:41 +0000 Received: by outflank-mailman (input) for mailman id 846622; Mon, 02 Dec 2024 12:02: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 1tI58S-0000il-9T for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 12:02:40 +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 529a2a1a-b0a5-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 13:02:37 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-4349fb56260so35776335e9.3 for ; Mon, 02 Dec 2024 04:02:37 -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-385dd99504csm10333233f8f.85.2024.12.02.04.02.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 04:02: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: 529a2a1a-b0a5-11ef-a0d2-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjozMmUiLCJoZWxvIjoibWFpbC13bTEteDMyZS5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjUyOWEyYTFhLWIwYTUtMTFlZi1hMGQyLThiZTBkYWMzMDJiMCIsInRzIjoxNzMzMTQwOTU3LjU3MDE5Niwic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733140957; x=1733745757; 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=yYZblrAheqyANJS/2YXXWISZ98F4iN3X0U4SDz7Anus=; b=VQZQ7j+2yZgCsWSQxYEi3eega0UvSqECieSVDtzRpNgJHVtrMvhMQ6WT0bUwxgA5Am 0NLwAVy/BF7cj3UMo5uS6O85Hl1W8Ij2gQOPqA3wzV/s9HLyhrZcOGz0VxXMmmvsqBoY akgcQCJQbbIHMFsxVkyt0hgS+ZO09MAB/fJA+ZWKOV4TUKzxTVUMBI2iopTnTGjHsGIV 35K2sG6KOun70MmLS9mGsr5yMBEn1LEmE9ltlVHCHACv3FUGj4FFDOrGHJbtFVzlWEd1 l9TNSoOb+WIth5TwyoYHBqmF6QGug+dKLNmmFILTVLyMYGL2ksm39FylYMkiSh/mMHsC h6lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733140957; x=1733745757; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yYZblrAheqyANJS/2YXXWISZ98F4iN3X0U4SDz7Anus=; b=s9SKvOEdJl5d0pBHGcOyKYcA/MnC+sJGcIeHTiEUXSFZcDP35qmxBCNor6b/0mKl2R r8YDX+yo8z7bAZ7QsMPhFhcws5pVFT0/Gsr78b4kvYcn8wnUAyq7CRs2+Ea3uyESgLR8 RBRqe2WvQHUgBOGh/oX+KTEkNYKSp8lxtWUyc8sE4ylw7O19/oJ8Tuhbq7EFh5vvvLdj Gx4Kb4s0bLoHstr5YF7Lx5SDo5Rwk6yrO9hyDLnVULtJhE9U4nStf5lCOJrE201MBtqO rG3OiFU5945CYWTYvW0rHjZ3Q9GR8jPgbF0+5cQ05TwAA2aGhap2+5tYclC9aSePwcAp TZEw== X-Forwarded-Encrypted: i=1; AJvYcCXG1yWpfqWKZHY3QndXGyqOkpXWdWZg9tsdWFzHdL+3T5uplQY9SH/gXy/RfnEnG/B9Jrvi8lfdpVM=@lists.xenproject.org X-Gm-Message-State: AOJu0YxKC/1Ii3P/yz8Xc3BnRILGE/1sOe1+fAhfbZpOcNBd3swLzKS4 WeG87Gv5CYGoggFVM70SzC5lgB7Ld+afZTopq3qpf4J6oBGlc2n0RaHaYdT2VA== X-Gm-Gg: ASbGncupnWG/Kby4uR9hk9S5YsCHoa0pJiTXEGszNgZlAZ0MW1xOOfhBwPPwFh/14qr vQdt0dClIgu+Zr8b9FymVQ9Xpu1VSRQTgook2JoE5r1wE/GY5SCseWxv/ZOaemTEePbTf0Pz5cK A0CghT7jwjo/UhFTsHAhW8Lw00ttjHGhrz4edSLn2jFx2eZAJKQ7zbaV8NRN3U//2ZSw4ElyQgq IYa3/ON5JQuF9haXBeGZrOBVeJjlXXC2DY0VmY2ZRWLGJPaAYM2w2z7PU3GHTSnDzcKh6XcXaJd ecFJ7ThwkqTB5D1CXI8HqOE2du57W+8AgIA= X-Google-Smtp-Source: AGHT+IFiUOs2pvEvimK2zlxiSP7qFuaC067uLC9/xtuGhGasImd3ZXwfUCvMko3V0tahtCg8MGj8xA== X-Received: by 2002:a05:600c:1e03:b0:434:a805:1939 with SMTP id 5b1f17b1804b1-434a9e0a29amr175438035e9.33.1733140954037; Mon, 02 Dec 2024 04:02:34 -0800 (PST) Message-ID: <8a492a4d-cc9c-4756-8fb9-721626c295a6@suse.com> Date: Mon, 2 Dec 2024 13:02:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 11/15] x86/hyperlaunch: add domain id parsing to domain config To: "Daniel P. Smith" Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com, stefano.stabellini@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241123182044.30687-1-dpsmith@apertussolutions.com> <20241123182044.30687-12-dpsmith@apertussolutions.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: <20241123182044.30687-12-dpsmith@apertussolutions.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.11.2024 19:20, Daniel P. Smith wrote: > --- a/xen/arch/x86/domain_builder/fdt.h > +++ b/xen/arch/x86/domain_builder/fdt.h > @@ -27,6 +27,24 @@ static inline int __init fdt_cell_as_u64(const fdt32_t *cell, uint64_t *val) > return 0; > } > > +static inline int __init fdt_prop_as_u32( > + const struct fdt_property *prop, uint32_t *val) > +{ > + if ( !prop || fdt32_to_cpu(prop->len) < sizeof(u32) ) > + return -EINVAL; > + > + return fdt_cell_as_u32((fdt32_t *)prop->data, val); > +} > + > +static inline bool __init match_fdt_property( > + const void *fdt, const struct fdt_property *prop, const char *s) > +{ > + int slen, len = strlen(s); Plain int isn't quite appropriate for strlen()'s return. It doesn't strictly need to be size_t, but it should be at least unsigned int. > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -1020,7 +1020,8 @@ static struct domain *__init create_dom0(struct boot_info *bi) > dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu; > > /* Create initial domain. Not d0 for pvshim. */ > - bd->domid = get_initial_domain_id(); > + if ( bd->domid == DOMID_INVALID ) > + bd->domid = get_initial_domain_id(); Looks like the comment then wants to move, too. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 12:05:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 12:05:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846632.1261785 (Exim 4.92) (envelope-from ) id 1tI5Bb-0001J8-Nu; Mon, 02 Dec 2024 12:05:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846632.1261785; Mon, 02 Dec 2024 12:05: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 1tI5Bb-0001J1-Ks; Mon, 02 Dec 2024 12:05:55 +0000 Received: by outflank-mailman (input) for mailman id 846632; Mon, 02 Dec 2024 12:05: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 1tI5Ba-0001Iv-SS for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 12:05:54 +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 c5d2a490-b0a5-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 13:05:50 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-434a742481aso33404875e9.3 for ; Mon, 02 Dec 2024 04:05:50 -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-434b0d9bef8sm149534845e9.7.2024.12.02.04.05.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 04:05: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: c5d2a490-b0a5-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjozMmIiLCJoZWxvIjoibWFpbC13bTEteDMyYi5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6ImM1ZDJhNDkwLWIwYTUtMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTQxMTUwLjg4MzUyLCJzZW5kZXIiOiJqYmV1bGljaEBzdXNlLmNvbSIsInJlY2lwaWVudCI6Inhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZyJ9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733141150; x=1733745950; 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=vMfxcwDyeYhwaV3qN3UgSZfnc2TJWskP0eXG885FWlI=; b=Nl49V1R8gDL6U32z122pPCLvYQD/AyvzCjRqHs02/AhA3QAm8wZtL629nv8Z0DiD2N I4MBmIW3URp58rtljU95gE6AdT5FitXMwYpQR+OeVi7RGGa96srSt79Afywwp2qXio9I AVby0NSfzUyeSlxlDiENi8dB/eawnY3ctgmAsyBodHG0qKcctCCMuKuqZ0dZDrESGQu/ l2dXuMG4p5YXSf2KGb/R+AYwUAWMd62tOsCvFBHFTxYVngZvIOknw8amaxndBeSCQGcw 2LGw98u/F4aJ8jHDLHrzingt1XqEJjvj5WM54ZDXrGa0uxdMqTkazSw9fGOuFqFy0JPm 8ueQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733141150; x=1733745950; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vMfxcwDyeYhwaV3qN3UgSZfnc2TJWskP0eXG885FWlI=; b=NM4uMfoFkNaOo4xrC9iYm5BPAlELfnT8KFRXJbjiKB4KrjgPF8vEQ9RZ6LAhFjwR2X AfJKP7911H7LkzrO9Dg/awALyPImx0pVmTFmcWCSaBVoOUhro5qZH+/IoYNv8SU6Wexn vcbsjHLg5Cd1q+MV3kUX7vYDNXKLZ6hAcAkl5VuiJ9JALsDP/XDKNhaIqQSchZlKwN4D KSfeZCcwo25e7MVZHkEq1/JiXiacrHX1+KjjORRvr8CJp8ZPFkjnHKBThJOA+9TvN/4B lfDQQ68ufj90gzFq3tfjlwK6nuT/Ty219FyLCPZZKqLbiZ8UlWRyHzb/EB4+adeDuSZc uP8g== X-Forwarded-Encrypted: i=1; AJvYcCVYV9HxW070iKJnfQL+5XkMw7R3U5Du7XhEpGchWRXvW9tGEQHxmPxXYT8MGZum2u4QvCMkLDHyLAY=@lists.xenproject.org X-Gm-Message-State: AOJu0YxkBUrT99rwq3iIc/gfPsqEYTnEgs5A0NjIZtSGylMrCke9QqwN D87C1dRFVZsDku6IYwaccYmhwFVs1L9O0qgKlOXJC+8qwzJ+B66pDYd4pwYBlA== X-Gm-Gg: ASbGncvxx9SZlPMz6j6isQDpCjzKCGQ68CSP8+R1ak5WKLiHc3ghw6OAC3LqrDPukdU mnnlGtWkVkELMlIh63PK5o0DKCG9qPdnx+kOTzGqGkuIpwaTacT3m/DP/pLUQ9T61wrk5V4c205 Zbd5jRKmHCH/+dVlqiWNkkXoWYDVpcQiHBXlMCSPCNYSpVvGKflOnsSs/xgcoKbJgt2y/PA3QvM V2ARqXucp+Zk55z2qy1aWemJl2emcXDhuw+C3VhwHn+tTvQZfNQA1wKHYru0PM0jSv777hbNc1q 172YCOasV56OA6aAN8xAf0iU04refqSQVk0= X-Google-Smtp-Source: AGHT+IGvBOxuDcuUe0rQfPksQn85tsrl38dlno8agmnTthlvxnbJGjVHSemVS1VcFWLSoyi8c1nkqQ== X-Received: by 2002:a05:600c:3aca:b0:434:9e1d:7626 with SMTP id 5b1f17b1804b1-434a9df6a16mr187537915e9.25.1733141148788; Mon, 02 Dec 2024 04:05:48 -0800 (PST) Message-ID: <5dc478be-7b8a-4966-8889-d4d40bda8770@suse.com> Date: Mon, 2 Dec 2024 13:05:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 12/15] x86/hyperlaunch: specify dom0 mode with device tree To: "Daniel P. Smith" Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com, stefano.stabellini@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241123182044.30687-1-dpsmith@apertussolutions.com> <20241123182044.30687-13-dpsmith@apertussolutions.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: <20241123182044.30687-13-dpsmith@apertussolutions.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.11.2024 19:20, Daniel P. Smith wrote: > --- a/xen/arch/x86/domain_builder/fdt.c > +++ b/xen/arch/x86/domain_builder/fdt.c > @@ -141,6 +141,25 @@ static int __init process_domain_node( > bd->domid = (domid_t)val; > printk(" domid: %d\n", bd->domid); > } > + if ( match_fdt_property(fdt, prop, "mode" ) ) > + { > + if ( fdt_prop_as_u32(prop, &bd->mode) != 0 ) > + { > + printk(" failed processing mode for domain %s\n", > + name == NULL ? "unknown" : name); > + return -EINVAL; > + } > + > + printk(" mode: "); > + if ( !(bd->mode & BUILD_MODE_PARAVIRT) ) { Nit: Brace placement. > + if ( bd->mode & BUILD_MODE_ENABLE_DM ) > + printk("HVM\n"); > + else > + printk("PVH\n"); > + } > + else > + printk("PV\n"); > + } > } > > fdt_for_each_subnode(node, fdt, dom_node) > --- a/xen/arch/x86/include/asm/bootdomain.h > +++ b/xen/arch/x86/include/asm/bootdomain.h > @@ -18,6 +18,12 @@ struct boot_domain { > > domid_t domid; > > + /* On | Off */ > +#define BUILD_MODE_PARAVIRT (1 << 0) /* PV | PVH/HVM */ > +#define BUILD_MODE_ENABLE_DM (1 << 1) /* HVM | PVH */ > +#define BUILD_MODE_LONG (1 << 2) /* 64 BIT | 32 BIT */ This last one isn't used anywhere, is it? > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -1006,7 +1006,8 @@ static struct domain *__init create_dom0(struct boot_info *bi) > struct boot_domain *bd = &bi->domains[0]; > struct domain *d; > > - if ( opt_dom0_pvh ) > + if ( opt_dom0_pvh || > + (bi->hyperlaunch_enabled && !(bd->mode & BUILD_MODE_PARAVIRT)) ) > { > dom0_cfg.flags |= (XEN_DOMCTL_CDF_hvm | > ((hvm_hap_supported() && !opt_dom0_shadow) ? What about BUILD_MODE_ENABLE_DM? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 12:07:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 12:07:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846644.1261799 (Exim 4.92) (envelope-from ) id 1tI5Cl-0001su-2B; Mon, 02 Dec 2024 12:07:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846644.1261799; Mon, 02 Dec 2024 12:07:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tI5Ck-0001sn-Ve; Mon, 02 Dec 2024 12:07:06 +0000 Received: by outflank-mailman (input) for mailman id 846644; Mon, 02 Dec 2024 12:07: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 1tI5Cj-0001s6-Ct for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 12:07:05 +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 f01b41a8-b0a5-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 13:07:01 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-434b3e32e9dso34935955e9.2 for ; Mon, 02 Dec 2024 04:07: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-434aa7e4c89sm179889225e9.41.2024.12.02.04.06.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 04:06:56 -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: f01b41a8-b0a5-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjozMzMiLCJoZWxvIjoibWFpbC13bTEteDMzMy5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6ImYwMWI0MWE4LWIwYTUtMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTQxMjIxLjgzODcwNCwic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733141221; x=1733746021; 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=2XWbVDXXoKXFVWcVjCzrVq3eYC2j9nnlFwtt9jS+5h4=; b=Cs08ad7Mcga6l7nmuRjBfQe/qEP6WDNlz4+kPGqRUwtSsO7HpZGaDLbO0phqiOf5pw K8jq3SIWkwtg5r5hHv+F8op0SAj/KX+w3Oryx0QeHeiD9gBISbR6GIyXaedP2TrRabAj emxN2411LFvAbWAv2jMhNlGdPq/BqvnOCLOzC1Me5IugSBbWiDlSDQOw88FXJNuxRPS3 RWkMvSBSsLR2x2HthaGIXcB5N0Ww/+0EP5TIkiB9Aj+q23DB3j0+PScmmua+Jq/6Isw8 IAdVVCQs6G69xzIFZ19Qxjn9r/hPZJgIo7+RuYsSUbnS7PzPdwC6wiHoVQONM35c1EvM 6a6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733141221; x=1733746021; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2XWbVDXXoKXFVWcVjCzrVq3eYC2j9nnlFwtt9jS+5h4=; b=w6FOIwfyUYVTfA1FqgXQCdLBoEv2M0YsKxFmh6KdSlRN2dZJqoPhiE7fBjr0AV1BfZ 5VgIcDvkX3s2hwA3hbJDdny0+Fm6e+g15FFKrBwbWgCqXsuVhuHlYXRtaGF63b+NZW3U yy7bD2jWY7VY34AA3+wZTZfDh+xYLUiHD0vBGy08XUR0h4b65piuyexMALYt/Eteh5EY wqD6aUEcFXQr2qDZcPXxYsD+HgCluCFBk13TPuYJR2UAF+wr8QWMEFUS0hiVk4DqHZny VLv7TlZR3MWnlS372ZsJSuT99UkfK7Z2/89PNy1WuAf0Seksp4M8V62h1Yn5CaT/i39L jYIg== X-Forwarded-Encrypted: i=1; AJvYcCUgJDZqmy4V5ZzTrI7lRjMgtKoGzJXsofgLAnVdfIxslW8rPJjTHzSwq0UZKinx/U7rXI3DtBWnvWE=@lists.xenproject.org X-Gm-Message-State: AOJu0YzY30WDOIIrEvwfPyCRJZ38kV38OFc6iZnGsQetLApfXva+yc7A hxZ6w8mn3hGkcE7uCdcxomVE5Hr9Tha4MQ9R7wA6SjV4YzZ1s5XeNxd8Obg3Og== X-Gm-Gg: ASbGncvlJ6zaSjOhpPnVMI0vjfxvAvwddZEhBWJeJ0Y7jE7WzduTug0x3muUUIe6Qbj r0f35iCQqmdWmIFdv+k26s7rZoRj0wkMPv9v82xahANgDw5tpvoKvwtN3h4P1SiNhpDIH9NpklC pZ4/SpHfVxpHiEM5Vdow3FIJ9CwjTGWXSb8ZcwJhQwrILYSpokKq81CGMLdAW27Nk9dHiHGuK7Y dvdrfwYkM2qq4MnKvStCDmuwvcYydAX97G39u2rzEHP4ysJXrzZNrgpS/oCfQeqRkd8ABKacYyD sYqWCIcUSzHG3KHL8nZokmxOQomUcMD3Rz4= X-Google-Smtp-Source: AGHT+IH+gXGOIVE4T3wrfxXJjuxzgSMdvBgZh8bT/72xJ1hKVJFZmghsLQ2AG5sDhJAKL9iWLK14VA== X-Received: by 2002:a05:600c:4f12:b0:432:cbe5:4f09 with SMTP id 5b1f17b1804b1-434a9db8171mr214601175e9.4.1733141217186; Mon, 02 Dec 2024 04:06:57 -0800 (PST) Message-ID: <294035fd-45c9-4c59-a5b7-bc1ebed90e47@suse.com> Date: Mon, 2 Dec 2024 13:06:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 12/15] x86/hyperlaunch: specify dom0 mode with device tree To: "Daniel P. Smith" Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com, stefano.stabellini@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241123182044.30687-1-dpsmith@apertussolutions.com> <20241123182044.30687-13-dpsmith@apertussolutions.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: <20241123182044.30687-13-dpsmith@apertussolutions.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.11.2024 19:20, Daniel P. Smith wrote: > --- a/xen/arch/x86/domain_builder/fdt.c > +++ b/xen/arch/x86/domain_builder/fdt.c > @@ -141,6 +141,25 @@ static int __init process_domain_node( > bd->domid = (domid_t)val; > printk(" domid: %d\n", bd->domid); > } > + if ( match_fdt_property(fdt, prop, "mode" ) ) > + { > + if ( fdt_prop_as_u32(prop, &bd->mode) != 0 ) > + { > + printk(" failed processing mode for domain %s\n", > + name == NULL ? "unknown" : name); > + return -EINVAL; > + } > + > + printk(" mode: "); > + if ( !(bd->mode & BUILD_MODE_PARAVIRT) ) { > + if ( bd->mode & BUILD_MODE_ENABLE_DM ) > + printk("HVM\n"); > + else > + printk("PVH\n"); > + } > + else > + printk("PV\n"); Oh, and: What about BUILD_MODE_ENABLE_DM also being set here? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 12:14:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 12:14:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846662.1261810 (Exim 4.92) (envelope-from ) id 1tI5KG-0003t5-V1; Mon, 02 Dec 2024 12:14:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846662.1261810; Mon, 02 Dec 2024 12:14:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tI5KG-0003sy-Rb; Mon, 02 Dec 2024 12:14:52 +0000 Received: by outflank-mailman (input) for mailman id 846662; Mon, 02 Dec 2024 12:14: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 1tI5KF-0003ss-Jj for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 12:14:51 +0000 Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [2a00:1450:4864:20::234]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 06615874-b0a7-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 13:14:48 +0100 (CET) Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-2ffbea0acc2so43736031fa.1 for ; Mon, 02 Dec 2024 04:14:48 -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 a640c23a62f3a-aa5996de56dsm504185666b.79.2024.12.02.04.14.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 04:14: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: 06615874-b0a7-11ef-a0d2-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjoyMzQiLCJoZWxvIjoibWFpbC1sajEteDIzNC5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjA2NjE1ODc0LWIwYTctMTFlZi1hMGQyLThiZTBkYWMzMDJiMCIsInRzIjoxNzMzMTQxNjg4LjU2NTc4MSwic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733141688; x=1733746488; 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=TYRdDXV7qCaW6xzUCDhQhNzZqubZov0EV3e88I7YnC8=; b=DHA5or1Rk0iRhifljw1/mJx8IDO/WPiiH98zi0wA6ybEjDo3xM6c0dy8iP7qBmQgoX OtZzG5gsoV1OpSNYh0jQBYHY8oZAJbjHVd5ActEd3279/AkVIWOfusEk4pLqFtNBM/Vl ClUriak4OTZMqPzOM4vBBEcMWy2lT3pr2xc5dWAKWxrT7AgGM1V9o/1b1J1x4Ukkm1+R 0f79laerY2Pci2VwpJXIqftCSd69cS6aMI2FeVIo7NRl6iPhiWsazW5wp06RMnxn6z9H hHACiWu8IbOUzj5ikEZALmFZ1rADgaQJzM0xxf1enOZ8qdsQvwGf1DmYL4uPNft89jrb 9LSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733141688; x=1733746488; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=TYRdDXV7qCaW6xzUCDhQhNzZqubZov0EV3e88I7YnC8=; b=jgfuukZsqhgdJUSBpLRkrW6ZZ6bIrVwaQcGT3OJKcMVDDQKSsMVRKteFnZ/aRT/Dcp Q4FrMztq8VyCOemHhxjau1Pr/9nqvP7QzyPs5YR5hw53vrzKWzooUieWzo2xGMhXdNFB r4XJpXeATU8+A4GhWIyMnq+tcxuvv/bLp/mBYWR3vTX1wr4ItrHk9gJtwkV577COsJIH cSAXWq0xVyuF8ielSOL31628omSa0kPEPtuz78MhXzUtAid70bkziz2B65eOfpnycbzG 9yoBesTMvSstfDfuSXtqezkFKMVSr4JJxm/mcpR6cdsQNx6k+kp2a8vL6pMC4oVSiyNM 7jgg== X-Forwarded-Encrypted: i=1; AJvYcCUk7vDujlhY1JapzGFIDk2IbuPT70Kqa4eghGAW3o2NEjtOuq4ASuJ3SenOppIohUTEi75FgJ5PdVo=@lists.xenproject.org X-Gm-Message-State: AOJu0YzmhWkB067dhYpZ9z6NnY0VMCC7+ubP7469BHOyCjW7nDwkMCu6 EuMLdbhCVS2lHF9X3RfmE/JagIf2FXos6DX/i2F+OSSHJqZrR0MSj1SF+wHD6Q== X-Gm-Gg: ASbGncs5y0YJLcIdDbLjz4uaTw87ibGP2w7NgirtINb7iQoSdpf7gWbMN0Djkpdyj8y 6qxaOQNBmnGYn+B3D6bNlORAuVfrz/2xNZDiO8tjyhEteFvgP9QHChA79f3HjZ4N6C9WsAfK3Gf kowuiKCuD6zd4oup6poe0vk5TwYFmejhOAxxGps1/d9ymKBZC4zoSnx6GjimToq+5W0RW2SBK51 ZciKVt5X3FMlBXYTAPWEbK8Iv8GUYyHOv8XE2FxNLKPA/aRxrmor7jjx9Ls5xya5LVQQzmjGd79 AQtKSzQG3qCfrORvRtMEjqrAnp4hUGllpts= X-Google-Smtp-Source: AGHT+IHM2wKF2NLv8qB5Oo2bVJWWDU5HhAbJMNoKxux67IOb0AWXjm+AQmEaapmR5GOII+kYFC7f9g== X-Received: by 2002:a05:6512:3d26:b0:53d:ed26:344b with SMTP id 2adb3069b0e04-53df00a97b4mr12765197e87.7.1733141687983; Mon, 02 Dec 2024 04:14:47 -0800 (PST) Message-ID: Date: Mon, 2 Dec 2024 13:14:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 13/15] x86/hyperlaunch: add memory parsing to domain config To: "Daniel P. Smith" Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com, stefano.stabellini@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241123182044.30687-1-dpsmith@apertussolutions.com> <20241123182044.30687-14-dpsmith@apertussolutions.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: <20241123182044.30687-14-dpsmith@apertussolutions.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.11.2024 19:20, Daniel P. Smith wrote: > @@ -160,6 +161,42 @@ static int __init process_domain_node( > else > printk("PV\n"); > } > + if ( match_fdt_property(fdt, prop, "memory" ) ) > + { > + uint64_t kb; > + if ( fdt_prop_as_u64(prop, &kb) != 0 ) > + { > + printk(" failed processing memory for domain %s\n", > + name == NULL ? "unknown" : name); > + return -EINVAL; > + } > + bd->mem_pages = PFN_DOWN(kb * SZ_1K); > + printk(" memory: %ld\n", bd->mem_pages << PAGE_SHIFT); > + } > + if ( match_fdt_property(fdt, prop, "mem-min" ) ) > + { > + uint64_t kb; > + if ( fdt_prop_as_u64(prop, &kb) != 0 ) > + { > + printk(" failed processing memory for domain %s\n", > + name == NULL ? "unknown" : name); > + return -EINVAL; > + } > + bd->min_pages = PFN_DOWN(kb * SZ_1K); > + printk(" min memory: %ld\n", bd->min_pages << PAGE_SHIFT); > + } > + if ( match_fdt_property(fdt, prop, "mem-max" ) ) > + { > + uint64_t kb; > + if ( fdt_prop_as_u64(prop, &kb) != 0 ) > + { > + printk(" failed processing memory for domain %s\n", > + name == NULL ? "unknown" : name); > + return -EINVAL; > + } > + bd->max_pages = PFN_DOWN(kb * SZ_1K); > + printk(" max memory: %ld\n", bd->max_pages << PAGE_SHIFT); > + } Since the values logged are all multiples of 1k, why make reading the logs more complicated by logging byte-granular values? I instead wonder whether converting to more coarse grained values (leaving, say, between 4 and 6 significant digits while using kb, Mb, Gb, etc) wouldn't be yet better. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 12:19:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 12:19:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846672.1261820 (Exim 4.92) (envelope-from ) id 1tI5P5-0004Tr-Fv; Mon, 02 Dec 2024 12:19:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846672.1261820; Mon, 02 Dec 2024 12:19:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tI5P5-0004Tk-C9; Mon, 02 Dec 2024 12:19:51 +0000 Received: by outflank-mailman (input) for mailman id 846672; Mon, 02 Dec 2024 12:19: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 1tI5P3-0004TL-CP for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 12:19:49 +0000 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [2a00:1450:4864:20::534]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b7687e26-b0a7-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 13:19:45 +0100 (CET) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-5d0ac27b412so3616561a12.1 for ; Mon, 02 Dec 2024 04:19: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 a640c23a62f3a-aa5998e63a2sm502177566b.113.2024.12.02.04.19.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 04:19: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: b7687e26-b0a7-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo1MzQiLCJoZWxvIjoibWFpbC1lZDEteDUzNC5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6ImI3Njg3ZTI2LWIwYTctMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTQxOTg1LjY3MTY4Miwic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733141985; x=1733746785; 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=DbhVsuh4+pHZtocjf52LXiC3wejoUyITarBkXiQXtT0=; b=LKOtc+gCwFDNtId8AVvVFT2OY/OnUnIeifJ4bWlK/n3SR4Z0gZsGev6rOVuKgs1fCv DjCIPkGSUAZIHKAKNsbZ1A87griWKwMGeRhvYxxiLLHLUTf66+c1tqw5jRBjwkd0cHW7 +Vg2mJs/PFlML7t68yxWLykL+UIKuD5e81XaoK4xhd0/5ACGdtpkgDPg6PIlp3IhELCG wkBnBUL6Cw4AQWtprYcvRD6J/CKvMkSwpHdYXDHteIBuk4KZZ/6CzJnmx+iXuBCLEg9o IAr0XjqaDMO6RFYCtoQ0bezZQCA3jHxrXNt5B9jfQwe7rLyBtB3vmhJExmV+GbvKjRvY jTdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733141985; x=1733746785; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=DbhVsuh4+pHZtocjf52LXiC3wejoUyITarBkXiQXtT0=; b=R/mJJqcvJKPabH9EgymK/P1FBMP94E3HQN9oxd5NWw1/LT7hgCI0/IFr01PsFCH6L0 mKusSyIiNyt3vkrdFQ1s5Gd5hULO6mQcSdllJ6fuxCXOLv1ze/qZRheDSeUszDUqb501 DY2JgPOlV+d/RlhkYZpP4fpYsIICgwjULqqY/EiQya753AoNogefuAigVr5ahgzuq3Y4 KBJX5xBbVFJkrY7SJsX7iXF+Sk5s2OaHgftgun1uT5/E655ELgqg8dMRXTAfSjuZF6nK goPI4eL+YsZ/VMjMU7k++Oh+0K7/j5TEYK5PrQLudjnXQU7JComNPJfuVgtNTJ1W8OQu 8rWQ== X-Forwarded-Encrypted: i=1; AJvYcCXvkYOAf33qKBC2cMqyoHs8hJvDlWnT9zqbncRatWJfS6ZfawL31YchVjCtbgF13tJ01Z4l5LYeUSY=@lists.xenproject.org X-Gm-Message-State: AOJu0YzxzkwT94zz1fwe1WrJmjH00Owx0ZSXuv/SLJPUvGyvL6PPnJqP B1PZu9sakoGX6sKMhlvQnMChE3Cr0ylvbw6V7d5pAisqmt5uBL9sYCiwwxAH4Q== X-Gm-Gg: ASbGnctKhU8LlK74wOg5HmBIvEFe1dydMvA3ij8LloC8k5xnx3EPfPBrl7+MquywBZY rB+XMSZktAYfvhVciDy0VKs2XYFW/J4DspFwnk9wIjNpTkXA0d9/c0okuUjMOm+bDdT9bx0otpR AUFoY6GFelEcSonHWgNaIATTvLoAn8xay9mEYLNYCqtGaN0Up4AJ8vjfyF8QABBaUNqAH8jbm+9 BbHhmlguIqFeXwK09r52slod+yp8cvGcBT+xLcl5JT3bdhifxYOOGoqdmBWy+5OkNteWCtdzlv3 pxTbJe7v9mhle308q6F6Pez6YHvhxIegsbw= X-Google-Smtp-Source: AGHT+IHn+EXbWerfVcZvo0IWgtk/ZHUn+nk0l2dfFf5jn9LnMp9mftIDlqaDn1kIWzEN0YOrA/n9qw== X-Received: by 2002:a17:906:3152:b0:aa5:3663:64bf with SMTP id a640c23a62f3a-aa580edf9cdmr1991918566b.12.1733141985043; Mon, 02 Dec 2024 04:19:45 -0800 (PST) Message-ID: <88126e8c-96f8-4cb2-a899-eec2b800cf66@suse.com> Date: Mon, 2 Dec 2024 13:19:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 14/15] x86/hyperlaunch: add max vcpu parsing of hyperlaunch device tree To: "Daniel P. Smith" Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com, stefano.stabellini@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241123182044.30687-1-dpsmith@apertussolutions.com> <20241123182044.30687-15-dpsmith@apertussolutions.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: <20241123182044.30687-15-dpsmith@apertussolutions.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.11.2024 19:20, Daniel P. Smith wrote: > --- a/xen/arch/x86/dom0_build.c > +++ b/xen/arch/x86/dom0_build.c > @@ -617,6 +617,9 @@ int __init construct_dom0(struct boot_domain *bd) > if ( !get_memsize(&dom0_max_size, LONG_MAX) && bd->max_pages ) > dom0_size.nr_pages = bd->max_pages; > > + if ( opt_dom0_max_vcpus_max == UINT_MAX && bd->max_vcpus ) > + opt_dom0_max_vcpus_max = bd->max_vcpus; Isn't this kind of backwards? I.e. aren't you meaning to move us towards boot-domains? Also, what about the counterpart opt_dom0_max_vcpus_min? That wants to be controllable from DT too, I would think? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 12:23:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 12:23:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846681.1261830 (Exim 4.92) (envelope-from ) id 1tI5Sc-0006Q3-Uo; Mon, 02 Dec 2024 12:23:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846681.1261830; Mon, 02 Dec 2024 12:23:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tI5Sc-0006Pw-QP; Mon, 02 Dec 2024 12:23:30 +0000 Received: by outflank-mailman (input) for mailman id 846681; Mon, 02 Dec 2024 12:23:29 +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 1tI5Sb-0006Pj-Om for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 12:23:29 +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 3a35391b-b0a8-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 13:23:25 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-385e2880606so2447707f8f.3 for ; Mon, 02 Dec 2024 04:23: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-434aa7d264dsm181325935e9.33.2024.12.02.04.23.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 04:23: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: 3a35391b-b0a8-11ef-99a3-01e77a169b0f X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo0MzIiLCJoZWxvIjoibWFpbC13cjEteDQzMi5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjNhMzUzOTFiLWIwYTgtMTFlZi05OWEzLTAxZTc3YTE2OWIwZiIsInRzIjoxNzMzMTQyMjA1LjEzMzEwNSwic2VuZGVyIjoiamJldWxpY2hAc3VzZS5jb20iLCJyZWNpcGllbnQiOiJ4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcifQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733142204; x=1733747004; 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=UaZ+LuVNqAp3iogsGJTgclrSlHqSYqAZXBa2nsIVt+Q=; b=QnRRHbutJJJdoX0VE0YlOvw6jsSQXQ5QmlFKWJK9OtvQQAI/G88V20OrH0rcwZ8lov u2tEn0ImEjlKiJ3rcCrjv+yMAc/85MX1L8lSa7/w7HG2A170golhrsigMRPmQWRTnvPo jqQZ6lJ2iWzSBe7LEVkioIDwbMGOg6pCnCs9035u+5T6B/Q57e9BTNrLU/qe1K1iu6J3 cl/OGroCLAsurrkQOlRRgGA44FmxEpbgC+2FsL26cI/oY0OChZFjorXlSjlmZUciap8h FPYEx6gCU5+NNgpVC0ZEINaX0KRkdS+xxNPs86j/UTwmdK/C6xCTvwPhHlAYhP+ZF+dO KoXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733142204; x=1733747004; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=UaZ+LuVNqAp3iogsGJTgclrSlHqSYqAZXBa2nsIVt+Q=; b=rzxTEbRriseJdajdbRb316uyh0UXCLJcJeNIS48Jnk9gf88QuOB3dwxFKDvW8J3M0x VEHao6EdItvmKCzRgQzhPXED7Z8F4yhJGAp687XB0y5+SxjW+l7jEvziq0UgWlyo5RiI jBqBTSMPzVvYIaDEyseSjeZU0jIktjLh80KfhQdzGUFlgrRDZMxw+Na9TwykyTsmQQlF Jk5+VlauLr83w9/3/5ZmsqI2WuZxT1lESPv7igZslz0l3AiFKjdWo8f6N7gmnRqkEd3G TH4FHrv3mbPa6mzM4ndhy3f/AiLb1wd5LTDIxyvHqttw4zLUzNjTEnjlOcjzjUkCz7H+ ULXQ== X-Forwarded-Encrypted: i=1; AJvYcCUzOL4c2BNAYVO4bCdq72FcxG9ANr7abORDHJnMr0U2E9VYAX/n/BZb5d3soiRfXIoFSJZTgMQC+D0=@lists.xenproject.org X-Gm-Message-State: AOJu0Yws8c4tiBxcG2fXOpYA3NiDstzvFn9GY3nQOAlsIWo/vAOC9iJo Nhc5Gu7a5cCt69cam2SGnGX12QEnBZN+ULkGpXCLwAJEn9arSXF3sEroKNpbDQ== X-Gm-Gg: ASbGncsgOpi087gpJhe2kDoW+JEQInIbsg4kYv2Gvr2vsBx4+B3Cpgq8WHAMKXh/amz VY0yT7voXMM0erJlh4b3OZAdahHZjJWH449snYoKEcGWWHGoOZ6I8YrnwEQT4FpxENQiow3qWyC oCp0CHBNqRSINhkB4/2F9LzA/620tZcoIzZRoofT7ZvAMSe2xCwid5PTL8/sjIKp5pHGlpT8YrE Fm3UXMIRtK7PB6GnQSDjfF+roHzD518+2ZaeuUqoWmez+K1beE5sIU3mGNCUCX1wovn2nvoVk0/ C/USmGrUxhM1/0HOYZE+twzvTIeMKQ40VwI= X-Google-Smtp-Source: AGHT+IHrWLTZDpGGOxOpjfv7ZzbWQvUDo5LstWAMdyx95iabh5Lh0p8Ntv8iE0jZaePAtv0+EHJCoQ== X-Received: by 2002:a05:6000:1f8b:b0:385:e176:43e8 with SMTP id ffacd0b85a97d-385e17644c1mr13151066f8f.33.1733142204385; Mon, 02 Dec 2024 04:23:24 -0800 (PST) Message-ID: <84bc7854-7935-4f36-b574-d19dde775673@suse.com> Date: Mon, 2 Dec 2024 13:23:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 15/15] x86/hyperlaunch: add capabilities to boot domain To: "Daniel P. Smith" Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com, stefano.stabellini@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241123182044.30687-1-dpsmith@apertussolutions.com> <20241123182044.30687-16-dpsmith@apertussolutions.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: <20241123182044.30687-16-dpsmith@apertussolutions.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.11.2024 19:20, Daniel P. Smith wrote: > --- a/xen/arch/x86/domain_builder/fdt.c > +++ b/xen/arch/x86/domain_builder/fdt.c > @@ -209,6 +209,19 @@ static int __init process_domain_node( > bd->max_vcpus = val; > printk(" max vcpus: %d\n", bd->max_vcpus); > } > + if ( match_fdt_property(fdt, prop, "capabilities" ) ) > + { > + if ( fdt_prop_as_u32(prop, &bd->capabilities) != 0 ) > + { > + printk(" failed processing domain id for domain %s\n", > + name == NULL ? "unknown" : name); > + return -EINVAL; > + } > + printk(" caps: "); > + if ( bd->capabilities & BUILD_CAPS_CONTROL ) > + printk("c"); > + printk("\n"); > + } What if any of the other bits is set? > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -992,6 +992,7 @@ static size_t __init domain_cmdline_size( > static struct domain *__init create_dom0(struct boot_info *bi) > { > char *cmdline = NULL; > + int create_flags = 0; Once again unsigned int please. > @@ -1023,7 +1024,10 @@ static struct domain *__init create_dom0(struct boot_info *bi) > /* Create initial domain. Not d0 for pvshim. */ > if ( bd->domid == DOMID_INVALID ) > bd->domid = get_initial_domain_id(); > - d = domain_create(bd->domid, &dom0_cfg, pv_shim ? 0 : CDF_privileged); > + if ( bd->capabilities & BUILD_CAPS_CONTROL ) > + create_flags |= CDF_privileged; Nit: Indentation. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 12:51:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 12:51:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846695.1261843 (Exim 4.92) (envelope-from ) id 1tI5te-0002M8-3f; Mon, 02 Dec 2024 12:51:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846695.1261843; Mon, 02 Dec 2024 12:51: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 1tI5td-0002M1-VW; Mon, 02 Dec 2024 12:51:25 +0000 Received: by outflank-mailman (input) for mailman id 846695; Mon, 02 Dec 2024 12:51: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 1tI5tc-0002Lv-Vp for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 12:51:25 +0000 Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [2a00:1450:4864:20::12d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1f5a2f11-b0ac-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 13:51:17 +0100 (CET) Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-53de7321675so4307023e87.2 for ; Mon, 02 Dec 2024 04:51:18 -0800 (PST) Received: from [192.168.1.21] ([95.91.249.175]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa59991f1d2sm502605366b.170.2024.12.02.04.51.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 04:51: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: 1f5a2f11-b0ac-11ef-a0d2-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjoxMmQiLCJoZWxvIjoibWFpbC1sZjEteDEyZC5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjFmNWEyZjExLWIwYWMtMTFlZi1hMGQyLThiZTBkYWMzMDJiMCIsInRzIjoxNzMzMTQzODc3LjkzOTA2Mywic2VuZGVyIjoiYW5kcmVhLmJhc3RvbmlAbWluZXJ2YXN5cy50ZWNoIiwicmVjaXBpZW50IjoieGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnIn0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1733143878; x=1733748678; 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=evlHODTqQpDD23xlCiQJnJFL4S3np0fQpFLj1pSZ6z8=; b=jEbz3h/cQMACO4p/BrEH0IBtc23wuTdFH1c1uJE3ojZe3m/ILSr/3jJhaopWG3kpWu +YL7oq5hu+ZNfAkIQ8F0Feltr4gr+lEGN8KOo6nTYjbElDUdEBtPRiAcuOgoGBUxdkF3 BF6D2vPQlCFNsy1GmcivIjpyYh4oY99jiY2B3l1m+6m7Kcj0kUA5wYxftLyCF5XY2Wfx r/fCEpkwYP+cLUaAHq118wj6AxklxET2EzAk0FQpk4XKsvF4SodnYwfklwxpmhzhHiEr 6a2wEgmAOTDHaEj+b1ULEHPPkhmEKne1JME2tDcpXx00lTNdjrq8pUZq/PyEUqOVruJ3 LBvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733143878; x=1733748678; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=evlHODTqQpDD23xlCiQJnJFL4S3np0fQpFLj1pSZ6z8=; b=E096oZ2/aUBaUAVoUDu+GaFM9CYvrAS/VYho3inZNBg0uK83x1pqU0feuioU8HcL/C uhcN0PLirN169WkADq3oRDcM1q2ExfweuQfcgS75JCeAj/CmcKkrSCRrQRIMCaZN8VNM mrnB1YkABJVjSWqKNC6JuYKD5IaS0n0/eNX3kFczsLfb/I+jwIWTv2Qr3VIN6/k9SwHJ w1dVw2C2dim8deXL8maoBUCUO6uB7f7ApZKM2UvxGKo4PZTv16uLCfpmwRbRxlcuAwcY hbe05pKBWgnBcCpQfDmoa0luAtuh4xaj6Bn0M95AYbYlp7ZmATFpt5FPd2ogB/LlJHAd 6JPw== X-Forwarded-Encrypted: i=1; AJvYcCXRgI/4OBWN8ywWJaoPCzEyyJU0SiyzvaWgFfc/2M/zObzoYCfsYGMg+xBb1WFp7lYSyJFJKxzR+2c=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz8vR4dV1TEHK/GllryN98au7H7zSJDA537fPkGdQd0Zlv9Kr67 MYlb3BlMJsYZHt9B5E8MKjUdfQ/wNaApyktM0HMVdEdynd5kWUy6SiFyDiBvsPc= X-Gm-Gg: ASbGncsXf8PXgDuCyVmplQHK9q1G2JofepQQAk/KOqJ7giDBiuRVnkN1ULdoY4AzR+b XLry2IZpT1u68M+OTPufZX15S12zdzpPFmsQcVScIcKA6sB4DHbJksKmj8cKC0JkxpUMVfuPpQh 526hjz6LebF3PlDf7BA/SZb9GMPEyv4skEOklpeRgma4pvoN0WNOdUOnZyAoVb4ODz2fj7/y7+u jBbWLIh2yYr5utFhjADUYaIoEUwTOnn+EVtMwBdWH+KRdLG6MtzgWPos+AxBRo9VKA= X-Google-Smtp-Source: AGHT+IEp1hHPLS3l1a6XvhlOwnxeNnj717z4jeqoPXpTISFsrS7xARGlnshRcSbLLqopISvah17QeA== X-Received: by 2002:ac2:4199:0:b0:53d:f1cb:624c with SMTP id 2adb3069b0e04-53df1cb63a0mr9738004e87.34.1733143877720; Mon, 02 Dec 2024 04:51:17 -0800 (PST) Message-ID: Date: Mon, 2 Dec 2024 13:51:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v10 08/12] xen/page_alloc: introduce preserved page flags macro To: Jan Beulich , Carlo Nonato Cc: marco.solieri@minervasys.tech, Andrew Cooper , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20241119141329.44221-1-carlo.nonato@minervasys.tech> <20241119141329.44221-9-carlo.nonato@minervasys.tech> <29e69d97-41ef-4ebc-a68e-0253e230f6f4@suse.com> Content-Language: en-US From: Andrea Bastoni Autocrypt: addr=andrea.bastoni@minervasys.tech; keydata= xsFNBF5Nh4sBEAC7UM3QJtjrFO3pjcMCCh04JFyCCDzLFMIqMTB1UWCLamZ9dUwIau7ScgWv 49aqbM++edVvEBmG8JHDC83DFWymvFVXBgqgcR7tHHBbg33XJKFMHvuW/kFm/67XPTFcec4L JsH5MWms9TLJbgCnaWQQMH3kztTRQaf5QcULIoHnTySKlt3WzzzHosaMO+/GNYX7vzfc4ypJ mD5SQWYDhfRefASkyxdrN6/QkPwS2vGTyVK58o2U9I27KPYvs+77JrjrNBfpnebapaYVA55C 7BvTnno5Kr6QHwA6LcnIZqefz7KxQ1n+1C5QQbmhi9S68aloGCeUo9R06UMJG79TXC2Mc68t AtSCN/HpgcvN1CSL45f/4WCDPG572ebo5M6MPcTb4ptV1SC/i+4U/3cG0LNSUap+sGRCf0Iy C5xy0KOtgoq8jesdleSy8j/3DNIMGekSYbQYMO39DfZds2XFh9lVDjG7tQcChwW+lQDPo113 ENBRftDyqJthrvmJXGyrOmn0su56qh2Zqvi5pSHWsH88vAZUJsOU+9lpohmcb3o/cQ18UXNK H/9wjo2zKHFdSylQFERHIzj6WlBp01wkTcCqtUGpxsjJHmVSyakWs3TrGXooKR9SPMxqVrD/ oCCEo9IUD9jd+TxLsp/4TzUp4ScTO/43uPgdkMekU5mRs6B6WwARAQABzS9BbmRyZWEgQmFz dG9uaSA8YW5kcmVhLmJhc3RvbmlAbWluZXJ2YXN5cy50ZWNoPsLBlAQTAQgAPgIbAwULCQgH AgYVCgkICwIEFgIDAQIeAQIXgBYhBImpnm1L3x9XIoXhD3VSShFTR9xSBQJitcUIBQkKC9f2 AAoJEHVSShFTR9xSmSoP/0W/VboJmWmLh89eIl1QRoiL1nGcti1fTN835Q2TPiSdg+nFVqy1 8oLrJaHNe5THVaSr4S2du56SASYSG6f+Y5aiQccbalUJIV7KwXr741kovTnUPUKjPoi61Bx4 DUzis0Xo0NmMnz7M1YudbQZmjoakE/wZJRB+b79+kJwrfZFcNg4DSuSvNOUeI17uapLKRQ1a ukuRgXwUpMOudKngJ8HB+16aHIQX+yfpcsanNr1nGwHSLhEPEM20DVzKiCp2cKjv9Y7zZ+6y akbJHdbRuJliyZmXaSVO8sQ1tO/W6Y/4zAjejw2c1qDKISeIlGi+o6UEVYZlKCThzrV9vYok AcJF4DlYcAuBMVYCTomovXb/9/Y48pRGlfDGrmnt+FvGVA0jYrG02oufItY2JAGzFcX1KMTG AGf1S7pOj3AvBTGJjW8d8+sXuedH51HNixJtMnzcmi+qJfPJujBW3BEZ1p0ZoDyTH/WCZF+7 B5lFvTi0DRKY6AI0TSzBdjtaOMt64fn6KXtLtaTZKDKkFUBwAShJyYcWQSp/7EO+ZJW7dWIw 1vM5AcnugonJby+q+JGgBVC2rjscu5Okl3lnviF9WLAzmRH/pDkAa3jifiUm8eS+dP+4cN6g WXL9vTF6FtFyI8sgzRlY/IX8mao5bV/P1HCwNvkBhO8C3XMaul4FwQsjzsFNBF5Nh4sBEADN J99l+vOp8LB8jDjWOhINlpgp+EcrmWOuler5QnoJUywc2zkLelQIwVGP2lFliMdLHM6DbMEX ySIzHbhw7oPRP0QRPK/6I4bXYkSQCrLyqYd0CYSbkar8YV6Xa6nGxRmP1bBv1lPFHN66D0yE /z1ScGMXyX+ZOIvH0ekIkqFvi7Ec/7a/ntfU43o2t05dmbnEKoECZgeS8SraojfKnQRpz7+P N0q45O5fMETZpIiQh1/mB12HOcklDNELcKohqVfevbknJw04Yjbcv79aGpBRqoVWWBS4TxcD CRPQZ+H0tMUVEL/MqO7tNLA1VuGpOccyFtZnC/+J/twa7iKpPIxS9Ec/LDYTddebWH+8gOmr /PkBerBXghlZpxmQUlJeQ8kyecOOc4C7ec3aUGj+x28j0+zlXFLUbjiKIEM5VowIMgDDRwA/ MDr9IJhFzHaY2VCfBnX8sgJSn62IxqREq4X3KkR/Jtxt+HYXQYLl0yva2MBplkRcwQO799o6 woAMW0uyct4+BUcKo1sBFP2x2n4NFiPEjeoH3y9baruD9iiMQsmbJ3IKqtT13crCa+bcY3ZS Oz+CymgzNdH+RabJMC3mGfKIhUQGwEHz+wyMnv16nqO49bmoCk3q5Oneo4I3XwI3QbIJr0rd QkX6oh6R0taC3naal1ZYGxs0vZK567bT5wARAQABwsF2BBgBCAAgFiEEiamebUvfH1ciheEP dVJKEVNH3FIFAl5Nh4sCGwwACgkQdVJKEVNH3FLafxAAl7pW0v6Jju19I6wtB+XNzzi5Wota 3AyWzCxO/hUHNGRV/ZufhMkNFCMNzAxbdmO56eCk9ZYf/JMLu8H1GwhV1NgQ7HL4FNXXxLZ0 ixZDik86iiSjVLtEjLuwkS4Fj9wjqevycL/t16kJduFNyxT0/XiB5UPh5NClOMonHSC+V2If Kf6l2Ic34CrA3ovkfVvBXJTzia0VgyQCikeazgPRELH8bq2WTBWfjR3/l86Y0twiYyXqBNQ8 Q2Z83mu+yt38gTanz4YuDYz7YFjvL6IU2MZ5+ByothK6Cfx4W595q81dsGcJOlcd6j3QE+ps b3SHuToWZCHZRHyKrgGDqCL5RbsK3wXgDmc48SfN+5TxenT8A1lkoOHFcQ0SV8xleiwURXHc Ao+SzyDcTfltBNjzQmntQjAfq1Lq5Ux9nfpPMgnVHu5ANWeLtwLJyh+4aPVE5hGjeCa+Ab5U MyocCYdTuAmDHB9RQdf9c+qlVYuZCg7yYlWsvId5DGZnab2MzvExayaFCJVEoCccpfrqFFiF kJ19BogE4A6VTU0ShoHYJhLg7PuEZS1oWzULZnM8sNNI72MecvfZn5Oi0ZEJhFh+HETlJnIT 7gh7CGFBxPacT8vHxmeMPod7qrvYgKW+QKhU+tAI8gkI6hHXLBg/dxn7wAwTjlX1bo+jRJyp Id5SuAU= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, On 29/11/2024 12:09, Jan Beulich wrote: > On 29.11.2024 10:32, Carlo Nonato wrote: >> Hi Jan, >> >> On Thu, Nov 28, 2024 at 12:05 PM Jan Beulich wrote: >>> >>> On 19.11.2024 15:13, Carlo Nonato wrote: >>>> PGC_static, PGC_extra and PGC_broken need to be preserved when assigning a >>>> page. Define a new macro that groups those flags and use it instead of or'ing >>>> every time. >>>> >>>> To make preserved flags even more meaningful, they are kept also when >>>> switching state in mark_page_free(). >>>> Enforce the removal of PGC_extra before freeing domain pages as this is >>>> considered an error and can cause ASSERT violations. >>>> >>>> Signed-off-by: Carlo Nonato >>>> --- >>>> v10: >>>> - fixed commit message >>>> v9: >>>> - add PGC_broken to PGC_preserved >>>> - clear PGC_extra in alloc_domheap_pages() only if MEMF_no_refcount is set >>>> v8: >>>> - fixed PGC_extra ASSERT fail in alloc_domheap_pages() by removing PGC_extra >>>> before freeing >>>> v7: >>>> - PGC_preserved used also in mark_page_free() >>>> v6: >>>> - preserved_flags renamed to PGC_preserved >>>> - PGC_preserved is used only in assign_pages() >>>> v5: >>>> - new patch >>>> --- >>>> xen/common/page_alloc.c | 19 ++++++++++++++----- >>>> 1 file changed, 14 insertions(+), 5 deletions(-) >>>> >>>> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c >>>> index 7b911b5ed9..34cd473150 100644 >>>> --- a/xen/common/page_alloc.c >>>> +++ b/xen/common/page_alloc.c >>>> @@ -160,6 +160,7 @@ >>>> #endif >>>> >>>> #define PGC_no_buddy_merge PGC_static >>>> +#define PGC_preserved (PGC_extra | PGC_static | PGC_broken) >>>> >>>> #ifndef PGT_TYPE_INFO_INITIALIZER >>>> #define PGT_TYPE_INFO_INITIALIZER 0 >>>> @@ -1427,12 +1428,11 @@ static bool mark_page_free(struct page_info *pg, mfn_t mfn) >>>> { >>>> case PGC_state_inuse: >>>> BUG_ON(pg->count_info & PGC_broken); >>>> - pg->count_info = PGC_state_free; >>>> + pg->count_info = PGC_state_free | (pg->count_info & PGC_preserved); >>>> break; >>> >>> PGC_extra doesn't want preserving here. Since it's mark_page_free(), and >>> since PGC_extra is removed before freeing, the state change is apparently >>> fine. But an assertion may want adding, for documentation purposes if >>> nothing else. >>> >>> Alternatively it may make sense to indeed exclude PGC_extra here. In fact >>> PGC_static doesn't need using here either, as unprepare_staticmem_pages() >>> will explicitly set it again anyway. >>> >>> Hence I wonder whether the change here really is necessary (one will then >>> be needed in the next patch aiui, when PGC_colored is introduced). Which >>> would then eliminate the need for the final two hunks of the patch, I >>> think. >>> >>>> case PGC_state_offlining: >>>> - pg->count_info = (pg->count_info & PGC_broken) | >>>> - PGC_state_offlined; >>>> + pg->count_info = (pg->count_info & PGC_preserved) | PGC_state_offlined; >>>> pg_offlined = true; >>>> break; >>> >>> I'm similarly unconvinced that anything other than PGC_broken (and >>> subsequently perhaps PGC_colored) would need preserving here. >> >> Yes, we (re)checked the code and also believe that the introduction of >> PGC_preserved is generating more confusion (and code) then the actual logical >> help it provides. >> >> We'll remove this patch and integrate PGC_colored explicitly in the flags to >> be preserved. This avoid the clumsy logic of preserving something (extra) >> when it's not needed and then handling the special case to remove it >> explicitly. >> Basically my goal is to go back to v4 where this patch didn't exist. > > Hmm, no, I don't think I said anything in the direction of removing PGC_preserved > again. I merely think you went too far in where it actually wants using. Let me try to better detail the intention of what we have in mind. Here again parts of this patch: > diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c > index 7b911b5ed9..34cd473150 100644 > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -160,6 +160,7 @@ > #endif > > #define PGC_no_buddy_merge PGC_static > +#define PGC_preserved (PGC_extra | PGC_static | PGC_broken) The granularity of preserved as implemented by v10 is different than what you require... > > #ifndef PGT_TYPE_INFO_INITIALIZER > #define PGT_TYPE_INFO_INITIALIZER 0 > @@ -1427,12 +1428,11 @@ static bool mark_page_free(struct page_info *pg, mfn_t mfn) > { > case PGC_state_inuse: > BUG_ON(pg->count_info & PGC_broken); > - pg->count_info = PGC_state_free; > + pg->count_info = PGC_state_free | (pg->count_info & PGC_preserved); here (no need), > break; > > case PGC_state_offlining: > - pg->count_info = (pg->count_info & PGC_broken) | > - PGC_state_offlined; > + pg->count_info = (pg->count_info & PGC_preserved) | PGC_state_offlined; here (only broken), > pg_offlined = true; > break; > > @@ -2366,7 +2366,7 @@ int assign_pages( > > for ( i = 0; i < nr; i++ ) > { > - ASSERT(!(pg[i].count_info & ~(PGC_extra | PGC_static))); > + ASSERT(!(pg[i].count_info & ~PGC_preserved)); here (no broken), > if ( pg[i].count_info & PGC_extra ) > extra_pages++; > } > @@ -2426,7 +2426,7 @@ int assign_pages( > page_set_owner(&pg[i], d); > smp_wmb(); /* Domain pointer must be visible before updating refcnt. */ > pg[i].count_info = > - (pg[i].count_info & (PGC_extra | PGC_static)) | PGC_allocated | 1; > + (pg[i].count_info & PGC_preserved) | PGC_allocated | 1; here (no broken). And it also leads (as noted) to the special management of extra... > > page_list_add_tail(&pg[i], page_to_list(d, &pg[i])); > } > @@ -2485,6 +2485,14 @@ struct page_info *alloc_domheap_pages( > } > if ( assign_page(pg, order, d, memflags) ) > { > + if ( memflags & MEMF_no_refcount ) > + { > + unsigned long i; > + > + for ( i = 0; i < (1UL << order); i++ ) > + pg[i].count_info &= ~PGC_extra; > + } here (likely not need, should be impossible to trigger), > + > free_heap_pages(pg, order, memflags & MEMF_no_scrub); > return NULL; > } > @@ -2539,6 +2547,7 @@ void free_domheap_pages(struct page_info *pg, unsigned int order) > { > ASSERT(d->extra_pages); > d->extra_pages--; > + pg[i].count_info &= ~PGC_extra; and here. The proposal would be to go back to v9, which reduces (for the PGC) the management to colored only: > diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c ... > @@ -2382,7 +2556,7 @@ int assign_pages( > > for ( i = 0; i < nr; i++ ) > { > - ASSERT(!(pg[i].count_info & ~(PGC_extra | PGC_static))); > + ASSERT(!(pg[i].count_info & ~(PGC_extra | PGC_static | PGC_colored))); > if ( pg[i].count_info & PGC_extra ) > extra_pages++; > } > @@ -2442,7 +2616,8 @@ int assign_pages( > page_set_owner(&pg[i], d); > smp_wmb(); /* Domain pointer must be visible before updating refcnt. */ > pg[i].count_info = > - (pg[i].count_info & (PGC_extra | PGC_static)) | PGC_allocated | 1; > + (pg[i].count_info & (PGC_extra | PGC_static | PGC_colored)) | > + PGC_allocated | 1; > > page_list_add_tail(&pg[i], page_to_list(d, &pg[i])); Thanks, Andrea From xen-devel-bounces@lists.xenproject.org Mon Dec 02 14:29:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 14:29:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846710.1261852 (Exim 4.92) (envelope-from ) id 1tI7Pq-0004SQ-T4; Mon, 02 Dec 2024 14:28:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846710.1261852; Mon, 02 Dec 2024 14:28: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 1tI7Pq-0004SJ-QU; Mon, 02 Dec 2024 14:28:46 +0000 Received: by outflank-mailman (input) for mailman id 846710; Mon, 02 Dec 2024 14:28: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 1tI7Pp-0004SA-Qs for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 14:28:45 +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 bbe75f72-b0b9-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 15:28:44 +0100 (CET) Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-385f06d0c8eso759256f8f.0 for ; Mon, 02 Dec 2024 06:28: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-434aa74efbesm185330625e9.7.2024.12.02.06.28.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 06:28: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: bbe75f72-b0b9-11ef-a0d2-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733149723; x=1733754523; 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=fHJeNuD6v1xFh34P4V/VA1MX88pcKwvoFSDDtzYEMYA=; b=KbgHrC2XkcmPXqUaFNvRHbQ2zK8uGAGGV4G1ZSt08vyG/b8qKNrpX+r7pXKx6jfP4q SF+fmf+r+EU2MKKeeAvdSsj9Fnd73XV+vXuOqbgUAODxJwzFIuuskSDCef37xif1UqEb uhnxwSpLbeEIn0b2VRb96EZmsO6Ddk5gwXQ5fUqtjq/jqHF64pNvtFAHpW9UUmvg/+tf dfiDsL07V9dcBQDQBGnwr0D65993B3uEpJmifMVFHPvMYOLQZfaB4zqT31yXJ4OgHNFJ k2VyssHjnO1e0Nssoxa1P+mEKpTPuGjMDw/FBoqkPHQDgga6MQ/t/zJMk3z69jT3tfAH RNfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733149723; x=1733754523; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fHJeNuD6v1xFh34P4V/VA1MX88pcKwvoFSDDtzYEMYA=; b=sEXUeBpmJ7+rWUFPOd9Yb/YcdM7YMjfe/Lwn9DPL7kb0oHbiPbfjfnZAc2a+WZKUe7 xON5I7T1HWKzEtEyeOgVpxiSdbEbk2+VtTE1/3Zpn8I/P0v1b/syc3tdVqBTBSTFEH/x eNkQrayukGcu02W5TWIWXisT/6HxI7BPIIZWVRXmpS2UdSwbHgZ+fdkjg/ze0tOGaF/g RU3G2+kQVXo9Wev/en6+mSVsvHdmRFuR33geO0iq9adqoDDbiINY/kU6QvaIrvgaNOC+ H0aW0EFYe/QUr1UxiDhDuBCbDgEJwjRI7FdcEbJal/3zaJJQyeSqmv1GCxtRusQz7Qb8 uvMA== X-Forwarded-Encrypted: i=1; AJvYcCXX5invu6wAIc1e0TP2r5SyIo+pwnaq/1ocxU6R0INFAqa0QIBg/1sAduKJw5wXab8APf1oeuQLdBc=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz3lsAPAF71I9MWSuDgIbOfut1DuAc3Q5oCu1V9MwJG0a1oviAU /0d2W0JYsW2JxvAyLQfglJiiWBkLlOZP18zuAOLYAYc1VLgheYoFGt1htCCyMg== X-Gm-Gg: ASbGncvcBO0mjzc8ZiDSorh7ba/7Me1asSrxmKsUBjjZS1Gu4wELkWhKHqpS85SWi6V 1oXFKd/gbNsHLgADhA1EKmPmWnn9AkZGUA5QmXBzWQw+GF7C/HBs0E3MXVGfzk/li9o7tVLfQCC bL5WN8p76/DtgMFFdDI7SAse96MVzruaU+GKzxllF8G16NeJFnhWNjRmbDbJCbgzImYE1ROqjj6 l9QDL7C3bh33gC3BGAvTpGcg/1b+p8K/jKxwvknkpDyTDs3s62/npWCHmr3FOFrM527l80E3spZ nw4P3k8s5Q+CZvaH196pzNoK1Q0bqTVp07k= X-Google-Smtp-Source: AGHT+IGf4OxwMXRJGTfkQ3fCbsLRA+KNNxWSoC9OfbLfbmS0ma1Vv9vk9Wfijqh+OQ7L+4rgT1i7VA== X-Received: by 2002:a5d:47a7:0:b0:385:ec2a:325b with SMTP id ffacd0b85a97d-385ec2a343emr4091971f8f.29.1733149723595; Mon, 02 Dec 2024 06:28:43 -0800 (PST) Message-ID: Date: Mon, 2 Dec 2024 15:28:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v10 08/12] xen/page_alloc: introduce preserved page flags macro To: Andrea Bastoni , Carlo Nonato Cc: marco.solieri@minervasys.tech, Andrew Cooper , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20241119141329.44221-1-carlo.nonato@minervasys.tech> <20241119141329.44221-9-carlo.nonato@minervasys.tech> <29e69d97-41ef-4ebc-a68e-0253e230f6f4@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 02.12.2024 13:51, Andrea Bastoni wrote: > The proposal would be to go back to v9, which reduces (for the PGC) > the management to colored only: > >> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c > ... >> @@ -2382,7 +2556,7 @@ int assign_pages( >> >> for ( i = 0; i < nr; i++ ) >> { >> - ASSERT(!(pg[i].count_info & ~(PGC_extra | PGC_static))); >> + ASSERT(!(pg[i].count_info & ~(PGC_extra | PGC_static | PGC_colored))); >> if ( pg[i].count_info & PGC_extra ) >> extra_pages++; >> } >> @@ -2442,7 +2616,8 @@ int assign_pages( >> page_set_owner(&pg[i], d); >> smp_wmb(); /* Domain pointer must be visible before updating refcnt. */ >> pg[i].count_info = >> - (pg[i].count_info & (PGC_extra | PGC_static)) | PGC_allocated | 1; >> + (pg[i].count_info & (PGC_extra | PGC_static | PGC_colored)) | >> + PGC_allocated | 1; >> >> page_list_add_tail(&pg[i], page_to_list(d, &pg[i])); So what's wrong with having PGC_preserved _just_ for these two instances? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 15:33:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 15:33:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846723.1261870 (Exim 4.92) (envelope-from ) id 1tI8QM-00045k-IN; Mon, 02 Dec 2024 15:33:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846723.1261870; Mon, 02 Dec 2024 15:33: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 1tI8QM-00045d-Ff; Mon, 02 Dec 2024 15:33:22 +0000 Received: by outflank-mailman (input) for mailman id 846723; Mon, 02 Dec 2024 15:33: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 1tI8QK-00045X-A3 for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 15:33:20 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2061d.outbound.protection.outlook.com [2a01:111:f403:2416::61d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c0caeb50-b0c2-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 16:33:18 +0100 (CET) Received: from BL0PR02CA0034.namprd02.prod.outlook.com (2603:10b6:207:3c::47) by DS7PR12MB8420.namprd12.prod.outlook.com (2603:10b6:8:e9::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.19; Mon, 2 Dec 2024 15:33:12 +0000 Received: from BL02EPF0001A102.namprd05.prod.outlook.com (2603:10b6:207:3c:cafe::9d) by BL0PR02CA0034.outlook.office365.com (2603:10b6:207:3c::47) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.15 via Frontend Transport; Mon, 2 Dec 2024 15:33:11 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by BL02EPF0001A102.mail.protection.outlook.com (10.167.241.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Mon, 2 Dec 2024 15:33:11 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) 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; Mon, 2 Dec 2024 09:33:11 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 2 Dec 2024 09:33:11 -0600 Received: from [172.25.146.163] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Mon, 2 Dec 2024 09:33:10 -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: c0caeb50-b0c2-11ef-a0d2-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FIkWkbVi/cAPOf3h5VL1iQnsIqMSMdeYi8JWoo5g+VZ5yTxBN5cECJh1L2OQlM2mLW4Bd0JJEi6djSteCU4NtRvjb71ka3I4++e2YBFg8lsrB+4/tF4RwP+j6Kn2kAbK7e6MXddJLctnto9IZQGK4bz9AODOlwlNRyIaCXcecDTL5ON6atyIJKuJew0Ux4ebxsYjSxJUHApXfm5FsIM8r/xYI9rfVyqDJqPQH5RAS6FbTp6+rbiwG8+VQsQO2zLUOR4pQbCNiCjPPzeec7bdUBQ5egouaL84TA2fJ5e2fbuU8sGrfWkuTt+HknxfR6F7+hIK185poKYk7jJM4Ksp9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VgruRwCGnpC8s0feqCfANfitgNd0hEHhIo4mt08w4xA=; b=QtKYo/iR07W4MZmPWKKP1ghGKTMbjqwMKZllOchUXVt36BrUS0Czu0iiVOQPA3m/z15bNlbCWuDtKnaS5/HaRNKIlutd329qK8/+s0cQv2P+riZiOnhRA3mm4fNpi2Im2GSdIdZoe6DDm5f057wfcmx6B2fBZovcXMkVqK+5AGK13L33DU+QfzwiHX4LUTC8ESurfpuxFL4YoIv3DcfAxOO+LN2VijNqzyNsuAIhT5rPFqVuL74rb+4MUdJjfNmdG/Oz9L8bAKYRW5henEn5C/yA0PE7i37yI75wXlLOiBHXimOxUI+trHhyT1JwXAp/aRF3KEaKoPXHnQtuwE23sg== 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=VgruRwCGnpC8s0feqCfANfitgNd0hEHhIo4mt08w4xA=; b=FHZQG/sdAK3AvQQTTW9T7HO/8EOaIqpiEJ1GbH9RsN+xrtedK4OMVC3s3TtYkqCnXEA+fgY64wLARLZIK4zB1W2gwqLaP/YwON1BXUTqCWgRf/eCBN6lv4BvM649bZlzGfBUvOZkQytrImKf/kFZWcOOCcp+cvoPmh8/mUWBCTU= 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=SATLEXMB04.amd.com; pr=C Message-ID: <109dc316-d9c4-4d18-b34a-ea182fad6529@amd.com> Date: Mon, 2 Dec 2024 10:31:24 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/15] x86/hyperlaunch: introduce the domain builder To: Jan Beulich , "Daniel P. Smith" CC: , , "Andrew Cooper" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , References: <20241123182044.30687-1-dpsmith@apertussolutions.com> <20241123182044.30687-7-dpsmith@apertussolutions.com> <7ca79382-251c-403a-9d1c-9afd778bb203@suse.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <7ca79382-251c-403a-9d1c-9afd778bb203@suse.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF0001A102:EE_|DS7PR12MB8420:EE_ X-MS-Office365-Filtering-Correlation-Id: c69e6edc-98c6-422d-3557-08dd12e6a17c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|36860700013|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?bEVFWEk3alRHbVRyTEJGVjFwQldLMTdhbzl4cXpndE1PSDlhVVV3dlZpdkli?= =?utf-8?B?Z3JYbC9nWWRTczBNM2x1VlFrWVJ2alF4UnZVWU5NalJUV005R2lPSXA3bnlu?= =?utf-8?B?N3RYWll4Vk4va0tiZ2dZdEhZa28xdC8rUlhZblR1V2M4L3g1WTJKMmRJWTBj?= =?utf-8?B?UnQyR3dnUXVSVmZ4VHMyd1JHRmYzdURwNms1Qkh3dXc5TWlCSU9uZ2VzK3RK?= =?utf-8?B?Mm1ZNlBjOWtmVy9LaDJNUmtpUGI2VnFJZUVtcWc0YiszcnoyQjJMclQ0eTBS?= =?utf-8?B?UC9NR2lLUDNVR3Y3TjdnODlyOENnUi8wQ2dPL0haekJXK1VwVDBnbTI4WGo2?= =?utf-8?B?MVA0ZkV2RkFZMkhMME9IZHpRRmJvVy9ITGhSSzJ0dXM3NmZScEpSNXRrUlFF?= =?utf-8?B?NDZhR1BmVmF6UkdRK2lRVVIya1ZyZXM2SFJPSm5LOThwaEl6NlhIS0taQVJp?= =?utf-8?B?eUtMV3VmVnVtK2JoSVJnelZiOE8xUUNFY01Lc1JacFdvbU9rcERadlNteUk1?= =?utf-8?B?Tk0rTnhCOUR5cnBtbnIyQmNFMy9OcVRRK3VES2NiOXljcmd6YTl0SW1PRDYw?= =?utf-8?B?YzRRa2VRN1BjTW5CUzAvSWtFMithNzZOTDIwUS80UHhEampaNE5yZlkyYXZM?= =?utf-8?B?ZUp6UW5LcjdVYmNlOFNEMGM3Vk9iQkE1UGgxeG5MYjBFRW5PbFJNbFFvTXNC?= =?utf-8?B?TWNMNVVqcUZycU1xRCtka1Z5RG9SYUJDTEV5Skc0bkhDZkxiSFhnY08yak5o?= =?utf-8?B?OFk1OFJINE5XT2hIWU82K0dSbVZhNS9ZVXNpRlJPNVF1NXgyeXAzKzQ1NUlK?= =?utf-8?B?MkxtWTlielJ6M2ROM3RrMk10S0gzQmFQV0VYNE4yNDA2d0lXZ3RjUEIrcEJx?= =?utf-8?B?OWh4aWlFU0hJdTh6VmFYbEJKQTFTUHpPY3RBam9hazhTdmpEQlZXVVYyTHRF?= =?utf-8?B?b3cwTGxkT0tUc3JHRnBjbU5CSGdCQlYraUVWc0xMRkpEOTdNcUtmSjhOUnpy?= =?utf-8?B?T1hvTXZYUmErU1F6M2V6UzRoaGFMczc4Z09KZUxvTlN5d1hJWWd0L0hWeDl0?= =?utf-8?B?cHdidzlWSG4xSnFXY2FVT0NIMUw3dmFFY1dNV3ZIbytsdThpRUxScjNYQktX?= =?utf-8?B?V2tYMjdyTExoUENycXYveFNTLzRpOVJMS3NBeWtIVURhWDN1a1BKbzcvRHY1?= =?utf-8?B?NUhSbGZTUFhTOEY4endxWVdEN0NEWVVwVllDRTFscjBwU3V4Sk5YVHN3NEpl?= =?utf-8?B?Sy9lNithdzVkRnRiQmVhQmpoVlpkSTE3UDAwNDl4ajJMOFNXVHFLTWthb3RF?= =?utf-8?B?Y1FuQTZwUExOUjh2MHI2Y0NtbmM0azBrU0dQa0RTT3lLZVRHd1M1Rm9FNWJZ?= =?utf-8?B?WGNPZFEyOHNTR3BtMWVmdmVJUy8wV2hxUnBacVlrTFE5am1ueHFSRWVFNFVv?= =?utf-8?B?RXkzQWpsUXJUSEZPZUtWTFlGVzZ2OTVGWFZHY2JkRXZyN3RwaHo1bk1STk9s?= =?utf-8?B?di9abUdUbE81NzdXL09VcU9zWGNSYUp6SGt6VTgyL2JGZUFUVFlEV2dibzhM?= =?utf-8?B?cGZMZUc4TFREc1gvVXhtTUR0TUhkNzJrUU1VV3E2MmF2S1RkUnlSRkh1NldX?= =?utf-8?B?YWRITXNyZVEzcjFVZzBud2EwUW9xWlAwR3B5R1pYUHpXbENwRU1qS1JJdFB0?= =?utf-8?B?bjZxN3JVWmMyVTF2cldhbmNwRXRYUHVmSzI3OW8wWU50ZTlFZ1BHc0VXaEtG?= =?utf-8?B?K1dWVTFPVmJac2hobjZEVWx3UE41Q2I0MnFldXVrd3VrUUY0R0p0S1Bvc2JX?= =?utf-8?B?cmZRTnVWdTk5aXg2WCtvaGdKK1Rha0N0aktzTGR4Z0tsYVhOV2Fldk9RUlZw?= =?utf-8?B?aDN6U01OaHJOVlZWemZXcjQ2SFZmUkZPcGd1T2hCQU1mT0pzTURMRUkyaUJF?= =?utf-8?Q?6yVU3Ypa7zo7NbcYMePLfZfW0+ctJSYJ?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Dec 2024 15:33:11.6747 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c69e6edc-98c6-422d-3557-08dd12e6a17c 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL02EPF0001A102.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB8420 On 2024-12-02 04:55, Jan Beulich wrote: > On 25.11.2024 18:52, Jason Andryuk wrote: >> On 2024-11-23 13:20, Daniel P. Smith wrote: >>> --- /dev/null >>> +++ b/xen/arch/x86/domain_builder/fdt.c >>> @@ -0,0 +1,38 @@ >>> +/* SPDX-License-Identifier: GPL-2.0-only */ >>> +/* >>> + * Copyright (C) 2024, Apertus Solutions, LLC >>> + */ >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include /* required for asm/setup.h */ >> >> Should asm/setup.h just be changed? > > Why would it need changing (and why's that #include needed)? It has a > proper forward decl of the struct tag, and I can't see why it would need > anything else. My question was suggesting to just make the changes, but that was already done by Frediano in aa4ad424f0 ("x86/setup: Make setup.h header self contained"). I think Dan's comment predates aa4ad424f0. So it is now stale and the whole line should be removed. Regards, Jason From xen-devel-bounces@lists.xenproject.org Mon Dec 02 15:36:20 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 15:36:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846730.1261881 (Exim 4.92) (envelope-from ) id 1tI8TD-0004ee-VP; Mon, 02 Dec 2024 15:36:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846730.1261881; Mon, 02 Dec 2024 15:36:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tI8TD-0004eX-SN; Mon, 02 Dec 2024 15:36:19 +0000 Received: by outflank-mailman (input) for mailman id 846730; Mon, 02 Dec 2024 15:36: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 1tI8TC-0004eR-LD for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 15:36:18 +0000 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2061b.outbound.protection.outlook.com [2a01:111:f403:2009::61b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2b4dbed3-b0c3-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 16:36:16 +0100 (CET) Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7) by IA0PR12MB7556.namprd12.prod.outlook.com (2603:10b6:208:43c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Mon, 2 Dec 2024 15:36:12 +0000 Received: from PH8PR12MB7326.namprd12.prod.outlook.com ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com ([fe80::6d76:9c33:d230:8264%6]) with mapi id 15.20.8207.017; Mon, 2 Dec 2024 15:36: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: 2b4dbed3-b0c3-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NaNsm1KStYnGabtyuBW6saMRkySODJRv/e1pPKRzQcSk5RIKwz6RVNepCjATzFCyrf41r8W57dfEJYIXTmb7uaWTySbG3R88Q7A7YmMbpB5hGeH4TQ0+mfAOVTmtuW49a+4OOt1XvNkCD+IEjh0wKo/ytzIUHzBteVePSctzqv8MCLZBNAl7qvhEsHuzUIM/uPf7AU2eqsv4oMU0od8oX+E+sFVgqn7HmLvbbZrp+gmOSBcoaARXdxyes3b8zUY8O5/EKtEuWKC10zRCdKiTayVeG1mccnJOgTS6zt6D13k9jLtUNvQAsFnQURjpAZDnDgbRMYuLOVZBtRGx8sKNdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=RGQL8XVivSmIqhJLIGJN3hPvdiz+GNNKZi3aRNbCIt8=; b=ZKoohSuhJpQYG2Ac0C6lmJ7swQyP93e0fZWhE4jAk+uABrObu2//ZMFzD3VxRcT4wePqcWwYTPfrdXHjRJWnzk7czWR8iobtotU6+t6M1NajDf+176q4hxBNtZOgkUSs4k9CfZVsRVaNwXD0QaAC4BsDIKJgIM1WceN5X33md/QWT9+wpk7JIj1nhyDqddIblNlkRrbDvqL9fAwWOLvq1OmjY4z+8P5MNTgFFuKboOh94A+fWNXOms/W6SHoz9UbXT5zr618kSITrhvscHRua2mpal91xenoFeqi1aoAY+EmaTxSiutRiMcUg9wcXSu7onOAoXccySf4K6NKQdNRMw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RGQL8XVivSmIqhJLIGJN3hPvdiz+GNNKZi3aRNbCIt8=; b=bRROMRm2x1VyZuUGvZa5pLPg1NaY93J0RGuWMQzy5vrsGKjKLGh+UrvRQDyA3C5EoRErOtkV1v92LdfiK2P8TNkbur60K9QalDRi/E2DlNNW4/aOzWOM4Rd5NrhirJmn9fgjHcNXt8fWr6AR3n+RGs6kqEIZE0aTTgGbluU6Jcs= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <3b29ca45-3df0-4853-88ba-f2138909daa7@amd.com> Date: Mon, 2 Dec 2024 15:36:06 +0000 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/3] xen/arm: mpu: Create boot-time MPU protection regions To: Julien Grall , Ayan Kumar Halder , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Luca Fancellu References: <20241118121250.4027441-1-ayan.kumar.halder@amd.com> <20241118121250.4027441-2-ayan.kumar.halder@amd.com> <4521597b-2714-4ec2-8e80-d90dfa84ce99@xen.org> Content-Language: en-GB From: Ayan Kumar Halder In-Reply-To: <4521597b-2714-4ec2-8e80-d90dfa84ce99@xen.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: PR0P264CA0140.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1a::32) To PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|IA0PR12MB7556:EE_ X-MS-Office365-Filtering-Correlation-Id: 969a0327-e012-43ce-aa45-08dd12e70c8b 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: =?utf-8?B?UE4zd0J3bisxSnEvRGh5emRndUdFV29wQVNGVHo2N2p5WTdCYThGMWtCbllS?= =?utf-8?B?NGVIK2dMeGE2c2xTWkNMWFFFSnltZ3lUc3V6WGc5dnhmU05JUzk3WHZaY3RW?= =?utf-8?B?TXRQZFVtRDJPeU1oTkQzQkhLNzBiSkxyRHBIMi9pWnh0NGFUd0VIY215Z2pl?= =?utf-8?B?c0RvV0dPcjNOREI4SGpLN0JXNnFwUWhYdkFYUmRxdlIyN0NSTm1ITDgzcVNm?= =?utf-8?B?RDIwVzkrbStGZXdHTEZHSzJKWG5GVmdBOHNEUU9YS05uUDBRelBtdDk0c0Qr?= =?utf-8?B?bXFrc0ZKYU0xYXVpb0ZqOUxVOVBuWWVRQ1JhL0pTbVFRL2t6ZG5mcjhQaXNC?= =?utf-8?B?SHcvVWloUG1EMzFJeGY4aG5aaSsxZC84ZVA1WUoxU1BoUlRkaE5RQXdHTXBT?= =?utf-8?B?VXVodVpWQkhvYWh3L3lkUlZtNEt4aWYvd1ZHRXkwUUhWSU1obXY0R3pOWHhC?= =?utf-8?B?Zjd2K3lpRDFPdzBZbDRzZ3BTU053Y2U0MjRSRnZ4TElPc2MyNzdYeHRlSzR6?= =?utf-8?B?UndDWGIwMFdwU1lPRWhIb21ZT2RFU240Y1Z3M1NFcHY2ZGZCSE91WkFhd0NT?= =?utf-8?B?L0p4aVZjNFpZM2xtTkgvWmp2QmZFNCtiZzVET3RtZi96TGlHc3ZzYU55MkhZ?= =?utf-8?B?SzBFQlRpakNCY1FsTlpBNjNJcEZEQWZKY0NvR09pa2YzMi9YaUMxdnJTdUdZ?= =?utf-8?B?eUJVSUdIMzN6M0RUZGFUTEZVL3FNMjlsbnRaVExqaHNIallkUkExaXJuRVV5?= =?utf-8?B?RmdFNUNadnF0UHdwTXQwa3J2dVo3L2Qzc3RjVHdJOWdqeHhTZloyN3BRVHM3?= =?utf-8?B?dmVPdFVDWWUvL2w1enM3aWRpWnBjbGZJVlVVa1RCN2tOczBVL2lncmlFMVFy?= =?utf-8?B?eVVtNzBOU0JTR0xwZ29HaGdxdDNHcHVJOU8rNHhJWUFaemNTK1hQUlVncWxq?= =?utf-8?B?NGJwUFlyZjZuZXdkN3hVZjM1Wjc1MkFsZ0VqS1E4NHBuTXE2R1Eya1hGbnNI?= =?utf-8?B?WVI5bGw0WVpUVjN6U3NTWGErc0pMZGtvM3ZCdVNmenpHY2Rkdkh6SDgraS9L?= =?utf-8?B?eUFIaEVCaTR2aVBYaVpiVzJ5bkhQa0NTS1g4T1U4MXJlb2ZDQnNKdmgzRm01?= =?utf-8?B?UlhPWWYxSlZmclRCaUV2YVZuY2l1T0Z6Yytacmt3MUxUNEIyeFI3clNYbldl?= =?utf-8?B?Z2N6Q0pEeDhHdEREdGIyaXBvbUNIOG1kVVlvTGEvem5uWHVmTUdaTFBOZnhO?= =?utf-8?B?UnNFZDlSMnFZbjBobnpSaDVjYTg3MHhrTzR5SjlWUVMyWVcvSmtYUGx3dWMv?= =?utf-8?B?RWU0NXlnaTJBK0lQdURZeFlPVkxCQ1oxRFpyaG1zUmhTVjVNZmtQK2pGS3pj?= =?utf-8?B?VUhPVHdNVzdqbHlsN0FxTVZlVUZUQklISG9YeTAyTVE0OGRXcExjRVhSaXlj?= =?utf-8?B?K1dvM2xVTWFTVkh4ZFdLbHZLbjVWYjR0aDN1Rm12SDdZcWNUMkVsUzVOemZC?= =?utf-8?B?SmtBVk9QREZWQnBtVHVmZWpLcXFNdjhnQXBUQmcxcFBsRUpJdzB5bTJPZTZT?= =?utf-8?B?SDl3WS9DSDE5RWtEamtNa0dPbWVyeElSK0RrY3lhaTNJdHBuN0p2citrbHJ6?= =?utf-8?B?bngwS1IxdGlYaDR2UjVrMHVKT0IzL2hyTTJBbG8yV1k0ZWJyVUJ6QVFEczdp?= =?utf-8?B?eVA0cWROMFEyeUE3OGJrQUFPQ3hKamVpaG91ODBaNmRZYnVhWUVsSmVIRFc1?= =?utf-8?B?R1AvQXg4YmVDQjNzR1VubjBMZTRTNXhHU20wckNxd1BndmE0VWRqVm4yZUhK?= =?utf-8?B?Q05JU09iQmN0Z2dVb25CZz09?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH8PR12MB7326.namprd12.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?dlowZkZ3T1o1YnJnL0dRMjFzNXJWL1ZBTzB1OEQwRzdBYXp3VytYeDE1OGl1?= =?utf-8?B?RGF2QjlEMDMxRVUwMzZTclhlLzg1eU1kSGxkaUx1bHR3bENpcXh2ejZpVkRp?= =?utf-8?B?YitJNTZZWDREMUhMdkpvY0kxcGw4TitmYzJsK3JLRm8vNGhtUkxhOUtURm9L?= =?utf-8?B?SXdjMGRYb0duR2Y4ZUd1ei9OOHozUVhXYjJPUW16YUphaUpsWG5HOWlEb2k0?= =?utf-8?B?YVFMZk5iTmFvdGI2aGNGZmVYcEdXRWZTWmNaQ3hIUDlMOWZPZUxLSURiM1Ro?= =?utf-8?B?TlBmOWE0RGN1QzZQOTB4U2hYaUxmNjgxVDkxL1NjSk1pN3p2bGY0SWtvbFpz?= =?utf-8?B?Vkl1Ny9nZDVKeEZmNGV2bGZsWkczOFJ1R0pYcWFsRDcxclpPNE81d20xK2JH?= =?utf-8?B?bHlUdk84SEJ4a3ZpWkJnSlZUSUN1RnAwMzFZVEo1K2xwR29JRmVZUnpDcC82?= =?utf-8?B?WG1xWGpQN3lhbzc1SVpmTXpBTGsvNDF5M1lpdTlSRDEyVDlET0lOL3VnaTF4?= =?utf-8?B?OTgyMm8ybm9mNDFiSytTNG5wTXNOQWZzd3hNd2JjbjcyV2xIaFJNWThtWFRU?= =?utf-8?B?MVR5N2FQZmhQd1BlMHRQc1ZXUitqV21sZG9vMUM5aTBQVTlSaGUxb24wQmxV?= =?utf-8?B?enhaODlOeXVkUjdpTkNMR0ZsOTMraWhYLzdvWFdJc1hxbXhOMW5takNmWkgv?= =?utf-8?B?Z3I5anRORXpEbm5YTEEveHE5SGlMclViVit6cEI5V1pnV1RTTjFFdHBEOHJP?= =?utf-8?B?NUdNRThxZjVBQ2pzc09sUUhaNktkTmtlS2x3M2R3c3p0Mjg2ZVFBM3hHN25L?= =?utf-8?B?S1NJMjVLWklxYVUrZkRMSmI1NzJRUnRpelY3N0VSMTZEd0VXLzVDZndkWFJ2?= =?utf-8?B?N0NPSzJOM2tteFdtNjdlT0JkZ2FwV3ZPZjhuaERxblFGdGphelB5OG1yaG5D?= =?utf-8?B?Q0gwRng3dWhLZ1hvQWxQMjRGZ05YMnlrckRDa0YrYkRURlkxZ1dSRWcrOEJu?= =?utf-8?B?WER4YkdQRk42bmVBdDRrKzFWUFBxcWZTeEs1YXJQYURKbkwxTFowVjRWZG5Q?= =?utf-8?B?UjdVZVd0L0VJMXFnMVpxVjB1VXVoQmhjTkp3eHdtWS8vRndtT0xrWjBlejgw?= =?utf-8?B?U3h4akFpSDI5NnRCY1o0Zk1SUzhZVS85NEVCV3ErWDZ5VDNMODNXQXpmRlp4?= =?utf-8?B?Y2JnTmxVaHdqMHZCWjJMdnJKUEtMN1MydXVXZlpjR0d6T2liUHNWOVNsTnNO?= =?utf-8?B?UW9ScVd4OGxCNGk0WlNiajZ5dHdlZ2xUbU02cGlETGxvN29NU014TldmSGlw?= =?utf-8?B?VWdXbTZjeEE1R3JJNXlVT0tXZCtFbHpsTis0d1VxcHBNajNvRWtzNnc3U2t5?= =?utf-8?B?eTdXaG1CWXZOcmJLUDhqQ2NValkzN0xGV2ROQWtDTUVMTG1zRm1sSFhUQ055?= =?utf-8?B?K2FrZlVhS3J0WkZYR3o3K2lQenZTOGlMOENLUkY0VW5QK1ZVWE80dHJXNUJq?= =?utf-8?B?VGpkU3Bob28zZCsrQ1J5ZVFGSVdSY1pGMnB6aTZqWTFTNFpjNUFiV0JmRk9D?= =?utf-8?B?UVFVSWxHd1JQV24xNGErUzE4SWJ2SG9KLzZYKzcybjdUeDNLTWozc1VPTW0y?= =?utf-8?B?L25TRVQ4Qks4ZE9hSkM3aWNNdEZ0Vm16MXB3UTRaVUlaQmJIOWdpWHIydFBC?= =?utf-8?B?YytwZzlLZjU2LzA0TWJvcCtia1BOOFdpVnFYNXl1N250VjU4OCtjK0d5dHRt?= =?utf-8?B?QTVMUlZ6K0ZJOG5adlMyeCtobzNCQVd6dVpPUmtQTEk1b0J0bmJLVFNNd05F?= =?utf-8?B?ekhDUzhRQkpkOWowNnAyek43cDAwSXpVNGc0eU9nRDBBc0Qwa0RYRkt5R2d5?= =?utf-8?B?UmNtUE9PUWNTakRHb0crUG5TVFJXZ0RyOCt5KzBMbWErSGhYajlFRmw1b2Zl?= =?utf-8?B?eWlXY0p1TWdsMmFQcmovSTFjMmMySmFpdFhMNjdQL3gwSEVueHl2VFZCdXJu?= =?utf-8?B?SDlXTHdPcS80Zks3c056NkRsK1JLUjU5WCs5VXFzMXFTa0Z5aHQwQytLSURq?= =?utf-8?B?VENvUWdUUmNQVHRlcWRNU1BrVHhVSlFDVWRQY1ZqYlJGWm5Vb1lnd2lMZGVw?= =?utf-8?Q?ZpLnvGkJXYt0bOYgIK07YAmne?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 969a0327-e012-43ce-aa45-08dd12e70c8b X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Dec 2024 15:36:11.7514 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 9jLq9ZzzQ+EZp2Rd7uX4FCn4xp29FaVdJNlAy6dIoDbhzzFHK562knyg+czxujygdymO0+20K4DZAjZ4PjTUqQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB7556 On 30/11/2024 17:45, Julien Grall wrote: > Hi Ayan, Hi Julien, > > On 18/11/2024 12:12, Ayan Kumar Halder wrote: >> +/* >> + * Macro to prepare and set a EL2 MPU memory region. >> + * We will also create an according MPU memory region entry, which >> + * is a structure of pr_t,  in table \prmap. >> + * >> + * sel:         region selector >> + * base:        reg storing base address >> + * limit:       reg storing limit address >> + * prbar:       store computed PRBAR_EL2 value >> + * prlar:       store computed PRLAR_EL2 value >> + * maxcount:    maximum number of EL2 regions supported >> + * attr_prbar:  PRBAR_EL2-related memory attributes. If not >> specified it will be >> + *              REGION_DATA_PRBAR >> + * attr_prlar:  PRLAR_EL2-related memory attributes. If not >> specified it will be >> + *              REGION_NORMAL_PRLAR >> + * >> + * Preserves \maxcount >> + * Clobbers \sel, \base, \limit, \prbar, \prlar > > Per this line, "\sel" is clobbered. Which implies the caller cannot > rely on the value. Yet ... > >> + * >> + * Note that all parameters using registers should be distinct. >> + */ >> +.macro prepare_xen_region, sel, base, limit, prbar, prlar, maxcount, >> attr_prbar=REGION_DATA_PRBAR, attr_prlar=REGION_NORMAL_PRLAR >> +    /* Check if the region is empty */ >> +    cmp   \base, \limit >> +    beq   1f >> + >> +    /* Check if the number of regions exceeded the count specified >> in MPUIR_EL2 */ >> +    cmp   \sel, \maxcount >> +    bge   fail_insufficient_regions >> + >> +    /* Prepare value for PRBAR_EL2 reg and preserve it in \prbar.*/ >> +    and   \base, \base, #MPU_REGION_MASK >> +    mov   \prbar, #\attr_prbar >> +    orr   \prbar, \prbar, \base >> + >> +    /* Limit address should be inclusive */ >> +    sub   \limit, \limit, #1 >> +    and   \limit, \limit, #MPU_REGION_MASK >> +    mov   \prlar, #\attr_prlar >> +    orr   \prlar, \prlar, \limit >> + >> +    msr   PRSELR_EL2, \sel >> +    isb >> +    msr   PRBAR_EL2, \prbar >> +    msr   PRLAR_EL2, \prlar >> +    dsb   sy >> +    isb >> + >> +    add   \sel, \sel, #1 >> + >> +1: >> +.endm >> + >> +/* >> + * Failure caused due to insufficient MPU regions. >> + */ >> +FUNC_LOCAL(fail_insufficient_regions) >> +    PRINT("- Selected MPU region is above the implemented number in >> MPUIR_EL2 -\r\n") >> +1:  wfe >> +    b   1b >> +END(fail_insufficient_regions) >> + >> +/* >> + * Maps the various sections of Xen (described in xen.lds.S) as >> different MPU >> + * regions. >> + * >> + * Clobbers x0 - x5 >> + * >> + */ >> +FUNC(enable_boot_cpu_mm) >> +    /* Get the number of regions specified in MPUIR_EL2 */ >> +    mrs   x5, MPUIR_EL2 >> +    and   x5, x5, #NUM_MPU_REGIONS_MASK >> + >> +    /* x0: region sel */ >> +    mov   x0, xzr >> +    /* Xen text section. */ >> +    ldr   x1, =_stext >> +    ldr   x2, =_etext >> +    prepare_xen_region x0, x1, x2, x3, x4, x5, >> attr_prbar=REGION_TEXT_PRBAR >> + >> +    /* Xen read-only data section. */ >> +    ldr   x1, =_srodata >> +    ldr   x2, =_erodata >> +    prepare_xen_region x0, x1, x2, x3, x4, x5, >> attr_prbar=REGION_RO_PRBAR > > > ... you will pass x0 (\sel) without any update from the previous call. > So effectively, you treat \sel as an input/output that will get > incremented. > > Therefore the comment needs to be updated. Possibly to: > > " > output: > > sel: Next available index in the MPU > " Yes,  makes sense. > > I will commit the series once we agree on the wording. Yes, agreed with the wording. - Ayan From xen-devel-bounces@lists.xenproject.org Mon Dec 02 15:54:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 15:54:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846747.1261891 (Exim 4.92) (envelope-from ) id 1tI8ks-0007XQ-Jb; Mon, 02 Dec 2024 15:54:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846747.1261891; Mon, 02 Dec 2024 15:54: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 1tI8ks-0007XJ-Fv; Mon, 02 Dec 2024 15:54:34 +0000 Received: by outflank-mailman (input) for mailman id 846747; Mon, 02 Dec 2024 15:54: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 1tI8kq-0007XD-6f for xen-devel@lists.xen.org; Mon, 02 Dec 2024 15:54:33 +0000 Received: from smarthost01b.ixn.mail.zen.net.uk (smarthost01b.ixn.mail.zen.net.uk [212.23.1.21]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b296e102-b0c5-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 16:54:23 +0100 (CET) Received: from [217.155.64.189] (helo=mail0.xen.dingwall.me.uk) by smarthost01b.ixn.mail.zen.net.uk with esmtpsa (TLS1.0) tls TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (Exim 4.95) (envelope-from ) id 1tI8ke-004lbS-8Z; Mon, 02 Dec 2024 15:54:21 +0000 Received: from localhost (localhost [IPv6:::1]) by mail0.xen.dingwall.me.uk (Postfix) with ESMTP id 60DE8B84841; Mon, 2 Dec 2024 15:54:24 +0000 (GMT) Received: from mail0.xen.dingwall.me.uk ([IPv6:::1]) by localhost (mail0.xen.dingwall.me.uk [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id tR1zea69a3op; Mon, 2 Dec 2024 15:54:24 +0000 (GMT) Received: from ghoul.dingwall.me.uk (ghoul.dingwall.me.uk [IPv6:2a02:8010:698e:302::c0a8:1c8]) by dingwall.me.uk (Postfix) with ESMTP id E12F4B8483A; Mon, 2 Dec 2024 15:54:23 +0000 (GMT) Received: by ghoul.dingwall.me.uk (Postfix, from userid 1000) id AED5134C; Mon, 2 Dec 2024 15:54:23 +0000 (GMT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b296e102-b0c5-11ef-99a3-01e77a169b0f X-Virus-Scanned: Debian amavisd-new at dingwall.me.uk Date: Mon, 2 Dec 2024 15:54:23 +0000 From: James Dingwall To: xen-devel@lists.xen.org Cc: Andrew Cooper , Jan Beulich , Roger Pau =?iso-8859-1?Q?Monn=E9?= , "security@xenproject.org" Subject: Re: stable-4.18: reliably crash network driver domain by squeezing free_memory Message-ID: References: <6614df33-e383-44dd-aebc-a238ad82f398@citrix.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="mynTevqUIMXVj7cQ" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6614df33-e383-44dd-aebc-a238ad82f398@citrix.com> X-Originating-smarthost01b-IP: [217.155.64.189] Feedback-ID: 217.155.64.189 --mynTevqUIMXVj7cQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Nov 28, 2024 at 03:39:07PM +0000, Andrew Cooper wrote: > On 28/11/2024 3:31 pm, James Dingwall wrote: > > Hi, > > > > We have reproducible issue with the current HEAD of the stable-4.18 branch > > which crashes a network driver domain and on some hardware subsequently > > results in a dom0 crash. > > > > `xl info` reports: free_memory : 39961, configuring a guest with > > memory = 39800 and starting it gives the log as below. This is intel > > hardware so if I've followed the code correctly I think this leads through > > to intel_iommu_map_page() from drivers/passthrough/vtd/iommu.c. > > > > The expectation is that we can safely allocate up to free_memory for a > > guest without any issue. Is there any extra logging we could enable to > > gain more information? > > For this, you really should CC the x86 maintainers, or it stands a > chance of getting missed. > > Do you have the complete serial log including boot and eventual crash ? > > -12 is -ENOMEM so something is wonky, and while dom2 is definitely dead > at this point, Xen ought to be able to unwind cleanly and not take down > dom0 too. > > ~Andrew I've attached complete serial console logs from an Intel and an AMD dom0 which show similar behaviour. The dom0 crash originally mentioned was resolved by updating a patch for OpenZFS issue #15140 and no longer occurs. During the capture of the serial console logs I noted that: 1. If the order that the domains start is different then there is no crash. Restarting the domain later will lead to the driver domain crash even without a configuration change. 2. If the domU memory is closer to free_memory but still less than the domain fails to start with libxl reporting not enough memory. So there is some undefined range for (free_memory - m) to (free_memory - n) where it is possible to crash the driver domain depending on the guest startup ordering. My (perhaps naive) reasoning would be that free_memory is the resource available to safely assign without having to allow for some unknown overhead and if I do ask for too much then I get a 'safe' failure. Thanks, James --mynTevqUIMXVj7cQ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="amd-enomem.txt" Content-Transfer-Encoding: quoted-printable (XEN) Xen version 4.18.3 (@) (gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0) de= bug=3Dy Fri Nov 15 14:08:14 UTC 2024 (XEN) Latest ChangeSet: Fri Nov 15 14:07:55 2024 +0000 git:8d7c71efb0 (XEN) build-id: c241bf4ecc9a93bbcc74e7f758c4f55a6759216f (XEN) Bootloader: GRUB 2.06-2ubuntu14.4 (XEN) Command line: placeholder console=3Dvga,com2 dom0_max_vcpus=3D4-8 dom= 0_mem=3Dmin:6144,max:65536m iommu=3Don,required,intpost,verbose,debug x2api= c=3Doff sched=3Dcredit2 flask=3Denforcing gnttab_max_frames=3D128 xpti=3Dof= f smt=3Don cpufreq=3Dxen:performance spec-ctrl=3Dgds-mit=3D0 com2=3Dirq=3D3= ,io-base=3D0xfedc9000,reg-shift=3D2 (XEN) Xen image load base address: 0x8e000000 (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 2 EDD information structures (XEN) CPU Vendor: AMD, Family 25 (0x19), Model 117 (0x75), Stepping 2 (raw = 00a70f52) (XEN) Enabling Supervisor Shadow Stacks (XEN) EFI RAM map: (XEN) [0000000000000000, 000000000009ffff] (usable) (XEN) [00000000000a0000, 00000000000fffff] (reserved) (XEN) [0000000000100000, 0000000009a7efff] (usable) (XEN) [0000000009a7f000, 0000000009ffffff] (reserved) (XEN) [000000000a000000, 000000000a1fffff] (usable) (XEN) [000000000a200000, 000000000a23bfff] (ACPI NVS) (XEN) [000000000a23c000, 0000000093c7dfff] (usable) (XEN) [0000000093c7e000, 0000000096683fff] (reserved) (XEN) [0000000096684000, 00000000966f2fff] (ACPI data) (XEN) [00000000966f3000, 000000009716dfff] (ACPI NVS) (XEN) [000000009716e000, 000000009affefff] (reserved) (XEN) [000000009afff000, 000000009bff8fff] (usable) (XEN) [000000009bff9000, 000000009bffcfff] (reserved) (XEN) [000000009bffd000, 000000009bffefff] (usable) (XEN) [000000009bfff000, 000000009cffffff] (reserved) (XEN) [000000009d790000, 000000009d7effff] (reserved) (XEN) [000000009d7f5000, 000000009fffffff] (reserved) (XEN) [00000000e0000000, 00000000efffffff] (reserved) (XEN) [00000000fd000000, 00000000ffffffff] (reserved) (XEN) [0000000100000000, 0000000fde2fffff] (usable) (XEN) [0000000fdf340000, 00000010801fffff] (reserved) (XEN) BSP microcode revision: 0x0a705205 (XEN) ACPI: RSDP 97154014, 0024 (r2 ALASKA) (XEN) ACPI: XSDT 97153728, 013C (r1 ALASKA A M I 1072009 AMI 1000013) (XEN) ACPI: FACP 966E8000, 0114 (r6 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: DSDT 966E0000, 78B7 (r2 ALASKA A M I 1072009 INTL 20200717) (XEN) ACPI: FACS 9690D000, 0040 (XEN) ACPI: SSDT 966EA000, 8416 (r2 AMD AmdTable 2 MSFT 2000002) (XEN) ACPI: SSDT 966E9000, 0221 (r2 ALASKA CPUSSDT 1072009 AMI 1072009) (XEN) ACPI: FIDT 966DF000, 009C (r1 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: MCFG 966DE000, 003C (r1 ALASKA A M I 1072009 MSFT 10013) (XEN) ACPI: HPET 966DD000, 0038 (r1 ALASKA A M I 1072009 AMI 5) (XEN) ACPI: UEFI 9690C000, 0048 (r1 ALASKA A M I 1072009 AMI 1000013) (XEN) ACPI: FPDT 966DC000, 0044 (r1 ALASKA A M I 1072009 AMI 1000013) (XEN) ACPI: VFCT 966D7000, 4284 (r1 ALASKA A M I 1 AMD 33504F47) (XEN) ACPI: TPM2 966D6000, 0044 (r5 ALASKA A M I 1 AMI 0) (XEN) ACPI: SSDT 966D0000, 547E (r2 AMD AmdTable 1 AMD 1) (XEN) ACPI: CRAT 966CF000, 0EE8 (r1 AMD AmdTable 1 AMD 1) (XEN) ACPI: CDIT 966CE000, 0029 (r1 AMD AmdTable 1 AMD 1) (XEN) ACPI: SDEV 966CD000, 0144 (r1 AMD SdevTble 1 ACPI 2) (XEN) ACPI: SSDT 966CB000, 15C8 (r2 AMD CPMDFIG2 1 INTL 20200717) (XEN) ACPI: SSDT 966C8000, 2A9E (r2 AMD CDFAAIG2 1 INTL 20200717) (XEN) ACPI: SSDT 966C6000, 1E78 (r2 AMD CPMPMF 1 INTL 20200717) (XEN) ACPI: SSDT 966C4000, 12AE (r2 AMD OEMACP 1 INTL 20200717) (XEN) ACPI: SSDT 966C3000, 08BA (r2 AMD OEMPMF 1 INTL 20200717) (XEN) ACPI: SSDT 966B9000, 98F6 (r2 AMD CPMCMN 1 INTL 20200717) (XEN) ACPI: WSMT 966B8000, 0028 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: APIC 966B7000, 00E8 (r5 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: MHSP 966B6000, 00C8 (r4 AMD AGESA 20505348 =01 = 1) (XEN) ACPI: SSDT 966B5000, 00E5 (r2 MSFT MHSP 4 INTL 20200717) (XEN) ACPI: SSDT 966B2000, 233C (r2 AMD AOD 1 INTL 20200717) (XEN) ACPI: SSDT 966B1000, 0051 (r2 AMD DRTM 1 INTL 20200717) (XEN) ACPI: IVRS 966B0000, 0198 (r2 AMD AmdTable 1 AMD 1) (XEN) ACPI: SSDT 966AF000, 0968 (r2 AMD CPMMSOSC 1 INTL 20200717) (XEN) ACPI: SSDT 966AE000, 0FF5 (r2 AMD CPMACPV5 1 INTL 20200717) (XEN) ACPI: SSDT 966AD000, 0FF7 (r2 AMD GPP_PME_ 1 INTL 20200717) (XEN) ACPI: SSDT 966A3000, 98BD (r2 AMD INTGPP03 1 INTL 20200717) (XEN) ACPI: SSDT 9669E000, 4FEB (r2 AMD INTGPP01 1 INTL 20200717) (XEN) ACPI: SSDT 9669D000, 0DA2 (r2 AMD CPMGPIO0 1 INTL 20200717) (XEN) ACPI: SSDT 9669C000, 008D (r2 AMD CPMMSLPI 1 INTL 20200717) (XEN) ACPI: SSDT 9669B000, 0501 (r2 AMD CPMSFAML 1 INTL 20200717) (XEN) System RAM: 63273MB (64791924kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-0000000fde300000 (XEN) Domain heap initialised (XEN) SMBIOS 3.5 present. (XEN) XSM Framework v1.0.1 initialized (XEN) Policy len 0x3467, start at ffff830fde1fc000. (XEN) Flask: 128 avtab hash slots, 458 rules. (XEN) Flask: 128 avtab hash slots, 458 rules. (XEN) Flask: 4 users, 3 roles, 46 types, 2 bools (XEN) Flask: 13 classes, 458 rules (XEN) Flask: Starting in enforcing mode. (XEN) AMD-Vi: IVRS Block: Found type 0x10 flags 0xb0 len 0x44 id 0x2 (XEN) AMD-Vi: IVRS Block: Found type 0x11 flags 0x30 len 0x54 id 0x2 (XEN) AMD-Vi: Using IVHD type 0x11 (XEN) AMD-Vi: Found MSI capability block at 0x64 (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x808 (32 bits) (XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0] (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:804,1:0], pm1x_evt[1:800,1:0] (XEN) ACPI: 32/64X FACS address mismatch in FADT - 9690d000/000000000000000= 0, using 32 (XEN) ACPI: wakeup_vec[9690d00c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) Overriding APIC driver with bigsmp (XEN) ACPI: IOAPIC (id[0x21] address[0xfec00000] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 33, version 33, address 0xfec00000, GSI 0-23 (XEN) ACPI: IOAPIC (id[0x22] address[0xfec01000] gsi_base[24]) (XEN) IOAPIC[1]: apic_id 34, version 33, address 0xfec01000, GSI 24-55 (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 1 low edge) (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) (XEN) ACPI: IRQ0 used by override. (XEN) ACPI: IRQ1 used by override. (XEN) ACPI: IRQ2 used by override. (XEN) ACPI: IRQ9 used by override. (XEN) ACPI: HPET id: 0x10228201 base: 0xfed00000 (XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff (XEN) PCI: MCFG area at e0000000 reserved in E820 (XEN) PCI: Using MCFG for segment 0000 bus 00-ff (XEN) Using ACPI (MADT) for SMP configuration information (XEN) SMP: Allowing 16 CPUs (0 hotplug CPUs) (XEN) IRQ limits: 56 GSI, 3272 MSI/MSI-X (XEN) Not enabling x2APIC: disabled by cmdline. (XEN) CPU0: 1600 ... 3300 MHz (XEN) xstate: size: 0x988 and states: 0x2e7 (XEN) CPU0: AMD Fam19h machine check reporting enabled (XEN) Speculative mitigation facilities: (XEN) Hardware hints: STIBP_ALWAYS IBRS_FAST IBRS_SAME_MODE (XEN) Hardware features: IBPB IBRS STIBP SSBD PSFD L1D_FLUSH (XEN) Compiled-in support: INDIRECT_THUNK SHADOW_PAGING HARDEN_ARRAY HARD= EN_BRANCH HARDEN_GUEST_ACCESS HARDEN_LOCK (XEN) Xen settings: BTI-Thunk: JMP, SPEC_CTRL: IBRS+ STIBP+ SSBD- PSFD-, = Other: BRANCH_HARDEN (XEN) Support for HVM VMs: MSR_SPEC_CTRL MSR_VIRT_SPEC_CTRL RSB IBPB-entry (XEN) Support for PV VMs: IBPB-entry (XEN) XPTI (64-bit PV only): Dom0 disabled, DomU disabled (without PCID) (XEN) PV L1TF shadowing: Dom0 disabled, DomU disabled (XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2) (XEN) Initializing Credit2 scheduler (XEN) load_precision_shift: 18 (XEN) load_window_shift: 30 (XEN) underload_balance_tolerance: 0 (XEN) overload_balance_tolerance: -3 (XEN) runqueues arrangement: socket (XEN) cap enforcement granularity: 10ms (XEN) load tracking window length 1073741824 ns (XEN) Platform timer is 14.318MHz HPET (XEN) Detected 3293.813 MHz processor. (XEN) Freed 1016kB unused BSS memory (XEN) EFI memory map: (XEN) 0000000000000-0000000007fff type=3D2 attr=3D000000000000000f (XEN) 0000000008000-000000008efff type=3D7 attr=3D000000000000000f (XEN) 000000008f000-000000009efff type=3D2 attr=3D000000000000000f (XEN) 000000009f000-000000009ffff type=3D4 attr=3D000000000000000f (XEN) 0000000100000-0000000ffffff type=3D7 attr=3D000000000000000f (XEN) 0000001000000-000000107ffff type=3D4 attr=3D000000000000000f (XEN) 0000001080000-0000002104fff type=3D2 attr=3D000000000000000f (XEN) 0000002105000-0000009a7efff type=3D7 attr=3D000000000000000f (XEN) 0000009a7f000-0000009ffffff type=3D0 attr=3D000000000000000f (XEN) 000000a000000-000000a1fffff type=3D7 attr=3D000000000000000f (XEN) 000000a200000-000000a23bfff type=3D10 attr=3D000000000000000f (XEN) 000000a23c000-0000012d96fff type=3D2 attr=3D000000000000000f (XEN) 0000012d97000-000007441efff type=3D7 attr=3D000000000000000f (XEN) 000007441f000-000007fffefff type=3D1 attr=3D000000000000000f (XEN) 000007ffff000-000008e1fffff type=3D7 attr=3D000000000000000f (XEN) 000008e200000-000008e62afff type=3D2 attr=3D000000000000000f (XEN) 000008e62b000-000008e7aafff type=3D7 attr=3D000000000000000f (XEN) 000008e7ab000-000008ea25fff type=3D1 attr=3D000000000000000f (XEN) 000008ea26000-000008eca2fff type=3D2 attr=3D000000000000000f (XEN) 000008eca3000-000008eca4fff type=3D7 attr=3D000000000000000f (XEN) 000008eca5000-000008eca5fff type=3D2 attr=3D000000000000000f (XEN) 000008eca6000-000008ed7cfff type=3D1 attr=3D000000000000000f (XEN) 000008ed7d000-000008f67efff type=3D4 attr=3D000000000000000f (XEN) 000008f67f000-000008f807fff type=3D7 attr=3D000000000000000f (XEN) 000008f808000-000008f809fff type=3D4 attr=3D000000000000000f (XEN) 000008f80a000-000008f8eafff type=3D7 attr=3D000000000000000f (XEN) 000008f8eb000-000009347efff type=3D4 attr=3D000000000000000f (XEN) 000009347f000-0000093617fff type=3D7 attr=3D000000000000000f (XEN) 0000093618000-0000093c7dfff type=3D3 attr=3D000000000000000f (XEN) 0000093c7e000-0000096683fff type=3D0 attr=3D000000000000000f (XEN) 0000096684000-00000966f2fff type=3D9 attr=3D000000000000000f (XEN) 00000966f3000-000009716dfff type=3D10 attr=3D000000000000000f (XEN) 000009716e000-000009af7afff type=3D6 attr=3D800000000000000f (XEN) 000009af7b000-000009affefff type=3D5 attr=3D800000000000000f (XEN) 000009afff000-000009b5fffff type=3D4 attr=3D000000000000000f (XEN) 000009b600000-000009b697fff type=3D7 attr=3D000000000000000f (XEN) 000009b698000-000009b797fff type=3D4 attr=3D000000000000000f (XEN) 000009b798000-000009b7bafff type=3D3 attr=3D000000000000000f (XEN) 000009b7bb000-000009be40fff type=3D4 attr=3D000000000000000f (XEN) 000009be41000-000009be5dfff type=3D3 attr=3D000000000000000f (XEN) 000009be5e000-000009be78fff type=3D4 attr=3D000000000000000f (XEN) 000009be79000-000009be88fff type=3D3 attr=3D000000000000000f (XEN) 000009be89000-000009be9afff type=3D4 attr=3D000000000000000f (XEN) 000009be9b000-000009bea2fff type=3D3 attr=3D000000000000000f (XEN) 000009bea3000-000009bebafff type=3D4 attr=3D000000000000000f (XEN) 000009bebb000-000009bebefff type=3D3 attr=3D000000000000000f (XEN) 000009bebf000-000009bed2fff type=3D4 attr=3D000000000000000f (XEN) 000009bed3000-000009bee5fff type=3D3 attr=3D000000000000000f (XEN) 000009bee6000-000009bfeffff type=3D4 attr=3D000000000000000f (XEN) 000009bff0000-000009bff6fff type=3D3 attr=3D000000000000000f (XEN) 000009bff7000-000009bff8fff type=3D4 attr=3D000000000000000f (XEN) 000009bff9000-000009bffcfff type=3D6 attr=3D800000000000000f (XEN) 000009bffd000-000009bffefff type=3D4 attr=3D000000000000000f (XEN) 000009bfff000-000009bffffff type=3D6 attr=3D800000000000000f (XEN) 0000100000000-0000fde2fffff type=3D7 attr=3D000000000000000f (XEN) 00000000a0000-00000000fffff type=3D0 attr=3D000000000000000f (XEN) 000009c000000-000009cffffff type=3D0 attr=3D000000000000000f (XEN) 000009d790000-000009d7effff type=3D0 attr=3D000000000000000f (XEN) 000009d7f5000-000009fffffff type=3D0 attr=3D000000000000000f (XEN) 00000e0000000-00000efffffff type=3D11 attr=3D800000000000100d (XEN) 00000fd000000-00000fedfffff type=3D11 attr=3D800000000000100d (XEN) 00000fee00000-00000fee00fff type=3D11 attr=3D8000000000000001 (XEN) 00000fee01000-00000ffffffff type=3D11 attr=3D800000000000100d (XEN) 0000fdf340000-000105fffffff type=3D0 attr=3D000000000000000f (XEN) 0001060000000-00010801fffff type=3D11 attr=3D800000000000100d (XEN) alt table ffff82d040489b58 -> ffff82d04049c5c6 (XEN) AMD-Vi: IOMMU Extended Features: (XEN) - Peripheral Page Service Request (XEN) - NX bit (XEN) - Invalidate All Command (XEN) - Guest APIC (XEN) - Performance Counters (XEN) - Host Address Translation Size: 0x2 (XEN) - Guest Address Translation Size: 0 (XEN) - Guest CR3 Root Table Level: 0x1 (XEN) - Maximum PASID: 0xf (XEN) - SMI Filter Register: 0x1 (XEN) - SMI Filter Register Count: 0x1 (XEN) - Guest Virtual APIC Modes: 0 (XEN) - Dual PPR Log: 0x2 (XEN) - Dual Event Log: 0x2 (XEN) - Secure ATS (XEN) - User / Supervisor Page Protection (XEN) - Device Table Segmentation: 0x3 (XEN) - PPR Log Overflow Early Warning (XEN) - PPR Automatic Response (XEN) - Memory Access Routing and Control: 0x1 (XEN) - Block StopMark Message (XEN) - Performance Optimization (XEN) - MSI Capability MMIO Access (XEN) - Guest I/O Protection (XEN) - Enhanced PPR Handling (XEN) - Invalidate IOTLB Type (XEN) - VM Table Size: 0x2 (XEN) - Guest Access Bit Update Disable (XEN) AMD-Vi: ACPI Table: (XEN) AMD-Vi: Signature IVRS (XEN) AMD-Vi: Length 0x198 (XEN) AMD-Vi: Revision 0x2 (XEN) AMD-Vi: CheckSum 0xc0 (XEN) AMD-Vi: OEM_Id AMD =20 (XEN) AMD-Vi: OEM_Table_Id AmdTable (XEN) AMD-Vi: OEM_Revision 0x1 (XEN) AMD-Vi: Creator_Id AMD=20 (XEN) AMD-Vi: Creator_Revision 0x1 (XEN) AMD-Vi: IVRS Block: type 0x10 flags 0xb0 len 0x44 id 0x2 (XEN) AMD-Vi: IVRS Block: type 0x11 flags 0x30 len 0x54 id 0x2 (XEN) AMD-Vi: IVHD Device Entry: type 0x3 id 0x3 flags 0 (XEN) AMD-Vi: Dev_Id Range: 0x3 -> 0xfffe (XEN) AMD-Vi: IVHD Device Entry: type 0x43 id 0xff00 flags 0 (XEN) AMD-Vi: Dev_Id Range: 0xff00 -> 0xffff alias 0xa5 (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0 (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x2 handle 0 (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0xd7 (XEN) AMD-Vi: IVHD Special: 0000:00:14.0 variety 0x1 handle 0x21 (XEN) AMD-Vi: IVHD Device Entry: type 0x48 id 0 flags 0 (XEN) AMD-Vi: IVHD Special: 0000:00:00.1 variety 0x1 handle 0x22 (XEN) AMD-Vi: IVRS Block: type 0x40 flags 0x30 len 0xd0 id 0x2 (XEN) AMD-Vi: Disabled HAP memory map sharing with IOMMU (XEN) AMD-Vi: using 256-entry cmd ring(s) (XEN) AMD-Vi: PPR Log Enabled. (XEN) AMD-Vi: Guest Translation Enabled. (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) Interrupt remapping enabled (XEN) nr_sockets: 1 (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) Enabling APIC mode. Using 2 I/O APICs (XEN) ENABLING IO-APIC IRQs (XEN) -> Using old ACK method (XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D-1 pin2=3D-1 (XEN) Allocated console ring of 128 KiB. (XEN) mwait-idle: does not run on family 25 model 117 (XEN) HVM: ASIDs enabled. (XEN) SVM: Supported advanced features: (XEN) - Nested Page Tables (NPT) (XEN) - Last Branch Record (LBR) Virtualisation (XEN) - Next-RIP Saved on #VMEXIT (XEN) - VMCB Clean Bits (XEN) - DecodeAssists (XEN) - Virtual VMLOAD/VMSAVE (XEN) - Virtual GIF (XEN) - Pause-Intercept Filter (XEN) - Pause-Intercept Filter Threshold (XEN) - TSC Rate MSR (XEN) - NPT Supervisor Shadow Stack (XEN) - MSR_SPEC_CTRL virtualisation (XEN) HVM: SVM enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB (XEN) alt table ffff82d040489b58 -> ffff82d04049c5c6 (XEN) cpu10: spurious 8259A interrupt: IRQ7 (XEN) Brought up 16 CPUs (XEN) Scheduling granularity: cpu, 1 CPU per sched-resource (XEN) Initializing Credit2 scheduler (XEN) load_precision_shift: 18 (XEN) load_window_shift: 30 (XEN) underload_balance_tolerance: 0 (XEN) overload_balance_tolerance: -3 (XEN) runqueues arrangement: socket (XEN) cap enforcement granularity: 10ms (XEN) load tracking window length 1073741824 ns (XEN) Adding cpu 0 to runqueue 0 (XEN) First cpu on runqueue, activating (XEN) Adding cpu 1 to runqueue 0 (XEN) Adding cpu 2 to runqueue 0 (XEN) Adding cpu 3 to runqueue 0 (XEN) Adding cpu 4 to runqueue 0 (XEN) Adding cpu 5 to runqueue 0 (XEN) Adding cpu 6 to runqueue 0 (XEN) Adding cpu 7 to runqueue 0 (XEN) Adding cpu 8 to runqueue 0 (XEN) Adding cpu 9 to runqueue 0 (XEN) Adding cpu 10 to runqueue 0 (XEN) Adding cpu 11 to runqueue 0 (XEN) Adding cpu 12 to runqueue 0 (XEN) Adding cpu 13 to runqueue 0 (XEN) Adding cpu 14 to runqueue 0 (XEN) Adding cpu 15 to runqueue 0 (XEN) mcheck_poll: Machine check polling timer started. (XEN) Running stub recovery selftests... (XEN) Fixup #UD[0000]: ffff82d07fffe044 [ffff82d07fffe044] -> ffff82d04038a= 141 (XEN) Fixup #GP[0000]: ffff82d07fffe045 [ffff82d07fffe045] -> ffff82d04038a= 141 (XEN) Fixup #SS[0000]: ffff82d07fffe044 [ffff82d07fffe044] -> ffff82d04038a= 141 (XEN) Fixup #BP[0000]: ffff82d07fffe045 [ffff82d07fffe045] -> ffff82d04038a= 141 (XEN) NX (Execute Disable) protection active (XEN) d0 has maximum 1096 PIRQs (XEN) *** Building a PV Dom0 *** (XEN) Xen kernel: 64-bit, lsb (XEN) Dom0 kernel: 64-bit, lsb, paddr 0x1000000 -> 0x4800000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000fa0000000->0000000fa8000000 (15902088 pages to= be allocated) (XEN) Init. ramdisk: 0000000fd56a1000->0000000fde1fb724 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff84800000 (XEN) Phys-Mach map: 0000008000000000->00000080079d8718 (XEN) Start info: ffffffff84800000->ffffffff848004b8 (XEN) Page tables: ffffffff84801000->ffffffff8482a000 (XEN) Boot stack: ffffffff8482a000->ffffffff8482b000 (XEN) TOTAL: ffffffff80000000->ffffffff84c00000 (XEN) ENTRY ADDRESS: ffffffff838c48c0 (XEN) Dom0 has maximum 8 VCPUs (XEN) AMD-Vi: Skipping host bridge 0000:00:00.0 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x8, type =3D 0x6, root t= able =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x9, type =3D 0x2, root t= able =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0xb, type =3D 0x2, root t= able =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x10, type =3D 0x6, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x11, type =3D 0x2, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x12, type =3D 0x2, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x13, type =3D 0x2, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x14, type =3D 0x2, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x18, type =3D 0x6, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x20, type =3D 0x6, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x40, type =3D 0x6, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x41, type =3D 0x2, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x42, type =3D 0x2, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x43, type =3D 0x2, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0xa0, type =3D 0x7, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0xa3, type =3D 0x7, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0xc0, type =3D 0x6, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0xc1, type =3D 0x6, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0xc2, type =3D 0x6, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0xc3, type =3D 0x6, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0xc4, type =3D 0x6, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0xc5, type =3D 0x6, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0xc6, type =3D 0x6, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0xc7, type =3D 0x6, root = table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x100, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x200, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x300, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x400, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x500, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x600, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x700, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x701, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x702, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x703, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x704, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x705, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x706, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x707, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x800, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x801, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x900, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x903, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x904, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Scrubbing Free RAM in background (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) (XEN) Re-running stub recovery selftests... (XEN) Fixup #UD[0000]: ffff82d07fffe044 [ffff82d07fffe044] -> ffff82d04038a= 141 (XEN) Fixup #GP[0000]: ffff82d07fffe045 [ffff82d07fffe045] -> ffff82d04038a= 141 (XEN) Fixup #SS[0000]: ffff82d07fffe044 [ffff82d07fffe044] -> ffff82d04038a= 141 (XEN) Fixup #BP[0000]: ffff82d07fffe045 [ffff82d07fffe045] -> ffff82d04038a= 141 (XEN) Freed 700kB init memory mapping kernel into physical memory about to get started... [ 0.000000] Linux version 6.8.0-48-generic (root@a5570d9c6ad5) (x86_64-l= inux-gnu-gcc-12 (Ubuntu 12.3.0-1ubuntu1~22.04) 12.3.0, GNU ld (GNU Binutils= for Ubuntu) 2.38) #48~22.04.1 SMP PREEMPT_DYNAMIC Tue Nov 26 23:18:34 UTC = (Ubuntu 6.8.0-48.48~22.04.1-generic 6.8.12) [ 0.000000] Command line: console=3Dhvc0 console=3Dtty1 earlyprintk=3Dxe= n xen-pciback.passthrough=3D1 oops=3Dpanic panic=3D15 root=3D/dev/loop0 ro = rootfstype=3Dext4 zyimage=3Dzvol:xvda1@ref5030000 zyoverlay pstore.backend= =3Defi libata.fua=3D1 audit=3D1 nohz=3Doff consoleblank=3D0 modprobe.blackl= ist=3D8250_dw [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Hygon HygonGenuine [ 0.000000] Centaur CentaurHauls [ 0.000000] zhaoxin Shanghai =20 [ 0.000000] [Firmware Bug]: TSC doesn't count with P0 frequency! [ 0.000000] initrd moved from [mem 0x08000000-0x10b5a724] to [mem 0x1853= 7000-0x21091724] [ 0.000000] Released 0 page(s) [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: [mem 0x0000000000000000-0x000000000007ffff] usable [ 0.000000] Xen: [mem 0x0000000000080000-0x00000000000fffff] reserved [ 0.000000] Xen: [mem 0x0000000000100000-0x0000000009a7efff] usable [ 0.000000] Xen: [mem 0x0000000009a7f000-0x0000000009ffffff] reserved [ 0.000000] Xen: [mem 0x000000000a000000-0x000000000a1fffff] usable [ 0.000000] Xen: [mem 0x000000000a200000-0x000000000a23bfff] ACPI NVS [ 0.000000] Xen: [mem 0x000000000a23c000-0x0000000093c7dfff] usable [ 0.000000] Xen: [mem 0x0000000093c7e000-0x0000000096683fff] reserved [ 0.000000] Xen: [mem 0x0000000096684000-0x00000000966f2fff] ACPI data [ 0.000000] Xen: [mem 0x00000000966f3000-0x000000009716dfff] ACPI NVS [ 0.000000] Xen: [mem 0x000000009716e000-0x000000009affefff] reserved [ 0.000000] Xen: [mem 0x000000009afff000-0x000000009bff8fff] usable [ 0.000000] Xen: [mem 0x000000009bff9000-0x000000009bffcfff] reserved [ 0.000000] Xen: [mem 0x000000009bffd000-0x000000009bffefff] usable [ 0.000000] Xen: [mem 0x000000009bfff000-0x000000009cffffff] reserved [ 0.000000] Xen: [mem 0x000000009d790000-0x000000009d7effff] reserved [ 0.000000] Xen: [mem 0x000000009d7f5000-0x000000009fffffff] reserved [ 0.000000] Xen: [mem 0x00000000e0000000-0x00000000efffffff] reserved [ 0.000000] Xen: [mem 0x00000000fd000000-0x00000000ffffffff] reserved [ 0.000000] Xen: [mem 0x0000000100000000-0x0000000fde2fffff] usable [ 0.000000] Xen: [mem 0x0000000fdf340000-0x00000010801fffff] reserved [ 0.000000] printk: legacy bootconsole [xenboot0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] APIC: Static calls initialized [ 0.000000] efi: EFI v2.8 by American Megatrends [ 0.000000] efi: ACPI=3D0x97154000 ACPI 2.0=3D0x97154014 TPMFinalLog=3D0= x97120000 SMBIOS=3D0x9ad65000 SMBIOS 3.0=3D0x9ad64000 (MEMATTR=3D0x8f8eb098= unusable) ESRT=3D0x9669a018 MOKvar=3D0x9adc2000=20 [ 0.000000] secureboot: Secure boot disabled [ 0.000000] SMBIOS 3.5.0 present. [ 0.000000] DMI: Simply NUC EES24E32r8/EES24E32r8B, BIOS 0ACTF_SR_000_33= 05/31/2024 [ 0.000000] Hypervisor detected: Xen PV [ 0.026632] tsc: Fast TSC calibration using PIT [ 0.026634] tsc: Detected 3293.815 MHz processor [ 0.026635] tsc: Detected 3293.812 MHz TSC [ 0.026716] last_pfn =3D 0xfde300 max_arch_pfn =3D 0x400000000 [ 0.026719] MTRR map: 1 entries (0 fixed + 1 variable; max 16), built fr= om 8 variable MTRRs [ 0.026720] MTRRs set to read-only [ 0.026723] x86/PAT: Configuration [0-7]: WB WT UC- UC WC WP UC UC= =20 [ 0.026725] last_pfn =3D 0x9bfff max_arch_pfn =3D 0x400000000 [ 0.026744] esrt: Reserving ESRT space from 0x000000009669a018 to 0x0000= 00009669a050. [ 0.966402] secureboot: Secure boot disabled [ 0.966423] RAMDISK: [mem 0x18537000-0x21091fff] [ 0.966430] ACPI: Early table checksum verification disabled [ 0.966437] ACPI: RSDP 0x0000000097154014 000024 (v02 ALASKA) [ 0.966444] ACPI: XSDT 0x0000000097153728 00013C (v01 ALASKA A M I 01= 072009 AMI 01000013) [ 0.966486] ACPI: FACP 0x00000000966E8000 000114 (v06 ALASKA A M I 01= 072009 AMI 00010013) [ 0.966527] ACPI: DSDT 0x00000000966E0000 0078B7 (v02 ALASKA A M I 01= 072009 INTL 20200717) [ 0.966532] ACPI: FACS 0x000000009690D000 000040 [ 0.966537] ACPI: SSDT 0x00000000966EA000 008416 (v02 AMD AmdTable 00= 000002 MSFT 02000002) [ 0.966564] ACPI: SSDT 0x00000000966E9000 000221 (v02 ALASKA CPUSSDT 01= 072009 AMI 01072009) [ 0.966569] ACPI: FIDT 0x00000000966DF000 00009C (v01 ALASKA A M I 01= 072009 AMI 00010013) [ 0.966574] ACPI: MCFG 0x00000000966DE000 00003C (v01 ALASKA A M I 01= 072009 MSFT 00010013) [ 0.966579] ACPI: HPET 0x00000000966DD000 000038 (v01 ALASKA A M I 01= 072009 AMI 00000005) [ 0.966584] ACPI: UEFI 0x000000009690C000 000048 (v01 ALASKA A M I 01= 072009 AMI 01000013) [ 0.966589] ACPI: FPDT 0x00000000966DC000 000044 (v01 ALASKA A M I 01= 072009 AMI 01000013) [ 0.966594] ACPI: VFCT 0x00000000966D7000 004284 (v01 ALASKA A M I 00= 000001 AMD 33504F47) [ 0.966599] ACPI: TPM2 0x00000000966D6000 000044 (v05 ALASKA A M I 00= 000001 AMI 00000000) [ 0.966604] ACPI: SSDT 0x00000000966D0000 00547E (v02 AMD AmdTable 00= 000001 AMD 00000001) [ 0.966609] ACPI: CRAT 0x00000000966CF000 000EE8 (v01 AMD AmdTable 00= 000001 AMD 00000001) [ 0.966614] ACPI: CDIT 0x00000000966CE000 000029 (v01 AMD AmdTable 00= 000001 AMD 00000001) [ 0.966619] ACPI: SDEV 0x00000000966CD000 000144 (v01 AMD SdevTble 00= 000001 ACPI 00000002) [ 0.966624] ACPI: SSDT 0x00000000966CB000 0015C8 (v02 AMD CPMDFIG2 00= 000001 INTL 20200717) [ 0.966629] ACPI: SSDT 0x00000000966C8000 002A9E (v02 AMD CDFAAIG2 00= 000001 INTL 20200717) [ 0.966634] ACPI: SSDT 0x00000000966C6000 001E78 (v02 AMD CPMPMF 00= 000001 INTL 20200717) [ 0.966639] ACPI: SSDT 0x00000000966C4000 0012AE (v02 AMD OEMACP 00= 000001 INTL 20200717) [ 0.966644] ACPI: SSDT 0x00000000966C3000 0008BA (v02 AMD OEMPMF 00= 000001 INTL 20200717) [ 0.966649] ACPI: SSDT 0x00000000966B9000 0098F6 (v02 AMD CPMCMN 00= 000001 INTL 20200717) [ 0.966654] ACPI: WSMT 0x00000000966B8000 000028 (v01 ALASKA A M I 01= 072009 AMI 00010013) [ 0.966658] ACPI: APIC 0x00000000966B7000 0000E8 (v05 ALASKA A M I 01= 072009 AMI 00010013) [ 0.966664] ACPI: MHSP 0x00000000966B6000 0000C8 (v04 AMD AGESA 20= 505348 ? 00000001) [ 0.966669] ACPI: SSDT 0x00000000966B5000 0000E5 (v02 MSFT MHSP 00= 000004 INTL 20200717) [ 0.966674] ACPI: SSDT 0x00000000966B2000 00233C (v02 AMD AOD 00= 000001 INTL 20200717) [ 0.966678] ACPI: SSDT 0x00000000966B1000 000051 (v02 AMD DRTM 00= 000001 INTL 20200717) [ 0.966683] ACPI: IVRS 0x00000000966B0000 000198 (v02 AMD AmdTable 00= 000001 AMD 00000001) [ 0.966688] ACPI: SSDT 0x00000000966AF000 000968 (v02 AMD CPMMSOSC 00= 000001 INTL 20200717) [ 0.966693] ACPI: SSDT 0x00000000966AE000 000FF5 (v02 AMD CPMACPV5 00= 000001 INTL 20200717) [ 0.966698] ACPI: SSDT 0x00000000966AD000 000FF7 (v02 AMD GPP_PME_ 00= 000001 INTL 20200717) [ 0.966703] ACPI: SSDT 0x00000000966A3000 0098BD (v02 AMD INTGPP03 00= 000001 INTL 20200717) [ 0.966708] ACPI: SSDT 0x000000009669E000 004FEB (v02 AMD INTGPP01 00= 000001 INTL 20200717) [ 0.966713] ACPI: SSDT 0x000000009669D000 000DA2 (v02 AMD CPMGPIO0 00= 000001 INTL 20200717) [ 0.966718] ACPI: SSDT 0x000000009669C000 00008D (v02 AMD CPMMSLPI 00= 000001 INTL 20200717) [ 0.966723] ACPI: SSDT 0x000000009669B000 000501 (v02 AMD CPMSFAML 00= 000001 INTL 20200717) [ 0.966726] ACPI: Reserving FACP table memory at [mem 0x966e8000-0x966e8= 113] [ 0.966728] ACPI: Reserving DSDT table memory at [mem 0x966e0000-0x966e7= 8b6] [ 0.966729] ACPI: Reserving FACS table memory at [mem 0x9690d000-0x9690d= 03f] [ 0.966730] ACPI: Reserving SSDT table memory at [mem 0x966ea000-0x966f2= 415] [ 0.966731] ACPI: Reserving SSDT table memory at [mem 0x966e9000-0x966e9= 220] [ 0.966732] ACPI: Reserving FIDT table memory at [mem 0x966df000-0x966df= 09b] [ 0.966733] ACPI: Reserving MCFG table memory at [mem 0x966de000-0x966de= 03b] [ 0.966734] ACPI: Reserving HPET table memory at [mem 0x966dd000-0x966dd= 037] [ 0.966735] ACPI: Reserving UEFI table memory at [mem 0x9690c000-0x9690c= 047] [ 0.966737] ACPI: Reserving FPDT table memory at [mem 0x966dc000-0x966dc= 043] [ 0.966738] ACPI: Reserving VFCT table memory at [mem 0x966d7000-0x966db= 283] [ 0.966739] ACPI: Reserving TPM2 table memory at [mem 0x966d6000-0x966d6= 043] [ 0.966740] ACPI: Reserving SSDT table memory at [mem 0x966d0000-0x966d5= 47d] [ 0.966741] ACPI: Reserving CRAT table memory at [mem 0x966cf000-0x966cf= ee7] [ 0.966742] ACPI: Reserving CDIT table memory at [mem 0x966ce000-0x966ce= 028] [ 0.966743] ACPI: Reserving SDEV table memory at [mem 0x966cd000-0x966cd= 143] [ 0.966744] ACPI: Reserving SSDT table memory at [mem 0x966cb000-0x966cc= 5c7] [ 0.966745] ACPI: Reserving SSDT table memory at [mem 0x966c8000-0x966ca= a9d] [ 0.966746] ACPI: Reserving SSDT table memory at [mem 0x966c6000-0x966c7= e77] [ 0.966747] ACPI: Reserving SSDT table memory at [mem 0x966c4000-0x966c5= 2ad] [ 0.966749] ACPI: Reserving SSDT table memory at [mem 0x966c3000-0x966c3= 8b9] [ 0.966750] ACPI: Reserving SSDT table memory at [mem 0x966b9000-0x966c2= 8f5] [ 0.966751] ACPI: Reserving WSMT table memory at [mem 0x966b8000-0x966b8= 027] [ 0.966752] ACPI: Reserving APIC table memory at [mem 0x966b7000-0x966b7= 0e7] [ 0.966753] ACPI: Reserving MHSP table memory at [mem 0x966b6000-0x966b6= 0c7] [ 0.966754] ACPI: Reserving SSDT table memory at [mem 0x966b5000-0x966b5= 0e4] [ 0.966755] ACPI: Reserving SSDT table memory at [mem 0x966b2000-0x966b4= 33b] [ 0.966756] ACPI: Reserving SSDT table memory at [mem 0x966b1000-0x966b1= 050] [ 0.966757] ACPI: Reserving IVRS table memory at [mem 0x966b0000-0x966b0= 197] [ 0.966759] ACPI: Reserving SSDT table memory at [mem 0x966af000-0x966af= 967] [ 0.966760] ACPI: Reserving SSDT table memory at [mem 0x966ae000-0x966ae= ff4] [ 0.966761] ACPI: Reserving SSDT table memory at [mem 0x966ad000-0x966ad= ff6] [ 0.966762] ACPI: Reserving SSDT table memory at [mem 0x966a3000-0x966ac= 8bc] [ 0.966763] ACPI: Reserving SSDT table memory at [mem 0x9669e000-0x966a2= fea] [ 0.966764] ACPI: Reserving SSDT table memory at [mem 0x9669d000-0x9669d= da1] [ 0.966765] ACPI: Reserving SSDT table memory at [mem 0x9669c000-0x9669c= 08c] [ 0.966766] ACPI: Reserving SSDT table memory at [mem 0x9669b000-0x9669b= 500] [ 0.966827] APIC: Switched APIC routing to: Xen PV [ 0.966863] NUMA turned off [ 0.966864] Faking a node at [mem 0x0000000000000000-0x0000000fde2fffff] [ 0.966870] NODE_DATA(0) allocated [mem 0xf3b0b8000-0xf3b0e2fff] [ 1.052384] Zone ranges: [ 1.052388] DMA [mem 0x0000000000001000-0x0000000000ffffff] [ 1.052390] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] [ 1.052392] Normal [mem 0x0000000100000000-0x0000000fde2fffff] [ 1.052393] Device empty [ 1.052395] Movable zone start for each node [ 1.052396] Early memory node ranges [ 1.052397] node 0: [mem 0x0000000000001000-0x000000000007ffff] [ 1.052399] node 0: [mem 0x0000000000100000-0x0000000009a7efff] [ 1.052400] node 0: [mem 0x000000000a000000-0x000000000a1fffff] [ 1.052401] node 0: [mem 0x000000000a23c000-0x0000000093c7dfff] [ 1.052403] node 0: [mem 0x000000009afff000-0x000000009bff8fff] [ 1.052404] node 0: [mem 0x000000009bffd000-0x000000009bffefff] [ 1.052405] node 0: [mem 0x0000000100000000-0x0000000fde2fffff] [ 1.052410] Initmem setup node 0 [mem 0x0000000000001000-0x0000000fde2ff= fff] [ 1.052416] On node 0, zone DMA: 1 pages in unavailable ranges [ 1.052429] On node 0, zone DMA: 128 pages in unavailable ranges [ 1.052539] On node 0, zone DMA32: 1409 pages in unavailable ranges [ 1.054214] On node 0, zone DMA32: 60 pages in unavailable ranges [ 1.054384] On node 0, zone DMA32: 29569 pages in unavailable ranges [ 1.054401] On node 0, zone DMA32: 4 pages in unavailable ranges [ 1.090715] On node 0, zone Normal: 16385 pages in unavailable ranges [ 1.090770] On node 0, zone Normal: 7424 pages in unavailable ranges [ 1.090773] p2m virtual area at (____ptrval____), size is 40000000 [ 1.337431] Remapped 440771 page(s) [ 1.338130] ACPI: PM-Timer IO Port: 0x808 [ 1.338186] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) [ 1.338208] IOAPIC[0]: apic_id 33, version 33, address 0xfec00000, GSI 0= -23 [ 1.338215] IOAPIC[1]: apic_id 34, version 33, address 0xfec01000, GSI 2= 4-55 [ 1.338223] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 1.338226] ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 1 low edge) [ 1.338229] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) [ 1.338243] ACPI: Using ACPI (MADT) for SMP configuration information [ 1.338245] ACPI: HPET id: 0x10228201 base: 0xfed00000 [ 1.338675] smpboot: Allowing 8 CPUs, 0 hotplug CPUs [ 1.338689] PM: hibernation: Registered nosave memory: [mem 0x00000000-0= x00000fff] [ 1.338691] PM: hibernation: Registered nosave memory: [mem 0x00080000-0= x000fffff] [ 1.338693] PM: hibernation: Registered nosave memory: [mem 0x09a7f000-0= x09ffffff] [ 1.338694] PM: hibernation: Registered nosave memory: [mem 0x0a200000-0= x0a23bfff] [ 1.338696] PM: hibernation: Registered nosave memory: [mem 0x93c7e000-0= x96683fff] [ 1.338697] PM: hibernation: Registered nosave memory: [mem 0x96684000-0= x966f2fff] [ 1.338698] PM: hibernation: Registered nosave memory: [mem 0x966f3000-0= x9716dfff] [ 1.338699] PM: hibernation: Registered nosave memory: [mem 0x9716e000-0= x9affefff] [ 1.338701] PM: hibernation: Registered nosave memory: [mem 0x9bff9000-0= x9bffcfff] [ 1.338703] PM: hibernation: Registered nosave memory: [mem 0x9bfff000-0= x9cffffff] [ 1.338704] PM: hibernation: Registered nosave memory: [mem 0x9d000000-0= x9d78ffff] [ 1.338705] PM: hibernation: Registered nosave memory: [mem 0x9d790000-0= x9d7effff] [ 1.338706] PM: hibernation: Registered nosave memory: [mem 0x9d7f0000-0= x9d7f4fff] [ 1.338707] PM: hibernation: Registered nosave memory: [mem 0x9d7f5000-0= x9fffffff] [ 1.338708] PM: hibernation: Registered nosave memory: [mem 0xa0000000-0= xdfffffff] [ 1.338709] PM: hibernation: Registered nosave memory: [mem 0xe0000000-0= xefffffff] [ 1.338710] PM: hibernation: Registered nosave memory: [mem 0xf0000000-0= xfcffffff] [ 1.338711] PM: hibernation: Registered nosave memory: [mem 0xfd000000-0= xffffffff] [ 1.338713] [mem 0xa0000000-0xdfffffff] available for PCI devices [ 1.338720] Booting kernel on Xen [ 1.338721] Xen version: 4.18.3 (preserve-AD) [ 1.338724] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0= xffffffff, max_idle_ns: 1910969940391419 ns [ 1.338732] setup_percpu: NR_CPUS:8192 nr_cpumask_bits:8 nr_cpu_ids:8 nr= _node_ids:1 [ 1.338982] percpu: Embedded 86 pages/cpu s229376 r8192 d114688 u524288 [ 1.339028] PV qspinlock hash table entries: 256 (order: 0, 4096 bytes, = linear) [ 1.339031] Kernel command line: console=3Dhvc0 console=3Dtty1 earlyprin= tk=3Dxen xen-pciback.passthrough=3D1 oops=3Dpanic panic=3D15 root=3D/dev/lo= op0 ro rootfstype=3Dext4 zyimage=3Dzvol:xvda1@ref5030000 zyoverlay pstore.b= ackend=3Defi libata.fua=3D1 audit=3D1 nohz=3Doff consoleblank=3D0 modprobe.= blacklist=3D8250_dw [ 1.339108] audit: enabled (after initialization) [ 1.339124] Unknown kernel command line parameters "zyoverlay zyimage=3D= zvol:xvda1@ref5030000", will be passed to user space. [ 1.339316] random: crng init done [ 1.342318] Dentry cache hash table entries: 8388608 (order: 14, 6710886= 4 bytes, linear) [ 1.343852] Inode-cache hash table entries: 4194304 (order: 13, 33554432= bytes, linear) [ 1.343993] Fallback order for Node 0: 0=20 [ 1.343997] Built 1 zonelists, mobility grouping on. Total pages: 15944= 838 [ 1.344000] Policy zone: Normal [ 1.344009] mem auto-init: stack:all(zero), heap alloc:on, heap free:off [ 1.344012] software IO TLB: area num 8. [ 1.454324] Memory: 62248564K/64791792K available (22528K kernel code, 4= 438K rwdata, 13964K rodata, 4972K init, 4740K bss, 2542976K reserved, 0K cm= a-reserved) [ 1.455150] SLUB: HWalign=3D64, Order=3D0-3, MinObjects=3D0, CPUs=3D8, N= odes=3D1 Poking KASLR using RDRAND RDTSC... [ 1.455490] ftrace: allocating 57923 entries in 227 pages [ 1.463031] ftrace: allocated 227 pages with 5 groups [ 1.463604] Dynamic Preempt: voluntary [ 1.463679] rcu: Preemptible hierarchical RCU implementation. [ 1.463681] rcu: RCU restricting CPUs from NR_CPUS=3D8192 to nr_cpu_ids= =3D8. [ 1.463682] Trampoline variant of Tasks RCU enabled. [ 1.463683] Rude variant of Tasks RCU enabled. [ 1.463684] Tracing variant of Tasks RCU enabled. [ 1.463685] rcu: RCU calculated value of scheduler-enlistment delay is 1= 00 jiffies. [ 1.463686] rcu: Adjusting geometry for rcu_fanout_leaf=3D16, nr_cpu_ids= =3D8 [ 1.466431] NR_IRQS: 524544, nr_irqs: 1032, preallocated irqs: 16 [ 1.466497] xen:events: Using FIFO-based ABI [ 1.466544] rcu: srcu_init: Setting srcu_struct sizes based on contentio= n. [ 1.466822] Console: colour dummy device 80x25 [ 1.466825] printk: legacy console [tty1] enabled [ 1.466828] printk: legacy bootconsole [xenboot0] disabled [ 0.000000] Linux version 6.8.0-48-generic (root@a5570d9c6ad5) (x86_64-l= inux-gnu-gcc-12 (Ubuntu 12.3.0-1ubuntu1~22.04) 12.3.0, GNU ld (GNU Binutils= for Ubuntu) 2.38) #48~22.04.1 SMP PREEMPT_DYNAMIC Tue Nov 26 23:18:34 UTC = (Ubuntu 6.8.0-48.48~22.04.1-generic 6.8.12) [ 0.000000] Command line: console=3Dhvc0 console=3Dtty1 earlyprintk=3Dxe= n xen-pciback.passthrough=3D1 oops=3Dpanic panic=3D15 root=3D/dev/loop0 ro = rootfstype=3Dext4 zyimage=3Dzvol:xvda1@ref5030000 zyoverlay pstore.backend= =3Defi libata.fua=3D1 audit=3D1 nohz=3Doff consoleblank=3D0 modprobe.blackl= ist=3D8250_dw [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Hygon HygonGenuine [ 0.000000] Centaur CentaurHauls [ 0.000000] zhaoxin Shanghai =20 [ 0.000000] [Firmware Bug]: TSC doesn't count with P0 frequency! [ 0.000000] initrd moved from [mem 0x08000000-0x10b5a724] to [mem 0x1853= 7000-0x21091724] [ 0.000000] Released 0 page(s) [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: [mem 0x0000000000000000-0x000000000007ffff] usable [ 0.000000] Xen: [mem 0x0000000000080000-0x00000000000fffff] reserved [ 0.000000] Xen: [mem 0x0000000000100000-0x0000000009a7efff] usable [ 0.000000] Xen: [mem 0x0000000009a7f000-0x0000000009ffffff] reserved [ 0.000000] Xen: [mem 0x000000000a000000-0x000000000a1fffff] usable [ 0.000000] Xen: [mem 0x000000000a200000-0x000000000a23bfff] ACPI NVS [ 0.000000] Xen: [mem 0x000000000a23c000-0x0000000093c7dfff] usable [ 0.000000] Xen: [mem 0x0000000093c7e000-0x0000000096683fff] reserved [ 0.000000] Xen: [mem 0x0000000096684000-0x00000000966f2fff] ACPI data [ 0.000000] Xen: [mem 0x00000000966f3000-0x000000009716dfff] ACPI NVS [ 0.000000] Xen: [mem 0x000000009716e000-0x000000009affefff] reserved [ 0.000000] Xen: [mem 0x000000009afff000-0x000000009bff8fff] usable [ 0.000000] Xen: [mem 0x000000009bff9000-0x000000009bffcfff] reserved [ 0.000000] Xen: [mem 0x000000009bffd000-0x000000009bffefff] usable [ 0.000000] Xen: [mem 0x000000009bfff000-0x000000009cffffff] reserved [ 0.000000] Xen: [mem 0x000000009d790000-0x000000009d7effff] reserved [ 0.000000] Xen: [mem 0x000000009d7f5000-0x000000009fffffff] reserved [ 0.000000] Xen: [mem 0x00000000e0000000-0x00000000efffffff] reserved [ 0.000000] Xen: [mem 0x00000000fd000000-0x00000000ffffffff] reserved [ 0.000000] Xen: [mem 0x0000000100000000-0x0000000fde2fffff] usable [ 0.000000] Xen: [mem 0x0000000fdf340000-0x00000010801fffff] reserved [ 0.000000] printk: legacy bootconsole [xenboot0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] APIC: Static calls initialized [ 0.000000] efi: EFI v2.8 by American Megatrends [ 0.000000] efi: ACPI=3D0x97154000 ACPI 2.0=3D0x97154014 TPMFinalLog=3D0= x97120000 SMBIOS=3D0x9ad65000 SMBIOS 3.0=3D0x9ad64000 (MEMATTR=3D0x8f8eb098= unusable) ESRT=3D0x9669a018 MOKvar=3D0x9adc2000=20 [ 0.000000] secureboot: Secure boot disabled [ 0.000000] SMBIOS 3.5.0 present. [ 0.000000] DMI: Simply NUC EES24E32r8/EES24E32r8B, BIOS 0ACTF_SR_000_33= 05/31/2024 [ 0.000000] Hypervisor detected: Xen PV [ 0.026632] tsc: Fast TSC calibration using PIT [ 0.026634] tsc: Detected 3293.815 MHz processor [ 0.026635] tsc: Detected 3293.812 MHz TSC [ 0.026716] last_pfn =3D 0xfde300 max_arch_pfn =3D 0x400000000 [ 0.026719] MTRR map: 1 entries (0 fixed + 1 variable; max 16), built fr= om 8 variable MTRRs [ 0.026720] MTRRs set to read-only [ 0.026723] x86/PAT: Configuration [0-7]: WB WT UC- UC WC WP UC UC= =20 [ 0.026725] last_pfn =3D 0x9bfff max_arch_pfn =3D 0x400000000 [ 0.026744] esrt: Reserving ESRT space from 0x000000009669a018 to 0x0000= 00009669a050. [ 0.966402] secureboot: Secure boot disabled [ 0.966423] RAMDISK: [mem 0x18537000-0x21091fff] [ 0.966430] ACPI: Early table checksum verification disabled [ 0.966437] ACPI: RSDP 0x0000000097154014 000024 (v02 ALASKA) [ 0.966444] ACPI: XSDT 0x0000000097153728 00013C (v01 ALASKA A M I 01= 072009 AMI 01000013) [ 0.966486] ACPI: FACP 0x00000000966E8000 000114 (v06 ALASKA A M I 01= 072009 AMI 00010013) [ 0.966527] ACPI: DSDT 0x00000000966E0000 0078B7 (v02 ALASKA A M I 01= 072009 INTL 20200717) [ 0.966532] ACPI: FACS 0x000000009690D000 000040 [ 0.966537] ACPI: SSDT 0x00000000966EA000 008416 (v02 AMD AmdTable 00= 000002 MSFT 02000002) [ 0.966564] ACPI: SSDT 0x00000000966E9000 000221 (v02 ALASKA CPUSSDT 01= 072009 AMI 01072009) [ 0.966569] ACPI: FIDT 0x00000000966DF000 00009C (v01 ALASKA A M I 01= 072009 AMI 00010013) [ 0.966574] ACPI: MCFG 0x00000000966DE000 00003C (v01 ALASKA A M I 01= 072009 MSFT 00010013) [ 0.966579] ACPI: HPET 0x00000000966DD000 000038 (v01 ALASKA A M I 01= 072009 AMI 00000005) [ 0.966584] ACPI: UEFI 0x000000009690C000 000048 (v01 ALASKA A M I 01= 072009 AMI 01000013) [ 0.966589] ACPI: FPDT 0x00000000966DC000 000044 (v01 ALASKA A M I 01= 072009 AMI 01000013) [ 0.966594] ACPI: VFCT 0x00000000966D7000 004284 (v01 ALASKA A M I 00= 000001 AMD 33504F47) [ 0.966599] ACPI: TPM2 0x00000000966D6000 000044 (v05 ALASKA A M I 00= 000001 AMI 00000000) [ 0.966604] ACPI: SSDT 0x00000000966D0000 00547E (v02 AMD AmdTable 00= 000001 AMD 00000001) [ 0.966609] ACPI: CRAT 0x00000000966CF000 000EE8 (v01 AMD AmdTable 00= 000001 AMD 00000001) [ 0.966614] ACPI: CDIT 0x00000000966CE000 000029 (v01 AMD AmdTable 00= 000001 AMD 00000001) [ 0.966619] ACPI: SDEV 0x00000000966CD000 000144 (v01 AMD SdevTble 00= 000001 ACPI 00000002) [ 0.966624] ACPI: SSDT 0x00000000966CB000 0015C8 (v02 AMD CPMDFIG2 00= 000001 INTL 20200717) [ 0.966629] ACPI: SSDT 0x00000000966C8000 002A9E (v02 AMD CDFAAIG2 00= 000001 INTL 20200717) [ 0.966634] ACPI: SSDT 0x00000000966C6000 001E78 (v02 AMD CPMPMF 00= 000001 INTL 20200717) [ 0.966639] ACPI: SSDT 0x00000000966C4000 0012AE (v02 AMD OEMACP 00= 000001 INTL 20200717) [ 0.966644] ACPI: SSDT 0x00000000966C3000 0008BA (v02 AMD OEMPMF 00= 000001 INTL 20200717) [ 0.966649] ACPI: SSDT 0x00000000966B9000 0098F6 (v02 AMD CPMCMN 00= 000001 INTL 20200717) [ 0.966654] ACPI: WSMT 0x00000000966B8000 000028 (v01 ALASKA A M I 01= 072009 AMI 00010013) [ 0.966658] ACPI: APIC 0x00000000966B7000 0000E8 (v05 ALASKA A M I 01= 072009 AMI 00010013) [ 0.966664] ACPI: MHSP 0x00000000966B6000 0000C8 (v04 AMD AGESA 20= 505348 ? 00000001) [ 0.966669] ACPI: SSDT 0x00000000966B5000 0000E5 (v02 MSFT MHSP 00= 000004 INTL 20200717) [ 0.966674] ACPI: SSDT 0x00000000966B2000 00233C (v02 AMD AOD 00= 000001 INTL 20200717) [ 0.966678] ACPI: SSDT 0x00000000966B1000 000051 (v02 AMD DRTM 00= 000001 INTL 20200717) [ 0.966683] ACPI: IVRS 0x00000000966B0000 000198 (v02 AMD AmdTable 00= 000001 AMD 00000001) [ 0.966688] ACPI: SSDT 0x00000000966AF000 000968 (v02 AMD CPMMSOSC 00= 000001 INTL 20200717) [ 0.966693] ACPI: SSDT 0x00000000966AE000 000FF5 (v02 AMD CPMACPV5 00= 000001 INTL 20200717) [ 0.966698] ACPI: SSDT 0x00000000966AD000 000FF7 (v02 AMD GPP_PME_ 00= 000001 INTL 20200717) [ 0.966703] ACPI: SSDT 0x00000000966A3000 0098BD (v02 AMD INTGPP03 00= 000001 INTL 20200717) [ 0.966708] ACPI: SSDT 0x000000009669E000 004FEB (v02 AMD INTGPP01 00= 000001 INTL 20200717) [ 0.966713] ACPI: SSDT 0x000000009669D000 000DA2 (v02 AMD CPMGPIO0 00= 000001 INTL 20200717) [ 0.966718] ACPI: SSDT 0x000000009669C000 00008D (v02 AMD CPMMSLPI 00= 000001 INTL 20200717) [ 0.966723] ACPI: SSDT 0x000000009669B000 000501 (v02 AMD CPMSFAML 00= 000001 INTL 20200717) [ 0.966726] ACPI: Reserving FACP table memory at [mem 0x966e8000-0x966e8= 113] [ 0.966728] ACPI: Reserving DSDT table memory at [mem 0x966e0000-0x966e7= 8b6] [ 0.966729] ACPI: Reserving FACS table memory at [mem 0x9690d000-0x9690d= 03f] [ 0.966730] ACPI: Reserving SSDT table memory at [mem 0x966ea000-0x966f2= 415] [ 0.966731] ACPI: Reserving SSDT table memory at [mem 0x966e9000-0x966e9= 220] [ 0.966732] ACPI: Reserving FIDT table memory at [mem 0x966df000-0x966df= 09b] [ 0.966733] ACPI: Reserving MCFG table memory at [mem 0x966de000-0x966de= 03b] [ 0.966734] ACPI: Reserving HPET table memory at [mem 0x966dd000-0x966dd= 037] [ 0.966735] ACPI: Reserving UEFI table memory at [mem 0x9690c000-0x9690c= 047] [ 0.966737] ACPI: Reserving FPDT table memory at [mem 0x966dc000-0x966dc= 043] [ 0.966738] ACPI: Reserving VFCT table memory at [mem 0x966d7000-0x966db= 283] [ 0.966739] ACPI: Reserving TPM2 table memory at [mem 0x966d6000-0x966d6= 043] [ 0.966740] ACPI: Reserving SSDT table memory at [mem 0x966d0000-0x966d5= 47d] [ 0.966741] ACPI: Reserving CRAT table memory at [mem 0x966cf000-0x966cf= ee7] [ 0.966742] ACPI: Reserving CDIT table memory at [mem 0x966ce000-0x966ce= 028] [ 0.966743] ACPI: Reserving SDEV table memory at [mem 0x966cd000-0x966cd= 143] [ 0.966744] ACPI: Reserving SSDT table memory at [mem 0x966cb000-0x966cc= 5c7] [ 0.966745] ACPI: Reserving SSDT table memory at [mem 0x966c8000-0x966ca= a9d] [ 0.966746] ACPI: Reserving SSDT table memory at [mem 0x966c6000-0x966c7= e77] [ 0.966747] ACPI: Reserving SSDT table memory at [mem 0x966c4000-0x966c5= 2ad] [ 0.966749] ACPI: Reserving SSDT table memory at [mem 0x966c3000-0x966c3= 8b9] [ 0.966750] ACPI: Reserving SSDT table memory at [mem 0x966b9000-0x966c2= 8f5] [ 0.966751] ACPI: Reserving WSMT table memory at [mem 0x966b8000-0x966b8= 027] [ 0.966752] ACPI: Reserving APIC table memory at [mem 0x966b7000-0x966b7= 0e7] [ 0.966753] ACPI: Reserving MHSP table memory at [mem 0x966b6000-0x966b6= 0c7] [ 0.966754] ACPI: Reserving SSDT table memory at [mem 0x966b5000-0x966b5= 0e4] [ 0.966755] ACPI: Reserving SSDT table memory at [mem 0x966b2000-0x966b4= 33b] [ 0.966756] ACPI: Reserving SSDT table memory at [mem 0x966b1000-0x966b1= 050] [ 0.966757] ACPI: Reserving IVRS table memory at [mem 0x966b0000-0x966b0= 197] [ 0.966759] ACPI: Reserving SSDT table memory at [mem 0x966af000-0x966af= 967] [ 0.966760] ACPI: Reserving SSDT table memory at [mem 0x966ae000-0x966ae= ff4] [ 0.966761] ACPI: Reserving SSDT table memory at [mem 0x966ad000-0x966ad= ff6] [ 0.966762] ACPI: Reserving SSDT table memory at [mem 0x966a3000-0x966ac= 8bc] [ 0.966763] ACPI: Reserving SSDT table memory at [mem 0x9669e000-0x966a2= fea] [ 0.966764] ACPI: Reserving SSDT table memory at [mem 0x9669d000-0x9669d= da1] [ 0.966765] ACPI: Reserving SSDT table memory at [mem 0x9669c000-0x9669c= 08c] [ 0.966766] ACPI: Reserving SSDT table memory at [mem 0x9669b000-0x9669b= 500] [ 0.966827] APIC: Switched APIC routing to: Xen PV [ 0.966863] NUMA turned off [ 0.966864] Faking a node at [mem 0x0000000000000000-0x0000000fde2fffff] [ 0.966870] NODE_DATA(0) allocated [mem 0xf3b0b8000-0xf3b0e2fff] [ 1.052384] Zone ranges: [ 1.052388] DMA [mem 0x0000000000001000-0x0000000000ffffff] [ 1.052390] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] [ 1.052392] Normal [mem 0x0000000100000000-0x0000000fde2fffff] [ 1.052393] Device empty [ 1.052395] Movable zone start for each node [ 1.052396] Early memory node ranges [ 1.052397] node 0: [mem 0x0000000000001000-0x000000000007ffff] [ 1.052399] node 0: [mem 0x0000000000100000-0x0000000009a7efff] [ 1.052400] node 0: [mem 0x000000000a000000-0x000000000a1fffff] [ 1.052401] node 0: [mem 0x000000000a23c000-0x0000000093c7dfff] [ 1.052403] node 0: [mem 0x000000009afff000-0x000000009bff8fff] [ 1.052404] node 0: [mem 0x000000009bffd000-0x000000009bffefff] [ 1.052405] node 0: [mem 0x0000000100000000-0x0000000fde2fffff] [ 1.052410] Initmem setup node 0 [mem 0x0000000000001000-0x0000000fde2ff= fff] [ 1.052416] On node 0, zone DMA: 1 pages in unavailable ranges [ 1.052429] On node 0, zone DMA: 128 pages in unavailable ranges [ 1.052539] On node 0, zone DMA32: 1409 pages in unavailable ranges [ 1.054214] On node 0, zone DMA32: 60 pages in unavailable ranges [ 1.054384] On node 0, zone DMA32: 29569 pages in unavailable ranges [ 1.054401] On node 0, zone DMA32: 4 pages in unavailable ranges [ 1.090715] On node 0, zone Normal: 16385 pages in unavailable ranges [ 1.090770] On node 0, zone Normal: 7424 pages in unavailable ranges [ 1.090773] p2m virtual area at (____ptrval____), size is 40000000 [ 1.337431] Remapped 440771 page(s) [ 1.338130] ACPI: PM-Timer IO Port: 0x808 [ 1.338186] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) [ 1.338208] IOAPIC[0]: apic_id 33, version 33, address 0xfec00000, GSI 0= -23 [ 1.338215] IOAPIC[1]: apic_id 34, version 33, address 0xfec01000, GSI 2= 4-55 [ 1.338223] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 1.338226] ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 1 low edge) [ 1.338229] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) [ 1.338243] ACPI: Using ACPI (MADT) for SMP configuration information [ 1.338245] ACPI: HPET id: 0x10228201 base: 0xfed00000 [ 1.338675] smpboot: Allowing 8 CPUs, 0 hotplug CPUs [ 1.338689] PM: hibernation: Registered nosave memory: [mem 0x00000000-0= x00000fff] [ 1.338691] PM: hibernation: Registered nosave memory: [mem 0x00080000-0= x000fffff] [ 1.338693] PM: hibernation: Registered nosave memory: [mem 0x09a7f000-0= x09ffffff] [ 1.338694] PM: hibernation: Registered nosave memory: [mem 0x0a200000-0= x0a23bfff] [ 1.338696] PM: hibernation: Registered nosave memory: [mem 0x93c7e000-0= x96683fff] [ 1.338697] PM: hibernation: Registered nosave memory: [mem 0x96684000-0= x966f2fff] [ 1.338698] PM: hibernation: Registered nosave memory: [mem 0x966f3000-0= x9716dfff] [ 1.338699] PM: hibernation: Registered nosave memory: [mem 0x9716e000-0= x9affefff] [ 1.338701] PM: hibernation: Registered nosave memory: [mem 0x9bff9000-0= x9bffcfff] [ 1.338703] PM: hibernation: Registered nosave memory: [mem 0x9bfff000-0= x9cffffff] [ 1.338704] PM: hibernation: Registered nosave memory: [mem 0x9d000000-0= x9d78ffff] [ 1.338705] PM: hibernation: Registered nosave memory: [mem 0x9d790000-0= x9d7effff] [ 1.338706] PM: hibernation: Registered nosave memory: [mem 0x9d7f0000-0= x9d7f4fff] [ 1.338707] PM: hibernation: Registered nosave memory: [mem 0x9d7f5000-0= x9fffffff] [ 1.338708] PM: hibernation: Registered nosave memory: [mem 0xa0000000-0= xdfffffff] [ 1.338709] PM: hibernation: Registered nosave memory: [mem 0xe0000000-0= xefffffff] [ 1.338710] PM: hibernation: Registered nosave memory: [mem 0xf0000000-0= xfcffffff] [ 1.338711] PM: hibernation: Registered nosave memory: [mem 0xfd000000-0= xffffffff] [ 1.338713] [mem 0xa0000000-0xdfffffff] available for PCI devices [ 1.338720] Booting kernel on Xen [ 1.338721] Xen version: 4.18.3 (preserve-AD) [ 1.338724] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0= xffffffff, max_idle_ns: 1910969940391419 ns [ 1.338732] setup_percpu: NR_CPUS:8192 nr_cpumask_bits:8 nr_cpu_ids:8 nr= _node_ids:1 [ 1.338982] percpu: Embedded 86 pages/cpu s229376 r8192 d114688 u524288 [ 1.339028] PV qspinlock hash table entries: 256 (order: 0, 4096 bytes, = linear) [ 1.339031] Kernel command line: console=3Dhvc0 console=3Dtty1 earlyprin= tk=3Dxen xen-pciback.passthrough=3D1 oops=3Dpanic panic=3D15 root=3D/dev/lo= op0 ro rootfstype=3Dext4 zyimage=3Dzvol:xvda1@ref5030000 zyoverlay pstore.b= ackend=3Defi libata.fua=3D1 audit=3D1 nohz=3Doff consoleblank=3D0 modprobe.= blacklist=3D8250_dw [ 1.339108] audit: enabled (after initialization) [ 1.339124] Unknown kernel command line parameters "zyoverlay zyimage=3D= zvol:xvda1@ref5030000", will be passed to user space. [ 1.339316] random: crng init done [ 1.342318] Dentry cache hash table entries: 8388608 (order: 14, 6710886= 4 bytes, linear) [ 1.343852] Inode-cache hash table entries: 4194304 (order: 13, 33554432= bytes, linear) [ 1.343993] Fallback order for Node 0: 0=20 [ 1.343997] Built 1 zonelists, mobility grouping on. Total pages: 15944= 838 [ 1.344000] Policy zone: Normal [ 1.344009] mem auto-init: stack:all(zero), heap alloc:on, heap free:off [ 1.344012] software IO TLB: area num 8. [ 1.454324] Memory: 62248564K/64791792K available (22528K kernel code, 4= 438K rwdata, 13964K rodata, 4972K init, 4740K bss, 2542976K reserved, 0K cm= a-reserved) [ 1.455150] SLUB: HWalign=3D64, Order=3D0-3, MinObjects=3D0, CPUs=3D8, N= odes=3D1 [ 1.455490] ftrace: allocating 57923 entries in 227 pages [ 1.463031] ftrace: allocated 227 pages with 5 groups [ 1.463604] Dynamic Preempt: voluntary [ 1.463679] rcu: Preemptible hierarchical RCU implementation. [ 1.463681] rcu: RCU restricting CPUs from NR_CPUS=3D8192 to nr_cpu_ids= =3D8. [ 1.463682] Trampoline variant of Tasks RCU enabled. [ 1.463683] Rude variant of Tasks RCU enabled. [ 1.463684] Tracing variant of Tasks RCU enabled. [ 1.463685] rcu: RCU calculated value of scheduler-enlistment delay is 1= 00 jiffies. [ 1.463686] rcu: Adjusting geometry for rcu_fanout_leaf=3D16, nr_cpu_ids= =3D8 [ 1.466431] NR_IRQS: 524544, nr_irqs: 1032, preallocated irqs: 16 [ 1.466497] xen:events: Using FIFO-based ABI [ 1.466544] rcu: srcu_init: Setting srcu_struct sizes based on contentio= n. [ 1.466822] Console: colour dummy device 80x25 [ 1.466825] printk: legacy console [tty1] enabled [ 1.466828] printk: legacy bootconsole [xenboot0] disabled [ 1.466832] printk: legacy console [hvc0] enabled [ 1.467132] ACPI: Core revision 20230628 [ 1.495547] clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd= 42e4dffb, max_idle_ns: 881590591483 ns [ 1.495555] installing Xen timer for CPU 0 [ 1.495622] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles:= 0x2f7a76a4ebd, max_idle_ns: 440795230158 ns [ 1.495628] Calibrating delay loop (skipped), value calculated using tim= er frequency.. 6587.62 BogoMIPS (lpj=3D3293812) [ 1.495663] Last level iTLB entries: 4KB 512, 2MB 512, 4MB 256 [ 1.495666] Last level dTLB entries: 4KB 3072, 2MB 3072, 4MB 1536, 1GB 0 [ 1.495669] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user= pointer sanitization [ 1.495674] Spectre V2 : Mitigation: Retpolines [ 1.495676] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB= on context switch [ 1.495679] Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT [ 1.495682] Spectre V2 : mitigation: Enabling conditional Indirect Branc= h Prediction Barrier [ 1.495686] Speculative Store Bypass: Vulnerable [ 1.495688] Speculative Return Stack Overflow: Mitigation: Safe RET [ 1.495698] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point= registers' [ 1.495701] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [ 1.495704] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [ 1.495706] x86/fpu: Supporting XSAVE feature 0x020: 'AVX-512 opmask' [ 1.495708] x86/fpu: Supporting XSAVE feature 0x040: 'AVX-512 Hi256' [ 1.495711] x86/fpu: Supporting XSAVE feature 0x080: 'AVX-512 ZMM_Hi256' [ 1.495713] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [ 1.495716] x86/fpu: xstate_offset[5]: 832, xstate_sizes[5]: 64 [ 1.495718] x86/fpu: xstate_offset[6]: 896, xstate_sizes[6]: 512 [ 1.495721] x86/fpu: xstate_offset[7]: 1408, xstate_sizes[7]: 1024 [ 1.495723] x86/fpu: Enabled xstate features 0xe7, context size is 2432 = bytes, using 'compacted' format. [ 1.511484] Freeing SMP alternatives memory: 48K [ 1.511493] pid_max: default: 32768 minimum: 301 [ 1.511544] LSM: initializing lsm=3Dlockdown,capability,landlock,yama,ap= parmor,integrity [ 1.511567] landlock: Up and running. [ 1.511571] Yama: becoming mindful. [ 1.511605] AppArmor: AppArmor initialized [ 1.511678] Mount-cache hash table entries: 131072 (order: 8, 1048576 by= tes, linear) [ 1.511721] Mountpoint-cache hash table entries: 131072 (order: 8, 10485= 76 bytes, linear) [ 1.512178] cpu 0 spinlock event irq 57 [ 1.512187] VPMU disabled by hypervisor. [ 1.512388] RCU Tasks: Setting shift to 3 and lim to 1 rcu_task_cb_adjus= t=3D1. [ 1.512428] RCU Tasks Rude: Setting shift to 3 and lim to 1 rcu_task_cb_= adjust=3D1. [ 1.512450] RCU Tasks Trace: Setting shift to 3 and lim to 1 rcu_task_cb= _adjust=3D1. [ 1.512474] Performance Events: PMU not available due to virtualization,= using software events only. [ 1.512485] signal: max sigframe size: 3376 [ 1.512520] rcu: Hierarchical SRCU implementation. [ 1.512525] rcu: Max phase no-delay instances is 400. [ 1.520689] NMI watchdog: Perf NMI watchdog permanently disabled [ 1.520793] smp: Bringing up secondary CPUs ... [ 1.520926] installing Xen timer for CPU 1 [ 1.521145] installing Xen timer for CPU 2 [ 1.521331] installing Xen timer for CPU 3 [ 1.521527] installing Xen timer for CPU 4 [ 1.521716] installing Xen timer for CPU 5 [ 1.521897] installing Xen timer for CPU 6 [ 1.522072] installing Xen timer for CPU 7 [ 1.522144] cpu 1 spinlock event irq 97 [ 1.522144] cpu 2 spinlock event irq 98 [ 1.522144] cpu 3 spinlock event irq 99 [ 1.522635] cpu 4 spinlock event irq 100 [ 1.522744] cpu 5 spinlock event irq 101 [ 1.522763] cpu 6 spinlock event irq 102 [ 1.522763] cpu 7 spinlock event irq 103 [ 1.522765] smp: Brought up 1 node, 8 CPUs [ 1.522771] smpboot: Max logical packages: 1 [ 1.524439] devtmpfs: initialized [ 1.524439] x86/mm: Memory block size: 128MB [ 1.530666] ACPI: PM: Registering ACPI NVS region [mem 0x0a200000-0x0a23= bfff] (245760 bytes) [ 1.530678] ACPI: PM: Registering ACPI NVS region [mem 0x966f3000-0x9716= dfff] (10989568 bytes) [ 1.530844] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xfffffff= f, max_idle_ns: 1911260446275000 ns [ 1.530858] futex hash table entries: 2048 (order: 5, 131072 bytes, line= ar) [ 1.530927] pinctrl core: initialized pinctrl subsystem [ 1.531034] PM: RTC time: 13:39:38, date: 2024-12-02 [ 1.532061] NET: Registered PF_NETLINK/PF_ROUTE protocol family [ 1.532086] xen:grant_table: Grant tables using version 1 layout [ 1.532106] Grant table initialized [ 1.532577] DMA: preallocated 4096 KiB GFP_KERNEL pool for atomic alloca= tions [ 1.532786] DMA: preallocated 4096 KiB GFP_KERNEL|GFP_DMA pool for atomi= c allocations [ 1.532980] DMA: preallocated 4096 KiB GFP_KERNEL|GFP_DMA32 pool for ato= mic allocations [ 1.533000] audit: initializing netlink subsys (enabled) [ 1.533015] audit: type=3D2000 audit(1733146778.033:1): state=3Dinitiali= zed audit_enabled=3D1 res=3D1 [ 1.533015] thermal_sys: Registered thermal governor 'fair_share' [ 1.533015] thermal_sys: Registered thermal governor 'bang_bang' [ 1.533015] thermal_sys: Registered thermal governor 'step_wise' [ 1.533015] thermal_sys: Registered thermal governor 'user_space' [ 1.533015] thermal_sys: Registered thermal governor 'power_allocator' [ 1.533015] EISA bus registered [ 1.533690] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 1.533948] PCI: ECAM [mem 0xe0000000-0xefffffff] (base 0xe0000000) for = domain 0000 [bus 00-ff] (XEN) d0: Forcing write emulation on MFNs e0000-effff [ 1.566930] PCI: Using configuration type 1 for base access [ 1.567239] kprobes: kprobe jump-optimization is enabled. All kprobes ar= e optimized if possible. [ 1.567717] fbcon: Taking over console [ 1.567742] ACPI: Added _OSI(Module Device) [ 1.567747] ACPI: Added _OSI(Processor Device) [ 1.567751] ACPI: Added _OSI(3.0 _SCP Extensions) [ 1.567756] ACPI: Added _OSI(Processor Aggregator Device) [ 1.600527] ACPI: 21 ACPI AML tables successfully acquired and loaded [ 1.622838] ACPI: _OSC evaluation for CPUs failed, trying _PDC [ 1.624340] ACPI: Interpreter enabled [ 1.624359] ACPI: PM: (supports S0 S3 S4 S5) [ 1.624364] ACPI: Using IOAPIC for interrupt routing [ 1.626467] PCI: Using host bridge windows from ACPI; if necessary, use = "pci=3Dnocrs" and report a bug [ 1.626475] PCI: Ignoring E820 reservations for host bridge windows [ 1.627418] ACPI: Enabled 4 GPEs in block 00 to 1F [ 1.630913] ACPI: \_SB_.PCI0.GP11.PWRS: New power resource [ 1.632031] ACPI: \_SB_.PCI0.GP11.SWUS.PWRS: New power resource [ 1.633056] ACPI: \_SB_.PCI0.GP12.PWRS: New power resource [ 1.634148] ACPI: \_SB_.PCI0.GP12.SWUS.PWRS: New power resource [ 1.634586] ACPI: \_SB_.PCI0.GP17.PWRS: New power resource [ 1.635033] ACPI: \_SB_.PCI0.GP17.VGA_.PWRS: New power resource [ 1.635567] ACPI: \_SB_.PCI0.GP17.HDAU.PWRS: New power resource [ 1.636027] ACPI: \_SB_.PCI0.GP17.ACP_.PWRS: New power resource [ 1.637100] ACPI: \_SB_.PCI0.GP17.AZAL.PWRS: New power resource [ 1.638165] ACPI: \_SB_.PCI0.GP17.XHC0.PWRS: New power resource [ 1.642929] ACPI: \_SB_.PCI0.GP17.XHC1.PWRS: New power resource [ 1.646471] ACPI: \_SB_.PCI0.GP19.XHC2.PWRS: New power resource [ 1.648936] ACPI: \_SB_.PCI0.GP19.XHC3.PWRS: New power resource [ 1.651469] ACPI: \_SB_.PCI0.GP19.XHC4.PWRS: New power resource [ 1.653968] ACPI: \_SB_.PCI0.GP19.NHI0.PWRS: New power resource [ 1.655031] ACPI: \_SB_.PCI0.GP19.NHI1.PWRS: New power resource [ 1.670026] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 1.670036] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM Cloc= kPM Segments MSI EDR HPX-Type3] [ 1.670299] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug SHPCHotp= lug PME AER PCIeCapability LTR DPC] [ 1.671252] PCI host bridge to bus 0000:00 [ 1.671257] pci_bus 0000:00: root bus resource [io 0x0000-0x03af window] [ 1.671263] pci_bus 0000:00: root bus resource [io 0x03e0-0x0cf7 window] [ 1.671268] pci_bus 0000:00: root bus resource [io 0x03b0-0x03df window] [ 1.671274] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] [ 1.671280] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000dfff= f window] [ 1.671286] pci_bus 0000:00: root bus resource [mem 0xfa000000-0xfcfffff= f window] [ 1.671292] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xf9fffff= f window] [ 1.671298] pci_bus 0000:00: root bus resource [mem 0xa0000000-0xdffffff= f window] [ 1.671304] pci_bus 0000:00: root bus resource [mem[ 4.024813] x86/mm= : Checked W+X mappings: passed, no W+X pages found. [ 4.024870] Run /init as init process [ 4.025387] audit: type=3D1334 audit(1733146780.694:8): prog-id=3D1 op= =3DUNLOAD [ 4.188822] ACPI: video: Video Device [VGA] (multi-head: yes rom: no p= ost: no) [ 4.189248] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08= :00/device:22/LNXVIDEO:00/input/input1 [ 4.196462] piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, re= vision 0 [ 4.196476] piix4_smbus 0000:00:14.0: Using register 0x02 for SMBus port= selection [ 4.196762] hid: raw HID events driver (C) Jiri Kosina [ 4.196963] pstore: backend 'efi' already in use: ignoring 'efi_pstore' [ 4.197068] Already setup the GSI :37 [ 4.197406] xhci_hcd 0000:07:00.3: xHCI Host Controller [ 4.197660] xhci_hcd 0000:07:00.3: new USB bus registered, assigned bus = number 1 [ 4.197774] piix4_smbus 0000:00:14.0: Auxiliary SMBus Host Controller at= 0xb20 [ 4.198147] xhci_hcd 0000:07:00.3: hcc params 0x0128ffc5 hci version 0x1= 20 quirks 0x0000000200000010 [ 4.198425] pcie_mp2_amd 0000:07:00.7: enabling device (0000 -> 0002) [ 4.198783] xhci_hcd 0000:07:00.3: xHCI Host Controller [ 4.198796] xhci_hcd 0000:07:00.3: new USB bus registered, assigned bus = number 2 [ 4.198808] xhci_hcd 0000:07:00.3: Host supports USB 3.1 Enhanced SuperS= peed [ 4.198897] usb usb1: New USB device found, idVendor=3D1d6b, idProduct= =3D0002, bcdDevice=3D 6.08 [ 4.198908] usb usb1: New USB device strings: Mfr=3D3, Product=3D2, Seri= alNumber=3D1 [ 4.198917] usb usb1: Product: xHCI Host Controller [ 4.198924] usb usb1: Manufacturer: Linux 6.8.0-48-generic xhci-hcd [ 4.198932] usb usb1: SerialNumber: 0000:07:00.3 [ 4.199192] Already setup the GSI :37 [ 4.199727] nvme 0000:01:00.0: platform quirk: setting simple suspend [ 4.199745] nvme 0000:06:00.0: platform quirk: setting simple suspend [ 4.199885] hub 1-0:1.0: USB hub found [ 4.199893] nvme nvme1: pci function 0000:06:00.0 [ 4.199900] nvme nvme0: pci function 0000:01:00.0 [ 4.199923] hub 1-0:1.0: 5 ports detected [ 4.206498] nvme nvme0: missing or invalid SUBNQN field. [ 4.206509] nvme nvme1: missing or invalid SUBNQN field. [ 4.206656] nvme nvme0: Shutdown timeout set to 8 seconds [ 4.207094] nvme nvme1: Shutdown timeout set to 8 seconds [ 4.211216] usb usb2: We don't know the algorithms for LPM for this host= , disabling LPM. [ 4.211304] usb usb2: New USB device found, idVendor=3D1d6b, idProduct= =3D0003, bcdDevice=3D 6.08 [ 4.211323] usb usb2: New USB device strings: Mfr=3D3, Product=3D2, Seri= alNumber=3D1 [ 4.211338] usb usb2: Product: xHCI Host Controller [ 4.211349] usb usb2: Manufacturer: Linux 6.8.0-48-generic xhci-hcd [ 4.211362] usb usb2: SerialNumber: 0000:07:00.3 [ 4.211635] hub 2-0:1.0: USB hub found [ 4.211649] hub 2-0:1.0: 2 ports detected [ 4.215753] Already setup the GSI :38 [ 4.215953] xhci_hcd 0000:07:00.4: xHCI Host Controller [ 4.215963] xhci_hcd 0000:07:00.4: new USB bus registered, assigned bus = number 3 [ 4.216398] xhci_hcd 0000:07:00.4: hcc params 0x0110ffc5 hci version 0x1= 20 quirks 0x0000000200000010 [ 4.216699] xhci_hcd 0000:07:00.4: xHCI Host Controller [ 4.216707] xhci_hcd 0000:07:00.4: new USB bus registered, assigned bus = number 4 [ 4.216716] xhci_hcd 0000:07:00.4: Host supports USB 3.1 Enhanced SuperS= peed [ 4.216798] usb usb3: New USB device found, idVendor=3D1d6b, idProduct= =3D0002, bcdDevice=3D 6.08 [ 4.216806] usb usb3: New USB device strings: Mfr=3D3, Product=3D2, Seri= alNumber=3D1 [ 4.216814] usb usb3: Product: xHCI Host Controller [ 4.216820] usb usb3: Manufacturer: Linux 6.8.0-48-generic xhci-hcd [ 4.216826] usb usb3: SerialNumber: 0000:07:00.4 [ 4.216978] hub 3-0:1.0: USB hub found [ 4.217006] hub 3-0:1.0: 1 port detected [ 4.218183] nvme nvme0: 8/0/0 default/read/poll queues [ 4.218615] usb usb4: We don't know the algorithms for LPM for this host= , disabling LPM. [ 4.218660] usb usb4: New USB device found, idVendor=3D1d6b, idProduct= =3D0003, bcdDevice=3D 6.08 [ 4.218669] usb usb4: New USB device strings: Mfr=3D3, Product=3D2, Seri= alNumber=3D1 [ 4.218676] usb usb4: Product: xHCI Host Controller [ 4.218682] usb usb4: Manufacturer: Linux 6.8.0-48-generic xhci-hcd [ 4.218688] usb usb4: SerialNumber: 0000:07:00.4 [ 4.218814] hub 4-0:1.0: USB hub found [ 4.218840] hub 4-0:1.0: 1 port detected [ 4.219576] nvme nvme1: 8/0/0 default/read/poll queues [ 4.220568] Already setup the GSI :46 [ 4.220763] xhci_hcd 0000:09:00.3: xHCI Host Controller [ 4.220772] xhci_hcd 0000:09:00.3: new USB bus registered, assigned bus = number 5 [ 4.221139] xhci_hcd 0000:09:00.3: hcc params 0x0110ffc5 hci version 0x1= 20 quirks 0x0000000200000010 [ 4.221447] nvme0n1: p1 p2 p3 p4 p5 p6 [ 4.221727] xhci_hcd 0000:09:00.3: xHCI Host Controller [ 4.221737] xhci_hcd 0000:09:00.3: new USB bus registered, assigned bus = number 6 [ 4.221746] xhci_hcd 0000:09:00.3: Host supports USB 3.1 Enhanced SuperS= peed [ 4.221806] usb usb5: New USB device found, idVendor=3D1d6b, idProduct= =3D0002, bcdDevice=3D 6.08 [ 4.221814] usb usb5: New USB device strings: Mfr=3D3, Product=3D2, Seri= alNumber=3D1 [ 4.221823] usb usb5: Product: xHCI Host Controller [ 4.221827] usb usb5: Manufacturer: Linux 6.8.0-48-generic xhci-hcd [ 4.221834] usb usb5: SerialNumber: 0000:09:00.3 [ 4.221986] hub 5-0:1.0: USB hub found [ 4.222013] hub 5-0:1.0: 1 port detected [ 4.223158] nvme1n1: p1 p2 p3 p4 p5 p6 [ 4.223642] usb usb6: We don't know the algorithms for LPM for this host= , disabling LPM. [ 4.223691] usb usb6: New USB device found, idVendor=3D1d6b, idProduct= =3D0003, bcdDevice=3D 6.08 [ 4.223700] usb usb6: New USB device strings: Mfr=3D3, Product=3D2, Seri= alNumber=3D1 [ 4.223707] usb usb6: Product: xHCI Host Controller [ 4.223713] usb usb6: Manufacturer: Linux 6.8.0-48-generic xhci-hcd [ 4.223723] usb usb6: SerialNumber: 0000:09:00.3 [ 4.224169] hub 6-0:1.0: USB hub found [ 4.224196] hub 6-0:1.0: 1 port detected [ 4.231228] Already setup the GSI :47 [ 4.231481] xhci_hcd 0000:09:00.4: xHCI Host Controller [ 4.231494] xhci_hcd 0000:09:00.4: new USB bus registered, assigned bus = number 7 [ 4.231831] xhci_hcd 0000:09:00.4: hcc params 0x0110ffc5 hci version 0x1= 20 quirks 0x0000000200000010 [ 4.232615] xhci_hcd 0000:09:00.4: xHCI Host Controller [ 4.232629] xhci_hcd 0000:09:00.4: new USB bus registered, assigned bus = number 8 [ 4.232643] xhci_hcd 0000:09:00.4: Host supports USB 3.1 Enhanced SuperS= peed [ 4.232756] usb usb7: New USB device found, idVendor=3D1d6b, idProduct= =3D0002, bcdDevice=3D 6.08 [ 4.232771] usb usb7: New USB device strings: Mfr=3D3, Product=3D2, Seri= alNumber=3D1 [ 4.232782] usb usb7: Product: xHCI Host Controller [ 4.232791] usb usb7: Manufacturer: Linux 6.8.0-48-generic xhci-hcd [ 4.232800] usb usb7: SerialNumber: 0000:09:00.4 [ 4.233143] hub 7-0:1.0: USB hub found [ 4.233202] hub 7-0:1.0: 1 port detected [ 4.235576] usb usb8: We don't know the algorithms for LPM for this host= , disabling LPM. [ 4.235736] usb usb8: New USB device found, idVendor=3D1d6b, idProduct= =3D0003, bcdDevice=3D 6.08 [ 4.235751] usb usb8: New USB device strings: Mfr=3D3, Product=3D2, Seri= alNumber=3D1 [ 4.235763] usb usb8: Product: xHCI Host Controller [ 4.235773] usb usb8: Manufacturer: Linux 6.8.0-48-generic xhci-hcd [ 4.235782] usb usb8: SerialNumber: 0000:09:00.4 [ 4.244377] hub 8-0:1.0: USB hub found [ 4.244429] hub 8-0:1.0: 1 port detected [ 4.474166] usb 7-1: new high-speed USB device number 2 using xhci_hcd [ 4.604005] usb 7-1: New USB device found, idVendor=3D04b4, idProduct=3D= 6502, bcdDevice=3D50.10 [ 4.604016] usb 7-1: New USB device strings: Mfr=3D0, Product=3D0, Seria= lNumber=3D0 [ 4.649541] hub 7-1:1.0: USB hub found [ 4.649900] hub 7-1:1.0: 4 ports detected [ 4.718189] usb 8-1: new SuperSpeed USB device number 2 using xhci_hcd [ 4.730589] usb 8-1: New USB device found, idVendor=3D04b4, idProduct=3D= 6500, bcdDevice=3D50.10 [ 4.730613] usb 8-1: New USB device strings: Mfr=3D0, Product=3D0, Seria= lNumber=3D0 [ 4.762374] hub 8-1:1.0: USB hub found [ 4.762452] hub 8-1:1.0: 4 ports detected [ 5.347496] [drm] amdgpu kernel modesetting enabled. [ 5.355084] raid6: avx512x4 gen() 41154 MB/s [ 5.364461] amdgpu: Virtual CRAT table created for CPU [ 5.364481] amdgpu: Topology: Add CPU node [ 5.364751] amdgpu 0000:07:00.0: enabling device (0006 -> 0007) [ 5.364831] Already setup the GSI :38 [ 5.364853] [drm] initializing kernel modesetting (IP DISCOVERY 0x1002:0= x1900 0x1002:0x0124 0xD0). [ 5.364935] [drm] register mmio base: 0xFBC00000 [ 5.364941] [drm] register mmio size: 524288 [ 5.368987] [drm] add ip block number 0 [ 5.368995] [drm] add ip block number 1 [ 5.369000] [drm] add ip block number 2 [ 5.369006] [drm] add ip block number 3 [ 5.369012] [drm] add ip block number 4 [ 5.369017] [drm] add ip block number 5 [ 5.369023] [drm] add ip block number 6 [ 5.369029] [drm] add ip block number 7 [ 5.369035] [drm] add ip block number 8 [ 5.369040] [drm] add ip block number 9 [ 5.369046] [drm] add ip block number 10 [ 5.372084] raid6: avx512x2 gen() 41444 MB/s [ 5.373486] amdgpu 0000:07:00.0: amdgpu: Fetched VBIOS from VFCT [ 5.373493] amdgpu: ATOM BIOS: 113-PHXGENERIC-001 [ 5.378345] [drm] VCN(0) encode/decode are enabled in VM mode [ 5.379507] amdgpu 0000:07:00.0: [drm:jpeg_v4_0_early_init [amdgpu]] JPE= G decode is enabled in VM mode [ 5.381242] amdgpu 0000:07:00.0: vgaarb: deactivate vga console [ 5.381253] amdgpu 0000:07:00.0: amdgpu: Trusted Memory Zone (TMZ) featu= re enabled [ 5.381320] [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, f= ragment size is 9-bit [ 5.381350] amdgpu 0000:07:00.0: amdgpu: VRAM: 2048M 0x0000008000000000 = - 0x000000807FFFFFFF (2048M used) [ 5.381358] amdgpu 0000:07:00.0: amdgpu: GART: 512M 0x00007FFF00000000 -= 0x00007FFF1FFFFFFF [ 5.381380] [drm] Detected VRAM RAM=3D2048M, BAR=3D2048M [ 5.381385] [drm] RAM width 128bits DDR5 [ 5.389085] raid6: avx512x1 gen() 28187 MB/s [ 5.406084] raid6: avx2x4 gen() 44277 MB/s [ 5.423084] raid6: avx2x2 gen() 50236 MB/s [ 5.440084] raid6: avx2x1 gen() 37095 MB/s [ 5.440090] raid6: using algorithm avx2x2 gen() 50236 MB/s [ 5.457084] raid6: .... xor() 40859 MB/s, rmw enabled [ 5.457090] raid6: using avx512x2 recovery algorithm [ 5.457824] xor: automatically using best checksumming function avx = =20 [ 5.458421] async_tx: api initialized (async) [ 5.526556] md/raid1:mdX: active with 2 out of 2 mirrors [ 5.526573] md/raid1:mdX: active with 2 out of 2 mirrors [ 5.662909] [drm] amdgpu: 2048M of VRAM memory ready [ 5.662947] [drm] amdgpu: 30468M of GTT memory ready. [ 5.662972] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 5.663477] [drm] PCIE GART of 512M enabled (table at 0x000000807FD00000= ). [ 5.664899] [drm] Loading DMUB firmware via PSP: version=3D0x08003700 [ 5.665329] [drm] Found VCN firmware Version ENC: 1.19 DEC: 7 VEP: 0 Rev= ision: 13 [ 5.665341] amdgpu 0000:07:00.0: amdgpu: Will use PSP to load VCN firmwa= re [ 5.691359] [drm] reserve 0x4000000 from 0x8078000000 for PSP TMR [ 6.237764] amdgpu 0000:07:00.0: amdgpu: RAS: optional ras ta ucode is n= ot available [ 6.245936] amdgpu 0000:07:00.0: amdgpu: RAP: optional rap ta ucode is n= ot available [ 6.245970] amdgpu 0000:07:00.0: amdgpu: SECUREDISPLAY: securedisplay ta= ucode is not available [ 6.279536] amdgpu 0000:07:00.0: amdgpu: SMU is initialized successfully! [ 6.279561] [drm] Seamless boot condition check passed [ 6.280713] [drm] Display Core v3.2.266 initialized on DCN 3.1.4 [ 6.280721] [drm] DP-HDMI FRL PCON supported [ 6.282465] [drm] DMUB hardware initialized: version=3D0x08003700 [ 6.287786] [drm] kiq ring mec 3 pipe 1 q 0 [ 6.290333] [drm] VCN decode and encode initialized successfully(under D= PG Mode). [ 6.290409] amdgpu 0000:07:00.0: [drm:jpeg_v4_0_hw_init [amdgpu]] JPEG d= ecode initialized successfully. [ 6.295084] kfd kfd: amdgpu: Allocated 3969056 bytes on gart [ 6.295113] kfd kfd: amdgpu: Total number of KFD nodes to be created: 1 [ 6.295247] amdgpu: Virtual CRAT table created for GPU [ 6.296073] amdgpu: Topology: Add dGPU node [0x1900:0x1002] [ 6.296084] kfd kfd: amdgpu: added device 1002:1900 [ 6.296102] amdgpu 0000:07:00.0: amdgpu: SE 1, SH per SE 2, CU per SH 6,= active_cu_number 12 [ 6.296114] amdgpu 0000:07:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng = 0 on hub 0 [ 6.296122] amdgpu 0000:07:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng= 1 on hub 0 [ 6.296129] amdgpu 0000:07:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng= 4 on hub 0 [ 6.296136] amdgpu 0000:07:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng= 6 on hub 0 [ 6.296143] amdgpu 0000:07:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng= 7 on hub 0 [ 6.296150] amdgpu 0000:07:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng= 8 on hub 0 [ 6.296157] amdgpu 0000:07:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng= 9 on hub 0 [ 6.296164] amdgpu 0000:07:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng= 10 on hub 0 [ 6.296171] amdgpu 0000:07:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng= 11 on hub 0 [ 6.296178] amdgpu 0000:07:00.0: amdgpu: ring sdma0 uses VM inv eng 12 o= n hub 0 [ 6.296185] amdgpu 0000:07:00.0: amdgpu: ring vcn_unified_0 uses VM inv = eng 0 on hub 8 [ 6.296192] amdgpu 0000:07:00.0: amdgpu: ring jpeg_dec uses VM inv eng 1= on hub 8 [ 6.296199] amdgpu 0000:07:00.0: amdgpu: ring mes_kiq_3.1.0 uses VM inv = eng 13 on hub 0 [ 6.297709] [drm] ring gfx_32768.1.1 was added [ 6.298368] [drm] ring compute_32768.2.2 was added [ 6.299030] [drm] ring sdma_32768.3.3 was added [ 6.299106] [drm] ring gfx_32768.1.1 ib test pass [ 6.299162] [drm] ring compute_32768.2.2 ib test pass [ 6.299233] [drm] ring sdma_32768.3.3 ib test pass [ 6.303753] [drm] Initialized amdgpu 3.57.0 20150101 for 0000:07:00.0 on= minor 0 [ 6.305636] amdgpu 0000:07:00.0: [drm] Cannot find any crtc or sizes [ 6.305655] [drm] DSC precompute is not needed. [ 7.428443] aufs 6.8-20241118 [ 7.447735] spl: loading out-of-tree module taints kernel. [ 7.447774] spl: module verification failed: signature and/or required k= ey missing - tainting kernel [ 7.473708] zfs: module license 'CDDL' taints kernel. [ 7.473749] Disabling lock debugging due to kernel taint [ 7.473768] zfs: module license taints kernel. [ 8.445274] ZFS: Loaded module v2.2.6-8_g4d7c8a4831, ZFS pool version 50= 00, ZFS filesystem version 5 [ 8.451525] zram: Added device: zram0 [ 8.459967] usbcore: registered new interface driver usbhid [ 8.460001] usbhid: USB HID core driver [ 9.396507] zd0: p1 p2 [ 9.401182] zd16: p1 p2 [ 9.403714] zd32: p1 p2 [ 9.438841] zd144: p1 p2 [ 9.446862] zd160: p1 p2 [ 9.449952] zd176: p1 p2 [ 9.462561] zd192: p1 p2 p3 [ 9.479210] zd208: p1 [ 9.497995] zd224: p1 [ 9.502332] zd240: p1 [ 9.513842] zd256: p1 [ 9.519121] zd272: p1 [ 9.531274] zd288: p1 [ 9.544013] zd304: p1 p2 p3 [ 9.556444] zd320: p1 [ 9.561798] zd336: p1 [ 9.564952] zd352: p1 [ 9.576968] zd368: p1 [ 9.581743] zd384: p1 [ 9.586965] zd400: p1 [ 9.600764] zd416: p1 [ 9.615404] zd432: p1 p2 p3 [ 9.627818] zd448: p1 [ 9.640320] zd464: p1 [ 9.644034] zd480: p1 [ 9.657310] pcie_mp2_amd 0000:07:00.7: sfh1_1_init failed err -95 [ 9.657834] zd496: p1 p2 p3 [ 9.660678] zd512: p1 p2 p3 [ 9.674613] zd528: p1 [ 9.677809] zd544: p1 [ 9.691380] zd560: p1 [ 9.695991] zd576: p1 [ 9.710232] zd592: p1 [ 9.724310] zd608: p1 [ 9.728514] zd624: p1 [ 9.741590] zd640: p1 [ 9.753245] zd656: p1 [ 9.756131] zd672: p1 [ 9.767304] zd688: p1 [ 9.773466] zd704: p1 [ 9.776668] zd720: p1 [ 9.790611] zd736: p1 p2 p3 [ 9.803857] zd752: p1 p2 p3 [ 9.807237] zd768: p1 p2 p3 [ 9.819582] zd784: p1 [ 9.830972] zd800: p1 [ 9.835318] zd816: p1 [ 9.851177] zd832: p1 p2 [ 9.862476] zd848: p1 p2 [ 9.874208] zd864: p1 p2 [ 9.888243] zd880: p1 p2 p3 [ 9.900926] zd896: p1 p2 [ 9.905365] zd912: p1 p2 [ 9.908283] zd928: p1 p2 [ 9.921880] GPT:Primary header thinks Alt. header is not at the end of t= he disk. [ 9.921916] GPT:2092307 !=3D 2121223 [ 9.921923] GPT:Alternate GPT header not at the end of the disk. [ 9.921930] GPT:2092307 !=3D 2121223 [ 9.921936] GPT: Use GNU Parted to correct GPT errors. [ 9.921956] zd944: p1 p2 p3 [ 9.926837] GPT:Primary header thinks Alt. header is not at the end of t= he disk. [ 9.926856] GPT:2092307 !=3D 2121223 [ 9.926863] GPT:Alternate GPT header not at the end of the disk. [ 9.926871] GPT:2092307 !=3D 2121223 [ 9.926876] GPT: Use GNU Parted to correct GPT errors. [ 9.926888] zd960: p1 p2 p3 [ 9.940779] zd976: p1 p2 [ 9.947284] zd992: p1 p2 [ 9.961786] zd1008: p1 p2 [ 9.964797] zd1024: p1 p2 [ 9.973156] GPT:Primary header thinks Alt. header is not at the end of t= he disk. [ 9.973176] GPT:136314879 !=3D 150994943 [ 9.973183] GPT:Alternate GPT header not at the end of the disk. [ 9.973190] GPT:136314879 !=3D 150994943 [ 9.973196] GPT: Use GNU Parted to correct GPT errors. [ 9.973208] zd1040: p1 p2 p3 p4 [ 9.978939] GPT:Primary header thinks Alt. header is not at the end of t= he disk. [ 9.978956] GPT:136314879 !=3D 150994943 [ 9.978963] GPT:Alternate GPT header not at the end of the disk. [ 9.978970] GPT:136314879 !=3D 150994943 [ 9.978976] GPT: Use GNU Parted to correct GPT errors. [ 9.978987] zd1056: p1 p2 p3 p4 [ 9.997241] zd1104: p1 p2 p3 [ 10.015204] zd1120: p1 p2 [ 10.039813] zd1136: p1 p2 [ 10.053519] zd1152: p1 p2 [ 10.057397] zd1168: p1 p2 [ 10.059243] zd1184: p1 p2 [ 10.073804] zd1200: p1 [ 10.091854] zd1216: p1 [ 10.096485] zd1232: p1 [ 10.109361] zd1248: p1 [ 10.120892] zd1264: p1 [ 10.124926] zd1280: p1 [ 10.138443] zd1296: p1 p2 p3 p4 [ 10.151472] zd1312: p1 p2 p3 p4 [ 10.154671] zd1328: p1 p2 p3 p4 [ 10.165337] zd1344: p1 [ 10.170596] zd1360: p1 [ 10.175486] zd1376: p1 [ 10.193476] zd1392: p1 [ 10.211117] zd1408: p1 [ 10.215308] zd1424: p1 [ 10.229505] zd1440: p1 [ 10.240423] zd1456: p1 [ 10.244656] zd1472: p1 [ 10.254972] zd1488: p1 [ 10.260188] zd1504: p1 [ 10.262725] zd1520: p1 [ 10.273501] zd1536: p1 p2 p3 p4 p5 [ 10.288048] zd1552: p1 p2 p3 p4 p5 [ 10.291370] zd1568: p1 p2 p3 p4 p5 [ 10.357418] zd1712: p1 p2 p3 [ 10.369822] zd1728: p1 p2 p3 [ 10.373371] zd1744: p1 p2 p3 [ 10.385383] zd1760: p1 [ 10.389904] zd1776: p1 [ 10.392520] zd1792: p1 [ 10.408595] zd1808: p1 [ 10.424685] zd1824: p1 [ 10.428784] zd1840: p1 [ 10.441381] zd1856: p1 [ 10.455092] zd1872: p1 [ 10.458960] zd1888: p1 [ 10.462251] zd1904: p1 [ 10.467292] zd1920: p1 [ 10.471515] zd1936: p1 [ 10.482930] zd1952: p1 p2 p3 [ 10.497493] zd1968: p1 p2 p3 [ 10.500866] zd1984: p1 p2 p3 [ 10.513614] zd2000: p1 [ 10.528958] zd2016: p1 [ 10.533789] zd2032: p1 [ 10.548673] zd2048: p1 [ 10.559739] zd2064: p1 [ 10.564121] zd2080: p1 [ 10.577550] zd2096: p1 [ 10.588429] zd2112: p1 [ 10.592466] zd2128: p1 [ 10.605433] zd2144: p1 [ 10.616125] zd2160: p1 [ 10.619785] zd2176: p1 [ 10.630272] zd2192: p1 p2 p3 [ 10.643644] zd2208: p1 p2 p3 [ 10.647987] zd2224: p1 p2 p3 [ 10.659162] zd2240: p1 [ 10.663553] zd2256: p1 [ 10.666556] zd2272: p1 [ 10.685401] zd2288: p1 [ 10.690621] zd2304: p1 [ 10.705112] zd2320: p1 [ 10.708159] zd2336: p1 [ 10.718401] zd2352: p1 [ 10.721129] zd2368: p1 [ 10.732581] zd2384: p1 p2 p3 [ 10.737364] zd2400: p1 p2 p3 [ 10.748981] zd2416: p1 [ 10.751487] zd2432: p1 [ 10.765338] zd2448: p1 [ 10.769094] zd2464: p1 [ 10.787553] zd2480: p1 [ 10.790660] zd2496: p1 [ 10.800120] zd2512: p1 [ 10.802556] zd2528: p1 [ 10.813603] zd2544: p1 p2 p3 [ 10.817336] zd2560: p1 p2 p3 [ 10.829861] zd2576: p1 [ 10.846220] zd2592: p1 [ 10.849689] zd2608: p1 [ 10.861449] zd2624: p1 [ 10.874833] zd2640: p1 [ 10.878814] zd2656: p1 [ 10.893092] zd2672: p1 p2 p3 [ 10.903658] zd2688: p1 p2 p3 [ 10.906908] zd2704: p1 p2 p3 [ 10.916403] zd2720: p1 [ 10.921545] zd2736: p1 [ 10.924611] zd2752: p1 [ 10.929644] zd2768: p1 [ 10.935525] zd2784: p1 [ 10.954379] zd2800: p1 p2 p3 [ 10.958026] zd2816: p1 p2 p3 [ 10.971677] zd2832: p1 [ 10.975041] zd2848: p1 [ 10.985655] zd2864: p1 [ 10.989718] zd2880: p1 [ 11.007745] zd2896: p1 [ 11.010784] zd2912: p1 [ 11.013296] zd2928: p1 [ 11.015352] zd2944: p1 [ 11.020160] zd2960: p1 p2 [ 11.025573] zd2976: p1 p2 [ 11.041262] zd3040: p1 p2 [ 11.049825] zd3056: p1 p2 [ 11.055432] zd3072: p1 p2 [ 11.061875] zd3088: p1 p2 [ 11.079360] zd3152: p1 [ 11.099048] zd3184: p1 p2 [ 11.101894] zd3200: p1 p2 [ 11.117340] zd3264: p1 [ 11.133901] zd3296: p1 [ 11.137994] zd3312: p1 [ 11.140895] zd3328: p1 [ 11.148472] zd3344: p1 p2 [ 11.153157] zd3360: p1 p2 [ 46.369382] loop0: detected capacity change from 0 to 9598976 [ 47.145668] EXT4-fs: Warning: mounting with data=3Djournal disables dela= yed allocation, dioread_nolock, O_DIRECT and fast_commit support! [ 47.145703] EXT4-fs (dm-7): mounting ext3 file system using the ext4 sub= system [ 47.151293] EXT4-fs (dm-7): mounted filesystem 3b55de21-2328-4c37-8970-f= 425c189995e r/w with journalled data mode. Quota mode: none. [ 47.153643] EXT4-fs (dm-7): unmounting filesystem 3b55de21-2328-4c37-897= 0-f425c189995e. [ 92.580568] EXT4-fs (loop0): mounted filesystem 3d024585-a02c-4717-94fb-= de350993d29e ro with ordered data mode. Quota mode: none. [ 92.599669] aufs test_add:291:mount[4141]: uid/gid/perm /root.ro 0/0/075= 5, 0/0/01777 [ 92.846126] EXT4-fs (loop0): re-mounted 3d024585-a02c-4717-94fb-de350993= d29e ro. Quota mode: none. [ 92.851742] EXT4-fs (loop0): re-mounted 3d024585-a02c-4717-94fb-de350993= d29e ro. Quota mode: none. [ 92.877108] EXT4-fs (loop0): re-mounted 3d024585-a02c-4717-94fb-de350993= d29e ro. Quota mode: none. [ 92.913093] EXT4-fs (loop0): re-mounted 3d024585-a02c-4717-94fb-de350993= d29e ro. Quota mode: none. [ 93.293601] systemd[1]: Inserted module 'autofs4' [ 93.326879] systemd[1]: systemd 249.11-0ubuntu3.12 running in system mod= e (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPE= NSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSET= UP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZST= D -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=3Dunified) [ 93.327043] systemd[1]: Detected architecture x86-64. [ 93.327755] systemd[1]: Hostname set to . [ 93.345484] audit: type=3D1334 audit(1733146870.014:9): prog-id=3D3 op= =3DLOAD [ 93.345504] audit: type=3D1300 audit(1733146870.014:9): arch=3Dc000003e = syscall=3D321 success=3Dyes exit=3D8 a0=3D5 a1=3D7ffc322f1390 a2=3D78 a3=3D= 7ffc322f1390 items=3D0 ppid=3D0 pid=3D1 auid=3D4294967295 uid=3D0 gid=3D0 e= uid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4= 294967295 comm=3D"systemd" exe=3D"/usr/lib/systemd/systemd" subj=3Dunconfin= ed key=3D(null) [ 93.345544] audit: type=3D1327 audit(1733146870.014:9): proctitle=3D2F73= 62696E2F696E6974007A796F7665726C6179 [ 93.345561] audit: type=3D1334 audit(1733146870.014:10): prog-id=3D3 op= =3DUNLOAD [ 93.345575] audit: type=3D1300 audit(1733146870.014:10): arch=3Dc000003e= syscall=3D3 success=3Dyes exit=3D0 a0=3D8 a1=3D7ffc322f1450 a2=3D78 a3=3D2= 00000008 items=3D0 ppid=3D0 pid=3D1 auid=3D4294967295 uid=3D0 gid=3D0 euid= =3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294= 967295 comm=3D"systemd" exe=3D"/usr/lib/systemd/systemd" subj=3Dunconfined = key=3D(null) [ 93.345612] audit: type=3D1327 audit(1733146870.014:10): proctitle=3D2F7= 362696E2F696E6974007A796F7665726C6179 [ 93.345629] audit: type=3D1334 audit(1733146870.014:11): prog-id=3D4 op= =3DLOAD [ 93.345642] audit: type=3D1300 audit(1733146870.014:11): arch=3Dc000003e= syscall=3D321 success=3Dyes exit=3D8 a0=3D5 a1=3D7ffc322f1460 a2=3D78 a3= =3D7ffc322f1460 items=3D0 ppid=3D0 pid=3D1 auid=3D4294967295 uid=3D0 gid=3D= 0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses= =3D4294967295 comm=3D"systemd" exe=3D"/usr/lib/systemd/systemd" subj=3Dunco= nfined key=3D(null) [ 93.345684] audit: type=3D1327 audit(1733146870.014:11): proctitle=3D2F7= 362696E2F696E6974007A796F7665726C6179 [ 93.345701] audit: type=3D1334 audit(1733146870.014:12): prog-id=3D4 op= =3DUNLOAD [ 93.688188] systemd[1]: Configuration file /run/systemd/system/netplan-o= vs-cleanup.service is marked world-inaccessible. This has no effect as conf= iguration data is accessible via APIs without restrictions. Proceeding anyw= ay. [ 93.753703] systemd[1]: Queued start job for default target Graphical In= terface. [ 93.766962] systemd[1]: Created slice Slice /system/modprobe. [ 93.767496] systemd[1]: Created slice Slice /system/serial-getty. [ 93.767899] systemd[1]: Created slice Slice /system/ourcorp-proxhub. [ 93.768215] systemd[1]: Created slice User and Session Slice. [ 93.768330] systemd[1]: Started Dispatch Password Requests to Console Di= rectory Watch. [ 93.768435] systemd[1]: Started Forward Password Requests to Wall Direct= ory Watch. [ 93.768637] systemd[1]: Set up automount Arbitrary Executable File Forma= ts File System Automount Point. [ 93.768697] systemd[1]: Reached target Local Encrypted Volumes. [ 93.768754] systemd[1]: Reached target Remote File Systems. [ 93.768789] systemd[1]: Reached target Slice Units. [ 93.768830] systemd[1]: Reached target TLS tunnels for network services = - per-config-file target. [ 93.768874] systemd[1]: Reached target Swaps. [ 93.768912] systemd[1]: Reached target Local Verity Protected Volumes. [ 93.769021] systemd[1]: Listening on Device-mapper event daemon FIFOs. [ 93.769225] systemd[1]: Listening on LVM2 poll daemon socket. [ 93.769374] systemd[1]: Listening on Syslog Socket. [ 93.769514] systemd[1]: Listening on fsck to fsckd communication Socket. [ 93.769613] systemd[1]: Listening on initctl Compatibility Named Pipe. [ 93.769763] systemd[1]: Listening on Journal Socket (/dev/log). [ 93.769965] systemd[1]: Listening on Network Service Netlink Socket. [ 93.770179] systemd[1]: Listening on udev Control Socket. [ 93.770323] systemd[1]: Listening on udev Kernel Socket. [ 93.771126] systemd[1]: Created slice Slice /system/ourcorp-diskmanager-= disk-added. [ 93.771316] systemd[1]: Listening on Journal Socket. [ 93.771556] systemd[1]: Condition check resulted in Huge Pages File Syst= em being skipped. [ 93.773339] systemd[1]: Mounting POSIX Message Queue File System... [ 93.774840] systemd[1]: Mounting Mount /proc/xen files... [ 93.776415] systemd[1]: Mounting Kernel Debug File System... [ 93.777978] systemd[1]: Mounting Kernel Trace File System... [ 93.780685] systemd[1]: Starting Journal Service... [ 93.780961] systemd[1]: Finished Availability of block devices. [ 93.783096] systemd[1]: Starting Set the console keyboard layout... [ 93.785089] systemd[1]: Starting Create List of Static Device Nodes... [ 93.787089] systemd[1]: Starting Monitoring of LVM2 mirrors, snapshots e= tc. using dmeventd or progress polling... [ 93.789213] systemd[1]: Starting Load Kernel Module configfs... [ 93.791228] systemd[1]: Starting Load Kernel Module drm... [ 93.793464] systemd[1]: Starting Load Kernel Module efi_pstore... [ 93.795709] systemd[1]: Starting Load Kernel Module fuse... [ 93.796986] systemd[1]: Condition check resulted in OpenVSwitch configur= ation for cleanup being skipped. [ 93.797299] systemd[1]: Condition check resulted in File System Check on= Root Device being skipped. [ 93.800080] systemd[1]: Starting Load Kernel Modules... [ 93.802553] systemd[1]: Starting Remount Root and Kernel File Systems... [ 93.805217] systemd[1]: Starting Coldplug All udev Devices... [ 93.810431] systemd[1]: Mounted POSIX Message Queue File System. [ 93.810600] systemd[1]: Mounted Mount /proc/xen files. [ 93.810745] systemd[1]: Mounted Kernel Debug File System. [ 93.810998] systemd[1]: Mounted Kernel Trace File System. [ 93.811662] systemd[1]: Finished Create List of Static Device Nodes. [ 93.812099] systemd[1]: modprobe@configfs.service: Deactivated successfu= lly. [ 93.812510] systemd[1]: Finished Load Kernel Module configfs. [ 93.812925] systemd[1]: modprobe@drm.service: Deactivated successfully. [ 93.813332] systemd[1]: Finished Load Kernel Module drm. [ 93.813737] systemd[1]: modprobe@efi_pstore.service: Deactivated success= fully. [ 93.814138] systemd[1]: Finished Load Kernel Module efi_pstore. [ 93.814608] systemd[1]: modprobe@fuse.service: Deactivated successfully. [ 93.815026] systemd[1]: Finished Load Kernel Module fuse. [ 93.818346] systemd[1]: Finished Remount Root and Kernel File Systems. [ 93.819394] xen:xen_evtchn: Event-channel device installed [ 93.820956] systemd[1]: Mounting FUSE Control File System... [ 93.823378] systemd[1]: Mounting Kernel Configuration File System... [ 93.823650] systemd[1]: Condition check resulted in Platform Persistent = Storage Archival being skipped. [ 93.825893] systemd[1]: Starting Load/Save Random Seed... [ 93.828303] systemd[1]: Starting Create System Users... [ 93.835870] systemd[1]: Mounted FUSE Control File System. [ 93.836037] systemd[1]: Mounted Kernel Configuration File System. [ 93.841314] systemd[1]: Finished Load/Save Random Seed. [ 93.841589] systemd[1]: Condition check resulted in First Boot Complete = being skipped. [ 93.873169] systemd[1]: Finished Create System Users. [ 93.875559] systemd[1]: Starting Create Static Device Nodes in /dev... [ 93.884225] systemd[1]: Finished Set the console keyboard layout. [ 93.884763] systemd[1]: Started Journal Service. [ 93.890345] xen_pciback: backend is passthrough [ 93.895359] systemd-journald[4245]: Received client request to flush run= time journal. (d1) Bootstrapping... (d1) Xen Minimal OS (pv)! (d1) start_info: 0x10a000(VA) (d1) nr_pages: 0x4000 (d1) shared_inf: 0x8e49c000(MA) (d1) pt_base: 0x10d000(VA) (d1) nr_pt_frames: 0x5 (d1) mfn_list: 0xea000(VA) (d1) mod_start: 0x0(VA) (d1) mod_len: 0 (d1) flags: 0x10 (d1) cmd_line: --event 91 --watch-nb 512 --entry-nb 8000 --entry-size 4= 000 (d1) stack: 0xc8c40-0xe8c40 (d1) MM: Init (d1) _text: 0x0(VA) (d1) _etext: 0x7120f(VA) (d1) _erodata: 0x87000(VA) (d1) _edata: 0x89064(VA) (d1) stack start: 0xc8c40(VA) (d1) _end: 0xe9884(VA) (d1) start_pfn: 112 (d1) max_pfn: 4000 (d1) Mapping memory range 0x112000 - 0x4000000 (d1) setting 0x0-0x87000 readonly (d1) skipped 1000 (d1) Maximum memory size: 32776 pages (d1) MM: Initialise page allocator for 130000(130000)-4000000(4000000) (d1) Adding memory range 131000-4000000 (d1) MM: done (d1) remapped p2m list to 0x8000002000 (d1) Demand map pfns at 100000000000-108000000000. (d1) Heap resides at 200000000000-208000000000. (XEN) common/grant_table.c:1909:d1v0 Expanding d1 grant table from 1 to 4 f= rames [ 94.430994] ccp 0000:07:00.2: tee: ring init command failed (0x00000006) [ 94.431027] ccp 0000:07:00.2: tee: failed to init ring buffer [ 94.485150] amd-tee driver: tee not present [ 94.864322] snd_hda_intel 0000:07:00.6: no codecs found! (XEN) AMD-Vi: Disable: device id =3D 0x300, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Re-assign 0000:03:00.0 from d0 to d[IO] (XEN) AMD-Vi: Disable: device id =3D 0x200, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Re-assign 0000:02:00.0 from d0 to d[IO] (XEN) AMD-Vi: Disable: device id =3D 0x400, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Re-assign 0000:04:00.0 from d0 to d[IO] (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x300, type =3D 0x1, root= table =3D 0xd51d23000, domain =3D 2, paging mode =3D 3 (XEN) AMD-Vi: Re-assign 0000:03:00.0 from d[IO] to d2 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x200, type =3D 0x1, root= table =3D 0xd51d23000, domain =3D 2, paging mode =3D 3 (XEN) AMD-Vi: Re-assign 0000:02:00.0 from d[IO] to d2 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x400, type =3D 0x1, root= table =3D 0xd51d23000, domain =3D 2, paging mode =3D 3 (XEN) AMD-Vi: Re-assign 0000:04:00.0 from d[IO] to d2 (d2) mapping kernel into physical memory (d2) about to get started... (XEN) common/grant_table.c:1909:d2v0 Expanding d2 grant table from 1 to 2 f= rames (XEN) arch/x86/pv/emul-priv-op.c:1015:d2v0 RDMSR 0xc001029b unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1015:d2v0 RDMSR 0xc001029a unimplemented (XEN) d2: Forcing read-only access to MFN fc600 (XEN) d0: Forcing read-only access to MFN fc600 (XEN) d2: Forcing read-only access to MFN fc900 (XEN) d0: Forcing read-only access to MFN fc900 (XEN) d2: Forcing read-only access to MFN fc300 (XEN) d0: Forcing read-only access to MFN fc300 (XEN) common/grant_table.c:1909:d0v3 Expanding d0 grant table from 1 to 2 f= rames (XEN) common/grant_table.c:1909:d0v3 Expanding d0 grant table from 2 to 3 f= rames (d4) mapping kernel into physical memory (d4) about to get started... (d3) mapping kernel into physical memory (d3) about to get started... (d7) mapping kernel into physical memory (d7) about to get started... (d11) mapping kernel into physical memory (d11) about to get started... (XEN) common/grant_table.c:1909:d3v0 Expanding d3 grant table from 1 to 2 f= rames (XEN) common/grant_table.c:1909:d4v0 Expanding d4 grant table from 1 to 2 f= rames (d6) mapping kernel into physical memory (d6) about to get started... (XEN) common/grant_table.c:1909:d7v0 Expanding d7 grant table from 1 to 2 f= rames (XEN) common/grant_table.c:1909:d7v0 Expanding d7 grant table from 2 to 3 f= rames (XEN) common/grant_table.c:1909:d11v0 Expanding d11 grant table from 1 to 2= frames (d9) mapping kernel into physical memory (d9) about to get started... (d8) mapping kernel into physical memory (d8) about to get started... (d10) mapping kernel into physical memory (d10) about to get started... (XEN) common/grant_table.c:1909:d6v0 Expanding d6 grant table from 1 to 2 f= rames (XEN) common/grant_table.c:1909:d9v0 Expanding d9 grant table from 1 to 2 f= rames (XEN) common/grant_table.c:1909:d9v0 Expanding d9 grant table from 2 to 3 f= rames (XEN) common/grant_table.c:1909:d10v1 Expanding d10 grant table from 1 to 2= frames (XEN) common/grant_table.c:1909:d10v1 Expanding d10 grant table from 2 to 3= frames (XEN) common/grant_table.c:1909:d8v0 Expanding d8 grant table from 1 to 2 f= rames (XEN) common/grant_table.c:1909:d9v1 Expanding d9 grant table from 3 to 4 f= rames (XEN) arch/x86/pv/emul-priv-op.c:1015:d7v0 RDMSR 0xc001029b unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1015:d7v0 RDMSR 0xc001029a unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1015:d4v0 RDMSR 0xc001029b unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1015:d4v0 RDMSR 0xc001029a unimplemented (XEN) common/grant_table.c:1909:d10v1 Expanding d10 grant table from 3 to 4= frames (XEN) arch/x86/pv/emul-priv-op.c:1015:d3v0 RDMSR 0xc001029b unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1015:d3v0 RDMSR 0xc001029a unimplemented (d5) mapping kernel into physical memory (d5) about to get started... (XEN) arch/x86/pv/emul-priv-op.c:1015:d5v0 RDMSR 0xc0010112 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1015:d10v0 RDMSR 0xc001029b unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1015:d10v0 RDMSR 0xc001029a unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1015:d9v0 RDMSR 0xc001029b unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1015:d9v0 RDMSR 0xc001029a unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1015:d11v0 RDMSR 0xc001029b unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1015:d11v0 RDMSR 0xc001029a unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1015:d6v0 RDMSR 0xc001029b unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1015:d6v0 RDMSR 0xc001029a unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1015:d8v0 RDMSR 0xc001029b unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1015:d8v0 RDMSR 0xc001029a unimplemented (XEN) common/grant_table.c:1909:d7v0 Expanding d7 grant table from 3 to 4 f= rames (XEN) arch/x86/pv/emul-priv-op.c:1015:d5v1 RDMSR 0xc001029b unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1015:d5v1 RDMSR 0xc0010299 unimplemented (XEN) common/grant_table.c:1909:d5v1 Expanding d5 grant table from 1 to 2 f= rames (XEN) common/grant_table.c:1909:d5v1 Expanding d5 grant table from 2 to 3 f= rames (XEN) common/grant_table.c:1909:d5v1 Expanding d5 grant table from 3 to 4 f= rames (XEN) common/grant_table.c:1909:d5v1 Expanding d5 grant table from 4 to 5 f= rames (XEN) common/grant_table.c:1909:d5v1 Expanding d5 grant table from 5 to 6 f= rames (XEN) common/grant_table.c:1909:d5v1 Expanding d5 grant table from 6 to 7 f= rames (XEN) common/grant_table.c:1909:d5v1 Expanding d5 grant table from 7 to 8 f= rames (XEN) common/grant_table.c:1909:d5v1 Expanding d5 grant table from 8 to 9 f= rames (XEN) common/grant_table.c:1909:d5v1 Expanding d5 grant table from 9 to 10 = frames (XEN) common/grant_table.c:1909:d5v1 Expanding d5 grant table from 10 to 11= frames (XEN) common/grant_table.c:1909:d5v0 Expanding d5 grant table from 11 to 12= frames (XEN) common/grant_table.c:1909:d9v1 Expanding d9 grant table from 4 to 5 f= rames (XEN) common/grant_table.c:1909:d6v0 Expanding d6 grant table from 2 to 3 f= rames (XEN) common/grant_table.c:1909:d6v0 Expanding d6 grant table from 3 to 4 f= rames (XEN) common/grant_table.c:1909:d11v0 Expanding d11 grant table from 2 to 3= frames (XEN) common/grant_table.c:1909:d3v0 Expanding d3 grant table from 2 to 3 f= rames (XEN) common/grant_table.c:1909:d10v0 Expanding d10 grant table from 4 to 5= frames (XEN) common/grant_table.c:1909:d8v0 Expanding d8 grant table from 2 to 3 f= rames (XEN) common/grant_table.c:1909:d5v1 Expanding d5 grant table from 12 to 13= frames (XEN) common/grant_table.c:1909:d9v0 Expanding d9 grant table from 5 to 6 f= rames ##### -> network driver domain (d2) has been started along with a few other= vms root@amd-xen-dom0:~# xl info host : amd-xen-dom0 release : 6.8.0-48-generic version : #48~22.04.1 SMP PREEMPT_DYNAMIC Tue Nov 26 23:18:3= 4 UTC=20 machine : x86_64 nr_cpus : 16 max_cpu_id : 15 nr_nodes : 1 cores_per_socket : 8 threads_per_core : 2 cpu_mhz : 3293.813 hw_caps : 178bf3ff:76f8320b:2e500800:244037ff:0000000f:f1bf9= 7a9:00405fce:00000780 virt_caps : pv hvm hvm_directio pv_directio hap shadow gnttab-= v1 gnttab-v2 total_memory : 63273 free_memory : 39149 sharing_freed_memory : 0 sharing_used_memory : 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 18 xen_extra : .3 xen_version : 4.18.3 xen_caps : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-= 3.0-x86_64=20 xen_scheduler : credit2 xen_pagesize : 4096 platform_params : virt_start=3D0x0 xen_changeset : Fri Nov 15 14:07:55 2024 +0000 git:8d7c71efb0 xen_commandline : placeholder console=3Dvga,com2 dom0_max_vcpus=3D4-= 8 dom0_mem=3Dmin:6144,max:65536m iommu=3Don,required,intpost,verbose,debug = x2apic=3Doff sched=3Dcredit2 flask=3Denforcing gnttab_max_frames=3D128 xpti= =3Doff smt=3Don cpufreq=3Dxen:performance spec-ctrl=3Dgds-mit=3D0 com2=3Dir= q=3D3,io-base=3D0xfedc9000,reg-shift=3D2 cc_compiler : gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 cc_compile_by :=20 cc_compile_domain :=20 cc_compile_date : Fri Nov 15 14:08:14 UTC 2024 build_id : c241bf4ecc9a93bbcc74e7f758c4f55a6759216f xend_config_format : 4 ##### -> domU is started with memory =3D 3900 (XEN) HVM d12v0 save: CPU (XEN) HVM d12v1 save: CPU (XEN) HVM d12 save: PIC (XEN) HVM d12 save: IOAPIC (XEN) HVM d12v0 save: LAPIC (XEN) HVM d12v1 save: LAPIC (XEN) HVM d12v0 save: LAPIC_REGS (XEN) HVM d12v1 save: LAPIC_REGS (XEN) HVM d12 save: PCI_IRQ (XEN) HVM d12 save: ISA_IRQ (XEN) HVM d12 save: PCI_LINK (XEN) HVM d12 save: PIT (XEN) HVM d12 save: RTC (XEN) HVM d12 save: HPET (XEN) HVM d12 save: PMTIMER (XEN) HVM d12v0 save: MTRR (XEN) HVM d12v1 save: MTRR (XEN) HVM d12 save: VIRIDIAN_DOMAIN (XEN) HVM d12v0 save: CPU_XSAVE (XEN) HVM d12v1 save: CPU_XSAVE (XEN) HVM d12v0 save: VIRIDIAN_VCPU (XEN) HVM d12v1 save: VIRIDIAN_VCPU (XEN) HVM d12v0 save: VMCE_VCPU (XEN) HVM d12v1 save: VMCE_VCPU (XEN) HVM d12v0 save: TSC_ADJUST (XEN) HVM d12v1 save: TSC_ADJUST (XEN) HVM d12v0 save: CPU_MSR (XEN) HVM d12v1 save: CPU_MSR (XEN) HVM12 restore: CPU 0 (d12) HVM Loader (d12) Detected Xen v4.18.3 (d12) Xenbus rings @0xfeffc000, event channel 1 (d12) System requested SeaBIOS (d12) CPU speed is 3294 MHz (d12) Relocating guest memory for lowmem MMIO space disabled (XEN) arch/x86/hvm/irq.c:367: Dom12 PCI link 0 changed 0 -> 5 (d12) PCI-ISA link 0 routed to IRQ5 (XEN) arch/x86/hvm/irq.c:367: Dom12 PCI link 1 changed 0 -> 10 (d12) PCI-ISA link 1 routed to IRQ10 (XEN) arch/x86/hvm/irq.c:367: Dom12 PCI link 2 changed 0 -> 11 (d12) PCI-ISA link 2 routed to IRQ11 (XEN) arch/x86/hvm/irq.c:367: Dom12 PCI link 3 changed 0 -> 5 (d12) PCI-ISA link 3 routed to IRQ5 (d12) pci dev 01:2 INTD->IRQ5 (d12) pci dev 01:3 INTA->IRQ10 (d12) pci dev 02:0 INTA->IRQ11 (d12) pci dev 03:0 INTA->IRQ5 (d12) pci dev 05:0 INTA->IRQ10 (d12) RAM in high memory; setting high_mem resource base to 102c00000 (d12) pci dev 02:0 bar 14 size 001000000: 0f0000008 (d12) pci dev 04:0 bar 10 size 001000000: 0f1000008 (d12) pci dev 05:0 bar 30 size 000040000: 0f2000000 (d12) pci dev 04:0 bar 30 size 000010000: 0f2040000 (d12) pci dev 03:0 bar 10 size 000004000: 0f2050000 (d12) pci dev 04:0 bar 18 size 000001000: 0f2054000 (d12) pci dev 02:0 bar 10 size 000000100: 00000c001 (d12) pci dev 05:0 bar 10 size 000000100: 00000c101 (d12) pci dev 05:0 bar 14 size 000000100: 0f2055000 (d12) pci dev 01:2 bar 20 size 000000020: 00000c201 (d12) pci dev 01:1 bar 20 size 000000010: 00000c221 (d12) Multiprocessor initialisation: (d12) - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done. (d12) - CPU1 ... 48-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done. (d12) Writing SMBIOS tables ... (d12) Loading SeaBIOS ... (d12) Creating MP tables ... (d12) Loading ACPI ... (d12) vm86 TSS at fc100280 (d12) BIOS map: (d12) 10000-100e3: Scratch space (d12) c0000-fffff: Main BIOS (d12) E820 table: (d12) [00]: 00000000:00000000 - 00000000:000a0000: RAM (d12) HOLE: 00000000:000a0000 - 00000000:000c0000 (d12) [01]: 00000000:000c0000 - 00000000:00100000: RESERVED (d12) [02]: 00000000:00100000 - 00000000:f0000000: RAM (d12) HOLE: 00000000:f0000000 - 00000000:fc000000 (d12) [03]: 00000000:fc000000 - 00000000:fc00b000: NVS (d12) [04]: 00000000:fc00b000 - 00000001:00000000: RESERVED (d12) [05]: 00000001:00000000 - 00000001:02c00000: RAM (d12) Invoking SeaBIOS ... (d12) SeaBIOS (version rel-1.16.2-0-gea1b7a0-Xen) (d12) BUILD: gcc: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 binutils: (GNU Binu= tils for Ubuntu) 2.38 (d12)=20 (d12) Found Xen hypervisor signature at 40000100 (d12) Running on QEMU (i440fx) (d12) xen: copy e820... (d12) Relocating init from 0x000d4760 to 0xeefeb2c0 (size 85152) (d12) Found 9 PCI devices (max PCI bus is 00) (d12) Allocated Xen hypercall page at effff000 (d12) Detected Xen v4.18.3 (d12) xen: copy BIOS tables... (d12) Copying SMBIOS from 0x00010020 to 0x000f5aa0 (d12) Copying MPTABLE from 0xfc100180/fc100190 to 0x000f59a0 (d12) Copying PIR from 0x00010040 to 0x000f5920 (d12) Copying ACPI RSDP from 0x000100c0 to 0x000f58f0 (d12) table(50434146)=3D0xfc00a370 (via xsdt) (d12) Using pmtimer, ioport 0xb008 (d12) table(50434146)=3D0xfc00a370 (via xsdt) (d12) ACPI: parse DSDT at 0xfc001040 (len 37539) (d12) parse_termlist: parse error, skip from 16/27641 (d12) parse_termlist: parse error, skip from 87/6041 (d12) Scan for VGA option rom (d12) Running option rom at c000:0003 (XEN) arch/x86/hvm/stdvga.c:172:d12v0 entering stdvga mode (d12) pmm call arg1=3D0 (d12) Turning on vga text mode console (d12) SeaBIOS (version rel-1.16.2-0-gea1b7a0-Xen) (d12) Machine UUID 61d12f94-5b6f-442f-895e-a6fac7de64c3 (d12) UHCI init on dev 00:01.2 (io=3Dc200) (d12) ATA controller 1 at 1f0/3f4/c220 (irq 14 dev 9) (d12) ATA controller 2 at 170/374/c228 (irq 15 dev 9) (d12) Searching bootorder for: HALT (d12) Found 0 lpt ports (d12) Found 0 serial ports (d12) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (52000 MiBytes) (d12) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0 (d12) Searching bios-geometry for: /pci@i0cf8/*@1,1/drive@0/disk@0 (d12) ata0-1: QEMU HARDDISK ATA-7 Hard-Disk (20480 MiBytes) (d12) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@1 (d12) Searching bios-geometry for: /pci@i0cf8/*@1,1/drive@0/disk@1 (d12) PS2 keyboard initialized (d12) All threads complete. (d12) Scan for option roms (d12) Running option rom at ca00:0003 (d12) pmm call arg1=3D1 (d12) pmm call arg1=3D0 (d12) pmm call arg1=3D1 (d12) pmm call arg1=3D0 (d12) Searching bootorder for: /pci@i0cf8/*@5 (d12)=20 (d12) Press ESC for boot menu. (d12)=20 (d12) Searching bootorder for: HALT (d12) drive 0x000f5870: PCHS=3D16383/16/63 translation=3Dlba LCHS=3D1024/25= 5/63 s=3D106496000 (d12) drive 0x000f5830: PCHS=3D16383/16/63 translation=3Dlba LCHS=3D1024/25= 5/63 s=3D41943040 (d12) Space available for UMB: cb000-e8800, f52c0-f5830 (d12) Returned 16773120 bytes of ZoneHigh (d12) e820 map has 8 items: (d12) 0: 0000000000000000 - 000000000009fc00 =3D 1 RAM (d12) 1: 000000000009fc00 - 00000000000a0000 =3D 2 RESERVED (d12) 2: 00000000000f0000 - 0000000000100000 =3D 2 RESERVED (d12) 3: 0000000000100000 - 00000000effff000 =3D 1 RAM (d12) 4: 00000000effff000 - 00000000f0000000 =3D 2 RESERVED (d12) 5: 00000000fc000000 - 00000000fc00b000 =3D 4 NVS (d12) 6: 00000000fc00b000 - 0000000100000000 =3D 2 RESERVED (d12) 7: 0000000100000000 - 0000000102c00000 =3D 1 RAM (d12) enter handle_19: (d12) NULL (d12) Booting from Hard Disk... (d12) Booting from 0000:7c00 (XEN) d12: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 3 sp: 0 bu= ild: 2580 (XEN) d12: VIRIDIAN HYPERCALL: enabled: 1 pfn: 4 (XEN) d12v0: VIRIDIAN VP_ASSIST: pfn: 7 (XEN) d12: VIRIDIAN HVCALL_NOTIFY_LONG_SPIN_WAIT (XEN) d12: VIRIDIAN MSR_TIME_REF_COUNT: accessed (XEN) d12v1: VIRIDIAN VP_ASSIST: pfn: 3ffff (XEN) arch/x86/hvm/irq.c:367: Dom12 PCI link 0 changed 5 -> 0 (XEN) arch/x86/hvm/irq.c:367: Dom12 PCI link 1 changed 10 -> 0 (XEN) arch/x86/hvm/irq.c:367: Dom12 PCI link 2 changed 11 -> 0 (XEN) arch/x86/hvm/irq.c:367: Dom12 PCI link 3 changed 5 -> 0 (XEN) d12v0: upcall vector b1 (XEN) d12v1: upcall vector b1 (XEN) Dom12 callback via changed to GSI 24 (XEN) common/grant_table.c:1909:d12v1 Expanding d12 grant table from 1 to 2= frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 2 to 3= frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 3 to 4= frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 4 to 5= frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 5 to 6= frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 6 to 7= frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 7 to 8= frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 8 to 9= frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 9 to 1= 0 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 10 to = 11 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 11 to = 12 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 12 to = 13 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 13 to = 14 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 14 to = 15 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 15 to = 16 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 16 to = 17 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 17 to = 18 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 18 to = 19 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 19 to = 20 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 20 to = 21 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 21 to = 22 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 22 to = 23 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 23 to = 24 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 24 to = 25 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 25 to = 26 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 26 to = 27 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 27 to = 28 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 28 to = 29 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 29 to = 30 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 30 to = 31 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 31 to = 32 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 32 to = 33 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 33 to = 34 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 34 to = 35 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 35 to = 36 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 36 to = 37 frames (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 37 to = 38 frames ##### -> memory for domU is changed to 39000 and the domain is restarted: (XEN) common/memory.c:278:d0v3 Could not allocate order=3D18 extent: id=3D1= 3 memflags=3D0xc0 (0 of 1) (XEN) common/memory.c:278:d0v3 Could not allocate order=3D18 extent: id=3D1= 3 memflags=3D0xc0 (0 of 1) (XEN) common/memory.c:278:d0v3 Could not allocate order=3D18 extent: id=3D1= 3 memflags=3D0xc0 (0 of 1) (XEN) common/memory.c:278:d0v3 Could not allocate order=3D18 extent: id=3D1= 3 memflags=3D0xc0 (0 of 1) (XEN) common/memory.c:278:d0v3 Could not allocate order=3D18 extent: id=3D1= 3 memflags=3D0xc0 (0 of 1) (XEN) common/memory.c:278:d0v3 Could not allocate order=3D9 extent: id=3D13= memflags=3D0xc0 (2 of 4) (XEN) common/memory.c:278:d0v3 Could not allocate order=3D9 extent: id=3D13= memflags=3D0xc0 (0 of 4) (XEN) common/memory.c:278:d0v3 Could not allocate order=3D9 extent: id=3D13= memflags=3D0xc0 (0 of 4) (XEN) common/memory.c:278:d0v3 Could not allocate order=3D9 extent: id=3D13= memflags=3D0xc0 (0 of 4) (XEN) HVM d13v0 save: CPU (XEN) HVM d13v1 save: CPU (XEN) HVM d13 save: PIC (XEN) HVM d13 save: IOAPIC (XEN) HVM d13v0 save: LAPIC (XEN) HVM d13v1 save: LAPIC (XEN) HVM d13v0 save: LAPIC_REGS (XEN) HVM d13v1 save: LAPIC_REGS (XEN) HVM d13 save: PCI_IRQ (XEN) HVM d13 save: ISA_IRQ (XEN) HVM d13 save: PCI_LINK (XEN) HVM d13 save: PIT (XEN) HVM d13 save: RTC (XEN) HVM d13 save: HPET (XEN) HVM d13 save: PMTIMER (XEN) HVM d13v0 save: MTRR (XEN) HVM d13v1 save: MTRR (XEN) HVM d13 save: VIRIDIAN_DOMAIN (XEN) HVM d13v0 save: CPU_XSAVE (XEN) HVM d13v1 save: CPU_XSAVE (XEN) HVM d13v0 save: VIRIDIAN_VCPU (XEN) HVM d13v1 save: VIRIDIAN_VCPU (XEN) HVM d13v0 save: VMCE_VCPU (XEN) HVM d13v1 save: VMCE_VCPU (XEN) HVM d13v0 save: TSC_ADJUST (XEN) HVM d13v1 save: TSC_ADJUST (XEN) HVM d13v0 save: CPU_MSR (XEN) HVM d13v1 save: CPU_MSR (XEN) HVM13 restore: CPU 0 (XEN) common/memory.c:278:d0v0 Could not allocate order=3D0 extent: id=3D13= memflags=3D0xc0 (2799 of 4096) (XEN) AMD-Vi: Error: cannot allocate I/O page table (XEN) AMD-Vi: Error: invalid IO pagetable entry dfn =3D b1ad3c (XEN) domain_crash called from drivers/passthrough/amd/iommu_map.c:457 (XEN) Domain 2 (vcpu#0) crashed on cpu#6: (XEN) ----[ Xen-4.18.3 x86_64 debug=3Dy Not tainted ]---- (XEN) CPU: 6 (XEN) RIP: e033:[] (XEN) RFLAGS: 0000000000000282 EM: 0 CONTEXT: pv guest (d2v0) (XEN) rax: 0000000000000014 rbx: ffffc900421ca000 rcx: ffffffff8220128c (XEN) rdx: 0000000000000001 rsi: ffffc900421d4018 rdi: 0000000000000000 (XEN) rbp: ffffc90040003e18 rsp: ffffc90040003dc8 r8: 0000000000000000 (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000282 (XEN) r12: 0000000000000001 r13: ffffc900421d4018 r14: ffffc900421ca000 (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: 0000000000b506e0 (XEN) cr3: 0000000b3472f000 cr2: 0000758a2803e4b0 (XEN) fsb: 0000000000000000 gsb: ffff88811a200000 gss: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 (XEN) Guest stack trace from rsp=3Dffffc90040003dc8: (XEN) 0000000000000000 0000000000000001 ffffffff81a942a0 0000000000000000 (XEN) ffffc900421d7818 ffffc900421ca000 0000000000000000 0000000000000001 (XEN) ffffc900421ca000 0000000000000000 ffffc90040003e58 ffffffffc050ff35 (XEN) 0000000100000001 24d9cc65bcebac00 ffffc900421ca030 0000000000000000 (XEN) 0000000000000040 ffffc900421ca000 ffffc90040003e88 ffffffffc05134ae (XEN) ffffc900421ca030 0000000000000000 ffffc90040003eef 0000000000000040 (XEN) ffffc90040003ec0 ffffffff81edede3 ffff88811a235e40 000000000000012c (XEN) ffffc90040003ef8 ffffc900421ca030 0000000000000000 ffffc90040003f48 (XEN) ffffffff81edf3c1 ffffffff811b5c7f ffff88811a236100 000000010001cc97 (XEN) 0000000000000007 ffff88811a231b60 ffffc90040003ef8 ffffc90040003ef8 (XEN) ffffc90040003f08 ffffc90040003f08 24d9cc65bcebac00 0000000080000101 (XEN) 0000000000000003 0000000000000008 0000000000000004 ffffffff834060d8 (XEN) ffffc90040003fb8 ffffffff8110a19b ffff88811a234200 0420000200000000 (XEN) ffffffff8340fcc0 000000010001cc97 000000000000000a ffffffff00000003 (XEN) ffffffff81a9f6fe ffffffff83403cc8 0000000000000001 0000000000000000 (XEN) 0000000000000000 0000000000000000 ffffc90040003fd8 ffffffff8110a4e9 (XEN) ffffffff83403cc8 0000000000000001 ffffc90040003fe8 ffffffff8110a84e (XEN) ffffffff83403cb8 ffffffff821ffd0a ffffffff83403ca0 (XEN) Fault while accessing guest memory. (XEN) domain_crash called from drivers/passthrough/iommu.c:366 (XEN) common/memory.c:278:d0v2 Could not allocate order=3D18 extent: id=3D1= 4 memflags=3D0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=3D18 extent: id=3D1= 4 memflags=3D0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=3D18 extent: id=3D1= 4 memflags=3D0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=3D18 extent: id=3D1= 4 memflags=3D0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=3D18 extent: id=3D1= 4 memflags=3D0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=3D9 extent: id=3D14= memflags=3D0xc0 (2 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=3D9 extent: id=3D14= memflags=3D0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=3D9 extent: id=3D14= memflags=3D0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=3D9 extent: id=3D14= memflags=3D0xc0 (0 of 4) (XEN) HVM d14v0 save: CPU (XEN) HVM d14v1 save: CPU (XEN) HVM d14 save: PIC (XEN) HVM d14 save: IOAPIC (XEN) HVM d14v0 save: LAPIC (XEN) HVM d14v1 save: LAPIC (XEN) HVM d14v0 save: LAPIC_REGS (XEN) HVM d14v1 save: LAPIC_REGS (XEN) HVM d14 save: PCI_IRQ (XEN) HVM d14 save: ISA_IRQ (XEN) HVM d14 save: PCI_LINK (XEN) HVM d14 save: PIT (XEN) HVM d14 save: RTC (XEN) HVM d14 save: HPET (XEN) HVM d14 save: PMTIMER (XEN) HVM d14v0 save: MTRR (XEN) HVM d14v1 save: MTRR (XEN) HVM d14 save: VIRIDIAN_DOMAIN (XEN) HVM d14v0 save: CPU_XSAVE (XEN) HVM d14v1 save: CPU_XSAVE (XEN) HVM d14v0 save: VIRIDIAN_VCPU (XEN) HVM d14v1 save: VIRIDIAN_VCPU (XEN) HVM d14v0 save: VMCE_VCPU (XEN) HVM d14v1 save: VMCE_VCPU (XEN) HVM d14v0 save: TSC_ADJUST (XEN) HVM d14v1 save: TSC_ADJUST (XEN) HVM d14v0 save: CPU_MSR (XEN) HVM d14v1 save: CPU_MSR (XEN) HVM14 restore: CPU 0 (XEN) common/memory.c:278:d0v1 Could not allocate order=3D0 extent: id=3D14= memflags=3D0xc0 (2798 of 4096) (XEN) AMD-Vi: Disable: device id =3D 0x300, domain =3D 2, paging mode =3D 3 (XEN) AMD-Vi: Re-assign 0000:03:00.0 from d2 to d[IO] (XEN) AMD-Vi: Disable: device id =3D 0x200, domain =3D 2, paging mode =3D 3 (XEN) AMD-Vi: Re-assign 0000:02:00.0 from d2 to d[IO] (XEN) AMD-Vi: Disable: device id =3D 0x400, domain =3D 2, paging mode =3D 3 (XEN) AMD-Vi: Re-assign 0000:04:00.0 from d2 to d[IO] (XEN) common/grant_table.c:3861:d0v3 Grant release 0x135 ref 0x1ca flags 0x= 12 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x134 ref 0x1c9 flags 0x= 12 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x133 ref 0x1c0 flags 0x= 12 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x132 ref 0x1bf flags 0x= 12 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x131 ref 0x1bc flags 0x= 12 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x130 ref 0x1bb flags 0x= 12 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x12f ref 0x20d flags 0x= 12 d8 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x12e ref 0x20c flags 0x= 12 d8 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x12d ref 0x417 flags 0x= 12 d10 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x12c ref 0x416 flags 0x= 12 d10 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x12b ref 0x413 flags 0x= 12 d9 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x12a ref 0x412 flags 0x= 12 d9 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x129 ref 0x413 flags 0x= 12 d7 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x128 ref 0x412 flags 0x= 12 d7 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x127 ref 0x210 flags 0x= 12 d4 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x126 ref 0x20f flags 0x= 12 d4 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x5c ref 0x1ce flags 0x1= 2 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x5b ref 0x1cd flags 0x1= 2 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x5a ref 0x1cc flags 0x1= 2 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x59 ref 0x1cb flags 0x1= 2 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x58 ref 0x1c8 flags 0x1= 2 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x57 ref 0x1c7 flags 0x1= 2 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x56 ref 0x1c6 flags 0x1= 2 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x55 ref 0x1c5 flags 0x1= 2 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x54 ref 0x1c4 flags 0x1= 2 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x53 ref 0x1c3 flags 0x1= 2 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x52 ref 0x1c2 flags 0x1= 2 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x51 ref 0x1c1 flags 0x1= 2 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x50 ref 0x1be flags 0x1= 2 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x4f ref 0x1bd flags 0x1= 2 d5 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x3b ref 0x415 flags 0x1= 2 d10 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x3a ref 0x414 flags 0x1= 2 d10 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x39 ref 0x411 flags 0x1= 2 d9 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x38 ref 0x410 flags 0x1= 2 d9 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x37 ref 0x20e flags 0x1= 2 d6 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x36 ref 0x20d flags 0x1= 2 d6 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x35 ref 0x20e flags 0x1= 2 d11 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x34 ref 0x20d flags 0x1= 2 d11 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x33 ref 0x411 flags 0x1= 2 d7 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x32 ref 0x410 flags 0x1= 2 d7 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x31 ref 0x20e flags 0x1= 2 d3 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x30 ref 0x20d flags 0x1= 2 d3 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x3 ref 0x40b flags 0x12= d0 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x2 ref 0x40a flags 0x12= d0 (XEN) common/grant_table.c:3861:d0v3 Grant release 0x1 ref 0x409 flags 0x12= d0 (XEN) common/grant_table.c:3861:d0v3 Grant release 0 ref 0x408 flags 0x12 d0 (XEN) cannot mask IRQ 95: masking MSI-X on Dom32753's 0000:03:00.0 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x400, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Re-assign 0000:04:00.0 from d[IO] to d0 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x200, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Re-assign 0000:02:00.0 from d[IO] to d0 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x300, type =3D 0x1, root= table =3D 0xfd5613000, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Re-assign 0000:03:00.0 from d[IO] to d0 ##### -> our domain orchestration tool has cleaned up and is starting the d= river domain again (XEN) AMD-Vi: Disable: device id =3D 0x300, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Re-assign 0000:03:00.0 from d0 to d[IO] (XEN) AMD-Vi: Disable: device id =3D 0x200, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Re-assign 0000:02:00.0 from d0 to d[IO] (XEN) AMD-Vi: Disable: device id =3D 0x400, domain =3D 0, paging mode =3D 3 (XEN) AMD-Vi: Re-assign 0000:04:00.0 from d0 to d[IO] (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x300, type =3D 0x1, root= table =3D 0x98330b000, domain =3D 15, paging mode =3D 3 (XEN) AMD-Vi: Re-assign 0000:03:00.0 from d[IO] to d15 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x200, type =3D 0x1, root= table =3D 0x98330b000, domain =3D 15, paging mode =3D 3 (XEN) AMD-Vi: Re-assign 0000:02:00.0 from d[IO] to d15 (XEN) AMD-Vi: Setup I/O page table: device id =3D 0x400, type =3D 0x1, root= table =3D 0x98330b000, domain =3D 15, paging mode =3D 3 (XEN) AMD-Vi: Re-assign 0000:04:00.0 from d[IO] to d15 --mynTevqUIMXVj7cQ Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="intel-enomem.txt" Content-Transfer-Encoding: 8bit (XEN) Xen version 4.18.4-pre (@) (gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0) debug=y Wed Nov 27 17:18:46 UTC 2024 (XEN) Latest ChangeSet: Fri Nov 15 14:07:55 2024 +0000 git:05ee7d9083-dirty (XEN) build-id: 0adefb2a5aa28a52782a7c8481ebd48539af86d0 (XEN) Bootloader: GRUB 2.06-2ubuntu14.4 (XEN) Command line: placeholder console=vga,com2 dom0_max_vcpus=4-8 dom0_mem=min:6144,max:65536m iommu=on,required,intpost,verbose,debug x2apic=off sched=credit2 flask=enforcing gnttab_max_frames=128 xpti=off smt=on cpufreq=xen:performance spec-ctrl=gds-mit=0 com2=115200,8n1 (XEN) Xen image load base address: 0x6f800000 (XEN) Video information: (XEN) VGA is graphics mode 1024x768, 32 bpp (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 2 EDD information structures (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 85 (0x55), Stepping 4 (raw 00050654) (XEN) EFI RAM map: (XEN) [0000000000000000, 000000000009ffff] (usable) (XEN) [00000000000a0000, 00000000000fffff] (reserved) (XEN) [0000000000100000, 00000000695bdfff] (usable) (XEN) [00000000695be000, 000000006be46fff] (reserved) (XEN) [000000006be47000, 000000006bf01fff] (ACPI data) (XEN) [000000006bf02000, 000000006ca0bfff] (ACPI NVS) (XEN) [000000006ca0c000, 000000006ed10fff] (reserved) (XEN) [000000006ed11000, 000000006fffffff] (usable) (XEN) [0000000070000000, 000000008fffffff] (reserved) (XEN) [00000000fd000000, 00000000fe7fffff] (reserved) (XEN) [00000000fed20000, 00000000fed44fff] (reserved) (XEN) [00000000ff000000, 00000000ffffffff] (reserved) (XEN) [0000000100000000, 000000107fffffff] (usable) (XEN) BSP microcode revision: 0x02007006 (XEN) ACPI: RSDP 6C663000, 0024 (r2 SUPERM) (XEN) ACPI: XSDT 6C6630C8, 0114 (r1 SUPERM SUPERM 1072009 AMI 10013) (XEN) ACPI: FACP 6C6A5D70, 0114 (r6 SUPERM SMCI--MB 1072009 INTL 20091013) (XEN) ACPI: DSDT 6C663278, 42AF5 (r2 SUPERM SMCI--MB 1072009 INTL 20091013) (XEN) ACPI: FACS 6CA0A080, 0040 (XEN) ACPI: FPDT 6C6A5E88, 0044 (r1 1072009 AMI 10013) (XEN) ACPI: FIDT 6C6A5ED0, 009C (r1 SUPERM SMCI--MB 1072009 AMI 10013) (XEN) ACPI: SPMI 6C6A5F70, 0041 (r5 SUPERM SMCI--MB 0 AMI. 0) (XEN) ACPI: UEFI 6C6A5FB8, 0048 (r1 SUPERM SMCI--MB 1072009 1000013) (XEN) ACPI: UEFI 6C6A6000, 005C (r1 INTEL RstUefiV 0 0) (XEN) ACPI: MCFG 6C6A6060, 003C (r1 SUPERM SMCI--MB 1072009 MSFT 97) (XEN) ACPI: HPET 6C6A60A0, 0038 (r1 SUPERM SMCI--MB 1 INTL 20091013) (XEN) ACPI: APIC 6C6A60D8, 071E (r3 SUPERM SMCI--MB 0 INTL 20091013) (XEN) ACPI: MIGT 6C6A67F8, 0040 (r1 SUPERM SMCI--MB 0 INTL 20091013) (XEN) ACPI: MSCT 6C6A6838, 004E (r1 SUPERM SMCI--MB 1 INTL 20091013) (XEN) ACPI: PCAT 6C6A6888, 0068 (r2 SUPERM SMCI--MB 2 INTL 20091013) (XEN) ACPI: PCCT 6C6A68F0, 006E (r1 SUPERM SMCI--MB 2 INTL 20091013) (XEN) ACPI: RASF 6C6A6960, 0030 (r1 SUPERM SMCI--MB 1 INTL 20091013) (XEN) ACPI: SLIT 6C6A6990, 002D (r1 SUPERM SMCI--MB 1 INTL 20091013) (XEN) ACPI: SRAT 6C6A69C0, 0A30 (r3 SUPERM SMCI--MB 2 INTL 20091013) (XEN) ACPI: SVOS 6C6A73F0, 0032 (r1 SUPERM SMCI--MB 0 INTL 20091013) (XEN) ACPI: WDDT 6C6A7428, 0040 (r1 SUPERM SMCI--MB 0 INTL 20091013) (XEN) ACPI: OEM4 6C6A7468, 28A0C (r2 INTEL CPU CST 3000 INTL 20140828) (XEN) ACPI: OEM1 6C6CFE78, A8CC (r2 INTEL CPU EIST 3000 INTL 20140828) (XEN) ACPI: SSDT 6C6DA748, CEB8 (r2 INTEL SSDT PM 4000 INTL 20140828) (XEN) ACPI: SSDT 6C6E7600, 065B (r2 SUPERM SMCI--MB 0 INTL 20091013) (XEN) ACPI: BGRT 6C6E7C60, 0038 (r1 SUPERM SMCI--MB 1072009 AMI 10013) (XEN) ACPI: SSDT 6C6E7C98, 1368 (r2 INTEL SpsNm 2 INTL 20140828) (XEN) ACPI: DMAR 6C6E9000, 0138 (r1 SUPERM SMCI--MB 1 INTL 20091013) (XEN) ACPI: HEST 6C6E9138, 00A8 (r1 SUPERM SMCI--MB 1 INTL 1) (XEN) ACPI: BERT 6C6E91E0, 0030 (r1 SUPERM SMCI--MB 1 INTL 1) (XEN) ACPI: ERST 6C6E9210, 0230 (r1 SUPERM SMCI--MB 1 INTL 1) (XEN) ACPI: EINJ 6C6E9440, 0150 (r1 SUPERM SMCI--MB 1 INTL 1) (XEN) ACPI: WSMT 6C6E9590, 0028 (r1 ên 1072009 AMI 10013) (XEN) System RAM: 65192MB (66756916kB) (XEN) NUMA: Node 0 PXM 0 [0000000000000000, 000000007fffffff] (XEN) NUMA: Node 0 PXM 0 [0000000100000000, 000000107fffffff] (XEN) NUMA: Using 52 for the hash shift (XEN) Domain heap initialised (XEN) vesafb: framebuffer at 0x00000000a9000000, mapped to 0xffff82c000201000, using 3072k, total 3072k (XEN) vesafb: mode is 1024x768x32, linelength=4096, font 8x14 (XEN) vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0 (XEN) SMBIOS 3.1 present. (XEN) XSM Framework v1.0.1 initialized (XEN) Policy len 0x3467, start at ffff83107fffc000. (XEN) Flask: 128 avtab hash slots, 458 rules. (XEN) Flask: 128 avtab hash slots, 458 rules. (XEN) Flask: 4 users, 3 roles, 46 types, 2 bools (XEN) Flask: 13 classes, 458 rules (XEN) Flask: Starting in enforcing mode. (XEN) [VT-D]Host address width 46 (XEN) [VT-D]found ACPI_DMAR_DRHD: (XEN) [VT-D] dmaru->address = c5ffc000 (XEN) [VT-D]drhd->address = c5ffc000 iommu->reg = ffff82c000506000 (XEN) [VT-D]cap = 8d2078c106f0466 ecap = f020df (XEN) [VT-D] IOAPIC: 0000:16:05.4 (XEN) [VT-D]found ACPI_DMAR_DRHD: (XEN) [VT-D] dmaru->address = e0ffc000 (XEN) [VT-D]drhd->address = e0ffc000 iommu->reg = ffff82c000508000 (XEN) [VT-D]cap = 8d2078c106f0466 ecap = f020df (XEN) [VT-D] IOAPIC: 0000:64:05.4 (XEN) [VT-D] bridge: 0000:64:03.0 start=64 sec=65 sub=65 (XEN) [VT-D]found ACPI_DMAR_DRHD: (XEN) [VT-D] dmaru->address = fbffc000 (XEN) [VT-D]drhd->address = fbffc000 iommu->reg = ffff82c00050a000 (XEN) [VT-D]cap = 8d2078c106f0466 ecap = f020df (XEN) [VT-D] IOAPIC: 0000:b2:05.4 (XEN) [VT-D] bridge: 0000:b2:00.0 start=b2 sec=b3 sub=b5 (XEN) [VT-D]found ACPI_DMAR_DRHD: (XEN) [VT-D] dmaru->address = aaffc000 (XEN) [VT-D]drhd->address = aaffc000 iommu->reg = ffff82c00050c000 (XEN) [VT-D]cap = 8d2078c106f0466 ecap = f020df (XEN) [VT-D] IOAPIC: 0000:f0:1f.0 (XEN) [VT-D] IOAPIC: 0000:00:05.4 (XEN) [VT-D] MSI HPET: 0000:00:1f.0 (XEN) [VT-D] flags: INCLUDE_ALL (XEN) [VT-D]found ACPI_DMAR_RMRR: (XEN) [VT-D] endpoint: 0000:00:14.0 (XEN) [VT-D]drivers/passthrough/vtd/dmar.c:614: RMRR: [6e7f3000,6e815fff] (XEN) [VT-D]found ACPI_DMAR_ATSR: (XEN) [VT-D] atsru->all_ports: 0 (XEN) [VT-D] bridge: 0000:64:03.0 start=64 sec=65 sub=65 (XEN) [VT-D] bridge: 0000:b2:00.0 start=b2 sec=b3 sub=b5 (XEN) [VT-D]found ACPI_DMAR_RHSA: (XEN) [VT-D] rhsau->address: aaffc000 rhsau->proximity_domain: 0 (XEN) [VT-D]found ACPI_DMAR_RHSA: (XEN) [VT-D] rhsau->address: c5ffc000 rhsau->proximity_domain: 0 (XEN) [VT-D]found ACPI_DMAR_RHSA: (XEN) [VT-D] rhsau->address: e0ffc000 rhsau->proximity_domain: 0 (XEN) [VT-D]found ACPI_DMAR_RHSA: (XEN) [VT-D] rhsau->address: fbffc000 rhsau->proximity_domain: 0 (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x508 (24 bits) (XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0] (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:504,1:0], pm1x_evt[1:500,1:0] (XEN) ACPI: 32/64X FACS address mismatch in FADT - 6ca0a080/0000000000000000, using 32 (XEN) ACPI: wakeup_vec[6ca0a08c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23 (XEN) ACPI: IOAPIC (id[0x09] address[0xfec01000] gsi_base[24]) (XEN) IOAPIC[1]: apic_id 9, version 32, address 0xfec01000, GSI 24-31 (XEN) ACPI: IOAPIC (id[0x0a] address[0xfec08000] gsi_base[32]) (XEN) IOAPIC[2]: apic_id 10, version 32, address 0xfec08000, GSI 32-39 (XEN) ACPI: IOAPIC (id[0x0b] address[0xfec10000] gsi_base[40]) (XEN) IOAPIC[3]: apic_id 11, version 32, address 0xfec10000, GSI 40-47 (XEN) ACPI: IOAPIC (id[0x0c] address[0xfec18000] gsi_base[48]) (XEN) IOAPIC[4]: apic_id 12, version 32, address 0xfec18000, GSI 48-55 (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) ACPI: IRQ0 used by override. (XEN) ACPI: IRQ2 used by override. (XEN) ACPI: IRQ9 used by override. (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000 (XEN) PCI: MCFG configuration 0: base 80000000 segment 0000 buses 00 - ff (XEN) PCI: MCFG area at 80000000 reserved in E820 (XEN) PCI: Using MCFG for segment 0000 bus 00-ff (XEN) Xen ERST support is initialized. (XEN) HEST: Table parsing has been initialized (XEN) ACPI: BGRT: invalidating v1 image at 0x62875018 (XEN) Using ACPI (MADT) for SMP configuration information (XEN) SMP: Allowing 8 CPUs (0 hotplug CPUs) (XEN) IRQ limits: 56 GSI, 1608 MSI/MSI-X (XEN) Not enabling x2APIC: disabled by cmdline. (XEN) CPU0: TSC: ratio: 176 / 2 (XEN) CPU0: bus: 100 MHz base: 2200 MHz max: 3000 MHz (XEN) CPU0: 1000 ... 2200 MHz (XEN) xstate: size: 0xa88 and states: 0x2ff (XEN) arch/x86/cpu/mcheck/mce_intel.c:776: MCA Capability: firstbank 0, extended MCE MSR 0, BCAST, SER, CMCI, LMCE (XEN) CMCI: threshold 0x2 too large for CPU0 bank 6, using 0x1 (XEN) CMCI: threshold 0x2 too large for CPU0 bank 9, using 0x1 (XEN) CMCI: threshold 0x2 too large for CPU0 bank 10, using 0x1 (XEN) CMCI: threshold 0x2 too large for CPU0 bank 11, using 0x1 (XEN) CPU0: Intel machine check reporting enabled (XEN) Speculative mitigation facilities: (XEN) Hardware hints: RSBA (XEN) Hardware features: IBPB IBRS STIBP SSBD L1D_FLUSH MD_CLEAR GDS_CTRL (XEN) Compiled-in support: INDIRECT_THUNK SHADOW_PAGING HARDEN_ARRAY HARDEN_BRANCH HARDEN_GUEST_ACCESS HARDEN_LOCK (XEN) Xen settings: BTI-Thunk: JMP, SPEC_CTRL: IBRS+ STIBP+ SSBD-, Other: IBPB-ctxt L1D_FLUSH VERW BRANCH_HARDEN (XEN) L1TF: believed vulnerable, maxphysaddr L1D 46, CPUID 46, Safe address 300000000000 (XEN) Support for HVM VMs: MSR_SPEC_CTRL MSR_VIRT_SPEC_CTRL RSB EAGER_FPU (XEN) Support for PV VMs: MSR_SPEC_CTRL EAGER_FPU VERW (XEN) XPTI (64-bit PV only): Dom0 disabled, DomU disabled (with PCID) (XEN) PV L1TF shadowing: Dom0 disabled, DomU enabled (XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2) (XEN) Initializing Credit2 scheduler (XEN) load_precision_shift: 18 (XEN) load_window_shift: 30 (XEN) underload_balance_tolerance: 0 (XEN) overload_balance_tolerance: -3 (XEN) runqueues arrangement: socket (XEN) cap enforcement granularity: 10ms (XEN) load tracking window length 1073741824 ns (XEN) Platform timer is 24.000MHz HPET (XEN) Detected 2194.844 MHz processor. (XEN) Freed 1020kB unused BSS memory (XEN) EFI memory map: (XEN) 0000000000000-0000000007fff type=3 attr=000000000000000f (XEN) 0000000008000-000000000ffff type=2 attr=000000000000000f (XEN) 0000000010000-000000002efff type=7 attr=000000000000000f (XEN) 000000002f000-000000003efff type=2 attr=000000000000000f (XEN) 000000003f000-000000003ffff type=4 attr=000000000000000f (XEN) 0000000040000-000000009ffff type=3 attr=000000000000000f (XEN) 0000000100000-0000009ce1fff type=2 attr=000000000000000f (XEN) 0000009ce2000-000004ededfff type=7 attr=000000000000000f (XEN) 000004edee000-000005b1cffff type=1 attr=000000000000000f (XEN) 000005b1d0000-000005b2cffff type=4 attr=000000000000000f (XEN) 000005b2d0000-000005b5adfff type=7 attr=000000000000000f (XEN) 000005b5ae000-000005b828fff type=1 attr=000000000000000f (XEN) 000005b829000-000005baa5fff type=2 attr=000000000000000f (XEN) 000005baa6000-000005baa7fff type=7 attr=000000000000000f (XEN) 000005baa8000-000005baa8fff type=2 attr=000000000000000f (XEN) 000005baa9000-000005bb7ffff type=1 attr=000000000000000f (XEN) 000005bb80000-0000067c43fff type=4 attr=000000000000000f (XEN) 0000067c44000-000006815bfff type=7 attr=000000000000000f (XEN) 000006815c000-00000695bdfff type=3 attr=000000000000000f (XEN) 00000695be000-000006be46fff type=0 attr=000000000000000f (XEN) 000006be47000-000006bf01fff type=9 attr=000000000000000f (XEN) 000006bf02000-000006ca0bfff type=10 attr=000000000000000f (XEN) 000006ca0c000-000006eb5dfff type=6 attr=800000000000000f (XEN) 000006eb5e000-000006ed10fff type=5 attr=800000000000000f (XEN) 000006ed11000-000006ee92fff type=4 attr=000000000000000f (XEN) 000006ee93000-000006eeb1fff type=3 attr=000000000000000f (XEN) 000006eeb2000-000006eee1fff type=4 attr=000000000000000f (XEN) 000006eee2000-000006eee7fff type=3 attr=000000000000000f (XEN) 000006eee8000-000006f0effff type=4 attr=000000000000000f (XEN) 000006f0f0000-000006f103fff type=3 attr=000000000000000f (XEN) 000006f104000-000006f128fff type=4 attr=000000000000000f (XEN) 000006f129000-000006f13ffff type=3 attr=000000000000000f (XEN) 000006f140000-000006f167fff type=4 attr=000000000000000f (XEN) 000006f168000-000006f19ffff type=3 attr=000000000000000f (XEN) 000006f1a0000-000006f1cbfff type=4 attr=000000000000000f (XEN) 000006f1cc000-000006f9fffff type=7 attr=000000000000000f (XEN) 000006fa00000-000006fe2afff type=2 attr=000000000000000f (XEN) 000006fe2b000-000006fffffff type=7 attr=000000000000000f (XEN) 0000100000000-000107fffffff type=7 attr=000000000000000f (XEN) 00000000a0000-00000000fffff type=0 attr=0000000000000000 (XEN) 0000070000000-000007fffffff type=0 attr=0000000000000000 (XEN) 0000080000000-000008fffffff type=11 attr=8000000000000001 (XEN) 00000fd000000-00000fe7fffff type=11 attr=800000000000100d (XEN) 00000fed20000-00000fed44fff type=11 attr=800000000000100d (XEN) 00000ff000000-00000ffffffff type=11 attr=800000000000100d (XEN) alt table ffff82d040489b58 -> ffff82d04049c58e (XEN) Intel VT-d iommu 2 supported page sizes: 4kB, 2MB, 1GB (XEN) Intel VT-d iommu 1 supported page sizes: 4kB, 2MB, 1GB (XEN) Intel VT-d iommu 0 supported page sizes: 4kB, 2MB, 1GB (XEN) Intel VT-d iommu 3 supported page sizes: 4kB, 2MB, 1GB (XEN) Intel VT-d Snoop Control enabled. (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) Intel VT-d Queued Invalidation enabled. (XEN) Intel VT-d Interrupt Remapping enabled. (XEN) Intel VT-d Posted Interrupt enabled. (XEN) Intel VT-d Shared EPT tables enabled. (XEN) [VT-D]drivers/passthrough/vtd/qinval.c:422: QI: using 256-entry ring(s) (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) Interrupt remapping enabled (XEN) nr_sockets: 1 (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) Enabling APIC mode. Using 5 I/O APICs (XEN) ENABLING IO-APIC IRQs (XEN) -> Using old ACK method (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) TSC deadline timer enabled (XEN) Allocated console ring of 64 KiB. (XEN) mwait-idle: MWAIT substates: 0x2020 (XEN) mwait-idle: v0.4.1 model 0x55 (XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Extended Page Tables (EPT) (XEN) - Virtual-Processor Identifiers (VPID) (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) - Unrestricted Guest (XEN) - APIC Register Virtualization (XEN) - Virtual Interrupt Delivery (XEN) - Posted Interrupt Processing (XEN) - VMCS shadowing (XEN) - VM Functions (XEN) - Virtualisation Exceptions (XEN) - Page Modification Logging (XEN) - TSC Scaling (XEN) HVM: ASIDs enabled. (XEN) VMX: Disabling executable EPT superpages due to CVE-2018-12207 (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB (XEN) alt table ffff82d040489b58 -> ffff82d04049c58e (XEN) Brought up 8 CPUs (XEN) Scheduling granularity: cpu, 1 CPU per sched-resource (XEN) Initializing Credit2 scheduler (XEN) load_precision_shift: 18 (XEN) load_window_shift: 30 (XEN) underload_balance_tolerance: 0 (XEN) overload_balance_tolerance: -3 (XEN) runqueues arrangement: socket (XEN) cap enforcement granularity: 10ms (XEN) load tracking window length 1073741824 ns (XEN) Adding cpu 0 to runqueue 0 (XEN) First cpu on runqueue, activating (XEN) Adding cpu 1 to runqueue 0 (XEN) Adding cpu 2 to runqueue 0 (XEN) Adding cpu 3 to runqueue 0 (XEN) Adding cpu 4 to runqueue 0 (XEN) Adding cpu 5 to runqueue 0 (XEN) Adding cpu 6 to runqueue 0 (XEN) Adding cpu 7 to runqueue 0 (XEN) mcheck_poll: Machine check polling timer started. (XEN) Running stub recovery selftests... (XEN) Fixup #UD[0000]: ffff82d07fffe044 [ffff82d07fffe044] -> ffff82d040389c71 (XEN) Fixup #GP[0000]: ffff82d07fffe045 [ffff82d07fffe045] -> ffff82d040389c71 (XEN) Fixup #SS[0000]: ffff82d07fffe044 [ffff82d07fffe044] -> ffff82d040389c71 (XEN) Fixup #BP[0000]: ffff82d07fffe045 [ffff82d07fffe045] -> ffff82d040389c71 (XEN) arch/x86/time.c:1290: CMOS aliased at 74, index r/w (XEN) NX (Execute Disable) protection active (XEN) d0 has maximum 1664 PIRQs (XEN) *** Building a PV Dom0 *** (XEN) Xen kernel: 64-bit, lsb (XEN) Dom0 kernel: 64-bit, lsb, paddr 0x1000000 -> 0x4800000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000001040000000->0000001048000000 (16387284 pages to be allocated) (XEN) Init. ramdisk: 000000107749f000->000000107fffba06 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff84800000 (XEN) Phys-Mach map: 0000008000000000->0000008007d8c188 (XEN) Start info: ffffffff84800000->ffffffff848004b8 (XEN) Page tables: ffffffff84801000->ffffffff8482a000 (XEN) Boot stack: ffffffff8482a000->ffffffff8482b000 (XEN) TOTAL: ffffffff80000000->ffffffff84c00000 (XEN) ENTRY ADDRESS: ffffffff838c48c0 (XEN) Dom0 has maximum 8 VCPUs (XEN) [VT-D]d0:Hostbridge: skip 0000:00:00.0 map (XEN) [VT-D]d0:PCIe: map 0000:00:04.0 (XEN) [VT-D]d0:PCIe: map 0000:00:04.1 (XEN) [VT-D]d0:PCIe: map 0000:00:04.2 (XEN) [VT-D]d0:PCIe: map 0000:00:04.3 (XEN) [VT-D]d0:PCIe: map 0000:00:04.4 (XEN) [VT-D]d0:PCIe: map 0000:00:04.5 (XEN) [VT-D]d0:PCIe: map 0000:00:04.6 (XEN) [VT-D]d0:PCIe: map 0000:00:04.7 (XEN) [VT-D]d0:PCIe: map 0000:00:05.0 (XEN) [VT-D]d0:PCIe: map 0000:00:05.2 (XEN) [VT-D]d0:PCIe: map 0000:00:05.4 (XEN) [VT-D]d0:PCIe: map 0000:00:08.0 (XEN) [VT-D]d0:PCI: map 0000:00:08.1 (XEN) [VT-D]d0:PCIe: map 0000:00:08.2 (XEN) [VT-D]d0:PCI: map 0000:00:11.0 (XEN) [VT-D]d0:PCI: map 0000:00:11.5 (XEN) [VT-D]d0:PCI: map 0000:00:14.0 (XEN) [VT-D]d0:PCI: map 0000:00:14.2 (XEN) [VT-D]d0:PCI: map 0000:00:16.0 (XEN) [VT-D]d0:PCI: map 0000:00:16.1 (XEN) [VT-D]d0:PCI: map 0000:00:16.4 (XEN) [VT-D]d0:PCI: map 0000:00:17.0 (XEN) [VT-D]d0:PCI: map 0000:00:1f.0 (XEN) [VT-D]d0:PCI: map 0000:00:1f.2 (XEN) [VT-D]d0:PCI: map 0000:00:1f.4 (XEN) [VT-D]d0:PCI: map 0000:00:1f.5 (XEN) [VT-D]d0:PCI: map 0000:03:00.0 (XEN) [VT-D]d0:PCIe: map 0000:16:05.0 (XEN) [VT-D]d0:PCIe: map 0000:16:05.2 (XEN) [VT-D]d0:PCIe: map 0000:16:05.4 (XEN) [VT-D]d0:PCI: map 0000:16:08.0 (XEN) [VT-D]d0:PCI: map 0000:16:08.1 (XEN) [VT-D]d0:PCI: map 0000:16:08.2 (XEN) [VT-D]d0:PCI: map 0000:16:08.3 (XEN) [VT-D]d0:PCI: map 0000:16:08.4 (XEN) [VT-D]d0:PCI: map 0000:16:08.5 (XEN) [VT-D]d0:PCI: map 0000:16:08.6 (XEN) [VT-D]d0:PCI: map 0000:16:08.7 (XEN) [VT-D]d0:PCI: map 0000:16:09.0 (XEN) [VT-D]d0:PCI: map 0000:16:09.1 (XEN) [VT-D]d0:PCI: map 0000:16:09.2 (XEN) [VT-D]d0:PCI: map 0000:16:09.3 (XEN) [VT-D]d0:PCI: map 0000:16:09.4 (XEN) [VT-D]d0:PCI: map 0000:16:09.5 (XEN) [VT-D]d0:PCI: map 0000:16:09.6 (XEN) [VT-D]d0:PCI: map 0000:16:09.7 (XEN) [VT-D]d0:PCI: map 0000:16:0a.0 (XEN) [VT-D]d0:PCI: map 0000:16:0a.1 (XEN) [VT-D]d0:PCI: map 0000:16:0e.0 (XEN) [VT-D]d0:PCI: map 0000:16:0e.1 (XEN) [VT-D]d0:PCI: map 0000:16:0e.2 (XEN) [VT-D]d0:PCI: map 0000:16:0e.3 (XEN) [VT-D]d0:PCI: map 0000:16:0e.4 (XEN) [VT-D]d0:PCI: map 0000:16:0e.5 (XEN) [VT-D]d0:PCI: map 0000:16:0e.6 (XEN) [VT-D]d0:PCI: map 0000:16:0e.7 (XEN) [VT-D]d0:PCI: map 0000:16:0f.0 (XEN) [VT-D]d0:PCI: map 0000:16:0f.1 (XEN) [VT-D]d0:PCI: map 0000:16:0f.2 (XEN) [VT-D]d0:PCI: map 0000:16:0f.3 (XEN) [VT-D]d0:PCI: map 0000:16:0f.4 (XEN) [VT-D]d0:PCI: map 0000:16:0f.5 (XEN) [VT-D]d0:PCI: map 0000:16:0f.6 (XEN) [VT-D]d0:PCI: map 0000:16:0f.7 (XEN) [VT-D]d0:PCI: map 0000:16:10.0 (XEN) [VT-D]d0:PCI: map 0000:16:10.1 (XEN) [VT-D]d0:PCI: map 0000:16:1d.0 (XEN) [VT-D]d0:PCI: map 0000:16:1d.1 (XEN) [VT-D]d0:PCI: map 0000:16:1d.2 (XEN) [VT-D]d0:PCI: map 0000:16:1d.3 (XEN) [VT-D]d0:PCI: map 0000:16:1e.0 (XEN) [VT-D]d0:PCI: map 0000:16:1e.1 (XEN) [VT-D]d0:PCI: map 0000:16:1e.2 (XEN) [VT-D]d0:PCI: map 0000:16:1e.3 (XEN) [VT-D]d0:PCI: map 0000:16:1e.4 (XEN) [VT-D]d0:PCI: map 0000:16:1e.5 (XEN) [VT-D]d0:PCI: map 0000:16:1e.6 (XEN) [VT-D]d0:PCIe: map 0000:64:05.0 (XEN) [VT-D]d0:PCIe: map 0000:64:05.2 (XEN) [VT-D]d0:PCIe: map 0000:64:05.4 (XEN) [VT-D]d0:PCIe: map 0000:64:08.0 (XEN) [VT-D]d0:PCIe: map 0000:64:09.0 (XEN) [VT-D]d0:PCIe: map 0000:64:0a.0 (XEN) [VT-D]d0:PCIe: map 0000:64:0a.1 (XEN) [VT-D]d0:PCIe: map 0000:64:0a.2 (XEN) [VT-D]d0:PCIe: map 0000:64:0a.3 (XEN) [VT-D]d0:PCIe: map 0000:64:0a.4 (XEN) [VT-D]d0:PCIe: map 0000:64:0a.5 (XEN) [VT-D]d0:PCIe: map 0000:64:0a.6 (XEN) [VT-D]d0:PCIe: map 0000:64:0a.7 (XEN) [VT-D]d0:PCIe: map 0000:64:0b.0 (XEN) [VT-D]d0:PCIe: map 0000:64:0b.1 (XEN) [VT-D]d0:PCIe: map 0000:64:0b.2 (XEN) [VT-D]d0:PCIe: map 0000:64:0b.3 (XEN) [VT-D]d0:PCIe: map 0000:64:0c.0 (XEN) [VT-D]d0:PCIe: map 0000:64:0c.1 (XEN) [VT-D]d0:PCIe: map 0000:64:0c.2 (XEN) [VT-D]d0:PCIe: map 0000:64:0c.3 (XEN) [VT-D]d0:PCIe: map 0000:64:0c.4 (XEN) [VT-D]d0:PCIe: map 0000:64:0c.5 (XEN) [VT-D]d0:PCIe: map 0000:64:0c.6 (XEN) [VT-D]d0:PCIe: map 0000:64:0c.7 (XEN) [VT-D]d0:PCIe: map 0000:64:0d.0 (XEN) [VT-D]d0:PCIe: map 0000:64:0d.1 (XEN) [VT-D]d0:PCIe: map 0000:64:0d.2 (XEN) [VT-D]d0:PCIe: map 0000:64:0d.3 (XEN) [VT-D]d0:PCIe: map 0000:65:00.0 (XEN) [VT-D]d0:PCIe: map 0000:65:00.1 (XEN) [VT-D]d0:PCIe: map 0000:65:00.2 (XEN) [VT-D]d0:PCIe: map 0000:65:00.3 (XEN) [VT-D]d0:PCIe: map 0000:b2:05.0 (XEN) [VT-D]d0:PCIe: map 0000:b2:05.2 (XEN) [VT-D]d0:PCIe: map 0000:b2:05.4 (XEN) [VT-D]d0:PCIe: map 0000:b2:12.0 (XEN) [VT-D]d0:PCI: map 0000:b2:12.1 (XEN) [VT-D]d0:PCI: map 0000:b2:12.2 (XEN) [VT-D]d0:PCI: map 0000:b2:15.0 (XEN) [VT-D]d0:PCI: map 0000:b2:16.0 (XEN) [VT-D]d0:PCI: map 0000:b2:16.4 (XEN) [VT-D]d0:PCI: map 0000:b2:17.0 (XEN) [VT-D]d0:PCIe: map 0000:b5:00.0 (XEN) [VT-D]d0:PCIe: map 0000:b5:00.1 (XEN) [VT-D]d0:PCIe: map 0000:b5:00.2 (XEN) [VT-D]d0:PCIe: map 0000:b5:00.3 (XEN) [VT-D]iommu_enable_translation: iommu->reg = ffff82c00050a000 (XEN) [VT-D]iommu_enable_translation: iommu->reg = ffff82c000508000 (XEN) [VT-D]iommu_enable_translation: iommu->reg = ffff82c000506000 (XEN) [VT-D]iommu_enable_translation: iommu->reg = ffff82c00050c000 (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Scrubbing Free RAM in background (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) (XEN) Freed 704kB init memory mapping kernel into physical memory about to get started... [ 0.000000] Linux version 6.8.0-48-generic (root@d834ac22c75d) (x86_64-linux-gnu-gcc-12 (Ubuntu 12.3.0-1ubuntu1~22.04) 12.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #48~22.04.1 SMP PREEMPT_DYNAMIC Thu Oct 24 08:09:57 UTC (Ubuntu 6.8.0-48.48~22.04.1-generic 6.8.12) [ 0.000000] Command line: console=hvc0 console=tty1 earlyprintk=xen xen-pciback.passthrough=1 oops=panic panic=15 root=/dev/loop0 ro rootfstype=ext4 zyimage=zvol:xvda1@ref9000000 zyoverlay pstore.backend=efi libata.fua=1 audit=1 nohz=off consoleblank=0 [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Hygon HygonGenuine [ 0.000000] Centaur CentaurHauls [ 0.000000] zhaoxin Shanghai [ 0.000000] Released 0 page(s) [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: [mem 0x0000000000000000-0x000000000007ffff] usable [ 0.000000] Xen: [mem 0x0000000000080000-0x00000000000fffff] reserved [ 0.000000] Xen: [mem 0x0000000000100000-0x00000000695bdfff] usable [ 0.000000] Xen: [mem 0x00000000695be000-0x000000006be46fff] reserved [ 0.000000] Xen: [mem 0x000000006be47000-0x000000006bf01fff] ACPI data [ 0.000000] Xen: [mem 0x000000006bf02000-0x000000006ca0bfff] ACPI NVS [ 0.000000] Xen: [mem 0x000000006ca0c000-0x000000006ed10fff] reserved [ 0.000000] Xen: [mem 0x000000006ed11000-0x000000006fffffff] usable [ 0.000000] Xen: [mem 0x0000000070000000-0x000000008fffffff] reserved [ 0.000000] Xen: [mem 0x00000000aaffc000-0x00000000aaffcfff] reserved [ 0.000000] Xen: [mem 0x00000000c5ffc000-0x00000000c5ffcfff] reserved [ 0.000000] Xen: [mem 0x00000000e0ffc000-0x00000000e0ffcfff] reserved [ 0.000000] Xen: [mem 0x00000000fbffc000-0x00000000fbffcfff] reserved [ 0.000000] Xen: [mem 0x00000000fd000000-0x00000000fe7fffff] reserved [ 0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec01fff] reserved [ 0.000000] Xen: [mem 0x00000000fec08000-0x00000000fec08fff] reserved [ 0.000000] Xen: [mem 0x00000000fec10000-0x00000000fec10fff] reserved [ 0.000000] Xen: [mem 0x00000000fec18000-0x00000000fec18fff] reserved [ 0.000000] Xen: [mem 0x00000000fed20000-0x00000000fed44fff] reserved [ 0.000000] Xen: [mem 0x00000000fee00000-0x00000000feefffff] reserved [ 0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved [ 0.000000] Xen: [mem 0x0000000100000000-0x000000107fffffff] usable [ 0.000000] printk: legacy bootconsole [xenboot0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] APIC: Static calls initialized [ 0.000000] efi: EFI v2.6 by American Megatrends [ 0.000000] efi: ACPI 2.0=0x6c663000 ACPI=0x6c663000 SMBIOS=0x6e7bb000 SMBIOS 3.0=0x6e7ba000 (MEMATTR=0x65964018 unusable) ESRT=0x6bf01018 MOKvar=0x6e7f2000 [ 0.000000] secureboot: Secure boot disabled [ 0.000000] SMBIOS 3.1.1 present. [ 0.000000] DMI: Supermicro SYS-5019D-FN8TP-5-NC041/X11SDV-4C-TP8F, BIOS 2.1 01/18/2024 [ 0.000000] Hypervisor detected: Xen PV [ 0.000490] tsc: Detected 2194.844 MHz processor [ 0.000891] last_pfn = 0x1080000 max_arch_pfn = 0x400000000 [ 0.000897] MTRR map: 5 entries (0 fixed + 5 variable; max 20), built from 10 variable MTRRs [ 0.000903] MTRRs set to read-only [ 0.000909] x86/PAT: Configuration [0-7]: WB WT UC- UC WC WP UC UC [ 0.000913] last_pfn = 0x70000 max_arch_pfn = 0x400000000 [ 0.000968] esrt: Reserving ESRT space from 0x000000006bf01018 to 0x000000006bf01050. [ 0.000975] Kernel/User page tables isolation: disabled on XEN PV. [ 2.971016] secureboot: Secure boot disabled [ 2.971090] RAMDISK: [mem 0x08000000-0x10b5cfff] [ 2.971102] ACPI: Early table checksum verification disabled [ 2.971115] ACPI: RSDP 0x000000006C663000 000024 (v02 SUPERM) [ 2.971129] ACPI: XSDT 0x000000006C6630C8 000114 (v01 SUPERM SUPERM 01072009 AMI 00010013) [ 2.971184] ACPI: FACP 0x000000006C6A5D70 000114 (v06 SUPERM SMCI--MB 01072009 INTL 20091013) [ 2.971253] ACPI: DSDT 0x000000006C663278 042AF5 (v02 SUPERM SMCI--MB 01072009 INTL 20091013) [ 2.971270] ACPI: FACS 0x000000006CA0A080 000040 [ 2.971286] ACPI: FPDT 0x000000006C6A5E88 000044 (v01 01072009 AMI 00010013) [ 2.971304] ACPI: FIDT 0x000000006C6A5ED0 00009C (v01 SUPERM SMCI--MB 01072009 AMI 00010013) [ 2.971321] ACPI: SPMI 0x000000006C6A5F70 000041 (v05 SUPERM SMCI--MB 00000000 AMI. 00000000) [ 2.971338] ACPI: UEFI 0x000000006C6A5FB8 000048 (v01 SUPERM SMCI--MB 01072009 01000013) [ 2.971355] ACPI: UEFI 0x000000006C6A6000 00005C (v01 INTEL RstUefiV 00000000 00000000) [ 2.971373] ACPI: MCFG 0x000000006C6A6060 00003C (v01 SUPERM SMCI--MB 01072009 MSFT 00000097) [ 2.971390] ACPI: HPET 0x000000006C6A60A0 000038 (v01 SUPERM SMCI--MB 00000001 INTL 20091013) [ 2.971407] ACPI: APIC 0x000000006C6A60D8 00071E (v03 SUPERM SMCI--MB 00000000 INTL 20091013) [ 2.971424] ACPI: MIGT 0x000000006C6A67F8 000040 (v01 SUPERM SMCI--MB 00000000 INTL 20091013) [ 2.971441] ACPI: MSCT 0x000000006C6A6838 00004E (v01 SUPERM SMCI--MB 00000001 INTL 20091013) [ 2.971459] ACPI: PCAT 0x000000006C6A6888 000068 (v02 SUPERM SMCI--MB 00000002 INTL 20091013) [ 2.971476] ACPI: PCCT 0x000000006C6A68F0 00006E (v01 SUPERM SMCI--MB 00000002 INTL 20091013) [ 2.971493] ACPI: RASF 0x000000006C6A6960 000030 (v01 SUPERM SMCI--MB 00000001 INTL 20091013) [ 2.971510] ACPI: SLIT 0x000000006C6A6990 00002D (v01 SUPERM SMCI--MB 00000001 INTL 20091013) [ 2.971527] ACPI: SRAT 0x000000006C6A69C0 000A30 (v03 SUPERM SMCI--MB 00000002 INTL 20091013) [ 2.971544] ACPI: SVOS 0x000000006C6A73F0 000032 (v01 SUPERM SMCI--MB 00000000 INTL 20091013) [ 2.971561] ACPI: WDDT 0x000000006C6A7428 000040 (v01 SUPERM SMCI--MB 00000000 INTL 20091013) [ 2.971578] ACPI: OEM4 0x000000006C6A7468 028A0C (v02 INTEL CPU CST 00003000 INTL 20140828) [ 2.971596] ACPI: OEM1 0x000000006C6CFE78 00A8CC (v02 INTEL CPU EIST 00003000 INTL 20140828) [ 2.971613] ACPI: SSDT 0x000000006C6DA748 00CEB8 (v02 INTEL SSDT PM 00004000 INTL 20140828) [ 2.971630] ACPI: SSDT 0x000000006C6E7600 00065B (v02 SUPERM SMCI--MB 00000000 INTL 20091013) [ 2.971647] ACPI: BGRT 0x000000006C6E7C60 000038 (v01 SUPERM SMCI--MB 01072009 AMI 00010013) [ 2.971664] ACPI: SSDT 0x000000006C6E7C98 001368 (v02 INTEL SpsNm 00000002 INTL 20140828) [ 2.971682] ACPI: RMAD 0x000000006C6E9000 000138 (v01 SUPERM SMCI--MB 00000001 INTL 20091013) [ 2.971699] ACPI: HEST 0x000000006C6E9138 0000A8 (v01 SUPERM SMCI--MB 00000001 INTL 00000001) [ 2.971716] ACPI: BERT 0x000000006C6E91E0 000030 (v01 SUPERM SMCI--MB 00000001 INTL 00000001) [ 2.971733] ACPI: ERST 0x000000006C6E9210 000230 (v01 SUPERM SMCI--MB 00000001 INTL 00000001) [ 2.971750] ACPI: EINJ 0x000000006C6E9440 000150 (v01 SUPERM SMCI--MB 00000001 INTL 00000001) [ 2.971767] ACPI: WSMT 0x000000006C6E9590 000028 (v01 ên 01072009 AMI 00010013) [ 2.971778] ACPI: Reserving FACP table memory at [mem 0x6c6a5d70-0x6c6a5e83] [ 2.971784] ACPI: Reserving DSDT table memory at [mem 0x6c663278-0x6c6a5d6c] [ 2.971787] ACPI: Reserving FACS table memory at [mem 0x6ca0a080-0x6ca0a0bf] [ 2.971791] ACPI: Reserving FPDT table memory at [mem 0x6c6a5e88-0x6c6a5ecb] [ 2.971795] ACPI: Reserving FIDT table memory at [mem 0x6c6a5ed0-0x6c6a5f6b] [ 2.971799] ACPI: Reserving SPMI table memory at [mem 0x6c6a5f70-0x6c6a5fb0] [ 2.971803] ACPI: Reserving UEFI table memory at [mem 0x6c6a5fb8-0x6c6a5fff] [ 2.971806] ACPI: Reserving UEFI table memory at [mem 0x6c6a6000-0x6c6a605b] [ 2.971810] ACPI: Reserving MCFG table memory at [mem 0x6c6a6060-0x6c6a609b] [ 2.971814] ACPI: Reserving HPET table memory at [mem 0x6c6a60a0-0x6c6a60d7] [ 2.971818] ACPI: Reserving APIC table memory at [mem 0x6c6a60d8-0x6c6a67f5] [ 2.971822] ACPI: Reserving MIGT table memory at [mem 0x6c6a67f8-0x6c6a6837] [ 2.971825] ACPI: Reserving MSCT table memory at [mem 0x6c6a6838-0x6c6a6885] [ 2.971829] ACPI: Reserving PCAT table memory at [mem 0x6c6a6888-0x6c6a68ef] [ 2.971833] ACPI: Reserving PCCT table memory at [mem 0x6c6a68f0-0x6c6a695d] [ 2.971837] ACPI: Reserving RASF table memory at [mem 0x6c6a6960-0x6c6a698f] [ 2.971841] ACPI: Reserving SLIT table memory at [mem 0x6c6a6990-0x6c6a69bc] [ 2.971844] ACPI: Reserving SRAT table memory at [mem 0x6c6a69c0-0x6c6a73ef] [ 2.971848] ACPI: Reserving SVOS table memory at [mem 0x6c6a73f0-0x6c6a7421] [ 2.971852] ACPI: Reserving WDDT table memory at [mem 0x6c6a7428-0x6c6a7467] [ 2.971856] ACPI: Reserving OEM4 table memory at [mem 0x6c6a7468-0x6c6cfe73] [ 2.971859] ACPI: Reserving OEM1 table memory at [mem 0x6c6cfe78-0x6c6da743] [ 2.971863] ACPI: Reserving SSDT table memory at [mem 0x6c6da748-0x6c6e75ff] [ 2.971867] ACPI: Reserving SSDT table memory at [mem 0x6c6e7600-0x6c6e7c5a] [ 2.971871] ACPI: Reserving BGRT table memory at [mem 0x6c6e7c60-0x6c6e7c97] [ 2.971875] ACPI: Reserving SSDT table memory at [mem 0x6c6e7c98-0x6c6e8fff] [ 2.971878] ACPI: Reserving RMAD table memory at [mem 0x6c6e9000-0x6c6e9137] [ 2.971882] ACPI: Reserving HEST table memory at [mem 0x6c6e9138-0x6c6e91df] [ 2.971886] ACPI: Reserving BERT table memory at [mem 0x6c6e91e0-0x6c6e920f] [ 2.971890] ACPI: Reserving ERST table memory at [mem 0x6c6e9210-0x6c6e943f] [ 2.971894] ACPI: Reserving EINJ table memory at [mem 0x6c6e9440-0x6c6e958f] [ 2.971897] ACPI: Reserving WSMT table memory at [mem 0x6c6e9590-0x6c6e95b7] [ 2.972011] APIC: Switched APIC routing to: Xen PV [ 2.972099] NUMA turned off [ 2.972102] Faking a node at [mem 0x0000000000000000-0x000000107fffffff] [ 2.972117] NODE_DATA(0) allocated [mem 0xfb1806000-0xfb1830fff] [ 2.973084] Section 501 and 502 (node 0) have a circular dependency on usemap and pgdat allocations [ 3.328882] Zone ranges: [ 3.328889] DMA [mem 0x0000000000001000-0x0000000000ffffff] [ 3.328895] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] [ 3.328957] Normal [mem 0x0000000100000000-0x000000107fffffff] [ 3.328965] Device empty [ 3.328969] Movable zone start for each node [ 3.328974] Early memory node ranges [ 3.328977] node 0: [mem 0x0000000000001000-0x000000000007ffff] [ 3.328982] node 0: [mem 0x0000000000100000-0x00000000695bdfff] [ 3.328987] node 0: [mem 0x000000006ed11000-0x000000006fffffff] [ 3.328990] node 0: [mem 0x0000000100000000-0x000000107fffffff] [ 3.329003] Initmem setup node 0 [mem 0x0000000000001000-0x000000107fffffff] [ 3.329013] On node 0, zone DMA: 1 pages in unavailable ranges [ 3.329042] On node 0, zone DMA: 128 pages in unavailable ranges [ 3.332019] On node 0, zone DMA32: 22355 pages in unavailable ranges [ 3.431745] p2m virtual area at (____ptrval____), size is 40000000 [ 4.989453] Remapped 612307 page(s) [ 4.990215] ACPI: PM-Timer IO Port: 0x508 [ 4.990413] ACPI: X2APIC_NMI (uid[0xffffffff] high level lint[0x1]) [ 4.990442] ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1]) [ 4.990498] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23 [ 4.990512] IOAPIC[1]: apic_id 9, version 32, address 0xfec01000, GSI 24-31 [ 4.990529] IOAPIC[2]: apic_id 10, version 32, address 0xfec08000, GSI 32-39 [ 4.990543] IOAPIC[3]: apic_id 11, version 32, address 0xfec10000, GSI 40-47 [ 4.990557] IOAPIC[4]: apic_id 12, version 32, address 0xfec18000, GSI 48-55 [ 4.990603] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 4.990609] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 4.990699] ACPI: Using ACPI (MADT) for SMP configuration information [ 4.990706] ACPI: HPET id: 0x8086a701 base: 0xfed00000 [ 4.996414] smpboot: Allowing 8 CPUs, 0 hotplug CPUs [ 4.996446] PM: hibernation: Registered nosave memory: [mem 0x00000000-0x00000fff] [ 4.996452] PM: hibernation: Registered nosave memory: [mem 0x00080000-0x000fffff] [ 4.996457] PM: hibernation: Registered nosave memory: [mem 0x695be000-0x6be46fff] [ 4.996461] PM: hibernation: Registered nosave memory: [mem 0x6be47000-0x6bf01fff] [ 4.996465] PM: hibernation: Registered nosave memory: [mem 0x6bf02000-0x6ca0bfff] [ 4.996469] PM: hibernation: Registered nosave memory: [mem 0x6ca0c000-0x6ed10fff] [ 4.996474] PM: hibernation: Registered nosave memory: [mem 0x70000000-0x8fffffff] [ 4.996477] PM: hibernation: Registered nosave memory: [mem 0x90000000-0xaaffbfff] [ 4.996481] PM: hibernation: Registered nosave memory: [mem 0xaaffc000-0xaaffcfff] [ 4.996485] PM: hibernation: Registered nosave memory: [mem 0xaaffd000-0xc5ffbfff] [ 4.996489] PM: hibernation: Registered nosave memory: [mem 0xc5ffc000-0xc5ffcfff] [ 4.996492] PM: hibernation: Registered nosave memory: [mem 0xc5ffd000-0xe0ffbfff] [ 4.996496] PM: hibernation: Registered nosave memory: [mem 0xe0ffc000-0xe0ffcfff] [ 4.996500] PM: hibernation: Registered nosave memory: [mem 0xe0ffd000-0xfbffbfff] [ 4.996503] PM: hibernation: Registered nosave memory: [mem 0xfbffc000-0xfbffcfff] [ 4.996507] PM: hibernation: Registered nosave memory: [mem 0xfbffd000-0xfcffffff] [ 4.996511] PM: hibernation: Registered nosave memory: [mem 0xfd000000-0xfe7fffff] [ 4.996515] PM: hibernation: Registered nosave memory: [mem 0xfe800000-0xfebfffff] [ 4.996518] PM: hibernation: Registered nosave memory: [mem 0xfec00000-0xfec01fff] [ 4.996522] PM: hibernation: Registered nosave memory: [mem 0xfec02000-0xfec07fff] [ 4.996526] PM: hibernation: Registered nosave memory: [mem 0xfec08000-0xfec08fff] [ 4.996530] PM: hibernation: Registered nosave memory: [mem 0xfec09000-0xfec0ffff] [ 4.996533] PM: hibernation: Registered nosave memory: [mem 0xfec10000-0xfec10fff] [ 4.996537] PM: hibernation: Registered nosave memory: [mem 0xfec11000-0xfec17fff] [ 4.996595] PM: hibernation: Registered nosave memory: [mem 0xfec18000-0xfec18fff] [ 4.996602] PM: hibernation: Registered nosave memory: [mem 0xfec19000-0xfed1ffff] [ 4.996605] PM: hibernation: Registered nosave memory: [mem 0xfed20000-0xfed44fff] [ 4.996609] PM: hibernation: Registered nosave memory: [mem 0xfed45000-0xfedfffff] [ 4.996613] PM: hibernation: Registered nosave memory: [mem 0xfee00000-0xfeefffff] [ 4.996617] PM: hibernation: Registered nosave memory: [mem 0xfef00000-0xfeffffff] [ 4.996620] PM: hibernation: Registered nosave memory: [mem 0xff000000-0xffffffff] [ 4.996625] [mem 0xaaffd000-0xc5ffbfff] available for PCI devices [ 4.996636] Booting kernel on Xen [ 4.996639] Xen version: 4.18.4-pre (preserve-AD) [ 4.996645] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns [ 4.996661] setup_percpu: NR_CPUS:8192 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1 [ 4.997254] percpu: Embedded 86 pages/cpu s229376 r8192 d114688 u524288 [ 4.997354] PV qspinlock hash table entries: 256 (order: 0, 4096 bytes, linear) [ 4.997360] Kernel command line: console=hvc0 console=tty1 earlyprintk=xen xen-pciback.passthrough=1 oops=panic panic=15 root=/dev/loop0 ro rootfstype=ext4 zyimage=zvol:xvda1@ref9000000 zyoverlay pstore.backend=efi libata.fua=1 audit=1 nohz=off consoleblank=0 [ 4.997562] audit: enabled (after initialization) [ 4.997588] Unknown kernel command line parameters "zyoverlay zyimage=zvol:xvda1@ref9000000", will be passed to user space. [ 4.997605] random: crng init done [ 5.003861] Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes, linear) [ 5.007013] Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes, linear) [ 5.007992] Fallback order for Node 0: 0 [ 5.007998] Built 1 zonelists, mobility grouping on. Total pages: 16428410 [ 5.008006] Policy zone: Normal [ 5.008017] mem auto-init: stack:all(zero), heap alloc:on, heap free:off [ 5.008023] software IO TLB: area num 8. [ 5.286869] Memory: 64152948K/66756784K available (22528K kernel code, 4438K rwdata, 13984K rodata, 4972K init, 4740K bss, 2603584K reserved, 0K cma-reserved) [ 5.289202] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 Poking KASLR using RDRAND RDTSC... [ 5.290452] ftrace: allocating 57924 entries in 227 pages [ 5.304210] ftrace: allocated 227 pages with 5 groups [ 5.305587] Dynamic Preempt: voluntary [ 5.305900] rcu: Preemptible hierarchical RCU implementation. [ 5.305904] rcu: RCU restricting CPUs from NR_CPUS=8192 to nr_cpu_ids=8. [ 5.305909] Trampoline variant of Tasks RCU enabled. [ 5.305912] Rude variant of Tasks RCU enabled. [ 5.305915] Tracing variant of Tasks RCU enabled. [ 5.305918] rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies. [ 5.305922] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8 [ 5.317939] NR_IRQS: 524544, nr_irqs: 1032, preallocated irqs: 16 [ 5.318172] xen:events: Using FIFO-based ABI [ 5.318321] rcu: srcu_init: Setting srcu_struct sizes based on contention. [ 5.318444] Console: colour dummy device 80x25 [ 5.318451] printk: legacy console [tty1] enabled [ 5.318458] printk: legacy bootconsole [xenboot0] disabled [ 0.000000] Linux version 6.8.0-48-generic (root@d834ac22c75d) (x86_64-linux-gnu-gcc-12 (Ubuntu 12.3.0-1ubuntu1~22.04) 12.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #48~22.04.1 SMP PREEMPT_DYNAMIC Thu Oct 24 08:09:57 UTC (Ubuntu 6.8.0-48.48~22.04.1-generic 6.8.12) [ 0.000000] Command line: console=hvc0 console=tty1 earlyprintk=xen xen-pciback.passthrough=1 oops=panic panic=15 root=/dev/loop0 ro rootfstype=ext4 zyimage=zvol:xvda1@ref9000000 zyoverlay pstore.backend=efi libata.fua=1 audit=1 nohz=off consoleblank=0 [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Hygon HygonGenuine [ 0.000000] Centaur CentaurHauls [ 0.000000] zhaoxin Shanghai [ 0.000000] Released 0 page(s) [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: [mem 0x0000000000000000-0x000000000007ffff] usable [ 0.000000] Xen: [mem 0x0000000000080000-0x00000000000fffff] reserved [ 0.000000] Xen: [mem 0x0000000000100000-0x00000000695bdfff] usable [ 0.000000] Xen: [mem 0x00000000695be000-0x000000006be46fff] reserved [ 0.000000] Xen: [mem 0x000000006be47000-0x000000006bf01fff] ACPI data [ 0.000000] Xen: [mem 0x000000006bf02000-0x000000006ca0bfff] ACPI NVS [ 0.000000] Xen: [mem 0x000000006ca0c000-0x000000006ed10fff] reserved [ 0.000000] Xen: [mem 0x000000006ed11000-0x000000006fffffff] usable [ 0.000000] Xen: [mem 0x0000000070000000-0x000000008fffffff] reserved [ 0.000000] Xen: [mem 0x00000000aaffc000-0x00000000aaffcfff] reserved [ 0.000000] Xen: [mem 0x00000000c5ffc000-0x00000000c5ffcfff] reserved [ 0.000000] Xen: [mem 0x00000000e0ffc000-0x00000000e0ffcfff] reserved [ 0.000000] Xen: [mem 0x00000000fbffc000-0x00000000fbffcfff] reserved [ 0.000000] Xen: [mem 0x00000000fd000000-0x00000000fe7fffff] reserved [ 0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec01fff] reserved [ 0.000000] Xen: [mem 0x00000000fec08000-0x00000000fec08fff] reserved [ 0.000000] Xen: [mem 0x00000000fec10000-0x00000000fec10fff] reserved [ 0.000000] Xen: [mem 0x00000000fec18000-0x00000000fec18fff] reserved [ 0.000000] Xen: [mem 0x00000000fed20000-0x00000000fed44fff] reserved [ 0.000000] Xen: [mem 0x00000000fee00000-0x00000000feefffff] reserved [ 0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved [ 0.000000] Xen: [mem 0x0000000100000000-0x000000107fffffff] usable [ 0.000000] printk: legacy bootconsole [xenboot0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] APIC: Static calls initialized [ 0.000000] efi: EFI v2.6 by American Megatrends [ 0.000000] efi: ACPI 2.0=0x6c663000 ACPI=0x6c663000 SMBIOS=0x6e7bb000 SMBIOS 3.0=0x6e7ba000 (MEMATTR=0x65964018 unusable) ESRT=0x6bf01018 MOKvar=0x6e7f2000 [ 0.000000] secureboot: Secure boot disabled [ 0.000000] SMBIOS 3.1.1 present. [ 0.000000] DMI: Supermicro SYS-5019D-FN8TP-5-NC041/X11SDV-4C-TP8F, BIOS 2.1 01/18/2024 [ 0.000000] Hypervisor detected: Xen PV [ 0.000490] tsc: Detected 2194.844 MHz processor [ 0.000891] last_pfn = 0x1080000 max_arch_pfn = 0x400000000 [ 0.000897] MTRR map: 5 entries (0 fixed + 5 variable; max 20), built from 10 variable MTRRs [ 0.000903] MTRRs set to read-only [ 0.000909] x86/PAT: Configuration [0-7]: WB WT UC- UC WC WP UC UC [ 0.000913] last_pfn = 0x70000 max_arch_pfn = 0x400000000 [ 0.000968] esrt: Reserving ESRT space from 0x000000006bf01018 to 0x000000006bf01050. [ 0.000975] Kernel/User page tables isolation: disabled on XEN PV. [ 2.971016] secureboot: Secure boot disabled [ 2.971090] RAMDISK: [mem 0x08000000-0x10b5cfff] [ 2.971102] ACPI: Early table checksum verification disabled [ 2.971115] ACPI: RSDP 0x000000006C663000 000024 (v02 SUPERM) [ 2.971129] ACPI: XSDT 0x000000006C6630C8 000114 (v01 SUPERM SUPERM 01072009 AMI 00010013) [ 2.971184] ACPI: FACP 0x000000006C6A5D70 000114 (v06 SUPERM SMCI--MB 01072009 INTL 20091013) [ 2.971253] ACPI: DSDT 0x000000006C663278 042AF5 (v02 SUPERM SMCI--MB 01072009 INTL 20091013) [ 2.971270] ACPI: FACS 0x000000006CA0A080 000040 [ 2.971286] ACPI: FPDT 0x000000006C6A5E88 000044 (v01 01072009 AMI 00010013) [ 2.971304] ACPI: FIDT 0x000000006C6A5ED0 00009C (v01 SUPERM SMCI--MB 01072009 AMI 00010013) [ 2.971321] ACPI: SPMI 0x000000006C6A5F70 000041 (v05 SUPERM SMCI--MB 00000000 AMI. 00000000) [ 2.971338] ACPI: UEFI 0x000000006C6A5FB8 000048 (v01 SUPERM SMCI--MB 01072009 01000013) [ 2.971355] ACPI: UEFI 0x000000006C6A6000 00005C (v01 INTEL RstUefiV 00000000 00000000) [ 2.971373] ACPI: MCFG 0x000000006C6A6060 00003C (v01 SUPERM SMCI--MB 01072009 MSFT 00000097) [ 2.971390] ACPI: HPET 0x000000006C6A60A0 000038 (v01 SUPERM SMCI--MB 00000001 INTL 20091013) [ 2.971407] ACPI: APIC 0x000000006C6A60D8 00071E (v03 SUPERM SMCI--MB 00000000 INTL 20091013) [ 2.971424] ACPI: MIGT 0x000000006C6A67F8 000040 (v01 SUPERM SMCI--MB 00000000 INTL 20091013) [ 2.971441] ACPI: MSCT 0x000000006C6A6838 00004E (v01 SUPERM SMCI--MB 00000001 INTL 20091013) [ 2.971459] ACPI: PCAT 0x000000006C6A6888 000068 (v02 SUPERM SMCI--MB 00000002 INTL 20091013) [ 2.971476] ACPI: PCCT 0x000000006C6A68F0 00006E (v01 SUPERM SMCI--MB 00000002 INTL 20091013) [ 2.971493] ACPI: RASF 0x000000006C6A6960 000030 (v01 SUPERM SMCI--MB 00000001 INTL 20091013) [ 2.971510] ACPI: SLIT 0x000000006C6A6990 00002D (v01 SUPERM SMCI--MB 00000001 INTL 20091013) [ 2.971527] ACPI: SRAT 0x000000006C6A69C0 000A30 (v03 SUPERM SMCI--MB 00000002 INTL 20091013) [ 2.971544] ACPI: SVOS 0x000000006C6A73F0 000032 (v01 SUPERM SMCI--MB 00000000 INTL 20091013) [ 2.971561] ACPI: WDDT 0x000000006C6A7428 000040 (v01 SUPERM SMCI--MB 00000000 INTL 20091013) [ 2.971578] ACPI: OEM4 0x000000006C6A7468 028A0C (v02 INTEL CPU CST 00003000 INTL 20140828) [ 2.971596] ACPI: OEM1 0x000000006C6CFE78 00A8CC (v02 INTEL CPU EIST 00003000 INTL 20140828) [ 2.971613] ACPI: SSDT 0x000000006C6DA748 00CEB8 (v02 INTEL SSDT PM 00004000 INTL 20140828) [ 2.971630] ACPI: SSDT 0x000000006C6E7600 00065B (v02 SUPERM SMCI--MB 00000000 INTL 20091013) [ 2.971647] ACPI: BGRT 0x000000006C6E7C60 000038 (v01 SUPERM SMCI--MB 01072009 AMI 00010013) [ 2.971664] ACPI: SSDT 0x000000006C6E7C98 001368 (v02 INTEL SpsNm 00000002 INTL 20140828) [ 2.971682] ACPI: RMAD 0x000000006C6E9000 000138 (v01 SUPERM SMCI--MB 00000001 INTL 20091013) [ 2.971699] ACPI: HEST 0x000000006C6E9138 0000A8 (v01 SUPERM SMCI--MB 00000001 INTL 00000001) [ 2.971716] ACPI: BERT 0x000000006C6E91E0 000030 (v01 SUPERM SMCI--MB 00000001 INTL 00000001) [ 2.971733] ACPI: ERST 0x000000006C6E9210 000230 (v01 SUPERM SMCI--MB 00000001 INTL 00000001) [ 2.971750] ACPI: EINJ 0x000000006C6E9440 000150 (v01 SUPERM SMCI--MB 00000001 INTL 00000001) [ 2.971767] ACPI: WSMT 0x000000006C6E9590 000028 (v01 ên 01072009 AMI 00010013) [ 2.971778] ACPI: Reserving FACP table memory at [mem 0x6c6a5d70-0x6c6a5e83] [ 2.971784] ACPI: Reserving DSDT table memory at [mem 0x6c663278-0x6c6a5d6c] [ 2.971787] ACPI: Reserving FACS table memory at [mem 0x6ca0a080-0x6ca0a0bf] [ 2.971791] ACPI: Reserving FPDT table memory at [mem 0x6c6a5e88-0x6c6a5ecb] [ 2.971795] ACPI: Reserving FIDT table memory at [mem 0x6c6a5ed0-0x6c6a5f6b] [ 2.971799] ACPI: Reserving SPMI table memory at [mem 0x6c6a5f70-0x6c6a5fb0] [ 2.971803] ACPI: Reserving UEFI table memory at [mem 0x6c6a5fb8-0x6c6a5fff] [ 2.971806] ACPI: Reserving UEFI table memory at [mem 0x6c6a6000-0x6c6a605b] [ 2.971810] ACPI: Reserving MCFG table memory at [mem 0x6c6a6060-0x6c6a609b] [ 2.971814] ACPI: Reserving HPET table memory at [mem 0x6c6a60a0-0x6c6a60d7] [ 2.971818] ACPI: Reserving APIC table memory at [mem 0x6c6a60d8-0x6c6a67f5] [ 2.971822] ACPI: Reserving MIGT table memory at [mem 0x6c6a67f8-0x6c6a6837] [ 2.971825] ACPI: Reserving MSCT table memory at [mem 0x6c6a6838-0x6c6a6885] [ 2.971829] ACPI: Reserving PCAT table memory at [mem 0x6c6a6888-0x6c6a68ef] [ 2.971833] ACPI: Reserving PCCT table memory at [mem 0x6c6a68f0-0x6c6a695d] [ 2.971837] ACPI: Reserving RASF table memory at [mem 0x6c6a6960-0x6c6a698f] [ 2.971841] ACPI: Reserving SLIT table memory at [mem 0x6c6a6990-0x6c6a69bc] [ 2.971844] ACPI: Reserving SRAT table memory at [mem 0x6c6a69c0-0x6c6a73ef] [ 2.971848] ACPI: Reserving SVOS table memory at [mem 0x6c6a73f0-0x6c6a7421] [ 2.971852] ACPI: Reserving WDDT table memory at [mem 0x6c6a7428-0x6c6a7467] [ 2.971856] ACPI: Reserving OEM4 table memory at [mem 0x6c6a7468-0x6c6cfe73] [ 2.971859] ACPI: Reserving OEM1 table memory at [mem 0x6c6cfe78-0x6c6da743] [ 2.971863] ACPI: Reserving SSDT table memory at [mem 0x6c6da748-0x6c6e75ff] [ 2.971867] ACPI: Reserving SSDT table memory at [mem 0x6c6e7600-0x6c6e7c5a] [ 2.971871] ACPI: Reserving BGRT table memory at [mem 0x6c6e7c60-0x6c6e7c97] [ 2.971875] ACPI: Reserving SSDT table memory at [mem 0x6c6e7c98-0x6c6e8fff] [ 2.971878] ACPI: Reserving RMAD table memory at [mem 0x6c6e9000-0x6c6e9137] [ 2.971882] ACPI: Reserving HEST table memory at [mem 0x6c6e9138-0x6c6e91df] [ 2.971886] ACPI: Reserving BERT table memory at [mem 0x6c6e91e0-0x6c6e920f] [ 2.971890] ACPI: Reserving ERST table memory at [mem 0x6c6e9210-0x6c6e943f] [ 2.971894] ACPI: Reserving EINJ table memory at [mem 0x6c6e9440-0x6c6e958f] [ 2.971897] ACPI: Reserving WSMT table memory at [mem 0x6c6e9590-0x6c6e95b7] [ 2.972011] APIC: Switched APIC routing to: Xen PV [ 2.972099] NUMA turned off [ 2.972102] Faking a node at [mem 0x0000000000000000-0x000000107fffffff] [ 2.972117] NODE_DATA(0) allocated [mem 0xfb1806000-0xfb1830fff] [ 2.973084] Section 501 and 502 (node 0) have a circular dependency on usemap and pgdat allocations [ 3.328882] Zone ranges: [ 3.328889] DMA [mem 0x0000000000001000-0x0000000000ffffff] [ 3.328895] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] [ 3.328957] Normal [mem 0x0000000100000000-0x000000107fffffff] [ 3.328965] Device empty [ 3.328969] Movable zone start for each node [ 3.328974] Early memory node ranges [ 3.328977] node 0: [mem 0x0000000000001000-0x000000000007ffff] [ 3.328982] node 0: [mem 0x0000000000100000-0x00000000695bdfff] [ 3.328987] node 0: [mem 0x000000006ed11000-0x000000006fffffff] [ 3.328990] node 0: [mem 0x0000000100000000-0x000000107fffffff] [ 3.329003] Initmem setup node 0 [mem 0x0000000000001000-0x000000107fffffff] [ 3.329013] On node 0, zone DMA: 1 pages in unavailable ranges [ 3.329042] On node 0, zone DMA: 128 pages in unavailable ranges [ 3.332019] On node 0, zone DMA32: 22355 pages in unavailable ranges [ 3.431745] p2m virtual area at (____ptrval____), size is 40000000 [ 4.989453] Remapped 612307 page(s) [ 4.990215] ACPI: PM-Timer IO Port: 0x508 [ 4.990413] ACPI: X2APIC_NMI (uid[0xffffffff] high level lint[0x1]) [ 4.990442] ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1]) [ 4.990498] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23 [ 4.990512] IOAPIC[1]: apic_id 9, version 32, address 0xfec01000, GSI 24-31 [ 4.990529] IOAPIC[2]: apic_id 10, version 32, address 0xfec08000, GSI 32-39 [ 4.990543] IOAPIC[3]: apic_id 11, version 32, address 0xfec10000, GSI 40-47 [ 4.990557] IOAPIC[4]: apic_id 12, version 32, address 0xfec18000, GSI 48-55 [ 4.990603] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 4.990609] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 4.990699] ACPI: Using ACPI (MADT) for SMP configuration information [ 4.990706] ACPI: HPET id: 0x8086a701 base: 0xfed00000 [ 4.996414] smpboot: Allowing 8 CPUs, 0 hotplug CPUs [ 4.996446] PM: hibernation: Registered nosave memory: [mem 0x00000000-0x00000fff] [ 4.996452] PM: hibernation: Registered nosave memory: [mem 0x00080000-0x000fffff] [ 4.996457] PM: hibernation: Registered nosave memory: [mem 0x695be000-0x6be46fff] [ 4.996461] PM: hibernation: Registered nosave memory: [mem 0x6be47000-0x6bf01fff] [ 4.996465] PM: hibernation: Registered nosave memory: [mem 0x6bf02000-0x6ca0bfff] [ 4.996469] PM: hibernation: Registered nosave memory: [mem 0x6ca0c000-0x6ed10fff] [ 4.996474] PM: hibernation: Registered nosave memory: [mem 0x70000000-0x8fffffff] [ 4.996477] PM: hibernation: Registered nosave memory: [mem 0x90000000-0xaaffbfff] [ 4.996481] PM: hibernation: Registered nosave memory: [mem 0xaaffc000-0xaaffcfff] [ 4.996485] PM: hibernation: Registered nosave memory: [mem 0xaaffd000-0xc5ffbfff] [ 4.996489] PM: hibernation: Registered nosave memory: [mem 0xc5ffc000-0xc5ffcfff] [ 4.996492] PM: hibernation: Registered nosave memory: [mem 0xc5ffd000-0xe0ffbfff] [ 4.996496] PM: hibernation: Registered nosave memory: [mem 0xe0ffc000-0xe0ffcfff] [ 4.996500] PM: hibernation: Registered nosave memory: [mem 0xe0ffd000-0xfbffbfff] [ 4.996503] PM: hibernation: Registered nosave memory: [mem 0xfbffc000-0xfbffcfff] [ 4.996507] PM: hibernation: Registered nosave memory: [mem 0xfbffd000-0xfcffffff] [ 4.996511] PM: hibernation: Registered nosave memory: [mem 0xfd000000-0xfe7fffff] [ 4.996515] PM: hibernation: Registered nosave memory: [mem 0xfe800000-0xfebfffff] [ 4.996518] PM: hibernation: Registered nosave memory: [mem 0xfec00000-0xfec01fff] [ 4.996522] PM: hibernation: Registered nosave memory: [mem 0xfec02000-0xfec07fff] [ 4.996526] PM: hibernation: Registered nosave memory: [mem 0xfec08000-0xfec08fff] [ 4.996530] PM: hibernation: Registered nosave memory: [mem 0xfec09000-0xfec0ffff] [ 4.996533] PM: hibernation: Registered nosave memory: [mem 0xfec10000-0xfec10fff] [ 4.996537] PM: hibernation: Registered nosave memory: [mem 0xfec11000-0xfec17fff] [ 4.996595] PM: hibernation: Registered nosave memory: [mem 0xfec18000-0xfec18fff] [ 4.996602] PM: hibernation: Registered nosave memory: [mem 0xfec19000-0xfed1ffff] [ 4.996605] PM: hibernation: Registered nosave memory: [mem 0xfed20000-0xfed44fff] [ 4.996609] PM: hibernation: Registered nosave memory: [mem 0xfed45000-0xfedfffff] [ 4.996613] PM: hibernation: Registered nosave memory: [mem 0xfee00000-0xfeefffff] [ 4.996617] PM: hibernation: Registered nosave memory: [mem 0xfef00000-0xfeffffff] [ 4.996620] PM: hibernation: Registered nosave memory: [mem 0xff000000-0xffffffff] [ 4.996625] [mem 0xaaffd000-0xc5ffbfff] available for PCI devices [ 4.996636] Booting kernel on Xen [ 4.996639] Xen version: 4.18.4-pre (preserve-AD) [ 4.996645] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns [ 4.996661] setup_percpu: NR_CPUS:8192 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1 [ 4.997254] percpu: Embedded 86 pages/cpu s229376 r8192 d114688 u524288 [ 4.997354] PV qspinlock hash table entries: 256 (order: 0, 4096 bytes, linear) [ 4.997360] Kernel command line: console=hvc0 console=tty1 earlyprintk=xen xen-pciback.passthrough=1 oops=panic panic=15 root=/dev/loop0 ro rootfstype=ext4 zyimage=zvol:xvda1@ref9000000 zyoverlay pstore.backend=efi libata.fua=1 audit=1 nohz=off consoleblank=0 [ 4.997562] audit: enabled (after initialization) [ 4.997588] Unknown kernel command line parameters "zyoverlay zyimage=zvol:xvda1@ref9000000", will be passed to user space. [ 4.997605] random: crng init done [ 5.003861] Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes, linear) [ 5.007013] Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes, linear) [ 5.007992] Fallback order for Node 0: 0 [ 5.007998] Built 1 zonelists, mobility grouping on. Total pages: 16428410 [ 5.008006] Policy zone: Normal [ 5.008017] mem auto-init: stack:all(zero), heap alloc:on, heap free:off [ 5.008023] software IO TLB: area num 8. [ 5.286869] Memory: 64152948K/66756784K available (22528K kernel code, 4438K rwdata, 13984K rodata, 4972K init, 4740K bss, 2603584K reserved, 0K cma-reserved) [ 5.289202] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 [ 5.290452] ftrace: allocating 57924 entries in 227 pages [ 5.304210] ftrace: allocated 227 pages with 5 groups [ 5.305587] Dynamic Preempt: voluntary [ 5.305900] rcu: Preemptible hierarchical RCU implementation. [ 5.305904] rcu: RCU restricting CPUs from NR_CPUS=8192 to nr_cpu_ids=8. [ 5.305909] Trampoline variant of Tasks RCU enabled. [ 5.305912] Rude variant of Tasks RCU enabled. [ 5.305915] Tracing variant of Tasks RCU enabled. [ 5.305918] rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies. [ 5.305922] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8 [ 5.317939] NR_IRQS: 524544, nr_irqs: 1032, preallocated irqs: 16 [ 5.318172] xen:events: Using FIFO-based ABI [ 5.318321] rcu: srcu_init: Setting srcu_struct sizes based on contention. [ 5.318444] Console: colour dummy device 80x25 [ 5.318451] printk: legacy console [tty1] enabled [ 5.318458] printk: legacy bootconsole [xenboot0] disabled [ 5.318467] printk: legacy console [hvc0] enabled [ 5.320045] ACPI: Core revision 20230628 [ 5.372962] ACPI BIOS Warning (bug): Incorrect checksum in table [BGRT] - 0x18, should be 0xFFFFFFAE (20230628/utcksum-58) [ 5.373735] clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [ 5.373759] installing Xen timer for CPU 0 [ 5.373807] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x1fa32c1de86, max_idle_ns: 440795251159 ns [ 5.373826] Calibrating delay loop (skipped), value calculated using timer frequency.. 4389.68 BogoMIPS (lpj=2194844) [ 5.373997] Last level iTLB entries: 4KB 64, 2MB 8, 4MB 8 [ 5.374007] Last level dTLB entries: 4KB 64, 2MB 0, 4MB 0, 1GB 4 [ 5.374024] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization [ 5.374041] Spectre V2 : Spectre BHI mitigation: SW BHB clearing on vm exit [ 5.374053] Spectre V2 : Spectre BHI mitigation: SW BHB clearing on syscall [ 5.374065] Spectre V2 : Mitigation: IBRS [ 5.374074] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch [ 5.374088] Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT [ 5.374100] RETBleed: Mitigation: IBRS [ 5.374110] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier [ 5.374126] Spectre V2 : User space: Mitigation: STIBP via prctl [ 5.374140] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl [ 5.374164] MDS: Mitigation: Clear CPU buffers [ 5.374174] TAA: Mitigation: Clear CPU buffers [ 5.374184] MMIO Stale Data: Vulnerable: Clear CPU buffers attempted, no microcode [ 5.374198] GDS: Unknown: Dependent on hypervisor status [ 5.374235] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [ 5.374250] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [ 5.374262] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [ 5.374275] x86/fpu: Supporting XSAVE feature 0x020: 'AVX-512 opmask' [ 5.374287] x86/fpu: Supporting XSAVE feature 0x040: 'AVX-512 Hi256' [ 5.374299] x86/fpu: Supporting XSAVE feature 0x080: 'AVX-512 ZMM_Hi256' [ 5.374312] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [ 5.374325] x86/fpu: xstate_offset[5]: 832, xstate_sizes[5]: 64 [ 5.374337] x86/fpu: xstate_offset[6]: 896, xstate_sizes[6]: 512 [ 5.374350] x86/fpu: xstate_offset[7]: 1408, xstate_sizes[7]: 1024 [ 5.374362] x86/fpu: Enabled xstate features 0xe7, context size is 2432 bytes, using 'compacted' format. [ 5.427064] Freeing SMP alternatives memory: 48K [ 5.427082] pid_max: default: 32768 minimum: 301 [ 5.427193] LSM: initializing lsm=lockdown,capability,landlock,yama,apparmor,integrity [ 5.427239] landlock: Up and running. [ 5.427247] Yama: becoming mindful. [ 5.427315] AppArmor: AppArmor initialized [ 5.427468] Mount-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) [ 5.427574] Mountpoint-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) [ 5.428316] cpu 0 spinlock event irq 57 [ 5.428335] VPMU disabled by hypervisor. [ 5.428835] RCU Tasks: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1. [ 5.428891] RCU Tasks Rude: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1. [ 5.428946] RCU Tasks Trace: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1. [ 5.429047] Performance Events: unsupported p6 CPU model 85 no PMU driver, software events only. [ 5.429067] signal: max sigframe size: 3632 [ 5.429156] rcu: Hierarchical SRCU implementation. [ 5.429167] rcu: Max phase no-delay instances is 400. [ 5.436375] NMI watchdog: Perf NMI watchdog permanently disabled [ 5.436603] smp: Bringing up secondary CPUs ... [ 5.436939] installing Xen timer for CPU 1 [ 5.437365] installing Xen timer for CPU 2 [ 5.437764] installing Xen timer for CPU 3 [ 5.438160] installing Xen timer for CPU 4 [ 5.438536] installing Xen timer for CPU 5 [ 5.438937] installing Xen timer for CPU 6 [ 5.439360] installing Xen timer for CPU 7 [ 5.439480] cpu 1 spinlock event irq 97 [ 5.439983] MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details. [ 5.440009] TAA CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/tsx_async_abort.html for more details. [ 5.440034] MMIO Stale Data CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/processor_mmio_stale_data.html for more details. [ 5.440919] cpu 2 spinlock event irq 98 [ 5.440937] cpu 3 spinlock event irq 99 [ 5.441897] cpu 4 spinlock event irq 100 [ 5.441913] cpu 5 spinlock event irq 101 [ 5.441913] cpu 6 spinlock event irq 102 [ 5.441915] cpu 7 spinlock event irq 103 [ 5.443007] smp: Brought up 1 node, 8 CPUs [ 5.443021] smpboot: Max logical packages: 1 [ 5.446832] devtmpfs: initialized [ 5.446902] x86/mm: Memory block size: 2048MB [ 5.448277] ACPI: PM: Registering ACPI NVS region [mem 0x6bf02000-0x6ca0bfff] (11575296 bytes) [ 5.448277] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns [ 5.448300] futex hash table entries: 2048 (order: 5, 131072 bytes, linear) [ 5.448920] pinctrl core: initialized pinctrl subsystem [ 5.449127] PM: RTC time: 14:28:18, date: 2024-12-02 [ 5.451890] NET: Registered PF_NETLINK/PF_ROUTE protocol family [ 5.451938] xen:grant_table: Grant tables using version 1 layout [ 5.451979] Grant table initialized [ 5.452797] DMA: preallocated 4096 KiB GFP_KERNEL pool for atomic allocations [ 5.453506] DMA: preallocated 4096 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations [ 5.453869] DMA: preallocated 4096 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations [ 5.453912] audit: initializing netlink subsys (enabled) [ 5.453949] audit: type=2000 audit(1733149697.639:1): state=initialized audit_enabled=1 res=1 [ 5.453973] thermal_sys: Registered thermal governor 'fair_share' [ 5.453973] thermal_sys: Registered thermal governor 'bang_bang' [ 5.453981] thermal_sys: Registered thermal governor 'step_wise' [ 5.453993] thermal_sys: Registered thermal governor 'user_space' [ 5.454004] thermal_sys: Registered thermal governor 'power_allocator' [ 5.454024] EISA bus registered [ 5.454079] Detected 1 PCC Subspaces [ 5.454087] Registering PCC driver as Mailbox controller [ 5.454263] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it [ 5.454278] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 5.455114] PCI: ECAM [mem 0x80000000-0x8fffffff] (base 0x80000000) for domain 0000 [bus 00-ff] (XEN) d0: Forcing write emulation on MFNs 80000-8ffff [ 5.556707] PCI: Using configuration type 1 for base access [ 5.557360] kprobes: kprobe jump-optimization is enabled. All kprobes are optimized if possible. [ 5.558845] fbcon: Taking over console [ 5.558934] ACPI: Added _OSI(Module Device) [ 5.558944] ACPI: Added _OSI(Processor Device) [ 5.558954] ACPI: Added _OSI(3.0 _SCP Extensions) [ 5.558964] ACPI: Added _OSI(Processor Aggregator Device) [ 5.691303] ACPI: 4 ACPI AML tables successfully acquired and loaded [ 5.698536] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored [ 5.711068] ACPI: Dynamic OEM Table Load: [ 5.733243] ACPI: Dynamic OEM Table Load: [ 5.814951] ACPI: _OSC evaluated successfully for all CPUs [ 5.816015] ACPI: Interpreter enabled [ 5.816054] ACPI: PM: (supports S0 S4 S5) [ 5.816064] ACPI: Using IOAPIC for interrupt routing [ 5.824611] HEST: Table parsing has been initialized. [ 5.824863] GHES: APEI firmware first mode is enabled by APEI bit and WHEA _OSC. [ 5.824894] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 5.824916] PCI: Ignoring E820 reservations for host bridge windows [ 5.826371] ACPI: Enabled 6 GPEs in block 00 to 7F [ 5.899650] ACPI: PCI Root Bridge [PC00] (domain 0000 [bus 00-15]) [ 5.899675] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3] [ 5.899844] acpi PNP0A08:00: _OSC: platform does not support [SHPCHotplug AER LTR DPC] [ 5.900123] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME PCIeCapability] [ 5.900139] acpi PNP0A08:00: FADT indicates ASPM is unsupported, using BIOS configuration [ 5.902195] PCI host bridge to bus 0000:00 [ 5.902206] pci_bus 0000:00: root bus resource [io 0x0000-0x03af window] [ 5.902220] pci_bus 0000:00: root bus resource [io 0x03e0-0x0cf7 window] [ 5.902233] pci_bus 0000:00: root bus resource [io 0x03b0-0x03bb window] [ 5.902245] pci_bus 0000:00: root bus resource [io 0x03c0-0x03df window] [ 5.902258] pci_bus 0000:00: root bus resource [io 0x1000-0x3fff window] [ 5.902270] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] [ 5.902284] pci_bus 0000:00: root bus resource [mem 0x000c4000-0x000c7fff window] [ 5.902298] pci_bus 0000:00: root bus resource [mem 0xfe010000-0xfe010fff window] [ 5.902312] pci_bus 0000:00: root bus resource [mem 0x90000000-0xaaffffff window] [ 5.902326] pci_bus 0000:00: root bus resource [mem 0x380000000000-0x383fffffffff window] [ 5.902341] pci_bus 0000:00: root bus resource [bus 00-15] [ 5.902426] pci 0000:00:00.0: [8086:2020] type 00 class 0x060000 PCIe Root Port (XEN) PCI add device 0000:00:00.0 [ 5.903895] pci 0000:00:04.0: [8086:2021] type 00 class 0x088000 PCIe Root Complex Integrated Endpoint [ 5.903984] pci 0000:00:04.0: BAR 0 [mem 0x383ffff1c000-0x383ffff1ffff 64bit] (XEN) PCI add device 0000:00:04.0 [ 5.904452] pci 0000:00:04.1: [8086:2021] type 00 class 0x088000 PCIe Root Complex Integrated Endpoint [ 5.904539] pci 0000:00:04.1: BAR 0 [mem 0x383ffff18000-0x383ffff1bfff 64bit] (XEN) PCI add device 0000:00:04.1 [ 5.905046] pci 0000:00:04.2: [8086:2021] type 00 class 0x088000 PCIe Root Complex Integrated Endpoint [ 5.905133] pci 0000:00:04.2: BAR 0 [mem 0x383ffff14000-0x383ffff17fff 64bit] (XEN) PCI add device 0000:00:04.2 [ 5.905593] pci 0000:00:04.3: [8086:2021] type 00 class 0x088000 PCIe Root Complex Integrated Endpoint [ 5.905679] pci 0000:00:04.3: BAR 0 [mem 0x383ffff10000-0x383ffff13fff 64bit] (XEN) PCI add device 0000:00:04.3 [ 5.906160] pci 0000:00:04.4: [8086:2021] type 00 class 0x088000 PCIe Root Complex Integrated Endpoint [ 5.906272] pci 0000:00:04.4: BAR 0 [mem 0x383ffff0c000-0x383ffff0ffff 64bit] (XEN) PCI add device 0000:00:04.4 [ 5.906731] pci 0000:00:04.5: [8086:2021] type 00 class 0x088000 PCIe Root Complex Integrated Endpoint [ 5.906817] pci 0000:00:04.5: BAR 0 [mem 0x383ffff08000-0x383ffff0bfff 64bit] (XEN) PCI add device 0000:00:04.5 [ 5.907281] pci 0000:00:04.6: [8086:2021] type 00 class 0x088000 PCIe Root Complex Integrated Endpoint [ 5.907368] pci 0000:00:04.6: BAR 0 [mem 0x383ffff04000-0x383ffff07fff 64bit] (XEN) PCI add device 0000:00:04.6 [ 5.907884] pci 0000:00:04.7: [8086:2021] type 00 class 0x088000 PCIe Root Complex Integrated Endpoint [ 5.907970] pci 0000:00:04.7: BAR 0 [mem 0x383ffff00000-0x383ffff03fff 64bit] (XEN) PCI add device 0000:00:04.7 [ 5.908421] pci 0000:00:05.0: [8086:2024] type 00 class 0x088000 PCIe Root Complex Integrated Endpoint (XEN) PCI add device 0000:00:05.0 [ 5.908849] pci 0000:00:05.2: [8086:2025] type 00 class 0x088000 PCIe Root Complex Integrated Endpoint (XEN) PCI add device 0000:00:05.2 [ 5.909329] pci 0000:00:05.4: [8086:2026] type 00 class 0x080020 PCIe Root Complex Integrated Endpoint [ 5.909405] pci 0000:00:05.4: BAR 0 [mem 0xaa21a000-0xaa21afff] (XEN) PCI add device 0000:00:05.4 [ 5.910522] pci 0000:00:08.0: [8086:2014] type 00 class 0x088000 PCIe Root Complex Integrated Endpoint (XEN) PCI add device 0000:00:08.0 [ 5.910952] pci 0000:00:08.1: [8086:2015] type 00 class 0x110100 conventional PCI endpoint (XEN) PCI add device 0000:00:08.1 [ 5.911272] pci 0000:00:08.2: [8086:2016] type 00 class 0x088000 PCIe Root Complex Integrated Endpoint (XEN) PCI add device 0000:00:08.2 [ 5.914094] pci 0000:00:11.0: [8086:a1ec] type 00 class 0xff0000 conventional PCI endpoint (XEN) PCI add device 0000:00:11.0 [ 5.914514] pci 0000:00:11.5: [8086:a1d2] type 00 class 0x010601 conventional PCI endpoint [ 5.914598] pci 0000:00:11.5: BAR 0 [mem 0xaa216000-0xaa217fff] [ 5.914648] pci 0000:00:11.5: BAR 1 [mem 0xaa219000-0xaa2190ff] [ 5.914698] pci 0000:00:11.5: BAR 2 [io 0x3070-0x3077] [ 5.914746] pci 0000:00:11.5: BAR 3 [io 0x3060-0x3063] [ 5.914795] pci 0000:00:11.5: BAR 4 [io 0x3020-0x303f] [ 5.914846] pci 0000:00:11.5: BAR 5 [mem 0xaa180000-0xaa1fffff] [ 5.915048] pci 0000:00:11.5: PME# supported from D3hot (XEN) PCI add device 0000:00:11.5 [ 5.916341] pci 0000:00:14.0: [8086:a1af] type 00 class 0x0c0330 conventional PCI endpoint [ 5.916447] pci 0000:00:14.0: BAR 0 [mem 0xaa200000-0xaa20ffff 64bit] [ 5.916771] pci 0000:00:14.0: PME# supported from D3hot D3cold (XEN) PCI add device 0000:00:14.0 [ 5.917480] pci 0000:00:14.2: [8086:a1b1] type 00 class 0x118000 conventional PCI endpoint [ 5.917587] pci 0000:00:14.2: BAR 0 [mem 0x383ffff23000-0x383ffff23fff 64bit] (XEN) PCI add device 0000:00:14.2 [ 5.918408] pci 0000:00:16.0: [8086:a1ba] type 00 class 0x078000 conventional PCI endpoint [ 5.918525] pci 0000:00:16.0: BAR 0 [mem 0x383ffff22000-0x383ffff22fff 64bit] [ 5.918925] pci 0000:00:16.0: PME# supported from D3hot (XEN) PCI add device 0000:00:16.0 [ 5.919149] pci 0000:00:16.1: [8086:a1bb] type 00 class 0x078000 conventional PCI endpoint [ 5.919259] pci 0000:00:16.1: BAR 0 [mem 0x383ffff21000-0x383ffff21fff 64bit] [ 5.919603] pci 0000:00:16.1: PME# supported from D3hot (XEN) PCI add device 0000:00:16.1 [ 5.919834] pci 0000:00:16.4: [8086:a1be] type 00 class 0x078000 conventional PCI endpoint [ 5.920002] pci 0000:00:16.4: BAR 0 [mem 0x383ffff20000-0x383ffff20fff 64bit] [ 5.920346] pci 0000:00:16.4: PME# supported from D3hot (XEN) PCI add device 0000:00:16.4 [ 5.920590] pci 0000:00:17.0: [8086:a182] type 00 class 0x010601 conventional PCI endpoint [ 5.920673] pci 0000:00:17.0: BAR 0 [mem 0xaa214000-0xaa215fff] [ 5.920723] pci 0000:00:17.0: BAR 1 [mem 0xaa218000-0xaa2180ff] [ 5.920773] pci 0000:00:17.0: BAR 2 [io 0x3050-0x3057] [ 5.920821] pci 0000:00:17.0: BAR 3 [io 0x3040-0x3043] [ 5.920872] pci 0000:00:17.0: BAR 4 [io 0x3000-0x301f] [ 5.920920] pci 0000:00:17.0: BAR 5 [mem 0xaa100000-0xaa17ffff] [ 5.921122] pci 0000:00:17.0: PME# supported from D3hot (XEN) PCI add device 0000:00:17.0 [ 5.922991] pci 0000:00:1c.0: [8086:a190] type 01 class 0x060400 PCIe Root Port [ 5.923150] pci 0000:00:1c.0: PCI bridge to [bus 01] [ 5.923439] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold (XEN) PCI add device 0000:00:1c.0 [ 5.924884] pci 0000:00:1c.4: [8086:a194] type 01 class 0x060400 PCIe Root Port [ 5.925043] pci 0000:00:1c.4: PCI bridge to [bus 02-03] [ 5.925066] pci 0000:00:1c.4: bridge window [io 0x2000-0x2fff] [ 5.925087] pci 0000:00:1c.4: bridge window [mem 0xa9000000-0xaa0fffff] [ 5.925351] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold (XEN) PCI add device 0000:00:1c.4 [ 5.926839] pci 0000:00:1d.0: [8086:a198] type 01 class 0x060400 PCIe Root Port [ 5.927003] pci 0000:00:1d.0: PCI bridge to [bus 04] [ 5.927292] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold (XEN) PCI add device 0000:00:1d.0 [ 5.928997] pci 0000:00:1f.0: [8086:a1c8] type 00 class 0x060100 conventional PCI endpoint (XEN) PCI add device 0000:00:1f.0 [ 5.929858] pci 0000:00:1f.2: [8086:a1a1] type 00 class 0x058000 conventional PCI endpoint [ 5.929928] pci 0000:00:1f.2: BAR 0 [mem 0xaa210000-0xaa213fff] (XEN) PCI add device 0000:00:1f.2 [ 5.930589] pci 0000:00:1f.4: [8086:a1a3] type 00 class 0x0c0500 conventional PCI endpoint [ 5.930699] pci 0000:00:1f.4: BAR 0 [mem 0xaafff000-0xaafff0ff 64bit] [ 5.930824] pci 0000:00:1f.4: BAR 4 [io 0x3fe0-0x3fff] (XEN) PCI add device 0000:00:1f.4 [ 5.931153] pci 0000:00:1f.5: [8086:a1a4] type 00 class 0x0c8000 conventional PCI endpoint [ 5.931236] pci 0000:00:1f.5: BAR 0 [mem 0xfe010000-0xfe010fff] (XEN) PCI add device 0000:00:1f.5 [ 5.932051] pci 0000:00:1c.0: PCI bridge to [bus 01] [ 5.932359] pci 0000:02:00.0: [1a03:1150] type 01 class 0x060400 PCIe to PCI/PCI-X bridge [ 5.932530] pci 0000:02:00.0: PCI bridge to [bus 03] [ 5.932563] pci 0000:02:00.0: bridge window [io 0x2000-0x2fff] [ 5.932584] pci 0000:02:00.0: bridge window [mem 0xa9000000-0xaa0fffff] [ 5.932694] pci 0000:02:00.0: enabling Extended Tags [ 5.932902] pci 0000:02:00.0: supports D1 D2 [ 5.932912] pci 0000:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold (XEN) PCI add device 0000:02:00.0 [ 5.933200] pci 0000:00:1c.4: PCI bridge to [bus 02-03] [ 5.933376] pci_bus 0000:03: extended config space not accessible [ 5.933460] pci 0000:03:00.0: [1a03:2000] type 00 class 0x030000 conventional PCI endpoint [ 5.933551] pci 0000:03:00.0: BAR 0 [mem 0xa9000000-0xa9ffffff] [ 5.933605] pci 0000:03:00.0: BAR 1 [mem 0xaa000000-0xaa01ffff] [ 5.933660] pci 0000:03:00.0: BAR 2 [io 0x2000-0x207f] [ 5.933946] pci 0000:03:00.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff] [ 5.934083] pci 0000:03:00.0: supports D1 D2 [ 5.934094] pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold (XEN) PCI add device 0000:03:00.0 [ 5.943505] pci 0000:02:00.0: PCI bridge to [bus 03] [ 5.944016] pci 0000:00:1d.0: PCI bridge to [bus 04] [ 5.945980] ACPI: PCI Root Bridge [PC01] (domain 0000 [bus 16-63]) [ 5.945999] acpi PNP0A08:01: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3] [ 5.946919] acpi PNP0A08:01: _OSC: platform does not support [SHPCHotplug AER LTR DPC] [ 5.947743] acpi PNP0A08:01: _OSC: OS now controls [PCIeHotplug PME PCIeCapability] [ 5.947758] acpi PNP0A08:01: FADT indicates ASPM is unsupported, using BIOS configuration [ 5.948321] PCI host bridge to bus 0000:16 [ 5.948332] pci_bus 0000:16: root bus resource [io 0x4000-0x7fff window] [ 5.948345] pci_bus 0000:16: root bus resource [mem 0xab000000-0xc5ffffff window] [ 5.948360] pci_bus 0000:16: root bus resource [mem 0x384000000000-0x387fffffffff window] [ 5.948375] pci_bus 0000:16: root bus resource [bus 16-63] [ 5.949909] pci 0000:16:05.0: [8086:2034] type 00 class 0x088000 PCIe Root Complex Integrated Endpoint (XEN) PCI add device 0000:16:05.0 [ 5.950395] pci 0000:16:05.2: [8086:2035] type 00 class 0x088000 PCIe Root Complex Integrated Endpoint (XEN) PCI add device 0000:16:05.2 [ 5.950818] pci 0000:16:05.4: [8086:2036] type 00 class 0x080020 PCIe Root Complex Integrated Endpoint [ 5.950896] pci 0000:16:05.4: BAR 0 [mem 0xc5f00000-0xc5f00fff] (XEN) PCI add device 0000:16:05.4 [ 5.951991] pci 0000:16:08.0: [8086:208d] type 00 class 0x088000 conventional PCI endpoint (XEN) PCI add device 0000:16:08.0 [ 5.952334] pci 0000:16:08.1: [8086:208d] type 00 class 0x088000 conventional PCI endpoint (XEN) PCI ad[ 8.192912] Freeing initrd memory: 142708K [ 8.216252] Segment Routing with IPv6 [ 8.216279] In-situ OAM (IOAM) with IPv6 [ 8.216326] NET: Registered PF_PACKET protocol family [ 8.216446] Key type dns_resolver registered [ 8.217127] mce: Unable to init device /dev/mcelog, already registered [ 8.217270] No MBM correction factor available [ 8.217308] IPI shorthand broadcast: enabled [ 8.219651] sched_clock: Marking stable (8164005079, 55497260)->(8269941226, -50438887) [ 8.220122] registered taskstats version 1 [ 8.220813] Loading compiled-in X.509 certificates [ 8.221521] Loaded X.509 cert 'Build time autogenerated kernel key: 92155ebfc585c501e81f1546047dc047a265b1ca' [ 8.222096] Loaded X.509 cert 'Canonical Ltd. Live Patch Signing: 14df34d1a87cf37625abec039ef2bf521249b969' [ 8.222669] Loaded X.509 cert 'Canonical Ltd. Kernel Module Signing: 88f752e560a1e0737e31163a466ad7b70a850c19' [ 8.222685] blacklist: Loading compiled-in revocation X.509 certificates [ 8.222718] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing: 61482aa2830d0ab2ad5af10b7250da9033ddcef0' [ 8.222748] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2017): 242ade75ac4a15e50d50c84b0d45ff3eae707a03' [ 8.222778] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (ESM 2018): 365188c1d374d6b07c3c8f240f8ef722433d6a8b' [ 8.222809] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2019): c0746fd6c5da3ae827864651ad66ae47fe24b3e8' [ 8.222839] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2021 v1): a8d54bbb3825cfb94fa13c9f8a594a195c107b8d' [ 8.222869] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2021 v2): 4cf046892d6fd3c9a5b03f98d845f90851dc6a8c' [ 8.222902] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2021 v3): 100437bb6de6e469b581e61cd66bce3ef4ed53af' [ 8.222934] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (Ubuntu Core 2019): c1d57b8f6b743f23ee41f4f7ee292f06eecadfb9' [ 8.227860] Key type .fscrypt registered [ 8.227871] Key type fscrypt-provisioning registered [ 8.283930] Key type encrypted registered [ 8.283958] AppArmor: AppArmor sha256 policy hashing enabled [ 8.283972] audit: type=1400 audit(1733149701.476:5): apparmor="STATUS" info="AppArmor sha256 policy hashing enabled" pid=1 comm="swapper/0" [ 8.284774] ima: No TPM chip found, activating TPM-bypass! [ 8.284790] Loading compiled-in module X.509 certificates [ 8.285375] Loaded X.509 cert 'Build time autogenerated kernel key: 92155ebfc585c501e81f1546047dc047a265b1ca' [ 8.285391] ima: Allocated hash algorithm: sha256 [ 8.285409] ima: No architecture policies found [ 8.285429] evm: Initialising EVM extended attributes: [ 8.285437] evm: security.selinux [ 8.285444] evm: security.SMACK64 [ 8.285450] evm: security.SMACK64EXEC [ 8.285457] evm: security.SMACK64TRANSMUTE [ 8.285463] evm: security.SMACK64MMAP [ 8.285470] evm: security.apparmor [ 8.285476] evm: security.ima [ 8.285482] evm: security.capability [ 8.285488] evm: HMAC attrs: 0x1 [ 8.286126] PM: Magic number: 4:597:484 [ 8.286423] BIOS EDD facility v0.16 2004-Jun-25, 2 devices found [ 8.286819] audit: type=1334 audit(1733149701.479:6): prog-id=1 op=LOAD [ 8.287838] audit: type=1334 audit(1733149701.480:7): prog-id=2 op=LOAD (XEN) arch/x86/pv/emul-priv-op.c:1175:d0v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d0v1 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d0v2 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d0v3 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d0v4 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d0v5 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d0v6 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d0v7 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented [ 8.293414] RAS: Correctable Errors collector initialized. [ 8.293550] clk: Disabling unused clocks [ 8.295821] Freeing unused decrypted memory: 2028K [ 8.298655] Freeing unused kernel image (initmem) memory: 4972K [ 8.298669] Write protecting the kernel read-only data: 36864k [ 8.321247] Freeing unused kernel image (rodata/data gap) memory: 352K [ 10.189159] x86/mm: Checked W+X mappings: passed, no W+X pages found. [ 10.189265] Run /init as init process [ 10.189694] audit: type=1334 audit(1733149703.382:8): prog-id=1 op=UNLOAD [ 10.756089] Already setup the GSI :16 [ 10.756386] xhci_hcd 0000:00:14.0: xHCI Host Controller [ 10.756536] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1 [ 10.757196] Already setup the GSI :16 [ 10.757724] xhci_hcd 0000:00:14.0: hcc params 0x200077c1 hci version 0x100 quirks 0x0000000000009810 [ 10.758323] xhci_hcd 0000:00:14.0: xHCI Host Controller [ 10.758341] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2 [ 10.758359] xhci_hcd 0000:00:14.0: Host supports USB 3.0 SuperSpeed [ 10.758548] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.08 [ 10.758574] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 10.758589] usb usb1: Product: xHCI Host Controller [ 10.758600] usb usb1: Manufacturer: Linux 6.8.0-48-generic xhci-hcd [ 10.758613] usb usb1: SerialNumber: 0000:00:14.0 [ 10.758913] hub 1-0:1.0: USB hub found [ 10.758953] hub 1-0:1.0: 16 ports detected [ 10.761546] ast 0000:03:00.0: vgaarb: deactivate vga console [ 10.761860] Already setup the GSI :16 [ 10.762165] Already setup the GSI :16 [ 10.762280] ast 0000:03:00.0: Using default configuration [ 10.762292] ast 0000:03:00.0: AST 2500 detected [ 10.762381] ast 0000:03:00.0: [drm] Using analog VGA [ 10.762394] ast 0000:03:00.0: [drm] dram MCLK=800 Mhz type=1 bus_width=16 [ 10.763044] Already setup the GSI :16 [ 10.763379] i801_smbus 0000:00:1f.4: SPD Write Disable is set [ 10.763477] i801_smbus 0000:00:1f.4: SMBus using PCI interrupt [ 10.767898] ahci 0000:00:11.5: AHCI 0001.0301 32 slots 6 ports 6 Gbps 0x3f impl SATA mode [ 10.767922] ahci 0000:00:11.5: flags: 64bit ncq sntf led clo only pio slum part ems deso sadm sds apst [ 10.769610] [drm] Initialized ast 0.1.0 20120228 for 0000:03:00.0 on minor 0 [ 10.774453] fbcon: astdrmfb (fb0) is primary device [ 10.779016] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.08 [ 10.779024] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 10.779027] usb usb2: Product: xHCI Host Controller [ 10.779031] usb usb2: Manufacturer: Linux 6.8.0-48-generic xhci-hcd [ 10.779034] usb usb2: SerialNumber: 0000:00:14.0 [ 10.779414] hub 2-0:1.0: USB hub found [ 10.779475] hub 2-0:1.0: 10 ports detected [ 10.787044] scsi host0: ahci [ 10.787383] scsi host1: ahci [ 10.787686] scsi host2: ahci [ 10.787955] scsi host3: ahci [ 10.788232] scsi host4: ahci [ 10.788589] scsi host5: ahci [ 10.788650] ata1: SATA max UDMA/133 abar m524288@0xaa180000 port 0xaa180100 irq 113 lpm-pol 0 [ 10.788654] ata2: SATA max UDMA/133 abar m524288@0xaa180000 port 0xaa180180 irq 113 lpm-pol 0 [ 10.788658] ata3: SATA max UDMA/133 abar m524288@0xaa180000 port 0xaa180200 irq 113 lpm-pol 0 [ 10.788662] ata4: SATA max UDMA/133 abar m524288@0xaa180000 port 0xaa180280 irq 113 lpm-pol 0 [ 10.788664] ata5: SATA max UDMA/133 abar m524288@0xaa180000 port 0xaa180300 irq 113 lpm-pol 0 [ 10.788666] ata6: SATA max UDMA/133 abar m524288@0xaa180000 port 0xaa180380 irq 113 lpm-pol 0 [ 10.789254] Already setup the GSI :16 [ 10.789799] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 8 ports 6 Gbps 0xff impl SATA mode [ 10.789804] ahci 0000:00:17.0: flags: 64bit ncq sntf led clo only pio slum part ems deso sadm sds apst [ 10.789961] Console: switching to colour frame buffer device 128x48 [ 10.804624] pstore: backend 'efi' already in use: ignoring 'efi_pstore' [ 10.814834] scsi host6: ahci [ 10.815192] scsi host7: ahci [ 10.815533] scsi host8: ahci [ 10.815542] ast 0000:03:00.0: [drm] fb0: astdrmfb frame buffer device [ 10.816436] scsi host9: ahci [ 10.817897] scsi host10: ahci [ 10.818559] scsi host11: ahci [ 10.819184] scsi host12: ahci [ 10.819861] scsi host13: ahci [ 10.820335] ata7: SATA max UDMA/133 abar m524288@0xaa100000 port 0xaa100100 irq 115 lpm-pol 0 [ 10.820690] ata8: SATA max UDMA/133 abar m524288@0xaa100000 port 0xaa100180 irq 115 lpm-pol 0 [ 10.821003] ata9: SATA max UDMA/133 abar m524288@0xaa100000 port 0xaa100200 irq 115 lpm-pol 0 [ 10.821310] ata10: SATA max UDMA/133 abar m524288@0xaa100000 port 0xaa100280 irq 115 lpm-pol 0 [ 10.821644] ata11: SATA max UDMA/133 abar m524288@0xaa100000 port 0xaa100300 irq 115 lpm-pol 0 [ 10.821954] ata12: SATA max UDMA/133 abar m524288@0xaa100000 port 0xaa100380 irq 115 lpm-pol 0 [ 10.822284] ata13: SATA max UDMA/133 abar m524288@0xaa100000 port 0xaa100400 irq 115 lpm-pol 0 [ 10.822630] ata14: SATA max UDMA/133 abar m524288@0xaa100000 port 0xaa100480 irq 115 lpm-pol 0 [ 10.835551] i2c i2c-0: 2/4 memory slots populated (from DMI) [ 11.016590] usb 1-3: new high-speed USB device number 2 using xhci_hcd [ 11.100205] ata4: SATA link down (SStatus 0 SControl 300) [ 11.100709] ata3: SATA link down (SStatus 0 SControl 300) [ 11.101259] ata5: SATA link down (SStatus 0 SControl 300) [ 11.101869] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 11.102389] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 11.102860] ata6: SATA link down (SStatus 0 SControl 300) [ 11.103359] ata2.00: supports DRM functions and may not be fully accessible [ 11.103651] ata2.00: ATA-11: SAMSUNG MZ7L31T9HBLT-00A07, JXTC304Q, max UDMA/133 [ 11.103914] ata1.00: supports DRM functions and may not be fully accessible [ 11.104179] ata1.00: ATA-11: SAMSUNG MZ7L31T9HBLT-00A07, JXTC304Q, max UDMA/133 [ 11.105368] ata2.00: 3750748848 sectors, multi 16: LBA48 NCQ (depth 32), AA [ 11.105683] ata1.00: 3750748848 sectors, multi 16: LBA48 NCQ (depth 32), AA [ 11.109414] ata2.00: Features: FUA Trust NCQ-sndrcv [ 11.109723] ata1.00: Features: FUA Trust NCQ-sndrcv [ 11.110370] ata2.00: supports DRM functions and may not be fully accessible [ 11.110676] ata1.00: supports DRM functions and may not be fully accessible [ 11.115835] ata2.00: configured for UDMA/133 [ 11.116137] ata1.00: configured for UDMA/133 [ 11.116634] scsi 0:0:0:0: Direct-Access ATA SAMSUNG MZ7L31T9 304Q PQ: 0 ANSI: 5 [ 11.117489] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 11.117623] sd 0:0:0:0: [sda] 3750748848 512-byte logical blocks: (1.92 TB/1.75 TiB) [ 11.118111] scsi 1:0:0:0: Direct-Access ATA SAMSUNG MZ7L31T9 304Q PQ: 0 ANSI: 5 [ 11.118133] sd 0:0:0:0: [sda] 4096-byte physical blocks [ 11.118836] sd 0:0:0:0: [sda] Write Protect is off [ 11.118917] sd 1:0:0:0: Attached scsi generic sg1 type 0 [ 11.118990] sd 1:0:0:0: [sdb] 3750748848 512-byte logical blocks: (1.92 TB/1.75 TiB) [ 11.118994] sd 1:0:0:0: [sdb] 4096-byte physical blocks [ 11.119007] sd 1:0:0:0: [sdb] Write Protect is off [ 11.119032] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA [ 11.119086] sd 1:0:0:0: [sdb] Preferred minimum I/O size 4096 bytes [ 11.121269] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA [ 11.121796] sd 0:0:0:0: [sda] Preferred minimum I/O size 4096 bytes [ 11.122123] sdb: sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 [ 11.124617] sda: sda1 sda2 sda3 sda4 sda5 sda6 [ 11.126455] sd 0:0:0:0: [sda] supports TCG Opal [ 11.126491] sd 1:0:0:0: [sdb] supports TCG Opal [ 11.126788] sd 0:0:0:0: [sda] Attached SCSI disk [ 11.127089] sd 1:0:0:0: [sdb] Attached SCS0) [ 11.133737] ata11: SATA link down (SStatus 0 SControl 300) [ 11.134313] ata9: SATA link down (SStatus 0 SControl 300) [ 11.134831] ata7: SATA link down (SStatus 0 SControl 300) [ 11.135394] ata13: SATA link down (SStatus 0 SControl 300) [ 11.135852] ata12: SATA link down (SStatus 0 SControl 300) [ 11.136674] ata8: SATA link down (SStatus 0 SControl 300) [ 11.153304] usb 1-3: New USB device found, idVendor=0557, idProduct=7000, bcdDevice= 0.00 [ 11.153664] usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 11.157055] hub 1-3:1.0: USB hub found [ 11.157630] hub 1-3:1.0: 4 ports detected [ 11.272538] usb 1-4: new high-speed USB device number 3 using xhci_hcd [ 11.407524] raid6:.409419] usb 1-4: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 11.409786] usb 1-4: Product: USB2.0 Hub [ 11.411340] hub 1-4:1.0: USB hub found [ 11.411997] hub 1-4:1.0: 4 ports detected [ 11.424519] raid6: avx512x2 gen() 40218 MB/s [ 11.441518] raid6: avx512x1 gen() 36952 MB/s [ 11.458522] raid6: avx2x4 gen() 28067 MB/s [ 11.475527] raid6: avx2x2 gen() 27585 MB/s [ 11.483539] usb 1-3.1: new low-speed USB device number 4 using xhci_hcd [ 11.492517] raid6: avx2x1 gen() 22404 MB/s [ 11.492863] raid6: using algorithm avx512x4 gen() 40300 MB/s [ 11.509533] raid6: .... xor() 7374 MB/s, rmw enabled [ 11.509870] raid6: using avx512x2 recovery algorithm [ 11.511775] xor: automatically using best checksumming function avx [ 11.513806] async_tx: api initialized (async) [ 11.562577] md/raid1:mdX: active with 2 out of 2 mirrors [ 11.570641] md/raid1:mdX: active with 2 out of 2 mirrors [ 11.577003] usb 1-3.1: New USB device found, idVendor=0557, idProduct=2419, bcdDevice= 1.00 [ 11.577485] usb 1-3.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 11.609086] hid: raw HID events driver (C) Jiri Kosina [ 11.619807] usbcore: registered new interface driver usbhid [ 11.620239] usbhid: USB HID core driver [ 11.624477] input: HID 0557:2419 as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.1/1-3.1:1.0/0003:0557:2419.0001/input/input1 [ 11.677710] hid-generic 0003:0557:2419.0001: input,hidraw0: USB HID v1.00 Keyboard [HID 0557:2419] on usb-0000:00:14.0-3.1/input0 [ 11.678738] input: HID 0557:2419 as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.1/1-3.1:1.1/0003:0557:2419.0002/input/input2 [ 11.679678] hid-generic 0003:0557:2419.0002: input,hidraw1: USB HID v1.00 Mouse [HID 0557:2419] on usb-0000:00:14.0-3.1/input1 [ 11.687543] usb 1-4.2: new high-speed USB device number 5 using xhci_hcd [ 11.767695] usb 1-4.2: New USB device found, idVendor=05e3, idProduct=0610, bcdDevice=32.98 [ 11.768254] usb 1-4.2: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 11.768699] usb 1-4.2: Product: USB2.0 Hub [ 11.771520] hub 1-4.2:1.0: USB hub found [ 11.772354] hub 1-4.2:1.0: 4 ports detected [ 11.911564] aufs 6.8-20240923 [ 11.947637] spl: loading out-of-tree module taints kernel. [ 11.948478] spl: module verification failed: signature and/or required key missing - tainting kernel [ 12.008615] zfs: module license 'CDDL' taints kernel. [ 12.009116] Disabling lock debugging due to kernel taint [ 12.009571] zfs: module license taints kernel. [ 14.051380] ZFS: Loaded module v2.2.6-8_gb67a69748a, ZFS pool version 5000, ZFS filesystem version 5 [ 14.062528] zram: Added device: zram0 [ 15.684459] zd128: p1 p2 [ 15.692278] zd144: p1 p2 [ 15.696637] zd160: p1 p2 [ 15.700455] zd176: p1 p2 [ 15.705816] zd192: p1 p2 [ 15.713339] zd208: p1 p2 [ 15.718571] zd224: p1 p2 [ 15.723368] zd240: p1 p2 [ 15.759231] zd256: p1 [ 15.773105] zd272: p1 [ 15.783937] zd288: p1 [ 15.825543] zd304: p1 [ 15.861385] zd320: p1 p2 p3 [ 15.895048] zd336: p1 p2 [ 15.902184] zd352: p1 p2 [ 15.907204] zd368: p1 p2 [ 15.911359] zd384: p1 p2 [ 15.916588] zd400: p1 p2 [ 15.921910] zd416: p1 p2 [ 15.928607] zd432: p1 p2 [ 15.933049] zd448: p1 p2 [ 16.078365] zd592: p1 p2 [ 16.092093] zd608: p1 p2 [ 16.102939] zd624: p1 p2 [ 16.112428] zd640: p1 p2 [ 16.123649] zd656: p1 p2 [ 16.129564] zd672: p1 p2 [ 16.136278] zd688: p1 p2 [ 16.144290] zd704: p1 p2 [ 16.152803] zd720: p1 [ 16.160470] zd736: p1 [ 16.208637] zd752: p1 [ 16.253539] zd768: p1 p2 p3 p4 p5 [ 16.294429] zd784: p1 [ 16.326336] zd816: p1 [ 16.360686] zd832: p1 p2 p3 [ 16.384436] zd848: p1 [ 16.403634] zd864: p1 [ 16.415751] zd880: p1 [ 16.423026] zd896: p1 [ 16.501256] zd1040: p1 p2 [ 16.517194] zd1056: p1 p2 [ 16.521339] zd1072: p1 p2 [ 16.525051] zd1088: p1 p2 [ 16.529343] zd1104: p1 p2 [ 16.532932] zd1120: p1 p2 [ 16.536891] zd1136: p1 p2 [ 16.542303] zd1152: p1 p2 [ 16.564081] zd1168: p1 [ 16.594718] zd1184: p1 [ 16.634805] zd1200: p1 [ 16.657414] zd1216: p1 [ 16.690011] zd1232: p1 [ 16.719542] zd1248: p1 p2 p3 [ 16.730399] zd1264: p1 [ 16.737806] zd1280: p1 [ 16.761727] zd1296: p1 [ 16.787239] zd1312: p1 p2 p3 [ 16.812539] zd1328: p1 [ 16.832342] zd1344: p1 p2 [ 16.837232] zd1360: p1 p2 [ 16.840666] zd1376: p1 p2 [ 16.844548] zd1392: p1 p2 [ 16.849084] zd1408: p1 p2 [ 16.855368] zd1424: p1 p2 [ 16.861518] zd1440: p1 p2 [ 16.866762] zd1456: p1 p2 [ 16.967086] zd1600: p1 [ 16.987140] zd1616: p1 [ 17.014874] zd1632: p1 [ 17.050362] zd1648: p1 [ 17.084595] zd1664: p1 p2 p3 [ 17.155633] zd1824: p1 p2 [ 17.166382] zd1840: p1 p2 [ 17.171784] zd1856: p1 p2 [ 17.182691] zd1872: p1 p2 [ 17.186294] zd1888: p1 p2 [ 17.195674] zd1904: p1 p2 [ 17.199847] zd1920: p1 p2 [ 17.204896] zd1936: p1 p2 [ 17.241423] zd1952: p1 [ 17.274255] zd1968: p1 p2 p3 [ 17.318660] zd1984: p1 [ 17.330549] zd2000: p1 [ 17.335910] zd2016: p1 [ 17.373388] zd2032: p1 [ 17.398070] zd2048: p1 p2 p3 p4 [ 17.427189] zd2064: p1 [ 17.438083] zd2080: p1 [ 17.448370] zd2096: p1 [ 17.479164] zd2112: p1 [ 17.494733] zd2128: p1 [ 17.518908] zd2144: p1 [ 17.525477] zd2160: p1 [ 17.549330] zd2176: p1 [ 17.554033] zd2192: p1 [ 17.581309] zd2208: p1 p2 p3 [ 17.587389] zd2224: p1 p2 p3 [ 17.615081] zd2240: p1 [ 17.621542] zd2256: p1 [ 17.648805] zd2272: p1 p2 p3 [ 17.658974] zd2288: p1 p2 p3 [ 17.694089] zd2304: p1 [ 17.698898] zd2320: p1 [ 17.726037] zd2336: p1 [ 17.734483] zd2352: p1 [ 17.767767] zd2368: p1 [ 17.776913] zd2384: p1 [ 17.799631] zd2400: p1 [ 17.807928] zd2416: p1 [ 17.812870] zd2432: p1 [ 17.845471] zd2448: p1 [ 17.867694] zd2464: p1 [ 17.874419] zd2480: p1 [ 17.899589] zd2496: p1 p2 p3 [ 17.921126] zd2512: p1 p2 p3 [ 17.929597] zd2528: p1 p2 p3 [ 17.964911] zd2544: p1 [ 17.992050] zd2560: p1 [ 18.004137] zd2576: p1 [ 18.030769] zd2592: p1 [ 18.050453] zd2608: p1 [ 18.054705] zd2624: p1 [ 18.067196] GPT:Primary header thinks Alt. header is not at the end of the disk. [ 18.067818] GPT:136314879 != 150994943 [ 18.068048] GPT:Alternate GPT header not at the end of the disk. [ 18.068238] GPT:136314879 != 150994943 [ 18.068479] GPT: Use GNU Parted to correct GPT errors. [ 18.068720] zd2640: p1 p2 p3 p4 [ 18.080667] GPT:Primary header thinks Alt. header is not at the end of the disk. [ 18.081018] GPT:136314879 != 150994943 [ 18.081297] GPT:Alternate GPT header not at the end of the disk. [ 18.081574] GPT:136314879 != 150994943 [ 18.081930] GPT: Use GNU Parted to correct GPT errors. [ 18.082259] zd2656: p1 p2 p3 p4 [ 18.115938] zd2672: p1 p2 p3 [ 18.122614] zd2688: p1 p2 p3 [ 18.148071] zd2704: p1 p2 [ 18.179919] zd2720: p1 p2 [ 18.195428] zd2736: p1 p2 [ 18.204913] zd2752: p1 p2 [ 18.244854] zd2768: p1 p2 [ 18.255308] zd2784: p1 p2 [ 18.282608] zd2800: p1 p2 [ 18.290207] zd2816: p1 p2 [ 18.325104] GPT:Primary header thinks Alt. header is not at the end of the disk. [ 18.325606] GPT:2092307 != 2121223 [ 18.326007] GPT:Alternate GPT header not at the end of the disk. [ 18.326490] GPT:2092307 != 2121223 [ 18.326935] GPT: Use GNU Parted to correct GPT errors. [ 18.327393] zd2832: p1 p2 p3 [ 18.340263] GPT:Primary header thinks Alt. header is not at the end of the disk. [ 18.340809] GPT:2092307 != 2121223 [ 18.341331] GPT:Alternate GPT header not at the end of the disk. [ 18.341907] GPT:2092307 != 2121223 [ 18.342461] GPT: Use GNU Parted to correct GPT errors. [ 18.342947] zd2848: p1 p2 p3 [ 18.399652] zd2896: p1 p2 [ 18.415217] zd2912: p1 p2 [ 18.421340] zd2928: p1 p2 [ 18.456891] zd2944: p1 [ 18.466279] zd2960: p1 [ 18.489809] zd2976: p1 [ 18.506030] zd2992: p1 [ 18.537008] zd3008: p1 p2 p3 [ 18.547133] zd3024: p1 p2 p3 [ 18.570563] zd3040: p1 [ 18.574941] zd3056: p1 [ 18.600456] zd3072: p1 [ 18.609046] zd3088: p1 [ 18.666176] zd3184: p1 [ 18.676845] zd3200: p1 [ 18.706743] zd3216: p1 [ 18.712601] zd3232: p1 [ 18.718571] zd3248: p1 [ 18.724193] zd3264: p1 [ 18.754431] zd3280: p1 p2 p3 p4 p5 [ 18.766859] zd3296: p1 p2 p3 p4 p5 [ 18.798088] zd3312: p1 p2 p3 [ 18.807046] zd3328: p1 p2 p3 [ 18.838557] zd3344: p1 [ 18.843617] zd3360: p1 [ 18.881195] zd3376: p1 [ 18.889567] zd3392: p1 [ 18.924214] zd3408: p1 [ 18.935948] zd3424: p1 [ 18.969589] zd3440: p1 [ 18.992038] zd3456: p1 [ 18.999794] zd3472: p1 [ 19.027024] zd3488: p1 [ 19.047805] zd3504: p1 [ 19.052763] zd3520: p1 [ 19.072900] zd3536: p1 p2 p3 [ 19.101067] zd3552: p1 p2 p3 [ 19.107390] zd3568: p1 p2 p3 [ 19.132793] zd3584: p1 [ 19.142550] zd3600: p1 [ 19.146552] zd3616: p1 [ 19.177062] zd3632: p1 [ 19.192527] zd3648: p1 [ 19.224152] zd3664: p1 [ 19.229546] zd3680: p1 [ 19.263296] zd3696: p1 p2 p3 [ 19.272347] zd3712: p1 p2 p3 [ 19.296989] zd3728: p1 [ 19.301284] zd3744: p1 [ 19.330373] zd3760: p1 p2 p3 [ 19.341000] zd3776: p1 p2 p3 [ 19.367749] zd3792: p1 [ 19.373321] zd3808: p1 [ 19.407366] zd3824: p1 [ 19.415588] zd3840: p1 [ 19.445767] zd3856: p1 [ 19.457104] zd3872: p1 [ 19.489562] zd3888: p1 [ 19.495989] zd3904: p1 [ 19.523679] zd3920: p1 [ 19.527982] zd3936: p1 [ 19.554042] zd3952: p1 p2 p3 p4 [ 19.564070] zd3968: p1 p2 p3 p4 [ 19.579553] zd3984: p1 [ 19.583749] zd4000: p1 [ 19.625580] zd4048: p1 [ 19.642508] zd4064: p1 [ 19.677044] zd4080: p1 [ 19.686594] zd4096: p1 [ 19.719236] zd4112: p1 p2 p3 [ 19.727177] zd4128: p1 p2 p3 [ 19.749077] zd4144: p1 [ 19.754024] zd4160: p1 [ 19.757955] zd4176: p1 [ 19.765297] zd4192: p1 p2 [ 19.770450] zd4208: p1 p2 [ 19.777095] zd4224: p1 p2 [ 19.782802] zd4240: p1 p2 [ 19.790737] zd4256: p1 p2 [ 19.795937] zd4272: p1 p2 [ 19.815594] zd4288: p1 p2 [ 19.912123] zd4448: p1 [ 61.282137] loop0: detected capacity change from 0 to 9533440 [ 63.948708] EXT4-fs: Warning: mounting with data=journal disables delayed allocation, dioread_nolock, O_DIRECT and fast_commit support! [ 63.949721] EXT4-fs (dm-8): mounting ext3 file system using the ext4 subsystem [ 63.954167] EXT4-fs (dm-8): mounted filesystem 1483d293-407b-4a2b-b4c1-a86729d91b3d r/w with journalled data mode. Quota mode: none. [ 63.957927] EXT4-fs (dm-8): unmounting filesystem 1483d293-407b-4a2b-b4c1-a86729d91b3d. [ 110.140100] EXT4-fs (loop0): mounted filesystem 19a5e477-b452-4d76-82fa-c6f6e1a3a706 ro with ordered data mode. Quota mode: none. [ 110.176194] aufs test_add:291:mount[5100]: uid/gid/perm /root.ro 0/0/0755, 0/0/01777 [ 110.461627] EXT4-fs (loop0): re-mounted 19a5e477-b452-4d76-82fa-c6f6e1a3a706 ro. Quota mode: none. [ 110.470631] EXT4-fs (loop0): re-mounted 19a5e477-b452-4d76-82fa-c6f6e1a3a706 ro. Quota mode: none. [ 110.479405] EXT4-fs (loop0): re-mounted 19a5e477-b452-4d76-82fa-c6f6e1a3a706 ro. Quota mode: none. [ 110.545537] EXT4-fs (loop0): re-mounted 19a5e477-b452-4d76-82fa-c6f6e1a3a706 ro. Quota mode: none. [ 111.062634] systemd[1]: Inserted module 'autofs4' [ 111.123552] systemd[1]: systemd 249.11-0ubuntu3.12 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified) [ 111.125552] systemd[1]: Detected architecture x86-64. [ 111.135665] systemd[1]: Hostname set to . [ 111.180278] audit: type=1334 audit(1733149804.372:9): prog-id=3 op=LOAD [ 111.180840] audit: type=1300 audit(1733149804.372:9): arch=c000003e syscall=321 success=yes exit=8 a0=5 a1=7ffdac0860c0 a2=78 a3=7ffdac0860c0 items=0 ppid=0 pid=1 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="systemd" exe="/usr/lib/systemd/systemd" subj=unconfined key=(null) [ 111.182351] audit: type=1327 audit(1733149804.372:9): proctitle=2F7362696E2F696E6974007A796F7665726C6179 [ 111.182854] audit: type=1334 audit(1733149804.372:10): prog-id=3 op=UNLOAD [ 111.183317] audit: type=1300 audit(1733149804.372:10): arch=c000003e syscall=3 success=yes exit=0 a0=8 a1=7ffdac086180 a2=78 a3=200000008 items=0 ppid=0 pid=1 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="systemd" exe="/usr/lib/systemd/systemd" subj=unconfined key=(null) [ 111.184768] audit: type=1327 audit(1733149804.372:10): proctitle=2F7362696E2F696E6974007A796F7665726C6179 [ 111.185245] audit: type=1334 audit(1733149804.372:11): prog-id=4 op=LOAD [ 111.185728] audit: type=1300 audit(1733149804.372:11): arch=c000003e syscall=321 success=yes exit=8 a0=5 a1=7ffdac086190 a2=78 a3=7ffdac086190 items=0 ppid=0 pid=1 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="systemd" exe="/usr/lib/systemd/systemd" subj=unconfined key=(null) [ 111.187154] audit: type=1327 audit(1733149804.372:11): proctitle=2F7362696E2F696E6974007A796F7665726C6179 [ 111.187664] audit: type=1334 audit(1733149804.372:12): prog-id=4 op=UNLOAD [ 111.658866] systemd[1]: Configuration file /run/systemd/system/netplan-ovs-cleanup.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway. [ 111.753056] systemd[1]: Queued start job for default target Graphical Interface. [ 111.767784] systemd[1]: Created slice Slice /system/modprobe. [ 111.770376] systemd[1]: Created slice Slice /system/serial-getty. [ 111.772524] systemd[1]: Created slice Slice /system/ourcorp-proxhub. [ 111.774436] systemd[1]: Created slice User and Session Slice. [ 111.775882] systemd[1]: Started Dispatch Password Requests to Console Directory Watch. [ 111.777281] systemd[1]: Started Forward Password Requests to Wall Directory Watch. [ 111.778923] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. [ 111.780155] systemd[1]: Reached target Local Encrypted Volumes. [ 111.781381] systemd[1]: Reached target Remote File Systems. [ 111.782594] systemd[1]: Reached target Slice Units. [ 111.783766] systemd[1]: Reached target TLS tunnels for network services - per-config-file target. [ 111.784949] systemd[1]: Reached target Swaps. [ 111.786107] systemd[1]: Reached target Local Verity Protected Volumes. [ 111.787559] systemd[1]: Listening on Device-mapper event daemon FIFOs. [ 111.789094] systemd[1]: Listening on LVM2 poll daemon socket. [ 111.790605] systemd[1]: Listening on Syslog Socket. [ 111.792031] systemd[1]: Listening on fsck to fsckd communication Socket. [ 111.793312] systemd[1]: Listening on initctl Compatibility Named Pipe. [ 111.794818] systemd[1]: Listening on Journal Socket (/dev/log). [ 111.796507] systemd[1]: Listening on Network Service Netlink Socket. [ 111.798061] systemd[1]: Listening on udev Control Socket. [ 111.799503] systemd[1]: Listening on udev Kernel Socket. [ 111.801993] systemd[1]: Created slice Slice /system/ourcorp-diskmanager-disk-added. [ 111.804062] systemd[1]: Created slice Slice /system/ourcorp-wce. [ 111.805759] systemd[1]: Listening on Journal Socket. [ 111.807353] systemd[1]: Condition check resulted in Huge Pages File System being skipped. [ 111.812350] systemd[1]: Mounting POSIX Message Queue File System... [ 111.818148] systemd[1]: Mounting Mount /proc/xen files... [ 111.826311] systemd[1]: Mounting Kernel Debug File System... [ 111.832157] systemd[1]: Mounting Kernel Trace File System... [ 111.840831] systemd[1]: Starting Journal Service... [ 111.842745] systemd[1]: Finished Availability of block devices. [ 111.848401] systemd[1]: Starting Set the console keyboard layout... [ 111.855113] systemd[1]: Starting Create List of Static Device Nodes... [ 111.861770] systemd[1]: Starting Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling... [ 111.868286] systemd[1]: Starting Load Kernel Module configfs... [ 111.875663] systemd[1]: Starting Load Kernel Module drm... [ 111.883574] systemd[1]: Starting Load Kernel Module efi_pstore... [ 111.893692] systemd[1]: Starting Load Kernel Module fuse... [ 111.896557] systemd[1]: Condition check resulted in OpenVSwitch configuration for cleanup being skipped. [ 111.898110] systemd[1]: Condition check resulted in File System Check on Root Device being skipped. [ 111.908147] systemd[1]: Starting Load Kernel Modules... [ 111.916780] systemd[1]: Starting Remount Root and Kernel File Systems... [ 111.925265] systemd[1]: Starting Coldplug All udev Devices... [ 111.939529] xen:xen_evtchn: Event-channel device installed [ 111.939833] systemd[1]: Mounted POSIX Message Queue File System. [ 111.942638] systemd[1]: Mounted Mount /proc/xen files. [ 111.944906] systemd[1]: Mounted Kernel Debug File System. [ 111.955413] systemd[1]: Mounted Kernel Trace File System. [ 111.958920] systemd[1]: Finished Create List of Static Device Nodes. [ 111.961539] systemd[1]: modprobe@configfs.service: Deactivated successfully. [ 111.963226] systemd[1]: Finished Load Kernel Module configfs. [ 111.966439] systemd[1]: modprobe@drm.service: Deactivated successfully. [ 111.968493] systemd[1]: Finished Load Kernel Module drm. [ 111.971638] systemd[1]: modprobe@efi_pstore.service: Deactivated successfully. [ 111.973663] systemd[1]: Finished Load Kernel Module efi_pstore. [ 111.976781] systemd[1]: modprobe@fuse.service: Deactivated successfully. [ 111.978747] systemd[1]: Finished Load Kernel Module fuse. [ 111.982336] systemd[1]: Finished Remount Root and Kernel File Systems. [ 111.991596] systemd[1]: Mounting FUSE Control File System... [ 111.999783] systemd[1]: Mounting Kernel Configuration File System... [ 112.002194] systemd[1]: Condition check resulted in Platform Persistent Storage Archival being skipped. [ 112.009329] systemd[1]: Starting Load/Save Random Seed... [ 112.017925] systemd[1]: Starting Create System Users... [ 112.034770] xen_pciback: backend is passthrough [ 112.051685] systemd[1]: Finished Load Kernel Modules. [ 112.056212] systemd[1]: Mounted FUSE Control File System. [ 112.059151] systemd[1]: Mounted Kernel Configuration File System. [ 112.071019] systemd[1]: Finished Load/Save Random Seed. [ 112.074388] systemd[1]: Condition check resulted in First Boot Complete being skipped. [ 112.079728] systemd[1]: Starting Apply Kernel Variables... [ 112.087157] systemd[1]: Starting The Xen xenstore... (d1) Bootstrapping... (d1) Xen Minimal OS (pv)! (d1) start_info: 0x10a000(VA) (d1) nr_pages: 0x4000 (d1) shared_inf: 0x6fc9c000(MA) (d1) pt_base: 0x10d000(VA) (d1) nr_pt_frames: 0x5 (d1) mfn_list: 0xea000(VA) (d1) mod_start: 0x0(VA) (d1) mod_len: 0 (d1) flags: 0x10 (d1) cmd_line: --event 64 --watch-nb 512 --entry-nb 8000 --entry-size 4000 (d1) stack: 0xc8c40-0xe8c40 (d1) MM: Init (d1) _text: 0x0(VA) (d1) _etext: 0x7120f(VA) (d1) _erodata: 0x87000(VA) (d1) _edata: 0x89064(VA) (d1) stack start: 0xc8c40(VA) (d1) _end: 0xe9884(VA) (d1) start_pfn: 112 (d1) max_pfn: 4000 (d1) Mapping memory range 0x112000 - 0x4000000 (d1) setting 0x0-0x87000 readonly (d1) skipped 1000 (d1) Maximum memory size: 32776 pages (d1) MM: Initialise page allocator for 130000(130000)-4000000(4000000) (d1) Adding memory range 131000-4000000 (d1) MM: done (d1) remapped p2m list to 0x8000002000 (d1) Demand map pfns at 100000000000-108000000000. (d1) Heap resides at 200000000000-208000000000. (XEN) common/grant_table.c:1909:d1v0 Expanding d1 grant table from 1 to 4 frames (XEN) arch/x86/irq.c:3017: dom0: can't create irq for msi! (XEN) arch/x86/irq.c:3017: dom0: can't create irq for msi! (XEN) arch/x86/irq.c:3017: dom0: can't create irq for msi! (XEN) arch/x86/irq.c:3017: dom0: can't create irq for msi! (XEN) [VT-D]d0:PCIe: unmap 0000:65:00.0 (XEN) [VT-D]d0:PCIe: unmap 0000:65:00.1 (XEN) [VT-D]d2:PCIe: map 0000:65:00.0 (XEN) [VT-D]d2:PCIe: map 0000:65:00.1 (d2) mapping kernel into physical memory (d2) about to get started... (XEN) arch/x86/pv/emul-priv-op.c:1017:d2v0 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d2v0 RDMSR 0x00000034 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d2v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d2v1 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d2v1 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d2v1 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d2v1 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d2v1 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d2v0 RDMSR 0x000000b0 unimplemented (XEN) d2: Forcing read-only access to MFN e0e8c (XEN) d0: Forcing read-only access to MFN e0e8c (XEN) d2: Forcing read-only access to MFN e0e8c (XEN) arch/x86/pv/emul-priv-op.c:1017:d2v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d2v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d2v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d2v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d2v0 RDMSR 0x0000064d unimplemented (XEN) d2: Forcing read-only access to MFN e0e88 (XEN) d0: Forcing read-only access to MFN e0e88 (XEN) d2: Forcing read-only access to MFN e0e88 (XEN) common/grant_table.c:1909:d2v1 Expanding d2 grant table from 1 to 2 frames (XEN) d2 L1TF-vulnerable L1e c7ffe7ffff987e02 - Shadowing (XEN) d2 L1TF-vulnerable L1e c7ffe7ffff987e02 - Shadowing (XEN) arch/x86/pv/emul-priv-op.c:1017:d2v1 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d2v1 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d2v1 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d2v1 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d2v0 RDMSR 0x000000b0 unimplemented (XEN) common/grant_table.c:1909:d0v4 Expanding d0 grant table from 1 to 2 frames (XEN) common/grant_table.c:1909:d0v4 Expanding d0 grant table from 2 to 3 frames (XEN) common/memory.c:278:d0v1 Could not allocate order=18 extent: id=6 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v1 Could not allocate order=18 extent: id=6 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v1 Could not allocate order=18 extent: id=6 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v1 Could not allocate order=18 extent: id=6 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v1 Could not allocate order=18 extent: id=6 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v1 Could not allocate order=18 extent: id=6 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v0 Could not allocate order=18 extent: id=6 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v0 Could not allocate order=18 extent: id=6 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v0 Could not allocate order=18 extent: id=6 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v0 Could not allocate order=18 extent: id=6 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v0 Could not allocate order=18 extent: id=6 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v0 Could not allocate order=18 extent: id=6 memflags=0xc0 (0 of 1) (XEN) HVM d6v0 save: CPU (XEN) HVM d6v1 save: CPU (XEN) HVM d6v2 save: CPU (XEN) HVM d6v3 save: CPU (XEN) HVM d6 save: PIC (XEN) HVM d6 save: IOAPIC (XEN) HVM d6v0 save: LAPIC (XEN) HVM d6v1 save: LAPIC (XEN) HVM d6v2 save: LAPIC (XEN) HVM d6v3 save: LAPIC (XEN) HVM d6v0 save: LAPIC_REGS (XEN) HVM d6v1 save: LAPIC_REGS (XEN) HVM d6v2 save: LAPIC_REGS (XEN) HVM d6v3 save: LAPIC_REGS (XEN) HVM d6 save: PCI_IRQ (XEN) HVM d6 save: ISA_IRQ (XEN) HVM d6 save: PCI_LINK (XEN) HVM d6 save: PIT (XEN) HVM d6 save: RTC (XEN) HVM d6 save: HPET (XEN) HVM d6 save: PMTIMER (XEN) HVM d6v0 save: MTRR (XEN) HVM d6v1 save: MTRR (XEN) HVM d6v2 save: MTRR (XEN) HVM d6v3 save: MTRR (XEN) HVM d6 save: VIRIDIAN_DOMAIN (XEN) HVM d6v0 save: CPU_XSAVE (XEN) HVM d6v1 save: CPU_XSAVE (XEN) HVM d6v2 save: CPU_XSAVE (XEN) HVM d6v3 save: CPU_XSAVE (XEN) HVM d6v0 save: VIRIDIAN_VCPU (XEN) HVM d6v1 save: VIRIDIAN_VCPU (XEN) HVM d6v2 save: VIRIDIAN_VCPU (XEN) HVM d6v3 save: VIRIDIAN_VCPU (XEN) HVM d6v0 save: VMCE_VCPU (XEN) HVM d6v1 save: VMCE_VCPU (XEN) HVM d6v2 save: VMCE_VCPU (XEN) HVM d6v3 save: VMCE_VCPU (XEN) HVM d6v0 save: TSC_ADJUST (XEN) HVM d6v1 save: TSC_ADJUST (XEN) HVM d6v2 save: TSC_ADJUST (XEN) HVM d6v3 save: TSC_ADJUST (XEN) HVM d6v0 save: CPU_MSR (XEN) HVM d6v1 save: CPU_MSR (XEN) HVM d6v2 save: CPU_MSR (XEN) HVM d6v3 save: CPU_MSR (XEN) HVM6 restore: CPU 0 (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=12 memflags=0xc0 (203 of 230) (d6) HVM Loader (d6) Detected Xen v4.18.4-pre (d6) Xenbus rings @0xfeffc000, event channel 1 (d6) System requested SeaBIOS (d6) CPU speed is 2195 MHz (d6) Relocating guest memory for lowmem MMIO space disabled (XEN) arch/x86/hvm/irq.c:367: Dom6 PCI link 0 changed 0 -> 5 (d6) PCI-ISA link 0 routed to IRQ5 (XEN) arch/x86/hvm/irq.c:367: Dom6 PCI link 1 changed 0 -> 10 (d6) PCI-ISA link 1 routed to IRQ10 (XEN) arch/x86/hvm/irq.c:367: Dom6 PCI link 2 changed 0 -> 11 (d6) PCI-ISA link 2 routed to IRQ11 (XEN) arch/x86/hvm/irq.c:367: Dom6 PCI link 3 changed 0 -> 5 (d6) PCI-ISA link 3 routed to IRQ5 (d6) pci dev 01:2 INTD->IRQ5 (d6) pci dev 01:3 INTA->IRQ10 (d6) pci dev 02:0 INTA->IRQ11 (d6) pci dev 03:0 INTA->IRQ5 (d6) pci dev 04:0 INTA->IRQ5 (d6) pci dev 06:0 INTA->IRQ11 (d6) pci dev 07:0 INTD->IRQ11 (d6) pci dev 08:0 INTA->IRQ5 (d6) pci dev 09:0 INTB->IRQ11 (d6) pci dev 0a:0 INTC->IRQ5 (d6) pci dev 0b:0 INTA->IRQ5 (d6) pci dev 0c:0 INTA->IRQ5 (d6) pci dev 0d:0 INTA->IRQ10 (d6) pci dev 0e:0 INTA->IRQ11 (d6) pci dev 0f:0 INTA->IRQ5 (d6) pci dev 10:0 INTA->IRQ5 (d6) pci dev 11:0 INTA->IRQ10 (d6) RAM in high memory; setting high_mem resource base to 9d3000000 (d6) pci dev 02:0 bar 14 size 001000000: 0f0000008 (d6) pci dev 05:0 bar 10 size 001000000: 0f1000008 (d6) pci dev 06:0 bar 30 size 000040000: 0f2000000 (d6) pci dev 05:0 bar 30 size 000010000: 0f2040000 (d6) pci dev 03:0 bar 10 size 000004000: 0f2050000 (d6) pci dev 04:0 bar 20 size 000004000: 0f205400c (d6) pci dev 04:0 bar 14 size 000001000: 0f2058000 (d6) pci dev 05:0 bar 18 size 000001000: 0f2059000 (d6) pci dev 07:0 bar 10 size 000001000: 0f205a000 (d6) pci dev 02:0 bar 10 size 000000100: 00000c001 (d6) pci dev 06:0 bar 10 size 000000100: 00000c101 (d6) pci dev 06:0 bar 14 size 000000100: 0f205b000 (d6) pci dev 04:0 bar 10 size 000000040: 00000c201 (d6) pci dev 01:2 bar 20 size 000000020: 00000c241 (d6) pci dev 08:0 bar 20 size 000000020: 00000c261 (d6) pci dev 09:0 bar 20 size 000000020: 00000c281 (d6) pci dev 0a:0 bar 20 size 000000020: 00000c2a1 (d6) pci dev 01:1 bar 20 size 000000010: 00000c2c1 (d6) pci dev 0b:0 bar 10 size 000000008: 00000c2d1 (d6) pci dev 0c:0 bar 10 size 000000008: 00000c2d9 (d6) pci dev 0d:0 bar 10 size 000000008: 00000c2e1 (d6) pci dev 0e:0 bar 10 size 000000008: 00000c2e9 (d6) pci dev 0f:0 bar 10 size 000000008: 00000c2f1 (d6) pci dev 10:0 bar 10 size 000000008: 00000c2f9 (d6) pci dev 11:0 bar 10 size 000000008: 00000c301 (d6) Multiprocessor initialisation: (d6) - CPU0 ... 46-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done. (d6) - CPU1 ... 46-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done. (d6) - CPU2 ... 46-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done. (d6) - CPU3 ... 46-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done. (d6) Writing SMBIOS tables ... (d6) Loading SeaBIOS ... (d6) Creating MP tables ... (d6) Loading ACPI ... (d6) vm86 TSS at fc100400 (d6) BIOS map: (d6) 10000-100e3: Scratch space (d6) c0000-fffff: Main BIOS (d6) E820 table: (d6) [00]: 00000000:00000000 - 00000000:000a0000: RAM (d6) HOLE: 00000000:000a0000 - 00000000:000c0000 (d6) [01]: 00000000:000c0000 - 00000000:00100000: RESERVED (d6) [02]: 00000000:00100000 - 00000000:f0000000: RAM (d6) HOLE: 00000000:f0000000 - 00000000:fc000000 (d6) [03]: 00000000:fc000000 - 00000000:fc00b000: NVS (d6) [04]: 00000000:fc00b000 - 00000001:00000000: RESERVED (d6) [05]: 00000001:00000000 - 00000009:d3000000: RAM (d6) Invoking SeaBIOS ... (d6) SeaBIOS (version rel-1.16.2-0-gea1b7a0-Xen) (d6) BUILD: gcc: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 binutils: (GNU Binutils for Ubuntu) 2.38 (d6) (d6) Found Xen hypervisor signature at 40000100 (d6) Running on QEMU (i440fx) (d6) xen: copy e820... (d6) Relocating init from 0x000d4760 to 0xeefeb2c0 (size 85152) (d6) Found 21 PCI devices (max PCI bus is 00) (d6) Allocated Xen hypercall page at effff000 (d6) Detected Xen v4.18.4-pre (d6) xen: copy BIOS tables... (d6) Copying SMBIOS from 0x00010020 to 0x000f5aa0 (d6) Copying MPTABLE from 0xfc100270/fc100280 to 0x000f5980 (d6) Copying PIR from 0x00010040 to 0x000f5900 (d6) Copying ACPI RSDP from 0x000100c0 to 0x000f58d0 (d6) table(50434146)=0xfc00a370 (via xsdt) (d6) Using pmtimer, ioport 0xb008 (d6) table(50434146)=0xfc00a370 (via xsdt) (d6) ACPI: parse DSDT at 0xfc001040 (len 37539) (d6) parse_termlist: parse error, skip from 16/27641 (d6) parse_termlist: parse error, skip from 87/6041 (d6) Scan for VGA option rom (d6) Running option rom at c000:0003 (d6) pmm call arg1=0 (d6) Turning on vga text mode console (d6) SeaBIOS (version rel-1.16.2-0-gea1b7a0-Xen) (d6) Machine UUID 1919b33b-e382-4473-b798-222d525f2309 (d6) EHCI init on dev 00:07.0 (regs=0xf205a020) (d6) UHCI init on dev 00:01.2 (io=c240) (d6) UHCI init on dev 00:08.0 (io=c260) (d6) UHCI init on dev 00:09.0 (io=c280) (d6) UHCI init on dev 00:0a.0 (io=c2a0) (d6) ATA controller 1 at 1f0/3f4/c2c0 (irq 14 dev 9) (d6) ATA controller 2 at 170/374/c2c8 (irq 15 dev 9) (d6) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (52000 MiBytes) (d6) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0 (d6) Searching bios-geometry for: /pci@i0cf8/*@1,1/drive@0/disk@0 (d6) Searching bootorder for: HALT (d6) Found 0 lpt ports (d6) Found 2 serial ports (d6) PS2 keyboard initialized (d6) All threads complete. (d6) Scan for option roms (d6) Running option rom at ca00:0003 (d6) pmm call arg1=1 (d6) pmm call arg1=0 (d6) pmm call arg1=1 (d6) pmm call arg1=0 (d6) Searching bootorder for: /pci@i0cf8/*@6 (d6) (d6) Press ESC for boot menu. (d6) (d6) Searching bootorder for: HALT (d6) drive 0x000f5850: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 s=106496000 (d6) Space available for UMB: cb000-e8800, f52c0-f5850 (d6) Returned 16773120 bytes of ZoneHigh (d6) e820 map has 8 items: (d6) 0: 0000000000000000 - 000000000009fc00 = 1 RAM (d6) 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED (d6) 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED (d6) 3: 0000000000100000 - 00000000effff000 = 1 RAM (d6) 4: 00000000effff000 - 00000000f0000000 = 2 RESERVED (d6) 5: 00000000fc000000 - 00000000fc00b000 = 4 NVS (d6) 6: 00000000fc00b000 - 0000000100000000 = 2 RESERVED (d6) 7: 0000000100000000 - 00000009d3000000 = 1 RAM (d6) enter handle_19: (d6) NULL (d6) Booting from Hard Disk... (d6) Booting from 0000:7c00 (d5) mapping kernel into physical memory (d5) about to get started... (d3) mapping kernel into physical memory (d3) about to get started... (XEN) arch/x86/pv/emul-priv-op.c:1017:d5v1 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d5v1 RDMSR 0x00000034 unimplemented (XEN) common/grant_table.c:1909:d5v1 Expanding d5 grant table from 1 to 2 frames (XEN) common/grant_table.c:1909:d5v1 Expanding d5 grant table from 2 to 3 frames (XEN) arch/x86/pv/emul-priv-op.c:1175:d5v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d5v1 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (d7) mapping kernel into physical memory (d7) about to get started... (XEN) arch/x86/pv/emul-priv-op.c:1017:d3v0 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d3v0 RDMSR 0x00000034 unimplemented (XEN) common/grant_table.c:1909:d3v0 Expanding d3 grant table from 1 to 2 frames (XEN) arch/x86/pv/emul-priv-op.c:1175:d3v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (d8) mapping kernel into physical memory (d8) about to get started... (XEN) arch/x86/pv/emul-priv-op.c:1017:d7v0 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d7v0 RDMSR 0x00000034 unimplemented (XEN) common/grant_table.c:1909:d7v1 Expanding d7 grant table from 1 to 2 frames (XEN) common/grant_table.c:1909:d7v1 Expanding d7 grant table from 2 to 3 frames (d9) mapping kernel into physical memory (d9) about to get started... (d4) mapping kernel into physical memory (d4) about to get started... (XEN) arch/x86/pv/emul-priv-op.c:1017:d8v0 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d8v0 RDMSR 0x00000034 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d7v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d7v1 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) common/grant_table.c:1909:d8v0 Expanding d8 grant table from 1 to 2 frames (d12) mapping kernel into physical memory (d12) about to get started... (d10) mapping kernel into physical memory (d10) about to get started... (XEN) arch/x86/pv/emul-priv-op.c:1175:d8v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d9v0 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d9v0 RDMSR 0x00000034 unimplemented (XEN) common/grant_table.c:1909:d9v0 Expanding d9 grant table from 1 to 2 frames (XEN) arch/x86/pv/emul-priv-op.c:1017:d4v0 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d4v0 RDMSR 0x00000034 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d12v0 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d12v0 RDMSR 0x00000034 unimplemented (XEN) common/grant_table.c:1909:d4v0 Expanding d4 grant table from 1 to 2 frames (XEN) common/grant_table.c:1909:d4v0 Expanding d4 grant table from 2 to 3 frames (XEN) arch/x86/pv/emul-priv-op.c:1175:d9v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 1 to 2 frames (XEN) arch/x86/pv/emul-priv-op.c:1017:d10v0 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d10v0 RDMSR 0x00000034 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d5v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d5v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d5v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d5v0 RDMSR 0x00000606 unimplemented (XEN) common/grant_table.c:1909:d5v0 Expanding d5 grant table from 3 to 4 frames (XEN) common/grant_table.c:1909:d10v0 Expanding d10 grant table from 1 to 2 frames (XEN) arch/x86/pv/emul-priv-op.c:1175:d4v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d4v1 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d12v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d10v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d5v1 RDMSR 0x000000b0 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d5v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d5v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d5v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d5v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d5v0 RDMSR 0x0000064d unimplemented (XEN) d6: VIRIDIAN GUEST_OS_ID: vendor: 0x1 os: 0x4 major: 0xa minor: 0 sp: 0 build: 0x271b (XEN) d6: VIRIDIAN HYPERCALL: enabled: 1 pfn: 0x215 (XEN) d6v0: VIRIDIAN VP_ASSIST: pfn: 0xc (XEN) d6: VIRIDIAN HVCALL_NOTIFY_LONG_SPIN_WAIT (XEN) d6: VIRIDIAN MSR_TIME_REF_COUNT: accessed (XEN) arch/x86/pv/emul-priv-op.c:1017:d7v1 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d7v1 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d7v1 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d7v1 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d3v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d3v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d3v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d3v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d7v1 RDMSR 0x000000b0 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d7v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d7v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d7v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d7v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d7v0 RDMSR 0x0000064d unimplemented (XEN) common/grant_table.c:1909:d7v1 Expanding d7 grant table from 3 to 4 frames (XEN) arch/x86/pv/emul-priv-op.c:1017:d3v0 RDMSR 0x000000b0 unimplemented (d11) mapping kernel into physical memory (d11) about to get started... (XEN) arch/x86/pv/emul-priv-op.c:1017:d4v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d4v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d4v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d4v0 RDMSR 0x00000606 unimplemented (XEN) common/grant_table.c:1909:d4v1 Expanding d4 grant table from 3 to 4 frames (XEN) d6v1: VIRIDIAN VP_ASSIST: pfn: 0x3ffff (XEN) d6v2: VIRIDIAN VP_ASSIST: pfn: 0x3fffe (XEN) d6v3: VIRIDIAN VP_ASSIST: pfn: 0x3ffef (XEN) arch/x86/pv/emul-priv-op.c:1017:d3v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d3v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d3v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d3v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d3v0 RDMSR 0x0000064d unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d4v0 RDMSR 0x000000b0 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d8v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d8v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d8v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d8v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d4v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d4v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d4v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d4v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d4v0 RDMSR 0x0000064d unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d9v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d9v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d9v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d9v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d8v0 RDMSR 0x000000b0 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d12v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d12v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d12v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d12v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/hvm/irq.c:367: Dom6 PCI link 0 changed 5 -> 0 (XEN) arch/x86/hvm/irq.c:367: Dom6 PCI link 1 changed 10 -> 0 (XEN) arch/x86/hvm/irq.c:367: Dom6 PCI link 2 changed 11 -> 0 (XEN) arch/x86/hvm/irq.c:367: Dom6 PCI link 3 changed 5 -> 0 (XEN) arch/x86/pv/emul-priv-op.c:1017:d10v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d10v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d10v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d10v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d8v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d8v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d8v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d8v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d8v0 RDMSR 0x0000064d unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d9v0 RDMSR 0x000000b0 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d11v1 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d11v1 RDMSR 0x00000034 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d11v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d11v1 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d12v0 RDMSR 0x000000b0 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d10v0 RDMSR 0x000000b0 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d9v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d9v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d9v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d9v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d9v0 RDMSR 0x0000064d unimplemented (XEN) d6v0: upcall vector a1 (XEN) d6v1: upcall vector a1 (XEN) d6v2: upcall vector a1 (XEN) d6v3: upcall vector a1 (XEN) Dom6 callback via changed to GSI 24 (XEN) arch/x86/pv/emul-priv-op.c:1017:d10v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d10v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d10v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d10v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d10v0 RDMSR 0x0000064d unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d12v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d12v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d12v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d12v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d12v0 RDMSR 0x0000064d unimplemented (XEN) common/grant_table.c:1909:d11v1 Expanding d11 grant table from 1 to 2 frames (XEN) arch/x86/pv/emul-priv-op.c:1017:d11v1 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d11v1 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d11v1 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d11v1 RDMSR 0x00000606 unimplemented (XEN) common/grant_table.c:1909:d11v0 Expanding d11 grant table from 2 to 3 frames (XEN) common/grant_table.c:1909:d11v0 Expanding d11 grant table from 3 to 4 frames (XEN) common/grant_table.c:1909:d11v0 Expanding d11 grant table from 4 to 5 frames (XEN) common/grant_table.c:1909:d11v0 Expanding d11 grant table from 5 to 6 frames (XEN) common/grant_table.c:1909:d11v0 Expanding d11 grant table from 6 to 7 frames (XEN) common/grant_table.c:1909:d11v0 Expanding d11 grant table from 7 to 8 frames (XEN) common/grant_table.c:1909:d11v0 Expanding d11 grant table from 8 to 9 frames (XEN) common/grant_table.c:1909:d11v0 Expanding d11 grant table from 9 to 10 frames (XEN) arch/x86/pv/emul-priv-op.c:1017:d11v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d11v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d11v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d11v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d11v0 RDMSR 0x0000064d unimplemented (XEN) common/grant_table.c:1909:d6v2 Expanding d6 grant table from 1 to 2 frames (XEN) arch/x86/hvm/vmx/vmx.c:3446:d6v2 RDMSR 0x0000019a unimplemented (XEN) arch/x86/hvm/vmx/vmx.c:3446:d6v2 RDMSR 0x0000019b unimplemented (XEN) arch/x86/hvm/vmx/vmx.c:3446:d6v1 RDMSR 0x0000019a unimplemented (XEN) arch/x86/hvm/vmx/vmx.c:3446:d6v1 RDMSR 0x0000019b unimplemented (XEN) common/grant_table.c:1909:d6v1 Expanding d6 grant table from 2 to 3 frames (XEN) d4 L1TF-vulnerable L1e d7ffe7fffffbc002 - Shadowing (XEN) arch/x86/pv/emul-priv-op.c:1017:d5v1 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d5v1 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d5v1 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d5v1 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d5v1 RDMSR 0x000000b0 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d7v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d7v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d7v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d7v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d7v0 RDMSR 0x000000b0 unimplemented (XEN) d8 L1TF-vulnerable L1e c7ffe7ffff988a02 - Shadowing (XEN) arch/x86/pv/emul-priv-op.c:1017:d4v1 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d4v1 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d4v1 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d4v1 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d4v0 RDMSR 0x000000b0 unimplemented (XEN) d10 L1TF-vulnerable L1e c7ffe7ffff987402 - Shadowing (XEN) d12 L1TF-vulnerable L1e c7ffe7ffff98a602 - Shadowing (XEN) arch/x86/pv/emul-priv-op.c:1017:d9v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d9v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d9v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d9v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d9v0 RDMSR 0x000000b0 unimplemented (XEN) d3 L1TF-vulnerable L1e d7ffe7fffff9c202 - Shadowing (XEN) arch/x86/pv/emul-priv-op.c:1017:d3v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d3v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d3v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d3v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d3v0 RDMSR 0x000000b0 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d12v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d12v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d12v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d12v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d12v0 RDMSR 0x000000b0 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d8v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d8v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d8v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d8v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d8v0 RDMSR 0x000000b0 unimplemented (XEN) common/grant_table.c:1909:d12v0 Expanding d12 grant table from 2 to 3 frames (XEN) arch/x86/pv/emul-priv-op.c:1017:d10v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d10v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d10v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d10v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d10v0 RDMSR 0x000000b0 unimplemented (XEN) d5 L1TF-vulnerable L1e c7ffe7ffff987602 - Shadowing ##### -> network driver domain (d2) has been started along with a few other vms root@intel-xen-host:~# xl info host : intel-xen-host release : 6.8.0-48-generic version : #48~22.04.1 SMP PREEMPT_DYNAMIC Thu Oct 24 08:09:57 UTC machine : x86_64 nr_cpus : 8 max_cpu_id : 7 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 2 cpu_mhz : 2194.844 hw_caps : bfebfbff:77fef3ff:2c100800:00000121:0000000f:d29ffffb:00000008:00000100 virt_caps : pv hvm hvm_directio pv_directio hap shadow iommu_hap_pt_share vmtrace gnttab-v1 gnttab-v2 total_memory : 65192 free_memory : 40549 sharing_freed_memory : 0 sharing_used_memory : 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 18 xen_extra : .4-pre xen_version : 4.18.4-pre xen_caps : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit2 xen_pagesize : 4096 platform_params : virt_start=0x0 xen_changeset : Fri Nov 15 14:07:55 2024 +0000 git:05ee7d9083-dirty xen_commandline : placeholder console=vga,com2 dom0_max_vcpus=4-8 dom0_mem=min:6144,max:65536m iommu=on,required,intpost,verbose,debug x2apic=off sched=credit2 flask=enforcing gnttab_max_frames=128 xpti=off smt=on cpufreq=xen:performance spec-ctrl=gds-mit=0 com2=115200,8n1 cc_compiler : gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 cc_compile_by : cc_compile_domain : cc_compile_date : Wed Nov 27 17:18:46 UTC 2024 build_id : 0adefb2a5aa28a52782a7c8481ebd48539af86d0 xend_config_format : 4 (XEN) d7 L1TF-vulnerable L1e c7ffe7ffff980c02 - Shadowing (XEN) d9 L1TF-vulnerable L1e c7ffe7ffff98b002 - Shadowing ##### -> memory for domU is changed to 40200 and the domain is restarted (XEN) d2: IOMMU mapping dfn f78b20 to mfn f78b20 failed: -12 (XEN) domain_crash called from drivers/passthrough/iommu.c:366 (XEN) Domain 2 (vcpu#0) crashed on cpu#3: (XEN) ----[ Xen-4.18.4-pre x86_64 debug=y Not tainted ]---- (XEN) CPU: 3 (XEN) RIP: e033:[] (XEN) RFLAGS: 0000000000000282 EM: 0 CONTEXT: pv guest (d2v0) (XEN) rax: 0000000000000014 rbx: ffffc900414b1000 rcx: ffffffff8220128c (XEN) rdx: 0000000000000001 rsi: ffffc900414bb018 rdi: 0000000000000000 (XEN) rbp: ffffc90040003e18 rsp: ffffc90040003dc8 r8: 0000000000000000 (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000282 (XEN) r12: 0000000000000001 r13: ffffc900414bb018 r14: ffffc900414b1000 (XEN) r15: 0000000000000000 cr0: 0000000080050033 cr4: 00000000003526e0 (XEN) cr3: 000000088ab0b000 cr2: 000079b3655f2fd8 (XEN) fsb: 0000000000000000 gsb: ffff888023000000 gss: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 (XEN) Guest stack trace from rsp=ffffc90040003dc8: (XEN) 0000000000000000 0000000000000001 ffffffff81a94320 0000000000000000 (XEN) ffffc900414be818 ffffc900414b1000 0000000000000000 0000000000000001 (XEN) ffffc900414b1000 0000000000000000 ffffc90040003e58 ffffffffc0542f35 (XEN) 0000000200000001 dbe37fd809e08800 ffffc900414b1030 0000000000000000 (XEN) 0000000000000040 ffffc900414b1000 ffffc90040003e88 ffffffffc05464ae (XEN) ffffc900414b1030 0000000000000000 ffffc90040003eef 0000000000000040 (XEN) ffffc90040003ec0 ffffffff81edef70 ffff888023035e40 000000000000012c (XEN) ffffc90040003ef8 ffffc900414b1030 0000000000000000 ffffc90040003f48 (XEN) ffffffff81edf551 ffffffff811b5c7f ffff888023036100 0000000100001212 (XEN) 0000000000000007 ffff888023031b60 ffffc90040003ef8 ffffc90040003ef8 (XEN) ffffc90040003f08 ffffc90040003f08 dbe37fd809e08800 0000000080000101 (XEN) 0000000000000003 0000000000000088 0000000000000004 ffffffff834060d8 (XEN) ffffc90040003fb8 ffffffff8110a198 ffff888023034200 0420000200000000 (XEN) ffffffff8340fcc0 0000000100001212 000000000000000a ffffc90000000003 (XEN) ffffffff81a9f77e ffffffff83403cc8 0000000000000001 0000000000000000 (XEN) 0000000000000000 0000000000000000 ffffc90040003fd8 ffffffff8110a4e9 (XEN) ffffffff83403cc8 0000000000000001 ffffc90040003fe8 ffffffff8110a84e (XEN) ffffffff83403cb8 ffffffff821ffd0a ffffffff83403ca0 (XEN) Fault while accessing guest memory. (XEN) common/memory.c:278:d0v2 Could not allocate order=18 extent: id=20 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=18 extent: id=20 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=18 extent: id=20 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=18 extent: id=20 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=18 extent: id=20 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=18 extent: id=20 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=18 extent: id=20 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=18 extent: id=20 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=18 extent: id=20 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=18 extent: id=20 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=18 extent: id=20 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=18 extent: id=20 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=20 memflags=0xc0 (0 of 4) (XEN) HVM d20v0 save: CPU (XEN) HVM d20v1 save: CPU (XEN) HVM d20v2 save: CPU (XEN) HVM d20v3 save: CPU (XEN) HVM d20 save: PIC (XEN) HVM d20 save: IOAPIC (XEN) HVM d20v0 save: LAPIC (XEN) HVM d20v1 save: LAPIC (XEN) HVM d20v2 save: LAPIC (XEN) HVM d20v3 save: LAPIC (XEN) HVM d20v0 save: LAPIC_REGS (XEN) HVM d20v1 save: LAPIC_REGS (XEN) HVM d20v2 save: LAPIC_REGS (XEN) HVM d20v3 save: LAPIC_REGS (XEN) HVM d20 save: PCI_IRQ (XEN) HVM d20 save: ISA_IRQ (XEN) HVM d20 save: PCI_LINK (XEN) HVM d20 save: PIT (XEN) HVM d20 save: RTC (XEN) HVM d20 save: HPET (XEN) HVM d20 save: PMTIMER (XEN) HVM d20v0 save: MTRR (XEN) HVM d20v1 save: MTRR (XEN) HVM d20v2 save: MTRR (XEN) HVM d20v3 save: MTRR (XEN) HVM d20 save: VIRIDIAN_DOMAIN (XEN) HVM d20v0 save: CPU_XSAVE (XEN) HVM d20v1 save: CPU_XSAVE (XEN) HVM d20v2 save: CPU_XSAVE (XEN) HVM d20v3 save: CPU_XSAVE (XEN) HVM d20v0 save: VIRIDIAN_VCPU (XEN) HVM d20v1 save: VIRIDIAN_VCPU (XEN) HVM d20v2 save: VIRIDIAN_VCPU (XEN) HVM d20v3 save: VIRIDIAN_VCPU (XEN) HVM d20v0 save: VMCE_VCPU (XEN) HVM d20v1 save: VMCE_VCPU (XEN) HVM d20v2 save: VMCE_VCPU (XEN) HVM d20v3 save: VMCE_VCPU (XEN) HVM d20v0 save: TSC_ADJUST (XEN) HVM d20v1 save: TSC_ADJUST (XEN) HVM d20v2 save: TSC_ADJUST (XEN) HVM d20v3 save: TSC_ADJUST (XEN) HVM d20v0 save: CPU_MSR (XEN) HVM d20v1 save: CPU_MSR (XEN) HVM d20v2 save: CPU_MSR (XEN) HVM d20v3 save: CPU_MSR (XEN) HVM20 restore: CPU 0 (XEN) [VT-D]d2:PCIe: unmap 0000:65:00.0 (XEN) [VT-D]d2:PCIe: unmap 0000:65:00.1 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x172 ref 0xf03 flags 0x12 d11 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x171 ref 0xf02 flags 0x12 d11 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x170 ref 0xf01 flags 0x12 d11 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x16f ref 0xf00 flags 0x12 d11 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x16e ref 0xb03 flags 0x12 d11 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x16d ref 0xb02 flags 0x12 d11 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x16c ref 0xb01 flags 0x12 d11 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x16b ref 0xb00 flags 0x12 d11 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x155 ref 0x20f flags 0x12 d12 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x154 ref 0x20e flags 0x12 d12 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x153 ref 0x413 flags 0x12 d7 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x152 ref 0x412 flags 0x12 d7 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x151 ref 0x411 flags 0x12 d7 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x150 ref 0x410 flags 0x12 d7 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x13c ref 0x413 flags 0x12 d5 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x13b ref 0x412 flags 0x12 d5 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x13a ref 0x411 flags 0x12 d5 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x139 ref 0x410 flags 0x12 d5 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x50 ref 0x1303 flags 0x12 d11 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x4f ref 0x1302 flags 0x12 d11 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x4e ref 0x1301 flags 0x12 d11 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x4d ref 0x1300 flags 0x12 d11 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x4c ref 0x703 flags 0x12 d11 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x4b ref 0x702 flags 0x12 d11 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x4a ref 0x701 flags 0x12 d11 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x49 ref 0x700 flags 0x12 d11 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x35 ref 0x20e flags 0x12 d10 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x34 ref 0x20d flags 0x12 d10 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x33 ref 0x417 flags 0x12 d4 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x32 ref 0x416 flags 0x12 d4 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x31 ref 0x415 flags 0x12 d4 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x30 ref 0x414 flags 0x12 d4 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x2f ref 0x20e flags 0x12 d9 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x2e ref 0x20d flags 0x12 d9 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x2d ref 0x20d flags 0x12 d8 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x2c ref 0x20c flags 0x12 d8 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x2b ref 0x20e flags 0x12 d3 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x2a ref 0x20d flags 0x12 d3 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x3 ref 0x40b flags 0x12 d0 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x2 ref 0x40a flags 0x12 d0 (XEN) common/grant_table.c:3861:d0v4 Grant release 0x1 ref 0x409 flags 0x12 d0 (XEN) common/grant_table.c:3861:d0v4 Grant release 0 ref 0x408 flags 0x12 d0 (XEN) [VT-D]d0:PCIe: map 0000:65:00.1 (XEN) [VT-D]d0:PCIe: map 0000:65:00.0 (XEN) [VT-D]d0:PCIe: unmap 0000:65:00.0 (XEN) [VT-D]d0:PCIe: unmap 0000:65:00.1 (XEN) [VT-D]d21:PCIe: map 0000:65:00.0 (XEN) [VT-D]d21:PCIe: map 0000:65:00.1 (d21) mapping kernel into physical memory (d21) about to get started... (XEN) arch/x86/pv/emul-priv-op.c:1017:d21v0 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d21v0 RDMSR 0x00000034 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d21v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d21v1 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d21v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d21v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d21v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d21v0 RDMSR 0x00000606 unimplemented (XEN) common/grant_table.c:1909:d21v0 Expanding d21 grant table from 1 to 2 frames (XEN) d21: Forcing read-only access to MFN e0e8c (XEN) d0: Forcing read-only access to MFN e0e8c (XEN) d21: Forcing read-only access to MFN e0e8c (XEN) arch/x86/pv/emul-priv-op.c:1017:d21v0 RDMSR 0x000000b0 unimplemented (XEN) d21: Forcing read-only access to MFN e0e88 (XEN) d0: Forcing read-only access to MFN e0e88 (XEN) d21: Forcing read-only access to MFN e0e88 (XEN) arch/x86/pv/emul-priv-op.c:1017:d21v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d21v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d21v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d21v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d21v0 RDMSR 0x0000064d unimplemented (XEN) d21 L1TF-vulnerable L1e c7ffefffff987e02 - Shadowing (XEN) d21 L1TF-vulnerable L1e c7ffefffff987e02 - Shadowing (XEN) arch/x86/pv/emul-priv-op.c:1017:d21v1 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d21v1 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d21v1 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d21v1 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d21v1 RDMSR 0x000000b0 unimplemented (XEN) common/memory.c:278:d0v1 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v1 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v1 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v4 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v4 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v5 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v5 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v5 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v5 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v5 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v5 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v5 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v5 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v5 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v5 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v5 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v5 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v5 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v1 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v1 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v1 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v1 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v1 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v5 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (1 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v3 Could not allocate order=9 extent: id=30 memflags=0xc0 (0 of 178) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=18 extent: id=24 memflags=0xc0 (0 of 1) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) common/memory.c:278:d0v2 Could not allocate order=9 extent: id=24 memflags=0xc0 (0 of 4) (XEN) HVM d24v0 save: CPU (XEN) HVM d24v1 save: CPU (XEN) HVM d24v2 save: CPU (XEN) HVM d24v3 save: CPU (XEN) HVM d24 save: PIC (XEN) HVM d24 save: IOAPIC (XEN) HVM d24v0 save: LAPIC (XEN) HVM d24v1 save: LAPIC (XEN) HVM d24v2 save: LAPIC (XEN) HVM d24v3 save: LAPIC (XEN) HVM d24v0 save: LAPIC_REGS (XEN) HVM d24v1 save: LAPIC_REGS (XEN) HVM d24v2 save: LAPIC_REGS (XEN) HVM d24v3 save: LAPIC_REGS (XEN) HVM d24 save: PCI_IRQ (XEN) HVM d24 save: ISA_IRQ (XEN) HVM d24 save: PCI_LINK (XEN) HVM d24 save: PIT (XEN) HVM d24 save: RTC (XEN) HVM d24 save: HPET (XEN) HVM d24 save: PMTIMER (XEN) HVM d24v0 save: MTRR (XEN) HVM d24v1 save: MTRR (XEN) HVM d24v2 save: MTRR (XEN) HVM d24v3 save: MTRR (XEN) HVM d24 save: VIRIDIAN_DOMAIN (XEN) HVM d24v0 save: CPU_XSAVE (XEN) HVM d24v1 save: CPU_XSAVE (XEN) HVM d24v2 save: CPU_XSAVE (XEN) HVM d24v3 save: CPU_XSAVE (XEN) HVM d24v0 save: VIRIDIAN_VCPU (XEN) HVM d24v1 save: VIRIDIAN_VCPU (XEN) HVM d24v2 save: VIRIDIAN_VCPU (XEN) HVM d24v3 save: VIRIDIAN_VCPU (XEN) HVM d24v0 save: VMCE_VCPU (XEN) HVM d24v1 save: VMCE_VCPU (XEN) HVM d24v2 save: VMCE_VCPU (XEN) HVM d24v3 save: VMCE_VCPU (XEN) HVM d24v0 save: TSC_ADJUST (XEN) HVM d24v1 save: TSC_ADJUST (XEN) HVM d24v2 save: TSC_ADJUST (XEN) HVM d24v3 save: TSC_ADJUST (XEN) HVM d24v0 save: CPU_MSR (XEN) HVM d24v1 save: CPU_MSR (XEN) HVM d24v2 save: CPU_MSR (XEN) HVM d24v3 save: CPU_MSR (XEN) HVM24 restore: CPU 0 (XEN) common/memory.c:278:d0v0 Could not allocate order=9 extent: id=31 memflags=0xc0 (0 of 230) (d24) HVM Loader (d24) Detected Xen v4.18.4-pre (d24) Xenbus rings @0xfeffc000, event channel 1 (d24) System requested SeaBIOS (d24) CPU speed is 2195 MHz (d24) Relocating guest memory for lowmem MMIO space disabled (XEN) arch/x86/hvm/irq.c:367: Dom24 PCI link 0 changed 0 -> 5 (d24) PCI-ISA link 0 routed to IRQ5 (XEN) arch/x86/hvm/irq.c:367: Dom24 PCI link 1 changed 0 -> 10 (d24) PCI-ISA link 1 routed to IRQ10 (XEN) arch/x86/hvm/irq.c:367: Dom24 PCI link 2 changed 0 -> 11 (d24) PCI-ISA link 2 routed to IRQ11 (XEN) arch/x86/hvm/irq.c:367: Dom24 PCI link 3 changed 0 -> 5 (d24) PCI-ISA link 3 routed to IRQ5 (d24) pci dev 01:2 INTD->IRQ5 (d24) pci dev 01:3 INTA->IRQ10 (d24) pci dev 02:0 INTA->IRQ11 (d24) pci dev 03:0 INTA->IRQ5 (d24) pci dev 04:0 INTA->IRQ5 (d24) pci dev 06:0 INTA->IRQ11 (d24) pci dev 07:0 INTD->IRQ11 (d24) pci dev 08:0 INTA->IRQ5 (d24) pci dev 09:0 INTB->IRQ11 (d24) pci dev 0a:0 INTC->IRQ5 (d24) pci dev 0b:0 INTA->IRQ5 (d24) pci dev 0c:0 INTA->IRQ5 (d24) pci dev 0d:0 INTA->IRQ10 (d24) pci dev 0e:0 INTA->IRQ11 (d24) pci dev 0f:0 INTA->IRQ5 (d24) pci dev 10:0 INTA->IRQ5 (d24) pci dev 11:0 INTA->IRQ10 (d24) RAM in high memory; setting high_mem resource base to 9df800000 (d24) pci dev 02:0 bar 14 size 001000000: 0f0000008 (d24) pci dev 05:0 bar 10 size 001000000: 0f1000008 (d24) pci dev 06:0 bar 30 size 000040000: 0f2000000 (d24) pci dev 05:0 bar 30 size 000010000: 0f2040000 (d24) pci dev 03:0 bar 10 size 000004000: 0f2050000 (d24) pci dev 04:0 bar 20 size 000004000: 0f205400c (d24) pci dev 04:0 bar 14 size 000001000: 0f2058000 (d24) pci dev 05:0 bar 18 size 000001000: 0f2059000 (d24) pci dev 07:0 bar 10 size 000001000: 0f205a000 (d24) pci dev 02:0 bar 10 size 000000100: 00000c001 (d24) pci dev 06:0 bar 10 size 000000100: 00000c101 (d24) pci dev 06:0 bar 14 size 000000100: 0f205b000 (d24) pci dev 04:0 bar 10 size 000000040: 00000c201 (d24) pci dev 01:2 bar 20 size 000000020: 00000c241 (d24) pci dev 08:0 bar 20 size 000000020: 00000c261 (d24) pci dev 09:0 bar 20 size 000000020: 00000c281 (d24) pci dev 0a:0 bar 20 size 000000020: 00000c2a1 (d24) pci dev 01:1 bar 20 size 000000010: 00000c2c1 (d24) pci dev 0b:0 bar 10 size 000000008: 00000c2d1 (d24) pci dev 0c:0 bar 10 size 000000008: 00000c2d9 (d24) pci dev 0d:0 bar 10 size 000000008: 00000c2e1 (d24) pci dev 0e:0 bar 10 size 000000008: 00000c2e9 (d24) pci dev 0f:0 bar 10 size 000000008: 00000c2f1 (d24) pci dev 10:0 bar 10 size 000000008: 00000c2f9 (d24) pci dev 11:0 bar 10 size 000000008: 00000c301 (d24) Multiprocessor initialisation: (d24) - CPU0 ... 46-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done. (d24) - CPU1 ... 46-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done. (d24) - CPU2 ... 46-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done. (d24) - CPU3 ... 46-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done. (d24) Writing SMBIOS tables ... (d24) Loading SeaBIOS ... (d24) Creating MP tables ... (d24) Loading ACPI ... (d24) vm86 TSS at fc100400 (d24) BIOS map: (d24) 10000-100e3: Scratch space (d24) c0000-fffff: Main BIOS (d24) E820 table: (d24) [00]: 00000000:00000000 - 00000000:000a0000: RAM (d24) HOLE: 00000000:000a0000 - 00000000:000c0000 (d24) [01]: 00000000:000c0000 - 00000000:00100000: RESERVED (d24) [02]: 00000000:00100000 - 00000000:f0000000: RAM (d24) HOLE: 00000000:f0000000 - 00000000:fc000000 (d24) [03]: 00000000:fc000000 - 00000000:fc00b000: NVS (d24) [04]: 00000000:fc00b000 - 00000001:00000000: RESERVED (d24) [05]: 00000001:00000000 - 00000009:df800000: RAM (d24) Invoking SeaBIOS ... (d24) SeaBIOS (version rel-1.16.2-0-gea1b7a0-Xen) (d24) BUILD: gcc: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 binutils: (GNU Binutils for Ubuntu) 2.38 (d24) (d24) Found Xen hypervisor signature at 40000100 (d24) Running on QEMU (i440fx) (d24) xen: copy e820... (d24) Relocating init from 0x000d4760 to 0xeefeb2c0 (size 85152) (d24) Found 21 PCI devices (max PCI bus is 00) (d24) Allocated Xen hypercall page at effff000 (d24) Detected Xen v4.18.4-pre (d24) xen: copy BIOS tables... (d24) Copying SMBIOS from 0x00010020 to 0x000f5aa0 (d24) Copying MPTABLE from 0xfc100270/fc100280 to 0x000f5980 (d24) Copying PIR from 0x00010040 to 0x000f5900 (d24) Copying ACPI RSDP from 0x000100c0 to 0x000f58d0 (d24) table(50434146)=0xfc00a370 (via xsdt) (d24) Using pmtimer, ioport 0xb008 (d24) table(50434146)=0xfc00a370 (via xsdt) (d24) ACPI: parse DSDT at 0xfc001040 (len 37539) (d24) parse_termlist: parse error, skip from 16/27641 (d24) parse_termlist: parse error, skip from 87/6041 (d24) Scan for VGA option rom (d24) Running option rom at c000:0003 (d24) pmm call arg1=0 (d24) Turning on vga text mode console (d24) SeaBIOS (version rel-1.16.2-0-gea1b7a0-Xen) (d24) Machine UUID 1919b33b-e382-4473-b798-222d525f2309 (d24) EHCI init on dev 00:07.0 (regs=0xf205a020) (d24) UHCI init on dev 00:01.2 (io=c240) (d24) UHCI init on dev 00:08.0 (io=c260) (d24) UHCI init on dev 00:09.0 (io=c280) (d24) UHCI init on dev 00:0a.0 (io=c2a0) (d24) ATA controller 1 at 1f0/3f4/c2c0 (irq 14 dev 9) (d24) ATA controller 2 at 170/374/c2c8 (irq 15 dev 9) (d24) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (52000 MiBytes) (d24) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0 (d24) Searching bios-geometry for: /pci@i0cf8/*@1,1/drive@0/disk@0 (d24) Searching bootorder for: HALT (d24) Found 0 lpt ports (d24) Found 2 serial ports (d24) PS2 keyboard initialized (d24) All threads complete. (d24) Scan for option roms (d24) Running option rom at ca00:0003 (d24) pmm call arg1=1 (d24) pmm call arg1=0 (d24) pmm call arg1=1 (d24) pmm call arg1=0 (d24) Searching bootorder for: /pci@i0cf8/*@6 (d24) (d24) Press ESC for boot menu. (d24) (d24) Searching bootorder for: HALT (d24) drive 0x000f5850: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 s=106496000 (d24) Space available for UMB: cb000-e8800, f52c0-f5850 (d24) Returned 16773120 bytes of ZoneHigh (d24) e820 map has 8 items: (d24) 0: 0000000000000000 - 000000000009fc00 = 1 RAM (d24) 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED (d24) 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED (d24) 3: 0000000000100000 - 00000000effff000 = 1 RAM (d24) 4: 00000000effff000 - 00000000f0000000 = 2 RESERVED (d24) 5: 00000000fc000000 - 00000000fc00b000 = 4 NVS (d24) 6: 00000000fc00b000 - 0000000100000000 = 2 RESERVED (d24) 7: 0000000100000000 - 00000009df800000 = 1 RAM (d24) enter handle_19: (d24) NULL (d24) Booting from Hard Disk... (d24) Booting from 0000:7c00 (d22) mapping kernel into physical memory (d22) about to get started... (XEN) arch/x86/pv/emul-priv-op.c:1017:d22v1 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d22v1 RDMSR 0x00000034 unimplemented (XEN) common/grant_table.c:1909:d22v0 Expanding d22 grant table from 1 to 2 frames (XEN) common/grant_table.c:1909:d22v0 Expanding d22 grant table from 2 to 3 frames (XEN) arch/x86/pv/emul-priv-op.c:1175:d22v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d22v1 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) common/grant_table.c:1909:d22v0 Expanding d22 grant table from 3 to 4 frames (d23) mapping kernel into physical memory (d23) about to get started... (d26) mapping kernel into physical memory (d26) about to get started... (XEN) arch/x86/pv/emul-priv-op.c:1017:d23v0 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d23v0 RDMSR 0x00000034 unimplemented (XEN) common/grant_table.c:1909:d23v0 Expanding d23 grant table from 1 to 2 frames (XEN) arch/x86/pv/emul-priv-op.c:1175:d23v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (d27) mapping kernel into physical memory (d27) about to get started... (XEN) arch/x86/pv/emul-priv-op.c:1017:d22v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d22v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d22v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d22v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d22v1 RDMSR 0x000000b0 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d26v0 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d26v0 RDMSR 0x00000034 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d22v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d22v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d22v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d22v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d22v0 RDMSR 0x0000064d unimplemented (XEN) common/grant_table.c:1909:d26v1 Expanding d26 grant table from 1 to 2 frames (XEN) common/grant_table.c:1909:d26v1 Expanding d26 grant table from 2 to 3 frames (d25) mapping kernel into physical memory (d25) about to get started... (XEN) arch/x86/pv/emul-priv-op.c:1175:d26v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d26v1 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d27v0 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d27v0 RDMSR 0x00000034 unimplemented (XEN) common/grant_table.c:1909:d27v0 Expanding d27 grant table from 1 to 2 frames (d30) mapping kernel into physical memory (d30) about to get started... (XEN) arch/x86/pv/emul-priv-op.c:1175:d27v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) d24: VIRIDIAN GUEST_OS_ID: vendor: 0x1 os: 0x4 major: 0xa minor: 0 sp: 0 build: 0x271b (XEN) d24: VIRIDIAN HYPERCALL: enabled: 1 pfn: 0x215 (XEN) d24v0: VIRIDIAN VP_ASSIST: pfn: 0xc (XEN) d24: VIRIDIAN HVCALL_NOTIFY_LONG_SPIN_WAIT (XEN) d24: VIRIDIAN MSR_TIME_REF_COUNT: accessed (d29) mapping kernel into physical memory (d29) about to get started... (XEN) arch/x86/pv/emul-priv-op.c:1017:d25v0 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d25v0 RDMSR 0x00000034 unimplemented (d31) mapping kernel into physical memory (d31) about to get started... (XEN) common/grant_table.c:1909:d25v0 Expanding d25 grant table from 1 to 2 frames (XEN) arch/x86/pv/emul-priv-op.c:1017:d30v0 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d30v0 RDMSR 0x00000034 unimplemented (XEN) common/grant_table.c:1909:d30v0 Expanding d30 grant table from 1 to 2 frames (XEN) arch/x86/pv/emul-priv-op.c:1175:d25v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d30v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d29v0 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d29v0 RDMSR 0x00000034 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d31v0 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d31v0 RDMSR 0x00000034 unimplemented (XEN) common/grant_table.c:1909:d29v1 Expanding d29 grant table from 1 to 2 frames (XEN) common/grant_table.c:1909:d29v1 Expanding d29 grant table from 2 to 3 frames (XEN) common/grant_table.c:1909:d31v0 Expanding d31 grant table from 1 to 2 frames (XEN) arch/x86/pv/emul-priv-op.c:1175:d29v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d29v1 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d31v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d26v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d26v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d26v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d26v0 RDMSR 0x00000606 unimplemented (XEN) d24v1: VIRIDIAN VP_ASSIST: pfn: 0x3ffff (XEN) d24v2: VIRIDIAN VP_ASSIST: pfn: 0x3fffe (XEN) d24v3: VIRIDIAN VP_ASSIST: pfn: 0x3ffef (XEN) arch/x86/pv/emul-priv-op.c:1017:d23v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d23v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d23v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d23v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d26v1 RDMSR 0x000000b0 unimplemented (XEN) common/grant_table.c:1909:d29v0 Expanding d29 grant table from 3 to 4 frames (XEN) arch/x86/pv/emul-priv-op.c:1017:d26v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d26v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d26v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d26v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d26v0 RDMSR 0x0000064d unimplemented (XEN) common/grant_table.c:1909:d26v1 Expanding d26 grant table from 3 to 4 frames (XEN) arch/x86/pv/emul-priv-op.c:1017:d23v0 RDMSR 0x000000b0 unimplemented (d28) mapping kernel into physical memory (d28) about to get started... (XEN) arch/x86/hvm/irq.c:367: Dom24 PCI link 0 changed 5 -> 0 (XEN) arch/x86/hvm/irq.c:367: Dom24 PCI link 1 changed 10 -> 0 (XEN) arch/x86/hvm/irq.c:367: Dom24 PCI link 2 changed 11 -> 0 (XEN) arch/x86/hvm/irq.c:367: Dom24 PCI link 3 changed 5 -> 0 (XEN) arch/x86/pv/emul-priv-op.c:1017:d23v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d23v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d23v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d23v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d23v0 RDMSR 0x0000064d unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d27v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d27v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d27v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d27v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d29v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d29v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d29v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d29v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d27v0 RDMSR 0x000000b0 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d29v1 RDMSR 0x000000b0 unimplemented (XEN) d24v0: upcall vector a1 (XEN) d24v1: upcall vector a1 (XEN) d24v2: upcall vector a1 (XEN) d24v3: upcall vector a1 (XEN) Dom24 callback via changed to GSI 24 (XEN) arch/x86/pv/emul-priv-op.c:1017:d29v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d29v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d29v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d29v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d29v0 RDMSR 0x0000064d unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d25v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d25v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d25v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d25v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d30v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d30v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d30v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d30v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d27v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d27v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d27v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d27v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d27v0 RDMSR 0x0000064d unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d28v0 RDMSR 0x0000064e unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d28v0 RDMSR 0x00000034 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d28v0 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1175:d28v1 WRMSR 0x00000150 val 0x8000001c00000000 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d25v0 RDMSR 0x000000b0 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d31v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d31v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d31v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d31v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d30v0 RDMSR 0x000000b0 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d25v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d25v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d25v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d25v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d25v0 RDMSR 0x0000064d unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d30v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d30v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d30v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d30v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d30v0 RDMSR 0x0000064d unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d31v0 RDMSR 0x000000b0 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d31v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d31v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d31v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d31v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d31v0 RDMSR 0x0000064d unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d28v1 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d28v1 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d28v1 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d28v1 RDMSR 0x00000606 unimplemented (XEN) common/grant_table.c:1909:d28v0 Expanding d28 grant table from 1 to 2 frames (XEN) common/grant_table.c:1909:d28v0 Expanding d28 grant table from 2 to 3 frames (XEN) common/grant_table.c:1909:d28v0 Expanding d28 grant table from 3 to 4 frames (XEN) common/grant_table.c:1909:d28v0 Expanding d28 grant table from 4 to 5 frames (XEN) common/grant_table.c:1909:d28v0 Expanding d28 grant table from 5 to 6 frames (XEN) common/grant_table.c:1909:d28v0 Expanding d28 grant table from 6 to 7 frames (XEN) common/grant_table.c:1909:d28v0 Expanding d28 grant table from 7 to 8 frames (XEN) common/grant_table.c:1909:d28v0 Expanding d28 grant table from 8 to 9 frames (XEN) common/grant_table.c:1909:d24v1 Expanding d24 grant table from 1 to 2 frames (XEN) common/grant_table.c:1909:d28v0 Expanding d28 grant table from 9 to 10 frames (XEN) arch/x86/hvm/vmx/vmx.c:3446:d24v0 RDMSR 0x0000019a unimplemented (XEN) arch/x86/hvm/vmx/vmx.c:3446:d24v0 RDMSR 0x0000019b unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d28v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d28v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d28v0 RDMSR 0x00000641 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d28v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d28v0 RDMSR 0x0000064d unimplemented (XEN) arch/x86/hvm/vmx/vmx.c:3446:d24v1 RDMSR 0x0000019a unimplemented (XEN) arch/x86/hvm/vmx/vmx.c:3446:d24v1 RDMSR 0x0000019b unimplemented (XEN) common/grant_table.c:1909:d24v1 Expanding d24 grant table from 2 to 3 frames (XEN) arch/x86/pv/emul-priv-op.c:1017:d22v1 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d22v1 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d22v1 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d22v1 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d22v0 RDMSR 0x000000b0 unimplemented (XEN) d29 L1TF-vulnerable L1e c7ffe7ffff981202 - Shadowing (XEN) arch/x86/pv/emul-priv-op.c:1017:d26v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d26v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d26v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d26v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d26v1 RDMSR 0x000000b0 unimplemented (XEN) d30 L1TF-vulnerable L1e c7ffe7ffff987c02 - Shadowing (XEN) arch/x86/pv/emul-priv-op.c:1017:d29v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d29v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d29v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d29v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d29v1 RDMSR 0x000000b0 unimplemented (XEN) d25 L1TF-vulnerable L1e c7ffe7ffff987402 - Shadowing (XEN) d27 L1TF-vulnerable L1e c7ffe7ffff987602 - Shadowing (XEN) common/grant_table.c:1909:d28v0 Expanding d28 grant table from 10 to 11 frames (XEN) d31 L1TF-vulnerable L1e c7ffe7ffff98a002 - Shadowing (XEN) arch/x86/pv/emul-priv-op.c:1017:d23v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d23v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d23v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d23v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d23v0 RDMSR 0x000000b0 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d31v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d31v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d31v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d31v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d31v0 RDMSR 0x000000b0 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d27v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d27v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d27v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d27v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d30v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d30v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d30v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d30v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d27v0 RDMSR 0x000000b0 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d30v0 RDMSR 0x000000b0 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d25v0 RDMSR 0x00000639 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d25v0 RDMSR 0x00000611 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d25v0 RDMSR 0x00000619 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d25v0 RDMSR 0x00000606 unimplemented (XEN) arch/x86/pv/emul-priv-op.c:1017:d25v0 RDMSR 0x000000b0 unimplemented (XEN) d26 L1TF-vulnerable L1e c7ffe7ffff8ee802 - Shadowing (XEN) d22 L1TF-vulnerable L1e c7ffe7ffff988402 - Shadowing ##### -> our domain orchestration tool has cleaned up and is starting the driver domain again ##### -> after recovery the 'big' guest has started ok suggesting the ordering is significant root@intel-xen-host:~# xl list Name ID Mem VCPUs State Time(s) Domain-0 0 16298 6 r----- 1586.0 Xenstore 1 64 1 -b---- 10.5 netdd 21 576 2 -b---- 69.1 infra01 22 800 2 ------ 50.7 infra02 23 750 1 r----- 27.6 payload01 24 40200 4 ------ 23.7 infra03 25 384 1 r----- 25.2 infra04 26 1400 2 r----- 41.3 infra05 27 384 1 ------ 26.0 infra06 28 2048 2 r----- 33.0 infra07 29 448 2 ------ 36.6 infra08 30 356 1 r----- 24.8 infra09 31 460 1 ------ 23.9 root@intel-xen-host:~# xl info host : intel-xen-host release : 6.8.0-48-generic version : #48~22.04.1 SMP PREEMPT_DYNAMIC Thu Oct 24 08:09:57 UTC machine : x86_64 nr_cpus : 8 max_cpu_id : 7 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 2 cpu_mhz : 2194.844 hw_caps : bfebfbff:77fef3ff:2c100800:00000121:0000000f:d29ffffb:00000008:00000100 virt_caps : pv hvm hvm_directio pv_directio hap shadow iommu_hap_pt_share vmtrace gnttab-v1 gnttab-v2 total_memory : 65192 free_memory : 183 sharing_freed_memory : 0 sharing_used_memory : 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 18 xen_extra : .4-pre xen_version : 4.18.4-pre xen_caps : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit2 xen_pagesize : 4096 platform_params : virt_start=0x0 xen_changeset : Fri Nov 15 14:07:55 2024 +0000 git:05ee7d9083-dirty xen_commandline : placeholder console=vga,com2 dom0_max_vcpus=4-8 dom0_mem=min:6144,max:65536m iommu=on,required,intpost,verbose,debug x2apic=off sched=credit2 flask=enforcing gnttab_max_frames=128 xpti=off smt=on cpufreq=xen:performance spec-ctrl=gds-mit=0 com2=115200,8n1 cc_compiler : gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 cc_compile_by : cc_compile_domain : cc_compile_date : Wed Nov 27 17:18:46 UTC 2024 build_id : 0adefb2a5aa28a52782a7c8481ebd48539af86d0 xend_config_format : 4 ##### -> if the big guest memory is set to 40500 xl reports: xc: error: panic: xg_dom_boot.c:119: xc_dom_boot_mem_init: can't allocate low memory for domain: Out of memory libxl: error: libxl_dom.c:581:libxl__build_dom: xc_dom_boot_mem_init failed: Cannot allocate memory libxl: error: libxl_create.c:1662:domcreate_rebuild_done: Domain 32:cannot (re-)build domain: -3 libxl: error: libxl_domain.c:354:libxl_domain_info: Domain 32:Getting domain info: No such process libxl: error: libxl_domain.c:1245:libxl__destroy_domid: Domain 32:Non-existant domain libxl: error: libxl_domain.c:1199:domain_destroy_callback: Domain 32:Unable to destroy guest libxl: error: libxl_domain.c:1126:domain_destroy_cb: Domain 32:Destruction of domain failed --mynTevqUIMXVj7cQ-- From xen-devel-bounces@lists.xenproject.org Mon Dec 02 16:59:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 16:59:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846764.1261931 (Exim 4.92) (envelope-from ) id 1tI9lk-0007eq-Ji; Mon, 02 Dec 2024 16:59:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846764.1261931; Mon, 02 Dec 2024 16:59: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 1tI9lk-0007eb-Gc; Mon, 02 Dec 2024 16:59:32 +0000 Received: by outflank-mailman (input) for mailman id 846764; Mon, 02 Dec 2024 16:59: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 1tI9li-0006wq-DJ for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 16:59:30 +0000 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [2a00:1450:4864:20::131]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cb840a3a-b0ce-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 17:59:29 +0100 (CET) Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-53df67d6659so6805931e87.3 for ; Mon, 02 Dec 2024 08:59:29 -0800 (PST) Received: from carlo-ubuntu.home.arpa (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5998e64c4sm526802666b.97.2024.12.02.08.59.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 08:59: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: cb840a3a-b0ce-11ef-a0d2-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1733158769; x=1733763569; 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=f+tyePsYcLfjXIwoyPcyVhlRR1rCp6P8smeteExEhoc=; b=Ugyzb1brD6MFs42axqquuGznUi3WpDPNFShOSo1N+ZbkIJpmOneOV0X+Uhb2walngJ C7dCMcQ/nltrsEFBCl+ghyDVro3LSYogv6uy92GinlLU0Vx1z/fOueCxxzR9h0Pj5Vgv lOqDnxSsrO8uT33+qiSw3JE3jMiYX9xXgjOAtaD0Htj/b+2xQUVbN/UbWAfDXHdD2+2q JvnU6OatehL0e20fqoTtN3Ri3IwP6/fy4VkgFvxO+kHSQjBVLPh2iRo8/rG2lUak612f bQqXb2TprN5Q0ea/ghu8XZJs+2T3fq6eQJT8SfC1BAN979wOdzLS4Eq8xO4ZGYMI+TYl E8XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733158769; x=1733763569; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=f+tyePsYcLfjXIwoyPcyVhlRR1rCp6P8smeteExEhoc=; b=fEZPmXaDttQQW6c+DCmjVyODt2OZ511PZDU3nidGWELL4N4FsW7plFDobUSK+JEPIu urqj/2r1iCUubT1avD8sziCxaTRQc8tsSg6IeIzVxkXlnqUoW3RMh1SV6WtulumFY0hA a8PMmcRHvf5rPzP73Q3bz12kq10P/tIvC5YAk44bnifM/5HIqEvpwVj7r4yS+NrxbkYX 8J4c+0JTo6AitwvZ82zPNfwC4UziMKFiuPzofySlAewlvCsk3yGRAfnJhUfoANagg7r/ mhQx8WYoduVgualx5ZiPtnKPsGKw4rqOdporiRATOOe8fKwfbZ5jynO77HEo93nOr1q5 qcSA== X-Gm-Message-State: AOJu0YzF8xb+A/Nv0l3zJ/iJ3ZIhu52zmWPvmTXnioO3tSQJW7R7d667 l+QdutWXCHMjXGQ8QYjUnz24VmDWCb7Wm4ZBpSNz3OZMcmhWYC1eIxfmBPSQB7pCWLc43QKSI4U h X-Gm-Gg: ASbGnctinbbUXRmeLrVGGx2Yk8Gqgd6a5DRyLNJ6pQePBZWc1Q+oKm4LSaxizL9zpKj lr2GKvGU4EUmvP88spisb7mewUMPZHVfUcBUe1gKUfPG6qpN9Jnovba8dd1ogsxqnWz5NpGGtxI sJiZFHn3yR5jHnXJRIdutdIstbPA2Mp01ENkLlldPgA8JOm9GT++XeGaCsa3G3p+QYcLeycCQYE 5TdfBhoAMoN/EuvzapYQ2phzpjGv8T4XWVQ+c44KbucllO5CLlY2ppNvaLY5+nV6ZgoyBEE5TDc Yp+/CrO8n5EWyju3vclV47vvY1zw/jFSfKDgws/Wex2Q67rVhkIF X-Google-Smtp-Source: AGHT+IEU8H5NoSdw3aNt7spYNOY0Mw2YbA0JS1+Va/g8Yz/R+xHt3Znt9iJeAGBGJtmADcICqNJniQ== X-Received: by 2002:a05:6512:3994:b0:53d:a025:1142 with SMTP id 2adb3069b0e04-53df01172c2mr18687189e87.54.1733158768743; Mon, 02 Dec 2024 08:59:28 -0800 (PST) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Carlo Nonato , Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v11 04/12] xen/arm: add Dom0 cache coloring support Date: Mon, 2 Dec 2024 17:59:13 +0100 Message-ID: <20241202165921.249585-5-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241202165921.249585-1-carlo.nonato@minervasys.tech> References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add a command line parameter to allow the user to set the coloring configuration for Dom0. A common configuration syntax for cache colors is introduced and documented. Take the opportunity to also add: - default configuration notion. - function to check well-formed configurations. Direct mapping Dom0 isn't possible when coloring is enabled, so CDF_directmap flag is removed when creating it. Based on original work from: Luca Miccio Signed-off-by: Carlo Nonato Signed-off-by: Marco Solieri Reviewed-by: Jan Beulich Reviewed-by: Michal Orzel --- v11: - minor changes v10: - fixed array type for colors parameter in check_colors() v9: - moved domain_llc_coloring_free() in next patch cause it's never used for dom0 v8: - added bound check on dom0_num_colors - default colors array set just once v7: - parse_color_config() doesn't accept leading/trailing commas anymore - removed alloc_colors() helper v6: - moved domain_llc_coloring_free() in this patch - removed domain_alloc_colors() in favor of a more explicit allocation - parse_color_config() now accepts the size of the array to be filled - allocate_memory() moved in another patch v5: - Carlo Nonato as the new author - moved dom0 colors parsing (parse_colors()) in this patch - added dom0_set_llc_colors() to set dom0 colors after creation - moved color allocation and checking in this patch - error handling when allocating color arrays - FIXME: copy pasted allocate_memory() cause it got moved v4: - dom0 colors are dynamically allocated as for any other domain (colors are duplicated in dom0_colors and in the new array, but logic is simpler) --- docs/misc/cache-coloring.rst | 29 ++++++++ docs/misc/xen-command-line.pandoc | 9 +++ xen/arch/arm/domain_build.c | 10 ++- xen/common/llc-coloring.c | 120 +++++++++++++++++++++++++++++- xen/include/xen/llc-coloring.h | 1 + 5 files changed, 167 insertions(+), 2 deletions(-) diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst index 12972dbb2c..7b47d0ed92 100644 --- a/docs/misc/cache-coloring.rst +++ b/docs/misc/cache-coloring.rst @@ -107,6 +107,35 @@ Specific documentation is available at `docs/misc/xen-command-line.pandoc`. +----------------------+-------------------------------+ | ``llc-nr-ways`` | Set the LLC number of ways | +----------------------+-------------------------------+ +| ``dom0-llc-colors`` | Dom0 color configuration | ++----------------------+-------------------------------+ + +Colors selection format +*********************** + +Regardless of the memory pool that has to be colored (Xen, Dom0/DomUs), +the color selection can be expressed using the same syntax. In particular a +comma-separated list of colors or ranges of colors is used. +Ranges are hyphen-separated intervals (such as `0-4`) and are inclusive on both +sides. + +Note that: + +- no spaces are allowed between values. +- no overlapping ranges or duplicated colors are allowed. +- values must be written in ascending order. + +Examples: + ++-------------------+-----------------------------+ +| **Configuration** | **Actual selection** | ++-------------------+-----------------------------+ +| 1-2,5-8 | [1, 2, 5, 6, 7, 8] | ++-------------------+-----------------------------+ +| 4-8,10,11,12 | [4, 5, 6, 7, 8, 10, 11, 12] | ++-------------------+-----------------------------+ +| 0 | [0] | ++-------------------+-----------------------------+ Auto-probing of LLC specs ######################### diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index abd8dae96f..bfdc8b0002 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -963,6 +963,15 @@ Controls for the dom0 IOMMU setup. Specify a list of IO ports to be excluded from dom0 access. +### dom0-llc-colors (arm64) +> `= List of [ | - ]` + +> Default: `All available LLC colors` + +Specify dom0 LLC color configuration. This option is available only when +`CONFIG_LLC_COLORING` is enabled. If the parameter is not set, all available +colors are used. + ### dom0_max_vcpus Either: diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 2b8cba9b2f..83d7585e7e 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -2,6 +2,7 @@ #include #include #include +#include #include #include #include @@ -2285,6 +2286,7 @@ void __init create_dom0(void) .max_maptrack_frames = -1, .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version), }; + unsigned int flags = CDF_privileged; int rc; /* The vGIC for DOM0 is exactly emulating the hardware GIC */ @@ -2312,10 +2314,16 @@ void __init create_dom0(void) panic("SVE vector length error\n"); } - dom0 = domain_create(0, &dom0_cfg, CDF_privileged | CDF_directmap); + if ( !llc_coloring_enabled ) + flags |= CDF_directmap; + + dom0 = domain_create(0, &dom0_cfg, flags); if ( IS_ERR(dom0) ) panic("Error creating domain 0 (rc = %ld)\n", PTR_ERR(dom0)); + if ( llc_coloring_enabled && (rc = dom0_set_llc_colors(dom0)) ) + panic("Error initializing LLC coloring for domain 0 (rc = %d)\n", rc); + if ( alloc_dom0_vcpu0(dom0) == NULL ) panic("Error creating domain 0 vcpu0\n"); diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c index 5139890e3d..8f076849c1 100644 --- a/xen/common/llc-coloring.c +++ b/xen/common/llc-coloring.c @@ -25,6 +25,66 @@ static unsigned int __initdata llc_nr_ways; integer_param("llc-nr-ways", llc_nr_ways); /* Number of colors available in the LLC */ static unsigned int __ro_after_init max_nr_colors; +/* Default coloring configuration */ +static unsigned int __ro_after_init default_colors[NR_LLC_COLORS]; + +static unsigned int __initdata dom0_colors[NR_LLC_COLORS]; +static unsigned int __initdata dom0_num_colors; + +/* + * Parse the coloring configuration given in the buf string, following the + * syntax below. + * + * COLOR_CONFIGURATION ::= COLOR | RANGE,...,COLOR | RANGE + * RANGE ::= COLOR-COLOR + * + * Example: "0,2-6,15-16" represents the set of colors: 0,2,3,4,5,6,15,16. + */ +static int __init parse_color_config(const char *buf, unsigned int colors[], + unsigned int max_num_colors, + unsigned int *num_colors) +{ + const char *s = buf; + + *num_colors = 0; + + while ( *s != '\0' ) + { + unsigned int color, start, end; + + start = simple_strtoul(s, &s, 0); + + if ( *s == '-' ) /* Range */ + { + s++; + end = simple_strtoul(s, &s, 0); + } + else /* Single value */ + end = start; + + if ( start > end || (end - start) > (UINT_MAX - *num_colors) || + (*num_colors + (end - start)) >= max_num_colors ) + return -EINVAL; + + /* Colors are range checked in check_colors() */ + for ( color = start; color <= end; color++ ) + colors[(*num_colors)++] = color; + + if ( *s == ',' ) + s++; + else if ( *s != '\0' ) + break; + } + + return *s ? -EINVAL : 0; +} + +static int __init parse_dom0_colors(const char *s) +{ + return parse_color_config(s, dom0_colors, ARRAY_SIZE(dom0_colors), + &dom0_num_colors); +} +custom_param("dom0-llc-colors", parse_dom0_colors); static void print_colors(const unsigned int colors[], unsigned int num_colors) { @@ -49,9 +109,27 @@ static void print_colors(const unsigned int colors[], unsigned int num_colors) printk(" }\n"); } +static bool __init check_colors(const unsigned int colors[], + unsigned int num_colors) +{ + unsigned int i; + + for ( i = 0; i < num_colors; i++ ) + { + if ( colors[i] >= max_nr_colors ) + { + printk(XENLOG_ERR "LLC color %u >= %u (max allowed)\n", colors[i], + max_nr_colors); + return false; + } + } + + return true; +} + void __init llc_coloring_init(void) { - unsigned int way_size; + unsigned int way_size, i; if ( (llc_coloring_enabled < 0) && (llc_size && llc_nr_ways) ) { @@ -89,6 +167,9 @@ void __init llc_coloring_init(void) else if ( max_nr_colors < 2 ) panic("Number of LLC colors %u < 2\n", max_nr_colors); + for ( i = 0; i < max_nr_colors; i++ ) + default_colors[i] = i; + arch_llc_coloring_init(); } @@ -110,6 +191,43 @@ void domain_dump_llc_colors(const struct domain *d) print_colors(d->llc_colors, d->num_llc_colors); } +static void __init domain_set_default_colors(struct domain *d) +{ + printk(XENLOG_WARNING + "LLC color config not found for %pd, using all colors\n", d); + + d->llc_colors = default_colors; + d->num_llc_colors = max_nr_colors; +} + +int __init dom0_set_llc_colors(struct domain *d) +{ + typeof(*dom0_colors) *colors; + + if ( !dom0_num_colors ) + { + domain_set_default_colors(d); + return 0; + } + + if ( (dom0_num_colors > max_nr_colors) || + !check_colors(dom0_colors, dom0_num_colors) ) + { + printk(XENLOG_ERR "%pd: bad LLC color config\n", d); + return -EINVAL; + } + + colors = xmalloc_array(typeof(*dom0_colors), dom0_num_colors); + if ( !colors ) + return -ENOMEM; + + memcpy(colors, dom0_colors, sizeof(*colors) * dom0_num_colors); + d->llc_colors = colors; + d->num_llc_colors = dom0_num_colors; + + return 0; +} + /* * Local variables: * mode: C diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h index ee0c58ab1c..4ce14e4e4a 100644 --- a/xen/include/xen/llc-coloring.h +++ b/xen/include/xen/llc-coloring.h @@ -26,6 +26,7 @@ static inline void domain_dump_llc_colors(const struct domain *d) {} unsigned int get_llc_way_size(void); void arch_llc_coloring_init(void); +int dom0_set_llc_colors(struct domain *d); #endif /* __XEN_LLC_COLORING_H__ */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 16:59:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 16:59:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846768.1261966 (Exim 4.92) (envelope-from ) id 1tI9ln-0008SG-9G; Mon, 02 Dec 2024 16:59:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846768.1261966; Mon, 02 Dec 2024 16:59: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 1tI9ln-0008Qy-1B; Mon, 02 Dec 2024 16:59:35 +0000 Received: by outflank-mailman (input) for mailman id 846768; Mon, 02 Dec 2024 16:59: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 1tI9ll-0006wq-Fl for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 16:59:33 +0000 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [2a00:1450:4864:20::636]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cd4d04ac-b0ce-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 17:59:32 +0100 (CET) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-aa5b0d8bd41so540602366b.2 for ; Mon, 02 Dec 2024 08:59:32 -0800 (PST) Received: from carlo-ubuntu.home.arpa (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5998e64c4sm526802666b.97.2024.12.02.08.59.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 08:59: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: cd4d04ac-b0ce-11ef-a0d2-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1733158772; x=1733763572; 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=ppPQl9w5dBFddHDYD8Vy/EIAYsGbht/mLYkRtxhgMrM=; b=q6EsyGZqD7xrIsPzNY/3Rqh0edToIz7ru20l5BLYkDUo88AoTxJ/jaihv1sRywvUnA R2HJSJGpJCfnMbqfrHbKsrWuyFZerk2J3Liqvt9xHFeJtSMzyg7bD3XhgxfCHg9D9WzG xAZVSb8DWvUIZjU1tHGFr21TAXdXiaiqAQgjPsQbTXRCPTE+/QwMzNciTWjdO+Cn0jfh OX5snsIt02M2+cm5ah/U+8RaNecZZmlqc/gwf0LZyE0jXSMnhYZRW97ha2iQ2hopjBHt hugjDz8O6hov9tg0V3cSKAB/q4ntntktM7Ok5BTBkc7lbMDme1WP1MyQe+EJPVtby7B2 Ce7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733158772; x=1733763572; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ppPQl9w5dBFddHDYD8Vy/EIAYsGbht/mLYkRtxhgMrM=; b=W11/d2bf62aO40ZZZA8DkiIQem2khG5Qu20FDn/V8noxTbF6eOcNkpI6rzDArOJdx3 6mVu0pPfo2VzAAFnTgPdQlEvsfp0Xh0pfggzgOg8K3YgKQ06G5G4lQ1eivgc9zDIFxcS rUgYMrpVUt7NmgwJBxu6ndrU23ZdblkL8l+g74GhorYAtxYSPq2JDe9XpZLYG8vXdt8B /S2imVfJjdbZQJpShdJ0JwvD7FbCExhVYOHn9J2QYgLu7piC///MtcTEMc1oL9Z8Pi3D AIrqbcfqIfAVS/MnTfUBxbq/Xzdpuv218k/uk2iM/JfKoSjk00OLT/7r/B/eN0E3R7j5 trwA== X-Gm-Message-State: AOJu0YzHJ1PRnumOHRex83cZ5Cn1RkBAHoka6lck+Dy+qLAn1qULyWUT XOh1lM1ztij/fxI1FUfDaFBxUM8Vnc0aeWzatKAf9KVT0qw7McOclpnQzujafhnmgQE3klwa19w H X-Gm-Gg: ASbGncu4o6bIw+CTNm2MJ9c9O1l6MVIA7Vgi0JXAcZpfBswGHFjOBExN+xMD+P/3dPR c2cSSzcHJGcNYPDE2yYrW0Im2se/9G06gI83Fdga5oXtBBY1xZza707QdrTLY87QXBVgBnxp6b9 GEpCNT7xRzdKnAbuv1UEHOgFgrjUpAjD/OwSd6iZ3IkhhBxkHLBu9yKfnf1mxhz2F+UwbJu5lOL WezkPMCosWrFWllT+I7ckJKvauWJmoQb2mg6o5Yjn1pNHgpV4tuVk6qlWgZMXsH0orWUFeekhaL CxX9aW/X62IcefpShfU1yod+qDA47yOhCbuuwINNlnGm9nP4ZLHj X-Google-Smtp-Source: AGHT+IGjX7fCpJbm3uAUYe0AcHx2T+eRrdwJ4BdABtf082bgnzFYleij+K9H4TXHjRTsnFgt6zcLjQ== X-Received: by 2002:a17:906:1daa:b0:aa5:1d33:dc10 with SMTP id a640c23a62f3a-aa581041505mr1928713866b.45.1733158771845; Mon, 02 Dec 2024 08:59:31 -0800 (PST) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Carlo Nonato , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Jan Beulich Subject: [PATCH v11 07/12] xen/arm: add support for cache coloring configuration via device-tree Date: Mon, 2 Dec 2024 17:59:16 +0100 Message-ID: <20241202165921.249585-8-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241202165921.249585-1-carlo.nonato@minervasys.tech> References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add the "llc-colors" Device Tree property to express DomUs and Dom0less color configurations. Based on original work from: Luca Miccio Signed-off-by: Carlo Nonato Signed-off-by: Marco Solieri Reviewed-by: Jan Beulich # non-Arm Reviewed-by: Michal Orzel --- v11: - made clear that llc-colors device-tree property is Arm64-only in booting.txt v10: - no changes v9: - use best-effort allocation in domain_set_llc_colors_from_str() v8: - fixed memory leak on error path of domain_set_llc_colors_from_str() - realloc colors array after parsing from string to reduce memory usage v7: - removed alloc_colors() helper usage from domain_set_llc_colors_from_str() v6: - rewrote domain_set_llc_colors_from_str() to be more explicit v5: - static-mem check has been moved in a previous patch - added domain_set_llc_colors_from_str() to set colors after domain creation --- docs/misc/arm/device-tree/booting.txt | 5 +++ docs/misc/cache-coloring.rst | 48 +++++++++++++++++++++++++++ xen/arch/arm/dom0less-build.c | 10 ++++++ xen/common/llc-coloring.c | 40 ++++++++++++++++++++++ xen/include/xen/llc-coloring.h | 1 + xen/include/xen/xmalloc.h | 12 +++++++ 6 files changed, 116 insertions(+) diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt index 3a04f5c57f..9c881baccc 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -162,6 +162,11 @@ with the following properties: An integer specifying the number of vcpus to allocate to the guest. +- llc-colors + A string specifying the LLC color configuration for the guest. + Refer to docs/misc/cache_coloring.rst for syntax. This option is applicable + only to Arm64 guests. + - vpl011 An empty property to enable/disable a virtual pl011 for the guest to diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst index 7b47d0ed92..e097e74032 100644 --- a/docs/misc/cache-coloring.rst +++ b/docs/misc/cache-coloring.rst @@ -14,6 +14,7 @@ If needed, change the maximum number of colors with ``CONFIG_LLC_COLORS_ORDER=``. Runtime configuration is done via `Command line parameters`_. +For DomUs follow `DomUs configuration`_. Background ********** @@ -149,6 +150,53 @@ LLC specs can be manually set via the above command line parameters. This bypasses any auto-probing and it's used to overcome failing situations, such as flawed probing logic, or for debugging/testing purposes. +DomUs configuration +******************* + +DomUs colors can be set either in the ``xl`` configuration file (documentation +at `docs/man/xl.cfg.pod.5.in`) or via Device Tree (documentation at +`docs/misc/arm/device-tree/booting.txt`) using the ``llc-colors`` option. +For example: + +:: + + xen,xen-bootargs = "console=dtuart dtuart=serial0 dom0_mem=1G dom0_max_vcpus=1 sched=null llc-coloring=on dom0-llc-colors=2-6"; + xen,dom0-bootargs "console=hvc0 earlycon=xen earlyprintk=xen root=/dev/ram0" + + dom0 { + compatible = "xen,linux-zimage" "xen,multiboot-module"; + reg = <0x0 0x1000000 0x0 15858176>; + }; + + dom0-ramdisk { + compatible = "xen,linux-initrd" "xen,multiboot-module"; + reg = <0x0 0x2000000 0x0 20638062>; + }; + + domU0 { + #address-cells = <0x1>; + #size-cells = <0x1>; + compatible = "xen,domain"; + memory = <0x0 0x40000>; + llc-colors = "4-8,10,11,12"; + cpus = <0x1>; + vpl011 = <0x1>; + + module@2000000 { + compatible = "multiboot,kernel", "multiboot,module"; + reg = <0x2000000 0xffffff>; + bootargs = "console=ttyAMA0"; + }; + + module@30000000 { + compatible = "multiboot,ramdisk", "multiboot,module"; + reg = <0x3000000 0xffffff>; + }; + }; + +**Note:** If no color configuration is provided for a domain, the default one, +which corresponds to all available colors is used instead. + Known issues and limitations **************************** diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index 67b1503647..49d1f14d65 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -817,6 +817,7 @@ void __init create_domUs(void) bool iommu = false; const struct dt_device_node *cpupool_node, *chosen = dt_find_node_by_path("/chosen"); + const char *llc_colors_str = NULL; BUG_ON(chosen == NULL); dt_for_each_child_node(chosen, node) @@ -965,6 +966,10 @@ void __init create_domUs(void) #endif } + dt_property_read_string(node, "llc-colors", &llc_colors_str); + if ( !llc_coloring_enabled && llc_colors_str ) + panic("'llc-colors' found, but LLC coloring is disabled\n"); + /* * The variable max_init_domid is initialized with zero, so here it's * very important to use the pre-increment operator to call @@ -975,6 +980,11 @@ void __init create_domUs(void) panic("Error creating domain %s (rc = %ld)\n", dt_node_name(node), PTR_ERR(d)); + if ( llc_coloring_enabled && + (rc = domain_set_llc_colors_from_str(d, llc_colors_str)) ) + panic("Error initializing LLC coloring for domain %s (rc = %d)\n", + dt_node_name(node), rc); + d->is_console = true; dt_device_set_used_by(node, d->domain_id); diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c index 2a0ee695c8..2a85345cf1 100644 --- a/xen/common/llc-coloring.c +++ b/xen/common/llc-coloring.c @@ -277,6 +277,46 @@ void domain_llc_coloring_free(struct domain *d) xfree(__va(__pa(d->llc_colors))); } +int __init domain_set_llc_colors_from_str(struct domain *d, const char *str) +{ + int err; + unsigned int *colors, num_colors; + + if ( !str ) + { + domain_set_default_colors(d); + return 0; + } + + colors = xmalloc_array(unsigned int, max_nr_colors); + if ( !colors ) + return -ENOMEM; + + err = parse_color_config(str, colors, max_nr_colors, &num_colors); + if ( err ) + { + printk(XENLOG_ERR "Error parsing LLC color configuration"); + xfree(colors); + return err; + } + + if ( !check_colors(colors, num_colors) ) + { + printk(XENLOG_ERR "%pd: bad LLC color config\n", d); + xfree(colors); + return -EINVAL; + } + + /* Adjust the size cause it was initially set to max_nr_colors */ + d->llc_colors = xrealloc_array(colors, num_colors); + if ( !d->llc_colors ) + d->llc_colors = colors; + + d->num_llc_colors = num_colors; + + return 0; +} + /* * Local variables: * mode: C diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h index cbebe0816c..ae8a8825e5 100644 --- a/xen/include/xen/llc-coloring.h +++ b/xen/include/xen/llc-coloring.h @@ -32,6 +32,7 @@ void arch_llc_coloring_init(void); int dom0_set_llc_colors(struct domain *d); int domain_set_llc_colors(struct domain *d, const struct xen_domctl_set_llc_colors *config); +int domain_set_llc_colors_from_str(struct domain *d, const char *str); #endif /* __XEN_LLC_COLORING_H__ */ diff --git a/xen/include/xen/xmalloc.h b/xen/include/xen/xmalloc.h index b903fa2e26..f0412fb4e0 100644 --- a/xen/include/xen/xmalloc.h +++ b/xen/include/xen/xmalloc.h @@ -37,6 +37,9 @@ ((_type *)_xmalloc_array(sizeof(_type), __alignof__(_type), _num)) #define xzalloc_array(_type, _num) \ ((_type *)_xzalloc_array(sizeof(_type), __alignof__(_type), _num)) +#define xrealloc_array(_ptr, _num) \ + ((typeof(_ptr))_xrealloc_array(_ptr, sizeof(typeof(*(_ptr))), \ + __alignof__(typeof(*(_ptr))), _num)) /* Allocate space for a structure with a flexible array of typed objects. */ #define xzalloc_flex_struct(type, field, nr) \ @@ -98,6 +101,15 @@ static inline void *_xzalloc_array( return _xzalloc(size * num, align); } +static inline void *_xrealloc_array( + void *ptr, unsigned long size, unsigned long align, unsigned long num) +{ + /* Check for overflow. */ + if ( size && num > UINT_MAX / size ) + return NULL; + return _xrealloc(ptr, size * num, align); +} + /* * Pooled allocator interface. */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 16:59:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 16:59:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846765.1261936 (Exim 4.92) (envelope-from ) id 1tI9ll-0007hU-0U; Mon, 02 Dec 2024 16:59:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846765.1261936; Mon, 02 Dec 2024 16:59: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 1tI9lk-0007gd-Qw; Mon, 02 Dec 2024 16:59:32 +0000 Received: by outflank-mailman (input) for mailman id 846765; Mon, 02 Dec 2024 16:59: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 1tI9li-0006x4-G8 for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 16:59:30 +0000 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [2a00:1450:4864:20::632]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c9afe829-b0ce-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 17:59:26 +0100 (CET) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-aa54adcb894so592012866b.0 for ; Mon, 02 Dec 2024 08:59:26 -0800 (PST) Received: from carlo-ubuntu.home.arpa (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5998e64c4sm526802666b.97.2024.12.02.08.59.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 08:59: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: c9afe829-b0ce-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1733158766; x=1733763566; 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=JHLIjqNln10+uaaGPR6Goi/c1sEntGahZG9YudcBl6s=; b=nwLK0uIrER4O2w3WP0oY9aA1j9aVxBeHF7wX+U50mW8GKkSwnhLUF9/CcZFJKUAkhW +decTTSo8zeUZPu67AmhaW2FSQSkXlHNR/lOIIy/5Y1vkT+QaQyUMqFUBBEDIC3aTgis GJ1qaGEgZKf937QNRWwMLjYfrlh1G9dddrhCm2Ixnpd+qh7euZ0NH3Two/zSEVlbgZHI VtNEnPlou2EFxn7Rc8wJAVkaRgG/XU5otHIS8142m76DyQB38xApwSx5jrSwc96CtxxQ fvU2nAObEGh44EQl2WCwWUPUmOdNkPo5Renizot3XofDJuc74QMhlrif73NsKC3bfnQv iKpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733158766; x=1733763566; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JHLIjqNln10+uaaGPR6Goi/c1sEntGahZG9YudcBl6s=; b=kS5a/BU/yWmp/i8rCstOtbWFETOgFYWmUSNU59pNj44WiQXnv4R6fUb+fDUIHkkEPn dfvGVC0xHWwPGWjbAREAPMKJRys9qvGsx3OfFFFK8OGqKk+y1NEcsPusAr46QbkUAURM NgrZwtJZNOnVN/iEoMZfWcjCom4BSdhUh4SjqkvaQ7KLXoOsPGZXpMSBjpNtZanA41F/ LkPjBzK9ilpZLfAzIGl2HuWnBxs76vzBeEpSkD4sVEBG8d4WOwEz4JQ7jq1LYjov6kSL K37MKG9a5ea1w33wRTuQDs0Ae0MvVuYmtIEL2t2LFCNDY4KLy5c1f7GQwn2tJ0/Gux9U TIhA== X-Gm-Message-State: AOJu0Yx8iNKXatiNmH+jQTbKcGGV/eJ88v6ej0ncoVPsHd3THRQMx6d3 Cbv75aEuxDR33EXlHV+b+3DGDtqT0tr5hhNpfPs3BoRjDEaiG22421yxla6njJwhpEB5qxRELC3 U X-Gm-Gg: ASbGnctMdZLmtq/z0qiOvNNamVCCO32Ncp2ilj7uvcuJrFDx8wsXj8LJ1Q5JaYZ/2WG /UzhZnF+vBdQn21Okba2Y5RdneP1/lwwPCroI+DkHXiQSJe2HzUksUCJG0ayD15eD7dW25D+ASR KMGzLL62XasLSFvGvY/9SAxrduJoWHIoNXRoz1qi4MprtaYvnuKm1iNX5cRQJfY5QJdTRq3uPdQ 26fmBy01B6IJI5MPR4mX5ZuwuUKDiy+/KPoDj6U/jCcEJi7s9t2DsFMP3/Bzln+Km6FjnOt1rYp CiFeGvcbGbLpeo8CkRqWmQcjfeEpWAWQcRGM0poQZgBSAvB1/hs8 X-Google-Smtp-Source: AGHT+IHq+mPW+7hN/xHplIh/FSA2AJTOopTHeCCqUeuziyhDmQ/ahN1vH+jFcmEE6BKUhmxRRpwA1A== X-Received: by 2002:a17:906:3299:b0:aa5:2237:67af with SMTP id a640c23a62f3a-aa580edf62dmr1878429566b.9.1733158765672; Mon, 02 Dec 2024 08:59:25 -0800 (PST) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Carlo Nonato , Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Michal Orzel Subject: [PATCH v11 01/12] xen/common: add cache coloring common code Date: Mon, 2 Dec 2024 17:59:10 +0100 Message-ID: <20241202165921.249585-2-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241202165921.249585-1-carlo.nonato@minervasys.tech> References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Last Level Cache (LLC) coloring allows to partition the cache in smaller chunks called cache colors. Since not all architectures can actually implement it, add a HAS_LLC_COLORING Kconfig option. LLC_COLORS_ORDER Kconfig option has a range maximum of 10 (2^10 = 1024) because that's the number of colors that fit in a 4 KiB page when integers are 4 bytes long. LLC colors are a property of the domain, so struct domain has to be extended. Based on original work from: Luca Miccio Signed-off-by: Carlo Nonato Signed-off-by: Marco Solieri Acked-by: Michal Orzel --- v11: - __COLORING_H__ -> __XEN_LLC_COLORING_H__ in llc-coloring.h - added SPDX tag to cache-coloring.rst - llc-coloring=off now takes precedence over other cmdline options - removed useless #includes v10: - fixed commit message to use LLC_COLORS_ORDER - added documentation to index.rst - moved check on CONFIG_NUMA in arch/arm/Kconfig (next patch) - fixed copyright line - fixed array type for colors parameter in print_colors() - added check on (way_size & ~PAGE_MASK) v9: - dropped _MAX_ from CONFIG_MAX_LLC_COLORS_ORDER v8: - minor documentation fixes - "llc-coloring=on" is inferred from "llc-nr-ways" and "llc-size" usage - turned CONFIG_NR_LLC_COLORS to CONFIG_MAX_LLC_COLORS_ORDER, base-2 exponent - moved Kconfig options to common/Kconfig - don't crash if computed max_nr_colors is too large v7: - SUPPORT.md changes added to this patch - extended documentation to better address applicability of cache coloring - "llc-nr-ways" and "llc-size" params introduced in favor of "llc-way-size" - moved dump_llc_coloring_info() call in 'm' keyhandler (pagealloc_info()) v6: - moved almost all code in common - moved documentation in this patch - reintroduced range for CONFIG_NR_LLC_COLORS - reintroduced some stub functions to reduce the number of checks on llc_coloring_enabled - moved domain_llc_coloring_free() in same patch where allocation happens - turned "d->llc_colors" to pointer-to-const - llc_coloring_init() now returns void and panics if errors are found v5: - used - instead of _ for filenames - removed domain_create_llc_colored() - removed stub functions - coloring domain fields are now #ifdef protected v4: - Kconfig options moved to xen/arch - removed range for CONFIG_NR_LLC_COLORS - added "llc_coloring_enabled" global to later implement the boot-time switch - added domain_create_llc_colored() to be able to pass colors - added is_domain_llc_colored() macro --- SUPPORT.md | 7 ++ docs/index.rst | 1 + docs/misc/cache-coloring.rst | 118 +++++++++++++++++++++++++++++ docs/misc/xen-command-line.pandoc | 37 +++++++++ xen/common/Kconfig | 21 ++++++ xen/common/Makefile | 1 + xen/common/keyhandler.c | 3 + xen/common/llc-coloring.c | 121 ++++++++++++++++++++++++++++++ xen/common/page_alloc.c | 3 + xen/include/xen/llc-coloring.h | 36 +++++++++ xen/include/xen/sched.h | 5 ++ 11 files changed, 353 insertions(+) create mode 100644 docs/misc/cache-coloring.rst create mode 100644 xen/common/llc-coloring.c create mode 100644 xen/include/xen/llc-coloring.h diff --git a/SUPPORT.md b/SUPPORT.md index 82239d0294..998faf5635 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -401,6 +401,13 @@ by maintaining multiple physical to machine (p2m) memory mappings. Status, x86 HVM: Tech Preview Status, ARM: Tech Preview +### Cache coloring + +Allows to reserve Last Level Cache (LLC) partitions for Dom0, DomUs and Xen +itself. + + Status, Arm64: Experimental + ## Resource Management ### CPU Pools diff --git a/docs/index.rst b/docs/index.rst index 1d44796d72..1bb8d02ea3 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -66,6 +66,7 @@ Documents in need of some rearranging. misc/xen-makefiles/makefiles misra/index fusa/index + misc/cache-coloring Miscellanea diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst new file mode 100644 index 0000000000..371f21a0e7 --- /dev/null +++ b/docs/misc/cache-coloring.rst @@ -0,0 +1,118 @@ +.. SPDX-License-Identifier: CC-BY-4.0 + +Xen cache coloring user guide +============================= + +The cache coloring support in Xen allows to reserve Last Level Cache (LLC) +partitions for Dom0, DomUs and Xen itself. Currently only ARM64 is supported. +Cache coloring realizes per-set cache partitioning in software and is applicable +to shared LLCs as implemented in Cortex-A53, Cortex-A72 and similar CPUs. + +To compile LLC coloring support set ``CONFIG_LLC_COLORING=y``. + +If needed, change the maximum number of colors with +``CONFIG_LLC_COLORS_ORDER=``. + +Runtime configuration is done via `Command line parameters`_. + +Background +********** + +Cache hierarchy of a modern multi-core CPU typically has first levels dedicated +to each core (hence using multiple cache units), while the last level is shared +among all of them. Such configuration implies that memory operations on one +core (e.g. running a DomU) are able to generate interference on another core +(e.g. hosting another DomU). Cache coloring realizes per-set cache-partitioning +in software and mitigates this, guaranteeing more predictable performances for +memory accesses. +Software-based cache coloring is particularly useful in those situations where +no hardware mechanisms (e.g., DSU-based way partitioning) are available to +partition caches. This is the case for e.g., Cortex-A53, A57 and A72 CPUs that +feature a L2 LLC cache shared among all cores. + +The key concept underlying cache coloring is a fragmentation of the memory +space into a set of sub-spaces called colors that are mapped to disjoint cache +partitions. Technically, the whole memory space is first divided into a number +of subsequent regions. Then each region is in turn divided into a number of +subsequent sub-colors. The generic i-th color is then obtained by all the +i-th sub-colors in each region. + +:: + + Region j Region j+1 + ..................... ............ + . . . + . . + _ _ _______________ _ _____________________ _ _ + | | | | | | | + | c_0 | c_1 | | c_n | c_0 | c_1 | + _ _ _|_____|_____|_ _ _|_____|_____|_____|_ _ _ + : : + : :... ... . + : color 0 + :........................... ... . + : + . . ..................................: + +How colors are actually defined depends on the function that maps memory to +cache lines. In case of physically-indexed, physically-tagged caches with linear +mapping, the set index is found by extracting some contiguous bits from the +physical address. This allows colors to be defined as shown in figure: they +appear in memory as subsequent blocks of equal size and repeats themselves after +``n`` different colors, where ``n`` is the total number of colors. + +If some kind of bit shuffling appears in the mapping function, then colors +assume a different layout in memory. Those kind of caches aren't supported by +the current implementation. + +**Note**: Finding the exact cache mapping function can be a really difficult +task since it's not always documented in the CPU manual. As said Cortex-A53, A57 +and A72 are known to work with the current implementation. + +How to compute the number of colors +################################### + +Given the linear mapping from physical memory to cache lines for granted, the +number of available colors for a specific platform is computed using three +parameters: + +- the size of the LLC. +- the number of the LLC ways. +- the page size used by Xen. + +The first two parameters can be found in the processor manual, while the third +one is the minimum mapping granularity. Dividing the cache size by the number of +its ways we obtain the size of a way. Dividing this number by the page size, +the number of total cache colors is found. So for example an Arm Cortex-A53 +with a 16-ways associative 1 MiB LLC can isolate up to 16 colors when pages are +4 KiB in size. + +Effective colors assignment +########################### + +When assigning colors, if one wants to avoid cache interference between two +domains, different colors needs to be used for their memory. + +Command line parameters +*********************** + +Specific documentation is available at `docs/misc/xen-command-line.pandoc`. + ++----------------------+-------------------------------+ +| **Parameter** | **Description** | ++----------------------+-------------------------------+ +| ``llc-coloring`` | Enable coloring at runtime | ++----------------------+-------------------------------+ +| ``llc-size`` | Set the LLC size | ++----------------------+-------------------------------+ +| ``llc-nr-ways`` | Set the LLC number of ways | ++----------------------+-------------------------------+ + +Auto-probing of LLC specs +######################### + +LLC size and number of ways are probed automatically by default. + +LLC specs can be manually set via the above command line parameters. This +bypasses any auto-probing and it's used to overcome failing situations, such as +flawed probing logic, or for debugging/testing purposes. diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 293dbc1a95..abd8dae96f 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -1708,6 +1708,43 @@ This option is intended for debugging purposes only. Enable MSR_DEBUGCTL.LBR in hypervisor context to be able to dump the Last Interrupt/Exception To/From record with other registers. +### llc-coloring (arm64) +> `= ` + +> Default: `false` + +Flag to enable or disable LLC coloring support at runtime. This option is +available only when `CONFIG_LLC_COLORING` is enabled. See the general +cache coloring documentation for more info. + +### llc-nr-ways (arm64) +> `= ` + +> Default: `Obtained from hardware` + +Specify the number of ways of the Last Level Cache. This option is available +only when `CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are used +to find the number of supported cache colors. By default the value is +automatically computed by probing the hardware, but in case of specific needs, +it can be manually set. Those include failing probing and debugging/testing +purposes so that it's possible to emulate platforms with different number of +supported colors. If set, also "llc-size" must be set, otherwise the default +will be used. Note that using both options implies "llc-coloring=on". + +### llc-size (arm64) +> `= ` + +> Default: `Obtained from hardware` + +Specify the size of the Last Level Cache. This option is available only when +`CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are used to find +the number of supported cache colors. By default the value is automatically +computed by probing the hardware, but in case of specific needs, it can be +manually set. Those include failing probing and debugging/testing purposes so +that it's possible to emulate platforms with different number of supported +colors. If set, also "llc-nr-ways" must be set, otherwise the default will be +used. Note that using both options implies "llc-coloring=on". + ### lock-depth-size > `= ` diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 90268d9249..b4ec6893be 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -71,6 +71,9 @@ config HAS_IOPORTS config HAS_KEXEC bool +config HAS_LLC_COLORING + bool + config HAS_PIRQ bool @@ -516,4 +519,22 @@ config TRACEBUFFER to be collected at run time for debugging or performance analysis. Memory and execution overhead when not active is minimal. +config LLC_COLORING + bool "Last Level Cache (LLC) coloring" if EXPERT + depends on HAS_LLC_COLORING + +config LLC_COLORS_ORDER + int "Maximum number of LLC colors (base-2 exponent)" + range 1 10 + default 7 + depends on LLC_COLORING + help + Controls the build-time size of various arrays associated with LLC + coloring. The value is a base-2 exponent. Refer to cache coloring + documentation for how to compute the number of colors supported by the + platform. This is only an upper bound. The runtime value is autocomputed + or manually set via cmdline parameters. + The default value corresponds to an 8 MiB 16-ways LLC, which should be + more than what's needed in the general case. + endmenu diff --git a/xen/common/Makefile b/xen/common/Makefile index b279b09bfb..cba3b32733 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -25,6 +25,7 @@ obj-y += keyhandler.o obj-$(CONFIG_KEXEC) += kexec.o obj-$(CONFIG_KEXEC) += kimage.o obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o +obj-$(CONFIG_LLC_COLORING) += llc-coloring.o obj-$(CONFIG_MEM_ACCESS) += mem_access.o obj-y += memory.o obj-y += multicall.o diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c index 6da291b34e..6ea54838d4 100644 --- a/xen/common/keyhandler.c +++ b/xen/common/keyhandler.c @@ -5,6 +5,7 @@ #include #include #include +#include #include #include #include @@ -304,6 +305,8 @@ static void cf_check dump_domains(unsigned char key) arch_dump_domain_info(d); + domain_dump_llc_colors(d); + rangeset_domain_printk(d); dump_pageframe_info(d); diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c new file mode 100644 index 0000000000..54d76e3aca --- /dev/null +++ b/xen/common/llc-coloring.c @@ -0,0 +1,121 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Last Level Cache (LLC) coloring common code + * + * Copyright (C) 2024, Advanced Micro Devices, Inc. + * Copyright (C) 2024, Minerva Systems SRL + */ +#include +#include +#include + +#define NR_LLC_COLORS (1U << CONFIG_LLC_COLORS_ORDER) + +/* + * -1: not specified (disabled unless llc-size and llc-nr-ways present) + * 0: explicitly disabled through cmdline + * 1: explicitly enabled through cmdline + */ +static int8_t __ro_after_init llc_coloring_enabled = -1; +boolean_param("llc-coloring", llc_coloring_enabled); + +static unsigned int __initdata llc_size; +size_param("llc-size", llc_size); +static unsigned int __initdata llc_nr_ways; +integer_param("llc-nr-ways", llc_nr_ways); +/* Number of colors available in the LLC */ +static unsigned int __ro_after_init max_nr_colors; + +static void print_colors(const unsigned int colors[], unsigned int num_colors) +{ + unsigned int i; + + printk("{ "); + for ( i = 0; i < num_colors; i++ ) + { + unsigned int start = colors[i], end = start; + + printk("%u", start); + + for ( ; i < num_colors - 1 && end + 1 == colors[i + 1]; i++, end++ ) + ; + + if ( start != end ) + printk("-%u", end); + + if ( i < num_colors - 1 ) + printk(", "); + } + printk(" }\n"); +} + +void __init llc_coloring_init(void) +{ + unsigned int way_size; + + if ( (llc_coloring_enabled < 0) && (llc_size && llc_nr_ways) ) + { + llc_coloring_enabled = true; + way_size = llc_size / llc_nr_ways; + } + else if ( !llc_coloring_enabled ) + return; + else + { + way_size = get_llc_way_size(); + if ( !way_size ) + panic("LLC probing failed and 'llc-size' or 'llc-nr-ways' missing\n"); + } + + if ( way_size & ~PAGE_MASK ) + panic("LLC way size must be a multiple of PAGE_SIZE\n"); + + /* + * The maximum number of colors must be a power of 2 in order to correctly + * map them to bits of an address. + */ + max_nr_colors = way_size >> PAGE_SHIFT; + + if ( max_nr_colors & (max_nr_colors - 1) ) + panic("Number of LLC colors (%u) isn't a power of 2\n", max_nr_colors); + + if ( max_nr_colors > NR_LLC_COLORS ) + { + printk(XENLOG_WARNING + "Number of LLC colors (%u) too big. Using configured max %u\n", + max_nr_colors, NR_LLC_COLORS); + max_nr_colors = NR_LLC_COLORS; + } + else if ( max_nr_colors < 2 ) + panic("Number of LLC colors %u < 2\n", max_nr_colors); + + arch_llc_coloring_init(); +} + +void dump_llc_coloring_info(void) +{ + if ( !llc_coloring_enabled ) + return; + + printk("LLC coloring info:\n"); + printk(" Number of LLC colors supported: %u\n", max_nr_colors); +} + +void domain_dump_llc_colors(const struct domain *d) +{ + if ( !llc_coloring_enabled ) + return; + + printk("%u LLC colors: ", d->num_llc_colors); + print_colors(d->llc_colors, d->num_llc_colors); +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 92abed6514..55d561e93c 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -126,6 +126,7 @@ #include #include #include +#include #include #include #include @@ -2644,6 +2645,8 @@ static void cf_check pagealloc_info(unsigned char key) } printk(" Dom heap: %lukB free\n", total << (PAGE_SHIFT-10)); + + dump_llc_coloring_info(); } static __init int cf_check pagealloc_keyhandler_init(void) diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h new file mode 100644 index 0000000000..0acd8d0ad6 --- /dev/null +++ b/xen/include/xen/llc-coloring.h @@ -0,0 +1,36 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Last Level Cache (LLC) coloring common header + * + * Copyright (C) 2024, Advanced Micro Devices, Inc. + * Copyright (C) 2024, Minerva Systems SRL + */ +#ifndef __XEN_LLC_COLORING_H__ +#define __XEN_LLC_COLORING_H__ + +struct domain; + +#ifdef CONFIG_LLC_COLORING +void llc_coloring_init(void); +void dump_llc_coloring_info(void); +void domain_dump_llc_colors(const struct domain *d); +#else +static inline void llc_coloring_init(void) {} +static inline void dump_llc_coloring_info(void) {} +static inline void domain_dump_llc_colors(const struct domain *d) {} +#endif + +unsigned int get_llc_way_size(void); +void arch_llc_coloring_init(void); + +#endif /* __XEN_LLC_COLORING_H__ */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index 76e39378b3..bc798a2f61 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -637,6 +637,11 @@ struct domain /* Holding CDF_* constant. Internal flags for domain creation. */ unsigned int cdf; + +#ifdef CONFIG_LLC_COLORING + unsigned int num_llc_colors; + const unsigned int *llc_colors; +#endif }; static inline struct page_list_head *page_to_list( -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 16:59:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 16:59:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846766.1261944 (Exim 4.92) (envelope-from ) id 1tI9ll-0007sB-FP; Mon, 02 Dec 2024 16:59:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846766.1261944; Mon, 02 Dec 2024 16:59:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tI9ll-0007rJ-9L; Mon, 02 Dec 2024 16:59:33 +0000 Received: by outflank-mailman (input) for mailman id 846766; Mon, 02 Dec 2024 16: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 1tI9lk-0006x4-7h for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 16:59:32 +0000 Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [2a00:1450:4864:20::132]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cbf9f788-b0ce-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 17:59:30 +0100 (CET) Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-53dd59a2bc1so4860354e87.2 for ; Mon, 02 Dec 2024 08:59:30 -0800 (PST) Received: from carlo-ubuntu.home.arpa (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5998e64c4sm526802666b.97.2024.12.02.08.59.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 08:59: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: cbf9f788-b0ce-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1733158770; x=1733763570; 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=uPDYDU9V+cT61NhOvEC9qVLU2fWBxFfDL0pDRFCfADs=; b=rxbhCpqgZafgQaWYMqPWpKNqw/+AHnJePzclEdzJd8CifIzEQUIjpXlieg9czVp7/3 6Tp4LdaC1hJY5nL93ERx6L7pJ2gVoKWwc1ugerBSDW1hXKERLW4xyd620l05rz9mFl7z AmV3/D1/21g2gkJtRsXUTjMz9MVhrsYTIPpjwdQ8z/jAbfjgw68+vTXCYewMXDbQOdO4 1VN0mYWuThCOJCcyNx/z6D5CRg/AxWWAlcu3LyLd97aHLGV9ChHsGRX8lnjn+w4/yB8p DHGe/YESaPN98a8/VmSZCVheQUCjzt3yoTP18n20o8WGoEQfuxyU3Hqa4A+5WUQPBzkk sFHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733158770; x=1733763570; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uPDYDU9V+cT61NhOvEC9qVLU2fWBxFfDL0pDRFCfADs=; b=UATpVOX/3ZL2uRae7Bkm/6CUASA+VBsxjVHGNAjFUFfqs1Ev80yQsI4rgC+Wmc/QQQ WlNCYDagXnUbohNoTmAqi+Ej+P3ULyK837vZvssviBw1Kw+nG/pDtlNkDioyscv1+1sZ q5c03qQDFMerBcoqH9EnwtH8Ds0e18G03MgBOFID2BBjQ+ZqdO95dwqujpouWmD9Kqq1 qcGUGx6mIstCzKqAfpUB4fvCrDL83ujHWGZ51m95/N4lIA4xeXORIcG3RpmPE6P1KPYc e7H997EC6xZRo1Tl045JO4HbPMT03Xd2ywvHO8d4ej05r42aBVgTfbzgTy4nkCiGSq3j +fmQ== X-Gm-Message-State: AOJu0Ywa+GwoMbWKiwnPO6pPVg6j/6rac7ULnHjz2obvBzLTSLYvIpFL 9VWrq1hLLrO6lzTPLZtqAKA5bJAdXZopJJGGGg7VuQ+6PU+OmSCQDkNpb+dquyS+C5XUMaeKqrn u X-Gm-Gg: ASbGncvZPIMtNYuedDV4ywY1qUg9qB/lETg4VPzoydzvj7a/8cISwsBf5ntS8DGdYXJ 7U/ILhX9ky+FgB+nzBYB8//+7oKwtPs22fqj93pFO+FkoLe273ByKv7dxpP7/0xYM2wBJJ8kmEg 2zl9YHnUry/ExGCJ3Pm9c2nwLW0GpEFqOuovmwSZFwJWRpl+AlWuRJadF3YH94bozC/dzMir60i FXYnA9X6U2p64Zgsqq07vfAxqk27l1aXiVkClAAvVWEoNZ+CQRVrQxG6MiOAqsTdVGopoA2jLyU klSK2njhcufH+sduFTNL/g9O53dUcelj3Loo2aCJ9EgBBj/HUke6 X-Google-Smtp-Source: AGHT+IGU9K5UrKiaW80g16K3SmuTHJjnReFkYfE1nN+bAa8o8fbCMxAm+qhH44scGK11AjAKmyVRag== X-Received: by 2002:a05:6512:3ba3:b0:53d:cf93:8072 with SMTP id 2adb3069b0e04-53df00ff250mr12783810e87.38.1733158769685; Mon, 02 Dec 2024 08:59:29 -0800 (PST) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Carlo Nonato , Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v11 05/12] xen: extend domctl interface for cache coloring Date: Mon, 2 Dec 2024 17:59:14 +0100 Message-ID: <20241202165921.249585-6-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241202165921.249585-1-carlo.nonato@minervasys.tech> References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add a new domctl hypercall to allow the user to set LLC coloring configurations. Colors can be set only once, just after domain creation, since recoloring isn't supported. Based on original work from: Luca Miccio Signed-off-by: Carlo Nonato Signed-off-by: Marco Solieri Reviewed-by: Jan Beulich --- v11: - no changes v10: - no changes v9: - minor printk message changes - moved domain_llc_coloring_free() in this patch v8: - fixed memory leak on error path of domain_set_llc_colors() v7: - -EOPNOTSUPP returned in case of hypercall called without llc_coloring_enabled - domain_set_llc_colors_domctl() renamed to domain_set_llc_colors() - added padding and input bound checks to domain_set_llc_colors() - removed alloc_colors() helper usage from domain_set_llc_colors() v6: - reverted the XEN_DOMCTL_INTERFACE_VERSION bump - reverted to uint32 for the guest handle - explicit padding added to the domctl struct - rewrote domain_set_llc_colors_domctl() to be more explicit v5: - added a new hypercall to set colors - uint for the guest handle v4: - updated XEN_DOMCTL_INTERFACE_VERSION --- xen/common/domain.c | 3 ++ xen/common/domctl.c | 10 +++++++ xen/common/llc-coloring.c | 55 ++++++++++++++++++++++++++++++++-- xen/include/public/domctl.h | 9 ++++++ xen/include/xen/llc-coloring.h | 5 ++++ 5 files changed, 79 insertions(+), 3 deletions(-) diff --git a/xen/common/domain.c b/xen/common/domain.c index 92263a4fbd..842a23751a 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -34,6 +34,7 @@ #include #include #include +#include #include #include #include @@ -1276,6 +1277,8 @@ void domain_destroy(struct domain *d) { BUG_ON(!d->is_dying); + domain_llc_coloring_free(d); + /* May be already destroyed, or get_domain() can race us. */ if ( atomic_cmpxchg(&d->refcnt, 0, DOMAIN_DESTROYED) != 0 ) return; diff --git a/xen/common/domctl.c b/xen/common/domctl.c index ea16b75910..6387dddbcd 100644 --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -8,6 +8,7 @@ #include #include +#include #include #include #include @@ -866,6 +867,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) __HYPERVISOR_domctl, "h", u_domctl); break; + case XEN_DOMCTL_set_llc_colors: + if ( op->u.set_llc_colors.pad ) + ret = -EINVAL; + else if ( llc_coloring_enabled ) + ret = domain_set_llc_colors(d, &op->u.set_llc_colors); + else + ret = -EOPNOTSUPP; + break; + default: ret = arch_do_domctl(op, d, u_domctl); break; diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c index 8f076849c1..2a0ee695c8 100644 --- a/xen/common/llc-coloring.c +++ b/xen/common/llc-coloring.c @@ -5,6 +5,7 @@ * Copyright (C) 2024, Advanced Micro Devices, Inc. * Copyright (C) 2024, Minerva Systems SRL */ +#include #include #include #include @@ -109,8 +110,7 @@ static void print_colors(const unsigned int colors[], unsigned int num_colors) printk(" }\n"); } -static bool __init check_colors(const unsigned int colors[], - unsigned int num_colors) +static bool check_colors(const unsigned int colors[], unsigned int num_colors) { unsigned int i; @@ -191,7 +191,7 @@ void domain_dump_llc_colors(const struct domain *d) print_colors(d->llc_colors, d->num_llc_colors); } -static void __init domain_set_default_colors(struct domain *d) +static void domain_set_default_colors(struct domain *d) { printk(XENLOG_WARNING "LLC color config not found for %pd, using all colors\n", d); @@ -228,6 +228,55 @@ int __init dom0_set_llc_colors(struct domain *d) return 0; } +int domain_set_llc_colors(struct domain *d, + const struct xen_domctl_set_llc_colors *config) +{ + unsigned int *colors; + + if ( d->num_llc_colors ) + return -EEXIST; + + if ( !config->num_llc_colors ) + { + domain_set_default_colors(d); + return 0; + } + + if ( config->num_llc_colors > max_nr_colors ) + return -EINVAL; + + colors = xmalloc_array(unsigned int, config->num_llc_colors); + if ( !colors ) + return -ENOMEM; + + if ( copy_from_guest(colors, config->llc_colors, config->num_llc_colors) ) + { + xfree(colors); + return -EFAULT; + } + + if ( !check_colors(colors, config->num_llc_colors) ) + { + printk(XENLOG_ERR "%pd: bad LLC color config\n", d); + xfree(colors); + return -EINVAL; + } + + d->llc_colors = colors; + d->num_llc_colors = config->num_llc_colors; + + return 0; +} + +void domain_llc_coloring_free(struct domain *d) +{ + if ( !llc_coloring_enabled || d->llc_colors == default_colors ) + return; + + /* free pointer-to-const using __va(__pa()) */ + xfree(__va(__pa(d->llc_colors))); +} + /* * Local variables: * mode: C diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h index 353f831e40..e2d392d1e5 100644 --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -1236,6 +1236,13 @@ struct xen_domctl_dt_overlay { }; #endif +struct xen_domctl_set_llc_colors { + /* IN LLC coloring parameters */ + uint32_t num_llc_colors; + uint32_t pad; + XEN_GUEST_HANDLE_64(uint32) llc_colors; +}; + struct xen_domctl { uint32_t cmd; #define XEN_DOMCTL_createdomain 1 @@ -1325,6 +1332,7 @@ struct xen_domctl { #define XEN_DOMCTL_set_paging_mempool_size 86 #define XEN_DOMCTL_dt_overlay 87 #define XEN_DOMCTL_gsi_permission 88 +#define XEN_DOMCTL_set_llc_colors 89 #define XEN_DOMCTL_gdbsx_guestmemio 1000 #define XEN_DOMCTL_gdbsx_pausevcpu 1001 #define XEN_DOMCTL_gdbsx_unpausevcpu 1002 @@ -1391,6 +1399,7 @@ struct xen_domctl { #if defined(__arm__) || defined(__aarch64__) struct xen_domctl_dt_overlay dt_overlay; #endif + struct xen_domctl_set_llc_colors set_llc_colors; uint8_t pad[128]; } u; }; diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h index 4ce14e4e4a..cbebe0816c 100644 --- a/xen/include/xen/llc-coloring.h +++ b/xen/include/xen/llc-coloring.h @@ -9,6 +9,7 @@ #define __XEN_LLC_COLORING_H__ struct domain; +struct xen_domctl_set_llc_colors; #ifdef CONFIG_LLC_COLORING extern int8_t llc_coloring_enabled; @@ -16,17 +17,21 @@ extern int8_t llc_coloring_enabled; void llc_coloring_init(void); void dump_llc_coloring_info(void); void domain_dump_llc_colors(const struct domain *d); +void domain_llc_coloring_free(struct domain *d); #else #define llc_coloring_enabled false static inline void llc_coloring_init(void) {} static inline void dump_llc_coloring_info(void) {} static inline void domain_dump_llc_colors(const struct domain *d) {} +static inline void domain_llc_coloring_free(struct domain *d) {} #endif unsigned int get_llc_way_size(void); void arch_llc_coloring_init(void); int dom0_set_llc_colors(struct domain *d); +int domain_set_llc_colors(struct domain *d, + const struct xen_domctl_set_llc_colors *config); #endif /* __XEN_LLC_COLORING_H__ */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 16:59:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 16:59:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846762.1261906 (Exim 4.92) (envelope-from ) id 1tI9lh-0006zC-Ug; Mon, 02 Dec 2024 16:59:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846762.1261906; Mon, 02 Dec 2024 16:59: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 1tI9lh-0006yd-QL; Mon, 02 Dec 2024 16:59:29 +0000 Received: by outflank-mailman (input) for mailman id 846762; Mon, 02 Dec 2024 16:59: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 1tI9lg-0006wq-Tu for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 16:59:28 +0000 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [2a00:1450:4864:20::52a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ca396b30-b0ce-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 17:59:27 +0100 (CET) Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-5d0d71d7f00so3185832a12.3 for ; Mon, 02 Dec 2024 08:59:27 -0800 (PST) Received: from carlo-ubuntu.home.arpa (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5998e64c4sm526802666b.97.2024.12.02.08.59.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 08: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: ca396b30-b0ce-11ef-a0d2-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1733158767; x=1733763567; 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=dOkVSMHCBjXldk0yaSWMOLuz0CcNMdAPNEbfMOACw4Y=; b=UA/DMkuxSNoEAhcOqW1TcLMcuaJDTpc//g+y2sfLZmzDM2s7/GuzjskQ34ojdtLfMd yTEP5Csbi2CplteQCrzR7T4RQVWjFmZbbCrIuPh1VILbOXNF9e+ZR0AkD9L+heh6MtM9 qf3D5c+4re/WTisDKnJuyUBMVAQRCBJQTSbkHeWW5iqbNigluELcWFion2wzkqHkgPUT h4Y8nJIUpS5cyBrGeLyICQn98S5ee4pdMR1Nb+w9Byb/kUhuFMs7P6MQ86eZDCR9rt1O nXOwqyy4kpi/UtrdNcejFXDrfmT34MJsdoNmG7yiyW+lPrUku/sdZCv4jd4DdibZbJVy 1tag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733158767; x=1733763567; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dOkVSMHCBjXldk0yaSWMOLuz0CcNMdAPNEbfMOACw4Y=; b=anw84XyU8RXW+OXEQ2vnoWt2Q3PXW7d3fwaDEuvhGl9aFOkjqTHLeDwdtJNMcriK/O XbG7/wMPuQn9vPvwtG3V0/Dp4y2VTJdXNC0/zUDSCeM2h58IC9DvRJx84OeTmTqePDea ai1rNfWdlvTMNhVvRsOwCorAopy0yi7nej5q8ove28Z+F1HTDl+LUtUWFqfk3R7oTGvA YoZDENqGNKRzAoSZbzOqZn6FgVOhtF6RpRZgxJnQfvhGHCeyybJZEemxdBMzcx3yLKET oWGZ4HBy9k+jwLRpd3Cpn2PSzX5rCv0dcMg3Ui3+E+lr/t8eOMrgOPSGDmC50KzSqOdr llYg== X-Gm-Message-State: AOJu0YzigsdXlw+G69UAfKc5hB9l1f3qCWJ8+Mtgpdzs+WyR12B+nGHt GQ2ykpXCtyqOHa2a4LxTWgBNiinDRn2clUcFZkdRGkQ5+4YF9x78oxQkjfF3aixYTofETG+hsvm o X-Gm-Gg: ASbGncsDwqdRBVmqnr+L4nnpGPzyvEIw1uRy3HRS0LFdl5WEPO1rQoC1bQA3zSN4XnN NOuJR/P6kinvIycuZLBjTtxq1PK1zllqMGbcSjul18WROKTkNJeZFNHVeO5Sxa67c5JGysDjF6z u4BsA5d36JDzvj78cWbH3PIO4BHIlAsUc+QVBBT5MKl74pVLdRC/xgfa93z8FOfWnVfrG8Kotkn kcJy98KZQS28riHLrkc4lJd259/oY3TOO5Fgt4H1CSEv7AbwH20RYFF89Iq2bMEtvNg3xR6Z+MS /Fs5xWelYfAGaX0TbZxH1KQt88MI5uqy3uGt63WDZvPSEqmmoR9q X-Google-Smtp-Source: AGHT+IGHILtzOHKu/xnfwr24UkOR6vkT7e9vLWHdOFJmAPcnVR0/UyHLIlLBk551tmX0Tr4FlZMdcg== X-Received: by 2002:a17:906:315b:b0:aa5:3853:553e with SMTP id a640c23a62f3a-aa58103dbb5mr2664708966b.47.1733158766635; Mon, 02 Dec 2024 08:59:26 -0800 (PST) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Carlo Nonato , Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v11 02/12] xen/arm: add initial support for LLC coloring on arm64 Date: Mon, 2 Dec 2024 17:59:11 +0100 Message-ID: <20241202165921.249585-3-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241202165921.249585-1-carlo.nonato@minervasys.tech> References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit LLC coloring needs to know the last level cache layout in order to make the best use of it. This can be probed by inspecting the CLIDR_EL1 register, so the Last Level is defined as the last level visible by this register. Note that this excludes system caches in some platforms. Static memory allocation and cache coloring are incompatible because static memory can't be guaranteed to use only colors assigned to the domain. Panic during DomUs creation when both are enabled. Based on original work from: Luca Miccio Signed-off-by: Carlo Nonato Signed-off-by: Marco Solieri Reviewed-by: Michal Orzel Acked-by: Jan Beulich --- v11: - removed useless #define from processor.h v10: - moved CONFIG_NUMA check in arch/arm/Kconfig v9: - no changes v8: - no changes v7: - only minor changes v6: - get_llc_way_size() now checks for at least separate I/D caches v5: - used - instead of _ for filenames - moved static-mem check in this patch - moved dom0 colors parsing in next patch - moved color allocation and configuration in next patch - moved check_colors() in next patch - colors are now printed in short form v4: - added "llc-coloring" cmdline option for the boot-time switch - dom0 colors are now checked during domain init as for any other domain - fixed processor.h masks bit width - check for overflow in parse_color_config() - check_colors() now checks also that colors are sorted and unique --- docs/misc/cache-coloring.rst | 14 +++++ xen/arch/arm/Kconfig | 1 + xen/arch/arm/Makefile | 1 + xen/arch/arm/dom0less-build.c | 6 +++ xen/arch/arm/include/asm/processor.h | 15 ++++++ xen/arch/arm/llc-coloring.c | 79 ++++++++++++++++++++++++++++ xen/arch/arm/setup.c | 3 ++ xen/common/llc-coloring.c | 2 +- xen/include/xen/llc-coloring.h | 4 ++ 9 files changed, 124 insertions(+), 1 deletion(-) create mode 100644 xen/arch/arm/llc-coloring.c diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst index 371f21a0e7..12972dbb2c 100644 --- a/docs/misc/cache-coloring.rst +++ b/docs/misc/cache-coloring.rst @@ -113,6 +113,20 @@ Auto-probing of LLC specs LLC size and number of ways are probed automatically by default. +In the Arm implementation, this is done by inspecting the CLIDR_EL1 register. +This means that other system caches that aren't visible there are ignored. + LLC specs can be manually set via the above command line parameters. This bypasses any auto-probing and it's used to overcome failing situations, such as flawed probing logic, or for debugging/testing purposes. + +Known issues and limitations +**************************** + +"xen,static-mem" isn't supported when coloring is enabled +######################################################### + +In the domain configuration, "xen,static-mem" allows memory to be statically +allocated to the domain. This isn't possible when LLC coloring is enabled, +because that memory can't be guaranteed to use only colors assigned to the +domain. diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 23bbc91aad..4ec9ef8334 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -8,6 +8,7 @@ config ARM_64 depends on !ARM_32 select 64BIT select HAS_FAST_MULTIPLY + select HAS_LLC_COLORING if !NUMA config ARM def_bool y diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index e4ad1ce851..ccbfc61f88 100644 --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -35,6 +35,7 @@ obj-$(CONFIG_IOREQ_SERVER) += ioreq.o obj-y += irq.o obj-y += kernel.init.o obj-$(CONFIG_LIVEPATCH) += livepatch.o +obj-$(CONFIG_LLC_COLORING) += llc-coloring.o obj-$(CONFIG_MEM_ACCESS) += mem_access.o obj-y += mm.o obj-y += monitor.o diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index f328a044e9..d93a85434e 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -5,6 +5,7 @@ #include #include #include +#include #include #include #include @@ -890,7 +891,12 @@ void __init create_domUs(void) panic("No more domain IDs available\n"); if ( dt_find_property(node, "xen,static-mem", NULL) ) + { + if ( llc_coloring_enabled ) + panic("LLC coloring and static memory are incompatible\n"); + flags |= CDF_staticmem; + } if ( dt_property_read_bool(node, "direct-map") ) { diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h index 8e02410465..60b587db69 100644 --- a/xen/arch/arm/include/asm/processor.h +++ b/xen/arch/arm/include/asm/processor.h @@ -18,6 +18,21 @@ #define CTR_IDC_SHIFT 28 #define CTR_DIC_SHIFT 29 +/* CCSIDR Current Cache Size ID Register */ +#define CCSIDR_LINESIZE_MASK _AC(0x7, UL) +#define CCSIDR_NUMSETS_SHIFT 13 +#define CCSIDR_NUMSETS_MASK _AC(0x3fff, UL) +#define CCSIDR_NUMSETS_SHIFT_FEAT_CCIDX 32 +#define CCSIDR_NUMSETS_MASK_FEAT_CCIDX _AC(0xffffff, UL) + +/* CSSELR Cache Size Selection Register */ +#define CSSELR_LEVEL_SHIFT 1 + +/* CLIDR Cache Level ID Register */ +#define CLIDR_CTYPEn_SHIFT(n) (3 * ((n) - 1)) +#define CLIDR_CTYPEn_MASK _AC(0x7, UL) +#define CLIDR_CTYPEn_LEVELS 7 + #define ICACHE_POLICY_VPIPT 0 #define ICACHE_POLICY_AIVIVT 1 #define ICACHE_POLICY_VIPT 2 diff --git a/xen/arch/arm/llc-coloring.c b/xen/arch/arm/llc-coloring.c new file mode 100644 index 0000000000..6c8fa6b576 --- /dev/null +++ b/xen/arch/arm/llc-coloring.c @@ -0,0 +1,79 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Last Level Cache (LLC) coloring support for ARM + * + * Copyright (C) 2024, Advanced Micro Devices, Inc. + * Copyright (C) 2024, Minerva Systems SRL + */ +#include +#include +#include + +#include +#include + +/* Return the LLC way size by probing the hardware */ +unsigned int __init get_llc_way_size(void) +{ + register_t ccsidr_el1; + register_t clidr_el1 = READ_SYSREG(CLIDR_EL1); + register_t csselr_el1 = READ_SYSREG(CSSELR_EL1); + register_t id_aa64mmfr2_el1 = READ_SYSREG(ID_AA64MMFR2_EL1); + uint32_t ccsidr_numsets_shift = CCSIDR_NUMSETS_SHIFT; + uint32_t ccsidr_numsets_mask = CCSIDR_NUMSETS_MASK; + unsigned int n, line_size, num_sets; + + for ( n = CLIDR_CTYPEn_LEVELS; n != 0; n-- ) + { + uint8_t ctype_n = (clidr_el1 >> CLIDR_CTYPEn_SHIFT(n)) & + CLIDR_CTYPEn_MASK; + + /* Unified cache (see Arm ARM DDI 0487J.a D19.2.27) */ + if ( ctype_n == 0b100 ) + break; + } + + if ( n == 0 ) + return 0; + + WRITE_SYSREG((n - 1) << CSSELR_LEVEL_SHIFT, CSSELR_EL1); + isb(); + + ccsidr_el1 = READ_SYSREG(CCSIDR_EL1); + + /* Arm ARM: (Log2(Number of bytes in cache line)) - 4 */ + line_size = 1U << ((ccsidr_el1 & CCSIDR_LINESIZE_MASK) + 4); + + /* If FEAT_CCIDX is enabled, CCSIDR_EL1 has a different bit layout */ + if ( (id_aa64mmfr2_el1 >> ID_AA64MMFR2_CCIDX_SHIFT) & 0x7 ) + { + ccsidr_numsets_shift = CCSIDR_NUMSETS_SHIFT_FEAT_CCIDX; + ccsidr_numsets_mask = CCSIDR_NUMSETS_MASK_FEAT_CCIDX; + } + + /* Arm ARM: (Number of sets in cache) - 1 */ + num_sets = ((ccsidr_el1 >> ccsidr_numsets_shift) & ccsidr_numsets_mask) + 1; + + printk(XENLOG_INFO "LLC found: L%u (line size: %u bytes, sets num: %u)\n", + n, line_size, num_sets); + + /* Restore value in CSSELR_EL1 */ + WRITE_SYSREG(csselr_el1, CSSELR_EL1); + isb(); + + return line_size * num_sets; +} + +void __init arch_llc_coloring_init(void) +{ +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 2e27af4560..568a49b274 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include @@ -326,6 +327,8 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr) printk("Command line: %s\n", cmdline); cmdline_parse(cmdline); + llc_coloring_init(); + setup_mm(); vm_init(); diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c index 54d76e3aca..5139890e3d 100644 --- a/xen/common/llc-coloring.c +++ b/xen/common/llc-coloring.c @@ -16,7 +16,7 @@ * 0: explicitly disabled through cmdline * 1: explicitly enabled through cmdline */ -static int8_t __ro_after_init llc_coloring_enabled = -1; +int8_t __ro_after_init llc_coloring_enabled = -1; boolean_param("llc-coloring", llc_coloring_enabled); static unsigned int __initdata llc_size; diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h index 0acd8d0ad6..ee0c58ab1c 100644 --- a/xen/include/xen/llc-coloring.h +++ b/xen/include/xen/llc-coloring.h @@ -11,10 +11,14 @@ struct domain; #ifdef CONFIG_LLC_COLORING +extern int8_t llc_coloring_enabled; + void llc_coloring_init(void); void dump_llc_coloring_info(void); void domain_dump_llc_colors(const struct domain *d); #else +#define llc_coloring_enabled false + static inline void llc_coloring_init(void) {} static inline void dump_llc_coloring_info(void) {} static inline void domain_dump_llc_colors(const struct domain *d) {} -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 16:59:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 16:59:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846761.1261901 (Exim 4.92) (envelope-from ) id 1tI9lh-0006xI-MG; Mon, 02 Dec 2024 16:59:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846761.1261901; Mon, 02 Dec 2024 16:59: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 1tI9lh-0006xB-JL; Mon, 02 Dec 2024 16:59:29 +0000 Received: by outflank-mailman (input) for mailman id 846761; Mon, 02 Dec 2024 16:59: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 1tI9lg-0006wq-5r for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 16:59: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 c8f8e1d8-b0ce-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 17:59:25 +0100 (CET) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-aa52bb7beceso522807766b.3 for ; Mon, 02 Dec 2024 08:59:25 -0800 (PST) Received: from carlo-ubuntu.home.arpa (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5998e64c4sm526802666b.97.2024.12.02.08.59.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 08:59: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: c8f8e1d8-b0ce-11ef-a0d2-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1733158765; x=1733763565; 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=+rJsfH+V+Soptn6R7o1ALXaGMOegZkt3cFlTFnOfJ54=; b=OABK8SfX9IoNuQ6L2IdyJVvhMwZh1SfMNFJU9RpDtdWLqzKNHucC6kXnDLlW58USib Wxv6ryrc0ZndMXqqr23MGCv/WZ0eJEtCwludAo/5ehyj0dHUXvEx7LNxvqhYFZXWQSSg CeIowsg6w1L4g+46zpzNCGTCRPjKVITavBzSB85wrTF2jm4p3n4faDN16DBR1Pxfz9Df ZfvYf0413h1pW7qcntuBJ6aiLLR92Avpo1WLdUPBhSBELTAb+GT1Avi8uLnNEUSvq0x8 DkAoAmokY2tWkOYqJD7firY6ZlRlQMTQhpG6SLtikrETXllDo2iT6Fz24jKrH/alHAsc RWDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733158765; x=1733763565; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+rJsfH+V+Soptn6R7o1ALXaGMOegZkt3cFlTFnOfJ54=; b=IQBQyaOvO8OX+ky7LV+OnIse/Vya9vQUAxLscZdG6Ru/Iin4XxHm066qPqRzKM+cyb C6pHwm8wJtmP/Jf2ytq/xdDG7mZrYRyFfaDNgX/8WF1PE+PEMkyyOsLPR4y73NnKX/1W bGnM73+olJc92GQQ2PizMQ+BFhCVqO9p8MquoUCNDm052tcpMlgiOEWB2ViY7HtixZEM VaPYC78W22TJi5ryXkiw89FLB+mlSeGkHvBA9RRBrTdI16HCTJ6iBmDBCWQ0VVnWPwCt 4sesI83IVQLa7T3vv24U+MJifR62cR5/vTVry3aBZNYHV1AoneYTEOsd53V+SjkCc/Zn yfXQ== X-Gm-Message-State: AOJu0Yyxa42YNzNTs7DIOow2Qj+E3/8uT5Xgtn/EMgTR4ba3EWDn7BG6 23EVdWsD/wwnzxLuhHT9tYoNOVdL0KZweHfaDLQZXfgA596KU0KcchAw/CqR82mKIGbTd1H/O/W 7 X-Gm-Gg: ASbGncvVI5Wuu3rAod6eOPunCYpUwf7VpHvfuoXKgVqEHSlGrNuJifJ8qCKUZdoAxKK 2zl++H1EUZ3J6U6mNQvl2I19+iuVyMSKihyVocc9+vEkLNPbNyAap2zuRqP/VSvZDHbRI6uTqCX y+oWuNm/u2TRjk7N6KOce+NyTTMdRNF0AHnYpoAPe/CAE2HBYfV6mPZHzif6wXTopWVheq9ONnP mqWxV/fB3vX7/5HVcoWaXv7ptgg3wm2MaYn7rD0WNypcovU1OlncxDRhi2t9AAnRXzRj4zfgSSV DH+PTys6/0Mu/B+N67/KRB5GEFVI2stQ8ffpSUm52dpPf7VCs4JR X-Google-Smtp-Source: AGHT+IFQI3QBUh10pKtPQ9/85JLzaWgm+DrhqsxXhrUseAfmCYZB3jvREbh8ySpOyIry13D8tyhFEA== X-Received: by 2002:a17:906:3d2a:b0:aa5:3423:2dfe with SMTP id a640c23a62f3a-aa580f33384mr1969780166b.25.1733158764714; Mon, 02 Dec 2024 08:59:24 -0800 (PST) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Carlo Nonato , Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Anthony PERARD , Nick Rosbrook , George Dunlap , Juergen Gross Subject: [PATCH v11 00/12] Arm cache coloring Date: Mon, 2 Dec 2024 17:59:09 +0100 Message-ID: <20241202165921.249585-1-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Shared caches in multi-core CPU architectures represent a problem for predictability of memory access latency. This jeopardizes applicability of many Arm platform in real-time critical and mixed-criticality scenarios. We introduce support for cache partitioning with page coloring, a transparent software technique that enables isolation between domains and Xen, and thus avoids cache interference. When creating a domain, a simple syntax (e.g. `0-3` or `4-11`) allows the user to define assignments of cache partitions ids, called colors, where assigning different colors guarantees no mutual eviction on cache will ever happen. This instructs the Xen memory allocator to provide the i-th color assignee only with pages that maps to color i, i.e. that are indexed in the i-th cache partition. The proposed implementation supports the dom0less feature. The proposed implementation doesn't support the static-mem feature. The solution has been tested in several scenarios, including Xilinx Zynq MPSoCs. Carlo Nonato (11): xen/common: add cache coloring common code xen/arm: add initial support for LLC coloring on arm64 xen/arm: permit non direct-mapped Dom0 construction xen/arm: add Dom0 cache coloring support xen: extend domctl interface for cache coloring tools: add support for cache coloring configuration xen/arm: add support for cache coloring configuration via device-tree xen/page_alloc: introduce preserved page flags macro xen: add cache coloring allocator for domains xen/arm: make consider_modules() available for xen relocation xen/arm: add cache coloring support for Xen image Luca Miccio (1): xen/arm: add Xen cache colors command line parameter SUPPORT.md | 7 + docs/index.rst | 1 + docs/man/xl.cfg.5.pod.in | 6 + docs/misc/arm/device-tree/booting.txt | 5 + docs/misc/cache-coloring.rst | 248 +++++++++++++++ docs/misc/xen-command-line.pandoc | 70 +++++ tools/golang/xenlight/helpers.gen.go | 16 + tools/golang/xenlight/types.gen.go | 1 + tools/include/libxl.h | 5 + tools/include/xenctrl.h | 9 + tools/libs/ctrl/xc_domain.c | 34 +++ tools/libs/light/libxl_create.c | 18 ++ tools/libs/light/libxl_types.idl | 1 + tools/xl/xl_parse.c | 38 ++- xen/arch/arm/Kconfig | 1 + xen/arch/arm/Makefile | 1 + xen/arch/arm/alternative.c | 30 +- xen/arch/arm/arm32/mmu/mm.c | 95 +----- xen/arch/arm/arm64/mmu/head.S | 58 +++- xen/arch/arm/arm64/mmu/mm.c | 28 +- xen/arch/arm/dom0less-build.c | 60 +--- xen/arch/arm/domain_build.c | 107 ++++++- xen/arch/arm/include/asm/domain_build.h | 1 + xen/arch/arm/include/asm/mm.h | 5 + xen/arch/arm/include/asm/mmu/layout.h | 3 + xen/arch/arm/include/asm/processor.h | 15 + xen/arch/arm/include/asm/setup.h | 3 + xen/arch/arm/llc-coloring.c | 142 +++++++++ xen/arch/arm/mmu/setup.c | 193 +++++++++++- xen/arch/arm/setup.c | 13 +- xen/common/Kconfig | 29 ++ xen/common/Makefile | 1 + xen/common/domain.c | 3 + xen/common/domctl.c | 10 + xen/common/keyhandler.c | 3 + xen/common/llc-coloring.c | 388 ++++++++++++++++++++++++ xen/common/page_alloc.c | 209 ++++++++++++- xen/include/public/domctl.h | 9 + xen/include/xen/llc-coloring.h | 64 ++++ xen/include/xen/sched.h | 5 + xen/include/xen/xmalloc.h | 12 + 41 files changed, 1775 insertions(+), 172 deletions(-) create mode 100644 docs/misc/cache-coloring.rst create mode 100644 xen/arch/arm/llc-coloring.c create mode 100644 xen/common/llc-coloring.c create mode 100644 xen/include/xen/llc-coloring.h -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 16:59:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 16:59:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846772.1261990 (Exim 4.92) (envelope-from ) id 1tI9lq-0000kl-A9; Mon, 02 Dec 2024 16:59:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846772.1261990; Mon, 02 Dec 2024 16:59: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 1tI9lq-0000kD-3s; Mon, 02 Dec 2024 16:59:38 +0000 Received: by outflank-mailman (input) for mailman id 846772; Mon, 02 Dec 2024 16:59: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 1tI9lp-0006x4-1m for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 16:59:37 +0000 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [2a00:1450:4864:20::633]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cee59eaa-b0ce-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 17:59:35 +0100 (CET) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-aa549d9dffdso738908866b.2 for ; Mon, 02 Dec 2024 08:59:35 -0800 (PST) Received: from carlo-ubuntu.home.arpa (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5998e64c4sm526802666b.97.2024.12.02.08.59.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 08:59: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: cee59eaa-b0ce-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1733158775; x=1733763575; 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=Pagk7URGKJuUs/rn2A1jGcJIDnUg2XZUgAYh+RZjekY=; b=qOW3mCgU3OWgm47gnss4elRvvY4Aws7VCrjynaN1mmVf6huVWHbKfDLdPMqGpaigyf 7d0xSM6xfIvm1JHBvMr0tW0HidxTgXLXmgOH0ZQP26WKZQUzCb2EXYEerEZGWLn2422U bmKlqJAbXVl9ltXyz3x/FuvM6sDJu9hhxkKarKg3y55RpQPuzpAQ536+AWpwIchsd3up 4gLCZudmhCKK8Ax0RPmzHXtrEh3oMYbaZIMNZiHVUiAyg/fJwodXvS90gsv3KFzzDEV4 940TA6HDUFw2fLm2ICS5KMpn3vEZfKc5B6w7r7rqvUh87UZkEjJMLDl0gIvEVtyKWikB y8Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733158775; x=1733763575; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Pagk7URGKJuUs/rn2A1jGcJIDnUg2XZUgAYh+RZjekY=; b=e0f9n+qj3LTioLwGoeZ1kHNRRGIaKUzL5bHFsNQcZywqttL3GD5YianBPuSpcL+cB4 MOfRYyZ2nJ7Mi5fKlAr74N57JopO7ckrIcauZfd9XS+EZSudGhvhDXL28WRGkz528lLP jAoOelJfxmeMm87gYIUnhJtM4j3HdumFymD2VnzhxHuYadJavsbcnh3OhTU28Ga3313h IRpWEwmPgVNw9voVwHloO/13lGLviwqwpzQAte+vE1kbSoXARZT4B8XvtUkPxV4oXE0g g8kCkLJF4qFDS0qZjJPKEbEMZFckKzhWN2YRNO2nDqiixMElVV1/fmXAGKLiT9QJAQrm OL2A== X-Gm-Message-State: AOJu0YzfA4bbEdF/nZmp8oG0ZRldVy/X8lmpr4a/AXvZuPDzCaFotg2B gwTvEPFGDogXSkE1Z2dUVgI05N3o+M6Op5iMn+fnOL/ivbpxxTyOf+mfu0rLOKcMqTMz+zVeIpq 4 X-Gm-Gg: ASbGncsZmsgctVXcAv0vQRYZiBsQAsMV/k7DiCqH2WlkJm4A5pqr/CjWeGkpvFx/gVD OcG9g2GmatBLXx6TD6yHQKnUaDzZvtrCITiLJDBUQH06unVxP1SqhoorhGzjvkbGH6lijUYbaFs LyuHdYzhEVtRdwyyl95U3yuFoi5Z6c1H6TSZaYNR6XiEso3l5YQeHVfqvSCL6hlfUo2ph+F/E/i WmNHD1h9rW5s/ZK1KObgdHu2U+9MQ7WgEI7qNfu+zNXz9vfTZ2703HD2bALk/hjv4PPN8yJZndT euYFDtuecNwc2tD5BDuzGp0I2DdSXLkRvfrt5IT3sPNF3p5hZLxd X-Google-Smtp-Source: AGHT+IHqanNwJRkV0inBQ2YdQNsACfSn8h1bYFVsTBn8btuIFrbCKnK748o/hg+sTWcfgvVbkaZ1lQ== X-Received: by 2002:a17:906:3096:b0:aa5:3782:53af with SMTP id a640c23a62f3a-aa580f57d1dmr2144670766b.27.1733158774671; Mon, 02 Dec 2024 08:59:34 -0800 (PST) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Luca Miccio , Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Carlo Nonato Subject: [PATCH v11 10/12] xen/arm: add Xen cache colors command line parameter Date: Mon, 2 Dec 2024 17:59:19 +0100 Message-ID: <20241202165921.249585-11-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241202165921.249585-1-carlo.nonato@minervasys.tech> References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Luca Miccio Add a new command line parameter to configure Xen cache colors. These colors are dumped together with other coloring info. Benchmarking the VM interrupt response time provides an estimation of LLC usage by Xen's most latency-critical runtime task. Results on Arm Cortex-A53 on Xilinx Zynq UltraScale+ XCZU9EG show that one color, which reserves 64 KiB of L2, is enough to attain best responsiveness: - Xen 1 color latency: 3.1 us - Xen 2 color latency: 3.1 us Since this is the most common target for Arm cache coloring, the default amount of Xen colors is set to one. More colors are instead very likely to be needed on processors whose L1 cache is physically-indexed and physically-tagged, such as Cortex-A57. In such cases, coloring applies to L1 also, and there typically are two distinct L1-colors. Therefore, reserving only one color for Xen would senselessly partitions a cache memory that is already private, i.e. underutilize it. Signed-off-by: Luca Miccio Signed-off-by: Marco Solieri Signed-off-by: Carlo Nonato Reviewed-by: Jan Beulich --- v11: - no changes v10: - no changes v9: - no changes v8: - added bound check on xen_colors in llc_coloring_init() v7: - removed XEN_DEFAULT_COLOR - XEN_DEFAULT_NUM_COLORS is now used in a for loop to set xen default colors --- docs/misc/cache-coloring.rst | 2 ++ docs/misc/xen-command-line.pandoc | 10 ++++++++++ xen/common/llc-coloring.c | 29 +++++++++++++++++++++++++++++ 3 files changed, 41 insertions(+) diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst index 5224b27afe..e156062aa2 100644 --- a/docs/misc/cache-coloring.rst +++ b/docs/misc/cache-coloring.rst @@ -115,6 +115,8 @@ Specific documentation is available at `docs/misc/xen-command-line.pandoc`. +----------------------+-------------------------------+ | ``buddy-alloc-size`` | Buddy allocator reserved size | +----------------------+-------------------------------+ +| ``xen-llc-colors`` | Xen color configuration | ++----------------------+-------------------------------+ Colors selection format *********************** diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 3a70c49c05..992e1f993e 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -2923,6 +2923,16 @@ mode. **WARNING: `x2apic_phys` is deprecated and superseded by `x2apic-mode`. The latter takes precedence if both are set.** +### xen-llc-colors (arm64) +> `= List of [ | - ]` + +> Default: `0: the lowermost color` + +Specify Xen LLC color configuration. This options is available only when +`CONFIG_LLC_COLORING` is enabled. +Two colors are most likely needed on platforms where private caches are +physically indexed, e.g. the L1 instruction cache of the Arm Cortex-A57. + ### xenheap_megabytes (arm32) > `= ` diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c index 0f22a9b72c..2e7c0f505d 100644 --- a/xen/common/llc-coloring.c +++ b/xen/common/llc-coloring.c @@ -11,6 +11,7 @@ #include #define NR_LLC_COLORS (1U << CONFIG_LLC_COLORS_ORDER) +#define XEN_DEFAULT_NUM_COLORS 1 /* * -1: not specified (disabled unless llc-size and llc-nr-ways present) @@ -32,6 +33,9 @@ static unsigned int __ro_after_init default_colors[NR_LLC_COLORS]; static unsigned int __initdata dom0_colors[NR_LLC_COLORS]; static unsigned int __initdata dom0_num_colors; +static unsigned int __ro_after_init xen_colors[NR_LLC_COLORS]; +static unsigned int __ro_after_init xen_num_colors; + #define mfn_color_mask (max_nr_colors - 1) #define mfn_to_color(mfn) (mfn_x(mfn) & mfn_color_mask) @@ -90,6 +94,13 @@ static int __init parse_dom0_colors(const char *s) } custom_param("dom0-llc-colors", parse_dom0_colors); +static int __init parse_xen_colors(const char *s) +{ + return parse_color_config(s, xen_colors, ARRAY_SIZE(xen_colors), + &xen_num_colors); +} +custom_param("xen-llc-colors", parse_xen_colors); + static void print_colors(const unsigned int colors[], unsigned int num_colors) { unsigned int i; @@ -173,6 +184,22 @@ void __init llc_coloring_init(void) for ( i = 0; i < max_nr_colors; i++ ) default_colors[i] = i; + if ( !xen_num_colors ) + { + unsigned int i; + + xen_num_colors = MIN(XEN_DEFAULT_NUM_COLORS, max_nr_colors); + + printk(XENLOG_WARNING + "Xen LLC color config not found. Using first %u colors\n", + xen_num_colors); + for ( i = 0; i < xen_num_colors; i++ ) + xen_colors[i] = i; + } + else if ( xen_num_colors > max_nr_colors || + !check_colors(xen_colors, xen_num_colors) ) + panic("Bad LLC color config for Xen\n"); + arch_llc_coloring_init(); } @@ -183,6 +210,8 @@ void dump_llc_coloring_info(void) printk("LLC coloring info:\n"); printk(" Number of LLC colors supported: %u\n", max_nr_colors); + printk(" Xen LLC colors (%u): ", xen_num_colors); + print_colors(xen_colors, xen_num_colors); } void domain_dump_llc_colors(const struct domain *d) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 16:59:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 16:59:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846771.1261981 (Exim 4.92) (envelope-from ) id 1tI9lp-0000UF-0V; Mon, 02 Dec 2024 16:59:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846771.1261981; Mon, 02 Dec 2024 16:59: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 1tI9lo-0000Tz-Pz; Mon, 02 Dec 2024 16:59:36 +0000 Received: by outflank-mailman (input) for mailman id 846771; Mon, 02 Dec 2024 16:59: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 1tI9ln-0006x4-9c for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 16:59:35 +0000 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [2a00:1450:4864:20::634]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cdcea3f1-b0ce-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 17:59:33 +0100 (CET) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-aa543c4db92so666974066b.0 for ; Mon, 02 Dec 2024 08:59:33 -0800 (PST) Received: from carlo-ubuntu.home.arpa (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5998e64c4sm526802666b.97.2024.12.02.08.59.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 08:59: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: cdcea3f1-b0ce-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1733158773; x=1733763573; 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=Jo1+hlLxBc+2E+3aaQJBdv0vb2kf6V0j/TqdNW1tAOE=; b=V/hCI906gyUME2CtsMSrQvcJpfmcETVyGJyIWfdJCJ+Dmym0H4sLHnF3tUIZFPceER 2GVX5lzZCB/8ugVb6p6YTsWq2tQTjF3Br+4i5XzTbqAanJgYcguTlGIWucwPXXCk6O7F lKcjmwA2cCWk6CKcx5vkUBPhfegSZ3uY3zC+7FrL1ZPRAIMQyAYf3y04sWMUcF3OXrCS RHMW6y1oAUDBiLTlnU0NmoM8nySXBwMDVaod62TdtfGYLcXyaC8Kz8czeb5D+BccA0Xf Z87eMwkquz8ktO4fEYodQm0d6ip5sKNfnDrIjkhCbX0Q9RXsIS22PSkh+NfMvapFJ3r5 hefw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733158773; x=1733763573; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Jo1+hlLxBc+2E+3aaQJBdv0vb2kf6V0j/TqdNW1tAOE=; b=MkhlMgIE5XcyS4l01fnLbpSAwzugFjHML9K3zW4p7br0ihAOxvy0x3ZUZTwgf2lCaL SCCWSsGHp82n4Ggbuy+F4Mq5WQO0ltIwWstRnxznKUiMK9ZOfV++ZCbHO6Y1PsIACsBW IMj98SfHRmasXmTYx49MiNiVa9N+DKwAoW9ZdlxNX0WYWMKmkRdrNt+OEZ2SYnKWxerb 3rW7nPIS0YD/qiRrmQZ4XOjcEH/hH71Y2RweZ4NAm+LU3mdNZ+HXY8MIB66kU3WrIGtZ f7U192j5yhKBQFW6QpQz/gmCd6nRyVTxo2Tsj54GFriIFYmdkQtitgRFqo/nXGf9gtp5 Pi5w== X-Gm-Message-State: AOJu0YxHs1u1CcQVcflK9Jv55ZTbhxDzqRHYKu2+qfFOwownz3yKiHtU dZ4EhIh6xgnKb65DiJdpxjtkNfRH9nWpQUxZATO6QoN12hd4juOcYcTmFYLeTe8fD6Aj0+ck4hP a X-Gm-Gg: ASbGnctdbcww/jxqsw2j/Eq4YEiNDH3qRe14jxvZ0t5gZCKbw8Q/J2P3DRHyb/NcOXA +i9+hyzduPqoT3V17SDFA3DtS2OfCqy8Jwl5PiJbk9WjJz0xZcEIqrPsdLTdDf7JePF0mZryHdz IpXxj/RX7hbJuX7tV5hlWShNvCb9vgNm6yoI78Hx4LLP10mDXAC1ELEjwsYPvIcV3u7gLQHZ7P/ Fv9yJ4D5uSSR8nAWyrn5YabPQDQJ6gxZgNZaosu8/Eq/8PHKdnwf2VYpVDv4KlYuW1HZTS60iOe ajbhl36QYp3LK7iEvzjLnVsj84yECE+xvJxP+EC0JbMIr5byEAPg X-Google-Smtp-Source: AGHT+IFR0lxo0qW7rgGGz6p/lTSVqQksARCF+uwg/BOh7xiEKCWmRLJ2vEox2DuIuRXNxSvX4lKEFQ== X-Received: by 2002:a17:906:329a:b0:aa5:1d08:dacf with SMTP id a640c23a62f3a-aa580f01a6amr2077894266b.13.1733158772840; Mon, 02 Dec 2024 08:59:32 -0800 (PST) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Carlo Nonato , Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v11 08/12] xen/page_alloc: introduce preserved page flags macro Date: Mon, 2 Dec 2024 17:59:17 +0100 Message-ID: <20241202165921.249585-9-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241202165921.249585-1-carlo.nonato@minervasys.tech> References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit PGC_static and PGC_extra need to be preserved when assigning a page. Define a new macro that groups those flags and use it instead of or'ing every time. Signed-off-by: Carlo Nonato --- v11: - removed PGC_broken from PGC_preserved - removed PGC preservation from mark_page_free() v10: - fixed commit message v9: - add PGC_broken to PGC_preserved - clear PGC_extra in alloc_domheap_pages() only if MEMF_no_refcount is set v8: - fixed PGC_extra ASSERT fail in alloc_domheap_pages() by removing PGC_extra before freeing v7: - PGC_preserved used also in mark_page_free() v6: - preserved_flags renamed to PGC_preserved - PGC_preserved is used only in assign_pages() v5: - new patch --- xen/common/page_alloc.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 55d561e93c..e73b404169 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -161,6 +161,7 @@ #endif #define PGC_no_buddy_merge PGC_static +#define PGC_preserved (PGC_extra | PGC_static) #ifndef PGT_TYPE_INFO_INITIALIZER #define PGT_TYPE_INFO_INITIALIZER 0 @@ -1447,8 +1448,7 @@ static bool mark_page_free(struct page_info *pg, mfn_t mfn) break; case PGC_state_offlining: - pg->count_info = (pg->count_info & PGC_broken) | - PGC_state_offlined; + pg->count_info = (pg->count_info & PGC_broken) | PGC_state_offlined; pg_offlined = true; break; @@ -2382,7 +2382,7 @@ int assign_pages( for ( i = 0; i < nr; i++ ) { - ASSERT(!(pg[i].count_info & ~(PGC_extra | PGC_static))); + ASSERT(!(pg[i].count_info & ~PGC_preserved)); if ( pg[i].count_info & PGC_extra ) extra_pages++; } @@ -2442,7 +2442,7 @@ int assign_pages( page_set_owner(&pg[i], d); smp_wmb(); /* Domain pointer must be visible before updating refcnt. */ pg[i].count_info = - (pg[i].count_info & (PGC_extra | PGC_static)) | PGC_allocated | 1; + (pg[i].count_info & PGC_preserved) | PGC_allocated | 1; page_list_add_tail(&pg[i], page_to_list(d, &pg[i])); } @@ -2501,6 +2501,14 @@ struct page_info *alloc_domheap_pages( } if ( assign_page(pg, order, d, memflags) ) { + if ( memflags & MEMF_no_refcount ) + { + unsigned long i; + + for ( i = 0; i < (1UL << order); i++ ) + pg[i].count_info &= ~PGC_extra; + } + free_heap_pages(pg, order, memflags & MEMF_no_scrub); return NULL; } @@ -2555,6 +2563,7 @@ void free_domheap_pages(struct page_info *pg, unsigned int order) { ASSERT(d->extra_pages); d->extra_pages--; + pg[i].count_info &= ~PGC_extra; } } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 16:59:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 16:59:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846767.1261960 (Exim 4.92) (envelope-from ) id 1tI9lm-0008Lb-OJ; Mon, 02 Dec 2024 16:59:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846767.1261960; Mon, 02 Dec 2024 16: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 1tI9lm-0008KW-Jd; Mon, 02 Dec 2024 16:59:34 +0000 Received: by outflank-mailman (input) for mailman id 846767; Mon, 02 Dec 2024 16:59: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 1tI9lk-0006wq-Cq for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 16:59:32 +0000 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [2a00:1450:4864:20::130]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ccaa52d0-b0ce-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 17:59:31 +0100 (CET) Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-53de579f775so6235926e87.2 for ; Mon, 02 Dec 2024 08:59:31 -0800 (PST) Received: from carlo-ubuntu.home.arpa (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5998e64c4sm526802666b.97.2024.12.02.08.59.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 08:59: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: ccaa52d0-b0ce-11ef-a0d2-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1733158771; x=1733763571; 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=gqhiaN/uGHCe7Mq6SZhbOqUmu19X+lhLAzCqw3rcUEU=; b=RcKXyJ8DaJ2JfD4csSjF6PAkYHjMQrSjY9wSqqrSaz9QGwJs7WLc+QdCv8raVOxMBc 8WRzMI+nKQi8b+px0AT5+I/wazQCeZt9xx2/i7zA3i+Xhvj3AnnTU2jDV3+3KvoV05OL FfZ5jP3thy4SsV1AkzcvWTODubz+KO9+gh/ScLR/L054KKBMVxbP1KoOaJfBBpYDNyI9 n3Y4bJLARscE7gGWONB3CQHalLgpiXWcFWPErE2d1o12C9FDkcXDI1AsrJZB3GWYodMb oqL0kDlMnNwu33dIL1EEnJ2Cem5g8iGvutVW1OYZd+ICrBZZcWy3fKzO9GnJkZEiEgt7 IfcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733158771; x=1733763571; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gqhiaN/uGHCe7Mq6SZhbOqUmu19X+lhLAzCqw3rcUEU=; b=fxdkscXYQ3MC+oIc3FrnK6s/gkjCQkyXmrCMQGC5NWyP0yMWTkT4yRn8FqM8j0iYa6 yTulT6P7xLmfBIbXAT8EiBCr9RTMgRAblNPt6SS3FfT339XD56ZIXGwqEaqKGwSZV80/ 5Ez+zn5Sh67wciJ49JOJ19cgWxhxAqZRLnSC3F51phgAoHMIbywhd0hGmrhN2q1abzcC mNPZSYbHIa4fUTApv8AOFuv3DIjiG8Y2HquJatjAHitt0RY+sqGKrNKsMq7FdzkpWlRM QsdXDRLgg9DugQtqRE/2W+/OsSsV0N9jzDD481S+a2pn6GnBZY7aTvgh6m3zM+mzhx2J wufw== X-Gm-Message-State: AOJu0YxwlgrdeDxaVCep/I2ckdWTFwXld9ElP5QXmukEXjSR0p28WQtm svIRH4xHWMYFlG0GzbkdEQg5Q2nSwPL1pgcBsSTbqjik6rrMRLPt4xMF+uTAkqWmQ8HGLQj1DdE Q X-Gm-Gg: ASbGncv6O1uhRWVzqnJHvZ5X8l12H7yOWjaJt9UxpDTGY3lPgWo80r1LJGvmNGkoFe8 sYNAvR1AQgBa8YGSQC3xVrrJrFxy3AKnybbI6pP+Q7knMer/01TnxVmQ0OHZwThbwrLwEa+5oda nIoBupUHfHP/GJFdMDyEwqK1SXdejOHx/AMadO0B3ivSqSGdJLTHMxXp115yU4Bkfmzr186Kwv5 /w6kpbOhTwIHMxtD5pK+lOVN0MIQeTkJrxmOsVEivhIwX2mDjoMo90wi676YmQAmKXQUN86OjXQ FWbZf79VCcsVPEGQ5TvpZl2o563WQ2zOn7TaV86kNeLOKhu35SVv X-Google-Smtp-Source: AGHT+IFm581PTU/1OI+wUfh3HI4lQknPI4z33Hs16wQMIfYEoLjGSSJ10EF+CJozUSfhvDZ9SFphnA== X-Received: by 2002:ac2:4e04:0:b0:53d:cbaa:86f5 with SMTP id 2adb3069b0e04-53df00ccbb8mr17030885e87.13.1733158770744; Mon, 02 Dec 2024 08:59:30 -0800 (PST) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Carlo Nonato , Anthony PERARD , Nick Rosbrook , George Dunlap , Juergen Gross Subject: [PATCH v11 06/12] tools: add support for cache coloring configuration Date: Mon, 2 Dec 2024 17:59:15 +0100 Message-ID: <20241202165921.249585-7-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241202165921.249585-1-carlo.nonato@minervasys.tech> References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add a new "llc_colors" parameter that defines the LLC color assignment for a domain. The user can specify one or more color ranges using the same syntax used everywhere else for color config described in the documentation. The parameter is defined as a list of strings that represent the color ranges. Documentation is also added. Based on original work from: Luca Miccio Signed-off-by: Carlo Nonato Signed-off-by: Marco Solieri --- v11: - turned unsigned int to uint32_t in xc_domain_set_llc_colors() - return -1 in case of error instead of ENOMEM in xc_domain_set_llc_colors() - added regenerated go bindings v10: - no changes v9: - turned warning into error in case of coloring not enabled v8: - warn the user in case of coloring not supported at hypervisor level v7: - removed unneeded NULL check before xc_hypercall_buffer_free() in xc_domain_set_llc_colors() v6: - no edits v5: - added LIBXL_HAVE_BUILDINFO_LLC_COLORS - moved color configuration in xc_domain_set_llc_colors() cause of the new hypercall v4: - removed overlapping color ranges checks during parsing - moved hypercall buffer initialization in libxenctrl --- docs/man/xl.cfg.5.pod.in | 6 +++++ tools/golang/xenlight/helpers.gen.go | 16 ++++++++++++ tools/golang/xenlight/types.gen.go | 1 + tools/include/libxl.h | 5 ++++ tools/include/xenctrl.h | 9 +++++++ tools/libs/ctrl/xc_domain.c | 34 +++++++++++++++++++++++++ tools/libs/light/libxl_create.c | 18 +++++++++++++ tools/libs/light/libxl_types.idl | 1 + tools/xl/xl_parse.c | 38 +++++++++++++++++++++++++++- 9 files changed, 127 insertions(+), 1 deletion(-) diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index ac3f88fd57..8e1422104e 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -3074,6 +3074,12 @@ raised. =over 4 +=item B + +Specify the Last Level Cache (LLC) color configuration for the guest. +B can be either a single color value or a hypen-separated closed +interval of colors (such as "0-4"). + =item B An optional integer parameter specifying the number of SPIs (Shared diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go index fe5110474d..90846ea8e8 100644 --- a/tools/golang/xenlight/helpers.gen.go +++ b/tools/golang/xenlight/helpers.gen.go @@ -1097,6 +1097,14 @@ if err := x.Iomem[i].fromC(&v); err != nil { return fmt.Errorf("converting field Iomem: %v", err) } } } +x.LlcColors = nil +if n := int(xc.num_llc_colors); n > 0 { +cLlcColors := (*[1<<28]C.uint32_t)(unsafe.Pointer(xc.llc_colors))[:n:n] +x.LlcColors = make([]uint32, n) +for i, v := range cLlcColors { +x.LlcColors[i] = uint32(v) +} +} if err := x.ClaimMode.fromC(&xc.claim_mode);err != nil { return fmt.Errorf("converting field ClaimMode: %v", err) } @@ -1453,6 +1461,14 @@ return fmt.Errorf("converting field Iomem: %v", err) } } } +if numLlcColors := len(x.LlcColors); numLlcColors > 0 { +xc.llc_colors = (*C.uint32_t)(C.malloc(C.size_t(numLlcColors*numLlcColors))) +xc.num_llc_colors = C.int(numLlcColors) +cLlcColors := (*[1<<28]C.uint32_t)(unsafe.Pointer(xc.llc_colors))[:numLlcColors:numLlcColors] +for i,v := range x.LlcColors { +cLlcColors[i] = C.uint32_t(v) +} +} if err := x.ClaimMode.toC(&xc.claim_mode); err != nil { return fmt.Errorf("converting field ClaimMode: %v", err) } diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go index c9e45b306f..e7667f1ce3 100644 --- a/tools/golang/xenlight/types.gen.go +++ b/tools/golang/xenlight/types.gen.go @@ -575,6 +575,7 @@ SchedParams DomainSchedParams Ioports []IoportRange Irqs []uint32 Iomem []IomemRange +LlcColors []uint32 ClaimMode Defbool EventChannels uint32 Kernel string diff --git a/tools/include/libxl.h b/tools/include/libxl.h index 8d32428ea9..f8fe4afd7d 100644 --- a/tools/include/libxl.h +++ b/tools/include/libxl.h @@ -1379,6 +1379,11 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, const libxl_mac *src); */ #define LIBXL_HAVE_BUILDINFO_HVM_SYSTEM_FIRMWARE +/* + * The libxl_domain_build_info has the llc_colors array. + */ +#define LIBXL_HAVE_BUILDINFO_LLC_COLORS 1 + /* * ERROR_REMUS_XXX error code only exists from Xen 4.5, Xen 4.6 and it * is changed to ERROR_CHECKPOINT_XXX in Xen 4.7 diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h index 29617585c5..d6d93a2e8f 100644 --- a/tools/include/xenctrl.h +++ b/tools/include/xenctrl.h @@ -2667,6 +2667,15 @@ int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t timeout, uint32 int xc_domain_cacheflush(xc_interface *xch, uint32_t domid, xen_pfn_t start_pfn, xen_pfn_t nr_pfns); +/* + * Set LLC colors for a domain. + * It can only be used directly after domain creation. An attempt to use it + * afterwards will result in an error. + */ +int xc_domain_set_llc_colors(xc_interface *xch, uint32_t domid, + const uint32_t *llc_colors, + uint32_t num_llc_colors); + #if defined(__arm__) || defined(__aarch64__) int xc_dt_overlay(xc_interface *xch, void *overlay_fdt, uint32_t overlay_fdt_size, uint8_t overlay_op); diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c index e3538ec0ba..2ddc3f4f42 100644 --- a/tools/libs/ctrl/xc_domain.c +++ b/tools/libs/ctrl/xc_domain.c @@ -2195,6 +2195,40 @@ int xc_domain_soft_reset(xc_interface *xch, domctl.domain = domid; return do_domctl(xch, &domctl); } + +int xc_domain_set_llc_colors(xc_interface *xch, uint32_t domid, + const uint32_t *llc_colors, + uint32_t num_llc_colors) +{ + struct xen_domctl domctl = {}; + DECLARE_HYPERCALL_BUFFER(uint32_t, local); + int ret = -1; + + if ( num_llc_colors ) + { + size_t bytes = sizeof(uint32_t) * num_llc_colors; + + local = xc_hypercall_buffer_alloc(xch, local, bytes); + if ( local == NULL ) + { + PERROR("Could not allocate LLC colors for set_llc_colors"); + goto out; + } + memcpy(local, llc_colors, bytes); + set_xen_guest_handle(domctl.u.set_llc_colors.llc_colors, local); + } + + domctl.cmd = XEN_DOMCTL_set_llc_colors; + domctl.domain = domid; + domctl.u.set_llc_colors.num_llc_colors = num_llc_colors; + + ret = do_domctl(xch, &domctl); + +out: + xc_hypercall_buffer_free(xch, local); + + return ret; +} /* * Local variables: * mode: C diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c index edeadd57ef..e03599ea99 100644 --- a/tools/libs/light/libxl_create.c +++ b/tools/libs/light/libxl_create.c @@ -747,6 +747,24 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config, /* A new domain now exists */ *domid = local_domid; + ret = xc_domain_set_llc_colors(ctx->xch, local_domid, + b_info->llc_colors, + b_info->num_llc_colors); + if (ret < 0) { + if (errno == EOPNOTSUPP) { + if (b_info->num_llc_colors > 0) { + LOGED(ERROR, local_domid, + "LLC coloring not enabled in the hypervisor"); + rc = ERROR_FAIL; + goto out; + } + } else { + LOGED(ERROR, local_domid, "LLC colors allocation failed"); + rc = ERROR_FAIL; + goto out; + } + } + rc = libxl__is_domid_recent(gc, local_domid, &recent); if (rc) goto out; diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl index 4e65e6fda5..bd4b8721ff 100644 --- a/tools/libs/light/libxl_types.idl +++ b/tools/libs/light/libxl_types.idl @@ -616,6 +616,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ ("ioports", Array(libxl_ioport_range, "num_ioports")), ("irqs", Array(uint32, "num_irqs")), ("iomem", Array(libxl_iomem_range, "num_iomem")), + ("llc_colors", Array(uint32, "num_llc_colors")), ("claim_mode", libxl_defbool), ("event_channels", uint32), ("kernel", string), diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c index e3a4800f6e..3d85be7dd4 100644 --- a/tools/xl/xl_parse.c +++ b/tools/xl/xl_parse.c @@ -1296,7 +1296,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; + *mca_caps, *smbios, *llc_colors; int num_ioports, num_irqs, num_iomem, num_cpus, num_viridian, num_mca_caps; int num_smbios; int pci_power_mgmt = 0; @@ -1304,6 +1304,7 @@ void parse_config_data(const char *config_source, int pci_permissive = 0; int pci_seize = 0; int i, e; + int num_llc_colors; char *kernel_basename; libxl_domain_create_info *c_info = &d_config->c_info; @@ -1447,6 +1448,41 @@ void parse_config_data(const char *config_source, if (!xlu_cfg_get_long (config, "maxmem", &l, 0)) b_info->max_memkb = l * 1024; + if (!xlu_cfg_get_list(config, "llc_colors", &llc_colors, &num_llc_colors, 0)) { + int cur_index = 0; + + b_info->num_llc_colors = 0; + for (i = 0; i < num_llc_colors; i++) { + uint32_t start = 0, end = 0, k; + + buf = xlu_cfg_get_listitem(llc_colors, i); + if (!buf) { + fprintf(stderr, + "xl: Can't get element %d in LLC color list\n", i); + exit(1); + } + + if (sscanf(buf, "%" SCNu32 "-%" SCNu32, &start, &end) != 2) { + if (sscanf(buf, "%" SCNu32, &start) != 1) { + fprintf(stderr, "xl: Invalid LLC color range: %s\n", buf); + exit(1); + } + end = start; + } else if (start > end) { + fprintf(stderr, + "xl: Start LLC color is greater than end: %s\n", buf); + exit(1); + } + + b_info->num_llc_colors += (end - start) + 1; + b_info->llc_colors = (uint32_t *)realloc(b_info->llc_colors, + sizeof(*b_info->llc_colors) * b_info->num_llc_colors); + + for (k = start; k <= end; k++) + b_info->llc_colors[cur_index++] = k; + } + } + if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) { vcpus = l; if (libxl_cpu_bitmap_alloc(ctx, &b_info->avail_vcpus, l)) { -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 16:59:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 16:59:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846763.1261912 (Exim 4.92) (envelope-from ) id 1tI9li-00074w-7Q; Mon, 02 Dec 2024 16:59:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846763.1261912; Mon, 02 Dec 2024 16:59: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 1tI9li-00074G-1w; Mon, 02 Dec 2024 16:59:30 +0000 Received: by outflank-mailman (input) for mailman id 846763; Mon, 02 Dec 2024 16:59: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 1tI9lh-0006wq-6i for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 16:59:29 +0000 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [2a00:1450:4864:20::52e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cacafa36-b0ce-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 17:59:28 +0100 (CET) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-5cfa1ec3b94so5223153a12.2 for ; Mon, 02 Dec 2024 08:59:28 -0800 (PST) Received: from carlo-ubuntu.home.arpa (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5998e64c4sm526802666b.97.2024.12.02.08.59.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 08:59: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: cacafa36-b0ce-11ef-a0d2-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1733158768; x=1733763568; 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=FuTlneISEoSBSqnNXr83jGC6mPB/G48PgoDktHtlOF0=; b=K40McR3XPkhKWxiIfIxA2DAcHfk3hA5Im1711WxHb0WSUOJshW10DoqWV9UBf+2jp4 vuTCuv8dNko/D71VeJYzOISm+kp3uQUnu5xATFffz8aS7kFYAXIonuVbUPg0sOVJzuCw +6dRpgSsMr2qLqZ+EBo77tnzBu7IgEmbw2Fn005sVKbm1V7WhnTVRv1tULEt39He+6mX IVE66npqSVPiiNHQJtBmsYwUzZ6vXaIrec3w+HpYDOZBD9RlOcWOc67AUOGI3y15zqGb QXAljdoEeJxT05HJh/TEFcaOk2RBcL3ZVKC8NDLV+MuyUpO/R0qT8YWIzFc5Zcf5VCYo /cKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733158768; x=1733763568; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FuTlneISEoSBSqnNXr83jGC6mPB/G48PgoDktHtlOF0=; b=n2N5OiKvIsTzybW+vUJisvkGKXRx+ATpRwv2SB6om3HbQU4R7YGaN/U+J0lFtKTN4T pPxhEPWuwEpl4QSGtCcwtSpsv00I60lWH8KLw0LegkwF/1AXrRsvy8FjkIQiTKoitE6u Sr4ri68pZqZcHzedKPMyX+0tkSUW2E+Z240SGKCPvindeBiO30m+i2xkY6AGQl1ndFxr aH8/r3BoHovjeO3u8EnoGx9oi/fN5TeEDGXDL0ER8AziqgIUlLXE6hx8Ay0AjQ1Gj2l5 JhJ4t3AOw9E+l0fmLRHAbzFf2xFkkyJ/bSxU6f8GgJoVGA5grJ/BopSY/ACNQl7NZzFc 9wvQ== X-Gm-Message-State: AOJu0YxZEiJj8uyOL8RYmCafGQaNviLxA6ZyxIqCtNpadnlmuKkJquIE eb+qkGaHzm22P3kFjw5V4HR+yUDyO+KlbG1GZ+svSFOLivRJK/+fxBfSA0BiS5cprwh1RF1mnyd f X-Gm-Gg: ASbGnctZ2NuIO6QsJT6HGiMbFeCsOFFvo5TB3FpdDlIM8Lzt4sCpn5yuBDwT3E1Mnwd hK5eiiEOGeN/AZWRZkqELAGVLy0cIxo/msbMSyitm6rYzcJB2DCSiTR+Jx8ffh6VkZWNApnGhj9 Rytzbpt/WxOSRTWp4A0+pWOQFpGL4PJgPOtNwy+I+VRQrwBknjQ0z5OQBZgdZB+lU7lHIh2Mk6Y 6Hxsiessq3ia6ngNcKQfK2AeQ1S8feACZlr6rhhuhN1/jHTe3hxG3okYdtZhvHuOWQszlZc2bjV G6B168Tgyk0MMPEryXQgOofURkGpeXEYuS+XaN10yXw47y1HJziW X-Google-Smtp-Source: AGHT+IFSZN81YR3At05jAS8Y5uQq55EBJLmehdRTJEzxbzXI+AUKAbipwqjZXa5+/6ZAgCJN3HW5rQ== X-Received: by 2002:a17:906:3d29:b0:aa5:1699:e25a with SMTP id a640c23a62f3a-aa580ee98eamr1733280466b.10.1733158767753; Mon, 02 Dec 2024 08:59:27 -0800 (PST) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Carlo Nonato , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v11 03/12] xen/arm: permit non direct-mapped Dom0 construction Date: Mon, 2 Dec 2024 17:59:12 +0100 Message-ID: <20241202165921.249585-4-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241202165921.249585-1-carlo.nonato@minervasys.tech> References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Cache coloring requires Dom0 not to be direct-mapped because of its non contiguous mapping nature, so allocate_memory() is needed in this case. 8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a separate module") moved allocate_memory() in dom0less_build.c. In order to use it in Dom0 construction bring it back to domain_build.c and declare it in domain_build.h. Take the opportunity to adapt the implementation of allocate_memory() so that it uses the host layout when called on the hwdom, via find_unallocated_memory(). Signed-off-by: Carlo Nonato --- v11: - GUEST_RAM_BANKS instead of hardcoding the number of banks in allocate_memory() - hwdom_ext_regions -> hwdom_free_mem in allocate_memory() - added a comment in allocate_memory() when skipping small banks v10: - fixed a compilation bug that happened when dom0less support was disabled v9: - no changes v8: - patch adapted to new changes to allocate_memory() v7: - allocate_memory() now uses the host layout when called on the hwdom v6: - new patch --- xen/arch/arm/dom0less-build.c | 44 ----------- xen/arch/arm/domain_build.c | 97 ++++++++++++++++++++++++- xen/arch/arm/include/asm/domain_build.h | 1 + 3 files changed, 94 insertions(+), 48 deletions(-) diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index d93a85434e..67b1503647 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -49,50 +49,6 @@ bool __init is_dom0less_mode(void) return ( !dom0found && domUfound ); } -static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo) -{ - struct membanks *mem = kernel_info_get_mem(kinfo); - unsigned int i; - paddr_t bank_size; - - printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n", - /* Don't want format this as PRIpaddr (16 digit hex) */ - (unsigned long)(kinfo->unassigned_mem >> 20), d); - - mem->nr_banks = 0; - bank_size = MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem); - if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM0_BASE), - bank_size) ) - goto fail; - - bank_size = MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem); - if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM1_BASE), - bank_size) ) - goto fail; - - if ( kinfo->unassigned_mem ) - goto fail; - - for( i = 0; i < mem->nr_banks; i++ ) - { - printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n", - d, - i, - mem->bank[i].start, - mem->bank[i].start + mem->bank[i].size, - /* Don't want format this as PRIpaddr (16 digit hex) */ - (unsigned long)(mem->bank[i].size >> 20)); - } - - return; - -fail: - panic("Failed to allocate requested domain memory." - /* Don't want format this as PRIpaddr (16 digit hex) */ - " %ldKB unallocated. Fix the VMs configurations.\n", - (unsigned long)kinfo->unassigned_mem >> 10); -} - #ifdef CONFIG_VGICV2 static int __init make_gicv2_domU_node(struct kernel_info *kinfo) { diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 2c30792de8..2b8cba9b2f 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -416,7 +416,6 @@ static void __init allocate_memory_11(struct domain *d, } } -#ifdef CONFIG_DOM0LESS_BOOT bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size, alloc_domheap_mem_cb cb, void *extra) { @@ -508,7 +507,6 @@ bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn, return true; } -#endif /* * When PCI passthrough is available we want to keep the @@ -1003,6 +1001,94 @@ out: return res; } +void __init allocate_memory(struct domain *d, struct kernel_info *kinfo) +{ + struct membanks *mem = kernel_info_get_mem(kinfo); + unsigned int i, nr_banks = GUEST_RAM_BANKS; + paddr_t bank_start, bank_size; + struct membanks *hwdom_free_mem = NULL; + const uint64_t bankbase[] = GUEST_RAM_BANK_BASES; + const uint64_t banksize[] = GUEST_RAM_BANK_SIZES; + + printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n", + /* Don't want format this as PRIpaddr (16 digit hex) */ + (unsigned long)(kinfo->unassigned_mem >> 20), d); + + mem->nr_banks = 0; + /* + * Use host memory layout for hwdom. Only case for this is when LLC coloring + * is enabled. + */ + if ( is_hardware_domain(d) ) + { + ASSERT(llc_coloring_enabled); + + hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank, + NR_MEM_BANKS); + if ( !hwdom_free_mem ) + goto fail; + + hwdom_free_mem->max_banks = NR_MEM_BANKS; + + if ( find_unallocated_memory(kinfo, hwdom_free_mem) ) + goto fail; + + nr_banks = hwdom_free_mem->nr_banks; + } + + for ( i = 0; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_banks-- ) + { + if ( is_hardware_domain(d) ) + { + bank_start = hwdom_free_mem->bank[i].start; + bank_size = hwdom_free_mem->bank[i].size; + + /* + * Skip banks that are too small. The first bank must contain + * dom0 kernel + ramdisk + dtb and 128 MB is the same limit used + * in allocate_memory_11(). + */ + if ( bank_size < min_t(paddr_t, kinfo->unassigned_mem, MB(128)) ) + continue; + } + else + { + if ( i >= GUEST_RAM_BANKS ) + goto fail; + + bank_start = bankbase[i]; + bank_size = banksize[i]; + } + + bank_size = MIN(bank_size, kinfo->unassigned_mem); + if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(bank_start), bank_size) ) + goto fail; + } + + if ( kinfo->unassigned_mem ) + goto fail; + + for( i = 0; i < mem->nr_banks; i++ ) + { + printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n", + d, + i, + mem->bank[i].start, + mem->bank[i].start + mem->bank[i].size, + /* Don't want format this as PRIpaddr (16 digit hex) */ + (unsigned long)(mem->bank[i].size >> 20)); + } + + xfree(hwdom_free_mem); + return; + +fail: + panic("Failed to allocate requested domain memory." + /* Don't want format this as PRIpaddr (16 digit hex) */ + " %ldKB unallocated. Fix the VMs configurations.\n", + (unsigned long)kinfo->unassigned_mem >> 10); +} + static int __init handle_pci_range(const struct dt_device_node *dev, uint64_t addr, uint64_t len, void *data) { @@ -1223,7 +1309,7 @@ int __init make_hypervisor_node(struct domain *d, ext_regions->max_banks = NR_MEM_BANKS; - if ( is_domain_direct_mapped(d) ) + if ( domain_use_host_layout(d) ) { if ( !is_iommu_enabled(d) ) res = find_unallocated_memory(kinfo, ext_regions); @@ -2152,7 +2238,10 @@ static int __init construct_dom0(struct domain *d) /* type must be set before allocate_memory */ d->arch.type = kinfo.type; #endif - allocate_memory_11(d, &kinfo); + if ( is_domain_direct_mapped(d) ) + allocate_memory_11(d, &kinfo); + else + allocate_memory(d, &kinfo); find_gnttab_region(d, &kinfo); rc = process_shm_chosen(d, &kinfo); diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h index e712afbc7f..5d77af2e8b 100644 --- a/xen/arch/arm/include/asm/domain_build.h +++ b/xen/arch/arm/include/asm/domain_build.h @@ -11,6 +11,7 @@ bool allocate_domheap_memory(struct domain *d, paddr_t tot_size, alloc_domheap_mem_cb cb, void *extra); bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn, paddr_t tot_size); +void allocate_memory(struct domain *d, struct kernel_info *kinfo); int construct_domain(struct domain *d, struct kernel_info *kinfo); int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit); int make_chosen_node(const struct kernel_info *kinfo); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 16:59:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 16:59:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846773.1261993 (Exim 4.92) (envelope-from ) id 1tI9lr-0000pm-1B; Mon, 02 Dec 2024 16:59:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846773.1261993; Mon, 02 Dec 2024 16:59: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 1tI9lq-0000np-EU; Mon, 02 Dec 2024 16:59:38 +0000 Received: by outflank-mailman (input) for mailman id 846773; Mon, 02 Dec 2024 16:59: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 1tI9lp-0006wq-0U for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 16:59:37 +0000 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [2a00:1450:4864:20::136]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cf78e0e6-b0ce-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 17:59:36 +0100 (CET) Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-53de8ecafeeso4908664e87.1 for ; Mon, 02 Dec 2024 08:59:36 -0800 (PST) Received: from carlo-ubuntu.home.arpa (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5998e64c4sm526802666b.97.2024.12.02.08.59.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 08:59: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: cf78e0e6-b0ce-11ef-a0d2-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1733158775; x=1733763575; 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=SQLU0z+L0dGPs9j3VJOLeVLjnDV4HcwqVQ59IBOieiw=; b=l6secaQPM6CHW3+nmmnL/eFyIXRuh90goQzrmrT6phh58IRCrtrj6uQzpQsZ7+nhM5 XcqCi9EQ6nwXmqUGWNu2emj3dIXSjWhDqdWxPF3uX+5E3/jD3hc8B80nyphE274o7qpM kOzmQTJemldY28GrYMeg0eOxdHgnveekE8PasW/0pohdjTrCCrfC5jyMFKNtS4O5/nCb JZE2gopDieSY9HpDwVruEdG+zzqdoNWDAp84B5fGYTsiHGiATYiN3lzd7D/HG9Cjj8SK BTmFtRWpe4lytzXk7ng2RckRT6HN2HS2b43CPAKSPddvq0OPUYgG79yc6e4QthbHVmWZ F4IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733158775; x=1733763575; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SQLU0z+L0dGPs9j3VJOLeVLjnDV4HcwqVQ59IBOieiw=; b=Gww2ztHHMpZgnvJmP95ano3/5PN3CQmOTdvMd1lG+ZGtPujT+UJPyKsxQqfzyFwVpV dta1mMgH8FiMeCdPl+/xMSG8+g+HCs+dBhYOVjL5DKgJf1dLPnPGiuZodtfvOakyUzmJ mkuy8TXcvb7kJP1t0gwS/9UxJ5YRK7BHVG9pqEjP+zxavaH4uY0czsYZsoc2/ypuFicG x1zury2anvqS+5KC/J1Slcvbc82CFLFoRwIiSYZbnHS37fr9ltPusZrZ5XlLzfbFDMyI ZUev1Ex8TSUmj7ZGFfF0lo41JOzcAq0tHRQ8il1afoY5KG0Fhj44UguCq6aE5VEQhyrw JyNw== X-Gm-Message-State: AOJu0YywZK9//xO+dVBj5+8HD3Q1QjGthoOZnO/1Qtc0JuBQD2WRhH58 4GzIM8AIXHx3x/t5CEJ+TDW6+CKbc45fMWjRorVEMPoWOvjfmf/llGadupr2qTZGZfksTVuVBcO w X-Gm-Gg: ASbGnctRly8hboR8KVBSqJUf5UuH3rWC9GJBTQo9dGLv3o+J+eAeqisIEV06lm/jIo2 dSP5qWy9C0OWLTZygANR5CWbNiPzlRHxcv8pI71xtpFvliKIAYXzP4xCMfF6ydUtElZQ4gVkCyR siS8qA2x30Gp5oU/TbeXVqHceB4kivX8in5rtnnz3PqCcAgUn3You8xzfMMDbkmI8SBEeiSIGYN 5kAjqHLKLuCn/wRu/uOrCHjvTGvB3f73or4vqcfC6eJyUxBbmvtjC+KLEEmPEKEo9Y5mu3FEL1/ g0rUKuKgFR3LfYYP9y0lumFB7CVncGgmevJiWsIz84gEYCLqtI2o X-Google-Smtp-Source: AGHT+IFcthVhkf4BkBdZ3UvYNyO3JNKzXHzfDVFYUXTj/ROlFjZIToNYkja9jc7/mLFmlkM7PuSk2A== X-Received: by 2002:a05:6512:3e1d:b0:539:e12c:bba7 with SMTP id 2adb3069b0e04-53df00a9f2amr12143887e87.12.1733158775555; Mon, 02 Dec 2024 08:59:35 -0800 (PST) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Carlo Nonato , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v11 11/12] xen/arm: make consider_modules() available for xen relocation Date: Mon, 2 Dec 2024 17:59:20 +0100 Message-ID: <20241202165921.249585-12-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241202165921.249585-1-carlo.nonato@minervasys.tech> References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Cache coloring must physically relocate Xen in order to color the hypervisor and consider_modules() is a key function that is needed to find a new available physical address. 672d67f339c0 ("xen/arm: Split MMU-specific setup_mm() and related code out") moved consider_modules() under arm32. Move it to mmu/setup.c and make it non-static so that it can be used outside. Signed-off-by: Carlo Nonato Reviewed-by: Michal Orzel --- v11: - removed useless #include v10: - no changes v9: - no changes v8: - patch adapted to new changes to consider_modules() v7: - moved consider_modules() to arm/mmu/setup.c v6: - new patch --- xen/arch/arm/arm32/mmu/mm.c | 95 +------------------------------- xen/arch/arm/include/asm/setup.h | 3 + xen/arch/arm/mmu/setup.c | 94 +++++++++++++++++++++++++++++++ 3 files changed, 98 insertions(+), 94 deletions(-) diff --git a/xen/arch/arm/arm32/mmu/mm.c b/xen/arch/arm/arm32/mmu/mm.c index 063611412b..903d946f07 100644 --- a/xen/arch/arm/arm32/mmu/mm.c +++ b/xen/arch/arm/arm32/mmu/mm.c @@ -7,6 +7,7 @@ #include #include #include +#include #include #include @@ -31,100 +32,6 @@ static void __init setup_directmap_mappings(unsigned long base_mfn, directmap_virt_end = XENHEAP_VIRT_START + nr_mfns * PAGE_SIZE; } -/* - * Returns the end address of the highest region in the range s..e - * with required size and alignment that does not conflict with the - * modules from first_mod to nr_modules. - * - * For non-recursive callers first_mod should normally be 0 (all - * modules and Xen itself) or 1 (all modules but not Xen). - */ -static paddr_t __init consider_modules(paddr_t s, paddr_t e, - uint32_t size, paddr_t align, - int first_mod) -{ - const struct membanks *reserved_mem = bootinfo_get_reserved_mem(); -#ifdef CONFIG_STATIC_SHM - const struct membanks *shmem = bootinfo_get_shmem(); -#endif - const struct bootmodules *mi = &bootinfo.modules; - int i; - int nr; - - s = (s+align-1) & ~(align-1); - e = e & ~(align-1); - - if ( s > e || e - s < size ) - return 0; - - /* First check the boot modules */ - for ( i = first_mod; i < mi->nr_mods; i++ ) - { - paddr_t mod_s = mi->module[i].start; - paddr_t mod_e = mod_s + mi->module[i].size; - - if ( s < mod_e && mod_s < e ) - { - mod_e = consider_modules(mod_e, e, size, align, i+1); - if ( mod_e ) - return mod_e; - - return consider_modules(s, mod_s, size, align, i+1); - } - } - - /* - * i is the current bootmodule we are evaluating, across all - * possible kinds of bootmodules. - * - * When retrieving the corresponding reserved-memory addresses, we - * need to index the reserved_mem bank starting from 0, and only counting - * the reserved-memory modules. Hence, we need to use i - nr. - */ - nr = mi->nr_mods; - for ( ; i - nr < reserved_mem->nr_banks; i++ ) - { - paddr_t r_s = reserved_mem->bank[i - nr].start; - paddr_t r_e = r_s + reserved_mem->bank[i - nr].size; - - if ( s < r_e && r_s < e ) - { - r_e = consider_modules(r_e, e, size, align, i + 1); - if ( r_e ) - return r_e; - - return consider_modules(s, r_s, size, align, i + 1); - } - } - -#ifdef CONFIG_STATIC_SHM - nr += reserved_mem->nr_banks; - for ( ; i - nr < shmem->nr_banks; i++ ) - { - paddr_t r_s, r_e; - - r_s = shmem->bank[i - nr].start; - - /* Shared memory banks can contain INVALID_PADDR as start */ - if ( INVALID_PADDR == r_s ) - continue; - - r_e = r_s + shmem->bank[i - nr].size; - - if ( s < r_e && r_s < e ) - { - r_e = consider_modules(r_e, e, size, align, i + 1); - if ( r_e ) - return r_e; - - return consider_modules(s, r_s, size, align, i + 1); - } - } -#endif - - return e; -} - /* * Find a contiguous region that fits in the static heap region with * required size and alignment, and return the end address of the region diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h index 64c227d171..0c560d141f 100644 --- a/xen/arch/arm/include/asm/setup.h +++ b/xen/arch/arm/include/asm/setup.h @@ -89,6 +89,9 @@ struct init_info unsigned int cpuid; }; +paddr_t consider_modules(paddr_t s, paddr_t e, uint32_t size, paddr_t align, + int first_mod); + #endif /* * Local variables: diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c index 9664e85ee6..196974f3e2 100644 --- a/xen/arch/arm/mmu/setup.c +++ b/xen/arch/arm/mmu/setup.c @@ -222,6 +222,100 @@ static void xen_pt_enforce_wnx(void) flush_xen_tlb_local(); } +/* + * Returns the end address of the highest region in the range s..e + * with required size and alignment that does not conflict with the + * modules from first_mod to nr_modules. + * + * For non-recursive callers first_mod should normally be 0 (all + * modules and Xen itself) or 1 (all modules but not Xen). + */ +paddr_t __init consider_modules(paddr_t s, paddr_t e, + uint32_t size, paddr_t align, + int first_mod) +{ + const struct membanks *reserved_mem = bootinfo_get_reserved_mem(); +#ifdef CONFIG_STATIC_SHM + const struct membanks *shmem = bootinfo_get_shmem(); +#endif + const struct bootmodules *mi = &bootinfo.modules; + int i; + int nr; + + s = (s+align-1) & ~(align-1); + e = e & ~(align-1); + + if ( s > e || e - s < size ) + return 0; + + /* First check the boot modules */ + for ( i = first_mod; i < mi->nr_mods; i++ ) + { + paddr_t mod_s = mi->module[i].start; + paddr_t mod_e = mod_s + mi->module[i].size; + + if ( s < mod_e && mod_s < e ) + { + mod_e = consider_modules(mod_e, e, size, align, i+1); + if ( mod_e ) + return mod_e; + + return consider_modules(s, mod_s, size, align, i+1); + } + } + + /* + * i is the current bootmodule we are evaluating, across all + * possible kinds of bootmodules. + * + * When retrieving the corresponding reserved-memory addresses, we + * need to index the reserved_mem bank starting from 0, and only counting + * the reserved-memory modules. Hence, we need to use i - nr. + */ + nr = mi->nr_mods; + for ( ; i - nr < reserved_mem->nr_banks; i++ ) + { + paddr_t r_s = reserved_mem->bank[i - nr].start; + paddr_t r_e = r_s + reserved_mem->bank[i - nr].size; + + if ( s < r_e && r_s < e ) + { + r_e = consider_modules(r_e, e, size, align, i + 1); + if ( r_e ) + return r_e; + + return consider_modules(s, r_s, size, align, i + 1); + } + } + +#ifdef CONFIG_STATIC_SHM + nr += reserved_mem->nr_banks; + for ( ; i - nr < shmem->nr_banks; i++ ) + { + paddr_t r_s, r_e; + + r_s = shmem->bank[i - nr].start; + + /* Shared memory banks can contain INVALID_PADDR as start */ + if ( INVALID_PADDR == r_s ) + continue; + + r_e = r_s + shmem->bank[i - nr].size; + + if ( s < r_e && r_s < e ) + { + r_e = consider_modules(r_e, e, size, align, i + 1); + if ( r_e ) + return r_e; + + return consider_modules(s, r_s, size, align, i + 1); + } + } +#endif + + return e; +} + /* * Boot-time pagetable setup. * Changes here may need matching changes in head.S -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 16:59:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 16:59:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846774.1261998 (Exim 4.92) (envelope-from ) id 1tI9lr-0000tt-80; Mon, 02 Dec 2024 16:59:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846774.1261998; Mon, 02 Dec 2024 16:59: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 1tI9lr-0000sq-3E; Mon, 02 Dec 2024 16:59:39 +0000 Received: by outflank-mailman (input) for mailman id 846774; Mon, 02 Dec 2024 16:59: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 1tI9lp-0006x4-9d for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 16:59:37 +0000 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [2a00:1450:4864:20::62b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ce99f3f6-b0ce-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 17:59:34 +0100 (CET) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-aa543c4db92so666977666b.0 for ; Mon, 02 Dec 2024 08:59:34 -0800 (PST) Received: from carlo-ubuntu.home.arpa (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5998e64c4sm526802666b.97.2024.12.02.08.59.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 08:59: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: ce99f3f6-b0ce-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1733158774; x=1733763574; 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=5jmTpoIsSrEVNjy7/04k9RPLkrs/AHNOCuox3jJ6UZQ=; b=fWM7wCg1jia36eQXta8xhvb4zi+evnv1DufJWIWz4NwaMAG7cf1PGF7sx9AUwKNfWv yVR6KciTVD/Lzw1EXLKL+YRQG3q/Op9cHoypiVs9yngSJx5d5bboxTINFxJMG7XmKc+U ax5TR0337xenK2ZFW94Gu9ZdbK8GWZPMcKJmVw9hLwdcVjRePzvRHkwt4qa1yioe/APt oOsjUT5s521cXWSqHqbwo/fzGy+mhyLRuYcRrrAK1j2Sq8T9BpbH+GqfyYKY2hkzOaG8 RX1C3VWR772Q3yv19/IbWTMk0qG7msL304jRDCvxWKsMZwIuIUyUWEVSi/kBa4rNlqvw Xhbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733158774; x=1733763574; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5jmTpoIsSrEVNjy7/04k9RPLkrs/AHNOCuox3jJ6UZQ=; b=U+yz/C26yOUmZSr/ansxqTL6rIMxSUNRkDnHtLzZtCUH+T6knSYi0wBeyvWe0EOtQh UFf5L3dqCpDWekwVfGVJpy92F6uugclAhg3R1QK3R0cPwhepD/XYeHYLOJlaibI/cumT w+QdC48D8HKSaT/SZ+Zy2a1dihfehLYzw5OD0gf2vxP747DDLZqQ2UGckU2C9x3ksJEz xZOXAtG6vGeKNu+Y+tRZA8PSHEe81/UXh+OyCBU9o5xL+SyV8OFXBtfCzH4P7ECyTKnh Sypww6go9XaT0E4XK6b22AgQ+Gl2pbapVRfhh8mgJXFRbDimK4nPf+Xa/uyWlvobk5Nl jWUA== X-Gm-Message-State: AOJu0Yxr7rLDo7do7YrjeADoX0rn2/GrHdSaUZx4FpLWZCzAWFG9fcWu 6nqTs33A4qJYFE/U6vepvOyfP0Z9BmvNMjHoa99+Y3yVBgnX67OnTZecpbefMw4hqCA7zj/vnhT A X-Gm-Gg: ASbGncsZShLy5i4D3ZLIvh9meC4CE8H4ANg3xVj+DOObD5TEW1YSIf5rzAgZAUdTWfF LmUtxz+1p0o1T6gS4hezTZd0EbDpGYZ0jp387+Wc+IUj9vOFoQftCbPTT3Us8detwHZYLTma22u Ng5yLAjDYYdqhItBWGiqS6J/kAyFrA1ril4fUxk4k+hUKZmT2gD6mMQ75L+Te8Ilp+FrIENe/TA nTr/6KLSdd8eKX6VN3Lof9WctNFG/j/05caLmVPfori53MwgXEYRnAfCb0mIwHmBYRjJLLYqYkf N/ECKZqmyqcC4zKMg6szujwJrq85MeFbGT/dvS3iscy3quoR/AkC X-Google-Smtp-Source: AGHT+IFEuCFDELQO7TRdcBoHJN5Jfc+bCWUrh5rO84iI5OBTaOWeGikUxGR6zgDDV7n9Pdg61F2/Iw== X-Received: by 2002:a17:906:310d:b0:aa5:1551:99f0 with SMTP id a640c23a62f3a-aa580f3336dmr1632815966b.30.1733158773801; Mon, 02 Dec 2024 08:59:33 -0800 (PST) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Carlo Nonato , Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v11 09/12] xen: add cache coloring allocator for domains Date: Mon, 2 Dec 2024 17:59:18 +0100 Message-ID: <20241202165921.249585-10-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241202165921.249585-1-carlo.nonato@minervasys.tech> References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add a new memory page allocator that implements the cache coloring mechanism. The allocation algorithm enforces equal frequency distribution of cache partitions, following the coloring configuration of a domain. This allows for an even utilization of cache sets for every domain. Pages are stored in a color-indexed array of lists. Those lists are filled by a simple init function which computes the color of each page. When a domain requests a page, the allocator extracts the page from the list with the maximum number of free pages among those that the domain can access, given its coloring configuration. The allocator can only handle requests of order-0 pages. This allows for easier implementation and since cache coloring targets only embedded systems, it's assumed not to be a major problem. The buddy allocator must coexist with the colored one because the Xen heap isn't colored. For this reason a new Kconfig option and a command line parameter are added to let the user set the amount of memory reserved for the buddy allocator. Even when cache coloring is enabled, this memory isn't managed by the colored allocator. Colored heap information is dumped in the dump_heap() debug-key function. Based on original work from: Luca Miccio Signed-off-by: Marco Solieri Signed-off-by: Carlo Nonato --- v11: - CONFIG_BUDDY_ALLOCATOR_SIZE depends on CONFIG_LLC_COLORING - buddy_alloc_size is defined only if CONFIG_LLC_COLORING - buddy-alloc-size param is parsed only if CONFIG_LLC_COLORING v10: - stated explicit dependency on CONFIG_LLC_COLORING for buddy-alloc-size - fix for MISRA rule 20.7 parenthesis v9: - added ASSERT(order == 0) when freeing a colored page - moved buddy_alloc_size initialization logic in Kconfig v8: - requests that uses MEMF_* flags that can't be served are now going to fail - free_color_heap_page() is called directly from free_heap_pages() v7: - requests to alloc_color_heap_page() now fail if MEMF_bits is used v6: - colored allocator functions are now static v5: - Carlo Nonato as the new author - the colored allocator balances color usage for each domain and it searches linearly only in the number of colors (FIXME removed) - addedd scrub functionality - removed stub functions (still requires some macro definition) - addr_to_color turned to mfn_to_color for easier operations - removed BUG_ON in init_color_heap_pages() in favor of panic() - only non empty page lists are logged in dump_color_heap() v4: - moved colored allocator code after buddy allocator because it now has some dependencies on buddy functions - buddy_alloc_size is now used only by the colored allocator - fixed a bug that allowed the buddy to merge pages when they were colored - free_color_heap_page() now calls mark_page_free() - free_color_heap_page() uses of the frametable array for faster searches - added FIXME comment for the linear search in free_color_heap_page() - removed alloc_color_domheap_page() to let the colored allocator exploit some more buddy allocator code - alloc_color_heap_page() now allocs min address pages first - reduced the mess in end_boot_allocator(): use the first loop for init_color_heap_pages() - fixed page_list_add_prev() (list.h) since it was doing the opposite of what it was supposed to do - fixed page_list_add_prev() (non list.h) to check also for next existence - removed unused page_list_add_next() - moved p2m code in another patch --- docs/misc/cache-coloring.rst | 37 ++++++ docs/misc/xen-command-line.pandoc | 14 +++ xen/arch/arm/include/asm/mm.h | 5 + xen/common/Kconfig | 8 ++ xen/common/llc-coloring.c | 13 ++ xen/common/page_alloc.c | 191 +++++++++++++++++++++++++++++- xen/include/xen/llc-coloring.h | 3 + 7 files changed, 267 insertions(+), 4 deletions(-) diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst index e097e74032..5224b27afe 100644 --- a/docs/misc/cache-coloring.rst +++ b/docs/misc/cache-coloring.rst @@ -13,6 +13,9 @@ To compile LLC coloring support set ``CONFIG_LLC_COLORING=y``. If needed, change the maximum number of colors with ``CONFIG_LLC_COLORS_ORDER=``. +If needed, change the buddy allocator reserved size with +``CONFIG_BUDDY_ALLOCATOR_SIZE=``. + Runtime configuration is done via `Command line parameters`_. For DomUs follow `DomUs configuration`_. @@ -110,6 +113,8 @@ Specific documentation is available at `docs/misc/xen-command-line.pandoc`. +----------------------+-------------------------------+ | ``dom0-llc-colors`` | Dom0 color configuration | +----------------------+-------------------------------+ +| ``buddy-alloc-size`` | Buddy allocator reserved size | ++----------------------+-------------------------------+ Colors selection format *********************** @@ -197,6 +202,17 @@ For example: **Note:** If no color configuration is provided for a domain, the default one, which corresponds to all available colors is used instead. +Colored allocator and buddy allocator +************************************* + +The colored allocator distributes pages based on color configurations of +domains so that each domains only gets pages of its own colors. +The colored allocator is meant as an alternative to the buddy allocator because +its allocation policy is by definition incompatible with the generic one. Since +the Xen heap is not colored yet, we need to support the coexistence of the two +allocators and some memory must be left for the buddy one. Buddy memory +reservation is configured via Kconfig or via command-line. + Known issues and limitations **************************** @@ -207,3 +223,24 @@ In the domain configuration, "xen,static-mem" allows memory to be statically allocated to the domain. This isn't possible when LLC coloring is enabled, because that memory can't be guaranteed to use only colors assigned to the domain. + +Cache coloring is intended only for embedded systems +#################################################### + +The current implementation aims to satisfy the need of predictability in +embedded systems with small amount of memory to be managed in a colored way. +Given that, some shortcuts are taken in the development. Expect worse +performances on larger systems. + +Colored allocator can only make use of order-0 pages +#################################################### + +The cache coloring technique relies on memory mappings and on the smallest +mapping granularity to achieve the maximum number of colors (cache partitions) +possible. This granularity is what is normally called a page and, in Xen +terminology, the order-0 page is the smallest one. The fairly simple +colored allocator currently implemented, makes use only of such pages. +It must be said that a more complex one could, in theory, adopt higher order +pages if the colors selection contained adjacent colors. Two subsequent colors, +for example, can be represented by an order-1 page, four colors correspond to +an order-2 page, etc. diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index bfdc8b0002..3a70c49c05 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -270,6 +270,20 @@ and not running softirqs. Reduce this if softirqs are not being run frequently enough. Setting this to a high value may cause boot failure, particularly if the NMI watchdog is also enabled. +### buddy-alloc-size (arm64) +> `= ` + +> Default: `64M` + +Amount of memory reserved for the buddy allocator when colored allocator is +active. This option is available only when `CONFIG_LLC_COLORING` is enabled. +The colored allocator is meant as an alternative to the buddy allocator, +because its allocation policy is by definition incompatible with the generic +one. Since the Xen heap systems is not colored yet, we need to support the +coexistence of the two allocators for now. This parameter, which is optional +and for expert only, it's used to set the amount of memory reserved to the +buddy allocator. + ### cet = List of [ shstk=, ibt= ] diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h index 5abd4b0d1c..c1a5ac7bee 100644 --- a/xen/arch/arm/include/asm/mm.h +++ b/xen/arch/arm/include/asm/mm.h @@ -145,6 +145,11 @@ struct page_info #else #define PGC_static 0 #endif +#ifdef CONFIG_LLC_COLORING +/* Page is cache colored */ +#define _PGC_colored PG_shift(4) +#define PGC_colored PG_mask(1, 4) +#endif /* ... */ /* Page is broken? */ #define _PGC_broken PG_shift(7) diff --git a/xen/common/Kconfig b/xen/common/Kconfig index b4ec6893be..6166327f4d 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -537,4 +537,12 @@ config LLC_COLORS_ORDER The default value corresponds to an 8 MiB 16-ways LLC, which should be more than what's needed in the general case. +config BUDDY_ALLOCATOR_SIZE + int "Buddy allocator reserved memory size (MiB)" + default "64" + depends on LLC_COLORING + help + Amount of memory reserved for the buddy allocator to serve Xen heap, + working alongside the colored one. + endmenu diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c index 2a85345cf1..0f22a9b72c 100644 --- a/xen/common/llc-coloring.c +++ b/xen/common/llc-coloring.c @@ -32,6 +32,9 @@ static unsigned int __ro_after_init default_colors[NR_LLC_COLORS]; static unsigned int __initdata dom0_colors[NR_LLC_COLORS]; static unsigned int __initdata dom0_num_colors; +#define mfn_color_mask (max_nr_colors - 1) +#define mfn_to_color(mfn) (mfn_x(mfn) & mfn_color_mask) + /* * Parse the coloring configuration given in the buf string, following the * syntax below. @@ -317,6 +320,16 @@ int __init domain_set_llc_colors_from_str(struct domain *d, const char *str) return 0; } +unsigned int page_to_llc_color(const struct page_info *pg) +{ + return mfn_to_color(page_to_mfn(pg)); +} + +unsigned int get_max_nr_llc_colors(void) +{ + return max_nr_colors; +} + /* * Local variables: * mode: C diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index e73b404169..a1133cfd89 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -139,6 +139,7 @@ #include #include #include +#include #include #include @@ -160,8 +161,12 @@ #define PGC_static 0 #endif -#define PGC_no_buddy_merge PGC_static -#define PGC_preserved (PGC_extra | PGC_static) +#ifndef PGC_colored +#define PGC_colored 0 +#endif + +#define PGC_no_buddy_merge (PGC_static | PGC_colored) +#define PGC_preserved (PGC_extra | PGC_static | PGC_colored) #ifndef PGT_TYPE_INFO_INITIALIZER #define PGT_TYPE_INFO_INITIALIZER 0 @@ -1473,6 +1478,8 @@ static bool mark_page_free(struct page_info *pg, mfn_t mfn) return pg_offlined; } +static void free_color_heap_page(struct page_info *pg, bool need_scrub); + /* Free 2^@order set of pages. */ static void free_heap_pages( struct page_info *pg, unsigned int order, bool need_scrub) @@ -1497,6 +1504,15 @@ static void free_heap_pages( pg[i].count_info |= PGC_need_scrub; poison_one_page(&pg[i]); } + + if ( pg->count_info & PGC_colored ) + { + ASSERT(order == 0); + + free_color_heap_page(pg, need_scrub); + spin_unlock(&heap_lock); + return; + } } avail[node][zone] += 1 << order; @@ -1961,6 +1977,157 @@ static unsigned long avail_heap_pages( return free_pages; } +/************************* + * COLORED SIDE-ALLOCATOR + * + * Pages are grouped by LLC color in lists which are globally referred to as the + * color heap. Lists are populated in end_boot_allocator(). + * After initialization there will be N lists where N is the number of + * available colors on the platform. + */ +static struct page_list_head *__ro_after_init _color_heap; +#define color_heap(color) (&_color_heap[color]) + +static unsigned long *__ro_after_init free_colored_pages; + +#ifdef CONFIG_LLC_COLORING +#define domain_num_llc_colors(d) ((d)->num_llc_colors) +#define domain_llc_color(d, i) ((d)->llc_colors[i]) + +/* Memory required for buddy allocator to work with colored one */ +static unsigned long __initdata buddy_alloc_size = + MB(CONFIG_BUDDY_ALLOCATOR_SIZE); +size_param("buddy-alloc-size", buddy_alloc_size); +#else +#define domain_num_llc_colors(d) 0 +#define domain_llc_color(d, i) 0 +#endif + +static void free_color_heap_page(struct page_info *pg, bool need_scrub) +{ + unsigned int color; + + color = page_to_llc_color(pg); + free_colored_pages[color]++; + /* + * Head insertion allows re-using cache-hot pages in configurations without + * sharing of colors. + */ + page_list_add(pg, color_heap(color)); +} + +static struct page_info *alloc_color_heap_page(unsigned int memflags, + const struct domain *d) +{ + struct page_info *pg = NULL; + unsigned int i, color = 0; + unsigned long max = 0; + bool need_tlbflush = false; + uint32_t tlbflush_timestamp = 0; + bool need_scrub; + + if ( memflags & ~(MEMF_no_refcount | MEMF_no_owner | MEMF_no_tlbflush | + MEMF_no_icache_flush | MEMF_no_scrub) ) + return NULL; + + spin_lock(&heap_lock); + + for ( i = 0; i < domain_num_llc_colors(d); i++ ) + { + unsigned long free = free_colored_pages[domain_llc_color(d, i)]; + + if ( free > max ) + { + color = domain_llc_color(d, i); + pg = page_list_first(color_heap(color)); + max = free; + } + } + + if ( !pg ) + { + spin_unlock(&heap_lock); + return NULL; + } + + need_scrub = pg->count_info & PGC_need_scrub; + pg->count_info = PGC_state_inuse | (pg->count_info & PGC_colored); + free_colored_pages[color]--; + page_list_del(pg, color_heap(color)); + + if ( !(memflags & MEMF_no_tlbflush) ) + accumulate_tlbflush(&need_tlbflush, pg, &tlbflush_timestamp); + + init_free_page_fields(pg); + + spin_unlock(&heap_lock); + + if ( !(memflags & MEMF_no_scrub) ) + { + if ( need_scrub ) + scrub_one_page(pg); + else + check_one_page(pg); + } + + if ( need_tlbflush ) + filtered_flush_tlb_mask(tlbflush_timestamp); + + flush_page_to_ram(mfn_x(page_to_mfn(pg)), + !(memflags & MEMF_no_icache_flush)); + + return pg; +} + +static void __init init_color_heap_pages(struct page_info *pg, + unsigned long nr_pages) +{ + unsigned long i; + bool need_scrub = opt_bootscrub == BOOTSCRUB_IDLE; + +#ifdef buddy_alloc_size + if ( buddy_alloc_size >= PAGE_SIZE ) + { + unsigned long buddy_pages = min(PFN_DOWN(buddy_alloc_size), nr_pages); + + init_heap_pages(pg, buddy_pages); + nr_pages -= buddy_pages; + buddy_alloc_size -= buddy_pages << PAGE_SHIFT; + pg += buddy_pages; + } +#endif + + if ( !_color_heap ) + { + unsigned int max_nr_colors = get_max_nr_llc_colors(); + + _color_heap = xvmalloc_array(struct page_list_head, max_nr_colors); + free_colored_pages = xvzalloc_array(unsigned long, max_nr_colors); + if ( !_color_heap || !free_colored_pages ) + panic("Can't allocate colored heap. Buddy reserved size is too low"); + + for ( i = 0; i < max_nr_colors; i++ ) + INIT_PAGE_LIST_HEAD(color_heap(i)); + } + + for ( i = 0; i < nr_pages; i++ ) + { + pg[i].count_info = PGC_colored; + free_color_heap_page(&pg[i], need_scrub); + } +} + +static void dump_color_heap(void) +{ + unsigned int color; + + printk("Dumping color heap info\n"); + for ( color = 0; color < get_max_nr_llc_colors(); color++ ) + if ( free_colored_pages[color] > 0 ) + printk("Color heap[%u]: %lu pages\n", + color, free_colored_pages[color]); +} + void __init end_boot_allocator(void) { unsigned int i; @@ -1980,7 +2147,13 @@ void __init end_boot_allocator(void) for ( i = nr_bootmem_regions; i-- > 0; ) { struct bootmem_region *r = &bootmem_region_list[i]; - if ( r->s < r->e ) + + if ( r->s >= r->e ) + continue; + + if ( llc_coloring_enabled ) + init_color_heap_pages(mfn_to_page(_mfn(r->s)), r->e - r->s); + else init_heap_pages(mfn_to_page(_mfn(r->s)), r->e - r->s); } nr_bootmem_regions = 0; @@ -2476,7 +2649,14 @@ struct page_info *alloc_domheap_pages( if ( memflags & MEMF_no_owner ) memflags |= MEMF_no_refcount; - if ( !dma_bitsize ) + /* Only domains are supported for coloring */ + if ( d && llc_coloring_enabled ) + { + /* Colored allocation must be done on 0 order */ + if ( order || (pg = alloc_color_heap_page(memflags, d)) == NULL ) + return NULL; + } + else if ( !dma_bitsize ) memflags &= ~MEMF_no_dma; else if ( (dma_zone = bits_to_zone(dma_bitsize)) < zone_hi ) pg = alloc_heap_pages(dma_zone + 1, zone_hi, order, memflags, d); @@ -2688,6 +2868,9 @@ static void cf_check dump_heap(unsigned char key) continue; printk("Node %d has %lu unscrubbed pages\n", i, node_need_scrub[i]); } + + if ( llc_coloring_enabled ) + dump_color_heap(); } static __init int cf_check register_heap_trigger(void) diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h index ae8a8825e5..b3f2fa22bc 100644 --- a/xen/include/xen/llc-coloring.h +++ b/xen/include/xen/llc-coloring.h @@ -9,6 +9,7 @@ #define __XEN_LLC_COLORING_H__ struct domain; +struct page_info; struct xen_domctl_set_llc_colors; #ifdef CONFIG_LLC_COLORING @@ -33,6 +34,8 @@ int dom0_set_llc_colors(struct domain *d); int domain_set_llc_colors(struct domain *d, const struct xen_domctl_set_llc_colors *config); int domain_set_llc_colors_from_str(struct domain *d, const char *str); +unsigned int page_to_llc_color(const struct page_info *pg); +unsigned int get_max_nr_llc_colors(void); #endif /* __XEN_LLC_COLORING_H__ */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 16:59:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 16:59:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846777.1262021 (Exim 4.92) (envelope-from ) id 1tI9lu-0001jU-Ko; Mon, 02 Dec 2024 16:59:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846777.1262021; Mon, 02 Dec 2024 16:59: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 1tI9lu-0001ga-6w; Mon, 02 Dec 2024 16:59:42 +0000 Received: by outflank-mailman (input) for mailman id 846777; Mon, 02 Dec 2024 16:59: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 1tI9lr-0006x4-LI for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 16:59:39 +0000 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [2a00:1450:4864:20::52b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d01b1c2d-b0ce-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 17:59:37 +0100 (CET) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5d0bdeb0374so3449397a12.0 for ; Mon, 02 Dec 2024 08:59:37 -0800 (PST) Received: from carlo-ubuntu.home.arpa (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5998e64c4sm526802666b.97.2024.12.02.08.59.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 08:59: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: d01b1c2d-b0ce-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1733158777; x=1733763577; 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=jLbjZwSsMBhbP6FhXxodaS+Dw8jqZO+nNvFUCEAf4WQ=; b=dYdDMogB8QoTbJvjXB4TwSfiyVhhgwaFXN4b/HQNg8MbgGd1QSMIwQDQ9sMj0xpjcU wsfcKviWWFh7ygV/44c/zAe9ZpVeYRIZAgahgUw/TbxSY7d8NTHNddWJtKrdn7toeWMy msEjOmqrABeWxqs0FHXl7yIxfr6poZCEjcjdK7dlrMCXz79SFZYQwiLw/w3RdjpWqVLI bcQyhXwuRT7OeP0/qT76yKObSzD2zeU69vCeDENhbmwJYv1GrODRWy79wzJANBkJ4uMg oDH4u2OiyyLyd1Wyi/hcUyMLLEYwXJyfPNJwrla6WudED2zXBabpt/Qxzi0BKY+QyMru iLEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733158777; x=1733763577; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jLbjZwSsMBhbP6FhXxodaS+Dw8jqZO+nNvFUCEAf4WQ=; b=JwHRqC0owu2ifzfOg8GNxu8hItzXqx44z8Qh38CccWdHA/l0hHuh8bm/KuqccEA9Qq Th3nRDERiTloLiQB5cIBH1J8HsIb5zQwVAg1w1jxLGgfjFIJNPKoZoUB13ewdhzHYD3V 8Jc+hg9ubBgZrNwSnV1uWKxRCbRuPK9t4LG8G1ctgScs3/mymQfDpSXRVdby3hEXU85+ RqbqHBdvt8RCHsyx5wVum8kbzXM446EqZQ97egg9VKIUb0Qm+fmW/dS5sGiLoapMyrrF zCOGinQ5uyII6rKsNnKRXdex8hhP8mDKbQhNRCfTl3oTbeKxfUYrCVYaJuf+AWT3xh+w lsoQ== X-Gm-Message-State: AOJu0YzKzxaUjBoi17jifgiEHUpcWYPedaPpukSh0iIclggQzhL+2Wdv GKYWMn0kaaYE8oVAz7wCytQn2Z/8QjRpnB3q1ZE590Rc5aZCpmBnm6pUeXbYb/yXVerLlLR6H5T z X-Gm-Gg: ASbGncvt3l3zTOZSiNwFIZQrqorl6RpjxZbPmqq+NDVCkWkfIG96ZY2M4dN7rIU3cwx YydZnZA8xnevri7qQ3sFcc73+vCns9UGa06DnqCf670faBnafuYi7/zkP7p4e7J7Dr691FNNq3/ P07U4NJq6/6GpkySqncTSNm2/PbzHZskB1AtMMu6GThn9OgIvoaGpftdUWbthwzjf7A93h46IZf 7HRRR8l7Rpsc/XIk4J7Nh/u/Jl03GrK7nD/EHIEseLHISZhNsVxKGSLwxSGHo7G6ZeLNP9/egv3 ajF7Ms463yTCpS5s2cm6VgPfFSC9aw9yijFIej0eSLRCgsh1Mex7 X-Google-Smtp-Source: AGHT+IEsMeY8tJTcRZ/irSPCXsIki96bRQtsE2O99r8NeN/Y5vw5MLh2IGvkhfJsUG7F8Abaqi/UUA== X-Received: by 2002:a17:906:3d2a:b0:aa5:3423:2dfe with SMTP id a640c23a62f3a-aa580f33384mr1969822066b.25.1733158776539; Mon, 02 Dec 2024 08:59:36 -0800 (PST) From: Carlo Nonato To: xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Carlo Nonato , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Jan Beulich Subject: [PATCH v11 12/12] xen/arm: add cache coloring support for Xen image Date: Mon, 2 Dec 2024 17:59:21 +0100 Message-ID: <20241202165921.249585-13-carlo.nonato@minervasys.tech> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241202165921.249585-1-carlo.nonato@minervasys.tech> References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Xen image is relocated to a new colored physical space. Some relocation functionalities must be brought back: - the virtual address of the new space is taken from 0c18fb76323b ("xen/arm: Remove unused BOOT_RELOC_VIRT_START"). - relocate_xen() and get_xen_paddr() are taken from f60658c6ae47 ("xen/arm: Stop relocating Xen"). setup_pagetables() must be adapted for coloring and for relocation. Runtime page tables are used to map the colored space, but they are also linked in boot tables so that the new space is temporarily available for relocation. This implies that Xen protection must happen after the copy. Finally, since the alternative framework needs to remap the Xen text and inittext sections, this operation must be done in a coloring-aware way. The function xen_remap_colored() is introduced for that. Signed-off-by: Carlo Nonato Signed-off-by: Marco Solieri Reviewed-by: Jan Beulich # common --- v11: - else if -> if in xen_colored_mfn() v10: - no changes v9: - patch adapted to changes to setup_pagetables() v8: - moved xen_colored_map_size() to arm/llc-coloring.c v7: - added BUG_ON() checks to arch_llc_coloring_init() and create_llc_coloring_mappings() v6: - squashed with BOOT_RELOC_VIRT_START patch - consider_modules() moved in another patch - removed psci and smpboot code because of new idmap work already handles that - moved xen_remap_colored() in alternative.c since it's only used there - removed xen_colored_temp[] in favor of xen_xenmap[] usage for mapping - use of boot_module_find_by_kind() to remove the need of extra parameter in setup_pagetables() - moved get_xen_paddr() in arm/llc-coloring.c since it's only used there v5: - FIXME: consider_modules copy pasted since it got moved v4: - removed set_value_for_secondary() because it was wrongly cleaning cache - relocate_xen() now calls switch_ttbr_id() --- xen/arch/arm/alternative.c | 30 +++++++- xen/arch/arm/arm64/mmu/head.S | 58 +++++++++++++++- xen/arch/arm/arm64/mmu/mm.c | 28 ++++++-- xen/arch/arm/include/asm/mmu/layout.h | 3 + xen/arch/arm/llc-coloring.c | 63 +++++++++++++++++ xen/arch/arm/mmu/setup.c | 99 +++++++++++++++++++++++---- xen/arch/arm/setup.c | 10 ++- xen/common/llc-coloring.c | 18 +++++ xen/include/xen/llc-coloring.h | 14 ++++ 9 files changed, 302 insertions(+), 21 deletions(-) diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c index d99b507093..0fcf4e451d 100644 --- a/xen/arch/arm/alternative.c +++ b/xen/arch/arm/alternative.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include #include @@ -191,6 +192,27 @@ static int __apply_alternatives_multi_stop(void *xenmap) return 0; } +static void __init *xen_remap_colored(mfn_t xen_mfn, paddr_t xen_size) +{ + unsigned int i; + void *xenmap; + mfn_t *xen_colored_mfns, mfn; + + xen_colored_mfns = xmalloc_array(mfn_t, xen_size >> PAGE_SHIFT); + if ( !xen_colored_mfns ) + panic("Can't allocate LLC colored MFNs\n"); + + for_each_xen_colored_mfn ( xen_mfn, mfn, i ) + { + xen_colored_mfns[i] = mfn; + } + + xenmap = vmap(xen_colored_mfns, xen_size >> PAGE_SHIFT); + xfree(xen_colored_mfns); + + return xenmap; +} + /* * This function should only be called during boot and before CPU0 jump * into the idle_loop. @@ -209,8 +231,12 @@ void __init apply_alternatives_all(void) * The text and inittext section are read-only. So re-map Xen to * be able to patch the code. */ - xenmap = __vmap(&xen_mfn, 1U << xen_order, 1, 1, PAGE_HYPERVISOR, - VMAP_DEFAULT); + if ( llc_coloring_enabled ) + xenmap = xen_remap_colored(xen_mfn, xen_size); + else + xenmap = __vmap(&xen_mfn, 1U << xen_order, 1, 1, PAGE_HYPERVISOR, + VMAP_DEFAULT); + /* Re-mapping Xen is not expected to fail during boot. */ BUG_ON(!xenmap); diff --git a/xen/arch/arm/arm64/mmu/head.S b/xen/arch/arm/arm64/mmu/head.S index 665a51a337..a1fc9a82f1 100644 --- a/xen/arch/arm/arm64/mmu/head.S +++ b/xen/arch/arm/arm64/mmu/head.S @@ -428,6 +428,61 @@ FUNC_LOCAL(fail) b 1b END(fail) +/* + * Copy Xen to new location and switch TTBR + * x0 ttbr + * x1 source address + * x2 destination address + * x3 length + * + * Source and destination must be word aligned, length is rounded up + * to a 16 byte boundary. + * + * MUST BE VERY CAREFUL when saving things to RAM over the copy + */ +ENTRY(relocate_xen) + /* + * Copy 16 bytes at a time using: + * x9: counter + * x10: data + * x11: data + * x12: source + * x13: destination + */ + mov x9, x3 + mov x12, x1 + mov x13, x2 + +1: ldp x10, x11, [x12], #16 + stp x10, x11, [x13], #16 + + subs x9, x9, #16 + bgt 1b + + /* + * Flush destination from dcache using: + * x9: counter + * x10: step + * x11: vaddr + * + * This is to ensure data is visible to the instruction cache + */ + dsb sy + + mov x9, x3 + ldr x10, =dcache_line_bytes /* x10 := step */ + ldr x10, [x10] + mov x11, x2 + +1: dc cvac, x11 + + add x11, x11, x10 + subs x9, x9, x10 + bgt 1b + + /* No need for dsb/isb because they are alredy done in switch_ttbr_id */ + b switch_ttbr_id + /* * Switch TTBR * @@ -453,7 +508,8 @@ FUNC(switch_ttbr_id) /* * 5) Flush I-cache - * This should not be necessary but it is kept for safety. + * This should not be necessary in the general case, but it's needed + * for cache coloring because code is relocated in that case. */ ic iallu isb diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c index 671eaadbc1..3732d5897e 100644 --- a/xen/arch/arm/arm64/mmu/mm.c +++ b/xen/arch/arm/arm64/mmu/mm.c @@ -1,6 +1,7 @@ /* SPDX-License-Identifier: GPL-2.0-only */ #include +#include #include #include @@ -138,27 +139,46 @@ void update_boot_mapping(bool enable) } extern void switch_ttbr_id(uint64_t ttbr); +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len); typedef void (switch_ttbr_fn)(uint64_t ttbr); +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t len); void __init switch_ttbr(uint64_t ttbr) { - vaddr_t id_addr = virt_to_maddr(switch_ttbr_id); - switch_ttbr_fn *fn = (switch_ttbr_fn *)id_addr; + vaddr_t vaddr, id_addr; lpae_t pte; + if ( llc_coloring_enabled ) + vaddr = (vaddr_t)relocate_xen; + else + vaddr = (vaddr_t)switch_ttbr_id; + + id_addr = virt_to_maddr(vaddr); + /* Enable the identity mapping in the boot page tables */ update_identity_mapping(true); /* Enable the identity mapping in the runtime page tables */ - pte = pte_of_xenaddr((vaddr_t)switch_ttbr_id); + pte = pte_of_xenaddr(vaddr); pte.pt.table = 1; pte.pt.xn = 0; pte.pt.ro = 1; write_pte(&xen_third_id[third_table_offset(id_addr)], pte); /* Switch TTBR */ - fn(ttbr); + if ( llc_coloring_enabled ) + { + relocate_xen_fn *fn = (relocate_xen_fn *)id_addr; + + fn(ttbr, _start, (void *)BOOT_RELOC_VIRT_START, _end - _start); + } + else + { + switch_ttbr_fn *fn = (switch_ttbr_fn *)id_addr; + + fn(ttbr); + } /* * Disable the identity mapping in the runtime page tables. diff --git a/xen/arch/arm/include/asm/mmu/layout.h b/xen/arch/arm/include/asm/mmu/layout.h index a3b546465b..19c0ec63a5 100644 --- a/xen/arch/arm/include/asm/mmu/layout.h +++ b/xen/arch/arm/include/asm/mmu/layout.h @@ -30,6 +30,7 @@ * 10M - 12M Fixmap: special-purpose 4K mapping slots * 12M - 16M Early boot mapping of FDT * 16M - 18M Livepatch vmap (if compiled in) + * 16M - 24M Cache-colored Xen text, data, bss (temporary, if compiled in) * * 1G - 2G VMAP: ioremap and early_ioremap * @@ -74,6 +75,8 @@ #define BOOT_FDT_VIRT_START (FIXMAP_VIRT_START + FIXMAP_VIRT_SIZE) #define BOOT_FDT_VIRT_SIZE _AT(vaddr_t, MB(4)) +#define BOOT_RELOC_VIRT_START (BOOT_FDT_VIRT_START + BOOT_FDT_VIRT_SIZE) + #ifdef CONFIG_LIVEPATCH #define LIVEPATCH_VMAP_START (BOOT_FDT_VIRT_START + BOOT_FDT_VIRT_SIZE) #define LIVEPATCH_VMAP_SIZE _AT(vaddr_t, MB(2)) diff --git a/xen/arch/arm/llc-coloring.c b/xen/arch/arm/llc-coloring.c index 6c8fa6b576..8e10a505db 100644 --- a/xen/arch/arm/llc-coloring.c +++ b/xen/arch/arm/llc-coloring.c @@ -10,6 +10,7 @@ #include #include +#include #include /* Return the LLC way size by probing the hardware */ @@ -64,8 +65,70 @@ unsigned int __init get_llc_way_size(void) return line_size * num_sets; } +/** + * get_xen_paddr - get physical address to relocate Xen to + * + * Xen is relocated to as near to the top of RAM as possible and + * aligned to a XEN_PADDR_ALIGN boundary. + */ +static paddr_t __init get_xen_paddr(paddr_t xen_size) +{ + const struct membanks *mem = bootinfo_get_mem(); + paddr_t min_size, paddr = 0; + unsigned int i; + + min_size = (xen_size + (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1); + + /* Find the highest bank with enough space. */ + for ( i = 0; i < mem->nr_banks; i++ ) + { + const struct membank *bank = &mem->bank[i]; + paddr_t s, e; + + if ( bank->size >= min_size ) + { + e = consider_modules(bank->start, bank->start + bank->size, + min_size, XEN_PADDR_ALIGN, 0); + if ( !e ) + continue; + +#ifdef CONFIG_ARM_32 + /* Xen must be under 4GB */ + if ( e > GB(4) ) + e = GB(4); + if ( e < bank->start ) + continue; +#endif + + s = e - min_size; + + if ( s > paddr ) + paddr = s; + } + } + + if ( !paddr ) + panic("Not enough memory to relocate Xen\n"); + + printk("Placing Xen at 0x%"PRIpaddr"-0x%"PRIpaddr"\n", + paddr, paddr + min_size); + + return paddr; +} + +static paddr_t __init xen_colored_map_size(void) +{ + return ROUNDUP((_end - _start) * get_max_nr_llc_colors(), XEN_PADDR_ALIGN); +} + void __init arch_llc_coloring_init(void) { + struct bootmodule *xen_bootmodule = boot_module_find_by_kind(BOOTMOD_XEN); + + BUG_ON(!xen_bootmodule); + + xen_bootmodule->size = xen_colored_map_size(); + xen_bootmodule->start = get_xen_paddr(xen_bootmodule->size); } /* diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c index 196974f3e2..1d8d7eb70c 100644 --- a/xen/arch/arm/mmu/setup.c +++ b/xen/arch/arm/mmu/setup.c @@ -7,6 +7,7 @@ #include #include +#include #include #include #include @@ -20,6 +21,9 @@ #undef virt_to_mfn #define virt_to_mfn(va) _mfn(__virt_to_mfn(va)) +#define virt_to_reloc_virt(virt) \ + (((vaddr_t)virt) - XEN_VIRT_START + BOOT_RELOC_VIRT_START) + /* Main runtime page tables */ /* @@ -69,6 +73,7 @@ static void __init __maybe_unused build_assertions(void) /* 2MB aligned regions */ BUILD_BUG_ON(XEN_VIRT_START & ~SECOND_MASK); BUILD_BUG_ON(FIXMAP_ADDR(0) & ~SECOND_MASK); + BUILD_BUG_ON(BOOT_RELOC_VIRT_START & ~SECOND_MASK); /* 1GB aligned regions */ #ifdef CONFIG_ARM_32 BUILD_BUG_ON(XENHEAP_VIRT_START & ~FIRST_MASK); @@ -138,6 +143,9 @@ static void __init __maybe_unused build_assertions(void) lpae_t __init pte_of_xenaddr(vaddr_t va) { + if ( llc_coloring_enabled ) + va = virt_to_reloc_virt(va); + return mfn_to_xen_entry(virt_to_mfn(va), MT_NORMAL); } @@ -316,9 +324,44 @@ paddr_t __init consider_modules(paddr_t s, paddr_t e, return e; } +static void __init create_llc_coloring_mappings(void) +{ + lpae_t pte; + unsigned int i; + struct bootmodule *xen_bootmodule = boot_module_find_by_kind(BOOTMOD_XEN); + mfn_t start_mfn = maddr_to_mfn(xen_bootmodule->start), mfn; + + for_each_xen_colored_mfn ( start_mfn, mfn, i ) + { + pte = mfn_to_xen_entry(mfn, MT_NORMAL); + pte.pt.table = 1; /* level 3 mappings always have this bit set */ + xen_xenmap[i] = pte; + } + + for ( i = 0; i < XEN_NR_ENTRIES(2); i++ ) + { + vaddr_t va = BOOT_RELOC_VIRT_START + (i << XEN_PT_LEVEL_SHIFT(2)); + + pte = mfn_to_xen_entry(virt_to_mfn(xen_xenmap + + i * XEN_PT_LPAE_ENTRIES), + MT_NORMAL); + pte.pt.table = 1; + write_pte(&boot_second[second_table_offset(va)], pte); + } +} + /* - * Boot-time pagetable setup. + * Boot-time pagetable setup with coloring support * Changes here may need matching changes in head.S + * + * The cache coloring support consists of: + * - Create colored mapping that conforms to Xen color selection in xen_xenmap[] + * - Link the mapping in boot page tables using BOOT_RELOC_VIRT_START as vaddr + * - pte_of_xenaddr() takes care of translating addresses to the new space + * during runtime page tables creation + * - Relocate xen and update TTBR with the new address in the colored space + * (see switch_ttbr()) + * - Protect the new space */ void __init setup_pagetables(void) { @@ -326,6 +369,9 @@ void __init setup_pagetables(void) lpae_t pte, *p; int i; + if ( llc_coloring_enabled ) + create_llc_coloring_mappings(); + arch_setup_page_tables(); #ifdef CONFIG_ARM_64 @@ -353,13 +399,7 @@ void __init setup_pagetables(void) break; pte = pte_of_xenaddr(va); pte.pt.table = 1; /* third level mappings always have this bit set */ - if ( is_kernel_text(va) || is_kernel_inittext(va) ) - { - pte.pt.xn = 0; - pte.pt.ro = 1; - } - if ( is_kernel_rodata(va) ) - pte.pt.ro = 1; + pte.pt.xn = 0; /* Permissions will be enforced later. Allow execution */ xen_xenmap[i] = pte; } @@ -385,13 +425,48 @@ void __init setup_pagetables(void) ttbr = virt_to_maddr(cpu0_pgtable); #endif - switch_ttbr(ttbr); - - xen_pt_enforce_wnx(); - #ifdef CONFIG_ARM_32 per_cpu(xen_pgtable, 0) = cpu0_pgtable; #endif + + if ( llc_coloring_enabled ) + ttbr = virt_to_maddr(virt_to_reloc_virt(THIS_CPU_PGTABLE)); + + switch_ttbr(ttbr); + + /* Protect Xen */ + for ( i = 0; i < XEN_NR_ENTRIES(3); i++ ) + { + vaddr_t va = XEN_VIRT_START + (i << PAGE_SHIFT); + lpae_t *entry = xen_xenmap + i; + + if ( !is_kernel(va) ) + break; + + pte = read_atomic(entry); + + if ( is_kernel_text(va) || is_kernel_inittext(va) ) + { + pte.pt.xn = 0; + pte.pt.ro = 1; + } else if ( is_kernel_rodata(va) ) { + pte.pt.ro = 1; + pte.pt.xn = 1; + } else { + pte.pt.xn = 1; + pte.pt.ro = 0; + } + + write_pte(entry, pte); + } + + /* + * We modified live page-tables. Ensure the TLBs are invalidated + * before setting enforcing the WnX permissions. + */ + flush_xen_tlb_local(); + + xen_pt_enforce_wnx(); } void *__init arch_vmap_virt_end(void) diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 568a49b274..5e2c519ce8 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -304,8 +304,6 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr) /* Initialize traps early allow us to get backtrace when an error occurred */ init_traps(); - setup_pagetables(); - smp_clear_cpu_maps(); device_tree_flattened = early_fdt_map(fdt_paddr); @@ -329,6 +327,14 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr) llc_coloring_init(); + /* + * Page tables must be setup after LLC coloring initialization because + * coloring info are required in order to create colored mappings + */ + setup_pagetables(); + /* Device-tree was mapped in boot page tables, remap it in the new tables */ + device_tree_flattened = early_fdt_map(fdt_paddr); + setup_mm(); vm_init(); diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c index 2e7c0f505d..2d6aed5fb4 100644 --- a/xen/common/llc-coloring.c +++ b/xen/common/llc-coloring.c @@ -38,6 +38,8 @@ static unsigned int __ro_after_init xen_num_colors; #define mfn_color_mask (max_nr_colors - 1) #define mfn_to_color(mfn) (mfn_x(mfn) & mfn_color_mask) +#define get_mfn_with_color(mfn, color) \ + (_mfn((mfn_x(mfn) & ~mfn_color_mask) | (color))) /* * Parse the coloring configuration given in the buf string, following the @@ -359,6 +361,22 @@ unsigned int get_max_nr_llc_colors(void) return max_nr_colors; } +mfn_t __init xen_colored_mfn(mfn_t mfn) +{ + unsigned int i, color = mfn_to_color(mfn); + + for ( i = 0; i < xen_num_colors; i++ ) + { + if ( color == xen_colors[i] ) + return mfn; + if ( color < xen_colors[i] ) + return get_mfn_with_color(mfn, xen_colors[i]); + } + + /* Jump to next color space (max_nr_colors mfns) and use the first color */ + return get_mfn_with_color(mfn_add(mfn, max_nr_colors), xen_colors[0]); +} + /* * Local variables: * mode: C diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h index b3f2fa22bc..4f10a5310f 100644 --- a/xen/include/xen/llc-coloring.h +++ b/xen/include/xen/llc-coloring.h @@ -8,6 +8,8 @@ #ifndef __XEN_LLC_COLORING_H__ #define __XEN_LLC_COLORING_H__ +#include + struct domain; struct page_info; struct xen_domctl_set_llc_colors; @@ -28,6 +30,17 @@ static inline void domain_dump_llc_colors(const struct domain *d) {} static inline void domain_llc_coloring_free(struct domain *d) {} #endif +/** + * Iterate over each Xen mfn in the colored space. + * @start_mfn: the first mfn that needs to be colored. + * @mfn: the current mfn. + * @i: loop index. + */ +#define for_each_xen_colored_mfn(start_mfn, mfn, i) \ + for ( i = 0, mfn = xen_colored_mfn(start_mfn); \ + i < (_end - _start) >> PAGE_SHIFT; \ + i++, mfn = xen_colored_mfn(mfn_add(mfn, 1)) ) + unsigned int get_llc_way_size(void); void arch_llc_coloring_init(void); int dom0_set_llc_colors(struct domain *d); @@ -36,6 +49,7 @@ int domain_set_llc_colors(struct domain *d, int domain_set_llc_colors_from_str(struct domain *d, const char *str); unsigned int page_to_llc_color(const struct page_info *pg); unsigned int get_max_nr_llc_colors(void); +mfn_t xen_colored_mfn(mfn_t mfn); #endif /* __XEN_LLC_COLORING_H__ */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 17:02:20 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 17:02:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846879.1262031 (Exim 4.92) (envelope-from ) id 1tI9oR-0007Xg-Br; Mon, 02 Dec 2024 17:02:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846879.1262031; Mon, 02 Dec 2024 17:02: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 1tI9oR-0007XZ-8g; Mon, 02 Dec 2024 17:02:19 +0000 Received: by outflank-mailman (input) for mailman id 846879; Mon, 02 Dec 2024 17:02: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 1tI9oP-0006xH-Cu for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 17:02:17 +0000 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [2a00:1450:4864:20::62b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2e553771-b0cf-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 18:02:15 +0100 (CET) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-aa51bf95ce1so76277866b.3 for ; Mon, 02 Dec 2024 09:02: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: 2e553771-b0cf-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1733158935; x=1733763735; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=yvUO+Cob+4BPHSlSnE+x5pEdUSplc0l78jq4eGwEYSw=; b=HxFNXmgHfqVZ/5XOIvZj32pVqMnNP0DyPFSrJu6yvwGxFZ14MKl6NxVnUEV8C3ZqEk ecxkUOPYA/DxXOx+CJosBuZBKGsh1xCTpCEXF1u1snMcp+Vnwp7loRMLMfHs4Az55J8o 3kCkr0n/QwT6Is98wOb1mTPZTDWnoHTTNy0I8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733158935; x=1733763735; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=yvUO+Cob+4BPHSlSnE+x5pEdUSplc0l78jq4eGwEYSw=; b=qeCyKg04Z8jA6MOG1PODwb5hBYsqqmnuJXeB/s2SB28clZalh45mvE6Vw91Dc9a0B4 PMSHwdQUKuwOkJD4IBHtDplKfmJ20kB5Hc3UBD6PAb+quFThRSlDF5xHF8TxR8G7nHie UFzX4GGDJDMpkqjb8rDox+cAwy28/BulrpHH4W66D3OQFXv5BqxjMKFAFsMqDqZSAyjI kCZDssrP6Ja4o0rwVkei1G+t2chals256wo2iLmgYB7ny65c3U9PyBggRAuXS53VHjcG NMvmi6gxqhhWI6c6kRynYUwoZIzNEw3wsvA+lbzNWeJHgyV6BQCJTCeC6njoNpAExLc0 vr2g== X-Forwarded-Encrypted: i=1; AJvYcCVh1JvUeHKNp2/B6Ln/pIEQwv7AmS98+udO8IKGT/mBj8indcd74se0kxDI951w9r86iic4/kyMGF4=@lists.xenproject.org X-Gm-Message-State: AOJu0YxhXeLpXuHcwWhIPywOjQCsYxjuwoSVQE3l5URiRxZInHzbw53h NsoBYvfX22XHb3QhT5zn2cTUI2hRoiwuyCW7mEvj/PXEUQr2GAT8Vknqqbxrl/dXp6b7S3qNDNh +5HIrhGYd5eNSH3PL+xvkCBnsUEwHcmrrLXeh3g== X-Gm-Gg: ASbGncu8DjMUwSIBSWc8MfazNkvL2q6movQt/SoSkCUjfzV+1+cthyp6Ow8ZKB3iuOV QDQjbq4gml7LXC32Og0/LzuqmzBB2wG3DK0fwIMFwxcz+lUSsaaNT2LRazLb8+ZPSBw== X-Google-Smtp-Source: AGHT+IGA/yyMxVuh1zjvfEZctTTbU1UJeWezawIMrQd4uH37xw0bXd5kJbfbI4cQk1fMeBFilqXjf11v4Wyjzl82CCQ= X-Received: by 2002:a17:906:1bb2:b0:aa2:c73:3720 with SMTP id a640c23a62f3a-aa58107846bmr2358157166b.58.1733158933157; Mon, 02 Dec 2024 09:02:13 -0800 (PST) MIME-Version: 1.0 From: Kelly Choi Date: Mon, 2 Dec 2024 17:01:37 +0000 Message-ID: Subject: New Xen Project Website To: Xen Project Advisory Board , xen-announce@lists.xenproject.org, xen-devel Cc: "committers @ xenproject . org" Content-Type: multipart/alternative; boundary="0000000000008cffb706284c82ef" --0000000000008cffb706284c82ef Content-Type: text/plain; charset="UTF-8" Hello Xen Community, For the past 12 months, I have been working with our web developer and UX designer on creating and refreshing our project website. I'm excited to share that this is now live! The URL remains the same and you can view this at *https://xenproject.org/ * These new changes are part of an ongoing effort to increase our visibility and make it easier to find information on pages. Our documentation will still link to our old wiki for now, as this is where most of our guides are stored. However, you might remember we are in the process of moving to Sphinx so we will eventually update the website once we have more content created. We welcome community members to contribute to this! I'd also like to thank our existing board members, whose financial investment in the Xen Project allows for these changes. If you do have any feedback or notice errors, please feel free to reach out. Thanks, Kelly Choi Community Manager Xen Project --0000000000008cffb706284c82ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Xen Community,

For the= past 12 months, I have been working with our web developer and UX designer= on creating and refreshing our project website. I'm excited=C2=A0to sh= are that this=C2=A0is now live!
The URL remains the same and you = can view this at=C2=A0https://xenpro= ject.org/=C2=A0

These new changes are part= of an ongoing effort to increase our visibility and make it easier to find= information on pages.=C2=A0

Our documentation wil= l still link to our old wiki for now, as this is where most of our guides a= re stored. However, you might remember we are in the process of moving to S= phinx so we will eventually update the website once we have more content cr= eated. We welcome community members to contribute to this!

I'd also like to thank our existing board members, whose finan= cial investment in the Xen Project allows for these changes.

=
If you do have any feedback or notice errors,=C2=A0please feel f= ree to reach out.

Thanks,=
Kelly Choi
C= ommunity Manager
--0000000000008cffb706284c82ef-- From xen-devel-bounces@lists.xenproject.org Mon Dec 02 17:21:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 17:21:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846934.1262056 (Exim 4.92) (envelope-from ) id 1tIA7K-0003lH-5Z; Mon, 02 Dec 2024 17:21:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846934.1262056; Mon, 02 Dec 2024 17: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 1tIA7K-0003lA-2k; Mon, 02 Dec 2024 17:21:50 +0000 Received: by outflank-mailman (input) for mailman id 846934; Mon, 02 Dec 2024 17:21: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 1tIA7J-0003l4-9g for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 17:21:49 +0000 Received: from mail136-20.atl41.mandrillapp.com (mail136-20.atl41.mandrillapp.com [198.2.136.20]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e86c27f2-b0d1-11ef-a0d2-8be0dac302b0; Mon, 02 Dec 2024 18:21:47 +0100 (CET) Received: from pmta11.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail136-20.atl41.mandrillapp.com (Mailchimp) with ESMTP id 4Y29Z15nXHzCf9MQv for ; Mon, 2 Dec 2024 17:21:45 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 2b9c360ecc7e462db0f990868fee4e0c; Mon, 02 Dec 2024 17:21:45 +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: e86c27f2-b0d1-11ef-a0d2-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1733160105; x=1733420605; bh=IauL8Qp0YWYvkAARRtO9cDCFO2BMI77KcbI4z8abZFI=; 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=TJYc7w4NRxGk6MPQUE9jI6jgbHmWSm2V+ZytN5Wtn08PPdWeiCYQrLsklgDRCx5sO WVj8PJMLUwky6gh67HNu8abeMQfbBE99c9eC5QKlo0pO8UpulMOVx5qC1E/afJwgBB ovtuGZeq2LZQyjrymxAdbkkgzGvQOniOrNcZxLonW5VqO85e0N0Ecj5Y4ygVGPiros h/x1gGYE2L8wh641vUKYDOckcgSfRDwy9c5Dnx0VNPEIh1dkeu5rtcBGcBSiwWsS1s MTuKhIGa1ziWeeosRSJr0/tloxYXQkrG10aTkq5HjdrPkb6XnYy6S3sixGcBt9PkTQ FhuMlION6UL2Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1733160105; x=1733420605; i=thierry.escande@vates.tech; bh=IauL8Qp0YWYvkAARRtO9cDCFO2BMI77KcbI4z8abZFI=; 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=qnbSV9suHL9D9gVxDNxH6dKUO7oSiJ0TlwhWjgh2dgAp7ebtGSyzvr1iBTFsGNbj4 7jp9WMn+hueO1+suofQyezozU9A/+IL6ubTu+C3Yc110R70VaaiST4+nvGHEl5i0fS 9cJeeilsLWUmCRxSFttLA+5zm8Jje1M1vFnuqZpWqpMBzOOW3r6W6jYCYk7T2+4UwD A40zjaWHUhUq/osiVjtw3eqxPOvzpbEBPqbfq/dPS6MMIknq0FNxd+hRFHExaB61In t7iiRjgg232yE+6BMJfDWu0z4rYTXrMs3qHzivAUCzs2npJ0HIV+bdKxq9nrndBL8y 2Ly8ok8JqhS4Q== From: "Thierry Escande" Subject: =?utf-8?Q?Re:=20[PATCH=20v2=201/2]=20xen/swiotlb:=20add=20alignment=20check=20for=20dma=20buffers?= X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1733160104462 Message-Id: To: =?utf-8?Q?J=C3=BCrgen=20Gro=C3=9F?= , linux-kernel@vger.kernel.org, iommu@lists.linux.dev Cc: "Stefano Stabellini" , "Oleksandr Tyshchenko" , xen-devel@lists.xenproject.org, jbeulich@suse.com References: <20240916064748.18071-1-jgross@suse.com> <20240916064748.18071-2-jgross@suse.com> <2d4fd45a-2461-441e-a116-3b6cff18ee9e@suse.com> In-Reply-To: <2d4fd45a-2461-441e-a116-3b6cff18ee9e@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.2b9c360ecc7e462db0f990868fee4e0c?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20241202:md Date: Mon, 02 Dec 2024 17:21:45 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/12/2024 09:27, J=C3=BCrgen Gro=C3=9F wrote: > On 29.11.24 18:36, Thierry Escande wrote: >> Hi, >> >> On 16/09/2024 08:47, Juergen Gross wrote: >>> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c >>> index 35155258a7e2..ddf5b1df632e 100644 >>> --- a/drivers/xen/swiotlb-xen.c >>> +++ b/drivers/xen/swiotlb-xen.c >>> @@ -78,9 +78,15 @@ static inline int >>> range_straddles_page_boundary(phys_addr_t p, size_t size) >>> =C2=A0 { >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unsigned long next_bfn, xen_pfn =3D XEN_= PFN_DOWN(p); >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unsigned int i, nr_pages =3D XEN_PFN_UP(= xen_offset_in_page(p) + >>> size); >>> +=C2=A0=C2=A0=C2=A0 phys_addr_t algn =3D 1ULL << (get_order(size) + PAG= E_SHIFT); >>> =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 next_bfn =3D pfn_to_bfn(xen_pfn); >>> =C2=A0 +=C2=A0=C2=A0=C2=A0 /* If buffer is physically aligned, ensure D= MA alignment. */ >>> +=C2=A0=C2=A0=C2=A0 if (IS_ALIGNED(p, algn) && >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 !IS_ALIGNED(next_bfn << XEN= _PAGE_SHIFT, algn)) >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 1; >> >> There is a regression in the mpt3sas driver because of this change. >> When, in a dom0, this driver creates its DMA pool at probe time and >> calls dma_pool_zalloc() (see [1]), the call to >> range_straddles_page_boundary() (from xen_swiotlb_alloc_coherent()) >> returns 1 because of the alignment checks added by this patch. Then the >> call to xen_create_contiguous_region() in xen_swiotlb_alloc_coherent() >> fails because the passed size order is too big (> MAX_CONTIG_ORDER). >> This driver sets the pool allocation block size to 2.3+ MBytes. >> >> =C2=A0From previous discussions on the v1 patch, these checks are not >> necessary from xen_swiotlb_alloc_coherent() that already ensures >> alignment, right? > > It ensures alignment regarding guest physical memory, but it doesn't do > so for machine memory. > > For DMA machine memory proper alignment might be needed, too, so the > check is required. As an example, some crypto drivers seem to rely on > proper machine memory alignment, which was the reason for those checks > to be added. > > Possible solutions include: > > - rising the MAX_CONTIG_ORDER limit (to which value?) Looks like the quick and easy solution. Bumping MAX_CONTIG_ORDER to 10 would allow 4MB pools, enough for this particular driver. I'll send a patch if that sounds reasonable. Regards, Thierry > - adding a way to allocate large DMA buffers with relaxed alignment > =C2=A0 requirements (this will impact the whole DMA infrastructure plus > =C2=A0 drivers like mp3sas which would need to use the new interface) > - modify the mpt3sas driver to stay within the current limits > - only guarantee proper machine memory alignment up to MAX_CONTIG_ORDER > =C2=A0 (risking to introduce hard to diagnose bugs for the rare use cases= of > =C2=A0 such large buffers) > > > Juergen From xen-devel-bounces@lists.xenproject.org Mon Dec 02 17:33:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 17:33:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846944.1262067 (Exim 4.92) (envelope-from ) id 1tIAIm-0006jA-5v; Mon, 02 Dec 2024 17:33:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846944.1262067; Mon, 02 Dec 2024 17:33:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIAIm-0006j3-1k; Mon, 02 Dec 2024 17:33:40 +0000 Received: by outflank-mailman (input) for mailman id 846944; Mon, 02 Dec 2024 17:33:38 +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 1tIAIk-0006ix-Pk for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 17:33:38 +0000 Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [2607:f8b0:4864:20::331]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8f0d4e62-b0d3-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 18:33:36 +0100 (CET) Received: by mail-ot1-x331.google.com with SMTP id 46e09a7af769-71d5476ebb1so1951442a34.2 for ; Mon, 02 Dec 2024 09:33: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: 8f0d4e62-b0d3-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1733160815; x=1733765615; 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=HrUozg3jRdY0qRVlW3pISKvHP9R1SVt3R+pgqv7WHfY=; b=z4Hr+9KSzsjRv/sV1b0kJHsZnyq/JjWQIrmUhMEK/7m7d+Pozx9vonKjrElmYj/Iaj LDEDz8fvaum5YTuUXRPtona9d/oayildKonFOGlCZG8br2hbfDUKCSCVjnsco0KACni2 4jxsAqHlo/R1zLqSj6/8UPuNnO0zwW9feRt4sjjsv32uxQreoTzN8LZWeqfHUbagW4Nh n8kSTspD85CXJyyMLlpO15YedEu69lNYDlyHvjYBPTAUAINMZa1bjF0L5xQAGmEWsoY9 M2EayD/XuR1+lTMyQb5BCm29I5G0VRPksG9sTyReUMONv7i0nPsLe1WgGv+44LlFkzNi 9DbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733160815; x=1733765615; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HrUozg3jRdY0qRVlW3pISKvHP9R1SVt3R+pgqv7WHfY=; b=ZRz8WVvnp8FGjlbyP+I0BCivcqCDIBQZQEUbaTJZxNkywy4w2gLV4C+lfXfUIUhrue v8jY7rVj/mUUtDIoAi5ucrkcoABJ/owyW7aT4bI1axzX2KHmLVt6giFxcKGw5mS8uDrQ IXUlIEMzPKC+a7R9GpPgHHCR5eyFRw1g7ZaOJtYNSztebWmw5lfpt1DGBpjJMQ/P3hHJ 5KdkxrzrDaKe6Hstfjyn/qT4DkNB7W1Fu9l9lCRvSZC/cDUmSZ19JSGzKT0nFCqi1yCL WNaHV26lgNGL+DnkAHG9opfMNQCeo7n1JVyIdMnGnwOwRkL1xQJKVwQdsANFGqslDX+J GsoA== X-Gm-Message-State: AOJu0YyEODHO6C2jIWYefRIo8FnSkRWMC/x59LDmOddr8jJZCKrD/62B +A6ywMIO0xtfnIoY2dNMIRTRLHJLw9zKpMBU5B3yHLOvAKekyXMrQ2o76XqbxnwJ5xO1S7PsS/i YevjTD9tt9afQ4w1io+UBWlLd3VNd0u0URzwnFLaID3jB/NDFWng= X-Gm-Gg: ASbGnctxhpWx4ys0S7SMmZsWyyAfuvQ36gs76vBCZEf0nyH+XGO5iqeYqpW7H7tjldI gw1IoEEasp0LYjOqxk3+twQR0Frva9Iig X-Google-Smtp-Source: AGHT+IHaq5L05Jz51NraCFfDdHEi6jfBClAScqBxMrcR05V1qNObc+OAZ858XmCVZKM+sVCqQRYnQGRbxjZSZPdb93w= X-Received: by 2002:a05:6830:25d6:b0:71d:5983:8827 with SMTP id 46e09a7af769-71d65cf7445mr14236820a34.19.1733160814980; Mon, 02 Dec 2024 09:33:34 -0800 (PST) MIME-Version: 1.0 References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> <20241202165921.249585-9-carlo.nonato@minervasys.tech> In-Reply-To: <20241202165921.249585-9-carlo.nonato@minervasys.tech> From: Carlo Nonato Date: Mon, 2 Dec 2024 18:33:24 +0100 Message-ID: Subject: Re: [PATCH v11 08/12] xen/page_alloc: introduce preserved page flags macro To: xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, On Mon, Dec 2, 2024 at 5:59=E2=80=AFPM Carlo Nonato wrote: > > PGC_static and PGC_extra need to be preserved when assigning a page. > Define a new macro that groups those flags and use it instead of or'ing > every time. > > Signed-off-by: Carlo Nonato > --- > v11: > - removed PGC_broken from PGC_preserved > - removed PGC preservation from mark_page_free() > v10: > - fixed commit message > v9: > - add PGC_broken to PGC_preserved > - clear PGC_extra in alloc_domheap_pages() only if MEMF_no_refcount is se= t > v8: > - fixed PGC_extra ASSERT fail in alloc_domheap_pages() by removing PGC_ex= tra > before freeing > v7: > - PGC_preserved used also in mark_page_free() > v6: > - preserved_flags renamed to PGC_preserved > - PGC_preserved is used only in assign_pages() > v5: > - new patch > --- > xen/common/page_alloc.c | 17 +++++++++++++---- > 1 file changed, 13 insertions(+), 4 deletions(-) > > diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c > index 55d561e93c..e73b404169 100644 > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -161,6 +161,7 @@ > #endif > > #define PGC_no_buddy_merge PGC_static > +#define PGC_preserved (PGC_extra | PGC_static) > > #ifndef PGT_TYPE_INFO_INITIALIZER > #define PGT_TYPE_INFO_INITIALIZER 0 > @@ -1447,8 +1448,7 @@ static bool mark_page_free(struct page_info *pg, mf= n_t mfn) > break; > > case PGC_state_offlining: > - pg->count_info =3D (pg->count_info & PGC_broken) | > - PGC_state_offlined; > + pg->count_info =3D (pg->count_info & PGC_broken) | PGC_state_off= lined; > pg_offlined =3D true; > break; > > @@ -2382,7 +2382,7 @@ int assign_pages( > > for ( i =3D 0; i < nr; i++ ) > { > - ASSERT(!(pg[i].count_info & ~(PGC_extra | PGC_static))); > + ASSERT(!(pg[i].count_info & ~PGC_preserved)); > if ( pg[i].count_info & PGC_extra ) > extra_pages++; > } > @@ -2442,7 +2442,7 @@ int assign_pages( > page_set_owner(&pg[i], d); > smp_wmb(); /* Domain pointer must be visible before updating ref= cnt. */ > pg[i].count_info =3D > - (pg[i].count_info & (PGC_extra | PGC_static)) | PGC_allocate= d | 1; > + (pg[i].count_info & PGC_preserved) | PGC_allocated | 1; > > page_list_add_tail(&pg[i], page_to_list(d, &pg[i])); > } > @@ -2501,6 +2501,14 @@ struct page_info *alloc_domheap_pages( > } > if ( assign_page(pg, order, d, memflags) ) > { > + if ( memflags & MEMF_no_refcount ) > + { > + unsigned long i; > + > + for ( i =3D 0; i < (1UL << order); i++ ) > + pg[i].count_info &=3D ~PGC_extra; > + } > + > free_heap_pages(pg, order, memflags & MEMF_no_scrub); > return NULL; > } > @@ -2555,6 +2563,7 @@ void free_domheap_pages(struct page_info *pg, unsig= ned int order) > { > ASSERT(d->extra_pages); > d->extra_pages--; > + pg[i].count_info &=3D ~PGC_extra; > } > } > > -- > 2.43.0 > Sorry guys, this patch is wrong. Here's the correct one. diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 55d561e93c..1c0990b180 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -161,6 +161,7 @@ #endif #define PGC_no_buddy_merge PGC_static +#define PGC_preserved (PGC_extra | PGC_static) #ifndef PGT_TYPE_INFO_INITIALIZER #define PGT_TYPE_INFO_INITIALIZER 0 @@ -2382,7 +2383,7 @@ int assign_pages( for ( i =3D 0; i < nr; i++ ) { - ASSERT(!(pg[i].count_info & ~(PGC_extra | PGC_static))); + ASSERT(!(pg[i].count_info & ~PGC_preserved)); if ( pg[i].count_info & PGC_extra ) extra_pages++; } @@ -2442,7 +2443,7 @@ int assign_pages( page_set_owner(&pg[i], d); smp_wmb(); /* Domain pointer must be visible before updating refcn= t. */ pg[i].count_info =3D - (pg[i].count_info & (PGC_extra | PGC_static)) | PGC_allocated = | 1; + (pg[i].count_info & PGC_preserved) | PGC_allocated | 1; page_list_add_tail(&pg[i], page_to_list(d, &pg[i])); } Sorry about that. Thanks. From xen-devel-bounces@lists.xenproject.org Mon Dec 02 18:23:57 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 18:23:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846955.1262075 (Exim 4.92) (envelope-from ) id 1tIB5B-00073p-Mb; Mon, 02 Dec 2024 18:23:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846955.1262075; Mon, 02 Dec 2024 18:23: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 1tIB5B-00073i-Jq; Mon, 02 Dec 2024 18:23:41 +0000 Received: by outflank-mailman (input) for mailman id 846955; Mon, 02 Dec 2024 18:23:40 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIB5A-00073a-0N for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 18:23:40 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tIB53-000Ls2-1D; Mon, 02 Dec 2024 18:23:33 +0000 Received: from [2a02:8012:3a1:0:c6e:c614:26eb:b495] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tIB53-00AuT8-1A; Mon, 02 Dec 2024 18:23: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" 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=Zf+CN+1FO8AbVDZckrdqTGAafV0mB3ewjuyGTquR5HE=; b=kTJurHE7h4ofFG11BGg/+W49Xx VrmTzaOvglrtNGBqs0g7FijGOvkAqD+H1fCOCnBft5fWhVEzQHPjmgzK/15kjV/zjNBRBCU2x02OF NRgEmajTjqnheEvVWKfGnc+WlHJM7Fq3Y3ikaV0uuznaAzsag8kFVdVDmEirjnEWOn7A=; Message-ID: <71681528-6571-4d31-830c-89bbad6b55a5@xen.org> Date: Mon, 2 Dec 2024 18:23:31 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm32: Get rid of __memzero() Content-Language: en-GB To: Jan Beulich Cc: Julien Grall , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , xen-devel@lists.xenproject.org References: <20241127105512.88703-1-julien@xen.org> <0e3ddfc0-af52-4127-a130-76299101f6ec@suse.com> From: Julien Grall In-Reply-To: <0e3ddfc0-af52-4127-a130-76299101f6ec@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Jan, On 27/11/2024 11:09, Jan Beulich wrote: > On 27.11.2024 11:55, Julien Grall wrote: >> From: Julien Grall >> >> All the code in arch/arm32/lib/ where copied from Linux 3.16 >> and never re-synced since then. >> >> A few years ago, Linux got rid of __memzero() because the implementation >> is very similar to memset(p,0,n) and the current use of __memzero() >> interferes with optimization. See full commit message from Linux below. >> >> So it makes sense to get rid of __memzero in Xen as well. >> >> From ff5fdafc9e9702846480e0cea55ba861f72140a2 Mon Sep 17 00:00:00 2001 >> From: Nicolas Pitre >> Date: Fri, 19 Jan 2018 18:17:46 +0100 >> Subject: [PATCH] ARM: 8745/1: get rid of __memzero() >> >> The __memzero assembly code is almost identical to memset's except for >> two orr instructions. The runtime performance of __memset(p, n) and >> memset(p, 0, n) is accordingly almost identical. >> >> However, the memset() macro used to guard against a zero length and to >> call __memzero at compile time when the fill value is a constant zero >> interferes with compiler optimizations. >> >> Arnd found tha the test against a zero length brings up some new >> warnings with gcc v8: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82103 >> >> And successively rremoving the test against a zero length and the call >> to __memzero optimization produces the following kernel sizes for >> defconfig with gcc 6: >> >> text data bss dec hex filename >> 12248142 6278960 413588 18940690 1210312 vmlinux.orig >> 12244474 6278960 413588 18937022 120f4be vmlinux.no_zero_test >> 12239160 6278960 413588 18931708 120dffc vmlinux.no_memzero >> >> So it is probably not worth keeping __memzero around given that the >> compiler can do a better job at inlining trivial memset(p,0,n) on its >> own. And the memset code already handles a zero length just fine. >> >> Suggested-by: Arnd Bergmann >> Signed-off-by: Nicolas Pitre >> Acked-by: Ard Biesheuvel >> Acked-by: Arnd Bergmann >> Signed-off-by: Russell King >> >> Origin: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git ff5fdafc9e97 >> Signed-off-by: Julien Grall > > Reviewed-by: Jan Beulich Thanks! > with a suggestion: > >> --- a/xen/arch/arm/README.LinuxPrimitives >> +++ b/xen/arch/arm/README.LinuxPrimitives >> @@ -108,10 +108,9 @@ linux/arch/arm/lib/memchr.S xen/arch/arm/arm32/lib/memchr.S >> linux/arch/arm/lib/memcpy.S xen/arch/arm/arm32/lib/memcpy.S >> linux/arch/arm/lib/memmove.S xen/arch/arm/arm32/lib/memmove.S >> linux/arch/arm/lib/memset.S xen/arch/arm/arm32/lib/memset.S >> -linux/arch/arm/lib/memzero.S xen/arch/arm/arm32/lib/memzero.S >> >> for i in copy_template.S memchr.S memcpy.S memmove.S memset.S \ >> - memzero.S ; do >> + ; do >> diff -u linux/arch/arm/lib/$i xen/arch/arm/arm32/lib/$i >> done > > Also do away with the line continuation at the same time? E.g. > > for i in copy_template.S memchr.S memcpy.S memmove.S memset.S; do > diff -u linux/arch/arm/lib/$i xen/arch/arm/arm32/lib/$i > done I will go with this version because I don't expect the number of files to increase. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Dec 02 18:32:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 18:32:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846965.1262085 (Exim 4.92) (envelope-from ) id 1tIBE6-0000Pk-Eg; Mon, 02 Dec 2024 18:32:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846965.1262085; Mon, 02 Dec 2024 18:32: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 1tIBE6-0000Pd-C7; Mon, 02 Dec 2024 18:32:54 +0000 Received: by outflank-mailman (input) for mailman id 846965; Mon, 02 Dec 2024 18:32:52 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIBE4-0000PX-Ec for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 18:32:52 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tIBE3-000M0b-2I; Mon, 02 Dec 2024 18:32:52 +0000 Received: from [2a02:8012:3a1:0:c6e:c614:26eb:b495] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tIBE3-00AvLi-2a; Mon, 02 Dec 2024 18:32:51 +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=d34t6NqhGUKyrU5b1GJ2UqvM7qZs799ENVBO9NjVGco=; b=kZx/7ha5+dUglb5NYLXifNuNum uNH5fRSWmAxl8u8+qFyVgOyr8M4vFGARhEO0/dsUA78GaRYpsX7VCNFm4wLxaXIui4kAUC/bcYAiz 8JnaaKQZTbSvK6FtF5RDUvIlivPQV/O3ZpcXn1h7kpCxAc8IqnqrJAOvh+G47H4kQJog=; Message-ID: Date: Mon, 2 Dec 2024 18:32:50 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/3] xen/arm: mpu: Create boot-time MPU protection regions Content-Language: en-GB To: Ayan Kumar Halder , Ayan Kumar Halder , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Luca Fancellu References: <20241118121250.4027441-1-ayan.kumar.halder@amd.com> <20241118121250.4027441-2-ayan.kumar.halder@amd.com> <4521597b-2714-4ec2-8e80-d90dfa84ce99@xen.org> <3b29ca45-3df0-4853-88ba-f2138909daa7@amd.com> From: Julien Grall In-Reply-To: <3b29ca45-3df0-4853-88ba-f2138909daa7@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 02/12/2024 15:36, Ayan Kumar Halder wrote: > > On 30/11/2024 17:45, Julien Grall wrote: >> Hi Ayan, > Hi Julien, >> >> On 18/11/2024 12:12, Ayan Kumar Halder wrote: >>> +/* >>> + * Macro to prepare and set a EL2 MPU memory region. >>> + * We will also create an according MPU memory region entry, which >>> + * is a structure of pr_t,  in table \prmap. >>> + * >>> + * sel:         region selector >>> + * base:        reg storing base address >>> + * limit:       reg storing limit address >>> + * prbar:       store computed PRBAR_EL2 value >>> + * prlar:       store computed PRLAR_EL2 value >>> + * maxcount:    maximum number of EL2 regions supported >>> + * attr_prbar:  PRBAR_EL2-related memory attributes. If not >>> specified it will be >>> + *              REGION_DATA_PRBAR >>> + * attr_prlar:  PRLAR_EL2-related memory attributes. If not >>> specified it will be >>> + *              REGION_NORMAL_PRLAR >>> + * >>> + * Preserves \maxcount >>> + * Clobbers \sel, \base, \limit, \prbar, \prlar >> >> Per this line, "\sel" is clobbered. Which implies the caller cannot >> rely on the value. Yet ... >> >>> + * >>> + * Note that all parameters using registers should be distinct. >>> + */ >>> +.macro prepare_xen_region, sel, base, limit, prbar, prlar, maxcount, >>> attr_prbar=REGION_DATA_PRBAR, attr_prlar=REGION_NORMAL_PRLAR >>> +    /* Check if the region is empty */ >>> +    cmp   \base, \limit >>> +    beq   1f >>> + >>> +    /* Check if the number of regions exceeded the count specified >>> in MPUIR_EL2 */ >>> +    cmp   \sel, \maxcount >>> +    bge   fail_insufficient_regions >>> + >>> +    /* Prepare value for PRBAR_EL2 reg and preserve it in \prbar.*/ >>> +    and   \base, \base, #MPU_REGION_MASK >>> +    mov   \prbar, #\attr_prbar >>> +    orr   \prbar, \prbar, \base >>> + >>> +    /* Limit address should be inclusive */ >>> +    sub   \limit, \limit, #1 >>> +    and   \limit, \limit, #MPU_REGION_MASK >>> +    mov   \prlar, #\attr_prlar >>> +    orr   \prlar, \prlar, \limit >>> + >>> +    msr   PRSELR_EL2, \sel >>> +    isb >>> +    msr   PRBAR_EL2, \prbar >>> +    msr   PRLAR_EL2, \prlar >>> +    dsb   sy >>> +    isb >>> + >>> +    add   \sel, \sel, #1 >>> + >>> +1: >>> +.endm >>> + >>> +/* >>> + * Failure caused due to insufficient MPU regions. >>> + */ >>> +FUNC_LOCAL(fail_insufficient_regions) >>> +    PRINT("- Selected MPU region is above the implemented number in >>> MPUIR_EL2 -\r\n") >>> +1:  wfe >>> +    b   1b >>> +END(fail_insufficient_regions) >>> + >>> +/* >>> + * Maps the various sections of Xen (described in xen.lds.S) as >>> different MPU >>> + * regions. >>> + * >>> + * Clobbers x0 - x5 >>> + * >>> + */ >>> +FUNC(enable_boot_cpu_mm) >>> +    /* Get the number of regions specified in MPUIR_EL2 */ >>> +    mrs   x5, MPUIR_EL2 >>> +    and   x5, x5, #NUM_MPU_REGIONS_MASK >>> + >>> +    /* x0: region sel */ >>> +    mov   x0, xzr >>> +    /* Xen text section. */ >>> +    ldr   x1, =_stext >>> +    ldr   x2, =_etext >>> +    prepare_xen_region x0, x1, x2, x3, x4, x5, >>> attr_prbar=REGION_TEXT_PRBAR >>> + >>> +    /* Xen read-only data section. */ >>> +    ldr   x1, =_srodata >>> +    ldr   x2, =_erodata >>> +    prepare_xen_region x0, x1, x2, x3, x4, x5, >>> attr_prbar=REGION_RO_PRBAR >> >> >> ... you will pass x0 (\sel) without any update from the previous call. >> So effectively, you treat \sel as an input/output that will get >> incremented. >> >> Therefore the comment needs to be updated. Possibly to: >> >> " >> output: >> >> sel: Next available index in the MPU >> " > Yes,  makes sense. >> >> I will commit the series once we agree on the wording. > > Yes, agreed with the wording. Perfect. I have committed the series. I am looking forward for the rest of the MPU support :). Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Dec 02 19:08:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 19:08:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846983.1262112 (Exim 4.92) (envelope-from ) id 1tIBmf-0004yw-Dp; Mon, 02 Dec 2024 19:08:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846983.1262112; Mon, 02 Dec 2024 19:08:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIBmf-0004yp-B7; Mon, 02 Dec 2024 19:08:37 +0000 Received: by outflank-mailman (input) for mailman id 846983; Mon, 02 Dec 2024 19:08: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 1tIBme-0004yj-2x for xen-devel@lists.xen.org; Mon, 02 Dec 2024 19:08:36 +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 d26037f7-b0e0-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 20:08:33 +0100 (CET) Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfout.stl.internal (Postfix) with ESMTP id 717A611401D7; Mon, 2 Dec 2024 14:08:31 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-11.internal (MEProxy); Mon, 02 Dec 2024 14:08:31 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 2 Dec 2024 14:08: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: d26037f7-b0e0-11ef-99a3-01e77a169b0f 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=1733166511; x=1733252911; bh=stQmbIMB6d7bKFQLedKn3FV9vJ6OJpwsH/zhKzioNxg=; b= XNa//SLCXxxBDA37f203pw958ORH2cAtJOlBToDGw2SKI3aok0k2Z175nU3urEqo k4ZSrGSCVmg3Qd3TgSXRRh7LibUxPqFPiXaE9yJW9HiDZ7JP+Nf+wWCfO6V6GLPn dKJsk8XZyRUIjgRsUJU5mT19FuKXdsqjdbiyVOTrOZ8WugiyklMDCdT9cfTgwYHG Afqkdqs+WgO4KBCfh+pjh7d43ru+T4l4qt9xQdOMM6Wz1oHGx5l2UbkdVl7aVKmC 4TwXO9cr7z7uch2kAdKyj9iZgOumcLgEJ8jYit+8mHNYGzQCIAWDHqZ42/LabG6+ p9i3YDGXmUp/PEaEmJQ5YA== 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= 1733166511; x=1733252911; bh=stQmbIMB6d7bKFQLedKn3FV9vJ6OJpwsH/z hKzioNxg=; b=gyfIwML+8tY0+2IjQzdAH/pbejFKAoq8JSdQRPHsgO6HTWMHu95 oE+wBUObVYFUOQ40HFnuohrmkkOrdymxfUqceyAEMagXBbXoH9ii29ZZdGOMFdc9 UnYPnIllpoXl3DYXkoNg8G2iZpuhGd7cLfBgTTV7QU48AOBPNqUVtg3pUshGirgb 3szk3g+/S2yTWg543WCzPO9d3ut3/dVMPkEUlSo9bevhCWR+O1XyzFpH7Umbo5a1 rOadKeVDwmsEzhNwhnvleguNO6o5oxn3rXW983/SibJUvKTVWWW0grE9HoGNi6xV oXluxqVg8Yd1fJHmYVAgUqNZmK5w9exgCUw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrheelgdduudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft rfgrthhtvghrnhepgfduleetfeevhfefheeiteeliefhjefhleduveetteekveettddvge euteefjedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnh gspghrtghpthhtohepiedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhgrmhgv shesughinhhgfigrlhhlrdhmvgdruhhkpdhrtghpthhtohepgigvnhdquggvvhgvlheslh hishhtshdrgigvnhdrohhrghdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfees tghithhrihigrdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomh dprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtghomhdprhgtphhtthho pehsvggtuhhrihhthiesgigvnhhprhhojhgvtghtrdhorhhg X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Mon, 2 Dec 2024 20:08:27 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: James Dingwall Cc: xen-devel@lists.xen.org, Andrew Cooper , Jan Beulich , Roger Pau =?utf-8?B?TW9ubsOp?= , "security@xenproject.org" Subject: Re: stable-4.18: reliably crash network driver domain by squeezing free_memory Message-ID: References: <6614df33-e383-44dd-aebc-a238ad82f398@citrix.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cbMKMcFLg4avRI/E" Content-Disposition: inline In-Reply-To: --cbMKMcFLg4avRI/E Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Dec 2024 20:08:27 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: James Dingwall Cc: xen-devel@lists.xen.org, Andrew Cooper , Jan Beulich , Roger Pau =?utf-8?B?TW9ubsOp?= , "security@xenproject.org" Subject: Re: stable-4.18: reliably crash network driver domain by squeezing free_memory On Mon, Dec 02, 2024 at 03:54:23PM +0000, James Dingwall wrote: > So there is some undefined range for (free_memory - m) to (free_memory - = n) > where it is possible to crash the driver domain depending on the guest > startup ordering. My (perhaps naive) reasoning would be that > free_memory is the resource available to safely assign without having to > allow for some unknown overhead and if I do ask for too much then I > get a 'safe' failure. FWIW Qubes OS tries to always keep at least 50MB free for Xen. So, our formula is (free_memory - 50MB). --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --cbMKMcFLg4avRI/E Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmdOBasACgkQ24/THMrX 1yxybAgAgTv8qhLuSCoOhHfNrOvAeuQ7aAmoX7xaf0b2rY6Vc9jtQMeLSXT4FbEn 0jKR94kVqDULqElpWeqgPwjldmpF1mDWNgvoDQuf85qqV+eGMOq5bROAsHH7Pt69 Uo7fh23YA7lFQl6JdcPD4+DB36eXYqEWqqaSAtZWu3iAYZhinPhHASSY4X5WFsvo C9ty8trS+lr65BN5OCZ9zhUhLfFsu3h07qsxZQn2mwQoeEHHIb4fbxTKcMQ1Zhdo l+KuUao8sr1KuwsutBac4eEmadRMPgQfWNTVofLZEkzONKYuAKXsKBnGBnZFFM1o AgSyfTiMa+bPBPA5mhP6QvWKnoYG3g== =PZEU -----END PGP SIGNATURE----- --cbMKMcFLg4avRI/E-- From xen-devel-bounces@lists.xenproject.org Mon Dec 02 19:44:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 19:44:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847001.1262153 (Exim 4.92) (envelope-from ) id 1tICLW-0002Bx-FT; Mon, 02 Dec 2024 19:44:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847001.1262153; Mon, 02 Dec 2024 19:44: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 1tICLW-0002AI-5r; Mon, 02 Dec 2024 19:44:38 +0000 Received: by outflank-mailman (input) for mailman id 847001; Mon, 02 Dec 2024 19:41: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 1tICIo-0001je-9F for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 19:41:50 +0000 Received: from lelvem-ot01.ext.ti.com (lelvem-ot01.ext.ti.com [198.47.23.234]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 71e3929b-b0e5-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 20:41:39 +0100 (CET) Received: from lelv0266.itg.ti.com ([10.180.67.225]) by lelvem-ot01.ext.ti.com (8.15.2/8.15.2) with ESMTPS id 4B2Jf9lX1777088 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Dec 2024 13:41:09 -0600 Received: from DLEE114.ent.ti.com (dlee114.ent.ti.com [157.170.170.25]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTP id 4B2Jf9o8073856; Mon, 2 Dec 2024 13:41:09 -0600 Received: from DLEE114.ent.ti.com (157.170.170.25) by DLEE114.ent.ti.com (157.170.170.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Mon, 2 Dec 2024 13:41:09 -0600 Received: from lelvsmtp5.itg.ti.com (10.180.75.250) by DLEE114.ent.ti.com (157.170.170.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Mon, 2 Dec 2024 13:41:09 -0600 Received: from fllvsmtp7.itg.ti.com ([10.249.42.149]) by lelvsmtp5.itg.ti.com (8.15.2/8.15.2) with ESMTP id 4B2Jf8iL127393; Mon, 2 Dec 2024 13:41:08 -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: 71e3929b-b0e5-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1733168469; bh=pn8eSTUe12a9qvKo+zKnPKpjS9szyd/Lpr/Ci+nt4Fc=; h=From:To:CC:Subject:Date; b=rGZ2UQZlyTutS9HlG7KOnvww9jInzBxpmHEhaqzOPWlCIo3EAJfyjlgGd5KQwoQ4g LvdH5tRnJFnnWrKFeFrDXyCSSAKwp3jVeP2lzpptJecgucUqfZrT4wQimmYZMZyJcn VxOBnZWy3IoAosbhUb9IZwQBIjSeZ6jb3Hn2a6zM= From: Andrew Davis To: Arnd Bergmann , Andre Przywara , Russell King , Daniel Mack , Haojian Zhuang , Robert Jarzmik , Alexey Charkov , Krzysztof Kozlowski , Stefano Stabellini CC: , , , Andrew Davis Subject: [PATCH v4 0/5] Switch more ARM plats to sys-off handler API Date: Mon, 2 Dec 2024 13:41:02 -0600 Message-ID: <20241202194107.105119-1-afd@ti.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-C2ProcessedOrg: 333ef613-75bf-4e12-a4b1-8e3623f5dcea Hello all, Continuing the quest to remove the legacy pm_power_off() global function handler. Remove uses from arch/arm/ using the helper register_platform_power_off(). Thanks, Andrew Changes for v4: - Drop already taken patches - Rebase on latest master Changes for v3: - Rebase on v6.12-rc1 Changes for v2: - Collect Reviewed/Acked-bys - Rebase on v6.11-rc1 Andrew Davis (5): ARM: highbank: Switch to new sys-off handler API ARM: pxa: Switch to new sys-off handler API ARM: sa1100: Switch to new sys-off handler API ARM: vt8500: Switch to new sys-off handler API arm/xen: Switch to new sys-off handler API arch/arm/mach-highbank/highbank.c | 2 +- arch/arm/mach-pxa/spitz.c | 2 +- arch/arm/mach-sa1100/generic.c | 2 +- arch/arm/mach-vt8500/vt8500.c | 2 +- arch/arm/xen/enlighten.c | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) -- 2.39.2 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 19:44:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 19:44:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846994.1262131 (Exim 4.92) (envelope-from ) id 1tICLV-0001sG-HU; Mon, 02 Dec 2024 19:44:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846994.1262131; Mon, 02 Dec 2024 19:44: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 1tICLV-0001rL-BT; Mon, 02 Dec 2024 19:44:37 +0000 Received: by outflank-mailman (input) for mailman id 846994; Mon, 02 Dec 2024 19: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 1tICIe-0001jK-Bx for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 19:41:40 +0000 Received: from lelvem-ot02.ext.ti.com (lelvem-ot02.ext.ti.com [198.47.23.235]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 71cdeedf-b0e5-11ef-a0d3-8be0dac302b0; Mon, 02 Dec 2024 20:41:38 +0100 (CET) Received: from lelv0266.itg.ti.com ([10.180.67.225]) by lelvem-ot02.ext.ti.com (8.15.2/8.15.2) with ESMTPS id 4B2JfCtc1528218 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Dec 2024 13:41:12 -0600 Received: from DLEE114.ent.ti.com (dlee114.ent.ti.com [157.170.170.25]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTP id 4B2JfCKA073877; Mon, 2 Dec 2024 13:41:12 -0600 Received: from DLEE114.ent.ti.com (157.170.170.25) by DLEE114.ent.ti.com (157.170.170.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Mon, 2 Dec 2024 13:41:12 -0600 Received: from lelvsmtp5.itg.ti.com (10.180.75.250) by DLEE114.ent.ti.com (157.170.170.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Mon, 2 Dec 2024 13:41:12 -0600 Received: from fllvsmtp7.itg.ti.com ([10.249.42.149]) by lelvsmtp5.itg.ti.com (8.15.2/8.15.2) with ESMTP id 4B2Jf8iQ127393; Mon, 2 Dec 2024 13:41:11 -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: 71cdeedf-b0e5-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1733168472; bh=wQeXaz16g8BvuxKa6rSagWr4SkeKW522Qc0ciOgW77o=; h=From:To:CC:Subject:Date:In-Reply-To:References; b=xOmSrWmuL7641IvGVJpjRxFzUGUslnfZf9jkh2//cO/IgXTjRJ0clOsqbhZwz4Yu+ CIety5knPe661921/lgq5hSE4HFnoqPIO7QjTX21ov3KsH6kIWogYGd/z4ISqBqWB2 ahdZfZIdSSmbTv6R9t81iZi1FYQLQaqGTxdldJL8= From: Andrew Davis To: Arnd Bergmann , Andre Przywara , Russell King , Daniel Mack , Haojian Zhuang , Robert Jarzmik , Alexey Charkov , Krzysztof Kozlowski , Stefano Stabellini CC: , , , Andrew Davis Subject: [PATCH v4 5/5] arm/xen: Switch to new sys-off handler API Date: Mon, 2 Dec 2024 13:41:07 -0600 Message-ID: <20241202194107.105119-6-afd@ti.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20241202194107.105119-1-afd@ti.com> References: <20241202194107.105119-1-afd@ti.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-C2ProcessedOrg: 333ef613-75bf-4e12-a4b1-8e3623f5dcea Kernel now supports chained power-off handlers. Use register_platform_power_off() that registers a platform level power-off handler. Legacy pm_power_off() will be removed once all drivers and archs are converted to the new sys-off API. Signed-off-by: Andrew Davis --- arch/arm/xen/enlighten.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index a395b6c0aae2a..8655bc3d36347 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -541,7 +541,7 @@ static int __init xen_late_init(void) if (!xen_domain()) return -ENODEV; - pm_power_off = xen_power_off; + register_platform_power_off(xen_power_off); register_restart_handler(&xen_restart_nb); if (!xen_initial_domain()) { struct timespec64 ts; -- 2.39.2 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 19:44:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 19:44:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846995.1262140 (Exim 4.92) (envelope-from ) id 1tICLV-0001yP-RY; Mon, 02 Dec 2024 19:44:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846995.1262140; Mon, 02 Dec 2024 19:44: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 1tICLV-0001w8-K2; Mon, 02 Dec 2024 19:44:37 +0000 Received: by outflank-mailman (input) for mailman id 846995; Mon, 02 Dec 2024 19:41: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 1tICIf-0001jK-3z for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 19:41:41 +0000 Received: from lelvem-ot01.ext.ti.com (lelvem-ot01.ext.ti.com [198.47.23.234]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 726a9a2e-b0e5-11ef-a0d3-8be0dac302b0; Mon, 02 Dec 2024 20:41:39 +0100 (CET) Received: from lelv0265.itg.ti.com ([10.180.67.224]) by lelvem-ot01.ext.ti.com (8.15.2/8.15.2) with ESMTPS id 4B2JfAHv1777092 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 2 Dec 2024 13:41:10 -0600 Received: from DLEE115.ent.ti.com (dlee115.ent.ti.com [157.170.170.26]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 4B2JfA8L018331 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 2 Dec 2024 13:41:10 -0600 Received: from DLEE109.ent.ti.com (157.170.170.41) by DLEE115.ent.ti.com (157.170.170.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Mon, 2 Dec 2024 13:41:10 -0600 Received: from lelvsmtp5.itg.ti.com (10.180.75.250) by DLEE109.ent.ti.com (157.170.170.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Mon, 2 Dec 2024 13:41:09 -0600 Received: from fllvsmtp7.itg.ti.com ([10.249.42.149]) by lelvsmtp5.itg.ti.com (8.15.2/8.15.2) with ESMTP id 4B2Jf8iM127393; Mon, 2 Dec 2024 13:41:09 -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: 726a9a2e-b0e5-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1733168470; bh=P6d498xP36XXy4X2j2XNBIV3J80KTeTFWEpSStPLVgY=; h=From:To:CC:Subject:Date:In-Reply-To:References; b=tHfWAYTb7oGZnG+xPW+4zrXYKTxWVEwuxtfhYX0ntLfAjUFfoG+oqDzQ+1JgTAnOb BVZboqAUgIAiyyUo0qOBQHDp7XAL/HZHB+Qolc/aJ2pLHvEht0l3gYU0G9VfqPB8en BfpXfNCSCPOlgRsSmBmjlU38u00ZrO125iNpWj4Q= From: Andrew Davis To: Arnd Bergmann , Andre Przywara , Russell King , Daniel Mack , Haojian Zhuang , Robert Jarzmik , Alexey Charkov , Krzysztof Kozlowski , Stefano Stabellini CC: , , , Andrew Davis Subject: [PATCH v4 1/5] ARM: highbank: Switch to new sys-off handler API Date: Mon, 2 Dec 2024 13:41:03 -0600 Message-ID: <20241202194107.105119-2-afd@ti.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20241202194107.105119-1-afd@ti.com> References: <20241202194107.105119-1-afd@ti.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-C2ProcessedOrg: 333ef613-75bf-4e12-a4b1-8e3623f5dcea Kernel now supports chained power-off handlers. Use register_platform_power_off() that registers a platform level power-off handler. Legacy pm_power_off() will be removed once all drivers and archs are converted to the new sys-off API. Signed-off-by: Andrew Davis Reviewed-by: Andre Przywara --- arch/arm/mach-highbank/highbank.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-highbank/highbank.c b/arch/arm/mach-highbank/highbank.c index 5d4f977ac7d2a..47335c7dadf8d 100644 --- a/arch/arm/mach-highbank/highbank.c +++ b/arch/arm/mach-highbank/highbank.c @@ -143,7 +143,7 @@ static void __init highbank_init(void) sregs_base = of_iomap(np, 0); WARN_ON(!sregs_base); - pm_power_off = highbank_power_off; + register_platform_power_off(highbank_power_off); highbank_pm_init(); bus_register_notifier(&platform_bus_type, &highbank_platform_nb); -- 2.39.2 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 19:44:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 19:44:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846999.1262142 (Exim 4.92) (envelope-from ) id 1tICLW-00025G-1F; Mon, 02 Dec 2024 19:44:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846999.1262142; Mon, 02 Dec 2024 19:44: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 1tICLV-00022h-Sk; Mon, 02 Dec 2024 19:44:37 +0000 Received: by outflank-mailman (input) for mailman id 846999; Mon, 02 Dec 2024 19:41: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 1tICIg-0001jK-41 for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 19:41:42 +0000 Received: from fllv0015.ext.ti.com (fllv0015.ext.ti.com [198.47.19.141]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 72b8f423-b0e5-11ef-a0d3-8be0dac302b0; Mon, 02 Dec 2024 20:41:40 +0100 (CET) Received: from lelv0265.itg.ti.com ([10.180.67.224]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 4B2JfAbX018430; Mon, 2 Dec 2024 13:41:10 -0600 Received: from DLEE114.ent.ti.com (dlee114.ent.ti.com [157.170.170.25]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 4B2JfAe1018340 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 2 Dec 2024 13:41:10 -0600 Received: from DLEE112.ent.ti.com (157.170.170.23) by DLEE114.ent.ti.com (157.170.170.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Mon, 2 Dec 2024 13:41:10 -0600 Received: from lelvsmtp5.itg.ti.com (10.180.75.250) by DLEE112.ent.ti.com (157.170.170.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Mon, 2 Dec 2024 13:41:10 -0600 Received: from fllvsmtp7.itg.ti.com ([10.249.42.149]) by lelvsmtp5.itg.ti.com (8.15.2/8.15.2) with ESMTP id 4B2Jf8iN127393; Mon, 2 Dec 2024 13:41:09 -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: 72b8f423-b0e5-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1733168470; bh=1hB+Rsl8dEIP80gJg1dRpUGGywa9yjHgvJWWFP9MDZc=; h=From:To:CC:Subject:Date:In-Reply-To:References; b=yWXLnTHwyw6OZErIdXaEl0iD3giWyOLXMsrm1kKc67jTA1r9YvNYEFDLLhKXFhYh+ nd2FlxCcZJ2Hik3hA3QqQnQfJoNraILyRB7usN8bs6ItTAdOfNMQz6xutiW/L4nXxG jEcJdaX37p4LagWo98aDTsFEf7d4YByTkoudOuMY= From: Andrew Davis To: Arnd Bergmann , Andre Przywara , Russell King , Daniel Mack , Haojian Zhuang , Robert Jarzmik , Alexey Charkov , Krzysztof Kozlowski , Stefano Stabellini CC: , , , Andrew Davis Subject: [PATCH v4 2/5] ARM: pxa: Switch to new sys-off handler API Date: Mon, 2 Dec 2024 13:41:04 -0600 Message-ID: <20241202194107.105119-3-afd@ti.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20241202194107.105119-1-afd@ti.com> References: <20241202194107.105119-1-afd@ti.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-C2ProcessedOrg: 333ef613-75bf-4e12-a4b1-8e3623f5dcea Kernel now supports chained power-off handlers. Use register_platform_power_off() that registers a platform level power-off handler. Legacy pm_power_off() will be removed once all drivers and archs are converted to the new sys-off API. Signed-off-by: Andrew Davis --- arch/arm/mach-pxa/spitz.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c index 33533e35720f8..c0b1f7e6be874 100644 --- a/arch/arm/mach-pxa/spitz.c +++ b/arch/arm/mach-pxa/spitz.c @@ -1096,7 +1096,7 @@ static void __init spitz_init(void) software_node_register(&spitz_scoop_2_gpiochip_node); init_gpio_reset(SPITZ_GPIO_ON_RESET, 1, 0); - pm_power_off = spitz_poweroff; + register_platform_power_off(spitz_poweroff); PMCR = 0x00; -- 2.39.2 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 19:44:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 19:44:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.846993.1262126 (Exim 4.92) (envelope-from ) id 1tICLV-0001pQ-8j; Mon, 02 Dec 2024 19:44:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 846993.1262126; Mon, 02 Dec 2024 19:44: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 1tICLV-0001pH-5u; Mon, 02 Dec 2024 19:44:37 +0000 Received: by outflank-mailman (input) for mailman id 846993; Mon, 02 Dec 2024 19: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 1tICId-0001jK-TH for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 19:41:40 +0000 Received: from lelv0142.ext.ti.com (lelv0142.ext.ti.com [198.47.23.249]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 70e4eaa1-b0e5-11ef-a0d3-8be0dac302b0; Mon, 02 Dec 2024 20:41:38 +0100 (CET) Received: from lelv0265.itg.ti.com ([10.180.67.224]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 4B2JfBig060711; Mon, 2 Dec 2024 13:41:11 -0600 Received: from DFLE115.ent.ti.com (dfle115.ent.ti.com [10.64.6.36]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 4B2JfBjE018352 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 2 Dec 2024 13:41:11 -0600 Received: from DFLE113.ent.ti.com (10.64.6.34) by DFLE115.ent.ti.com (10.64.6.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Mon, 2 Dec 2024 13:41:11 -0600 Received: from lelvsmtp5.itg.ti.com (10.180.75.250) by DFLE113.ent.ti.com (10.64.6.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Mon, 2 Dec 2024 13:41:11 -0600 Received: from fllvsmtp7.itg.ti.com ([10.249.42.149]) by lelvsmtp5.itg.ti.com (8.15.2/8.15.2) with ESMTP id 4B2Jf8iP127393; Mon, 2 Dec 2024 13:41:10 -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: 70e4eaa1-b0e5-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1733168471; bh=UUkIu/8Qmux6+/va5NpKSfNIFMGEqp8ObO5jfrobR38=; h=From:To:CC:Subject:Date:In-Reply-To:References; b=Sb56Fw/Np5bBmWP10EiYKoAuc68IRVqCvFiPqIaTykrGLXoWuQ+/upX8a6SJlKE4I r5cS4bf5eN7PsdtblNfGQZQKZGSBMtvkT82pOv1jMgiG5ZMDRo0sKEs3OfSuq2v+h4 WFDf1Oi1v1px4/Vbc4cIdqTTg7nDXt6RbFZwdr+I= From: Andrew Davis To: Arnd Bergmann , Andre Przywara , Russell King , Daniel Mack , Haojian Zhuang , Robert Jarzmik , Alexey Charkov , Krzysztof Kozlowski , Stefano Stabellini CC: , , , Andrew Davis Subject: [PATCH v4 4/5] ARM: vt8500: Switch to new sys-off handler API Date: Mon, 2 Dec 2024 13:41:06 -0600 Message-ID: <20241202194107.105119-5-afd@ti.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20241202194107.105119-1-afd@ti.com> References: <20241202194107.105119-1-afd@ti.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-C2ProcessedOrg: 333ef613-75bf-4e12-a4b1-8e3623f5dcea Kernel now supports chained power-off handlers. Use register_platform_power_off() that registers a platform level power-off handler. Legacy pm_power_off() will be removed once all drivers and archs are converted to the new sys-off API. Signed-off-by: Andrew Davis --- arch/arm/mach-vt8500/vt8500.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-vt8500/vt8500.c b/arch/arm/mach-vt8500/vt8500.c index 0ab40087ae1cc..1d294255d7083 100644 --- a/arch/arm/mach-vt8500/vt8500.c +++ b/arch/arm/mach-vt8500/vt8500.c @@ -141,7 +141,7 @@ static void __init vt8500_init(void) pr_err("%s:ioremap(power_off) failed\n", __func__); } if (pmc_base) - pm_power_off = &vt8500_power_off; + register_platform_power_off(vt8500_power_off); else pr_err("%s: PMC Hibernation register could not be remapped, not enabling power off!\n", __func__); } -- 2.39.2 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 19:44:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 19:44:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847002.1262156 (Exim 4.92) (envelope-from ) id 1tICLW-0002KY-Nx; Mon, 02 Dec 2024 19:44:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847002.1262156; Mon, 02 Dec 2024 19:44: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 1tICLW-0002Gy-FL; Mon, 02 Dec 2024 19:44:38 +0000 Received: by outflank-mailman (input) for mailman id 847002; Mon, 02 Dec 2024 19:41: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 1tICIo-0001je-GC for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 19:41:50 +0000 Received: from fllv0015.ext.ti.com (fllv0015.ext.ti.com [198.47.19.141]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 769e2653-b0e5-11ef-99a3-01e77a169b0f; Mon, 02 Dec 2024 20:41:46 +0100 (CET) Received: from lelv0266.itg.ti.com ([10.180.67.225]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 4B2JfBHg018434; Mon, 2 Dec 2024 13:41:11 -0600 Received: from DLEE113.ent.ti.com (dlee113.ent.ti.com [157.170.170.24]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTP id 4B2JfB4d073869; Mon, 2 Dec 2024 13:41:11 -0600 Received: from DLEE103.ent.ti.com (157.170.170.33) by DLEE113.ent.ti.com (157.170.170.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Mon, 2 Dec 2024 13:41:10 -0600 Received: from lelvsmtp5.itg.ti.com (10.180.75.250) by DLEE103.ent.ti.com (157.170.170.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Mon, 2 Dec 2024 13:41:10 -0600 Received: from fllvsmtp7.itg.ti.com ([10.249.42.149]) by lelvsmtp5.itg.ti.com (8.15.2/8.15.2) with ESMTP id 4B2Jf8iO127393; Mon, 2 Dec 2024 13:41:10 -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: 769e2653-b0e5-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1733168471; bh=8gIz69rx+O7g3l2dUBVUwaQsvlZ4QBJNSMujzHzSCeo=; h=From:To:CC:Subject:Date:In-Reply-To:References; b=t62o3g685pCzx96mI0/dHENguE2daTXBpYrgLh0cn+WfgnPhOsx4Ad4tPHOuH5DVl jI5vTfxmbYpfzLfcc4fSSDSxqnCQU54Wx74TOOLbonG3fpDlZCCp+9RQjE10eQH+k1 WpkCLDsfC75vGblnqkelqHwXxydf2Axg/O2QF+WY= From: Andrew Davis To: Arnd Bergmann , Andre Przywara , Russell King , Daniel Mack , Haojian Zhuang , Robert Jarzmik , Alexey Charkov , Krzysztof Kozlowski , Stefano Stabellini CC: , , , Andrew Davis Subject: [PATCH v4 3/5] ARM: sa1100: Switch to new sys-off handler API Date: Mon, 2 Dec 2024 13:41:05 -0600 Message-ID: <20241202194107.105119-4-afd@ti.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20241202194107.105119-1-afd@ti.com> References: <20241202194107.105119-1-afd@ti.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-C2ProcessedOrg: 333ef613-75bf-4e12-a4b1-8e3623f5dcea Kernel now supports chained power-off handlers. Use register_platform_power_off() that registers a platform level power-off handler. Legacy pm_power_off() will be removed once all drivers and archs are converted to the new sys-off API. Signed-off-by: Andrew Davis --- arch/arm/mach-sa1100/generic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-sa1100/generic.c b/arch/arm/mach-sa1100/generic.c index 0c586047d130f..5383a26f51169 100644 --- a/arch/arm/mach-sa1100/generic.c +++ b/arch/arm/mach-sa1100/generic.c @@ -298,7 +298,7 @@ static struct platform_device *sa11x0_devices[] __initdata = { static int __init sa1100_init(void) { struct resource wdt_res = DEFINE_RES_MEM(0x90000000, 0x20); - pm_power_off = sa1100_power_off; + register_platform_power_off(sa1100_power_off); regulator_has_full_constraints(); -- 2.39.2 From xen-devel-bounces@lists.xenproject.org Mon Dec 02 20:38:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 20:38:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847067.1262198 (Exim 4.92) (envelope-from ) id 1tIDC0-0004vk-R4; Mon, 02 Dec 2024 20:38:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847067.1262198; Mon, 02 Dec 2024 20:38:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIDC0-0004vd-O4; Mon, 02 Dec 2024 20:38:52 +0000 Received: by outflank-mailman (input) for mailman id 847067; Mon, 02 Dec 2024 20:38:51 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIDBz-0004vU-HM for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 20:38:51 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tIDBw-000Ogs-19; Mon, 02 Dec 2024 20:38:48 +0000 Received: from [2a02:8012:3a1:0:c6e:c614:26eb:b495] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tIDBw-00B8XO-17; Mon, 02 Dec 2024 20:38: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" 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=SX1o11VmnEru2ojH9pmsWmrHAe7Uo3A6MYVEmSKK2xA=; b=qXVBMAUZzcNUL/4TYyq5XGR2LJ Mk0Fyrivh4YzHtPjpK2lm1JcqB+7HiQyp0ifNggT0TClDsK7AFmfXaEBz/rbZK/K+nIi2oeaBTd7P cdNXwyNr2HNBnllDsaswFaR863BOr1j1IihBtV9jooB61oxA0tvqGypSshCFc343JTH4=; Message-ID: <6d4134c9-25ac-4b16-9928-2a4bdc48d996@xen.org> Date: Mon, 2 Dec 2024 20:38:46 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/5] build: arm64: provide -target and -march if using clang Content-Language: en-GB To: Jan Beulich , Volodymyr Babchuk Cc: Andrew Cooper , Stefano Stabellini , "xen-devel@lists.xenproject.org" , Anthony PERARD , Ayan Kumar Halder , Luca Fancellu References: <20241129014850.2852844-1-volodymyr_babchuk@epam.com> <20241129014850.2852844-4-volodymyr_babchuk@epam.com> <87iks5bsgd.fsf@epam.com> <8df584b8-fb23-4db4-af87-903fde91e42e@xen.org> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Jan, On 02/12/2024 07:52, Jan Beulich wrote: > On 30.11.2024 18:15, Julien Grall wrote: >> On 29/11/2024 22:12, Volodymyr Babchuk wrote: >>> Jan Beulich writes: >>>> On 29.11.2024 02:49, Volodymyr Babchuk wrote: >>>>> --- a/config/arm64.mk >>>>> +++ b/config/arm64.mk >>>>> @@ -5,6 +5,10 @@ CONFIG_XEN_INSTALL_SUFFIX := >>>>> >>>>> CFLAGS += #-marm -march= -mcpu= etc >>>>> >>>>> +ifeq ($(clang),y) >>>>> +CFLAGS += -target aarch64 -march=armv8-a >>>>> +endif >>>> >>>> Why is this dependent on (just?) $(clang), not (also?) $(llvm)? >>> >>> Because this parameter is handled by clang only. There is no harm in >>> providing it explicitly. When building on arm64, value of this parameter >>> will match the default value for the platform. When building on x86, we >>> need to tell clang that it should generate arm64 code anyways. There is >>> no reason in trying to make ARM build with x86 instruction set. >>> >>>> Also >>>> this affects both toolstack builds and hypervisor. Is applying -march >>>> like this actually appropriate for the toolstack? >>> >>> This is a good question. I can't see why this can't be appropriate for >>> toolstack. I.e. what bad can happen when building the toolstack. >> >> In the future, we may want to build the tools for Armv8-M. So I think >> the -march should also applies for the toolstack. > > Perhaps I don't know enough of the Arm world, but: Wouldn't it be possible > to build a tool stack suitable for a wide range for Arm64 flavors, while > requiring more targeted hypervisor binaries? Good question. There are some commonnality between ARMv8-M and ARMv8-R but I am not sure whether it means we could use -march=armv8-a build and run on ARMv8-M. Adding Ayan and Luca. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Dec 02 20:41:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 20:41:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847075.1262207 (Exim 4.92) (envelope-from ) id 1tIDEH-0006hH-6I; Mon, 02 Dec 2024 20:41:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847075.1262207; Mon, 02 Dec 2024 20:41:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIDEH-0006hA-3l; Mon, 02 Dec 2024 20:41:13 +0000 Received: by outflank-mailman (input) for mailman id 847075; Mon, 02 Dec 2024 20:41:11 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIDEF-0006h4-Sb for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 20:41:11 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tIDEF-000OkB-19; Mon, 02 Dec 2024 20:41:11 +0000 Received: from [2a02:8012:3a1:0:c6e:c614:26eb:b495] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tIDEF-00B8gp-1U; Mon, 02 Dec 2024 20:41: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" 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=IwjUOjUCOLRRP5/usm2FAj4h21fTUA/W25Y3l5SSqDE=; b=R+lRUJ6CbzBPtntmGqT6nqFlOo Y0OmqK044uyaTklTNTrOlOfDsolSI6vHfhIRq4AyGUgWmM8tkCvV6atqd1+UmgbBLY1/6atpm3UvX c3h4rr3vDHNUJ2B05YaPu+DmIMmzBXO3rKzJjwpq7ctIncNcAwTbX6Tc19/juthrnxhY=; Message-ID: <02cfc279-bac3-47f7-b2dc-859eb1573e2d@xen.org> Date: Mon, 2 Dec 2024 20:41:09 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/5] arm/setup: Move MMU specific extern declarations to mmu/setup.h Content-Language: en-GB To: Luca Fancellu , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20241129091237.3409304-1-luca.fancellu@arm.com> <20241129091237.3409304-3-luca.fancellu@arm.com> From: Julien Grall In-Reply-To: <20241129091237.3409304-3-luca.fancellu@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Luca, On 29/11/2024 09:12, Luca Fancellu wrote: > Move some extern declarations related to MMU structures and define > from asm/setup.h to asm/mmu/setup.h, in order to increase encapsulation > and allow the MPU part to build, since it has no clue about them. > > Signed-off-by: Luca Fancellu Acked-by: Julien Grall Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Dec 02 20:45:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 20:45:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847086.1262218 (Exim 4.92) (envelope-from ) id 1tIDID-0007P8-NT; Mon, 02 Dec 2024 20:45:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847086.1262218; Mon, 02 Dec 2024 20:45: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 1tIDID-0007P1-Kl; Mon, 02 Dec 2024 20:45:17 +0000 Received: by outflank-mailman (input) for mailman id 847086; Mon, 02 Dec 2024 20:45:17 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIDIC-0007Ov-VF for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 20:45:16 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tIDIC-000Oqp-0d; Mon, 02 Dec 2024 20:45:16 +0000 Received: from [2a02:8012:3a1:0:c6e:c614:26eb:b495] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tIDIC-00B9NI-0f; Mon, 02 Dec 2024 20:45: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" 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=1WZ9rsGy6I2YuVIxZrziyD3fL0QBRDKsRJ1onf97jPg=; b=3sEAflb9ChmaiQe/coKHyhbxSe 3oZ986D/jxxnYWY+PMHCWH+MWJXNCgSp93cpj/IUP96kGvtNavGunC9dAUtVWsY153Gvl/JQyJ3+u L2lo9g8Puaazeb0Qvl1nFYyyMzad/wBosQDlOETOqjmhwMxOAJWZhBfag3kPJAOqvNwY=; Message-ID: <96f33042-b019-40b2-b72e-cc5c1f4855c0@xen.org> Date: Mon, 2 Dec 2024 20:45:14 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 5/5] xen/arm: Move setup_frametable_mappings to arm/mmu Content-Language: en-GB To: Luca Fancellu , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20241129091237.3409304-1-luca.fancellu@arm.com> <20241129091237.3409304-6-luca.fancellu@arm.com> From: Julien Grall In-Reply-To: <20241129091237.3409304-6-luca.fancellu@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Luca, On 29/11/2024 09:12, Luca Fancellu wrote: > diff --git a/xen/arch/arm/mmu/Makefile b/xen/arch/arm/mmu/Makefile > index 2cb44b857dd2..1c89602947de 100644 > --- a/xen/arch/arm/mmu/Makefile > +++ b/xen/arch/arm/mmu/Makefile > @@ -1,3 +1,4 @@ > +obj-y += mm.o > obj-y += p2m.o > obj-y += pt.o > obj-y += setup.o > diff --git a/xen/arch/arm/mmu/mm.c b/xen/arch/arm/mmu/mm.c > new file mode 100644 > index 000000000000..aefec908b7f2 > --- /dev/null > +++ b/xen/arch/arm/mmu/mm.c > @@ -0,0 +1,61 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ arch/arm/mm.c is GPL-2.0-or-later. AFAIU, there are still disagreements within the committers on whether we can drop the "or later" for existing code. So I would suggest to keep the same license. The rest LGTM. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Dec 02 20:53:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 20:53:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847096.1262227 (Exim 4.92) (envelope-from ) id 1tIDQD-00013Z-Co; Mon, 02 Dec 2024 20:53:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847096.1262227; Mon, 02 Dec 2024 20:53: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 1tIDQD-00013S-AK; Mon, 02 Dec 2024 20:53:33 +0000 Received: by outflank-mailman (input) for mailman id 847096; Mon, 02 Dec 2024 20:53:32 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIDQC-00013M-Mg for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 20:53:32 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tIDQB-000P28-31; Mon, 02 Dec 2024 20:53:32 +0000 Received: from [2a02:8012:3a1:0:c6e:c614:26eb:b495] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tIDQC-00BA1Q-07; Mon, 02 Dec 2024 20: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" 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=pdua7B8mNdKb+SIbBcojmnt/LkJXGdP3vi9aKM8Zp1o=; b=aJPigXqoiiTUnA8M6DMN9h41oG ROx5/LD129mZ9G8vFCYVnhhZOeKdJpwgQgRk6mdQtoq/p9VeM4V3TeetTZwVL3XZfe2gqBbNPthKu wqIxpDDdOjg5SrCcfH0g8pAk8BXPFQ12h7n3waQv6yxrG38yjgCM4/A98o3K10oJXMpk=; Message-ID: Date: Mon, 2 Dec 2024 20:53:30 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] xen/mpu: Map early uart when earlyprintk on Content-Language: en-GB To: Ayan Kumar Halder , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20241127183906.485824-1-ayan.kumar.halder@amd.com> <20241127183906.485824-2-ayan.kumar.halder@amd.com> From: Julien Grall In-Reply-To: <20241127183906.485824-2-ayan.kumar.halder@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Ayan, On 27/11/2024 18:39, Ayan Kumar Halder wrote: > CONFIG_EARLY_UART_SIZE is introduced to let user provide physical size of > early UART. Unlike MMU where we map a page in the virtual address space, > here we need to know the exact physical size to be mapped. > As VA == PA in case of MPU, the memory layout follows exactly the hardware > configuration. As a consequence, we set EARLY_UART_VIRTUAL_ADDRESS as physical > address. > > EARLY_UART_BASE_ADDRESS and EARLY_UART_SIZE should be aligned to the minimum > size of MPU region (ie 64 bits) as per the hardware restrictions. Refer ARM > DDI 0600A.d ID120821 A1.3 "A minimum protection region size of 64 bytes.". > > UART is mapped as nGnRE region (as specified by ATTR=100 , refer G1.3.13, > MAIR_EL2, "---0100 Device memory nGnRE") and Doc ID - 102670_0101_02_en I can't find the Doc you point online. Do you have a link? > Table 4-3, Armv8 architecture memory types (nGnRE - Corresponds to Device in > Armv7 architecture). Also, it is mapped as outer shareable, RW at EL2 only I don't quite understand why you mention Armv7 here. The code you modify below is 64-bit so Armv8 only. The code itself LGTM. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Dec 02 20:54:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 20:54:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847103.1262238 (Exim 4.92) (envelope-from ) id 1tIDQw-0001YQ-ML; Mon, 02 Dec 2024 20:54:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847103.1262238; Mon, 02 Dec 2024 20:54: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 1tIDQw-0001YG-JI; Mon, 02 Dec 2024 20:54:18 +0000 Received: by outflank-mailman (input) for mailman id 847103; Mon, 02 Dec 2024 20:54:17 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIDQu-0001Y7-Vu for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 20:54:16 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tIDQu-000P2m-0o; Mon, 02 Dec 2024 20:54:16 +0000 Received: from [2a02:8012:3a1:0:c6e:c614:26eb:b495] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tIDQu-00BA3n-1E; Mon, 02 Dec 2024 20:54: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" 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=ioq9OyZDefqv6t4xRQ1lsI3jBQW2cIv/HXVKr5OmBHY=; b=ltTkyIlkX9rd9pJ8SIYCCmOlJo AQ3PCng+RJ3NiPH9Zbq3dxLUwlU/pEwSn/2gZbSnarXOISWQgqRrvVN7CR6B8DXMhvCAQJ32kKVmh 8iRd7zs2lKWG+IKd02fZGxweom0nBtzGaRSjU7rfrx+A53UP6aMlkBc1Tktdhs6Z6XcY=; Message-ID: <12c66d02-49e2-4912-80ba-412ddebcb081@xen.org> Date: Mon, 2 Dec 2024 20:54:14 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] xen/mmu: enable SMMU subsystem only in MMU Content-Language: en-GB To: Ayan Kumar Halder , xen-devel@lists.xenproject.org Cc: Penny Zheng , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20241127183906.485824-1-ayan.kumar.halder@amd.com> <20241127183906.485824-3-ayan.kumar.halder@amd.com> From: Julien Grall In-Reply-To: <20241127183906.485824-3-ayan.kumar.halder@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Ayan, On 27/11/2024 18:39, Ayan Kumar Halder wrote: > From: Penny Zheng > > In Xen, SMMU subsystem is supported for MMU system only. The reason being SMMU > driver uses the same page tables as MMU. > Thus, we make it dependent on CONFIG_MMU. > > Signed-off-by: Penny Zheng > Signed-off-by: Ayan Kumar Halder Acked-by: Julien Grall Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Dec 02 21:44:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 21:44:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847117.1262248 (Exim 4.92) (envelope-from ) id 1tIEDX-0000uC-5G; Mon, 02 Dec 2024 21:44:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847117.1262248; Mon, 02 Dec 2024 21:44: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 1tIEDX-0000u5-25; Mon, 02 Dec 2024 21:44:31 +0000 Received: by outflank-mailman (input) for mailman id 847117; Mon, 02 Dec 2024 21:44:29 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIEDV-0000tz-QK for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 21:44:29 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tIEDU-000Q1B-2q; Mon, 02 Dec 2024 21:44:29 +0000 Received: from [2a02:8012:3a1:0:c6e:c614:26eb:b495] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tIEDU-00BFHj-2h; Mon, 02 Dec 2024 21:44: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" 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=E4zctEyqEng8Qz8EtwEcpCCuurG450RkiGhedUO1H1A=; b=2FfJQjw9TCPaUBLaOjM7vmbpgs YZoUwoqZr7wQyN9IMuC7EG5jIm2SaCGIA0946vArAumYkAUMWVjyCK4NLG/H5AVs58OUNBLY3QeOv x+fv2ZjZ9EpZGUHnGoCyobugfBW+GSB1L4lfGTkWqzxe8/kLrc55OY6i7EqG4SZYdMcU=; Message-ID: <800b0b49-e6c5-4a83-8ee6-d89d51613b0c@xen.org> Date: Mon, 2 Dec 2024 21:44:26 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 12/12] xen/arm: add cache coloring support for Xen image Content-Language: en-GB To: Carlo Nonato , xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Jan Beulich References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> <20241202165921.249585-13-carlo.nonato@minervasys.tech> From: Julien Grall In-Reply-To: <20241202165921.249585-13-carlo.nonato@minervasys.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Carlo, I appreciate this is v11. So I will try to keep the comments to only what I consider important to fix and some coding style issue. On 02/12/2024 16:59, Carlo Nonato wrote: > --- > xen/arch/arm/alternative.c | 30 +++++++- > xen/arch/arm/arm64/mmu/head.S | 58 +++++++++++++++- > xen/arch/arm/arm64/mmu/mm.c | 28 ++++++-- > xen/arch/arm/include/asm/mmu/layout.h | 3 + > xen/arch/arm/llc-coloring.c | 63 +++++++++++++++++ > xen/arch/arm/mmu/setup.c | 99 +++++++++++++++++++++++---- > xen/arch/arm/setup.c | 10 ++- > xen/common/llc-coloring.c | 18 +++++ > xen/include/xen/llc-coloring.h | 14 ++++ > 9 files changed, 302 insertions(+), 21 deletions(-) > > diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c > index d99b507093..0fcf4e451d 100644 > --- a/xen/arch/arm/alternative.c > +++ b/xen/arch/arm/alternative.c > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -191,6 +192,27 @@ static int __apply_alternatives_multi_stop(void *xenmap) > return 0; > } > > +static void __init *xen_remap_colored(mfn_t xen_mfn, paddr_t xen_size) > +{ > + unsigned int i; > + void *xenmap; > + mfn_t *xen_colored_mfns, mfn; > + > + xen_colored_mfns = xmalloc_array(mfn_t, xen_size >> PAGE_SHIFT); > + if ( !xen_colored_mfns )> + panic("Can't allocate LLC colored MFNs\n"); > + > + for_each_xen_colored_mfn ( xen_mfn, mfn, i ) > + { > + xen_colored_mfns[i] = mfn; > + } NIT: Parenthesis should not be necessary. > + > + xenmap = vmap(xen_colored_mfns, xen_size >> PAGE_SHIFT); > + xfree(xen_colored_mfns);> + > + return xenmap; > +} > + > /* > * This function should only be called during boot and before CPU0 jump > * into the idle_loop. > @@ -209,8 +231,12 @@ void __init apply_alternatives_all(void) > * The text and inittext section are read-only. So re-map Xen to > * be able to patch the code. > */ > - xenmap = __vmap(&xen_mfn, 1U << xen_order, 1, 1, PAGE_HYPERVISOR, > - VMAP_DEFAULT); > + if ( llc_coloring_enabled ) > + xenmap = xen_remap_colored(xen_mfn, xen_size); > + else > + xenmap = __vmap(&xen_mfn, 1U << xen_order, 1, 1, PAGE_HYPERVISOR, > + VMAP_DEFAULT); > + > /* Re-mapping Xen is not expected to fail during boot. */ > BUG_ON(!xenmap); > > diff --git a/xen/arch/arm/arm64/mmu/head.S b/xen/arch/arm/arm64/mmu/head.S > index 665a51a337..a1fc9a82f1 100644 > --- a/xen/arch/arm/arm64/mmu/head.S > +++ b/xen/arch/arm/arm64/mmu/head.S > @@ -428,6 +428,61 @@ FUNC_LOCAL(fail) > b 1b > END(fail) > > +/* > + * Copy Xen to new location and switch TTBR > + * x0 ttbr > + * x1 source address > + * x2 destination address > + * x3 length > + * > + * Source and destination must be word aligned, length is rounded up > + * to a 16 byte boundary. > + * > + * MUST BE VERY CAREFUL when saving things to RAM over the copy > + */ > +ENTRY(relocate_xen) We are trying to get rid of ENTRY. Instead, please use FUNC(). > + /* > + * Copy 16 bytes at a time using: > + * x9: counter > + * x10: data > + * x11: data > + * x12: source > + * x13: destination > + */ > + mov x9, x3 > + mov x12, x1 > + mov x13, x2 > + > +1: ldp x10, x11, [x12], #16 > + stp x10, x11, [x13], #16 > + > + subs x9, x9, #16 > + bgt 1b > + > + /* > + * Flush destination from dcache using: > + * x9: counter > + * x10: step > + * x11: vaddr > + * > + * This is to ensure data is visible to the instruction cache > + */ The comments implies that the only reason we need to flush the cache is to ensure the data and cache is coherent. But... > + dsb sy > + > + mov x9, x3 > + ldr x10, =dcache_line_bytes /* x10 := step */ > + ldr x10, [x10]> + mov x11, x2 > + > +1: dc cvac, x11 ... here you use Point of Coherency. Point of Unification should be sufficient here. This is boot code, so I am not against having stricter cache maintenance. But it would be good to clarify. > + > + add x11, x11, x10 > + subs x9, x9, x10 > + bgt 1b > + > + /* No need for dsb/isb because they are alredy done in switch_ttbr_id */ > + b switch_ttbr_id > + > /* > * Switch TTBR > * > @@ -453,7 +508,8 @@ FUNC(switch_ttbr_id) > > /* > * 5) Flush I-cache > - * This should not be necessary but it is kept for safety. > + * This should not be necessary in the general case, but it's needed > + * for cache coloring because code is relocated in that case. > */ > ic iallu > isb > diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c > index 671eaadbc1..3732d5897e 100644 > --- a/xen/arch/arm/arm64/mmu/mm.c > +++ b/xen/arch/arm/arm64/mmu/mm.c > @@ -1,6 +1,7 @@ > /* SPDX-License-Identifier: GPL-2.0-only */ > > #include > +#include > #include > #include > > @@ -138,27 +139,46 @@ void update_boot_mapping(bool enable) > } > > extern void switch_ttbr_id(uint64_t ttbr); > +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len); > > typedef void (switch_ttbr_fn)(uint64_t ttbr); > +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t len); > > void __init switch_ttbr(uint64_t ttbr) Given the change below, I think this function needs to be renamed. Possibly to relocate_and_jump() with a comment explaning that the relocation only happen for cache-coloring. > { > - vaddr_t id_addr = virt_to_maddr(switch_ttbr_id); > - switch_ttbr_fn *fn = (switch_ttbr_fn *)id_addr; > + vaddr_t vaddr, id_addr; > lpae_t pte; > > + if ( llc_coloring_enabled ) > + vaddr = (vaddr_t)relocate_xen; > + else > + vaddr = (vaddr_t)switch_ttbr_id; > + > + id_addr = virt_to_maddr(vaddr); > + > /* Enable the identity mapping in the boot page tables */ > update_identity_mapping(true); > > /* Enable the identity mapping in the runtime page tables */ > - pte = pte_of_xenaddr((vaddr_t)switch_ttbr_id); > + pte = pte_of_xenaddr(vaddr); > pte.pt.table = 1; > pte.pt.xn = 0; > pte.pt.ro = 1; > write_pte(&xen_third_id[third_table_offset(id_addr)], pte); > > /* Switch TTBR */ This comment needs to be updated. > - fn(ttbr); > + if ( llc_coloring_enabled ) > + { > + relocate_xen_fn *fn = (relocate_xen_fn *)id_addr; > + > + fn(ttbr, _start, (void *)BOOT_RELOC_VIRT_START, _end - _start); > + } > + else > + { > + switch_ttbr_fn *fn = (switch_ttbr_fn *)id_addr; > + > + fn(ttbr); > + } > > /* > * Disable the identity mapping in the runtime page tables. > diff --git a/xen/arch/arm/include/asm/mmu/layout.h b/xen/arch/arm/include/asm/mmu/layout.h > index a3b546465b..19c0ec63a5 100644 > --- a/xen/arch/arm/include/asm/mmu/layout.h > +++ b/xen/arch/arm/include/asm/mmu/layout.h > @@ -30,6 +30,7 @@ > * 10M - 12M Fixmap: special-purpose 4K mapping slots > * 12M - 16M Early boot mapping of FDT > * 16M - 18M Livepatch vmap (if compiled in) > + * 16M - 24M Cache-colored Xen text, data, bss (temporary, if compiled in) > * > * 1G - 2G VMAP: ioremap and early_ioremap > * > @@ -74,6 +75,8 @@ > #define BOOT_FDT_VIRT_START (FIXMAP_VIRT_START + FIXMAP_VIRT_SIZE) > #define BOOT_FDT_VIRT_SIZE _AT(vaddr_t, MB(4)) > > +#define BOOT_RELOC_VIRT_START (BOOT_FDT_VIRT_START + BOOT_FDT_VIRT_SIZE) > +> #ifdef CONFIG_LIVEPATCH > #define LIVEPATCH_VMAP_START (BOOT_FDT_VIRT_START + BOOT_FDT_VIRT_SIZE) > #define LIVEPATCH_VMAP_SIZE _AT(vaddr_t, MB(2)) > diff --git a/xen/arch/arm/llc-coloring.c b/xen/arch/arm/llc-coloring.c > index 6c8fa6b576..8e10a505db 100644 > --- a/xen/arch/arm/llc-coloring.c > +++ b/xen/arch/arm/llc-coloring.c > @@ -10,6 +10,7 @@ > #include > > #include > +#include > #include > > /* Return the LLC way size by probing the hardware */ > @@ -64,8 +65,70 @@ unsigned int __init get_llc_way_size(void) > return line_size * num_sets; > } > > +/** > + * get_xen_paddr - get physical address to relocate Xen to > + * > + * Xen is relocated to as near to the top of RAM as possible and > + * aligned to a XEN_PADDR_ALIGN boundary. > + */ > +static paddr_t __init get_xen_paddr(paddr_t xen_size) > +{ > + const struct membanks *mem = bootinfo_get_mem(); > + paddr_t min_size, paddr = 0; > + unsigned int i; > + > + min_size = (xen_size + (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1); Style: Missing space before *and* after '-' in both cases. But effectively, this is an open-coded version of ROUNDUP(). > + > + /* Find the highest bank with enough space. */ > + for ( i = 0; i < mem->nr_banks; i++ ) > + { > + const struct membank *bank = &mem->bank[i]; > + paddr_t s, e; > + > + if ( bank->size >= min_size ) > + { > + e = consider_modules(bank->start, bank->start + bank->size, > + min_size, XEN_PADDR_ALIGN, 0); > + if ( !e ) > + continue; > + > +#ifdef CONFIG_ARM_32 > + /* Xen must be under 4GB */ > + if ( e > GB(4) ) > + e = GB(4); > + if ( e < bank->start ) > + continue; > +#endif > + > + s = e - min_size; > + > + if ( s > paddr ) > + paddr = s; > + } > + } > + > + if ( !paddr ) > + panic("Not enough memory to relocate Xen\n"); > + > + printk("Placing Xen at 0x%"PRIpaddr"-0x%"PRIpaddr"\n", > + paddr, paddr + min_size); > + > + return paddr; > +} > + [...] > +static void __init create_llc_coloring_mappings(void) > +{ > + lpae_t pte; > + unsigned int i; > + struct bootmodule *xen_bootmodule = boot_module_find_by_kind(BOOTMOD_XEN); > + mfn_t start_mfn = maddr_to_mfn(xen_bootmodule->start), mfn;> + > + for_each_xen_colored_mfn ( start_mfn, mfn, i ) > + { > + pte = mfn_to_xen_entry(mfn, MT_NORMAL); > + pte.pt.table = 1; /* level 3 mappings always have this bit set */ > + xen_xenmap[i] = pte; > + } > + > + for ( i = 0; i < XEN_NR_ENTRIES(2); i++ ) > + { > + vaddr_t va = BOOT_RELOC_VIRT_START + (i << XEN_PT_LEVEL_SHIFT(2)); > + > + pte = mfn_to_xen_entry(virt_to_mfn(xen_xenmap + > + i * XEN_PT_LPAE_ENTRIES), > + MT_NORMAL); > + pte.pt.table = 1; > + write_pte(&boot_second[second_table_offset(va)], pte); > + } > +} > + > /* > - * Boot-time pagetable setup. > + * Boot-time pagetable setup with coloring support I am a bit confused with this change. I agree you added support for cache coloring, but the code is still doing the same thing: Preparing the page-tables regardless on whether this is cache coloring or not. So I would say this update is not warrant. > * Changes here may need matching changes in head.S > + * > + * The cache coloring support consists of: > + * - Create colored mapping that conforms to Xen color selection in xen_xenmap[] > + * - Link the mapping in boot page tables using BOOT_RELOC_VIRT_START as vaddr > + * - pte_of_xenaddr() takes care of translating addresses to the new space > + * during runtime page tables creation > + * - Relocate xen and update TTBR with the new address in the colored space > + * (see switch_ttbr()) > + * - Protect the new space Similarly here. Most of what is written has nothing to do with cache coloring. So I think this comment needs to be made a bit more generic. > */ > void __init setup_pagetables(void) > { > @@ -326,6 +369,9 @@ void __init setup_pagetables(void) > lpae_t pte, *p; > int i; > > + if ( llc_coloring_enabled ) > + create_llc_coloring_mappings(); > + > arch_setup_page_tables(); > > #ifdef CONFIG_ARM_64 > @@ -353,13 +399,7 @@ void __init setup_pagetables(void) > break; > pte = pte_of_xenaddr(va); > pte.pt.table = 1; /* third level mappings always have this bit set */ > - if ( is_kernel_text(va) || is_kernel_inittext(va) ) > - { > - pte.pt.xn = 0; > - pte.pt.ro = 1; > - } > - if ( is_kernel_rodata(va) ) > - pte.pt.ro = 1; > + pte.pt.xn = 0; /* Permissions will be enforced later. Allow execution */ > xen_xenmap[i] = pte; > } > > @@ -385,13 +425,48 @@ void __init setup_pagetables(void) > ttbr = virt_to_maddr(cpu0_pgtable); > #endif > > - switch_ttbr(ttbr); > - > - xen_pt_enforce_wnx(); > - > #ifdef CONFIG_ARM_32 > per_cpu(xen_pgtable, 0) = cpu0_pgtable; > #endif > + > + if ( llc_coloring_enabled ) > + ttbr = virt_to_maddr(virt_to_reloc_virt(THIS_CPU_PGTABLE)); The logic is a bit difficult to understand. You first update ttbr above: ttbr = virt_to_maddr(cpu0_pgtable); But then overwrite it for cache coloring. virt_to_maddr() is also not a trivial function. So I think it would be better to write the following: #ifdef CONFIG_ARM_32 per_cpu(xen_pgtable, 0) = cpu0_pgtable; #endif if ( llc_coloring_enabled ) ttbr = virt_to_maddr(virt_to_reloc_virt(...)); else ttbr = virt_to_maddr(THIS_CPU_PGTABLE); > +> + switch_ttbr(ttbr); > + > + /* Protect Xen */ > + for ( i = 0; i < XEN_NR_ENTRIES(3); i++ ) > + { > + vaddr_t va = XEN_VIRT_START + (i << PAGE_SHIFT); > + lpae_t *entry = xen_xenmap + i; > + > + if ( !is_kernel(va) ) > + break; > + > + pte = read_atomic(entry); > + > + if ( is_kernel_text(va) || is_kernel_inittext(va) ) > + { > + pte.pt.xn = 0; > + pte.pt.ro = 1; > + } else if ( is_kernel_rodata(va) ) { Coding style: } else if { ... } else { ... } > + pte.pt.ro = 1; > + pte.pt.xn = 1; > + } else { > + pte.pt.xn = 1; > + pte.pt.ro = 0; > + } > + > + write_pte(entry, pte); > + } > + > + /* > + * We modified live page-tables. Ensure the TLBs are invalidated > + * before setting enforcing the WnX permissions. > + */ > + flush_xen_tlb_local(); > + > + xen_pt_enforce_wnx(); > } Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Dec 02 23:30:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 23:30:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847132.1262268 (Exim 4.92) (envelope-from ) id 1tIFs7-0005Ml-R7; Mon, 02 Dec 2024 23:30:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847132.1262268; Mon, 02 Dec 2024 23:30: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 1tIFs7-0005Mc-Nb; Mon, 02 Dec 2024 23:30:31 +0000 Received: by outflank-mailman (input) for mailman id 847132; Mon, 02 Dec 2024 23:30: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 1tIFs7-0005MA-4i for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 23:30:31 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2061b.outbound.protection.outlook.com [2a01:111:f403:2416::61b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 69b4a4de-b105-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 00:30:28 +0100 (CET) Received: from CH0P220CA0011.NAMP220.PROD.OUTLOOK.COM (2603:10b6:610:ef::13) by DS0PR12MB8503.namprd12.prod.outlook.com (2603:10b6:8:15a::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8048.22; Mon, 2 Dec 2024 23:30:22 +0000 Received: from CH1PEPF0000AD82.namprd04.prod.outlook.com (2603:10b6:610:ef:cafe::b1) by CH0P220CA0011.outlook.office365.com (2603:10b6:610:ef::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.18 via Frontend Transport; Mon, 2 Dec 2024 23:30:22 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by CH1PEPF0000AD82.mail.protection.outlook.com (10.167.244.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Mon, 2 Dec 2024 23:30:22 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 2 Dec 2024 17:30:21 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 2 Dec 2024 17:30:21 -0600 Received: from [172.25.146.163] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Mon, 2 Dec 2024 17:30:20 -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: 69b4a4de-b105-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=GyVR5KfG0GjzSUNWcQgwP2d9slNjJIMEb6GkNl+fV7jFWHF2DLLvKv8FO+zAwSrrNdWuaRhwa6u+fk98HHnv7ZwEd8aWw0utFaRklcZfqQp4c1VROwhyN5HRefyzHVotQjCMBCgxqcScO8J09N+77SRthP8a6MgRfIch0E5ICW/z6qkANKArWCJ+bzAud/xdzn8c0XnE/EyZD759iDlCcYKCFbuKZdSxhTr4OUtZknqucrKIdY6NXtvdxALsCT7e9QxXecvX8Edj4xCKN7rjWpFIpGJEGzHVOq5Y/Wrq5J5v1Y8xHkh15zYhFkmg9bp8P/bOHLSQN3Mc77Zz1uWeYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mJBWXBIbNO36o0iRQCRlSmzN18HIFarj3mI6Kpjyx18=; b=Kt6xCJF4S8HFG93IYuq7wMXuiojVD8hVC1kXVeiJeZOnYgBUkSXSfFKYMtUN9nwT8W5jptioNgju8eqq1yEq/OTtPHM832dHmqWO/pDKsCIUCmLXito1fwahaORAqfgnt81dhP6ltp6e0V8G4AFnyiH1Zs5kJO7SCEnMxAFZxSac5dP41ytxHchX2h0vi1yKylQV/WjdnOhDeNFB3CSfjJ0Q2MKVsYuW/23gAcmBCi+fCyMTb73U8HyMJoZ6X+Mk2I0At0po4sU9HU361fiPVseQhP7Tcz7vssk2s1VpVTpvzXMWgxZxvDMme8jSEoRqFZkASbgVyXeuMFErMI3NuQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=vates.tech smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mJBWXBIbNO36o0iRQCRlSmzN18HIFarj3mI6Kpjyx18=; b=EIyRzU/xZaWMFJtCXCxkLLmOoR9lWMvK793OVoumwdklL6tfxRaHEk4kNhbdkGRpmDf8Q+5d0yWIZyR8+Ce2LsADY2+EOj44BkYPLlAEmL/OoANpS0+5ggs7o6WtD10OAsERUJpsOHO/gK1+ULAy4w0dkbrmt2813xYtYuz6eoQ= 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=SATLEXMB03.amd.com; pr=C Message-ID: <108b16b7-19c1-44ee-ab49-48b5fd63d87b@amd.com> Date: Mon, 2 Dec 2024 18:30:20 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jason Andryuk Subject: Re: [PATCH v2 2/2] tools/xl: add suspend and resume subcommands To: Anthony PERARD CC: , =?UTF-8?Q?zithro_/_Cyril_R=C3=A9bert?= , Andrew Cooper , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= References: <20241126171941.170897-1-jason.andryuk@amd.com> <20241126171941.170897-3-jason.andryuk@amd.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD82:EE_|DS0PR12MB8503:EE_ X-MS-Office365-Filtering-Correlation-Id: b87a0d54-1543-46fa-ab77-08dd13294a89 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|82310400026|376014|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?NGdrTnZCYTdpcURQaUEreVViVVdOdXYrd2JBRUM4MnJMUnBNc0tRd1kvamJv?= =?utf-8?B?NTQyNWlxQlRDdjhxd1JmRkRtMVVieWtPUEVDVStVVXpwYXIrbEcvQ1pvSE9Y?= =?utf-8?B?SDQzTWQ3VXZyU0dIM3lRTnE3K3lSc01hajZXaXM1dWVrNjhrOUYxRmU1VWlC?= =?utf-8?B?SFpZTEZwUFlvMUtuS0RtL1RWSmFPWlpuQkVOcldheCtkS2VPL2VKK28vVXZ1?= =?utf-8?B?R1dUVGNNREZaRWMrcHUzaDQzUVdxL2c3K3pxaTdIaVhMcXA2bUZ6ZWd1YlFI?= =?utf-8?B?QzBnNi80YXRiNlIzbllualk5YXFwU29sUVFlaWNZRWlrL3ZUZDBsZFlUQlYr?= =?utf-8?B?eWxjS3VHR21oTkhOM3hyd1REUVMwY1RIK1cwRnVYalNLNkZJakxqS1haVElk?= =?utf-8?B?RkRSR1NnbTdzbkE4WHowaEJpZlBUQ3RZaTNrWUYrajN1eGdPc1BkWTUwME4z?= =?utf-8?B?RE5KdnFzMTBpVXdZYjgvaDdqZWVuaklYdWh5bThHT0NLeEhwbUNKTWQ1S0Jn?= =?utf-8?B?eHpTUi9oZkVreWdlT3F4V0lteVQzVytHUXlQVjJrcnR0NnNWb0wwT1hGOFIv?= =?utf-8?B?ajQ3NUIxUzR4NmRpQWNLeEFiZFJ2eUJwNUJRSnQ2aDFUVmJ3R2d4YjRaVyt5?= =?utf-8?B?Y1lhZ1JSU1NaUzA0SndkRzZFK1dGYUErUHNnRFNWTENSeHY0WXR1UmdLMlVs?= =?utf-8?B?WTlPdXgrTjFxR2d5OXNOUUtCdjFTNWE0TDVuK3Q0dGducGdEdTRDSTBZckhl?= =?utf-8?B?a1hnNGpIS3liZ0dLaFJlcStZNlJIMGY0L2FZMTNiQ1MwZDV6TlFvbnRCTHVl?= =?utf-8?B?UEpkQjNkNnYrSWxYMTBLLy8zc0h6eGtBblY1Tk5rTGFPUThWdms0cDQxR0xa?= =?utf-8?B?L25IcGM1c2Rpc2EwTXVQOXA0MTJzZVFubkl3VlVzdkd2R3o3dGRDZWtPTnQv?= =?utf-8?B?cS9wc1Nlb2RYQmQ2OVdKVGRnTWFIVVIvdHl3c1BaUFlsR0ZYRFcrYTI2Um14?= =?utf-8?B?K0ZSTUpaQUQzMzBZYUJUNEtrNnAvQWs1SU9waEtZandITlY2RndnbWJkRXBT?= =?utf-8?B?N3hXUHJLaXhwRWF2NHpTN1E1bkRqV3BaZ0tNeFhBSXh0QWlKTEY4ZjRyOGlu?= =?utf-8?B?dWluQUtoRFVvZHRmYWdvNWl2Z3FURzQrRk5FY0pNbVVhQVcwTTUyaUxyQU1M?= =?utf-8?B?aE43eGROZ2p1cGZWTXRUcEF6Z3ZiTm0vWVpsdDNSb1lJVTNXNTljVXE3UjRR?= =?utf-8?B?dUdFRVN1UVc4K3hnVmJBeWZBQ3BoWHNCOFNBSEdkNFBOd0t0OWpvVGRidzEz?= =?utf-8?B?MXNKc3kvck9XMXAvWGs4SUJRU1lTc3drUVo5NnFkM3h5RXFGR3hhcUhxSDlu?= =?utf-8?B?TEhRdXdVejBBZ2s4UFRKZWlhck1penhyUjFOMWNVbWJYTEtwVW8zWjYrU3Zv?= =?utf-8?B?cGhPSTF0Y0k0dnFLMUxkT2NEWXBCcUUxQ0hObHJBMnVwdHlGVDRGZzJiSnZU?= =?utf-8?B?YUZzWHFmTFAyNmxncVVQNVlIMGF4VDlCcVlDdTRSYXZIVTRBT3NoN0IxcTlW?= =?utf-8?B?QzBqdlV4MXNvSWVtQ09vb3J0TERzUFltTHNCTnhPTVNranJDMTFEQWcyMFQv?= =?utf-8?B?bTVtQm9lVGI3YjZLVUtOcTVuTlRNM21lMXJuRkoxc01iUFdjdW5zUDJqRzU5?= =?utf-8?B?bGszZnUxTy9DNjFqbFhsQVErTThzaElBd2RCNVFhSUladjI5MlRrR05nUDJW?= =?utf-8?B?QmUwL0xteGY5TTNocnhIamQrc05PZStSNktML2oveFZsbHVmY1hrbWxJK0Rm?= =?utf-8?B?YzdJZUVsRnhnY2FlK0I3YXJjOGVHeG5Zb2lCbEZ0eStLM1JkM1BUR1FueW5w?= =?utf-8?B?MTJmMkw0d1Zqd1Fld0FzMXNkNXRlS25IRU9KbU5nL2NRSmxoSlg5RmZ6SkZH?= =?utf-8?Q?7Ebtz+sVBupG4VcJF3eZxWWbVaRnma1m?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(376014)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Dec 2024 23:30:22.0820 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b87a0d54-1543-46fa-ab77-08dd13294a89 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=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH1PEPF0000AD82.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8503 On 2024-11-28 12:19, Anthony PERARD wrote: > On Tue, Nov 26, 2024 at 12:19:41PM -0500, Jason Andryuk wrote: >> diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c >> index c45d497c28..3160966972 100644 >> --- a/tools/xl/xl_vmcontrol.c >> +++ b/tools/xl/xl_vmcontrol.c >> @@ -42,6 +42,16 @@ static void unpause_domain(uint32_t domid) >> libxl_domain_unpause(ctx, domid, NULL); >> } >> >> +static void suspend_domain(uint32_t domid) >> +{ >> + libxl_domain_suspend_only(ctx, domid, NULL); >> +} >> + >> +static void resume_domain(uint32_t domid) >> +{ >> + libxl_domain_resume(ctx, domid, 1, NULL); >> +} >> + >> static void destroy_domain(uint32_t domid, int force) >> { >> int rc; >> @@ -82,6 +92,32 @@ int main_unpause(int argc, char **argv) >> return EXIT_SUCCESS; >> } >> >> +int main_suspend(int argc, char **argv) >> +{ >> + int opt; >> + >> + SWITCH_FOREACH_OPT(opt, "", NULL, "suspend", 1) { >> + /* No options */ >> + } >> + >> + suspend_domain(find_domain(argv[optind])); >> + >> + return EXIT_SUCCESS; >> +} >> + >> +int main_resume(int argc, char **argv) >> +{ >> + int opt; >> + >> + SWITCH_FOREACH_OPT(opt, "", NULL, "resume", 1) { >> + /* No options */ >> + } >> + >> + resume_domain(find_domain(argv[optind])); >> + >> + return EXIT_SUCCESS; >> +} > > These four new functions in xl_vmcontrol.c needs to be hidden behind > LIBXL_HAVE_NO_SUSPEND_RESUME, like the whole xl_migrate.c file is. > Both prototypes for main_*() are already hidden as well as the new > command in xl_cmdtables. > > Or alternatively, we could probably have the command been present on > Arm, but I don't know if libxl_domain_suspend_only() is going to work. > It looks like it only depends on the hypervisor. I can't find any logic > that would treat Arm differently, besides the presence of > LIBXL_HAVE_NO_SUSPEND_RESUME. > > But best bet would be to hide those four functions when > LIBXL_HAVE_NO_SUSPEND_RESUME is defined. Thanks. Yes, I'll hide them. Regards, Jason From xen-devel-bounces@lists.xenproject.org Mon Dec 02 23:30:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Dec 2024 23:30:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847131.1262258 (Exim 4.92) (envelope-from ) id 1tIFs2-00057h-Ko; Mon, 02 Dec 2024 23:30:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847131.1262258; Mon, 02 Dec 2024 23:30: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 1tIFs2-00057a-Gi; Mon, 02 Dec 2024 23:30:26 +0000 Received: by outflank-mailman (input) for mailman id 847131; Mon, 02 Dec 2024 23:30: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 1tIFs0-00057U-JT for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 23:30:24 +0000 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on20604.outbound.protection.outlook.com [2a01:111:f403:2406::604]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 65aef7bc-b105-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 00:30:22 +0100 (CET) Received: from CH0P220CA0017.NAMP220.PROD.OUTLOOK.COM (2603:10b6:610:ef::34) by SN7PR12MB8027.namprd12.prod.outlook.com (2603:10b6:806:32a::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Mon, 2 Dec 2024 23:30:17 +0000 Received: from CH1PEPF0000AD7E.namprd04.prod.outlook.com (2603:10b6:610:ef:cafe::c4) by CH0P220CA0017.outlook.office365.com (2603:10b6:610:ef::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.18 via Frontend Transport; Mon, 2 Dec 2024 23:30:17 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by CH1PEPF0000AD7E.mail.protection.outlook.com (10.167.244.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Mon, 2 Dec 2024 23:30:16 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 2 Dec 2024 17:30:16 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 2 Dec 2024 17:30:16 -0600 Received: from [172.25.146.163] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Mon, 2 Dec 2024 17:30:15 -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: 65aef7bc-b105-11ef-a0d3-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NKi/vrtKO2hxxM/BDXL0thDUAdrlWI2Bx9ujQkaZ4g9OBBQA68/btaLFfHTl4BzZoVECaPDnk49abHYnVxtxhRYOr2HvAQGD4LgXW9YluZeiN4cxv6l5t6xLROiNbpgqSQS0KDdLFBmTS359+yjYthQsFxCaaZmbZi/fmVWb78uynNJMJmJ926TYoRxM551xl3jPCKbj0Qy+OWdUmEoaV6wsDad1scxQgAasxW9DgrRwiNWRtEwN5rGv2MR9OVchvDkSLxWwdFnG2Oghx6Af1bvnMgXxYYpSgEtxIBl2qn2RpzpTueyffF0C1lgn8LXExB2YeYYnhMOu1R3xs8IQLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yr4+xPwlByZzVA0fa5bri/NPFAgZZCBLCSr7JMRSsUw=; b=Dn/6WH2FNVauIj2v/3MapWtgSwL11AyNLOSEWPD/ze5oKSPOzu2IkmP531Pwo0t3Rl3YWdZr26Kb1igA2lVJA0yWmPrsPGV2q9UfFSkKFQ1a+Y3sfLFBWr3LGW/R2dyJgMfurVmy4EWXhGfusqf8Uc0EyttIze5eq40XYJADAv0ARbkot+pkmupPHaEgsJaTIVcG6XoEa+7Xnfb4LLl0sOdfTpk9yNwLbAid10c51YB8k/3Ki8wUg0UzDQM1ki4e9oV+//rP95AQIAl84LKcHMFk85168/yLMou0DCrs3p/KNKuSUSJ0fZUtvqbIZelpIsFHpmpHUX5LoeAvcAFyYg== 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=yr4+xPwlByZzVA0fa5bri/NPFAgZZCBLCSr7JMRSsUw=; b=Ak6QMlX41qHjs4DgVTZWxCarlElRz1o9nP/d+ZI0FuNeTRhabA1Of60Y92XlZl2F/O+7JF9SGaO1SZqGYBCscNEzXm/efJWGkTJJVciCPUWUM6pDjG3mCBRdtTr7onrpWSoXBtOURhrHJxm1O6U0FUEW7K5d8zz1tmY3ZFri4BE= 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=SATLEXMB03.amd.com; pr=C Message-ID: Date: Mon, 2 Dec 2024 18:30:14 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jason Andryuk Subject: Re: [PATCH v2 1/2] xl: Keep monitoring suspended domain To: Jan Beulich , Anthony PERARD CC: References: <20241126171941.170897-1-jason.andryuk@amd.com> <20241126171941.170897-2-jason.andryuk@amd.com> <95754086-9c90-4765-b386-299baf2b5f94@suse.com> Content-Language: en-US In-Reply-To: <95754086-9c90-4765-b386-299baf2b5f94@suse.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD7E:EE_|SN7PR12MB8027:EE_ X-MS-Office365-Filtering-Correlation-Id: ca6d7622-5f95-46de-7010-08dd13294776 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|82310400026|36860700013; X-Microsoft-Antispam-Message-Info: =?utf-8?B?WTFDMEoxMklXR0FQeXdoK3c3K0IrWWdrTnRDYkk3dC9JTVEzb0NHODhtdTd6?= =?utf-8?B?cTcrVkw2REdld2NWNG9jZkNBMmhKQVhOUk1LblhSUjRqbXBEdm9xWUNhQlY2?= =?utf-8?B?TGJhbVlYMGhvUzRkOEdLL3VQVWo5TkQ5ajk4KzZ2WnNyMERTWHJxOTJ6UDlo?= =?utf-8?B?Zm9VTlZ5TjkxbzFmTEdMcXJyZzE2c2RRWnBwL0ZsNnNua1g1SndId1VrSS80?= =?utf-8?B?VzZaN0xMT1MxaG5ML2JzUzVQalo4SFpNbnR4SWp0cDBGRG9Kb2VJN2ZIcko4?= =?utf-8?B?dUdJbkdSSXhwSVhOZnE3Q0FoMmkxdHREeGNVZGlrYTJtSFp1YllLdjl3ckRG?= =?utf-8?B?UHAwdXBuQ2VES0tZRkRkbitVMk9MRzR2MTV4aW1xQmY4VXlQbXZQbU9wYVFP?= =?utf-8?B?ejdwZzVJa0tGQzZjWkJTUWgrZlY1OHcydStjMnp6SDYzZ3NkUks0RStLa3d1?= =?utf-8?B?V2FZOUYzZytBbUNSSjdKSDVmU0I2QjJqUWgxYk53UGhzRkQ3SmlORG5JUWlS?= =?utf-8?B?bDZjL0w5OVVRWGN6bmFhNFBtZ0w2NS9mTXBoSWNpVytVeW9OQ2thZXRNRVNF?= =?utf-8?B?TFNMSlYveEU5ZWV5cllXUWNONXFpemF3bEMzazhETUtZREl2WUJjTUFrUWZr?= =?utf-8?B?RndYZ1NKQjRYVGZ3blNmcmRTSG8vODRCTXNaWmt2L0RBSjJxdjh4cmVBaVhw?= =?utf-8?B?UENqNFkyb2czSnlVcU9nMVpzRDJDVTVDM1ZFRC9ma2tDV3ZaSlhlZkNtRUV0?= =?utf-8?B?VEZtSHZuSlhGQUVjTHZCSi9wT2pZTjNia2d5dDFzWDZJanI3Q0tQU214UWZh?= =?utf-8?B?YXE2Rmx2Q1FoL250dXR6QUhOUC9LNUMzU0FIRDB4alZPeGdiNWo4ZWo5dklK?= =?utf-8?B?N3NodllKWjhhWWxmNkliUk1rL1B1YktRY1JpbG90UHJnbkhGbG9ybzRRZitS?= =?utf-8?B?VXZ4clNRZkpLUEV4UjBOZ3J5Ym13djNTY1ZLNURvUTFGVXcrKzlTbS9NTWNF?= =?utf-8?B?SEtPM21LZ2RoVllXdE5QT3R1dHhnQzNTZTdCT2xmcHdSdS80NXpCYjlJc2lh?= =?utf-8?B?M2hRTG1MWHZhcnYvWXdtRE9OY1lIRHJyL01oSS9zSDNhbll0RUJsK1ZXb1JX?= =?utf-8?B?a2hJaHBGWFQvbjJWemdYbTNYcnFZakduYUo3bjhzM0RWUjNJVEN1KzV6SDUz?= =?utf-8?B?MU5lZmEyK1dwdmQ0WlhXK0xMcDhOTEk2MFZkMjJvSFovZzVCdHpCdWJTWFdP?= =?utf-8?B?K0g2azVVTG1NWU5vTHNUQnR4djgydGQ4eC9HSVJTaWoxd3pxckZUalFrdnBE?= =?utf-8?B?ZUpPa3lTVlJqN2FPZVJjbkRIenc2N1UxdmxTQ3B3V2RNbFFBaXB5NzloK3lH?= =?utf-8?B?WWpkakxzR1hXYVEyQnJLQW4xYWJMc3hmY3NMV2w0YXd6T1E1UjhlYjlYWDdG?= =?utf-8?B?VExkY0h6bG5NRUxyd0RDTURUbTNtV3E3NXBxcHF2eEkxcFU5T2ViYzhETC9k?= =?utf-8?B?L2ViMklmUEdOdFJsM0lURGxLZTNlbFpsS1VZZjFHQkRuaDJLMjEvUVJ5ZlFS?= =?utf-8?B?dGRWTUcwRmZ4aU9GVFVwcVBObXZNWmgrbzdVYk9mbG1nQko5b1RJWUR2dmxL?= =?utf-8?B?WUFCNXF5Vmswc3d0Q1lhTHdVL1F5ZkkxTWt2OWtOVHREaFRFRktpUEhDWjFT?= =?utf-8?B?R1dQOThjN2tQR3ZadjVwMjkxZVFBT0N6aDFMbEk1OUpyM1IvUmQ2K0lPa3VK?= =?utf-8?B?eHUyL0pSeHVtR1FXZEROenlLQk16bUh2amRreWNrb1B6VmV2YmN0TkE3TmQ3?= =?utf-8?B?VFVOeDdsRENLSVNEQ0I3czVMRGdoamRlZFBRWDJPM0FPNmtwcmZ1dHIxQ3RE?= =?utf-8?B?L0l6eHgxMzFpeTRTSU4ycVMrU1VtSm5BUVVQMm5NWHRBc2U4eDNaSVJOT0Qw?= =?utf-8?Q?RHmgg67/qoWo/bQYv4wQPXRx1iwNYtY4?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Dec 2024 23:30:16.8603 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ca6d7622-5f95-46de-7010-08dd13294776 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=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH1PEPF0000AD7E.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8027 On 2024-12-02 03:53, Jan Beulich wrote: > On 28.11.2024 17:45, Anthony PERARD wrote: >> On Tue, Nov 26, 2024 at 12:19:40PM -0500, Jason Andryuk wrote: >>> When a VM transitioned to LIBXL_SHUTDOWN_REASON_SUSPEND, the xl daemon >>> was exiting as 0 = DOMAIN_RESTART_NONE "No domain restart". >>> Later, when the VM actually shutdown, the missing xl daemon meant the >>> domain wasn't cleaned up properly. >>> >>> Add a new DOMAIN_RESTART_SUSPENDED to handle the case. The xl daemon >>> keeps running to react to future shutdown events. >>> >>> The domain death event needs to be re-enabled to catch subsequent >>> events. The libxl_evgen_domain_death is moved from death_list to >>> death_reported, and then it isn't found on subsequent iterations through >>> death_list. We enable the new event before disabling the old event, to >>> keep the xenstore watch active. If it is unregistered and >>> re-registered, it'll fire immediately for our suspended domain which >>> will end up continuously re-triggering. >>> >>> Signed-off-by: Jason Andryuk >> >> Reviewed-by: Anthony PERARD > > While committing I was wondering: Does this want/need backporting (and hence > was it perhaps lacking a Fixes: tag)? Thanks, Jan. I don't think it's really worth backporting. Mainly, it hasn't been an issue in the last 14 years. A Linux domU doesn't suspend itself - it only does so in response to a xenstore watch. A domU *could* suspend itself without the xenstore watch, but that doesn't seem to happen in practice. Since xl has not been able to generate those xenstore events prior to the `xl suspend` introduction, this code path hasn't run or been an issue. The tag would be: Fixes: 1a0e17891f ("xl: support on_{poweroff,reboot,crash} domain configuration options.") Regards, Jason From xen-devel-bounces@lists.xenproject.org Tue Dec 03 00:16:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 00:16:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847151.1262278 (Exim 4.92) (envelope-from ) id 1tIGai-0003Dj-F4; Tue, 03 Dec 2024 00:16:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847151.1262278; Tue, 03 Dec 2024 00:16: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 1tIGai-0003Dc-Bm; Tue, 03 Dec 2024 00:16:36 +0000 Received: by outflank-mailman (input) for mailman id 847151; Tue, 03 Dec 2024 00:16: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 1tIGai-0003DW-4M for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 00:16:36 +0000 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [2a00:1450:4864:20::62f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id da1ccb81-b10b-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 01:16:33 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-aa543c4db92so716928266b.0 for ; Mon, 02 Dec 2024 16:16:33 -0800 (PST) Received: from andrewcoop.eng.citrite.net ([90.240.255.120]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa59990a8e5sm555423666b.173.2024.12.02.16.16.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 16:16: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: da1ccb81-b10b-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1733184993; x=1733789793; 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=vayJHxmC3miwlguVJZfGiN5O+5EOjDwaWf4pKmb+Tjk=; b=khN8fAUL36gTyh2kJWutao2NnmYseI1NOvi5Q2rvpRRhw5GcGvcoEab8NpJFGJBoc/ jbdMZfCElcOYfn4AwpsL9H5tJhUyzRqQ0omd4d7k4ibp/sSsWIgfA3Wpaq+OyL+RXjYL h6WgP9Gl5dubHpZAZWsK9YlH85CFFbZmsSxTg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733184993; x=1733789793; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vayJHxmC3miwlguVJZfGiN5O+5EOjDwaWf4pKmb+Tjk=; b=QTILD3edOJwfySLPycK8Exx6GumOYPvxa2g8awgNUnp7JM/c2TcdTQ9aAraPikrQpf 3m6VqBVo9O/1bwBup8RLLF8Ils0K94P9viYjeGLqWtb7akHzs6R9rZrMzWav3+l2gTjg CwgAvu03nO3McyRVikr3wKcz8UzGYe2LwoNb/KOkN/XCygPBhnxJh7zII5YwTnPqNyhe LQYrwH6zShaoNH5FD0RuM2X8Qu6dmniSiuqkp8XJuVKusaDgsMw74OxIr4lTUbaYRWH5 rMdNtmw/RqxCFch416KfCjJon108t5I6joq6KYnFlGZEEdubUjsgHKm0Wpdyf8FzaT68 J1qQ== X-Gm-Message-State: AOJu0YyxENZ+vuLZw8Pb7jF53P/0twxwN+w6QfrSQ2uUrdnGgGwTtolL rU7+MXaWlX4ocTHofCyl9S/125ZVWwIBp5csFPIUxX86sR8lseD37eC8iOxHHO+FIMKDXQNK3Cy jl3c= X-Gm-Gg: ASbGncttt4wZ2XEqA7dUtIVbL3sfHJJV3k77kLPkEii5pfd4QJ+Iwz5SGPA76kqmFRO yod36jpEQdHy6/CAhvR0hzhkoSr+pzGnEoguk0c1CmytYfMM/xltGU9BSyGVMCULasC2ENSPVu8 N4jsDFwubO3v/G89IsJEXVOeTfkeP8JYChBh86O10BN3OkgWtyMyzuAcXgEt8iDeUjwmBG6Hk50 Xbo8x8N/Rhn3Wt9qSXVaxMtXBlFVYDG25rg7Fzuz+GgrVzJOqpY87ZDD4pOM/FU6STT4ftQaPdq Yw== X-Google-Smtp-Source: AGHT+IFiF8+vfBFdlHkHlQu8gizE6sadjFeF8npnXqLtJuQka2R0mkoQ+vGiR+KBIpRLM9CTiDQT9A== X-Received: by 2002:a17:906:3d32:b0:aa5:1dc0:7c1 with SMTP id a640c23a62f3a-aa5f7ccf566mr15938966b.9.1733184992715; Mon, 02 Dec 2024 16:16:32 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH] libs/guest: Fix migration compatibility with a security-patched Xen 4.13 Date: Tue, 3 Dec 2024 00:16:29 +0000 Message-Id: <20241203001629.132594-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 xc_cpuid_apply_policy() provides compatibility for migration of a pre-4.14 VM where no CPUID data was provided in the stream. It guesses the various max-leaf limits, based on what was true at the time of writing, but this was not correctly adapted when speculative security issues forced the advertisement of new feature bits. Of note are: * LFENCE-DISPATCH, in leaf 0x80000021.eax * BHI-CTRL, in leaf 0x7[2].edx In both cases, a VM booted on a security-patched Xen 4.13, and then migrated on to any newer version of Xen on the same or compatible hardware would have these features stripped back because Xen is still editing the cpu-policy for sanity behind the back of the toolstack. For VMs using BHI_DIS_S to mitigate Native-BHI, this resulted in a failure to restore the guests MSR_SPEC_CTRL setting: (XEN) HVM d7v0 load MSR 0x48 with value 0x401 failed (XEN) HVM7 restore: failed to load entry 20/0 rc -6 Fixes: e9b4fe263649 ("x86/cpuid: support LFENCE always serialising CPUID bit") Fixes: f3709b15fc86 ("x86/cpuid: Infrastructure for cpuid word 7:2.edx") Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné Every option here is terrible. This is the least terrible one I could come up with. XenServer, still the only caller to provide featureset into xc_cpuid_apply_policy() could in principle reverse engineer these two numbers from the non-zero-ness of the passed-in feature words. However, such an approach more complicated, equally as fragile, and not reusable with the current plans to re-integrate the shrinking logic. i.e. this is the least invasive option. --- tools/libs/guest/xg_cpuid_x86.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/tools/libs/guest/xg_cpuid_x86.c b/tools/libs/guest/xg_cpuid_x86.c index 4453178100ad..263a9d4787b6 100644 --- a/tools/libs/guest/xg_cpuid_x86.c +++ b/tools/libs/guest/xg_cpuid_x86.c @@ -640,7 +640,8 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, * * This restore path is used for incoming VMs with no CPUID data * i.e. originated on Xen 4.13 or earlier. We must invent a policy - * compatible with what Xen 4.13 would have done on the same hardware. + * compatible with what a security-patched Xen 4.13 would have done on + * the same hardware. * * Specifically: * - Clamp max leaves. @@ -657,8 +658,8 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, } p->policy.basic.max_leaf = min(p->policy.basic.max_leaf, 0xdu); - p->policy.feat.max_subleaf = 0; - p->policy.extd.max_leaf = min(p->policy.extd.max_leaf, 0x8000001c); + p->policy.feat.max_subleaf = min(p->policy.feat.max_subleaf, 0x2u); + p->policy.extd.max_leaf = min(p->policy.extd.max_leaf, 0x80000021); } if ( featureset ) base-commit: 126b0a6e537ce1d486a29e35cfeec1f222a74d11 -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 01:09:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 01:09:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847161.1262294 (Exim 4.92) (envelope-from ) id 1tIHPZ-0000XC-Ms; Tue, 03 Dec 2024 01:09:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847161.1262294; Tue, 03 Dec 2024 01:09: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 1tIHPZ-0000WL-GX; Tue, 03 Dec 2024 01:09:09 +0000 Received: by outflank-mailman (input) for mailman id 847161; Tue, 03 Dec 2024 01:00: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 1tIHGt-0004Oy-Iy for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 01:00:11 +0000 Received: from mail-io1-xd49.google.com (mail-io1-xd49.google.com [2607:f8b0:4864:20::d49]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f03b51d6-b111-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 02:00:10 +0100 (CET) Received: by mail-io1-xd49.google.com with SMTP id ca18e2360f4ac-84182041b05so500234739f.1 for ; Mon, 02 Dec 2024 17:00: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: f03b51d6-b111-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1733187607; x=1733792407; darn=lists.xenproject.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=gPDpv/chkg5p0fi43rAQfMRL2kKLevnRZ1FyVaa7akc=; b=EetRFhKLu1pky9WEgEvoYJFdk9rbiZR7ZggT9pgSmwWd39jow/KeUzDmMcy47+J/En fm1hANGMwQaKVmPM4hJaeVLwMlcwes3wIrNz3UzWkKDSO2wNJ89Rv9E3DQrCVsiB0vTY BHuLaYusBfRASvoBRgmWrd7eHzbRXxeGkMH+aS+byUiRyqCdm10bhw+DVW213QpP23nv IDQ0UQRfsSKTScZeZzVsJGsh45EKU+ThQeomVvKHjv1Rsl+UVXB6CIj+wOniUMyJVy7c MTDZMafmnBNyVDqeE2VTx1BCL8ILcnR98uebV520YLd5pkfhmTilTCOZD77xK8Igd64i Nqcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733187607; x=1733792407; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=gPDpv/chkg5p0fi43rAQfMRL2kKLevnRZ1FyVaa7akc=; b=ol7Udz1Gf0H8sHdfTtJnbwoWti0UrscfqLTWr8JgkU9C0c9y+lAGmVlQ+xO1tSbxbQ bsz4D0X3Oj0qY6yLhCq6WW6fUJB2UnKUI2Z+f6LU/E5AlpJoqbRE3ZZgdnXUBAhmRzUn mRajgm03Y5HTGZg331Om1NIOhAEoZNRFeLWjJ9/PJTyqNtmcGjciYpLq24q779dLJBLE ihOFSzytg92eQuv+ea2EfHkCNp9lT0k+hVoMBbHnrUstIO6wY8sftL1elP3NfbV+qhGw /uPR0qWE+Jgs8MjKcjuGFuBM6gI/ge+OE/5YfVrhTEKdSNHuO2UhD9GIcm2eFqdCVoeE rCmg== X-Forwarded-Encrypted: i=1; AJvYcCWiStsms9UmTj7iZTbDxItrcWjYYWpbLuEcA+9OJkkQASQ1eD4XwBkcuFvxPQat7VsQpqHZDv+H3wQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YxiIqPH8ZgnXO2QTqmAtKIpIW+QNLmuhmB3zUHkgviWafIAMWiw +VPenIC5G11c9MAwhX0isVZkLNx2B3QM9xT1XUVWoavsEReqp1YucWGexzG42k+7ckKrEyEfPac o0fc+9QPWqrSpxs4cEz4Lv/kmkXBqgA== X-Google-Smtp-Source: AGHT+IHqJwhD7dDrPHnnwi0nKSyWpAXx88t8MplXy6qAA9f67EUD1JW80naumNLzsou5U5ZEc/gbCz70e8AwEIt7ij7T X-Received: from ioay19.prod.google.com ([2002:a6b:c413:0:b0:841:802b:8e24]) (user=kevinloughlin job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6602:1546:b0:82a:2a67:9429 with SMTP id ca18e2360f4ac-8445b554fbbmr110164539f.5.1733187606796; Mon, 02 Dec 2024 17:00:06 -0800 (PST) Date: Tue, 3 Dec 2024 00:59:19 +0000 Mime-Version: 1.0 X-Mailer: git-send-email 2.47.0.338.g60cca15819-goog Message-ID: <20241203005921.1119116-1-kevinloughlin@google.com> Subject: [RFC PATCH 0/2] KVM: SEV: Prefer WBNOINVD over WBINVD for cache maintenance efficiency From: Kevin Loughlin To: linux-kernel@vger.kernel.org Cc: seanjc@google.com, pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, kvm@vger.kernel.org, thomas.lendacky@amd.com, pgonda@google.com, sidtelang@google.com, mizhang@google.com, virtualization@lists.linux.dev, xen-devel@lists.xenproject.org, bcm-kernel-feedback-list@broadcom.com, Kevin Loughlin Content-Type: text/plain; charset="UTF-8" AMD CPUs currently execute WBINVD in the host when unregistering SEV guest memory or when deactivating SEV guests. Such cache maintenance is performed to prevent data corruption, wherein the encrypted (C=1) version of a dirty cache line might otherwise only be written back after the memory is written in a different context (ex: C=0), yielding corruption. However, WBINVD is performance-costly, especially because it invalidates processor caches. Strictly-speaking, unless the SEV ASID is being recycled (meaning all existing cache lines with the recycled ASID must be flushed), the cache invalidation triggered by WBINVD is unnecessary; only the writeback is needed to prevent data corruption in remaining scenarios. To improve performance in these scenarios, use WBNOINVD when available instead of WBINVD. WBNOINVD still writes back all dirty lines (preventing host data corruption by SEV guests) but does *not* invalidate processor caches. First, provide helper functions to use WBINVD similar to how WBINVD is invoked. Second, check for WBNOINVD support and execute WBNOINVD if possible in lieu of WBINVD to avoid cache invalidations Kevin Loughlin (2): x86, lib, xenpv: Add WBNOINVD helper functions KVM: SEV: Prefer WBNOINVD over WBINVD for cache maintenance efficiency arch/x86/include/asm/paravirt.h | 7 ++++++ arch/x86/include/asm/paravirt_types.h | 1 + arch/x86/include/asm/smp.h | 7 ++++++ arch/x86/include/asm/special_insns.h | 12 ++++++++- arch/x86/kernel/paravirt.c | 6 +++++ arch/x86/kvm/svm/sev.c | 35 +++++++++++++++++---------- arch/x86/lib/cache-smp.c | 12 +++++++++ arch/x86/xen/enlighten_pv.c | 1 + 8 files changed, 67 insertions(+), 14 deletions(-) -- 2.47.0.338.g60cca15819-goog From xen-devel-bounces@lists.xenproject.org Tue Dec 03 01:09:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 01:09:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847163.1262300 (Exim 4.92) (envelope-from ) id 1tIHPZ-0000dO-WC; Tue, 03 Dec 2024 01:09:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847163.1262300; Tue, 03 Dec 2024 01:09: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 1tIHPZ-0000cb-QG; Tue, 03 Dec 2024 01:09:09 +0000 Received: by outflank-mailman (input) for mailman id 847163; Tue, 03 Dec 2024 01:00: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 1tIHHD-0004Oy-5G for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 01:00:31 +0000 Received: from mail-io1-xd4a.google.com (mail-io1-xd4a.google.com [2607:f8b0:4864:20::d4a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fd7b6d15-b111-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 02:00:30 +0100 (CET) Received: by mail-io1-xd4a.google.com with SMTP id ca18e2360f4ac-84181aad98aso517753739f.0 for ; Mon, 02 Dec 2024 17:00: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: fd7b6d15-b111-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1733187629; x=1733792429; darn=lists.xenproject.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=HXZpw0j64Kx8pQRMw/cVhgPa64V3XlxKoRy53BFPQ2Y=; b=dYfBRqIC0SuFrs+EPrdxIKKbBydHZMZGxayarUNAHSbr48upFSmbr3PQqROgEUNuaX N2xm+AhreBsc2/UC7cm2aro53oRYUbDcpN1XBw4FD29rjfo+ju711p0Lubj0E/L0+rh8 zSj5z5+mcp4CCdfLCBPczGT0KQ4NUOUqxuzZ1/Xdrz3ecplPfYOLvLKdvXI6LXkzKpSO AkAGU9OMeMVQbTf1BbT+2aYvAXbwc+j+DD3nekk1lhrokOHEQ4hsTZOqX2zVrdfzvA58 pUDmgFh5qwxsnafoXjG3tn95VZC1AKeL3JEw1fFpIVcLP+SLgX4GO65wnEnHmzB/1Q+e 7WwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733187629; x=1733792429; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HXZpw0j64Kx8pQRMw/cVhgPa64V3XlxKoRy53BFPQ2Y=; b=i373KBaECP1DN1FvWVS+ZZRLxX5FbD5iLS9iUilSjnp87lkLQQ05fyOu+MpxUL60c4 sTvduld4sPGXvtm0GeXJos959v1N3R3q4DwVwmRbAw8aAKCpsqsJZVS+JCuWjzPjmj7P ryBJMEt3Z2jzZr/sjvERWz6nVXlNXIEch6FkZ/RPKtDfU+etT6EupJFDpQra+BpV4X7W 5yr0epJkjggdAamOy10Vmg46EvmSSAQ+DOESC1u8HDWxY0Awr3rzlhWrI0GdCb9zEYwI eFxO2ExD6+k9gAIJ/aODuNsbai2Y4z1MX6yQdip+wPreDTMtaoNnRo9dRbsa3ZRNCtEN M+dA== X-Forwarded-Encrypted: i=1; AJvYcCXueygk8yJbYIv7dyqsGFUN6PPugVwy3HD3n4XyrQOc5c9vLX7HmGgtua5/XiJdjNauHq0tRTi/CIU=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx9YM8QG1hnUE80O2i+Kv/UkfJcQyldz92LIUweIgQnTVKl/cqV yuybRmGqDRu6yOegVVwrq75uVrSV/jm317N2km7B9N/M6tVLUnWy8hxOAVhUA/Wg6jFGNuSRgDA ds5bBGYChoIn+dIeQrX5ndz/I/eka9g== X-Google-Smtp-Source: AGHT+IEZmspYrC4umegddmCrbePNuN6PHswfr1n3f4QWHFbbvkBj0Jxf86Z77+97glx5zKlFrBkgAIn3Vka01mS0VDUG X-Received: from iotr20.prod.google.com ([2002:a05:6602:2354:b0:841:8ee4:fc23]) (user=kevinloughlin job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6602:6422:b0:83a:db84:41a8 with SMTP id ca18e2360f4ac-8445b5ccdddmr90500239f.10.1733187629246; Mon, 02 Dec 2024 17:00:29 -0800 (PST) Date: Tue, 3 Dec 2024 00:59:21 +0000 In-Reply-To: <20241203005921.1119116-1-kevinloughlin@google.com> Mime-Version: 1.0 References: <20241203005921.1119116-1-kevinloughlin@google.com> X-Mailer: git-send-email 2.47.0.338.g60cca15819-goog Message-ID: <20241203005921.1119116-3-kevinloughlin@google.com> Subject: [RFC PATCH 2/2] KVM: SEV: Prefer WBNOINVD over WBINVD for cache maintenance efficiency From: Kevin Loughlin To: linux-kernel@vger.kernel.org Cc: seanjc@google.com, pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, kvm@vger.kernel.org, thomas.lendacky@amd.com, pgonda@google.com, sidtelang@google.com, mizhang@google.com, virtualization@lists.linux.dev, xen-devel@lists.xenproject.org, bcm-kernel-feedback-list@broadcom.com, Kevin Loughlin Content-Type: text/plain; charset="UTF-8" AMD CPUs currently execute WBINVD in the host when unregistering SEV guest memory or when deactivating SEV guests. Such cache maintenance is performed to prevent data corruption, wherein the encrypted (C=1) version of a dirty cache line might otherwise only be written back after the memory is written in a different context (ex: C=0), yielding corruption. However, WBINVD is performance-costly, especially because it invalidates processor caches. Strictly-speaking, unless the SEV ASID is being recycled (meaning all existing cache lines with the recycled ASID must be flushed), the cache invalidation triggered by WBINVD is unnecessary; only the writeback is needed to prevent data corruption in remaining scenarios. To improve performance in these scenarios, use WBNOINVD when available instead of WBINVD. WBNOINVD still writes back all dirty lines (preventing host data corruption by SEV guests) but does *not* invalidate processor caches. Signed-off-by: Kevin Loughlin --- arch/x86/kvm/svm/sev.c | 35 ++++++++++++++++++++++------------- 1 file changed, 22 insertions(+), 13 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 943bd074a5d3..dbe40f728c4b 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -116,6 +116,7 @@ static int sev_flush_asids(unsigned int min_asid, unsigned int max_asid) */ down_write(&sev_deactivate_lock); + /* SNP firmware expects WBINVD before SNP_DF_FLUSH, so do *not* use WBNOINVD */ wbinvd_on_all_cpus(); if (sev_snp_enabled) @@ -710,6 +711,14 @@ static void sev_clflush_pages(struct page *pages[], unsigned long npages) } } +static void sev_wb_on_all_cpus(void) +{ + if (boot_cpu_has(X86_FEATURE_WBNOINVD)) + wbnoinvd_on_all_cpus(); + else + wbinvd_on_all_cpus(); +} + static unsigned long get_num_contig_pages(unsigned long idx, struct page **inpages, unsigned long npages) { @@ -2774,11 +2783,11 @@ int sev_mem_enc_unregister_region(struct kvm *kvm, } /* - * Ensure that all guest tagged cache entries are flushed before - * releasing the pages back to the system for use. CLFLUSH will - * not do this, so issue a WBINVD. + * Ensure that all dirty guest tagged cache entries are written back + * before releasing the pages back to the system for use. CLFLUSH will + * not do this without SME_COHERENT, so issue a WB[NO]INVD. */ - wbinvd_on_all_cpus(); + sev_wb_on_all_cpus(); __unregister_enc_region_locked(kvm, region); @@ -2900,11 +2909,11 @@ void sev_vm_destroy(struct kvm *kvm) } /* - * Ensure that all guest tagged cache entries are flushed before - * releasing the pages back to the system for use. CLFLUSH will - * not do this, so issue a WBINVD. + * Ensure that all dirty guest tagged cache entries are written back + * before releasing the pages back to the system for use. CLFLUSH will + * not do this without SME_COHERENT, so issue a WB[NO]INVD. */ - wbinvd_on_all_cpus(); + sev_wb_on_all_cpus(); /* * if userspace was terminated before unregistering the memory regions @@ -3130,12 +3139,12 @@ static void sev_flush_encrypted_page(struct kvm_vcpu *vcpu, void *va) * by leaving stale encrypted data in the cache. */ if (WARN_ON_ONCE(wrmsrl_safe(MSR_AMD64_VM_PAGE_FLUSH, addr | asid))) - goto do_wbinvd; + goto do_wb_on_all_cpus; return; -do_wbinvd: - wbinvd_on_all_cpus(); +do_wb_on_all_cpus: + sev_wb_on_all_cpus(); } void sev_guest_memory_reclaimed(struct kvm *kvm) @@ -3149,7 +3158,7 @@ void sev_guest_memory_reclaimed(struct kvm *kvm) if (!sev_guest(kvm) || sev_snp_guest(kvm)) return; - wbinvd_on_all_cpus(); + sev_wb_on_all_cpus(); } void sev_free_vcpu(struct kvm_vcpu *vcpu) @@ -3858,7 +3867,7 @@ static int __sev_snp_update_protected_guest_state(struct kvm_vcpu *vcpu) * guest-mapped page rather than the initial one allocated * by KVM in svm->sev_es.vmsa. In theory, svm->sev_es.vmsa * could be free'd and cleaned up here, but that involves - * cleanups like wbinvd_on_all_cpus() which would ideally + * cleanups like sev_wb_on_all_cpus() which would ideally * be handled during teardown rather than guest boot. * Deferring that also allows the existing logic for SEV-ES * VMSAs to be re-used with minimal SNP-specific changes. -- 2.47.0.338.g60cca15819-goog From xen-devel-bounces@lists.xenproject.org Tue Dec 03 01:09:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 01:09:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847165.1262304 (Exim 4.92) (envelope-from ) id 1tIHPa-0000ku-7S; Tue, 03 Dec 2024 01:09:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847165.1262304; Tue, 03 Dec 2024 01:09:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIHPa-0000iH-2u; Tue, 03 Dec 2024 01:09:10 +0000 Received: by outflank-mailman (input) for mailman id 847165; Tue, 03 Dec 2024 01: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 1tIHHJ-0004Oy-Ft for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 01:00:37 +0000 Received: from mail-oa1-x4a.google.com (mail-oa1-x4a.google.com [2001:4860:4864:20::4a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 01407258-b112-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 02:00:36 +0100 (CET) Received: by mail-oa1-x4a.google.com with SMTP id 586e51a60fabf-29e422f0433so1842407fac.3 for ; Mon, 02 Dec 2024 17:00: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: 01407258-b112-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1733187635; x=1733792435; darn=lists.xenproject.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=d+a3eBnHKvD8AQod1gMB/LKTW1oN3to08D39Docv/eQ=; b=MAnPcCO5k7gMSM7zwVCsDFPTcrgDAHrL5jkMdpwuabPU6UeObqFqWAz2/fgtBHGkWt BgP3FkwM9i62CV4aR6a3Jy15/NdWpa6YBRg9EkaBfA0M3tVxjnchZnm9gyEoaHiRnGY2 fEgXVNkruswC2eZeD6HuYZXHVILA8T6vuPVzsdbnOI6dQDeWY90q8IHyhth/gFQXo/l9 oTRfkz6UqO/6wsMmnrRTxgs0xfIpqhSzsV/AhLdjwXBRmhusxV0jTqhpSexYsjDwVHNY /iDWb/ucSCz5/y1vKPmoq9oF6ucWxoxUIznfMxgCz6T4BpPIe0Ntmw1P62g51eftYa1c +tSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733187635; x=1733792435; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=d+a3eBnHKvD8AQod1gMB/LKTW1oN3to08D39Docv/eQ=; b=uGvH6wv2ICY+RrF7hZSmIfbkwX5rDVk/z9bIJeGeqqC59ogMromlMsprDMX9MayrfM 5hxbZbDCLj14QNyKty0UYdaqL5abveDxiMB+sAUSWEaUxGw9NBbRb0soC4b0tcAzUnWe 1jLE/hE/roQmAZg+m9DetBDg/jNtqRjWQHRmAlWAYEUO8bknbKCYFV/noTz6Ps3P86x5 9Xq9iff3tZc18FZNBdDpI4/GbGVLXknqASOZN/LOiEdApPUjFkWDIqkdwVXntKxBQLlY Yrk4VrcCsDgAMSX7Vgod0odD8m2YDgOUppb0cLXwubwqMhAAePEMfgLp7XIRDQa09u0y EluA== X-Forwarded-Encrypted: i=1; AJvYcCVJVkbBTkK7PfybxCDRB1Vovf7u5h2EmlRQic7/ywcefHfh1nfCxhXgR/bapS5LnwGVP/1dwR16JHc=@lists.xenproject.org X-Gm-Message-State: AOJu0YxneZbyNEZVy/16SMidNwKHDFboBydXU9GudeoRP8/KBHxalRG/ t/p9IGvJKwv9t81fV5Te09xrlC5Whmi49UrT+mlTIGgWnVBsfKe4Qq53kdbru98uj8Z46Rx4Jga rnR+SXlLRFnnTLsTr5bx2yq5A8RBTKA== X-Google-Smtp-Source: AGHT+IHlAWUl/6xhfzZLqge5+mtkzOWOXTSZQKntjfye63eE/1sMNIDsJdEGUh7DCOLnVMK90ja1kBMWTjMKXb6+Bxua X-Received: from ioay19.prod.google.com ([2002:a6b:c413:0:b0:841:802b:8e24]) (user=kevinloughlin job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6602:2b85:b0:83a:872f:4b98 with SMTP id ca18e2360f4ac-8445b53e7d6mr104251439f.2.1733187625111; Mon, 02 Dec 2024 17:00:25 -0800 (PST) Date: Tue, 3 Dec 2024 00:59:20 +0000 In-Reply-To: <20241203005921.1119116-1-kevinloughlin@google.com> Mime-Version: 1.0 References: <20241203005921.1119116-1-kevinloughlin@google.com> X-Mailer: git-send-email 2.47.0.338.g60cca15819-goog Message-ID: <20241203005921.1119116-2-kevinloughlin@google.com> Subject: [RFC PATCH 1/2] x86, lib, xenpv: Add WBNOINVD helper functions From: Kevin Loughlin To: linux-kernel@vger.kernel.org Cc: seanjc@google.com, pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, kvm@vger.kernel.org, thomas.lendacky@amd.com, pgonda@google.com, sidtelang@google.com, mizhang@google.com, virtualization@lists.linux.dev, xen-devel@lists.xenproject.org, bcm-kernel-feedback-list@broadcom.com, Kevin Loughlin Content-Type: text/plain; charset="UTF-8" In line with WBINVD usage, add WBONINVD helper functions, accounting for kernels built with and without CONFIG_PARAVIRT_XXL. Signed-off-by: Kevin Loughlin --- arch/x86/include/asm/paravirt.h | 7 +++++++ arch/x86/include/asm/paravirt_types.h | 1 + arch/x86/include/asm/smp.h | 7 +++++++ arch/x86/include/asm/special_insns.h | 12 +++++++++++- arch/x86/kernel/paravirt.c | 6 ++++++ arch/x86/lib/cache-smp.c | 12 ++++++++++++ arch/x86/xen/enlighten_pv.c | 1 + 7 files changed, 45 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index d4eb9e1d61b8..c040af2d8eff 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -187,6 +187,13 @@ static __always_inline void wbinvd(void) PVOP_ALT_VCALL0(cpu.wbinvd, "wbinvd", ALT_NOT_XEN); } +extern noinstr void pv_native_wbnoinvd(void); + +static __always_inline void wbnoinvd(void) +{ + PVOP_ALT_VCALL0(cpu.wbnoinvd, "wbnoinvd", ALT_NOT_XEN); +} + static inline u64 paravirt_read_msr(unsigned msr) { return PVOP_CALL1(u64, cpu.read_msr, msr); diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 8d4fbe1be489..9a3f38ad1958 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -87,6 +87,7 @@ struct pv_cpu_ops { #endif void (*wbinvd)(void); + void (*wbnoinvd)(void); /* cpuid emulation, mostly so that caps bits can be disabled */ void (*cpuid)(unsigned int *eax, unsigned int *ebx, diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h index ca073f40698f..ecf93a243b83 100644 --- a/arch/x86/include/asm/smp.h +++ b/arch/x86/include/asm/smp.h @@ -112,6 +112,7 @@ void native_play_dead(void); void play_dead_common(void); void wbinvd_on_cpu(int cpu); int wbinvd_on_all_cpus(void); +int wbnoinvd_on_all_cpus(void); void smp_kick_mwait_play_dead(void); @@ -160,6 +161,12 @@ static inline int wbinvd_on_all_cpus(void) return 0; } +static inline int wbnoinvd_on_all_cpus(void) +{ + wbnoinvd(); + return 0; +} + static inline struct cpumask *cpu_llc_shared_mask(int cpu) { return (struct cpumask *)cpumask_of(0); diff --git a/arch/x86/include/asm/special_insns.h b/arch/x86/include/asm/special_insns.h index aec6e2d3aa1d..c2d16ddcd79b 100644 --- a/arch/x86/include/asm/special_insns.h +++ b/arch/x86/include/asm/special_insns.h @@ -117,7 +117,12 @@ static inline void wrpkru(u32 pkru) static __always_inline void native_wbinvd(void) { - asm volatile("wbinvd": : :"memory"); + asm volatile("wbinvd" : : : "memory"); +} + +static __always_inline void native_wbnoinvd(void) +{ + asm volatile("wbnoinvd" : : : "memory"); } static inline unsigned long __read_cr4(void) @@ -173,6 +178,11 @@ static __always_inline void wbinvd(void) native_wbinvd(); } +static __always_inline void wbnoinvd(void) +{ + native_wbnoinvd(); +} + #endif /* CONFIG_PARAVIRT_XXL */ static __always_inline void clflush(volatile void *__p) diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c index fec381533555..a66b708d8a1e 100644 --- a/arch/x86/kernel/paravirt.c +++ b/arch/x86/kernel/paravirt.c @@ -121,6 +121,11 @@ noinstr void pv_native_wbinvd(void) native_wbinvd(); } +noinstr void pv_native_wbnoinvd(void) +{ + native_wbnoinvd(); +} + static noinstr void pv_native_safe_halt(void) { native_safe_halt(); @@ -149,6 +154,7 @@ struct paravirt_patch_template pv_ops = { .cpu.write_cr0 = native_write_cr0, .cpu.write_cr4 = native_write_cr4, .cpu.wbinvd = pv_native_wbinvd, + .cpu.wbnoinvd = pv_native_wbnoinvd, .cpu.read_msr = native_read_msr, .cpu.write_msr = native_write_msr, .cpu.read_msr_safe = native_read_msr_safe, diff --git a/arch/x86/lib/cache-smp.c b/arch/x86/lib/cache-smp.c index 7af743bd3b13..7ac5cca53031 100644 --- a/arch/x86/lib/cache-smp.c +++ b/arch/x86/lib/cache-smp.c @@ -20,3 +20,15 @@ int wbinvd_on_all_cpus(void) return 0; } EXPORT_SYMBOL(wbinvd_on_all_cpus); + +static void __wbnoinvd(void *dummy) +{ + wbnoinvd(); +} + +int wbnoinvd_on_all_cpus(void) +{ + on_each_cpu(__wbnoinvd, NULL, 1); + return 0; +} +EXPORT_SYMBOL(wbnoinvd_on_all_cpus); diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index d6818c6cafda..a5c76a6f8976 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -1162,6 +1162,7 @@ static const typeof(pv_ops) xen_cpu_ops __initconst = { .write_cr4 = xen_write_cr4, .wbinvd = pv_native_wbinvd, + .wbnoinvd = pv_native_wbnoinvd, .read_msr = xen_read_msr, .write_msr = xen_write_msr, -- 2.47.0.338.g60cca15819-goog From xen-devel-bounces@lists.xenproject.org Tue Dec 03 01:09:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 01:09:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847115.1262288 (Exim 4.92) (envelope-from ) id 1tIHPZ-0000UA-DB; Tue, 03 Dec 2024 01:09:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847115.1262288; Tue, 03 Dec 2024 01:09: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 1tIHPZ-0000U3-9b; Tue, 03 Dec 2024 01:09:09 +0000 Received: by outflank-mailman (input) for mailman id 847115; Mon, 02 Dec 2024 21:17: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 1tIDn2-0005Ky-72 for xen-devel@lists.xenproject.org; Mon, 02 Dec 2024 21:17:08 +0000 Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [2607:f8b0:4864:20::102b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c7ddd56d-b0f2-11ef-a0d3-8be0dac302b0; Mon, 02 Dec 2024 22:17:06 +0100 (CET) Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-2ee786b3277so1966855a91.1 for ; Mon, 02 Dec 2024 13:17: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: c7ddd56d-b0f2-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733174225; x=1733779025; 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=FZHtDSci4mxW9uObrOpyGXF4tVtVRk+OAevn+2+RUUc=; b=irXez6Hhcq3PUsFFmw9oUtx/fqzYNG1iWCVXZt7DX/0GoKVcyDJ9qxh6wvgrZEvMaG UeTZmDv4CPDP1BaewBDjir0aACXZlzWfk2MHfy5JqyJ1aA8w59wN4nsTW0cW+iZeSck0 ny+8VOR0Mw1vpD28RJKLpyQzc5FMlnyOnfZ8xuiNjOJwxgaLiChFB+K33n2B9HPycOew dLEoS6r3yPPZZmJQHld8tt1/tilsoVwJ6pSTXdnPZJkLB+mhAHrGL38+xat4Ijz8bcPC ncWbFc+dyzyMdUvHdue9TlRJkAT2wo1iXa3q1E/Kb4wildxySe4R0E0WCHHcDVX7ElEL ie0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733174225; x=1733779025; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FZHtDSci4mxW9uObrOpyGXF4tVtVRk+OAevn+2+RUUc=; b=HJVfXfkQlSRzQxyoXSG6FvIKNvLF+I5xbLVWUyJrnk8e5k2Egg/O6EQJPCNAKboRA/ LMk56VXucbI3Spe3x2Cpzqvwo6HEcTE7fAeFiKIcSxpn9cCs73JRHC2NdA2GV8ERaJkC 561+pfMJLORRQt/IHo9In7n2patINbo8DUodyAVIPFqceYYN/+pfGdZsU8MUt3dTpa7K j5lYEWbiCxhKBQlQAPxI7pRmLzkh3kMX8fShm4YzZSfLidzLt3a2asCEpyvTCPUjSRH9 cuLg1atQ8GU3FshhgOSsXnb3/IXg8hFawbssx4qEKBpT2GJVR1B4e2Bf8j8XPp82U8By HmDA== X-Forwarded-Encrypted: i=1; AJvYcCUpyGStZGWb2KANvfgjaDIhZIkNbbhA3DMnq6J7XG5dX4SqT1KsHZVXe/AphJCB1YZJS2ihAZfj65Y=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx6uJTpnynMaW6/9e2oFkND21micrRNGFVfFdsmkHM4H6iQ4BzH dhb4g1H1du6j81QSMMXP2SzC4t8ols82gXdOXJBw9KPdI9w64hGygqvqH7nDloX/yWgWY3D6Xhj MkOBgrrtt7Hokqu2Xpk+GMYaOQfI= X-Gm-Gg: ASbGncvCS/hRcbvbMqABWyHohj1UDZQAguawq4E/01ZODmk9KaGQ3UrtOBKNYlkLQA+ b/dvU+/3PyfXcEmOu6IvlVrqPEgKFjg== X-Google-Smtp-Source: AGHT+IFDh1yb6d6zM40EzPJelJu2iVMH0WClLwmjysRWgfnYNSB8awfS5UuhO/EqqMc0eH1dffTLKgwFM99xaAmy4L8= X-Received: by 2002:a17:90b:1c09:b0:2ee:3cc1:793a with SMTP id 98e67ed59e1d1-2ef0124c720mr32029a91.29.1733174224966; Mon, 02 Dec 2024 13:17:04 -0800 (PST) MIME-Version: 1.0 References: <20241115-converge-secs-to-jiffies-v2-0-911fb7595e79@linux.microsoft.com> <20241115-converge-secs-to-jiffies-v2-9-911fb7595e79@linux.microsoft.com> In-Reply-To: <20241115-converge-secs-to-jiffies-v2-9-911fb7595e79@linux.microsoft.com> From: Christian Gmeiner Date: Mon, 2 Dec 2024 22:16:53 +0100 Message-ID: Subject: Re: [PATCH v2 09/21] drm/etnaviv: Convert timeouts to secs_to_jiffies() To: Easwar Hariharan Cc: Pablo Neira Ayuso , Jozsef Kadlecsik , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Julia Lawall , Nicolas Palix , Daniel Mack , Haojian Zhuang , Robert Jarzmik , Russell King , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Ofir Bitton , Oded Gabbay , Lucas De Marchi , =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= , Rodrigo Vivi , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Jeroen de Borst , Praveen Kaligineedi , Shailend Chand , Andrew Lunn , James Smart , Dick Kennedy , "James E.J. Bottomley" , "Martin K. Petersen" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jens Axboe , Kalle Valo , Jeff Johnson , Catalin Marinas , Andrew Morton , Jack Wang , Marcel Holtmann , Johan Hedberg , Luiz Augusto von Dentz , Greg Kroah-Hartman , Florian Fainelli , Ray Jui , Scott Branden , Broadcom internal kernel review list , Xiubo Li , Ilya Dryomov , Josh Poimboeuf , Jiri Kosina , Miroslav Benes , Petr Mladek , Joe Lawrence , Jaroslav Kysela , Takashi Iwai , Lucas Stach , Russell King , Louis Peens , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Naveen N Rao , Madhavan Srinivasan , netfilter-devel@vger.kernel.org, coreteam@netfilter.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, ath11k@lists.infradead.org, linux-mm@kvack.org, linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, live-patching@vger.kernel.org, linux-sound@vger.kernel.org, etnaviv@lists.freedesktop.org, oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, Anna-Maria Behnsen Content-Type: text/plain; charset="UTF-8" > > Changes made with the following Coccinelle rules: > > @@ constant C; @@ > > - msecs_to_jiffies(C * 1000) > + secs_to_jiffies(C) > > @@ constant C; @@ > > - msecs_to_jiffies(C * MSEC_PER_SEC) > + secs_to_jiffies(C) > > Signed-off-by: Easwar Hariharan Reviewed-by: Christian Gmeiner > --- > drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c > index 721d633aece9d4c81f0019e4c55884f26ee61c60..0f5a2c885d0ab7029c7248e15d6ea3c31823b782 100644 > --- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c > +++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c > @@ -100,7 +100,7 @@ int etnaviv_cmdbuf_init(struct etnaviv_cmdbuf_suballoc *suballoc, > mutex_unlock(&suballoc->lock); > ret = wait_event_interruptible_timeout(suballoc->free_event, > suballoc->free_space, > - msecs_to_jiffies(10 * 1000)); > + secs_to_jiffies(10)); > if (!ret) { > dev_err(suballoc->dev, > "Timeout waiting for cmdbuf space\n"); > > -- > 2.34.1 > -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info/privacypolicy From xen-devel-bounces@lists.xenproject.org Tue Dec 03 01:29:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 01:29:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847209.1262328 (Exim 4.92) (envelope-from ) id 1tIHil-0005Vl-Vz; Tue, 03 Dec 2024 01:28:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847209.1262328; Tue, 03 Dec 2024 01: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 1tIHil-0005Ve-Su; Tue, 03 Dec 2024 01:28:59 +0000 Received: by outflank-mailman (input) for mailman id 847209; Tue, 03 Dec 2024 01:28: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 1tIHik-0005VI-KA for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 01:28:58 +0000 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [2a00:1450:4864:20::62c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f6440de8-b115-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 02:28:55 +0100 (CET) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-aa53ebdf3caso157110966b.2 for ; Mon, 02 Dec 2024 17:28:56 -0800 (PST) Received: from [192.168.86.29] ([90.240.255.120]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5997d560asm563452966b.61.2024.12.02.17.28.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Dec 2024 17:28: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: f6440de8-b115-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1733189336; x=1733794136; 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=uq0J8rWPM2r7OFPHUCmfWJUZ2yRsTZhEnzsRvPF/O2A=; b=CLEtTSjzOPjz6yxJxXWqNBWAJSIh8SJBuHnOaDvDefkB9Rj7Hb7uX80a4brcFpwTKg C0S48jOeWycMgiMuLDb67XoeYmCYsk4QJCCKEHwfgvXWZTxlu79Q8UZAXXtE9ywFqSuH +XHLuLZxcKy+cWHQfbhAgHXaB8G/dKhlUKy5o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733189336; x=1733794136; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uq0J8rWPM2r7OFPHUCmfWJUZ2yRsTZhEnzsRvPF/O2A=; b=FiVApbpdNHHLJnHs9rKDISVfF+4V/BG41D6Bxh8IiMJqhgTiaSd9fiR069RbEZrNNF qiIld7o0yFQ90b8Rm09pcNrJI7gBfDa802xB2Rx8i1tPWFRz53d3wOarS7HOHC6T3T30 lt12oJyzdsTYEi7sJR47EGu4oYIup0e+rKxeMyQvj+AN6e1NjfnU5xAbgRK1MD+gy8Gw U+P25IaKNvl91c+1bl89ACWJ7NdRabSKHlb3qAyvkGq2409931JbCmTIUc4RBekGzD0P jRABDyvk851TBVkdsN5pRRIz/DYhoRjkTdtWRcwpp3eUCIJVxRoPj36hduXld3QFcVEh TgzQ== X-Forwarded-Encrypted: i=1; AJvYcCUBSgJ1sQNo6fwN4Y/tq3esO/ZrUZywo4XCI1TMhQK8rXUi1rAXCPj8p+JF8a/hM84AaE6AQOisIbo=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx6mHuWKlzCisUMrykQxIgaoLSkRvPJD3kVdV6Ndw+D2QNceuc9 D6ogdatvfQ7SAZ4gxYhkpoLazYxCH3hBp4EKeYLG6nXP1sG0vNb+QdtaqF2PNtk= X-Gm-Gg: ASbGncvJU95Bdd46c19ctOrasfHYg0DJS6yIwDpptlgmJxMNlgaJ4XgP5LgX2zo8/co 5JyjfSzv0kibn9fOGVA+/7N6Ro3gEgA1c48GpFK44nKmYgm+JT58ciDiD3beDSKFSGsvXnjYZuu uPBJjYTnmL5MKt0nWYSfSTSNEDiLB+/al402hTPbH2JmzX+8E5iOzHuYdfBA6o1Zpm4PL/gMpip uzd/b4nMn0Q5If8XPuRrgxYcGPZERhI4BiGwYYpzVcDC/RJzguU5W3O3WDME0w= X-Google-Smtp-Source: AGHT+IGU7jxH5mfvqjUzNNO+cJvYRC6zia50akRFOhFPYVPqR473ZqGd/ljEGbus5kELxvRnJrn/Pw== X-Received: by 2002:a17:907:3f96:b0:aa5:4ea6:fcae with SMTP id a640c23a62f3a-aa5f7daba68mr38700666b.28.1733189335776; Mon, 02 Dec 2024 17:28:55 -0800 (PST) Message-ID: Date: Tue, 3 Dec 2024 01:28:54 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 1/2] x86, lib, xenpv: Add WBNOINVD helper functions To: Kevin Loughlin , linux-kernel@vger.kernel.org Cc: seanjc@google.com, pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, kvm@vger.kernel.org, thomas.lendacky@amd.com, pgonda@google.com, sidtelang@google.com, mizhang@google.com, virtualization@lists.linux.dev, xen-devel@lists.xenproject.org, bcm-kernel-feedback-list@broadcom.com References: <20241203005921.1119116-1-kevinloughlin@google.com> <20241203005921.1119116-2-kevinloughlin@google.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20241203005921.1119116-2-kevinloughlin@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 03/12/2024 12:59 am, Kevin Loughlin wrote: > diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h > index d4eb9e1d61b8..c040af2d8eff 100644 > --- a/arch/x86/include/asm/paravirt.h > +++ b/arch/x86/include/asm/paravirt.h > @@ -187,6 +187,13 @@ static __always_inline void wbinvd(void) > PVOP_ALT_VCALL0(cpu.wbinvd, "wbinvd", ALT_NOT_XEN); > } > > +extern noinstr void pv_native_wbnoinvd(void); > + > +static __always_inline void wbnoinvd(void) > +{ > + PVOP_ALT_VCALL0(cpu.wbnoinvd, "wbnoinvd", ALT_NOT_XEN); > +} Given this, ... > diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c > index fec381533555..a66b708d8a1e 100644 > --- a/arch/x86/kernel/paravirt.c > +++ b/arch/x86/kernel/paravirt.c > @@ -149,6 +154,7 @@ struct paravirt_patch_template pv_ops = { > .cpu.write_cr0 = native_write_cr0, > .cpu.write_cr4 = native_write_cr4, > .cpu.wbinvd = pv_native_wbinvd, > + .cpu.wbnoinvd = pv_native_wbnoinvd, > .cpu.read_msr = native_read_msr, > .cpu.write_msr = native_write_msr, > .cpu.read_msr_safe = native_read_msr_safe, this, and ... > diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c > index d6818c6cafda..a5c76a6f8976 100644 > --- a/arch/x86/xen/enlighten_pv.c > +++ b/arch/x86/xen/enlighten_pv.c > @@ -1162,6 +1162,7 @@ static const typeof(pv_ops) xen_cpu_ops __initconst = { > .write_cr4 = xen_write_cr4, > > .wbinvd = pv_native_wbinvd, > + .wbnoinvd = pv_native_wbnoinvd, > > .read_msr = xen_read_msr, > .write_msr = xen_write_msr, this, what is the point having a paravirt hook which is wired to native_wbnoinvd() in all cases? That just seems like overhead for overhead sake. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Dec 03 01:45:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 01:45:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847223.1262337 (Exim 4.92) (envelope-from ) id 1tIHyQ-0000MZ-Ay; Tue, 03 Dec 2024 01:45:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847223.1262337; Tue, 03 Dec 2024 01:45: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 1tIHyQ-0000MS-8D; Tue, 03 Dec 2024 01:45:10 +0000 Received: by outflank-mailman (input) for mailman id 847223; Tue, 03 Dec 2024 01:45: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 1tIHyO-0000MM-Gw for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 01:45:08 +0000 Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [2607:f8b0:4864:20::a2f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 37fca537-b118-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 02:45:05 +0100 (CET) Received: by mail-vk1-xa2f.google.com with SMTP id 71dfb90a1353d-5152377321cso1262571e0c.2 for ; Mon, 02 Dec 2024 17:45: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: 37fca537-b118-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1733190305; x=1733795105; 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=wscqKrTwFb9sgoc/UfAh+DpARa9frP273Npy3sEJYN8=; b=y/8bFtFyrjzUnrJ3LJq1pwH94m4S7alku5Blp/DwYrz/qIBH05yKToxBZWx/zbRyQc zgJ4BKqbhkCXndD73z93lKlUZLQCQyOwXNovs5IZ+ZzARiZRn3IiRXC7jlxuDWZbtjzR mOnRtmxN9ttsAdaKzlMjZP4TwxNMYFAM+FtQCn+gIiaFZ5wGBO2VjpGq4a1UeHqoBKQE 81kmWmw3cwAlW7j2XYAzNxCTabCEGPm3wiMcYkEmvJD1I56t8wqmUxI/zZ74i1zt3Fr1 xfoL4FFjA/gjJIogg55aftN6TXq8kmYuEA+hh+ffDWXcCLx0MIMSkkBvyXFQSwOLi8yv rt3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733190305; x=1733795105; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wscqKrTwFb9sgoc/UfAh+DpARa9frP273Npy3sEJYN8=; b=e/QqAgxC+hYZ9GAb2xZVtCb59dP6Vs3SL9Qr9Mn979a9Q6oefSjfNpWztqfsW8urQ8 Ox0yWhzIVL+5Oj+b/ZAIKN97kQgu2UzQuO/+o7RCyu9EgrXDf+qOZqaO2Rdf2s4AEoQQ xqkdU4Y/ImxCm20NJzSSgIR1NsgtCeziWlj6mumo+gsNhNDUZwuWL4a9yd2Tn5EJ2J1r jHFDKlsNZg8aJ6OQtPwT3Q07H2E/5Izgc5mdq4tfaHGX50Aa3Hkg3DiLFJQNYlcZLft2 DXXe6fVX/Vu8vJ/rYjS+kCopHedsn5Ow4+DRQZkKWAcdzYV25+K6lW1gwcZR5wj7UnL3 ohNA== X-Forwarded-Encrypted: i=1; AJvYcCXw2TTJttSKPIZM4AK9/AqAx6/3/so8pMrc7yRHtP11Ivut61NWHWaJkVG2+0PZsPv0KLo1fy05QQA=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz0bWOk21NSLRSlk5/+nKQlWZHbbk0AkcWq3Vbo0rTrJ9sUGs18 OWh2eat2EXsXI6pysEO2O+xDUWRYTWsB5rinqQs0J2rA2Jsd2CcZic1sz5otLbdOHdHNYmurTkU Hr9fKbaWj6CFC9NeOWM0MB57wmarTyPAaBSDi X-Gm-Gg: ASbGncurPCq27bD1Qeo4GU1MOI/RrLvZdjk/4Xu838EAT6D/NlSVDv1Y8GSrdrylG0o KnqpEyq5Ob7F05MlcMPveoiAdjhqYp7+R X-Google-Smtp-Source: AGHT+IEp0cLLV0HS2GVNv35k+CB8WVNUZpet9fwmVxa/fQluHk3o8PZV+wDlJqqbk9+pA1JRUyjCGBWE6ek73EZak9c= X-Received: by 2002:a05:6122:169a:b0:515:4fab:2e53 with SMTP id 71dfb90a1353d-515bf56cea7mr1114649e0c.7.1733190304632; Mon, 02 Dec 2024 17:45:04 -0800 (PST) MIME-Version: 1.0 References: <20241203005921.1119116-1-kevinloughlin@google.com> <20241203005921.1119116-2-kevinloughlin@google.com> In-Reply-To: From: Kevin Loughlin Date: Mon, 2 Dec 2024 17:44:53 -0800 Message-ID: Subject: Re: [RFC PATCH 1/2] x86, lib, xenpv: Add WBNOINVD helper functions To: Andrew Cooper Cc: linux-kernel@vger.kernel.org, seanjc@google.com, pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, kvm@vger.kernel.org, thomas.lendacky@amd.com, pgonda@google.com, sidtelang@google.com, mizhang@google.com, virtualization@lists.linux.dev, xen-devel@lists.xenproject.org, bcm-kernel-feedback-list@broadcom.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 2, 2024 at 5:28=E2=80=AFPM Andrew Cooper wrote: > > On 03/12/2024 12:59 am, Kevin Loughlin wrote: > > diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/par= avirt.h > > index d4eb9e1d61b8..c040af2d8eff 100644 > > --- a/arch/x86/include/asm/paravirt.h > > +++ b/arch/x86/include/asm/paravirt.h > > @@ -187,6 +187,13 @@ static __always_inline void wbinvd(void) > > PVOP_ALT_VCALL0(cpu.wbinvd, "wbinvd", ALT_NOT_XEN); > > } > > > > +extern noinstr void pv_native_wbnoinvd(void); > > + > > +static __always_inline void wbnoinvd(void) > > +{ > > + PVOP_ALT_VCALL0(cpu.wbnoinvd, "wbnoinvd", ALT_NOT_XEN); > > +} > > Given this, ... > > > diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c > > index fec381533555..a66b708d8a1e 100644 > > --- a/arch/x86/kernel/paravirt.c > > +++ b/arch/x86/kernel/paravirt.c > > @@ -149,6 +154,7 @@ struct paravirt_patch_template pv_ops =3D { > > .cpu.write_cr0 =3D native_write_cr0, > > .cpu.write_cr4 =3D native_write_cr4, > > .cpu.wbinvd =3D pv_native_wbinvd, > > + .cpu.wbnoinvd =3D pv_native_wbnoinvd, > > .cpu.read_msr =3D native_read_msr, > > .cpu.write_msr =3D native_write_msr, > > .cpu.read_msr_safe =3D native_read_msr_safe, > > this, and ... > > > diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c > > index d6818c6cafda..a5c76a6f8976 100644 > > --- a/arch/x86/xen/enlighten_pv.c > > +++ b/arch/x86/xen/enlighten_pv.c > > @@ -1162,6 +1162,7 @@ static const typeof(pv_ops) xen_cpu_ops __initcon= st =3D { > > .write_cr4 =3D xen_write_cr4, > > > > .wbinvd =3D pv_native_wbinvd, > > + .wbnoinvd =3D pv_native_wbnoinvd, > > > > .read_msr =3D xen_read_msr, > > .write_msr =3D xen_write_msr, > > this, what is the point having a paravirt hook which is wired to > native_wbnoinvd() in all cases? > > That just seems like overhead for overhead sake. I'm mirroring what's done for WBINVD here, which was changed to a paravirt hook in 10a099405fdf ("cpuidle, xenpv: Make more PARAVIRT_XXL noinstr clean") in order to avoid calls out to instrumented code as described in the commit message in more detail. I believe a hook is similarly required for WBNOINVD, but please let me know if you disagree. Thanks! From xen-devel-bounces@lists.xenproject.org Tue Dec 03 03:12:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 03:12:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847233.1262348 (Exim 4.92) (envelope-from ) id 1tIJL3-0003Zy-7Y; Tue, 03 Dec 2024 03:12:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847233.1262348; Tue, 03 Dec 2024 03:12: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 1tIJL3-0003Zr-4G; Tue, 03 Dec 2024 03:12:37 +0000 Received: by outflank-mailman (input) for mailman id 847233; Tue, 03 Dec 2024 03:12: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 1tIJL2-0003Zl-MP for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 03:12:36 +0000 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11olkn2081e.outbound.protection.outlook.com [2a01:111:f403:2c14::81e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 70190445-b124-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 04:12:34 +0100 (CET) Received: from SN6PR02MB4157.namprd02.prod.outlook.com (2603:10b6:805:33::23) by DM3PR02MB10276.namprd02.prod.outlook.com (2603:10b6:0:42::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 03:12:29 +0000 Received: from SN6PR02MB4157.namprd02.prod.outlook.com ([fe80::cedd:1e64:8f61:b9df]) by SN6PR02MB4157.namprd02.prod.outlook.com ([fe80::cedd:1e64:8f61:b9df%7]) with mapi id 15.20.8182.018; Tue, 3 Dec 2024 03:12: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: 70190445-b124-11ef-a0d3-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JBT437YwG/C/miYaKx+fsN2IP/gddGECJX/eMhPKiO1etVq4QnIp/H+he91SoTmtaW3fw49O8/6+vWkwxVPbdHKBtOlgXXS2Fivg+4pswB4fE3yml8qSOroBjs9sgjMnElwTdzxK12iJoFTEL0FXCsFt/lghATQ6ywFHcB4WcZIpiFEJZ9yUcSuWg0nBsDkIQOJMjv3dOhrb1xvCOMmaBrZWOAaICcc1nJHki6C3sqlqBaJJR665ACtPMF+HUPDrhKa+3Ro91Bmf3ujUfLOQbfAu9ksXWz4L4Hvviw92C2osxhk18dMsnwKB11cM3bWKg9+32YbiotE20NVteeNVMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZplPv3xqGvvwUi46639Brdw+EmoWbKI+XpTmDUaTQeI=; b=T9Fun+kCLAU04p2has/qPXY3zh1uvIGZRT0KkHjKXsm++VEVjWSt9Xh1bXjQ0Zu7LBrw35YvaTT2FUlz0m585lzZ8dQSu0lTaj+wAT08PJUYzjK2D39PDMJg8nKvQS2NC9l//R8oDmp/F7LlZfNH8/GTO74+Jb7hr7xf/Zsn3gUQom0JSQ5ccQNTttt6sZ2xzuJN69IxPhcSVAjBXT8x2wguj5n2TALkoTEf2fgnzYsCAJxJG/1Ct3+7tsbYg+HsPHaZ96Zj3OwTVL+KVNzF+iIy43az8TtDzKHlqPo9ExGK4TelOutOb8GxYv5npJ250mNcVbx3m//2pbupbgYzEQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZplPv3xqGvvwUi46639Brdw+EmoWbKI+XpTmDUaTQeI=; b=FnX3m2+1+Bo7vzKfoD/FbgQnZAIFpH9uWMoeW/wrvYGuwZgxXMKOK+25OH2H7cDP//6CU+bROQ+yIZOSVgtDe3hS0iy0Q/8Pfi1ZGjZMYM3tn7P64XAr2Z7R5+XNjdiNvhjTbdujYkbeS72KL7PoPCwIkD+8ZAG4mNe6WG0o37pOEjdgwNnDExWcUU1rEyeH7qt4QR5hxgVAUBjokJCPBU9Ajl65N2D6vDqGCcydDWCLsdisT+iG+aX0JIs4agm58xmG8NU0ZQvym/2zsb9OTfIMcCepWdXDIT2glamiJ2uilLvyZoPYmnXe8l+BQzt8FTdI9F0S0tyWJ4a6UHeNVA== From: Michael Kelley To: "Kirill A. Shutemov" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "x86@kernel.org" CC: "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , "H. Peter Anvin" , Paolo Bonzini , Vitaly Kuznetsov , Juergen Gross , Boris Ostrovsky , Gaosheng Cui , Michael Roth , Tom Lendacky , Ashish Kalra , Kai Huang , Andi Kleen , Sean Christopherson , Xiaoyao Li , "linux-hyperv@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , "xen-devel@lists.xenproject.org" , Dave Hansen Subject: RE: [PATCH, RESEND] x86/mtrr: Rename mtrr_overwrite_state() to guest_force_mtrr_state() Thread-Topic: [PATCH, RESEND] x86/mtrr: Rename mtrr_overwrite_state() to guest_force_mtrr_state() Thread-Index: AQHbRIxOtYAfZHtFM0eAunneB0shz7LT1/sQ Date: Tue, 3 Dec 2024 03:12:28 +0000 Message-ID: References: <20241202073139.448208-1-kirill.shutemov@linux.intel.com> In-Reply-To: <20241202073139.448208-1-kirill.shutemov@linux.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SN6PR02MB4157:EE_|DM3PR02MB10276:EE_ x-ms-office365-filtering-correlation-id: 1f260513-a488-4a08-6439-08dd134851f5 x-microsoft-antispam: BCL:0;ARA:14566002|15080799006|8060799006|8062599003|19110799003|461199028|4302099013|440099028|3412199025|1602099012|10035399004|102099032; x-microsoft-antispam-message-info: =?us-ascii?Q?oFu6tdQIGfeHVO+F8mWkQ+5p1NMpIZ5/udl0OQ2QA8L/bK0B6QbSvDeLIjF3?= =?us-ascii?Q?heA1UvZWm+kfESHkfdzfMBDCO/iEt6+xOqgig672uMv01XA+483VsrLdGfJW?= =?us-ascii?Q?9GBZQqutytUCQoQzsjNhViS+Lze7u3GxVjzktKN/28UUf6rmdsR14jq2jWqk?= =?us-ascii?Q?K+7KDBuRtvuj8D7xL3pKOMGji2pP1U+6fofl5KXBOzFcS3felnuPfcV+RXAr?= =?us-ascii?Q?n4fiujoIkKrGc0FQyeU6MiNh1xmMdS+1YIIR7deunwaFg/AZY6td3NB2EBqM?= =?us-ascii?Q?z0ooGD1D52xnQWSGcopfN9uLCJAGHkq71tCSAMpAGAcYnomNbyZxSAeJ75kQ?= =?us-ascii?Q?5SZSwZ+0Gc885ivg8ZhFTsIGB4Mts0dXbxdJyakom9aZQDVPDiPZWzTDKQnS?= =?us-ascii?Q?NxLWOGqZSMfiiEW4MaO3RDn+BUe1uNZyuVvkKTSMwzZkwtFCnnJ/WijoRpIc?= =?us-ascii?Q?V9iZMaZMc6Qc8tRC+EhdyAOUIKlCQxtAeFbYS//vJ2sXmobGAKYE2bclRPp9?= =?us-ascii?Q?D0TKDEb6bkkiQb/DCWBmw83h8kRWthDbQmwcABBBLdyRYG7nAxnvIexc1une?= =?us-ascii?Q?Tit6euexwLGHGF3m4JeIKmROjHgHi18ZsdYv77okBtdbcQBkmQUv02UaWJcU?= =?us-ascii?Q?cTX5NLIeHxUPDZbsEAZz0yh+nuKi18A6In/rvzlJ38zmt+6TbCTzYm93dTTK?= =?us-ascii?Q?BHwPei2vLicM4HERNjTPfu6Y9oRoOJiq6XP5BFOcwbgDfpWcvL8lkK6uQGvi?= =?us-ascii?Q?h0XmJEF9Mh//y5mG38rlL4d8RnNjNFh9dYBY75FpXDlr5PxeWqecQgzaJVSI?= =?us-ascii?Q?sYesVKD72cqjkZAA6dyHReVCLE+og9Iq2yMsJzX51xseYH0aFi31JuI85RTl?= =?us-ascii?Q?C2hUk0uvmym1LOw76Z6t0Ax/vI70/+dVnZ8umvMDHR/JuO8FaNhW7wZvilXP?= =?us-ascii?Q?YalK5QFPOuPwwYh9aD0D6Ou2cxDLjH4FrGGA1ftIUJJaHSbNPPptGimlhwyo?= =?us-ascii?Q?ib/hyvJ6lwBOsFjK76C9nf7lVPUo5Lvk+UjA7kHMVx6cSE/JlfvaTaKs8JEv?= =?us-ascii?Q?bRtWW9sKQCNSfjs6PX0hLdRqe13NRGJW9aBVTSFHRpmBUIkjkzUh9HDlLTIH?= =?us-ascii?Q?AmSin+yN9sG/ggcVTsoB7MwAtO7fM4OuBGsfTOOdUJ4NrEhgwiCR8uA=3D?= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?uIZ0Hx9RVxiHYEwic90WFLW4k0PGWCn9zpPNfR8WdnaENiRu0XHczaaYkXtP?= =?us-ascii?Q?2nOtcxOMkGtPKy0/NK5xtUqpTCnFMYCOHBPAK+4avkRPJ94HBpBskN2s3eYU?= =?us-ascii?Q?5jJrsaFY3CNcw1Hh7whzOORtjvPp2KzSHBsd6idJBugZcsT0TTCy1hLmt4Mb?= =?us-ascii?Q?D5xZnI4wukUVxrVOAp8LMoisJtU/HF4WWrKQsH7WbcKVBqX4WG9KYcOo+am+?= =?us-ascii?Q?rX3OMbndrp1lp3lwmiFKEke00/8kMddWkaUYenGuHwRuSKbWIY50A0kTPcrW?= =?us-ascii?Q?IieQPyYTjhBL8xH9ojoIGXNTSXrWC9o5+wKymlSSKVNmqMdb7sBVI9PptiLS?= =?us-ascii?Q?qkQ2be4OVdZGsqdqMOhl+6iXnO/JxgK7JToJ3Y3F7LWrTpLsW4qkqAPX7fh3?= =?us-ascii?Q?qM6xQvBUy1R5ac6aTP/JwZaN0uhoGPH9VRowMxd0ZIYN62yCwc4rWXHnC8jT?= =?us-ascii?Q?XBBkSXUJNlbdkFoIUIlavv301X/WrJdaikxef4exEXKX16cCz3+jBhzv+dGf?= =?us-ascii?Q?krIhpxFHFuq1xdCVAGJO0HRc9Bmm/KGz2cae2kIFsdpAbI4UPv+5d8Xvi17n?= =?us-ascii?Q?QZy6bm4O9nBUXuoEI5XLJ1zAKNqBUPz01OoRgcUtWVEnHJlfQWnafgb9Xaee?= =?us-ascii?Q?LAxKF21FnpAZaQbSC4QjkhR/MuOa3EvLDGggdCD/HQ5KJi70XGmqmjiOTxRt?= =?us-ascii?Q?5BGaMDro2NgHAp3WZH9nzA3rAHGq+IaXky5BFBt7E+EVl1m29cI/fSM2OiND?= =?us-ascii?Q?T9ZqlE6/3lXpSYnqbd+tabOhNAM4ppXysDX4JUBRR96TqMPKlbQDaoM+IKhN?= =?us-ascii?Q?LhSCHwmQfHp0GOfeokJzKpTjuXwXyfQrbBuPevvuxaS9BmRSGaPtfKUJrWl0?= =?us-ascii?Q?LUGs85yzjvakSVvB2s0gS2v1XVqWmT6aC36uyAQyUhlJadTfGrmBO10iTacW?= =?us-ascii?Q?cEneUnqMfTHWsPfnGy5Sr50LXG/h+QQ2fqjQY2/aOfsnubjwr1hcrrLN+8RN?= =?us-ascii?Q?RR0jOugbYOCJS6+6X40Yctz156OCyGpH+LrBxf8a0hz0Yr2OJp6iAIg49aFq?= =?us-ascii?Q?iEM36nognffg6eHd67aB7TWMdGMH9voFM57cjvRxNlDPX0hJXEor88CXtGzE?= =?us-ascii?Q?mUzaiZc7wvuVrtfqbAN2gPVAokE/Zr4JqM637+PAHhfG0uVKCTtjDh6q4J98?= =?us-ascii?Q?0ALJLiKVD2t2dpH2Y07sIagok1zwrBMhgwQoLIAK7KtNcrw5oF4XbYrx/i8?= =?us-ascii?Q?=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 1f260513-a488-4a08-6439-08dd134851f5 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2024 03:12:28.9825 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR02MB10276 From: Kirill A. Shutemov Sent: Sunday, De= cember 1, 2024 11:32 PM >=20 > Rename the helper to better reflect its function. >=20 > Signed-off-by: Kirill A. Shutemov > Suggested-by: Dave Hansen > Acked-by: Dave Hansen FWIW, I previously gave my "Reviewed-by" on this patch [1]. I didn't call it out explicitly, but did so for the patch in general as well as specifically for the Hyper-V related change. Michael [1]: https://lore.kernel.org/linux-hyperv/SN6PR02MB4157C91EE70F4EF4B6EDDE46= D4412@SN6PR02MB4157.namprd02.prod.outlook.com/ > --- > arch/x86/hyperv/ivm.c | 2 +- > arch/x86/include/asm/mtrr.h | 10 +++++----- > arch/x86/kernel/cpu/mtrr/generic.c | 6 +++--- > arch/x86/kernel/cpu/mtrr/mtrr.c | 2 +- > arch/x86/kernel/kvm.c | 2 +- > arch/x86/xen/enlighten_pv.c | 4 ++-- > 6 files changed, 13 insertions(+), 13 deletions(-) >=20 > diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c > index 60fc3ed72830..90aabe1fd3b6 100644 > --- a/arch/x86/hyperv/ivm.c > +++ b/arch/x86/hyperv/ivm.c > @@ -664,7 +664,7 @@ void __init hv_vtom_init(void) > x86_platform.guest.enc_status_change_finish =3D hv_vtom_set_host_visibi= lity; >=20 > /* Set WB as the default cache mode. */ > - mtrr_overwrite_state(NULL, 0, MTRR_TYPE_WRBACK); > + guest_force_mtrr_state(NULL, 0, MTRR_TYPE_WRBACK); > } >=20 > #endif /* defined(CONFIG_AMD_MEM_ENCRYPT) || > defined(CONFIG_INTEL_TDX_GUEST) */ > diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h > index 4218248083d9..c69e269937c5 100644 > --- a/arch/x86/include/asm/mtrr.h > +++ b/arch/x86/include/asm/mtrr.h > @@ -58,8 +58,8 @@ struct mtrr_state_type { > */ > # ifdef CONFIG_MTRR > void mtrr_bp_init(void); > -void mtrr_overwrite_state(struct mtrr_var_range *var, unsigned int num_v= ar, > - mtrr_type def_type); > +void guest_force_mtrr_state(struct mtrr_var_range *var, unsigned int num= _var, > + mtrr_type def_type); > extern u8 mtrr_type_lookup(u64 addr, u64 end, u8 *uniform); > extern void mtrr_save_fixed_ranges(void *); > extern void mtrr_save_state(void); > @@ -75,9 +75,9 @@ void mtrr_disable(void); > void mtrr_enable(void); > void mtrr_generic_set_state(void); > # else > -static inline void mtrr_overwrite_state(struct mtrr_var_range *var, > - unsigned int num_var, > - mtrr_type def_type) > +static inline void guest_force_mtrr_state(struct mtrr_var_range *var, > + unsigned int num_var, > + mtrr_type def_type) > { > } >=20 > diff --git a/arch/x86/kernel/cpu/mtrr/generic.c b/arch/x86/kernel/cpu/mtr= r/generic.c > index 7b29ebda024f..2fdfda2b60e4 100644 > --- a/arch/x86/kernel/cpu/mtrr/generic.c > +++ b/arch/x86/kernel/cpu/mtrr/generic.c > @@ -423,7 +423,7 @@ void __init mtrr_copy_map(void) > } >=20 > /** > - * mtrr_overwrite_state - set static MTRR state > + * guest_force_mtrr_state - set static MTRR state for a guest > * > * Used to set MTRR state via different means (e.g. with data obtained f= rom > * a hypervisor). > @@ -436,8 +436,8 @@ void __init mtrr_copy_map(void) > * @num_var: length of the @var array > * @def_type: default caching type > */ > -void mtrr_overwrite_state(struct mtrr_var_range *var, unsigned int num_v= ar, > - mtrr_type def_type) > +void guest_force_mtrr_state(struct mtrr_var_range *var, unsigned int num= _var, > + mtrr_type def_type) > { > unsigned int i; >=20 > diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.c b/arch/x86/kernel/cpu/mtrr/m= trr.c > index 989d368be04f..ecbda0341a8a 100644 > --- a/arch/x86/kernel/cpu/mtrr/mtrr.c > +++ b/arch/x86/kernel/cpu/mtrr/mtrr.c > @@ -625,7 +625,7 @@ void mtrr_save_state(void) > static int __init mtrr_init_finalize(void) > { > /* > - * Map might exist if mtrr_overwrite_state() has been called or if > + * Map might exist if guest_force_mtrr_state() has been called or if > * mtrr_enabled() returns true. > */ > mtrr_copy_map(); > diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c > index 21e9e4845354..7a422a6c5983 100644 > --- a/arch/x86/kernel/kvm.c > +++ b/arch/x86/kernel/kvm.c > @@ -983,7 +983,7 @@ static void __init kvm_init_platform(void) > x86_platform.apic_post_init =3D kvm_apic_init; >=20 > /* Set WB as the default cache mode for SEV-SNP and TDX */ > - mtrr_overwrite_state(NULL, 0, MTRR_TYPE_WRBACK); > + guest_force_mtrr_state(NULL, 0, MTRR_TYPE_WRBACK); > } >=20 > #if defined(CONFIG_AMD_MEM_ENCRYPT) > diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c > index d6818c6cafda..633469fab536 100644 > --- a/arch/x86/xen/enlighten_pv.c > +++ b/arch/x86/xen/enlighten_pv.c > @@ -171,7 +171,7 @@ static void __init xen_set_mtrr_data(void) >=20 > /* Only overwrite MTRR state if any MTRR could be got from Xen. */ > if (reg) > - mtrr_overwrite_state(var, reg, MTRR_TYPE_UNCACHABLE); > + guest_force_mtrr_state(var, reg, MTRR_TYPE_UNCACHABLE); > #endif > } >=20 > @@ -195,7 +195,7 @@ static void __init xen_pv_init_platform(void) > if (xen_initial_domain()) > xen_set_mtrr_data(); > else > - mtrr_overwrite_state(NULL, 0, MTRR_TYPE_WRBACK); > + guest_force_mtrr_state(NULL, 0, MTRR_TYPE_WRBACK); >=20 > /* Adjust nr_cpu_ids before "enumeration" happens */ > xen_smp_count_cpus(); > -- > 2.45.2 >=20 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 04:11:02 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 04:11:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847243.1262357 (Exim 4.92) (envelope-from ) id 1tIKFU-0002hI-EK; Tue, 03 Dec 2024 04:10:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847243.1262357; Tue, 03 Dec 2024 04:10: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 1tIKFU-0002hB-Bi; Tue, 03 Dec 2024 04:10:56 +0000 Received: by outflank-mailman (input) for mailman id 847243; Tue, 03 Dec 2024 04:10: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 1tIKFS-0002h5-Dj for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 04:10:54 +0000 Received: from mail.zytor.com (torg.zytor.com [2607:7c80:54:3::138]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 945db2ef-b12c-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 05:10:51 +0100 (CET) Received: from [192.168.7.205] ([71.202.166.45]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 4B349oNB230762 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 2 Dec 2024 20:09:51 -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: 945db2ef-b12c-11ef-99a3-01e77a169b0f DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 4B349oNB230762 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2024111601; t=1733198993; bh=sHPXdo6p8K0elhJ6IE0XDTGTz2zzDKVVPgjp1vb9is4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=RDSHn9YgbMj/SGP9f25WYjgOkPbspINuSTcqQC3Xn+QMx9ncZZeAsFmGs09JHNZtN 6IeBjOt9WIiegvHcSkw/6rp+CwdoraHSEI8mISCic+C6z7LhE6UEIUMC9fjJJPpL3u dU7IxTRlEhh73Pwh1BsbLXECyGA7jocz2SR47GxukMlxWavs5sH9kGA/dcrqNggUAA /1X4gR402tHq67Cb5GPgcMexk9W8p63VCgtmRZGkc4STwEneVaK/sdxH8ZiszXd2iu 6dm3uvrouJ8CeaUYvDMH3hAJtNISHNOO2X0feQTYDC1eCHKD4CzX/oROXoD6QksjbP j4ykXHguONibg== Message-ID: Date: Mon, 2 Dec 2024 20:09:49 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 1/2] x86, lib, xenpv: Add WBNOINVD helper functions To: Kevin Loughlin , Andrew Cooper Cc: linux-kernel@vger.kernel.org, seanjc@google.com, pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, kvm@vger.kernel.org, thomas.lendacky@amd.com, pgonda@google.com, sidtelang@google.com, mizhang@google.com, virtualization@lists.linux.dev, xen-devel@lists.xenproject.org, bcm-kernel-feedback-list@broadcom.com References: <20241203005921.1119116-1-kevinloughlin@google.com> <20241203005921.1119116-2-kevinloughlin@google.com> Content-Language: en-US From: Xin Li Autocrypt: addr=xin@zytor.com; keydata= xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+ QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4 l75w1xInsg== In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/2/2024 5:44 PM, Kevin Loughlin wrote: > On Mon, Dec 2, 2024 at 5:28 PM Andrew Cooper wrote: >> >> On 03/12/2024 12:59 am, Kevin Loughlin wrote: >>> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h >>> index d4eb9e1d61b8..c040af2d8eff 100644 >>> --- a/arch/x86/include/asm/paravirt.h >>> +++ b/arch/x86/include/asm/paravirt.h >>> @@ -187,6 +187,13 @@ static __always_inline void wbinvd(void) >>> PVOP_ALT_VCALL0(cpu.wbinvd, "wbinvd", ALT_NOT_XEN); >>> } >>> >>> +extern noinstr void pv_native_wbnoinvd(void); >>> + >>> +static __always_inline void wbnoinvd(void) >>> +{ >>> + PVOP_ALT_VCALL0(cpu.wbnoinvd, "wbnoinvd", ALT_NOT_XEN); >>> +} >> >> Given this, ... >> >>> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c >>> index fec381533555..a66b708d8a1e 100644 >>> --- a/arch/x86/kernel/paravirt.c >>> +++ b/arch/x86/kernel/paravirt.c >>> @@ -149,6 +154,7 @@ struct paravirt_patch_template pv_ops = { >>> .cpu.write_cr0 = native_write_cr0, >>> .cpu.write_cr4 = native_write_cr4, >>> .cpu.wbinvd = pv_native_wbinvd, >>> + .cpu.wbnoinvd = pv_native_wbnoinvd, >>> .cpu.read_msr = native_read_msr, >>> .cpu.write_msr = native_write_msr, >>> .cpu.read_msr_safe = native_read_msr_safe, >> >> this, and ... >> >>> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c >>> index d6818c6cafda..a5c76a6f8976 100644 >>> --- a/arch/x86/xen/enlighten_pv.c >>> +++ b/arch/x86/xen/enlighten_pv.c >>> @@ -1162,6 +1162,7 @@ static const typeof(pv_ops) xen_cpu_ops __initconst = { >>> .write_cr4 = xen_write_cr4, >>> >>> .wbinvd = pv_native_wbinvd, >>> + .wbnoinvd = pv_native_wbnoinvd, >>> >>> .read_msr = xen_read_msr, >>> .write_msr = xen_write_msr, >> >> this, what is the point having a paravirt hook which is wired to >> native_wbnoinvd() in all cases? >> >> That just seems like overhead for overhead sake. > > I'm mirroring what's done for WBINVD here, which was changed to a > paravirt hook in 10a099405fdf ("cpuidle, xenpv: Make more PARAVIRT_XXL > noinstr clean") in order to avoid calls out to instrumented code as > described in the commit message in more detail. I believe a hook is > similarly required for WBNOINVD, but please let me know if you > disagree. Thanks! Then the question is why we need to add WBINVD/WBNOINVD to the paravirt hooks. From xen-devel-bounces@lists.xenproject.org Tue Dec 03 06:48:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 06:48:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847258.1262368 (Exim 4.92) (envelope-from ) id 1tIMhV-0002zs-Jk; Tue, 03 Dec 2024 06:48:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847258.1262368; Tue, 03 Dec 2024 06:48: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 1tIMhV-0002zl-G3; Tue, 03 Dec 2024 06:48:01 +0000 Received: by outflank-mailman (input) for mailman id 847258; Tue, 03 Dec 2024 06:48: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 1tIMhT-0002zf-V7 for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 06:47:59 +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 8707fe9d-b142-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 07:47:56 +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 C9C0A2116D; Tue, 3 Dec 2024 06:47:55 +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 1459F139C2; Tue, 3 Dec 2024 06:47:55 +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 IfMAApupTmdmIAAAD6G6ig (envelope-from ); Tue, 03 Dec 2024 06:47: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: 8707fe9d-b142-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733208475; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KmTgfQaLPbT4i+fON6Y5ezxxdO6L+T5ytkzLsgHmxZg=; b=ON/teFOrcct37tAnFgOR2NrHAzcYeTxxCe+Wn8mh605pWh3cYXyGwQEBkWPTRFw7+/i7NV qwzuhbiRwNVQTD4toB3ap+JgGGMd2lLu28dXvzkFxz++s2mQnTKsVu3K1n5Q/fYktaQ9vp A64vaMyCcjx0mZv1ZUdJGrpLd9e1rRI= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733208475; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KmTgfQaLPbT4i+fON6Y5ezxxdO6L+T5ytkzLsgHmxZg=; b=ON/teFOrcct37tAnFgOR2NrHAzcYeTxxCe+Wn8mh605pWh3cYXyGwQEBkWPTRFw7+/i7NV qwzuhbiRwNVQTD4toB3ap+JgGGMd2lLu28dXvzkFxz++s2mQnTKsVu3K1n5Q/fYktaQ9vp A64vaMyCcjx0mZv1ZUdJGrpLd9e1rRI= Message-ID: <24b80006-dcea-4a76-b5c8-e147d9191ed2@suse.com> Date: Tue, 3 Dec 2024 07:47:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 1/2] x86, lib, xenpv: Add WBNOINVD helper functions To: Xin Li , Kevin Loughlin , Andrew Cooper Cc: linux-kernel@vger.kernel.org, seanjc@google.com, pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, kvm@vger.kernel.org, thomas.lendacky@amd.com, pgonda@google.com, sidtelang@google.com, mizhang@google.com, virtualization@lists.linux.dev, xen-devel@lists.xenproject.org, bcm-kernel-feedback-list@broadcom.com References: <20241203005921.1119116-1-kevinloughlin@google.com> <20241203005921.1119116-2-kevinloughlin@google.com> Content-Language: en-US From: Juergen Gross In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -4.30 X-Spamd-Result: default: False [-4.30 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; ARC_NA(0.00)[]; RCPT_COUNT_TWELVE(0.00)[20]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid] X-Spam-Flag: NO X-Spam-Level: On 03.12.24 05:09, Xin Li wrote: > On 12/2/2024 5:44 PM, Kevin Loughlin wrote: >> On Mon, Dec 2, 2024 at 5:28 PM Andrew Cooper wrote: >>> >>> On 03/12/2024 12:59 am, Kevin Loughlin wrote: >>>> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h >>>> index d4eb9e1d61b8..c040af2d8eff 100644 >>>> --- a/arch/x86/include/asm/paravirt.h >>>> +++ b/arch/x86/include/asm/paravirt.h >>>> @@ -187,6 +187,13 @@ static __always_inline void wbinvd(void) >>>>        PVOP_ALT_VCALL0(cpu.wbinvd, "wbinvd", ALT_NOT_XEN); >>>>   } >>>> >>>> +extern noinstr void pv_native_wbnoinvd(void); >>>> + >>>> +static __always_inline void wbnoinvd(void) >>>> +{ >>>> +     PVOP_ALT_VCALL0(cpu.wbnoinvd, "wbnoinvd", ALT_NOT_XEN); >>>> +} >>> >>> Given this, ... >>> >>>> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c >>>> index fec381533555..a66b708d8a1e 100644 >>>> --- a/arch/x86/kernel/paravirt.c >>>> +++ b/arch/x86/kernel/paravirt.c >>>> @@ -149,6 +154,7 @@ struct paravirt_patch_template pv_ops = { >>>>        .cpu.write_cr0          = native_write_cr0, >>>>        .cpu.write_cr4          = native_write_cr4, >>>>        .cpu.wbinvd             = pv_native_wbinvd, >>>> +     .cpu.wbnoinvd           = pv_native_wbnoinvd, >>>>        .cpu.read_msr           = native_read_msr, >>>>        .cpu.write_msr          = native_write_msr, >>>>        .cpu.read_msr_safe      = native_read_msr_safe, >>> >>> this, and ... >>> >>>> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c >>>> index d6818c6cafda..a5c76a6f8976 100644 >>>> --- a/arch/x86/xen/enlighten_pv.c >>>> +++ b/arch/x86/xen/enlighten_pv.c >>>> @@ -1162,6 +1162,7 @@ static const typeof(pv_ops) xen_cpu_ops __initconst = { >>>>                .write_cr4 = xen_write_cr4, >>>> >>>>                .wbinvd = pv_native_wbinvd, >>>> +             .wbnoinvd = pv_native_wbnoinvd, >>>> >>>>                .read_msr = xen_read_msr, >>>>                .write_msr = xen_write_msr, >>> >>> this, what is the point having a paravirt hook which is wired to >>> native_wbnoinvd() in all cases? >>> >>> That just seems like overhead for overhead sake. >> >> I'm mirroring what's done for WBINVD here, which was changed to a >> paravirt hook in 10a099405fdf ("cpuidle, xenpv: Make more PARAVIRT_XXL >> noinstr clean") in order to avoid calls out to instrumented code as >> described in the commit message in more detail. I believe a hook is >> similarly required for WBNOINVD, but please let me know if you >> disagree. Thanks! > > Then the question is why we need to add WBINVD/WBNOINVD to the paravirt > hooks. > We don't. The wbinvd hook is a leftover from lguest times. I'll send a patch to remove it. Juergen P.S.: As the paravirt maintainer I would have preferred to be Cc-ed in the initial patch mail. From xen-devel-bounces@lists.xenproject.org Tue Dec 03 07:16:05 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 07:16:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847268.1262378 (Exim 4.92) (envelope-from ) id 1tIN8Y-0006rP-GI; Tue, 03 Dec 2024 07:15:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847268.1262378; Tue, 03 Dec 2024 07:15:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIN8Y-0006rI-D4; Tue, 03 Dec 2024 07:15:58 +0000 Received: by outflank-mailman (input) for mailman id 847268; Tue, 03 Dec 2024 07:15: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 1tIN8X-0006rC-Es for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 07:15:57 +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 6feb9826-b146-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 08:15:55 +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 ED95D2116D; Tue, 3 Dec 2024 07:15:54 +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 6E6A8139C2; Tue, 3 Dec 2024 07:15:54 +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 abvvGCqwTmeVJwAAD6G6ig (envelope-from ); Tue, 03 Dec 2024 07:15: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: 6feb9826-b146-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733210155; 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=YteXmpzJovraoUH7Bk6Fvs0Z1YQksr+1l5QkNJPajMU=; b=S/nw+k6yAnLTqZGvI+KqLMq9SD/ydjeYjWSkKssGFQ5/wmKWcKZAc0hdpWkm5il70c5Wtr oMTbYJC1dGwwa+hXGAppeD1nq5eMoWerYwtTzeInPPkovaKmiQia53Rj0Tl0ks8dbR5ABl 8Hrg+j0bW5/3hcrY8zfcspXZzGbEhp0= Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b="S/nw+k6y" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733210155; 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=YteXmpzJovraoUH7Bk6Fvs0Z1YQksr+1l5QkNJPajMU=; b=S/nw+k6yAnLTqZGvI+KqLMq9SD/ydjeYjWSkKssGFQ5/wmKWcKZAc0hdpWkm5il70c5Wtr oMTbYJC1dGwwa+hXGAppeD1nq5eMoWerYwtTzeInPPkovaKmiQia53Rj0Tl0ks8dbR5ABl 8Hrg+j0bW5/3hcrY8zfcspXZzGbEhp0= From: Juergen Gross To: linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev Cc: Juergen Gross , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Fenghua Yu , Reinette Chatre , Boris Ostrovsky , xen-devel@lists.xenproject.org Subject: [PATCH] x86/paravirt: remove the wbinvd hook Date: Tue, 3 Dec 2024 08:15:50 +0100 Message-ID: <20241203071550.26487-1-jgross@suse.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: ED95D2116D X-Spam-Level: X-Spamd-Result: default: False [-3.01 / 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)[]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:dkim,suse.com:mid]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWELVE(0.00)[16]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[suse.com:+] X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Action: no action X-Spam-Score: -3.01 X-Spam-Flag: NO The wbinvd paravirt hook is a leftover of lguest times. Today it is no longer needed, as all users use the native wbinvd implementation. Remove the hook and rename native_wbinvd() to wbinvd(). Signed-off-by: Juergen Gross --- arch/x86/include/asm/paravirt.h | 7 ------- arch/x86/include/asm/paravirt_types.h | 2 -- arch/x86/include/asm/special_insns.h | 8 +------- arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 2 +- arch/x86/kernel/paravirt.c | 6 ------ arch/x86/kernel/process.c | 4 ++-- arch/x86/xen/enlighten_pv.c | 2 -- 7 files changed, 4 insertions(+), 27 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index d4eb9e1d61b8..041aff51eb50 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -180,13 +180,6 @@ static inline void halt(void) PVOP_VCALL0(irq.halt); } -extern noinstr void pv_native_wbinvd(void); - -static __always_inline void wbinvd(void) -{ - PVOP_ALT_VCALL0(cpu.wbinvd, "wbinvd", ALT_NOT_XEN); -} - static inline u64 paravirt_read_msr(unsigned msr) { return PVOP_CALL1(u64, cpu.read_msr, msr); diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 8d4fbe1be489..fea56b04f436 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -86,8 +86,6 @@ struct pv_cpu_ops { void (*update_io_bitmap)(void); #endif - void (*wbinvd)(void); - /* cpuid emulation, mostly so that caps bits can be disabled */ void (*cpuid)(unsigned int *eax, unsigned int *ebx, unsigned int *ecx, unsigned int *edx); diff --git a/arch/x86/include/asm/special_insns.h b/arch/x86/include/asm/special_insns.h index aec6e2d3aa1d..fab7c8af27a4 100644 --- a/arch/x86/include/asm/special_insns.h +++ b/arch/x86/include/asm/special_insns.h @@ -115,7 +115,7 @@ static inline void wrpkru(u32 pkru) } #endif -static __always_inline void native_wbinvd(void) +static __always_inline void wbinvd(void) { asm volatile("wbinvd": : :"memory"); } @@ -167,12 +167,6 @@ static inline void __write_cr4(unsigned long x) { native_write_cr4(x); } - -static __always_inline void wbinvd(void) -{ - native_wbinvd(); -} - #endif /* CONFIG_PARAVIRT_XXL */ static __always_inline void clflush(volatile void *__p) diff --git a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c index 972e6b6b0481..b72f7e91387e 100644 --- a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c +++ b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c @@ -459,7 +459,7 @@ static int pseudo_lock_fn(void *_rdtgrp) * increase likelihood that allocated cache portion will be filled * with associated memory. */ - native_wbinvd(); + wbinvd(); /* * Always called with interrupts enabled. By disabling interrupts diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c index fec381533555..927e33e6843a 100644 --- a/arch/x86/kernel/paravirt.c +++ b/arch/x86/kernel/paravirt.c @@ -116,11 +116,6 @@ static noinstr void pv_native_set_debugreg(int regno, unsigned long val) native_set_debugreg(regno, val); } -noinstr void pv_native_wbinvd(void) -{ - native_wbinvd(); -} - static noinstr void pv_native_safe_halt(void) { native_safe_halt(); @@ -148,7 +143,6 @@ struct paravirt_patch_template pv_ops = { .cpu.read_cr0 = native_read_cr0, .cpu.write_cr0 = native_write_cr0, .cpu.write_cr4 = native_write_cr4, - .cpu.wbinvd = pv_native_wbinvd, .cpu.read_msr = native_read_msr, .cpu.write_msr = native_write_msr, .cpu.read_msr_safe = native_read_msr_safe, diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index f63f8fd00a91..58ead05a1c29 100644 --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -825,7 +825,7 @@ void __noreturn stop_this_cpu(void *dummy) * X86_FEATURE_SME due to cmdline options. */ if (c->extended_cpuid_level >= 0x8000001f && (cpuid_eax(0x8000001f) & BIT(0))) - native_wbinvd(); + wbinvd(); /* * This brings a cache line back and dirties it, but @@ -846,7 +846,7 @@ void __noreturn stop_this_cpu(void *dummy) /* * Use native_halt() so that memory contents don't change * (stack usage and variables) after possibly issuing the - * native_wbinvd() above. + * wbinvd() above. */ native_halt(); } diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index d6818c6cafda..fd2169063480 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -1161,8 +1161,6 @@ static const typeof(pv_ops) xen_cpu_ops __initconst = { .write_cr4 = xen_write_cr4, - .wbinvd = pv_native_wbinvd, - .read_msr = xen_read_msr, .write_msr = xen_write_msr, -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 08:12:00 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 08:12:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847283.1262388 (Exim 4.92) (envelope-from ) id 1tIO0W-00065H-7N; Tue, 03 Dec 2024 08:11:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847283.1262388; Tue, 03 Dec 2024 08:11: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 1tIO0W-00065A-4p; Tue, 03 Dec 2024 08:11:44 +0000 Received: by outflank-mailman (input) for mailman id 847283; Tue, 03 Dec 2024 08:11: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 1tIO0U-00064y-IX for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 08:11:42 +0000 Received: from mail.zytor.com (torg.zytor.com [2607:7c80:54:3::138]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 34adec79-b14e-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 09:11:33 +0100 (CET) Received: from [192.168.7.205] ([71.202.166.45]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 4B38AqJi322558 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 3 Dec 2024 00:10:52 -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: 34adec79-b14e-11ef-99a3-01e77a169b0f DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 4B38AqJi322558 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2024111601; t=1733213454; bh=Gjt29Xyz+OZvO528TtflAd8fuc5YuSz5FuvYYAukkjY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=NJVWnyohYxxPHKawzE2PaIJShfBzSYY3l6rvK/K94gmRO32nSvFn5vdb/0lD1IN3W BLOprK8yii/5+vEloY+ObAHpkivASlubGMQyPO9LWvh/13JJD0BrhrnZeLdIZlE95S wB3UaFxWOBbWQ9U/7bLejiu7cPyPQ5tM1T+18KuIqrAdGjX+LiR6TJcCWCELXEIkBQ DN0CYc2ouYU4ThmU5gqBDG41+egL3BpPL8T22pdH3Tal8O0VMKQuFwwKSis8Tdx5mA zmgeFXrRsTjnWIuF9Jj5o1eVpGEUsAbDnSYWkC/2HqkJaFlpH3lNec8fWHlK/dkep/ ABs6l+vOD/WlQ== Message-ID: <25fa8746-3b36-4d43-86cd-37aadaacdf2e@zytor.com> Date: Tue, 3 Dec 2024 00:10:46 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 1/2] x86, lib, xenpv: Add WBNOINVD helper functions To: Juergen Gross , Kevin Loughlin , Andrew Cooper Cc: linux-kernel@vger.kernel.org, seanjc@google.com, pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, kvm@vger.kernel.org, thomas.lendacky@amd.com, pgonda@google.com, sidtelang@google.com, mizhang@google.com, virtualization@lists.linux.dev, xen-devel@lists.xenproject.org, bcm-kernel-feedback-list@broadcom.com References: <20241203005921.1119116-1-kevinloughlin@google.com> <20241203005921.1119116-2-kevinloughlin@google.com> <24b80006-dcea-4a76-b5c8-e147d9191ed2@suse.com> Content-Language: en-US From: Xin Li Autocrypt: addr=xin@zytor.com; keydata= xsDNBGUPz1cBDACS/9yOJGojBFPxFt0OfTWuMl0uSgpwk37uRrFPTTLw4BaxhlFL0bjs6q+0 2OfG34R+a0ZCuj5c9vggUMoOLdDyA7yPVAJU0OX6lqpg6z/kyQg3t4jvajG6aCgwSDx5Kzg5 Rj3AXl8k2wb0jdqRB4RvaOPFiHNGgXCs5Pkux/qr0laeFIpzMKMootGa4kfURgPhRzUaM1vy bsMsL8vpJtGUmitrSqe5dVNBH00whLtPFM7IbzKURPUOkRRiusFAsw0a1ztCgoFczq6VfAVu raTye0L/VXwZd+aGi401V2tLsAHxxckRi9p3mc0jExPc60joK+aZPy6amwSCy5kAJ/AboYtY VmKIGKx1yx8POy6m+1lZ8C0q9b8eJ8kWPAR78PgT37FQWKYS1uAroG2wLdK7FiIEpPhCD+zH wlslo2ETbdKjrLIPNehQCOWrT32k8vFNEMLP5G/mmjfNj5sEf3IOKgMTMVl9AFjsINLHcxEQ 6T8nGbX/n3msP6A36FDfdSEAEQEAAc0WWGluIExpIDx4aW5Aenl0b3IuY29tPsLBDQQTAQgA NxYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89XBQkFo5qAAhsDBAsJCAcFFQgJCgsFFgID AQAACgkQa70OVx2uN1HUpgv/cM2fsFCQodLArMTX5nt9yqAWgA5t1srri6EgS8W3F+3Kitge tYTBKu6j5BXuXaX3vyfCm+zajDJN77JHuYnpcKKr13VcZi1Swv6Jx1u0II8DOmoDYLb1Q2ZW v83W55fOWJ2g72x/UjVJBQ0sVjAngazU3ckc0TeNQlkcpSVGa/qBIHLfZraWtdrNAQT4A1fa sWGuJrChBFhtKbYXbUCu9AoYmmbQnsx2EWoJy3h7OjtfFapJbPZql+no5AJ3Mk9eE5oWyLH+ QWqtOeJM7kKvn/dBudokFSNhDUw06e7EoVPSJyUIMbYtUO7g2+Atu44G/EPP0yV0J4lRO6EA wYRXff7+I1jIWEHpj5EFVYO6SmBg7zF2illHEW31JAPtdDLDHYcZDfS41caEKOQIPsdzQkaQ oW2hchcjcMPAfyhhRzUpVHLPxLCetP8vrVhTvnaZUo0xaVYb3+wjP+D5j/3+hwblu2agPsaE vgVbZ8Fx3TUxUPCAdr/p73DGg57oHjgezsDNBGUPz1gBDAD4Mg7hMFRQqlzotcNSxatlAQNL MadLfUTFz8wUUa21LPLrHBkUwm8RujehJrzcVbPYwPXIO0uyL/F///CogMNx7Iwo6by43KOy g89wVFhyy237EY76j1lVfLzcMYmjBoTH95fJC/lVb5Whxil6KjSN/R/y3jfG1dPXfwAuZ/4N cMoOslWkfZKJeEut5aZTRepKKF54T5r49H9F7OFLyxrC/uI9UDttWqMxcWyCkHh0v1Di8176 jjYRNTrGEfYfGxSp+3jYL3PoNceIMkqM9haXjjGl0W1B4BidK1LVYBNov0rTEzyr0a1riUrp Qk+6z/LHxCM9lFFXnqH7KWeToTOPQebD2B/Ah5CZlft41i8L6LOF/LCuDBuYlu/fI2nuCc8d m4wwtkou1Y/kIwbEsE/6RQwRXUZhzO6llfoN96Fczr/RwvPIK5SVMixqWq4QGFAyK0m/1ap4 bhIRrdCLVQcgU4glo17vqfEaRcTW5SgX+pGs4KIPPBE5J/ABD6pBnUUAEQEAAcLA/AQYAQgA JhYhBIUq/WFSDTiOvUIqv2u9DlcdrjdRBQJlD89ZBQkFo5qAAhsMAAoJEGu9DlcdrjdR4C0L /RcjolEjoZW8VsyxWtXazQPnaRvzZ4vhmGOsCPr2BPtMlSwDzTlri8BBG1/3t/DNK4JLuwEj OAIE3fkkm+UG4Kjud6aNeraDI52DRVCSx6xff3bjmJsJJMb12mWglN6LjdF6K+PE+OTJUh2F dOhslN5C2kgl0dvUuevwMgQF3IljLmi/6APKYJHjkJpu1E6luZec/lRbetHuNFtbh3xgFIJx 2RpgVDP4xB3f8r0I+y6ua+p7fgOjDLyoFjubRGed0Be45JJQEn7A3CSb6Xu7NYobnxfkwAGZ Q81a2XtvNS7Aj6NWVoOQB5KbM4yosO5+Me1V1SkX2jlnn26JPEvbV3KRFcwV5RnDxm4OQTSk PYbAkjBbm+tuJ/Sm+5Yp5T/BnKz21FoCS8uvTiziHj2H7Cuekn6F8EYhegONm+RVg3vikOpn gao85i4HwQTK9/D1wgJIQkdwWXVMZ6q/OALaBp82vQ2U9sjTyFXgDjglgh00VRAHP7u1Rcu4 l75w1xInsg== In-Reply-To: <24b80006-dcea-4a76-b5c8-e147d9191ed2@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/2/2024 10:47 PM, Juergen Gross wrote: > P.S.: As the paravirt maintainer I would have preferred to be Cc-ed in the >       initial patch mail. Looks that Kevin didn't run './scripts/get_maintainer.pl'? Thanks! Xin From xen-devel-bounces@lists.xenproject.org Tue Dec 03 08:20:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 08:20:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847306.1262398 (Exim 4.92) (envelope-from ) id 1tIO93-0007lP-Cd; Tue, 03 Dec 2024 08:20:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847306.1262398; Tue, 03 Dec 2024 08:20: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 1tIO93-0007lI-9a; Tue, 03 Dec 2024 08:20:33 +0000 Received: by outflank-mailman (input) for mailman id 847306; Tue, 03 Dec 2024 08:20: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 1tIO91-0007ic-Fv for xen-devel@lists.xen.org; Tue, 03 Dec 2024 08:20:31 +0000 Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [2a00:1450:4864:20::22a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 754d4705-b14f-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 09:20:30 +0100 (CET) Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2f7657f9f62so50500911fa.3 for ; Tue, 03 Dec 2024 00:20: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 4fb4d7f45d1cf-5d0b7ce5584sm4515835a12.54.2024.12.03.00.20.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Dec 2024 00:20: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: 754d4705-b14f-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733214029; x=1733818829; darn=lists.xen.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=nctq/kz5JcX7M5aYFszmAP6iR+je2UNnsZFVhkU1lYc=; b=Ha4WzPhkhXo3jneiCLoz0KOp0e+s8O9+I/BAKg2k10fi4IEXkFvyuQtgp9iywxNmwy 15Cmgl6h/8ItFmZyT+IUR82XNUKrOi0Al9DgLmZGtzACJlfwjc3K747so6a4q/VS4izo 7Ji686jqcZNp51N9AN0UJKTRfJHMBtUZ2tAe2OYAtNhfvBp5iTQ+cgCIDsXMNJcisxuH a4QHQeIu6eUXQvDB1ucZUS3hj8LlUwVM3MJWoHatkS7ZimHOa6jfdh2Sx/Ry5ryD0A84 maKqZHXrG8NSjo8uOcp5OeVrwwELbbpNxAzHFqp2cvPh6wca96XVZ1jZm6IohKBhlJVH k1Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733214029; x=1733818829; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nctq/kz5JcX7M5aYFszmAP6iR+je2UNnsZFVhkU1lYc=; b=uPpQ0hIRvqs4Q1ZzfWYylxlNB3/70DvYCFK1kknGed2sS1Oddr30OmhILAKTB/HtCt ib7oEm4Y8NHEjBnBDmyObZICDejOptlr8P+AsKB8B68jKdMqnc2eE+IWovvt3GsbevYg OoZNd1D9nF3imXk9Edj31HGKFipz4nbF2xdEyDKLxVoJckNFBdUi+ZiA92GycQvLao/R doYhRrhWhdms5SNetVLHNIKwz8HLoZQLDKcBe1oanWoumN6h3UzITrRfW0v8l4XWS1D8 KukTU9HqmBfQB3dd0ZrO9mFa0UqkMHMiCn3tZstQnuN73kOvQsS0+ZzLU45vDG5bzZU6 ux7g== X-Forwarded-Encrypted: i=1; AJvYcCWwtn11DBhanYf0B6FtKx2Hase4iP3TmT45IOupDj3x5crpv7MgKzYuUJqoyTXi9CradRH/BffFjTQ=@lists.xen.org X-Gm-Message-State: AOJu0YwSkqAqw2X79tkH1VXN1w4lwNwhupNnri/bGdd2WlgwH45gSnNH O1V1cC8ZoJDxVW5z8Oi5G8VLUnAKfiJBxjTAB7bcYYhOPkroWYdv3x19iIjY3g== X-Gm-Gg: ASbGncv7d8cz0OoL6LbBbKOYo6QTwDXvt9+OR453AcKc8n6vY2nnNorMEXo0WRcxx48 5880+YxlojikCZa+zgewgEwh/tVZfemOXJD9M/ReN8WYB8IBB7k+DNdZ8xlGeZIkphE2u5Wnq90 8ZU32XZkx/p/BspHVoqGiLZwOBoUcGVVokSK1JC6xQxrzK0/5Dquhn0VykgI97jtLCYC8e2Ihxy 9SQZSRsSBCe6jNmwyZ0aVV+cb5gXV14NmZ/JBl9A74HqSqzOKX3nO3qUDrd3W+BHrl2CfwMHdEv 4Yiba0i2oOaVyNSL10lwz/sge/fGASb085Y= X-Google-Smtp-Source: AGHT+IFllXZfN/kjblGorxONRg19GDBG3pXy1jTgrJpowm/fdpUyx2On2DYdHBLZsdaTbOCQOlnFrA== X-Received: by 2002:a2e:bcc1:0:b0:2ff:c3a2:f42d with SMTP id 38308e7fff4ca-30009c92be7mr8482261fa.30.1733214029345; Tue, 03 Dec 2024 00:20:29 -0800 (PST) Message-ID: <0cd6a440-6039-400f-a2aa-ed460a3878c1@suse.com> Date: Tue, 3 Dec 2024 09:20:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: stable-4.18: reliably crash network driver domain by squeezing free_memory To: James Dingwall Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xen.org References: <6614df33-e383-44dd-aebc-a238ad82f398@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: 7bit On 02.12.2024 16:54, James Dingwall wrote: > On Thu, Nov 28, 2024 at 03:39:07PM +0000, Andrew Cooper wrote: >> On 28/11/2024 3:31 pm, James Dingwall wrote: >>> Hi, >>> >>> We have reproducible issue with the current HEAD of the stable-4.18 branch >>> which crashes a network driver domain and on some hardware subsequently >>> results in a dom0 crash. >>> >>> `xl info` reports: free_memory : 39961, configuring a guest with >>> memory = 39800 and starting it gives the log as below. This is intel >>> hardware so if I've followed the code correctly I think this leads through >>> to intel_iommu_map_page() from drivers/passthrough/vtd/iommu.c. >>> >>> The expectation is that we can safely allocate up to free_memory for a >>> guest without any issue. Is there any extra logging we could enable to >>> gain more information? >> >> For this, you really should CC the x86 maintainers, or it stands a >> chance of getting missed. >> >> Do you have the complete serial log including boot and eventual crash ? >> >> -12 is -ENOMEM so something is wonky, and while dom2 is definitely dead >> at this point, Xen ought to be able to unwind cleanly and not take down >> dom0 too. >> >> ~Andrew > > > > I've attached complete serial console logs from an Intel and an AMD dom0 > which show similar behaviour. The dom0 crash originally mentioned was > resolved by updating a patch for OpenZFS issue #15140 and no longer > occurs. > > During the capture of the serial console logs I noted that: > > 1. If the order that the domains start is different then there is no crash. > Restarting the domain later will lead to the driver domain crash even > without a configuration change. > 2. If the domU memory is closer to free_memory but still less than the > domain fails to start with libxl reporting not enough memory. > > So there is some undefined range for (free_memory - m) to (free_memory - n) > where it is possible to crash the driver domain depending on the guest > startup ordering. My (perhaps naive) reasoning would be that > free_memory is the resource available to safely assign without having to > allow for some unknown overhead and if I do ask for too much then I > get a 'safe' failure. As per the earlier reply I sent, this isn't the case. "free_memory" isn't adjusted to account for extra overhead. As per Marek's reply, you need to leave some spare, at least as of how things are right now. Jan PS: I've dropped security@. We're now firmly into discussing this in public, irrespective of possible security angles. I don't think that's what should have happened, but it also makes no sense to further pretend to attempt to first assess the full scope in private. From xen-devel-bounces@lists.xenproject.org Tue Dec 03 08:22:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 08:22:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847297.1262426 (Exim 4.92) (envelope-from ) id 1tIOAa-0000Ag-PS; Tue, 03 Dec 2024 08:22:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847297.1262426; Tue, 03 Dec 2024 08:22:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIOAa-00008o-IK; Tue, 03 Dec 2024 08:22:08 +0000 Received: by outflank-mailman (input) for mailman id 847297; Tue, 03 Dec 2024 08:16: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 1tIO4r-0006fu-SC for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 08:16:13 +0000 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2062c.outbound.protection.outlook.com [2a01:111:f403:2417::62c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id db64af16-b14e-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 09:16:13 +0100 (CET) Received: from CH2PR14CA0031.namprd14.prod.outlook.com (2603:10b6:610:56::11) by DM4PR12MB6349.namprd12.prod.outlook.com (2603:10b6:8:a4::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 08:16:02 +0000 Received: from DS3PEPF0000C37D.namprd04.prod.outlook.com (2603:10b6:610:56:cafe::c7) by CH2PR14CA0031.outlook.office365.com (2603:10b6:610:56::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.18 via Frontend Transport; Tue, 3 Dec 2024 08:16:01 +0000 Received: from SATLEXMB04.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_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 08:16:01 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Tue, 3 Dec 2024 02:14:11 -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: db64af16-b14e-11ef-a0d3-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HBALj0iwWTZhtTNB4m/9IaArFm/7IEBRoyPCvWid9Jpm+/9v887vk86iyIwQHnGfc4surbZpPW7RQwhi4zXSvWR2pSH3bO8Izujlv9+LPOLMNJzK8mcHBHU6IFYo6GEn4ubTpZYc5k29zt2NGbWEP7QBsHwxr80l+XMRpiaitZquw7Tb9ZZe2AdMQUF0IOJ6kG6Q/3fEkpA8r8MmwigGEoWVXeqnYw78k1EC0aVr+N1Lk8AP801iwRsvzwDZLoIgwZg9398yo7BgWmIWTwNlgWvbC+iM86CweKbOSDxpxuVIWLNIAxqaD06t0P4/rNgQ8J4CAbwZv7fkI1PuB5xp7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4pMiDIbPnk4KOwi5Wnpl0tX4XgGePDycYMINNFX4f3E=; b=GbG+f9B45tkdX/A3tckiTDzs9iZoNlABvZS8TqPriJPZQh21EtKMS+RRU5nI0XYeo7TiF3IuglNnjHSEHU57CWIzLveCXcaQ+PA1PsYIWc5nNIEetzivR5kNl0XlQy3ASt1T0QKu0Xusrpv10GK+w7+KrBrKEN7SXojZHAP2KyTspnbE3w4qSzLTswX8Bxe5s7B17JGBDEMDxOU/dgSt02fxNkCZAXVUnugFfw4UNDo1b7on+6pNjhJ+K7FpsNU+vsw42JhbSM+/tbjb6ocjwMu2LF9tOM0MPaHAachSArDmr364qiGc6eZ+veztdXX0eqHKQfTBaaAmFcs+TfpC5g== 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=4pMiDIbPnk4KOwi5Wnpl0tX4XgGePDycYMINNFX4f3E=; b=R38U9L/Am/H3UX0uep6bS2+I13idinpEmZaapnzU2b1KqgUsW/pWJ4NW4LeJ4zcxc9ewaJL2yH7O/pXiYBK0ihYDanzr4IQiC01fDKvA/4DqeuJLhqEBAXsaBrwZMGR3eLA9XMv2rKQsW6YNeT0o1CIDnxZsk0SyBwLyq+rmfw8= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: CC: , , , , , Penny Zheng , Jan Beulich , "Andrew Cooper" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julien Grall , Stefano Stabellini Subject: [PATCH v1 02/11] xen/x86: introduce new sub-hypercall to get CPPC data Date: Tue, 3 Dec 2024 16:11:02 +0800 Message-ID: <20241203081111.463400-3-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241203081111.463400-1-Penny.Zheng@amd.com> References: <20241203081111.463400-1-Penny.Zheng@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS3PEPF0000C37D:EE_|DM4PR12MB6349:EE_ X-MS-Office365-Filtering-Correlation-Id: f22a0c5d-1264-48f6-502e-08dd1372b955 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|82310400026|36860700013; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?C1MmUL0CWsM/fCxiN1qGIpAMZpdzbSq3rotW9sVJ6X697RxD62RG/CN7VgBU?= =?us-ascii?Q?c6HMdzMymwahE/K9fyB0EpXgdnPEidzGmqRm+7vBz5EZ09bad6/+bSkeuK+s?= =?us-ascii?Q?olFbSEnLRduxQ3jE86I3ge+loVXUx4mpEiPjgykUQzCX6KxGjChFudcmlSA7?= =?us-ascii?Q?acyDcyw4K4vw5L+3j/W+1ZHbag4B2eNAsyHaq71mMkm8SodMTaiuMoxqBYiz?= =?us-ascii?Q?e/zRyfm2YiUUi2aUfC3CU78h6ZaOe5XCAHNBucTxVmpAaKJnW6F+xUIl9dDn?= =?us-ascii?Q?NAikNiqCxFABmvLAm7rnKMVeqQg8sHd5pnz4e1ieB1Yp5jJ4stqzNpwk/tM6?= =?us-ascii?Q?XXBJfm4oEL0Zyu7rwv77CDOVVV2Cqud0KfgxKYj7YGkTyuJMPcj3nBzFL4xF?= =?us-ascii?Q?D1YcxcCpS3dgix3grcAxY7eZU3fSRAJIyfkFGMKD8pmnK63jmV0skQJYrnmm?= =?us-ascii?Q?/+W5jt/lFsQGxoXOXrHp8i8NyvlCMX1cEvJuOnjzcdcpA2maNtQs+WRS249q?= =?us-ascii?Q?wFQh5iJGvC0aU/Mvm/oAdEqnrzfk1GIz1pB0OluSoqRUGunngSObhQj2r+7V?= =?us-ascii?Q?DiDARgpZKOqfMsSFAlesf8+jJZ3+fYAzskxAum4pEZyFjCLOMApGoLH020kU?= =?us-ascii?Q?Bb54Nb0HwOGa1JMCJtm2AF966qYu2d29f1VAuUQQeBEUY+jzf9bYtieEF09Z?= =?us-ascii?Q?5aYJDzgHJjzwgG8e1GIn9PUAigM6wOueT6b980YEJ76n7BB5DaUZDrPUFqYy?= =?us-ascii?Q?A1e9XVjyRtgohMWsw6rHy3ArgzxkM7BoTgxQlfuVtTFXd7o6Z5zvVJhKTmD0?= =?us-ascii?Q?KXeWoravLyljhu+29+2ftwVn3LhIYMpS6lXVhR1ReKYxBv2g0bDkX6bVELo6?= =?us-ascii?Q?cv09h/sBOhdaaRCpG9gL3Qy1on/PCOtD00nsTg6vDVGb+Ty16nVrpnugfAQS?= =?us-ascii?Q?CRbdoJ8tNJn9Ev1q2KSPZj2vm8e5eATHqbIUgCG4deHuSXjBU2kcuYAB5JCw?= =?us-ascii?Q?H67VPNkO+RzcmBhNhIlLQ2tJ/QIfBeAA41qkIJW0Of/tOVPVyhcroudjoqWG?= =?us-ascii?Q?E8AOsiJBR0DDeLdPMWmLDSo/rq4BbeK9kxxp2PJqko5gFX1K+EKw/6wsdrV5?= =?us-ascii?Q?+uAsYS/NuiPgctcF6jGXO6CXBak9X1rohtWXtNlDgjZSNoSJbhLNXYxcWeDn?= =?us-ascii?Q?O4sfKKtQspMnoP6bNWu30B33JJ86b+7/f7eauhFLCrqc8DQIBirQp41Iq3G4?= =?us-ascii?Q?BwcNNOrp/N4nyrLc1ta5BmM11GWokNiER+pOOj6w6QHFhUS8q0R48xmJ0C7A?= =?us-ascii?Q?ig93TCg36SuRJvsdoEegiiZwWetvfUVyZD2tBG/5tPR6R2m5P1drmPfANQ+X?= =?us-ascii?Q?uNA2eVLdPIdDxwyJgFEy0PFpap8cAwxtNWCko0KxH98w+JrOXohawthudo/X?= =?us-ascii?Q?fWAF1auOQn+aKuBPSed5AEddnVzWdauU?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 08:16:01.1960 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f22a0c5d-1264-48f6-502e-08dd1372b955 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=[SATLEXMB04.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: DM4PR12MB6349 In order to provide backward compatibility with existing governors that represent performance as frequencies, like ondemand, the _CPC table can optionally provide processor frequency range values, Lowest frequency and Norminal frequency, to let OS use Lowest Frequency/ Performance and Nominal Frequency/Performance as anchor points to create linear mapping of CPPC abstract performance to CPU frequency. As Xen is uncapable of parsing the ACPI dynamic table, this commit introduces a new sub-hypercall to get required CPPC data from dom0 kernel. Signed-off-by: Penny Zheng --- xen/arch/x86/platform_hypercall.c | 6 +++ xen/arch/x86/x86_64/cpufreq.c | 18 ++++++++ xen/arch/x86/x86_64/platform_hypercall.c | 3 ++ xen/drivers/cpufreq/cpufreq.c | 50 +++++++++++++++++++++++ xen/include/acpi/cpufreq/processor_perf.h | 1 + xen/include/public/platform.h | 11 +++++ xen/include/xen/pmstat.h | 3 ++ xen/include/xlat.lst | 1 + 8 files changed, 93 insertions(+) diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c index 67f851237d..917c395f58 100644 --- a/xen/arch/x86/platform_hypercall.c +++ b/xen/arch/x86/platform_hypercall.c @@ -572,6 +572,12 @@ ret_t do_platform_op( break; } + case XEN_PM_CPPC: + { + ret = set_cppc_pminfo(op->u.set_pminfo.id, &op->u.set_pminfo.u.cppc_data); + } + break; + default: ret = -EINVAL; break; diff --git a/xen/arch/x86/x86_64/cpufreq.c b/xen/arch/x86/x86_64/cpufreq.c index e4f3d5b436..1aa10a5dbd 100644 --- a/xen/arch/x86/x86_64/cpufreq.c +++ b/xen/arch/x86/x86_64/cpufreq.c @@ -54,3 +54,21 @@ int compat_set_px_pminfo(uint32_t acpi_id, return set_px_pminfo(acpi_id, xen_perf); } + +int compat_set_cppc_pminfo(uint32_t acpi_id, + struct compat_processor_cppc *cppc_data) +{ + struct xen_processor_cppc *xen_cppc; + unsigned long xlat_page_current; + + xlat_malloc_init(xlat_page_current); + + xen_cppc = xlat_malloc_array(xlat_page_current, + struct xen_processor_cppc, 1); + if ( unlikely(xen_cppc == NULL) ) + return -EFAULT; + + XLAT_processor_cppc(xen_cppc, cppc_data); + + return set_cppc_pminfo(acpi_id, xen_cppc); +} diff --git a/xen/arch/x86/x86_64/platform_hypercall.c b/xen/arch/x86/x86_64/platform_hypercall.c index 9ab631c17f..8c28465b8e 100644 --- a/xen/arch/x86/x86_64/platform_hypercall.c +++ b/xen/arch/x86/x86_64/platform_hypercall.c @@ -20,6 +20,9 @@ EMIT_FILE; #define xen_processor_power compat_processor_power #define set_cx_pminfo compat_set_cx_pminfo +#define xen_processor_cppc compat_processor_cppc +#define set_cppc_pminfo compat_set_cppc_pminfo + #define xen_pf_pcpuinfo xenpf_pcpuinfo CHECK_pf_pcpuinfo; #undef xen_pf_pcpuinfo diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c index 4a103c6de9..3e3392da1b 100644 --- a/xen/drivers/cpufreq/cpufreq.c +++ b/xen/drivers/cpufreq/cpufreq.c @@ -458,6 +458,56 @@ static void print_PPC(unsigned int platform_limit) printk("\t_PPC: %d\n", platform_limit); } +static void print_CPPC(struct xen_processor_cppc *cppc_data) +{ + printk("\t_CPC: highest_perf=%u, lowest_perf=%u, " + "nominal_perf=%u, lowest_nonlinear_perf=%u, " + "nominal_freq=%uMhz, lowest_freq=%uMhz\n", + cppc_data->highest_perf, cppc_data->lowest_perf, + cppc_data->nominal_perf, cppc_data->lowest_nonlinear_perf, + cppc_data->nominal_freq, cppc_data->lowest_freq); +} + +int set_cppc_pminfo(uint32_t acpi_id, struct xen_processor_cppc *cppc_data) +{ + int ret = 0, cpuid; + struct processor_pminfo *pm_info; + + cpuid = get_cpu_id(acpi_id); + if ( cpuid < 0 || !cppc_data ) + { + ret = -EINVAL; + goto out; + } + if ( cpufreq_verbose ) + printk("Set CPU acpi_id(%d) cpuid(%d) CPPC State info:\n", + acpi_id, cpuid); + + pm_info = processor_pminfo[cpuid]; + if ( !pm_info ) + { + pm_info = xzalloc(struct processor_pminfo); + if ( !pm_info ) + { + ret = -ENOMEM; + goto out; + } + processor_pminfo[cpuid] = pm_info; + } + pm_info->acpi_id = acpi_id; + pm_info->id = cpuid; + + memcpy ((void *)&pm_info->cppc_data, + (void *)cppc_data, + sizeof(struct xen_processor_cppc)); + + if ( cpufreq_verbose ) + print_CPPC(&pm_info->cppc_data); + + out: + return ret; +} + int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *perf) { int ret = 0, cpu; diff --git a/xen/include/acpi/cpufreq/processor_perf.h b/xen/include/acpi/cpufreq/processor_perf.h index 301104e16f..cfa0fed647 100644 --- a/xen/include/acpi/cpufreq/processor_perf.h +++ b/xen/include/acpi/cpufreq/processor_perf.h @@ -37,6 +37,7 @@ struct processor_pminfo { uint32_t acpi_id; uint32_t id; struct processor_performance perf; + struct xen_processor_cppc cppc_data; }; extern struct processor_pminfo *processor_pminfo[NR_CPUS]; diff --git a/xen/include/public/platform.h b/xen/include/public/platform.h index 2725b8d104..be1cf9a12f 100644 --- a/xen/include/public/platform.h +++ b/xen/include/public/platform.h @@ -363,6 +363,7 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_getidletime_t); #define XEN_PM_PX 1 #define XEN_PM_TX 2 #define XEN_PM_PDC 3 +#define XEN_PM_CPPC 4 /* Px sub info type */ #define XEN_PX_PCT 1 @@ -432,6 +433,15 @@ struct xen_processor_px { typedef struct xen_processor_px xen_processor_px_t; DEFINE_XEN_GUEST_HANDLE(xen_processor_px_t); +struct xen_processor_cppc { + uint32_t highest_perf; + uint32_t nominal_perf; + uint32_t lowest_perf; + uint32_t lowest_nonlinear_perf; + uint32_t lowest_freq; + uint32_t nominal_freq; +}; + struct xen_psd_package { uint64_t num_entries; uint64_t revision; @@ -465,6 +475,7 @@ struct xenpf_set_processor_pminfo { struct xen_processor_power power;/* Cx: _CST/_CSD */ struct xen_processor_performance perf; /* Px: _PPC/_PCT/_PSS/_PSD */ XEN_GUEST_HANDLE(uint32) pdc; /* _PDC */ + struct xen_processor_cppc cppc_data; /*_CPC */ } u; }; typedef struct xenpf_set_processor_pminfo xenpf_set_processor_pminfo_t; diff --git a/xen/include/xen/pmstat.h b/xen/include/xen/pmstat.h index 8350403e95..7b73b123aa 100644 --- a/xen/include/xen/pmstat.h +++ b/xen/include/xen/pmstat.h @@ -5,6 +5,7 @@ #include /* for struct xen_processor_power */ #include /* for struct pm_cx_stat */ +int set_cppc_pminfo(uint32_t cpu, struct xen_processor_cppc *cppc_data); int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance *perf); long set_cx_pminfo(uint32_t acpi_id, struct xen_processor_power *power); @@ -13,6 +14,8 @@ struct compat_processor_performance; int compat_set_px_pminfo(uint32_t acpi_id, struct compat_processor_performance *perf); struct compat_processor_power; long compat_set_cx_pminfo(uint32_t acpi_id, struct compat_processor_power *power); +struct compat_processor_cppc; +int compat_set_cppc_pminfo(uint32_t acpi_id, struct compat_processor_cppc *cppc); #endif uint32_t pmstat_get_cx_nr(unsigned int cpu); diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst index 2046b36c04..cdd0340c5e 100644 --- a/xen/include/xlat.lst +++ b/xen/include/xlat.lst @@ -166,6 +166,7 @@ ! processor_cx platform.h ! processor_flags platform.h ! processor_performance platform.h +! processor_cppc platform.h ! processor_power platform.h ? processor_px platform.h ! psd_package platform.h -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 08:22:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 08:22:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847290.1262407 (Exim 4.92) (envelope-from ) id 1tIOAZ-0008MV-SD; Tue, 03 Dec 2024 08:22:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847290.1262407; Tue, 03 Dec 2024 08:22: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 1tIOAZ-0008MO-Pi; Tue, 03 Dec 2024 08:22:07 +0000 Received: by outflank-mailman (input) for mailman id 847290; Tue, 03 Dec 2024 08:14: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 1tIO32-0006dX-Ju for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 08:14:20 +0000 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on20608.outbound.protection.outlook.com [2a01:111:f403:2414::608]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9819adca-b14e-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 09:14:19 +0100 (CET) Received: from BN9P221CA0012.NAMP221.PROD.OUTLOOK.COM (2603:10b6:408:10a::7) by SN7PR12MB8818.namprd12.prod.outlook.com (2603:10b6:806:34b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 08:14:13 +0000 Received: from BN3PEPF0000B06C.namprd21.prod.outlook.com (2603:10b6:408:10a:cafe::3b) by BN9P221CA0012.outlook.office365.com (2603:10b6:408:10a::7) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.18 via Frontend Transport; Tue, 3 Dec 2024 08:14:13 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by BN3PEPF0000B06C.mail.protection.outlook.com (10.167.243.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8251.1 via Frontend Transport; Tue, 3 Dec 2024 08:14:13 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Tue, 3 Dec 2024 02:11:28 -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: 9819adca-b14e-11ef-a0d3-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=W/kZ9Joc87vuAm1mqEjUhAqu7vQSfyLUoD/o4/CnKCJ3/VEhHJM87UFgbMraxZSoMMyT+pSEoZzyiH/kCCvBQyfnzmyTTaW1ltXvMyme4G+uYK5qo/+BSqhp2v+54M9tCVWHdLqDHl5SDZtCgp6pEhLCFVYhkJq+hA7n4WoGioG89urvekrwOOhBJNdd9BLfLKnphkzK4r255DMokh7/qjhEFLjhrbruWxOxoML+8BWwl6Vc0VrhXlVj3K/jwOwuztvUaY59Qxew0Ayx8KCdgByxH4D/yy5vvOn7U+9xZUwmh3NbITJCkxtBoADLg8oWdx0XF7IdkX2wg6mJhKM+tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2LbG/8IIub4wmb2kCfj2ltWzhRP860ymQnZzHFTwDL8=; b=V96EQabQaaFuFLUpJ2I6N15R8PXVpzoRuGuB78ZKZrug15quF4oZ3hCv/B3X9bBIFnoi4oVvDl4V6rRWIgFAfYUYzKAQlYNLDtW0xo+8BpLfl2N6VKnlhrptuzGUp/f0lGmYa3KdjDSP3KKxjFySbcBj85DCbqsFOAJqmEOzK3JQ6ZnHSQPHqxB6Eg836KuoZqW15m0P92JKt9JUjofz7yCVp6GIuC4sFzqfKNoEi5oSqU8FKdkL2cFQ6o3JOt+PDGIQffdDdt7h1VuG9nI++dTGmQqnadk57+7yLbXttUW9OtAHge+q/r2BlphyBFMjwir0HRJOVkQlWRx3cwLp3Q== 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=2LbG/8IIub4wmb2kCfj2ltWzhRP860ymQnZzHFTwDL8=; b=UP5XWTPgPImhhfxUoxCDEio0ZX2qljd5toiAl3z4mU6LcoGwecu9Vd+HGXwGZZv5iQMkduSLM72thvpctOkhD3nCBO6aIa0eoBP3ES8PSDPk5G8KChF65IbCL/lfdWryYZ07br/p9/DpnRit20ZG35RB0rhBmXWZYSWXfuK4A18= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: CC: , , , , , Penny Zheng , Jan Beulich , "Andrew Cooper" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julien Grall , Stefano Stabellini , Anthony PERARD Subject: [PATCH v1 00/11] amd-pstate CPU Performance Scaling Driver Date: Tue, 3 Dec 2024 16:11:00 +0800 Message-ID: <20241203081111.463400-1-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF0000B06C:EE_|SN7PR12MB8818:EE_ X-MS-Office365-Filtering-Correlation-Id: 9463a888-a7f4-4bb1-efb0-08dd13727905 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?ClctKpYGuSar7O7AsGCs74lfRQ8NY1TtyiZ/0TPuTp3Ip4IoFLpnP+KUBz3w?= =?us-ascii?Q?8o8hHwpBRiIl6lqecgSPAnM/vArcvf0mGS/aN84YysgwD6zbLJe+IFID7yoe?= =?us-ascii?Q?ikGNeWr7D8HtjXBwY68j0Xsz7TXD1buE7tHNl3yEVYpIh5CZeRbFzeHs6SvN?= =?us-ascii?Q?WmIDpGJpGKXG+DqrpruYMJIRkNFZTs3v5jz2+nC+KAPllUo6AsowCkVXVvEq?= =?us-ascii?Q?Kag6PC+TKlTJZtjohKU2H0eALuCIp+uMkLqWq+wguZbpWbv0yUjhdDB5shFm?= =?us-ascii?Q?R1toRBDbE5HqkEevSMZV4/TTNYZalY1HJFxsxLemt9rXPm3knSNJpJjCHaF0?= =?us-ascii?Q?9UCphKYVYm2ymdgbK9Mywy6lGX/WvvvwkmBnB5m/IVJNSLpT+py9gBRZcXOf?= =?us-ascii?Q?KupTEOy0mIToHIQ979xThP8q4SLQPsLETMtBztAlOdi4scjUjUtP5wwGb+dO?= =?us-ascii?Q?yViQr8y+cIpV6bNOlhvU5XShDfIO8oBr1XCT8tYW88C0xn+UKeBB1RakwTCR?= =?us-ascii?Q?XCFBE2++aDMs6XCVjivDWDoX3lnQ9SeIrcZ0c7oJddgZYLdJm5QTmXUVc+cg?= =?us-ascii?Q?RqdD1IZmj3aKPgkl57Kug3vyTH34PPBBbepVH0Tou4cvcQT3XPkWzqYR0rLj?= =?us-ascii?Q?psp+8ZnjPmCaPayoW4Wd+fPRcQ/2BNSfquESWHEHiJ4o/yAsTy1SwCl/LkxE?= =?us-ascii?Q?dXCH8ZIuGn4IY10eBrNPR0brwMGA2AZNEtGjO9owZqpNku413BYACHJeY+tk?= =?us-ascii?Q?ENgKUlUebUneb4Mu4lShQTTb2Ehk559oZadex3OLhIrQpdrfyTOczmE8PB3c?= =?us-ascii?Q?plYkoXR5/xBqnz0oz78z5DBtikdF5uiZCe/Y+RrSS2HeGXUdl8BQChUgjKuc?= =?us-ascii?Q?9AHlSHpupC9HlpizOL5TO96Z4vH+Fm+cl5+M5a7OrBOTo+qNP1MObUVqZ3yF?= =?us-ascii?Q?PCUpN6OMQYPL0ZtqDLQEy6F8rOOfJUwLgCGYOj6TGWoxRMvh5XriiagOBq0y?= =?us-ascii?Q?fXnSgxuRoNKgBEbdiB3CWuuaJDnlrzVPpXyqCq1xB6xaOEwZhBc9UYYufDq/?= =?us-ascii?Q?OXl2wW+KiAgRqVv7M9HxAZ2WmaPIUqkdqxmaL3czu38Tk4ISDHp+OJmKQstk?= =?us-ascii?Q?F5grvLQGcvm9baa7FhFk1DHbcwaK3jbb1awrlvh8IKW0M4xo2/kwbRB3dCnj?= =?us-ascii?Q?ZxJTFOhgtjMThYQxhQJuP+JNvGexGT9j5+Ne9H6SfCJhzuIsTVoZPlGml3I5?= =?us-ascii?Q?Ple7F7Im6RpqvQdBJGBCvZx4do1vOj87RPYfo/rSACkXk+tSd6fIG4dm9+Qv?= =?us-ascii?Q?tT4MzjNhnibxxmK9XHzHlqM8C3yqU0OJjp0ngi3XS+TllAcYC4RwyTPoLKST?= =?us-ascii?Q?a+BFEBcyAR5ABZbSF0phTJPAyG9SzT8Zy2kUaKVWL2/OUR21CW8iIjOF1Al6?= =?us-ascii?Q?+hKhj3UJqd8RdQIdWeQhvXmriqhKmzAX?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 08:14:13.3329 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9463a888-a7f4-4bb1-efb0-08dd13727905 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN3PEPF0000B06C.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8818 amd-pstate is the AMD CPU performance scaling driver that introduces a new CPU frequency control mechanism on modern AMD APU and CPU series in Xen. The new mechanism is based on Collaborative Processor Performance Control (CPPC) which provides finer grain frequency management than legacy ACPI hardware P-States. Current AMD CPU/APU platforms are using the ACPI P-states driver to manage CPU frequency and clocks with switching only in 3 P-states. CPPC replaces the ACPI P-states controls and allows a flexible, low-latency interface for Xen to directly communicate the performance hints to hardware. amd_pstate CPPC has 2 operation modes: autonomous (active) mode, and non-autonomous (passive) mode. We register different CPUFreq driver for different modes, "amd-pstate" for passive mode and "amd-pstate-epp" for active mode. The passive mode leverages common governors such as *ondemand*, *performance*, etc, to manage the performance hints. And the active mode uses epp to provides a hint to the hardware if software wants to bias toward performance (0x0) or energy efficiency (0xff). CPPC power algorithm will calculate the runtime workload and adjust the realtime cpu cores frequency according to the power supply and thermal, core voltage and some other hardware conditions. amd-pstate is enabled with a top-level cpufreq=amd-pstate option. It will fallback to cpufreq=xen if amd-pstate is unavailable. With `cpufreq=amd-pstate,active`, We did a 60s sampling test to see the CPU frequency change, through tweaking the energy_perf preference from `xenpm set-cpufreq-cppc powersave` to `xenpm set-cpufreq-cppc performance`. The outputs are as follows: ``` Setting CPU in powersave mode Sampling and Outputs: Avg freq 2000000 KHz Avg freq 2000000 KHz Avg freq 2000000 KHz Setting CPU in performance mode Sampling and Outputs: Avg freq 4640000 KHz Avg freq 4220000 KHz Avg freq 4640000 KHz ``` Penny Zheng (11): xen/x86: add CPPC feature flag for AMD processors xen/x86: introduce new sub-hypercall to get CPPC data xen/x86: introduce "cpufreq=amd-pstate" xen cmdline xen/x86: get processor max speed from DMI table xen/x86: introduce a new amd pstate driver for cpufreq scaling xen/cpufreq: introduce policy type when cpufreq_driver->setpolicy exists xen/cpufreq: only set gov NULL when cpufreq_driver.target() exists x86/cpufreq: add "cpufreq=amd-pstate,active" para xen/x86: implement EPP support for the AMD processors tools/xenpm: Print CPPC parameters for amd-pstate driver xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC xen_sysctl_pm_op for amd-pstate driver docs/misc/xen-command-line.pandoc | 15 +- tools/misc/xenpm.c | 19 +- xen/arch/x86/acpi/cpufreq/Makefile | 1 + xen/arch/x86/acpi/cpufreq/amd-pstate.c | 641 ++++++++++++++++++++ xen/arch/x86/acpi/cpufreq/cpufreq.c | 28 + xen/arch/x86/acpi/cpufreq/hwp.c | 10 +- xen/arch/x86/dmi_scan.c | 19 + xen/arch/x86/include/asm/cpufeature.h | 1 + xen/arch/x86/include/asm/msr-index.h | 5 + xen/arch/x86/platform_hypercall.c | 12 + xen/arch/x86/x86_64/cpufreq.c | 18 + xen/arch/x86/x86_64/platform_hypercall.c | 3 + xen/drivers/acpi/pmstat.c | 24 +- xen/drivers/cpufreq/cpufreq.c | 71 ++- xen/drivers/cpufreq/utility.c | 11 + xen/include/acpi/cpufreq/cpufreq.h | 27 + xen/include/acpi/cpufreq/processor_perf.h | 1 + xen/include/public/arch-x86/cpufeatureset.h | 1 + xen/include/public/platform.h | 12 + xen/include/public/sysctl.h | 3 +- xen/include/xen/dmi.h | 5 + xen/include/xen/pmstat.h | 3 + xen/include/xlat.lst | 1 + 23 files changed, 910 insertions(+), 21 deletions(-) create mode 100644 xen/arch/x86/acpi/cpufreq/amd-pstate.c -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 08:22:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 08:22:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847295.1262419 (Exim 4.92) (envelope-from ) id 1tIOAa-0008Vt-Dg; Tue, 03 Dec 2024 08:22:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847295.1262419; Tue, 03 Dec 2024 08:22:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIOAa-0008Ti-82; Tue, 03 Dec 2024 08:22:08 +0000 Received: by outflank-mailman (input) for mailman id 847295; Tue, 03 Dec 2024 08:16: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 1tIO4o-0006fu-MQ for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 08:16:10 +0000 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam02on20627.outbound.protection.outlook.com [2a01:111:f403:2407::627]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id da0c5593-b14e-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 09:16:09 +0100 (CET) Received: from SJ0PR03CA0286.namprd03.prod.outlook.com (2603:10b6:a03:39e::21) by SJ2PR12MB8011.namprd12.prod.outlook.com (2603:10b6:a03:4c8::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 08:16:03 +0000 Received: from SJ1PEPF000023D7.namprd21.prod.outlook.com (2603:10b6:a03:39e:cafe::f8) by SJ0PR03CA0286.outlook.office365.com (2603:10b6:a03:39e::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.17 via Frontend Transport; Tue, 3 Dec 2024 08:16:03 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SJ1PEPF000023D7.mail.protection.outlook.com (10.167.244.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8251.1 via Frontend Transport; Tue, 3 Dec 2024 08:16:02 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Tue, 3 Dec 2024 02:14:14 -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: da0c5593-b14e-11ef-a0d3-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vVM3oDCloDBqgDVKKele4GT3DsRnDok19kzN1mH7IY3YPBK00FQYqlzlJZEo4hP3f7/ge/woPk/Pu3La6sy/j0murCatKbI0/w+05PHdNjAxrQ68W26AreCMK/vVk238SnZFFzjsYEhkzSqYsRENnDG7svGBWC4gY3t7U5VE7RE22RO7l45HRFEcq1rG2Rk6OGX4hjkD2vlh0GG63ypF40EXvUoZwLUxogfMRyRwU1q+HDlQ+LcCpTHeKyCO/bGRwszs3uRAteX3hrZCI50A92RawTLuS/P3gO5kEsYsqe+CS/mRhdOXWkLNS2f1kXeYz+d3H7sbAsTHwwMet7lDig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PILZWKdkihFFteMi5h8IOZU28qV1Ey6rbX7QWWPukOs=; b=xT7dqwlV3Y+XxgrPzCiiEziuUQxRoyuaaNkSZqOGx49+YodklClHrB9ITeO+4bn9lLHoR5vfZvGDJaaBzPfJdNzkpJi2a3Rt86exiROAE3jrEM3QS09VU1at4OzZkC2AsSuKoh6yy8dkI6NPkz+UgSy+NEFKAfVrHm0kCJEMMjXkcko3q/w6xh5T9YlQbZCNlcZQVJwsCNdXxQ+24l2TKbiW01tK1Z9noWb7E+2BCtzr24qC0/cZUXczp/hUDKaejgWl3ZDcsXV+TD53u5RQxv2LyuFqYDleEUmyC3ILhmnpgaax52rjgIklMcM4liiakJn43c/1S2LQ5EKHTTFK7Q== 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=PILZWKdkihFFteMi5h8IOZU28qV1Ey6rbX7QWWPukOs=; b=j8YPzI9Ic2UvZvcbdK5qH+2+L0JQ2QNiz88ruYnCpzG2sly8Z5mxV5Xb7krbx3NX7TxoNE2usWnSOVh5r7srSVsHc+wdVkMw9u8tH8NflMbhPp6rGSXRf1bcmiQBpN6Q4dDcSq2sTbu8b182WJCPBTdA/YMOtYz/hdFMeECHXQY= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: CC: , , , , , Penny Zheng , Andrew Cooper , Jan Beulich , Julien Grall , "Stefano Stabellini" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v1 03/11] xen/x86: introduce "cpufreq=amd-pstate" xen cmdline Date: Tue, 3 Dec 2024 16:11:03 +0800 Message-ID: <20241203081111.463400-4-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241203081111.463400-1-Penny.Zheng@amd.com> References: <20241203081111.463400-1-Penny.Zheng@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF000023D7:EE_|SJ2PR12MB8011:EE_ X-MS-Office365-Filtering-Correlation-Id: cafe7023-9793-4283-487c-08dd1372ba6b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?kXM6P0AW2VHLYsNaPYRCiV4ovXKoJp9gsiDh2nPdSsL/D6G8ZO89jjOCZ3nO?= =?us-ascii?Q?qqXm1RldBgWP2bIP0eQbiSDsWw+dMkrg5ZFO+D9TSovAyV0sY9TN8nSV4Me+?= =?us-ascii?Q?hQ7zjvExUjixzjCxHRExO/cQ8N9X/YyJPKjfUbB+Qod/A8KUhgnmFgn8YjSZ?= =?us-ascii?Q?AdmBEoKXj1DDX/B9Q6S5HpNvb3ATnnqXNjZ73nV1pR8yTdVDbvPTymBbU5mw?= =?us-ascii?Q?X1tH9ma9yuKbAACRgdfdGeJV+RJM4wJsuHohEATeIFoj9Z8n9ShOGyMaCrDr?= =?us-ascii?Q?s6WEeeHRdRX8qUgFleb9kILS78MkZu8i/pxKQ3yv6J30V072tBcydx3BtGXH?= =?us-ascii?Q?VaL44w9SiY9mFzsv3zzlTT+WkwFWNPYbAAIGpPfYCW4sJTr+AfvJ9yAQGF/i?= =?us-ascii?Q?IT2dYt4GLnOpOFbcmCQXQtEqp+KZuYU/CsH1HL6qO8KPnGVxHRKGIn0VzqD8?= =?us-ascii?Q?sDbKfgkOM0OtstSLdIMaTDQjuZGJeXD/GFOjJyQE3BOq2UUbgDU1TZWz4/RR?= =?us-ascii?Q?6FQKlC1eowxDwBNNvU4AVXpw0+gfC/cvjvHiff2zv1fvx5WQDvxtR0Th0YQJ?= =?us-ascii?Q?FKLbhXNFidRx/INEoMEYTRJblqIpCGLxp+cUEEmKklFAh3tAGsLTMYLiJyz5?= =?us-ascii?Q?tcai8DdQYuHednQIwxb1sMJr8AL9t32qrVmpLRkah1/lZcniwyDCvDj1SQDV?= =?us-ascii?Q?wa8gAM8nl3QaqknOv7ul1ynY0MrgselDueWNluVdPuJ9v9gZjXYtdQpDl+e3?= =?us-ascii?Q?e0+YQOjXco6Oe+spBqZef05RprbLcUaYt7UpxqNx55rrk48AETPt8r3io3T6?= =?us-ascii?Q?RZj6S8iygQq2ZoY8tEfZ09shSMt3SRhtIcasn8xvzkPjsteBhjKAsPXIUlOW?= =?us-ascii?Q?SRkMjko8ng0ESs1GiIsTN06emMwgd/ri5e67kVwlp//4SxIhetOM9Qf/KCCM?= =?us-ascii?Q?imOpwI+NxcIc0NiblDTBFJFgdEUmKwkX1/BESS1YJrGA/HQ3xrFgHRVr2pBk?= =?us-ascii?Q?9Vxv57fHQY6nyI+nr4hACleWA6TANYfpm0wkITyMyOThtSKx+yDv9iLzJREJ?= =?us-ascii?Q?5p4Hv+WwlHi6bbgzZGfgm3GHGJSBinpCt7or3DZiIBNR5LFRvCOdrEKuIS7y?= =?us-ascii?Q?kdQdjMljjn6MlPiVa/1x40NlIZ1xy970PYayO9QeJT2gu7aXdwnWs+dyxzxI?= =?us-ascii?Q?OcqKpIaX3rT4uuixGVclyCBw7p3iIXWgpHD+rqF1xI71288QpMB3gInV+zGO?= =?us-ascii?Q?3flp528fTeKKnL3y87tvhuAwJpvc8YyKbVoQf4ZxddyN5JKVVHDw0S5vPfCW?= =?us-ascii?Q?hx/1WjPwlcQPbJTN5CYp33yNXSIRuK1VHy7Q6r+X72XP3kD4oPDxgG3Tid4L?= =?us-ascii?Q?8T2yd++niAte2ZE+p0zsUdiu41orOszopY6pNvhU2Gspj7dogmh+RX/xQQnD?= =?us-ascii?Q?gmka8pzmBGyZXEl29quUFTKiYsarfUfg?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 08:16:02.9708 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cafe7023-9793-4283-487c-08dd1372ba6b 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF000023D7.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8011 Users need to set "cpufreq=amd-pstate" in xen cmdline to enable amd-pstate driver, which selects ACPI Collaborative Performance and Power Control (CPPC) on supported AMD hardware to provide a finer grained frequency control mechanism. `verbose` option can also be included to support verbose print. When users setting "cpufreq=amd-pstate", a new amd-pstate driver shall be registered and used. Actual implmentation will be introduced in the following commits. Signed-off-by: Penny Zheng --- docs/misc/xen-command-line.pandoc | 8 +++- xen/arch/x86/acpi/cpufreq/Makefile | 1 + xen/arch/x86/acpi/cpufreq/amd-pstate.c | 66 ++++++++++++++++++++++++++ xen/arch/x86/acpi/cpufreq/cpufreq.c | 28 +++++++++++ xen/arch/x86/platform_hypercall.c | 6 +++ xen/drivers/cpufreq/cpufreq.c | 13 ++++- xen/include/acpi/cpufreq/cpufreq.h | 4 ++ xen/include/public/platform.h | 1 + xen/include/public/sysctl.h | 1 + 9 files changed, 124 insertions(+), 4 deletions(-) create mode 100644 xen/arch/x86/acpi/cpufreq/amd-pstate.c diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 293dbc1a95..30f855fa18 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -499,7 +499,7 @@ If set, force use of the performance counters for oprofile, rather than detectin available support. ### cpufreq -> `= none | {{ | xen } { [:[powersave|performance|ondemand|userspace][,[]][,[]]] } [,verbose]} | dom0-kernel | hwp[:[][,verbose]]` +> `= none | {{ | xen } { [:[powersave|performance|ondemand|userspace][,[]][,[]]] } [,verbose]} | dom0-kernel | hwp[:[][,verbose]] | amd-pstate[:[verbose]]` > Default: `xen` @@ -510,7 +510,7 @@ choice of `dom0-kernel` is deprecated and not supported by all Dom0 kernels. * `` and `` are integers which represent max and min processor frequencies respectively. * `verbose` option can be included as a string or also as `verbose=` - for `xen`. It is a boolean for `hwp`. + for `xen`. It is a boolean for `hwp` and `amd-pstate`. * `hwp` selects Hardware-Controlled Performance States (HWP) on supported Intel hardware. HWP is a Skylake+ feature which provides better CPU power management. The default is disabled. If `hwp` is selected, but hardware @@ -518,6 +518,10 @@ choice of `dom0-kernel` is deprecated and not supported by all Dom0 kernels. * `` is a boolean to enable Hardware Duty Cycling (HDC). HDC enables the processor to autonomously force physical package components into idle state. The default is enabled, but the option only applies when `hwp` is enabled. +* `amd-pstate` selects ACPI Collaborative Performance and Power Control (CPPC) + on supported AMD hardware to provide a finer grained frequency control mechanism. + The default is disabled. If `amd-pstate` is selected, but hardware support + is not available, Xen will fallback to cpufreq=xen. There is also support for `;`-separated fallback options: `cpufreq=hwp;xen,verbose`. This first tries `hwp` and falls back to `xen` if diff --git a/xen/arch/x86/acpi/cpufreq/Makefile b/xen/arch/x86/acpi/cpufreq/Makefile index e7dbe434a8..1710fc776c 100644 --- a/xen/arch/x86/acpi/cpufreq/Makefile +++ b/xen/arch/x86/acpi/cpufreq/Makefile @@ -1,4 +1,5 @@ obj-$(CONFIG_INTEL) += acpi.o obj-y += cpufreq.o +obj-y += amd-pstate.o obj-$(CONFIG_INTEL) += hwp.o obj-$(CONFIG_AMD) += powernow.o diff --git a/xen/arch/x86/acpi/cpufreq/amd-pstate.c b/xen/arch/x86/acpi/cpufreq/amd-pstate.c new file mode 100644 index 0000000000..bfad96ae3d --- /dev/null +++ b/xen/arch/x86/acpi/cpufreq/amd-pstate.c @@ -0,0 +1,66 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * amd-pstate.c - AMD Processor P-state Frequency Driver + * + * Copyright (C) 2024 Advanced Micro Devices, Inc. All Rights Reserved. + * + * Author: Penny Zheng + * + * AMD P-State introduces a new CPU performance scaling design for AMD + * processors using the ACPI Collaborative Performance and Power Control (CPPC) + * feature which provides a finer grained frequency control range. + * + */ + +#include +#include +#include + +uint16_t __read_mostly dmi_max_speed_mhz; + +static bool __init amd_pstate_handle_option(const char *s, const char *end) +{ + int ret; + + ret = parse_boolean("verbose", s, end); + if ( ret >= 0 ) + { + cpufreq_verbose = ret; + return true; + } + + return false; +} + +int __init amd_pstate_cmdline_parse(const char *s, const char *e) +{ + do + { + const char *end = strpbrk(s, ",;"); + + if ( !amd_pstate_handle_option(s, end) ) + { + printk(XENLOG_WARNING "cpufreq/amd-pstate: option '%.*s' not recognized\n", + (int)((end ?: e) - s), s); + + return -EINVAL; + } + + s = end ? ++end : end; + } while ( s && s < e ); + + return 0; +} + +static const struct cpufreq_driver __initconstrel amd_pstate_cpufreq_driver = +{ + .name = XEN_AMD_PSTATE_DRIVER_NAME, +}; + +int __init amd_pstate_register_driver(void) +{ + if ( !cpu_has_cppc ) + return -ENODEV; + + return cpufreq_register_driver(&amd_pstate_cpufreq_driver); +} diff --git a/xen/arch/x86/acpi/cpufreq/cpufreq.c b/xen/arch/x86/acpi/cpufreq/cpufreq.c index 61e98b67bd..a461cfc7b3 100644 --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c @@ -148,6 +148,9 @@ static int __init cf_check cpufreq_driver_init(void) case CPUFREQ_none: ret = 0; break; + default: + printk(XENLOG_WARNING "Unsupported cpufreq driver for vendor Intel\n"); + break; } if ( ret != -ENODEV ) @@ -156,6 +159,31 @@ static int __init cf_check cpufreq_driver_init(void) break; case X86_VENDOR_AMD: + ret = -ENOENT; + + for ( unsigned int i = 0; i < cpufreq_xen_cnt; i++ ) + { + switch ( cpufreq_xen_opts[i] ) + { + case CPUFREQ_xen: + ret = powernow_register_driver(); + break; + case CPUFREQ_amd_pstate: + ret = amd_pstate_register_driver(); + break; + case CPUFREQ_none: + ret = 0; + break; + default: + printk(XENLOG_WARNING "Unsupported cpufreq driver for vendor AMD\n"); + break; + } + + if ( ret != -ENODEV ) + break; + } + break; + case X86_VENDOR_HYGON: ret = IS_ENABLED(CONFIG_AMD) ? powernow_register_driver() : -ENODEV; break; diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c index 917c395f58..4720c30e7e 100644 --- a/xen/arch/x86/platform_hypercall.c +++ b/xen/arch/x86/platform_hypercall.c @@ -574,6 +574,12 @@ ret_t do_platform_op( case XEN_PM_CPPC: { + if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_CPPC) ) + { + ret = -ENOSYS; + break; + } + ret = set_cppc_pminfo(op->u.set_pminfo.id, &op->u.set_pminfo.u.cppc_data); } break; diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c index 3e3392da1b..54d554aa4f 100644 --- a/xen/drivers/cpufreq/cpufreq.c +++ b/xen/drivers/cpufreq/cpufreq.c @@ -84,7 +84,7 @@ static int __init cf_check setup_cpufreq_option(const char *str) if ( choice < 0 && !cmdline_strcmp(str, "dom0-kernel") ) { - xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX; + xen_processor_pmbits &= ~(XEN_PROCESSOR_PM_PX|XEN_PROCESSOR_PM_CPPC); cpufreq_controller = FREQCTL_dom0_kernel; opt_dom0_vcpus_pin = 1; return 0; @@ -92,7 +92,7 @@ static int __init cf_check setup_cpufreq_option(const char *str) if ( choice == 0 || !cmdline_strcmp(str, "none") ) { - xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX; + xen_processor_pmbits &= ~(XEN_PROCESSOR_PM_PX|XEN_PROCESSOR_PM_CPPC); cpufreq_controller = FREQCTL_none; return 0; } @@ -130,6 +130,15 @@ static int __init cf_check setup_cpufreq_option(const char *str) if ( arg[0] && arg[1] ) ret = hwp_cmdline_parse(arg + 1, end); } + else if ( choice < 0 && !cmdline_strcmp(str, "amd-pstate") ) + { + xen_processor_pmbits |= XEN_PROCESSOR_PM_CPPC; + cpufreq_controller = FREQCTL_xen; + cpufreq_xen_opts[cpufreq_xen_cnt++] = CPUFREQ_amd_pstate; + ret = 0; + if ( arg[0] && arg[1] ) + ret = amd_pstate_cmdline_parse(arg + 1, end); + } else ret = -EINVAL; diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h index 3f1b05a02e..71e8ca91f0 100644 --- a/xen/include/acpi/cpufreq/cpufreq.h +++ b/xen/include/acpi/cpufreq/cpufreq.h @@ -28,6 +28,7 @@ enum cpufreq_xen_opt { CPUFREQ_none, CPUFREQ_xen, CPUFREQ_hwp, + CPUFREQ_amd_pstate, }; extern enum cpufreq_xen_opt cpufreq_xen_opts[2]; extern unsigned int cpufreq_xen_cnt; @@ -267,4 +268,7 @@ int set_hwp_para(struct cpufreq_policy *policy, int acpi_cpufreq_register(void); +int amd_pstate_cmdline_parse(const char *s, const char *e); +int amd_pstate_register_driver(void); + #endif /* __XEN_CPUFREQ_PM_H__ */ diff --git a/xen/include/public/platform.h b/xen/include/public/platform.h index be1cf9a12f..ad942f1775 100644 --- a/xen/include/public/platform.h +++ b/xen/include/public/platform.h @@ -357,6 +357,7 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_getidletime_t); #define XEN_PROCESSOR_PM_CX 1 #define XEN_PROCESSOR_PM_PX 2 #define XEN_PROCESSOR_PM_TX 4 +#define XEN_PROCESSOR_PM_CPPC 8 /* cmd type */ #define XEN_PM_CX 0 diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h index b0fec271d3..df4f362681 100644 --- a/xen/include/public/sysctl.h +++ b/xen/include/public/sysctl.h @@ -424,6 +424,7 @@ struct xen_set_cppc_para { }; #define XEN_HWP_DRIVER_NAME "hwp" +#define XEN_AMD_PSTATE_DRIVER_NAME "amd-pstate" /* * cpufreq para name of this structure named -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 08:22:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 08:22:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847300.1262436 (Exim 4.92) (envelope-from ) id 1tIOAb-0000HU-6g; Tue, 03 Dec 2024 08:22:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847300.1262436; Tue, 03 Dec 2024 08:22: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 1tIOAa-0000FF-R6; Tue, 03 Dec 2024 08:22:08 +0000 Received: by outflank-mailman (input) for mailman id 847300; Tue, 03 Dec 2024 08:17: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 1tIO6Y-0006iL-Kv for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 08:17:58 +0000 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam04on20614.outbound.protection.outlook.com [2a01:111:f403:2409::614]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 18c32e9e-b14f-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 09:17:56 +0100 (CET) Received: from SJ2PR07CA0011.namprd07.prod.outlook.com (2603:10b6:a03:505::20) by LV8PR12MB9081.namprd12.prod.outlook.com (2603:10b6:408:188::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 08:17:52 +0000 Received: from SJ1PEPF000023D4.namprd21.prod.outlook.com (2603:10b6:a03:505:cafe::54) by SJ2PR07CA0011.outlook.office365.com (2603:10b6:a03:505::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.18 via Frontend Transport; Tue, 3 Dec 2024 08:17:51 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SJ1PEPF000023D4.mail.protection.outlook.com (10.167.244.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8251.1 via Frontend Transport; Tue, 3 Dec 2024 08:17:50 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Tue, 3 Dec 2024 02:15:14 -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: 18c32e9e-b14f-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RzRVv/8MQzO1pA2BcmN8CA7FPWGJDSWWIecgf1+X1DD2pNvTcDi+OTFpGLMBxps+XEBL3Q/JMHv8cXQpHD6Oap0KadkkOBOet0WqPrP8XWN2gyVkscLS/k+N3wSip8ouCiPzvIAOeLhl4oQEC8fXAiAP5ZXcrshQY/Hk9CRWX0/s0sWlLVTni0Js4MYBStw8wuK9Z7N6wc4gr8oLHSb7LVImITKzsemGlm4Yrv3jS1sslqvisyPzGXywTiHkxhWn9KOfIPA4UUVIhRYi3x2d+sVu5xwwtj2+m7cQqRZLeGwxsokKltI8rWlTm5A18+EZID3spKhDt7O9uAV4ZwEohw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=z0U8rdCyjQTujNhBIGlymmnhb0TRmAlHR3r/R+Vaoss=; b=jmwnFeEddpbPpWfiLDgpU6bE7AztxkU/+ojDLAOMIsUPerQpkmPXIxd6UQ2kEmEKt7jctl8Ep+sE6Rq/VYQPjekGGkfeLvHAdAgdLVU+/K1oMq11jm/F3pEnyJjHaSQ+RU0OFopWgokeJaNz+1glgk+0urCciJG9Yh4t7t/oUuZCG0+Jq+LgMt3WeWFhAXSHV55YxgRVw2AU1MjNm/vfgFdGnWbRfL5wZORmYxkSBw8I35f4MsHgr+Ql6Lk04nzmBsBA6ZxVweHx+TxxVhc7MglnNc1O8O2Zt88eKF7oWWSHv9jfg/1muvO1M8Ekh7WZAoFwAutap5rDsE03jJT8wg== 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=z0U8rdCyjQTujNhBIGlymmnhb0TRmAlHR3r/R+Vaoss=; b=ZIgXMDZ4FB0Pcyb4SxP5CbqrljaQlbJTpE5QXFvl9gIBC8/XeaohLJI9lY6Vd2tOEJahK2MFBILdq3O0zJP3Uo56GucfwTDykOhuBfwHrUHgvo87l21127ujTzRNaaU1m/sI/DI17qHGa95jl12i1/XswRPgPoQKwHPxTSD51zU= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: CC: , , , , , Penny Zheng , Jan Beulich , "Andrew Cooper" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julien Grall , Stefano Stabellini Subject: [PATCH v1 04/11] xen/x86: get processor max speed from DMI table Date: Tue, 3 Dec 2024 16:11:04 +0800 Message-ID: <20241203081111.463400-5-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241203081111.463400-1-Penny.Zheng@amd.com> References: <20241203081111.463400-1-Penny.Zheng@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF000023D4:EE_|LV8PR12MB9081:EE_ X-MS-Office365-Filtering-Correlation-Id: d5fed296-43bd-4d34-737d-08dd1372fab9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|36860700013|1800799024; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?IYLPJvog9Bsgq+YJ+0VMgfT8z4rPNAt2pXUer7CCY3NiuwAXQt453ApjQFIW?= =?us-ascii?Q?/7ND6ClnRHPuI7IgcYwxsAhz00RvLEA94LOqfqvU8upYq0Pzq3qYHQN9KSzI?= =?us-ascii?Q?SIR3xg5IaI+XMRf/KMOfloLlxYe7iiVHdfpnl+SNWr1cLuAqNBmZ6KNAT77I?= =?us-ascii?Q?uO0Zx+Y5HH/tibTVWtcV9t5MlL70tyEMY6jDiRP0x1sYFiXr8u+fMlyRMDgQ?= =?us-ascii?Q?CVhRoy516RNaOTHdz4SkzOrsV4n5QVONlBVs3TFTh9LZ4fbEGXR4DHqi5s6B?= =?us-ascii?Q?oNj8HrnAW3dPWGn3ucunMJ6XuuZ36PciXIRQSZ4YCcTHrPVeCz6dVi8mwunU?= =?us-ascii?Q?Gix7SXi122CHMcBXLJMAx2Oe34RIK1wtrsIoQFhK9VQlpX7c2GbYEPe42LSg?= =?us-ascii?Q?yComDBM9lePXA0T6qs5UKxJoP0IYQBrR+gT6e7boM4/UaP6lOku2AV+V3Dx0?= =?us-ascii?Q?LR1X49sfNBdD3o6++h0EUkp/YCc9igGb42XhvLJo6xP9xGzdVSvEkeS30Gim?= =?us-ascii?Q?nDSFvLRPQX9/8e3dq5r+UhIZC8f+mFe8VxUcNwUxDZqqKMYAIUzOqalgu0fh?= =?us-ascii?Q?9/OfMiteu/dqsZqmN6paBy2opRSd6TpjiVjQSYE95Egq4ao3B1VDR4e2vrza?= =?us-ascii?Q?J3/L0Sa0x034gw1h/1NNYAq1rOaUh0kre7YbiSzh6QTA9B/N0g/DS7M0AR1d?= =?us-ascii?Q?AeBNyeKNU2vib/PNhIVhaFB04fvsVpZ09fHsajG3sg88q/dGcxTg0A32IeVQ?= =?us-ascii?Q?d2x1APVPpszRD+odZiLLYP2Ra5dZ52FDSmdrg5Bcs1MdouMAQg4Y2uYchsPU?= =?us-ascii?Q?8yG4U28mpXrIm70SUYkso/JZJCduyjmRGi7+7jX1fgJ+28oQfWYas/u+yTEt?= =?us-ascii?Q?WfXlBLywcCsPCD4HvaIPEjdOO/LaYLr4wuVKh24OYcDGqyb0FPkMRg+hxHbt?= =?us-ascii?Q?A0stXpPpXRZKMeoqPgF25NNqSHt97uVrW0eBQjVXwJqWS6TzzSLczBk/XT/p?= =?us-ascii?Q?V0zhliIZ7Dji+s4morFV0rVtwao1volj9BYF+cThNjMkHGwYKpID9tcXqLGd?= =?us-ascii?Q?snSwcIKfF5tQ+mkEjBzKag+3fbCSNwxMWF5LvY6PqRc1as4LpRS63nidZhvt?= =?us-ascii?Q?J35JNUNJeEmTLm6fzHY2gdbh/XQEXBJDslFu7OesNON+830hRpZu6fDmlXhC?= =?us-ascii?Q?5lc5XNfxSxlJ8oQrpAuqV6MGM2Zf9523k9PVZE/gx+BfWdVuEor3CZHLGb1M?= =?us-ascii?Q?xCAqZ9x3GgRK/9KURiD7oIPhCdo4FHEeAPrDnqVcs0DkUIQD9s2a0j/z8AHH?= =?us-ascii?Q?1MFbuLOGQroVpXTzZ2GYO/kI9FLI38lG4pMBTMAMsZuq3msXLe0wufbhEFDs?= =?us-ascii?Q?RKsdTHJ4d2KSZoccuZKaucljysVZAy/C4cYBoqPcNllKy7Lkp3bXL7yb25tt?= =?us-ascii?Q?ryfNU50JXCtl0SE47GIavaZWbEZ7/YNe?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700013)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 08:17:50.8416 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d5fed296-43bd-4d34-737d-08dd1372fab9 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF000023D4.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9081 When _CPC table could not provide processor frequency range values for OS governor, we need to read processor max frequency as anchor point. For AMD processors, we rely on parsing DMI table to get processor max speed. Signed-off-by: Penny Zheng --- xen/arch/x86/dmi_scan.c | 19 +++++++++++++++++++ xen/include/acpi/cpufreq/cpufreq.h | 2 ++ xen/include/xen/dmi.h | 5 +++++ 3 files changed, 26 insertions(+) diff --git a/xen/arch/x86/dmi_scan.c b/xen/arch/x86/dmi_scan.c index 2fcc485295..ec9073c04b 100644 --- a/xen/arch/x86/dmi_scan.c +++ b/xen/arch/x86/dmi_scan.c @@ -10,6 +10,8 @@ #include #include #include +#include +#include #define memcpy_fromio memcpy #define alloc_bootmem(l) xmalloc_bytes(l) @@ -680,6 +682,23 @@ static void __init cf_check dmi_decode(const struct dmi_header *dm) dmi_string(dm, data[6]))); dmi_save_ident(dm, DMI_BOARD_VERSION, 6); break; + case DMI_ENTRY_PROCESSOR: + dmi_max_speed_mhz = 0; + if ( dm->length >= DMI_ENTRY_PROCESSOR_MIN_LENGTH ) + { + dmi_max_speed_mhz = (uint16_t)get_unaligned((const uint16_t *) + (dm + DMI_PROCESSOR_MAX_SPEED_OFFSET)); + if ( !dmi_max_speed_mhz ) + dmi_printk(("Warnning: read zero value for Processor Max Speed\n")); + } + /* + * Real stupid fallback value, just in case there is no + * actual value set. + */ + dmi_max_speed_mhz = dmi_max_speed_mhz ? : 1; + + dmi_printk(("Processor Max Speed: %u\n", dmi_max_speed)); + break; } } diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h index 71e8ca91f0..acf133430b 100644 --- a/xen/include/acpi/cpufreq/cpufreq.h +++ b/xen/include/acpi/cpufreq/cpufreq.h @@ -271,4 +271,6 @@ int acpi_cpufreq_register(void); int amd_pstate_cmdline_parse(const char *s, const char *e); int amd_pstate_register_driver(void); +extern uint16_t dmi_max_speed_mhz; + #endif /* __XEN_CPUFREQ_PM_H__ */ diff --git a/xen/include/xen/dmi.h b/xen/include/xen/dmi.h index ed6ffda315..158bb6228a 100644 --- a/xen/include/xen/dmi.h +++ b/xen/include/xen/dmi.h @@ -1,6 +1,11 @@ #ifndef __DMI_H__ #define __DMI_H__ +/* Minimum struct length needed for the DMI processor entry we want */ +#define DMI_ENTRY_PROCESSOR_MIN_LENGTH 48 +/* Offset in the DMI processor entry for the max frequency */ +#define DMI_PROCESSOR_MAX_SPEED_OFFSET 0x14 + enum dmi_field { DMI_NONE, DMI_BIOS_VENDOR, -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 08:22:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 08:22:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847293.1262412 (Exim 4.92) (envelope-from ) id 1tIOAa-0008PG-4D; Tue, 03 Dec 2024 08:22:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847293.1262412; Tue, 03 Dec 2024 08:22:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIOAZ-0008Or-W4; Tue, 03 Dec 2024 08:22:07 +0000 Received: by outflank-mailman (input) for mailman id 847293; Tue, 03 Dec 2024 08: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 1tIO4l-0006fu-5h for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 08:16:07 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2061a.outbound.protection.outlook.com [2a01:111:f403:2415::61a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d6c5211e-b14e-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 09:16:05 +0100 (CET) Received: from BY3PR10CA0024.namprd10.prod.outlook.com (2603:10b6:a03:255::29) by CY8PR12MB7610.namprd12.prod.outlook.com (2603:10b6:930:9a::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.19; Tue, 3 Dec 2024 08:16:00 +0000 Received: from SJ1PEPF000023D3.namprd21.prod.outlook.com (2603:10b6:a03:255:cafe::13) by BY3PR10CA0024.outlook.office365.com (2603:10b6:a03:255::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.18 via Frontend Transport; Tue, 3 Dec 2024 08:15:59 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SJ1PEPF000023D3.mail.protection.outlook.com (10.167.244.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8251.1 via Frontend Transport; Tue, 3 Dec 2024 08:15:59 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Tue, 3 Dec 2024 02:13:05 -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: d6c5211e-b14e-11ef-a0d3-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QD5I0XmGN/cozyynmRCQly4xwqQFuFWu40PVHdzdOuR3O55htGbVJkr+d1e+noOt4wdG08eKK2IEtb56pkE+U+f9kDOevxEBu3yLK4CFP404fnqDps/2dj0kEqmfHK532co+3+wFOt0iMxuu/Ak40dqh9HamT0Nd68f5Q2HKSlMPYUkeSgyRK6QJKvul4QHARJ4WewBsy/WTbTtzfLZa90POcqbU/dA9jy0K90e8zR08kJGvPgZ+sYw9hfYomcYG30UyHutR3c/p5ud4uAPNejIt02O93Z9ZWXV7DLgR+JqwJxWVXr0FamkKjyJVY9ySs1JWQd5f656Sd0VZbm6h9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gcv16TAN0uUZcF80nkgtKyHscsZfjQCW9TkOZr32cuk=; b=h5c1MQtaT0tNABSc3OsHz2IOLIrgrtA1s3LbPSiXNMqnsSLWAA5Wi5B/OQiVTwo1LHvwy6zMWZKUq1elrNB1rwPqY7caMvxUGtI//mmCAmNGhTB4H2a7GkSAMWPIwfFZ5p7qf+OtAQ0ztg4wt0mLPsHSnjOKTXES0C+3hrdSKNj2qfwHkKJHdlpdDBLL5iQpED1zULz6RhTDzjDmq3vtGhppCIORz6yI6qP0LBeRSRCquCzz9w9Tw9hah2bbH55RSuUhz+Hd6iHy/MUzYKmdhLdlMSlOfrdKwKbqfKVTfA/0CiNRpznZQXXtKkRyfQSBOaLA3v4D4Yq5V5H8ZOKsNw== 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=gcv16TAN0uUZcF80nkgtKyHscsZfjQCW9TkOZr32cuk=; b=el/Pa6wxBt4zegLUrB0zke9uJSmq0OASOxqvPxoTrh1EA3q6v2UmeUfL6PdHULL9MHauv0Q4EvYOkoQ+U5dMA00t2P5ErvSw9d/wJWPdCs04S36iuYg6KSFZflYdy1n9XBIOwlrscFbV9WtfLeBkXjEWcj80RL/gAUq4Wq0wSyM= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: CC: , , , , , Penny Zheng , Jan Beulich , "Andrew Cooper" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v1 01/11] xen/x86: add CPPC feature flag for AMD processors Date: Tue, 3 Dec 2024 16:11:01 +0800 Message-ID: <20241203081111.463400-2-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241203081111.463400-1-Penny.Zheng@amd.com> References: <20241203081111.463400-1-Penny.Zheng@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF000023D3:EE_|CY8PR12MB7610:EE_ X-MS-Office365-Filtering-Correlation-Id: 55dd04e2-4651-402c-3915-08dd1372b810 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700013; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?IM43IzqbFs5eNIWXHAU+n3FB1dXYAoZeNBHvcPP7EB50l1O4FUJ84S64sTpP?= =?us-ascii?Q?jyedxh15OUPwyaFOFpku1MLkzrlcJeqBzGNUvyh0ii1k+0W0bV/JjXxlwR9o?= =?us-ascii?Q?GvUorKXNKOa53RlNaPk3Zjgcd/MK2bbr371fKbI7muLr/Gwi/rDQlzr2n0aU?= =?us-ascii?Q?wQlIPhyaozMCSGtNhKi2eWuoY3T60poy/uyMAWKq1t504aID+I3ztCyFfWke?= =?us-ascii?Q?APIc8wFv/ZJBvTz3zaFGAXAbcTpac6OU6M/EhARJwWsKLCF/RxAQBOX0VJ+c?= =?us-ascii?Q?wqVR71ceF9mzdeAjRJhxUPVR3xlAnNJ+mCMI+/qR4BspkXNdeUkhYcx120Uc?= =?us-ascii?Q?bvr2iWaj0pVFooe9w4jSdQeCa1dghbf1MzVJTFmCXbH2yhToFe1GAvwBOHjz?= =?us-ascii?Q?hnmyLMimHTaQkSp2e6NoVAcFIYMAWvalXu5E5y6rFc/DXT9eItMJcLlXmYSE?= =?us-ascii?Q?WKFSVCC9SOi8KEMuEM5lRlu3+ekuisU8ogkR9gsXaC9cmE4AKc8jw/QEMA+I?= =?us-ascii?Q?iWFbmWzF1N/fkNEW5hgTVQPNf8bv7YZWKYJXIA/+R3swTnkqSUxoivNadVyk?= =?us-ascii?Q?aG56O6HKTxG8FY8eUwqZk41K074QT2nacuUDeXg1suwqzZRFwK4bOgDSV0Yl?= =?us-ascii?Q?LTffLLDyLGDTHqyx0BDTlBVsDh/Q4EW5LSgPGrI/+13Cfk7DhaO0TpGeqMF8?= =?us-ascii?Q?hKavgJ4D23qIECLIIWl2D3hm+fkauFuhuokraGbKi9C68z4qHOwGceSGOH90?= =?us-ascii?Q?SIHLxfH/Dcd6gkXy0AfSpEEZHlJsIcau80niZf1MyUZcNFpcoRy3eekpz//4?= =?us-ascii?Q?7cOodGcSSIkujT+TqLOi+kSoq2Fppj78ftAF3+StlFZBA+vizhlu1ODY8o6a?= =?us-ascii?Q?Vik3weOiU/5a4wnfoiAZ6M4lnpIq26z22V9YSDxvONsTJYry9VEGGYVI/+95?= =?us-ascii?Q?ZhzWgkaD33LgVEqLs8z6VMw+zy68TUZ1SSYewz6tDjfrBZCptnXmg5P/936E?= =?us-ascii?Q?QwMgW+PrGWowWplBy0w/UBDC0EsSOenT/DWXcxtZ+8S6bO+ZmlclR2T1tOg8?= =?us-ascii?Q?PgT5Q+eyyqe1twFP059LI833CXORf0Owuzxk1wqrv9xai8v4hs+8aGVToHtU?= =?us-ascii?Q?+CQCNX3f+ZSNPIzQVnT1ChBvUA4YqyjrWEh3Mi21wrOpFylbLne0tsBSfhNG?= =?us-ascii?Q?Z+/YXASAk9Oze+1y8PwyyZJKNQzEkGULVoEgUmSgem9KeeqRjjEMWYV+eVRy?= =?us-ascii?Q?MmIviVelrVSqioVqYL/5J3l8t8gGTQNZtWDMl2SD4I52k5q55r5l7sgKMRUg?= =?us-ascii?Q?0T3Auq7IGqAZ5Xi0qEGsYgd0pl9hP+Rx/mL9TvOKV1KjTEsUYlEMeiKqBmET?= =?us-ascii?Q?uHvCFuWPtsG6ofmYmkwSeo5KfzuyS1/FxdDvBIUdRzzc4f90lFDoJnDl4ipP?= =?us-ascii?Q?jdIrFM2GgvF+sv4M3/IppKctVAju2+DY?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 08:15:59.0186 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 55dd04e2-4651-402c-3915-08dd1372b810 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF000023D3.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7610 Add Collaborative Processor Performance Control feature flag for AMD processors. amd-pstate is the AMD CPU performance scaling driver that introduces a new CPU frequency control mechanism on modern AMD APU and CPU series. There are two types of hardware implementations: "Full MSR Support" and "Shared Memory Support". Right now, xen will only implement "Full MSR Support", and this new feature flag indicates whether processor has this feature or not. Signed-off-by: Penny Zheng --- xen/arch/x86/include/asm/cpufeature.h | 1 + xen/include/public/arch-x86/cpufeatureset.h | 1 + 2 files changed, 2 insertions(+) diff --git a/xen/arch/x86/include/asm/cpufeature.h b/xen/arch/x86/include/asm/cpufeature.h index 3a06b6f297..6935703e71 100644 --- a/xen/arch/x86/include/asm/cpufeature.h +++ b/xen/arch/x86/include/asm/cpufeature.h @@ -170,6 +170,7 @@ static inline bool boot_cpu_has(unsigned int feat) #define cpu_has_amd_ssbd boot_cpu_has(X86_FEATURE_AMD_SSBD) #define cpu_has_virt_ssbd boot_cpu_has(X86_FEATURE_VIRT_SSBD) #define cpu_has_ssb_no boot_cpu_has(X86_FEATURE_SSB_NO) +#define cpu_has_cppc boot_cpu_has(X86_FEATURE_CPPC) #define cpu_has_auto_ibrs boot_cpu_has(X86_FEATURE_AUTO_IBRS) /* CPUID level 0x00000007:0.edx */ diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h index 8fa3fb711a..15f707639b 100644 --- a/xen/include/public/arch-x86/cpufeatureset.h +++ b/xen/include/public/arch-x86/cpufeatureset.h @@ -265,6 +265,7 @@ XEN_CPUFEATURE(AMD_PPIN, 8*32+23) /* Protected Processor Inventory Number XEN_CPUFEATURE(AMD_SSBD, 8*32+24) /*S MSR_SPEC_CTRL.SSBD available */ XEN_CPUFEATURE(VIRT_SSBD, 8*32+25) /*! MSR_VIRT_SPEC_CTRL.SSBD */ XEN_CPUFEATURE(SSB_NO, 8*32+26) /*A Hardware not vulnerable to SSB */ +XEN_CPUFEATURE(CPPC, 8*32+27) /*A Collaborative Processor Performance Control */ XEN_CPUFEATURE(PSFD, 8*32+28) /*S MSR_SPEC_CTRL.PSFD */ XEN_CPUFEATURE(BTC_NO, 8*32+29) /*A Hardware not vulnerable to Branch Type Confusion */ XEN_CPUFEATURE(IBPB_RET, 8*32+30) /*A IBPB clears RSB/RAS too. */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 08:22:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 08:22:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847302.1262446 (Exim 4.92) (envelope-from ) id 1tIOAb-0000UC-QH; Tue, 03 Dec 2024 08:22:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847302.1262446; Tue, 03 Dec 2024 08:22: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 1tIOAb-0000Pq-9l; Tue, 03 Dec 2024 08:22:09 +0000 Received: by outflank-mailman (input) for mailman id 847302; Tue, 03 Dec 2024 08: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 1tIO7I-0006kj-BH for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 08:18:44 +0000 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on20605.outbound.protection.outlook.com [2a01:111:f403:2414::605]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 33c7275f-b14f-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 09:18:41 +0100 (CET) Received: from SJ2PR07CA0002.namprd07.prod.outlook.com (2603:10b6:a03:505::25) by PH8PR12MB7160.namprd12.prod.outlook.com (2603:10b6:510:228::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 08:18:34 +0000 Received: from SJ1PEPF000023D4.namprd21.prod.outlook.com (2603:10b6:a03:505:cafe::cf) by SJ2PR07CA0002.outlook.office365.com (2603:10b6:a03:505::25) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.18 via Frontend Transport; Tue, 3 Dec 2024 08:18:34 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SJ1PEPF000023D4.mail.protection.outlook.com (10.167.244.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8251.1 via Frontend Transport; Tue, 3 Dec 2024 08:18:33 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Tue, 3 Dec 2024 02:16: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: 33c7275f-b14f-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=t+DvnDoePekH0k4dGFGw/Dcmj6ZotSTZverB1PgvniOIGbCm/EDvEuHNSblznaBA/Qc7MWHCo9dKATri776Ux0yWQHHvWJq2Z7XaoEMU4JkQXyPH/YibUQ80h07AozKKH+N6KlsFVwb0RnnWg6j4iXaD/m1h5hBGsUx7Dr3mKLItLvhSkRNPyjQ7j0JA7vIBfoEPdtNIdzTXpZSN8tkuqy+DdPhMM5AqGgO7bheI0wGkQFAIEgqopc4lYUaoUbiSiAeSTZtirmL3YTkW1WXlEqdTS01VkIEQP6K68xeyIzoItTiT3CEWFz1e9/DN0CjjglblMf+jLX33geW0rxZ5Jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=X8DNK8kEDIj5P0gCv/ZATmRXxy9NMlA56yx+rvk9jsc=; b=RrMW2ACv++bdShZwLX0J/LMC8lR8l4xomNFclUIry/q7i6dlWXdqSKmwcBFHjULzoquISZvwaTx0GXFlgU/k0/nEW7oh0tpJOV82gsnoZqBa1kuxDNDLI+StP2XzPtZV+ygHhuuOq6XrXOEMlgGoNffyptuCTyKmxTdgBzvLYFfsDRTMtM1+HTTlGWIitZbkw+6c8QUII9Ok2DYb8AxyBo4De8tfNxhLSOxJ+lRGsy8pZbelY24upLSqdV7fEvP4xca+d3xvdEn0ZLerxE3BCN/eAR7jUqmMHG/H8BvE/4cJNPt24MpLNkV5dTEfLx7Ln+svfX34dRh9FRCHw70Bog== 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=X8DNK8kEDIj5P0gCv/ZATmRXxy9NMlA56yx+rvk9jsc=; b=fpiEBd918ycM8lf50qwf1jlYAxo8j+3ByoFRrB3Ga3NFMiBWAPv2KRZ45b+dxxIyQSqVoWhqzDleS9A3qZzuNJv44+Qj2afU5IIoRxFd+6MDen/d7m++0jFIMojB/QLnKUMEcBNFn1ruQHlYtttEXKVt8qYmQ5nFojnxwf7gv1Q= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: CC: , , , , , Penny Zheng , Jan Beulich , "Andrew Cooper" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v1 05/11] xen/x86: introduce a new amd pstate driver for cpufreq scaling Date: Tue, 3 Dec 2024 16:11:05 +0800 Message-ID: <20241203081111.463400-6-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241203081111.463400-1-Penny.Zheng@amd.com> References: <20241203081111.463400-1-Penny.Zheng@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF000023D4:EE_|PH8PR12MB7160:EE_ X-MS-Office365-Filtering-Correlation-Id: 668cb013-e510-4059-523d-08dd13731464 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?nS8O9KFJdoegiHeUyxTPKPkA1Ex7r6w/gBZ65cxdlV/uQjs9T89wRu6e9nkm?= =?us-ascii?Q?NX1xpZJsdN9RHP+pbyDTIzUa4KL06vzAIAn9YaCic10e0AfsjYT9KpWqMK4l?= =?us-ascii?Q?OKUuPOhxfP49hhPzq+jHXp8yf3B0CUA1K0ERaSsCwiuAE1/mz/ME2Rg9GDP3?= =?us-ascii?Q?VgcxrWx2xQ5dZ8icR/hRD0vYjtuO0RYIGdOcE0i9by5J+V4pOYkxiz4Bfozz?= =?us-ascii?Q?PwrJv9KH94xlJspeQfGHlR+cHObKMdc2V+oaTmOsL3VONuu/Qf7UZacm53ID?= =?us-ascii?Q?5BKXBoTF6/wSKwZ1pbK4ZJ7mi1QkaOsW85WgqCpTkxtRpTodla3X0udN+CNX?= =?us-ascii?Q?n/FKwLAVEl7ZlxmJ7j+ATvWkvk9hF7o79DwMHsQHYB5/xRpgXCCVH2yC9pPs?= =?us-ascii?Q?gAfKfKu/ICI2c+K4isIXmUfeBAcab9Kc8QRnNcLr4B84t9nOjP2xML2I0RJ9?= =?us-ascii?Q?VVvBQ5ekpPPcD0AIs1rK3W50cpJYclMEB5CxvrcD+G15TIicnxg18pTMFQMK?= =?us-ascii?Q?uAyrEucoTWh7Ei7dMOJ3lg5ab9dUEfyIKgtjySc1I7J+BixDCByQjjqnwMk+?= =?us-ascii?Q?CVvylfvYJYIJFy3Q3b2AJFiD7yBnmVIVl6jHcVNI1TzLfkW4HA/EpaxZKuG4?= =?us-ascii?Q?8lHJ5t0MfingR0Y6IH4JALcYHXdqw982HoxkJMptdpTY4LQK7XKGhZyK7kdT?= =?us-ascii?Q?bYJ6JXBcJAVMomgSCsJ3q/LdKxTOVQYmlM7PYJuFgkXcFm/dPihOgNMqtSxt?= =?us-ascii?Q?PmQIPtZk/8S0fCme5DscjhSFFJgJ42RqrW1kqG7pfcfS2qB+fPKVbz+Sa2HJ?= =?us-ascii?Q?LNCx6TpV6ehFAhT1OkzfIaUDvuKySrOIrpTGkCUi3JeyVi78ruKnz8ibiV+f?= =?us-ascii?Q?n+ADMJZ9Q8rhVaAP/h6kCkMEK7SH3djt6C+i3jtL6jQWp9JT1dyzuGVl7yvc?= =?us-ascii?Q?2K5ij9tzxnGSGAF30xvccXFg/tNaEwG3pylQN0jEXiYWSeA/2yCbCmfC0xBZ?= =?us-ascii?Q?xdDBuL+H4dK+iXtHUvgH+Bi9CcRB2FDaXADzG1J0dXXB9Gzm1A4eEfqLxnna?= =?us-ascii?Q?BvWplD/NhoYknJUhlpo1BXHZ5r6xz8M9sm9L72gfH4BVnfMeo+KqrABuyF6Q?= =?us-ascii?Q?xJYAxx2+pRBJSGbXTXLCHgWrigulgcer8l3U177xCsXqF3OQsHKxOxSkgVKI?= =?us-ascii?Q?n+c4dIvZY4YPJtNFvQeYeS2hpJ+mJwYzm4L7S1c6Mmzj996P+w/pwqHz3SHK?= =?us-ascii?Q?WK/V7TaTdZKHd0N92Pm7v3wYQbQ9/hHDdN20s06l2LyvDGcNJKjcholCNiZp?= =?us-ascii?Q?6gKz3HLiR9o2o2EZySuit/pOras2KCZFUwDa8Sd3XX03GT69NV5YylrGlZru?= =?us-ascii?Q?b4mrXCnPA64xxka0RFjzs8MRsSx5LK/nsT//+CPLK+3138FM767hy0zq123b?= =?us-ascii?Q?V/8EIkfBN3w2FXE4gBYThy/Zb6Aq1ikE?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 08:18:33.9357 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 668cb013-e510-4059-523d-08dd13731464 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF000023D4.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7160 amd-pstate is the AMD CPU performance scaling driver that introduces a new CPU frequency control mechanism on AMD Zen based CPU series. The new mechanism is based on Collaborative Processor Performance Control (CPPC) which is a finer grain frequency management than legacy ACPI hardware P-States. Current AMD CPU platforms are using the ACPI P-states driver to manage CPU frequency and clocks with switching only in 3 P-states. The new amd-pstate allows a more flexible, low-latency interface for Xen to directly communicate the performance hints to hardware. The first version "amd-pstate" could leverage common governors such as *ondemand*, *performance*, etc, to manage the performance hints. In the future, we will introduce an advanced active mode to enable autonomous performence level selection. Signed-off-by: Penny Zheng --- xen/arch/x86/acpi/cpufreq/amd-pstate.c | 336 +++++++++++++++++++++++++ xen/arch/x86/include/asm/msr-index.h | 5 + 2 files changed, 341 insertions(+) diff --git a/xen/arch/x86/acpi/cpufreq/amd-pstate.c b/xen/arch/x86/acpi/cpufreq/amd-pstate.c index bfad96ae3d..5dfa35581a 100644 --- a/xen/arch/x86/acpi/cpufreq/amd-pstate.c +++ b/xen/arch/x86/acpi/cpufreq/amd-pstate.c @@ -15,6 +15,53 @@ #include #include #include +#include + +#define amd_pstate_err(cpu, fmt, args...) \ + printk(XENLOG_ERR "AMD_PSTATE: CPU%u error: " fmt, cpu, ## args) +#define amd_pstate_verbose(fmt, args...) \ +({ \ + if ( cpufreq_verbose ) \ + printk(XENLOG_DEBUG "AMD_PSTATE: " fmt, ## args); \ +}) +#define amd_pstate_warn(fmt, args...) \ + printk(XENLOG_WARNING "AMD_PSTATE: CPU%u warning: " fmt, cpu, ## args) + +struct amd_pstate_drv_data +{ + struct xen_processor_cppc *cppc_data; + union + { + uint64_t amd_caps; + struct + { + unsigned int lowest_perf:8; + unsigned int lowest_nonlinear_perf:8; + unsigned int nominal_perf:8; + unsigned int highest_perf:8; + unsigned int :32; + } hw; + }; + union + { + uint64_t amd_req; + struct + { + unsigned int max_perf:8; + unsigned int min_perf:8; + unsigned int des_perf:8; + unsigned int epp:8; + unsigned int :32; + } req; + }; + int err; + + uint32_t max_freq; + uint32_t min_freq; + uint32_t nominal_freq; +}; + +static DEFINE_PER_CPU_READ_MOSTLY(struct amd_pstate_drv_data *, amd_pstate_drv_data); uint16_t __read_mostly dmi_max_speed_mhz; @@ -52,9 +99,298 @@ int __init amd_pstate_cmdline_parse(const char *s, const char *e) return 0; } +/* + * If CPPC lowest_freq and nominal_freq registers are exposed then we can + * use them to convert perf to freq and vice versa. The conversion is + * extrapolated as an affine function passing by the 2 points: + * - (Low perf, Low freq) + * - (Nominal perf, Nominal freq) + */ +static unsigned int amd_pstate_khz_to_perf(struct amd_pstate_drv_data *data, unsigned int freq) +{ + struct xen_processor_cppc* cppc_data = data->cppc_data; + uint64_t mul, div, offset = 0; + + if ( freq == (cppc_data->nominal_freq * 1000) ) + return data->hw.nominal_perf; + + if ( freq == (cppc_data->lowest_freq * 1000) ) + return data->hw.lowest_perf; + + if ( (cppc_data->lowest_freq) && (cppc_data->nominal_freq) ) + { + mul = data->hw.nominal_perf - data->hw.lowest_perf; + div = cppc_data->nominal_freq - cppc_data->lowest_freq; + /* + * We don't need to convert to kHz for computing offset and can + * directly use nominal_freq and lowest_freq as the division + * will remove the frequency unit. + */ + div = div ?: 1; + offset = data->hw.nominal_perf - (mul * cppc_data->nominal_freq) / div; + } + else + { + /* Read Processor Max Speed(mhz) from DMI table as anchor point */ + mul = data->hw.highest_perf; + div = dmi_max_speed_mhz; + } + + return (unsigned int)(offset + (mul * freq ) / (div * 1000)); +} + +static unsigned int amd_get_min_freq(struct amd_pstate_drv_data *data) +{ + struct xen_processor_cppc *cppc_data = data->cppc_data; + uint64_t mul, div; + + if ( cppc_data->lowest_freq ) + /* Switch to khz */ + return cppc_data->lowest_freq * 1000; + else + { + /* Read Processor Max Speed(mhz) from DMI table as anchor point */ + mul = dmi_max_speed_mhz; + div = data->hw.highest_perf; + + return (unsigned int)(mul / div) * data->hw.lowest_perf * 1000; + } +} + +static unsigned int amd_get_nominal_freq(struct amd_pstate_drv_data *data) +{ + struct xen_processor_cppc *cppc_data = data->cppc_data; + uint64_t mul, div; + + if ( cppc_data->nominal_freq ) + /* Switch to khz */ + return cppc_data->nominal_freq * 1000; + else + { + /* Read Processor Max Speed(mhz) from DMI table as anchor point */ + mul = dmi_max_speed_mhz; + div = data->hw.highest_perf; + + return (unsigned int)(mul / div) * data->hw.nominal_perf * 1000; + } +} + +static unsigned int amd_get_max_freq(struct amd_pstate_drv_data *data) +{ + uint64_t max_perf, max_freq, nominal_freq, nominal_perf; + uint64_t boost_ratio; + + nominal_freq = amd_get_nominal_freq(data); + nominal_perf = data->hw.nominal_perf; + max_perf = data->hw.highest_perf; + + boost_ratio = (uint64_t)(max_perf / nominal_perf); + max_freq = nominal_freq * boost_ratio; + + return max_freq; +} + +static int cf_check amd_pstate_cpufreq_verify(struct cpufreq_policy *policy) +{ + struct amd_pstate_drv_data *data = per_cpu(amd_pstate_drv_data, policy->cpu); + + cpufreq_verify_within_limits(policy, data->min_freq, data->max_freq); + + return 0; +} + +static void amd_pstate_write_request_msrs(void *info) +{ + struct amd_pstate_drv_data *data =(struct amd_pstate_drv_data *)info; + + if ( wrmsr_safe(MSR_AMD_CPPC_REQ, data->amd_req) ) + { + amd_pstate_verbose("Failed to wrmsr_safe(MSR_AMD_CPPC_REQ, %lx)\n", + data->amd_req); + data->err = -EINVAL; + return; + } + data->err = 0; +} + +static int cf_check amd_pstate_write_request(int cpu, uint8_t min_perf, + uint8_t des_perf, uint8_t max_perf) +{ + struct amd_pstate_drv_data *data = per_cpu(amd_pstate_drv_data, cpu); + uint64_t prev = data->amd_req; + + data->req.min_perf = min_perf; + data->req.max_perf = max_perf; + data->req.des_perf = des_perf; + + if ( prev == data->amd_req ) + return 0; + + on_selected_cpus(cpumask_of(cpu), amd_pstate_write_request_msrs, data, 1); + + return data->err; +} + +static int cf_check amd_pstate_cpufreq_target(struct cpufreq_policy *policy, + unsigned int target_freq, + unsigned int relation) +{ + unsigned int cpu = policy->cpu; + struct amd_pstate_drv_data *data = per_cpu(amd_pstate_drv_data, cpu); + uint64_t max_perf, min_perf, des_perf; + + if ( unlikely(!target_freq) ) + { + amd_pstate_warn("Not setting target frequency to zero\n"); + return 0; + } + max_perf = data->hw.highest_perf; + min_perf = data->hw.lowest_nonlinear_perf; + des_perf = amd_pstate_khz_to_perf(data, target_freq); + + return amd_pstate_write_request(policy->cpu, min_perf, des_perf, max_perf); +} + +static void cf_check amd_pstate_init_msrs(void *info) +{ + struct cpufreq_policy *policy = info; + struct amd_pstate_drv_data *data = this_cpu(amd_pstate_drv_data); + uint64_t val; + unsigned int min_freq, nominal_freq, max_freq; + + /* Package level MSR */ + if ( rdmsr_safe(MSR_AMD_CPPC_ENABLE, val) ) + { + amd_pstate_err(policy->cpu, "rdmsr_safe(MSR_AMD_CPPC_ENABLE)\n"); + data->err = -EINVAL; + return; + } + + if ( !(val & AMD_CPPC_ENABLE) ) + { + val |= AMD_CPPC_ENABLE; + if ( wrmsr_safe(MSR_AMD_CPPC_ENABLE, val) ) + { + amd_pstate_err(policy->cpu, "wrmsr_safe(MSR_AMD_CPPC_ENABLE, %lx)\n", val); + data->err = -EINVAL; + return; + } + } + + if ( rdmsr_safe(MSR_AMD_CPPC_CAP1, data->amd_caps) ) + { + amd_pstate_err(policy->cpu, "rdmsr_safe(MSR_AMD_CPPC_CAP1)\n"); + goto error; + } + + if ( data->hw.highest_perf == 0 || data->hw.lowest_perf == 0 || + data->hw.nominal_perf == 0 || data->hw.lowest_nonlinear_perf == 0 ) + { + amd_pstate_err(policy->cpu, "Platform malfunction, read CPPC highest_perf: %u, lowest_perf: %u, nominal_perf: %u, lowest_nonlinear_perf: %u zero value\n", + data->hw.highest_perf, data->hw.lowest_perf, + data->hw.nominal_perf, data->hw.lowest_nonlinear_perf); + goto error; + } + + min_freq = amd_get_min_freq(data); + nominal_freq = amd_get_nominal_freq(data); + max_freq = amd_get_max_freq(data); + if ( min_freq > max_freq ) + { + amd_pstate_err(policy->cpu, "min_freq(%u) or max_freq(%u) value is incorrect\n", + min_freq, max_freq); + goto error; + } + + policy->min = min_freq; + policy->max = max_freq; + + policy->cpuinfo.min_freq = min_freq; + policy->cpuinfo.max_freq = max_freq; + policy->cpuinfo.perf_freq = nominal_freq; + policy->cur = nominal_freq; + + /* Initial processor data capability frequencies */ + data->min_freq = min_freq; + data->nominal_freq = nominal_freq; + data->max_freq = max_freq; + + data->err = 0; + return; + + error: + data->err = -EINVAL; + val &= ~AMD_CPPC_ENABLE; + if ( wrmsr_safe(MSR_AMD_CPPC_ENABLE, val) ) + amd_pstate_err(policy->cpu, "wrmsr_safe(MSR_AMD_CPPC_ENABLE, %lx)\n", val); +} + +/* + * The new AMD P-States driver is different than legacy ACPI hardware P-State, + * which has a finer grain frequency range between the highest and lowest + * frequency. And boost frequency is actually the frequency which is mapped on + * highest performance ratio. The legacy P0 frequency is actually mapped on + * nominal performance ratio. + */ +static void amd_pstate_boost_init(struct cpufreq_policy *policy, struct amd_pstate_drv_data *data) +{ + uint32_t highest_perf, nominal_perf; + + highest_perf = data->hw.highest_perf; + nominal_perf = data->hw.nominal_perf; + + if ( highest_perf <= nominal_perf ) + return; + + policy->turbo = CPUFREQ_TURBO_ENABLED; +} + +static int cf_check amd_pstate_cpufreq_cpu_init(struct cpufreq_policy *policy) +{ + unsigned int cpu = policy->cpu; + struct amd_pstate_drv_data *data; + + data = xzalloc(struct amd_pstate_drv_data); + if ( !data ) + return -ENOMEM; + + data->cppc_data = &processor_pminfo[cpu]->cppc_data; + + policy->governor = cpufreq_opt_governor ? : CPUFREQ_DEFAULT_GOVERNOR; + + per_cpu(amd_pstate_drv_data, cpu) = data; + + on_selected_cpus(cpumask_of(cpu), amd_pstate_init_msrs, policy, 1); + + if ( data->err ) + { + amd_pstate_err(cpu, "Could not initialize AMD CPPC MSR properly\n"); + per_cpu(amd_pstate_drv_data, cpu) = NULL; + xfree(data); + return -ENODEV; + } + + amd_pstate_boost_init(policy, data); + return 0; +} + +static int cf_check amd_pstate_cpufreq_cpu_exit(struct cpufreq_policy *policy) +{ + struct amd_pstate_drv_data *data = per_cpu(amd_pstate_drv_data, policy->cpu); + + per_cpu(amd_pstate_drv_data, policy->cpu) = NULL; + xfree(data); + + return 0; +} + static const struct cpufreq_driver __initconstrel amd_pstate_cpufreq_driver = { .name = XEN_AMD_PSTATE_DRIVER_NAME, + .verify = amd_pstate_cpufreq_verify, + .target = amd_pstate_cpufreq_target, + .init = amd_pstate_cpufreq_cpu_init, + .exit = amd_pstate_cpufreq_cpu_exit, }; int __init amd_pstate_register_driver(void) diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h index 9cdb5b2625..14eaddcaad 100644 --- a/xen/arch/x86/include/asm/msr-index.h +++ b/xen/arch/x86/include/asm/msr-index.h @@ -455,6 +455,11 @@ #define MSR_AMD_PPIN_CTL 0xc00102f0U #define MSR_AMD_PPIN 0xc00102f1U +#define MSR_AMD_CPPC_CAP1 0xc00102b0 +#define MSR_AMD_CPPC_ENABLE 0xc00102b1 +#define MSR_AMD_CPPC_REQ 0xc00102b3 +#define AMD_CPPC_ENABLE BIT(0, ULL) + /* VIA Cyrix defined MSRs*/ #define MSR_VIA_FCR 0x00001107 #define MSR_VIA_RNG 0x0000110b -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 08:22:10 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 08:22:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847304.1262452 (Exim 4.92) (envelope-from ) id 1tIOAc-0000gP-AS; Tue, 03 Dec 2024 08:22:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847304.1262452; Tue, 03 Dec 2024 08:22:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIOAb-0000eR-Tu; Tue, 03 Dec 2024 08:22:09 +0000 Received: by outflank-mailman (input) for mailman id 847304; Tue, 03 Dec 2024 08:20: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 1tIO8b-0007Zo-Vp for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 08:20:05 +0000 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on20629.outbound.protection.outlook.com [2a01:111:f403:2009::629]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 64d2524b-b14f-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 09:20:03 +0100 (CET) Received: from SJ0PR13CA0172.namprd13.prod.outlook.com (2603:10b6:a03:2c7::27) by IA1PR12MB6410.namprd12.prod.outlook.com (2603:10b6:208:38a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 08:19:57 +0000 Received: from SN1PEPF0002529E.namprd05.prod.outlook.com (2603:10b6:a03:2c7:cafe::d3) by SJ0PR13CA0172.outlook.office365.com (2603:10b6:a03:2c7::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.9 via Frontend Transport; Tue, 3 Dec 2024 08:19:57 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SN1PEPF0002529E.mail.protection.outlook.com (10.167.242.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 08:19:56 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Tue, 3 Dec 2024 02:17:49 -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: 64d2524b-b14f-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sQXvPqpVS1eu5eOyVus+74kxKYVsawh3Ul15YgJ4U8pgzzy666/FEfI8WWSwh/MFTD4vZL5iQcDv/75TYK1zBdz2TahQVgrrAchvDobjtmSHOyl75EhN+h4ndJbWDf3f3b+R9agdei04WLqmb4YZd7plNj4X8U4rwNHI9xB64t3njPiEig723eSVPt6nTZnVDQ4TgaTTPnrEd30RRVO+G6KluQLHfC8IRLpCIPIRGVA/M890aG2P4BOgPZ6/cKoaDkvGitt7ThU1N1cm+Epnp5ZPyMgTsRPTPh3bYZgl/KHYNmAU/LCB2I0HLo6J6D2TNoauFOYfiaYaoSpzl359Hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=l+yjn6tY8kv6aWZsbjG/GS2xunJRw06lAQvR1V0lj7o=; b=PMmVmgrgHmCuuc/6I9vCJwPCQxSVIdb9bTfrA10/mbiK5unGKd9CAa/DSV/sDIS2OAhlzTyrHwbyToYrnY0b+RU1R6P1vQ+X/i6yb45PNLNT6qVtYWbjc+70cm0FoLpYRxl4PcWCy94w+GMrYYJxnqt+aCr2ArPE9OJkh+/WnpsmOLiW8WS3Rl2HT8O8Y7ni0bQKcB1EGnvaGs6JFCPyZneNopC9Z6kj1wLsqD3geUWFn3Qh2exnhhYVw7OWr8i2XwBXTiufbyT6JtvVA03gfnF4WRzYvknpGdYxJvWfqVJRwDI3FzyCBLhBGuS3jt5E3qQh2xMlyB7W6z92oGa7og== 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=l+yjn6tY8kv6aWZsbjG/GS2xunJRw06lAQvR1V0lj7o=; b=1KR6qmdXMS/SSkrOOzwWtYveiAIQ/2zBJLUcJ2ZTMT8ugqvMbFzUVVYa4GGanhkGQ/ldijDnu2doW1amto3+tkxfZ4dCHof63qJiSFRRE5DV5Gvod0YT7ZqdDdiqUQBEKRA+gJIexTKW0SWEOvj7sEfQCzQdV71ySYpA+Wz4G00= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: CC: , , , , , Jan Beulich , Penny Zheng Subject: [PATCH v1 06/11] xen/cpufreq: introduce policy type when cpufreq_driver->setpolicy exists Date: Tue, 3 Dec 2024 16:11:06 +0800 Message-ID: <20241203081111.463400-7-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241203081111.463400-1-Penny.Zheng@amd.com> References: <20241203081111.463400-1-Penny.Zheng@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PEPF0002529E:EE_|IA1PR12MB6410:EE_ X-MS-Office365-Filtering-Correlation-Id: d34d4d1c-b349-44be-137f-08dd137345a5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|82310400026|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?gfKf1U5PHlbKSL4sKieGBvNsemCb0Y7SC+emdaFiFTxYoXrLOw67x3vze5DP?= =?us-ascii?Q?+7MHaU7BBOXMAPF1aPmsjVPczUe+Hxs525KUABqOVSlHs19JCrRewl1r1Kjl?= =?us-ascii?Q?RGQb5WzLHfkkEWhG8GIuaDOQtFDEb7a6LfROyJpfT3z3o66ebgCXt8FVBYeB?= =?us-ascii?Q?R7wfXZzvYS/9E7JAzYci2wZdLDKQ9KtfWINQPTG39wOIEeaEsY39TbUuStsd?= =?us-ascii?Q?+ISKAQd+8GS8NTFhzTBR2Bojei9JqrSHD+Wjgy8ugMmyLFz/Tt6vsj+WIhrS?= =?us-ascii?Q?cLciiezmGywSTnEbsYlBFhcGPsXrtkRVeROcCM/r0VgSxTxXbeCvb9113ESl?= =?us-ascii?Q?hRfRmfEBw5hV2PcRSzWw6oxhaKj5X/yqgbZgWBiDL/z5QIYK8iJ47cT7i6G+?= =?us-ascii?Q?HNiVZ0Er8CVmoD+NNkIUj7DACt/zzZiHI7GgwN1tzPzdTdqt11kkO53Px4s3?= =?us-ascii?Q?l9lxTzpoTwWSdOFf7gD1+jkziQvstrhQIJ8AYuFTl0Gu5k4P+WRaCNyZnggA?= =?us-ascii?Q?W79HQm6C71Jd7yArHXLXIhsFqsCv9m3U1ZRPVw1lpxe5Xum82g7FxQ6R50PS?= =?us-ascii?Q?PPIMS9jSCWgcv3RuJodAyQe99G0xeJtPzutA0XEV4phN1LqJajCEO0l3Cy9Q?= =?us-ascii?Q?Kug9jRmrx5KDbcce2TyJUy/x2efVUm+5yxg7y7hXfSwR1/xGrCSRBOzf9SJ6?= =?us-ascii?Q?cQMXkJa/YJrxEiaTmcY/pR7Zya/vRMuDsxdBBrkd1wj4KDtqyYS3erBlfaYa?= =?us-ascii?Q?3MM2kcComhTU4jGxuDLJmcMJQbXpFrl6TSK7KB1kI80vXojYF/gNJqbv7e5G?= =?us-ascii?Q?TJt9vKK+5A98sjapB/m+/gHNMWxG7DfvF+meSj81j4yurxAlg1dJG2S+5TsJ?= =?us-ascii?Q?eMCUOhdLLlH9krdD3vSJghLSU0mZO7+yFvEDnF4AwSLredTpb6vPMtkLEf7q?= =?us-ascii?Q?30FpQ5f5cvwEY0EXyfS/wzj4H9aQOXTNCvHuOw23zNQDS55aW5/rppRUn+KP?= =?us-ascii?Q?XN8Sn5F628Sza+I+Kj80K9WXak9P64Ki5OQFNTuLR+C2lm3fFtj0X1ZdG75b?= =?us-ascii?Q?t/RV6UzITbNWbUZHNqNRnHRqMjGLeC00gHa2oQ63XVFK4/ELKCAvy4wuVf4d?= =?us-ascii?Q?XoXfnsEjJM2mw1LXHDUn7mPYXZaJgd8RV4S8enbFiZORnDcb7i9vtG1wnVYw?= =?us-ascii?Q?PFtrcuobPkkNpJYirJLflTk3JElQViLIQb2xnr+rz9iBt5ai1aMCFmJm94nk?= =?us-ascii?Q?YFAT8Y9i2uQnlPV7sRkGYbOP79ZkQdwhB3l2E/GdQyXeCElx1XnifLItxp6d?= =?us-ascii?Q?sCabrBsvNMxXveb+XTOOu5d0owlXTtd6WlxKQfv5G+1RQ9bdfaSAEJCagIQX?= =?us-ascii?Q?nFzbKiUZG7TRV38fKme4Hfz0guBcPFuKUzkpvhJ1ektC3Ud4xV97ZOic3cSi?= =?us-ascii?Q?DInw31QeTqr0uYrfeI1SrlZErvO9r+Lt?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 08:19:56.6154 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d34d4d1c-b349-44be-137f-08dd137345a5 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SN1PEPF0002529E.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6410 From: Penny Zheng If cpufreq_driver->target exists, the ->governor decides what frequency within the limits is used. But when cpufreq_driver->setpolicy exists, the CPUFreq scaling driver bypasses the governor layer and implement their own performance scaling algorithms. And we introduce the following two generic policies CPUFREQ_POLICY_POWERSAVE and CPUFREQ_POLICY_PERFORMANCE, to have 1:1 map with governor info, to still benefit from cpufreq_opt_governor cmdline. Signed-off-by: Penny Zheng --- xen/drivers/cpufreq/utility.c | 11 +++++++++++ xen/include/acpi/cpufreq/cpufreq.h | 11 +++++++++++ 2 files changed, 22 insertions(+) diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c index e690a484f1..2503ce6243 100644 --- a/xen/drivers/cpufreq/utility.c +++ b/xen/drivers/cpufreq/utility.c @@ -484,3 +484,14 @@ int __cpufreq_set_policy(struct cpufreq_policy *data, return __cpufreq_governor(data, CPUFREQ_GOV_LIMITS); } + +unsigned int cpufreq_parse_policy(struct cpufreq_governor *gov) +{ + if ( !strncasecmp(gov->name, "performance", CPUFREQ_NAME_LEN) ) + return CPUFREQ_POLICY_PERFORMANCE; + + if ( !strncasecmp(gov->name, "powersave", CPUFREQ_NAME_LEN) ) + return CPUFREQ_POLICY_POWERSAVE; + + return CPUFREQ_POLICY_UNKNOWN; +} diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h index acf133430b..cad27f6811 100644 --- a/xen/include/acpi/cpufreq/cpufreq.h +++ b/xen/include/acpi/cpufreq/cpufreq.h @@ -133,6 +133,17 @@ extern int cpufreq_register_governor(struct cpufreq_governor *governor); extern struct cpufreq_governor *__find_governor(const char *governor); #define CPUFREQ_DEFAULT_GOVERNOR &cpufreq_gov_dbs +#define CPUFREQ_POLICY_UNKNOWN 0 +/* + * If cpufreq_driver->target() exists, the ->governor decides what frequency + * within the limits is used. If cpufreq_driver->setpolicy() exists, these + * two generic policies are available: + */ +#define CPUFREQ_POLICY_POWERSAVE 1 +#define CPUFREQ_POLICY_PERFORMANCE 2 + +unsigned int cpufreq_parse_policy(struct cpufreq_governor *gov); + /* pass a target to the cpufreq driver */ extern int __cpufreq_driver_target(struct cpufreq_policy *policy, unsigned int target_freq, -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 08:22:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 08:22:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847308.1262462 (Exim 4.92) (envelope-from ) id 1tIOAd-0000wx-19; Tue, 03 Dec 2024 08:22:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847308.1262462; Tue, 03 Dec 2024 08:22:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIOAc-0000tl-GI; Tue, 03 Dec 2024 08:22:10 +0000 Received: by outflank-mailman (input) for mailman id 847308; Tue, 03 Dec 2024 08:20: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 1tIO99-0007ic-F3 for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 08:20:39 +0000 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on20625.outbound.protection.outlook.com [2a01:111:f403:2417::625]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 79d08f79-b14f-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 09:20:38 +0100 (CET) Received: from BLAPR03CA0022.namprd03.prod.outlook.com (2603:10b6:208:32b::27) by SJ1PR12MB6147.namprd12.prod.outlook.com (2603:10b6:a03:45a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 08:20:34 +0000 Received: from BL6PEPF0001AB4D.namprd04.prod.outlook.com (2603:10b6:208:32b:cafe::8c) by BLAPR03CA0022.outlook.office365.com (2603:10b6:208:32b::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.19 via Frontend Transport; Tue, 3 Dec 2024 08:20:33 +0000 Received: from SATLEXMB04.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_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 08:20:32 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Tue, 3 Dec 2024 02:17: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: 79d08f79-b14f-11ef-a0d3-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HCasWjSrBn73oZePdaOjykvj9DvWfyLaNBvz4Pb65V2+d0slKzhKCtkau97Cj+F1gOjmzBsWv6TLpCyeSD/WI8hTXFu4v/alXuR9OBimag+c7POGBFYcYLM9+tq9I7ECQfC0dU+6Zn5IbcOR9oqcSp1KYNFBNWdtqW4bxUpN1uHpXU2UrDyd5arK4nTLfIYJM8/V9+YlrccIFF5O/9Oh42YeIDSo533NOc/0lOPOll0aGlQRgyfIvDXImhG0s15tfCUKMdAlj2mvrW1axAbwmUO3VReKXwtu6EmJUBHOctSu9TOU2XYMQk83D2ROXQWj2wz92gZVgV33KmpDiwh1qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0QP5qhZll8rzt3zPECYH2FuNf7IFpUiVXoJ+eD0kzQE=; b=YulXtlYwlYGAWLtwVoNft5q8dsXxCuFiA4hVUA1x7yPsIqckyAhkruBcwZP+Z7/5DNjbyTS39Uzda4mmljFSNSPS3p9uROd9YYiXMohr3RahaaQBy13H/FjhWDg52Rj8dkj6dBgLLaJ6D0//24+PNk/bDqGw9k7OOjZ3C93Y31gUkT/Nw8+LD13qqT7lK0kawPCJ2kS99mNHntvjjEOpRPOABNhDs64MpTZH6TBSTHUoQz4aWV/DlMV1H5YRIbQ1L5fqYUJ+IqM/myuvKTjTu4VcEmMdtxGKl28V4RugBEk0uW/augUODSAupOhWEXklFUBv68JE/N0RhpIYeEMOCg== 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=0QP5qhZll8rzt3zPECYH2FuNf7IFpUiVXoJ+eD0kzQE=; b=aCoskza9RnJbZJUb8uBVTJKSjfl3C9JlmbTimDbTVdACQ1zPsHjbtQdq9odInIcQIhsrJTDvGzzRGvRl55AdgUBd9ak4KaYqYzeBfQkxTsjCGqzQR8VAItNWU9vJUO9xruKiMHDlC529v2nmg6zTWmhW14GiCbzWYibSRtgSG14= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: CC: , , , , , Jan Beulich , Penny Zheng Subject: [PATCH v1 07/11] xen/cpufreq: only set gov NULL when cpufreq_driver.target() exists Date: Tue, 3 Dec 2024 16:11:07 +0800 Message-ID: <20241203081111.463400-8-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241203081111.463400-1-Penny.Zheng@amd.com> References: <20241203081111.463400-1-Penny.Zheng@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB4D:EE_|SJ1PR12MB6147:EE_ X-MS-Office365-Filtering-Correlation-Id: 4a14cf4d-fafb-492b-b2e9-08dd13735b4c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?921LlBPZ2eJqUf5e9rFmvuEBZkws5TWNjbo5XpuBJ49MYj+22OCW0g2Es5jX?= =?us-ascii?Q?c2w7ABRnXlhDnePGW069Fxgn2oGFYr3CjmP88fpzjAc1OR4qcI3okByYxLZ2?= =?us-ascii?Q?5hxaM7SL3Qkom7+ELaYh5LKX11TmyTz770V4UhZh+32clmQvV7q0wkasGoKa?= =?us-ascii?Q?f4aY8RPkyjEIv8Pi5HF327IwYfURVEL/ISoPrsBfnMjqLCB7GqLD8Wa/kyN7?= =?us-ascii?Q?5vjhuLGCoj+ZwlgM9zcS1IjKefbtBclpu4UgfvrYrchA2HNvi/4ShxRIog+w?= =?us-ascii?Q?in5zwfYb5ZQdVHuVZkxna2qjs038q60O82Zx4t3K2fxfWa/7MS8zicZ2itm4?= =?us-ascii?Q?w7AdKf9Bsm9VGud6RvmW2vc64vvhOfCpVLN/KUjBSkmic+/FaE+0ys4sm+xF?= =?us-ascii?Q?9IZW95jczw+GdFPF3Yv9XK4K8Oy6xOURkxR8Rw/hQnc59J0jqwc42cZfD+jB?= =?us-ascii?Q?PqH/7eI5O7hiQQ0t72MN0ZQRMkd/ScfAtosMo4zOAPnJ8Hgz2NNBPkKCN2CM?= =?us-ascii?Q?Iew7VwuwwkkYLoVJJzW9T1e5e1OzJEbqU5igIIkJJB9mwAbrI0x4x07SIPYN?= =?us-ascii?Q?XqL/JIgLDsbEtnorQ26L/INXcReLxgU3LdAfjK+yObwP1Bqbd5vyP1XCiTpi?= =?us-ascii?Q?uh1e2+4T8akMYjj8IKgwHDmp3pFdwGtnPrHU4guV4DEofVWeQdeginVc2eOu?= =?us-ascii?Q?jelko8Px+hBYU9AbU75QwKuTE8GCjdHNDsksDsijyswwrihx5jAxhHyCWMGc?= =?us-ascii?Q?fNIIQMnxDVwK1fNNPnTP4ARQ7EI/e3izyO2vvpsar3V+ohdOzRCvW+mqb+lE?= =?us-ascii?Q?0NeG/Yopa9RNRV8HxWZ7w/RAMcaI2MJMPM3ZSumgJaBXhBC+C8qY90J4P3r/?= =?us-ascii?Q?Sfnxv0DpculM3xGPftQYGKEQq4QGptHApZHrQ8QDyngqMmY7GsZWxz8N/Gjv?= =?us-ascii?Q?WidFbIo71oHf+ZR2z6krcW+MAuQAiJxHs2ugI1H1puQC2Aj8+xMiPTSarbdp?= =?us-ascii?Q?LsW1i4LrFPXj4Mdjj7v+wQ02oJj8jgMoHguK/yVnHHZC2wQWdx6pJCe/YfOR?= =?us-ascii?Q?5sXcKT1zayWFWKzRddn96W4qR0WxCSrHi8C3lSfQOREbNfAKTW3u0sRPSJ47?= =?us-ascii?Q?/auUK4HMmZelge5ppY8vQrUmvVpupAW0Cvk+sYGp1GyukfOldVcD1Q37VJiZ?= =?us-ascii?Q?1ghWHp7Eeu4TAeeQaKtz6g685IrO7R422HUmiWgrl0DZLZkgIoTUr1TGdanC?= =?us-ascii?Q?0aCGidAXUBZsyKUamvx888EOE4uRiF1j87KPJ0Y/RTcw+oXbDdtTvggdGGET?= =?us-ascii?Q?80WnVDxVrBzAtMPduc459fX9MVTfcBM67/dnURS6+b7W8PTYDwa1cbZDCYim?= =?us-ascii?Q?fYTF/eUM0KV8m5edTkKwaQwOxJUtktVFRjhd4ca9YrQq9Ied5gAOhdJWxTI5?= =?us-ascii?Q?huK1LLrvoe+y6HiOxhy2+6J1ooidbynL?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 08:20:32.9773 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4a14cf4d-fafb-492b-b2e9-08dd13735b4c 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=[SATLEXMB04.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: SJ1PR12MB6147 From: Penny Zheng amd-pstate on active mode bypasses the scaling governor layer, and provides its own P-state selection algorithms. Consequently, when it is used, the driver's -> setpolicy() callback is invoked to register per-CPU utilization update callbacks, not the ->target() callback. So, only when cpufreq_driver.target() exists, we need to deliberately set old gov as NULL to trigger the according gov starting. Signed-off-by: Penny Zheng --- xen/drivers/cpufreq/cpufreq.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c index 54d554aa4f..c170a2cb2b 100644 --- a/xen/drivers/cpufreq/cpufreq.c +++ b/xen/drivers/cpufreq/cpufreq.c @@ -316,7 +316,13 @@ int cpufreq_add_cpu(unsigned int cpu) if (hw_all || (cpumask_weight(cpufreq_dom->map) == perf->domain_info.num_processors)) { memcpy(&new_policy, policy, sizeof(struct cpufreq_policy)); - policy->governor = NULL; + + /* + * Only when cpufreq_driver.target exists, we need to deliberately set old gov as NULL + * to trigger the according gov starting. + */ + if ( cpufreq_driver.target ) + policy->governor = NULL; cpufreq_cmdline_common_para(&new_policy); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 08:22:19 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 08:22:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847324.1262488 (Exim 4.92) (envelope-from ) id 1tIOAl-0002DL-21; Tue, 03 Dec 2024 08:22:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847324.1262488; Tue, 03 Dec 2024 08:22: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 1tIOAk-0002Cw-T7; Tue, 03 Dec 2024 08:22:18 +0000 Received: by outflank-mailman (input) for mailman id 847324; Tue, 03 Dec 2024 08:22: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 1tIOAj-000271-9h for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 08:22:17 +0000 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2061c.outbound.protection.outlook.com [2a01:111:f403:2414::61c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b41e465d-b14f-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 09:22:16 +0100 (CET) Received: from CH2PR04CA0026.namprd04.prod.outlook.com (2603:10b6:610:52::36) by IA1PR12MB8079.namprd12.prod.outlook.com (2603:10b6:208:3fb::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 08:22:10 +0000 Received: from DS3PEPF000099E2.namprd04.prod.outlook.com (2603:10b6:610:52:cafe::e) by CH2PR04CA0026.outlook.office365.com (2603:10b6:610:52::36) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.18 via Frontend Transport; Tue, 3 Dec 2024 08:22:10 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by DS3PEPF000099E2.mail.protection.outlook.com (10.167.17.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 08:22:09 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Tue, 3 Dec 2024 02:18:32 -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: b41e465d-b14f-11ef-a0d3-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=PZpvVohbClks+20ir+fgAFpRF1CEOAjAMP+JPJq3QuomFFphqMRrYTowrd+yOU8zPBkjuPlmTjisIT3LLliFjTipkBgS9X4yAYO0aXRDe8Ys6z4BQPHlwnLeGiuJO1rH/B6BwWU4IrclMaWR6dwa2tkVDMUSKqJWae+spamFXBDkYLVOEYleQq2BivEhwzIxBYdU8GxA6KCJJmsZPHOsWpBrFbJAqB+FffJuZDzWNCipJBp6vu4ov+N+AFbte2k5QN1T84S++sKbfFvm/675gkdtak0ZQumjXK1b91bItWRwFiRBe30tQdjLT+EAFDQr7F5qTRNL9rQZ0WFJqAul8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ruSsC38qnvGR7EDsFK/ZZZZT5Bp/vYDQpQsoiYuXqPY=; b=pObgZN9d+Q3EhqlE17BJX1r3wFhHpGRHGZwy7KyWbwE6JsQCMBlGnLaAN6EmItDN2ikKNEHz1mkKOR4kJt4CyWTyVJA9IpNCldVUt7VxwK349Sez3PZAS9TFVV99AEYspjoaxR2O5U2T3+NoRcNYnX2/3wOlLfQC+cV+R0pELUJsTp8nweutueG5Z6vSN6yRgyPTSjRQVAjpNwlki3y333bhf+JezHLVCMfy5XMs1JxmPOdutYPUaf3sIyZ9+OHDCEo5CRtQ0IMZbbL7BtKkNl5wgwsDISsNOI/MrLdu+UraVIygUTcgK/XUnqcxYy+BLPKrdDpXLqvtjjStT9hcJg== 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=ruSsC38qnvGR7EDsFK/ZZZZT5Bp/vYDQpQsoiYuXqPY=; b=VVZzEPD9yFlEXRnkI585m42RSgNqMf0NFiKMlo+PMoPTpan3LtSPCJjDKtWGzVEMJjZOA4/VaY9txFyFPBw4XuSZLxAm560AdkZiQfhbOZyss3EEtD5bdDzoQ2eAtVQj+zj7YGLxv5YZgDghc9wquQVxcK09KxfYqEtwPF9rwJY= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: CC: , , , , , Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Penny Zheng Subject: [PATCH v1 08/11] x86/cpufreq: add "cpufreq=amd-pstate,active" para Date: Tue, 3 Dec 2024 16:11:08 +0800 Message-ID: <20241203081111.463400-9-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241203081111.463400-1-Penny.Zheng@amd.com> References: <20241203081111.463400-1-Penny.Zheng@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS3PEPF000099E2:EE_|IA1PR12MB8079:EE_ X-MS-Office365-Filtering-Correlation-Id: 34af70fd-8b9a-4079-f29c-08dd13739512 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|36860700013|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?4E+nIAjoNAy+H4HRoYS8Irc56tgy5OUSyaKi0dM5DCmc0J6yHUYfRbvOp5+H?= =?us-ascii?Q?tcsSkSPFML/nkHEv5r/yPxedR+/k5tDmyLrJApM5LdI2p9Fy0OFy3Rv8ALZU?= =?us-ascii?Q?W71dtr01WH5CBbatPXMA6DQnXXQvYcuM69lrNHtazDhhRZpcPanV5q9ZavNj?= =?us-ascii?Q?OxZfo9hk+ibI/Jhwy0rNtDQiT9NLoHJDGaIKPrdbqUYX0+GD+JfJ4uLEMblE?= =?us-ascii?Q?sbXrskTQVEJxlClFNjD5XU7liK7mPJ964vQZBmRUSxULNKpgTI9YbrBVNXBv?= =?us-ascii?Q?hnZuCP17Lx2e7qWv1pZbFfClov3VBJDtk4alnJo7bb/Tw+ke/S353x0MkdbV?= =?us-ascii?Q?dUqs5Pb2rIep57CpjqTI8i3mMv7DxRUiaHcdjlp+O5QRk8iiIRrwSUj3fLZ1?= =?us-ascii?Q?IKA9BldAYLFIJB5fNU7mlBEb4iWAkJJ6HwbGLeMQDRqKfXvgLKbsdhr5GMl2?= =?us-ascii?Q?rTM+o+Y/ROEiWSw1JwBtvYhIBS+VAvPQXqgyhUNBaf/xOifULMKfQWmXpRDh?= =?us-ascii?Q?3knwsCWqP0JkCF4vvJbs+QIn8MfQD0LD+M4EmQ73nyZUvj0iv+Ro5lZNBruR?= =?us-ascii?Q?dd4pXUqMo3Cq78miV7XpKPOAQgLb79oFQR/XrAWbOj+ujo5+7CIno5nAnc8F?= =?us-ascii?Q?J/XIQ9naiCczcStwBBr/4Rbn9Whr/XthQmrluevDoDUJF1YT7OwZvXRsObDz?= =?us-ascii?Q?M2mCDdy7hYkEnsRU73ANFMrAVkZS9Klrb9Kk77/FQfwcjC97H5p9Eoh9srKl?= =?us-ascii?Q?JQjOoQOES4iaEwwjiw4fhEdt3hpLqzCWlcSzYJt92tDTYw6IRrz9EmhHFf8m?= =?us-ascii?Q?sYKiWRy2qco0FU4V2D0h+pQLD4PS3czaXgmItc4Xp3b3EANmpKYnibC5v3YV?= =?us-ascii?Q?vdoDfn3ct7ILUT+wNopG2N99l6UDTTGVK9XU8k4M2D2MVR3y0uvf9adwzE8b?= =?us-ascii?Q?K+qUHpr3va7zqL+QMnY5ZMH2vrocZ2hNcbFiN/ZENk5RZsd5/kttHc/6nYoE?= =?us-ascii?Q?00nij0SYP1r8AyISqVILCCPHMZKoCJ7IxjvJ1oQowfpvEnZIbvfRlyX7OuKS?= =?us-ascii?Q?srN5BB4g44jC/tjt3yKSMk+JZBikZjPzRrDOkBipkMn57NUHDrt9FH9KVa7p?= =?us-ascii?Q?qDS7DSElTfSBcRbLM6EJGoJHk/Rf/7P2WHdJ51/UzOcqxwpO//9vJEGfIfS3?= =?us-ascii?Q?ZqXjMePN+x+8m4EaOlQ6lvSfQVSaTYMgJ1EN4bJi4Kj+zBpG+ztoxAlHnhai?= =?us-ascii?Q?9veWTwPN1wEbNv7nl7y09mE04FuN/18RXKG5W6+K2NB2m1aGR0DCr9+0W+pn?= =?us-ascii?Q?aVd8o3+LeJr7vsCC1jJwLYANrCnMN1REHITP/eg7D0uq/EpMWCptZj2gSePV?= =?us-ascii?Q?F6xWzeWouBUBxmPz2i3LzSgJO/dATBQ00/CZdrExdsevs6tog8QKw1uJEIIO?= =?us-ascii?Q?6dmmSoDa+mdW03aei7BUz5vAyTwpkBoW?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 08:22:09.8910 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 34af70fd-8b9a-4079-f29c-08dd13739512 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DS3PEPF000099E2.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8079 From: Penny Zheng The amd-pstate driver may support multiple working modes, passive and active. Introduce a new variable to keep track of which mode is currently enabled. This variable will also help to choose which cpufreq driver to be registered. Signed-off-by: Penny Zheng --- docs/misc/xen-command-line.pandoc | 9 ++++++++- xen/arch/x86/acpi/cpufreq/amd-pstate.c | 12 +++++++++++- 2 files changed, 19 insertions(+), 2 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 30f855fa18..a9a3e0ef79 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -499,7 +499,8 @@ If set, force use of the performance counters for oprofile, rather than detectin available support. ### cpufreq -> `= none | {{ | xen } { [:[powersave|performance|ondemand|userspace][,[]][,[]]] } [,verbose]} | dom0-kernel | hwp[:[][,verbose]] | amd-pstate[:[verbose]]` +> `= none | {{ | xen } { [:[powersave|performance|ondemand|userspace][,[]][,[]]] } +[,verbose]} | dom0-kernel | hwp[:[][,verbose]] | amd-pstate[:[active][,verbose]]` > Default: `xen` @@ -522,6 +523,12 @@ choice of `dom0-kernel` is deprecated and not supported by all Dom0 kernels. on supported AMD hardware to provide a finer grained frequency control mechanism. The default is disabled. If `amd-pstate` is selected, but hardware support is not available, Xen will fallback to cpufreq=xen. +* `active` is a boolean to enable amd-pstate driver in active(autonomous) mode. + In this mode, users could provide a hint with energy performance preference + register to the hardware if they want to bias toward performance(0x0) or + energy efficiency(0xff), then CPPC power algorithm will calculate the runtime + workload and adjust the realtime cores frequency according to the power supply + and themal, core voltage and some other hardware conditions. There is also support for `;`-separated fallback options: `cpufreq=hwp;xen,verbose`. This first tries `hwp` and falls back to `xen` if diff --git a/xen/arch/x86/acpi/cpufreq/amd-pstate.c b/xen/arch/x86/acpi/cpufreq/amd-pstate.c index 5dfa35581a..43abdd8636 100644 --- a/xen/arch/x86/acpi/cpufreq/amd-pstate.c +++ b/xen/arch/x86/acpi/cpufreq/amd-pstate.c @@ -27,6 +27,8 @@ #define amd_pstate_warn(fmt, args...) \ printk(XENLOG_WARNING "AMD_PSTATE: CPU%u warning: " fmt, cpu, ## args) +static bool __ro_after_init opt_cpufreq_active = false; + struct amd_pstate_drv_data { struct xen_processor_cppc *cppc_data; @@ -76,6 +78,13 @@ static bool __init amd_pstate_handle_option(const char *s, const char *end) return true; } + ret = parse_boolean("active", s, end); + if ( ret >= 0 ) + { + opt_cpufreq_active = ret; + return true; + } + return false; } @@ -398,5 +407,6 @@ int __init amd_pstate_register_driver(void) if ( !cpu_has_cppc ) return -ENODEV; - return cpufreq_register_driver(&amd_pstate_cpufreq_driver); + if ( !opt_cpufreq_active ) + return cpufreq_register_driver(&amd_pstate_cpufreq_driver); } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 08:25:30 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 08:25:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847374.1262498 (Exim 4.92) (envelope-from ) id 1tIODp-0004rd-Li; Tue, 03 Dec 2024 08:25:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847374.1262498; Tue, 03 Dec 2024 08: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 1tIODp-0004rW-Iv; Tue, 03 Dec 2024 08:25:29 +0000 Received: by outflank-mailman (input) for mailman id 847374; Tue, 03 Dec 2024 08:25: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 1tIODo-0004rQ-EO for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 08:25:28 +0000 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on20618.outbound.protection.outlook.com [2a01:111:f403:2414::618]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 25a3e7c2-b150-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 09:25:26 +0100 (CET) Received: from BLAPR05CA0005.namprd05.prod.outlook.com (2603:10b6:208:36e::14) by CH0PR12MB8530.namprd12.prod.outlook.com (2603:10b6:610:188::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.17; Tue, 3 Dec 2024 08:25:20 +0000 Received: from BL02EPF0001A105.namprd05.prod.outlook.com (2603:10b6:208:36e:cafe::60) by BLAPR05CA0005.outlook.office365.com (2603:10b6:208:36e::14) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.8 via Frontend Transport; Tue, 3 Dec 2024 08:25:20 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by BL02EPF0001A105.mail.protection.outlook.com (10.167.241.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 08:25:20 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Tue, 3 Dec 2024 02:18:59 -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: 25a3e7c2-b150-11ef-a0d3-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=pOh0pbkD/pccWa6LSOkuFNQOXUbkhVnnL5tOmw+BUwFkQQg9o511AbB/k5/VsB6O1UPVPDUaKm75x+3v8yJIbDXBnv8dcMiXGcJxoEOhPzDBcLpcSRB66N7FkZVUjP5te3ugh9nyloEAEv0TI2MgqpJvHd4xqqf9uXezGoDezxy6gzSY/nWITAKklVx6ade+ROj4bx7v3FtkwMBBRZfQN/NspLoo4d5aKk8vv9Bua/6M36MifhUlnY1JLaZXdgh/kMhIzMpolQ4g43mqN7Dt6szBRjQMZC+DzYYPspccDMKd+4u9leGAYypFtSXw1lcVQoz0Lb3Ci4EDjS5LWdKgEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=T4dJCl26eHmCdRb0RKikZAAPzPCXi7jxKKOsNs/5cWE=; b=Qfey+JeGPHx0jIy1QcrsGnSaZJxDrBmhYunVJlgUUUvEMpgvZJbwlm0niuR+eKFCsDBoc23ewuLWDJENeN+KtxjqLqPc6BUiyqDgnU7hYx0qFpi66MHsBU38+G6h31YdaskjeOsUIgMzGylcvc03Ti0gbqhbdG8RM3mernWdpMH0kpByXM6ZRPRBdeSUV6eU4LIhGPFJ3VjQPmKEm575ID/Zz5FeY5InG7qXc9Wa9GGutlivvGy4hdNqRqEk2sYB1FVVkiruzqdwKho8X7ZByP6B2XparaqsnG8aa4Tk65CFaypA1S5Zu/faapcUsWNWmu5179D5n02mINBG7oI3zg== 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=T4dJCl26eHmCdRb0RKikZAAPzPCXi7jxKKOsNs/5cWE=; b=JGQ8nH8z4QGsYpHNbMdSDQvD+Xoa/EMe0UXgfHzIFlEnRD4vjyZHHAJM1BKuQ4H2u/3xiGzOzi+30asfrAdxEPiCVfKPynOOZb31j/EaAEvTEMsUl4Uu06DyGN2C9eMCpN/KP429so875o4SMqMe8alnC/B/fwGYB3yTHVGuEEM= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: CC: , , , , , Penny Zheng , Jan Beulich , "Andrew Cooper" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julien Grall , Stefano Stabellini Subject: [PATCH v1 09/11] xen/x86: implement EPP support for the AMD processors Date: Tue, 3 Dec 2024 16:11:09 +0800 Message-ID: <20241203081111.463400-10-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241203081111.463400-1-Penny.Zheng@amd.com> References: <20241203081111.463400-1-Penny.Zheng@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF0001A105:EE_|CH0PR12MB8530:EE_ X-MS-Office365-Filtering-Correlation-Id: e9f9b21e-0211-4b0a-579f-08dd1374068f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?mii5nmVtQOUzMQRU7LY5WkFE44Dmii+pDmEMQah706N/LK7vBIBKcliIWKgD?= =?us-ascii?Q?zFOXeqGB/N5yodCnlzNvu37cgS2Sg4YQjq7nXgNo9rWLzOQ4/PCw7JfN+rRr?= =?us-ascii?Q?kYtBqX7waFSqP5arYKmVKGRrnc+JGhq3USFu3UzK2tyyisRNgqvdE7Ezwb0H?= =?us-ascii?Q?GC9ZgGSEWmFJkAuiQDA7lFpftKX6M6tXO9WWj9Xo6/bMXZv4/KiIZGdHXrAq?= =?us-ascii?Q?YoZlWqibgIIX4dGanVBM/zCsEClgI5J7JDfsWV6DqmyJbKHQunu1JnfRqqsb?= =?us-ascii?Q?8OXrxZUrgSySOgIOnbU717ggAWzOomLM+cMlTwzHX69P04KwVRAHO8ZR/WUP?= =?us-ascii?Q?5Ws1sanJX38M8SKnT042EgqXM+43fRsrpX18PDTjDH6EK3dlwnOZw0uuFHhK?= =?us-ascii?Q?2o+bvcercbhAQ1Y3rAC4Rp7M2BRqAHuyJ4pCypr8EJf5zerLExi1z1lxeOrk?= =?us-ascii?Q?CALhzXjf8qNwFhoCF23b1/C6jh890hKxAGmFuJQZf//rQ1Kn208HnWv3jo/+?= =?us-ascii?Q?Eqckm5gXZHVyIlemCveTwMFBfj04TNbjz0mc80pU3w6JBXAEy8y39tD6AsJg?= =?us-ascii?Q?H02Rl9COzq1jRa2E4oji+/Q2St0S9aLu4j7F3pd/TlrEn/+4e/fllogFlI3d?= =?us-ascii?Q?bvrTAq6GJukrXa0hbwoBYi4NOFRX2x4vE4T2x+8LjR+yC3/zoZFThdYWRJkg?= =?us-ascii?Q?GxC0RYetFv83vKXSBqzaRTMqlyiMGPjx1BEywimMwNwV0j+0yhteFlgUhBcr?= =?us-ascii?Q?swQNPkJ6fg20zitjFFPQtPZS3TlV99dNmmidp5sXfj6y4+6QggeT/2pKSwKt?= =?us-ascii?Q?aybcGqw7D5jVYH+S6e4KcFrI20G4mn8NK8jniYb04acVEHC7lz/swOKVM0gD?= =?us-ascii?Q?K/DxkyDHyF4MpzLQK6ML44lADFOtyIzf+3G+hskfr/EUENVqnpxPAbzLcpL2?= =?us-ascii?Q?3u9YQvAcz2ZK6TkWMGrULmBS/foUT+BvEgjZSQ1Argha7gZ4T9Gcaj9ln9NU?= =?us-ascii?Q?1k1JwQB7ZuU+RNjeEvw5h+/t8//8vfgINCgN6LglgMnFWM7Uo1VoXnjz4r3Y?= =?us-ascii?Q?rLEW8uXd/s8DM/w8AX9HJiKgOitLTyVCsKcqznhus7rrrKKWxKrlatqUd0On?= =?us-ascii?Q?3BvzhQdE/IoFS44COZZvjkvpe6y3uqvgAEO7ADyJ+YiAwd8KFoOexjt9da4O?= =?us-ascii?Q?ce3pbh1U1kcTQh0m0SXlPXxxHWFRSYFeOIhPPYxczmK2ip/uNgrABd5/B5Iu?= =?us-ascii?Q?qzO6UX3XBhLQl26rIDzi3zJ9OS7iVSC0zJUxORV3GA6yd+vxE8ueVI2UR1Jw?= =?us-ascii?Q?m1A3IMC6uUGKn0rmG8OqUAL0Apnl4beWfwAdY3KbhVIAXoggFLQ85MPzTpkr?= =?us-ascii?Q?INMy/PYCKPbRcV6DqrzFRUQIYhlU44zBqwDG3JUoSKso6CzP4ZHACWqC8Q9m?= =?us-ascii?Q?xk2l6s5ovQ2cB5/45+D+zUobZr6uYy4Y?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 08:25:20.3044 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e9f9b21e-0211-4b0a-579f-08dd1374068f 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL02EPF0001A105.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR12MB8530 amd-pstate has 2 operation modes: autonomous (active) mode, non-autonomous (passive) mode. In active mode, platform ignores the requestd done in the Desired Performance Target register and takes into account only the values set to the minimum, maximum and energy performance preference(EPP) registers. The EPP is used in the CCLK DPM controller to drive the frequency that a core is going to operate during short periods of activity. The SOC EPP targets are configured on a scale from 0 to 255 where 0 represents maximum performance and 255 represents maximum efficiency. This commit implements one new AMD CPU frequency driver `amd-pstate-epp` for active mode. Signed-off-by: Penny Zheng --- xen/arch/x86/acpi/cpufreq/amd-pstate.c | 122 +++++++++++++++++++++++-- xen/arch/x86/acpi/cpufreq/hwp.c | 10 +- xen/include/acpi/cpufreq/cpufreq.h | 5 + xen/include/public/sysctl.h | 2 +- 4 files changed, 125 insertions(+), 14 deletions(-) diff --git a/xen/arch/x86/acpi/cpufreq/amd-pstate.c b/xen/arch/x86/acpi/cpufreq/amd-pstate.c index 43abdd8636..40ecd04259 100644 --- a/xen/arch/x86/acpi/cpufreq/amd-pstate.c +++ b/xen/arch/x86/acpi/cpufreq/amd-pstate.c @@ -57,6 +57,8 @@ struct amd_pstate_drv_data } req; }; int err; + /* EPP feature related attributes */ + unsigned int policy; uint32_t max_freq; uint32_t min_freq; @@ -67,6 +69,8 @@ static DEFINE_PER_CPU_READ_MOSTLY(struct amd_pstate_drv_data *, amd_pstate_drv_d uint16_t __read_mostly dmi_max_speed_mhz; +static bool __ro_after_init epp_mode; + static bool __init amd_pstate_handle_option(const char *s, const char *end) { int ret; @@ -223,14 +227,29 @@ static void amd_pstate_write_request_msrs(void *info) } static int cf_check amd_pstate_write_request(int cpu, uint8_t min_perf, - uint8_t des_perf, uint8_t max_perf) + uint8_t des_perf, uint8_t max_perf, + int epp) { struct amd_pstate_drv_data *data = per_cpu(amd_pstate_drv_data, cpu); - uint64_t prev = data->amd_req; + uint64_t prev = data->amd_req, val; data->req.min_perf = min_perf; data->req.max_perf = max_perf; - data->req.des_perf = des_perf; + if ( !epp_mode ) + data->req.des_perf = des_perf; + else + { + data->req.des_perf = 0; + /* Get pre-defined BIOS value */ + if ( epp < 0 ) + { + if ( rdmsr_safe(MSR_AMD_CPPC_REQ, val) ) + return -EINVAL; + data->req.epp = (val >> 24) & 0xFF; + } + else + data->req.epp = epp; + } if ( prev == data->amd_req ) return 0; @@ -257,7 +276,7 @@ static int cf_check amd_pstate_cpufreq_target(struct cpufreq_policy *policy, min_perf = data->hw.lowest_nonlinear_perf; des_perf = amd_pstate_khz_to_perf(data, target_freq); - return amd_pstate_write_request(policy->cpu, min_perf, des_perf, max_perf); + return amd_pstate_write_request(policy->cpu, min_perf, des_perf, max_perf, -1); } static void cf_check amd_pstate_init_msrs(void *info) @@ -354,7 +373,7 @@ static void amd_pstate_boost_init(struct cpufreq_policy *policy, struct amd_psta policy->turbo = CPUFREQ_TURBO_ENABLED; } -static int cf_check amd_pstate_cpufreq_cpu_init(struct cpufreq_policy *policy) +static int amd_pstate_cpufreq_init_perf(struct cpufreq_policy *policy) { unsigned int cpu = policy->cpu; struct amd_pstate_drv_data *data; @@ -379,10 +398,23 @@ static int cf_check amd_pstate_cpufreq_cpu_init(struct cpufreq_policy *policy) return -ENODEV; } - amd_pstate_boost_init(policy, data); return 0; } +static int cf_check amd_pstate_cpufreq_cpu_init(struct cpufreq_policy *policy) +{ + int ret = 0; + struct amd_pstate_drv_data *data; + + ret = amd_pstate_cpufreq_init_perf(policy); + if ( ret ) + return ret; + + data = per_cpu(amd_pstate_drv_data, policy->cpu); + amd_pstate_boost_init(policy, data); + return ret; +} + static int cf_check amd_pstate_cpufreq_cpu_exit(struct cpufreq_policy *policy) { struct amd_pstate_drv_data *data = per_cpu(amd_pstate_drv_data, policy->cpu); @@ -393,6 +425,70 @@ static int cf_check amd_pstate_cpufreq_cpu_exit(struct cpufreq_policy *policy) return 0; } +static void amd_perf_ctl_reset(void *data) +{ + wrmsr_safe(MSR_K8_PSTATE_CTRL, 0); +} + +static int cf_check amd_pstate_epp_cpu_init(struct cpufreq_policy *policy) +{ + int ret = 0; + struct amd_pstate_drv_data *data; + + /* + * Resetting P-State Control register will put the CPU in P0 frequency, + * which is ideal for initialization process. + */ + on_selected_cpus(cpumask_of(policy->cpu), amd_perf_ctl_reset, NULL, 1); + + ret = amd_pstate_cpufreq_init_perf(policy); + if ( ret ) + return ret; + + data = per_cpu(amd_pstate_drv_data, policy->cpu); + + policy->policy = cpufreq_parse_policy(policy->governor); + + amd_pstate_boost_init(policy, data); + + amd_pstate_verbose("CPU %u initialized with amd-pstate active mode\n", policy->cpu); + + return 0; +} + +static int cf_check amd_pstate_epp_update_limit(struct cpufreq_policy *policy) +{ + struct amd_pstate_drv_data *data = per_cpu(amd_pstate_drv_data, policy->cpu); + uint8_t max_perf, min_perf, des_perf; + int epp = -1; + + /* Initial min/max values for CPPC Performance Controls Register */ + max_perf = data->hw.highest_perf; + min_perf = data->hw.lowest_perf; + + if ( data->policy == CPUFREQ_POLICY_PERFORMANCE ) + min_perf = max_perf; + + /* CPPC EPP feature require to set zero to the desire perf bit */ + des_perf = 0; + + if ( data->policy == CPUFREQ_POLICY_PERFORMANCE ) + /* Force the epp value to be zero for performance policy */ + epp = CPPC_ENERGY_PERF_MAX_PERFORMANCE; + else if ( data->policy == CPUFREQ_POLICY_POWERSAVE ) + /* Force the epp value to be 0xff for powersave policy */ + epp = CPPC_ENERGY_PERF_MAX_POWERSAVE; + + return amd_pstate_write_request(policy->cpu, min_perf, des_perf, max_perf, epp); +} + +static int cf_check amd_pstate_epp_set_policy(struct cpufreq_policy *policy) +{ + amd_pstate_verbose("Set new policy for CPU %u\n", policy->cpu); + + return amd_pstate_epp_update_limit(policy); +} + static const struct cpufreq_driver __initconstrel amd_pstate_cpufreq_driver = { .name = XEN_AMD_PSTATE_DRIVER_NAME, @@ -402,6 +498,15 @@ static const struct cpufreq_driver __initconstrel amd_pstate_cpufreq_driver = .exit = amd_pstate_cpufreq_cpu_exit, }; +static const struct cpufreq_driver __initconstrel amd_pstate_epp_driver = +{ + .name = XEN_AMD_PSTATE_EPP_DRIVER_NAME, + .verify = amd_pstate_cpufreq_verify, + .setpolicy = amd_pstate_epp_set_policy, + .init = amd_pstate_epp_cpu_init, + .exit = amd_pstate_cpufreq_cpu_exit, +}; + int __init amd_pstate_register_driver(void) { if ( !cpu_has_cppc ) @@ -409,4 +514,9 @@ int __init amd_pstate_register_driver(void) if ( !opt_cpufreq_active ) return cpufreq_register_driver(&amd_pstate_cpufreq_driver); + else + { + epp_mode = true; + return cpufreq_register_driver(&amd_pstate_epp_driver); + } } diff --git a/xen/arch/x86/acpi/cpufreq/hwp.c b/xen/arch/x86/acpi/cpufreq/hwp.c index 59b57a4cef..d5fa3d47ca 100644 --- a/xen/arch/x86/acpi/cpufreq/hwp.c +++ b/xen/arch/x86/acpi/cpufreq/hwp.c @@ -21,10 +21,6 @@ static bool __ro_after_init feature_hdc; static bool __ro_after_init opt_cpufreq_hdc = true; -#define HWP_ENERGY_PERF_MAX_PERFORMANCE 0 -#define HWP_ENERGY_PERF_BALANCE 0x80 -#define HWP_ENERGY_PERF_MAX_POWERSAVE 0xff - union hwp_request { struct @@ -597,7 +593,7 @@ int set_hwp_para(struct cpufreq_policy *policy, data->minimum = data->hw.lowest; data->maximum = data->hw.lowest; data->activity_window = 0; - data->energy_perf = HWP_ENERGY_PERF_MAX_POWERSAVE; + data->energy_perf = CPPC_ENERGY_PERF_MAX_POWERSAVE; data->desired = 0; break; @@ -605,7 +601,7 @@ int set_hwp_para(struct cpufreq_policy *policy, data->minimum = data->hw.highest; data->maximum = data->hw.highest; data->activity_window = 0; - data->energy_perf = HWP_ENERGY_PERF_MAX_PERFORMANCE; + data->energy_perf = CPPC_ENERGY_PERF_MAX_PERFORMANCE; data->desired = 0; break; @@ -613,7 +609,7 @@ int set_hwp_para(struct cpufreq_policy *policy, data->minimum = data->hw.lowest; data->maximum = data->hw.highest; data->activity_window = 0; - data->energy_perf = HWP_ENERGY_PERF_BALANCE; + data->energy_perf = CPPC_ENERGY_PERF_BALANCE; data->desired = 0; break; diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h index cad27f6811..d2a74d8315 100644 --- a/xen/include/acpi/cpufreq/cpufreq.h +++ b/xen/include/acpi/cpufreq/cpufreq.h @@ -83,6 +83,7 @@ struct cpufreq_policy { int8_t turbo; /* tristate flag: 0 for unsupported * -1 for disable, 1 for enabled * See CPUFREQ_TURBO_* below for defines */ + unsigned int policy; }; DECLARE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_policy); @@ -264,6 +265,10 @@ void cpufreq_dbs_timer_resume(void); void intel_feature_detect(struct cpufreq_policy *policy); +#define CPPC_ENERGY_PERF_MAX_PERFORMANCE 0 +#define CPPC_ENERGY_PERF_BALANCE 0x80 +#define CPPC_ENERGY_PERF_MAX_POWERSAVE 0xff + int hwp_cmdline_parse(const char *s, const char *e); int hwp_register_driver(void); #ifdef CONFIG_INTEL diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h index df4f362681..74f73a6bba 100644 --- a/xen/include/public/sysctl.h +++ b/xen/include/public/sysctl.h @@ -425,7 +425,7 @@ struct xen_set_cppc_para { #define XEN_HWP_DRIVER_NAME "hwp" #define XEN_AMD_PSTATE_DRIVER_NAME "amd-pstate" - +#define XEN_AMD_PSTATE_EPP_DRIVER_NAME "amd-pstate-epp" /* * cpufreq para name of this structure named * same as sysfs file name of native linux -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 08:27:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 08:27:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847390.1262508 (Exim 4.92) (envelope-from ) id 1tIOFO-0005PK-0K; Tue, 03 Dec 2024 08:27:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847390.1262508; Tue, 03 Dec 2024 08:27:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIOFN-0005PD-TS; Tue, 03 Dec 2024 08:27:05 +0000 Received: by outflank-mailman (input) for mailman id 847390; Tue, 03 Dec 2024 08:27: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 1tIOFN-0005P7-4C for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 08:27:05 +0000 Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [2a00:1450:4864:20::643]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5f16c1eb-b150-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 09:27:02 +0100 (CET) Received: by mail-ej1-x643.google.com with SMTP id a640c23a62f3a-aa51d32fa69so801663866b.2 for ; Tue, 03 Dec 2024 00:27:03 -0800 (PST) Received: from andrewcoop.eng.citrite.net ([90.240.255.120]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5996de56dsm588159466b.79.2024.12.03.00.27.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Dec 2024 00:27: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: 5f16c1eb-b150-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1733214422; x=1733819222; 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=n4RYmB97U5RP7D/ueIKFiK5qjFE/edcdOpxPRLmG8lE=; b=i9rwJ+AD4HDSy22qCVQOzjsAvmvSyf6o7hExMHr2IvYaCLqYproZXMnkF5tPZVTrgD 2gYjWVt7UBOkTK6hSUzr0w7rhezB0YriJLziAAB71Iim9xHtYkvK4Qma2Ux4Q2LbuJJt Hgbn6lD5j726DPaTus2ComrI0qKcwOY+ujyjM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733214422; x=1733819222; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=n4RYmB97U5RP7D/ueIKFiK5qjFE/edcdOpxPRLmG8lE=; b=g9oOoXbF0Aa/PZRb0FVZCadSjNcC/ye0jrPm/4E+KDz8y2+zuRPNb0NAKRBI3Au3+t tY2iDRsMgf/FV750yNFICz3jy1Qm8M887O1HPLC6BhMWwxz2LUNOEbhfwulKtlAfdH8i WIhxzJkhe2pYh6yspQU72JEYUf8TOe2YafN08qcrO/mJYSQOsmWGh4Z04/87uhXyney+ fGQiXcf//m8YOux5stE+PvczOuQx/FhQQdSkbKutZhj/Ger8X1R6VQRQFE8nOsgMTtKs MJFPkk8PO/dwOEaqGzzuIs4+L+1c94RIwc1R3anEbXW660wzvej/3xzC1zd6rKizp2GK jT9Q== X-Gm-Message-State: AOJu0YxjuyKDpgVgGWyZC3i/+Ees9qShAEADBVfoSJIlktuD9ho5gpbB 0bfZqxSprEfObBxavLI+BJ9tN6zf8HcrzSkmDuBO4y/i7/44kpZ1FNw4jeg22hW7qTOi3IJB9VC x0U9eKw== X-Gm-Gg: ASbGncuB0XO7XHkHgebIy3woNmtEM24t29MrhU7i38jLLPlIktpYBNKB7PCRRedFu2D 4qAHhFPMetDcXtMtLPT9bD9N8+yN+TT4fez2a/xdCKZEBD+UxEGMNV14YTmWb+DVkVIC2+sp/fT uPPbsu2vIniH2Vmhq6GkW+Vp1dBb3BuGXfc1yDcGA3PWwQZgKS8nJ7UMY7zQUmCi79WBIE7VzDk kHNSCh/o9FvftqDf5YgFowgphnIPfjA7zbj7a5eYEE5gCqEabuxwL/PGknUfc4bYfNqUM0ObT1U 6w== X-Google-Smtp-Source: AGHT+IGUwKfLjT46BhetCnRPGSUz0vRn7TLNlnwBDiPpNtB3xRVG33KctAZBTJBeucMddG0pA8eJiw== X-Received: by 2002:a17:907:7814:b0:a9a:b70:2a92 with SMTP id a640c23a62f3a-aa5f7d47a36mr112660666b.16.1733214422048; Tue, 03 Dec 2024 00:27:02 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD , Stefano Stabellini Subject: [PATCH] CI: Update to FreeBSD 14.2 Date: Tue, 3 Dec 2024 08:26:58 +0000 Message-Id: <20241203082658.134073-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 Signed-off-by: Andrew Cooper --- CC: Roger Pau Monné CC: Anthony PERARD CC: Stefano Stabellini https://cirrus-ci.com/task/5913096629256192 --- .cirrus.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.cirrus.yml b/.cirrus.yml index 00e4c57678c2..4a120fad41b2 100644 --- a/.cirrus.yml +++ b/.cirrus.yml @@ -24,7 +24,7 @@ task: task: name: 'FreeBSD 14' freebsd_instance: - image_family: freebsd-14-1 + image_family: freebsd-14-2 << : *FREEBSD_TEMPLATE task: base-commit: 126b0a6e537ce1d486a29e35cfeec1f222a74d11 -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 08:32:31 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 08:32:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847434.1262518 (Exim 4.92) (envelope-from ) id 1tIOKY-0007oQ-IS; Tue, 03 Dec 2024 08:32:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847434.1262518; Tue, 03 Dec 2024 08:32:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIOKY-0007oJ-FB; Tue, 03 Dec 2024 08:32:26 +0000 Received: by outflank-mailman (input) for mailman id 847434; Tue, 03 Dec 2024 08:32: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 1tIOKX-0007oD-4B for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 08:32:25 +0000 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [2a00:1450:4864:20::62b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1eaedcfc-b151-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 09:32:23 +0100 (CET) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-aa53a971480so782806966b.1 for ; Tue, 03 Dec 2024 00:32:24 -0800 (PST) Received: from [192.168.86.29] ([90.240.255.120]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa599908be5sm587424566b.140.2024.12.03.00.32.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Dec 2024 00:32: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: 1eaedcfc-b151-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1733214743; x=1733819543; 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=5dk7L1AB/1OawhJt16KYVFGRl5D8ofJSiY5t4igpxCw=; b=SdRnf5s+ap5PoTh51TIHYAL3d2voSElFEYsOBMLwOqFxbiBlD7k80flq40ch1Gzdo7 s97rqrfPRkBI4DXFV+pE6fCAewvpG87+g1eYo929MYjjlAc4PaEQHNkQdyTujf4qtIOK NOr7HtHfLaH5yhpjRxidH9ygY0KF/9xE6+lqU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733214743; x=1733819543; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5dk7L1AB/1OawhJt16KYVFGRl5D8ofJSiY5t4igpxCw=; b=DSbhs+5p5AHFX6A/4pKXZ4rkbyxFmqSkV633hM0N8ThWVemWW5dM8sDwNTBb9bQA7j eFrOyB/IWazWUUNNm7weNorAGi0h2O0YspHgeyLFnk/2fHeQto71FeixguFAOAgowMEb BHZ9Kfppi6Jt6DWhOCGXy5lAJt/mXD9oQzr92lJF0fHUDzFlVuiviu5c4VZ4iZwhg4J7 OTdiajXJsaVMVIZz8jHnrJOGYxkjbFmt8lPH39Gc600Ui+6KZZl/MaECJ7k4p8z8SIav z17F/ouxdoGZZ4r2P1IavRGDl5TQ8DMscgp0bVBX1xPfwSa/itHHOXWQ7aa+hJAJvold z74Q== X-Forwarded-Encrypted: i=1; AJvYcCWXUsCOAC6CxVnE40Kkk/dHTKkICgDwwjB6XIl76Dc4hpPBCA8wRPG6DxUhsSL+TuokQ3ULTjLThPc=@lists.xenproject.org X-Gm-Message-State: AOJu0YyzSRZ9SUgyRJWiR0VH72y2zLazjfCYm7IeqcQ/Kb8C1WvokZ0Q JgckSW0YMX13pAe1QzwhfuPbJUe6O4xwyTRawFpOTWPwSYNPiwLtLRH5mTI6nL4= X-Gm-Gg: ASbGncvLJaFS5MbChpJucAcJTqFMvTcI6611vrtf9lhuso4UBsqlm7I6zba5hOh2YtY 8wl7UJo9OzCmWUb6l8hUBfraL6xY6ihBA3v3UvsiHPTkkIeGwpsTMq4yvnvJ3v9xq0dgTorS4CE lPghUIJ07xQEr7P/Bu41JuDxiwR0veAmfMoQIBDeuBzSLr9wMj/2qrU0Do+dxgvFhPu2Rx37U3o LzTTUfarobmw0ZaD0INGBMKlNNjX+J5cfo2bL+Hjnc4HVATmFxeb9N25nBVA0A= X-Google-Smtp-Source: AGHT+IELCOvDrv+Ho44zAn5o8KCGBM6fqjdabvtg/iWF5vV9/xb7m71gInBVAEjztX3zCzj0M0ENBQ== X-Received: by 2002:a17:906:30cf:b0:aa5:274b:60e4 with SMTP id a640c23a62f3a-aa5f7d9558cmr124047966b.29.1733214743569; Tue, 03 Dec 2024 00:32:23 -0800 (PST) Message-ID: <99fb0003-8ad6-403a-9340-40d9dc322429@citrix.com> Date: Tue, 3 Dec 2024 08:32:22 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 01/11] xen/x86: add CPPC feature flag for AMD processors To: Penny Zheng , xen-devel@lists.xenproject.org Cc: stefano.stabellini@amd.com, Ray.Huang@amd.com, Xenia.Ragiadakou@amd.com, Jason.Andryuk@amd.com, Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20241203081111.463400-1-Penny.Zheng@amd.com> <20241203081111.463400-2-Penny.Zheng@amd.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20241203081111.463400-2-Penny.Zheng@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 03/12/2024 8:11 am, Penny Zheng wrote: > Add Collaborative Processor Performance Control feature flag for > AMD processors. > > amd-pstate is the AMD CPU performance scaling driver that > introduces a new CPU frequency control mechanism on modern AMD > APU and CPU series. > There are two types of hardware implementations: "Full MSR Support" > and "Shared Memory Support". > > Right now, xen will only implement "Full MSR Support", and this new > feature flag indicates whether processor has this feature or not. Do you have a reference to where this is documented? > > Signed-off-by: Penny Zheng > --- > xen/arch/x86/include/asm/cpufeature.h | 1 + > xen/include/public/arch-x86/cpufeatureset.h | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/xen/arch/x86/include/asm/cpufeature.h b/xen/arch/x86/include/asm/cpufeature.h > index 3a06b6f297..6935703e71 100644 > --- a/xen/arch/x86/include/asm/cpufeature.h > +++ b/xen/arch/x86/include/asm/cpufeature.h > @@ -170,6 +170,7 @@ static inline bool boot_cpu_has(unsigned int feat) > #define cpu_has_amd_ssbd boot_cpu_has(X86_FEATURE_AMD_SSBD) > #define cpu_has_virt_ssbd boot_cpu_has(X86_FEATURE_VIRT_SSBD) > #define cpu_has_ssb_no boot_cpu_has(X86_FEATURE_SSB_NO) > +#define cpu_has_cppc boot_cpu_has(X86_FEATURE_CPPC) > #define cpu_has_auto_ibrs boot_cpu_has(X86_FEATURE_AUTO_IBRS) > > /* CPUID level 0x00000007:0.edx */ > diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h > index 8fa3fb711a..15f707639b 100644 > --- a/xen/include/public/arch-x86/cpufeatureset.h > +++ b/xen/include/public/arch-x86/cpufeatureset.h > @@ -265,6 +265,7 @@ XEN_CPUFEATURE(AMD_PPIN, 8*32+23) /* Protected Processor Inventory Number > XEN_CPUFEATURE(AMD_SSBD, 8*32+24) /*S MSR_SPEC_CTRL.SSBD available */ > XEN_CPUFEATURE(VIRT_SSBD, 8*32+25) /*! MSR_VIRT_SPEC_CTRL.SSBD */ > XEN_CPUFEATURE(SSB_NO, 8*32+26) /*A Hardware not vulnerable to SSB */ > +XEN_CPUFEATURE(CPPC, 8*32+27) /*A Collaborative Processor Performance Control */ There needs to be no "A" in this patch, because it's certainly not ready to advertise to guests yet. If you're intending it for eventual use by guests, then the "A" only goes back in at the end of the series when the support to correctly virtualise it appears, but it looks like it will be Xen-only. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Dec 03 08:35:53 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 08:35:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847446.1262528 (Exim 4.92) (envelope-from ) id 1tIONr-0008RS-4d; Tue, 03 Dec 2024 08:35:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847446.1262528; Tue, 03 Dec 2024 08:35: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 1tIONr-0008RL-1K; Tue, 03 Dec 2024 08:35:51 +0000 Received: by outflank-mailman (input) for mailman id 847446; Tue, 03 Dec 2024 08:35: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 1tIONp-0008RD-96 for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 08:35:49 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on20619.outbound.protection.outlook.com [2a01:111:f403:2412::619]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 967d32f5-b151-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 09:35:46 +0100 (CET) Received: from DS7P220CA0058.NAMP220.PROD.OUTLOOK.COM (2603:10b6:8:224::22) by DM4PR12MB5722.namprd12.prod.outlook.com (2603:10b6:8:5d::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.19; Tue, 3 Dec 2024 08:35:39 +0000 Received: from DS1PEPF0001709D.namprd05.prod.outlook.com (2603:10b6:8:224:cafe::66) by DS7P220CA0058.outlook.office365.com (2603:10b6:8:224::22) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.18 via Frontend Transport; Tue, 3 Dec 2024 08:35:39 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by DS1PEPF0001709D.mail.protection.outlook.com (10.167.18.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 08:35:39 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Tue, 3 Dec 2024 02:33: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: 967d32f5-b151-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kGUnxo5t0m9NqVOFemeqC81wDB5Iw45KtrjSJl63SuK8e+IZBWm68kijv1HZ4p7eemMgzuVO3weDd5tC41xM8xZGhRWdyh2W/aXrPddGwSQo9vbu1cJUQyb1u0zH8Svhe6oR302AKLReoX26lZrWual5vV/XyhOh4ekPKDk8xXUzo6IKpVXROj2Dn+5OLdZJ+6BCM7RQXFbbzWm9NxQYb8fpipWSrV+2IpJy68leN6134P56IpdZdQNCw3qp0q4vlDENYH3GNsnMq+q0rko05VtAHIKufwZ1lL/GoTTRvFrCQhI22xTe1sxMKTZh62zzNDG3uOUYCOHL8rdkdtTVDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=RXdS+5gaEuT5scthbVrK+h/Gd+9a+0HPlHnCGnSwq/E=; b=vqV0RyrduVTjgNNgd9fjpRhcPZP9q+/4M7tsvszpHCD1iACvmy5bUvJAmL6TfdAS96J6jgDzzpStHJfe8fZ4OWYks0Wt/6WmNRwNqbhRmroF79clup3cNlp8E7RvcYNJ+4AS0yAo2Y/YlChWwDkuwaNnJRpP9/Y1q1RAdQI4S2SoTP/2k5yhGHsI2NhuEacJA2H1doWXU+dFpGBuko2Wuqm48PZJRWwuMwjIXKwmOacSkx0bG+USe/eFYSdZvp+/uz1Zt0A/wEoxS1C37nWvypg2G+gV+FOIN4X5iao0JfasGTN4R+uM83e7u+uJ5OOGLTgUYR7HVGfV8Rf1T9Ltxg== 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=RXdS+5gaEuT5scthbVrK+h/Gd+9a+0HPlHnCGnSwq/E=; b=AZdFeWFe2zoEjkYmFPvvdNlxuezqLCaYrVHh9e3nnxEYfkBUASRuCq1kWtyLJao9YQ6Ck+70w1mQEiDHsvikE3CwfFJx+9aFQMB5hJbKru9/FfiYHFBOlfjFkKUzP8HMHY0/eIH3Y1+yzrXvwZI9BavbdCrgPG90DqRDOgOOGy4= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: CC: , , , , , Anthony PERARD , Penny Zheng Subject: [PATCH v1 10/11] tools/xenpm: Print CPPC parameters for amd-pstate driver Date: Tue, 3 Dec 2024 16:33:15 +0800 Message-ID: <20241203083315.463511-1-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS1PEPF0001709D:EE_|DM4PR12MB5722:EE_ X-MS-Office365-Filtering-Correlation-Id: 1184c72a-67e5-475c-5353-08dd13757761 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|36860700013|1800799024; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?oIPySKemX3NZx+HcqNpbWK34Pcxt4njji39RwInifQUwb7lMcpqrFDJhM0WA?= =?us-ascii?Q?W1BHXwHANgRAMFZAXi+XQuhsiGcUFejOFamASqAof6+aw1t2/23cP2+EgLEY?= =?us-ascii?Q?eA/6MwV9bcXjixaV7LrOQZ8wwojEoOPK623MOsIVNmvNobysjzFV5GRQyi0Y?= =?us-ascii?Q?yS99Z36XchKRZP6AL7em0Lh5zXd8/d+KEVrQk2X9IlsFX+na29GDXcLgnFDZ?= =?us-ascii?Q?rXQCzjJCHVGBytYR4ge+z0lnUD033dXv8/UwLUJ4YqrJ6cmozB2Py4fXJfWH?= =?us-ascii?Q?TU4mIjCFdgNYZJux4G/EbhDWOrAEHc5HQawMyxkL+4z9UIfXCN6t+asuUN8J?= =?us-ascii?Q?vitob1AeBf923vZSQ8taI5Wgd5HDtmn6iWsV8VXi8dArU8jWYtgMTmQmkgBR?= =?us-ascii?Q?gUtn3DJzf0q4Eo9qIN1tFI15+tq0RkDfNoM28BrVNRe2AUKWxxug8FAdQEtK?= =?us-ascii?Q?pIA+jf7QtY3XLwYTUifn2A0fk+uYDSdwfAJ9EROIzLBBwWB39uICPBnSAXgN?= =?us-ascii?Q?sGgPmEVyY1ULIQfMokbBLuvQBuFbqvb++qJhGhPo1M1ICD9/qxDdVdKUs2Mf?= =?us-ascii?Q?PJBPEXakDioqIkITMUGcywy9DrBMMIUrQ88L5FhhKH3OcYo3cBBQM78K+IZI?= =?us-ascii?Q?GdQsQIXaHnaJVEsmhz+a7B57S7Xic1QXa57MnkhT7HlpkBAXeBxXr0LwRjZU?= =?us-ascii?Q?tgOOPmkXEe2ESMQOzjGF48QWoG0kGkEooiJlxNNSnhoNR99i3vYoQ1WAvqpE?= =?us-ascii?Q?DNBBpUcEDkMVDDcyNijpZVv3w0VGezS5WTi2IrHoakhHwcNidSryBTOchRhH?= =?us-ascii?Q?XIFov2ASIvhKowVl5281fP+WV/DbbsRfpkMt0+difRwgh+Ravm2QbB+0MK9Q?= =?us-ascii?Q?DpiO8WIePChAW9mVInSChjzZTZdzRs2/f6F6dcXsUk5Ce/jlZbg3c4wGNT67?= =?us-ascii?Q?WQiOUopVGYXP5qoS3RsOSrHVxjqp3fONJnw41VH1nk9fqdC3xBUqLsj1WCDm?= =?us-ascii?Q?HX1JGOM9J0PNPpgN3ua6PGMoOBRS5alUmeHPN0jz5ezVutTZBh/38a2J9If8?= =?us-ascii?Q?d4Y4hd0oaHof0wjIMeHt1W2XtWZRrZw3Vp1Lft/JDWY4WU7zzZsIjc6dYA0c?= =?us-ascii?Q?uGpBLupDdu6q+SQfSTcVGvTyprMdH+VIv9s9AJXJ4VqQNHH+33fhVUXJ1I2D?= =?us-ascii?Q?kMmNZr9nhOoTaQgSiZLtSJTobpIv+y5LLjK7kXRUE1fL2P17MK+6K/y8/CQt?= =?us-ascii?Q?NrIdiyLRvN1RVpYgCS2ndbvbLtMMUOXc5IqxgNvaxTZHy1KLOnqtDE/mQqLW?= =?us-ascii?Q?GKhWawXj8f9eP+nhaz/araN1q83sskqUzPQT34L7n9j8CrK8Kq4ml+3caoQO?= =?us-ascii?Q?Jnc6wnLBdbKoQ6ZO5/zJEoaigTF4SqU7fIYoYTgzI4+NE8VJIb8yqUWHg21K?= =?us-ascii?Q?/FwaSD6X7MHoW1FelP6pjFoAaxGcq9HW?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700013)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 08:35:39.0353 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1184c72a-67e5-475c-5353-08dd13757761 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DS1PEPF0001709D.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5722 From: Penny Zheng HWP, amd-pstate, amd-pstate-epp are all the implementation of ACPI CPPC (Collaborative Processor Performace Control), so we introduce cppc_mode flag to print CPPC-related para. And HWP and amd-pstate-epp are both governor-less driver, so we introduce hw_auto flag to bypass governor-related print. Signed-off-by: Penny Zheng --- tools/misc/xenpm.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c index 336d246346..a09b53c4f3 100644 --- a/tools/misc/xenpm.c +++ b/tools/misc/xenpm.c @@ -787,12 +787,22 @@ static unsigned int calculate_activity_window(const xc_cppc_para_t *cppc, return mantissa * multiplier; } + /* print out parameters about cpu frequency */ static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq) { - bool hwp = strcmp(p_cpufreq->scaling_driver, XEN_HWP_DRIVER_NAME) == 0; + bool cppc_mode = false, hw_auto = false; int i; + if ( !strcmp(p_cpufreq->scaling_driver, XEN_HWP_DRIVER_NAME) || + !strcmp(p_cpufreq->scaling_driver, XEN_AMD_PSTATE_DRIVER_NAME) || + !strcmp(p_cpufreq->scaling_driver, XEN_AMD_PSTATE_EPP_DRIVER_NAME) ) + cppc_mode = true; + + if ( !strcmp(p_cpufreq->scaling_driver, XEN_HWP_DRIVER_NAME) || + !strcmp(p_cpufreq->scaling_driver, XEN_AMD_PSTATE_EPP_DRIVER_NAME) ) + hw_auto = true; + printf("cpu id : %d\n", cpuid); printf("affected_cpus :"); @@ -800,7 +810,7 @@ static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq) printf(" %d", p_cpufreq->affected_cpus[i]); printf("\n"); - if ( hwp ) + if ( hw_auto ) printf("cpuinfo frequency : base [%"PRIu32"] max [%"PRIu32"]\n", p_cpufreq->cpuinfo_min_freq, p_cpufreq->cpuinfo_max_freq); @@ -812,7 +822,7 @@ static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq) printf("scaling_driver : %s\n", p_cpufreq->scaling_driver); - if ( hwp ) + if ( cppc_mode ) { const xc_cppc_para_t *cppc = &p_cpufreq->u.cppc_para; @@ -838,7 +848,8 @@ static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para *p_cpufreq) cppc->desired, cppc->desired ? "" : " hw autonomous"); } - else + + if ( !hw_auto ) { printf("scaling_avail_gov : %s\n", p_cpufreq->scaling_available_governors); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 08:38:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 08:38:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847458.1262537 (Exim 4.92) (envelope-from ) id 1tIOQD-0000Z5-GB; Tue, 03 Dec 2024 08:38:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847458.1262537; Tue, 03 Dec 2024 08:38: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 1tIOQD-0000Yy-Db; Tue, 03 Dec 2024 08:38:17 +0000 Received: by outflank-mailman (input) for mailman id 847458; Tue, 03 Dec 2024 08:38: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 1tIOQB-0000Yo-Ae for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 08:38:15 +0000 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on20626.outbound.protection.outlook.com [2a01:111:f403:2418::626]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id eec53702-b151-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 09:38:13 +0100 (CET) Received: from DS7PR07CA0008.namprd07.prod.outlook.com (2603:10b6:5:3af::21) 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.8207.18; Tue, 3 Dec 2024 08:38:09 +0000 Received: from DS1PEPF0001709A.namprd05.prod.outlook.com (2603:10b6:5:3af:cafe::bd) by DS7PR07CA0008.outlook.office365.com (2603:10b6:5:3af::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.17 via Frontend Transport; Tue, 3 Dec 2024 08:38:09 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by DS1PEPF0001709A.mail.protection.outlook.com (10.167.18.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 08:37:19 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Tue, 3 Dec 2024 02:37:16 -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: eec53702-b151-11ef-a0d3-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UQ4t+E8YhMECFg1m3ObhAR/x+Y13kKeauuR2K++feAV4LpnuSZxmQVEmmEUl7T9ULyMdsfddaf+aQlOFw8HyTnWTFkH+GhoiQojcsS5dqVK23R0MDGIBiVRsJWXxMDwkYjdB3E9oDqospzkmey9QrC4P45sFEWgqxJso4kd/15gxggXLRwYPcW56Ny0ttk3iMfUl9WBo0CS5Xzx4UtS8gs6jAZpFOROSwR9A4g/yhDxL3WYeSO7WXYz+QAnzwJ0EhaHBtxYqFODo7srDZD900ig9lpuEBCtC09LNN8Bu8hwipV/l1UIRRfwr+q5p0+dew3F7gXkGQdwip148fDulrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=V2P9uY49wOAkSXwRdYzJBulEXJpWyFUaFXnQvFqoUiY=; b=dy8pAjXTdNJ2+XXHNtcG+AEgVQGG7wnOcFihBPlLMPoTQgeXBuSTHrhVGp3vVvQMEJBkztB1J591gXrKXvXudOAoa+jH+TTda/arg6fXTHs1+Qaclwr+7lNKSq/co7IEInPMGqR9aBAeMe8u2rOAUQIDBoY3dI1XQ1042hfS8LYknESJ/YFczZlsBf4AuH65bF84TRrphn74dA/s8jjI+F/ryWPPARezG6VL5Xah+AEbrH0MF4T8SShAsXCUmkJJm5IbW5+px1TCEAGiNY76Nzv0+KzGGupmFcCh4ZsKgSaquAIDdPI7xmutM9cKVe5JOdEbt/QOLwbDz6g5jRc0pA== 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=V2P9uY49wOAkSXwRdYzJBulEXJpWyFUaFXnQvFqoUiY=; b=YyJAAQOuYg9QwcHejx4gnZ/EIO9DwOXgm3tK5C6XfEoTyHSKryjg78glev26FDDxwkAoqVbOGCmM70avmr6sbZ67NxT22OnO4pkg8Sl2UaO9ZeOK6cjGmfRXkMAvKoDkMgiu72BDIJeDABX9zo7a5ILj69aZFUeb/O5B4Ljc6lA= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: CC: , , , , , Penny Zheng , Jan Beulich , "Andrew Cooper" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v1 11/11] xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC xen_sysctl_pm_op for amd-pstate driver Date: Tue, 3 Dec 2024 16:35:35 +0800 Message-ID: <20241203083535.463533-1-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS1PEPF0001709A:EE_|DS0PR12MB7701:EE_ X-MS-Office365-Filtering-Correlation-Id: 862962be-f0f0-4f2f-e16d-08dd1375d077 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?D+m1Y1EtbE75H87IXViBEXGpik6cDqKbn05jSjj7QmTA6Dmi7jPqW8Pj9MVe?= =?us-ascii?Q?WauTSHf/lbGDiP8YrI4y880Rfq7pkXBZboYK1Vkc+8aLnCVuscOSP3uOIN1K?= =?us-ascii?Q?qWnToDLSOhnZ22TWn809z4el4TmMLSwcrbLh6bjkxPhYSrXRii2ffOzwCdKl?= =?us-ascii?Q?jaMrM7iovHi7cfPx3I6+cZOQKYg1UlEw7NQlsDl0A4WcxCB4Z/m0eb91JzCe?= =?us-ascii?Q?buLh91A7HnGgW8cwu4IOI6dIXveyOL3GQeo5D8grv2DbpvL4M6Y/NgvcSART?= =?us-ascii?Q?yQeert1P0uwnol7GkkHNOcF1BoQbVHxK1dbovfK52rZg/VLuSG6HiQlSedHR?= =?us-ascii?Q?q14Ks0rucsEsy7AytyCEVpk/mHWEs6D0QsGJZXAwzhTFs1qU2ybTe0poG294?= =?us-ascii?Q?BxBxAO1KdEI3I9UA5hV4BCKqswI2a02FvyAgbK1sjGLeK6xYknnkCW352Ipr?= =?us-ascii?Q?P4nqI/dD2VX83npPtmPUyv0iJT6CdH8j6riE1HwvYLcdHG9zEyPJgBPl71Bu?= =?us-ascii?Q?NZRN785DEltCRrLPzdBArpnHM04C/Q98Yk35UxNOmKQAOz8jXYip0kD2s/0R?= =?us-ascii?Q?UovCsPdbA7iodDtpG4sWbmyfpZuBFl34K6XNHUYqSlvXy1kxZ5uv7GdqOixY?= =?us-ascii?Q?JlYDHuLU5PDePayhsZB8bRyjOOTeDIeFGhvyZxH6KvJ6Ti9vYWjihTx9FeXm?= =?us-ascii?Q?rAQu/3FsQn97g4aRQQQu4fmUXIHoijsEe/+KsKugu2l59i6rvgiHhQQAWtLK?= =?us-ascii?Q?MKwxO3HeNSHSmJtBeTE0AJB2oDzFrsWNzh6IXKTskNZH3DqWUgwl9zOdB81/?= =?us-ascii?Q?m/SjsnJ5TVasdfPg9n2SqIWyQd9a9ffmWL4uzyBBOwWK58DDl+MNmczkULX9?= =?us-ascii?Q?Oc0LxIDahVoXJSaKC8rN8JNdmEeA9RyNR3EzU2ir6+RqasHfZIIxcBZ5XWJa?= =?us-ascii?Q?UYKBfgkcbpKInLZrM3lHmlxIHAmQ9TsA46zXZ+aCL5v1ubtm6gH78CApotO1?= =?us-ascii?Q?/bW6oCKTFkI+9x/9amLOA5aaq0Gbr73gixr7ea4y/WXU8vZUXpRkC5MIFX/v?= =?us-ascii?Q?QFXxVMIxscNOR7PSHpCjONggrEhaX22dA5PrG15xLJ8yvr0om61F9lUOVcA5?= =?us-ascii?Q?dPHtw12JID/a406bn7E6bQiWubuzEy+EK8G+mhNVroZo0FPmQP6Na3tAQfos?= =?us-ascii?Q?Zp/yHEv4FtYVMqOKc5W9rxo67hb16/hJxLcd9HApszPetvV6D4RX5p64CA7o?= =?us-ascii?Q?G4lipc4nnsbbKWX4vWxQjf4mF7Kegq67NO6rPOP1apyzDUEEOatOt9Hq8QbI?= =?us-ascii?Q?ApxfIm0KEGhD88rPZ9/UTvHmBKduuD5Q8LFk8MfRzla9gj4ueGPShKLLmksT?= =?us-ascii?Q?zs5Y3MQf8nV07AMjmFSK9TIUiFB1STYmtE9nfN9BPR4suQZ3NJoJubNZn3aY?= =?us-ascii?Q?a4ypGpvUfppakkATbQnfOr4RIeKHVPpr?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 08:37:19.0317 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 862962be-f0f0-4f2f-e16d-08dd1375d077 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DS1PEPF0001709A.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7701 Introduce helper set_amd_cppc_para and get_amd_cppc_para to SET/GET CPPC-related para for amd-pstate/amd-pstate-epp driver. Signed-off-by: Penny Zheng --- xen/arch/x86/acpi/cpufreq/amd-pstate.c | 119 +++++++++++++++++++++++++ xen/drivers/acpi/pmstat.c | 24 ++++- xen/include/acpi/cpufreq/cpufreq.h | 5 ++ 3 files changed, 144 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/acpi/cpufreq/amd-pstate.c b/xen/arch/x86/acpi/cpufreq/amd-pstate.c index 40ecd04259..2b1f6c7731 100644 --- a/xen/arch/x86/acpi/cpufreq/amd-pstate.c +++ b/xen/arch/x86/acpi/cpufreq/amd-pstate.c @@ -29,6 +29,8 @@ static bool __ro_after_init opt_cpufreq_active = false; +static bool __ro_after_init amd_pstate_in_use; + struct amd_pstate_drv_data { struct xen_processor_cppc *cppc_data; @@ -489,6 +491,117 @@ static int cf_check amd_pstate_epp_set_policy(struct cpufreq_policy *policy) return amd_pstate_epp_update_limit(policy); } +int get_amd_cppc_para(unsigned int cpu, + struct xen_cppc_para *cppc_para) +{ + struct amd_pstate_drv_data *data = per_cpu(amd_pstate_drv_data, cpu); + + if ( data == NULL ) + return -ENODATA; + + cppc_para->features = 0; + cppc_para->lowest = data->hw.lowest_perf; + cppc_para->lowest_nonlinear = data->hw.lowest_nonlinear_perf; + cppc_para->nominal = data->hw.nominal_perf; + cppc_para->highest = data->hw.highest_perf; + cppc_para->minimum = data->req.min_perf; + cppc_para->maximum = data->req.max_perf; + cppc_para->desired = data->req.des_perf; + cppc_para->energy_perf = data->req.epp; + + return 0; +} + +int set_amd_cppc_para(struct cpufreq_policy *policy, + struct xen_set_cppc_para *set_cppc) +{ + unsigned int cpu = policy->cpu; + struct amd_pstate_drv_data *data = per_cpu(amd_pstate_drv_data, cpu); + uint8_t max_perf, min_perf, des_perf; + int epp = -1; + + if ( data == NULL ) + return -ENOENT; + + /* Validate all parameters - Disallow reserved bits. */ + if ( set_cppc->minimum > 255 || set_cppc->maximum > 255 || + set_cppc->desired > 255 || set_cppc->energy_perf > 255 ) + return -EINVAL; + + /* Only allow values if params bit is set. */ + if ( (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED) && + set_cppc->desired) || + (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MINIMUM) && + set_cppc->minimum) || + (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MAXIMUM) && + set_cppc->maximum) || + (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ENERGY_PERF) && + set_cppc->energy_perf) ) + return -EINVAL; + + /* Activity window not supported */ + if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ACT_WINDOW ) + return -EINVAL; + + /* Return if there is nothing to do. */ + if ( set_cppc->set_params == 0 ) + return 0; + + /* Apply presets */ + switch ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_PRESET_MASK ) + { + case XEN_SYSCTL_CPPC_SET_PRESET_POWERSAVE: + if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED ) + return -EINVAL; + min_perf = data->hw.lowest_perf; + max_perf = data->hw.highest_perf; + epp = CPPC_ENERGY_PERF_MAX_POWERSAVE; + des_perf = 0; + break; + + case XEN_SYSCTL_CPPC_SET_PRESET_PERFORMANCE: + if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED ) + return -EINVAL; + min_perf = data->hw.highest_perf; + max_perf = data->hw.highest_perf; + epp = CPPC_ENERGY_PERF_MAX_PERFORMANCE; + des_perf = 0; + break; + + case XEN_SYSCTL_CPPC_SET_PRESET_BALANCE: + if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED ) + return -EINVAL; + min_perf = data->hw.lowest_perf; + max_perf = data->hw.highest_perf; + epp = CPPC_ENERGY_PERF_BALANCE; + des_perf = 0; + break; + + case XEN_SYSCTL_CPPC_SET_PRESET_NONE: + min_perf = data->hw.lowest_nonlinear_perf; + max_perf = data->hw.highest_perf; + break; + + default: + return -EINVAL; + } + + /* Further customize presets if needed */ + if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MINIMUM ) + min_perf = set_cppc->minimum; + + if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MAXIMUM ) + max_perf = set_cppc->maximum; + + if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ENERGY_PERF ) + epp = set_cppc->energy_perf; + + if ( set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED ) + des_perf = set_cppc->desired; + + return amd_pstate_write_request(cpu, min_perf, des_perf, max_perf, epp); +} + static const struct cpufreq_driver __initconstrel amd_pstate_cpufreq_driver = { .name = XEN_AMD_PSTATE_DRIVER_NAME, @@ -507,11 +620,17 @@ static const struct cpufreq_driver __initconstrel amd_pstate_epp_driver = .exit = amd_pstate_cpufreq_cpu_exit, }; +bool amd_pstate_active(void) +{ + return amd_pstate_in_use; +} + int __init amd_pstate_register_driver(void) { if ( !cpu_has_cppc ) return -ENODEV; + amd_pstate_in_use = true; if ( !opt_cpufreq_active ) return cpufreq_register_driver(&amd_pstate_cpufreq_driver); else diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c index df309e27b4..63b4019c16 100644 --- a/xen/drivers/acpi/pmstat.c +++ b/xen/drivers/acpi/pmstat.c @@ -198,6 +198,7 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op) char *scaling_available_governors; struct list_head *pos; uint32_t cpu, i, j = 0; + bool hw_auto = false; pmpt = processor_pminfo[op->cpuid]; policy = per_cpu(cpufreq_cpu_policy, op->cpuid); @@ -258,7 +259,19 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op) !strncmp(op->u.get_para.scaling_driver, XEN_HWP_DRIVER_NAME, CPUFREQ_NAME_LEN) ) ret = get_hwp_para(policy->cpu, &op->u.get_para.u.cppc_para); - else + else if ( !strncmp(op->u.get_para.scaling_driver, XEN_AMD_PSTATE_DRIVER_NAME, + CPUFREQ_NAME_LEN) || + !strncmp(op->u.get_para.scaling_driver, XEN_AMD_PSTATE_EPP_DRIVER_NAME, + CPUFREQ_NAME_LEN) ) + ret = get_amd_cppc_para(policy->cpu, &op->u.get_para.u.cppc_para); + + if ( !strncmp(op->u.get_para.scaling_driver, XEN_HWP_DRIVER_NAME, + CPUFREQ_NAME_LEN) || + !strncmp(op->u.get_para.scaling_driver, XEN_AMD_PSTATE_EPP_DRIVER_NAME, + CPUFREQ_NAME_LEN) ) + hw_auto = true; + + if ( !hw_auto ) { if ( !(scaling_available_governors = xzalloc_array(char, gov_num * CPUFREQ_NAME_LEN)) ) @@ -414,10 +427,13 @@ static int set_cpufreq_cppc(struct xen_sysctl_pm_op *op) if ( !policy || !policy->governor ) return -ENOENT; - if ( !hwp_active() ) - return -EOPNOTSUPP; + if ( hwp_active() ) + return set_hwp_para(policy, &op->u.set_cppc); + + if ( amd_pstate_active() ) + return set_amd_cppc_para(policy, &op->u.set_cppc); - return set_hwp_para(policy, &op->u.set_cppc); + return -EOPNOTSUPP; } int do_pm_op(struct xen_sysctl_pm_op *op) diff --git a/xen/include/acpi/cpufreq/cpufreq.h b/xen/include/acpi/cpufreq/cpufreq.h index d2a74d8315..bbc783cb1b 100644 --- a/xen/include/acpi/cpufreq/cpufreq.h +++ b/xen/include/acpi/cpufreq/cpufreq.h @@ -286,6 +286,11 @@ int acpi_cpufreq_register(void); int amd_pstate_cmdline_parse(const char *s, const char *e); int amd_pstate_register_driver(void); +bool amd_pstate_active(void); +int get_amd_cppc_para(unsigned int cpu, + struct xen_cppc_para *cppc_para); +int set_amd_cppc_para(struct cpufreq_policy *policy, + struct xen_set_cppc_para *set_cppc); extern uint16_t dmi_max_speed_mhz; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 08:54:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 08:54:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847469.1262548 (Exim 4.92) (envelope-from ) id 1tIOgB-0004i2-S9; Tue, 03 Dec 2024 08:54:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847469.1262548; Tue, 03 Dec 2024 08:54:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIOgB-0004hv-PI; Tue, 03 Dec 2024 08:54:47 +0000 Received: by outflank-mailman (input) for mailman id 847469; Tue, 03 Dec 2024 08:54: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 1tIOgB-0004hp-0B for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 08:54:47 +0000 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [2a00:1450:4864:20::62f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3e2e8b08-b154-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 09:54:45 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-aa531a70416so339033066b.0 for ; Tue, 03 Dec 2024 00:54: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 4fb4d7f45d1cf-5d097db0a6esm5846455a12.27.2024.12.03.00.54.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Dec 2024 00:54: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: 3e2e8b08-b154-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733216084; x=1733820884; 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=jPUNVDWkogcynT8pGLDTi0w2gyUNXgK+hXK8tDXrm4w=; b=YYoi9Tdnt1YEg1Bf6UQJisNwZ/Q7xiMnEYogWHM7n+62XsoAOkLHhqRWWGR61WYKQC 779TTmk4WngqOP4jOxtbikUyT28ee1Am8SrSfKqWgNVXmaPm/CHtMA0Wopz1dU/WIxX1 QQlewaa0r2zCzevo6QeslZK+WP+Gf0+wegXi5CX+xTOVus/a5kALfQXBZOa5/QLNvi3d ZPHBexMJYO8+CbfY/00wIp5Aw0FvjS7Kr7JEBoNtXrdobDEGD9P4zrT9sktwen/Ghg7S ytvjLeGRcJKD5AXV0KW7Y7HX+WVQd5cfYUHlVTFJ8UTpqhKj+8n6MI2auGrWYKNfz2Ej HoDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733216084; x=1733820884; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=jPUNVDWkogcynT8pGLDTi0w2gyUNXgK+hXK8tDXrm4w=; b=s8Wvzgu0xxBCDYb4Y9Fd5Rfe7Q9GqTJS8DLmiFqicdc8oAl74l1KKn+EJA9vkcZ/Td hnKrEI0o87vzIQghT2vzJM2lfhKVfeNGssXiROTJbSR3aRPNFrSqLioZlgdsGhoUDnog fG4g93iI0J7pIZzq0ycYRbA+C7hKKfjqQin9lYDAJAbW2nWPPW+Vz7CqP7cwZtKde5XC LFeVIHI7Ng008qtcPBwnNwZoYfDdJM9ePj/hwDTOo4WqIOkgPeJa+YTdm29293jkum/h z3tVae+3GLYWSpWEDxIbnQatTqDonbEXdvrTIdi0m7pqpKn5Zm2Wus/wJNBaK/E6E1EZ 6tKg== X-Forwarded-Encrypted: i=1; AJvYcCXGbL8tCBkhhA6WVSSaXmPLcOj7nuDWl+mQoIFQrIC7q58qX24+0oGyoMn8vpF0f92GqlrUHkSedqs=@lists.xenproject.org X-Gm-Message-State: AOJu0YwB4OBXGZq9nyrJIEc6qO/tuPNTNfiUpqQZC6PrhPkXHNNuvlJu yCw6Jbe2ZVXzytvZHLT8CWgj0COgTDKPO46Tp9f9vq/AewYe2k8n7JwR1idzvg== X-Gm-Gg: ASbGncsdLIb0nTvlAcpafuldiIj7dh1FI5EJMoaSS4aQTXrTsoUdvw9XEJCbJXkHGgp R7J1SKbIaMYc9SbdbJoZ4koy0OSVrsetM1PsbmvpfT3qV0fLBNtvX26WBLwxp1OUzHp4EdcBzWP yRHLxIUVweGgH+AJw+v3+CGTh1gcqXNidqBt+v+IMDEz59hhdpbgfWwhMWsNR2qsOvYHV1FPgLr bj6kBoUkBLD9qei607p/yTP1jS7FI7izt0yT9yul19prMjkTREFV0TPSBO+BfQf4PpBhteHzTVf Urh8kze6NROy4lTcHMhJyr1MzNAMcbw3Jdc= X-Google-Smtp-Source: AGHT+IFXi2GLytIYV7oO6QRxR5PHJZFrbuv2c1s/CiYg21PquypfTwtStZfIczn8XTlfneOL2ybtyw== X-Received: by 2002:a05:6402:42c3:b0:5d0:d2ed:ebb with SMTP id 4fb4d7f45d1cf-5d10cb4e70amr1966772a12.3.1733216084619; Tue, 03 Dec 2024 00:54:44 -0800 (PST) Message-ID: <5b98f7cd-fb84-4a67-af3a-9c81a687b291@suse.com> Date: Tue, 3 Dec 2024 09:54:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 08/12] xen/page_alloc: introduce preserved page flags macro To: Carlo Nonato Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Andrew Cooper , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> <20241202165921.249585-9-carlo.nonato@minervasys.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 02.12.2024 18:33, Carlo Nonato wrote: > Sorry guys, this patch is wrong. > Here's the correct one. Which looks okay to me now, just that imo ... > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -161,6 +161,7 @@ > #endif > > #define PGC_no_buddy_merge PGC_static > +#define PGC_preserved (PGC_extra | PGC_static) ... this new #define now wants a comment, to clarify where the constant is to be used (or specifically not to be used). Unlike for PGC_no_buddy_merge this can't be easily deduced from the name. Jan From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:01:16 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:01:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847481.1262558 (Exim 4.92) (envelope-from ) id 1tIOmN-0006Ya-Js; Tue, 03 Dec 2024 09:01:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847481.1262558; Tue, 03 Dec 2024 09:01:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIOmN-0006YT-G6; Tue, 03 Dec 2024 09:01:11 +0000 Received: by outflank-mailman (input) for mailman id 847481; Tue, 03 Dec 2024 09:01: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 1tIOmM-0006YN-Ac for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:01:10 +0000 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [2a00:1450:4864:20::130]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 231225d6-b155-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 10:01:09 +0100 (CET) Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-53df67d6659so8123241e87.3 for ; Tue, 03 Dec 2024 01:01: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 a640c23a62f3a-aa59991f1b1sm588820066b.165.2024.12.03.01.01.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Dec 2024 01:01: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: 231225d6-b155-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733216468; x=1733821268; 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=4YRb2XHdKNSFAGkA9/fZjUUYBUqXrLnykySbZz9RxHM=; b=gLLwlEDwhUOFCcC+Ui5b1EZYnCISjbAYSue68tPkfc6srZZSbGHnQQzzZs2aJzq0cQ 5u8eJWzjBFihK6t/9v01N1FgY4AEjvBSTxxPLRDkc1Xi3oYsG2FSp5L07siIvuFjPszi +Gh2bzs9+UGW8WadnwDiXqHx5xvjA1XrfFNamYxm5FrqgnZ1PZc/c2XTv9ZmMUBBVW2I v3A7zOGlurLV8Yr0+RgIdp7D7m5P+YqeH+HRwe9rFE0jdfKsMXw8/n+AJ1317VJafpWf 9etKTxq9fCbr+5xGm+CmkYmxa/nYaREnNywbRzQnkSoIqAbHx7OyhN14YrIuEDTyTY2a UrHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733216468; x=1733821268; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4YRb2XHdKNSFAGkA9/fZjUUYBUqXrLnykySbZz9RxHM=; b=Sl9lypat7TvkDCHFQzS8pDdl0jwJZ4rahB2POymno0dty7/fXKEntHyxq6iVNUUKnE VmpwaeB7dJRc3kOs7ZSLUePiCfqLiTO+Ai3pQwROoUAUJjDSrc//uZuUuY2qFoerdUSh QaAT/tNAGNXuP1OKDErjtA8XOgR8g7bQauO1plrJvXRo8DsY9AUuYyBe4nQxMO+wKYR0 UN3U4HR1fnHi9x8u6BL5pAqkgJvW7/fkkqQB9Q991fOZ3Rp0jjzg+yy2gyL4eEqCxqP0 NbYYXN0wVB5FyoMVoe8SfeTaXf8gg5DdfiaEpQGDwjZVRK8tQrO1t3z673r+d8jSc24s Io1A== X-Forwarded-Encrypted: i=1; AJvYcCXF1rWnNDtP+LaF0xDAmFDAxsMeHAfvAVoGEiH/Xp5xAmXGz7xFphlu35ypCiDqjZvmnxHvYi4l+eQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YxJNQ2xBj5yHlgQuVTN3Fwc/MJXJpMbZL6T/yoDTTWZWPDO8JX6 j1Szr/peRk0nS4J3BR/fgIVkSMljH3aRnlS5FEqWSL1dxCEo4UZQhfN1D3KtOQ== X-Gm-Gg: ASbGnct0ZjBoLRf8tDLPbzOdok6x18Xt96CDixXBuDTFo9e233qD0od1iB2p2gs2zPN 7eyUTnqbfTbR6W2HqJNh2tCf8w2gTQCuxiRF4rmPqxbXGtZTopQgcfU6FDuIkj4MXXfglcF+YRh 8kocuZOrUW2iqAIIBfGokFg2X6KG7VA+B3+HXxicFW/FL8HZfDki3Cg9RJ7zL9m6vatQYAQA769 kzQlRf1LkPHIhdlJazEUGtYVa0atCoy6NrS3RoUoPgJ38rNTfxIpLjtbKhldBtw4yrSK8oVzRhE pdZN/UX0MeKP6PxBxfdIvuiWaISoleUsJRo= X-Google-Smtp-Source: AGHT+IFCoZx9jD9ylrLhyUpnHj7rce1pa6sjPuv8/ddPVXjBP2Elo7tKAZmg+o9z8MkBNSA32IOdOA== X-Received: by 2002:a05:6512:b14:b0:53d:e7b6:c701 with SMTP id 2adb3069b0e04-53e12a06d37mr1395337e87.33.1733216468557; Tue, 03 Dec 2024 01:01:08 -0800 (PST) Message-ID: <593baee2-9bf1-4db4-86e8-015cae48dc1a@suse.com> Date: Tue, 3 Dec 2024 10:01:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 00/11] amd-pstate CPU Performance Scaling Driver To: Penny Zheng Cc: stefano.stabellini@amd.com, Ray.Huang@amd.com, Xenia.Ragiadakou@amd.com, Jason.Andryuk@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julien Grall , Stefano Stabellini , Anthony PERARD , xen-devel@lists.xenproject.org References: <20241203081111.463400-1-Penny.Zheng@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: <20241203081111.463400-1-Penny.Zheng@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 03.12.2024 09:11, Penny Zheng wrote: > amd-pstate is the AMD CPU performance scaling driver that introduces a > new CPU frequency control mechanism on modern AMD APU and CPU series in > Xen. The new mechanism is based on Collaborative Processor Performance > Control (CPPC) which provides finer grain frequency management than > legacy ACPI hardware P-States. Current AMD CPU/APU platforms are using > the ACPI P-states driver to manage CPU frequency and clocks with > switching only in 3 P-states. CPPC replaces the ACPI P-states controls > and allows a flexible, low-latency interface for Xen to directly > communicate the performance hints to hardware. > > amd_pstate CPPC has 2 operation modes: autonomous (active) mode, > and non-autonomous (passive) mode. We register different CPUFreq driver > for different modes, "amd-pstate" for passive mode and "amd-pstate-epp" > for active mode. > > The passive mode leverages common governors such as *ondemand*, > *performance*, etc, to manage the performance hints. And the active mode > uses epp to provides a hint to the hardware if software wants to bias > toward performance (0x0) or energy efficiency (0xff). CPPC power algorithm > will calculate the runtime workload and adjust the realtime cpu cores > frequency according to the power supply and thermal, core voltage and some > other hardware conditions. > > amd-pstate is enabled with a top-level cpufreq=amd-pstate option. It will > fallback to cpufreq=xen if amd-pstate is unavailable. > > With `cpufreq=amd-pstate,active`, We did a 60s sampling test to see the CPU > frequency change, through tweaking the energy_perf preference from > `xenpm set-cpufreq-cppc powersave` to `xenpm set-cpufreq-cppc performance`. > The outputs are as follows: > ``` > Setting CPU in powersave mode > Sampling and Outputs: > Avg freq 2000000 KHz > Avg freq 2000000 KHz > Avg freq 2000000 KHz > Setting CPU in performance mode > Sampling and Outputs: > Avg freq 4640000 KHz > Avg freq 4220000 KHz > Avg freq 4640000 KHz > ``` > > Penny Zheng (11): > xen/x86: add CPPC feature flag for AMD processors > xen/x86: introduce new sub-hypercall to get CPPC data > xen/x86: introduce "cpufreq=amd-pstate" xen cmdline > xen/x86: get processor max speed from DMI table > xen/x86: introduce a new amd pstate driver for cpufreq scaling > xen/cpufreq: introduce policy type when cpufreq_driver->setpolicy > exists > xen/cpufreq: only set gov NULL when cpufreq_driver.target() exists > x86/cpufreq: add "cpufreq=amd-pstate,active" para > xen/x86: implement EPP support for the AMD processors > tools/xenpm: Print CPPC parameters for amd-pstate driver > xen/cpufreq: Adapt SET/GET_CPUFREQ_CPPC xen_sysctl_pm_op for > amd-pstate driver Just to clarify: While certainly fine, it is a little surprising to see such a submission just after the submission deadline for 4.20 was passed. This is intended for 4.21 then, I expect? Or else have you talked to the release manager? Jan From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:04:53 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:04:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847491.1262568 (Exim 4.92) (envelope-from ) id 1tIOpv-0007SU-1o; Tue, 03 Dec 2024 09:04:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847491.1262568; Tue, 03 Dec 2024 09:04:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIOpu-0007SN-VQ; Tue, 03 Dec 2024 09:04:50 +0000 Received: by outflank-mailman (input) for mailman id 847491; Tue, 03 Dec 2024 09:04: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 1tIOpt-0007SH-CY for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:04:49 +0000 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [2a00:1450:4864:20::635]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a5212674-b155-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 10:04:47 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-aa549d9dffdso846728666b.2 for ; Tue, 03 Dec 2024 01:04: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 a640c23a62f3a-aa599953f9fsm588899866b.195.2024.12.03.01.04.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Dec 2024 01:04: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: a5212674-b155-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733216687; x=1733821487; 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=VtLwP3ekoMvcsVWikQLByRg6fVccSAjy9eZqzLqxRvI=; b=gpfKvSroi1l3zxADYY20Q0NZ5yjMs6xaKHtA0gL8Hwg0wJ8nivx3KdrvKnBt4V/1Qq RwOC+GA6vbmdPepVryM8cQvz79qmZmqbup/VREMUZ/+KOTiEdWPOHPQ4rwh2E2+62Kft jGQ8PNeIO6MST948kolYmrZM4UguI+UXJk92hc/pZetWVDgPEQ4PoCMFFLrCKranrJNP djg/SZZoWmcdyvPoeotdcSlK8AV05L3XBJWNm4k0l7TD12IDUZZ3rUSM0QBslRw0IoDa y3Dwel+65rGEg6d6T0dJhmhKUoWIeWlSy2fPFOmEQ35j8iYKB77FrfmqCtAanzX1Jq9i nKOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733216687; x=1733821487; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VtLwP3ekoMvcsVWikQLByRg6fVccSAjy9eZqzLqxRvI=; b=sDHYP92qoMgNJGoqyOZJvtNrkVP+GQEa/NUByb6r2LDoq11grMB6nMAEuhg/HNit80 mr2HUCchePBtSUpkU+x+imydYLb19uWlo6WvyhW0Ejnw/By8h+knhHgQclRMl8/xSs4P H33f67Ptm3Iohm2DwCEMDtxXkn1xDR15cg+39rap0NsgdPLwS5daWHaTFtoravDDd/G9 b5LtN8o+pQhXiOAn+noxfOaVXPVT09eC8oLIiUz0eLkD+u4Gqrf2xREPbWxn8FkUrdk0 OmNQEh44oPgc+8D/tigitvGWa6/5xyvGEV3LHxIRzwy6uy+QEvVSlVAIqsYuqzPW9DSU lm/Q== X-Forwarded-Encrypted: i=1; AJvYcCVTnM01sUHlscHrutkQnZEqLQnkfyzouAyqq06/7lPZ4XkodzkP3CPHHGxq3CI3M1eirCKzh+qiLLw=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx44rkmFeEd0Kp80EdBiaKAWJ1CPW91gMjzSpY0WrGtzZra/f+g +FRhyk0I0WkVlhZ3oDKyk1512rG2AbXnTHxYoJqdVcry53lBu90Bhu6YcneZdwi+2YgsJpnvJPo = X-Gm-Gg: ASbGncv+V3MCwhDPFKYZheFomhQY2d4UyJonEU9J0W/C0JYvZ4waQXLoa+PfuWhkuoV lTS4ipXDmyRb4LQopSpAGMlO6zN07r6r4ZLpcXNmr3CsCfrnbJk32xuxsIsfMGki06EG6mD6QZY dLopYObRBMJZCetT8Ul5bVJqmuBqjrNY7NeZ9CdWUwCzBHBJEzN1kcIfP0Vyq/WlJb/jnY4cIK8 uVkf/ocFNYBmtyF7oJctCP9S6VweXwjV5jDZlp5zUofwz2hEuGsSRKl/5RWVJljnh3RNKxwUwlj aAcNweqk/SMRyCVMBDnzN63WHkkekpAZiIA= X-Google-Smtp-Source: AGHT+IF3uBdlUcmUDYUstUEdTAi9dBk2kTBOC2+1XOH5oAzJbHV3QidF3PSZ3Ckus2z6pI5FXGRThQ== X-Received: by 2002:a17:906:30cf:b0:aa5:274b:60e4 with SMTP id a640c23a62f3a-aa5f7d9558cmr132091366b.29.1733216686907; Tue, 03 Dec 2024 01:04:46 -0800 (PST) Message-ID: <01fd16b9-f886-499e-b19c-59d20a089735@suse.com> Date: Tue, 3 Dec 2024 10:04:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] libs/guest: Fix migration compatibility with a security-patched Xen 4.13 To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20241203001629.132594-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: <20241203001629.132594-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 03.12.2024 01:16, Andrew Cooper wrote: > xc_cpuid_apply_policy() provides compatibility for migration of a pre-4.14 VM > where no CPUID data was provided in the stream. > > It guesses the various max-leaf limits, based on what was true at the time of > writing, but this was not correctly adapted when speculative security issues > forced the advertisement of new feature bits. Of note are: > > * LFENCE-DISPATCH, in leaf 0x80000021.eax > * BHI-CTRL, in leaf 0x7[2].edx > > In both cases, a VM booted on a security-patched Xen 4.13, and then migrated > on to any newer version of Xen on the same or compatible hardware would have > these features stripped back because Xen is still editing the cpu-policy for > sanity behind the back of the toolstack. > > For VMs using BHI_DIS_S to mitigate Native-BHI, this resulted in a failure to > restore the guests MSR_SPEC_CTRL setting: > > (XEN) HVM d7v0 load MSR 0x48 with value 0x401 failed > (XEN) HVM7 restore: failed to load entry 20/0 rc -6 > > Fixes: e9b4fe263649 ("x86/cpuid: support LFENCE always serialising CPUID bit") > Fixes: f3709b15fc86 ("x86/cpuid: Infrastructure for cpuid word 7:2.edx") > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:20:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:20:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847503.1262577 (Exim 4.92) (envelope-from ) id 1tIP4p-00029b-A8; Tue, 03 Dec 2024 09:20:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847503.1262577; Tue, 03 Dec 2024 09:20:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIP4p-00029U-7X; Tue, 03 Dec 2024 09:20:15 +0000 Received: by outflank-mailman (input) for mailman id 847503; Tue, 03 Dec 2024 09:20: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 1tIP4o-00029O-Af for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:20:14 +0000 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (mail-bn8nam04on20628.outbound.protection.outlook.com [2a01:111:f403:2408::628]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cbe5314e-b157-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 10:20:11 +0100 (CET) Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by PH7PR12MB6562.namprd12.prod.outlook.com (2603:10b6:510:212::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.19; Tue, 3 Dec 2024 09:20:07 +0000 Received: from DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::b04e:2da5:7189:4c4d%5]) with mapi id 15.20.8207.017; Tue, 3 Dec 2024 09: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: cbe5314e-b157-11ef-a0d3-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=T2WCnYVTlH5VWOi7zRvKKq1Qc/x9Oa5Hy46jixSAosBMqQz2TDRzsOX44huj4T02F++pN32bEarLKyAwxHmc2RgeK1ZgxaMu+axT+500uYm/p2xsOQ17/1xbQp3V2rCpP3P5NIbAKVqT3n9c9gCeiOHY4VUTXz849AkfIxS7g7sFhbvH66hBIcqFsLebVvAxHnO4jCTm2p5rc8bKQnNiyGvNd9h4Y+FWGaMl8Vjq+k/bDGAMPP9tcTun/t2ry9xESxt/HHH50kDet1/yupN3aQ3r0/DKyjgFp7+sfGHCpdNYmp9LbWu5jKPia3C0ljw+wEiARLMq45jSETL0V/quJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wpmG62rNwxUCRRSduoBNtHqYfSVIsRfGjwj5dP9BrEw=; b=D+v2DTkTzz7pCSpauHZVoUURcb/eQ2PnJske7HDDe0HZDx4WYBXcTaCx7AZpNN0ry/tp4Ucs+CKmNQdSWW9RqCYd237PfEkodQEDXgnHmX/ylZp+m+RbXQiZiLVwUS+vXmlLhPXA/GdB+nWOuWqmhewP+a6DBPdbI0c5PyRo10QJDErF99FI3ePGlmSlJKGr8QAGiRpRDlFjbKls4ILFB8gzhlQwv9Eyyk8tleVIy/X8v0j6dRzeGb/YOzSgTWx+YWdEyAAZ7PBvQOr8WYnobkghGiDeIiQB628ltvA/BJQd6rHCaEGQ05PGVDHVe4spv3pMtk5q/4p7gQTt78zapQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wpmG62rNwxUCRRSduoBNtHqYfSVIsRfGjwj5dP9BrEw=; b=O6W6AKoW9/j2cD3doKZN74NeCgR+Rjvva2GhfxYtjTmVdB+gEbSbF0K66MCwH8Mfe0V44W7+j6+5xA6k7/fgj5bE3xKPFDqS0SciK71zsC+DU7Kd1zuHh1vZclS+iH3tzEm4hpPcs7DmwHK956PFUVn+KVEKdgxq/Zi1FRO+xLI= From: "Penny, Zheng" To: Andrew Cooper , "xen-devel@lists.xenproject.org" CC: "Stabellini, Stefano" , "Huang, Ray" , "Ragiadakou, Xenia" , "Andryuk, Jason" , Jan Beulich , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: RE: [PATCH v1 01/11] xen/x86: add CPPC feature flag for AMD processors Thread-Topic: [PATCH v1 01/11] xen/x86: add CPPC feature flag for AMD processors Thread-Index: AQHbRVvdfIbZFgMPg0manVVUsTPS8rLUMQcAgAAMzBA= Date: Tue, 3 Dec 2024 09:20:07 +0000 Message-ID: References: <20241203081111.463400-1-Penny.Zheng@amd.com> <20241203081111.463400-2-Penny.Zheng@amd.com> <99fb0003-8ad6-403a-9340-40d9dc322429@citrix.com> In-Reply-To: <99fb0003-8ad6-403a-9340-40d9dc322429@citrix.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ActionId=407fcdab-ec81-48c0-a8ca-3e4e84714271;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ContentBits=0;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Enabled=true;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Method=Standard;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Name=AMD Internal Distribution Only;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SetDate=2024-12-03T09:18:10Z;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|PH7PR12MB6562:EE_ x-ms-office365-filtering-correlation-id: 78c64f74-354e-47f8-a49c-08dd137badc2 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700018; x-microsoft-antispam-message-info: =?utf-8?B?Qk5vWkJwOTVIQXJ3NUh0alA3amRHaktrS3NpaXFjZ0owNUVHNmtZa0pJZ2Rw?= =?utf-8?B?emJEbSsyK0NrTVM1bGQ5R0UwVDVxQkFubS9PY2k4RFpDcTJzZllma2RhVGNS?= =?utf-8?B?SnZNWXdmV3lFY2NaWHp6MkRtWVFabFg3YlNycUsrMEhDNHJnUXhJN1VnV1dz?= =?utf-8?B?TkNoUnpNVk4wWkc3TVBzYUNHekxkbXRkM21XSmpmdHI0Um4xLzJzM0lzZ1FY?= =?utf-8?B?eXJ1aEpCRmtuYWZSV0RmNW1HMmlSVGl2N0lyL3dWSjZURHRUYXJGOHNLZm1s?= =?utf-8?B?aU9FMXpEemNWMjJVejlkT010R0ZWbnBscFVjNURDYWpVRnpNMDFpNVIybzZv?= =?utf-8?B?WVRmSTA1c2tmT2p2TmxHbE1vSUsxdzd4QkttZDNoRExXVDdlb3Y4RVBGY0pR?= =?utf-8?B?STY0dzdaK05RM1FqNjRIdjhOUUptR09JdFVFaHg1ZzFZcW1EVVhMM2VRTVVY?= =?utf-8?B?SWh1aUR3eEhzSFhZQ3AxdnNFSzhyVFVmVHZaWkJGNXZlWDRyWW1aOGlvaEwy?= =?utf-8?B?Rk1oVHhkUXlqMjlERnc5Nkx5SUp3TjhDZ3JSZE1nb0F2a3FlV04wYS9aTWpz?= =?utf-8?B?LzQvVkhWOXJ0dVVibDBKeE5WMzErMTI0M1oyVGhSUVFTY1g1Vkw3VldOU29v?= =?utf-8?B?VFZZOXBvMDNMRHA0VHVOTmxlYmN6Rkx0V2thY2VSamo0aWZmUjl4NnFzMFlk?= =?utf-8?B?djV5RUNaS0JGc29vYTdHZnNFS0xJdFMvemsrS210RTcxczFEWFI1R1NVL3k3?= =?utf-8?B?S1dpdkxaeDIzWVloUUp0dG4xVllHaUhyb1JIOStSVGhuU2xnUFFKZGhYeXd4?= =?utf-8?B?M3VKTTFUaFRVV2tlZ0ZuVkZzTUxSelBMcWFTSGp5V2JxdU9qL0lHZlR0QThj?= =?utf-8?B?WlZLREpkbGJVcVF6d2ZpK1NZZVlzQk0wK0FHVWNTYzRQaXhHVVZNVmYvckxx?= =?utf-8?B?OU5STmF3aFVrL0VYNjA1YldTZFFPeEZJc3g1THQvQ29VL0tMOHMrNjhKN1dk?= =?utf-8?B?WWNITFVvWXIxblNyd2xXazRNS1k4aDlTL2dlclQyNGpWQ296U25sTWVHUTVq?= =?utf-8?B?SkJlUUNyd3NZQWJUR05vTWxMMmJ3VzhndWRINFh5UnVkWXhDTlRmNEgyT2Ns?= =?utf-8?B?T1MzZlRMMjVBMVAwTGlyOXFsMW5FeXhDZ080R1lPSkI4dERvVVkxazNqamJv?= =?utf-8?B?YXg4eFBxeGhqdVdtb2lpdGplMS9aTHREYldyOXkrYkZiaTdVaVVTZEIwdkcr?= =?utf-8?B?R2V0TnFxN2hQdENDdjhQWU5ydmlLZ3BiNDN0STZKbFdZZ3R0TjI3Wm1Naklv?= =?utf-8?B?M1pDV3c2UUdsZE1oOEluR1VnNnp5aExtUkg5OFNVODdOREE0eklXeU4zR1ZT?= =?utf-8?B?Y1N1SjZ4aEF3QzJKNGVvbWpyQ0JVdjNtZjRZSTh2cVZaZjhLeWR6aXNKS1Fy?= =?utf-8?B?NFZGdmpobDIzTlVNVTBIdU1jMnZJNmt3eWlyaUxDenUvbU5pbmhWejBpaFZO?= =?utf-8?B?eEVvN0pmTjUwTkZ0cXhQSWNxeUpCVzhEeW5MVXRRWWpqeGZYU3htaXBkV3B1?= =?utf-8?B?c0ZwTUo2TzBUVWNSbHFHQ1JPZE4vd2xpWHhQeXJxb0VGSWFBTVRYUWswWndy?= =?utf-8?B?N2tvUEkyWFVsY0UvS0F6RCtYMVJnL1RpL3hOVG92bkJ3bEpMRk1GRkFFUk5R?= =?utf-8?B?NWV2V3NJZldjZ1JnQlMvMlBuRkZoMExxenlPTk9CVEJnSXZLNkRUMmU0cmxo?= =?utf-8?B?NFFhaVliN0JuWEIvSmNvT1ZmbThmdGpRWEJCSHJ1T1c2WVZuWnNldHNabXJF?= =?utf-8?B?UU1uQnFnUTdVNHVFd1BWdzYzVmFJbFQ4ZnV2aUJ0N0JzZGgvMlJFaXd5VUhY?= =?utf-8?B?eEd0MzFiRzJVZzZVeG5zVy8xRnR6NjNmdlc3T1R1K1NQb3htWUNpUmhUM1lU?= =?utf-8?Q?+lOj3/LTXjs=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?d3VjM0FOSVJIajNHZFlXb0NpY3UxK01MaWIzdXNGZWwvZktKTjU1Y3d0Q0dM?= =?utf-8?B?c3R4Mm5SdVBHVDJqWW8yRC9jUDVyK1hyN2pSVEx2dHFKR2NMWGxkK3UvQXpp?= =?utf-8?B?dmVFRXZGRTFlb2FpWHlqL1JZbkpvT3BFbmtZRy8xa3pYak1XUVZkRUxabGRM?= =?utf-8?B?RlVVTG9BYmdDWDlHSHpMQS9IbXFHM0k4amVDMDNjbHhERG45RGdjUml0VC8w?= =?utf-8?B?emNIclAxN0FSWGJGakg3aFdieXFaUFZOY3JDK0VsZURIcFVsWE95bjU1NVpK?= =?utf-8?B?UVpSZjNxZitaTndkZ0YxbzdyNm4xZmM1cFl1Vm9ManI5WVArY2ZEdU5IdVN0?= =?utf-8?B?Nk1MQUJ3ZnY5c0t4VzZFckg5T3E3bFBycjAxUnJ6YlowdDlpdHA5QVJlMGs1?= =?utf-8?B?MjV5MnFKdGZiUEg1aC9OMEtINUJZMDcxOXZuSW5BY0djT3RUZTNlU1cxRW45?= =?utf-8?B?bHNpMU4zMTRVaFV0cEVjbDhmMlQ1ajFWU2h3b09rcm1paTlteVZTbm1ETDZN?= =?utf-8?B?QldYNG9ieXgwVkZ1NjAzRUFwZWk0ZDRnWVF3dlJQcjQyU01Za0gvakQxWjQx?= =?utf-8?B?NTljTmQrM05QT3NnRTJ3U1lQUjNTZmZ2TkhidGhSRTJDVi9KZVJTRDRtczhx?= =?utf-8?B?cDcyejB3eG1BWi9wMnNJdlhuY1NOOSswdGg5S1B3OUtLblpnZEw1RVJFNE5Q?= =?utf-8?B?MjUybkttUEVRS1F5RXVkTWdXdW9laXo4eGRkS29nanZpWXQrdVhsWkZEeUI1?= =?utf-8?B?NDVpQ0U0V1Q1WGJ4NkhqMTRzRTRUSWg5NzFZeGl1UXNUck1WTU5pR3pQMmd6?= =?utf-8?B?ZHlwaTBjZGFZUklMK3NMYVQxb3hlTmEzM3hjSjBBdVNVYTRpcy80blg5Mktl?= =?utf-8?B?MC9DaTZyNDZZREZ2Uy9BeCtJSDA0TVhWMkw5SnI2MHNDMkZTc3JsWU9Jdnov?= =?utf-8?B?Ny9TNHl3RUx3b2wrT2pmZVZrMmdKdUpzbnBRZkJwZWY2NUhoRTYvdWpMU1F2?= =?utf-8?B?WExrdU5TZjVnNW5sd0M3OXZ1SXdXWWxlWWxvTnB5WG1kVElHUzdCSEhjK2tC?= =?utf-8?B?V3JIOXVSekF3K3VnNUJkcHcyZXc3dFNpWjJpMUc4a284R1pDdytFQ2RsaXVX?= =?utf-8?B?WkMraEtYcjBwZE83Y2tCcXVpWnAwRUdOWFlMUlJxOGRCb2dqaEpqdWxqaW9r?= =?utf-8?B?TGR3U0oxVGRleURqSUxabU9lemRHYm9FclMzM0VBMzRrbVpoRVE0YWFvOCtN?= =?utf-8?B?TGRUa0hVZHROQnppTnJHUUY4ZWNxOEM0U3dxdmNCbjNiQVF6dUVaR2k0WDNl?= =?utf-8?B?VXhWWm5wSkFBcFJtMXBOQlZyWW5kYnVzdzV5bERlZnBQbys4MkRRSFdISlA5?= =?utf-8?B?V3p3dVBVQS8vS0ZwdzN1dmNYWDhtU2hMSVJXWWhZRVRIMHhNZUNKZ1JHdkMw?= =?utf-8?B?OFYxc3dlY2xtVjM1bzlKTTJ1aWNHRUM0VnJIcU5tU3d4Y3ltYkFQRTY1c0pq?= =?utf-8?B?Wm02eFdRR3RYUGl0WS9rbkJLMjNFQzlOT1czenNySkFXSWV3SExOMFY3Z3hW?= =?utf-8?B?Q21mZ0NYRmFOSUk0eEVQN1hSaW5XNFEvMi8vZkhlbjBjS0JveWVCTEdoQkd4?= =?utf-8?B?R09mU2pYTUlJVTlxSzVzTDFqcVFIb2lmTFpEYjRIczBCdFBpbGszSU9vK0JD?= =?utf-8?B?L1lLTVNHZTdUSHlBMXdkNUljR0JRMGdxcDJTSTFqc2RwdFNVNHVlTzJTUjVi?= =?utf-8?B?c2RHS1BjNDVObm5BWFdPeHBwRDlwRk9MS0cwOVFLYVVpSE9VcXJLOUtiOHd5?= =?utf-8?B?TnczMzl0cVhxNEY4emYvbURWYVFoTlhJZERjc3d6Qmo4K0hSdFo0ZExod3Jx?= =?utf-8?B?M1A1Mllna05JblF4UmJ5Tm42WUJxb1RBOWxPZ3dBbXNRN05zTWdoWkZJRFI1?= =?utf-8?B?bDdFeGZRV3hRbEUrTzVmbFE0ZEhLZ2w1NThDZzBCL3FIUHhGSzNvNUc1YUpt?= =?utf-8?B?RElaT1AvT0R3Q3ZGZlNjanpkQVFBNDczSGNDL3ViMHJiMWVmSGlmSGE4ZzJp?= =?utf-8?B?dWROekZMZjlQMlRIa3F3M0RlaWVYYndEcGZ5bVN5OXdEWVlCenVHVnp4WDdm?= =?utf-8?Q?2mXU=3D?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 78c64f74-354e-47f8-a49c-08dd137badc2 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2024 09:20:07.3539 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +t/zmztUsHGnIHGRYkPs8jwPvERtEIFZguXxgqgirNJeVAngfWip0I3vW2lxCtzyVTauVtgIimdxksrMKLnf1Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6562 W0FNRCBPZmZpY2lhbCBVc2UgT25seSAtIEFNRCBJbnRlcm5hbCBEaXN0cmlidXRpb24gT25seV0N Cg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW5kcmV3IENv b3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4NCj4gU2VudDogVHVlc2RheSwgRGVjZW1i ZXIgMywgMjAyNCA0OjMyIFBNDQo+IFRvOiBQZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5j b20+OyB4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcNCj4gQ2M6IFN0YWJlbGxpbmksIFN0 ZWZhbm8gPHN0ZWZhbm8uc3RhYmVsbGluaUBhbWQuY29tPjsgSHVhbmcsIFJheQ0KPiA8UmF5Lkh1 YW5nQGFtZC5jb20+OyBSYWdpYWRha291LCBYZW5pYSA8WGVuaWEuUmFnaWFkYWtvdUBhbWQuY29t PjsNCj4gQW5kcnl1aywgSmFzb24gPEphc29uLkFuZHJ5dWtAYW1kLmNvbT47IEphbiBCZXVsaWNo IDxqYmV1bGljaEBzdXNlLmNvbT47DQo+IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRy aXguY29tPg0KPiBTdWJqZWN0OiBSZTogW1BBVENIIHYxIDAxLzExXSB4ZW4veDg2OiBhZGQgQ1BQ QyBmZWF0dXJlIGZsYWcgZm9yIEFNRA0KPiBwcm9jZXNzb3JzDQo+DQo+IE9uIDAzLzEyLzIwMjQg ODoxMSBhbSwgUGVubnkgWmhlbmcgd3JvdGU6DQo+ID4gQWRkIENvbGxhYm9yYXRpdmUgUHJvY2Vz c29yIFBlcmZvcm1hbmNlIENvbnRyb2wgZmVhdHVyZSBmbGFnIGZvciBBTUQNCj4gPiBwcm9jZXNz b3JzLg0KPiA+DQo+ID4gYW1kLXBzdGF0ZSBpcyB0aGUgQU1EIENQVSBwZXJmb3JtYW5jZSBzY2Fs aW5nIGRyaXZlciB0aGF0IGludHJvZHVjZXMgYQ0KPiA+IG5ldyBDUFUgZnJlcXVlbmN5IGNvbnRy b2wgbWVjaGFuaXNtIG9uIG1vZGVybiBBTUQgQVBVIGFuZCBDUFUgc2VyaWVzLg0KPiA+IFRoZXJl IGFyZSB0d28gdHlwZXMgb2YgaGFyZHdhcmUgaW1wbGVtZW50YXRpb25zOiAiRnVsbCBNU1IgU3Vw cG9ydCINCj4gPiBhbmQgIlNoYXJlZCBNZW1vcnkgU3VwcG9ydCIuDQo+ID4NCj4gPiBSaWdodCBu b3csIHhlbiB3aWxsIG9ubHkgaW1wbGVtZW50ICJGdWxsIE1TUiBTdXBwb3J0IiwgYW5kIHRoaXMg bmV3DQo+ID4gZmVhdHVyZSBmbGFnIGluZGljYXRlcyB3aGV0aGVyIHByb2Nlc3NvciBoYXMgdGhp cyBmZWF0dXJlIG9yIG5vdC4NCj4NCj4gRG8geW91IGhhdmUgYSByZWZlcmVuY2UgdG8gd2hlcmUg dGhpcyBpcyBkb2N1bWVudGVkPw0KPg0KDQpZZXMsIGh0dHBzOi8vd3d3LmFtZC5jb20vY29udGVu dC9kYW0vYW1kL2VuL2RvY3VtZW50cy9wcm9jZXNzb3ItdGVjaC1kb2NzL3Byb2dyYW1tZXItcmVm ZXJlbmNlcy8yNDU5NC5wZGYNClNlZSBwYWdlIDYyOCBmb3IgQ1BVSUQgRm44MDAwXzAwMDhfRUJY IEV4dGVuZGVkIEZlYXR1cmUgSWRlbnRpZmllcnMNCg0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTog UGVubnkgWmhlbmcgPFBlbm55LlpoZW5nQGFtZC5jb20+DQo+ID4gLS0tDQo+ID4gIHhlbi9hcmNo L3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmggICAgICAgfCAxICsNCj4gPiAgeGVuL2luY2x1 ZGUvcHVibGljL2FyY2gteDg2L2NwdWZlYXR1cmVzZXQuaCB8IDEgKw0KPiA+ICAyIGZpbGVzIGNo YW5nZWQsIDIgaW5zZXJ0aW9ucygrKQ0KPiA+DQo+ID4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4 Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgNCj4gPiBiL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2Fz bS9jcHVmZWF0dXJlLmgNCj4gPiBpbmRleCAzYTA2YjZmMjk3Li42OTM1NzAzZTcxIDEwMDY0NA0K PiA+IC0tLSBhL3hlbi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9jcHVmZWF0dXJlLmgNCj4gPiArKysg Yi94ZW4vYXJjaC94ODYvaW5jbHVkZS9hc20vY3B1ZmVhdHVyZS5oDQo+ID4gQEAgLTE3MCw2ICsx NzAsNyBAQCBzdGF0aWMgaW5saW5lIGJvb2wgYm9vdF9jcHVfaGFzKHVuc2lnbmVkIGludCBmZWF0 KQ0KPiA+ICAjZGVmaW5lIGNwdV9oYXNfYW1kX3NzYmQgICAgICAgIGJvb3RfY3B1X2hhcyhYODZf RkVBVFVSRV9BTURfU1NCRCkNCj4gPiAgI2RlZmluZSBjcHVfaGFzX3ZpcnRfc3NiZCAgICAgICBi b290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfVklSVF9TU0JEKQ0KPiA+ICAjZGVmaW5lIGNwdV9oYXNf c3NiX25vICAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9TU0JfTk8pDQo+ID4gKyNk ZWZpbmUgY3B1X2hhc19jcHBjICAgICAgICAgICAgYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX0NQ UEMpDQo+ID4gICNkZWZpbmUgY3B1X2hhc19hdXRvX2licnMgICAgICAgYm9vdF9jcHVfaGFzKFg4 Nl9GRUFUVVJFX0FVVE9fSUJSUykNCj4gPg0KPiA+ICAvKiBDUFVJRCBsZXZlbCAweDAwMDAwMDA3 OjAuZWR4ICovDQo+ID4gZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9j cHVmZWF0dXJlc2V0LmgNCj4gPiBiL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0 dXJlc2V0LmgNCj4gPiBpbmRleCA4ZmEzZmI3MTFhLi4xNWY3MDc2MzliIDEwMDY0NA0KPiA+IC0t LSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgNCj4gPiArKysg Yi94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oDQo+ID4gQEAgLTI2 NSw2ICsyNjUsNyBAQCBYRU5fQ1BVRkVBVFVSRShBTURfUFBJTiwgICAgICA4KjMyKzIzKSAvKg0K PiBQcm90ZWN0ZWQgUHJvY2Vzc29yIEludmVudG9yeSBOdW1iZXINCj4gPiAgWEVOX0NQVUZFQVRV UkUoQU1EX1NTQkQsICAgICAgOCozMisyNCkgLypTICBNU1JfU1BFQ19DVFJMLlNTQkQNCj4gYXZh aWxhYmxlICovDQo+ID4gIFhFTl9DUFVGRUFUVVJFKFZJUlRfU1NCRCwgICAgIDgqMzIrMjUpIC8q IQ0KPiBNU1JfVklSVF9TUEVDX0NUUkwuU1NCRCAqLw0KPiA+ICBYRU5fQ1BVRkVBVFVSRShTU0Jf Tk8sICAgICAgICA4KjMyKzI2KSAvKkEgIEhhcmR3YXJlIG5vdCB2dWxuZXJhYmxlIHRvDQo+IFNT QiAqLw0KPiA+ICtYRU5fQ1BVRkVBVFVSRShDUFBDLCAgICAgICAgICA4KjMyKzI3KSAvKkEgIENv bGxhYm9yYXRpdmUgUHJvY2Vzc29yDQo+IFBlcmZvcm1hbmNlIENvbnRyb2wgKi8NCj4NCj4gVGhl cmUgbmVlZHMgdG8gYmUgbm8gIkEiIGluIHRoaXMgcGF0Y2gsIGJlY2F1c2UgaXQncyBjZXJ0YWlu bHkgbm90IHJlYWR5IHRvIGFkdmVydGlzZQ0KPiB0byBndWVzdHMgeWV0Lg0KPg0KPiBJZiB5b3Un cmUgaW50ZW5kaW5nIGl0IGZvciBldmVudHVhbCB1c2UgYnkgZ3Vlc3RzLCB0aGVuIHRoZSAiQSIg b25seSBnb2VzIGJhY2sgaW4gYXQgdGhlDQo+IGVuZCBvZiB0aGUgc2VyaWVzIHdoZW4gdGhlIHN1 cHBvcnQgdG8gY29ycmVjdGx5IHZpcnR1YWxpc2UgaXQgYXBwZWFycywgYnV0IGl0IGxvb2tzIGxp a2UNCj4gaXQgd2lsbCBiZSBYZW4tb25seS4NCj4NCg0KVW5kZXJzdG9vZCEgVGh4IGZvciB0aGUg ZXhwbGFuYXRpb24uIEknbGwgcmVtb3ZlIGluIG5leHQgU2VyaWUNCg0KPiB+QW5kcmV3DQoNCk1h bnkgdGhhbmtzLA0KUGVubnkNCg== From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:21:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:21:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847514.1262588 (Exim 4.92) (envelope-from ) id 1tIP6U-0003Bt-Ni; Tue, 03 Dec 2024 09:21:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847514.1262588; Tue, 03 Dec 2024 09: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 1tIP6U-0003Bk-Kp; Tue, 03 Dec 2024 09:21:58 +0000 Received: by outflank-mailman (input) for mailman id 847514; Tue, 03 Dec 2024 09:21: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 1tIP6T-0003Be-Gf for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:21:57 +0000 Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [2a00:1450:4864:20::129]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0a52347e-b158-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 10:21:56 +0100 (CET) Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-53de8ecb39bso6148779e87.2 for ; Tue, 03 Dec 2024 01:21:56 -0800 (PST) Received: from localhost.localdomain ([176.187.209.146]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5996c1945sm587682966b.19.2024.12.03.01.21.54 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 03 Dec 2024 01:21: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: 0a52347e-b158-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1733217716; x=1733822516; 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=7YrECqGgLUZ1d6WAaLttV2kaR/8HcO6J1SyjXJDIUtI=; b=TIAJWMPqwpUutjBdCnY/UZcjjrboxyd3RJA699GFOfyK/0UN+9Hr+X2YvsFo7UCCUt 9eoBRrHLkVTMw61jY32+nOgWr+AWEb6wYGxa2zFWtd6kMXcKApgFP+9OOwqCpQMokwzS 5zippWFE+6K3j4r80/VavGgZtP7L5w5crzA6vRSmCKb0Fr/QftgIFGojXAJq1Urk3PXu svqH+SmCZ8WlvAj+0Wu7vHg+LAw8B95nu3Cp6NoFEUwRWsGtioU5GSnYRT69Df95clx3 san7d4MKP4KGdz4vlDcPYgdJjeP/1JT8UN9mLkmzh8m93xBzxuzTCQvQ9PgL8nd/v/0U E/rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733217716; x=1733822516; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7YrECqGgLUZ1d6WAaLttV2kaR/8HcO6J1SyjXJDIUtI=; b=C4+x4h1AU+tZDSSwW1y5bA4iztUpjvqQdfK+iMeYlnu/88zrEnkMGRlt4fVJ5iHjXo TZZX318/obK2fLuxbRewnbEyop5ZV4Ang3Ij6YoVWOHPoXxqmLw8snxNxRIdxV6C3obj bZqtKP00ENnm49dMfo0Wm2NsBDgDeH74XYRYvdWr7c2+BUupqKbkMUrK9reTFKtv9GfM ZIpIeh+io0JUpvVZy+E9cAE9eYO7rlbun/2QfCeReDE1CdPtPOHDo7/CzQHyEzPcNXxh UEK6fa5sFLO9jG2JiTnEw6eBfYXFamFBuzsCruUpsXC11rS0RUA4eOsCT72bDgsaNJU7 sdyA== X-Forwarded-Encrypted: i=1; AJvYcCXgrNn9GvZRw+BMLNcrFwGk57Fc0FLgiKleoqWjeyt6Oj8vzIsoAx4iE42cGld3SG3dbpZkUyqQ3Ew=@lists.xenproject.org X-Gm-Message-State: AOJu0YyMI3az25+Q2TOHegzGxW3cTjdCSZDj71tNfxO4nx24Xf/KZjy6 dotCpxmKj+Y/lwDp/q2PXmqOj310akcYkkiQkPSxWdSz7gMvSWGeSS4VQEfMbPo= X-Gm-Gg: ASbGncuzlLj4Nbd3CTMEnouFGS35AfV9QfwkTykKSiu+u20QhpuafmCkZH4dnNMeoah zUBDHNyJ6O22JeCooLmIVrSCOFLjbl+6dPkut2euK87XVjsUiHmNYYlNPsxlAGBL4/6ntHesRwH Mp+hNJn0qJFDl10MFFgFU944YVfsVayZNWwn9qlIL+Cyaoeoc5PlTWQDiG3v9WnPCmuZpn+cS1P yVHgC5Zwp25WcWhERW1QPi1Wu5tFZvKW6vFI28Ket6WOldNOgDFhrbauut8DwHaVkAs3U3C X-Google-Smtp-Source: AGHT+IGkt6mxy3bo2pU8QJ+xjjL4dNnVHS7c3xduFhLG6J04XUp0rGi+FzFB5ZjxOtJwHrXFCV9gJQ== X-Received: by 2002:a05:6512:1313:b0:53d:ed94:fe64 with SMTP id 2adb3069b0e04-53e129ef4aemr1305626e87.10.1733217715863; Tue, 03 Dec 2024 01:21:55 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: Paolo Bonzini , =?UTF-8?q?Daniel=20P=20=2E=20Berrang=C3=A9?= , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org, Thomas Huth , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Subject: [PATCH 0/7] cli: Remove mentions of legacy '-machine foo,accel=bar' command line Date: Tue, 3 Dec 2024 10:21:46 +0100 Message-ID: <20241203092153.60590-1-philmd@linaro.org> X-Mailer: git-send-email 2.45.2 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Thomas told '-machine foo,accel=bar' is sugar and almost deprecated. Rather than having bad examples in the tree, remove the legacy form and update to the new '-accel bar' one. Xen uses via MachineClass::default_machine_opts left for later: hw/i386/pc_piix.c:818: m->default_machine_opts = "accel=xen,suppress-vmdesc=on"; hw/i386/pc_piix.c:830: m->default_machine_opts = "accel=xen,suppress-vmdesc=on"; hw/xen/xen-pvh-common.c:381: mc->default_machine_opts = "accel=xen"; hw/xenpv/xen_machine_pv.c:69: mc->default_machine_opts = "accel=xen"; Philippe Mathieu-Daudé (7): tests/functional/test_ppc64_hv: Remove legacy '-machine foo,accel=bar' tests/functional/test_virtio_gpu: Remove legacy '-machine foo,accel=bar' tests/qtest/fuzz: Remove legacy '-machine foo,accel=bar' scripts/device-crash-test: Remove legacy '-machine foo,accel=bar' accel/tcg: Remove mentions of legacy '-machine foo,accel=bar' accel/kvm: Remove mentions of legacy '-machine foo,accel=bar' qemu-options: Remove mentions of legacy '-machine foo,accel=bar' docs/about/removed-features.rst | 2 +- docs/bypass-iommu.txt | 3 ++- docs/nvdimm.txt | 2 +- docs/specs/tpm.rst | 2 +- docs/system/arm/cpu-features.rst | 2 +- docs/system/cpu-hotplug.rst | 2 +- docs/system/ppc/powernv.rst | 2 +- docs/system/ppc/pseries.rst | 4 ++-- linux-user/s390x/target_proc.h | 2 +- accel/tcg/monitor.c | 4 ++-- system/vl.c | 2 +- tests/qtest/fuzz/generic_fuzz.c | 2 +- tests/qtest/fuzz/i440fx_fuzz.c | 2 +- tests/qtest/fuzz/qos_fuzz.c | 2 +- tests/qtest/qmp-cmd-test.c | 2 +- qemu-options.hx | 9 --------- scripts/device-crash-test | 11 ++++++++--- scripts/oss-fuzz/output_reproducer.py | 2 -- scripts/oss-fuzz/reorder_fuzzer_qtest_trace.py | 6 +++--- tests/functional/test_ppc64_hv.py | 3 ++- tests/functional/test_virtio_gpu.py | 6 ++++-- 21 files changed, 35 insertions(+), 37 deletions(-) -- 2.45.2 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:22:05 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:22:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847515.1262597 (Exim 4.92) (envelope-from ) id 1tIP6a-0003ST-VB; Tue, 03 Dec 2024 09:22:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847515.1262597; Tue, 03 Dec 2024 09:22:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIP6a-0003SM-SI; Tue, 03 Dec 2024 09:22:04 +0000 Received: by outflank-mailman (input) for mailman id 847515; Tue, 03 Dec 2024 09:22: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 1tIP6a-0003Ra-1G for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:22:04 +0000 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [2a00:1450:4864:20::12a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0de70a18-b158-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 10:22:02 +0100 (CET) Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-53df6322ea7so9025667e87.0 for ; Tue, 03 Dec 2024 01:22:02 -0800 (PST) Received: from localhost.localdomain ([176.187.209.146]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa599908be5sm591969266b.140.2024.12.03.01.22.00 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 03 Dec 2024 01:22: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: 0de70a18-b158-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1733217722; x=1733822522; 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=XItCJo5+ANEXJJ4rNbIonoA3BAW/mx+bgexv+wsAke8=; b=lYSS1UjsP3SYWBGfErLLhzadHBbklYQcYKcFvItkVEUX3hGMb+2E34viwr67ih07+z mipLjH5voNoB6jgTguovCh9AIewy8DV5dQxKZiVFcaL2H1EmWh/KsYukVK931etRlhyQ CREVUxIPW+FwjBpMhqDEyTnuphYzmvTBzWyPXbeH9MkPCwu/nddWGjzCDgepxSClUg2S 4T79uQbjo+4Lpc2jzIFFAGjsg5tJ+025n9fmCC+TnJ/KRd0C/mcFk7Swxz9G/4O1/fO9 30aGKHmQC21fi2UCrhutdBztO2v21vl2Ab59rdVhHHtqQy/wu0gLgtMZthbe/jv1pL9E 58tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733217722; x=1733822522; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=XItCJo5+ANEXJJ4rNbIonoA3BAW/mx+bgexv+wsAke8=; b=m1pYas7CuNJtNzfFMeyli8csZPQUdIYrGeeisF/MocGscGWQACw2YqH7nBs1KaOx8V UoR6/8/5BL7lcxmbMWlKHvQHCy0lz3M7JrGiSR/tEve9e2r6amrcaatYC+vbYbYRPE2V K9NCYfvkRRwYGv4Tw1x/t4On10MjV2ECcrhZPWFpE/dOSQmbRY0hyvBWA/J4Q/rtcYko L+p8oN0mgDAkCcNg95iRVE/Ec5Ci8A0U1cM/nIlNGp0yzLJ8F0n4rKIaJrvvSNzHdVN8 h5Afi119v1MB06nSZt9nHgLobcW2njFv8BRZiYXsac7xa63Fucb6piIBaXeaSsLdBbW3 c7Pg== X-Forwarded-Encrypted: i=1; AJvYcCVzCBrBNPS/MzsovcnOw57EZc93PC0r6fcs8kK4rZ/tN3GQJehybU39D8NskkIYOjiOaGZrZ0jh01E=@lists.xenproject.org X-Gm-Message-State: AOJu0YwuQaE3/uYr2TkjkHsXNxXpWuyXsIgzxtjBSq3vrPsT5IUR2O2D ATxKLM6l5Eo6KG9OiVKeb4JlaINcvWFAtmiJNb5ykssZYMmwq8SdljDuqWZDWHI= X-Gm-Gg: ASbGncuIdQO8Ghk/2R/vY9gOrYVZ77PRKoxvQdP/+5kbMU4iwqaBK2hUMkHHkZsckao +kBEuDc/9mPSyginkTzJJ+yOnvUbmshhh+PQg6YaksejTqsrqIcDrz4a20OLbch0IWCADhbui1p TiC2bYgeCZUvP3wYBHWlLUfzdQR9V/dMMdMrW16XruWM0eekyiAPYci/68lTQ7l7W3Fbd3nZzOe 6bORDN0bIOmIrujvUIBCGwtveBJyj8NElp2pFdgSh2Rb9LFnOCQxQYa/VwmEqRs6WKFNqlj X-Google-Smtp-Source: AGHT+IELVm7e97U6LHV1aSNR3lGVC9QDV3n0nCKk5HiuyFOrOWNT99UW+76qnuiTrgbzvwhK7O0Rcg== X-Received: by 2002:ac2:5967:0:b0:53e:12f2:5e02 with SMTP id 2adb3069b0e04-53e12f25e19mr1049931e87.42.1733217721439; Tue, 03 Dec 2024 01:22:01 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: Paolo Bonzini , =?UTF-8?q?Daniel=20P=20=2E=20Berrang=C3=A9?= , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org, Thomas Huth , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Subject: [PATCH 1/7] tests/functional/test_ppc64_hv: Remove legacy '-machine foo,accel=bar' Date: Tue, 3 Dec 2024 10:21:47 +0100 Message-ID: <20241203092153.60590-2-philmd@linaro.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20241203092153.60590-1-philmd@linaro.org> References: <20241203092153.60590-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Since commit 6f6e1698a68 ("vl: configure accelerators from -accel options") we prefer the '-accel bar' command line option. Replace '-machine foo,accel=bar' -> '-machine foo -accel bar' in functional tests. Signed-off-by: Philippe Mathieu-Daudé --- tests/functional/test_ppc64_hv.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/functional/test_ppc64_hv.py b/tests/functional/test_ppc64_hv.py index 312248bbfe4..536a433b993 100755 --- a/tests/functional/test_ppc64_hv.py +++ b/tests/functional/test_ppc64_hv.py @@ -138,7 +138,8 @@ def do_test_kvm(self, hpt=False): else: append = '' exec_command(self, 'qemu-system-ppc64 -nographic -smp 2 -m 1g ' - '-machine pseries,x-vof=on,accel=kvm ' + '-accel kvm ' + '-machine pseries,x-vof=on ' '-machine cap-cfpc=broken,cap-sbbc=broken,' 'cap-ibs=broken,cap-ccf-assist=off ' '-drive file=/dev/nvme0n1,format=raw,readonly=on ' -- 2.45.2 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:22:10 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:22:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847517.1262609 (Exim 4.92) (envelope-from ) id 1tIP6g-0003lM-8x; Tue, 03 Dec 2024 09:22:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847517.1262609; Tue, 03 Dec 2024 09:22:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIP6g-0003lD-3u; Tue, 03 Dec 2024 09:22:10 +0000 Received: by outflank-mailman (input) for mailman id 847517; Tue, 03 Dec 2024 09:22: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 1tIP6e-0003Be-73 for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:22:08 +0000 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [2a00:1450:4864:20::52c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 10fb037f-b158-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 10:22:07 +0100 (CET) Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-5d0be79e7e7so4771954a12.0 for ; Tue, 03 Dec 2024 01:22:07 -0800 (PST) Received: from localhost.localdomain ([176.187.209.146]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d0c8dc9b8asm3868557a12.17.2024.12.03.01.22.05 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 03 Dec 2024 01:22: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: 10fb037f-b158-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1733217727; x=1733822527; 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=QhfmnQV2U1yeLbQ0YN69JuJChLdIfKrfDAxolXgPuaM=; b=NY2YzZpXib/9b46FQvVQ5Pa0ome/80ghyw/L1Emqfl+JAXKlIn78p1aIcwQNgxobhk tGfWaGjGcwMltnXFi5H0xspUtgKONh6Z9sCfVvth/fwv3Uc2hUKUi0m4M4G8lf5IwOvX X2DrfqG8D5A3eLhYYgyGx86ncpctJiuOFHvrZMRxsAqCJToNtuqx7uSUG2zaZ39Wq8I5 hAGY18duND5LLbQw8gMmsqhT1HjkjCG5rcgAedOzyKjy6ltocLcvQnFUz57E92DJ2wSk jUDKO54J2Iq9zYv0Yyv4rkCc+75U4iW6qyT2wMcl856mSpfIKmBPnYaGh4U4JMHB5a7H 6yJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733217727; x=1733822527; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QhfmnQV2U1yeLbQ0YN69JuJChLdIfKrfDAxolXgPuaM=; b=CZ+xjSpH9/MX7XbHeKYbIupPYS9+Jn1cT3zd3jdwMUkZc7ZzBETgESM6lsOsIACy+1 HVszYRn5sksxXlMdGDb7p1RCypxQ/qhOmd1N1VS/O31+NhRYSr0kZXu5tNqDco9tGUep h1G41Ckek7nS14hPHA8Xemb63WBR5Mdx4hPuNjyVzCu2tLfOg+ogwApumV8EmZlo6i2/ /V4rH1lEPofKIIvFZaCgsq3T1XCJpa4+P+Yk9Z3vNcLY5HrV1A1cEO6Ij+BBConeU2WH dSDyFh+mzasn3c6/MaeBV5jXX2MIvl9G26ySmJ63Vop2YT659QtZoqdEwfjGmfYIPjiX TNtQ== X-Forwarded-Encrypted: i=1; AJvYcCVotojgVrKTzmmAYxvUK/8U7YFrWkAf1Rs5noBfgH39j/XcOV+HzR0QU1tjsY9IytZ+4fMJEoLKHkI=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzwc0borwUhKZiCJ7gSHx2fRKdOETD7ye+HId4kILoOcc+ETVTU RMkas9vaEjzMZLQ4ezJMEZzxDdqdZj8mLvP/T09a1k+pJCiifSEM3nEyU/OambI= X-Gm-Gg: ASbGncsJJAU6M5Jt0jZXN/n4UdFU2z5gyOUehi8GWKIqrfR6qVajUy8t5NuoP4W5i8i 4JwCay3bxP8WYcgtF4obyPXm9e2dycF5Bv+fWQ85e/p4BiBj0zOFP7fDV2/bE38tXFpCFfCM+xw NPt3itNUjGErBKitFCrqxnJrcrKzvMZBtHz26n8kQni1egRf/jUDiRK0DGjatJKlXmehpUw5HJ3 /RkfNQY+auESz3BV377kgLiqYPlY76SsPLdYj2ofdAFnB02t6THSjFwoMKUa02IXmlK/9aE X-Google-Smtp-Source: AGHT+IExs5Yi7XHHfGv+VoO8nUw6diCtB41A7VJ/kLqxsUAKXSiS5Jv3sEFudcXPJVh9yDPwSljpgA== X-Received: by 2002:a05:6402:518c:b0:5d0:abb8:799 with SMTP id 4fb4d7f45d1cf-5d10cb4e1ccmr1719770a12.7.1733217727075; Tue, 03 Dec 2024 01:22:07 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: Paolo Bonzini , =?UTF-8?q?Daniel=20P=20=2E=20Berrang=C3=A9?= , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org, Thomas Huth , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Subject: [PATCH 2/7] tests/functional/test_virtio_gpu: Remove legacy '-machine foo,accel=bar' Date: Tue, 3 Dec 2024 10:21:48 +0100 Message-ID: <20241203092153.60590-3-philmd@linaro.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20241203092153.60590-1-philmd@linaro.org> References: <20241203092153.60590-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Since commit 6f6e1698a68 ("vl: configure accelerators from -accel options") we prefer the '-accel bar' command line option. Replace '-machine foo,accel=bar' -> '-machine foo -accel bar' in functional tests. Signed-off-by: Philippe Mathieu-Daudé --- tests/functional/test_virtio_gpu.py | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tests/functional/test_virtio_gpu.py b/tests/functional/test_virtio_gpu.py index d5027487ac4..cc0ec234861 100755 --- a/tests/functional/test_virtio_gpu.py +++ b/tests/functional/test_virtio_gpu.py @@ -61,7 +61,8 @@ def test_virtio_vga_virgl(self): self.vm.set_console() self.vm.add_args("-cpu", "host") self.vm.add_args("-m", "2G") - self.vm.add_args("-machine", "pc,accel=kvm") + self.vm.add_args('-accel', 'kvm') + self.vm.add_args("-machine", "pc") self.vm.add_args("-device", "virtio-vga-gl") self.vm.add_args("-display", "egl-headless") self.vm.add_args( @@ -118,10 +119,11 @@ def test_vhost_user_vga_virgl(self): ) self.vm.set_console() + self.vm.add_args('-accel', 'kvm') self.vm.add_args("-cpu", "host") self.vm.add_args("-m", "2G") self.vm.add_args("-object", "memory-backend-memfd,id=mem,size=2G") - self.vm.add_args("-machine", "pc,memory-backend=mem,accel=kvm") + self.vm.add_args("-machine", "pc,memory-backend=mem") self.vm.add_args("-chardev", "socket,id=vug,fd=%d" % qemu_sock.fileno()) self.vm.add_args("-device", "vhost-user-vga,chardev=vug") self.vm.add_args("-display", "egl-headless") -- 2.45.2 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:22:15 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:22:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847520.1262618 (Exim 4.92) (envelope-from ) id 1tIP6l-0004Ag-ES; Tue, 03 Dec 2024 09:22:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847520.1262618; Tue, 03 Dec 2024 09:22:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIP6l-0004AX-Bh; Tue, 03 Dec 2024 09:22:15 +0000 Received: by outflank-mailman (input) for mailman id 847520; Tue, 03 Dec 2024 09:22: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 1tIP6j-0003Be-MH for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:22:13 +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 1446cfc6-b158-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 10:22:12 +0100 (CET) Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5cf6f367f97so6273392a12.0 for ; Tue, 03 Dec 2024 01:22:13 -0800 (PST) Received: from localhost.localdomain ([176.187.209.146]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa599801591sm590543266b.91.2024.12.03.01.22.11 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 03 Dec 2024 01:22: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: 1446cfc6-b158-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1733217732; x=1733822532; 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=C/6Bk/TIHmUcRxz6rQ6nK013EsFPgzobZnpt1ORjNTg=; b=Ns0faxOLv/DHDL/hqcwnpNQ3liJ2RfEeerFr/34ttx5RJ1+/MeAKddbDKOrl2WfG6n d43uB0eBHdycZG1VAMySXGfehlWPhi9b3B9Jw4aNI/CYAuDP7ocxRYhNJnw+I5iBF/v5 1Vnp7RlQiJGH9byGA15iwLiwvBbwA8z7f9qgsRazuBWwzcsftQf6ijzIqLw3HH7ddYOC /eHicsE6K01d2pxaEg7XLMgTIa01Yn1Z2WRNkXKCAo7ViEveCgD+sq/P9qdePe9QfLsu MRTCI7nmuI8dbNweZbrgltQAToBJLa/Kk3MEh4OXoVcEij5uOKf5K19CW6ScLN+LPkW6 8hKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733217732; x=1733822532; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=C/6Bk/TIHmUcRxz6rQ6nK013EsFPgzobZnpt1ORjNTg=; b=PRFGVfn2u4qyHzB6Psi4MS0990fQrPPSQGviSSf313HUAPpXoV5FC3GehFczY/s9k0 tHFUztD/VA/r0NO92Ix+fxutAOCbG0QSlwL2ctY/nXeNauQDXfbbAT7ILNV8Omjee5IP 6duBsqz/8ObyF5Ih44fis/zPm3fD6vgGHjNwY+dAWzFA9IFy33a9nm35vCQtYOzuylM8 oqg3lDipstHfl7yAvg+GbmY8RTuq1c5c0x5vhUHdN5KeMflx3veMzcm2ZGIF6viZab2V 7N+H5qkuNNwTrxY/bC0/0lTUgiT4foLRhGGXR4LtDj6XoLFzWA0Zj9QHVJKXbVphX26P K5gQ== X-Forwarded-Encrypted: i=1; AJvYcCXsu8lwBwrh3lfJCWWcLvoEJmJMbu4rB6iVTITibiVnbwOy67CnCmiXUgORgfMuaGhh3rgRXiFD988=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxivcle1vKA+1EMRaM+Wd8KGhn5iNDQxr/COMpgey2qLNCsQcax iNaKZDSPPvb0+uLfAc0HicN/R+fte85jO3WRqdCIajM2Eyq1tgwrQUJL3bXuA08= X-Gm-Gg: ASbGncsqA/x2JjpFWittxkRGfq7wLC7nu7kpUWkfBf5eeUBCeMPKHDtSwx/WJ0i91GZ dglcSBSjRRuoC7iZLcMudnErhBy5ROGnCmJmjDoLt8JbSvQvUpuEuyFKAE3UpflH7H6SnFLIK31 J6HUUj7xSQwLvp3dNE8cEwy57rZ5oafGhXjeXH+qjTb7Ppdn+hEIwQ7Gub7sHg2FTnQxwptAJc0 t41OZ+96dMXhim9/DY44ob29jMDR6XK1RxuUOmPy8jhdYuO0pj6dudCnKfkoVcfQIbOneWG X-Google-Smtp-Source: AGHT+IHoObOZjdwlMr3aboz/4y2YVDb50eN7RHCCjr/fwpXa6yi9c/pFOSALP0ifpRtK2osZHvNbbA== X-Received: by 2002:a17:906:30cb:b0:aa5:297a:ac65 with SMTP id a640c23a62f3a-aa5f7d4ec91mr122028566b.19.1733217732604; Tue, 03 Dec 2024 01:22:12 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: Paolo Bonzini , =?UTF-8?q?Daniel=20P=20=2E=20Berrang=C3=A9?= , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org, Thomas Huth , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Subject: [PATCH 3/7] tests/qtest/fuzz: Remove legacy '-machine foo,accel=bar' Date: Tue, 3 Dec 2024 10:21:49 +0100 Message-ID: <20241203092153.60590-4-philmd@linaro.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20241203092153.60590-1-philmd@linaro.org> References: <20241203092153.60590-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Since commit 6f6e1698a68 ("vl: configure accelerators from -accel options") we prefer the '-accel bar' command line option. Replace '-machine foo,accel=bar' -> '-machine foo -accel bar' in fuzzer scripts and tests. Signed-off-by: Philippe Mathieu-Daudé --- tests/qtest/fuzz/generic_fuzz.c | 2 +- tests/qtest/fuzz/i440fx_fuzz.c | 2 +- tests/qtest/fuzz/qos_fuzz.c | 2 +- scripts/oss-fuzz/output_reproducer.py | 2 -- scripts/oss-fuzz/reorder_fuzzer_qtest_trace.py | 6 +++--- 5 files changed, 6 insertions(+), 8 deletions(-) diff --git a/tests/qtest/fuzz/generic_fuzz.c b/tests/qtest/fuzz/generic_fuzz.c index d107a496da6..a8737a4c463 100644 --- a/tests/qtest/fuzz/generic_fuzz.c +++ b/tests/qtest/fuzz/generic_fuzz.c @@ -919,7 +919,7 @@ static GString *generic_fuzz_cmdline(FuzzTarget *t) usage(); } g_string_append_printf(cmd_line, " -display none \ - -machine accel=qtest, \ + -accel qtest \ -m 512M %s ", getenv("QEMU_FUZZ_ARGS")); return cmd_line; } diff --git a/tests/qtest/fuzz/i440fx_fuzz.c b/tests/qtest/fuzz/i440fx_fuzz.c index 155fe018f80..b5487996625 100644 --- a/tests/qtest/fuzz/i440fx_fuzz.c +++ b/tests/qtest/fuzz/i440fx_fuzz.c @@ -145,7 +145,7 @@ static void i440fx_fuzz_qos(QTestState *s, pciconfig_fuzz_qos(s, bus, Data, Size); } -static const char *i440fx_qtest_argv = TARGET_NAME " -machine accel=qtest" +static const char *i440fx_qtest_argv = TARGET_NAME " -accel qtest" " -m 0 -display none"; static GString *i440fx_argv(FuzzTarget *t) { diff --git a/tests/qtest/fuzz/qos_fuzz.c b/tests/qtest/fuzz/qos_fuzz.c index d3839bf9994..9267e63889d 100644 --- a/tests/qtest/fuzz/qos_fuzz.c +++ b/tests/qtest/fuzz/qos_fuzz.c @@ -84,7 +84,7 @@ static GString *qos_build_main_args(void) } /* Prepend the arguments that we need */ g_string_prepend(cmd_line, - TARGET_NAME " -display none -machine accel=qtest -m 64 "); + TARGET_NAME " -display none -accel qtest -m 64 "); return cmd_line; } diff --git a/scripts/oss-fuzz/output_reproducer.py b/scripts/oss-fuzz/output_reproducer.py index e8ef76b3413..840da3b5a5b 100755 --- a/scripts/oss-fuzz/output_reproducer.py +++ b/scripts/oss-fuzz/output_reproducer.py @@ -64,8 +64,6 @@ def c_reproducer(name, args, trace): # libqtest will add its own qtest args, so get rid of them args = args.replace("-accel qtest","") - args = args.replace(",accel=qtest","") - args = args.replace("-machine accel=qtest","") args = args.replace("-qtest stdio","") result.append("""QTestState *s = qtest_init("{}");""".format(args)) for l in trace.splitlines(): diff --git a/scripts/oss-fuzz/reorder_fuzzer_qtest_trace.py b/scripts/oss-fuzz/reorder_fuzzer_qtest_trace.py index b154a25508f..f3813944d3b 100755 --- a/scripts/oss-fuzz/reorder_fuzzer_qtest_trace.py +++ b/scripts/oss-fuzz/reorder_fuzzer_qtest_trace.py @@ -5,15 +5,15 @@ Use this to convert qtest log info from a generic fuzzer input into a qtest trace that you can feed into a standard qemu-system process. Example usage: -QEMU_FUZZ_ARGS="-machine q35,accel=qtest" QEMU_FUZZ_OBJECTS="*" \ +QEMU_FUZZ_ARGS="-machine q35 -accel qtest" QEMU_FUZZ_OBJECTS="*" \ ./i386-softmmu/qemu-fuzz-i386 --fuzz-target=generic-pci-fuzz # .. Finds some crash QTEST_LOG=1 FUZZ_SERIALIZE_QTEST=1 \ -QEMU_FUZZ_ARGS="-machine q35,accel=qtest" QEMU_FUZZ_OBJECTS="*" \ +QEMU_FUZZ_ARGS="-machine q35 -accel qtest" QEMU_FUZZ_OBJECTS="*" \ ./i386-softmmu/qemu-fuzz-i386 --fuzz-target=generic-pci-fuzz /path/to/crash 2> qtest_log_output scripts/oss-fuzz/reorder_fuzzer_qtest_trace.py qtest_log_output > qtest_trace -./i386-softmmu/qemu-fuzz-i386 -machine q35,accel=qtest \ +./i386-softmmu/qemu-fuzz-i386 -machine q35 -accel qtest \ -qtest stdio < qtest_trace ### Details ### -- 2.45.2 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:22:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:22:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847528.1262628 (Exim 4.92) (envelope-from ) id 1tIP6r-0004dV-LI; Tue, 03 Dec 2024 09:22:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847528.1262628; Tue, 03 Dec 2024 09:22:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIP6r-0004dO-IX; Tue, 03 Dec 2024 09:22:21 +0000 Received: by outflank-mailman (input) for mailman id 847528; Tue, 03 Dec 2024 09:22: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 1tIP6q-0003Ra-Tf for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:22:20 +0000 Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [2a00:1450:4864:20::12d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 17d24f65-b158-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 10:22:18 +0100 (CET) Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-53df6322ea7so9026150e87.0 for ; Tue, 03 Dec 2024 01:22:18 -0800 (PST) Received: from localhost.localdomain ([176.187.209.146]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5997d5625sm600599666b.63.2024.12.03.01.22.16 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 03 Dec 2024 01: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: 17d24f65-b158-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1733217738; x=1733822538; 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=7Z0cleQPrNy9NjZu27Yx3P0Ha1Flw6gQBqfbwRAF2Ak=; b=L+jBn8stAqUjaEbbEf4vB8yfYGzJJJVAcNXix5dEo5HGqlgHH8Jov0q896K/pozbiG l3pIYZwHkoMdDk2EIYGEgkTFArCH03SKBNsLzOXPePt9YhBU+HmezMOVF1s00Jq74aZ5 0oVPBd4EHda8EEO8DglNbbBPuLNGncVV1hqC2WwCjq7T6AHv+JMrQRkL4YGtP9ZSGBFB 5kIQo3fFN5hSc3690k46eQFbGqVxmBoyDn6ESDBTrkUfMLMM91GGJoptogzFOJKLsLyZ vzweAbPFa1ST4G52gMprYYX50l3vf6Plfufp2jJQRFHITDG0V/ld3gUZD+1axdV1ZJOy IcJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733217738; x=1733822538; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7Z0cleQPrNy9NjZu27Yx3P0Ha1Flw6gQBqfbwRAF2Ak=; b=qFWz0+6SSNTyuXrV99S0DTzez8pcUNC8uuYI4na/fLMOIGKM5q7TV8ox+C8N+35XHB jCf3I+viyMXdHtc1l2XjOP8cwhnuP1/mqnsihGIH/VZiSstkfOYH7JxW6q8CUr8RSuqY iQhax0jUdNy4ddLdzQ1OoXRxyG3Rh3LOwxM7elxuNr7rfyJ5abrwVaPF3nR68+ge2Z/M WOw+lK/DbI7yeic6sYmrkasqMfnUB3maLexBM+aREeZ1tYI8WPQy0RusYA46llvVZXu3 pxCLLsv8hiA4e+KElyRFJSp8yWf/NMMIwR0ea61ufHQKljofJIGtIbVg1n82WS6JGO7g pPJQ== X-Forwarded-Encrypted: i=1; AJvYcCVXrZbqTtK8KxFATaIoMCMHbgovLeNV8oTNDBXpMQ6X+evXHZxLcgVwjaa3s6HByjOQc5VFKLd6Uu8=@lists.xenproject.org X-Gm-Message-State: AOJu0YxPSTKyrjE5TvlCmi+kgRWfRnC+oL6kwVJ/8IDp7RvwtuZdgL06 RukmDuT/ehNqZcY46udklRBm2oE9Fdvy0UWy7nMBYcPtF1gyXio2SXn3uGXSkfc= X-Gm-Gg: ASbGncszaOeOErH+GiqGxySOuM3hQZqWnnY0mFSKBzsEtVyeLqQ6SzXqlq1Z37HgMcv zaF6nSCUra42sS26Ou+dd9w5v5cuYAnV5Y5z9+Zt+VF7lO17OYxth/zbjTJVNJiyi2g/ZTcpB3f kHg+iC+zAT4N3B3iwWcKCm7HzNk4vi8Et32n0PAuzh6xWaY+ek7eEgg6hhixO4hELjsNWN24AQV nNQSEQtha/X9WLCHO7/WLFhAdeggjtB9LMDDLCtkANo3jicSUafiVAujXkS6FeLIzsYT7pV X-Google-Smtp-Source: AGHT+IFKXdzCHgoYrbBgxEetwk2wWIxXomwv6Wa0ZHXf5sB1MUtHIOwB2t+dSu80nFR8vz7SoiVkxQ== X-Received: by 2002:a05:6512:124f:b0:53d:ed0a:8113 with SMTP id 2adb3069b0e04-53e129fef1amr1251543e87.14.1733217738255; Tue, 03 Dec 2024 01:22:18 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: Paolo Bonzini , =?UTF-8?q?Daniel=20P=20=2E=20Berrang=C3=A9?= , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org, Thomas Huth , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Subject: [PATCH 4/7] scripts/device-crash-test: Remove legacy '-machine foo,accel=bar' Date: Tue, 3 Dec 2024 10:21:50 +0100 Message-ID: <20241203092153.60590-5-philmd@linaro.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20241203092153.60590-1-philmd@linaro.org> References: <20241203092153.60590-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Since commit 6f6e1698a68 ("vl: configure accelerators from -accel options") we prefer the '-accel bar' command line option. Replace '-machine foo,accel=bar' -> '-machine foo -accel bar' in the device-crash-test script. Signed-off-by: Philippe Mathieu-Daudé --- scripts/device-crash-test | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/scripts/device-crash-test b/scripts/device-crash-test index da8b56edd99..2b139e29ba0 100755 --- a/scripts/device-crash-test +++ b/scripts/device-crash-test @@ -295,7 +295,10 @@ class QemuBinaryInfo(object): self._machine_info = {} dbg("devtype: %r", devtype) - args = ['-S', '-machine', 'none,accel=kvm:tcg'] + args = ['-S', + '-machine', 'none', + '-accel', 'kvm:tcg', + ] dbg("querying info for QEMU binary: %s", binary) vm = QEMUMachine(binary=binary, args=args) vm.launch() @@ -358,7 +361,9 @@ def checkOneCase(args, testcase): dbg("will test: %r", testcase) - args = ['-S', '-machine', '%s,accel=%s' % (machine, accel), + args = ['-S', + '-machine', machine, + '-accel', accel, '-device', qemuOptsEscape(device)] cmdline = ' '.join([binary] + args) dbg("will launch QEMU: %s", cmdline) -- 2.45.2 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:22:25 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:22:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847531.1262638 (Exim 4.92) (envelope-from ) id 1tIP6v-00050k-4O; Tue, 03 Dec 2024 09:22:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847531.1262638; Tue, 03 Dec 2024 09:22:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIP6u-00050Q-Uh; Tue, 03 Dec 2024 09:22:24 +0000 Received: by outflank-mailman (input) for mailman id 847531; Tue, 03 Dec 2024 09:22: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 1tIP6t-0003Be-A2 for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:22:23 +0000 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on20615.outbound.protection.outlook.com [2a01:111:f403:2418::615]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 195ce481-b158-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 10:22:22 +0100 (CET) Received: from PH7P221CA0012.NAMP221.PROD.OUTLOOK.COM (2603:10b6:510:32a::29) by SJ2PR12MB9138.namprd12.prod.outlook.com (2603:10b6:a03:565::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 09:22:18 +0000 Received: from SN1PEPF0002BA4F.namprd03.prod.outlook.com (2603:10b6:510:32a:cafe::a9) by PH7P221CA0012.outlook.office365.com (2603:10b6:510:32a::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.19 via Frontend Transport; Tue, 3 Dec 2024 09:22:18 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SN1PEPF0002BA4F.mail.protection.outlook.com (10.167.242.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 09:22:17 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) 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; Tue, 3 Dec 2024 03:22:17 -0600 Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Tue, 3 Dec 2024 03:22:16 -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: 195ce481-b158-11ef-a0d3-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=cBgZLFfpYaLzX/yXbxdPY/UI0b5NbIyRwBDgQFRinFEC72f0muCOUZ5nGSvb8bLyxGTxhp8plV9r+bDXAbbBqa08Al29zE0HSbp3Z2GCvboOX4wxr589DLoh+xnAk6eN0XP24R7dBzZ9VIW3I8piZCMfbrpaaPG3ATNQmBTsenMroIMigsUqsy2ZR3s/CBsS2J0WPQ8wizEZocEv1K9hhfwPlotnZ80FkyaDDi/Zj48XkzbBzETqPdEj17Tb9pI5yTKoJOaePz2QyzwA7cyrlT1wYu5gfOKU3c7r1uT0BIpkpddZNws1Mjy9LA/guBB82rVH2aEqQcHOt7kQitKLUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=d8Ct+reimjzemVFaJskhM5hwM6oYG5iOA7cDYiFPT+0=; b=anWwzURrizqnCABPcVVr1djt87hNBHtW+9GtFmKAF8lRS38Nf0S5U7BkLuaqx4pWjEMhHi9fTqtbKMMc0I1ORFK169y45Um/qrtCTJn9f806bg3FwstvE7wNemPlMyeypBSoRyR3Q4XJLHosDgk2ZaskayBzp3/viMwB/sD0TsVrwbaK3hJEuKN+jGs2fp5nZknRm5vv4OwrGMJgurYtAK+wcnT4Ul0SjXNkCX7fOMUMhffYsURtSPYa56qqW+0/nsXcDk1M9FDZTyLhrw9rvonIXO5q1REEefMW0eJpX+RLWtZMwVSXWundkPIPIqkU2cUt2XUhqsyfiO2rWH7a5w== 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=d8Ct+reimjzemVFaJskhM5hwM6oYG5iOA7cDYiFPT+0=; b=NAsHdnERL7twTQibDbV8x9PzWI7KDvOLBEGbj7VZ46H4OUiE3MVPkR9XECtHEcjEMU3YV3hYoQVy3fzVIREYotNyNmCY+q6vN9FoTT6EpfjQWW9NGBAsDHW7c4ftbi60d5/BuVYSspxvzEPaCqHxtioBvlkKf0Vmo/HmaAej/QQ= 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=SATLEXMB04.amd.com; pr=C From: Michal Orzel To: CC: Michal Orzel , Stefano Stabellini , Julien Grall , Bertrand Marquis Subject: [PATCH] bootfdt: Add missing trailing commas in BOOTINFO_{ACPI,SHMEM}_INIT Date: Tue, 3 Dec 2024 10:22:14 +0100 Message-ID: <20241203092214.276453-1-michal.orzel@amd.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PEPF0002BA4F:EE_|SJ2PR12MB9138:EE_ X-MS-Office365-Filtering-Correlation-Id: 1348204b-83ec-458e-4911-08dd137bfb83 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?5k49ED2teQTjiUBgqewajBjPsN/L1cieqHs0BUm06VZMLEwA7J0801ItolXn?= =?us-ascii?Q?sVJjrvBol6R0D6wBvT4GehdK2OGbl3GRY9mU9tw7LJIa9S4PwyPwECdXwUX7?= =?us-ascii?Q?qu6HA5z7KizMEGEIANJrvJoCsvwmfGffjFuwC3dClcMncqnybTjJaGxbBdrF?= =?us-ascii?Q?15mEpxxWHN4AE2WgaYfzi4NlSSGAxFbvr5LwJ5o3goX53VsmIdHRsPqZIub6?= =?us-ascii?Q?2e3IpQjfglDMRqUjKcZ889YKO65FITsrNY9TN8WqschdihGXUwgfZ4GBx/nA?= =?us-ascii?Q?kHC8FQEPi4kLt4WhoGcjbOZgOcKmOrTbrBBUNp8+RkCc979qLyTspmQ56hHM?= =?us-ascii?Q?np0tUUbvwcJOfnpaKN9iXZiEy+ZxzjPKufs2kU/DSwLz1dTnzgzoFpxh7PkP?= =?us-ascii?Q?r332sSsifCmH0CcLHHL3o2ClTIobntAVnw2ohj+gF4VR6V5ADpkoGpYVg0eJ?= =?us-ascii?Q?AVTM2LI/A3uDp8ZGiCXNzusGNEpdVAZtEl6hWrQlatvTAe36t0SM0WYd3D3l?= =?us-ascii?Q?93NbPDPoCVVhts0x2TYykM4IF8RM+P3Q2b5KzZ40gWozLzETcfTN8ytTpR4I?= =?us-ascii?Q?VPAIMc202icXzvmI6L+Zz92wXXsVhSfmSR9ZYNKEN1HrXyV3Gsyrgzj4YIyc?= =?us-ascii?Q?ARJHmtFQGMNf7bHiGIVkh3wsELSbtMqoZ8JUGEW06XHlJYznayl4Ud89gUP/?= =?us-ascii?Q?XgJN/4sCeqyMkANEhq33Fn6uZErmZ5zq1YQcZtKZ7c5EBmAz9r3i4x8SyHLg?= =?us-ascii?Q?Ysch2CAK4iaRu6btWyHiIpzMv0jRSKpsTgwu5ZI4HpfcliO6gQmJdcTHTPVi?= =?us-ascii?Q?OR3lLDuzs1121ioqg0veCByH/LGgla1vgBkEZt89WgucJ8a4yKUW1Vnk+F6w?= =?us-ascii?Q?sSGaVAhlx8ZKfYolXfWJCpB1LiP6y0eV+RscWw8YLMJs23kA61zKMw62cCvY?= =?us-ascii?Q?T5AZE8XWgHUjkjGElqQus6WH8njS2U5eI+wwq/2n1eTziAbLOceoiI4Xz+w0?= =?us-ascii?Q?MRk87zN4As5As/cEdEC6EaNWMNbs9UFRduBDd/TcqJBRYcwV7XkD+6xCt+Tw?= =?us-ascii?Q?WuZF2FtoQmk+YDmXoYaJNBPw++3rwR9ltYCdS+yhlM4fW6/8YAPGg8zf6wNm?= =?us-ascii?Q?WoM7DWRiH9Epb2TzCNA4tINrEIlNs5+qbkzGu5YMLeXojQdX2jcnI0TxInZO?= =?us-ascii?Q?eIha79yPa4T9RSBxPe0tHzDfU7zUOu5ry1uvsoeWNNGaEnlUkr+1xA2ed0Wo?= =?us-ascii?Q?VFZSrLUcu3YZWU29hnS+VwNTI5/EqDfWY/pEPsVAEiMmmhm+P6XYGu1yJii+?= =?us-ascii?Q?V7RQEyjsLGpyVJWQdb8ug6WZ0TrggKXIZNNSljnoaW6C69rHj5Be2wnhMJ8g?= =?us-ascii?Q?lvv6y1pHaxTcbBEsg0KmNJHM7BY4BXJsJnbxE2SOTLDErIPXsgpg69hhbvpz?= =?us-ascii?Q?xQygr/JFnYiaf/1E17pUT+duKV7zutO6?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 09:22:17.7287 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1348204b-83ec-458e-4911-08dd137bfb83 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SN1PEPF0002BA4F.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB9138 Commit a14593e3995a extended BOOTINFO_{ACPI,SHMEM}_INIT initializers list with a new 'type' member but forgot to add trailing commas (they were present before). This results in a build failure when building with CONFIG_ACPI=y and CONFIG_STATIC_SHM=y: ./include/xen/bootfdt.h:155:5: error: request for member 'shmem' in something not a structure or union 155 | .shmem.common.max_banks = NR_SHMEM_BANKS, \ | ^ ./include/xen/bootfdt.h:168:5: note: in expansion of macro 'BOOTINFO_SHMEM_INIT' 168 | BOOTINFO_SHMEM_INIT \ | ^~~~~~~~~~~~~~~~~~~ common/device-tree/bootinfo.c:22:39: note: in expansion of macro 'BOOTINFO_INIT' 22 | struct bootinfo __initdata bootinfo = BOOTINFO_INIT; Fixes: a14593e3995a ("xen/device-tree: Allow region overlapping with /memreserve/ ranges") Signed-off-by: Michal Orzel --- xen/include/xen/bootfdt.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h index cea40ee11706..343c48b73d2c 100644 --- a/xen/include/xen/bootfdt.h +++ b/xen/include/xen/bootfdt.h @@ -145,7 +145,7 @@ struct bootinfo { #ifdef CONFIG_ACPI #define BOOTINFO_ACPI_INIT \ .acpi.common.max_banks = NR_MEM_BANKS, \ - .acpi.common.type = MEMORY + .acpi.common.type = MEMORY, #else #define BOOTINFO_ACPI_INIT #endif @@ -153,7 +153,7 @@ struct bootinfo { #ifdef CONFIG_STATIC_SHM #define BOOTINFO_SHMEM_INIT \ .shmem.common.max_banks = NR_SHMEM_BANKS, \ - .shmem.common.type = STATIC_SHARED_MEMORY + .shmem.common.type = STATIC_SHARED_MEMORY, #else #define BOOTINFO_SHMEM_INIT #endif -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:22:26 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:22:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847534.1262647 (Exim 4.92) (envelope-from ) id 1tIP6w-0005JY-AB; Tue, 03 Dec 2024 09:22:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847534.1262647; Tue, 03 Dec 2024 09:22:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIP6w-0005Is-62; Tue, 03 Dec 2024 09:22:26 +0000 Received: by outflank-mailman (input) for mailman id 847534; Tue, 03 Dec 2024 09:22: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 1tIP6u-0003Be-Tf for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:22:24 +0000 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [2a00:1450:4864:20::636]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1aff5178-b158-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 10:22:24 +0100 (CET) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a9e8522445dso749760466b.1 for ; Tue, 03 Dec 2024 01:22:24 -0800 (PST) Received: from localhost.localdomain ([176.187.209.146]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5997d5646sm594152766b.62.2024.12.03.01.22.22 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 03 Dec 2024 01:22: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: 1aff5178-b158-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1733217744; x=1733822544; 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=PERYJEjYxWhdPat57HCXQqDRHV3hL1ijs4gpAo4T2SI=; b=OAPp2F7CGPnbKaxNH77iXorhXZARMk94mid2A7Vi+u3xwQfyqnUX7yKIyiKu+WbXSV 9d2V/hZEq/uudkefH8QFhysyuA1AXMSHPU3/bKySLtlOj5psf2Zl84RXSaSM0HeRvAW9 TWqqYWaCY4o6J4xAlhCozWy/nETadKT3yw2mIdSnLueBxtFbS8Es02PzK9M+UFybAeW0 9zwbqNTTwdvpUicXWCkz5DmxjxGa2dXVbXihkpFtEjFT5kT3czax/Cy/cG1vzfDJWmav ulU3yXFDcCvecNpf5+Ey+/WSuw4MKnzUgX15oXzbbptIdrmaGrdVBp0C5Msfxae7mOGC Y/WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733217744; x=1733822544; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PERYJEjYxWhdPat57HCXQqDRHV3hL1ijs4gpAo4T2SI=; b=vu1sD6pMYt/bQdL4t5C5mgThgT5LUJ9JbpViHNzEDDDrENtqhzRDW7Pdmb9FxcddrS Pi7ba6Knu4ah5ZWSIHX4h9ob9dqJG3/er6zdKCe5xxtfIt8NAIRg7wOqZIyWUx0revH7 L+AZy28u7ltTMTUuAICyGiHwgRX2hQXu1FShi+bdQMjiBtO7ItrHKTFSc3u4H+G8zvhF Pw8Pp3j5bicbHays7qiK8bZVL/x9n/aZZ0NX7OD0Yty4wipb3MgmyUmfUTIU01I7Jset HgnscYvJoSPJbhqPgQcQmw3jWz183BpRTb2svl0OxiEwG4yh0K+K7eNCG5Jly5zUDm30 OHvg== X-Forwarded-Encrypted: i=1; AJvYcCUuP4SJznzeoHDM7t/PLY88junkOe4la8e4bSES/rZzXOO2PDnP9ylUM3FwllRdtOg//W5f41VUU5k=@lists.xenproject.org X-Gm-Message-State: AOJu0YzYn2fewyGqjHirBg52hbZTcrDXoP3ACsQWrLsFXrmMnq5oLKki ZZzFKwSdHaKl1ir+8kwO1cRw478r2rg3FDkaouZMzkLRU2X+UZm5IDs3qQQCxCI= X-Gm-Gg: ASbGncufnFMG9WW50iB4UNKuY0i/wAwJJPSS0g3kIwaQl7PQMRbS7xNlu2Im0/AVcpc S2W3ve9fnVWdgdzjsaGR/JB/IRjhlf0rkRu4laqXPU140f5LCJb04LarFqT2LMEBeRxPXfP9dmh u6lveScG1OStmO/Ws/1clkIbm3aAJ34CPxaV+XWinWCV5X61hocK00uNS/oR6rp/TsCa/+YNflz 5d8KA78UsStiDpMyvwkjO/wnINIuCqp9HKfgj2YQAvzWdPfNUcc+duyltMnod8YuhRS7zMa X-Google-Smtp-Source: AGHT+IG/10KRcSJmHbz27onCyU5ZPCzMEQmMKXxzXO8/y/6O5dpHc4TRW51Ux3lkFGHoBQyD1B/v6w== X-Received: by 2002:a17:907:7623:b0:a9e:26ad:d0a with SMTP id a640c23a62f3a-aa5f7f18ec8mr118492466b.58.1733217743897; Tue, 03 Dec 2024 01:22:23 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: Paolo Bonzini , =?UTF-8?q?Daniel=20P=20=2E=20Berrang=C3=A9?= , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org, Thomas Huth , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Subject: [PATCH 5/7] accel/tcg: Remove mentions of legacy '-machine foo,accel=bar' Date: Tue, 3 Dec 2024 10:21:51 +0100 Message-ID: <20241203092153.60590-6-philmd@linaro.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20241203092153.60590-1-philmd@linaro.org> References: <20241203092153.60590-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Since commit 6f6e1698a68 ("vl: configure accelerators from -accel options") we prefer the '-accel bar' command line option. Update the documentation when TCG is referred to. Signed-off-by: Philippe Mathieu-Daudé --- docs/about/removed-features.rst | 2 +- linux-user/s390x/target_proc.h | 2 +- accel/tcg/monitor.c | 4 ++-- system/vl.c | 2 +- tests/qtest/qmp-cmd-test.c | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst index ee6455aeeeb..d96dc5e80bc 100644 --- a/docs/about/removed-features.rst +++ b/docs/about/removed-features.rst @@ -216,7 +216,7 @@ The ``enforce-config-section`` property was replaced by the ``-no-kvm`` (removed in 5.2) '''''''''''''''''''''''''''' -The ``-no-kvm`` argument was a synonym for setting ``-machine accel=tcg``. +The ``-no-kvm`` argument was a synonym for setting ``-accel tcg``. ``-realtime`` (removed in 6.0) '''''''''''''''''''''''''''''' diff --git a/linux-user/s390x/target_proc.h b/linux-user/s390x/target_proc.h index a4a4821ea5c..f443d8f8080 100644 --- a/linux-user/s390x/target_proc.h +++ b/linux-user/s390x/target_proc.h @@ -7,7 +7,7 @@ #define S390X_TARGET_PROC_H /* - * Emulate what a Linux kernel running in qemu-system-s390x -M accel=tcg would + * Emulate what a Linux kernel running in 'qemu-system-s390x -accel tcg' would * show in /proc/cpuinfo. * * Skip the following in order to match the missing support in op_ecag(): diff --git a/accel/tcg/monitor.c b/accel/tcg/monitor.c index 093efe97144..0430b6e1514 100644 --- a/accel/tcg/monitor.c +++ b/accel/tcg/monitor.c @@ -204,7 +204,7 @@ HumanReadableText *qmp_x_query_jit(Error **errp) g_autoptr(GString) buf = g_string_new(""); if (!tcg_enabled()) { - error_setg(errp, "JIT information is only available with accel=tcg"); + error_setg(errp, "JIT information is only available with TCG"); return NULL; } @@ -226,7 +226,7 @@ HumanReadableText *qmp_x_query_opcount(Error **errp) if (!tcg_enabled()) { error_setg(errp, - "Opcode count information is only available with accel=tcg"); + "Opcode count information is only available with TCG"); return NULL; } diff --git a/system/vl.c b/system/vl.c index 54998fdbc7e..c056fcb740c 100644 --- a/system/vl.c +++ b/system/vl.c @@ -2385,7 +2385,7 @@ static void configure_accelerators(const char *progname) for (tmp = accel_list; *tmp; tmp++) { /* * Filter invalid accelerators here, to prevent obscenities - * such as "-machine accel=tcg,,thread=single". + * such as "-accel tcg,,thread=single". */ if (accel_find(*tmp)) { qemu_opts_parse_noisily(qemu_find_opts("accel"), *tmp, true); diff --git a/tests/qtest/qmp-cmd-test.c b/tests/qtest/qmp-cmd-test.c index 2c15f609584..83f4a2b451b 100644 --- a/tests/qtest/qmp-cmd-test.c +++ b/tests/qtest/qmp-cmd-test.c @@ -49,7 +49,7 @@ static int query_error_class(const char *cmd) { "query-vm-generation-id", ERROR_CLASS_GENERIC_ERROR }, /* Only valid with a USB bus added */ { "x-query-usb", ERROR_CLASS_GENERIC_ERROR }, - /* Only valid with accel=tcg */ + /* Only valid with TCG */ { "x-query-jit", ERROR_CLASS_GENERIC_ERROR }, { "x-query-opcount", ERROR_CLASS_GENERIC_ERROR }, { "xen-event-list", ERROR_CLASS_GENERIC_ERROR }, -- 2.45.2 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:22:32 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:22:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847540.1262658 (Exim 4.92) (envelope-from ) id 1tIP72-0005sI-Jd; Tue, 03 Dec 2024 09:22:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847540.1262658; Tue, 03 Dec 2024 09:22:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIP72-0005s1-GA; Tue, 03 Dec 2024 09:22:32 +0000 Received: by outflank-mailman (input) for mailman id 847540; Tue, 03 Dec 2024 09:22: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 1tIP70-0003Be-Sp for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:22:30 +0000 Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [2a00:1450:4864:20::12c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1e7d1ce8-b158-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 10:22:30 +0100 (CET) Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-53dd2fdcebcso6021936e87.0 for ; Tue, 03 Dec 2024 01:22:30 -0800 (PST) Received: from localhost.localdomain ([176.187.209.146]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5998e6a1asm591445466b.98.2024.12.03.01.22.28 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 03 Dec 2024 01:22: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: 1e7d1ce8-b158-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1733217750; x=1733822550; 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=PKNytw/ebCVRIpsQ9YAUBfkaMh3JJAq/QjBPjtgiz7g=; b=tiZQhQEIPQIT8irrTmv4wfI8mWIq+3djWnxplVzAOg6zpBud4yyMRPlW8VTWdEaQaE xCluZ4uFXLW4psMqeUZZW66Xe0y/J6SGVULHoKxELhKH05WuQrdsnDhOxImuT4EhbU6P G3cOJLE6f9L7WpoR19Ts4urCvPSjDRTFtZAl9JXdskkwoejxaU5q1ay5Tq3bIploADoI BdouQylsettHVvRk0i4IfeuqYXY4MXKDUV6Zrv2L33JfydP5/M0Y+oWBsSFzgmpBxRZX 60IquTZ4dxr4AL3s04AWovDSflkhoCZbvIyxTZ0zMnMBvOdqGw4zCja9ft6S3hfKZdHf cBUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733217750; x=1733822550; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PKNytw/ebCVRIpsQ9YAUBfkaMh3JJAq/QjBPjtgiz7g=; b=G/CKNF6V6+LQ464yS3FeAv/aRCxwt5OvrpaNFyxCKb/0wUg3jPbfVE1SF/8/Rbrtq9 S374FUriDeSruhe/0YOLASn0sM/DDXlcN3hd56TtQVScRnG44fUCacM8kUZiO0sOYACh N2L6/dqFeHrsSWafGt+gsMNW8two0wLjJ2tP7EWF7+lVOxs45fjTfrVYHrAdmGZL3zCb 4ohvHHDq1cVVzdZSrKRHWA1KczDalfSXd6mjtoKiVshdVGJfBG3ne5wiIzGq2R+cJtsh 28fDbarp1oYa/0qdmZK/bGDAWoljNIVgfPqva7qrUcRssusy84XX+iyb0QnHwBRqUFWU E85g== X-Forwarded-Encrypted: i=1; AJvYcCWOCclv09JOl6jLAFaZLCm8xC5Ot2mXqn+pf8Rlqpuw4zu4XFw20Ah/O9pOJHmHO48pLY2plScs0rk=@lists.xenproject.org X-Gm-Message-State: AOJu0YwfZPnS+i9dwmm06/hrtu7CAu7fxhZtb9solbK36+vNw2ZFGICx VLHEPYq4RF55KdhjJy+Vd25K0FAQiAk6K5NJPlWBn7VXaSVqwGoNpzMoDBeAEsTHi+WTPalzeR5 WrJo= X-Gm-Gg: ASbGncujykWLhJ7KdS1S6N+QVhnrNJDXAuMo70rFV/v9z1d/i+DflQEjPyVnhwxeVB6 HJzdGLY1N9ieZr9Y7ItxHseoTDmXW7vf3rLlYpYEd9KKHKtTvbD5cliph8CIgIeqAitoVILhQkS RnG8VW8o1dGHVGdEI5L+bc1fsxmQgx1Dx9wG7d2tQMiLJupn5rePgXQ+O+iWCiIdPphFUhJREBJ GMrZ7GN5W9w4wHMRdSYVqmIb//sxGsvmASFhfN46R4Nu9aXqH8Gyb8bUE/qACITg2c/MU6k X-Google-Smtp-Source: AGHT+IFcpj6QzfB53oly3i7BN3QSlvt4/aDJxnH7tiR3CcVRsSurQ5wh0JwIqkBOrHoycPMN8RfEuA== X-Received: by 2002:a05:6512:3096:b0:53d:a273:7da6 with SMTP id 2adb3069b0e04-53e12a290b4mr863155e87.57.1733217749670; Tue, 03 Dec 2024 01:22:29 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: Paolo Bonzini , =?UTF-8?q?Daniel=20P=20=2E=20Berrang=C3=A9?= , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org, Thomas Huth , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Subject: [PATCH 6/7] accel/kvm: Remove mentions of legacy '-machine foo,accel=bar' Date: Tue, 3 Dec 2024 10:21:52 +0100 Message-ID: <20241203092153.60590-7-philmd@linaro.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20241203092153.60590-1-philmd@linaro.org> References: <20241203092153.60590-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Since commit 6f6e1698a68 ("vl: configure accelerators from -accel options") we prefer the '-accel bar' command line option. Update the documentation when KVM is referred to. Signed-off-by: Philippe Mathieu-Daudé --- docs/bypass-iommu.txt | 3 ++- docs/nvdimm.txt | 2 +- docs/specs/tpm.rst | 2 +- docs/system/arm/cpu-features.rst | 2 +- docs/system/cpu-hotplug.rst | 2 +- docs/system/ppc/powernv.rst | 2 +- docs/system/ppc/pseries.rst | 4 ++-- scripts/device-crash-test | 2 +- 8 files changed, 10 insertions(+), 9 deletions(-) diff --git a/docs/bypass-iommu.txt b/docs/bypass-iommu.txt index e6677bddd32..2ef0e0f6a65 100644 --- a/docs/bypass-iommu.txt +++ b/docs/bypass-iommu.txt @@ -51,7 +51,8 @@ And we got: x86 architecture: qemu-system-x86_64 \ - -machine q35,accel=kvm,default_bus_bypass_iommu=true \ + -accel kvm \ + -machine q35,default_bus_bypass_iommu=true \ -device pxb-pcie,bus_nr=0x10,id=pci.10,bus=pcie.0,addr=0x3 \ -device pxb-pcie,bus_nr=0x20,id=pci.20,bus=pcie.0,addr=0x4,bypass_iommu=true \ -device intel-iommu \ diff --git a/docs/nvdimm.txt b/docs/nvdimm.txt index fd7773dc5ab..d589c3a9b77 100644 --- a/docs/nvdimm.txt +++ b/docs/nvdimm.txt @@ -228,7 +228,7 @@ which allows the platform to communicate what features it supports related to NVDIMM data persistence. Users can provide a persistence value to a guest via the optional "nvdimm-persistence" machine command line option: - -machine pc,accel=kvm,nvdimm,nvdimm-persistence=cpu + -machine pc,nvdimm,nvdimm-persistence=cpu There are currently two valid values for this option: diff --git a/docs/specs/tpm.rst b/docs/specs/tpm.rst index 1ad36ad7099..c50bb1cec01 100644 --- a/docs/specs/tpm.rst +++ b/docs/specs/tpm.rst @@ -329,7 +329,7 @@ In case a pSeries machine is emulated, use the following command line: .. code-block:: console - qemu-system-ppc64 -display sdl -machine pseries,accel=kvm \ + qemu-system-ppc64 -display sdl -accel kvm -machine pseries \ -m 1024 -bios slof.bin -boot menu=on \ -nodefaults -device VGA -device pci-ohci -device usb-kbd \ -chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock \ diff --git a/docs/system/arm/cpu-features.rst b/docs/system/arm/cpu-features.rst index a5fb929243c..4aed91a987d 100644 --- a/docs/system/arm/cpu-features.rst +++ b/docs/system/arm/cpu-features.rst @@ -329,7 +329,7 @@ SVE CPU Property Examples 3) When KVM is enabled, implicitly enable all host CPU supported vector lengths with the ``host`` CPU type:: - $ qemu-system-aarch64 -M virt,accel=kvm -cpu host + $ qemu-system-aarch64 -M virt -accel kvm -cpu host 4) Only enable the 128-bit vector length:: diff --git a/docs/system/cpu-hotplug.rst b/docs/system/cpu-hotplug.rst index cc50937c36c..64314ccfd6f 100644 --- a/docs/system/cpu-hotplug.rst +++ b/docs/system/cpu-hotplug.rst @@ -12,7 +12,7 @@ vCPU hotplug allow vCPU hotplug):: $ qemu-system-x86_64 -display none -no-user-config -m 2048 \ - -nodefaults -monitor stdio -machine pc,accel=kvm,usb=off \ + -nodefaults -monitor stdio -accel kvm -machine pc,usb=off \ -smp 1,maxcpus=2 -cpu IvyBridge-IBRS \ -qmp unix:/tmp/qmp-sock,server=on,wait=off diff --git a/docs/system/ppc/powernv.rst b/docs/system/ppc/powernv.rst index de7a807ac76..689f9c81a02 100644 --- a/docs/system/ppc/powernv.rst +++ b/docs/system/ppc/powernv.rst @@ -63,7 +63,7 @@ powernv. kvm-pr in theory could be used as a valid accel option but this isn't supported by kvm-pr at this moment. To spare users from dealing with not so informative errors when attempting -to use accel=kvm, the powernv machine will throw an error informing that +to use '-accel kvm', the powernv machine will throw an error informing that KVM is not supported. This can be revisited in the future if kvm-pr (or any other KVM alternative) is usable as KVM accel for this machine. diff --git a/docs/system/ppc/pseries.rst b/docs/system/ppc/pseries.rst index bbc51aa7fcd..3b18d2ee1ef 100644 --- a/docs/system/ppc/pseries.rst +++ b/docs/system/ppc/pseries.rst @@ -164,9 +164,9 @@ Currently, there are two implementations of KVM on Power, ``kvm_hv.ko`` and If a host supports both KVM modes, and both KVM kernel modules are loaded, it is possible to switch between the two modes with the ``kvm-type`` parameter: -* Use ``qemu-system-ppc64 -M pseries,accel=kvm,kvm-type=PR`` to use the +* Use ``qemu-system-ppc64 -accel kvm -M pseries,kvm-type=PR`` to use the ``kvm_pr.ko`` kernel module. -* Use ``qemu-system-ppc64 -M pseries,accel=kvm,kvm-type=HV`` to use ``kvm_hv.ko`` +* Use ``qemu-system-ppc64 -accel kvm -M pseries,kvm-type=HV`` to use ``kvm_hv.ko`` instead. KVM-PR diff --git a/scripts/device-crash-test b/scripts/device-crash-test index 2b139e29ba0..2c6fd7c6f6e 100755 --- a/scripts/device-crash-test +++ b/scripts/device-crash-test @@ -147,7 +147,7 @@ ERROR_RULE_LIST = [ # "spapr-cpu-core needs a pseries machine" {'machine':'(?!pseries).*', 'device':'.*-spapr-cpu-core', 'expected':True}, - # KVM-specific devices shouldn't be tried without accel=kvm: + # KVM-specific devices shouldn't be tried without '-accel kvm': {'accel':'(?!kvm).*', 'device':'kvmclock', 'expected':True}, # xen-specific machines and devices: -- 2.45.2 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:24:19 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:24:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847553.1262668 (Exim 4.92) (envelope-from ) id 1tIP8i-0007SG-Uz; Tue, 03 Dec 2024 09:24:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847553.1262668; Tue, 03 Dec 2024 09:24: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 1tIP8i-0007S9-RN; Tue, 03 Dec 2024 09:24:16 +0000 Received: by outflank-mailman (input) for mailman id 847553; Tue, 03 Dec 2024 09:24: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 1tIP8i-0007S3-1Q for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:24:16 +0000 Received: from EUR03-DBA-obe.outbound.protection.outlook.com (mail-dbaeur03on20605.outbound.protection.outlook.com [2a01:111:f403:260d::605]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5c35a63a-b158-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 10:24:13 +0100 (CET) Received: from DB7PR05CA0026.eurprd05.prod.outlook.com (2603:10a6:10:36::39) by PAWPR08MB10210.eurprd08.prod.outlook.com (2603:10a6:102:367::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.19; Tue, 3 Dec 2024 09:24:09 +0000 Received: from DB1PEPF00039234.eurprd03.prod.outlook.com (2603:10a6:10:36:cafe::5a) by DB7PR05CA0026.outlook.office365.com (2603:10a6:10:36::39) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.18 via Frontend Transport; Tue, 3 Dec 2024 09:24:09 +0000 Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB1PEPF00039234.mail.protection.outlook.com (10.167.8.107) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 09:24:09 +0000 Received: ("Tessian outbound 3b1f0cd68b0e:v514"); Tue, 03 Dec 2024 09:24:09 +0000 Received: from Lddfb3a6e10d3.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id F16E8829-C206-4FB3-9E2C-4D0A02D78D05.1; Tue, 03 Dec 2024 09:24:03 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id Lddfb3a6e10d3.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 03 Dec 2024 09:24:02 +0000 Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24) by AS2PR08MB9414.eurprd08.prod.outlook.com (2603:10a6:20b:596::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 09:24:01 +0000 Received: from DB9PR08MB6588.eurprd08.prod.outlook.com ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8207.014; Tue, 3 Dec 2024 09:24: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: 5c35a63a-b158-11ef-a0d3-8be0dac302b0 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=SBbWMrn9u2hONENxX2RoxuJ4CkfAw/1WAeAzQ/Mez1+ppKhO+ooDPMn3np58KB0QUYvbuO5YHzwovjD2U8Egz/FqEde6Uj57z2ET5EZEa6vm7UpTsADid2d8dRx2aY7HobpXYw0vfNCsNz4RyYv57yLJRZ4KpxUkPhUP/+6J2KZ2ZH06qmje0ZLjMuheu10lasEMe9T79Dtn5qeMLr3wOO3RbIcnTTsZhgTQ2NtUuw+k8Uzz8Ui1qEfiV2n8MNX2JEh4MRZE5BcpM6u4t3x+OcGa/z16trmVrQcL4oEnVD+wP8+dSp1ET/xm/MpQ/4M8WLc2SgvFQa18Ggx+Q4iINQ== 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=f6XyTv27PWT0FkuwHgF5iVQqnoDihYutOn6vnsjZDgs=; b=Ru12QLpbzqLYxo/3rGYtmGasq8oYdbgdel07CMUxCsCE0VWrQQxrSsMMk/jyXpFm/2Pz9m2psSyEQvawVdSwjT3hAou/xDcvSZg9Wcz+rx0mLHGD+7jfcuZlOS8z237a7WWaXoho2grXur0+tJAOy92gx4ZdVwYMljfj6DXVnjNGdvlBT96PH2AoXuRFT2lI4OAshI/oQ7GqeJLH1sZjAi2ZKjKZlcCs6axgacsw1BmhPbCu7BKfbxjpRNMQjkuz41hubqkkyF8qzFbNcGwhxwx0ETeINHLAQDuzdqYt564jrJ4bxXQOlky646cilKrfMQW+wUu4Dr3BTUqyTUlhNA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=f6XyTv27PWT0FkuwHgF5iVQqnoDihYutOn6vnsjZDgs=; b=ZEDjlVj0qDRGakd1wxTz8YbXV2qjUVxqaFAAttaGZRhBCX6vtSbHY1D5EeW+Jo6asi/a96cBBxqboMeUNkU7jC4g6dimFA1HHGnnuUTR6xrwBmu20h11XDivXvNTntAja1U19cNVS73dY3kC3aEXc4AU8CCBohRZhaTOCcLcPJU= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) 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 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C X-CheckRecipientChecked: true X-CR-MTA-CID: b117ce788629a830 X-TessianGatewayMetadata: q2BVB+UWw1N4lW06PgTFI3LH38QKSwyHp+I7kurV778AyniaKsIFFYs11L7o30uGKZqfbpIWMkTh/hTNy1gkQxWJTsUmlNrcWrt58TZrdf9b7nz0peLPk81Wvfkkr8NgEnmsOQmAai7KsxKnpKn8SGh+UdP5NcDYWnI2NrNe3PY= X-CR-MTA-TID: 64aa7808 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xt9wVcJVPY9+xo4588RFbO9CnfyLfGb2ZKzzdd/9H19j5eMWULFSHGO6ReIUP9W0QKJZpuwl932jwfyK4fkg2THxUkOVbsodkBV+6+ITEltQOeylcC9hsnOX54ODo30YYfg5IKD3uDR9+gZ+xCw45FieYM7eyVcG8UZ2nG05eCfQkViYEt9PvmxQjFP7S4oqJIqCD9UfBz1BS4QeBmcr14SqkgXGdkz5malSkX2u3jy3dlF7sqqbiielGrw2Xx//CLX/iUgCAxS1ZyyKiPKosUPWNEtmRYktf0+V5Bztpiy29Sf6wwj1ZxwJ4vc6x469Xg5aU8lAUYLQqZZ9/mmF/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=f6XyTv27PWT0FkuwHgF5iVQqnoDihYutOn6vnsjZDgs=; b=Q284QzLH6Bcqd4ZL17UuAH2q6cosF4BnGakkfnZGloCmYIAK2138ueOFSL9klf6KaZNpxjgeOUhkdrbQy0eFEJwwKhlzW9yI2KRk20vfYDv5Gd+Nf89NKKMjStB9CnLn1V3y8ZI3aHdlJoLPXMhFwHMpuL7z90QNPmOMa1/fuQaRCFtlLb9HD/JxNTSMws+WAqeCR+rROBVNmQQMPxUwRxVjl9vBGBPBxXl3sx5xn474tD2sZ3cM4ZR1CAlK6kRnJRH8g1DE5TXX57THlDubtU+xsBegAwr98SjzAsvB7DVj4u7U2AP/DTw0VzT/L/4jm2ce6lk1B8E39ulk7v/MOA== 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=f6XyTv27PWT0FkuwHgF5iVQqnoDihYutOn6vnsjZDgs=; b=ZEDjlVj0qDRGakd1wxTz8YbXV2qjUVxqaFAAttaGZRhBCX6vtSbHY1D5EeW+Jo6asi/a96cBBxqboMeUNkU7jC4g6dimFA1HHGnnuUTR6xrwBmu20h11XDivXvNTntAja1U19cNVS73dY3kC3aEXc4AU8CCBohRZhaTOCcLcPJU= From: Bertrand Marquis To: Michal Orzel CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall Subject: Re: [PATCH] bootfdt: Add missing trailing commas in BOOTINFO_{ACPI,SHMEM}_INIT Thread-Topic: [PATCH] bootfdt: Add missing trailing commas in BOOTINFO_{ACPI,SHMEM}_INIT Thread-Index: AQHbRWTfGBof/YMyMU6ZlfcGMKQsgLLUP1YA Date: Tue, 3 Dec 2024 09:24:00 +0000 Message-ID: <0CEE35C9-48AA-4A88-A8EE-4FF29220D07F@arm.com> References: <20241203092214.276453-1-michal.orzel@amd.com> In-Reply-To: <20241203092214.276453-1-michal.orzel@amd.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3826.200.121) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DB9PR08MB6588:EE_|AS2PR08MB9414:EE_|DB1PEPF00039234:EE_|PAWPR08MB10210:EE_ X-MS-Office365-Filtering-Correlation-Id: 37576c98-604c-481f-f6ba-08dd137c3de4 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|1800799024|366016|38070700018; X-Microsoft-Antispam-Message-Info-Original: =?us-ascii?Q?5Yr265at3Gaq+yx0vrVc4m3NLe2J+KuC63vDFcrf60/UDEsxCL/AhBND/j8a?= =?us-ascii?Q?LjK2oqJeVBg842/IU4utuWfu3AHfd6/aoCqw/QhSFB1ASJNg+eXKmIXtW1Wx?= =?us-ascii?Q?ihbZIB64wvQ3v+kXI+flYEKcGD1XjBHLfdwZvw3Zsoyqi7oN0bd8+OWHsVab?= =?us-ascii?Q?IOMuzqosnOpEmsPaisfpZ3VC8yfDAbn2w8CIsm/cWaWMWu+ZVW4a+OY3mRgx?= =?us-ascii?Q?h/rpkg2QMwZyGWiu/i+QZCfY5FTTaPQAujG0sjsxqTXwosTY2UfvGUuv9i1d?= =?us-ascii?Q?D8YsRJVLyesHTY5CLZBQqY33vw+gZGw2GM9EpPCw0TpQgGhjAVjWkPOYCXom?= =?us-ascii?Q?hOaTU43ffNuHwtlSCIVosqdPpjDJ1lxFIhGUW01lVqCMnjK8MmyXTVmGgemH?= =?us-ascii?Q?P9vn6SHkYXmgO3EKmlpm6JaWlWIU6+ImyA3zOa6OI9kOWkRxcbap/5jwUQ+0?= =?us-ascii?Q?Rq6O0EFC9ESVG3X9Rhigv1Z1JIc5wStDGjcnbtqZ3Qj7oZh7AfYN28zL65oh?= =?us-ascii?Q?9Wcr+3H2rNI5hpyswJrVS0jkWoykzNTafnx3QcPClBAae9PhFGZpfZh42bDs?= =?us-ascii?Q?9ejfiqy0mfyC1gszhozU9OYXMI6l3JU1dejxr32TpcCV1X+MxtP3eYUYwyT5?= =?us-ascii?Q?/CDKs5jxqgztQn6cdES5+CEPVvUUNXt+hPutiRUmSoqm2BDm6zac4Rk9FMwz?= =?us-ascii?Q?Ty/eW92koRVU/9eV4ZToRsj4VnBTnZnI/PFz49lEWj7KR+pd+6OQyhbHT4Zb?= =?us-ascii?Q?B6soW1nOUtP28O5XCA9aWarcH9+yYhuKX+4BLQlxojDUFC/f3NTZjJNIGSSe?= =?us-ascii?Q?ZUAlkBu9fpb+L7O+K9RH17lzmDAAYVzKFotO84PDg44H//peEDNqAzNG9tbc?= =?us-ascii?Q?kal2KhZqN6re432YTm/ebT68urnUTfa8s5N+rlieb8Wk6bW+Fz9OZ+2wwzkp?= =?us-ascii?Q?TCmvW0aU5Uiv1Lbd9duycwPCHF7kPkY3S5dVrrERXyDJPBOSB1X589bzjzX7?= =?us-ascii?Q?JXrqgLP7EECkp/u6YXYFu8APUKkMAEHXaAoJbfU0xyGPyNlWV9JYoSPk6Wkv?= =?us-ascii?Q?S9gpTSgxaTpPyhAEHKGR2o0C2cIkcYhY97FuVjr90tpzQjrPmeuaAdQ/hgFx?= =?us-ascii?Q?ySNO+KoOyPvyuWzRtpkGiWCPlyOc+293vTyyeLCLcN49FOvsBi4jlGbM986b?= =?us-ascii?Q?s7cYwrZlM0Bl6gjlm51PoEKLrBkMCkVcQ6bwBAvDVy0peX8mgo3IysUR0OIm?= =?us-ascii?Q?poVuGy7UXEDQX949T3s/ygU7LCE5Dy+UkF1Idg+5uXooR1L/u1h7OZPj1YvD?= =?us-ascii?Q?YQIWyQV/WzI2VSz4zHdlelGZuOPqKuQwwFyndpP12YTTFMtUbZMWw45a7nXP?= =?us-ascii?Q?zKqug48sEgKWTg7eFmWSX0nXUW9fZzCUVoKCdOLeln5cDf1rJg=3D=3D?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB9414 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-SkipListedInternetSender: ip=[2603:10a6:10:25a::24];domain=DB9PR08MB6588.eurprd08.prod.outlook.com X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB1PEPF00039234.eurprd03.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: b8b677af-fe60-434f-c498-08dd137c3903 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|35042699022|36860700013|14060799003|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?Yn/5hNb6fT4lZuaF8bb0Cf3lQv2neXliFkE2nbHZroWhNEEUHhri7sp0BZhM?= =?us-ascii?Q?FQU16QYoNG6XL8lebWmofextMeYITAuHi8ojrVMzUN+kXNYa9mioGGFvg/Ot?= =?us-ascii?Q?ba8Pgf0nKM2hqJFLjMsKLlBSsUWiS2I0ei2GTbaHpKEOOTBPBeq+FJNSTaDl?= =?us-ascii?Q?4rKmqncAIf4M5rf4AKY6fwGSUTgg1uBBFiuzVJfJqIMOzagavc1slMWVodxR?= =?us-ascii?Q?adShysfelCOKtTTCl9DFZNNp8Wh6QK+7qIieaZStg9+reGVfTjCUz0gqqpZk?= =?us-ascii?Q?Vs82H1pf2foGSprx9RjiCoCAk8NbCY8bi0OP6/NZa/drGaR8kxZxg2LXBTAu?= =?us-ascii?Q?vCLWz+V+InNOzCwyx3sA555BNWFPqXx67eTDrGf7iQZeATHJEz/TyCVNtzpc?= =?us-ascii?Q?HTG7f98cwhFKatDhJ4V2ZsRTLzyN4/K5EzAcaPWI1QSic/Xoh5lvDylDM1Gj?= =?us-ascii?Q?dX0KuRKvAl4IHCE4GALfZAWFBXsPdAEuE3KHyCOtVSQTx9UQ7MrO54whN1ah?= =?us-ascii?Q?lpyMXKcjAcAh5EZQpd2T2ixiC5xNpVyPyCzVjYPIg62wtnXIz+lPVav/IcUh?= =?us-ascii?Q?HH0m88H81YDX4DDYED2Z6VwdpkB3VNjEuKV76N8VI28sGUOaTJSDU44Rmbin?= =?us-ascii?Q?CZ9ds8fKhUxc1altCCM1uuv/7OC2oe6g1AJE40Y64b9skggQAlsB5v4KdXbl?= =?us-ascii?Q?4sJLwAB6bYJOO6oXBcxLwI21RAhMb7Fa0CWxA0Qfof4034itncYLU+R1FR01?= =?us-ascii?Q?T4N/9jyt9dmqvoOvyCQacbNIdoE+PiBshN+JPTyO60xoY60AmhKLGRhLLEjI?= =?us-ascii?Q?3e5ZI6CYf9YRnNI5AQ5kYEwyosgxnCiGnsmxz6HTNpjOsw8YuLCGzqnnpymK?= =?us-ascii?Q?Ma7HtMqoK7CAvkfya813dtJRtFZeCEIznrOEzmQ7EWCSqyPY09r8gYzMZpO1?= =?us-ascii?Q?Jpvtf9qR4h0hOztZ20rDD0DxfAkn6OSgivNAn8FCt8UjJafmptGG0m2nOTXK?= =?us-ascii?Q?I2ySTMkiSyQIZzDJW5fxkRgbM35wdf5grGISy0jjWWFL+t+8ZJUAhIozmoXf?= =?us-ascii?Q?r8EseFqPpKcuzMUYa2D2x9pqVitrw/QVStr2XbRnhqVgfIfnBR/FhMYuft3A?= =?us-ascii?Q?8CzK0M8uZ9ky9f22peTp6QMKlEQNeOrRf2wOo46uTx+wLRwS9JhecqM0HSaF?= =?us-ascii?Q?LSYhaKrqnprwsxHAYPBW50UowTmtX6GUOeGFEkkdgQntWqSY+RSOWa2Uv+AO?= =?us-ascii?Q?ya+bZRAQVh4voqsclVvb/DRRsY6y5HXVYYiqB0jU+cPYHEnzzBSr4PhEkj5r?= =?us-ascii?Q?kfWhCkNmvvH3o5RcxGJWSzpsmLu40ZOxMEcbAS5iLliex44eoecHUNyPDhb6?= =?us-ascii?Q?Sd5vNZ3V2QXSGqkHUxnNBcDWtXbpGLzY0cMHi56sJIWmPFe8n2c7pkoZr9M+?= =?us-ascii?Q?T5J19uP9dKdk8rBa6j7SNu2AAqV8AKvh?= X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(35042699022)(36860700013)(14060799003)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 09:24:09.1766 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 37576c98-604c-481f-f6ba-08dd137c3de4 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB1PEPF00039234.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB10210 Hi Michal, > On 3 Dec 2024, at 10:22, Michal Orzel wrote: >=20 > Commit a14593e3995a extended BOOTINFO_{ACPI,SHMEM}_INIT initializers > list with a new 'type' member but forgot to add trailing commas (they > were present before). This results in a build failure when building > with CONFIG_ACPI=3Dy and CONFIG_STATIC_SHM=3Dy: > ./include/xen/bootfdt.h:155:5: error: request for member 'shmem' in somet= hing not a structure or union > 155 | .shmem.common.max_banks =3D NR_SHMEM_BANKS, \ > | ^ > ./include/xen/bootfdt.h:168:5: note: in expansion of macro 'BOOTINFO_SHME= M_INIT' > 168 | BOOTINFO_SHMEM_INIT \ > | ^~~~~~~~~~~~~~~~~~~ > common/device-tree/bootinfo.c:22:39: note: in expansion of macro 'BOOTINF= O_INIT' > 22 | struct bootinfo __initdata bootinfo =3D BOOTINFO_INIT; >=20 > Fixes: a14593e3995a ("xen/device-tree: Allow region overlapping with /mem= reserve/ ranges") > Signed-off-by: Michal Orzel Reviewed-by: Bertrand Marquis Cheers Bertrand > --- > xen/include/xen/bootfdt.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) >=20 > diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h > index cea40ee11706..343c48b73d2c 100644 > --- a/xen/include/xen/bootfdt.h > +++ b/xen/include/xen/bootfdt.h > @@ -145,7 +145,7 @@ struct bootinfo { > #ifdef CONFIG_ACPI > #define BOOTINFO_ACPI_INIT \ > .acpi.common.max_banks =3D NR_MEM_BANKS, \ > - .acpi.common.type =3D MEMORY > + .acpi.common.type =3D MEMORY, > #else > #define BOOTINFO_ACPI_INIT > #endif > @@ -153,7 +153,7 @@ struct bootinfo { > #ifdef CONFIG_STATIC_SHM > #define BOOTINFO_SHMEM_INIT \ > .shmem.common.max_banks =3D NR_SHMEM_BANKS, \ > - .shmem.common.type =3D STATIC_SHARED_MEMORY > + .shmem.common.type =3D STATIC_SHARED_MEMORY, > #else > #define BOOTINFO_SHMEM_INIT > #endif > --=20 > 2.25.1 >=20 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:26:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:26:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847583.1262678 (Exim 4.92) (envelope-from ) id 1tIPB2-00085t-Dg; Tue, 03 Dec 2024 09:26:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847583.1262678; Tue, 03 Dec 2024 09:26: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 1tIPB2-00085m-Ay; Tue, 03 Dec 2024 09:26:40 +0000 Received: by outflank-mailman (input) for mailman id 847583; Tue, 03 Dec 2024 09:26: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 1tIPB1-00084R-B4 for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:26:39 +0000 Received: from DUZPR83CU001.outbound.protection.outlook.com (mail-northeuropeazlp170130004.outbound.protection.outlook.com [2a01:111:f403:c200::4]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b1ec6268-b158-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 10:26:37 +0100 (CET) Received: from AS4P190CA0054.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:656::18) by VE1PR08MB5677.eurprd08.prod.outlook.com (2603:10a6:800:1ab::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 09:26:32 +0000 Received: from AMS1EPF0000004D.eurprd04.prod.outlook.com (2603:10a6:20b:656:cafe::35) by AS4P190CA0054.outlook.office365.com (2603:10a6:20b:656::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.18 via Frontend Transport; Tue, 3 Dec 2024 09:26:32 +0000 Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AMS1EPF0000004D.mail.protection.outlook.com (10.167.16.138) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 09:26:31 +0000 Received: ("Tessian outbound 3b1f0cd68b0e:v514"); Tue, 03 Dec 2024 09:26:31 +0000 Received: from Le8669a32a9cf.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 6AF550CE-4548-485C-ADC8-A7B9668559D5.1; Tue, 03 Dec 2024 09:26:25 +0000 Received: from EUR03-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id Le8669a32a9cf.2 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 03 Dec 2024 09:26:25 +0000 Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21) by DU2PR08MB10013.eurprd08.prod.outlook.com (2603:10a6:10:49c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 09:26:22 +0000 Received: from DBAPR08MB5798.eurprd08.prod.outlook.com ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com ([fe80::4a66:d3e2:570:9632%5]) with mapi id 15.20.8207.017; Tue, 3 Dec 2024 09:26: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: b1ec6268-b158-11ef-99a3-01e77a169b0f ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=D+c0cGlabbZIMaFTKhsVoQTjX4hcHss9LvPvkvMUiHANpvzf50xRw/IBBIkQYAbqNReCB3/JZKk/8g+otUosPNIaGHoyfENXmMrKATRtv9VtaCJHw24W4m4W/cavZjToyWv3OwrEyIOl4AohH8Jvr5otCdR0JwEH1sK5w0n0TvG6LCmLeozspkJ7dvRMoJvHi0XbMnLwes1pwAmFyDCdQtOWiex2lff1EbKQ0cJHd+W01p9L1xOlLmM1f2p4rrmev+3Fs1tYv0bcqtTGR2LJJCq6YucXLYjTX3DY8rJe7F/U0TdHA7+wYEgOGLToFJkQKqdsn2XeWlg2h4FxYA1CGg== 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=2Y6GPGf96UhUOpaZ7qfGW1EE/OhDxl3YJTjTOPLRSH4=; b=krp71+rRRI/AuvwFAdKA+NfYw9K+WsbVgQ4QHX9l2aQSMayO5mV91MC2m5cvQ3aZzkUjRIi5mupLkSN7vcVq363OxBbUfKjShYxXpPQ2wGqq+hvkLasmxfTwgXTFmHBonw5h2USTM/WaCnSZd+trZAcm/ITiugCOF8vlS3eWzcuPBfMbwWG7+rV/tpAIgSzOjz056pXoq5WXSO5nCrJ2dVGt6WFwIwmUjNsD7g8nsgHdpBv0p/JPzmliLcRWfUddWGdCwbkJ27YHEQs3os1Cm7lfnZw9NERA2vKeXpBV5SpGfhJRp7W/uEdtP8cBIHlPNmmMN0sHlezN6omeh3Q+8w== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=2Y6GPGf96UhUOpaZ7qfGW1EE/OhDxl3YJTjTOPLRSH4=; b=kLkBlKh356dvWTF/TRbwz1TJzwjtYxHBf909c6s5xrg64GhpGL387rRqcomDYaGTFcWWqHMRl4EwEKWOe238J8ATQ1lZ0S5UKv0zJ++/+Kh0TwYhS4H0K1qaPIL5D3iUt3dX5xdJ/W/osuioNf6jWgB67Zn6L02at13axzLexxI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) 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 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C X-CheckRecipientChecked: true X-CR-MTA-CID: f67df11adde3981c X-TessianGatewayMetadata: oI/6vbCgnFPHCvtyK9cnZJD8BWq01U5U6Y81sQzUbpNSYeBxeQpsFVas93u9Btlo+HmVP0l4OF7iYbKY0gPWOIXi47FdPoEhYl9FfRYMQl4pzo7HcjzUs18OCDgVhM5a0q/EhWQj/JVPQDl1tQH11CmMI50415DQ8ViTLnbgiEg= X-CR-MTA-TID: 64aa7808 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tKaMLB1oLm9v3TodGjdQbIJp2jdT6GpieAapBgBzWTAP98nSV37sICrah8JwgNr5Oz/faA9fgWE9YXWiyrFxm9TN31mu2ZExl9JBql+A5s84Db666R5DJUxE4CIyQUiuZX7A9+6dazGb8ArZeN3PHoEQ5auWVF0KukzH9WfnJxRYyOvV3xAC9dlnABP4Bk1PYKOp7KLNLEs99sRbAer/TC9dcUChthdY8njzammZaNExPlPiHgwtXoKzNPeb7MMMsuotkYv+J1XPCdeHoPY9QG0nuYqi1RUxfAzFhfrSnCsmL/mFXFYoHI47918QCljSBhyEGGB9HPRSal5TMulTKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2Y6GPGf96UhUOpaZ7qfGW1EE/OhDxl3YJTjTOPLRSH4=; b=hHeEFQEmlSdhiKnBvYBD78hiB4AcxwPK1YizuGqINuJPhMh8RfjKjm5qv52RMrfq2upDLy37iIlkyJ39tIVtF1F2qX1Bc7jarI3GNPg9jeGSvO5BF/OVeIYDqsCvnmQDC2nGbpr3jzAOPB2R3bbSLhYWOblQwhuR1A3rH+Z3mose4NYRybLdyzX+df/5HPdp+wxW2mJ/GGorjkPfmCd1Rl+ki0vA9P0uGGLrHvBXQL957GAZUzcrPCPb5Bp3/q9RXzW9v5/actFaxZbf47SU5U2ZLGBZQ0LbJPBYi13IqcERiwcShR8zfOvKbHNyknCWteqpF9n1JkaOrQ5i5HlIFg== 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=2Y6GPGf96UhUOpaZ7qfGW1EE/OhDxl3YJTjTOPLRSH4=; b=kLkBlKh356dvWTF/TRbwz1TJzwjtYxHBf909c6s5xrg64GhpGL387rRqcomDYaGTFcWWqHMRl4EwEKWOe238J8ATQ1lZ0S5UKv0zJ++/+Kh0TwYhS4H0K1qaPIL5D3iUt3dX5xdJ/W/osuioNf6jWgB67Zn6L02at13axzLexxI= From: Luca Fancellu To: Michal Orzel CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis Subject: Re: [PATCH] bootfdt: Add missing trailing commas in BOOTINFO_{ACPI,SHMEM}_INIT Thread-Topic: [PATCH] bootfdt: Add missing trailing commas in BOOTINFO_{ACPI,SHMEM}_INIT Thread-Index: AQHbRWTiS8+/Ezdwzk6UJiAaaYX4BrLUP+cA Date: Tue, 3 Dec 2024 09:26:22 +0000 Message-ID: References: <20241203092214.276453-1-michal.orzel@amd.com> In-Reply-To: <20241203092214.276453-1-michal.orzel@amd.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3826.200.121) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DBAPR08MB5798:EE_|DU2PR08MB10013:EE_|AMS1EPF0000004D:EE_|VE1PR08MB5677:EE_ X-MS-Office365-Filtering-Correlation-Id: 00b34259-4a15-418a-1f7e-08dd137c930c 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|1800799024|366016|38070700018; X-Microsoft-Antispam-Message-Info-Original: =?us-ascii?Q?lSa1LgAYuES7KdhBDovkzKggg/NZTVe5zMkiKwOCoEgLUlR6KNslztsaWEGJ?= =?us-ascii?Q?Ly0IYcxfokeHJYqRAQAqLcgg1PsKEgs+Vdv+eenLVoqvXxR5QehXaw9z9vAz?= =?us-ascii?Q?iYPEv9vZW07FOekS2ajBZc/pQ+eFZH3u8k5uI8J0s4Iigi6cnNXf+WPyRSZr?= =?us-ascii?Q?zqhw1tirO7mZjHtjII+x7sFu3oObsn73ZEj+cQ3LqtygeuD6dtpkLY1cJvoh?= =?us-ascii?Q?1WSL55NC4SYWXIBP9f9+M6TuQvu/R8/e7a4aAmzSL5ES/p7SXWpngGBMntIC?= =?us-ascii?Q?GAefXkpyhJqs/mrnI6dOjgYUK5tGhJo0HwkWr15oD/umNNXofbxoGNfQ8EXK?= =?us-ascii?Q?fBom97/tkQXHQ9SYy99kvFBkuN/dDZvbo/iMbm+PqrYw4GcVK4kl7nsqAA/Z?= =?us-ascii?Q?jJeOwhd8z0sCvi0JJPUirYkaRAUfvA8lGXkDNCoeiaE4dTUwCEbEJV+3eBxi?= =?us-ascii?Q?/XlO1C8bwpZlHf6sQglZbUmxBvFVJE8B+vkUxtiUq4JxNn4+9jcfQTwQ1+kA?= =?us-ascii?Q?r1lOGAwMklPtCVVISmtSF+D9OQG9toS4hvjKbljEIl3HPes6bHFLXpzyODPk?= =?us-ascii?Q?fuvCVwvcpH9PIGzFSk4EOcVqRJCkiXTfJZJPqvfx8PVRWRpuEFXajIP5EsGr?= =?us-ascii?Q?g1l2B/3tzG5fGXpQoHQLOxLM6hfK3PD2HEhfLuiTYZPHvGPK6P/MKVr2zoOn?= =?us-ascii?Q?zRRJUMN1o+gju7GbW0PTFcLUQQa3bPyWkGBV9jpyRDhF8eqG4S3kobdQgVzW?= =?us-ascii?Q?Z+4BovfF0295Cnpew50gUo0zfEHysOfGn0ANoVBIMgTiaavF4J+l40cqJALT?= =?us-ascii?Q?EuIKALpEACCOcdUgH0CUHOo8lY05ztHFLPJvYv7npoiQMyZAnzJwWN0oFybg?= =?us-ascii?Q?ltZlneWeg3ojgqGvzKs054SWoinEnrWY9BwhtOXrhIgg98nEGrDcqqHb9477?= =?us-ascii?Q?las2p9hfCFLRVLSPWTkREe2oFKdDmZdc4qhTabOqhF/5ffxkIlWF8pDBeC0s?= =?us-ascii?Q?ritfpC825XyYwyuFaNkGDT4zRenTkE8fjwkqrFFWEWCpLnHAybupXCnLOVE0?= =?us-ascii?Q?wdNEP6WlDy/nyJeXUCLyAJQkTnmigiYgzrm0coQIaGp/Si6GqQ2G8plM3kOQ?= =?us-ascii?Q?nTDTuAt7rvMfW73UjXDQzBOboCoVtN4Ow4e4SDp+rnH391m3lzjuohvVXFDX?= =?us-ascii?Q?w7a6Og85atwJtsf5rdQoZUvbj/Zlo7fQaYA/4g+MgYeGFCVVI5hnZhvQmz2i?= =?us-ascii?Q?g+YDQunCAbKCq3+canzQnWfTRByoJtDD68tnbM6KGu7Cah9dh5aYPfjCSd62?= =?us-ascii?Q?UihgsJeu6hhOXS4WMWtDgzMIG+lleXsysmRD1pgOCYb1w6thM36QrndAqGqE?= =?us-ascii?Q?TyLzM0HK8uUfGiJr9HWWF2CE+0pBKkDPHqKA8gENZ7jSDXLDbg=3D=3D?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: <57E10F0A1F5D1E46B9E9C64D8D2722F3@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR08MB10013 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-SkipListedInternetSender: ip=[2603:10a6:10:1a6::21];domain=DBAPR08MB5798.eurprd08.prod.outlook.com X-MS-Exchange-Transport-CrossTenantHeadersStripped: AMS1EPF0000004D.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 6ed0f217-2d02-4cbe-defd-08dd137c8d54 X-Microsoft-Antispam: BCL:0;ARA:13230040|35042699022|14060799003|36860700013|82310400026|1800799024|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?xMQTwibs6PIB07ZlTeOfrJ67Ra+gP+TqwrDhstNOmxJowD11KgEsGhlF7Ssu?= =?us-ascii?Q?/VFGPyLmT1Egq6BHwIUsUG7k2eZPCs7w4dMYyato4+J1RDVFlnrnkv1eE7uY?= =?us-ascii?Q?ZpsJp+yytj4loBZavjIJoMJaJSUvsfV/1Ilh4ig+C2u68YTs/SrfJ3eHco+p?= =?us-ascii?Q?sIy55OASIO/8B0fPKP2Ewja8slQVC+5DHvin5ZwAQsKxdQ9JODxuOK3HFJuo?= =?us-ascii?Q?+h3H9SUYZEWJ/Kq17s7RoL2OyGdDkTKD5ORdbk/gkvEtHjIZMPAYaUznxEOS?= =?us-ascii?Q?OWYgrqhaDIoc+lUgzSDy57kTEK8Hv4T1NEJixvpRSc10l4n/napjbUTXz/lb?= =?us-ascii?Q?UsJPpsPhlOgGtu5+qOa1NkoU3BZFgx8xMLkRCq7+zXRg6AqqXwmMguzo9eyj?= =?us-ascii?Q?69gscNuqSR+CBAt/U/GjycUHGpHb5zJWdNYMQrsOe5QmG0IPe9fi3zNy2JkN?= =?us-ascii?Q?c1igbnEQRDGdBUzKBjg0pRLpbN6qM8i0ANynSDTcaQihhAqyKcBkmEo3MMVb?= =?us-ascii?Q?SLvEv1szb8jzVdyb9P7pomX69YaVhBZIQmftgWXNWxhinRMHJlkZkbGozi6Y?= =?us-ascii?Q?b6MycTBPFVwtq4PBSMKs4WJgiq2cicGEiUlcd2JeEx7g0bET+Z2xpZWBltNz?= =?us-ascii?Q?SUeDK6akVNbfVlyDc/0cE0RL+4XvS8S4KfFSqZJKK9xMpWTkJ1DybA4wYD3p?= =?us-ascii?Q?xegNROlz6p3JNPaAKWmlMO7uf2tuDxeu6KicwCIlCqb7RG0+h529jLrnNLUq?= =?us-ascii?Q?TG2CH98nesTWk+dJ14kjdHNQwhSplG5Ujicbp4Z6gWBdpxJF+6SsNXL5ZHGI?= =?us-ascii?Q?0b+h8PtZVn457YyFAx8hxlM6ftFkG/P6qUn3e1Nj0RUJlfCBylJyw4XNG+NB?= =?us-ascii?Q?NVjfbbrhB2Xd1OM6OUeow7CIriwfl8uZSitSTaiWpAa/S2kBR//bujpOJDRj?= =?us-ascii?Q?NjKAzm6weheXteV2Jq2txVAA14Xw7337bqJiPkwckzOSLq6gU47gM17vjnn1?= =?us-ascii?Q?3l8wxBQ2LhjC1cga332e6yIEkBjyRIhGeMlxMl3BLJl4UI9yArFtCl8rbEPm?= =?us-ascii?Q?Spv4y+YKFpdBBxbBiaegVQeiRYoYfbFw+J8D/DD9hNfJfIWdu0Qy4YTLWX6z?= =?us-ascii?Q?wFp7uqV86wS38egyohdW3H0AzCnIXB/8Th3IDqhJTr5OI233KqAUjHRx+hl0?= =?us-ascii?Q?vzLkFZ35O6c1Uggh30GT360EJvnFbE6Cxa1XanxRTETka2mSaPPCozNeZtb5?= =?us-ascii?Q?MPH1gycZjW/a9fZrh5nlfufuOeVPsHkAFTGslD1fnytmuvoAwxw5JjOVzyma?= =?us-ascii?Q?AMnEdnt6i8rpiE5zSNS0iamkAOp4cWX+8MkKFyM3zXztuh4akGIfhHVUkGEy?= =?us-ascii?Q?GXKpyE1WCE7Ikm/mhiCtBvAYl9VDP+Ra8VmEq6Fqazmbi80OIf3FPdGzyJdZ?= =?us-ascii?Q?Zt+bY1vtj9WMfLyZBfjIYaL8e7FN+4yO?= X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(35042699022)(14060799003)(36860700013)(82310400026)(1800799024)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 09:26:31.9927 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 00b34259-4a15-418a-1f7e-08dd137c930c X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AMS1EPF0000004D.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5677 > On 3 Dec 2024, at 09:22, Michal Orzel wrote: >=20 > Commit a14593e3995a extended BOOTINFO_{ACPI,SHMEM}_INIT initializers > list with a new 'type' member but forgot to add trailing commas (they > were present before). This results in a build failure when building > with CONFIG_ACPI=3Dy and CONFIG_STATIC_SHM=3Dy: > ./include/xen/bootfdt.h:155:5: error: request for member 'shmem' in somet= hing not a structure or union > 155 | .shmem.common.max_banks =3D NR_SHMEM_BANKS, \ > | ^ > ./include/xen/bootfdt.h:168:5: note: in expansion of macro 'BOOTINFO_SHME= M_INIT' > 168 | BOOTINFO_SHMEM_INIT \ > | ^~~~~~~~~~~~~~~~~~~ > common/device-tree/bootinfo.c:22:39: note: in expansion of macro 'BOOTINF= O_INIT' > 22 | struct bootinfo __initdata bootinfo =3D BOOTINFO_INIT; >=20 > Fixes: a14593e3995a ("xen/device-tree: Allow region overlapping with /mem= reserve/ ranges") > Signed-off-by: Michal Orzel > --- Thanks Michal, I realise our internal CI is not testing a configuration wit= h CONFIG_ACPI=3Dy and CONFIG_STATIC_SHM=3Dy, this is why I missed it. Reviewed-by: Luca Fancellu > Cheers, Luca From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:30:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:30:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847606.1262698 (Exim 4.92) (envelope-from ) id 1tIPEt-0001Yi-4b; Tue, 03 Dec 2024 09:30:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847606.1262698; Tue, 03 Dec 2024 09:30: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 1tIPEt-0001Ya-1q; Tue, 03 Dec 2024 09:30:39 +0000 Received: by outflank-mailman (input) for mailman id 847606; Tue, 03 Dec 2024 09:30: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 1tIP7Q-0003Be-Jr for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:22:56 +0000 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam04on2061b.outbound.protection.outlook.com [2a01:111:f403:2409::61b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2d1fcf17-b158-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 10:22:55 +0100 (CET) Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by PH7PR12MB6562.namprd12.prod.outlook.com (2603:10b6:510:212::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.19; Tue, 3 Dec 2024 09:22:52 +0000 Received: from DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::b04e:2da5:7189:4c4d%5]) with mapi id 15.20.8207.017; Tue, 3 Dec 2024 09:22: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: 2d1fcf17-b158-11ef-a0d3-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=d7PiYMH4sWMrCvlY0GuWpFfyoosfC0jWqlDSc/Uu8UiU+MERTzbf3YF8GxQoB2AYLKrcZVhA5DBJ0leJahnPOqLKnr6dFhomDKMN8xGBkDuL+0ZU8YpytQtRQ4EBKzzc/co1zU+tjvJQOtTmBsxInGJagcCB4C7xtK10+O1n3WUw4agXWEZgvkEnpP10uXQEKdnS2Bb8ONpvbc+4BDpNmCDBNgUqjB3YpI/qsDCVrnDBD2rjT6NmJ1rq5JShPtKTz5vG7wvLww/zQO7b/FoyqNcnYUHey8VxzJzn/u4YAtj1B/PiIoPTF0hOYQ5Z4kBbB3Smo4vFCjNcYZ+gdpKaAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=81Ldwl0GqaYchefVU+uRrSQ4FZ9bnLV8Ifjzlr4OwOw=; b=ahY9Hfc36WsylW6QclcPT+1wEcZdFTPExq1yAUp/NzsuP5yEMZRAER1UiZ0tc+ZQfwIUvJnCXdYBfqAN81kHMxPHhjLJ98VP7Cp6/mJqKjvHCeXdXwav/8al4LmN+vLNFyprbWrrzll9CYQja/TK6/GObKkGvqWn0p8tFd4fPJr46kI77VVZFe/OgHm0IpGb3SxVgovmurbmT+s5EOT6NuwHcanCkya2bxoiwAwPQ1oZalTC7ae0Dv4CZ4IiW9GjqfyvsbwipCJ0Xi00ym7pzD6H78kUlgb4e7cTWwgm3L/soAYUpyDwkHgB19FsgeIoqoXhb45+r4jz9IyH9UEuTQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=81Ldwl0GqaYchefVU+uRrSQ4FZ9bnLV8Ifjzlr4OwOw=; b=vYMiqNe97cXlOKJpwJT0QQmEjzMlHdZnQ+IBXsetqsKqCuxsqNN6F2p/cnpWEVpgsbkjK6V9tA37g6cN3HG3WcLP4ouPoZzD7ISTtNp+Oz4DoRkVM7K4LFCtDpsaScdX1mMN+8uif+RRTU3y/bsXpBrSkzGlbVpiR9mhYl09j7I= From: "Penny, Zheng" To: Jan Beulich CC: "Stabellini, Stefano" , "Huang, Ray" , "Ragiadakou, Xenia" , "Andryuk, Jason" , Andrew Cooper , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Julien Grall , Stefano Stabellini , Anthony PERARD , "xen-devel@lists.xenproject.org" Subject: RE: [PATCH v1 00/11] amd-pstate CPU Performance Scaling Driver Thread-Topic: [PATCH v1 00/11] amd-pstate CPU Performance Scaling Driver Thread-Index: AQHbRVunyKYn4ka+eUmYX8UkoWQ2p7LUOQ4AgAAFVxA= Date: Tue, 3 Dec 2024 09:22:52 +0000 Message-ID: References: <20241203081111.463400-1-Penny.Zheng@amd.com> <593baee2-9bf1-4db4-86e8-015cae48dc1a@suse.com> In-Reply-To: <593baee2-9bf1-4db4-86e8-015cae48dc1a@suse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ActionId=bf334407-ae71-498b-82b3-c71c1a6f3b0b;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ContentBits=0;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Enabled=true;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Method=Standard;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Name=AMD Internal Distribution Only;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SetDate=2024-12-03T09:20:12Z;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|PH7PR12MB6562:EE_ x-ms-office365-filtering-correlation-id: 5eea3dec-093c-4de1-643b-08dd137c0fef x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700018; x-microsoft-antispam-message-info: =?utf-8?B?a1p3WnFxRllRVmdiN1YwYkdpUUI4R1ZReUFNQlc4azl5L2pKbitXV0VFeWZ2?= =?utf-8?B?T29lTDVkb04rOGZtYjBScmZqM3AvWXo4Y2hpeFhTeFIrWndWSGl3Rm5ESW93?= =?utf-8?B?OHZoM3ZLLy9jekVmWXQ3UnRBZTFhQVc5cDRMdEV4ZGZRc2RDb0R6M3phZkdF?= =?utf-8?B?L3FsTWh6UkFETGF3UWFzN2gxcWd5R2pQaVdQbjhGSm93Tmw0T2xFd3FxWHlx?= =?utf-8?B?d25iWFJ4ZzlWU3JUZUVIZmJ1amxYUVptRFcxVjcvaTd4UHE1WFQ1YXZhSEVm?= =?utf-8?B?N0RiZVhQWWFjbUozRlpkMVc0c0VrSHg5SjQyb2NzL1FIRCtIeFJHMlVxRFAy?= =?utf-8?B?c0JXYS9aVlhXK0hlMDg3YTUrOWtsY25LY1VDVWZhM2RrTis5TUJDYkM0emkx?= =?utf-8?B?WDMzNEFmYUNnY0FiaWlyL0VpNHFkd3lEOEVQblE0WmdlUmljZ0dncmJESmc1?= =?utf-8?B?VllWQWF6WDUveFJwZjl6R3VVVjI2NnNhUnJrcWxxMHd3UkdsSmE2VkU1VVl1?= =?utf-8?B?TEhJK09QeXhxM0NYZlVPOW12ZjVOQk5RMWFvVW1kZk1ibWVXWWkvK05HQTQ1?= =?utf-8?B?MzRWL3UzaldXV1VUaTd0ZUl2dVl1dTNOYU1HOFhOR0ZKMVlZYXRVWkpSbCtF?= =?utf-8?B?Um5WMnFPTjNjTm8zVGRNYW1iRVpqUUF0bEg1RWRoQmdBLzlPUjBrSUtyL1Rj?= =?utf-8?B?d0x4RFFSNURYcG9QOTU2YjZIUUZRVVBwQk8rUnd4akZORmRLQ3Zla1V5bEJZ?= =?utf-8?B?TytkNThpV0xSb0ZEblIxaysrdlJxeGJtS0FkeTNUdDR0K0JWSXNnU3h3M1JJ?= =?utf-8?B?dUF1QWhyLzB4N1NyazA0c0FMRC82bFhMZVhOZEVtTFlDcVpoSzlmSjlGRFI0?= =?utf-8?B?ZTYrYzVkUkhiMm5qMFhMTEUxRitYcm50QW44d0tXNlV2ckhSakp6ZTNDQXZI?= =?utf-8?B?QUNFMENWOXpHcWpYWDBINWEzeG5lQjlkR1Bxb0J1T2ZBSE5uT3lpMXFySmdV?= =?utf-8?B?R0pieUtPeEJ3VHh3eStrWnA2VjJ2U2tYUFR0YjdrQTJqdzlIRy9TRzRJNENq?= =?utf-8?B?U3ZDUTIrcmQvRmVjaDNjOEw4NkRKWVNpMmpKdnB3YjFpZmNYL1NVcmlscUc2?= =?utf-8?B?a0laVDNsK2ZVMXZqZ0dNdUI4VDRudWhpUkVlL29Xc0hZUU9zK3dHWUsxTStW?= =?utf-8?B?Q1AzZjdkZnVmUnRIMlRsQ3JESVphY0JsZWhxN0RZM0dWTlN0YnRJSERQd1lx?= =?utf-8?B?dy9kcnFZOXFhcWpJYjVDcUNJazdMSDFmTXFGRmRMNktvMXluRG9tM1l3N0hL?= =?utf-8?B?a1RRbGpzaWlHS29raHhhbE81ZmNOTHVkaHhZRExaaWNZL1FNYi9ocS8xMGhp?= =?utf-8?B?SzNsMy91K2ZzWnpRSFVnWksvZjFkQkQyUG5JTkxWdDE2L1p4eXdONlprSmNX?= =?utf-8?B?TzNWU3VvQ2NPM3ZrSFZPNVU1Snh0L3cxenFQSkFZS1RTZ0xCYnFLdkNIQlVh?= =?utf-8?B?L3RLMS9FdkdvK25sRGh4cFVjdURLUy9rRkFFSGJ2T1k5WGRIeXdZVXdhbUY4?= =?utf-8?B?WFJxcU5jN0o3UnZjUmtDWXFqcU1FaHFmRVl4NWJPK2YwdjQ4dVZ4SVlzVXI1?= =?utf-8?B?cWtROG9mVDNVaTVWSEFrREZMcGRHNVA3ZVBIV2dFSE9GeG4zRFlCbUhaOFgy?= =?utf-8?B?T1EwQmVReTNDYllMdGk4N0VPK0dYb3E1Y2V5QXZ6QWh0SHNVTEh2S00yamo1?= =?utf-8?B?MFdxNTNCVE9ydUtrcUxIYWJteUJPRVl6RG5jSTJGRmM4b3JaUVZRM2pveXJO?= =?utf-8?B?ZzRoM1BtNUtNVDVBSzdmOGY4TDRZZzhUenR0UUxuZW5zdE9WWjM1b090U01D?= =?utf-8?B?QXF3bFEzTittNGJ3MUswbVhCMmpOWEIzVVNMeGlWQzAyWnc9PQ==?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WEp6UnRMV0RZYTk5V3ExQW5MdWJqNmZuNVVNK2NsUXZlTTkyVjdlbTJqbmpy?= =?utf-8?B?bC9JVVkrV2RZd2xQUzlWV2s0dnduRGsvQ3BBTkFqZi9tZnZHYkZSZG5wZi9k?= =?utf-8?B?TDRqNXNCWEF6OWJ0SHJXaG8ydjRYVmVyYSt5bXU3NnF4TUlscFdHWTltL2F5?= =?utf-8?B?cURiUEl6SkVoNitvUHlWYzRsYndrY0s0cytQSXMvNkMwa2VwOWZOZUVrUlAv?= =?utf-8?B?bndZei84dmxpVUVWNFVSbFYzakFtdWNsVFJjVUpjcjRLM2JORU1CWXdKZ0dm?= =?utf-8?B?dEtBRFpwYUlQcEtuWEhxd3dhNUkvOC9Bb2ZsQXNVdm9XUVhxMmRVeXpuVDFH?= =?utf-8?B?TmEyaDI3KzNKaEUrTWJReGt6NCszV0ZsMC8wdEVUY0VLWlFWdkkvNkN2c0pO?= =?utf-8?B?WmgvY2dDRVQzcXYzbkZNMDdlZTVXKzlQQWFBbjlMVUUrdElmWjNoYVZJM2Y2?= =?utf-8?B?YXhkYWtnWlE0NkNWYTU2ditFckpCVVhwb25lYUZueUNvLzBGYk45QWY0bWc4?= =?utf-8?B?SWtQWVdKakdTRFluM3dndVN1anpYbjZ2Q21heHJsOTNwaHR3OVpsNlBmdW5R?= =?utf-8?B?M3RvUGdXRkVpVEorWCt6ZjZtU0ZobTFGd3ZiLzVhRTVrWHdBV1pNV2U0emlQ?= =?utf-8?B?ZGc5aXFLNVFvMkxwVzBidWYzbTBSWndqd0VSdGIzVDg2TFRDWlJWNlMrdGNN?= =?utf-8?B?KzdHSlpka2RyZTFlQVpDbUovcDdQR3B2TXUxRXN5YWhmNEZnZXI5dDRpclZ3?= =?utf-8?B?aFM5d3A1RHcyUCtnYTdWUkkvdmhkM1VLekhRZ3B4TTlRQmRqalVPS0d5akNG?= =?utf-8?B?dmRFVlB3VmNFN1gvMXJBNXRZS1c2RUpMUTZ1UUVyRllDREk0dnJteko3QTlY?= =?utf-8?B?bldDWkRnNHUvaWR3eWZTVDR6Wk56QVhidTQ0ZVBLUUV0YWM4U1VlRnY1WUM0?= =?utf-8?B?WDhoVHczRkhiWll3Ynl1bklnZ3dFb0RwaTBwZ2RMQ2lGcTlOb1BySDFreVl5?= =?utf-8?B?Y0xBYU9mMllTSDhzVmNWbWFBUWxNQkJkMkc0VXFHYjhiY3gxdmwvN3Bha1Zr?= =?utf-8?B?QnZkM0xlQnlzVjlpc2FHOTdLRkZPSUxXQ0JCdGZuWlpXaWlza2lsYVF5TFpP?= =?utf-8?B?aFU2bXBjeEVCNmdDaXkyVXFjRjh5UU1tdXJad1dWMVZ1NG90VEFTSHc4K1ZN?= =?utf-8?B?UXZEdG53ZnNMbmZwbG9qUnIrQ1JBbTZaaWFoVGRkWDYxT0EvWEtraUZ2Wlcw?= =?utf-8?B?SmFuRTlxeGlDTGNieFQ4SXE4MjA1N3RrUXhOQS9BcElpWnloR3VuQmZXRHRq?= =?utf-8?B?REVtODU3MDFUSlVFaWtHUHZmZ3VpeTdRQXd2cTFVTWF4QXJjeGU2eWJCWTdp?= =?utf-8?B?VlJrclpPQTVNZGNJTytNYlhtL2hyWFF1clg5T3FubDlYWEIzQkI5N0JBZWU5?= =?utf-8?B?RUZoUGRoTTBPV0NMWXprRnl2eThjaloxMWd3MjdLSXpTM1lnWUthTEFFZTZ2?= =?utf-8?B?ZzIwek9zelZvU3Jwd2htREJuenpQcURVZzYzbU1rYkd6eEZZYmhHZGY0V3pk?= =?utf-8?B?UC9MMkxVWHZhMmxoQWZVeGE0bVdYQkhaYXVUaXVvdmxFU0hoK3BsWjdMWGFj?= =?utf-8?B?OU5MMy9aSWlKUktHSnArT3N2azR0Mm5qeUlSc0piM29jUE5IclZGVVpVN2pl?= =?utf-8?B?K1hqdDZYVzJvemhyb25mV3MrM2RRNTlHMS8yUU0wOU42QmNwdTRjalVWZmxD?= =?utf-8?B?MWJHZDBLM3BLYmdTY0tQb2MxYjA5WG1zMlFsbXZ6c3FIa3p3NGFOYnlBaTZa?= =?utf-8?B?UjhPTEFPLy83Sm1ubk1GSy9Kdm5aR1ZJR0QxWnA3RTFsa0FaZzB2ZjRNK040?= =?utf-8?B?SUl0OG9xc3c4WGlXdEhSYTYwbnV0UnhvOFlHanZoZTZuUEVSbHpLejNZWTB3?= =?utf-8?B?YkpwL0JzWVU2RnRnY1daYTd2aUx2bldvb0s4RUdTdjBjQmQvTVZudlRLVHZF?= =?utf-8?B?SWl5TVZsb0dxZ0N6MXNjVlFKdFNJcWRhcTNsR3NETkFoaDNXVzNTYlpEdURT?= =?utf-8?B?QjlFMkF3aE4vMnI1TG40U2hFbVg5eUc5Q2d4b3hVQStPYlB3bytOMjI2bjRZ?= =?utf-8?Q?kkQk=3D?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5eea3dec-093c-4de1-643b-08dd137c0fef X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2024 09:22:52.0164 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MQ9qDKwXtsMdhA//c0GJstjMQZBlB9RkrwkQ0UhOzYOjF5gD6oR8OUs+hHlxld3sIxK5VVY5LGwd4U7CFT6hGg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6562 W0FNRCBPZmZpY2lhbCBVc2UgT25seSAtIEFNRCBJbnRlcm5hbCBEaXN0cmlidXRpb24gT25seV0N Cg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPg0KPiBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAzLCAyMDI0 IDU6MDEgUE0NCj4gVG86IFBlbm55LCBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCj4gQ2M6 IFN0YWJlbGxpbmksIFN0ZWZhbm8gPHN0ZWZhbm8uc3RhYmVsbGluaUBhbWQuY29tPjsgSHVhbmcs IFJheQ0KPiA8UmF5Lkh1YW5nQGFtZC5jb20+OyBSYWdpYWRha291LCBYZW5pYSA8WGVuaWEuUmFn aWFkYWtvdUBhbWQuY29tPjsNCj4gQW5kcnl1aywgSmFzb24gPEphc29uLkFuZHJ5dWtAYW1kLmNv bT47IEFuZHJldyBDb29wZXINCj4gPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBSb2dlciBQ YXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT47IEp1bGllbg0KPiBHcmFsbCA8anVsaWVu QHhlbi5vcmc+OyBTdGVmYW5vIFN0YWJlbGxpbmkgPHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+OyBB bnRob255DQo+IFBFUkFSRCA8YW50aG9ueS5wZXJhcmRAdmF0ZXMudGVjaD47IHhlbi1kZXZlbEBs aXN0cy54ZW5wcm9qZWN0Lm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIHYxIDAwLzExXSBhbWQt cHN0YXRlIENQVSBQZXJmb3JtYW5jZSBTY2FsaW5nIERyaXZlcg0KPg0KPiBPbiAwMy4xMi4yMDI0 IDA5OjExLCBQZW5ueSBaaGVuZyB3cm90ZToNCj4gPiBhbWQtcHN0YXRlIGlzIHRoZSBBTUQgQ1BV IHBlcmZvcm1hbmNlIHNjYWxpbmcgZHJpdmVyIHRoYXQgaW50cm9kdWNlcyBhDQo+ID4gbmV3IENQ VSBmcmVxdWVuY3kgY29udHJvbCBtZWNoYW5pc20gb24gbW9kZXJuIEFNRCBBUFUgYW5kIENQVSBz ZXJpZXMNCj4gPiBpbiBYZW4uIFRoZSBuZXcgbWVjaGFuaXNtIGlzIGJhc2VkIG9uIENvbGxhYm9y YXRpdmUgUHJvY2Vzc29yDQo+ID4gUGVyZm9ybWFuY2UgQ29udHJvbCAoQ1BQQykgd2hpY2ggcHJv dmlkZXMgZmluZXIgZ3JhaW4gZnJlcXVlbmN5DQo+ID4gbWFuYWdlbWVudCB0aGFuIGxlZ2FjeSBB Q1BJIGhhcmR3YXJlIFAtU3RhdGVzLiBDdXJyZW50IEFNRCBDUFUvQVBVDQo+ID4gcGxhdGZvcm1z IGFyZSB1c2luZyB0aGUgQUNQSSBQLXN0YXRlcyBkcml2ZXIgdG8gbWFuYWdlIENQVSBmcmVxdWVu Y3kNCj4gPiBhbmQgY2xvY2tzIHdpdGggc3dpdGNoaW5nIG9ubHkgaW4gMyBQLXN0YXRlcy4gQ1BQ QyByZXBsYWNlcyB0aGUgQUNQSQ0KPiA+IFAtc3RhdGVzIGNvbnRyb2xzIGFuZCBhbGxvd3MgYSBm bGV4aWJsZSwgbG93LWxhdGVuY3kgaW50ZXJmYWNlIGZvciBYZW4NCj4gPiB0byBkaXJlY3RseSBj b21tdW5pY2F0ZSB0aGUgcGVyZm9ybWFuY2UgaGludHMgdG8gaGFyZHdhcmUuDQo+ID4NCj4gPiBh bWRfcHN0YXRlIENQUEMgaGFzIDIgb3BlcmF0aW9uIG1vZGVzOiBhdXRvbm9tb3VzIChhY3RpdmUp IG1vZGUsIGFuZA0KPiA+IG5vbi1hdXRvbm9tb3VzIChwYXNzaXZlKSBtb2RlLiBXZSByZWdpc3Rl ciBkaWZmZXJlbnQgQ1BVRnJlcSBkcml2ZXINCj4gPiBmb3IgZGlmZmVyZW50IG1vZGVzLCAiYW1k LXBzdGF0ZSIgZm9yIHBhc3NpdmUgbW9kZSBhbmQgImFtZC1wc3RhdGUtZXBwIg0KPiA+IGZvciBh Y3RpdmUgbW9kZS4NCj4gPg0KPiA+IFRoZSBwYXNzaXZlIG1vZGUgbGV2ZXJhZ2VzIGNvbW1vbiBn b3Zlcm5vcnMgc3VjaCBhcyAqb25kZW1hbmQqLA0KPiA+ICpwZXJmb3JtYW5jZSosIGV0YywgdG8g bWFuYWdlIHRoZSBwZXJmb3JtYW5jZSBoaW50cy4gQW5kIHRoZSBhY3RpdmUNCj4gPiBtb2RlIHVz ZXMgZXBwIHRvIHByb3ZpZGVzIGEgaGludCB0byB0aGUgaGFyZHdhcmUgaWYgc29mdHdhcmUgd2Fu dHMgdG8NCj4gPiBiaWFzIHRvd2FyZCBwZXJmb3JtYW5jZSAoMHgwKSBvciBlbmVyZ3kgZWZmaWNp ZW5jeSAoMHhmZikuIENQUEMgcG93ZXINCj4gPiBhbGdvcml0aG0gd2lsbCBjYWxjdWxhdGUgdGhl IHJ1bnRpbWUgd29ya2xvYWQgYW5kIGFkanVzdCB0aGUgcmVhbHRpbWUNCj4gPiBjcHUgY29yZXMg ZnJlcXVlbmN5IGFjY29yZGluZyB0byB0aGUgcG93ZXIgc3VwcGx5IGFuZCB0aGVybWFsLCBjb3Jl DQo+ID4gdm9sdGFnZSBhbmQgc29tZSBvdGhlciBoYXJkd2FyZSBjb25kaXRpb25zLg0KPiA+DQo+ ID4gYW1kLXBzdGF0ZSBpcyBlbmFibGVkIHdpdGggYSB0b3AtbGV2ZWwgY3B1ZnJlcT1hbWQtcHN0 YXRlIG9wdGlvbi4gSXQNCj4gPiB3aWxsIGZhbGxiYWNrIHRvIGNwdWZyZXE9eGVuIGlmIGFtZC1w c3RhdGUgaXMgdW5hdmFpbGFibGUuDQo+ID4NCj4gPiBXaXRoIGBjcHVmcmVxPWFtZC1wc3RhdGUs YWN0aXZlYCwgV2UgZGlkIGEgNjBzIHNhbXBsaW5nIHRlc3QgdG8gc2VlDQo+ID4gdGhlIENQVSBm cmVxdWVuY3kgY2hhbmdlLCB0aHJvdWdoIHR3ZWFraW5nIHRoZSBlbmVyZ3lfcGVyZiBwcmVmZXJl bmNlDQo+ID4gZnJvbSBgeGVucG0gc2V0LWNwdWZyZXEtY3BwYyBwb3dlcnNhdmVgIHRvIGB4ZW5w bSBzZXQtY3B1ZnJlcS1jcHBjDQo+IHBlcmZvcm1hbmNlYC4NCj4gPiBUaGUgb3V0cHV0cyBhcmUg YXMgZm9sbG93czoNCj4gPiBgYGANCj4gPiBTZXR0aW5nIENQVSBpbiBwb3dlcnNhdmUgbW9kZQ0K PiA+IFNhbXBsaW5nIGFuZCBPdXRwdXRzOg0KPiA+ICAgQXZnIGZyZXEgICAgICAyMDAwMDAwIEtI eg0KPiA+ICAgQXZnIGZyZXEgICAgICAyMDAwMDAwIEtIeg0KPiA+ICAgQXZnIGZyZXEgICAgICAy MDAwMDAwIEtIeg0KPiA+IFNldHRpbmcgQ1BVIGluIHBlcmZvcm1hbmNlIG1vZGUNCj4gPiBTYW1w bGluZyBhbmQgT3V0cHV0czoNCj4gPiAgIEF2ZyBmcmVxICAgICAgNDY0MDAwMCBLSHoNCj4gPiAg IEF2ZyBmcmVxICAgICAgNDIyMDAwMCBLSHoNCj4gPiAgIEF2ZyBmcmVxICAgICAgNDY0MDAwMCBL SHoNCj4gPiBgYGANCj4gPg0KPiA+IFBlbm55IFpoZW5nICgxMSk6DQo+ID4gICB4ZW4veDg2OiBh ZGQgQ1BQQyBmZWF0dXJlIGZsYWcgZm9yIEFNRCBwcm9jZXNzb3JzDQo+ID4gICB4ZW4veDg2OiBp bnRyb2R1Y2UgbmV3IHN1Yi1oeXBlcmNhbGwgdG8gZ2V0IENQUEMgZGF0YQ0KPiA+ICAgeGVuL3g4 NjogaW50cm9kdWNlICJjcHVmcmVxPWFtZC1wc3RhdGUiIHhlbiBjbWRsaW5lDQo+ID4gICB4ZW4v eDg2OiBnZXQgcHJvY2Vzc29yIG1heCBzcGVlZCBmcm9tIERNSSB0YWJsZQ0KPiA+ICAgeGVuL3g4 NjogaW50cm9kdWNlIGEgbmV3IGFtZCBwc3RhdGUgZHJpdmVyIGZvciBjcHVmcmVxIHNjYWxpbmcN Cj4gPiAgIHhlbi9jcHVmcmVxOiBpbnRyb2R1Y2UgcG9saWN5IHR5cGUgd2hlbiBjcHVmcmVxX2Ry aXZlci0+c2V0cG9saWN5DQo+ID4gICAgIGV4aXN0cw0KPiA+ICAgeGVuL2NwdWZyZXE6IG9ubHkg c2V0IGdvdiBOVUxMIHdoZW4gY3B1ZnJlcV9kcml2ZXIudGFyZ2V0KCkgZXhpc3RzDQo+ID4gICB4 ODYvY3B1ZnJlcTogYWRkICJjcHVmcmVxPWFtZC1wc3RhdGUsYWN0aXZlIiBwYXJhDQo+ID4gICB4 ZW4veDg2OiBpbXBsZW1lbnQgRVBQIHN1cHBvcnQgZm9yIHRoZSBBTUQgcHJvY2Vzc29ycw0KPiA+ ICAgdG9vbHMveGVucG06IFByaW50IENQUEMgcGFyYW1ldGVycyBmb3IgYW1kLXBzdGF0ZSBkcml2 ZXINCj4gPiAgIHhlbi9jcHVmcmVxOiBBZGFwdCBTRVQvR0VUX0NQVUZSRVFfQ1BQQyB4ZW5fc3lz Y3RsX3BtX29wIGZvcg0KPiA+ICAgICBhbWQtcHN0YXRlIGRyaXZlcg0KPg0KPiBKdXN0IHRvIGNs YXJpZnk6IFdoaWxlIGNlcnRhaW5seSBmaW5lLCBpdCBpcyBhIGxpdHRsZSBzdXJwcmlzaW5nIHRv IHNlZSBzdWNoIGEgc3VibWlzc2lvbg0KPiBqdXN0IGFmdGVyIHRoZSBzdWJtaXNzaW9uIGRlYWRs aW5lIGZvciA0LjIwIHdhcyBwYXNzZWQuDQoNClNvIHNvcnJ5Li4uLiBGb3Jnb3Qgd2UncmUgaW4g ZmVhdHVyZSBmcm96ZW4gd2luZG93DQoNCj4gVGhpcyBpcyBpbnRlbmRlZCBmb3IgNC4yMSB0aGVu LCBJIGV4cGVjdD8gT3IgZWxzZSBoYXZlIHlvdSB0YWxrZWQgdG8gdGhlIHJlbGVhc2UNCj4gbWFu YWdlcj8NCg0KWWVzLCBpdCBpcyBmb3IgNC4yMQ0KDQo+DQo+IEphbg0KDQpNYW55IHRoYW5rcywN ClBlbm55LA0K From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:30:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:30:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847603.1262687 (Exim 4.92) (envelope-from ) id 1tIPEr-0001IX-T4; Tue, 03 Dec 2024 09:30:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847603.1262687; Tue, 03 Dec 2024 09:30: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 1tIPEr-0001IQ-QU; Tue, 03 Dec 2024 09:30:37 +0000 Received: by outflank-mailman (input) for mailman id 847603; Tue, 03 Dec 2024 09:30: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 1tIP76-0003Be-Dv for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:22:36 +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 21da1635-b158-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 10:22:35 +0100 (CET) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a9a977d6cc7so314164266b.3 for ; Tue, 03 Dec 2024 01:22:35 -0800 (PST) Received: from localhost.localdomain ([176.187.209.146]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d0bfa327dcsm4180475a12.83.2024.12.03.01.22.34 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 03 Dec 2024 01:22: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: 21da1635-b158-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1733217755; x=1733822555; 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=uLnillY0LwsA1bGIi96aGqNPMbJhHjhH+14EVXV96qM=; b=imUrguuRYGI3zY/PgAsSHrinryfCiJPIe6JSAI8oiLSlJC4i6U5ztiCxdXXQ6XziCB IVeR1KxT4Lta81ACKhd4Or0zKrVhrrDcESZFVL5iVwFoxgyBIHtrdQ8nk55LDYDws6nT t9+WRoshGfzJqOfHbO00G9Xm/ncH41f9JFeZDKWx2UIp038HBihIcig9aHCS41hxYGdW XIP/cs7Rj86WodLnZKlDX2zYGVd7gGv2jCcSjfBU+RZ1NipfsYONHLlaAv5cJ5SDqJgc hmmkC1Ondvc9mrgWEL8GbHqYjHkJj8ryboz6y7FsrMCpjXCODJA9wui1XG1D/hN3sIkK G5YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733217755; x=1733822555; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uLnillY0LwsA1bGIi96aGqNPMbJhHjhH+14EVXV96qM=; b=c1GzdnUDRe9OvjBVzFv4yR3KLCg4lPlSFbt8tmiRGhS9bQGHonDAWNgw8MYPdaQP6p fOknaKwztq1U9U59Q7b0Zmh3HcPVZL079NisYmWSoXFMFhSDuz9kiGXh9JCOWgNuBYHR nudvfKrYHYOAm8gAgqsX7Ooe4OTNrfdvunu7CePbvO5pZ2FF8ENWGgftWTLvW1NI+2lK MDvPQvTBf/463iwUXwhGO5SCNIgMO7YHe+qymSfA9ReIx2HWPnELU7Bzf+nmuyJ2bmSC uViTy7e/KAyChJahbHsvE1dYM6hnymk7DwcgXKJgmy4yQsGHizGns2k0qcdPkmMgyKlY 6QWw== X-Forwarded-Encrypted: i=1; AJvYcCWxoqJfyQU44bbDN4HILYiqmxj9ixm4K39M/hwARfByN/xNcfornrykPAXtTLItJqTBR434UZN+MPU=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz3hsrnQpMXYX+Da6/p9FP6BMDSpoNMSIFA8juAsBiqUr/7t0ld lvvW6K6tSdxK7wqGjTaFAIQyCC9yROfWlgCCQMEYztl6h4G8aiK9wuCj40Ompmw= X-Gm-Gg: ASbGncuec356kjmDZnhHJPf2vJTR9a4BkUwcbXSMEB8Ki+Au13xDkpVNEaD6jxGpSMo cfPZg9To7o84vwLVB0vQ9A3x0cXPNLzSCq0NYpuOPUvpIiVkL28plyAD0/M54VWss24pcExdIiS 1Q2JHjIsQPG+sPnNURr5KNYdCJr27uPgGi6hbldOxE7HHjNUqqDD3Y9z+bRWBk29GhMB0dpOp7M fAmPT03hYU5tZbRWbwkoHlUI9sWb6gFcPXdxmVjCBlwrmtUHvnXYAk15+QyKA2qzihSwnUc X-Google-Smtp-Source: AGHT+IF5ZHDt63zdyXLW6Zs/Jp904vDaPlOUCO3dMRciku/OnWILf9UyYpg15w7m7vgh9JrGFnoyKA== X-Received: by 2002:a05:6402:34d5:b0:5d0:e9b7:170c with SMTP id 4fb4d7f45d1cf-5d10cb5c39fmr1604224a12.18.1733217755400; Tue, 03 Dec 2024 01:22:35 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: Paolo Bonzini , =?UTF-8?q?Daniel=20P=20=2E=20Berrang=C3=A9?= , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org, Thomas Huth , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Subject: [PATCH 7/7] qemu-options: Remove mentions of legacy '-machine foo,accel=bar' Date: Tue, 3 Dec 2024 10:21:53 +0100 Message-ID: <20241203092153.60590-8-philmd@linaro.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20241203092153.60590-1-philmd@linaro.org> References: <20241203092153.60590-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Since commit 6f6e1698a68 ("vl: configure accelerators from -accel options") we prefer the '-accel bar' command line option. The new form started to be documented in commit 8d4e9146b35 ("tcg: add options for enabling MTTCG"); it is safe to remove the mentions of the legacy option. Signed-off-by: Philippe Mathieu-Daudé --- qemu-options.hx | 9 --------- 1 file changed, 9 deletions(-) diff --git a/qemu-options.hx b/qemu-options.hx index dacc9790a4b..11f0aab1470 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -27,8 +27,6 @@ ERST DEF("machine", HAS_ARG, QEMU_OPTION_machine, \ "-machine [type=]name[,prop[=value][,...]]\n" " selects emulated machine ('-machine help' for list)\n" - " property accel=accel1[:accel2[:...]] selects accelerator\n" - " supported accelerators are kvm, xen, hvf, nvmm, whpx or tcg (default: tcg)\n" " vmport=on|off|auto controls emulation of vmport (default: auto)\n" " dump-guest-core=on|off include guest memory in a core dump (default=on)\n" " mem-merge=on|off controls memory merge support (default: on)\n" @@ -59,13 +57,6 @@ SRST Supported machine properties are: - ``accel=accels1[:accels2[:...]]`` - This is used to enable an accelerator. Depending on the target - architecture, kvm, xen, hvf, nvmm, whpx or tcg can be available. - By default, tcg is used. If there is more than one accelerator - specified, the next one is used if the previous one fails to - initialize. - ``vmport=on|off|auto`` Enables emulation of VMWare IO port, for vmmouse etc. auto says to select the value based on accel and i8042. For accel=xen or -- 2.45.2 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:34:40 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:34:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847644.1262707 (Exim 4.92) (envelope-from ) id 1tIPIg-0003OK-Mm; Tue, 03 Dec 2024 09:34:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847644.1262707; Tue, 03 Dec 2024 09:34: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 1tIPIg-0003OD-KI; Tue, 03 Dec 2024 09:34:34 +0000 Received: by outflank-mailman (input) for mailman id 847644; Tue, 03 Dec 2024 09:34: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 1tIPIe-0003O5-P8 for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:34:32 +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 cb6b6f16-b159-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 10:34:30 +0100 (CET) Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-621-Felw6C6uNPC6Oa_d6tQmDA-1; Tue, 03 Dec 2024 04:34:26 -0500 Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B497B1945CB2; Tue, 3 Dec 2024 09:34:23 +0000 (UTC) Received: from redhat.com (unknown [10.42.28.37]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 10BCE1956054; Tue, 3 Dec 2024 09:34:19 +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: cb6b6f16-b159-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733218469; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IfaFyjHUCv5c9jS6dqEqYzXGE/sktBXnwnslhm1P5GU=; b=BTplj7Penr9yGfidmiC/wOQnRSb0GFQEYqIVLxI9ofyIok33If29nC9YOhI47Ov6o6odB9 cp4nCeuP2u6s/UMKJrewRYoG6j6uzZ3ds1kfQz4DIqBzz+zLEVQ3FNRaiZ3carEAjVgg+0 nwim1ECvs1NMMffE92xgJ8tZqq9JyJM= X-MC-Unique: Felw6C6uNPC6Oa_d6tQmDA-1 X-Mimecast-MFC-AGG-ID: Felw6C6uNPC6Oa_d6tQmDA Date: Tue, 3 Dec 2024 09:34:16 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= Cc: qemu-devel@nongnu.org, Paolo Bonzini , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org, Thomas Huth Subject: Re: [PATCH 1/7] tests/functional/test_ppc64_hv: Remove legacy '-machine foo,accel=bar' Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20241203092153.60590-1-philmd@linaro.org> <20241203092153.60590-2-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20241203092153.60590-2-philmd@linaro.org> User-Agent: Mutt/2.2.13 (2024-03-09) X-Scanned-By: MIMEDefang 3.0 on 10.30.177.40 On Tue, Dec 03, 2024 at 10:21:47AM +0100, Philippe Mathieu-Daudé wrote: > Since commit 6f6e1698a68 ("vl: configure accelerators from -accel > options") we prefer the '-accel bar' command line option. > > Replace '-machine foo,accel=bar' -> '-machine foo -accel bar' in > functional tests. > > Signed-off-by: Philippe Mathieu-Daudé > --- > tests/functional/test_ppc64_hv.py | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Reviewed-by: Daniel P. Berrangé With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:35:00 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:35:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847649.1262718 (Exim 4.92) (envelope-from ) id 1tIPJ5-0003pS-UF; Tue, 03 Dec 2024 09:34:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847649.1262718; Tue, 03 Dec 2024 09:34: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 1tIPJ5-0003pL-RI; Tue, 03 Dec 2024 09:34:59 +0000 Received: by outflank-mailman (input) for mailman id 847649; Tue, 03 Dec 2024 09:34: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 1tIPJ4-0003O5-PY for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:34:58 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id db4efc74-b159-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 10:34:57 +0100 (CET) Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-376-GoRi7I92Ofijny-Oqj7edg-1; Tue, 03 Dec 2024 04:34:50 -0500 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 508951944D1A; Tue, 3 Dec 2024 09:34:49 +0000 (UTC) Received: from redhat.com (unknown [10.42.28.37]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9D3481956052; Tue, 3 Dec 2024 09:34:46 +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: db4efc74-b159-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733218496; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WbCUJ3dVExYB6bKX4zWz/GsJygEsbgGFBQybZmklhPU=; b=PCg24Rf2vaAaRz0/4aBKHdDqIEIEspJtpqYXMTf1fayvvhSUeITA7+sbP04vBpoBg8eTjC Fuh26d3AnS3Ie3QOs+moLrzN0xre/BtzTl6pn11nIdPg+k9uFxTGSBm9tqXY2dqWWtUhhU gArISd0GbSgxjwvdkh4wOabO9MPPcYY= X-MC-Unique: GoRi7I92Ofijny-Oqj7edg-1 X-Mimecast-MFC-AGG-ID: GoRi7I92Ofijny-Oqj7edg Date: Tue, 3 Dec 2024 09:34:43 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= Cc: qemu-devel@nongnu.org, Paolo Bonzini , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org, Thomas Huth Subject: Re: [PATCH 2/7] tests/functional/test_virtio_gpu: Remove legacy '-machine foo,accel=bar' Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20241203092153.60590-1-philmd@linaro.org> <20241203092153.60590-3-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20241203092153.60590-3-philmd@linaro.org> User-Agent: Mutt/2.2.13 (2024-03-09) X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 On Tue, Dec 03, 2024 at 10:21:48AM +0100, Philippe Mathieu-Daudé wrote: > Since commit 6f6e1698a68 ("vl: configure accelerators from -accel > options") we prefer the '-accel bar' command line option. > > Replace '-machine foo,accel=bar' -> '-machine foo -accel bar' in > functional tests. > > Signed-off-by: Philippe Mathieu-Daudé > --- > tests/functional/test_virtio_gpu.py | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) Reviewed-by: Daniel P. Berrangé With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:36:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:36:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847658.1262728 (Exim 4.92) (envelope-from ) id 1tIPKB-0004QN-6N; Tue, 03 Dec 2024 09:36:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847658.1262728; Tue, 03 Dec 2024 09:36: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 1tIPKB-0004QG-3d; Tue, 03 Dec 2024 09:36:07 +0000 Received: by outflank-mailman (input) for mailman id 847658; Tue, 03 Dec 2024 09:36: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 1tIPK9-0004QA-V2 for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:36:05 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 02f9948f-b15a-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 10:36:03 +0100 (CET) Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-183-EJopHmXxOcyvUwsuY-hNew-1; Tue, 03 Dec 2024 04:36:01 -0500 Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id F1FBD19560AA; Tue, 3 Dec 2024 09:35:59 +0000 (UTC) Received: from redhat.com (unknown [10.42.28.37]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id DF25A1956054; Tue, 3 Dec 2024 09:35:57 +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: 02f9948f-b15a-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733218562; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rQBKPg7kKSDKtUpdcDIPkN150R6XVQZ1n4vXmPnwve0=; b=eUItAPBbXLt8SlAuXdDX+z++LhZOHgFZt9ZZ5BCzX9HfWGUISgLacWzk2qMwb7VoPkfuHE xYe5gtrcx5tqxubI9tfOp8tbf3IInK1KktrdE8I0T4b1bgCkwRZieTdlYhcHwgb+NZ5ILN zZYw0pSEBMRLblUqPkPt2tS6LQKjDUs= X-MC-Unique: EJopHmXxOcyvUwsuY-hNew-1 X-Mimecast-MFC-AGG-ID: EJopHmXxOcyvUwsuY-hNew Date: Tue, 3 Dec 2024 09:35:54 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= Cc: qemu-devel@nongnu.org, Paolo Bonzini , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org, Thomas Huth Subject: Re: [PATCH 3/7] tests/qtest/fuzz: Remove legacy '-machine foo,accel=bar' Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20241203092153.60590-1-philmd@linaro.org> <20241203092153.60590-4-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20241203092153.60590-4-philmd@linaro.org> User-Agent: Mutt/2.2.13 (2024-03-09) X-Scanned-By: MIMEDefang 3.0 on 10.30.177.40 On Tue, Dec 03, 2024 at 10:21:49AM +0100, Philippe Mathieu-Daudé wrote: > Since commit 6f6e1698a68 ("vl: configure accelerators from -accel > options") we prefer the '-accel bar' command line option. > > Replace '-machine foo,accel=bar' -> '-machine foo -accel bar' in > fuzzer scripts and tests. > > Signed-off-by: Philippe Mathieu-Daudé > --- > tests/qtest/fuzz/generic_fuzz.c | 2 +- > tests/qtest/fuzz/i440fx_fuzz.c | 2 +- > tests/qtest/fuzz/qos_fuzz.c | 2 +- > scripts/oss-fuzz/output_reproducer.py | 2 -- > scripts/oss-fuzz/reorder_fuzzer_qtest_trace.py | 6 +++--- > 5 files changed, 6 insertions(+), 8 deletions(-) Reviewed-by: Daniel P. Berrangé With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:38:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:38:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847674.1262738 (Exim 4.92) (envelope-from ) id 1tIPMR-000516-In; Tue, 03 Dec 2024 09:38:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847674.1262738; Tue, 03 Dec 2024 09:38:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIPMR-00050z-F4; Tue, 03 Dec 2024 09:38:27 +0000 Received: by outflank-mailman (input) for mailman id 847674; Tue, 03 Dec 2024 09:38: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 1tIPMQ-000508-IS for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:38:26 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 577e9ab9-b15a-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 10:38:25 +0100 (CET) Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-491-4W2OJDnoPW6sgWszQLdNtg-1; Tue, 03 Dec 2024 04:38:21 -0500 Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 001021944DD3; Tue, 3 Dec 2024 09:38:20 +0000 (UTC) Received: from redhat.com (unknown [10.42.28.37]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 1A4731956064; Tue, 3 Dec 2024 09:38: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: 577e9ab9-b15a-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733218704; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8ny4xWTBcN9ksCKY3sFHa4wfhsqLLtBnjJ3TxutDRXU=; b=L2C1G4sT01kd5upDvOmAo54MAfo8oMtpNhpRfKGfPcWBUNK3PmDK92zTnEWzSPIxlPSxiu PQ8tBUI07FYwOH727iyFzZhcO3estSeJrC6+/KDzxeW8wzFhuFnffMm0ELfG7YgXGrhwx7 yVqMxmljMUeHvxapdGzG6PLG/oy0ksg= X-MC-Unique: 4W2OJDnoPW6sgWszQLdNtg-1 X-Mimecast-MFC-AGG-ID: 4W2OJDnoPW6sgWszQLdNtg Date: Tue, 3 Dec 2024 09:38:13 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= Cc: qemu-devel@nongnu.org, Paolo Bonzini , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org, Thomas Huth Subject: Re: [PATCH 4/7] scripts/device-crash-test: Remove legacy '-machine foo,accel=bar' Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20241203092153.60590-1-philmd@linaro.org> <20241203092153.60590-5-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20241203092153.60590-5-philmd@linaro.org> User-Agent: Mutt/2.2.13 (2024-03-09) X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 On Tue, Dec 03, 2024 at 10:21:50AM +0100, Philippe Mathieu-Daudé wrote: > Since commit 6f6e1698a68 ("vl: configure accelerators from -accel > options") we prefer the '-accel bar' command line option. > > Replace '-machine foo,accel=bar' -> '-machine foo -accel bar' in > the device-crash-test script. > > Signed-off-by: Philippe Mathieu-Daudé > --- > scripts/device-crash-test | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/scripts/device-crash-test b/scripts/device-crash-test > index da8b56edd99..2b139e29ba0 100755 > --- a/scripts/device-crash-test > +++ b/scripts/device-crash-test > @@ -295,7 +295,10 @@ class QemuBinaryInfo(object): > self._machine_info = {} > > dbg("devtype: %r", devtype) > - args = ['-S', '-machine', 'none,accel=kvm:tcg'] > + args = ['-S', > + '-machine', 'none', > + '-accel', 'kvm:tcg', -accel doesn't work this way - that is legacy syntax sugar from -machine You need multiple args: -accel kvm -accel tcg > + ] > dbg("querying info for QEMU binary: %s", binary) > vm = QEMUMachine(binary=binary, args=args) > vm.launch() > @@ -358,7 +361,9 @@ def checkOneCase(args, testcase): > > dbg("will test: %r", testcase) > > - args = ['-S', '-machine', '%s,accel=%s' % (machine, accel), > + args = ['-S', > + '-machine', machine, > + '-accel', accel, I've not checked what 'accel' value is - if that's another compound value like 'kvm:tcg', it'll need to be turned into an array, and expanded to multiple '-accel' args. > '-device', qemuOptsEscape(device)] > cmdline = ' '.join([binary] + args) > dbg("will launch QEMU: %s", cmdline) > -- > 2.45.2 > With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:42:32 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:42:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847684.1262749 (Exim 4.92) (envelope-from ) id 1tIPQJ-00075d-2C; Tue, 03 Dec 2024 09:42:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847684.1262749; Tue, 03 Dec 2024 09:42:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIPQI-00075W-Tm; Tue, 03 Dec 2024 09:42:26 +0000 Received: by outflank-mailman (input) for mailman id 847684; Tue, 03 Dec 2024 09:42: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 1tIPQH-000749-Eq for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:42:25 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e5ca1ec9-b15a-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 10:42:24 +0100 (CET) Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-615-u3we_1XyN_2_r62U9GpjIQ-1; Tue, 03 Dec 2024 04:42:20 -0500 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id EE12F1954220; Tue, 3 Dec 2024 09:42:17 +0000 (UTC) Received: from redhat.com (unknown [10.42.28.37]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id CFF6719560A3; Tue, 3 Dec 2024 09:42: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: e5ca1ec9-b15a-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733218943; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FdOP4qqzg77tZ2HjGa/4x5tiYEmReqUm0KhFF1X4Y1Y=; b=Xh6FWSfVs9LHWCmg3a5RzmOdnD0+eD8tWJurBJs32mkMN19VYRs1lbvAFhvaYatc84X70z Ikv/usNtCMiTfjColAoW2g4S3msvXpaCHpx2U8J40ZpLaR0mu25+PO3iYqc0TjfRZVFJXO uDn7rGmcw9sB+xoWdqHdE8OOQ0FowcQ= X-MC-Unique: u3we_1XyN_2_r62U9GpjIQ-1 X-Mimecast-MFC-AGG-ID: u3we_1XyN_2_r62U9GpjIQ Date: Tue, 3 Dec 2024 09:42:09 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= Cc: qemu-devel@nongnu.org, Paolo Bonzini , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org, Thomas Huth Subject: Re: [PATCH 5/7] accel/tcg: Remove mentions of legacy '-machine foo,accel=bar' Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20241203092153.60590-1-philmd@linaro.org> <20241203092153.60590-6-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20241203092153.60590-6-philmd@linaro.org> User-Agent: Mutt/2.2.13 (2024-03-09) X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 On Tue, Dec 03, 2024 at 10:21:51AM +0100, Philippe Mathieu-Daudé wrote: > Since commit 6f6e1698a68 ("vl: configure accelerators from -accel > options") we prefer the '-accel bar' command line option. > > Update the documentation when TCG is referred to. > > Signed-off-by: Philippe Mathieu-Daudé > --- > docs/about/removed-features.rst | 2 +- > linux-user/s390x/target_proc.h | 2 +- > accel/tcg/monitor.c | 4 ++-- > system/vl.c | 2 +- > tests/qtest/qmp-cmd-test.c | 2 +- > 5 files changed, 6 insertions(+), 6 deletions(-) > diff --git a/system/vl.c b/system/vl.c > index 54998fdbc7e..c056fcb740c 100644 > --- a/system/vl.c > +++ b/system/vl.c > @@ -2385,7 +2385,7 @@ static void configure_accelerators(const char *progname) > for (tmp = accel_list; *tmp; tmp++) { > /* > * Filter invalid accelerators here, to prevent obscenities > - * such as "-machine accel=tcg,,thread=single". > + * such as "-accel tcg,,thread=single". > */ I'm not sure I understand what the old message was trying to archive, but at the same time I'm even less convinced it makes sense to change the comment. > if (accel_find(*tmp)) { > qemu_opts_parse_noisily(qemu_find_opts("accel"), *tmp, true); For all of the patch, except for that chunk above: Reviewed-by: Daniel P. Berrangé With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:43:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:43:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847691.1262758 (Exim 4.92) (envelope-from ) id 1tIPR1-0007mY-9g; Tue, 03 Dec 2024 09:43:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847691.1262758; Tue, 03 Dec 2024 09:43:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIPR1-0007mR-5q; Tue, 03 Dec 2024 09:43:11 +0000 Received: by outflank-mailman (input) for mailman id 847691; Tue, 03 Dec 2024 09:43: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 1tIPQz-0007Yh-MM for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:43:09 +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 fffb194a-b15a-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 10:43:08 +0100 (CET) Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-365-jUBPHpOAMHWdwhWg_maZJw-1; Tue, 03 Dec 2024 04:43:01 -0500 Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C3C591955D45; Tue, 3 Dec 2024 09:43:00 +0000 (UTC) Received: from redhat.com (unknown [10.42.28.37]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 8F78A1956089; Tue, 3 Dec 2024 09:42:57 +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: fffb194a-b15a-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733218987; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=I+JRUYnBGGGQCm69OO+rjh8nq3v9YjWxvZA969LR9Tw=; b=bSvTOInJMRaJVATcnvR5w6P950rAQULYJNM/G0mMxFmjmbxpTHyCWJOMRDLLugpgjSjWMu 1AuOkfKXIN4U/OYT5LDojwYyS5spJhsUCYLBSkNblp+HNwO+Lp+mY0AvgOjqzEk67gLpPy y7XuLO6/nbCQJcWzQE/U7PECg0YZzso= X-MC-Unique: jUBPHpOAMHWdwhWg_maZJw-1 X-Mimecast-MFC-AGG-ID: jUBPHpOAMHWdwhWg_maZJw Date: Tue, 3 Dec 2024 09:42:53 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= Cc: qemu-devel@nongnu.org, Paolo Bonzini , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org, Thomas Huth Subject: Re: [PATCH 6/7] accel/kvm: Remove mentions of legacy '-machine foo,accel=bar' Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20241203092153.60590-1-philmd@linaro.org> <20241203092153.60590-7-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20241203092153.60590-7-philmd@linaro.org> User-Agent: Mutt/2.2.13 (2024-03-09) X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 On Tue, Dec 03, 2024 at 10:21:52AM +0100, Philippe Mathieu-Daudé wrote: > Since commit 6f6e1698a68 ("vl: configure accelerators from -accel > options") we prefer the '-accel bar' command line option. > > Update the documentation when KVM is referred to. > > Signed-off-by: Philippe Mathieu-Daudé > --- > docs/bypass-iommu.txt | 3 ++- > docs/nvdimm.txt | 2 +- > docs/specs/tpm.rst | 2 +- > docs/system/arm/cpu-features.rst | 2 +- > docs/system/cpu-hotplug.rst | 2 +- > docs/system/ppc/powernv.rst | 2 +- > docs/system/ppc/pseries.rst | 4 ++-- > scripts/device-crash-test | 2 +- > 8 files changed, 10 insertions(+), 9 deletions(-) Reviewed-by: Daniel P. Berrangé With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:48:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:48:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847712.1262794 (Exim 4.92) (envelope-from ) id 1tIPW8-00017e-NC; Tue, 03 Dec 2024 09:48:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847712.1262794; Tue, 03 Dec 2024 09:48:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIPW8-00016g-FO; Tue, 03 Dec 2024 09:48:28 +0000 Received: by outflank-mailman (input) for mailman id 847712; Tue, 03 Dec 2024 09:48: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 1tIPW7-0000ZD-7Z for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:48:27 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id be0ba06c-b15b-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 10:48:26 +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 4D2221C25; Tue, 3 Dec 2024 01:48:54 -0800 (PST) Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BB68C3F58B; Tue, 3 Dec 2024 01: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: be0ba06c-b15b-11ef-a0d3-8be0dac302b0 From: Luca Fancellu To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Ross Lagerwall , Julien Grall Subject: [PATCH v4 3/5] xen/arm: Use vmap_contig instead of __vmap where it's possible Date: Tue, 3 Dec 2024 09:48:08 +0000 Message-Id: <20241203094811.427076-4-luca.fancellu@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241203094811.427076-1-luca.fancellu@arm.com> References: <20241203094811.427076-1-luca.fancellu@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently the arm code uses __vmap function in few parts to map physically contiguous pages, vmap_contig was introduced recently and does the same because it's a wrapper for __vmap, so use the latter instead of the direct __vmap function. Signed-off-by: Luca Fancellu Acked-by: Julien Grall Acked-by: Roger Pau Monné --- Changes from v2: - Add ack-by Roger Changes from v1: - Add ack-by Julien --- --- xen/arch/arm/alternative.c | 3 +-- xen/arch/arm/cpuerrata.c | 5 ++--- xen/arch/arm/kernel.c | 2 +- xen/arch/arm/livepatch.c | 3 +-- 4 files changed, 5 insertions(+), 8 deletions(-) diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c index d99b5070937d..fec7dbd2cde9 100644 --- a/xen/arch/arm/alternative.c +++ b/xen/arch/arm/alternative.c @@ -209,8 +209,7 @@ void __init apply_alternatives_all(void) * The text and inittext section are read-only. So re-map Xen to * be able to patch the code. */ - xenmap = __vmap(&xen_mfn, 1U << xen_order, 1, 1, PAGE_HYPERVISOR, - VMAP_DEFAULT); + xenmap = vmap_contig(xen_mfn, 1U << xen_order); /* Re-mapping Xen is not expected to fail during boot. */ BUG_ON(!xenmap); diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c index eef9c0ea0e21..17cf134f1b0d 100644 --- a/xen/arch/arm/cpuerrata.c +++ b/xen/arch/arm/cpuerrata.c @@ -61,9 +61,8 @@ static bool copy_hyp_vect_bpi(unsigned int slot, const char *hyp_vec_start, * Vectors are part of the text that are mapped read-only. So re-map * the vector table to be able to update vectors. */ - dst_remapped = __vmap(&dst_mfn, - 1UL << get_order_from_bytes(VECTOR_TABLE_SIZE), - 1, 1, PAGE_HYPERVISOR, VMAP_DEFAULT); + dst_remapped = vmap_contig(dst_mfn, + 1UL << get_order_from_bytes(VECTOR_TABLE_SIZE)); if ( !dst_remapped ) return false; diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c index 669d143cee1b..293d7efaed9c 100644 --- a/xen/arch/arm/kernel.c +++ b/xen/arch/arm/kernel.c @@ -211,7 +211,7 @@ static __init int kernel_decompress(struct bootmodule *mod, uint32_t offset) return -ENOMEM; } mfn = page_to_mfn(pages); - output = __vmap(&mfn, 1 << kernel_order_out, 1, 1, PAGE_HYPERVISOR, VMAP_DEFAULT); + output = vmap_contig(mfn, 1 << kernel_order_out); rc = perform_gunzip(output, input, size); clean_dcache_va_range(output, output_size); diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c index 037746d9528d..3805b2974663 100644 --- a/xen/arch/arm/livepatch.c +++ b/xen/arch/arm/livepatch.c @@ -39,8 +39,7 @@ int arch_livepatch_quiesce(void) * The text section is read-only. So re-map Xen to be able to patch * the code. */ - vmap_of_xen_text = __vmap(&text_mfn, 1U << text_order, 1, 1, PAGE_HYPERVISOR, - VMAP_DEFAULT); + vmap_of_xen_text = vmap_contig(text_mfn, 1U << text_order); if ( !vmap_of_xen_text ) { -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:48:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:48:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847710.1262773 (Exim 4.92) (envelope-from ) id 1tIPW6-0000cT-5N; Tue, 03 Dec 2024 09:48:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847710.1262773; Tue, 03 Dec 2024 09:48:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIPW6-0000bu-1Q; Tue, 03 Dec 2024 09:48:26 +0000 Received: by outflank-mailman (input) for mailman id 847710; Tue, 03 Dec 2024 09:48: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 1tIPW5-0000ZD-A3 for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:48:25 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id bc4a7fe0-b15b-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 10:48:23 +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 3E247143D; Tue, 3 Dec 2024 01:48:51 -0800 (PST) Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 337253F58B; Tue, 3 Dec 2024 01:48: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: bc4a7fe0-b15b-11ef-a0d3-8be0dac302b0 From: Luca Fancellu To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v4 1/5] common/vmap: Fall back to simple allocator when !HAS_VMAP Date: Tue, 3 Dec 2024 09:48:06 +0000 Message-Id: <20241203094811.427076-2-luca.fancellu@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241203094811.427076-1-luca.fancellu@arm.com> References: <20241203094811.427076-1-luca.fancellu@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit When HAS_VMAP is disabled, the xv{malloc,zalloc,...} functions should fall back to the simple x{malloc,zalloc,...} variant, implement that because MPU systems won't have virtual memory. Additionally remove VMAP_VIRT_START from vmap.h guards since MPU systems won't have it defined. Signed-off-by: Luca Fancellu --- Changes from v3: - use #define-s instead of static inline functions Changes from v2: - Don't protect declarations. Changes from v1: - put back static inline iounmap - changed commit message - hide not used declaration for system with !HAS_VMAP - correct function declared in xvmalloc.h to be static inline - prefer '#ifdef' instead of '#if defined' where possible --- --- xen/include/xen/vmap.h | 2 +- xen/include/xen/xvmalloc.h | 21 ++++++++++++++++----- 2 files changed, 17 insertions(+), 6 deletions(-) diff --git a/xen/include/xen/vmap.h b/xen/include/xen/vmap.h index c1dd7ac22f30..26c831757a11 100644 --- a/xen/include/xen/vmap.h +++ b/xen/include/xen/vmap.h @@ -5,7 +5,7 @@ * purpose area (VMAP_DEFAULT) and a livepatch-specific area (VMAP_XEN). The * latter is used when loading livepatches and the former for everything else. */ -#if !defined(__XEN_VMAP_H__) && defined(VMAP_VIRT_START) +#ifndef __XEN_VMAP_H__ #define __XEN_VMAP_H__ #include diff --git a/xen/include/xen/xvmalloc.h b/xen/include/xen/xvmalloc.h index 440d85a284bb..7686d49f8154 100644 --- a/xen/include/xen/xvmalloc.h +++ b/xen/include/xen/xvmalloc.h @@ -40,20 +40,31 @@ ((typeof(ptr))_xvrealloc(ptr, offsetof(typeof(*(ptr)), field[nr]), \ __alignof__(typeof(*(ptr))))) +#ifdef CONFIG_HAS_VMAP + /* Free any of the above. */ void xvfree(void *va); +/* Underlying functions */ +void *_xvmalloc(size_t size, unsigned int align); +void *_xvzalloc(size_t size, unsigned int align); +void *_xvrealloc(void *va, size_t size, unsigned int align); + +#else /* !CONFIG_HAS_VMAP */ + +#define xvfree xfree +#define _xvmalloc _xmalloc +#define _xvzalloc _xzalloc +#define _xvrealloc _xrealloc + +#endif /* CONFIG_HAS_VMAP */ + /* Free an allocation, and zero the pointer to it. */ #define XVFREE(p) do { \ xvfree(p); \ (p) = NULL; \ } while ( false ) -/* Underlying functions */ -void *_xvmalloc(size_t size, unsigned int align); -void *_xvzalloc(size_t size, unsigned int align); -void *_xvrealloc(void *va, size_t size, unsigned int align); - static inline void *_xvmalloc_array( size_t size, unsigned int align, unsigned long num) { -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:48:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:48:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847711.1262788 (Exim 4.92) (envelope-from ) id 1tIPW8-00014X-CR; Tue, 03 Dec 2024 09:48:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847711.1262788; Tue, 03 Dec 2024 09:48:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIPW8-00014O-8K; Tue, 03 Dec 2024 09:48:28 +0000 Received: by outflank-mailman (input) for mailman id 847711; Tue, 03 Dec 2024 09:48: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 1tIPW6-0000ZC-QG for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:48:26 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id bd469e41-b15b-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 10:48:25 +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 A13741BF3; Tue, 3 Dec 2024 01:48:52 -0800 (PST) Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 592C23F58B; Tue, 3 Dec 2024 01:48: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: bd469e41-b15b-11ef-99a3-01e77a169b0f From: Luca Fancellu To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Julien Grall Subject: [PATCH v4 2/5] arm/setup: Move MMU specific extern declarations to mmu/setup.h Date: Tue, 3 Dec 2024 09:48:07 +0000 Message-Id: <20241203094811.427076-3-luca.fancellu@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241203094811.427076-1-luca.fancellu@arm.com> References: <20241203094811.427076-1-luca.fancellu@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Move some extern declarations related to MMU structures and define from asm/setup.h to asm/mmu/setup.h, in order to increase encapsulation and allow the MPU part to build, since it has no clue about them. Signed-off-by: Luca Fancellu Acked-by: Julien Grall --- CHanges from v3: - add Ack-by Julien Changes from v1: - Moved extern to mmu/setup.h instead of mmu/mm.h - moved also pte_of_xenaddr() --- --- xen/arch/arm/include/asm/mmu/setup.h | 31 ++++++++++++++++++++++++++++ xen/arch/arm/include/asm/setup.h | 20 ++++++------------ 2 files changed, 37 insertions(+), 14 deletions(-) create mode 100644 xen/arch/arm/include/asm/mmu/setup.h diff --git a/xen/arch/arm/include/asm/mmu/setup.h b/xen/arch/arm/include/asm/mmu/setup.h new file mode 100644 index 000000000000..3fe752b04c63 --- /dev/null +++ b/xen/arch/arm/include/asm/mmu/setup.h @@ -0,0 +1,31 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +#ifndef __ARM_MMU_SETUP_H__ +#define __ARM_MMU_SETUP_H__ + +#include +#include + +extern lpae_t boot_pgtable[XEN_PT_LPAE_ENTRIES]; + +#ifdef CONFIG_ARM_64 +extern lpae_t boot_first[XEN_PT_LPAE_ENTRIES]; +extern lpae_t boot_first_id[XEN_PT_LPAE_ENTRIES]; +#endif +extern lpae_t boot_second[XEN_PT_LPAE_ENTRIES]; +extern lpae_t boot_second_id[XEN_PT_LPAE_ENTRIES]; +extern lpae_t boot_third[XEN_PT_LPAE_ENTRIES * XEN_NR_ENTRIES(2)]; +extern lpae_t boot_third_id[XEN_PT_LPAE_ENTRIES]; + +/* Find where Xen will be residing at runtime and return a PT entry */ +lpae_t pte_of_xenaddr(vaddr_t va); + +#endif /* __ARM_MMU_SETUP_H__ */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h index 64c227d171fc..a5a80d9b477f 100644 --- a/xen/arch/arm/include/asm/setup.h +++ b/xen/arch/arm/include/asm/setup.h @@ -6,6 +6,12 @@ #include #include +#if defined(CONFIG_MMU) +# include +#elif !defined(CONFIG_MPU) +# error "Unknown memory management layout" +#endif + #define MAX_FDT_SIZE SZ_2M struct map_range_data @@ -65,20 +71,6 @@ int map_irq_to_domain(struct domain *d, unsigned int irq, int map_range_to_domain(const struct dt_device_node *dev, uint64_t addr, uint64_t len, void *data); -extern lpae_t boot_pgtable[XEN_PT_LPAE_ENTRIES]; - -#ifdef CONFIG_ARM_64 -extern lpae_t boot_first[XEN_PT_LPAE_ENTRIES]; -extern lpae_t boot_first_id[XEN_PT_LPAE_ENTRIES]; -#endif -extern lpae_t boot_second[XEN_PT_LPAE_ENTRIES]; -extern lpae_t boot_second_id[XEN_PT_LPAE_ENTRIES]; -extern lpae_t boot_third[XEN_PT_LPAE_ENTRIES * XEN_NR_ENTRIES(2)]; -extern lpae_t boot_third_id[XEN_PT_LPAE_ENTRIES]; - -/* Find where Xen will be residing at runtime and return a PT entry */ -lpae_t pte_of_xenaddr(vaddr_t va); - extern const char __ro_after_init_start[], __ro_after_init_end[]; struct init_info -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:48:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:48:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847709.1262768 (Exim 4.92) (envelope-from ) id 1tIPW5-0000ZV-Ui; Tue, 03 Dec 2024 09:48:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847709.1262768; Tue, 03 Dec 2024 09:48: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 1tIPW5-0000ZO-Rj; Tue, 03 Dec 2024 09:48:25 +0000 Received: by outflank-mailman (input) for mailman id 847709; Tue, 03 Dec 2024 09:48: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 1tIPW4-0000ZC-W2 for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:48:24 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id bbc32b1b-b15b-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 10:48:22 +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 1B618FEC; Tue, 3 Dec 2024 01:48:50 -0800 (PST) Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 692173F58B; Tue, 3 Dec 2024 01:48:20 -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: bbc32b1b-b15b-11ef-99a3-01e77a169b0f From: Luca Fancellu To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Ross Lagerwall Subject: [PATCH v4 0/5] Prerequisite patches for R82 upstreaming Date: Tue, 3 Dec 2024 09:48:05 +0000 Message-Id: <20241203094811.427076-1-luca.fancellu@arm.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In this serie I've taken out patches from the R82 branch already in the ML[1] and some new patches I've done based on the current status of staging that will not impact the current Armv8-R earlyboot work. [1] https://patchwork.kernel.org/project/xen-devel/cover/20230626033443.2943270-1-Penny.Zheng@arm.com/ Changes between v2 and v3: - New patch - changes to previous patch are listed inside them Luca Fancellu (4): common/vmap: Fall back to simple allocator when !HAS_VMAP arm/setup: Move MMU specific extern declarations to mmu/setup.h xen/arm: Use vmap_contig instead of __vmap where it's possible xen/arm: Move setup_frametable_mappings to arm/mmu Penny Zheng (1): xen/arm: Check for Static Heap feature when freeing resources xen/arch/arm/alternative.c | 3 +- xen/arch/arm/arm32/mmu/mm.c | 4 +- xen/arch/arm/cpuerrata.c | 5 +-- xen/arch/arm/include/asm/mmu/setup.h | 31 ++++++++++++++ xen/arch/arm/include/asm/setup.h | 20 +++------ xen/arch/arm/kernel.c | 9 ++-- xen/arch/arm/livepatch.c | 3 +- xen/arch/arm/mm.c | 40 ------------------ xen/arch/arm/mmu/Makefile | 1 + xen/arch/arm/mmu/mm.c | 61 ++++++++++++++++++++++++++++ xen/arch/arm/mmu/setup.c | 8 +++- xen/arch/arm/setup.c | 27 ++++++------ xen/common/device-tree/bootfdt.c | 4 +- xen/common/device-tree/bootinfo.c | 2 +- xen/common/page_alloc.c | 5 +++ xen/include/xen/bootfdt.h | 1 - xen/include/xen/mm.h | 6 +++ xen/include/xen/vmap.h | 2 +- xen/include/xen/xvmalloc.h | 21 +++++++--- 19 files changed, 162 insertions(+), 91 deletions(-) create mode 100644 xen/arch/arm/include/asm/mmu/setup.h create mode 100644 xen/arch/arm/mmu/mm.c -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:48:31 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:48:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847713.1262809 (Exim 4.92) (envelope-from ) id 1tIPWB-0001dS-RJ; Tue, 03 Dec 2024 09:48:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847713.1262809; Tue, 03 Dec 2024 09:48:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIPWB-0001dL-LT; Tue, 03 Dec 2024 09:48:31 +0000 Received: by outflank-mailman (input) for mailman id 847713; Tue, 03 Dec 2024 09:48: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 1tIPWA-0000ZC-Ev for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:48:30 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id bf6655de-b15b-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 10:48:28 +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 36E4F1D70; Tue, 3 Dec 2024 01:48:56 -0800 (PST) Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 678D03F58B; Tue, 3 Dec 2024 01:48: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: bf6655de-b15b-11ef-99a3-01e77a169b0f From: Luca Fancellu To: xen-devel@lists.xenproject.org Cc: Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Jan Beulich , Penny Zheng , Wei Chen Subject: [PATCH v4 4/5] xen/arm: Check for Static Heap feature when freeing resources Date: Tue, 3 Dec 2024 09:48:09 +0000 Message-Id: <20241203094811.427076-5-luca.fancellu@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241203094811.427076-1-luca.fancellu@arm.com> References: <20241203094811.427076-1-luca.fancellu@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Penny Zheng If the Xen heap is statically configured in Device Tree, its size is definite, so only the defined memory shall be given to the boot allocator. Have a check where init_domheap_pages() is called which takes into account if static heap feature is used. Extract static_heap flag from init data bootinfo, as it will be needed after destroying the init data section, rename it to using_static_heap and use it to tell whether the Xen static heap feature is enabled. Signed-off-by: Penny Zheng Signed-off-by: Wei Chen Signed-off-by: Luca Fancellu --- Changes from v3: - Removed helper using_static_heap(), renamed static_heap variable to using_static_heap and simplified #ifdef-ary (Jan suggestion) Changes from v2: - Change xen_is_using_staticheap() to using_static_heap() - Move declaration of static_heap to xen/mm.h and import that in bootfdt.h - Reprased first part of the commit message Changes from v1: - moved static_heap to common/page_alloc.c - protect static_heap access with CONFIG_STATIC_MEMORY - update comment in arm/kernel.c kernel_decompress() --- --- xen/arch/arm/arm32/mmu/mm.c | 4 ++-- xen/arch/arm/kernel.c | 7 ++++--- xen/arch/arm/mmu/setup.c | 8 ++++++-- xen/arch/arm/setup.c | 27 ++++++++++++++------------- xen/common/device-tree/bootfdt.c | 4 +++- xen/common/device-tree/bootinfo.c | 2 +- xen/common/page_alloc.c | 5 +++++ xen/include/xen/bootfdt.h | 1 - xen/include/xen/mm.h | 6 ++++++ 9 files changed, 41 insertions(+), 23 deletions(-) diff --git a/xen/arch/arm/arm32/mmu/mm.c b/xen/arch/arm/arm32/mmu/mm.c index 063611412be0..0824d61323b5 100644 --- a/xen/arch/arm/arm32/mmu/mm.c +++ b/xen/arch/arm/arm32/mmu/mm.c @@ -199,7 +199,7 @@ void __init setup_mm(void) total_pages = ram_size >> PAGE_SHIFT; - if ( bootinfo.static_heap ) + if ( using_static_heap ) { const struct membanks *reserved_mem = bootinfo_get_reserved_mem(); @@ -246,7 +246,7 @@ void __init setup_mm(void) do { - e = bootinfo.static_heap ? + e = using_static_heap ? fit_xenheap_in_static_heap(pfn_to_paddr(xenheap_pages), MB(32)) : consider_modules(ram_start, ram_end, pfn_to_paddr(xenheap_pages), diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c index 293d7efaed9c..8270684246ea 100644 --- a/xen/arch/arm/kernel.c +++ b/xen/arch/arm/kernel.c @@ -244,10 +244,11 @@ static __init int kernel_decompress(struct bootmodule *mod, uint32_t offset) size += offset; /* - * Free the original kernel, update the pointers to the - * decompressed kernel + * In case Xen is not using the static heap feature, free the original + * kernel, update the pointers to the decompressed kernel */ - fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0); + if ( !using_static_heap ) + fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0); return 0; } diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c index 9664e85ee6c0..8c87649bc88e 100644 --- a/xen/arch/arm/mmu/setup.c +++ b/xen/arch/arm/mmu/setup.c @@ -341,8 +341,12 @@ void free_init_memory(void) if ( rc ) panic("Unable to remove the init section (rc = %d)\n", rc); - init_domheap_pages(pa, pa + len); - printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10); + if ( !using_static_heap ) + { + init_domheap_pages(pa, pa + len); + printk("Freed %ldkB init memory.\n", + (long)(__init_end-__init_begin) >> 10); + } } /** diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 2e27af4560a5..22ab342dc8f4 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -206,24 +206,25 @@ void __init discard_initial_modules(void) struct bootmodules *mi = &bootinfo.modules; int i; - for ( i = 0; i < mi->nr_mods; i++ ) + if ( !using_static_heap ) { - paddr_t s = mi->module[i].start; - paddr_t e = s + PAGE_ALIGN(mi->module[i].size); - - if ( mi->module[i].kind == BOOTMOD_XEN ) - continue; + for ( i = 0; i < mi->nr_mods; i++ ) + { + paddr_t s = mi->module[i].start; + paddr_t e = s + PAGE_ALIGN(mi->module[i].size); - if ( !mfn_valid(maddr_to_mfn(s)) || - !mfn_valid(maddr_to_mfn(e)) ) - continue; + if ( mi->module[i].kind == BOOTMOD_XEN ) + continue; - fw_unreserved_regions(s, e, init_domheap_pages, 0); - } + if ( !mfn_valid(maddr_to_mfn(s)) || + !mfn_valid(maddr_to_mfn(e)) ) + continue; - mi->nr_mods = 0; + fw_unreserved_regions(s, e, init_domheap_pages, 0); + } - remove_early_mappings(); + mi->nr_mods = 0; + } } /* Relocate the FDT in Xen heap */ diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c index fc93d86e8232..61ad24c3ddc8 100644 --- a/xen/common/device-tree/bootfdt.c +++ b/xen/common/device-tree/bootfdt.c @@ -410,7 +410,9 @@ static int __init process_chosen_node(const void *fdt, int node, if ( rc ) return rc; - bootinfo.static_heap = true; +#ifdef CONFIG_STATIC_MEMORY + using_static_heap = true; +#endif } printk("Checking for initrd in /chosen\n"); diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c index 0daf5e941a51..76d652c0de0b 100644 --- a/xen/common/device-tree/bootinfo.c +++ b/xen/common/device-tree/bootinfo.c @@ -407,7 +407,7 @@ void __init populate_boot_allocator(void) const struct membanks *reserved_mem = bootinfo_get_reserved_mem(); paddr_t s, e; - if ( bootinfo.static_heap ) + if ( using_static_heap ) { for ( i = 0 ; i < reserved_mem->nr_banks; i++ ) { diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 92abed6514b4..013a1057cc7c 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -165,6 +165,11 @@ #define PGT_TYPE_INFO_INITIALIZER 0 #endif +#ifdef CONFIG_STATIC_MEMORY +/* Flag saved when Xen is using the static heap feature */ +bool __ro_after_init using_static_heap; +#endif + unsigned long __read_mostly max_page; unsigned long __read_mostly total_pages; paddr_t __ro_after_init mem_hotplug; diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h index cea40ee11706..06c4a1023a9b 100644 --- a/xen/include/xen/bootfdt.h +++ b/xen/include/xen/bootfdt.h @@ -139,7 +139,6 @@ struct bootinfo { #ifdef CONFIG_STATIC_SHM struct shared_meminfo shmem; #endif - bool static_heap; }; #ifdef CONFIG_ACPI diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index d7dcf0f06330..88536e8132f5 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -72,6 +72,12 @@ struct page_info; +#ifdef CONFIG_STATIC_MEMORY +extern bool using_static_heap; +#else +#define using_static_heap false +#endif + void put_page(struct page_info *page); bool __must_check get_page(struct page_info *page, const struct domain *domain); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:48:34 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:48:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847714.1262818 (Exim 4.92) (envelope-from ) id 1tIPWE-0001wP-2r; Tue, 03 Dec 2024 09:48:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847714.1262818; Tue, 03 Dec 2024 09:48:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIPWD-0001wB-Vr; Tue, 03 Dec 2024 09:48:33 +0000 Received: by outflank-mailman (input) for mailman id 847714; Tue, 03 Dec 2024 09:48: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 1tIPWB-0000ZC-MD for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:48:31 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id c027a98b-b15b-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 10:48:29 +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 7976A1DB5; Tue, 3 Dec 2024 01:48:57 -0800 (PST) Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 503E83F58B; Tue, 3 Dec 2024 01:48: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: c027a98b-b15b-11ef-99a3-01e77a169b0f From: Luca Fancellu To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v4 5/5] xen/arm: Move setup_frametable_mappings to arm/mmu Date: Tue, 3 Dec 2024 09:48:10 +0000 Message-Id: <20241203094811.427076-6-luca.fancellu@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241203094811.427076-1-luca.fancellu@arm.com> References: <20241203094811.427076-1-luca.fancellu@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Move the current setup_frametable_mappings implementation to arm/mmu under a new file mm.c, this implementation depends on virtual memory and won't be used as it is for MPU systems. Take the occasion to fix code style issues related to the line length. Moved also frametable_virt_end since it is used only on MMU systems. Signed-off-by: Luca Fancellu --- Changes to v3: - changed SPDX to reflect original file Changes to v2: - New patch --- --- xen/arch/arm/mm.c | 40 ------------------------- xen/arch/arm/mmu/Makefile | 1 + xen/arch/arm/mmu/mm.c | 61 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 62 insertions(+), 40 deletions(-) create mode 100644 xen/arch/arm/mmu/mm.c diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index def939172cc5..a56e20ba2bdc 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -22,7 +22,6 @@ #define virt_to_mfn(va) _mfn(__virt_to_mfn(va)) unsigned long frametable_base_pdx __read_mostly; -unsigned long frametable_virt_end __read_mostly; void flush_page_to_ram(unsigned long mfn, bool sync_icache) { @@ -43,45 +42,6 @@ void flush_page_to_ram(unsigned long mfn, bool sync_icache) invalidate_icache(); } -/* Map a frame table to cover physical addresses ps through pe */ -void __init setup_frametable_mappings(paddr_t ps, paddr_t pe) -{ - unsigned long nr_pdxs = mfn_to_pdx(mfn_add(maddr_to_mfn(pe), -1)) - - mfn_to_pdx(maddr_to_mfn(ps)) + 1; - unsigned long frametable_size = nr_pdxs * sizeof(struct page_info); - mfn_t base_mfn; - const unsigned long mapping_size = frametable_size < MB(32) ? MB(2) : MB(32); - int rc; - - /* - * The size of paddr_t should be sufficient for the complete range of - * physical address. - */ - BUILD_BUG_ON((sizeof(paddr_t) * BITS_PER_BYTE) < PADDR_BITS); - BUILD_BUG_ON(sizeof(struct page_info) != PAGE_INFO_SIZE); - - if ( frametable_size > FRAMETABLE_SIZE ) - panic("The frametable cannot cover the physical region %#"PRIpaddr" - %#"PRIpaddr"\n", - ps, pe); - - frametable_base_pdx = mfn_to_pdx(maddr_to_mfn(ps)); - /* Round up to 2M or 32M boundary, as appropriate. */ - frametable_size = ROUNDUP(frametable_size, mapping_size); - base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 32<<(20-12)); - - rc = map_pages_to_xen(FRAMETABLE_VIRT_START, base_mfn, - frametable_size >> PAGE_SHIFT, - PAGE_HYPERVISOR_RW | _PAGE_BLOCK); - if ( rc ) - panic("Unable to setup the frametable mappings.\n"); - - memset(&frame_table[0], 0, nr_pdxs * sizeof(struct page_info)); - memset(&frame_table[nr_pdxs], -1, - frametable_size - (nr_pdxs * sizeof(struct page_info))); - - frametable_virt_end = FRAMETABLE_VIRT_START + (nr_pdxs * sizeof(struct page_info)); -} - int steal_page( struct domain *d, struct page_info *page, unsigned int memflags) { diff --git a/xen/arch/arm/mmu/Makefile b/xen/arch/arm/mmu/Makefile index 2cb44b857dd2..1c89602947de 100644 --- a/xen/arch/arm/mmu/Makefile +++ b/xen/arch/arm/mmu/Makefile @@ -1,3 +1,4 @@ +obj-y += mm.o obj-y += p2m.o obj-y += pt.o obj-y += setup.o diff --git a/xen/arch/arm/mmu/mm.c b/xen/arch/arm/mmu/mm.c new file mode 100644 index 000000000000..9c50479c6373 --- /dev/null +++ b/xen/arch/arm/mmu/mm.c @@ -0,0 +1,61 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ + +#include +#include +#include +#include +#include +#include +#include + +unsigned long frametable_virt_end __read_mostly; + +/* Map a frame table to cover physical addresses ps through pe */ +void __init setup_frametable_mappings(paddr_t ps, paddr_t pe) +{ + unsigned long nr_pdxs = mfn_to_pdx(mfn_add(maddr_to_mfn(pe), -1)) - + mfn_to_pdx(maddr_to_mfn(ps)) + 1; + unsigned long frametable_size = nr_pdxs * sizeof(struct page_info); + mfn_t base_mfn; + const unsigned long mapping_size = frametable_size < MB(32) ? MB(2) + : MB(32); + int rc; + + /* + * The size of paddr_t should be sufficient for the complete range of + * physical address. + */ + BUILD_BUG_ON((sizeof(paddr_t) * BITS_PER_BYTE) < PADDR_BITS); + BUILD_BUG_ON(sizeof(struct page_info) != PAGE_INFO_SIZE); + + if ( frametable_size > FRAMETABLE_SIZE ) + panic("The frametable cannot cover the physical region %#"PRIpaddr" - %#"PRIpaddr"\n", + ps, pe); + + frametable_base_pdx = mfn_to_pdx(maddr_to_mfn(ps)); + /* Round up to 2M or 32M boundary, as appropriate. */ + frametable_size = ROUNDUP(frametable_size, mapping_size); + base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 32<<(20-12)); + + rc = map_pages_to_xen(FRAMETABLE_VIRT_START, base_mfn, + frametable_size >> PAGE_SHIFT, + PAGE_HYPERVISOR_RW | _PAGE_BLOCK); + if ( rc ) + panic("Unable to setup the frametable mappings.\n"); + + memset(&frame_table[0], 0, nr_pdxs * sizeof(struct page_info)); + memset(&frame_table[nr_pdxs], -1, + frametable_size - (nr_pdxs * sizeof(struct page_info))); + + frametable_virt_end = FRAMETABLE_VIRT_START + (nr_pdxs * + sizeof(struct page_info)); +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:54:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:54:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847767.1262828 (Exim 4.92) (envelope-from ) id 1tIPby-0006A4-UL; Tue, 03 Dec 2024 09:54:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847767.1262828; Tue, 03 Dec 2024 09:54: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 1tIPby-00069x-RM; Tue, 03 Dec 2024 09:54:30 +0000 Received: by outflank-mailman (input) for mailman id 847767; Tue, 03 Dec 2024 09:54: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 1tIPbx-00069r-DD for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:54:29 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 94abc892-b15c-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 10:54:27 +0100 (CET) Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-19-YxXr4IOQPeeG_3ecYmygPg-1; Tue, 03 Dec 2024 04:54:22 -0500 Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 95DD5195608A; Tue, 3 Dec 2024 09:54:21 +0000 (UTC) Received: from redhat.com (unknown [10.42.28.37]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 39021195608A; Tue, 3 Dec 2024 09:54:18 +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: 94abc892-b15c-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733219666; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=l3VcSU2FOCO6z2TK0iPyybiLDyV7PIhM+xSHQeNdxLM=; b=bNgLo4E8dDfMZszR8H33xrDHzPEhzEcEUHhQp4/veQwmt6LxWsAlOeNXR1ddd1Ymhds1Mq QIxSsGteZgjOxhmdnh59hAkpslmqjluoJQBGGyDcS+oSP/PvShCPAPNIGD1W0TyEs2otlm DJH/BHsYaSPw2aFtpZ8UfQO0AC73k7g= X-MC-Unique: YxXr4IOQPeeG_3ecYmygPg-1 X-Mimecast-MFC-AGG-ID: YxXr4IOQPeeG_3ecYmygPg Date: Tue, 3 Dec 2024 09:54:15 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= Cc: qemu-devel@nongnu.org, Paolo Bonzini , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org, Thomas Huth Subject: Re: [PATCH 7/7] qemu-options: Remove mentions of legacy '-machine foo,accel=bar' Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20241203092153.60590-1-philmd@linaro.org> <20241203092153.60590-8-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20241203092153.60590-8-philmd@linaro.org> User-Agent: Mutt/2.2.13 (2024-03-09) X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 On Tue, Dec 03, 2024 at 10:21:53AM +0100, Philippe Mathieu-Daudé wrote: > Since commit 6f6e1698a68 ("vl: configure accelerators from -accel > options") we prefer the '-accel bar' command line option. > > The new form started to be documented in commit 8d4e9146b35 ("tcg: > add options for enabling MTTCG"); it is safe to remove the mentions > of the legacy option. > > Signed-off-by: Philippe Mathieu-Daudé > --- > qemu-options.hx | 9 --------- > 1 file changed, 9 deletions(-) > > diff --git a/qemu-options.hx b/qemu-options.hx > index dacc9790a4b..11f0aab1470 100644 > --- a/qemu-options.hx > +++ b/qemu-options.hx > @@ -27,8 +27,6 @@ ERST > DEF("machine", HAS_ARG, QEMU_OPTION_machine, \ > "-machine [type=]name[,prop[=value][,...]]\n" > " selects emulated machine ('-machine help' for list)\n" > - " property accel=accel1[:accel2[:...]] selects accelerator\n" > - " supported accelerators are kvm, xen, hvf, nvmm, whpx or tcg (default: tcg)\n" > " vmport=on|off|auto controls emulation of vmport (default: auto)\n" > " dump-guest-core=on|off include guest memory in a core dump (default=on)\n" > " mem-merge=on|off controls memory merge support (default: on)\n" > @@ -59,13 +57,6 @@ SRST > > Supported machine properties are: > > - ``accel=accels1[:accels2[:...]]`` > - This is used to enable an accelerator. Depending on the target > - architecture, kvm, xen, hvf, nvmm, whpx or tcg can be available. > - By default, tcg is used. If there is more than one accelerator > - specified, the next one is used if the previous one fails to > - initialize. > - I'm not convinced we should be removing documentation for options that currently exist and remain supported. The documentation should be updated to say that we prefer use of '-accel' instead at least. Beyond that, what is our long term intention with '-machine accel=xxx' ? Is this a case where we are happy to leave '-machine accel=' as syntax sugar forever ? Or is this a case where we want to deprecate it and eventually remove its impl (and thus the documention here) > ``vmport=on|off|auto`` > Enables emulation of VMWare IO port, for vmmouse etc. auto says > to select the value based on accel and i8042. For accel=xen or > -- > 2.45.2 > With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| From xen-devel-bounces@lists.xenproject.org Tue Dec 03 09:55:40 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 09:55:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847775.1262837 (Exim 4.92) (envelope-from ) id 1tIPd5-0006g6-6M; Tue, 03 Dec 2024 09:55:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847775.1262837; Tue, 03 Dec 2024 09: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 1tIPd5-0006fz-3Z; Tue, 03 Dec 2024 09:55:39 +0000 Received: by outflank-mailman (input) for mailman id 847775; Tue, 03 Dec 2024 09:55: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 1tIPd3-0006fp-8h for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 09:55:37 +0000 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on20631.outbound.protection.outlook.com [2a01:111:f403:2418::631]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id bdaa3dfe-b15c-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 10:55:35 +0100 (CET) Received: from SN7PR04CA0007.namprd04.prod.outlook.com (2603:10b6:806:f2::12) by DS0PR12MB7926.namprd12.prod.outlook.com (2603:10b6:8:14a::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 09:55:31 +0000 Received: from SA2PEPF0000150A.namprd04.prod.outlook.com (2603:10b6:806:f2:cafe::50) by SN7PR04CA0007.outlook.office365.com (2603:10b6:806:f2::12) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.18 via Frontend Transport; Tue, 3 Dec 2024 09:55:31 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by SA2PEPF0000150A.mail.protection.outlook.com (10.167.242.42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 09:55:31 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 3 Dec 2024 03:55:30 -0600 Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Tue, 3 Dec 2024 03:55:29 -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: bdaa3dfe-b15c-11ef-a0d3-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LeAtfbsb95Z2l/LyQthoiYgbZ5IyjHfgNWRLmKj0jHQG4EmaH6+WVPqfbbkMIbJ/hd1rcXCr1fD1uacLEbnPvXao5UstdpzEVqjSz4cqCRq8TQyKmtx/wURuxRi7d15ySYNOBym5x2wOjgkwdzPfdf6YTY1qtVIjwi7HWrs3GXknbCyVRnWf8uyvMSSgItvl1caljs2j3G59S+SpoR93i9tNcZMcTF92lwmHE9TSYvBaTYgJ100uOJjWO7IT+/JlY4ECc1YvqCGkvKoHBGhOZLLM486LvYx1UJKaTQ+HhfEUictnnOfe2BQeR4wPTVLGuNen5V4JmDWkLIZ1DM+zkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EhnB41Ioz2MUi+y44Vwy3ra2J8obH0cGcbZeRmuHc88=; b=gsE9xNfWXq09QfRDB+9lu1P+6Lgg7uQ/+pxZQrDW5QuC+f58LQKOqWnZ/kZk6RDDk+xTJ2kMIf7AOVnUWiFP3pZx5Dk2JP3GZy2aklmv29gnFvM1U/+lwvH/M8ONUyZHXuv4EYnIPTcG4/ZGbl99JN1Q69oAKTD7TT1KKCbUEaeqRVRcsaLgB/AVXrgasmNF/OHP+OP80fPDsyNWtjfznA+8lNmSJfdwI+LMQpNmec+sgYjB5yJEMu14WehiSnXHj1/k/mkh9vJQbIX04u5gX9iylDeMXix3HUciSX93L6lIqgFOUMEN2r06/i4t3l5phF8ZkXjN5D8aUwUFgFjYcw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=minervasys.tech smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EhnB41Ioz2MUi+y44Vwy3ra2J8obH0cGcbZeRmuHc88=; b=PQKJXo4+oVulXS3wxi/0VDltxe7ziMHyEmE3CRfJc8dBvrfW4Tom66Nc2G/9NMPepr57aZ72zCXeeSdAt5oxMtyURBqPX09sDs/OVVPWJ8ECN9pv+3OBRU78b+1zqutXz0ecgXohpXKMqGWRZ69Bi956v4WpFd2Wyb1RIdjsYMc= 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=SATLEXMB03.amd.com; pr=C Message-ID: Date: Tue, 3 Dec 2024 10:55:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 01/12] xen/common: add cache coloring common code To: Carlo Nonato , CC: , , Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> <20241202165921.249585-2-carlo.nonato@minervasys.tech> Content-Language: en-US From: Michal Orzel In-Reply-To: <20241202165921.249585-2-carlo.nonato@minervasys.tech> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA2PEPF0000150A:EE_|DS0PR12MB7926:EE_ X-MS-Office365-Filtering-Correlation-Id: 7f3c66e6-aa2e-40de-85fc-08dd13809fe0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?V0YxRWp5SGZrMEViQWpSRmN5RU5HUDdhZEJ4a3NVd1BlbVoxeEdla0JiOW0w?= =?utf-8?B?TC93NCtqNU5GbEdYYVp0Z1E4MVhLaytUNXphOWVLZGoxaGJHU3VWMlozand6?= =?utf-8?B?VWVWdzc0S0tHUG1zZjFVL0wrN0puWXFTYnNhNVJWYUFKTHBNZzZTLy9QY2Zt?= =?utf-8?B?NXhwajEzb3RyVTBuRm9XaHYra2tsTEFwbTF5TTNKaHY4MytpZnZSaW1RMllt?= =?utf-8?B?QjlLNjNpNDVwU0MyZm9yMXorSC9heUh4SlowNGx0UGRxdEdhbENxRVRsbmVY?= =?utf-8?B?ZE9jbFZNV3FkMVMxeTgrVFVacTVIUTF6LzFObGZuQzBOQk9YemdaZlNoRGFp?= =?utf-8?B?bmx0RStJSE1UZ1FFaTRQd1hOZmhFcFpPZkFJYnhMMWRLQStSdjhOTlc3a0cr?= =?utf-8?B?RW9XT1Fsc2hyNGtqUnFGc2RWc0dBUG1HZ1h4cHdzbEtIWjhCekw3cktQUVdx?= =?utf-8?B?Ulo3c0xBNjN5eEx2VUE4K2U0aUdvc1RxeWx4N256cDZLbU1LREF5dXZVTnFn?= =?utf-8?B?OC9BWXhhM2hZU21OOWRZcWJKOG01cC84U2NsbWNZUGswbHFHUENxSUorOEtN?= =?utf-8?B?dXRkL0JqdGhRaW92YzNxYnF4NjhkTWtFUGZiY0RBdHFlbHZDZFJRc2hVdVpX?= =?utf-8?B?T2M2cURBN0dYY3MrTUtvbWI0YzExTDVtYStDYnUxOWZpNWdEejZZL1dHUG93?= =?utf-8?B?eTJnWWFYSElDTkdPYVJPZloybm9yMzgzWGROcXU4WUp2ZTRiOU5SdTZ2b2hP?= =?utf-8?B?LzhERFI2VHF2N0FhY2xQZ09qQ3pPdWtKV1FKRkRGZ09UcjI3YkJ4T3VRYU5X?= =?utf-8?B?WE5sNCt2bzVzMzFFZXFod2pzenNMZlN0QkVJTlM0ZHhDbHdmdmQvNWJUYUla?= =?utf-8?B?SGdqVnB3aVk5cXcxNm9TcTNJMHZGVlV5b0tQS091TWFWQnN6QmFYbm1LeXdv?= =?utf-8?B?WHNyVS9ZUlQ4UUZySGs5OFBoTktSL0txOXI4Vmd6RXNTMjBQZ1Zxb3B6M2hN?= =?utf-8?B?K3NuUjZwYWw3R01TRnJxd1A3YzEwdjJ0K2s1UXNDa1c5aVFrNEdUS0liVnhV?= =?utf-8?B?U2NXaFRkMXdQOEI1WFpjWU5mc3lHTW5UK1o5QmlOR3JVK3YzWVhzTmFCTCtq?= =?utf-8?B?aUJrb2svRWxiRnMyUTg0YTI1V3AwUTJ0Z09KcU5HM2NVNk9TNWF2bUVXZkRy?= =?utf-8?B?VnR3THVubVAwQ2pMTFZWc1VybDQ1cXNySXZrUkFsMXFIYTRweTJYSTluT0xH?= =?utf-8?B?ZUwwaXBkZ3V1OUVObkZFWEowLzdEOEdaclp3b1E3b05lTHQrMFRZQ1pvaDBE?= =?utf-8?B?WjU4NVBGdVNKQ0Y3d0syWlpQN1AybzZWRDlTYVJicTV1ZGx6NTNlcG8rclgx?= =?utf-8?B?YmJGUWxjVlhSMXVoQmM2Qm1DVVpDQk83dkNaTDRwSlF5dUw3WGJBMisyeE5Y?= =?utf-8?B?YnZ1QThkYy9ZbVN5MTBmb1B2SFQ3RENvMXlmS29oeE5sK2N5TElMdDNLN2JW?= =?utf-8?B?aXJYblJRVXgrZkRkMWx0Mll1TjRWaXpJUUk0RDQyMTBsWnFRMTRKZmNkdjNC?= =?utf-8?B?UUQwWXpMQmJNR1pObm8ydkI1bkw5cS9aSE9RTEk1b0M5a0hCRSswM3Q3cEhI?= =?utf-8?B?c2hlckJzWHJJdUQxdHVueXhkOUlMT0h0OGVJU3daZFJPK2VEZ1JKRDc0RzE1?= =?utf-8?B?U2JUc3pwOFpNVUpyVDF2UFp0aHdZUEtydk9UUnpEcXc1U1luUWtmOXlwSmRF?= =?utf-8?B?NkFwanNveHhXRUthSU13ODVmZE9wYjRXamRtWkEvSnF5UkRSS1k2NWlKUWpP?= =?utf-8?B?eEhzODgxM1VvMzBsWGFKVlhTb2tYU1hiR0xPWjB1UUtZOVE3bUlkSDdCSkpo?= =?utf-8?B?MEREaldXZ0NWMVNjQ1IrcWZsWDVKcFluL0dvTU1CYzZSWmhHUlc4NzNwZEgy?= =?utf-8?Q?MhkCK+vDLunqUunP1L5tyCB5xcsjm7LG?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 09:55:31.4574 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7f3c66e6-aa2e-40de-85fc-08dd13809fe0 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=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SA2PEPF0000150A.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7926 On 02/12/2024 17:59, Carlo Nonato wrote: > > > Last Level Cache (LLC) coloring allows to partition the cache in smaller > chunks called cache colors. > > Since not all architectures can actually implement it, add a HAS_LLC_COLORING > Kconfig option. > LLC_COLORS_ORDER Kconfig option has a range maximum of 10 (2^10 = 1024) > because that's the number of colors that fit in a 4 KiB page when integers > are 4 bytes long. > > LLC colors are a property of the domain, so struct domain has to be extended. > > Based on original work from: Luca Miccio > > Signed-off-by: Carlo Nonato > Signed-off-by: Marco Solieri > Acked-by: Michal Orzel [...] > > +### llc-coloring (arm64) > +> `= ` > + > +> Default: `false` By default, it is disabled. If CONFIG_ is enabled but ... [...] > + * -1: not specified (disabled unless llc-size and llc-nr-ways present) the user doesn't specify any llc-* options, LLC feature should be disabled. In your case llc_coloring_enabled is -1 and due to 'if ( llc_coloring_enabled ... )' checks all around the code base, the LLC will be enabled even though it should not. You can either set it to 0 if (llc_coloring_enabled < 0) and other llc-* options have not been provided (this would require modifying this comment to provide different meaning depending on the context) or you could do sth like that: diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c index 2d6aed5fb4ac..560fe03aa86b 100644 --- a/xen/common/llc-coloring.c +++ b/xen/common/llc-coloring.c @@ -18,8 +18,10 @@ * 0: explicitly disabled through cmdline * 1: explicitly enabled through cmdline */ -int8_t __ro_after_init llc_coloring_enabled = -1; -boolean_param("llc-coloring", llc_coloring_enabled); +int8_t __init opt_llc_coloring = -1; +boolean_param("llc-coloring", opt_llc_coloring); + +bool __ro_after_init llc_coloring_enabled = false; static unsigned int __initdata llc_size; size_param("llc-size", llc_size); @@ -147,15 +149,17 @@ void __init llc_coloring_init(void) { unsigned int way_size, i; - if ( (llc_coloring_enabled < 0) && (llc_size && llc_nr_ways) ) + if ( (opt_llc_coloring < 0) && (llc_size && llc_nr_ways) ) { llc_coloring_enabled = true; way_size = llc_size / llc_nr_ways; } - else if ( !llc_coloring_enabled ) + else if ( !opt_llc_coloring ) return; else { + llc_coloring_enabled = true; + way_size = get_llc_way_size(); if ( !way_size ) panic("LLC probing failed and 'llc-size' or 'llc-nr-ways' missing\n"); I think that this would be better in terms of readability. ~Michal From xen-devel-bounces@lists.xenproject.org Tue Dec 03 10:00:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 10:00:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847793.1262847 (Exim 4.92) (envelope-from ) id 1tIPhm-0008HA-Mm; Tue, 03 Dec 2024 10:00:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847793.1262847; Tue, 03 Dec 2024 10:00: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 1tIPhm-0008H3-KB; Tue, 03 Dec 2024 10:00:30 +0000 Received: by outflank-mailman (input) for mailman id 847793; Tue, 03 Dec 2024 10:00: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 1tIPhk-0008Gx-N8 for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 10:00:28 +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 6b7dff4d-b15d-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 11:00:26 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-434a736518eso65873065e9.1 for ; Tue, 03 Dec 2024 02:00:26 -0800 (PST) Received: from [192.168.69.223] ([176.187.209.146]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-385db7f86dasm13053820f8f.66.2024.12.03.02.00.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Dec 2024 02:00: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: 6b7dff4d-b15d-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1733220026; x=1733824826; 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=Mou40D0ZjD2Lf1VQwRddwv9731DnFFHuY1Fb6AhznBU=; b=o8blNhYMuRBcst0NVK45hLRq16jOJK8RktWNYBc90oxEgzCO4pp7wx0f4+lTvR5RpH hqeYHWcMwDXnXYTKv8GPWgd93TjS2P1vxQlQ3czHZ+RIzXJYcjkY/bgF+J32d0tfvXpo rbWpx2mAErI5SW2mKVZdwL91zPXytVeqjI8uTqqjQ7DLPB9/s2EsFmukdEWO829Y/ABM 1tVEFscMIjQrkl/jmzjW/EK/b+BqeupOIcyDVni6QZhObxyeG7TMo+HuJfAmeluv9tMe P2Kxd/g4rbhCpGrathhEKvgukyoFyq4/M4iCXrS5wFw7vyZosjgk5fEzpUFCWXRxng/k jUBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733220026; x=1733824826; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Mou40D0ZjD2Lf1VQwRddwv9731DnFFHuY1Fb6AhznBU=; b=H+lbnRlr0Nk2qwgQUmfFYN2XB5/MkOPJgJAJbfFJ03028jQkAHFHH1p4lBJxr8p5y9 XWcRD5SbSdTJyttlWMzbln43Df5/kUg2IL9s5H3JFbErr3KQhev/t8EkPQxxgg9fEjHd aIs7liDZ20Rq1OKVwUkML3YyFGNGGScwIe2QQqE1aAUDo1leZi6P8yfcNyYtZKgA1xVg qLX07RZvezcJaD/Mp7jmHh4SVc+uBYBdwmmJkjDzGjPHNtLw13olV73sMrNdn6V61riF 9RD6g/rjQw5NY0xgtjNhuSgTfaSif/0FdwF3rufYVJjEA0NL9P7BpCp7HveRnRIbdhoC L/Zw== X-Forwarded-Encrypted: i=1; AJvYcCVDGCD9GMfmTTj7I4sMg8PCm6zvQpY+PUBzEgxbw1FPfCTbx/aQWd4b0LpIMji1JZ7qjy0xI0Rh3J0=@lists.xenproject.org X-Gm-Message-State: AOJu0YxoU3+Yb6W9yf+v1se3bTJGRNDEXxfl0ydb3U/kc/8MC/YeRNmY vxods/NNhwyEbVCGHM3c2etAI8tCHqX5FugdBuT00W1/1feAqBSoheX6lJws/ic= X-Gm-Gg: ASbGnctsHzPDjH5+RZXhzYj86Dnhh6yHUDNk4gTPM+C4+Peb+0a+59KDZXmjA0R3Eub 6KST+KfbSc9j8in95YDv2JJ+bOy/6qVBkZKBhi8VeHCjnYuC+sx5gQ90EOSPXM+ByhXrdCDNAE6 O6bYukpVtSzZ/i4lExGIe2Vn0cYgNWsx1mfDnAGaUShONx6MGuTYdErtvwjtqM9U220OQKn5tXl qWz3eeTw8WAKMyl3khUyMRF5tGbbuBuqJ8Z/cODCN/2dzTrJcMQx5GHaACVIBEIQw== X-Google-Smtp-Source: AGHT+IE9vxZfRp24W90RJX0+iLYHphI7Leo+DbgvnW1oVtIyTYr8wsT4fzpvKsL/PjdyubjEmCbDIQ== X-Received: by 2002:a05:6000:4024:b0:385:f062:c2d4 with SMTP id ffacd0b85a97d-385fd435560mr1562279f8f.37.1733220025994; Tue, 03 Dec 2024 02:00:25 -0800 (PST) Message-ID: <0ca2c3e9-2ea6-4cd1-9f97-56068b48d870@linaro.org> Date: Tue, 3 Dec 2024 11:00:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 7/7] qemu-options: Remove mentions of legacy '-machine foo,accel=bar' To: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= Cc: qemu-devel@nongnu.org, Paolo Bonzini , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org, Thomas Huth References: <20241203092153.60590-1-philmd@linaro.org> <20241203092153.60590-8-philmd@linaro.org> Content-Language: en-US From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/12/24 10:54, Daniel P. Berrangé wrote: > On Tue, Dec 03, 2024 at 10:21:53AM +0100, Philippe Mathieu-Daudé wrote: >> Since commit 6f6e1698a68 ("vl: configure accelerators from -accel >> options") we prefer the '-accel bar' command line option. >> >> The new form started to be documented in commit 8d4e9146b35 ("tcg: >> add options for enabling MTTCG"); it is safe to remove the mentions >> of the legacy option. >> >> Signed-off-by: Philippe Mathieu-Daudé >> --- >> qemu-options.hx | 9 --------- >> 1 file changed, 9 deletions(-) > I'm not convinced we should be removing documentation for options that > currently exist and remain supported. > > The documentation should be updated to say that we prefer use of '-accel' > instead at least. > > Beyond that, what is our long term intention with '-machine accel=xxx' ? > > Is this a case where we are happy to leave '-machine accel=' as syntax > sugar forever ? Or is this a case where we want to deprecate it and > eventually remove its impl (and thus the documention here) Right, we should deprecate and then remove. From xen-devel-bounces@lists.xenproject.org Tue Dec 03 10:08:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 10:08:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847804.1262858 (Exim 4.92) (envelope-from ) id 1tIPpY-0001vz-HC; Tue, 03 Dec 2024 10:08:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847804.1262858; Tue, 03 Dec 2024 10:08: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 1tIPpY-0001vs-Cg; Tue, 03 Dec 2024 10:08:32 +0000 Received: by outflank-mailman (input) for mailman id 847804; Tue, 03 Dec 2024 10:08: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 1tIPpW-0001vm-CJ for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 10:08:30 +0000 Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [2607:f8b0:4864:20::129]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8ab0c1eb-b15e-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 11:08:29 +0100 (CET) Received: by mail-il1-x129.google.com with SMTP id e9e14a558f8ab-3a7e104e500so13079325ab.0 for ; Tue, 03 Dec 2024 02:08: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: 8ab0c1eb-b15e-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1733220508; x=1733825308; 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=k+0kTlN11UW/7L1+9Pcc5O9w7zSu0yOYTwdiDBdyX/g=; b=ZWaLWNJqTOCUoUgxCJPGArRWYDQ2QbIAnrjZsC2pXmJgF06xlJ9a5Yhwdjcug3s+QR eCHdRtmPUUd57QuGi4BF/IbG+E9ic8HBQXH56+eFn84e3RuOnFhZwBfRiwdtyojDZu2R /B4CYJMTwTWBc6VlJxC+nm0c+zJeBYQXZfqK8g0nOswc1LSbwhXA/1iQVOoQhhxjmwjQ chGNAH5nzybaZqSJqXvcQzgsIQg4S0RCOLhsepEs10Bb2Dv7yRyWcJgvaXd/S2UejbqN fHOhWDMJM5oaJYJQGgfzhdeKfJ1fe9AEBB5jqZN9xj0aqYQbPUuCCmPWTbfBeZQ9tYWf pMng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733220508; x=1733825308; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=k+0kTlN11UW/7L1+9Pcc5O9w7zSu0yOYTwdiDBdyX/g=; b=puhYbjNIA0ViItVMyhr4Fx0jpU3WjvOP2tvvpwbCIs9QmCH77tBplulCkWeHNWsgNe 7XAtGhB7z++q3dv/re5wdvCYElwnPZG9pt47snqA4M7HnZ4Yn3lsTc7pG61W71KNndLZ CPpoOhKNXT2tICrkUZvjD1AvHL8lvZHKdPbHSYINmnZOQDUO0dKh4ISqJMXVE90LjS/h 4JONmA2mON523TNnQopIfau2LKpsU9QuOw5rh7/yHTNYuavBJY4WlnwqlZjA8qPpSDrv XjiHhNAqqvalAoNhxiliNjYXfA/B+2Xbf7rPm7ZPjEWXlJWWlSmMLKoSZt0fra1WOFy1 YwsQ== X-Gm-Message-State: AOJu0YyDSWBUxHnwwNt6Rw/iWI8/FNiEV5K9xUYgABYzDDqzpiNRiv13 oBBTMUuzTfClRf29Q5s8aCeDTG7fRTXmRy450kYkAaUR0VMp01pB9v4ucvxHXdHvBaX2ZT/L7zF 0GZCWNDIntAgZZZJYC0Pzbv82UJi89Q6LfPlosg== X-Gm-Gg: ASbGnctOr79mepp1EYpCmRPUBTDdYyHByXs6DFmLkaTUsIYpjphtAFlKnKn6bMbIz0e 3rH9DoOd8d+l1ixO213Cht0xcCGogG0Dz X-Google-Smtp-Source: AGHT+IFkJxDkrXMhanZvMzc/uppOczk89bn50k2YGZSyoSPbIWKeIy/zqCv3hurng8tTe+gUGS5R9L2FkaOB75yYCKo= X-Received: by 2002:a05:6602:2d81:b0:835:4d27:edf6 with SMTP id ca18e2360f4ac-8445b577027mr237018739f.7.1733220507812; Tue, 03 Dec 2024 02:08:27 -0800 (PST) MIME-Version: 1.0 References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> <20241202165921.249585-13-carlo.nonato@minervasys.tech> <800b0b49-e6c5-4a83-8ee6-d89d51613b0c@xen.org> In-Reply-To: <800b0b49-e6c5-4a83-8ee6-d89d51613b0c@xen.org> From: Carlo Nonato Date: Tue, 3 Dec 2024 11:08:17 +0100 Message-ID: Subject: Re: [PATCH v11 12/12] xen/arm: add cache coloring support for Xen image To: Julien Grall Cc: xen-devel@lists.xenproject.org, andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Jan Beulich Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Julien, On Mon, Dec 2, 2024 at 10:44=E2=80=AFPM Julien Grall wrote= : > > Hi Carlo, [...] > > diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c > > index 671eaadbc1..3732d5897e 100644 > > --- a/xen/arch/arm/arm64/mmu/mm.c > > +++ b/xen/arch/arm/arm64/mmu/mm.c > > @@ -1,6 +1,7 @@ > > /* SPDX-License-Identifier: GPL-2.0-only */ > > > > #include > > +#include > > #include > > #include > > > > @@ -138,27 +139,46 @@ void update_boot_mapping(bool enable) > > } > > > > extern void switch_ttbr_id(uint64_t ttbr); > > +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t l= en); > > > > typedef void (switch_ttbr_fn)(uint64_t ttbr); > > +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, si= ze_t len); > > > > void __init switch_ttbr(uint64_t ttbr) > > Given the change below, I think this function needs to be renamed. > Possibly to relocate_and_jump() with a comment explaning that the > relocation only happen for cache-coloring. Changing the name of switch_ttbr() to relocate_and_jump() seems a bit misleading to me. First I need to change the name also for arm32 where ther= e's no relocation at all. Second, relocation is something that happens conditionally so I don't think it's a good name for the function. [...] > Cheers, > > -- > Julien Grall Thanks. - Carlo From xen-devel-bounces@lists.xenproject.org Tue Dec 03 10:21:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 10:21:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847819.1262868 (Exim 4.92) (envelope-from ) id 1tIQ1Y-0005zi-LX; Tue, 03 Dec 2024 10:20:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847819.1262868; Tue, 03 Dec 2024 10:20: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 1tIQ1Y-0005zb-Ix; Tue, 03 Dec 2024 10:20:56 +0000 Received: by outflank-mailman (input) for mailman id 847819; Tue, 03 Dec 2024 10:20: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 1tIQ1X-0005yh-H5 for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 10:20:55 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4537cb7c-b160-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 11:20:51 +0100 (CET) Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-94-5o-kJoWZOi-tXhPZfYxmUg-1; Tue, 03 Dec 2024 05:20:48 -0500 Received: by mail-qk1-f197.google.com with SMTP id af79cd13be357-7b678f64ac9so851892485a.1 for ; Tue, 03 Dec 2024 02:20:48 -0800 (PST) Received: from [192.168.0.7] (ip-109-42-51-199.web.vodafone.de. [109.42.51.199]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7b684944f4asm496777385a.52.2024.12.03.02.20.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Dec 2024 02:20: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: 4537cb7c-b160-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733221250; 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:autocrypt:autocrypt; bh=YKWGDBbWazXWRRISTbTF1ZHM9e0Oj61kFvNUpJ5aQ5c=; b=CADZxIgjna0d3as1JXCmsXn46IyOnWm6LAMxtxB0yzzw36KSPIBXNExc8Bxn94/nH0FK0J fBx4RB2ys59Q3xtOsCJi1npXn5ccUhm5T07rTxNihpo09+A0lSFNDOf62FmqZ6pogQ549g LKEszuvOYK18AcjBw8CL8mZ7JSlvRnA= X-MC-Unique: 5o-kJoWZOi-tXhPZfYxmUg-1 X-Mimecast-MFC-AGG-ID: 5o-kJoWZOi-tXhPZfYxmUg X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733221248; x=1733826048; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=YKWGDBbWazXWRRISTbTF1ZHM9e0Oj61kFvNUpJ5aQ5c=; b=UvhgZcFq26JxM8qDwOYU8sokbwos4uxrcJpGpdedCOcZmbokUW5v5s2V3k+ndoXksi cljHG8tYmy8It8hJffIEoh/vxbZqSGuUwnGACG4TrHljfRAefPxhGPYTTNTMXaEWSGS6 gfm1YqTBJ3fIYuMO2MDwWpz7YFLnJTXf3nSpjOWYvt76I806229vlPqVcgkpty7gg+w9 l3HcA3Ss/Ags3l+RQKm/QbA5SpX0c4GwPKtXFUkgkxePT4eRXLlSqLDmEpkzq8CT/UDq Tk2eU5LPEcAlahPMWU5HbzTjPf8Bkgls2JG2K687DGYFd7jjmgWJxTexNhh7+O9Ub0pL vtSQ== X-Forwarded-Encrypted: i=1; AJvYcCVqahENswq+DZ5HCxk6nq1T1rJ2aVKTwdjtdVrteBvUYdLuMPXoVJpoeoQKxfLfatal3srFkTspLgc=@lists.xenproject.org X-Gm-Message-State: AOJu0YxBTb1rEEoPnjQuUiX5I2otD8O2RRvE1e8gbBxzH1hVJ/KgV2Zv eBA27qdj92dhFUsv+yxTkdVD1k8d6hqtVJKo5mlfnE9j9fHHem2SLw2SWfmqn2vlZM4y++F6AmG R2yMWt4P9BcY2vjQ/46SReb2Z52bS7vgjT+OQ0vfqgiA28TzVqj0UrHNiVrzr571m X-Gm-Gg: ASbGnctBwGMPw0AKXNZes9hF1T5bOKaOXrtWnId3dDoXovICNregGl5k46lFCMXRMLK WZ0MrV7f4ZPSN5prhh71JtuRmZxI5oexh/rzLDoaqqchpzmC+CNnvbgYGzupW8NmQua1cylvK8+ 0PFEyOWdjdcKwVEAly4/KaRBgSLHw8FKbmGA/mE/406XgV7+xNShDMH92rFd24NvfmSaJpfSyWM sERjcD0SYAY5s/sUOJBdqVe6n3nh6xbeugWe8G9c+2YRKBVBTBmFx89J0vjjHd4QlA6ioUwmU6i ti4T4Q== X-Received: by 2002:a05:620a:4622:b0:7b6:7030:5125 with SMTP id af79cd13be357-7b6a671c791mr271864785a.21.1733221248411; Tue, 03 Dec 2024 02:20:48 -0800 (PST) X-Google-Smtp-Source: AGHT+IGmVZ3ON9eIn5dL8E5BQTHAgs0mmQUW6ex3+h04ZvNnq/PhqrDf+t126oQ7tGNKj/ag+YHQzw== X-Received: by 2002:a05:620a:4622:b0:7b6:7030:5125 with SMTP id af79cd13be357-7b6a671c791mr271862685a.21.1733221248125; Tue, 03 Dec 2024 02:20:48 -0800 (PST) Message-ID: <94358073-193a-40f1-b625-8722a9de8b29@redhat.com> Date: Tue, 3 Dec 2024 11:20:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/7] tests/functional/test_ppc64_hv: Remove legacy '-machine foo,accel=bar' To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= , qemu-devel@nongnu.org Cc: Paolo Bonzini , =?UTF-8?Q?Daniel_P_=2E_Berrang=C3=A9?= , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org References: <20241203092153.60590-1-philmd@linaro.org> <20241203092153.60590-2-philmd@linaro.org> From: Thomas Huth Autocrypt: addr=thuth@redhat.com; keydata= xsFNBFH7eUwBEACzyOXKU+5Pcs6wNpKzrlJwzRl3VGZt95VCdb+FgoU9g11m7FWcOafrVRwU yYkTm9+7zBUc0sW5AuPGR/dp3pSLX/yFWsA/UB4nJsHqgDvDU7BImSeiTrnpMOTXb7Arw2a2 4CflIyFqjCpfDM4MuTmzTjXq4Uov1giGE9X6viNo1pxyEpd7PanlKNnf4PqEQp06X4IgUacW tSGj6Gcns1bCuHV8OPWLkf4hkRnu8hdL6i60Yxz4E6TqlrpxsfYwLXgEeswPHOA6Mn4Cso9O 0lewVYfFfsmokfAVMKWzOl1Sr0KGI5T9CpmRfAiSHpthhHWnECcJFwl72NTi6kUcUzG4se81 O6n9d/kTj7pzTmBdfwuOZ0YUSqcqs0W+l1NcASSYZQaDoD3/SLk+nqVeCBB4OnYOGhgmIHNW 0CwMRO/GK+20alxzk//V9GmIM2ACElbfF8+Uug3pqiHkVnKqM7W9/S1NH2qmxB6zMiJUHlTH gnVeZX0dgH27mzstcF786uPcdEqS0KJuxh2kk5IvUSL3Qn3ZgmgdxBMyCPciD/1cb7/Ahazr 3ThHQXSHXkH/aDXdfLsKVuwDzHLVSkdSnZdt5HHh75/NFHxwaTlydgfHmFFwodK8y/TjyiGZ zg2Kje38xnz8zKn9iesFBCcONXS7txENTzX0z80WKBhK+XSFJwARAQABzR5UaG9tYXMgSHV0 aCA8dGh1dGhAcmVkaGF0LmNvbT7CwXgEEwECACIFAlVgX6oCGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAAoJEC7Z13T+cC21EbIP/ii9cvT2HHGbFRl8HqGT6+7Wkb+XLMqJBMAIGiQK QIP3xk1HPTsLfVG0ao4hy/oYkGNOP8+ubLnZen6Yq3zAFiMhQ44lvgigDYJo3Ve59gfe99KX EbtB+X95ODARkq0McR6OAsPNJ7gpEUzfkQUUJTXRDQXfG/FX303Gvk+YU0spm2tsIKPl6AmV 1CegDljzjycyfJbk418MQmMu2T82kjrkEofUO2a24ed3VGC0/Uz//XCR2ZTo+vBoBUQl41BD eFFtoCSrzo3yPFS+w5fkH9NT8ChdpSlbNS32NhYQhJtr9zjWyFRf0Zk+T/1P7ECn6gTEkp5k ofFIA4MFBc/fXbaDRtBmPB0N9pqTFApIUI4vuFPPO0JDrII9dLwZ6lO9EKiwuVlvr1wwzsgq zJTPBU3qHaUO4d/8G+gD7AL/6T4zi8Jo/GmjBsnYaTzbm94lf0CjXjsOX3seMhaE6WAZOQQG tZHAO1kAPWpaxne+wtgMKthyPLNwelLf+xzGvrIKvLX6QuLoWMnWldu22z2ICVnLQChlR9d6 WW8QFEpo/FK7omuS8KvvopFcOOdlbFMM8Y/8vBgVMSsK6fsYUhruny/PahprPbYGiNIhKqz7 UvgyZVl4pBFjTaz/SbimTk210vIlkDyy1WuS8Zsn0htv4+jQPgo9rqFE4mipJjy/iboDzsFN BFH7eUwBEAC2nzfUeeI8dv0C4qrfCPze6NkryUflEut9WwHhfXCLjtvCjnoGqFelH/PE9NF4 4VPSCdvD1SSmFVzu6T9qWdcwMSaC+e7G/z0/AhBfqTeosAF5XvKQlAb9ZPkdDr7YN0a1XDfa +NgA+JZB4ROyBZFFAwNHT+HCnyzy0v9Sh3BgJJwfpXHH2l3LfncvV8rgFv0bvdr70U+On2XH 5bApOyW1WpIG5KPJlDdzcQTyptOJ1dnEHfwnABEfzI3dNf63rlxsGouX/NFRRRNqkdClQR3K gCwciaXfZ7ir7fF0u1N2UuLsWA8Ei1JrNypk+MRxhbvdQC4tyZCZ8mVDk+QOK6pyK2f4rMf/ WmqxNTtAVmNuZIwnJdjRMMSs4W4w6N/bRvpqtykSqx7VXcgqtv6eqoDZrNuhGbekQA0sAnCJ VPArerAZGArm63o39me/bRUQeQVSxEBmg66yshF9HkcUPGVeC4B0TPwz+HFcVhheo6hoJjLq knFOPLRj+0h+ZL+D0GenyqD3CyuyeTT5dGcNU9qT74bdSr20k/CklvI7S9yoQje8BeQAHtdV cvO8XCLrpGuw9SgOS7OP5oI26a0548M4KldAY+kqX6XVphEw3/6U1KTf7WxW5zYLTtadjISB X9xsRWSU+Yqs3C7oN5TIPSoj9tXMoxZkCIHWvnqGwZ7JhwARAQABwsFfBBgBAgAJBQJR+3lM AhsMAAoJEC7Z13T+cC21hPAQAIsBL9MdGpdEpvXs9CYrBkd6tS9mbaSWj6XBDfA1AEdQkBOn ZH1Qt7HJesk+qNSnLv6+jP4VwqK5AFMrKJ6IjE7jqgzGxtcZnvSjeDGPF1h2CKZQPpTw890k fy18AvgFHkVk2Oylyexw3aOBsXg6ukN44vIFqPoc+YSU0+0QIdYJp/XFsgWxnFIMYwDpxSHS 5fdDxUjsk3UBHZx+IhFjs2siVZi5wnHIqM7eK9abr2cK2weInTBwXwqVWjsXZ4tq5+jQrwDK cvxIcwXdUTLGxc4/Z/VRH1PZSvfQxdxMGmNTGaXVNfdFZjm4fz0mz+OUi6AHC4CZpwnsliGV ODqwX8Y1zic9viSTbKS01ZNp175POyWViUk9qisPZB7ypfSIVSEULrL347qY/hm9ahhqmn17 Ng255syASv3ehvX7iwWDfzXbA0/TVaqwa1YIkec+/8miicV0zMP9siRcYQkyTqSzaTFBBmqD oiT+z+/E59qj/EKfyce3sbC9XLjXv3mHMrq1tKX4G7IJGnS989E/fg6crv6NHae9Ckm7+lSs IQu4bBP2GxiRQ+NV3iV/KU3ebMRzqIC//DCOxzQNFNJAKldPe/bKZMCxEqtVoRkuJtNdp/5a yXFZ6TfE1hGKrDBYAm4vrnZ4CXFSBDllL59cFFOJCkn4Xboj/aVxxJxF30bn In-Reply-To: <20241203092153.60590-2-philmd@linaro.org> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: gJIOwyJbyTXIFFV5SaL3n3QiHViFphgZ9dJX53RW4KU_1733221248 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 03/12/2024 10.21, Philippe Mathieu-Daudé wrote: > Since commit 6f6e1698a68 ("vl: configure accelerators from -accel > options") we prefer the '-accel bar' command line option. > > Replace '-machine foo,accel=bar' -> '-machine foo -accel bar' in > functional tests. > > Signed-off-by: Philippe Mathieu-Daudé > --- > tests/functional/test_ppc64_hv.py | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/tests/functional/test_ppc64_hv.py b/tests/functional/test_ppc64_hv.py > index 312248bbfe4..536a433b993 100755 > --- a/tests/functional/test_ppc64_hv.py > +++ b/tests/functional/test_ppc64_hv.py > @@ -138,7 +138,8 @@ def do_test_kvm(self, hpt=False): > else: > append = '' > exec_command(self, 'qemu-system-ppc64 -nographic -smp 2 -m 1g ' > - '-machine pseries,x-vof=on,accel=kvm ' > + '-accel kvm ' > + '-machine pseries,x-vof=on ' > '-machine cap-cfpc=broken,cap-sbbc=broken,' > 'cap-ibs=broken,cap-ccf-assist=off ' > '-drive file=/dev/nvme0n1,format=raw,readonly=on ' Reviewed-by: Thomas Huth From xen-devel-bounces@lists.xenproject.org Tue Dec 03 10:23:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 10:23:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847827.1262878 (Exim 4.92) (envelope-from ) id 1tIQ4E-0007XH-49; Tue, 03 Dec 2024 10:23:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847827.1262878; Tue, 03 Dec 2024 10:23: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 1tIQ4E-0007Wa-12; Tue, 03 Dec 2024 10:23:42 +0000 Received: by outflank-mailman (input) for mailman id 847827; Tue, 03 Dec 2024 10:23: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 1tIQ4C-0007WU-FN for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 10:23:40 +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 a9b5be80-b160-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 11:23:39 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-385e1721716so1969843f8f.3 for ; Tue, 03 Dec 2024 02:23: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 ffacd0b85a97d-385e2716cedsm10231480f8f.38.2024.12.03.02.23.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Dec 2024 02:23:38 -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: a9b5be80-b160-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733221419; x=1733826219; 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=s9mJzrQ656d1QIixiQ7zVRy6sfzjK+3fk+YEJqEfkuo=; b=FIl4Mm/2gzVikVpkM41AM2vcIqChAciHOFw+0/e2UiDnCkiJVMHfafgNRm/FMigvED 51FgWYwwNiqkSILZ3nTjfLYvqEp3nvjTHJV8l8NKtCVKK/k4/imcouFuc/IsabWl6vy4 2zceMOEOrBKyI7858odq3BWu+v3vlsseflxmj24c/A1DnrNLQz2F+ly58fQzJ6xp/8z9 Wtk0O+0okQAhU2Xt2L69inZAAVs6bkLr/flGVBZhmsPdU+o2CnoNtWzbBcE06/BP5Kxq p0pdqWN1IY2xyl7EH0feo57CY5G+U5nuEOM2htFTu7/0GijgDPRtK47FmmQwCTub5hjh YdKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733221419; x=1733826219; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=s9mJzrQ656d1QIixiQ7zVRy6sfzjK+3fk+YEJqEfkuo=; b=pp2kooe/bu3tDPRzNQEvuNpvN8uQmiqqTQljxN20qhOlKKHYaZjpRCrQJEUcLktQ/B 3JwSGuzCrvLfETCKyo9ts3jLhOJeH/uMPyjLttMTf1gh0EJvyQP8MP7R6vqAMXGYVeiM m0tboNMDmi7YfLiNyXxKAtBSxE+fnhw6hbedb6IVL0yGcw9oT0VBMGUScp/bCFbUsjt0 FW9bwTGbZ5gHn43b+bNQxi5g4Gpohft0c4XwAwJz1+2F+IO004TiKiAHcYPj2iUrzpn8 OXfSVIjA/JRjUk4FRPAV1w+pEnQE/6v3CCjlgxneh/ZqXKcGzhMwMHNznxR3COyeHqY5 wnXQ== X-Forwarded-Encrypted: i=1; AJvYcCWTw8JHMSRsp/h3ozK3r7D8WsgEKoQ8kAruAoAx1PFbnIfl0baKPjPL/HKudNWLXxcfRTEe6kifjeA=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz7Na+dn9hoy0taAAMeivjvzKNwVFfh4+YWtvn7zk/3buyNisPu KntVLKqflKy4hxmuULqLg19nryeY1dTO3RWri2L6NLESdcAImFaOOtw2aD2XZA== X-Gm-Gg: ASbGncsuGHxbJ+86KpzCVHiUNNCkPeaKd9CLPMvvP46PFWvxWDfbnXrh0vl2QzKTUaM /tzCAlF6PBzU5fMVO7stnRjMZPaUbUeVlnltJrqAisZCTGAC8MUa4nV9rOW4OBIhhNDpn6jGtok 07QcNaGyj8X2y96wpEPis+OvlZDj0YCubK8x/0ckP0v0Ldc/VktwHA/MDZ3GfTm87Lo76+gj3AK 5riet3dAW/raqeCuxYtCOD9F5kKDqZ9hAu5cW+zBW7R3/QOvf9fGmqnZYzxD9s5iCJDNolqDOJT crCpCP07YzVPhQbfXJpDWKXN2Km9D6RqKp8= X-Google-Smtp-Source: AGHT+IHFBWHFExpDYW3Ocxe/Ua0eJeCYaS5d0IvuRviGcImSUX6mfD4n7Vxb5NKU25d5PyU4gjxgZQ== X-Received: by 2002:a05:6000:1fae:b0:385:fa3d:19c6 with SMTP id ffacd0b85a97d-385fd419e15mr1581448f8f.38.1733221419040; Tue, 03 Dec 2024 02:23:39 -0800 (PST) Message-ID: <54ac1d03-3dc1-49a5-9cd8-da544a0139a6@suse.com> Date: Tue, 3 Dec 2024 11:23:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/5] common/vmap: Fall back to simple allocator when !HAS_VMAP To: Luca Fancellu Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20241203094811.427076-1-luca.fancellu@arm.com> <20241203094811.427076-2-luca.fancellu@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: <20241203094811.427076-2-luca.fancellu@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 03.12.2024 10:48, Luca Fancellu wrote: > When HAS_VMAP is disabled, the xv{malloc,zalloc,...} functions > should fall back to the simple x{malloc,zalloc,...} variant, > implement that because MPU systems won't have virtual memory. > > Additionally remove VMAP_VIRT_START from vmap.h guards since > MPU systems won't have it defined. > > Signed-off-by: Luca Fancellu Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Dec 03 10:23:48 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 10:23:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847829.1262888 (Exim 4.92) (envelope-from ) id 1tIQ4K-0007qI-BM; Tue, 03 Dec 2024 10:23:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847829.1262888; Tue, 03 Dec 2024 10:23:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIQ4K-0007qB-8C; Tue, 03 Dec 2024 10:23:48 +0000 Received: by outflank-mailman (input) for mailman id 847829; Tue, 03 Dec 2024 10:23: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 1tIQ4I-0007oa-IP for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 10:23:46 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ac4976ed-b160-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 11:23:44 +0100 (CET) Received: from mail-yw1-f199.google.com (mail-yw1-f199.google.com [209.85.128.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-594-pNdf7GLvNait0MZc-Mskig-1; Tue, 03 Dec 2024 05:23:40 -0500 Received: by mail-yw1-f199.google.com with SMTP id 00721157ae682-6ef7c67eeb8so41018527b3.3 for ; Tue, 03 Dec 2024 02:23:40 -0800 (PST) Received: from [192.168.0.7] (ip-109-42-51-199.web.vodafone.de. [109.42.51.199]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6d87fe890a3sm53397756d6.29.2024.12.03.02.23.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Dec 2024 02:23: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: ac4976ed-b160-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733221423; 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:autocrypt:autocrypt; bh=kmyxVJ+YUkcgpMOIJZRmGj3gv31AXTUXR3Mg+4OB2T0=; b=dwlktHBupXvfVnzHUbOVNwXSA0UKg3dv1c6lWCuw5sfp9Pu/Oww2b+ag85Ikjp/HbEPBJ5 DC9cVlE9eHwB1DYEbn9dKieaYPEM5J+3toH8hoMYoEE5XKkMYqGRNyiReDCOs2S0C1XeVA 8JS4mVuLyv0LTkf2WciQCyU0Pqh8UEs= X-MC-Unique: pNdf7GLvNait0MZc-Mskig-1 X-Mimecast-MFC-AGG-ID: pNdf7GLvNait0MZc-Mskig X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733221420; x=1733826220; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kmyxVJ+YUkcgpMOIJZRmGj3gv31AXTUXR3Mg+4OB2T0=; b=jlYaogiasyZDpaiV1qi+REsK4+3K13lyKqXNdZzWWSh6HhXbDM/4ch5OkHVXAKOXuS VHqbiagIdbhUluEkttlfp8ZathH9AMkyGOu9ckaJxqcHEobNrgYKawA8uVqy1vzX/TGK wixj8uz/hrzsylDfFlhWmbSauDAHHOuxoWLBY1JWr18yL11xr/+83Fv+vo7eDfympxlN cIJB3RJRuXxMi/+ehytBgRLMcQrNRnNU+XijrhfJMFTDrC0J6KDn/w/2vEZpLe8iO2wY dAEcI4f2mBFoDn+IxtmBPTf8kM58cV3m44wcVBR0TLtMcZDB53b59V/E/MH+SUeylwZe sYtg== X-Forwarded-Encrypted: i=1; AJvYcCVCGIh6OBh2dCZJ8q5DdPIi8H76fJMWohQDIonR7R9T5jqMZlkBnQ7tkMMA6YQFX+JrOeY/xBzq4PI=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw6pyAFllDt2Nl6iCIZz0I5H1MF8fFxZUwSbzjRZlfwk/+kbT0I XWPNprgG2hc+ondcfdo9mTB3GXVIEAg4PpvJ8JKeYqaZRuZVhLM4l9WUyLqilWpe0aVHJ8IRvTN hwgqIGR81ftaYlWONEjECjj+mahGdzywAubi+7rtwLILRhrgy4mZehbcPNpdc+9Mu X-Gm-Gg: ASbGncs3Y4GG5AVJsRmdNvDoi4D8eLqWxVQfBA+5d9m/HYYBeMRVjeMnoc77gnxs7t1 rrhXLA2Quvv1kGbrL6/lH2FOflH70mB85GjB2iXDhEEbsLZWvvFN1zTyR/E+tQBSedo9AQmSmQq Amv5Q3Y99oAHoW13u1jBxGMhJ6Wow68LkIPFZ/LA0yWOYAdltiIbIs1TQOxQhNjfdUqctSOvCkT DzS675i9adrp/BeUdlBlvCmErmTLdQzcqvRujLqpLoX2XNSQ23r1umeFOBbMfxcp8/67kv2GaSE UIDAFQ== X-Received: by 2002:a05:690c:498c:b0:6ef:6d37:1844 with SMTP id 00721157ae682-6eface0165amr26104437b3.7.1733221419704; Tue, 03 Dec 2024 02:23:39 -0800 (PST) X-Google-Smtp-Source: AGHT+IHhLH5mlnPSZDMavmUUFnJVktKyJMWmluLB4C8Hy0mLsNN/3vDHojrXbS5zn/OAP8RhyeXzIw== X-Received: by 2002:a05:690c:498c:b0:6ef:6d37:1844 with SMTP id 00721157ae682-6eface0165amr26104227b3.7.1733221419366; Tue, 03 Dec 2024 02:23:39 -0800 (PST) Message-ID: Date: Tue, 3 Dec 2024 11:23:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/7] tests/functional/test_virtio_gpu: Remove legacy '-machine foo,accel=bar' To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= , qemu-devel@nongnu.org Cc: Paolo Bonzini , =?UTF-8?Q?Daniel_P_=2E_Berrang=C3=A9?= , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org References: <20241203092153.60590-1-philmd@linaro.org> <20241203092153.60590-3-philmd@linaro.org> From: Thomas Huth Autocrypt: addr=thuth@redhat.com; keydata= xsFNBFH7eUwBEACzyOXKU+5Pcs6wNpKzrlJwzRl3VGZt95VCdb+FgoU9g11m7FWcOafrVRwU yYkTm9+7zBUc0sW5AuPGR/dp3pSLX/yFWsA/UB4nJsHqgDvDU7BImSeiTrnpMOTXb7Arw2a2 4CflIyFqjCpfDM4MuTmzTjXq4Uov1giGE9X6viNo1pxyEpd7PanlKNnf4PqEQp06X4IgUacW tSGj6Gcns1bCuHV8OPWLkf4hkRnu8hdL6i60Yxz4E6TqlrpxsfYwLXgEeswPHOA6Mn4Cso9O 0lewVYfFfsmokfAVMKWzOl1Sr0KGI5T9CpmRfAiSHpthhHWnECcJFwl72NTi6kUcUzG4se81 O6n9d/kTj7pzTmBdfwuOZ0YUSqcqs0W+l1NcASSYZQaDoD3/SLk+nqVeCBB4OnYOGhgmIHNW 0CwMRO/GK+20alxzk//V9GmIM2ACElbfF8+Uug3pqiHkVnKqM7W9/S1NH2qmxB6zMiJUHlTH gnVeZX0dgH27mzstcF786uPcdEqS0KJuxh2kk5IvUSL3Qn3ZgmgdxBMyCPciD/1cb7/Ahazr 3ThHQXSHXkH/aDXdfLsKVuwDzHLVSkdSnZdt5HHh75/NFHxwaTlydgfHmFFwodK8y/TjyiGZ zg2Kje38xnz8zKn9iesFBCcONXS7txENTzX0z80WKBhK+XSFJwARAQABzR5UaG9tYXMgSHV0 aCA8dGh1dGhAcmVkaGF0LmNvbT7CwXgEEwECACIFAlVgX6oCGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAAoJEC7Z13T+cC21EbIP/ii9cvT2HHGbFRl8HqGT6+7Wkb+XLMqJBMAIGiQK QIP3xk1HPTsLfVG0ao4hy/oYkGNOP8+ubLnZen6Yq3zAFiMhQ44lvgigDYJo3Ve59gfe99KX EbtB+X95ODARkq0McR6OAsPNJ7gpEUzfkQUUJTXRDQXfG/FX303Gvk+YU0spm2tsIKPl6AmV 1CegDljzjycyfJbk418MQmMu2T82kjrkEofUO2a24ed3VGC0/Uz//XCR2ZTo+vBoBUQl41BD eFFtoCSrzo3yPFS+w5fkH9NT8ChdpSlbNS32NhYQhJtr9zjWyFRf0Zk+T/1P7ECn6gTEkp5k ofFIA4MFBc/fXbaDRtBmPB0N9pqTFApIUI4vuFPPO0JDrII9dLwZ6lO9EKiwuVlvr1wwzsgq zJTPBU3qHaUO4d/8G+gD7AL/6T4zi8Jo/GmjBsnYaTzbm94lf0CjXjsOX3seMhaE6WAZOQQG tZHAO1kAPWpaxne+wtgMKthyPLNwelLf+xzGvrIKvLX6QuLoWMnWldu22z2ICVnLQChlR9d6 WW8QFEpo/FK7omuS8KvvopFcOOdlbFMM8Y/8vBgVMSsK6fsYUhruny/PahprPbYGiNIhKqz7 UvgyZVl4pBFjTaz/SbimTk210vIlkDyy1WuS8Zsn0htv4+jQPgo9rqFE4mipJjy/iboDzsFN BFH7eUwBEAC2nzfUeeI8dv0C4qrfCPze6NkryUflEut9WwHhfXCLjtvCjnoGqFelH/PE9NF4 4VPSCdvD1SSmFVzu6T9qWdcwMSaC+e7G/z0/AhBfqTeosAF5XvKQlAb9ZPkdDr7YN0a1XDfa +NgA+JZB4ROyBZFFAwNHT+HCnyzy0v9Sh3BgJJwfpXHH2l3LfncvV8rgFv0bvdr70U+On2XH 5bApOyW1WpIG5KPJlDdzcQTyptOJ1dnEHfwnABEfzI3dNf63rlxsGouX/NFRRRNqkdClQR3K gCwciaXfZ7ir7fF0u1N2UuLsWA8Ei1JrNypk+MRxhbvdQC4tyZCZ8mVDk+QOK6pyK2f4rMf/ WmqxNTtAVmNuZIwnJdjRMMSs4W4w6N/bRvpqtykSqx7VXcgqtv6eqoDZrNuhGbekQA0sAnCJ VPArerAZGArm63o39me/bRUQeQVSxEBmg66yshF9HkcUPGVeC4B0TPwz+HFcVhheo6hoJjLq knFOPLRj+0h+ZL+D0GenyqD3CyuyeTT5dGcNU9qT74bdSr20k/CklvI7S9yoQje8BeQAHtdV cvO8XCLrpGuw9SgOS7OP5oI26a0548M4KldAY+kqX6XVphEw3/6U1KTf7WxW5zYLTtadjISB X9xsRWSU+Yqs3C7oN5TIPSoj9tXMoxZkCIHWvnqGwZ7JhwARAQABwsFfBBgBAgAJBQJR+3lM AhsMAAoJEC7Z13T+cC21hPAQAIsBL9MdGpdEpvXs9CYrBkd6tS9mbaSWj6XBDfA1AEdQkBOn ZH1Qt7HJesk+qNSnLv6+jP4VwqK5AFMrKJ6IjE7jqgzGxtcZnvSjeDGPF1h2CKZQPpTw890k fy18AvgFHkVk2Oylyexw3aOBsXg6ukN44vIFqPoc+YSU0+0QIdYJp/XFsgWxnFIMYwDpxSHS 5fdDxUjsk3UBHZx+IhFjs2siVZi5wnHIqM7eK9abr2cK2weInTBwXwqVWjsXZ4tq5+jQrwDK cvxIcwXdUTLGxc4/Z/VRH1PZSvfQxdxMGmNTGaXVNfdFZjm4fz0mz+OUi6AHC4CZpwnsliGV ODqwX8Y1zic9viSTbKS01ZNp175POyWViUk9qisPZB7ypfSIVSEULrL347qY/hm9ahhqmn17 Ng255syASv3ehvX7iwWDfzXbA0/TVaqwa1YIkec+/8miicV0zMP9siRcYQkyTqSzaTFBBmqD oiT+z+/E59qj/EKfyce3sbC9XLjXv3mHMrq1tKX4G7IJGnS989E/fg6crv6NHae9Ckm7+lSs IQu4bBP2GxiRQ+NV3iV/KU3ebMRzqIC//DCOxzQNFNJAKldPe/bKZMCxEqtVoRkuJtNdp/5a yXFZ6TfE1hGKrDBYAm4vrnZ4CXFSBDllL59cFFOJCkn4Xboj/aVxxJxF30bn In-Reply-To: <20241203092153.60590-3-philmd@linaro.org> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: wIf5NZF8eGUBMIeYhrmytIKAme05zwBleI6hKqdn80Y_1733221420 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 03/12/2024 10.21, Philippe Mathieu-Daudé wrote: > Since commit 6f6e1698a68 ("vl: configure accelerators from -accel > options") we prefer the '-accel bar' command line option. > > Replace '-machine foo,accel=bar' -> '-machine foo -accel bar' in > functional tests. > > Signed-off-by: Philippe Mathieu-Daudé > --- > tests/functional/test_virtio_gpu.py | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/tests/functional/test_virtio_gpu.py b/tests/functional/test_virtio_gpu.py > index d5027487ac4..cc0ec234861 100755 > --- a/tests/functional/test_virtio_gpu.py > +++ b/tests/functional/test_virtio_gpu.py > @@ -61,7 +61,8 @@ def test_virtio_vga_virgl(self): > self.vm.set_console() > self.vm.add_args("-cpu", "host") > self.vm.add_args("-m", "2G") > - self.vm.add_args("-machine", "pc,accel=kvm") > + self.vm.add_args('-accel', 'kvm') > + self.vm.add_args("-machine", "pc") While you're at it, could you please change this test to use "self.set_machine('pc')" at the very beginning of the test function instead of using -machine pc here? That way the test gets properly skipped in case the machine is not available in the QEMU binary. Thanks, Thomas > self.vm.add_args("-device", "virtio-vga-gl") > self.vm.add_args("-display", "egl-headless") > self.vm.add_args( > @@ -118,10 +119,11 @@ def test_vhost_user_vga_virgl(self): > ) > > self.vm.set_console() > + self.vm.add_args('-accel', 'kvm') > self.vm.add_args("-cpu", "host") > self.vm.add_args("-m", "2G") > self.vm.add_args("-object", "memory-backend-memfd,id=mem,size=2G") > - self.vm.add_args("-machine", "pc,memory-backend=mem,accel=kvm") > + self.vm.add_args("-machine", "pc,memory-backend=mem") > self.vm.add_args("-chardev", "socket,id=vug,fd=%d" % qemu_sock.fileno()) > self.vm.add_args("-device", "vhost-user-vga,chardev=vug") > self.vm.add_args("-display", "egl-headless") From xen-devel-bounces@lists.xenproject.org Tue Dec 03 10:25:32 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 10:25:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847848.1262897 (Exim 4.92) (envelope-from ) id 1tIQ5z-0000Ol-MW; Tue, 03 Dec 2024 10:25:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847848.1262897; Tue, 03 Dec 2024 10:25: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 1tIQ5z-0000Oe-JX; Tue, 03 Dec 2024 10:25:31 +0000 Received: by outflank-mailman (input) for mailman id 847848; Tue, 03 Dec 2024 10:25: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 1tIQ5x-0000OY-Nt for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 10:25: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 ead32d23-b160-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 11:25:28 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-385f4a4093eso1311336f8f.1 for ; Tue, 03 Dec 2024 02:25: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-385eeb999f4sm6692160f8f.109.2024.12.03.02.25.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Dec 2024 02:25: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: ead32d23-b160-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733221528; x=1733826328; 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=VPh2ldz1/G2jFFaI8XyezhAGeaXAdERd0SaJwon5RNs=; b=VtIdy2sGpaUlRIKsy2iUrSIW46rd4R2d8h7nq5GIqGPsLjn6JRiqindwJFQf00lFdH X1Lu6m57juf2Qcz3tas79r/yDuokKT29OxIR6aO9jsTiZGKNTCWUheZYk0SLRH4WSyHH dlrAPB4WW087HMfR1NidkycjQUgPMGLfl9z9VN7/ZO7UgU75FSAtS6Qs3fh9y7Wa6RH+ QYArTdf5LepVbPaWhN53vGct9EijMDD7jBlwHFxPVR9R1/LZTpaIwB5H/FSBkqkgq31J d3Mn9Zfn23iOBIrStRbS4L58TyW3z8uP/iPFGyyEdJ9s2A4mJywyjm6zXfCzKe6CJ4jf /QcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733221528; x=1733826328; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VPh2ldz1/G2jFFaI8XyezhAGeaXAdERd0SaJwon5RNs=; b=VZ5NS62Xtqzh1Uvv1/ofjlL0p5Z2e9mI3w17yeLlaSA2GpeLyiXkSqlRcQdmwDwyko lWKD6hDZLttadBKqMfgrA9kbWgi2odRu+Oh2yHOtNoxtm+jrrcH0U6X2qwnAYSbsQK3E 8mUlVhpHZdTz3j7u7TYJ823OTOqVUkLB0J0+jqrb6JZJUYsTJQNN8z1i+fTUgXN5zCiD I0lMXCO3+K6BDCLa9YkV0mNStmPJe9/2+nO2bVjmNjZ0S9BdbsoHg0MImom90AmmgvdN CFGAvpZN+XfwO0/FYpB22+/0O+XBCCvJO1y6WvpP2q5SfXcFHsm46rH/DnmaJehOsSkS IEDQ== X-Forwarded-Encrypted: i=1; AJvYcCVp8b7ZSCUJfS9ww0d7kpgaF5Ro53sg2GrYtT1ZrWn1/YSVX7PV6kg+OjRpKEhmVHzHdB+LCXjU32I=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw5YqPPGG1+Kfz9JSuXzNLoTlDImI5fGySTtkQa95xhoeKVZ6Wc 4+dqhZWUow4pLUbg7ODCPwTeiJQTMQL7ibZKuz2Hvb6rbZ7sRIi2IRc+yK5+Fw== X-Gm-Gg: ASbGncuOObVfraDtHTgeRZGeHhJaX7MaElgxHvU5gwtPloTM0zq5YF4UdDhtM2bmq9x yKoL0DslNnWkhKyGhmdNLvjPnsz6tWJj4fPAHs3BqLM/p0yw21vLK/Ro1z/L6sHCXBQ8VtG3Adw 57I/1JLlruB1wq3N7picQbWem7B0a0/G7OmuIvA1itWVBuIfsSeHK/kRCDKpDPEO1F9vJ53qiDP 7ML84VILAUKN/vzn8As8Gbg54ftZBpkTJEwiuUGPDSsXKMXKa+bdxGr3JyevFBxx8+nZGpEYsKb eLrEjK90qQszx5baQUXtRJsMkMnKlXc1ZAI= X-Google-Smtp-Source: AGHT+IFHNtlggfT7nu9s/M230KeN+MlGNk+ZRjf9NsqYgO5w8V/NK1qoxAJKJonFr+ZM9yvzilK+Mw== X-Received: by 2002:a5d:64cb:0:b0:385:e43a:4ded with SMTP id ffacd0b85a97d-385fd42d1b4mr1739176f8f.57.1733221528217; Tue, 03 Dec 2024 02:25:28 -0800 (PST) Message-ID: <617be60d-1807-4bae-98cc-2a438598e07f@suse.com> Date: Tue, 3 Dec 2024 11:25:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 4/5] xen/arm: Check for Static Heap feature when freeing resources To: Luca Fancellu Cc: Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Wei Chen , xen-devel@lists.xenproject.org References: <20241203094811.427076-1-luca.fancellu@arm.com> <20241203094811.427076-5-luca.fancellu@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: <20241203094811.427076-5-luca.fancellu@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 03.12.2024 10:48, Luca Fancellu wrote: > From: Penny Zheng > > If the Xen heap is statically configured in Device Tree, its size is > definite, so only the defined memory shall be given to the boot > allocator. Have a check where init_domheap_pages() is called > which takes into account if static heap feature is used. > > Extract static_heap flag from init data bootinfo, as it will be needed > after destroying the init data section, rename it to using_static_heap > and use it to tell whether the Xen static heap feature is enabled. > > Signed-off-by: Penny Zheng > Signed-off-by: Wei Chen > Signed-off-by: Luca Fancellu Reviewed-by: Jan Beulich # common From xen-devel-bounces@lists.xenproject.org Tue Dec 03 10:25:34 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 10:25:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847849.1262908 (Exim 4.92) (envelope-from ) id 1tIQ62-0000eM-0v; Tue, 03 Dec 2024 10:25:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847849.1262908; Tue, 03 Dec 2024 10:25: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 1tIQ61-0000eD-TQ; Tue, 03 Dec 2024 10:25:33 +0000 Received: by outflank-mailman (input) for mailman id 847849; Tue, 03 Dec 2024 10:25: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 1tIQ61-0000OY-Ax for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 10:25:33 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ec77d4d8-b160-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 11:25:32 +0100 (CET) Received: from mail-yw1-f200.google.com (mail-yw1-f200.google.com [209.85.128.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-600-lJWNlTEeM_65pIhmjGo1xQ-1; Tue, 03 Dec 2024 05:25:29 -0500 Received: by mail-yw1-f200.google.com with SMTP id 00721157ae682-6ef6add361aso49862827b3.2 for ; Tue, 03 Dec 2024 02:25:29 -0800 (PST) Received: from [192.168.0.7] (ip-109-42-51-199.web.vodafone.de. [109.42.51.199]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6d875221e2csm59512626d6.108.2024.12.03.02.25.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Dec 2024 02:25: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: ec77d4d8-b160-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733221531; 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:autocrypt:autocrypt; bh=9RD4AGEHDHwzQlUUYYm0x1kn9o+vBEiZ5DFCqwxpxGM=; b=MkOZ8PfW0OWe4ceEQwitA3YTUcAJ7alWJdhsEa9vmCEktk+debZEvLTEroDt/dZGRVknL4 MHWhPxD6VhhtfqiUcLXYkgG4+RW/b9AyeoUSx8nm3Kw6E20mbuj4D+5X0piC98rcA3mvqp H1j2r+2J2rWuks1VXzsMq/Hm6HuSFkI= X-MC-Unique: lJWNlTEeM_65pIhmjGo1xQ-1 X-Mimecast-MFC-AGG-ID: lJWNlTEeM_65pIhmjGo1xQ X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733221529; x=1733826329; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9RD4AGEHDHwzQlUUYYm0x1kn9o+vBEiZ5DFCqwxpxGM=; b=XWgyERQa65h9VePCD33VYTjbP2CXFKfnJ6QldtRPaLsxVZL6i5yleueJ6AgwQNPxjp v/XdFA0M7ls/MQrMXJgoF0OFxnzLgTx9sldL4sFCr3JIC+Mg56wiVV7TpggID317qfx+ 4vzf+b04LVkmEkDOuoZNB9JHenxBqxwinBKXP/V0WIiZRQ0oKRTgAddZeAkrZRblG7eH JieQbaHzaAfWnf+2S/eQj3A+2JOGCCKTmM9HJsTl09suO/grCEfxXzbL6oLSGP2I5f2Q dIhGpcmVCucltt5WUSkE9KDOZsHi61XmyvrwvUdp/iKDQT2VUTgF5CwW83FFb2EiZtqV saPg== X-Forwarded-Encrypted: i=1; AJvYcCV4KUX/ekPobjQvE3ITZK4AMrzr/QuebFz8/zcib17YNjiSBVlDhbIz6N9CzVQnFkftmkX+VcScZxg=@lists.xenproject.org X-Gm-Message-State: AOJu0YwlNDeTMVSHQpLejl6+vnfG5Ph8heQXttSEhHl3/GUzVApHPO/d 7DfKL4lCkFcE8seC8JiPw6TK9VUJmaQ4vKJZQeyxqZOTl84hvoY4xOh428Zqd9nhml/x4fe6XTS yyBlDM6SmSsMXsA/uF+taX+Y+mywyosSSzKXdhc18uUYBoZt1LT5+u5zQts26yhOd X-Gm-Gg: ASbGncsSLCuNNIb7b6mXbOIBZKkdmPbPezM3mvPaEdMvxZZE2JxquFX8uZFndm+n9cR ieyrAzBdT/Djr5fkYRXE6D+FtHp4ste9dDsmP5ORGBdfORm8Kl1EyuLk58foBJVMxiVlYANLaPA WEw2LYtEbjCBO29jdGd+md/tNOMsNfroYIPRknelK6CjK1JF28SkE4zu1rIY8Di4ubFKWo0aCJc BKAmWWL+gQUqQUaRHJYdcmC+9msq+5+2VZs7WodykT6qMYaaTZGh2Mt6X64cEZzJ0uXpv4v+wwQ UdTWPA== X-Received: by 2002:a05:690c:7082:b0:6ef:7372:1131 with SMTP id 00721157ae682-6efad347d99mr29596027b3.41.1733221528929; Tue, 03 Dec 2024 02:25:28 -0800 (PST) X-Google-Smtp-Source: AGHT+IHCzHlHtzf8vt0HkFH4QdgEQXGf7HxTcee32BcaMWjQ+E3LVW6GJQ+e9gCjohaYy4zSxRVU4Q== X-Received: by 2002:a05:690c:7082:b0:6ef:7372:1131 with SMTP id 00721157ae682-6efad347d99mr29595887b3.41.1733221528714; Tue, 03 Dec 2024 02:25:28 -0800 (PST) Message-ID: Date: Tue, 3 Dec 2024 11:25:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/7] tests/qtest/fuzz: Remove legacy '-machine foo,accel=bar' To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= , qemu-devel@nongnu.org Cc: Paolo Bonzini , =?UTF-8?Q?Daniel_P_=2E_Berrang=C3=A9?= , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org References: <20241203092153.60590-1-philmd@linaro.org> <20241203092153.60590-4-philmd@linaro.org> From: Thomas Huth Autocrypt: addr=thuth@redhat.com; keydata= xsFNBFH7eUwBEACzyOXKU+5Pcs6wNpKzrlJwzRl3VGZt95VCdb+FgoU9g11m7FWcOafrVRwU yYkTm9+7zBUc0sW5AuPGR/dp3pSLX/yFWsA/UB4nJsHqgDvDU7BImSeiTrnpMOTXb7Arw2a2 4CflIyFqjCpfDM4MuTmzTjXq4Uov1giGE9X6viNo1pxyEpd7PanlKNnf4PqEQp06X4IgUacW tSGj6Gcns1bCuHV8OPWLkf4hkRnu8hdL6i60Yxz4E6TqlrpxsfYwLXgEeswPHOA6Mn4Cso9O 0lewVYfFfsmokfAVMKWzOl1Sr0KGI5T9CpmRfAiSHpthhHWnECcJFwl72NTi6kUcUzG4se81 O6n9d/kTj7pzTmBdfwuOZ0YUSqcqs0W+l1NcASSYZQaDoD3/SLk+nqVeCBB4OnYOGhgmIHNW 0CwMRO/GK+20alxzk//V9GmIM2ACElbfF8+Uug3pqiHkVnKqM7W9/S1NH2qmxB6zMiJUHlTH gnVeZX0dgH27mzstcF786uPcdEqS0KJuxh2kk5IvUSL3Qn3ZgmgdxBMyCPciD/1cb7/Ahazr 3ThHQXSHXkH/aDXdfLsKVuwDzHLVSkdSnZdt5HHh75/NFHxwaTlydgfHmFFwodK8y/TjyiGZ zg2Kje38xnz8zKn9iesFBCcONXS7txENTzX0z80WKBhK+XSFJwARAQABzR5UaG9tYXMgSHV0 aCA8dGh1dGhAcmVkaGF0LmNvbT7CwXgEEwECACIFAlVgX6oCGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAAoJEC7Z13T+cC21EbIP/ii9cvT2HHGbFRl8HqGT6+7Wkb+XLMqJBMAIGiQK QIP3xk1HPTsLfVG0ao4hy/oYkGNOP8+ubLnZen6Yq3zAFiMhQ44lvgigDYJo3Ve59gfe99KX EbtB+X95ODARkq0McR6OAsPNJ7gpEUzfkQUUJTXRDQXfG/FX303Gvk+YU0spm2tsIKPl6AmV 1CegDljzjycyfJbk418MQmMu2T82kjrkEofUO2a24ed3VGC0/Uz//XCR2ZTo+vBoBUQl41BD eFFtoCSrzo3yPFS+w5fkH9NT8ChdpSlbNS32NhYQhJtr9zjWyFRf0Zk+T/1P7ECn6gTEkp5k ofFIA4MFBc/fXbaDRtBmPB0N9pqTFApIUI4vuFPPO0JDrII9dLwZ6lO9EKiwuVlvr1wwzsgq zJTPBU3qHaUO4d/8G+gD7AL/6T4zi8Jo/GmjBsnYaTzbm94lf0CjXjsOX3seMhaE6WAZOQQG tZHAO1kAPWpaxne+wtgMKthyPLNwelLf+xzGvrIKvLX6QuLoWMnWldu22z2ICVnLQChlR9d6 WW8QFEpo/FK7omuS8KvvopFcOOdlbFMM8Y/8vBgVMSsK6fsYUhruny/PahprPbYGiNIhKqz7 UvgyZVl4pBFjTaz/SbimTk210vIlkDyy1WuS8Zsn0htv4+jQPgo9rqFE4mipJjy/iboDzsFN BFH7eUwBEAC2nzfUeeI8dv0C4qrfCPze6NkryUflEut9WwHhfXCLjtvCjnoGqFelH/PE9NF4 4VPSCdvD1SSmFVzu6T9qWdcwMSaC+e7G/z0/AhBfqTeosAF5XvKQlAb9ZPkdDr7YN0a1XDfa +NgA+JZB4ROyBZFFAwNHT+HCnyzy0v9Sh3BgJJwfpXHH2l3LfncvV8rgFv0bvdr70U+On2XH 5bApOyW1WpIG5KPJlDdzcQTyptOJ1dnEHfwnABEfzI3dNf63rlxsGouX/NFRRRNqkdClQR3K gCwciaXfZ7ir7fF0u1N2UuLsWA8Ei1JrNypk+MRxhbvdQC4tyZCZ8mVDk+QOK6pyK2f4rMf/ WmqxNTtAVmNuZIwnJdjRMMSs4W4w6N/bRvpqtykSqx7VXcgqtv6eqoDZrNuhGbekQA0sAnCJ VPArerAZGArm63o39me/bRUQeQVSxEBmg66yshF9HkcUPGVeC4B0TPwz+HFcVhheo6hoJjLq knFOPLRj+0h+ZL+D0GenyqD3CyuyeTT5dGcNU9qT74bdSr20k/CklvI7S9yoQje8BeQAHtdV cvO8XCLrpGuw9SgOS7OP5oI26a0548M4KldAY+kqX6XVphEw3/6U1KTf7WxW5zYLTtadjISB X9xsRWSU+Yqs3C7oN5TIPSoj9tXMoxZkCIHWvnqGwZ7JhwARAQABwsFfBBgBAgAJBQJR+3lM AhsMAAoJEC7Z13T+cC21hPAQAIsBL9MdGpdEpvXs9CYrBkd6tS9mbaSWj6XBDfA1AEdQkBOn ZH1Qt7HJesk+qNSnLv6+jP4VwqK5AFMrKJ6IjE7jqgzGxtcZnvSjeDGPF1h2CKZQPpTw890k fy18AvgFHkVk2Oylyexw3aOBsXg6ukN44vIFqPoc+YSU0+0QIdYJp/XFsgWxnFIMYwDpxSHS 5fdDxUjsk3UBHZx+IhFjs2siVZi5wnHIqM7eK9abr2cK2weInTBwXwqVWjsXZ4tq5+jQrwDK cvxIcwXdUTLGxc4/Z/VRH1PZSvfQxdxMGmNTGaXVNfdFZjm4fz0mz+OUi6AHC4CZpwnsliGV ODqwX8Y1zic9viSTbKS01ZNp175POyWViUk9qisPZB7ypfSIVSEULrL347qY/hm9ahhqmn17 Ng255syASv3ehvX7iwWDfzXbA0/TVaqwa1YIkec+/8miicV0zMP9siRcYQkyTqSzaTFBBmqD oiT+z+/E59qj/EKfyce3sbC9XLjXv3mHMrq1tKX4G7IJGnS989E/fg6crv6NHae9Ckm7+lSs IQu4bBP2GxiRQ+NV3iV/KU3ebMRzqIC//DCOxzQNFNJAKldPe/bKZMCxEqtVoRkuJtNdp/5a yXFZ6TfE1hGKrDBYAm4vrnZ4CXFSBDllL59cFFOJCkn4Xboj/aVxxJxF30bn In-Reply-To: <20241203092153.60590-4-philmd@linaro.org> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: JREj9Bd8zTeV_KU-9o0j6GAv1YU4g1ROJ_NY6VrOxWA_1733221529 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 03/12/2024 10.21, Philippe Mathieu-Daudé wrote: > Since commit 6f6e1698a68 ("vl: configure accelerators from -accel > options") we prefer the '-accel bar' command line option. > > Replace '-machine foo,accel=bar' -> '-machine foo -accel bar' in > fuzzer scripts and tests. > > Signed-off-by: Philippe Mathieu-Daudé > --- > tests/qtest/fuzz/generic_fuzz.c | 2 +- > tests/qtest/fuzz/i440fx_fuzz.c | 2 +- > tests/qtest/fuzz/qos_fuzz.c | 2 +- > scripts/oss-fuzz/output_reproducer.py | 2 -- > scripts/oss-fuzz/reorder_fuzzer_qtest_trace.py | 6 +++--- > 5 files changed, 6 insertions(+), 8 deletions(-) Reviewed-by: Thomas Huth From xen-devel-bounces@lists.xenproject.org Tue Dec 03 10:27:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 10:27:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847876.1262917 (Exim 4.92) (envelope-from ) id 1tIQ7k-0001Y5-B4; Tue, 03 Dec 2024 10:27:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847876.1262917; Tue, 03 Dec 2024 10: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 1tIQ7k-0001Xy-8L; Tue, 03 Dec 2024 10:27:20 +0000 Received: by outflank-mailman (input) for mailman id 847876; Tue, 03 Dec 2024 10:27: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 1tIQ7j-0001Xl-7M for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 10:27:19 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2060c.outbound.protection.outlook.com [2a01:111:f403:2613::60c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2b484b63-b161-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 11:27:17 +0100 (CET) Received: from AM0PR04CA0066.eurprd04.prod.outlook.com (2603:10a6:208:1::43) by DU0PR08MB7740.eurprd08.prod.outlook.com (2603:10a6:10:3bc::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.17; Tue, 3 Dec 2024 10:27:11 +0000 Received: from AMS0EPF000001A3.eurprd05.prod.outlook.com (2603:10a6:208:1:cafe::4c) by AM0PR04CA0066.outlook.office365.com (2603:10a6:208:1::43) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.18 via Frontend Transport; Tue, 3 Dec 2024 10:27:11 +0000 Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AMS0EPF000001A3.mail.protection.outlook.com (10.167.16.228) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 10:27:11 +0000 Received: ("Tessian outbound 5b75617ec243:v514"); Tue, 03 Dec 2024 10:27:11 +0000 Received: from Lda6a7b59695f.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id AA03A824-059A-454E-85D0-20A45B86EA7C.1; Tue, 03 Dec 2024 10:26:59 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id Lda6a7b59695f.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 03 Dec 2024 10:26:59 +0000 Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21) by PAXPR08MB6703.eurprd08.prod.outlook.com (2603:10a6:102:138::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.20; Tue, 3 Dec 2024 10:26:56 +0000 Received: from DBAPR08MB5798.eurprd08.prod.outlook.com ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com ([fe80::4a66:d3e2:570:9632%5]) with mapi id 15.20.8207.017; Tue, 3 Dec 2024 10:26: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: 2b484b63-b161-11ef-99a3-01e77a169b0f ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=urmZ2jO+jYWCI0vX0JuRa5xlO48tXlHjrGInW4CVWd+QTNaPqkNuz8vNMIeeaxlCSvqa1DUdtkNS5cYPg5OedeHV4srVOmFCK9Yz2LbqSzUocaUc1RnVErP76xDRcNL4mJeqWidzoJQ4JnkjGw1LmVlHeC0icdQG4HCKSRP6urEVZlVwpBFq6or75QIpMoo5pPWpvdg2zOmPSCAcQ2IJqvoH7ItQzzpM+F/ZX5sWEuV9t2V8p0m05Ex/gFT2qoZjPg3Qs9DIOUML6aJzhXxi2AbCbQ5Z+vHbf8ZIZrvHlDyR6MZ36CCHmMd1ue/Y1hg6kJSU+4JWSf1Xbz7dYwMF2A== 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=0CB/1zE4sssgW4K4RAwcWrfF175IqUSsEX0VuPOdf5o=; b=M5mh+ihrGYhEoxibbASbS4TOMm9ylXByURgC1+rYOo9ei4dv7t2fZZiDMcJZUn+ffv10ADq7bv1aB2Jm5gK3U2wyvPE6xBUFkcUfbc61rKl3DUBPpgXXUxkKg9rKVwlkAARsCLe4a0Qv7LuUcSi1uz3cxyhxIqe7BE5i4JcfRPpDQ/lGHv+8Hyp449VUEkxBV60i0BSmmbBe6QEuaKE6T6//yQ4MMA3FJtY7uecgrOeoOPEzfHT5sMcD4kHUow7pvZZTk3zxKKzppX764JODGYFYmprjTAhju32yDEpUt4eLM6DhFOleW2nhwZgrx+uJSqgQT4798ZHFDne5DxcWaA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=0CB/1zE4sssgW4K4RAwcWrfF175IqUSsEX0VuPOdf5o=; b=T2OPCMgdYqhTFQVSC4FaUO9hNWzUvi29nzm7DOJPRp+BsSaLmMN+nL9nNSgN3cegqLx6YEGUl+lTTjp/WEjV4gzhQdzoWknfYiS76K2zp0Nug+4EVn9pIG9R7/lLVxm7yNm3j/yPMPP5ozIbKppxBFGWxzMewMmH8iGShqgLyxQ= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) 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 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C X-CheckRecipientChecked: true X-CR-MTA-CID: f195fc99f087e75c X-TessianGatewayMetadata: JmkbBzTWxWj72fUsSzYPbATjdL41XE6eO7yw1XXI+ZF1VB/34g1y7b17dHhZpDrLoTP9u9EoWWD0c4S6qQskGp8vcMfsyudaihqfgYpmY1Z62NHXgXDv5lvPDOjmxoeu6TXP0X4CHpZ/j7vw1uOQ3rUh2Hch8YaiURjpkHI5kqI= X-CR-MTA-TID: 64aa7808 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VolOVbnvtTQF0a2F5UOsJcVci+2nsL603VoUrtz5FTUO60zwb3iR3Yg+EmC+81quePjilbiMaeBvR7XHH3KdKzGTqCtkCf+bAmg3uQ/vAwgBQnOm0OmrkPBpUFE0tYSJofWLDeTPcE03sXyx1XELvI0DfHJ9r0LDqzlnEXqabV0JcMn575NWgj55f6VHnxLEYZHxG43iJbOqmQF0MMlEvwhaMvuezmiJHNmqLSLJfAqPhMrUOBwCKpLsN6GHzZNMxla8KC8sjB44LD6L89VhPjEFmLTWS8Mb+ae/8+lutUTHFjegu6NkEk4tr8i0BL4u+4UosZvOzdYD3oTBCzU2+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0CB/1zE4sssgW4K4RAwcWrfF175IqUSsEX0VuPOdf5o=; b=NC3KRuy5zc3iWksG0roTIzyumq5QpT7z/4JVQ91gm3Z1cuq/6MJjyVh9ouHXhs+q2wgjZU5qukEK2rboddrS9ahzZ0TEGUmipx7qOwB7KiH1xWPgr7ECzIU9n+NK4rSPNImwouxkrmKPzC+vPdcsK69AkRaPE8NIY8eavysR1wExJr18xvnFra2VuCshWg1mreZIXexskzM+uSNdW5wIzjZGuVDVQ8TSrv5i4Ar+X86qi214wy7IamSfqtz1lakJXNvYt/YrEd8BZSCNvz6pduQr9zNgA9fjXQZNsqwXab7JMUiRsmLb8WBMw6Wr7aLp9Z/ksiZ8XZq6H5bCyhTkow== 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=0CB/1zE4sssgW4K4RAwcWrfF175IqUSsEX0VuPOdf5o=; b=T2OPCMgdYqhTFQVSC4FaUO9hNWzUvi29nzm7DOJPRp+BsSaLmMN+nL9nNSgN3cegqLx6YEGUl+lTTjp/WEjV4gzhQdzoWknfYiS76K2zp0Nug+4EVn9pIG9R7/lLVxm7yNm3j/yPMPP5ozIbKppxBFGWxzMewMmH8iGShqgLyxQ= From: Luca Fancellu To: Ayan Kumar Halder CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: Re: [PATCH v2 1/2] xen/mpu: Map early uart when earlyprintk on Thread-Topic: [PATCH v2 1/2] xen/mpu: Map early uart when earlyprintk on Thread-Index: AQHbRWz5mao3stJzR02TMW5lND/1eLLUUMKA Date: Tue, 3 Dec 2024 10:26:56 +0000 Message-ID: <88BFD6BF-A7EF-49D6-B817-2737FB28F28D@arm.com> References: <20241127183906.485824-1-ayan.kumar.halder@amd.com> <20241127183906.485824-2-ayan.kumar.halder@amd.com> In-Reply-To: <20241127183906.485824-2-ayan.kumar.halder@amd.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3826.200.121) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DBAPR08MB5798:EE_|PAXPR08MB6703:EE_|AMS0EPF000001A3:EE_|DU0PR08MB7740:EE_ X-MS-Office365-Filtering-Correlation-Id: ee693a66-ec35-48e1-8c8b-08dd13850c4b 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|38070700018; X-Microsoft-Antispam-Message-Info-Original: =?utf-8?B?eTZyWk5wRytEMUZyVkRoeEhySHJveVJmMi9MRDl0UkpZNWx1Q0FLZ2VIVXVr?= =?utf-8?B?K29pazFZc05wYUhsUWd6ZmxmM25JTE51OXp4UU13MDJNczkxN1AwR2kyVStR?= =?utf-8?B?QTdURG9sanJISGxkTnlUVkIzUE55S3dWNkNRcDladFg1Snc2TVZFVnJzejF6?= =?utf-8?B?b2ltdGJNU3NSb3M5WWJEZ0p5dWJZM3NoNVIwL2JWcEJKa3ZqV3M2K29sU1lE?= =?utf-8?B?OTk4U1dRV0EwZGZWQ1ZFS1UwallCeTN3ZUlHZUdBWjZZbmlPWS9CVUJNS3pV?= =?utf-8?B?cENxMjdHOVZnK2VUTlNQUm1HaXN2ZGk4SlNYeHlob3NJVnZHOTV6UDd5VjdF?= =?utf-8?B?YkpMamhWQVRhdVMvS2xXQ2UrdzhzVnBqVFcwdGtFUGNkQm1NeUdBWUVmRWVF?= =?utf-8?B?a2RETThjOUM1My9RdlIzcmVweThnT1lsSTB1bnRjemIxSnBVZWNIMi9CUzR5?= =?utf-8?B?WkF4eGQ4V0pWMUJzZUx5Zk50bnhrbzROemhxcHUzbXJjVHRpRnR3NmYxamZw?= =?utf-8?B?T21MZnpEcnlVcDBqeXAwQmlocU5wSVlUSzZmMEtkVUVhL1pBOGFVcGJNMldn?= =?utf-8?B?OEdOS3JLSE5RWG1WUXJTcW1CQ2I2bURUOEd2enhMYmhuWHBKcUo2d3p4QXZI?= =?utf-8?B?dVkwek5jU1Fza3lUN2JkL0xqTVpLSy9jby9aL1ZDRkZiM29RQmFTeElWT2xl?= =?utf-8?B?eGJUQURqY1B5enNLYXZ5Zy9lbytLM0haVlpGM0c1QzhZUG13ZmlSbEpoUlkw?= =?utf-8?B?YjRIaDcybWtXWVU5VUhJcnQyMTBNSll2YlFiN3kraUcvcnRZeWZhSmRIUFo2?= =?utf-8?B?V1JpQnBhbFpjODNhRjFJdkFCQnpFa3ZpbFBTbURtaDErb3A1Y0Nnak1LeXhs?= =?utf-8?B?d295MzduZ3lrS1lHbk1mLy84RlRIMVZOdHJtdVFMczFPTURVSm0yQ3BRM1JT?= =?utf-8?B?ckZmZkxZVWdudFNpNTA2WGRWeC91UmdXenFaSHRhU3JRRzNmQzJER2xoKzZC?= =?utf-8?B?VnVnRGlid1kzTnRTMmVWNGpNTFc5OGVKbE5yMWdvWDJtTklxaGQ1aCtVeWt5?= =?utf-8?B?M3RVakRLUU5CYlFFVEJWMyt2VmlWWTFWc05PM0hqYjFSazRydUdWTEpTL2Vr?= =?utf-8?B?WmJ3a1dmZlhpeTJiTnh2REhEQnJHTzFOeFhmRzhHMURMNTNQZ05Bejg2eVYy?= =?utf-8?B?UnBpQkd1aERCN0NwVXNRZTJpcms5NVQrTDltQVM0QWU2dSszVVhESFYxbWFX?= =?utf-8?B?QUFZUlhOTXpDQWpBdEE5OGoxWktncEtBeEF0YlFwdStWNGFaa1VZOUdIWUdy?= =?utf-8?B?d0xNcGZIWlczcHpQTWhRNURxMEFkRnd4RW4rbDRsSkRFTlV6VXl0TnVua1o1?= =?utf-8?B?dy9lelpKOU41NUZWcUhRZlBoeWRCdnpnaTVac2ZaOTUvTmZIdmhIOVBubWZk?= =?utf-8?B?RDZTWEh3dFIzOSt4L0c4TmNidEdITGtFVEVoSW1BRHdaOVZYVStVRTBSMitK?= =?utf-8?B?Z0lTaW1ZcDRvVTJMcUx2MUxXUlBQVkZtdDFHcnR4bEZSRW91RmJQcnhWYVk4?= =?utf-8?B?aThzVmtIa3BCZ1FsRSsxV3Njc3o4Y1NBd2JqYmZ6UU9pcDI2cFk0ZEhCS0lP?= =?utf-8?B?VlphQWxJT3BkUmlWQ3U3UTE1akZZUk0wUy8xdlhMUUZvcXl0Y1pNVXROeklS?= =?utf-8?B?aVpGUFY3TFhkUlZhODhER0pET1gwa2Z1eG9SaTlrT1E3bUFNRnlIMHFtNHEx?= =?utf-8?B?RXJveW0rQzJoK05pTlVGcEsybzJDZGtRVEdRcnhOMVArTStNeWRwZXlhSlpP?= =?utf-8?B?OU9MeUkwSVFLaVhZc1VabTRSekdHamVtejBRS01wakZRVE9ZcWJSN01vckc5?= =?utf-8?B?QVZRd28vWUZGSmdsT1JLR0M3ZHJXUjRwZ2dqTktsWCtPTGc9PQ==?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);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: PAXPR08MB6703 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-SkipListedInternetSender: ip=[2603:10a6:10:1a6::21];domain=DBAPR08MB5798.eurprd08.prod.outlook.com X-MS-Exchange-Transport-CrossTenantHeadersStripped: AMS0EPF000001A3.eurprd05.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 88d49e39-2008-48a8-416b-08dd1385032c X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|36860700013|376014|14060799003|35042699022; X-Microsoft-Antispam-Message-Info: =?utf-8?B?cWlzZmVRNk5tbE1JVTZWaW14azRuenY0V3ZFcG5BTTA1ZWUzYWs4SmI2bDVC?= =?utf-8?B?NmtpVWxXdjN6SEVVdVNTR1FpSG9SWnZrRFJnRHVxSFh0SUtVTk5yTnBnWStq?= =?utf-8?B?QjQzSGVtUWU4VjQvVHFoOG14cER2NEllM2xtc21GRlc2VDZFbVZMSmxxOVAw?= =?utf-8?B?WWFTWHRsN2x6SUNsOGxGcUJpRmFobythRWlSQlowMWpOS3ZaaXY4cWh2eFFQ?= =?utf-8?B?aGtsOUVxa2luRWpoNG5Dalh2VTlXZms4QnJSSi90K1IzY29WeE9oaDFOZXYr?= =?utf-8?B?MXoxb1k2UDdSa3BRUUpQN0ZEQm9CWEVYSVphekdWYXNzdWRBU3lrbFVheVln?= =?utf-8?B?cGEzYTNJUVRCdFd4Y1RKeHRLVXpXNW8xS3B1L2F2U3pCbE1XQzF3MzRaWS9Q?= =?utf-8?B?SFIwNTdwbm55WEltTFB0NVdaUnZWWnFvT2tEUGRVY1BmalJmR0RHNzQwdEVM?= =?utf-8?B?YVFFNEJHakk0QzN0eWtaVGM2Mmx5cWpYbWc1LzMvQnZjY3lJOU1STjByc2Zl?= =?utf-8?B?ZENMUXlZbU5qZGVxamR3dXhQcHFlb1lsK3R4amlFcktycGp3WjR5azI2NXND?= =?utf-8?B?ZUNncVBoL05BKzB4OVEyVU5YSUlxbGhvc0I1KzRkdWhkUkZpL2FEMkI4MTAy?= =?utf-8?B?ZG00MjFjMmczUE1rdno5bmpsZjBLYktxSDVhbDZvNzJ6UktCZ2pTYzNFR3JE?= =?utf-8?B?UkwzYTN4emJqVUpndy82akcyOVhjeFZXWWh1QVNsc0JRTWlza3pGRDVwSThp?= =?utf-8?B?NzNkMmdsY2VRdGtlODRGVy9wcmh1cDVGcTRuUzQ1WHhxVGo4Z2taOGVMN1ly?= =?utf-8?B?NU1QUkdCZFA2TFZyUnV5eEt6Qlk1d2JORVZDZmRtcm4zRUJ4UnUwVWtwbXl3?= =?utf-8?B?ZkxOaE1OYWJOMmFzbEVZd0xhTktYRkxRUnZEcVNyRFVWUGxtSjEwby9XU20z?= =?utf-8?B?RXhIUXFwYjBlUS9EV3p2cER3K1VLOTdkRXJRUTV6QmJjdTQ4S0crTmlTZDlN?= =?utf-8?B?cWc1bThrWXl2MlVoSDdzcFFDWlR1QUc2ck9LV3lsU2cxU3lkLzVLRFFHQW11?= =?utf-8?B?NUQ0Y3cvYk5MZlB2OEMxZU5uNEtwQmMzK1cwbHlsa0x6NzNjcEpHU20yV203?= =?utf-8?B?eFg0QXd4Vm1lMlRoVzdCdG9haTdKcnhnYWpEL0U5T0haNldpSjJsRGJJY3o2?= =?utf-8?B?d1RPRGR4dEVUSm5yZTdPYm5qQWtINGQ5bERmTFlucXdubHFoVlFFTXJ4NDZH?= =?utf-8?B?Q3V0NUxDcVFseko5NFNDMUN4VkR4L0NuQTVMOHMzdTZaOVlqL2JabWJ5Zjd6?= =?utf-8?B?WjBoOEkxZkFBbFc2WDM3Zmw3KzkvU1VGRVdrUGhQL2RlZUJNR1huOWdjNC9m?= =?utf-8?B?U3BNWTk0WEJpU3F2QnZFQ0RXcXNya3M1bXJzcVZkUGpwOHZYY0hpbVk4dHor?= =?utf-8?B?OTc1czQyakZSZkhFTnUvTHRWRzYrNC95d2g5d2R6aWVVSXloUnRGbVJ1aUNX?= =?utf-8?B?R2ErZDc0V01hbDVMMm4wUzFWV2d5OWJlQjFnSEo4elcvMmN2Qkd4VnZuQmNl?= =?utf-8?B?UUR2Q0JvdjR2d09CaHU4YmgrZjNWRTk1dzNteWNQb285ZHN1YmJCNnNiL3hj?= =?utf-8?B?RlJoSVV0a2NldTNvOHpta1hIZUlwNGRQdDduVzB2cHE0UkxlQU5lSGhkS3VP?= =?utf-8?B?ZHY3YVVrTElEbEFJZ042Tm8yRlVudzlPenFHRlF2SVZFMW9qQmorbDdjL2Zy?= =?utf-8?B?SzhCRitYMEdaZUJMUmVycGwzN1FvTjZxTGZHYllXQ1hQdkRmN1J0SDdGQ21H?= =?utf-8?B?ZmUrd3ZKaDZZYTlTMk1UalR4ak1sa0NHUFkvSm51T3hjZEtiRFREOW5LS2U5?= =?utf-8?B?OHlTKzR5MjVNN1cyNlphOS9DeUlIM29iayt2TytsbWxQeW5GMXRRUGo2bHdv?= =?utf-8?Q?cQ6JTyr4a1zu76oCzrO+YsNhG3QTqKLR?= X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014)(14060799003)(35042699022);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 10:27:11.3865 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ee693a66-ec35-48e1-8c8b-08dd13850c4b X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AMS0EPF000001A3.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB7740 SGkgQXlhbiwNCg0Kc29ycnkgSSd2ZSBqdXN0IHNwb3R0ZWQgc29tZSBpc3N1ZXMgd2hpbGUgY29t cGlsaW5nDQoNCg0KPiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2Vhcmx5 X3ByaW50ay5oIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2Vhcmx5X3ByaW50ay5oDQo+IGlu ZGV4IDQ2YTVlNTYyZGQuLjYwNmFhZWRkNmUgMTAwNjQ0DQo+IC0tLSBhL3hlbi9hcmNoL2FybS9p bmNsdWRlL2FzbS9lYXJseV9wcmludGsuaA0KPiArKysgYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9h c20vZWFybHlfcHJpbnRrLmgNCj4gQEAgLTE1LDYgKzE1LDI5IEBADQoNCnlvdSBuZWVkIHRvIGlu Y2x1ZGUNCg0KI2luY2x1ZGUgPGFzbS9hcm02NC9tcHUuaD4NCg0KaW4gb3JkZXIgdG8gc2VlIE1Q VV9SRUdJT05fQUxJR04gd2hpY2ggb3RoZXJ3aXNlIHdpbGwgYmUgemVybyBmb3IgdGhlIHByZXBy b2Nlc3Nvcg0KDQo+IA0KPiAjaWZkZWYgQ09ORklHX0VBUkxZX1BSSU5USw0KPiANCj4gKyNpZiBk ZWZpbmVkKENPTkZJR19NUFUpDQo+ICsNCj4gKy8qDQo+ICsgKiBGb3IgTVBVIHN5c3RlbXMsIHRo ZXJlIGlzIG5vIFZNU0Egc3VwcG9ydCBpbiBFTDIsIHNvIHdlIHVzZSBWQSA9PSBQQQ0KPiArICog Zm9yIEVBUkxZX1VBUlRfVklSVFVBTF9BRERSRVNTLg0KPiArICovDQo+ICsjZGVmaW5lIEVBUkxZ X1VBUlRfVklSVFVBTF9BRERSRVNTIENPTkZJR19FQVJMWV9VQVJUX0JBU0VfQUREUkVTUw0KPiAr DQo+ICsvKg0KPiArICogVXNlci1kZWZpbmVkIEVBUkxZX1VBUlRfQkFTRV9BRERSRVNTIGFuZCBF QVJMWV9VQVJUX1NJWkUgbXVzdCBiZSBhbGlnbmVkIHRvDQo+ICsgKiBtaW5pbXVtIHNpemUgb2Yg TVBVIHJlZ2lvbi4NCj4gKyAqLw0KPiArDQo+ICsjaWYgKEVBUkxZX1VBUlRfQkFTRV9BRERSRVNT ICUgTVBVX1JFR0lPTl9BTElHTikgIT0gMA0KICAgICAgICAgICBe4oCUIFRoaXMgbmVlZHMgdG8g YmUgQ09ORklHXyoNCg0KDQo+ICsjZXJyb3IgIkVBUkxZX1VBUlRfQkFTRV9BRERSRVNTIG11c3Qg YmUgYWxpZ25lZCB0byBtaW5pbXVtIE1QVSByZWdpb24gc2l6ZSINCj4gKyNlbmRpZg0KPiArDQo+ ICsjaWYgKEVBUkxZX1VBUlRfU0laRSAlIE1QVV9SRUdJT05fQUxJR04pICE9IDANCiAgICAgICAg ICAgXuKAlCBUaGlzIG5lZWRzIHRvIGJlIENPTkZJR18qDQoNCg0KT25jZSB0aGVzZSBhcmUgYWRk cmVzc2VkIGFuZCB0YWtpbmcgY2FyZSBhbHNvIG9mIEp1bGllbidzIGNvbW1lbnQ6DQoNClJldmll d2VkLWJ5OiBMdWNhIEZhbmNlbGx1IDxsdWNhLmZhbmNlbGx1QGFybS5jb20gPG1haWx0bzpsdWNh LmZhbmNlbGx1QGFybS5jb20+Pg0KDQpDaGVlcnMsDQpMdWNhDQoNCg== From xen-devel-bounces@lists.xenproject.org Tue Dec 03 10:33:34 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 10:33:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847891.1262927 (Exim 4.92) (envelope-from ) id 1tIQDh-00040s-Ts; Tue, 03 Dec 2024 10:33:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847891.1262927; Tue, 03 Dec 2024 10:33: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 1tIQDh-00040l-RL; Tue, 03 Dec 2024 10:33:29 +0000 Received: by outflank-mailman (input) for mailman id 847891; Tue, 03 Dec 2024 10:33: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 1tIQDg-00040f-M0 for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 10:33:28 +0000 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [2a00:1450:4864:20::636]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 083b9076-b162-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 11:33:27 +0100 (CET) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-aa545dc7105so822429266b.3 for ; Tue, 03 Dec 2024 02:33:27 -0800 (PST) Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5996c2c44sm607854366b.29.2024.12.03.02.33.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Dec 2024 02:33: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: 083b9076-b162-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1733222007; x=1733826807; 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=YyYtfOOLljpob3nWI63TVA0dLSLbyIvSyPKWxvhWjjc=; b=iZ7WUUhf/U/7vy/FC6+kS0CKJiHD2lSwZne3xhYvGKp0AL9jyFnbVktiOYzemY0ZZb wC+LFOerE7PHhBzHnla4m16pv2K+muVoNLJpDmVZmecG5aOQKvXxUqbEbGtj1F4FaNOv cb7zsWa0OdFb86591deVRR9e8RDaFjeN+ECxs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733222007; x=1733826807; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YyYtfOOLljpob3nWI63TVA0dLSLbyIvSyPKWxvhWjjc=; b=GHD2rDoTaf/HigadJ+ZHyTifaGcM3dp1leuxvQdUGDmtpcYFgENQpJ7vWRDbclCAgN 0BtXZqvBQ89LyLEbB3Eh5uZsQf1xUfcBPJKrPZb5SZYa9PrqRCEehlraqZ/1RIBPUHJT ErvWtN4pjxBdf/b6s7pn5Qieh7iIqfn9WL3C4faqdjRzMHAFeSSmSscPLDjZJHK9P5NT Y3Qn6tVno6rY8wPCl1xgA/d9kxiBgqW4WkbJD1vHsallAw7k+rN1s2Xb0uRX28tmSYY6 3f1/6Myx2p8eAeiPdt6AYBwenK1Nc4sPaxGLb8xHFdQo+eayxmj0YvovjpdunwppI/+a Qerg== X-Gm-Message-State: AOJu0YzjdeYTnGmSA2YU2IlptqSTWWwhZqW4DIARundxZIjLyyhl4UpZ +sH052Vo2s35wBBbCGd4licMPo2xLfMotFo4oq919eexvSruKTFzUHnzB0T0ZmIhAAEXm64Ieqa M X-Gm-Gg: ASbGncutjVIAOCtqQ/K48Vr5O1XJqVOZTFil8LvezJ4xpV5EuBjJrAuoQlkrrYZDftd wtxKVSh9QqbNlKNxG9FFV0cYo9+mWF660+TioP1z/ZidPDKusE3BNmOrOXbtFW24IG2bb9AE1hh RsmCW5JSYnpweaO2BrLrIrfK6i8rH6e7MCU0DlLMC2tR9BdxD2YtBoCaY8DhYgUk7jhJ2hfHV1y lWtrFfY7nRTUZwpxO0rfP74n6q7JEshuQG/ya3vfdn9s4RUVDt66X8LJyE= X-Google-Smtp-Source: AGHT+IHdMGhIdkiMGB1EYtSz6w1pCoc4vdzRf+9uVvw71l72PmoCb10pDlrXjOpxEJlRZ5XKvaf4rA== X-Received: by 2002:a17:906:30cb:b0:aa5:297a:ac65 with SMTP id a640c23a62f3a-aa5f7d4ec91mr139169266b.19.1733222007144; Tue, 03 Dec 2024 02:33:27 -0800 (PST) Date: Tue, 3 Dec 2024 11:33:25 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: Xen-devel , Anthony PERARD , Stefano Stabellini Subject: Re: [PATCH] CI: Update to FreeBSD 14.2 Message-ID: References: <20241203082658.134073-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20241203082658.134073-1-andrew.cooper3@citrix.com> On Tue, Dec 03, 2024 at 08:26:58AM +0000, Andrew Cooper wrote: > Signed-off-by: Andrew Cooper Acked-by: Roger Pau Monné Thanks! From xen-devel-bounces@lists.xenproject.org Tue Dec 03 10:34:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 10:34:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847903.1262938 (Exim 4.92) (envelope-from ) id 1tIQEe-0004sN-8t; Tue, 03 Dec 2024 10:34:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847903.1262938; Tue, 03 Dec 2024 10:34: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 1tIQEe-0004sG-67; Tue, 03 Dec 2024 10:34:28 +0000 Received: by outflank-mailman (input) for mailman id 847903; Tue, 03 Dec 2024 10:34: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 1tIQEc-0004s0-Qu for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 10:34:26 +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 29af441e-b162-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 11:34:24 +0100 (CET) Received: from mail-oi1-f197.google.com (mail-oi1-f197.google.com [209.85.167.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-665-3imNtiqfPWiTDY4FPD89Tg-1; Tue, 03 Dec 2024 05:34:22 -0500 Received: by mail-oi1-f197.google.com with SMTP id 5614622812f47-3ea3b6b1930so4122752b6e.3 for ; Tue, 03 Dec 2024 02:34:22 -0800 (PST) Received: from [192.168.0.7] (ip-109-42-51-199.web.vodafone.de. [109.42.51.199]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6d896a2a706sm36364946d6.112.2024.12.03.02.34.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Dec 2024 02:34: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: 29af441e-b162-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733222063; 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:autocrypt:autocrypt; bh=c8+mtyeu29sdyoeKiIX8Wc5RPqMhIGCC9Pt4TP7ecf4=; b=cJqHL1FUPDVrg3aN5BY3BEBlF/rtphem34aLZEAbI6q8hiKviHf2c+rggFNYQWRkrR7Ad8 aH0j5Brin/hbDLKWN/GVcVX+gBm5gyK0vGaBZauHlSEXMA2J9np9py30bCwi+6mvfdkKvs W8MbKIt2XHCqWDr2M1hAO7oGPKmws1Q= X-MC-Unique: 3imNtiqfPWiTDY4FPD89Tg-1 X-Mimecast-MFC-AGG-ID: 3imNtiqfPWiTDY4FPD89Tg X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733222061; x=1733826861; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=c8+mtyeu29sdyoeKiIX8Wc5RPqMhIGCC9Pt4TP7ecf4=; b=KUTV/1Eko5DQ0gbXrvaMESaXC9CCmDdklqeaR2FClxScTFHjBXfHKQ+rL71CbwiFiN +LRHrfskxAqO0AYY2t+fs9fRk1cVgK4II1aYV5wj68U+rFEZTGbPzGdZ6S0QENe1OrdI JF/KDI1PRmzseueZSfBGpL/NcMMSwFjozK2eU2YD+jGtsn5HwiXrD5SzUbR19nJKMkf0 jGhe7lMrATBlVEaH5x4ByG0CfsXi2d3tW7M/5hkcBS034dsJZk24EtYOvSctXgYnjCo2 VpxTRohLy0SH99N5si9HJ8QetqrAj4uNz+Uy5uCHhPKvNQ5oGWtaIU5832DNfJuAL+ml an6Q== X-Forwarded-Encrypted: i=1; AJvYcCUzi+37RLINd7DYhysjL08v7ZaiAVJLIswpGNfnz7MlXxD2AaKjEmp6VzhzmAOax+uIwVdp9Ze1iG8=@lists.xenproject.org X-Gm-Message-State: AOJu0YzkX9WABSa0HCo1s8JoJ/xI6G+J9e9NJ277TmOV1qkiCbrqpSne bz4JqTr/UkII7+3roVKCVeAsbsY1ACzoMNyuq15CFHTMx4gcrC28eihklPFZpcyL8DvRy8WQqG+ IM5TNsIq0YaZ7PFe7Fnsm0Eh/tHUA+PvYwNm5EiZtdfdE/T0kBKxDtrGOSPFuERw6 X-Gm-Gg: ASbGnctbtyqNlcSXZ9QkDHIzOsaBj3A06YzHoCULsmG7m60pemJMC35jjlO8VwcS3gg QMTVWQ5AkbYEpRM4uNqonSy3gegX7Hi44ul/NcYMxObfg/cU9OdDu/euwcH6e8gXYNj6nVEDjpa 6HDLpiBzQ9bKbhq5Z67QFcQjNteLgusERgjdSlf5mWk+GlOV96h8QDE21z2dmOB87oTa8cEoCkt O7/5zs/SypAbjfIHP4PFqDyfNKeB8eRtJMxfB2XIy1nDAy2MgU7Aq6ChMtepmwN5rYVv8OjSHbD 4GZ8og== X-Received: by 2002:a05:6808:e8b:b0:3ea:50a8:4559 with SMTP id 5614622812f47-3eae4f3644dmr2105741b6e.11.1733222061682; Tue, 03 Dec 2024 02:34:21 -0800 (PST) X-Google-Smtp-Source: AGHT+IGuIhxr1AdwQWCioyz4uSMKD/Tml3jp2xw56cENHvBd4LkbxW9BtfirqUCqNBfExKytFJdHMw== X-Received: by 2002:a05:6808:e8b:b0:3ea:50a8:4559 with SMTP id 5614622812f47-3eae4f3644dmr2105729b6e.11.1733222061475; Tue, 03 Dec 2024 02:34:21 -0800 (PST) Message-ID: <0715a97a-5b59-45c9-acd0-a1357a6ffa86@redhat.com> Date: Tue, 3 Dec 2024 11:34:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 6/7] accel/kvm: Remove mentions of legacy '-machine foo,accel=bar' To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= , qemu-devel@nongnu.org Cc: Paolo Bonzini , =?UTF-8?Q?Daniel_P_=2E_Berrang=C3=A9?= , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Markus Armbruster , qemu-arm@nongnu.org References: <20241203092153.60590-1-philmd@linaro.org> <20241203092153.60590-7-philmd@linaro.org> From: Thomas Huth Autocrypt: addr=thuth@redhat.com; keydata= xsFNBFH7eUwBEACzyOXKU+5Pcs6wNpKzrlJwzRl3VGZt95VCdb+FgoU9g11m7FWcOafrVRwU yYkTm9+7zBUc0sW5AuPGR/dp3pSLX/yFWsA/UB4nJsHqgDvDU7BImSeiTrnpMOTXb7Arw2a2 4CflIyFqjCpfDM4MuTmzTjXq4Uov1giGE9X6viNo1pxyEpd7PanlKNnf4PqEQp06X4IgUacW tSGj6Gcns1bCuHV8OPWLkf4hkRnu8hdL6i60Yxz4E6TqlrpxsfYwLXgEeswPHOA6Mn4Cso9O 0lewVYfFfsmokfAVMKWzOl1Sr0KGI5T9CpmRfAiSHpthhHWnECcJFwl72NTi6kUcUzG4se81 O6n9d/kTj7pzTmBdfwuOZ0YUSqcqs0W+l1NcASSYZQaDoD3/SLk+nqVeCBB4OnYOGhgmIHNW 0CwMRO/GK+20alxzk//V9GmIM2ACElbfF8+Uug3pqiHkVnKqM7W9/S1NH2qmxB6zMiJUHlTH gnVeZX0dgH27mzstcF786uPcdEqS0KJuxh2kk5IvUSL3Qn3ZgmgdxBMyCPciD/1cb7/Ahazr 3ThHQXSHXkH/aDXdfLsKVuwDzHLVSkdSnZdt5HHh75/NFHxwaTlydgfHmFFwodK8y/TjyiGZ zg2Kje38xnz8zKn9iesFBCcONXS7txENTzX0z80WKBhK+XSFJwARAQABzR5UaG9tYXMgSHV0 aCA8dGh1dGhAcmVkaGF0LmNvbT7CwXgEEwECACIFAlVgX6oCGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAAoJEC7Z13T+cC21EbIP/ii9cvT2HHGbFRl8HqGT6+7Wkb+XLMqJBMAIGiQK QIP3xk1HPTsLfVG0ao4hy/oYkGNOP8+ubLnZen6Yq3zAFiMhQ44lvgigDYJo3Ve59gfe99KX EbtB+X95ODARkq0McR6OAsPNJ7gpEUzfkQUUJTXRDQXfG/FX303Gvk+YU0spm2tsIKPl6AmV 1CegDljzjycyfJbk418MQmMu2T82kjrkEofUO2a24ed3VGC0/Uz//XCR2ZTo+vBoBUQl41BD eFFtoCSrzo3yPFS+w5fkH9NT8ChdpSlbNS32NhYQhJtr9zjWyFRf0Zk+T/1P7ECn6gTEkp5k ofFIA4MFBc/fXbaDRtBmPB0N9pqTFApIUI4vuFPPO0JDrII9dLwZ6lO9EKiwuVlvr1wwzsgq zJTPBU3qHaUO4d/8G+gD7AL/6T4zi8Jo/GmjBsnYaTzbm94lf0CjXjsOX3seMhaE6WAZOQQG tZHAO1kAPWpaxne+wtgMKthyPLNwelLf+xzGvrIKvLX6QuLoWMnWldu22z2ICVnLQChlR9d6 WW8QFEpo/FK7omuS8KvvopFcOOdlbFMM8Y/8vBgVMSsK6fsYUhruny/PahprPbYGiNIhKqz7 UvgyZVl4pBFjTaz/SbimTk210vIlkDyy1WuS8Zsn0htv4+jQPgo9rqFE4mipJjy/iboDzsFN BFH7eUwBEAC2nzfUeeI8dv0C4qrfCPze6NkryUflEut9WwHhfXCLjtvCjnoGqFelH/PE9NF4 4VPSCdvD1SSmFVzu6T9qWdcwMSaC+e7G/z0/AhBfqTeosAF5XvKQlAb9ZPkdDr7YN0a1XDfa +NgA+JZB4ROyBZFFAwNHT+HCnyzy0v9Sh3BgJJwfpXHH2l3LfncvV8rgFv0bvdr70U+On2XH 5bApOyW1WpIG5KPJlDdzcQTyptOJ1dnEHfwnABEfzI3dNf63rlxsGouX/NFRRRNqkdClQR3K gCwciaXfZ7ir7fF0u1N2UuLsWA8Ei1JrNypk+MRxhbvdQC4tyZCZ8mVDk+QOK6pyK2f4rMf/ WmqxNTtAVmNuZIwnJdjRMMSs4W4w6N/bRvpqtykSqx7VXcgqtv6eqoDZrNuhGbekQA0sAnCJ VPArerAZGArm63o39me/bRUQeQVSxEBmg66yshF9HkcUPGVeC4B0TPwz+HFcVhheo6hoJjLq knFOPLRj+0h+ZL+D0GenyqD3CyuyeTT5dGcNU9qT74bdSr20k/CklvI7S9yoQje8BeQAHtdV cvO8XCLrpGuw9SgOS7OP5oI26a0548M4KldAY+kqX6XVphEw3/6U1KTf7WxW5zYLTtadjISB X9xsRWSU+Yqs3C7oN5TIPSoj9tXMoxZkCIHWvnqGwZ7JhwARAQABwsFfBBgBAgAJBQJR+3lM AhsMAAoJEC7Z13T+cC21hPAQAIsBL9MdGpdEpvXs9CYrBkd6tS9mbaSWj6XBDfA1AEdQkBOn ZH1Qt7HJesk+qNSnLv6+jP4VwqK5AFMrKJ6IjE7jqgzGxtcZnvSjeDGPF1h2CKZQPpTw890k fy18AvgFHkVk2Oylyexw3aOBsXg6ukN44vIFqPoc+YSU0+0QIdYJp/XFsgWxnFIMYwDpxSHS 5fdDxUjsk3UBHZx+IhFjs2siVZi5wnHIqM7eK9abr2cK2weInTBwXwqVWjsXZ4tq5+jQrwDK cvxIcwXdUTLGxc4/Z/VRH1PZSvfQxdxMGmNTGaXVNfdFZjm4fz0mz+OUi6AHC4CZpwnsliGV ODqwX8Y1zic9viSTbKS01ZNp175POyWViUk9qisPZB7ypfSIVSEULrL347qY/hm9ahhqmn17 Ng255syASv3ehvX7iwWDfzXbA0/TVaqwa1YIkec+/8miicV0zMP9siRcYQkyTqSzaTFBBmqD oiT+z+/E59qj/EKfyce3sbC9XLjXv3mHMrq1tKX4G7IJGnS989E/fg6crv6NHae9Ckm7+lSs IQu4bBP2GxiRQ+NV3iV/KU3ebMRzqIC//DCOxzQNFNJAKldPe/bKZMCxEqtVoRkuJtNdp/5a yXFZ6TfE1hGKrDBYAm4vrnZ4CXFSBDllL59cFFOJCkn4Xboj/aVxxJxF30bn In-Reply-To: <20241203092153.60590-7-philmd@linaro.org> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: K-D1k4kVfrqXovhNQhvie_CykjCGqUwG7VfWCaSgLOM_1733222061 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 03/12/2024 10.21, Philippe Mathieu-Daudé wrote: > Since commit 6f6e1698a68 ("vl: configure accelerators from -accel > options") we prefer the '-accel bar' command line option. > > Update the documentation when KVM is referred to. > > Signed-off-by: Philippe Mathieu-Daudé > --- > docs/bypass-iommu.txt | 3 ++- > docs/nvdimm.txt | 2 +- > docs/specs/tpm.rst | 2 +- > docs/system/arm/cpu-features.rst | 2 +- > docs/system/cpu-hotplug.rst | 2 +- > docs/system/ppc/powernv.rst | 2 +- > docs/system/ppc/pseries.rst | 4 ++-- > scripts/device-crash-test | 2 +- > 8 files changed, 10 insertions(+), 9 deletions(-) Reviewed-by: Thomas Huth From xen-devel-bounces@lists.xenproject.org Tue Dec 03 10:36:15 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 10:36:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847911.1262948 (Exim 4.92) (envelope-from ) id 1tIQGM-0005nh-JV; Tue, 03 Dec 2024 10:36:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847911.1262948; Tue, 03 Dec 2024 10:36: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 1tIQGM-0005na-Gi; Tue, 03 Dec 2024 10:36:14 +0000 Received: by outflank-mailman (input) for mailman id 847911; Tue, 03 Dec 2024 10:36: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 1tIQGK-0005nN-DK for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 10:36:12 +0000 Received: from EUR03-VI1-obe.outbound.protection.outlook.com (mail-vi1eur03on2062e.outbound.protection.outlook.com [2a01:111:f403:260c::62e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 68774d29-b162-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 11:36:09 +0100 (CET) Received: from AM6P195CA0085.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:86::26) by PA4PR08MB5952.eurprd08.prod.outlook.com (2603:10a6:102:e9::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.19; Tue, 3 Dec 2024 10:36:04 +0000 Received: from AMS0EPF00000196.eurprd05.prod.outlook.com (2603:10a6:209:86:cafe::b7) by AM6P195CA0085.outlook.office365.com (2603:10a6:209:86::26) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.17 via Frontend Transport; Tue, 3 Dec 2024 10:36:04 +0000 Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AMS0EPF00000196.mail.protection.outlook.com (10.167.16.217) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 10:36:03 +0000 Received: ("Tessian outbound 3b1f0cd68b0e:v514"); Tue, 03 Dec 2024 10:36:02 +0000 Received: from Leebd2d869ec8.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 558BAF45-EE58-4BFA-9280-EFED15AA8A0C.1; Tue, 03 Dec 2024 10:35:56 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id Leebd2d869ec8.2 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 03 Dec 2024 10:35:56 +0000 Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21) by AS8PR08MB8874.eurprd08.prod.outlook.com (2603:10a6:20b:5b8::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 10:35:49 +0000 Received: from DBAPR08MB5798.eurprd08.prod.outlook.com ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com ([fe80::4a66:d3e2:570:9632%5]) with mapi id 15.20.8207.017; Tue, 3 Dec 2024 10:35: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: 68774d29-b162-11ef-a0d3-8be0dac302b0 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=tV51WzxR6ko9i3GrPjzjHnpmlzsxcL2kKeS8HZdtxwY7wSiQIV31BldFv0Eu8NkT4UVYj43Vipi45FBDJVoJrxltOrdI5ZNAdkIRgIZO+VTNXJ1TgD4bVFdR6AAuaFeNJws8/crl7cDcxUfrNtpPWJs+FZOY9FeqbWOjFM/cglSpV7uGWUhX0KKMPaj1Lur+0+v6TsVNzuNon2nWN+NA/acqMLTam2Fl9SP2tmlJGziyDyLMt7OLY8+vFOn0GwFWjQ3DT/ZGE2Er7sYaplF1HlToRN0bJfAlLzhPdVZmhs4/hGRgtW0U4UFvAkdmmRgxlqGvkcvH+0GVYpRjM/K/AA== 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=zqpGvx/DKaZfbGFyKM6NO+fx+CIiYkQzdSiWawj89bI=; b=hg17gnkyTcsoe0olsm/DnRrIo142oV4QMA7Zerib/KmOq/q26/2qL8gPZWXB8RP/6jusT9kxKrN60Uo3mHJx7niW6QLAlBEM2QC7E/ZxTs1qGVRcrS1bLDOYfBFxDLAb9X57phB+NVdVnO2BPqGkZ9E5dnTWdws2tVq5PLll0CrSi+coOuteAvgYtUyvTHElJm0FHRMGtLlo3PFFNhtQ02soitfJ/z+rlPvNz4wetLI+ssqe14/ttHEROi2ulK8HaI7Jd9O5wYMalxkK3W7ipHTzhcEyMFealVhYfRLbe4slLi9L4kyBiJ3qLrfhdgLlVcKNF/nFfeahhmX1CKycyA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=zqpGvx/DKaZfbGFyKM6NO+fx+CIiYkQzdSiWawj89bI=; b=a7W2AJe0Joxb3jcNTXqchVFR2x/KXaIWt+KVv7SLZEz6OopNt/PVhSyNh8tFErm+H3x7SLwvT37u2nG4Dfxuq0bRMZWffx7mud6skixlKgDdrVKACsE/quTO5hzDZJ5Ptx6zrh/5aeGE4nUo0MsOTXqrN5H7+IzY4c+WoJzEa48= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) 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 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C X-CheckRecipientChecked: true X-CR-MTA-CID: 40b8cb1df06dcf98 X-TessianGatewayMetadata: ugqjC5HMuAf5nqrc+Kkz3/pCQ+sFO/UQoaXtzxYSOm3zgwdFp0V4ZquSOkd5t6B+Gepo8t8XWsQFurHDUpfmJJ03bTb5K8kA0LHrlMX+ip+lkhEUK0bBwmD4NgbKPGyN30SjlkfzDQ2Tj0q220eyoAKWi8OAXDC+FpnZB99eOKU= X-CR-MTA-TID: 64aa7808 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RC1txj8SnYbmWWZUdAi+58wFS3oX9qmm5A0c8tas2zP6cHACmCT0RdhnuRxhEG4nyKFNdYmxAhQURbKVbP1EJiyb71RrGpCELk4jcjYZV1OBUdE20ObFO4b8tUjlXa30LMR6o6p7sYznPcGYkeYk91S9d1o6hZLF14P6XuDhg53n/yaOukA/iJqsupAQmKXXoU3hIY9HU6LttjDMrrMlEOMZ8ISxb6+Fi5Fx8f/24P8kBC8liIpw4Xje0i9yquODG2AaoI49tYdo2gIC9T+SZnj2gIIX0OybMSiS/yizANyUqM/TFtHlG8iMZUSjVlml/yO9mZH/oVgARABzWi9TJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zqpGvx/DKaZfbGFyKM6NO+fx+CIiYkQzdSiWawj89bI=; b=YGHqXY1WK7+Accq0PqTae00Qe3CCJJPo3EuxPWwQY38r71/ySe9kPosT0GFcXSM4mKlQwdC/nOHaXZlcOHqzGP/shKFAd/nzYI3MXAjoJz4YTARZTFKoO5/6Yj7bbx/qgounhm4eVD1P4pnAvS+4EicwCB001bl9C+6x1hJcK/CpY8DMNQ1mxucIm6lh7BQBN2EQmbJz15lPEzsRcYpevt9nGkS9RxG2GWitViMgl0cbMPWKxKpjeL/bf7WaNzdJHM50Bar49dglpTq7dLgBR1Sz8b5NL6/mEl5US87sq856aevfHK9RcLZow1qW+YAkHx/HkQHTazew1bYnBOS0QQ== 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=zqpGvx/DKaZfbGFyKM6NO+fx+CIiYkQzdSiWawj89bI=; b=a7W2AJe0Joxb3jcNTXqchVFR2x/KXaIWt+KVv7SLZEz6OopNt/PVhSyNh8tFErm+H3x7SLwvT37u2nG4Dfxuq0bRMZWffx7mud6skixlKgDdrVKACsE/quTO5hzDZJ5Ptx6zrh/5aeGE4nUo0MsOTXqrN5H7+IzY4c+WoJzEa48= From: Luca Fancellu To: Julien Grall CC: Jan Beulich , Volodymyr Babchuk , Andrew Cooper , Stefano Stabellini , "xen-devel@lists.xenproject.org" , Anthony PERARD , Ayan Kumar Halder Subject: Re: [PATCH 3/5] build: arm64: provide -target and -march if using clang Thread-Topic: [PATCH 3/5] build: arm64: provide -target and -march if using clang Thread-Index: AQHbRPo1JX+4yJsUxkavQ6TQ6Lnjf7LUVCKA Date: Tue, 3 Dec 2024 10:35:48 +0000 Message-ID: References: <20241129014850.2852844-1-volodymyr_babchuk@epam.com> <20241129014850.2852844-4-volodymyr_babchuk@epam.com> <87iks5bsgd.fsf@epam.com> <8df584b8-fb23-4db4-af87-903fde91e42e@xen.org> <6d4134c9-25ac-4b16-9928-2a4bdc48d996@xen.org> In-Reply-To: <6d4134c9-25ac-4b16-9928-2a4bdc48d996@xen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3826.200.121) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DBAPR08MB5798:EE_|AS8PR08MB8874:EE_|AMS0EPF00000196:EE_|PA4PR08MB5952:EE_ X-MS-Office365-Filtering-Correlation-Id: 6ddba862-0f63-41f2-a0df-08dd138649a9 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|38070700018; X-Microsoft-Antispam-Message-Info-Original: =?us-ascii?Q?M24G/fjeQMuSXHfROy/H3bSAgB99ZYIJHVerW/2ZI2COTjQtAjSjXqTrWmZJ?= =?us-ascii?Q?lAvanCh28Doc9TcRk8lFy0TGC3HZoQaqWqKe5Ceqv1HXDMxyuQTVsU49nSeb?= =?us-ascii?Q?dQjSyTjZYIqw5bUUuOKrVnsuLe5rUHu1krHoz5zz8lGYaEbMckFCXLSUuV1T?= =?us-ascii?Q?RiKciYklTfEsZ55jad/dTUFJMxOMWfoIwYkXobHt/xfPm1X3SviVPt3+bPVx?= =?us-ascii?Q?uSDDFXLZ0ODlKjG+x2fAF/52y4dtWpvjdPNtHlrMtukvU0DcBH5h2XZzVv8v?= =?us-ascii?Q?OmoGJHUNWCdYIAYcWMVjZ1MAgqzIkpx3mST1DSghnXKLVewpYlAIA8O7n3k+?= =?us-ascii?Q?0XHqJUX5qGRXDMWDeQ1Y43JsH0B9xM/njODZKDrgzcNvbUgxYFZOMSOGAi/2?= =?us-ascii?Q?gC8sT4vW4V5Rjy++U37JAAyU+44//BPKEB72jQ8sJicQdTz6OD5HDF1D1/dK?= =?us-ascii?Q?TALN3mMypcEiK/uvvzYAJtyqBgxEu07wRRnpSP7h151eiRNiqc/qtb57K4Du?= =?us-ascii?Q?BqmD0OAE9/ow8/2sTQXID2SpsOGW+C+yIrI+48m/jbi1W0JWdlv/vG2s9pir?= =?us-ascii?Q?QTCF/tXengzD2Rh0qMrS07+YuC15cie5TKszYZOVY9mMfnAR9kM28B8qSVCS?= =?us-ascii?Q?Zy5eRKR3HHN4wsdDXH1bPuutO9wH4CkMFwuxXZl8Hz9+Bv+BSjDyu3PVuKJV?= =?us-ascii?Q?w+Ant0DG8fUbEVPVn5nictwyjNr3GJAKK0BVfOLtJ7lOxjeGYCmPgVnexwAA?= =?us-ascii?Q?l0jOtKTHo7mUArkCK+A7OBtFE4DAPVgpUR7SHQTV71/KUOK0H1nTC3Pnq4VY?= =?us-ascii?Q?RXFM7LDqpERmisoXVeFur8Gi/7KPwuKDM0J6SME7kUqicGM7fQBd17RSVyS6?= =?us-ascii?Q?PIqo9OQBMtruHp7HTpjNu3MiP2DZa21MHTq6wO+y04sFIkaFd+xKHSH6UgfC?= =?us-ascii?Q?jmd8tspK1TVFalxubPSQEagwuZpjcdezcMMl5Hgg45O5FP9k/lU1Txy2ZY3X?= =?us-ascii?Q?S+OIfY+4qIoAg6SLEo7EgBHxbANeAuan9bg246Z+A2DzTsfz8vg+bjTkm7Pl?= =?us-ascii?Q?/QOo3YXw9a2qtXaXUgFyI5zgTFw4xWRq5pWBkMRl8fuijx+PnV8h1uzgQ4k0?= =?us-ascii?Q?mogSa7qPjv1gHBn3KunceADJTfHZbFisBjCTBV5qX7xjHYYtX9Vjhzaug+tP?= =?us-ascii?Q?4xASuTGYPhEsxOQhHYPCUf9FXMb2R+Apb8Q9lFmeoNHYNmHmFjDxxGOiS5hV?= =?us-ascii?Q?P4KwqOuuO5lcdiu14w2Qc6ZcrF3u8XR1O5Q359AH7o395flxDh2FLGul3WHk?= =?us-ascii?Q?wUQn2KzIv/ZSnpErfXs6CkMQXIc7jpPGLO44BBIhRrmO8tVb3nnRyisOHO4w?= =?us-ascii?Q?/42J7ZsdYTF0vGYO83nHmOu0vxxY0k8yANRulnWdrlg0QT1NVA=3D=3D?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: <472F1D44DFC4AC4DBF1CD70720AED2E6@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB8874 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-SkipListedInternetSender: ip=[2603:10a6:10:1a6::21];domain=DBAPR08MB5798.eurprd08.prod.outlook.com X-MS-Exchange-Transport-CrossTenantHeadersStripped: AMS0EPF00000196.eurprd05.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 1be35616-8856-497d-b48c-08dd13864071 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|35042699022|14060799003|82310400026|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?WhMMFMEGvAPFvYxiIU87fwIJHq55deaj9YzxJI/w4+XBlywYV93/OXSDiJYY?= =?us-ascii?Q?LFs2CtjWoEaQzHEdFoVjwqJRRhi5juli7DXdyrbMdN8/RAxgeiKVTV85GlwU?= =?us-ascii?Q?tabjg6yeJdzABzozkXVhGpY4+ObTUTamaFw53WZm5teZiYF4Ajyy/RefMT/H?= =?us-ascii?Q?8FbxubSt+e4E+EkP1NUc5pfG6ezuCEk73v0IBEgoT9JatM1cM+Wot/efwAdk?= =?us-ascii?Q?XKH1fwGEwXRi/TI5EcKRNA9vi1F/gkUqRng4nFfIGrdyz2JIXnC0N3RnOlIC?= =?us-ascii?Q?N99K8NHYtHQn7ZdtdANhrL5ZV1S0hcNTAdXJORaOTaprIKyv49xtaj4xzfob?= =?us-ascii?Q?aNtQzMu1cUrw019s52rWkHHEfse4jF1B/+ozbaAuIqsTio2PGdCYthPEuxD+?= =?us-ascii?Q?STTvs1spRtElBo0294JiUO56t2qs47esTY9968Y4TM/wT2xrzHYZaB2J56IS?= =?us-ascii?Q?wzEnz+iS7WD6q5cuRtqYjhY4J3LUtZscwp6KvDiTmDE5AnW3JPRf4OI0RsSa?= =?us-ascii?Q?SgMBa3/zh1+ICXFapcp5mk+EO267jdfHwueB3gNZ9MmcwbfDvhAGnhNCcJTt?= =?us-ascii?Q?d55J/04tyrVnzE0AC5rtF6n8LL2PUdCAZsEJbFmBAEMS/PsRW45FU+5MYE3Y?= =?us-ascii?Q?I4erUMaRDa41wI80HSNNYMtHitaMlVuGXGr/CUN0olrw8baRlddhBPDaTeN2?= =?us-ascii?Q?FR2g31UceAUp5kdfpIk2oyTfTsn8Yodh9r4aPjaWnl7wKLW/9y0Hy37Zgen+?= =?us-ascii?Q?OBtZGPLrEtobB8d7P1tbJnXGQOppud+1nmmobJAdBKzoGblMmpNcATzYVn64?= =?us-ascii?Q?Bg2AAgYKn8cnpFD/JKCESZlHKumgLsrEaZJgXJjQl5tWIQ32gRKevjeEh9tA?= =?us-ascii?Q?HpJPwC06+JhqmQVOWKLSiMLK7XOGV/ny3ljv5/cmHQ1DnlszJRV1fEDA30+Q?= =?us-ascii?Q?+w1mr99T04YpOjmflpFslBo+xT5bUyugzzzf8+dy+1FKG2PgsFqZag0LQxqr?= =?us-ascii?Q?we1RTwAnW68Q8DG8aGxSAEerhCcbztwOft+HdD1oXGfDGrRFehVNwue7a1d2?= =?us-ascii?Q?r6s84a7SNW+HSUKoLds5ffHa9o589hClQbw66Jo+OORzQ1rVcG1Uvrz/mAZa?= =?us-ascii?Q?3oH898gPfIj4dLJaJVcOy7c4PBnu8yIOclgw7gJEgfbpjmQsWSYBRwjqiNWJ?= =?us-ascii?Q?HiCBb04/mYYV1mwgFbV3yV4hAwjAdKQLiXWYlvXQ7sy2DciyUx5/guGfuhxY?= =?us-ascii?Q?bwTISwLx1VZzBYnt0FzKYIRgCZD1KscZ2ZW4fGOuMMypKZ3jWsCAjHyzEcBs?= =?us-ascii?Q?/6T7fvND+ILdeWjM7XlnGH5mgluKa9wtRHA+I2OyC5/K0V648pli21I4CaBo?= =?us-ascii?Q?DEm/tPHUFtrMtwNrY+eHOM4PrqgJ4TuKYAH2elHtnvFPdUtx4YOnrAqFCh6S?= =?us-ascii?Q?1KMkfYD5RLg7+vCVF14WBgocEZbcWVpe?= X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(35042699022)(14060799003)(82310400026)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 10:36:03.8096 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6ddba862-0f63-41f2-a0df-08dd138649a9 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AMS0EPF00000196.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB5952 HI, > On 2 Dec 2024, at 20:38, Julien Grall wrote: >=20 > Hi Jan, >=20 > On 02/12/2024 07:52, Jan Beulich wrote: >> On 30.11.2024 18:15, Julien Grall wrote: >>> On 29/11/2024 22:12, Volodymyr Babchuk wrote: >>>> Jan Beulich writes: >>>>> On 29.11.2024 02:49, Volodymyr Babchuk wrote: >>>>>> --- a/config/arm64.mk >>>>>> +++ b/config/arm64.mk >>>>>> @@ -5,6 +5,10 @@ CONFIG_XEN_INSTALL_SUFFIX :=3D >>>>>> CFLAGS +=3D #-marm -march=3D -mcpu=3D etc >>>>>> +ifeq ($(clang),y) >>>>>> +CFLAGS +=3D -target aarch64 -march=3Darmv8-a >>>>>> +endif >>>>>=20 >>>>> Why is this dependent on (just?) $(clang), not (also?) $(llvm)? >>>>=20 >>>> Because this parameter is handled by clang only. There is no harm in >>>> providing it explicitly. When building on arm64, value of this paramet= er >>>> will match the default value for the platform. When building on x86, w= e >>>> need to tell clang that it should generate arm64 code anyways. There i= s >>>> no reason in trying to make ARM build with x86 instruction set. >>>>=20 >>>>> Also >>>>> this affects both toolstack builds and hypervisor. Is applying -march >>>>> like this actually appropriate for the toolstack? >>>>=20 >>>> This is a good question. I can't see why this can't be appropriate for >>>> toolstack. I.e. what bad can happen when building the toolstack. >>>=20 >>> In the future, we may want to build the tools for Armv8-M. So I think >>> the -march should also applies for the toolstack. >> Perhaps I don't know enough of the Arm world, but: Wouldn't it be possib= le >> to build a tool stack suitable for a wide range for Arm64 flavors, while >> requiring more targeted hypervisor binaries? >=20 > Good question. There are some commonnality between ARMv8-M and ARMv8-R bu= t I am not sure whether it means we could use -march=3Darmv8-a build and ru= n on ARMv8-M. Adding Ayan and Luca. AFAIK a binary compiled for armv8-a aarch64 will work also on armv8-r aarch= 64 since they share almost everything apart from some MPU registers, instead in order to work on armv8-m we might need to pass the appropriate m= arch Cheers, Luca= From xen-devel-bounces@lists.xenproject.org Tue Dec 03 10:36:16 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 10:36:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847912.1262954 (Exim 4.92) (envelope-from ) id 1tIQGM-0005qs-Td; Tue, 03 Dec 2024 10:36:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847912.1262954; Tue, 03 Dec 2024 10:36: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 1tIQGM-0005qj-OI; Tue, 03 Dec 2024 10:36:14 +0000 Received: by outflank-mailman (input) for mailman id 847912; Tue, 03 Dec 2024 10:36: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 1tIQGL-0005nN-2r for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 10:36:13 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2061c.outbound.protection.outlook.com [2a01:111:f403:2614::61c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 68101d05-b162-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 11:36:08 +0100 (CET) Received: from AS9PR05CA0341.eurprd05.prod.outlook.com (2603:10a6:20b:490::27) by DBAPR08MB5752.eurprd08.prod.outlook.com (2603:10a6:10:1ac::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.19; Tue, 3 Dec 2024 10:36:04 +0000 Received: from AM3PEPF00009B9F.eurprd04.prod.outlook.com (2603:10a6:20b:490:cafe::57) by AS9PR05CA0341.outlook.office365.com (2603:10a6:20b:490::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.17 via Frontend Transport; Tue, 3 Dec 2024 10:36:04 +0000 Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM3PEPF00009B9F.mail.protection.outlook.com (10.167.16.24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 10:36:03 +0000 Received: ("Tessian outbound 3b1f0cd68b0e:v514"); Tue, 03 Dec 2024 10:36:02 +0000 Received: from Leebd2d869ec8.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 993D9F97-1532-4EC8-90E2-A1E6B720DAF6.1; Tue, 03 Dec 2024 10:35:56 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id Leebd2d869ec8.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 03 Dec 2024 10:35:56 +0000 Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21) by AS8PR08MB8874.eurprd08.prod.outlook.com (2603:10a6:20b:5b8::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 10:35:50 +0000 Received: from DBAPR08MB5798.eurprd08.prod.outlook.com ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com ([fe80::4a66:d3e2:570:9632%5]) with mapi id 15.20.8207.017; Tue, 3 Dec 2024 10:35: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: 68101d05-b162-11ef-a0d3-8be0dac302b0 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=slku8J403dkRDUAknjy0/E3wGIngc95KzzgODjhqYAA+MzCEuaIR2k+fEgkId7e437gqyYD9h2PsI3LeZK9v/F7nVWO443Yv1Vi4UUx5s/NGxUE6Mb0gKrxkREr9OwUku46qA4f01iZwPBnfT7E2zlMPyAREhO6zTrZ977plnxVfHnWxfNyUYK0SgQk7fM9sGQF6HSrz6clQZLBOqSRWIjvVVeHslMD4F/Ck1EgjHRdHCuNGAkhLGpjj5GU4P1olXAYT/i+d4YeRZXuMqtMKaHyjTnF9d5XcSvql1kBpuhI6cXV1h87xF3TnZMFCJ0WCjEmSP0osR9qkPJhOeJTvaQ== 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=zqpGvx/DKaZfbGFyKM6NO+fx+CIiYkQzdSiWawj89bI=; b=hg17gnkyTcsoe0olsm/DnRrIo142oV4QMA7Zerib/KmOq/q26/2qL8gPZWXB8RP/6jusT9kxKrN60Uo3mHJx7niW6QLAlBEM2QC7E/ZxTs1qGVRcrS1bLDOYfBFxDLAb9X57phB+NVdVnO2BPqGkZ9E5dnTWdws2tVq5PLll0CrSi+coOuteAvgYtUyvTHElJm0FHRMGtLlo3PFFNhtQ02soitfJ/z+rlPvNz4wetLI+ssqe14/ttHEROi2ulK8HaI7Jd9O5wYMalxkK3W7ipHTzhcEyMFealVhYfRLbe4slLi9L4kyBiJ3qLrfhdgLlVcKNF/nFfeahhmX1CKycyA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=zqpGvx/DKaZfbGFyKM6NO+fx+CIiYkQzdSiWawj89bI=; b=a7W2AJe0Joxb3jcNTXqchVFR2x/KXaIWt+KVv7SLZEz6OopNt/PVhSyNh8tFErm+H3x7SLwvT37u2nG4Dfxuq0bRMZWffx7mud6skixlKgDdrVKACsE/quTO5hzDZJ5Ptx6zrh/5aeGE4nUo0MsOTXqrN5H7+IzY4c+WoJzEa48= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) 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 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C X-CheckRecipientChecked: true X-CR-MTA-CID: 40b8cb1df06dcf98 X-TessianGatewayMetadata: OtZdU2y71sAMOzzfsLy3EC/Oj8R+znEnF05fX5SvOCNzHA7WSVQ/AnAsSkTeLKyrrgXEY7psrgnTyEzZI+V1SPPtbyPhIBBZHP9Z9LGQqQ2liG52Mm02ss76vj23nO2Jtgt7PRnbanFYYfAFcig8r8i5XefYPsf8Xmu6K/VgqWk= X-CR-MTA-TID: 64aa7808 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=GvY9+h6/5gwCAzPXpYiK73mNEVrL4LyA8NT/n3wfnNnHj4wPDw0v0LdISi2YDzpToY8W4CgsNWWmmrA7zMt9h2G4Ki2He9DSfU+CkDVk38joFZjhWa1GHMhRNEJmFRSwH05in9RO9Gx+PxiF07EwuOZYTqo17pYXvVBlYEgCcyx6pyfSYvDJOZIw3J1cMsBeae9zCSpBjTw3nbZD8cHdfou8ilrHXQQoAThCh4CSVOqQq1HAxbzVC+SathsH/YjM/AGmdxJYx+igyEIq5yyzVNW7qk+BGDJ9qRLr/1cmGphoruOiUaTJWKUIU213pRDU/6kJt9CaPxFrErqA0NVVFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zqpGvx/DKaZfbGFyKM6NO+fx+CIiYkQzdSiWawj89bI=; b=cTILu3z3Yy7NPQdG+433SXFA/xZevstRCrhgHtEM6XxIoXHxjG32kZlwJ0CclIJYyFexhITMyFELrgjdNFhPRErg6eTSsit95whZ31QUSLRyX0GzW8mVO8l0LCGyJ+qQWqqur5N2eDDYBaLrGzPl88EvxQdcPIzf65wQzySfKPOHwbx2k1+PW4UiHcGu28VSyAe5idJ9PeRvWoA23d7X/Yyztx62lW9i7aV8fpj8HR2Cep1X0+alpDzdf+3ICduIfjZ102RWUSZxohTZiyHPKg2iz9TiHfi7OiyuWWW2a9J2pLvazC4TB/T2AHO0AWX1PH20kWd/V/BxNwBxnVLXoQ== 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=zqpGvx/DKaZfbGFyKM6NO+fx+CIiYkQzdSiWawj89bI=; b=a7W2AJe0Joxb3jcNTXqchVFR2x/KXaIWt+KVv7SLZEz6OopNt/PVhSyNh8tFErm+H3x7SLwvT37u2nG4Dfxuq0bRMZWffx7mud6skixlKgDdrVKACsE/quTO5hzDZJ5Ptx6zrh/5aeGE4nUo0MsOTXqrN5H7+IzY4c+WoJzEa48= From: Luca Fancellu To: Julien Grall CC: Jan Beulich , Volodymyr Babchuk , Andrew Cooper , Stefano Stabellini , "xen-devel@lists.xenproject.org" , Anthony PERARD , Ayan Kumar Halder Subject: Re: [PATCH 3/5] build: arm64: provide -target and -march if using clang Thread-Topic: [PATCH 3/5] build: arm64: provide -target and -march if using clang Thread-Index: AQHbRPo1JX+4yJsUxkavQ6TQ6Lnjf7LUVCKA Date: Tue, 3 Dec 2024 10:35:48 +0000 Message-ID: References: <20241129014850.2852844-1-volodymyr_babchuk@epam.com> <20241129014850.2852844-4-volodymyr_babchuk@epam.com> <87iks5bsgd.fsf@epam.com> <8df584b8-fb23-4db4-af87-903fde91e42e@xen.org> <6d4134c9-25ac-4b16-9928-2a4bdc48d996@xen.org> In-Reply-To: <6d4134c9-25ac-4b16-9928-2a4bdc48d996@xen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3826.200.121) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DBAPR08MB5798:EE_|AS8PR08MB8874:EE_|AM3PEPF00009B9F:EE_|DBAPR08MB5752:EE_ X-MS-Office365-Filtering-Correlation-Id: 3120b73c-19bc-4f5a-2ff6-08dd138649b1 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|38070700018; X-Microsoft-Antispam-Message-Info-Original: =?us-ascii?Q?0k/FyMWfjDOP8axd7CW4MkO4G2cfa8yZP1TETrB002Vsll++7SzgMNQtWtkw?= =?us-ascii?Q?0EKhg8aeblZi1st9bIkfaSWRUxUnUQxpBkHZB91qni3KnVJwuO1jct4n1Rn8?= =?us-ascii?Q?7u2PZJ0ygJ0mSrMBe0ekM16GYADeZBG042fo89yuf65Js2g5Ztx7KAJDCEy5?= =?us-ascii?Q?oklnp3K3Ch9ukQtKeQEnTqZoMB7JoNtn8vA7QVLDM35PFrpD2+YG3+Vc8cMZ?= =?us-ascii?Q?KJD+T36TuC7imz5/qkcUAXLSV1GS3bjkNX3Noe9b2ZJGUNkKfO3IX+ttn1D1?= =?us-ascii?Q?GWphBRSZiGeKvtne0+2dUPSMlEeoaWn1U1FGmwwAhQdIuAs44/mNeVkdJLRQ?= =?us-ascii?Q?9BH46kYTgtqIaxQrpVyphklM9Z0T9Ie8Hdkqvijp0XhQoH7txgTKwhDMqzdx?= =?us-ascii?Q?OtcQpdDkSfVqgOlBfSWm2uw3pvpQOcr9/gS92Y9TyhJ+qD9P0fC9fTZMfvtr?= =?us-ascii?Q?qq4XMguNpGC6a78s/nbmx5b4hLyPJAosQxXFxVS1M9wigOgGMnT2HZOfmBub?= =?us-ascii?Q?nPdkgAUQnxrNf7Po2f2A7GuuTF/03RFOBq3mB24v/ReaNsabPOe6O3FRV+3l?= =?us-ascii?Q?zh8uGPh6QVzx5+i5cgSOTx5zEk3Qq0lSVIp8BjkUj0OKakJJ2Il9/C1hAAP6?= =?us-ascii?Q?RRSKr/2zin/S0lhuq8jtMtsGoCZzJizp7edkAUuGWZ5yxktMPHj3vflFmKAj?= =?us-ascii?Q?yPFi/RowyuKaJFgPxVBo58LNBlptQJFNd84/NcsnzJbJ8Ly/JX1NAkcG7eex?= =?us-ascii?Q?dg0c0knH0mUcnlocLGLZtG2uR8g78Nvvul/9MsLDcZCa7IiX3J63O2GVVaNu?= =?us-ascii?Q?nS+hpc7pwRdhBB+4Upt96ZHF/b4WrpuFQ7KXBv6DgeQ+MDAX//wgIXTUhLje?= =?us-ascii?Q?ruXmwnLxZJAiIhC0VoQ7jXeHSUkr0AO9JtraK6kOlnMe6ICSxJCKsw8+3tE1?= =?us-ascii?Q?f8sOgR9UFQG4WtAHEAhGicttgv3Du80dpy/xNNH9ypWlwNpI4EQNAP/s0bUh?= =?us-ascii?Q?CXvqtkChZ+j4BH9CVq+dNGoeY7B3dV9Wk/h8MMz+jWAPDjoGGtLGxNWkrbZp?= =?us-ascii?Q?WUy9jVD6f6oWXI/GbB4r+Z+6ZifZdSWAbBSCGvkutFlqBW5oBDjw6jdnfunN?= =?us-ascii?Q?H9sh6UAfKXVvC/QFqbViM8Qtknc6lBzSf9ltoPylEHe/sYhinIECqZg+9NOe?= =?us-ascii?Q?ERMaDbcgiPpgK9fDI1WREjCyCQdOFrk8Q9/sVbsB3JH7X2xi72rcawHhFYgj?= =?us-ascii?Q?XR0nUqE59L0z0GnAxyPGt3zYIbx6YBTBkdt99/AxbPfzuHGy1bm/37azZUnJ?= =?us-ascii?Q?45S+vSCcUjLUvOJ5TGeyiDG+EGJ5oTZdMniLeXHV8SCOTFQDOIXeHBbA7o0f?= =?us-ascii?Q?dVUYp7uLckps6+cjt3v6nifubCYXD8WD4ntcNLvAzTQj4ATCqg=3D=3D?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB8874 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-SkipListedInternetSender: ip=[2603:10a6:10:1a6::21];domain=DBAPR08MB5798.eurprd08.prod.outlook.com X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM3PEPF00009B9F.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 4711b94c-286b-4fce-da57-08dd13864166 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|14060799003|36860700013|35042699022|376014|82310400026; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?gcOr3cZrrKm9QgClLUGeNtB6vDcNPJ8VE2FF5CoiPHHVq/oOUy0DG/TrY31s?= =?us-ascii?Q?jXkiEQEptFcXJp/t1r8sKJLAE5k3Gf5iOeJqiQQhEmbQDDN3f46DUkuQOogU?= =?us-ascii?Q?q3jMUKSTvxpvHg9E/5h7E9HeU/CQJrHEPAuLm9LStU4QDu5NSqF71q99C9+O?= =?us-ascii?Q?9mSbLMzwxmMBbNOQtP4rtXpB5MgFv8aNanJUGtDesnmcGj9DKb+ujc3aLEf4?= =?us-ascii?Q?DdH/u54LilGtlYaGlNFk6gS4L+CYbGIDmfyPAXJphk47uBmxZ2UcEvhHFCsD?= =?us-ascii?Q?6bRKIA/QxC+e8w0SqojB1GH3dyzzsN2tLxu5+54OnL+yheMQo44mIZxXAjP8?= =?us-ascii?Q?iRpPIfU1TcCSI4wKZWkI2N4ds7z/9ayq1SJK9QTV6IguDnB/Qsh250yk3m1a?= =?us-ascii?Q?PnwnZOAMOwvacM1wkCrQTEwdyisJFrUQ00V1EhR7p0g8wbflGq5h249RbuQS?= =?us-ascii?Q?AaAqQfK+IrKfGeTl+kCjmSUi4X5Y3jhO5PeK+XJomQiBONDlySt3EsqIRCMu?= =?us-ascii?Q?SCGFPvi+RoCGfpSge9MKF3C+f/HP5f4pQO093iQDToWX4yXeGLK1GqKmq6Vw?= =?us-ascii?Q?CfkeEA5lLRw9G3/lzUMZVSV7oGcd31fpTMLBQlD6vo/OzD58Cc/PPHFmv6i2?= =?us-ascii?Q?2OFnztsKE0pzg+Fv530Oa3u3jG2XYDKVpu2TEhX/pP0I91PQ7Tj44yP32+db?= =?us-ascii?Q?PaRufZAsuyj+f75txt/cGM3waQ24yk09a1Pb6U1qPEnWn5umYx4xlgU7LMPL?= =?us-ascii?Q?OFzAzRggLLy9Q4e5s008+j9qepvLSgvuxpHBtY2zh9ApsAJJT8ukD+TXSbdp?= =?us-ascii?Q?+It51q/S5oizsA5w3ZowqkdFCvC+0dDIbGjEyksm/Uz+/OqoeOz5t7oT7/p4?= =?us-ascii?Q?IFp0p+Ywe9/jU6XCt0gGoj43GU79toT2+Y/FuNv3RLD+ZYRGhrcCvYikIF03?= =?us-ascii?Q?q6H+NaqBuOgoKH6zi1RhydNFHFMu5koc4A5js8eDgL2Hz18zJcoRBL5QLx7R?= =?us-ascii?Q?tb91jfrU5hcU3P3wa1dxQ/P2QN+m1T1JH04BcTyMQ41gxXuDPAuYcyByOKGq?= =?us-ascii?Q?yLxmDtPjFgItO0xLXkHrcmQLp8BKgVXOnRkEPor2etDJTmrTmoOa+s7VQd1f?= =?us-ascii?Q?BNPPLfHyoaVMu42lL/scuGAa+w/rPWbOXESCBNafMcUVEQ2pD6BKDcDaeExP?= =?us-ascii?Q?lg2DofYxZeULHlwMc5jep7esLpwBZp9tWjjt0TCS8Xg68a0nS5TeLGGW09Ar?= =?us-ascii?Q?4q60+jWMMozftnM34T+otWzYMjCRYqLIt9fWQiHlc8HlQy5KxPpKT7PONSGT?= =?us-ascii?Q?fO0jo/DXEaA9vPpcpKDl2VRktFOzxhUkE9vzMmh2S59UDc/+vhqp0QovxrS5?= =?us-ascii?Q?Y0wbZkhyDBU+38VDEjnr8wSaLzIUXYLl3AO9ZRhRjIvh7LnShcUWmlUyiBQy?= =?us-ascii?Q?C3qnAiyzq1PYKGSBtCX36rBRF1vJ7RSK?= X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(1800799024)(14060799003)(36860700013)(35042699022)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 10:36:03.8591 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3120b73c-19bc-4f5a-2ff6-08dd138649b1 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM3PEPF00009B9F.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR08MB5752 HI, > On 2 Dec 2024, at 20:38, Julien Grall wrote: >=20 > Hi Jan, >=20 > On 02/12/2024 07:52, Jan Beulich wrote: >> On 30.11.2024 18:15, Julien Grall wrote: >>> On 29/11/2024 22:12, Volodymyr Babchuk wrote: >>>> Jan Beulich writes: >>>>> On 29.11.2024 02:49, Volodymyr Babchuk wrote: >>>>>> --- a/config/arm64.mk >>>>>> +++ b/config/arm64.mk >>>>>> @@ -5,6 +5,10 @@ CONFIG_XEN_INSTALL_SUFFIX :=3D >>>>>> CFLAGS +=3D #-marm -march=3D -mcpu=3D etc >>>>>> +ifeq ($(clang),y) >>>>>> +CFLAGS +=3D -target aarch64 -march=3Darmv8-a >>>>>> +endif >>>>>=20 >>>>> Why is this dependent on (just?) $(clang), not (also?) $(llvm)? >>>>=20 >>>> Because this parameter is handled by clang only. There is no harm in >>>> providing it explicitly. When building on arm64, value of this paramet= er >>>> will match the default value for the platform. When building on x86, w= e >>>> need to tell clang that it should generate arm64 code anyways. There i= s >>>> no reason in trying to make ARM build with x86 instruction set. >>>>=20 >>>>> Also >>>>> this affects both toolstack builds and hypervisor. Is applying -march >>>>> like this actually appropriate for the toolstack? >>>>=20 >>>> This is a good question. I can't see why this can't be appropriate for >>>> toolstack. I.e. what bad can happen when building the toolstack. >>>=20 >>> In the future, we may want to build the tools for Armv8-M. So I think >>> the -march should also applies for the toolstack. >> Perhaps I don't know enough of the Arm world, but: Wouldn't it be possib= le >> to build a tool stack suitable for a wide range for Arm64 flavors, while >> requiring more targeted hypervisor binaries? >=20 > Good question. There are some commonnality between ARMv8-M and ARMv8-R bu= t I am not sure whether it means we could use -march=3Darmv8-a build and ru= n on ARMv8-M. Adding Ayan and Luca. AFAIK a binary compiled for armv8-a aarch64 will work also on armv8-r aarch= 64 since they share almost everything apart from some MPU registers, instead in order to work on armv8-m we might need to pass the appropriate m= arch Cheers, Luca= From xen-devel-bounces@lists.xenproject.org Tue Dec 03 10:36:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 10:36:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847920.1262969 (Exim 4.92) (envelope-from ) id 1tIQGb-0006Wg-AZ; Tue, 03 Dec 2024 10:36:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847920.1262969; Tue, 03 Dec 2024 10:36:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIQGb-0006WV-6K; Tue, 03 Dec 2024 10:36:29 +0000 Received: by outflank-mailman (input) for mailman id 847920; Tue, 03 Dec 2024 10:36:28 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIQGa-0006Un-7b for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 10:36:28 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tIQGZ-001tXm-1T; Tue, 03 Dec 2024 10:36:27 +0000 Received: from [15.248.3.91] (helo=[10.24.66.43]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tIQGZ-00CVkR-1U; Tue, 03 Dec 2024 10:36: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" 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=QJLMf8Jsd3DkRoapzlW/IqRs2AZ9dGhfd/wiyl1JB2k=; b=PK24NjgcrT/0gUcXdDPxKG5StG L6FNpakEEkrB6K+o10by8SijAHAnKyxEaWVK+BqjR+t0MpIa4nt/Mus3dqiuvfu9dzeIwo7xHmOdj aKK557uSkMbof0xP/e1295m2O16nfvYKg9mE+VJkJtQDbSYCFK0PnF3qabpRDIhfrE24=; Message-ID: <5580b3fc-66d7-4193-9c54-2733fb628418@xen.org> Date: Tue, 3 Dec 2024 10:36:24 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 12/12] xen/arm: add cache coloring support for Xen image Content-Language: en-GB To: Carlo Nonato Cc: xen-devel@lists.xenproject.org, andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Jan Beulich References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> <20241202165921.249585-13-carlo.nonato@minervasys.tech> <800b0b49-e6c5-4a83-8ee6-d89d51613b0c@xen.org> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 03/12/2024 10:08, Carlo Nonato wrote: > Hi Julien, > > On Mon, Dec 2, 2024 at 10:44 PM Julien Grall wrote: >> >> Hi Carlo, > > [...] > >>> diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c >>> index 671eaadbc1..3732d5897e 100644 >>> --- a/xen/arch/arm/arm64/mmu/mm.c >>> +++ b/xen/arch/arm/arm64/mmu/mm.c >>> @@ -1,6 +1,7 @@ >>> /* SPDX-License-Identifier: GPL-2.0-only */ >>> >>> #include >>> +#include >>> #include >>> #include >>> >>> @@ -138,27 +139,46 @@ void update_boot_mapping(bool enable) >>> } >>> >>> extern void switch_ttbr_id(uint64_t ttbr); >>> +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len); >>> >>> typedef void (switch_ttbr_fn)(uint64_t ttbr); >>> +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t len); >>> >>> void __init switch_ttbr(uint64_t ttbr) >> >> Given the change below, I think this function needs to be renamed. >> Possibly to relocate_and_jump() with a comment explaning that the >> relocation only happen for cache-coloring. > > Changing the name of switch_ttbr() to relocate_and_jump() seems a bit > misleading to me. First I need to change the name also for arm32 where there's > no relocation at all. Second, relocation is something that happens > conditionally so I don't think it's a good name for the function. Feel free to propose a new name. The main thing is the current name can't stay "switch_ttbr()" because you are doing more than switching the TTBR. The other solution is to have a separate call for relocating xen (which will fall-through to switch_ttbr) and another one for those that only to switch TTBR. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Dec 03 11:13:10 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 11:13:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847954.1262978 (Exim 4.92) (envelope-from ) id 1tIQq1-00084F-0K; Tue, 03 Dec 2024 11:13:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847954.1262978; Tue, 03 Dec 2024 11:13: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 1tIQq0-000848-TI; Tue, 03 Dec 2024 11:13:04 +0000 Received: by outflank-mailman (input) for mailman id 847954; Tue, 03 Dec 2024 11:13: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 1tIQpz-000842-QT for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 11:13:03 +0000 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [2a00:1450:4864:20::134]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8f465404-b167-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 12:13:01 +0100 (CET) Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-53df6322ea7so9229514e87.0 for ; Tue, 03 Dec 2024 03:13:01 -0800 (PST) Received: from localhost ([185.68.248.203]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5998e6a3fsm604818866b.119.2024.12.03.03.13.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Dec 2024 03:13: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: 8f465404-b167-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1733224381; x=1733829181; 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=1Brczf+jm2PjfF/d6A12kdSlpJIrCxg0ukV1D8qw93M=; b=MAExyqAQcbsRqrmdE5X8t9VzI+9i72STsg/2QZ2isAlYla0zjcc0cGcC0FTCV5TjM9 IUsrFk2R0H5Dr8R49lazl4ZTOwY/f+yN8Abv8UkolydS+nf6tc670IfYe05Bhpo7PABf 0W5Vtg9pLBXXZLtHANQbDJxyNYbbUiVD+KOl0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733224381; x=1733829181; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1Brczf+jm2PjfF/d6A12kdSlpJIrCxg0ukV1D8qw93M=; b=QkLcJl1nAuld8+IhjHIQp1CH6mX71knURBOfH1tM3OTMHO9oDGo1gEo5iHsOD0rkjL 0fDSUNkqGJH21t6wTcXJuym/7x+gLKnjDTLrldXXF1PxwyesLscmZix38qhT0Y1D2QxR IoGXAEHABlIzaE9jQ47fSjZ1d0oQyu7d8NrVHMgHLwgGC3MQhFdASCX7Jylk60CyzmJN c/qoGvN+LT5Ibdibm5xbgX5TDFWwIJWNpDjyzMCrvbfRLT7GBfufQSVxcxMo9y+Lg3N8 CtfTX/5R0CsUfIIPL3haApZB1mRzzLkl+LeHv66o7iivDyOfZmhcZsSzLs5fTREB8BUL 8PjA== X-Gm-Message-State: AOJu0YwkU2rkV++5A73W0BgPFWTUJ9HR0Rh7qTITmtEMLNfxbJk62xvv f/RcQFee1Uj2Wut6OJs32x0WLnKxe9twcan35xAMeav+yMRXAceikoF51iPAKDD4/jF1V8WR0sa fSLo= X-Gm-Gg: ASbGncshICLM6YwCKnb4czM4iRYrUkJfOl1VrIrrV9luRgpXMmbWlM+f2zYYFlvJEMa 1nYmdV5ES0XguoJxuaLqYOyyeAzwWmzeX5Xpkn6HUWOEJHiYSpGUhr5ZMtEwb8Rxd/Be4uYcg8w LYr9VMKb7lgGqCWujWh28h0/Xxt6LsG3ClL2Mn1qm+yS6G7sjlwXaSjkXRdNtw1J3i6IaCSc/Af nL+UznZGSe2QJtjEKjxKqvtwQ+/NgCQnw5zL+qHmuGU8Li1URilsQM= X-Google-Smtp-Source: AGHT+IHLdK3NEMZBnYwxf68XeNDzEpzC8BNv3KJy82w58kTvJlGRhVYiBQTis/kYvEDtHN9aU2tzXA== X-Received: by 2002:a05:6512:3d89:b0:53d:ed19:d25a with SMTP id 2adb3069b0e04-53e12a06d4dmr2013707e87.32.1733224380852; Tue, 03 Dec 2024 03:13:00 -0800 (PST) From: Bernhard Kaindl To: xen-devel@lists.xenproject.org Cc: Bernhard Kaindl , Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [RFC PATCH] SYSCTL_numainfo.memsize: Switch spanned to present memory Date: Tue, 3 Dec 2024 12:12:56 +0100 Message-ID: <10466e8c29b5f69774915bcf6562985c75e98bb7.1733224306.git.bernhard.kaindl@cloud.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This the 2nd part of my submission to fix the NUMA node memsize retured in xen_sysctl_meminfo[].memsize by the XEN_SYSCTL_numainfo hypercall to not count MMIO memory holes etc but only memory pages. For this, we introduced NODE_DATA->node_present_pages as a prereq. With the prereq merged in master, I send this 2nd part for review: This RFC is for changing the value of xen_sysctl_meminfo[]->memsize from NODE_DATA->node_spanned_pages << PAGE_SHIFT to NODE_DATA->node_present_pages << PAGE_SHIFT for returing total present NUMA node memory instead of spanned range. Sample of struct xen_sysctl_meminfo[].* as presented by in xl info -n: xl info -n: [...] node: memsize memfree distances 0: -> 67584 <- 60672 10,21 1: 65536 60958 21,10 The -> memsize <- marked here is the value that we'd like to fix: The current value based node_spanned_pages is often 2TB too large. We're currently not using these often false memsize values in XenServer according to my code review and and Andrew seemed to confirm this as well. I think that the same is likely true for other Xen toolstacks, but of course to review this change or propose an alternaive is the purpose of this RFC. Thanks, Bernhard Signed-off-by: Bernhard Kaindl --- xen/common/sysctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c index d02f44fe3a..cba6d3cfea 100644 --- a/xen/common/sysctl.c +++ b/xen/common/sysctl.c @@ -316,7 +316,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) { if ( node_online(i) ) { - meminfo.memsize = node_spanned_pages(i) << PAGE_SHIFT; + meminfo.memsize = node_present_pages(i) << PAGE_SHIFT; meminfo.memfree = avail_node_heap_pages(i) << PAGE_SHIFT; } else -- 2.43.0 Signed-off-by: Bernhard Kaindl --- xen/common/sysctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c index d02f44fe3a..cba6d3cfea 100644 --- a/xen/common/sysctl.c +++ b/xen/common/sysctl.c @@ -316,7 +316,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) { if ( node_online(i) ) { - meminfo.memsize = node_spanned_pages(i) << PAGE_SHIFT; + meminfo.memsize = node_present_pages(i) << PAGE_SHIFT; meminfo.memfree = avail_node_heap_pages(i) << PAGE_SHIFT; } else -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 11:28:32 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 11:28:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847965.1262988 (Exim 4.92) (envelope-from ) id 1tIR4h-0002uE-8Y; Tue, 03 Dec 2024 11:28:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847965.1262988; Tue, 03 Dec 2024 11:28: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 1tIR4h-0002u7-4f; Tue, 03 Dec 2024 11:28:15 +0000 Received: by outflank-mailman (input) for mailman id 847965; Tue, 03 Dec 2024 11:28: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 1tIR4f-0002u1-PW for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 11:28:13 +0000 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [2a00:1450:4864:20::629]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ad7fa29b-b169-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 12:28:11 +0100 (CET) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-aa54adcb894so697047466b.0 for ; Tue, 03 Dec 2024 03:28:11 -0800 (PST) Received: from localhost ([185.68.248.203]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5998e7164sm612021766b.125.2024.12.03.03.28.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Dec 2024 03:28: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: ad7fa29b-b169-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1733225290; x=1733830090; 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=hA6nNf0bV2s6ks1c3yyy0VaM6y5y+WImctA+vf3iikc=; b=THkRh7vIIEC6Z/r7CLy0lEXrSutxhaOjUOKU/6q9+YTOzHyDM4CCzs/VuhcXUEuhzR ARU0JdiQhSMNc6kebkFRiQTUTpr0lZMZaurtQy/hGdUgx5gDyQGguzYljHVuoyOZlbfD 8nO6887b2t+ma6y9Ct7gJN590gS2L8taINW+0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733225290; x=1733830090; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hA6nNf0bV2s6ks1c3yyy0VaM6y5y+WImctA+vf3iikc=; b=Tb61oPZdHZWIAdZluUUZKqRrdhnr/1i2SUuhGTSWG5zRTqZFRKBa+QS1awwbL0FNS+ Z23PobATpOIxHzRbI5S+xtlbHGgFNDA0ThUQCPn/c/awqAnxiYWQoMR5u+1S9yCDkWsS rqfm9eSRWeQpDxkCK8GInqgrsucnaKJgFzUCNpgoNL8aN16aYpzTyIRkPLJYZ71OoLpQ szIqEgLFcV2f1Zv0loym8hsRfcMwEFiCMQPItoUZkg/H9nkKTJYVp5ZGOtGCqN6N27m+ DA0bhMrXOAldhgk76SDfjNUfnKZ3f+ORB/cgQEbTZRGg6vOfD/KaWk3oB59eV7jvgGRE wJyg== X-Gm-Message-State: AOJu0Yxx+fTVbzdb5JPIcFJtkKxwNv3TbW/7ewK0/TIHE+RSyz5sC+UY 4XrOKbhbVvgScXVal391XFrOXdCeQ4z2p+VjnXtZkI5Dk7T18THSRroygxymyHlkdaID6BdyrDi xJ+M= X-Gm-Gg: ASbGncuZOJLjZ/HQ1EEIbziQPNAsOYhX6vwc2izwQr6IMbM5ysa+jJ0k9BkUyUkgyli SmJBKCyA7bdFfden5aeRNiP1ED8g3F/vhpKHuKVriK7wp0tyN/CQEmR6zsRZx8UfC5eTjPrW6gl UpHuHggBpHYXlqk/hDBwy1vxqKfGZUOCHNzRjv51is3Tvzf/4/i/evzu4+neKkV0cb6AJPm4/ZK MFRWwkeX2HzNLUWVoCHlwEP4MUzff+8s3kI4P8DWlsJ2j/CIp9Oq6I= X-Google-Smtp-Source: AGHT+IFuy0tbXMBYU/lpXkoyuI6W/CwCkRjmoAagEWafPY5CKZftjWG1PqhwWh8cud8zjxvA7L53Kg== X-Received: by 2002:a17:906:3197:b0:aa5:324f:5319 with SMTP id a640c23a62f3a-aa5f7cce42amr162634566b.12.1733225290594; Tue, 03 Dec 2024 03:28:10 -0800 (PST) From: Bernhard Kaindl To: xen-devel@lists.xenproject.org Cc: Bernhard Kaindl , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julien Grall , Stefano Stabellini Subject: [PATCH] docs: Add function doc strings to a few x86 NUMA functions Date: Tue, 3 Dec 2024 12:28:07 +0100 Message-ID: X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit While reviewing x86 NUMA code, I noticed that some funcitons could benefit from adding some function header doc strings. Signed-off-by: Bernhard Kaindl --- xen/arch/x86/srat.c | 45 ++++++++++++++++++++++++++++++++++++++-- xen/arch/x86/x86_64/mm.c | 22 ++++++++++++++++++-- xen/common/numa.c | 27 ++++++++++++++++++++++-- 3 files changed, 88 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c index 688f410287..a7f6b79324 100644 --- a/xen/arch/x86/srat.c +++ b/xen/arch/x86/srat.c @@ -51,6 +51,22 @@ nodeid_t pxm_to_node(unsigned pxm) return NUMA_NO_NODE; } +/** + * @brief Set up a NUMA node based on the given proximity domain (pxm). + * + * If the proximity domain is already found in the pxm2node array, this function + * returns the node ID associated with the given proximity domain. + * + * Otherwise, it assigns a new node ID to the proximity domain and returns it. + * If the maximum number of nodes has been reached, it returns an error code. + * + * @param pxm The proximity domain to set up or to find in the pxm2node array. + * @return The node ID associated with the given proximity domain, + * or NUMA_NO_NODE if the setup fails + * or the maximum number of nodes has been reached. + * + * @note Uses a static variable to assign the next NUMA node ID to be assigned. + */ nodeid_t setup_node(unsigned pxm) { nodeid_t node; @@ -212,7 +228,19 @@ acpi_numa_processor_affinity_init(const struct acpi_srat_cpu_affinity *pa) pxm, pa->apic_id, node); } -/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */ +/** + * @brief Initialize memory affinity for an SRAT memory affinity structure. + * @param ma Pointer to the ACPI SRAT memory affinity structure to be parsed. + * + * Callback for parsing of the Proximity Domain <-> Memory Area mappings + * provided by the ACPI SRAT(System Resource Affinity Table) + * + * This function is called during the initialization phase and is responsible + * for setting up memory affinity information for NUMA nodes + * based on the provided ACPI SRAT entries. + * + * If valid, it updates the memory block information for the specified node. + */ void __init acpi_numa_memory_affinity_init(const struct acpi_srat_mem_affinity *ma) { @@ -314,16 +342,29 @@ void __init srat_parse_regions(paddr_t addr) pfn_pdx_hole_setup(mask >> PAGE_SHIFT); } +/** + * @brief Find the proximity domain of a given NUMA node ID + * + * @param node The NUMA node ID to look up. + * @return The proximity domain of the given NUMA node ID, or 0 if not found + * + * This funciton uses the pxm2node array to find the proximity domain: + * The pxm2node array maps proximity domains to NUMA nodes and is indexed by the + * proximity domain. Each entry contains the proximity domain and the NUMA node. + */ unsigned int numa_node_to_arch_nid(nodeid_t n) { unsigned int i; + /* If the NUMA node is found using the index, return the pxm directly: */ if ((n < ARRAY_SIZE(pxm2node)) && (pxm2node[n].node == n)) return pxm2node[n].pxm; + + /* Else, scan over the pxm2node array to find the architecture node ID: */ for (i = 0; i < ARRAY_SIZE(pxm2node); i++) if (pxm2node[i].node == n) return pxm2node[i].pxm; - return 0; + return 0; /* If the node ID is not found, return 0. */ } u8 __node_distance(nodeid_t a, nodeid_t b) diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c index 0d8e602529..e8571000b2 100644 --- a/xen/arch/x86/x86_64/mm.c +++ b/xen/arch/x86/x86_64/mm.c @@ -1218,8 +1218,26 @@ static int mem_hotadd_check(unsigned long spfn, unsigned long epfn) } /* - * A bit paranoid for memory allocation failure issue since - * it may be reason for memory add + * @brief Add a contiguous range of pages to the Xen hypervisor heap + * + * Update the machine-to-phys (m2p) and frame tables, the max_page, max_pdx and + * total_pages values, and set the page table entries for the new memory range. + * + * Also update the node_start_pfn and node_spanned_pages fields in the node_data + * structure for the NUMA node that the memory range belongs to. + * + * If the NUMA node is offline, set the node's online flag. + * + * If the hardware domain uses an IOMMU and the IOMMU pagetable + * is not using the HW domain's P2M table or is not kept in sync, + * also update the IOMMU maps for the newly added memory. + * + * When memory allocations or adding the memory fails, revert any changes made. + * + * @param spfn The starting page frame number of the range. + * @param epfn The ending page frame number of the range. + * @param pxm The proximity domain of the range, which represents the NUMA node. + * @return 0 on success, or a negative error code on failure. */ int memory_add(unsigned long spfn, unsigned long epfn, unsigned int pxm) { diff --git a/xen/common/numa.c b/xen/common/numa.c index ce3991929c..5db0a6745e 100644 --- a/xen/common/numa.c +++ b/xen/common/numa.c @@ -140,6 +140,18 @@ bool __init numa_memblks_available(void) } /* + * @brief Update the memory blocks of a NUMA node. + * + * Check for overlaps and interleaves with existing memory blocks for the node. + * If none, update the node's memory range and maintain the sorting of blocks. + * + * @param node The node ID for which memory blocks are being updated. + * @param arch_nid The architecture node ID associated with the memory. + * @param start The starting physical address of the memory block. + * @param size The size of the memory block. + * @param hotplug Indicates if the memory is being hotplugged. + * @return true if the memory block was successfully added, false otherwise. + * * This function will be called by NUMA memory affinity initialization to * update NUMA node's memory range. In this function, we assume all memory * regions belonging to a single node are in one chunk. Holes (or MMIO @@ -264,8 +276,17 @@ bool __init numa_update_node_memblks(nodeid_t node, unsigned int arch_nid, } /* + * @brief Check if all RAM ranges are covered by NUMA nodes. + * * Sanity check to catch more bad SRATs (they are amazingly common). * Make sure the PXMs cover all memory. + * + * This function iterates through the memory map and checks if each RAM range + * is covered by any of the NUMA nodes. If a RAM range is not covered by any + * node, it logs an error and returns false. If all RAM ranges are covered, + * it returns true. + * + * @return true if all RAM ranges are covered by NUMA nodes, false otherwise. */ static bool __init nodes_cover_memory(void) { @@ -291,18 +312,20 @@ static bool __init nodes_cover_memory(void) do { found = false; + /* Loop over the NUMA nodes and if check they cover this mapping */ for_each_node_mask ( j, memory_nodes_parsed ) + /* Check if this node's spanned pages are inside this mapping */ if ( start < numa_nodes[j].end && end > numa_nodes[j].start ) { if ( start >= numa_nodes[j].start ) { - start = numa_nodes[j].end; + start = numa_nodes[j].end; /* Check following memory */ found = true; } if ( end <= numa_nodes[j].end ) { - end = numa_nodes[j].start; + end = numa_nodes[j].start; /* check preceding memory */ found = true; } } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 11:37:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 11:37:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847978.1263008 (Exim 4.92) (envelope-from ) id 1tIRDv-0005cr-DG; Tue, 03 Dec 2024 11:37:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847978.1263008; Tue, 03 Dec 2024 11: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 1tIRDv-0005ck-AJ; Tue, 03 Dec 2024 11:37:47 +0000 Received: by outflank-mailman (input) for mailman id 847978; Tue, 03 Dec 2024 11:37: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 1tIRDt-0005VL-N0 for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 11:37:45 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0344d2ab-b16b-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 12:37:44 +0100 (CET) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a9a0ef5179dso784582866b.1 for ; Tue, 03 Dec 2024 03:37: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 a640c23a62f3a-aa599955662sm607383966b.190.2024.12.03.03.37.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Dec 2024 03:37: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: 0344d2ab-b16b-11ef-a0d3-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733225864; x=1733830664; 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=eJZM+UHf9Bf+4TYP3ZJ/KjCeoxpJHlhgAHhZPjXHN78=; b=do/WV5RAJSKVvJbc12RPg6M4K4uiglinEvU5Y2jvLmaUyyMbWAQjaGBPPc3R8OO+Y+ 7EP9vu9nKKvanYh9PT3R9O5T/cGXvmh4LZ8M0ODeiQPhKOJ5uhVP/WKMoEmLBVzzdfce 34GrV/Dst1eeWN7n249vPyciZdFTzy4e9fRYWxJy1qBHBRZU6cKYFz9fs79MIRZvOi85 Z7PARJ5vDo9/nXuwqKhFa/qaFxPKJmJ4id3UfkHwpw8ZwRm4S46ZpA86MwPgbc3vurdP 0SNejJ/Sp/Sppa3X8apa1J5dgvQbh9HWd+VnxTgTca6XEiBdxLmIHQroZCX1hxaeUQKk +rYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733225864; x=1733830664; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=eJZM+UHf9Bf+4TYP3ZJ/KjCeoxpJHlhgAHhZPjXHN78=; b=H5WYJfvvi/7tcD+P4ACVl6jX3XLz5recQRGywVI2D4+MS8NhU/M9z0Dj+AQFaiESHF /0kckWsF+VmahtzQePpi2snSpQbX0Piv+FBYb8h5wqeYoyoUP8u9TsDtLDfVQEArBdmc FU1QHjAAd9qejH4P0GZq/Idk4aNPOhJQwnDsCjc1daz0r1lBdrzo+6+rPiW5V37Pc8gt sklIAeB/dtw5aFWIt22G0u5+KZuqfOupVuPkizrcsKnpx9rXAdz8sRp8Yqv7QWIvk3JO 3z9lr8drmv8KTRQoRpizIUQE9J2ihbeEKQxlREg/NCXz/hKjy/je40bpZnWiNIuoFscM 341Q== X-Forwarded-Encrypted: i=1; AJvYcCVIF+Frlu2nVNTWN88dQdiNgPe7503HnXvd/a3H78xi4i3OteXnlHLPYADkiiLjT0GOk4QiyuObdIk=@lists.xenproject.org X-Gm-Message-State: AOJu0YyJsOsFB2TPvWE+He5J4yIiTEufdqfSA1JL77mzOo6lWBMHLuy0 5hkiKirX545ixHZGGOAQUUTXrK3EhQFbCMBSsSINUsAtrRpIQQ/eyQPH7OnXUg== X-Gm-Gg: ASbGncuxW9jLEBiuSUjrOCmm1iBRrSW51bed4gie0qyCwTmZxWyFUOX9zb8y3TI3g+d XtD6/wS4jXqpbTS59olRLWatx94ONKSR8hs3uQY9VlqrnlTlx4Y+bjbhlVtcncl+JkbjG8xGDh/ vgWzgctRyP3n3H6QuQOTQnRch6vXQIS4CYUiDSJ5nKooBZZR+kMPoM4LXL5zpBu8h2VJgaxF0Xy RPySaKq/VLaMQlWxiG4WCobwLB3FMxBuOxVPeqOzAU/AMUAmeyErj5BPTTZ8pfgVw42ML7mBjFE HQAcDl2P28LNPBzqpYcYfiE0Eo8JdSSDg+g= X-Google-Smtp-Source: AGHT+IHon4OVEqF/GM+y4l1CHbmYKI739FN7P590YZtPSeqcHG3Ou8BaBhmWCIAWAEoMg9G83eF9KA== X-Received: by 2002:a17:906:32c2:b0:aa5:52db:eebd with SMTP id a640c23a62f3a-aa5f7daba8amr165197366b.26.1733225864216; Tue, 03 Dec 2024 03:37:44 -0800 (PST) Message-ID: <0299582c-7261-4947-a2ac-bf3d62ccac14@suse.com> Date: Tue, 3 Dec 2024 12:37:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] SYSCTL_numainfo.memsize: Switch spanned to present memory To: Bernhard Kaindl Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <10466e8c29b5f69774915bcf6562985c75e98bb7.1733224306.git.bernhard.kaindl@cloud.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: <10466e8c29b5f69774915bcf6562985c75e98bb7.1733224306.git.bernhard.kaindl@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 03.12.2024 12:12, Bernhard Kaindl wrote: > This the 2nd part of my submission to fix the NUMA node memsize > retured in xen_sysctl_meminfo[].memsize by the XEN_SYSCTL_numainfo > hypercall to not count MMIO memory holes etc but only memory pages. > > For this, we introduced NODE_DATA->node_present_pages as a prereq. > With the prereq merged in master, I send this 2nd part for review: > > This RFC is for changing the value of xen_sysctl_meminfo[]->memsize > from NODE_DATA->node_spanned_pages << PAGE_SHIFT > to NODE_DATA->node_present_pages << PAGE_SHIFT > for returing total present NUMA node memory instead of spanned range. > > Sample of struct xen_sysctl_meminfo[].* as presented by in xl info -n: > > xl info -n: > [...] > node: memsize memfree distances > 0: -> 67584 <- 60672 10,21 > 1: 65536 60958 21,10 > > The -> memsize <- marked here is the value that we'd like to fix: > The current value based node_spanned_pages is often 2TB too large. > > We're currently not using these often false memsize values in XenServer > according to my code review and and Andrew seemed to confirm this as well. > > I think that the same is likely true for other Xen toolstacks, but of course > to review this change or propose an alternaive is the purpose of this RFC. > > Thanks, > Bernhard All of the above reads like a cover letter. What's missing is a patch description, part of which would be to clarify whether the field is indeed unused except for display purposes, or why respective users would at least not regress from this change. What's also unclear is what comments you're actually after (i.e. what question(s) you want to have answered), seeing this is tagged RFC. The code change is in principle fine, just that ... > Signed-off-by: Bernhard Kaindl > --- > xen/common/sysctl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c > index d02f44fe3a..cba6d3cfea 100644 > --- a/xen/common/sysctl.c > +++ b/xen/common/sysctl.c > @@ -316,7 +316,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) > { > if ( node_online(i) ) > { > - meminfo.memsize = node_spanned_pages(i) << PAGE_SHIFT; > + meminfo.memsize = node_present_pages(i) << PAGE_SHIFT; > meminfo.memfree = avail_node_heap_pages(i) << PAGE_SHIFT; > } > else > -- > 2.43.0 > > Signed-off-by: Bernhard Kaindl > --- > xen/common/sysctl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c > index d02f44fe3a..cba6d3cfea 100644 > --- a/xen/common/sysctl.c > +++ b/xen/common/sysctl.c > @@ -316,7 +316,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) > { > if ( node_online(i) ) > { > - meminfo.memsize = node_spanned_pages(i) << PAGE_SHIFT; > + meminfo.memsize = node_present_pages(i) << PAGE_SHIFT; > meminfo.memfree = avail_node_heap_pages(i) << PAGE_SHIFT; > } > else ... everything appears twice in your email. Jan From xen-devel-bounces@lists.xenproject.org Tue Dec 03 11:37:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 11:37:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.847977.1262998 (Exim 4.92) (envelope-from ) id 1tIRDt-0005O6-36; Tue, 03 Dec 2024 11:37:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 847977.1262998; Tue, 03 Dec 2024 11:37: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 1tIRDt-0005Nz-0R; Tue, 03 Dec 2024 11:37:45 +0000 Received: by outflank-mailman (input) for mailman id 847977; Tue, 03 Dec 2024 11:37: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 1tIRDr-0005Nt-JE for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 11:37:43 +0000 Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [2607:f8b0:4864:20::d34]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 00e530d4-b16b-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 12:37:41 +0100 (CET) Received: by mail-io1-xd34.google.com with SMTP id ca18e2360f4ac-84194e90c0fso345336939f.2 for ; Tue, 03 Dec 2024 03:37: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: 00e530d4-b16b-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1733225860; x=1733830660; 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=NIRpuvz3RljS/vyayA+DDMGZzyz0+4eCbKMkqB6SKK8=; b=gwS9H+Us5/gKWOVZD61KuMtiR3Ruk1bAf/8IsNnmSTse+qAiiDGGFG38wqaNCtxx1D fg4BalIsltYKdvgDMIPSmjqwSyBNxaNtyLO+Lcg047CDnQ8D48NV9E2ZMppaxcSsP2xn YoqbEtQtxKkh7QRPpuihVRbvhabLvF1sm0nNqckMK63sHJuUxhA8g5zeK4iU9PO3AWze 0FF6AWmBoFvgASqgvYpSsjLyYOqI83cCecTqeBze5RoWmvs1ZtDqi+EHwi7x7DKc8e3k ZCBCndYsvrmAB95NiuSsXnR3xeNRyVFDhM3QK10gelOUQ/j+vZHEtPnfaUfY8tRzNfZm paig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733225860; x=1733830660; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NIRpuvz3RljS/vyayA+DDMGZzyz0+4eCbKMkqB6SKK8=; b=qpxET5JLY8HOuMwDyreWXl0t6qGa0qq7SEwA81unIaN16Y2vuf3QN5Ha7TRQptneg2 fu5AgldzqQRBH89wOqpvZmEDZVWWWp3EkeMpibQQmf4pGOFX4LnqxsFVdbbHZuT8RIA6 EElB2MH1EdGC2eQgxZIOl4RN/lNw5YUmxMUlUv4SeyErDwSJtdKasG0QdL9+k4aiMcF8 hr+nywa0N67FrGVnS/IkT7HD0hKrivCpzdUjke53uoUlb1WYh3Hx1YkTLn2loiJdkYsX +RA6blGSzvY15HN099GyHl/EVV7Q0sGZcMThCT7meyqLBdpx9XB3BSma1EfLbObvhDeU 4VHA== X-Gm-Message-State: AOJu0YzPtV2rt698UL50ITK5OgqKylntP7aSMsCmM+SCKlQNgeuqGhhZ 6tx/eGkpOe9jCazy/7FQaQH3jKovDGxACOmhpPnMP3EyoxPVdNVI9LmWBmKFx7FcAC6DGkMItt5 i21PRGzLd1ZXL9+oFiGOc3t5tfbOkTGbdOs1+lg== X-Gm-Gg: ASbGncu5hTuOoGAq4SJH6eYI9jtFNPJ4NumKLKp5BaWLsLIyxIkQH9tF7EixY1vEkOJ OzXncBI9aimGGXITtfDMHlVgf44ahLxNj X-Google-Smtp-Source: AGHT+IH3K5wKzJpLJGqLBXjUYu58KD2ERsrMrEEleRbv+TVCTEyU1PsRtF1D+yBo102Nwpizc84aPFUd7G+J8s/TVWg= X-Received: by 2002:a05:6602:1513:b0:843:c87e:ec24 with SMTP id ca18e2360f4ac-8445b55330dmr215165039f.4.1733225859774; Tue, 03 Dec 2024 03:37:39 -0800 (PST) MIME-Version: 1.0 References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> <20241202165921.249585-13-carlo.nonato@minervasys.tech> <800b0b49-e6c5-4a83-8ee6-d89d51613b0c@xen.org> <5580b3fc-66d7-4193-9c54-2733fb628418@xen.org> In-Reply-To: <5580b3fc-66d7-4193-9c54-2733fb628418@xen.org> From: Carlo Nonato Date: Tue, 3 Dec 2024 12:37:29 +0100 Message-ID: Subject: Re: [PATCH v11 12/12] xen/arm: add cache coloring support for Xen image To: Julien Grall Cc: xen-devel@lists.xenproject.org, andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Jan Beulich Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Julien, On Tue, Dec 3, 2024 at 11:36=E2=80=AFAM Julien Grall wrote= : > > On 03/12/2024 10:08, Carlo Nonato wrote: > > Hi Julien, > > > > On Mon, Dec 2, 2024 at 10:44=E2=80=AFPM Julien Grall w= rote: > >> > >> Hi Carlo, > > > > [...] > > > >>> diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.= c > >>> index 671eaadbc1..3732d5897e 100644 > >>> --- a/xen/arch/arm/arm64/mmu/mm.c > >>> +++ b/xen/arch/arm/arm64/mmu/mm.c > >>> @@ -1,6 +1,7 @@ > >>> /* SPDX-License-Identifier: GPL-2.0-only */ > >>> > >>> #include > >>> +#include > >>> #include > >>> #include > >>> > >>> @@ -138,27 +139,46 @@ void update_boot_mapping(bool enable) > >>> } > >>> > >>> extern void switch_ttbr_id(uint64_t ttbr); > >>> +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t= len); > >>> > >>> typedef void (switch_ttbr_fn)(uint64_t ttbr); > >>> +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, = size_t len); > >>> > >>> void __init switch_ttbr(uint64_t ttbr) > >> > >> Given the change below, I think this function needs to be renamed. > >> Possibly to relocate_and_jump() with a comment explaning that the > >> relocation only happen for cache-coloring. > > > > Changing the name of switch_ttbr() to relocate_and_jump() seems a bit > > misleading to me. First I need to change the name also for arm32 where = there's > > no relocation at all. Second, relocation is something that happens > > conditionally so I don't think it's a good name for the function. > > Feel free to propose a new name. The main thing is the current name > can't stay "switch_ttbr()" because you are doing more than switching the > TTBR. > > The other solution is to have a separate call for relocating xen (which > will fall-through to switch_ttbr) and another one for those that only to > switch TTBR. What about a function like this one, defined in xen/arch/arm/arm64/mmu/mm.c= : typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t = len); void __init relocate_and_switch_ttbr(uint64_t ttbr) { vaddr_t id_addr =3D virt_to_maddr(relocate_xen); relocate_xen_fn *fn =3D (relocate_xen_fn *)id_addr; lpae_t pte; /* Enable the identity mapping in the boot page tables */ update_identity_mapping(true); /* Enable the identity mapping in the runtime page tables */ pte =3D pte_of_xenaddr((vaddr_t)relocate_xen); pte.pt.table =3D 1; pte.pt.xn =3D 0; pte.pt.ro =3D 1; write_pte(&xen_third_id[third_table_offset(id_addr)], pte); /* Relocate Xen and switch TTBR */ fn(ttbr, _start, (void *)BOOT_RELOC_VIRT_START, _end - _start); /* * Disable the identity mapping in the runtime page tables. * Note it is not necessary to disable it in the boot page tables * because they are not going to be used by this CPU anymore. */ update_identity_mapping(false); } which is actually a clone of switch_ttbr() but it does relocation. I would then call it in case of coloring in setup_pagetables(). This should go in t= he direction you suggested, but it would duplicate a bit of code. What do you think about it? > Cheers, > > -- > Julien Grall > Thanks, - Carlo From xen-devel-bounces@lists.xenproject.org Tue Dec 03 13:35:00 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 13:35:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848022.1263030 (Exim 4.92) (envelope-from ) id 1tIT39-00064s-NL; Tue, 03 Dec 2024 13:34:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848022.1263030; Tue, 03 Dec 2024 13: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 1tIT39-00064l-KI; Tue, 03 Dec 2024 13:34:47 +0000 Received: by outflank-mailman (input) for mailman id 848022; Tue, 03 Dec 2024 13:34: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 1tIT37-00064f-VQ for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 13:34:46 +0000 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2062c.outbound.protection.outlook.com [2a01:111:f403:2417::62c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5a371c15-b17b-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 14:34:43 +0100 (CET) Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7) by IA1PR12MB6409.namprd12.prod.outlook.com (2603:10b6:208:38b::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.19; Tue, 3 Dec 2024 13:34:39 +0000 Received: from PH8PR12MB7326.namprd12.prod.outlook.com ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com ([fe80::6d76:9c33:d230:8264%6]) with mapi id 15.20.8207.017; Tue, 3 Dec 2024 13:34:39 +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: 5a371c15-b17b-11ef-a0d3-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RNLS6+04Iy+CzbU9VHxnSI+FSkragwCET4kDDuh2guDptIBiz5tyNEUAi1qMbHBQSGAqfwHrpWT6EczlyBNcMygZsALtTD2n6I+AW8UbOustom7QqY9WwIjqsRPvBwrqZz0XrOGnaN1fgZMgHJCFIYrW/JrsszrgT3nRDt3cYygU8IfiEyazRVpcFY7rzMUhVWJKamBAWArxBOranVDMTiKVjcjJkchxYvPRdM22Y/6ElSbUPFcjzN8jbJLa1s42hDqzlot1d3/2nALgqSY6is1APUtgrHLtpGbgJqjeh5eoVAV1kSwyQinNgF2SQFuHCN3JXrB+/hvawFT6SI6gnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5xw/MM0N0dOAzwKaqMDkHInXxh8ufqcWtVk0U998Z5M=; b=SSf4k3NBJeMdSVS4lvrIZRUAJKycgenNikl6QPyxmAf1bM1Z9gAq063TKUQRbikJwsYQgdpYURphU1mYOBsQk+Yr9sG3RsN/shBMHJDXlYRNtycO28j1o7KEoeL6RmHfp/FSSfmsJ2FLL+o8lFr79LwD8FOiMlu5dMsP82oTG0pTHpj0q2xrUZwy8R7Sjvut7Xo/e8ebP5Sfkjmx4x8juz3Nv3mlp8GkZ3KdJA9q82Gp7gSuK/IgE+Y/CFegXVGgNaz4bT7GXKH3dEkuh7+DvvnsiyY+9k63AMsSGpVLTMVpEVJoZJ9XagFEK3pII97KQB/Dm8OVJnf8qmxLtEfjNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5xw/MM0N0dOAzwKaqMDkHInXxh8ufqcWtVk0U998Z5M=; b=TqpCUCjATdRgvZvp+yvRO2bs47XZKs7yw3dcSFJ12Q+EVRdQSdm1hXXumU+lpUm/bd33mrflKhAJCBXRX/Ru01TNtT/tEINHSWRo+B1FTQgRRmipCQIhpwZOeh1xK9LUJDmlIvkQYCaSsiwe5eTpNPVoS7px9ekTqFQv8jxwrLI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <41114d52-b618-4692-87f5-94de4b7ddeff@amd.com> Date: Tue, 3 Dec 2024 13:34:34 +0000 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] xen/mpu: Map early uart when earlyprintk on To: Julien Grall , Ayan Kumar Halder , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20241127183906.485824-1-ayan.kumar.halder@amd.com> <20241127183906.485824-2-ayan.kumar.halder@amd.com> Content-Language: en-GB From: Ayan Kumar Halder In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: PA7P264CA0001.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:2d3::9) To PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|IA1PR12MB6409:EE_ X-MS-Office365-Filtering-Correlation-Id: 17a6e625-1909-40df-fd31-08dd139f3c7d 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: =?utf-8?B?VW9aeXZkRXlVL2NKS1o1UTVhRjlEOGduMTVqNVg5WEl6UFh3OVd6dzU1Z1Vy?= =?utf-8?B?RFo4MWxaTmlJazFiT1dvK1BoMHNvUURIcldZcmRuRWpSNkpoZ0ZRZjZYckwr?= =?utf-8?B?TVdIQWtKT2xzZlZ6VlNHOGs5TnUxWUZ6UWYxaTFiakJQS3EyK3kxTXVqcFFM?= =?utf-8?B?cVdHUXdPTk1CZGJxekhRQ3ZWcEVwM2hteVk1R2xjd2pXSjRoTGovTjVRZTFJ?= =?utf-8?B?VjJvb2xmYTJsalJ5d2llQldRbnFZaVFvTzRJeEVQN2JOZnEvOFhueVcvVTR6?= =?utf-8?B?N2JSbDJLOU9xbmt5ampESlY0enBGNTlNZXM2OGM1U3hWd0IxcVgrd3NZVHVw?= =?utf-8?B?UWxSRXc1UTlCenBKUTMxL3BTbGFtRmk5MzFOOUhiRE1MZlcvTGRhL1Z6WVBt?= =?utf-8?B?NGR1UzlxWElTdDhTcXdUL3p2S09YbGkwYjZobFBPaFZnOFkrVHdjb0ZNTGFX?= =?utf-8?B?V2Yxck9KSXpWWUJyNXR2TVUyT0h2VzFjVmFURUFvZVRZUUxmREJiSmpPQWRH?= =?utf-8?B?RHljemdzQ0t1ckY1SmcvVUVvcUJFbTJPZ1lkS2VRemgvSjhKSThxN3h1bVFR?= =?utf-8?B?QURFVXhpNUlJK09MRTBxdThzWDRtaXEyYUJIRGJiQ3F2M28yV056UCt5SGdK?= =?utf-8?B?WC9ORW1WZkxlK3NWakZyQzNWZ3BSbXNNWStaWkx6TTZ1OHNjbmo1Z09CZmRN?= =?utf-8?B?RlNPT2dhOEFVWGJMVGdjVG5Pb1hpTEg4amVkdVZtb0c5TktPN3pYWk1CdDha?= =?utf-8?B?b3dZRmtXOEJVdGdrWjRnOForR3A5N09UQUY2TVhPc08yKyt3Vnc5OTQxeGdr?= =?utf-8?B?MjhVdzRzck1XbXRzU0V3STdCY1BuOVpTZHdGMFJFSHVwTVB2eFQvczcxbFVO?= =?utf-8?B?ekZCNXMyL3Y2NGF0a0tLSzRkZHI3eVNuVHdxWXYwcUZCOHNIUGhJc3VBcmNR?= =?utf-8?B?VlVnVndoRE11TGdFdVNBNlU2UEFKNVY5SDBray9vK1lJNTBCWVFQZEh4dUVy?= =?utf-8?B?WkZKdWRPY09WRExjaTdMVThHMnM4ZVpXWkZYUXhhcCtMWHJCZXpKNFJzUzNy?= =?utf-8?B?YUJrMEcycTkzdjFBVTBEZElESWxoUUJQbzBtck1lNHpSaFNMVTBKcVZoSWxP?= =?utf-8?B?UVRZNy96RjBna29JVXpnbkl2b0FHM1ZYOFM1MjRCQ1RaTERYdnMwY2t0bk41?= =?utf-8?B?eittbzlUcFhGU1h5RHNueklhOVY4L1EvVG9FWUNVNGVQN0NSMTVJNVo4VTRr?= =?utf-8?B?czhRcE9VRndmQUVVTmhTdUYvajAzeE1UdkNHY2xhQzNTMzFyUHhiTllScDUy?= =?utf-8?B?ZDRtYnhiOU16clk0aGdGUXlNelFabGF6VHU3b1h1S1JBTlJzM1dZWGl5WFNj?= =?utf-8?B?ejlYK1FudzBtSU5rZ0k5cCtub2d4R1RjTC9mYm1IQ25hLzRqbS9KV2o3d2xp?= =?utf-8?B?cWlYNWQzV0U1bVl3alp6YzMrYUVFNENuVW51enZXdDk2NWprd0tuVmptNzVW?= =?utf-8?B?Z0d3QVhrQ0RzMEVOTkIwYzZRLzN2VGZjb1lKTkd4SllhY2dTM2pQVkNaTmNi?= =?utf-8?B?dHBrZXd1M09oT2lwZFNES2ZZZjNzcWZFQ1pnbW9zZ3pwYUYvWFlFNzZUOFBD?= =?utf-8?B?MGgzUERoWWREaVR1NEpGUjVaalAyMnNIYllsNzNvdXUrVDBQdmVLSmdaZ0V5?= =?utf-8?B?TXMrT24vUnRkL1ZIbWJUeXpOUDRHVU9jcUJ0OWZFUVlXTzNXTWtsUXp0Yk5K?= =?utf-8?B?UjF3eFJYNlpaTFlkbmRyWW9iSDdvamQ3ZWF6ZDNYRWVMblBpMVpIek1iRnJQ?= =?utf-8?Q?MYZ9xRVC0DpXOX5gVL2vYPKwT05ky/RGwV/DU=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH8PR12MB7326.namprd12.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?dTNmOWE4U3J3MnVaTFM3cEJ6NmovNWNIU1JubG5rbFBoWUdXVVZaV2YwVFIw?= =?utf-8?B?MDJCVTVlT2l1dk1BQVFmblhncUNoWkk5RjNwUVdIVlNqTmJKQlZSMGhLQXV6?= =?utf-8?B?OWpoUUd5dC9maVlzLzUxQVlvVklwYm1nRGQ3bDJyOHcrakVWNEVoWThhSlBu?= =?utf-8?B?b0hONlNPVXdodmpiQTEzSkhqZUw1WkQwZnd2S2pxaFl2bis0ZFFyYnk3Yy8z?= =?utf-8?B?OXVOdmt6Nk9XT0ptWFNkM3JZUEhQUERQWDNKdEFEMWZaREdtQXJWNTBGWUZF?= =?utf-8?B?eElOKyszS3I3Q0tncUFEcDVrY3JVU0ZTR2NURXEvNzhVaThSZ2FWeEtmcC9Q?= =?utf-8?B?ZkswY2taNVJTSElyV3BvaUFWUzBMOEs3dnUzTGw3dXpRWGZGNEkySi9UTEcz?= =?utf-8?B?TVp3cWp4NFUxVXF6dzNOSko3UGZ4d3pCUnIzeGw0NmpQS3lraW1JQ3o5dGpD?= =?utf-8?B?ZVR1RlBZeVVaSVdraTN1R2wrVWl2dndBQ2V6eDJCZDYrUmkyOWE0SzFMejNL?= =?utf-8?B?UWxVVDgwdlpXSkNyUVBwdTVabm90VmIxZkkzYis1SzdYUGpiZ1VUN3FUTWZu?= =?utf-8?B?K1ZZQmhrTmZSbXNVajJnUm9sWjlFampjZ0FsMVdWSjNYbloyTmVhYkhsYzlv?= =?utf-8?B?blhYM2NLcnJyYlRCTUR3ekNMTWljNnhRUDdIUFFQT0tPUllJQU9FdHRINmZD?= =?utf-8?B?N2lRVkl2R3Rpd21jbUpVTElQNXNHRXdVTmFPRURpalQxZDdYTUNndStvWkFW?= =?utf-8?B?VCtpZnpkZE1Xa1hpOFpXYnVBeVhSZEEyRGdhVDFMRmtiOEtUd2wyNzgyVDVi?= =?utf-8?B?UFVNZUdxMjZ1SURmVTRvd1RBV2FFb0RLMHNzczh5TDBjU29NUGZQbElwMjdt?= =?utf-8?B?eVRjRnRpcWtXSUVFTUk4ZitPMjZ5WUI2TEFHN2tGcVYzMlpsMGVXZlVqTWwx?= =?utf-8?B?MnM1ZnpVMFBLbCtrdFUzTktCbkZYZjdmY2xoeWYvendxcU9EOEdqUGlDZVVO?= =?utf-8?B?eEJaa2ZSK2xPZmIrUXFiMkZ0aFFWODJJVHFVY2g0NHlrejgyRTVlMGdOOE94?= =?utf-8?B?bEdrbzhmYm8reElkWW9QalNlY0dCUlBJa3lrcldWek5xVE1YbWhvU1gyNTJI?= =?utf-8?B?cUI2elNBYlBXeTBQeEl6M1VacEdDMVVxU3huYjJvK2ZISWliUi9LTzNQOUpU?= =?utf-8?B?blBzN1U3Ym82Vm5MN1lhMngyZ0EzTXpRdUhJL3RKTEVxS0tIUU42dnhMZEJC?= =?utf-8?B?N28zUUoxQ0JtN2R2NWNSRXYyakl3RDVoemhTNXAvamVZS29JMmlrZGs3aU9v?= =?utf-8?B?eGszT3YxOGVQTWplSVBEd2k1S3RuZVo3d1hqeWsvaGZBQzRZNnd1RjBnZFp5?= =?utf-8?B?WjQxOWUxZzNwcHpnd056c21HWithWjV5cE1uMy94WjV6amZKWlVZczlVb3lC?= =?utf-8?B?M24xbHc2V1graXdQSWhiZVZMalFKa21VazlhTkJ4ODVlNWxVQ1V5bXdkL2NL?= =?utf-8?B?bTdhVjNDcUxFUE5USXU5Yk15ZjNoNHowcU1BeHBtRzJoaU9GKzAyazIvQnMv?= =?utf-8?B?anNFS3BHY0Z3UmtMY1Fkc05majdwSkJUY0lScmlSVndoQUttV0ZzUEVqNmdC?= =?utf-8?B?TFc0VzdzNEFJL0F3SGFESGhsMExHVmQ1cnZzYy90K0o2WkRRM3c4VXFIUHFq?= =?utf-8?B?RUE2LzlDSlhkdTdMb29EQWc0VE05NXhUM1JhcVpyaW5FT0JnTkNwdjNMeEp5?= =?utf-8?B?clg4S2tsbGNIWDllU0pkd013QXJ6aVBtTTZpZ3BRTk5PVmJ0Y0NRUlBQd3BQ?= =?utf-8?B?dGFYcTM1aWVBNjh0alc1aUZFYzJBdENDeG9wcVkveG9Eeml6akllY1JxbzVi?= =?utf-8?B?N0F5bEwzUjU3ek9TeWxBd3hvYlorWTZJbGQyU3p5ODJMejdBYW50b3BCcncy?= =?utf-8?B?WjVSNjdNVElRcGcrbnhsVmEycFhEYkkxbmFIKzZPNjNHc1k5T1FjMjgyVEwv?= =?utf-8?B?TTlIcm9pdi9SNGVKcFRGZWh4SUdSYUltZGhwSzU2djRjRDFZaVdmZS9HcTJK?= =?utf-8?B?OUVQQ2JaTFk2MEFiNm5MYUNiaEw2RnVKWTUrYTBSVHVGN0NwZnI1VnltQ3dx?= =?utf-8?Q?kSuymdz7BcL3+V34Oif1/UUEh?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 17a6e625-1909-40df-fd31-08dd139f3c7d X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 13:34:39.5152 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: s/YTA0QDKyl4aC5npmT025857WHC/eNZi+Gic497DQYovmZWCXd4iQcllVs9/BEiSyUhNu1HQkUbEjWhsCL7cQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6409 On 02/12/2024 20:53, Julien Grall wrote: > Hi Ayan, Hi Julien, > > On 27/11/2024 18:39, Ayan Kumar Halder wrote: >> CONFIG_EARLY_UART_SIZE is introduced to let user provide physical >> size of >> early UART. Unlike MMU where we map a page in the virtual address space, >> here we need to know the exact physical size to be mapped. >> As VA == PA in case of MPU, the memory layout follows exactly the >> hardware >> configuration. As a consequence, we set EARLY_UART_VIRTUAL_ADDRESS as >> physical >> address. >> >> EARLY_UART_BASE_ADDRESS and EARLY_UART_SIZE should be aligned to the >> minimum >> size of MPU region (ie 64 bits) as per the hardware restrictions. >> Refer ARM >> DDI 0600A.d ID120821 A1.3 "A minimum protection region size of 64 >> bytes.". >> >> UART is mapped as nGnRE region (as specified by ATTR=100 , refer >> G1.3.13, >> MAIR_EL2, "---0100 Device memory nGnRE") and Doc ID - 102670_0101_02_en > > I can't find the Doc you point online. Do you have a link? https://developer.arm.com/documentation/102670/0101 - Cortex-R82 processor TRM > >> Table 4-3, Armv8 architecture memory types (nGnRE - Corresponds to >> Device in >> Armv7 architecture). Also, it is mapped as outer shareable, RW at EL2 >> only > > I don't quite understand why you mention Armv7 here. Actually I was quoting from Cortex-R82 TRM. > The code you modify below is 64-bit so Armv8 only. > > The code itself LGTM. Ack. - Ayan > > Cheers, > From xen-devel-bounces@lists.xenproject.org Tue Dec 03 13:51:00 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 13:51:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848033.1263040 (Exim 4.92) (envelope-from ) id 1tITIj-0000Mj-VU; Tue, 03 Dec 2024 13:50:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848033.1263040; Tue, 03 Dec 2024 13:50: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 1tITIj-0000Mc-SQ; Tue, 03 Dec 2024 13:50:53 +0000 Received: by outflank-mailman (input) for mailman id 848033; Tue, 03 Dec 2024 13:50:52 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tITIi-0000MW-Os for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 13:50:52 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tITIh-001xNR-3B; Tue, 03 Dec 2024 13:50:52 +0000 Received: from [15.248.2.31] (helo=[10.24.67.35]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tITIi-00CqQe-0G; Tue, 03 Dec 2024 13:50: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" 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=uLa4qfKBHDtHVQTN8QYkqLF6xUntc/HcZWCWCPtBaOo=; b=ozAe1+3Y8tXnmZ06beD135I9bf H2WvUNzlVW5sNg/oZ82YXiCWrc1i8DK40KEsesGUY8D/Xz5tYsKYTdk8viLMi6XENeGqjvh90y0dF gOCiSdrAd/JO/3QXbibcqkMW5yU6ZDttwZ9LleAbPmlh5dutopVRQmMDX5BM9dWQl3I8=; Message-ID: Date: Tue, 3 Dec 2024 13:50:49 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] xen/mpu: Map early uart when earlyprintk on Content-Language: en-GB To: Ayan Kumar Halder , Ayan Kumar Halder , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20241127183906.485824-1-ayan.kumar.halder@amd.com> <20241127183906.485824-2-ayan.kumar.halder@amd.com> <41114d52-b618-4692-87f5-94de4b7ddeff@amd.com> From: Julien Grall In-Reply-To: <41114d52-b618-4692-87f5-94de4b7ddeff@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 03/12/2024 13:34, Ayan Kumar Halder wrote: > > On 02/12/2024 20:53, Julien Grall wrote: >> Hi Ayan, > Hi Julien, >> >> On 27/11/2024 18:39, Ayan Kumar Halder wrote: >>> CONFIG_EARLY_UART_SIZE is introduced to let user provide physical >>> size of >>> early UART. Unlike MMU where we map a page in the virtual address space, >>> here we need to know the exact physical size to be mapped. >>> As VA == PA in case of MPU, the memory layout follows exactly the >>> hardware >>> configuration. As a consequence, we set EARLY_UART_VIRTUAL_ADDRESS as >>> physical >>> address. >>> >>> EARLY_UART_BASE_ADDRESS and EARLY_UART_SIZE should be aligned to the >>> minimum >>> size of MPU region (ie 64 bits) as per the hardware restrictions. >>> Refer ARM >>> DDI 0600A.d ID120821 A1.3 "A minimum protection region size of 64 >>> bytes.". >>> >>> UART is mapped as nGnRE region (as specified by ATTR=100 , refer >>> G1.3.13, >>> MAIR_EL2, "---0100 Device memory nGnRE") and Doc ID - 102670_0101_02_en >> >> I can't find the Doc you point online. Do you have a link? > https://developer.arm.com/documentation/102670/0101 - Cortex-R82 > processor TRM Thanks. But why are you quoting the Cortex-R82 TRM? This code is meant to work on any Armv8-R processor. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Dec 03 15:54:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 15:54:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848049.1263063 (Exim 4.92) (envelope-from ) id 1tIVEM-0005cf-CN; Tue, 03 Dec 2024 15:54:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848049.1263063; Tue, 03 Dec 2024 15:54: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 1tIVEM-0005cY-89; Tue, 03 Dec 2024 15:54:30 +0000 Received: by outflank-mailman (input) for mailman id 848049; Tue, 03 Dec 2024 15:54: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 1tIVEL-0005cM-Cc for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 15:54:29 +0000 Received: from EUR03-VI1-obe.outbound.protection.outlook.com (mail-vi1eur03on2061b.outbound.protection.outlook.com [2a01:111:f403:260c::61b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id df7bd25a-b18e-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 16:54:26 +0100 (CET) Received: from DU2PR04CA0316.eurprd04.prod.outlook.com (2603:10a6:10:2b5::21) by PAWPR08MB9590.eurprd08.prod.outlook.com (2603:10a6:102:2e8::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 15:54:21 +0000 Received: from DB1PEPF00050A00.eurprd03.prod.outlook.com (2603:10a6:10:2b5:cafe::26) by DU2PR04CA0316.outlook.office365.com (2603:10a6:10:2b5::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.17 via Frontend Transport; Tue, 3 Dec 2024 15:54:20 +0000 Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB1PEPF00050A00.mail.protection.outlook.com (10.167.242.42) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 15:54:20 +0000 Received: ("Tessian outbound 206fab1c37e0:v514"); Tue, 03 Dec 2024 15:54:19 +0000 Received: from L4a802d8ed828.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 0983236E-F230-4036-8706-7CE37C759F22.1; Tue, 03 Dec 2024 15:54:08 +0000 Received: from EUR02-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id L4a802d8ed828.2 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 03 Dec 2024 15:54:08 +0000 Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21) by GVXPR08MB7848.eurprd08.prod.outlook.com (2603:10a6:150:16::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.17; Tue, 3 Dec 2024 15:54:05 +0000 Received: from DBAPR08MB5798.eurprd08.prod.outlook.com ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com ([fe80::4a66:d3e2:570:9632%5]) with mapi id 15.20.8207.017; Tue, 3 Dec 2024 15:54:05 +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: df7bd25a-b18e-11ef-a0d3-8be0dac302b0 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=KFtQIToY1zDwHyortKBHjgwumgt/OHYCxCuJaKuc/IbQDOO5K956NUpnrvCJpQnKEX/Ljet9ACsMVsmncYas7IcZRPKCRdwLd7/Y9XM7UQPd0bZ0kdxkGsfiIrRuwqJiIXAVUUGnKQFr7mdGm6AmRXVpF7Pqn/9V+BbBJ1vpDK1m75K6IM8bokiOHjeHhGelyBao/Y14HbqgnBPAtmvNRzYjPBS03O0jjMS1NHi/cu+5wx6Sq4UMqsEBmXkHwZ0DGoN4iPANpX3A5EUWAHcwPFHBQHLJl+0w/Ds0fdIW27K9gUzvjmCTxYu/9PZoWQwt80PYaSIPv5TFQp3WtxppyQ== 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=xfdpysEpVYmCg3juruySqhZcoVCTgjl+WYsJi5jecUg=; b=HzRZDY+EKrekH28A5cb6io+E772meaZ2nIOGhYKfGLamFaWlj2r+16x5dwra1MdO9od8SSsyVeI7EmhUQhTArZki4Pd1WFsA39L1y3w7juEfcKKZEkeG51wr9IatpfbRKUUtKsLsTq0x4IAhUAjZd94BJhYfgAJLKptevSd5Y7vYlR06hkmYpEEB05/9U0F0oKywKs78KzRdMmQR9SjSQ/OWSSWOA9lC1+oOFJzwTtZv8ouBQUfqY7k9JhI/J/Qr9zoP45g1I2hKo40t2PVRSPCjTkTxDwp7tKxofXfMAn9+mPmBvftAYRltJfdb+5hYuyaAMoRGDgTC4knJjA0k/w== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=xfdpysEpVYmCg3juruySqhZcoVCTgjl+WYsJi5jecUg=; b=WJtcuHKeANc8/OaKx5RJYSepl12CmXhA47sJE8MneE4gakqms/zDRCHYVzg9eBAJTIv8egzn/bm/N2zGfCMppkd4O+ktbrx8749y5JSXLCDBsmwl6OCOb2fENurWmI2Xeg0HWxeJ4UiKeS+5lmGNoQ44mdOUw042mrQvM0gCDvE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) 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 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C X-CheckRecipientChecked: true X-CR-MTA-CID: 010ef2828509d02d X-TessianGatewayMetadata: VuZMNs+3RBXvncJOEGc/vMVUaB1UE/LLRXTb9IQWYox7T4X6gUUUVHfGrmePQ6ecTuw60Rfnqry9wntNONj/jilGinZQ498k59+a3tuGOvCbG/8gwL+6Ts7x7RgSmDB7M0cTY/Snx0sEfwttJxGSKTZtHXB5Bi2b3vR5vvxrXrE= X-CR-MTA-TID: 64aa7808 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SwF++H1KyomAfmRWncMdqcMLUNDueEOwSAP5Gd5h6cLasRZPRCRSRyni4zbYcUuGzJoIkhUAIfwjicO2PujVc4THJkWeTH0LE/XI4TvzeHmQ+3K0Cb1yBrP4HB3/meHw4O63bHUmMJlJnfh2OnyV5nSghFbUYT6J1PwNaZWtq+yFSaWDxLDA1QWkTJCv1nlluYepFPS8hUOgGRUZXTNwpJNITQ6nCBaPPgOnDNIuKWUP6sFGUfE+UUwduyou9rmWZnPZD0gcLRtq/ogFVHxUcov6UlGH1vJV/V1ODofSe9NiQ6rWmlvUlboRKmJEmkxb4/xz68RYOWu2TnKPrD+Tew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xfdpysEpVYmCg3juruySqhZcoVCTgjl+WYsJi5jecUg=; b=YY/67yh2EDx1I9TFdAOae4ZNGB+UxQsRWVj7F6VhgML88EPYATYzNV6jcmCTyu5zZiUN8iwdGojl3Qzpf24OdkbYVBKamwddm8mpOnBVw9d85dTfJTKEe+UUAJz18n70w9678mZgVRE8zTjRZwPadLUq6aTXGuDvECFUlBUAEVUNUAv/E4irtF1BUc+7Dc3+5DglrWORR9P4wtDzwTT+BYWmleinfNxgfnR8xHRBsSvvcAUhfhf6zNb9jDWF46M+BuJzrC+nihdEyZPYn95760pUDV90gXDZTxNSFLtylh3VNEI0gdYxU9uO3JXDpIQ8kdVZod7f62WIeEwdprXuaA== 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=xfdpysEpVYmCg3juruySqhZcoVCTgjl+WYsJi5jecUg=; b=WJtcuHKeANc8/OaKx5RJYSepl12CmXhA47sJE8MneE4gakqms/zDRCHYVzg9eBAJTIv8egzn/bm/N2zGfCMppkd4O+ktbrx8749y5JSXLCDBsmwl6OCOb2fENurWmI2Xeg0HWxeJ4UiKeS+5lmGNoQ44mdOUw042mrQvM0gCDvE= From: Luca Fancellu To: Ayan Kumar Halder CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: Re: [PATCH v2 1/2] xen/mpu: Map early uart when earlyprintk on Thread-Topic: [PATCH v2 1/2] xen/mpu: Map early uart when earlyprintk on Thread-Index: AQHbRWz5mao3stJzR02TMW5lND/1eLLUrCiA Date: Tue, 3 Dec 2024 15:54:05 +0000 Message-ID: <433175CF-550A-4AF8-9422-5411D0107653@arm.com> References: <20241127183906.485824-1-ayan.kumar.halder@amd.com> <20241127183906.485824-2-ayan.kumar.halder@amd.com> In-Reply-To: <20241127183906.485824-2-ayan.kumar.halder@amd.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3826.200.121) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DBAPR08MB5798:EE_|GVXPR08MB7848:EE_|DB1PEPF00050A00:EE_|PAWPR08MB9590:EE_ X-MS-Office365-Filtering-Correlation-Id: 4da99b2a-3314-4576-8d63-08dd13b2c029 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|38070700018; X-Microsoft-Antispam-Message-Info-Original: =?utf-8?B?MnRqZjlqUEVUNTREQ1RpeU15WjRvNFZCTjA3bnQ4VFMxQ1J2bGRMczBaZ2o2?= =?utf-8?B?WC96OXgxTDA2TU40N28yYktpTUpobUxzbUF6Q2ZtTkVLdk1tUFV3QlBRQUsy?= =?utf-8?B?N2lhN1ZOSVQ0ZVlEZWM2M3c4d3lIbnJ0UzB6alR1RHlGMFkzamdIdDFtNTFS?= =?utf-8?B?cXgxdEh4ak5TZEEzMDFNVnFCZFE3Z3lZeWg3M0hSb2xsd2s2SmkrNVUveDl1?= =?utf-8?B?RzV2TTlPOXgyNFFXMXJyZ2ZzOVBDVGFHa0JSNWJkOFVwb2VjVGVSNWhRR0Ji?= =?utf-8?B?QlI0d0I1V0ttOE9UQTl4UnFQam1pTHh2NnU0dHZTa1JYZVBFWkZHMG56OXRD?= =?utf-8?B?eUFsY0xvYkhHSlhiK1lyaVpjMUdPbmJrTWhhNktzZlVrdWhDeVovenZBQXB3?= =?utf-8?B?aFNydTEzMGtHZEREclNFTkFIeHdHR3lJd3ZYd01Xa2NJaTlMWHlXUmdaYjJ5?= =?utf-8?B?VkVFampnODI5cWN5V3V6bVN5aEpoN3NvOU1kY1MxK0JUcElMcGkweXlKOS82?= =?utf-8?B?RlRTdHgyRjhhNStMeXp2ZDR3Y056WGJXd1JSelM4RlJORVNvUmRkSkk1SUE5?= =?utf-8?B?ZitKVkFuNWtjcXBJWE9NR2dqdmxDZjJ3ZWowalV2eDI3WFc5Z0dSNzdRRG1k?= =?utf-8?B?eGRueDBQUURRUmltMGNxbndiT3JqSzFnbGd5emVpZHRGcXY3Vm5Ucmx3WENa?= =?utf-8?B?d0c4b0xwTmFTMWlRUHQvN1lmNW1PemVsUFoxS1FWWE5DOWFvMGJpd290QTlo?= =?utf-8?B?eE9mcXVhd09zM0xhNldDUEJXakpWS3VzOEMza3pIeU50dk5nN3V2eGhsd2VZ?= =?utf-8?B?SlJQck5neitTd3ZzWk1sN0g2YS9XWmgwYnVtSkptUFRIdUQ0WTlDd05HWnBY?= =?utf-8?B?bjlWb3owVlhFZzMycis4UFNua3BoZEhWQU1MaWN4ak1OR0F1djBhK3djbDVM?= =?utf-8?B?VllKcnlXU0c3czdEclVRTVpUYWFXMEd5WkkzYkVOMlNoM25uR3VaUmhMZUJO?= =?utf-8?B?UTlRWm10NTlVSzFEbndyeitFVXhLeG9YSlFyNEZ2Z3VKWnFCMTQvODhxTSs4?= =?utf-8?B?ZElHanNaVzJ2dE9iY2dOU0hNVmdpbHg5YnZzQ2dTUXRBR2dyZ2tid3o4Ny9r?= =?utf-8?B?Syt0YmdqVGdzd3ZvR0tqMEc3VE1BUE4xQmFyM0ozbERLRzlHYzRvdGRTVE9m?= =?utf-8?B?QTlDRFMwR09jalJNYkEzUXBxZDRkcVB0NnNpS2I1eHhScTI4VDQwZHYrSC9O?= =?utf-8?B?MnFYTTNJWElZUkgvcjQrczFFMmNBekE3KzNrOUF0OG94Uzd3OWRpQnhIVmRM?= =?utf-8?B?RHJCRC9QMGJWY2wzWnZzTThKRDF6bFRBdzZWU2VNYklHaGRuRldmS0VneFF0?= =?utf-8?B?OU03TWFKSVMwbFVuejJDc0U0eWtFMFhmb0NLZlQvQWtqSkFUczg1SEtTMnJn?= =?utf-8?B?TW9IemM4b29WeVM5STNsaUJNemVEanhBQzlzTDFNV1NldlJOY3pWWHhjcVp2?= =?utf-8?B?R2pJbmI3ZUNyMm5BdDRIYzdOeVYvNkVObUNqYjMrRFhubG12NzYxWldyKzVm?= =?utf-8?B?bEZLcWlLWXM2VVlHVytLYUlHY21Wa2s1dC9SY2F6WVd0QTcrSGE1RVBUSVAr?= =?utf-8?B?SmdKSkhhN01CaTBzM1B2YTI1clZjL3cwTXJrNFJTRFBFQkphWWk2Y0pHSzkx?= =?utf-8?B?Uno2am9mcTNMYlJPdHdTNk9QUktUeHVqV2R4dzBkbDZNODJYa3lsM3pmdURq?= =?utf-8?B?b0JwU0FjYk1DekhsaFpHamhtT0FmemFnM3haaDgva1VlTUFla3E5ZE9aTTlN?= =?utf-8?B?WExPYS9XZUdJRnVLeHNnQWtaMnV3b2ovS1JReno5aitvQmd2d3hjN1U5dmdh?= =?utf-8?B?bkJjb011SWR2Z0MzVmFhMHpRU1RCZ0FxWmxBUXZScCtMQ0E9PQ==?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="utf-8" Content-ID: <30FCA0C9FDB6AD4CBE5EDB1D2A4117A3@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB7848 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-SkipListedInternetSender: ip=[2603:10a6:10:1a6::21];domain=DBAPR08MB5798.eurprd08.prod.outlook.com X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB1PEPF00050A00.eurprd03.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 5b005394-1214-4636-7651-08dd13b2b6f7 X-Microsoft-Antispam: BCL:0;ARA:13230040|14060799003|376014|1800799024|36860700013|35042699022|82310400026; X-Microsoft-Antispam-Message-Info: =?utf-8?B?c211NGVFeS92Q3kvSld6dzVwSDVkRnJnaGoyTGtzU2d6YmhEci9EekdSdkp6?= =?utf-8?B?b2ViTnE4Vm5lbFlWWGR0cEhUV0lPeDJvVklCak15N1ltWHZUYmZhd0VZdGFx?= =?utf-8?B?Si9rcUJ3LzQ1akJWRUdzdnlyMllZeTJXeFZDT1RrYVFGRzdnVVJ2Qmg5OVNI?= =?utf-8?B?MjFoWkVIbTJ2M0JHcERBNmlHaUtTb3ZoWnB3anhzV1RUd0w5bVdTR0gyNjND?= =?utf-8?B?NUZPTUo5eGJtRGZieUVvamNxM0pSOXUyc2tzaitaL3daRXprNFRaeEdFY25F?= =?utf-8?B?bEV3TkJOOFhjcE9DY092MmxvbkxnS1l6d21xR2tId0VnVDljSS93MWtsTDFm?= =?utf-8?B?dDJXVUhVRWpZYXZtQXV0QWVhRCtDKzVncVExNk5PWG9VL1djcWxvdU9Qd3VO?= =?utf-8?B?dnptSU1yWTloWjZFWGNkVlJMRHJqdTdBWnVrQStHSTdoeXJRVXNPc1lVb3FB?= =?utf-8?B?QysweGJleG5QYTZsY2FEekREUWhtODJCU3dzMzlFdXg0L3hSN2VqN0ZBZ1kz?= =?utf-8?B?UHYzcjNoanpEaXRrT2R5bElMK2ZHSkVVa2pYbW81YU40ejZRekVYRE04Z29V?= =?utf-8?B?c1RlbmNjSXI1a09oaTJGTW5vc0VvZXphbGMvemtMek9PM2RVYUJZVTI1Y3JM?= =?utf-8?B?RGdRdXJIcWNZZC83UTFWbWVQNE8rc280UnJRMHN6NE4xSVVMTGV0WUhkUUEw?= =?utf-8?B?NkVnSzZYVjJidVcrVmpaSlFzbU00emJWcmFTT3RSNXNkSndGNmNwTmNkS0FJ?= =?utf-8?B?d1BoSlNvNmFPZ3NKTE9GSHNiZUo2eTNFT2VkN0FTcFZnQ0tVOHRGQUZUVVR5?= =?utf-8?B?c3FGSllaVHU4c3BmbEJpRXYxV251aVc4NTZCTmN6cXB0RXMrelVCeFJuaUNM?= =?utf-8?B?RHRVVzhSVk9VOXdPK1ZjZExDQnVPSHR5K24wck1xMjQwaVVzdFZPKzljRG5q?= =?utf-8?B?U3p0Q1V0akMyNWpvV3lyN21WQVpOL1lZYXEwb1F0ckt4c01nNWY2YTZaYklt?= =?utf-8?B?Ni9rUlEydDJ5RjgrTm5sb1F5S0hLTm1RWEczYm1kVTEvbk9mejRMODhEcGtZ?= =?utf-8?B?T01oUzBLWlJDNHdMSHdWclBZYUhmdWdLUzg1TGNLL3U1RE1sZmg0cFFFVWh2?= =?utf-8?B?TEtPWGlleWN1V2NtL2Fxb0dmdGZyWnhLMzJPcXpCcEpzaFRUdXJsSndtMWdv?= =?utf-8?B?UXhBUzNMclA5eHpnZVo3RW44RU5vSnhFenJLd3dwQ1pzMXpvNWhRRWV5aHNr?= =?utf-8?B?YTJzcXAzdjRscFo1L3VjWGZFK0VxSWl1ZVBmMU9GTEtzNWRBNHRSOGFCcG9a?= =?utf-8?B?T0MvR1VyTXJLazJqTnpDVWZJczdNY3B6YkNiVWMxWFZkU1ZjbDZjNEJvRUwr?= =?utf-8?B?aE5Bb1JlOGsyZGN2Z3Ntdk10ZU9TTTlNcU9ud294RnRiR3RVNnRhN0E1d0VN?= =?utf-8?B?amdNQ3pla24rK0VzUGRNT3I5Z0s2U1B4djFCQTYvcUpiOTUraXpFNWlpN2pq?= =?utf-8?B?Z2pBR3hNb1YzTXFJdXNuMmh1azFzc2xFY3VSNHMzcENVNHUxcFFUb1hkV1Uw?= =?utf-8?B?YXhLc29Qa3ErR3I2NjI4S2tqR1hwaUZFdnhGaEdUVURCNkI1YlhyNDdmNkJr?= =?utf-8?B?VzJHaXZyMzBMY1h5cUk3b1dDNjhxbnpMMXBBOHo2VEZpWC9UdU1FVlUxd0Fo?= =?utf-8?B?T1pIZ1FQQk53MDJQZUJkdzNCVHlkZ0RxbmFvK0c3dzh0WXZKVjIvbnA3RmR0?= =?utf-8?B?MHQ4R1VIZUN2UXovbWlBYzN5SGcyQ1ExUXFGWnczV2J1WW9DRXQyMXoyNWtZ?= =?utf-8?B?MkExbWczUmRNMzlITVNpUnJIUlFOUnlyTmpXQ0VBaE1JSEJlaUlqNTRkTWQw?= =?utf-8?B?SjZsdmpZaUNWY1k5TCtVK3dMcWxTZUpZOEROcTBlRUFhV3hFVldpaEhMWnl2?= =?utf-8?Q?iZAHLwE60mG40D3Y8vFIO50zdEoF4PkS?= X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(14060799003)(376014)(1800799024)(36860700013)(35042699022)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 15:54:20.4283 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4da99b2a-3314-4576-8d63-08dd13b2c029 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB1PEPF00050A00.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB9590 SGkgQXlhbiwNCg0Kc29ycnkgZm9yIHRoZSBzZXBhcmF0ZSBtZXNzYWdlLCBJJ3ZlIHNwb3R0ZWQg YW5vdGhlciB0aGluZyB3aGVyZSBJ4oCZbSBpbiBkb3VidA0KDQo+IE9uIDI3IE5vdiAyMDI0LCBh dCAxODozOSwgQXlhbiBLdW1hciBIYWxkZXIgPGF5YW4ua3VtYXIuaGFsZGVyQGFtZC5jb20+IHdy b3RlOg0KPiANCj4gQ09ORklHX0VBUkxZX1VBUlRfU0laRSBpcyBpbnRyb2R1Y2VkIHRvIGxldCB1 c2VyIHByb3ZpZGUgcGh5c2ljYWwgc2l6ZSBvZg0KPiBlYXJseSBVQVJULiBVbmxpa2UgTU1VIHdo ZXJlIHdlIG1hcCBhIHBhZ2UgaW4gdGhlIHZpcnR1YWwgYWRkcmVzcyBzcGFjZSwNCj4gaGVyZSB3 ZSBuZWVkIHRvIGtub3cgdGhlIGV4YWN0IHBoeXNpY2FsIHNpemUgdG8gYmUgbWFwcGVkLg0KPiBB cyBWQSA9PSBQQSBpbiBjYXNlIG9mIE1QVSwgdGhlIG1lbW9yeSBsYXlvdXQgZm9sbG93cyBleGFj dGx5IHRoZSBoYXJkd2FyZQ0KPiBjb25maWd1cmF0aW9uLiBBcyBhIGNvbnNlcXVlbmNlLCB3ZSBz ZXQgIEVBUkxZX1VBUlRfVklSVFVBTF9BRERSRVNTIGFzIHBoeXNpY2FsDQo+IGFkZHJlc3MuDQo+ IA0KPiBFQVJMWV9VQVJUX0JBU0VfQUREUkVTUyBhbmQgRUFSTFlfVUFSVF9TSVpFIHNob3VsZCBi ZSBhbGlnbmVkIHRvIHRoZSBtaW5pbXVtDQo+IHNpemUgb2YgTVBVIHJlZ2lvbiAoaWUgNjQgYml0 cykgYXMgcGVyIHRoZSBoYXJkd2FyZSByZXN0cmljdGlvbnMuIFJlZmVyIEFSTQ0KPiBEREkgMDYw MEEuZCBJRDEyMDgyMSBBMS4zICJBIG1pbmltdW0gcHJvdGVjdGlvbiByZWdpb24gc2l6ZSBvZiA2 NCBieXRlcy4iLg0KPiANCj4gVUFSVCBpcyBtYXBwZWQgYXMgbkduUkUgcmVnaW9uIChhcyBzcGVj aWZpZWQgYnkgQVRUUj0xMDAgLCByZWZlciBHMS4zLjEzLA0KPiBNQUlSX0VMMiwgIi0tLTAxMDAg RGV2aWNlIG1lbW9yeSBuR25SRSIpIGFuZCBEb2MgSUQgLSAxMDI2NzBfMDEwMV8wMl9lbg0KPiBU YWJsZSA0LTMsIEFybXY4IGFyY2hpdGVjdHVyZSBtZW1vcnkgdHlwZXMgKG5HblJFIC0gQ29ycmVz cG9uZHMgdG8gRGV2aWNlIGluDQo+IEFybXY3IGFyY2hpdGVjdHVyZSkuIEFsc28sIGl0IGlzIG1h cHBlZCBhcyBvdXRlciBzaGFyZWFibGUsIFJXIGF0IEVMMiBvbmx5DQo+IGFuZCBleGVjdXRpb24g b2YgaW5zdHJ1Y3Rpb25zIGZyb20gdGhlIHJlZ2lvbiBpcyBub3QgcGVybWl0dGVkLg0KPiANCg0K Wy4uLl0NCg0KDQo+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vYXJtNjQvbXB1L2hlYWQuUyBi L3hlbi9hcmNoL2FybS9hcm02NC9tcHUvaGVhZC5TDQo+IGluZGV4IGY2OTJmYzc0NDMuLjg2ZTQw MTlhMGMgMTAwNjQ0DQo+IC0tLSBhL3hlbi9hcmNoL2FybS9hcm02NC9tcHUvaGVhZC5TDQo+ICsr KyBiL3hlbi9hcmNoL2FybS9hcm02NC9tcHUvaGVhZC5TDQo+IEBAIC0xMSw4ICsxMSwxMCBAQA0K PiAjZGVmaW5lIFJFR0lPTl9URVhUX1BSQkFSICAgICAgIDB4MzggICAgLyogU0g9MTEgQVA9MTAg WE49MDAgKi8NCj4gI2RlZmluZSBSRUdJT05fUk9fUFJCQVIgICAgICAgICAweDNBICAgIC8qIFNI PTExIEFQPTEwIFhOPTEwICovDQo+ICNkZWZpbmUgUkVHSU9OX0RBVEFfUFJCQVIgICAgICAgMHgz MiAgICAvKiBTSD0xMSBBUD0wMCBYTj0xMCAqLw0KPiArI2RlZmluZSBSRUdJT05fREVWSUNFX1BS QkFSICAgICAweDIyICAgIC8qIFNIPTEwIEFQPTAwIFhOPTEwICovDQo+IA0KPiAjZGVmaW5lIFJF R0lPTl9OT1JNQUxfUFJMQVIgICAgIDB4MGYgICAgLyogTlM9MCBBVFRSPTExMSBFTj0xICovDQo+ ICsjZGVmaW5lIFJFR0lPTl9ERVZJQ0VfUFJMQVIgICAgIDB4MDkgICAgLyogTlM9MCBBVFRSPTEw MCBFTj0xICovDQoNClNob3VsZCB0aGlzIHBvaW50IHRvIEFUVFI9MCBpbnN0ZWFkPyBGcm9tIHdo YXQgSSBzZWUgb24gWmVwaHlyLCB0aGUgcGwwMTEgaXMNCm1hcHBlZCB3aXRoIG5HblJuRSwgb24g UjgyIHRoaXMgd29ya3MgZmluZSBiZWNhdXNlIGl0IHdpbGwgdHJlYXQgYWxsIGRldmljZSBtZW1v cnkgYXMNCm5HblJuRSwgYnV0IEnigJltIG5vdCBzdXJlIHRoYXQgdGhpcyB3aWxsIHdvcmsgd2Vs bCBvbiBvdGhlciBBcm12OC1SIGFhcmNoNjQgcGxhdGZvcm1zLg0KDQpJIHdhcyB0cnlpbmcgdG8g Y2hlY2sgaG93IExpbnV4IG1hcHMgcGwwMTEgYnV0IEnigJltIGtpbmQgb2YgbG9zdCwgc28gbWF5 YmUgaWYgYW55b25lIGhhcw0KbW9yZSBleHBlcmllbmNlIGlzIG1vcmUgdGhhbiB3ZWxjb21lIHRv IGNvbnRyaWJ1dGUgdG8gdGhlIGRpc2N1c3Npb24uDQoNCkNoZWVycywNCkx1Y2ENCg0K From xen-devel-bounces@lists.xenproject.org Tue Dec 03 15:54:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 15:54:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848050.1263072 (Exim 4.92) (envelope-from ) id 1tIVEN-0005qs-Nc; Tue, 03 Dec 2024 15:54:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848050.1263072; Tue, 03 Dec 2024 15:54: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 1tIVEN-0005ql-J7; Tue, 03 Dec 2024 15:54:31 +0000 Received: by outflank-mailman (input) for mailman id 848050; Tue, 03 Dec 2024 15:54: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 1tIVEM-0005cM-1F for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 15:54:30 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on20619.outbound.protection.outlook.com [2a01:111:f403:2612::619]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id dff4cade-b18e-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 16:54:27 +0100 (CET) Received: from DU2PR04CA0320.eurprd04.prod.outlook.com (2603:10a6:10:2b5::25) by DB9PR08MB8652.eurprd08.prod.outlook.com (2603:10a6:10:3d0::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.17; Tue, 3 Dec 2024 15:54:22 +0000 Received: from DB1PEPF00050A00.eurprd03.prod.outlook.com (2603:10a6:10:2b5:cafe::14) by DU2PR04CA0320.outlook.office365.com (2603:10a6:10:2b5::25) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.17 via Frontend Transport; Tue, 3 Dec 2024 15:54:22 +0000 Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB1PEPF00050A00.mail.protection.outlook.com (10.167.242.42) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 15:54:20 +0000 Received: ("Tessian outbound 206fab1c37e0:v514"); Tue, 03 Dec 2024 15:54:19 +0000 Received: from L4a802d8ed828.4 by 64aa7808-outbound-1.mta.getcheckrecipient.com id E0882D8A-D090-4D06-A751-12B2DE7CCE90.1; Tue, 03 Dec 2024 15:54:09 +0000 Received: from EUR02-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id L4a802d8ed828.4 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 03 Dec 2024 15:54:09 +0000 Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21) by GVXPR08MB7848.eurprd08.prod.outlook.com (2603:10a6:150:16::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.17; Tue, 3 Dec 2024 15:54:06 +0000 Received: from DBAPR08MB5798.eurprd08.prod.outlook.com ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com ([fe80::4a66:d3e2:570:9632%5]) with mapi id 15.20.8207.017; Tue, 3 Dec 2024 15:54: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: dff4cade-b18e-11ef-a0d3-8be0dac302b0 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=B+Qtbw9oyaE1lAGPzMT8VEuxeodYK3+iD8E8i8mzZHzIJG0rak/4Nq8uOcK43qjz2WoG9z7vmgi6uGcVXWFtUR1eDSsZNl3wvY548zcxhTnIiMFsqHIWn1aVZ2cjBzoNwtSyVAWT6DQ8NtoUYVPkpgUQHXCA1DVb3dipaRJNJo8NyPStC4bIpg/PI5b8McY2KcReOfOOu3NSPxdyxjt+E9jVWalMTQJzxDuyT38gPYTvQYoSxgKF+tgg/jeUpGzYtrOJUy8b/8DZpwuIEFCuc6v6vYzFVFIWTP4OYjg1QYOLneChs40hZW0PEl3GMoyuu09vFR2mmvmuxHyJiUubgQ== 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=xfdpysEpVYmCg3juruySqhZcoVCTgjl+WYsJi5jecUg=; b=HzRZDY+EKrekH28A5cb6io+E772meaZ2nIOGhYKfGLamFaWlj2r+16x5dwra1MdO9od8SSsyVeI7EmhUQhTArZki4Pd1WFsA39L1y3w7juEfcKKZEkeG51wr9IatpfbRKUUtKsLsTq0x4IAhUAjZd94BJhYfgAJLKptevSd5Y7vYlR06hkmYpEEB05/9U0F0oKywKs78KzRdMmQR9SjSQ/OWSSWOA9lC1+oOFJzwTtZv8ouBQUfqY7k9JhI/J/Qr9zoP45g1I2hKo40t2PVRSPCjTkTxDwp7tKxofXfMAn9+mPmBvftAYRltJfdb+5hYuyaAMoRGDgTC4knJjA0k/w== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=xfdpysEpVYmCg3juruySqhZcoVCTgjl+WYsJi5jecUg=; b=WJtcuHKeANc8/OaKx5RJYSepl12CmXhA47sJE8MneE4gakqms/zDRCHYVzg9eBAJTIv8egzn/bm/N2zGfCMppkd4O+ktbrx8749y5JSXLCDBsmwl6OCOb2fENurWmI2Xeg0HWxeJ4UiKeS+5lmGNoQ44mdOUw042mrQvM0gCDvE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) 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 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C X-CheckRecipientChecked: true X-CR-MTA-CID: 010ef2828509d02d X-TessianGatewayMetadata: 9+hyyYhcfGB19mYMjSpKybmbsakIIFk2A9XZHmqADX7lE02beVJIhn26qWYMejnJMSXO3wdk6UeKTKkv6jamCFLtrQN4qjnxOW9xQNPqz2gBltPjPqQKqb3wl5//oySxxVfy1K4yp115D86yitSiphYIMnVGhs55QjVWFPu1kIE= X-CR-MTA-TID: 64aa7808 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qsea1hoiotbjsIDRX8p9Uqc9TC7iEmhbjUYia4Hs2UCnojkNqbwvsIxq5/PBa/7hhQlMPIQUd9uPyTTHXGSgcaHtCUgW/WFvca/uipz+4LUaNj87WEgclvrpI0OJboUoebELudunZ39qa+Z5xL9pyntwD2Zx43cJtNExJMfg78ls3t3o9/6++bVNa67bAn0rkYTH9R/vu/MILHb1W2pxKrdr3HwmM/Umy0MV7+26c09oR+dveinEeCxTEAECs9eeWqUdLzQFlDFiv69qWpKFKXv+Xo3qq6cCIvLY3XgiD2TJuOs2pu0736tcdPWGaLM7VE9yb3KWdIE5ojWF2NDwuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xfdpysEpVYmCg3juruySqhZcoVCTgjl+WYsJi5jecUg=; b=r6RIGH0S/DPl1KjRO64beuU35tBncyL1SCdUG139WJtUUCARGscPsEgPWIU+JvaFKjq6HzSasGuhtCJXoreE+0iobVpz9EEP2e4U83Q3dHR+QWvhkpcCHXxyECfyORcIGwDWhbEORVBMA7c2n1Rmeygkwn4XdeCeyvNX5cSQ7aJM2qQQYBQFhg4KHoawhCcnnI6cJKP9kvTvNSvgiKtP1enI9JhPLV4HffC07tOLiUFerlQ4tc6gJupfNotXGn8bQqVHJpm4lZh16wvXuFuKty3CvL0xZmDFKGwQJPVJYv11pVvDVin8ZNnrGqmzWbBpMB26SVXXa5FjvKW2fhipHA== 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=xfdpysEpVYmCg3juruySqhZcoVCTgjl+WYsJi5jecUg=; b=WJtcuHKeANc8/OaKx5RJYSepl12CmXhA47sJE8MneE4gakqms/zDRCHYVzg9eBAJTIv8egzn/bm/N2zGfCMppkd4O+ktbrx8749y5JSXLCDBsmwl6OCOb2fENurWmI2Xeg0HWxeJ4UiKeS+5lmGNoQ44mdOUw042mrQvM0gCDvE= From: Luca Fancellu To: Ayan Kumar Halder CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: Re: [PATCH v2 1/2] xen/mpu: Map early uart when earlyprintk on Thread-Topic: [PATCH v2 1/2] xen/mpu: Map early uart when earlyprintk on Thread-Index: AQHbRWz5mao3stJzR02TMW5lND/1eLLUrCiA Date: Tue, 3 Dec 2024 15:54:05 +0000 Message-ID: <433175CF-550A-4AF8-9422-5411D0107653@arm.com> References: <20241127183906.485824-1-ayan.kumar.halder@amd.com> <20241127183906.485824-2-ayan.kumar.halder@amd.com> In-Reply-To: <20241127183906.485824-2-ayan.kumar.halder@amd.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3826.200.121) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DBAPR08MB5798:EE_|GVXPR08MB7848:EE_|DB1PEPF00050A00:EE_|DB9PR08MB8652:EE_ X-MS-Office365-Filtering-Correlation-Id: 98007401-c0c8-46b8-8d63-08dd13b2c029 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|38070700018; X-Microsoft-Antispam-Message-Info-Original: =?utf-8?B?VmdKMUpsTFJqOThkaWRrTHRnK1pveGY3NlRBc0RnM25QVUhGRVFiK3dmQ2FG?= =?utf-8?B?RlN0SkZHbHVNY3o2SFpOU2xEWC9yTHFQcmJYY3hHb3NMMEJVM0czMnN1RWhQ?= =?utf-8?B?NEFBM1N5MSt2My9zelB2SXZXUEhtbVcrSU5ZM3JnZU9RZ1ZVSUl4MHozTUNx?= =?utf-8?B?RHU2U3BJQVR5TFJLbU5kc1R2SDZSVUgyTkkvVWVQZDdPNG9HMXMva1FrRVlz?= =?utf-8?B?TlJmR3ZsK0E1Y2Rqa0drVUUxMTFabHdnaXVYV2V3akpYdFFCb3dST3JXc0pp?= =?utf-8?B?TFhNSDg4bDNjb2hveTJqVGYvSGU3T3JnVEhvc0QrZEp6d2c1VE9rVTUydVds?= =?utf-8?B?WXZTcHJhZDB6S2VZZDZxZ3JQMXNicFduaFdoWjM1RFRxSjkvV2dXWjU1TVNL?= =?utf-8?B?dkp3NjlGZlVSN2lkUEszbGpZQjJHV2t3WEtuRU5pOEU3V3hwN1hPNzcrZWJv?= =?utf-8?B?V29mUVd1L285aUduSENKeWx3ZEdxWGJHOEM3T0FRR2NkNmVodHFrdDdLS2lz?= =?utf-8?B?TFRwUjVRVCt2azNuMXA4T3R3ZzZzVDlZZURvY0N1bC9QZ0RFd0ttcXA4c3k2?= =?utf-8?B?RktudUgwRXNpelU2SFYxWTNrRzBrM1h1YjhDSmtkbFZnWUNnM0xPY2RHSXpt?= =?utf-8?B?Z1Zxb21admxlV3RCSkRmWlZqeE9Yb2MwRFRRVnB2Rnc3dnJKMWdlSjZHb0ps?= =?utf-8?B?WHYvRTN0SS9EQlZoL2F0ZGU3Z0g0Zlg0Z2xTdlM2TUJoUnh1SEdRV2hqT1Fy?= =?utf-8?B?bUx6bkI2QTVJR2wrUEJBd21sWlZkQ0cyVGhUZnQ4YkJaYnNlNjNPMEZJSGFw?= =?utf-8?B?MlFTYkl5OStGMnJBN2I4Y2VyYVIzWG9rWC84Y3FhTE5Mc0wrYm1vdlpsYjlo?= =?utf-8?B?YXhCV2Rsb3U0c0lCVGtSK2dFeU1xTzRMSjJjQVVkVStDMkt1YlBWY2xqSG14?= =?utf-8?B?dUlCK0FkS2NlVU9rWnlKR0o3R21VZ0dFaWhhaHBYYVphQVBKSWVtY3g1akIx?= =?utf-8?B?U0ozVjd4U2JzRDJYNnFiRlU5Y3RBbDJEaDlybzd4S3RZVUhzM3pjTEZDY005?= =?utf-8?B?NmZqcklMODZKTmUvdG5XNGo2blJ2Q2FaMGIxcjJuY1I2dU1IVk9WODZ4b2Vk?= =?utf-8?B?YTB1emxxZWtSRVJUM2R4VEd5R2tCa1VnNVNQbmJXRmFTcGlKRTZicFJpTzFl?= =?utf-8?B?ekZ1Q2lzYW53OVJNd2dvdzZIZ0hPNGRtV0ZFRFVlMEhmampJVmRDRjFaWGtv?= =?utf-8?B?UHk4NDcrVlpzeGdlVFRja1BmMFN4RlJkSG1kQnR5R05GZzlMaURIMzhKd1ht?= =?utf-8?B?ZXFGRGlTVld0Ui85b0xiZElzRFpyOSswTFlwczZJUVMzUW56L1RSY0V1QUJD?= =?utf-8?B?a3h1ZzdKdm5yK1VJVFlWZ05sSGhrN2tLUzU3VDdRa0YrWC9EVHBIUGF2MWNF?= =?utf-8?B?QUtFREg2WHhicS90OGhoeXFFYlpyMUE4eTIzQ1dOUzFiUDZBcjQwaHplMmZv?= =?utf-8?B?cldsZTB0dUJHUENOanB6VERESHhTU3BnRFBZNml4bEZkT1ovMndnUys5aGpU?= =?utf-8?B?S2s2OG4vaUNyKzYwN1d4bXEyZE9XRVhwZTd3bDU4WjYzMkhGbS9IeGhHK3BX?= =?utf-8?B?Z056Tnk1MytLNThEb3pnVkUxUjNpMnY3VkVlUTFhTUx0dk1lRVoyZHFYMHRF?= =?utf-8?B?UmEyTXUzSkpDSDVnbzY5S0MyVUVFUUZMYXdSV0Npa1NQWXNFYUlVRnY5aVpI?= =?utf-8?B?bzdmUkNUcDVaYUw1aDRSMzhCQVl0VG9YRHpPclFQWm11TmZvVWRJSUgrMTFQ?= =?utf-8?B?RXJxYzRRTS8vWW9mR2V1VkhGV2lrVW0va0tlZzh5b2pWYnFsZjhBN09ZTXY3?= =?utf-8?B?V283bjBzUXBwbDBUSHl4ZEZzNmJ0M3JQcU84amVOdEdscEE9PQ==?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="utf-8" Content-ID: <45A5BC4B562B364EA12F102AC074CECF@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB7848 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-SkipListedInternetSender: ip=[2603:10a6:10:1a6::21];domain=DBAPR08MB5798.eurprd08.prod.outlook.com X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB1PEPF00050A00.eurprd03.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 909c3cb3-2a82-4153-52fc-08dd13b2b7ae X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|376014|1800799024|36860700013|14060799003|35042699022; X-Microsoft-Antispam-Message-Info: =?utf-8?B?elVibk9Fd3V4TTBNaHNyS2tEbTFrOHU4cFRyY3NMbEV6RGk0aXZvUnpHNlFF?= =?utf-8?B?czA5U3pZdS9wVGJQbzB1a0FYa2tya3JZcVlnM1ZsbUM3S00vZlA5ZlE5NC8y?= =?utf-8?B?YW14dVJaeElCaURTbWlSemtpak1JV1cxbS9rbWJpZzlUd1Y0YStETktOUU1l?= =?utf-8?B?MUdVTHFYd3NHMXJ6QXJOenJmWi80ZzArUDhGVmhpRG5kMjFoV2pZTHdxYktB?= =?utf-8?B?WFArMGJUaFB4UFo3UktTMkxwZDhWS1ROM1kxNzdrVWFQaHpsZXQ0eXN4NndM?= =?utf-8?B?c3dGSi9GNTV2ZVdkVFpmTXR5am9FQ0pBcWRrVDB5YlNLTUJoNGorSHd1bGhn?= =?utf-8?B?a0VqZHJheWpWT0k3M3RhMy84QzhZSk1VUSsxQlY0UXJ1Uyt4aTVXbVFBejlB?= =?utf-8?B?ejZEYkp3WG1sQ2F3VEhqYUZ5SlRBeEs0RGI1a2s0M2hHSlV1bXVZNnFZTXFi?= =?utf-8?B?aFRwVHVRVGhxZU81NHdjOFlFWENidGY2Tm5uK3k1N0psNVprdXp4em5ybjlI?= =?utf-8?B?MnlrdUc4VXc4OE03eGREY1cxZUxlSGVaUFNnZDNQQ1pCMm9hcEVEYWFoOU5j?= =?utf-8?B?emZuckswMitJVnk3SU0wTW9zVkdORWpCNHpvT094SkZDY0pGYU4zTEpOL3Az?= =?utf-8?B?ekp0TFcvSy9TVU0yaGZOL0ZHYjZsYXlkU29ZQUJvNmk0Rmd2dFcxakFUOWRK?= =?utf-8?B?U3FPZ3gxOUw2TjB4VlRram1jL0xWRU00aW9uOStBanJoTHBGRjhIdWkyTzhK?= =?utf-8?B?M2RtK1dkNFljd0t3NCtYSDlGUTF4VXZZc0xzd2RUWXZlZHhrdWUxcVpvaWg1?= =?utf-8?B?WU0yaVFuQXVlUzl0Wm5xb1RwK2p6ck1xemVuK3lSUzV6dHdNM1VoL2dUZG9M?= =?utf-8?B?S29mV3ZCdWh3UEI5TjZJSElramlFZ3RSajV4aWVsR25nSk9PcmJwL3JielI1?= =?utf-8?B?anBUMEdkdVF0Wlk2RlNsYyt3UnRjVDRWbG1oLzJZQW14R0tlOTJIR0VJc2ZH?= =?utf-8?B?MmoyTHovTVBoWGJoeWgxTjRlYTRJTTJlUnlUMjh1UHp0SnBCdmdwMzdjOU5j?= =?utf-8?B?MGFxd0hSWFNFTHFHaEdLVXNuRmkyeHZXL2sxTGRlSTBvKzhmRHozTTB1REhL?= =?utf-8?B?Z1hpK0J1OGh1NHZRczA1eXdVbEtHYkVBTUdqZUdyRDVsVmFuOVBkSjlKNnVL?= =?utf-8?B?bkFORityRXM1YnRvUXl5K2RGODhoS2NvblZmMHBYMCs4dFhDZDQ2aTdnQi9L?= =?utf-8?B?VjluUGJmOUx3c01FczA5ZnA1QVRGMWo1emZ1S25BdlI0UEdpTUI5VEg4Rmpz?= =?utf-8?B?RVhEaDRwU3hVdTBZZkUrRGN0Yyt0UUZpRUIyVU44RnBsTE1xaWtWM0Y1TVEz?= =?utf-8?B?aXVnZWxCdHFSMzdqVGxnWEJKT2YwdlFBbUQrR1g0bTZMMFc2M2lMRlpIZE1Y?= =?utf-8?B?c2hwR0EwcUJsc2Q4RkJWZ2p6RGxobUk5eUNmblFWbWhUQzFGOE1pa3RTVjJE?= =?utf-8?B?WFRjNGNhclF1RUF0cHBuVHduYTArUlJ5bm8vdmpQaEgyVXY0TG1Uc2svTzlT?= =?utf-8?B?d0Z3dUJFMExSMndkNHN5ZG9DaUlmZ0E4SVlxeWxSS0FSQUNiNld2eG5VaWtJ?= =?utf-8?B?VEJ3MnhZTUJIQlJkbEk5aTRTaWZBRjk4MkRHM2t4MnlCOFBxRWVER05Ib29M?= =?utf-8?B?M1hEQ0grSXRDNXN2ZVRLbGw4OWljdUV5LzdFRWNYU0VlSkNlLy80d0VuUlNZ?= =?utf-8?B?TTdBQjB3MWE4QTFYTFdJMk5lOWZjbTdaQnRENGFjcDVOWW16R255TU8xNjY4?= =?utf-8?B?YkZrRkhJUDUzYlBZWklyMTVKaDgxNUhwb3REdWU4TXJ2eFNFWVVTNm94d2N3?= =?utf-8?B?Q0YySjNYdDU2M0F3YVdiL2ZNR0ZZd25tY0VzKy9yQ1RkNzZmSFZwZVRwNzU5?= =?utf-8?Q?CpwDrivwlOmO3U+Y6dEiCJVskJSMofQd?= X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(82310400026)(376014)(1800799024)(36860700013)(14060799003)(35042699022);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 15:54:20.4283 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 98007401-c0c8-46b8-8d63-08dd13b2c029 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB1PEPF00050A00.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB8652 SGkgQXlhbiwNCg0Kc29ycnkgZm9yIHRoZSBzZXBhcmF0ZSBtZXNzYWdlLCBJJ3ZlIHNwb3R0ZWQg YW5vdGhlciB0aGluZyB3aGVyZSBJ4oCZbSBpbiBkb3VidA0KDQo+IE9uIDI3IE5vdiAyMDI0LCBh dCAxODozOSwgQXlhbiBLdW1hciBIYWxkZXIgPGF5YW4ua3VtYXIuaGFsZGVyQGFtZC5jb20+IHdy b3RlOg0KPiANCj4gQ09ORklHX0VBUkxZX1VBUlRfU0laRSBpcyBpbnRyb2R1Y2VkIHRvIGxldCB1 c2VyIHByb3ZpZGUgcGh5c2ljYWwgc2l6ZSBvZg0KPiBlYXJseSBVQVJULiBVbmxpa2UgTU1VIHdo ZXJlIHdlIG1hcCBhIHBhZ2UgaW4gdGhlIHZpcnR1YWwgYWRkcmVzcyBzcGFjZSwNCj4gaGVyZSB3 ZSBuZWVkIHRvIGtub3cgdGhlIGV4YWN0IHBoeXNpY2FsIHNpemUgdG8gYmUgbWFwcGVkLg0KPiBB cyBWQSA9PSBQQSBpbiBjYXNlIG9mIE1QVSwgdGhlIG1lbW9yeSBsYXlvdXQgZm9sbG93cyBleGFj dGx5IHRoZSBoYXJkd2FyZQ0KPiBjb25maWd1cmF0aW9uLiBBcyBhIGNvbnNlcXVlbmNlLCB3ZSBz ZXQgIEVBUkxZX1VBUlRfVklSVFVBTF9BRERSRVNTIGFzIHBoeXNpY2FsDQo+IGFkZHJlc3MuDQo+ IA0KPiBFQVJMWV9VQVJUX0JBU0VfQUREUkVTUyBhbmQgRUFSTFlfVUFSVF9TSVpFIHNob3VsZCBi ZSBhbGlnbmVkIHRvIHRoZSBtaW5pbXVtDQo+IHNpemUgb2YgTVBVIHJlZ2lvbiAoaWUgNjQgYml0 cykgYXMgcGVyIHRoZSBoYXJkd2FyZSByZXN0cmljdGlvbnMuIFJlZmVyIEFSTQ0KPiBEREkgMDYw MEEuZCBJRDEyMDgyMSBBMS4zICJBIG1pbmltdW0gcHJvdGVjdGlvbiByZWdpb24gc2l6ZSBvZiA2 NCBieXRlcy4iLg0KPiANCj4gVUFSVCBpcyBtYXBwZWQgYXMgbkduUkUgcmVnaW9uIChhcyBzcGVj aWZpZWQgYnkgQVRUUj0xMDAgLCByZWZlciBHMS4zLjEzLA0KPiBNQUlSX0VMMiwgIi0tLTAxMDAg RGV2aWNlIG1lbW9yeSBuR25SRSIpIGFuZCBEb2MgSUQgLSAxMDI2NzBfMDEwMV8wMl9lbg0KPiBU YWJsZSA0LTMsIEFybXY4IGFyY2hpdGVjdHVyZSBtZW1vcnkgdHlwZXMgKG5HblJFIC0gQ29ycmVz cG9uZHMgdG8gRGV2aWNlIGluDQo+IEFybXY3IGFyY2hpdGVjdHVyZSkuIEFsc28sIGl0IGlzIG1h cHBlZCBhcyBvdXRlciBzaGFyZWFibGUsIFJXIGF0IEVMMiBvbmx5DQo+IGFuZCBleGVjdXRpb24g b2YgaW5zdHJ1Y3Rpb25zIGZyb20gdGhlIHJlZ2lvbiBpcyBub3QgcGVybWl0dGVkLg0KPiANCg0K Wy4uLl0NCg0KDQo+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vYXJtNjQvbXB1L2hlYWQuUyBi L3hlbi9hcmNoL2FybS9hcm02NC9tcHUvaGVhZC5TDQo+IGluZGV4IGY2OTJmYzc0NDMuLjg2ZTQw MTlhMGMgMTAwNjQ0DQo+IC0tLSBhL3hlbi9hcmNoL2FybS9hcm02NC9tcHUvaGVhZC5TDQo+ICsr KyBiL3hlbi9hcmNoL2FybS9hcm02NC9tcHUvaGVhZC5TDQo+IEBAIC0xMSw4ICsxMSwxMCBAQA0K PiAjZGVmaW5lIFJFR0lPTl9URVhUX1BSQkFSICAgICAgIDB4MzggICAgLyogU0g9MTEgQVA9MTAg WE49MDAgKi8NCj4gI2RlZmluZSBSRUdJT05fUk9fUFJCQVIgICAgICAgICAweDNBICAgIC8qIFNI PTExIEFQPTEwIFhOPTEwICovDQo+ICNkZWZpbmUgUkVHSU9OX0RBVEFfUFJCQVIgICAgICAgMHgz MiAgICAvKiBTSD0xMSBBUD0wMCBYTj0xMCAqLw0KPiArI2RlZmluZSBSRUdJT05fREVWSUNFX1BS QkFSICAgICAweDIyICAgIC8qIFNIPTEwIEFQPTAwIFhOPTEwICovDQo+IA0KPiAjZGVmaW5lIFJF R0lPTl9OT1JNQUxfUFJMQVIgICAgIDB4MGYgICAgLyogTlM9MCBBVFRSPTExMSBFTj0xICovDQo+ ICsjZGVmaW5lIFJFR0lPTl9ERVZJQ0VfUFJMQVIgICAgIDB4MDkgICAgLyogTlM9MCBBVFRSPTEw MCBFTj0xICovDQoNClNob3VsZCB0aGlzIHBvaW50IHRvIEFUVFI9MCBpbnN0ZWFkPyBGcm9tIHdo YXQgSSBzZWUgb24gWmVwaHlyLCB0aGUgcGwwMTEgaXMNCm1hcHBlZCB3aXRoIG5HblJuRSwgb24g UjgyIHRoaXMgd29ya3MgZmluZSBiZWNhdXNlIGl0IHdpbGwgdHJlYXQgYWxsIGRldmljZSBtZW1v cnkgYXMNCm5HblJuRSwgYnV0IEnigJltIG5vdCBzdXJlIHRoYXQgdGhpcyB3aWxsIHdvcmsgd2Vs bCBvbiBvdGhlciBBcm12OC1SIGFhcmNoNjQgcGxhdGZvcm1zLg0KDQpJIHdhcyB0cnlpbmcgdG8g Y2hlY2sgaG93IExpbnV4IG1hcHMgcGwwMTEgYnV0IEnigJltIGtpbmQgb2YgbG9zdCwgc28gbWF5 YmUgaWYgYW55b25lIGhhcw0KbW9yZSBleHBlcmllbmNlIGlzIG1vcmUgdGhhbiB3ZWxjb21lIHRv IGNvbnRyaWJ1dGUgdG8gdGhlIGRpc2N1c3Npb24uDQoNCkNoZWVycywNCkx1Y2ENCg0K From xen-devel-bounces@lists.xenproject.org Tue Dec 03 16:49:26 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 16:49:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848075.1263082 (Exim 4.92) (envelope-from ) id 1tIW5O-00054i-Ns; Tue, 03 Dec 2024 16:49:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848075.1263082; Tue, 03 Dec 2024 16:49: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 1tIW5O-00054b-KM; Tue, 03 Dec 2024 16:49:18 +0000 Received: by outflank-mailman (input) for mailman id 848075; Tue, 03 Dec 2024 16:49: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 1tIW5N-00054T-If for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 16:49:17 +0000 Received: from EUR03-AM7-obe.outbound.protection.outlook.com (mail-am7eur03on20609.outbound.protection.outlook.com [2a01:111:f403:260e::609]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 88485fc2-b196-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 17:49:16 +0100 (CET) Received: from AS4P190CA0027.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:5d0::16) by AS2PR08MB9319.eurprd08.prod.outlook.com (2603:10a6:20b:599::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.19; Tue, 3 Dec 2024 16:49:11 +0000 Received: from AMS0EPF000001A8.eurprd05.prod.outlook.com (2603:10a6:20b:5d0:cafe::97) by AS4P190CA0027.outlook.office365.com (2603:10a6:20b:5d0::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.17 via Frontend Transport; Tue, 3 Dec 2024 16:49:11 +0000 Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AMS0EPF000001A8.mail.protection.outlook.com (10.167.16.148) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 16:49:10 +0000 Received: ("Tessian outbound 4eb3d11e9250:v514"); Tue, 03 Dec 2024 16:49:10 +0000 Received: from L98739cf83a07.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 9A4626CE-0AB2-43BA-AEAF-D8E276D5B68A.1; Tue, 03 Dec 2024 16:49:04 +0000 Received: from EUR02-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id L98739cf83a07.2 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 03 Dec 2024 16:49:04 +0000 Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21) by DU0PR08MB9631.eurprd08.prod.outlook.com (2603:10a6:10:448::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 16:49:02 +0000 Received: from DBAPR08MB5798.eurprd08.prod.outlook.com ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com ([fe80::4a66:d3e2:570:9632%5]) with mapi id 15.20.8207.017; Tue, 3 Dec 2024 16:49: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: 88485fc2-b196-11ef-a0d3-8be0dac302b0 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=vdERTbylWYMJ/vD2oE1OaMD3/gkh3SNPCkRtgSRpdmZCgNgi2w3H4wllHsiJ8XX/0p2dXNGnLvmynsNnY24gs1a/mRH5d0AEYjPCpG93W8smB0pfq6SqnNXBtjeU7F3z48fr3+GhFJ36WDGTlF77vJbhf75Z4rC0bOptL0vDDqP1yvXiDf9gu5utV3Cz2iQVHLLnVyVMYFVB5HhO1CU8wUQ+H1JV/UPaQIwi48JFfHZZtXHdRLMJP4P27fGXyVapfAMiczv0KI9vTVGal7G2a9BCNZK4y7qQqO0EG8Ax4AotcbyxGcl0Pq6/Dtngc7Rmhu2aen0bQjhnoOrpZB/47w== 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=GTYDWcqNwuIfZLvqdzy09qQIMnJ/Jd/lkFMevRKznCY=; b=sfE6veXKJp9zzGR2agG2Ojwwwm28l7qbPpyBAb5BXCxsOPoJjikUQ9J16bx02jaWJ9avNoTWupLZ+lHcFR7+5dIPW0q+CGrqMn9x+VBajzHxc7t3kp4JOpWx7LquRQKFdGrvOxEvoGHhhkmv0h9RqwPGW6ZOBDRAzjYX0JSx0ubonrAYM4xoD2SQhLmavUjztblpXwI0JH844NweHQNfYd97uCaNoMj801SWJc9tHjSQRJxbqqgO8B8w1MW5swtf4Pmd9IS7G4vjptbWeUigEX6nb+bmCjH76Hjos7mJWN0OXAoUifJYS/G3Ckw93LKJf2hVcoLtpQsge8hzSWGdkQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=GTYDWcqNwuIfZLvqdzy09qQIMnJ/Jd/lkFMevRKznCY=; b=Q/pmJq4jWmAJimVO3Z5Ja70a9pmVRTyTN2O5B7OsTHFEHMDDTNYGmJasdW4naLXncFq8bDM6Sr+Fsc+sLm5u5yj1u94pf86ZSYqOwb1Iv+sZTtVjKD22pUv+yNBjJCQCWYRKIbBmdGReIKL/wkJGChq1M6jJrKzmYMRDZKmPYLw= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) 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 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C X-CheckRecipientChecked: true X-CR-MTA-CID: 59ad6097e1d01965 X-TessianGatewayMetadata: ZUUalytOjh1LK2gW329sJOWQqHtSmrqf1/Dtzq+zcHGAb4VaJbhhZ7j8zVCYDa0SV9O/EX3DUiMlKTKRpe8Ui3wBE947mCtdLWt3zdhCQcC57dBI7Ks3xxycEp+2yCpXHvfG3WJsLsqyE028UIxY/hLvkdRIsj6bhGcZ9NuVxEk= X-CR-MTA-TID: 64aa7808 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YmUvcbT26rXZDw4gTkUx/bfzicwxXsAKex0Ct7hOTCyYXD7jFC2oWx2K72PXAqkbquBH4ca2vNeHQtHcB1ptk5A6TqCW63Ow3wYYEel4B/ns5wQvyTjQ+rUzZ4Qn/e3BgqjPdi87IQ8BsRZcfEyGK8ztLwNBDFtIyAkFrOObQyxXaNew8WG7CS5AusOtJHUO2fc6afbrllUpFx0R9/T01gw5B/vNFedx15/tC/76uGfMkuegMZIreU/l3M4FkYrVEdp3k0CSQLuIDzDO+3IGrLXiJ4/TvnAav4BeuuP0EiHw9wqTHdOm1Xie3MB5qfNA83Ipu/G++Sh7m2nIb+q3vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GTYDWcqNwuIfZLvqdzy09qQIMnJ/Jd/lkFMevRKznCY=; b=E8foPcEnVUAcLArSX8x8P5SQDG3EnR6r/qtoZeLzUllEAtEo2mE1GOREJLHxZA8GTqq8+TpnA4VvYo3hAwqWxceskQFb/VqduRJKL+4YUzURpWb83wbv1/o1yBLtQFnvR8cqQiaUDzaFNCOFYGk6WY6DPV3H9apF4YiuEQBlnl8t/mkAYuoPXSOk2ZdAPeLGzTPGYXjx2tZnulJSmsWYAG3+VeiS19EdWyhGgWIXo/DAMlvkYzOOVYN1K5TDTAwJ2vOjbBwr6SXIjreDrVNhVgJyD5WGIcQNvBsXvG6eSPBmjDNl110LFUL0l9N+T6LF9wPN1CP4vfOoqvNk011fpw== 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=GTYDWcqNwuIfZLvqdzy09qQIMnJ/Jd/lkFMevRKznCY=; b=Q/pmJq4jWmAJimVO3Z5Ja70a9pmVRTyTN2O5B7OsTHFEHMDDTNYGmJasdW4naLXncFq8bDM6Sr+Fsc+sLm5u5yj1u94pf86ZSYqOwb1Iv+sZTtVjKD22pUv+yNBjJCQCWYRKIbBmdGReIKL/wkJGChq1M6jJrKzmYMRDZKmPYLw= From: Luca Fancellu To: Ayan Kumar Halder CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: Re: [PATCH v2 1/2] xen/mpu: Map early uart when earlyprintk on Thread-Topic: [PATCH v2 1/2] xen/mpu: Map early uart when earlyprintk on Thread-Index: AQHbRWz5mao3stJzR02TMW5lND/1eLLUrCiAgAAPXIA= Date: Tue, 3 Dec 2024 16:49:01 +0000 Message-ID: References: <20241127183906.485824-1-ayan.kumar.halder@amd.com> <20241127183906.485824-2-ayan.kumar.halder@amd.com> <433175CF-550A-4AF8-9422-5411D0107653@arm.com> In-Reply-To: <433175CF-550A-4AF8-9422-5411D0107653@arm.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3826.200.121) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DBAPR08MB5798:EE_|DU0PR08MB9631:EE_|AMS0EPF000001A8:EE_|AS2PR08MB9319:EE_ X-MS-Office365-Filtering-Correlation-Id: 15a11a3c-9533-4c91-8edc-08dd13ba6947 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|1800799024|366016|38070700018; X-Microsoft-Antispam-Message-Info-Original: =?utf-8?B?bWNFdWc0OW1rcHE4VzdmMXRKQ0tWTjR1enZPUTlpQStTUXVTei9VOEhvalJM?= =?utf-8?B?cUthQlBwTmtVVGczOHlKQVJ3K2JVNHIwRTJhR3o3MElNVGZpQno1d0ZpbEI1?= =?utf-8?B?UDZhUEdMMzNvblpBMVFkQVFtRzBSYXp0K1dBTkdJdWlXcFFUUkM4NFIyNCtu?= =?utf-8?B?L1YyblpxTFFMV05TRmtBZmk5b2JVM3RVeFZSQUZJZ1pOZ1orMEtjaHBkQkVJ?= =?utf-8?B?Y2JKczh0TS9CQlF1Z3FPaEpDT2xHZmx5TFR3andLZjRBVTJYdzlIMWQyNHVk?= =?utf-8?B?aW4xdHZGNG0vWGpVd3RKeWVHS1UzUktIV3BwN2JOckpaanZvQ1VpL2ZMTFl3?= =?utf-8?B?VHJlUGd4ekdlL0lmeno3U2hHSUlhcHF4ajBQSlBtZEJOOG52c29mckg2OUtU?= =?utf-8?B?aUZjNVdkamNnWVd4SlJSNGthQzBYaU5uK2w3dVg1RUU5OFZ3ZVBpcnllOVhS?= =?utf-8?B?RnZYdk1IbHJjNjVlcWhSbE5JOXRPcXZMaXg1Tmtpb0YyT2VFMlR0ck9nMGJY?= =?utf-8?B?c0hIeUZLUmtuNGdEYnhVOEJSbHdBTTQzdzNwNldLWDJadCtNVHZLQ0ZGUUk1?= =?utf-8?B?MExXTHJqRDc0TzFYVUNscXF5WjBpTi9sbTZsUFp0bjYvN2I3RjdySlZpd0Uz?= =?utf-8?B?ODh3dTRoNU02ZVA2TXhJbDhnOWQzOEk2REU2TEVjMUFmN3Q4TmZxRk0xb29C?= =?utf-8?B?aEhEWVlUd0ZBL0F6d3NHa0NWcHJBcnZhNlRIc2lKdm9iZGhWb0kvS01jZ0h4?= =?utf-8?B?cHNqcEhxa3A5bEdjY1BGM2FJamUreXduZEtDN010OHNHSzFQdUg4R1FiU0Y1?= =?utf-8?B?SDZGUkNIZFgwdUxvNmdPNU1SaHkxNG5ENS9uc0d4U1RISTJ4WmJ3TXdwb2Rw?= =?utf-8?B?bGcxeDFGT2dOamFOem9vWG0vWFFJSVEydndTQmZqaUxvbVpoMlVJaWlMNVNX?= =?utf-8?B?RnlzUjJtT0VmZGdEMXRkb1BBNUtKaUs2b3FjQm8yeTZIdm5uZWovSlhuT2hm?= =?utf-8?B?M2JJUldJbThJbUNsZVJIK3FuR0RiNWY0bHhFeGVQL0JpcEZhU0NucUcwSXJQ?= =?utf-8?B?SWpiREJEVVpLTlhZUk9PV3lxdVRJZlRUOHNZT2xFanNjVE9NNExvVDNJVUU0?= =?utf-8?B?eUpxRFQzTHpYU3paWDRvenBEeXJSb3VaV0ovNXRIcTRXekxpVFB1YmR5K1Jy?= =?utf-8?B?QnJmRUVuak1TVEcrRVlkR0YvdlJhOHN4M0x4ZEtmeTdMQWRrUXdWc2lBZTgy?= =?utf-8?B?ZFBrdlZGdGJSV29pODU3VW9KL0syZUxFOWNHYnpIQTVFcGZHdXZ6NkV0MEZJ?= =?utf-8?B?NWZCK0J6QTFXc0JySDFSRDBnSXBDL21TbGZMa3pkRlFQMHBDQzF6bWVhSFRv?= =?utf-8?B?djlySjBmNFZ4MDErT05XdnR2SVJDNUVyUi9wRW0waDFORVN3VUV6SVBSRWJQ?= =?utf-8?B?L0dxVm5WMVZOZ2tVYk9adkNoVXdHVzl3Z1ovMWF6UXpzejNibzRjVFFleUlC?= =?utf-8?B?T09VOWlSMWlVWFFjRElXWjJnRXQ1MFNUMVBFcjVqUnlZZXNxUjk3aEh0OW5F?= =?utf-8?B?QS8xU1pkbnNGRThxelFHdHRhRTE2Tk9IR0F6U0FJQ05UczlCNi9KRkxPeG5U?= =?utf-8?B?cFp1T2hwQnh3MnFWcnZuaXNkU3FBWUN6dE5ia3Y0ODFsQVMvOW1GWDFPeTRE?= =?utf-8?B?VHBZQWEvRXpvUnRBMUhFSUdCVFpDRXRMbTJyY3VraGlxTXVPSmNnZ0hxekts?= =?utf-8?B?Y21JU1JSb1h0WXcwb0hKeGdQd1ljbjVlMzcvNUhkenJXaW13K251SmVidUdl?= =?utf-8?B?dThjZE4rWjUwb1VlT0J4Y1dRZEk3RWQ5QURZTVE5enh2WHhUT2ZlMTJVRCs4?= =?utf-8?B?alFHTXVrVDBpYUFsVHp1bk9MVkswSUlpYmEza3RpS1NoY1E9PQ==?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);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: DU0PR08MB9631 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-SkipListedInternetSender: ip=[2603:10a6:10:1a6::21];domain=DBAPR08MB5798.eurprd08.prod.outlook.com X-MS-Exchange-Transport-CrossTenantHeadersStripped: AMS0EPF000001A8.eurprd05.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 512c57ee-eda5-425e-46fe-08dd13ba6407 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|376014|14060799003|1800799024|82310400026|35042699022; X-Microsoft-Antispam-Message-Info: =?utf-8?B?dzluajdrU253M0VMTXNkWXp3STI0dERSWGVZRVJwcmswTGVaUlBwdHFlbHpo?= =?utf-8?B?NmFBU2FreFMvV21mNkFxUzRNNmExelZRY0cvTnovdlNpMTlVZEpqQ0hTYUJJ?= =?utf-8?B?NVBrbFhJOXNpYWU2ZHBBWXhYdlVmU0RBYTdWOEMxQXVTS3huYWVyZ2dISDNu?= =?utf-8?B?UXl4a0xkOWFJNnBrZU1LaURwOExJZVFxQmZOR3NTdHpGQWw4UTJnWmp2VW43?= =?utf-8?B?ZStxU1hSdUhlSnlRWFg5N004TStjT2t6Vng4eVlEWHoybVNwK3hVNHBxVW9M?= =?utf-8?B?WnJlMU4wdjVyQkZTTldrV1h1YTlLTVF2bEF1Z1c4M3pLRkZyMlZGN0dwaXh6?= =?utf-8?B?c1BIeUw1cEJ1emtNRVNaZ2hUWXQ5L1NVVDVIRDVzakZRTFFQZGcvZEptdnhD?= =?utf-8?B?SnBSd29PdUN3S0s3MXZHNy9ZaUQvWno4ODRuZ3o2QzFJRlhkWXJMTlZRaWRa?= =?utf-8?B?REJZcEYrWG5JQ1Q0a1dyQm5pbU5WUjhLNjkrazlvY01pNDRVOStYb2Fwd1Np?= =?utf-8?B?K3Z3V3l3SGd5Mkx1cEFqYlA4RzRFRHliblN4dUZHNUk3bDV4NjdncmgyNnUr?= =?utf-8?B?MzZIQnFZN0hXeWZPV2lJQUFzUW5BZlhIb28raFNxWFVHdURteGhBWStmT0pr?= =?utf-8?B?UXgzVndSNjhwUUx3NU1renAwTUltOGxDbnNFVmp6VTFCUmd0d0NxR1dwcUNr?= =?utf-8?B?UVE4UWd3NS9OZ1JIRTNNNWFjOVordGFSTVZoZk5md0REaDRncDJ6bTdLMGF4?= =?utf-8?B?alVMaDI0M2FrTTR3ZmN5ZTN4WDJUYURsTUJlcXhwU0FZZnp6bHJFeHlMYmg4?= =?utf-8?B?Q29VdmxIb29UdCtoQkp3RmNJd2dwVGRBd3pSWnR3RTJxS3FZRkxDL2dDT2Ns?= =?utf-8?B?TXdNSWJxWm5wSG0zOWFNb1lQRTJIQjZDejEyTEtCZzV3aDFuMUkxMmNtZUtG?= =?utf-8?B?bjd2NlRSbUVXQWlsbE5xVTVMWC9idVVCNURQTENpYXJHc1NpSnNlQmFkWXg1?= =?utf-8?B?MkNJK2RDem5SeThScWRuTi94SExNVGpWdUloeG4yRHUrbGdGbEgwcVVDTzBR?= =?utf-8?B?NitlZGZ1dnZQeGtTYThXa1ZvZU1sQU81RGd1UWQ4KzlpempieklPdS9hdWV4?= =?utf-8?B?MTBPU1hjUzZkL1BPdDNYbEhJYitHUDRsMnhVcWd1NGgxOVZLNmVIY2htdkRC?= =?utf-8?B?Ynkyb2R3dDVBbUE1dzBPR0N5enNwUzBKeVN0RVg1SVp5QXNHZkhmVG5oN1RZ?= =?utf-8?B?ajZQNnpjUXI1eTFSMVR6UXBSaUNBckh5NGtsQmxIcGVjUXZxOVcweFFMdk5z?= =?utf-8?B?VURtaGIwU1ZOZFhJYVFiaXBMY04rUy9DSGpVQ0o4RWNtL254bUkvN2RRaW9Z?= =?utf-8?B?NzkrM1BlcXdHZm80THUwOFFIaEpqRUdzYlJ4ZUdLVFpPb25iTzVybFVaVEpM?= =?utf-8?B?cTFlaVZuVHhpcksxRVJHQ2JXVEw4bTFOV01YZm8wMXdqd3dPZ0RQQjM0QnFq?= =?utf-8?B?U0JXY1d3eGo2NlBJbXZnc0gyV2NRaG1pbDdTMGthK0NtN3JMcXFsNDQ4c3Fp?= =?utf-8?B?MmlwRW95Zit2dWxMMmFWOEk4eTBaSm1vZlZrY2FkL1REeEp0T0YvSk5XWExq?= =?utf-8?B?Myt1MEhwMmlrN1ZETEIySlRZNkhBdXpxbExUalhtV25zTWVYTWhRZHJjVW5o?= =?utf-8?B?UVU5NjZNQzRnYjhOektvWGw1QTRhSEE0OGhyV3lOSURLTzhPZ1NLYWthMlhJ?= =?utf-8?B?RlhRaHVIMjFKcDNHMGFNeFR5OE9teXNBMHlEUWZpOG4rbFhjeW1ZZE9zSXk0?= =?utf-8?B?UEcyUzl0Wm9CZE85c3BhWU1QdnVBOFZLS1JkZTdkbi90aEZla0dmL05EUFBt?= =?utf-8?B?SGRrR2JSVGhENzJBSUdJTkkxcWt3TkpxR2JNSkxKSXRVanZDbWJSZXRHemZo?= =?utf-8?Q?QZbZU/yYdtP846qC5uJo8+Egbdv8YQFE?= X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(36860700013)(376014)(14060799003)(1800799024)(82310400026)(35042699022);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 16:49:10.6839 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 15a11a3c-9533-4c91-8edc-08dd13ba6947 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AMS0EPF000001A8.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB9319 DQoNCj4gT24gMyBEZWMgMjAyNCwgYXQgMTU6NTQsIEx1Y2EgRmFuY2VsbHUgPEx1Y2EuRmFuY2Vs bHVAYXJtLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBBeWFuLA0KPiANCj4gc29ycnkgZm9yIHRoZSBz ZXBhcmF0ZSBtZXNzYWdlLCBJJ3ZlIHNwb3R0ZWQgYW5vdGhlciB0aGluZyB3aGVyZSBJ4oCZbSBp biBkb3VidA0KPiANCj4+IE9uIDI3IE5vdiAyMDI0LCBhdCAxODozOSwgQXlhbiBLdW1hciBIYWxk ZXIgPGF5YW4ua3VtYXIuaGFsZGVyQGFtZC5jb20+IHdyb3RlOg0KPj4gDQo+PiBDT05GSUdfRUFS TFlfVUFSVF9TSVpFIGlzIGludHJvZHVjZWQgdG8gbGV0IHVzZXIgcHJvdmlkZSBwaHlzaWNhbCBz aXplIG9mDQo+PiBlYXJseSBVQVJULiBVbmxpa2UgTU1VIHdoZXJlIHdlIG1hcCBhIHBhZ2UgaW4g dGhlIHZpcnR1YWwgYWRkcmVzcyBzcGFjZSwNCj4+IGhlcmUgd2UgbmVlZCB0byBrbm93IHRoZSBl eGFjdCBwaHlzaWNhbCBzaXplIHRvIGJlIG1hcHBlZC4NCj4+IEFzIFZBID09IFBBIGluIGNhc2Ug b2YgTVBVLCB0aGUgbWVtb3J5IGxheW91dCBmb2xsb3dzIGV4YWN0bHkgdGhlIGhhcmR3YXJlDQo+ PiBjb25maWd1cmF0aW9uLiBBcyBhIGNvbnNlcXVlbmNlLCB3ZSBzZXQgIEVBUkxZX1VBUlRfVklS VFVBTF9BRERSRVNTIGFzIHBoeXNpY2FsDQo+PiBhZGRyZXNzLg0KPj4gDQo+PiBFQVJMWV9VQVJU X0JBU0VfQUREUkVTUyBhbmQgRUFSTFlfVUFSVF9TSVpFIHNob3VsZCBiZSBhbGlnbmVkIHRvIHRo ZSBtaW5pbXVtDQo+PiBzaXplIG9mIE1QVSByZWdpb24gKGllIDY0IGJpdHMpIGFzIHBlciB0aGUg aGFyZHdhcmUgcmVzdHJpY3Rpb25zLiBSZWZlciBBUk0NCj4+IERESSAwNjAwQS5kIElEMTIwODIx IEExLjMgIkEgbWluaW11bSBwcm90ZWN0aW9uIHJlZ2lvbiBzaXplIG9mIDY0IGJ5dGVzLiIuDQo+ PiANCj4+IFVBUlQgaXMgbWFwcGVkIGFzIG5HblJFIHJlZ2lvbiAoYXMgc3BlY2lmaWVkIGJ5IEFU VFI9MTAwICwgcmVmZXIgRzEuMy4xMywNCj4+IE1BSVJfRUwyLCAiLS0tMDEwMCBEZXZpY2UgbWVt b3J5IG5HblJFIikgYW5kIERvYyBJRCAtIDEwMjY3MF8wMTAxXzAyX2VuDQo+PiBUYWJsZSA0LTMs IEFybXY4IGFyY2hpdGVjdHVyZSBtZW1vcnkgdHlwZXMgKG5HblJFIC0gQ29ycmVzcG9uZHMgdG8g RGV2aWNlIGluDQo+PiBBcm12NyBhcmNoaXRlY3R1cmUpLiBBbHNvLCBpdCBpcyBtYXBwZWQgYXMg b3V0ZXIgc2hhcmVhYmxlLCBSVyBhdCBFTDIgb25seQ0KPj4gYW5kIGV4ZWN1dGlvbiBvZiBpbnN0 cnVjdGlvbnMgZnJvbSB0aGUgcmVnaW9uIGlzIG5vdCBwZXJtaXR0ZWQuDQo+PiANCj4gDQo+IFsu Li5dDQo+IA0KPiANCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vYXJtNjQvbXB1L2hlYWQu UyBiL3hlbi9hcmNoL2FybS9hcm02NC9tcHUvaGVhZC5TDQo+PiBpbmRleCBmNjkyZmM3NDQzLi44 NmU0MDE5YTBjIDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJtL2FybTY0L21wdS9oZWFkLlMN Cj4+ICsrKyBiL3hlbi9hcmNoL2FybS9hcm02NC9tcHUvaGVhZC5TDQo+PiBAQCAtMTEsOCArMTEs MTAgQEANCj4+ICNkZWZpbmUgUkVHSU9OX1RFWFRfUFJCQVIgICAgICAgMHgzOCAgICAvKiBTSD0x MSBBUD0xMCBYTj0wMCAqLw0KPj4gI2RlZmluZSBSRUdJT05fUk9fUFJCQVIgICAgICAgICAweDNB ICAgIC8qIFNIPTExIEFQPTEwIFhOPTEwICovDQo+PiAjZGVmaW5lIFJFR0lPTl9EQVRBX1BSQkFS ICAgICAgIDB4MzIgICAgLyogU0g9MTEgQVA9MDAgWE49MTAgKi8NCj4+ICsjZGVmaW5lIFJFR0lP Tl9ERVZJQ0VfUFJCQVIgICAgIDB4MjIgICAgLyogU0g9MTAgQVA9MDAgWE49MTAgKi8NCj4+IA0K Pj4gI2RlZmluZSBSRUdJT05fTk9STUFMX1BSTEFSICAgICAweDBmICAgIC8qIE5TPTAgQVRUUj0x MTEgRU49MSAqLw0KPj4gKyNkZWZpbmUgUkVHSU9OX0RFVklDRV9QUkxBUiAgICAgMHgwOSAgICAv KiBOUz0wIEFUVFI9MTAwIEVOPTEgKi8NCj4gDQo+IFNob3VsZCB0aGlzIHBvaW50IHRvIEFUVFI9 MCBpbnN0ZWFkPyBGcm9tIHdoYXQgSSBzZWUgb24gWmVwaHlyLCB0aGUgcGwwMTEgaXMNCj4gbWFw cGVkIHdpdGggbkduUm5FLCBvbiBSODIgdGhpcyB3b3JrcyBmaW5lIGJlY2F1c2UgaXQgd2lsbCB0 cmVhdCBhbGwgZGV2aWNlIG1lbW9yeSBhcw0KPiBuR25SbkUsIGJ1dCBJ4oCZbSBub3Qgc3VyZSB0 aGF0IHRoaXMgd2lsbCB3b3JrIHdlbGwgb24gb3RoZXIgQXJtdjgtUiBhYXJjaDY0IHBsYXRmb3Jt cy4NCj4gDQo+IEkgd2FzIHRyeWluZyB0byBjaGVjayBob3cgTGludXggbWFwcyBwbDAxMSBidXQg SeKAmW0ga2luZCBvZiBsb3N0LCBzbyBtYXliZSBpZiBhbnlvbmUgaGFzDQo+IG1vcmUgZXhwZXJp ZW5jZSBpcyBtb3JlIHRoYW4gd2VsY29tZSB0byBjb250cmlidXRlIHRvIHRoZSBkaXNjdXNzaW9u Lg0KDQoNCkFueXdheSwgY2hhbmdpbmcgdGhhdCB0byAweDAxIChBVFRSPTAgRU49MSkgaXMgZ2l2 aW5nIG1lIGEgd2VpcmQgaXNzdWUgaW4gbXkgYnJhbmNoOg0KDQoiRXJyb3IgZ2V0dGluZyBJUlEg bnVtYmVyIGZvciB0aGlzIHNlcmlhbCBwb3J0IDDigJ0gZnJvbSBjcmVhdGVfZG9tVXMoKSwgc28g SeKAmW0gbm90IHN1cmUgbm93DQppZiB0aGUgcmlnaHQgdmFsdWUgd2FzIGluZGVlZCAweDA5DQoN Cg== From xen-devel-bounces@lists.xenproject.org Tue Dec 03 17:47:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 17:47:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848100.1263091 (Exim 4.92) (envelope-from ) id 1tIWzf-0004O4-J2; Tue, 03 Dec 2024 17:47:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848100.1263091; Tue, 03 Dec 2024 17: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 1tIWzf-0004Nx-GG; Tue, 03 Dec 2024 17:47:27 +0000 Received: by outflank-mailman (input) for mailman id 848100; Tue, 03 Dec 2024 17: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 1tIWze-0004Nr-1C for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 17:47:26 +0000 Received: from metis.whiteo.stw.pengutronix.de (metis.whiteo.stw.pengutronix.de [2a0a:edc0:2:b01:1d::104]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a6dadde0-b19e-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 18:47:23 +0100 (CET) Received: from ptz.office.stw.pengutronix.de ([2a0a:edc0:0:900:1d::77] helo=[IPv6:::1]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tIWyE-0003sq-Mm; Tue, 03 Dec 2024 18:45:58 +0100 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a6dadde0-b19e-11ef-99a3-01e77a169b0f Message-ID: Subject: Re: [PATCH 09/22] drm/etnaviv: Convert timeouts to secs_to_jiffies() From: Lucas Stach To: Easwar Hariharan , Pablo Neira Ayuso , Jozsef Kadlecsik , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Julia Lawall , Nicolas Palix , Daniel Mack , Haojian Zhuang , Robert Jarzmik , Russell King , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Ofir Bitton , Oded Gabbay , Lucas De Marchi , Thomas =?ISO-8859-1?Q?Hellstr=F6m?= , Rodrigo Vivi , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Jeroen de Borst , Praveen Kaligineedi , Shailend Chand , Andrew Lunn , James Smart , Dick Kennedy , "James E.J. Bottomley" , "Martin K. Petersen" , Roger Pau =?ISO-8859-1?Q?Monn=E9?= , Jens Axboe , Kalle Valo , Jeff Johnson , Catalin Marinas , Andrew Morton , Jack Wang , Marcel Holtmann , Johan Hedberg , Luiz Augusto von Dentz , Greg Kroah-Hartman , Florian Fainelli , Ray Jui , Scott Branden , Broadcom internal kernel review list , Xiubo Li , Ilya Dryomov , Josh Poimboeuf , Jiri Kosina , Miroslav Benes , Petr Mladek , Joe Lawrence , Jaroslav Kysela , Takashi Iwai , Russell King , Christian Gmeiner , Louis Peens , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Naveen N Rao , Madhavan Srinivasan Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, ath11k@lists.infradead.org, linux-mm@kvack.org, linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, live-patching@vger.kernel.org, linux-sound@vger.kernel.org, etnaviv@lists.freedesktop.org, oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, Anna-Maria Behnsen Date: Tue, 03 Dec 2024 18:45:50 +0100 In-Reply-To: <20241115-converge-secs-to-jiffies-v1-9-19aadc34941b@linux.microsoft.com> References: <20241115-converge-secs-to-jiffies-v1-0-19aadc34941b@linux.microsoft.com> <20241115-converge-secs-to-jiffies-v1-9-19aadc34941b@linux.microsoft.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.52.4 (3.52.4-2.fc40) MIME-Version: 1.0 X-SA-Exim-Connect-IP: 2a0a:edc0:0:900:1d::77 X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: xen-devel@lists.xenproject.org Am Freitag, dem 15.11.2024 um 21:22 +0000 schrieb Easwar Hariharan: > Changes made with the following Coccinelle rules: >=20 > @@ constant C; @@ >=20 > - msecs_to_jiffies(C * 1000) > + secs_to_jiffies(C) >=20 > @@ constant C; @@ >=20 > - msecs_to_jiffies(C * MSEC_PER_SEC) > + secs_to_jiffies(C) >=20 Thanks, applied to etnaviv/next. Regards, Lucas > Signed-off-by: Easwar Hariharan > --- > drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c b/drivers/gpu/drm/e= tnaviv/etnaviv_cmdbuf.c > index 721d633aece9d4c81f0019e4c55884f26ee61c60..0f5a2c885d0ab7029c7248e15= d6ea3c31823b782 100644 > --- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c > +++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c > @@ -100,7 +100,7 @@ int etnaviv_cmdbuf_init(struct etnaviv_cmdbuf_suballo= c *suballoc, > mutex_unlock(&suballoc->lock); > ret =3D wait_event_interruptible_timeout(suballoc->free_event, > suballoc->free_space, > - msecs_to_jiffies(10 * 1000)); > + secs_to_jiffies(10)); > if (!ret) { > dev_err(suballoc->dev, > "Timeout waiting for cmdbuf space\n"); >=20 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 19:03:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 19:03:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848144.1263118 (Exim 4.92) (envelope-from ) id 1tIYAa-0006IS-7t; Tue, 03 Dec 2024 19:02:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848144.1263118; Tue, 03 Dec 2024 19:02: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 1tIYAa-0006IL-5I; Tue, 03 Dec 2024 19:02:48 +0000 Received: by outflank-mailman (input) for mailman id 848144; Tue, 03 Dec 2024 19:02: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 1tIYAZ-0006ID-6U for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 19:02:47 +0000 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on20610.outbound.protection.outlook.com [2a01:111:f403:2414::610]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2d182a84-b1a9-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 20:02:44 +0100 (CET) Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7) by MN0PR12MB6270.namprd12.prod.outlook.com (2603:10b6:208:3c2::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 19:02:39 +0000 Received: from PH8PR12MB7326.namprd12.prod.outlook.com ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com ([fe80::6d76:9c33:d230:8264%6]) with mapi id 15.20.8207.017; Tue, 3 Dec 2024 19:02:39 +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: 2d182a84-b1a9-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=o7VmRKos0b6LcSMUOf1sFB+otFB6gPrqgC3h3k6c9Ha1kTUP3lXsmSY7qQAdr2hHW+EVzk+BzewM0VLrJRQz/l8AxfHks7Gi0ei487o8i+poRYZYuiVH6cO1ZEKxhn/PPLOeLTS3e/FLcwVivjxZQHR8bKr0u2nN5gUDoHo9zw4EclPfOS0I97WF5Aa4nqMAO5CYWb14qCrk9AWya2kI5XQ+OmJMn3B/ZmKLv0LguUYyL7fevK61MVs1W0xm5Px94Lsv9Bm+Fvs0FEF5DZqheG+4h0uZd3jZrT1wGfwtsTEX4fpgEtTZ12AhfHwAbQotj3VypVfn5DE36MFkVvAdsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ftzR8sMcBRKNtfSrvzvZZugSVvuk50Hs8EIhto9ICKM=; b=vXdSCdD44iyCHVFVErFj6/lcnd+/b9iFv8Kev8QeQyfOBxHhzXSnusESuEIigDjwz135u7Q+nLzVAD5egh5CCEQLFfRr8C3WDvOsaeVSloUal2IlXHMUmGOxdYsebcsQaRL9Kd6oTPTGXW/PbMiJytal8URhaikrBrgEdn4BX/c5nUA/hMUyGFXGEALRmrFoqn4VR10FoheTxgViVVG/p+Anm3f8XgUXVa6QC2f3pZyoJnxnPLMyW+JPR5lV9SvrBLS6wv+Z4YjmfF+hYzx5CZIoasgz7JMvtzIEJ0enOAucX3eyWXJaPWI6jjf5LGr3zMIYc4p9nUeuMMhoS1U4Sg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ftzR8sMcBRKNtfSrvzvZZugSVvuk50Hs8EIhto9ICKM=; b=wmyiwRLfcNkuYBJyyN7Z13nRCN+Y5fyPA4Tjgeu8TaibyuteJzqbh5lNyekP1UaL29cyRPEI9DlNKoj2AhVuiSikTgRvVPj1OqyGA8OpLmWpNzpQ0sL39yPwhMVnmFKj9zljb1PamMRMptcVCCEk9Vpbh3n7xXZ3GdOdhLPdWUo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <048424f0-41ee-4bb7-b585-42ed82a337b4@amd.com> Date: Tue, 3 Dec 2024 19:02:34 +0000 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] xen/mpu: Map early uart when earlyprintk on Content-Language: en-GB To: Julien Grall , Ayan Kumar Halder , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20241127183906.485824-1-ayan.kumar.halder@amd.com> <20241127183906.485824-2-ayan.kumar.halder@amd.com> <41114d52-b618-4692-87f5-94de4b7ddeff@amd.com> From: Ayan Kumar Halder In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0383.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a3::35) To PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|MN0PR12MB6270:EE_ X-MS-Office365-Filtering-Correlation-Id: 6af21d10-573d-42fc-75ed-08dd13cd0ec1 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: =?utf-8?B?RktGZGVmOFFEcVRyL2ZzN1NacWZvOHdabDRoN0pnNU9wWnk3TjUvOUlzSWhr?= =?utf-8?B?WUQ4d3pteTR4Um5yZFpJNmxSclBPTlYxOE5VUFhYZ1BJSUhuU2ZLcGpPQmdH?= =?utf-8?B?OUg2SGFubHYvVUNHTm1GNkMvVVpVUUNDR2o2bFhJNlNubmJSTGZySHZTYVF3?= =?utf-8?B?THpTWTJtMDVDSUtYbk5nMWpCem00dEs3T0c0VGQ3TXI5enFhYzhiamZwdXRk?= =?utf-8?B?ZXRxKzIxdGRMUWlIcDlOMW5tdjh4WVE0eTRlYTdUYStwS3JyOTBTVk1BOFJt?= =?utf-8?B?Tlhkd2NtcGgwcFRhV3ZuUkRTd3NXaFZQemh0YjlYeW9NTmN6cHRtOXZwakxz?= =?utf-8?B?SGlCUWpZazFGYnpFYnl0RjRENmR2eStMNnhhVWhUM09iZ2RLb1I1S3dzbFVO?= =?utf-8?B?SUZBVGZLbkh5R2FYU2Q3cDdUdmdyRWIwTHQyRUt6U2tQUHoyMEJqbnNmTVFu?= =?utf-8?B?Q1JOc3RMRDhsM0swcjdKQ21NdHJxSGlZSzlsRGQralJKTDhBV3pyWTFwaTlJ?= =?utf-8?B?bnI2cnBxZUlvVWMrM1NmSWRiRmRCck0yd2lwNzVyS1ZvMW1wT3hVNnFWT2Rw?= =?utf-8?B?VHJNVlQ2aXVxMSt5Z1YrSVBJNFNPR2ZwcG94WjNYOUJ4U3d3ajZLUFFmU2pU?= =?utf-8?B?cmpEKzF6ZUd2U0JnRDNGMEJMYWRBSjZkT0xmVWl0cXlwVkNRMHFiMy9CL0R6?= =?utf-8?B?NDFwcjRmSk5NRWVYQXgxOXdybldSUTRsR2tsRUF4N0JsbmhJNXNzR2FZWHZK?= =?utf-8?B?L0VlVE9saVlETXhmZ0NBazkvNXAwMjVEbE1kVjJaZUZDRldLNTE3bERJbVlr?= =?utf-8?B?Rk9ubXdqeE5qUTNpa1hVYWRoVjlQVzF4TUo0dVZiYWtBazNPUFp0RWE3WjJ5?= =?utf-8?B?S050Um8wWSt5eUxUeTVTSmpoUFRpODZIT0FHSC9Na1BYL3prSUg2OFBSczFW?= =?utf-8?B?cVgrbFBCcEdveXJCdkx1WDRWOFJScUxCVlpTY0JWdUQ3UEZzWkR1Kzc0ZmxV?= =?utf-8?B?eVk3VHdNSkRSMUcydTdCeTd1Z3NUL3NzYitFMUtHcExNbHFJaVU2eGs1cC9T?= =?utf-8?B?ajB6cjZNZWVwOVZZVTRRVVZTWFBhT0pXTk1ldzVaWnFwUWVVYWF0N0RYNFIr?= =?utf-8?B?R3B2OTBwLzVFUm9yektRdDk0YThXTWVnaHd5bTBtc0NWY2NvT1JodEFoc1dH?= =?utf-8?B?REM0NG9VKzNtYUNoa0c3bmlJNElGRjRRd09tNGt2aVY2SjBIZ3RyVEVoRXdI?= =?utf-8?B?OUhOcVRSazRFNEI4MjI4dXRDYjErVFEvOEJJK2U2cHRtWnYxNFNWS0ppOElm?= =?utf-8?B?Z29Ybmc3WGpuNWM2cGgrSUd0aXhUNWI4QkRpRHpHSjF2NEJnQi91NGNRS3dh?= =?utf-8?B?K0c4NXdodXltSGc1ZEZZdlQ1ZGxQSkNGMVA5Zi82N21EM29BbjF2N1hDRnRq?= =?utf-8?B?TXFqQ09FUGdvRzRucWFXdHFSYUJGTnR1Vi9sV1RYb21JZ3paUU1wM0dkd1Bn?= =?utf-8?B?L0NOd0pNclRzK3FzQnI5ZkdEelJNTjhGdVUzV0NEWitTUmtNb0pmWjhER3dx?= =?utf-8?B?UXFqdlY4Y2owMGhOSUFhQUdOWmd0eGtmSThLWWQ3N0VMNzhtSThwV3pDUkl5?= =?utf-8?B?N2FrOUpNd3RZS1ZQZkNwQzFpTDZEdzRGcHRYNGN6ME1vZEZDaTBsazBzUHJE?= =?utf-8?B?MHZrQjhJZ2lpV3hrc2NteFp4KytCSjhVNTJROGdIUkFmK2tmbzNSa0lCWlpx?= =?utf-8?B?OUsrY25MMGRKN2o5cXU3MURWd2p2T08yN0djUktQWWJMMjA2QjhwR0RoWmVN?= =?utf-8?Q?Ew7fClUyLABKfx0GSO1QNyykgxsEvPWegDFqM=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH8PR12MB7326.namprd12.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?eElHaldmcEZocWJZR3J6MWg0N08xdkNZNHlJSVRrTllxVWNlOWVlVWx3R2dZ?= =?utf-8?B?aUJxZko3UnJ5a28vYktoUVZkWHp4YTJIMnpMdklVYVU3bXVscSs4WlNmbmVD?= =?utf-8?B?WUhqLzFjVWl4eFc1MFN0V0lZOURRVDV3dmt6ZGxWL1JDVjcwQ0x4UEFIMXRK?= =?utf-8?B?Uy9HeVdIbm1RVWJpeXExMWlkN2hrMEsvUzRqa0pRQTlJUmpOWnJyTnFaRUlC?= =?utf-8?B?cmhJWmtQWXdadzBXQ2FkNTBkZmluc2tJYWY5djh0Q1NrTVIrUE9hK2dTTit2?= =?utf-8?B?Y3ljUDlkbDZyVmI3a1J3alhCSTErSGVYWnh3ZmZOOEdvZHliNi9TNEFPaGJh?= =?utf-8?B?NWJtVk16Y2R6NmxvQjcxVm5iRlM2ZWJiL1RKa1ZXYXRjT3JodGRmd0Q1NmtD?= =?utf-8?B?RGRCanhsQjJsd0lpMTZvam9zRXVHRWczbi9tT1lzNEtUckRTczB1VUVacG1Y?= =?utf-8?B?WjExNDB5aFlJak9aUkxLVXh1c24rZlZDdzRLYUtIYk0wOG41TjBvdjRVb25w?= =?utf-8?B?Q2FxZTJmUHB6ZE1XNzBneHRpK09TczNPOUJBcW5zWHExdGd3UHFRcjJLaUt5?= =?utf-8?B?end1SFRzb1I1Y01xZkYrK3pmV1lOc3BlUU5uTEhMUnJtbDhPWTNmTXFLZWtP?= =?utf-8?B?bmp1b3dSMkpHQ1RWUWJpVG0rNlRIbk55ODBQVkpsQ29LbzF5SEo3R2pyN2dh?= =?utf-8?B?V0NXbTU4dVQ2amZPMC9TOGd3UkJVamJQeFRnQUxyMVVOODRUVS80c003cGNJ?= =?utf-8?B?eElwMXJPeDkwVnVKSXlROFJBOWM4eDNuYXhvUDFCeFZqaVVKMWxRYnRVL2Zn?= =?utf-8?B?Y1l6VUhkZjdiQ21tbWZjVHlwLzFUSHBFdlBwUEhxY2tvYXhhb2lBNStYOEpx?= =?utf-8?B?anpVUGh6MjAyRnROMWNRYmtxdmlPNDhZNnN6L0hFdVpSd2dOak5XVVNvb0RO?= =?utf-8?B?YlNQbk85YTk4T3Y1aFpZb2RlVzFta0g2QytUV1lHaUQ0T0pJSlhRcXBJWFov?= =?utf-8?B?Q2hBaENXK0JiN3BsakE2aVZFRzFLUzZOMFpETW1YQXY0eWNjTFhDRVc1WFJh?= =?utf-8?B?Qm0vWGxONW15aDUyZDd0U0drK2QzTzREQ0Z1a1E1Z24yL09JWkZRNkJ1NUhO?= =?utf-8?B?WHlpVXFWaGljVjlTeTJQMjJNOEpxNlBONHA1OWN4WU5VWW4weGlJbmJXbzZU?= =?utf-8?B?NjYyT2Urcmc1Nk8ybmx5QXBCVU8vRnFtQXRpMlA4TENLMHVzZXJmM0dEQWMr?= =?utf-8?B?K01qYmhodDRHVFVRS0krR2JhV25Ma05KdDQrSWVLUTFMZFU0M1pQUnBLai83?= =?utf-8?B?bGljTG1nNDRUVXZ1WVlJdjZvb3N3bkx2YWh3NTgvQkhzOUJQSkpsODFWNWdr?= =?utf-8?B?N3IzQlk0WHZQLzNORnM4VElmRno5NDhaZUxrVWNTTXAzNFlBak5ibW83eVFV?= =?utf-8?B?L3lsRjJyWDdhby9WVDBYRVNwc1J6QTQzODlCQllwWGMvUUc4WkxWZ0t2djNG?= =?utf-8?B?a3k5MUxjRmlmQk1FWEVpUmJBMzBmSWsvQklhTzV4NUgzbHFmeE5wRDN5RzF4?= =?utf-8?B?Y3lqZGVja3VDUkk1VEVsalZGVXpIaEZVSEMvVkFJR21SNGc4Yzc5aUtEbEow?= =?utf-8?B?WXNLbUtZQmpVM2FxWUtmZzFzN25SZEg0MHhZcGJ5MzBNS0ZMNFA2ajdBR0Fz?= =?utf-8?B?T0hXQXlLMSsvR1dieGM5cnFrQnNIQlNxeXlJS0VLdXpCMGg3ZDFiKzlMTEFH?= =?utf-8?B?aFdwZUFXLzZERks5SWhjUENpbTVmYmlKSG1CbG16bzNibGxYc2h5dVhodGxZ?= =?utf-8?B?cnB3NGhjajVvT2RvQjJSaHdsSWU3bGlmZGVmVW9OOFRRY29vN2dyMjgyTzJ1?= =?utf-8?B?dDVsWEgvL0VoeWVCRVJRSmNFMkhsMzNsVWU3VkZCUWN2ZDM0MU1aOUhGbnpi?= =?utf-8?B?d2Z3T0dGL3BUeFkxNGpSTVorbERHMUx5a1p0N01TVzFFR1VRR1FKQ05SYy94?= =?utf-8?B?YnFzUjkxMjdpK2o0NUhkbUlQUExlMHNINmVTYXhsdHMzdEtJLytQWm9XMkZp?= =?utf-8?B?VUlYbWdSZHFjWEtTRUIyNWFvN3JaajRrcVFLQnUycmNzVDhLSE9nbVd6Nnpy?= =?utf-8?Q?hvOGWR0EW9mtuFDTW3HoSBhve?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6af21d10-573d-42fc-75ed-08dd13cd0ec1 X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 19:02:39.6492 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: LDsqEyoObCBEE6E4V43wMYAW9EmhX2Y0GmFzQznY+gQvO9MMYEdkSFMzz5KrCBuqsaFv7tKt3ZZ/eJm7mxpDog== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6270 Hi Julien and Luca, (Luca, I will respond to your other comment here) On 03/12/2024 13:50, Julien Grall wrote: > > > On 03/12/2024 13:34, Ayan Kumar Halder wrote: >> >> On 02/12/2024 20:53, Julien Grall wrote: >>> Hi Ayan, >> Hi Julien, >>> >>> On 27/11/2024 18:39, Ayan Kumar Halder wrote: >>>> CONFIG_EARLY_UART_SIZE is introduced to let user provide physical >>>> size of >>>> early UART. Unlike MMU where we map a page in the virtual address >>>> space, >>>> here we need to know the exact physical size to be mapped. >>>> As VA == PA in case of MPU, the memory layout follows exactly the >>>> hardware >>>> configuration. As a consequence, we set EARLY_UART_VIRTUAL_ADDRESS >>>> as physical >>>> address. >>>> >>>> EARLY_UART_BASE_ADDRESS and EARLY_UART_SIZE should be aligned to >>>> the minimum >>>> size of MPU region (ie 64 bits) as per the hardware restrictions. >>>> Refer ARM >>>> DDI 0600A.d ID120821 A1.3 "A minimum protection region size of 64 >>>> bytes.". >>>> >>>> UART is mapped as nGnRE region (as specified by ATTR=100 , refer >>>> G1.3.13, >>>> MAIR_EL2, "---0100 Device memory nGnRE") and Doc ID - >>>> 102670_0101_02_en >>> >>> I can't find the Doc you point online. Do you have a link? >> https://developer.arm.com/documentation/102670/0101 - Cortex-R82 >> processor TRM > > Thanks. But why are you quoting the Cortex-R82 TRM? > This code is meant to work on any Armv8-R processor. You mean Armv8-R AArch64 processor. Actually, I was looking for a reference to tell me if UART is to be mapped as a nGnRE or nGnRnE. Table 4-3 mentions that nGnRE corresponds to the device memory. So, I used this. I assumed that this behavior will apply to all Armv8-R AArch64 processors as it did not mention anything specific about R82. To address Luca's comment >>"on Zephyr, the pl011 is mapped with nGnRnE". I don't really have a good reason whether we should map it as nGnRnE or nGnRE other than what I have mentioned before (ie nGnRE corresponds to device memory). I am happy to change it to make it consistent with Zephyr and Linux (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/include/asm/mpu.h?h=v6.13-rc1#n67 , this is Armv8-R **AArch32** ). Let me know which one you think is correct. Other comment from Luca >>"Anyway, changing that to 0x01 (ATTR=0 EN=1) is giving me a weird issue in my branch:" This is due to https://gitlab.com/xen-project/people/lucafancellu/xen/-/commit/4ec46883b1dffcbafd86c32732d1267102696d84 , |ioremap_cache() in arm/mpu/mm.c . This can be fixed if we choose nGnRnE.| |- Ayan| From xen-devel-bounces@lists.xenproject.org Tue Dec 03 19:30:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 19:30:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848155.1263129 (Exim 4.92) (envelope-from ) id 1tIYbF-0001fT-9m; Tue, 03 Dec 2024 19:30:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848155.1263129; Tue, 03 Dec 2024 19:30: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 1tIYbF-0001fM-5B; Tue, 03 Dec 2024 19:30:21 +0000 Received: by outflank-mailman (input) for mailman id 848155; Tue, 03 Dec 2024 19:30: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 1tIYbD-0001fG-Hl for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 19:30:19 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2061c.outbound.protection.outlook.com [2a01:111:f403:2612::61c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 07679e40-b1ad-11ef-a0d3-8be0dac302b0; Tue, 03 Dec 2024 20:30:18 +0100 (CET) Received: from GV1PR03MB10456.eurprd03.prod.outlook.com (2603:10a6:150:16a::21) by AS4PR03MB8316.eurprd03.prod.outlook.com (2603:10a6:20b:507::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.16; Tue, 3 Dec 2024 19:30:15 +0000 Received: from GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e%7]) with mapi id 15.20.8207.017; Tue, 3 Dec 2024 19:30: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: 07679e40-b1ad-11ef-a0d3-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Je1CFuVHxhgVtZwLgQcqxk8wxxwuPv7uuMbQGQH56KDcmkrdc7H7SgSUECAGMVcgRfTlDFRNm0PbxDHw10vCUlqpCMpH5BGodRPxFsmaoTIosYgUVtGcawfHIM/0p4E4nTmGu+P1WQFhC4Z1HXX6IGf1fWSavEYt4BcdJ8Lj2JSpgYc64P1Fc3QBp6TaiT1TdK0YBqMRCb6WWP0tu1ZYZI7lbTSfDU+RYEngMjydrpoKIJh7oviR5sZWqVWno2Y5KaRfU194Vyt0pblg0XeQhTv2tCRqUynQsr1r56LcjW1zFdMdb+56TFce+jcrbFh60jbfSpoL/E2oU/Nibp0XBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dYIY7CAKecYg8EqSgltMDeirxnVgSPqchNxbYLyRC9U=; b=uK3biCUganniBB5BhACXLF0/sW4tPYg3llmesQDfphVf0/K0w1y+r39OT1DOj6bcQ37eLBd/3XPWgx8P9Hdsl/pK1t8VeHgW6cQcpXETk/s3bExwTMHkMQ8gy65iQzsJglh0P2JfnzMScncD57lqtVVGA2dgfsmfmr1UHMqgBkLKY/SVTzgQjvyiDB6mt0R2wQN+FbBpu/AwQkbyuA4xZZRx/xKBnEuO7cnY3rV6tsv4UwL2djZhXQKUQnxKc9H+XTKtdpyKNQzspzSADvov7tR7HrsQZMKGB6gYx7xWcn4RqjeWUhVeeLXL3jC2KX5LOeY1mPCcP1zzmF9yO7uamQ== 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=dYIY7CAKecYg8EqSgltMDeirxnVgSPqchNxbYLyRC9U=; b=W0BmRJGkveOHE4IXJMfP+Is2yRP8s617Y29sULP4A+lPGpwmWQOMiBm3m5MkKFdkY5wIr8FvmKigauHHX8aD7mWh25Js7tlwpOhXsPjOtlMzckK1QDNkVaDcgy9py1F7z6+2C5TVXNz5WN28N05IIQfPuGnjUgBmn3cX/nxjuddqEojHvo3piX35Wark0t9OIQ1vBx77ZP19W+OK4o2yoyfoP1a/OggPKg/niqyW45x5B1b/msRch8+ZUDkIdQ0ac8aQs+8zvVF+sFBJoXiRRyGl0cvZ1KgtE/8CbphNxKmea/mnBxSjRhkL8D6grIQ047EjNBr307diyrNGs4vwbg== From: Volodymyr Babchuk To: "oleksii.kurochko@gmail.com" CC: Jan Beulich , Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , Julien Grall , Stefano Stabellini , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v2 4/4] xen: riscv: enable stack protector feature Thread-Topic: [PATCH v2 4/4] xen: riscv: enable stack protector feature Thread-Index: AQHbQsSdrqhVO8R3/0W5bnSX25z8yw== Date: Tue, 3 Dec 2024 19:30:15 +0000 Message-ID: <87ttbk4la1.fsf@epam.com> References: <20241130010954.36057-1-volodymyr_babchuk@epam.com> <20241130010954.36057-5-volodymyr_babchuk@epam.com> <2f92aeb0-bb1f-49d0-9655-8ff93fee8837@suse.com> In-Reply-To: (oleksii kurochko's message of "Mon, 02 Dec 2024 10:56:04 +0100") 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: GV1PR03MB10456:EE_|AS4PR03MB8316:EE_ x-ms-office365-filtering-correlation-id: 86c32cfd-f2eb-4aa7-853b-08dd13d0ea0d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|7053199007|38070700018; x-microsoft-antispam-message-info: =?utf-8?B?ejZaVy9WR3h0VXZ1YVhQRCtsWFF6Y0w5VFlEbGYzcVYwQk90aXhrclBISFZo?= =?utf-8?B?U1oxQmZxSW5uWlhKeEtPQWlISFVJODRjNWxJemxqdXVLYVA1dml4N3R2SFU5?= =?utf-8?B?dnN2aG00TG05UmVDWE04MVE1Y1IrbjVCcmtoelI5NlpvWll3OFF5MmhxV2Nn?= =?utf-8?B?enEzd0QrS1Y3Q0hLMTdkeGRlWk9mUEhrOFpBbFMrU3J0UDBmN2FCVXljRER4?= =?utf-8?B?VG1qaHorMkluV3hsZjhxR0paK3ltZ05SVG16TktUTjhCbnJLOFI2NTI5a2hv?= =?utf-8?B?dlFPa2Qyc1ZDa0NERWJTY2xWUHUwZmpzZWk0YkhTcjRjbEdWK2lKeHhoQktn?= =?utf-8?B?a0VwbGZMNEZyYStDUE04K3RzQkNtNmdHdnlndVp5WEErNDFRRllydjkvTjlM?= =?utf-8?B?Si9Za1U0ZE9qekhZUWlra1Q3VmM1OVBkWXJaQSsyL2hBMVdXNU1XTFJiODgx?= =?utf-8?B?NGswelByekRHVDZ5NStsSDZvNzhIWXEzSk56UkpwbkJ5bnIxM2ZlRWpXaEJ3?= =?utf-8?B?bS9XeHZ1YlcrRURBZ1lxcG5SK3pLSzNhaFZYdnlZYjVGU1M4RExKOXZsa2pR?= =?utf-8?B?Y2Y1Vm1jbHQ4TjIzNlpsRVRaQUxQcnBXOTkxOGNUZzZnbVBkTmdPeHdZbm5j?= =?utf-8?B?N1l6dmxsQi9IeG91RkdJNlpDc2tQdmdCR3R1Y2h2QmdzMGdObitGaHJ0djRE?= =?utf-8?B?TFVlL21CK0JpdkNyNFNJT1lLUk1KY2xUdHhRM09WSVhLLzM5YlhHZjNsNTJv?= =?utf-8?B?WkhMUEVaeklwcGFuTUx6MVJzRG0vUWliT1BWS1NxQ1Nra1dIZlJTclUwbzRk?= =?utf-8?B?dDM3eWZ3VjFWcFV3YTRiUlFjQStpVU1TTldQdm5OUnJJVHhVMWV2bmkrK0s3?= =?utf-8?B?ZUk4OWhJMmp5MEoxcTVpbGYwT09PT1p2UWlRcVZHcWczdEQ0Sk5JbDN3Ump1?= =?utf-8?B?SWc3cDU4MkdOSDk1SnRQZHpSaktrUU5JeTJHN3B4T3hiS3BINkYrSGVUS2g3?= =?utf-8?B?S3hsR1JhUEExT2N3ZGQ3bzdsTjFnazM0ZzRQU3FZYk5XOUh0TXh1L1BQUXI0?= =?utf-8?B?ZEFFYnA0M2d5bVhhTlEvaHdCTUUxdTJvWTN3eUR6c29kN0RabEFJb2NwRjFp?= =?utf-8?B?R1pjZC8rR2ZFa3MyRFZQazFRRzRJbHlqTGdWQnZNcmlFbXBVaXRXOTJsZXB1?= =?utf-8?B?RmpibEY4Z2w5aHZqU2dHN09RNU84YzE3SVUzV0JLOXpxL0pCWXRTa0RYM1FB?= =?utf-8?B?Snp1RTMrR1gxV2VldWozQkFMM0REMTBVOXd6Y3BPcEh1OXovRHpma1ZaaHYw?= =?utf-8?B?dHpkeW9kNHU3Z211d3BVSE9mMWtxU2xlQ3dwdGhLSzVFQ2RORnF0OEZUUUxh?= =?utf-8?B?dW1hVzB5QVNGTkd1V0NIazJ1T2ZvVWxjOU1CSjFzRGQ1SCs3amtaOFgwNFc2?= =?utf-8?B?clQxeHhNYzUzdjBPZnRrQ04rK1hMekM0cXIyYWpTZFJXaGtCNnd4Qi90OWpp?= =?utf-8?B?QXNWeDhzM2tDWjM2S2hnTjkvd3oxbVI4bVorZmV0U1dDa2lZNS91dnVkdmFs?= =?utf-8?B?czIwUnJIL1FnZXE2QW1IWXMrQ1gxZWx6a1J0N3NnbGZ2NmUwdGx2emd2VnRt?= =?utf-8?B?MmVydllwTElXVzRNaDJjN2FGMWVPNlN3QitDNWk4ZTRmRkViNVBtVDZDU2dh?= =?utf-8?B?YVF4ZlNOU2p6MEZ2TXk3VmRoNjNiYW9MZWh3VUJWeFVPcGxOY3lBY1Nwb1Fq?= =?utf-8?B?UEpQVTAwWWxBVmxlVkpMVjRhcUc5NzhxeUpPRUYxRUt4cFdvUGlVR1NPZjkx?= =?utf-8?Q?W4aGtpIzvb6hf8FzULTla22wNEMXMAipJ/TXM=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cmJOelZKWmZHMko5SW9DaUt3Y2g1MWxDaFFCUWNyK3h0aldtYXlTTVlZVEJa?= =?utf-8?B?REZVenhwUW5HZDhCdFgxd08ycU1md0J4MWtqaEt1OVZEWGZxNmtJeGtmOHlI?= =?utf-8?B?SGVSd0FPMjRQcXBvWXlvWXNUdzdGcmQrakhtZlY2UlhxOTh5QkEyNFJXUDg2?= =?utf-8?B?emUwbHVNVVQ3VDFDOU96MHVSN0poN0NxMlNGaTRua043YnZlRi81Y28vZ1Ni?= =?utf-8?B?RkU1TVhsRkd0N2tJVVlrOHBRM29mUHVzckZpa0JtNUVQZHZwSlVqNTh2OStP?= =?utf-8?B?WjU0Y1lPZkxDbU1FZEgzZU5RZ0xDcWRIc01EbitUWWJ1NGFxYUg5MTZtTCs5?= =?utf-8?B?ZlgvT3JJcHcvNTNPK0wvZGU3aWVVRHhpdlNLcXluZytnNFpjUktKQWY4RTZ0?= =?utf-8?B?T1RFVThpTytMV21raWI0K3VoMktyY2FLZUJmQWM2aldaSVVvQ1prcnJxWCtz?= =?utf-8?B?aTVGck5tbXM1UjY5VXVTdDErSFlWU3ZHOHh6Y0d6Q3VrUUthRGVMMk5CblJ1?= =?utf-8?B?cDJEWTAxV21oTzNEaTYxUDJFRlRHS2FBTDJ5MSs5RWVTQ0JWVnpsc25zTU1S?= =?utf-8?B?T2dXS3NGVGQwVVF5Uno5Y01FOHVpRVZsUTFvQzJ3OUFLbmdzM1VGdG5DVE93?= =?utf-8?B?NmRSUVgvL2kzOTlVdStncVdsc29vT1YzTWorRktMNlovTEQ5YkZPMmxVZWNn?= =?utf-8?B?QmxuczNNcEdqd0FwY2liblJIWmF1dWhndExZVXZzdlRHVHZWbER0cGNtdXoz?= =?utf-8?B?VFY0RXZvUFovQ09mN3pkS1Y0eWN6aCtlL3NsUEdnK1M4bmIvSW5ESnNMaFdO?= =?utf-8?B?MTlwQld0aGM4ZVJxdlpwTHdHa2NyZktMcHc4dWl6UllIaDVYRTRFRG5pcHBl?= =?utf-8?B?b2pIbVY3RmplcWhSdEJmVDdTV3M4UnhVZmtoNy96aFRic2t4bDU4dzVhSXBj?= =?utf-8?B?M0M4ZWljMzlsdmw3MFluYnNtK2JSVkgraXlZRXNmQ005TkJWOFBzRlhNQ1cx?= =?utf-8?B?VHZhOStXRGtpczJKNENobS9zU1NkbGlXckE0dStYVnFaK1ZIZlVUMWZvdndL?= =?utf-8?B?Kzl0bVpEUHR2UzFGc3BWN1FHVTEvc283WWlJbVh4VTY4QTAwbUhYYXduZDBj?= =?utf-8?B?VDJ1RmVBdkFtVklXWlFXWk9tMzZEeWFCeGFzR2cyWHRvN3JacUFxWmRvWXhj?= =?utf-8?B?NnFjRTBGdzlPdi9hblFxUUtRKzJpbFFJRTdIa2Z1bWNqNVkrcW03cTB4UTRv?= =?utf-8?B?Z3V4MVo1ZjU4SXcyM1FtWVUxdkNtMFFDQ1lCNXVNZFhneGVyVkg0UFg4UnJz?= =?utf-8?B?MVYwMmQ2U1V5U1drNDh4RTBNQ2R0VDRQRmxzZTRrVlpDa2Rqc2F0c04wYlNh?= =?utf-8?B?aStKVGYxRGhjYjF4WTBDN1BmWUdEME50QzhPNG84dXdjSnVHYmpvcHZta1V3?= =?utf-8?B?U3pGdGNwRFZ4aHVvNU9WemtwM0xWWTIyNTZvbjNJZ211Y3N3MDIwZmNkekkz?= =?utf-8?B?MWhHMlIxSm5EYUw3NERCVklNSWt3N3BFSjV2YzhiZ3R0dWE3TWNnSkE0UC9M?= =?utf-8?B?ZWNmV1B5WWljcG44MTF3anpPWlVHRzd1b3p0cTlxWktmQnU5eW5HSGtZK2Ji?= =?utf-8?B?a2crVTZ5MXVONlNxMmFjb1lZeWRpUzZLWU5mMUhqdVl5YWxNVG56MWdFakUy?= =?utf-8?B?dUVmY1ZmSDdsNDdjTXJWc2cwTWtnbW01Wm9XWUtnVkRzL3hXc1RmN21HTGVQ?= =?utf-8?B?NHBoWE1DZ0dDZUhjT3l3TktJOENJUmdCYlNPVENicjVhMnF1YTJrZ1FzaFlu?= =?utf-8?B?WS9TMXBDeEhMRjk4SjVvQmgxRGM0VmI0T3dpWlM0VU5Pck41SUNBSElHdXJ2?= =?utf-8?B?SjdJUFhHc01CMmc5bFV3MkRxOXJVWVVUM3M1L2ZDZkhmbU4vNFVZVlZyQVJO?= =?utf-8?B?QzViNlNNOUxwb294SDFuQmtQUGhHVGdKRjZQdkh4VGR2RHRHKzl6TURjSS9G?= =?utf-8?B?OVM3V3dDaW1ZZ3lYQjAwQzFDM0d3V2N1T1pXekNvemxsSUlJd3FVS3NPR29j?= =?utf-8?B?Y2VhYXRXbUhQNWpPOUJzMVQrSTJsbjdFYi9pVUJ0aXlQY0wrK2huQ1E3Y0Za?= =?utf-8?B?NE1kcnFsTzB1dUVRdmZtVFFVZjF0SUJoc0U0TzIwWW9EbFg4K1RyMGJQU3lZ?= =?utf-8?B?Zmc9PQ==?= Content-Type: text/plain; charset="utf-8" Content-ID: <862A02E5D708A44EA838148B91DF3A2F@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: GV1PR03MB10456.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 86c32cfd-f2eb-4aa7-853b-08dd13d0ea0d X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2024 19:30:15.6960 (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: Zr39oqUmmaKNIbhca3xAebPwhs/oQfeqb/EjdVpYyVaO/aztD7/JSWYwYasqbaqokKkIxzOaad6SNcs09Kh/LkC4T8twTIR3M9tXYrEjJJI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR03MB8316 DQpIZWxsbyBPbGVrc2lpLA0KDQoNCm9sZWtzaWkua3Vyb2Noa29AZ21haWwuY29tIHdyaXRlczoN Cg0KPiBPbiBNb24sIDIwMjQtMTItMDIgYXQgMDk6MTIgKzAxMDAsIEphbiBCZXVsaWNoIHdyb3Rl Og0KPj4gT24gMzAuMTEuMjAyNCAwMjoxMCwgVm9sb2R5bXlyIEJhYmNodWsgd3JvdGU6DQo+PiA+ IEVuYWJsZSBwcmV2aW91c2x5IGFkZGVkIENPTkZJR19TVEFDS19QUk9URUNUT1IgZmVhdHVyZSBm b3IgUklTQy1WDQo+PiA+IHBsYXRmb3JtLiBIZXJlIHdlIGNhbiBjYWxsIGJvb3Rfc3RhY2tfY2hr X2d1YXJkX3NldHVwKCkgaW4NCj4+ID4gc3RhcnRfeGVuKCkNCj4+ID4gZnVuY3Rpb24sIGJlY2F1 c2UgaXQgbmV2ZXIgcmV0dXJucywgc28gc3RhY2sgcHJvdGVjdG9yIGNvZGUgd2lsbA0KPj4gPiBu b3QNCj4+ID4gYmUgdHJpZ2dlcmVkIGJlY2F1c2Ugb2YgY2hhbmdlZCBjYW5hcnkuDQo+PiA+DQo+ PiA+IFNpZ25lZC1vZmYtYnk6IFZvbG9keW15ciBCYWJjaHVrIDx2b2xvZHlteXJfYmFiY2h1a0Bl cGFtLmNvbT4NCj4+ID4gVGVzdGVkLWJ5OiBPbGVrc2lpIEt1cm9jaGtvIDxvbGVrc2lpLmt1cm9j aGtvQGdtYWlsLmNvbT4NCj4+DQo+PiBJc24ndCB0aGlzIHByZW1hdHVyZT8gRm9yIC4uLg0KPj4N Cj4+ID4gQEAgLTU3LDYgKzU4LDggQEAgdm9pZCBfX2luaXQgbm9yZXR1cm4gc3RhcnRfeGVuKHVu c2lnbmVkIGxvbmcNCj4+ID4gYm9vdGNwdV9pZCwNCj4+ID4gICAgICBpZiAoICFib290X2ZkdF9p bmZvKGRldmljZV90cmVlX2ZsYXR0ZW5lZCwgZHRiX2FkZHIpICkNCj4+ID4gICAgICAgICAgQlVH KCk7DQo+PiA+DQo+PiA+ICsgICAgYm9vdF9zdGFja19jaGtfZ3VhcmRfc2V0dXAoKTsNCj4+DQo+ PiAuLi4gdGhpcyBmdW5jdGlvbidzIHVzZSBvZiBnZXRfcmFuZG9tKCksIGVpdGhlciBhcmNoX2dl dF9yYW5kb20oKQ0KPj4gbmVlZHMNCj4+IHRvIGJlIGltcGxlbWVudGVkLCBvciAoYXMgSnVsaWVu IGFsc28gcG9pbnRlZCBvdXQgZm9yIEFybTY0KSBOT1coKQ0KPj4gbmVlZHMNCj4+IHRvIHdvcmsu IFlldCBnZXRfc190aW1lKCkgcHJlc2VudGx5IGV4cGFuZHMgdG8ganVzdCBCVUdfT04oKS4gR2l2 ZW4NCj4+IHRoaXMNCj4+IGl0J3Mgbm90IGV2ZW4gY2xlYXIgdG8gbWUgaG93IE9sZWtzaWkgbWFu YWdlZCB0byBhY3R1YWxseSB0ZXN0IHRoaXMuDQo+IE9rYXksIEkgdGhpbmsgSSBmb3VuZCB3aGF0 IGlzIHRoZSBwcm9ibGVtIGFuZCB3aHkgbXkgdGVzdGluZyBvbiBzdGFnaW5nDQo+IHdhc24ndCBy ZWFsbHkgY29ycmVjdC4NCj4NCj4gSW4geGVuL2luY2x1ZGUveGVuL3N0YWNrX3Byb3RlY3Rvci5o ICgNCj4gaHR0cHM6Ly9wYXRjaGV3Lm9yZy9YZW4vMjAyNDExMzAwMTA5NTQuMzYwNTctMS12b2xv ZHlteXIuXzVGYmFiY2h1a0BlcGFtLmNvbS8yMDI0MTEzMDAxMDk1NC4zNjA1Ny0zLXZvbG9keW15 ci5fNUZiYWJjaHVrQGVwYW0uY29tLw0KPiApIENPTkZJR19TVEFDS1BST1RFQ1RPUiBpcyB1c2Vk IGZvciBpZmRlZi1pbmcgc28gdGhlIHN0dWIgdmVyc2lvbiBvZg0KPiBib290X3N0YWNrX2Noa19n dWFyZF9zZXR1cCgpIGlzIHVzZWQgYW5kIHRoZXJlIGlzIG5vIG5lZWQgZm9yDQo+IGdldF9yYW5k b20oKSBpbXBsZW1lbnRhdGlvbjoNCj4gMS4gU2hvdWxkbid0IGl0IGJlIC9zL0NPTkZJR19TVEFD S1BST1RFQ1RPUi9DT05GSUdfU1RBQ0tfUFJPVEVDVE9SID8NCj4gMi4gQ09ORklHX1NUQUNLX1BS T1RFQ1RPUiBpc24ndCBzZXQgaW4gY2FzZSBvZiBSSVNDLVYsIGF0IGxlYXN0Og0KPiAgICAgICBn cmVwIC1SbmkgIlNUQUNLX1BST1RFQ1RPUiIgeGVuLy5jb25maWcNCj4gICAgICAgMzg6Q09ORklH X0hBU19TVEFDS19QUk9URUNUT1I9eQ0KPiAgICAgICA3NjojIENPTkZJR19TVEFDS19QUk9URUNU T1IgaXMgbm90IHNldA0KPg0KPiAgICBTaG91bGRuJ3QgaXQgYmUgZGVmYXVsdCBIQVNfU1RBQ0tf UFJPVEVDVE9SICggb3Igc29tZXRoaW5nIHNpbWlsYXIgKQ0KPiAgICBmb3IgJ2NvbmZpZyBTVEFD S19QUk9URUNUT1InOg0KPiAgICAgICBkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9LY29uZmlnIGIv eGVuL2NvbW1vbi9LY29uZmlnDQo+ICAgICAgIGluZGV4IDBmZmQ4MjU1MTAuLmYzMTU2ZGJiOWEg MTAwNjQ0DQo+ICAgICAgIC0tLSBhL3hlbi9jb21tb24vS2NvbmZpZw0KPiAgICAgICArKysgYi94 ZW4vY29tbW9uL0tjb25maWcNCj4gICAgICAgQEAgLTUyMSw2ICs1MjEsNyBAQCBjb25maWcgVFJB Q0VCVUZGRVINCj4NCj4gICAgICAgIGNvbmZpZyBTVEFDS19QUk9URUNUT1INCj4gICAgICAgICAg ICAgICBib29sICJTdGFjayBwcm90ZWN0aW9uIg0KPiAgICAgICArICAgICAgIGRlZmF1bHQgSEFT X1NUQUNLX1BST1RFQ1RPUg0KPiAgICAgICAgICAgICAgIGRlcGVuZHMgb24gSEFTX1NUQUNLX1BS T1RFQ1RPUg0KPiAgICAgICAgICAgICAgIGhlbHANCj4gICAgICAgICAgICAgICAgIFVzZSBjb21w aWxlcidzIG9wdGlvbiAtZnN0YWNrLXByb3RlY3RvciAoc3VwcG9ydGVkIGJvdGggYnkNCj4gICAg ICAgR0NDDQo+DQo+IFdpdGggdGhlc2UgY2hhbmdlcywgSSBjYW4gY29uZmlybSBKYW4ncyBzdGF0 ZW1lbnQgdGhhdCB0aGUgQlVHX09OKCkNCj4gb2NjdXJzIGR1ZSB0byB0aGUgYWJzZW5jZSBvZiB0 aGUgZ2V0X3JhbmRvbSgpL05PVygpIGltcGxlbWVudGF0aW9uLg0KPg0KPiBNeSBzZWNvbmQgdGVz dCAob24gbXkgZG93bnN0cmVhbSBicmFuY2gpIHdhc24ndCByZWxldmFudCBiZWNhdXNlDQo+IGdl dF9zX3RpbWUoKSBhbmQgTk9XKCkgYXJlIGltcGxlbWVudGVkIHRoZXJlLg0KPg0KPg0KPiBBc2lk ZSBmcm9tIHRoZSBjaGFuZ2VzIEkgbWVudGlvbmVkIGFib3ZlLCBJIGNhbiByZS1zZW5kIHRoaXMg cGF0Y2ggd2hlbg0KPiBJIHN1Ym1pdCB0aGUgcGF0Y2ggZW5hYmxpbmcgZ2V0X3NfdGltZSgpIGFu ZCBOT1coKSBmb3IgUklTQy1WLiBJZiB5b3UsDQo+IFZvbG9keW15ciwgYXJlIG9rYXkgd2l0aCB0 aGF0LCB3ZSBjYW4gcHJvY2VlZCBpbiB0aGlzIHdheS4NCg0KVGhhbmsgeW91IGZvciB0ZXN0aW5n IHRoaXMgb25jZSBtb3JlLiBJJ2xsIGRyb3AgdGhpcyBwYXRjaCBmcm9tIHYzIHRoZW4sIHNvDQp5 b3UnbGwgYmUgYWJsZSB0byBpbmNsdWRlIGl0IGludG8geW91ciBzZXJpZXMuDQoNCi0tDQpXQlIs IFZvbG9keW15cg0K From xen-devel-bounces@lists.xenproject.org Tue Dec 03 20:33:30 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 20:33:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848173.1263138 (Exim 4.92) (envelope-from ) id 1tIZa5-0000YV-RT; Tue, 03 Dec 2024 20:33:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848173.1263138; Tue, 03 Dec 2024 20:33:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIZa5-0000YO-OW; Tue, 03 Dec 2024 20:33:13 +0000 Received: by outflank-mailman (input) for mailman id 848173; Tue, 03 Dec 2024 20:33: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 1tIZa4-0000Xy-C6 for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 20:33:12 +0000 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [2a00:1450:4864:20::62f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ce9b80df-b1b5-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 21:33:08 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-aa5302a0901so717119166b.0 for ; Tue, 03 Dec 2024 12:33:08 -0800 (PST) Received: from [192.168.86.29] ([90.240.255.120]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5996c1408sm647537166b.15.2024.12.03.12.33.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Dec 2024 12:33: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: ce9b80df-b1b5-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1733257988; x=1733862788; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=jxR1FGK3+feziYsHaMop3zcgA6TxQT/HkAiZ2onL1zU=; b=tw6AXjcoSToWjK7Q8912/17E+JG6jJ4q7L9ZsIOBi3M8ITH+fDQ6U7m+95dWBqQATl +nT1uREMTB7YrBdcCxln2k+GC26x7KhDxEB8D4uQMeljsDSNun0hLdNZmiBxz1gGo8XG su/vlTkcpFCqnkXK49wBGchanNzyqji5KQrvA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733257988; x=1733862788; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jxR1FGK3+feziYsHaMop3zcgA6TxQT/HkAiZ2onL1zU=; b=sYOe2FyEQm3Gnyb2IFfCtPiomKqTVvOMnOKRTTaztXR4o+az6cLcyA2VoQqV9LI2o8 yDwo9S9MaA4y8FCdagFX7tq4UUDVSxqr/rtxhJXoiqzu0LinnNCN8sbfMVKwwQcwRmQk snOypnZeqQTRZ3jRuIKFBjFhVWYz3+DS63y4IlFUOx5Ya9coozvldgm5W1HYqG8dq54C Ug3cnkW/n399gwsLXKLfHDm1xTOH+Ve+NvHJWslRT+3yzVbpvQXTQxqu/u62o2PKBIGe shTtp29w1p8ig/1LBKNcf3PNRL2hExaQ1bSgcrGOZqD1Pa4kRZpf9dD7PNNm9h33HaNJ Pgzw== X-Forwarded-Encrypted: i=1; AJvYcCXYDIPamTDm43AWE8M4gHNtQiAytNxswM1KZJwfcjPKCyQp0Pd32RDp2Xz1tmgbpYC1Roj2jf5Ucqo=@lists.xenproject.org X-Gm-Message-State: AOJu0YwsdLizK8q3D59216KuuHgtHPGLM2h7obqb0+6XJGqbqBtYUvlU qsvPetB8TpnLH3jqm0AJA3jxa/7t0C3+xxnJjI4GZ+yJVyX0NaI6UOvBoNzRr2s= X-Gm-Gg: ASbGncvtvuyhQMs+fOS1TVmiK49Xr5doMxQNrs2yBEsZZMFXPUPXzNd9sJDkptb7Ewf 551HKLd7WzVM+2ToiSHKPLJ6RpZZiw3QKaUWCvmBWgXV6LXlWd+DrZxa26VNcyPUWckMb1Okn/z 9ycuaJA34nYpWEMBk6h/froVMAWOC653Gs63gGvxnNA06zvBgI+zq5bZDi1UY4sLOmtANx0iHTo QHo+WN4QtoaEGRsnhLZcCtZ4BHo4MIZmfnmlGSME7VZq4IdcFY8ev1S7SDuo/U= X-Google-Smtp-Source: AGHT+IHGm69XCRGYjxrmkM/uPXIWlpw2vZDkUeUkv3bXslpMX9FgB69SqvM4F0VgdeQCBgnUB/ldVQ== X-Received: by 2002:a17:907:762d:b0:aa5:1d33:dc10 with SMTP id a640c23a62f3a-aa5f7f0b58bmr271443466b.45.1733257988101; Tue, 03 Dec 2024 12:33:08 -0800 (PST) Message-ID: <4f2f949b-a53e-4a79-8084-d374cabc109e@citrix.com> Date: Tue, 3 Dec 2024 20:33:07 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Andrew Cooper Subject: Re: [PATCH v2 2/4] xen: common: add ability to enable stack protector To: Volodymyr Babchuk , "xen-devel@lists.xenproject.org" Cc: Jan Beulich , Julien Grall , Stefano Stabellini References: <20241130010954.36057-1-volodymyr_babchuk@epam.com> <20241130010954.36057-3-volodymyr_babchuk@epam.com> Content-Language: en-GB Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20241130010954.36057-3-volodymyr_babchuk@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 30/11/2024 1:10 am, Volodymyr Babchuk wrote: > diff --git a/xen/common/Kconfig b/xen/common/Kconfig > index 90268d9249..64fd04f805 100644 > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -213,6 +216,20 @@ config SPECULATIVE_HARDEN_LOCK > > endmenu > > +menu "Compiler options" > + > +config STACK_PROTECTOR > + bool "Stack protection" Call this "Stack Protector".  There is no point deviating from the name most people know. > + depends on HAS_STACK_PROTECTOR > + help > + Use compiler's option -fstack-protector (supported both by GCC > + and Clang) to generate code that checks for corrupted stack > + and halts the system in case of any problems. > + > + Please note that this option will impair performance. This final sentence isn't interesting.  All hardening options come with a cost, and stack protector is small compared to some we have in Xen.  Furthermore, the audience you need to write for is the curious power user, not a developer. How about this: "Enable the Stack Protector compiler hardening option.  This inserts a canary value in the stack frame of functions, and performs an integrity check on exit." > diff --git a/xen/common/stack-protector.c b/xen/common/stack-protector.c > new file mode 100644 > index 0000000000..b258590d3a > --- /dev/null > +++ b/xen/common/stack-protector.c > @@ -0,0 +1,10 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +#include > +#include > + > +unsigned long __ro_after_init __stack_chk_guard; > + > +void __stack_chk_fail(void) asmlinkage.  This MISRA check is now blocking in Eclair. > +{ > + panic("Detected stack corruption\n"); At a bare minimum, "Stack Protector integrity violation identified in %ps\n", __builtin_return_address(0) It's a little awkward because ending up here means a sibling call from the same function ended up corrupting the stack, but there's no way of tracking down which. > +} > diff --git a/xen/include/xen/stack-protector.h b/xen/include/xen/stack-protector.h > new file mode 100644 > index 0000000000..779d7cf9ec > --- /dev/null > +++ b/xen/include/xen/stack-protector.h > @@ -0,0 +1,29 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#ifndef XEN__STACK_PROTECTOR_H > +#define XEN__STACK_PROTECTOR_H > + > +#ifdef CONFIG_STACKPROTECTOR This is the header needing to include random.h, or it won't compile in isolation. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Dec 03 22:00:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 22:00:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848185.1263148 (Exim 4.92) (envelope-from ) id 1tIawl-0002Ic-Uf; Tue, 03 Dec 2024 22:00:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848185.1263148; Tue, 03 Dec 2024 22:00: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 1tIawl-0002IV-S2; Tue, 03 Dec 2024 22:00:43 +0000 Received: by outflank-mailman (input) for mailman id 848185; Tue, 03 Dec 2024 22:00: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 1tIawk-0002IN-D3 for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 22:00:42 +0000 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [2a00:1450:4864:20::633]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 08cac5d8-b1c2-11ef-a0d4-8be0dac302b0; Tue, 03 Dec 2024 23:00:40 +0100 (CET) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-aa549d9dffdso969806966b.2 for ; Tue, 03 Dec 2024 14:00:40 -0800 (PST) Received: from [192.168.86.29] ([90.240.255.120]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5998e6dc3sm664840866b.121.2024.12.03.14.00.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Dec 2024 14:00: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: 08cac5d8-b1c2-11ef-a0d4-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1733263240; x=1733868040; 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=zEV4uiUrM+twfEXjtF1CX6yDxxHdTHowV4QnSlnrfow=; b=kakyK3ZGWfXJ+2UD64a5CEDzzFWfE+ms3ZVfYLaAexb8MKoIEHCXbHEGhzC5HQfd3b 3OKdQzefNFv5VUVubilyHPuKzSFOyA+QFCQtUjAFiX7Tmk31ndSWiIBvqABstQb5aWek 0rxL1p9+XQfFtm3sV8gp2/DiGCwiflJC5+v78= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733263240; x=1733868040; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zEV4uiUrM+twfEXjtF1CX6yDxxHdTHowV4QnSlnrfow=; b=U9+Jf90Lzqc0umdIM+CM/EjtzmuDnAufKnj3c5YccqsL+7ATGVuZsOA9Ue45enwbMf Oz1rPDC9pLSFfDObp1V32jwZUSbctOxlDRvmvQRevoyJakKfCDhrMIsLZg5fP5M/wEEY HRkyyaloBDrYYkexVjQTnUu/czRUt6XAeDDTJ0D0lnbWaQSWRotRo0aUhC9CwQSj/sOx 0ZxLjwvorE9WjeMFZnorSJiam0cAXE7z8oLCryQmF16fuNb+z53MbRBaWUJqPih306Qx LCCS99wG56nWxiG4v5xVlgLVP8XkN6y9XxCRCBajYgX9a4+JopSrtt5QR+RmxslySd4c qRwA== X-Forwarded-Encrypted: i=1; AJvYcCWjUaG1nCQha5fldiLoFvbnrAcaSUsAbnBRGY1X2NSM69Ag3K9GHE1TvMFqOhLTatJ0mg/EBjGA0WY=@lists.xenproject.org X-Gm-Message-State: AOJu0YxeV3J2SHe7bdSVLILVONhW1AoVAhrT3qlspsFmL8VK9z9OIInS QC42yPHn/9FDy3bBLuEjwZto7BvT7XmLRuB67qqLwFkScUKdkBY+UStg/A1kTFI= X-Gm-Gg: ASbGncvE2JfEURIzD3n49ma/tcIYf1QJKSR4pEDDMoPrr2WFA0KV7G0jArFNFDPNxTy 9tWbDI8akn3j8Ok1mgCfJvAaPojq+bD/FE6/CUfqWO4NYj4MFsW9qDIJTEjn3Y7L/5tUiHUrUjy Vv9m89z8UjQq0BqEvCqEc2ERnAhZ+bi5f++BshkIqCBcciIr9u4b11nyHsovT4tDx/dZ3Y2ZOJ9 QDBKgZSFMGQI1Eu3es6kkfuJsa3eDEkqvZqSvoktc4CXbciUw4S8dc1oCjprXg= X-Google-Smtp-Source: AGHT+IHhd1TzoPjJc/oQSobQ7ZdvMuWxnxMujckyKXRHGg+bDQgCezKiTjkWNCCOABtTLCiohc6p+w== X-Received: by 2002:a17:906:cc2:b0:a9a:ad8:fc56 with SMTP id a640c23a62f3a-aa5f7f006d8mr299435566b.44.1733263239629; Tue, 03 Dec 2024 14:00:39 -0800 (PST) Message-ID: Date: Tue, 3 Dec 2024 22:00:38 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/4] xen: arm: enable stack protector feature To: Volodymyr Babchuk , "xen-devel@lists.xenproject.org" Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel References: <20241130010954.36057-1-volodymyr_babchuk@epam.com> <20241130010954.36057-4-volodymyr_babchuk@epam.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20241130010954.36057-4-volodymyr_babchuk@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 30/11/2024 1:10 am, Volodymyr Babchuk wrote: > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c > index 2e27af4560..f855e97e25 100644 > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -341,6 +342,8 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr) > */ > system_state = SYS_STATE_boot; > > + boot_stack_chk_guard_setup(); > + > if ( acpi_disabled ) > { > printk("Booting using Device Tree\n"); I still think that __stack_chk_guard wants setting up in ASM before entering C. The only reason this call is so late is because Xen's get_random() sequence is less than helpful.  That wants rewriting somewhat, but maybe now isn't the best time. Even if you initialise __stack_chk_guard it to -1 rather than 0, it's still got a better chance of catching errors during very early boot; the instrumentation is present, but is using 0 as the canary value. On x86, dumping the current TSC value into __stack_chk_guard would be far better than using -1.  Even if it skewed to a lower number, it's unpredictable and not going to reoccur by accident during a stack overrun. Surely ARM has something similar it could use? [edit] Yes, get_cycles(), which every architecture seems to have.  In fact, swapping get_random() from NOW() to get_cycles() would be good enough to get it usable from early assembly. ~Andrew A better option for get_random() would be to use a proven PRNG (e.g. one of the xorshift family), seeded with get_cycles() and then re-seeded with a real RDRAND/etc instruction if such a capability is found to exist on the hardware. From xen-devel-bounces@lists.xenproject.org Tue Dec 03 22:06:52 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 22:06:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848196.1263158 (Exim 4.92) (envelope-from ) id 1tIb2d-0002ub-L6; Tue, 03 Dec 2024 22:06:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848196.1263158; Tue, 03 Dec 2024 22:06: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 1tIb2d-0002uU-HN; Tue, 03 Dec 2024 22:06:47 +0000 Received: by outflank-mailman (input) for mailman id 848196; Tue, 03 Dec 2024 22:06: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 1tIb2b-0002uO-Pr for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 22:06:45 +0000 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2061c.outbound.protection.outlook.com [2a01:111:f403:2414::61c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e085c2d3-b1c2-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 23:06:43 +0100 (CET) Received: from PH7P221CA0037.NAMP221.PROD.OUTLOOK.COM (2603:10b6:510:33c::9) by PH0PR12MB7472.namprd12.prod.outlook.com (2603:10b6:510:1e9::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 22:06:37 +0000 Received: from MWH0EPF000A6733.namprd04.prod.outlook.com (2603:10b6:510:33c:cafe::a1) by PH7P221CA0037.outlook.office365.com (2603:10b6:510:33c::9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.18 via Frontend Transport; Tue, 3 Dec 2024 22:06:37 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by MWH0EPF000A6733.mail.protection.outlook.com (10.167.249.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 22:06:36 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 3 Dec 2024 16:06:35 -0600 Received: from amd-BIRMANPLUS.mshome.net (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Tue, 3 Dec 2024 16:06:35 -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: e085c2d3-b1c2-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=D3XRdt1ng4gpuGmOrq2GCbvd0/sH5x/aMxmkWjmKuooUNXxj3v24/4jeo0Qz4Hu5Qs6FJI4etRgMUjB6oKi7m51fcDK6DE8Z7DYIrvrpSqeUCZv0MR92LWRQYxg41zTqL6Gn7V0atha4ehEI182/HW1erBgTXzIiwrA9jwJplFpb57+QXUTP8ftMGqKQs8jQMc/xXhvO9/jyiiyQGZflDPJZYcVtflrcSeTJFT9DWxopROLdl/u1GcwpRMmK1SaGPHBZlyJ+TbERn7+lZnswg2tcjwEpZgjXi7gq3pK34Gdo3EhWRswZJ9wfhyDno8lkUP5kHkwAYmQR+6MHYpHwUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Q66tnZkfbJTgYgQsDYVjaaaWnZNr+Jjg9l611QxeEqY=; b=l8IYtNLWmL54NvqsvYvpWljXV/dARDk6Wh8yCznHlS3YQyLQaima/ftnZJE0CFsc3+VZwg4Er23baqYQSd2bgaa6nAXuMsYX5+S3B85IPnQEoINa7/JfcV8B/4WHqdGS1bFQh2Zhc8lsUHOalEx2P2bOKGS5uO4e73yFr4fzJyhQW5sTzS4HHc/r9Har69svM9UvEkhOf7HeVaX6FIYTSuLshCdOQN0lMGBhpfxsFIsAJPi9DKYy0ujfRyFcQBCWd6t+qnci0lmAPybWVSgp3C+xiOBabL6jkprGomr5pHwYfXbWFZVsOjBth1Qs9cuXe24b3TE2tu8eugDyoVH5MA== 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=Q66tnZkfbJTgYgQsDYVjaaaWnZNr+Jjg9l611QxeEqY=; b=I/OqoekgvOJQwoZSE9NOPlDWCraXMLMD3cnbBgUX1LT3g8ooTMpc3kG64Hh244VDjUWXGMsLzvU72N26gXJRv1uOdBfylb5A9/+zOEjmga26erSgFe67HT+r5ZOnVDoCHLyAeYNnuN/xtrxirHc+xCEhdImo1pZ8OXHzDNQauHA= 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=SATLEXMB03.amd.com; pr=C From: Jason Andryuk To: CC: =?UTF-8?q?zithro=20/=20Cyril=20R=C3=A9bert?= , "Anthony PERARD" , Andrew Cooper , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Jason Andryuk Subject: [PATCH v3] tools/xl: add suspend and resume subcommands Date: Tue, 3 Dec 2024 17:06:41 -0500 Message-ID: <20241203220641.4202-1-jason.andryuk@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWH0EPF000A6733:EE_|PH0PR12MB7472:EE_ X-MS-Office365-Filtering-Correlation-Id: d32f6e1e-43d5-4df8-2f09-08dd13e6c18f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|36860700013|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?RXVneWlZbTNmb2VnL2l4eFFBenhCSnNzZ2FYTmZwQTlYWmZHWWRyWGI0dWxP?= =?utf-8?B?SmtSTFFCZDJiVXVMdkFaWGJudElSR1phY1JoR044dnVzK2xmWGVybVBVL3Vx?= =?utf-8?B?WloyQ1JBZVVzTzVCZnJMQTVlWHM0VlQwMkI1S2ViM2NHOGZsZHhSY1BOcm5y?= =?utf-8?B?K0VySnFLMG1KT2ZUVE9XTno4bEF0bjJDSUs5RHZsdVNxOVA1c2llZWxCazRY?= =?utf-8?B?c3pOQkRFOGRIeHNpSnZFLzU4U3R2aWNpMVdjWEZjQi9aZmI1WVZUQ29sMVV0?= =?utf-8?B?RGIzOWxuTjJmdGo4YU9qOEhORW14WmRLRHY0TjVGb3A0cWQ2SmN5SGNmcHNJ?= =?utf-8?B?dnlUNHRzU2JwTXkrTEtESXd3SnhvVlFVSU90dElCdnBPcnZRQzltenkxeko0?= =?utf-8?B?Y1MzbVU0K2V5bXN6ajc3VnpFVGt1SEsvUDVtTm5PdGttdnFlaGlzTFFnNXZv?= =?utf-8?B?Uzh0MlFjVWNSb2RTWm5RdXZJYjY3WERuU3dTekVvdWttcVg1TkhiNyt4bEhB?= =?utf-8?B?L1lneEVuaXpSTFNPRXJLaFVkN3ltZHAxaCtNV1pITVNvN3lsNjdMVnN6SWpK?= =?utf-8?B?cFhxQ0NIUDFaWWNsMy9rNWc5WUsraXlkdWUzMzZWdFJGclFJTlZZUVpXU1RJ?= =?utf-8?B?SHRyM2poV3gyRDVwMFIyY25qTGRhMXV2NzdjekpaWkU5bU4yTFZKTXF2NC9h?= =?utf-8?B?NVVrelovcTdtRVZ5cDBWUWlreExmK3RuMzQ0cTMwWmhBNGpINzhDL2tXOVFo?= =?utf-8?B?c2lKMGdZUUhOZjFCSEZleWJJWC9Yd2FYdVdGQ0JrTkoxOEpUbWF0OGpIRFNP?= =?utf-8?B?R2RxaWtXZ0NnaGhVcm40MGRPRUQ5dDY0V2V0dXRacFk1QTJ2V3JLV0hFT0tM?= =?utf-8?B?RWVEcWpVVm1GTFRzV2hXL3ZiS3FTNnhDcnRTQnRaZWtEelNyaGgwaHh2SzZv?= =?utf-8?B?U0FhTFNlbGNPdUJXRlZqRXZJbmdlMk9wYzROcnRYTVJqUGpDNWNHc0JuUERF?= =?utf-8?B?OHdkQ3JkMGE3dlJyRjdqUnZSd2xtSzM5aFFhQUpIZlErUCt1bHdlM0d3OTM5?= =?utf-8?B?ZXduTk05YkZyT0llL216RVZXYmQ0SmlYSG9Bd0tySXFVaG03Yi9Qa0FoUUkx?= =?utf-8?B?dVYzVmsxQi9xa1MrWVhseWVDclcrSi9tMnlQRXVES2xrQlhkR3M2RVJoSGlF?= =?utf-8?B?enhIajJZb09EeEp4OStmSkQ1Uzk4czJGOVh0eGp5QjRwL0hodkR3d2h3U3hB?= =?utf-8?B?T0pBaGJ0dWN0MVpGd09IYmdQdzdWSTA5VXcydk1VVXdjK083dGNQSVF2dU1h?= =?utf-8?B?WjJuRTV4eUlMZUhRRFN0VW1mcVZkUDlWb2FBeVdMQWlxVEVMY3pTOW9yakNU?= =?utf-8?B?dEEyUW5SbmErR1hRVTU0Vmd6Y2J0SHI3MW4za0NNUUJDUWd5a2FkZXc3VVlx?= =?utf-8?B?RHhUcXgxRU80MUdjYlRrcWtNa2MzZDQwRzkvSkx4T090aHZhclZlSDA0dWcz?= =?utf-8?B?VXdDTDdJOTZkYzZqR3FNclB5MmMyTXFPdUlQRFF3Y0tURVUrSVpVRmVldnRV?= =?utf-8?B?bW9ja1ZVQjNzcHZ4M0VxM05SZjRCdTNteFd5OUxpR0o5b00va1h6YzRsaWxP?= =?utf-8?B?OG5lSjJleEw0MS8xVUlWTm9yQUhmYVU2dG9IeFZMdmdtbUEyQmJLQW5mcksr?= =?utf-8?B?N0l5YU1maVBDMmxlc0Y1QXVDanVhd3ZmengvRWFEQTFwYXEyM0pGZGtOc1hM?= =?utf-8?B?akN0R2MvakVOQW41eUdJVmpURXRKRUoyTWtNTEd1Rm5rUzFWT3VCTVpsS3B0?= =?utf-8?B?dHlpZVdycDFtZjMvejBETENaUm1JazhHLzNyMk5VZ3hibVJhVEhwTWtNRWxk?= =?utf-8?B?RU4wTExZUE5FMWJWYXVrMGhYRGQ4U2FUWWRqZ1ZjNGI2VXdRbGtLcWdZRitD?= =?utf-8?Q?5Wu2h5Hc2gcZsvn1tcnuMxjoHR9f7yOL?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 22:06:36.5551 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d32f6e1e-43d5-4df8-2f09-08dd13e6c18f 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=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: MWH0EPF000A6733.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7472 From: zithro / Cyril Rébert The xl command doesn't provide suspend/resume, so add them : xl suspend xl resume This patch follows a discussion on XenDevel: when you want the virtualized equivalent of "sleep"-ing a host, it's better to suspend/resume than to pause/unpause a domain. Suggested-by: Andrew Cooper Suggested-by: Marek Marczykowski-Górecki Signed-off-by: Cyril Rébert (zithro) Signed-off-by: Jason Andryuk --- v2 Rename command to just "suspend" Move inside the HAVE_NO_SUSPEND_RESUME v3 Move more functions inside HAVE_NO_SUSPEND_RESUME --- docs/man/xl.1.pod.in | 12 ++++++++++++ tools/xl/xl.h | 2 ++ tools/xl/xl_cmdtable.c | 10 ++++++++++ tools/xl/xl_vmcontrol.c | 38 ++++++++++++++++++++++++++++++++++++++ 4 files changed, 62 insertions(+) diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in index bed8393473..fe38724b2b 100644 --- a/docs/man/xl.1.pod.in +++ b/docs/man/xl.1.pod.in @@ -682,6 +682,10 @@ Pass the VNC password to vncviewer via stdin. =back +=item B I + +Resume a domain, after having been suspended. + =item B [I] I I [I] Saves a running domain to a state file so that it can be restored @@ -760,6 +764,14 @@ in response to this event. =back +=item B I + +Suspend a domain. This is a cooperative operation where the domain must +respond to the xenstore trigger. When in a suspended state the domain +still consumes allocated resources (such as memory), but is not eligible +for scheduling by the Xen hypervisor. It is in a shutdown state, but +not dying. + =item B I I Send a to the domain, each type of request is diff --git a/tools/xl/xl.h b/tools/xl/xl.h index 967d034cfe..45745f0dbb 100644 --- a/tools/xl/xl.h +++ b/tools/xl/xl.h @@ -129,6 +129,8 @@ int main_restore(int argc, char **argv); int main_migrate_receive(int argc, char **argv); int main_save(int argc, char **argv); int main_migrate(int argc, char **argv); +int main_suspend(int argc, char **argv); +int main_resume(int argc, char **argv); #endif int main_dump_core(int argc, char **argv); int main_pause(int argc, char **argv); diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c index 53fc22d344..06a0039718 100644 --- a/tools/xl/xl_cmdtable.c +++ b/tools/xl/xl_cmdtable.c @@ -193,6 +193,16 @@ const struct cmd_spec cmd_table[] = { "Restore a domain from a saved state", "- for internal use only", }, + { "suspend", + &main_suspend, 0, 1, + "Suspend a domain to RAM", + "", + }, + { "resume", + &main_resume, 0, 1, + "Resume a domain from RAM", + "", + }, #endif { "dump-core", &main_dump_core, 0, 1, diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c index c45d497c28..c813732838 100644 --- a/tools/xl/xl_vmcontrol.c +++ b/tools/xl/xl_vmcontrol.c @@ -32,6 +32,44 @@ static int fd_lock = -1; +#ifndef LIBXL_HAVE_NO_SUSPEND_RESUME +static void suspend_domain(uint32_t domid) +{ + libxl_domain_suspend_only(ctx, domid, NULL); +} + +static void resume_domain(uint32_t domid) +{ + libxl_domain_resume(ctx, domid, 1, NULL); +} + +int main_suspend(int argc, char **argv) +{ + int opt; + + SWITCH_FOREACH_OPT(opt, "", NULL, "suspend", 1) { + /* No options */ + } + + suspend_domain(find_domain(argv[optind])); + + return EXIT_SUCCESS; +} + +int main_resume(int argc, char **argv) +{ + int opt; + + SWITCH_FOREACH_OPT(opt, "", NULL, "resume", 1) { + /* No options */ + } + + resume_domain(find_domain(argv[optind])); + + return EXIT_SUCCESS; +} +#endif + static void pause_domain(uint32_t domid) { libxl_domain_pause(ctx, domid, NULL); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 22:09:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 22:09:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848209.1263168 (Exim 4.92) (envelope-from ) id 1tIb55-0003Xy-4G; Tue, 03 Dec 2024 22:09:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848209.1263168; Tue, 03 Dec 2024 22:09: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 1tIb55-0003Xr-1S; Tue, 03 Dec 2024 22:09:19 +0000 Received: by outflank-mailman (input) for mailman id 848209; Tue, 03 Dec 2024 22:09: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 1tIb54-0003Xl-DW for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 22:09:18 +0000 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on20605.outbound.protection.outlook.com [2a01:111:f403:2417::605]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3c1196ab-b1c3-11ef-a0d4-8be0dac302b0; Tue, 03 Dec 2024 23:09:17 +0100 (CET) Received: from PH8PR15CA0015.namprd15.prod.outlook.com (2603:10b6:510:2d2::23) by PH7PR12MB7332.namprd12.prod.outlook.com (2603:10b6:510:20f::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Tue, 3 Dec 2024 22:09:07 +0000 Received: from MWH0EPF000A6734.namprd04.prod.outlook.com (2603:10b6:510:2d2:cafe::3b) by PH8PR15CA0015.outlook.office365.com (2603:10b6:510:2d2::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.18 via Frontend Transport; Tue, 3 Dec 2024 22:09:07 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by MWH0EPF000A6734.mail.protection.outlook.com (10.167.249.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 22:09:07 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 3 Dec 2024 16:09:06 -0600 Received: from [172.25.146.163] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Tue, 3 Dec 2024 16:09:05 -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: 3c1196ab-b1c3-11ef-a0d4-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qKmvV20VX8DAfak48q+YIKCysb5CeU+xNa4IPzuEqDsMFjZE5xyKG9CxhIuOcNvjGKi1i6FBOAnCPBPrenfk5UhnFaqio3NfcNNVWj5KkKwov3wdzCuhCQamjHV/9g8slf0Ahx9JfYlfqvvRm+/PagzpZ7C/ubOzunVJqn+p+Qv6jSgZbSJ1K6pyp7RgCKfisAzqaLhc2er8Nj/TMqNKRBOyw9Miz0KM2+17/JGcnx3qTPQI4mrYakL5GMft/vWaQumm0OVkGqpH836dfUyl3JNq1qK993OCJ0E3UaOl0fge7zFBUImL6WtrK0KjtmE1aw9TzbaVSflLzkWa944p6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Z9BW7P+K2nrEHfG3ECYMxja8KtSCfd9Yu4xjWNVvWx8=; b=D+Oh3n3qXeeGonR+BJcUnV0bj5UWhBG9H6Ox6v4PtQrOIT01a3vTa0deq7XMn0/hQ0jekhzMJ4oiGyTNNG4YDUW/Gz1qd0b7ddy+tJ8906LVeJXQOYNI87PKBFjxXqP76EEvkeeVCVuCXQDsQmQRB98WlUfodS3x73yS7NndhzP61xSBiYdHxERjDInlyb41z+wjG8K5GX0xK0CH4V/8FrZNReorCMzZuJm7+NN8RTZ5BmPT0TjNgQfR0xJNH0Oem/RjnayDCSjaPFwrF4jBrggn8ozGcrZM++CTqXXJPEF6zX27nP9h3v9yrsLsV/AcWEpBjijMDFmh/QA1zhhLPQ== 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=Z9BW7P+K2nrEHfG3ECYMxja8KtSCfd9Yu4xjWNVvWx8=; b=iSSez8G3gQceRt+MxYlQM+Dfcxb2zAXFi1sweU1DR/PBgRSs/bVmqEEjuvVWKzpFWNISDf1u1PH7g5EA/LcnQtwJaDeNn+9usj1oPS4JtIPeEKi+kruIw/uCcdnaXtkaXeHyd2aFsHVHf2UsUv63HG1DpRlXyzlX//yTNHI4FoI= 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=SATLEXMB03.amd.com; pr=C Message-ID: <5c76ebcb-baf2-4a63-b9d9-bd498f417202@amd.com> Date: Tue, 3 Dec 2024 17:09:05 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/acpi: upload power and performance related data from a PVH dom0 To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Stefano Stabellini , Oleksandr Tyshchenko CC: Roger Pau Monne , , References: <20240916205009.52887-1-jason.andryuk@amd.com> <52a2b2f3-ecdc-45fa-afcf-c4d6e2b1dd0c@suse.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <52a2b2f3-ecdc-45fa-afcf-c4d6e2b1dd0c@suse.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWH0EPF000A6734:EE_|PH7PR12MB7332:EE_ X-MS-Office365-Filtering-Correlation-Id: 30b45f19-4cdf-4ba4-c5c5-08dd13e71b4b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|82310400026|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?ckR4blNQclYySWE5MHJoVDNvQjBzalh2TkdIUnM1eng3L3BIemMvZXFWT2Qw?= =?utf-8?B?b0RIazQ2TmpyUlBHQThZcEFjU2V0aWlLWmFvUWo5bDYwbzZSSzJsLzQwbkcw?= =?utf-8?B?RUJRbXFCc1poVkFOZ2RreGF5bFh0REdLYzFlYSs5K214UjBGWmNqRnVyUHNR?= =?utf-8?B?eGsxemo2ZE9zVlh0TWNnZW5DMzJRTlNhMlAvSjhKYUVhbE85ZWdNSHdpdkFP?= =?utf-8?B?dkkyYWxGYnNEYUc2SHVaV2ZrT3E5MGFpSkJMY1pkVlc3VTlLNGhRWnFLMnNN?= =?utf-8?B?S2tLeWR6UHJ2YXZXckR5TW1KOHRBeUdQSnpCVHl6MHdLdFBpV0p6b2xBTjBo?= =?utf-8?B?VjMxU1dQTjI5dDFLMW1pZ2wza2tHODZrc3dmTlJQZVJrTzg3Rm1LR0txUW9C?= =?utf-8?B?Q1QvYzBDOHdUL25aOEVyS29haWQ3ZG1mVHRGNlJncjE4anZFejJ0WnFvS3RD?= =?utf-8?B?TjZxT0JKaEpJQlYySm1zamlQRzhRK0luWmo3RmRSUGlBSktTWnNmWTdEZlVN?= =?utf-8?B?VTcyWkJpQVpBZ2RwQUNDWWowemUvdERCNDE1elJZclhsNC9JbGFlWWliQmw3?= =?utf-8?B?Q0ZCbmFETFdDZFlPakdmY2JDQTVSK0JsUGJLbjRGYnVXT2JQSmd2K0s2UUR2?= =?utf-8?B?QUlqcFFtYkVHWFJCYTJhcGhnYlo3OVJyMld4ZVhKNjFFL2dPQ013UkZaS1hB?= =?utf-8?B?ZkZ2bkpLVEIzc0VPaDZWUWRLbVd0N1Rjd05Jam1IOW9jOGV1YVNuamtyZTRQ?= =?utf-8?B?dlNNbFR5Qy9GVXh2RE52Mnl4OXZ6Q0dkUHZwVVlPQnA1dVRHdE90WnNSVjhC?= =?utf-8?B?QmlNNHlZZFRoY3VuMTB6SDRPQTNRVzZwVmNjVVFuNTBOalBCNmJyOXpzK28v?= =?utf-8?B?UE41NHpkSXpScVlNQkFId3Z3NWNGTUJaRUNSNGN3WHY4VzlrajcvM1hYWDZH?= =?utf-8?B?MmxoZ2ZpUmh5cGJZQWIyVkw3NnhDZFVjTFVLS0Q2Vko3L1k4cVJFR2R3Mnhj?= =?utf-8?B?MVh6LzhuWksrWWpyaHV4dmttRjg4ZTg4UVJKUFFSR2FuREVZNjlqRnh5dS84?= =?utf-8?B?cldWc3hQS0dXZEtiMmhxbDVXaW1uUnFzRmJpTkRWUGNybnI3dEoyWHp6ZGM5?= =?utf-8?B?L2cxMkExb1lpZTIwQUdQT0hPOTlKcDk0ekg5ajFZYkR0QzdwZk1RYnZ6bFNG?= =?utf-8?B?NnVIdXViUlJCVm9wUzRxVzhSajdTWlU5WjRZWVFNZHV3bW1ZMmJSMzdxSGtu?= =?utf-8?B?Zk1OZEZLTTI5dUJEZ0h4TlR2R2trdEtPT2d6NnB5eGlHRm53K0JBS1BCOElG?= =?utf-8?B?MGEwdjE0blZua1hHLzNqckxGbWdxVHBSNUU0K2FkWjVpdk0zZUk1RWc1d2hP?= =?utf-8?B?V1o4RUdzM3NORXhKM0cxZ3dPL2FWa2ZHWUlWcGp6NDBlWlJ0U29JYVJ1Snls?= =?utf-8?B?dWZyaTZBVlVabVVmZmNQempCNVh5bmNZNVZ0dGFFK2VoMnBBenJRbWw0TVE1?= =?utf-8?B?U3pCdTV6RHBOTU03bk1MeW9pNk03aG96R2xsZXIvZ2VPOW02QWV4UjBDWnRX?= =?utf-8?B?M1JxSzVsL0VObDBza2RzZGdDWC9IZUN4QVMxMUFSYUh3NlF1Vkdpd1k4VVd1?= =?utf-8?B?blFKazBhUjh5T1VYT0RTdVlXMW9TQWVWQ1FTMzJ4bVAzRGRKQVNPQUV6Mjhn?= =?utf-8?B?bTF1d1RIdktKWFB5UEJOcWNLTUlleVF4bWFLWjFuOTFCTVBJbnJQeXZtMTNp?= =?utf-8?B?UTFIaHAwRkJLRVJNNWtjSVFsR2Zub09LQkEvdmtHMHdES3o4cE1QVStGYll3?= =?utf-8?B?NFlJNEVRM0ZlMFUxK0dXbDdPN0xEUlNlVU5VbmV4S0lBY0NKVWM4Mkc5bmxr?= =?utf-8?B?b3dlQWJEODZ3QVVKd3hnY2krQUdlNkJYWmhvUnA0VFVzbTR5Vm04SVpRT0tD?= =?utf-8?Q?blsOhaKsdlhaffRQBP9ihSK/mu5zFucK?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 22:09:07.1083 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 30b45f19-4cdf-4ba4-c5c5-08dd13e71b4b 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=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: MWH0EPF000A6734.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7332 On 2024-09-25 05:17, Jürgen Groß wrote: > On 16.09.24 22:50, Jason Andryuk wrote: >> From: Roger Pau Monne >> >> When running as a PVH dom0 the ACPI MADT is crafted by Xen in order to >> report the correct numbers of vCPUs that dom0 has, so the host MADT is >> not provided to dom0.  This creates issues when parsing the power and >> performance related data from ACPI dynamic tables, as the ACPI >> Processor UIDs found on the dynamic code are likely to not match the >> ones crafted by Xen in the dom0 MADT. >> >> Xen would rely on Linux having filled at least the power and >> performance related data of the vCPUs on the system, and would clone >> that information in order to setup the remaining pCPUs on the system >> if dom0 vCPUs < pCPUs.  However when running as PVH dom0 it's likely >> that none of dom0 CPUs will have the power and performance data >> filled, and hence the Xen ACPI Processor driver needs to fetch that >> information by itself. >> >> In order to do so correctly, introduce a new helper to fetch the _CST >> data without taking into account the system capabilities from the >> CPUID output, as the capabilities reported to dom0 in CPUID might be >> different from the ones on the host. >> >> Note that the newly introduced code will only fetch the _CST, _PSS, >> _PPC and _PCT from a single CPU, and clone that information for all the >> other Processors.  This won't work on an heterogeneous system with >> Processors having different power and performance related data between >> them. >> >> Signed-off-by: Roger Pau Monné >> Signed-off-by: Jason Andryuk >> --- >> v2: >> Add second buffer for _CST.  Call was failing with >> AE_BUFFER_OVERFLOW(0x000b) >> >> Running a PVH Dom0 on AMD, I needed this v2 change to get the C-State >> information uploaded. >> >> --- >>   drivers/xen/pcpu.c               |   3 +- >>   drivers/xen/xen-acpi-processor.c | 230 ++++++++++++++++++++++++++++--- >>   include/xen/xen.h                |   2 +- >>   3 files changed, 216 insertions(+), 19 deletions(-) >> >> diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c >> index c63f317e3df3..dc9f2c14bf62 100644 >> --- a/drivers/xen/pcpu.c >> +++ b/drivers/xen/pcpu.c > > ... > >> @@ -354,24 +511,44 @@ read_acpi_id(acpi_handle handle, u32 lvl, void >> *context, void **rv) >>       default: >>           return AE_OK; >>       } >> -    if (invalid_phys_cpuid(acpi_get_phys_id(handle, >> -                        acpi_type == ACPI_TYPE_DEVICE, >> -                        acpi_id))) { >> + >> +    if (!xen_processor_present(acpi_id)) { >>           pr_debug("CPU with ACPI ID %u is unavailable\n", acpi_id); >>           return AE_OK; >>       } >> -    /* There are more ACPI Processor objects than in x2APIC or MADT. >> -     * This can happen with incorrect ACPI SSDT declerations. */ >> -    if (acpi_id >= nr_acpi_bits) { >> -        pr_debug("max acpi id %u, trying to set %u\n", >> -             nr_acpi_bits - 1, acpi_id); >> -        return AE_OK; >> -    } >> + >>       /* OK, There is a ACPI Processor object */ >>       __set_bit(acpi_id, acpi_id_present); >>       pr_debug("ACPI CPU%u w/ PBLK:0x%lx\n", acpi_id, (unsigned >> long)pblk); >> +    if (!pr_initialized) { >> +        struct acpi_processor *pr = context; >> +        int rc; >> + >> +        /* >> +         * There's no CPU on the system that has any performance or >> +         * power related data, initialize all the required fields by >> +         * fetching that info here. >> +         * >> +         * Note such information is only fetched once, and then reused >> +         * for all pCPUs.  This won't work on heterogeneous systems >> +         * with different Cx anb/or Px states between CPUs. >> +         */ >> + >> +        pr->handle = handle; >> + >> +        rc = acpi_processor_get_performance_info(pr); >> +        if (rc) >> +            pr_debug("ACPI CPU%u failed to get performance data\n", >> +                 acpi_id); > > Is it really normal to get a failure here? Shouldn't the reaction > be a little bit more visible in this case? > > And can you just continue processing? > >> +        rc = xen_acpi_processor_evaluate_cst(handle, &pr->power); >> +        if (rc) >> +            pr_debug("ACPI CPU%u failed to get _CST data\n", acpi_id); > > Same again. Is pr_debug() enough? Thanks. I'll switch them to pr_err(). And I'll only set pr_initialized = true when both calls succeed. Regards, Jason From xen-devel-bounces@lists.xenproject.org Tue Dec 03 22:53:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 22:53:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848281.1263210 (Exim 4.92) (envelope-from ) id 1tIbm1-00044e-21; Tue, 03 Dec 2024 22:53:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848281.1263210; Tue, 03 Dec 2024 22: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 1tIbm0-00044X-Uc; Tue, 03 Dec 2024 22:53:40 +0000 Received: by outflank-mailman (input) for mailman id 848281; Tue, 03 Dec 2024 22:53: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 1tIbm0-00044R-5p for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 22:53:40 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2062e.outbound.protection.outlook.com [2a01:111:f403:2416::62e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6d5f6853-b1c9-11ef-99a3-01e77a169b0f; Tue, 03 Dec 2024 23:53:37 +0100 (CET) Received: from BYAPR07CA0087.namprd07.prod.outlook.com (2603:10b6:a03:12b::28) by CY5PR12MB6105.namprd12.prod.outlook.com (2603:10b6:930:2a::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.19; Tue, 3 Dec 2024 22:53:29 +0000 Received: from MWH0EPF000971E4.namprd02.prod.outlook.com (2603:10b6:a03:12b:cafe::8b) by BYAPR07CA0087.outlook.office365.com (2603:10b6:a03:12b::28) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.17 via Frontend Transport; Tue, 3 Dec 2024 22:53:29 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by MWH0EPF000971E4.mail.protection.outlook.com (10.167.243.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Tue, 3 Dec 2024 22:53:29 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) 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; Tue, 3 Dec 2024 16:53:28 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) 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; Tue, 3 Dec 2024 16:53:28 -0600 Received: from amd-BIRMANPLUS.mshome.net (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Tue, 3 Dec 2024 16:53:27 -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: 6d5f6853-b1c9-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RxIBrZ+qohD9VdQRnDtgId6ZLGxmlIrbKPgav5YrnwYYldLwbTHMhgYC4NUzINBvyeIW/us87eDrZQNYKOiviSG4w+Op6C1b4UAHKGkRnzYsK1t5CQRgldxUkFfuugJ3rj/b+y9RGu/UHRBU1pMRl59B9dNA+nl4jjb9R+h8iSJ3OKQTRxQfJtONmQrBcmYJBqsvukQS7ClqbYRq1K3ceLpl0V+988BZS2BBzFafvzM/XmxtWzW4QsKLLboBr36K9y2KeBi58KOubtZi2UR3uXOc1MSc8iOpJssf1vtxnoiQurpywfgUmtGOFt1nPIX91pXQoDr2QYizErnNU+UNVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=buKuJRQISbtaWxtySk3tsXXCvGMq1tZmcfuosqxgBs8=; b=NK18/WgRtiTOLBUmbRvHZ9MHkq4Up9swiSLGr1/1aZTktnAzQVDUG4NCXRdXQXjrthR8spg+c7qKFLDLU8BTc5nw4PSyQIsF4U+LbOJlvotrm9UB7V9q+4FXXGsCNb3K5cT+moJJ7uqo/cagC7ZdhS23uX0Ps7hWnzySH4Vpii2sCzIFlLe8Ijolg/BHG4Ub5eXjvgcmfGT21FhH9imaJqsISqhMAU+bSMtY8D5hNuStqWVCZ7+RyU6fHIGeZtsq6xsvWa874EOdjqzkoKtaG4gse8IIeW6zlm7eBVtE2ag2boP3VtiKIqNqNACeTUqaUUq4dPbFNiCUx5EpZVtQPw== 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=buKuJRQISbtaWxtySk3tsXXCvGMq1tZmcfuosqxgBs8=; b=JjQpvTjZv9IQyjhlG/enYKBDmsXbTs0zbBhdPVa9Uv3P0L9HWfbyBPLeqaePWSEmSZGy+gQ7iPuVJrdLi+j/PfnNSHJX8l2DvS8UiSApVsAI1xMk7vxELypq+l4hcJTxfWca1X1zB/w4xrgx7j+++ydcPNwmUMo1MFwsglNf5p0= 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=SATLEXMB04.amd.com; pr=C From: Jason Andryuk To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko CC: Penny Zheng , Roger Pau Monne , Jason Andryuk , , Subject: [PATCH v3] xen/acpi: upload power and performance related data from a PVH dom0 Date: Tue, 3 Dec 2024 17:53:37 -0500 Message-ID: <20241203225338.1336-1-jason.andryuk@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWH0EPF000971E4:EE_|CY5PR12MB6105:EE_ X-MS-Office365-Filtering-Correlation-Id: 605e909e-da62-447d-2bf1-08dd13ed4dfb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?eUVyclF4TGpWY0JVemo5MEtidTNuNEEwK1E5VGtmR3VJNmFlRU42Y1BEOWhu?= =?utf-8?B?WXNESCtjZmw5RElzYjlNYkxXRDNuZTNtQzg3OGtSMGtKWHdSRVdyTnRIeXll?= =?utf-8?B?SlBkUy9objlIMHJBRVUvKzhOajR4eGx6NWcrOWpkZFEvNTJabFd0Umxuellh?= =?utf-8?B?MDZBR1k0OE9oSlJ3OEkxUXcrYklBcUwyWDNLZnBQdnhaY3NtYm9YWllIYmFm?= =?utf-8?B?ZHRXQVcxM042cmZ1aHNJTHNXZHVaaG05bmpYTXVHbmFLYWdhK01USnJBZTRz?= =?utf-8?B?YVFRZ1NBNXl4MEgvL21JVmJia0dSczBCaWdyNGxtaGEyeWxhaTV2MzRJUjFH?= =?utf-8?B?TGVtM3U2dllDM2l6NWZiUVRvSVdmTEpLR1kvL0MxM2c3VWRuNzFqcFBJVHJw?= =?utf-8?B?QjcyRENtQVZHemVQbzhoZVZrM1JLQkJDZzFjWDU1NnFweUJEUURqZWdUOUl1?= =?utf-8?B?bTBFRytFZ1ZhUy9uK1J0T2EwSmxwWWt3T2dLb2szc3VTM3FuZlBBeCtRQ2x5?= =?utf-8?B?TTRkOVlmMWF1ZHM4OExkbTcySXhhOVRlaW81V2IrM2VsOWwwU0d6UmRBN1Mw?= =?utf-8?B?WU0rNkkzUDVocElxUHdQK1V2K3hLV3ZVUE55a1R6a0JlTDY5ODkybEovM2Ji?= =?utf-8?B?RnBnTGVtOWRFNnJxQ0t3YVYvY0hDZVBkaXE4T3BPTWcweTJ1cWVuczBpcFpp?= =?utf-8?B?Q3YwQ3hrZHRiRzhKbC9yR1N5UElFaXhYcmc3Z2FHL0NDdHJtQlJha0traE5y?= =?utf-8?B?ZENEbGxUTG5HejhSMUtOUTBHOTZDMU5icnViL3NZTzlpTk4xZUJYR0xRd2hy?= =?utf-8?B?R29XSVhlWndVcDYvc01vMVBzTVlMZXFZNVVXNk1PbG9QalpJeW5WL2IxMVls?= =?utf-8?B?NkFJOXBETnZxMGluSjJONitUc2pNck5BOGhkaDZRc25UaXVZc2RPbXd0bXYw?= =?utf-8?B?OHJYVXJSU0VPaXYwK0xwVW4wa3BXWG0wMVIzOUQvK1FKQnczZVdTR1IyamFM?= =?utf-8?B?ZG9ZelhNemRrQTJUUWhBeXpwWlduWjFDcHcyaExrcENkcGUvKzdwMUJPY0Vw?= =?utf-8?B?cUs2b0pDdHZRZ1E4SVNReHYreUJuMlR6NU5JSEUvSU53ZWFkU0hiQVlTRkxr?= =?utf-8?B?Ty9BQytGTTEwSmxRYkNJRldRbWRNR25Vb29sVmFhRUVYL1dHRFVMdHdRNnF1?= =?utf-8?B?V2VLK3Bmb1RHdzJ2Y1BxRHVXTWc3VVJLSnVPVjZpK2lQd1k5VldrWE9zNzBm?= =?utf-8?B?TVRmQXlleTdNRy9ybXFNL3FtM0hhRUllaGtzdkVFVUVYQW94czlpdWVZcXFT?= =?utf-8?B?clhUYW1WOVhaNE9DbUhxVktOZ2l5TWJyb3pNa0p4bFdueEc1QmtGRnB6UHpz?= =?utf-8?B?a3ZuS2VhMDJ1Tyt2Z2xkSVZqVHlXOEpZcGxudllsQ1BXM2lQMENpTkJ2L2ZW?= =?utf-8?B?QnpxV1d0WE9tMjdqcnJSTURpenR5eTM3K3NTRjJQeSs4c1pBeEdRZ1ZoWW1R?= =?utf-8?B?RVdKL3NrZzVJdnhPaVowejU4dlFUZVg4dmhwTzZJYkZCTVJKVzJBbC84bk44?= =?utf-8?B?T2djOFNJSlc2ckFQODg3L1dHcW0vNHBLYmYzeGJnR2ZHa0loMUFLZmhoV0dL?= =?utf-8?B?MHRzVnFlK1R4YmlRSE5BTk5JQThnemFBYXNqQVRQd0JIS2NyZG9XOXc1dGta?= =?utf-8?B?Nzl4VUhYVkQ4VkVXaWN2V1M3UzBLVHFxNVlhemQwb0R1b0xEbzVFMjdXa2tu?= =?utf-8?B?NFRlVzF4STZqQ0JCZzJZWVN0MTZ1ZEFPbHcrWjcyTERaMGo2cjVjYUEvaUJX?= =?utf-8?B?Y0pBdmhEZUhzdllXb3RNb2xxeEQ4K2k3czVrWFBhS256VEFlRHpiaFRwYWJH?= =?utf-8?B?L0dHY3JyT1JCVHYvZlI1YXlBbVpmakU4MnVZcjYvcHhYU0wxNzJkdmpGV0lM?= =?utf-8?Q?88iwSQ+fu2rUL3+hZGTmAbfi9D+5p2gy?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2024 22:53:29.1243 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 605e909e-da62-447d-2bf1-08dd13ed4dfb 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: MWH0EPF000971E4.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6105 From: Roger Pau Monne When running as a PVH dom0 the ACPI MADT is crafted by Xen in order to report the correct numbers of vCPUs that dom0 has, so the host MADT is not provided to dom0. This creates issues when parsing the power and performance related data from ACPI dynamic tables, as the ACPI Processor UIDs found on the dynamic code are likely to not match the ones crafted by Xen in the dom0 MADT. Xen would rely on Linux having filled at least the power and performance related data of the vCPUs on the system, and would clone that information in order to setup the remaining pCPUs on the system if dom0 vCPUs < pCPUs. However when running as PVH dom0 it's likely that none of dom0 CPUs will have the power and performance data filled, and hence the Xen ACPI Processor driver needs to fetch that information by itself. In order to do so correctly, introduce a new helper to fetch the _CST data without taking into account the system capabilities from the CPUID output, as the capabilities reported to dom0 in CPUID might be different from the ones on the host. Note that the newly introduced code will only fetch the _CST, _PSS, _PPC and _PCT from a single CPU, and clone that information for all the other Processors. This won't work on an heterogeneous system with Processors having different power and performance related data between them. Signed-off-by: Roger Pau Monné Signed-off-by: Jason Andryuk --- v2: Add second buffer for _CST. Call was failing with AE_BUFFER_OVERFLOW(0x000b) v3: Upgrade some failures to pr_err Only set pr_initialized when acpi_processor_get_performance_info() and xen_acpi_processor_evaluate_cst() both succeed. Remove BUG_ON(!pr_backup) - checkpatch complains and the case is handled earlier. --- drivers/xen/pcpu.c | 3 +- drivers/xen/xen-acpi-processor.c | 232 ++++++++++++++++++++++++++++--- include/xen/xen.h | 2 +- 3 files changed, 216 insertions(+), 21 deletions(-) diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c index c63f317e3df3..dc9f2c14bf62 100644 --- a/drivers/xen/pcpu.c +++ b/drivers/xen/pcpu.c @@ -388,7 +388,7 @@ static int __init xen_pcpu_init(void) arch_initcall(xen_pcpu_init); #ifdef CONFIG_ACPI -bool __init xen_processor_present(uint32_t acpi_id) +bool xen_processor_present(uint32_t acpi_id) { const struct pcpu *pcpu; bool online = false; @@ -403,6 +403,7 @@ bool __init xen_processor_present(uint32_t acpi_id) return online; } +EXPORT_SYMBOL_GPL(xen_processor_present); void xen_sanitize_proc_cap_bits(uint32_t *cap) { diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c index 296703939846..e9f38f171240 100644 --- a/drivers/xen/xen-acpi-processor.c +++ b/drivers/xen/xen-acpi-processor.c @@ -48,6 +48,8 @@ static unsigned long *acpi_id_cst_present; /* Which ACPI P-State dependencies for a enumerated processor */ static struct acpi_psd_package *acpi_psd; +static bool pr_initialized; + static int push_cxx_to_hypervisor(struct acpi_processor *_pr) { struct xen_platform_op op = { @@ -172,8 +174,13 @@ static int xen_copy_psd_data(struct acpi_processor *_pr, /* 'acpi_processor_preregister_performance' does not parse if the * num_processors <= 1, but Xen still requires it. Do it manually here. + * + * Also init the field if not set, as that's possible if the physical + * CPUs on the system doesn't match the data provided in the MADT when + * running as a PVH dom0. */ - if (pdomain->num_processors <= 1) { + if (pdomain->num_processors <= 1 || + dst->shared_type == CPUFREQ_SHARED_TYPE_NONE) { if (pdomain->coord_type == DOMAIN_COORD_TYPE_SW_ALL) dst->shared_type = CPUFREQ_SHARED_TYPE_ALL; else if (pdomain->coord_type == DOMAIN_COORD_TYPE_HW_ALL) @@ -313,6 +320,155 @@ static unsigned int __init get_max_acpi_id(void) pr_debug("Max ACPI ID: %u\n", max_acpi_id); return max_acpi_id; } + +/* + * Custom version of the native acpi_processor_evaluate_cst() function, to + * avoid some sanity checks done based on the CPUID data. When running as a + * Xen domain the CPUID data provided to dom0 is not the native one, so C + * states cannot be sanity checked. Leave it to the hypervisor which is also + * the entity running the driver. + */ +static int xen_acpi_processor_evaluate_cst(acpi_handle handle, + struct acpi_processor_power *info) +{ + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL }; + union acpi_object *cst; + acpi_status status; + u64 count; + int last_index = 0; + int i, ret = 0; + + status = acpi_evaluate_object(handle, "_CST", NULL, &buffer); + if (ACPI_FAILURE(status)) { + acpi_handle_debug(handle, "No _CST\n"); + return -ENODEV; + } + + cst = buffer.pointer; + + /* There must be at least 2 elements. */ + if (!cst || cst->type != ACPI_TYPE_PACKAGE || cst->package.count < 2) { + acpi_handle_warn(handle, "Invalid _CST output\n"); + ret = -EFAULT; + goto end; + } + + count = cst->package.elements[0].integer.value; + + /* Validate the number of C-states. */ + if (count < 1 || count != cst->package.count - 1) { + acpi_handle_warn(handle, "Inconsistent _CST data\n"); + ret = -EFAULT; + goto end; + } + + for (i = 1; i <= count; i++) { + union acpi_object *element; + union acpi_object *obj; + struct acpi_power_register *reg; + struct acpi_processor_cx cx; + + /* + * If there is not enough space for all C-states, skip the + * excess ones and log a warning. + */ + if (last_index >= ACPI_PROCESSOR_MAX_POWER - 1) { + acpi_handle_warn(handle, "No room for more idle states (limit: %d)\n", + ACPI_PROCESSOR_MAX_POWER - 1); + break; + } + + memset(&cx, 0, sizeof(cx)); + + element = &cst->package.elements[i]; + if (element->type != ACPI_TYPE_PACKAGE) { + acpi_handle_info(handle, "_CST C%d type(%x) is not package, skip...\n", + i, element->type); + continue; + } + + if (element->package.count != 4) { + acpi_handle_info(handle, "_CST C%d package count(%d) is not 4, skip...\n", + i, element->package.count); + continue; + } + + obj = &element->package.elements[0]; + + if (obj->type != ACPI_TYPE_BUFFER) { + acpi_handle_info(handle, "_CST C%d package element[0] type(%x) is not buffer, skip...\n", + i, obj->type); + continue; + } + + reg = (struct acpi_power_register *)obj->buffer.pointer; + + obj = &element->package.elements[1]; + if (obj->type != ACPI_TYPE_INTEGER) { + acpi_handle_info(handle, "_CST C[%d] package element[1] type(%x) is not integer, skip...\n", + i, obj->type); + continue; + } + + cx.type = obj->integer.value; + /* + * There are known cases in which the _CST output does not + * contain C1, so if the type of the first state found is not + * C1, leave an empty slot for C1 to be filled in later. + */ + if (i == 1 && cx.type != ACPI_STATE_C1) + last_index = 1; + + cx.address = reg->address; + cx.index = last_index + 1; + + switch (reg->space_id) { + case ACPI_ADR_SPACE_FIXED_HARDWARE: + cx.entry_method = ACPI_CSTATE_FFH; + break; + + case ACPI_ADR_SPACE_SYSTEM_IO: + cx.entry_method = ACPI_CSTATE_SYSTEMIO; + break; + + default: + acpi_handle_info(handle, "_CST C%d space_id(%x) neither FIXED_HARDWARE nor SYSTEM_IO, skip...\n", + i, reg->space_id); + continue; + } + + if (cx.type == ACPI_STATE_C1) + cx.valid = 1; + + obj = &element->package.elements[2]; + if (obj->type != ACPI_TYPE_INTEGER) { + acpi_handle_info(handle, "_CST C%d package element[2] type(%x) not integer, skip...\n", + i, obj->type); + continue; + } + + cx.latency = obj->integer.value; + + obj = &element->package.elements[3]; + if (obj->type != ACPI_TYPE_INTEGER) { + acpi_handle_info(handle, "_CST C%d package element[3] type(%x) not integer, skip...\n", + i, obj->type); + continue; + } + + memcpy(&info->states[++last_index], &cx, sizeof(cx)); + } + + acpi_handle_info(handle, "Found %d idle states\n", last_index); + + info->count = last_index; + +end: + kfree(buffer.pointer); + + return ret; +} + /* * The read_acpi_id and check_acpi_ids are there to support the Xen * oddity of virtual CPUs != physical CPUs in the initial domain. @@ -331,6 +487,7 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) unsigned long long tmp; union acpi_object object = { 0 }; struct acpi_buffer buffer = { sizeof(union acpi_object), &object }; + struct acpi_buffer cst_buf = { ACPI_ALLOCATE_BUFFER, NULL }; acpi_io_address pblk = 0; status = acpi_get_type(handle, &acpi_type); @@ -354,24 +511,45 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) default: return AE_OK; } - if (invalid_phys_cpuid(acpi_get_phys_id(handle, - acpi_type == ACPI_TYPE_DEVICE, - acpi_id))) { + + if (!xen_processor_present(acpi_id)) { pr_debug("CPU with ACPI ID %u is unavailable\n", acpi_id); return AE_OK; } - /* There are more ACPI Processor objects than in x2APIC or MADT. - * This can happen with incorrect ACPI SSDT declerations. */ - if (acpi_id >= nr_acpi_bits) { - pr_debug("max acpi id %u, trying to set %u\n", - nr_acpi_bits - 1, acpi_id); - return AE_OK; - } + /* OK, There is a ACPI Processor object */ __set_bit(acpi_id, acpi_id_present); pr_debug("ACPI CPU%u w/ PBLK:0x%lx\n", acpi_id, (unsigned long)pblk); + if (!pr_initialized) { + struct acpi_processor *pr = context; + int rc, rc2; + + /* + * There's no CPU on the system that has any performance or + * power related data, initialize all the required fields by + * fetching that info here. + * + * Note such information is only fetched once, and then reused + * for all pCPUs. This won't work on heterogeneous systems + * with different Cx anb/or Px states between CPUs. + */ + + pr->handle = handle; + + rc = acpi_processor_get_performance_info(pr); + if (rc) + pr_err("ACPI CPU%u failed to get performance data\n", + acpi_id); + rc2 = xen_acpi_processor_evaluate_cst(handle, &pr->power); + if (rc2) + pr_err("ACPI CPU%u failed to get _CST data\n", acpi_id); + + if (!rc && !rc2) + pr_initialized = true; + } + /* It has P-state dependencies */ if (!acpi_processor_get_psd(handle, &acpi_psd[acpi_id])) { pr_debug("ACPI CPU%u w/ PST:coord_type = %llu domain = %llu\n", @@ -379,11 +557,13 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) acpi_psd[acpi_id].domain); } - status = acpi_evaluate_object(handle, "_CST", NULL, &buffer); + status = acpi_evaluate_object(handle, "_CST", NULL, &cst_buf); if (ACPI_FAILURE(status)) { if (!pblk) return AE_OK; } + kfree(cst_buf.pointer); + /* .. and it has a C-state */ __set_bit(acpi_id, acpi_id_cst_present); @@ -391,10 +571,6 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) } static int check_acpi_ids(struct acpi_processor *pr_backup) { - - if (!pr_backup) - return -ENODEV; - if (acpi_id_present && acpi_id_cst_present) /* OK, done this once .. skip to uploading */ goto upload; @@ -422,8 +598,8 @@ static int check_acpi_ids(struct acpi_processor *pr_backup) acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT, ACPI_UINT32_MAX, - read_acpi_id, NULL, NULL, NULL); - acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID, read_acpi_id, NULL, NULL); + read_acpi_id, NULL, pr_backup, NULL); + acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID, read_acpi_id, pr_backup, NULL); upload: if (!bitmap_equal(acpi_id_present, acpi_ids_done, nr_acpi_bits)) { @@ -464,6 +640,7 @@ static int xen_upload_processor_pm_data(void) struct acpi_processor *pr_backup = NULL; int i; int rc = 0; + bool free_perf = false; pr_info("Uploading Xen processor PM info\n"); @@ -473,12 +650,29 @@ static int xen_upload_processor_pm_data(void) if (!_pr) continue; - if (!pr_backup) + if (!pr_backup) { pr_backup = kmemdup(_pr, sizeof(*_pr), GFP_KERNEL); + pr_initialized = true; + } (void)upload_pm_data(_pr); } + if (!pr_backup) { + pr_backup = kzalloc(sizeof(struct acpi_processor), GFP_KERNEL); + if (!pr_backup) + return -ENOMEM; + pr_backup->performance = kzalloc(sizeof(struct acpi_processor_performance), + GFP_KERNEL); + if (!pr_backup->performance) { + kfree(pr_backup); + return -ENOMEM; + } + free_perf = true; + } + rc = check_acpi_ids(pr_backup); + if (free_perf) + kfree(pr_backup->performance); kfree(pr_backup); return rc; diff --git a/include/xen/xen.h b/include/xen/xen.h index a1e5b3f18d69..6ff3e2f40803 100644 --- a/include/xen/xen.h +++ b/include/xen/xen.h @@ -81,7 +81,7 @@ static inline void xen_free_unpopulated_pages(unsigned int nr_pages, #endif #if defined(CONFIG_XEN_DOM0) && defined(CONFIG_ACPI) && defined(CONFIG_X86) -bool __init xen_processor_present(uint32_t acpi_id); +bool xen_processor_present(uint32_t acpi_id); #else #include static inline bool xen_processor_present(uint32_t acpi_id) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 03 23:16:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 23:16:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848296.1263219 (Exim 4.92) (envelope-from ) id 1tIc84-0007IJ-V5; Tue, 03 Dec 2024 23:16:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848296.1263219; Tue, 03 Dec 2024 23:16:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIc84-0007IC-SV; Tue, 03 Dec 2024 23:16:28 +0000 Received: by outflank-mailman (input) for mailman id 848296; Tue, 03 Dec 2024 23:16: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 1tIc83-0007I6-VR for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 23:16: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 9da273dc-b1cc-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 00:16:25 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-434a044dce2so75128985e9.2 for ; Tue, 03 Dec 2024 15:16: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: 9da273dc-b1cc-11ef-a0d4-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733267784; x=1733872584; 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=4rWZKbxVjhvo+myeo7DxMHip09ZQtePB47fxAQ2IzlE=; b=lsjqbPKd6vx66GYNL+6nGvz4c2zaEER2aI+3ouEjUoOeZP97O0H2MuM/1hjphOAvTT p8waek2ERWYWLdNF/pJOuT8T17XbZIEkgIIq4xTT3dLRioQUFqNVDpPAz3tJkYo/hSsK Cd6pKMyBEei432cj+RWRHeH10A46vOu12aKO7SnGevX5Rs5FFbnb20G5wVypqh7+uubP KCsHFtwwP4jPfXZ6HdL0VxUq0bzgnXOfIGcEugPc/Clx2binkiBsaCSxjZSQ2J5qyi3j 7P7uNXI8Sbuikgio7pzBXELLBWAD15w125lfg0LNmvB7Cp1yfThrcCfxCKqWPwjscnkm L3gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733267784; x=1733872584; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4rWZKbxVjhvo+myeo7DxMHip09ZQtePB47fxAQ2IzlE=; b=LDDhyPQOzUlBGDQlGIPu95BT3o/BtusVhy/YNivPsxfPq+Gz2mL27qoPtC+I+CA5r6 0TM82C/IfoM77Q1d8eP8SoruRXd2yMJdiwZJnZ0XcvWgB7fa2Kiw81GtPhpf+50cqyDB L3TlH+1Zs1E7lmkyM80rDEIQGZGvzD2wPxCZojQBArTjZj3DLs+UTJBJiL9pPAmq1/kL ikUnbmprJvI4YPvMHy3YFGoc+SJuN8zSc59tHfXJojM0TGuq4Tv+RswmDRYXjuo+l+rx LOxwCRBxKEkzk+N0/Dj71PRh0rFvuytXQv7ZK+A16T/fYkDsC63h1CoXO8fQItQ6pUCZ hnow== X-Forwarded-Encrypted: i=1; AJvYcCUkPLm2zw7OeJUee/CVIT+Q+rloT57kkWn/++iPOxs/kFP1us3WHZNDpvKJ50mYXSGniE5DN1GA+GE=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx90e6ywasqArTZOMZxpSHAH/YTgXzupNLcKgk0DW/3tZb4BESX xnTvIjOgTcK+DSqmaltl2eDOT1h7u+X1+C3RQRwe1RikWBn4KcvjQum66l+6wL2jBNZ/53fvs25 FeluTJEBwzpteSMWMQ+ewIPXX0xQ= X-Gm-Gg: ASbGncsZajYIuI3lR0z/AubLi2As3L/pjYJnqHjH9TG0/kSkNwKTaSn8WKDqXfra+PL 0weBJyBte7zQ+peoxc9h0MTzadjMrkQy0d4SgsVML2d7kcf/USpsHoXoHh24q X-Google-Smtp-Source: AGHT+IHcZJQzQnAoFfiNQpJke12pTp46ia7jXjPEKPE75lbULp7MPNkvCwOFydrVyNaFEb8YrQQ2PdFVUUZGFjSlmGo= X-Received: by 2002:a5d:6f15:0:b0:382:4ab4:b3e5 with SMTP id ffacd0b85a97d-385fd378fc9mr4568941f8f.0.1733267784017; Tue, 03 Dec 2024 15:16:24 -0800 (PST) MIME-Version: 1.0 References: <20241130010954.36057-1-volodymyr_babchuk@epam.com> <20241130010954.36057-4-volodymyr_babchuk@epam.com> In-Reply-To: From: Julien Grall Date: Tue, 3 Dec 2024 23:16:12 +0000 Message-ID: Subject: Re: [PATCH v2 3/4] xen: arm: enable stack protector feature To: Andrew Cooper Cc: Volodymyr Babchuk , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Bertrand Marquis , Michal Orzel Content-Type: text/plain; charset="UTF-8" On Tue, 3 Dec 2024 at 22:00, Andrew Cooper wrote: > > On 30/11/2024 1:10 am, Volodymyr Babchuk wrote: > > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c > > index 2e27af4560..f855e97e25 100644 > > --- a/xen/arch/arm/setup.c > > +++ b/xen/arch/arm/setup.c > > @@ -341,6 +342,8 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr) > > */ > > system_state = SYS_STATE_boot; > > > > + boot_stack_chk_guard_setup(); > > + > > if ( acpi_disabled ) > > { > > printk("Booting using Device Tree\n"); > > I still think that __stack_chk_guard wants setting up in ASM before > entering C. > > The only reason this call is so late is because Xen's get_random() > sequence is less than helpful. That wants rewriting somewhat, but maybe > now isn't the best time. > > Even if you initialise __stack_chk_guard it to -1 rather than 0, it's > still got a better chance of catching errors during very early boot; the > instrumentation is present, but is using 0 as the canary value. > > On x86, dumping the current TSC value into __stack_chk_guard would be > far better than using -1. Even if it skewed to a lower number, it's > unpredictable and not going to reoccur by accident during a stack overrun. > > Surely ARM has something similar it could use? There is a optional system register to read a random number. > > [edit] Yes, get_cycles(), which every architecture seems to have. In > fact, swapping get_random() from NOW() to get_cycles() would be good > enough to get it usable from early assembly. Not quite. Technically we can't rely on the timer counter until platform_init_time() is called. This was to cater an issue on the exynos we used in OssTest. But arguably this is the exception rather than the norm because the firmware ought to properly initialize the timer... I haven't checked recent firmware. But I could be convinced to access the counter before hand if we really think that setting __stack_chk_guard from ASM is much better. Cheers, From xen-devel-bounces@lists.xenproject.org Tue Dec 03 23:43:16 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Dec 2024 23:43:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848308.1263230 (Exim 4.92) (envelope-from ) id 1tIcXt-0003jz-Qp; Tue, 03 Dec 2024 23:43:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848308.1263230; Tue, 03 Dec 2024 23:43: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 1tIcXt-0003js-Nm; Tue, 03 Dec 2024 23:43:09 +0000 Received: by outflank-mailman (input) for mailman id 848308; Tue, 03 Dec 2024 23:43: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 1tIcXr-0003jm-V7 for xen-devel@lists.xenproject.org; Tue, 03 Dec 2024 23:43:08 +0000 Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [2607:f8b0:4864:20::933]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 57a26635-b1d0-11ef-99a3-01e77a169b0f; Wed, 04 Dec 2024 00:43:06 +0100 (CET) Received: by mail-ua1-x933.google.com with SMTP id a1e0cc1a2514c-85b8d1fd1bbso1207939241.1 for ; Tue, 03 Dec 2024 15:43:05 -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: 57a26635-b1d0-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1733269385; x=1733874185; 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=efxAKMGIsYtsJH1TfFadrRu53b/jP4XGduoqdQKfUDs=; b=h1iS4xq+GGEd/ABvnPItonmGoWFafwlpkETSUm1gXJy87nTtI76PfKrTb7GI12tm0Z 4whv/4CQP4AI+QTNE1LbCNEsou7PYDM/tiwc6tQTJ9waMb1Y3ta6EoB9yhyYPFOiIQ29 y6HA5R239nUkArKuJ4vkea02QdLN3Nbg5UTGZm6qXucx+jO+bP5vPc1pXNW5kVPEXB6b AHIhU3HZoAwVdrhUUAFKVYJ8N/yfh5c1FhrV7EkGtNgdxUNcqCRGI6j2K1vAZWFvA+oG zw8XKUiKubIjkKhHcdXuz5nprF2D4DDS72BfQAACsm8SD0qXfqOavy/bU6R1jxQxm+OL oldg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733269385; x=1733874185; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=efxAKMGIsYtsJH1TfFadrRu53b/jP4XGduoqdQKfUDs=; b=G4O9OaBJcciYOyYN2MSS80jlzuATUaIVD4/SoaCDqRPTuYUAcJH2kgWZ7PMj72+k6x WPQv/vpeuraQhbRPvAywcnLsps6kuyS5m+tEkzdrthGcNBj0T2vJBPpOJbbdwoTJzmd3 HYJz5LFnwTyxr012y4SlozsCAoOlgiPN7Mn865vUBA7sv6iv39kxeh2iA98zVcfq1KBr I7V7E1MulLnCRMQj0fIz8mf1DDzHuB7IzoaBGk7YSm/MgU9E6U9wyXCljzRrUCQXAFqQ 5ONZ7uZ9wcJn1eF1WxUSTZgbX8DHnpWbrCsXUj1IXkSzE5/dyfsN10vpBHRyfpKqDt7Q LUwQ== X-Forwarded-Encrypted: i=1; AJvYcCW4yJ5fhXrwmxNMZFy6tn6OE/x0kwSZNAUVsxUu8hBW6IB/zPIGJN7Fy2fnLyELQiYgTclgPkEVaLA=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxbwcj/UUejHIGUlKDSGi4tAOt0D7amIKZXz2iDGwXh+ZAG+p1w NMHiDj7u+eNXlw26s4wPYDmWZkjT4DULbqTXstmftYJzNyisJH4JNPz1YAskcjRMrwXOfiGbwal bEuMS6MbO0SDkL4daN69xi2LsC10t4b3jk5pE X-Gm-Gg: ASbGncts+e914pUl15WJwurBh43uJDJSu71Sd/oZi/OneH+s92WxrdaRkFaLjLB8l0M Esi6UuoYkkcJwOOb/yWU/5GLmfpEXg0u+aSiI7nkvq9fXNrbB2ZgPNuNGCeES X-Google-Smtp-Source: AGHT+IFnoxNObCnxOJ19RTHQOfy3IS0mP97qq1D+ZXM9Cr4w6i9KeiYqycIxeXsC6V041VYgYczgtjNRhEyAzhN1RZQ= X-Received: by 2002:a05:6102:548e:b0:4af:ab78:f383 with SMTP id ada2fe7eead31-4afab78f4b5mr933855137.24.1733269384628; Tue, 03 Dec 2024 15:43:04 -0800 (PST) MIME-Version: 1.0 References: <20241203005921.1119116-1-kevinloughlin@google.com> <20241203005921.1119116-2-kevinloughlin@google.com> <24b80006-dcea-4a76-b5c8-e147d9191ed2@suse.com> <25fa8746-3b36-4d43-86cd-37aadaacdf2e@zytor.com> In-Reply-To: <25fa8746-3b36-4d43-86cd-37aadaacdf2e@zytor.com> From: Kevin Loughlin Date: Tue, 3 Dec 2024 15:42:53 -0800 Message-ID: Subject: Re: [RFC PATCH 1/2] x86, lib, xenpv: Add WBNOINVD helper functions To: Xin Li Cc: Juergen Gross , Andrew Cooper , linux-kernel@vger.kernel.org, seanjc@google.com, pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, kvm@vger.kernel.org, thomas.lendacky@amd.com, pgonda@google.com, sidtelang@google.com, mizhang@google.com, virtualization@lists.linux.dev, xen-devel@lists.xenproject.org, bcm-kernel-feedback-list@broadcom.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Dec 3, 2024 at 12:11=E2=80=AFAM Xin Li wrote: > > On 12/2/2024 10:47 PM, Juergen Gross wrote: > > P.S.: As the paravirt maintainer I would have preferred to be Cc-ed in = the > > initial patch mail. > > Looks that Kevin didn't run './scripts/get_maintainer.pl'? Woops, my bad. I somehow ended up with the full maintainer list for patch 2/2 from the script but not this one (1/2). Apologies and thanks for the heads up. I saw Juergen's patch [0] ("x86/paravirt: remove the wbinvd hook") to remove the WBINVD hook, so I'll do the same for WBNOINVD in the next version (meaning I shouldn't need to update xenpv code anymore). [0] https://lore.kernel.org/lkml/20241203071550.26487-1-jgross@suse.com/ Thanks! Kevin From xen-devel-bounces@lists.xenproject.org Wed Dec 04 08:25:07 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 08:25:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848355.1263259 (Exim 4.92) (envelope-from ) id 1tIkgs-0003d2-Bm; Wed, 04 Dec 2024 08:24:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848355.1263259; Wed, 04 Dec 2024 08:24: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 1tIkgs-0003cv-98; Wed, 04 Dec 2024 08:24:58 +0000 Received: by outflank-mailman (input) for mailman id 848355; Wed, 04 Dec 2024 08:24: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 1tIkgq-0003co-EQ for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 08:24:56 +0000 Received: from NAM02-DM3-obe.outbound.protection.outlook.com (mail-dm3nam02on20604.outbound.protection.outlook.com [2a01:111:f403:2405::604]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3c6d7a96-b219-11ef-99a3-01e77a169b0f; Wed, 04 Dec 2024 09:24:54 +0100 (CET) Received: from MN2PR06CA0004.namprd06.prod.outlook.com (2603:10b6:208:23d::9) by CY5PR12MB6647.namprd12.prod.outlook.com (2603:10b6:930:40::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.19; Wed, 4 Dec 2024 08:24:49 +0000 Received: from MN1PEPF0000ECD7.namprd02.prod.outlook.com (2603:10b6:208:23d:cafe::20) by MN2PR06CA0004.outlook.office365.com (2603:10b6:208:23d::9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.19 via Frontend Transport; Wed, 4 Dec 2024 08:24:49 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by MN1PEPF0000ECD7.mail.protection.outlook.com (10.167.242.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Wed, 4 Dec 2024 08:24:49 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Wed, 4 Dec 2024 02:24:46 -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: 3c6d7a96-b219-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qsja8VcdRQVNsKZAvfZ6m0ey5grOR/c0NxbpCOGeHQGEr8+3MTgc7Rsru9SRhKfqnataUd2efcSOFeGIKM65f7etBe+Fe41JAyvXCoiBZI5khKz7xxvDoAC76NueqptEf/ww80wvyZfhsEHOmQu+YR+hTLlm3qRFP4AEuUnNrR0SX33MsUeN/mhkxvSwyiw4gTEyKYZCdonUVQdRrTyULTPtDX+CY4fGa5ub30OaN4LxurjLvnwDxkGOfYznp8OrwaR6nceOLMewuWW+PrFia/7y663YwBtsO9JrEmNPCsU7wfcl7S85UmXymoqHogngwkb00NVdEaaFgLLgSldrzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nq011CqfPYWDc9yuGWnE6O3tXd54B0zHXUEi+oQM+2I=; b=NETLOXHn4+uajEe0jXm2eanka8QGrL/bBOcpif9QV5Ce1E7KAgCK3ucvQhBdtoO3/J/41DPTfMZ4DmcH+Mhl6uqYWMUHCuOefmKIV4t+uRtp+AiR3ruYro3f8MXWVXWRi4UErMFkmPQLInECwKuBAyOCgAcJCm+h4T3R1aAqJ2t9RJUFs3syJCsKp6R2NfvsRNYcNpkDAf1/kOoRpvBAaaooHtNru7R+EJLbOEIPQKi8ZbX90U7jjqAiayJUBdb91qErMLg9quWzeb7mpHq/VyPB0VdS4LUtNa0TZfUfebYDJRjUykYwz0AUBhMJP0sXiRjqELeK/4jHc7Olhd41Dg== 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=nq011CqfPYWDc9yuGWnE6O3tXd54B0zHXUEi+oQM+2I=; b=Ynwb6YPCJGy0siJpkD4Xf9x3qwEXs4H9g1CwzO9DKNIzGykr+iE3i2EbTHZLcqg58/i3EqMO4mL5Rg5YEDzicjf7f+dEzeQ/FalbsWF0FDO+PNofzrcHosRvridKOAZSGOvLtKyfkbiDCjB38j10H2BEF69UrsqEV0Aq7d5eHI0= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko CC: Ray Huang , Xenia Ragiadakou , Jason Andryuk , "Penny Zheng" , , Subject: [PATCH v1 0/4] xen/acpi: introduce cppc performance hypercall Date: Wed, 4 Dec 2024 16:24:26 +0800 Message-ID: <20241204082430.469092-1-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN1PEPF0000ECD7:EE_|CY5PR12MB6647:EE_ X-MS-Office365-Filtering-Correlation-Id: 247b0757-60c5-4b65-9706-08dd143d1e9d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?RVdNWUtFdkRnMG9pT2l3NTdaTU14VUNSU3hzVDNzenYyZ3ZuaWJsYmNqTFV6?= =?utf-8?B?Qm8zWEtXQWV1KzFwSzJFY2hzbFFSRnhmNG4wVk42dG1WVDZpVWwyd1JrUnNE?= =?utf-8?B?YWtGQ3ZtaCtvOXlMSlN0dGRJUTRSbHZXcmZzT0xidWk4NUdIKzdhWnNiYUo5?= =?utf-8?B?VjlEdnpuNCtVUjFtMVY4NGFQTnJHSm04TWZWeG8yckxsY2laS01SY2tULy9a?= =?utf-8?B?R081SnNjVHRlWElxVHd0MHk2b1pTZDFZZkZtSU9OelBkbUJ4UXAwVGJhZ0do?= =?utf-8?B?dGtMU3BsL0k5aVozNTFoNkNOMjhTd0pyNWJHcTI3eFFXd3g4UXNid0NlMDBX?= =?utf-8?B?U2lXYnVUSzRkdkxFU1d3TGJaZXpIV1ZHM1Q1dW54WXBiRTlGTG1jcmdUUWtM?= =?utf-8?B?RUVZR3BHMlVwWHpoK1dod0dGMzdIM05uRS81WGRQdHNqK0FQK2xMMmh3eGlm?= =?utf-8?B?N2lwMkkycVV3b0syeW1zakNQM2lFVUJPaHFmQWU5TFVNVDY4bUJxL2hZQnV5?= =?utf-8?B?d1dXSW0xSXVjZ29QQ2hGdVZLOTBSR1B0UTJBbCtRU2Q0S3hPbFNXakRUL3dP?= =?utf-8?B?YTgwMmswTXFWUnA1S1hJV3lZd0JDb0pCdVBFMHVWbHVoemV3WFdLcmlyT0RH?= =?utf-8?B?SURjMXJJOVV4MGU3cC9iK00raU1LcUZta1ZCQk00eVBqZ3ppcmRiSkFFUytW?= =?utf-8?B?VmppdkNXYWpqVGs3M2lpUzFYWFN6aXViRit3emEvTGxrOGl5c1dPZTIzNHJ5?= =?utf-8?B?MDRqeGhlVHhrRUgrT3NqUmp5czNSZ1dSYmlNaGorNC9uakpGVHpUWG5nbGJv?= =?utf-8?B?SzdveEh3b00zLys1S00zTko0MFBhalVlSEdLMnkzU2ZHcjFDaU5zemw3UEZw?= =?utf-8?B?OXM0ZEUyNUNENVo2MWJ3YXlUaGdISlFCWUJ4SE1WdUdCYldTSER4VWNheHBa?= =?utf-8?B?SERhTHZVYWd0dDdSRDF6em1rV1JZRzhuM1lHRHNuZjJnMzk2ZWxhV0s2RGdy?= =?utf-8?B?T0NjOTFJVWh2ZFhVM3RrNmx5S2RrWVZGTktEVTNiaG1UOWV1SVljRUp3Rkhw?= =?utf-8?B?UFhUUExZR2lCSHM4UGs1ZnlJVGpNS2t5REZWVGU4SWVweW1LeFZuSjdVQ1Zr?= =?utf-8?B?RFg5bHR4R0FrbTNYcWJHbTc1MG95cDlXRzNjNno0ZFVheDdiN0QrNDlnTWlL?= =?utf-8?B?T1p6UlJSeFNiTVM0Q3o1MFBBY1lZbjBnQmk4UklacTExOTZ0bGxySExBaTdN?= =?utf-8?B?U0I2bzFYcnBockpaQityUE9CVTJxd3FEd1Z3OXpkaVlnMzUyaXNHcFc4M1h3?= =?utf-8?B?M3p3dWFHZlB0VGNNQWova1h5MWRZTE5US1JJN1JQVnRJc0tVcXpCeVBsY0pz?= =?utf-8?B?aGptUEp3WEN0OGlNUTVGKzFmTnZ5UW9Mc0YxMFI3MnZETUVDZnc3dXVLemVD?= =?utf-8?B?RDRtZjBHTUc3bG1NR242ZnZMcWFOcGtBaEVvVnBHQ2x2ZE1qRzUvU3diVlRi?= =?utf-8?B?ZGcvNTZBMklSNWx0aVB3MTBkN3BTR0ptWjNuY0k0d0tjbkJEcENNYXVaeWx3?= =?utf-8?B?K0tLcExyTnlGOWpkVFg5MVVVVTVkZXpFSTU5bXQ2TzJBR2J0M3liVGkzUW1K?= =?utf-8?B?MWtQRkNMZkhESm5iQTM5cXc3TG1XeWdxanNtYzJ4V3BtNktjZmdndGtIUWls?= =?utf-8?B?Y0sxa08zYWdkRGYxTHQxREhtQk40ZDdzblNMSkdWUmJSYnZnSkxOMldJejNW?= =?utf-8?B?RkhsSHZqelVtLzErQWxJNmVEK2IxTmVoSnFFSUlZZmZxbU1wMFVMMGgyOTVJ?= =?utf-8?B?M0xlcFVRdWNHNUxWN2NBRDdiNVAwM2wrN0lGVDlIWTZkUzkxaFNMM0ZiNlZV?= =?utf-8?B?SzBZWnF4clhDeVJYY21IWGVxRjBnTHk0RzdydE9jOVJ5YTZWYW9RaGV6K1dM?= =?utf-8?B?SWZnRFBDbjFSa3lFMC9BTExvTTc1NGIwbXduWXo0T0h3alE1eUFTdFB0a3dr?= =?utf-8?B?Z1NneHBiTXB3PT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2024 08:24:49.5058 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 247b0757-60c5-4b65-9706-08dd143d1e9d 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: MN1PEPF0000ECD7.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6647 When running as Xen dom0 PVH guest, MADT table is customized and may have the "wrong" UID processor number, which is inconsistent with the UID in Processor entry in native DSDT. As a result, during ACPI boot-up for dom0, linux fails to set up proper processor logical id <-> physical id map(acpi_map_cpuid). Furthermore, It leads to that some ACPI processor feature capibility, like per-cpu cpc_desc structure, failed to be correctly stored and processed. With upstreaming "amd-pstate CPU Performance Scaling Driver"( https://lore.kernel.org/all/20241203081111.463400-1-Penny.Zheng@amd.com/) to Xen community, amd-pstate driver is supported on Xen platform. And as Xen is uncapable of parsing the ACPI dynamic table, like _CPC entry, this patch serie introduces a new sub-hypercall XEN_PM_CPPC to deliver CPPC performance capability data. This patch serie is based on commit "xen/acpi: upload power and performance related data from a PVH dom0"( https://patchwork.kernel.org/project/xen-devel/patch/20241203225338.1336-1-jason.andryuk@amd.com/), which is still under review. Penny Zheng (3): acpi/cppc: extract _cpc entry parsing logic xen/cppc: get xen-required cppc perf caps data xen/cppc: introduce cppc data upload sub-hypercall Roger Pau Monné (1): xen/acpi: upload power and performance related data from a PVH dom0 drivers/acpi/cppc_acpi.c | 206 +++++++++++++++----- drivers/xen/pcpu.c | 3 +- drivers/xen/xen-acpi-processor.c | 320 +++++++++++++++++++++++++++++-- include/acpi/cppc_acpi.h | 5 + include/acpi/processor.h | 2 + include/xen/interface/platform.h | 11 ++ include/xen/xen.h | 2 +- 7 files changed, 477 insertions(+), 72 deletions(-) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Dec 04 08:25:33 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 08:25:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848362.1263270 (Exim 4.92) (envelope-from ) id 1tIkhR-000466-KD; Wed, 04 Dec 2024 08:25:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848362.1263270; Wed, 04 Dec 2024 08:25: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 1tIkhR-00045z-Gm; Wed, 04 Dec 2024 08:25:33 +0000 Received: by outflank-mailman (input) for mailman id 848362; Wed, 04 Dec 2024 08:25: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 1tIkhQ-0003co-An for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 08:25:32 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on20614.outbound.protection.outlook.com [2a01:111:f403:2412::614]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 51a5be1a-b219-11ef-99a3-01e77a169b0f; Wed, 04 Dec 2024 09:25:30 +0100 (CET) Received: from BN0PR04CA0097.namprd04.prod.outlook.com (2603:10b6:408:ec::12) by MN0PR12MB6199.namprd12.prod.outlook.com (2603:10b6:208:3c4::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.20; Wed, 4 Dec 2024 08:25:23 +0000 Received: from MN1PEPF0000ECD8.namprd02.prod.outlook.com (2603:10b6:408:ec:cafe::7a) by BN0PR04CA0097.outlook.office365.com (2603:10b6:408:ec::12) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.19 via Frontend Transport; Wed, 4 Dec 2024 08:25:23 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by MN1PEPF0000ECD8.mail.protection.outlook.com (10.167.242.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Wed, 4 Dec 2024 08:25:23 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Wed, 4 Dec 2024 02:25:19 -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: 51a5be1a-b219-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TqtOXu+pq2kI5zk7Hg8wBrrS7VQIzoRDcs1sD9n4i3t6ub61eHNyo9EQNj7mQp4uC/0c5if7ywAVjYkgK8ves5wtGhL5BpdW4QRUx2qZUWaX9cDAzBa9Xn1A3y5uKBwW214LTFhXgr/3TmCndBymuxZuf45CYLMBXrhQZykZhWCc0CDA3ZLRaeSMREAHsFSuNa9UOCXDXUbr9Xnye+tMhwAsWjVMW8LzIw13bDKhKjEkgshVzv7BqonWW8HBqjfMrOHtPVXWawQ1pv8tryzWrlrW7GI1KgedS2Zu3nmYSsS3x0i4CrYtIg/zRSoCHmZiP6vkRKCYNj4yT/WXzcW4iQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YpP8JRBUrbaH/kvgj2naryw9SRdyb8lhDhZ/RxMRf38=; b=a1HSmDl+I/wKmpESa+gtOd0S2d90RJpggyTVksr8+D+GP3c+fV/YrOUv5ltkOALVGiOEHimQN7QAVBQu3fKZSOO0COrURDQmKKVpZ+ReGDBF8hRDeGuyA5rBwkFsVz2fpZ3sJ57hR3p7nbCU/HVlln6KsuMR0AVbJQdrWmm2rjL7/IoKQeTtLgTfC3QxyPAvMbWLGG5nTUO9upig/lKtzjeR8rEuEdc2omUP+Ir6Nyx82L6g6fO3fhZNaJZzqX95D5MC9g4ra1rrbjqMoyqzBuQTDHhO8D7c5WKF9HeQ7M/1UVPSOyMSvr3Zkh2JQOP4frH9+eaJxvt/D5R0daXG3A== 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=YpP8JRBUrbaH/kvgj2naryw9SRdyb8lhDhZ/RxMRf38=; b=5Br+IH2zMNXpbJzaIS+Hikf2VVODDT4oKib1ODhigq4CUTJrDG7wf5/Tk8TS/qFjidi3Itvc5TAAJPYyk4GCGdvYrTkwINGNJpK9nfcHZSILpStw4WM1DhGyNuiqqBWWS8sHlPAJ5+5+hV7jhLYCPXE4Xu2ferzQ/NlK87tKXTg= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko CC: Ray Huang , Xenia Ragiadakou , Jason Andryuk , "Penny Zheng" , , , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v1 1/4] xen/acpi: upload power and performance related data from a PVH dom0 Date: Wed, 4 Dec 2024 16:24:27 +0800 Message-ID: <20241204082430.469092-2-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241204082430.469092-1-Penny.Zheng@amd.com> References: <20241204082430.469092-1-Penny.Zheng@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN1PEPF0000ECD8:EE_|MN0PR12MB6199:EE_ X-MS-Office365-Filtering-Correlation-Id: 8df05f41-6062-4f14-d309-08dd143d32d8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?eTBQdTZNMXVtOFNDellFV2hPMkYyNWlGQzFMbDlLRTZmdUxtOXM3OW5Wcldl?= =?utf-8?B?QnhKZEEwNFJoRnpuR3hjalFiR2xQSnQrTjk4aUlXdm50RDcxbTJvdG5wa1NX?= =?utf-8?B?d3N3cVZNNTZZZlJFMHZ3STRJUjdxYlZVSTRiWDJsdjdrQ2RzUmFxTTIySUx3?= =?utf-8?B?OHZXK3huSVMvV0hCbWkxbHB1dDZGZGFLQldmcW5xcmVjUjRwMjNCdjg4WVdi?= =?utf-8?B?VXo1UlVFZXJtUGhmc0hJYXduZXhOcDc1c3VMRzNpVG1TUWlVRXd1M3JXNmw4?= =?utf-8?B?S2k1bjIxN1AydU8waXlMRFdvbEMxS2F5bnp6ZGc1ZjlrNVZvN3d6MHVYQ0o1?= =?utf-8?B?Mks2aGdncWlQNTVhaUxtdmJTbTEzKy9PMlpLYzRpWWhwK3ZwbHNKOFdEcjQz?= =?utf-8?B?bUJ2bkNnMVFrelNMVENWcjNVL2VVWmx0T1NzTFgzdWw4RHl0bmI5T2dqYS9w?= =?utf-8?B?c2cxcWFrbHRhK2FoQTZrZ0ZQbjFMUHlTNTd4c2pac0pSVHNDeWRobVEwRWxj?= =?utf-8?B?WXpRNjRZUGZjbU1JaUpRcmJQNGRVM3RROGRkWTZYSlllZ0g1NGZWWkkyUFlW?= =?utf-8?B?YjU5Qy9JcC9LNjYzVDBxellwSVUrN0RFQXJZODVtTmRHczduVUd5eXhwa1Bn?= =?utf-8?B?N3hYZk1xRlVQRHpLdG5IZkFJRmd3SjU1ZUNFbi9DNFJCUlBDWnByNVdYUWky?= =?utf-8?B?cjlNdjB6RWcvT2NpTEhYdG81UUF0U0R1TE9GV2czTmFzSHluWXBaaFloMElR?= =?utf-8?B?MWo0aUtUcW5NQWprN3Z2OVlwdnAyeWRqdnRiU1hmZzRGajd6ZFhGdVN6R3BU?= =?utf-8?B?aXExYXlmTE5palQxYm5IQ2hQV1BJWGpJN1pXUzlrcGNwY3lUZkk3YkV1TExY?= =?utf-8?B?UURBVXJMcWJtcFJWVENIcjVMOVBuQnZDc1I2UVVTMCtwRGc5MFdaOWVoV204?= =?utf-8?B?c2F5TnEwNXk3ckY0a212bWM5dWJtbHlWK3ZIVWFqdTROaUR6akVYRFdWcy82?= =?utf-8?B?MUVWOStOc1puUVZaSWNwcmZ6RXJXeTZQekEvTHZLcmw1SEM0aWZvbEQ5NUQ3?= =?utf-8?B?dWM0YVdOQlZqZEtnVlQ0dzJYSHFnT2tGbWE2WkYxZ2lSdjBSMzRoMnNMVHJa?= =?utf-8?B?eHB6YzV6OXplaGk3T21waHBMSFBwQmtOcHlscWpNbEgzcEQxMTJMd3NrNlpo?= =?utf-8?B?WGo5UHZlUmZUQ1paVUk2SlJkQWNJK0VyWVZ4T2czdWFUdDZWQmJUeU53Y0Vm?= =?utf-8?B?elhNaDU4RkVMUG4zTlZZTXUwKzUrbkN3WWUyUEZPSCs4NU5vN25WM3E0TUZh?= =?utf-8?B?OE96TnNtZExSczBCZkVPNTNwUjY5dThtUjFsS0hodldTSGc2T0xOdzY0L1lK?= =?utf-8?B?eFdILytPRVN3ZWt5WmVOdDhSRUw5OFJvL2YvbmFUZHNvdW11bUpMRWtlclZJ?= =?utf-8?B?VGVCTGNnTWdueEtpVktEa0ExRGlac0k5dFlrOEFpditqYWpMYlpuMTh1eFVU?= =?utf-8?B?SXQrdGxkbkZBaHlhZWljclE5MlR4dG9ZMzg1MzIvdUQ5L09uRnM4S01NRDhX?= =?utf-8?B?ZXM0djJwa2hpdWFEYklmUkVHdkRDOGtJbVZBS2QweTZsYm5IYkJMZi9vbVZJ?= =?utf-8?B?YjFzNTBwbDJBMHNNVVpNTThCcUZvSXdLSnUxWnVHT2JOSlcwczlmeFJyaHl6?= =?utf-8?B?a29ML0J4K0lsQXd1V0RtNWM2aTQwdko3d3J4WDJJL29RWFZUdHR3R0FycWVa?= =?utf-8?B?bDZlZk9XMDlaSXk0dkR5WmRraU1YSW5sVFNTVXFvYTg4WHl2WVZvRWdDS3dU?= =?utf-8?B?YXlFdW9UaG9rZE1vVjdYTGd1dnErYUdaOWtXenFjSVl2V21GdGZhY3ZJaE5L?= =?utf-8?B?R2F4ZmJTT21ML3VOS0tRVnUycGY3eWtoTk1kUFVPSCtsMituOVREemdQWVh0?= =?utf-8?Q?kuscR72bRrQut+jEwy8f7HLC2U85pH2S?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2024 08:25:23.4328 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8df05f41-6062-4f14-d309-08dd143d32d8 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: MN1PEPF0000ECD8.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6199 From: Roger Pau Monné When running as a PVH dom0 the ACPI MADT is crafted by Xen in order to report the correct numbers of vCPUs that dom0 has, so the host MADT is not provided to dom0. This creates issues when parsing the power and performance related data from ACPI dynamic tables, as the ACPI Processor UIDs found on the dynamic code are likely to not match the ones crafted by Xen in the dom0 MADT. Xen would rely on Linux having filled at least the power and performance related data of the vCPUs on the system, and would clone that information in order to setup the remaining pCPUs on the system if dom0 vCPUs < pCPUs. However when running as PVH dom0 it's likely that none of dom0 CPUs will have the power and performance data filled, and hence the Xen ACPI Processor driver needs to fetch that information by itself. In order to do so correctly, introduce a new helper to fetch the _CST data without taking into account the system capabilities from the CPUID output, as the capabilities reported to dom0 in CPUID might be different from the ones on the host. Note that the newly introduced code will only fetch the _CST, _PSS, _PPC and _PCT from a single CPU, and clone that information for all the other Processors. This won't work on an heterogeneous system with Processors having different power and performance related data between them. Signed-off-by: Roger Pau Monné Signed-off-by: Jason Andryuk --- drivers/xen/pcpu.c | 3 +- drivers/xen/xen-acpi-processor.c | 231 ++++++++++++++++++++++++++++--- include/xen/xen.h | 2 +- 3 files changed, 217 insertions(+), 19 deletions(-) diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c index c63f317e3df3..dc9f2c14bf62 100644 --- a/drivers/xen/pcpu.c +++ b/drivers/xen/pcpu.c @@ -388,7 +388,7 @@ static int __init xen_pcpu_init(void) arch_initcall(xen_pcpu_init); #ifdef CONFIG_ACPI -bool __init xen_processor_present(uint32_t acpi_id) +bool xen_processor_present(uint32_t acpi_id) { const struct pcpu *pcpu; bool online = false; @@ -403,6 +403,7 @@ bool __init xen_processor_present(uint32_t acpi_id) return online; } +EXPORT_SYMBOL_GPL(xen_processor_present); void xen_sanitize_proc_cap_bits(uint32_t *cap) { diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c index 296703939846..74dcc84b9199 100644 --- a/drivers/xen/xen-acpi-processor.c +++ b/drivers/xen/xen-acpi-processor.c @@ -48,6 +48,8 @@ static unsigned long *acpi_id_cst_present; /* Which ACPI P-State dependencies for a enumerated processor */ static struct acpi_psd_package *acpi_psd; +static bool pr_initialized; + static int push_cxx_to_hypervisor(struct acpi_processor *_pr) { struct xen_platform_op op = { @@ -172,8 +174,13 @@ static int xen_copy_psd_data(struct acpi_processor *_pr, /* 'acpi_processor_preregister_performance' does not parse if the * num_processors <= 1, but Xen still requires it. Do it manually here. + * + * Also init the field if not set, as that's possible if the physical + * CPUs on the system doesn't match the data provided in the MADT when + * running as a PVH dom0. */ - if (pdomain->num_processors <= 1) { + if (pdomain->num_processors <= 1 || + dst->shared_type == CPUFREQ_SHARED_TYPE_NONE) { if (pdomain->coord_type == DOMAIN_COORD_TYPE_SW_ALL) dst->shared_type = CPUFREQ_SHARED_TYPE_ALL; else if (pdomain->coord_type == DOMAIN_COORD_TYPE_HW_ALL) @@ -313,6 +320,155 @@ static unsigned int __init get_max_acpi_id(void) pr_debug("Max ACPI ID: %u\n", max_acpi_id); return max_acpi_id; } + +/* + * Custom version of the native acpi_processor_evaluate_cst() function, to + * avoid some sanity checks done based on the CPUID data. When running as a + * Xen domain the CPUID data provided to dom0 is not the native one, so C + * states cannot be sanity checked. Leave it to the hypervisor which is also + * the entity running the driver. + */ +static int xen_acpi_processor_evaluate_cst(acpi_handle handle, + struct acpi_processor_power *info) +{ + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL }; + union acpi_object *cst; + acpi_status status; + u64 count; + int last_index = 0; + int i, ret = 0; + + status = acpi_evaluate_object(handle, "_CST", NULL, &buffer); + if (ACPI_FAILURE(status)) { + acpi_handle_debug(handle, "No _CST\n"); + return -ENODEV; + } + + cst = buffer.pointer; + + /* There must be at least 2 elements. */ + if (!cst || cst->type != ACPI_TYPE_PACKAGE || cst->package.count < 2) { + acpi_handle_warn(handle, "Invalid _CST output\n"); + ret = -EFAULT; + goto end; + } + + count = cst->package.elements[0].integer.value; + + /* Validate the number of C-states. */ + if (count < 1 || count != cst->package.count - 1) { + acpi_handle_warn(handle, "Inconsistent _CST data\n"); + ret = -EFAULT; + goto end; + } + + for (i = 1; i <= count; i++) { + union acpi_object *element; + union acpi_object *obj; + struct acpi_power_register *reg; + struct acpi_processor_cx cx; + + /* + * If there is not enough space for all C-states, skip the + * excess ones and log a warning. + */ + if (last_index >= ACPI_PROCESSOR_MAX_POWER - 1) { + acpi_handle_warn(handle, "No room for more idle states (limit: %d)\n", + ACPI_PROCESSOR_MAX_POWER - 1); + break; + } + + memset(&cx, 0, sizeof(cx)); + + element = &cst->package.elements[i]; + if (element->type != ACPI_TYPE_PACKAGE) { + acpi_handle_info(handle, "_CST C%d type(%x) is not package, skip...\n", + i, element->type); + continue; + } + + if (element->package.count != 4) { + acpi_handle_info(handle, "_CST C%d package count(%d) is not 4, skip...\n", + i, element->package.count); + continue; + } + + obj = &element->package.elements[0]; + + if (obj->type != ACPI_TYPE_BUFFER) { + acpi_handle_info(handle, "_CST C%d package element[0] type(%x) is not buffer, skip...\n", + i, obj->type); + continue; + } + + reg = (struct acpi_power_register *)obj->buffer.pointer; + + obj = &element->package.elements[1]; + if (obj->type != ACPI_TYPE_INTEGER) { + acpi_handle_info(handle, "_CST C[%d] package element[1] type(%x) is not integer, skip...\n", + i, obj->type); + continue; + } + + cx.type = obj->integer.value; + /* + * There are known cases in which the _CST output does not + * contain C1, so if the type of the first state found is not + * C1, leave an empty slot for C1 to be filled in later. + */ + if (i == 1 && cx.type != ACPI_STATE_C1) + last_index = 1; + + cx.address = reg->address; + cx.index = last_index + 1; + + switch (reg->space_id) { + case ACPI_ADR_SPACE_FIXED_HARDWARE: + cx.entry_method = ACPI_CSTATE_FFH; + break; + + case ACPI_ADR_SPACE_SYSTEM_IO: + cx.entry_method = ACPI_CSTATE_SYSTEMIO; + break; + + default: + acpi_handle_info(handle, "_CST C%d space_id(%x) neither FIXED_HARDWARE nor SYSTEM_IO, skip...\n", + i, reg->space_id); + continue; + } + + if (cx.type == ACPI_STATE_C1) + cx.valid = 1; + + obj = &element->package.elements[2]; + if (obj->type != ACPI_TYPE_INTEGER) { + acpi_handle_info(handle, "_CST C%d package element[2] type(%x) not integer, skip...\n", + i, obj->type); + continue; + } + + cx.latency = obj->integer.value; + + obj = &element->package.elements[3]; + if (obj->type != ACPI_TYPE_INTEGER) { + acpi_handle_info(handle, "_CST C%d package element[3] type(%x) not integer, skip...\n", + i, obj->type); + continue; + } + + memcpy(&info->states[++last_index], &cx, sizeof(cx)); + } + + acpi_handle_info(handle, "Found %d idle states\n", last_index); + + info->count = last_index; + +end: + kfree(buffer.pointer); + + return ret; +} + /* * The read_acpi_id and check_acpi_ids are there to support the Xen * oddity of virtual CPUs != physical CPUs in the initial domain. @@ -331,6 +487,7 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) unsigned long long tmp; union acpi_object object = { 0 }; struct acpi_buffer buffer = { sizeof(union acpi_object), &object }; + struct acpi_buffer cst_buf = { ACPI_ALLOCATE_BUFFER, NULL }; acpi_io_address pblk = 0; status = acpi_get_type(handle, &acpi_type); @@ -354,24 +511,45 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) default: return AE_OK; } - if (invalid_phys_cpuid(acpi_get_phys_id(handle, - acpi_type == ACPI_TYPE_DEVICE, - acpi_id))) { + + if (!xen_processor_present(acpi_id)) { pr_debug("CPU with ACPI ID %u is unavailable\n", acpi_id); return AE_OK; } - /* There are more ACPI Processor objects than in x2APIC or MADT. - * This can happen with incorrect ACPI SSDT declerations. */ - if (acpi_id >= nr_acpi_bits) { - pr_debug("max acpi id %u, trying to set %u\n", - nr_acpi_bits - 1, acpi_id); - return AE_OK; - } + /* OK, There is a ACPI Processor object */ __set_bit(acpi_id, acpi_id_present); pr_debug("ACPI CPU%u w/ PBLK:0x%lx\n", acpi_id, (unsigned long)pblk); + if (!pr_initialized) { + struct acpi_processor *pr = context; + int rc, rc2; + + /* + * There's no CPU on the system that has any performance or + * power related data, initialize all the required fields by + * fetching that info here. + * + * Note such information is only fetched once, and then reused + * for all pCPUs. This won't work on heterogeneous systems + * with different Cx anb/or Px states between CPUs. + */ + + pr->handle = handle; + + rc = acpi_processor_get_performance_info(pr); + if (rc) + pr_debug("ACPI CPU%u failed to get performance data\n", + acpi_id); + rc2 = xen_acpi_processor_evaluate_cst(handle, &pr->power); + if (rc2) + pr_debug("ACPI CPU%u failed to get _CST data\n", acpi_id); + + if (!rc && !rc2) + pr_initialized = true; + } + /* It has P-state dependencies */ if (!acpi_processor_get_psd(handle, &acpi_psd[acpi_id])) { pr_debug("ACPI CPU%u w/ PST:coord_type = %llu domain = %llu\n", @@ -379,11 +557,13 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) acpi_psd[acpi_id].domain); } - status = acpi_evaluate_object(handle, "_CST", NULL, &buffer); + status = acpi_evaluate_object(handle, "_CST", NULL, &cst_buf); if (ACPI_FAILURE(status)) { if (!pblk) return AE_OK; } + kfree(cst_buf.pointer); + /* .. and it has a C-state */ __set_bit(acpi_id, acpi_id_cst_present); @@ -392,8 +572,7 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) static int check_acpi_ids(struct acpi_processor *pr_backup) { - if (!pr_backup) - return -ENODEV; + BUG_ON(!pr_backup); if (acpi_id_present && acpi_id_cst_present) /* OK, done this once .. skip to uploading */ @@ -422,8 +601,8 @@ static int check_acpi_ids(struct acpi_processor *pr_backup) acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT, ACPI_UINT32_MAX, - read_acpi_id, NULL, NULL, NULL); - acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID, read_acpi_id, NULL, NULL); + read_acpi_id, NULL, pr_backup, NULL); + acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID, read_acpi_id, pr_backup, NULL); upload: if (!bitmap_equal(acpi_id_present, acpi_ids_done, nr_acpi_bits)) { @@ -464,6 +643,7 @@ static int xen_upload_processor_pm_data(void) struct acpi_processor *pr_backup = NULL; int i; int rc = 0; + bool free_perf = false; pr_info("Uploading Xen processor PM info\n"); @@ -473,12 +653,29 @@ static int xen_upload_processor_pm_data(void) if (!_pr) continue; - if (!pr_backup) + if (!pr_backup) { pr_backup = kmemdup(_pr, sizeof(*_pr), GFP_KERNEL); + pr_initialized = true; + } (void)upload_pm_data(_pr); } + if (!pr_backup) { + pr_backup = kzalloc(sizeof(struct acpi_processor), GFP_KERNEL); + if (!pr_backup) + return -ENOMEM; + pr_backup->performance = kzalloc(sizeof(struct acpi_processor_performance), + GFP_KERNEL); + if (!pr_backup->performance) { + kfree(pr_backup); + return -ENOMEM; + } + free_perf = true; + } + rc = check_acpi_ids(pr_backup); + if (free_perf) + kfree(pr_backup->performance); kfree(pr_backup); return rc; diff --git a/include/xen/xen.h b/include/xen/xen.h index a1e5b3f18d69..6ff3e2f40803 100644 --- a/include/xen/xen.h +++ b/include/xen/xen.h @@ -81,7 +81,7 @@ static inline void xen_free_unpopulated_pages(unsigned int nr_pages, #endif #if defined(CONFIG_XEN_DOM0) && defined(CONFIG_ACPI) && defined(CONFIG_X86) -bool __init xen_processor_present(uint32_t acpi_id); +bool xen_processor_present(uint32_t acpi_id); #else #include static inline bool xen_processor_present(uint32_t acpi_id) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Dec 04 08:25:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 08:25:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848363.1263280 (Exim 4.92) (envelope-from ) id 1tIkhS-0004L6-W4; Wed, 04 Dec 2024 08:25:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848363.1263280; Wed, 04 Dec 2024 08:25: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 1tIkhS-0004Kx-RX; Wed, 04 Dec 2024 08:25:34 +0000 Received: by outflank-mailman (input) for mailman id 848363; Wed, 04 Dec 2024 08:25: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 1tIkhS-00040M-FG for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 08:25:34 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on20601.outbound.protection.outlook.com [2a01:111:f403:2413::601]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 53cfe468-b219-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 09:25:33 +0100 (CET) Received: from BN0PR10CA0020.namprd10.prod.outlook.com (2603:10b6:408:143::11) by DS7PR12MB9043.namprd12.prod.outlook.com (2603:10b6:8:db::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Wed, 4 Dec 2024 08:25:28 +0000 Received: from MN1PEPF0000ECD4.namprd02.prod.outlook.com (2603:10b6:408:143:cafe::65) by BN0PR10CA0020.outlook.office365.com (2603:10b6:408:143::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.19 via Frontend Transport; Wed, 4 Dec 2024 08:25:28 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by MN1PEPF0000ECD4.mail.protection.outlook.com (10.167.242.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Wed, 4 Dec 2024 08:25:28 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Wed, 4 Dec 2024 02:25:25 -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: 53cfe468-b219-11ef-a0d4-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=h8/1QB1y2kZxqXmuYeLVifrpUmkPMvkhNTg5Co8NqM6fKnwOexeMRIDjxQ0+aSE4UlDUqhlQ06Sd+uS90kkejzfwqNH2mi/GQm/kjJ3Iwoej94Xj7j4BbaAG2+hpGvBkyxMfcyp/zqJb45AjJiMTXnl7NrFWF81dn05S8iQumTIplvPGmU9NKARhfti6fX05BB57pLBOTiiYNnBmnr0yiCxUXMMzhmrMk+1fIP4fcJ0PLpINZ9y8MtY0BZEf1CaVB2/rrzRwow1VxJpUszxBG15WSDtd+3R2TDfdDSs5/qKdbGRc3ASP4eSWjJ3R8xgjwKPb5vHuG10vC3OdjLp5Lg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5o13Q5hSamLrZeOi0igyIZdjl2uFNvY/kr1u9WVfxZo=; b=V/w+1mmCUWfY+iFOzzUV4/lQXldBK6y1sSWdGILrChUkhKmHvZ1BIBZIYTZoOYtCVPqmy4GaLYFQucvUA+QDwuzOKFdQ31YZsRJpZhIlhw05r/Dn9Ba9R1mJWnS6nuinc+/qrBlYJ/CmJHiFtngR8mO+LYahHUscxDE/CbcigBdmk2jLpb1F1kF3MrZ9Znzv7aOzXbmYwOhCxOt1mfGOH4NUM7g9iSjW0z4EC4kW+3nWR5apyqm19Ll0smf6OCE/UWPLJIZKgZ8zJFvNSpp8ytNIV1GGh8LAPegoCaELh7sfV1dYiVHj8VHtnY9wXxoWEGL5WJaR0PCV11+bNxpQmw== 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=5o13Q5hSamLrZeOi0igyIZdjl2uFNvY/kr1u9WVfxZo=; b=VBVSyk2Jsj+zbFuut4TrHxjgnxpsvrM7zA/fKZl7eqSr7S//eiRs2ORM9kd/w3OgtmeN8zXYcQPQSpyNM0kMQmS1StTfereuS7NeNjsJdFtfQgliyvaerxz0+vx9sFbbv0UodVbFcXcet5gLmHIVbXhTcAXZFghzcg5ts4k1J7I= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko CC: Ray Huang , Xenia Ragiadakou , Jason Andryuk , "Penny Zheng" , , Subject: [PATCH v1 2/4] acpi/cppc: extract _cpc entry parsing logic Date: Wed, 4 Dec 2024 16:24:28 +0800 Message-ID: <20241204082430.469092-3-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241204082430.469092-1-Penny.Zheng@amd.com> References: <20241204082430.469092-1-Penny.Zheng@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN1PEPF0000ECD4:EE_|DS7PR12MB9043:EE_ X-MS-Office365-Filtering-Correlation-Id: dd40afde-3d90-49b2-6d79-08dd143d35be X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|82310400026|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?3sdVD9OcpAQT+jvjavi/JkEleCp4OdDAcsHB7/8sWLbjfN/yTDupX4pyl1Eq?= =?us-ascii?Q?ZcpXwxz1TglCwRMUI0UCDdD9nn6fdPNqpkhSisCEoxc7Ku9Zi+YtdUtkmpxR?= =?us-ascii?Q?t8oLBCrpnGIc3fvvKdN5Jn4yMVXkuB5S5TitU0e7R3a0mHuQzbmyQMpn7ZkD?= =?us-ascii?Q?YTqyITjh+UbQQmDtKRnuRL3aIaCAuae7zhKPIS7DDJdkHmp/jeOvLR5cIoiS?= =?us-ascii?Q?13aq5t6AkJtRllurOEyQOUA/IKba64wy6R4KZ0ZXRPDM2Iz4i8BLj2Awyvlm?= =?us-ascii?Q?iPqnTwpLdQk4o5TzZK/XWtnLpr5g6w/Y6y2OYgzXQ6QKlHk98fNOVYKKnnuf?= =?us-ascii?Q?VutHNag6c/mPY+A0l+zyibRckQwpMfpS6PwpGSfwI6tccVtHSSBrAcA0dTkY?= =?us-ascii?Q?W9hsaIMS8V47N5+i1l4npjZEBicUbi1SG+udSHeUpcfmfU4QAJvesQxxCWEW?= =?us-ascii?Q?813Io+9IDxdJShUrNZtuVgsTfb82XaBdKBSqzRdrZwljWoMhL5T+yceVINbw?= =?us-ascii?Q?wBsSHAmlqDYDgG4eJMGVqEifOnhMc0WHHTA/t2LQKKol/JJ6jF1XGJ37U8vj?= =?us-ascii?Q?tCxJNeLEczEnkxSsTsqRoU0x4emQ/fyWvZHJ+GwxoPQdqXIdbi2JFRu23HvW?= =?us-ascii?Q?RvlOBgQNLMPmTJ6kY48vNhvV21Ztn9diqvUocDJuLkXpwgEOhml4/2BjjhKk?= =?us-ascii?Q?ONb3vFpv9nlcVjPZu4LxC0REVvRqhPFYfRfl7UXJz3T+wyq1kK8vryICKAdh?= =?us-ascii?Q?yEhle7T9yObd8CiiDvgge7X69wqnYeR0JvKDHoh+VVGN3YoQqGG+TAtgTKnx?= =?us-ascii?Q?JRrJDyBFp2/sThol62Dfm74k7kb6qKX9MC9ZZY7p+1/MOohecvkZgxkSo+n8?= =?us-ascii?Q?xVN8isE7Mvbfo6U1yJ9VdG1aaUdtpLQMKBLXlHvffmP0yUv12PNyAncH+Dks?= =?us-ascii?Q?e3Z+tUOWwh9JTRKGv+mp3ivP2ZHELVSkRkXYQ2vV+l37sm8J7kfS/850kSUo?= =?us-ascii?Q?lrgHgsnJUPKkX3M3Sof6MZwFyab17WTIKafdHzZErRLyYoqtf6szU+hE6LW/?= =?us-ascii?Q?fodde2bxOxDfMeq9bnNLmrhnDSXYEv0AihJGSVk8EKMsFNScOJ5AA0RgptvP?= =?us-ascii?Q?B+PPqfvHu+0lPybv8gsn+7mmT63tM7O0gayIrlBpJA11H9McsCsOzc5F+F38?= =?us-ascii?Q?1fP2e10Zpr29gBF2AeafpBoa0mVt+4DkchGg4LtbMWQwM/9ZZ0oKJkgNWO5t?= =?us-ascii?Q?gJBVgSdcvtfMNlv7TaQmDj6tCrdTJly88dREi3QwEFV+Jna90zVv4jUeLG+m?= =?us-ascii?Q?7jIy9AcQM9RszLpimZ/jc7Hxkssdg/XAa6fkGpsw5DytOCt9TMJWZ1JvqnVb?= =?us-ascii?Q?VA9eP5d9gXsQSbBdza6PZ39EjLhKXLtLZDEeD6wFojNhWTcua16GSUOjuf6X?= =?us-ascii?Q?QkCKRvoTtVWBXY+1wszMKEnQtrHg1TQE?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2024 08:25:28.3086 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dd40afde-3d90-49b2-6d79-08dd143d35be 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: MN1PEPF0000ECD4.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB9043 When running as Xen dom0 PVH guest, MADT table is customized and may have the "wrong" UID processor number, which is inconsistent with the UID in Processor entry in native DSDT. As a result, during ACPI boot-up for dom0, linux fails to set up proper processor logical id <-> physical id map(acpi_map_cpuid). Furthermore, It leads to that some ACPI processor feature data, like per-cpu cpc_desc structure, failed to be correctly stored. In order to re-parse _CPC entry later for delivering correct data in performance hypercall, firstly, we extract parsing logic from acpi_cppc_processor_probe() and export it as a new function acpi_cppc_processor_parse(). Also, replace logical processor id with ACPI ID, to show correct print info in Xen dom0 PVH guest. Signed-off-by: Penny Zheng --- drivers/acpi/cppc_acpi.c | 95 +++++++++++++++++++++++----------------- 1 file changed, 54 insertions(+), 41 deletions(-) diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index c3fc2c05d868..40e1fce629aa 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -675,19 +675,11 @@ static int pcc_data_alloc(int pcc_ss_id) static inline void arch_init_invariance_cppc(void) { } #endif -/** - * acpi_cppc_processor_probe - Search for per CPU _CPC objects. - * @pr: Ptr to acpi_processor containing this CPU's logical ID. - * - * Return: 0 for success or negative value for err. - */ -int acpi_cppc_processor_probe(struct acpi_processor *pr) +static int acpi_cppc_processor_parse(struct acpi_processor *pr, struct cpc_desc *cpc_ptr) { struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL}; union acpi_object *out_obj, *cpc_obj; - struct cpc_desc *cpc_ptr; struct cpc_reg *gas_t; - struct device *cpu_dev; acpi_handle handle = pr->handle; unsigned int num_ent, i, cpc_rev; int pcc_subspace_id = -1; @@ -706,31 +698,24 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) status = acpi_evaluate_object_typed(handle, "_CPC", NULL, &output, ACPI_TYPE_PACKAGE); if (ACPI_FAILURE(status)) { - ret = -ENODEV; - goto out_buf_free; + return -ENODEV; } out_obj = (union acpi_object *) output.pointer; - cpc_ptr = kzalloc(sizeof(struct cpc_desc), GFP_KERNEL); - if (!cpc_ptr) { - ret = -ENOMEM; - goto out_buf_free; - } - /* First entry is NumEntries. */ cpc_obj = &out_obj->package.elements[0]; if (cpc_obj->type == ACPI_TYPE_INTEGER) { num_ent = cpc_obj->integer.value; if (num_ent <= 1) { pr_debug("Unexpected _CPC NumEntries value (%d) for CPU:%d\n", - num_ent, pr->id); - goto out_free; + num_ent, pr->acpi_id); + goto out_pointer; } } else { pr_debug("Unexpected _CPC NumEntries entry type (%d) for CPU:%d\n", - cpc_obj->type, pr->id); - goto out_free; + cpc_obj->type, pr->acpi_id); + goto out_pointer; } /* Second entry should be revision. */ @@ -739,18 +724,18 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) cpc_rev = cpc_obj->integer.value; } else { pr_debug("Unexpected _CPC Revision entry type (%d) for CPU:%d\n", - cpc_obj->type, pr->id); - goto out_free; + cpc_obj->type, pr->acpi_id); + goto out_pointer; } if (cpc_rev < CPPC_V2_REV) { pr_debug("Unsupported _CPC Revision (%d) for CPU:%d\n", cpc_rev, - pr->id); - goto out_free; + pr->acpi_id); + goto out_pointer; } /* - * Disregard _CPC if the number of entries in the return pachage is not + * Disregard _CPC if the number of entries in the return package is not * as expected, but support future revisions being proper supersets of * the v3 and only causing more entries to be returned by _CPC. */ @@ -758,8 +743,8 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) (cpc_rev == CPPC_V3_REV && num_ent != CPPC_V3_NUM_ENT) || (cpc_rev > CPPC_V3_REV && num_ent <= CPPC_V3_NUM_ENT)) { pr_debug("Unexpected number of _CPC return package entries (%d) for CPU:%d\n", - num_ent, pr->id); - goto out_free; + num_ent, pr->acpi_id); + goto out_pointer; } if (cpc_rev > CPPC_V3_REV) { num_ent = CPPC_V3_NUM_ENT; @@ -793,7 +778,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) goto out_free; } else if (pcc_subspace_id != gas_t->access_width) { pr_debug("Mismatched PCC ids in _CPC for CPU:%d\n", - pr->id); + pr->acpi_id); goto out_free; } } else if (gas_t->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) { @@ -848,7 +833,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) memcpy(&cpc_ptr->cpc_regs[i-2].cpc_entry.reg, gas_t, sizeof(*gas_t)); } else { pr_debug("Invalid entry type (%d) in _CPC for CPU:%d\n", - i, pr->id); + i, pr->acpi_id); goto out_free; } } @@ -864,6 +849,45 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) cpc_ptr->cpc_regs[i].cpc_entry.int_value = 0; } + pr_debug("Parsed _CPC entry for CPU: %d\n", pr->acpi_id); + kfree(output.pointer); + return 0; + + out_free: + /* Free all the mapped sys mem areas for this CPU */ + for (i = 2; i < cpc_ptr->num_entries; i++) { + void __iomem *addr = cpc_ptr->cpc_regs[i-2].sys_mem_vaddr; + + if (addr) + iounmap(addr); + } + out_pointer: + kfree(output.pointer); + return ret; +} + +/** + * acpi_cppc_processor_probe - Search for per CPU _CPC objects. + * @pr: Ptr to acpi_processor containing this CPU's logical ID. + * + * Return: 0 for success or negative value for err. + */ +int acpi_cppc_processor_probe(struct acpi_processor *pr) +{ + acpi_handle handle = pr->handle; + struct cpc_desc *cpc_ptr; + struct device *cpu_dev; + int pcc_subspace_id = -1; + int ret = -ENODATA; + + cpc_ptr = kzalloc(sizeof(struct cpc_desc), GFP_KERNEL); + if (!cpc_ptr) + return -ENOMEM; + + ret = acpi_cppc_processor_parse(pr, cpc_ptr); + if (ret) + goto out_free; + pcc_subspace_id = per_cpu(cpu_pcc_subspace_idx, pr->id); /* Store CPU Logical ID */ cpc_ptr->cpu_id = pr->id; @@ -907,21 +931,10 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) arch_init_invariance_cppc(); - kfree(output.pointer); return 0; out_free: - /* Free all the mapped sys mem areas for this CPU */ - for (i = 2; i < cpc_ptr->num_entries; i++) { - void __iomem *addr = cpc_ptr->cpc_regs[i-2].sys_mem_vaddr; - - if (addr) - iounmap(addr); - } kfree(cpc_ptr); - -out_buf_free: - kfree(output.pointer); return ret; } EXPORT_SYMBOL_GPL(acpi_cppc_processor_probe); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Dec 04 08:25:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 08:25:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848366.1263290 (Exim 4.92) (envelope-from ) id 1tIkhc-0004hE-7C; Wed, 04 Dec 2024 08:25:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848366.1263290; Wed, 04 Dec 2024 08:25: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 1tIkhc-0004h1-3a; Wed, 04 Dec 2024 08:25:44 +0000 Received: by outflank-mailman (input) for mailman id 848366; Wed, 04 Dec 2024 08:25: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 1tIkha-0003co-M3 for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 08:25:42 +0000 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on20624.outbound.protection.outlook.com [2a01:111:f403:2418::624]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 585847ba-b219-11ef-99a3-01e77a169b0f; Wed, 04 Dec 2024 09:25:40 +0100 (CET) Received: from BN0PR04CA0047.namprd04.prod.outlook.com (2603:10b6:408:e8::22) by CH3PR12MB8458.namprd12.prod.outlook.com (2603:10b6:610:155::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.20; Wed, 4 Dec 2024 08:25:32 +0000 Received: from MN1PEPF0000ECD6.namprd02.prod.outlook.com (2603:10b6:408:e8:cafe::3d) by BN0PR04CA0047.outlook.office365.com (2603:10b6:408:e8::22) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.18 via Frontend Transport; Wed, 4 Dec 2024 08:25:32 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by MN1PEPF0000ECD6.mail.protection.outlook.com (10.167.242.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Wed, 4 Dec 2024 08:25:32 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Wed, 4 Dec 2024 02:25:29 -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: 585847ba-b219-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eb+PYAzenKc1lzpKqcbuEwB8f4SPCjFr7Ql6X127A4L2v0WgHoPEHohMXbjt7XQW33pml9prMVDWXs+imJ042kN5tRR+JjneaLSpxhVFV2zaJmz18dYKDTAY4T5js+zyDTbSrypgfsBO2OxtnBK84NV6byoU1iCN49JKSUvxiPzyPTrmPMaFuwGRyrqXyO08zGxIaD7kauDOpYpmRBd11JvL0blOy4ReQsD+G+ejK98d/UBr7zFQXE9935gniS5WNRiVhDzmPL9/tzdd92TT4ReeLY/38+o82/l+wyL39+WHaHt4DCUSafqsG0BRYiEUHmRk/28eOHHB4z58MXoKZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fE1NdC00ImjH8qXiIUgD1CcWY2B/oXHOxHCeQUc+8NI=; b=dN27TteJ2Yvm+pXfd07viowtatKAXvb8B9H1sBBiqDgvP1JnSgYz9yimg8QzaSF48Sm9+WUTbIUFRChFL5vw+D5sPK4D0sDHo/J6sQ6yDQPDJODiwM54uK4N8y0USBJ42CphtTkGTQSeIvfyL8zRr2strslGjUMdtvUv12ChUET9javMjUUSyqj3UgE91zCXkc+wWvUjoce4Unc9KfpyW+yNwCqbKX9C0vnpI2TlhzShWn9ZzdXnvpOhWpf99H9MU8Y0BVh+9NgkaxYXjS4TWYgM7HvMNUMPVaD9PMgLI+97vxXfspDhIqT6VTuGenSu+EUFKNrLFQ7uXiKetsN5xQ== 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=fE1NdC00ImjH8qXiIUgD1CcWY2B/oXHOxHCeQUc+8NI=; b=yuroTZOHIw5tGwlycghtK1stLF1X6DutgZKSMOtB7FSgZIPxgnmtyHhagfmInclr82V/2kOh1hj2I94SlGaBRGRFf5qVTAArZdkR0KqLIlZoGCTuklnC/aRUcwVdvcOx3oOO/lMX+R96WXuW8l5M1YLA6F+2vdXu5lZql3w1pmA= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko CC: Ray Huang , Xenia Ragiadakou , Jason Andryuk , "Penny Zheng" , , Subject: [PATCH v1 3/4] xen/cppc: get xen-required cppc perf caps data Date: Wed, 4 Dec 2024 16:24:29 +0800 Message-ID: <20241204082430.469092-4-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241204082430.469092-1-Penny.Zheng@amd.com> References: <20241204082430.469092-1-Penny.Zheng@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN1PEPF0000ECD6:EE_|CH3PR12MB8458:EE_ X-MS-Office365-Filtering-Correlation-Id: d2e2623f-1505-478e-fb5a-08dd143d380f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|36860700013|82310400026; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?oa3LFcWjJMY3rTcl9SFBEpXPSmZKpxP2WN9f4GQmzoCEW6gj8S59fo7EcBF2?= =?us-ascii?Q?afDZTKgfhKxU9yq5w6LnYUcZDXoQp/pNDr+VPe9qdivpvofNYXF1ynFvBYn+?= =?us-ascii?Q?S207Lt+7YSKO6kSG6yKwnFAtDFG4hSHahotYBq3x6fnH/SxIRxYqObt3+8fk?= =?us-ascii?Q?ezOuMDNU6BppjLUmUhihE81Mri/kcXVmQli63jVo98lsnJ9nnItchTOggQ18?= =?us-ascii?Q?ehl0b/Ilo+EK8Fpg/i/g1+FqdnTALHPr9uU5HZNpR5hQZ0L8GOgmvnIAk1kH?= =?us-ascii?Q?0RpRud/eqNAtWeay26grv7ziJBMdWXBFtai3zOwQ7TZt6oBadob9HU6qYBPw?= =?us-ascii?Q?ooAOoV47VuS/lP+XxjOyEyhrDNJAkBhpXMO2wB6AoxaqWbfAfLfe9uyvV53k?= =?us-ascii?Q?4JTW49Q/lMhuKNb7cwetFfVFNlaWX2Tf6XzhTE+++CVsRkeP3dXjxsnw1Y1U?= =?us-ascii?Q?BINws9TTOxseG7c722UMwoq3W1TwgVa2V86QxhFDwi5yiJnkPSRNapdexGFE?= =?us-ascii?Q?l+mfFobQ2Nou48QZBWKKpwl6nAKSPnWeOrCy9gcYVaqwYacJ3UrxjtJAp/QG?= =?us-ascii?Q?WTY2IRckCQptyuNXr8v8NjGigKUTLgZxLCdLeP0h7AxZgwTnNw1Rw2vJf7cn?= =?us-ascii?Q?WUohhHX/jwkkeTTzc63FcTyYT8GGTZjoU3NEb58oRyhoTfzRT1Rw//Smxv9H?= =?us-ascii?Q?dAJRHpSSQcfk9iHBYMb2Z8P5QsTSU7YlTRvM5eD/Kp/g5aMx8I6PpkjSp54X?= =?us-ascii?Q?EFPEgT50KS6uPBHDL7Uw7/9jLUYeprsj+6fJOLG1WSfCTNeNdkRKq9mMkuM4?= =?us-ascii?Q?8b6ZncHuwK7D7knxaXlzOBnTWAgS6MGZ+g8cRyNm3ew5BsJp20WFcyhXqEfO?= =?us-ascii?Q?Q7rXCTYlND8ayUI9d9S1H4swsiT5/ssZ4dpTrTswkax7+240FiTXH+NlEIZm?= =?us-ascii?Q?WJicjO+4JF81x4OGXfNDOL5tjj1nQmmmtGF2Qb0je7sjevDnYvdM5Fie7WJW?= =?us-ascii?Q?ecF06+UVvdZUsTlRpVmyA6CyQm79rWx2lGhRXIP354qwKW1GR2vGwZM0+Em2?= =?us-ascii?Q?BqgxhKe+re66t79xGx+1gFiZlJmiD1PQde2pLHNuyn19QpsqYM708xhHGLuj?= =?us-ascii?Q?K30r6DU2o/g5FmJtG86Gzw2wdUGgGjqvj60TRfpQXUBUZss4ko75vhBqkc6M?= =?us-ascii?Q?jhekQukGHWDHjE+hnOzmG89bAt2TjZcv+fbtP/rupHhEegnHvOO1ItyRfC0+?= =?us-ascii?Q?Loxyr13LY53/V0t2vXCjYiUVGgmQ4G0tF+23BtCZpmeDI4uwTSUz4rf26suq?= =?us-ascii?Q?vfy6KexRxskZGuR6nCR22P0zKW05tuPA/Ct5ty7GZIAUTq+qTiY+FM+el3Qp?= =?us-ascii?Q?ss/903hFdiBDY+tLyZBM1+opEPNlOkeNEK8HidAStuVLGr7wVSn82JEZMTjJ?= =?us-ascii?Q?MkKkfX+AKM3OK8QieKQhhcoDAWiq0DL4?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(36860700013)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2024 08:25:32.1829 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d2e2623f-1505-478e-fb5a-08dd143d380f 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: MN1PEPF0000ECD6.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8458 When running as Xen dom0 PVH guest, processor logical id <-> physical id map could not be properly set up. So the original function cppc_get_perf_caps() fails to get correct cppc data for Xen ACPI processor. A new function xen_processor_get_perf_caps() is introduced to get xen-required cppc perf caps data. Also, as Xen couldn't read and process PCC-type register, this commit includes a new flag pcc_unsupported in struct acpi_processor_flags to tell whether platform supports PCC-type register. Signed-off-by: Penny Zheng --- drivers/acpi/cppc_acpi.c | 110 +++++++++++++++++++++++++++++++++++---- include/acpi/cppc_acpi.h | 5 ++ include/acpi/processor.h | 1 + 3 files changed, 105 insertions(+), 11 deletions(-) diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index 40e1fce629aa..d4780739d4a1 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -772,6 +772,15 @@ static int acpi_cppc_processor_parse(struct acpi_processor *pr, struct cpc_desc * so extract it only once. */ if (gas_t->space_id == ACPI_ADR_SPACE_PLATFORM_COMM) { + /* + * When ACPI processor represents Xen processor, PCC register type + * could not be properly read and processed right now, as logical + * processor doesn't always have 1:1 map relation to physical processor. + */ + if (pr->flags.pcc_unsupported) { + pr_debug("Unsupported PCC register type:%d\n", pr->acpi_id); + goto out_free; + } if (pcc_subspace_id < 0) { pcc_subspace_id = gas_t->access_width; if (pcc_data_alloc(pcc_subspace_id)) @@ -837,7 +846,9 @@ static int acpi_cppc_processor_parse(struct acpi_processor *pr, struct cpc_desc goto out_free; } } - per_cpu(cpu_pcc_subspace_idx, pr->id) = pcc_subspace_id; + + if (!pr->flags.pcc_unsupported) + per_cpu(cpu_pcc_subspace_idx, pr->id) = pcc_subspace_id; /* * Initialize the remaining cpc_regs as unsupported. @@ -1018,8 +1029,7 @@ int __weak cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val) static int cpc_read(int cpu, struct cpc_register_resource *reg_res, u64 *val) { void __iomem *vaddr = NULL; - int size; - int pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpu); + int size, pcc_ss_id; struct cpc_reg *reg = ®_res->cpc_entry.reg; if (reg_res->type == ACPI_TYPE_INTEGER) { @@ -1044,14 +1054,17 @@ static int cpc_read(int cpu, struct cpc_register_resource *reg_res, u64 *val) *val = val_u32; return 0; - } else if (reg->space_id == ACPI_ADR_SPACE_PLATFORM_COMM && pcc_ss_id >= 0) { - /* - * For registers in PCC space, the register size is determined - * by the bit width field; the access size is used to indicate - * the PCC subspace id. - */ - size = reg->bit_width; - vaddr = GET_PCC_VADDR(reg->address, pcc_ss_id); + } else if (reg->space_id == ACPI_ADR_SPACE_PLATFORM_COMM) { + pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpu); + if (pcc_ss_id >= 0) { + /* + * For registers in PCC space, the register size is determined + * by the bit width field; the access size is used to indicate + * the PCC subspace id. + */ + size = reg->bit_width; + vaddr = GET_PCC_VADDR(reg->address, pcc_ss_id); + } } else if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) vaddr = reg_res->sys_mem_vaddr; @@ -1282,6 +1295,81 @@ int cppc_get_epp_perf(int cpunum, u64 *epp_perf) } EXPORT_SYMBOL_GPL(cppc_get_epp_perf); + +int xen_processor_get_perf_caps(struct acpi_processor *pr, struct cppc_perf_caps *perf_caps) +{ + struct cpc_desc *cpc_ptr; + struct cpc_register_resource *highest_reg, *lowest_reg, + *lowest_non_linear_reg, *nominal_reg, + *low_freq_reg = NULL, *nom_freq_reg = NULL; + u64 high, low, nom, min_nonlinear, low_f = 0, nom_f = 0; + int ret = 0; + + cpc_ptr = kzalloc(sizeof(struct cpc_desc), GFP_KERNEL); + if (!cpc_ptr) + return -ENOMEM; + + ret = acpi_cppc_processor_parse(pr, cpc_ptr); + if (ret) + goto err; + + highest_reg = &cpc_ptr->cpc_regs[HIGHEST_PERF]; + lowest_reg = &cpc_ptr->cpc_regs[LOWEST_PERF]; + lowest_non_linear_reg = &cpc_ptr->cpc_regs[LOW_NON_LINEAR_PERF]; + nominal_reg = &cpc_ptr->cpc_regs[NOMINAL_PERF]; + low_freq_reg = &cpc_ptr->cpc_regs[LOWEST_FREQ]; + nom_freq_reg = &cpc_ptr->cpc_regs[NOMINAL_FREQ]; + + /* Are any of the regs PCC ?*/ + if (CPC_IN_PCC(highest_reg) || CPC_IN_PCC(lowest_reg) || + CPC_IN_PCC(lowest_non_linear_reg) || CPC_IN_PCC(nominal_reg) || + CPC_IN_PCC(low_freq_reg) || CPC_IN_PCC(nom_freq_reg)) { + pr_debug("Unsupported register type read for Xen Processor %d," + "highest_reg in PCC: %s, lowest_reg in PCC: %s," + "lowest_non_linear_reg in PCC: %s, nominal_reg in PCC: %s," + "low_freq_reg in PCC: %s, nom_freq_reg in PCC: %s\n", + pr->acpi_id, CPC_IN_PCC(highest_reg) ? "true" : "false", + CPC_IN_PCC(lowest_reg) ? "true" : "false", + CPC_IN_PCC(lowest_non_linear_reg) ? "true" : "false", + CPC_IN_PCC(nominal_reg) ? "true" : "false", + CPC_IN_PCC(low_freq_reg) ? "true" : "false", + CPC_IN_PCC(nom_freq_reg) ? "true" : "false"); + goto err; + } + + cpc_read(pr->acpi_id, highest_reg, &high); + perf_caps->highest_perf = high; + + cpc_read(pr->acpi_id, lowest_reg, &low); + perf_caps->lowest_perf = low; + + cpc_read(pr->acpi_id, nominal_reg, &nom); + perf_caps->nominal_perf = nom; + + cpc_read(pr->id, lowest_non_linear_reg, &min_nonlinear); + perf_caps->lowest_nonlinear_perf = min_nonlinear; + + if (!high || !low || !nom || !min_nonlinear) + pr_warn("CPPC: read zero cpc register value for Xen Processor %d" + "highest_reg: %llu, lowest_reg: %llu" + "nominal_reg: %llu, lowest_non_linear_reg: %llu\n", + pr->acpi_id, high, low, nom, min_nonlinear); + + /* Read optional lowest and nominal frequencies if present */ + if (CPC_SUPPORTED(low_freq_reg)) + cpc_read(pr->acpi_id, low_freq_reg, &low_f); + + if (CPC_SUPPORTED(nom_freq_reg)) + cpc_read(pr->acpi_id, nom_freq_reg, &nom_f); + + perf_caps->lowest_freq = low_f; + perf_caps->nominal_freq = nom_f; + + err: + kfree(cpc_ptr); + return ret; +} +EXPORT_SYMBOL_GPL(xen_processor_get_perf_caps); /** * cppc_get_perf_caps - Get a CPU's performance capabilities. * @cpunum: CPU from which to get capabilities info. diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h index 76e44e102780..2281110c00b7 100644 --- a/include/acpi/cppc_acpi.h +++ b/include/acpi/cppc_acpi.h @@ -164,6 +164,7 @@ extern int cppc_set_auto_sel(int cpu, bool enable); extern int amd_get_highest_perf(unsigned int cpu, u32 *highest_perf); extern int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator); extern int amd_detect_prefcore(bool *detected); +extern int xen_processor_get_perf_caps(struct acpi_processor *pr, struct cppc_perf_caps *perf_caps); #else /* !CONFIG_ACPI_CPPC_LIB */ static inline int cppc_get_desired_perf(int cpunum, u64 *desired_perf) { @@ -249,6 +250,10 @@ static inline int amd_detect_prefcore(bool *detected) { return -ENODEV; } +static inline int xen_processor_get_perf_caps(struct acpi_processor *pr, struct cppc_perf_caps *perf_caps) +{ + return -ENOTSUPP; +} #endif /* !CONFIG_ACPI_CPPC_LIB */ #endif /* _CPPC_ACPI_H*/ diff --git a/include/acpi/processor.h b/include/acpi/processor.h index e6f6074eadbf..18499cc11366 100644 --- a/include/acpi/processor.h +++ b/include/acpi/processor.h @@ -214,6 +214,7 @@ struct acpi_processor_flags { u8 bm_control:1; u8 bm_check:1; u8 has_cst:1; + u8 pcc_unsupported:1; u8 has_lpi:1; u8 power_setup_done:1; u8 bm_rld_set:1; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Dec 04 08:25:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 08:25:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848367.1263297 (Exim 4.92) (envelope-from ) id 1tIkhc-0004ki-Ka; Wed, 04 Dec 2024 08:25:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848367.1263297; Wed, 04 Dec 2024 08:25: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 1tIkhc-0004js-Ci; Wed, 04 Dec 2024 08:25:44 +0000 Received: by outflank-mailman (input) for mailman id 848367; Wed, 04 Dec 2024 08:25: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 1tIkha-00040M-P9 for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 08:25:42 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on20622.outbound.protection.outlook.com [2a01:111:f403:2415::622]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5988f3f9-b219-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 09:25:42 +0100 (CET) Received: from MN2PR19CA0052.namprd19.prod.outlook.com (2603:10b6:208:19b::29) by SN7PR12MB6792.namprd12.prod.outlook.com (2603:10b6:806:267::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Wed, 4 Dec 2024 08:25:35 +0000 Received: from MN1PEPF0000ECDB.namprd02.prod.outlook.com (2603:10b6:208:19b:cafe::93) by MN2PR19CA0052.outlook.office365.com (2603:10b6:208:19b::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.19 via Frontend Transport; Wed, 4 Dec 2024 08:25:35 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by MN1PEPF0000ECDB.mail.protection.outlook.com (10.167.242.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Wed, 4 Dec 2024 08:25:35 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Wed, 4 Dec 2024 02:25:32 -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: 5988f3f9-b219-11ef-a0d4-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=J9WfmQDUwN2JjN4E4Xe1ObgamQKqZc2hbEWSZPsuzl6xFm6wfxllatd0yEztip/pJ2rZipu3T1AuHd6R86isSY9yETdMMDJscCUjVa5JESyIB5l3tQQUC3kQGPGav60hZC/mnY0vWocVLzrs4nkdF4m3Ez5OEeFTWazdUaHsCc2AGsVNjrEVLt7iMRQvjPGVeDP08uNW1gQsH7ovNZmVrbJNU6hROfrXSzY+95IK8DnuVdq45xqiPXd6QX+TECk5Jv7x1PjMTyn+bhLSeBJIDxfz62lESGP63DxiqbFmxFuhuQ+KCojsa1Ba53hmhSVHKnT7B+8yOEGsWGJro++iGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=o8eXS7xLrtcql42ixed09fNk4mrAhayll7Z9u3NR5mY=; b=Jf3fz+Ov7iCH6z1V2pm03HB5OF/nsHLHHHe6qLgbeANXJ4Ui8V+/7FjFkJcBlj/BWfC3Guns/JagdTj20juu07pXZtJ4NaK6+20Z6pFfwMNVneMfSUXKrnkERpu8UiAX8k5y7KnCcf6+1oJk/Pb53NNn9Bub5Yu97bU01SYEgBeBCP8FFonhAhE6SN47GK3ACRVpxMQr47ierHDOUlSlGtd7iwf+kRvF03s2+DkKOfpXXJ766EvWCa13523nuXVxBWyVg/ZLXTFa4sCaIwpHPc3FDXL/hE8L9lvX6Kw8A6el43TLZaVreWsxT90Xlb748dzEQs0S+DURrldvWGl9AA== 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=o8eXS7xLrtcql42ixed09fNk4mrAhayll7Z9u3NR5mY=; b=IaetdHkyhWQeRWf5b5w371yj4DjpZyPBwFPyESbf96m1BYYdxFLs6+GJg648hb/oEVPBvzNUu8v9cYBu96zNlsaMtPjHi9yH6DxuMBO7FhjFQPKVwwj8TPEOcs1gcLs1bzHsbNR3IB/y1BYw4b3/XSKLP+78kuu7M0q80j+IUac= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko CC: Ray Huang , Xenia Ragiadakou , Jason Andryuk , "Penny Zheng" , , Subject: [PATCH v1 4/4] xen/cppc: introduce cppc data upload sub-hypercall Date: Wed, 4 Dec 2024 16:24:30 +0800 Message-ID: <20241204082430.469092-5-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241204082430.469092-1-Penny.Zheng@amd.com> References: <20241204082430.469092-1-Penny.Zheng@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN1PEPF0000ECDB:EE_|SN7PR12MB6792:EE_ X-MS-Office365-Filtering-Correlation-Id: 29f313d5-150c-4f40-ecbd-08dd143d3a01 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?jfiCw+Bz+ad1ip6zgK0+ATny7qg2dnuQXIh1FvIC17Qnte/x8vOY2RTnxdc/?= =?us-ascii?Q?v+T8ZATNQYTUVqCf3cWkyxdcXqU6LugnF/eYswwViUlzi2qOdO6KVkbKXPGV?= =?us-ascii?Q?hSuInLw3vGspIK4omfnXKJ6xAM1Boka+L6kBRnIIInq5RBFiGAcdIBBKBO7y?= =?us-ascii?Q?KSz69SRolceswWg5eUM1tEDWGXIDEhhJvYVEB1m/0I8SS/lI7WbnNGm52t8R?= =?us-ascii?Q?aacoAiMZqt4kOEILdLxmSfXp+wcs9Y8Mk5o4EHHT6ScZmtRZ2ZPyl+rjwi9+?= =?us-ascii?Q?gJmE3f5egtJq8FOdAf9Yrr6Ve50usEnXVcEAPUlOsiuTGy8PlO7B3XiwmbBx?= =?us-ascii?Q?bsNkGrjFODPnMJ0rf5Jm+at/hWwBaQcK9+pmvoudviXr59H7Vt8BjQjf+bUC?= =?us-ascii?Q?cjgcO9hQM3cjoGXjdwnm1/m3Zl1rPe6evxcsvzOHABxMbYNXvXYY3IKgOfpn?= =?us-ascii?Q?ITtQ7xUOOGIZIOSLVTn9fcRhHaYYFpW4VszhxfUmtveDQeDKUa8wR/VE5TW/?= =?us-ascii?Q?XtQRmceORtwT5KWfF6BS7BV27oLzEN9WBCzhIQsNxHsC9k/R0a2OWF9oawjL?= =?us-ascii?Q?Uip8MPFDWzaiY/ZDQutP6vL7fPUA5GHoj8L1vwn6jtaEI4q0ahje1uZVzwD6?= =?us-ascii?Q?gHEHLqn3AoBS2Xg5QZeQ7gImtyXrqGS77kCC/StReLP0hWq/P94jKEEnT+ut?= =?us-ascii?Q?/aG3MPfii7/wSuX38HGSsXs+CmX3kt1x7xiYN1DuyQBQ2h1vw/KVFyfcYBE2?= =?us-ascii?Q?kpxqVu08CD5+AtygtYeitlqXcp6c8oXlciQIsYoghO9MvknLfnlxcUPaXqX3?= =?us-ascii?Q?FwvJmbFkkrq0Mzp/6S1DQwlbJ/IrT7O+cGbZkF/RYaWPpC9pZ4//MhAx8S6s?= =?us-ascii?Q?6yCEaliEfhNFjhKSTrX63c7r3gCKS+sH7gqwWQVSd3ySPXE8SK+COsCMtZBy?= =?us-ascii?Q?QUzwWhk+/V/hklu0kWbdhl7T0eDIfhLlJLWK5mkPWMzYuYw0ttyptewnjTGy?= =?us-ascii?Q?s9j4EpP2ODhj9TJ6+JA+dWcovUGiabk1iXoW3loPJrFDf7lLMiGrQVL/15jU?= =?us-ascii?Q?ecFn0RBKUTF3pz4JjmilMfJsQB2nHRNGeN7PDk5OGvyfpPpHVEeJCI+7yoP6?= =?us-ascii?Q?sgLi1vrZtprHzdgjk27REr/FFf4DbjKLstUQmgXQLz/QOH1ZPdyXeZiBS4R4?= =?us-ascii?Q?FEqenAJTDrPebqmv12vu01AY5GgwKpd6Y8fMBYUSXQVQ1A8g+tZc57NtPczz?= =?us-ascii?Q?4FLPTgVNGhhufpsu/dBZymgqwnyr4n9LzBym2l6fN+rxgYpZzgFx0owp7Ttd?= =?us-ascii?Q?hn+tc/rCxr9zuk3wGIK3vqZrqyuXacRpzQWkQVCozUhq+zsDDdFDe+TYmzUU?= =?us-ascii?Q?kRG/kYvTyQ6RmxDi/8ShcPzKiUfL55fIMb1vzrnm4sLBLNqEzSB3uGl4oJ4t?= =?us-ascii?Q?EoVUC0UCS9fVMoOLA1RnXj68S2UJS90z?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2024 08:25:35.4462 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 29f313d5-150c-4f40-ecbd-08dd143d3a01 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: MN1PEPF0000ECDB.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6792 As Xen is uncapable of parsing the ACPI dynamic table, this commit introduces a new sub-hypercall XEN_PM_CPPC to deliver CPPC perf caps data. Signed-off-by: Penny Zheng --- drivers/acpi/cppc_acpi.c | 1 + drivers/xen/xen-acpi-processor.c | 89 +++++++++++++++++++++++++++++++- include/acpi/processor.h | 1 + include/xen/interface/platform.h | 11 ++++ 4 files changed, 101 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index d4780739d4a1..a30eeb0d9cb7 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -860,6 +860,7 @@ static int acpi_cppc_processor_parse(struct acpi_processor *pr, struct cpc_desc cpc_ptr->cpc_regs[i].cpc_entry.int_value = 0; } + pr->flags.has_cpc = 1; pr_debug("Parsed _CPC entry for CPU: %d\n", pr->acpi_id); kfree(output.pointer); return 0; diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c index 74dcc84b9199..9de59774eac5 100644 --- a/drivers/xen/xen-acpi-processor.c +++ b/drivers/xen/xen-acpi-processor.c @@ -25,6 +25,7 @@ #include #include #include +#include static int no_hypercall; MODULE_PARM_DESC(off, "Inhibit the hypercall."); @@ -45,8 +46,12 @@ static unsigned long *acpi_ids_done; static unsigned long *acpi_id_present; /* And if there is an _CST definition (or a PBLK) for the ACPI IDs */ static unsigned long *acpi_id_cst_present; +/* And if there is an _CPC entry for the ACPI IDs */ +static unsigned long *acpi_id_cpc_present; /* Which ACPI P-State dependencies for a enumerated processor */ static struct acpi_psd_package *acpi_psd; +/* ACPI CPPC structures for a enumerated processor */ +static struct cppc_perf_caps *acpi_cppc_data; static bool pr_initialized; @@ -208,6 +213,44 @@ static int xen_copy_pct_data(struct acpi_pct_register *pct, dst_pct->address = pct->address; return 0; } +static int push_cppc_to_hypervisor(struct acpi_processor *_pr) +{ + int ret = 0; + struct xen_platform_op op = { + .cmd = XENPF_set_processor_pminfo, + .interface_version = XENPF_INTERFACE_VERSION, + .u.set_pminfo.id = _pr->acpi_id, + .u.set_pminfo.type = XEN_PM_CPPC, + }; + struct cppc_perf_caps *cppc_perf = acpi_cppc_data + _pr->acpi_id; + + op.u.set_pminfo.cppc_data.highest_perf = cppc_perf->highest_perf; + op.u.set_pminfo.cppc_data.lowest_perf = cppc_perf->lowest_perf; + op.u.set_pminfo.cppc_data.nominal_perf = cppc_perf->nominal_perf; + op.u.set_pminfo.cppc_data.lowest_nonlinear_perf = cppc_perf->lowest_nonlinear_perf; + op.u.set_pminfo.cppc_data.lowest_freq = cppc_perf->lowest_freq; + op.u.set_pminfo.cppc_data.nominal_freq = cppc_perf->nominal_freq; + + if (!no_hypercall) + ret = HYPERVISOR_platform_op(&op); + + if (!ret) { + pr_debug("ACPI CPU%u - CPPC uploaded.\n", _pr->acpi_id); + pr_debug(" highest_perf: %d\n", cppc_perf->highest_perf); + pr_debug(" lowest_perf: %d\n", cppc_perf->lowest_perf); + pr_debug(" lowest_nonlinear_perf: %d\n", cppc_perf->lowest_nonlinear_perf); + pr_debug(" nominal_perf: %d\n", cppc_perf->nominal_perf); + pr_debug(" lowest_freq: %d Mhz\n", cppc_perf->lowest_freq); + pr_debug(" nominal_freq: %d Mhz\n", cppc_perf->nominal_freq); + } else if ((ret != -EINVAL) && (ret != -ENOSYS)) + /* EINVAL means the ACPI ID is incorrect - meaning the ACPI + * table is referencing a non-existing CPU - which can happen + * with broken ACPI tables. */ + pr_warn("(_CPC): Hypervisor error (%d) for ACPI CPU%u\n", + ret, _pr->acpi_id); + + return ret; +} static int push_pxx_to_hypervisor(struct acpi_processor *_pr) { int ret = 0; @@ -284,6 +327,9 @@ static int upload_pm_data(struct acpi_processor *_pr) if (_pr->flags.power) err = push_cxx_to_hypervisor(_pr); + if (_pr->flags.has_cpc) + err |= push_cppc_to_hypervisor(_pr); + if (_pr->performance && _pr->performance->states) err |= push_pxx_to_hypervisor(_pr); @@ -488,6 +534,7 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) union acpi_object object = { 0 }; struct acpi_buffer buffer = { sizeof(union acpi_object), &object }; struct acpi_buffer cst_buf = { ACPI_ALLOCATE_BUFFER, NULL }; + struct acpi_buffer cpc_buf = { ACPI_ALLOCATE_BUFFER, NULL }; acpi_io_address pblk = 0; status = acpi_get_type(handle, &acpi_type); @@ -567,6 +614,15 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) /* .. and it has a C-state */ __set_bit(acpi_id, acpi_id_cst_present); + status = acpi_evaluate_object(handle, "_CPC", NULL, &cpc_buf); + if (ACPI_FAILURE(status)) { + return AE_OK; + } + kfree(cpc_buf.pointer); + + /* .. and it has a _CPC entry */ + __set_bit(acpi_id, acpi_id_cpc_present); + return AE_OK; } static int check_acpi_ids(struct acpi_processor *pr_backup) @@ -574,7 +630,7 @@ static int check_acpi_ids(struct acpi_processor *pr_backup) BUG_ON(!pr_backup); - if (acpi_id_present && acpi_id_cst_present) + if (acpi_id_present && acpi_id_cst_present && acpi_id_cpc_present) /* OK, done this once .. skip to uploading */ goto upload; @@ -591,11 +647,19 @@ static int check_acpi_ids(struct acpi_processor *pr_backup) return -ENOMEM; } + acpi_id_cpc_present = bitmap_zalloc(nr_acpi_bits, GFP_KERNEL); + if (!acpi_id_cpc_present) { + bitmap_free(acpi_id_present); + bitmap_free(acpi_id_cst_present); + return -ENOMEM; + } + acpi_psd = kcalloc(nr_acpi_bits, sizeof(struct acpi_psd_package), GFP_KERNEL); if (!acpi_psd) { bitmap_free(acpi_id_present); bitmap_free(acpi_id_cst_present); + bitmap_free(acpi_id_cpc_present); return -ENOMEM; } @@ -611,6 +675,12 @@ static int check_acpi_ids(struct acpi_processor *pr_backup) pr_backup->acpi_id = i; /* Mask out C-states if there are no _CST or PBLK */ pr_backup->flags.power = test_bit(i, acpi_id_cst_present); + /* Mask out relevant flag if there are no _CPC */ + pr_backup->flags.has_cpc = test_bit(i, acpi_id_cpc_present); + if (pr_backup->flags.has_cpc) { + if (xen_processor_get_perf_caps(pr_backup, acpi_cppc_data + i)) + return -EINVAL; + } /* num_entries is non-zero if we evaluated _PSD */ if (acpi_psd[i].num_entries) { memcpy(&pr_backup->performance->domain_info, @@ -729,6 +799,15 @@ static int __init xen_acpi_processor_init(void) bitmap_free(acpi_ids_done); return -ENOMEM; } + + acpi_cppc_data = kcalloc(nr_acpi_bits, sizeof(struct cppc_perf_caps), + GFP_KERNEL); + if (!acpi_cppc_data) { + pr_debug("Memory allocation error for acpi_cppc_data\n"); + rc = -ENOMEM; + goto err1_out; + } + for_each_possible_cpu(i) { if (!zalloc_cpumask_var_node( &per_cpu_ptr(acpi_perf_data, i)->shared_cpu_map, @@ -754,6 +833,11 @@ static int __init xen_acpi_processor_init(void) rc = acpi_processor_get_performance_info(pr); if (rc) goto err_out; + + pr->flags.pcc_unsupported = true; + rc = xen_processor_get_perf_caps(pr, acpi_cppc_data + i); + if (rc) + goto err_out; } rc = xen_upload_processor_pm_data(); @@ -769,6 +853,8 @@ static int __init xen_acpi_processor_init(void) err_out: /* Freeing a NULL pointer is OK: alloc_percpu zeroes. */ + kfree(acpi_cppc_data); +err1_out: free_acpi_perf_data(); bitmap_free(acpi_ids_done); return rc; @@ -782,6 +868,7 @@ static void __exit xen_acpi_processor_exit(void) bitmap_free(acpi_id_present); bitmap_free(acpi_id_cst_present); kfree(acpi_psd); + kfree(acpi_cppc_data); for_each_possible_cpu(i) acpi_processor_unregister_performance(i); diff --git a/include/acpi/processor.h b/include/acpi/processor.h index 18499cc11366..66492f5d68a8 100644 --- a/include/acpi/processor.h +++ b/include/acpi/processor.h @@ -214,6 +214,7 @@ struct acpi_processor_flags { u8 bm_control:1; u8 bm_check:1; u8 has_cst:1; + u8 has_cpc:1; u8 pcc_unsupported:1; u8 has_lpi:1; u8 power_setup_done:1; diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h index 79a443c65ea9..e11bb9443dc0 100644 --- a/include/xen/interface/platform.h +++ b/include/xen/interface/platform.h @@ -319,6 +319,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t); #define XEN_PM_PX 1 #define XEN_PM_TX 2 #define XEN_PM_PDC 3 +#define XEN_PM_CPPC 4 /* Px sub info type */ #define XEN_PX_PCT 1 #define XEN_PX_PSS 2 @@ -384,6 +385,15 @@ struct xen_processor_px { }; DEFINE_GUEST_HANDLE_STRUCT(xen_processor_px); +struct xen_processor_cppc { + uint32_t highest_perf; + uint32_t nominal_perf; + uint32_t lowest_perf; + uint32_t lowest_nonlinear_perf; + uint32_t lowest_freq; + uint32_t nominal_freq; +}; + struct xen_psd_package { uint64_t num_entries; uint64_t revision; @@ -412,6 +422,7 @@ struct xenpf_set_processor_pminfo { struct xen_processor_power power;/* Cx: _CST/_CSD */ struct xen_processor_performance perf; /* Px: _PPC/_PCT/_PSS/_PSD */ GUEST_HANDLE(uint32_t) pdc; + struct xen_processor_cppc cppc_data; /* _CPC */ }; }; DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Dec 04 08:30:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 08:30:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848402.1263310 (Exim 4.92) (envelope-from ) id 1tIklp-00079e-7o; Wed, 04 Dec 2024 08:30:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848402.1263310; Wed, 04 Dec 2024 08:30: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 1tIklp-00079C-4j; Wed, 04 Dec 2024 08:30:05 +0000 Received: by outflank-mailman (input) for mailman id 848402; Wed, 04 Dec 2024 08:30: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 1tIkln-0006es-1k for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 08:30:03 +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 f3cee395-b219-11ef-99a3-01e77a169b0f; Wed, 04 Dec 2024 09:30:00 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-434a9f2da82so57122535e9.2 for ; Wed, 04 Dec 2024 00:30:00 -0800 (PST) Received: from ?IPV6:2003:e5:872e:b100:d3c7:e0c0:5e3b:aa1c? (p200300e5872eb100d3c7e0c05e3baa1c.dip0.t-ipconnect.de. [2003:e5:872e:b100:d3c7:e0c0:5e3b:aa1c]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-434d52a46e6sm16336835e9.30.2024.12.04.00.29.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Dec 2024 00:29: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: f3cee395-b219-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733301000; x=1733905800; 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=pOfJD/zrOUKVJSR2MgqIv5aVoUGydLMJW6+9jh64hAQ=; b=SOHvhCLDTe4lIf9tHWE/5GGXpW7+mtPcu3r1XaXBqmBblM4aqNh0/bT/fuGAotSJ7G 4WMI9lliwzaBAS8rBlvuubwAietFfotEDjieVD+QKJPp1OzFocQ9GT2lAuH1XwUWqJ8W FrucWLVKGteqr3TgZHZKjQ/LQLKNsrcvbU0Apz8Bpbqdkvc1TA2EHFT/+w7FjxZmHvFa mCBVR97Zj6o4kcYALnz6siF4Eu0cQzwQlYqSetKARBLshEmpln1Z+7ojqcD8gE2nQb8o ILrYbMvIuPi2pfY0F3ccDEOhIG4H0atWphOhbER5n+WmwMoUTVEFByEgFMeSI1FKjBja 4fnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733301000; x=1733905800; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=pOfJD/zrOUKVJSR2MgqIv5aVoUGydLMJW6+9jh64hAQ=; b=sCluij1+lZ6c8ML9V4ah4F8NtBN0+napP2LClK+RNltsjQXQhdXspF78l94fpWe7Ci LSaQQwh4NFN46hR1jv+OAFViYPjmeuKnvuhCA6a87068IlXNw9sqd2pvwQqOcPz/GC1F ulUanaB8sFNoQxYO/mJRYWml1Ydrr4aBh3HxAZdsXArRN2Lc1a2UlYWUMgnLJZEncuU+ wsTWgNdnrjyQ/gpSFhFM5mfhuMJ2bEVo6gJkoNjdQSaquY6v/YNqzWREmkdOwN8v18sO fzHRtbEwQH0eu9oCj22m4iSJZ8mTPwOsttzZ6BgzAdtQTzl9QqwwuKYhtFItjjFQNu9Q lmYA== X-Forwarded-Encrypted: i=1; AJvYcCU0WvQNLPcfTniK+C2zPZTCY7KN2JSgGPvJL76Si5Gqy+yTeREXUEVtxYs3LMPNjl8gPXnG8sISwNc=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxw0mdmc1JbOmO55/4hzdyjn27KeBvlwlgijX8/cbbi8pmsfqPJ d/I9dCdDHvKkK/UCYniSwqIxlCNnvC+4VAwB6SZ0ZSUxr6gz+y3CKfXoQKuOp5I= X-Gm-Gg: ASbGncuD9qpjz5/dtSpagPBTAaFPOAJQvWfcQ2PlsZxbpqPyQQjVXrJr4Ktp/clfZVB W/gLUSXD/tn5qZ3Pa5UnciKeUz58AajVONEwiHOg4uPpMgZ6XIimtsnMYZLnKuGz1tdL5cfZEit 8HYmG5AEWyShRVuaijJBY1R53gsNj/8qSNblQFB73X5klbE2fN+jqV56ePz22wHaSZBoFPUwaOo jn7v/tqAhHN9ITVjm4U4knP3ZP4qerXCvCY9028rLmYKp0ad7X9546VxFitCnUYePqhI4G36f+B aKQcyXSy+CuxBc+JRPqBO7/sTmldRk/y40UGtaj5zDfUiHVsNOGtbTV2xG6wBArvAJmzbQu8ugY = X-Google-Smtp-Source: AGHT+IEACGfO3lWB5Uq2l4l1xaA4Spg3axZYZCp9WlqbptvHBWTDyU1yueiLDhMFJEqm7m041Q4EyA== X-Received: by 2002:a05:600c:5121:b0:434:a169:6ff8 with SMTP id 5b1f17b1804b1-434d09b149bmr52787435e9.3.1733301000159; Wed, 04 Dec 2024 00:30:00 -0800 (PST) Message-ID: Date: Wed, 4 Dec 2024 09:29:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/4] xen/acpi: upload power and performance related data from a PVH dom0 To: Penny Zheng , Stefano Stabellini , Oleksandr Tyshchenko Cc: Ray Huang , Xenia Ragiadakou , Jason Andryuk , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20241204082430.469092-1-Penny.Zheng@amd.com> <20241204082430.469092-2-Penny.Zheng@amd.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: <20241204082430.469092-2-Penny.Zheng@amd.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------HaIIC0Wr9wOSGmDsSo9I1LnX" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------HaIIC0Wr9wOSGmDsSo9I1LnX Content-Type: multipart/mixed; boundary="------------X00g6DcFXgG6ZdTV7CoGbLcc"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Penny Zheng , Stefano Stabellini , Oleksandr Tyshchenko Cc: Ray Huang , Xenia Ragiadakou , Jason Andryuk , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Message-ID: Subject: Re: [PATCH v1 1/4] xen/acpi: upload power and performance related data from a PVH dom0 References: <20241204082430.469092-1-Penny.Zheng@amd.com> <20241204082430.469092-2-Penny.Zheng@amd.com> In-Reply-To: <20241204082430.469092-2-Penny.Zheng@amd.com> --------------X00g6DcFXgG6ZdTV7CoGbLcc Content-Type: multipart/mixed; boundary="------------2lMiSsNkJHtIfDZ5BcwEIWDT" --------------2lMiSsNkJHtIfDZ5BcwEIWDT Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDQuMTIuMjQgMDk6MjQsIFBlbm55IFpoZW5nIHdyb3RlOg0KPiBGcm9tOiBSb2dlciBQ YXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4NCj4gDQo+IFdoZW4gcnVubmluZyBh cyBhIFBWSCBkb20wIHRoZSBBQ1BJIE1BRFQgaXMgY3JhZnRlZCBieSBYZW4gaW4gb3JkZXIg dG8NCj4gcmVwb3J0IHRoZSBjb3JyZWN0IG51bWJlcnMgb2YgdkNQVXMgdGhhdCBkb20wIGhh cywgc28gdGhlIGhvc3QgTUFEVCBpcw0KPiBub3QgcHJvdmlkZWQgdG8gZG9tMC4gIFRoaXMg Y3JlYXRlcyBpc3N1ZXMgd2hlbiBwYXJzaW5nIHRoZSBwb3dlciBhbmQNCj4gcGVyZm9ybWFu Y2UgcmVsYXRlZCBkYXRhIGZyb20gQUNQSSBkeW5hbWljIHRhYmxlcywgYXMgdGhlIEFDUEkN Cj4gUHJvY2Vzc29yIFVJRHMgZm91bmQgb24gdGhlIGR5bmFtaWMgY29kZSBhcmUgbGlrZWx5 IHRvIG5vdCBtYXRjaCB0aGUNCj4gb25lcyBjcmFmdGVkIGJ5IFhlbiBpbiB0aGUgZG9tMCBN QURULg0KPiANCj4gWGVuIHdvdWxkIHJlbHkgb24gTGludXggaGF2aW5nIGZpbGxlZCBhdCBs ZWFzdCB0aGUgcG93ZXIgYW5kDQo+IHBlcmZvcm1hbmNlIHJlbGF0ZWQgZGF0YSBvZiB0aGUg dkNQVXMgb24gdGhlIHN5c3RlbSwgYW5kIHdvdWxkIGNsb25lDQo+IHRoYXQgaW5mb3JtYXRp b24gaW4gb3JkZXIgdG8gc2V0dXAgdGhlIHJlbWFpbmluZyBwQ1BVcyBvbiB0aGUgc3lzdGVt DQo+IGlmIGRvbTAgdkNQVXMgPCBwQ1BVcy4gIEhvd2V2ZXIgd2hlbiBydW5uaW5nIGFzIFBW SCBkb20wIGl0J3MgbGlrZWx5DQo+IHRoYXQgbm9uZSBvZiBkb20wIENQVXMgd2lsbCBoYXZl IHRoZSBwb3dlciBhbmQgcGVyZm9ybWFuY2UgZGF0YQ0KPiBmaWxsZWQsIGFuZCBoZW5jZSB0 aGUgWGVuIEFDUEkgUHJvY2Vzc29yIGRyaXZlciBuZWVkcyB0byBmZXRjaCB0aGF0DQo+IGlu Zm9ybWF0aW9uIGJ5IGl0c2VsZi4NCj4gDQo+IEluIG9yZGVyIHRvIGRvIHNvIGNvcnJlY3Rs eSwgaW50cm9kdWNlIGEgbmV3IGhlbHBlciB0byBmZXRjaCB0aGUgX0NTVA0KPiBkYXRhIHdp dGhvdXQgdGFraW5nIGludG8gYWNjb3VudCB0aGUgc3lzdGVtIGNhcGFiaWxpdGllcyBmcm9t IHRoZQ0KPiBDUFVJRCBvdXRwdXQsIGFzIHRoZSBjYXBhYmlsaXRpZXMgcmVwb3J0ZWQgdG8g ZG9tMCBpbiBDUFVJRCBtaWdodCBiZQ0KPiBkaWZmZXJlbnQgZnJvbSB0aGUgb25lcyBvbiB0 aGUgaG9zdC4NCj4gDQo+IE5vdGUgdGhhdCB0aGUgbmV3bHkgaW50cm9kdWNlZCBjb2RlIHdp bGwgb25seSBmZXRjaCB0aGUgX0NTVCwgX1BTUywNCj4gX1BQQyBhbmQgX1BDVCBmcm9tIGEg c2luZ2xlIENQVSwgYW5kIGNsb25lIHRoYXQgaW5mb3JtYXRpb24gZm9yIGFsbCB0aGUNCj4g b3RoZXIgUHJvY2Vzc29ycy4gIFRoaXMgd29uJ3Qgd29yayBvbiBhbiBoZXRlcm9nZW5lb3Vz IHN5c3RlbSB3aXRoDQo+IFByb2Nlc3NvcnMgaGF2aW5nIGRpZmZlcmVudCBwb3dlciBhbmQg cGVyZm9ybWFuY2UgcmVsYXRlZCBkYXRhIGJldHdlZW4NCj4gdGhlbS4NCj4gDQo+IFNpZ25l ZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPg0KPiBT aWduZWQtb2ZmLWJ5OiBKYXNvbiBBbmRyeXVrIDxqYXNvbi5hbmRyeXVrQGFtZC5jb20+DQoN CkkgdGhpbmsgdGhpcyBpcyB0aGUgVjIgdmVyc2lvbiBvZiBKYXNvbidzIHBhdGNoLCBvZiB3 aGljaCBoZSBzZW50IFYzIGp1c3QNCnllc3RlcmRheT8NCg0KUGxlYXNlIHN5bmMgd2l0aCBo aW0gaG93IHRvIHByb2NlZWQ6IGlzIGhpcyBwYXRjaCBtZWFudCB0byBiZSBhIHByZXJlcXVp c2l0ZQ0KZm9yIHlvdXIgc2VyaWVzIG9yIGEgcGFydCBvZiBpdD8NCg0KDQpKdWVyZ2VuDQo= --------------2lMiSsNkJHtIfDZ5BcwEIWDT 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----- --------------2lMiSsNkJHtIfDZ5BcwEIWDT-- --------------X00g6DcFXgG6ZdTV7CoGbLcc-- --------------HaIIC0Wr9wOSGmDsSo9I1LnX 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/Ey8FAmdQEwYFAwAAAAAACgkQsN6d1ii/Ey8a zwgAjA1lwxjNPoYBwoyZ5WCkpvCgsevWly/QBako5bZkWyeVLO/xLjIxAzckIY/hDXoMyQ7O1jgY Qr9BipOEhf/jUPUgKNonNIxVQRCcYiV0tkUbh6s7Ptqs3XVUVH99B3lobNyDSHjcRrmbNWm5JP4E mHst1xtXeHfDah4atBMay8kcxtxJF+4Fe5JHaVeGL877z/9x+B9WSj+pFLmimPbo9WAI3T1oL3CI zuVteV5fDN3q5kEH84bstfiJTjEgOg721ezxkUK9Tz8/QPY9AFYpJKw09JmEawRHkr7RU2r3Ev52 JVLAzurAM1rP94wNU9vvNVuVq6G1HVS14rcBMULuEQ== =TEQ8 -----END PGP SIGNATURE----- --------------HaIIC0Wr9wOSGmDsSo9I1LnX-- From xen-devel-bounces@lists.xenproject.org Wed Dec 04 10:02:00 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 10:02:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848456.1263323 (Exim 4.92) (envelope-from ) id 1tImCY-0002MM-PY; Wed, 04 Dec 2024 10:01:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848456.1263323; Wed, 04 Dec 2024 10:01: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 1tImCY-0002MF-MZ; Wed, 04 Dec 2024 10:01:46 +0000 Received: by outflank-mailman (input) for mailman id 848456; Wed, 04 Dec 2024 10:01: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 1tImCX-0002M7-Iu for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 10:01:45 +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 c429bae4-b226-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 11:01:44 +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 8911F2110A; Wed, 4 Dec 2024 10:01: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 3FF5F1396E; Wed, 4 Dec 2024 10:01:43 +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 T2KvDYcoUGf7dgAAD6G6ig (envelope-from ); Wed, 04 Dec 2024 10:01: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: c429bae4-b226-11ef-a0d4-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733306503; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Wg/HNt8w5jlL8bm27uvZ++dhdHsSn//5ba/0MEjaz+I=; b=j8RqdAMk0tWlZkgZKjuG5lKIWPN1GcUg47iC8LK8AtxMADB+dgMfeMqKXElGi/q408HVik eyJd1ggB9yJfLdZ6oSOec6Fuden5aVieB9PvVUq0IKfkMv0GkLi9Z/Wxh03LOY9O/Ras+h Yit7o9xIuJOQRdiTWTc2+JZrafOtR5E= Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=j8RqdAMk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733306503; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Wg/HNt8w5jlL8bm27uvZ++dhdHsSn//5ba/0MEjaz+I=; b=j8RqdAMk0tWlZkgZKjuG5lKIWPN1GcUg47iC8LK8AtxMADB+dgMfeMqKXElGi/q408HVik eyJd1ggB9yJfLdZ6oSOec6Fuden5aVieB9PvVUq0IKfkMv0GkLi9Z/Wxh03LOY9O/Ras+h Yit7o9xIuJOQRdiTWTc2+JZrafOtR5E= Message-ID: <0a7b19a0-5002-4fc5-8870-be78a2e59f3c@suse.com> Date: Wed, 4 Dec 2024 11:01:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/6] xen: add new domctl get_changed_domain To: xen-devel@lists.xenproject.org, Andrew Cooper , Jan Beulich Cc: "Daniel P. Smith" , Anthony PERARD , Julien Grall , Stefano Stabellini References: <20241023131005.32144-1-jgross@suse.com> <20241023131005.32144-4-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: <20241023131005.32144-4-jgross@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------OfHT0EmyS4QBrytCY9EMjYXJ" X-Rspamd-Queue-Id: 8911F2110A X-Spam-Score: -5.36 X-Rspamd-Action: no action X-Spamd-Result: default: False [-5.36 / 50.00]; BAYES_HAM(-3.00)[99.99%]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.15)[-0.733]; MIME_BASE64_TEXT(0.10)[]; MIME_UNKNOWN(0.10)[application/pgp-keys]; MX_GOOD(-0.01)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; ARC_NA(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; HAS_ATTACHMENT(0.00)[]; DKIM_TRACE(0.00)[suse.com:+]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo] X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Spam-Flag: NO X-Spam-Level: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------OfHT0EmyS4QBrytCY9EMjYXJ Content-Type: multipart/mixed; boundary="------------6J9EUMh5eER3o04fnjI41W0e"; protected-headers="v1" From: Juergen Gross To: xen-devel@lists.xenproject.org, Andrew Cooper , Jan Beulich Cc: "Daniel P. Smith" , Anthony PERARD , Julien Grall , Stefano Stabellini Message-ID: <0a7b19a0-5002-4fc5-8870-be78a2e59f3c@suse.com> Subject: Re: [PATCH 3/6] xen: add new domctl get_changed_domain References: <20241023131005.32144-1-jgross@suse.com> <20241023131005.32144-4-jgross@suse.com> In-Reply-To: <20241023131005.32144-4-jgross@suse.com> Autocrypt-Gossip: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------6J9EUMh5eER3o04fnjI41W0e Content-Type: multipart/mixed; boundary="------------cW4z0Ipcxa3bnUfUYLXkMhcE" --------------cW4z0Ipcxa3bnUfUYLXkMhcE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjMuMTAuMjQgMTU6MTAsIEp1ZXJnZW4gR3Jvc3Mgd3JvdGU6DQo+IEFkZCBhIG5ldyBk b21jdGwgc3ViLWZ1bmN0aW9uIHRvIGdldCBkYXRhIG9mIGEgZG9tYWluIGhhdmluZyBjaGFu Z2VkDQo+IHN0YXRlICh0aGlzIGlzIG5lZWRlZCBieSBYZW5zdG9yZSkuDQo+IA0KPiBUaGUg cmV0dXJuZWQgc3RhdGUganVzdCBjb250YWlucyB0aGUgZG9taWQsIHRoZSBkb21haW4gdW5p cXVlIGlkLA0KPiBhbmQgc29tZSBmbGFncyAoZXhpc3RpbmcsIHNodXRkb3duLCBkeWluZyku DQo+IA0KPiBJbiBvcmRlciB0byBlbmFibGUgWGVuc3RvcmUgc3R1YmRvbSBiZWluZyBidWls dCBmb3IgbXVsdGlwbGUgWGVuDQo+IHZlcnNpb25zLCBtYWtlIHRoaXMgZG9tY3RsIHN0YWJs ZS4gIEZvciBzdGFibGUgZG9tY3RscyB0aGUNCj4gaW50ZXJmYWNlX3ZlcnNpb24gaXMgc3Bl Y2lmaWMgdG8gdGhlIHJlc3BlY3RpdmUgZG9tY3RsIG9wIGFuZCBpdCBpcyBhbg0KPiBpbi9v dXQgcGFyYW1ldGVyOiBPbiBpbnB1dCB0aGUgY2FsbGVyIGlzIHNwZWNpZnlpbmcgdGhlIGRl c2lyZWQgdmVyc2lvbg0KPiBvZiB0aGUgb3AsIHdoaWxlIG9uIG91dHB1dCB0aGUgaHlwZXJ2 aXNvciB3aWxsIHJldHVybiB0aGUgdXNlZCB2ZXJzaW9uDQo+ICh0aGlzIHdpbGwgYmUgYXQg bWF4IHRoZSBjYWxsZXIgc3VwcGxpZWQgdmVyc2lvbiwgYnV0IG1pZ2h0IGJlIGxvd2VyIGlu DQo+IGNhc2UgdGhlIGh5cGVydmlzb3IgZG9lc24ndCBzdXBwb3J0IHRoaXMgdmVyc2lvbiku DQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+ DQoNCkNvdWxkIEkgcGxlYXNlIGdldCBzb21lIGZlZWRiYWNrIHJlZ2FyZGluZyB0aGUgbmV3 IHN0YWJsZSAoc3ViLSloeXBlcmNhbGw/DQoNCkknZCBfcmVhbGx5XyBsaWtlIHRvIGdldCB0 aGlzIHNlcmllcyBpbnRvIDQuMjAuDQoNCkluIHRoZSBSRkMgc2VyaWVzIEkgc3VnZ2VzdGVk IGEgbmV3IHN0YWJsZSBtYWluIGh5cGVyY2FsbCwgYnV0IHRoaXMgd2Fzbid0DQpsaWtlZCBi eSBKYW4uIFNvIEkgdXNlZCB0aGUgY3VycmVudCBhcHByb2FjaCB0byBtYWtlIGl0IGEgc3Vi LW9wIG9mIHRoZQ0KZG9tY3RsIGh5cGVyY2FsbCwgd2hpY2ggSmFuIGRpZG4ndCBsaWtlIGVp dGhlciBpbiB0aGUgY3VycmVudCBmb3JtLg0KDQpBbmRyZXcgdG9sZCBtZSBtdWx0aXBsZSB0 aW1lcywgaGUgd2FudGVkIHRvIGdpdmUgc29tZSBmZWVkYmFjaywgYnV0IGhhc24ndA0KZG9u ZSBzbyB5ZXQuDQoNCkkgdGhpbmsgdGhlcmUgYXJlIG11bHRpcGxlIG9wdGlvbnMgaG93IHRv IHByb2NlZWQsIHRoZSBmb2xsb3dpbmcgY29taW5nIHRvDQpteSBtaW5kOg0KDQoxLiBVc2Ug YSBuZXcgc3RhYmxlIGFkbWluIGh5cGVyY2FsbCwgc2ltaWxhciB0byB0aGUgUkZDIHNlcmll cyBzb21lIHRpbWUgYWdvLg0KICAgIEluIGNhc2UgdGhpcyBpcyB0aGUgcHJlZmVycmVkIG9w dGlvbiwgSSdkIHN1Z2dlc3QgdG8gbWFrZSBpdCBzaW1pbGFyIHRvDQogICAgdGhlIGN1cnJl bnQgc3lzY3RsIGh5cGVyY2FsbCwgYnV0IHdpdGhvdXQgdGhlIHZlcnNpb24gZmllbGQuIEFu eSBub3QNCiAgICBjb21wYXRpYmxlIGNoYW5nZSBvZiBhIHN1Yi1vcCB3b3VsZCBuZWVkIGEg bmV3IHN1Yi1vcCBpbnN0ZWFkLg0KDQoyLiBVc2Ugc3RhYmxlIGRvbWN0bCAoYW5kIHBvc3Np Ymx5IHN5c2N0bCBpbiB0aGUgZnV0dXJlKSBzdWItb3BzIGxpa2UgaW4gdGhpcw0KICAgIHBh dGNoLCBidXQgcG9zc2libHkgZHJvcCB0aGUgdXNlIG9mIHRoZSBpbnRlcmZhY2UgdmVyc2lv biBmaWVsZC4gQW55IG5vdA0KICAgIGNvbXBhdGlibGUgY2hhbmdlIG9mIGEgc3RhYmxlIHN1 Yi1vcCB3b3VsZCBuZWVkIGEgbmV3IHN1Yi1vcCBpbnN0ZWFkLg0KDQpJJ2xsIHNldCB0aGlz IHRvcGljIG9uIHRoZSBhZ2VuZGEgb2YgdGhlIGNvbW11bml0eSBjYWxsIHRvbW9ycm93IGlu IGNhc2UgSQ0KZG9uJ3QgZ2V0IGFueSBmZWVkYmFjayBhbGxvd2luZyB0byBwcm9jZWVkLg0K DQoNCkp1ZXJnZW4NCg== --------------cW4z0Ipcxa3bnUfUYLXkMhcE 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----- --------------cW4z0Ipcxa3bnUfUYLXkMhcE-- --------------6J9EUMh5eER3o04fnjI41W0e-- --------------OfHT0EmyS4QBrytCY9EMjYXJ 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/Ey8FAmdQKIYFAwAAAAAACgkQsN6d1ii/Ey9W gQf9EpnSiDTyvbnQW1dFm9X8r/cpqw/PiDgPOBoLPd+T09kXMVqAEXH27QApPiifAir1KZA63QJF Ko1FensB9LW2ulYVOrXLev7AeeGL0ysOM19OcGTiEVtHLypIbfjHQMJLZiqfdxuOucar7nnwdl7m oxvCezCAAbkNBKZjdTP81EIvwdOqkMgGFnsJTpeBtEjxsY1vEwnTz6Y23dg6CFFGwU5mQ2mE5qy1 OuwupSM0lV8n/IoX1h/Mjrzw5uLBglNgI2dvWhJP7nYA5nexN0pIW6EHNPDufxHQZG7pk+VcfoMK c07gs1U+VikLOC0l6E8RPMp7KT9Fx3yUYrV6RTSw4A== =mUQ5 -----END PGP SIGNATURE----- --------------OfHT0EmyS4QBrytCY9EMjYXJ-- From xen-devel-bounces@lists.xenproject.org Wed Dec 04 10:18:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 10:18:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848467.1263333 (Exim 4.92) (envelope-from ) id 1tImSJ-00043z-3x; Wed, 04 Dec 2024 10:18:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848467.1263333; Wed, 04 Dec 2024 10:18:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tImSJ-00043s-11; Wed, 04 Dec 2024 10:18:03 +0000 Received: by outflank-mailman (input) for mailman id 848467; Wed, 04 Dec 2024 10:18: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 1tImSH-00043m-EM for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 10:18:01 +0000 Received: from mail136-20.atl41.mandrillapp.com (mail136-20.atl41.mandrillapp.com [198.2.136.20]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 08d6b659-b229-11ef-99a3-01e77a169b0f; Wed, 04 Dec 2024 11:17:59 +0100 (CET) Received: from pmta11.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail136-20.atl41.mandrillapp.com (Mailchimp) with ESMTP id 4Y3D4512tqzCf9NCZ for ; Wed, 4 Dec 2024 10:17:57 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id cca75ed5ee8e488da2ef79e4b108d98f; Wed, 04 Dec 2024 10:17: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: 08d6b659-b229-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1733307477; x=1733567977; bh=PM4sxTw1TF2yB7+p5Yf7VPbis4BsQWw5t0Ce8WOdBEs=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=1e1y7qqsHsKq30EqyZM7dowpMhgXsW6O9coWflq0mm5FPwkWBd88f/XGvWdOThuc7 vF9CTwY5lQ+xL7cwsYfC06p0r4CWhogJfkYgnXjznJ8/veFYknC2IGgksK4xw3lwUk eqH3FHmLy09DW5lLVInDaY4fWPf1S1IhSo1b0gucLsXpeH2jdnK27/Uoelun5LbxFN yXDPQGCpq7BGQhUrUwvcBSQ9urFcBIGjqr3oIB2KPycwBdE+xGSToZJXxdrtEN3F1V 8GxyvhRqek0kXrrO+DIuP6agW9LKUyXNr0kMKrLGy6ELy7h3cXOn0h3xgT1zwgOTZz f31zWDMMd2Plg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1733307477; x=1733567977; i=teddy.astie@vates.tech; bh=PM4sxTw1TF2yB7+p5Yf7VPbis4BsQWw5t0Ce8WOdBEs=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=r+JjyNvdRG5X50p5yS95vjH2pjQRtdERPsZ4K8zz75bzsGii8ZHoVIRNkfEo8GXHq tlmYNW3cDnrtH2GE6IIUpoEaAqswj0nvNGiSvpRb3kBzI29Ot7Mj4/N/22Vl9AU729 /OvbJguTCpP40yFDVohaRqjeu5rDqBn5rFg2H05gSyREwEhUe2b87u3FyS+pKf3tk6 WWUa8ZabhhpltDaXTYmrp8LA/i8tFy8NGQmZKT8+r91sdkIhbxyllVwarXWubxbiqX nMwHCpAS6xRKfTJWinC7MWvhVLh7h7MSF1bRSTG+era3jtzVnNKVvgxGIbHRvWg2Vq Hx8XQoCnX/6+g== From: "Teddy Astie" Subject: =?utf-8?Q?[XEN=20PATCH]=20XSM/domctl:=20Only=20pass=20properly=20initialized=20ssidref=20to=20xsm=5Fdomctl?= X-Mailer: git-send-email 2.45.2 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1733307475753 To: xen-devel@lists.xenproject.org Cc: "Teddy Astie" , "Andrew Cooper" , "Jan Beulich" , "Julien Grall" , "Stefano Stabellini" , "Daniel P. Smith" 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.cca75ed5ee8e488da2ef79e4b108d98f?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20241204:md Date: Wed, 04 Dec 2024 10:17:57 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On XEN_DOMCTL_create_domain, we need to pass the ssidref parameter to xsm_domctl, currently, it is always passed regardless of what command we actually do (meaning that we are likely to pass garbage in !XEN_DOMCTL_create_domain). Pass ssidref from u.createdomain only for create_domain command, 0 otherwise. No functionnal change as ssidref parameter is ignored for non-XEN_DOMCTL_create_domain commands. Fixes: ee32b9b29af449d38aad0a1b3a81aaae586f5ea7 ("XSM/domctl: Fix permission checks on XEN_DOMCTL_createdomain") Signed-off-by: Teddy Astie --- xen/common/domctl.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/common/domctl.c b/xen/common/domctl.c index ea16b75910..313022fe01 100644 --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -281,6 +281,7 @@ static struct vnuma_info *vnuma_init(const struct xen_domctl_vnuma *uinfo, long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) { long ret = 0; + uint32_t ssidref = 0; /* SSIDRef only applicable for cmd == createdomain */ bool copyback = false; struct xen_domctl curop, *op = &curop; struct domain *d; @@ -295,6 +296,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) { case XEN_DOMCTL_createdomain: d = NULL; + ssidref = op->u.createdomain.ssidref; break; case XEN_DOMCTL_assign_device: @@ -322,9 +324,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) break; } - ret = xsm_domctl(XSM_OTHER, d, op->cmd, - /* SSIDRef only applicable for cmd == createdomain */ - op->u.createdomain.ssidref); + ret = xsm_domctl(XSM_OTHER, d, op->cmd, ssidref); if ( ret ) goto domctl_out_unlock_domonly; -- 2.45.2 Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Wed Dec 04 10:40:30 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 10:40:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848482.1263343 (Exim 4.92) (envelope-from ) id 1tImnv-0007vR-TB; Wed, 04 Dec 2024 10:40:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848482.1263343; Wed, 04 Dec 2024 10:40:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tImnv-0007vK-Qb; Wed, 04 Dec 2024 10:40:23 +0000 Received: by outflank-mailman (input) for mailman id 848482; Wed, 04 Dec 2024 10:40: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 1tImnu-0007vE-VL for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 10:40:22 +0000 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [2a00:1450:4864:20::62e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 28ff57ec-b22c-11ef-99a3-01e77a169b0f; Wed, 04 Dec 2024 11:40:20 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a9e44654ae3so872375866b.1 for ; Wed, 04 Dec 2024 02:40:20 -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 a640c23a62f3a-aa5997d4101sm712748766b.73.2024.12.04.02.40.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Dec 2024 02:40:20 -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: 28ff57ec-b22c-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733308820; x=1733913620; 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=oWVq6j4z997qHNScOgBh97kzZ0u6YgZyVsP/3S57X0Q=; b=BjEFHKgeP8WxJN4SWVepcXJ06OZ/TwpI3U34vvvSj8yBdnHPzDFZRLsGF/utA9snlP Me8Pl4pSM9AdpLtaJTl8rDgeAzAsCCS18O/rl/AQ/7wQtIiH6JJt262veOZizCEhGUkR ozTAa36Q6YMC4hcmfNa7v+ByILTOPazgF5uY//htcwSYJiboiXjpeeSg6eq1UP8uzGXS u5t1t1WgzCJhcJ8G+ISFoU87Sc1/+Lo/Ho2Qkq3l3qKhefZc56Ec/TezzlRh0MchwNMQ u8WPDXmPgs9jSPRgq70+ONyQdlbpSopRQMi1yxqYJRPixUTIxqGUbOSroXdkcqMfY5UV uxWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733308820; x=1733913620; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=oWVq6j4z997qHNScOgBh97kzZ0u6YgZyVsP/3S57X0Q=; b=nbEGNp/DpWxRjhy51AxZlOC9+hZml7w9xi+Ept/YRxi0JEe6vkK0KFv5iB+B/Z9XHD +7Wkes5NeClZRrU/1iG5Ij0wwB5U7/2jHZcuQykVOWLflInpyzRKl//iPGI1H+WMQcH2 Jtsp1nfBbW4anNlLMtfd0KUYwI+YkkenaDaRrzvnybsXvYhsthEE0lYFtppCx0Jde0Do Uw3pxxtReLVtpZAP/JVL9Qyxf6xgjnL6pAVOM4jwfyDHRlHEA4PX0Zk/FV6DacFXYyce szudhAeyEq/axM2qP3kgbo8uNAdCZQvHIBig9yz4rwkx2FHAsQURSjzqr2DOvO8vUfs/ SmYQ== X-Forwarded-Encrypted: i=1; AJvYcCWkI7HkqLLYJlkuZQ7TIu2vSLrBrx6Vn7u/aj1V0h1iuA8L8x/micMKjsXir2tkH6Gtu2EF95Sh/8s=@lists.xenproject.org X-Gm-Message-State: AOJu0YwAQxq7gID10PyItyoXFh6Ht6x3prxnV1jt/1bmQqlhnf5CeVQ0 ospyuFZgtoh/a6Frr4WicW7DqU2M+EtHnQyf0yB8cZVjxCpTahKtltolh91RZg== X-Gm-Gg: ASbGnct9791UW8niXnmz31zlhkXM/VjJhs6c5gKTeOfUCcROlbvindQA9rLu19RlYcA c8n/jyweNR/7rTZT9URtUeCuJ9xI1UuG5KuFholjEu3qlNYzj8bM2CvOszdmvMM/apzywyhYj+p dCvlbNlmrMQqBgltBBmMuxAqkvoJc5vfuYj4U6UzdEKcHgpc1N2no6XxWDROVl6IPHQ4YAdveej MMyBCNOM2MlWWHnFahvV5zgFnQlUikGDUs/10y5Il37Xqz9g+n/9yT0U4k4dwKJK0uMyP3UES/h 657pVsFhlegXMQaoxJytuBeBSzp5QxR7lDg= X-Google-Smtp-Source: AGHT+IHug87E0sEncEmRZlpGvAF79OUkIsA93zqP0eP/wnf8uX7lC0f2MjBxci/K7CERdSGXcsVOVA== X-Received: by 2002:a17:907:75d1:b0:aa5:31f5:922a with SMTP id a640c23a62f3a-aa5f7d22d13mr537540766b.19.1733308820349; Wed, 04 Dec 2024 02:40:20 -0800 (PST) Message-ID: <6acc7206-86b1-42fa-8106-557ffa1167f0@suse.com> Date: Wed, 4 Dec 2024 11:40:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] XSM/domctl: Only pass properly initialized ssidref to xsm_domctl To: Teddy Astie Cc: Andrew Cooper , Julien Grall , 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 04.12.2024 11:17, Teddy Astie wrote: > On XEN_DOMCTL_create_domain, we need to pass the ssidref parameter to xsm_domctl, > currently, it is always passed regardless of what command we actually do (meaning > that we are likely to pass garbage in !XEN_DOMCTL_create_domain). > > Pass ssidref from u.createdomain only for create_domain command, 0 otherwise. > No functionnal change as ssidref parameter is ignored for non-XEN_DOMCTL_create_domain > commands. And then why is this change being made? > Fixes: ee32b9b29af449d38aad0a1b3a81aaae586f5ea7 ("XSM/domctl: Fix permission checks on XEN_DOMCTL_createdomain") Please limit the hash to 12 digits. Jan From xen-devel-bounces@lists.xenproject.org Wed Dec 04 10:41:53 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 10:41:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848480.1263354 (Exim 4.92) (envelope-from ) id 1tImpM-0000Cv-9y; Wed, 04 Dec 2024 10:41:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848480.1263354; Wed, 04 Dec 2024 10:41:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tImpM-0000Cm-79; Wed, 04 Dec 2024 10:41:52 +0000 Received: by outflank-mailman (input) for mailman id 848480; Wed, 04 Dec 2024 10:37: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 1tIml5-0006yL-4y for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 10:37:27 +0000 Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [2607:f8b0:4864:20::72f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bfc33f8f-b22b-11ef-99a3-01e77a169b0f; Wed, 04 Dec 2024 11:37:24 +0100 (CET) Received: by mail-qk1-x72f.google.com with SMTP id af79cd13be357-7b65d1c707aso479571085a.0 for ; Wed, 04 Dec 2024 02:37:24 -0800 (PST) Received: from jupiter.home ([188.91.253.160]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5997ffc1bsm714073566b.83.2024.12.04.02.37.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Dec 2024 02:37: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: bfc33f8f-b22b-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exostellar.io; s=google; t=1733308644; x=1733913444; 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=UKZBElfC/runRO3THcVur0T/wfu1RwMrcL6FtcVDe5Y=; b=DFLv6mTzkrYmcRX8yAhKK8aSouQF+DnGdHTGLFq4ZzV6JZgJG03OLyVD+MO2+HrF1J O1NDKFkNiKbh+0Plr82iZsoWW3BS+8steS9t5iRdUdT21tKtwsIox42KiyJEaJdeirHO HbsyAapRn3RHu/1EgSUNmjMPTvifNszp4CB0zq6ooSiyYVj9C2htAxBT+mVaRmmaEP0R tJF/gzrjfVcARCfvMr0rUEhDti2HmlitObb9HwHqJ8rxs1D/JveMZYNGm1iyPugGtdn/ o8DZREDmNmVjYYszquOfh9n8oG8t3jfcdDAUniLt1pqKkBl0JFFDOlaZB1Y4YRE9eUd8 eX9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733308644; x=1733913444; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UKZBElfC/runRO3THcVur0T/wfu1RwMrcL6FtcVDe5Y=; b=rVn5QPOL1CJMHvROleSHwGrFnlWBqoWj6oANnEnzkOYB1+WPDMHJo/t9YW+9SlXuWm 1Bc30W+/xt4xye3ZaM0QWPpG6oUVLdsWfs1Bt6whuOrF4uJa8SjxyPVqzQgUmm65QEhI SoS+749/RG/a35V7rfbhtgBH/tnm33Ye3mEptLE4y0zApHHAzwskSQqOLdPlZBdaUJjh YDKJmxtG+eVO3w9a6s0NNUA3tQyurmhkx1BCljfoF/SGQ5uuNLXvQNMkIo+zEMe4z+K6 nXbUBMVIBrVQ2xEnBJqOK7YDPahfrSlPH6OixnyhScwk9aPKsNWk2B14GBwp+T/tvxqz xNNA== X-Forwarded-Encrypted: i=1; AJvYcCU9nmKNWIPvzPBqBadifENnBUFKPMN3DRL3JEyIvtzbTrEFQWvHwHJNdCZRTr8mUrrnUKGlEqSFcgs=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzx0/P/2QE4D2DzuakWvNgfl1idk7BU8sYfjZPR2CSUbIkw3e2n 5XlaHRHpyp5DC5DlIimazcrDQtRiokou94+YocfzGnmRCZ6OJqZU2jv/U4uHDKA= X-Gm-Gg: ASbGnctHDL1EfhWV0TlB95G1S4dSPhhksZvKFF1zWZrp8u4ovlZZpYNAQEjZZHshA0F IvUGlzX0QiMP7vnn5mSDpPozL3kccn480pvooU5QsODJ7HxdXPFXeSWk6/MmJZtkErV+ZXhzkyF wbGvMKAfbhrff6L3yTWv9CvS5qZKa9cg3K73Hw6kTkzP9JAyRXS6dR0F2uSpQi/owcnlFLPUy26 AntXvpHcG3anb9cir267ADq8LqM/eRArfDw4u7FhOUCNl7b6WNd X-Google-Smtp-Source: AGHT+IFzj1Z+lwW7ef4Zyi/r9kehnRmxvWWd7pNR8/zIhzo8RWZkM08u76l5FSHquIrCZJ6GngUFjA== X-Received: by 2002:a05:620a:1724:b0:7b1:522a:b07 with SMTP id af79cd13be357-7b6a61cc099mr1057430985a.61.1733308643628; Wed, 04 Dec 2024 02:37:23 -0800 (PST) From: Maksym Planeta To: Juergen Gross , Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" Cc: Maksym Planeta , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Subject: [PATCH] Grab mm lock before grabbing pt lock Date: Wed, 4 Dec 2024 11:35:15 +0100 Message-ID: <20241204103516.3309112-1-maksym@exostellar.io> X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Function xen_pin_page calls xen_pte_lock, which in turn grab page table lock (ptlock). When locking, xen_pte_lock expect mm->page_table_lock to be held before grabbing ptlock, but this does not happen when pinning is caused by xen_mm_pin_all. This commit addresses lockdep warning below, which shows up when suspending a Xen VM. [ 3680.658422] Freezing user space processes [ 3680.660156] Freezing user space processes completed (elapsed 0.001 seconds) [ 3680.660182] OOM killer disabled. [ 3680.660192] Freezing remaining freezable tasks [ 3680.661485] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 3680.685254] [ 3680.685265] ================================== [ 3680.685269] WARNING: Nested lock was not taken [ 3680.685274] 6.12.0+ #16 Tainted: G W [ 3680.685279] ---------------------------------- [ 3680.685283] migration/0/19 is trying to lock: [ 3680.685288] ffff88800bac33c0 (ptlock_ptr(ptdesc)#2){+.+.}-{3:3}, at: xen_pin_page+0x175/0x1d0 [ 3680.685303] [ 3680.685303] but this task is not holding: [ 3680.685308] init_mm.page_table_lock [ 3680.685311] [ 3680.685311] stack backtrace: [ 3680.685316] CPU: 0 UID: 0 PID: 19 Comm: migration/0 Tainted: G W 6.12.0+ #16 [ 3680.685324] Tainted: [W]=WARN [ 3680.685328] Stopper: multi_cpu_stop+0x0/0x120 <- __stop_cpus.constprop.0+0x8c/0xd0 [ 3680.685339] Call Trace: [ 3680.685344] [ 3680.685347] dump_stack_lvl+0x77/0xb0 [ 3680.685356] __lock_acquire+0x917/0x2310 [ 3680.685364] lock_acquire+0xce/0x2c0 [ 3680.685369] ? xen_pin_page+0x175/0x1d0 [ 3680.685373] _raw_spin_lock_nest_lock+0x2f/0x70 [ 3680.685381] ? xen_pin_page+0x175/0x1d0 [ 3680.685386] xen_pin_page+0x175/0x1d0 [ 3680.685390] ? __pfx_xen_pin_page+0x10/0x10 [ 3680.685394] __xen_pgd_walk+0x233/0x2c0 [ 3680.685401] ? stop_one_cpu+0x91/0x100 [ 3680.685405] __xen_pgd_pin+0x5d/0x250 [ 3680.685410] xen_mm_pin_all+0x70/0xa0 [ 3680.685415] xen_pv_pre_suspend+0xf/0x280 [ 3680.685420] xen_suspend+0x57/0x1a0 [ 3680.685428] multi_cpu_stop+0x6b/0x120 [ 3680.685432] ? update_cpumasks_hier+0x7c/0xa60 [ 3680.685439] ? __pfx_multi_cpu_stop+0x10/0x10 [ 3680.685443] cpu_stopper_thread+0x8c/0x140 [ 3680.685448] ? smpboot_thread_fn+0x20/0x1f0 [ 3680.685454] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 3680.685458] smpboot_thread_fn+0xed/0x1f0 [ 3680.685462] kthread+0xde/0x110 [ 3680.685467] ? __pfx_kthread+0x10/0x10 [ 3680.685471] ret_from_fork+0x2f/0x50 [ 3680.685478] ? __pfx_kthread+0x10/0x10 [ 3680.685482] ret_from_fork_asm+0x1a/0x30 [ 3680.685489] [ 3680.685491] [ 3680.685491] other info that might help us debug this: [ 3680.685497] 1 lock held by migration/0/19: [ 3680.685500] #0: ffffffff8284df38 (pgd_lock){+.+.}-{3:3}, at: xen_mm_pin_all+0x14/0xa0 [ 3680.685512] [ 3680.685512] stack backtrace: [ 3680.685518] CPU: 0 UID: 0 PID: 19 Comm: migration/0 Tainted: G W 6.12.0+ #16 [ 3680.685528] Tainted: [W]=WARN [ 3680.685531] Stopper: multi_cpu_stop+0x0/0x120 <- __stop_cpus.constprop.0+0x8c/0xd0 [ 3680.685538] Call Trace: [ 3680.685541] [ 3680.685544] dump_stack_lvl+0x77/0xb0 [ 3680.685549] __lock_acquire+0x93c/0x2310 [ 3680.685554] lock_acquire+0xce/0x2c0 [ 3680.685558] ? xen_pin_page+0x175/0x1d0 [ 3680.685562] _raw_spin_lock_nest_lock+0x2f/0x70 [ 3680.685568] ? xen_pin_page+0x175/0x1d0 [ 3680.685572] xen_pin_page+0x175/0x1d0 [ 3680.685578] ? __pfx_xen_pin_page+0x10/0x10 [ 3680.685582] __xen_pgd_walk+0x233/0x2c0 [ 3680.685588] ? stop_one_cpu+0x91/0x100 [ 3680.685592] __xen_pgd_pin+0x5d/0x250 [ 3680.685596] xen_mm_pin_all+0x70/0xa0 [ 3680.685600] xen_pv_pre_suspend+0xf/0x280 [ 3680.685607] xen_suspend+0x57/0x1a0 [ 3680.685611] multi_cpu_stop+0x6b/0x120 [ 3680.685615] ? update_cpumasks_hier+0x7c/0xa60 [ 3680.685620] ? __pfx_multi_cpu_stop+0x10/0x10 [ 3680.685625] cpu_stopper_thread+0x8c/0x140 [ 3680.685629] ? smpboot_thread_fn+0x20/0x1f0 [ 3680.685634] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 3680.685638] smpboot_thread_fn+0xed/0x1f0 [ 3680.685642] kthread+0xde/0x110 [ 3680.685645] ? __pfx_kthread+0x10/0x10 [ 3680.685649] ret_from_fork+0x2f/0x50 [ 3680.685654] ? __pfx_kthread+0x10/0x10 [ 3680.685657] ret_from_fork_asm+0x1a/0x30 [ 3680.685662] [ 3680.685267] xen:grant_table: Grant tables using version 1 layout [ 3680.685921] OOM killer enabled. [ 3680.685934] Restarting tasks ... done. Signed-off-by: Maksym Planeta --- arch/x86/xen/mmu_pv.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c index 55a4996d0c04..2c70cd35e72c 100644 --- a/arch/x86/xen/mmu_pv.c +++ b/arch/x86/xen/mmu_pv.c @@ -781,6 +781,7 @@ void xen_mm_pin_all(void) { struct page *page; + spin_lock(&init_mm.page_table_lock); spin_lock(&pgd_lock); list_for_each_entry(page, &pgd_list, lru) { @@ -791,6 +792,7 @@ void xen_mm_pin_all(void) } spin_unlock(&pgd_lock); + spin_unlock(&init_mm.page_table_lock); } static void __init xen_mark_pinned(struct mm_struct *mm, struct page *page, @@ -887,6 +889,7 @@ void xen_mm_unpin_all(void) { struct page *page; + spin_lock(&init_mm.page_table_lock); spin_lock(&pgd_lock); list_for_each_entry(page, &pgd_list, lru) { @@ -898,6 +901,7 @@ void xen_mm_unpin_all(void) } spin_unlock(&pgd_lock); + spin_unlock(&init_mm.page_table_lock); } static void xen_enter_mmap(struct mm_struct *mm) -- 2.42.0 From xen-devel-bounces@lists.xenproject.org Wed Dec 04 11:01:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 11:01:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848506.1263364 (Exim 4.92) (envelope-from ) id 1tIn7x-0003Fg-RI; Wed, 04 Dec 2024 11:01:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848506.1263364; Wed, 04 Dec 2024 11:01: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 1tIn7x-0003FZ-OB; Wed, 04 Dec 2024 11:01:05 +0000 Received: by outflank-mailman (input) for mailman id 848506; Wed, 04 Dec 2024 11:01: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 1tIn7x-0003FT-AF for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 11:01:05 +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 0d23430e-b22f-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 12:01:02 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-434a9f2da82so58500605e9.2 for ; Wed, 04 Dec 2024 03:01:02 -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-434d5273199sm20553715e9.14.2024.12.04.03.01.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Dec 2024 03:01: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: 0d23430e-b22f-11ef-a0d4-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733310062; x=1733914862; 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=K6EPxLBgH2uOPc1YMRH/qANrWmud5mKlT8E7LujwulM=; b=Ty9++cvOLd1VVmGyAVh/YbEpVYp0iIgNNL1gsjkGLLYBcsxzZmVwnSNe1Ld9xZuwIg FOM5CPxeSeYVzl+jc4nTg3n4bXLRnHmf2QbpWCS+DZWWCmNRJhBH+AfZ+NcypAUw2Xfl ThM/EGcfIQoi0ZCEeCOXXeAr7CQhbPO3af7O1Sonct/5bfE4ElN71B6dxCH23xgpN4rU OHQL42ngKhMnRgmNXmGlKLPyyFYl/Jn5i37NUBbcMy7/zc+mwqAzOAGY8ZAYkHYyA0sS unzZUbkMAqUFaNrmlSYF1q3OnNeIXGe/+JTHOGai8fZR0R9q+oLCLWVSROcOqxM5ksxs EImw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733310062; x=1733914862; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=K6EPxLBgH2uOPc1YMRH/qANrWmud5mKlT8E7LujwulM=; b=VhQCCZ7PLLPSsjtq/FaV+8fn6zxWWri/pqWJH1CNqFgTGYIATw7XfZiTIQMwwFBoWC 6puzeOUF9aC7MkDIs9v3XpzX1lv6sum9CCGVQo9dDOTpP9FgUCtBmrK+jIE9BZ1snGyJ zBIYFFNJYe6bYGSI8odqvzFs33olW2X7zSWZHVHBE60vSw44bTw3OgjENbpAcwuWKUaz jvd/571nPg+HJtfR8WJgM6hZ2fAuWWIuD2EUM7m/f2metKDCDzp5cMA78g51Mlej5X/k Bq3jm6viOOBBuwNzIKxfG4zraufuEfmhXxcs5s62EiX83eNLF40v3TtCSRqsoH7vT42P U98g== X-Forwarded-Encrypted: i=1; AJvYcCVNP/DpYPK3Ak38L8ALz3mF+BDPHY2EL7LGFCbVo77WizgAa7wtvZJ6LDa9ZzaMlIvuYcdTt+8SZfk=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxxksqg+ibFUp/TmNMMZUH9T0XZ7+lVjZ7PXtCezZPpBhmAvQkD lqt4L+POD7Mart59JmALB7aUPbu/dRYAjJtCbtJ6pr8C+0B5th6lvq6tYkwv1B4LuOuxIc7N6IQ = X-Gm-Gg: ASbGncs//vFIo+NEX2b751AlI328oLZJRHeiPZzMVY02sh4B7RnJ/t/WuvXlIY7iv+6 s44rpTSWOPQzQ8wzyEJfkZV18Vd/V+Ptu7+pUXRKpTFjNm2c0/XGV0BR7uXjZGYmaOBr2oMD4kJ uSJuQAQ6cULg8sQT53cMiza63N2CdFZBhXSt3oPkA9SxxXHKHNZeO4mwT/sKVnbT7ZyzbMJaatT GWWPmkAgPYS2PdPn5MbxusDZJ2CiyW+YPjLgCcOCzIuE4x0o2dw3QORulWUJhtpugpG8VkG0/Yf 7bL7MVXugUSh7NzV9j+iaLahBqprBHq2wtk= X-Google-Smtp-Source: AGHT+IHArLbFC3F5WAAgEgxRisITlttOdOuzaGtekx0ZU33kmpUTEX2/XDfxliwF2yImnYXNpWF1sQ== X-Received: by 2002:a05:600c:524d:b0:431:5aea:95f with SMTP id 5b1f17b1804b1-434d09ce368mr53712405e9.16.1733310062044; Wed, 04 Dec 2024 03:01:02 -0800 (PST) Message-ID: <3e4e504e-f4d4-4ac2-be66-3f32a9f31c9a@suse.com> Date: Wed, 4 Dec 2024 12:01:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Xen 4.20 Development Update [November] To: Oleksii Kurochko Cc: committers@xenproject.org, kelly.choi@cloud.com, xen-devel@lists.xenproject.org References: <20241204102035.22505-1-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: <20241204102035.22505-1-oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.12.2024 11:20, Oleksii Kurochko wrote: > === x86 === > > * Expose consistent topology to guests (v7) > - Alejandro Vallejo > - https://lore.kernel.org/xen-devel/20241021154600.11745-1-alejandro.vallejo@cloud.com/T/#m6033f95c660675039d7789d3af1ba2f292a3a69b > > * Boot modules for Hyperlaunch (v8 -> v9) > - Daniel P. Smith > - https://patchew.org/Xen/20241115131204.32135-1-dpsmith@apertussolutions.com/ > > * x86/mm: miscellaneous fixes (v2 -> v3) > - Roger Pau Monne > - https://patchew.org/Xen/20241114145715.59777-1-roger.pau@citrix.com/ This went in, didn't it? > * Address Space Isolation FPU preparations (v2) > - Alejandro Vallejo > - https://lore.kernel.org/xen-devel/20241105143310.28301-1-alejandro.vallejo@cloud.com/T/#mbca5192d7e5636ef5ea005a083e5ff28ebe6317d > > * x86/alternatives: Adjust all insn-relative fields (v2) > - Andrew Cooper > - https://lore.kernel.org/xen-devel/20241002152725.1841575-1-andrew.cooper3@citrix.com/T/#mac2deaea7e02a343210d61887486433d946ad129 > > * Support device passthrough when dom0 is PVH on Xen (v16) > - Jiqian Chen > - https://lore.kernel.org/xen-devel/20240930034250.2682265-1-Jiqian.Chen@amd.com/T/#m5d557d76f290ff5b5550c1443cab5774d397e526 Some of this went in too, I think? > * x86emul: misc additions (v5 -> v7) > - Jan Beulich > - https://patchew.org/Xen/3a25cd59-e1cb-4bfc-b868-fb11599d22f5@suse.com/ > > * x86/HVM: emulation (MMIO) improvements (v2) > - Jan Beulich > - https://lore.kernel.org/xen-devel/3294f629-f91f-4b5d-9eb0-40a34aa2ec3e@suse.com/ > > * x86: support AVX10.1 (v2) > - Jan Beulich > - https://lore.kernel.org/xen-devel/bcfea345-57c1-43d9-82b3-240b685486cc@suse.com/ In v2 the title had changed to "x86: support AVX10", dealing with a first aspect of AVX10.2 as well. I have long completed AVX10.2 work, yet there was little reason to re-post without having got any feedback. > * APX support (v?) > - Jan Beulich > - ? I think you want to remove this from the list. While I have completed work there, I'm not fancying re-basing ahead of the AVX10 work, and hence that needs to go in first anyway. Which seems unlikely enough at this point, for 4.20. > * VT-d: SATC handling; ATS: tidying (v2) > - Jan Beulich > - https://patchew.org/Xen/64b028be-2197-4951-ae5b-32f9eabfa84a@suse.com/ > > * x86: parallelize AP bring-up during boot (v1) > - Krystian Hebel > - https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.hebel@3mdeb.com/ > > * x86: memcpy() / memset() (non-)ERMS flavors plus (v3) > - Jan Beulich > - https://lore.kernel.org/xen-devel/e7314ac8-ed09-4da8-b915-09409b01fe77@suse.com/ Isn't this the same as ... > * x86/spec-ctrl: IBPB improvements (v4) > - Jan Beulich > - https://patchew.org/Xen/06591b64-2f05-a4cc-a2f3-a74c3c4a76d6@suse.com/ > > * Move some boot code from assembly to C (v2) > - Frediano Ziglio > - https://patchew.org/Xen/20241122093358.478774-1-frediano.ziglio@cloud.com/ > > * Hyperlaunch device tree for dom0 (v1) > - Daniel P. Smith > - https://patchew.org/Xen/20241123182044.30687-1-dpsmith@apertussolutions.com/ > > * x86: memcpy() / memset() (non-)ERMS flavors plus fallout (v3) > - Jan Beulich > - https://patchew.org/Xen/e7314ac8-ed09-4da8-b915-09409b01fe77@suse.com/ ... this? > * amd-pstate CPU Performance Scaling Driver (v1) > - Penny Zheng > - https://patchew.org/Xen/20241203081111.463400-1-Penny.Zheng@amd.com/ This series was posted only this week, and upon asking it was clarified that it's indeed not aiming at 4.20. Jan From xen-devel-bounces@lists.xenproject.org Wed Dec 04 11:10:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 11:10:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848517.1263374 (Exim 4.92) (envelope-from ) id 1tInGz-0004x1-M4; Wed, 04 Dec 2024 11:10:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848517.1263374; Wed, 04 Dec 2024 11:10:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tInGz-0004wu-It; Wed, 04 Dec 2024 11:10:25 +0000 Received: by outflank-mailman (input) for mailman id 848517; Wed, 04 Dec 2024 11:10: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 1tInGy-0004wo-V8 for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 11:10:24 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5bb345f9-b230-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 12:10:24 +0100 (CET) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-aa51bf95ce1so475547866b.3 for ; Wed, 04 Dec 2024 03:10: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 a640c23a62f3a-aa5996c19c0sm726507966b.23.2024.12.04.03.10.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Dec 2024 03:10: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: 5bb345f9-b230-11ef-a0d4-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733310623; x=1733915423; 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=nj7CgqAAQQhNHgK0hte7ZaiQHV8FhEfQVmCLQVxteIQ=; b=gkgj05vUx8zaX/JhP0LqWpj6Ly5JJgGp/phokpUS5k+EloaxC6DqoFPiFE/nby/pYK +iKBgx0saVJWd9Gxkt8xtWiP5XgBtXSXeV6NDt2ixvVF5lhrvlRQ0dCt7K7LrqAhtCJD 1ONY5LeL6gbdi02Ww/6rUS9aK0h5NCj8Q/kCuyOyg5wO5qCV79Z0weG2TIdM+CiaNRxL hUlGEL12KWz1YA+N14oGSvcvgKENlBWP4q77lTPVsZx//XRNvF9pV9nG0U9p3fU8RNLJ 7GEMB/lFHpRFBknKGKvqTS6BGWc0QtrRxFojoB9/TJ3RJT9llGugQ00vN7uJLxxXmLkZ 9KKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733310623; x=1733915423; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nj7CgqAAQQhNHgK0hte7ZaiQHV8FhEfQVmCLQVxteIQ=; b=GnTW5OISkSKct6BLqSJF+wudTIvAaVQeRtg9LcKsFnWeiR3ia4zdP/hs6b741HNe9e V+ar/ULBPHqshBYYVgYE/EO/Mt/gh52Q0SXv716csGIRSKob96z8nOE4uj7pDLIN2Ai6 ddpv9RU9iCDUwNZOgQRRVBUQAArVsYl9u8MrGroHZ+M9Idq+gv9173EhFx99WY2Z8Niz LFG/THBhypynZ8nfizBwnpMjX5Fd+nt5lwqbrmkAazFdHbukTWbmr+5SPwOoX1AdbJHA pDmCg9G+Wq7bxq7jiVYYth0B/DX3icJzCltSPH9va23Tno8rfaozxY4crbU85TA5+QDv 1fBw== X-Forwarded-Encrypted: i=1; AJvYcCUFPU9Mry3lmyuQEnMOKMDQQ47K8TlZl9L/vEtnf1YB6c9FlkFF/qWJToJ8nd2JpgcsW2zykQdAzXg=@lists.xenproject.org X-Gm-Message-State: AOJu0YyxTVPKsNGMxAT/P/JsTq01paM56I2nnOLx0VwlHkbif0JCjPwO n9kDy5RAtd34xlHXN8Ea/qwujYeDJEMpUuA9W14MDNoQh0OvCMAD6IgRnmZyyQ== X-Gm-Gg: ASbGncsk6aTy9CdmwbPP4DrCqropRpzOor3uw3IW/Uod+yGa6u+ejJUCFd+t/NwqQOm oZlghNdBr0LE+83Q1AFdr+VxxICZRKYgz17u/W6KH3ZUYR0wrLiYHjTd93oUnKhWIO8kSotOqyu +l8wz4pT5rwEeM9RKy++VBCmSEisE1hBPHBTBbsPVyROcPnboUlq31iFuyh549Lqx7Ntk9Xsd5S ElZjo9Sp1MOgCPzy7FyBMBwP8m1raIc0mVpTWnfwfM5WX8ohlfP0IwEWLWhRxtx6xGeC+m182iU 7uhXViHuXWKmlOi0bggcVX9ea/0s96ufVyM= X-Google-Smtp-Source: AGHT+IGIihWtD8bmSHjj/ucBs5sXCWXky+VH2kSnATRJOI8gu1qj7r/4LD0UEnZcGwbsOwNrj8ZDmQ== X-Received: by 2002:a17:907:7758:b0:aa5:630d:7de0 with SMTP id a640c23a62f3a-aa6018d8978mr408893866b.44.1733310623459; Wed, 04 Dec 2024 03:10:23 -0800 (PST) Message-ID: <12fcd5dd-5d01-465b-bbaa-4e7e2f598727@suse.com> Date: Wed, 4 Dec 2024 12:10:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v2] x86/hvm: Use constants for x86 modes To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Paul Durrant , 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 02.12.2024 10:49, Teddy Astie wrote: > In many places of x86 HVM code, constants integer are used to indicate in what mode is > running the CPU (real, vm86, 16-bits, 32-bits, 64-bits). However, these constants are > are written directly as integer which hides the actual meaning of these modes. > > This patch introduces X86_MODE_* macros and replace those occurences with it. > > Signed-off-by Teddy Astie Reviewed-by: Jan Beulich with further style adjustments (see below) and ideally with ... > --- > v2: > Formatting changes (alignment, ...) > Renamed v86 to vm86. (Jan) ... this extended to ... > @@ -2952,11 +2954,11 @@ static const char *guest_x86_mode_to_str(int mode) > { > switch ( mode ) > { > - case 0: return "Real"; > - case 1: return "v86"; > - case 2: return "16bit"; > - case 4: return "32bit"; > - case 8: return "64bit"; > + case X86_MODE_REAL: return "Real"; > + case X86_MODE_VM86: return "v86"; ... the string literal here. > @@ -112,23 +113,23 @@ int hvm_hypercall(struct cpu_user_regs *regs) > > switch ( mode ) > { > - case 8: > + case X86_MODE_64BIT: > eax = regs->rax; > fallthrough; > - case 4: > - case 2: > + case X86_MODE_32BIT: > + case X86_MODE_16BIT: > if ( currd->arch.monitor.guest_request_userspace_enabled && > eax == __HYPERVISOR_hvm_op && > - (mode == 8 ? regs->rdi : regs->ebx) == HVMOP_guest_request_vm_event ) > + (mode == X86_MODE_64BIT ? regs->rdi : regs->ebx) == HVMOP_guest_request_vm_event ) This line is too long now. > @@ -2073,7 +2073,8 @@ int nvmx_handle_vmx_insn(struct cpu_user_regs *regs, unsigned int exit_reason) > > if ( !(curr->arch.hvm.guest_cr[4] & X86_CR4_VMXE) || > !nestedhvm_enabled(curr->domain) || > - (vmx_guest_x86_mode(curr) < (hvm_long_mode_active(curr) ? 8 : 2)) || > + (vmx_guest_x86_mode(curr) < (hvm_long_mode_active(curr) ? X86_MODE_64BIT > + : X86_MODE_16BIT)) || As are these two. Likely easy enough to adjust while committing. Jan From xen-devel-bounces@lists.xenproject.org Wed Dec 04 11:18:26 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 11:18:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848528.1263384 (Exim 4.92) (envelope-from ) id 1tInOd-0005sS-Dl; Wed, 04 Dec 2024 11:18:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848528.1263384; Wed, 04 Dec 2024 11:18:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tInOd-0005sL-Af; Wed, 04 Dec 2024 11:18:19 +0000 Received: by outflank-mailman (input) for mailman id 848528; Wed, 04 Dec 2024 11:18:18 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tInOc-0005sF-EY for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 11:18:18 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tInOb-003b73-1Y; Wed, 04 Dec 2024 11:18:17 +0000 Received: from [15.248.2.30] (helo=[10.24.67.22]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tInOb-00F1tV-1Y; Wed, 04 Dec 2024 11:18: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" 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=wQtOr/4W3Ysv2wRRLbBoQxvR2KNUVcWPImcsAjJEyeI=; b=a7R0yq9+2TeuUfLNM7P7EVoeRm MC6fpShSSpl5u3aWo7SrsNr8Wa3MJp3C+aDJTIkWI/tU486lzLwnnufGfRjTwKV2u8S/3ePsVSqlx aficeYAu+8+DIemFOl2JiGKS8KpFJdNbZqYc90z+dnB+fikK10pzRQt4DIrqz1Ad85yk=; Message-ID: <2bea0c6d-ce0e-44e3-ab9a-cbd5c2fdd99e@xen.org> Date: Wed, 4 Dec 2024 11:18:15 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 12/12] xen/arm: add cache coloring support for Xen image Content-Language: en-GB To: Carlo Nonato Cc: xen-devel@lists.xenproject.org, andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Jan Beulich References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> <20241202165921.249585-13-carlo.nonato@minervasys.tech> <800b0b49-e6c5-4a83-8ee6-d89d51613b0c@xen.org> <5580b3fc-66d7-4193-9c54-2733fb628418@xen.org> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Carlo, On 03/12/2024 11:37, Carlo Nonato wrote: > On Tue, Dec 3, 2024 at 11:36 AM Julien Grall wrote: >> >> On 03/12/2024 10:08, Carlo Nonato wrote: >>> Hi Julien, >>> >>> On Mon, Dec 2, 2024 at 10:44 PM Julien Grall wrote: >>>> >>>> Hi Carlo, >>> >>> [...] >>> >>>>> diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c >>>>> index 671eaadbc1..3732d5897e 100644 >>>>> --- a/xen/arch/arm/arm64/mmu/mm.c >>>>> +++ b/xen/arch/arm/arm64/mmu/mm.c >>>>> @@ -1,6 +1,7 @@ >>>>> /* SPDX-License-Identifier: GPL-2.0-only */ >>>>> >>>>> #include >>>>> +#include >>>>> #include >>>>> #include >>>>> >>>>> @@ -138,27 +139,46 @@ void update_boot_mapping(bool enable) >>>>> } >>>>> >>>>> extern void switch_ttbr_id(uint64_t ttbr); >>>>> +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len); >>>>> >>>>> typedef void (switch_ttbr_fn)(uint64_t ttbr); >>>>> +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t len); >>>>> >>>>> void __init switch_ttbr(uint64_t ttbr) >>>> >>>> Given the change below, I think this function needs to be renamed. >>>> Possibly to relocate_and_jump() with a comment explaning that the >>>> relocation only happen for cache-coloring. >>> >>> Changing the name of switch_ttbr() to relocate_and_jump() seems a bit >>> misleading to me. First I need to change the name also for arm32 where there's >>> no relocation at all. Second, relocation is something that happens >>> conditionally so I don't think it's a good name for the function. >> >> Feel free to propose a new name. The main thing is the current name >> can't stay "switch_ttbr()" because you are doing more than switching the >> TTBR. >> >> The other solution is to have a separate call for relocating xen (which >> will fall-through to switch_ttbr) and another one for those that only to >> switch TTBR. > > What about a function like this one, defined in xen/arch/arm/arm64/mmu/mm.c: > > typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t len); > > void __init relocate_and_switch_ttbr(uint64_t ttbr) { > vaddr_t id_addr = virt_to_maddr(relocate_xen); > relocate_xen_fn *fn = (relocate_xen_fn *)id_addr; > lpae_t pte; > > /* Enable the identity mapping in the boot page tables */ > update_identity_mapping(true); > > /* Enable the identity mapping in the runtime page tables */ > pte = pte_of_xenaddr((vaddr_t)relocate_xen); > pte.pt.table = 1; > pte.pt.xn = 0; > pte.pt.ro = 1; > write_pte(&xen_third_id[third_table_offset(id_addr)], pte); > > /* Relocate Xen and switch TTBR */ > fn(ttbr, _start, (void *)BOOT_RELOC_VIRT_START, _end - _start); > > /* > * Disable the identity mapping in the runtime page tables. > * Note it is not necessary to disable it in the boot page tables > * because they are not going to be used by this CPU anymore. > */ > update_identity_mapping(false); > } > > which is actually a clone of switch_ttbr() but it does relocation. I would > then call it in case of coloring in setup_pagetables(). This should go in the > direction you suggested, but it would duplicate a bit of code. What do you > think about it? I think the duplication is fine here. It would be possible to reduce the duplication is we introduce an helper for call update_identity_mapping(true) and update the PTE. But I am not sure it is worth it. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Dec 04 13:02:07 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 13:02:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848554.1263401 (Exim 4.92) (envelope-from ) id 1tIp0q-0002fz-2b; Wed, 04 Dec 2024 13:01:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848554.1263401; Wed, 04 Dec 2024 13:01: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 1tIp0q-0002fs-06; Wed, 04 Dec 2024 13:01:52 +0000 Received: by outflank-mailman (input) for mailman id 848554; Wed, 04 Dec 2024 13:01: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 1tIp0o-0002fh-Qn for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 13:01:50 +0000 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [2a00:1450:4864:20::52b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ec9304ba-b23f-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 14:01:49 +0100 (CET) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5cf9ef18ae9so1523496a12.1 for ; Wed, 04 Dec 2024 05:01:49 -0800 (PST) Received: from [192.168.86.29] ([90.240.255.120]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa5996c2b9csm724719566b.9.2024.12.04.05.01.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Dec 2024 05:01: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: ec9304ba-b23f-11ef-a0d4-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1733317309; x=1733922109; 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=OLpOkLrWRhcylB11s7d1FGp4TC8CC1YgVQyvnX1mE+s=; b=JKw0Sm9MJueXkV965Esc+JttcQYza4wKr7fFVFaQ+OXeJVOgi+5j+Wnwg6FRCZ02l+ C7Vq55W2IBlt0YHGP4r1xsHtt3py/P1W/8ziIM4cFAVuj/WRiF2pV4A2rpdv6D+L+NXH 90WKBTmi123WKWUAoukqft7BnWzHFNWmgw8/Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733317309; x=1733922109; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=OLpOkLrWRhcylB11s7d1FGp4TC8CC1YgVQyvnX1mE+s=; b=NvyrovyyXw6SXBnOlzxVY0fduP2+33W7IPhJ+ArFLZPBppKz2Hj0oA0JCgMMsncpgk x5n8gF3mfAWWhMFhQvuXaLyy1RIsns1Mz+7U5uRXbXuc3jWrfwU3F5H9nZnT7Y2ARtSI yZ04kZDGvHrL+dOrAVcDsLDWIJmlJd0i4dGNDj+w7gJChuGAvdipXxs1XQL/ftGdReBu DS1cRixDOggOwVW+Pg7hrxMO1FDegw+kc//YO72F4i8pE0p+cS55yERSMBl5LcK5kUkD kSSlBrCQ9zQJD9zcXqWeh6jWW+vkh43053Smdnf4etNjJrBCNOnrgvYpcf9QQpjOrG4z RK7g== X-Forwarded-Encrypted: i=1; AJvYcCXQ4nXbbza97ek6CtcaqgQll70UUhGtsvd5rRBd2JQShbH1EIp2WD1p2p9HYB9axGK/dntSjFg24ak=@lists.xenproject.org X-Gm-Message-State: AOJu0YzRfVmwnkaun5Vw4f7d8X1NcevaTVFJpEBQ0RblP6J4PaSs/kg9 g5/2+yZZ2qQ0ZBhu9jMEj0cbs+8nMbmiWlU2GYssw5CzFKnbAXaEBjKAPupiTGw3ylGFQ+7cdmr LnbQ= X-Gm-Gg: ASbGnctzXFm78ybfVAbXl3VIIFMfvh2UD0CHWQmOAXh/BQsI8Zp0UhKB0jzSRohynT8 nMg9lPePb4mkcTugA6iBR0RPV5XjNUSDvJkjGv5kOJmDbRhdEBeqS3ZG7t3AxZHyvV9SDG5HhQb P+YOhsjXh3IyWxHTbWctAVcXeMGQbVTmt7oShdwC3fNyU12kInfkS2qSYcU2fU7T4iiEx4KVhnN zoEspT4neFX252LBaoepL7YfxnXY+0pXH/nhrS6CPpKLbGSeAC8lOxPw9ybvys= X-Google-Smtp-Source: AGHT+IGFwBxM3nG2Ci1SHXGSm0Cqv0F3jp30ABIdO+QSn/hOyhcbHUxTLI2z5H3HeEv0hJk9UqgQsQ== X-Received: by 2002:a17:907:3f96:b0:aa5:55b6:8080 with SMTP id a640c23a62f3a-aa5945353a1mr3218607666b.12.1733317308478; Wed, 04 Dec 2024 05:01:48 -0800 (PST) Message-ID: <79004c19-7e55-4623-86e6-badd165b1d30@citrix.com> Date: Wed, 4 Dec 2024 13:01:47 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH v2] x86/hvm: Use constants for x86 modes To: Teddy Astie , xen-devel@lists.xenproject.org Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Paul Durrant References: Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 02/12/2024 9:49 am, Teddy Astie wrote: > In many places of x86 HVM code, constants integer are used to indicate in what mode is > running the CPU (real, vm86, 16-bits, 32-bits, 64-bits). However, these constants are > are written directly as integer which hides the actual meaning of these modes. > > This patch introduces X86_MODE_* macros and replace those occurences with it. > > Signed-off-by Teddy Astie As fed back previously, these are (mostly) not modes. "Mode" has a specific meaning in the x86 architecture which is not this.  You are going to have to change your commit message, and choice of constant names. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Dec 04 13:43:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 13:43:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848565.1263412 (Exim 4.92) (envelope-from ) id 1tIpf8-0007il-UT; Wed, 04 Dec 2024 13:43:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848565.1263412; Wed, 04 Dec 2024 13:43: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 1tIpf8-0007ie-RA; Wed, 04 Dec 2024 13:43:30 +0000 Received: by outflank-mailman (input) for mailman id 848565; Wed, 04 Dec 2024 13:43:29 +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 1tIpf7-0007iY-TL for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 13:43:29 +0000 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [2a00:1450:4864:20::634]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bdbe5309-b245-11ef-99a3-01e77a169b0f; Wed, 04 Dec 2024 14:43:27 +0100 (CET) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a9a68480164so901835666b.3 for ; Wed, 04 Dec 2024 05:43: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: bdbe5309-b245-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1733319807; x=1733924607; darn=lists.xenproject.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=0Fopsikh4/TA9+CQof8cGFRjnBqSfg99ecS2CWbxhJc=; b=XyTPmSe1xJDXe0Q3/RNYa7JvlSYdcHqI4TIQDAQzqNpQtvuCn6h2UdWICGt8PTy7AJ uOv8yncg/yEmeZZ6tf/jovHowDbA516p1k1N+SU5wiK3dbzI5UbxakBRsDv+Upegkbqn R6GNLBodoJRn9RlBsVCTTc5jJ+XZa7GyN4ORM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733319807; x=1733924607; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=0Fopsikh4/TA9+CQof8cGFRjnBqSfg99ecS2CWbxhJc=; b=Y771hWWMiA//ZQblKfKk027DHqtlTN2e66VbL3kLjNO5wMExxOVqSNYR5sL2gLtfkz 8g9zGJk783VOwnvwSWPxIgFJrZfX9A72y+OC9we3P+OdayufxPs3+2jQTGlBxrnEhL8c niNrmOtmKab+Tt78a4MsNh9Vmr8woYyWfGkqsw+Fe4p7O8aSyDfXhkPpu0CALi2czuKu 9Z/sYNJUQkMsdKzi5K7afDLa+cP8ZHl0ODgx8i4fEzURkPkzrYhC/lor9vDluzN4U/Yr vB+traVEDTBtt9TvFcoy2qfFwjSTOEwpE0aMwP5FEN1kUq8XqDEepJ38XrypUgsKzmTs iL5Q== X-Gm-Message-State: AOJu0YzLd4BUUt+szH4jpe1EWBtNj2iNMa7vcESrRPtqyIJWmviZRk8H Ds4MJgnjfoLOGekJSahV7Rv+vBRit8Y2kYNBky4e2OK4QObLmnRz1kUDQxJYQZkC/u6JkpUNNGW 5yHrfczSctITYoQ14nCGap9XSoSwZJPMQIhQk1sdECZRR9dXseYP9/w== X-Gm-Gg: ASbGncueGxSug6xCVmKtS0sBzBnSN5ClJFcC9FD6beLe2FToBqn0T6dKNYqYflJ+TaG jP3KSWPY9YBh7+Wy1ZsUbED7pKZxPYA== X-Google-Smtp-Source: AGHT+IFkvBAX+bmgKG/FdjOVbYFgg0BOxFA3iBysHkk55EM+Fp1arTdJEfbVlWlqef1Ho4w4WXJXEfyvxetHnZhFM8M= X-Received: by 2002:a17:907:7815:b0:a9e:43d9:401a with SMTP id a640c23a62f3a-aa5f7d15961mr542476066b.14.1733319806494; Wed, 04 Dec 2024 05:43:26 -0800 (PST) MIME-Version: 1.0 From: Kelly Choi Date: Wed, 4 Dec 2024 13:42:50 +0000 Message-ID: Subject: [ANNOUNCE] Call for agenda items - Community Call 5th Dec 2024 To: xen-devel Content-Type: multipart/alternative; boundary="00000000000059552a062871f741" --00000000000059552a062871f741 Content-Type: text/plain; charset="UTF-8" Hi all, Please add your proposed agenda items below. If any action items are missing or have been resolved, please add/remove them from the sheet. https://cryptpad.fr/pad/#/2/pad/edit/rEgpgVlezL41HDxAxxTdteJ-/ *CALL LINK:* https://meet.jit.si/XenProjectCommunityCall *DATE: *Thursday 5th December 2024 *TIME: *1600 UTC (4 pm UK time) *Note the following administrative conventions for the call:* ** To allow time to switch between meetings, we plan on starting theagenda at 16:05 UTC sharp. Aim to join by 16:03 UTC if possible to allocatetime to sort out technical difficulties.* ** If you want to be CC'ed please add or remove yourself from thesign-up-sheet at https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/ == Dial-in Information ==## Meeting time16:00 - 17:00 British timeFurther International meeting times:* https://www.timeanddate.com/worldclock/meetingdetails.html?year=2024&month=12&day=5&hour=16&min=0&sec=0&p1=1234&p2=37&p3=224&p4=179 ## Dial in details https://meet.jit.si/static/dialInInfo.html?room=XenProjectCommunityCall Thanks, Kelly Choi Community Manager Xen Project --00000000000059552a062871f741 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi all,=C2=A0

Please add your proposed = agenda items below. If any action items are missing or have been resolved, = please add/remove them from the sheet.=C2=A0

https://cryptpad.fr/pad/= #/2/pad/edit/rEgpgVlezL41HDxAxxTdteJ-/=C2=A0=C2=A0

CALL LINK:<= /b>=C2=A0https://meet= .jit.si/XenProjectCommunityCall

DATE:=C2=A0Thursday 5th De= cember 2024

TIME:=C2=A01600 UTC (4 pm UK time)

Note the = following administrative conventions for the=C2=A0= call:
* To allow time to switch between meetin= gs, we plan on starting the
agenda at 16:05 UTC sharp.=C2=A0 Aim to join= by 16:03 UTC if possible to allocate
time to sort out technical difficu= lties.

* If you want to be CC'ed please add or rem= ove yourself from the
sign-up-sheet at=C2=A0https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/=

=3D=3D=C2=A0Dial-in Information =3D= =3D
## Meeting time
16:00 - 17:00 British time
Further Internation= al meeting times:
https://www.timeanddate.com/worldclock/meetingdetails.htm= l?year=3D2024&month=3D12&day=3D5&hour=3D16&min=3D0&sec= =3D0&p1=3D1234&p2=3D37&p3=3D224&p4=3D179=C2=A0

#= #=C2=A0Dial=C2=A0in details
https://meet.jit.si/static/dialInInfo.h= tml?room=3DXenProjectCommunityCall

Thanks,
Kelly Choi
Community Manager
--00000000000059552a062871f741-- From xen-devel-bounces@lists.xenproject.org Wed Dec 04 14:08:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 14:08:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848576.1263422 (Exim 4.92) (envelope-from ) id 1tIq2h-0002Cu-Me; Wed, 04 Dec 2024 14:07:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848576.1263422; Wed, 04 Dec 2024 14:07: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 1tIq2h-0002Cn-JK; Wed, 04 Dec 2024 14:07:51 +0000 Received: by outflank-mailman (input) for mailman id 848576; Wed, 04 Dec 2024 14:07: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 1tIq2f-0002Ch-Rm for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 14:07:50 +0000 Received: from mail180-27.suw31.mandrillapp.com (mail180-27.suw31.mandrillapp.com [198.2.180.27]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 22315ec5-b249-11ef-99a3-01e77a169b0f; Wed, 04 Dec 2024 15:07:45 +0100 (CET) Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail180-27.suw31.mandrillapp.com (Mailchimp) with ESMTP id 4Y3K9D0fBJz6CQQJm for ; Wed, 4 Dec 2024 14:07:44 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id c9fb72217ccc4995aaeed03a349a81c1; Wed, 04 Dec 2024 14:07: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: 22315ec5-b249-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1733321264; x=1733581764; bh=8t8U+zgJZtjkj5kbEmTvYvbrqtJ0B+UOcaKS+uPHTwA=; 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=Kkq+WcAxE1t0ekfNV9Rpx1E3Am0kypqX1/X/mm+soY/9j2sKGMjj0tk+ZhzQXtzpm /Ogca7bH6ndLDZMuxCz7JdTRB/nQbx/A+TA0KSCx2MLx5gDibNssvtz5I29ZkGI3H2 1MTXCe/n+C84ZrqTI3ZslZhf9tl0qM9tKUPsTb3zsm0y3lNy3AjvdhwHSTLvJ/7deJ mNO99CIV04PS0jXfq3ujzR/jk40D6WIINOIMAiyzBdw8IaHkZThboEkNjXz701HL9U 7xfUqHk1/srvtzxIWCozEDbxFZUDuQdP3n47KMoxYZVka+7ZhTJClWSncDTiTE4p1d zjVThhG7SFT/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1733321264; x=1733581764; i=anthony.perard@vates.tech; bh=8t8U+zgJZtjkj5kbEmTvYvbrqtJ0B+UOcaKS+uPHTwA=; 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=1EeQIKbXBQmeDGzGukAJ+aesdDpasHBCrOo9sO8/TZfEGPyXU3/3t2HDMWYqPI3QY R3zMGVeVplqL9Cy0pK8y2+kRHD8z3r2cpnXNnMs0ZbxDZGKLeLt68eK4k5tJPCfJZU B3wjCxUBqTaysTIiWzrB5JUY7mTdaY3FDsBnA08tzeCO5SpX/p2Ms6JvFQOynir3A7 OD9y967/+/CVyS4q0wEeT/8Ua2s5tUTyD3n/dEBqnLKMr9dlnXne8WgMs7Ul4AtTB/ Tv2UTpGooaH+c+OJ6KPoG1XoCKYdT5mYYEF3SSVFuZOnTAf0ovycrbOslEwba7Y9lA OE2dpVqLQLv8Q== From: "Anthony PERARD" Subject: =?utf-8?Q?Re:=20[PATCH=20v11=2006/12]=20tools:=20add=20support=20for=20cache=20coloring=20configuration?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1733321263150 To: "Carlo Nonato" Cc: xen-devel@lists.xenproject.org, andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, "Nick Rosbrook" , "George Dunlap" , "Juergen Gross" Message-Id: References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> <20241202165921.249585-7-carlo.nonato@minervasys.tech> In-Reply-To: <20241202165921.249585-7-carlo.nonato@minervasys.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.c9fb72217ccc4995aaeed03a349a81c1?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20241204:md Date: Wed, 04 Dec 2024 14:07:44 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On Mon, Dec 02, 2024 at 05:59:15PM +0100, Carlo Nonato wrote: > Add a new "llc_colors" parameter that defines the LLC color assignment for > a domain. The user can specify one or more color ranges using the same > syntax used everywhere else for color config described in the > documentation. > The parameter is defined as a list of strings that represent the color > ranges. > > Documentation is also added. > > Based on original work from: Luca Miccio > > Signed-off-by: Carlo Nonato > Signed-off-by: Marco Solieri Reviewed-by: Anthony PERARD Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Wed Dec 04 14:31:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 14:31:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848589.1263431 (Exim 4.92) (envelope-from ) id 1tIqPd-0005xr-Fd; Wed, 04 Dec 2024 14:31:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848589.1263431; Wed, 04 Dec 2024 14:31: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 1tIqPd-0005xk-Cu; Wed, 04 Dec 2024 14:31:33 +0000 Received: by outflank-mailman (input) for mailman id 848589; Wed, 04 Dec 2024 14:31: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 1tIqPb-0005xe-I6 for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 14:31:31 +0000 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 71a8107e-b24c-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 15:31:28 +0100 (CET) Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Dec 2024 06:31:26 -0800 Received: from mwiniars-desk2.ger.corp.intel.com (HELO localhost) ([10.245.246.205]) by fmviesa008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Dec 2024 06:31:21 -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: 71a8107e-b24c-11ef-a0d4-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1733322688; x=1764858688; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=dTapqBXiBmZ3/iS1nkrTPcg40STqJyfdMGiif+W/trs=; b=mlsdN0yyPJDjcGIwIiZKOJeSSqwsaIzlJFDV3zdz3ygPsovIArloIIhU RaoNR8Fo9D88VaOjVAfs2QDhvvPcz6gXo2teF/Fiz1KCg5PXkLm9JJCIy MdRa33UpMrs2Gg98CUebEB6k+MlIb1J+zExz2JEo/SnZunCSw/cWO7kOx ddmtLtBC0eEKiGtqfQzhVeGuzQJgw3OxkW5jH0qr+CrmQ1tt6M1yzCNg9 3VxWckicjuWElhof/tU4e4j8g5Iq8E9Q6F+CSosCdnjWm4AwapyKmMt7F PU6CpMvMeksgQbuUql0hG46/VHYQmCnZzRcFMZp59yHoWS4iylG8h4A2X w==; X-CSE-ConnectionGUID: W5yT81heTSaStyJ4Y7MeJg== X-CSE-MsgGUID: aXkMWb5JQdG7po/SfdRpNg== X-IronPort-AV: E=McAfee;i="6700,10204,11276"; a="44255526" X-IronPort-AV: E=Sophos;i="6.12,207,1728975600"; d="scan'208";a="44255526" X-CSE-ConnectionGUID: qP9l167GS5WX+6j0tx76Uw== X-CSE-MsgGUID: 0lE6/Rr8R8asFhrmSkn/wg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,207,1728975600"; d="scan'208";a="93963339" From: Jani Nikula To: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org Cc: jani.nikula@intel.com, Alex Deucher , Oleksandr Andrushchenko , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , xen-devel@lists.xenproject.org Subject: [PATCH v2 1/3] drm/xen: remove redundant initialization info print Date: Wed, 4 Dec 2024 16:31:10 +0200 Message-Id: <900b3836c80a23923ede034ab10eb344be1e35bd.1733322525.git.jani.nikula@intel.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: References: MIME-Version: 1.0 Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Content-Transfer-Encoding: 8bit drm_dev_register() already prints the same information on successful init. Remove the redundant prints. Acked-by: Alex Deucher Signed-off-by: Jani Nikula --- Note: I prefer to merge this together with the next patch via drm-misc-next. Cc: Oleksandr Andrushchenko Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Simona Vetter Cc: dri-devel@lists.freedesktop.org Cc: xen-devel@lists.xenproject.org --- drivers/gpu/drm/xen/xen_drm_front.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/xen/xen_drm_front.c b/drivers/gpu/drm/xen/xen_drm_front.c index aab79c5e34c2..931d855bfbe8 100644 --- a/drivers/gpu/drm/xen/xen_drm_front.c +++ b/drivers/gpu/drm/xen/xen_drm_front.c @@ -525,11 +525,6 @@ static int xen_drm_drv_init(struct xen_drm_front_info *front_info) if (ret) goto fail_register; - DRM_INFO("Initialized %s %d.%d.%d %s on minor %d\n", - xen_drm_driver.name, xen_drm_driver.major, - xen_drm_driver.minor, xen_drm_driver.patchlevel, - xen_drm_driver.date, drm_dev->primary->index); - return 0; fail_register: -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Wed Dec 04 14:31:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 14:31:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848591.1263441 (Exim 4.92) (envelope-from ) id 1tIqPt-0006FN-Nm; Wed, 04 Dec 2024 14:31:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848591.1263441; Wed, 04 Dec 2024 14: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 1tIqPt-0006FE-KH; Wed, 04 Dec 2024 14:31:49 +0000 Received: by outflank-mailman (input) for mailman id 848591; Wed, 04 Dec 2024 14:31: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 1tIqPs-0005xe-BT for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 14:31:48 +0000 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7c0993d0-b24c-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 15:31:45 +0100 (CET) Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Dec 2024 06:31:43 -0800 Received: from mwiniars-desk2.ger.corp.intel.com (HELO localhost) ([10.245.246.205]) by fmviesa008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Dec 2024 06:31:36 -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: 7c0993d0-b24c-11ef-a0d4-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1733322706; x=1764858706; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=HTWO312KR4C6cq2PyX6O42TCk5OSpo8Ejn1R3BrxEG0=; b=eD/E6ExdrRa/ktc8YdcP5PhZQC3ZYGBTIPpcLvrb8qFUzdlX8zZcZ4+2 FRewjYDnFfVARfaMOHgn9pWeYfZCVv89oktgG7Kg9qm51IqnYuYGovU3r iPzwtSl+dbLSfvF1NGEx1INds0rOIkma0dOIerJZS5PqcJ7KZStcrtfI7 ke/nZGuHvZOqAeDJyFasV5b5aNQ1Lv+lXcbZlbZXQ/6e8M30eVsqoX31t PVVzl+5M2VhYA0mMLVYZ1BPRQyDgJcA0BGRjSJv0IciHpS8IWjhf3FoFl eB7iDYcaCAeCq0cfKgsyYJOOuPDE+Whq9S/MbkmRl6hL/zwxRT52/xSg/ A==; X-CSE-ConnectionGUID: Ns2UIOmxQ46RITlG6BFytg== X-CSE-MsgGUID: NUHtA6orRlGBugxxZm+AsA== X-IronPort-AV: E=McAfee;i="6700,10204,11276"; a="44255601" X-IronPort-AV: E=Sophos;i="6.12,207,1728975600"; d="scan'208";a="44255601" X-CSE-ConnectionGUID: EJ/2tPD0TwOHPWTxUOsoLw== X-CSE-MsgGUID: uIlEmVlOSJq2XViRhpY6xg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,207,1728975600"; d="scan'208";a="93963445" From: Jani Nikula To: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org Cc: jani.nikula@intel.com, Javier Martinez Canillas , Alex Deucher , Simon Ser , Jeffrey Hugo , David Airlie , Hamza Mahfooz , Maarten Lankhorst , Maxime Ripard , Oleksandr Andrushchenko , Simona Vetter , Thomas Zimmermann , =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= , amd-gfx@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, nouveau@lists.freedesktop.org, xen-devel@lists.xenproject.org Subject: [PATCH v2 3/3] drm: remove driver date from struct drm_driver and all drivers Date: Wed, 4 Dec 2024 16:31:12 +0200 Message-Id: <1f2bf2543aed270a06f6c707fd6ed1b78bf16712.1733322525.git.jani.nikula@intel.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Content-Transfer-Encoding: 8bit We stopped using the driver initialized date in commit 7fb8af6798e8 ("drm: deprecate driver date") and (eventually) started returning "0" for drm_version ioctl instead. Finish the job, and remove the unused date member from struct drm_driver, its initialization from drivers, along with the common DRIVER_DATE macros. v2: Also update drivers/accel (kernel test robot) Reviewed-by: Javier Martinez Canillas Acked-by: Alex Deucher Acked-by: Simon Ser Acked-by: Jeffrey Hugo Signed-off-by: Jani Nikula --- Cc: David Airlie Cc: Hamza Mahfooz Cc: Javier Martinez Canillas Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Oleksandr Andrushchenko Cc: Simon Ser Cc: Simona Vetter Cc: Thomas Zimmermann Cc: Ville Syrjälä Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Cc: nouveau@lists.freedesktop.org Cc: xen-devel@lists.xenproject.org --- drivers/accel/habanalabs/common/habanalabs_drv.c | 1 - drivers/accel/ivpu/ivpu_drv.c | 1 - drivers/accel/qaic/qaic_drv.c | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 -- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.h | 1 - drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 1 - drivers/gpu/drm/arm/hdlcd_drv.c | 1 - drivers/gpu/drm/arm/malidp_drv.c | 1 - drivers/gpu/drm/armada/armada_drv.c | 1 - drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 1 - drivers/gpu/drm/ast/ast_drv.c | 1 - drivers/gpu/drm/ast/ast_drv.h | 1 - drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 1 - drivers/gpu/drm/etnaviv/etnaviv_drv.c | 1 - drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 -- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 1 - drivers/gpu/drm/gma500/psb_drv.c | 1 - drivers/gpu/drm/gma500/psb_drv.h | 1 - drivers/gpu/drm/gud/gud_drv.c | 1 - drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 1 - drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 1 - drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 2 -- drivers/gpu/drm/i915/i915_driver.c | 1 - drivers/gpu/drm/i915/i915_driver.h | 1 - drivers/gpu/drm/i915/i915_gpu_error.c | 1 - drivers/gpu/drm/imagination/pvr_drv.c | 1 - drivers/gpu/drm/imagination/pvr_drv.h | 1 - drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 - drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 1 - drivers/gpu/drm/imx/lcdc/imx-lcdc.c | 1 - drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 1 - drivers/gpu/drm/kmb/kmb_drv.c | 1 - drivers/gpu/drm/kmb/kmb_drv.h | 1 - drivers/gpu/drm/lima/lima_drv.c | 1 - drivers/gpu/drm/logicvc/logicvc_drm.c | 1 - drivers/gpu/drm/loongson/lsdc_drv.c | 2 -- drivers/gpu/drm/mcde/mcde_drv.c | 1 - drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 -- drivers/gpu/drm/meson/meson_drv.c | 1 - drivers/gpu/drm/mgag200/mgag200_drv.c | 1 - drivers/gpu/drm/mgag200/mgag200_drv.h | 1 - drivers/gpu/drm/msm/msm_drv.c | 1 - drivers/gpu/drm/mxsfb/lcdif_drv.c | 1 - drivers/gpu/drm/mxsfb/mxsfb_drv.c | 1 - drivers/gpu/drm/nouveau/nouveau_drm.c | 5 ----- drivers/gpu/drm/nouveau/nouveau_drv.h | 1 - drivers/gpu/drm/omapdrm/omap_drv.c | 2 -- drivers/gpu/drm/panfrost/panfrost_drv.c | 1 - drivers/gpu/drm/panthor/panthor_drv.c | 1 - drivers/gpu/drm/pl111/pl111_drv.c | 1 - drivers/gpu/drm/qxl/qxl_drv.c | 1 - drivers/gpu/drm/qxl/qxl_drv.h | 1 - drivers/gpu/drm/radeon/radeon_drv.c | 1 - drivers/gpu/drm/radeon/radeon_drv.h | 1 - drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 1 - drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 1 - drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c | 1 - drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 -- drivers/gpu/drm/solomon/ssd130x.c | 2 -- drivers/gpu/drm/sprd/sprd_drm.c | 2 -- drivers/gpu/drm/sti/sti_drv.c | 2 -- drivers/gpu/drm/stm/drv.c | 1 - drivers/gpu/drm/sun4i/sun4i_drv.c | 1 - drivers/gpu/drm/tegra/drm.c | 2 -- drivers/gpu/drm/tidss/tidss_drv.c | 1 - drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 - drivers/gpu/drm/tiny/arcpgu.c | 1 - drivers/gpu/drm/tiny/bochs.c | 1 - drivers/gpu/drm/tiny/cirrus-qemu.c | 2 -- drivers/gpu/drm/tiny/gm12u320.c | 2 -- drivers/gpu/drm/tiny/hx8357d.c | 1 - drivers/gpu/drm/tiny/ili9163.c | 1 - drivers/gpu/drm/tiny/ili9225.c | 1 - drivers/gpu/drm/tiny/ili9341.c | 1 - drivers/gpu/drm/tiny/ili9486.c | 1 - drivers/gpu/drm/tiny/mi0283qt.c | 1 - drivers/gpu/drm/tiny/ofdrm.c | 2 -- drivers/gpu/drm/tiny/panel-mipi-dbi.c | 1 - drivers/gpu/drm/tiny/repaper.c | 1 - drivers/gpu/drm/tiny/sharp-memory.c | 1 - drivers/gpu/drm/tiny/simpledrm.c | 2 -- drivers/gpu/drm/tiny/st7586.c | 1 - drivers/gpu/drm/tiny/st7735r.c | 1 - drivers/gpu/drm/tve200/tve200_drv.c | 1 - drivers/gpu/drm/udl/udl_drv.c | 1 - drivers/gpu/drm/udl/udl_drv.h | 1 - drivers/gpu/drm/v3d/v3d_drv.c | 2 -- drivers/gpu/drm/vboxvideo/vbox_drv.c | 1 - drivers/gpu/drm/vboxvideo/vbox_drv.h | 1 - drivers/gpu/drm/vc4/vc4_drv.c | 3 --- drivers/gpu/drm/vgem/vgem_drv.c | 2 -- drivers/gpu/drm/virtio/virtgpu_drv.c | 1 - drivers/gpu/drm/virtio/virtgpu_drv.h | 1 - drivers/gpu/drm/vkms/vkms_drv.c | 2 -- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 - drivers/gpu/drm/xe/xe_device.c | 1 - drivers/gpu/drm/xe/xe_drv.h | 1 - drivers/gpu/drm/xen/xen_drm_front.c | 1 - drivers/gpu/drm/xlnx/zynqmp_kms.c | 1 - include/drm/drm_drv.h | 2 -- 101 files changed, 126 deletions(-) diff --git a/drivers/accel/habanalabs/common/habanalabs_drv.c b/drivers/accel/habanalabs/common/habanalabs_drv.c index 708dfd10f39c..5409b2c656c8 100644 --- a/drivers/accel/habanalabs/common/habanalabs_drv.c +++ b/drivers/accel/habanalabs/common/habanalabs_drv.c @@ -101,7 +101,6 @@ static const struct drm_driver hl_driver = { .major = LINUX_VERSION_MAJOR, .minor = LINUX_VERSION_PATCHLEVEL, .patchlevel = LINUX_VERSION_SUBLEVEL, - .date = "20190505", .fops = &hl_fops, .open = hl_device_open, diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c index 1f359dbe5150..1e8ffbe25eee 100644 --- a/drivers/accel/ivpu/ivpu_drv.c +++ b/drivers/accel/ivpu/ivpu_drv.c @@ -458,7 +458,6 @@ static const struct drm_driver driver = { .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = UTS_RELEASE, .major = 1, }; diff --git a/drivers/accel/qaic/qaic_drv.c b/drivers/accel/qaic/qaic_drv.c index 3575e0c984d6..542c5d24e499 100644 --- a/drivers/accel/qaic/qaic_drv.c +++ b/drivers/accel/qaic/qaic_drv.c @@ -208,7 +208,6 @@ static const struct drm_driver qaic_accel_driver = { .name = QAIC_NAME, .desc = QAIC_DESC, - .date = "20190618", .fops = &qaic_accel_fops, .open = qaic_open, diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 346746d6c233..eaeaaddb32cd 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -2916,7 +2916,6 @@ static const struct drm_driver amdgpu_kms_driver = { .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = KMS_DRIVER_MAJOR, .minor = KMS_DRIVER_MINOR, .patchlevel = KMS_DRIVER_PATCHLEVEL, @@ -2940,7 +2939,6 @@ const struct drm_driver amdgpu_partition_driver = { .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = KMS_DRIVER_MAJOR, .minor = KMS_DRIVER_MINOR, .patchlevel = KMS_DRIVER_PATCHLEVEL, diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.h index 5bc2cb661af7..2d86cc6f7f4d 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.h @@ -40,7 +40,6 @@ #define DRIVER_NAME "amdgpu" #define DRIVER_DESC "AMD GPU" -#define DRIVER_DATE "20150101" extern const struct drm_driver amdgpu_partition_driver; diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c index 1e7b1fcb2848..6ed504099188 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c @@ -63,7 +63,6 @@ static const struct drm_driver komeda_kms_driver = { .fops = &komeda_cma_fops, .name = "komeda", .desc = "Arm Komeda Display Processor driver", - .date = "20181101", .major = 0, .minor = 1, }; diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c index 4af8fce7dab7..8617d10940d8 100644 --- a/drivers/gpu/drm/arm/hdlcd_drv.c +++ b/drivers/gpu/drm/arm/hdlcd_drv.c @@ -233,7 +233,6 @@ static const struct drm_driver hdlcd_driver = { .fops = &fops, .name = "hdlcd", .desc = "ARM HDLCD Controller DRM", - .date = "20151021", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c index 38b1b5b6bf69..3abc9339464b 100644 --- a/drivers/gpu/drm/arm/malidp_drv.c +++ b/drivers/gpu/drm/arm/malidp_drv.c @@ -570,7 +570,6 @@ static const struct drm_driver malidp_driver = { .fops = &fops, .name = "mali-dp", .desc = "ARM Mali Display Processor driver", - .date = "20160106", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c index ddf0eaf546a6..5d5b7435970a 100644 --- a/drivers/gpu/drm/armada/armada_drv.c +++ b/drivers/gpu/drm/armada/armada_drv.c @@ -45,7 +45,6 @@ static const struct drm_driver armada_drm_driver = { .minor = 0, .name = "armada-drm", .desc = "Armada SoC DRM", - .date = "20120730", .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC, .ioctls = armada_ioctls, .num_ioctls = ARRAY_SIZE(armada_ioctls), diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c index 55e90ab9b231..90189a3cf886 100644 --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c @@ -252,7 +252,6 @@ static const struct drm_driver aspeed_gfx_driver = { .fops = &fops, .name = "aspeed-gfx-drm", .desc = "ASPEED GFX DRM", - .date = "20180319", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c index 8e9c9cb89a50..ff3bcdd1cff2 100644 --- a/drivers/gpu/drm/ast/ast_drv.c +++ b/drivers/gpu/drm/ast/ast_drv.c @@ -60,7 +60,6 @@ static const struct drm_driver ast_driver = { .fops = &ast_fops, .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL, diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h index 21ce3769bf0d..6b4305ac07d4 100644 --- a/drivers/gpu/drm/ast/ast_drv.h +++ b/drivers/gpu/drm/ast/ast_drv.h @@ -43,7 +43,6 @@ #define DRIVER_NAME "ast" #define DRIVER_DESC "AST" -#define DRIVER_DATE "20120228" #define DRIVER_MAJOR 0 #define DRIVER_MINOR 1 diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c index 506289a937e2..b51528b2166c 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c @@ -846,7 +846,6 @@ static const struct drm_driver atmel_hlcdc_dc_driver = { .fops = &fops, .name = "atmel-hlcdc", .desc = "Atmel HLCD Controller DRM", - .date = "20141504", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c index 9b4e2f4b1bc7..c4ddabe3cabd 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c @@ -503,7 +503,6 @@ static const struct drm_driver etnaviv_drm_driver = { .fops = &fops, .name = "etnaviv", .desc = "etnaviv DRM", - .date = "20151214", .major = 1, .minor = 4, }; diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 7e517a2ec681..91ab42b56716 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -35,7 +35,6 @@ #define DRIVER_NAME "exynos" #define DRIVER_DESC "Samsung SoC DRM" -#define DRIVER_DATE "20180330" /* * Interface history: @@ -118,7 +117,6 @@ static const struct drm_driver exynos_drm_driver = { .fops = &exynos_drm_driver_fops, .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, }; diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c index 12b2096b6c9d..e1183644ec39 100644 --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c @@ -174,7 +174,6 @@ static const struct drm_driver fsl_dcu_drm_driver = { .fops = &fsl_dcu_drm_fops, .name = "fsl-dcu-drm", .desc = "Freescale DCU DRM", - .date = "20160425", .major = 1, .minor = 1, }; diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c index 2c56ece17d71..85d3557c2eb9 100644 --- a/drivers/gpu/drm/gma500/psb_drv.c +++ b/drivers/gpu/drm/gma500/psb_drv.c @@ -513,7 +513,6 @@ static const struct drm_driver driver = { .fops = &psb_gem_fops, .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h index de62cbfcdc72..7f77cb2b2751 100644 --- a/drivers/gpu/drm/gma500/psb_drv.h +++ b/drivers/gpu/drm/gma500/psb_drv.h @@ -26,7 +26,6 @@ #define DRIVER_NAME "gma500" #define DRIVER_DESC "DRM driver for the Intel GMA500, GMA600, GMA3600, GMA3650" -#define DRIVER_DATE "20140314" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c index 65a16f009ea6..cb405771d6e2 100644 --- a/drivers/gpu/drm/gud/gud_drv.c +++ b/drivers/gpu/drm/gud/gud_drv.c @@ -381,7 +381,6 @@ static const struct drm_driver gud_drm_driver = { .name = "gud", .desc = "Generic USB Display", - .date = "20200422", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c index 69bdae604982..7f814c32ed34 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c @@ -57,7 +57,6 @@ static const struct drm_driver hibmc_driver = { .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC, .fops = &hibmc_fops, .name = "hibmc", - .date = "20160828", .desc = "hibmc drm driver", .major = 1, .minor = 0, diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index 5616c3917c03..2eb49177ac42 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -929,7 +929,6 @@ static const struct drm_driver ade_driver = { DRM_FBDEV_DMA_DRIVER_OPS, .name = "kirin", .desc = "Hisilicon Kirin620 SoC DRM Driver", - .date = "20150718", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c index c5ac240f7a7a..f59abfa7622a 100644 --- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c +++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c @@ -20,7 +20,6 @@ #define DRIVER_NAME "hyperv_drm" #define DRIVER_DESC "DRM driver for Hyper-V synthetic video device" -#define DRIVER_DATE "2020" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 @@ -31,7 +30,6 @@ static struct drm_driver hyperv_driver = { .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c index c1edf5e1f61e..e35aa0274d76 100644 --- a/drivers/gpu/drm/i915/i915_driver.c +++ b/drivers/gpu/drm/i915/i915_driver.c @@ -1797,7 +1797,6 @@ static const struct drm_driver i915_drm_driver = { .fops = &i915_driver_fops, .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL, diff --git a/drivers/gpu/drm/i915/i915_driver.h b/drivers/gpu/drm/i915/i915_driver.h index 94a70d8ec5d5..4b67ad9a61cd 100644 --- a/drivers/gpu/drm/i915/i915_driver.h +++ b/drivers/gpu/drm/i915/i915_driver.h @@ -15,7 +15,6 @@ struct drm_printer; #define DRIVER_NAME "i915" #define DRIVER_DESC "Intel Graphics" -#define DRIVER_DATE "20230929" #define DRIVER_TIMESTAMP 1695980603 extern const struct dev_pm_ops i915_pm_ops; diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index 4eb58887819a..eb975b3815df 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++ b/drivers/gpu/drm/i915/i915_gpu_error.c @@ -841,7 +841,6 @@ static void __err_print_to_sgl(struct drm_i915_error_state_buf *m, err_printf(m, "Kernel: %s %s\n", init_utsname()->release, init_utsname()->machine); - err_printf(m, "Driver: %s\n", DRIVER_DATE); ts = ktime_to_timespec64(error->time); err_printf(m, "Time: %lld s %ld us\n", (s64)ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC); diff --git a/drivers/gpu/drm/imagination/pvr_drv.c b/drivers/gpu/drm/imagination/pvr_drv.c index 36c0e768698e..6ab023593476 100644 --- a/drivers/gpu/drm/imagination/pvr_drv.c +++ b/drivers/gpu/drm/imagination/pvr_drv.c @@ -1387,7 +1387,6 @@ static struct drm_driver pvr_drm_driver = { .name = PVR_DRIVER_NAME, .desc = PVR_DRIVER_DESC, - .date = PVR_DRIVER_DATE, .major = PVR_DRIVER_MAJOR, .minor = PVR_DRIVER_MINOR, .patchlevel = PVR_DRIVER_PATCHLEVEL, diff --git a/drivers/gpu/drm/imagination/pvr_drv.h b/drivers/gpu/drm/imagination/pvr_drv.h index 378fe477b759..7fa147312dd1 100644 --- a/drivers/gpu/drm/imagination/pvr_drv.h +++ b/drivers/gpu/drm/imagination/pvr_drv.h @@ -9,7 +9,6 @@ #define PVR_DRIVER_NAME "powervr" #define PVR_DRIVER_DESC "Imagination PowerVR (Series 6 and later) & IMG Graphics" -#define PVR_DRIVER_DATE "20230904" /* * Driver interface version: diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c b/drivers/gpu/drm/imx/dcss/dcss-kms.c index 490b5c269f39..3633e8f3aff6 100644 --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c @@ -34,7 +34,6 @@ static const struct drm_driver dcss_kms_driver = { .fops = &dcss_cma_fops, .name = "imx-dcss", .desc = "i.MX8MQ Display Subsystem", - .date = "20190917", .major = 1, .minor = 0, .patchlevel = 0, diff --git a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c index 6b84429735d6..bcb35ba670fc 100644 --- a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c +++ b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c @@ -163,7 +163,6 @@ static const struct drm_driver imx_drm_driver = { .fops = &imx_drm_driver_fops, .name = "imx-drm", .desc = "i.MX DRM graphics", - .date = "20120507", .major = 1, .minor = 0, .patchlevel = 0, diff --git a/drivers/gpu/drm/imx/lcdc/imx-lcdc.c b/drivers/gpu/drm/imx/lcdc/imx-lcdc.c index c5121fed80fd..d70981295f88 100644 --- a/drivers/gpu/drm/imx/lcdc/imx-lcdc.c +++ b/drivers/gpu/drm/imx/lcdc/imx-lcdc.c @@ -352,7 +352,6 @@ static struct drm_driver imx_lcdc_drm_driver = { DRM_FBDEV_DMA_DRIVER_OPS, .name = "imx-lcdc", .desc = "i.MX LCDC driver", - .date = "20200716", }; static const struct of_device_id imx_lcdc_of_dev_id[] = { diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c index 0a4eb3994cd6..6546d9ec410a 100644 --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c @@ -953,7 +953,6 @@ static const struct drm_driver ingenic_drm_driver_data = { .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC, .name = "ingenic-drm", .desc = "DRM module for Ingenic SoCs", - .date = "20200716", .major = 1, .minor = 1, .patchlevel = 0, diff --git a/drivers/gpu/drm/kmb/kmb_drv.c b/drivers/gpu/drm/kmb/kmb_drv.c index 4173344ba32c..c340b4c6a74b 100644 --- a/drivers/gpu/drm/kmb/kmb_drv.c +++ b/drivers/gpu/drm/kmb/kmb_drv.c @@ -445,7 +445,6 @@ static const struct drm_driver kmb_driver = { DRM_FBDEV_DMA_DRIVER_OPS, .name = "kmb-drm", .desc = "KEEMBAY DISPLAY DRIVER", - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, }; diff --git a/drivers/gpu/drm/kmb/kmb_drv.h b/drivers/gpu/drm/kmb/kmb_drv.h index bf085e95b28f..1f0c10d317fe 100644 --- a/drivers/gpu/drm/kmb/kmb_drv.h +++ b/drivers/gpu/drm/kmb/kmb_drv.h @@ -16,7 +16,6 @@ #define KMB_MIN_WIDTH 1920 /*Max width in pixels */ #define KMB_MIN_HEIGHT 1080 /*Max height in pixels */ -#define DRIVER_DATE "20210223" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 1 diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c index 10bce18b7c31..4b70c5189f7c 100644 --- a/drivers/gpu/drm/lima/lima_drv.c +++ b/drivers/gpu/drm/lima/lima_drv.c @@ -271,7 +271,6 @@ static const struct drm_driver lima_drm_driver = { .fops = &lima_drm_driver_fops, .name = "lima", .desc = "lima DRM", - .date = "20191231", .major = 1, .minor = 1, .patchlevel = 0, diff --git a/drivers/gpu/drm/logicvc/logicvc_drm.c b/drivers/gpu/drm/logicvc/logicvc_drm.c index 9152034e54a3..bda2a689d928 100644 --- a/drivers/gpu/drm/logicvc/logicvc_drm.c +++ b/drivers/gpu/drm/logicvc/logicvc_drm.c @@ -52,7 +52,6 @@ static struct drm_driver logicvc_drm_driver = { .fops = &logicvc_drm_fops, .name = "logicvc-drm", .desc = "Xylon LogiCVC DRM driver", - .date = "20200403", .major = 1, .minor = 0, diff --git a/drivers/gpu/drm/loongson/lsdc_drv.c b/drivers/gpu/drm/loongson/lsdc_drv.c index a55aa1fe2c21..12193d2a301a 100644 --- a/drivers/gpu/drm/loongson/lsdc_drv.c +++ b/drivers/gpu/drm/loongson/lsdc_drv.c @@ -26,7 +26,6 @@ #define DRIVER_AUTHOR "Sui Jingfeng " #define DRIVER_NAME "loongson" #define DRIVER_DESC "drm driver for loongson graphics" -#define DRIVER_DATE "20220701" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 #define DRIVER_PATCHLEVEL 0 @@ -39,7 +38,6 @@ static const struct drm_driver lsdc_drm_driver = { .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL, diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c index f8c7aa9d7f33..324a95d7f15b 100644 --- a/drivers/gpu/drm/mcde/mcde_drv.c +++ b/drivers/gpu/drm/mcde/mcde_drv.c @@ -208,7 +208,6 @@ static const struct drm_driver mcde_drm_driver = { .fops = &drm_fops, .name = "mcde", .desc = DRIVER_DESC, - .date = "20180529", .major = 1, .minor = 0, .patchlevel = 0, diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c index 38297d705df6..723782e75c55 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c @@ -33,7 +33,6 @@ #define DRIVER_NAME "mediatek" #define DRIVER_DESC "Mediatek SoC DRM" -#define DRIVER_DATE "20150513" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 @@ -615,7 +614,6 @@ static const struct drm_driver mtk_drm_driver = { .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, }; diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c index 83ee18024682..64c8c4bb60f1 100644 --- a/drivers/gpu/drm/meson/meson_drv.c +++ b/drivers/gpu/drm/meson/meson_drv.c @@ -105,7 +105,6 @@ static const struct drm_driver meson_driver = { .fops = &fops, .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = "20161109", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c b/drivers/gpu/drm/mgag200/mgag200_drv.c index b7ed763addfa..069fdd2dc8f6 100644 --- a/drivers/gpu/drm/mgag200/mgag200_drv.c +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c @@ -97,7 +97,6 @@ static const struct drm_driver mgag200_driver = { .fops = &mgag200_driver_fops, .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL, diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h b/drivers/gpu/drm/mgag200/mgag200_drv.h index 988967eafbf2..0608fc63e588 100644 --- a/drivers/gpu/drm/mgag200/mgag200_drv.h +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h @@ -25,7 +25,6 @@ #define DRIVER_NAME "mgag200" #define DRIVER_DESC "MGA G200 SE" -#define DRIVER_DATE "20110418" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c index b5fa715cbfb0..73e72aee6ec5 100644 --- a/drivers/gpu/drm/msm/msm_drv.c +++ b/drivers/gpu/drm/msm/msm_drv.c @@ -910,7 +910,6 @@ static const struct drm_driver msm_driver = { .fops = &fops, .name = "msm", .desc = "MSM Snapdragon DRM", - .date = "20130625", .major = MSM_VERSION_MAJOR, .minor = MSM_VERSION_MINOR, .patchlevel = MSM_VERSION_PATCHLEVEL, diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c b/drivers/gpu/drm/mxsfb/lcdif_drv.c index 81ec91cef66c..02fe6b89f3aa 100644 --- a/drivers/gpu/drm/mxsfb/lcdif_drv.c +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c @@ -248,7 +248,6 @@ static const struct drm_driver lcdif_driver = { .fops = &fops, .name = "imx-lcdif", .desc = "i.MX LCDIF Controller DRM", - .date = "20220417", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c index 1c27a97dce03..129cc3fb4448 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c @@ -336,7 +336,6 @@ static const struct drm_driver mxsfb_driver = { .fops = &fops, .name = "mxsfb-drm", .desc = "MXSFB Controller DRM", - .date = "20160824", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index a99c1d9855c9..744ae9d3305d 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -1326,11 +1326,6 @@ driver_stub = { .name = DRIVER_NAME, .desc = DRIVER_DESC, -#ifdef GIT_REVISION - .date = GIT_REVISION, -#else - .date = DRIVER_DATE, -#endif .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL, diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h index 685d6ca3d8aa..55abc510067b 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drv.h +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h @@ -7,7 +7,6 @@ #define DRIVER_NAME "nouveau" #define DRIVER_DESC "nVidia Riva/TNT/GeForce/Quadro/Tesla/Tegra K1+" -#define DRIVER_DATE "20120801" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 4 diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c index 1796cd20a877..a80e0f375a0e 100644 --- a/drivers/gpu/drm/omapdrm/omap_drv.c +++ b/drivers/gpu/drm/omapdrm/omap_drv.c @@ -28,7 +28,6 @@ #define DRIVER_NAME MODULE_NAME #define DRIVER_DESC "OMAP DRM" -#define DRIVER_DATE "20110917" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 #define DRIVER_PATCHLEVEL 0 @@ -653,7 +652,6 @@ static const struct drm_driver omap_drm_driver = { .fops = &omapdriver_fops, .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL, diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c index 04d615df5259..fbaef3afcd66 100644 --- a/drivers/gpu/drm/panfrost/panfrost_drv.c +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c @@ -636,7 +636,6 @@ static const struct drm_driver panfrost_drm_driver = { .fops = &panfrost_drm_driver_fops, .name = "panfrost", .desc = "panfrost DRM", - .date = "20180908", .major = 1, .minor = 3, diff --git a/drivers/gpu/drm/panthor/panthor_drv.c b/drivers/gpu/drm/panthor/panthor_drv.c index ac7e53f6e3f0..ad46a40ed9e1 100644 --- a/drivers/gpu/drm/panthor/panthor_drv.c +++ b/drivers/gpu/drm/panthor/panthor_drv.c @@ -1505,7 +1505,6 @@ static const struct drm_driver panthor_drm_driver = { .fops = &panthor_drm_driver_fops, .name = "panthor", .desc = "Panthor DRM driver", - .date = "20230801", .major = 1, .minor = 2, diff --git a/drivers/gpu/drm/pl111/pl111_drv.c b/drivers/gpu/drm/pl111/pl111_drv.c index 4b96f48cf630..56ff6a3fb483 100644 --- a/drivers/gpu/drm/pl111/pl111_drv.c +++ b/drivers/gpu/drm/pl111/pl111_drv.c @@ -220,7 +220,6 @@ static const struct drm_driver pl111_drm_driver = { .fops = &drm_fops, .name = "pl111", .desc = DRIVER_DESC, - .date = "20170317", .major = 1, .minor = 0, .patchlevel = 0, diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c index f15e9583b098..417061ae59eb 100644 --- a/drivers/gpu/drm/qxl/qxl_drv.c +++ b/drivers/gpu/drm/qxl/qxl_drv.c @@ -300,7 +300,6 @@ static struct drm_driver qxl_driver = { .num_ioctls = ARRAY_SIZE(qxl_ioctls), .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = 0, .minor = 1, .patchlevel = 0, diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h index b5fc14c9525d..cc02b5f10ad9 100644 --- a/drivers/gpu/drm/qxl/qxl_drv.h +++ b/drivers/gpu/drm/qxl/qxl_drv.h @@ -54,7 +54,6 @@ struct iosys_map; #define DRIVER_NAME "qxl" #define DRIVER_DESC "RH QXL" -#define DRIVER_DATE "20120117" #define DRIVER_MAJOR 0 #define DRIVER_MINOR 1 diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c index 5ce7e91bedad..267f082bc430 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -603,7 +603,6 @@ static const struct drm_driver kms_driver = { .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = KMS_DRIVER_MAJOR, .minor = KMS_DRIVER_MINOR, .patchlevel = KMS_DRIVER_PATCHLEVEL, diff --git a/drivers/gpu/drm/radeon/radeon_drv.h b/drivers/gpu/drm/radeon/radeon_drv.h index 02a65971d140..0f3dbffc492d 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.h +++ b/drivers/gpu/drm/radeon/radeon_drv.h @@ -43,7 +43,6 @@ #define DRIVER_NAME "radeon" #define DRIVER_DESC "ATI Radeon" -#define DRIVER_DATE "20080528" /* Interface history: * diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c index 0f5204ef996e..be39b107b98c 100644 --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c @@ -611,7 +611,6 @@ static const struct drm_driver rcar_du_driver = { .fops = &rcar_du_fops, .name = "rcar-du", .desc = "Renesas R-Car Display Unit", - .date = "20130110", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c index 0a03a20f663b..9bbdc4d63d88 100644 --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c @@ -84,7 +84,6 @@ static const struct drm_driver rzg2l_du_driver = { .fops = &rzg2l_du_fops, .name = "rzg2l-du", .desc = "Renesas RZ/G2L Display Unit", - .date = "20230410", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c b/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c index 40b582ee178e..387eb602dadf 100644 --- a/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c +++ b/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c @@ -107,7 +107,6 @@ static const struct drm_driver shmob_drm_driver = { .fops = &shmob_drm_fops, .name = "shmob-drm", .desc = "Renesas SH Mobile DRM", - .date = "20120424", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c index 0393b48ad65b..1fe4399d6901 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c @@ -39,7 +39,6 @@ #define DRIVER_NAME "rockchip" #define DRIVER_DESC "RockChip Soc DRM" -#define DRIVER_DATE "20140818" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 @@ -235,7 +234,6 @@ static const struct drm_driver rockchip_drm_driver = { .fops = &rockchip_drm_driver_fops, .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, }; diff --git a/drivers/gpu/drm/solomon/ssd130x.c b/drivers/gpu/drm/solomon/ssd130x.c index a737f650c2bc..7b9f8fc193ac 100644 --- a/drivers/gpu/drm/solomon/ssd130x.c +++ b/drivers/gpu/drm/solomon/ssd130x.c @@ -39,7 +39,6 @@ #define DRIVER_NAME "ssd130x" #define DRIVER_DESC "DRM driver for Solomon SSD13xx OLED displays" -#define DRIVER_DATE "20220131" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 @@ -1784,7 +1783,6 @@ static const struct drm_driver ssd130x_drm_driver = { DRM_FBDEV_SHMEM_DRIVER_OPS, .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .driver_features = DRIVER_ATOMIC | DRIVER_GEM | DRIVER_MODESET, diff --git a/drivers/gpu/drm/sprd/sprd_drm.c b/drivers/gpu/drm/sprd/sprd_drm.c index a74cd0caf645..867ee2d8997f 100644 --- a/drivers/gpu/drm/sprd/sprd_drm.c +++ b/drivers/gpu/drm/sprd/sprd_drm.c @@ -23,7 +23,6 @@ #define DRIVER_NAME "sprd" #define DRIVER_DESC "Spreadtrum SoCs' DRM Driver" -#define DRIVER_DATE "20200201" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 @@ -59,7 +58,6 @@ static struct drm_driver sprd_drm_drv = { .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, }; diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c index a6c13318aa0b..46e6b674fa54 100644 --- a/drivers/gpu/drm/sti/sti_drv.c +++ b/drivers/gpu/drm/sti/sti_drv.c @@ -29,7 +29,6 @@ #define DRIVER_NAME "sti" #define DRIVER_DESC "STMicroelectronics SoC DRM" -#define DRIVER_DATE "20140601" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 @@ -143,7 +142,6 @@ static const struct drm_driver sti_driver = { .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, }; diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c index d181d11b277b..40a62c57e04c 100644 --- a/drivers/gpu/drm/stm/drv.c +++ b/drivers/gpu/drm/stm/drv.c @@ -62,7 +62,6 @@ static const struct drm_driver drv_driver = { .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC, .name = "stm", .desc = "STMicroelectronics SoC DRM", - .date = "20170330", .major = 1, .minor = 0, .patchlevel = 0, diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c index a7c11b795e98..025b0bdcbfd9 100644 --- a/drivers/gpu/drm/sun4i/sun4i_drv.c +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c @@ -50,7 +50,6 @@ static const struct drm_driver sun4i_drv_driver = { .fops = &sun4i_drv_fops, .name = "sun4i-drm", .desc = "Allwinner sun4i Display Engine", - .date = "20150629", .major = 1, .minor = 0, diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c index 34878f5d2918..4596073fe28f 100644 --- a/drivers/gpu/drm/tegra/drm.c +++ b/drivers/gpu/drm/tegra/drm.c @@ -35,7 +35,6 @@ #define DRIVER_NAME "tegra" #define DRIVER_DESC "NVIDIA Tegra graphics" -#define DRIVER_DATE "20120330" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 #define DRIVER_PATCHLEVEL 0 @@ -901,7 +900,6 @@ static const struct drm_driver tegra_drm_driver = { .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL, diff --git a/drivers/gpu/drm/tidss/tidss_drv.c b/drivers/gpu/drm/tidss/tidss_drv.c index 53bc219c097f..ee1132d581f5 100644 --- a/drivers/gpu/drm/tidss/tidss_drv.c +++ b/drivers/gpu/drm/tidss/tidss_drv.c @@ -113,7 +113,6 @@ static const struct drm_driver tidss_driver = { DRM_FBDEV_DMA_DRIVER_OPS, .name = "tidss", .desc = "TI Keystone DSS", - .date = "20180215", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c index 821d0ba26287..8013f01dbdf0 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c @@ -481,7 +481,6 @@ static const struct drm_driver tilcdc_driver = { .fops = &fops, .name = "tilcdc", .desc = "TI LCD Controller DRM", - .date = "20121205", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/drivers/gpu/drm/tiny/arcpgu.c index 5a0c8a874421..1e570f6f639f 100644 --- a/drivers/gpu/drm/tiny/arcpgu.c +++ b/drivers/gpu/drm/tiny/arcpgu.c @@ -367,7 +367,6 @@ static const struct drm_driver arcpgu_drm_driver = { .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC, .name = "arcpgu", .desc = "ARC PGU Controller", - .date = "20160219", .major = 1, .minor = 0, .patchlevel = 0, diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c index 71a1f15d6ac9..89a699370a59 100644 --- a/drivers/gpu/drm/tiny/bochs.c +++ b/drivers/gpu/drm/tiny/bochs.c @@ -680,7 +680,6 @@ static const struct drm_driver bochs_driver = { .fops = &bochs_fops, .name = "bochs-drm", .desc = "bochs dispi vga interface (qemu stdvga)", - .date = "20130925", .major = 1, .minor = 0, DRM_GEM_SHMEM_DRIVER_OPS, diff --git a/drivers/gpu/drm/tiny/cirrus-qemu.c b/drivers/gpu/drm/tiny/cirrus-qemu.c index c0ae316888e2..52ec1e4ea9e5 100644 --- a/drivers/gpu/drm/tiny/cirrus-qemu.c +++ b/drivers/gpu/drm/tiny/cirrus-qemu.c @@ -48,7 +48,6 @@ #define DRIVER_NAME "cirrus-qemu" #define DRIVER_DESC "qemu cirrus vga" -#define DRIVER_DATE "2019" #define DRIVER_MAJOR 2 #define DRIVER_MINOR 0 @@ -659,7 +658,6 @@ static const struct drm_driver cirrus_driver = { .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c index 47dbee84d58b..41e9bfb2e2ff 100644 --- a/drivers/gpu/drm/tiny/gm12u320.c +++ b/drivers/gpu/drm/tiny/gm12u320.c @@ -34,7 +34,6 @@ MODULE_PARM_DESC(eco_mode, "Turn on Eco mode (less bright, more silent)"); #define DRIVER_NAME "gm12u320" #define DRIVER_DESC "Grain Media GM12U320 USB projector display" -#define DRIVER_DATE "2019" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 @@ -626,7 +625,6 @@ static const struct drm_driver gm12u320_drm_driver = { .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c index 910279ebbbaa..df263818f45f 100644 --- a/drivers/gpu/drm/tiny/hx8357d.c +++ b/drivers/gpu/drm/tiny/hx8357d.c @@ -199,7 +199,6 @@ static const struct drm_driver hx8357d_driver = { .debugfs_init = mipi_dbi_debugfs_init, .name = "hx8357d", .desc = "HX8357D", - .date = "20181023", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/tiny/ili9163.c b/drivers/gpu/drm/tiny/ili9163.c index e54ce120692f..62cadf5e033d 100644 --- a/drivers/gpu/drm/tiny/ili9163.c +++ b/drivers/gpu/drm/tiny/ili9163.c @@ -118,7 +118,6 @@ static struct drm_driver ili9163_driver = { .debugfs_init = mipi_dbi_debugfs_init, .name = "ili9163", .desc = "Ilitek ILI9163", - .date = "20210208", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c index f322e67f473a..6de44ff69b51 100644 --- a/drivers/gpu/drm/tiny/ili9225.c +++ b/drivers/gpu/drm/tiny/ili9225.c @@ -364,7 +364,6 @@ static const struct drm_driver ili9225_driver = { DRM_FBDEV_DMA_DRIVER_OPS, .name = "ili9225", .desc = "Ilitek ILI9225", - .date = "20171106", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/tiny/ili9341.c b/drivers/gpu/drm/tiny/ili9341.c index 356c7f107c3e..e55029433509 100644 --- a/drivers/gpu/drm/tiny/ili9341.c +++ b/drivers/gpu/drm/tiny/ili9341.c @@ -155,7 +155,6 @@ static const struct drm_driver ili9341_driver = { .debugfs_init = mipi_dbi_debugfs_init, .name = "ili9341", .desc = "Ilitek ILI9341", - .date = "20180514", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c index f5b1d21f7109..093661c771a0 100644 --- a/drivers/gpu/drm/tiny/ili9486.c +++ b/drivers/gpu/drm/tiny/ili9486.c @@ -177,7 +177,6 @@ static const struct drm_driver ili9486_driver = { .debugfs_init = mipi_dbi_debugfs_init, .name = "ili9486", .desc = "Ilitek ILI9486", - .date = "20200118", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/tiny/mi0283qt.c b/drivers/gpu/drm/tiny/mi0283qt.c index 61e33376fbc9..b6b4664908ae 100644 --- a/drivers/gpu/drm/tiny/mi0283qt.c +++ b/drivers/gpu/drm/tiny/mi0283qt.c @@ -159,7 +159,6 @@ static const struct drm_driver mi0283qt_driver = { .debugfs_init = mipi_dbi_debugfs_init, .name = "mi0283qt", .desc = "Multi-Inno MI0283QT", - .date = "20160614", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/tiny/ofdrm.c b/drivers/gpu/drm/tiny/ofdrm.c index b27ed3677bfd..cd5916752507 100644 --- a/drivers/gpu/drm/tiny/ofdrm.c +++ b/drivers/gpu/drm/tiny/ofdrm.c @@ -25,7 +25,6 @@ #define DRIVER_NAME "ofdrm" #define DRIVER_DESC "DRM driver for OF platform devices" -#define DRIVER_DATE "20220501" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 @@ -1348,7 +1347,6 @@ static struct drm_driver ofdrm_driver = { DRM_FBDEV_SHMEM_DRIVER_OPS, .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .driver_features = DRIVER_ATOMIC | DRIVER_GEM | DRIVER_MODESET, diff --git a/drivers/gpu/drm/tiny/panel-mipi-dbi.c b/drivers/gpu/drm/tiny/panel-mipi-dbi.c index 79d5818cbbe6..4786b8144a9f 100644 --- a/drivers/gpu/drm/tiny/panel-mipi-dbi.c +++ b/drivers/gpu/drm/tiny/panel-mipi-dbi.c @@ -269,7 +269,6 @@ static const struct drm_driver panel_mipi_dbi_driver = { .debugfs_init = mipi_dbi_debugfs_init, .name = "panel-mipi-dbi", .desc = "MIPI DBI compatible display panel", - .date = "20220103", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gpu/drm/tiny/repaper.c index 9373063a13fc..52ba6c699bc8 100644 --- a/drivers/gpu/drm/tiny/repaper.c +++ b/drivers/gpu/drm/tiny/repaper.c @@ -917,7 +917,6 @@ static const struct drm_driver repaper_driver = { DRM_FBDEV_DMA_DRIVER_OPS, .name = "repaper", .desc = "Pervasive Displays RePaper e-ink panels", - .date = "20170405", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/tiny/sharp-memory.c b/drivers/gpu/drm/tiny/sharp-memory.c index d87068126f9b..03d2850310c4 100644 --- a/drivers/gpu/drm/tiny/sharp-memory.c +++ b/drivers/gpu/drm/tiny/sharp-memory.c @@ -107,7 +107,6 @@ static const struct drm_driver sharp_memory_drm_driver = { DRM_FBDEV_DMA_DRIVER_OPS, .name = "sharp_memory_display", .desc = "Sharp Display Memory LCD", - .date = "20231129", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c index b3a2fc11dcf0..b47ca2d902d9 100644 --- a/drivers/gpu/drm/tiny/simpledrm.c +++ b/drivers/gpu/drm/tiny/simpledrm.c @@ -31,7 +31,6 @@ #define DRIVER_NAME "simpledrm" #define DRIVER_DESC "DRM driver for simple-framebuffer platform devices" -#define DRIVER_DATE "20200625" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 @@ -1015,7 +1014,6 @@ static struct drm_driver simpledrm_driver = { DRM_FBDEV_SHMEM_DRIVER_OPS, .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .driver_features = DRIVER_ATOMIC | DRIVER_GEM | DRIVER_MODESET, diff --git a/drivers/gpu/drm/tiny/st7586.c b/drivers/gpu/drm/tiny/st7586.c index 7bfd4296c1c9..a29672d84ede 100644 --- a/drivers/gpu/drm/tiny/st7586.c +++ b/drivers/gpu/drm/tiny/st7586.c @@ -295,7 +295,6 @@ static const struct drm_driver st7586_driver = { .debugfs_init = mipi_dbi_debugfs_init, .name = "st7586", .desc = "Sitronix ST7586", - .date = "20170801", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/tiny/st7735r.c b/drivers/gpu/drm/tiny/st7735r.c index 6832ca590127..1d60f6e5b3bc 100644 --- a/drivers/gpu/drm/tiny/st7735r.c +++ b/drivers/gpu/drm/tiny/st7735r.c @@ -160,7 +160,6 @@ static const struct drm_driver st7735r_driver = { .debugfs_init = mipi_dbi_debugfs_init, .name = "st7735r", .desc = "Sitronix ST7735R", - .date = "20171128", .major = 1, .minor = 0, }; diff --git a/drivers/gpu/drm/tve200/tve200_drv.c b/drivers/gpu/drm/tve200/tve200_drv.c index cb66dbbe2801..65a0d4301160 100644 --- a/drivers/gpu/drm/tve200/tve200_drv.c +++ b/drivers/gpu/drm/tve200/tve200_drv.c @@ -146,7 +146,6 @@ static const struct drm_driver tve200_drm_driver = { .fops = &drm_fops, .name = "tve200", .desc = DRIVER_DESC, - .date = "20170703", .major = 1, .minor = 0, .patchlevel = 0, diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c index 6c182b21028e..05b3a152cc33 100644 --- a/drivers/gpu/drm/udl/udl_drv.c +++ b/drivers/gpu/drm/udl/udl_drv.c @@ -78,7 +78,6 @@ static const struct drm_driver driver = { .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL, diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h index 1eb716d9dad5..be00dc1d87a1 100644 --- a/drivers/gpu/drm/udl/udl_drv.h +++ b/drivers/gpu/drm/udl/udl_drv.h @@ -26,7 +26,6 @@ struct drm_mode_create_dumb; #define DRIVER_NAME "udl" #define DRIVER_DESC "DisplayLink" -#define DRIVER_DATE "20120220" #define DRIVER_MAJOR 0 #define DRIVER_MINOR 0 diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c index fb35c5c3f1a7..9d8de9146cb0 100644 --- a/drivers/gpu/drm/v3d/v3d_drv.c +++ b/drivers/gpu/drm/v3d/v3d_drv.c @@ -31,7 +31,6 @@ #define DRIVER_NAME "v3d" #define DRIVER_DESC "Broadcom V3D graphics" -#define DRIVER_DATE "20180419" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 #define DRIVER_PATCHLEVEL 0 @@ -248,7 +247,6 @@ static const struct drm_driver v3d_drm_driver = { .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL, diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c b/drivers/gpu/drm/vboxvideo/vbox_drv.c index d9d884aad97f..bb861f0a0a31 100644 --- a/drivers/gpu/drm/vboxvideo/vbox_drv.c +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c @@ -189,7 +189,6 @@ static const struct drm_driver driver = { .fops = &vbox_fops, .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL, diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h b/drivers/gpu/drm/vboxvideo/vbox_drv.h index e77bd6512eb1..dfa935f381a6 100644 --- a/drivers/gpu/drm/vboxvideo/vbox_drv.h +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h @@ -25,7 +25,6 @@ #define DRIVER_NAME "vboxvideo" #define DRIVER_DESC "Oracle VM VirtualBox Graphics Card" -#define DRIVER_DATE "20130823" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c index ee5df153c2a6..e88a7ee486c6 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.c +++ b/drivers/gpu/drm/vc4/vc4_drv.c @@ -47,7 +47,6 @@ #define DRIVER_NAME "vc4" #define DRIVER_DESC "Broadcom VC4 graphics" -#define DRIVER_DATE "20140616" #define DRIVER_MAJOR 0 #define DRIVER_MINOR 0 #define DRIVER_PATCHLEVEL 0 @@ -222,7 +221,6 @@ const struct drm_driver vc4_drm_driver = { .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL, @@ -244,7 +242,6 @@ const struct drm_driver vc5_drm_driver = { .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL, diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c index c5e3e5457737..2752ab4f1c97 100644 --- a/drivers/gpu/drm/vgem/vgem_drv.c +++ b/drivers/gpu/drm/vgem/vgem_drv.c @@ -47,7 +47,6 @@ #define DRIVER_NAME "vgem" #define DRIVER_DESC "Virtual GEM provider" -#define DRIVER_DATE "20120112" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 @@ -121,7 +120,6 @@ static const struct drm_driver vgem_driver = { .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, }; diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c index e216123ce6a5..6a67c6297d58 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.c +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c @@ -201,7 +201,6 @@ static const struct drm_driver driver = { .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL, diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index 8328107edf78..f42ca9d8ed10 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -45,7 +45,6 @@ #define DRIVER_NAME "virtio_gpu" #define DRIVER_DESC "virtio GPU" -#define DRIVER_DATE "0" #define DRIVER_MAJOR 0 #define DRIVER_MINOR 1 diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c index fa3331f612e3..e0409aba9349 100644 --- a/drivers/gpu/drm/vkms/vkms_drv.c +++ b/drivers/gpu/drm/vkms/vkms_drv.c @@ -34,7 +34,6 @@ #define DRIVER_NAME "vkms" #define DRIVER_DESC "Virtual Kernel Mode Setting" -#define DRIVER_DATE "20180514" #define DRIVER_MAJOR 1 #define DRIVER_MINOR 0 @@ -116,7 +115,6 @@ static const struct drm_driver vkms_driver = { .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, }; diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c index ded48554568a..1699236fca5a 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c @@ -1634,7 +1634,6 @@ static const struct drm_driver driver = { .fops = &vmwgfx_driver_fops, .name = VMWGFX_DRIVER_NAME, .desc = VMWGFX_DRIVER_DESC, - .date = VMWGFX_DRIVER_DATE, .major = VMWGFX_DRIVER_MAJOR, .minor = VMWGFX_DRIVER_MINOR, .patchlevel = VMWGFX_DRIVER_PATCHLEVEL diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h index b21831ef214a..5275ef632d4b 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h @@ -57,7 +57,6 @@ #define VMWGFX_DRIVER_NAME "vmwgfx" -#define VMWGFX_DRIVER_DATE "20211206" #define VMWGFX_DRIVER_MAJOR 2 #define VMWGFX_DRIVER_MINOR 20 #define VMWGFX_DRIVER_PATCHLEVEL 0 diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c index d6fccea1e083..56d4ffb650da 100644 --- a/drivers/gpu/drm/xe/xe_device.c +++ b/drivers/gpu/drm/xe/xe_device.c @@ -271,7 +271,6 @@ static struct drm_driver driver = { .fops = &xe_driver_fops, .name = DRIVER_NAME, .desc = DRIVER_DESC, - .date = DRIVER_DATE, .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL, diff --git a/drivers/gpu/drm/xe/xe_drv.h b/drivers/gpu/drm/xe/xe_drv.h index d45b71426cc8..d61650d4aa0b 100644 --- a/drivers/gpu/drm/xe/xe_drv.h +++ b/drivers/gpu/drm/xe/xe_drv.h @@ -10,7 +10,6 @@ #define DRIVER_NAME "xe" #define DRIVER_DESC "Intel Xe Graphics" -#define DRIVER_DATE "20201103" /* Interface history: * diff --git a/drivers/gpu/drm/xen/xen_drm_front.c b/drivers/gpu/drm/xen/xen_drm_front.c index 931d855bfbe8..1bda7ef606cc 100644 --- a/drivers/gpu/drm/xen/xen_drm_front.c +++ b/drivers/gpu/drm/xen/xen_drm_front.c @@ -478,7 +478,6 @@ static const struct drm_driver xen_drm_driver = { .fops = &xen_drm_dev_fops, .name = "xendrm-du", .desc = "Xen PV DRM Display Unit", - .date = "20180221", .major = 1, .minor = 0, diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c index e272ecbce78d..b47463473472 100644 --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c @@ -409,7 +409,6 @@ static const struct drm_driver zynqmp_dpsub_drm_driver = { .name = "zynqmp-dpsub", .desc = "Xilinx DisplayPort Subsystem Driver", - .date = "20130509", .major = 1, .minor = 0, }; diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h index 1bbbcb8e2d23..1b6e59139e6c 100644 --- a/include/drm/drm_drv.h +++ b/include/drm/drm_drv.h @@ -401,8 +401,6 @@ struct drm_driver { char *name; /** @desc: driver description */ char *desc; - /** @date: driver date, unused, to be removed */ - char *date; /** * @driver_features: -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Wed Dec 04 14:32:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 14:32:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848587.1263452 (Exim 4.92) (envelope-from ) id 1tIqQz-00071z-8B; Wed, 04 Dec 2024 14:32:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848587.1263452; Wed, 04 Dec 2024 14:32: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 1tIqQz-00071s-49; Wed, 04 Dec 2024 14:32:57 +0000 Received: by outflank-mailman (input) for mailman id 848587; Wed, 04 Dec 2024 14:30: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 1tIqOM-0005sF-4T for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 14:30:14 +0000 Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [2607:f8b0:4864:20::832]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 452237c3-b24c-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 15:30:13 +0100 (CET) Received: by mail-qt1-x832.google.com with SMTP id d75a77b69052e-4668486dec2so50520481cf.3 for ; Wed, 04 Dec 2024 06:30:13 -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: 452237c3-b24c-11ef-a0d4-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733322611; x=1733927411; 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=l4ORUpe0pVZmQmvkw1nu+aTOjOaP1O5zfh0k3pgSPzo=; b=GVgvQ+3+LKHEMDfnYXBcetqITur8s8TnO1CafJymu78jNYMmR414HYkWAMCOWJjJ4M pNUP1AELaTPhYwT5uKJCVA7rH7AhrZGoIjz+AyINEP6IOdtk2qUwvZUMLA1xqwFW5h2b 0sIsN6g4j9GQsLlCqn9+MxggRO8TpoWQxezJbZfXSZ3+ra6DdShwx7P7dPV8jURV9Vqm h+oERGOiUVZlJbnBpxomAoWPnJgTRQVvTfouxHttxLqrISytPGzu3wyiP2RtRQsa+yiS o+zeIJ8q8nPlRDUPnzbqTL6IF4zoIY4vdOYNnBkTHcbouwm2A8bTWSVOlwj+jXjCk8Ge k5Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733322611; x=1733927411; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=l4ORUpe0pVZmQmvkw1nu+aTOjOaP1O5zfh0k3pgSPzo=; b=Z/dgYmxH4kYDBqB5P3aJWBrRQBdamizYSxdK+6RPjkVPYVQD8aPWnZoJCzVnWuvNMS yDsYxu6VUmgdRtmE5Db7ARGRj7lJbn5lNlK07daPqpuXbxliIWCvNbbu50AayqySOVQC MXJksLXUfjuOzmxWFTALuKMJrKNJA2D41erIxbwsxSnKAiBjOV+JBYAVQZlBpMFlO0wH ywIcXjZjUiqPEacFLNTCcUT2SAesgk71hRZC/0q99DBw59q9NX36Fg6yZfCpC29vVuhr x1ekZAkuJ5mYT6ZylwC3PMQXaJeg3CSm71zhnIPwSILiuoLoGh2KzF1V35HqQH4d+NrB qQHQ== X-Forwarded-Encrypted: i=1; AJvYcCWibUoZh2QAkDIHenCX6NSyJmKTIrj+CEf40hwo2FPjMRGcGAwpnV/dnNmIeORBXC+CzvJYudICSz4=@lists.xenproject.org X-Gm-Message-State: AOJu0YxWuyCLvhpbGAd4M2erLgW4TtnOl1F7XJzt3OtsMiC0sWiGmpMK eYO50KCWguLt2quXDei9Jb9+pLK6kTHihCRsSYz0gW0Bh4uHOtF/TyET3USJkKrgDoEmGCOOMOP 45o/y/4d3dlNdt12xzHRgV+AmTQc= X-Gm-Gg: ASbGnct0d8IPMoa0RZprcsAvMUv5KoSzlpqWnQiA6gaablCprrLl85L/g87Y4tCjgd6 /17wId8MJUnqKzfGxGDJD+POBsVmJEWQ= X-Google-Smtp-Source: AGHT+IFz9AqjuEgEtpGhSGQOZnrxRUdrncSun9IdkUiaSxXNrzlUhCJKBQf8IWnzX9RSbBxpI0ATkHRWJCCRT5JjEU8= X-Received: by 2002:a05:622a:1801:b0:463:60a9:74c0 with SMTP id d75a77b69052e-4670c09df44mr91467951cf.14.1733322611045; Wed, 04 Dec 2024 06:30:11 -0800 (PST) MIME-Version: 1.0 References: <20241202194107.105119-1-afd@ti.com> <20241202194107.105119-5-afd@ti.com> In-Reply-To: <20241202194107.105119-5-afd@ti.com> From: Alexey Charkov Date: Wed, 4 Dec 2024 17:30:00 +0300 Message-ID: Subject: Re: [PATCH v4 4/5] ARM: vt8500: Switch to new sys-off handler API To: Andrew Davis Cc: Arnd Bergmann , Andre Przywara , Russell King , Daniel Mack , Haojian Zhuang , Robert Jarzmik , Krzysztof Kozlowski , Stefano Stabellini , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Andrew, On Mon, Dec 2, 2024 at 10:41=E2=80=AFPM Andrew Davis wrote: > > Kernel now supports chained power-off handlers. Use > register_platform_power_off() that registers a platform level power-off > handler. Legacy pm_power_off() will be removed once all drivers and archs > are converted to the new sys-off API. > > Signed-off-by: Andrew Davis > --- > arch/arm/mach-vt8500/vt8500.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-vt8500/vt8500.c b/arch/arm/mach-vt8500/vt8500.= c > index 0ab40087ae1cc..1d294255d7083 100644 > --- a/arch/arm/mach-vt8500/vt8500.c > +++ b/arch/arm/mach-vt8500/vt8500.c > @@ -141,7 +141,7 @@ static void __init vt8500_init(void) > pr_err("%s:ioremap(power_off) failed\n", __func__= ); > } > if (pmc_base) > - pm_power_off =3D &vt8500_power_off; > + register_platform_power_off(vt8500_power_off); This really calls for a separate tiny driver under drivers/power to remove the legacy single-register remapping higher up in this function... Pending that: Acked-by: Alexey Charkov Best regards, Alexey From xen-devel-bounces@lists.xenproject.org Wed Dec 04 14:48:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 14:48:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848625.1263462 (Exim 4.92) (envelope-from ) id 1tIqfe-0000XY-Ev; Wed, 04 Dec 2024 14:48:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848625.1263462; Wed, 04 Dec 2024 14:48: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 1tIqfe-0000XR-BS; Wed, 04 Dec 2024 14:48:06 +0000 Received: by outflank-mailman (input) for mailman id 848625; Wed, 04 Dec 2024 14:48: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 1tIqfd-0000XL-2K for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 14:48:05 +0000 Received: from mail136-20.atl41.mandrillapp.com (mail136-20.atl41.mandrillapp.com [198.2.136.20]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c2ee70d5-b24e-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 15:48:03 +0100 (CET) Received: from pmta11.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail136-20.atl41.mandrillapp.com (Mailchimp) with ESMTP id 4Y3L3j0dMDzCf9Q9t for ; Wed, 4 Dec 2024 14:48:01 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 78a7af3d9efe4da895ea52e44101c412; Wed, 04 Dec 2024 14:48: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: c2ee70d5-b24e-11ef-a0d4-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1733323681; x=1733584181; bh=u35DPZ8ea1kMaR4tSzEAnpDkJRruFsNUg1/+5+OYYAY=; 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=aZ5NTpH5L0jVYhaSp06jSRH5qBinj0rX3TOqIQaKxEsm/J0i2G1S7z3JKX6KZkqdt 30Pnn1wXVsuS3i3FWXsxy+8rFryVEqk34Vj8BGfWJMuG4VV1Lqqo64dgznda6VMtm+ vn+kzE7wPmIm9hVFvyFQEWfvtPj35tRisXgQlN9FFtsXC5ht4rPYG3psOzAMdZ18H5 bHGlmFAf6/j8k0x86NX/ef/WJcrp4KyKkpLvtk2PUt8j3QrcY9kdvGCktKvcSUQx24 /6C1gNsS1fsibtgWRuImvlpi78/mKw+o+z53eQXZwhpq0WQMc99wJVi2v0wfYx81DI KG/JwIZy64Txg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1733323681; x=1733584181; i=teddy.astie@vates.tech; bh=u35DPZ8ea1kMaR4tSzEAnpDkJRruFsNUg1/+5+OYYAY=; 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=fsNVnAHqsZ2UnMRdfaXjGuKee9vrmkzZZ4GAHy11d8VxKM7ae8ph8Cdnq5I4h0z2D TTNVOAG8yXTTmWBetYtrMVbEg3CHvAtWLKha/xQW5wrSwvHK6YMQfIieMMO4rWAC7d k8YDUXi4CpCdLhdESO3ibTVFTHE7Qo9bUlTFLfPFSiGRsK5doEOsg0k4NOoa1bJ6Sh AHRjut227qC9Sj/6oi/Gvyopmo8psDQax5Kdd8Rltmne75l6GLSSRRaEVwJdVGVbKW P/Z8Bvv9NCFKnmDjIRydGN6iug0STAoa0QIECn88F7L7+oUMiR4Ay3Nrkh7gILb20b YvKvEqIJrQvAw== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[RFC=20PATCH=2019/25]=20xen:=20Replace=20hand-crafted=20domctl/createdomain=20with=20autogenerated=20version?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1733323679366 Message-Id: To: "Alejandro Vallejo" , xen-devel@lists.xenproject.org Cc: "Anthony PERARD" , "Andrew Cooper" , "Jan Beulich" , "Julien Grall" , "Stefano Stabellini" , "Daniel P. Smith" References: <20241115115200.2824-1-alejandro.vallejo@cloud.com> <20241115115200.2824-20-alejandro.vallejo@cloud.com> In-Reply-To: <20241115115200.2824-20-alejandro.vallejo@cloud.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.78a7af3d9efe4da895ea52e44101c412?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20241204:md Date: Wed, 04 Dec 2024 14:48:01 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hello, There is a alternative relevant way of representing "handle" (keeping : > +[[structs.fields]] > +name = "handle" > +description = "IN: Unique identifier for this guest given by the toolstack." > +typ = { tag = "array", args = [{ tag = "u8" }, 16] } > + We can introduce a "guest_handle" type which is represented either as : - C: xen_guest_handle_t (basically uint8_t[16]) - Rust: uuid::Uuid (which is uuid::Bytes thus [u8; 16]) [1] (we would need to add uuid = "1" as a dependency on xen-sys) The toolstack currently uses and represents this handle as a UUID, so I suppose we can keep this representation and being able to manipulate those as Uuid as well (and having new_v4 functions and similar). [1] https://docs.rs/uuid/1.11.0/uuid/struct.Uuid.html#abi Cheers Teddy Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Wed Dec 04 15:23:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 15:23:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848635.1263472 (Exim 4.92) (envelope-from ) id 1tIrDX-0005re-LC; Wed, 04 Dec 2024 15:23:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848635.1263472; Wed, 04 Dec 2024 15:23: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 1tIrDX-0005rX-IH; Wed, 04 Dec 2024 15:23:07 +0000 Received: by outflank-mailman (input) for mailman id 848635; Wed, 04 Dec 2024 15:23: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 1tIrDW-0005rR-Cr for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 15:23:06 +0000 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam04on20614.outbound.protection.outlook.com [2a01:111:f403:240a::614]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a7499f94-b253-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 16:23:04 +0100 (CET) Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7) by CYYPR12MB8937.namprd12.prod.outlook.com (2603:10b6:930:cb::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.20; Wed, 4 Dec 2024 15:22:59 +0000 Received: from PH8PR12MB7326.namprd12.prod.outlook.com ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com ([fe80::6d76:9c33:d230:8264%6]) with mapi id 15.20.8230.010; Wed, 4 Dec 2024 15:22: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: a7499f94-b253-11ef-a0d4-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NlQCXePat+yJaJfC6Wbh70X3v5SSdgoG4N61Z9Tf3GmLNOfvAw2BlkPd5TUbE7IYGwhulIY323xO/47hUq3Y75vrBqNnwSQ7HAPjpEjpFH5XFcwmyt5HbMB/elky58HBCqWLWbMlKtv/+OlqMSZ9E6BsS/C7yVVY+ZdSknkmcWBi8wynz5RKP6JzJow7P3kzhKzyp6zuk9BFPxdmfoeEIGZACWmF6aO8pd4WAy6OYqxFHxAkId8+WMVBo8b3eOw7DUPPRv+D64rQpscvK+c87v80gohyxKVapYMyjk/9+SWiINgJDHzgfgOTrgmPOzehB/+Q3BMIo57o/XdzOUvg9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uDvX3WI++Ebn5mIbPO9jEB/bjvBn2cBlAmji3v+1rzA=; b=DDgVD/GEgP8xtTZ/O+DOhTd2ZBZM/eDxWOSvg1ZuhqbyWYC5fwfxycVvvDMzCLaXBWSckWzjfj8Y7FiHPjA8BBk4HnMH47ycbcJWCOqO9n1lUDL+zaHVrNwkJo717NG6xSfs+gwP3WkctDLstx6S3j3KCA1IEztTNl6yTOF0KkyQy6ueDASXR1R6hhIfG/w8HCy0/m4qx9iiWxRb4pr+dZSGjChTvs0EmmaErA8Hp0MvArVaZghkZ38fPzeVU995GTyz0OPPkaLuRw3VMJqc+5vGTq0pzH0o4Co378IbRscfJ1XuIQOhWUX4jM7A1+VfaOkajl+BsWrSEFdcM7FzYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uDvX3WI++Ebn5mIbPO9jEB/bjvBn2cBlAmji3v+1rzA=; b=KwXl1jLjFb/HyAprur8bITVWtBjyIKeG6Qe5CJxrFROf/DVu48ZbfBN6OKzsQ3DbkMGWileI1A3S6ZzjV78jQefuej1FWPzoTnzzcbTrpPP7gD6KGjWMvgaHc+J8lsN83kb54SZvEW/7h08t3NEDShGUoxLHCIaDvZNKGz+4AnM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <9fa5a82f-d1cf-403b-9488-64494324e438@amd.com> Date: Wed, 4 Dec 2024 15:22:53 +0000 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] docs: fusa: Add dom0less domain configuration requirements Content-Language: en-GB To: Bertrand Marquis , Julien Grall Cc: Ayan Kumar Halder , "xen-devel@lists.xenproject.org" , Michal Orzel , Stefano Stabellini , Artem Mygaiev , Munakata Hisao References: <20241018155144.3433395-1-ayan.kumar.halder@amd.com> <4dbf2c4d-f7bd-4032-b52f-29c24e3ec055@xen.org> <22282f26-5c66-444b-b63a-d5442e6fcdad@amd.com> <04a358de-ed76-46b4-bc09-f3f343e09186@xen.org> <1E89C10B-2307-4076-A018-0E1722DD22EC@arm.com> From: Ayan Kumar Halder In-Reply-To: <1E89C10B-2307-4076-A018-0E1722DD22EC@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0051.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:152::20) To PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|CYYPR12MB8937:EE_ X-MS-Office365-Filtering-Correlation-Id: 2dda5ba0-0141-4847-eb7b-08dd14778920 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: =?utf-8?B?MlMvT3NML01jVGNGYmt5MUNDQlRZd01zL05HSUZ4c0dBa05kSDZjY0c4UDkz?= =?utf-8?B?UkRmMmlWR0tHakprWk8ya2hoTnhaTTlnZGxrZmx5WEgzQ2RmUm5mYWF2YkZO?= =?utf-8?B?U2tTYk1MU2xJeHFTSTFFVGM4YkZ5Tk5pUjhNS1hEdXVnU3BJN205Mk5XUW1S?= =?utf-8?B?L21abEk3WlZCSWNoVUg5STJ4UGFKcVc2Rm1oQU9ZdzUzREtEaklOQjF6Smk2?= =?utf-8?B?N2JkRHpleFpVOFZGSWZzOWY0eXRrMXVCTGlaSkh4ZG9PcVJoWHBpcS9HTWNU?= =?utf-8?B?WWlTK21YSkVPRU42NXBUTkR6aCttUDM4REZsT2NGZjF3cXZKb3B4QzBJcVY3?= =?utf-8?B?TnpFSStrbGRNMTVvbkt5d082VXk2N0l4QVd1RjRpeTdGMlJ4ZXlOZTNscFV4?= =?utf-8?B?eXo3dk5yeHo0N2IrdXdkTFBCVDBSeVlReGtXS0VLQmNUTE1ONzdHN28xbjdz?= =?utf-8?B?OVd3VFVSM3RUMzd1QkFzSXNaSnVtTUtKZFEvblpiYVhTVmUwWGtydHpYUHVm?= =?utf-8?B?ek5NQUxvREpsTHdRcUtzZ3BORW9iSVBvZmZCMnZiUkxtbVBSekRzLzZlbEx1?= =?utf-8?B?dWdKU1hRN3NJcUlKVVJVc0c4YVQ0R1pNT2FWNVVXSXpkN05CejBjTTBXcFA1?= =?utf-8?B?Uk9TbzVaN1k4YUtoOWtGZU5TK2c0anFjUEhYNjc1am1ocmdiUndIVnhEbTlu?= =?utf-8?B?U0RtVTVjZVYrZDMrQ3hvMXZUaUJVa01RRXNsVXllM2pUSHFPQzVZTG9SSVZW?= =?utf-8?B?Z0J5Und2eCtQeE43eXAwUXNlcWNxUFdsZmF1WXlDUDUzeFVIWnExZ2RIc0xE?= =?utf-8?B?UHV4N29wckY0YXc5UXhySTc5SGhqZWxMTnBQMEJBTlE5ZDhRa3JZZjlkUEI4?= =?utf-8?B?WWVjTGxHVWN5TGkzUU10V0ZHKzd0WW9zOUR0VU5EeURBbnZ3a0dtNFJLWk92?= =?utf-8?B?MWI3S0t4Ni92SWFaOXBpOGw5ZWNNS1F6VXMrRS91Vy9GWlRNa0lMbGxoblFu?= =?utf-8?B?ZFIvSnlYcFdIWkxIRXZlUXZZLzJKaTd0K2xtZDYza0JkQ3hKTzRyWm5SeVhz?= =?utf-8?B?OTY1QzZjTzRaS05Henl1c29KU2xGWFRLbk5YZDdoOHZaaXR3VG56RFcvb1Bq?= =?utf-8?B?ZUNmcUZJWXFwRXQyZmVLSVVHMDVxdVlGVmJveWtlSW9SNXF1Y3hiUjJOeEtY?= =?utf-8?B?Z0V1V2FrVEVHazdhMkswcUNJN1ppNzJpbW1HV0dHK3RXSXlYWVYwMHI2Z0M1?= =?utf-8?B?WEdiWHpTazVONmUxZHdkOEJyVFRCeDlycjh1c0RPZlJxRTE1bGRFOTBzVUMv?= =?utf-8?B?WEYyR0lCSUc3cTdOV2pxS3Q0TE5FU0E3N2s3WWtLdVkwdlA3TGFSRUZaeGpS?= =?utf-8?B?a3MySlcvaHhubTgrT3ovbDJ0ZGU2OUQ2cS9mQXd2WTNSN3F1ODlxQk9LT0J3?= =?utf-8?B?OU1ySGRKL3NTNHZMdStiUEcxUWFCUWNpelc1UndlWkpDY242Vi9yb2dITmt6?= =?utf-8?B?Tlo5WkFQa21yZEdqSXFVMTQzUThuUGxrMjdvRXk0YWZYTmc1WXhXQUh4WWFs?= =?utf-8?B?dWFzMlNKMzE2V2lpbTk1bmEzRmJ4UHIvN0RheG9jSEFva0dzUGhCVUtESHRL?= =?utf-8?B?SmJPeW00c1RPbDNwQmsyVWQ0Nm9QTXpGai9lOWNLZkpaM21NbnBMUytFekQy?= =?utf-8?B?UzB2WlBzeUhhdWlOUFEySkhra1Q4THpJWno4N0ZNVkhyQnVlSVBic2FRbUZw?= =?utf-8?B?b2JtQUZYQ3VMaW15NjltaGJHQzZpNWdMeTFiS2xTbnhFTngzZmdlUlRKZ2My?= =?utf-8?B?cjdmcHdlY1loclZpdjRtZz09?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH8PR12MB7326.namprd12.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?bXJmNGd1OVVRQnJDUk1LWDZuQ2tUZHNCRUVhMjNkbXZWaUV1OTNkNDE5cW84?= =?utf-8?B?K2dEWDRHa0NIamJtamY1YWF5T2h3akNqcUJ1ZTNIeWpOTHR0MWtiUGI0SEpP?= =?utf-8?B?NGN4cnozN2c3dnRNTDZ0UENXVXZSdzFkT0xpQXZ6WVh4V3FybVFubjFGUW1i?= =?utf-8?B?dWg1MEhMeGVXRGJtekVqdmc2ZVBhV2J3K2p0SlJjOHpBWHlhcTVqOWx1WEZ2?= =?utf-8?B?NW1tdmRPWnJBeUFHMWZLSTFNZ3JUdEtnOEN1d2RtSFBmQWUrbzJzS1VSTWwz?= =?utf-8?B?ekFwU3dHa1FpbEF1TGxPRmhsdmVyQThVUkZ1cTIvM1VyL0JnUHRsc2RNMXhn?= =?utf-8?B?aEx6QldRQStQcDV0RngzMytIL0dKQW8vZTFHSVVZaVlWMFNpWE5VSFQ5b0dD?= =?utf-8?B?VllhdkJ0WGcya2R6Wk9PaDNodTBJNXVEUHBpd1dueS9aS0ZuWW12WlBlNHVZ?= =?utf-8?B?cGxJYVJpUzlaY0FLNHc2SEJzZ0cvTmpCUk5QUFpSdlVJU1FLSWh5RE9zMksy?= =?utf-8?B?RFJwaTZLZ1V4UWlrUXh1aGI4WTNiS0o5czB5NkJ3bXI3bVk1cW5tRkptK1Zi?= =?utf-8?B?QURPSlR3MDVMeXVjTFlCSDdkYndGYllMK0ZMWkFyRnU2SS9JQ0c5VEVBalNl?= =?utf-8?B?SzhmMnpaV0lrMmQyZUtLOWpTSS9hS2VpWW05aVNSb04xWnBrRXBJSVVUSGFs?= =?utf-8?B?U2ZwZHJJaXo2amxCQ2NyRmM1UzdTZU4weTk5SkgwWk05a3lyTUdTSzRBamZh?= =?utf-8?B?RFhvUCtFVW5KdStFSkxTWXNqNklhK0xGb0VRQlRIY043RkZEMmowSysyWlV0?= =?utf-8?B?WlZFVzBLVEJFMTJPbk1iZXZDR2FJelhaOUJzYmY2dkxaVUdYSEZaN2dURTJQ?= =?utf-8?B?UzlDalJQQTFZQ29qZnN4UnZvdDNCblhBVkxkNUIvckF1NWt0azQ4TVNpR0lK?= =?utf-8?B?M1k3dFhZYWVxOTBCSUMrZVJuREdSN3gvT3QzQ040citFYlVmRlc2Wk5oQ2VK?= =?utf-8?B?VkF2Tm10WldEdC8wbkhmV1gwbFRJdHFrcUN6dk9XbEpuUllBMkFMVHBsTXg4?= =?utf-8?B?eDlTUjlYYURIUktkTUpnbjVnZVoreW1hNDBzWHhuQUpxYWRsL1U5NDF4WnRN?= =?utf-8?B?VTd5R1pCSlZsRlFwWXpNb1I2U05wYitmeERIOHhlWUluL0ZvaGxTTEJaUHA3?= =?utf-8?B?cmIrVEV3UytwTmFHNkZ4RmVhcmZvVU0zSXYzNm9nbmdsMVo3dlZUelRBeVZT?= =?utf-8?B?RSszb25nNXo4K3E4eEdNZnZHNC95ekVZM0dmYUhFTVVyQW96RGd1a3hjT255?= =?utf-8?B?MTNvd1A4Q1pOY3dNcWd5REZ3SXh6NG1qRW8vbStDZEFWb3VCMGJCTFJneitK?= =?utf-8?B?TitkQlllMnB4UysyRzhiZ0F5b1ZPb1V0cEhyajU5aWw4cmVzbGFqcXZNcVFm?= =?utf-8?B?ZWFvVG02VThOQ3pnUkIxUFRXU3RBSzBpUURNMHNxR0M5d2lkdktQWWZVYzlZ?= =?utf-8?B?b1I4UFk2NnRmZERhY1czTVVNUFhNc1VNMVBLd0hIZ3N3d21aOW8yR1Z3emIx?= =?utf-8?B?QTdDRWVsQXU4aE50U0g3VjlMaG5JWEo1Y0s0VWNNUVU4MXdnOTh2b3ZsaHRQ?= =?utf-8?B?SXllT204OFhqdzRHdXZSNFhuaVdScjFDVFhVaHVpeksrWjZCeitmTFpMdkVQ?= =?utf-8?B?S1J0TlV2dlVNd0ZzbnpGcjFBdUFTa25hWnFVQW9CRHk4Z1lOaW5FdnZyNUpW?= =?utf-8?B?Y2hKTlA0SFJNOTVZR2F2dVdBbjZyMVhxbWFKV3ZGREl0dS8zZ29Db3UwZjk1?= =?utf-8?B?TGNQOHQrZ0FCdFk4a2FyZDNFSGt1RGpUUkFuaGJrOTZWS2NOb29FcUpmakV3?= =?utf-8?B?a1l0Y0EwNFpOejNHNU0xM3V4MGphUXg2RXZVREhtUWFydVpVY1pqNmd4UDJB?= =?utf-8?B?UzNDUHd5NlBmbENqc1BDOFZ6dmxFYXR2T0NuRHdPdm1YZllUbFFPaC9CbGZO?= =?utf-8?B?SUdyVWZoWXBtd2JlSXFPOGRlWEMyZE5scy94Z3paMFc4b1dSQjV0WitucWc4?= =?utf-8?B?emZZc3U3S2h1TXNOT2o3NjFUQXVKRHJXRTZLQjg2U0FQdVViSHJLYThIRGRI?= =?utf-8?Q?ahIn0IbRFvRNCzFmwnQVrIWEx?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2dda5ba0-0141-4847-eb7b-08dd14778920 X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2024 15:22:59.4404 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: j4Q9ZpkkMdBM2DfmP8k8FjnqNQnzLnXW3shhhy7i51bJIZtxAWZIGdTCs8NX4ZCULufYxCIHjGaPsBVV/D/Uaw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8937 On 19/11/2024 09:04, Bertrand Marquis wrote: > Hi Ayan and Julien, Hi, > >> On 16 Nov 2024, at 10:57, Julien Grall wrote: >> >> Hi Ayan, >> >> On 15/11/2024 18:53, Ayan Kumar Halder wrote: >>>>> +Assign vCPUs from CPU pool >>>>> +-------------------------- >>>>> + >>>>> +`XenSwdgn~arm64_assign_vcpus_cpu_pool~1` >>>>> + >>>>> +Description: >>>>> +Xen shall assign vCPUs to a domain from a CPU pool. >>>> Same remark about the wording. You create a domain with N vCPUs and *assign* a CPU pool to a domain. >>> Ok, so all the previous 3 requirements can be merged into >>> Xen shall create a domain with N vCPUs and assign a CPU pool to a domain. >>> Or >>> Xen shall create a domain with N vCPUs. >> I think this one is better because it is not mandatory for the user to select a CPU pool and you will have it ... >> >>> (which of the two looks better to you if we keep the next requirement ?) >> ... by the next one. >> >>> Comments: >>> Here N is determined by the device tree configuration provided by the user. >>>> You also assign pCPU to a CPU pool. >>>> >>>> But I am not sure about if this requirement is actually necessary given ... >>>> >>>>> + >>>>> +Rationale: >>>>> + >>>>> +Comments: >>>>> + >>>>> +Covers: >>>>> + - `XenProd~static_domains_configuration~1` >>>>> + >>>>> +Specify CPU pool scheduler >>>>> +-------------------------- >>>>> + >>>>> +`XenSwdgn~arm64_specify_cpu_pool_scheduler~1` >>>>> + >>>>> +Description: >>>>> +Xen shall assign a CPU pool scheduler to a domain. >>>> ... you have th is one. >>> So, we can keep it as it is. >>>>> + >>>>> +Rationale: >>>>> + >>>>> +Comments: >>>>> + >>>>> +Covers: >>>>> + - `XenProd~static_domains_configuration~1` >>>>> + >>>>> +Assign virtual UART >>>>> +------------------- >>>>> + >>>>> +`XenSwdgn~arm64_assign_virtual_uart~1` >>>>> + >>>>> +Description: >>>>> +Xen shall assign a virtual UART to a domain. >>>> Are we talking about the virtual PL011 or the fake emulation of the real UART we do? >>> virtual PL011. >> Is it possible to specify it in the market requirements? >> >> [...] >> >>>>> + >>>>> +Static VM definition >>>>> +-------------------- >>>>> + >>>>> +`XenMkt~static_vm_definition~1` >>>>> + >>>>> +Description: >>>>> +Xen shall support specifying resources for a domain. >>>> Compare to the other requirements, this is quite a vague. Should we list the resources? >>> The list of resources depends on what the user has provided in the device tree configuration. >>> But the requirement is correct as it is. Xen allows direct assignment of devices to domains (ie passthrough). >>> How do you want to write it ? >> This is probably a better question for Bertrand. I don't know how market requirements are usually described. I was making a comparison with the other where you explicitely listed the expected resources (e.g. CPU, Memory, device). > I definitely agree with Julien here, this requirement is not clear as "resources" is not specified or defined. > I would highly suggest to be more specific by listing what we mean by resources and maybe even split this requirement in several to make testing and linking easier. As per our discussion , the market requirement should be Xen shall support assigning peripherals to various domains. Comment: /* we need to define peripheral */ Peripheral implies an iomem (input output memory) and/or interrupts. (This aligns with our definition of market requirement where we specify the capabilities of Xen at a high level.) And the product requirements should be 1. Xen shall support assigning iomem to a domain. 2. Xen shall support forwarding interrupts to a domain. (Here, we try to describe the interface between Xen and domain. So, domains unterstand how Xen will interact with them.) The design requirements will be 1. Xen shall create a mapping for iomem in stage 2 page tables. 2. Xen shall route the interrupts to the domains. 3. Xen shall add iommu master (if present) for the iomem, to the domain's device tree. 4. Xen shall add the iomem to its iommu master. 5. Xen shall allow assignment of iomem without iommu protection. The design requirements are still a bit high level ie it does not describe the details (at register level or granular level) of how Xen creates a mapping (for eg). The advantage is that the requirements will be linked to the top level functions. It will allow the underneath functions to change without requiring us to modify the requirements. Besides, it will help us to provide some justification for the missing coverage at the lower level (ie we can say that we don't really care if Xen chooses to  perform a manual translation vs hardware translation. ) - Ayan > > Cheers > Bertrand > >> Cheers, >> >> -- >> Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Dec 04 16:24:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 16:24:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848646.1263481 (Exim 4.92) (envelope-from ) id 1tIsB7-0005En-0P; Wed, 04 Dec 2024 16:24:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848646.1263481; Wed, 04 Dec 2024 16:24: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 1tIsB6-0005Eg-U8; Wed, 04 Dec 2024 16:24:40 +0000 Received: by outflank-mailman (input) for mailman id 848646; Wed, 04 Dec 2024 16:24: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 1tIsB5-0005Ea-KL for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 16:24:39 +0000 Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3ffbf54e-b25c-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 17:24:37 +0100 (CET) Received: by mx.zohomail.com with SMTPS id 173332946810217.00801812770635; Wed, 4 Dec 2024 08:24: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: 3ffbf54e-b25c-11ef-a0d4-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; t=1733329470; cv=none; d=zohomail.com; s=zohoarc; b=WNq13jO1YktDI/g1fnvrIExCRVTunQiDgEMKtqnGifs+T+3BDDLCCZzYnfF4jE7MhlVVA51TUuwu/Offdl6YJQcHtZ8WOJ3tCrxyM7vS2KKdxpszYRufMH3mXMuuAqlE+NwzZI8OC7AeJlMq0ISbJrUpC11UZHxlXyrune6gZ/8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1733329470; 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=RxgYDXsBYiRkEpYFcGDo2cbsf/3SzYXigoj7D8z8bSc=; b=gVx9Ick3So0c3yGCbfhAHhKZrpSw69kTdn2gErFhP0pMS+5iqvWEx8igDof9qFwTR8ohldBQj1NfeBozG20zZzjVIlrvqY9ytdBdgkmM03ortgY5DsSn9efVdPibP6rjr2SprRIGxjF6TnNlWyWf+UcVf3+s4syougKRN6LI98Y= 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=1733329470; s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=RxgYDXsBYiRkEpYFcGDo2cbsf/3SzYXigoj7D8z8bSc=; b=WAIZfcoNXyTgFZUdt3MQwa6PQ+cx9/R/fYOMP70aRZ1MkKQQBR6R8fwsxWriM0Yd 5U3Z1NldYmWzp2qtdlUWI41n5YjuWP4KwuB6s10h2MFkIjHoZ9r6nRhEPs3P5uipEwt V21RcOO0d0qNss5JoR6Ut4kM8rjoJ6U9bsdAJ5VY= Message-ID: <3da1fda2-21ee-4768-acc3-34133a6aa05b@apertussolutions.com> Date: Wed, 4 Dec 2024 11:24:26 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 4/6] x86/boot: introduce boot domain To: Jan Beulich Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com, stefano.stabellini@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241115131204.32135-1-dpsmith@apertussolutions.com> <20241115131204.32135-5-dpsmith@apertussolutions.com> <6c2defc4-f8ae-4d5a-a9b8-721f168e6520@suse.com> Content-Language: en-US From: "Daniel P. Smith" In-Reply-To: <6c2defc4-f8ae-4d5a-a9b8-721f168e6520@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ZohoMailClient: External On 11/27/24 05:22, Jan Beulich wrote: > On 15.11.2024 14:12, Daniel P. Smith wrote: >> --- /dev/null >> +++ b/xen/arch/x86/include/asm/bootdomain.h >> @@ -0,0 +1,31 @@ >> +/* SPDX-License-Identifier: GPL-2.0-or-later */ >> +/* >> + * Copyright (c) 2024 Apertus Solutions, LLC >> + * Author: Daniel P. Smith >> + * Copyright (c) 2024 Christopher Clark >> + */ >> + >> +#ifndef __XEN_X86_BOOTDOMAIN_H__ >> +#define __XEN_X86_BOOTDOMAIN_H__ >> + >> +struct boot_module; >> +struct domain; > > You don't really need these, do you? The uses ... Your are correct, they are not necessary for C to compile. I can drop them. v/r, dps From xen-devel-bounces@lists.xenproject.org Wed Dec 04 16:45:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 16:45:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848661.1263492 (Exim 4.92) (envelope-from ) id 1tIsVR-000814-RT; Wed, 04 Dec 2024 16:45:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848661.1263492; Wed, 04 Dec 2024 16:45:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIsVR-00080x-NV; Wed, 04 Dec 2024 16:45:41 +0000 Received: by outflank-mailman (input) for mailman id 848661; Wed, 04 Dec 2024 16:45: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 1tIsVQ-00080r-Nz for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 16:45:40 +0000 Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3089a7f7-b25f-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 17:45:39 +0100 (CET) Received: by mx.zohomail.com with SMTPS id 1733330728970124.90999914480108; Wed, 4 Dec 2024 08:45: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: 3089a7f7-b25f-11ef-a0d4-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; t=1733330731; cv=none; d=zohomail.com; s=zohoarc; b=Ih+JLt6WwtUUKccZlxJU04kb/xN7CF5dfbXvs0P4dsb3QzWKL7eO0/947oFTK49Gf2MREapois0FJm17G5/u4TVtd4CVPd7cwlWX/cAVpQy6AHOupvv4e0CLIjeSseXdHKrwxJq1COXJfjWpZBm5/ci2GhWgOtP/n8mQuWOElx0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1733330731; 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=+3MltfeL075nxvUxpT+/pW7oy/jG3RGsnr1IUjpw0R0=; b=IQ0n7DiQXlEClq4F0ZHGFZEUSQSG/xcI20icf0H0lO92YzRu2csfrZfhxWogT2MfsH0H/la+Ux3Qs+ILMtcvl3xZtFO0f3spw5MvqXup+x8Dy4TjOe0wA2SBsge2gWu0C6J0+wP88VQ58uFhJaYVWMKYwLLCpNyRFzh70EC4tQQ= 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=1733330731; s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=+3MltfeL075nxvUxpT+/pW7oy/jG3RGsnr1IUjpw0R0=; b=PT6PpZrkBJe7SaMbLy+f+ctgJfS8frR5eK30lWXWMC3O7EhFSlCIZdfVMIIHlpX/ 1GyaI5szVFxnRPHAUD+ruAktYdFWI3pM6IbpgxvSjUpthvy4kE/yWbKmh4cBATGAx5y O24f4dskllhznSpFQ1fluESXWrDkU7kV9NrljMEE= Message-ID: <83e3b0a9-e0e6-4d36-a3ce-4687b1886733@apertussolutions.com> Date: Wed, 4 Dec 2024 11:45:27 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 5/6] x86/boot: introduce domid field to struct boot_domain To: Jan Beulich Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com, stefano.stabellini@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241115131204.32135-1-dpsmith@apertussolutions.com> <20241115131204.32135-6-dpsmith@apertussolutions.com> Content-Language: en-US From: "Daniel P. Smith" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ZohoMailClient: External On 11/27/24 05:32, Jan Beulich wrote: > On 15.11.2024 14:12, Daniel P. Smith wrote: >> Add a domid field to struct boot_domain to hold the assigned domain id for the >> domain. During initialization, ensure all instances of struct boot_domain have >> the invalid domid to ensure that the domid must be set either by convention or >> configuration. > > I'm missing the "why" part here - after all ... Which is part of why I rolled these over into the dom0 device tree series, as it will provide more context to its purpose. This field is used to store the value parsed in from the device tree. In dom0 device tree series, this commit could be merged with the commit that introduces the device tree parsing for domid to provide better context for the introduction of the structure element. >> --- a/xen/arch/x86/include/asm/bootdomain.h >> +++ b/xen/arch/x86/include/asm/bootdomain.h >> @@ -12,6 +12,8 @@ struct boot_module; >> struct domain; >> >> struct boot_domain { >> + domid_t domid; >> + >> struct boot_module *kernel; >> struct boot_module *ramdisk; >> > > ... just out of context here there is struct domain *. I can only guess that > the domain ID is needed for the time until the domain pointer was actually > filled. Correct, thus why it makes more sense to merge with the domid device tree parsing. >> --- a/xen/arch/x86/setup.c >> +++ b/xen/arch/x86/setup.c >> @@ -339,6 +339,9 @@ static struct boot_info *__init multiboot_fill_boot_info( >> /* Variable 'i' should be one entry past the last module. */ >> bi->mods[i].type = BOOTMOD_XEN; >> >> + for ( i = 0; i < MAX_NR_BOOTDOMS; i++ ) >> + bi->domains[i].domid = DOMID_INVALID; > > Generally I think ARRAY_SIZE() is better to use for loop boundaries. Yet > then - why don't you statically initialize the array in xen_boot_info? I indifferent with ARRAY_SIZE(), I will try and keep that in mind for future parts of the series. As for static init'ing, good point since we are already doing it with other fields, I can add this to it. >> @@ -977,7 +980,6 @@ static struct domain *__init create_dom0(struct boot_info *bi) >> }; >> struct boot_domain *bd = &bi->domains[0]; >> struct domain *d; >> - domid_t domid; >> >> if ( opt_dom0_pvh ) >> { >> @@ -993,15 +995,15 @@ static struct domain *__init create_dom0(struct boot_info *bi) >> dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu; >> >> /* Create initial domain. Not d0 for pvshim. */ >> - domid = get_initial_domain_id(); >> - d = domain_create(domid, &dom0_cfg, pv_shim ? 0 : CDF_privileged); >> + bd->domid = get_initial_domain_id(); >> + d = domain_create(bd->domid, &dom0_cfg, pv_shim ? 0 : CDF_privileged); >> if ( IS_ERR(d) ) >> - panic("Error creating d%u: %ld\n", domid, PTR_ERR(d)); >> + panic("Error creating d%u: %ld\n", bd->domid, PTR_ERR(d)); > > As to the comment at the top - this change alone certainly doesn't clarify > the "why". Agreed. >> init_dom0_cpuid_policy(d); >> >> if ( alloc_dom0_vcpu0(d) == NULL ) >> - panic("Error creating d%uv0\n", domid); >> + panic("Error creating d%uv0\n", bd->domid); > > Imo this would better use d->domain_id. And while touching it, %u would also > want swapping for %d. hmm, I was actually considering s/d%u/%pd/ and just pass in d, but was certain if there was an explicit reason it wasn't used before. If I am going to change it, would %pd not be more desired here? v/r, dps From xen-devel-bounces@lists.xenproject.org Wed Dec 04 17:14:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 17:14:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848672.1263502 (Exim 4.92) (envelope-from ) id 1tIswz-0003Xm-V6; Wed, 04 Dec 2024 17:14:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848672.1263502; Wed, 04 Dec 2024 17:14: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 1tIswz-0003Xf-SQ; Wed, 04 Dec 2024 17:14:09 +0000 Received: by outflank-mailman (input) for mailman id 848672; Wed, 04 Dec 2024 17:14: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 1tIswx-0003XZ-QZ for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 17:14:07 +0000 Received: from mail180-27.suw31.mandrillapp.com (mail180-27.suw31.mandrillapp.com [198.2.180.27]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2a359ec9-b263-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 18:14:06 +0100 (CET) Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail180-27.suw31.mandrillapp.com (Mailchimp) with ESMTP id 4Y3PJD3NKXz6CQQJV for ; Wed, 4 Dec 2024 17:14:04 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id f99d86d7f05b44549852944f2c0e5649; Wed, 04 Dec 2024 17:14: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: 2a359ec9-b263-11ef-a0d4-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1733332444; x=1733592944; bh=ha+PFFcK2rZoX5f3m0+6W/HqdkROKWb4ZcN5LYyjSAE=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=R99wySBm+4RO0EOvjoCRfxVj2jcHQOQs/aYkNBsDLWT8lsfnybnepq8uzZgnZ0tU9 UwzlNeH4zcVYXYHo+Tj5r5ZRuh/h9Kbk92PbG7pyK5vfIhl2XLaY/Z0kIpfNURrXNL 8+z022bReZHqeEF1q7YN1qtD5nLbVubsA2zdDbRQUnX2UP+1PNrB7Y70FKPGuiQNmf p8FFxVv2J8FX0D00oqSFe952IrBdayt5HvpgFq+jx1cpH8SrFHQHwJHz1dF9wFbaBP /UoAh4hfQ95CM30O05t8Qno6c7Msjm/JWULG/SKlZPHn92dYWMKNXXTG67EDUHivnY PFtq0HMxhy1nA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1733332444; x=1733592944; i=thierry.escande@vates.tech; bh=ha+PFFcK2rZoX5f3m0+6W/HqdkROKWb4ZcN5LYyjSAE=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=zMV4Pef6dRp3DaRKEVvp1RLzzsIu+mefmcRZTMwIMjOWSgCo102KjytMSX2QBjhuM 84L8xmcEGVfNzlykQWiT4HHtIiqX4xQ5CYIPM8YJlyeqgJZeiYQ7N3x6rR0SSVZnG8 CceijJ/QQY8pcXocdFbifu4nWyu5IyJwA9FJEwfRoosvtGdJ7jri0yCjY53BhOii/z spYMg64rMKFkiLwYoMI/a+8Shb/0OxpH5StwJEMcrl7sLN5QNT9XRLjyqOupdF/eRo G6Ic6qbQovuiA2H3YL22fmZT7qzcGbVGjcfbut2V3Niv/a8ZoxcHUEp4Pp/zottoFT dv8BwwmhjHzVw== From: "Thierry Escande" Subject: =?utf-8?Q?[PATCH]=20x86/xen/mmu:=20Increase=20MAX=5FCONTIG=5FORDER?= X-Mailer: git-send-email 2.45.2 X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1733332443466 To: "Juergen Gross" , linux-kernel@vger.kernel.org Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, jbeulich@suse.com, xen-devel@lists.xenproject.org Message-Id: <20241204171346.458105-1-thierry.escande@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.f99d86d7f05b44549852944f2c0e5649?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20241204:md Date: Wed, 04 Dec 2024 17:14:04 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit With change 9f40ec84a797 (xen/swiotlb: add alignment check for dma buffers), the driver mpt3sas fails to load because it cannot allocate its DMA pool for an allocation size of ~2,3 MBytes. This is because the alignement check added by 9f40ec84a797 fails and xen_swiotlb_alloc_coherent() ends up calling xen_create_contiguous_region() with a size order of 10 which is too high for the current max value. This patch increases the MAX_CONTIG_ORDER from 9 to 10 (4MB) to allow such allocations. Signed-off-by: Thierry Escande --- arch/x86/xen/mmu_pv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c index 55a4996d0c04..7f110740e1a2 100644 --- a/arch/x86/xen/mmu_pv.c +++ b/arch/x86/xen/mmu_pv.c @@ -2200,7 +2200,7 @@ void __init xen_init_mmu_ops(void) } /* Protected by xen_reservation_lock. */ -#define MAX_CONTIG_ORDER 9 /* 2MB */ +#define MAX_CONTIG_ORDER 10 /* 4MB */ static unsigned long discontig_frames[1< Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 17:23:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848682.1263512 (Exim 4.92) (envelope-from ) id 1tIt5U-0005EZ-Ok; Wed, 04 Dec 2024 17:22:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848682.1263512; Wed, 04 Dec 2024 17:22: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 1tIt5U-0005ES-LK; Wed, 04 Dec 2024 17:22:56 +0000 Received: by outflank-mailman (input) for mailman id 848682; Wed, 04 Dec 2024 17:22: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 1tIt5U-0005EK-4B for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 17:22:56 +0000 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam04on20616.outbound.protection.outlook.com [2a01:111:f403:2409::616]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 64aee8b5-b264-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 18:22:54 +0100 (CET) Received: from MN0PR02CA0014.namprd02.prod.outlook.com (2603:10b6:208:530::19) by DM4PR12MB7669.namprd12.prod.outlook.com (2603:10b6:8:106::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.19; Wed, 4 Dec 2024 17:22:49 +0000 Received: from BL02EPF0001A105.namprd05.prod.outlook.com (2603:10b6:208:530:cafe::fa) by MN0PR02CA0014.outlook.office365.com (2603:10b6:208:530::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.9 via Frontend Transport; Wed, 4 Dec 2024 17:22:49 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by BL02EPF0001A105.mail.protection.outlook.com (10.167.241.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Wed, 4 Dec 2024 17:22:49 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) 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; Wed, 4 Dec 2024 11:22:48 -0600 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 4 Dec 2024 11:22:48 -0600 Received: from xcbayankuma40.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Wed, 4 Dec 2024 11:22:47 -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: 64aee8b5-b264-11ef-a0d4-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=R8zjalz6u8+zdHpnyTTJakOm7GQCoO+YGjFP1SeF5P7F26B8LCrdJyk+qEWfmXHx+6X+QztBXz+rwhGlLj/N7yxPvD5UIFCDv2ZEXH4fwE2DbwMaufeb0UXeHFLdlnAIgspTh+/wTXE3MwIE19ZFxEUaAqHsDDEoh7BRKrcNBwBy3YEGC7dPfcBR+SVAc2brAAZw75ndEqk90Cwl2Jc3m6ra/Oo1Eu0xBqkmCz3fHcIrgKdsAdK4SdB7BrmpL+0UsjzA/dibXIsTCwUC8CkAV8SOAtxfQeydC3AKeF+UzZ3Bymr1zxOEJdEgn/gO/zNw22D3QkuZo390wFNeFyfB6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OEQtjR1kGtdkm7vjc53mHIojUpBALYz8vbwOTtXYxN0=; b=Popg1oTQdvtOVmtcMGK8Or2hlq/wN5kyxe5ReM2Ee1jy0P29ZloPfeXZSxr6CNUaF8Tvj//qPjgim0SLI6aDOMAe3ZLRFTGQCb1j4Wh2+/zG5aDRLk2UurK2ujWVkDnUtBjZqHPvF6gMT99XtDDWHd4o6kc8u7SZ6D4z9F27xHYxdmwoNmjyLeLspelEyPc39QtMs9Hn78xaFDlVGsPTpzwpHFnlYSApy+l9CvTs7eSoy0SL+jNwZxrwkX52Q82mPzKIfWl+rwMarSxSApeHlFuhptpMTPzCfBE3KFWXpBm3XpFZGvCrzHA95GV9dRe+3QDSPpaH7vb0D1o+1Jp0GA== 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=OEQtjR1kGtdkm7vjc53mHIojUpBALYz8vbwOTtXYxN0=; b=4SIaEWNRSXHSfELSqwN1y5HWMpOOU6IPpLgoRCZ6X+m4JzrGEevKkLHPbIn7zTYJkl9C45cEfAqXjUtEe7bnpidsK9gcwZ/42RZeL3YHedRofnUwlDe/6ebWYYOwKIrJj2vS0citll3BKlG0qtGZKy1/DfjQTgNz/3sY3oHw13Y= 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=SATLEXMB04.amd.com; pr=C From: Ayan Kumar Halder To: CC: Ayan Kumar Halder , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" Subject: [PATCH v3 0/2] Enable early bootup of AArch64 MPU systems (Part 2) Date: Wed, 4 Dec 2024 17:22:41 +0000 Message-ID: <20241204172243.1229942-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 Received-SPF: None (SATLEXMB05.amd.com: ayan.kumar.halder@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF0001A105:EE_|DM4PR12MB7669:EE_ X-MS-Office365-Filtering-Correlation-Id: 451c3543-2ba7-4047-676d-08dd148846d2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|376014|36860700013|1800799024; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?NChCat2Q5NdeG7G19/Jqg2CU9YIEKymyw15+hKg6ILij1EBgXNWEdtcEnKjM?= =?us-ascii?Q?bExC7BfKz6CVC5Jkolenu7EEKj9wWdus9pH5s3w91lqURN5XylBjGCdgE0GU?= =?us-ascii?Q?qwybmXNlM1IliOBno8ycklC3CIyMhA3mPQBVvpjdi5Bjzy9r6iTySEGJSiZf?= =?us-ascii?Q?TV0zgh1Xz2dWTPKBu12MVLXQ/aNwcJsMOKOxMuBG63bXM9YMcyCg2FWf2o+r?= =?us-ascii?Q?VkzOh5kZqPRaE/TC5mAFQ3OiTJKTgtlwd5fxu5rH6+O72R0Buv+q3PMCINq2?= =?us-ascii?Q?Rh3tQkYY3TKnJXa8YcyZh1E1QvVhjQ4YOYB5JYq1kJ8MXsjEaDE/FLSgShhx?= =?us-ascii?Q?nanabX17ksy+PpRcjwUshfqcxGe/x4Cupl0KYoytIku0EzfcYd5XJcpMUTZ7?= =?us-ascii?Q?f9Bp/+nlmImZuNiRaEky4jl7SZTHB7qscz/nlV9e8xdqw8gGjyPHAxCWEi77?= =?us-ascii?Q?qXEtXWt9EA7p6UoqDj15r8LjD1o0mWb9iaSb4I6IKCOtka94GefxX+vSCu7e?= =?us-ascii?Q?x2Yst0UN3xVX/llIVEfzbdrzuf2k7Xcbtq7UjaVEgXArkzWCdR1ifoZpAx/t?= =?us-ascii?Q?zeYQqOugjAcyZdzOh/YDr0dMWRgBf8vDH86HwaZa7LZy9f0z0VqXXGtxPK1d?= =?us-ascii?Q?yKoN1S2FatpFaYGypueJbL5h6ReQK5LmNUvdM1x6iUIN1O18PEvXpEMKnZTx?= =?us-ascii?Q?FFIY3KfjcMLN3dPv35I+5hwdUTQqL5gduLLUrGLfFD2/jfBqpW3WbIhqEzSY?= =?us-ascii?Q?q3SzloIormR8NQ7BtiNs0b8qJKWY5sXPsVa40lX5BiZYySo1+aYChfG07PU2?= =?us-ascii?Q?LnV7ltul/14fEoKaMNP6YdXTnAjkO3d9MQes0pdTug/AUdxYnmDgQiGXRSG6?= =?us-ascii?Q?JjMbR3uKUD+zhqPWpO+k/RysuDcy6z4ekYUxvKXo/MSNk+d6seakOPUAtpQO?= =?us-ascii?Q?+kBul/VfAerYejnS2jFGYl+YnQMej5c5lCa4ni5SBVu+oR2NP4EGIbyJRZ9q?= =?us-ascii?Q?jBJqwcLn7mzhpuwjFs9gBGUill/pQK1ZLecEnUmezm9SzKdFBi4OA1Flg0kZ?= =?us-ascii?Q?RrqZIVRGhK/x+mjI9X6BmdA3IyxTzH7YyEAWXjj6y+ddEe6XCV2ZK7SHySOp?= =?us-ascii?Q?9b+0upgO7d95bN4Y/gq6eg08jIjSxO9lfM9Q2du3a/pKgEPa7xX4mN7JtE4l?= =?us-ascii?Q?lpeyAxlvg7vjLI5QW1s/AkUySaVGOBGNYeFoz/OBfsHJS0/ioHDRKd2zW8Oh?= =?us-ascii?Q?hD74zCTl/f5bake+K9asaA9xrIzl0yK7KqP9gGWoRnHkbKz8Lff57KQTt2e+?= =?us-ascii?Q?AyRx+yFVXLP0FyK3O29eBj16sWeem/zFkm++/xMZoLYDfvJLgCtDd8vpCEuK?= =?us-ascii?Q?DthC/1GHq2z2+EKXYxXJ1f0gmnyzvjTP7QqYd+NGuCCelSJmAf0oBoFqwaFe?= =?us-ascii?Q?RDxpfk/32OGarSrZSxz7wxJfC+/vAcpj?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(36860700013)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2024 17:22:49.1999 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 451c3543-2ba7-4047-676d-08dd148846d2 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL02EPF0001A105.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7669 This patch serie concludes earlyboot support for Arm-v8R AArch64 MPU systems. Ayan Kumar Halder (1): xen/mpu: Map early uart when earlyprintk on Penny Zheng (1): xen/mmu: enable SMMU subsystem only in MMU xen/arch/arm/Kconfig | 4 ++-- xen/arch/arm/Kconfig.debug | 7 +++++++ xen/arch/arm/arm64/mpu/head.S | 10 +++++++++ xen/arch/arm/include/asm/early_printk.h | 28 ++++++++++++++++++++++++- 4 files changed, 46 insertions(+), 3 deletions(-) -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Wed Dec 04 17:23:01 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 17:23:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848683.1263521 (Exim 4.92) (envelope-from ) id 1tIt5Y-0005U9-VZ; Wed, 04 Dec 2024 17:23:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848683.1263521; Wed, 04 Dec 2024 17:23: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 1tIt5Y-0005U0-Su; Wed, 04 Dec 2024 17:23:00 +0000 Received: by outflank-mailman (input) for mailman id 848683; Wed, 04 Dec 2024 17:23: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 1tIt5Y-0005EK-1y for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 17:23:00 +0000 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on20610.outbound.protection.outlook.com [2a01:111:f403:2414::610]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6875bdc4-b264-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 18:22:59 +0100 (CET) Received: from BN9PR03CA0109.namprd03.prod.outlook.com (2603:10b6:408:fd::24) by MW6PR12MB8833.namprd12.prod.outlook.com (2603:10b6:303:23f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.11; Wed, 4 Dec 2024 17:22:54 +0000 Received: from BL02EPF0001A104.namprd05.prod.outlook.com (2603:10b6:408:fd:cafe::42) by BN9PR03CA0109.outlook.office365.com (2603:10b6:408:fd::24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.13 via Frontend Transport; Wed, 4 Dec 2024 17:22:53 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by BL02EPF0001A104.mail.protection.outlook.com (10.167.241.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Wed, 4 Dec 2024 17:22:53 +0000 Received: from SATLEXMB04.amd.com (10.181.40.145) 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; Wed, 4 Dec 2024 11:22:52 -0600 Received: from xcbayankuma40.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Wed, 4 Dec 2024 11:22: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: 6875bdc4-b264-11ef-a0d4-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=y90Y2MjkTusisFnjrDjGAwibOdxRwUHDXq44/e8mGqJDsKLGPDm6MeKhl7oqlYbdXT5SBOtB9dXxieaHC2B/+3uv1g4YBUymbQr1c82OgcUKIv/9BDAkxEyG0iVCQW0CVuiWob5dXl2rF+bxUIKVVit9d91zS0w7hwcT6HobAZgKfjn81GJqOXgCPxXomEB3tUbV+/9KWTIeCQXT/j3c721fW797B9tbsF8+RRaU5h8SyyQg600Mk44mzQJNCXB9aJy5cq1VaaVbdtS/GxuntXsrZ/q78vNLgJZdsPUn7XpdGrFFHX6pUAkSj6bf/J8ysIRq6DKOUNfym72e2QYisw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eKRJlYZj/vM8lMPFruBRq7uav07apuOnarZh8uy17dk=; b=cY19GKTxKqgtNjjc4u2elEr+Z8O6NUFN4/kYPNeJJzP1ekdA6FW3m8KM5DhN5JRUCpbDLwWV/rtg32aeQjvsif/kyVJpEbPCcJ3xEH/pKFI9lnQ1LStOTPQqlIr3K7y3cARPq53m+SJEoN706+DNCfXZdKlCS0xqRCDBmVIX0pCNAx7ZGF+LWTtQ4jYb1BdJgqG9EBSsFSE4h7GgxNj2IfcRK7gHdVzXiliHV2YU2uz/sMHj5ChrYF3/dUwjD3f58UkL4zspqkeowsWJHX3i4wZtXUJ6GD92yzC4jQaLy1khvfmbga3teew179DyMPiw/qVjQgs8BEcSzvqWqzI3Xw== 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=eKRJlYZj/vM8lMPFruBRq7uav07apuOnarZh8uy17dk=; b=tK8GDlbkBvj3oBNdNWrsypxtp1Ff61nHvPXrKcVUGyxn7J2o3YaxHnQydBBJjttqqoMwrXUnkXVYJohDNhQRX/w54yIESW5IlDrGK5WjqcBlNsrO38QWFBIg9Vaz3QugqiAPjeNgOLehcCdmDo5E5Ow7QkvSjhyYC+PNRYvDOaw= 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=SATLEXMB04.amd.com; pr=C From: Ayan Kumar Halder To: CC: Ayan Kumar Halder , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" , Luca Fancellu Subject: [PATCH v3 1/2] xen/mpu: Map early uart when earlyprintk on Date: Wed, 4 Dec 2024 17:22:42 +0000 Message-ID: <20241204172243.1229942-2-ayan.kumar.halder@amd.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20241204172243.1229942-1-ayan.kumar.halder@amd.com> References: <20241204172243.1229942-1-ayan.kumar.halder@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB04.amd.com: ayan.kumar.halder@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF0001A104:EE_|MW6PR12MB8833:EE_ X-MS-Office365-Filtering-Correlation-Id: 31c31c7b-0477-450f-1b12-08dd1488494e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?EhqGEt+ISUOHHSEDsCU9D9Lnl+gOPPP3n/WRHKvphuVpFNue3ZI5dFN53zf5?= =?us-ascii?Q?X+hquwNZYduPOKCt5i7A65eDZapSwb2pd8LVUaVla25QkYn2wkXUqT+AdX5o?= =?us-ascii?Q?oZVS/0M+8g5svuvjZ111TtYy3LJu9iQt5HltJXW78zLzQGidL6NpEx+u8PLa?= =?us-ascii?Q?UKjx2BiGt62iOwac0zjfy0HwavPa1GjLW/kp8i3o99Nj/tEJighQMvpQKGvw?= =?us-ascii?Q?rZdzwXUfU+MfL5LaXAmgTrTrYOb4HlX5yxCf+0O6JufcBex4/0fyG84Q7r3u?= =?us-ascii?Q?V7tyDFFed88rq7kEDAijCmX88lqJU59j82KomLItEOsWFHA/748AQEUgNT5R?= =?us-ascii?Q?ZQtelMk756OyqXTZqwqwByc8ftx6tYGVc5oXNv7wEme6MjWE3AxOnSeNL7Qv?= =?us-ascii?Q?QxIaOYrj63moT+AmqidsBNStcDtuFqKo5ZTyzOzrvPY+n/AvNpdu92kELbMX?= =?us-ascii?Q?k/25Dnmo0k+iW7I72nS+rXQyeyzqimqSlsa9pR2z9FbNPNVo8amIA45I1M1v?= =?us-ascii?Q?DXqm76UTHOMVRBlUx/q442WPZHcqSkBQud+vebIDqxlN10oyBbON7ZgNKrRL?= =?us-ascii?Q?EOVIQLEU2M9ZiUDU06IW/akOXrE+dn1byEPHs70jmir347r0U6Gy1IQdMgBC?= =?us-ascii?Q?tmEofjiKyXiZtcx6tWd8MNeUSAdrKETPjl9xzYYaS5uR4lr9esMdb00UZiMv?= =?us-ascii?Q?rHkzWZLnvAkQjAfn4J33qTGHVcT6fr942B2vEoE3Ir56ilhR7x1uBnY9CGQm?= =?us-ascii?Q?5R26lFbJfSVZtXwPn/7eIV+iQTNgDW74SWX5mhQk03iGk5oj5Qh9zfyk9diH?= =?us-ascii?Q?YrlTrzs2qTOWacjLDdF2lA/bXr0K48Bm40O9mFu4A5O4nyo0/Pu6eiwClB13?= =?us-ascii?Q?3A7Ea9/K6qXZtkqIvfNVp304J89dtOsjEA6nGQX80Zhi/wT/uiWUhFcMDbLP?= =?us-ascii?Q?bO6eR+2SrvnNDDelSlTxXLWyBv/tmYIt/WJ1XQDOaq6oXUZZNCJeb9q6ktdS?= =?us-ascii?Q?yi6O2Y+6lrkKuvwgES1Ljsx7OvyYP2mggpU/9TOCb+uqhDzg2FvC8td4AgwJ?= =?us-ascii?Q?2XvoEAmI7s5qWsZtWb7r3km+fKrZJ4hy6UplHTcIBoO+I4EakmexhG8QyaEN?= =?us-ascii?Q?FzRmE7kLkIotrplBN87kOw3zfmckrxoUbR/vT4wkt2RCVntFajGlm4ptWZiE?= =?us-ascii?Q?5pj8NSy/3oHR6SEu+JqiOZzbqmCmHTjl/agNriSSeA3Hc7fh4XsE7O+JD+Zl?= =?us-ascii?Q?r27dpTcma3vXaPnuETMt6iYI3OUTDxp2MY57vo/0mfG8AGOC1/waXTBrJIab?= =?us-ascii?Q?XUVD4Z2wlMo8O0Kg+x2bTdrkFxfBvoz0Dx+LXE6tdXzw8/lUFeh4Ge6UlsFa?= =?us-ascii?Q?t033wj/f6bCqrCSpeI33uLrv6UntZhlxepHIhC2+UgHzPQtiJjXlaN4YlZgs?= =?us-ascii?Q?XD4OzF54kQnBM5gefQPC6Yu37VfStCb9?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2024 17:22:53.3816 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 31c31c7b-0477-450f-1b12-08dd1488494e 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL02EPF0001A104.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8833 CONFIG_EARLY_UART_SIZE is introduced to let user provide physical size of early UART. Unlike MMU where we map a page in the virtual address space, here we need to know the exact physical size to be mapped. As VA == PA in case of MPU, the memory layout follows exactly the hardware configuration. As a consequence, we set EARLY_UART_VIRTUAL_ADDRESS as physical address. EARLY_UART_BASE_ADDRESS and EARLY_UART_SIZE should be aligned to the minimum size of MPU region (ie 64 bits) as per the hardware restrictions. Refer ARM DDI 0600A.d ID120821 A1.3 "A minimum protection region size of 64 bytes.". UART is mapped as nGnRE region (as specified by ATTR=100 , refer G1.3.13, MAIR_EL2, "---0100 Device memory nGnRE"). Also, it is mapped as outer shareable, RW at EL2 only and execution of instructions from the region is not permitted. Signed-off-by: Ayan Kumar Halder Reviewed-by: Luca Fancellu --- Changes from :- v1 - 1. UART base address and size should be aligned to the minimum size of MPU region (and not PAGE_SIZE). v2 - 1. In early_printk.h, included and fixed the macro names. 2. Included in head.S. 3. Updated the commit message (to remove reference to R82 TRM) and added Luca's R-b. xen/arch/arm/Kconfig.debug | 7 +++++++ xen/arch/arm/arm64/mpu/head.S | 10 +++++++++ xen/arch/arm/include/asm/early_printk.h | 28 ++++++++++++++++++++++++- 3 files changed, 44 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug index 7660e599c0..84a0616102 100644 --- a/xen/arch/arm/Kconfig.debug +++ b/xen/arch/arm/Kconfig.debug @@ -121,6 +121,13 @@ config EARLY_UART_BASE_ADDRESS hex "Early printk, physical base address of debug UART" range 0x0 0xffffffff if ARM_32 +config EARLY_UART_SIZE + depends on EARLY_PRINTK + depends on MPU + hex "Early printk, physical size of debug UART" + range 0x0 0xffffffff if ARM_32 + default 0x1000 + config EARLY_UART_PL011_BAUD_RATE depends on EARLY_UART_PL011 int "Early printk UART baud rate for pl011" diff --git a/xen/arch/arm/arm64/mpu/head.S b/xen/arch/arm/arm64/mpu/head.S index d3db5e53af..e4f2021f45 100644 --- a/xen/arch/arm/arm64/mpu/head.S +++ b/xen/arch/arm/arm64/mpu/head.S @@ -4,6 +4,7 @@ */ #include +#include /* Backgroud region enable/disable */ #define SCTLR_ELx_BR BIT(17, UL) @@ -11,8 +12,10 @@ #define REGION_TEXT_PRBAR 0x38 /* SH=11 AP=10 XN=00 */ #define REGION_RO_PRBAR 0x3A /* SH=11 AP=10 XN=10 */ #define REGION_DATA_PRBAR 0x32 /* SH=11 AP=00 XN=10 */ +#define REGION_DEVICE_PRBAR 0x22 /* SH=10 AP=00 XN=10 */ #define REGION_NORMAL_PRLAR 0x0f /* NS=0 ATTR=111 EN=1 */ +#define REGION_DEVICE_PRLAR 0x09 /* NS=0 ATTR=100 EN=1 */ /* * Macro to prepare and set a EL2 MPU memory region. @@ -140,6 +143,13 @@ FUNC(enable_boot_cpu_mm) ldr x2, =__bss_end prepare_xen_region x0, x1, x2, x3, x4, x5 +#ifdef CONFIG_EARLY_PRINTK + /* Xen early UART section. */ + ldr x1, =CONFIG_EARLY_UART_BASE_ADDRESS + ldr x2, =(CONFIG_EARLY_UART_BASE_ADDRESS + CONFIG_EARLY_UART_SIZE) + prepare_xen_region x0, x1, x2, x3, x4, x5, attr_prbar=REGION_DEVICE_PRBAR, attr_prlar=REGION_DEVICE_PRLAR +#endif + b enable_mpu ret END(enable_boot_cpu_mm) diff --git a/xen/arch/arm/include/asm/early_printk.h b/xen/arch/arm/include/asm/early_printk.h index 46a5e562dd..219705a8b6 100644 --- a/xen/arch/arm/include/asm/early_printk.h +++ b/xen/arch/arm/include/asm/early_printk.h @@ -11,10 +11,33 @@ #define __ARM_EARLY_PRINTK_H__ #include +#include #include #ifdef CONFIG_EARLY_PRINTK +#if defined(CONFIG_MPU) + +/* + * For MPU systems, there is no VMSA support in EL2, so we use VA == PA + * for EARLY_UART_VIRTUAL_ADDRESS. + */ +#define EARLY_UART_VIRTUAL_ADDRESS CONFIG_EARLY_UART_BASE_ADDRESS + +/* + * User-defined EARLY_UART_BASE_ADDRESS and EARLY_UART_SIZE must be aligned to + * minimum size of MPU region. + */ +#if (CONFIG_EARLY_UART_BASE_ADDRESS % MPU_REGION_ALIGN) != 0 +#error "EARLY_UART_BASE_ADDRESS must be aligned to minimum MPU region size" +#endif + +#if (CONFIG_EARLY_UART_SIZE % MPU_REGION_ALIGN) != 0 +#error "EARLY_UART_SIZE must be aligned to minimum MPU region size" +#endif + +#elif defined(CONFIG_MMU) + /* need to add the uart address offset in page to the fixmap address */ #define EARLY_UART_VIRTUAL_ADDRESS \ (FIXMAP_ADDR(FIX_CONSOLE) + (CONFIG_EARLY_UART_BASE_ADDRESS & ~PAGE_MASK)) @@ -22,6 +45,9 @@ #define TEMPORARY_EARLY_UART_VIRTUAL_ADDRESS \ (TEMPORARY_FIXMAP_ADDR(FIX_CONSOLE) + (CONFIG_EARLY_UART_BASE_ADDRESS & ~PAGE_MASK)) -#endif /* !CONFIG_EARLY_PRINTK */ +#else +#error "Unknown Memory management system" +#endif +#endif /* !CONFIG_EARLY_PRINTK */ #endif -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Wed Dec 04 17:23:07 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 17:23:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848686.1263532 (Exim 4.92) (envelope-from ) id 1tIt5f-0005nh-B4; Wed, 04 Dec 2024 17:23:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848686.1263532; Wed, 04 Dec 2024 17:23: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 1tIt5f-0005nW-7l; Wed, 04 Dec 2024 17:23:07 +0000 Received: by outflank-mailman (input) for mailman id 848686; Wed, 04 Dec 2024 17:23: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 1tIt5d-0005EK-Ux for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 17:23:05 +0000 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam04on2062c.outbound.protection.outlook.com [2a01:111:f403:2409::62c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6c04c62d-b264-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 18:23:05 +0100 (CET) Received: from BN8PR15CA0051.namprd15.prod.outlook.com (2603:10b6:408:80::28) by BY5PR12MB4260.namprd12.prod.outlook.com (2603:10b6:a03:206::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.11; Wed, 4 Dec 2024 17:23:00 +0000 Received: from BL02EPF0001A101.namprd05.prod.outlook.com (2603:10b6:408:80:cafe::60) by BN8PR15CA0051.outlook.office365.com (2603:10b6:408:80::28) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.19 via Frontend Transport; Wed, 4 Dec 2024 17:22:59 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by BL02EPF0001A101.mail.protection.outlook.com (10.167.241.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Wed, 4 Dec 2024 17:22:57 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) 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; Wed, 4 Dec 2024 11:22:57 -0600 Received: from SATLEXMB04.amd.com (10.181.40.145) 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 Dec 2024 11:22:57 -0600 Received: from xcbayankuma40.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Wed, 4 Dec 2024 11:22:56 -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: 6c04c62d-b264-11ef-a0d4-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sAtKyBlUbfpqp9Mrx0EGP/XAT+ol6bw9Se4GsXT3jNIei1psgO87gNk2KnjiZoiTR9U4EmlJUXMTRxgiR9Hn0B9UjHLzmVNtKBpoV1F5CmDWQzYk8zGwFj8FIMyKDawDJI5gHjJRqzApjFpUX80cmYWpxLZXowp6cpL80o6URUZti3ugRuHVb7iOgof/6FX+jMzoLkYBbC5Lg351+TVYj7majS8k6Y4RfD1V/EPSBvB16sdjST9WOYxIqRfq9C1cKUcpueOf+nSpOKYcdUlDOIewoLmbZY4EqbKrg9/9RAazDGtOsSdXekksblLq7rONzQuVXVdPo3Qmf+6zP1/bHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zkeSlG1x1nQlbLTNFU3f2etPFvJ/ZKq7O/4HU9Y+JXk=; b=eZJro7FIbQ9REmIYxPUmr1u3qaavdsCSDhiSub4g5GZ9NV1FW4sQH6w3+fbdAtnVQBckF/QRklhyqtGIJkMJAfIVy8zulLe7U7uQtRJE9MViNaN45wBITa/zimZ2VnATk3TvTHNRznBze6+AWkmVzi82LLuGoN6thJfnsxMpy+nHA/m8KhL/LjxaxA3GK+eCodg3kCx8ItkdixGROYSyTFSVyhM8vdBsCBu0wyEY7JaEbrTQlq4SsGWrs/Bnch7j8tkl5NVrAyb4ToSODmTDSQYUjxnDYP18wnSFftJshDHC32BbuGAvTSMAbIwLf3R0sjYpoMn/5GnXfN6ZpiwmEQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=temperror (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=temperror 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=zkeSlG1x1nQlbLTNFU3f2etPFvJ/ZKq7O/4HU9Y+JXk=; b=Iq2I1CGUupXI+TMpCEsKM/hAtEmKMC6nISyrs34TMjfmNWvCKQ0qfBeDJS33+1GuDijJdI8Ib0p8M2c7Afu9UWjAhavCjHmeIDiJB2XBI6G604Gm35hpZajb8RGboxIJMawu2/L6FWh6d6vo8H0FJ8zpYY34/gjFINNwltaiwfo= X-MS-Exchange-Authentication-Results: spf=temperror (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=temperror action=none header.from=amd.com; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of amd.com: DNS Timeout) From: Ayan Kumar Halder To: CC: Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" , Ayan Kumar Halder , Julien Grall Subject: [PATCH v3 2/2] xen/mmu: enable SMMU subsystem only in MMU Date: Wed, 4 Dec 2024 17:22:43 +0000 Message-ID: <20241204172243.1229942-3-ayan.kumar.halder@amd.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20241204172243.1229942-1-ayan.kumar.halder@amd.com> References: <20241204172243.1229942-1-ayan.kumar.halder@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF0001A101:EE_|BY5PR12MB4260:EE_ X-MS-Office365-Filtering-Correlation-Id: 6327af57-a15a-46f0-afc3-08dd14884c0e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?wD9lowN9JR0R6D8GyMObCId7u4OTtpQGoXwZ2kcTjpJPLl2hDQqQ+BP7DoA2?= =?us-ascii?Q?fdbKiDmZzwBguXZk4PRnvqWZJ4JMa3gagiRUHE+JgNpfinewkC8+yBr66uXU?= =?us-ascii?Q?7XaCwpWD/KbYeCNYqIu9NPKb3ELXO3ZAqyON+J9WqevII9F8E7Tk/MkxcP+y?= =?us-ascii?Q?mYB6FfMHIvkZ4eAE/TBvm+c8OyIsjOpA5L5TgKj9DCABIrFCoGyZIgb2A46p?= =?us-ascii?Q?LRjkgPnLxc8nt6Xq9FKU0mfCqz9XDQJcXakXr62ZWQ4JGEiBndMOxouyKWSC?= =?us-ascii?Q?Vt+w43Rt6oHM8UNVs5Lg08YDVmwuo8qhnsw52ho5MvJPME+njKgXn6Bv6vFi?= =?us-ascii?Q?TNHFpTgErLoKTmJpwiQjbYv7dXl64NH8fPeDOGnWJksOTs0nYbSXmjOJTzVP?= =?us-ascii?Q?aNbsNsB6EiJHc1yTWXxYK9LY2z1fuC6Wqidn3wJMTf/NjwbGfd4FJoWBzlKP?= =?us-ascii?Q?qnqbx5NbKWub9IblTUwY8+qvWGX/q3WzwsJI7UZ2EhW1TjkEicCcYA6Fu5tV?= =?us-ascii?Q?EIdkZkUJg+PVub9KSXwkcJGy7tBFGDZOpi7ObRD5jqLaIKwGcD4QusuUndfu?= =?us-ascii?Q?yJRcV6h+e7nkppQbIiri/rNU3jcAiU/dJUoX/FwAEtWZjHrTKhd+VoJ9qlTb?= =?us-ascii?Q?Srt+8nodz1Eq7vyM6jcXKQrIBLt1rb/8z5at2nwdGtwZPJd8Mi637jgM5wzN?= =?us-ascii?Q?xOJBcC7IpyfwimZ9ZvhV4XiVHOwcublA90+sCgL8KX0wJ4KZ3VCLMBmg6Uft?= =?us-ascii?Q?kxQNPxnsoDt54XhYTV1pl0Eh9eH/ePS11kZCYKt/KRmRyyS+zb9qqmugCVVv?= =?us-ascii?Q?03b7WGKtWtA1pI9v/nBAlywhOiNZSrOsT0YK6gvU6gCvtnetqyykTuz+b45U?= =?us-ascii?Q?ZKOu+fZdj79tyYKgseLxM0ETV5Ab3tdlky53jFXXSlcovBDt9cqBOGfDCF2J?= =?us-ascii?Q?hpqQNJ/mVMSV9zqL37aB3+8sRHC6I7SzfavrTX0C1a37DA9eYFx7Cedmsg2A?= =?us-ascii?Q?0itdm6jWnsnEgmwpYVfZWQMJSRhDmQwRRE34v0J7AW9E+j/UlgaQ5wGInpEQ?= =?us-ascii?Q?99gJMAwa7Nxdvwj32gsE+U+ZfpxP2sRWII6eTTrUhSpQCiloh/cgJBGN2nrW?= =?us-ascii?Q?R5NKcybG8rKuQgngaqZPWgn1VzXy/ZPzKkqys4z+RLRomCT6h+s6DrAefB89?= =?us-ascii?Q?YqMu7OcTg14vYUxU2SnE2qn0rIubYba+Ml+OjCf56xYp2MQ5ib3t0c6Hm93m?= =?us-ascii?Q?bqkPQ9GtYdT9VqZCjJJdoXXrca8AkwIm9sXQbSUM8aTV+2HyY8sIT1WNp1ty?= =?us-ascii?Q?l4zghdH/Q0FMPu7PcB6xIDjZXDdccH4JYtCt8AcLxZf0mUk1R5pgBmkmr3Oc?= =?us-ascii?Q?j9P0YbNy/LQHRox0VtrjO3i4lmVRz+2EQhKwyNw2IGKHs6pGEL1C9i5vrq93?= =?us-ascii?Q?GrJJguMsIEIGz4sbTuVVoQEvUuLLyNJB?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2024 17:22:57.9992 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6327af57-a15a-46f0-afc3-08dd14884c0e 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL02EPF0001A101.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4260 From: Penny Zheng In Xen, SMMU subsystem is supported for MMU system only. The reason being SMMU driver uses the same page tables as MMU. Thus, we make it dependent on CONFIG_MMU. Signed-off-by: Penny Zheng Signed-off-by: Ayan Kumar Halder Acked-by: Julien Grall --- Changes from v1 - 1. HAS_PASSTHROUGH is now enclosed within "config MMU". There was a pending response on "[PATCH v1 2/2] xen/mmu: enable SMMU subsystem only in MMU" that it might introduce a bunch of #if-defs in arm specific common code. However, there are alternative implementations possible to reduce #if-defs. So, that can be decided at a later point in time and should not block the current patch. v2 - 1. Added Julien's A-b. xen/arch/arm/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 23bbc91aad..604aba4996 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -15,9 +15,7 @@ config ARM select GENERIC_UART_INIT select HAS_ALTERNATIVE if HAS_VMAP select HAS_DEVICE_TREE - select HAS_PASSTHROUGH select HAS_UBSAN - select IOMMU_FORCE_PT_SHARE config ARCH_DEFCONFIG string @@ -79,6 +77,8 @@ config MMU bool "MMU" select HAS_PMAP select HAS_VMAP + select HAS_PASSTHROUGH + select IOMMU_FORCE_PT_SHARE help Select it if you plan to run Xen on A-profile Armv7+ -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Wed Dec 04 17:51:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 17:51:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848718.1263543 (Exim 4.92) (envelope-from ) id 1tItWw-0002O7-EE; Wed, 04 Dec 2024 17:51:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848718.1263543; Wed, 04 Dec 2024 17:51: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 1tItWw-0002O0-9y; Wed, 04 Dec 2024 17:51:18 +0000 Received: by outflank-mailman (input) for mailman id 848718; Wed, 04 Dec 2024 17:51: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 1tItWu-0002Nr-9x for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 17:51:16 +0000 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 598e6c29-b268-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 18:51:14 +0100 (CET) Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Dec 2024 09:51:11 -0800 Received: from ldmartin-desk2.corp.intel.com (HELO ldmartin-desk2) ([10.125.108.58]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Dec 2024 09:51:09 -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: 598e6c29-b268-11ef-a0d4-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1733334675; x=1764870675; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ik3QLw9UGMKnxPg4l01yFX/0oyq1X9s68T58mzM5ads=; b=mFJkwQNf5fb7/ES9NvblmxWi87PQ2POqnQO3StJa1ylKeEVM5rvG7afU LAVXma8AIOMjXPkAq87BdgXZfSWM6WvE0MrTS2I5zcL40SaRbPnCJyhr/ e1llotORoJ3hYZx/8QTWpPHGo0/Yo4LWrQ69YOEhYVeaIOqE/HXAq3K2G 7opi5tIuiFeBXq90MjszDClcNAiRvsI1vsf9vTRsFPfk9UfGnkk5Rz+Ai xBD10E+KfLn7dqjqgAU/JveqtXbujrN6Ml2OVM1ywIPrQRp0dcypQieLI hau+82ZspZKpY/Dw6OF2Xg2sKJ98woPLtvAqRQHqlm8XkrCtLCrH2Fh9R A==; X-CSE-ConnectionGUID: KdIXQeW1RDWeLcMj/0HvAA== X-CSE-MsgGUID: aJ9qRMprSdyNXzA2/rdthQ== X-IronPort-AV: E=McAfee;i="6700,10204,11276"; a="37392169" X-IronPort-AV: E=Sophos;i="6.12,208,1728975600"; d="scan'208";a="37392169" X-CSE-ConnectionGUID: lPqKmV1BT4eeE13DlFLk8Q== X-CSE-MsgGUID: ImJp8lYITJ6+VecW9ZGo8w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,208,1728975600"; d="scan'208";a="131283575" Date: Wed, 4 Dec 2024 11:51:01 -0600 From: Lucas De Marchi To: Jani Nikula Cc: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org, Javier Martinez Canillas , Alex Deucher , Simon Ser , Jeffrey Hugo , David Airlie , Hamza Mahfooz , Maarten Lankhorst , Maxime Ripard , Oleksandr Andrushchenko , Simona Vetter , Thomas Zimmermann , Ville =?utf-8?B?U3lyasOkbMOk?= , amd-gfx@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, nouveau@lists.freedesktop.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v2 3/3] drm: remove driver date from struct drm_driver and all drivers Message-ID: References: <1f2bf2543aed270a06f6c707fd6ed1b78bf16712.1733322525.git.jani.nikula@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <1f2bf2543aed270a06f6c707fd6ed1b78bf16712.1733322525.git.jani.nikula@intel.com> On Wed, Dec 04, 2024 at 04:31:12PM +0200, Jani Nikula wrote: >We stopped using the driver initialized date in commit 7fb8af6798e8 >("drm: deprecate driver date") and (eventually) started returning "0" >for drm_version ioctl instead. > >Finish the job, and remove the unused date member from struct >drm_driver, its initialization from drivers, along with the common >DRIVER_DATE macros. > >v2: Also update drivers/accel (kernel test robot) > >Reviewed-by: Javier Martinez Canillas >Acked-by: Alex Deucher >Acked-by: Simon Ser >Acked-by: Jeffrey Hugo >Signed-off-by: Jani Nikula Acked-by: Lucas De Marchi Lucas De Marchi From xen-devel-bounces@lists.xenproject.org Wed Dec 04 19:12:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 19:12:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848728.1263551 (Exim 4.92) (envelope-from ) id 1tIun8-0003nk-Vc; Wed, 04 Dec 2024 19:12:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848728.1263551; Wed, 04 Dec 2024 19:12:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tIun8-0003nd-Sy; Wed, 04 Dec 2024 19:12:06 +0000 Received: by outflank-mailman (input) for mailman id 848728; Wed, 04 Dec 2024 19:12: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 1tIun7-0003nV-ID for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 19:12:05 +0000 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on20605.outbound.protection.outlook.com [2a01:111:f403:2009::605]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a42ad816-b273-11ef-a0d4-8be0dac302b0; Wed, 04 Dec 2024 20:12:02 +0100 (CET) Received: from BL1PR13CA0134.namprd13.prod.outlook.com (2603:10b6:208:2bb::19) by SA1PR12MB5638.namprd12.prod.outlook.com (2603:10b6:806:229::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.20; Wed, 4 Dec 2024 19:11:55 +0000 Received: from BL02EPF0001A0FE.namprd03.prod.outlook.com (2603:10b6:208:2bb:cafe::a3) by BL1PR13CA0134.outlook.office365.com (2603:10b6:208:2bb::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.9 via Frontend Transport; Wed, 4 Dec 2024 19:11:55 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by BL02EPF0001A0FE.mail.protection.outlook.com (10.167.242.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Wed, 4 Dec 2024 19:11:55 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 4 Dec 2024 13:11:54 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) 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 Dec 2024 13:11:54 -0600 Received: from [172.25.146.163] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Wed, 4 Dec 2024 13:11:53 -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: a42ad816-b273-11ef-a0d4-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Ky3LKFWY0uzH/WpOBrkV5pkSE60EVx/UKmHby8UJaAh4BGyr+fa75BMqSZLRuwawzL8EXxgKIYZGhG0TW1NNeWpmZUHoW/EZ0wXY19uZIpL5kIgxXpv0L2FE5NfLuxm1/EAZFfxUbEk08N+EkRBX/6z+iZBXjHuT62iNCFpvVUbroBwOiABnqWvHdbt/xEiw8Teid7F8/InzLfrVf3YgLIqq3GMj8RNEXpkAbaTqvPp4+7k/64JHFYPXFFyTFDsj3liRaJkKhGR4q34ey5yCpSXo1osCVeK5OhP83B2LUu8U5iFIBVoFfYu2MazdYI3iwchVTgpjkkVTURW5huXn5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VIvU9Z5ByWuz4UFhN3A/jP8+K+nyO8vRzw/nm2mnmWM=; b=Jy2mW2s1ojAuYbgQxS7zxf/rIaNofAKUhe8+wT+07WZFFtEQ5nz367U48rcr9V7G4Xr/NWtvC0dlI+X/I9T2Z4cq7Y1Eq0MbmdSzqYD8Jubz2FuUEx4FToBX8kaCpT6RX2h+AbFPoMA7YPwmRbSrXKn6R/Xjcrf51PktuyuiVZBP9UZq4Y212LpQ3QGhv2ZnZJTJANnPBzyhH9GbSY/xa3jIwdjDWh2x9Zb2XX4+ZrgJdEcEpKOCljeiwY6xhXSpYuJnrDgPgdcFqhMzDrb97tRXg22AryBOUbYDSMFzGa5PazhJMRDANV5TwFBUHw34TwmLbJYeFzZ3rFjAVkYq2A== 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=VIvU9Z5ByWuz4UFhN3A/jP8+K+nyO8vRzw/nm2mnmWM=; b=yOYbqjVGz7u/ff2m1kuOpb0OIY6ZXOXld3EUk4U8Ezo/2plrXQOzeG4I2p2MR6zwzh55kslgz/tzuuWhxIOXyaL0I9N8dF/3Yg8jd8nFFA+XyQzhE3KTVt9CiMTTpYIrSSm+97CFAHCjuDAs3UfyDfRAnjwWO2dtpGDkRTjlyuM= 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=SATLEXMB03.amd.com; pr=C Message-ID: <89ab9108-aa40-4da4-8e9f-dfa3bd49e2f4@amd.com> Date: Wed, 4 Dec 2024 14:11:52 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/4] xen/acpi: upload power and performance related data from a PVH dom0 To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Penny Zheng , Stefano Stabellini , Oleksandr Tyshchenko CC: Ray Huang , Xenia Ragiadakou , , , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20241204082430.469092-1-Penny.Zheng@amd.com> <20241204082430.469092-2-Penny.Zheng@amd.com> Content-Language: en-US From: Jason Andryuk 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: BL02EPF0001A0FE:EE_|SA1PR12MB5638:EE_ X-MS-Office365-Filtering-Correlation-Id: e1c04954-d3a4-4f88-626f-08dd149784a2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|36860700013|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?Rk9UMHRwTFRCbGlSc0kzaytZdVJyR3VKVHp6aE9JV0ZKWjBYVzhYZmJTUCta?= =?utf-8?B?enJjclIrMVNuWFpZMGsvcnFEa2VnZnRrV3Y4bjc5VXgwaWkwajl3TEJTR3M1?= =?utf-8?B?ZGhVQ0xYRjVFc2dlZmwxaHprU3BPNlpBYStzZVlOcERudkFqRVBSQlVlRUt0?= =?utf-8?B?d1cwaWlHeEhCbGRNMUhTT0ZkdFBEWXVNemRZWTU3ZWJOdGpUWk5paVduaUoy?= =?utf-8?B?K3AxYmU4VzdpMk5oOFJ4T00zY3IzMzNhd21jWVdHMDZBa2dyRzZEZmprdS9Q?= =?utf-8?B?bHVVb3FkSTFTLzZhUjFSU2JINFd3dEE3Z3Q2T2FxemtSczhkaXZBNm1wWjhL?= =?utf-8?B?Y3BtNTM3TWRpeFUrR3pkSlFsL1hLbC9KSlZtY1pmeU1kMWpBS3lTN2JnRU5m?= =?utf-8?B?ZXl1dmZwMkJNL3JiUU10TkorWndnbW1iTjZObXhLRnhXcmw0WEJvNTBpS21C?= =?utf-8?B?YldWYzJIb1dIQ3FSa0NoL0Mya20rV3J1Y2w5MC9DOHFpdllHeXFPTFJCVWFX?= =?utf-8?B?NjhEcUFOQmpVQWVGYXdDTndydEV4TmJtOVhJb1UvU1gyYVk4UCs3SGFVVUpx?= =?utf-8?B?TkNieXlBYjhOOTFxNnFtT2phM0owOHdGMzV1SzM5UVhiaENKQUtFVE9WUWw4?= =?utf-8?B?UENVaTRCOUNJblNERWU5UE14VXYxUzQ4Z3JNZDN2S2RmQU8yT3lNWjd5SlZS?= =?utf-8?B?d21EOEhaUy9qY2ZJeERMdjhwV3ZvSEtNZ1Y1WEZVLzlaL1NNaWNMMjBYSVBE?= =?utf-8?B?NTA5NmVDKzU4QWUyTUNseGhGQXMrLzFWdm8wbXRzZkxPTDBibnZRZnVVZGFj?= =?utf-8?B?Rm8zb29pVFJGandlbTQ0ZnQ5RFcwWW1UamFiUFZWcTdCTVE5THkydStweXJs?= =?utf-8?B?NVhaWWhTdVN3eWduazlxbzUwZlYvVzhkNjE1QWtGcFBnb01lM0J5dHNYNWZ5?= =?utf-8?B?bENvTHZ6SnhXbjZFWGEzQmFld1pmc0pJVGRVcmMzYi9tTE9NQ1haZS90d3BR?= =?utf-8?B?S0gxdWdHTG9pRnVJazh0bHdCWFh3VitVZG10VVRLa29yWC8xOEFxSFBvZ1A1?= =?utf-8?B?cDZHSzYyTnR0eDl6SER4dTNZclFhbXhFZEQxOXhBQmhsY1F3WDNGdm90aFAz?= =?utf-8?B?SHdiZFo4Z1RoSXQrZDNzZENUTTFaZktZbUo5VkEwUVlFREpGMTNnQnJha1J6?= =?utf-8?B?TXFGMDArdU5pSnIxRnRleEhVOHJ0aW9zVjI5czJSMVd3Ui9BeCtNVUVJYlZS?= =?utf-8?B?T05aVUR3OERSNk5vL2d0WlI5L2Q0UTVkUDBFRlJBWDIwc2pZV21FRlBmN241?= =?utf-8?B?RFhGb3FDNWNXRDBZcGFoYWZUeVphRENwRU80SDFTVzlzbnZtYnM0a2p4MnEv?= =?utf-8?B?bGpWSDlINlVKaExzQXVmN2wzT05XZzhSbUZGWlhFVUU3MVpCbkNUeGp5MHBx?= =?utf-8?B?ck53ZUovUzVRTUcwbXFnVWpUWmR4NC9QWEI0UWJ3c056WFB3ZVYwZ3dYTFVt?= =?utf-8?B?cmpUT1VJM1NRVDcxcUw4OVRocTZYY2hGb1pneldQV005djlsakExano0SGZW?= =?utf-8?B?cDFadm04K2U3dy9kZnJsUXREYXd4bi92YTlmeXFVd2hCRXJhUitCZ2hRMno2?= =?utf-8?B?ZnR4U1R6NmdRd0c2QmRONzVMdU1pZEt2YjJvSGRZZmJzZW5nLzhNVVg4QVRP?= =?utf-8?B?NEg4eThPVkk5dVJEd3FuRTV5ZW5NQjkxNG84VHBJcllFNHBmSmx1K21OMDVp?= =?utf-8?B?NFl0eURSTCtHcFBCMGhpSWNCYkpMbVVjaEJLTmpWUVNDem9oMS91eVlBMllC?= =?utf-8?B?cmRsTUVRTHE2SWp6d2lPWmI3VWFVQm0yYTVvVVJBcjdlQUNlUXUrRjBwWlUv?= =?utf-8?B?WHdkcVpMNDFVcE1YN2VaU1hsK3JpZjJaVU11K0dFVi9pclE9PQ==?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700013)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2024 19:11:55.3705 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e1c04954-d3a4-4f88-626f-08dd149784a2 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=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL02EPF0001A0FE.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB5638 On 2024-12-04 03:29, Jürgen Groß wrote: > On 04.12.24 09:24, Penny Zheng wrote: >> From: Roger Pau Monné >> >> When running as a PVH dom0 the ACPI MADT is crafted by Xen in order to >> report the correct numbers of vCPUs that dom0 has, so the host MADT is >> not provided to dom0.  This creates issues when parsing the power and >> performance related data from ACPI dynamic tables, as the ACPI >> Processor UIDs found on the dynamic code are likely to not match the >> ones crafted by Xen in the dom0 MADT. >> >> Xen would rely on Linux having filled at least the power and >> performance related data of the vCPUs on the system, and would clone >> that information in order to setup the remaining pCPUs on the system >> if dom0 vCPUs < pCPUs.  However when running as PVH dom0 it's likely >> that none of dom0 CPUs will have the power and performance data >> filled, and hence the Xen ACPI Processor driver needs to fetch that >> information by itself. >> >> In order to do so correctly, introduce a new helper to fetch the _CST >> data without taking into account the system capabilities from the >> CPUID output, as the capabilities reported to dom0 in CPUID might be >> different from the ones on the host. >> >> Note that the newly introduced code will only fetch the _CST, _PSS, >> _PPC and _PCT from a single CPU, and clone that information for all the >> other Processors.  This won't work on an heterogeneous system with >> Processors having different power and performance related data between >> them. >> >> Signed-off-by: Roger Pau Monné >> Signed-off-by: Jason Andryuk > > I think this is the V2 version of Jason's patch, of which he sent V3 just > yesterday? Penny's patch has some of the changes I made, but then I made an additional change and didn't tell her about it. > Please sync with him how to proceed: is his patch meant to be a > prerequisite > for your series or a part of it? Sorry for the confusion. Penny, I think you should just grab my v3 (https://lore.kernel.org/xen-devel/20241203225338.1336-1-jason.andryuk@amd.com/T/#u) and resubmit with that. It removes a BUG_ON that checkpatch complained about (which is unreachable because of an earlier NULL check). Thanks, Jason From xen-devel-bounces@lists.xenproject.org Wed Dec 04 19:17:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 19:17:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848739.1263561 (Exim 4.92) (envelope-from ) id 1tIus6-0004Px-Hy; Wed, 04 Dec 2024 19:17:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848739.1263561; Wed, 04 Dec 2024 19:17: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 1tIus6-0004Pq-F0; Wed, 04 Dec 2024 19:17:14 +0000 Received: by outflank-mailman (input) for mailman id 848739; Wed, 04 Dec 2024 19:17: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 1tIus5-0004Pk-D8 for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 19:17:13 +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 5b213348-b274-11ef-99a3-01e77a169b0f; Wed, 04 Dec 2024 20:17:10 +0100 (CET) Received: by mx.zohomail.com with SMTPS id 1733339821300558.3175722697706; Wed, 4 Dec 2024 11:17: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: 5b213348-b274-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; t=1733339823; cv=none; d=zohomail.com; s=zohoarc; b=JUIFAYTptMPu+D+S5wJzODsBXuz13Y95U2dMv2fbM+ykBQ7hQjogvnv05cDXt9pS9QSMuHI05GLEcTWHPn1iGL9wtmx8OZzpkiN+nhNGWxC2R8SEBXe4+xWg5xtDo4XwmSSgsFvLUd8acETBQbz4ZVIDVfb2IMNGJhhiZaf78vI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1733339823; 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=StuxpsyUAmqaaCDxtlpMU/g74F5wKRQHXEQ4hk5YQys=; b=Ht7tj7GYEYRLqNjIcmNJWhUGThoocP0khOqxbU1DQby0LTPaQC2jK63Rzgk7THPEhC8YBlKgS9EugC6RM1g3q5/Mnmnr51yxjHpVxD8En0BEi3npzwH/uank41OaVmItz9v8o7BSaFdWgO1xDzdwWWF9SkvlGoXBiCYPfAbP/js= 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=1733339823; s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=StuxpsyUAmqaaCDxtlpMU/g74F5wKRQHXEQ4hk5YQys=; b=gZ8JgUALYQDV5LsCbrKxl0N9JS49KFTFIpKvDXnxx3CAkVJFiwHV5eUgy3Fb4qR0 hPAJR3ZCErCNKvnoMUKy1egPIR5pd9fQRZVC4wt+seO2QwdNBIbJfGYPQx+hJJGhcRk y7V3uJlqMmeUDiSQRUwZU1AOB0czflWWKZn5KlQU= Message-ID: Date: Wed, 4 Dec 2024 14:16:59 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 01/15] x86/boot: introduce boot domain To: Jan Beulich Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com, stefano.stabellini@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241123182044.30687-1-dpsmith@apertussolutions.com> <20241123182044.30687-2-dpsmith@apertussolutions.com> Content-Language: en-US From: "Daniel P. Smith" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ZohoMailClient: External On 12/2/24 04:57, Jan Beulich wrote: > On 23.11.2024 19:20, Daniel P. Smith wrote: >> To begin moving toward allowing the hypervisor to construct more than one >> domain at boot, a container is needed for a domain's build information. >> Introduce a new header, , that contains the initial >> struct boot_domain that encapsulate the build information for a domain. > > Why does this need to be a per-arch header? Wasn't one of the goals to unify > things as much as possible? Correct and at this point the level of unification is this series that provides a common device tree definition. >> --- a/xen/arch/x86/include/asm/dom0_build.h >> +++ b/xen/arch/x86/include/asm/dom0_build.h >> @@ -13,9 +13,9 @@ unsigned long dom0_compute_nr_pages(struct domain *d, >> unsigned long initrd_len); >> int dom0_setup_permissions(struct domain *d); >> >> -struct boot_info; >> -int dom0_construct_pv(struct boot_info *bi, struct domain *d); >> -int dom0_construct_pvh(struct boot_info *bi, struct domain *d); >> +struct boot_domain; >> +int dom0_construct_pv(struct boot_domain *bd); >> +int dom0_construct_pvh(struct boot_domain *bd); > > I'm wondering: Just a few commits ago you moved these to boot_info. Now you > move them to boot_domain. Why the extra churn, and what further transformations > are to be expected? Introducing all the abstractions and adjusting all interfaces in one go was deemed too complex to review and originally done that way because doing it incrementally would require making changes to changes. Therefore it is an artifact of breaking the larger change into an incremental introduction of the changes. When the multi-domain builder is incrementally introduced, there will be renaming in place, splitting, and renaming as function are moved. v/r, dps From xen-devel-bounces@lists.xenproject.org Wed Dec 04 23:15:01 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Dec 2024 23:15:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848791.1263588 (Exim 4.92) (envelope-from ) id 1tIya3-0006rX-Tg; Wed, 04 Dec 2024 23:14:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848791.1263588; Wed, 04 Dec 2024 23:14: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 1tIya3-0006rQ-R2; Wed, 04 Dec 2024 23:14:51 +0000 Received: by outflank-mailman (input) for mailman id 848791; Wed, 04 Dec 2024 23:14: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 1tIya1-0006rK-Iu for xen-devel@lists.xenproject.org; Wed, 04 Dec 2024 23:14:49 +0000 Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [2a00:1450:4864:20::230]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8e0dd46c-b295-11ef-a0d4-8be0dac302b0; Thu, 05 Dec 2024 00:14:47 +0100 (CET) Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2ffd6882dcbso2025071fa.0 for ; Wed, 04 Dec 2024 15:14:47 -0800 (PST) Received: from eriador.lumag.spb.ru (2001-14ba-a0c3-3a00--b8c.rev.dnainternet.fi. [2001:14ba:a0c3:3a00::b8c]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-30020e2085fsm158771fa.83.2024.12.04.15.14.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Dec 2024 15:14: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: 8e0dd46c-b295-11ef-a0d4-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1733354087; x=1733958887; 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=ByDBggfihaA7bzylhtE2nPcYIo+DwLJnDtkfjIDytqw=; b=WgAlmLcZnDveqCDLxawek4l/+8MC3prjweUZtHNX89XB1lyWyWEgmm3e9vfWJ5bZLb sLfDn7tr6CFm0jvNd9Ms/i4H31pQHPdDcqbLITgxDEqRxe1RYIIxyDrwKdLCiFV2ZUu/ FDP3df5JPVX0MLbUFxvS1lbMwQDR0Fp+FnFjGuBf2tBoYWriyVl4BVHx7QiqD8QHU/9T UiuIQq7SOEY0jMn1OI6F+t3df4buz1xERiwzM0whyuSTNfttkCRHZ7NfDzdfkb2p46I+ HfkMUdEfl9fB0smeSxeq6OVD+UGwhzDGCyuB9FFEJ4MEJ20H437W+SC4vPXdwxJbXgZa cZLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733354087; x=1733958887; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ByDBggfihaA7bzylhtE2nPcYIo+DwLJnDtkfjIDytqw=; b=p+l52y3r9qC8VR83H5k1+jDDKgYzPyja69sX3WiHkZX0kgxcgqLPH7jFvxeoDa692L WD6vOQ+d1cVyudveRo1n721q1GhkKzu4pBrtfDxXvk4WHKnVO0F1Gf8p4HsCLNcNBr+/ yII0xmo+1jV3SPh1TpSWRU5Obq1YtbCfVkmadr08ZGwUzvDW0icjRPQJTp3IK+M1LAUi FMt+lidz9VHFpPb+A4M4QOeVY+ejK0Bk2aOP1/QR55bc2o60whAbdBlx2jm35fGArpYt vG9ezjnd61B3FOMicp4d9QjGzrpRZ4xXWmL+Bb/O2/F6fz4ApmfTwtj6W9zMmhkXh2uu HyRg== X-Forwarded-Encrypted: i=1; AJvYcCUmhJjxxJ9NdQOZ+UXv9KwlOivtcNEgl4a3frvSfeB0oLXsK/DIxBC/mjHwwl54Flb1tJCNRj7RvUg=@lists.xenproject.org X-Gm-Message-State: AOJu0YyDQao1anzxLAdpEoIROPQ0bM1cpM6S/RyWAa0Ixz8XzwCMWtpO vpDwyvAU+nyi9JRm8P6zVZRJujuktxo+sO7YpaUOSSJQiBoQwmRB1k76ohMZgvE= X-Gm-Gg: ASbGncv8hl5iFXY9+2aPXJGgrO7bj4Gk3lEDphDbxADzTLWAa+vetLuZrXxQqt6jSzN sF2Z0Mbb6lrJ232i+phhgBZpfrsWBJJKItxTzA6E723xV2sm/WJQMTLt7OfIGrXKxzoSISG5CsU n9Tc/7/9jRk2wA3K4v8I7OLeOz6vqK0Y6mNMJJWfY8XgyXuynT6pT79/BVyF9uhWIOUZIwqQD4J YWEZ4PS4/I/Q0P8Fqrvj25I2a9HNIPZK8mJJni2i22lWCjJb9rSfDrdLoBjlTMNy/ien6NQA9iF nYAdmWcrZkHl8cSa43AzIgDl1JVNWQ== X-Google-Smtp-Source: AGHT+IFuUS7Not1i5YzDB3gHy3ub9/hXvCvAwbQxzNqfeGQDqOoYZ6k6qPs0qszHy91ZjySfOh3ENQ== X-Received: by 2002:a05:651c:210c:b0:2ff:7a4f:e770 with SMTP id 38308e7fff4ca-30014eaa13cmr17797471fa.31.1733354087009; Wed, 04 Dec 2024 15:14:47 -0800 (PST) Date: Thu, 5 Dec 2024 01:14:43 +0200 From: Dmitry Baryshkov To: Jani Nikula Cc: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org, Javier Martinez Canillas , Alex Deucher , Simon Ser , Jeffrey Hugo , David Airlie , Hamza Mahfooz , Maarten Lankhorst , Maxime Ripard , Oleksandr Andrushchenko , Simona Vetter , Thomas Zimmermann , Ville =?utf-8?B?U3lyasOkbMOk?= , amd-gfx@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, nouveau@lists.freedesktop.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v2 3/3] drm: remove driver date from struct drm_driver and all drivers Message-ID: References: <1f2bf2543aed270a06f6c707fd6ed1b78bf16712.1733322525.git.jani.nikula@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1f2bf2543aed270a06f6c707fd6ed1b78bf16712.1733322525.git.jani.nikula@intel.com> On Wed, Dec 04, 2024 at 04:31:12PM +0200, Jani Nikula wrote: > We stopped using the driver initialized date in commit 7fb8af6798e8 > ("drm: deprecate driver date") and (eventually) started returning "0" > for drm_version ioctl instead. > > Finish the job, and remove the unused date member from struct > drm_driver, its initialization from drivers, along with the common > DRIVER_DATE macros. > > v2: Also update drivers/accel (kernel test robot) > > Reviewed-by: Javier Martinez Canillas > Acked-by: Alex Deucher > Acked-by: Simon Ser > Acked-by: Jeffrey Hugo > Signed-off-by: Jani Nikula Acked-by: Dmitry Baryshkov # msm > > --- -- With best wishes Dmitry From xen-devel-bounces@lists.xenproject.org Thu Dec 05 03:35:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 03:35:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848805.1263598 (Exim 4.92) (envelope-from ) id 1tJ2dr-0001tA-30; Thu, 05 Dec 2024 03:35:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848805.1263598; Thu, 05 Dec 2024 03:35: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 1tJ2dr-0001t3-0F; Thu, 05 Dec 2024 03:35:03 +0000 Received: by outflank-mailman (input) for mailman id 848805; Thu, 05 Dec 2024 03:35: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 1tJ2dq-0001sx-5J for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 03:35:02 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on20605.outbound.protection.outlook.com [2a01:111:f403:2612::605]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e70fbffa-b2b9-11ef-99a3-01e77a169b0f; Thu, 05 Dec 2024 04:34:59 +0100 (CET) Received: from GV1PR03MB10456.eurprd03.prod.outlook.com (2603:10a6:150:16a::21) by AM7PR03MB6417.eurprd03.prod.outlook.com (2603:10a6:20b:1bd::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.14; Thu, 5 Dec 2024 03:34:54 +0000 Received: from GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e%7]) with mapi id 15.20.8230.010; Thu, 5 Dec 2024 03:34: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: e70fbffa-b2b9-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=r8YGHhnVzx2Z/DKT9KMizrBdj1nPKn+LalrtmZqrJWNMVLcrVCgDIHTkQesUo2T8o/n8OCBr/J5aMHNSCoDb/mj/TSTWTYrGW68AixTVQtqpJERMdcc1zjVRKC0K5OgnyKiGv4pmCxpBN8stTl3bw5/aOws6SNEihyzZ/blMnL/FA0v0DA4Ly7+1hfT1o1QT66xi0HsNTeR9K6CF+hzi6UzwMTiy8SYplF4Gme3uNk7+LXKYBZKJngIThMysOw9ExuLW0VSu5YwcyHz/D9Cf/gU6R7MtuuXjWFWYDzMhO0akXRTPRiKi9Nk9M2fOgkOnGbXdoxnNkQTkPhMQWlXB0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BrsBh4e8GRaB9i/ixGAlg5QXPFJibfasQBHxP1XHJcU=; b=YjvyrZ7vYXrlpXTE5MxHu9RyeHK+NbRXj7QXl0dc/2/gFW9GIPDqKb8XbGFNbZ3NLSrWM5LgY210eMclDWjsEaz5lgSgOfn1pFHliJgYeNlKtzd1M5X+4Od/Mktrg2xbGxwQjG7tESZGAK5so39Lz/VamwteenxeioJdTeqcMt5X+C/74T3SHdU6isGvSRcKAwd3jfll1U5fTZZpbA5IXA2d9NFB9WGWTM0szypVYSETW59icg7Gk8yWJQX3TXbzm+nJSRHVz4mpqZ7t6STlChHwTtUoKB+Nd2KUfTbudfdSemOz+qjrSCysvLvI9jXrxMuHpC4sYuVa3eSUnPA39w== 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=BrsBh4e8GRaB9i/ixGAlg5QXPFJibfasQBHxP1XHJcU=; b=JnfXQz7SOATspFCcc8wAGpIK3usG6bLDlx9dcQC6GHYlNJQYHqCkPa/BTH7odlzC2pUb9V0Z/oqONM3GjBbymeSz1BqcK8sqW2sYCxbpDXkRLjRbc8kwwVTSw1sd6XoxojU4ZyU9UtE/CA/R4z/qnTLP/Yy8vvV5EPebJ6dq+5b6qsWPO6qk0GXySprdSoTIgq+SwehG0aqadFr50325pNGP4KfMbCSmMKgwy4tka/JvoZAbbArdswnEHSW+j6A44/quWlKbNxv3cghFukAnrGDDPjftHgs7+LdhWBiE7ZH456D12FD6/3avrnU5PBJhNITaf1cqDi7Gx/bke9K4ag== From: Volodymyr Babchuk To: Andrew Cooper CC: "xen-devel@lists.xenproject.org" , Jan Beulich , Julien Grall , Stefano Stabellini Subject: Re: [PATCH v2 2/4] xen: common: add ability to enable stack protector Thread-Topic: [PATCH v2 2/4] xen: common: add ability to enable stack protector Thread-Index: AQHbQsSdkWILXIuO706XPyPrUU1cAA== Date: Thu, 5 Dec 2024 03:34:54 +0000 Message-ID: <87o71q4xb7.fsf@epam.com> References: <20241130010954.36057-1-volodymyr_babchuk@epam.com> <20241130010954.36057-3-volodymyr_babchuk@epam.com> <4f2f949b-a53e-4a79-8084-d374cabc109e@citrix.com> In-Reply-To: <4f2f949b-a53e-4a79-8084-d374cabc109e@citrix.com> (Andrew Cooper's message of "Tue, 3 Dec 2024 20:33:07 +0000") 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: GV1PR03MB10456:EE_|AM7PR03MB6417:EE_ x-ms-office365-filtering-correlation-id: d7be533d-b0a3-479b-2a92-08dd14ddc898 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018; x-microsoft-antispam-message-info: =?utf-8?B?UnhmMFBad29sT2hlVmtGTzJjWnRBWUk4SkczZHdSK0VlM2FUMktjdUxhMXBT?= =?utf-8?B?cEI4L0tmWjI0OTlZRHJsK0wyQWJvSE5lbzh3bmM5eU5BWXo3K2pScEFyL3VV?= =?utf-8?B?TFd1emdYOUUvWUpjUldpRXA0bUNLcGR0d3JpdnNoL2FLcTZENjZiWkhKSlU1?= =?utf-8?B?ZmxGc1owQ0d0bDNadnpnYzlWSmlZRW8zSG5GOUZvVUp0RGh1bGR0Zjk5TGIr?= =?utf-8?B?dEpqdGkxNTRnbWRBVVZSVElmSG5NcXl4NFU0bFV3MXNBdC8vZWhuNG0yZEhz?= =?utf-8?B?cWRralY5UHlTcVRicTRCKzN4RnZtK0dqUmZsTmQ2NHFoVWYxYktQcDYxaCth?= =?utf-8?B?bHYzMnI2ZzVBL2dzMG5oMlVaNWhET3BTeVVWZVM3dHd5V1ZKR1V6cVo4VUlF?= =?utf-8?B?ZSt0T0FsUHh3RG54MkwzalpjaGZkTXprYVZvTDhBcGxXL0NtV0kwN2R0N01j?= =?utf-8?B?dlpPLzVSV0NMdmFqemZpbmRKSklmcDFYL3dTSmhZS2FZTENQT3ZhanU5emRT?= =?utf-8?B?TXVmOFFkRTlPZTMzcWlCUWQrckkxejNIQlNFU2dFT1I4UXp3ZEx0MnkvR3B0?= =?utf-8?B?Qk5nZmFxWExKbExGczk1Uy9kSG9XUFdkTllwOG1lZUNOWHRwWHN1eSs4aEd6?= =?utf-8?B?aDdQYTNSZUNOSHNxazdLRjNrN3JVc281cGhDZ1c3MVFUemlBWFhLc3l1d0xN?= =?utf-8?B?RDZ5K0U1UUVMa2xIM0xnMU5SelFWa2Y2QWxubDRrVGtielFPSFNWU3NiTjJn?= =?utf-8?B?TkQ4cG05T1RXdytPRndTWEw4VmtOL255TnRGSVpoU2ZNeEQ5amxTRm5mT3M5?= =?utf-8?B?Q2R2S1FhNzBVZVBtTHpQVXAvajUwVVZDYUpYa01ON3Q3a1RGQ25kVDZkWitS?= =?utf-8?B?bGFGZVhrZWlUWnFNcVdVK1p1aXpJYld5WDFTNXo5Q1ltNUJncVY3TjVCc2ZI?= =?utf-8?B?R3hzRWoxN2orUWxhdldISlA1RmRiaFF4OUQrWkJGZ2RvQUF5T3R1TkorZ3Ny?= =?utf-8?B?T3BnQThnM2s2NTNyUTMzekxBbG1vTGxSZnpMV0Z3OHArZ0lOQi8wb3pXaFZS?= =?utf-8?B?RGFFaE5TbWlIRHdLS1pEL0VuZlZhUTB6RWhLQWVGTkpoSVQ0Q0ppNUUrNnBx?= =?utf-8?B?MFMxbzVGbWFtMHNkSVo5WC9Eb2c5RmJZRE5GT0lLUFdTSkRZKytTYnVRV2dp?= =?utf-8?B?NHltbXNuZG92Wmg0aGpacW92U2dERkZ6UDdLVENiTVJjMjJZZGYvdVhXL3FG?= =?utf-8?B?Y1FHRGx3azRnNWpRMlN4L2k1QUJxQk5BNzFpNXAwbWdzZGhvOW9OcGZVZGhp?= =?utf-8?B?ZDh2b2ROQVE2eVNxb2pnVlZoL01vS0FjT1ppMjNDY3pmVW5xWVdhWGpsQTRU?= =?utf-8?B?NTZWZStSamgwWSswNFozaXQ5cnJUZ09TZ2V0aTNwU1l2OXdCNyswcElaNWM5?= =?utf-8?B?eXdPOUtvbjRNM3pmMStjenpWbjhuQWlJL002RUNyTVgwTU12NVZEalk5ZmI3?= =?utf-8?B?Y20xTE56aE9qK1JYS3liN0UzeXhHbmdKVGY5VndnUnhXUlliQWVGUVdKVFRu?= =?utf-8?B?djNXUy9CSUgyVHNkbUhhZVhlb0lPbk5IUlE2MEc0UnBLQnJUZUlZdWxVMTRO?= =?utf-8?B?VFBXYnFHUXdGZ3M4UVVVdTNFaC90ZHlYK1B5eGVTdm1Vb2YyU1oxdFNSZFZh?= =?utf-8?B?SlREYVVMSXc2MCtUUlg1MUtDTU5PRXNmekFFMWREYmtRczlBbm52blFqTzhk?= =?utf-8?B?OGM0TnZIQ28vV0RxWGxQQ3IvQ1E0Uno3SGlCangvMDRleFBKS0V3alAxYk1v?= =?utf-8?B?eEJOZ1NsOENDWnVvY0cvUSt6TVQ0QWc4RnZaNjJhTzc5TENKQmdkZGVwejJ3?= =?utf-8?B?WG9EQUV6cEVRYkUzQm1LM3hRZE0zaDBNT3hsZFlPZG5DT2c9PQ==?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ZW5FZDZGWDhnZlRSdVpNRm5LOGNKa1pOYXkvNncyN3JBVk9ubFNleStqZ0NH?= =?utf-8?B?T0x1U2FqRW5Xb1JBSEZZZnZxam9iaXdvS2ZMdEZOaXJuSmh1aVdWQXF0TElZ?= =?utf-8?B?WjhuYS9BQ2syT3V0K0hVclZEZjZaMTNJbWJpQkp2dGx3WXo0RFJSVHBwYjRP?= =?utf-8?B?WDhudEVCUW9DeFVOYk43bWlsMnIrVllWemxxQkJpakl2YmJtUFBJUUFzUGti?= =?utf-8?B?Y1laNDdBVDM5VGZXa25QYS8yTzRrWFZoZUx4d1lObytGbzRoQThxSEZpS29y?= =?utf-8?B?aU95UzdpVTBDMTZRL2REQWh1bUpHb0ZJWU04bGNkY0l4ZmprN0toKzc3M3ZJ?= =?utf-8?B?ZGQvc01lRTcwTnRqczdxMWN4WXU2SXdnNjNCdzhFVlJHVFllREtMTy83VTVh?= =?utf-8?B?dmowNXZyMHhHSzVTQkN5aThXeGxOeGZsaXlqcFQ3cHVWZU9yS2txUTlpUEkr?= =?utf-8?B?WmR2VlJ6MUJicnhBU3hrZmdiZWJNdzU3VDhPRlVrdjgxTmVDeWorN3lIZ1Yz?= =?utf-8?B?TTE4YTB4cVdMTHdWY29PRzJ4NEVZd0lYQTkzYXFFcEVjaCtYRE1pTVdoaXFu?= =?utf-8?B?eFJmUjduTGJWZUJlSzJ6TkFtNHdsdTNrRjliaFZrdlgrRkVFUXdSVlZyK3hX?= =?utf-8?B?aXM2RmFKN3VWZEV3cXVvWnRXcDhJWkppdmp3U2haOW5LT1dsRUdaK2R3OXRD?= =?utf-8?B?WUY3WWVNbVVsQnJmbW40a0E2YThTOWtDSW56Y2llVkU5RzhaRUJpaWRGcExz?= =?utf-8?B?NGpudkxDVS8xazM4M2RxSXhMdTA3U09zZWJ4ZXZjaGZ5YjJYci95ZFlJV3NB?= =?utf-8?B?L2FJQVBMUjUzcG9zVlA5UmhQZ2FXS2xZQUVsejdNTnNRRFY5dzMrUThsUWZx?= =?utf-8?B?Z1R4OGswZFZpL1FGUnJ1MnJYOGZSQm9RL3pzSjM4b004K2ErdktUMHd3eWM2?= =?utf-8?B?S0NvL3ZFVkpraU9VUkVSQ2g2OWhLY093TGFhQytGWlZ2WmNDVUV5WUVVZlZR?= =?utf-8?B?L0FxWGIvSjZPcDdJbjAwTkYxbjNvbklpMTl1OUszNmJlS0pJUy9jQXk4dWF3?= =?utf-8?B?Ti8xTFdFODMwOU1kaUg2RXlXRXpoL2R3Z2Z1SVdBQ0FoeEJ6TEJ3d2lqMndX?= =?utf-8?B?YytsSTUwOC9JZncwa0I4dmpsb2R5WERCSi9ieDJEaDRsV2UrM1NXWGNVaUl5?= =?utf-8?B?MnBEZ2FMZGtXOCsrWEFQWUJ6ajNjMzgxQjBNY2VHb0JyNXN3NEdnbnR0dktz?= =?utf-8?B?Qk1Jbkdkd0xKS0hEL3NsNUhucEZlQ0M3SFpOUXFqTFVqTHU4UzJKaUkvNThZ?= =?utf-8?B?cXZVOWJzcEpLZ0d5bjcxajNJa3JRSklwVEFZMDJsRmJPVmUzRzdHbENPWVZI?= =?utf-8?B?Yy8wMnE3WDNSSzkrY0k3UWJnMzJYdlQ5ZzdkU280YVFYVy9aRXMyeURUdXV5?= =?utf-8?B?Z3RKUmlrVHh4Rm5GUktLU0owTUJjam5xcndHOVU5VmF0ZGsvd3FCN0QyWk90?= =?utf-8?B?ZExjVExwdktzYkdZS09hdklQTFU0L3YvaEs3UDZQSUduMDJhK0g3UVl4aWg1?= =?utf-8?B?N0hpVjk3MmhzUkF1d2lSSU1HSnVjeUFEd0F3bXdWNFN6amp0SDNCdkdpVkt1?= =?utf-8?B?c0RwN3VsVERJai9HN2hIVVo4ZHNVcGlaNlphSThPVnpQSjcvOTR5MUhBcUty?= =?utf-8?B?MjFxeFhHaTBoWVY2cVhEQnBBTDd1R3lNTmE0V1FzdlRvZDlyeWdjN3Ywb1BN?= =?utf-8?B?dGY5dDFUU0dyUC9XRFlCVHorenpWbXlhbkNYWWxRMzVtWWV2bTAwN24wT25N?= =?utf-8?B?RFlpQzUvV0I3Rlo1cU94c2pmK29hY1VvYXJoSElnZW50RFdFcFJvY0NLcHJE?= =?utf-8?B?OG43R25FZzFmNWo0eTJNaDdWc1lHekl4TStyQXFJNHlOMFdDbmpaNUF6NkhZ?= =?utf-8?B?SVBFNDAxektkNC84c2FhcVFJZGVGY1ZTc2ZLVzc1ZGQvWS9NaUNzSGREWlB2?= =?utf-8?B?SzdoZjFpVjF1dCtQNGsvUTUzZ2FqKzRGUHpWQmI5VjJWRE1XcTR4Ui85TzJm?= =?utf-8?B?UWFXU081MXVwbnlMa1dpZ2paM3VWVWtadE9ES1FQTXJsWm9vTFVQYUdEZENm?= =?utf-8?B?M0dOM2NHY1RSejNLQmhObkZUeFZDTTJ4STBhSnpGblZjbzROQVVFTVBqUGRa?= =?utf-8?B?SkE9PQ==?= Content-Type: text/plain; charset="utf-8" Content-ID: <16B932742FFC9F46A5D8AB0E0E8EE830@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: GV1PR03MB10456.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d7be533d-b0a3-479b-2a92-08dd14ddc898 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2024 03:34:54.2172 (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: wrXSjj9q+2TL7lkGMp3SIj0lEfjqRwRGvX61qh1iGeCyU9RnbBS1X2fOpM9YqGLbxLgumY1ILMVP8Y8KYSGpa7Dcq35M1ibfeMBXPn1MP0E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR03MB6417 DQpIaSBBbmRyZXcsDQoNCkkgYWRkcmVzc2VkIGFsbW9zdCBhbGwgeW91ciBjb21tZW50cywgYnV0 IGRpZG4ndCBnZXQgdGhpcyBvbmU6DQoNCkFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNp dHJpeC5jb20+IHdyaXRlczoNCg0KPiBPbiAzMC8xMS8yMDI0IDE6MTAgYW0sIFZvbG9keW15ciBC YWJjaHVrIHdyb3RlOg0KDQpbLi4uXQ0KDQoNCj4+IGRpZmYgLS1naXQgYS94ZW4vY29tbW9uL3N0 YWNrLXByb3RlY3Rvci5jIGIveGVuL2NvbW1vbi9zdGFjay1wcm90ZWN0b3IuYw0KPj4gbmV3IGZp bGUgbW9kZSAxMDA2NDQNCj4+IGluZGV4IDAwMDAwMDAwMDAuLmIyNTg1OTBkM2ENCj4+IC0tLSAv ZGV2L251bGwNCj4+ICsrKyBiL3hlbi9jb21tb24vc3RhY2stcHJvdGVjdG9yLmMNCj4+IEBAIC0w LDAgKzEsMTAgQEANCj4+ICsvLyBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMC1vbmx5 DQo+PiArI2luY2x1ZGUgPHhlbi9saWIuaD4NCj4+ICsjaW5jbHVkZSA8eGVuL3JhbmRvbS5oPg0K Pj4gKw0KPj4gK3Vuc2lnbmVkIGxvbmcgX19yb19hZnRlcl9pbml0IF9fc3RhY2tfY2hrX2d1YXJk Ow0KPj4gKw0KPj4gK3ZvaWQgX19zdGFja19jaGtfZmFpbCh2b2lkKQ0KPg0KPiBhc21saW5rYWdl LsKgIFRoaXMgTUlTUkEgY2hlY2sgaXMgbm93IGJsb2NraW5nIGluIEVjbGFpci4NCg0KSSBjYW4g c2VlIHdoYXQgd2UgbWlnaHQgd2FudCB0byBtYXJrIGl0IGFzICJub3JldHVybiIsIGJ1dCBJIGRv bid0DQp1bmRlcnN0YW5kIHdoeSB5b3Ugd2FudCB0byB1c2UgYXNtbGlua2FnZS4gSXQgaXMgbm90 IGNhbGxlZCBmcm9tDQphc3NlbWJseS4NCg0KDQotLSANCldCUiwgVm9sb2R5bXly From xen-devel-bounces@lists.xenproject.org Thu Dec 05 05:24:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 05:24:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848841.1263624 (Exim 4.92) (envelope-from ) id 1tJ4LZ-0007SI-K5; Thu, 05 Dec 2024 05:24:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848841.1263624; Thu, 05 Dec 2024 05:24: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 1tJ4LZ-0007SB-Gf; Thu, 05 Dec 2024 05:24:17 +0000 Received: by outflank-mailman (input) for mailman id 848841; Thu, 05 Dec 2024 05:24: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 1tJ4LX-0007S3-PS for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 05:24:16 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on20631.outbound.protection.outlook.com [2a01:111:f403:2413::631]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 29af72b1-b2c9-11ef-a0d5-8be0dac302b0; Thu, 05 Dec 2024 06:24:14 +0100 (CET) Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by MW6PR12MB8897.namprd12.prod.outlook.com (2603:10b6:303:24a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.12; Thu, 5 Dec 2024 05:24:09 +0000 Received: from DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::b04e:2da5:7189:4c4d]) by DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::b04e:2da5:7189:4c4d%5]) with mapi id 15.20.8207.017; Thu, 5 Dec 2024 05:24: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: 29af72b1-b2c9-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dZrMNKeAbkh+Q5jfoKuWakCH1iZdTyFSOHuzXltULjcR9t1x7z8ErBLlsb5TttTYWo6wjycY1ZIoOI05RVqym2aw+hHyLr+EF9biLPW/p/ISKD7okc3ynVf5UJrDK49DDMm9VSY/u8IZb9T9tl9Z32LFSM8cbWERHWfJadoTXPW/bp415bsZKGTms4yVmGnMBpUsd1UhieJMNaMyud3qVzj5vvxiPnR/ulnKHaEY4oAmIVMhUf1uU0Ls4cCPMu36Q52+SGYey8YYcti7OtmZWH9nvcu1OO3t3bLuwpIMzWytgxXnQuOUCKn4cwGEUE4pt0MoRHLZIxwt0247qiQlhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9QGzr0bpIIS6cGjua0AR48f45vIQxjwsO4CcqQH7VWU=; b=HP+oif/7ddYsdneV4cR/IJcOpGFOu16T2MdY7jxNgp+8fWk1a/EoXqQhMtCtNBcQDBsPSKnYE0LBZDXmsDps+47eeGuJ8zvXvcdYMU/3glgAWe/xcsZVh3C2Dc3ApnP0zCDOlHhpfY65GOkk7jDtFJb81mqCBwcq6taJMNFsZN03R8T0n6RIMwq+BTjQ/ndI23rONeXToj3R2hlbGnVf5UShc7mMfU5gYRMVz7WIZae0BTdiB8m+no7L6IOkRuY2VCFuskbJ5QYcDKgmeI9RRb/Jhvolce7+6qN8xlK99QtA8PZvNgpLMRDz5NP7oPihLTJ9Nzfdjv3kRSRlN5wwDw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9QGzr0bpIIS6cGjua0AR48f45vIQxjwsO4CcqQH7VWU=; b=2XGSNPs0WLJDZGdqLnmGGL/cqClB9S6hAtzEWys1HnlZIF38r6stK8Sic6yDEn/lBHUK7qWKQzBf2G0ykjJfJ1dUVERMaNIavSG8k2M1xlGORHZgvwRBCH5fDEPX5DTSWrq1TAehsG3YYZpeET24YTTiN+/5oGAFzJ1Z/f1TSHw= From: "Penny, Zheng" To: "Andryuk, Jason" , =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= , Stefano Stabellini , Oleksandr Tyshchenko CC: "Huang, Ray" , "Ragiadakou, Xenia" , "xen-devel@lists.xenproject.org" , "linux-kernel@vger.kernel.org" , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: RE: [PATCH v1 1/4] xen/acpi: upload power and performance related data from a PVH dom0 Thread-Topic: [PATCH v1 1/4] xen/acpi: upload power and performance related data from a PVH dom0 Thread-Index: AQHbRiYT0x98jyXl30G0kVQmyAsIc7LVwRsAgACzWQCAAKqSkA== Date: Thu, 5 Dec 2024 05:24:08 +0000 Message-ID: References: <20241204082430.469092-1-Penny.Zheng@amd.com> <20241204082430.469092-2-Penny.Zheng@amd.com> <89ab9108-aa40-4da4-8e9f-dfa3bd49e2f4@amd.com> In-Reply-To: <89ab9108-aa40-4da4-8e9f-dfa3bd49e2f4@amd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ActionId=6ee03fae-d4d4-4996-ae84-4d17a9756712;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_ContentBits=0;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Enabled=true;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Method=Standard;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_Name=AMD Internal Distribution Only;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SetDate=2024-12-05T05:22:22Z;MSIP_Label_dce362fe-1558-4fb5-9f64-8a6240d76441_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|MW6PR12MB8897:EE_ x-ms-office365-filtering-correlation-id: 0b3f2a9b-7412-453d-d6b9-08dd14ed0b92 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018; x-microsoft-antispam-message-info: =?utf-8?B?RXVoYWRNcS9VdTlyaERlSHNwekQ3aXhKd2JEcEpINHlKT3E0MCt2QlRmOUM3?= =?utf-8?B?Q0w3YnpVMk91cFVSWEU2eTA5SDJHekJvRlMwalFQczM4ZUxPUElsMEJBbVdo?= =?utf-8?B?MTN2WVVOeVZrZDhWTjQyWmU5dUNnVS9zbjBLaGpSbVNUanpIc1NmYUVzbzMw?= =?utf-8?B?L1RhaDdOZ2FZbXlsN0hYNHk4OG5sZlBaTFcvcm9TSHpwbnY4MVYrLzNYcnlx?= =?utf-8?B?UXBWVTAwYnBqR1hOaFBhM2x3bHQ3aHVuRnBHQlhsb3h2RXNrVFp6THJEOXFP?= =?utf-8?B?LzlOUjArVkxITnNrWmhPVFc4NVpXeHlzUzJEWTdZTEdyazZOZUNaRUdDM2tk?= =?utf-8?B?VERoTDJ0dGh4NmZLVjlseWtDTFE4eXBsMUdTN2kralBmc0Q5bHA5VFJHckJL?= =?utf-8?B?RmxtV3AxRk5YaG5CdCtUZXBvM1NlbStQUi95cXE4K1dGWng0enh2eUEvdnUy?= =?utf-8?B?TkZUVnY1U3pWalBwYmtSeWJUV2M0Z2ZpM0k1d3RqMFM0VHNqR1FjMVg0bkdW?= =?utf-8?B?Wm9SMkI1OEh0NkVYckgrN1Z0QlZ6N1dtQkNRTDMybldnZXU2cjc1NTkrU1dt?= =?utf-8?B?ZlQyajJxSXFvRUNjVXBHRmorOVNsbG1SbUxXL2lPRzZOYi81dkt6cldLb1I5?= =?utf-8?B?YzJZYTlzdW5MbS9WaUxEZ1d2cHFvZVQzSiszOE9saWJYQW9NZzhxSkE5Tjdi?= =?utf-8?B?aU9FUStGSFpTcUd5NlJ5cE5ZakJDNWdQTnBMTmZkQ2VMUmlvT3BEam84MmYy?= =?utf-8?B?WkFqUUdDb0U3K2xUd1VGWi85aGd1WDN4d0RhVGxlVUQzdTJ3SS9RRTc0Uldu?= =?utf-8?B?czMrQi9MSTQveUNPRWY1ZzA4ZXp6d292dG1ENlExODJuaVN3V2JrZ1pkd3VR?= =?utf-8?B?VGx2VjE2cUJwckNCNW9icDBxYnBiOVZoK2MwNWpLTU5raStDTkszcmRuU2F6?= =?utf-8?B?RXN5LzhscHp1VlpwUk5JMEVoZEgvcUgzU2tKdmJjRkV3WFBnTVBVVHNBL2VD?= =?utf-8?B?aDVJYTNMeDB5ZVhSWHFYT2o4UmE2NVE0cmcyTWk3ZTBmcS9LR1dEdldEL1N0?= =?utf-8?B?OURHR1dIZzBBKzlrMzJJOVoyNGpmbFkwUzkrd0FKbzBCWE9DVk5hNmkvaXho?= =?utf-8?B?WHR1UUhycVBiTDZmWVEzYldaQkZ1Ukw2S2RaREVjWFAyU3BUSUZSYUVlNHZX?= =?utf-8?B?YUJsNkdKY2tkbGE0RFN1QjlJLzJqQkdvVWllZlB2WVFPckw5cVJEbXJtK0h5?= =?utf-8?B?R2pjaXk5ektOWmlpNXl1ZXpOYm9wOERtVTJEdW9pa08renJmZ1RHaDVjcE9v?= =?utf-8?B?VlA4WDFXdGRxaHRkM0tEang3N2RPOEJocktZbGVBN2FTbXFuWnRIYSt2UHhv?= =?utf-8?B?L2ltd0VhbGNNcDZFTTFOVE1XdTdSYXZPMU0yQStaTllHR2pvQjdDRXlkK3hn?= =?utf-8?B?RFpqQUpwbVVYY2FURTkxaWRIbHZDZWVFcUZYU3NlaGpoRko5aEtpdmpDQmRC?= =?utf-8?B?ZmMrU0dKNzBzWEttTFZMOFA2REJ3QVhqU3crVFNvYy9ZeWM2djhPNWI0ZXBB?= =?utf-8?B?dEFqMlEranJXclpKQTlSTFRiamRpelBQU3kvZ1hSQ1VqOWEvOGlzOWk3a3pr?= =?utf-8?B?WTVKOHZFT3JhVDJYTWw5MjR0eW5HanNObitsR3lqWGpSSURJZW1LMDQyTVFw?= =?utf-8?B?aVZESGt1MVo0a2xsSFFjY01CS0JUNmFKNTZmNFJSdGhoMWlDOHU2OENlajVC?= =?utf-8?B?N3FKWTl6dC80RVZXOTh1S0h0TCtMZnM2RVdBK2thTkg4VURqcGVxYWxGQW9N?= =?utf-8?Q?nphfglkOoHP9hy01Us6/RWoa/tEdassn61JG4=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB8451.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VUF0QS8wTDZrUkdGZUhlcG40U3BBUnMwRFJXaVhwWElZTzZzTnFtcnNtYkEw?= =?utf-8?B?VjR2N1E2TmpzaTRCWHFoL2NtbzJpbnJqVzhiUnB1UHEwYWxwNmgzUlhDSnpi?= =?utf-8?B?dDdqaEV6WXNRZmNSVjhadzZHV3VUTU9sRmJmRE85dGxVZlljSG13Ri9LcitI?= =?utf-8?B?d0tyU1NoSlEvUmN1N1B4U05HWWdLQWNvQUNKOE9Sek9yKzRZVUxxVXhtaUVj?= =?utf-8?B?emk0VTMxY2hudjJMUlFBS2ptNkdpeTdkUWd4UHlQMnd1Visvelh5dUxxYjUy?= =?utf-8?B?UThNdCswMzcxUzFGc1J1TW00Z0IwYjJ0ZFVKdFkzNFphZzhHcGkyNnkvaDNN?= =?utf-8?B?UlRhakhtYVFvU3dvWWM2UlRTMEVsdm9LdGU1WWpoc2pqTzVhVlhsWEhyR2ov?= =?utf-8?B?MzBlL1BrUG80NUV1dmdaRkJNaFpUY1VQSWZrbnpxbldNVDE2RzFhN2FPQkRl?= =?utf-8?B?ZlRXbWZaUWVuelBYMjE3SHpNRzRZVDU3TVhQZllNNktJN2ZoOHNZYTJ2Wmg2?= =?utf-8?B?Z2NNQzdtUXc3bzY1Yis1RVZ3clQvN0M4dnFmZkRicGl3U01mVExHeU5IdzRy?= =?utf-8?B?MEtIMDkzYmRmU3V2T2ErdG1hK0c3OEJZR0JXMWIxbGliK0xNUVU5RWZKWE5Z?= =?utf-8?B?cVFndW4xc3JTRFErTSt6TFhicFZPcVpBS21IMjYwbkFtQklvSXBpcjBLTDAz?= =?utf-8?B?WXNVckZaMERvdmRGdHRvemxYNUNNVEtyVEJVUmsxZmhVWmcyL1BRM3BORXo2?= =?utf-8?B?U2RicWp2eWI0VDRMdVVZYzVqZHFBY05QbVNUMElOd0lETUJRQVZIRHpvQ3pH?= =?utf-8?B?dFhJbVNlVTRld1M0b0ZoZXVyTEJxWWZ4d2NhTFVpK3pYZjViR3JHOXI1cndq?= =?utf-8?B?dlRkZG1tek8zenM5ay9NUWhidTZXRFNob0hXZ1dVbDZRL3JxNDczcTlJOWZh?= =?utf-8?B?VUx6S0RYaVNIcldhS2NEOFM1VVBXVEx4VUFsNFNUeGVaTDFVcnJncGdsaTRp?= =?utf-8?B?WEpvT2FoMUhZSHlxYWZJSjQ0WWtmRDNvSnFzTHQrUVdiRjh4L0gwa2RHc0dx?= =?utf-8?B?ZXFMZ1A4MGlwZjVDMU5STWsrRnJPaitLSVh5R2w2NFA4MGdRRzRkRVlYaGlD?= =?utf-8?B?Vm9jR0pBR0MwQXo5aW9tU29BN1dtbmxocWJuR3FnOXpBQjZDTHBYbkRibVdV?= =?utf-8?B?bWwxL0hCR0tyeFFZcnB2bE8rR2swaTlJMVkrZk12K0JhNGdIZG1wVG5YWjVN?= =?utf-8?B?cS90eUFZVVQ4S2M4R0pUQXJVazFRQk9pSEF3UVJzd3luS0k3MEd0NG5tM05t?= =?utf-8?B?bmZmTnM2UDBRTmw3Rm42bnRQdzhDdFRuYXRsZFhyd1RDb0Y0ODlnZy93Z1Bi?= =?utf-8?B?NGhEdFhTanArbk1CeTJoTWx0aFlycW4xaHE2eUdocUJpcUZLVXdneStBdzJM?= =?utf-8?B?TUprN0ZHaEs0V21lb2R0eUZ1SGV2MUxibG03KzBMaERNTGV4Rkp3d3RsTllB?= =?utf-8?B?VUh2b0VUdUtKNzJXMlJKOU9lR1lHRXEvUU4ralBNNWRZcG9lQUkrMDd3WjBK?= =?utf-8?B?c20yWGJVY2pSemlVdTlNMnM2VDhRT3g4NjAyRG9vdEVtQmYrZWpjR1Y4TFJ3?= =?utf-8?B?bU1MWVJUZWRZdm1VQms5OXpEMUhEZkxjSUpkUkp5RFZWNmRUY1BpaC8rdTJO?= =?utf-8?B?SUJ1U052WHJwOGtIUHgwNGZ6T3d4N3MrRW9jeFRqRWVMeml4TjMwUFhDZ20x?= =?utf-8?B?bUhmR0YwYzZnQzU3T3ErSkI5c0NpWjdCb3B0d01BWVRNZ09saVNZUjJvYUdt?= =?utf-8?B?OUtyeERiTURKbnNJMk10aXlDa2VxRmU3eUttMXBsK1h5eXc3NldMUjUzYU8x?= =?utf-8?B?aTlQRnlxekw5WVRqdmhmOFVaUjQ2RkgvY2s4alZWK0Yzb1NxWjZnaTNxNUhW?= =?utf-8?B?R2wyK3ArQnpQbk1SSTFJSWQ0dThtZVMvQXN3RitZM0w3b0svak83S3hGTE0v?= =?utf-8?B?ZmZKbitUYURUemU1M2ZiQ2ZTeXhPSk05ZkhtWW5aYWNUY2N6N1hMZ3FOc01L?= =?utf-8?B?aUR0aUNUaEowbnNQa0hNcVhxQWZndnZmL2UrSVNoaU4yRVJzRXhyYUkvNjN3?= =?utf-8?Q?EulA=3D?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0b3f2a9b-7412-453d-d6b9-08dd14ed0b92 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2024 05:24:09.0317 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IRo0r+cuMXYw8S5Uf1R2xHZ8r19ihcReoOkXIJcOT5Rs4ODWJ86/ygRXwpTrEwb+E2P0vcZuiafJeHXiK/Baqw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8897 W0FNRCBPZmZpY2lhbCBVc2UgT25seSAtIEFNRCBJbnRlcm5hbCBEaXN0cmlidXRpb24gT25seV0N Cg0KSGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmFzb24gQW5k cnl1ayA8amFzb24uYW5kcnl1a0BhbWQuY29tPg0KPiBTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIg NSwgMjAyNCAzOjEyIEFNDQo+IFRvOiBKw7xyZ2VuIEdyb8OfIDxqZ3Jvc3NAc3VzZS5jb20+OyBQ ZW5ueSwgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5jb20+Ow0KPiBTdGVmYW5vIFN0YWJlbGxpbmkg PHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+OyBPbGVrc2FuZHIgVHlzaGNoZW5rbw0KPiA8b2xla3Nh bmRyX3R5c2hjaGVua29AZXBhbS5jb20+DQo+IENjOiBIdWFuZywgUmF5IDxSYXkuSHVhbmdAYW1k LmNvbT47IFJhZ2lhZGFrb3UsIFhlbmlhDQo+IDxYZW5pYS5SYWdpYWRha291QGFtZC5jb20+OyB4 ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmc7IGxpbnV4LQ0KPiBrZXJuZWxAdmdlci5rZXJu ZWwub3JnOyBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4NCj4gU3ViamVj dDogUmU6IFtQQVRDSCB2MSAxLzRdIHhlbi9hY3BpOiB1cGxvYWQgcG93ZXIgYW5kIHBlcmZvcm1h bmNlIHJlbGF0ZWQgZGF0YQ0KPiBmcm9tIGEgUFZIIGRvbTANCj4NCj4gT24gMjAyNC0xMi0wNCAw MzoyOSwgSsO8cmdlbiBHcm/DnyB3cm90ZToNCj4gPiBPbiAwNC4xMi4yNCAwOToyNCwgUGVubnkg Wmhlbmcgd3JvdGU6DQo+ID4+IEZyb206IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRy aXguY29tPg0KPiA+Pg0KPiA+PiBXaGVuIHJ1bm5pbmcgYXMgYSBQVkggZG9tMCB0aGUgQUNQSSBN QURUIGlzIGNyYWZ0ZWQgYnkgWGVuIGluIG9yZGVyDQo+ID4+IHRvIHJlcG9ydCB0aGUgY29ycmVj dCBudW1iZXJzIG9mIHZDUFVzIHRoYXQgZG9tMCBoYXMsIHNvIHRoZSBob3N0DQo+ID4+IE1BRFQg aXMgbm90IHByb3ZpZGVkIHRvIGRvbTAuICBUaGlzIGNyZWF0ZXMgaXNzdWVzIHdoZW4gcGFyc2lu ZyB0aGUNCj4gPj4gcG93ZXIgYW5kIHBlcmZvcm1hbmNlIHJlbGF0ZWQgZGF0YSBmcm9tIEFDUEkg ZHluYW1pYyB0YWJsZXMsIGFzIHRoZQ0KPiA+PiBBQ1BJIFByb2Nlc3NvciBVSURzIGZvdW5kIG9u IHRoZSBkeW5hbWljIGNvZGUgYXJlIGxpa2VseSB0byBub3QgbWF0Y2gNCj4gPj4gdGhlIG9uZXMg Y3JhZnRlZCBieSBYZW4gaW4gdGhlIGRvbTAgTUFEVC4NCj4gPj4NCj4gPj4gWGVuIHdvdWxkIHJl bHkgb24gTGludXggaGF2aW5nIGZpbGxlZCBhdCBsZWFzdCB0aGUgcG93ZXIgYW5kDQo+ID4+IHBl cmZvcm1hbmNlIHJlbGF0ZWQgZGF0YSBvZiB0aGUgdkNQVXMgb24gdGhlIHN5c3RlbSwgYW5kIHdv dWxkIGNsb25lDQo+ID4+IHRoYXQgaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8gc2V0dXAgdGhlIHJl bWFpbmluZyBwQ1BVcyBvbiB0aGUgc3lzdGVtDQo+ID4+IGlmIGRvbTAgdkNQVXMgPCBwQ1BVcy4g IEhvd2V2ZXIgd2hlbiBydW5uaW5nIGFzIFBWSCBkb20wIGl0J3MgbGlrZWx5DQo+ID4+IHRoYXQg bm9uZSBvZiBkb20wIENQVXMgd2lsbCBoYXZlIHRoZSBwb3dlciBhbmQgcGVyZm9ybWFuY2UgZGF0 YQ0KPiA+PiBmaWxsZWQsIGFuZCBoZW5jZSB0aGUgWGVuIEFDUEkgUHJvY2Vzc29yIGRyaXZlciBu ZWVkcyB0byBmZXRjaCB0aGF0DQo+ID4+IGluZm9ybWF0aW9uIGJ5IGl0c2VsZi4NCj4gPj4NCj4g Pj4gSW4gb3JkZXIgdG8gZG8gc28gY29ycmVjdGx5LCBpbnRyb2R1Y2UgYSBuZXcgaGVscGVyIHRv IGZldGNoIHRoZSBfQ1NUDQo+ID4+IGRhdGEgd2l0aG91dCB0YWtpbmcgaW50byBhY2NvdW50IHRo ZSBzeXN0ZW0gY2FwYWJpbGl0aWVzIGZyb20gdGhlDQo+ID4+IENQVUlEIG91dHB1dCwgYXMgdGhl IGNhcGFiaWxpdGllcyByZXBvcnRlZCB0byBkb20wIGluIENQVUlEIG1pZ2h0IGJlDQo+ID4+IGRp ZmZlcmVudCBmcm9tIHRoZSBvbmVzIG9uIHRoZSBob3N0Lg0KPiA+Pg0KPiA+PiBOb3RlIHRoYXQg dGhlIG5ld2x5IGludHJvZHVjZWQgY29kZSB3aWxsIG9ubHkgZmV0Y2ggdGhlIF9DU1QsIF9QU1Ms DQo+ID4+IF9QUEMgYW5kIF9QQ1QgZnJvbSBhIHNpbmdsZSBDUFUsIGFuZCBjbG9uZSB0aGF0IGlu Zm9ybWF0aW9uIGZvciBhbGwNCj4gPj4gdGhlIG90aGVyIFByb2Nlc3NvcnMuICBUaGlzIHdvbid0 IHdvcmsgb24gYW4gaGV0ZXJvZ2VuZW91cyBzeXN0ZW0NCj4gPj4gd2l0aCBQcm9jZXNzb3JzIGhh dmluZyBkaWZmZXJlbnQgcG93ZXIgYW5kIHBlcmZvcm1hbmNlIHJlbGF0ZWQgZGF0YQ0KPiA+PiBi ZXR3ZWVuIHRoZW0uDQo+ID4+DQo+ID4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uw6kg PHJvZ2VyLnBhdUBjaXRyaXguY29tPg0KPiA+PiBTaWduZWQtb2ZmLWJ5OiBKYXNvbiBBbmRyeXVr IDxqYXNvbi5hbmRyeXVrQGFtZC5jb20+DQo+ID4NCj4gPiBJIHRoaW5rIHRoaXMgaXMgdGhlIFYy IHZlcnNpb24gb2YgSmFzb24ncyBwYXRjaCwgb2Ygd2hpY2ggaGUgc2VudCBWMw0KPiA+IGp1c3Qg eWVzdGVyZGF5Pw0KPg0KPiBQZW5ueSdzIHBhdGNoIGhhcyBzb21lIG9mIHRoZSBjaGFuZ2VzIEkg bWFkZSwgYnV0IHRoZW4gSSBtYWRlIGFuIGFkZGl0aW9uYWwNCj4gY2hhbmdlIGFuZCBkaWRuJ3Qg dGVsbCBoZXIgYWJvdXQgaXQuDQo+DQo+ID4gUGxlYXNlIHN5bmMgd2l0aCBoaW0gaG93IHRvIHBy b2NlZWQ6IGlzIGhpcyBwYXRjaCBtZWFudCB0byBiZSBhDQo+ID4gcHJlcmVxdWlzaXRlIGZvciB5 b3VyIHNlcmllcyBvciBhIHBhcnQgb2YgaXQ/DQo+DQo+IFNvcnJ5IGZvciB0aGUgY29uZnVzaW9u LiAgUGVubnksIEkgdGhpbmsgeW91IHNob3VsZCBqdXN0IGdyYWIgbXkgdjMNCj4gKGh0dHBzOi8v bG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC8yMDI0MTIwMzIyNTMzOC4xMzM2LTEtDQo+IGphc29u LmFuZHJ5dWtAYW1kLmNvbS9ULyN1KQ0KPiBhbmQgcmVzdWJtaXQgd2l0aCB0aGF0LiAgSXQgcmVt b3ZlcyBhIEJVR19PTiB0aGF0IGNoZWNrcGF0Y2ggY29tcGxhaW5lZCBhYm91dA0KPiAod2hpY2gg aXMgdW5yZWFjaGFibGUgYmVjYXVzZSBvZiBhbiBlYXJsaWVyIE5VTEwgY2hlY2spLg0KPg0KDQpT dXJlLCBJJ20gZG93bmxvYWRpbmcgeW91ciB2ZXJzaW9uLCBhbmQgd2lsbCByZWJhc2UgYW5kIHB1 c2ggYSBuZXcgdmVyc2lvbiBoZXJlfg0KDQo+IFRoYW5rcywNCj4gSmFzb24NCg0KTWFudCB0aHgs DQpQZW5ueQ0K From xen-devel-bounces@lists.xenproject.org Thu Dec 05 05:43:33 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 05:43:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848857.1263643 (Exim 4.92) (envelope-from ) id 1tJ4eA-0002FM-CV; Thu, 05 Dec 2024 05:43:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848857.1263643; Thu, 05 Dec 2024 05:43: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 1tJ4eA-0002FF-9i; Thu, 05 Dec 2024 05:43:30 +0000 Received: by outflank-mailman (input) for mailman id 848857; Thu, 05 Dec 2024 05:43: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 1tJ4e9-0001z8-AG for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 05:43:29 +0000 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on20617.outbound.protection.outlook.com [2a01:111:f403:2417::617]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d9891a44-b2cb-11ef-a0d5-8be0dac302b0; Thu, 05 Dec 2024 06:43:28 +0100 (CET) Received: from CY8P222CA0013.NAMP222.PROD.OUTLOOK.COM (2603:10b6:930:6b::6) by SJ2PR12MB8783.namprd12.prod.outlook.com (2603:10b6:a03:4d0::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Thu, 5 Dec 2024 05:43:21 +0000 Received: from CY4PEPF0000FCC2.namprd03.prod.outlook.com (2603:10b6:930:6b:cafe::1a) by CY8P222CA0013.outlook.office365.com (2603:10b6:930:6b::6) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.9 via Frontend Transport; Thu, 5 Dec 2024 05:43:21 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CY4PEPF0000FCC2.mail.protection.outlook.com (10.167.242.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Thu, 5 Dec 2024 05:43:21 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Wed, 4 Dec 2024 23:43:17 -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: d9891a44-b2cb-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=g5IU8p+c0CjXps19m4rZ3HVlRkE3B7xnWh/wbZ3j08JApanIbPoO3VnASiufSDoN2yM7UQTCl451OPIeQqCCjCV4eyutqnl/6mh8Mcie1z85MVT+SFMs4GjhaZhyW9EZvwgh3RMdpTSJDqqzQCQgCrsBuhrH6itKaXUby27gWEAHJyfoRKpzoEwHiMqNOTGF+lSsaJN6c+Nr3bEn1pKPRROzB+H3ZlOw0QX04MpuL3rBqPYyc7oGVd0+7XCSdduCf5ADU8KM+UL8f7V7sNmzEbD6tBFZ9K+PiydqrrX3yi2p6zAS7QlCZOQftBp0zbqhOMwzbHCyYN/ALHmOSo7t5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=A2mvoo0AwSmZHRNlDBxrD1PqpsXiFjqStSx71eJmWSM=; b=UPODDh/IMdn2eJ4WYxWTFfm9Yj5p3wM4+s6sCM7RqF2V8yzGWfoysICx6fmiN+onocscblKPmQst/nTB5gLw8E3a5sZy/JDQ2tyUAS4WV70JETbG/ZRiD2D1aFkOehHzEH1H1w5cBa7nPq5VILBWEP1+surJpHTLrAHmNmcCeCNwk5T3lp89K9thK6mrbvSSAuLmN7pypNPM27ZbJ6boaRkIPKSuJMdxTTpF0ZDMYVL80jida0eSQ7WcyclZ4OwdS3i6VuS6rYM52eJ+WYrLVG3jtzHyCcVQUq0l3tusKvRQO9FYJ0LFriAwvpDdhRzCItvlqlp/W88P4CMSpQ5SYw== 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=A2mvoo0AwSmZHRNlDBxrD1PqpsXiFjqStSx71eJmWSM=; b=nsFaJIkZpjJr7/jaFfc/lmXclPq/6cWh5sJ9nqWCfb2JAydkLqmFVA9eanTrEy0J9YzUEHHsC4MnDP21WG2CoN0T1cqlW28eyelhXUS6+M6L4cuHSOFHyhZLK7OTR3hxXH0HzpJEmqZN51x2heEKLlJHH+pSxvUP8b9t2HO+uBw= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko CC: Ray Huang , Xenia Ragiadakou , Jason Andryuk , "Penny Zheng" , , , Roger Pau Monne Subject: [PATCH v2 1/4] xen/acpi: upload power and performance related data from a PVH dom0 Date: Thu, 5 Dec 2024 13:42:49 +0800 Message-ID: <20241205054252.471761-2-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241205054252.471761-1-Penny.Zheng@amd.com> References: <20241205054252.471761-1-Penny.Zheng@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000FCC2:EE_|SJ2PR12MB8783:EE_ X-MS-Office365-Filtering-Correlation-Id: 4bfe8ce1-6aef-43e0-8368-08dd14efba6b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?UGlhcmlzeXl3bHV2ZUdwV3ZOVFJKblhVZzdUR3VpUnFDTVozaHhuaFNDUEl5?= =?utf-8?B?aVNROXI0TzExakhpU1Z2MGNvUDhjYW5YSXovQWhCZUpFTDQ4UU1kdjI1am5X?= =?utf-8?B?SHFrampoL2orMTl0aTBCUC80aitUZThLNDZsWExBenJhR2ZFa3lIQnNLVFRU?= =?utf-8?B?Qm8zd3JtWm5NTVV2cXVaR1Y0eC9XZTQxaHZyZElISElKSmpCeHF0d1N6aVQx?= =?utf-8?B?RHZsV3h3dy9PYUJJVnFGcEplbUlSTG9YdTNQcHhUcytzRVRRSUJTeTB2OUND?= =?utf-8?B?ZW13ME1BU3loZkFqODBkOTNxN2dXYTdzNEJaR3FSZHBORmg3NUpLSWlLWFpG?= =?utf-8?B?WHRMalFuNTlDV2d4amljRkE4QmF5NXV1R2pZNitRcnRkNFY2WkY1Z0xxVVFT?= =?utf-8?B?QXlwYkhMTXZJS2xvdTZUR3l6cGZLN25tWm1tY1F4dnVBempOZHFsaDdQVmRE?= =?utf-8?B?ZzBSTWt1b1R4RzBmMFlaNHhKcDVTQ2tNT3lEYWZ3Wk81c0NCZVByNmhFdVFX?= =?utf-8?B?SVV1UE5oWHZSdUM1SEl6RFZsMW9ndjVIVUJlL2R1aFpuN0duV1BoRmI0VWE1?= =?utf-8?B?MTJTdW5QMndRRTM2L0JrY3dzR2svN2N4cTdtYktqdkgrOTBLbkY5U1hhbHJm?= =?utf-8?B?dld4bi9HL2thTjAwUHY1TXhVaHdLMDM5OUhrSDY1RVdTV09taVQyWEVpTllB?= =?utf-8?B?ZFhiMGJZRitxNHpxblJGOXlOUlFRL2JRVW53Qjh4anBoZ0w4T1lJbVpKL1kv?= =?utf-8?B?dVlSeVBXdGpTV0J3M2Q3ZitkaDNmblBrdTRicHpmLzEyTVhQZUVNQTBGT1A3?= =?utf-8?B?UkhJaVprTlMxK3J3Z1B1S09Pc05sRFNJcXNlVWNYV0RWT3FmMWk5V1FiL2sv?= =?utf-8?B?elArOTFQb0xNd3dpYUg0ZER1RXpPY0hsWTRNODNBbUFYQ1JwTlF3aUFKck85?= =?utf-8?B?ZUcvUWtUZ3hNeStBZlVLS1k0cG1Ub3dlUnUra0ZlUkZRR1JZUURoeGZLZHla?= =?utf-8?B?NThoU2FzUzc0OUMzVS9PNjA3N1lTSm1jR0dSQnRXRVUycCtQM05xWFZWVTVE?= =?utf-8?B?aUNIVzlicWdwT05YNkRteEE3TlN6VVBKUUtaQkxXdmNnS1ZmamhCZ2YvbHZN?= =?utf-8?B?UWRWaU1ReUJvYWU5NnpQSWVmaitjVU1JYlZIYjJ4SDV1T3V2TTRMc2pyczBL?= =?utf-8?B?QU95UFI0L2E3ZnlBOXhGRFBjUCtpc0I5dThsZzRWMUZEblA2OVQ2NlByTnc5?= =?utf-8?B?N2ttU3JKdlVMRmhUQlFaZzVMRlJqN3V6bmN6cXZYdzg3aTlROTgvZlROQjFS?= =?utf-8?B?aWRaYlIwWmdWVEtkQnlvamM1NlpYMDBCUG5mZkZSNjJQdS9meEVSM2VLWjRP?= =?utf-8?B?eVVqS1VDVWlTcnlsOFFqejdLb1VBL05oekwvK09NTUFORlNJc3hMc2dwMjZV?= =?utf-8?B?R3ovRzV6SmFYZjdBRFpUS0hXY2ZZS1pYbC9zdCtrV0tudnNPZ2d5MEw0MFY4?= =?utf-8?B?a1FTZExkNG1Td2J1ZmdUZEpkdWc5VzRCUFFiRkp0L3NvY0krS0Y1RVdpOUhZ?= =?utf-8?B?c0hIOFZya1NRYkp1VzdOSis5ZTJKdWllbXZrQU5mREE2Ullvc3p5V25IN1RB?= =?utf-8?B?Zk5GVzQ1OXZnSlp6VDMyck5tckpObjNjVHlScTZiV29EMGhnaURRd0liUmEy?= =?utf-8?B?TitjRUJRbFBtZmgwZGtESVlibXpVRGJHYUF1QVM5bEhnS0JlbFFhWUtSekFD?= =?utf-8?B?aHdqVkY3Q01IdUVvRFhTUlRnZWUrbnM4NElaMm9Ecmc4U1ducEZSV2NuT2ZY?= =?utf-8?B?KzhhTHZpMVFFd1RQWFZPdStoY2FMaFNWc2xpMHpDSUZvbjdvUWRvWXVKT09P?= =?utf-8?B?YnFxakk0NU9IMi9sS0VMVGZQVnFRdnpZNmlzM0VwT0lHZGoxMjl3YzNCM3V4?= =?utf-8?Q?dNLm8q/Kw/kCcpH1izTGFkQuk99L89HO?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2024 05:43:21.2107 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4bfe8ce1-6aef-43e0-8368-08dd14efba6b 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000FCC2.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8783 From: Roger Pau Monne When running as a PVH dom0 the ACPI MADT is crafted by Xen in order to report the correct numbers of vCPUs that dom0 has, so the host MADT is not provided to dom0. This creates issues when parsing the power and performance related data from ACPI dynamic tables, as the ACPI Processor UIDs found on the dynamic code are likely to not match the ones crafted by Xen in the dom0 MADT. Xen would rely on Linux having filled at least the power and performance related data of the vCPUs on the system, and would clone that information in order to setup the remaining pCPUs on the system if dom0 vCPUs < pCPUs. However when running as PVH dom0 it's likely that none of dom0 CPUs will have the power and performance data filled, and hence the Xen ACPI Processor driver needs to fetch that information by itself. In order to do so correctly, introduce a new helper to fetch the _CST data without taking into account the system capabilities from the CPUID output, as the capabilities reported to dom0 in CPUID might be different from the ones on the host. Note that the newly introduced code will only fetch the _CST, _PSS, _PPC and _PCT from a single CPU, and clone that information for all the other Processors. This won't work on an heterogeneous system with Processors having different power and performance related data between them. Signed-off-by: Roger Pau Monné Signed-off-by: Jason Andryuk --- drivers/xen/pcpu.c | 3 +- drivers/xen/xen-acpi-processor.c | 232 ++++++++++++++++++++++++++++--- include/xen/xen.h | 2 +- 3 files changed, 216 insertions(+), 21 deletions(-) diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c index c63f317e3df3..dc9f2c14bf62 100644 --- a/drivers/xen/pcpu.c +++ b/drivers/xen/pcpu.c @@ -388,7 +388,7 @@ static int __init xen_pcpu_init(void) arch_initcall(xen_pcpu_init); #ifdef CONFIG_ACPI -bool __init xen_processor_present(uint32_t acpi_id) +bool xen_processor_present(uint32_t acpi_id) { const struct pcpu *pcpu; bool online = false; @@ -403,6 +403,7 @@ bool __init xen_processor_present(uint32_t acpi_id) return online; } +EXPORT_SYMBOL_GPL(xen_processor_present); void xen_sanitize_proc_cap_bits(uint32_t *cap) { diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c index 296703939846..e9f38f171240 100644 --- a/drivers/xen/xen-acpi-processor.c +++ b/drivers/xen/xen-acpi-processor.c @@ -48,6 +48,8 @@ static unsigned long *acpi_id_cst_present; /* Which ACPI P-State dependencies for a enumerated processor */ static struct acpi_psd_package *acpi_psd; +static bool pr_initialized; + static int push_cxx_to_hypervisor(struct acpi_processor *_pr) { struct xen_platform_op op = { @@ -172,8 +174,13 @@ static int xen_copy_psd_data(struct acpi_processor *_pr, /* 'acpi_processor_preregister_performance' does not parse if the * num_processors <= 1, but Xen still requires it. Do it manually here. + * + * Also init the field if not set, as that's possible if the physical + * CPUs on the system doesn't match the data provided in the MADT when + * running as a PVH dom0. */ - if (pdomain->num_processors <= 1) { + if (pdomain->num_processors <= 1 || + dst->shared_type == CPUFREQ_SHARED_TYPE_NONE) { if (pdomain->coord_type == DOMAIN_COORD_TYPE_SW_ALL) dst->shared_type = CPUFREQ_SHARED_TYPE_ALL; else if (pdomain->coord_type == DOMAIN_COORD_TYPE_HW_ALL) @@ -313,6 +320,155 @@ static unsigned int __init get_max_acpi_id(void) pr_debug("Max ACPI ID: %u\n", max_acpi_id); return max_acpi_id; } + +/* + * Custom version of the native acpi_processor_evaluate_cst() function, to + * avoid some sanity checks done based on the CPUID data. When running as a + * Xen domain the CPUID data provided to dom0 is not the native one, so C + * states cannot be sanity checked. Leave it to the hypervisor which is also + * the entity running the driver. + */ +static int xen_acpi_processor_evaluate_cst(acpi_handle handle, + struct acpi_processor_power *info) +{ + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL }; + union acpi_object *cst; + acpi_status status; + u64 count; + int last_index = 0; + int i, ret = 0; + + status = acpi_evaluate_object(handle, "_CST", NULL, &buffer); + if (ACPI_FAILURE(status)) { + acpi_handle_debug(handle, "No _CST\n"); + return -ENODEV; + } + + cst = buffer.pointer; + + /* There must be at least 2 elements. */ + if (!cst || cst->type != ACPI_TYPE_PACKAGE || cst->package.count < 2) { + acpi_handle_warn(handle, "Invalid _CST output\n"); + ret = -EFAULT; + goto end; + } + + count = cst->package.elements[0].integer.value; + + /* Validate the number of C-states. */ + if (count < 1 || count != cst->package.count - 1) { + acpi_handle_warn(handle, "Inconsistent _CST data\n"); + ret = -EFAULT; + goto end; + } + + for (i = 1; i <= count; i++) { + union acpi_object *element; + union acpi_object *obj; + struct acpi_power_register *reg; + struct acpi_processor_cx cx; + + /* + * If there is not enough space for all C-states, skip the + * excess ones and log a warning. + */ + if (last_index >= ACPI_PROCESSOR_MAX_POWER - 1) { + acpi_handle_warn(handle, "No room for more idle states (limit: %d)\n", + ACPI_PROCESSOR_MAX_POWER - 1); + break; + } + + memset(&cx, 0, sizeof(cx)); + + element = &cst->package.elements[i]; + if (element->type != ACPI_TYPE_PACKAGE) { + acpi_handle_info(handle, "_CST C%d type(%x) is not package, skip...\n", + i, element->type); + continue; + } + + if (element->package.count != 4) { + acpi_handle_info(handle, "_CST C%d package count(%d) is not 4, skip...\n", + i, element->package.count); + continue; + } + + obj = &element->package.elements[0]; + + if (obj->type != ACPI_TYPE_BUFFER) { + acpi_handle_info(handle, "_CST C%d package element[0] type(%x) is not buffer, skip...\n", + i, obj->type); + continue; + } + + reg = (struct acpi_power_register *)obj->buffer.pointer; + + obj = &element->package.elements[1]; + if (obj->type != ACPI_TYPE_INTEGER) { + acpi_handle_info(handle, "_CST C[%d] package element[1] type(%x) is not integer, skip...\n", + i, obj->type); + continue; + } + + cx.type = obj->integer.value; + /* + * There are known cases in which the _CST output does not + * contain C1, so if the type of the first state found is not + * C1, leave an empty slot for C1 to be filled in later. + */ + if (i == 1 && cx.type != ACPI_STATE_C1) + last_index = 1; + + cx.address = reg->address; + cx.index = last_index + 1; + + switch (reg->space_id) { + case ACPI_ADR_SPACE_FIXED_HARDWARE: + cx.entry_method = ACPI_CSTATE_FFH; + break; + + case ACPI_ADR_SPACE_SYSTEM_IO: + cx.entry_method = ACPI_CSTATE_SYSTEMIO; + break; + + default: + acpi_handle_info(handle, "_CST C%d space_id(%x) neither FIXED_HARDWARE nor SYSTEM_IO, skip...\n", + i, reg->space_id); + continue; + } + + if (cx.type == ACPI_STATE_C1) + cx.valid = 1; + + obj = &element->package.elements[2]; + if (obj->type != ACPI_TYPE_INTEGER) { + acpi_handle_info(handle, "_CST C%d package element[2] type(%x) not integer, skip...\n", + i, obj->type); + continue; + } + + cx.latency = obj->integer.value; + + obj = &element->package.elements[3]; + if (obj->type != ACPI_TYPE_INTEGER) { + acpi_handle_info(handle, "_CST C%d package element[3] type(%x) not integer, skip...\n", + i, obj->type); + continue; + } + + memcpy(&info->states[++last_index], &cx, sizeof(cx)); + } + + acpi_handle_info(handle, "Found %d idle states\n", last_index); + + info->count = last_index; + +end: + kfree(buffer.pointer); + + return ret; +} + /* * The read_acpi_id and check_acpi_ids are there to support the Xen * oddity of virtual CPUs != physical CPUs in the initial domain. @@ -331,6 +487,7 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) unsigned long long tmp; union acpi_object object = { 0 }; struct acpi_buffer buffer = { sizeof(union acpi_object), &object }; + struct acpi_buffer cst_buf = { ACPI_ALLOCATE_BUFFER, NULL }; acpi_io_address pblk = 0; status = acpi_get_type(handle, &acpi_type); @@ -354,24 +511,45 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) default: return AE_OK; } - if (invalid_phys_cpuid(acpi_get_phys_id(handle, - acpi_type == ACPI_TYPE_DEVICE, - acpi_id))) { + + if (!xen_processor_present(acpi_id)) { pr_debug("CPU with ACPI ID %u is unavailable\n", acpi_id); return AE_OK; } - /* There are more ACPI Processor objects than in x2APIC or MADT. - * This can happen with incorrect ACPI SSDT declerations. */ - if (acpi_id >= nr_acpi_bits) { - pr_debug("max acpi id %u, trying to set %u\n", - nr_acpi_bits - 1, acpi_id); - return AE_OK; - } + /* OK, There is a ACPI Processor object */ __set_bit(acpi_id, acpi_id_present); pr_debug("ACPI CPU%u w/ PBLK:0x%lx\n", acpi_id, (unsigned long)pblk); + if (!pr_initialized) { + struct acpi_processor *pr = context; + int rc, rc2; + + /* + * There's no CPU on the system that has any performance or + * power related data, initialize all the required fields by + * fetching that info here. + * + * Note such information is only fetched once, and then reused + * for all pCPUs. This won't work on heterogeneous systems + * with different Cx anb/or Px states between CPUs. + */ + + pr->handle = handle; + + rc = acpi_processor_get_performance_info(pr); + if (rc) + pr_err("ACPI CPU%u failed to get performance data\n", + acpi_id); + rc2 = xen_acpi_processor_evaluate_cst(handle, &pr->power); + if (rc2) + pr_err("ACPI CPU%u failed to get _CST data\n", acpi_id); + + if (!rc && !rc2) + pr_initialized = true; + } + /* It has P-state dependencies */ if (!acpi_processor_get_psd(handle, &acpi_psd[acpi_id])) { pr_debug("ACPI CPU%u w/ PST:coord_type = %llu domain = %llu\n", @@ -379,11 +557,13 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) acpi_psd[acpi_id].domain); } - status = acpi_evaluate_object(handle, "_CST", NULL, &buffer); + status = acpi_evaluate_object(handle, "_CST", NULL, &cst_buf); if (ACPI_FAILURE(status)) { if (!pblk) return AE_OK; } + kfree(cst_buf.pointer); + /* .. and it has a C-state */ __set_bit(acpi_id, acpi_id_cst_present); @@ -391,10 +571,6 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) } static int check_acpi_ids(struct acpi_processor *pr_backup) { - - if (!pr_backup) - return -ENODEV; - if (acpi_id_present && acpi_id_cst_present) /* OK, done this once .. skip to uploading */ goto upload; @@ -422,8 +598,8 @@ static int check_acpi_ids(struct acpi_processor *pr_backup) acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT, ACPI_UINT32_MAX, - read_acpi_id, NULL, NULL, NULL); - acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID, read_acpi_id, NULL, NULL); + read_acpi_id, NULL, pr_backup, NULL); + acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID, read_acpi_id, pr_backup, NULL); upload: if (!bitmap_equal(acpi_id_present, acpi_ids_done, nr_acpi_bits)) { @@ -464,6 +640,7 @@ static int xen_upload_processor_pm_data(void) struct acpi_processor *pr_backup = NULL; int i; int rc = 0; + bool free_perf = false; pr_info("Uploading Xen processor PM info\n"); @@ -473,12 +650,29 @@ static int xen_upload_processor_pm_data(void) if (!_pr) continue; - if (!pr_backup) + if (!pr_backup) { pr_backup = kmemdup(_pr, sizeof(*_pr), GFP_KERNEL); + pr_initialized = true; + } (void)upload_pm_data(_pr); } + if (!pr_backup) { + pr_backup = kzalloc(sizeof(struct acpi_processor), GFP_KERNEL); + if (!pr_backup) + return -ENOMEM; + pr_backup->performance = kzalloc(sizeof(struct acpi_processor_performance), + GFP_KERNEL); + if (!pr_backup->performance) { + kfree(pr_backup); + return -ENOMEM; + } + free_perf = true; + } + rc = check_acpi_ids(pr_backup); + if (free_perf) + kfree(pr_backup->performance); kfree(pr_backup); return rc; diff --git a/include/xen/xen.h b/include/xen/xen.h index a1e5b3f18d69..6ff3e2f40803 100644 --- a/include/xen/xen.h +++ b/include/xen/xen.h @@ -81,7 +81,7 @@ static inline void xen_free_unpopulated_pages(unsigned int nr_pages, #endif #if defined(CONFIG_XEN_DOM0) && defined(CONFIG_ACPI) && defined(CONFIG_X86) -bool __init xen_processor_present(uint32_t acpi_id); +bool xen_processor_present(uint32_t acpi_id); #else #include static inline bool xen_processor_present(uint32_t acpi_id) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Dec 05 05:43:33 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 05:43:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848856.1263634 (Exim 4.92) (envelope-from ) id 1tJ4e7-000206-77; Thu, 05 Dec 2024 05:43:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848856.1263634; Thu, 05 Dec 2024 05:43: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 1tJ4e7-0001zz-2s; Thu, 05 Dec 2024 05:43:27 +0000 Received: by outflank-mailman (input) for mailman id 848856; Thu, 05 Dec 2024 05:43: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 1tJ4e6-0001z8-HX for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 05:43:26 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on20619.outbound.protection.outlook.com [2a01:111:f403:200a::619]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d776746d-b2cb-11ef-a0d5-8be0dac302b0; Thu, 05 Dec 2024 06:43:25 +0100 (CET) Received: from CYZPR20CA0009.namprd20.prod.outlook.com (2603:10b6:930:a2::20) by PH7PR12MB9128.namprd12.prod.outlook.com (2603:10b6:510:2f7::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.19; Thu, 5 Dec 2024 05:43:18 +0000 Received: from CY4PEPF0000FCC4.namprd03.prod.outlook.com (2603:10b6:930:a2:cafe::fe) by CYZPR20CA0009.outlook.office365.com (2603:10b6:930:a2::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.10 via Frontend Transport; Thu, 5 Dec 2024 05:43:18 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CY4PEPF0000FCC4.mail.protection.outlook.com (10.167.242.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Thu, 5 Dec 2024 05:43:18 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Wed, 4 Dec 2024 23:43:15 -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: d776746d-b2cb-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=BV+VRHVXPtcui9yie5MgDp7fdnTwjlf9+arzMsN3Yu848zLqGHXLQieaqhLT9SoZScSN+HjLHZQAiA0Fr/J9TbyffUKZ024+wU0fDs9Tx92RKAVt0ysZ+3lO2XcWQWL2GLglqdAToMM2BjUSfeDZjtpcDqvEc4wMJyIHhVCBBvvKzekLQPH/+21Vzi+Nwge3msIabTBmSPkSIgBGU4j7lHD4N80x0jH+UjDRyUrdyfUAFeCG+dntXPz0zAPFXVfSKhOw62Oo3d6DUEKq76HC50mkHnQGBtReB18XFJyEhD4s1QcK4nnPSYCzkMw09FfzCKk5IbEzLg5Wxd0xplCuyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zJv3VOfPiqxlGpmdzLE83at11S7zrrzGSH5aVPpRpZo=; b=SpETUT0lHVhDULEaWxZDyz2o48sz4zLTGqbMEKe1DhjPymCjPrVn8SOr21MsJh45+c2iS4FC1+R8+9amT+q/xyblBd4kYFDNEmG0pbZf1GqkPHEG8SbcHV1lrE9LzKuD3yDgqj+J/67asDzxN2/A8Lbx7XUJ/876J1ubv65eTo2Ey8AvuT760UiRiNfOk1w4srdYwEPnl8W07k3uJNAy7cIz/qVoqnpqY5nUmRPdOcan3pPTD2kcmg5QoaEkPqm73Hix6lvStABrKohV47gPzJbiSvPcaN07mZw5mlp7FzkYeNO7meIA9nYsutqfLJzYAru5RI7ZTGDXhlSZrKU7Fg== 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=zJv3VOfPiqxlGpmdzLE83at11S7zrrzGSH5aVPpRpZo=; b=puNwNLE4uDItAr5X/2lH5ZpVVO1hCvOHRcnKeH9A03CdYmosiL9jyyHtpb/diWIbrehszEjVtXVJiF25LGItKiXC4cxaIlh4OGNzZTjkpPaIgu2UbkXlJoYU9mZmnwbYa7b2Pahp4Jb2Q4bRmOBGpwVhW1FdoLt82GyezfzVsoA= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko CC: Ray Huang , Xenia Ragiadakou , Jason Andryuk , "Penny Zheng" , , Subject: [PATCH v2 0/4] xen/acpi: introduce cppc performance hypercall Date: Thu, 5 Dec 2024 13:42:48 +0800 Message-ID: <20241205054252.471761-1-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000FCC4:EE_|PH7PR12MB9128:EE_ X-MS-Office365-Filtering-Correlation-Id: 60210363-8d12-4846-727b-08dd14efb8a6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|376014|1800799024|82310400026; X-Microsoft-Antispam-Message-Info: =?utf-8?B?ZjNlZ2hGUHVxaVJCK3VSN05pK1RZUExuWGZDQWo2cG41aThWRGs2MWQ4bm5O?= =?utf-8?B?SDRxZEpXbm81RjF3UEEwWHk2aytaQklKaDZZaDJkRUs2MnRLdFZlZjNOWjRL?= =?utf-8?B?aXNyUUR3NGpMa1UyaExpWm9LS01QVVhhNzVwb29GbGt0ZkdTRm4wZG1LUWZK?= =?utf-8?B?c29udjVwZzlGTGdDS0YzTlhHOEdvcDNTa3F3Y21tdmlGbU9IcTNhVFlBdjd3?= =?utf-8?B?Vk1qOU05MlhFQks2Kzg3dTdCUG5tajlrNG50TlVLdVB1c05sdGVSc2wwd2lp?= =?utf-8?B?NXJMSWV2OWFHSmpqWnRxMkI3ZVlBendSOHRDL1g2NUlsRitWTGNSeE1ZZ0FG?= =?utf-8?B?akNpMUhuSHpKY3E5L3dKRS94dEZkeU5BNXhUcDhkak92MGRhVUZZOXl0M2xw?= =?utf-8?B?bHRCWkJZcElDcVV5RjFHQzZjcEloelpYdWsxMk9hMjRibmxwSjNZVGZOYUlD?= =?utf-8?B?LzIveFBaZXplbHpmOHo3dlBpZGdVSTlvVXMrSkdLUEZJTVh1ekY3NVVHakNJ?= =?utf-8?B?NWYwc2lPK0E2eHRwckpmRjhrdUw4eFU4cUN2NDhoeTVGdWlRakJZbDYwejAx?= =?utf-8?B?a0RNSElGSlpWMGgzZWpWaXgyU3dabHU4VnFNbWYxYzRYemRwWjRxbnVsdmFI?= =?utf-8?B?b3FjRldpRXpDakRIUG14cjdRN1lGTjZoL0ZLNjk0Q0tMVkhUalZNdEcrcjR1?= =?utf-8?B?WExXM05WVVFaWGxvTi9oSkd3aGRHOGNJQkRlRkdRWnVKR0tFQjhoa2NpMW4r?= =?utf-8?B?SHdwRml4ZnM3WVQrVEU2NmRiQWZuK2dTOXFMYkZuRStUcGk3UWJwcFNxVXNB?= =?utf-8?B?K09EMzRPSElYMGR0a1JBbnI0RTNQeHFjZjhhaG5JN2lSMjExbDJXOFl1bEpT?= =?utf-8?B?VVJudWljc1BZL3BvRnFPK3RoclF4TmY1RjNCWlN1U2Q5VXB6amJBTWpxOVdI?= =?utf-8?B?UkVEVWNIY3FIclJxVng1RkJuV2lJZFBSYnl0NWJ2WjlBcnNXdnpqMWNjNnAy?= =?utf-8?B?OTZQdmh3UDJibWFHaldPN0o1aFdNNkIwbkRkTFpvNDg3UXh3SVlCb3lYNTlm?= =?utf-8?B?R0pFb1Rta3l0R0Z2ZFlqQjUvQXh0ckNUVlpFb1RGOVRCdmE1SElXei9rWDZz?= =?utf-8?B?YU85bGFNTnVrL3dIQlg2VWlyR3FKcVVQZ1k1dk8vaXNITDFaZW9UWFdhVG9X?= =?utf-8?B?Qm5MTHFITFJQejlGS3JzRU9aLzQxOEY2a2VoMzB4cXprblA5UVkxQlE4Vyto?= =?utf-8?B?c1VxMWpZdGZESFpQWG5pRlNZWVpYN2VpdXBVZHlvZTc5djYyY1BlVXNmKzZo?= =?utf-8?B?TGZRcXhQUWFkQU5qcVFhK0RoTmxDRWVQTFlhazJIYnpDVlNLZzJzRUdUSlhw?= =?utf-8?B?ejR6NWNNc3lsSXh2UHhDNFZKYnpqd2JqY25FNHFEVVJlOEMxRkxFU1VwUjA3?= =?utf-8?B?UTBtZ3pQOU8zSVBUd2paYWxXL0JtczdId3lSY0RYUm1hVnpXRFB5YnQwVW9K?= =?utf-8?B?dDhKMjVyZEhKYkt3UE1nclVzbmtLY2lJL25keS9vc3R6TkZjMDNJL2o4WTF4?= =?utf-8?B?VHlFZ2U3cFF4bjZvdk1NSDdneThHajViUGFRS3JNVi9LSVVsRUtBWUxjeklG?= =?utf-8?B?aEdxSWtmTHBHMFVvNXJNZkNSOGo3S1NkcDdYcndiYmFuUnBkZlNUVUxyUVVr?= =?utf-8?B?TnkxR255TCtUNFUzcHZObUovM1RHTVpNcEkrajhieG04N3VuVHpSbWI4QjZS?= =?utf-8?B?VUlYdEsxUHVuai8wQi9YbVpEUnowaE13bzZBSnk2cllSSkZSZWRmUDc5UHRN?= =?utf-8?B?WHJOaktqenBFdWNsSHNDZDRKMkZFNkNrTEE1QTRKdmNFNmNkZzExdGNQajVr?= =?utf-8?B?ZnQvWElsWERMdUtkZWJlREk1TnZ5RDJ3TXNoNFZrNVpZN0pwMVNwRnF5WEFN?= =?utf-8?B?aEN5Rm5LSlRMaDNLVlZ4ak9Wb3h5UkpxQUlWRXFvRWREdkMwL2dScTg4bGpi?= =?utf-8?B?UFgxMnk3UVVRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2024 05:43:18.2571 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 60210363-8d12-4846-727b-08dd14efb8a6 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000FCC4.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB9128 When running as Xen dom0 PVH guest, MADT table is customized and may have the "wrong" UID processor number, which is inconsistent with the UID in Processor entry in native DSDT. As a result, during ACPI boot-up for dom0, linux fails to set up proper processor logical id <-> physical id map(acpi_map_cpuid). Furthermore, It leads to that some ACPI processor feature capibility, like per-cpu cpc_desc structure, failed to be correctly stored and processed. With upstreaming "amd-pstate CPU Performance Scaling Driver"( https://lore.kernel.org/all/20241203081111.463400-1-Penny.Zheng@amd.com/) to Xen community, amd-pstate driver is supported on Xen platform. And as Xen is uncapable of parsing the ACPI dynamic table, like _CPC entry, this patch serie introduces a new sub-hypercall XEN_PM_CPPC to deliver CPPC performance capability data. This patch serie is based on commit "xen/acpi: upload power and performance related data from a PVH dom0"( https://patchwork.kernel.org/project/xen-devel/patch/20241203225338.1336-1-jason.andryuk@amd.com/), which is still under review. v2 -> v1 : - rebase to the latest v3 version of "xen/acpi: upload power and performance related data from a PVH dom0" Penny Zheng (3): acpi/cppc: extract _cpc entry parsing logic xen/cppc: get xen-required cppc perf caps data xen/cppc: introduce cppc data upload sub-hypercall Roger Pau Monne (1): xen/acpi: upload power and performance related data from a PVH dom0 drivers/acpi/cppc_acpi.c | 204 +++++++++++++++----- drivers/xen/pcpu.c | 3 +- drivers/xen/xen-acpi-processor.c | 321 +++++++++++++++++++++++++++++-- include/acpi/cppc_acpi.h | 5 + include/acpi/processor.h | 2 + include/xen/interface/platform.h | 11 ++ include/xen/xen.h | 2 +- 7 files changed, 475 insertions(+), 73 deletions(-) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Dec 05 05:43:33 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 05:43:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848858.1263653 (Exim 4.92) (envelope-from ) id 1tJ4eB-0002Uf-OF; Thu, 05 Dec 2024 05:43:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848858.1263653; Thu, 05 Dec 2024 05:43: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 1tJ4eB-0002UR-LK; Thu, 05 Dec 2024 05:43:31 +0000 Received: by outflank-mailman (input) for mailman id 848858; Thu, 05 Dec 2024 05:43: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 1tJ4eA-0001z8-Db for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 05:43:30 +0000 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on20604.outbound.protection.outlook.com [2a01:111:f403:2418::604]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id da8d5936-b2cb-11ef-a0d5-8be0dac302b0; Thu, 05 Dec 2024 06:43:29 +0100 (CET) Received: from DM6PR12CA0029.namprd12.prod.outlook.com (2603:10b6:5:1c0::42) by DM3PR12MB9392.namprd12.prod.outlook.com (2603:10b6:0:44::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.11; Thu, 5 Dec 2024 05:43:24 +0000 Received: from CY4PEPF0000FCC0.namprd03.prod.outlook.com (2603:10b6:5:1c0:cafe::52) by DM6PR12CA0029.outlook.office365.com (2603:10b6:5:1c0::42) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.9 via Frontend Transport; Thu, 5 Dec 2024 05:43:24 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CY4PEPF0000FCC0.mail.protection.outlook.com (10.167.242.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Thu, 5 Dec 2024 05:43:23 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Wed, 4 Dec 2024 23:43:20 -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: da8d5936-b2cb-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DD+ra+IFQGzH37GSSyAkDexD9EKCYoUst8aA73R00lx9ccwDC77aina1yYkqKaOeGI6Fp7SI/yVKxIrkpumG59eF/RQhlG7KaI1yPl2JgoLbRYutRYK5p2orXZbgF0awMvyHFcHMVPwWVXXWCxX4stCCV9pjfurQx4JkbYFv22W1TWYDGgWAZx2SxteVWGuPpfRSxkLovqvJ4QaUC7zS4Sp2WDqGBfsSK9Uvim0e+p402HDE7W+9aKQMY0qhnIbzyanuh+lkTDit2h2P/k1x8TfFdcAe9PwFGoKfexKvsHwZENjjT76tVNPqRcLTJq2NEpKcQh0GZRKj/5ivSl4UPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GsDTXx9VhQgMbr8Jxkh1RlqXObfZJnJqSYjRU1bKv7Q=; b=lK1paWeIxVEpdwe0oxSewu5sOfn4bb+nurvE1opka0szu7Y5CNuaZt8AxF+JkOnV9tIfiL3qqV4yCAvUKrYvMyPMkGWtCttsy36DVIU4cmAvHM4JgQ3LPdQjhx8HKhtl5KfY8vpMPLvHKedtbqR4und0poMkzYG9ajO3l7U8Q/dIzLie+Xje3KchAfMFDxm1pU0SdZM79ayCyLE4C28EpcuqUih8EclK+bE2FFP1MNCUmq7Q6zn2FzbymjMoUtqSb5hU3bMZXr3VWi+b0thi/8dkmbzwgUcB5+yrWw6xrkaYOt7zf8pQAVvS+IRQySU7d8OulLe+a3zaGE3Debvv0w== 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=GsDTXx9VhQgMbr8Jxkh1RlqXObfZJnJqSYjRU1bKv7Q=; b=DhgqZlkxnyvjmPrP40F35R3OYpBA8zkZ11e3j8kK8Ao5zMy+kshfd//LD6QepqV5SwruGl4MHXqZp2Q+EHAlXVKDS6bjbSRwR1kB9XMCWDrVtDZ+om4+DyHQhOMnXrWt6x7eLlza/PVkkJaLfxERVQdKIBAnu5r4hYLUQlsRkVM= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko CC: Ray Huang , Xenia Ragiadakou , Jason Andryuk , "Penny Zheng" , , Subject: [PATCH v2 2/4] acpi/cppc: extract _cpc entry parsing logic Date: Thu, 5 Dec 2024 13:42:50 +0800 Message-ID: <20241205054252.471761-3-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241205054252.471761-1-Penny.Zheng@amd.com> References: <20241205054252.471761-1-Penny.Zheng@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000FCC0:EE_|DM3PR12MB9392:EE_ X-MS-Office365-Filtering-Correlation-Id: 06c4401c-9187-43bd-f46c-08dd14efbbed X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?9APmW5t2gIPePvIuvB3zLgJsIg3fd0GPpk4OQeLwt3XqaaJoGUoCq9bswOyN?= =?us-ascii?Q?vj8MkJoUlKuL/5Dm397fhI0z9gMnfYz8QBNYsYA5vnNqHs4MS/iqf+BCQ/GR?= =?us-ascii?Q?bnNkilwRPvm3KW6/iOqJK+q/XKntlWcQBSX1l5fbAmpc8JqDO1yZmI3aHRUf?= =?us-ascii?Q?ritxH54ClqT+Oor7viCbHz3uOKrfigMxXmrbsTQMq5BX21KsvZJr45+YhiwX?= =?us-ascii?Q?0vg3LkaG+1WUnf5fgnAQkO0diRl5s+b59Ic/e6ASFgK7gm3JxmHnfgkpmRuA?= =?us-ascii?Q?onbb3bScy7TeOk4eBc45+3A775LPz7yIKKbCYGPYhzuawfj/yPcz7qpl8O1g?= =?us-ascii?Q?D5E1zgLr8+0LWx6+gQ+cDhZFj/C90W9Fsd0fRFFiD5o1vHgegG0Y/o7cXEmK?= =?us-ascii?Q?VzD4gGqSjmeYvZUM1eHCkMbaJlA6ZIx5Hjl/343qcGQ8nH5ITSouz56K/n/T?= =?us-ascii?Q?T7Ds5RGloPmTTYQRm3U+pFoCRrOWp/3vEVQjDJ62dOZZH2XHLAxiRclWMsYU?= =?us-ascii?Q?CS4SzGtd98hwwSsWjKXMbzdjaeyUbvSG0TPtctaNCSQdCCuqFPdIBuXNX1+P?= =?us-ascii?Q?HewHscInNkBtjG81aWX2COOOFuVCQZ1ZgXNhN27Wcc9O6HI+1nwvgJwNeoZN?= =?us-ascii?Q?DzSRJ6IzCeD2/h6D4rW4kHb6Nr+kT7NhXjZhcLOUJoaStZWcGd1hwUoV6Xdd?= =?us-ascii?Q?wL8B2XkSdPxMmYTaDLuOwaCOaRPiokjRm0fzjR5un2zqMheucm0DJ0zxJCgf?= =?us-ascii?Q?VG5aiMKQw9wuUHerD1vVEcWFX08bqYjEFvfh8s+u5NRi1NOavx8FE2hzFGKC?= =?us-ascii?Q?kGp3Rjy7WC29Bd0QlcwILonn5EHfogvNuByBl7vNjEwErErQLmV4GX3JSTtI?= =?us-ascii?Q?mA3FXzvjaeSx5nAxYKCzWQTjxmU2vFFgS28ad/CD2vjyxjhG+o35QFfQw/e9?= =?us-ascii?Q?Q7eVIgrvwqtx/lR8VWjzNcf9fYQTOldouxOpL4Y15aXqLYff27axsRc9Hwfg?= =?us-ascii?Q?YWXW/NxvF27dxiTf7JTUAMG+mq3sxe1/hcZjjNvO84Qal7dzHmNDv5m15Upu?= =?us-ascii?Q?rsfPJ8BYL3cdpiOy1hSWgQCLbAtFrqeQbRlPTAv5EGmDo2RXpjKZDfPRlBiq?= =?us-ascii?Q?ZBRnFhB5+DNXbBi5QILXTrtEON/T1QSWtUaaZHVuZkoKeBsgXoNerAg289Qc?= =?us-ascii?Q?P87VE90mA1Sb/U2Rq4qF+2ig+j2XnqgsJ7g99myhMxd04MdeprSQ4t+kQKLO?= =?us-ascii?Q?dpjjebPZRjLdswNT+SNqlpW6JVpvZGFabjB/gJ4+ys46F6KgB9kVc1X4Ng2P?= =?us-ascii?Q?5ci+fNZ8xa5Pq9QqOL9oBkwVzWN2S+haprikh+DnnEYvI12yAjbsKo0sZwWq?= =?us-ascii?Q?kAOPxMI+SPcWg8FQAQj+7sNk9QbgqLUsCRPKcMtqRzIX0E08H0W6rdYw8qLn?= =?us-ascii?Q?4A6DBgrf/pW1KzfmujHFmEzZedLCZ1Do?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2024 05:43:23.7432 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 06c4401c-9187-43bd-f46c-08dd14efbbed 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000FCC0.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR12MB9392 When running as Xen dom0 PVH guest, MADT table is customized and may have the "wrong" UID processor number, which is inconsistent with the UID in Processor entry in native DSDT. As a result, during ACPI boot-up for dom0, linux fails to set up proper processor logical id <-> physical id map(acpi_map_cpuid). Furthermore, It leads to that some ACPI processor feature data, like per-cpu cpc_desc structure, failed to be correctly stored. In order to re-parse _CPC entry later for delivering correct data in performance hypercall, firstly, we extract parsing logic from acpi_cppc_processor_probe() and export it as a new function acpi_cppc_processor_parse(). Also, replace logical processor id with ACPI ID, to show correct print info in Xen dom0 PVH guest. Signed-off-by: Penny Zheng --- drivers/acpi/cppc_acpi.c | 93 +++++++++++++++++++++++----------------- 1 file changed, 53 insertions(+), 40 deletions(-) diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index c3fc2c05d868..13d6ff84a1e9 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -675,19 +675,11 @@ static int pcc_data_alloc(int pcc_ss_id) static inline void arch_init_invariance_cppc(void) { } #endif -/** - * acpi_cppc_processor_probe - Search for per CPU _CPC objects. - * @pr: Ptr to acpi_processor containing this CPU's logical ID. - * - * Return: 0 for success or negative value for err. - */ -int acpi_cppc_processor_probe(struct acpi_processor *pr) +static int acpi_cppc_processor_parse(struct acpi_processor *pr, struct cpc_desc *cpc_ptr) { struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL}; union acpi_object *out_obj, *cpc_obj; - struct cpc_desc *cpc_ptr; struct cpc_reg *gas_t; - struct device *cpu_dev; acpi_handle handle = pr->handle; unsigned int num_ent, i, cpc_rev; int pcc_subspace_id = -1; @@ -706,31 +698,24 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) status = acpi_evaluate_object_typed(handle, "_CPC", NULL, &output, ACPI_TYPE_PACKAGE); if (ACPI_FAILURE(status)) { - ret = -ENODEV; - goto out_buf_free; + return -ENODEV; } out_obj = (union acpi_object *) output.pointer; - cpc_ptr = kzalloc(sizeof(struct cpc_desc), GFP_KERNEL); - if (!cpc_ptr) { - ret = -ENOMEM; - goto out_buf_free; - } - /* First entry is NumEntries. */ cpc_obj = &out_obj->package.elements[0]; if (cpc_obj->type == ACPI_TYPE_INTEGER) { num_ent = cpc_obj->integer.value; if (num_ent <= 1) { pr_debug("Unexpected _CPC NumEntries value (%d) for CPU:%d\n", - num_ent, pr->id); - goto out_free; + num_ent, pr->acpi_id); + goto out_pointer; } } else { pr_debug("Unexpected _CPC NumEntries entry type (%d) for CPU:%d\n", - cpc_obj->type, pr->id); - goto out_free; + cpc_obj->type, pr->acpi_id); + goto out_pointer; } /* Second entry should be revision. */ @@ -739,14 +724,14 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) cpc_rev = cpc_obj->integer.value; } else { pr_debug("Unexpected _CPC Revision entry type (%d) for CPU:%d\n", - cpc_obj->type, pr->id); - goto out_free; + cpc_obj->type, pr->acpi_id); + goto out_pointer; } if (cpc_rev < CPPC_V2_REV) { pr_debug("Unsupported _CPC Revision (%d) for CPU:%d\n", cpc_rev, - pr->id); - goto out_free; + pr->acpi_id); + goto out_pointer; } /* @@ -758,8 +743,8 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) (cpc_rev == CPPC_V3_REV && num_ent != CPPC_V3_NUM_ENT) || (cpc_rev > CPPC_V3_REV && num_ent <= CPPC_V3_NUM_ENT)) { pr_debug("Unexpected number of _CPC return package entries (%d) for CPU:%d\n", - num_ent, pr->id); - goto out_free; + num_ent, pr->acpi_id); + goto out_pointer; } if (cpc_rev > CPPC_V3_REV) { num_ent = CPPC_V3_NUM_ENT; @@ -793,7 +778,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) goto out_free; } else if (pcc_subspace_id != gas_t->access_width) { pr_debug("Mismatched PCC ids in _CPC for CPU:%d\n", - pr->id); + pr->acpi_id); goto out_free; } } else if (gas_t->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) { @@ -848,7 +833,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) memcpy(&cpc_ptr->cpc_regs[i-2].cpc_entry.reg, gas_t, sizeof(*gas_t)); } else { pr_debug("Invalid entry type (%d) in _CPC for CPU:%d\n", - i, pr->id); + i, pr->acpi_id); goto out_free; } } @@ -864,6 +849,45 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) cpc_ptr->cpc_regs[i].cpc_entry.int_value = 0; } + pr_debug("Parsed _CPC entry for CPU: %d\n", pr->acpi_id); + kfree(output.pointer); + return 0; + + out_free: + /* Free all the mapped sys mem areas for this CPU */ + for (i = 2; i < cpc_ptr->num_entries; i++) { + void __iomem *addr = cpc_ptr->cpc_regs[i-2].sys_mem_vaddr; + + if (addr) + iounmap(addr); + } + out_pointer: + kfree(output.pointer); + return ret; +} + +/** + * acpi_cppc_processor_probe - Search for per CPU _CPC objects. + * @pr: Ptr to acpi_processor containing this CPU's logical ID. + * + * Return: 0 for success or negative value for err. + */ +int acpi_cppc_processor_probe(struct acpi_processor *pr) +{ + acpi_handle handle = pr->handle; + struct cpc_desc *cpc_ptr; + struct device *cpu_dev; + int pcc_subspace_id = -1; + int ret = -ENODATA; + + cpc_ptr = kzalloc(sizeof(struct cpc_desc), GFP_KERNEL); + if (!cpc_ptr) + return -ENOMEM; + + ret = acpi_cppc_processor_parse(pr, cpc_ptr); + if (ret) + goto out_free; + pcc_subspace_id = per_cpu(cpu_pcc_subspace_idx, pr->id); /* Store CPU Logical ID */ cpc_ptr->cpu_id = pr->id; @@ -907,21 +931,10 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) arch_init_invariance_cppc(); - kfree(output.pointer); return 0; out_free: - /* Free all the mapped sys mem areas for this CPU */ - for (i = 2; i < cpc_ptr->num_entries; i++) { - void __iomem *addr = cpc_ptr->cpc_regs[i-2].sys_mem_vaddr; - - if (addr) - iounmap(addr); - } kfree(cpc_ptr); - -out_buf_free: - kfree(output.pointer); return ret; } EXPORT_SYMBOL_GPL(acpi_cppc_processor_probe); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Dec 05 05:43:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 05:43:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848860.1263663 (Exim 4.92) (envelope-from ) id 1tJ4eE-0002mh-Vf; Thu, 05 Dec 2024 05:43:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848860.1263663; Thu, 05 Dec 2024 05:43: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 1tJ4eE-0002mW-T2; Thu, 05 Dec 2024 05:43:34 +0000 Received: by outflank-mailman (input) for mailman id 848860; Thu, 05 Dec 2024 05:43: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 1tJ4eD-0001z8-IB for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 05:43:33 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2061e.outbound.protection.outlook.com [2a01:111:f403:2415::61e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id dc455609-b2cb-11ef-a0d5-8be0dac302b0; Thu, 05 Dec 2024 06:43:32 +0100 (CET) Received: from DS7P222CA0017.NAMP222.PROD.OUTLOOK.COM (2603:10b6:8:2e::26) by PH8PR12MB7181.namprd12.prod.outlook.com (2603:10b6:510:22a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.15; Thu, 5 Dec 2024 05:43:27 +0000 Received: from CY4PEPF0000FCC3.namprd03.prod.outlook.com (2603:10b6:8:2e:cafe::46) by DS7P222CA0017.outlook.office365.com (2603:10b6:8:2e::26) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.19 via Frontend Transport; Thu, 5 Dec 2024 05:43:26 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CY4PEPF0000FCC3.mail.protection.outlook.com (10.167.242.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Thu, 5 Dec 2024 05:43:26 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Wed, 4 Dec 2024 23:43: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: dc455609-b2cb-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=l2myruzZq6Lyh6/aNpzGbce9kl2lX3JhD2RiEihN+BAOD8lNlb29Hq2tRrUFWG3lEs30RVAntG+gAlS8zB9UdWczNlZmvxwADvcWibl0CmzBHt1sguY8y7xV3xX6WPbclXqjNWZlVVUfRODSRgA+pWpVfBgjumgBIDnceAeVGbU/TQzky2XVh042oLM9QU6l96oU+bkd6UlCa1B+cHgXes3G0IpWx9ndaQghprqZV/E74SvwM6vZOw0nr8waZgsaZKklfzy7YH72x2EJk97H4qUqFAZfHKZW74b6c9ev0TsARU+camC5WXdtCFWnFLoLWf0YFQO/iC+Ljv17/jtegg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iFOJrAd0KMsoZrN9Shjj1dooQzMESP1akwRRETW6xhI=; b=GMZhXYwPHmkAtCCLbxYdpUXgylFiQ+L7bGRHtGCAXvNXme6/LLJWwIqpaAMgvElOvUFMwcmGVzgjWTcTz+81stLbwI7XsXhUU+lC5cQ8QqH1r0DdfALOjN1Z45LsO6rB+GE4qtIpxsxbOKcuA94Ou99F7Q9p6Aug5V5mDMeCCjVpw9uRS11/FxHlKlVIC0rdBigqCVgBx/2Rv0a4d+fA6/V8hfqItpUBNVnsj2qLi/MzP9S9GGpR8XbghkPiApgnaOIgH6eV1ZR17sK3RsCXMj4yDcMgqIhsk5zb8g9vI/DA4FxJ57Yfku+8qMIj8ocHczHVtd1O1aYUB8UZ49EfCg== 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=iFOJrAd0KMsoZrN9Shjj1dooQzMESP1akwRRETW6xhI=; b=ens/F7esvTX9U4hlVjvFwAwKPCgacatzecxS8uSDfkrIoDq87HsSVLxonE1jtmji1hcP8EAe87VWJsZd3XTPsy+ph4PrMP5MjdLsM3y2BMf6N1sSKrkyzKwPxlw1ZckjJurNNqk37g+MiJxWDX56mwAJBPct93mJ+QlPBklxBT0= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko CC: Ray Huang , Xenia Ragiadakou , Jason Andryuk , "Penny Zheng" , , Subject: [PATCH v2 3/4] xen/cppc: get xen-required cppc perf caps data Date: Thu, 5 Dec 2024 13:42:51 +0800 Message-ID: <20241205054252.471761-4-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241205054252.471761-1-Penny.Zheng@amd.com> References: <20241205054252.471761-1-Penny.Zheng@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000FCC3:EE_|PH8PR12MB7181:EE_ X-MS-Office365-Filtering-Correlation-Id: 77293042-9397-4491-4cd8-08dd14efbd82 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?hA5gdBlM4rCRgjPyC3wKnk76+FoHivFpgWQppyuuYLoJDL9I06SyhMORBdWJ?= =?us-ascii?Q?/n5G63Qq+VTSOvan+vD+Sg4NCZ5qv3ebBVLgj9JDZAy7BaIbDDdfWn5D3XnK?= =?us-ascii?Q?NoIfSLRVk1g4/Ivv4N41PvrbkT2B66JukXfTqHIIWmy4INqojAskb8j5wpgG?= =?us-ascii?Q?IiCUXlKu+GGDs+Yr0Nee7RvB0XMR7/PqrFHWg1Czj/jqWR3NoLqrYhqWS6tL?= =?us-ascii?Q?mo/ytzB68MThvAijxqWPGRshb8LhdAivZwylFl6coUptfIF+d1m3lish7KOr?= =?us-ascii?Q?kFtbPS6wskZqple8Xh9GNtPjjq0aTXddeAUPg+ei2kZQiyXO9yGBA+1A8z6M?= =?us-ascii?Q?LYSG8evphqQuoTx5RaAKExZBE+lX4pr21amQ78s8IklltdTR6BEUhxLN78Ge?= =?us-ascii?Q?kVjKbBhwcl0RwMUVw1YbaQtIs7hCiV5Hki7YnAm+Q2D4tCCL/5zPLBiGP0Mt?= =?us-ascii?Q?rNpvv6IIXfGj5X3Jqnu1nFfYyEgpui1qj4EST311YSk8+wmNKSRD8kIOa8o0?= =?us-ascii?Q?yEcZRduNrKUhqCERUCwT5saRjq1eoy3Hmsy5l2ekt9ZDj6DHnK0k7KMT78nY?= =?us-ascii?Q?bPq31jzmWVtYTVjqK0UWUAvh9esurwr0lOtDdDNRbIChLsqBbhP1hJ4wqtwh?= =?us-ascii?Q?McKie1JHabCTgpNTwPuTD2SZjqRzrf97rEVVqFkYfWYuQQGexRaKYyGrETKy?= =?us-ascii?Q?NzO8vkje8UOWx/So4D0erW0acVhTdSgJzExvBrFZI44H18T1TmuJSPs67nG4?= =?us-ascii?Q?Q8gcZ99fiX/n7SvwNRfX3H1bdbKeDvklQFP/pVGm1BMdXQZ5DrTB/+3P+ulA?= =?us-ascii?Q?4X/axEOmz7R/e+95ZApwFkhl7ETTWrgTgcK54WJPb0oAJihoTvZ3BYQ4g9GA?= =?us-ascii?Q?1i+vuoMKr8TnhobFqSpv4u20ZUM+GUY6BhC/3pVG5mBeLjtU7Vvb35EDT+OC?= =?us-ascii?Q?fW+HYFv08NOKUbSM6nYDx1r72tlOJL4r2Q3unYizn7n5gAnqjPQN0zsd8L63?= =?us-ascii?Q?6tk/olrnookcM0acO22T1YJiVHt/i61BvHzaOLri84sE3mzfcleMATWSRDBH?= =?us-ascii?Q?APA0UQkLUlQwn59hyNEECN57cKE9d52sFZWCJTk3602EwhtLM5ctY9IcEHEY?= =?us-ascii?Q?iHdEUHgXdvPM/94GbPViJCscGrjBh7gn4QAHWv8ekMwhI/3tZva3Mo1KUNwa?= =?us-ascii?Q?q4O47P6lmmSoz7FcqkdFH/50sVMtCfTU8yFEt0/ChsCwA7484QMquFg1Nxlf?= =?us-ascii?Q?YUUFa8nnQWPxYGz/4jOf//f+Vzv33EFPcAwM+fyyqqZ2e3lRKKq45/GdYy+K?= =?us-ascii?Q?LV/47e6M0ff4b82nVYfF0yxp8Gjskv0I/r5e4Vq8HUkIWT7Uf0QDV7cuSNFY?= =?us-ascii?Q?nFWOqWttsjjkBNsD6sug6xc7FusVBRD/Ig2os0OyWQto1q9QvRtOuk2Ummvq?= =?us-ascii?Q?Qe4i0eXYcb1b8+EAlImZ4xvu62LkuMLa?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2024 05:43:26.3932 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 77293042-9397-4491-4cd8-08dd14efbd82 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000FCC3.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7181 When running as Xen dom0 PVH guest, processor logical id <-> physical id map could not be properly set up. So the original function cppc_get_perf_caps() fails to get correct cppc data for Xen ACPI processor. A new function xen_processor_get_perf_caps() is introduced to get xen-required cppc perf caps data. Also, as Xen couldn't read and process PCC-type register, this commit includes a new flag pcc_unsupported in struct acpi_processor_flags to tell whether platform supports PCC-type register. Signed-off-by: Penny Zheng --- drivers/acpi/cppc_acpi.c | 110 +++++++++++++++++++++++++++++++++++---- include/acpi/cppc_acpi.h | 5 ++ include/acpi/processor.h | 1 + 3 files changed, 105 insertions(+), 11 deletions(-) diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index 13d6ff84a1e9..3a436591da07 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -772,6 +772,15 @@ static int acpi_cppc_processor_parse(struct acpi_processor *pr, struct cpc_desc * so extract it only once. */ if (gas_t->space_id == ACPI_ADR_SPACE_PLATFORM_COMM) { + /* + * When ACPI processor represents Xen processor, PCC register type + * could not be properly read and processed right now, as logical + * processor doesn't always have 1:1 map relation to physical processor. + */ + if (pr->flags.pcc_unsupported) { + pr_debug("Unsupported PCC register type:%d\n", pr->acpi_id); + goto out_free; + } if (pcc_subspace_id < 0) { pcc_subspace_id = gas_t->access_width; if (pcc_data_alloc(pcc_subspace_id)) @@ -837,7 +846,9 @@ static int acpi_cppc_processor_parse(struct acpi_processor *pr, struct cpc_desc goto out_free; } } - per_cpu(cpu_pcc_subspace_idx, pr->id) = pcc_subspace_id; + + if (!pr->flags.pcc_unsupported) + per_cpu(cpu_pcc_subspace_idx, pr->id) = pcc_subspace_id; /* * Initialize the remaining cpc_regs as unsupported. @@ -1018,8 +1029,7 @@ int __weak cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val) static int cpc_read(int cpu, struct cpc_register_resource *reg_res, u64 *val) { void __iomem *vaddr = NULL; - int size; - int pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpu); + int size, pcc_ss_id; struct cpc_reg *reg = ®_res->cpc_entry.reg; if (reg_res->type == ACPI_TYPE_INTEGER) { @@ -1044,14 +1054,17 @@ static int cpc_read(int cpu, struct cpc_register_resource *reg_res, u64 *val) *val = val_u32; return 0; - } else if (reg->space_id == ACPI_ADR_SPACE_PLATFORM_COMM && pcc_ss_id >= 0) { - /* - * For registers in PCC space, the register size is determined - * by the bit width field; the access size is used to indicate - * the PCC subspace id. - */ - size = reg->bit_width; - vaddr = GET_PCC_VADDR(reg->address, pcc_ss_id); + } else if (reg->space_id == ACPI_ADR_SPACE_PLATFORM_COMM) { + pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpu); + if (pcc_ss_id >= 0) { + /* + * For registers in PCC space, the register size is determined + * by the bit width field; the access size is used to indicate + * the PCC subspace id. + */ + size = reg->bit_width; + vaddr = GET_PCC_VADDR(reg->address, pcc_ss_id); + } } else if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) vaddr = reg_res->sys_mem_vaddr; @@ -1282,6 +1295,81 @@ int cppc_get_epp_perf(int cpunum, u64 *epp_perf) } EXPORT_SYMBOL_GPL(cppc_get_epp_perf); + +int xen_processor_get_perf_caps(struct acpi_processor *pr, struct cppc_perf_caps *perf_caps) +{ + struct cpc_desc *cpc_ptr; + struct cpc_register_resource *highest_reg, *lowest_reg, + *lowest_non_linear_reg, *nominal_reg, + *low_freq_reg = NULL, *nom_freq_reg = NULL; + u64 high, low, nom, min_nonlinear, low_f = 0, nom_f = 0; + int ret = 0; + + cpc_ptr = kzalloc(sizeof(struct cpc_desc), GFP_KERNEL); + if (!cpc_ptr) + return -ENOMEM; + + ret = acpi_cppc_processor_parse(pr, cpc_ptr); + if (ret) + goto err; + + highest_reg = &cpc_ptr->cpc_regs[HIGHEST_PERF]; + lowest_reg = &cpc_ptr->cpc_regs[LOWEST_PERF]; + lowest_non_linear_reg = &cpc_ptr->cpc_regs[LOW_NON_LINEAR_PERF]; + nominal_reg = &cpc_ptr->cpc_regs[NOMINAL_PERF]; + low_freq_reg = &cpc_ptr->cpc_regs[LOWEST_FREQ]; + nom_freq_reg = &cpc_ptr->cpc_regs[NOMINAL_FREQ]; + + /* Are any of the regs PCC ?*/ + if (CPC_IN_PCC(highest_reg) || CPC_IN_PCC(lowest_reg) || + CPC_IN_PCC(lowest_non_linear_reg) || CPC_IN_PCC(nominal_reg) || + CPC_IN_PCC(low_freq_reg) || CPC_IN_PCC(nom_freq_reg)) { + pr_debug("Unsupported register type read for Xen Processor %d," + "highest_reg in PCC: %s, lowest_reg in PCC: %s," + "lowest_non_linear_reg in PCC: %s, nominal_reg in PCC: %s," + "low_freq_reg in PCC: %s, nom_freq_reg in PCC: %s\n", + pr->acpi_id, CPC_IN_PCC(highest_reg) ? "true" : "false", + CPC_IN_PCC(lowest_reg) ? "true" : "false", + CPC_IN_PCC(lowest_non_linear_reg) ? "true" : "false", + CPC_IN_PCC(nominal_reg) ? "true" : "false", + CPC_IN_PCC(low_freq_reg) ? "true" : "false", + CPC_IN_PCC(nom_freq_reg) ? "true" : "false"); + goto err; + } + + cpc_read(pr->acpi_id, highest_reg, &high); + perf_caps->highest_perf = high; + + cpc_read(pr->acpi_id, lowest_reg, &low); + perf_caps->lowest_perf = low; + + cpc_read(pr->acpi_id, nominal_reg, &nom); + perf_caps->nominal_perf = nom; + + cpc_read(pr->id, lowest_non_linear_reg, &min_nonlinear); + perf_caps->lowest_nonlinear_perf = min_nonlinear; + + if (!high || !low || !nom || !min_nonlinear) + pr_warn("CPPC: read zero cpc register value for Xen Processor %d" + "highest_reg: %llu, lowest_reg: %llu" + "nominal_reg: %llu, lowest_non_linear_reg: %llu\n", + pr->acpi_id, high, low, nom, min_nonlinear); + + /* Read optional lowest and nominal frequencies if present */ + if (CPC_SUPPORTED(low_freq_reg)) + cpc_read(pr->acpi_id, low_freq_reg, &low_f); + + if (CPC_SUPPORTED(nom_freq_reg)) + cpc_read(pr->acpi_id, nom_freq_reg, &nom_f); + + perf_caps->lowest_freq = low_f; + perf_caps->nominal_freq = nom_f; + + err: + kfree(cpc_ptr); + return ret; +} +EXPORT_SYMBOL_GPL(xen_processor_get_perf_caps); /** * cppc_get_perf_caps - Get a CPU's performance capabilities. * @cpunum: CPU from which to get capabilities info. diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h index 76e44e102780..2281110c00b7 100644 --- a/include/acpi/cppc_acpi.h +++ b/include/acpi/cppc_acpi.h @@ -164,6 +164,7 @@ extern int cppc_set_auto_sel(int cpu, bool enable); extern int amd_get_highest_perf(unsigned int cpu, u32 *highest_perf); extern int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator); extern int amd_detect_prefcore(bool *detected); +extern int xen_processor_get_perf_caps(struct acpi_processor *pr, struct cppc_perf_caps *perf_caps); #else /* !CONFIG_ACPI_CPPC_LIB */ static inline int cppc_get_desired_perf(int cpunum, u64 *desired_perf) { @@ -249,6 +250,10 @@ static inline int amd_detect_prefcore(bool *detected) { return -ENODEV; } +static inline int xen_processor_get_perf_caps(struct acpi_processor *pr, struct cppc_perf_caps *perf_caps) +{ + return -ENOTSUPP; +} #endif /* !CONFIG_ACPI_CPPC_LIB */ #endif /* _CPPC_ACPI_H*/ diff --git a/include/acpi/processor.h b/include/acpi/processor.h index e6f6074eadbf..18499cc11366 100644 --- a/include/acpi/processor.h +++ b/include/acpi/processor.h @@ -214,6 +214,7 @@ struct acpi_processor_flags { u8 bm_control:1; u8 bm_check:1; u8 has_cst:1; + u8 pcc_unsupported:1; u8 has_lpi:1; u8 power_setup_done:1; u8 bm_rld_set:1; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Dec 05 05:43:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 05:43:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848861.1263674 (Exim 4.92) (envelope-from ) id 1tJ4eG-00032s-Cg; Thu, 05 Dec 2024 05:43:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848861.1263674; Thu, 05 Dec 2024 05:43: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 1tJ4eG-00032l-9Q; Thu, 05 Dec 2024 05:43:36 +0000 Received: by outflank-mailman (input) for mailman id 848861; Thu, 05 Dec 2024 05:43: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 1tJ4eF-0001z8-FA for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 05:43:35 +0000 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on20616.outbound.protection.outlook.com [2a01:111:f403:2417::616]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id dd62f5be-b2cb-11ef-a0d5-8be0dac302b0; Thu, 05 Dec 2024 06:43:34 +0100 (CET) Received: from MW4PR03CA0071.namprd03.prod.outlook.com (2603:10b6:303:b6::16) by CY8PR12MB7609.namprd12.prod.outlook.com (2603:10b6:930:99::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.12; Thu, 5 Dec 2024 05:43:29 +0000 Received: from CY4PEPF0000FCBE.namprd03.prod.outlook.com (2603:10b6:303:b6:cafe::bb) by MW4PR03CA0071.outlook.office365.com (2603:10b6:303:b6::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.9 via Frontend Transport; Thu, 5 Dec 2024 05:43:29 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CY4PEPF0000FCBE.mail.protection.outlook.com (10.167.242.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Thu, 5 Dec 2024 05:43:28 +0000 Received: from penny-System-Product-Name.amd.com (10.180.168.240) 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; Wed, 4 Dec 2024 23:43:25 -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: dd62f5be-b2cb-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bqbEarWZcyjRyCaTHu+gTf5GtU0WxNMQmKRL7pBJXmwaWS8qB5qNdfAXW6PC27o4kvZnBvxh+QZgL5QRtbcCuZKHVYZRS2sOLUfEm5nH1kyCaMWIsWc5ab3vQdSeh12x18JFSF9ZLYzJOUWJtkS29WCf+yqoEnK4iVd1qM6Wq99L38yP/76ZgRCXZJ2dRraSlLktPJ0fy3HZ9KgikOUwMTfEeCdaI0bsIhN5LMn7FkpCz9eLq24N8odQyMl01Cw9tff2OU5VYjLJ8aIuhgjULaQ7RlzFD5bXD6PXaOtaYoqPN7PO8vscqBoCa5G/yES0fq1E4WpbttXdux2w4p0Eag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=f3kT6q2N35dmBYg9LrUhnFoFHFr1MmQ2XdbI9z7bg1s=; b=sbepxTvpRkMUDqCcq2jJGi3Ccib/Pa1UTQtuQ4fJT+FB9dSvksHZ32dP/iBwfx53zqos3AuouienTocZ7czrrqujHWl/0qKqvY6u7Rd5QdHjeU+jtBP+ONgOeof75AExah3r5WhwYCseuQSsRbBkn0AzoMXbNOgRsFYZRJ+Yw0+xy7YeSXizAy4pjKlakQ/8+b1SNDgc5eExoZxw1Xtd8a3RkPA99aRd6fJSecrDWZjUamPiOj7Pg9yQIVR4u+zwvD+5Av7HXRUX24dSv1fFzwi3FnB8oWy+utba817OeOkCUq+YqgzMFqwf6FEZxXRIVkBjvssykBGIkVBOuTUSKg== 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=f3kT6q2N35dmBYg9LrUhnFoFHFr1MmQ2XdbI9z7bg1s=; b=if2IhlaItK79RyYRy47iIOOgclnVXSxdIsyzv0378RQBVZbtb6Jz4itfldaRnxq+cgaT4i7Yw5twxZdenehYDSddDh00d6xkV9YOAX9oohA44M56zcibQ79Ez7W4rXHqW2hi8ZsX6WgwzIxtpTeZnIGudzm/h0ZFSvTkvEXgiTk= 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=SATLEXMB04.amd.com; pr=C From: Penny Zheng To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko CC: Ray Huang , Xenia Ragiadakou , Jason Andryuk , "Penny Zheng" , , Subject: [PATCH v2 4/4] xen/cppc: introduce cppc data upload sub-hypercall Date: Thu, 5 Dec 2024 13:42:52 +0800 Message-ID: <20241205054252.471761-5-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241205054252.471761-1-Penny.Zheng@amd.com> References: <20241205054252.471761-1-Penny.Zheng@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000FCBE:EE_|CY8PR12MB7609:EE_ X-MS-Office365-Filtering-Correlation-Id: 849b106c-4aad-4ce6-36f2-08dd14efbf02 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?hUwWn9GBx1E0HpOsdtodvd6SX/W/0F/sohJNZ86YnkruvPeE4P0MOaN103TA?= =?us-ascii?Q?nk2EmgyHpWzIITrhCfkVgFZ2WiHoJ4j5Eq53Hk/h+Pgf3UHlkBesoEfa6vgs?= =?us-ascii?Q?NwAlEzArodqxBctDOkCWRkj5mIIglmkSoOzKOWNWCS282Kr9EML5K4mgKRTs?= =?us-ascii?Q?fV9efe3Dob+gZH+VFioaDBtZqhKl2xZZcSyNSrKGTIF7HwiOuFukrP5jeplW?= =?us-ascii?Q?Ox1jxDdlekpPmXb6PoSnthQPNAEIHPnp/xVvlD7kwYCVAchQuLCVVFggz2v+?= =?us-ascii?Q?2Y+xsPdgD2j7YZC45o6mvX0hDtizPkJcMC4WT88Dm9KYoPk7EYtwQShNST5a?= =?us-ascii?Q?hM5MKHysDqO2M9PkVZKfNUBa9qBtY+3X55htgG0knLTyyyraiTWDK2IOqmxC?= =?us-ascii?Q?u2nAUKV7zLkB2Io7/ghKdsAPtKt7xK6Qjf+q3q0ZidsS/aUBfxcX10Q+n4Mz?= =?us-ascii?Q?utiS4YUfvalhtVW7kigTlVNipJMT36OOCk0vIAAnU5A43M/6uTs6rxOAApZ/?= =?us-ascii?Q?kJn96GobkQDg3KY3i1ByZopsr0Od3hQh7cdv6rSfNOiXmu9bjw+3ExjvKqeh?= =?us-ascii?Q?e0Nqp3bOxMDHdiXXPuUpE+orYIun1rQPAxXB0KiUtb0B8jb/WXsHkFoUcKEZ?= =?us-ascii?Q?Gg+rHFbYSTJYIaPi6KTNVWOjmSh7CQyMbvqQzevOEufRdeVDsxKYXQZhs9iS?= =?us-ascii?Q?xER5onyfc3N45izOY5x/FQsZoOqcWtA8gz0Olzqbyro19hH1tmhRF2mDKdhQ?= =?us-ascii?Q?9mFqldziWElNIHV6UsBw2YgUxL0gRHfleGvSdeTkCmYyv/7wp5+1NryR9gEZ?= =?us-ascii?Q?Z2/oePtjHORMIdkddujEa9jqmMkMTstzj/TeMv0KYMew2PJmOVK9GXpjNKLE?= =?us-ascii?Q?PkTGmyRgaEJPBnXWGDJErhcs/fMMUDg0d7LfNt+dFnEFaDuklfKOjmRKiiiP?= =?us-ascii?Q?B3RgObQ4fl1XkYzbA+uRzKTuZ0elVc6X2cm4RDC1aTUHF8kUw02E76V50BAz?= =?us-ascii?Q?TBhPYl8tqpYJm01pE4c8lT62c5FtRskZK1JrP1dFkBwIOL+NuHY5y92v8tfc?= =?us-ascii?Q?19P8sMBph0O+XuLFnIndHlhsbPQW+fY0+NxtNBBsS3Mdu+NpzZC/DIMYhkgM?= =?us-ascii?Q?D66SpmfXwgB9tOcQkDMcSvJtGDgF3Ivxjczf4I1VpqBbNCqhcp/NTgqv77sd?= =?us-ascii?Q?I48BiqBgpUTCEu9T90LZ2RNEjhgxPcWzuo9D9cmpDBXsTUO76rvmVBe90H0S?= =?us-ascii?Q?bAICojxysyh17BVJmUKXsJjcpNsT7OvYpudh62M2BelBXWDcwXcFcu7HiUJD?= =?us-ascii?Q?kETfKDOt/PgfSZKkHTM6sBDGX6DEDbDCtft4aL1hcyVOD9M+MG02ng9if89X?= =?us-ascii?Q?NOT+T4Gi6UKM0gnioMLuA+ugBodrbYVz7N+fXuV9SwsVxYGDs+QEnJ6shJ4e?= =?us-ascii?Q?BwPWpbOTnYe/NYdLSdM04DOuJpNtPZBz?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2024 05:43:28.9248 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 849b106c-4aad-4ce6-36f2-08dd14efbf02 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000FCBE.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7609 As Xen is uncapable of parsing the ACPI dynamic table, this commit introduces a new sub-hypercall XEN_PM_CPPC to deliver CPPC perf caps data. Signed-off-by: Penny Zheng --- drivers/acpi/cppc_acpi.c | 1 + drivers/xen/xen-acpi-processor.c | 89 +++++++++++++++++++++++++++++++- include/acpi/processor.h | 1 + include/xen/interface/platform.h | 11 ++++ 4 files changed, 101 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index 3a436591da07..3570a52a5dbd 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -860,6 +860,7 @@ static int acpi_cppc_processor_parse(struct acpi_processor *pr, struct cpc_desc cpc_ptr->cpc_regs[i].cpc_entry.int_value = 0; } + pr->flags.has_cpc = 1; pr_debug("Parsed _CPC entry for CPU: %d\n", pr->acpi_id); kfree(output.pointer); return 0; diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c index e9f38f171240..8a39e46c1ebc 100644 --- a/drivers/xen/xen-acpi-processor.c +++ b/drivers/xen/xen-acpi-processor.c @@ -25,6 +25,7 @@ #include #include #include +#include static int no_hypercall; MODULE_PARM_DESC(off, "Inhibit the hypercall."); @@ -45,8 +46,12 @@ static unsigned long *acpi_ids_done; static unsigned long *acpi_id_present; /* And if there is an _CST definition (or a PBLK) for the ACPI IDs */ static unsigned long *acpi_id_cst_present; +/* And if there is an _CPC entry for the ACPI IDs */ +static unsigned long *acpi_id_cpc_present; /* Which ACPI P-State dependencies for a enumerated processor */ static struct acpi_psd_package *acpi_psd; +/* ACPI CPPC structures for a enumerated processor */ +static struct cppc_perf_caps *acpi_cppc_data; static bool pr_initialized; @@ -208,6 +213,44 @@ static int xen_copy_pct_data(struct acpi_pct_register *pct, dst_pct->address = pct->address; return 0; } +static int push_cppc_to_hypervisor(struct acpi_processor *_pr) +{ + int ret = 0; + struct xen_platform_op op = { + .cmd = XENPF_set_processor_pminfo, + .interface_version = XENPF_INTERFACE_VERSION, + .u.set_pminfo.id = _pr->acpi_id, + .u.set_pminfo.type = XEN_PM_CPPC, + }; + struct cppc_perf_caps *cppc_perf = acpi_cppc_data + _pr->acpi_id; + + op.u.set_pminfo.cppc_data.highest_perf = cppc_perf->highest_perf; + op.u.set_pminfo.cppc_data.lowest_perf = cppc_perf->lowest_perf; + op.u.set_pminfo.cppc_data.nominal_perf = cppc_perf->nominal_perf; + op.u.set_pminfo.cppc_data.lowest_nonlinear_perf = cppc_perf->lowest_nonlinear_perf; + op.u.set_pminfo.cppc_data.lowest_freq = cppc_perf->lowest_freq; + op.u.set_pminfo.cppc_data.nominal_freq = cppc_perf->nominal_freq; + + if (!no_hypercall) + ret = HYPERVISOR_platform_op(&op); + + if (!ret) { + pr_debug("ACPI CPU%u - CPPC uploaded.\n", _pr->acpi_id); + pr_debug(" highest_perf: %d\n", cppc_perf->highest_perf); + pr_debug(" lowest_perf: %d\n", cppc_perf->lowest_perf); + pr_debug(" lowest_nonlinear_perf: %d\n", cppc_perf->lowest_nonlinear_perf); + pr_debug(" nominal_perf: %d\n", cppc_perf->nominal_perf); + pr_debug(" lowest_freq: %d Mhz\n", cppc_perf->lowest_freq); + pr_debug(" nominal_freq: %d Mhz\n", cppc_perf->nominal_freq); + } else if ((ret != -EINVAL) && (ret != -ENOSYS)) + /* EINVAL means the ACPI ID is incorrect - meaning the ACPI + * table is referencing a non-existing CPU - which can happen + * with broken ACPI tables. */ + pr_warn("(_CPC): Hypervisor error (%d) for ACPI CPU%u\n", + ret, _pr->acpi_id); + + return ret; +} static int push_pxx_to_hypervisor(struct acpi_processor *_pr) { int ret = 0; @@ -284,6 +327,9 @@ static int upload_pm_data(struct acpi_processor *_pr) if (_pr->flags.power) err = push_cxx_to_hypervisor(_pr); + if (_pr->flags.has_cpc) + err |= push_cppc_to_hypervisor(_pr); + if (_pr->performance && _pr->performance->states) err |= push_pxx_to_hypervisor(_pr); @@ -488,6 +534,7 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) union acpi_object object = { 0 }; struct acpi_buffer buffer = { sizeof(union acpi_object), &object }; struct acpi_buffer cst_buf = { ACPI_ALLOCATE_BUFFER, NULL }; + struct acpi_buffer cpc_buf = { ACPI_ALLOCATE_BUFFER, NULL }; acpi_io_address pblk = 0; status = acpi_get_type(handle, &acpi_type); @@ -567,11 +614,20 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) /* .. and it has a C-state */ __set_bit(acpi_id, acpi_id_cst_present); + status = acpi_evaluate_object(handle, "_CPC", NULL, &cpc_buf); + if (ACPI_FAILURE(status)) { + return AE_OK; + } + kfree(cpc_buf.pointer); + + /* .. and it has a _CPC entry */ + __set_bit(acpi_id, acpi_id_cpc_present); + return AE_OK; } static int check_acpi_ids(struct acpi_processor *pr_backup) { - if (acpi_id_present && acpi_id_cst_present) + if (acpi_id_present && acpi_id_cst_present && acpi_id_cpc_present) /* OK, done this once .. skip to uploading */ goto upload; @@ -588,11 +644,19 @@ static int check_acpi_ids(struct acpi_processor *pr_backup) return -ENOMEM; } + acpi_id_cpc_present = bitmap_zalloc(nr_acpi_bits, GFP_KERNEL); + if (!acpi_id_cpc_present) { + bitmap_free(acpi_id_present); + bitmap_free(acpi_id_cst_present); + return -ENOMEM; + } + acpi_psd = kcalloc(nr_acpi_bits, sizeof(struct acpi_psd_package), GFP_KERNEL); if (!acpi_psd) { bitmap_free(acpi_id_present); bitmap_free(acpi_id_cst_present); + bitmap_free(acpi_id_cpc_present); return -ENOMEM; } @@ -608,6 +672,12 @@ static int check_acpi_ids(struct acpi_processor *pr_backup) pr_backup->acpi_id = i; /* Mask out C-states if there are no _CST or PBLK */ pr_backup->flags.power = test_bit(i, acpi_id_cst_present); + /* Mask out relevant flag if there are no _CPC */ + pr_backup->flags.has_cpc = test_bit(i, acpi_id_cpc_present); + if (pr_backup->flags.has_cpc) { + if (xen_processor_get_perf_caps(pr_backup, acpi_cppc_data + i)) + return -EINVAL; + } /* num_entries is non-zero if we evaluated _PSD */ if (acpi_psd[i].num_entries) { memcpy(&pr_backup->performance->domain_info, @@ -726,6 +796,15 @@ static int __init xen_acpi_processor_init(void) bitmap_free(acpi_ids_done); return -ENOMEM; } + + acpi_cppc_data = kcalloc(nr_acpi_bits, sizeof(struct cppc_perf_caps), + GFP_KERNEL); + if (!acpi_cppc_data) { + pr_debug("Memory allocation error for acpi_cppc_data\n"); + rc = -ENOMEM; + goto err1_out; + } + for_each_possible_cpu(i) { if (!zalloc_cpumask_var_node( &per_cpu_ptr(acpi_perf_data, i)->shared_cpu_map, @@ -751,6 +830,11 @@ static int __init xen_acpi_processor_init(void) rc = acpi_processor_get_performance_info(pr); if (rc) goto err_out; + + pr->flags.pcc_unsupported = true; + rc = xen_processor_get_perf_caps(pr, acpi_cppc_data + i); + if (rc) + goto err_out; } rc = xen_upload_processor_pm_data(); @@ -766,6 +850,8 @@ static int __init xen_acpi_processor_init(void) err_out: /* Freeing a NULL pointer is OK: alloc_percpu zeroes. */ + kfree(acpi_cppc_data); +err1_out: free_acpi_perf_data(); bitmap_free(acpi_ids_done); return rc; @@ -779,6 +865,7 @@ static void __exit xen_acpi_processor_exit(void) bitmap_free(acpi_id_present); bitmap_free(acpi_id_cst_present); kfree(acpi_psd); + kfree(acpi_cppc_data); for_each_possible_cpu(i) acpi_processor_unregister_performance(i); diff --git a/include/acpi/processor.h b/include/acpi/processor.h index 18499cc11366..66492f5d68a8 100644 --- a/include/acpi/processor.h +++ b/include/acpi/processor.h @@ -214,6 +214,7 @@ struct acpi_processor_flags { u8 bm_control:1; u8 bm_check:1; u8 has_cst:1; + u8 has_cpc:1; u8 pcc_unsupported:1; u8 has_lpi:1; u8 power_setup_done:1; diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h index 79a443c65ea9..e11bb9443dc0 100644 --- a/include/xen/interface/platform.h +++ b/include/xen/interface/platform.h @@ -319,6 +319,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t); #define XEN_PM_PX 1 #define XEN_PM_TX 2 #define XEN_PM_PDC 3 +#define XEN_PM_CPPC 4 /* Px sub info type */ #define XEN_PX_PCT 1 #define XEN_PX_PSS 2 @@ -384,6 +385,15 @@ struct xen_processor_px { }; DEFINE_GUEST_HANDLE_STRUCT(xen_processor_px); +struct xen_processor_cppc { + uint32_t highest_perf; + uint32_t nominal_perf; + uint32_t lowest_perf; + uint32_t lowest_nonlinear_perf; + uint32_t lowest_freq; + uint32_t nominal_freq; +}; + struct xen_psd_package { uint64_t num_entries; uint64_t revision; @@ -412,6 +422,7 @@ struct xenpf_set_processor_pminfo { struct xen_processor_power power;/* Cx: _CST/_CSD */ struct xen_processor_performance perf; /* Px: _PPC/_PCT/_PSS/_PSD */ GUEST_HANDLE(uint32_t) pdc; + struct xen_processor_cppc cppc_data; /* _CPC */ }; }; DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Dec 05 07:28:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 07:28:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848921.1263683 (Exim 4.92) (envelope-from ) id 1tJ6Hv-0002pG-OO; Thu, 05 Dec 2024 07:28:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848921.1263683; Thu, 05 Dec 2024 07:28: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 1tJ6Hv-0002p9-LD; Thu, 05 Dec 2024 07:28:39 +0000 Received: by outflank-mailman (input) for mailman id 848921; Thu, 05 Dec 2024 07:28:38 +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 1tJ6Hu-0002oz-Ep for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 07:28:38 +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 895f1fa6-b2da-11ef-99a3-01e77a169b0f; Thu, 05 Dec 2024 08:28:35 +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 66E741F7A6; Thu, 5 Dec 2024 07:28:33 +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 1A56C138A5; Thu, 5 Dec 2024 07:28:33 +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 m3/qBCFWUWd8XQAAD6G6ig (envelope-from ); Thu, 05 Dec 2024 07:28: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: 895f1fa6-b2da-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1733383714; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=7T44+/Rf+hvl7fVoATnIgllk0M60mW9k6WyEjvHt7kM=; b=IeLsrUsnl38yTL58LheBCSIUjU770co1tFHJv/rLosLa6g85+is966cS1P40jttOg2KzRQ SG5QFmH4zCYcoZfu+h7KxHckghnBJyfFpCT3FPEZsx7fxVbFs+Ela+N4UQBvatBZtUe+22 W3Gb1knsRgQSiHN41XpAPG6hlgQOme4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1733383714; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=7T44+/Rf+hvl7fVoATnIgllk0M60mW9k6WyEjvHt7kM=; b=N7cGqlOOazqFrJ71TeSSu42wyneJYNMcPYPTJ85fBXbPdyuagZvbymKugxZgAS+wE9+Vw8 neNcap8mLpnV8QAw== Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1733383713; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=7T44+/Rf+hvl7fVoATnIgllk0M60mW9k6WyEjvHt7kM=; b=I0BDZC5Yw6SkZo/gi1/ECyQRsocxIuCrEw2/g1dmI8KpF8GgELc1Se9/JmSj/Biwzuk196 QPslmbAURlj0LwR7uRBomyBe1n6rZa5ZELUB0oDq5AOf154IdWflL8ydrbBI1r3Dq1JRdp oWkUKXagOj6YSE54Ne7rPYxKmWC4rjo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1733383713; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=7T44+/Rf+hvl7fVoATnIgllk0M60mW9k6WyEjvHt7kM=; b=iifqd+dqNQ0z1tOPCgN71Vipxpa6T41tT8Pe7TIb9Jdi8Ds8RPQfzXLHDX4KZGNsgipdJI fmuAb2AjRWDp/GDA== Message-ID: Date: Thu, 5 Dec 2024 08:28:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/3] drm/xen: remove redundant initialization info print To: Jani Nikula , dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org Cc: Alex Deucher , Oleksandr Andrushchenko , Maarten Lankhorst , Maxime Ripard , David Airlie , Simona Vetter , xen-devel@lists.xenproject.org References: <900b3836c80a23923ede034ab10eb344be1e35bd.1733322525.git.jani.nikula@intel.com> Content-Language: en-US From: Thomas Zimmermann Autocrypt: addr=tzimmermann@suse.de; keydata= xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c= In-Reply-To: <900b3836c80a23923ede034ab10eb344be1e35bd.1733322525.git.jani.nikula@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.30 X-Spamd-Result: default: False [-4.30 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_SEVEN(0.00)[11]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[amd.com,epam.com,linux.intel.com,kernel.org,gmail.com,ffwll.ch,lists.xenproject.org]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[] X-Spam-Flag: NO X-Spam-Level: Am 04.12.24 um 15:31 schrieb Jani Nikula: > drm_dev_register() already prints the same information on successful > init. Remove the redundant prints. > > Acked-by: Alex Deucher > Signed-off-by: Jani Nikula > > --- > > Note: I prefer to merge this together with the next patch via > drm-misc-next. > > Cc: Oleksandr Andrushchenko > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Simona Vetter > Cc: dri-devel@lists.freedesktop.org > Cc: xen-devel@lists.xenproject.org Reviewed-by: Thomas Zimmermann > --- > drivers/gpu/drm/xen/xen_drm_front.c | 5 ----- > 1 file changed, 5 deletions(-) > > diff --git a/drivers/gpu/drm/xen/xen_drm_front.c b/drivers/gpu/drm/xen/xen_drm_front.c > index aab79c5e34c2..931d855bfbe8 100644 > --- a/drivers/gpu/drm/xen/xen_drm_front.c > +++ b/drivers/gpu/drm/xen/xen_drm_front.c > @@ -525,11 +525,6 @@ static int xen_drm_drv_init(struct xen_drm_front_info *front_info) > if (ret) > goto fail_register; > > - DRM_INFO("Initialized %s %d.%d.%d %s on minor %d\n", > - xen_drm_driver.name, xen_drm_driver.major, > - xen_drm_driver.minor, xen_drm_driver.patchlevel, > - xen_drm_driver.date, drm_dev->primary->index); > - > return 0; > > fail_register: -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) From xen-devel-bounces@lists.xenproject.org Thu Dec 05 07:29:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 07:29:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848928.1263694 (Exim 4.92) (envelope-from ) id 1tJ6Ic-0003He-1x; Thu, 05 Dec 2024 07:29:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848928.1263694; Thu, 05 Dec 2024 07: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 1tJ6Ib-0003HX-U6; Thu, 05 Dec 2024 07:29:21 +0000 Received: by outflank-mailman (input) for mailman id 848928; Thu, 05 Dec 2024 07:29: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 1tJ6Ia-0003As-5M for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 07:29:20 +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 a2c76f0f-b2da-11ef-a0d5-8be0dac302b0; Thu, 05 Dec 2024 08:29:17 +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 114C6211FD; Thu, 5 Dec 2024 07:29:17 +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 7CF07138A5; Thu, 5 Dec 2024 07:29:16 +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 2slcHExWUWe3XQAAD6G6ig (envelope-from ); Thu, 05 Dec 2024 07:29: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: a2c76f0f-b2da-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1733383757; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=ZMPAzUJtEZlDER17NWKwIIveeV8osFA4jYgOuYBHSmk=; b=ai0PjzUWZ/URKmE0hFhPbSmYOD1YmPttGFvhbJPX+QC1SSOobAETrRdgd6mQkV7KgjmiXe DQSkhkb++6g10HUV/HJLNKhkA6v7fiBs8zMeFNlgx6EafYhKpeI8tj5ZT4p8br25/36dKG BVN58Dnk2F3qEAcdotqCdt/5OgS+PwI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1733383757; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=ZMPAzUJtEZlDER17NWKwIIveeV8osFA4jYgOuYBHSmk=; b=UE0QI+t1o8JfDveCqpbB521DwQVWIsNTFN7CmMDDAL9J/EHbIUDhh8OxKJEo59HWZge9xA 46lADKwbc/jOUJCg== Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=ai0PjzUW; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=UE0QI+t1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1733383757; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=ZMPAzUJtEZlDER17NWKwIIveeV8osFA4jYgOuYBHSmk=; b=ai0PjzUWZ/URKmE0hFhPbSmYOD1YmPttGFvhbJPX+QC1SSOobAETrRdgd6mQkV7KgjmiXe DQSkhkb++6g10HUV/HJLNKhkA6v7fiBs8zMeFNlgx6EafYhKpeI8tj5ZT4p8br25/36dKG BVN58Dnk2F3qEAcdotqCdt/5OgS+PwI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1733383757; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=ZMPAzUJtEZlDER17NWKwIIveeV8osFA4jYgOuYBHSmk=; b=UE0QI+t1o8JfDveCqpbB521DwQVWIsNTFN7CmMDDAL9J/EHbIUDhh8OxKJEo59HWZge9xA 46lADKwbc/jOUJCg== Message-ID: <340a179e-04fb-49cc-8ed9-227a34c32bc6@suse.de> Date: Thu, 5 Dec 2024 08:29:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/3] drm: remove driver date from struct drm_driver and all drivers To: Jani Nikula , dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org Cc: Javier Martinez Canillas , Alex Deucher , Simon Ser , Jeffrey Hugo , David Airlie , Hamza Mahfooz , Maarten Lankhorst , Maxime Ripard , Oleksandr Andrushchenko , Simona Vetter , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , amd-gfx@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, nouveau@lists.freedesktop.org, xen-devel@lists.xenproject.org References: <1f2bf2543aed270a06f6c707fd6ed1b78bf16712.1733322525.git.jani.nikula@intel.com> Content-Language: en-US From: Thomas Zimmermann Autocrypt: addr=tzimmermann@suse.de; keydata= xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c= In-Reply-To: <1f2bf2543aed270a06f6c707fd6ed1b78bf16712.1733322525.git.jani.nikula@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 114C6211FD X-Spam-Score: -4.51 X-Rspamd-Action: no action X-Spamd-Result: default: False [-4.51 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_TWELVE(0.00)[19]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[redhat.com,amd.com,emersion.fr,quicinc.com,gmail.com,linux.intel.com,kernel.org,epam.com,ffwll.ch,lists.freedesktop.org,lists.infradead.org,lists.xenproject.org]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[infradead.org:email]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[suse.de:+] X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Spam-Flag: NO X-Spam-Level: Am 04.12.24 um 15:31 schrieb Jani Nikula: > We stopped using the driver initialized date in commit 7fb8af6798e8 > ("drm: deprecate driver date") and (eventually) started returning "0" > for drm_version ioctl instead. > > Finish the job, and remove the unused date member from struct > drm_driver, its initialization from drivers, along with the common > DRIVER_DATE macros. > > v2: Also update drivers/accel (kernel test robot) > > Reviewed-by: Javier Martinez Canillas > Acked-by: Alex Deucher > Acked-by: Simon Ser > Acked-by: Jeffrey Hugo > Signed-off-by: Jani Nikula Reviewed-by: Thomas Zimmermann > > --- > > Cc: David Airlie > Cc: Hamza Mahfooz > Cc: Javier Martinez Canillas > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Oleksandr Andrushchenko > Cc: Simon Ser > Cc: Simona Vetter > Cc: Thomas Zimmermann > Cc: Ville Syrjälä > Cc: amd-gfx@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: nouveau@lists.freedesktop.org > Cc: xen-devel@lists.xenproject.org > --- > drivers/accel/habanalabs/common/habanalabs_drv.c | 1 - > drivers/accel/ivpu/ivpu_drv.c | 1 - > drivers/accel/qaic/qaic_drv.c | 1 - > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 -- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.h | 1 - > drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 1 - > drivers/gpu/drm/arm/hdlcd_drv.c | 1 - > drivers/gpu/drm/arm/malidp_drv.c | 1 - > drivers/gpu/drm/armada/armada_drv.c | 1 - > drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 1 - > drivers/gpu/drm/ast/ast_drv.c | 1 - > drivers/gpu/drm/ast/ast_drv.h | 1 - > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 1 - > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 1 - > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 -- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 1 - > drivers/gpu/drm/gma500/psb_drv.c | 1 - > drivers/gpu/drm/gma500/psb_drv.h | 1 - > drivers/gpu/drm/gud/gud_drv.c | 1 - > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 1 - > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 1 - > drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 2 -- > drivers/gpu/drm/i915/i915_driver.c | 1 - > drivers/gpu/drm/i915/i915_driver.h | 1 - > drivers/gpu/drm/i915/i915_gpu_error.c | 1 - > drivers/gpu/drm/imagination/pvr_drv.c | 1 - > drivers/gpu/drm/imagination/pvr_drv.h | 1 - > drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 - > drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 1 - > drivers/gpu/drm/imx/lcdc/imx-lcdc.c | 1 - > drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 1 - > drivers/gpu/drm/kmb/kmb_drv.c | 1 - > drivers/gpu/drm/kmb/kmb_drv.h | 1 - > drivers/gpu/drm/lima/lima_drv.c | 1 - > drivers/gpu/drm/logicvc/logicvc_drm.c | 1 - > drivers/gpu/drm/loongson/lsdc_drv.c | 2 -- > drivers/gpu/drm/mcde/mcde_drv.c | 1 - > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 -- > drivers/gpu/drm/meson/meson_drv.c | 1 - > drivers/gpu/drm/mgag200/mgag200_drv.c | 1 - > drivers/gpu/drm/mgag200/mgag200_drv.h | 1 - > drivers/gpu/drm/msm/msm_drv.c | 1 - > drivers/gpu/drm/mxsfb/lcdif_drv.c | 1 - > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 1 - > drivers/gpu/drm/nouveau/nouveau_drm.c | 5 ----- > drivers/gpu/drm/nouveau/nouveau_drv.h | 1 - > drivers/gpu/drm/omapdrm/omap_drv.c | 2 -- > drivers/gpu/drm/panfrost/panfrost_drv.c | 1 - > drivers/gpu/drm/panthor/panthor_drv.c | 1 - > drivers/gpu/drm/pl111/pl111_drv.c | 1 - > drivers/gpu/drm/qxl/qxl_drv.c | 1 - > drivers/gpu/drm/qxl/qxl_drv.h | 1 - > drivers/gpu/drm/radeon/radeon_drv.c | 1 - > drivers/gpu/drm/radeon/radeon_drv.h | 1 - > drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 1 - > drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 1 - > drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c | 1 - > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 -- > drivers/gpu/drm/solomon/ssd130x.c | 2 -- > drivers/gpu/drm/sprd/sprd_drm.c | 2 -- > drivers/gpu/drm/sti/sti_drv.c | 2 -- > drivers/gpu/drm/stm/drv.c | 1 - > drivers/gpu/drm/sun4i/sun4i_drv.c | 1 - > drivers/gpu/drm/tegra/drm.c | 2 -- > drivers/gpu/drm/tidss/tidss_drv.c | 1 - > drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 - > drivers/gpu/drm/tiny/arcpgu.c | 1 - > drivers/gpu/drm/tiny/bochs.c | 1 - > drivers/gpu/drm/tiny/cirrus-qemu.c | 2 -- > drivers/gpu/drm/tiny/gm12u320.c | 2 -- > drivers/gpu/drm/tiny/hx8357d.c | 1 - > drivers/gpu/drm/tiny/ili9163.c | 1 - > drivers/gpu/drm/tiny/ili9225.c | 1 - > drivers/gpu/drm/tiny/ili9341.c | 1 - > drivers/gpu/drm/tiny/ili9486.c | 1 - > drivers/gpu/drm/tiny/mi0283qt.c | 1 - > drivers/gpu/drm/tiny/ofdrm.c | 2 -- > drivers/gpu/drm/tiny/panel-mipi-dbi.c | 1 - > drivers/gpu/drm/tiny/repaper.c | 1 - > drivers/gpu/drm/tiny/sharp-memory.c | 1 - > drivers/gpu/drm/tiny/simpledrm.c | 2 -- > drivers/gpu/drm/tiny/st7586.c | 1 - > drivers/gpu/drm/tiny/st7735r.c | 1 - > drivers/gpu/drm/tve200/tve200_drv.c | 1 - > drivers/gpu/drm/udl/udl_drv.c | 1 - > drivers/gpu/drm/udl/udl_drv.h | 1 - > drivers/gpu/drm/v3d/v3d_drv.c | 2 -- > drivers/gpu/drm/vboxvideo/vbox_drv.c | 1 - > drivers/gpu/drm/vboxvideo/vbox_drv.h | 1 - > drivers/gpu/drm/vc4/vc4_drv.c | 3 --- > drivers/gpu/drm/vgem/vgem_drv.c | 2 -- > drivers/gpu/drm/virtio/virtgpu_drv.c | 1 - > drivers/gpu/drm/virtio/virtgpu_drv.h | 1 - > drivers/gpu/drm/vkms/vkms_drv.c | 2 -- > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 - > drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 - > drivers/gpu/drm/xe/xe_device.c | 1 - > drivers/gpu/drm/xe/xe_drv.h | 1 - > drivers/gpu/drm/xen/xen_drm_front.c | 1 - > drivers/gpu/drm/xlnx/zynqmp_kms.c | 1 - > include/drm/drm_drv.h | 2 -- > 101 files changed, 126 deletions(-) > > diff --git a/drivers/accel/habanalabs/common/habanalabs_drv.c b/drivers/accel/habanalabs/common/habanalabs_drv.c > index 708dfd10f39c..5409b2c656c8 100644 > --- a/drivers/accel/habanalabs/common/habanalabs_drv.c > +++ b/drivers/accel/habanalabs/common/habanalabs_drv.c > @@ -101,7 +101,6 @@ static const struct drm_driver hl_driver = { > .major = LINUX_VERSION_MAJOR, > .minor = LINUX_VERSION_PATCHLEVEL, > .patchlevel = LINUX_VERSION_SUBLEVEL, > - .date = "20190505", > > .fops = &hl_fops, > .open = hl_device_open, > diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c > index 1f359dbe5150..1e8ffbe25eee 100644 > --- a/drivers/accel/ivpu/ivpu_drv.c > +++ b/drivers/accel/ivpu/ivpu_drv.c > @@ -458,7 +458,6 @@ static const struct drm_driver driver = { > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > > - .date = UTS_RELEASE, > .major = 1, > }; > > diff --git a/drivers/accel/qaic/qaic_drv.c b/drivers/accel/qaic/qaic_drv.c > index 3575e0c984d6..542c5d24e499 100644 > --- a/drivers/accel/qaic/qaic_drv.c > +++ b/drivers/accel/qaic/qaic_drv.c > @@ -208,7 +208,6 @@ static const struct drm_driver qaic_accel_driver = { > > .name = QAIC_NAME, > .desc = QAIC_DESC, > - .date = "20190618", > > .fops = &qaic_accel_fops, > .open = qaic_open, > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > index 346746d6c233..eaeaaddb32cd 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > @@ -2916,7 +2916,6 @@ static const struct drm_driver amdgpu_kms_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = KMS_DRIVER_MAJOR, > .minor = KMS_DRIVER_MINOR, > .patchlevel = KMS_DRIVER_PATCHLEVEL, > @@ -2940,7 +2939,6 @@ const struct drm_driver amdgpu_partition_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = KMS_DRIVER_MAJOR, > .minor = KMS_DRIVER_MINOR, > .patchlevel = KMS_DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.h > index 5bc2cb661af7..2d86cc6f7f4d 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.h > @@ -40,7 +40,6 @@ > > #define DRIVER_NAME "amdgpu" > #define DRIVER_DESC "AMD GPU" > -#define DRIVER_DATE "20150101" > > extern const struct drm_driver amdgpu_partition_driver; > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c > index 1e7b1fcb2848..6ed504099188 100644 > --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c > @@ -63,7 +63,6 @@ static const struct drm_driver komeda_kms_driver = { > .fops = &komeda_cma_fops, > .name = "komeda", > .desc = "Arm Komeda Display Processor driver", > - .date = "20181101", > .major = 0, > .minor = 1, > }; > diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c > index 4af8fce7dab7..8617d10940d8 100644 > --- a/drivers/gpu/drm/arm/hdlcd_drv.c > +++ b/drivers/gpu/drm/arm/hdlcd_drv.c > @@ -233,7 +233,6 @@ static const struct drm_driver hdlcd_driver = { > .fops = &fops, > .name = "hdlcd", > .desc = "ARM HDLCD Controller DRM", > - .date = "20151021", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c > index 38b1b5b6bf69..3abc9339464b 100644 > --- a/drivers/gpu/drm/arm/malidp_drv.c > +++ b/drivers/gpu/drm/arm/malidp_drv.c > @@ -570,7 +570,6 @@ static const struct drm_driver malidp_driver = { > .fops = &fops, > .name = "mali-dp", > .desc = "ARM Mali Display Processor driver", > - .date = "20160106", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c > index ddf0eaf546a6..5d5b7435970a 100644 > --- a/drivers/gpu/drm/armada/armada_drv.c > +++ b/drivers/gpu/drm/armada/armada_drv.c > @@ -45,7 +45,6 @@ static const struct drm_driver armada_drm_driver = { > .minor = 0, > .name = "armada-drm", > .desc = "Armada SoC DRM", > - .date = "20120730", > .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC, > .ioctls = armada_ioctls, > .num_ioctls = ARRAY_SIZE(armada_ioctls), > diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c > index 55e90ab9b231..90189a3cf886 100644 > --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c > +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c > @@ -252,7 +252,6 @@ static const struct drm_driver aspeed_gfx_driver = { > .fops = &fops, > .name = "aspeed-gfx-drm", > .desc = "ASPEED GFX DRM", > - .date = "20180319", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c > index 8e9c9cb89a50..ff3bcdd1cff2 100644 > --- a/drivers/gpu/drm/ast/ast_drv.c > +++ b/drivers/gpu/drm/ast/ast_drv.c > @@ -60,7 +60,6 @@ static const struct drm_driver ast_driver = { > .fops = &ast_fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h > index 21ce3769bf0d..6b4305ac07d4 100644 > --- a/drivers/gpu/drm/ast/ast_drv.h > +++ b/drivers/gpu/drm/ast/ast_drv.h > @@ -43,7 +43,6 @@ > > #define DRIVER_NAME "ast" > #define DRIVER_DESC "AST" > -#define DRIVER_DATE "20120228" > > #define DRIVER_MAJOR 0 > #define DRIVER_MINOR 1 > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > index 506289a937e2..b51528b2166c 100644 > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > @@ -846,7 +846,6 @@ static const struct drm_driver atmel_hlcdc_dc_driver = { > .fops = &fops, > .name = "atmel-hlcdc", > .desc = "Atmel HLCD Controller DRM", > - .date = "20141504", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c > index 9b4e2f4b1bc7..c4ddabe3cabd 100644 > --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c > +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c > @@ -503,7 +503,6 @@ static const struct drm_driver etnaviv_drm_driver = { > .fops = &fops, > .name = "etnaviv", > .desc = "etnaviv DRM", > - .date = "20151214", > .major = 1, > .minor = 4, > }; > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c > index 7e517a2ec681..91ab42b56716 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c > @@ -35,7 +35,6 @@ > > #define DRIVER_NAME "exynos" > #define DRIVER_DESC "Samsung SoC DRM" > -#define DRIVER_DATE "20180330" > > /* > * Interface history: > @@ -118,7 +117,6 @@ static const struct drm_driver exynos_drm_driver = { > .fops = &exynos_drm_driver_fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > }; > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > index 12b2096b6c9d..e1183644ec39 100644 > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > @@ -174,7 +174,6 @@ static const struct drm_driver fsl_dcu_drm_driver = { > .fops = &fsl_dcu_drm_fops, > .name = "fsl-dcu-drm", > .desc = "Freescale DCU DRM", > - .date = "20160425", > .major = 1, > .minor = 1, > }; > diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c > index 2c56ece17d71..85d3557c2eb9 100644 > --- a/drivers/gpu/drm/gma500/psb_drv.c > +++ b/drivers/gpu/drm/gma500/psb_drv.c > @@ -513,7 +513,6 @@ static const struct drm_driver driver = { > .fops = &psb_gem_fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL > diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h > index de62cbfcdc72..7f77cb2b2751 100644 > --- a/drivers/gpu/drm/gma500/psb_drv.h > +++ b/drivers/gpu/drm/gma500/psb_drv.h > @@ -26,7 +26,6 @@ > > #define DRIVER_NAME "gma500" > #define DRIVER_DESC "DRM driver for the Intel GMA500, GMA600, GMA3600, GMA3650" > -#define DRIVER_DATE "20140314" > > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c > index 65a16f009ea6..cb405771d6e2 100644 > --- a/drivers/gpu/drm/gud/gud_drv.c > +++ b/drivers/gpu/drm/gud/gud_drv.c > @@ -381,7 +381,6 @@ static const struct drm_driver gud_drm_driver = { > > .name = "gud", > .desc = "Generic USB Display", > - .date = "20200422", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c > index 69bdae604982..7f814c32ed34 100644 > --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c > +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c > @@ -57,7 +57,6 @@ static const struct drm_driver hibmc_driver = { > .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC, > .fops = &hibmc_fops, > .name = "hibmc", > - .date = "20160828", > .desc = "hibmc drm driver", > .major = 1, > .minor = 0, > diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c > index 5616c3917c03..2eb49177ac42 100644 > --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c > +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c > @@ -929,7 +929,6 @@ static const struct drm_driver ade_driver = { > DRM_FBDEV_DMA_DRIVER_OPS, > .name = "kirin", > .desc = "Hisilicon Kirin620 SoC DRM Driver", > - .date = "20150718", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c > index c5ac240f7a7a..f59abfa7622a 100644 > --- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c > +++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c > @@ -20,7 +20,6 @@ > > #define DRIVER_NAME "hyperv_drm" > #define DRIVER_DESC "DRM driver for Hyper-V synthetic video device" > -#define DRIVER_DATE "2020" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -31,7 +30,6 @@ static struct drm_driver hyperv_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > > diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c > index c1edf5e1f61e..e35aa0274d76 100644 > --- a/drivers/gpu/drm/i915/i915_driver.c > +++ b/drivers/gpu/drm/i915/i915_driver.c > @@ -1797,7 +1797,6 @@ static const struct drm_driver i915_drm_driver = { > .fops = &i915_driver_fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/i915/i915_driver.h b/drivers/gpu/drm/i915/i915_driver.h > index 94a70d8ec5d5..4b67ad9a61cd 100644 > --- a/drivers/gpu/drm/i915/i915_driver.h > +++ b/drivers/gpu/drm/i915/i915_driver.h > @@ -15,7 +15,6 @@ struct drm_printer; > > #define DRIVER_NAME "i915" > #define DRIVER_DESC "Intel Graphics" > -#define DRIVER_DATE "20230929" > #define DRIVER_TIMESTAMP 1695980603 > > extern const struct dev_pm_ops i915_pm_ops; > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c > index 4eb58887819a..eb975b3815df 100644 > --- a/drivers/gpu/drm/i915/i915_gpu_error.c > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c > @@ -841,7 +841,6 @@ static void __err_print_to_sgl(struct drm_i915_error_state_buf *m, > err_printf(m, "Kernel: %s %s\n", > init_utsname()->release, > init_utsname()->machine); > - err_printf(m, "Driver: %s\n", DRIVER_DATE); > ts = ktime_to_timespec64(error->time); > err_printf(m, "Time: %lld s %ld us\n", > (s64)ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC); > diff --git a/drivers/gpu/drm/imagination/pvr_drv.c b/drivers/gpu/drm/imagination/pvr_drv.c > index 36c0e768698e..6ab023593476 100644 > --- a/drivers/gpu/drm/imagination/pvr_drv.c > +++ b/drivers/gpu/drm/imagination/pvr_drv.c > @@ -1387,7 +1387,6 @@ static struct drm_driver pvr_drm_driver = { > > .name = PVR_DRIVER_NAME, > .desc = PVR_DRIVER_DESC, > - .date = PVR_DRIVER_DATE, > .major = PVR_DRIVER_MAJOR, > .minor = PVR_DRIVER_MINOR, > .patchlevel = PVR_DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/imagination/pvr_drv.h b/drivers/gpu/drm/imagination/pvr_drv.h > index 378fe477b759..7fa147312dd1 100644 > --- a/drivers/gpu/drm/imagination/pvr_drv.h > +++ b/drivers/gpu/drm/imagination/pvr_drv.h > @@ -9,7 +9,6 @@ > > #define PVR_DRIVER_NAME "powervr" > #define PVR_DRIVER_DESC "Imagination PowerVR (Series 6 and later) & IMG Graphics" > -#define PVR_DRIVER_DATE "20230904" > > /* > * Driver interface version: > diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c b/drivers/gpu/drm/imx/dcss/dcss-kms.c > index 490b5c269f39..3633e8f3aff6 100644 > --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c > +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c > @@ -34,7 +34,6 @@ static const struct drm_driver dcss_kms_driver = { > .fops = &dcss_cma_fops, > .name = "imx-dcss", > .desc = "i.MX8MQ Display Subsystem", > - .date = "20190917", > .major = 1, > .minor = 0, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c > index 6b84429735d6..bcb35ba670fc 100644 > --- a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c > +++ b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c > @@ -163,7 +163,6 @@ static const struct drm_driver imx_drm_driver = { > .fops = &imx_drm_driver_fops, > .name = "imx-drm", > .desc = "i.MX DRM graphics", > - .date = "20120507", > .major = 1, > .minor = 0, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/imx/lcdc/imx-lcdc.c b/drivers/gpu/drm/imx/lcdc/imx-lcdc.c > index c5121fed80fd..d70981295f88 100644 > --- a/drivers/gpu/drm/imx/lcdc/imx-lcdc.c > +++ b/drivers/gpu/drm/imx/lcdc/imx-lcdc.c > @@ -352,7 +352,6 @@ static struct drm_driver imx_lcdc_drm_driver = { > DRM_FBDEV_DMA_DRIVER_OPS, > .name = "imx-lcdc", > .desc = "i.MX LCDC driver", > - .date = "20200716", > }; > > static const struct of_device_id imx_lcdc_of_dev_id[] = { > diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c > index 0a4eb3994cd6..6546d9ec410a 100644 > --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c > +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c > @@ -953,7 +953,6 @@ static const struct drm_driver ingenic_drm_driver_data = { > .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC, > .name = "ingenic-drm", > .desc = "DRM module for Ingenic SoCs", > - .date = "20200716", > .major = 1, > .minor = 1, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/kmb/kmb_drv.c b/drivers/gpu/drm/kmb/kmb_drv.c > index 4173344ba32c..c340b4c6a74b 100644 > --- a/drivers/gpu/drm/kmb/kmb_drv.c > +++ b/drivers/gpu/drm/kmb/kmb_drv.c > @@ -445,7 +445,6 @@ static const struct drm_driver kmb_driver = { > DRM_FBDEV_DMA_DRIVER_OPS, > .name = "kmb-drm", > .desc = "KEEMBAY DISPLAY DRIVER", > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > }; > diff --git a/drivers/gpu/drm/kmb/kmb_drv.h b/drivers/gpu/drm/kmb/kmb_drv.h > index bf085e95b28f..1f0c10d317fe 100644 > --- a/drivers/gpu/drm/kmb/kmb_drv.h > +++ b/drivers/gpu/drm/kmb/kmb_drv.h > @@ -16,7 +16,6 @@ > #define KMB_MIN_WIDTH 1920 /*Max width in pixels */ > #define KMB_MIN_HEIGHT 1080 /*Max height in pixels */ > > -#define DRIVER_DATE "20210223" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 1 > > diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c > index 10bce18b7c31..4b70c5189f7c 100644 > --- a/drivers/gpu/drm/lima/lima_drv.c > +++ b/drivers/gpu/drm/lima/lima_drv.c > @@ -271,7 +271,6 @@ static const struct drm_driver lima_drm_driver = { > .fops = &lima_drm_driver_fops, > .name = "lima", > .desc = "lima DRM", > - .date = "20191231", > .major = 1, > .minor = 1, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/logicvc/logicvc_drm.c b/drivers/gpu/drm/logicvc/logicvc_drm.c > index 9152034e54a3..bda2a689d928 100644 > --- a/drivers/gpu/drm/logicvc/logicvc_drm.c > +++ b/drivers/gpu/drm/logicvc/logicvc_drm.c > @@ -52,7 +52,6 @@ static struct drm_driver logicvc_drm_driver = { > .fops = &logicvc_drm_fops, > .name = "logicvc-drm", > .desc = "Xylon LogiCVC DRM driver", > - .date = "20200403", > .major = 1, > .minor = 0, > > diff --git a/drivers/gpu/drm/loongson/lsdc_drv.c b/drivers/gpu/drm/loongson/lsdc_drv.c > index a55aa1fe2c21..12193d2a301a 100644 > --- a/drivers/gpu/drm/loongson/lsdc_drv.c > +++ b/drivers/gpu/drm/loongson/lsdc_drv.c > @@ -26,7 +26,6 @@ > #define DRIVER_AUTHOR "Sui Jingfeng " > #define DRIVER_NAME "loongson" > #define DRIVER_DESC "drm driver for loongson graphics" > -#define DRIVER_DATE "20220701" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > #define DRIVER_PATCHLEVEL 0 > @@ -39,7 +38,6 @@ static const struct drm_driver lsdc_drm_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c > index f8c7aa9d7f33..324a95d7f15b 100644 > --- a/drivers/gpu/drm/mcde/mcde_drv.c > +++ b/drivers/gpu/drm/mcde/mcde_drv.c > @@ -208,7 +208,6 @@ static const struct drm_driver mcde_drm_driver = { > .fops = &drm_fops, > .name = "mcde", > .desc = DRIVER_DESC, > - .date = "20180529", > .major = 1, > .minor = 0, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > index 38297d705df6..723782e75c55 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > @@ -33,7 +33,6 @@ > > #define DRIVER_NAME "mediatek" > #define DRIVER_DESC "Mediatek SoC DRM" > -#define DRIVER_DATE "20150513" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -615,7 +614,6 @@ static const struct drm_driver mtk_drm_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > }; > diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c > index 83ee18024682..64c8c4bb60f1 100644 > --- a/drivers/gpu/drm/meson/meson_drv.c > +++ b/drivers/gpu/drm/meson/meson_drv.c > @@ -105,7 +105,6 @@ static const struct drm_driver meson_driver = { > .fops = &fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = "20161109", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c b/drivers/gpu/drm/mgag200/mgag200_drv.c > index b7ed763addfa..069fdd2dc8f6 100644 > --- a/drivers/gpu/drm/mgag200/mgag200_drv.c > +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c > @@ -97,7 +97,6 @@ static const struct drm_driver mgag200_driver = { > .fops = &mgag200_driver_fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h b/drivers/gpu/drm/mgag200/mgag200_drv.h > index 988967eafbf2..0608fc63e588 100644 > --- a/drivers/gpu/drm/mgag200/mgag200_drv.h > +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h > @@ -25,7 +25,6 @@ > > #define DRIVER_NAME "mgag200" > #define DRIVER_DESC "MGA G200 SE" > -#define DRIVER_DATE "20110418" > > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c > index b5fa715cbfb0..73e72aee6ec5 100644 > --- a/drivers/gpu/drm/msm/msm_drv.c > +++ b/drivers/gpu/drm/msm/msm_drv.c > @@ -910,7 +910,6 @@ static const struct drm_driver msm_driver = { > .fops = &fops, > .name = "msm", > .desc = "MSM Snapdragon DRM", > - .date = "20130625", > .major = MSM_VERSION_MAJOR, > .minor = MSM_VERSION_MINOR, > .patchlevel = MSM_VERSION_PATCHLEVEL, > diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c b/drivers/gpu/drm/mxsfb/lcdif_drv.c > index 81ec91cef66c..02fe6b89f3aa 100644 > --- a/drivers/gpu/drm/mxsfb/lcdif_drv.c > +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c > @@ -248,7 +248,6 @@ static const struct drm_driver lcdif_driver = { > .fops = &fops, > .name = "imx-lcdif", > .desc = "i.MX LCDIF Controller DRM", > - .date = "20220417", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c > index 1c27a97dce03..129cc3fb4448 100644 > --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c > +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c > @@ -336,7 +336,6 @@ static const struct drm_driver mxsfb_driver = { > .fops = &fops, > .name = "mxsfb-drm", > .desc = "MXSFB Controller DRM", > - .date = "20160824", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c > index a99c1d9855c9..744ae9d3305d 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_drm.c > +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c > @@ -1326,11 +1326,6 @@ driver_stub = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > -#ifdef GIT_REVISION > - .date = GIT_REVISION, > -#else > - .date = DRIVER_DATE, > -#endif > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h > index 685d6ca3d8aa..55abc510067b 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_drv.h > +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h > @@ -7,7 +7,6 @@ > > #define DRIVER_NAME "nouveau" > #define DRIVER_DESC "nVidia Riva/TNT/GeForce/Quadro/Tesla/Tegra K1+" > -#define DRIVER_DATE "20120801" > > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 4 > diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c > index 1796cd20a877..a80e0f375a0e 100644 > --- a/drivers/gpu/drm/omapdrm/omap_drv.c > +++ b/drivers/gpu/drm/omapdrm/omap_drv.c > @@ -28,7 +28,6 @@ > > #define DRIVER_NAME MODULE_NAME > #define DRIVER_DESC "OMAP DRM" > -#define DRIVER_DATE "20110917" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > #define DRIVER_PATCHLEVEL 0 > @@ -653,7 +652,6 @@ static const struct drm_driver omap_drm_driver = { > .fops = &omapdriver_fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c > index 04d615df5259..fbaef3afcd66 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_drv.c > +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c > @@ -636,7 +636,6 @@ static const struct drm_driver panfrost_drm_driver = { > .fops = &panfrost_drm_driver_fops, > .name = "panfrost", > .desc = "panfrost DRM", > - .date = "20180908", > .major = 1, > .minor = 3, > > diff --git a/drivers/gpu/drm/panthor/panthor_drv.c b/drivers/gpu/drm/panthor/panthor_drv.c > index ac7e53f6e3f0..ad46a40ed9e1 100644 > --- a/drivers/gpu/drm/panthor/panthor_drv.c > +++ b/drivers/gpu/drm/panthor/panthor_drv.c > @@ -1505,7 +1505,6 @@ static const struct drm_driver panthor_drm_driver = { > .fops = &panthor_drm_driver_fops, > .name = "panthor", > .desc = "Panthor DRM driver", > - .date = "20230801", > .major = 1, > .minor = 2, > > diff --git a/drivers/gpu/drm/pl111/pl111_drv.c b/drivers/gpu/drm/pl111/pl111_drv.c > index 4b96f48cf630..56ff6a3fb483 100644 > --- a/drivers/gpu/drm/pl111/pl111_drv.c > +++ b/drivers/gpu/drm/pl111/pl111_drv.c > @@ -220,7 +220,6 @@ static const struct drm_driver pl111_drm_driver = { > .fops = &drm_fops, > .name = "pl111", > .desc = DRIVER_DESC, > - .date = "20170317", > .major = 1, > .minor = 0, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c > index f15e9583b098..417061ae59eb 100644 > --- a/drivers/gpu/drm/qxl/qxl_drv.c > +++ b/drivers/gpu/drm/qxl/qxl_drv.c > @@ -300,7 +300,6 @@ static struct drm_driver qxl_driver = { > .num_ioctls = ARRAY_SIZE(qxl_ioctls), > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = 0, > .minor = 1, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h > index b5fc14c9525d..cc02b5f10ad9 100644 > --- a/drivers/gpu/drm/qxl/qxl_drv.h > +++ b/drivers/gpu/drm/qxl/qxl_drv.h > @@ -54,7 +54,6 @@ struct iosys_map; > > #define DRIVER_NAME "qxl" > #define DRIVER_DESC "RH QXL" > -#define DRIVER_DATE "20120117" > > #define DRIVER_MAJOR 0 > #define DRIVER_MINOR 1 > diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c > index 5ce7e91bedad..267f082bc430 100644 > --- a/drivers/gpu/drm/radeon/radeon_drv.c > +++ b/drivers/gpu/drm/radeon/radeon_drv.c > @@ -603,7 +603,6 @@ static const struct drm_driver kms_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = KMS_DRIVER_MAJOR, > .minor = KMS_DRIVER_MINOR, > .patchlevel = KMS_DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/radeon/radeon_drv.h b/drivers/gpu/drm/radeon/radeon_drv.h > index 02a65971d140..0f3dbffc492d 100644 > --- a/drivers/gpu/drm/radeon/radeon_drv.h > +++ b/drivers/gpu/drm/radeon/radeon_drv.h > @@ -43,7 +43,6 @@ > > #define DRIVER_NAME "radeon" > #define DRIVER_DESC "ATI Radeon" > -#define DRIVER_DATE "20080528" > > /* Interface history: > * > diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c > index 0f5204ef996e..be39b107b98c 100644 > --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c > +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c > @@ -611,7 +611,6 @@ static const struct drm_driver rcar_du_driver = { > .fops = &rcar_du_fops, > .name = "rcar-du", > .desc = "Renesas R-Car Display Unit", > - .date = "20130110", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c > index 0a03a20f663b..9bbdc4d63d88 100644 > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c > @@ -84,7 +84,6 @@ static const struct drm_driver rzg2l_du_driver = { > .fops = &rzg2l_du_fops, > .name = "rzg2l-du", > .desc = "Renesas RZ/G2L Display Unit", > - .date = "20230410", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c b/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c > index 40b582ee178e..387eb602dadf 100644 > --- a/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c > +++ b/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c > @@ -107,7 +107,6 @@ static const struct drm_driver shmob_drm_driver = { > .fops = &shmob_drm_fops, > .name = "shmob-drm", > .desc = "Renesas SH Mobile DRM", > - .date = "20120424", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > index 0393b48ad65b..1fe4399d6901 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > @@ -39,7 +39,6 @@ > > #define DRIVER_NAME "rockchip" > #define DRIVER_DESC "RockChip Soc DRM" > -#define DRIVER_DATE "20140818" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -235,7 +234,6 @@ static const struct drm_driver rockchip_drm_driver = { > .fops = &rockchip_drm_driver_fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > }; > diff --git a/drivers/gpu/drm/solomon/ssd130x.c b/drivers/gpu/drm/solomon/ssd130x.c > index a737f650c2bc..7b9f8fc193ac 100644 > --- a/drivers/gpu/drm/solomon/ssd130x.c > +++ b/drivers/gpu/drm/solomon/ssd130x.c > @@ -39,7 +39,6 @@ > > #define DRIVER_NAME "ssd130x" > #define DRIVER_DESC "DRM driver for Solomon SSD13xx OLED displays" > -#define DRIVER_DATE "20220131" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -1784,7 +1783,6 @@ static const struct drm_driver ssd130x_drm_driver = { > DRM_FBDEV_SHMEM_DRIVER_OPS, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .driver_features = DRIVER_ATOMIC | DRIVER_GEM | DRIVER_MODESET, > diff --git a/drivers/gpu/drm/sprd/sprd_drm.c b/drivers/gpu/drm/sprd/sprd_drm.c > index a74cd0caf645..867ee2d8997f 100644 > --- a/drivers/gpu/drm/sprd/sprd_drm.c > +++ b/drivers/gpu/drm/sprd/sprd_drm.c > @@ -23,7 +23,6 @@ > > #define DRIVER_NAME "sprd" > #define DRIVER_DESC "Spreadtrum SoCs' DRM Driver" > -#define DRIVER_DATE "20200201" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -59,7 +58,6 @@ static struct drm_driver sprd_drm_drv = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > }; > diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c > index a6c13318aa0b..46e6b674fa54 100644 > --- a/drivers/gpu/drm/sti/sti_drv.c > +++ b/drivers/gpu/drm/sti/sti_drv.c > @@ -29,7 +29,6 @@ > > #define DRIVER_NAME "sti" > #define DRIVER_DESC "STMicroelectronics SoC DRM" > -#define DRIVER_DATE "20140601" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -143,7 +142,6 @@ static const struct drm_driver sti_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > }; > diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c > index d181d11b277b..40a62c57e04c 100644 > --- a/drivers/gpu/drm/stm/drv.c > +++ b/drivers/gpu/drm/stm/drv.c > @@ -62,7 +62,6 @@ static const struct drm_driver drv_driver = { > .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC, > .name = "stm", > .desc = "STMicroelectronics SoC DRM", > - .date = "20170330", > .major = 1, > .minor = 0, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c > index a7c11b795e98..025b0bdcbfd9 100644 > --- a/drivers/gpu/drm/sun4i/sun4i_drv.c > +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c > @@ -50,7 +50,6 @@ static const struct drm_driver sun4i_drv_driver = { > .fops = &sun4i_drv_fops, > .name = "sun4i-drm", > .desc = "Allwinner sun4i Display Engine", > - .date = "20150629", > .major = 1, > .minor = 0, > > diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c > index 34878f5d2918..4596073fe28f 100644 > --- a/drivers/gpu/drm/tegra/drm.c > +++ b/drivers/gpu/drm/tegra/drm.c > @@ -35,7 +35,6 @@ > > #define DRIVER_NAME "tegra" > #define DRIVER_DESC "NVIDIA Tegra graphics" > -#define DRIVER_DATE "20120330" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > #define DRIVER_PATCHLEVEL 0 > @@ -901,7 +900,6 @@ static const struct drm_driver tegra_drm_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/tidss/tidss_drv.c b/drivers/gpu/drm/tidss/tidss_drv.c > index 53bc219c097f..ee1132d581f5 100644 > --- a/drivers/gpu/drm/tidss/tidss_drv.c > +++ b/drivers/gpu/drm/tidss/tidss_drv.c > @@ -113,7 +113,6 @@ static const struct drm_driver tidss_driver = { > DRM_FBDEV_DMA_DRIVER_OPS, > .name = "tidss", > .desc = "TI Keystone DSS", > - .date = "20180215", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c > index 821d0ba26287..8013f01dbdf0 100644 > --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c > +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c > @@ -481,7 +481,6 @@ static const struct drm_driver tilcdc_driver = { > .fops = &fops, > .name = "tilcdc", > .desc = "TI LCD Controller DRM", > - .date = "20121205", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/drivers/gpu/drm/tiny/arcpgu.c > index 5a0c8a874421..1e570f6f639f 100644 > --- a/drivers/gpu/drm/tiny/arcpgu.c > +++ b/drivers/gpu/drm/tiny/arcpgu.c > @@ -367,7 +367,6 @@ static const struct drm_driver arcpgu_drm_driver = { > .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC, > .name = "arcpgu", > .desc = "ARC PGU Controller", > - .date = "20160219", > .major = 1, > .minor = 0, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c > index 71a1f15d6ac9..89a699370a59 100644 > --- a/drivers/gpu/drm/tiny/bochs.c > +++ b/drivers/gpu/drm/tiny/bochs.c > @@ -680,7 +680,6 @@ static const struct drm_driver bochs_driver = { > .fops = &bochs_fops, > .name = "bochs-drm", > .desc = "bochs dispi vga interface (qemu stdvga)", > - .date = "20130925", > .major = 1, > .minor = 0, > DRM_GEM_SHMEM_DRIVER_OPS, > diff --git a/drivers/gpu/drm/tiny/cirrus-qemu.c b/drivers/gpu/drm/tiny/cirrus-qemu.c > index c0ae316888e2..52ec1e4ea9e5 100644 > --- a/drivers/gpu/drm/tiny/cirrus-qemu.c > +++ b/drivers/gpu/drm/tiny/cirrus-qemu.c > @@ -48,7 +48,6 @@ > > #define DRIVER_NAME "cirrus-qemu" > #define DRIVER_DESC "qemu cirrus vga" > -#define DRIVER_DATE "2019" > #define DRIVER_MAJOR 2 > #define DRIVER_MINOR 0 > > @@ -659,7 +658,6 @@ static const struct drm_driver cirrus_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > > diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c > index 47dbee84d58b..41e9bfb2e2ff 100644 > --- a/drivers/gpu/drm/tiny/gm12u320.c > +++ b/drivers/gpu/drm/tiny/gm12u320.c > @@ -34,7 +34,6 @@ MODULE_PARM_DESC(eco_mode, "Turn on Eco mode (less bright, more silent)"); > > #define DRIVER_NAME "gm12u320" > #define DRIVER_DESC "Grain Media GM12U320 USB projector display" > -#define DRIVER_DATE "2019" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -626,7 +625,6 @@ static const struct drm_driver gm12u320_drm_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > > diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c > index 910279ebbbaa..df263818f45f 100644 > --- a/drivers/gpu/drm/tiny/hx8357d.c > +++ b/drivers/gpu/drm/tiny/hx8357d.c > @@ -199,7 +199,6 @@ static const struct drm_driver hx8357d_driver = { > .debugfs_init = mipi_dbi_debugfs_init, > .name = "hx8357d", > .desc = "HX8357D", > - .date = "20181023", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/ili9163.c b/drivers/gpu/drm/tiny/ili9163.c > index e54ce120692f..62cadf5e033d 100644 > --- a/drivers/gpu/drm/tiny/ili9163.c > +++ b/drivers/gpu/drm/tiny/ili9163.c > @@ -118,7 +118,6 @@ static struct drm_driver ili9163_driver = { > .debugfs_init = mipi_dbi_debugfs_init, > .name = "ili9163", > .desc = "Ilitek ILI9163", > - .date = "20210208", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c > index f322e67f473a..6de44ff69b51 100644 > --- a/drivers/gpu/drm/tiny/ili9225.c > +++ b/drivers/gpu/drm/tiny/ili9225.c > @@ -364,7 +364,6 @@ static const struct drm_driver ili9225_driver = { > DRM_FBDEV_DMA_DRIVER_OPS, > .name = "ili9225", > .desc = "Ilitek ILI9225", > - .date = "20171106", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/ili9341.c b/drivers/gpu/drm/tiny/ili9341.c > index 356c7f107c3e..e55029433509 100644 > --- a/drivers/gpu/drm/tiny/ili9341.c > +++ b/drivers/gpu/drm/tiny/ili9341.c > @@ -155,7 +155,6 @@ static const struct drm_driver ili9341_driver = { > .debugfs_init = mipi_dbi_debugfs_init, > .name = "ili9341", > .desc = "Ilitek ILI9341", > - .date = "20180514", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c > index f5b1d21f7109..093661c771a0 100644 > --- a/drivers/gpu/drm/tiny/ili9486.c > +++ b/drivers/gpu/drm/tiny/ili9486.c > @@ -177,7 +177,6 @@ static const struct drm_driver ili9486_driver = { > .debugfs_init = mipi_dbi_debugfs_init, > .name = "ili9486", > .desc = "Ilitek ILI9486", > - .date = "20200118", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/mi0283qt.c b/drivers/gpu/drm/tiny/mi0283qt.c > index 61e33376fbc9..b6b4664908ae 100644 > --- a/drivers/gpu/drm/tiny/mi0283qt.c > +++ b/drivers/gpu/drm/tiny/mi0283qt.c > @@ -159,7 +159,6 @@ static const struct drm_driver mi0283qt_driver = { > .debugfs_init = mipi_dbi_debugfs_init, > .name = "mi0283qt", > .desc = "Multi-Inno MI0283QT", > - .date = "20160614", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/ofdrm.c b/drivers/gpu/drm/tiny/ofdrm.c > index b27ed3677bfd..cd5916752507 100644 > --- a/drivers/gpu/drm/tiny/ofdrm.c > +++ b/drivers/gpu/drm/tiny/ofdrm.c > @@ -25,7 +25,6 @@ > > #define DRIVER_NAME "ofdrm" > #define DRIVER_DESC "DRM driver for OF platform devices" > -#define DRIVER_DATE "20220501" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -1348,7 +1347,6 @@ static struct drm_driver ofdrm_driver = { > DRM_FBDEV_SHMEM_DRIVER_OPS, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .driver_features = DRIVER_ATOMIC | DRIVER_GEM | DRIVER_MODESET, > diff --git a/drivers/gpu/drm/tiny/panel-mipi-dbi.c b/drivers/gpu/drm/tiny/panel-mipi-dbi.c > index 79d5818cbbe6..4786b8144a9f 100644 > --- a/drivers/gpu/drm/tiny/panel-mipi-dbi.c > +++ b/drivers/gpu/drm/tiny/panel-mipi-dbi.c > @@ -269,7 +269,6 @@ static const struct drm_driver panel_mipi_dbi_driver = { > .debugfs_init = mipi_dbi_debugfs_init, > .name = "panel-mipi-dbi", > .desc = "MIPI DBI compatible display panel", > - .date = "20220103", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gpu/drm/tiny/repaper.c > index 9373063a13fc..52ba6c699bc8 100644 > --- a/drivers/gpu/drm/tiny/repaper.c > +++ b/drivers/gpu/drm/tiny/repaper.c > @@ -917,7 +917,6 @@ static const struct drm_driver repaper_driver = { > DRM_FBDEV_DMA_DRIVER_OPS, > .name = "repaper", > .desc = "Pervasive Displays RePaper e-ink panels", > - .date = "20170405", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/sharp-memory.c b/drivers/gpu/drm/tiny/sharp-memory.c > index d87068126f9b..03d2850310c4 100644 > --- a/drivers/gpu/drm/tiny/sharp-memory.c > +++ b/drivers/gpu/drm/tiny/sharp-memory.c > @@ -107,7 +107,6 @@ static const struct drm_driver sharp_memory_drm_driver = { > DRM_FBDEV_DMA_DRIVER_OPS, > .name = "sharp_memory_display", > .desc = "Sharp Display Memory LCD", > - .date = "20231129", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c > index b3a2fc11dcf0..b47ca2d902d9 100644 > --- a/drivers/gpu/drm/tiny/simpledrm.c > +++ b/drivers/gpu/drm/tiny/simpledrm.c > @@ -31,7 +31,6 @@ > > #define DRIVER_NAME "simpledrm" > #define DRIVER_DESC "DRM driver for simple-framebuffer platform devices" > -#define DRIVER_DATE "20200625" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -1015,7 +1014,6 @@ static struct drm_driver simpledrm_driver = { > DRM_FBDEV_SHMEM_DRIVER_OPS, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .driver_features = DRIVER_ATOMIC | DRIVER_GEM | DRIVER_MODESET, > diff --git a/drivers/gpu/drm/tiny/st7586.c b/drivers/gpu/drm/tiny/st7586.c > index 7bfd4296c1c9..a29672d84ede 100644 > --- a/drivers/gpu/drm/tiny/st7586.c > +++ b/drivers/gpu/drm/tiny/st7586.c > @@ -295,7 +295,6 @@ static const struct drm_driver st7586_driver = { > .debugfs_init = mipi_dbi_debugfs_init, > .name = "st7586", > .desc = "Sitronix ST7586", > - .date = "20170801", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/st7735r.c b/drivers/gpu/drm/tiny/st7735r.c > index 6832ca590127..1d60f6e5b3bc 100644 > --- a/drivers/gpu/drm/tiny/st7735r.c > +++ b/drivers/gpu/drm/tiny/st7735r.c > @@ -160,7 +160,6 @@ static const struct drm_driver st7735r_driver = { > .debugfs_init = mipi_dbi_debugfs_init, > .name = "st7735r", > .desc = "Sitronix ST7735R", > - .date = "20171128", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tve200/tve200_drv.c b/drivers/gpu/drm/tve200/tve200_drv.c > index cb66dbbe2801..65a0d4301160 100644 > --- a/drivers/gpu/drm/tve200/tve200_drv.c > +++ b/drivers/gpu/drm/tve200/tve200_drv.c > @@ -146,7 +146,6 @@ static const struct drm_driver tve200_drm_driver = { > .fops = &drm_fops, > .name = "tve200", > .desc = DRIVER_DESC, > - .date = "20170703", > .major = 1, > .minor = 0, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c > index 6c182b21028e..05b3a152cc33 100644 > --- a/drivers/gpu/drm/udl/udl_drv.c > +++ b/drivers/gpu/drm/udl/udl_drv.c > @@ -78,7 +78,6 @@ static const struct drm_driver driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h > index 1eb716d9dad5..be00dc1d87a1 100644 > --- a/drivers/gpu/drm/udl/udl_drv.h > +++ b/drivers/gpu/drm/udl/udl_drv.h > @@ -26,7 +26,6 @@ struct drm_mode_create_dumb; > > #define DRIVER_NAME "udl" > #define DRIVER_DESC "DisplayLink" > -#define DRIVER_DATE "20120220" > > #define DRIVER_MAJOR 0 > #define DRIVER_MINOR 0 > diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c > index fb35c5c3f1a7..9d8de9146cb0 100644 > --- a/drivers/gpu/drm/v3d/v3d_drv.c > +++ b/drivers/gpu/drm/v3d/v3d_drv.c > @@ -31,7 +31,6 @@ > > #define DRIVER_NAME "v3d" > #define DRIVER_DESC "Broadcom V3D graphics" > -#define DRIVER_DATE "20180419" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > #define DRIVER_PATCHLEVEL 0 > @@ -248,7 +247,6 @@ static const struct drm_driver v3d_drm_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c b/drivers/gpu/drm/vboxvideo/vbox_drv.c > index d9d884aad97f..bb861f0a0a31 100644 > --- a/drivers/gpu/drm/vboxvideo/vbox_drv.c > +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c > @@ -189,7 +189,6 @@ static const struct drm_driver driver = { > .fops = &vbox_fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h b/drivers/gpu/drm/vboxvideo/vbox_drv.h > index e77bd6512eb1..dfa935f381a6 100644 > --- a/drivers/gpu/drm/vboxvideo/vbox_drv.h > +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h > @@ -25,7 +25,6 @@ > > #define DRIVER_NAME "vboxvideo" > #define DRIVER_DESC "Oracle VM VirtualBox Graphics Card" > -#define DRIVER_DATE "20130823" > > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c > index ee5df153c2a6..e88a7ee486c6 100644 > --- a/drivers/gpu/drm/vc4/vc4_drv.c > +++ b/drivers/gpu/drm/vc4/vc4_drv.c > @@ -47,7 +47,6 @@ > > #define DRIVER_NAME "vc4" > #define DRIVER_DESC "Broadcom VC4 graphics" > -#define DRIVER_DATE "20140616" > #define DRIVER_MAJOR 0 > #define DRIVER_MINOR 0 > #define DRIVER_PATCHLEVEL 0 > @@ -222,7 +221,6 @@ const struct drm_driver vc4_drm_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > @@ -244,7 +242,6 @@ const struct drm_driver vc5_drm_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c > index c5e3e5457737..2752ab4f1c97 100644 > --- a/drivers/gpu/drm/vgem/vgem_drv.c > +++ b/drivers/gpu/drm/vgem/vgem_drv.c > @@ -47,7 +47,6 @@ > > #define DRIVER_NAME "vgem" > #define DRIVER_DESC "Virtual GEM provider" > -#define DRIVER_DATE "20120112" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -121,7 +120,6 @@ static const struct drm_driver vgem_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > }; > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c > index e216123ce6a5..6a67c6297d58 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_drv.c > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c > @@ -201,7 +201,6 @@ static const struct drm_driver driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h > index 8328107edf78..f42ca9d8ed10 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h > @@ -45,7 +45,6 @@ > > #define DRIVER_NAME "virtio_gpu" > #define DRIVER_DESC "virtio GPU" > -#define DRIVER_DATE "0" > > #define DRIVER_MAJOR 0 > #define DRIVER_MINOR 1 > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c > index fa3331f612e3..e0409aba9349 100644 > --- a/drivers/gpu/drm/vkms/vkms_drv.c > +++ b/drivers/gpu/drm/vkms/vkms_drv.c > @@ -34,7 +34,6 @@ > > #define DRIVER_NAME "vkms" > #define DRIVER_DESC "Virtual Kernel Mode Setting" > -#define DRIVER_DATE "20180514" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -116,7 +115,6 @@ static const struct drm_driver vkms_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > }; > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > index ded48554568a..1699236fca5a 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > @@ -1634,7 +1634,6 @@ static const struct drm_driver driver = { > .fops = &vmwgfx_driver_fops, > .name = VMWGFX_DRIVER_NAME, > .desc = VMWGFX_DRIVER_DESC, > - .date = VMWGFX_DRIVER_DATE, > .major = VMWGFX_DRIVER_MAJOR, > .minor = VMWGFX_DRIVER_MINOR, > .patchlevel = VMWGFX_DRIVER_PATCHLEVEL > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h > index b21831ef214a..5275ef632d4b 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h > @@ -57,7 +57,6 @@ > > > #define VMWGFX_DRIVER_NAME "vmwgfx" > -#define VMWGFX_DRIVER_DATE "20211206" > #define VMWGFX_DRIVER_MAJOR 2 > #define VMWGFX_DRIVER_MINOR 20 > #define VMWGFX_DRIVER_PATCHLEVEL 0 > diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c > index d6fccea1e083..56d4ffb650da 100644 > --- a/drivers/gpu/drm/xe/xe_device.c > +++ b/drivers/gpu/drm/xe/xe_device.c > @@ -271,7 +271,6 @@ static struct drm_driver driver = { > .fops = &xe_driver_fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/xe/xe_drv.h b/drivers/gpu/drm/xe/xe_drv.h > index d45b71426cc8..d61650d4aa0b 100644 > --- a/drivers/gpu/drm/xe/xe_drv.h > +++ b/drivers/gpu/drm/xe/xe_drv.h > @@ -10,7 +10,6 @@ > > #define DRIVER_NAME "xe" > #define DRIVER_DESC "Intel Xe Graphics" > -#define DRIVER_DATE "20201103" > > /* Interface history: > * > diff --git a/drivers/gpu/drm/xen/xen_drm_front.c b/drivers/gpu/drm/xen/xen_drm_front.c > index 931d855bfbe8..1bda7ef606cc 100644 > --- a/drivers/gpu/drm/xen/xen_drm_front.c > +++ b/drivers/gpu/drm/xen/xen_drm_front.c > @@ -478,7 +478,6 @@ static const struct drm_driver xen_drm_driver = { > .fops = &xen_drm_dev_fops, > .name = "xendrm-du", > .desc = "Xen PV DRM Display Unit", > - .date = "20180221", > .major = 1, > .minor = 0, > > diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c > index e272ecbce78d..b47463473472 100644 > --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c > +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c > @@ -409,7 +409,6 @@ static const struct drm_driver zynqmp_dpsub_drm_driver = { > > .name = "zynqmp-dpsub", > .desc = "Xilinx DisplayPort Subsystem Driver", > - .date = "20130509", > .major = 1, > .minor = 0, > }; > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h > index 1bbbcb8e2d23..1b6e59139e6c 100644 > --- a/include/drm/drm_drv.h > +++ b/include/drm/drm_drv.h > @@ -401,8 +401,6 @@ struct drm_driver { > char *name; > /** @desc: driver description */ > char *desc; > - /** @date: driver date, unused, to be removed */ > - char *date; > > /** > * @driver_features: -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) From xen-devel-bounces@lists.xenproject.org Thu Dec 05 08:01:02 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 08:01:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848973.1263720 (Exim 4.92) (envelope-from ) id 1tJ6nD-0002U5-Ue; Thu, 05 Dec 2024 08:00:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848973.1263720; Thu, 05 Dec 2024 08:00: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 1tJ6nD-0002Ty-Q4; Thu, 05 Dec 2024 08:00:59 +0000 Received: by outflank-mailman (input) for mailman id 848973; Thu, 05 Dec 2024 08:00: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 1tJ6nB-0002Tk-Vu for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 08:00:58 +0000 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2062e.outbound.protection.outlook.com [2a01:111:f403:2009::62e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0d4dcfc9-b2df-11ef-99a3-01e77a169b0f; Thu, 05 Dec 2024 09:00:55 +0100 (CET) Received: from CH2PR18CA0036.namprd18.prod.outlook.com (2603:10b6:610:55::16) by SA3PR12MB8804.namprd12.prod.outlook.com (2603:10b6:806:31f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.12; Thu, 5 Dec 2024 08:00:48 +0000 Received: from CH3PEPF00000016.namprd21.prod.outlook.com (2603:10b6:610:55:cafe::34) by CH2PR18CA0036.outlook.office365.com (2603:10b6:610:55::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.11 via Frontend Transport; Thu, 5 Dec 2024 08:00:47 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by CH3PEPF00000016.mail.protection.outlook.com (10.167.244.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8251.1 via Frontend Transport; Thu, 5 Dec 2024 08:00:47 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 5 Dec 2024 02:00:47 -0600 Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Thu, 5 Dec 2024 02:00: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: 0d4dcfc9-b2df-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jw05rkG7lehNWehSKdCrtzkIQxD/onDEKfW95A431NAclux8vvttH6cyqIlnfrAaRsMhUvjXJMNrfxeKZFymdlvojxXRCFO136Ijb3zckFYvghwF49/ZJALcBWhn3hB9xtT650VDLkLCwoFenkoEqhikqK6ql8Z7HqDCvSNo5hVtzoSoAOBwIx5J8xwU1GJ+Hle23rCcHDqjGhGuP2GssvKDArw/3ApWjPZ/3qBFIcc8GWaOeq26d7af5BJ/r/hyI5+P2TcIVxeNKyIEyacgF/AQg7HUo8Was9EPW/IJ64SvpkzImowYQeXHouWYRkaAeP6PYbBnKvAJBzHuNWcQcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=plQNE6TWr7v7kQSdtLfGstmPpnq1hrQ6jr0kiD+3wJQ=; b=fRxpOl5ViMBwVbmc8/NRNKNXMy5R7kAgOP/8K3lfI8KqfkKnb6AaK7FSDH1Rmrs7Z9TjzHN18ZZ4MQi6X1q94Ru4WFE1Zf0jsk5POb5RtsO7VknUR48+xtS+zoOc+SKQChPSKmD/PErKa0l4u7CTSKwFW6s5puCoyNPDgY1O7H+Ew57JPXCKMb8jDqFWBkclfzhnrh5JmGPksvmSBirZmB+lkjtPS/AcApDjSQo4NYkHRCl+jtR7U0g/A1HHjZSLuM4yazgbutsvzAm9gqRk/pnsL0kIBgmQ+Wt+2nDhTQPJuO4eZRotUj7Dz1V4rEc3qEuLB6g63SiOvWXiCBf6OQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=minervasys.tech smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=plQNE6TWr7v7kQSdtLfGstmPpnq1hrQ6jr0kiD+3wJQ=; b=CuXV1VZJQIEaEfNtJC7d2E4BQWdgpjOTCXKuTnJ5xCvLvHx+BMBoeS5M/rvctmsPw6JVp4D4NQIHKNTfjZcGzgYbRCiDiTsHF7Ox9Xuv058pcyHeXasIDNqyjgrpFfmtnaDIUMlgO1rmK0X75ecCDxsdNKC1a0XHxw7Xeo14kow= 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=SATLEXMB03.amd.com; pr=C Message-ID: <201c8fb0-83d5-4647-ba4e-6c8cf60c0ed5@amd.com> Date: Thu, 5 Dec 2024 09:00:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 01/12] xen/common: add cache coloring common code From: Michal Orzel To: Carlo Nonato , CC: , , Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> <20241202165921.249585-2-carlo.nonato@minervasys.tech> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH3PEPF00000016:EE_|SA3PR12MB8804:EE_ X-MS-Office365-Filtering-Correlation-Id: afeaaed3-5a35-425a-45df-08dd1502eda9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?ZHllcm9YdCtMUi9FYi9ocUdqNHNRekJZdi9vZDRkaGtXb2NVeEZLTkZkNllK?= =?utf-8?B?N0JZK21pakpIaGZ0dU95RlNKaWVwdDNjUUl4N2Fia1lYZmhuYXB1eVEzaDhx?= =?utf-8?B?MjNvZ2UwcnRGODBDQ0FWSnpoZmhtaUZUS2wxR2xGaTZzdWUyYTcyTDJOZ0ti?= =?utf-8?B?TTkyaHZtN1pTQllLUDNmSWdSRmtjZHcrVk5maUZuSHhGZVg3Y2UvcFdKWkpI?= =?utf-8?B?NXF0ZDhJSnpyNWQrV3ZrWlBpbUlRYk01cHNlaU9ERUpSemd2cjdSSHhyT2U0?= =?utf-8?B?NHdNRmdsYklRQWUrSDg1UllDZldoY3hXbTdwWkVMVHBJb0N0S0ZmT1h5K1Nq?= =?utf-8?B?MDVLT1pzdm1DdmRJekx3ay8rRUJsdytHVzRQSm8xT3ZTVVdtZjlzNy93NnAx?= =?utf-8?B?ZGF6cVdmSEhDN2N5eUtKelYxczJ2eUhTbWRqc0N4K3pOayt5elhGUHcrN0Nw?= =?utf-8?B?clhDZjZLOW90TjdtV2JwL2dhYlNEQ2xqZGtnMzRpZE5pc1d4WmZtSnNFOHYz?= =?utf-8?B?YVBkRG4rU3o1U2c0Z21mSmRRbnIzSGtDVUdlcWYrc0d3c1kzdlJSRTEyL1Fn?= =?utf-8?B?bmZxcTROU0Y4UXRxMHVDMUJrcjNxekNtZ3pWOW4yeXQzWHpMUkJzb1lSUGw1?= =?utf-8?B?VWoxZWV5Mnh3aXlyK0Ric0JqWEx0d2JoeTVVTTJJYWFYUUFiYU1RcmpSUmV3?= =?utf-8?B?VWFSajE4RnpMR0hYbHVaZmF2TmV5dERuSStPeFhBa0JsWE4zM2VMTy9JcUFq?= =?utf-8?B?Rk15K1psOUZZWEdVaklYTjcrem43S3hmS05nd3ZuODJBdmpTNWhJM3BuUkFr?= =?utf-8?B?Zi9nNE5zR1RWNFdBZy94VU1aR2V5eFFjL2xIbTdBR0lZaFJVdjR0RDVvcEk1?= =?utf-8?B?N2hTMjdNODY1Y3BPdzl3TlZSMzh0MC9ZNzVEVWx1MW1YNkFrM0xoM0pwUStt?= =?utf-8?B?NE84b1FoUFIzbXRQZlJieVNyWGhoeU8xTVZhVjhEdURLWEl4MUlkMGkxRTJm?= =?utf-8?B?THArUXIreFVkVlBSZUUvVnpTcHFvUFJ1dmZwc0ZVSk1Lc3NPdEFRcnQ4Z25i?= =?utf-8?B?ZW9FblNmQnpZVHFxSFVveUduM3FXc1ZnMElUOHJwemdxc3NqNElzNW5IdCsz?= =?utf-8?B?UTk2S0xuYlZ6QjVLMmh0TFVnVnhRMjFFVjduT0pkbE80OWlSZzFCdEJNaWx3?= =?utf-8?B?SWFMZ1NIKzN3dU9xMGM4Z1cwTnFmcEtCc2RFTExHQ3VQUFJVcWlvNS9DUHVI?= =?utf-8?B?TnpqOFNXTGlwa3JXNHJJVXJ5SFBSbDVqa1Bka0gwTTlKM2ViaXpLOEx6RmNu?= =?utf-8?B?S0Ywdy9QVjBUSXpEWktFKzRMZXg2bFpPV1RSZHVqc0VtU1pVYm5yRlBjd3Jr?= =?utf-8?B?UG91bGpUdmNSOTdvUUhxaXlFN3RjRmxNZWV2N1VTTldtVWNnK0NwclhvaElJ?= =?utf-8?B?VXA5TVR1M3U0cUl3MFlFSHlFTmFRNXZhcjRPUWFqS2toUFN4VStGQjB2enZI?= =?utf-8?B?MTU5SUZTSXJXWDUzL0tDUWVSblNoakg5M21YTGdYMW5TZkFkb1d6TTB2NTdO?= =?utf-8?B?c2E1RFRjaG05dWJCUXMxQWlDR254ZUtXSEZQS1dHTG5Nb2ZTTlVReUhVSmNT?= =?utf-8?B?UkxWa1V6QmhRL3U5Uk9MaUVLS2NNcXgrd2xWSVIxREVOdEtFYll0N3FOZ2JC?= =?utf-8?B?SllhUWNXU202MlR5UlJ2eEFwaGFaMlRhbFhsWVNXdDFQS0UzYzJNTXZ3RnVk?= =?utf-8?B?ZmN3WXN1TjZCNGRoUmpZTFNobmdkNm5oTHNLcnZpNHBSRGN4eHJzSDZvenZZ?= =?utf-8?B?SmNKalVhUWZwSW4xSDluQi9MK3oyYW9nZEZhSUZCOVhxWm1ON3c1ZEtEaW1O?= =?utf-8?B?RmhHNk9PUmRSdHd0OEdXNUZ1RmtZNzNxWlBoTTlqNDA0bVNXQklUaGNXeXBs?= =?utf-8?Q?xfbJvho88BDM9Smik1O0AhpnlzOApkWM?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2024 08:00:47.7108 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: afeaaed3-5a35-425a-45df-08dd1502eda9 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=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH3PEPF00000016.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB8804 On 03/12/2024 10:55, Michal Orzel wrote: > > > On 02/12/2024 17:59, Carlo Nonato wrote: >> >> >> Last Level Cache (LLC) coloring allows to partition the cache in smaller >> chunks called cache colors. >> >> Since not all architectures can actually implement it, add a HAS_LLC_COLORING >> Kconfig option. >> LLC_COLORS_ORDER Kconfig option has a range maximum of 10 (2^10 = 1024) >> because that's the number of colors that fit in a 4 KiB page when integers >> are 4 bytes long. >> >> LLC colors are a property of the domain, so struct domain has to be extended. >> >> Based on original work from: Luca Miccio >> >> Signed-off-by: Carlo Nonato >> Signed-off-by: Marco Solieri >> Acked-by: Michal Orzel > > [...] >> >> +### llc-coloring (arm64) >> +> `= ` >> + >> +> Default: `false` > By default, it is disabled. If CONFIG_ is enabled but ... > > [...] > >> + * -1: not specified (disabled unless llc-size and llc-nr-ways present) > the user doesn't specify any llc-* options, LLC feature should be disabled. > In your case llc_coloring_enabled is -1 and due to 'if ( llc_coloring_enabled ... )' checks > all around the code base, the LLC will be enabled even though it should not. > > You can either set it to 0 if (llc_coloring_enabled < 0) and other llc-* options have not been provided > (this would require modifying this comment to provide different meaning depending on the context) or > you could do sth like that: > > diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c > index 2d6aed5fb4ac..560fe03aa86b 100644 > --- a/xen/common/llc-coloring.c > +++ b/xen/common/llc-coloring.c > @@ -18,8 +18,10 @@ > * 0: explicitly disabled through cmdline > * 1: explicitly enabled through cmdline > */ > -int8_t __ro_after_init llc_coloring_enabled = -1; > -boolean_param("llc-coloring", llc_coloring_enabled); > +int8_t __init opt_llc_coloring = -1; > +boolean_param("llc-coloring", opt_llc_coloring); > + > +bool __ro_after_init llc_coloring_enabled = false; > > static unsigned int __initdata llc_size; > size_param("llc-size", llc_size); > @@ -147,15 +149,17 @@ void __init llc_coloring_init(void) > { > unsigned int way_size, i; > > - if ( (llc_coloring_enabled < 0) && (llc_size && llc_nr_ways) ) > + if ( (opt_llc_coloring < 0) && (llc_size && llc_nr_ways) ) > { > llc_coloring_enabled = true; > way_size = llc_size / llc_nr_ways; > } > - else if ( !llc_coloring_enabled ) > + else if ( !opt_llc_coloring ) > return; > else > { > + llc_coloring_enabled = true; > + > way_size = get_llc_way_size(); > if ( !way_size ) > panic("LLC probing failed and 'llc-size' or 'llc-nr-ways' missing\n"); > > I think that this would be better in terms of readability. > > ~Michal > > On top of my previous comments, attempt to build patch 2 with LLC_COLORING enabled results in a few build errors. In general, this should be avoided to allow bisection. There are 2 issues: - error: invalid use of undefined type 'const struct domain' You need to include xen/sched.h - error: unknown type name 'int8_t' You need to include xen/types.h in a header (regardless of whether you stick to int8_t or bool) - implicit declaration of function 'isb' ~Michal From xen-devel-bounces@lists.xenproject.org Thu Dec 05 08:04:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 08:04:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.848994.1263731 (Exim 4.92) (envelope-from ) id 1tJ6qi-0003OK-Cq; Thu, 05 Dec 2024 08:04:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 848994.1263731; Thu, 05 Dec 2024 08:04: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 1tJ6qi-0003OD-8Y; Thu, 05 Dec 2024 08:04:36 +0000 Received: by outflank-mailman (input) for mailman id 848994; Thu, 05 Dec 2024 08:04: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 1tJ6qg-0003Nm-KC for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 08:04:34 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on20600.outbound.protection.outlook.com [2a01:111:f403:2415::600]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8f51b5f0-b2df-11ef-99a3-01e77a169b0f; Thu, 05 Dec 2024 09:04:32 +0100 (CET) Received: from DM6PR06CA0050.namprd06.prod.outlook.com (2603:10b6:5:54::27) by IA0PR12MB7722.namprd12.prod.outlook.com (2603:10b6:208:432::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.12; Thu, 5 Dec 2024 08:04:26 +0000 Received: from DS1PEPF0001708F.namprd03.prod.outlook.com (2603:10b6:5:54:cafe::e4) by DM6PR06CA0050.outlook.office365.com (2603:10b6:5:54::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.18 via Frontend Transport; Thu, 5 Dec 2024 08:04:26 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by DS1PEPF0001708F.mail.protection.outlook.com (10.167.17.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Thu, 5 Dec 2024 08:04:26 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) 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; Thu, 5 Dec 2024 02:04:25 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 5 Dec 2024 02:04:25 -0600 Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Thu, 5 Dec 2024 02:04: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: 8f51b5f0-b2df-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=d+DuXWGwAyDLLzb3K4J9ilEqWqWHFLT3LsNQV7QgxTX9ZCNkR533YTN5Z21JZNQc9CHKiKpjvdD2FGeuADqr7QgaTCGfBtmtZkmPo44Qkle8eEIjirHKDrWA+5/PSHmD9YPMikdc9hOTuiW9BvV0lNLTdBtWQkb04eTcnThoCTnLIPZtT3bAIvH/eOMnQjefFRHSiwBRJDHiJ9+F49RyH9NwKuQ423c+rLIpkyjTd78HQ/Yp7nqTSrB1cygVGa9GG1OZyTCzEUC8kLNNuAWMvobdM02m49E/SDyIf4e6darQ4WGzsxFJeRJrENbtSofWIRviz8ci2uomjhOYgF+7aA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=94FhIpQYUlFz6e+5J4tHOh3JLjJ47tKls1jUrXSf6bM=; b=TUhjGSxaFtW+6RpNWpGS7Q6ewGmQ7xHZ53wV1IU8jSmfe+looWKe/2Gt4poaSkWT88q6ID3t+gP4ub9afEJpNanV6Ttq1UI4THWjeLhk5w1+gf1pQ+5wsoviK5CHInDu/zsZXXA8dc8RvKwQnF8NEd3LJcfnzCSU+SoigxNDfk3W56NhfWD+xhOvYLLQmhZbgNVQFzJYNqHsdFCVa4Mmusr4SqlUJVjBM+TQqJLUrFb1M3+p5bS5fnrAvPHtCI2QUjX8zfuya4fEbIAdExhAw6e5IhfYX9A1QJLJul0Q1WqsNxuV5DtjiPisUgbhSJB/3wymDZUlaigIkI+c2Pu6XA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=minervasys.tech smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=94FhIpQYUlFz6e+5J4tHOh3JLjJ47tKls1jUrXSf6bM=; b=PgAH/oOLH9T+qIFC1w70qO8qW2jDtLh7ns2iBGWih8EuY/5CN1YOyQWXBZe7y/rakjR1D5aWa0EAE6FiZ7XMLXOvGJCxXUFqkAN5UAtnO33w0ykiQvnnQJN1ZMGJnGAk0kFgnJymHHfn6b1ysWlrCOyIhznHpAVyRHJICh0rTvU= 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=SATLEXMB04.amd.com; pr=C Message-ID: Date: Thu, 5 Dec 2024 09:04:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 02/12] xen/arm: add initial support for LLC coloring on arm64 To: Carlo Nonato , CC: , , "Andrew Cooper" , Jan Beulich , "Julien Grall" , Stefano Stabellini , "Bertrand Marquis" , Volodymyr Babchuk References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> <20241202165921.249585-3-carlo.nonato@minervasys.tech> Content-Language: en-US From: Michal Orzel In-Reply-To: <20241202165921.249585-3-carlo.nonato@minervasys.tech> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB05.amd.com: michal.orzel@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS1PEPF0001708F:EE_|IA0PR12MB7722:EE_ X-MS-Office365-Filtering-Correlation-Id: 14c22335-f511-4534-b70b-08dd15036fef X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|376014|36860700013|7416014|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?OHhtQnNMS3VHUGNBUGdvZExidE1zcnlkeUtxTEg1U2JYbi9TcWNCZFJGRVVG?= =?utf-8?B?MkVPekV0ZWJaeFZWSGFRdml1blRVR2JHRENxbzRLR0Zpdnpyc0RodEdqMmNZ?= =?utf-8?B?UEt0WHVPQUVxYUgzOThBN05CU3k3dC9DcjRDeHhnTjE3cXdXMk1rS2tSaDVr?= =?utf-8?B?ZEVCME9zd29Cdlo2M2Jsa2ozZGcwcmZaOW5hbGZYU1A2M3phaDFkNTJuTEhD?= =?utf-8?B?bUo1NEJINExTMUN4dmlTS242U1NMR1U0b0FkWnJwZTRva3F6MVhGOWV4QWxy?= =?utf-8?B?eGFZYlMxclhiRVN6OUg1NHdadCtlaW5kVTk4YWRwSWJHamdXK0R2bHRKUzZt?= =?utf-8?B?ZmNkaXVGQ3YydURZTHowZ0RKcU1FM3kyUjEvUWVxTHBuOTd4em1DWmpvSS8v?= =?utf-8?B?VGd2Ym5oV09URXcwOEVEY2lyME1kWFlQbVFTNzRvYXUwLy9FL3pxbFdBL1pQ?= =?utf-8?B?WGFWUEE4RVM5Unh2TTBtZk5zNEtxU2tYMjlkUlpUU3BQeVdKUFU4cTIxa21q?= =?utf-8?B?TlhxaUMyZmJaUTdHV3poRDVBSmVCMldYeGdHNEpRQmNNSXhlVlIvcDl3QjFK?= =?utf-8?B?R0FoWjk1RWJYSDFBaGM5SUNGT1Z3NE50SjZ2MHpDL2FqUnJYNjFlUHZtSGpL?= =?utf-8?B?ZWxUMS96UnhIVFFEd1g0TU5WMnlIVXRXS2ZqWENCamJZS0c0eWRHUmNYQWdK?= =?utf-8?B?eHc5bjVnUjJzRTZqSkVzLzBhNCtLV3pJRHNORXZ6ZFE2dWozKzRXc2Y0TUkw?= =?utf-8?B?d2ovaVFtWUQyUHpBRGJpWE5WKzJlOEdqRlMwdzZOYkNrQWRvdTQxemxuS2Ni?= =?utf-8?B?Mk5Mam1IanFxalI2Wlo3ay9ZOGg0KzFyYUxHdjltcGFuOUFkdjdLamFyckI5?= =?utf-8?B?Ym01UUNMTEFWblVtTk9NMlh3alZOY1p2RVdFMjdRa1VFcWdrQ0Q5M09jTy92?= =?utf-8?B?ZHF3Vzd3SGM0bSs4OXdmVkZDWkYwY2U0aE5Vb0xtYklOWTF1M1o3R1BnOVgv?= =?utf-8?B?cjhUQi8rbUQvanBzcTF5Y2lyclU1eG1LOUk2YjFPYkpvVmZMNWY4L1pVWnp1?= =?utf-8?B?cjB1NnRwVGczYU5VcVVmdWRBOXlFeFRVQlFDSThGWTJKUmNSZWFIWFdSV0VO?= =?utf-8?B?bTFRcVU4eWR1Y2QxRXZZZnVRWExEcGZScXBTL0pVNFk3Z2FPWTR4eFE5Y3Z4?= =?utf-8?B?THY3VXRweU5NcnR5a3dSUWhQV0tmM0NOM0lqa2N5UGtkV2p5NmlZblRNUCtD?= =?utf-8?B?a2Y1elFvcXJVZ3NrYlFsTUFVbDlCWmFDZWQrNmtLSGNETCs1bEJrK1ZRUHZv?= =?utf-8?B?c1NTV08rWndxLzFuMURGQ0ZqMlRWeS9ZYW5Oc3pyUkl5Qys1SXJXRmZSU3BQ?= =?utf-8?B?ZzM2WDVpOEEza0M0dnBvU0d2WWl6YVBWbWwwWjh4VllEQnhhWnVySERZSUxp?= =?utf-8?B?ZXRNL0NlV2pOODdaYlVvSWFPS041QTdCQzNtMjBmWHJXRjErTjhnLzdXaUQv?= =?utf-8?B?UGRBN1laU3pCV0lNd3JPTCsvZEM5dEdEWFlvTktLTnJWUU54ZHp3dkhoNlh2?= =?utf-8?B?UTNmMFdrTGIySHJSbjd0MEdzY1VTa3NaMjZqUVB1WjlySlV0QjdpN1VqYUZX?= =?utf-8?B?eXhkc1dqN3FUVzN6NXI4ZjRYc0R4Q1FpM2RQU1F6Ry9CRHFPL1VnVEUrNWYv?= =?utf-8?B?SUdGTlhETHdLOHlpNXpBZ04zT1Y1V3VNd0VsNDcxVUVBMy96Z3Uwbk5zcEpv?= =?utf-8?B?cy82NlZVWjVkYW1US05JbW1hTk91SStIOEhXWmZBWllHMTdqVS8zbWtIbFZI?= =?utf-8?B?d3hDVTU2MWozaWpITys2Wk1ZbUsxUFVOa1RONTVxcHRBVGxvajd3bG9iWVRJ?= =?utf-8?B?Y3pxREkxMFgwdkhNRzBvUEpWUmVUeWJMT3FyazVqT1F1ZFhlZEIxZGY5eUt4?= =?utf-8?Q?kAjOdhJCUPJsp3A2qbfKOrNTrYVhBuSf?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(36860700013)(7416014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2024 08:04:26.2450 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 14c22335-f511-4534-b70b-08dd15036fef 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DS1PEPF0001708F.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB7722 On 02/12/2024 17:59, Carlo Nonato wrote: > > > LLC coloring needs to know the last level cache layout in order to make the > best use of it. This can be probed by inspecting the CLIDR_EL1 register, > so the Last Level is defined as the last level visible by this register. > Note that this excludes system caches in some platforms. > > Static memory allocation and cache coloring are incompatible because static > memory can't be guaranteed to use only colors assigned to the domain. > Panic during DomUs creation when both are enabled. > > Based on original work from: Luca Miccio > > Signed-off-by: Carlo Nonato > Signed-off-by: Marco Solieri > Reviewed-by: Michal Orzel > Acked-by: Jan Beulich [...] > + isb(); Attempt to build this patch with LLC_COLORING=y results in: error: implicit declaration of function 'isb' You need to include Please, always try to make sure that each patch can be built successfully. ~Michal From xen-devel-bounces@lists.xenproject.org Thu Dec 05 09:40:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 09:40:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849010.1263740 (Exim 4.92) (envelope-from ) id 1tJ8LY-0000tj-4I; Thu, 05 Dec 2024 09:40:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849010.1263740; Thu, 05 Dec 2024 09:40:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJ8LY-0000tc-1L; Thu, 05 Dec 2024 09:40:32 +0000 Received: by outflank-mailman (input) for mailman id 849010; Thu, 05 Dec 2024 09:40: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 1tJ8LW-0000tU-Kr for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 09:40:30 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on20619.outbound.protection.outlook.com [2a01:111:f403:2413::619]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f531686f-b2ec-11ef-a0d5-8be0dac302b0; Thu, 05 Dec 2024 10:40:28 +0100 (CET) Received: from MW4PR03CA0162.namprd03.prod.outlook.com (2603:10b6:303:8d::17) by DM4PR12MB6134.namprd12.prod.outlook.com (2603:10b6:8:ad::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Thu, 5 Dec 2024 09:40:23 +0000 Received: from CO1PEPF000044F7.namprd21.prod.outlook.com (2603:10b6:303:8d:cafe::d9) by MW4PR03CA0162.outlook.office365.com (2603:10b6:303:8d::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.17 via Frontend Transport; Thu, 5 Dec 2024 09:40:23 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CO1PEPF000044F7.mail.protection.outlook.com (10.167.241.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8251.1 via Frontend Transport; Thu, 5 Dec 2024 09:40:22 +0000 Received: from SATLEXMB04.amd.com (10.181.40.145) 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; Thu, 5 Dec 2024 03:40:21 -0600 Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Thu, 5 Dec 2024 03:40:19 -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: f531686f-b2ec-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=h+9K7ypO0yIMGKnTkU6IkuRqqcEdwoD2nReLD2GQvjR7Fi1oCkASTQsSlePNdwMVNYEAp1Qx8hR///eTrFVOJBKDwIaeBZ1ttaM43G2q6anPe/V8P1BluGQF/lTB+UMlwbdMh/RrEjcyaGU8D8murW82QynngeWtsGrAYojv9oO6NdcRT9zMwzZRuCVfXLZN08Qr2Tt7G15K0SAm4Vd/TvpdveoP1peWwiAL3K68j2nqlNbTHWmVUFp40lo82DJfsY4AwUnpvF1hc2X7zmZSVfhx2EQQhrQUYM6j35Ze7bGDHfQNVzcBv4wlXOTgvFnxapBVkFLSZ/1e/UwfX87VIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hznBQeb1ExTflNfXH0aGJrt9LW+eNoot1BZVA6crNNY=; b=QVC1s6UFBocKB5UC+Woi0zve5SrcQVlCrR1gBAbyEGIufFbfL4Z5yjiLJab5ppdelM553xuCzSEjUOdojOP0AgfEa7WyqBh/a7Ej84hRngCS3qWcZULGs/GRD4aCVFL5IYVO3IdxCVyIsUTJBwBximS5WFYX6LNLQOKaYFjv/x8KkXAFvKO7BKIIDzez+tnWc5UCxQJAjYm0BtOW1AUAE4YvgHQ7IDT5kj8Si3GRWtuVWjUB67bIovOTAsfsGqzAFPd75fW0Kne1YxqPVjFRJ/ikwEeCURKnM36KBWqv9rBcOSaN/Pru02GpDx954ZXWnewJ+BMMnlIgEA+T3eGy/w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=minervasys.tech smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hznBQeb1ExTflNfXH0aGJrt9LW+eNoot1BZVA6crNNY=; b=G2U61Ee6mlKvyIZrV0c0g3CJ9SuEFw2wG+duTqygVY+oaR6z+gkDUk1Dal6hL7xfw9xTp1qcuNbqAnNiSxRePgmHqaIjwjX69CJePHgw+Yb31v2wUQIO4GcuNk5TsCvXCGsKjxPxpLlqVOKwOrhe1qkjeuM6/AUlpfAVN00qXcc= 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=SATLEXMB04.amd.com; pr=C Message-ID: Date: Thu, 5 Dec 2024 10:40:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 03/12] xen/arm: permit non direct-mapped Dom0 construction To: Carlo Nonato , CC: , , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> <20241202165921.249585-4-carlo.nonato@minervasys.tech> Content-Language: en-US From: Michal Orzel In-Reply-To: <20241202165921.249585-4-carlo.nonato@minervasys.tech> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PEPF000044F7:EE_|DM4PR12MB6134:EE_ X-MS-Office365-Filtering-Correlation-Id: 290108a0-6c05-40cf-9787-08dd1510d6d0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?MGlEYkFaWkxjeWxUYmdlUzAvaHlTdjZMVDR0MERHdCtVc0dNbC9oWmhGcWgw?= =?utf-8?B?L1lmZG15Umxpbm9kNWN1c1N2WDBsQldlcUxLaDFJMzdaT0tJa0dhaXVtQlo1?= =?utf-8?B?aDUva2hmU3lRczh5Zy9QbGJnK201MXY1R24rVGswbzk3bEgxa3kwY0UvSUJs?= =?utf-8?B?Nkk5TlFsRTBZTVpGdjFwTWJwU25Uekg0d0s3emp2azF2Q2JGdDZPbGFUZXJn?= =?utf-8?B?dVYrVmRuM1V6ejJ5QVNMS0JodXloY1huNytjaDZTOFcvaWl2Z2pJcTVzODdW?= =?utf-8?B?Skl6K3MwT1Y1clY0WDZVbERyMXl1N3lPOEtUa09ZVlk2SHFKV1N0emRUd1pW?= =?utf-8?B?eDVSbk1xMkJRRVBhVWRENGNJY1A1a1FjMUhLRXZSTERWa2NZdGdoRGlFcGhu?= =?utf-8?B?aU5zWWlaTjhNVmsySzllYWhwMW9lSDNkYkFnUlZob1FxMERXaUd3b0FpdWNH?= =?utf-8?B?VEg5cSswaXpGdmU3NEhUby9FdFNqMnhqT2VIY2kvOTVPN2RsUElYcU0vMkpC?= =?utf-8?B?OEdKQXRhRk9Hb3pXZjRHVmFhZUVsL0FWTnphOFAzNTBpNjlPakgyZ3czL2FK?= =?utf-8?B?OXNiZ3RDeUlzMEFxbWZJV0pyaGlaSG5YVHZ6NGV1TkQxQ2pZRDVsd3dnQ3VX?= =?utf-8?B?cFVhV0NST3pER2p0aEx0M295QUc0WGVvNUxiaVowb05Dcm1KclRCaWdGVmMz?= =?utf-8?B?dk01L3M0ZHc0ZVYramJOOW5SYzRuUjB4UUQ4YkRzeWlCdkJZWnE4S0M1OHN1?= =?utf-8?B?SW5HWlErTVZsZU5CUmFmMXdjaUJDUHNRcXExVnd2WlFmaEZaVUJueDEwSXMw?= =?utf-8?B?Wmh1cXNjeTZyS0c5L0xjcURtQUtRT2JkMVh5ai9qU0FGMDVJVXI5SmN3ckl6?= =?utf-8?B?ZWVBWURiMVI4QkZqQ3A5cjdjRFhMRFlFTCtKeER4R1NnOXdaRG1Vd1hnR1c3?= =?utf-8?B?QkoyQXpzWllSa0Y5c2Z2VGlDQUFRZU1PanVhSytKM1c3YllpalhNMGhiVDk1?= =?utf-8?B?QUZKU3ZmSXdyNmN0S3VoM0w1RkxGeGF1RVRqYkM0NGFhYytMU3FaT0liZlZu?= =?utf-8?B?ckRyaUtoUzRFZlFXUHRGSnhRWFhKaWxqYjZDL2pRMEdxd3VpSHJrZWtEV3R4?= =?utf-8?B?elcwbFV4aXhQTmc5QWdtbE9wU0pkOU0vcjVldUJyMHp1TzdoeFdkM1BzdSsw?= =?utf-8?B?WDluK1R3M0hjaCtDR0pqam5mWHBCYjZmeXVmMk1Va0FwVC9OZEdLczlKT3NS?= =?utf-8?B?N3lJRmhOSk02ZVppM2UyN1NIRXUrZkdOM2F0cTVDLzcraGw0UEI1N3JzcDNV?= =?utf-8?B?TU1UTC9vSmtJNmZEZXdGbDVCZTl6bUNnUldySkFnb3QrUHJoVVNsU0Y5NHh6?= =?utf-8?B?Z1RFOGMyNkwyWXRrb1QzVHRFa2ExbkUzaWFRM1hweStnUkk2dVZ1M1Fib29U?= =?utf-8?B?TG9jbFlZNVFyeWNkNjZ2V2ZZOXpQVk1TYk8zS3NSWGp1cUJMcS9zMElpR09a?= =?utf-8?B?bGdzK2ozbkp4NFo2M040OWQ3SGVDVWtoV0hwam1pNE9xZjRya1o1ZWU4REcx?= =?utf-8?B?QWFUbFhBR3VHK3VCU2lxQy9UbUMwSU5EQ2JpbC9ySVBPUnk1NUVrN1dXU3Zl?= =?utf-8?B?TCtHRGdabTUyVzV2RGhVZkV2QnQxR01SMEIwcFFLcHYycUJlMmVPU29MY0ZX?= =?utf-8?B?OVp0WWluRmNNd2hPWndhanpkbmNOb1R0clJlaUpFRUZaSnBodlJVUEdiRWY2?= =?utf-8?B?YXI2L29oUkN5TDhSYmNob2pMQWNDT1BBcnpuY1YzbjJnL0FqaFNEV05TdHha?= =?utf-8?B?NXRhdFM2YmdiWGlaQ08yV2xiSk9kcWltcmJtbzNseVB1RVBsbngyNWdmMEJY?= =?utf-8?B?WU1qbXljd2Q3Nnp4NS9QMmlPMUR3clBaZVBCZ29wdXBUNHc9PQ==?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2024 09:40:22.2414 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 290108a0-6c05-40cf-9787-08dd1510d6d0 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CO1PEPF000044F7.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6134 On 02/12/2024 17:59, Carlo Nonato wrote: > > > Cache coloring requires Dom0 not to be direct-mapped because of its non > contiguous mapping nature, so allocate_memory() is needed in this case. > 8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a separate module") > moved allocate_memory() in dom0less_build.c. In order to use it > in Dom0 construction bring it back to domain_build.c and declare it in > domain_build.h. > > Take the opportunity to adapt the implementation of allocate_memory() so > that it uses the host layout when called on the hwdom, via > find_unallocated_memory(). > > Signed-off-by: Carlo Nonato > --- > v11: > - GUEST_RAM_BANKS instead of hardcoding the number of banks in allocate_memory() > - hwdom_ext_regions -> hwdom_free_mem in allocate_memory() > - added a comment in allocate_memory() when skipping small banks > v10: > - fixed a compilation bug that happened when dom0less support was disabled > v9: > - no changes > v8: > - patch adapted to new changes to allocate_memory() > v7: > - allocate_memory() now uses the host layout when called on the hwdom > v6: > - new patch > --- > xen/arch/arm/dom0less-build.c | 44 ----------- > xen/arch/arm/domain_build.c | 97 ++++++++++++++++++++++++- > xen/arch/arm/include/asm/domain_build.h | 1 + > 3 files changed, 94 insertions(+), 48 deletions(-) > > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c > index d93a85434e..67b1503647 100644 > --- a/xen/arch/arm/dom0less-build.c > +++ b/xen/arch/arm/dom0less-build.c > @@ -49,50 +49,6 @@ bool __init is_dom0less_mode(void) > return ( !dom0found && domUfound ); > } > > -static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo) > -{ > - struct membanks *mem = kernel_info_get_mem(kinfo); > - unsigned int i; > - paddr_t bank_size; > - > - printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n", > - /* Don't want format this as PRIpaddr (16 digit hex) */ > - (unsigned long)(kinfo->unassigned_mem >> 20), d); > - > - mem->nr_banks = 0; > - bank_size = MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem); > - if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM0_BASE), > - bank_size) ) > - goto fail; > - > - bank_size = MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem); > - if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM1_BASE), > - bank_size) ) > - goto fail; > - > - if ( kinfo->unassigned_mem ) > - goto fail; > - > - for( i = 0; i < mem->nr_banks; i++ ) > - { > - printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n", > - d, > - i, > - mem->bank[i].start, > - mem->bank[i].start + mem->bank[i].size, > - /* Don't want format this as PRIpaddr (16 digit hex) */ > - (unsigned long)(mem->bank[i].size >> 20)); > - } > - > - return; > - > -fail: > - panic("Failed to allocate requested domain memory." > - /* Don't want format this as PRIpaddr (16 digit hex) */ > - " %ldKB unallocated. Fix the VMs configurations.\n", > - (unsigned long)kinfo->unassigned_mem >> 10); > -} > - > #ifdef CONFIG_VGICV2 > static int __init make_gicv2_domU_node(struct kernel_info *kinfo) > { > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > index 2c30792de8..2b8cba9b2f 100644 > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -416,7 +416,6 @@ static void __init allocate_memory_11(struct domain *d, > } > } > > -#ifdef CONFIG_DOM0LESS_BOOT > bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size, > alloc_domheap_mem_cb cb, void *extra) > { > @@ -508,7 +507,6 @@ bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn, > > return true; > } > -#endif > > /* > * When PCI passthrough is available we want to keep the > @@ -1003,6 +1001,94 @@ out: > return res; > } > > +void __init allocate_memory(struct domain *d, struct kernel_info *kinfo) > +{ > + struct membanks *mem = kernel_info_get_mem(kinfo); > + unsigned int i, nr_banks = GUEST_RAM_BANKS; > + paddr_t bank_start, bank_size; Limit the scope > + struct membanks *hwdom_free_mem = NULL; > + const uint64_t bankbase[] = GUEST_RAM_BANK_BASES; > + const uint64_t banksize[] = GUEST_RAM_BANK_SIZES; Limit the scope > + > + printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n", > + /* Don't want format this as PRIpaddr (16 digit hex) */ > + (unsigned long)(kinfo->unassigned_mem >> 20), d); > + > + mem->nr_banks = 0; > + /* > + * Use host memory layout for hwdom. Only case for this is when LLC coloring > + * is enabled. > + */ > + if ( is_hardware_domain(d) ) > + { > + ASSERT(llc_coloring_enabled); This patch does not build because of declaration not being visible. You must include . > + > + hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank, > + NR_MEM_BANKS); > + if ( !hwdom_free_mem ) > + goto fail; > + > + hwdom_free_mem->max_banks = NR_MEM_BANKS; > + > + if ( find_unallocated_memory(kinfo, hwdom_free_mem) ) My remarks for the use of find_unallocated_memory() 1:1 have not been addressed. You did not even change the comments inside the function. The problem is that the function is specifically designed for finding extended regions and assumes being called at certain point i.e. dom0 RAM allocated, gnttab region allocated, etc. My opinion is that we should attempt to make the function generic so that in your case you can choose which regions to exclude, define even your own function to grab free regions (at the moment add_ext_regions grabs banks >= 64M but you still discards banks >= 128M, so it's a bit wasteful. My very short attempt to make the function as generic as possible in the first iteration: https://paste.debian.net/1338334/ For coloring, you could define your own add_free_regions and only pass RSVD and GNTTAB banks to be excluded. As said before, I still wait for other Arm maintainers to provide their own opinion. ~Michal From xen-devel-bounces@lists.xenproject.org Thu Dec 05 10:56:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 10:56:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849031.1263749 (Exim 4.92) (envelope-from ) id 1tJ9WW-0002fz-IC; Thu, 05 Dec 2024 10:55:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849031.1263749; Thu, 05 Dec 2024 10:55: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 1tJ9WW-0002fs-Fh; Thu, 05 Dec 2024 10:55:56 +0000 Received: by outflank-mailman (input) for mailman id 849031; Thu, 05 Dec 2024 10:55:55 +0000 Received: from [94.247.172.50] (helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJ9WV-0002fg-3u for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 10:55:55 +0000 Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [2a00:1450:4864:20::543]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 790ce410-b2f7-11ef-99a3-01e77a169b0f; Thu, 05 Dec 2024 11:55:43 +0100 (CET) Received: by mail-ed1-x543.google.com with SMTP id 4fb4d7f45d1cf-5d0bf6ac35aso1007611a12.1 for ; Thu, 05 Dec 2024 02:55:43 -0800 (PST) Received: from ?IPV6:2a02:1748:f7df:8cb1:b126:7c76:ed31:81e6? ([2a02:1748:f7df:8cb1:b126:7c76:ed31:81e6]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa62608d3bdsm74204466b.148.2024.12.05.02.55.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Dec 2024 02:55: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: 790ce410-b2f7-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1733396142; x=1734000942; 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=aYkIntcAJdP3iY1JitxN1xpkQ3Q2ZauFSEVV36awBKc=; b=QI6ifW5TW/uidWMUN3SsxRv3ROthYInAIxqveINiU8iWNPbv5IbpfNSUJXuci+97UW QZ5wIcorqupncFdQhTsDA1aE5LlHmG3elYu+FytNE1wsvr72nZUQ0eUZl95CP9qKBeZo nz+lfoMcZDft26yLdNtLOCgF9v1c8gOpqMaao= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733396142; x=1734000942; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aYkIntcAJdP3iY1JitxN1xpkQ3Q2ZauFSEVV36awBKc=; b=u17qZW0syTQibmNc677ssbM3rgcIV9hgg2UqTnTLErSXCuthS3ex3TBm1K8v0ULlKh WtU+s5wat/aXkaYgHIhrIzNujFvGoMWF0sP0O9rJhdfdZOeL9mslXSbRz3r+QijksUUO QrJkhgNRJa6N+ZoLTqa+ul9/mmq2qFwduj91oUZ5Q+iFAzRjOFR9u9TZ0eEUkTTXd1Gw M9Px707tbSgtzi+NzjJ+jhxcwqcvV7vBAM/G0vyC6gAtqV7BNAjgPQ1Is0MnQArK38P6 /3sabMnFXwYEAL9Wd3/fh63wwEStiykf0Cn2l2ih72VXxR5ifPRB3MAxQY/haYyJA6oa IgbA== X-Forwarded-Encrypted: i=1; AJvYcCXl1UQD+VEzGdXqXIoPqu3JKwwWINpGboxnx6uyq9t2YHSlBXWQgD5pZJho/aHtYp+KB4xGBfLnppU=@lists.xenproject.org X-Gm-Message-State: AOJu0YzbZ7J35GBUmf09cLhpmgn37yuvkbcEqZ3iIBrhjttHjBFRcR08 78PKQYR5qTlwCzW7Hy9S/81pYIiuUnqByXZ9nWfrsSONO3FCOz9QgXVLgf3MQEU= X-Gm-Gg: ASbGncufrcMyX5vkE/WTfPlAIhss756njtVvPN5Ca76PFEjqgOAbmVdQ4j/LkgqNGEs ATX6UrggxA/xJljv9KgGnk8oq/etPTGTtizj5W/UTvgc4ypW0xazDi+06rl07+YWIn9xpBkH2t0 OdK5/5Z4vsUk8TDTUVdNMVRx3C1pz+4EjTItckk1SpYtWTeZFwAyFm/D+ZhDBot928MrM4Z6R5q uEmHfqH/FCayinvjXxFI6UFAPCiK+V0QXlmR06gKWjAy25Q+2aGfUtQIZTPDpAdqdoFKnSgNcWg qtRQ4W9lZBsmii2CXrbdBufBTCsc5sIfxZdR+SM= X-Google-Smtp-Source: AGHT+IHDXSQi5DDGJN4cP2T3KVRLw6370SQqMBJuH5twFQLA6BsGe5yD/3ZvUudcnT44HadlTl/HyA== X-Received: by 2002:a05:6402:3511:b0:5d0:ccce:34b2 with SMTP id 4fb4d7f45d1cf-5d10cb99fcfmr14087068a12.29.1733396142480; Thu, 05 Dec 2024 02:55:42 -0800 (PST) Message-ID: <3f527685-e1bf-4a87-8986-2b9620d14646@cloud.com> Date: Thu, 5 Dec 2024 11:55:39 +0100 MIME-Version: 1.0 User-Agent: Thunderbird Daily Subject: Re: [RFC PATCH] SYSCTL_numainfo.memsize: Switch spanned to present memory Content-Language: en-US To: Jan Beulich Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <10466e8c29b5f69774915bcf6562985c75e98bb7.1733224306.git.bernhard.kaindl@cloud.com> <0299582c-7261-4947-a2ac-bf3d62ccac14@suse.com> From: Bernhard Kaindl In-Reply-To: <0299582c-7261-4947-a2ac-bf3d62ccac14@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 03/12/2024 12:37, Jan Beulich wrote: > On 03.12.2024 12:12, Bernhard Kaindl wrote: >> This the 2nd part of my submission to fix the NUMA node memsize >> retured in xen_sysctl_meminfo[].memsize by the XEN_SYSCTL_numainfo >> hypercall to not count MMIO memory holes etc but only memory pages. >> >> For this, we introduced NODE_DATA->node_present_pages as a prereq. >> With the prereq merged in master, I send this 2nd part for review: >> >> This RFC is for changing the value of xen_sysctl_meminfo[]->memsize >> from NODE_DATA->node_spanned_pages << PAGE_SHIFT >> to NODE_DATA->node_present_pages << PAGE_SHIFT >> for returing total present NUMA node memory instead of spanned range. >> >> Sample of struct xen_sysctl_meminfo[].* as presented by in xl info -n: >> >> xl info -n: >> [...] >> node: memsize memfree distances >> 0: -> 67584 <- 60672 10,21 >> 1: 65536 60958 21,10 >> >> The -> memsize <- marked here is the value that we'd like to fix: >> The current value based node_spanned_pages is often 2TB too large. >> >> We're currently not using these often false memsize values in XenServer >> according to my code review and and Andrew seemed to confirm this as well. >> >> I think that the same is likely true for other Xen toolstacks, but of course >> to review this change or propose an alternaive is the purpose of this RFC. >> >> Thanks, >> Bernhard > > All of the above reads like a cover letter. What's missing is a patch > description, part of which would be to clarify whether the field is > indeed unused except for display purposes, or why respective users would > at least not regress from this change. What's also unclear is what > comments you're actually after (i.e. what question(s) you want to have > answered), seeing this is tagged RFC. [...] > Jan Hi Jan! The answer I'm looking for is which users to check, or to check with. For example, I know that Xapi can use xen_sysctl_meminfo[].memfree to get a preference about the NUMA node use use when creating a domain (when the new mode `numa_affinity_policy.best_effort` is enabled): https://xapi-project.github.io/new-docs/toolstack/features/NUMA/ A potential use of xen_sysctl_meminfo.memsize in Xen toolstacks is less clear to me: The only potential use would be if some Xen toolstack would not like to solely rely on [nid].memfree for NUMA placement. The question is if there are other NUMA aware toolstacks besides Xapi, that would try to use it for e.g. planning the placement of domains. My in the Xapi and Xen repos only turned up a debug printf() in xen-api's xen-api/xenopsd and in xen only the output of xl info -n. It seems questionable to me that any other toolstacks would rely on it, especially as the value it returns currently is offset even 2GB on some machines. I'd expect that this bug would have affected code using it. The answers I am looking for are acknowledgements of that or references which users might use .memsize currently (that could be affected). Alternatively, I'd hope to get an idea what would be the method to create a new revision of the numainfo hypercall: I guess it would be to add a new #define XEN_SYSCTL_numainfo_v2, and if v2 is called, return [].memsize using [nid].node_present_pages instead? Kind regards, Bernhard From xen-devel-bounces@lists.xenproject.org Thu Dec 05 12:52:53 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 12:52:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849057.1263759 (Exim 4.92) (envelope-from ) id 1tJBLT-0008Hf-6W; Thu, 05 Dec 2024 12:52:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849057.1263759; Thu, 05 Dec 2024 12:52: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 1tJBLT-0008HY-44; Thu, 05 Dec 2024 12:52:39 +0000 Received: by outflank-mailman (input) for mailman id 849057; Thu, 05 Dec 2024 12:52:38 +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 1tJBLS-0008H9-8G for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 12:52:38 +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 cd247fc1-b307-11ef-99a3-01e77a169b0f; Thu, 05 Dec 2024 13:52:36 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4349f160d62so6269185e9.2 for ; Thu, 05 Dec 2024 04:52:36 -0800 (PST) Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-434da0dba72sm22986425e9.26.2024.12.05.04.52.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Dec 2024 04: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: cd247fc1-b307-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1733403155; x=1734007955; 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=+Q1KHN55W4zex0BzA/hEEwzfw8yNZL1/Gry8jV5gORE=; b=UGiSLLg8/7A5HKMiTYtCKsHHjV0jP/tJukBbnOruLoto7mLUfPKg3aiUZFI/DJcnOj 8GSJkuKtJz4NxeZlehyxpb7flcnf88dn3Afp+lTeVJZAdiBDzeJij8toVFIr0tpdZQX4 Q4eWumrprx8gyeifgPJA8XrYSQ1M3+eCjP1IA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733403155; x=1734007955; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+Q1KHN55W4zex0BzA/hEEwzfw8yNZL1/Gry8jV5gORE=; b=HhF4NnIH7j3SdHRtLX4s9GMKDk/aa9wVBYO15k3xG2+Wzg2HKru/lSKgnOtrPIQhRQ 47oQV5B+hbUIfZdJpDpfZHDCh0e0M3thoAYwt+vv1a2cRY6X734Hjj2r3pYUm/GXmA3p bHiyVMg4Z8DJ21ZCTxudl175e9u449A6U2E3rNmKeXu4WpoZ3xNaG9BpOMBZiHEDGENo N/FhD1cHcSm7pAPAAsJGTYJHvJfd8vWO994B/aS1fu3otmRn3NZfKihF58I9VfdyE6JG vL6T59lDWj4lnwPlLrymoYBWTp5ed0jnEwG34+pQ8vipCVUksXr8h5T7DOZrPbXenV/b rdOQ== X-Gm-Message-State: AOJu0YxntJCNKDKy0iBDbmxlNUweiRzdpxYkvzsWSw6ibuzm7Nux8XUz QbO5tpwCaeG5d/BjNol4x0+dk/QH74Y27ej6GeayZc9YC9raw5g+Wxz+7nyefpM= X-Gm-Gg: ASbGncur48gZfpoRkvwV9zL2ShOVgFnbOLerP8t2lCL/s3fpbFkfpC74ExltVCl4HI1 TfCaW87tLeaud1AQqwDsYdClBDEC4kijfwRD4R1wdfzyLSZmbyz0bIv0PGOFogRHuL8OFc53WS/ foyD/bVwcM+Xz8SHAkzGVTWRFBZlNKdFGjbXxpB5BHu6mV6eOMWLoXRsAPzyYoCyfURRiisa+X8 KTi4eIs6PowZnrmtNOfA+P0/DNOzh5b6jTyRtwWbDq+catDeaqPuCL5FTdiHhde1o2jvBNN4heW LKo8WFm+vOa3AQ== X-Google-Smtp-Source: AGHT+IGa9dKbUiXdIj3sMXTjO0GpRFLqxxzjpi/m6iHwgg7vqlkLswu39YBDArba7vLAskTMwJNVAA== X-Received: by 2002:a05:600c:1c0e:b0:434:a802:e99a with SMTP id 5b1f17b1804b1-434d09b1590mr92873955e9.4.1733403155570; Thu, 05 Dec 2024 04:52:35 -0800 (PST) Message-ID: <7de284f9-8266-4c74-9390-902e29703291@citrix.com> Date: Thu, 5 Dec 2024 12:52:34 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/4] xen: common: add ability to enable stack protector To: Volodymyr Babchuk Cc: "xen-devel@lists.xenproject.org" , Jan Beulich , Julien Grall , Stefano Stabellini References: <20241130010954.36057-1-volodymyr_babchuk@epam.com> <20241130010954.36057-3-volodymyr_babchuk@epam.com> <4f2f949b-a53e-4a79-8084-d374cabc109e@citrix.com> <87o71q4xb7.fsf@epam.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <87o71q4xb7.fsf@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05/12/2024 3:34 am, Volodymyr Babchuk wrote: >>> diff --git a/xen/common/stack-protector.c b/xen/common/stack-protector.c >>> new file mode 100644 >>> index 0000000000..b258590d3a >>> --- /dev/null >>> +++ b/xen/common/stack-protector.c >>> @@ -0,0 +1,10 @@ >>> +// SPDX-License-Identifier: GPL-2.0-only >>> +#include >>> +#include >>> + >>> +unsigned long __ro_after_init __stack_chk_guard; >>> + >>> +void __stack_chk_fail(void) >> asmlinkage.  This MISRA check is now blocking in Eclair. > I can see what we might want to mark it as "noreturn", but I don't > understand why you want to use asmlinkage. It is not called from > assembly. It's not really about "called from assembly", as "called from something Eclair can't see". There's no declaration of __stack_chk_fail() (Rule 8.4 violation), and no visible callsites (Rule 2.1 violation). asmlinkage is an annotation that Eclair knows about, for the purpose of identifying C construct such as this. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Dec 05 14:08:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 14:08:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849072.1263769 (Exim 4.92) (envelope-from ) id 1tJCWo-0008Ky-EK; Thu, 05 Dec 2024 14:08:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849072.1263769; Thu, 05 Dec 2024 14:08:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJCWo-0008Kr-B9; Thu, 05 Dec 2024 14:08:26 +0000 Received: by outflank-mailman (input) for mailman id 849072; Thu, 05 Dec 2024 14:08: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 1tJCWm-0008Kl-If for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 14:08:24 +0000 Received: from mail180-17.suw31.mandrillapp.com (mail180-17.suw31.mandrillapp.com [198.2.180.17]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 61d1cf6a-b312-11ef-a0d5-8be0dac302b0; Thu, 05 Dec 2024 15:08:21 +0100 (CET) Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail180-17.suw31.mandrillapp.com (Mailchimp) with ESMTP id 4Y3x7R5VR8zRKX5dV for ; Thu, 5 Dec 2024 14:08:19 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id fa438506577d428fa8d740685fae2d5a; Thu, 05 Dec 2024 14:08: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: 61d1cf6a-b312-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1733407699; x=1733668199; bh=owLWFM0WcMlsum23q/+BIpROAYWCco6AogDN+VAoWe4=; 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=Qu4aSn2eq6ABinoCRdDr9sCUlqd0W70dYXdbIOVzD3QZoaaz3htLvqApVwGRyYCF0 XwrWDUYEKOD6PwR6aLzSGUauu5E2ST+Gq1A+EacET93jGCAF8mOuvTpj53OdNs9E02 U62nRvT56VCS8h0sp9dLI94kUHgp8orAZbl5g7TZIw9ujv2xytYz8E3YejqVRV49Z0 a7RczXvpkUASLaChwvpv1dlAcYYy5cPsc5gTgEASRKt2SWCXF3LhO0L5UyUQm9FEEc rZy5uwKNuWU+O7C/HLFTvm8FCLPRLWH3whlXDIi6YIpXd2mDIOPEebWJIH+ytkXofB PlK/mgXhp9Wvg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1733407699; x=1733668199; i=anthony.perard@vates.tech; bh=owLWFM0WcMlsum23q/+BIpROAYWCco6AogDN+VAoWe4=; 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=Xi/J6u5KiqhfhkkyQ8DvIQJwll4M0aC2WCnP7aNp3TZZ44dMeEj8D0zVdw/6I/+XK hrT7G6yE3WabpDaCntnQwtSCQdSrw9EUUUqMZuOG9D906FCCXA/yt7GRnzRHRftlEB DKlMn0am+0Q2Q8+JfGjqeJ7ZnyeA9Z8vq2nUgLfu+IOEgl4fOjmjbIAOJOF/9leIpu Y7Ghy8cziE5LL3IemVsaE2JDSjMOzYn5J5Yi5f4mVXCPz+MrrgIJQ9ovVwYbuaoKH0 94beHc877O/RUUKtRsaj8iiMo+G6zJW2IpJniRDCE17n2EJxQjMb8qfHcemVo7IcOz MLvoIVbULQ1Hw== From: "Anthony PERARD" Subject: =?utf-8?Q?Re:=20[PATCH=20v3]=20tools/xl:=20add=20suspend=20and=20resume=20subcommands?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1733407698446 To: "Jason Andryuk" Cc: xen-devel@lists.xenproject.org, "=?utf-8?Q?zithro=20/=20Cyril=20R=C3=A9bert?=" , "Andrew Cooper" , "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" Message-Id: References: <20241203220641.4202-1-jason.andryuk@amd.com> In-Reply-To: <20241203220641.4202-1-jason.andryuk@amd.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.fa438506577d428fa8d740685fae2d5a?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20241205:md Date: Thu, 05 Dec 2024 14:08:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 03, 2024 at 05:06:41PM -0500, Jason Andryuk wrote: > From: zithro / Cyril R=C3=A9bert > > The xl command doesn't provide suspend/resume, so add them : > xl suspend > xl resume > > This patch follows a discussion on XenDevel: when you want the > virtualized equivalent of "sleep"-ing a host, it's better to > suspend/resume than to pause/unpause a domain. > > Suggested-by: Andrew Cooper > Suggested-by: Marek Marczykowski-G=C3=B3recki > Signed-off-by: Cyril R=C3=A9bert (zithro) > Signed-off-by: Jason Andryuk Reviewed-by: Anthony PERARD Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Thu Dec 05 14:45:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 14:45:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849083.1263780 (Exim 4.92) (envelope-from ) id 1tJD6Y-0004tf-Oo; Thu, 05 Dec 2024 14:45:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849083.1263780; Thu, 05 Dec 2024 14:45: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 1tJD6Y-0004tY-MF; Thu, 05 Dec 2024 14:45:22 +0000 Received: by outflank-mailman (input) for mailman id 849083; Thu, 05 Dec 2024 14:45: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 1tJD6X-0004tS-BA for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 14:45:21 +0000 Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [2607:f8b0:4864:20::231]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8c72bee6-b317-11ef-a0d5-8be0dac302b0; Thu, 05 Dec 2024 15:45:20 +0100 (CET) Received: by mail-oi1-x231.google.com with SMTP id 5614622812f47-3ea6b011b27so1002636b6e.0 for ; Thu, 05 Dec 2024 06:45:20 -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: 8c72bee6-b317-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1733409919; x=1734014719; 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=0ZgRQhHyuN6yCF0EyJMCVjUH6Tzf65Z7q3KGkJjdL+I=; b=jJRRuhnUF3f4Ifa5vCMiUHAcYtOjcITQoC3btnajHHBYk/w1Pv1tdUMou6s5j/lguO djd2TxK8a7GiXkJtppNSHcKbI1MhI6tedXVNrRHtkmEBkQBvj9cTkT/pcXDeiU1Gwrwr zaNq9ZQKojpziqHnOCrMaoNoN6yfguJo0RX6xmTIvymVcP/xRkx5BsMBXFPcOHtqKJjd BKpotagWOncrPzrzRxLwZOoa+ky7AVMVkckwYU8L5ijFCvGdSbOjXL5Y+krZDlOfL1vN xSf6Yz/XU/prA4Jp3WUXfdxTjqFNG6VZjCNRpUgSWNnAtZteP/WyMKL8/OXz5Pna1QIy 7uew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733409919; x=1734014719; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0ZgRQhHyuN6yCF0EyJMCVjUH6Tzf65Z7q3KGkJjdL+I=; b=tth0TnIy0kIn6HeID9XJQEA03mabAgYiPbADckGjIUxfZEPEeTRrVq00WD84Y8Ohsb YD6KfXffZsGVSN3gA6slv+NLeliopfdWVCE/5Xdf5oXt27l8NwL7XSDP7C0DddPc5K5s SR5Eh5ENaH+efbAh1NTSiqvGXlF832cjelwWsprUPO6VCxiFsfASZPUUran2dok6dp7p NQNCyDwe6p9ubrVFOF7NRkW/jiMyo95e2dUX/92DmohAm5YSzrXGJzKAGXLUp9rEU5mN ljsBnkSWSCNn+AvhyZ8baRhzIt+l3YGl35x3FJ/H47ICh31sfolT9aON1cw/ALBNn452 lV3w== X-Gm-Message-State: AOJu0Yw7HliyoF4YBAc+MX6D+SYUyqKYWLpyC77BBKd0F6EoKBtEiOfW mm8+3n1Et9eEt0ix7v7rB7QSJqBGX8YlfcFdiiXSoXVS6SY/8AVOLKgc8dzhXfY6ARZeCZHxRet 4X0J/EW32MhnLecN0bXfBq2jTVXXnyaWOZJOigA== X-Gm-Gg: ASbGncvh14o1bS0f+3H9UTlskIx13+glAHCzvYkSAn11ByxFFCLlZSkgAL7C0zQm3jA 1oQtkqbkcR8ZuS+M7j7CIoZWwA1QFGno= X-Google-Smtp-Source: AGHT+IG4gPj3qtGbAP5V8CtdEkijrF4OGCFB/CjfZ4qb0ghLH56gKmObG2NZ9wXuhszmqWv90lT3+PIC1poPFQOpz+g= X-Received: by 2002:a05:6808:182a:b0:3e7:9e8c:304f with SMTP id 5614622812f47-3eb045add67mr1552844b6e.7.1733409918705; Thu, 05 Dec 2024 06:45:18 -0800 (PST) MIME-Version: 1.0 References: <3fcc536cd2e13d0421839fc6890daeda71cfac44.1732702210.git.bertrand.marquis@arm.com> In-Reply-To: <3fcc536cd2e13d0421839fc6890daeda71cfac44.1732702210.git.bertrand.marquis@arm.com> From: Jens Wiklander Date: Thu, 5 Dec 2024 15:45:07 +0100 Message-ID: Subject: Re: [PATCH v3 01/10] xen/arm: ffa: Rework firmware discovery 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, Nov 27, 2024 at 5:08=E2=80=AFPM Bertrand Marquis wrote: > > Rework firmware discovery during probe: > - move prints into the probe > - rename ffa_version to ffa_fw_version as the variable identifies the > version of the firmware and not the one we support > - add error prints when allocation fail during probe > > No functional changes. > > Signed-off-by: Bertrand Marquis > --- > Changes in v3: > - Revert spurious change assigning major_vers > - Remove error print in ffa_rxtx_init as we have already a print in the > main init function > Changes in v2: > - Fix error message when we fail to retrieve ffa_version > - Move back printing the firmware version before checking supported > features > - Use Warning instead of Info to inform user that FF-A is not supported > in firmware. > --- > xen/arch/arm/tee/ffa.c | 41 ++++++++++++++++++++++--------------- > xen/arch/arm/tee/ffa_rxtx.c | 4 +--- > 2 files changed, 26 insertions(+), 19 deletions(-) Looks good. Reviewed-by: Jens Wiklander Cheers, Jens > > diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c > index 022089278e1c..5a7f297ca5c6 100644 > --- a/xen/arch/arm/tee/ffa.c > +++ b/xen/arch/arm/tee/ffa.c > @@ -71,8 +71,8 @@ > > #include "ffa_private.h" > > -/* Negotiated FF-A version to use with the SPMC */ > -static uint32_t __ro_after_init ffa_version; > +/* Negotiated FF-A version to use with the SPMC, 0 if not there or suppo= rted */ > +static uint32_t __ro_after_init ffa_fw_version; > > > /* > @@ -105,10 +105,7 @@ static bool ffa_get_version(uint32_t *vers) > > arm_smccc_1_2_smc(&arg, &resp); > if ( resp.a0 =3D=3D FFA_RET_NOT_SUPPORTED ) > - { > - gprintk(XENLOG_ERR, "ffa: FFA_VERSION returned not supported\n")= ; > return false; > - } > > *vers =3D resp.a0; > > @@ -372,7 +369,7 @@ static int ffa_domain_init(struct domain *d) > struct ffa_ctx *ctx; > int ret; > > - if ( !ffa_version ) > + if ( !ffa_fw_version ) > return -ENODEV; > /* > * We can't use that last possible domain ID or ffa_get_vm_id() wou= ld > @@ -505,6 +502,9 @@ static bool ffa_probe(void) > */ > BUILD_BUG_ON(PAGE_SIZE !=3D FFA_PAGE_SIZE); > > + printk(XENLOG_INFO "ARM FF-A Mediator version %u.%u\n", > + FFA_MY_VERSION_MAJOR, FFA_MY_VERSION_MINOR); > + > /* > * psci_init_smccc() updates this value with what's reported by EL-3 > * or secure world. > @@ -514,22 +514,23 @@ static bool ffa_probe(void) > printk(XENLOG_ERR > "ffa: unsupported SMCCC version %#x (need at least %#x)\n= ", > smccc_ver, ARM_SMCCC_VERSION_1_2); > - return false; > + goto err_no_fw; > } > > if ( !ffa_get_version(&vers) ) > - return false; > + { > + gprintk(XENLOG_ERR, "Cannot retrieve the FFA version\n"); > + goto err_no_fw; > + } > > if ( vers < FFA_MIN_SPMC_VERSION || vers > FFA_MY_VERSION ) > { > printk(XENLOG_ERR "ffa: Incompatible version %#x found\n", vers)= ; > - return false; > + goto err_no_fw; > } > > major_vers =3D (vers >> FFA_VERSION_MAJOR_SHIFT) & FFA_VERSION_MAJOR= _MASK; > minor_vers =3D vers & FFA_VERSION_MINOR_MASK; > - printk(XENLOG_INFO "ARM FF-A Mediator version %u.%u\n", > - FFA_MY_VERSION_MAJOR, FFA_MY_VERSION_MINOR); > printk(XENLOG_INFO "ARM FF-A Firmware version %u.%u\n", > major_vers, minor_vers); > > @@ -546,12 +547,18 @@ static bool ffa_probe(void) > !check_mandatory_feature(FFA_MEM_SHARE_32) || > !check_mandatory_feature(FFA_MEM_RECLAIM) || > !check_mandatory_feature(FFA_MSG_SEND_DIRECT_REQ_32) ) > - return false; > + { > + printk(XENLOG_ERR "ffa: Mandatory feature not supported by fw\n"= ); > + goto err_no_fw; > + } > > - if ( !ffa_rxtx_init() ) > - return false; > + ffa_fw_version =3D vers; > > - ffa_version =3D vers; > + if ( !ffa_rxtx_init() ) > + { > + printk(XENLOG_ERR "ffa: Error during RXTX buffer init\n"); > + goto err_no_fw; > + } > > if ( !ffa_partinfo_init() ) > goto err_rxtx_destroy; > @@ -564,7 +571,9 @@ static bool ffa_probe(void) > > err_rxtx_destroy: > ffa_rxtx_destroy(); > - ffa_version =3D 0; > +err_no_fw: > + ffa_fw_version =3D 0; > + printk(XENLOG_WARNING "ARM FF-A No firmware support\n"); > > return false; > } > diff --git a/xen/arch/arm/tee/ffa_rxtx.c b/xen/arch/arm/tee/ffa_rxtx.c > index 661764052e67..c8bc516a19be 100644 > --- a/xen/arch/arm/tee/ffa_rxtx.c > +++ b/xen/arch/arm/tee/ffa_rxtx.c > @@ -203,10 +203,8 @@ bool ffa_rxtx_init(void) > > e =3D ffa_rxtx_map(__pa(ffa_tx), __pa(ffa_rx), FFA_RXTX_PAGE_COUNT); > if ( e ) > - { > - printk(XENLOG_ERR "ffa: Failed to map rxtx: error %d\n", e); > goto err; > - } > + > return true; > > err: > -- > 2.47.0 > From xen-devel-bounces@lists.xenproject.org Thu Dec 05 15:59:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 15:59:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849159.1263821 (Exim 4.92) (envelope-from ) id 1tJEGH-0006pb-Fz; Thu, 05 Dec 2024 15:59:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849159.1263821; Thu, 05 Dec 2024 15:59: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 1tJEGH-0006pU-DP; Thu, 05 Dec 2024 15:59:29 +0000 Received: by outflank-mailman (input) for mailman id 849159; Thu, 05 Dec 2024 15:59: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 1tJEGG-0006pO-Cd for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 15:59:28 +0000 Received: from mail-oa1-x31.google.com (mail-oa1-x31.google.com [2001:4860:4864:20::31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e67d9c81-b321-11ef-99a3-01e77a169b0f; Thu, 05 Dec 2024 16:59:26 +0100 (CET) Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-29e5bf419ebso366949fac.1 for ; Thu, 05 Dec 2024 07: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: e67d9c81-b321-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1733414365; x=1734019165; 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=hEhcfAlqoTBbddD5bKETueYddtGFrbPHE/WdJaY9dts=; b=hRQEE+lZN+HDXq8fFzNo/5ps3Lmf48brx5PP7ybMq+pHNpDiP/cBo15ilRXSxHDOLO k17RlEoXDNfpMUIwJFYPOJv4V7GPVCHjoqF06k2jp0j6WOs8yoC7UoGHEJSE4Ju48diZ kXWcooBQ/FLSf/ssNKeTQIZhurYrWQod0Rhr1joA79vxHVpj3mCGzgDGZjZ7enuE8RY2 ysff6VflP5ilVilt3H4h1EaQGeMaIp6oYUQDecqij82gX2FSw5SisjyKHYgVhW/N78aa 9WedwZt2/mqgNLsWCSviAfE2L+1j1EGOARJYDtq6YjiAmaURqiNBw4IQzx8aAtH0nf7H KgeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733414365; x=1734019165; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hEhcfAlqoTBbddD5bKETueYddtGFrbPHE/WdJaY9dts=; b=tR7jzSkaXnFw9Kqd4/fM4R2jx7MnhqHdEgKbhNctJAZqSEJJL/SlzNnXgdv2ZEYPfh Ac9sqp2IJ7M9AAt/WMcACw+znIuius5PpK/GulIoqPWwzeMSIeFMDEBwQm7QQMpQAtrT 0YJYn++qLtO+ByBMa+UU1Og2VNHG4YHPRdwJcJp20QQjg9S1+JJ7Tzesx1YMGZ8woW47 9zpfJVFFyo3I5Q/zSqP0q2CaQPl/DqODcxkpYPu072w+UWk/MAiSL+zWNIx8bdxeR435 yDA2OyY9UNEX4JFs521dMhdOAsKMKpDpI5uuk2np29e/eqkU0UtRphDOKhx8YrdUwN/h RYig== X-Gm-Message-State: AOJu0YwlvqhSz1irC719T8vdsSKLOhWTal910GStsBoNAVx5WvdZppmA I7iXxSTjPFTeh/vCDJY3scDjNbTiV5xamIJUvCEpUxX5c8knZtEuFdBqDpAzaCbrMi9C3bBBvgX x+M4SbWGlX9vmYk8ClT1Y9Gl6cQxs1EsjlHJU7w== X-Gm-Gg: ASbGncuodFr8cy/hDHrteHRZEHyaKeWmnMYdSLzlZs6jwlXOkvOYOtT63n167RtRQJe il/avnUCiBsxR+5cBv8QPYbvA4C7YnII= X-Google-Smtp-Source: AGHT+IEjd9sgTFDcE3GmnYLGWqbSJ7I3AAIoACD5wqxEDTEIIZ65YvLOWuA64cztc9TKxgyG76q6rr7xN0k3wj6Hlo4= X-Received: by 2002:a05:6871:10d:b0:29e:20c4:2217 with SMTP id 586e51a60fabf-29e888949cfmr9408376fac.33.1733414364789; Thu, 05 Dec 2024 07:59:24 -0800 (PST) MIME-Version: 1.0 References: <244dc07cda4cdba30e305f62818141444223a4e4.1732702210.git.bertrand.marquis@arm.com> In-Reply-To: <244dc07cda4cdba30e305f62818141444223a4e4.1732702210.git.bertrand.marquis@arm.com> From: Jens Wiklander Date: Thu, 5 Dec 2024 16:59:13 +0100 Message-ID: Subject: Re: [PATCH v3 02/10] xen/arm: ffa: Rework feature discovery 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, Nov 27, 2024 at 5:08=E2=80=AFPM Bertrand Marquis wrote: > > Store the list of ABI we need in a list and go through the list instead > of having a list of conditions inside the code. > > No functional change. > > Signed-off-by: Bertrand Marquis > --- > Changes in v3: > - remove const attribute for id in ffa_fw_abi struct > Changes in v2: > - Store a string version of ABI needed from firmware and print the name > of the ABI not supported instead of the id > - Restore comment with TODO which should not have been removed at this > stage > - fix to unsigned int the index in the loop on the array > - use abi instead of feature in the names of the functions and variables > as we are not checking features but abis > --- > xen/arch/arm/tee/ffa.c | 57 +++++++++++++++++++++++++----------------- > 1 file changed, 34 insertions(+), 23 deletions(-) Looks good. Reviewed-by: Jens Wiklander Cheers, Jens > > diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c > index 5a7f297ca5c6..ade6aaa6fd1d 100644 > --- a/xen/arch/arm/tee/ffa.c > +++ b/xen/arch/arm/tee/ffa.c > @@ -74,6 +74,31 @@ > /* Negotiated FF-A version to use with the SPMC, 0 if not there or suppo= rted */ > static uint32_t __ro_after_init ffa_fw_version; > > +struct ffa_fw_abi { > + uint32_t id; > + const char *name; > +}; > + > +#define FW_ABI(abi) {abi,#abi} > + > +/* List of ABI we use from the firmware */ > +static const struct ffa_fw_abi ffa_fw_abi_needed[] =3D { > + FW_ABI(FFA_VERSION), > + FW_ABI(FFA_FEATURES), > + FW_ABI(FFA_NOTIFICATION_BITMAP_CREATE), > + FW_ABI(FFA_NOTIFICATION_BITMAP_DESTROY), > + FW_ABI(FFA_PARTITION_INFO_GET), > + FW_ABI(FFA_NOTIFICATION_INFO_GET_64), > + FW_ABI(FFA_NOTIFICATION_GET), > + FW_ABI(FFA_RX_RELEASE), > + FW_ABI(FFA_RXTX_MAP_64), > + FW_ABI(FFA_RXTX_UNMAP), > + FW_ABI(FFA_MEM_SHARE_32), > + FW_ABI(FFA_MEM_SHARE_64), > + FW_ABI(FFA_MEM_RECLAIM), > + FW_ABI(FFA_MSG_SEND_DIRECT_REQ_32), > + FW_ABI(FFA_MSG_SEND_DIRECT_REQ_64), > +}; > > /* > * Our rx/tx buffers shared with the SPMC. FFA_RXTX_PAGE_COUNT is the > @@ -112,20 +137,9 @@ static bool ffa_get_version(uint32_t *vers) > return true; > } > > -static int32_t ffa_features(uint32_t id) > -{ > - return ffa_simple_call(FFA_FEATURES, id, 0, 0, 0); > -} > - > -static bool check_mandatory_feature(uint32_t id) > +static bool ffa_abi_supported(uint32_t id) > { > - int32_t ret =3D ffa_features(id); > - > - if ( ret ) > - printk(XENLOG_ERR "ffa: mandatory feature id %#x missing: error = %d\n", > - id, ret); > - > - return !ret; > + return !ffa_simple_call(FFA_FEATURES, id, 0, 0, 0); > } > > static void handle_version(struct cpu_user_regs *regs) > @@ -539,17 +553,14 @@ static bool ffa_probe(void) > * TODO: Rework the code to allow domain to use a subset of the > * features supported. > */ > - if ( !check_mandatory_feature(FFA_PARTITION_INFO_GET) || > - !check_mandatory_feature(FFA_RX_RELEASE) || > - !check_mandatory_feature(FFA_RXTX_MAP_64) || > - !check_mandatory_feature(FFA_MEM_SHARE_64) || > - !check_mandatory_feature(FFA_RXTX_UNMAP) || > - !check_mandatory_feature(FFA_MEM_SHARE_32) || > - !check_mandatory_feature(FFA_MEM_RECLAIM) || > - !check_mandatory_feature(FFA_MSG_SEND_DIRECT_REQ_32) ) > + for ( unsigned int i =3D 0; i < ARRAY_SIZE(ffa_fw_abi_needed); i++ ) > { > - printk(XENLOG_ERR "ffa: Mandatory feature not supported by fw\n"= ); > - goto err_no_fw; > + if ( !ffa_abi_supported(ffa_fw_abi_needed[i].id) ) > + { > + printk(XENLOG_INFO "ARM FF-A Firmware does not support %s\n"= , > + ffa_fw_abi_needed[i].name); > + goto err_no_fw; > + } > } > > ffa_fw_version =3D vers; > -- > 2.47.0 > From xen-devel-bounces@lists.xenproject.org Thu Dec 05 16:04:34 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 16:04:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849172.1263832 (Exim 4.92) (envelope-from ) id 1tJELA-0000c3-6U; Thu, 05 Dec 2024 16:04:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849172.1263832; Thu, 05 Dec 2024 16: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 1tJELA-0000bw-3H; Thu, 05 Dec 2024 16:04:32 +0000 Received: by outflank-mailman (input) for mailman id 849172; Thu, 05 Dec 2024 16: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 1tJEL8-0000bq-Fx for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 16:04:30 +0000 Received: from mail-oa1-x34.google.com (mail-oa1-x34.google.com [2001:4860:4864:20::34]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9a9a9789-b322-11ef-99a3-01e77a169b0f; Thu, 05 Dec 2024 17:04:28 +0100 (CET) Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-29e59db8d58so762861fac.2 for ; Thu, 05 Dec 2024 08:04: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: 9a9a9789-b322-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1733414667; x=1734019467; 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=bryHlIy8+6XfUbd27Hqxg8WP7I9HwbP7WaLVVtgvtCQ=; b=OeJwTpHRVmTBhhYDk+sN7jCZ4iUu4ZJP5M5VnkuISRp52cTfBmxZzcLuY9EeyKLlPt eHxmx38A0fpfesT2sbLUo8fO7y+2KE78r4zu+1vkeacAckC0IeoNpEoUB3e/UypIPVWq cmgYZ9cOMGnzF27af0nRL/87FHGiTryqBqyDQhwwJfWCYIzkRKWHoWdkILPds+f8E6tX gr0FJP7jpuyY4hrCgYZfECthKJqsUt7tVamLLCuoBuHaFpP/DsAKU4qQfGvgEAghsm3m jHvgy5KBDE4opWiAHnoHgoYlwV3k4AbIRpBfIUTQVTWsURlKgO0GEKp+8LjVe/plytFI FLKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733414667; x=1734019467; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bryHlIy8+6XfUbd27Hqxg8WP7I9HwbP7WaLVVtgvtCQ=; b=dHByqBBkPG1uJdQtBFs/0p0rwBhypWi18nFiXiKCxzB/TQBf13hkSKg5SNFjX01msg 8JNKwrM9p3wr7QFkLXKLGOEvV9KekMSRUjMK/Q25CrIMkWF3wuCVKLKauZG8ZvLLO6ch pVsVw8YPRAcp2SXp/JvwBk0BSi2qFop3U8S4lRHbk6cEzLSIQpH2cvikqOerTAmzZAD+ 2bXhpAI1kwTTzOWgeICRKCt1jrfRxygSYGTj1BOsaBE2uUa0d5fYojF9z3LqyIsxmA7n YL/bus0JlY1B6nocd5VCCVxkBsQYKG4oNhx7ZiMZj/AfGW2Dam9L+AfAOYeuu81p7s2W A5vA== X-Gm-Message-State: AOJu0YxKqSJUH5mJoJVLP5jx9YlN19II2MTv4qjmA+BgNuIrdQuQRu4W jl8odma9O9nVWVTws9GbVelcFFLQfG2U8YBY6iz7GqfDiOCXY5dQrGZ3tpZTYN8IRTUYEAYtlgP j/CzclnDC1xNPDzhhPhddE2Hz9VttYZ9Vr5x4QA== X-Gm-Gg: ASbGncvs+MseR3LiS5DbmWRifbVxFqDYpHzgABBB3zVPcW9Oni7Td1mXP22YIR/fdqx N+VI6wHRyRc+ckWPIvSX2WjgnX4s69EQ= X-Google-Smtp-Source: AGHT+IHoKvDLckftHJYML6HzHWbM+Ph7K8n4CzHn1MCAKe7KEKhVZ+rl5x/bPKYixU9tupp7R3zseCP+7sSsSQGSykE= X-Received: by 2002:a05:6870:7d06:b0:29e:592f:f4f3 with SMTP id 586e51a60fabf-29e8881f5cemr8607522fac.27.1733414666792; Thu, 05 Dec 2024 08:04:26 -0800 (PST) MIME-Version: 1.0 References: <0b987183498242587f3795e870a7395b132ec9ee.1732702210.git.bertrand.marquis@arm.com> In-Reply-To: <0b987183498242587f3795e870a7395b132ec9ee.1732702210.git.bertrand.marquis@arm.com> From: Jens Wiklander Date: Thu, 5 Dec 2024 17:04:14 +0100 Message-ID: Subject: Re: [PATCH v3 06/10] xen/arm: ffa: Use bit 15 convention for SPs 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, Nov 27, 2024 at 5:08=E2=80=AFPM Bertrand Marquis wrote: > > Make use and required to have bit 15 convention respected by secure > world (having bit 15 of IDs set for secure endpoints and non-set for > non-secure ones). > If any secure partition has an ID with bit 15 not set, it will not be > possible to contact or detect them. > Print an error log during probe for each secure endpoint detected with > bit 15 not set. > > We are switching to this convention because Xen is currently not using > VMIDs with bit 15 set so we are sure that no VM will have it set (this > is ensured by BUILD_BUG_ON in case this becomes false in the future). > It is allowing to easily distinguish between secure and non-secure > endpoints, preventing the need to store a list of secure endpoint IDs in > Xen. > > Signed-off-by: Bertrand Marquis > --- > Changes in v3: > - rename real_num to n_limit > - remove log of skipped SP due to invalid ID as it is already printed > Changes in v2: > - rebase > --- > xen/arch/arm/tee/ffa.c | 22 ++++++++++---- > xen/arch/arm/tee/ffa_partinfo.c | 51 +++++++++++++++++++++++++-------- > xen/arch/arm/tee/ffa_private.h | 7 +++++ > xen/arch/arm/tee/ffa_shm.c | 12 +++++++- > 4 files changed, 74 insertions(+), 18 deletions(-) Looks good. Reviewed-by: Jens Wiklander Cheers, Jens > > diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c > index 4b283a4de5d0..0026ac9134ad 100644 > --- a/xen/arch/arm/tee/ffa.c > +++ b/xen/arch/arm/tee/ffa.c > @@ -195,6 +195,14 @@ static void handle_msg_send_direct_req(struct cpu_us= er_regs *regs, uint32_t fid) > goto out; > } > > + /* we do not support direct messages to VMs */ > + if ( !FFA_ID_IS_SECURE(src_dst & GENMASK(15,0)) ) > + { > + resp.a0 =3D FFA_ERROR; > + resp.a2 =3D FFA_RET_NOT_SUPPORTED; > + goto out; > + } > + > arg.a1 =3D src_dst; > arg.a2 =3D get_user_reg(regs, 2) & mask; > arg.a3 =3D get_user_reg(regs, 3) & mask; > @@ -391,11 +399,15 @@ static int ffa_domain_init(struct domain *d) > > if ( !ffa_fw_version ) > return -ENODEV; > - /* > - * We can't use that last possible domain ID or ffa_get_vm_id() wou= ld > - * cause an overflow. > - */ > - if ( d->domain_id >=3D UINT16_MAX) > + /* > + * We are using the domain_id + 1 as the FF-A ID for VMs as FF-A ID = 0 is > + * reserved for the hypervisor and we only support secure endpoints = using > + * FF-A IDs with BIT 15 set to 1 so make sure those are not used by = Xen. > + */ > + BUILD_BUG_ON(DOMID_FIRST_RESERVED >=3D UINT16_MAX); > + BUILD_BUG_ON((DOMID_MASK & BIT(15, U)) !=3D 0); > + > + if ( d->domain_id >=3D DOMID_FIRST_RESERVED ) > return -ERANGE; > > ctx =3D xzalloc(struct ffa_ctx); > diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_parti= nfo.c > index 75a073d090e0..74324e1d9d3f 100644 > --- a/xen/arch/arm/tee/ffa_partinfo.c > +++ b/xen/arch/arm/tee/ffa_partinfo.c > @@ -169,14 +169,23 @@ void ffa_handle_partition_info_get(struct cpu_user_= regs *regs) > > if ( ffa_sp_count > 0 ) > { > - uint32_t n; > + uint32_t n, n_limit =3D ffa_sp_count; > void *src_buf =3D ffa_rx; > > /* copy the secure partitions info */ > - for ( n =3D 0; n < ffa_sp_count; n++ ) > + for ( n =3D 0; n < n_limit; n++ ) > { > - memcpy(dst_buf, src_buf, dst_size); > - dst_buf +=3D dst_size; > + struct ffa_partition_info_1_1 *fpi =3D src_buf; > + > + /* filter out SP not following bit 15 convention if any */ > + if ( FFA_ID_IS_SECURE(fpi->id) ) > + { > + memcpy(dst_buf, src_buf, dst_size); > + dst_buf +=3D dst_size; > + } > + else > + ffa_sp_count--; > + > src_buf +=3D src_size; > } > } > @@ -276,10 +285,25 @@ static bool init_subscribers(uint16_t count, uint32= _t fpi_size) > { > fpi =3D ffa_rx + n * fpi_size; > > - 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++; > + /* > + * 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(XENLOG_ERR "ffa: Firmware is not using bit 15 convent= ion for IDs !!\n" > + "ffa: Secure partition with id 0x%04x cann= ot 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 ) > @@ -299,10 +323,13 @@ static bool init_subscribers(uint16_t count, uint32= _t fpi_size) > { > fpi =3D ffa_rx + n * fpi_size; > > - 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_DESTROYED ) > - subscr_vm_destroyed[d_pos++] =3D fpi->id; > + 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; > diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_privat= e.h > index e5bc73f9039e..afe69b43dbef 100644 > --- a/xen/arch/arm/tee/ffa_private.h > +++ b/xen/arch/arm/tee/ffa_private.h > @@ -108,6 +108,13 @@ > */ > #define FFA_CTX_TEARDOWN_DELAY SECONDS(1) > > +/* > + * We rely on the convention suggested but not mandated by the FF-A > + * specification that secure world endpoint identifiers have the bit 15 > + * set and normal world have it set to 0. > + */ > +#define FFA_ID_IS_SECURE(id) ((id) & BIT(15, U)) > + > /* FF-A-1.1-REL0 section 10.9.2 Memory region handle, page 167 */ > #define FFA_HANDLE_HYP_FLAG BIT(63, ULL) > #define FFA_HANDLE_INVALID 0xffffffffffffffffULL > diff --git a/xen/arch/arm/tee/ffa_shm.c b/xen/arch/arm/tee/ffa_shm.c > index efa5b67db8e1..29675f9ba3f7 100644 > --- a/xen/arch/arm/tee/ffa_shm.c > +++ b/xen/arch/arm/tee/ffa_shm.c > @@ -469,6 +469,7 @@ void ffa_handle_mem_share(struct cpu_user_regs *regs) > int ret =3D FFA_RET_DENIED; > uint32_t range_count; > uint32_t region_offs; > + uint16_t dst_id; > > if ( !ffa_fw_supports_fid(FFA_MEM_SHARE_64) ) > { > @@ -537,6 +538,15 @@ void ffa_handle_mem_share(struct cpu_user_regs *regs= ) > goto out_unlock; > > mem_access =3D ctx->tx + trans.mem_access_offs; > + > + dst_id =3D ACCESS_ONCE(mem_access->access_perm.endpoint_id); > + if ( !FFA_ID_IS_SECURE(dst_id) ) > + { > + /* we do not support sharing with VMs */ > + ret =3D FFA_RET_NOT_SUPPORTED; > + goto out_unlock; > + } > + > if ( ACCESS_ONCE(mem_access->access_perm.perm) !=3D FFA_MEM_ACC_RW ) > { > ret =3D FFA_RET_NOT_SUPPORTED; > @@ -567,7 +577,7 @@ void ffa_handle_mem_share(struct cpu_user_regs *regs) > goto out_unlock; > } > shm->sender_id =3D trans.sender_id; > - shm->ep_id =3D ACCESS_ONCE(mem_access->access_perm.endpoint_id); > + shm->ep_id =3D dst_id; > > /* > * Check that the Composite memory region descriptor fits. > -- > 2.47.0 > From xen-devel-bounces@lists.xenproject.org Thu Dec 05 18:02:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 18:02:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849204.1263845 (Exim 4.92) (envelope-from ) id 1tJGAx-0006Sr-7p; Thu, 05 Dec 2024 18:02:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849204.1263845; Thu, 05 Dec 2024 18:02: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 1tJGAx-0006Sk-4G; Thu, 05 Dec 2024 18:02:07 +0000 Received: by outflank-mailman (input) for mailman id 849204; Thu, 05 Dec 2024 18:02: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 1tJGAv-0006Se-Ep for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 18:02:05 +0000 Received: from mail180-17.suw31.mandrillapp.com (mail180-17.suw31.mandrillapp.com [198.2.180.17]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 07d86fb8-b333-11ef-a0d5-8be0dac302b0; Thu, 05 Dec 2024 19:02:03 +0100 (CET) Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail180-17.suw31.mandrillapp.com (Mailchimp) with ESMTP id 4Y42K61FZczRKMxJk for ; Thu, 5 Dec 2024 18:02:02 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 6834e9160f654eb09fe924cf10ec595b; Thu, 05 Dec 2024 18:02: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: 07d86fb8-b333-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1733421722; x=1733682222; bh=ad6+7K0MU3AplIOcEBv8BaP7kQJXpeNbZddg7QpiWRs=; 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=1yvwnZMlNUp3vJj+KC3E0hoW7nAJR3HUP65k3YGHWDOLYtsykSRAebgSuQ2+1ix1p hvo7KVti7UVUFqngwqG2KApzVUtZff/XmI3Lo0bgLeRfUaNPxzg3w9oNuxx8RI4Dxa RTYBQsEStrMRMPH1NYH0z28EsnAigiVXOnLoO6hNYZ+ce7l06R6RI+Lhu7WVr39s6t M6btLsgwqwT68bctlBt3WGLnM7EcuMceLoNg6U0911cmDIXf+bivyxEz1XuI8DNAn1 jj9P27gWqq7L9LXxBV6vcnxdAA8MObqbTUVwlqr2Uom04T9ezHD8ki+B6HhSlpGvkp XFyy0AJN2DxPw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1733421722; x=1733682222; i=teddy.astie@vates.tech; bh=ad6+7K0MU3AplIOcEBv8BaP7kQJXpeNbZddg7QpiWRs=; 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=Z0gEM+IP1NNdJKfVNAwxxY6/9X5ORQuRxdrf+MEzelSwZ9DWIdkmmjT7L7gZWdNqr /GzCMFnhnoHk44ndkKJL3xJMXPxK9uSo8p3cg/LAt3r6TVEuxcqFq3W5CJ5fIdTyRf 5CnuoeW5tkk75GQCs5T1GuYtP1ziB2D3qObSsznWXuGpNoTXArCZC7W37S66kJSbFh 5Skk7TPG/dt8FwwEcuky4SJCRFBmWsTOi0ksK0kgXsiyzsNr5T8QmiL4T84Srqu9id pCRho2P/7nqxFjT0LauBdfyLPepYUOIbnGMZOgP6nlDaCSo93Z4XOZXA8NIMERdBUH FyhIUAnmLHIRg== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[XEN=20PATCH=20v2]=20x86/hvm:=20Use=20constants=20for=20x86=20modes?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1733421721142 Message-Id: <05013b39-fb2c-4eed-97e9-b91506ff89b2@vates.tech> To: "Andrew Cooper" , xen-devel@lists.xenproject.org Cc: "Jan Beulich" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Paul Durrant" References: <79004c19-7e55-4623-86e6-badd165b1d30@citrix.com> In-Reply-To: <79004c19-7e55-4623-86e6-badd165b1d30@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.6834e9160f654eb09fe924cf10ec595b?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20241205:md Date: Thu, 05 Dec 2024 18:02:02 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, Le 04/12/2024 =C3=A0 14:01, Andrew Cooper a =C3=A9crit=C2=A0: > On 02/12/2024 9:49 am, Teddy Astie wrote: >> In many places of x86 HVM code, constants integer are used to indicate i= n what mode is >> running the CPU (real, vm86, 16-bits, 32-bits, 64-bits). However, these = constants are >> are written directly as integer which hides the actual meaning of these = modes. >> >> This patch introduces X86_MODE_* macros and replace those occurences wit= h it. >> >> Signed-off-by Teddy Astie > > As fed back previously, these are (mostly) not modes. > > "Mode" has a specific meaning in the x86 architecture which is not > this.=C2=A0 You are going to have to change your commit message, and choi= ce > of constant names. > > ~Andrew I took a look on the page you sent in the past [1], but I am quite confused on how they should be named then. Intel System Programming Guide in 2.2 "Modes of operation" defines these as "operating modes" - Protected mode (which are named in this patch X86_MODE_32BIT and X86_MODE_16BIT) - Real-address mode (which is named in this patch X86_MODE_REAL) - Virtual-8086 mode (X86_MODE_VM86) - IA-32e mode (X86_MODE_64BIT and in some cases X86_MODE_32BIT) The page you sent introduce multiple "processor modes" with variants of real mode (RM16, RM32), VM86 (VM16, VM16E0, VM16E1), Protected mode (PM16, PM32) and IA32-mode "long mode" (CM16, CM32, PM64). I think we can add all these modes as separate defines, while having a way (macro ?) to check some attributes (e.g is it "long mode" ? with a bit indicating a "long mode" mode). [1] https://sandpile.org/x86/mode.htm 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 Dec 05 18:52:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 18:52:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849218.1263854 (Exim 4.92) (envelope-from ) id 1tJGxl-0004Ph-UD; Thu, 05 Dec 2024 18:52:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849218.1263854; Thu, 05 Dec 2024 18:52: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 1tJGxl-0004Pa-RY; Thu, 05 Dec 2024 18:52:33 +0000 Received: by outflank-mailman (input) for mailman id 849218; Thu, 05 Dec 2024 18:52: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 1tJGxk-0004PU-3m for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 18:52:32 +0000 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 12f0fa1e-b33a-11ef-a0d5-8be0dac302b0; Thu, 05 Dec 2024 19:52:29 +0100 (CET) Received: from orviesa007.jf.intel.com ([10.64.159.147]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Dec 2024 10:52:26 -0800 Received: from uaeoff-desk2.amr.corp.intel.com (HELO [10.124.220.98]) ([10.124.220.98]) by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Dec 2024 10:52: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: 12f0fa1e-b33a-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1733424749; x=1764960749; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=l/aDO4IrCDD1jgJitpkzmkkhO1BeEVsbZ673Y07xHBg=; b=XoNa73ifWa15I99ADVQfF531JC/hN1lFU3XinAQFaVxsvxsDEMGjv/aA nJO+U6sFGLIdH6k4lZLL5N1dIKhY3U97g2YOPz7XBHTnsXY8epqy6uS77 dsQKzGUQN/M4OkLC6cFiA32roJhz1CKmphVehQHfZs5JS4qY0OBCq+XBE qNTGewxOxIc+u2oKQXDgkJCBSjNtYeWrgaMm9n1adGApOw1KHM5XUPdZw UPmyjz+B+xnZjcDgqSr6BViN5/L42kVNGYt8HYD0zUax7QBVuKnm0mlVL 3Y5dThxHvZ6RHxw/CuiJtMek8EOW8c3n5qz7h3eXr0MNyiVg52o5kB2AN g==; X-CSE-ConnectionGUID: mAj7Ye8VQTWEOStmbxjaVA== X-CSE-MsgGUID: niCMX+kqTVK+nFxrJ68Abw== X-IronPort-AV: E=McAfee;i="6700,10204,11277"; a="44425979" X-IronPort-AV: E=Sophos;i="6.12,211,1728975600"; d="scan'208";a="44425979" X-CSE-ConnectionGUID: hgJixa3hRde6dU6inf3fqg== X-CSE-MsgGUID: kMRGM0CMSduZ1oINGDyJUg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,211,1728975600"; d="scan'208";a="94621790" Message-ID: <24b8d4a0-36c3-4404-98aa-7d8e2c67ac95@intel.com> Date: Thu, 5 Dec 2024 10:52:24 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Grab mm lock before grabbing pt lock To: Maksym Planeta , Juergen Gross , Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org References: <20241204103516.3309112-1-maksym@exostellar.io> From: Dave Hansen Content-Language: en-US Autocrypt: addr=dave.hansen@intel.com; keydata= xsFNBE6HMP0BEADIMA3XYkQfF3dwHlj58Yjsc4E5y5G67cfbt8dvaUq2fx1lR0K9h1bOI6fC oAiUXvGAOxPDsB/P6UEOISPpLl5IuYsSwAeZGkdQ5g6m1xq7AlDJQZddhr/1DC/nMVa/2BoY 2UnKuZuSBu7lgOE193+7Uks3416N2hTkyKUSNkduyoZ9F5twiBhxPJwPtn/wnch6n5RsoXsb ygOEDxLEsSk/7eyFycjE+btUtAWZtx+HseyaGfqkZK0Z9bT1lsaHecmB203xShwCPT49Blxz VOab8668QpaEOdLGhtvrVYVK7x4skyT3nGWcgDCl5/Vp3TWA4K+IofwvXzX2ON/Mj7aQwf5W iC+3nWC7q0uxKwwsddJ0Nu+dpA/UORQWa1NiAftEoSpk5+nUUi0WE+5DRm0H+TXKBWMGNCFn c6+EKg5zQaa8KqymHcOrSXNPmzJuXvDQ8uj2J8XuzCZfK4uy1+YdIr0yyEMI7mdh4KX50LO1 pmowEqDh7dLShTOif/7UtQYrzYq9cPnjU2ZW4qd5Qz2joSGTG9eCXLz5PRe5SqHxv6ljk8mb ApNuY7bOXO/A7T2j5RwXIlcmssqIjBcxsRRoIbpCwWWGjkYjzYCjgsNFL6rt4OL11OUF37wL QcTl7fbCGv53KfKPdYD5hcbguLKi/aCccJK18ZwNjFhqr4MliQARAQABzUVEYXZpZCBDaHJp c3RvcGhlciBIYW5zZW4gKEludGVsIFdvcmsgQWRkcmVzcykgPGRhdmUuaGFuc2VuQGludGVs LmNvbT7CwXgEEwECACIFAlQ+9J0CGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEGg1 lTBwyZKwLZUP/0dnbhDc229u2u6WtK1s1cSd9WsflGXGagkR6liJ4um3XCfYWDHvIdkHYC1t MNcVHFBwmQkawxsYvgO8kXT3SaFZe4ISfB4K4CL2qp4JO+nJdlFUbZI7cz/Td9z8nHjMcWYF IQuTsWOLs/LBMTs+ANumibtw6UkiGVD3dfHJAOPNApjVr+M0P/lVmTeP8w0uVcd2syiaU5jB aht9CYATn+ytFGWZnBEEQFnqcibIaOrmoBLu2b3fKJEd8Jp7NHDSIdrvrMjYynmc6sZKUqH2 I1qOevaa8jUg7wlLJAWGfIqnu85kkqrVOkbNbk4TPub7VOqA6qG5GCNEIv6ZY7HLYd/vAkVY E8Plzq/NwLAuOWxvGrOl7OPuwVeR4hBDfcrNb990MFPpjGgACzAZyjdmYoMu8j3/MAEW4P0z F5+EYJAOZ+z212y1pchNNauehORXgjrNKsZwxwKpPY9qb84E3O9KYpwfATsqOoQ6tTgr+1BR CCwP712H+E9U5HJ0iibN/CDZFVPL1bRerHziuwuQuvE0qWg0+0SChFe9oq0KAwEkVs6ZDMB2 P16MieEEQ6StQRlvy2YBv80L1TMl3T90Bo1UUn6ARXEpcbFE0/aORH/jEXcRteb+vuik5UGY 5TsyLYdPur3TXm7XDBdmmyQVJjnJKYK9AQxj95KlXLVO38lczsFNBFRjzmoBEACyAxbvUEhd GDGNg0JhDdezyTdN8C9BFsdxyTLnSH31NRiyp1QtuxvcqGZjb2trDVuCbIzRrgMZLVgo3upr MIOx1CXEgmn23Zhh0EpdVHM8IKx9Z7V0r+rrpRWFE8/wQZngKYVi49PGoZj50ZEifEJ5qn/H Nsp2+Y+bTUjDdgWMATg9DiFMyv8fvoqgNsNyrrZTnSgoLzdxr89FGHZCoSoAK8gfgFHuO54B lI8QOfPDG9WDPJ66HCodjTlBEr/Cwq6GruxS5i2Y33YVqxvFvDa1tUtl+iJ2SWKS9kCai2DR 3BwVONJEYSDQaven/EHMlY1q8Vln3lGPsS11vSUK3QcNJjmrgYxH5KsVsf6PNRj9mp8Z1kIG qjRx08+nnyStWC0gZH6NrYyS9rpqH3j+hA2WcI7De51L4Rv9pFwzp161mvtc6eC/GxaiUGuH BNAVP0PY0fqvIC68p3rLIAW3f97uv4ce2RSQ7LbsPsimOeCo/5vgS6YQsj83E+AipPr09Caj 0hloj+hFoqiticNpmsxdWKoOsV0PftcQvBCCYuhKbZV9s5hjt9qn8CE86A5g5KqDf83Fxqm/ vXKgHNFHE5zgXGZnrmaf6resQzbvJHO0Fb0CcIohzrpPaL3YepcLDoCCgElGMGQjdCcSQ+Ci FCRl0Bvyj1YZUql+ZkptgGjikQARAQABwsFfBBgBAgAJBQJUY85qAhsMAAoJEGg1lTBwyZKw l4IQAIKHs/9po4spZDFyfDjunimEhVHqlUt7ggR1Hsl/tkvTSze8pI1P6dGp2XW6AnH1iayn yRcoyT0ZJ+Zmm4xAH1zqKjWplzqdb/dO28qk0bPso8+1oPO8oDhLm1+tY+cOvufXkBTm+whm +AyNTjaCRt6aSMnA/QHVGSJ8grrTJCoACVNhnXg/R0g90g8iV8Q+IBZyDkG0tBThaDdw1B2l asInUTeb9EiVfL/Zjdg5VWiF9LL7iS+9hTeVdR09vThQ/DhVbCNxVk+DtyBHsjOKifrVsYep WpRGBIAu3bK8eXtyvrw1igWTNs2wazJ71+0z2jMzbclKAyRHKU9JdN6Hkkgr2nPb561yjcB8 sIq1pFXKyO+nKy6SZYxOvHxCcjk2fkw6UmPU6/j/nQlj2lfOAgNVKuDLothIxzi8pndB8Jju KktE5HJqUUMXePkAYIxEQ0mMc8Po7tuXdejgPMwgP7x65xtfEqI0RuzbUioFltsp1jUaRwQZ MTsCeQDdjpgHsj+P2ZDeEKCbma4m6Ez/YWs4+zDm1X8uZDkZcfQlD9NldbKDJEXLIjYWo1PH hYepSffIWPyvBMBTW2W5FRjJ4vLRrJSUoEfJuPQ3vW9Y73foyo/qFoURHO48AinGPZ7PC7TF vUaNOTjKedrqHkaOcqB185ahG2had0xnFsDPlx5y In-Reply-To: <20241204103516.3309112-1-maksym@exostellar.io> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/4/24 02:35, Maksym Planeta wrote: > Function xen_pin_page calls xen_pte_lock, which in turn grab page > table lock (ptlock). When locking, xen_pte_lock expect mm->page_table_lock > to be held before grabbing ptlock, but this does not happen when pinning > is caused by xen_mm_pin_all. In changelogs, please indicate functions with parenthesis like this: func(). It makes it easier to tell what is a function versus a variable or other text. The use of init_mm here in the preexisting code is a _bit_ fishy because these pgds *HAVE* an mm and yet xen_mm_pin_all() passes in '&init_mm' for them. That's relevant here because locking 'init_mm' obviously doesn't do any good for other mm's. I have the _feeling_ it's just a big hack and this code throws caution tot the wind because of: > * Expected to be called in stop_machine() ("equivalent to taking > * every spinlock in the system"), so the locking doesn't really > * matter all that much. So the patch here kinda doubles down on the hack and continues the theme because "locking doesn't really matter all that much." If so, it's not super satisfying, but it is consistent with the existing code. > This commit addresses lockdep warning below, which shows up when > suspending a Xen VM. If the comment I quote above is right, this is a _harmless_ warning because nothing else can race here and the locking that gets added is useless anyway, right? You seem to agree because there's no cc:stable@ or Fixes: tags. Either way, I'm hesitant to add incorrect-in-any-other-context and uncommented locking just to shut up lockdep. Is there no better way? If not, can we comment it at least, please, so nobody else tries to duplicate the locking? From xen-devel-bounces@lists.xenproject.org Thu Dec 05 19:24:07 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 19:24:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849238.1263871 (Exim 4.92) (envelope-from ) id 1tJHS5-00007a-Bq; Thu, 05 Dec 2024 19:23:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849238.1263871; Thu, 05 Dec 2024 19:23: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 1tJHS5-00007T-97; Thu, 05 Dec 2024 19:23:53 +0000 Received: by outflank-mailman (input) for mailman id 849238; Thu, 05 Dec 2024 19:23: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 1tJHS4-00007N-9j for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 19:23:52 +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 74b30d71-b33e-11ef-99a3-01e77a169b0f; Thu, 05 Dec 2024 20:23:50 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-432d86a3085so9106525e9.2 for ; Thu, 05 Dec 2024 11:23:50 -0800 (PST) Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38621909739sm2678954f8f.66.2024.12.05.11.23.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Dec 2024 11:23: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: 74b30d71-b33e-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1733426629; x=1734031429; 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=ZYN67hFp8JAJSq9JWJnAKUz4jAU23Uz6qBkwgEF8fAs=; b=RHaYFWHKqG2hB7rQlfpnmJX5qeoq45OUhMCWWE707IPPWZRXo8eHRcNbU9mlg1VOW/ OYppCc6HS5mZ3EQSY5cyffN0t6RBZiAZ0l003/VtjDZcg8HNuo9FCLhxErKcBbIMgGtq hO0lv9KITeqcMXGZRMwDLgbZf8ksPNaxXpaaw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733426629; x=1734031429; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ZYN67hFp8JAJSq9JWJnAKUz4jAU23Uz6qBkwgEF8fAs=; b=qi5pSGsyCnb6Wt07J9D1IaTx+wzjDhvRHqCdS64hgMnSuCF8fYF3EGs5RawPP1NORL H8nfH8Zke9w4OngOt5tYdF7yQW9AFBply2d0qu7tXndH8ZyVHpDcIcYwd90A1d4np7ld q2bwK3JC9npXJgKYVdZpTSSYcnslx9puzOJfakM7nnFqCgZeJgHf0yG+moOkfdZY8aE+ FEM3HOjKkWDD9UQylYp9mpYsXOI5TAgNbctxhPnCjsFrFT+nsci8dkYPEpCYzxSRCEpt DJezVSF2teQcDDumEghyTxLqIGRDPlT5rX8sG3eiiHwRXNoEibg8DAFNs5/AvDAp0bpA 1WKQ== X-Forwarded-Encrypted: i=1; AJvYcCXOAH3MGisxefc57/0XFTO6q83fE1U6mrrb3qjVytAM0l28wPuPm1Q81FgJczIG86BnannM+nAKzE8=@lists.xenproject.org X-Gm-Message-State: AOJu0YzEKvPRSegRyIkjLy4nGM/alwjN9zPKdWy+j81+gsqCn7uC2zox bkRoYi8+DSAjnFEm0/RM+BxY7pMIHz+xrPIxM5DuHjBEvUN2QAKg1adUvnwUhO0= X-Gm-Gg: ASbGncsnRRqMxC38kl4/rL41PsaS0CC9eEBJoLrtzdV1OBwkCAVpSJMF0LZELo8lo7W hbnxbzzdF468pJkNc5EA+TfIJMTLlDOYplwp3f6cBRbiqYIvGYgwkatVGdEDHKHDGRGL0xQuNwY i8C+rKF8EFuWBcU9gUFesCv8o4hh2vSUw9VS04Nlk2TY3dQTHBZIvjAOjXZoxsslwWDWLoRdchA JHw5RPum3HgY7i9EkMzq+R8dCiF3YU5S7MHSTtdapMpqj1dEvMO7lNu1vP9OKQAlCNf6kz0Vzs6 vHUKsD8uDWh40Q== X-Google-Smtp-Source: AGHT+IG+p8ekGv/ewNgrODj5zAesLs0L80qzZbd15CBO0jbQG1BuyLWFXCYNftnBuZeBE2SCnTuCTA== X-Received: by 2002:a5d:6da5:0:b0:385:f195:27f with SMTP id ffacd0b85a97d-3862b33b9d3mr245902f8f.5.1733426629315; Thu, 05 Dec 2024 11:23:49 -0800 (PST) Message-ID: <79bb69b0-b00d-4e3c-966e-a341eac59499@citrix.com> Date: Thu, 5 Dec 2024 19:23:48 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/4] xen: arm: enable stack protector feature To: Julien Grall Cc: Volodymyr Babchuk , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Bertrand Marquis , Michal Orzel References: <20241130010954.36057-1-volodymyr_babchuk@epam.com> <20241130010954.36057-4-volodymyr_babchuk@epam.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 03/12/2024 11:16 pm, Julien Grall wrote: > On Tue, 3 Dec 2024 at 22:00, Andrew Cooper wrote: >> On 30/11/2024 1:10 am, Volodymyr Babchuk wrote: >>> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c >>> index 2e27af4560..f855e97e25 100644 >>> --- a/xen/arch/arm/setup.c >>> +++ b/xen/arch/arm/setup.c >>> @@ -341,6 +342,8 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr) >>> */ >>> system_state = SYS_STATE_boot; >>> >>> + boot_stack_chk_guard_setup(); >>> + >>> if ( acpi_disabled ) >>> { >>> printk("Booting using Device Tree\n"); >> I still think that __stack_chk_guard wants setting up in ASM before >> entering C. >> >> The only reason this call is so late is because Xen's get_random() >> sequence is less than helpful. That wants rewriting somewhat, but maybe >> now isn't the best time. >> >> Even if you initialise __stack_chk_guard it to -1 rather than 0, it's >> still got a better chance of catching errors during very early boot; the >> instrumentation is present, but is using 0 as the canary value. >> >> On x86, dumping the current TSC value into __stack_chk_guard would be >> far better than using -1. Even if it skewed to a lower number, it's >> unpredictable and not going to reoccur by accident during a stack overrun. >> >> Surely ARM has something similar it could use? > There is a optional system register to read a random number. Only in v8.5 as far as I can see, and even then it's not required.  Also, it suffers from the same problem as RDRAND on x86; we need to boot to at least feature detection before we can safely use it if it's available. > >> [edit] Yes, get_cycles(), which every architecture seems to have. In >> fact, swapping get_random() from NOW() to get_cycles() would be good >> enough to get it usable from early assembly. > Not quite. Technically we can't rely on the timer counter until > platform_init_time() is called. > This was to cater an issue on the exynos we used in OssTest. But > arguably this is the exception > rather than the norm because the firmware ought to properly initialize > the timer... > > I haven't checked recent firmware. But I could be convinced to access > the counter before > hand if we really think that setting __stack_chk_guard from ASM is much better. The C instrumentation is always present, right from the very start of start_xen(). Even working with a canary of 0, there's some value.  It will spot clobbering with a non-zero value, but it won't spot e.g. an overly-long memset(, 0). During boot, we're not defending against a malicious entity.  Simply defending against bad developer expectations. Therefore, anything to get a non-zero value prior to entering C will be an improvement.  Best-effort is fine, and if there's one platform with an errata that causes it to miss out, then oh well.  Any other platform which manifests a crash will still lead to the problem being fixed. I suppose taking this argument to it's logical conclusion, we could initialise __stack_chk_guard with a poison pattern, although not one shared by any other poison pattern in Xen.  That alone would be better than using 0 in early boot. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Dec 05 19:30:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 19:30:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849253.1263880 (Exim 4.92) (envelope-from ) id 1tJHXz-0000oM-1y; Thu, 05 Dec 2024 19:29:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849253.1263880; Thu, 05 Dec 2024 19: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 1tJHXy-0000oF-Vf; Thu, 05 Dec 2024 19:29:58 +0000 Received: by outflank-mailman (input) for mailman id 849253; Thu, 05 Dec 2024 19:29: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 1tJHXy-0000o7-Ag for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 19:29:58 +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 4f19fbd9-b33f-11ef-99a3-01e77a169b0f; Thu, 05 Dec 2024 20:29:56 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-3862a4b8ec2so89603f8f.1 for ; Thu, 05 Dec 2024 11:29:56 -0800 (PST) Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3862190965asm2748754f8f.82.2024.12.05.11.29.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Dec 2024 11:29: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: 4f19fbd9-b33f-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1733426996; x=1734031796; 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=Jrm0cAtT507kZI0+GHeU1830OSWqdmqJYqV3CAdFlb8=; b=fnrrTC/rCwM1j905UDOZJFYzGWXMjEcNKGnwWNQG/83Bx7chZ/zt6con5R2J/CY4oZ 0U62+kEX50nzJht1hX1GNfskcM74Lc3HrWpGJByJG4+OEn8xP+ei1AwHK5il3ddLniPL tyAzCr88dcQVGfdbf8p+dvuZk8j6HEXwdDAYk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733426996; x=1734031796; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Jrm0cAtT507kZI0+GHeU1830OSWqdmqJYqV3CAdFlb8=; b=XbdMP56QZvocj3MUJsFfqTZRj5RxZ+z6WAksk//VYE1OmvSgRR0S0xnX7OXlM3RY7U 9YVwMAUKUOCL9qvv7H/26I/2emKWoahQEHfhXQwr45vQEa0YiPQH3b5mOiSa8sSk7zA/ KjWzz0Fx/XGrIA5qC5CBETaiSbH1JmgQAnAlZGbyaA/L2DfdgTjT2BELs7sO1bXHJrgi PDDnuihYug1LNHLAkuatWqQSXOZPyUSjcIohwEYMocRb4JPnircQA97Jpoip0kVzNTad fudCy+MbJ6x0cFRhObOkb4d0EKUq2eTc0yZwLhE91bVrnzkXoyUteFAPye3zOy5bdYrR /nNw== X-Gm-Message-State: AOJu0YzwrEvSflVUxKh/lNNQDLo+S04zNQR7YnABZE04p73R9J5OnwAo UTqVb6/XrDR7j1dRcIQtfxWWVD1qhHvzwxtYLG3WYznH2sOjFLULkMS0wsgi5ZAr1AtqxN2hsxZ V X-Gm-Gg: ASbGncuZQX6Tst/reIMsFuVfHn2pPkaav5AUSGWsGyoEZCUqNoqTqdCf+JpwUw2WoQf CHsZBY2paziVucdzATAMU7UlqE0SAreFVWkeH9swyActq1Vmo7BgHNJaoCUV8QbBhLRLDbgKYSL mhkoXFdGQulizowC29q2NEploYnb4PdCz6VYqzP650FKGqknrPMfwohYq9plqcA6IaDNhLITXII fGWvpwtK0RUFy/7hArphjNuIRJIl5eDUcWwltn15W7iXuYS3QOnDRuamOYuYagnerB4tk9HqZ+6 Kcy9Wj9e10M7lA== X-Google-Smtp-Source: AGHT+IGBMiYKBRQoOq1OGegWXCZcE45iK4QvL+h3JdgjxMqy+8TQxknxTryho9iRGZiaRSKc51nwcA== X-Received: by 2002:a05:6000:793:b0:385:ef39:6ce9 with SMTP id ffacd0b85a97d-3862b351418mr253154f8f.21.1733426995920; Thu, 05 Dec 2024 11:29:55 -0800 (PST) Message-ID: Date: Thu, 5 Dec 2024 19:29:54 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] tools/xl: add suspend and resume subcommands To: Anthony PERARD , Jason Andryuk Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?zithro_/_Cyril_R=C3=A9bert?= , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= References: <20241203220641.4202-1-jason.andryuk@amd.com> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05/12/2024 2:08 pm, Anthony PERARD wrote: > On Tue, Dec 03, 2024 at 05:06:41PM -0500, Jason Andryuk wrote: >> From: zithro / Cyril Rébert >> >> The xl command doesn't provide suspend/resume, so add them : >> xl suspend >> xl resume >> >> This patch follows a discussion on XenDevel: when you want the >> virtualized equivalent of "sleep"-ing a host, it's better to >> suspend/resume than to pause/unpause a domain. >> >> Suggested-by: Andrew Cooper >> Suggested-by: Marek Marczykowski-Górecki >> Signed-off-by: Cyril Rébert (zithro) >> Signed-off-by: Jason Andryuk > Reviewed-by: Anthony PERARD Committed.  This definitely warrants a note in CHANGELOG.md ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Dec 05 19:50:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 19:50:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849265.1263894 (Exim 4.92) (envelope-from ) id 1tJHrz-0004tc-LT; Thu, 05 Dec 2024 19:50:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849265.1263894; Thu, 05 Dec 2024 19:50: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 1tJHrz-0004tV-Iw; Thu, 05 Dec 2024 19:50:39 +0000 Received: by outflank-mailman (input) for mailman id 849265; Thu, 05 Dec 2024 19:50:38 +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 1tJHry-0004sc-J4 for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 19:50:38 +0000 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam04on2061b.outbound.protection.outlook.com [2a01:111:f403:240a::61b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 31148944-b342-11ef-99a3-01e77a169b0f; Thu, 05 Dec 2024 20:50:36 +0100 (CET) Received: from MW4P223CA0009.NAMP223.PROD.OUTLOOK.COM (2603:10b6:303:80::14) by BN5PR12MB9462.namprd12.prod.outlook.com (2603:10b6:408:2ac::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.20; Thu, 5 Dec 2024 19:50:28 +0000 Received: from SJ1PEPF00002316.namprd03.prod.outlook.com (2603:10b6:303:80:cafe::75) by MW4P223CA0009.outlook.office365.com (2603:10b6:303:80::14) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.12 via Frontend Transport; Thu, 5 Dec 2024 19:50:27 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SJ1PEPF00002316.mail.protection.outlook.com (10.167.242.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Thu, 5 Dec 2024 19:50:27 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) 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; Thu, 5 Dec 2024 13:50:26 -0600 Received: from amd-BIRMANPLUS.mshome.net (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Thu, 5 Dec 2024 13:50:25 -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: 31148944-b342-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=GWwDXXMBL5AtPcBTmN4WN4vmUBbSKkZsbwoY4MTOU+LSpNUs4GB/8NLXeQA6VAeS4xBVzrFbUzDNQpIkI/znMng8kNSszTT5Z70wwjrw7OAVkf7nkrZdzUVL4KR1x8c3yPvBqzMhiTTnbAeQicfT+Go0MoE4XWEgVA9RbPBmnUEPWctxiUyAZj3fi1lO5sAzQ8o82q54tiMI+CwadIkiKxr2oeZS1W4oq3i2okS97RS9e4Xycp6aP2JlTAwg/d5fHAWWjDyq1PE9atR1pqDN3Tqu4zD3yfZylPicQV6WeK65VAThHhqCImG3h2qI+HYjU6EypathwFUAaIQpI0XRGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Nf0lRtSsJmnQ3IoBF+kWYK3/iAh21wGhB9n4z5P49Zk=; b=tsRWj72yzFJZeaB48Z72AkW0wJfzSLo/g/C4MwCzZe9qqgk5kv/t+SZ0hUM3GuGQ8pz1LQXAGMWBnMphUAYGFCcFI9L9By60jNW5R/p/32shlldEdxfTuljfW86dr5vSvLzCbc3t3kijEZXDS+MSOvQwuEZ9Qmzv7070hqmBxuxgq/viwN9DmFFIKUELJWVKpbqGB0CWgHjN8eS3Vf5mWgIJocsa7+7Fa/sS1l/BtDdIEAZPt3rdPgu/ZiBanO9iYxtqcqoF8hqd5NBJTj1mroTtvg45i+mIIg3GJYgNmuKtybOOMdgI+HxRAWkH6s9IyXVXQwXh+x6frmvoxrgchQ== 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=Nf0lRtSsJmnQ3IoBF+kWYK3/iAh21wGhB9n4z5P49Zk=; b=n466+tMySZ/DF3DadMLXyex4Sxif/L5Z3DdixEb43dr0jO/f0GsigMy/DaGLAZ84NRT+6B2884fRkQFWs8A7M21/YLf6NyPl8UyeU0GcDz58T9t/9RX62aUdobKhHOoCCISkypl9yIB/fFpv7gUGStkuY6K2JDQ04JJRxqDwxeM= 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=SATLEXMB04.amd.com; pr=C From: Jason Andryuk To: CC: Jason Andryuk , Oleksii Kurochko , Community Manager Subject: [PATCH] CHANGELOG: Mention xl suspend/resume Date: Thu, 5 Dec 2024 14:50:26 -0500 Message-ID: <20241205195026.3523-1-jason.andryuk@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF00002316:EE_|BN5PR12MB9462:EE_ X-MS-Office365-Filtering-Correlation-Id: e2125333-b0ca-4f32-9ec4-08dd15661105 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|82310400026|36860700013; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?tSQsOiu5+WYPXyxy+6iTDPshB/vyQgUHWjjQ2kfXMpX0XuoPnBSR30K7a/nr?= =?us-ascii?Q?4qAzjFV4naZXNSXyWepC3LRri48+GtbFY2qWypw/vPg3ZNyvlE9/lFsAagJt?= =?us-ascii?Q?0igmPsk+g+KThkbgEMWsifHOINlxxec3O49vXN+9TgDZZ34nCtbuOHtlBKeM?= =?us-ascii?Q?15lHpt5NGMmeZRVE3e86tv8mSd2EKcW1LVL6j8NFT0u5AciURS/psm/hihd9?= =?us-ascii?Q?2mNhlndutGSBu64+U3ZblCnlHeNbLqCokiVP6Uv+I/MOJERmVMw5a8++r43l?= =?us-ascii?Q?SShx3X4s005KFnl9SYITIOzry0vzn5sp0QnluqM4awI/JyRzP0KJwJ24Cass?= =?us-ascii?Q?T065b57IGP3Sjia4D29WnXu7LeTFwyQATSlPv/HiZGP07dOePzZxv0TLszBf?= =?us-ascii?Q?NR5iJ9jYRo3ncp+zU49+MmDc/qeDKqslUHtd4eT+jkEl4Tr5SV2UODbQuE7C?= =?us-ascii?Q?BOjFivjJtuI2PPTq4/MqVrfPgzv8CW/zNbpOdiEQZUNFY7u7LGZpcDxJ/vQX?= =?us-ascii?Q?vzWC7efIANIYTZPgTwikXyaRH3P+khnaGMpzzc7hXRBnH2ZYplPkpY/UCNff?= =?us-ascii?Q?E3ccE2lPI8cPvZsPPxWl96tOJYH9sc3nIBF2HFiq3I/IZ4DKlxpRLlf0uzKW?= =?us-ascii?Q?wXIhSLtl/P+TdF1z041lDH5bmwFQLs0Ct3cpTr1WQ/2ljLwXekHEbPk4NFdR?= =?us-ascii?Q?gHK4Hn9FW6IpChOHTwdw9dQZQWHIrUfpIkzt2ryJIzH1lvWmnwAQ61PJ2+bF?= =?us-ascii?Q?e+ciCbGbsen9bgZ1eH62A8+02PDIoTxIUM3FQS0e4ziiZoIqwWf63s0ytj+r?= =?us-ascii?Q?rY6A3/p6OWoLx/Pn264d6KMBmM1v2LbrvO50FHKNohYMMVc1jdXV0hfczpQz?= =?us-ascii?Q?cxC3VpGEJBy5zeliq3TmsT66x5UoGPDofnEqWsVyqRp6GX3zyllp4FEgThf+?= =?us-ascii?Q?wP9E475jwmtYtHGaJqWGZjev9MlY+aHqa25iMu+xh+aPPxEJWer+ZcHGkk4S?= =?us-ascii?Q?ogdl70dYD8lkt63pPlUJYADUU9fB4qacLJA0pwU6Yw2wJsulPdwv+OrSTp1a?= =?us-ascii?Q?Aij7LozA0LJMdlCtKGjx2IAoXwkZwhfpyiFKG6XTJ22drBufLRYrGYLqsHF9?= =?us-ascii?Q?skOPITD0sm7CT4R9J61jIk5/fJ4a4jBNY6UcWOZoL9H1GWpJQv6vP1UflZlV?= =?us-ascii?Q?YZlUj9FBvIHk7nekz951rjmBnDNVJ45Jx1DQNdq6BuT4ti1qmekT7sXCeZi9?= =?us-ascii?Q?5Ww1uSYIqYGqXAx+PFrMAjMXmgQptZgvYNTJ+3LmmrLWjGDOnhut1OdEcEje?= =?us-ascii?Q?dPEWk6wluVah8scM+b9Vvn9k7wgO/M5xb4ctUlXDBzY0EfRevqRVO84HqmLF?= =?us-ascii?Q?Iyu9r+E5hlCfrvVs1CBQEnKs0uz7glGjgQwUbQNWUgpFw+W6vA=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2024 19:50:27.1344 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e2125333-b0ca-4f32-9ec4-08dd15661105 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF00002316.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN5PR12MB9462 Signed-off-by: Jason Andryuk --- It only works for x86, but it isn't x86-specific. I chose to add it as a generic entry instead of listing it as x86. --- CHANGELOG.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 8553b2e451..5e912b3759 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -16,6 +16,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) ### Added - On Arm: - Experimental support for Armv8-R. + - xl suspend/resume subcommands. ### Removed - On x86: -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Dec 05 20:20:07 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 20:20:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849276.1263905 (Exim 4.92) (envelope-from ) id 1tJIKM-0008Fs-Ss; Thu, 05 Dec 2024 20:19:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849276.1263905; Thu, 05 Dec 2024 20:19:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJIKM-0008Fl-PN; Thu, 05 Dec 2024 20:19:58 +0000 Received: by outflank-mailman (input) for mailman id 849276; Thu, 05 Dec 2024 20:19: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 1tJIKL-0008Ff-6b for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 20:19:57 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on20620.outbound.protection.outlook.com [2a01:111:f403:200a::620]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4a210740-b346-11ef-a0d5-8be0dac302b0; Thu, 05 Dec 2024 21:19:56 +0100 (CET) Received: from PH7P220CA0088.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:32c::32) by PH7PR12MB5901.namprd12.prod.outlook.com (2603:10b6:510:1d5::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.12; Thu, 5 Dec 2024 20:19:50 +0000 Received: from CY4PEPF0000E9D1.namprd03.prod.outlook.com (2603:10b6:510:32c:cafe::4) by PH7P220CA0088.outlook.office365.com (2603:10b6:510:32c::32) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.18 via Frontend Transport; Thu, 5 Dec 2024 20:19:50 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by CY4PEPF0000E9D1.mail.protection.outlook.com (10.167.241.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Thu, 5 Dec 2024 20:19:49 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 5 Dec 2024 14:19:48 -0600 Received: from [172.25.146.163] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Thu, 5 Dec 2024 14:19: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: 4a210740-b346-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=pQdrE2WdP7OIkjtiwNQVpb/OJvb3jnFpxZPruFVM5V9V59sKyS7vCWnxXzgB195yE9Hom44UT2BtYloOy+Saje7tI9ggs/SEEnlIJvu+NwpWy4e2cwc+Vi07K21hg3f8xVifwRoUn5FcSM2vk02RVg1r/yJRguA49QiNE3E/zh8rjyCiWf4/uBvMEhfDRahrB4/4T50LL0dGvzNzGiOdX2MTxjR7q67NpBLLlDHkloHrz/i8n9fBaZTzlv8XLNb3rA1Rx0S2UCqR0ePLc3eml/tMCsfd3cboABs0/XlyRZvqbtmIoEhzuLAgmVMdch1AoIYwHUq7YiDQiJDQ6o+q4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=X6zUfCDw41NNpbHPmzbUDyvlwiQRB4ukS9/Z6rcq9Qc=; b=sX7NA1xmnlqpkW8ZAItAHhnF16LofQu6pZbMy4qhqu76wy3nQtF9FVpoUMvb7H41fesTfDDiABC/D/pWU5Ew+lGVDQ116pxsfqBiXf6YOAr6kJvjEX3uF11Rzv2dVXgGNvLXBXh7ui3woVd2dN8TH/mWjJ9OKJmlNl9XO4PLcuLahc8U++0aPWVzuEFssS0Ti5o4uw+pDnXR6L5DNwwgkfZYM9XW5Fu7ov1WvU95QRkAvqZsE7yZm2/E9qcP6vzZuvs5QJFwFJug7irtt7X6cGCiHsgL+Aa1IzNl2FXqwgCmtrX0EwD5W4BSg2Un6shtqzHigeNgw9P4Hc/YeWU8Mw== 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=X6zUfCDw41NNpbHPmzbUDyvlwiQRB4ukS9/Z6rcq9Qc=; b=cFytW+dI/OdBw35ICDZxSOWutkdOm3DtT3PJ2+CxxClvlngiKMyJa8GDzmH96xioHV8ewmX3+mCfpNteEGWI19rNRKZLaV8Za+jc7NCfEqyje7YvLQicz0RhWGhmiwa4Hj0IA/uWnS0nWDJ7ZPU8N/wBZbw3zvkJUPJpojAPRM0= 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=SATLEXMB03.amd.com; pr=C Message-ID: Date: Thu, 5 Dec 2024 15:19:47 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/4] xen/acpi: upload power and performance related data from a PVH dom0 To: Penny Zheng , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko CC: Ray Huang , Xenia Ragiadakou , , , Roger Pau Monne References: <20241205054252.471761-1-Penny.Zheng@amd.com> <20241205054252.471761-2-Penny.Zheng@amd.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <20241205054252.471761-2-Penny.Zheng@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D1:EE_|PH7PR12MB5901:EE_ X-MS-Office365-Filtering-Correlation-Id: 6d3cfb9d-b9ba-4bc9-be8c-08dd156a2bb0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|376014|1800799024|82310400026; X-Microsoft-Antispam-Message-Info: =?utf-8?B?cXBldGdPMVhWTFVjUFNJeGtCc25vaTE4dmxmNU1Gbkx4N09OK0pTdnRCTmZ2?= =?utf-8?B?OEk4cHh6cEJjUjNrQ0xaRDQ0OE5aeGZlQTEwNjd1Z1RqMmpna3l1MnlCZEVG?= =?utf-8?B?RmZJVkpoZ1ZoMDR2ZjFkNGVoa3VXWmEvcGlmTmpiMFhrYXM4ZG9QbU1Gc2I5?= =?utf-8?B?dEV0UmpNQlo1eWJKRHFJK1NHV0JvaVFycytjdWQ2NFlzZkFpVEJ6OUJja3V4?= =?utf-8?B?dEk0dXlDNTRuaHZSTldWOWtVZmtYK3M0K1Uwb0twK3lkUUp2RWo2TVdxTXRS?= =?utf-8?B?WjJLcUhrYnVqNy8rU0NKMEVwMEpXNUxLMkM5cGdEOGwrTXlCeWUvci80c0c4?= =?utf-8?B?RnppTlJzSjFTaE42OHlONmFlSzN4UWU4b2xWcmNEZUJRT01uRndxWnNOUlJK?= =?utf-8?B?K3U0THdLVFFqSlA2Z0k2UzRQYVY5WngrcDAydjg4K01pU0lEbFZLakUwd1Zq?= =?utf-8?B?RTNVU1l6TlcvalZPcndmWWl4ODBwS2JRMUlzN1I2Wmhac21kd05tcGVGQkNv?= =?utf-8?B?a09OY2cxQlJrb3IrelYwNVplOHBGT1ltZDhJTVBOVkh4QytNRUl3S1NpVUN1?= =?utf-8?B?dzEzb1NTcXJzNkhVVGEydm5mM0J2ZmcxSW9ITTgvQ3NMNW5LTEFGNTVkK3U1?= =?utf-8?B?QVFBdTA4cThzUDE0c3liajY2cDVuMVNnQVl2MmlGNmNFYTgyeUU3RVJJYzJM?= =?utf-8?B?NkpGV2swRkxSK0hlTFdEajdhOXY0Q1ZubGtXU3ZYN3VmVGpJTVV2a2pKT0tk?= =?utf-8?B?NzJmRUJrKzdKbm1iS0h5K1JlVWJ4a2Q3aFlaVEFUbXZYeldBK3d6aXVYKzVj?= =?utf-8?B?ZWNFVWJlOXhQNERHNWZPYVFWU2FwQTVwYVJwM2VHaDNxNmpseVVHbjZZcVY4?= =?utf-8?B?UjVYK25SRFk0ZmduQ0E3RlpscmowdjJJVHpDaXRGaXpMVFRwUHc4SDR1aXVK?= =?utf-8?B?Y3JPT1lNSjJOa1FxbWhXc01qRkxHbUxNUjBQdWEvVjdmZENqQjRacXFUc2Vy?= =?utf-8?B?YUsyejVkdDdMVTUyOWNaTSsrNDNYVCt0ekJaN2Ewc24wK3psUTVxZVdHemo1?= =?utf-8?B?S0dISWxBNUpJNG9Md3NUdW16WTdvNjlTZVY3eDJJdVlBRDhLV09tcWp2VzVo?= =?utf-8?B?YVlUNmJpZFZacWdVTTZLRWNhSEZnb3VwTmp6MkQ3TDZkQXJoRnhoMmJYNzN6?= =?utf-8?B?aUNWWmI3MHdtdUJkbStsWG1Fdm4zc0hYaWVFcTJDU0k3cWt5RUJQeFYweXFB?= =?utf-8?B?alA1UXZVbS84VGZEZDZILzlCb0dFN3luUWtQN05UTHoxeXlKMkJUVHZLTmh2?= =?utf-8?B?MmhJN1U3eUN4VzBobFdUR1Z3UFVabTNzSm8xU01BRjhFbGNzaEF4Uy9HOWdI?= =?utf-8?B?TTlES1djN0RORlJDNjJJT1drRU9kNW9WV2VQaHdnTTJOa2owNDBtRVhjdUZk?= =?utf-8?B?UUpOSEdvNGpRUS90ZVFPSmRCaFFmOU9Ickpyd1hDdE1jOWtBMzl1WDhQcXBU?= =?utf-8?B?RnZYYitzR3F4WkEzZ3VIaVBwQkxtZitocnJWUW5JYnZvNUlVUHBrcC9BYlkv?= =?utf-8?B?b3Zobm42Mm5vR0NSZm91QXF6Ti9OZG9NTHJ3OXlHR3ZDZ1Q5cnhEY0d5V0k1?= =?utf-8?B?ZGtjTTYxdUxEZmVwOWxBNU1JMUprbEdqcTRSaENEK2VGZE45TWV2VDNram9o?= =?utf-8?B?VFIvRm4rY096SFQvS0d4cmlNZlF1MVgwRVAvOHhHUk5aVDc2STN2ZzQvWHdD?= =?utf-8?B?a281VDJzanBKRzEwaVVYU2FWcFpzd25MYXNIRnFKaWNHK2crOWxtUi8xTlRZ?= =?utf-8?B?Wkh5MGpCWno0d0w5eGdGb2pLeWMvblZRazduZko0bUp1YWQ3ZXNMd2dzREVQ?= =?utf-8?B?cHVmMWQ1M1JjeGJWMXdqZk1GVWlQQkQwQkxRelZ1R2J2ZEliWG44MjJUZGNX?= =?utf-8?Q?VOR3QbMsd6jKHSDcibzrisMOiB5L/MIY?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2024 20:19:49.8479 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6d3cfb9d-b9ba-4bc9-be8c-08dd156a2bb0 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=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000E9D1.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5901 On 2024-12-05 00:42, Penny Zheng wrote: > From: Roger Pau Monne > > When running as a PVH dom0 the ACPI MADT is crafted by Xen in order to > report the correct numbers of vCPUs that dom0 has, so the host MADT is > not provided to dom0. This creates issues when parsing the power and > performance related data from ACPI dynamic tables, as the ACPI > Processor UIDs found on the dynamic code are likely to not match the > ones crafted by Xen in the dom0 MADT. > > Xen would rely on Linux having filled at least the power and > performance related data of the vCPUs on the system, and would clone > that information in order to setup the remaining pCPUs on the system > if dom0 vCPUs < pCPUs. However when running as PVH dom0 it's likely > that none of dom0 CPUs will have the power and performance data > filled, and hence the Xen ACPI Processor driver needs to fetch that > information by itself. > > In order to do so correctly, introduce a new helper to fetch the _CST > data without taking into account the system capabilities from the > CPUID output, as the capabilities reported to dom0 in CPUID might be > different from the ones on the host. > > Note that the newly introduced code will only fetch the _CST, _PSS, > _PPC and _PCT from a single CPU, and clone that information for all the > other Processors. This won't work on an heterogeneous system with > Processors having different power and performance related data between > them. > > Signed-off-by: Roger Pau Monné > Signed-off-by: Jason Andryuk Hi Penny, I think you should add your SoB since you are submitting on behalf of Roger and me. Thanks, Jason From xen-devel-bounces@lists.xenproject.org Thu Dec 05 20:50:07 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 20:50:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849288.1263919 (Exim 4.92) (envelope-from ) id 1tJInH-0003yy-0S; Thu, 05 Dec 2024 20:49:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849288.1263919; Thu, 05 Dec 2024 20:49: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 1tJInG-0003yr-Tn; Thu, 05 Dec 2024 20:49:50 +0000 Received: by outflank-mailman (input) for mailman id 849288; Thu, 05 Dec 2024 20:49: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 1tJInF-0003yl-If for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 20:49:49 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on20620.outbound.protection.outlook.com [2a01:111:f403:200a::620]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7578311b-b34a-11ef-99a3-01e77a169b0f; Thu, 05 Dec 2024 21:49:46 +0100 (CET) Received: from SJ0PR03CA0265.namprd03.prod.outlook.com (2603:10b6:a03:3a0::30) by SN7PR12MB7978.namprd12.prod.outlook.com (2603:10b6:806:34b::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.12; Thu, 5 Dec 2024 20:49:40 +0000 Received: from MWH0EPF000A6732.namprd04.prod.outlook.com (2603:10b6:a03:3a0:cafe::6d) by SJ0PR03CA0265.outlook.office365.com (2603:10b6:a03:3a0::30) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.19 via Frontend Transport; Thu, 5 Dec 2024 20:49:40 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by MWH0EPF000A6732.mail.protection.outlook.com (10.167.249.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Thu, 5 Dec 2024 20:49:39 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 5 Dec 2024 14:49:38 -0600 Received: from [172.25.146.163] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Thu, 5 Dec 2024 14:49:37 -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: 7578311b-b34a-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=heyG+CQfYQ3jVLYGf18XZ6z4eK5POExv9CzHxH097VXwK2TQeo9/dyNYPGneeS0dQY/y7dxz6arAmD5K9N6KdvelVw87uDFF5wg3FHFu9+SYNpxBSvlARcFWSUywtaX4IHlsXjrIdiUUvXLWE0Fn0Bcf/Pl33ZfyAIEWEK5DhHjByxTZ1r3hV9gxiiTFiJucDlqXBJte+tXMI3pEaOhBRdz99yAb/Wfzfz+WJxVu+S6lXmgEFfqRZKPTYee8nQHYodl2+VsBXtZ4EtipB9HDUE4gc93M5UzOIPWlNyE6uCsJTjfiyQfJAO5mgo95OkiWWjP1UoIZvwCfsEuY0dAoiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Oq74//hu6lmUd9isYSuyOsexQ6x8BZCWdccvcwf0Vhs=; b=x1uioLgvBvaqI2IFS2iL4emAUNn9GNEcEIsPY5uMXCYbBvj6Fn4qfHVZJeZ02sPQxwx++j+9uT1RD/YbnxpPdRs7QppuHbMn1e1xrnB/21tg2GXpt0IqF8cmhBeSn5A6vrRNp1W0+NcAzJjHtgC7pwWJ6lfbypaDT/D8jknEH2Zz/lH+y80xFzEbZNiFcmbM0klhyAFi7B3gQzoKeXVoXlOjVIQMNnDdfpB1RWL9fACRprXjV2JNozAiEXhbY3xi+BnXxXVHXkCpKj9l9mPSlIeQpj6ghU+Nw+7D3zdzwwzIaHvszZzUd+9olUT+t2uCKFaDzZTicArPf6EsoU/MeA== 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=Oq74//hu6lmUd9isYSuyOsexQ6x8BZCWdccvcwf0Vhs=; b=3kZQbGiK1Wc8Y3ottcy4IHbKRIjNamtTXa0UD6gyJpv5OZSw7mGxpX5hssBlIPrqTZVNa157glirGW8AwYQOtGXr7UqKAx06KFcxFEcpeQ3cY7sNgdTN5D/ldYtfcOsueyZLnVCTBLh6/FsLX2X18hybl8rNh1ztJW2BZdXz4r4= 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=SATLEXMB03.amd.com; pr=C Message-ID: <4227f19d-f065-4563-b48b-538aafe52ed9@amd.com> Date: Thu, 5 Dec 2024 15:49:37 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/4] acpi/cppc: extract _cpc entry parsing logic To: Penny Zheng , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , "Rafael J. Wysocki" , "Len Brown" CC: Ray Huang , Xenia Ragiadakou , , , References: <20241205054252.471761-1-Penny.Zheng@amd.com> <20241205054252.471761-3-Penny.Zheng@amd.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <20241205054252.471761-3-Penny.Zheng@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWH0EPF000A6732:EE_|SN7PR12MB7978:EE_ X-MS-Office365-Filtering-Correlation-Id: fd1d4c96-c0ea-4b10-41a4-08dd156e5696 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026; X-Microsoft-Antispam-Message-Info: =?utf-8?B?dzJoT3dERnd0SFNkSlduSDVHbm85NG5jOXJPMk4yb3A3Tnhubmg5a09VZkVH?= =?utf-8?B?NjRNWDFTZWM3MGJ5TWh6Y3NLVlNNeS83NUtiOFpFT1I5VEpsZStHRW9ZdnJF?= =?utf-8?B?dWlDMFpobUc3RTNDbFFLY21US0xrOUhHTFVUY3NXVnVHU0luV1h5cFJNOVpl?= =?utf-8?B?bFVKMFNYUEI3LzJMMG9KU2dmNVBwQUFPaWtTL1BxMXVBekpyVTZScEYzTEdX?= =?utf-8?B?cGtnSDNsVU5FOE9URXBLQm1OeW1hWDFIUTVBWVZ2WVBPMklWYThLUFozNGhq?= =?utf-8?B?NUlQbGlubDVlZ0pHUkplTzQ0bGtaYVI1eTIyZTJPZndKbWI0cnJUWnp5MVU3?= =?utf-8?B?TzdmcGNxWmcxdVNZcUZVYmZ1bHRUVEdMZnQ0SEViUzNZZnI0UDdnOFhTbW05?= =?utf-8?B?NG8xeFBVK1dpLzVFM3hVdTJ0OEhETER6OVRsQmRZbFFnOHkvaEdWb2hmT05V?= =?utf-8?B?OVk1OVRLSkpGVzZJejQzc0pwczcxd0tsRzd2S2JrTEtGV1lmM2ZjZmtiYTBF?= =?utf-8?B?NlRyRTFXZU5Mc2czb0ZCSTRWMndDcFRjbXNBS3dWUnNtWXJUVnBwZVlYalhM?= =?utf-8?B?UGVJWXROK3I2NkROdlpUQ0FXT1pqVXVrVU5NbjA5QWNXN1p0YldSQ0w5Y0tR?= =?utf-8?B?b1l4dGVnUFBwaWZnZ3ZjT2pxVzJxYlV4bXRVbk5ROHc3ZEJ4SVF1YU0xLzU1?= =?utf-8?B?SS9PdEx4MmY4NEJEZndjTG9GWFdFMExEZTNYN0dBeUhndU4xWXhDK29QUmlL?= =?utf-8?B?UmRlSlNSZzBjbG1rckgrRWVGdUhKclJmRFM4ek5ORTdZVEVTU08xdUtybzl2?= =?utf-8?B?Q3RSbDFBcCtkN09jTHJmby9EdWh4ckdNOXN4dnJ5QzZjQzN4UU9VV2tIQzBY?= =?utf-8?B?a3diaW5uaWMxeGVqRVc2aTlRYTVUd0dxUVViOHRoaTVCUFhBT3B5NHdtR2FZ?= =?utf-8?B?Q3RrTEFkV0RQRWNmd1hJMG9iZGZOQnZYYlNYY3VIbm0wcVM3QmduYXlTN0E4?= =?utf-8?B?N25sMmpsRkxRTTU4Y2lKQlNGa1hzV252dHpHS055MW91R2lRc3poYzVGNDRj?= =?utf-8?B?dWFnUWpjeXhydm9qTVpXM290SHhnb1NHTVRlTFBDNVFaRjdPZUxBT3RpdnFw?= =?utf-8?B?M2NlbWJobXVpeTdVb1lGamNvUk9KNmxLajRTSmlGa3pGcmhZdUpiQjB3QUJo?= =?utf-8?B?blBDaVRnWDlCL0ZSa2FRQXNSR3VORGNUekpYbHEzQmY3VGdyYmU4QnhTdEFU?= =?utf-8?B?dExLRGQ0NnZYb012ZksxRFozWnd0QWduSW5oNWVPYXl1K1Byd3JMYmNsUElQ?= =?utf-8?B?Y0h3aSt5Vk11dk0xcmhHTWZ4RkF3TU9TelBWVnZGTEZXMjJoeFo4QzI1Q0ls?= =?utf-8?B?S1BWU3U3a0Q1Qm5GbUFwaDBNM0FZczZUYjVPS2FtZVl0aFBIemVEUmpJL1FB?= =?utf-8?B?OElScWF5N3cyZ2NTRkoraFJaOXNrWWZ0L0ZTLzFTREMwSTJrYW5YRnRlN2RZ?= =?utf-8?B?cDFPeUU1cG9LM3ArMXNwa1BtUHl1WlFLdE1kekhzYk9VZ0dLSU1PTENzTjRZ?= =?utf-8?B?ZHErTWt1QnJ6TlJZWnNPdWFDczI0bWloRC9sRzJ2WEVuMVR3QmM3MHlzZVJs?= =?utf-8?B?c0NySzlZNFVaZnZ2amhpZ0FFdDE3Uk5zSGxERWcxek11SkZ6dXJuR2JJbUsv?= =?utf-8?B?V0NVNDVnRHNTNVkwWGNuVlRVNm1MVmUweHBUTVBSa3F2UzlMN1Rqam95VFA4?= =?utf-8?B?dTF5WTM5cUFGOHJsZ1RyV0hoV1BXUkdwR2xpUGpua1l6WUYvUUZMeno4VnBy?= =?utf-8?B?TGsvNWVuMUNQS2dqUU5GRUR4T3RWb3BkeWlXTHlVOGhSNW5xRE80Qk9rbVow?= =?utf-8?B?di9qNjk2eHR4TXRMOWhLeVltTW5jblY5a1Z6alBSSVVEbTR1VVN1M3p5NlIy?= =?utf-8?Q?VvhMefGIbE+gOSfAsJarJ49TCN7pzzqM?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2024 20:49:39.8189 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fd1d4c96-c0ea-4b10-41a4-08dd156e5696 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=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: MWH0EPF000A6732.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7978 Adding Rafael and Len, since the patch touches drivers/acpi/. On 2024-12-05 00:42, Penny Zheng wrote: > When running as Xen dom0 PVH guest, MADT table is customized > and may have the "wrong" UID processor number, which is > inconsistent with the UID in Processor entry in native DSDT. > > As a result, during ACPI boot-up for dom0, linux fails to set > up proper processor logical id <-> physical id map(acpi_map_cpuid). > Furthermore, It leads to that some ACPI processor feature data, > like per-cpu cpc_desc structure, failed to be correctly stored. > > In order to re-parse _CPC entry later for delivering correct data > in performance hypercall, firstly, we extract parsing logic from > acpi_cppc_processor_probe() and export it as a new function > acpi_cppc_processor_parse(). > > Also, replace logical processor id with ACPI ID, to show correct print > info in Xen dom0 PVH guest. > > Signed-off-by: Penny Zheng Reviewed-by: Jason Andryuk No further comments by me - leaving untrimmed for Rafael and Len. Regards, Jason > --- > drivers/acpi/cppc_acpi.c | 93 +++++++++++++++++++++++----------------- > 1 file changed, 53 insertions(+), 40 deletions(-) > > diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c > index c3fc2c05d868..13d6ff84a1e9 100644 > --- a/drivers/acpi/cppc_acpi.c > +++ b/drivers/acpi/cppc_acpi.c > @@ -675,19 +675,11 @@ static int pcc_data_alloc(int pcc_ss_id) > static inline void arch_init_invariance_cppc(void) { } > #endif > > -/** > - * acpi_cppc_processor_probe - Search for per CPU _CPC objects. > - * @pr: Ptr to acpi_processor containing this CPU's logical ID. > - * > - * Return: 0 for success or negative value for err. > - */ > -int acpi_cppc_processor_probe(struct acpi_processor *pr) > +static int acpi_cppc_processor_parse(struct acpi_processor *pr, struct cpc_desc *cpc_ptr) > { > struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL}; > union acpi_object *out_obj, *cpc_obj; > - struct cpc_desc *cpc_ptr; > struct cpc_reg *gas_t; > - struct device *cpu_dev; > acpi_handle handle = pr->handle; > unsigned int num_ent, i, cpc_rev; > int pcc_subspace_id = -1; > @@ -706,31 +698,24 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) > status = acpi_evaluate_object_typed(handle, "_CPC", NULL, &output, > ACPI_TYPE_PACKAGE); > if (ACPI_FAILURE(status)) { > - ret = -ENODEV; > - goto out_buf_free; > + return -ENODEV; > } > > out_obj = (union acpi_object *) output.pointer; > > - cpc_ptr = kzalloc(sizeof(struct cpc_desc), GFP_KERNEL); > - if (!cpc_ptr) { > - ret = -ENOMEM; > - goto out_buf_free; > - } > - > /* First entry is NumEntries. */ > cpc_obj = &out_obj->package.elements[0]; > if (cpc_obj->type == ACPI_TYPE_INTEGER) { > num_ent = cpc_obj->integer.value; > if (num_ent <= 1) { > pr_debug("Unexpected _CPC NumEntries value (%d) for CPU:%d\n", > - num_ent, pr->id); > - goto out_free; > + num_ent, pr->acpi_id); > + goto out_pointer; > } > } else { > pr_debug("Unexpected _CPC NumEntries entry type (%d) for CPU:%d\n", > - cpc_obj->type, pr->id); > - goto out_free; > + cpc_obj->type, pr->acpi_id); > + goto out_pointer; > } > > /* Second entry should be revision. */ > @@ -739,14 +724,14 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) > cpc_rev = cpc_obj->integer.value; > } else { > pr_debug("Unexpected _CPC Revision entry type (%d) for CPU:%d\n", > - cpc_obj->type, pr->id); > - goto out_free; > + cpc_obj->type, pr->acpi_id); > + goto out_pointer; > } > > if (cpc_rev < CPPC_V2_REV) { > pr_debug("Unsupported _CPC Revision (%d) for CPU:%d\n", cpc_rev, > - pr->id); > - goto out_free; > + pr->acpi_id); > + goto out_pointer; > } > > /* > @@ -758,8 +743,8 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) > (cpc_rev == CPPC_V3_REV && num_ent != CPPC_V3_NUM_ENT) || > (cpc_rev > CPPC_V3_REV && num_ent <= CPPC_V3_NUM_ENT)) { > pr_debug("Unexpected number of _CPC return package entries (%d) for CPU:%d\n", > - num_ent, pr->id); > - goto out_free; > + num_ent, pr->acpi_id); > + goto out_pointer; > } > if (cpc_rev > CPPC_V3_REV) { > num_ent = CPPC_V3_NUM_ENT; > @@ -793,7 +778,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) > goto out_free; > } else if (pcc_subspace_id != gas_t->access_width) { > pr_debug("Mismatched PCC ids in _CPC for CPU:%d\n", > - pr->id); > + pr->acpi_id); > goto out_free; > } > } else if (gas_t->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) { > @@ -848,7 +833,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) > memcpy(&cpc_ptr->cpc_regs[i-2].cpc_entry.reg, gas_t, sizeof(*gas_t)); > } else { > pr_debug("Invalid entry type (%d) in _CPC for CPU:%d\n", > - i, pr->id); > + i, pr->acpi_id); > goto out_free; > } > } > @@ -864,6 +849,45 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) > cpc_ptr->cpc_regs[i].cpc_entry.int_value = 0; > } > > + pr_debug("Parsed _CPC entry for CPU: %d\n", pr->acpi_id); > + kfree(output.pointer); > + return 0; > + > + out_free: > + /* Free all the mapped sys mem areas for this CPU */ > + for (i = 2; i < cpc_ptr->num_entries; i++) { > + void __iomem *addr = cpc_ptr->cpc_regs[i-2].sys_mem_vaddr; > + > + if (addr) > + iounmap(addr); > + } > + out_pointer: > + kfree(output.pointer); > + return ret; > +} > + > +/** > + * acpi_cppc_processor_probe - Search for per CPU _CPC objects. > + * @pr: Ptr to acpi_processor containing this CPU's logical ID. > + * > + * Return: 0 for success or negative value for err. > + */ > +int acpi_cppc_processor_probe(struct acpi_processor *pr) > +{ > + acpi_handle handle = pr->handle; > + struct cpc_desc *cpc_ptr; > + struct device *cpu_dev; > + int pcc_subspace_id = -1; > + int ret = -ENODATA; > + > + cpc_ptr = kzalloc(sizeof(struct cpc_desc), GFP_KERNEL); > + if (!cpc_ptr) > + return -ENOMEM; > + > + ret = acpi_cppc_processor_parse(pr, cpc_ptr); > + if (ret) > + goto out_free; > + pcc_subspace_id = per_cpu(cpu_pcc_subspace_idx, pr->id); > > /* Store CPU Logical ID */ > cpc_ptr->cpu_id = pr->id; > @@ -907,21 +931,10 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) > > arch_init_invariance_cppc(); > > - kfree(output.pointer); > return 0; > > out_free: > - /* Free all the mapped sys mem areas for this CPU */ > - for (i = 2; i < cpc_ptr->num_entries; i++) { > - void __iomem *addr = cpc_ptr->cpc_regs[i-2].sys_mem_vaddr; > - > - if (addr) > - iounmap(addr); > - } > kfree(cpc_ptr); > - > -out_buf_free: > - kfree(output.pointer); > return ret; > } > EXPORT_SYMBOL_GPL(acpi_cppc_processor_probe); From xen-devel-bounces@lists.xenproject.org Thu Dec 05 21:11:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 21:11:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849305.1263928 (Exim 4.92) (envelope-from ) id 1tJJ8X-0007wW-Qw; Thu, 05 Dec 2024 21:11:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849305.1263928; Thu, 05 Dec 2024 21: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 1tJJ8X-0007wP-OI; Thu, 05 Dec 2024 21:11:49 +0000 Received: by outflank-mailman (input) for mailman id 849305; Thu, 05 Dec 2024 21:11: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 1tJJ8W-0007wJ-Fe for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 21:11:48 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on20605.outbound.protection.outlook.com [2a01:111:f403:2412::605]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 884a87a7-b34d-11ef-a0d5-8be0dac302b0; Thu, 05 Dec 2024 22:11:46 +0100 (CET) Received: from BN9PR03CA0044.namprd03.prod.outlook.com (2603:10b6:408:fb::19) by SJ0PR12MB8616.namprd12.prod.outlook.com (2603:10b6:a03:485::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Thu, 5 Dec 2024 21:11:38 +0000 Received: from BL6PEPF0002256E.namprd02.prod.outlook.com (2603:10b6:408:fb:cafe::47) by BN9PR03CA0044.outlook.office365.com (2603:10b6:408:fb::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.17 via Frontend Transport; Thu, 5 Dec 2024 21:11:38 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by BL6PEPF0002256E.mail.protection.outlook.com (10.167.249.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Thu, 5 Dec 2024 21:11:38 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 5 Dec 2024 15:11:37 -0600 Received: from SATLEXMB04.amd.com (10.181.40.145) 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; Thu, 5 Dec 2024 15:11:37 -0600 Received: from [172.25.146.163] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Thu, 5 Dec 2024 15:11:36 -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: 884a87a7-b34d-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=EOG6tLHzr5nSIOzRQH+zyFsWmmbF0yM3p3HygoEXJ+FCFFJ7+EOiHF0o0H+/7DWswNSUBi9lX9gsghO8lqaoJRSN5E0PW5tKZEP0i1e6OrFKcIu3F243Oci3vy45j63QUae/1bsLh022v6Xlul631tgen6M0/KubtfgS16QRBBl3GU6dZmnd17jZkZ7NIQTern6e20YPcQdtvDLVO8cNFUVsX9b+/7pV37u2meRZKWV4EbZnlosKRuEoEl5BhdFJYsYNLX3aNjx2yXiO/9A+0VCcBloIeZQVtNfTSijgXq5K95lGbAV9ihtjkZ7OVAfPVnr6roTZY8xf8jXBA4PAcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HwNo/Z+AaJnqKbx3t2X1NFa9blJOGIv2GNPm6Ol7lv8=; b=ZJbBeolNvVgrfkkt7AtB6DxV0bVjEdeZkMBuzJI4QFPWSAQRKlqxUWY7ZLWjhya7krmIcnA01xMrLKTimFRWeJyGg9ajnRFY5qC34Qm8RkgAGJSOZGTk6Ektwdr7CEtsvwYyK4lkvEBJVrzQpS6iKMQBzQFO98R+JEMcMZOKtwr0Z3cL0xdmkojIVoCa57mX9NSGvhDhB9oLiIONq0k27Ku6DY++NcLnua9GkObehL9tPcKCwddEkjz+mGAdJ8gV0xuEpXZOHIQO31d3G4APLOqy7fb7ahRvZARliK6sbY95hfNnnmiSiBMm2LuF0VOmwwE7HfB8eU0BUAsUWWzaqA== 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=HwNo/Z+AaJnqKbx3t2X1NFa9blJOGIv2GNPm6Ol7lv8=; b=FOfA9yT+OOnGiUWHVQ5ia7kq6nPfwyHZ7YTsXnS4ulx1ZP+Lu7pVm1lIQYcowyVb+lTsxe+RL/YIVCRZZGvZJxGsgRefmsDH2B8+qnwMLseG5JEv2qs9UuDOhGxYNWAxuB9YoGJpDfl+m7iSFEOH0Ls8okL71hDK8GVmlde/jrU= 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=SATLEXMB03.amd.com; pr=C Message-ID: <81d0f983-eea5-477b-9e8c-7da572914335@amd.com> Date: Thu, 5 Dec 2024 16:11:36 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/4] xen/cppc: get xen-required cppc perf caps data To: Penny Zheng , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , "Rafael J. Wysocki" , Len Brown CC: Ray Huang , Xenia Ragiadakou , , , References: <20241205054252.471761-1-Penny.Zheng@amd.com> <20241205054252.471761-4-Penny.Zheng@amd.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <20241205054252.471761-4-Penny.Zheng@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL6PEPF0002256E:EE_|SJ0PR12MB8616:EE_ X-MS-Office365-Filtering-Correlation-Id: 23d477f3-baab-4374-3b28-08dd15716852 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700013|82310400026|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?N3BjdzUrRi9uK2tTYzRyTjF0UVVzMzFOZklEbnFzMktlNmFXd0hPZWZlcVBs?= =?utf-8?B?dmlzKzhPRDYwM0dVVUtlb2k2YVpUNHdWV2Y3NnZJZzF3MjJoaFJoUW13OVd2?= =?utf-8?B?bWtHVFYrOFFOWEhvcnN0QTJOZGFtdmRkMEhadnpENys1V2hMb3NKanVWZmo2?= =?utf-8?B?NE5UK3J6bmgxL3R2WUx0Q3pORGFFQnBVdm1DMnJhbVV4eDRhWkluZU53TExt?= =?utf-8?B?ZThXTnVFeVR0VFAwS2huZUlsTWM3ZlpndVg2OCtmVmRScjE2K1BPZlZKOEdB?= =?utf-8?B?NzN3ekp2bWRqcVphdnhWQ2hBR2wzYURzZDFlYkdZNU00L1JEMlgrZWR3dUg5?= =?utf-8?B?MmtWdW1zRWl1dk0zY0tDMGpqNDFobW4rb0NpYU5WakRkc3E4MURwZjQyWFR5?= =?utf-8?B?dVBId1Q3WVFUMHpLdVpGbEZudXA2UVZoRzhoTjJyblAxaVA3Q1BZcjhaeWhG?= =?utf-8?B?V1kyOXV5a1I4bW5CcTBVVDU5Y3J5bjJXN1d4bFRXTTIvdkk5NlNPTU1pbk91?= =?utf-8?B?RCtocmNNaTdZdzMvOWVzL3ZUQVExU2tVaTVzUjlpWjFTZXZkdlowbjVhQ0Iv?= =?utf-8?B?Z3BvbmpVQXlYV2g1OS9kN3BPQmN4SjdaVGpIUzNZY2l1bjRZRm1ZRW9BbmJC?= =?utf-8?B?dXZKUzk2MDBNb3VGWDNUVm9xMTJyRGFLalExS3dBQy9tbGY5RXkrL0ROZUVo?= =?utf-8?B?RlpxeXMzRlR2eGw0UDVhdmp0d2U2U2tXd0JuYkU0SE1hcUxaTkJGSVg0djVZ?= =?utf-8?B?THIzV3ZmaWVobUx1Z3NNUXptYnFvcFEySzlMRTZhRHByOEVDMWFSREVhUzR2?= =?utf-8?B?UU9lUHZqdXpta1FuSkxiLzNHd3AxaHcxU2VzT0xMM1FmbGVoaU5PdmZORE84?= =?utf-8?B?a1lvaVY5a21wV1lhSnAvTmhLeUFvcFFJWU11cHFoYkpwU0tSSk1vREtwY3Rp?= =?utf-8?B?dllTTHpRQ2R2ZWNtaEx1MVB2OURVZjcyTUl2LzVWZGVxbTB3Uk5RZ0swTkNI?= =?utf-8?B?bS9CVmkzK09DQUwzNlBBVkx3N2VaM00vTnR5RjFyRHJqemFmRVFKSmFWd0sz?= =?utf-8?B?T3E2WjBKcC81K1k4TDVaRnRRdXkxaktoMHJhTkI2RnZzazBORm9JcXZpdjBz?= =?utf-8?B?UzlZcmRsY24zSm9kMVFmb2VBc1pGZllZWmtJNkdqQVgzUmpENkdjVnZvWFIy?= =?utf-8?B?UDlyNm1pR2U4em80SVhkbHg2SVNnREVXWDdwNUVkRXBCaWM2YXRncGpuYzlE?= =?utf-8?B?Tk05R0w2OHlmL2swaURGVEtvcE5aTlY2bzFuc3lsN2Z1aDhDcEtHNXNWQnhz?= =?utf-8?B?WEhnQTZ5Y3VqNkdEYjRScU4vYVBwcVBuWDhMajRxenBpWERZaTN6eXRoVzJX?= =?utf-8?B?SFAveDJLZmd6dURLcCtBL3ZKdnZ6Nnh1VEhqc25zRUY4WTI5NEtwcGdVN0JV?= =?utf-8?B?RE9QM0hxUUVNaGV4UGpOZFN4ME5PUkE5MDhFcG81ZkdnN0FRb09zb2l2VUts?= =?utf-8?B?UnlrR2NVVkI5bWZTc3B5dyt2NTdsMUNDeXVXTjZoNlQ2WTlxQjR3NlBHcm40?= =?utf-8?B?SCtHK3FzcHlxQjlkU3RCOHR4bXJvSDVCMkNnVnFMWlFKN0NSWG5XMHl2VHdk?= =?utf-8?B?OXo2MmpOc0xyRHRybnltdnRxNzRYck1lMjA3TGFYSm1oV3ZzckpvS2ZLaGhZ?= =?utf-8?B?TzRwTlRhS093QTZZVXpYbEo0bk9Ib0U1Y2o2TTREMmVFeENKUE1xNnBPMGM2?= =?utf-8?B?Yyt6d3UxbkFiU0dtRDlMZ3N2NWtETXVNS2tGY3RTdkhUUndDQzVET1ZFajU3?= =?utf-8?B?RVJRNTR4M3BJV0Z3ajZPaVkrdHZYM0NjejFEOVZxWUFFRUhsajBEUURwcWhw?= =?utf-8?B?MUJXYXZWOStVejdFaU92djNmUTRjZ0V1R05WZThSL0VqRjJxZUN3LzQydDIx?= =?utf-8?Q?wp7VhpvOKtHjKDT20YP0mqSh8GW5X9Nk?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(82310400026)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2024 21:11:38.1560 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 23d477f3-baab-4374-3b28-08dd15716852 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=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL6PEPF0002256E.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB8616 Add Rafael and Len, On 2024-12-05 00:42, Penny Zheng wrote: > When running as Xen dom0 PVH guest, processor logical id <-> physical > id map could not be properly set up. So the original function > cppc_get_perf_caps() fails to get correct cppc data for Xen ACPI > processor. > > A new function xen_processor_get_perf_caps() is introduced to > get xen-required cppc perf caps data. > > Also, as Xen couldn't read and process PCC-type register, this commit > includes a new flag pcc_unsupported in struct acpi_processor_flags to > tell whether platform supports PCC-type register. > > Signed-off-by: Penny Zheng Reviewed-by: Jason Andryuk Again, no further comments - keeping full patch for others. Regards, Jason > --- > drivers/acpi/cppc_acpi.c | 110 +++++++++++++++++++++++++++++++++++---- > include/acpi/cppc_acpi.h | 5 ++ > include/acpi/processor.h | 1 + > 3 files changed, 105 insertions(+), 11 deletions(-) > > diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c > index 13d6ff84a1e9..3a436591da07 100644 > --- a/drivers/acpi/cppc_acpi.c > +++ b/drivers/acpi/cppc_acpi.c > @@ -772,6 +772,15 @@ static int acpi_cppc_processor_parse(struct acpi_processor *pr, struct cpc_desc > * so extract it only once. > */ > if (gas_t->space_id == ACPI_ADR_SPACE_PLATFORM_COMM) { > + /* > + * When ACPI processor represents Xen processor, PCC register type > + * could not be properly read and processed right now, as logical > + * processor doesn't always have 1:1 map relation to physical processor. > + */ > + if (pr->flags.pcc_unsupported) { > + pr_debug("Unsupported PCC register type:%d\n", pr->acpi_id); > + goto out_free; > + } > if (pcc_subspace_id < 0) { > pcc_subspace_id = gas_t->access_width; > if (pcc_data_alloc(pcc_subspace_id)) > @@ -837,7 +846,9 @@ static int acpi_cppc_processor_parse(struct acpi_processor *pr, struct cpc_desc > goto out_free; > } > } > - per_cpu(cpu_pcc_subspace_idx, pr->id) = pcc_subspace_id; > + > + if (!pr->flags.pcc_unsupported) > + per_cpu(cpu_pcc_subspace_idx, pr->id) = pcc_subspace_id; > > /* > * Initialize the remaining cpc_regs as unsupported. > @@ -1018,8 +1029,7 @@ int __weak cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val) > static int cpc_read(int cpu, struct cpc_register_resource *reg_res, u64 *val) > { > void __iomem *vaddr = NULL; > - int size; > - int pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpu); > + int size, pcc_ss_id; > struct cpc_reg *reg = ®_res->cpc_entry.reg; > > if (reg_res->type == ACPI_TYPE_INTEGER) { > @@ -1044,14 +1054,17 @@ static int cpc_read(int cpu, struct cpc_register_resource *reg_res, u64 *val) > > *val = val_u32; > return 0; > - } else if (reg->space_id == ACPI_ADR_SPACE_PLATFORM_COMM && pcc_ss_id >= 0) { > - /* > - * For registers in PCC space, the register size is determined > - * by the bit width field; the access size is used to indicate > - * the PCC subspace id. > - */ > - size = reg->bit_width; > - vaddr = GET_PCC_VADDR(reg->address, pcc_ss_id); > + } else if (reg->space_id == ACPI_ADR_SPACE_PLATFORM_COMM) { > + pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpu); > + if (pcc_ss_id >= 0) { > + /* > + * For registers in PCC space, the register size is determined > + * by the bit width field; the access size is used to indicate > + * the PCC subspace id. > + */ > + size = reg->bit_width; > + vaddr = GET_PCC_VADDR(reg->address, pcc_ss_id); > + } > } > else if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) > vaddr = reg_res->sys_mem_vaddr; > @@ -1282,6 +1295,81 @@ int cppc_get_epp_perf(int cpunum, u64 *epp_perf) > } > EXPORT_SYMBOL_GPL(cppc_get_epp_perf); > > + > +int xen_processor_get_perf_caps(struct acpi_processor *pr, struct cppc_perf_caps *perf_caps) > +{ > + struct cpc_desc *cpc_ptr; > + struct cpc_register_resource *highest_reg, *lowest_reg, > + *lowest_non_linear_reg, *nominal_reg, > + *low_freq_reg = NULL, *nom_freq_reg = NULL; > + u64 high, low, nom, min_nonlinear, low_f = 0, nom_f = 0; > + int ret = 0; > + > + cpc_ptr = kzalloc(sizeof(struct cpc_desc), GFP_KERNEL); > + if (!cpc_ptr) > + return -ENOMEM; > + > + ret = acpi_cppc_processor_parse(pr, cpc_ptr); > + if (ret) > + goto err; > + > + highest_reg = &cpc_ptr->cpc_regs[HIGHEST_PERF]; > + lowest_reg = &cpc_ptr->cpc_regs[LOWEST_PERF]; > + lowest_non_linear_reg = &cpc_ptr->cpc_regs[LOW_NON_LINEAR_PERF]; > + nominal_reg = &cpc_ptr->cpc_regs[NOMINAL_PERF]; > + low_freq_reg = &cpc_ptr->cpc_regs[LOWEST_FREQ]; > + nom_freq_reg = &cpc_ptr->cpc_regs[NOMINAL_FREQ]; > + > + /* Are any of the regs PCC ?*/ > + if (CPC_IN_PCC(highest_reg) || CPC_IN_PCC(lowest_reg) || > + CPC_IN_PCC(lowest_non_linear_reg) || CPC_IN_PCC(nominal_reg) || > + CPC_IN_PCC(low_freq_reg) || CPC_IN_PCC(nom_freq_reg)) { > + pr_debug("Unsupported register type read for Xen Processor %d," > + "highest_reg in PCC: %s, lowest_reg in PCC: %s," > + "lowest_non_linear_reg in PCC: %s, nominal_reg in PCC: %s," > + "low_freq_reg in PCC: %s, nom_freq_reg in PCC: %s\n", > + pr->acpi_id, CPC_IN_PCC(highest_reg) ? "true" : "false", > + CPC_IN_PCC(lowest_reg) ? "true" : "false", > + CPC_IN_PCC(lowest_non_linear_reg) ? "true" : "false", > + CPC_IN_PCC(nominal_reg) ? "true" : "false", > + CPC_IN_PCC(low_freq_reg) ? "true" : "false", > + CPC_IN_PCC(nom_freq_reg) ? "true" : "false"); > + goto err; > + } > + > + cpc_read(pr->acpi_id, highest_reg, &high); > + perf_caps->highest_perf = high; > + > + cpc_read(pr->acpi_id, lowest_reg, &low); > + perf_caps->lowest_perf = low; > + > + cpc_read(pr->acpi_id, nominal_reg, &nom); > + perf_caps->nominal_perf = nom; > + > + cpc_read(pr->id, lowest_non_linear_reg, &min_nonlinear); > + perf_caps->lowest_nonlinear_perf = min_nonlinear; > + > + if (!high || !low || !nom || !min_nonlinear) > + pr_warn("CPPC: read zero cpc register value for Xen Processor %d" > + "highest_reg: %llu, lowest_reg: %llu" > + "nominal_reg: %llu, lowest_non_linear_reg: %llu\n", > + pr->acpi_id, high, low, nom, min_nonlinear); > + > + /* Read optional lowest and nominal frequencies if present */ > + if (CPC_SUPPORTED(low_freq_reg)) > + cpc_read(pr->acpi_id, low_freq_reg, &low_f); > + > + if (CPC_SUPPORTED(nom_freq_reg)) > + cpc_read(pr->acpi_id, nom_freq_reg, &nom_f); > + > + perf_caps->lowest_freq = low_f; > + perf_caps->nominal_freq = nom_f; > + > + err: > + kfree(cpc_ptr); > + return ret; > +} > +EXPORT_SYMBOL_GPL(xen_processor_get_perf_caps); > /** > * cppc_get_perf_caps - Get a CPU's performance capabilities. > * @cpunum: CPU from which to get capabilities info. > diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h > index 76e44e102780..2281110c00b7 100644 > --- a/include/acpi/cppc_acpi.h > +++ b/include/acpi/cppc_acpi.h > @@ -164,6 +164,7 @@ extern int cppc_set_auto_sel(int cpu, bool enable); > extern int amd_get_highest_perf(unsigned int cpu, u32 *highest_perf); > extern int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator); > extern int amd_detect_prefcore(bool *detected); > +extern int xen_processor_get_perf_caps(struct acpi_processor *pr, struct cppc_perf_caps *perf_caps); > #else /* !CONFIG_ACPI_CPPC_LIB */ > static inline int cppc_get_desired_perf(int cpunum, u64 *desired_perf) > { > @@ -249,6 +250,10 @@ static inline int amd_detect_prefcore(bool *detected) > { > return -ENODEV; > } > +static inline int xen_processor_get_perf_caps(struct acpi_processor *pr, struct cppc_perf_caps *perf_caps) > +{ > + return -ENOTSUPP; > +} > #endif /* !CONFIG_ACPI_CPPC_LIB */ > > #endif /* _CPPC_ACPI_H*/ > diff --git a/include/acpi/processor.h b/include/acpi/processor.h > index e6f6074eadbf..18499cc11366 100644 > --- a/include/acpi/processor.h > +++ b/include/acpi/processor.h > @@ -214,6 +214,7 @@ struct acpi_processor_flags { > u8 bm_control:1; > u8 bm_check:1; > u8 has_cst:1; > + u8 pcc_unsupported:1; > u8 has_lpi:1; > u8 power_setup_done:1; > u8 bm_rld_set:1; From xen-devel-bounces@lists.xenproject.org Thu Dec 05 22:09:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Dec 2024 22:09:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849348.1263955 (Exim 4.92) (envelope-from ) id 1tJK2D-0006mb-9j; Thu, 05 Dec 2024 22:09:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849348.1263955; Thu, 05 Dec 2024 22: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 1tJK2D-0006mU-6u; Thu, 05 Dec 2024 22:09:21 +0000 Received: by outflank-mailman (input) for mailman id 849348; Thu, 05 Dec 2024 22: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 1tJK2B-0006mM-Rp for xen-devel@lists.xenproject.org; Thu, 05 Dec 2024 22:09:20 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on20615.outbound.protection.outlook.com [2a01:111:f403:2412::615]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 90dd9a86-b355-11ef-a0d5-8be0dac302b0; Thu, 05 Dec 2024 23:09:17 +0100 (CET) Received: from SJ0PR03CA0033.namprd03.prod.outlook.com (2603:10b6:a03:33e::8) by SA1PR12MB8724.namprd12.prod.outlook.com (2603:10b6:806:38b::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.11; Thu, 5 Dec 2024 22:09:00 +0000 Received: from SJ5PEPF000001CE.namprd05.prod.outlook.com (2603:10b6:a03:33e:cafe::ab) by SJ0PR03CA0033.outlook.office365.com (2603:10b6:a03:33e::8) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.11 via Frontend Transport; Thu, 5 Dec 2024 22:08:59 +0000 Received: from SATLEXMB03.amd.com (165.204.84.17) by SJ5PEPF000001CE.mail.protection.outlook.com (10.167.242.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Thu, 5 Dec 2024 22:08:59 +0000 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 5 Dec 2024 16:08:58 -0600 Received: from [172.25.146.163] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Thu, 5 Dec 2024 16:08:57 -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: 90dd9a86-b355-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Tqjkbz8yHYCzQzvgXV/qScrbsUj7/hHZ6wWMJ9EzcZSoko7zknAS8FxS1Hibjqjo8gimtdghN7AsyzAJd/LnhDbqZiN9szA5ch6MkdKWIX/ixJEvhg14cteOCCH61IMurTeDYSvr1hS9VRSWjZCsklr1BZjVclxhvXwf7J81UbB7Y+j26zFwQnALMIMS/bGSvLYiRH2ygHBKsBwddyc7W7xk7Z1H8Thv/ccsj7lewvA3Yw3wjJxtoHBjy5MmRIgebKtGvPMlbpXFjHdI2RbItYWsuL3WEfq2aftZdgp3RXZedOgtdUYSxNmWwRcx1QNoLLGkPEUfhgU3He5OUjdJ4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=i2oNJqsZFkdjC6f4t8Tnc11EcksGmoxUcgBJOkfzPoY=; b=VwmK2oTBr+vql5c2HtzRA1z20V/u44HikdiDCQ/9NK04iMV0TEPaWmwiAV0+tsjMcdryaqrQxg/T6K1ghnHJfK7WsX8LGe8rtPqxj1I+PL9Yobg1c6Ig/MMp+cGtSSB6SGGxumbhFHL8PolwGuG0w5SMeA+J7kuMueyeKY1xKOYd+20vCPFYsry4t5q1TOSDEqalDdjfVHkTbkU1oyFuBsw/kOu5QDDSHKblCpx8y77Di4yw+Q8FhYg9yWHGByKlUQHA2jXYqXrT8LnVAFWr5etSyNYN8BqFqUwWW3f9d9dVXOyguwHIvE8263ZR2ds1OnIvKryilgnWOgy82sVXAg== 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=i2oNJqsZFkdjC6f4t8Tnc11EcksGmoxUcgBJOkfzPoY=; b=m3UBIRjrhQLVRFdx1aAAt1Gx1R1+1MjUO7Bj64YrXJCs4ZujsX8yVk/Rmqsw1iYply5MSWOvQqvFdpUfYKDXaZCTJWYdmgMnMoBc4DVfDUf6dm1DeGn85IvGdDCQp5S5/AakNqdeIXsICVV/pBll89Pd8hRDl1vxGBICdm/NYNQ= 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=SATLEXMB03.amd.com; pr=C Message-ID: Date: Thu, 5 Dec 2024 17:08:56 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/4] xen/cppc: introduce cppc data upload sub-hypercall To: Penny Zheng , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , "Rafael J. Wysocki" , "Len Brown" CC: Ray Huang , Xenia Ragiadakou , , , References: <20241205054252.471761-1-Penny.Zheng@amd.com> <20241205054252.471761-5-Penny.Zheng@amd.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <20241205054252.471761-5-Penny.Zheng@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001CE:EE_|SA1PR12MB8724:EE_ X-MS-Office365-Filtering-Correlation-Id: 52b65e50-943e-4b44-3ac9-08dd15796b88 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?UkozUitXU2ZFVTg4Zit4V3B3ajJVNHNGZkJ2ZXJCR1VHRkV2dTlYK1h3UEdS?= =?utf-8?B?WmRmRnBnVi9hNlNuYjBBQWJIeDhleG03dlJnV29ZWnY4N2JsZlUvWitiNVda?= =?utf-8?B?Tys4VzJkUmxUVXNUTm5scGp5SG1UcGYwYTE3MkRFa1JaazdxVkQyYUZTUWJY?= =?utf-8?B?S2tmeUxiOGx1SmtISnh6bmY0Z1NIQnhSR1B2R0JWczBVSU9tNU5mR2h3UWFW?= =?utf-8?B?QzBtRmFDK0NWamxybGY4N0pvOVdqd0xQMExmMjBXWlREdklCSXRpTWdGN2tj?= =?utf-8?B?YTFKRkJvSndWOUdDdmJiV0RydDN4KzFiV29mM3VWNHlLK0xUTzFDVjI5VE9p?= =?utf-8?B?cFdPcVhrZkhJMXgzTnR0bndKQUkrU0RLN05vem81bVU3enVSS0VGZnhUSG15?= =?utf-8?B?c3VtR2tIZExHTWRlZ0Z4Qkh6OUg3UFd4MXFkTExBeXlEVGEzRVVuWm1mR09q?= =?utf-8?B?LzdBbE9GekpHV0JDUGJWWUlOMzUrRkJIWENuc242ZllsUlB4cjlpeXMySzdw?= =?utf-8?B?MlRqVnpZcDlsZjdnNC9lZ0JCQy9ZWGpabHdNVklYVk5WZ21uNnljem0vbGVU?= =?utf-8?B?N1BHQS83ZTJWSDJIa1htaXlBZG80dGlqRVl0RXAzbWJhR2ZTMUxaV1ltSmVS?= =?utf-8?B?L24ycmE2Z0x3OWRyUmw4bVpWN0NLZUtVdUNtWWxXc01kdUpVcXhJQmVUT3NC?= =?utf-8?B?ekdtR05ueEI2dFI5RzVyaysyT1BaMzhOMEJuRlkxS2ZmZjVvWm1kQTJjQjVF?= =?utf-8?B?a3ZkMElSTVFseTRSL0gzU2hYbXZiUE9hU0N2UjY5OXNTL0RlM1RFb3lQNzBs?= =?utf-8?B?QXd6V21OVjdFdUxDbitlSklQSzJBOWxnUEYwdGxCSXc5aUFQVlZFNm11NzRY?= =?utf-8?B?TnQxZkF6TjlIanhxTnBmYzJsV0UrdHJKd1BQSmpZTnhXSWVqZ3BGN3hub0tJ?= =?utf-8?B?R205ZktyZk5wYitHUS9LOWduc0VMZ1J0WVVHWkxvQ1oyYTh3V3dlQjIycjR4?= =?utf-8?B?RUFUNFZXQmhlTjJqdWdveTZWbTc1WklRVUE1emlLYlVGNVk0Wk5jYUVDL0M4?= =?utf-8?B?MFU0R3RsUCs1QisxMi96SE5adUswOUg5ZnpPWi9wdHB6RFlVRDB6ZG1JV1Fh?= =?utf-8?B?NjZCdHRVSXhjcTQzMTJHUDRrSThQd0gvem5vS1REWE1kbG9la2IveW1icXBV?= =?utf-8?B?d1lrNU5VMG1jQnpmR2pkZnZjMHEzQnZBRVM2Tm9LbUljRy9JdHNTZUFyR3Zm?= =?utf-8?B?L09YMWpja1pBb0xYbzJic0E0U1lWVVpPSkV5eTR0enZOd3dpM055RVBEa2hV?= =?utf-8?B?eHdDTElydFlzTFJqVWh0WHdIUEw1U2puU1d5SFYxcnA0b3NiT3A2YWZudlJp?= =?utf-8?B?SzdjTTd1aUlJOVgyeTdFWjUxZVFPMGxMdFlYYUZxQ2RqcXR1amtoOC9UMHFu?= =?utf-8?B?aWZLRy9JSUtnWnNMT2NGYUl3Y25lVXJmdnZtMllvVHF5ejRVMlBDZGxDbEM3?= =?utf-8?B?R1BwUHdxSHpNTCtqQVhIZ1VQOWdEYk5CendTbnpXcE5hK1F6Wnk5OGlzcUg3?= =?utf-8?B?TCtlRDlpYWUrN1NKUmZIZHoxdG12d1I0UUdXaDJYZFhLcjU1dkRVU0gzaXV3?= =?utf-8?B?cmZpTTRaVlB5Q28vU3pXVTVXTXROSyswZXFDQ2RXcS9pODJVZGdQRXlzSEFI?= =?utf-8?B?dkZjUjVsbHJGNitnUDBhVjlrQmtnL0d3N1NPUG55cWc3eDR0dDM5YkVZS1Jz?= =?utf-8?B?dGNoVTRxVGhKUXRGbytiOGNKbVliZENvZUxyUlZKLzMwMXYzNXQra3FVSm5r?= =?utf-8?B?SnZVaFJnb1ExcEU0UDZiS29aUmlkb2JGVlhtTzUvdjRuZEh2Vmd3ZHVxbkVv?= =?utf-8?B?bzFKWnJkME1xM0ZpbUhYNFpHd2JYVFRwN2RmczZNK0ZOSnNhZGFHUkZMMENy?= =?utf-8?Q?rh2YLT1jU4sm0Q1d54icIec5TccPTK/Z?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2024 22:08:59.4388 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 52b65e50-943e-4b44-3ac9-08dd15796b88 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=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF000001CE.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8724 Adding Rafael and Len. and again keeping the full patch. On 2024-12-05 00:42, Penny Zheng wrote: > As Xen is uncapable of parsing the ACPI dynamic table, this commit s/uncapable/incapable/ > introduces a new sub-hypercall XEN_PM_CPPC to deliver CPPC perf > caps data. > > Signed-off-by: Penny Zheng > --- > drivers/acpi/cppc_acpi.c | 1 + > drivers/xen/xen-acpi-processor.c | 89 +++++++++++++++++++++++++++++++- > include/acpi/processor.h | 1 + > include/xen/interface/platform.h | 11 ++++ > 4 files changed, 101 insertions(+), 1 deletion(-) > > diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c > index 3a436591da07..3570a52a5dbd 100644 > --- a/drivers/acpi/cppc_acpi.c > +++ b/drivers/acpi/cppc_acpi.c > @@ -860,6 +860,7 @@ static int acpi_cppc_processor_parse(struct acpi_processor *pr, struct cpc_desc > cpc_ptr->cpc_regs[i].cpc_entry.int_value = 0; > } > > + pr->flags.has_cpc = 1; > pr_debug("Parsed _CPC entry for CPU: %d\n", pr->acpi_id); > kfree(output.pointer); > return 0; > diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c > index e9f38f171240..8a39e46c1ebc 100644 > --- a/drivers/xen/xen-acpi-processor.c > +++ b/drivers/xen/xen-acpi-processor.c > @@ -25,6 +25,7 @@ > #include > #include > #include > +#include > > static int no_hypercall; > MODULE_PARM_DESC(off, "Inhibit the hypercall."); > @@ -45,8 +46,12 @@ static unsigned long *acpi_ids_done; > static unsigned long *acpi_id_present; > /* And if there is an _CST definition (or a PBLK) for the ACPI IDs */ > static unsigned long *acpi_id_cst_present; > +/* And if there is an _CPC entry for the ACPI IDs */ > +static unsigned long *acpi_id_cpc_present; > /* Which ACPI P-State dependencies for a enumerated processor */ > static struct acpi_psd_package *acpi_psd; > +/* ACPI CPPC structures for a enumerated processor */ > +static struct cppc_perf_caps *acpi_cppc_data; > > static bool pr_initialized; > > @@ -208,6 +213,44 @@ static int xen_copy_pct_data(struct acpi_pct_register *pct, > dst_pct->address = pct->address; > return 0; > } > +static int push_cppc_to_hypervisor(struct acpi_processor *_pr) > +{ > + int ret = 0; > + struct xen_platform_op op = { > + .cmd = XENPF_set_processor_pminfo, > + .interface_version = XENPF_INTERFACE_VERSION, > + .u.set_pminfo.id = _pr->acpi_id, > + .u.set_pminfo.type = XEN_PM_CPPC, > + }; > + struct cppc_perf_caps *cppc_perf = acpi_cppc_data + _pr->acpi_id; > + > + op.u.set_pminfo.cppc_data.highest_perf = cppc_perf->highest_perf; > + op.u.set_pminfo.cppc_data.lowest_perf = cppc_perf->lowest_perf; > + op.u.set_pminfo.cppc_data.nominal_perf = cppc_perf->nominal_perf; > + op.u.set_pminfo.cppc_data.lowest_nonlinear_perf = cppc_perf->lowest_nonlinear_perf; > + op.u.set_pminfo.cppc_data.lowest_freq = cppc_perf->lowest_freq; > + op.u.set_pminfo.cppc_data.nominal_freq = cppc_perf->nominal_freq; > + > + if (!no_hypercall) > + ret = HYPERVISOR_platform_op(&op); > + > + if (!ret) { > + pr_debug("ACPI CPU%u - CPPC uploaded.\n", _pr->acpi_id); > + pr_debug(" highest_perf: %d\n", cppc_perf->highest_perf); > + pr_debug(" lowest_perf: %d\n", cppc_perf->lowest_perf); > + pr_debug(" lowest_nonlinear_perf: %d\n", cppc_perf->lowest_nonlinear_perf); > + pr_debug(" nominal_perf: %d\n", cppc_perf->nominal_perf); > + pr_debug(" lowest_freq: %d Mhz\n", cppc_perf->lowest_freq); > + pr_debug(" nominal_freq: %d Mhz\n", cppc_perf->nominal_freq); > + } else if ((ret != -EINVAL) && (ret != -ENOSYS)) > + /* EINVAL means the ACPI ID is incorrect - meaning the ACPI > + * table is referencing a non-existing CPU - which can happen > + * with broken ACPI tables. */ > + pr_warn("(_CPC): Hypervisor error (%d) for ACPI CPU%u\n", > + ret, _pr->acpi_id); > + > + return ret; > +} > static int push_pxx_to_hypervisor(struct acpi_processor *_pr) > { > int ret = 0; > @@ -284,6 +327,9 @@ static int upload_pm_data(struct acpi_processor *_pr) > if (_pr->flags.power) > err = push_cxx_to_hypervisor(_pr); > > + if (_pr->flags.has_cpc) > + err |= push_cppc_to_hypervisor(_pr); > + Older hypervisors without the xen changes will return an error since they don't implement XEN_PM_CPPC. We might want to ignore the return when it's EINVAL, the default for the XEN_PM_* switch, but that may ignore more than intended. The two calls to upload_pm_data() ignore the return value, so maybe it doesn't matter. (This is the end of my comments.) Thanks, Jason > if (_pr->performance && _pr->performance->states) > err |= push_pxx_to_hypervisor(_pr); > > @@ -488,6 +534,7 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) > union acpi_object object = { 0 }; > struct acpi_buffer buffer = { sizeof(union acpi_object), &object }; > struct acpi_buffer cst_buf = { ACPI_ALLOCATE_BUFFER, NULL }; > + struct acpi_buffer cpc_buf = { ACPI_ALLOCATE_BUFFER, NULL }; > acpi_io_address pblk = 0; > > status = acpi_get_type(handle, &acpi_type); > @@ -567,11 +614,20 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context, void **rv) > /* .. and it has a C-state */ > __set_bit(acpi_id, acpi_id_cst_present); > > + status = acpi_evaluate_object(handle, "_CPC", NULL, &cpc_buf); > + if (ACPI_FAILURE(status)) { > + return AE_OK; > + } > + kfree(cpc_buf.pointer); > + > + /* .. and it has a _CPC entry */ > + __set_bit(acpi_id, acpi_id_cpc_present); > + > return AE_OK; > } > static int check_acpi_ids(struct acpi_processor *pr_backup) > { > - if (acpi_id_present && acpi_id_cst_present) > + if (acpi_id_present && acpi_id_cst_present && acpi_id_cpc_present) > /* OK, done this once .. skip to uploading */ > goto upload; > > @@ -588,11 +644,19 @@ static int check_acpi_ids(struct acpi_processor *pr_backup) > return -ENOMEM; > } > > + acpi_id_cpc_present = bitmap_zalloc(nr_acpi_bits, GFP_KERNEL); > + if (!acpi_id_cpc_present) { > + bitmap_free(acpi_id_present); > + bitmap_free(acpi_id_cst_present); > + return -ENOMEM; > + } > + > acpi_psd = kcalloc(nr_acpi_bits, sizeof(struct acpi_psd_package), > GFP_KERNEL); > if (!acpi_psd) { > bitmap_free(acpi_id_present); > bitmap_free(acpi_id_cst_present); > + bitmap_free(acpi_id_cpc_present); > return -ENOMEM; > } > > @@ -608,6 +672,12 @@ static int check_acpi_ids(struct acpi_processor *pr_backup) > pr_backup->acpi_id = i; > /* Mask out C-states if there are no _CST or PBLK */ > pr_backup->flags.power = test_bit(i, acpi_id_cst_present); > + /* Mask out relevant flag if there are no _CPC */ > + pr_backup->flags.has_cpc = test_bit(i, acpi_id_cpc_present); > + if (pr_backup->flags.has_cpc) { > + if (xen_processor_get_perf_caps(pr_backup, acpi_cppc_data + i)) > + return -EINVAL; > + } > /* num_entries is non-zero if we evaluated _PSD */ > if (acpi_psd[i].num_entries) { > memcpy(&pr_backup->performance->domain_info, > @@ -726,6 +796,15 @@ static int __init xen_acpi_processor_init(void) > bitmap_free(acpi_ids_done); > return -ENOMEM; > } > + > + acpi_cppc_data = kcalloc(nr_acpi_bits, sizeof(struct cppc_perf_caps), > + GFP_KERNEL); > + if (!acpi_cppc_data) { > + pr_debug("Memory allocation error for acpi_cppc_data\n"); > + rc = -ENOMEM; > + goto err1_out; > + } > + > for_each_possible_cpu(i) { > if (!zalloc_cpumask_var_node( > &per_cpu_ptr(acpi_perf_data, i)->shared_cpu_map, > @@ -751,6 +830,11 @@ static int __init xen_acpi_processor_init(void) > rc = acpi_processor_get_performance_info(pr); > if (rc) > goto err_out; > + > + pr->flags.pcc_unsupported = true; > + rc = xen_processor_get_perf_caps(pr, acpi_cppc_data + i); > + if (rc) > + goto err_out; > } > > rc = xen_upload_processor_pm_data(); > @@ -766,6 +850,8 @@ static int __init xen_acpi_processor_init(void) > > err_out: > /* Freeing a NULL pointer is OK: alloc_percpu zeroes. */ > + kfree(acpi_cppc_data); > +err1_out: > free_acpi_perf_data(); > bitmap_free(acpi_ids_done); > return rc; > @@ -779,6 +865,7 @@ static void __exit xen_acpi_processor_exit(void) > bitmap_free(acpi_id_present); > bitmap_free(acpi_id_cst_present); > kfree(acpi_psd); > + kfree(acpi_cppc_data); > for_each_possible_cpu(i) > acpi_processor_unregister_performance(i); > > diff --git a/include/acpi/processor.h b/include/acpi/processor.h > index 18499cc11366..66492f5d68a8 100644 > --- a/include/acpi/processor.h > +++ b/include/acpi/processor.h > @@ -214,6 +214,7 @@ struct acpi_processor_flags { > u8 bm_control:1; > u8 bm_check:1; > u8 has_cst:1; > + u8 has_cpc:1; > u8 pcc_unsupported:1; > u8 has_lpi:1; > u8 power_setup_done:1; > diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h > index 79a443c65ea9..e11bb9443dc0 100644 > --- a/include/xen/interface/platform.h > +++ b/include/xen/interface/platform.h > @@ -319,6 +319,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_getidletime_t); > #define XEN_PM_PX 1 > #define XEN_PM_TX 2 > #define XEN_PM_PDC 3 > +#define XEN_PM_CPPC 4 > /* Px sub info type */ > #define XEN_PX_PCT 1 > #define XEN_PX_PSS 2 > @@ -384,6 +385,15 @@ struct xen_processor_px { > }; > DEFINE_GUEST_HANDLE_STRUCT(xen_processor_px); > > +struct xen_processor_cppc { > + uint32_t highest_perf; > + uint32_t nominal_perf; > + uint32_t lowest_perf; > + uint32_t lowest_nonlinear_perf; > + uint32_t lowest_freq; > + uint32_t nominal_freq; > +}; > + > struct xen_psd_package { > uint64_t num_entries; > uint64_t revision; > @@ -412,6 +422,7 @@ struct xenpf_set_processor_pminfo { > struct xen_processor_power power;/* Cx: _CST/_CSD */ > struct xen_processor_performance perf; /* Px: _PPC/_PCT/_PSS/_PSD */ > GUEST_HANDLE(uint32_t) pdc; > + struct xen_processor_cppc cppc_data; /* _CPC */ > }; > }; > DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo); From xen-devel-bounces@lists.xenproject.org Fri Dec 06 00:37:20 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 00:37:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849367.1263965 (Exim 4.92) (envelope-from ) id 1tJMLE-0007y5-4v; Fri, 06 Dec 2024 00:37:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849367.1263965; Fri, 06 Dec 2024 00:37:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJMLE-0007xy-1L; Fri, 06 Dec 2024 00:37:08 +0000 Received: by outflank-mailman (input) for mailman id 849367; Fri, 06 Dec 2024 00:04: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 1tJLpp-0004eF-Jt for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 00:04:42 +0000 Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id afaaf2ec-b365-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 01:04:39 +0100 (CET) Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236]) by drago1i.eurecom.fr with ESMTP; 06 Dec 2024 01:04:38 +0100 Received: from localhost.localdomain (88-183-119-157.subs.proxad.net [88.183.119.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtps.eurecom.fr (Postfix) with ESMTPSA id 7DC922FE2; Fri, 6 Dec 2024 01:04:38 +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: afaaf2ec-b365-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default; t=1733443479; x=1764979479; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=Tbs/cru7vG9b5aNG/B4oTjXsxhug6sFN01k8JSOtV1s=; b=nT/ppDDi+uds5hW8QgMDyCXnSW7FAeKKjVp4nbmuAm7IpW8E+m6IvwX7 cTHANhxFXHRv6BHm3ditAtfXGTA7ShZkhaX2mwFkXgS8cOz/0KH1qmSP8 wefGLv9t0ZSRATFjBfgieWgPqZhp6Z2nIQTKpoPOVrwA8J2XcTD4BinQQ g=; X-CSE-ConnectionGUID: +O3iwYlSSMStF0/1kk67AA== X-CSE-MsgGUID: FTBKlSlpRWCs1Sc9S8JWeA== X-IronPort-AV: E=Sophos;i="6.12,211,1728943200"; d="scan'208";a="28052174" From: Ariel Otilibili To: xen-devel@lists.xenproject.org Cc: Anthony PERARD , Jan Beulich , Ariel Otilibili Subject: [PATCH 0/1] tools/libacpi: clear out compilation warnings Date: Fri, 6 Dec 2024 01:00:43 +0100 Message-ID: <20241206000422.331015-1-Ariel.Otilibili-Anieli@eurecom.fr> X-Mailer: git-send-email 2.47.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hello, This is my first patch to the list; your feedback is much appreciated. I am new to Xen; my aim is to improve my knowledge of virtualization. While compiling from scratch, I came across these warnings. If this patch makes sense, I will have a look at other ASL warnings I spotted. Thank you, Ariel Otilibili (1): tools/libacpi: clear out compilation warnings tools/libacpi/mk_dsdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.47.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 00:37:20 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 00:37:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849369.1263969 (Exim 4.92) (envelope-from ) id 1tJMLE-00081B-Ct; Fri, 06 Dec 2024 00:37:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849369.1263969; Fri, 06 Dec 2024 00:37:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJMLE-0007zu-8R; Fri, 06 Dec 2024 00:37:08 +0000 Received: by outflank-mailman (input) for mailman id 849369; Fri, 06 Dec 2024 00:04: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 1tJLpy-0004eF-Gw for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 00:04:50 +0000 Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b53cd916-b365-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 01:04:48 +0100 (CET) Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236]) by drago1i.eurecom.fr with ESMTP; 06 Dec 2024 01:04:48 +0100 Received: from localhost.localdomain (88-183-119-157.subs.proxad.net [88.183.119.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtps.eurecom.fr (Postfix) with ESMTPSA id 3A9F12FE3; Fri, 6 Dec 2024 01:04:48 +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: b53cd916-b365-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default; t=1733443488; x=1764979488; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=c15xd3hcrXYU5q0mBUtduN3+7E35PftljiN3bzGtRYk=; b=YnGeu3hyEuYmhirPR6kgjwgn+PZan+sKSMR7ioq51uO+rd5UEKGm5LXZ vgqFDIgdemoPvpK4AiEEAWGoUUFfpyNFbogSeCRaAbZ9+dTmt0+56wxGK bDFqUE08QmxSgoOALeVbX95f7BqfVE7ET+CojE+N/QizddgzZcAayaX/P E=; X-CSE-ConnectionGUID: HOEFrRNQRk20H4OnKqGBLQ== X-CSE-MsgGUID: vvAAnEQFTQquq4fIefyWOA== X-IronPort-AV: E=Sophos;i="6.12,211,1728943200"; d="scan'208";a="28052176" From: Ariel Otilibili To: xen-devel@lists.xenproject.org Cc: Anthony PERARD , Jan Beulich , Ariel Otilibili , Ariel Otilibili Subject: [PATCH 1/1] tools/libacpi: clear out compilation warnings Date: Fri, 6 Dec 2024 01:00:44 +0100 Message-ID: <20241206000422.331015-2-Ariel.Otilibili-Anieli@eurecom.fr> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20241206000422.331015-1-Ariel.Otilibili-Anieli@eurecom.fr> References: <20241206000422.331015-1-Ariel.Otilibili-Anieli@eurecom.fr> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Ariel Otilibili * While compiling ASLs, iasl puts out deprecation warnings ``` tools/libs/light/mk_dsdt --debug=y --maxcpu any --dm-version none >> tools/libs/light/dsdt_pvh.asl /usr/bin/iasl -vs -p tools/libs/light/dsdt_pvh.tmp -tc tools/libs/light/dsdt_pvh.asl tools/libs/light/dsdt_pvh.asl 40: Processor ( PR00, 0, 0x0000b010, 0x06 ) { Warning 3168 - ^ Legacy Processor() keyword detected. Use Device() keyword instead. tools/libs/light/dsdt_pvh.asl 64: Processor ( PR01, 1, 0x0000b010, 0x06 ) { Warning 3168 - ^ Legacy Processor() keyword detected. Use Device() keyword instead. ``` * since 6.0, the ACPI specs have deprecated the keyword Processor * the deprecation is mentioned in Rev. History, Issue 1232 * instead, ACPI advices to use the keyword Device * after the fix, the warnings are cleared out. ``` tools/libs/light/mk_dsdt --debug=y --maxcpu any --dm-version none >> tools/libs/light/dsdt_pvh.asl /usr/bin/iasl -vs -p tools/libs/light/dsdt_pvh.tmp -tc tools/libs/light/dsdt_pvh.asl ASL Input: tools/libs/light/dsdt_pvh.asl - 167025 bytes 3763 keywords 0 source lines AML Output: tools/libs/light/dsdt_pvh.aml - 27035 bytes 2599 opcodes 1164 named objects Hex Dump: tools/libs/light/dsdt_pvh.hex - 253913 bytes Compilation successful. 0 Errors, 0 Warnings, 0 Remarks, 1915 Optimizations ``` Link: https://uefi.org/specs/ACPI/6.5_A/Frontmatter/Revision_History.html#revision-history Link: https://uefi.org/specs/ACPI/6.5_A/08_Processor_Configuration_and_Control.html#declaring-processors Link: https://uefi.org/specs/ACPI/6.5_A/19_ASL_Reference.html#device-declare-device-package Signed-off-by: Ariel Otilibili Signed-off-by: Ariel Otilibili --- tools/libacpi/mk_dsdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c index 34f6753f61..5729b4238c 100644 --- a/tools/libacpi/mk_dsdt.c +++ b/tools/libacpi/mk_dsdt.c @@ -186,7 +186,7 @@ int main(int argc, char **argv) /* Define processor objects and control methods. */ for ( cpu = 0; cpu < max_cpus; cpu++) { - push_block("Processor", "PR%02X, %d, 0x0000b010, 0x06", cpu, cpu); + push_block("Device", "PR%02X", cpu); stmt("Name", "_HID, \"ACPI0007\""); -- 2.47.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 00:43:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 00:43:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849391.1263984 (Exim 4.92) (envelope-from ) id 1tJMQw-0001o3-0m; Fri, 06 Dec 2024 00:43:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849391.1263984; Fri, 06 Dec 2024 00: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 1tJMQv-0001nw-U1; Fri, 06 Dec 2024 00:43:01 +0000 Received: by outflank-mailman (input) for mailman id 849391; Fri, 06 Dec 2024 00:43: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 1tJMQv-0001nq-1H for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 00:43:01 +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 0ab69cb9-b36b-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 01:42:59 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-434a8640763so11082825e9.1 for ; Thu, 05 Dec 2024 16:42:59 -0800 (PST) Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-386219095desm3235088f8f.64.2024.12.05.16.42.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Dec 2024 16:42: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: 0ab69cb9-b36b-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1733445779; x=1734050579; 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=9ANN8Pw2RISl9iiMi3wsdHQnT40gHOJrWkb6RYxQgKE=; b=WpSWNSCO1aeollDl24PBE2yPBx7uR0XMtEd9i8Y5NDwlp7Vi47YjZ+OJgjvHLoxggq fl1oOIgdUiISaB0St1Meas64pjhzxKoLs7cWJaUmrE4zneX4xmlR6j8lR6C4Ploxx/Sk As2IAcFrtAl3j7KQ5/8iYYlTz/iIwC54K65kk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733445779; x=1734050579; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9ANN8Pw2RISl9iiMi3wsdHQnT40gHOJrWkb6RYxQgKE=; b=CyYk0xkKNOeWUV2A+trJWVI1ZB65Nz6mShqJPwZzCGG5f8w25Hd3FziFODB+SHS3RH LmNWi9/YuZk3RwBVoECVpEjFaCG6iV4HrBqO6TRx1b0LSH7MiGs5r01e3ZAEZZ/DJ8CL Mw9asXUlF+s5hkWGIMVlU9BI8jJYOe5dtduMHb+IMk4AJp6e8nEcnIInAeLGRuQurXvH TnMwKC3ilWroZR1d1R7ELlXZFRJEnx7FKGsaAJHQIJOp9GWLbLuAwaRSFUfIT09FdZcP aKTNyah6FYU/F4CMM2KRE2ao0Rqg7+g6hYSs0CuAKW88y35GiNfsflUlgEjvgG+hlj3I IS+A== X-Forwarded-Encrypted: i=1; AJvYcCUw0hgsQna4b0EQlcC7g8DFW3BXwZkaIdFnxyjfQj6yq3s1CJAqiscDQ/xdcQeyt7T05GawbD9+Zo8=@lists.xenproject.org X-Gm-Message-State: AOJu0YyJBnIBxGjaS9O8NzHI5wSH49TBO2roRRalSGjlc9asI0USZJ10 9ubtb9savldtbu1xMQ0117QPE/OzpoM3NdYeWoCDqGCHh43DanLu+oAxOaZxOL4= X-Gm-Gg: ASbGnctPoVc7JSVU9/yql6cBH/xdoROf1KLu8h/7cDZHHwP0FG5Jel7oc7NCV+CDcI1 VgF3+svMpNS3n7bXarHvHxrNCvdsfihAAuoV+GSUKfMHrNeJTK/Bz9gVfHICYcAk2uEqptgp+MO rxBqgKh8rlkYkGd8q44chEaWCoBWxpjJMpBEiwYIxT2hqCnpmY9vyMx8qZidqqSIaAY9ca3tMJk PFZ6mJULMEWeCnXjzhzBzsC5DPlNB/fo9l7n96o4w8paBW4t9Faa4NKUIrpJykgtRp2UqlbIUN9 UiINXkDFZGb9rA== X-Google-Smtp-Source: AGHT+IG1RCXWmNI8XB0drt9LgJjsGVaAxFUw2k4AzkrVNKQ9lkQBsgRJEteWdOu4G0ojL7Z24BUVSA== X-Received: by 2002:a05:600c:190a:b0:434:9936:c823 with SMTP id 5b1f17b1804b1-434ddeba3aamr9921335e9.18.1733445779004; Thu, 05 Dec 2024 16:42:59 -0800 (PST) Message-ID: Date: Fri, 6 Dec 2024 00:42:57 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/1] tools/libacpi: clear out compilation warnings To: Ariel Otilibili , xen-devel@lists.xenproject.org Cc: Anthony PERARD , Jan Beulich , Ariel Otilibili References: <20241206000422.331015-1-Ariel.Otilibili-Anieli@eurecom.fr> <20241206000422.331015-2-Ariel.Otilibili-Anieli@eurecom.fr> Content-Language: en-GB From: Andrew Cooper Autocrypt: addr=andrew.cooper3@citrix.com; keydata= xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA== In-Reply-To: <20241206000422.331015-2-Ariel.Otilibili-Anieli@eurecom.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06/12/2024 12:00 am, Ariel Otilibili wrote: > From: Ariel Otilibili > > * While compiling ASLs, iasl puts out deprecation warnings > > ``` > tools/libs/light/mk_dsdt --debug=y --maxcpu any --dm-version none >> tools/libs/light/dsdt_pvh.asl > /usr/bin/iasl -vs -p tools/libs/light/dsdt_pvh.tmp -tc tools/libs/light/dsdt_pvh.asl > > tools/libs/light/dsdt_pvh.asl 40: Processor ( PR00, 0, 0x0000b010, 0x06 ) { > Warning 3168 - ^ Legacy Processor() keyword detected. Use Device() keyword instead. > > tools/libs/light/dsdt_pvh.asl 64: Processor ( PR01, 1, 0x0000b010, 0x06 ) { > Warning 3168 - ^ Legacy Processor() keyword detected. Use Device() keyword instead. > ``` > > * since 6.0, the ACPI specs have deprecated the keyword Processor > * the deprecation is mentioned in Rev. History, Issue 1232 > * instead, ACPI advices to use the keyword Device > * after the fix, the warnings are cleared out. > > ``` > tools/libs/light/mk_dsdt --debug=y --maxcpu any --dm-version none >> tools/libs/light/dsdt_pvh.asl > /usr/bin/iasl -vs -p tools/libs/light/dsdt_pvh.tmp -tc tools/libs/light/dsdt_pvh.asl > > ASL Input: tools/libs/light/dsdt_pvh.asl - 167025 bytes 3763 keywords 0 source lines > AML Output: tools/libs/light/dsdt_pvh.aml - 27035 bytes 2599 opcodes 1164 named objects > Hex Dump: tools/libs/light/dsdt_pvh.hex - 253913 bytes > > Compilation successful. 0 Errors, 0 Warnings, 0 Remarks, 1915 Optimizations > ``` > > Link: https://uefi.org/specs/ACPI/6.5_A/Frontmatter/Revision_History.html#revision-history > Link: https://uefi.org/specs/ACPI/6.5_A/08_Processor_Configuration_and_Control.html#declaring-processors > Link: https://uefi.org/specs/ACPI/6.5_A/19_ASL_Reference.html#device-declare-device-package > Signed-off-by: Ariel Otilibili > Signed-off-by: Ariel Otilibili > --- > tools/libacpi/mk_dsdt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c > index 34f6753f61..5729b4238c 100644 > --- a/tools/libacpi/mk_dsdt.c > +++ b/tools/libacpi/mk_dsdt.c > @@ -186,7 +186,7 @@ int main(int argc, char **argv) > /* Define processor objects and control methods. */ > for ( cpu = 0; cpu < max_cpus; cpu++) > { > - push_block("Processor", "PR%02X, %d, 0x0000b010, 0x06", cpu, cpu); > + push_block("Device", "PR%02X", cpu); > > stmt("Name", "_HID, \"ACPI0007\""); > Hello, Thankyou for your patch. Unfortunately, it's not quite this simple.  While there is a warning out of IASL, older OSes coded to prior versions of the ACPI spec still depend on "Processor". It may be time to start thinking about removing support for the likes of WinXP, but that needs more consideration than simply fixing a warning. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:41:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:41:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849407.1264002 (Exim 4.92) (envelope-from ) id 1tJQ9v-0004OQ-Sm; Fri, 06 Dec 2024 04:41:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849407.1264002; Fri, 06 Dec 2024 04:41: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 1tJQ9v-0004Ng-Kb; Fri, 06 Dec 2024 04:41:43 +0000 Received: by outflank-mailman (input) for mailman id 849407; Fri, 06 Dec 2024 04:41: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 1tJQ9u-0004Ka-50 for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:42 +0000 Received: from nyc.source.kernel.org (nyc.source.kernel.org [2604:1380:45d1:ec00::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 619fc92f-b38c-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:41:39 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 6750BA43EEF; Fri, 6 Dec 2024 04:39:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id D8D96C4CED1; Fri, 6 Dec 2024 04:41:37 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id D21F2E77173; Fri, 6 Dec 2024 04:41:37 +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: 619fc92f-b38c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460097; bh=2WgWqZsNDflVD6JmnKTRAOPbRC5jJUlqppnLV6LXXy4=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=eFVU2m0MN1WdzL+1zbIbqDbDYwa9z1Mr9M1oPjJvCwWXkaXsAfzWiZQFuhrPbIcr2 nAvRMg5F3PJTqc6q153JNQkfmBacrI1Q4a9/ZMexcU7YmXwid8fTTZWdvPs8ZDkblq IcvJp8HzxF2lUT0tmHE6uokd+ncoq83kQEXK0lSsRF3DxAi0tNsqQXxx7Uw42xixnS gtiiQLpoNi6l7H/gPWv7j8rRyfZpzB+Hxo0gKKpxCQWFYnfb1TD6rfgytu5hGvkLx4 aA9DgEvxgSclbOxgr+uGf92wH0hC0TOvsyf/M8gC4XW1yUxs3R9m0dDTwgo0ZEPgtw IHtSBGOlOfKsg== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:39 -0800 Subject: [PATCH v2 09/35] x86/domain: print emulation_flags MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-9-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=1263; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=732gIMLcaCgGTFTHv9vAjNIT6ES/ZZttjeIUCT3F6PI=; b=Y7HK/z6jmiAxr9LffbLx3VzuTnpvsJKN4W5zpRGYQrcHh7C1xfTaL3qBH1d/hc6odnj49z0ll kg3ON+vpt6nA9uN2Ik2YEXEG2SpMz1AzDdlcvsmncdiJ05m4eO9kdq9 X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Print d->arch.emulation_flags on the console for better traceability while debugging in-hypervisor hardware emulators. Signed-off-by: Denis Mukhin --- xen/arch/x86/domain.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 78a13e6812c9120901d0a70fb3bc1bd6a8b6917d..c88d422a64544531c1e1058fa484364bb4277d1e 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -818,11 +818,15 @@ int arch_domain_create(struct domain *d, if ( !emulation_flags_ok(d, emflags) ) { - printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation " + printk(XENLOG_G_ERR "d%d: Xen does not allow %s %sdomain creation " "with the current selection of emulators: %#x\n", - d->domain_id, is_hvm_domain(d) ? "HVM" : "PV", emflags); + d->domain_id, + is_hvm_domain(d) ? "HVM" : "PV", + is_hardware_domain(d) ? "(hardware) " : "", + emflags); return -EOPNOTSUPP; } + printk(XENLOG_G_INFO "d%d: emulation_flags %#x\n", d->domain_id, emflags); d->arch.emulation_flags = emflags; #ifdef CONFIG_PV32 -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:41:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:41:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849409.1264015 (Exim 4.92) (envelope-from ) id 1tJQ9w-0004cW-HV; Fri, 06 Dec 2024 04:41:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849409.1264015; Fri, 06 Dec 2024 04: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 1tJQ9w-0004a7-9D; Fri, 06 Dec 2024 04:41:44 +0000 Received: by outflank-mailman (input) for mailman id 849409; Fri, 06 Dec 2024 04:41: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 1tJQ9u-0004Kb-J4 for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:42 +0000 Received: from nyc.source.kernel.org (nyc.source.kernel.org [2604:1380:45d1:ec00::3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 616f521f-b38c-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 05:41:39 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id E2B9EA43E3F; Fri, 6 Dec 2024 04:39:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 7BA55C4CEDE; Fri, 6 Dec 2024 04:41:37 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C2F9E77175; Fri, 6 Dec 2024 04:41:37 +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: 616f521f-b38c-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460097; bh=jP7Qo7rqdlhdDtQjECWtHV/Nhjgbh2HMa37UuR2ELXI=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=VzrVaW2cbMrG9x7Jrj87s43TAWtqcTNd2+m1z1Gk4WL/MKJSE10/C/PJtmrx8QnIW +yi2g+LLAwG4bFGgjXD7GdxPYQ5U3b+veIXKy1IR1p0WAi2YZIkpSJ2FawRLk0hfzz G408ojxg/NkVFunFlw8x++pozBR4dUWcimMaPCQbpdPpchIBOG+AdUSrzUTFLZIVwP ov2phTvjDnXcbeOgHXQZRaDgsXb1RftI6P9OwJiEMjGbQlicUsNet27BL/bhmbP0jo hW5Lbvqd70+/vqHuWhMOW92goNFvuO+txaM+S7Q3bDox9ukGih6lwNBJcdOi8foRGd pEfljzO0SwpgQ== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:32 -0800 Subject: [PATCH v2 02/35] xen/irq: introduce NO_IRQ MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-2-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=616; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=dP3fe+TbEoRyzDIKnwZpy2zc7XNhJoHUDN0gqSrT6Sc=; b=GKp4UmHhqYd4CVUECgv6TOG2tNjpaTsfFbUI/8w7Tg/1Iubs7IfYMbYiQH2BZuSCKukEeBIRd dw9amfh326NCUqU9lJxyOuAS13v+83XcJtUb9tN5Gt5oIKGchFjF22K X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Introduce definition for IRQ resource checks. Signed-off-by: Denis Mukhin --- xen/include/xen/irq.h | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/include/xen/irq.h b/xen/include/xen/irq.h index 95034c0d6bb5f0aa7d5bb572aca59872508a438a..aee878293ecc0de6a938bcfea1140d36b4de745a 100644 --- a/xen/include/xen/irq.h +++ b/xen/include/xen/irq.h @@ -53,6 +53,7 @@ struct irqaction { #define AUTO_ASSIGN_IRQ (-1) #define NEVER_ASSIGN_IRQ (-2) #define FREE_TO_ASSIGN_IRQ (-3) +#define NO_IRQ (-4) struct irq_desc; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:41:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:41:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849414.1264068 (Exim 4.92) (envelope-from ) id 1tJQA0-0005wG-Bq; Fri, 06 Dec 2024 04:41:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849414.1264068; Fri, 06 Dec 2024 04:41: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 1tJQ9z-0005u6-Tt; Fri, 06 Dec 2024 04:41:47 +0000 Received: by outflank-mailman (input) for mailman id 849414; Fri, 06 Dec 2024 04:41: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 1tJQ9w-0004Ka-Lc for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:44 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [2604:1380:4641:c500::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 62c9fd31-b38c-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:41:41 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 6BEB75C7306; Fri, 6 Dec 2024 04:40:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id CBE87C4CEEA; Fri, 6 Dec 2024 04:41:37 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id C0A58E77178; Fri, 6 Dec 2024 04:41:37 +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: 62c9fd31-b38c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460097; bh=uX6eDC7J8gnEJzkAK+vFayV4YOh384qGm0SB3/a+eoo=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=avrLbYKG1EF7oiTpLzSi+p6WiQ4UauuUO4vJI1wxBJfqP0HTep/fmdpbossvNA2co X20WpEpvBT3BOf005Ojs+fbuF7F0OjbqeNz+G3mag/JaxhthJYt2uDfK+TpLzUO7t+ Q99tKINVNihcqmQmoZ8ImR0pfr8Z/PVUbCas9rTHpEFTPPsCEv4EDUGpBKr0DTeD0N dMWZkTjIlI9pfmYIfsmOLE4CvrEvENBGrMZTrNw1brkmVFouX3W56rKC8mgFck5Pz5 R+NLN41O1RfOi56obCLFefiqr3kwGd0WSz9ifMw45arh6ghob7nChf5WANLv+Ln1f1 rmWq4AL3jL9ew== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:38 -0800 Subject: [PATCH v2 08/35] x86/domain: introduce domain_has_vuart() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-8-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=889; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=d8+eK1EX7G4dAD9MTJCuZscRKOX31WZGg59AsNpMxsU=; b=cG7SkKjK5QUHyRM3m5wrGnS1pgFt0n85Fs1Xe2pmZs5Vlb0KOvwBf5tETIrxKlEyd7jpRII9O toWVU7GmrsPCS+fsxc/qQNc08AGwg1KYEmN2hQEgOOrZFF13XuOGfCc X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Introduce domain_has_vuart() for x86 port to be used in the console driver. Signed-off-by: Denis Mukhin --- xen/arch/x86/include/asm/domain.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index b79d6badd71c4d96279555df62fad75fe817a2b6..c1d0d1f47324e8cc678a4c76c43f86820a89e7b3 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -506,6 +506,9 @@ struct arch_domain #define has_pirq(d) (!!((d)->arch.emulation_flags & X86_EMU_USE_PIRQ)) #define has_vpci(d) (!!((d)->arch.emulation_flags & X86_EMU_VPCI)) +/* NB: same symbol as in Arm port */ +#define domain_has_vuart(d) false + #define gdt_ldt_pt_idx(v) \ ((v)->vcpu_id >> (PAGETABLE_ORDER - GDT_LDT_VCPU_SHIFT)) #define pv_gdt_ptes(v) \ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:41:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:41:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849415.1264073 (Exim 4.92) (envelope-from ) id 1tJQA0-00062t-U6; Fri, 06 Dec 2024 04:41:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849415.1264073; Fri, 06 Dec 2024 04:41: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 1tJQA0-000608-I8; Fri, 06 Dec 2024 04:41:48 +0000 Received: by outflank-mailman (input) for mailman id 849415; Fri, 06 Dec 2024 04:41: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 1tJQ9w-0004Kb-Vd for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:44 +0000 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 61bf3ac9-b38c-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 05:41:39 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 6B989A43EF8; Fri, 6 Dec 2024 04:39:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 059B1C4CEEC; Fri, 6 Dec 2024 04:41:38 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0BA2E77171; Fri, 6 Dec 2024 04:41:37 +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: 61bf3ac9-b38c-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460098; bh=+PxKx+9Bd/NEReVQwLv8HwHoaFwOF8+i20hqmE7xSXQ=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=Nj6XLkuQmLp/uNXjB+dsck6DBJ29uP2b4H0jd7JyvqHnpdXwzzPGJwZz763k3n2K6 vy15uHNlEWnIvngW4gA7kpIkR/o0nMhomWd9N4qTGW9zrFGiSewvc5SS//R1Z/So7J zpfTk/+m2gKC5dpiJ2vke+LWmqXtmf7LhOQdETNRLCPUoKxuV7nopiInEqPzQhCLFI 9U37FnA+WaAj7sfDO8TBa1xojmEqEA22aW1xWcFQ5mllJPxI6dMQQ1+98PKocXtvHX R8UbVM511Ui+2dBoGD2FDFQPsvDDRG0DYmWqjmW89S0DxHpyNcLtE+kM/v0j1yZrGl 6TTsyQhh5v9Bw== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:41 -0800 Subject: [PATCH v2 11/35] xen/domain: enable max_init_domid for all architectures MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-11-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=4201; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=8SSnD1Rvlg1COWggZ+OR+NWe7LtZUd10G0Zzgq+sluI=; b=bpAwdXM1HckuHe2z460ut11GP/zeb2Seuz4iMoUD0qKiSQ2aJi9gKWeH+xAYirZL5R2XB7tFP S+AaQcyn37ZA9gVrx6KR2HNyCi7SiNrHbwLipUFQcKHQeVhT1n3aPXS X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Move max_init_domid to a public API and enable for all architectures. That is pre-requisite change for console focus switch logic cleanup. max_init_domid is updated in domain_create(). Signed-off-by: Denis Mukhin --- xen/arch/arm/include/asm/setup.h | 2 -- xen/arch/arm/setup.c | 2 -- xen/arch/ppc/include/asm/setup.h | 2 -- xen/arch/riscv/include/asm/setup.h | 2 -- xen/arch/x86/include/asm/setup.h | 2 -- xen/common/domain.c | 9 +++++++++ xen/include/xen/domain.h | 2 ++ 7 files changed, 11 insertions(+), 10 deletions(-) diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h index 64c227d171fc7b92e5b62d9fd42e5662871bd12b..d4e1670cd69cdd4475b2a5eb316d2c0601090ed7 100644 --- a/xen/arch/arm/include/asm/setup.h +++ b/xen/arch/arm/include/asm/setup.h @@ -19,8 +19,6 @@ struct map_range_data struct rangeset *irq_ranges; }; -extern domid_t max_init_domid; - void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len); size_t estimate_efi_size(unsigned int mem_nr_banks); diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 2e27af4560a504bf57daef572d4a768bd886145b..cb218fe3eb36f2cdda47cfa092fa99ee1ca4a14c 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -58,8 +58,6 @@ struct cpuinfo_arm __read_mostly system_cpuinfo; bool __read_mostly acpi_disabled; #endif -domid_t __read_mostly max_init_domid; - static __used void init_done(void) { int rc; diff --git a/xen/arch/ppc/include/asm/setup.h b/xen/arch/ppc/include/asm/setup.h index e4f64879b68ca5aac24bd9544255143e6ef693f3..956fa6985adb23375bd41d3e5d34d9d5f0712bd5 100644 --- a/xen/arch/ppc/include/asm/setup.h +++ b/xen/arch/ppc/include/asm/setup.h @@ -1,6 +1,4 @@ #ifndef __ASM_PPC_SETUP_H__ #define __ASM_PPC_SETUP_H__ -#define max_init_domid (0) - #endif /* __ASM_PPC_SETUP_H__ */ diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/include/asm/setup.h index 844a2f0ef1d762b3a9bc90b61a336a23f1693cc9..978cad71d3df484e80ba19acc0e37b9278e941f0 100644 --- a/xen/arch/riscv/include/asm/setup.h +++ b/xen/arch/riscv/include/asm/setup.h @@ -3,8 +3,6 @@ #ifndef ASM__RISCV__SETUP_H #define ASM__RISCV__SETUP_H -#define max_init_domid (0) - void setup_mm(void); #endif /* ASM__RISCV__SETUP_H */ diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h index 5c2391a8684b66efdf4b092409ed33935db6b40c..296348655b9d146c73acc305cc9edd5fd46f7d47 100644 --- a/xen/arch/x86/include/asm/setup.h +++ b/xen/arch/x86/include/asm/setup.h @@ -69,6 +69,4 @@ extern bool opt_dom0_verbose; extern bool opt_dom0_cpuid_faulting; extern bool opt_dom0_msr_relaxed; -#define max_init_domid (0) - #endif diff --git a/xen/common/domain.c b/xen/common/domain.c index 2f67aa06ed50e69c27cedc8d7f6eb0b469fe81cd..9e57dd4122a726e2fb42efe9c029e775202be0e6 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -65,6 +65,9 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock); static struct domain *domain_hash[DOMAIN_HASH_SIZE]; struct domain *domain_list; +/* Last known non-system domain ID. */ +domid_t __read_mostly max_init_domid; + /* * Insert a domain into the domlist/hash. This allows the domain to be looked * up by domid, and therefore to be the subject of hypercalls/etc. @@ -815,6 +818,12 @@ struct domain *domain_create(domid_t domid, memcpy(d->handle, config->handle, sizeof(d->handle)); + /* + * Housekeeping for physical console forwarding to the domain. + */ + if ( !is_system_domain(d) && max_init_domid < domid ) + max_init_domid = domid; + return d; fail: diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h index 601ef431cf621af44c867400499b73b845eb137a..6102826a929ff7aad58a4bc40974815071a97446 100644 --- a/xen/include/xen/domain.h +++ b/xen/include/xen/domain.h @@ -171,6 +171,8 @@ extern bool vmtrace_available; extern bool vpmu_is_available; +extern domid_t max_init_domid; + domid_t get_initial_domain_id(void); #endif /* __XEN_DOMAIN_H__ */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:41:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:41:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849413.1264050 (Exim 4.92) (envelope-from ) id 1tJQ9y-0005L0-IS; Fri, 06 Dec 2024 04:41:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849413.1264050; Fri, 06 Dec 2024 04:41: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 1tJQ9y-0005Gg-65; Fri, 06 Dec 2024 04:41:46 +0000 Received: by outflank-mailman (input) for mailman id 849413; Fri, 06 Dec 2024 04: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 1tJQ9v-0004Kb-Vj for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:43 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 617c78a4-b38c-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 05:41:39 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 530575C7303; Fri, 6 Dec 2024 04:40:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id ADC4EC4CEE4; Fri, 6 Dec 2024 04:41:37 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id A3375E77171; Fri, 6 Dec 2024 04:41:37 +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: 617c78a4-b38c-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460097; bh=BvkwglhN7fVuiz9QCGrNgLj6KeYwL4hLgRPhmZlEXLs=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=R0NAk2V8k78+YO2fyShNo4hL4Q1QuOCwlaxH70++zHg++M5jR9WmS6Pi218PwtJPl 1uhUrWRICPMVWKl2K8Mkq/9q9JewEjHT1yPgvVnUmiSpDJ8w1wez75Gu6MEWmTiG9+ QnwMPIzTmxlz5mWBy+xWIwQjijohFsGDT6Pj6XZqQbC6F/HvimDm5+u4Ftn7nalOtB RzWkCD9y6lTfSHZTodpumJK9JAwBPIrJ6yIZw96gsBGNTOQG71n1MJJzLW4oRw9gXx n9xM/MTAczUz0gbFiUXPhpuKIipcV5ZCfdScJ7fjJKx/eihIAZ6ON+mBuQjvf4wkjf sFWy5RETs+1Iw== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:36 -0800 Subject: [PATCH v2 06/35] riscv/domain: introduce domain_has_vuart() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-6-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin , Oleksii Kurochko X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=737; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=+kPk8EKdgpPKuThGSrouRJGm0Vji6pKcYMUo97PKO3Q=; b=6hYpirrUtuGFg5SJ0XrKEsxgzUe45RwgR0LajeGuvIJ0aB25n1VGtzPpVnNKCGGGKS7oUgfI4 8U4z97HHmmfBzikcouSM5h0MFyMmyrQbcm5azQxSjCr9Bq6EhZyi00j X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Introduce domain_has_vuart() for RISC-V port to be used in the console driver. Signed-off-by: Denis Mukhin Reviewed-by: Oleksii Kurochko --- xen/arch/riscv/include/asm/domain.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h index c3d965a559b6ce3661bf17166d0c51853ff295a2..efbc4f1ea2619a187fe30ede17d96de01e599220 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -10,6 +10,8 @@ struct hvm_domain uint64_t params[HVM_NR_PARAMS]; }; +#define domain_has_vuart(d) false + struct arch_vcpu_io { }; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:41:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:41:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849408.1264006 (Exim 4.92) (envelope-from ) id 1tJQ9w-0004U7-6C; Fri, 06 Dec 2024 04:41:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849408.1264006; Fri, 06 Dec 2024 04: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 1tJQ9v-0004RG-Ty; Fri, 06 Dec 2024 04:41:43 +0000 Received: by outflank-mailman (input) for mailman id 849408; Fri, 06 Dec 2024 04:41: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 1tJQ9u-0004Kb-CC for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:42 +0000 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 617b5f8d-b38c-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 05:41:39 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 2A085A438D2; Fri, 6 Dec 2024 04:39:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 9F72EC4CEE3; Fri, 6 Dec 2024 04:41:37 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 95DF9E77173; Fri, 6 Dec 2024 04:41:37 +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: 617b5f8d-b38c-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460097; bh=bTKPqZAc34jvickLJXvP5NAA91sRqludt+wCep7eH1g=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=X1Z+RCdC6743SeS1lGFzXjH+Rno1zVaTL+63bSmr73koOsdjSsSgmtnwSh1zP/6rK f2XLz16uPLyy74nfOecLe3+f1fDKfG2p46fluY9dD7+3ziwzfupD96STPvqq9tbf0c bUYwxgg9CwB7c7ToN34dqGeaD1yV2WoYYRWtgEszLCXU/QIH7WE7VI2tURwUHGXtdy DSwjHzRuY7yqMqpCabccf6z8iDZpia+Fd/35Y6MjHKfXqyIoxDn5C9HwEp955fH0QR WqXGsUCLhzduH2XwMN9m+6EcCwUjgQOJORy6RMqxFmv7AM7tAUSs39u/qwM6aCi451 0JkBPjww/Wf+A== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:35 -0800 Subject: [PATCH v2 05/35] arm/vuart: make domain_has_vuart() public MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-5-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=3833; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=SVfYvrMsNY/TLDndYHXbgUHVOFhA4YTrVOLvr92vE7k=; b=KMBAyLtbB0Ts4a079gWdldbMDGnLogOr8Cebv62MircIQWQpRoRbNbWS6+p88uFLYfP/pXyVi Gzrxs1rf9uNBhhLQq24G16NdpQXXlSEicpPnATBvCVuUGsFulswQ37a X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Move domain_has_vuart() to arch namespace as preparation code change for architecture-agnostic way of forwarding physical console to the guest OS w/ in-hypervisor UART emulator. Signed-off-by: Denis Mukhin --- xen/arch/arm/dom0less-build.c | 2 ++ xen/arch/arm/domain.c | 19 ++++++++++++------- xen/arch/arm/domctl.c | 4 +++- xen/arch/arm/include/asm/domain.h | 9 +++++++++ xen/arch/arm/vuart.c | 2 -- 5 files changed, 26 insertions(+), 10 deletions(-) diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index f328a044e9d3bb5c9d358456c2ead5d2f125fbb1..de64ee930fdfe9a1c2842761275641485f69f675 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -831,6 +831,8 @@ static int __init construct_domU(struct domain *d, rc = domain_vpl011_init(d, NULL); if ( rc < 0 ) return rc; + + d->arch.emulation_flags |= ARM_EMU_VUART; } rc = prepare_dtb_domU(d, &kinfo); diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 3ba959f866338d2e7f7dc0e301cd79c10fbc4549..02f9d59b38b4b7f6f73d97c421c9948c90e681d5 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -769,14 +769,19 @@ int arch_domain_create(struct domain *d, if ( !vgic_reserve_virq(d, GUEST_EVTCHN_PPI) ) BUG(); } + else + { + /* + * Virtual UART is only used by linux early printk and decompress code. + * Only use it for the hardware domain because the linux kernel may not + * support multi-platform. + */ + rc = domain_vuart_init(d); + if ( rc ) + goto fail; - /* - * Virtual UART is only used by linux early printk and decompress code. - * Only use it for the hardware domain because the linux kernel may not - * support multi-platform. - */ - if ( is_hardware_domain(d) && (rc = domain_vuart_init(d)) ) - goto fail; + d->arch.emulation_flags |= ARM_EMU_VUART; + } if ( (rc = domain_vpci_init(d)) != 0 ) goto fail; diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c index 9d047065ba13ffe003d2565879cd073e78f76893..f80d34bf5f3d323a15db7f032073be52ea1009ae 100644 --- a/xen/arch/arm/domctl.c +++ b/xen/arch/arm/domctl.c @@ -42,9 +42,11 @@ static int handle_vuart_init(struct domain *d, return -EOPNOTSUPP; rc = domain_vpl011_init(d, &info); - if ( !rc ) + { vuart_op->evtchn = info.evtchn; + d->arch.emulation_flags |= ARM_EMU_VUART; + } return rc; } diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h index f1d72c6e48dfeba347b4cd091ca33603c368b7c0..2bbd3f472176bdcfbc0f95f9d8809343d11965c8 100644 --- a/xen/arch/arm/include/asm/domain.h +++ b/xen/arch/arm/include/asm/domain.h @@ -119,8 +119,17 @@ struct arch_domain void *tee; #endif + /* Emulated devices enabled bitmap. */ + uint32_t emulation_flags; + } __cacheline_aligned; +enum { + ARM_EMU_VUART = BIT(0, U), +}; + +#define domain_has_vuart(d) (!!((d)->arch.emulation_flags & ARM_EMU_VUART)) + struct arch_vcpu { struct { diff --git a/xen/arch/arm/vuart.c b/xen/arch/arm/vuart.c index 38ce8cc14fac4132578059b696be952b29fab809..1fd980bd3a83820b382f875eb87ce4b8d83ccebe 100644 --- a/xen/arch/arm/vuart.c +++ b/xen/arch/arm/vuart.c @@ -31,8 +31,6 @@ #include "vuart.h" -#define domain_has_vuart(d) ((d)->arch.vuart.info != NULL) - static int vuart_mmio_read(struct vcpu *v, mmio_info_t *info, register_t *r, void *priv); static int vuart_mmio_write(struct vcpu *v, mmio_info_t *info, -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:41:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:41:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849417.1264092 (Exim 4.92) (envelope-from ) id 1tJQA2-0006Ns-Sr; Fri, 06 Dec 2024 04:41:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849417.1264092; Fri, 06 Dec 2024 04:41: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 1tJQA2-0006La-24; Fri, 06 Dec 2024 04:41:50 +0000 Received: by outflank-mailman (input) for mailman id 849417; Fri, 06 Dec 2024 04:41: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 1tJQ9x-0004Kb-Vk for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:45 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 617c78bd-b38c-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 05:41:39 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 3DC0C5C7300; Fri, 6 Dec 2024 04:40:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 8A1DAC4CED2; Fri, 6 Dec 2024 04:41:37 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 790DFE77178; Fri, 6 Dec 2024 04:41:37 +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: 617c78bd-b38c-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460097; bh=7koQaWLewXvB3SCK9dZyYM5ZVrnylbZtaIV5UaNbJIw=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=hoHmD/h87nsVaTNuOwWGeJIP/ib+VrDqptGul4bHy+1jdGv6d0tesKtcPvEI/oaJe 5gYgVFGmwqoGY8HEbJxfhSqIJt2tDg0S2l/0824jsFFymZXukR9QdzTePCDTnKjc38 iodnbyM/HB9js6hJlTSJe5RkFB7ZexvdPVAjq3rXZkcAG4deVzj6gZX9VlOuUI2FN4 JCNQptf8RThz9o2L6YpvS5+FNqMfWtdvEWOzE6i8ERk9pL/nbNWc2BWNUTGXcEJyoC 1S96uEz9GWNeT1az2qZFamB5BR34pQ6pLzl92zrJhvSY57uAbe/pxoQ2Gi6vSMfzZa Pbpxih71Gdd6A== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:33 -0800 Subject: [PATCH v2 03/35] xen/ctype: introduce isconsole() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-3-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=2965; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=VA1l2CgJQ6KceeM+tuMGN+rK6UFSe0FXEY/EUwUiYwI=; b=JGqXyT0nbX97Vn2mSNHSEgjpczcuciXKVCHfEW8CEpXFPzirY37JgpYwVuNT3Xh6fyHyQupM6 JwhVvYBYibZAg7WSsrLhqzDPlyDVc9R3X0g80jgVMZyQ7FNV0dbt/mw X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin There are several console drivers which have same checks w.r.t. printable characters. The check is moved to new isconsole() macro and re-used in the console drivers. Signed-off-by: Denis Mukhin --- xen/arch/arm/vuart.c | 3 +-- xen/arch/x86/hvm/hvm.c | 3 +-- xen/drivers/char/console.c | 2 +- xen/include/xen/ctype.h | 3 +++ 4 files changed, 6 insertions(+), 5 deletions(-) diff --git a/xen/arch/arm/vuart.c b/xen/arch/arm/vuart.c index d5ba483f1e63245e545346ad5045098152b8c152..ac76e2327bb84f05ea5716c6f5550f94812d2827 100644 --- a/xen/arch/arm/vuart.c +++ b/xen/arch/arm/vuart.c @@ -79,8 +79,7 @@ static void vuart_print_char(struct vcpu *v, char c) struct domain *d = v->domain; struct vuart *uart = &d->arch.vuart; - /* Accept only printable characters, newline, and horizontal tab. */ - if ( !isprint(c) && (c != '\n') && (c != '\t') ) + if ( !isconsole(c) ) return ; spin_lock(&uart->lock); diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 74e58c653e6f697e7e563fd076bbbafaf257137d..493b699c708949b2109c26573a107565543f5d45 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -561,8 +561,7 @@ static int cf_check hvm_print_line( if ( dir != IOREQ_WRITE ) return X86EMUL_UNHANDLEABLE; - /* Accept only printable characters, newline, and horizontal tab. */ - if ( !isprint(c) && (c != '\n') && (c != '\t') ) + if ( !isconsole(c) ) return X86EMUL_OKAY; spin_lock(&cd->pbuf_lock); diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 7da8c5296f3b62c6c45131c58fe5cf0e393e9ef3..bb56953bab681a13da8d41431aba4632f1919df9 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -674,7 +674,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, c = *kin++; if ( c == '\n' ) break; - if ( isprint(c) || c == '\t' ) + if ( isconsole(c) ) *kout++ = c; } while ( --kcount > 0 ); diff --git a/xen/include/xen/ctype.h b/xen/include/xen/ctype.h index 773ac27aa44ac65e76e87cdec960450804310249..deebaad96ede34f16f61ece862c788232c1d1efd 100644 --- a/xen/include/xen/ctype.h +++ b/xen/include/xen/ctype.h @@ -4,6 +4,8 @@ /* * NOTE! This ctype does not handle EOF like the standard C * library is required to. + * + * See Rule 21.13 in docs/misra/rules.rst. */ #define _U 0x01 /* upper */ @@ -30,6 +32,7 @@ extern const unsigned char _ctype[]; #define isspace(c) ((__ismask(c)&(_S)) != 0) #define isupper(c) ((__ismask(c)&(_U)) != 0) #define isxdigit(c) ((__ismask(c)&(_D|_X)) != 0) +#define isconsole(c) (isprint(c) || (c) == '\n' || (c) == '\t') #define isascii(c) (((unsigned char)(c))<=0x7f) #define toascii(c) (((unsigned char)(c))&0x7f) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:41:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:41:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849412.1264039 (Exim 4.92) (envelope-from ) id 1tJQ9x-0005A7-V9; Fri, 06 Dec 2024 04:41:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849412.1264039; Fri, 06 Dec 2024 04:41: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 1tJQ9x-00058M-Oo; Fri, 06 Dec 2024 04:41:45 +0000 Received: by outflank-mailman (input) for mailman id 849412; Fri, 06 Dec 2024 04:41: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 1tJQ9v-0004Ka-Li for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:43 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 617d6426-b38c-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:41:39 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 01D9E5C72FC; Fri, 6 Dec 2024 04:40:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 71ACCC4CEDD; Fri, 6 Dec 2024 04:41:37 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D5CBE77171; Fri, 6 Dec 2024 04:41:37 +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: 617d6426-b38c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460097; bh=hhpepZyC6+B98tKRYu7FEASFfIF/3/TSsCfLQMcZ32A=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=FgEft6ym49ftHh+ywRhew+yV7ooUsjJ9GgX7qlng7oFqZExFwgdQbJ3OZGbP2k1o8 hqWhBr48KvJajYXUC7s9kLqnORDaBpK0U5DsgE2yh8EUwvu7IWA4n9vf4y8pVWeHuL X0CNBMStmy163XE1QJQFbGSxnnzsiXE71hONAyET4ME7Jkfu4Y5PxY9DYQZi3ceIlX DUpDL78EXSQQxAzrVuEnY8ntTxHi4qhT0SXyQi334r+gmzvcqqV1ccgWwUuMKyjk+o Pf3N/SWiluN7VWPNThRC5ZB/bZ7FQAaFJaZWxzOL40fb6RU3SYMUULqSO3AtNoUJbS 6BhwXmARPGSWg== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:31 -0800 Subject: [PATCH v2 01/35] xen: introduce resource.h MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-1-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=4665; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=Q8GpN19knhkzccfTAV4prViqD1gvBrGqV7AxMvPxGlg=; b=pLKcxFd8odpX59gNXWYl0zBIJnHXlKMAZidA2yu9BapqleSET916m7mHU6Mvl0DNg3hQZIYM4 LVm76T+Dh3WCEayzQHVnI0ba7CbQu+O/yHEdwB8NsPJgJQ3XptYWOIA X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Move resource definitions to a new architecture-agnostic shared header file. It will be used in follow on NS8250 emulator code to describe legacy PC COM resources. Signed-off-by: Denis Mukhin --- xen/common/device-tree/device-tree.c | 21 +------------------ xen/drivers/passthrough/arm/smmu.c | 15 +------------- xen/include/xen/resource.h | 40 ++++++++++++++++++++++++++++++++++++ 3 files changed, 42 insertions(+), 34 deletions(-) diff --git a/xen/common/device-tree/device-tree.c b/xen/common/device-tree/device-tree.c index d0528c5825651f7cc9ebca0c949229c9083063c6..e8f810b2fe10890c033ed3a9d4ca627010ad019b 100644 --- a/xen/common/device-tree/device-tree.c +++ b/xen/common/device-tree/device-tree.c @@ -24,6 +24,7 @@ #include #include #include +#include const void *device_tree_flattened; dt_irq_xlate_func dt_irq_xlate; @@ -535,26 +536,6 @@ int dt_child_n_size_cells(const struct dt_device_node *parent) return __dt_n_size_cells(parent, true); } -/* - * These are defined in Linux where much of this code comes from, but - * are currently unused outside this file in the context of Xen. - */ -#define IORESOURCE_BITS 0x000000ff /* Bus-specific bits */ - -#define IORESOURCE_TYPE_BITS 0x00001f00 /* Resource type */ -#define IORESOURCE_IO 0x00000100 /* PCI/ISA I/O ports */ -#define IORESOURCE_MEM 0x00000200 -#define IORESOURCE_REG 0x00000300 /* Register offsets */ -#define IORESOURCE_IRQ 0x00000400 -#define IORESOURCE_DMA 0x00000800 -#define IORESOURCE_BUS 0x00001000 - -#define IORESOURCE_PREFETCH 0x00002000 /* No side effects */ -#define IORESOURCE_READONLY 0x00004000 -#define IORESOURCE_CACHEABLE 0x00008000 -#define IORESOURCE_RANGELENGTH 0x00010000 -#define IORESOURCE_SHADOWABLE 0x00020000 - /* * Default translator (generic bus) */ diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c index 03d22bce1e497e41834c273f9048b98dcbd48a54..aa6a968b574dce7cc753e8070fad3a6e585cd9e7 100644 --- a/xen/drivers/passthrough/arm/smmu.c +++ b/xen/drivers/passthrough/arm/smmu.c @@ -50,6 +50,7 @@ #include #include #include +#include #include #include #include @@ -70,22 +71,8 @@ #define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, out)) #define of_property_read_bool dt_property_read_bool #define of_parse_phandle_with_args dt_parse_phandle_with_args - -/* Xen: Helpers to get device MMIO and IRQs */ -struct resource -{ - paddr_t addr; - paddr_t size; - unsigned int type; -}; - -#define resource_size(res) (res)->size; - #define platform_device dt_device_node -#define IORESOURCE_MEM 0 -#define IORESOURCE_IRQ 1 - static struct resource *platform_get_resource(struct platform_device *pdev, unsigned int type, unsigned int num) diff --git a/xen/include/xen/resource.h b/xen/include/xen/resource.h new file mode 100644 index 0000000000000000000000000000000000000000..4962e17da8387b7f324317482b19cc9fe71433fc --- /dev/null +++ b/xen/include/xen/resource.h @@ -0,0 +1,40 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * System resource description. + * + * Reference: + * include/linux/ioport.h + */ +#if !defined(XEN__RESOURCE_H) +#define XEN__RESOURCE_H + +#define IORESOURCE_BITS 0x000000FFU /* Bus-specific bits */ + +#define IORESOURCE_TYPE_BITS 0x00001F00U /* Resource type */ +#define IORESOURCE_IO 0x00000100U /* PCI/ISA I/O ports */ +#define IORESOURCE_MEM 0x00000200U +#define IORESOURCE_REG 0x00000300U /* Register offsets */ +#define IORESOURCE_IRQ 0x00000400U +#define IORESOURCE_DMA 0x00000800U +#define IORESOURCE_BUS 0x00001000U + +#define IORESOURCE_PREFETCH 0x00002000U /* No side effects */ +#define IORESOURCE_READONLY 0x00004000U +#define IORESOURCE_CACHEABLE 0x00008000U +#define IORESOURCE_RANGELENGTH 0x00010000U +#define IORESOURCE_SHADOWABLE 0x00020000U + +#define IORESOURCE_UNKNOWN (~0U) + +struct resource { + paddr_t addr; + paddr_t size; + unsigned int type; +}; + +#define resource_size(res) (res)->size; + +#define foreach_resource(res) \ + for (; res && res->type != IORESOURCE_UNKNOWN; res++) + +#endif /* #if !defined(XEN__RESOURCE_H) */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:41:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:41:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849411.1264032 (Exim 4.92) (envelope-from ) id 1tJQ9x-00053D-Ib; Fri, 06 Dec 2024 04:41:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849411.1264032; Fri, 06 Dec 2024 04:41: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 1tJQ9x-00050h-Ab; Fri, 06 Dec 2024 04:41:45 +0000 Received: by outflank-mailman (input) for mailman id 849411; Fri, 06 Dec 2024 04:41: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 1tJQ9u-0004Kb-VS for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:42 +0000 Received: from nyc.source.kernel.org (nyc.source.kernel.org [2604:1380:45d1:ec00::3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6197751f-b38c-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 05:41:39 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 52687A43EE1; Fri, 6 Dec 2024 04:39:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id BC663C4CEE8; Fri, 6 Dec 2024 04:41:37 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id B1075E77175; Fri, 6 Dec 2024 04:41:37 +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: 6197751f-b38c-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460097; bh=W3lsM6sLlkNO6zjU1lHZ+u6ONjEFm+ba+WSVSjVypa4=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=DzXyb2zjGR03GXUhiHI+xBOLA5fTxJrXkDBwuKdD2uykpkrZ+FUvzLyROXp6yAHfk gPqgyybJkcvTsxc15htT0OAM9Ivaj/BmebKPxvPKLGBuw5VzuI279sbQhQr9OKuovx 38W+0IFNSQLSeABoc7GgKPl6gv8MT6rIExY03ViEQYBHm1pKL5hi5B+uO+hiZu3QOO cX1pEb7BisWouEaN5ux86AiFRrq7o8+lg4NqBJSzzQ2tiIfF1x19Gy8zsSakAZCoWF GNR6U8WG+cbnhR4s+kP8mpNHOUh4XGXyj3F2U0R9JFTWCPPSaL1w4VztS1mLM+17wS 52WTHc1B2CF7w== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:37 -0800 Subject: [PATCH v2 07/35] ppc/domain: introduce domain_has_vuart() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-7-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=728; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=t3QJZEOM8PRrx5tFAM37Q5lrsCWx/ouiwIRJrERCogM=; b=Miqdv195rw9t1S3j6p1XRsugjWUwQ1EFx/shKs1eSw6d+ul8/IaMuWZDk+NDDthwgf90m1sxh 3kbUZi6bZ/2BoWa5b05lZ0tlZtXQXK10znL6NDjaUHlqXg1kvLQo1tH X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Introduce domain_has_vuart() for PPC port to be used in the console driver. Signed-off-by: Denis Mukhin --- xen/arch/ppc/include/asm/domain.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/arch/ppc/include/asm/domain.h b/xen/arch/ppc/include/asm/domain.h index 3a447272c6f28586bf0d610929adbf228579e13f..764978e6a61b9d7220ec10fe0763e3424d07d27a 100644 --- a/xen/arch/ppc/include/asm/domain.h +++ b/xen/arch/ppc/include/asm/domain.h @@ -10,6 +10,8 @@ struct hvm_domain uint64_t params[HVM_NR_PARAMS]; }; +#define domain_has_vuart(d) false + /* TODO: Implement */ #define guest_mode(r) ({ (void)(r); BUG_ON("unimplemented"); 0; }) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:41:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:41:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849410.1264022 (Exim 4.92) (envelope-from ) id 1tJQ9w-0004lT-T6; Fri, 06 Dec 2024 04:41:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849410.1264022; Fri, 06 Dec 2024 04: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 1tJQ9w-0004jY-KZ; Fri, 06 Dec 2024 04:41:44 +0000 Received: by outflank-mailman (input) for mailman id 849410; Fri, 06 Dec 2024 04:41: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 1tJQ9u-0004Ka-LG for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:42 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 617d9a09-b38c-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:41:39 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id E20305C0EDA; Fri, 6 Dec 2024 04:40:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 60592C4CED1; Fri, 6 Dec 2024 04:41:37 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4A145E7716F; Fri, 6 Dec 2024 04:41:37 +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: 617d9a09-b38c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460097; bh=9q7mVixn7WzU3hMQhPlch4KRDD8wW06V5dyXPxftnZY=; h=From:Subject:Date:To:Cc:Reply-To:From; b=HSZKSdXeeElirLWxydyj60En5Xpa2uuBKbiWdiLm3k4sgIBdGPt04BWNxuyYhMwjo lKjBbVsVC+fpOK26zpQ1VLdXY80Ubsn2UyvjamQR4VatuXq3IW2cewqSlNIrzVojgI wJGnE4HnpuUBnP19lTqs4PnH7IMMEQ0pSnEjpf07Nd0Tm26Cb1r4BCMRoWP7XxC+9O 7accDtFZbyuK5kELp7prgSVCKQ+gDQKq5B2aAgFWb8Ohz1FOKpdSUUDxBYNvMoLQyS Y6NZZTYX5J3eHS+xoHzCCiNQ4Nl4eIY9cIda9OE3a6d73fA9XiQH88MAa3VvtMH6lJ eEkRLdTivPiCA== From: Denis Mukhin via B4 Relay Subject: [PATCH v2 00/35] Introduce NS8250 UART emulator Date: Thu, 05 Dec 2024 20:41:30 -0800 Message-Id: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAHqAUmcC/x3MMQqAMAxA0atIZgtpSFG8ijhojZqlSqtFEO9uc XzD/w8kiSoJuuqBKFmT7qHA1hX4bQyrGJ2LgZDYEjqTrzGeJqSWHBp2LTeTR7aMUJIjyqL3v+s hEwzv+wHHGfG5YgAAAA== X-Change-ID: 20241205-vuart-ns8250-45847bc04140 To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin , Oleksii Kurochko X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=7806; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=9q7mVixn7WzU3hMQhPlch4KRDD8wW06V5dyXPxftnZY=; b=wu87/WMMcq7kCGsWrNsCbOgz6lVO553WIrzg76dgaUMYmqQj4Bqs4n0nP7xVOkHdu46kASzcf mHjyChvpabRAC05U5Ldjv9zsXyZFwIJPV7ZCOE0r5qYf0IFrxFFEE/c X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com The patch series introduces initial in-hypervisor emulator for NS8250/NS16x50-compatible UARTs under CONFIG_HAS_VUART_NS8250. In parallel domain creation scenario (hyperlaunch), NS8520 emulator helps early guest OS bringup debugging, because it eliminates dependency on the external emulator being operational by the time domains are created. Also, there's no early console facility similar to vpl011 to support x86 guest OS bring up. The NS8250 emulator is disabled by default. Series ====== - patches 1-11: preparation fixes for xen console and NS8250 emulator. - patches 12-27: xen console driver cleanup, fixes and preparation for enabling physical serial console focus assignment to the guest VM w/ virtual NS8250. - patches 28-35: initial NS8250 emulator. That adds the I/O port emulator for legacy PC COM UARTs, Kconfig option, enabling emulator and libxl plumbing. Limitations =========== - Only x86; - Only Linux guest tested so far; - Only legacy COM{1,2,3,4} resources, no customization; - Only Xen console as a backend, no inter-domain communication (similar to vpl011 on Arm); - Only 8-bit characters; - Baud rate is not emulated; - FIFO-less mode is not emulated properly; - RX FIFO interrupt moderation (FCR) is not emulated properly, TL16C750 has special FCR handling; - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and friends); - Assumes no ISA-device IRQ sharing; - MMIO-based UART is not supported. Testing ======= Gitlab CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/1576164352 I tested boot of HVM linux guest w/ OVMF as the virtual firmware. The emulator, if enabled via CONFIG_HAS_VUART_NS8250=y, will use COM1 (0x3f8) resources by default. To test w/ virtual COM1, the guest kernel parameters should contain earlycon=uart,io,0x3f8,115200n8 console=uart,io,0x3f8,115200n8 Xen is able to forward physical console input to the domain w/ virtual NS8250. To switch the console focus press Ctrl+aaa. If console= is given to the HVM kernel, then the user shall be able to see the login prompt on xen console once console focus is switched to the HVM guest. Luca Fancellu helped big time w/ verifying the patch series on arm{32,64} w/ FVP Linux as a guest OS. Signed-off-by: Denis Mukhin --- Changes in v2: - dropped kmalloc/kfree aliases - fixed ECLAIR jobs (thanks Andrew Cooper) - addressed console forwarding on arm32 and arm64 (thanks to Luca Fancellu) - moved NS8250 debugging stubs into its own patch - added fix for https://gitlab.com/xen-project/xen/-/issues/184 - Link to v1: https://lore.kernel.org/r/20241126-vuart-ns8250-v1-v1-0-87b9a8375b7a@ford.com --- Denis Mukhin (35): xen: introduce resource.h xen/irq: introduce NO_IRQ xen/ctype: introduce isconsole() arm/vuart: use guest_printk() arm/vuart: make domain_has_vuart() public riscv/domain: introduce domain_has_vuart() ppc/domain: introduce domain_has_vuart() x86/domain: introduce domain_has_vuart() x86/domain: print emulation_flags xen/domain: add get_initial_domain_id() xen/domain: enable max_init_domid for all architectures xen/console: move vpl011-related code to vpl011 emulator xen/console: rename console_input_domain xen/console: rename switch_serial_input() to console_find_owner() xen/console: rename console_rx to console_owner xen/console: introduce printk_common() xen/console: introduce consoled_is_enabled() xen/console: introduce use of 'is_console' flag xen/console: introduce console_set_owner() xen/console: introduce console_owner_domid() xen/console: introduce console_init_owner() xen/console: introduce handle_keypress_in_domain() xen/console: introduce console_write() xen/console: introduce hwdom_crashconsole= xen/console: simplify console owner switch hint xen/console: make console buffer size configurable xen/console: flush console ring to physical console xen/8250-uart: add missing definitions x86/hvm: add HVM-specific Kconfig x86/hvm: add helpers for raising guest IRQs x86/hvm: introduce NS8250 UART emulator x86/hvm: add debugging facility to NS8250 UART emulator x86/domain: implement domain_has_vuart() xen/console: enable console owners w/ emulated NS8250 docs/misc: update console documentation automation/eclair_analysis/ECLAIR/deviations.ecl | 2 +- docs/misc/console.txt | 50 +- docs/misc/xen-command-line.pandoc | 5 + tools/libs/light/libxl_x86.c | 6 +- tools/ocaml/libs/xc/xenctrl.ml | 1 + tools/ocaml/libs/xc/xenctrl.mli | 1 + tools/python/xen/lowlevel/xc/xc.c | 4 +- xen/arch/arm/dom0less-build.c | 4 +- xen/arch/arm/domain.c | 20 +- xen/arch/arm/domctl.c | 5 +- xen/arch/arm/include/asm/domain.h | 9 + xen/arch/arm/include/asm/setup.h | 2 - xen/arch/arm/include/asm/vpl011.h | 2 +- xen/arch/arm/setup.c | 2 - xen/arch/arm/vpl011.c | 19 +- xen/arch/arm/vuart.c | 7 +- xen/arch/ppc/include/asm/domain.h | 2 + xen/arch/ppc/include/asm/setup.h | 2 - xen/arch/riscv/include/asm/domain.h | 2 + xen/arch/riscv/include/asm/setup.h | 2 - xen/arch/x86/Kconfig | 66 +- xen/arch/x86/dom0_build.c | 2 + xen/arch/x86/domain.c | 16 +- xen/arch/x86/hvm/Kconfig | 77 ++ xen/arch/x86/hvm/Makefile | 1 + xen/arch/x86/hvm/hvm.c | 16 +- xen/arch/x86/hvm/irq.c | 24 + xen/arch/x86/hvm/vuart_ns8250.c | 1008 ++++++++++++++++++++++ xen/arch/x86/include/asm/domain.h | 8 +- xen/arch/x86/include/asm/hvm/domain.h | 5 + xen/arch/x86/include/asm/hvm/irq.h | 3 + xen/arch/x86/include/asm/hvm/vuart_ns8250.h | 75 ++ xen/arch/x86/include/asm/pv/shim.h | 4 +- xen/arch/x86/include/asm/setup.h | 2 - xen/arch/x86/pv/shim.c | 6 +- xen/common/device-tree/device-tree.c | 21 +- xen/common/domain.c | 35 +- xen/drivers/char/Kconfig | 23 + xen/drivers/char/console.c | 394 +++++---- xen/drivers/char/consoled.c | 18 +- xen/drivers/passthrough/arm/smmu.c | 15 +- xen/include/public/arch-x86/xen.h | 14 +- xen/include/xen/8250-uart.h | 81 +- xen/include/xen/console.h | 4 +- xen/include/xen/consoled.h | 35 +- xen/include/xen/ctype.h | 3 + xen/include/xen/domain.h | 5 + xen/include/xen/irq.h | 1 + xen/include/xen/lib.h | 3 + xen/include/xen/resource.h | 40 + 50 files changed, 1799 insertions(+), 353 deletions(-) --- base-commit: dc8e1b33a525d31989c0d1ffe6ae7794484e1d99 change-id: 20241205-vuart-ns8250-45847bc04140 Best regards, -- Denis Mukhin From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:41:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:41:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849416.1264080 (Exim 4.92) (envelope-from ) id 1tJQA1-0006Dm-T7; Fri, 06 Dec 2024 04:41:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849416.1264080; Fri, 06 Dec 2024 04:41: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 1tJQA1-0006Bs-Bc; Fri, 06 Dec 2024 04:41:49 +0000 Received: by outflank-mailman (input) for mailman id 849416; Fri, 06 Dec 2024 04:41: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 1tJQ9x-0004Ka-Ly for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:45 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [2604:1380:4641:c500::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 63086e56-b38c-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:41:41 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 9DE2C5C730C; Fri, 6 Dec 2024 04:40:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 11DC6C4CEDE; Fri, 6 Dec 2024 04:41:38 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0B848E77173; Fri, 6 Dec 2024 04:41:38 +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: 63086e56-b38c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460098; bh=+LyhLMcPTctK8lq8DYz5tUJcWDqBCiRHMGxFmxItyZs=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=HBz+lNxRiLiqkCAG1Sbj8epCgg/Cp6fOqh1OfYZMGXzeLm7CsM/uW+4eYuDwjeZ+u ntKEVy2vfBbN6qjG2zrmR6GM33QU91X8oz5uPJRiikGJXNR5AasNHw5k2s0x4zicuq IiJpAbnv0oGEg5G6EP7+7RajPRXWFcQLPRbi/o+xSST7a1QZZrI4GTp9/oLUIpXBfs cXGfBfvnz8bXfzejW4Bv30qLL9A+2bLEvlzW6pmcoETpfVr2X0rPE3yvanWbarC0+0 3uQZKhDRvXJjLrGsW8ytGUUQ+FzF1vHqBJWBNyXyumxGxqXgD9+r4t+xN9c4pjgot0 8/mX2URhGIHnA== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:42 -0800 Subject: [PATCH v2 12/35] xen/console: move vpl011-related code to vpl011 emulator MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-12-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=3432; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=4e0NUECCqgXdJR10Lb5Vlh9vQMFlpd/8G3QTPhFXMng=; b=KocrOyWBiCRdnAEiMCLW1htC7QinL+Mg1NhUgbiDAge7ljxpdEUkZHKjGaPRBPpqIuYyd94qh VtPCr7iMtAuCevzRbRS6SKJouJY7MRd2FPh0+9iI/OWzujWexOb2SBA X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Xen console driver has vpl011-related logic which shall belong vpl011 emulator code. Move vpl011-related to vpl011.c. Signed-off-by: Denis Mukhin --- xen/arch/arm/include/asm/vpl011.h | 2 +- xen/arch/arm/vpl011.c | 15 +++++++++++---- xen/drivers/char/console.c | 4 +--- 3 files changed, 13 insertions(+), 8 deletions(-) diff --git a/xen/arch/arm/include/asm/vpl011.h b/xen/arch/arm/include/asm/vpl011.h index c09abcd7a9b3356d0809743517934adae00087f5..cc838682815c0d049ba33d3bf9966a64b2e527dd 100644 --- a/xen/arch/arm/include/asm/vpl011.h +++ b/xen/arch/arm/include/asm/vpl011.h @@ -69,7 +69,7 @@ struct vpl011_init_info { int domain_vpl011_init(struct domain *d, struct vpl011_init_info *info); void domain_vpl011_deinit(struct domain *d); -void vpl011_rx_char_xen(struct domain *d, char c); +int vpl011_rx_char_xen(struct domain *d, char c); #else static inline int domain_vpl011_init(struct domain *d, struct vpl011_init_info *info) diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c index 8ade6f2588b8bbcc58fb0f9edc324502a1992ce7..fe36fe2bd1529a4114884580ded6d6fa55a22f0e 100644 --- a/xen/arch/arm/vpl011.c +++ b/xen/arch/arm/vpl011.c @@ -567,16 +567,21 @@ static void vpl011_data_avail(struct domain *d, /* * vpl011_rx_char_xen adds a char to a domain's vpl011 receive buffer. - * It is only used when the vpl011 backend is in Xen. */ -void vpl011_rx_char_xen(struct domain *d, char c) +int vpl011_rx_char_xen(struct domain *d, char c) { unsigned long flags; struct vpl011 *vpl011 = &d->arch.vpl011; struct vpl011_xen_backend *intf = vpl011->backend.xen; XENCONS_RING_IDX in_cons, in_prod, in_fifo_level; - ASSERT(!vpl011->backend_in_domain); + /* Forward input iff the vpl011 backend is in Xen. */ + if ( vpl011->backend_in_domain ) + return -ENODEV; + + if ( intf == NULL ) + return -ENODEV; + VPL011_LOCK(d, flags); in_cons = intf->in_cons; @@ -584,7 +589,7 @@ void vpl011_rx_char_xen(struct domain *d, char c) if ( xencons_queued(in_prod, in_cons, sizeof(intf->in)) == sizeof(intf->in) ) { VPL011_UNLOCK(d, flags); - return; + return -ENOSPC; } intf->in[xencons_mask(in_prod, sizeof(intf->in))] = c; @@ -596,6 +601,8 @@ void vpl011_rx_char_xen(struct domain *d, char c) vpl011_data_avail(d, in_fifo_level, sizeof(intf->in), 0, SBSA_UART_FIFO_SIZE); VPL011_UNLOCK(d, flags); + + return 0; } static void vpl011_notification(struct vcpu *v, unsigned int port) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index bb56953bab681a13da8d41431aba4632f1919df9..0af4b551801356f242f1770b3826608136d65653 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -559,9 +559,7 @@ static void __serial_rx(char c) * domain, without a full PV ring to Dom0 (in that case input * comes from the PV ring), then send the character to it. */ - if ( d != NULL && - !d->arch.vpl011.backend_in_domain && - d->arch.vpl011.backend.xen != NULL ) + if ( d != NULL ) vpl011_rx_char_xen(d, c); else printk("Cannot send chars to Dom%d: no UART available\n", -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:41:51 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:41:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849418.1264100 (Exim 4.92) (envelope-from ) id 1tJQA3-0006ib-N0; Fri, 06 Dec 2024 04:41:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849418.1264100; Fri, 06 Dec 2024 04:41: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 1tJQA3-0006fj-4Q; Fri, 06 Dec 2024 04:41:51 +0000 Received: by outflank-mailman (input) for mailman id 849418; Fri, 06 Dec 2024 04:41: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 1tJQ9y-0004Ka-MH for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:46 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 631e1280-b38c-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:41:42 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id C776E5C7313; Fri, 6 Dec 2024 04:40:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 680C5C4CEE2; Fri, 6 Dec 2024 04:41:38 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5C123E77175; Fri, 6 Dec 2024 04:41:38 +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: 631e1280-b38c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460098; bh=xTYc/Qlg0H7wze8ET4iZ+jZPU60Pxe70nfmD2bNhJJc=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=HmxMoZEM1burY3Rn3ELAcCBBQCqV6gh5CTS8conK3YXZJBM2SuvqT3BYQwzx/imP4 JdbAbm3TTRVp7cNBAehwNLOXcvG0i9FhvdJ8cwPYl6+xvu+KEgJspDo5jCcw9+DqGA +xPtoAINRl2RVfHtHfFVSK5+YcKjaOszAlf4chNs2TaAONwcn7C9zM3amQtuu+5xs2 KpbAmhuhPVNdt/wUoJljwjkzp7jY3r6YEdyMsDlE9yJS2opANb2Y81Y32je1VzD3XN W1NnfFb5NBfCyyjCqeRtYIJ7vQGZGxxTIvcXj90RNxabz0NSpflhPq5+uTd1vgJ9KF S6eZvc8UU2JNg== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:46 -0800 Subject: [PATCH v2 16/35] xen/console: introduce printk_common() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-16-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=2804; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=0ZbhB6X3j//rZlvA+RHGboOQv/T4QXzBiywEl761Zm0=; b=mvzE8dnFdKifjiI0dNonuR4BBXjCK1QgfdIVHGd90YVxQ4pyP2joNBy5YkM/E0s0jgY0pCc59 ZutJT2tuuA5B0gthGeK0qfNuZBTsquHOQi7NQWwUpYzKUjR3VI2XKEp X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Introduce new printk() variant for convenient printouts which skip '(XEN)' prefix on xen console. This is needed for the case when physical console is owned by a domain w/ in-hypervisor UART emulation enabled. Signed-off-by: Denis Mukhin --- automation/eclair_analysis/ECLAIR/deviations.ecl | 2 +- xen/drivers/char/console.c | 8 ++++++++ xen/include/xen/lib.h | 3 +++ 3 files changed, 12 insertions(+), 1 deletion(-) diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl index 2f58f292036e3561118ce9664a92756b1b938739..c59d075262e9e6618ea2a2d27611a537ded3a776 100644 --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -522,7 +522,7 @@ safe." -config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printf\\(.*\\)$)))"} -config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"} -config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"} --config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"} +-config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(^v?printk_common)&&kind(function))))"} -config=MC3R1.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"} -doc_end diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 86bf899ada8f8221ffc77bcffb1f58777a22198e..f034ce5aab3f3bf59b0df9fa583ee9ce32dbf665 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -968,6 +968,14 @@ void printk(const char *fmt, ...) va_end(args); } +void printk_common(const char *fmt, ...) +{ + va_list args; + va_start(args, fmt); + vprintk_common("", fmt, args); + va_end(args); +} + void guest_printk(const struct domain *d, const char *fmt, ...) { va_list args; diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h index 81b722ea3e801e9089aaf8758249feb3a758c4f7..8a7ff2e8af9089796ff28ef8d01c00e9845782ca 100644 --- a/xen/include/xen/lib.h +++ b/xen/include/xen/lib.h @@ -61,6 +61,9 @@ debugtrace_printk(const char *fmt, ...) {} extern void printk(const char *fmt, ...) __attribute__ ((format (printf, 1, 2), cold)); +extern void printk_common(const char *fmt, ...) + __attribute__ ((format (printf, 1, 2))); + #define printk_once(fmt, args...) \ ({ \ static bool __read_mostly once_; \ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:41:52 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:41:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849406.1263994 (Exim 4.92) (envelope-from ) id 1tJQ9v-0004LD-Gw; Fri, 06 Dec 2024 04:41:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849406.1263994; Fri, 06 Dec 2024 04:41: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 1tJQ9v-0004L6-EE; Fri, 06 Dec 2024 04:41:43 +0000 Received: by outflank-mailman (input) for mailman id 849406; Fri, 06 Dec 2024 04:41: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 1tJQ9t-0004Ka-Rt for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:41 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 617d9a13-b38c-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:41:39 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 438EA5C7301; Fri, 6 Dec 2024 04:40:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 96D5BC4CEE1; Fri, 6 Dec 2024 04:41:37 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85447E7716F; Fri, 6 Dec 2024 04:41:37 +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: 617d9a13-b38c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460097; bh=8N48N7tGzPRpnph3uUKQy0qYgM/g5Ojg1QgMgxF7sN8=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=B7AKTba+ZCUl25/KVnwXJy8Hx4furWv40RdLJaBnWVuOeZFlL/5lXJCq2aX3vKNY0 FOPix4J8eUDtwg7EjiUI9azlKC5V7Ci32+o22yC5GcEML6yz2jSqzMyg9ZW6vutoIM ZFTso8B0JdpV5SlGxqfc+o0tWdfJ4oeDBHAHJVm+WEwcrSxmZH6i5xaTkJY1josudm ZGXCgRot0jLMbpwx3mN+hBvdUELrLXlCeiCVP5OA9c89lUik+igDLmmsrAE+5evPFH RbJad18NKxmI4mCFErwyOwedH1ceSBgUOmilmdSsGu38B3PqTqJQw0wCP+BMf9v2GM JanRKrjFnDcvA== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:34 -0800 Subject: [PATCH v2 04/35] arm/vuart: use guest_printk() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-4-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=1513; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=6dwRL08Xk+9xlKPfi6ImA8lNmAhhTdKU8a+CgXv8hC0=; b=r5qb9yLpCd19QazESKUYeqUw7XPz66116TcHZEi5I9uE5J5SBT20R+uyqiC8flWJlNa2WIADE piEke0mFrzmBELwfn54JWQkHGG+Fa1aPdvjA0UdJOW55FV1zieIoAsz X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Use guest_printk() in all current in-hypervisor UART emulators. That slightly improves the logging as guest_printk() already prints the domain ID. Signed-off-by: Denis Mukhin --- xen/arch/arm/vpl011.c | 2 +- xen/arch/arm/vuart.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c index 1fc3114cce9ddb48cf199834c8e9abe8cfba92b5..8ade6f2588b8bbcc58fb0f9edc324502a1992ce7 100644 --- a/xen/arch/arm/vpl011.c +++ b/xen/arch/arm/vpl011.c @@ -107,7 +107,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data) if ( data != '\n' ) intf->out[intf->out_prod++] = '\n'; intf->out[intf->out_prod++] = '\0'; - printk("DOM%u: %s", d->domain_id, intf->out); + guest_printk(d, "%s", intf->out); intf->out_prod = 0; } } diff --git a/xen/arch/arm/vuart.c b/xen/arch/arm/vuart.c index ac76e2327bb84f05ea5716c6f5550f94812d2827..38ce8cc14fac4132578059b696be952b29fab809 100644 --- a/xen/arch/arm/vuart.c +++ b/xen/arch/arm/vuart.c @@ -89,7 +89,7 @@ static void vuart_print_char(struct vcpu *v, char c) if ( c != '\n' ) uart->buf[uart->idx++] = '\n'; uart->buf[uart->idx] = '\0'; - printk(XENLOG_G_DEBUG "DOM%u: %s", d->domain_id, uart->buf); + guest_printk(d, "%s", uart->buf); uart->idx = 0; } spin_unlock(&uart->lock); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:41:52 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:41:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849419.1264107 (Exim 4.92) (envelope-from ) id 1tJQA4-0006xo-K5; Fri, 06 Dec 2024 04:41:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849419.1264107; Fri, 06 Dec 2024 04:41:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJQA3-0006sO-Ra; Fri, 06 Dec 2024 04:41:51 +0000 Received: by outflank-mailman (input) for mailman id 849419; Fri, 06 Dec 2024 04:41: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 1tJQ9y-0004Kb-WC for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:47 +0000 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 62e2a800-b38c-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 05:41:41 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id C3801A43EE9; Fri, 6 Dec 2024 04:39:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 8FD2BC4CEDD; Fri, 6 Dec 2024 04:41:39 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 879A7E77179; Fri, 6 Dec 2024 04:41: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: 62e2a800-b38c-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460099; bh=C4I0w8+5EC1wc6Fr7dK8Qf/iMDwJkx3ZOmN4HyH2Ud0=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=qKYFw2l/moSm4D/CiV74R+PyKJbSHn30VRjrCUtepKwzcx8qdNvQpKemQ4AaQtLsv U/E3gB0mr/dPn0WffqoJMTR225fGoZuSl6vnE5nmutU5mKh6pA0lo7eGelK1FArqCu fotwvW5Pt7j809Yw7jNpfbAv1Fhb93HYN8kpKRzkXz2wUTuy+8T3hjPwwPbtXR9xk6 goyoI7XfLDcMy9ha4lpxlN3qZ24JA2sV2o5fhiuzB/j6XyEX+05MQ4/h4lNCXj0bx2 JhWkcEeGcb1BBWOoyn0KPrCzieXX4Ry1IVRP2BFuWdIkXo6tnVSWgInsY2KZC3B3dp 3RHRQnAeaf/Bg== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:42:05 -0800 Subject: [PATCH v2 35/35] docs/misc: update console documentation MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-35-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460095; l=5686; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=APQcmog0xQYM3EBoFVE5ETu0ersksioDS4x/FBTt9bk=; b=fcukqs0MtpzP6GXP1AFPeyDh0mwVyYwNrAX1JE4Iad+84acEb8EnzftsWAW+Z/wvNGcrsuDbD /f1msBsXsXIBcTxHGqeGTmkklbg1oCypJQ1P8VwuGv9wF8UtrpSF+ZE X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Minor update related to virtual UART support. Also: s/pv/PV/g s/hvm/HVM/g Signed-off-by: Denis Mukhin --- docs/misc/console.txt | 50 ++++++++++++++++++++++++++------------------------ 1 file changed, 26 insertions(+), 24 deletions(-) diff --git a/docs/misc/console.txt b/docs/misc/console.txt index 4e180f88ba1312d8fcc47d27622ec347d387ce12..7840729b0c95d9c4ea5295f17ce77c04177f48a5 100644 --- a/docs/misc/console.txt +++ b/docs/misc/console.txt @@ -4,11 +4,11 @@ Xen PV Console notes stefano.stabellini@eu.citrix.com -Xen traditionally provided a single pv console to pv guests, storing the +Xen traditionally provided a single PV console to PV guests, storing the relevant information in xenstore under /local/domain/$DOMID/console. -Now many years after the introduction of the pv console we have -multiple pv consoles support for pv and hvm guests; multiple pv +Now many years after the introduction of the PV console we have +multiple PV consoles support for PV and HVM guests; multiple PV console backends (qemu and xenconsoled, see limitations below) and emulated serial cards too. @@ -103,48 +103,50 @@ The supported values are only xenconsoled or ioemu; xenconsoled has several limitations: it can only be used for the first PV or virtual UART console and it can only connect to a pty. -Emulated serials are provided by qemu-dm only to hvm guests; the number -of emulated serials depends on how many "-serial" command line options -are given to qemu. The output of a serial is specified as argument to -the -serial command line option to qemu. Qemu writes the tty name to -xenstore in the following path: +Emulated serials are provided to HVM guests by qemu-dm or in-hypervisor UART +emulator (Xen needs to be re-compiled). + +In qemu-dm case, the number of emulated serials depends on how many "-serial" +command line options are given to qemu. The output of a serial is specified as +argument to the -serial command line option to qemu. Qemu writes the tty name +to xenstore in the following path: /local/domain/$DOMID/serial/$SERIAL_NUM/tty xenconsole is the tool to connect to a PV or virtual UART console or an emulated serial that has a pty as output. Xenconsole takes a domid as -parameter plus an optional console type (pv for PV consoles, vuart for -virtual UART or serial for emulated serials) and console number. +parameter plus an optional console type ('pv' for PV consoles, 'vuart' for +virtual UART or 'serial' for emulated serials) and console number. Depending on the type and console number, xenconsole will look for the tty node in different xenstore paths, as described above. If the user doesn't -specify the console type xenconsole will try to guess: if the guest is a pv -guest it defaults to PV console, if the guest is an hvm guest it defaults to +specify the console type xenconsole will try to guess: if the guest is a PV +guest it defaults to PV console, if the guest is an HVM guest it defaults to emulated serial. -By default xl creates a pv console for hvm guests, plus an emulated +By default xl creates a PV console for HVM guests, plus an emulated serial if the user specified 'serial = "pty"' in the VM config file. -Considering that xenconsole defaults to emulated serials for hvm guests, +Considering that xenconsole defaults to emulated serials for HVM guests, executing xl create -c "domain" causes xenconsole to attach to the emulated serial tty. This is most probably what the user wanted because -currently no bootloaders support xen pv consoles so the only way to +currently no bootloaders support xen PV consoles so the only way to interact with a bootloader like grub over a console is to use the emulated serial. -However the pv console is still easy to use with Linux PV on HVM guests: +However the PV console is still easy to use with Linux PV on HVM guests: the user just need to pass "console=hvc0" to the kernel command line and then execute "xl console -t pv " to connect to it. When using stubdoms the serial cards are still emulated by qemu (this time running in the stubdom), the number of serial cards and where the output goes is still specified using qemu command line options. -The difference is that for each emulated serial card there must be a pv +The difference is that for each emulated serial card there must be a PV console connection between the stubdom and dom0 to export the serial -output from the stubdom to dom0. The pv console backend for stubdom's pv -consoles is always ioemu because multiple pv consoles support is a -requirement in this case, considering that minios has its own pv console -too. In order to simplify the setup when using stubdoms the hvm guest -can only have one pv console with xenstored as backend (the stubdom -could provide pv console backends to the hvm guest but then it would -need another pv console connection for each console backend to export +output from the stubdom to dom0. The PV console backend for stubdom's PV +consoles is always ioemu because multiple PV consoles support is a +requirement in this case, considering that minios has its own PV console +too. In order to simplify the setup when using stubdoms the HVM guest +can only have one PV console with xenstored as backend (the stubdom +could provide PV console backends to the HVM guest but then it would +need another PV console connection for each console backend to export the pty to dom0). The xenconsole program supports a very simple protocol to notify parent about -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:41:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:41:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849420.1264115 (Exim 4.92) (envelope-from ) id 1tJQA5-0007IH-QD; Fri, 06 Dec 2024 04:41:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849420.1264115; Fri, 06 Dec 2024 04:41:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJQA5-0007DH-Gg; Fri, 06 Dec 2024 04:41:53 +0000 Received: by outflank-mailman (input) for mailman id 849420; Fri, 06 Dec 2024 04:41: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 1tJQ9z-0004Ka-MQ for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:47 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [2604:1380:4641:c500::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 63b0a2cb-b38c-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:41:42 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 118C75C731A; Fri, 6 Dec 2024 04:40:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id A5D68C4CEE1; Fri, 6 Dec 2024 04:41:38 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9D9D6E77179; Fri, 6 Dec 2024 04:41:38 +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: 63b0a2cb-b38c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460098; bh=70k9tJWzxtakueDep8Z1r6BQFS566Fm/qs8rAVna/Is=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=c3NdRxrqCvEV62tN4hsqcZTPtfE4RgPlSdoCGonfz9cV69ojSBT7UTIyUqG8hMLmd bB8Uc1ysYXJ/7jzaDCATOfCzpx9ro8LPrB5HyMMFDbrdeI0Aw6sZETaWukcjpJfpIO ZLBOiRdyT2bpKNpDgjsIWLnd2Nmoi0z4yR02dCqEFeuUbQ9HoDfOj4T48frmIAOiS5 2CChhNXhld9o1KwZMY8NEH3Mb0hpKUfF6HzIpeviE99HAO5kB8of9BL0dIV8XZHgpZ oOLyCiOgwHWjB9SYKnvkagRo92j4V3nfzrX00ocJ4aetS2wwm36ebvUHy7sCv6YyVk 5CIGZwm0Goyfw== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:50 -0800 Subject: [PATCH v2 20/35] xen/console: introduce console_owner_domid() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=1498; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=B93paIiJy8o1DGD2n2g3KcZoYn4UUAYMMgdZEki+Vh4=; b=Knkc/GPlePCDp77YoynQwfl3vAq4MXPN4bGfSacAecxhgdGewN2VzhLvq78O/rqeOAPhPSSP+ d4gtAVUmJSEDCqv/TzQSACQbYlZC+3mE3ziOkjv6lNWXlNd0dODNmWy X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin console_owner_domid() is introduced to obtain the "console owner" domain ID. The call is used in NS8250 emulator to identify the case when physical xen console focus is owned by the domain w/ NS8250 emulator, in which case, messages from guest OS are formatted w/o '(XEN)' prefix. Signed-off-by: Denis Mukhin --- xen/drivers/char/console.c | 5 +++++ xen/include/xen/console.h | 1 + 2 files changed, 6 insertions(+) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 52cf64dbf6fd18d599cb88835d03501a23b3e3c4..a8ab5c2bcb98e4cadf9ad2c9ad28d297977d0557 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -498,6 +498,11 @@ struct domain *rcu_lock_domain_console_owner(void) return rcu_lock_domain_console_by_id(console_owner); } +domid_t console_owner_domid(void) +{ + return console_owner; +} + static bool console_owner_possible(domid_t domid) { struct domain *d; diff --git a/xen/include/xen/console.h b/xen/include/xen/console.h index 57c482cfbf2da15b011e64841ea086e779f4588d..83be5794aff6630beaad46f910fcc0fc6d833808 100644 --- a/xen/include/xen/console.h +++ b/xen/include/xen/console.h @@ -33,6 +33,7 @@ void console_end_log_everything(void); struct domain *rcu_lock_domain_console_owner(void); int console_set_owner(domid_t); +domid_t console_owner_domid(void); /* * Steal output from the console. Returns +ve identifier, else -ve error. -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:41:55 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:41:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849421.1264124 (Exim 4.92) (envelope-from ) id 1tJQA7-0007VG-06; Fri, 06 Dec 2024 04:41:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849421.1264124; Fri, 06 Dec 2024 04:41: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 1tJQA6-0007RI-A9; Fri, 06 Dec 2024 04:41:54 +0000 Received: by outflank-mailman (input) for mailman id 849421; Fri, 06 Dec 2024 04:41: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 1tJQ9z-0004Kb-W4 for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:47 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 62c8835c-b38c-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 05:41:41 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 6FFB45C7307; Fri, 6 Dec 2024 04:40:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id E9ACAC4CEE0; Fri, 6 Dec 2024 04:41:37 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id E22EDE77175; Fri, 6 Dec 2024 04:41:37 +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: 62c8835c-b38c-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460097; bh=tVwGh2fI891yEmph9JS9g2v7QV1qSjDfL8jnuUT3Tb8=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=DBzgJtybXhXq1eNkGfJ8DH1NhvocvW43UaWJ9Yx+ZaXnNmA7O91SFdmShOORcVfjc jJkau6mG4PfPNOa4/gtFMIMNBSuBVQ6+QULjgjSOucPgBbrGBRwBQdv3Q1JPenSYxo StTLy1K1v+DGdusUclQTcVrhsIMhXGkXujhnJcSKF6smgwfomcNBGKegVM17FzZBcR ILYV6ViRZ+htsoggtX+Xrtdx3yiRGKpZHQl9qXkuBHnW4wwrVYnPuxKSlGyqVeAtuh lKJdnFiqZHDxt2JE2VxWnV7BgfUTYJ/pYb8RrXVXFOzHNhAkH7Un/VfcFRnFQ28tLq bTNnIVfNOYHmw== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:40 -0800 Subject: [PATCH v2 10/35] xen/domain: add get_initial_domain_id() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-10-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=3214; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=e/LNB+9Wk5d4Vu+ImwNmQARBXeefJiOOq9L8JfHstNA=; b=5L8rPCs4pZZiWY8ZAdYomk3nYievoOQV1OGbxK/bIoBZOmkf4+R9OBRrd2hxO0WaHFXCsqyvB h1bbyNFHNsVBIh6LUg6sY+kHC6raUY41Eek0IyLAbNbykEParYXDVD8 X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Move get_initial_domain_id() to a public API and enable for all architectures. That is pre-requisite change for console focus switch logic cleanup. Signed-off-by: Denis Mukhin --- xen/arch/x86/include/asm/pv/shim.h | 4 ++-- xen/arch/x86/pv/shim.c | 4 ++-- xen/common/domain.c | 10 ++++++++++ xen/include/xen/domain.h | 2 ++ 4 files changed, 16 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/include/asm/pv/shim.h b/xen/arch/x86/include/asm/pv/shim.h index 6153e27005986881ad87e9db0b555b30edc59fc0..1515ad1b0680aa11ab91a152a1944fc1bb477a79 100644 --- a/xen/arch/x86/include/asm/pv/shim.h +++ b/xen/arch/x86/include/asm/pv/shim.h @@ -31,7 +31,7 @@ long cf_check pv_shim_cpu_up(void *data); long cf_check pv_shim_cpu_down(void *data); void pv_shim_online_memory(unsigned int nr, unsigned int order); void pv_shim_offline_memory(unsigned int nr, unsigned int order); -domid_t get_initial_domain_id(void); +domid_t pv_shim_initial_domain_id(void); uint64_t pv_shim_mem(uint64_t avail); void pv_shim_fixup_e820(void); const struct platform_bad_page *pv_shim_reserved_pages(unsigned int *size); @@ -76,7 +76,7 @@ static inline void pv_shim_offline_memory(unsigned int nr, unsigned int order) { ASSERT_UNREACHABLE(); } -static inline domid_t get_initial_domain_id(void) +static inline domid_t pv_shim_initial_domain_id(void) { return 0; } diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c index 81e4a0516d18b359561f471f1d96e38977661ca7..17cb30620290c76cf42251f70cfa4199c0e165d1 100644 --- a/xen/arch/x86/pv/shim.c +++ b/xen/arch/x86/pv/shim.c @@ -328,7 +328,7 @@ int pv_shim_shutdown(uint8_t reason) } /* Update domain id. */ - d->domain_id = get_initial_domain_id(); + d->domain_id = pv_shim_initial_domain_id(); /* Clean the iomem range. */ BUG_ON(iomem_deny_access(d, 0, ~0UL)); @@ -1016,7 +1016,7 @@ void pv_shim_offline_memory(unsigned int nr, unsigned int order) } } -domid_t get_initial_domain_id(void) +domid_t pv_shim_initial_domain_id(void) { uint32_t eax, ebx, ecx, edx; diff --git a/xen/common/domain.c b/xen/common/domain.c index 92263a4fbdc57159b4a32d9d4ee038f9f37804ed..2f67aa06ed50e69c27cedc8d7f6eb0b469fe81cd 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -45,6 +45,7 @@ #ifdef CONFIG_X86 #include +#include #endif /* Linux config option: propageted to domain0 */ @@ -2229,6 +2230,15 @@ int continue_hypercall_on_cpu( return 0; } +domid_t get_initial_domain_id(void) +{ +#ifdef CONFIG_X86 + return pv_shim_initial_domain_id(); +#else + return 0; +#endif +} + /* * Local variables: * mode: C diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h index 3de56352911347a54cce310f0211bcc213d8a08d..601ef431cf621af44c867400499b73b845eb137a 100644 --- a/xen/include/xen/domain.h +++ b/xen/include/xen/domain.h @@ -171,4 +171,6 @@ extern bool vmtrace_available; extern bool vpmu_is_available; +domid_t get_initial_domain_id(void); + #endif /* __XEN_DOMAIN_H__ */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:41:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:41:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849423.1264134 (Exim 4.92) (envelope-from ) id 1tJQA8-0007m1-9D; Fri, 06 Dec 2024 04:41:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849423.1264134; Fri, 06 Dec 2024 04:41:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJQA7-0007hl-GP; Fri, 06 Dec 2024 04:41:55 +0000 Received: by outflank-mailman (input) for mailman id 849423; Fri, 06 Dec 2024 04:41: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 1tJQA0-0004Ka-Mb for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:48 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 631ce79d-b38c-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:41:42 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id B68855C7311; Fri, 6 Dec 2024 04:40:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 51702C4CEE1; Fri, 6 Dec 2024 04:41:38 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 469A7E77171; Fri, 6 Dec 2024 04:41:38 +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: 631ce79d-b38c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460098; bh=owjhPqMN/sfHwDFdAwELQ23W67gacGzY3DCmgAbUG18=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=DLTBKB4oxMWdcE1LnVcKmfZjfrKJIOFEgEJ1YU6TUpJ3qeYzBimAOcHSF5Y0zuJk3 cvauLBWrtXW/9TNGZwEg8SHr14QqSa1+q+jRj6tt4Gexg+KYBDCYxxnuvsRCi54Nm3 MNKzuFfuXxm57lkeHvO72G3bm8U6dD5vh3n3klUHX/2R913vGc/KkcC6Z8JMiLveQr hflxbWwGj9pwzj3JZhpxZNFh2Nw30U2zleCYzIatOYhuN8D5Ux+qKwJPJeiAWawYiG cR3ux1HHjGZBMVbYyukJS1P44BHpt1Y/yobwsJx9+MGA573+zrf0FRX5L+gfc3GTYH AgjQzBjBJzH6Q== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:45 -0800 Subject: [PATCH v2 15/35] xen/console: rename console_rx to console_owner MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-15-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=3503; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=adx3ttDq9DGxs5v/iNqFG/t0SkuLKBWjA23PcHLO1+c=; b=U0p0Hzrt1FgB0xBL5A9gFP0Y7Mk23wTztAC/UqxMEAxRrYxGJSk3Xqom8dczkyZN2c2Nxokon RNRJP3sESjoB+bT52kOM2zEVS1JjKi7wpMFA62krW9kIMHww0XCdO41 X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Preparation for the follow on change to switch console_owner to domid_t address space. Signed-off-by: Denis Mukhin --- xen/drivers/char/console.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index f8a7db385c9525cabc69ceb1a84d73f57863aa45..86bf899ada8f8221ffc77bcffb1f58777a22198e 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -467,11 +467,11 @@ static void cf_check dump_console_ring_key(unsigned char key) */ #define switch_code (opt_conswitch[0]-'a'+1) /* - * console_rx=0 => input to xen - * console_rx=1 => input to dom0 (or the sole shim domain) - * console_rx=N => input to dom(N-1) + * console_owner=0 => input to xen + * console_owner=1 => input to dom0 (or the sole shim domain) + * console_owner=N => input to dom(N-1) */ -static unsigned int __read_mostly console_rx = 0; +static unsigned int __read_mostly console_owner = 0; #define max_console_rx (max_init_domid + 1) @@ -479,15 +479,15 @@ static unsigned int __read_mostly console_rx = 0; /* Make sure to rcu_unlock_domain after use */ struct domain *rcu_lock_domain_console_owner(void) { - if ( console_rx == 0 ) + if ( console_owner == 0 ) return NULL; - return rcu_lock_domain_by_id(console_rx - 1); + return rcu_lock_domain_by_id(console_owner - 1); } #endif static void console_find_owner(void) { - unsigned int next_rx = console_rx; + unsigned int next_rx = console_owner; /* * Rotate among Xen, dom0 and boot-time created domUs while skipping @@ -500,7 +500,7 @@ static void console_find_owner(void) if ( next_rx++ >= max_console_rx ) { - console_rx = 0; + console_owner = 0; printk("*** Serial input to Xen"); break; } @@ -515,7 +515,7 @@ static void console_find_owner(void) if ( d ) { rcu_unlock_domain(d); - console_rx = next_rx; + console_owner = next_rx; printk("*** Serial input to DOM%u", domid); break; } @@ -529,7 +529,7 @@ static void console_find_owner(void) static void __serial_rx(char c) { - switch ( console_rx ) + switch ( console_owner ) { case 0: return handle_keypress(c, false); @@ -552,7 +552,7 @@ static void __serial_rx(char c) #ifdef CONFIG_SBSA_VUART_CONSOLE default: { - struct domain *d = rcu_lock_domain_by_id(console_rx - 1); + struct domain *d = rcu_lock_domain_by_id(console_owner - 1); /* * If we have a properly initialized vpl011 console for the @@ -563,7 +563,7 @@ static void __serial_rx(char c) vpl011_rx_char_xen(d, c); else printk("Cannot send chars to Dom%d: no UART available\n", - console_rx - 1); + console_owner - 1); if ( d != NULL ) rcu_unlock_domain(d); @@ -1116,7 +1116,7 @@ void __init console_endboot(void) * a useful 'how to switch' message. */ if ( opt_conswitch[1] == 'x' ) - console_rx = max_console_rx; + console_owner = max_console_rx; register_keyhandler('w', dump_console_ring_key, "synchronously dump console ring buffer (dmesg)", 0); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:41:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:41:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849425.1264143 (Exim 4.92) (envelope-from ) id 1tJQA9-00083J-Qd; Fri, 06 Dec 2024 04:41:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849425.1264143; Fri, 06 Dec 2024 04:41:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJQA8-0007z2-R4; Fri, 06 Dec 2024 04:41:56 +0000 Received: by outflank-mailman (input) for mailman id 849425; Fri, 06 Dec 2024 04:41: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 1tJQA1-0004Kb-07 for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:49 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 630748e6-b38c-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 05:41:41 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 9F06E5C730D; Fri, 6 Dec 2024 04:40:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 3FE89C4CEE4; Fri, 6 Dec 2024 04:41:38 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3203AE77175; Fri, 6 Dec 2024 04:41:38 +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: 630748e6-b38c-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460098; bh=Cap5cSdXQnJhIWZIJycGmw66XTO7q8HjNlh67Jy7JB4=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=slEVXgrcxRMdts8sPlpZiuEnq6nMd1CJXo5dkrY+iH95kxfsnlS15QRK3taaMDw/s dPCF6+DfrrCLhxwuD3D6XopmRXmgdFB/iSP+TzFCBg/sedGESnVGWnRASO5Fso76EK NaSmqdwiVn9s2mRCzADjsbRv80BHc4iZOWzINZfusKq7300RwgQ1Zfs7+THoMEVH4P ZRd8LzFIdF59o69nF+1xazOq9dTsU8h6fUQWzOUi3rwun1X+sutRdo6TD2lWqVUHw6 Dt7Z0eHhaqMvCRyxJ3+rENlf7l3fqcrkeFnYH/8wEXAjcLZT7BjIEydTOwZgDfSl+W MElWGA+tKeDFQ== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:44 -0800 Subject: [PATCH v2 14/35] xen/console: rename switch_serial_input() to console_find_owner() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-14-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=1478; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=kkv+AJB+iT69SEANPtdQ4jOx6o8Fe+p28DiGHObsMCE=; b=gRXgx+DD5GIcVMPVQK7C1jj92QDW/kIDm/IOc/pZCgabGTEox1asRi6IgoPghVmZ7TWS8niFN n4qeqreO2lEBoEOFAlckvn2W2tk/QOfgi/PUKW8+0xqTiyq+lSP5ZG8 X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Updated the name to highlight the logic of selection the physical console owner: existing code does not switch only serial console, it also switches video console and debugging console (debug I/O port and console hypercall). Signed-off-by: Denis Mukhin --- xen/drivers/char/console.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 01fcbd5581d11f8f4f2b23592255b5c744430a3e..f8a7db385c9525cabc69ceb1a84d73f57863aa45 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -485,7 +485,7 @@ struct domain *rcu_lock_domain_console_owner(void) } #endif -static void switch_serial_input(void) +static void console_find_owner(void) { unsigned int next_rx = console_rx; @@ -588,7 +588,7 @@ static void cf_check serial_rx(char c) /* We eat CTRL- in groups of 3 to switch console input. */ if ( ++switch_code_count == 3 ) { - switch_serial_input(); + console_find_owner(); switch_code_count = 0; } return; @@ -1128,7 +1128,7 @@ void __init console_endboot(void) "toggle host/guest log level adjustment", 0); /* Serial input is directed to DOM0 by default. */ - switch_serial_input(); + console_find_owner(); } int __init console_has(const char *device) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:42:00 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:42:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849426.1264150 (Exim 4.92) (envelope-from ) id 1tJQAB-0008Oa-OF; Fri, 06 Dec 2024 04:41:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849426.1264150; Fri, 06 Dec 2024 04:41: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 1tJQAA-0008LS-Jx; Fri, 06 Dec 2024 04:41:58 +0000 Received: by outflank-mailman (input) for mailman id 849426; Fri, 06 Dec 2024 04:41: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 1tJQA1-0004Ka-Mg for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:49 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 634e9c37-b38c-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:41:42 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id E84FD5C7316; Fri, 6 Dec 2024 04:40:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 88145C4CED1; Fri, 6 Dec 2024 04:41:38 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7E850E77171; Fri, 6 Dec 2024 04:41:38 +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: 634e9c37-b38c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460098; bh=1+CfSEkR8zxLHnRjqs6FthJiLe4CA0nTnQb0fq6KDB8=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=mOcVJpk4N5JHbTIyQQM8RLgj5RcdtbYqIFONH8W+JhIioNg9ggVz6vQn60b1I24H+ zJQzrY1JeyR8kb7iDNydGZZZyXM0zrZo4Z/v7FCa/YLOtHLtmN+74nG6wgrsLKZoKL YOWUr/TWWSxcLbTCoE/zctSUS+zkxY8bQ1bGEkGNwfdPKVnaZsukpxcd5+RBRUJJ+G G6eTtn/+DTVdbxcMbhcAz28RcFptGq/kgILDn+UleKb5teBht70HcGRbKTrzZyHEv2 y1tGL2n/9Gzv0kzSHHUVNIVEfiK1ZcOqTXr6VYEWlLgZO3MDLyFj+iseYCtMHwql6I xIkYJL4STxTQw== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:48 -0800 Subject: [PATCH v2 18/35] xen/console: introduce use of 'is_console' flag MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-18-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=4575; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=c1qncLIbvdXkIva3csVS48o24QoMrU3zNKu5KbZwS0s=; b=WG1ksIYw4EgMLqSvIv9tHZhu+lH3WcqfWVayi+nfHijfuS+xnIvMui9g5p5iudJvKLVyMnVUq PSoDBtHWfQ7CsaFONJoLb62ddxjajRWzEKEVzmeJCrzkAq7eNAreWBp X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin The code now inspects d->is_console flag to decide whether the console focus should move to the domain w/ console after administrator presses . Console owner domain switch logic updated accordingly. Signed-off-by: Denis Mukhin --- xen/arch/arm/dom0less-build.c | 2 +- xen/arch/arm/domain.c | 1 + xen/arch/arm/domctl.c | 1 + xen/arch/x86/pv/shim.c | 2 ++ xen/common/domain.c | 2 ++ xen/drivers/char/console.c | 14 ++++++++++---- 6 files changed, 17 insertions(+), 5 deletions(-) diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index de64ee930fdfe9a1c2842761275641485f69f675..32b5e8e16a28ae9a4951c8b7815638e69b66406a 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -833,6 +833,7 @@ static int __init construct_domU(struct domain *d, return rc; d->arch.emulation_flags |= ARM_EMU_VUART; + d->is_console = true; } rc = prepare_dtb_domU(d, &kinfo); @@ -1015,7 +1016,6 @@ void __init create_domUs(void) panic("Error creating domain %s (rc = %ld)\n", dt_node_name(node), PTR_ERR(d)); - d->is_console = true; dt_device_set_used_by(node, d->domain_id); rc = construct_domU(d, node); diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 02f9d59b38b4b7f6f73d97c421c9948c90e681d5..c52d6e932a9a71b620ecefacc1e884338858e3ea 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -781,6 +781,7 @@ int arch_domain_create(struct domain *d, goto fail; d->arch.emulation_flags |= ARM_EMU_VUART; + d->is_console = true; } if ( (rc = domain_vpci_init(d)) != 0 ) diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c index f80d34bf5f3d323a15db7f032073be52ea1009ae..81b5caf17c4e0badb2eefa90b1522c107f844d06 100644 --- a/xen/arch/arm/domctl.c +++ b/xen/arch/arm/domctl.c @@ -46,6 +46,7 @@ static int handle_vuart_init(struct domain *d, { vuart_op->evtchn = info.evtchn; d->arch.emulation_flags |= ARM_EMU_VUART; + d->is_console = true; } return rc; diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c index 17cb30620290c76cf42251f70cfa4199c0e165d1..a55c1d2a1e616f8979677a198eb9caabc3afc6bf 100644 --- a/xen/arch/x86/pv/shim.c +++ b/xen/arch/x86/pv/shim.c @@ -238,6 +238,8 @@ void __init pv_shim_setup_dom(struct domain *d, l4_pgentry_t *l4start, * guest from depleting the shim memory pool. */ d->max_pages = domain_tot_pages(d); + + d->is_console = true; } static void write_start_info(struct domain *d) diff --git a/xen/common/domain.c b/xen/common/domain.c index 9e57dd4122a726e2fb42efe9c029e775202be0e6..aab546c0a8535e4f007cbbc9c5c552bcf66b5807 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -682,6 +682,8 @@ struct domain *domain_create(domid_t domid, old_hwdom = hardware_domain; hardware_domain = d; + + d->is_console = true; } TRACE_TIME(TRC_DOM0_DOM_ADD, d->domain_id); diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 60c055396b697869b04b9132b0dcfa832fabe932..8cbac54c66044ae8581e486a782102b75c8bfaa9 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -1,8 +1,8 @@ /****************************************************************************** * console.c - * + * * Emergency console I/O for Xen and the domain-0 guest OS. - * + * * Copyright (c) 2002-2004, K A Fraser. * * Added printf_ratelimit @@ -509,14 +509,20 @@ static void console_find_owner(void) domid = get_initial_domain_id(); else domid = next_rx - 1; + d = rcu_lock_domain_by_id(domid); - if ( d ) + if ( d == NULL ) + continue; + + if ( d->is_console ) { rcu_unlock_domain(d); console_owner = next_rx; printk("*** Serial input to DOM%u", domid); break; } + + rcu_unlock_domain(d); } if ( switch_code ) @@ -814,7 +820,7 @@ static int printk_prefix_check(char *p, char **pp) return ((atomic_read(&print_everything) != 0) || (loglvl < lower_thresh) || ((loglvl < upper_thresh) && printk_ratelimit())); -} +} static int cf_check parse_console_timestamps(const char *s) { -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:42:02 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:42:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849427.1264161 (Exim 4.92) (envelope-from ) id 1tJQAE-0000Nf-0h; Fri, 06 Dec 2024 04:42:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849427.1264161; Fri, 06 Dec 2024 04:42:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJQAC-0000FC-G9; Fri, 06 Dec 2024 04:42:00 +0000 Received: by outflank-mailman (input) for mailman id 849427; Fri, 06 Dec 2024 04:41: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 1tJQA2-0004Kb-0D for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:50 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 631bd654-b38c-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 05:41:42 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id A45025C730F; Fri, 6 Dec 2024 04:40:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 29627C4CED2; Fri, 6 Dec 2024 04:41:38 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1D715E77171; Fri, 6 Dec 2024 04:41:38 +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: 631bd654-b38c-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460098; bh=ta4eTkD9D4OUBDs5UKjXmM1SaNyKboC1ozVSiJGJ9fk=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=BDbPVXF39OLBkCaf44ChkLhfEnQh5AA+aAdEPGz42TrorphDQ5B9IysAgtboJ8JpO LarM+rfzESVampW03fvqLyj2Q7M81cs7XOohi+JDio2oKLKApsINaz/ymZOjFR2D9h NHF/6csdv/BH73wIOyXxxkQglBOdBJY+UekbpuouGyNilrPqmDk003hjOAciPjm1sq jKKfbPdpjsg8m1r+fl1MXQQglbTfw4GVB7rWEpj5AZ4HFAyUU2WdJYULjiynVXgInB 0oNwIyaC8YV2YHIqvnHs7V+xoFmIUG/zdGmoNyZkAp1LBxnP58CVJsT5+RByVr3bCe AKGQGvCv5u1NA== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:43 -0800 Subject: [PATCH v2 13/35] xen/console: rename console_input_domain MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-13-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=2162; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=TjvkwSY30h8BpopVytXRbdfBD9IC9WbY4nf7jp2MPFs=; b=zeaE1xdzcz1rmGEWkbbULiMYNpdF8vIKM2kxIXRGbDkvs9GB3XLoGOpOKjhPDnOFynaL6G94y BDNF2sVTre6A39d5KuhX2puYeT9E2Bn+u1uXzBcSjf+s9GgIpAmb6ZQ X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin console_input_domain() takes an RCU lock to protect domain structure. That implies call to rcu_unlock_domain() after use. Rename console_input_domain() to rcu_lock_domain_console_owner() to highlight the need of calling rcu_unlock_domain(). Signed-off-by: Denis Mukhin --- xen/arch/arm/vpl011.c | 2 +- xen/drivers/char/console.c | 2 +- xen/include/xen/console.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c index fe36fe2bd1529a4114884580ded6d6fa55a22f0e..4d682e98553303b4a12f5cd7e5e67ab096cd7cc2 100644 --- a/xen/arch/arm/vpl011.c +++ b/xen/arch/arm/vpl011.c @@ -78,7 +78,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data) unsigned long flags; struct vpl011 *vpl011 = &d->arch.vpl011; struct vpl011_xen_backend *intf = vpl011->backend.xen; - struct domain *input = console_input_domain(); + struct domain *input = rcu_lock_domain_console_owner(); VPL011_LOCK(d, flags); diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 0af4b551801356f242f1770b3826608136d65653..01fcbd5581d11f8f4f2b23592255b5c744430a3e 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -477,7 +477,7 @@ static unsigned int __read_mostly console_rx = 0; #ifdef CONFIG_SBSA_VUART_CONSOLE /* Make sure to rcu_unlock_domain after use */ -struct domain *console_input_domain(void) +struct domain *rcu_lock_domain_console_owner(void) { if ( console_rx == 0 ) return NULL; diff --git a/xen/include/xen/console.h b/xen/include/xen/console.h index 6dfbade3ece36352c74f1124305da945b210f2a7..0e211e44d9703c804e18f52c9743916f8d2a9d4e 100644 --- a/xen/include/xen/console.h +++ b/xen/include/xen/console.h @@ -31,7 +31,7 @@ void console_end_sync(void); void console_start_log_everything(void); void console_end_log_everything(void); -struct domain *console_input_domain(void); +struct domain *rcu_lock_domain_console_owner(void); /* * Steal output from the console. Returns +ve identifier, else -ve error. -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:46:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:46:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849508.1264194 (Exim 4.92) (envelope-from ) id 1tJQEU-0006cr-U2; Fri, 06 Dec 2024 04:46:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849508.1264194; Fri, 06 Dec 2024 04:46: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 1tJQEU-0006ch-Qz; Fri, 06 Dec 2024 04:46:26 +0000 Received: by outflank-mailman (input) for mailman id 849508; Fri, 06 Dec 2024 04:46: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 1tJQET-0006c5-3S for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:46:25 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2062b.outbound.protection.outlook.com [2a01:111:f403:2613::62b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0b93481b-b38d-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:46:24 +0100 (CET) Received: from GV1PR03MB10456.eurprd03.prod.outlook.com (2603:10a6:150:16a::21) by PAWPR03MB10089.eurprd03.prod.outlook.com (2603:10a6:102:360::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.12; Fri, 6 Dec 2024 04:46:21 +0000 Received: from GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e%7]) with mapi id 15.20.8230.010; Fri, 6 Dec 2024 04:46:20 +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: 0b93481b-b38d-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=x0cYZIvQxLnLemZYK/oAL6OC9LGc1tHdfXG1NYNM++ASnYi87ECLuXQ0/DawSgqRZ9CQ+7KgtRPvm+1Y4Gglw5bjWmir+9K4i8HRn6YOz+fWblB7y8LrKYDVVkMSnDdRYN9KHq7I/iXPDU7EeUPt1WbTE9vcF3s7M25UMPWNbKrRGvtOz1cjRz/nNViYOlEEbV2F/LGHYgJeMkHmQYurR+g4soVtNhhIJFi3JtV9/m1f/oNP0H1JTSM+SyE1il5KJ9OFNvSu+hThMjG4REGP4pVoUZQvcF3RZXY8YyPsEi8T5hK09xYmdJVhA2T5+9T9CMLH444+xtQ919NghW31Bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EhlqcASNy3eMPF02NdURzocj0TYfge7ov9uhgp3WDrY=; b=MyVGXVXzd/AvVXLx+iHYcP3GU+R0mBZ456Y6rnoEdAVq0T6mSCen9qjW6U94A0Qun3QQb19XSLeVUbzWbvqUVJ5w7O6irQB/9VIzxbWRw8oVkFn3yK2DExiYWSrn0lug5TSH3jGrR9e5KGwpkRHajJyh4IkyK19V018BahLhIvJM1XQcFtb4JaDslSEJXRfM4WdlGLvci/e1opZ1kIczJSRt0mIdnL8UH/btzP4BCHmMIBQr4V5Yj4ggQzRz22HdXl7Gm+xojLJgtRHbBJoZ1/3Urcz9dD9+BYEQbtNpv58cOqeS7ZK6PcwJnHi65xjqtJ+Y8Bcsbm9oZ3WZCZI4ww== 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=EhlqcASNy3eMPF02NdURzocj0TYfge7ov9uhgp3WDrY=; b=kqhIFtD90yuxjMFduSCqO7d6PNJY0LsdE1lEQtdBXYxVxq+JDPON8bp70ILLzWCucgl+1xpS3rLczQJm+tUAG9XkW4b8kRGSg7shVca3qu7N0KZXI0QmbUkqxW3LBQZ2UQnS+WGT6OilipPjZlM1LrjRYTPlXJgnDH73kRGGn3ceQa+1RvpMqnIv6SmyNb8nV2mVzigPLdxh5VuiR8z7k7EWRMQLRr/kNEuOL0ExQMGMKBFPcWjqY8Bj+bkxgc885CG6+p/i8IPJQFWSX4JHvl/bEP8IVpWb6Mo/ksEySPCvaMUKKZoLj5xJG3+lcs/eg27fIgZfuE5kmHjEVHSLXA== From: Volodymyr Babchuk To: Andrew Cooper CC: Julien Grall , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Bertrand Marquis , Michal Orzel Subject: Re: [PATCH v2 3/4] xen: arm: enable stack protector feature Thread-Topic: [PATCH v2 3/4] xen: arm: enable stack protector feature Thread-Index: AQHbQsSdZeSazgkTckCfCx9gDu8jUA== Date: Fri, 6 Dec 2024 04:46:20 +0000 Message-ID: <87a5d94dwk.fsf@epam.com> References: <20241130010954.36057-1-volodymyr_babchuk@epam.com> <20241130010954.36057-4-volodymyr_babchuk@epam.com> <79bb69b0-b00d-4e3c-966e-a341eac59499@citrix.com> In-Reply-To: <79bb69b0-b00d-4e3c-966e-a341eac59499@citrix.com> (Andrew Cooper's message of "Thu, 5 Dec 2024 19:23:48 +0000") 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: GV1PR03MB10456:EE_|PAWPR03MB10089:EE_ x-ms-office365-filtering-correlation-id: c9a77fb4-d341-461a-e74f-08dd15b0edcc x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018; x-microsoft-antispam-message-info: =?utf-8?B?Z2xPSTRIQ0JOSDRzMGlsc25xNHhvMXJnK3k3RVYrU0hZYVpsQmVRcXJaNFE2?= =?utf-8?B?TnJocGNTbWJtT1pZVUlGOFFyKzBJb1hKVHllWDVKTXBtWVdUZ2t2NWhrUmNT?= =?utf-8?B?M3hVS2NZbUVCVUFSbGxWMFREUC9peTQydjF1MitBWGY1M3o5Y1kwOUhvcEU1?= =?utf-8?B?dklZZDBJVVpTUndUUFQzd1ozN3A5d0ZNZk5wSjFtNDZURCtRTGwwVVo3RTVt?= =?utf-8?B?dHl6YTh1RXc4U2ZJWE51dUlaNGw3bWw1ODd1YmZPUE12Z3l5NURDcC9KWlFl?= =?utf-8?B?Z2tCZ3NlbUxBeHd4U2N1U1RDYzZmeTNDR2RBTlV4d3pseFNRMytFSXp5SU1J?= =?utf-8?B?WlVUSURKSXBqb1JFek5yMXp1NThJNWpmSXI2aFJBZ2t2Y1FHTS82SVhPemY0?= =?utf-8?B?UGRDR3NYK3V3d3FTd2RraVc0THlyaEkxQThqZ0xmbkFibjdaMlpON1B3TXFm?= =?utf-8?B?UWtPLzFuT3pocUpLbk9ZMXlrSmZSeU5EOVhXVmNiMzZuTXk4YVVjV2x2bmdT?= =?utf-8?B?NXlqenRYSDFFVmdUVzBFMmdWUXBvVWpXSkFLZVIyRkVRQVA2V2NLNFIyUmVE?= =?utf-8?B?YUZKNGZ3U1dDRFFqK0FsclpyWGQxRW40b3BKamlWZUtFVWkyRGRLeEN3VDh6?= =?utf-8?B?MVNnWEs3c204YzBqMW96aWwxT0ozS2J0UFZrZksrVjRJcnVaU3RmK1QyMmRr?= =?utf-8?B?QTBxL3FGYmhWS3h3ZnNuU3dTdGZ6dFUxMkxHaFVFcGFQeFBtV0hsSHdlK1A5?= =?utf-8?B?byt6bWV1cFZ5dGlvcUdwT2c2eCtEUlJub2M2ekNyU0xxbUg4KzFEV1lJWWdY?= =?utf-8?B?M3lpYUZFcE1idDQ0d1E4QWFsZjNRRWFFeDVob09tTFVZRTNVb2JNdnBMeGR2?= =?utf-8?B?OEJxVy8zbXEzT3N1bWhqZEpyV01EWkkyaXZIOGdpam1xVWpsL3EzT3dsRFFR?= =?utf-8?B?ZGxJOTJsaUFvZ2pDRCtzRmxwVnB3eThzSFlxU2dkWEc4VjVhcDlKWFVybno0?= =?utf-8?B?Z2JRcTlaQytOU2ZOR1lzUUMyVW8vdzJjVWpweVU2aTdPcjVVREtIRENiUWdC?= =?utf-8?B?bE1MWjBmazhUSWRRVUxhRjRISWhaVDlEUGUvQURoVGFkOVl3OEJzcm52OCtP?= =?utf-8?B?RGphLytlVEp1TmM1QWQxMlFvREFkcjlVS1JOWjM0UncxRDBPQ0VwWVMrR3Mx?= =?utf-8?B?VVpGVnFMMTNpQlEyc1lZOFV2OVB2SW9CZy83NDVRTE1KeUNVUC9Dc0FaTkV4?= =?utf-8?B?TnAvb0wzQ1ZsbnhzR053NkZVUExTUzRXSWV3RHBWUDVBSnpqNldGeS83ZlhR?= =?utf-8?B?ZXFUeHVydWRPNCt3Wk9qeWVJZTA1NnMxQXVnSFNSN3ZDV0xtU1dDNngxTzNK?= =?utf-8?B?QndoTUlPbmtVRWkxUENGbmJOR2wzYUZWZ1RiRHJlZ1RrUWp5Qk9wRmZPbHd1?= =?utf-8?B?bVcyYVorOU5RVEgwTGFzYjlXQmlnM1g0UHlUN0ZRTnVtRjJhVzNuYnRVYmk2?= =?utf-8?B?bStYSTVvaXFmMndaV0FxWndUdTJCL1h3aDFLNXlSTDQ2WlRIQ0hmalRMYTNB?= =?utf-8?B?dHNqR1RUSDRSb0ZHWUNmeS9yV2kvOHQrRGo2WEtEenM5K1p1amNjTHBzZW43?= =?utf-8?B?d1JVeS9ybFFNd1krT2dCaFR3MzIySEtCUGJuTkpMV2VpWFNXL3QvRzR1T1VQ?= =?utf-8?B?WTNhVGVJUXhKUWxxNnpZY2ZrdWU5UjBnQThwWDBleFFObWQ2bG1mTC9tWUtl?= =?utf-8?B?dzBkeFZveUxDMkY5eXhkSzJOWnROZUhBMUlFUFdtTlhYZWJiWjdhR2dTU0lV?= =?utf-8?B?b2ZqTlMwQzhOai9La29pUzJGcHYxWDY0cC9SSnBaR0Exdy83aVNOS2l3dHk5?= =?utf-8?B?UktFaXRhN0owb25LMzZkdkxURTdNeXd4UnVnUldiUnVLL1E9PQ==?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Qzl5ampvMy9uVjd1RUNIa1lsZ1NPOSt4NkNEUjI3SVZjTExaODlVVk4yZnlW?= =?utf-8?B?b096TmtENDkweGpvcjExazNEQTdXc2pyWWZ2MDQ4NHNkYk9uY2FBRnFyNERB?= =?utf-8?B?ekVpNVlCd1JhS2VDd25ZbmtpQmM0a0p2SUdmbzRIVUx2bk1URG9rek9nckxF?= =?utf-8?B?MWtPM1M2SUdORUhEZlpNRlF3Q3I4Wkp2VXFGUjZRNW1EZHBkR1dQOTNhTUg5?= =?utf-8?B?Q3cybmxzMHlzZCtMZ1QvRmROb3pKMFI1ZFhvSythN1kweXhJOTFOU25HeC9W?= =?utf-8?B?cmNMLzBlRlR2VDZpU3ZPUEsxZ1FSMklOQ1pNWllZSzVUTmxJczBRR2xaVWsw?= =?utf-8?B?K2VzM0E1NmwrY2RHanc3REFPKyswNTVlV3Erajh2Y1hwWDIrdVJNeGV5blEy?= =?utf-8?B?cDF5dG5XSHFqYi85dmZ3L1hoczFCT1FaUENSZ1NqMnR3N2NBQmJ5NVJKK0hV?= =?utf-8?B?MThJUEh2cXl5K2ZYQ2ZwaVdpa0JrbzhueHVMcVJhcThuU20rTWQveDhPbXJZ?= =?utf-8?B?RGZMbXZsVDFnR2I4L3RtRi8zcTg4amhiSUpsQkpUbWRqTU9WdnRZd0owck9k?= =?utf-8?B?Qkw0NlpwUkJWdDZTbE5URlhXVElQTjBXYXpPQUhwaWpXc3lMZmZJV01ieGdR?= =?utf-8?B?S2ljdVJDT0Mrd0o0OUl3U3BBdC8zck9GcVlHYmN3SU13NHdjdkNqNlZzREFS?= =?utf-8?B?aEJZTUFFZ2laRjFxemIzNTd2ZTRHRldNZTNseU9VSFhsSnV2dUl5TTdwSk55?= =?utf-8?B?c3RpV2xCbVREUVpJZ21vMFY1Mi9JVGp2NFBkeDlIbFh3YlZsSENvY3o5MTl0?= =?utf-8?B?OXRqWEt2MzA4NE1Ud3ZQSEtDbDlwNjdDWkh3T2VKY2V2eTFmZXJZWmdLVTMx?= =?utf-8?B?ZzdObWdiWkwzd2VRb2tKQUFBOGowR3ZzaFJWWnM4Zk1CM1dBUjhYZ1Y2MmRN?= =?utf-8?B?YmZyTVZlckc5dFFkWG1HUGVZeVluMUxMU0VHNkIzYkNWN3VNdWdLdEEvMDRV?= =?utf-8?B?d1JhR2JsWTkrT29IT1IxckRMbGdicVVxYnpMWkJ5MXFYRlRmNXJ5ZlBsL2hE?= =?utf-8?B?Yncxd3kzOHUyK1N5cVNiNll1ZnNFVk5ndWh4VU9aeVVuanNQTmFkTmxvRXZU?= =?utf-8?B?TlRjb2FhbzBnQkZVNmhUOHhMRU0rbjNvU2g2VHk4TjcvU3JCQ3VaOEQxSnlz?= =?utf-8?B?a2VaYTU4cHAvR3BxTGM0L3BlNEZRL3FJU1Erc0dLNWJxTEhzQzNCVmxzakJD?= =?utf-8?B?bDFETktiOWhISTM4aVNnV3cwdnE5UGdzSDk2aFpuc051VEFJbVdVQXhlak5H?= =?utf-8?B?b0F6MjkwMHp4RFlnYWh5eHh2K3BsNG1JWmhSaWp0dnZTS3Y2ZUdrRjUvZ0tJ?= =?utf-8?B?RUhjaUp5WlZHSWFKa055YVhFeFZQajllTUVUY2JycjdiMSt0OUpOSU5DbGxy?= =?utf-8?B?NjdwWGNaU0VYdmgwbU41UkRwMTFtYWplUHZieWh4dlZzcWEzbTk4ZEFNb0cr?= =?utf-8?B?SjJFZ1JDZW9tQm11c1RKZnFrWmFEcTY2YWc0R2hxVVpqdzdMR25NbDIrNFJk?= =?utf-8?B?b2F4VVo3TGxZZ2FhM2dXWSsxUkQvKzduT0xSMG9BZVNMN2Y3Z0hnOHY3SHo2?= =?utf-8?B?ejRDVFJXKy8xQ0NGSkNsaEV2SSt0dGtGRFFWTmpGZzBXblFhWkZmMTllL3VW?= =?utf-8?B?N1BTMDNVcXVtWGI1L0FTQWNRN1Q4RHBSZGNDdVcxSzhQWGdwOVRiVExtclFL?= =?utf-8?B?R3RERnVnS3Y1QVJiUEEvUlVLaUg5RjNheGxZYVd5QmQ0ajdPbVJmS0RMK0tI?= =?utf-8?B?RnVWSXhZd3BFOUwwL2FUak51OTJhd3JkV1dSd0JuYU91WVZYRHp4RDlxSlc4?= =?utf-8?B?aER4RzIyV1NseUZOL3FBa29JYkpNQmlOMzBYVUxKdFRDTjYwV3R6QjY3UUk3?= =?utf-8?B?aHYyckp4UytTRkd5TDVQUE1IcFc1VysvRzl2ZlVvNXBVMk5GN0t3WFdRZGo4?= =?utf-8?B?RGZRRmxkYUhwL0kxcnFRMCtGQTlmanFFTG9lU1VZUWxHTGFrSll5NXVEM3hV?= =?utf-8?B?VXQxQmtvUzZBUTM4TVRMMkNLbEo5MyszcTZTQVJ1SW84WTRxL2hsc3kwTjZ0?= =?utf-8?B?SXFFTXhWZStPdG9XSGYvMlNObk9rS0xZWlhuYjdBTzJySUYydXh2REVKdXRa?= =?utf-8?B?MkE9PQ==?= Content-Type: text/plain; charset="utf-8" Content-ID: <80493A35FDC2F744981B36DD3CF658CA@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: GV1PR03MB10456.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c9a77fb4-d341-461a-e74f-08dd15b0edcc X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2024 04:46:20.4090 (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: 4/1sAHp3EoUrbgNVkN7h5k4X+ZJWQODzihVuqKGN46hYk6o2a+UR/4OVk/QJBgHe1JsodmTZwfNLoN/5xpvrV1k/P5aWvVC4NDa0ZwGFylQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR03MB10089 DQpIaSBBbmRyZXcsDQoNCkFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ IHdyaXRlczoNCg0KPiBPbiAwMy8xMi8yMDI0IDExOjE2IHBtLCBKdWxpZW4gR3JhbGwgd3JvdGU6 DQo+PiBPbiBUdWUsIDMgRGVjIDIwMjQgYXQgMjI6MDAsIEFuZHJldyBDb29wZXIgPGFuZHJldy5j b29wZXIzQGNpdHJpeC5jb20+IHdyb3RlOg0KPj4+IE9uIDMwLzExLzIwMjQgMToxMCBhbSwgVm9s b2R5bXlyIEJhYmNodWsgd3JvdGU6DQo+Pj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vc2V0 dXAuYyBiL3hlbi9hcmNoL2FybS9zZXR1cC5jDQo+Pj4+IGluZGV4IDJlMjdhZjQ1NjAuLmY4NTVl OTdlMjUgMTAwNjQ0DQo+Pj4+IC0tLSBhL3hlbi9hcmNoL2FybS9zZXR1cC5jDQo+Pj4+ICsrKyBi L3hlbi9hcmNoL2FybS9zZXR1cC5jDQo+Pj4+IEBAIC0zNDEsNiArMzQyLDggQEAgdm9pZCBhc21s aW5rYWdlIF9faW5pdCBzdGFydF94ZW4odW5zaWduZWQgbG9uZyBmZHRfcGFkZHIpDQo+Pj4+ICAg ICAgICovDQo+Pj4+ICAgICAgc3lzdGVtX3N0YXRlID0gU1lTX1NUQVRFX2Jvb3Q7DQo+Pj4+DQo+ Pj4+ICsgICAgYm9vdF9zdGFja19jaGtfZ3VhcmRfc2V0dXAoKTsNCj4+Pj4gKw0KPj4+PiAgICAg IGlmICggYWNwaV9kaXNhYmxlZCApDQo+Pj4+ICAgICAgew0KPj4+PiAgICAgICAgICBwcmludGso IkJvb3RpbmcgdXNpbmcgRGV2aWNlIFRyZWVcbiIpOw0KPj4+IEkgc3RpbGwgdGhpbmsgdGhhdCBf X3N0YWNrX2Noa19ndWFyZCB3YW50cyBzZXR0aW5nIHVwIGluIEFTTSBiZWZvcmUNCj4+PiBlbnRl cmluZyBDLg0KPj4+DQo+Pj4gVGhlIG9ubHkgcmVhc29uIHRoaXMgY2FsbCBpcyBzbyBsYXRlIGlz IGJlY2F1c2UgWGVuJ3MgZ2V0X3JhbmRvbSgpDQo+Pj4gc2VxdWVuY2UgaXMgbGVzcyB0aGFuIGhl bHBmdWwuICBUaGF0IHdhbnRzIHJld3JpdGluZyBzb21ld2hhdCwgYnV0IG1heWJlDQo+Pj4gbm93 IGlzbid0IHRoZSBiZXN0IHRpbWUuDQo+Pj4NCj4+PiBFdmVuIGlmIHlvdSBpbml0aWFsaXNlIF9f c3RhY2tfY2hrX2d1YXJkIGl0IHRvIC0xIHJhdGhlciB0aGFuIDAsIGl0J3MNCj4+PiBzdGlsbCBn b3QgYSBiZXR0ZXIgY2hhbmNlIG9mIGNhdGNoaW5nIGVycm9ycyBkdXJpbmcgdmVyeSBlYXJseSBi b290OyB0aGUNCj4+PiBpbnN0cnVtZW50YXRpb24gaXMgcHJlc2VudCwgYnV0IGlzIHVzaW5nIDAg YXMgdGhlIGNhbmFyeSB2YWx1ZS4NCj4+Pg0KPj4+IE9uIHg4NiwgZHVtcGluZyB0aGUgY3VycmVu dCBUU0MgdmFsdWUgaW50byBfX3N0YWNrX2Noa19ndWFyZCB3b3VsZCBiZQ0KPj4+IGZhciBiZXR0 ZXIgdGhhbiB1c2luZyAtMS4gIEV2ZW4gaWYgaXQgc2tld2VkIHRvIGEgbG93ZXIgbnVtYmVyLCBp dCdzDQo+Pj4gdW5wcmVkaWN0YWJsZSBhbmQgbm90IGdvaW5nIHRvIHJlb2NjdXIgYnkgYWNjaWRl bnQgZHVyaW5nIGEgc3RhY2sgb3ZlcnJ1bi4NCj4+Pg0KPj4+IFN1cmVseSBBUk0gaGFzIHNvbWV0 aGluZyBzaW1pbGFyIGl0IGNvdWxkIHVzZT8NCj4+IFRoZXJlIGlzIGEgb3B0aW9uYWwgc3lzdGVt IHJlZ2lzdGVyIHRvIHJlYWQgYSByYW5kb20gbnVtYmVyLg0KPg0KPiBPbmx5IGluIHY4LjUgYXMg ZmFyIGFzIEkgY2FuIHNlZSwgYW5kIGV2ZW4gdGhlbiBpdCdzIG5vdCByZXF1aXJlZC7CoA0KPiBB bHNvLCBpdCBzdWZmZXJzIGZyb20gdGhlIHNhbWUgcHJvYmxlbSBhcyBSRFJBTkQgb24geDg2OyB3 ZSBuZWVkIHRvIGJvb3QNCj4gdG8gYXQgbGVhc3QgZmVhdHVyZSBkZXRlY3Rpb24gYmVmb3JlIHdl IGNhbiBzYWZlbHkgdXNlIGl0IGlmIGl0J3MgYXZhaWxhYmxlLg0KPg0KPj4NCj4+PiBbZWRpdF0g WWVzLCBnZXRfY3ljbGVzKCksIHdoaWNoIGV2ZXJ5IGFyY2hpdGVjdHVyZSBzZWVtcyB0byBoYXZl LiAgSW4NCj4+PiBmYWN0LCBzd2FwcGluZyBnZXRfcmFuZG9tKCkgZnJvbSBOT1coKSB0byBnZXRf Y3ljbGVzKCkgd291bGQgYmUgZ29vZA0KPj4+IGVub3VnaCB0byBnZXQgaXQgdXNhYmxlIGZyb20g ZWFybHkgYXNzZW1ibHkuDQo+PiBOb3QgcXVpdGUuIFRlY2huaWNhbGx5IHdlIGNhbid0IHJlbHkg b24gdGhlIHRpbWVyIGNvdW50ZXIgdW50aWwNCj4+IHBsYXRmb3JtX2luaXRfdGltZSgpIGlzIGNh bGxlZC4NCj4+IFRoaXMgd2FzIHRvIGNhdGVyIGFuIGlzc3VlIG9uIHRoZSBleHlub3Mgd2UgdXNl ZCBpbiBPc3NUZXN0LiBCdXQNCj4+IGFyZ3VhYmx5IHRoaXMgaXMgdGhlIGV4Y2VwdGlvbg0KPj4g cmF0aGVyIHRoYW4gdGhlIG5vcm0gYmVjYXVzZSB0aGUgZmlybXdhcmUgb3VnaHQgdG8gcHJvcGVy bHkgaW5pdGlhbGl6ZQ0KPj4gdGhlIHRpbWVyLi4uDQo+Pg0KPj4gSSBoYXZlbid0IGNoZWNrZWQg cmVjZW50IGZpcm13YXJlLiBCdXQgSSBjb3VsZCBiZSBjb252aW5jZWQgdG8gYWNjZXNzDQo+PiB0 aGUgY291bnRlciBiZWZvcmUNCj4+IGhhbmQgaWYgd2UgcmVhbGx5IHRoaW5rIHRoYXQgc2V0dGlu ZyBfX3N0YWNrX2Noa19ndWFyZCBmcm9tIEFTTSBpcyBtdWNoIGJldHRlci4NCj4NCj4gVGhlIEMg aW5zdHJ1bWVudGF0aW9uIGlzIGFsd2F5cyBwcmVzZW50LCByaWdodCBmcm9tIHRoZSB2ZXJ5IHN0 YXJ0IG9mDQo+IHN0YXJ0X3hlbigpLg0KPg0KPiBFdmVuIHdvcmtpbmcgd2l0aCBhIGNhbmFyeSBv ZiAwLCB0aGVyZSdzIHNvbWUgdmFsdWUuwqAgSXQgd2lsbCBzcG90DQo+IGNsb2JiZXJpbmcgd2l0 aCBhIG5vbi16ZXJvIHZhbHVlLCBidXQgaXQgd29uJ3Qgc3BvdCBlLmcuIGFuIG92ZXJseS1sb25n DQo+IG1lbXNldCgsIDApLg0KPg0KPiBEdXJpbmcgYm9vdCwgd2UncmUgbm90IGRlZmVuZGluZyBh Z2FpbnN0IGEgbWFsaWNpb3VzIGVudGl0eS7CoCBTaW1wbHkNCj4gZGVmZW5kaW5nIGFnYWluc3Qg YmFkIGRldmVsb3BlciBleHBlY3RhdGlvbnMuDQo+DQo+IFRoZXJlZm9yZSwgYW55dGhpbmcgdG8g Z2V0IGEgbm9uLXplcm8gdmFsdWUgcHJpb3IgdG8gZW50ZXJpbmcgQyB3aWxsIGJlDQo+IGFuIGlt cHJvdmVtZW50LsKgIEJlc3QtZWZmb3J0IGlzIGZpbmUsIGFuZCBpZiB0aGVyZSdzIG9uZSBwbGF0 Zm9ybSB3aXRoDQo+IGFuIGVycmF0YSB0aGF0IGNhdXNlcyBpdCB0byBtaXNzIG91dCwgdGhlbiBv aCB3ZWxsLsKgIEFueSBvdGhlciBwbGF0Zm9ybQ0KPiB3aGljaCBtYW5pZmVzdHMgYSBjcmFzaCB3 aWxsIHN0aWxsIGxlYWQgdG8gdGhlIHByb2JsZW0gYmVpbmcgZml4ZWQuDQo+DQo+IEkgc3VwcG9z ZSB0YWtpbmcgdGhpcyBhcmd1bWVudCB0byBpdCdzIGxvZ2ljYWwgY29uY2x1c2lvbiwgd2UgY291 bGQNCj4gaW5pdGlhbGlzZSBfX3N0YWNrX2Noa19ndWFyZCB3aXRoIGEgcG9pc29uIHBhdHRlcm4s IGFsdGhvdWdoIG5vdCBvbmUNCj4gc2hhcmVkIGJ5IGFueSBvdGhlciBwb2lzb24gcGF0dGVybiBp biBYZW4uwqAgVGhhdCBhbG9uZSB3b3VsZCBiZSBiZXR0ZXINCj4gdGhhbiB1c2luZyAwIGluIGVh cmx5IGJvb3QuDQoNCk9rYXksIHNvIEkgY29tZSB3aXRoIHRocmVlLXN0YWdlIGluaXRpYWxpemF0 aW9uOg0KDQoxLiBTdGF0aWMgcG9pc29uIHBhdHRlcm4NCjIuIFRpbWUtYmFzZWQgZWFybHkgdmFs dWUNCjMuIFJhbmRvbS1udW1iZXIgYmFzZWQgbG9uZy10ZXJtIHZhbHVlDQoNClNvLCBhcGFydCBm cm9tIGFscmVhZHkgcHJlc2VudA0KDQpzdGF0aWMgYWx3YXlzX2lubGluZSB2b2lkIGJvb3Rfc3Rh Y2tfY2hrX2d1YXJkX3NldHVwKHZvaWQpOw0KDQpJIGRpZCB0aGlzOg0KDQovKg0KICogSW5pdGlh bCB2YWx1ZSBpcyBjaG9zZW4gYnkgZmFpciBkaWNlIHJvbGwuDQogKiBJdCB3aWxsIGJlIHVwZGF0 ZWQgZHVyaW5nIGJvb3QgcHJvY2Vzcy4NCiAqLw0KI2lmIEJJVFNfUEVSX0xPTkcgPT0gMzINCnVu c2lnbmVkIGxvbmcgX19yb19hZnRlcl9pbml0IF9fc3RhY2tfY2hrX2d1YXJkID0gMHhkZDJjYzky NzsNCiNlbHNlDQp1bnNpZ25lZCBsb25nIF9fcm9fYWZ0ZXJfaW5pdCBfX3N0YWNrX2Noa19ndWFy ZCA9IDB4MmQ4NTM2MDVhNGQ5YTA5YzsNCiNlbmRpZg0KDQovKiBUaGlzIGZ1bmN0aW9uIHNob3Vs ZCBiZSBjYWxsZWQgZnJvbSBBU00gb25seSAqLw0Kdm9pZCBfX2luaXQgYXNtbGlua2FnZSBib290 X3N0YWNrX2Noa19ndWFyZF9zZXR1cF9lYXJseSh2b2lkKQ0Kew0KICAgIC8qDQogICAgICogTGlu ZWFyIGNvbmdydWVudCBnZW5lcmF0b3IuIENvbnN0YW50IGlzIHRha2VuIGZyb20NCiAgICAgKiBU YWJsZXMgT2YgTGluZWFyIENvbmdydWVudGlhbCBHZW5lcmF0b3JzDQogICAgICogT2YgRGlmZmVy ZW50IFNpemVzIEFuZCBHb29kIExhdHRpY2UgU3RydWN0dXJlIGJ5IFBpZXJyZSBM4oCZRWN1eWVy DQogICAgICovDQojaWYgQklUU19QRVJfTE9ORyA9PSAzMg0KICAgIGNvbnN0IHVuc2lnbmVkIGxv bmcgYSA9IDI4OTEzMzY0NTM7DQojZWxzZQ0KICAgIGNvbnN0IHVuc2lnbmVkIGxvbmcgYSA9IDI4 NjI5MzM1NTU3Nzc5NDE3NTc7DQojZW5kaWYNCiAgICBjb25zdCB1bnNpZ25lZCBjID0gMTsNCiAg ICB1bnNpZ25lZCBsb25nIGN5Y2xlcyA9IGdldF9jeWNsZXMoKTsNCg0KICAgIGlmICggIWN5Y2xl cyApDQogICAgICAgIHJldHVybjsNCg0KICAgIF9fc3RhY2tfY2hrX2d1YXJkID0gY3ljbGVzICog YSArIGM7DQp9DQoNCmJvb3Rfc3RhY2tfY2hrX2d1YXJkX3NldHVwX2Vhcmx5KCkgaXMgYmVpbmcg Y2FsbGVkIGJ5IEFTTSBjb2RlIGR1cmluZw0KZWFybHkgYm9vdCBzdGFnZXMuDQoNClRoZW4sIGxh dGVyLCBib290X3N0YWNrX2Noa19ndWFyZF9zZXR1cCgpIGlzIGNhbGxlZC4NCg0KSWYgeW91IGFy ZSBva2F5IHdpdGggdGhpcyBhcHByb2FjaCwgSSdsbCBzZW5kIHRoZSBuZXh0IHZlcnNpb24uDQoN Ci0tIA0KV0JSLCBWb2xvZHlteXI= From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:50:31 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:50:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849541.1264205 (Exim 4.92) (envelope-from ) id 1tJQIN-0008Dq-H8; Fri, 06 Dec 2024 04:50:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849541.1264205; Fri, 06 Dec 2024 04:50: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 1tJQIN-0008Dj-EY; Fri, 06 Dec 2024 04:50:27 +0000 Received: by outflank-mailman (input) for mailman id 849541; Fri, 06 Dec 2024 04:50: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 1tJQA5-0004Kb-0S for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:53 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 647d7eaa-b38c-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 05:41:43 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id E48795C7334; Fri, 6 Dec 2024 04:40:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 8338AC4CEDE; Fri, 6 Dec 2024 04:41:39 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79E78E7717C; Fri, 6 Dec 2024 04:41: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: 647d7eaa-b38c-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460099; bh=5gdanZ5e9+ASbcswvlhUW99s0NYH3AklpGAHEKCJ1yA=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=l7F4swuxWLy7qWUlFubA5ZMzqX3UhKLqkhKI2ES3SfsXA7oVuy7mPcpmlOZK+Xc3t umwFJM4ukOQnfTR4JnynPnV9gDpo+kYhA76d7PnKd7Q9MOqDOFCjdu/R+hX/7scSWD 02cQ8Zx6irE4HWu+N4cq8Hsec+a9ICFctxj+iKhw7hFbLcQnQ8BC5TyUhj1gs2sSzX DX/l80YRZ6bgzT/qBVI5BOrEitV3dCQapg8+TYOXk520IMr3zMx7U3+EUBh/O3NUJ4 LI5F+P3jqqdf9SIH2mcGp0NKjy0b7baB/Kei8fCoCWR47lmyMz9lKwk43B1KUwx8Fx A14s8d/0EwjUA== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:42:04 -0800 Subject: [PATCH v2 34/35] xen/console: enable console owners w/ emulated NS8250 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-34-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460095; l=1133; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=m+DZYhBfJNv2KVuFKRvMQy0kCP3iadnxj6rLAihix3M=; b=RacSKnwM5fBYuU8iskMZVZ/uehW76whDkeSjA2tP9mNGpXECzUNwGvJga6wsGA/b5LOBbFu5w EWu5DcHxADFDmrUml9OkGjTT4S3BA2zE90U1GzOO4ch9aJoZcj+SqBz X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Enable console focus for domains w/ virtual NS8250. Code change allows to capture the output from the guest OS now and send it to the physical console device. Signed-off-by: Denis Mukhin --- xen/drivers/char/console.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index a26daee9c4c4b1134d0ae3d105ffdb656340b6df..798dfdf3412a2feef35e72946d6c59bee59a9251 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -41,6 +41,9 @@ #ifdef CONFIG_SBSA_VUART_CONSOLE #include #endif +#if defined(CONFIG_HAS_VUART_NS8250) +#include +#endif /* console: comma-separated list of console outputs. */ static char __initdata opt_console[30] = OPT_CONSOLE_STR; @@ -627,6 +630,8 @@ static void handle_keypress_in_domain(struct domain *d, char c) { #if defined(CONFIG_SBSA_VUART_CONSOLE) rc = vpl011_rx_char_xen(d, c); +#elif defined(CONFIG_HAS_VUART_NS8250) + rc = vuart_putchar(&d->arch.hvm.vuart, c); #endif } /* -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:50:53 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:50:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849559.1264214 (Exim 4.92) (envelope-from ) id 1tJQIn-0000PH-Pa; Fri, 06 Dec 2024 04:50:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849559.1264214; Fri, 06 Dec 2024 04:50: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 1tJQIn-0000PA-Me; Fri, 06 Dec 2024 04:50:53 +0000 Received: by outflank-mailman (input) for mailman id 849559; Fri, 06 Dec 2024 04:50: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 1tJQA3-0004Kb-0L for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:51 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 631cddf8-b38c-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 05:41:42 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id D8A8B5C7314; Fri, 6 Dec 2024 04:40:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 7917CC4CEE3; Fri, 6 Dec 2024 04:41:38 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 70AFAE77173; Fri, 6 Dec 2024 04:41:38 +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: 631cddf8-b38c-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460098; bh=VfxhkDTfiR4LTXzGz0uTAKeAy5NNBjyHiibYeZqaqmE=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=fNb4aYvZhcL1WRoi5y/2Vn2DQM91di4kthUq+ulgmgme60LJZfKOqyq6i0c5XaTRP sqNSIxqti4kqnSD8+DvL9iRMxXL9k0WBX0YeM7Q31UlUcu//vHnZeuIABS9jZrnpN3 enxv9dFpzZ1MPRbjy6Dn8w1djRfaFSRTL0BIaH28UIeLw30USI7NA/aTm3yAdj1b2v ceH8jWb2K5lu2qrt2YD626y+3/vfWRgO0CgYzWOI/p0d9XZA1pJhyMkUujCK+EK1TH QLwMiwLaumBD/v2r1Zt2XsFdviHVNPnU5icOOh+wO8vGKBk09W3BmEc+0E6NiUlYJI NB+Ftmx2yopqA== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:47 -0800 Subject: [PATCH v2 17/35] xen/console: introduce consoled_is_enabled() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-17-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=4454; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=xhuHq6Qjuj4L9zlqilD/J1w4YyMosaifg1eUidT/6sY=; b=M3vrUCaT7Fshofkz23ivWXpzsFNrw5I6pGc14oCE9mPf6+CxOMss7QO9J5jIdUoJl7errU366 uw7W0G+g9R3Cll7yHkk1J6d3Myf566U/qHlna4OTq3D3KwwW1iMVJlC X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin There are few places which check pv_shim console under CONFIG_PV_SHIM in xen console driver. Instead of #ifdef-ing, use new consoled_is_enabled() to customize the logic. Header file now can be included w/o CONFIG_X86. Signature of consoled_guest_{rx,tx} has changed to account for follow-on console switch logic cleanup. Signed-off-by: Denis Mukhin --- xen/drivers/char/console.c | 10 +++------- xen/drivers/char/consoled.c | 18 ++++++++++++++---- xen/include/xen/consoled.h | 35 +++++++++++++++++++++++++++++++++-- 3 files changed, 50 insertions(+), 13 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index f034ce5aab3f3bf59b0df9fa583ee9ce32dbf665..60c055396b697869b04b9132b0dcfa832fabe932 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -33,9 +33,9 @@ #include #include #include +#include #ifdef CONFIG_X86 -#include #include #endif #ifdef CONFIG_SBSA_VUART_CONSOLE @@ -505,11 +505,9 @@ static void console_find_owner(void) break; } -#ifdef CONFIG_PV_SHIM - if ( next_rx == 1 ) + if ( consoled_is_enabled() && next_rx == 1 ) domid = get_initial_domain_id(); else -#endif domid = next_rx - 1; d = rcu_lock_domain_by_id(domid); if ( d ) @@ -573,10 +571,8 @@ static void __serial_rx(char c) #endif } -#ifdef CONFIG_X86 - if ( pv_shim && pv_console ) + if ( consoled_is_enabled() ) consoled_guest_tx(c); -#endif } static void cf_check serial_rx(char c) diff --git a/xen/drivers/char/consoled.c b/xen/drivers/char/consoled.c index b415b632cecc0a80e161b701d7b70ba4f3cc5fb8..d6624e7697f56e1a1959b0efa5dca104f34af002 100644 --- a/xen/drivers/char/consoled.c +++ b/xen/drivers/char/consoled.c @@ -43,13 +43,13 @@ struct xencons_interface *consoled_get_ring_addr(void) static char buf[BUF_SZ + 1]; /* Receives characters from a domain's PV console */ -void consoled_guest_rx(void) +int consoled_guest_rx(void) { size_t idx = 0; XENCONS_RING_IDX cons, prod; if ( !cons_ring ) - return; + return 0; spin_lock(&rx_lock); @@ -91,15 +91,17 @@ void consoled_guest_rx(void) out: spin_unlock(&rx_lock); + + return 0; } /* Sends a character into a domain's PV console */ -void consoled_guest_tx(char c) +int consoled_guest_tx(char c) { XENCONS_RING_IDX cons, prod; if ( !cons_ring ) - return; + return 0; cons = ACCESS_ONCE(cons_ring->in_cons); prod = cons_ring->in_prod; @@ -118,6 +120,7 @@ void consoled_guest_tx(char c) cons_ring->in[MASK_XENCONS_IDX(prod++, cons_ring->in)] = c; + /* Write to the ring before updating the pointer */ smp_wmb(); ACCESS_ONCE(cons_ring->in_prod) = prod; @@ -125,6 +128,13 @@ void consoled_guest_tx(char c) notify: /* Always notify the guest: prevents receive path from getting stuck. */ pv_shim_inject_evtchn(pv_console_evtchn()); + + return 0; +} + +bool consoled_is_enabled(void) +{ + return pv_shim && pv_console; } /* diff --git a/xen/include/xen/consoled.h b/xen/include/xen/consoled.h index bd7ab6329ee8a7c466484021247241ded8ed03c7..696677fa5a3be458a0ec93360e08376c3471f95b 100644 --- a/xen/include/xen/consoled.h +++ b/xen/include/xen/consoled.h @@ -3,10 +3,41 @@ #include +#if defined(CONFIG_PV_SHIM) + void consoled_set_ring_addr(struct xencons_interface *ring); struct xencons_interface *consoled_get_ring_addr(void); -void consoled_guest_rx(void); -void consoled_guest_tx(char c); +int consoled_guest_rx(void); +int consoled_guest_tx(char c); +bool consoled_is_enabled(void); + +#else + +static inline void consoled_set_ring_addr(struct xencons_interface *ring) +{ +} + +static inline struct xencons_interface *consoled_get_ring_addr(void) +{ + return NULL; +} + +static inline int consoled_guest_rx(void) +{ + return 0; +} + +static inline int consoled_guest_tx(char c) +{ + return 0; +} + +static inline bool consoled_is_enabled(void) +{ + return false; +} + +#endif /* #if defined(CONFIG_PV_SHIM) */ #endif /* __XEN_CONSOLED_H__ */ /* -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:51:19 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:51:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849574.1264224 (Exim 4.92) (envelope-from ) id 1tJQJD-00011K-11; Fri, 06 Dec 2024 04:51:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849574.1264224; Fri, 06 Dec 2024 04:51: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 1tJQJC-00011D-Uf; Fri, 06 Dec 2024 04:51:18 +0000 Received: by outflank-mailman (input) for mailman id 849574; Fri, 06 Dec 2024 04:51: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 1tJQA2-0004Ka-Mj for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:50 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [2604:1380:4641:c500::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 64042d93-b38c-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:41:42 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 2B98C5C731E; Fri, 6 Dec 2024 04:40:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id C1AD2C4CEE3; Fri, 6 Dec 2024 04:41:38 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id BC688E77173; Fri, 6 Dec 2024 04:41:38 +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: 64042d93-b38c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460098; bh=veV7CIvzm41wMp2I++KuzZXz6Dndb+ahoqqMyVD1SYk=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=hZTS+FIs6hRZT6n7ePbupewCgCGWvHLzGBsxXoqKjFHNtPVV+uUthUW166T4EKCwp oa36bOKHyxxHG0qkF4ahxl10NOheu6W/wN0XwKFEeMnWYVYNKQuDpSrqRtUUYTMYk3 c45M3cThzdQwXBgFxK6Zt6d1S9yaZKZmnHErA+ltwvuKPajEokq8ROZGaRbxlZObfR ysqQwqGZQueyFq8ptU/PZvjNlyWeVKFT7uxNSXWVw3990flDly05RCiD4pJT2PlBEP Ala+FDE+cTe4Wk8qK8lsd8a6xjCZd69FD5fyEgruUZdd+gk5zmxUf/5BkecXJX6bE7 bQjFS8KDGB5yA== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:52 -0800 Subject: [PATCH v2 22/35] xen/console: introduce handle_keypress_in_domain() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-22-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=3261; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=4Oy6tSy4ntedYhToxhGSrQwpwAn7T/tf6/puha/ackI=; b=SIjDO2ws3eUPEyBeLQ5QQZasuvP/vMSYzru4/T8IBkGlLwzyl1Bg1uoR7rFhT+sbGwXgUo04+ zxn9LrrwYdHAnc0oTPGSzkubS8ZnaOVnYA38M7BnDrd3OcReHl/I/5H X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin With introduction of NS8250 emulator for x86, the logic of switching console focus gets more convoluted: HVM domain w/ NS8205 must be able to receive the physical console input for guest VM debugging. Also, existing code does not honor `hardware_dom=` xen command line parameter (hardware domain ID does _not_ necessarily starts from 0). Introduce handle_keypress_in_domain() to account for all scenarios of console input forwarding. Signed-off-by: Denis Mukhin --- xen/drivers/char/console.c | 72 +++++++++++++++++++++++++++------------------- 1 file changed, 42 insertions(+), 30 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 6261bdb5a2ac1075bc89fa408c0fd6cfef380ae6..ce3639a4cdcda00ea63e3bf119bc3b242cbfdf6a 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -570,14 +570,16 @@ static void console_init_owner(void) console_set_owner(domid); } -static void __serial_rx(char c) +static void handle_keypress_in_domain(struct domain *d, char c) { - switch ( console_owner ) - { - case DOMID_XEN: - return handle_keypress(c, false); + int rc = 0; - case 0: + /* + * Deliver input to the hardware domain buffer. + * NB: must be the first check: hardware domain may have emulated UART. + */ + if ( d == hardware_domain ) + { /* * Deliver input to the hardware domain buffer, unless it is * already full. @@ -590,34 +592,44 @@ static void __serial_rx(char c) * getting stuck. */ send_global_virq(VIRQ_CONSOLE); - break; - -#ifdef CONFIG_SBSA_VUART_CONSOLE - default: - { - struct domain *d = rcu_lock_domain_by_id(console_owner); - - /* - * If we have a properly initialized vpl011 console for the - * domain, without a full PV ring to Dom0 (in that case input - * comes from the PV ring), then send the character to it. - */ - if ( d != NULL ) - vpl011_rx_char_xen(d, c); - else - printk("Cannot send chars to Dom%d: no UART available\n", - console_owner); - - if ( d != NULL ) - rcu_unlock_domain(d); - - break; } + /* + * Deliver input to the emulated UART. + */ + else if ( domain_has_vuart(d) ) + { +#if defined(CONFIG_SBSA_VUART_CONSOLE) + rc = vpl011_rx_char_xen(d, c); #endif } - + /* + * Deliver input to the PV shim console. + */ if ( consoled_is_enabled() ) - consoled_guest_tx(c); + rc = consoled_guest_tx(c); + + if ( rc && rc != -ENODEV ) + printk(KERN_WARNING "console input domain %d: not ready: %d\n", + d->domain_id, rc); +} + +static void __serial_rx(char c) +{ + struct domain *d; + + if ( console_owner == DOMID_XEN ) + { + handle_keypress(c, false); + return; + } + + d = rcu_lock_domain_console_owner(); + if ( d == NULL ) + return; + + handle_keypress_in_domain(d, c); + + rcu_unlock_domain(d); } static void cf_check serial_rx(char c) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:51:23 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:51:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849577.1264234 (Exim 4.92) (envelope-from ) id 1tJQJH-0001Ji-7E; Fri, 06 Dec 2024 04:51:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849577.1264234; Fri, 06 Dec 2024 04:51: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 1tJQJH-0001Jb-4a; Fri, 06 Dec 2024 04:51:23 +0000 Received: by outflank-mailman (input) for mailman id 849577; Fri, 06 Dec 2024 04:51: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 1tJQA9-0004Kb-0W for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:57 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 644269c0-b38c-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 05:41:43 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 960CC5C732D; Fri, 6 Dec 2024 04:40:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 35F63C4CEDE; Fri, 6 Dec 2024 04:41:39 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2C274E77173; Fri, 6 Dec 2024 04:41: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: 644269c0-b38c-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460099; bh=3rV9SQVk/30C/uR+xCoEerXgtGQ+GY3Qffyqy2vy1lU=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=k64HvH+qF2M9KGqEwnq44eOJ05uQEed2KEIqeWYUDnIzhT6RGz0czXFjlzNDO+VAZ 2KCrkwM762rqoIHcLKWZe9gcDm7751+ICxtL7b321CluCXK2EGsJXADEhQ+bUNZuQB 9ElKBIDS71X3NjP0UEtIWWaMHcR50mMLJkEQNAJA/Jrlgc51W4+CN/1DrWxo/E8/VF S6BHFzIiHxRupv3chXQ/ByJEtfrM/YejfB43HundwFN9HJqklvtErhA+4bK28DkaDx MzN/ENlfTD6af7HLWj/plxliEtPAzkLiuk5tVL7f9RYQGWfAlizuZpgqlhQctB30fW j/Tq701j5qasw== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:59 -0800 Subject: [PATCH v2 29/35] x86/hvm: add HVM-specific Kconfig MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-29-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460095; l=5119; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=xth/C4RssnpHF5d1BFSmQSRG1c+DKNwkoUPEyi1j9F4=; b=Vf271mgRaklsri59ELziwyPLixUZV+ZRBALCEceomO950VfpmFBMRC/F1MZNNjtkP1V+Xe9Qe TZw4tEu3tp+D99eMcCUirUGz0xbPwVr/dkhKp/It6nMJui7zC8PG38U X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Add separate menu for configuring HVM build-time settings. That will help organizing HVM-specific options under a separate menu. Signed-off-by: Denis Mukhin --- xen/arch/x86/Kconfig | 66 +++--------------------------------------------- xen/arch/x86/hvm/Kconfig | 63 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 66 insertions(+), 63 deletions(-) diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 9cdd04721afa1916c7edd8fdf7d606858c73ce88..5afee9a9f9bafa3c760b06b8601fad4cad3b7191 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -107,42 +107,9 @@ config PV_LINEAR_PT If unsure, say Y. -config HVM - bool "HVM support" - depends on !PV_SHIM_EXCLUSIVE - default !PV_SHIM - select COMPAT - select IOREQ_SERVER - select MEM_ACCESS_ALWAYS_ON - help - Interfaces to support HVM domains. HVM domains require hardware - virtualisation extensions (e.g. Intel VT-x, AMD SVM), but can boot - guests which have no specific Xen knowledge. - - This option is needed if you want to run HVM or PVH domains. - - If unsure, say Y. - -config AMD_SVM - bool "AMD-V" if EXPERT - depends on HVM - default y - help - Enables virtual machine extensions on platforms that implement the - AMD Virtualization Technology (AMD-V). - If your system includes a processor with AMD-V support, say Y. - If in doubt, say Y. - -config INTEL_VMX - bool "Intel VT-x" if EXPERT - depends on HVM - default y - select ARCH_VCPU_IOREQ_COMPLETION - help - Enables virtual machine extensions on platforms that implement the - Intel Virtualization Technology (Intel VT-x). - If your system includes a processor with Intel VT-x support, say Y. - If in doubt, say Y. +menu "HVM Support" +source "arch/x86/hvm/Kconfig" +endmenu config XEN_SHSTK bool "Supervisor Shadow Stacks" @@ -201,25 +168,6 @@ config BIGMEM If unsure, say N. -config HVM_FEP - bool "HVM Forced Emulation Prefix support (UNSUPPORTED)" if UNSUPPORTED - default DEBUG - depends on HVM - help - - Compiles in a feature that allows HVM guest to arbitrarily - exercise the instruction emulator. - - This feature can only be enabled during boot time with - appropriate hypervisor command line option. Please read - hypervisor command line documentation before trying to use - this feature. - - This is strictly for testing purposes, and not appropriate - for use in production. - - If unsure, say N. - config TBOOT bool "Xen tboot support (UNSUPPORTED)" depends on INTEL && UNSUPPORTED @@ -348,14 +296,6 @@ config HYPERV_GUEST endif -config MEM_PAGING - bool "Xen memory paging support (UNSUPPORTED)" if UNSUPPORTED - depends on HVM - -config MEM_SHARING - bool "Xen memory sharing support (UNSUPPORTED)" if UNSUPPORTED - depends on HVM - config REQUIRE_NX bool "Require NX (No eXecute) support" help diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig new file mode 100644 index 0000000000000000000000000000000000000000..361bb6572e633f3cf0fc972a3b391e8341c33361 --- /dev/null +++ b/xen/arch/x86/hvm/Kconfig @@ -0,0 +1,63 @@ +config HVM + bool "HVM support" + depends on !PV_SHIM_EXCLUSIVE + default !PV_SHIM + select COMPAT + select IOREQ_SERVER + select MEM_ACCESS_ALWAYS_ON + help + Interfaces to support HVM domains. HVM domains require hardware + virtualisation extensions (e.g. Intel VT-x, AMD SVM), but can boot + guests which have no specific Xen knowledge. + + This option is needed if you want to run HVM or PVH domains. + + If unsure, say Y. + +config AMD_SVM + bool "AMD-V" if EXPERT + depends on HVM + default y + help + Enables virtual machine extensions on platforms that implement the + AMD Virtualization Technology (AMD-V). + If your system includes a processor with AMD-V support, say Y. + If in doubt, say Y. + +config INTEL_VMX + bool "Intel VT-x" if EXPERT + depends on HVM + default y + select ARCH_VCPU_IOREQ_COMPLETION + help + Enables virtual machine extensions on platforms that implement the + Intel Virtualization Technology (Intel VT-x). + If your system includes a processor with Intel VT-x support, say Y. + If in doubt, say Y. + +config MEM_PAGING + bool "Xen memory paging support (UNSUPPORTED)" if UNSUPPORTED + depends on HVM + +config MEM_SHARING + bool "Xen memory sharing support (UNSUPPORTED)" if UNSUPPORTED + depends on HVM + +config HVM_FEP + bool "HVM Forced Emulation Prefix support (UNSUPPORTED)" if UNSUPPORTED + default DEBUG + depends on HVM + help + + Compiles in a feature that allows HVM guest to arbitrarily + exercise the instruction emulator. + + This feature can only be enabled during boot time with + appropriate hypervisor command line option. Please read + hypervisor command line documentation before trying to use + this feature. + + This is strictly for testing purposes, and not appropriate + for use in production. + + If unsure, say N. -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:51:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:51:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849579.1264245 (Exim 4.92) (envelope-from ) id 1tJQJL-0001ea-H5; Fri, 06 Dec 2024 04:51:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849579.1264245; Fri, 06 Dec 2024 04:51:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJQJL-0001eL-DB; Fri, 06 Dec 2024 04:51:27 +0000 Received: by outflank-mailman (input) for mailman id 849579; Fri, 06 Dec 2024 04:51: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 1tJQA6-0004Kb-0S for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:54 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 645bba61-b38c-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 05:41:43 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id D40125C7332; Fri, 6 Dec 2024 04:40:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 7635CC4CED1; Fri, 6 Dec 2024 04:41:39 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6EE1EE7717B; Fri, 6 Dec 2024 04:41: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: 645bba61-b38c-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460099; bh=YfYCHh0nVVhyUMXcW2poOpCSgAUn/qfDmEJPr0RM4oY=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=hLzR8gjhUR9ZFUJQotca4vwtdhYWQR4FQmZw4JZ9FrUQk3G0R+E/fXtA2T4uMxAvX OsCNkp0nm4UcV8js+vw6dyZaYIhRYqsnygSw1jnN7xcFiKOcyIfHyfURenDULiECwS iw62GTjHbFfm20AsCPNiyc+gpyuqC6zwnZ5Zt/C/LLHcapQkpERfhLFdrJM+2uyD6n sLBQFTdNnxReWackH13DdEFWaFllSrF9jBT7mk5HR+49vmESu/256p7BCRow9Laudz IG8GfzlznJNF3H8i0Kqsr8QAeBx0pis+myiRmmsIY2mTGOsgB4vb6NJyUh5yGivzc9 ZY5NF2Kkkr5OA== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:42:03 -0800 Subject: [PATCH v2 33/35] x86/domain: implement domain_has_vuart() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-33-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460095; l=7401; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=tfiJLSOur1vSXiemSyjr8enIFIEF26fIRGrdEEwbY18=; b=VUVl57v6//L3I+BVOtYyFg49j9VIti9hgqIArW35Tvfb1KnFjpdoyqXsMGsyn7IqjVEgKnwMC PbyvHwuU4uVDf9Jg3XNoX0yzmMarqvvv+SMIcmGTCTCKalKac3WS555 X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Add new emulation flag for virtual UART on x86 and plumb it through the stack. This change enables NS8250 emulator initialization. Signed-off-by: Denis Mukhin --- tools/libs/light/libxl_x86.c | 6 +++++- tools/ocaml/libs/xc/xenctrl.ml | 1 + tools/ocaml/libs/xc/xenctrl.mli | 1 + tools/python/xen/lowlevel/xc/xc.c | 4 +--- xen/arch/x86/domain.c | 8 +++++--- xen/arch/x86/include/asm/domain.h | 7 ++++--- xen/include/public/arch-x86/xen.h | 14 +++++++++++++- 7 files changed, 30 insertions(+), 11 deletions(-) diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c index a3164a3077fec7e1b81a34074894dc646954a49a..de5f05e18cb0671bb031b101b9a7159eb0fe0178 100644 --- a/tools/libs/light/libxl_x86.c +++ b/tools/libs/light/libxl_x86.c @@ -8,7 +8,11 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, { switch(d_config->c_info.type) { case LIBXL_DOMAIN_TYPE_HVM: - config->arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI); + config->arch.emulation_flags = XEN_X86_EMU_ALL; + config->arch.emulation_flags &= ~XEN_X86_EMU_VPCI; + /* Virtual UART is selected at Xen build time */ + config->arch.emulation_flags &= ~XEN_X86_EMU_VUART; + if (!libxl_defbool_val(d_config->b_info.u.hvm.pirq)) config->arch.emulation_flags &= ~XEN_X86_EMU_USE_PIRQ; break; diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml index 2690f9a92316b812ad3d3ff0e1c36823070adb4a..647239b3e55e88b00eb8e9773a5267894cbbae54 100644 --- a/tools/ocaml/libs/xc/xenctrl.ml +++ b/tools/ocaml/libs/xc/xenctrl.ml @@ -47,6 +47,7 @@ type x86_arch_emulation_flags = | X86_EMU_PIT | X86_EMU_USE_PIRQ | X86_EMU_VPCI + | X86_EMU_VUART type x86_arch_misc_flags = | X86_MSR_RELAXED diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli index febbe1f6ae3f10c5abe45eaa3c06a8a67d9ba268..4f5f64c786e83e8a0c3dd3cdb0460f7095de4a62 100644 --- a/tools/ocaml/libs/xc/xenctrl.mli +++ b/tools/ocaml/libs/xc/xenctrl.mli @@ -41,6 +41,7 @@ type x86_arch_emulation_flags = | X86_EMU_PIT | X86_EMU_USE_PIRQ | X86_EMU_VPCI + | X86_EMU_VUART type x86_arch_misc_flags = | X86_MSR_RELAXED diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c index 9feb12ae2b16e48cb5d0c3c45044ae226f152f2d..e54308956efc7061d58d2166ec9a95bc1dcd1781 100644 --- a/tools/python/xen/lowlevel/xc/xc.c +++ b/tools/python/xen/lowlevel/xc/xc.c @@ -159,9 +159,7 @@ static PyObject *pyxc_domain_create(XcObject *self, #if defined (__i386) || defined(__x86_64__) if ( config.flags & XEN_DOMCTL_CDF_hvm ) - config.arch.emulation_flags = XEN_X86_EMU_ALL & - ~(XEN_X86_EMU_VPCI | - XEN_X86_EMU_USE_PIRQ); + config.arch.emulation_flags = XEN_X86_EMU_HVM_ALLOWABLE; #elif defined (__arm__) || defined(__aarch64__) config.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE; #else diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index c88d422a64544531c1e1058fa484364bb4277d1e..439da7adc92a3a8eb481075bf834da5f9670dd54 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -752,10 +752,10 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags) if ( is_hardware_domain(d) && emflags != (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) ) return false; + + emflags &= ~X86_EMU_VUART; if ( !is_hardware_domain(d) && - /* HVM PIRQ feature is user-selectable. */ - (emflags & ~X86_EMU_USE_PIRQ) != - (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) && + xen_emflags_allowable(emflags) != XEN_X86_EMU_HVM_ALLOWABLE && emflags != X86_EMU_LAPIC ) return false; } @@ -806,6 +806,8 @@ int arch_domain_create(struct domain *d, emflags = config->arch.emulation_flags; + if ( IS_ENABLED(CONFIG_HAS_VUART_NS8250) && is_hvm_domain(d) ) + emflags |= XEN_X86_EMU_VUART; if ( is_hardware_domain(d) && is_pv_domain(d) ) emflags |= XEN_X86_EMU_PIT; diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index c1d0d1f47324e8cc678a4c76c43f86820a89e7b3..dacea6e1aad46e9f8710b2202bb81203c5e92807 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -484,7 +484,8 @@ struct arch_domain #define X86_EMU_VPCI 0 #endif -#define X86_EMU_PIT XEN_X86_EMU_PIT +#define X86_EMU_PIT XEN_X86_EMU_PIT +#define X86_EMU_VUART XEN_X86_EMU_VUART /* This must match XEN_X86_EMU_ALL in xen.h */ #define X86_EMU_ALL (X86_EMU_LAPIC | X86_EMU_HPET | \ @@ -492,7 +493,7 @@ struct arch_domain X86_EMU_IOAPIC | X86_EMU_PIC | \ X86_EMU_VGA | X86_EMU_IOMMU | \ X86_EMU_PIT | X86_EMU_USE_PIRQ | \ - X86_EMU_VPCI) + X86_EMU_VPCI | X86_EMU_VUART) #define has_vlapic(d) (!!((d)->arch.emulation_flags & X86_EMU_LAPIC)) #define has_vhpet(d) (!!((d)->arch.emulation_flags & X86_EMU_HPET)) @@ -507,7 +508,7 @@ struct arch_domain #define has_vpci(d) (!!((d)->arch.emulation_flags & X86_EMU_VPCI)) /* NB: same symbol as in Arm port */ -#define domain_has_vuart(d) false +#define domain_has_vuart(d) (!!((d)->arch.emulation_flags & X86_EMU_VUART)) #define gdt_ldt_pt_idx(v) \ ((v)->vcpu_id >> (PAGETABLE_ORDER - GDT_LDT_VCPU_SHIFT)) diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h index fc2487986642a7694578ab9d2f5f16d09761bff8..e7922e3f9ddc1742a464d228807279839df31e52 100644 --- a/xen/include/public/arch-x86/xen.h +++ b/xen/include/public/arch-x86/xen.h @@ -283,13 +283,25 @@ struct xen_arch_domainconfig { #define XEN_X86_EMU_USE_PIRQ (1U<<_XEN_X86_EMU_USE_PIRQ) #define _XEN_X86_EMU_VPCI 10 #define XEN_X86_EMU_VPCI (1U<<_XEN_X86_EMU_VPCI) +#define _XEN_X86_EMU_VUART 11 +#define XEN_X86_EMU_VUART (1U<<_XEN_X86_EMU_VUART) #define XEN_X86_EMU_ALL (XEN_X86_EMU_LAPIC | XEN_X86_EMU_HPET | \ XEN_X86_EMU_PM | XEN_X86_EMU_RTC | \ XEN_X86_EMU_IOAPIC | XEN_X86_EMU_PIC | \ XEN_X86_EMU_VGA | XEN_X86_EMU_IOMMU | \ XEN_X86_EMU_PIT | XEN_X86_EMU_USE_PIRQ |\ - XEN_X86_EMU_VPCI) + XEN_X86_EMU_VPCI | XEN_X86_EMU_VUART) + +/* HVM PIRQ feature is user-selectable (libxl). */ +#define XEN_X86_EMU_HVM_SELECTABLE (XEN_X86_EMU_VPCI | \ + XEN_X86_EMU_USE_PIRQ | \ + XEN_X86_EMU_VUART) + +#define xen_emflags_allowable(x) ((x) & ~XEN_X86_EMU_HVM_SELECTABLE) + +#define XEN_X86_EMU_HVM_ALLOWABLE xen_emflags_allowable(XEN_X86_EMU_ALL) + uint32_t emulation_flags; /* -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:52:07 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:52:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849610.1264256 (Exim 4.92) (envelope-from ) id 1tJQJy-0002v1-Vw; Fri, 06 Dec 2024 04:52:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849610.1264256; Fri, 06 Dec 2024 04:52: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 1tJQJy-0002uu-RP; Fri, 06 Dec 2024 04:52:06 +0000 Received: by outflank-mailman (input) for mailman id 849610; Fri, 06 Dec 2024 04:52: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 1tJQA3-0004Ka-Mn for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:51 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 641a6002-b38c-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:41:42 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 5D95B5C7324; Fri, 6 Dec 2024 04:40:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id F1783C4CEDD; Fri, 6 Dec 2024 04:41:38 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id EA12DE77171; Fri, 6 Dec 2024 04:41:38 +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: 641a6002-b38c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460099; bh=pEJQg723yWljjn985dh3Vj78Rpiz9AzjJ9MOG9LwSPs=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=lUCcZ3dxSny9GcrhYt/E5TKfIMvzI+VBNAYrTffh2f1GwtL3InyVq1nZXnp/uq8gy utDYxNt2R4iOLZd6qsqs0dGU/U5XKv3gXJn4GMcV7NsTsOce4ydHqc8XRUDpAYZCcK fTU6xWBZ8z19gPFHFgNrNokWKvhsNdyTTY8ZZ+awT6s3ISU5FbhzWIXizkcEmsrW13 mRdXivbAsFGjdjRo2R+G+RrGBsLyD/2MbKP1dCYV45bQ9ysIzald0l+GOT19f4v0mg MYI+I/JmZfrsIOLjJ/dP9wi+6dfBlOsKk+T3RsOQ5RhXSyXqF1Cj4mdiHiSxmk8NOZ KWkNAMg0yJCMQ== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:55 -0800 Subject: [PATCH v2 25/35] xen/console: simplify console owner switch hint MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-25-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=881; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=8rbmvBVON7AxnVLWZe4TyiZNfaP+ce1iMVhidiuAaeA=; b=ngSX/Bjan55Yf6HbhjCcVyH1MRrm+rX6fCLNvoL2CELYqurZ5AMRgsHmNbAjVstU/zeZv2WRK t2fk6SQ9SZpC3ILMTDGon5ON0+OcpvIJPkVFDh3uiDU0ZPaGM8EUHGk X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Update the hint w/ the combination of keys to press to switch physical console to the next owner. Signed-off-by: Denis Mukhin --- xen/drivers/char/console.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 115967d179998cba4a81578caba09db4e4aca7f7..d22fb4a253af26f9b51d91bd408e1dbf4bb5a7c1 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -528,8 +528,8 @@ int console_set_owner(domid_t domid) console_owner = domid; if ( switch_code ) - printk(" (type 'CTRL-%c' three times to switch input)", - opt_conswitch[0]); + printk(" (type 'CTRL-%c%c%c' to switch input)", + opt_conswitch[0], opt_conswitch[0], opt_conswitch[0]); printk("\n"); return 0; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:52:25 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:52:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849623.1264265 (Exim 4.92) (envelope-from ) id 1tJQKH-0003UN-5L; Fri, 06 Dec 2024 04:52:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849623.1264265; Fri, 06 Dec 2024 04:52: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 1tJQKH-0003UG-1w; Fri, 06 Dec 2024 04:52:25 +0000 Received: by outflank-mailman (input) for mailman id 849623; Fri, 06 Dec 2024 04:52: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 1tJQA4-0004Ka-N5 for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:52 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [2604:1380:4641:c500::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 64216c89-b38c-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:41:42 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 689D45C7326; Fri, 6 Dec 2024 04:40:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 09FA7C4CED2; Fri, 6 Dec 2024 04:41:39 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 01DF2E77179; Fri, 6 Dec 2024 04:41: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: 64216c89-b38c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460099; bh=Im1Mvwd2pdpjWUGPxHVuvCi077+oaVpTSYKTKajHUUQ=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=YnIAFC1KOQscV16csADO8+1kFmxcwMoJQGjTMUDHNQJA23KSOad09CfF759yRqc49 hsY/hyXNoiVl7Uzd14gJ3vZGUG7YafwoZV2TsBPjoBqt+SXV9R4eSt7j2rsTAGwiu0 hVDelKN3R5paZ1L5BG/0aFmN1a1bqHxgZxsv9X7qhD7bbA0JHlHGfXmgMAG/OgzMmj JphKEkeoyNNffgAqf8QyEoBXsKqH0hnAqIw7nEzsD8W9JAWbHl3wZk9RRbHu8g/n2d rXBRCRn2YjwGgAGLqohLgjndBKXM9qGD19XGDqi8LKv9Hl4MIURbW/9fXzuGK8sSou 6YkgOd2+gctoA== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:56 -0800 Subject: [PATCH v2 26/35] xen/console: make console buffer size configurable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-26-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=2270; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=c1A6Ce5BfoKvn4U6L7fgV9aDcO1E8jTShGZsUzA9o1w=; b=6nQIusazz8SZIdcS2FjkD73AGOVR3RZCfFt69UsZdbDOMeBLkjG7wc5tSw9FTJxQCypBclp6S qYSAqfv4s5xAyrHNjlKYKwaWHsnUW3YUkTF6v6RS2oc0+KOumBnFyY1 X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Add new CONRING_LOG_SHIFT Kconfig parameter to specify the boot console buffer size as a power of 2. Bump default size to 32 KiB. Link: https://gitlab.com/xen-project/xen/-/issues/185 Signed-off-by: Denis Mukhin --- xen/drivers/char/Kconfig | 23 +++++++++++++++++++++++ xen/drivers/char/console.c | 4 ++-- 2 files changed, 25 insertions(+), 2 deletions(-) diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig index e6e12bb4139717f9319031f51f5d20155d2caee2..3bc892fc38d8cdeb3c76ea44d747f712a8d0d372 100644 --- a/xen/drivers/char/Kconfig +++ b/xen/drivers/char/Kconfig @@ -96,6 +96,29 @@ config SERIAL_TX_BUFSIZE Default value is 32768 (32KiB). +config CONRING_LOG_SHIFT + int "Console buffer size" + range 14 25 + default 15 + help + Select the boot console buffer size as a power of 2. + Run-time console buffer size is the same as the boot console size, + unless enforced via 'conring_size=' boot parameter. + + Examples: + 25 => 32 MiB + 24 => 16 MiB + 23 => 8 MiB + 22 => 4 MiB + 21 => 2 MiB + 20 => 1 MiB + 19 => 512 KiB + 18 => 256 KiB + 17 => 128 KiB + 16 => 64 KiB + 15 => 32 KiB + 14 => 16 KiB + config XHCI bool "XHCI DbC UART driver" depends on X86 diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index d22fb4a253af26f9b51d91bd408e1dbf4bb5a7c1..581ee22b85302a54db5b9d5d28e8b2d689d31403 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -104,11 +104,11 @@ static int cf_check parse_console_timestamps(const char *s); custom_runtime_param("console_timestamps", parse_console_timestamps, con_timestamp_mode_upd); -/* conring_size: allows a large console ring than default (16kB). */ +/* conring_size: allows a large console ring than default (32 KiB). */ static uint32_t __initdata opt_conring_size; size_param("conring_size", opt_conring_size); -#define _CONRING_SIZE 16384 +#define _CONRING_SIZE (1U << CONFIG_CONRING_LOG_SHIFT) #define CONRING_IDX_MASK(i) ((i)&(conring_size-1)) static char __initdata _conring[_CONRING_SIZE]; static char *__read_mostly conring = _conring; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:52:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:52:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849635.1264275 (Exim 4.92) (envelope-from ) id 1tJQKm-0004J2-Dv; Fri, 06 Dec 2024 04:52:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849635.1264275; Fri, 06 Dec 2024 04:52: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 1tJQKm-0004Iv-Ah; Fri, 06 Dec 2024 04:52:56 +0000 Received: by outflank-mailman (input) for mailman id 849635; Fri, 06 Dec 2024 04:52: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 1tJQAA-0004Ka-O2 for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:58 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [2604:1380:4641:c500::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6470a81d-b38c-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:41:44 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id BAEF15C72FF; Fri, 6 Dec 2024 04:40:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 5B6CFC4CED2; Fri, 6 Dec 2024 04:41:39 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 52BB3E77173; Fri, 6 Dec 2024 04:41: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: 6470a81d-b38c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460099; bh=7ox8AYuku3MUu+7+JCRRTVFu9hJNAn02RVHVzf791I4=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=gIA2SOY1FfFYBYT1Mmn4tWVnGT57WAyk1dcQl+Fw8XfrjJyy9Um+J5ZAvBrPlWslv QzDQZ3gW/E1Ci1SkfDbo+0ggHYViOgCsDZh7dJSrXYhmhqCo1hK4HNGfJhSizGYtL5 a+S00kY3yAJqwRR7N81KJ77s9k2QTTz578/1ds7mi266oCf/DQvW8VfihtgFMRIGjh kIkOTAZxAI9/c9X9HDOiDv2ouuURQEryJYIWyuisFo0fsU1KtfzlzrkAYUfbvg7tb8 gABL97+S6AMlFfIeqlBSXZd6U888fdMFcWA+rXACKuuy7X+YfAG+RtfGNbozuPHS1b alMobDk4jzjBg== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:42:01 -0800 Subject: [PATCH v2 31/35] x86/hvm: introduce NS8250 UART emulator MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-31-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460095; l=30223; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=42CO+kpsKd8aGqw1Wi2RPUjXAFZtPSxxxhuC3C8Cx0s=; b=7jSym1HCgQXK3tY7REAoo34oHbZ8fob7eg2BunF86hE4iqf1r6WP4Bhl5Ef95ykA0IYEOqUXA v32CRfUfgP0DKJanKLEugltnyzw1PzKz2qld3GUsKHDMHu2CnzCfS1C X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Add initial in-hypervisor emulator for NS8250/NS16x50-compatible UARTs under CONFIG_HAS_VUART_NS8250. In parallel domain creation scenario (hyperlaunch), NS8520 emulator helps early guest OS bringup debugging, because it eliminates dependency on the external emulator being operational by the time domains are created. Also, there's no early console facility similar to vpl011 to support x86 guest OS bring up. By default, CONFIG_HAS_VUART_NS8250 enables emulatio of NS8250 at I/O port 0x3f8, IRQ#4 in guest OS. Limitations: - Only x86; - Only Linux guest tested so far; - Only legacy COM{1,2,3,4} resources, no customization; - Only Xen console as a backend, no inter-domain communication (similar to vpl011 on Arm); - Only 8-bit characters; - Baud rate is not emulated; - FIFO-less mode is not emulated properly; - RX FIFO interrupt moderation (FCR) is not emulated properly, TL16C750 has special FCR handling; - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and friends); - Assumes no ISA-device IRQ sharing; - MMIO-based UART is not supported. Signed-off-by: Denis Mukhin --- xen/arch/x86/hvm/Kconfig | 14 + xen/arch/x86/hvm/Makefile | 1 + xen/arch/x86/hvm/hvm.c | 13 + xen/arch/x86/hvm/vuart_ns8250.c | 886 ++++++++++++++++++++++++++++ xen/arch/x86/include/asm/hvm/domain.h | 5 + xen/arch/x86/include/asm/hvm/vuart_ns8250.h | 75 +++ 6 files changed, 994 insertions(+) diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig index 361bb6572e633f3cf0fc972a3b391e8341c33361..af6e698b8be0d82af94b00c0cfdaf9a2bc24b154 100644 --- a/xen/arch/x86/hvm/Kconfig +++ b/xen/arch/x86/hvm/Kconfig @@ -61,3 +61,17 @@ config HVM_FEP for use in production. If unsure, say N. + +config HAS_VUART_NS8250 + bool "NS8250-compatible UART Emulation" + depends on HVM && HAS_IOPORTS + default n + help + In-hypervisor NS8250/NS16x50 UART emulation. + + Only legacy PC I/O ports are emulated. + + This is strictly for testing purposes (early HVM guest console), and not + appropriate for use in production. + + If unsure, say N. diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile index 4c1fa5c6c2bf75d336b39f343241bfced5b91b09..14761435e0694109f815da63289666c0f1cbf0ce 100644 --- a/xen/arch/x86/hvm/Makefile +++ b/xen/arch/x86/hvm/Makefile @@ -29,3 +29,4 @@ obj-y += vm_event.o obj-y += vmsi.o obj-y += vpic.o obj-y += vpt.o +obj-$(CONFIG_HAS_VUART_NS8250) += vuart_ns8250.o diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 493b699c708949b2109c26573a107565543f5d45..db61af7defc5f5da795b7a613fe4d32fbff7d93e 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -55,6 +55,7 @@ #include #include #include +#include #include #include #include @@ -679,6 +680,15 @@ int hvm_domain_initialise(struct domain *d, if ( rc != 0 ) goto fail1; + if ( domain_has_vuart(d) ) + { + rc = domain_vuart_init(d); + if ( rc == 0 ) + d->is_console = true; + else if ( rc != -ENODEV ) + goto out_vioapic_deinit; + } + stdvga_init(d); rtc_init(d); @@ -699,6 +709,9 @@ int hvm_domain_initialise(struct domain *d, return 0; fail2: + if ( domain_has_vuart(d) ) + domain_vuart_free(d); + out_vioapic_deinit: vioapic_deinit(d); fail1: if ( is_hardware_domain(d) ) diff --git a/xen/arch/x86/hvm/vuart_ns8250.c b/xen/arch/x86/hvm/vuart_ns8250.c new file mode 100644 index 0000000000000000000000000000000000000000..779dbd80d7be4e070ea9df3ae736ecdc662a527a --- /dev/null +++ b/xen/arch/x86/hvm/vuart_ns8250.c @@ -0,0 +1,886 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * NS8250-compatible UART Emulator. + * + * Limitations: + * - Only x86; + * - Only Linux guest tested so far; + * - Only legacy COM{1,2,3,4} resources, no customization; + * - Only Xen console as a backend, no inter-domain communication (similar to + * vpl011 on Arm); + * - Only 8-bit characters; + * - Baud rate is not emulated; + * - FIFO-less mode is not emulated properly; + * - RX FIFO interrupt moderation (FCR) is not emulated properly, TL16C750 + * has special FCR handling; + * - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and + * friends); + * - Assumes no ISA-device IRQ sharing; + * - MMIO-based UART is not supported; + * - PCI UART is not supported. + */ + +#define pr_fmt(fmt) "ns8250: " fmt +#define pr_log_level hvm_ns8250_log_level + +/* Development debugging */ +#define NS8250_LOG_LEVEL 0 + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include /* console_input_domid() */ +#include /* max_init_domid */ +#include +#include +#include +#include + +#if !defined(pr_fmt) +#define pr_fmt(fmt) fmt +#endif + +#if !defined(pr_log_level) +#define pr_log_level 0 +#endif + +#define pr_err(fmt, args...) \ + gprintk(KERN_ERR, pr_fmt(fmt), ## args) +#define pr_warn(fmt, args...) \ + if (pr_log_level) gprintk(KERN_WARNING, pr_fmt(fmt), ## args) +#define pr_info(fmt, args...) \ + if (pr_log_level) gprintk(KERN_INFO, pr_fmt(fmt), ## args) +#define pr_debug(fmt, args...) \ + if (pr_log_level) gprintk(KERN_DEBUG, pr_fmt(fmt), ## args) + +/* + * NS8250 emulator state machine logging (development only) + * FIXME: use similar to parse_guest_loglvl() + */ +static unsigned int __read_mostly hvm_ns8250_log_level = NS8250_LOG_LEVEL; +integer_param("hvm.ns8250.log_level", hvm_ns8250_log_level); + +/* + * Default emulated NS8250 resources. + * If not specified, COM1 (I/O port 0x3f8, IRQ#4) is emulated. + * FIXME: follow Linux'es console= syntax or re-use + * ns16550_parse_port_config(). + */ +static char __read_mostly hvm_ns8250_console[64]; +string_param("hvm.ns8250.console", hvm_ns8250_console); + +/* I/O access mask */ +static const uint32_t io_access_mask[] = { + [0] = 0X00000000U, + [1] = 0X000000FFU, + [2] = 0X0000FFFFU, + [4] = 0XFFFFFFFFU, +}; + +/* + * Legacy IBM PC NS8250 resources. + * There are only 4 I/O port ranges, hardcoding all of them here. + */ +static const struct { + const char *name; + const struct resource *res; +} ns8250_x86_legacy_uarts[4] = { + [0] = { + .name = "com1", + .res = (const struct resource[]){ + { .type = IORESOURCE_IO, .addr = 0x3F8, .size = UART_MAX }, + { .type = IORESOURCE_IRQ, .addr = 4, .size = 1 }, + { .type = IORESOURCE_UNKNOWN }, + }, + }, + [1] = { + .name = "com2", + .res = (const struct resource[]){ + { .type = IORESOURCE_IO, .addr = 0x2F8, .size = UART_MAX }, + { .type = IORESOURCE_IRQ, .addr = 3, .size = 1 }, + { .type = IORESOURCE_UNKNOWN }, + }, + }, + [2] = { + .name = "com3", + .res = (const struct resource[]){ + { .type = IORESOURCE_IO, .addr = 0x3E8, .size = UART_MAX }, + { .type = IORESOURCE_IRQ, .addr = 4, .size = 1 }, + { .type = IORESOURCE_UNKNOWN }, + }, + }, + [3] = { + .name = "com4", + .res = (const struct resource[]){ + { .type = IORESOURCE_IO, .addr = 0x2E8, .size = UART_MAX }, + { .type = IORESOURCE_IRQ, .addr = 3, .size = 1 }, + { .type = IORESOURCE_UNKNOWN }, + }, + }, +}; + +static bool ns8250_fifo_rx_empty(struct vuart_ns8250 *vdev) +{ + struct xencons_interface *cons = vdev->cons; + + return cons->in_prod == cons->in_cons; +} + +static bool ns8250_fifo_rx_full(struct vuart_ns8250 *vdev) +{ + struct xencons_interface *cons = vdev->cons; + + return cons->in_prod - cons->in_cons == sizeof(cons->in); +} + +static void ns8250_fifo_rx_reset(struct vuart_ns8250 *vdev) +{ + struct xencons_interface *cons = vdev->cons; + + cons->in_cons = cons->in_prod; +} + +static int ns8250_fifo_rx_getchar(struct vuart_ns8250 *vdev) +{ + struct xencons_interface *cons = vdev->cons; + int rc = -1; + + if ( !ns8250_fifo_rx_empty(vdev) ) + { + rc = cons->in[MASK_XENCONS_IDX(cons->in_cons, cons->in)]; + cons->in_cons++; + } + + return rc; +} + +static int ns8250_fifo_rx_putchar(struct vuart_ns8250 *vdev, char c) +{ + struct xencons_interface *cons = vdev->cons; + int rc = 0; + + /* + * FIFO-less 8250/16450 UARTs: newly arrived word overwrites the contents + * of the THR. + */ + if ( ns8250_fifo_rx_full(vdev) ) + { + ns8250_fifo_rx_reset(vdev); + rc = -ENOSPC; + } + + cons->in[MASK_XENCONS_IDX(cons->in_prod, cons->in)] = c; + cons->in_prod++; + + return rc; +} + +/* + * Flush cached output to Xen console. + * Can be called from ns8250_exit(). + */ +static void ns8250_fifo_tx_reset(struct vuart_ns8250 *vdev) +{ + struct xencons_interface *cons = vdev->cons; + + if ( cons->out_prod == 0 ) + return; + + cons->out[cons->out_prod++] = '\0'; + + /* + * NB: do not show domain ID if the domain owning the virtual UART also + * owns Xen input console. + */ + if ( vdev->owner->domain_id == console_owner_domid() ) + printk_common("%s", cons->out); + else + guest_printk(vdev->owner, "%s", cons->out); + + cons->out_prod = 0; +} + +/* + * Send a character to Xen console. + */ +static void ns8250_fifo_tx_putchar(struct vuart_ns8250 *vdev, char ch) +{ + struct xencons_interface *cons = vdev->cons; + + if ( !isconsole(ch) ) + return; + + cons->out[cons->out_prod] = ch; + cons->out_prod++; + + if ( cons->out_prod == ARRAY_SIZE(cons->out) - 1 + || ch == '\n' || ch == '\0' ) + ns8250_fifo_tx_reset(vdev); +} + +static bool cf_check ns8250_iir_check_lsi(struct vuart_ns8250 *vdev) +{ + return !!( vdev->regs[UART_LSR] & UART_LSR_MASK ); +} + +static bool cf_check ns8250_iir_check_rda(struct vuart_ns8250 *vdev) +{ + return !ns8250_fifo_rx_empty(vdev); +} + +static bool cf_check ns8250_iir_check_thr(struct vuart_ns8250 *vdev) +{ + return !!( vdev->flags & NS8250_IRQ_THRE_PENDING ); +} + +static bool cf_check ns8250_iir_check_msi(struct vuart_ns8250 *vdev) +{ + return !!( vdev->regs[UART_MSR] & UART_MSR_DELTA ); +} + +/* + * Interrupt identity reasons by priority. + * NB: highest priority are at lower indexes. + */ +static const struct { + uint8_t ier_mask; + uint8_t iir_mask; + bool (*iir_check)(struct vuart_ns8250 *vdev); +} iir_by_prio[] = { + [0] = { UART_IER_ELSI, UART_IIR_LSI, ns8250_iir_check_lsi }, + [1] = { UART_IER_ERDAI, UART_IIR_RDA, ns8250_iir_check_rda }, + [2] = { UART_IER_ETHREI, UART_IIR_THR, ns8250_iir_check_thr }, + [3] = { UART_IER_EMSI, UART_IIR_MSI, ns8250_iir_check_msi }, +}; + +/* + * Define the interrupt identity reason. + * NB: NS8250 always reports high priority events first. + */ +static uint8_t ns8250_irq_reason(struct vuart_ns8250 *vdev) +{ + int i; + + ASSERT( spin_is_locked(&vdev->lock) ); + for ( i = 0; i < ARRAY_SIZE(iir_by_prio); i++ ) + { + if ( (vdev->regs[UART_IER] & iir_by_prio[i].ier_mask) + && iir_by_prio[i].iir_check(vdev) ) + return iir_by_prio[i].iir_mask; + } + + return UART_IIR_NOINT; +} + +/* + * Assert virtual NS8250 interrupt line. + */ +static void ns8250_irq_assert(struct vuart_ns8250 *vdev) +{ + uint8_t iir; + + iir = ns8250_irq_reason(vdev); + if (iir & UART_IIR_NOINT) + hvm_irq_lower(vdev->owner, vdev->irq); + else + hvm_irq_raise(vdev->owner, vdev->irq); + + pr_debug("IRQ#%d %x %s\n", vdev->irq, iir, + !!(iir & UART_IIR_NOINT) ? "lower" : "raise"); +} + +/* + * Emulate 8-bit write access to NS8250 register. + */ +static int ns8250_io_write8( + struct vuart_ns8250 *vdev, uint32_t reg, uint8_t *data) +{ + uint8_t val; + int rc = 0; + + val = *data; + + switch ( reg ) + { + /* DLAB=0 */ + case UART_THR: + if ( vdev->regs[UART_MCR] & UART_MCR_LOOP ) + { + ns8250_fifo_rx_putchar(vdev, val); + vdev->regs[UART_LSR] |= UART_LSR_OE; + } + else + ns8250_fifo_tx_putchar(vdev, val); + + vdev->flags |= NS8250_IRQ_THRE_PENDING; + + break; + + case UART_IER: + if ( val & vdev->regs[UART_IER] & UART_IER_ETHREI ) + vdev->flags |= NS8250_IRQ_THRE_PENDING; + + vdev->regs[UART_IER] = val & UART_IER_MASK; + + break; + + case UART_FCR: /* WO */ + if ( val & UART_FCR_CLRX ) + ns8250_fifo_rx_reset(vdev); + + if ( val & UART_FCR_CLTX ) + ns8250_fifo_tx_reset(vdev); + + if ( !(val & UART_FCR_ENABLE) ) + val = 0; + + vdev->regs[UART_FCR] = val & (UART_FCR_ENABLE | + UART_FCR_DMA | + UART_FCR_TRG_MASK); + + break; + + case UART_LCR: + vdev->regs[UART_LCR] = val; + break; + + case UART_MCR: { + uint8_t msr_curr, msr_next, msr_delta; + + msr_curr = vdev->regs[UART_MSR]; + msr_next = 0; + msr_delta = 0; + + /* Set modem status */ + if ( val & UART_MCR_LOOP ) + { + if ( val & UART_MCR_DTR ) + msr_next |= UART_MSR_DSR; + if ( val & UART_MCR_RTS ) + msr_next |= UART_MSR_CTS; + if ( val & UART_MCR_OUT1 ) + msr_next |= UART_MSR_RI; + if ( val & UART_MCR_OUT2 ) + msr_next |= UART_MSR_DCD; + } + else + msr_next |= UART_MSR_DCD | UART_MSR_DSR | UART_MSR_CTS; + + /* Calculate changes in modem status */ + if ( (msr_curr & UART_MSR_CTS) ^ (msr_next & UART_MSR_CTS) ) + msr_delta |= UART_MSR_DCTS; + if ( (msr_curr & UART_MCR_RTS) ^ (msr_next & UART_MCR_RTS) ) + msr_delta |= UART_MSR_DDSR; + if ( (msr_curr & UART_MSR_RI) & (msr_next & UART_MSR_RI) ) + msr_delta |= UART_MSR_TERI; + if ( (msr_curr & UART_MSR_DCD) ^ (msr_next & UART_MSR_DCD) ) + msr_delta |= UART_MSR_DDCD; + + vdev->regs[UART_MCR] = val & UART_MCR_MASK; + vdev->regs[UART_MSR] = msr_next | msr_delta; + + break; + } + + case UART_LSR: /* RO */ + case UART_MSR: /* RO */ + rc = -EINVAL; + break; + + /* + * NB: Firmware like OVMF rely on SCR presence to initialize the ns8250 + * driver. + */ + case UART_SCR: + vdev->regs[UART_SCR] = val; + break; + + /* DLAB=1 */ + case UART_MAX + UART_DLL: + vdev->dl = (vdev->dl & 0xFF00U) | val; + break; + + case UART_MAX + UART_DLM: + vdev->dl = (val << 8) | (vdev->dl & 0x00FFU); + break; + + default: + rc = -EINVAL; + break; + } + + return rc; +} + +/* + * Emulate 16-bit write access to NS8250 register. + * NB: some guest OSes use outw() to access UART_DLL. + */ +static int ns8250_io_write16( + struct vuart_ns8250 *vdev, uint32_t reg, uint16_t *data) +{ + int rc; + + switch ( reg ) + { + case UART_MAX + UART_DLL: + vdev->dl = *data; + rc = 0; + break; + + default: + rc = -EINVAL; + break; + } + + return rc; +} + +/* + * Emulate write access to NS8250 register. + */ +static int ns8250_io_write( + struct vuart_ns8250 *vdev, uint8_t reg, uint32_t size, uint32_t *data) +{ + int rc = -EINVAL; + + switch ( size ) + { + case 1: + rc = ns8250_io_write8(vdev, reg, (uint8_t *)data); + break; + + case 2: + rc = ns8250_io_write16(vdev, reg, (uint16_t *)data); + break; + + default: + break; + } + + ns8250_irq_assert(vdev); + + return rc; +} + +/* + * Emulate 8-bit read access to NS8250 register. + */ +static int ns8250_io_read8( + struct vuart_ns8250 *vdev, uint32_t reg, uint8_t *data) +{ + int rc = 0; + uint8_t val; + + switch ( reg ) + { + /* DLAB=0 */ + case UART_RBR: + val = (uint8_t)ns8250_fifo_rx_getchar(vdev); + /* NB: do not forget to clear overrun condition */ + vdev->regs[UART_LSR] &= ~UART_LSR_OE; + break; + + case UART_IER: /* RO */ + val = vdev->regs[UART_IER]; + break; + + case UART_IIR: + val = ns8250_irq_reason(vdev); + if ( val & UART_IIR_THR ) + vdev->flags &= ~NS8250_IRQ_THRE_PENDING; + + if ( vdev->regs[UART_FCR] & UART_FCR_ENABLE ) + val |= UART_IIR_FE_MASK; + + break; + + case UART_LCR: + val = vdev->regs[UART_LCR]; + break; + + case UART_MCR: + val = vdev->regs[UART_MCR]; + break; + + case UART_LSR: + val = vdev->regs[UART_LSR] | UART_LSR_THRE | UART_LSR_TEMT; + if ( ns8250_fifo_rx_empty(vdev) ) + val &= ~UART_LSR_DR; + else + val |= UART_LSR_DR; + + vdev->regs[UART_LSR] = val & ~UART_LSR_MASK; + + break; + + case UART_MSR: + val = vdev->regs[UART_MSR]; + vdev->regs[UART_MSR] &= ~UART_MSR_DELTA; + break; + + case UART_SCR: + val = vdev->regs[UART_SCR]; + break; + + /* DLAB=1 */ + case UART_MAX + UART_DLL: + val = vdev->dl & 0xFFU; + break; + + case UART_MAX + UART_DLM: + val = vdev->dl >> 8; + break; + + default: + val = (uint8_t)io_access_mask[1]; + rc = -EINVAL; + break; + } + + *data = val; + + return rc; +} + +/* + * Emulate 16-bit read access to NS8250 register. + */ +static int ns8250_io_read16( + struct vuart_ns8250 *vdev, uint32_t reg, uint16_t *data) +{ + uint16_t val; + int rc; + + switch ( reg ) + { + case UART_MAX + UART_DLL: + val = vdev->dl; + rc = 0; + break; + + default: + val = (uint16_t)io_access_mask[2]; + rc = -EINVAL; + break; + } + + *data = val; + + return rc; +} + +/* + * Emulate read access to NS8250 register. + */ +static int ns8250_io_read( + struct vuart_ns8250 *vdev, uint8_t reg, uint32_t size, uint32_t *data) +{ + int rc; + + switch ( size ) + { + case 1: + rc = ns8250_io_read8(vdev, reg, (uint8_t *)data); + break; + + case 2: + rc = ns8250_io_read16(vdev, reg, (uint16_t *)data); + break; + + default: + *data = io_access_mask[size]; + rc = -EINVAL; + break; + } + + ns8250_irq_assert(vdev); + + return rc; +} + +static const char *ns8250_regname( + const struct vuart_ns8250 *vdev, uint32_t reg, int dir) +{ + static const char *reg_names[UART_MAX + 2][2] = { + /* register W R */ + [UART_RBR] = { "THR", "RBR" }, + [UART_IER] = { "IER", "IER" }, + [UART_IIR] = { "FCR", "IIR" }, + [UART_LCR] = { "LCR", "LCR" }, + [UART_MCR] = { "MCR", "MCR" }, + [UART_LSR] = { "LSR", "LSR" }, + [UART_MSR] = { "MSR", "MSR" }, + [UART_SCR] = { "SCR", "SCR" }, + [UART_MAX + UART_DLL] = { "DLL", "DLL" }, + [UART_MAX + UART_DLM] = { "DLM", "DLM" }, + }; + + return reg_names[reg][dir]; +} + +/* + * Emulate I/O access to NS8250 register. + */ +static int cf_check ns8250_io_handle( + int dir, unsigned int addr, unsigned int size, uint32_t *data) +{ +#define op(dir) (((dir) == IOREQ_WRITE) ? 'W' : 'R') + struct domain *d = rcu_lock_current_domain(); + struct vuart_ns8250 *vdev = &d->arch.hvm.vuart; + uint32_t offset, reg; + int rc; + + spin_lock(&vdev->lock); + + BUG_ON( vdev->owner != d ); + + if ( !(vdev->flags & NS8250_READY) ) + { + pr_err("%c io 0x%04x %d 0x%08"PRIx32": propagate to external I/O emulator\n", + op(dir), addr, size, *data); + rc = X86EMUL_UNHANDLEABLE; + goto out; + } + + reg = addr - vdev->io_addr; + BUG_ON( reg >= UART_MAX ); + if ( reg % size != 0 ) + { + pr_err("%c 0x%04x %d 0x%08"PRIx32": unaligned access\n", + op(dir), addr, size, *data & io_access_mask[size]); + rc = X86EMUL_OKAY; + goto out; + } + + /* Redirect access to divisor latch registers */ + if ( !!(vdev->regs[UART_LCR] & UART_LCR_DLAB) + && (reg == UART_DLL || reg == UART_DLM) ) + offset = UART_MAX + reg; + else + offset = reg; + + if ( dir == IOREQ_WRITE ) + { + pr_debug("%c 0x%04x %d 0x%08"PRIx32" %s[0x%02"PRIx32"]\n", + op(dir), addr, size, + *data & io_access_mask[size], + ns8250_regname(vdev, offset, dir), reg); + rc = ns8250_io_write(vdev, offset, size, data); + } + else + { + rc = ns8250_io_read(vdev, offset, size, data); + pr_debug("%c 0x%04x %d 0x%08"PRIx32" %s[0x%02"PRIx32"]\n", + op(dir), addr, size, + *data & io_access_mask[size], + ns8250_regname(vdev, offset, dir), reg); + } + if ( rc ) + pr_err("%c 0x%04x %d 0x%08"PRIx32": unsupported access\n", + op(dir), addr, size, *data & io_access_mask[size]); + rc = X86EMUL_OKAY; + +out: + spin_unlock(&vdev->lock); + + return rc; +#undef op +} + +/* + * Parse virtual NS8250 configuration. + * hvm.ns8250.console=[com1|com2|com3|com4] + */ +static const struct resource *ns8250_parse(void) +{ + int i; + + for ( i = 0; i < ARRAY_SIZE(ns8250_x86_legacy_uarts); i++ ) + if ( !strcasecmp(hvm_ns8250_console, ns8250_x86_legacy_uarts[i].name) ) + return ns8250_x86_legacy_uarts[i].res; + + return ns8250_x86_legacy_uarts[0].res; +} + +/* + * Claim virtual NS8250 resources to domain. + */ +static int ns8250_claim( + struct vuart_ns8250 *vdev, const struct resource *r, struct domain *d) +{ + unsigned long size; + unsigned long start; + unsigned long end; + + vdev->irq = NO_IRQ; + vdev->io_addr = IORESOURCE_UNKNOWN; + vdev->io_size = IORESOURCE_UNKNOWN; + + foreach_resource(r) + { + if ( r->type & IORESOURCE_IO ) + { + size = r->size; + start = r->addr; + end = r->addr + r->size - 1; + + if ( !ioports_access_permitted(d, start, end) ) + ioports_permit_access(d, start, end); + + register_portio_handler(d, start, size, ns8250_io_handle); + + /* Used to assert I/O port handler */ + vdev->io_addr = start; + vdev->io_size = size; + } + else if ( r->type & IORESOURCE_IRQ ) + /* "Claim" virtual IRQ; assumes no ISA-device IRQ sharing */ + vdev->irq = r->addr; + else + return -EINVAL; + } + + if ( vdev->irq == NO_IRQ + || vdev->io_addr == IORESOURCE_UNKNOWN + || vdev->io_size == IORESOURCE_UNKNOWN ) + return -ENODEV; + + return 0; +} + +/* + * Unclaim virtual NS8250 resources. + */ +static void ns8250_unclaim(struct vuart_ns8250 *vdev, struct domain *d) +{ + unsigned long size = vdev->io_size; + unsigned long start = vdev->io_addr; + unsigned long end = start + size - 1; + + if ( ioports_access_permitted(d, start, end) ) + ioports_deny_access(d, start, size); +} + +static int ns8250_init(struct domain *d, const struct resource *r) +{ + struct vuart_ns8250 *vdev = &d->arch.hvm.vuart; + struct xencons_interface *cons; + int rc; + + cons = _xzalloc(sizeof(*vdev->cons), sizeof(void *)); + if ( cons == NULL ) + return -ENOMEM; + + rc = ns8250_claim(vdev, r, d); + if ( rc ) + { + xfree(cons); + return rc; + } + + spin_lock_init(&vdev->lock); + hvm_irq_lower(d, vdev->irq); + + vdev->dl = (UART_CLOCK_HZ / 115200) >> 4; /* Report 115200 baud rate */ + vdev->cons = cons; + vdev->owner = d; + vdev->flags = NS8250_READY | NS8250_IRQ_THRE_PENDING; + + return 0; +} + +static void ns8250_exit(struct domain *d) +{ + struct vuart_ns8250 *vdev = &d->arch.hvm.vuart; + + spin_lock(&vdev->lock); + + if ( !(vdev->flags & NS8250_READY) ) + goto out; + + ns8250_unclaim(vdev, d); + ns8250_fifo_tx_reset(vdev); + xfree(vdev->cons); + + vdev->cons = NULL; + vdev->owner = NULL; + vdev->flags = 0; + +out: + spin_unlock(&vdev->lock); +} + +int vuart_putchar(struct vuart_ns8250 *vdev, char ch) +{ + int rc; + + spin_lock(&vdev->lock); + + if ( !(vdev->flags & NS8250_READY) ) + { + rc = -ENODEV; + goto out; + } + + /* Echo the user input on the console */ + printk("%c", ch); + + /* + * Device is in loopback mode; do nothing. + */ + if ( vdev->regs[UART_MCR] & UART_MCR_LOOP ) + { + rc = -EBUSY; + goto out; + } + + rc = ns8250_fifo_rx_putchar(vdev, ch); + if ( rc == -ENOSPC ) + vdev->regs[UART_LSR] |= UART_LSR_OE | UART_LSR_DR; + else + /* NB: UART_LSR_DR is also set when UART_LSR is accessed. */ + vdev->regs[UART_LSR] |= UART_LSR_DR; + + /* FIXME: check FCR when to fire an interrupt */ + ns8250_irq_assert(vdev); + +out: + spin_unlock(&vdev->lock); + + return rc; +} + +int domain_vuart_init(struct domain *d) +{ + struct vuart_ns8250 *vdev = &d->arch.hvm.vuart; + const struct resource *r; + + memset(vdev, 0, sizeof(*vdev)); + + r = ns8250_parse(); + if ( r != NULL ) + return ns8250_init(d, r); + + return -ENODEV; +} + +void domain_vuart_free(struct domain *d) +{ + ns8250_exit(d); +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/x86/include/asm/hvm/domain.h b/xen/arch/x86/include/asm/hvm/domain.h index 333501d5f2ac01676646b9b277b551f06d43c3a5..d4ce25896259fc9763477e88d56bacbe4f78af5b 100644 --- a/xen/arch/x86/include/asm/hvm/domain.h +++ b/xen/arch/x86/include/asm/hvm/domain.h @@ -16,6 +16,7 @@ #include #include #include +#include #ifdef CONFIG_MEM_SHARING struct mem_sharing_domain @@ -73,6 +74,10 @@ struct hvm_domain { struct hvm_vioapic **vioapic; unsigned int nr_vioapics; +#if defined(CONFIG_HAS_VUART_NS8250) + struct vuart_ns8250 vuart; +#endif + /* * hvm_hw_pmtimer is a publicly-visible name. We will defer renaming * it to the more appropriate hvm_hw_acpi until the expected diff --git a/xen/arch/x86/include/asm/hvm/vuart_ns8250.h b/xen/arch/x86/include/asm/hvm/vuart_ns8250.h new file mode 100644 index 0000000000000000000000000000000000000000..e1013751f955441a9089ea38c96c4605a7f4cb75 --- /dev/null +++ b/xen/arch/x86/include/asm/hvm/vuart_ns8250.h @@ -0,0 +1,75 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * NS8250-compatible UART Emulator. + */ +#if !defined(HVM__VUART_NS8250_H) +#define HVM__VUART_NS8250_H + +#include +#include +#include /* xencons_interface */ + +/* + * NS8250 emulator operational flags. + */ +enum { + /* Emulator is ready */ + NS8250_READY = BIT(0, U), + /* Trigger re-delivery of THRE interrupt */ + NS8250_IRQ_THRE_PENDING = BIT(1, U), +}; + +/* + * Virtual NS8250 device state. + */ +struct vuart_ns8250 { + uint16_t dl; /* Divisor Latch */ + uint8_t regs[UART_MAX]; /* Registers */ + uint32_t flags; /* Virtual device flags */ + uint64_t io_addr; /* Guest I/O region base address */ + uint64_t io_size; /* Guest I/O region size */ + int irq; /* Guest IRQ# */ + struct xencons_interface *cons; /* Emulated RX/TX FIFOs */ + struct domain *owner; /* Owner domain */ + spinlock_t lock; /* Protection */ +}; + +#if defined(CONFIG_HAS_VUART_NS8250) + +int vuart_putchar(struct vuart_ns8250 *vdev, char ch); + +/* + * Match the names w/ arch/arm/vuart.h + * FIXME: move to common vuart.h + */ +int domain_vuart_init(struct domain *d); +void domain_vuart_free(struct domain *d); + +#else + +static inline int vuart_putchar(struct vuart_ns8250 *vdev, char ch) +{ + return -1; +} + +static inline int domain_vuart_init(struct domain *d) +{ + return -ENODEV; +} + +static inline void domain_vuart_free(struct domain *d) +{ +} + +#endif /* #if defined(CONFIG_HAS_VUART_NS8250) */ + +#endif /* #if !defined(HVM__VUART_NS8250_H) */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:56:57 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:56:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849686.1264285 (Exim 4.92) (envelope-from ) id 1tJQOa-0005Xd-27; Fri, 06 Dec 2024 04:56:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849686.1264285; Fri, 06 Dec 2024 04:56:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJQOZ-0005XW-V0; Fri, 06 Dec 2024 04:56:51 +0000 Received: by outflank-mailman (input) for mailman id 849686; Fri, 06 Dec 2024 04:56: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 1tJQA4-0004Kb-0M for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:52 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [2604:1380:4641:c500::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 634d5860-b38c-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 05:41:42 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 077005C7318; Fri, 6 Dec 2024 04:40:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 995A9C4CEDE; Fri, 6 Dec 2024 04:41:38 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8FF5CE77173; Fri, 6 Dec 2024 04:41:38 +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: 634d5860-b38c-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460098; bh=Msd9ALOQsKWgqYjqZp3vEbU4YxKp+IL/6j5doF/TX4s=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=X+rwlw/Zhai565ag9BYuM8ARm2DmW+qeIP0rEQDoOGMhV8nJZiXDotnvEi2++uIOv tIZVZeOY8vKJou4RWDXs6BDXUHTYW/wiaDpDWvqEhJtJ+tcbs5dl0Hn/SxL1DMXWx6 mT9SrdjkqUkGBqZtgwS5Lw5L5MaFD5MQrqvzgInx43ChGbWJzE0Qemtll4RsmutM9g fuPkDIIyCU5D9dh+XvlrNsFgSzL8yN71Xt6F5GUUURgqUT18KBmJdLY3cLMsyo7F6Y QRWBJ7c4h+zrWvJXpzuthPGUaGfrc1nCNpPPOSdTmkil9QBGNbrA+0JuQTtBs1qp09 FQfBt7I9O/AGw== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:49 -0800 Subject: [PATCH v2 19/35] xen/console: introduce console_set_owner() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-19-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=6105; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=LaoLtTtPVB803Wx66ywoNWCuGefL+9P7BcXWkOi4Ttw=; b=qIUuqjar9jBz7vlbvZO91eK5QZyrPGkyZdxoOW+bK/PhH1tCuhvcar4R2tTKQ6B0C7F6lxM93 WMCmcpor8byDDi3SZubIYvLxdlI1nk8JsNjv/6WTA/rYizZqV4c2rlQ X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin console_set_owner() is introduced for setting the new console owner. Switches console owner to domain ID vs range of integer numbers mapped to domain IDs. This a public API to console driver, will be used in the follow on code change. Signed-off-by: Denis Mukhin --- xen/drivers/char/console.c | 122 ++++++++++++++++++++++++++------------------- xen/include/xen/console.h | 1 + 2 files changed, 71 insertions(+), 52 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 8cbac54c66044ae8581e486a782102b75c8bfaa9..52cf64dbf6fd18d599cb88835d03501a23b3e3c4 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -463,82 +463,100 @@ static void cf_check dump_console_ring_key(unsigned char key) /* * CTRL- changes input direction, rotating among Xen, Dom0, - * and the DomUs started from Xen at boot. + * and the DomUs. */ #define switch_code (opt_conswitch[0]-'a'+1) + /* - * console_owner=0 => input to xen - * console_owner=1 => input to dom0 (or the sole shim domain) - * console_owner=N => input to dom(N-1) + * Current console owner domain ID: either Xen or domain w/ d->is_console == + * true. + * + * Initialized in console_endboot(). */ -static unsigned int __read_mostly console_owner = 0; +static domid_t __read_mostly console_owner; -#define max_console_rx (max_init_domid + 1) +static struct domain *rcu_lock_domain_console_by_id(domid_t domid) +{ + struct domain *d; + + d = rcu_lock_domain_by_id(domid); + + if ( d == NULL ) + return NULL; + + if ( d->is_console ) + return d; + + rcu_unlock_domain(d); + + return NULL; +} -#ifdef CONFIG_SBSA_VUART_CONSOLE /* Make sure to rcu_unlock_domain after use */ struct domain *rcu_lock_domain_console_owner(void) { - if ( console_owner == 0 ) - return NULL; - return rcu_lock_domain_by_id(console_owner - 1); + return rcu_lock_domain_console_by_id(console_owner); } -#endif -static void console_find_owner(void) +static bool console_owner_possible(domid_t domid) { - unsigned int next_rx = console_owner; - - /* - * Rotate among Xen, dom0 and boot-time created domUs while skipping - * switching serial input to non existing domains. - */ - for ( ; ; ) - { - domid_t domid; - struct domain *d; - - if ( next_rx++ >= max_console_rx ) - { - console_owner = 0; - printk("*** Serial input to Xen"); - break; - } - - if ( consoled_is_enabled() && next_rx == 1 ) - domid = get_initial_domain_id(); - else - domid = next_rx - 1; - - d = rcu_lock_domain_by_id(domid); - if ( d == NULL ) - continue; - - if ( d->is_console ) - { - rcu_unlock_domain(d); - console_owner = next_rx; - printk("*** Serial input to DOM%u", domid); - break; - } + struct domain *d; + d = rcu_lock_domain_console_by_id(domid); + if ( d != NULL ) rcu_unlock_domain(d); - } + + return d != NULL; +} + +int console_set_owner(domid_t domid) +{ + if ( domid == DOMID_XEN ) + printk("*** Serial input to Xen"); + else if ( console_owner_possible(domid) ) + printk("*** Serial input to DOM%u", domid); + else + return -ENOENT; + + console_owner = domid; if ( switch_code ) printk(" (type 'CTRL-%c' three times to switch input)", opt_conswitch[0]); printk("\n"); + + return 0; +} + +/* + * Switch console input focus. + * Rotates input focus among Xen, dom0 and boot-time created domUs while + * skipping switching serial input to non existing domains. + */ +static void console_find_owner(void) +{ + domid_t i, n = max_init_domid + 1; + + if ( console_owner == DOMID_XEN ) + i = get_initial_domain_id(); + else + i = console_owner + 1; + + for ( ; i < n; i++ ) + if ( !console_set_owner(i) ) + break; + if ( i == n ) + console_set_owner(DOMID_XEN); } static void __serial_rx(char c) { switch ( console_owner ) { - case 0: + case DOMID_XEN: return handle_keypress(c, false); - case 1: + case 0: /* * Deliver input to the hardware domain buffer, unless it is * already full. @@ -556,7 +574,7 @@ static void __serial_rx(char c) #ifdef CONFIG_SBSA_VUART_CONSOLE default: { - struct domain *d = rcu_lock_domain_by_id(console_owner - 1); + struct domain *d = rcu_lock_domain_by_id(console_owner); /* * If we have a properly initialized vpl011 console for the @@ -567,7 +585,7 @@ static void __serial_rx(char c) vpl011_rx_char_xen(d, c); else printk("Cannot send chars to Dom%d: no UART available\n", - console_owner - 1); + console_owner); if ( d != NULL ) rcu_unlock_domain(d); @@ -1126,7 +1144,7 @@ void __init console_endboot(void) * a useful 'how to switch' message. */ if ( opt_conswitch[1] == 'x' ) - console_owner = max_console_rx; + console_owner = DOMID_XEN; register_keyhandler('w', dump_console_ring_key, "synchronously dump console ring buffer (dmesg)", 0); diff --git a/xen/include/xen/console.h b/xen/include/xen/console.h index 0e211e44d9703c804e18f52c9743916f8d2a9d4e..57c482cfbf2da15b011e64841ea086e779f4588d 100644 --- a/xen/include/xen/console.h +++ b/xen/include/xen/console.h @@ -32,6 +32,7 @@ void console_start_log_everything(void); void console_end_log_everything(void); struct domain *rcu_lock_domain_console_owner(void); +int console_set_owner(domid_t); /* * Steal output from the console. Returns +ve identifier, else -ve error. -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:57:00 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:57:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849691.1264295 (Exim 4.92) (envelope-from ) id 1tJQOi-0005qx-8p; Fri, 06 Dec 2024 04:57:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849691.1264295; Fri, 06 Dec 2024 04:57:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJQOi-0005qo-5g; Fri, 06 Dec 2024 04:57:00 +0000 Received: by outflank-mailman (input) for mailman id 849691; Fri, 06 Dec 2024 04:56: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 1tJQA7-0004Ka-Nh for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:55 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 644bfbde-b38c-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:41:43 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id A52EF5C732E; Fri, 6 Dec 2024 04:40:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 474BEC4CEDD; Fri, 6 Dec 2024 04:41:39 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F6D9E77175; Fri, 6 Dec 2024 04:41: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: 644bfbde-b38c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460099; bh=WDr/PwUo7NPVqK8vVCu/sN3ApYHaNVXqHBFVutTjEsg=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=g9qa65XgT5Ti4I/dt0zAvh88VVZ8gYPwjf1RlnWBD6k0hqV7efZ2HqXdNt1syG6Gs Uzio9wCFBAMxJSwgLQ633VtFVqKBKw5sdipxVH4KpcjxT6bgmioK9u/cPVyOFt1axG 0+L8CcziOT19Rf4F37f8A3yxU49YxRNdKfn2EbGCHtn00nEDiUPFWcp02do6FsDUu8 w0/Pmv8IbSkCJCmvFBJF0gXjinqNcIt4+0yLnkwokU9vYCkurq6yGDxPlLfV+Oas6X KM7DVGtHII2LbcdmOKDJ2VkdUHASud+eWqsDXQtwK2s2dbo/gmA/sGH/2Ez7FKoU3O SW53fiVi2h/yQ== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:42:00 -0800 Subject: [PATCH v2 30/35] x86/hvm: add helpers for raising guest IRQs MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-30-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460095; l=1876; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=7BbjWtYddozrVOKtAkZI0QGQoqm6ofyyNdgxey+37YU=; b=uhL0RGFLhulzxy34cTyyqujnBOZL+ZBS9SzwALgDFSK48UaqsfdXhwT9z9YUX31hMSipGTyQr NaKRK096AcJApdMQnckrIdCUs36HPCgT/O+UwoSDG/wyfSUkq8syezC X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Added convenience wrappers for asserting/de-asserting interrupts in the hardware emulation code. That will be used for PCI-based NS8250 emulator. Signed-off-by: Denis Mukhin --- xen/arch/x86/hvm/irq.c | 24 ++++++++++++++++++++++++ xen/arch/x86/include/asm/hvm/irq.h | 3 +++ 2 files changed, 27 insertions(+) diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c index 1eab44defca4c82ec35769617c66c380cc07d1b6..9e3a50d21dcf281c1015116094e47795c51ed5d0 100644 --- a/xen/arch/x86/hvm/irq.c +++ b/xen/arch/x86/hvm/irq.c @@ -242,6 +242,30 @@ void hvm_isa_irq_deassert( spin_unlock(&d->arch.hvm.irq_lock); } +void hvm_irq_raise(struct domain *d, unsigned int irq) +{ + if ( irq < NR_ISAIRQS ) + { + hvm_isa_irq_assert(d, irq, NULL); + } + else + { + hvm_gsi_assert(d, irq); + } +} + +void hvm_irq_lower(struct domain *d, unsigned int irq) +{ + if ( irq < NR_ISAIRQS ) + { + hvm_isa_irq_deassert(d, irq); + } + else + { + hvm_gsi_deassert(d, irq); + } +} + static void hvm_set_callback_irq_level(struct vcpu *v) { struct domain *d = v->domain; diff --git a/xen/arch/x86/include/asm/hvm/irq.h b/xen/arch/x86/include/asm/hvm/irq.h index 87e89993a44f48f366fa84e851688f383cb562d4..27bb9f64171c1b8aac2cf119699e60c91e727177 100644 --- a/xen/arch/x86/include/asm/hvm/irq.h +++ b/xen/arch/x86/include/asm/hvm/irq.h @@ -210,6 +210,9 @@ void hvm_maybe_deassert_evtchn_irq(void); void hvm_assert_evtchn_irq(struct vcpu *v); void hvm_set_callback_via(struct domain *d, uint64_t via); +void hvm_irq_raise(struct domain *d, unsigned int irq); +void hvm_irq_lower(struct domain *d, unsigned int irq); + struct pirq; bool hvm_domain_use_pirq(const struct domain *d, const struct pirq *pirq); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:58:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:58:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849724.1264305 (Exim 4.92) (envelope-from ) id 1tJQQc-00075O-Ka; Fri, 06 Dec 2024 04:58:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849724.1264305; Fri, 06 Dec 2024 04:58:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJQQc-00075H-HQ; Fri, 06 Dec 2024 04:58:58 +0000 Received: by outflank-mailman (input) for mailman id 849724; Fri, 06 Dec 2024 04:58: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 1tJQA8-0004Kb-0Y for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:56 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 64345bc6-b38c-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 05:41:43 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 753495C7328; Fri, 6 Dec 2024 04:40:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 1675AC4CEE4; Fri, 6 Dec 2024 04:41:39 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0EA64E77173; Fri, 6 Dec 2024 04:41: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: 64345bc6-b38c-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460099; bh=pfeozTwM0lG3guW16R9YEzvHJZviJlXoXV1tkNollME=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=f6gF7PdCGex8zQ5mnanBXlfimZN+yyf9wVHGpLH0v6ONU5aF1nyYf9uODenzHMjZg o7TVTyUr8MFFtqHsow6MDgvfsSCOEz9yXNXR4dOtTCuxIAZbKan3DSLU2yquYO7qp8 uY9B1aNpIuM2d8MvvF8szQdybnNboU4qdnHckcUhTtBFkU7RpNYDNDrEGd4DKh0TFS 98HivOcZfVQBNf2kz83KBaurJrL0Im3fLndLTxxr/PO4vTfPWk84Cvixwi4y3PH4My GB7dHoXVLHiCIkByOrbVTRlPToks8znvhQwux0BcsAlLqSbrNYF+01+J3FrNbLUrRT I22VL57Iv98zg== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:57 -0800 Subject: [PATCH v2 27/35] xen/console: flush console ring to physical console MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-27-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460095; l=3110; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=9P4Y8stZ3v9veFAxdHp9EFeTfuXrbjGeXMl4yBrDrRM=; b=LcDAXG+yR65ns4PDQ7+Ep0c/twONKtCO6FP3OyvFTTqVtifqgbIkwSkeCUfa9psmIj3lFPPnM 83h3+UYJFZ4D7QPLSxSZewJhQFIyiw2yPpSDbEylErgaWgtM7WS39IF X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Messages printed before the serial and VGA consoles are initialized end up in the internal console buffer (conring). Flush contents of conring to all external consoles after external consoles are fully initialied. Link: https://gitlab.com/xen-project/xen/-/issues/184 Signed-off-by: Denis Mukhin --- xen/drivers/char/console.c | 54 +++++++++++++++++++++++++++++++++------------- 1 file changed, 39 insertions(+), 15 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 581ee22b85302a54db5b9d5d28e8b2d689d31403..a26daee9c4c4b1134d0ae3d105ffdb656340b6df 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -426,23 +426,35 @@ void console_serial_puts(const char *s, size_t nr) pv_console_puts(s, nr); } -static void cf_check dump_console_ring_key(unsigned char key) +/* + * Write characters to physical console(s). + * That covers: + * - serial console; + * - video output. + */ +static void console_puts(const char *str, size_t len) +{ + ASSERT(rspin_is_locked(&console_lock)); + + console_serial_puts(str, len); + video_puts(str, len); +} + +/* + * Flush contents of the conring to the physical console devices. + */ +static int console_flush(void) { uint32_t idx, len, sofar, c; unsigned int order; char *buf; - printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key); - - /* create a buffer in which we'll copy the ring in the correct - order and NUL terminate */ order = get_order_from_bytes(conring_size + 1); buf = alloc_xenheap_pages(order, 0); if ( buf == NULL ) - { - printk("unable to allocate memory!\n"); - return; - } + return -ENOMEM; + + nrspin_lock_irq(&console_lock); c = conringc; sofar = 0; @@ -457,10 +469,23 @@ static void cf_check dump_console_ring_key(unsigned char key) c += len; } - console_serial_puts(buf, sofar); - video_puts(buf, sofar); + console_puts(buf, sofar); + + nrspin_unlock_irq(&console_lock); free_xenheap_pages(buf, order); + + return 0; +} + +static void cf_check dump_console_ring_key(unsigned char key) +{ + int rc; + + printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key); + rc = console_flush(); + if ( rc ) + printk("failed to dump console ring buffer: %d\n", rc); } /* @@ -707,10 +732,7 @@ static inline void xen_console_write(const char *str, size_t len) */ static void console_write(const char *str, size_t len) { - ASSERT(rspin_is_locked(&console_lock)); - - console_serial_puts(str, len); - video_puts(str, len); + console_puts(str, len); if ( opt_console_xen ) xen_console_write(str, len); @@ -1177,6 +1199,8 @@ void __init console_endboot(void) video_endboot(); + /* NB: send conring contents to all enabled physical consoles, if any */ + console_flush(); use_conring = opt_console_to_ring; smp_wmb(); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 04:59:58 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 04:59:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849736.1264315 (Exim 4.92) (envelope-from ) id 1tJQRZ-0007sZ-UH; Fri, 06 Dec 2024 04:59:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849736.1264315; Fri, 06 Dec 2024 04: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 1tJQRZ-0007sS-Ra; Fri, 06 Dec 2024 04:59:57 +0000 Received: by outflank-mailman (input) for mailman id 849736; Fri, 06 Dec 2024 04: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 1tJQA6-0004Ka-NM for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:54 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 642fa7da-b38c-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:41:43 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 8411F5C732A; Fri, 6 Dec 2024 04:40:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 25C16C4CEE0; Fri, 6 Dec 2024 04:41:39 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1DE67E77175; Fri, 6 Dec 2024 04:41: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: 642fa7da-b38c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460099; bh=tqpmdL8JNRiLSamzy9ROf/yJ/66J2svyAG5pfiQILB0=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=u7P9mgJdpIjUCR4UTz9a57NXTHwJcB5aeeBrK0LU7Nov965LEsoBe1GBVhjVO3QQZ W0SvFy5A84Aj2H5qY5gPmEeXd3tCpjZc7TsXw3UnXUcX1htfK98vbtvrmCyfPpCOwQ EqZnHIb39dZc2WW8OTP6pkjnestLt6EXqx62a8t0QZ38di3jKlWrRiGJJt7/fNhUrl kTw2HUnIIjiUezrcjUDkyyl7bPM0FeCx3XdlC/dcbicKbiw9+tSCxw8+1oiEWNSUdq zR6UZuQZHfdI3MuFIrdANp4QHQv1nNe/+H+fDOHUO0Pw9PM/3cb6xbOTNfLwmBDjBJ N+4Z/BvgzJ8Mw== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:58 -0800 Subject: [PATCH v2 28/35] xen/8250-uart: add missing definitions MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-28-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460095; l=7150; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=tIDl7kdtapSdiWgcLjWmQ7v8zbW9hmc48ULvT599z7A=; b=kPzosi8ho+ByeLwfCWEeVFseo8sJZ+0pQO4SEJq2xAHq/cop5Z9wnnfTJ7hX4VXH2kuye0ajT y1zxyalUV4kBc0xBvVDO5M7y3G4JHEggAouSPKUNF5FfZUP436ueI3j X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Added missing definitions needed for NS8250 UART emulator. Signed-off-by: Denis Mukhin --- xen/include/xen/8250-uart.h | 81 +++++++++++++++++++++++++++++++++------------ 1 file changed, 60 insertions(+), 21 deletions(-) diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h index d13352940c13c50bac17d4cdf2f3bf584380776a..4a69b2b225140efda287bdf96fa0caa4aa70074f 100644 --- a/xen/include/xen/8250-uart.h +++ b/xen/include/xen/8250-uart.h @@ -32,16 +32,22 @@ #define UART_MCR 0x04 /* Modem control */ #define UART_LSR 0x05 /* line status */ #define UART_MSR 0x06 /* Modem status */ +#define UART_SCR 0x07 /* Scratch pad */ #define UART_USR 0x1f /* Status register (DW) */ #define UART_DLL 0x00 /* divisor latch (ls) (DLAB=1) */ #define UART_DLM 0x01 /* divisor latch (ms) (DLAB=1) */ #define UART_XR_EFR 0x09 /* Enhanced function register (Exar) */ +/* ns8250 emulator: range of emulated registers [0..UART_MAX-1] */ +#define UART_MAX (UART_SCR + 1) + /* Interrupt Enable Register */ #define UART_IER_ERDAI 0x01 /* rx data recv'd */ #define UART_IER_ETHREI 0x02 /* tx reg. empty */ #define UART_IER_ELSI 0x04 /* rx line status */ #define UART_IER_EMSI 0x08 /* MODEM status */ +#define UART_IER_MASK \ + (UART_IER_ERDAI | UART_IER_ETHREI | UART_IER_ELSI | UART_IER_EMSI) /* Interrupt Identification Register */ #define UART_IIR_NOINT 0x01 /* no interrupt pending */ @@ -51,12 +57,21 @@ #define UART_IIR_THR 0x02 /* - tx reg. empty */ #define UART_IIR_MSI 0x00 /* - MODEM status */ #define UART_IIR_BSY 0x07 /* - busy detect (DW) */ +#define UART_IIR_FE0 BIT(6, U) /* FIFO enable #0 */ +#define UART_IIR_FE1 BIT(7, U) /* FIFO enable #1 */ +#define UART_IIR_FE_MASK (UART_IIR_FE0 | UART_IIR_FE1) /* FIFO Control Register */ -#define UART_FCR_ENABLE 0x01 /* enable FIFO */ -#define UART_FCR_CLRX 0x02 /* clear Rx FIFO */ -#define UART_FCR_CLTX 0x04 /* clear Tx FIFO */ -#define UART_FCR_DMA 0x10 /* enter DMA mode */ +#define UART_FCR_ENABLE BIT(0, U) /* enable FIFO */ +#define UART_FCR_CLRX BIT(1, U) /* clear Rx FIFO */ +#define UART_FCR_CLTX BIT(2, U) /* clear Tx FIFO */ +#define UART_FCR_DMA BIT(3, U) /* enter DMA mode */ +#define UART_FCR_RESERVED0 BIT(4, U) /* reserved; always 0 */ +#define UART_FCR_RESERVED1 BIT(5, U) /* reserved; always 0 */ +#define UART_FCR_RTB0 BIT(6, U) /* receiver trigger bit #0 */ +#define UART_FCR_RTB1 BIT(7, U) /* receiver trigger bit #1 */ +#define UART_FCR_TRG_MASK (UART_FCR_RTB0 | UART_FCR_RTB1) + #define UART_FCR_TRG1 0x00 /* Rx FIFO trig lev 1 */ #define UART_FCR_TRG4 0x40 /* Rx FIFO trig lev 4 */ #define UART_FCR_TRG8 0x80 /* Rx FIFO trig lev 8 */ @@ -64,17 +79,17 @@ /* * Note: The FIFO trigger levels are chip specific: - * RX:76 = 00 01 10 11 TX:54 = 00 01 10 11 - * PC16550D: 1 4 8 14 xx xx xx xx - * TI16C550A: 1 4 8 14 xx xx xx xx - * TI16C550C: 1 4 8 14 xx xx xx xx - * ST16C550: 1 4 8 14 xx xx xx xx - * ST16C650: 8 16 24 28 16 8 24 30 PORT_16650V2 - * NS16C552: 1 4 8 14 xx xx xx xx - * ST16C654: 8 16 56 60 8 16 32 56 PORT_16654 - * TI16C750: 1 16 32 56 xx xx xx xx PORT_16750 - * TI16C752: 8 16 56 60 8 16 32 56 - * Tegra: 1 4 8 14 16 8 4 1 PORT_TEGRA + * RX:76 = 00 01 10 11 TX:54 = 00 01 10 11 + * PC16550D: 1 4 8 14 xx xx xx xx + * TI16C550A: 1 4 8 14 xx xx xx xx + * TI16C550C: 1 4 8 14 xx xx xx xx + * ST16C550: 1 4 8 14 xx xx xx xx + * ST16C650: 8 16 24 28 16 8 24 30 PORT_16650V2 + * NS16C552: 1 4 8 14 xx xx xx xx + * ST16C654: 8 16 56 60 8 16 32 56 PORT_16654 + * TI16C750: 1 16 32 56 xx xx xx xx PORT_16750 + * TI16C752: 8 16 56 60 8 16 32 56 + * Tegra: 1 4 8 14 16 8 4 1 PORT_TEGRA */ #define UART_FCR_R_TRIG_00 0x00 #define UART_FCR_R_TRIG_01 0x40 @@ -96,11 +111,31 @@ #define UART_LCR_CONF_MODE_B 0xBF /* Configuration mode B */ /* Modem Control Register */ -#define UART_MCR_DTR 0x01 /* Data Terminal Ready */ -#define UART_MCR_RTS 0x02 /* Request to Send */ -#define UART_MCR_OUT2 0x08 /* OUT2: interrupt mask */ -#define UART_MCR_LOOP 0x10 /* Enable loopback test mode */ -#define UART_MCR_TCRTLR 0x40 /* Access TCR/TLR (TI16C752, EFR[4]=1) */ +#define UART_MCR_DTR BIT(0, U) /* Data Terminal Ready */ +#define UART_MCR_RTS BIT(1, U) /* Request to Send */ +#define UART_MCR_OUT1 BIT(2, U) /* OUT1: interrupt mask */ +#define UART_MCR_OUT2 BIT(3, U) /* OUT2: interrupt mask */ +#define UART_MCR_LOOP BIT(4, U) /* Enable loopback test mode */ +#define UART_MCR_RESERVED0 BIT(5, U) /* Reserved #0 */ +#define UART_MCR_RESERVED1 BIT(6, U) /* Reserved #1 */ +#define UART_MCR_TCRTLR BIT(6, U) /* Access TCR/TLR (TI16C752, EFR[4]=1) */ +#define UART_MCR_RESERVED2 BIT(7, U) /* Reserved #2 */ +#define UART_MCR_MASK \ + (UART_MCR_DTR | UART_MCR_RTS | \ + UART_MCR_OUT1 | UART_MCR_OUT2 | \ + UART_MCR_LOOP) + +/* Modem Status Register */ +#define UART_MSR_DCTS BIT(0, U) /* Change in CTS */ +#define UART_MSR_DDSR BIT(1, U) /* Change in DSR */ +#define UART_MSR_TERI BIT(2, U) /* Change in RI */ +#define UART_MSR_DDCD BIT(3, U) /* Change in CTS */ +#define UART_MSR_CTS BIT(4, U) +#define UART_MSR_DSR BIT(5, U) +#define UART_MSR_RI BIT(6, U) +#define UART_MSR_DCD BIT(7, U) +#define UART_MSR_DELTA \ + (UART_MSR_DCTS | UART_MSR_DDSR | UART_MSR_TERI | UART_MSR_DDCD) /* Line Status Register */ #define UART_LSR_DR 0x01 /* Data ready */ @@ -111,6 +146,7 @@ #define UART_LSR_THRE 0x20 /* Xmit hold reg empty */ #define UART_LSR_TEMT 0x40 /* Xmitter empty */ #define UART_LSR_ERR 0x80 /* Error */ +#define UART_LSR_MASK (UART_LSR_OE | UART_LSR_BI) /* These parity settings can be ORed directly into the LCR. */ #define UART_PARITY_NONE (0<<3) @@ -119,7 +155,10 @@ #define UART_PARITY_MARK (5<<3) #define UART_PARITY_SPACE (7<<3) -/* Frequency of external clock source. This definition assumes PC platform. */ +/* + * Frequency of external UART clock source. + * Same as IBM PC master input clock frequency. + */ #define UART_CLOCK_HZ 1843200 /* Bits in Exar specific UART_XR_EFR register */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 05:01:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 05:01:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849758.1264325 (Exim 4.92) (envelope-from ) id 1tJQSi-0001iZ-BM; Fri, 06 Dec 2024 05:01:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849758.1264325; Fri, 06 Dec 2024 05:01:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJQSi-0001iS-8a; Fri, 06 Dec 2024 05:01:08 +0000 Received: by outflank-mailman (input) for mailman id 849758; Fri, 06 Dec 2024 05:01: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 1tJQA7-0004Kb-0S for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:55 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 642d15e5-b38c-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 05:41:43 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 505A75C7323; Fri, 6 Dec 2024 04:40:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id E50A9C4CEDE; Fri, 6 Dec 2024 04:41:38 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id DBE78E77175; Fri, 6 Dec 2024 04:41:38 +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: 642d15e5-b38c-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460098; bh=PJJ4npH36unNSzjXcb8NI2vArWEkfURXL6bFFuUiDHo=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=UQgkSZtWVa9FG9t1D5mOZW5z072Osw8G8GmdO1+7fn17cWhT0Ro8xPOW/k8vF45No kA21roJuxVeE0nzz7aI/hcDSWdDh5fd1KR36560FtLwOLm0BfIbgarlaI3I7dXFkAy ue39WmPRawJ1/n9YG9L3vT1WBEYrNBiINIbnRUt7kTpYEOI4Cz3zIH0I+uG3HwCSlX lCpXFcN+KXgYunteT3BKGARDEuxesjKuQWhCgdicE3PMsZahaoisGbUJMt1QAvFc2y mNaU3ZSiqJCiPoo6Wq/ToTGYZaEtn4mr3CWdaDnLfMS4bDoldla6Lhi4cbsOAUskja nhYA9JkPvmNFg== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:54 -0800 Subject: [PATCH v2 24/35] xen/console: introduce hwdom_crashconsole= MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-24-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=3897; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=1SE1nPGu4xeTH/OTKpOlxTlLd/mo9Wc6622Zz4Y1AHc=; b=Ojfyv76A9s+nHItTnUu5XXzmcReLwQ/cS7xcueyxc3sbROAgSJngYgjiuIlonbN9oIe8CBGJs YSZYIJCFA4+CNyG8V/SJfCQkjRyHkBMEHk16OIe2bCfcQi3csn2vS0U X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin The new command line switch `hwdom_crashconsole=BOOL` allows to switch serial console input focus to xen for machine state inspection using keyhandler mechanism after the hardware domain crashes. The new command line switch is aliased via `dom0=...,crashconsole` knob. Such functionality can be useful while debugging dom0 bringup. Signed-off-by: Denis Mukhin --- docs/misc/xen-command-line.pandoc | 5 +++++ xen/arch/x86/dom0_build.c | 2 ++ xen/common/domain.c | 14 +++++++++++++- xen/include/xen/domain.h | 1 + 4 files changed, 21 insertions(+), 1 deletion(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 293dbc1a957ba6e668fd4d55d58e84f643822126..fb77d7dca1ea517f79d6713aa6909422f31e7724 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -806,6 +806,7 @@ Specify the bit width of the DMA heap. ### dom0 = List of [ pv | pvh, shadow=, verbose=, + crashconsole=, cpuid-faulting=, msr-relaxed= ] (x86) = List of [ sve= ] (Arm64) @@ -839,6 +840,10 @@ Controls for how dom0 is constructed on x86 systems. information during the dom0 build. It defaults to the compile time choice of `CONFIG_VERBOSE_DEBUG`. +* The `crashconsole` boolean instructs Xen to drop into emergency console + in case of dom0 crash. May be useful for dom0 bringup on a custom + hardware. + * The `cpuid-faulting` boolean is an interim option, is only applicable to PV dom0, and defaults to true. diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c index e8f5bf5447bc47a6daa3d95787106a4c11e80d31..706aeec0ecbb565a415edbfb33ca2fd72967c560 100644 --- a/xen/arch/x86/dom0_build.c +++ b/xen/arch/x86/dom0_build.c @@ -286,6 +286,8 @@ int __init parse_arch_dom0_param(const char *s, const char *e) opt_dom0_cpuid_faulting = val; else if ( (val = parse_boolean("msr-relaxed", s, e)) >= 0 ) opt_dom0_msr_relaxed = val; + else if ( (val = parse_boolean("crashconsole", s, e)) >= 0 ) + opt_hwdom_crashconsole = !!val; else return -EINVAL; diff --git a/xen/common/domain.c b/xen/common/domain.c index aab546c0a8535e4f007cbbc9c5c552bcf66b5807..4fe69f294158dda7b2e0b9d98d49c34e04131cb8 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -56,6 +56,13 @@ unsigned int xen_processor_pmbits = XEN_PROCESSOR_PM_PX; bool opt_dom0_vcpus_pin; boolean_param("dom0_vcpus_pin", opt_dom0_vcpus_pin); +/* + * Hardware domain crash handler: if true, do not halt machine, but switch to + * Xen console for debugging. + */ +bool opt_hwdom_crashconsole; +boolean_param("hwdom_crashconsole", opt_hwdom_crashconsole); + /* Protect updates/reads (resp.) of domain_list and domain_hash. */ DEFINE_SPINLOCK(domlist_update_lock); DEFINE_RCU_READ_LOCK(domlist_read_lock); @@ -1138,7 +1145,12 @@ int domain_shutdown(struct domain *d, u8 reason) reason = d->shutdown_code; if ( is_hardware_domain(d) ) - hwdom_shutdown(reason); + { + if ( opt_hwdom_crashconsole ) + console_set_owner(DOMID_XEN); + else + hwdom_shutdown(reason); + } if ( d->is_shutting_down ) { diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h index 6102826a929ff7aad58a4bc40974815071a97446..e0c52af878b69e28e2d19957d0d3a8234860ecba 100644 --- a/xen/include/xen/domain.h +++ b/xen/include/xen/domain.h @@ -150,6 +150,7 @@ extern unsigned int xen_processor_pmbits; extern bool opt_dom0_vcpus_pin; extern cpumask_t dom0_cpus; extern bool dom0_affinity_relaxed; +extern bool opt_hwdom_crashconsole; /* vnuma topology per domain. */ struct vnuma_info { -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 05:01:30 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 05:01:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849771.1264335 (Exim 4.92) (envelope-from ) id 1tJQT4-0002MQ-IW; Fri, 06 Dec 2024 05:01:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849771.1264335; Fri, 06 Dec 2024 05:01:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJQT4-0002MJ-Fg; Fri, 06 Dec 2024 05:01:30 +0000 Received: by outflank-mailman (input) for mailman id 849771; Fri, 06 Dec 2024 05:01: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 1tJQA8-0004Ka-No for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:56 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 64187365-b38c-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:41:43 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 3C87F5C7320; Fri, 6 Dec 2024 04:40:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id D3109C4CEE0; Fri, 6 Dec 2024 04:41:38 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id CCB59E77171; Fri, 6 Dec 2024 04:41:38 +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: 64187365-b38c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460098; bh=eiE+Vk1+xwNQSS5lGvaUqRJncjb6mebSOM3N939URVI=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=d7BCDKwQXwZ4cbD1bFWhjDN/m+kXVWns99wYk96kr3EEL6V5TOfihPPg1zdjHjzYE hbhg3UGCriGtvZwt73RW5evUKX2XjkeYiDqjSa/hWTbaza3FSVSlasA/bLG4ECCjuR 3C71xULHuxVorDFC9FXMO9uOOpM6Msregplpkrb71Kd9Nus2tuNTqYwGJmq6ZN6n9s N6tfJBP8EvviPMtZ0KcOpzCVI6F73bO3nHt3c2tH/jVHmCMD+A4rAjTZ+nvbT5VHxt XhxI6AQayVJ5sIuSPZsArLR72nEYNXrHvpPYAepN2BrXFBJmh+6eiRau/op/7QioEa 9ZzR5RMXS6d3A== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:53 -0800 Subject: [PATCH v2 23/35] xen/console: introduce console_write() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-23-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=5090; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=IJndR90ln3ebR9JBLgcF8uZuUsxgXYKVX60Wdeeyfgg=; b=jHyeiWGUT3FC9wqdvmDyFZNzJI9ClfZ3Imp+FXv2XyaFHnvRcCAdBiVl5YgFppU5q80Nh4ylX 0lCDMsThybKD8ezbX7OiCuZe8c8k5/af+wQnUOUAs2dL7Iq58CX25YI X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin PV Linux kernel uses HYPERVISOR_console_io hypercall for early console which ends up being handled by Xen's console driver's guest_console_write(). guest_console_write() duplicates the code from __putstr(), elimitate code duplication. Signed-off-by: Denis Mukhin --- xen/drivers/char/console.c | 97 +++++++++++++++++++++++++--------------------- 1 file changed, 53 insertions(+), 44 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index ce3639a4cdcda00ea63e3bf119bc3b242cbfdf6a..115967d179998cba4a81578caba09db4e4aca7f7 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -63,6 +63,8 @@ static const char __initconst warning_sync_console[] = "However it can introduce SIGNIFICANT latencies and affect\n" "timekeeping. It is NOT recommended for production use!\n"; +/* Flag: use conring for early console; switches to opt_console_to_ring */ +static bool __read_mostly use_conring = true; /* console_to_ring: send guest (incl. dom 0) console data to console ring. */ static bool __read_mostly opt_console_to_ring; boolean_param("console_to_ring", opt_console_to_ring); @@ -661,6 +663,16 @@ static void cf_check notify_dom0_con_ring(void *unused) static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet, notify_dom0_con_ring, NULL); +static bool console_locks_busted; + +static void conring_write(const char *str, size_t len) +{ + conring_puts(str, len); + + if ( !console_locks_busted ) + tasklet_schedule(¬ify_dom0_con_ring_tasklet); +} + #ifdef CONFIG_X86 static inline void xen_console_write_debug_port(const char *buf, size_t len) { @@ -669,8 +681,44 @@ static inline void xen_console_write_debug_port(const char *buf, size_t len) : "=&S" (tmp), "=&c" (tmp) : "0" (buf), "1" (len), "d" (XEN_HVM_DEBUGCONS_IOPORT) ); } + +static void xen_console_write(const char *str, size_t len) +{ + if ( xen_guest ) + xen_hypercall_console_write(str, len); + else + xen_console_write_debug_port(str, len); +} +#else +static inline void xen_console_write(const char *str, size_t len) +{ +} #endif +/* + * Write characters to console. + * + * That will handle all possible scenarios working w/ console + * - serial console; + * - video output; + * - __HYPERVISOR_console_io hypercall (x86 only); + * - debug I/O port (x86 only); + * - forward to Xen event channel. + */ +static void console_write(const char *str, size_t len) +{ + ASSERT(rspin_is_locked(&console_lock)); + + console_serial_puts(str, len); + video_puts(str, len); + + if ( opt_console_xen ) + xen_console_write(str, len); + + if ( use_conring ) + conring_write(str, len); +} + static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, unsigned int count) { @@ -691,28 +739,8 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, if ( is_hardware_domain(cd) ) { - /* Use direct console output as it could be interactive */ nrspin_lock_irq(&console_lock); - - console_serial_puts(kbuf, kcount); - video_puts(kbuf, kcount); - -#ifdef CONFIG_X86 - if ( opt_console_xen ) - { - if ( xen_guest ) - xen_hypercall_console_write(kbuf, kcount); - else - xen_console_write_debug_port(kbuf, kcount); - } -#endif - - if ( opt_console_to_ring ) - { - conring_puts(kbuf, kcount); - tasklet_schedule(¬ify_dom0_con_ring_tasklet); - } - + console_write(kbuf, kcount); nrspin_unlock_irq(&console_lock); } else @@ -813,31 +841,9 @@ long do_console_io( * ***************************************************** */ -static bool console_locks_busted; - static void __putstr(const char *str) { - size_t len = strlen(str); - - ASSERT(rspin_is_locked(&console_lock)); - - console_serial_puts(str, len); - video_puts(str, len); - -#ifdef CONFIG_X86 - if ( opt_console_xen ) - { - if ( xen_guest ) - xen_hypercall_console_write(str, len); - else - xen_console_write_debug_port(str, len); - } -#endif - - conring_puts(str, len); - - if ( !console_locks_busted ) - tasklet_schedule(¬ify_dom0_con_ring_tasklet); + console_write(str, strlen(str)); } static int printk_prefix_check(char *p, char **pp) @@ -1171,6 +1177,9 @@ void __init console_endboot(void) video_endboot(); + use_conring = opt_console_to_ring; + smp_wmb(); + register_keyhandler('w', dump_console_ring_key, "synchronously dump console ring buffer (dmesg)", 0); register_irq_keyhandler('+', &do_inc_thresh, -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 05:01:32 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 05:01:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849774.1264344 (Exim 4.92) (envelope-from ) id 1tJQT6-0002ct-PN; Fri, 06 Dec 2024 05:01:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849774.1264344; Fri, 06 Dec 2024 05:01:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJQT6-0002cg-Lq; Fri, 06 Dec 2024 05:01:32 +0000 Received: by outflank-mailman (input) for mailman id 849774; Fri, 06 Dec 2024 05:01: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 1tJQA5-0004Ka-N8 for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:53 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 63c4dfa4-b38c-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:41:43 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 21D635C731C; Fri, 6 Dec 2024 04:40:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id B770CC4CEE4; Fri, 6 Dec 2024 04:41:38 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id ADBAEE77175; Fri, 6 Dec 2024 04:41:38 +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: 63c4dfa4-b38c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460098; bh=xN3Qk4AnkavJDz1+2oRzOsxhatlUANXuldhRbnVqaL0=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=WuYwP5N6FRVi49Tvc8z9O/76ioaUpi/FZQBJuMRGDB+GTX2VceyVOCu8rPyGBR9BJ Oc6LrY1JRMML+ctUVgOXz6zrZlPrbcvalDD+qBZGcAGzG/2luW3je+hPqXh2k02o2z YQ7HuB/3Ww2fsvyjPNmOm++JScVRUe0EUm5VJoRK7WZVH45B66YCLescgZHWO+B0ph f1aA8/e1LbT9z1wYmvG0kem2XXv9tpqFZ8J0KYmh8KtFUav8gHDOvgTkvtjsuMaduG 5BlvCSCLrHlqbO+6whey6fmCI1ci/YwN9wpp6ZFAzGacJHjCscL0md3noT+4DXQVNC fmeyoSd8P6+lQ== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:41:51 -0800 Subject: [PATCH v2 21/35] xen/console: introduce console_init_owner() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-21-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460094; l=1949; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=9IHMF1BdeViUoT1r1xwy88EM2J39hJxCdMpf6FUj+oc=; b=rkPuVSjKM6PdcjQpqYx04yf5XSLLo6WwLxCVOm3Xp526geyD7FoALVxOn/SqrCa9cjSfLb+QZ qW8+QGL4+VvD3kA/ow2AsW8esC9XvQRMDoI/h0TfmZ1MW76KHXfU+fc X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin console_init_owner() is introduced for selecting the boot-time console owner. Signed-off-by: Denis Mukhin --- xen/drivers/char/console.c | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index a8ab5c2bcb98e4cadf9ad2c9ad28d297977d0557..6261bdb5a2ac1075bc89fa408c0fd6cfef380ae6 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -554,6 +554,22 @@ static void console_find_owner(void) console_set_owner(DOMID_XEN); } +static void console_init_owner(void) +{ + domid_t domid; + + /* + * If user specifies so, we fool the switch routine to redirect input + * straight back to Xen. + */ + if ( opt_conswitch[1] == 'x' ) + domid = DOMID_XEN; + else + domid = get_initial_domain_id(); + + console_set_owner(domid); +} + static void __serial_rx(char c) { switch ( console_owner ) @@ -1143,14 +1159,6 @@ void __init console_endboot(void) video_endboot(); - /* - * If user specifies so, we fool the switch routine to redirect input - * straight back to Xen. I use this convoluted method so we still print - * a useful 'how to switch' message. - */ - if ( opt_conswitch[1] == 'x' ) - console_owner = DOMID_XEN; - register_keyhandler('w', dump_console_ring_key, "synchronously dump console ring buffer (dmesg)", 0); register_irq_keyhandler('+', &do_inc_thresh, @@ -1160,8 +1168,7 @@ void __init console_endboot(void) register_irq_keyhandler('G', &do_toggle_guest, "toggle host/guest log level adjustment", 0); - /* Serial input is directed to DOM0 by default. */ - console_find_owner(); + console_init_owner(); } int __init console_has(const char *device) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 05:01:52 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 05:01:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849798.1264355 (Exim 4.92) (envelope-from ) id 1tJQTQ-0003bQ-0r; Fri, 06 Dec 2024 05:01:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849798.1264355; Fri, 06 Dec 2024 05:01:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJQTP-0003bJ-Tq; Fri, 06 Dec 2024 05:01:51 +0000 Received: by outflank-mailman (input) for mailman id 849798; Fri, 06 Dec 2024 05:01: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 1tJQA9-0004Ka-No for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 04:41:57 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 64608fcb-b38c-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 05:41:44 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id C8AC75C72FD; Fri, 6 Dec 2024 04:40:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 6A760C4CEE0; Fri, 6 Dec 2024 04:41:39 +0000 (UTC) Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 62D13E77179; Fri, 6 Dec 2024 04:41: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: 64608fcb-b38c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733460099; bh=JVQCV0PI1+svIuRPhSKIXE4RQ76vQm0E6vam6EPtrcY=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=W6lEgWydg2RAPebKAr16/tct2cGa72FS3Sam7Hdj1prK15nvWBh/GwfZ1GeWPxh7o b/M9RtuoMe+3OCo21F1efsSdMhKQxJlijnUvu5Uy0OAU9Gnt6jx+Q+jjs4pliIanGg RmCWD3kYhgZREq3GlEwSwSFDmaGNk4WsW2t3XC+CFKcs07uscaRG3/uh/WnpQL25cu 5BCgiNcqlb9vrr4aLImKUG7Pd4CehQqXhcBOZuei/WAymH78qrNNQ9rb1tSL9+W+2Y cLel7bfYxe+/5oNf7+TBJVZ9lN60RnD6b6xvEJ3f5pE5+6XZ5/8Z/5L6l9AKHx+UEp 5q+znPHry/3FQ== From: Denis Mukhin via B4 Relay Date: Thu, 05 Dec 2024 20:42:02 -0800 Subject: [PATCH v2 32/35] x86/hvm: add debugging facility to NS8250 UART emulator MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20241205-vuart-ns8250-v1-32-e9aa923127eb@ford.com> References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> To: xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Denis Mukhin X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1733460095; l=5202; i=dmukhin@ford.com; s=20241125; h=from:subject:message-id; bh=fA/jJbL46n/cnt80o0lruMDE2CrX4KhOfstGR8R1g3U=; b=iKpHnHA52J7NwfZnAJaaYuYval44oMyAoTpLRR63oT969Q6ILWC0DwKXqePHb5y1UuvSLSiJD tf8/iPi9W0YBRYqrwgNGNpvlhNKnoHkaE//16iIF3La5S0GB4zMmWcD X-Developer-Key: i=dmukhin@ford.com; a=ed25519; pk=SsDZ9p39s0fqcpUKQuqKqrbn0rq6EtEAClvpOpzx6+U= X-Endpoint-Received: by B4 Relay for dmukhin@ford.com/20241125 with auth_id=287 X-Original-From: Denis Mukhin Reply-To: dmukhin@ford.com From: Denis Mukhin Enable keyhandler mechanism for dumping state of emulated NS8250 on the console. Signed-off-by: Denis Mukhin --- xen/arch/x86/hvm/vuart_ns8250.c | 122 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 122 insertions(+) diff --git a/xen/arch/x86/hvm/vuart_ns8250.c b/xen/arch/x86/hvm/vuart_ns8250.c index 779dbd80d7be4e070ea9df3ae736ecdc662a527a..c8c75afaf2b2419d1dae999da1d1e400fd367791 100644 --- a/xen/arch/x86/hvm/vuart_ns8250.c +++ b/xen/arch/x86/hvm/vuart_ns8250.c @@ -25,6 +25,7 @@ /* Development debugging */ #define NS8250_LOG_LEVEL 0 +#undef NS8250_DEBUG #include #include @@ -35,6 +36,9 @@ #include #include #include +#if defined(NS8250_DEBUG) +#include +#endif #include /* console_input_domid() */ #include /* max_init_domid */ #include @@ -625,6 +629,121 @@ static const char *ns8250_regname( return reg_names[reg][dir]; } +#if defined(NS8250_DEBUG) +static void ns8250_dump(struct vuart_ns8250 *vdev) +{ + struct xencons_interface *cons = vdev->cons; + uint8_t val; + + printk("I/O port %02"PRIx64" IRQ %d flags %"PRIx32" owner %d\n", + vdev->io_addr, vdev->irq, + vdev->flags, vdev->owner->domain_id); + + printk("RX size %ld in_prod %d in_cons %d used %d\n", + sizeof(cons->in), + cons->in_prod, cons->in_cons, + cons->in_prod - cons->in_cons); + + printk("TX size %ld out_prod %d out_cons %d used %d\n", + sizeof(cons->out), + cons->out_prod, cons->out_cons, + cons->out_prod - cons->out_cons); + + printk("%02x RBR [ %c ] THR [ %c ] DLL %02x DLM %02x\n", + UART_RBR, + cons->in[MASK_XENCONS_IDX(cons->in_prod, cons)], + cons->out[MASK_XENCONS_IDX(cons->out_prod, cons)], + vdev->dl & 0xFFU, vdev->dl >> 8); + + printk("%02"PRIx8" IER %02"PRIx8"\n", UART_IER, vdev->regs[UART_IER]); + + val = (vdev->regs[UART_FCR] & UART_FCR_ENABLE) ? UART_IIR_FE_MASK : 0; + val |= ns8250_irq_reason(vdev); + printk("%02"PRIx8" FCR %02"PRIx8" IIR %02"PRIx8"\n", + UART_FCR, vdev->regs[UART_FCR], val); + + printk("%02"PRIx8" LCR %02"PRIx8"\n", UART_LCR, vdev->regs[UART_LCR]); + printk("%02"PRIx8" MCR %02"PRIx8"\n", UART_MCR, vdev->regs[UART_MCR]); + printk("%02"PRIx8" LSR %02"PRIx8"\n", UART_LSR, vdev->regs[UART_LSR]); + printk("%02"PRIx8" MSR %02"PRIx8"\n", UART_MSR, vdev->regs[UART_MSR]); +} + +static struct domain *rcu_find_first_domain_with_vuart(void) +{ + struct domain *d = NULL; + domid_t i; + + for ( i = 0; i < max_init_domid + 1; i++ ) + { + d = rcu_lock_domain_by_id(i); + if ( d == NULL ) + continue; + + if ( domain_has_vuart(d) ) + break; + + rcu_unlock_domain(d); + } + + return d; +} + +static void cf_check ns8250_keyhandler_show(unsigned char key) +{ + struct vuart_ns8250 *vdev; + struct domain *d; + + d = rcu_find_first_domain_with_vuart(); + if ( d == NULL ) + return; + + printk("'%c' pressed -> dumping virtual NS8250 state (d%d)\n", + key, d->domain_id); + + vdev = &d->arch.hvm.vuart; + spin_lock(&vdev->lock); + ns8250_dump(vdev); + spin_unlock(&vdev->lock); + + rcu_unlock_domain(d); +} + +static void cf_check ns8250_keyhandler_irq(unsigned char key) +{ + struct vuart_ns8250 *vdev; + struct domain *d; + + d = rcu_find_first_domain_with_vuart(); + if ( d == NULL ) + return; + + printk("'%c' pressed -> triggering IRQ on virtual NS8250 (d%d)\n", + key, d->domain_id); + + vdev = &d->arch.hvm.vuart; + spin_lock(&vdev->lock); + ns8250_irq_assert(vdev); + spin_unlock(&vdev->lock); + + rcu_unlock_domain(d); +} + +static void ns8250_keyhandler_init(void) +{ + register_keyhandler('1', ns8250_keyhandler_show, + "dump virtual NS8250 state", 0); + register_keyhandler('2', ns8250_keyhandler_irq, + "trigger IRQ from virtual NS8250", 0); +} +#else +static inline void ns8250_keyhandler_init(void) +{ +} +static inline void ns8250_dump(struct vuart_ns8250 *vdev) +{ +} +#endif /* #if defined(NS8250_DEBUG) */ + /* * Emulate I/O access to NS8250 register. */ @@ -688,6 +807,7 @@ static int cf_check ns8250_io_handle( rc = X86EMUL_OKAY; out: + ns8250_dump(vdev); spin_unlock(&vdev->lock); return rc; @@ -786,6 +906,7 @@ static int ns8250_init(struct domain *d, const struct resource *r) } spin_lock_init(&vdev->lock); + ns8250_keyhandler_init(); hvm_irq_lower(d, vdev->irq); vdev->dl = (UART_CLOCK_HZ / 115200) >> 4; /* Report 115200 baud rate */ @@ -852,6 +973,7 @@ int vuart_putchar(struct vuart_ns8250 *vdev, char ch) ns8250_irq_assert(vdev); out: + ns8250_dump(vdev); spin_unlock(&vdev->lock); return rc; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 07:59:31 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 07:59:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849894.1264391 (Exim 4.92) (envelope-from ) id 1tJTF0-0008VO-Ov; Fri, 06 Dec 2024 07:59:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849894.1264391; Fri, 06 Dec 2024 07:59: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 1tJTF0-0008VH-LQ; Fri, 06 Dec 2024 07:59:10 +0000 Received: by outflank-mailman (input) for mailman id 849894; Fri, 06 Dec 2024 07:59: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 1tJTEy-0008VB-Eo for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 07:59:08 +0000 Received: from mail-oa1-x36.google.com (mail-oa1-x36.google.com [2001:4860:4864:20::36]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f73ed596-b3a7-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 08:59:06 +0100 (CET) Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-29654932226so948179fac.0 for ; Thu, 05 Dec 2024 23:59: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: f73ed596-b3a7-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1733471945; x=1734076745; 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=0YvyLJeFTkW8Aygi/0tkmgWGqrDPo/MIJUCL1hTOEp4=; b=rAzihSnp0/vSB5EvufSsBOFR1UHTS7YWdmuLBCcGuDwq89K4+Ib20+5kmbkEhUbedr 5so2nQjSF/Iy3+nv+HKjB87xpWUoeTSZnBH0yWELE3wRznIDwrXFkWx+VEHTHu+iaY2v rUXNchjsUYgssSIUhhcCdHiL+UV4F4OQbKAt/iR/90qWk6/Df6d7Na+KENnVLlwGbnBG 3ZbVIGMwzapGB7BGLjVXkkEqpWmbulhaZ5x7rSbOHSqZgi1bMHkGzBZzC8MNJrN6R69o 6FOEpNfmxLoOSRDWOEz4T0TdCKYecDLEVAhjC41JaX4qertE4bU0PfQOd+2UNXfJW0H2 YvJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733471945; x=1734076745; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0YvyLJeFTkW8Aygi/0tkmgWGqrDPo/MIJUCL1hTOEp4=; b=c0po40G6Eom9ZYwAe4tnUmCuYVxioyN7dGx45c+9JnaUfIqw9zOsxpze2GmtIEmI+u Di6C+91wcbz1h/g27T+NmHE+HuMwLeVuBoUJT1AeRaIJsmGOhH8QPVxDK61ti91n3e5R yOeakvdMlF6exLOjmWNUW3oTwafkM3pqYChTTcl1+hx8XVdPqqpUB7XQO3Rwv0L59qkP yNGZiV1hiAuDfH5ATzElA0bpDTYghH8oZ8PHupJB3kpQMV1jTcG6+Ow1xrA6EewDr5QE d9MAa2Y3prFp1vvrdRjNKg9JeYXTPV5OgBqPLT9pHX40tzMrOcKSNTrl0ROUZ3U2TKJJ zOUA== X-Gm-Message-State: AOJu0YxA6JizPeXGZR5BRzCsUfy+C5bIIQBpaMkUun0pu2ZK0+Hh+cI/ d+R1hMhlbLvJhuIX3iiwvrKYrZanbLKp0GZMheH6PEOXF5QHOvgC8gJ3Bf4IAwQBJjVvoS2DXcs 1PiZ7Aw142HWoexZCaxGXMDHxP9DNUPjcfh0XGQ== X-Gm-Gg: ASbGncvGi0rz515l7IzVEME+OaMRG0I1WzyIINDte+TDIOHzWsnlqT4gbzLZg7Q9aEk sF27x1QAqJ+/ZMG2M2mwEi9vYd0zsR+k= X-Google-Smtp-Source: AGHT+IGJS06Sp7PkFKH5KQuNr7udauDoCCdoIQ3OHtZZx84DAz8pszc/pFC30spqW8H0RfwrZfk5ibvtIhgdcr8710U= X-Received: by 2002:a05:6870:1f19:b0:29d:caa2:f0ef with SMTP id 586e51a60fabf-29f71b3ffa2mr1279752fac.6.1733471945379; Thu, 05 Dec 2024 23:59:05 -0800 (PST) MIME-Version: 1.0 References: <56217f2f7b4c29a5f84fb02de3f4cbb8342c5560.1732702210.git.bertrand.marquis@arm.com> In-Reply-To: <56217f2f7b4c29a5f84fb02de3f4cbb8342c5560.1732702210.git.bertrand.marquis@arm.com> From: Jens Wiklander Date: Fri, 6 Dec 2024 08:58:53 +0100 Message-ID: Subject: Re: [PATCH v3 07/10] xen/arm: ffa: Transmit RXTX buffers to the SPMC 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, Nov 27, 2024 at 5:08=E2=80=AFPM Bertrand Marquis wrote: > > When an RXTX buffer is mapped by a VM transmit it to the SPMC when it > supports RX_ACQUIRE. > As a consequence of that, we must acquire the RX buffer of a VM from the > SPMC when we want to use it: > - create a generic acquire and release function to get the rx buffer of > a VM which gets it from the SPMC when supported > - rename the rx_acquire to hyp_rx_acquire to remove confusion > - rework the rx_lock to only lock access to rx_is_free and only allow > usage of the rx buffer to one who managed to acquire it, thus removing > the trylock and returning busy if rx_is_free is false > > As part of this change move some structure definition to ffa_private > from ffa_shm as those are need for the MAP call with the SPMC. > > While there also fix ffa_handle_rxtx_map which was testing the wrong > variable after getting the page for the rx buffer, testing tx_pg > instead of rx_pg. > > Fixes: be75f686eb03 ("xen/arm: ffa: separate rxtx buffer routines") > > Signed-off-by: Bertrand Marquis > --- > Changes in v3: > - add a comment to explain why we only release the RX buffer if an error > occurs during partition_info_get > - fix the BUILD_BUG_ON check for TX buffer size in rxtx_map (coding > style and use PAGE_SIZE * NUM_PAGE) > - remove invalid 3 argument to ffa_rxtx_map when forwarding the call to > the SPMC > - fix bug in ffa_handle_rxtx_map testing wrong variable > Changes in v2: > - unmap VM rxtx buffer in SPMC on unmap call or on VM destroy > - rework the unmap call to the SPMC to properly pass the VM ID > --- > xen/arch/arm/tee/ffa.c | 2 +- > xen/arch/arm/tee/ffa_partinfo.c | 36 ++++--- > xen/arch/arm/tee/ffa_private.h | 22 ++++- > xen/arch/arm/tee/ffa_rxtx.c | 161 ++++++++++++++++++++++++++------ > xen/arch/arm/tee/ffa_shm.c | 15 --- > 5 files changed, 170 insertions(+), 66 deletions(-) > > diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c > index 0026ac9134ad..bc2722d53fd7 100644 > --- a/xen/arch/arm/tee/ffa.c > +++ b/xen/arch/arm/tee/ffa.c > @@ -347,7 +347,7 @@ static bool ffa_handle_call(struct cpu_user_regs *reg= s) > ffa_handle_partition_info_get(regs); > return true; > case FFA_RX_RELEASE: > - e =3D ffa_handle_rx_release(); > + e =3D ffa_rx_release(d); > break; > case FFA_MSG_SEND_DIRECT_REQ_32: > case FFA_MSG_SEND_DIRECT_REQ_64: > diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_parti= nfo.c > index 74324e1d9d3f..939ed49dd3da 100644 > --- a/xen/arch/arm/tee/ffa_partinfo.c > +++ b/xen/arch/arm/tee/ffa_partinfo.c > @@ -121,11 +121,9 @@ void ffa_handle_partition_info_get(struct cpu_user_r= egs *regs) > goto out; > } > > - if ( !spin_trylock(&ctx->rx_lock) ) > - { > - ret =3D FFA_RET_BUSY; > + ret =3D ffa_rx_acquire(d); > + if ( ret !=3D FFA_RET_OK ) > goto out; > - } > > dst_buf =3D ctx->rx; > > @@ -135,22 +133,16 @@ void ffa_handle_partition_info_get(struct cpu_user_= regs *regs) > goto out_rx_release; > } > > - if ( !ctx->page_count || !ctx->rx_is_free ) > - { > - ret =3D FFA_RET_DENIED; > - goto out_rx_release; > - } > - > spin_lock(&ffa_rx_buffer_lock); > > ret =3D ffa_partition_info_get(uuid, 0, &ffa_sp_count, &src_size); > > if ( ret ) > - goto out_rx_buf_unlock; > + goto out_rx_hyp_unlock; > > /* > * ffa_partition_info_get() succeeded so we now own the RX buffer we > - * share with the SPMC. We must give it back using ffa_rx_release() > + * share with the SPMC. We must give it back using ffa_hyp_rx_releas= e() > * once we've copied the content. > */ > > @@ -190,15 +182,20 @@ void ffa_handle_partition_info_get(struct cpu_user_= regs *regs) > } > } > > - ctx->rx_is_free =3D false; > - > out_rx_hyp_release: > - ffa_rx_release(); > -out_rx_buf_unlock: > + ffa_hyp_rx_release(); > +out_rx_hyp_unlock: > spin_unlock(&ffa_rx_buffer_lock); > out_rx_release: > - spin_unlock(&ctx->rx_lock); > - > + /* > + * The calling VM RX buffer only contains data to be used by the VM = if the > + * call was successfull, in which case the VM has to release the buf= fer successful > + * once it has used the data. > + * If something went wrong during the call, we have to release the R= X > + * buffer back to the SPMC as the VM will not do it. > + */ > + if ( ret !=3D FFA_RET_OK ) > + ffa_rx_release(d); > out: > if ( ret ) > ffa_set_regs_error(regs, ret); > @@ -365,8 +362,7 @@ bool ffa_partinfo_init(void) > ret =3D init_subscribers(count, fpi_size); > > out: > - ffa_rx_release(); > - > + ffa_hyp_rx_release(); > return ret; > } > > diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_privat= e.h > index afe69b43dbef..9adfe687c3c9 100644 > --- a/xen/arch/arm/tee/ffa_private.h > +++ b/xen/arch/arm/tee/ffa_private.h > @@ -265,6 +265,21 @@ > #define FFA_ABI_BITNUM(id) ((FFA_ABI_ID(id) - FFA_ABI_MIN) << 1 | \ > FFA_ABI_CONV(id)) > > +/* Constituent memory region descriptor */ > +struct ffa_address_range { > + uint64_t address; > + uint32_t page_count; > + uint32_t reserved; > +}; > + > +/* Composite memory region descriptor */ > +struct ffa_mem_region { > + uint32_t total_page_count; > + uint32_t address_range_count; > + uint64_t reserved; > + struct ffa_address_range address_range_array[]; > +}; > + > struct ffa_ctx_notif { > bool enabled; > > @@ -292,7 +307,7 @@ struct ffa_ctx { > struct ffa_ctx_notif notif; > /* > * tx_lock is used to serialize access to tx > - * rx_lock is used to serialize access to rx > + * rx_lock is used to serialize access to rx_is_free > * lock is used for the rest in this struct > */ > spinlock_t tx_lock; > @@ -331,7 +346,8 @@ void ffa_rxtx_domain_destroy(struct domain *d); > uint32_t ffa_handle_rxtx_map(uint32_t fid, register_t tx_addr, > register_t rx_addr, uint32_t page_count); > uint32_t ffa_handle_rxtx_unmap(void); > -int32_t ffa_handle_rx_release(void); > +int32_t ffa_rx_acquire(struct domain *d); > +int32_t ffa_rx_release(struct domain *d); > > void ffa_notif_init(void); > void ffa_notif_init_interrupt(void); > @@ -420,7 +436,7 @@ static inline int32_t ffa_simple_call(uint32_t fid, r= egister_t a1, > return ffa_get_ret_code(&resp); > } > > -static inline int32_t ffa_rx_release(void) > +static inline int32_t ffa_hyp_rx_release(void) > { > return ffa_simple_call(FFA_RX_RELEASE, 0, 0, 0, 0); > } > diff --git a/xen/arch/arm/tee/ffa_rxtx.c b/xen/arch/arm/tee/ffa_rxtx.c > index 132a7982407b..e1cab7fa5e46 100644 > --- a/xen/arch/arm/tee/ffa_rxtx.c > +++ b/xen/arch/arm/tee/ffa_rxtx.c > @@ -30,6 +30,17 @@ struct ffa_endpoint_rxtx_descriptor_1_1 { > uint32_t tx_region_offs; > }; > > +static int32_t ffa_rxtx_map(paddr_t tx_addr, paddr_t rx_addr, > + uint32_t page_count) > +{ > + return ffa_simple_call(FFA_RXTX_MAP_64, tx_addr, rx_addr, page_count= , 0); > +} > + > +static int32_t ffa_rxtx_unmap(uint16_t id) > +{ > + return ffa_simple_call(FFA_RXTX_UNMAP, ((uint64_t)id)<<16, 0, 0, 0); Please add a space before and after the "<<" operator. Cheers, Jens > +} > + > uint32_t ffa_handle_rxtx_map(uint32_t fid, register_t tx_addr, > register_t rx_addr, uint32_t page_count) > { > @@ -42,6 +53,9 @@ uint32_t ffa_handle_rxtx_map(uint32_t fid, register_t t= x_addr, > void *rx; > void *tx; > > + /* The code is considering that we only get one page for now */ > + BUILD_BUG_ON(FFA_MAX_RXTX_PAGE_COUNT !=3D 1); > + > if ( !smccc_is_conv_64(fid) ) > { > /* > @@ -72,7 +86,7 @@ uint32_t ffa_handle_rxtx_map(uint32_t fid, register_t t= x_addr, > goto err_put_tx_pg; > > rx_pg =3D get_page_from_gfn(d, gfn_x(gaddr_to_gfn(rx_addr)), &t, P2M= _ALLOC); > - if ( !tx_pg ) > + if ( !rx_pg ) > goto err_put_tx_pg; > > /* Only normal RW RAM for now */ > @@ -87,6 +101,66 @@ uint32_t ffa_handle_rxtx_map(uint32_t fid, register_t= tx_addr, > if ( !rx ) > goto err_unmap_tx; > > + /* > + * Transmit the RX/TX buffer information to the SPM if acquire is su= pported > + * as the spec says that if not there is not need to acquire/release= /map > + * rxtx buffers from the SPMC > + */ > + if ( ffa_fw_supports_fid(FFA_RX_ACQUIRE) ) > + { > + struct ffa_endpoint_rxtx_descriptor_1_1 *rxtx_desc; > + struct ffa_mem_region *mem_reg; > + > + /* All must fit in our TX buffer */ > + BUILD_BUG_ON(sizeof(*rxtx_desc) + sizeof(*mem_reg) * 2 + > + sizeof(struct ffa_address_range) * 2 > > + FFA_MAX_RXTX_PAGE_COUNT * FFA_PAGE_SIZE); > + > + spin_lock(&ffa_tx_buffer_lock); > + rxtx_desc =3D ffa_tx; > + > + /* > + * We have only one page for each so we pack everything: > + * - rx region descriptor > + * - rx region range > + * - tx region descriptor > + * - tx region range > + */ > + rxtx_desc->sender_id =3D ffa_get_vm_id(d); > + rxtx_desc->reserved =3D 0; > + rxtx_desc->rx_region_offs =3D sizeof(*rxtx_desc); > + rxtx_desc->tx_region_offs =3D sizeof(*rxtx_desc) + > + offsetof(struct ffa_mem_region, > + address_range_array[1]); > + > + /* rx buffer */ > + mem_reg =3D ffa_tx + sizeof(*rxtx_desc); > + mem_reg->total_page_count =3D 1; > + mem_reg->address_range_count =3D 1; > + mem_reg->reserved =3D 0; > + > + mem_reg->address_range_array[0].address =3D page_to_maddr(rx_pg)= ; > + mem_reg->address_range_array[0].page_count =3D 1; > + mem_reg->address_range_array[0].reserved =3D 0; > + > + /* tx buffer */ > + mem_reg =3D ffa_tx + rxtx_desc->tx_region_offs; > + mem_reg->total_page_count =3D 1; > + mem_reg->address_range_count =3D 1; > + mem_reg->reserved =3D 0; > + > + mem_reg->address_range_array[0].address =3D page_to_maddr(tx_pg)= ; > + mem_reg->address_range_array[0].page_count =3D 1; > + mem_reg->address_range_array[0].reserved =3D 0; > + > + ret =3D ffa_rxtx_map(0, 0, 0); > + > + spin_unlock(&ffa_tx_buffer_lock); > + > + if ( ret !=3D FFA_RET_OK ) > + goto err_unmap_rx; > + } > + > ctx->rx =3D rx; > ctx->tx =3D tx; > ctx->rx_pg =3D rx_pg; > @@ -95,6 +169,8 @@ uint32_t ffa_handle_rxtx_map(uint32_t fid, register_t = tx_addr, > ctx->rx_is_free =3D true; > return FFA_RET_OK; > > +err_unmap_rx: > + unmap_domain_page_global(rx); > err_unmap_tx: > unmap_domain_page_global(tx); > err_put_rx_pg: > @@ -105,8 +181,22 @@ err_put_tx_pg: > return ret; > } > > -static void rxtx_unmap(struct ffa_ctx *ctx) > +static uint32_t rxtx_unmap(struct domain *d) > { > + struct ffa_ctx *ctx =3D d->arch.tee; > + > + if ( !ctx->page_count ) > + return FFA_RET_INVALID_PARAMETERS; > + > + if ( ffa_fw_supports_fid(FFA_RX_ACQUIRE) ) > + { > + uint32_t ret; > + > + ret =3D ffa_rxtx_unmap(ffa_get_vm_id(d)); > + if ( ret !=3D FFA_RET_OK ) > + return ret; > + } > + > unmap_domain_page_global(ctx->rx); > unmap_domain_page_global(ctx->tx); > put_page(ctx->rx_pg); > @@ -117,32 +207,63 @@ static void rxtx_unmap(struct ffa_ctx *ctx) > ctx->tx_pg =3D NULL; > ctx->page_count =3D 0; > ctx->rx_is_free =3D false; > + > + return FFA_RET_OK; > } > > uint32_t ffa_handle_rxtx_unmap(void) > { > - struct domain *d =3D current->domain; > + return rxtx_unmap(current->domain); > +} > + > +int32_t ffa_rx_acquire(struct domain *d) > +{ > + int32_t ret =3D FFA_RET_OK; > struct ffa_ctx *ctx =3D d->arch.tee; > > - if ( !ctx->rx ) > - return FFA_RET_INVALID_PARAMETERS; > + spin_lock(&ctx->rx_lock); > > - rxtx_unmap(ctx); > + if ( !ctx->page_count ) > + { > + ret =3D FFA_RET_DENIED; > + goto out; > + } > > - return FFA_RET_OK; > + if ( !ctx->rx_is_free ) > + { > + ret =3D FFA_RET_BUSY; > + goto out; > + } > + > + if ( ffa_fw_supports_fid(FFA_RX_ACQUIRE) ) > + { > + ret =3D ffa_simple_call(FFA_RX_ACQUIRE, ffa_get_vm_id(d), 0, 0, = 0); > + if ( ret !=3D FFA_RET_OK ) > + goto out; > + } > + ctx->rx_is_free =3D false; > +out: > + spin_unlock(&ctx->rx_lock); > + > + return ret; > } > > -int32_t ffa_handle_rx_release(void) > +int32_t ffa_rx_release(struct domain *d) > { > int32_t ret =3D FFA_RET_DENIED; > - struct domain *d =3D current->domain; > struct ffa_ctx *ctx =3D d->arch.tee; > > - if ( !spin_trylock(&ctx->rx_lock) ) > - return FFA_RET_BUSY; > + spin_lock(&ctx->rx_lock); > > if ( !ctx->page_count || ctx->rx_is_free ) > goto out; > + > + if ( ffa_fw_supports_fid(FFA_RX_ACQUIRE) ) > + { > + ret =3D ffa_simple_call(FFA_RX_RELEASE, ffa_get_vm_id(d), 0, 0, = 0); > + if ( ret !=3D FFA_RET_OK ) > + goto out; > + } > ret =3D FFA_RET_OK; > ctx->rx_is_free =3D true; > out: > @@ -151,23 +272,9 @@ out: > return ret; > } > > -static int32_t ffa_rxtx_map(paddr_t tx_addr, paddr_t rx_addr, > - uint32_t page_count) > -{ > - return ffa_simple_call(FFA_RXTX_MAP_64, tx_addr, rx_addr, page_count= , 0); > -} > - > -static int32_t ffa_rxtx_unmap(void) > -{ > - return ffa_simple_call(FFA_RXTX_UNMAP, 0, 0, 0, 0); > -} > - > void ffa_rxtx_domain_destroy(struct domain *d) > { > - struct ffa_ctx *ctx =3D d->arch.tee; > - > - if ( ctx->rx ) > - rxtx_unmap(ctx); > + rxtx_unmap(d); > } > > void ffa_rxtx_destroy(void) > @@ -186,7 +293,7 @@ void ffa_rxtx_destroy(void) > } > > if ( need_unmap ) > - ffa_rxtx_unmap(); > + ffa_rxtx_unmap(0); > } > > bool ffa_rxtx_init(void) > diff --git a/xen/arch/arm/tee/ffa_shm.c b/xen/arch/arm/tee/ffa_shm.c > index 29675f9ba3f7..d628c1b70609 100644 > --- a/xen/arch/arm/tee/ffa_shm.c > +++ b/xen/arch/arm/tee/ffa_shm.c > @@ -16,21 +16,6 @@ > > #include "ffa_private.h" > > -/* Constituent memory region descriptor */ > -struct ffa_address_range { > - uint64_t address; > - uint32_t page_count; > - uint32_t reserved; > -}; > - > -/* Composite memory region descriptor */ > -struct ffa_mem_region { > - uint32_t total_page_count; > - uint32_t address_range_count; > - uint64_t reserved; > - struct ffa_address_range address_range_array[]; > -}; > - > /* Memory access permissions descriptor */ > struct ffa_mem_access_perm { > uint16_t endpoint_id; > -- > 2.47.0 > From xen-devel-bounces@lists.xenproject.org Fri Dec 06 08:03:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 08:03:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849909.1264401 (Exim 4.92) (envelope-from ) id 1tJTJH-0003YR-GG; Fri, 06 Dec 2024 08:03:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849909.1264401; Fri, 06 Dec 2024 08:03:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJTJH-0003YK-DS; Fri, 06 Dec 2024 08:03:35 +0000 Received: by outflank-mailman (input) for mailman id 849909; Fri, 06 Dec 2024 08:03: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 1tJTJG-0003YE-6G for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 08:03:34 +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 9230b1c9-b3a8-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 09:03:26 +0100 (CET) Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-29e579b9e9aso1206089fac.1 for ; Fri, 06 Dec 2024 00:03: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: 9230b1c9-b3a8-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1733472211; x=1734077011; 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=s9WuLxGnWqMHLUGy8xvZb0nPWni3GmQT6rbbqKA64U4=; b=um4u6IW8ByoP7nQL7M/Q5ouK7EqHFVUdEFPCN5q807RKOSzmssMqOFKktDQy6GBQEa 6PoQheYZb8Fcdjsrrr3jghKoGNnHexwHiOedWjzxbObiI9RQ9VqvcIJDL6+HAz9p4cRQ GpsJtXlyw22wzlxsZ2gPNg37dhdpeli3uXiA2xy9Nd1SNHS24wYRiZuqV4q5AXAopm82 aZMOq+WCabO65KoN3pJPcyfjYOqP8KT9fofodRYM44K6yP9Hyl+u2tSP+0JhmsxelDmQ u7vGD4u76hsKMwvk5Xz0zUpL7GUDnCjQP/ofTbc000hRjKT7kdCDvrAsIx4Z6FUcspg+ Jiuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733472211; x=1734077011; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=s9WuLxGnWqMHLUGy8xvZb0nPWni3GmQT6rbbqKA64U4=; b=djicUkPrzvbUYBzyZ2ncf9INLpyDTYq7JNG+JaNklS+dq2ctIJEDrabXgILahuTm1U BpZJXyhl8f4hcNp5a5ogsni7I3f7VCdkT7HjCNuC8jIUera4i7j0IQtVES1/i8p12OvS Ppzmy2HalsW4vjrAPpRuCYhUfdoOA1UXzbeNxEXcfAVMtNkcoh2wnNX0KrFr3rW9GaPf iNRX9tf0rzDu8/tt+7sUtAiBc/el7qeo0gynJlzdV5Afhr4BLHzD2WQWPQ+kEdE5SMLy tBX/99TtAy+jULAyP6JxxFGc8SPocPMl4uaPBpW/FgB0X4U57/dLhkv5fFPSlPg3wuid LaVg== X-Gm-Message-State: AOJu0YwUD2Zw0rG6okNLvNHsI3yvaC4DgZY/e5NzMajh0pAeQXLsE/3n PC2a0na1hf1rabKjG1NDePSJKeTRRxRyi50Ba0sFMpo0X1G97nJz5u2qk3cs/86iaT4JTqjUZ1z 68PbkYu0B47XRWk0cqp6Fp0mG3I4mrP8TJ3j48A== X-Gm-Gg: ASbGncv8hTfDEBP9Okc2rX2EGTDwsbkO6fDPd80agvi9gFyz3DpRP+N6q8ijdocQF+y 5AloN0EHEhTUl83qV3YQKFSsLw55Riy4= X-Google-Smtp-Source: AGHT+IEgHiObddcPtWJDCxFRQKMn4ZhJ25QMJAGBycxoGu2L94bXA4h7XwT+vwq4XzbGk+lUkklJCItE1LvtnXjx4vA= X-Received: by 2002:a05:6870:e97:b0:29e:5897:e9ed with SMTP id 586e51a60fabf-29f7355f123mr2193325fac.35.1733472210972; Fri, 06 Dec 2024 00:03:30 -0800 (PST) MIME-Version: 1.0 References: <8e7cf913eeba955f8ed6bced1cafdf264dcb4318.1732702210.git.bertrand.marquis@arm.com> In-Reply-To: <8e7cf913eeba955f8ed6bced1cafdf264dcb4318.1732702210.git.bertrand.marquis@arm.com> From: Jens Wiklander Date: Fri, 6 Dec 2024 09:03:19 +0100 Message-ID: Subject: Re: [PATCH v3 09/10] xen/arm: ffa: Remove per VM notif_enabled 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, Nov 27, 2024 at 5:08=E2=80=AFPM Bertrand Marquis wrote: > > Remove the per VM flag to store if notifications are enabled or not as > the only case where they are not, if notifications are enabled globally, > will make the VM creation fail. > Also use the opportunity to always give the notifications interrupts IDs > to VM. If the firmware does not support notifications, there won't be > any generated and setting one will give back a NOT_SUPPORTED. > > Signed-off-by: Bertrand Marquis > --- > Changes in v3: > - Add a comment explaining why it is ok to call bitmap destroy even if > bitmap create failed. > Changes in v2: > - rebase > --- > xen/arch/arm/tee/ffa.c | 17 +++-------------- > xen/arch/arm/tee/ffa_notif.c | 14 +++++--------- > xen/arch/arm/tee/ffa_private.h | 2 -- > 3 files changed, 8 insertions(+), 25 deletions(-) Looks good. Reviewed-by: Jens Wiklander Cheers, Jens > > diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c > index 8488fe6af9c0..04d2403415fe 100644 > --- a/xen/arch/arm/tee/ffa.c > +++ b/xen/arch/arm/tee/ffa.c > @@ -169,8 +169,6 @@ static void handle_version(struct cpu_user_regs *regs= ) > > static void handle_features(struct cpu_user_regs *regs) > { > - struct domain *d =3D current->domain; > - struct ffa_ctx *ctx =3D d->arch.tee; > uint32_t a1 =3D get_user_reg(regs, 1); > unsigned int n; > > @@ -218,16 +216,10 @@ static void handle_features(struct cpu_user_regs *r= egs) > ffa_set_regs_success(regs, 0, 0); > break; > case FFA_FEATURE_NOTIF_PEND_INTR: > - if ( ctx->notif.enabled ) > - ffa_set_regs_success(regs, GUEST_FFA_NOTIF_PEND_INTR_ID, 0); > - else > - ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED); > + ffa_set_regs_success(regs, GUEST_FFA_NOTIF_PEND_INTR_ID, 0); > break; > case FFA_FEATURE_SCHEDULE_RECV_INTR: > - if ( ctx->notif.enabled ) > - ffa_set_regs_success(regs, GUEST_FFA_SCHEDULE_RECV_INTR_ID, = 0); > - else > - ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED); > + ffa_set_regs_success(regs, GUEST_FFA_SCHEDULE_RECV_INTR_ID, 0); > break; > > case FFA_NOTIFICATION_BIND: > @@ -236,10 +228,7 @@ static void handle_features(struct cpu_user_regs *re= gs) > case FFA_NOTIFICATION_SET: > case FFA_NOTIFICATION_INFO_GET_32: > case FFA_NOTIFICATION_INFO_GET_64: > - if ( ctx->notif.enabled ) > - ffa_set_regs_success(regs, 0, 0); > - else > - ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED); > + ffa_set_regs_success(regs, 0, 0); > break; > default: > ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED); > diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c > index 4b3e46318f4b..21b9e78f6399 100644 > --- a/xen/arch/arm/tee/ffa_notif.c > +++ b/xen/arch/arm/tee/ffa_notif.c > @@ -405,7 +405,6 @@ void ffa_notif_init(void) > > int ffa_notif_domain_init(struct domain *d) > { > - struct ffa_ctx *ctx =3D d->arch.tee; > int32_t res; > > if ( !notif_enabled ) > @@ -415,18 +414,15 @@ int ffa_notif_domain_init(struct domain *d) > if ( res ) > return -ENOMEM; > > - ctx->notif.enabled =3D true; > - > return 0; > } > > void ffa_notif_domain_destroy(struct domain *d) > { > - struct ffa_ctx *ctx =3D d->arch.tee; > - > - if ( ctx->notif.enabled ) > - { > + /* > + * Call bitmap_destroy even if bitmap create failed as the SPMC will > + * return a DENIED error that we will ignore. > + */ > + if ( notif_enabled ) > ffa_notification_bitmap_destroy(ffa_get_vm_id(d)); > - ctx->notif.enabled =3D false; > - } > } > diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_privat= e.h > index 02162e0ee4c7..973ee55be09b 100644 > --- a/xen/arch/arm/tee/ffa_private.h > +++ b/xen/arch/arm/tee/ffa_private.h > @@ -281,8 +281,6 @@ struct ffa_mem_region { > }; > > struct ffa_ctx_notif { > - bool enabled; > - > /* > * True if domain is reported by FFA_NOTIFICATION_INFO_GET to have > * pending global notifications. > -- > 2.47.0 > From xen-devel-bounces@lists.xenproject.org Fri Dec 06 08:09:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 08:09:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849920.1264411 (Exim 4.92) (envelope-from ) id 1tJTOZ-0004AP-2G; Fri, 06 Dec 2024 08:09:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849920.1264411; Fri, 06 Dec 2024 08:09:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJTOY-0004AI-Va; Fri, 06 Dec 2024 08:09:02 +0000 Received: by outflank-mailman (input) for mailman id 849920; Fri, 06 Dec 2024 08:09: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 1tJTOX-0004AC-Le for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 08:09:01 +0000 Received: from mail-oa1-x2d.google.com (mail-oa1-x2d.google.com [2001:4860:4864:20::2d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 55523615-b3a9-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 09:08:54 +0100 (CET) Received: by mail-oa1-x2d.google.com with SMTP id 586e51a60fabf-29e59db8d58so1282714fac.2 for ; Fri, 06 Dec 2024 00:08: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: 55523615-b3a9-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1733472538; x=1734077338; 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=wJtk4S31GHBpWXy2Qd+rQtajgw7zqTCvAuIy9qxvuUM=; b=xri5MIcbW4W3V809l/3eW4f5xldu8GV0aiPOIoOz7VDio7Y29h6ZqRRkEIsD4cwA1/ h7p0Ky66rgrx09e04PVyVXoOpQ71nGUX2USv3scwWSHz5CbZc3sGinrwOHuLeo8eETot TZMqFv/y0uPfV5FNEFSCsf2jnJwtbw8LEq9kK1SQ1Qdcr6PimPsIWdXszsvSr4KZxJJZ 5rXT1zGQPw6ekv+WTiT9Qwqzx5IpUZvavd8/xfk22+TAikTOefcheUwd+U6u1aBncbAA eyBQHWoDS+0AWeNGGmEw+1IoHehJeHgyN/o1QFSD1y5Nm2DDMkEylZqzd7ozDMDaiq46 6B2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733472538; x=1734077338; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wJtk4S31GHBpWXy2Qd+rQtajgw7zqTCvAuIy9qxvuUM=; b=BsQvA85Bkv6DiLBCcwV0BZyu+uhTN+I2+1TOcokI7rZkN8dlM5d2FEFhGVJtVolls2 iEO5QPXU8e0Vpnj1/TixjR20hVzHTxE8ttvwnBErHJ75J62JGuZs8hdB7WNEFNnp4r4B damrL8jIGXNQ9XZN5TbZ9tQPPSqPGM5MLDGUgp8rhq3V9ZvR1TPW6EZXS6xweBbNth67 YL6juAp28YQj6JjltxwaMuPjF3TwfPmiZxkNNu/X/Cg98cb8sPaO0kTrznRMw3H0JFJ/ Gm3/3ejeUaXJBnslTZErr88O4XEvRu6/qiOQHdCjmXfxWiDD7yvNoI6iQBwMKhq/1cuL cu1g== X-Gm-Message-State: AOJu0YzzIk9SjY8HuheZ3/HAyMevxekQhLhekfR/8QByuRV/W398tDnL kjOk7pZ1pmvhBhBjvPovlulKOFVpz5axHZqdU7G0r5uQrtJI5O7JHUnA1sinUrvRJmBkMIuqiis zLJuI6hDoZfalx0TdNsGnpj3v5gTH474U3DBykA== X-Gm-Gg: ASbGncs3JSg4f8p4/DzQZIaoFb6KDkMBCQPVABhcLA9V82jscisr+PJAdiOOkcvMlIR cg8GJdfvlfsR8Xrdv/pLxjfjACGNPrKc= X-Google-Smtp-Source: AGHT+IF9UVBA4stT054vD2CesF+g2alBl2n8BaADsQu+Wr0+F3MkDnkx9+70r1F46epl9EgUKKOB06hvoZT9Urbu8Ks= X-Received: by 2002:a05:6870:ec9f:b0:297:24ad:402f with SMTP id 586e51a60fabf-29f732dff69mr981277fac.12.1733472538330; Fri, 06 Dec 2024 00:08:58 -0800 (PST) MIME-Version: 1.0 References: <7b3dc2c98d01478d5ab03780932844ea980b7ae0.1732702210.git.bertrand.marquis@arm.com> In-Reply-To: <7b3dc2c98d01478d5ab03780932844ea980b7ae0.1732702210.git.bertrand.marquis@arm.com> From: Jens Wiklander Date: Fri, 6 Dec 2024 09:08:46 +0100 Message-ID: Subject: Re: [PATCH v3 10/10] xen/arm: ffa: Add indirect message 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 Wed, Nov 27, 2024 at 5:08=E2=80=AFPM Bertrand Marquis wrote: > > Add support for FFA_MSG_SEND2 to send indirect messages from a VM to a > secure partition. > > Signed-off-by: Bertrand Marquis > --- > Changes in v3: > - in ffa_handle_msg_send2 use ffa_get_vm_id instead of a local variable > to make sure that we use the right VM ID as source without having a > potential solution for the VM to give a wrong identity. > Changes in v2: > - rebase > --- > xen/arch/arm/tee/ffa.c | 5 ++++ > xen/arch/arm/tee/ffa_msg.c | 50 ++++++++++++++++++++++++++++++++++ > xen/arch/arm/tee/ffa_private.h | 1 + > 3 files changed, 56 insertions(+) Looks good. Reviewed-by: Jens Wiklander Cheers, Jens > > diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c > index 04d2403415fe..87775ed88ffd 100644 > --- a/xen/arch/arm/tee/ffa.c > +++ b/xen/arch/arm/tee/ffa.c > @@ -101,6 +101,7 @@ static const struct ffa_fw_abi ffa_fw_abi_needed[] = =3D { > FW_ABI(FFA_MEM_RECLAIM), > FW_ABI(FFA_MSG_SEND_DIRECT_REQ_32), > FW_ABI(FFA_MSG_SEND_DIRECT_REQ_64), > + FW_ABI(FFA_MSG_SEND2), > }; > > /* > @@ -195,6 +196,7 @@ static void handle_features(struct cpu_user_regs *reg= s) > case FFA_PARTITION_INFO_GET: > case FFA_MSG_SEND_DIRECT_REQ_32: > case FFA_MSG_SEND_DIRECT_REQ_64: > + case FFA_MSG_SEND2: > ffa_set_regs_success(regs, 0, 0); > break; > case FFA_MEM_SHARE_64: > @@ -275,6 +277,9 @@ static bool ffa_handle_call(struct cpu_user_regs *reg= s) > case FFA_MSG_SEND_DIRECT_REQ_64: > ffa_handle_msg_send_direct_req(regs, fid); > return true; > + case FFA_MSG_SEND2: > + e =3D ffa_handle_msg_send2(regs); > + break; > case FFA_MEM_SHARE_32: > case FFA_MEM_SHARE_64: > ffa_handle_mem_share(regs); > diff --git a/xen/arch/arm/tee/ffa_msg.c b/xen/arch/arm/tee/ffa_msg.c > index ae263e54890e..ee594e737fc7 100644 > --- a/xen/arch/arm/tee/ffa_msg.c > +++ b/xen/arch/arm/tee/ffa_msg.c > @@ -12,6 +12,15 @@ > > #include "ffa_private.h" > > +/* Encoding of partition message in RX/TX buffer */ > +struct ffa_part_msg_rxtx { > + uint32_t flags; > + uint32_t reserved; > + uint32_t msg_offset; > + uint32_t send_recv_id; > + uint32_t msg_size; > +}; > + > void ffa_handle_msg_send_direct_req(struct cpu_user_regs *regs, uint32_t= fid) > { > struct arm_smccc_1_2_regs arg =3D { .a0 =3D fid, }; > @@ -78,3 +87,44 @@ out: > resp.a4 & mask, resp.a5 & mask, resp.a6 & mask, > resp.a7 & mask); > } > + > +int32_t ffa_handle_msg_send2(struct cpu_user_regs *regs) > +{ > + struct domain *src_d =3D current->domain; > + struct ffa_ctx *src_ctx =3D src_d->arch.tee; > + const struct ffa_part_msg_rxtx *src_msg; > + uint16_t dst_id, src_id; > + int32_t ret; > + > + if ( !ffa_fw_supports_fid(FFA_MSG_SEND2) ) > + return FFA_RET_NOT_SUPPORTED; > + > + if ( !spin_trylock(&src_ctx->tx_lock) ) > + return FFA_RET_BUSY; > + > + src_msg =3D src_ctx->tx; > + src_id =3D src_msg->send_recv_id >> 16; > + dst_id =3D src_msg->send_recv_id & GENMASK(15,0); > + > + if ( src_id !=3D ffa_get_vm_id(src_d) || !FFA_ID_IS_SECURE(dst_id) ) > + { > + ret =3D FFA_RET_INVALID_PARAMETERS; > + goto out_unlock_tx; > + } > + > + /* check source message fits in buffer */ > + if ( src_ctx->page_count * FFA_PAGE_SIZE < > + src_msg->msg_offset + src_msg->msg_size || > + src_msg->msg_offset < sizeof(struct ffa_part_msg_rxtx) ) > + { > + ret =3D FFA_RET_INVALID_PARAMETERS; > + goto out_unlock_tx; > + } > + > + ret =3D ffa_simple_call(FFA_MSG_SEND2, > + ((uint32_t)ffa_get_vm_id(src_d)) << 16, 0, 0, = 0); > + > +out_unlock_tx: > + spin_unlock(&src_ctx->tx_lock); > + return ret; > +} > diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_privat= e.h > index 973ee55be09b..d441c0ca5598 100644 > --- a/xen/arch/arm/tee/ffa_private.h > +++ b/xen/arch/arm/tee/ffa_private.h > @@ -359,6 +359,7 @@ void ffa_handle_notification_get(struct cpu_user_regs= *regs); > int ffa_handle_notification_set(struct cpu_user_regs *regs); > > void ffa_handle_msg_send_direct_req(struct cpu_user_regs *regs, uint32_t= fid); > +int32_t ffa_handle_msg_send2(struct cpu_user_regs *regs); > > static inline uint16_t ffa_get_vm_id(const struct domain *d) > { > -- > 2.47.0 > From xen-devel-bounces@lists.xenproject.org Fri Dec 06 08:37:32 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 08:37:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849937.1264420 (Exim 4.92) (envelope-from ) id 1tJTq0-0002fX-7Z; Fri, 06 Dec 2024 08:37:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849937.1264420; Fri, 06 Dec 2024 08:37: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 1tJTq0-0002fQ-4H; Fri, 06 Dec 2024 08:37:24 +0000 Received: by outflank-mailman (input) for mailman id 849937; Fri, 06 Dec 2024 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 1tJTpy-0002fK-Bb for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 08:37:22 +0000 Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4e5c75ec-b3ad-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 09:37:20 +0100 (CET) Received: from quovadis.eurecom.fr ([10.3.2.233]) by drago1i.eurecom.fr with ESMTP; 06 Dec 2024 09:37:19 +0100 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4e5c75ec-b3ad-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default; t=1733474240; x=1765010240; h=from:in-reply-to:references:date:cc:to:mime-version: message-id:subject:content-transfer-encoding; bh=rTkhAMK/kNKQuhdzI/kBqZ0iMBZKcdMldxieIpvvQKo=; b=NIEh6ht5Jp84cVrHWytheoGxT7Xf1Jf9Kr1U8dJzQG7lbPPIkFI+9nWn ZaWOqkbVuWtOpzcekVRocDsQtFwFqn6llV+Xu9OtM94Pahx86aJnnt/yS phxeXnYgomhzDyyFzbmC3Nw0UJNFYI8Sk2LwoSs8XL+IOf+cfm4UlH3g9 s=; X-CSE-ConnectionGUID: a7vYs/GoRi+Rmoyl2ETVDg== X-CSE-MsgGUID: fG5/L3wDS7+rOnRIlOK36A== X-IronPort-AV: E=Sophos;i="6.12,212,1728943200"; d="scan'208";a="28056097" From: "Ariel Otilibili-Anieli" In-Reply-To: Content-Type: text/plain; charset="utf-8" X-Forward: 88.183.119.157 References: <20241206000422.331015-1-Ariel.Otilibili-Anieli@eurecom.fr> <20241206000422.331015-2-Ariel.Otilibili-Anieli@eurecom.fr> Date: Fri, 06 Dec 2024 09:37:19 +0100 Cc: xen-devel@lists.xenproject.org, "Anthony PERARD" , "Jan Beulich" To: "Andrew Cooper" MIME-Version: 1.0 Message-ID: <2a1a24-6752b780-91-c912830@6857849> Subject: =?utf-8?q?Re=3A?= [PATCH 1/1] =?utf-8?q?tools/libacpi=3A?= clear out compilation warnings User-Agent: SOGoMail 5.11.1 Content-Transfer-Encoding: quoted-printable Content-Length: 3592 On Friday, December 06, 2024 01:42 CET, Andrew Cooper wrote: > On 06/12/2024 12:00 am, Ariel Otilibili wrote: > > From: Ariel Otilibili > > > > * While compiling ASLs, iasl puts out deprecation warnings > > > > ``` > > tools/libs/light/mk=5Fdsdt --debug=3Dy --maxcpu any --dm-version no= ne >> tools/libs/light/dsdt=5Fpvh.asl > > /usr/bin/iasl -vs -p tools/libs/light/dsdt=5Fpvh.tmp -tc tools/libs= /light/dsdt=5Fpvh.asl > > > > tools/libs/light/dsdt=5Fpvh.asl 40: Processor ( PR00, 0= , 0x0000b010, 0x06 ) { > > Warning 3168 - = ^ Legacy Processor() keyword detected. Use Device() keyw= ord instead. > > > > tools/libs/light/dsdt=5Fpvh.asl 64: Processor ( PR01, 1= , 0x0000b010, 0x06 ) { > > Warning 3168 - = ^ Legacy Processor() keyword detected. Use Device() keyw= ord instead. > > ``` > > > > * since 6.0, the ACPI specs have deprecated the keyword Processor > > * the deprecation is mentioned in Rev. History, Issue 1232 > > * instead, ACPI advices to use the keyword Device > > * after the fix, the warnings are cleared out. > > > > ``` > > tools/libs/light/mk=5Fdsdt --debug=3Dy --maxcpu any --dm-version no= ne >> tools/libs/light/dsdt=5Fpvh.asl > > /usr/bin/iasl -vs -p tools/libs/light/dsdt=5Fpvh.tmp -tc tools/libs= /light/dsdt=5Fpvh.asl > > > > ASL Input: tools/libs/light/dsdt=5Fpvh.asl - 167025 bytes 37= 63 keywords 0 source lines > > AML Output: tools/libs/light/dsdt=5Fpvh.aml - 27035 bytes 25= 99 opcodes 1164 named objects > > Hex Dump: tools/libs/light/dsdt=5Fpvh.hex - 253913 bytes > > > > Compilation successful. 0 Errors, 0 Warnings, 0 Remarks, 1915 Optim= izations > > ``` > > > > Link: https://uefi.org/specs/ACPI/6.5=5FA/Frontmatter/Revision=5FHi= story.html#revision-history > > Link: https://uefi.org/specs/ACPI/6.5=5FA/08=5FProcessor=5FConfigur= ation=5Fand=5FControl.html#declaring-processors > > Link: https://uefi.org/specs/ACPI/6.5=5FA/19=5FASL=5FReference.html= #device-declare-device-package > > Signed-off-by: Ariel Otilibili > > Signed-off-by: Ariel Otilibili > > --- > > tools/libacpi/mk=5Fdsdt.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/tools/libacpi/mk=5Fdsdt.c b/tools/libacpi/mk=5Fdsdt.c > > index 34f6753f61..5729b4238c 100644 > > --- a/tools/libacpi/mk=5Fdsdt.c > > +++ b/tools/libacpi/mk=5Fdsdt.c > > @@ -186,7 +186,7 @@ int main(int argc, char **argv) > > /* Define processor objects and control methods. */ > > for ( cpu =3D 0; cpu < max=5Fcpus; cpu++) > > { > > - push=5Fblock("Processor", "PR%02X, %d, 0x0000b010, 0x06", = cpu, cpu); > > + push=5Fblock("Device", "PR%02X", cpu); > > =20 > > stmt("Name", "=5FHID, \"ACPI0007\""); > > =20 >=20 > Hello, >=20 > Thankyou for your patch. >=20 > Unfortunately, it's not quite this simple.=C2=A0 While there is a war= ning out > of IASL, older OSes coded to prior versions of the ACPI spec still > depend on "Processor". Thanks for the feedback, Andrew; I didn't consider older OSes in the pa= tch, indeed. >=20 > It may be time to start thinking about removing support for the likes= of > WinXP, but that needs more consideration than simply fixing a warning= . If the removal makes sense; I am willing to work on it. I would need to know which parts of the codebase should be modified. Regards, Ariel >=20 > ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Dec 06 09:39:32 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 09:39:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849957.1264431 (Exim 4.92) (envelope-from ) id 1tJUnp-000430-Mt; Fri, 06 Dec 2024 09:39:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849957.1264431; Fri, 06 Dec 2024 09:39:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJUnp-00042t-Jz; Fri, 06 Dec 2024 09:39:13 +0000 Received: by outflank-mailman (input) for mailman id 849957; Fri, 06 Dec 2024 09:39: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 1tJUno-00042n-O5 for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 09:39:12 +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 f1fb8451-b3b5-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 10:39:10 +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 C7B591F38E; Fri, 6 Dec 2024 09:39:08 +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 79C1213647; Fri, 6 Dec 2024 09:39:08 +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 VVp3GzzGUmf2DwAAD6G6ig (envelope-from ); Fri, 06 Dec 2024 09:39: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: f1fb8451-b3b5-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733477948; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=4La1PApICUl8lH2+Xp52W5sEKTv28kQNJ79VSICGxmk=; b=VOqyayyhWT3BftVDujBi2ZFCCKSU4xaMa+GUcFxI05ErTD0BW6vmkDVs0AXMtBloWTHybf 6HcG4kYWp5aAtXvNe4pYBjLRcNktxGfiHsva56+fIeJO5s62ak8zqSWzwsVzrpW+HWmUO8 0GS3g4ArfbSerMf6CmiCJUqwl/KZLeM= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733477948; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=4La1PApICUl8lH2+Xp52W5sEKTv28kQNJ79VSICGxmk=; b=VOqyayyhWT3BftVDujBi2ZFCCKSU4xaMa+GUcFxI05ErTD0BW6vmkDVs0AXMtBloWTHybf 6HcG4kYWp5aAtXvNe4pYBjLRcNktxGfiHsva56+fIeJO5s62ak8zqSWzwsVzrpW+HWmUO8 0GS3g4ArfbSerMf6CmiCJUqwl/KZLeM= Message-ID: Date: Fri, 6 Dec 2024 10:39:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/6] xen: add new domctl get_changed_domain From: Juergen Gross To: xen-devel@lists.xenproject.org, Andrew Cooper , Jan Beulich Cc: "Daniel P. Smith" , Anthony PERARD , Julien Grall , Stefano Stabellini References: <20241023131005.32144-1-jgross@suse.com> <20241023131005.32144-4-jgross@suse.com> <0a7b19a0-5002-4fc5-8870-be78a2e59f3c@suse.com> Content-Language: en-US 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: <0a7b19a0-5002-4fc5-8870-be78a2e59f3c@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------JaX9jTah09QbTG4VywOYpxna" X-Spam-Score: -6.20 X-Spamd-Result: default: False [-6.20 / 50.00]; BAYES_HAM(-3.00)[99.99%]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; NEURAL_HAM_SHORT(-0.20)[-0.999]; MIME_BASE64_TEXT(0.10)[]; MIME_UNKNOWN(0.10)[application/pgp-keys]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; HAS_ATTACHMENT(0.00)[] X-Spam-Flag: NO X-Spam-Level: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------JaX9jTah09QbTG4VywOYpxna Content-Type: multipart/mixed; boundary="------------pee2CVzjK4MweN9X0KAHH16n"; protected-headers="v1" From: Juergen Gross To: xen-devel@lists.xenproject.org, Andrew Cooper , Jan Beulich Cc: "Daniel P. Smith" , Anthony PERARD , Julien Grall , Stefano Stabellini Message-ID: Subject: Re: [PATCH 3/6] xen: add new domctl get_changed_domain References: <20241023131005.32144-1-jgross@suse.com> <20241023131005.32144-4-jgross@suse.com> <0a7b19a0-5002-4fc5-8870-be78a2e59f3c@suse.com> In-Reply-To: <0a7b19a0-5002-4fc5-8870-be78a2e59f3c@suse.com> Autocrypt-Gossip: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs= --------------pee2CVzjK4MweN9X0KAHH16n Content-Type: multipart/mixed; boundary="------------OpWzyYEwouX4LBmheDTST080" --------------OpWzyYEwouX4LBmheDTST080 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDQuMTIuMjQgMTE6MDEsIEp1ZXJnZW4gR3Jvc3Mgd3JvdGU6DQo+IE9uIDIzLjEwLjI0 IDE1OjEwLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gQWRkIGEgbmV3IGRvbWN0bCBzdWIt ZnVuY3Rpb24gdG8gZ2V0IGRhdGEgb2YgYSBkb21haW4gaGF2aW5nIGNoYW5nZWQNCj4+IHN0 YXRlICh0aGlzIGlzIG5lZWRlZCBieSBYZW5zdG9yZSkuDQo+Pg0KPj4gVGhlIHJldHVybmVk IHN0YXRlIGp1c3QgY29udGFpbnMgdGhlIGRvbWlkLCB0aGUgZG9tYWluIHVuaXF1ZSBpZCwN Cj4+IGFuZCBzb21lIGZsYWdzIChleGlzdGluZywgc2h1dGRvd24sIGR5aW5nKS4NCj4+DQo+ PiBJbiBvcmRlciB0byBlbmFibGUgWGVuc3RvcmUgc3R1YmRvbSBiZWluZyBidWlsdCBmb3Ig bXVsdGlwbGUgWGVuDQo+PiB2ZXJzaW9ucywgbWFrZSB0aGlzIGRvbWN0bCBzdGFibGUuwqAg Rm9yIHN0YWJsZSBkb21jdGxzIHRoZQ0KPj4gaW50ZXJmYWNlX3ZlcnNpb24gaXMgc3BlY2lm aWMgdG8gdGhlIHJlc3BlY3RpdmUgZG9tY3RsIG9wIGFuZCBpdCBpcyBhbg0KPj4gaW4vb3V0 IHBhcmFtZXRlcjogT24gaW5wdXQgdGhlIGNhbGxlciBpcyBzcGVjaWZ5aW5nIHRoZSBkZXNp cmVkIHZlcnNpb24NCj4+IG9mIHRoZSBvcCwgd2hpbGUgb24gb3V0cHV0IHRoZSBoeXBlcnZp c29yIHdpbGwgcmV0dXJuIHRoZSB1c2VkIHZlcnNpb24NCj4+ICh0aGlzIHdpbGwgYmUgYXQg bWF4IHRoZSBjYWxsZXIgc3VwcGxpZWQgdmVyc2lvbiwgYnV0IG1pZ2h0IGJlIGxvd2VyIGlu DQo+PiBjYXNlIHRoZSBoeXBlcnZpc29yIGRvZXNuJ3Qgc3VwcG9ydCB0aGlzIHZlcnNpb24p Lg0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNv bT4NCj4gDQo+IENvdWxkIEkgcGxlYXNlIGdldCBzb21lIGZlZWRiYWNrIHJlZ2FyZGluZyB0 aGUgbmV3IHN0YWJsZSAoc3ViLSloeXBlcmNhbGw/DQo+IA0KPiBJJ2QgX3JlYWxseV8gbGlr ZSB0byBnZXQgdGhpcyBzZXJpZXMgaW50byA0LjIwLg0KPiANCj4gSW4gdGhlIFJGQyBzZXJp ZXMgSSBzdWdnZXN0ZWQgYSBuZXcgc3RhYmxlIG1haW4gaHlwZXJjYWxsLCBidXQgdGhpcyB3 YXNuJ3QNCj4gbGlrZWQgYnkgSmFuLiBTbyBJIHVzZWQgdGhlIGN1cnJlbnQgYXBwcm9hY2gg dG8gbWFrZSBpdCBhIHN1Yi1vcCBvZiB0aGUNCj4gZG9tY3RsIGh5cGVyY2FsbCwgd2hpY2gg SmFuIGRpZG4ndCBsaWtlIGVpdGhlciBpbiB0aGUgY3VycmVudCBmb3JtLg0KPiANCj4gQW5k cmV3IHRvbGQgbWUgbXVsdGlwbGUgdGltZXMsIGhlIHdhbnRlZCB0byBnaXZlIHNvbWUgZmVl ZGJhY2ssIGJ1dCBoYXNuJ3QNCj4gZG9uZSBzbyB5ZXQuDQo+IA0KPiBJIHRoaW5rIHRoZXJl IGFyZSBtdWx0aXBsZSBvcHRpb25zIGhvdyB0byBwcm9jZWVkLCB0aGUgZm9sbG93aW5nIGNv bWluZyB0bw0KPiBteSBtaW5kOg0KPiANCj4gMS4gVXNlIGEgbmV3IHN0YWJsZSBhZG1pbiBo eXBlcmNhbGwsIHNpbWlsYXIgdG8gdGhlIFJGQyBzZXJpZXMgc29tZSB0aW1lIGFnby4NCj4g IMKgwqAgSW4gY2FzZSB0aGlzIGlzIHRoZSBwcmVmZXJyZWQgb3B0aW9uLCBJJ2Qgc3VnZ2Vz dCB0byBtYWtlIGl0IHNpbWlsYXIgdG8NCj4gIMKgwqAgdGhlIGN1cnJlbnQgc3lzY3RsIGh5 cGVyY2FsbCwgYnV0IHdpdGhvdXQgdGhlIHZlcnNpb24gZmllbGQuIEFueSBub3QNCj4gIMKg wqAgY29tcGF0aWJsZSBjaGFuZ2Ugb2YgYSBzdWItb3Agd291bGQgbmVlZCBhIG5ldyBzdWIt b3AgaW5zdGVhZC4NCj4gDQo+IDIuIFVzZSBzdGFibGUgZG9tY3RsIChhbmQgcG9zc2libHkg c3lzY3RsIGluIHRoZSBmdXR1cmUpIHN1Yi1vcHMgbGlrZSBpbiB0aGlzDQo+ICDCoMKgIHBh dGNoLCBidXQgcG9zc2libHkgZHJvcCB0aGUgdXNlIG9mIHRoZSBpbnRlcmZhY2UgdmVyc2lv biBmaWVsZC4gQW55IG5vdA0KPiAgwqDCoCBjb21wYXRpYmxlIGNoYW5nZSBvZiBhIHN0YWJs ZSBzdWItb3Agd291bGQgbmVlZCBhIG5ldyBzdWItb3AgaW5zdGVhZC4NCj4gDQo+IEknbGwg c2V0IHRoaXMgdG9waWMgb24gdGhlIGFnZW5kYSBvZiB0aGUgY29tbXVuaXR5IGNhbGwgdG9t b3Jyb3cgaW4gY2FzZSBJDQo+IGRvbid0IGdldCBhbnkgZmVlZGJhY2sgYWxsb3dpbmcgdG8g cHJvY2VlZC4NCg0KU28ganVzdCB0byBoYXZlIHRoZSB3aG9sZSBkaXNjdXNzaW9uIG9uIHhl bi1kZXZlbDoNCg0KSW4gdGhlIGNvbW11bml0eSBjYWxsIEFuZHJldyBnYXZlIGhpcyBmZWVk YmFjazogaGUgaXMgcHJlZmVycmluZyBhYm92ZQ0KdmFyaWFudCAyLCB3aXRoIHRoZSBpbnRl cmZhY2UgdmVyc2lvbiBmaWVsZCByZXF1aXJlZCB0byBiZSAwIGZvciBzdGFibGUNCnN1Yi1v cHMuDQoNCkknbGwgZ28gdGhpcyByb3V0ZSwgd2hpbGUgYWRkcmVzc2luZyBKYW4ncyBvdGhl ciBjb21tZW50cy4NCg0KDQpKdWVyZ2VuDQo= --------------OpWzyYEwouX4LBmheDTST080 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----- --------------OpWzyYEwouX4LBmheDTST080-- --------------pee2CVzjK4MweN9X0KAHH16n-- --------------JaX9jTah09QbTG4VywOYpxna 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/Ey8FAmdSxjsFAwAAAAAACgkQsN6d1ii/Ey9m Lgf+NAejj1DP2+dgthE+hA3c0vKpepFsvT9mRSizotK2/nQ6NXS8GOlkYSsnwZTbSpsQ4JgNOEsC dzR1ZpL2zwreojzWPcYsL3gVgsCXtYVPzGycT5868NgpJFQpaIZtuuOvZ4aeLAH8FphDF9SrpGWX V5zgMMGNiLpbtid3UTCLEKVQR1scNHAR/zlI0z4NjevK/uOjyYDYoIDzPQa3SU/Qg1yiNsiSExDx By9uYFmwyRunwXZ3PYJhYDaWggYeXV4eUfm0fJsALhvWlCkbdJjApA74vS78HOPuRhshBOafsEj/ vwtxBxJ/5Sg3l3AWXXssdBDzKikIcetvc/s2DRmFjQ== =r2hZ -----END PGP SIGNATURE----- --------------JaX9jTah09QbTG4VywOYpxna-- From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:18:23 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:18:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849988.1264506 (Exim 4.92) (envelope-from ) id 1tJVPi-0003JI-2h; Fri, 06 Dec 2024 10:18:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849988.1264506; Fri, 06 Dec 2024 10:18:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJVPh-0003Ip-Qu; Fri, 06 Dec 2024 10:18:21 +0000 Received: by outflank-mailman (input) for mailman id 849988; Fri, 06 Dec 2024 10:18: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 1tJVPg-0001om-4Z for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:20 +0000 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 687aba6b-b3bb-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 11:18:18 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.88.105]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4Y4Rwr30x4z11Pg9; Fri, 6 Dec 2024 18:15:56 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id 95893140360; Fri, 6 Dec 2024 18:18:15 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:14 +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: 687aba6b-b3bb-11ef-99a3-01e77a169b0f From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 07/22] arm64: entry: preempt_schedule_irq() only if PREEMPTION enabled Date: Fri, 6 Dec 2024 18:17:29 +0800 Message-ID: <20241206101744.4161990-8-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) The generic entry check PREEMPTION for both PREEMPT_DYNAMIC enabled and PREEMPT_DYNAMIC disabled. Whether PREEMPT_DYNAMIC enabled or not, PREEMPTION should be enabled to allow reschedule before EL1 exception return, so move PREEMPTION check ahead in preparation for moving arm64 over to the generic entry code. Signed-off-by: Jinjie Ruan --- arch/arm64/kernel/entry-common.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c index 80b47ca02db2..029f8bd72f8a 100644 --- a/arch/arm64/kernel/entry-common.c +++ b/arch/arm64/kernel/entry-common.c @@ -109,9 +109,6 @@ void raw_irqentry_exit_cond_resched(void) #ifdef CONFIG_PREEMPT_DYNAMIC if (!static_branch_unlikely(&sk_dynamic_irqentry_exit_cond_resched)) return; -#else - if (!IS_ENABLED(CONFIG_PREEMPTION)) - return; #endif if (!preempt_count()) { @@ -142,7 +139,8 @@ static __always_inline void __exit_to_kernel_mode(struct pt_regs *regs, return; } - raw_irqentry_exit_cond_resched(); + if (IS_ENABLED(CONFIG_PREEMPTION)) + raw_irqentry_exit_cond_resched(); trace_hardirqs_on(); } else { -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:18:23 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:18:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849983.1264455 (Exim 4.92) (envelope-from ) id 1tJVPe-00026Z-6T; Fri, 06 Dec 2024 10:18:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849983.1264455; Fri, 06 Dec 2024 10: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 1tJVPe-00025b-1s; Fri, 06 Dec 2024 10:18:18 +0000 Received: by outflank-mailman (input) for mailman id 849983; Fri, 06 Dec 2024 10: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 1tJVPc-0001om-TX for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:16 +0000 Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 642ff8c3-b3bb-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 11:18:11 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.88.214]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4Y4Rwg75WYz1kvNq; Fri, 6 Dec 2024 18:15:47 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id 2CC471A016C; Fri, 6 Dec 2024 18:18:07 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:05 +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: 642ff8c3-b3bb-11ef-99a3-01e77a169b0f From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 00/22] arm64: entry: Convert to generic entry Date: Fri, 6 Dec 2024 18:17:22 +0800 Message-ID: <20241206101744.4161990-1-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) Currently, x86, Riscv, Loongarch use the generic entry. Convert arm64 to use the generic entry infrastructure from kernel/entry/*. The generic entry makes maintainers' work easier and codes more elegant, which aslo removed a lot of duplicate code. The main steps are as follows: - Make arm64 easier to use irqentry_enter/exit(). - Make arm64 closer to the PREEMPT_DYNAMIC code of generic entry. - Split generic entry into generic irq entry and generic syscall to make the single patch more concentrated in switching to one thing. - Switch to generic irq entry. - Make arm64 closer to the generic syscall code. - Switch to generic entry completely. Changes in v5: - Not change arm32 and keep inerrupts_enabled() macro for gicv3 driver. - Move irqentry_state definition into arch/arm64/kernel/entry-common.c. - Avoid removing the __enter_from_*() and __exit_to_*() wrappers. - Update "irqentry_state_t ret/irq_state" to "state" to keep it consistently. - Use generic irq entry header for PREEMPT_DYNAMIC after split the generic entry. - Also refactor the ARM64 syscall code. - Introduce arch_ptrace_report_syscall_entry/exit(), instead of arch_pre/post_report_syscall_entry/exit() to simplify code. - Make the syscall patches clear separation. - Update the commit message. Changes in v4: - Rework/cleanup split into a few patches as Mark suggested. - Replace interrupts_enabled() macro with regs_irqs_disabled(), instead of left it here. - Remove rcu and lockdep state in pt_regs by using temporary irqentry_state_t as Mark suggested. - Remove some unnecessary intermediate functions to make it clear. - Rework preempt irq and PREEMPT_DYNAMIC code to make the switch more clear. - arch_prepare_*_entry/exit() -> arch_pre_*_entry/exit(). - Expand the arch functions comment. - Make arch functions closer to its caller. - Declare saved_reg in for block. - Remove arch_exit_to_kernel_mode_prepare(), arch_enter_from_kernel_mode(). - Adjust "Add few arch functions to use generic entry" patch to be the penultimate. - Update the commit message. - Add suggested-by. Changes in v3: - Test the MTE test cases. - Handle forget_syscall() in arch_post_report_syscall_entry() - Make the arch funcs not use __weak as Thomas suggested, so move the arch funcs to entry-common.h, and make arch_forget_syscall() folded in arch_post_report_syscall_entry() as suggested. - Move report_single_step() to thread_info.h for arm64 - Change __always_inline() to inline, add inline for the other arch funcs. - Remove unused signal.h for entry-common.h. - Add Suggested-by. - Update the commit message. Changes in v2: - Add tested-by. - Fix a bug that not call arch_post_report_syscall_entry() in syscall_trace_enter() if ptrace_report_syscall_entry() return not zero. - Refactor report_syscall(). - Add comment for arch_prepare_report_syscall_exit(). - Adjust entry-common.h header file inclusion to alphabetical order. - Update the commit message. Jinjie Ruan (22): arm64: ptrace: Replace interrupts_enabled() with regs_irqs_disabled() arm64: entry: Refactor the entry and exit for exceptions from EL1 arm64: entry: Move arm64_preempt_schedule_irq() into __exit_to_kernel_mode() arm64: entry: Rework arm64_preempt_schedule_irq() arm64: entry: Use preempt_count() and need_resched() helper arm64: entry: Expand the need_irq_preemption() macro ahead arm64: entry: preempt_schedule_irq() only if PREEMPTION enabled arm64: entry: Use different helpers to check resched for PREEMPT_DYNAMIC entry: Split generic entry into irq and syscall entry: Add arch_irqentry_exit_need_resched() for arm64 arm64: entry: Switch to generic IRQ entry arm64/ptrace: Split report_syscall() function arm64/ptrace: Refactor syscall_trace_enter() arm64/ptrace: Refactor syscall_trace_exit() arm64/ptrace: Refator el0_svc_common() entry: Make syscall_exit_to_user_mode_prepare() not static arm64/ptrace: Return early for ptrace_report_syscall_entry() error arm64/ptrace: Expand secure_computing() in place arm64/ptrace: Use syscall_get_arguments() heleper entry: Add arch_ptrace_report_syscall_entry/exit() entry: Add has_syscall_work() helepr arm64: entry: Convert to generic entry MAINTAINERS | 1 + arch/Kconfig | 8 + arch/arm64/Kconfig | 1 + arch/arm64/include/asm/daifflags.h | 2 +- arch/arm64/include/asm/entry-common.h | 134 +++++++++ arch/arm64/include/asm/preempt.h | 2 - arch/arm64/include/asm/ptrace.h | 11 +- arch/arm64/include/asm/syscall.h | 6 +- arch/arm64/include/asm/thread_info.h | 23 +- arch/arm64/include/asm/xen/events.h | 2 +- arch/arm64/kernel/acpi.c | 2 +- arch/arm64/kernel/debug-monitors.c | 9 +- arch/arm64/kernel/entry-common.c | 377 ++++++++----------------- arch/arm64/kernel/ptrace.c | 90 ------ arch/arm64/kernel/sdei.c | 2 +- arch/arm64/kernel/signal.c | 3 +- arch/arm64/kernel/syscall.c | 31 +- include/linux/entry-common.h | 384 +------------------------ include/linux/irq-entry-common.h | 389 ++++++++++++++++++++++++++ kernel/entry/Makefile | 3 +- kernel/entry/common.c | 176 ++---------- kernel/entry/syscall-common.c | 198 +++++++++++++ kernel/sched/core.c | 8 +- 23 files changed, 909 insertions(+), 953 deletions(-) create mode 100644 arch/arm64/include/asm/entry-common.h create mode 100644 include/linux/irq-entry-common.h create mode 100644 kernel/entry/syscall-common.c -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:18:23 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:18:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849987.1264501 (Exim 4.92) (envelope-from ) id 1tJVPh-0003Gf-JV; Fri, 06 Dec 2024 10:18:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849987.1264501; Fri, 06 Dec 2024 10:18: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 1tJVPh-0003GS-GO; Fri, 06 Dec 2024 10:18:21 +0000 Received: by outflank-mailman (input) for mailman id 849987; Fri, 06 Dec 2024 10:18: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 1tJVPf-0001om-IK for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:19 +0000 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 67c4249d-b3bb-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 11:18:17 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4Y4Rw30dq5z11Lt2; Fri, 6 Dec 2024 18:15:15 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id 6CA1D18009B; Fri, 6 Dec 2024 18:18:14 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:13 +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: 67c4249d-b3bb-11ef-99a3-01e77a169b0f From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 06/22] arm64: entry: Expand the need_irq_preemption() macro ahead Date: Fri, 6 Dec 2024 18:17:28 +0800 Message-ID: <20241206101744.4161990-7-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) The generic entry has the same logic as need_irq_preemption() macro and use a helper function to check other resched condition. In preparation for moving arm64 over to the generic entry code, check and expand need_irq_preemption() ahead and extract arm64 resched check code to a helper function. No functional changes. Signed-off-by: Jinjie Ruan --- arch/arm64/include/asm/preempt.h | 1 + arch/arm64/kernel/entry-common.c | 28 +++++++++++++++++----------- 2 files changed, 18 insertions(+), 11 deletions(-) diff --git a/arch/arm64/include/asm/preempt.h b/arch/arm64/include/asm/preempt.h index 0159b625cc7f..d0f93385bd85 100644 --- a/arch/arm64/include/asm/preempt.h +++ b/arch/arm64/include/asm/preempt.h @@ -85,6 +85,7 @@ static inline bool should_resched(int preempt_offset) void preempt_schedule(void); void preempt_schedule_notrace(void); +void raw_irqentry_exit_cond_resched(void); #ifdef CONFIG_PREEMPT_DYNAMIC DECLARE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c index efd1a990d138..80b47ca02db2 100644 --- a/arch/arm64/kernel/entry-common.c +++ b/arch/arm64/kernel/entry-common.c @@ -77,17 +77,10 @@ static noinstr irqentry_state_t enter_from_kernel_mode(struct pt_regs *regs) #ifdef CONFIG_PREEMPT_DYNAMIC DEFINE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); -#define need_irq_preemption() \ - (static_branch_unlikely(&sk_dynamic_irqentry_exit_cond_resched)) -#else -#define need_irq_preemption() (IS_ENABLED(CONFIG_PREEMPTION)) #endif static inline bool arm64_need_resched(void) { - if (!need_irq_preemption()) - return false; - /* * DAIF.DA are cleared at the start of IRQ/FIQ handling, and when GIC * priority masking is used the GIC irqchip driver will clear DAIF.IF @@ -111,6 +104,22 @@ static inline bool arm64_need_resched(void) return true; } +void raw_irqentry_exit_cond_resched(void) +{ +#ifdef CONFIG_PREEMPT_DYNAMIC + if (!static_branch_unlikely(&sk_dynamic_irqentry_exit_cond_resched)) + return; +#else + if (!IS_ENABLED(CONFIG_PREEMPTION)) + return; +#endif + + if (!preempt_count()) { + if (need_resched() && arm64_need_resched()) + preempt_schedule_irq(); + } +} + /* * Handle IRQ/context state management when exiting to kernel mode. * After this function returns it is not safe to call regular kernel code, @@ -133,10 +142,7 @@ static __always_inline void __exit_to_kernel_mode(struct pt_regs *regs, return; } - if (!preempt_count() && need_resched()) { - if (arm64_need_resched()) - preempt_schedule_irq(); - } + raw_irqentry_exit_cond_resched(); trace_hardirqs_on(); } else { -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:18:23 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:18:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849986.1264478 (Exim 4.92) (envelope-from ) id 1tJVPf-0002VS-FV; Fri, 06 Dec 2024 10:18:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849986.1264478; Fri, 06 Dec 2024 10:18:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJVPf-0002Tx-5z; Fri, 06 Dec 2024 10:18:19 +0000 Received: by outflank-mailman (input) for mailman id 849986; Fri, 06 Dec 2024 10:18: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 1tJVPd-0001om-B4 for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:17 +0000 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 65b76f2f-b3bb-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 11:18:14 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.162.112]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4Y4RxV0z8nz21mdM; Fri, 6 Dec 2024 18:16:30 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id 8A77C1401DC; Fri, 6 Dec 2024 18:18:09 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:08 +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: 65b76f2f-b3bb-11ef-99a3-01e77a169b0f From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 02/22] arm64: entry: Refactor the entry and exit for exceptions from EL1 Date: Fri, 6 Dec 2024 18:17:24 +0800 Message-ID: <20241206101744.4161990-3-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) The generic entry code uses irqentry_state_t to track lockdep and RCU state across exception entry and return. For historical reasons, arm64 embeds similar fields within its pt_regs structure. In preparation for moving arm64 over to the generic entry code, pull these fields out of arm64's pt_regs, and use a separate structure, matching the style of the generic entry code. No functional changes. Suggested-by: Mark Rutland Signed-off-by: Jinjie Ruan --- arch/arm64/include/asm/ptrace.h | 4 - arch/arm64/kernel/entry-common.c | 136 +++++++++++++++++++------------ 2 files changed, 85 insertions(+), 55 deletions(-) diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h index bcfa96880377..e90dfc9982aa 100644 --- a/arch/arm64/include/asm/ptrace.h +++ b/arch/arm64/include/asm/ptrace.h @@ -169,10 +169,6 @@ struct pt_regs { u64 sdei_ttbr1; struct frame_record_meta stackframe; - - /* Only valid for some EL1 exceptions. */ - u64 lockdep_hardirqs; - u64 exit_rcu; }; /* For correct stack alignment, pt_regs has to be a multiple of 16 bytes. */ diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c index c547e70428d3..1687627b2ecf 100644 --- a/arch/arm64/kernel/entry-common.c +++ b/arch/arm64/kernel/entry-common.c @@ -28,6 +28,13 @@ #include #include +typedef struct irqentry_state { + union { + bool exit_rcu; + bool lockdep; + }; +} irqentry_state_t; + /* * Handle IRQ/context state management when entering from kernel mode. * Before this function is called it is not safe to call regular kernel code, @@ -36,29 +43,36 @@ * This is intended to match the logic in irqentry_enter(), handling the kernel * mode transitions only. */ -static __always_inline void __enter_from_kernel_mode(struct pt_regs *regs) +static __always_inline irqentry_state_t __enter_from_kernel_mode(struct pt_regs *regs) { - regs->exit_rcu = false; + irqentry_state_t state = { + .exit_rcu = false, + }; if (!IS_ENABLED(CONFIG_TINY_RCU) && is_idle_task(current)) { lockdep_hardirqs_off(CALLER_ADDR0); ct_irq_enter(); trace_hardirqs_off_finish(); - regs->exit_rcu = true; - return; + state.exit_rcu = true; + return state; } lockdep_hardirqs_off(CALLER_ADDR0); rcu_irq_enter_check_tick(); trace_hardirqs_off_finish(); + + return state; } -static void noinstr enter_from_kernel_mode(struct pt_regs *regs) +static noinstr irqentry_state_t enter_from_kernel_mode(struct pt_regs *regs) { - __enter_from_kernel_mode(regs); + irqentry_state_t state = __enter_from_kernel_mode(regs); + mte_check_tfsr_entry(); mte_disable_tco_entry(current); + + return state; } /* @@ -69,12 +83,13 @@ static void noinstr enter_from_kernel_mode(struct pt_regs *regs) * This is intended to match the logic in irqentry_exit(), handling the kernel * mode transitions only, and with preemption handled elsewhere. */ -static __always_inline void __exit_to_kernel_mode(struct pt_regs *regs) +static __always_inline void __exit_to_kernel_mode(struct pt_regs *regs, + irqentry_state_t state) { lockdep_assert_irqs_disabled(); if (!regs_irqs_disabled(regs)) { - if (regs->exit_rcu) { + if (state.exit_rcu) { trace_hardirqs_on_prepare(); lockdep_hardirqs_on_prepare(); ct_irq_exit(); @@ -84,15 +99,16 @@ static __always_inline void __exit_to_kernel_mode(struct pt_regs *regs) trace_hardirqs_on(); } else { - if (regs->exit_rcu) + if (state.exit_rcu) ct_irq_exit(); } } -static void noinstr exit_to_kernel_mode(struct pt_regs *regs) +static void noinstr exit_to_kernel_mode(struct pt_regs *regs, + irqentry_state_t state) { mte_check_tfsr_exit(); - __exit_to_kernel_mode(regs); + __exit_to_kernel_mode(regs, state); } /* @@ -190,9 +206,11 @@ asmlinkage void noinstr asm_exit_to_user_mode(struct pt_regs *regs) * mode. Before this function is called it is not safe to call regular kernel * code, instrumentable code, or any code which may trigger an exception. */ -static void noinstr arm64_enter_nmi(struct pt_regs *regs) +static noinstr irqentry_state_t arm64_enter_nmi(struct pt_regs *regs) { - regs->lockdep_hardirqs = lockdep_hardirqs_enabled(); + irqentry_state_t state; + + state.lockdep = lockdep_hardirqs_enabled(); __nmi_enter(); lockdep_hardirqs_off(CALLER_ADDR0); @@ -201,6 +219,8 @@ static void noinstr arm64_enter_nmi(struct pt_regs *regs) trace_hardirqs_off_finish(); ftrace_nmi_enter(); + + return state; } /* @@ -208,19 +228,18 @@ static void noinstr arm64_enter_nmi(struct pt_regs *regs) * mode. After this function returns it is not safe to call regular kernel * code, instrumentable code, or any code which may trigger an exception. */ -static void noinstr arm64_exit_nmi(struct pt_regs *regs) +static void noinstr arm64_exit_nmi(struct pt_regs *regs, + irqentry_state_t state) { - bool restore = regs->lockdep_hardirqs; - ftrace_nmi_exit(); - if (restore) { + if (state.lockdep) { trace_hardirqs_on_prepare(); lockdep_hardirqs_on_prepare(); } ct_nmi_exit(); lockdep_hardirq_exit(); - if (restore) + if (state.lockdep) lockdep_hardirqs_on(CALLER_ADDR0); __nmi_exit(); } @@ -230,14 +249,18 @@ static void noinstr arm64_exit_nmi(struct pt_regs *regs) * kernel mode. Before this function is called it is not safe to call regular * kernel code, instrumentable code, or any code which may trigger an exception. */ -static void noinstr arm64_enter_el1_dbg(struct pt_regs *regs) +static noinstr irqentry_state_t arm64_enter_el1_dbg(struct pt_regs *regs) { - regs->lockdep_hardirqs = lockdep_hardirqs_enabled(); + irqentry_state_t state; + + state.lockdep = lockdep_hardirqs_enabled(); lockdep_hardirqs_off(CALLER_ADDR0); ct_nmi_enter(); trace_hardirqs_off_finish(); + + return state; } /* @@ -245,17 +268,16 @@ static void noinstr arm64_enter_el1_dbg(struct pt_regs *regs) * kernel mode. After this function returns it is not safe to call regular * kernel code, instrumentable code, or any code which may trigger an exception. */ -static void noinstr arm64_exit_el1_dbg(struct pt_regs *regs) +static void noinstr arm64_exit_el1_dbg(struct pt_regs *regs, + irqentry_state_t state) { - bool restore = regs->lockdep_hardirqs; - - if (restore) { + if (state.lockdep) { trace_hardirqs_on_prepare(); lockdep_hardirqs_on_prepare(); } ct_nmi_exit(); - if (restore) + if (state.lockdep) lockdep_hardirqs_on(CALLER_ADDR0); } @@ -426,78 +448,86 @@ UNHANDLED(el1t, 64, error) static void noinstr el1_abort(struct pt_regs *regs, unsigned long esr) { unsigned long far = read_sysreg(far_el1); + irqentry_state_t state; - enter_from_kernel_mode(regs); + state = enter_from_kernel_mode(regs); local_daif_inherit(regs); do_mem_abort(far, esr, regs); local_daif_mask(); - exit_to_kernel_mode(regs); + exit_to_kernel_mode(regs, state); } static void noinstr el1_pc(struct pt_regs *regs, unsigned long esr) { unsigned long far = read_sysreg(far_el1); + irqentry_state_t state; - enter_from_kernel_mode(regs); + state = enter_from_kernel_mode(regs); local_daif_inherit(regs); do_sp_pc_abort(far, esr, regs); local_daif_mask(); - exit_to_kernel_mode(regs); + exit_to_kernel_mode(regs, state); } static void noinstr el1_undef(struct pt_regs *regs, unsigned long esr) { - enter_from_kernel_mode(regs); + irqentry_state_t state = enter_from_kernel_mode(regs); + local_daif_inherit(regs); do_el1_undef(regs, esr); local_daif_mask(); - exit_to_kernel_mode(regs); + exit_to_kernel_mode(regs, state); } static void noinstr el1_bti(struct pt_regs *regs, unsigned long esr) { - enter_from_kernel_mode(regs); + irqentry_state_t state = enter_from_kernel_mode(regs); + local_daif_inherit(regs); do_el1_bti(regs, esr); local_daif_mask(); - exit_to_kernel_mode(regs); + exit_to_kernel_mode(regs, state); } static void noinstr el1_gcs(struct pt_regs *regs, unsigned long esr) { - enter_from_kernel_mode(regs); + irqentry_state_t state = enter_from_kernel_mode(regs); + local_daif_inherit(regs); do_el1_gcs(regs, esr); local_daif_mask(); - exit_to_kernel_mode(regs); + exit_to_kernel_mode(regs, state); } static void noinstr el1_mops(struct pt_regs *regs, unsigned long esr) { - enter_from_kernel_mode(regs); + irqentry_state_t state = enter_from_kernel_mode(regs); + local_daif_inherit(regs); do_el1_mops(regs, esr); local_daif_mask(); - exit_to_kernel_mode(regs); + exit_to_kernel_mode(regs, state); } static void noinstr el1_dbg(struct pt_regs *regs, unsigned long esr) { unsigned long far = read_sysreg(far_el1); + irqentry_state_t state; - arm64_enter_el1_dbg(regs); + state = arm64_enter_el1_dbg(regs); if (!cortex_a76_erratum_1463225_debug_handler(regs)) do_debug_exception(far, esr, regs); - arm64_exit_el1_dbg(regs); + arm64_exit_el1_dbg(regs, state); } static void noinstr el1_fpac(struct pt_regs *regs, unsigned long esr) { - enter_from_kernel_mode(regs); + irqentry_state_t state = enter_from_kernel_mode(regs); + local_daif_inherit(regs); do_el1_fpac(regs, esr); local_daif_mask(); - exit_to_kernel_mode(regs); + exit_to_kernel_mode(regs, state); } asmlinkage void noinstr el1h_64_sync_handler(struct pt_regs *regs) @@ -546,15 +576,16 @@ asmlinkage void noinstr el1h_64_sync_handler(struct pt_regs *regs) static __always_inline void __el1_pnmi(struct pt_regs *regs, void (*handler)(struct pt_regs *)) { - arm64_enter_nmi(regs); + irqentry_state_t state = arm64_enter_nmi(regs); + do_interrupt_handler(regs, handler); - arm64_exit_nmi(regs); + arm64_exit_nmi(regs, state); } static __always_inline void __el1_irq(struct pt_regs *regs, void (*handler)(struct pt_regs *)) { - enter_from_kernel_mode(regs); + irqentry_state_t state = enter_from_kernel_mode(regs); irq_enter_rcu(); do_interrupt_handler(regs, handler); @@ -562,7 +593,7 @@ static __always_inline void __el1_irq(struct pt_regs *regs, arm64_preempt_schedule_irq(); - exit_to_kernel_mode(regs); + exit_to_kernel_mode(regs, state); } static void noinstr el1_interrupt(struct pt_regs *regs, void (*handler)(struct pt_regs *)) @@ -588,11 +619,12 @@ asmlinkage void noinstr el1h_64_fiq_handler(struct pt_regs *regs) asmlinkage void noinstr el1h_64_error_handler(struct pt_regs *regs) { unsigned long esr = read_sysreg(esr_el1); + irqentry_state_t state; local_daif_restore(DAIF_ERRCTX); - arm64_enter_nmi(regs); + state = arm64_enter_nmi(regs); do_serror(regs, esr); - arm64_exit_nmi(regs); + arm64_exit_nmi(regs, state); } static void noinstr el0_da(struct pt_regs *regs, unsigned long esr) @@ -855,12 +887,13 @@ asmlinkage void noinstr el0t_64_fiq_handler(struct pt_regs *regs) static void noinstr __el0_error_handler_common(struct pt_regs *regs) { unsigned long esr = read_sysreg(esr_el1); + irqentry_state_t state; enter_from_user_mode(regs); local_daif_restore(DAIF_ERRCTX); - arm64_enter_nmi(regs); + state = arm64_enter_nmi(regs); do_serror(regs, esr); - arm64_exit_nmi(regs); + arm64_exit_nmi(regs, state); local_daif_restore(DAIF_PROCCTX); exit_to_user_mode(regs); } @@ -968,6 +1001,7 @@ asmlinkage void noinstr __noreturn handle_bad_stack(struct pt_regs *regs) asmlinkage noinstr unsigned long __sdei_handler(struct pt_regs *regs, struct sdei_registered_event *arg) { + irqentry_state_t state; unsigned long ret; /* @@ -992,9 +1026,9 @@ __sdei_handler(struct pt_regs *regs, struct sdei_registered_event *arg) else if (cpu_has_pan()) set_pstate_pan(0); - arm64_enter_nmi(regs); + state = arm64_enter_nmi(regs); ret = do_sdei_event(regs, arg); - arm64_exit_nmi(regs); + arm64_exit_nmi(regs, state); return ret; } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:18:23 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:18:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849982.1264451 (Exim 4.92) (envelope-from ) id 1tJVPd-00023Q-TP; Fri, 06 Dec 2024 10:18:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849982.1264451; Fri, 06 Dec 2024 10: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 1tJVPd-00023J-Qk; Fri, 06 Dec 2024 10:18:17 +0000 Received: by outflank-mailman (input) for mailman id 849982; Fri, 06 Dec 2024 10: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 1tJVPc-0001of-PX for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:16 +0000 Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 66547a32-b3bb-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 11:18:15 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.162.112]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4Y4Rwm0C8Qz1T4md; Fri, 6 Dec 2024 18:15:52 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id EF8031401DC; Fri, 6 Dec 2024 18:18:11 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:10 +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: 66547a32-b3bb-11ef-a0d5-8be0dac302b0 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 04/22] arm64: entry: Rework arm64_preempt_schedule_irq() Date: Fri, 6 Dec 2024 18:17:26 +0800 Message-ID: <20241206101744.4161990-5-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) The generic entry do preempt_schedule_irq() by checking if need_resched() satisfied, but arm64 has some of its own additional checks such as GIC priority masking. In preparation for moving arm64 over to the generic entry code, rework arm64_preempt_schedule_irq() to check whether it need resched in a check function called arm64_need_resched(). No functional changes. Signed-off-by: Jinjie Ruan --- arch/arm64/kernel/entry-common.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c index 7a588515ee07..da68c089b74b 100644 --- a/arch/arm64/kernel/entry-common.c +++ b/arch/arm64/kernel/entry-common.c @@ -83,10 +83,10 @@ DEFINE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); #define need_irq_preemption() (IS_ENABLED(CONFIG_PREEMPTION)) #endif -static void __sched arm64_preempt_schedule_irq(void) +static inline bool arm64_need_resched(void) { if (!need_irq_preemption()) - return; + return false; /* * Note: thread_info::preempt_count includes both thread_info::count @@ -94,7 +94,7 @@ static void __sched arm64_preempt_schedule_irq(void) * preempt_count(). */ if (READ_ONCE(current_thread_info()->preempt_count) != 0) - return; + return false; /* * DAIF.DA are cleared at the start of IRQ/FIQ handling, and when GIC @@ -103,7 +103,7 @@ static void __sched arm64_preempt_schedule_irq(void) * DAIF we must have handled an NMI, so skip preemption. */ if (system_uses_irq_prio_masking() && read_sysreg(daif)) - return; + return false; /* * Preempting a task from an IRQ means we leave copies of PSTATE @@ -113,8 +113,10 @@ static void __sched arm64_preempt_schedule_irq(void) * Only allow a task to be preempted once cpufeatures have been * enabled. */ - if (system_capabilities_finalized()) - preempt_schedule_irq(); + if (!system_capabilities_finalized()) + return false; + + return true; } /* @@ -139,7 +141,8 @@ static __always_inline void __exit_to_kernel_mode(struct pt_regs *regs, return; } - arm64_preempt_schedule_irq(); + if (arm64_need_resched()) + preempt_schedule_irq(); trace_hardirqs_on(); } else { -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:18:23 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:18:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849984.1264461 (Exim 4.92) (envelope-from ) id 1tJVPe-0002C4-Hl; Fri, 06 Dec 2024 10:18:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849984.1264461; Fri, 06 Dec 2024 10: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 1tJVPe-0002BU-Ag; Fri, 06 Dec 2024 10:18:18 +0000 Received: by outflank-mailman (input) for mailman id 849984; Fri, 06 Dec 2024 10:18: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 1tJVPd-0001om-4A for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:17 +0000 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 66085406-b3bb-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 11:18:14 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.88.214]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4Y4Rwl2yr3z2DhB0; Fri, 6 Dec 2024 18:15:51 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id C04891A016C; Fri, 6 Dec 2024 18:18:10 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:09 +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: 66085406-b3bb-11ef-99a3-01e77a169b0f From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 03/22] arm64: entry: Move arm64_preempt_schedule_irq() into __exit_to_kernel_mode() Date: Fri, 6 Dec 2024 18:17:25 +0800 Message-ID: <20241206101744.4161990-4-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) The generic entry code try to reschedule every time when the kernel mode non-NMI exception return. At the moment, arm64 only reschedule every time when EL1 irq exception return; In preparation for moving arm64 over to the generic entry code, move arm64_preempt_schedule_irq() into exit_to_kernel_mode(), so not only EL1 irq but also all EL1 non-NMI exception return, there is a chance to reschedule. And only if irqs are enabled when the exception trapped, there may be a chance to reschedule after the exceptions have been handled, so move arm64_preempt_schedule_irq() into regs_irqs_disabled() check false block, but it will try to reschedule only when TINY_RCU is enabled or current is not an idle task. As Mark pointed out, this change will have the following 2 key impact: - " We'll preempt even without taking a "real" interrupt. That shouldn't result in preemption that wasn't possible before, but it does change the probability of preempting at certain points, and might have a performance impact, so probably warrants a benchmark." - " We will not preempt when taking interrupts from a region of kernel code where IRQs are enabled but RCU is not watching, matching the behaviour of the generic entry code. This has the potential to introduce livelock if we can ever have a screaming interrupt in such a region, so we'll need to go figure out whether that's actually a problem. Having this as a separate patch will make it easier to test/bisect for that specifically." Suggested-by: Mark Rutland Signed-off-by: Jinjie Ruan --- arch/arm64/kernel/entry-common.c | 88 ++++++++++++++++---------------- 1 file changed, 44 insertions(+), 44 deletions(-) diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c index 1687627b2ecf..7a588515ee07 100644 --- a/arch/arm64/kernel/entry-common.c +++ b/arch/arm64/kernel/entry-common.c @@ -75,6 +75,48 @@ static noinstr irqentry_state_t enter_from_kernel_mode(struct pt_regs *regs) return state; } +#ifdef CONFIG_PREEMPT_DYNAMIC +DEFINE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); +#define need_irq_preemption() \ + (static_branch_unlikely(&sk_dynamic_irqentry_exit_cond_resched)) +#else +#define need_irq_preemption() (IS_ENABLED(CONFIG_PREEMPTION)) +#endif + +static void __sched arm64_preempt_schedule_irq(void) +{ + if (!need_irq_preemption()) + return; + + /* + * Note: thread_info::preempt_count includes both thread_info::count + * and thread_info::need_resched, and is not equivalent to + * preempt_count(). + */ + if (READ_ONCE(current_thread_info()->preempt_count) != 0) + return; + + /* + * DAIF.DA are cleared at the start of IRQ/FIQ handling, and when GIC + * priority masking is used the GIC irqchip driver will clear DAIF.IF + * using gic_arch_enable_irqs() for normal IRQs. If anything is set in + * DAIF we must have handled an NMI, so skip preemption. + */ + if (system_uses_irq_prio_masking() && read_sysreg(daif)) + return; + + /* + * Preempting a task from an IRQ means we leave copies of PSTATE + * on the stack. cpufeature's enable calls may modify PSTATE, but + * resuming one of these preempted tasks would undo those changes. + * + * Only allow a task to be preempted once cpufeatures have been + * enabled. + */ + if (system_capabilities_finalized()) + preempt_schedule_irq(); +} + /* * Handle IRQ/context state management when exiting to kernel mode. * After this function returns it is not safe to call regular kernel code, @@ -97,6 +139,8 @@ static __always_inline void __exit_to_kernel_mode(struct pt_regs *regs, return; } + arm64_preempt_schedule_irq(); + trace_hardirqs_on(); } else { if (state.exit_rcu) @@ -281,48 +325,6 @@ static void noinstr arm64_exit_el1_dbg(struct pt_regs *regs, lockdep_hardirqs_on(CALLER_ADDR0); } -#ifdef CONFIG_PREEMPT_DYNAMIC -DEFINE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); -#define need_irq_preemption() \ - (static_branch_unlikely(&sk_dynamic_irqentry_exit_cond_resched)) -#else -#define need_irq_preemption() (IS_ENABLED(CONFIG_PREEMPTION)) -#endif - -static void __sched arm64_preempt_schedule_irq(void) -{ - if (!need_irq_preemption()) - return; - - /* - * Note: thread_info::preempt_count includes both thread_info::count - * and thread_info::need_resched, and is not equivalent to - * preempt_count(). - */ - if (READ_ONCE(current_thread_info()->preempt_count) != 0) - return; - - /* - * DAIF.DA are cleared at the start of IRQ/FIQ handling, and when GIC - * priority masking is used the GIC irqchip driver will clear DAIF.IF - * using gic_arch_enable_irqs() for normal IRQs. If anything is set in - * DAIF we must have handled an NMI, so skip preemption. - */ - if (system_uses_irq_prio_masking() && read_sysreg(daif)) - return; - - /* - * Preempting a task from an IRQ means we leave copies of PSTATE - * on the stack. cpufeature's enable calls may modify PSTATE, but - * resuming one of these preempted tasks would undo those changes. - * - * Only allow a task to be preempted once cpufeatures have been - * enabled. - */ - if (system_capabilities_finalized()) - preempt_schedule_irq(); -} - static void do_interrupt_handler(struct pt_regs *regs, void (*handler)(struct pt_regs *)) { @@ -591,8 +593,6 @@ static __always_inline void __el1_irq(struct pt_regs *regs, do_interrupt_handler(regs, handler); irq_exit_rcu(); - arm64_preempt_schedule_irq(); - exit_to_kernel_mode(regs, state); } static void noinstr el1_interrupt(struct pt_regs *regs, -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:18:23 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:18:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849981.1264441 (Exim 4.92) (envelope-from ) id 1tJVPb-0001ou-N6; Fri, 06 Dec 2024 10:18:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849981.1264441; Fri, 06 Dec 2024 10:18: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 1tJVPb-0001on-JX; Fri, 06 Dec 2024 10:18:15 +0000 Received: by outflank-mailman (input) for mailman id 849981; Fri, 06 Dec 2024 10:18: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 1tJVPa-0001of-Et for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:14 +0000 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6437bfc3-b3bb-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 11:18:11 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.163.252]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Y4RxJ14MkzqTVR; Fri, 6 Dec 2024 18:16:20 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id 5BBA41800D9; Fri, 6 Dec 2024 18:18:08 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:06 +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: 6437bfc3-b3bb-11ef-a0d5-8be0dac302b0 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 01/22] arm64: ptrace: Replace interrupts_enabled() with regs_irqs_disabled() Date: Fri, 6 Dec 2024 18:17:23 +0800 Message-ID: <20241206101744.4161990-2-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) The generic entry code expects architecture code to provide regs_irqs_disabled(regs) function, but arm64 does not have this and provides inerrupts_enabled(regs), which has the opposite polarity. In preparation for moving arm64 over to the generic entry code, relace arm64's interrupts_enabled() with regs_irqs_disabled() and update its callers under arch/arm64. For the moment, a definition of interrupts_enabled() is provided for the GICv3 driver. Once arch/arm implement regs_irqs_disabled(), this can be removed. No functional changes. Suggested-by: Mark Rutland Signed-off-by: Jinjie Ruan --- arch/arm64/include/asm/daifflags.h | 2 +- arch/arm64/include/asm/ptrace.h | 7 +++++++ arch/arm64/include/asm/xen/events.h | 2 +- arch/arm64/kernel/acpi.c | 2 +- arch/arm64/kernel/debug-monitors.c | 2 +- arch/arm64/kernel/entry-common.c | 4 ++-- arch/arm64/kernel/sdei.c | 2 +- 7 files changed, 14 insertions(+), 7 deletions(-) diff --git a/arch/arm64/include/asm/daifflags.h b/arch/arm64/include/asm/daifflags.h index fbb5c99eb2f9..5fca48009043 100644 --- a/arch/arm64/include/asm/daifflags.h +++ b/arch/arm64/include/asm/daifflags.h @@ -128,7 +128,7 @@ static inline void local_daif_inherit(struct pt_regs *regs) { unsigned long flags = regs->pstate & DAIF_MASK; - if (interrupts_enabled(regs)) + if (!regs_irqs_disabled(regs)) trace_hardirqs_on(); if (system_uses_irq_prio_masking()) diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h index 47ff8654c5ec..bcfa96880377 100644 --- a/arch/arm64/include/asm/ptrace.h +++ b/arch/arm64/include/asm/ptrace.h @@ -214,9 +214,16 @@ static inline void forget_syscall(struct pt_regs *regs) (regs)->pmr == GIC_PRIO_IRQON : \ true) +/* + * Used by the GICv3 driver, can be removed once arch/arm implements + * regs_irqs_disabled() directly. + */ #define interrupts_enabled(regs) \ (!((regs)->pstate & PSR_I_BIT) && irqs_priority_unmasked(regs)) +#define regs_irqs_disabled(regs) \ + (((regs)->pstate & PSR_I_BIT) || (!irqs_priority_unmasked(regs))) + #define fast_interrupts_enabled(regs) \ (!((regs)->pstate & PSR_F_BIT)) diff --git a/arch/arm64/include/asm/xen/events.h b/arch/arm64/include/asm/xen/events.h index 2788e95d0ff0..2977b5fe068d 100644 --- a/arch/arm64/include/asm/xen/events.h +++ b/arch/arm64/include/asm/xen/events.h @@ -14,7 +14,7 @@ enum ipi_vector { static inline int xen_irqs_disabled(struct pt_regs *regs) { - return !interrupts_enabled(regs); + return regs_irqs_disabled(regs); } #define xchg_xen_ulong(ptr, val) xchg((ptr), (val)) diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c index e6f66491fbe9..732f89daae23 100644 --- a/arch/arm64/kernel/acpi.c +++ b/arch/arm64/kernel/acpi.c @@ -403,7 +403,7 @@ int apei_claim_sea(struct pt_regs *regs) return_to_irqs_enabled = !irqs_disabled_flags(arch_local_save_flags()); if (regs) - return_to_irqs_enabled = interrupts_enabled(regs); + return_to_irqs_enabled = !regs_irqs_disabled(regs); /* * SEA can interrupt SError, mask it and describe this as an NMI so diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c index 58f047de3e1c..460c09d03a73 100644 --- a/arch/arm64/kernel/debug-monitors.c +++ b/arch/arm64/kernel/debug-monitors.c @@ -231,7 +231,7 @@ static void send_user_sigtrap(int si_code) if (WARN_ON(!user_mode(regs))) return; - if (interrupts_enabled(regs)) + if (!regs_irqs_disabled(regs)) local_irq_enable(); arm64_force_sig_fault(SIGTRAP, si_code, instruction_pointer(regs), diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c index b260ddc4d3e9..c547e70428d3 100644 --- a/arch/arm64/kernel/entry-common.c +++ b/arch/arm64/kernel/entry-common.c @@ -73,7 +73,7 @@ static __always_inline void __exit_to_kernel_mode(struct pt_regs *regs) { lockdep_assert_irqs_disabled(); - if (interrupts_enabled(regs)) { + if (!regs_irqs_disabled(regs)) { if (regs->exit_rcu) { trace_hardirqs_on_prepare(); lockdep_hardirqs_on_prepare(); @@ -569,7 +569,7 @@ static void noinstr el1_interrupt(struct pt_regs *regs, { write_sysreg(DAIF_PROCCTX_NOIRQ, daif); - if (IS_ENABLED(CONFIG_ARM64_PSEUDO_NMI) && !interrupts_enabled(regs)) + if (IS_ENABLED(CONFIG_ARM64_PSEUDO_NMI) && regs_irqs_disabled(regs)) __el1_pnmi(regs, handler); else __el1_irq(regs, handler); diff --git a/arch/arm64/kernel/sdei.c b/arch/arm64/kernel/sdei.c index 255d12f881c2..27a17da635d8 100644 --- a/arch/arm64/kernel/sdei.c +++ b/arch/arm64/kernel/sdei.c @@ -247,7 +247,7 @@ unsigned long __kprobes do_sdei_event(struct pt_regs *regs, * If we interrupted the kernel with interrupts masked, we always go * back to wherever we came from. */ - if (mode == kernel_mode && !interrupts_enabled(regs)) + if (mode == kernel_mode && regs_irqs_disabled(regs)) return SDEI_EV_HANDLED; /* -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:18:23 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:18:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849985.1264472 (Exim 4.92) (envelope-from ) id 1tJVPf-0002Q8-27; Fri, 06 Dec 2024 10:18:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849985.1264472; Fri, 06 Dec 2024 10:18:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJVPe-0002Lp-Sd; Fri, 06 Dec 2024 10:18:18 +0000 Received: by outflank-mailman (input) for mailman id 849985; Fri, 06 Dec 2024 10:18: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 1tJVPd-0001of-86 for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:17 +0000 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 67195428-b3bb-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 11:18:16 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4Y4Rw20yXpz1V4WK; Fri, 6 Dec 2024 18:15:14 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id 318F818009B; Fri, 6 Dec 2024 18:18:13 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:11 +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: 67195428-b3bb-11ef-a0d5-8be0dac302b0 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 05/22] arm64: entry: Use preempt_count() and need_resched() helper Date: Fri, 6 Dec 2024 18:17:27 +0800 Message-ID: <20241206101744.4161990-6-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) The generic entry code uses preempt_count() and need_resched() helpers to check if it is time to resched. Currently, arm64 use its own check logic, that is "READ_ONCE(current_thread_info()->preempt_count == 0", which is equivalent to "preempt_count() == 0 && need_resched()". In preparation for moving arm64 over to the generic entry code, use these helpers to replace arm64's own code and move it ahead. No functional changes. Signed-off-by: Jinjie Ruan --- arch/arm64/kernel/entry-common.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c index da68c089b74b..efd1a990d138 100644 --- a/arch/arm64/kernel/entry-common.c +++ b/arch/arm64/kernel/entry-common.c @@ -88,14 +88,6 @@ static inline bool arm64_need_resched(void) if (!need_irq_preemption()) return false; - /* - * Note: thread_info::preempt_count includes both thread_info::count - * and thread_info::need_resched, and is not equivalent to - * preempt_count(). - */ - if (READ_ONCE(current_thread_info()->preempt_count) != 0) - return false; - /* * DAIF.DA are cleared at the start of IRQ/FIQ handling, and when GIC * priority masking is used the GIC irqchip driver will clear DAIF.IF @@ -141,8 +133,10 @@ static __always_inline void __exit_to_kernel_mode(struct pt_regs *regs, return; } - if (arm64_need_resched()) - preempt_schedule_irq(); + if (!preempt_count() && need_resched()) { + if (arm64_need_resched()) + preempt_schedule_irq(); + } trace_hardirqs_on(); } else { -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:18:23 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:18:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849989.1264521 (Exim 4.92) (envelope-from ) id 1tJVPj-0003n7-Iu; Fri, 06 Dec 2024 10:18:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849989.1264521; Fri, 06 Dec 2024 10: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 1tJVPj-0003lo-EK; Fri, 06 Dec 2024 10:18:23 +0000 Received: by outflank-mailman (input) for mailman id 849989; Fri, 06 Dec 2024 10:18: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 1tJVPh-0001om-JO for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:21 +0000 Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 69236c05-b3bb-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 11:18:19 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.162.112]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4Y4Rws4GZ2z1kvVr; Fri, 6 Dec 2024 18:15:57 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id C093C1402E0; Fri, 6 Dec 2024 18:18:16 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:15 +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: 69236c05-b3bb-11ef-99a3-01e77a169b0f From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 08/22] arm64: entry: Use different helpers to check resched for PREEMPT_DYNAMIC Date: Fri, 6 Dec 2024 18:17:30 +0800 Message-ID: <20241206101744.4161990-9-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) In generic entry, when PREEMPT_DYNAMIC is enabled or disabled, two different helpers are used to check whether resched is required and some common code is reused. In preparation for moving arm64 over to the generic entry code, use new helper to check resched when PREEMPT_DYNAMIC enabled and reuse common code for the disabled case. No functional changes. Signed-off-by: Jinjie Ruan --- arch/arm64/include/asm/preempt.h | 3 +++ arch/arm64/kernel/entry-common.c | 21 +++++++++++---------- 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/arch/arm64/include/asm/preempt.h b/arch/arm64/include/asm/preempt.h index d0f93385bd85..0f0ba250efe8 100644 --- a/arch/arm64/include/asm/preempt.h +++ b/arch/arm64/include/asm/preempt.h @@ -93,11 +93,14 @@ void dynamic_preempt_schedule(void); #define __preempt_schedule() dynamic_preempt_schedule() void dynamic_preempt_schedule_notrace(void); #define __preempt_schedule_notrace() dynamic_preempt_schedule_notrace() +void dynamic_irqentry_exit_cond_resched(void); +#define irqentry_exit_cond_resched() dynamic_irqentry_exit_cond_resched() #else /* CONFIG_PREEMPT_DYNAMIC */ #define __preempt_schedule() preempt_schedule() #define __preempt_schedule_notrace() preempt_schedule_notrace() +#define irqentry_exit_cond_resched() raw_irqentry_exit_cond_resched() #endif /* CONFIG_PREEMPT_DYNAMIC */ #endif /* CONFIG_PREEMPTION */ diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c index 029f8bd72f8a..015a65d19b52 100644 --- a/arch/arm64/kernel/entry-common.c +++ b/arch/arm64/kernel/entry-common.c @@ -75,10 +75,6 @@ static noinstr irqentry_state_t enter_from_kernel_mode(struct pt_regs *regs) return state; } -#ifdef CONFIG_PREEMPT_DYNAMIC -DEFINE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); -#endif - static inline bool arm64_need_resched(void) { /* @@ -106,17 +102,22 @@ static inline bool arm64_need_resched(void) void raw_irqentry_exit_cond_resched(void) { -#ifdef CONFIG_PREEMPT_DYNAMIC - if (!static_branch_unlikely(&sk_dynamic_irqentry_exit_cond_resched)) - return; -#endif - if (!preempt_count()) { if (need_resched() && arm64_need_resched()) preempt_schedule_irq(); } } +#ifdef CONFIG_PREEMPT_DYNAMIC +DEFINE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); +void dynamic_irqentry_exit_cond_resched(void) +{ + if (!static_branch_unlikely(&sk_dynamic_irqentry_exit_cond_resched)) + return; + raw_irqentry_exit_cond_resched(); +} +#endif + /* * Handle IRQ/context state management when exiting to kernel mode. * After this function returns it is not safe to call regular kernel code, @@ -140,7 +141,7 @@ static __always_inline void __exit_to_kernel_mode(struct pt_regs *regs, } if (IS_ENABLED(CONFIG_PREEMPTION)) - raw_irqentry_exit_cond_resched(); + irqentry_exit_cond_resched(); trace_hardirqs_on(); } else { -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:18:26 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:18:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849992.1264531 (Exim 4.92) (envelope-from ) id 1tJVPl-0004AL-Up; Fri, 06 Dec 2024 10:18:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849992.1264531; Fri, 06 Dec 2024 10: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 1tJVPl-0004A1-OC; Fri, 06 Dec 2024 10:18:25 +0000 Received: by outflank-mailman (input) for mailman id 849992; Fri, 06 Dec 2024 10:18: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 1tJVPk-0001om-CX for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:24 +0000 Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 69f24653-b3bb-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 11:18:20 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.88.163]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4Y4Rwt0sCJz1T6WV; Fri, 6 Dec 2024 18:15:58 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id 0A16B180041; Fri, 6 Dec 2024 18:18:18 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:16 +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: 69f24653-b3bb-11ef-99a3-01e77a169b0f From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 09/22] entry: Split generic entry into irq and syscall Date: Fri, 6 Dec 2024 18:17:31 +0800 Message-ID: <20241206101744.4161990-10-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) As Mark pointed out, do not try to switch to *all* the generic entry code in one go. The regular entry state management (e.g. enter_from_user_mode() and exit_to_user_mode()) is largely separate from the syscall state management. Move arm64 over to enter_from_user_mode() and exit_to_user_mode() without needing to use any of the generic syscall logic. Doing that first, *then* moving over to the generic syscall handling would be much easier to review/test/bisect, and if there are any ABI issues with the syscall handling in particular, it will be easier to handle those in isolation. So split generic entry into irq entry and syscall code, which will make review work easier and switch to generic entry clear. Introdue two configs called GENERIC_SYSCALL and GENERIC_IRQ_ENTRY, which control the irq entry and syscall parts of the generic code respectively. And split the header file irq-entry-common.h from entry-common.h for GENERIC_IRQ_ENTRY. Suggested-by: Mark Rutland Signed-off-by: Jinjie Ruan --- MAINTAINERS | 1 + arch/Kconfig | 8 + include/linux/entry-common.h | 382 +----------------------------- include/linux/irq-entry-common.h | 389 +++++++++++++++++++++++++++++++ kernel/entry/Makefile | 3 +- kernel/entry/common.c | 160 +------------ kernel/entry/syscall-common.c | 159 +++++++++++++ kernel/sched/core.c | 8 +- 8 files changed, 565 insertions(+), 545 deletions(-) create mode 100644 include/linux/irq-entry-common.h create mode 100644 kernel/entry/syscall-common.c diff --git a/MAINTAINERS b/MAINTAINERS index 21f855fe468b..7a6e87587101 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9585,6 +9585,7 @@ S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core/entry F: include/linux/entry-common.h F: include/linux/entry-kvm.h +F: include/linux/irq-entry-common.h F: kernel/entry/ GENERIC GPIO I2C DRIVER diff --git a/arch/Kconfig b/arch/Kconfig index 6682b2a53e34..5a454eff780b 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -64,8 +64,16 @@ config HOTPLUG_PARALLEL bool select HOTPLUG_SPLIT_STARTUP +config GENERIC_IRQ_ENTRY + bool + +config GENERIC_SYSCALL + bool + config GENERIC_ENTRY bool + select GENERIC_IRQ_ENTRY + select GENERIC_SYSCALL config KPROBES bool "Kprobes" diff --git a/include/linux/entry-common.h b/include/linux/entry-common.h index fc61d0205c97..b3233e8328c5 100644 --- a/include/linux/entry-common.h +++ b/include/linux/entry-common.h @@ -2,27 +2,15 @@ #ifndef __LINUX_ENTRYCOMMON_H #define __LINUX_ENTRYCOMMON_H -#include +#include #include -#include #include #include -#include #include #include -#include -#include #include -/* - * Define dummy _TIF work flags if not defined by the architecture or for - * disabled functionality. - */ -#ifndef _TIF_PATCH_PENDING -# define _TIF_PATCH_PENDING (0) -#endif - #ifndef _TIF_UPROBE # define _TIF_UPROBE (0) #endif @@ -55,69 +43,6 @@ SYSCALL_WORK_SYSCALL_EXIT_TRAP | \ ARCH_SYSCALL_WORK_EXIT) -/* - * TIF flags handled in exit_to_user_mode_loop() - */ -#ifndef ARCH_EXIT_TO_USER_MODE_WORK -# define ARCH_EXIT_TO_USER_MODE_WORK (0) -#endif - -#define EXIT_TO_USER_MODE_WORK \ - (_TIF_SIGPENDING | _TIF_NOTIFY_RESUME | _TIF_UPROBE | \ - _TIF_NEED_RESCHED | _TIF_NEED_RESCHED_LAZY | \ - _TIF_PATCH_PENDING | _TIF_NOTIFY_SIGNAL | \ - ARCH_EXIT_TO_USER_MODE_WORK) - -/** - * arch_enter_from_user_mode - Architecture specific sanity check for user mode regs - * @regs: Pointer to currents pt_regs - * - * Defaults to an empty implementation. Can be replaced by architecture - * specific code. - * - * Invoked from syscall_enter_from_user_mode() in the non-instrumentable - * section. Use __always_inline so the compiler cannot push it out of line - * and make it instrumentable. - */ -static __always_inline void arch_enter_from_user_mode(struct pt_regs *regs); - -#ifndef arch_enter_from_user_mode -static __always_inline void arch_enter_from_user_mode(struct pt_regs *regs) {} -#endif - -/** - * enter_from_user_mode - Establish state when coming from user mode - * - * Syscall/interrupt entry disables interrupts, but user mode is traced as - * interrupts enabled. Also with NO_HZ_FULL RCU might be idle. - * - * 1) Tell lockdep that interrupts are disabled - * 2) Invoke context tracking if enabled to reactivate RCU - * 3) Trace interrupts off state - * - * Invoked from architecture specific syscall entry code with interrupts - * disabled. The calling code has to be non-instrumentable. When the - * function returns all state is correct and interrupts are still - * disabled. The subsequent functions can be instrumented. - * - * This is invoked when there is architecture specific functionality to be - * done between establishing state and enabling interrupts. The caller must - * enable interrupts before invoking syscall_enter_from_user_mode_work(). - */ -static __always_inline void enter_from_user_mode(struct pt_regs *regs) -{ - arch_enter_from_user_mode(regs); - lockdep_hardirqs_off(CALLER_ADDR0); - - CT_WARN_ON(__ct_state() != CT_STATE_USER); - user_exit_irqoff(); - - instrumentation_begin(); - kmsan_unpoison_entry_regs(regs); - trace_hardirqs_off_finish(); - instrumentation_end(); -} - /** * syscall_enter_from_user_mode_prepare - Establish state and enable interrupts * @regs: Pointer to currents pt_regs @@ -202,170 +127,6 @@ static __always_inline long syscall_enter_from_user_mode(struct pt_regs *regs, l return ret; } -/** - * local_irq_enable_exit_to_user - Exit to user variant of local_irq_enable() - * @ti_work: Cached TIF flags gathered with interrupts disabled - * - * Defaults to local_irq_enable(). Can be supplied by architecture specific - * code. - */ -static inline void local_irq_enable_exit_to_user(unsigned long ti_work); - -#ifndef local_irq_enable_exit_to_user -static inline void local_irq_enable_exit_to_user(unsigned long ti_work) -{ - local_irq_enable(); -} -#endif - -/** - * local_irq_disable_exit_to_user - Exit to user variant of local_irq_disable() - * - * Defaults to local_irq_disable(). Can be supplied by architecture specific - * code. - */ -static inline void local_irq_disable_exit_to_user(void); - -#ifndef local_irq_disable_exit_to_user -static inline void local_irq_disable_exit_to_user(void) -{ - local_irq_disable(); -} -#endif - -/** - * arch_exit_to_user_mode_work - Architecture specific TIF work for exit - * to user mode. - * @regs: Pointer to currents pt_regs - * @ti_work: Cached TIF flags gathered with interrupts disabled - * - * Invoked from exit_to_user_mode_loop() with interrupt enabled - * - * Defaults to NOOP. Can be supplied by architecture specific code. - */ -static inline void arch_exit_to_user_mode_work(struct pt_regs *regs, - unsigned long ti_work); - -#ifndef arch_exit_to_user_mode_work -static inline void arch_exit_to_user_mode_work(struct pt_regs *regs, - unsigned long ti_work) -{ -} -#endif - -/** - * arch_exit_to_user_mode_prepare - Architecture specific preparation for - * exit to user mode. - * @regs: Pointer to currents pt_regs - * @ti_work: Cached TIF flags gathered with interrupts disabled - * - * Invoked from exit_to_user_mode_prepare() with interrupt disabled as the last - * function before return. Defaults to NOOP. - */ -static inline void arch_exit_to_user_mode_prepare(struct pt_regs *regs, - unsigned long ti_work); - -#ifndef arch_exit_to_user_mode_prepare -static inline void arch_exit_to_user_mode_prepare(struct pt_regs *regs, - unsigned long ti_work) -{ -} -#endif - -/** - * arch_exit_to_user_mode - Architecture specific final work before - * exit to user mode. - * - * Invoked from exit_to_user_mode() with interrupt disabled as the last - * function before return. Defaults to NOOP. - * - * This needs to be __always_inline because it is non-instrumentable code - * invoked after context tracking switched to user mode. - * - * An architecture implementation must not do anything complex, no locking - * etc. The main purpose is for speculation mitigations. - */ -static __always_inline void arch_exit_to_user_mode(void); - -#ifndef arch_exit_to_user_mode -static __always_inline void arch_exit_to_user_mode(void) { } -#endif - -/** - * arch_do_signal_or_restart - Architecture specific signal delivery function - * @regs: Pointer to currents pt_regs - * - * Invoked from exit_to_user_mode_loop(). - */ -void arch_do_signal_or_restart(struct pt_regs *regs); - -/** - * exit_to_user_mode_loop - do any pending work before leaving to user space - */ -unsigned long exit_to_user_mode_loop(struct pt_regs *regs, - unsigned long ti_work); - -/** - * exit_to_user_mode_prepare - call exit_to_user_mode_loop() if required - * @regs: Pointer to pt_regs on entry stack - * - * 1) check that interrupts are disabled - * 2) call tick_nohz_user_enter_prepare() - * 3) call exit_to_user_mode_loop() if any flags from - * EXIT_TO_USER_MODE_WORK are set - * 4) check that interrupts are still disabled - */ -static __always_inline void exit_to_user_mode_prepare(struct pt_regs *regs) -{ - unsigned long ti_work; - - lockdep_assert_irqs_disabled(); - - /* Flush pending rcuog wakeup before the last need_resched() check */ - tick_nohz_user_enter_prepare(); - - ti_work = read_thread_flags(); - if (unlikely(ti_work & EXIT_TO_USER_MODE_WORK)) - ti_work = exit_to_user_mode_loop(regs, ti_work); - - arch_exit_to_user_mode_prepare(regs, ti_work); - - /* Ensure that kernel state is sane for a return to userspace */ - kmap_assert_nomap(); - lockdep_assert_irqs_disabled(); - lockdep_sys_exit(); -} - -/** - * exit_to_user_mode - Fixup state when exiting to user mode - * - * Syscall/interrupt exit enables interrupts, but the kernel state is - * interrupts disabled when this is invoked. Also tell RCU about it. - * - * 1) Trace interrupts on state - * 2) Invoke context tracking if enabled to adjust RCU state - * 3) Invoke architecture specific last minute exit code, e.g. speculation - * mitigations, etc.: arch_exit_to_user_mode() - * 4) Tell lockdep that interrupts are enabled - * - * Invoked from architecture specific code when syscall_exit_to_user_mode() - * is not suitable as the last step before returning to userspace. Must be - * invoked with interrupts disabled and the caller must be - * non-instrumentable. - * The caller has to invoke syscall_exit_to_user_mode_work() before this. - */ -static __always_inline void exit_to_user_mode(void) -{ - instrumentation_begin(); - trace_hardirqs_on_prepare(); - lockdep_hardirqs_on_prepare(); - instrumentation_end(); - - user_enter_irqoff(); - arch_exit_to_user_mode(); - lockdep_hardirqs_on(CALLER_ADDR0); -} - /** * syscall_exit_to_user_mode_work - Handle work before returning to user mode * @regs: Pointer to currents pt_regs @@ -412,145 +173,4 @@ void syscall_exit_to_user_mode_work(struct pt_regs *regs); */ void syscall_exit_to_user_mode(struct pt_regs *regs); -/** - * irqentry_enter_from_user_mode - Establish state before invoking the irq handler - * @regs: Pointer to currents pt_regs - * - * Invoked from architecture specific entry code with interrupts disabled. - * Can only be called when the interrupt entry came from user mode. The - * calling code must be non-instrumentable. When the function returns all - * state is correct and the subsequent functions can be instrumented. - * - * The function establishes state (lockdep, RCU (context tracking), tracing) - */ -void irqentry_enter_from_user_mode(struct pt_regs *regs); - -/** - * irqentry_exit_to_user_mode - Interrupt exit work - * @regs: Pointer to current's pt_regs - * - * Invoked with interrupts disabled and fully valid regs. Returns with all - * work handled, interrupts disabled such that the caller can immediately - * switch to user mode. Called from architecture specific interrupt - * handling code. - * - * The call order is #2 and #3 as described in syscall_exit_to_user_mode(). - * Interrupt exit is not invoking #1 which is the syscall specific one time - * work. - */ -void irqentry_exit_to_user_mode(struct pt_regs *regs); - -#ifndef irqentry_state -/** - * struct irqentry_state - Opaque object for exception state storage - * @exit_rcu: Used exclusively in the irqentry_*() calls; signals whether the - * exit path has to invoke ct_irq_exit(). - * @lockdep: Used exclusively in the irqentry_nmi_*() calls; ensures that - * lockdep state is restored correctly on exit from nmi. - * - * This opaque object is filled in by the irqentry_*_enter() functions and - * must be passed back into the corresponding irqentry_*_exit() functions - * when the exception is complete. - * - * Callers of irqentry_*_[enter|exit]() must consider this structure opaque - * and all members private. Descriptions of the members are provided to aid in - * the maintenance of the irqentry_*() functions. - */ -typedef struct irqentry_state { - union { - bool exit_rcu; - bool lockdep; - }; -} irqentry_state_t; -#endif - -/** - * irqentry_enter - Handle state tracking on ordinary interrupt entries - * @regs: Pointer to pt_regs of interrupted context - * - * Invokes: - * - lockdep irqflag state tracking as low level ASM entry disabled - * interrupts. - * - * - Context tracking if the exception hit user mode. - * - * - The hardirq tracer to keep the state consistent as low level ASM - * entry disabled interrupts. - * - * As a precondition, this requires that the entry came from user mode, - * idle, or a kernel context in which RCU is watching. - * - * For kernel mode entries RCU handling is done conditional. If RCU is - * watching then the only RCU requirement is to check whether the tick has - * to be restarted. If RCU is not watching then ct_irq_enter() has to be - * invoked on entry and ct_irq_exit() on exit. - * - * Avoiding the ct_irq_enter/exit() calls is an optimization but also - * solves the problem of kernel mode pagefaults which can schedule, which - * is not possible after invoking ct_irq_enter() without undoing it. - * - * For user mode entries irqentry_enter_from_user_mode() is invoked to - * establish the proper context for NOHZ_FULL. Otherwise scheduling on exit - * would not be possible. - * - * Returns: An opaque object that must be passed to idtentry_exit() - */ -irqentry_state_t noinstr irqentry_enter(struct pt_regs *regs); - -/** - * irqentry_exit_cond_resched - Conditionally reschedule on return from interrupt - * - * Conditional reschedule with additional sanity checks. - */ -void raw_irqentry_exit_cond_resched(void); -#ifdef CONFIG_PREEMPT_DYNAMIC -#if defined(CONFIG_HAVE_PREEMPT_DYNAMIC_CALL) -#define irqentry_exit_cond_resched_dynamic_enabled raw_irqentry_exit_cond_resched -#define irqentry_exit_cond_resched_dynamic_disabled NULL -DECLARE_STATIC_CALL(irqentry_exit_cond_resched, raw_irqentry_exit_cond_resched); -#define irqentry_exit_cond_resched() static_call(irqentry_exit_cond_resched)() -#elif defined(CONFIG_HAVE_PREEMPT_DYNAMIC_KEY) -DECLARE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); -void dynamic_irqentry_exit_cond_resched(void); -#define irqentry_exit_cond_resched() dynamic_irqentry_exit_cond_resched() -#endif -#else /* CONFIG_PREEMPT_DYNAMIC */ -#define irqentry_exit_cond_resched() raw_irqentry_exit_cond_resched() -#endif /* CONFIG_PREEMPT_DYNAMIC */ - -/** - * irqentry_exit - Handle return from exception that used irqentry_enter() - * @regs: Pointer to pt_regs (exception entry regs) - * @state: Return value from matching call to irqentry_enter() - * - * Depending on the return target (kernel/user) this runs the necessary - * preemption and work checks if possible and required and returns to - * the caller with interrupts disabled and no further work pending. - * - * This is the last action before returning to the low level ASM code which - * just needs to return to the appropriate context. - * - * Counterpart to irqentry_enter(). - */ -void noinstr irqentry_exit(struct pt_regs *regs, irqentry_state_t state); - -/** - * irqentry_nmi_enter - Handle NMI entry - * @regs: Pointer to currents pt_regs - * - * Similar to irqentry_enter() but taking care of the NMI constraints. - */ -irqentry_state_t noinstr irqentry_nmi_enter(struct pt_regs *regs); - -/** - * irqentry_nmi_exit - Handle return from NMI handling - * @regs: Pointer to pt_regs (NMI entry regs) - * @irq_state: Return value from matching call to irqentry_nmi_enter() - * - * Last action before returning to the low level assembly code. - * - * Counterpart to irqentry_nmi_enter(). - */ -void noinstr irqentry_nmi_exit(struct pt_regs *regs, irqentry_state_t irq_state); - #endif diff --git a/include/linux/irq-entry-common.h b/include/linux/irq-entry-common.h new file mode 100644 index 000000000000..8af374331900 --- /dev/null +++ b/include/linux/irq-entry-common.h @@ -0,0 +1,389 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef __LINUX_IRQENTRYCOMMON_H +#define __LINUX_IRQENTRYCOMMON_H + +#include +#include +#include +#include +#include + +#include + +/* + * Define dummy _TIF work flags if not defined by the architecture or for + * disabled functionality. + */ +#ifndef _TIF_PATCH_PENDING +# define _TIF_PATCH_PENDING (0) +#endif + +/* + * TIF flags handled in exit_to_user_mode_loop() + */ +#ifndef ARCH_EXIT_TO_USER_MODE_WORK +# define ARCH_EXIT_TO_USER_MODE_WORK (0) +#endif + +#define EXIT_TO_USER_MODE_WORK \ + (_TIF_SIGPENDING | _TIF_NOTIFY_RESUME | _TIF_UPROBE | \ + _TIF_NEED_RESCHED | _TIF_NEED_RESCHED_LAZY | \ + _TIF_PATCH_PENDING | _TIF_NOTIFY_SIGNAL | \ + ARCH_EXIT_TO_USER_MODE_WORK) + +/** + * arch_enter_from_user_mode - Architecture specific sanity check for user mode regs + * @regs: Pointer to currents pt_regs + * + * Defaults to an empty implementation. Can be replaced by architecture + * specific code. + * + * Invoked from syscall_enter_from_user_mode() in the non-instrumentable + * section. Use __always_inline so the compiler cannot push it out of line + * and make it instrumentable. + */ +static __always_inline void arch_enter_from_user_mode(struct pt_regs *regs); + +#ifndef arch_enter_from_user_mode +static __always_inline void arch_enter_from_user_mode(struct pt_regs *regs) {} +#endif + +/** + * enter_from_user_mode - Establish state when coming from user mode + * + * Syscall/interrupt entry disables interrupts, but user mode is traced as + * interrupts enabled. Also with NO_HZ_FULL RCU might be idle. + * + * 1) Tell lockdep that interrupts are disabled + * 2) Invoke context tracking if enabled to reactivate RCU + * 3) Trace interrupts off state + * + * Invoked from architecture specific syscall entry code with interrupts + * disabled. The calling code has to be non-instrumentable. When the + * function returns all state is correct and interrupts are still + * disabled. The subsequent functions can be instrumented. + * + * This is invoked when there is architecture specific functionality to be + * done between establishing state and enabling interrupts. The caller must + * enable interrupts before invoking syscall_enter_from_user_mode_work(). + */ +static __always_inline void enter_from_user_mode(struct pt_regs *regs) +{ + arch_enter_from_user_mode(regs); + lockdep_hardirqs_off(CALLER_ADDR0); + + CT_WARN_ON(__ct_state() != CT_STATE_USER); + user_exit_irqoff(); + + instrumentation_begin(); + kmsan_unpoison_entry_regs(regs); + trace_hardirqs_off_finish(); + instrumentation_end(); +} + +/** + * local_irq_enable_exit_to_user - Exit to user variant of local_irq_enable() + * @ti_work: Cached TIF flags gathered with interrupts disabled + * + * Defaults to local_irq_enable(). Can be supplied by architecture specific + * code. + */ +static inline void local_irq_enable_exit_to_user(unsigned long ti_work); + +#ifndef local_irq_enable_exit_to_user +static inline void local_irq_enable_exit_to_user(unsigned long ti_work) +{ + local_irq_enable(); +} +#endif + +/** + * local_irq_disable_exit_to_user - Exit to user variant of local_irq_disable() + * + * Defaults to local_irq_disable(). Can be supplied by architecture specific + * code. + */ +static inline void local_irq_disable_exit_to_user(void); + +#ifndef local_irq_disable_exit_to_user +static inline void local_irq_disable_exit_to_user(void) +{ + local_irq_disable(); +} +#endif + +/** + * arch_exit_to_user_mode_work - Architecture specific TIF work for exit + * to user mode. + * @regs: Pointer to currents pt_regs + * @ti_work: Cached TIF flags gathered with interrupts disabled + * + * Invoked from exit_to_user_mode_loop() with interrupt enabled + * + * Defaults to NOOP. Can be supplied by architecture specific code. + */ +static inline void arch_exit_to_user_mode_work(struct pt_regs *regs, + unsigned long ti_work); + +#ifndef arch_exit_to_user_mode_work +static inline void arch_exit_to_user_mode_work(struct pt_regs *regs, + unsigned long ti_work) +{ +} +#endif + +/** + * arch_exit_to_user_mode_prepare - Architecture specific preparation for + * exit to user mode. + * @regs: Pointer to currents pt_regs + * @ti_work: Cached TIF flags gathered with interrupts disabled + * + * Invoked from exit_to_user_mode_prepare() with interrupt disabled as the last + * function before return. Defaults to NOOP. + */ +static inline void arch_exit_to_user_mode_prepare(struct pt_regs *regs, + unsigned long ti_work); + +#ifndef arch_exit_to_user_mode_prepare +static inline void arch_exit_to_user_mode_prepare(struct pt_regs *regs, + unsigned long ti_work) +{ +} +#endif + +/** + * arch_exit_to_user_mode - Architecture specific final work before + * exit to user mode. + * + * Invoked from exit_to_user_mode() with interrupt disabled as the last + * function before return. Defaults to NOOP. + * + * This needs to be __always_inline because it is non-instrumentable code + * invoked after context tracking switched to user mode. + * + * An architecture implementation must not do anything complex, no locking + * etc. The main purpose is for speculation mitigations. + */ +static __always_inline void arch_exit_to_user_mode(void); + +#ifndef arch_exit_to_user_mode +static __always_inline void arch_exit_to_user_mode(void) { } +#endif + +/** + * arch_do_signal_or_restart - Architecture specific signal delivery function + * @regs: Pointer to currents pt_regs + * + * Invoked from exit_to_user_mode_loop(). + */ +void arch_do_signal_or_restart(struct pt_regs *regs); + +/** + * exit_to_user_mode_loop - do any pending work before leaving to user space + */ +unsigned long exit_to_user_mode_loop(struct pt_regs *regs, + unsigned long ti_work); + +/** + * exit_to_user_mode_prepare - call exit_to_user_mode_loop() if required + * @regs: Pointer to pt_regs on entry stack + * + * 1) check that interrupts are disabled + * 2) call tick_nohz_user_enter_prepare() + * 3) call exit_to_user_mode_loop() if any flags from + * EXIT_TO_USER_MODE_WORK are set + * 4) check that interrupts are still disabled + */ +static __always_inline void exit_to_user_mode_prepare(struct pt_regs *regs) +{ + unsigned long ti_work; + + lockdep_assert_irqs_disabled(); + + /* Flush pending rcuog wakeup before the last need_resched() check */ + tick_nohz_user_enter_prepare(); + + ti_work = read_thread_flags(); + if (unlikely(ti_work & EXIT_TO_USER_MODE_WORK)) + ti_work = exit_to_user_mode_loop(regs, ti_work); + + arch_exit_to_user_mode_prepare(regs, ti_work); + + /* Ensure that kernel state is sane for a return to userspace */ + kmap_assert_nomap(); + lockdep_assert_irqs_disabled(); + lockdep_sys_exit(); +} + +/** + * exit_to_user_mode - Fixup state when exiting to user mode + * + * Syscall/interrupt exit enables interrupts, but the kernel state is + * interrupts disabled when this is invoked. Also tell RCU about it. + * + * 1) Trace interrupts on state + * 2) Invoke context tracking if enabled to adjust RCU state + * 3) Invoke architecture specific last minute exit code, e.g. speculation + * mitigations, etc.: arch_exit_to_user_mode() + * 4) Tell lockdep that interrupts are enabled + * + * Invoked from architecture specific code when syscall_exit_to_user_mode() + * is not suitable as the last step before returning to userspace. Must be + * invoked with interrupts disabled and the caller must be + * non-instrumentable. + * The caller has to invoke syscall_exit_to_user_mode_work() before this. + */ +static __always_inline void exit_to_user_mode(void) +{ + instrumentation_begin(); + trace_hardirqs_on_prepare(); + lockdep_hardirqs_on_prepare(); + instrumentation_end(); + + user_enter_irqoff(); + arch_exit_to_user_mode(); + lockdep_hardirqs_on(CALLER_ADDR0); +} + +/** + * irqentry_enter_from_user_mode - Establish state before invoking the irq handler + * @regs: Pointer to currents pt_regs + * + * Invoked from architecture specific entry code with interrupts disabled. + * Can only be called when the interrupt entry came from user mode. The + * calling code must be non-instrumentable. When the function returns all + * state is correct and the subsequent functions can be instrumented. + * + * The function establishes state (lockdep, RCU (context tracking), tracing) + */ +void irqentry_enter_from_user_mode(struct pt_regs *regs); + +/** + * irqentry_exit_to_user_mode - Interrupt exit work + * @regs: Pointer to current's pt_regs + * + * Invoked with interrupts disabled and fully valid regs. Returns with all + * work handled, interrupts disabled such that the caller can immediately + * switch to user mode. Called from architecture specific interrupt + * handling code. + * + * The call order is #2 and #3 as described in syscall_exit_to_user_mode(). + * Interrupt exit is not invoking #1 which is the syscall specific one time + * work. + */ +void irqentry_exit_to_user_mode(struct pt_regs *regs); + +#ifndef irqentry_state +/** + * struct irqentry_state - Opaque object for exception state storage + * @exit_rcu: Used exclusively in the irqentry_*() calls; signals whether the + * exit path has to invoke ct_irq_exit(). + * @lockdep: Used exclusively in the irqentry_nmi_*() calls; ensures that + * lockdep state is restored correctly on exit from nmi. + * + * This opaque object is filled in by the irqentry_*_enter() functions and + * must be passed back into the corresponding irqentry_*_exit() functions + * when the exception is complete. + * + * Callers of irqentry_*_[enter|exit]() must consider this structure opaque + * and all members private. Descriptions of the members are provided to aid in + * the maintenance of the irqentry_*() functions. + */ +typedef struct irqentry_state { + union { + bool exit_rcu; + bool lockdep; + }; +} irqentry_state_t; +#endif + +/** + * irqentry_enter - Handle state tracking on ordinary interrupt entries + * @regs: Pointer to pt_regs of interrupted context + * + * Invokes: + * - lockdep irqflag state tracking as low level ASM entry disabled + * interrupts. + * + * - Context tracking if the exception hit user mode. + * + * - The hardirq tracer to keep the state consistent as low level ASM + * entry disabled interrupts. + * + * As a precondition, this requires that the entry came from user mode, + * idle, or a kernel context in which RCU is watching. + * + * For kernel mode entries RCU handling is done conditional. If RCU is + * watching then the only RCU requirement is to check whether the tick has + * to be restarted. If RCU is not watching then ct_irq_enter() has to be + * invoked on entry and ct_irq_exit() on exit. + * + * Avoiding the ct_irq_enter/exit() calls is an optimization but also + * solves the problem of kernel mode pagefaults which can schedule, which + * is not possible after invoking ct_irq_enter() without undoing it. + * + * For user mode entries irqentry_enter_from_user_mode() is invoked to + * establish the proper context for NOHZ_FULL. Otherwise scheduling on exit + * would not be possible. + * + * Returns: An opaque object that must be passed to idtentry_exit() + */ +irqentry_state_t noinstr irqentry_enter(struct pt_regs *regs); + +/** + * irqentry_exit_cond_resched - Conditionally reschedule on return from interrupt + * + * Conditional reschedule with additional sanity checks. + */ +void raw_irqentry_exit_cond_resched(void); +#ifdef CONFIG_PREEMPT_DYNAMIC +#if defined(CONFIG_HAVE_PREEMPT_DYNAMIC_CALL) +#define irqentry_exit_cond_resched_dynamic_enabled raw_irqentry_exit_cond_resched +#define irqentry_exit_cond_resched_dynamic_disabled NULL +DECLARE_STATIC_CALL(irqentry_exit_cond_resched, raw_irqentry_exit_cond_resched); +#define irqentry_exit_cond_resched() static_call(irqentry_exit_cond_resched)() +#elif defined(CONFIG_HAVE_PREEMPT_DYNAMIC_KEY) +DECLARE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); +void dynamic_irqentry_exit_cond_resched(void); +#define irqentry_exit_cond_resched() dynamic_irqentry_exit_cond_resched() +#endif +#else /* CONFIG_PREEMPT_DYNAMIC */ +#define irqentry_exit_cond_resched() raw_irqentry_exit_cond_resched() +#endif /* CONFIG_PREEMPT_DYNAMIC */ + +/** + * irqentry_exit - Handle return from exception that used irqentry_enter() + * @regs: Pointer to pt_regs (exception entry regs) + * @state: Return value from matching call to irqentry_enter() + * + * Depending on the return target (kernel/user) this runs the necessary + * preemption and work checks if possible and required and returns to + * the caller with interrupts disabled and no further work pending. + * + * This is the last action before returning to the low level ASM code which + * just needs to return to the appropriate context. + * + * Counterpart to irqentry_enter(). + */ +void noinstr irqentry_exit(struct pt_regs *regs, irqentry_state_t state); + +/** + * irqentry_nmi_enter - Handle NMI entry + * @regs: Pointer to currents pt_regs + * + * Similar to irqentry_enter() but taking care of the NMI constraints. + */ +irqentry_state_t noinstr irqentry_nmi_enter(struct pt_regs *regs); + +/** + * irqentry_nmi_exit - Handle return from NMI handling + * @regs: Pointer to pt_regs (NMI entry regs) + * @irq_state: Return value from matching call to irqentry_nmi_enter() + * + * Last action before returning to the low level assembly code. + * + * Counterpart to irqentry_nmi_enter(). + */ +void noinstr irqentry_nmi_exit(struct pt_regs *regs, irqentry_state_t irq_state); + +#endif diff --git a/kernel/entry/Makefile b/kernel/entry/Makefile index 095c775e001e..d38f3a7e7396 100644 --- a/kernel/entry/Makefile +++ b/kernel/entry/Makefile @@ -9,5 +9,6 @@ KCOV_INSTRUMENT := n CFLAGS_REMOVE_common.o = -fstack-protector -fstack-protector-strong CFLAGS_common.o += -fno-stack-protector -obj-$(CONFIG_GENERIC_ENTRY) += common.o syscall_user_dispatch.o +obj-$(CONFIG_GENERIC_IRQ_ENTRY) += common.o +obj-$(CONFIG_GENERIC_SYSCALL) += syscall-common.o syscall_user_dispatch.o obj-$(CONFIG_KVM_XFER_TO_GUEST_WORK) += kvm.o diff --git a/kernel/entry/common.c b/kernel/entry/common.c index e33691d5adf7..b82032777310 100644 --- a/kernel/entry/common.c +++ b/kernel/entry/common.c @@ -1,84 +1,13 @@ // SPDX-License-Identifier: GPL-2.0 -#include -#include +#include #include #include #include #include #include -#include #include -#include "common.h" - -#define CREATE_TRACE_POINTS -#include - -static inline void syscall_enter_audit(struct pt_regs *regs, long syscall) -{ - if (unlikely(audit_context())) { - unsigned long args[6]; - - syscall_get_arguments(current, regs, args); - audit_syscall_entry(syscall, args[0], args[1], args[2], args[3]); - } -} - -long syscall_trace_enter(struct pt_regs *regs, long syscall, - unsigned long work) -{ - long ret = 0; - - /* - * Handle Syscall User Dispatch. This must comes first, since - * the ABI here can be something that doesn't make sense for - * other syscall_work features. - */ - if (work & SYSCALL_WORK_SYSCALL_USER_DISPATCH) { - if (syscall_user_dispatch(regs)) - return -1L; - } - - /* Handle ptrace */ - if (work & (SYSCALL_WORK_SYSCALL_TRACE | SYSCALL_WORK_SYSCALL_EMU)) { - ret = ptrace_report_syscall_entry(regs); - if (ret || (work & SYSCALL_WORK_SYSCALL_EMU)) - return -1L; - } - - /* Do seccomp after ptrace, to catch any tracer changes. */ - if (work & SYSCALL_WORK_SECCOMP) { - ret = __secure_computing(NULL); - if (ret == -1L) - return ret; - } - - /* Either of the above might have changed the syscall number */ - syscall = syscall_get_nr(current, regs); - - if (unlikely(work & SYSCALL_WORK_SYSCALL_TRACEPOINT)) { - trace_sys_enter(regs, syscall); - /* - * Probes or BPF hooks in the tracepoint may have changed the - * system call number as well. - */ - syscall = syscall_get_nr(current, regs); - } - - syscall_enter_audit(regs, syscall); - - return ret ? : syscall; -} - -noinstr void syscall_enter_from_user_mode_prepare(struct pt_regs *regs) -{ - enter_from_user_mode(regs); - instrumentation_begin(); - local_irq_enable(); - instrumentation_end(); -} - /* Workaround to allow gradual conversion of architecture code */ void __weak arch_do_signal_or_restart(struct pt_regs *regs) { } @@ -133,93 +62,6 @@ __always_inline unsigned long exit_to_user_mode_loop(struct pt_regs *regs, return ti_work; } -/* - * If SYSCALL_EMU is set, then the only reason to report is when - * SINGLESTEP is set (i.e. PTRACE_SYSEMU_SINGLESTEP). This syscall - * instruction has been already reported in syscall_enter_from_user_mode(). - */ -static inline bool report_single_step(unsigned long work) -{ - if (work & SYSCALL_WORK_SYSCALL_EMU) - return false; - - return work & SYSCALL_WORK_SYSCALL_EXIT_TRAP; -} - -static void syscall_exit_work(struct pt_regs *regs, unsigned long work) -{ - bool step; - - /* - * If the syscall was rolled back due to syscall user dispatching, - * then the tracers below are not invoked for the same reason as - * the entry side was not invoked in syscall_trace_enter(): The ABI - * of these syscalls is unknown. - */ - if (work & SYSCALL_WORK_SYSCALL_USER_DISPATCH) { - if (unlikely(current->syscall_dispatch.on_dispatch)) { - current->syscall_dispatch.on_dispatch = false; - return; - } - } - - audit_syscall_exit(regs); - - if (work & SYSCALL_WORK_SYSCALL_TRACEPOINT) - trace_sys_exit(regs, syscall_get_return_value(current, regs)); - - step = report_single_step(work); - if (step || work & SYSCALL_WORK_SYSCALL_TRACE) - ptrace_report_syscall_exit(regs, step); -} - -/* - * Syscall specific exit to user mode preparation. Runs with interrupts - * enabled. - */ -static void syscall_exit_to_user_mode_prepare(struct pt_regs *regs) -{ - unsigned long work = READ_ONCE(current_thread_info()->syscall_work); - unsigned long nr = syscall_get_nr(current, regs); - - CT_WARN_ON(ct_state() != CT_STATE_KERNEL); - - if (IS_ENABLED(CONFIG_PROVE_LOCKING)) { - if (WARN(irqs_disabled(), "syscall %lu left IRQs disabled", nr)) - local_irq_enable(); - } - - rseq_syscall(regs); - - /* - * Do one-time syscall specific work. If these work items are - * enabled, we want to run them exactly once per syscall exit with - * interrupts enabled. - */ - if (unlikely(work & SYSCALL_WORK_EXIT)) - syscall_exit_work(regs, work); -} - -static __always_inline void __syscall_exit_to_user_mode_work(struct pt_regs *regs) -{ - syscall_exit_to_user_mode_prepare(regs); - local_irq_disable_exit_to_user(); - exit_to_user_mode_prepare(regs); -} - -void syscall_exit_to_user_mode_work(struct pt_regs *regs) -{ - __syscall_exit_to_user_mode_work(regs); -} - -__visible noinstr void syscall_exit_to_user_mode(struct pt_regs *regs) -{ - instrumentation_begin(); - __syscall_exit_to_user_mode_work(regs); - instrumentation_end(); - exit_to_user_mode(); -} - noinstr void irqentry_enter_from_user_mode(struct pt_regs *regs) { enter_from_user_mode(regs); diff --git a/kernel/entry/syscall-common.c b/kernel/entry/syscall-common.c new file mode 100644 index 000000000000..0eb036986ad4 --- /dev/null +++ b/kernel/entry/syscall-common.c @@ -0,0 +1,159 @@ +// SPDX-License-Identifier: GPL-2.0 + +#include +#include +#include "common.h" + +#define CREATE_TRACE_POINTS +#include + +static inline void syscall_enter_audit(struct pt_regs *regs, long syscall) +{ + if (unlikely(audit_context())) { + unsigned long args[6]; + + syscall_get_arguments(current, regs, args); + audit_syscall_entry(syscall, args[0], args[1], args[2], args[3]); + } +} + +long syscall_trace_enter(struct pt_regs *regs, long syscall, + unsigned long work) +{ + long ret = 0; + + /* + * Handle Syscall User Dispatch. This must comes first, since + * the ABI here can be something that doesn't make sense for + * other syscall_work features. + */ + if (work & SYSCALL_WORK_SYSCALL_USER_DISPATCH) { + if (syscall_user_dispatch(regs)) + return -1L; + } + + /* Handle ptrace */ + if (work & (SYSCALL_WORK_SYSCALL_TRACE | SYSCALL_WORK_SYSCALL_EMU)) { + ret = ptrace_report_syscall_entry(regs); + if (ret || (work & SYSCALL_WORK_SYSCALL_EMU)) + return -1L; + } + + /* Do seccomp after ptrace, to catch any tracer changes. */ + if (work & SYSCALL_WORK_SECCOMP) { + ret = __secure_computing(NULL); + if (ret == -1L) + return ret; + } + + /* Either of the above might have changed the syscall number */ + syscall = syscall_get_nr(current, regs); + + if (unlikely(work & SYSCALL_WORK_SYSCALL_TRACEPOINT)) { + trace_sys_enter(regs, syscall); + /* + * Probes or BPF hooks in the tracepoint may have changed the + * system call number as well. + */ + syscall = syscall_get_nr(current, regs); + } + + syscall_enter_audit(regs, syscall); + + return ret ? : syscall; +} + +noinstr void syscall_enter_from_user_mode_prepare(struct pt_regs *regs) +{ + enter_from_user_mode(regs); + instrumentation_begin(); + local_irq_enable(); + instrumentation_end(); +} + +/* + * If SYSCALL_EMU is set, then the only reason to report is when + * SINGLESTEP is set (i.e. PTRACE_SYSEMU_SINGLESTEP). This syscall + * instruction has been already reported in syscall_enter_from_user_mode(). + */ +static inline bool report_single_step(unsigned long work) +{ + if (work & SYSCALL_WORK_SYSCALL_EMU) + return false; + + return work & SYSCALL_WORK_SYSCALL_EXIT_TRAP; +} + +static void syscall_exit_work(struct pt_regs *regs, unsigned long work) +{ + bool step; + + /* + * If the syscall was rolled back due to syscall user dispatching, + * then the tracers below are not invoked for the same reason as + * the entry side was not invoked in syscall_trace_enter(): The ABI + * of these syscalls is unknown. + */ + if (work & SYSCALL_WORK_SYSCALL_USER_DISPATCH) { + if (unlikely(current->syscall_dispatch.on_dispatch)) { + current->syscall_dispatch.on_dispatch = false; + return; + } + } + + audit_syscall_exit(regs); + + if (work & SYSCALL_WORK_SYSCALL_TRACEPOINT) + trace_sys_exit(regs, syscall_get_return_value(current, regs)); + + step = report_single_step(work); + if (step || work & SYSCALL_WORK_SYSCALL_TRACE) + ptrace_report_syscall_exit(regs, step); +} + +/* + * Syscall specific exit to user mode preparation. Runs with interrupts + * enabled. + */ +static void syscall_exit_to_user_mode_prepare(struct pt_regs *regs) +{ + unsigned long work = READ_ONCE(current_thread_info()->syscall_work); + unsigned long nr = syscall_get_nr(current, regs); + + CT_WARN_ON(ct_state() != CT_STATE_KERNEL); + + if (IS_ENABLED(CONFIG_PROVE_LOCKING)) { + if (WARN(irqs_disabled(), "syscall %lu left IRQs disabled", nr)) + local_irq_enable(); + } + + rseq_syscall(regs); + + /* + * Do one-time syscall specific work. If these work items are + * enabled, we want to run them exactly once per syscall exit with + * interrupts enabled. + */ + if (unlikely(work & SYSCALL_WORK_EXIT)) + syscall_exit_work(regs, work); +} + +static __always_inline void __syscall_exit_to_user_mode_work(struct pt_regs *regs) +{ + syscall_exit_to_user_mode_prepare(regs); + local_irq_disable_exit_to_user(); + exit_to_user_mode_prepare(regs); +} + +void syscall_exit_to_user_mode_work(struct pt_regs *regs) +{ + __syscall_exit_to_user_mode_work(regs); +} + +__visible noinstr void syscall_exit_to_user_mode(struct pt_regs *regs) +{ + instrumentation_begin(); + __syscall_exit_to_user_mode_work(regs); + instrumentation_end(); + exit_to_user_mode(); +} diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 27a8fbd58091..2d560bb3efaa 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -68,8 +68,8 @@ #include #ifdef CONFIG_PREEMPT_DYNAMIC -# ifdef CONFIG_GENERIC_ENTRY -# include +# ifdef CONFIG_GENERIC_IRQ_ENTRY +# include # endif #endif @@ -7398,8 +7398,8 @@ EXPORT_SYMBOL(__cond_resched_rwlock_write); #ifdef CONFIG_PREEMPT_DYNAMIC -#ifdef CONFIG_GENERIC_ENTRY -#include +#ifdef CONFIG_GENERIC_IRQ_ENTRY +#include #endif /* -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:18:26 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:18:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849993.1264536 (Exim 4.92) (envelope-from ) id 1tJVPm-0004Jz-MO; Fri, 06 Dec 2024 10:18:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849993.1264536; Fri, 06 Dec 2024 10:18:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJVPm-0004IP-DL; Fri, 06 Dec 2024 10:18:26 +0000 Received: by outflank-mailman (input) for mailman id 849993; Fri, 06 Dec 2024 10:18: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 1tJVPl-0001om-Iv for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:25 +0000 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6b628898-b3bb-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 11:18:23 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.88.214]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4Y4Rwx0c4xz2Dh8H; Fri, 6 Dec 2024 18:16:01 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id 6B99A1A016C; Fri, 6 Dec 2024 18:18:20 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:19 +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: 6b628898-b3bb-11ef-99a3-01e77a169b0f From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 11/22] arm64: entry: Switch to generic IRQ entry Date: Fri, 6 Dec 2024 18:17:33 +0800 Message-ID: <20241206101744.4161990-12-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) Currently, x86, Riscv, Loongarch use the generic entry. Convert arm64 to use the generic entry infrastructure from kernel/entry/*. The generic entry makes maintainers' work easier and codes more elegant. Switch arm64 to generic IRQ entry first, which removed duplicate 100+ LOC, and it will switch to generic entry completely later. Switch to generic entry in two steps according to Mark's suggestion will make it easier to review. The changes are below: - Remove *enter_from/exit_to_kernel_mode(), and wrap with generic irqentry_enter/exit(). Also remove *enter_from/exit_to_user_mode(), and wrap with generic enter_from/exit_to_user_mode() because they are exactly the same so far. - Remove arm64_enter/exit_nmi() and use generic irqentry_nmi_enter/exit() because they're exactly the same, so the temporary arm64 version irqentry_state can also be removed. - Remove PREEMPT_DYNAMIC code, as generic entry do the same thing if arm64 implement arch_irqentry_exit_need_resched(). Suggested-by: Mark Rutland Signed-off-by: Jinjie Ruan --- arch/arm64/Kconfig | 1 + arch/arm64/include/asm/entry-common.h | 64 ++++++ arch/arm64/include/asm/preempt.h | 6 - arch/arm64/kernel/entry-common.c | 307 ++++++-------------------- arch/arm64/kernel/signal.c | 3 +- 5 files changed, 129 insertions(+), 252 deletions(-) create mode 100644 arch/arm64/include/asm/entry-common.h diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 0cd423d9aa5b..3751ab9f2a21 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -150,6 +150,7 @@ config ARM64 select GENERIC_EARLY_IOREMAP select GENERIC_IDLE_POLL_SETUP select GENERIC_IOREMAP + select GENERIC_IRQ_ENTRY select GENERIC_IRQ_IPI select GENERIC_IRQ_KEXEC_CLEAR_VM_FORWARD select GENERIC_IRQ_PROBE diff --git a/arch/arm64/include/asm/entry-common.h b/arch/arm64/include/asm/entry-common.h new file mode 100644 index 000000000000..1cc9d966a6c3 --- /dev/null +++ b/arch/arm64/include/asm/entry-common.h @@ -0,0 +1,64 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _ASM_ARM64_ENTRY_COMMON_H +#define _ASM_ARM64_ENTRY_COMMON_H + +#include + +#include +#include +#include +#include + +#define ARCH_EXIT_TO_USER_MODE_WORK (_TIF_MTE_ASYNC_FAULT | _TIF_FOREIGN_FPSTATE) + +static __always_inline void arch_exit_to_user_mode_work(struct pt_regs *regs, + unsigned long ti_work) +{ + if (ti_work & _TIF_MTE_ASYNC_FAULT) { + clear_thread_flag(TIF_MTE_ASYNC_FAULT); + send_sig_fault(SIGSEGV, SEGV_MTEAERR, (void __user *)NULL, current); + } + + if (ti_work & _TIF_FOREIGN_FPSTATE) + fpsimd_restore_current_state(); +} + +#define arch_exit_to_user_mode_work arch_exit_to_user_mode_work + +static inline void arch_exit_to_user_mode_prepare(struct pt_regs *regs, + unsigned long ti_work) +{ + local_daif_mask(); +} + +#define arch_exit_to_user_mode_prepare arch_exit_to_user_mode_prepare + +static inline bool arch_irqentry_exit_need_resched(void) +{ + /* + * DAIF.DA are cleared at the start of IRQ/FIQ handling, and when GIC + * priority masking is used the GIC irqchip driver will clear DAIF.IF + * using gic_arch_enable_irqs() for normal IRQs. If anything is set in + * DAIF we must have handled an NMI, so skip preemption. + */ + if (system_uses_irq_prio_masking() && read_sysreg(daif)) + return false; + + /* + * Preempting a task from an IRQ means we leave copies of PSTATE + * on the stack. cpufeature's enable calls may modify PSTATE, but + * resuming one of these preempted tasks would undo those changes. + * + * Only allow a task to be preempted once cpufeatures have been + * enabled. + */ + if (!system_capabilities_finalized()) + return false; + + return true; +} + +#define arch_irqentry_exit_need_resched arch_irqentry_exit_need_resched + +#endif /* _ASM_ARM64_ENTRY_COMMON_H */ diff --git a/arch/arm64/include/asm/preempt.h b/arch/arm64/include/asm/preempt.h index 0f0ba250efe8..932ea4b62042 100644 --- a/arch/arm64/include/asm/preempt.h +++ b/arch/arm64/include/asm/preempt.h @@ -2,7 +2,6 @@ #ifndef __ASM_PREEMPT_H #define __ASM_PREEMPT_H -#include #include #define PREEMPT_NEED_RESCHED BIT(32) @@ -85,22 +84,17 @@ static inline bool should_resched(int preempt_offset) void preempt_schedule(void); void preempt_schedule_notrace(void); -void raw_irqentry_exit_cond_resched(void); #ifdef CONFIG_PREEMPT_DYNAMIC -DECLARE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); void dynamic_preempt_schedule(void); #define __preempt_schedule() dynamic_preempt_schedule() void dynamic_preempt_schedule_notrace(void); #define __preempt_schedule_notrace() dynamic_preempt_schedule_notrace() -void dynamic_irqentry_exit_cond_resched(void); -#define irqentry_exit_cond_resched() dynamic_irqentry_exit_cond_resched() #else /* CONFIG_PREEMPT_DYNAMIC */ #define __preempt_schedule() preempt_schedule() #define __preempt_schedule_notrace() preempt_schedule_notrace() -#define irqentry_exit_cond_resched() raw_irqentry_exit_cond_resched() #endif /* CONFIG_PREEMPT_DYNAMIC */ #endif /* CONFIG_PREEMPTION */ diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c index 015a65d19b52..95885da2d776 100644 --- a/arch/arm64/kernel/entry-common.c +++ b/arch/arm64/kernel/entry-common.c @@ -6,6 +6,7 @@ */ #include +#include #include #include #include @@ -28,13 +29,6 @@ #include #include -typedef struct irqentry_state { - union { - bool exit_rcu; - bool lockdep; - }; -} irqentry_state_t; - /* * Handle IRQ/context state management when entering from kernel mode. * Before this function is called it is not safe to call regular kernel code, @@ -45,24 +39,7 @@ typedef struct irqentry_state { */ static __always_inline irqentry_state_t __enter_from_kernel_mode(struct pt_regs *regs) { - irqentry_state_t state = { - .exit_rcu = false, - }; - - if (!IS_ENABLED(CONFIG_TINY_RCU) && is_idle_task(current)) { - lockdep_hardirqs_off(CALLER_ADDR0); - ct_irq_enter(); - trace_hardirqs_off_finish(); - - state.exit_rcu = true; - return state; - } - - lockdep_hardirqs_off(CALLER_ADDR0); - rcu_irq_enter_check_tick(); - trace_hardirqs_off_finish(); - - return state; + return irqentry_enter(regs); } static noinstr irqentry_state_t enter_from_kernel_mode(struct pt_regs *regs) @@ -75,49 +52,6 @@ static noinstr irqentry_state_t enter_from_kernel_mode(struct pt_regs *regs) return state; } -static inline bool arm64_need_resched(void) -{ - /* - * DAIF.DA are cleared at the start of IRQ/FIQ handling, and when GIC - * priority masking is used the GIC irqchip driver will clear DAIF.IF - * using gic_arch_enable_irqs() for normal IRQs. If anything is set in - * DAIF we must have handled an NMI, so skip preemption. - */ - if (system_uses_irq_prio_masking() && read_sysreg(daif)) - return false; - - /* - * Preempting a task from an IRQ means we leave copies of PSTATE - * on the stack. cpufeature's enable calls may modify PSTATE, but - * resuming one of these preempted tasks would undo those changes. - * - * Only allow a task to be preempted once cpufeatures have been - * enabled. - */ - if (!system_capabilities_finalized()) - return false; - - return true; -} - -void raw_irqentry_exit_cond_resched(void) -{ - if (!preempt_count()) { - if (need_resched() && arm64_need_resched()) - preempt_schedule_irq(); - } -} - -#ifdef CONFIG_PREEMPT_DYNAMIC -DEFINE_STATIC_KEY_TRUE(sk_dynamic_irqentry_exit_cond_resched); -void dynamic_irqentry_exit_cond_resched(void) -{ - if (!static_branch_unlikely(&sk_dynamic_irqentry_exit_cond_resched)) - return; - raw_irqentry_exit_cond_resched(); -} -#endif - /* * Handle IRQ/context state management when exiting to kernel mode. * After this function returns it is not safe to call regular kernel code, @@ -129,25 +63,7 @@ void dynamic_irqentry_exit_cond_resched(void) static __always_inline void __exit_to_kernel_mode(struct pt_regs *regs, irqentry_state_t state) { - lockdep_assert_irqs_disabled(); - - if (!regs_irqs_disabled(regs)) { - if (state.exit_rcu) { - trace_hardirqs_on_prepare(); - lockdep_hardirqs_on_prepare(); - ct_irq_exit(); - lockdep_hardirqs_on(CALLER_ADDR0); - return; - } - - if (IS_ENABLED(CONFIG_PREEMPTION)) - irqentry_exit_cond_resched(); - - trace_hardirqs_on(); - } else { - if (state.exit_rcu) - ct_irq_exit(); - } + irqentry_exit(regs, state); } static void noinstr exit_to_kernel_mode(struct pt_regs *regs, @@ -162,18 +78,15 @@ static void noinstr exit_to_kernel_mode(struct pt_regs *regs, * Before this function is called it is not safe to call regular kernel code, * instrumentable code, or any code which may trigger an exception. */ -static __always_inline void __enter_from_user_mode(void) +static __always_inline void __enter_from_user_mode(struct pt_regs *regs) { - lockdep_hardirqs_off(CALLER_ADDR0); - CT_WARN_ON(ct_state() != CT_STATE_USER); - user_exit_irqoff(); - trace_hardirqs_off_finish(); + enter_from_user_mode(regs); mte_disable_tco_entry(current); } -static __always_inline void enter_from_user_mode(struct pt_regs *regs) +static __always_inline void arm64_enter_from_user_mode(struct pt_regs *regs) { - __enter_from_user_mode(); + __enter_from_user_mode(regs); } /* @@ -181,113 +94,17 @@ static __always_inline void enter_from_user_mode(struct pt_regs *regs) * After this function returns it is not safe to call regular kernel code, * instrumentable code, or any code which may trigger an exception. */ -static __always_inline void __exit_to_user_mode(void) +static __always_inline void arm64_exit_to_user_mode(struct pt_regs *regs) { - trace_hardirqs_on_prepare(); - lockdep_hardirqs_on_prepare(); - user_enter_irqoff(); - lockdep_hardirqs_on(CALLER_ADDR0); -} - -static void do_notify_resume(struct pt_regs *regs, unsigned long thread_flags) -{ - do { - local_irq_enable(); - - if (thread_flags & _TIF_NEED_RESCHED) - schedule(); - - if (thread_flags & _TIF_UPROBE) - uprobe_notify_resume(regs); - - if (thread_flags & _TIF_MTE_ASYNC_FAULT) { - clear_thread_flag(TIF_MTE_ASYNC_FAULT); - send_sig_fault(SIGSEGV, SEGV_MTEAERR, - (void __user *)NULL, current); - } - - if (thread_flags & (_TIF_SIGPENDING | _TIF_NOTIFY_SIGNAL)) - do_signal(regs); - - if (thread_flags & _TIF_NOTIFY_RESUME) - resume_user_mode_work(regs); - - if (thread_flags & _TIF_FOREIGN_FPSTATE) - fpsimd_restore_current_state(); - - local_irq_disable(); - thread_flags = read_thread_flags(); - } while (thread_flags & _TIF_WORK_MASK); -} - -static __always_inline void exit_to_user_mode_prepare(struct pt_regs *regs) -{ - unsigned long flags; - local_irq_disable(); - - flags = read_thread_flags(); - if (unlikely(flags & _TIF_WORK_MASK)) - do_notify_resume(regs, flags); - - local_daif_mask(); - - lockdep_sys_exit(); -} - -static __always_inline void exit_to_user_mode(struct pt_regs *regs) -{ exit_to_user_mode_prepare(regs); mte_check_tfsr_exit(); - __exit_to_user_mode(); + exit_to_user_mode(); } asmlinkage void noinstr asm_exit_to_user_mode(struct pt_regs *regs) { - exit_to_user_mode(regs); -} - -/* - * Handle IRQ/context state management when entering an NMI from user/kernel - * mode. Before this function is called it is not safe to call regular kernel - * code, instrumentable code, or any code which may trigger an exception. - */ -static noinstr irqentry_state_t arm64_enter_nmi(struct pt_regs *regs) -{ - irqentry_state_t state; - - state.lockdep = lockdep_hardirqs_enabled(); - - __nmi_enter(); - lockdep_hardirqs_off(CALLER_ADDR0); - lockdep_hardirq_enter(); - ct_nmi_enter(); - - trace_hardirqs_off_finish(); - ftrace_nmi_enter(); - - return state; -} - -/* - * Handle IRQ/context state management when exiting an NMI from user/kernel - * mode. After this function returns it is not safe to call regular kernel - * code, instrumentable code, or any code which may trigger an exception. - */ -static void noinstr arm64_exit_nmi(struct pt_regs *regs, - irqentry_state_t state) -{ - ftrace_nmi_exit(); - if (state.lockdep) { - trace_hardirqs_on_prepare(); - lockdep_hardirqs_on_prepare(); - } - - ct_nmi_exit(); - lockdep_hardirq_exit(); - if (state.lockdep) - lockdep_hardirqs_on(CALLER_ADDR0); - __nmi_exit(); + arm64_exit_to_user_mode(regs); } /* @@ -346,7 +163,7 @@ extern void (*handle_arch_fiq)(struct pt_regs *); static void noinstr __panic_unhandled(struct pt_regs *regs, const char *vector, unsigned long esr) { - arm64_enter_nmi(regs); + irqentry_nmi_enter(regs); console_verbose(); @@ -580,10 +397,10 @@ asmlinkage void noinstr el1h_64_sync_handler(struct pt_regs *regs) static __always_inline void __el1_pnmi(struct pt_regs *regs, void (*handler)(struct pt_regs *)) { - irqentry_state_t state = arm64_enter_nmi(regs); + irqentry_state_t state = irqentry_nmi_enter(regs); do_interrupt_handler(regs, handler); - arm64_exit_nmi(regs, state); + irqentry_nmi_exit(regs, state); } static __always_inline void __el1_irq(struct pt_regs *regs, @@ -624,19 +441,19 @@ asmlinkage void noinstr el1h_64_error_handler(struct pt_regs *regs) irqentry_state_t state; local_daif_restore(DAIF_ERRCTX); - state = arm64_enter_nmi(regs); + state = irqentry_nmi_enter(regs); do_serror(regs, esr); - arm64_exit_nmi(regs, state); + irqentry_nmi_exit(regs, state); } static void noinstr el0_da(struct pt_regs *regs, unsigned long esr) { unsigned long far = read_sysreg(far_el1); - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); local_daif_restore(DAIF_PROCCTX); do_mem_abort(far, esr, regs); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } static void noinstr el0_ia(struct pt_regs *regs, unsigned long esr) @@ -651,50 +468,50 @@ static void noinstr el0_ia(struct pt_regs *regs, unsigned long esr) if (!is_ttbr0_addr(far)) arm64_apply_bp_hardening(); - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); local_daif_restore(DAIF_PROCCTX); do_mem_abort(far, esr, regs); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } static void noinstr el0_fpsimd_acc(struct pt_regs *regs, unsigned long esr) { - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); local_daif_restore(DAIF_PROCCTX); do_fpsimd_acc(esr, regs); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } static void noinstr el0_sve_acc(struct pt_regs *regs, unsigned long esr) { - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); local_daif_restore(DAIF_PROCCTX); do_sve_acc(esr, regs); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } static void noinstr el0_sme_acc(struct pt_regs *regs, unsigned long esr) { - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); local_daif_restore(DAIF_PROCCTX); do_sme_acc(esr, regs); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } static void noinstr el0_fpsimd_exc(struct pt_regs *regs, unsigned long esr) { - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); local_daif_restore(DAIF_PROCCTX); do_fpsimd_exc(esr, regs); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } static void noinstr el0_sys(struct pt_regs *regs, unsigned long esr) { - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); local_daif_restore(DAIF_PROCCTX); do_el0_sys(esr, regs); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } static void noinstr el0_pc(struct pt_regs *regs, unsigned long esr) @@ -704,58 +521,58 @@ static void noinstr el0_pc(struct pt_regs *regs, unsigned long esr) if (!is_ttbr0_addr(instruction_pointer(regs))) arm64_apply_bp_hardening(); - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); local_daif_restore(DAIF_PROCCTX); do_sp_pc_abort(far, esr, regs); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } static void noinstr el0_sp(struct pt_regs *regs, unsigned long esr) { - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); local_daif_restore(DAIF_PROCCTX); do_sp_pc_abort(regs->sp, esr, regs); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } static void noinstr el0_undef(struct pt_regs *regs, unsigned long esr) { - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); local_daif_restore(DAIF_PROCCTX); do_el0_undef(regs, esr); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } static void noinstr el0_bti(struct pt_regs *regs) { - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); local_daif_restore(DAIF_PROCCTX); do_el0_bti(regs); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } static void noinstr el0_mops(struct pt_regs *regs, unsigned long esr) { - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); local_daif_restore(DAIF_PROCCTX); do_el0_mops(regs, esr); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } static void noinstr el0_gcs(struct pt_regs *regs, unsigned long esr) { - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); local_daif_restore(DAIF_PROCCTX); do_el0_gcs(regs, esr); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } static void noinstr el0_inv(struct pt_regs *regs, unsigned long esr) { - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); local_daif_restore(DAIF_PROCCTX); bad_el0_sync(regs, 0, esr); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } static void noinstr el0_dbg(struct pt_regs *regs, unsigned long esr) @@ -763,28 +580,28 @@ static void noinstr el0_dbg(struct pt_regs *regs, unsigned long esr) /* Only watchpoints write FAR_EL1, otherwise its UNKNOWN */ unsigned long far = read_sysreg(far_el1); - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); do_debug_exception(far, esr, regs); local_daif_restore(DAIF_PROCCTX); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } static void noinstr el0_svc(struct pt_regs *regs) { - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); cortex_a76_erratum_1463225_svc_handler(); fp_user_discard(); local_daif_restore(DAIF_PROCCTX); do_el0_svc(regs); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } static void noinstr el0_fpac(struct pt_regs *regs, unsigned long esr) { - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); local_daif_restore(DAIF_PROCCTX); do_el0_fpac(regs, esr); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } asmlinkage void noinstr el0t_64_sync_handler(struct pt_regs *regs) @@ -852,7 +669,7 @@ asmlinkage void noinstr el0t_64_sync_handler(struct pt_regs *regs) static void noinstr el0_interrupt(struct pt_regs *regs, void (*handler)(struct pt_regs *)) { - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); write_sysreg(DAIF_PROCCTX_NOIRQ, daif); @@ -863,7 +680,7 @@ static void noinstr el0_interrupt(struct pt_regs *regs, do_interrupt_handler(regs, handler); irq_exit_rcu(); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } static void noinstr __el0_irq_handler_common(struct pt_regs *regs) @@ -891,13 +708,13 @@ static void noinstr __el0_error_handler_common(struct pt_regs *regs) unsigned long esr = read_sysreg(esr_el1); irqentry_state_t state; - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); local_daif_restore(DAIF_ERRCTX); - state = arm64_enter_nmi(regs); + state = irqentry_nmi_enter(regs); do_serror(regs, esr); - arm64_exit_nmi(regs, state); + irqentry_nmi_exit(regs, state); local_daif_restore(DAIF_PROCCTX); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } asmlinkage void noinstr el0t_64_error_handler(struct pt_regs *regs) @@ -908,19 +725,19 @@ asmlinkage void noinstr el0t_64_error_handler(struct pt_regs *regs) #ifdef CONFIG_COMPAT static void noinstr el0_cp15(struct pt_regs *regs, unsigned long esr) { - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); local_daif_restore(DAIF_PROCCTX); do_el0_cp15(esr, regs); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } static void noinstr el0_svc_compat(struct pt_regs *regs) { - enter_from_user_mode(regs); + arm64_enter_from_user_mode(regs); cortex_a76_erratum_1463225_svc_handler(); local_daif_restore(DAIF_PROCCTX); do_el0_svc_compat(regs); - exit_to_user_mode(regs); + arm64_exit_to_user_mode(regs); } asmlinkage void noinstr el0t_32_sync_handler(struct pt_regs *regs) @@ -994,7 +811,7 @@ asmlinkage void noinstr __noreturn handle_bad_stack(struct pt_regs *regs) unsigned long esr = read_sysreg(esr_el1); unsigned long far = read_sysreg(far_el1); - arm64_enter_nmi(regs); + irqentry_nmi_enter(regs); panic_bad_stack(regs, esr, far); } #endif /* CONFIG_VMAP_STACK */ @@ -1028,9 +845,9 @@ __sdei_handler(struct pt_regs *regs, struct sdei_registered_event *arg) else if (cpu_has_pan()) set_pstate_pan(0); - state = arm64_enter_nmi(regs); + state = irqentry_nmi_enter(regs); ret = do_sdei_event(regs, arg); - arm64_exit_nmi(regs, state); + irqentry_nmi_exit(regs, state); return ret; } diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c index 14ac6fdb872b..84b6628647c7 100644 --- a/arch/arm64/kernel/signal.c +++ b/arch/arm64/kernel/signal.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include #include @@ -1603,7 +1604,7 @@ static void handle_signal(struct ksignal *ksig, struct pt_regs *regs) * the kernel can handle, and then we build all the user-level signal handling * stack-frames in one go after that. */ -void do_signal(struct pt_regs *regs) +void arch_do_signal_or_restart(struct pt_regs *regs) { unsigned long continue_addr = 0, restart_addr = 0; int retval = 0; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:18:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:18:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849995.1264548 (Exim 4.92) (envelope-from ) id 1tJVPo-0004ei-AD; Fri, 06 Dec 2024 10:18:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849995.1264548; Fri, 06 Dec 2024 10: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 1tJVPn-0004dw-WC; Fri, 06 Dec 2024 10:18:28 +0000 Received: by outflank-mailman (input) for mailman id 849995; Fri, 06 Dec 2024 10:18: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 1tJVPm-0001om-D8 for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:26 +0000 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6aa6598c-b3bb-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 11:18:23 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.163.174]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4Y4Rxg3tbYzRhvD; Fri, 6 Dec 2024 18:16:39 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id 301DB140134; Fri, 6 Dec 2024 18:18:19 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:17 +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: 6aa6598c-b3bb-11ef-99a3-01e77a169b0f From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 10/22] entry: Add arch_irqentry_exit_need_resched() for arm64 Date: Fri, 6 Dec 2024 18:17:32 +0800 Message-ID: <20241206101744.4161990-11-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) ARM64 requires an additional check whether to reschedule on return from interrupt. Add arch_irqentry_exit_need_resched() as the default NOP implementation and hook it up into the need_resched() condition in raw_irqentry_exit_cond_resched(). This allows ARM64 to implement the architecture specific version for switching over to the generic entry code. Suggested-by: Mark Rutland Suggested-by: Kevin Brodsky Suggested-by: Thomas Gleixner Signed-off-by: Jinjie Ruan --- kernel/entry/common.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/kernel/entry/common.c b/kernel/entry/common.c index b82032777310..4aa9656fa1b4 100644 --- a/kernel/entry/common.c +++ b/kernel/entry/common.c @@ -142,6 +142,20 @@ noinstr irqentry_state_t irqentry_enter(struct pt_regs *regs) return ret; } +/** + * arch_irqentry_exit_need_resched - Architecture specific need resched function + * + * Invoked from raw_irqentry_exit_cond_resched() to check if need resched. + * Defaults return true. + * + * The main purpose is to permit arch to skip preempt a task from an IRQ. + */ +static inline bool arch_irqentry_exit_need_resched(void); + +#ifndef arch_irqentry_exit_need_resched +static inline bool arch_irqentry_exit_need_resched(void) { return true; } +#endif + void raw_irqentry_exit_cond_resched(void) { if (!preempt_count()) { @@ -149,7 +163,7 @@ void raw_irqentry_exit_cond_resched(void) rcu_irq_exit_check_preempt(); if (IS_ENABLED(CONFIG_DEBUG_ENTRY)) WARN_ON_ONCE(!on_thread_stack()); - if (need_resched()) + if (need_resched() && arch_irqentry_exit_need_resched()) preempt_schedule_irq(); } } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:18:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:18:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.849996.1264555 (Exim 4.92) (envelope-from ) id 1tJVPp-0004r8-OR; Fri, 06 Dec 2024 10:18:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 849996.1264555; Fri, 06 Dec 2024 10:18: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 1tJVPp-0004q3-52; Fri, 06 Dec 2024 10:18:29 +0000 Received: by outflank-mailman (input) for mailman id 849996; Fri, 06 Dec 2024 10:18: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 1tJVPn-0001om-D9 for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:27 +0000 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6bf7821f-b3bb-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 11:18:23 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.88.194]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Y4RxY2kBHzqTBp; Fri, 6 Dec 2024 18:16:33 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id 972DA1400FD; Fri, 6 Dec 2024 18:18:21 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:20 +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: 6bf7821f-b3bb-11ef-99a3-01e77a169b0f From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 12/22] arm64/ptrace: Split report_syscall() function Date: Fri, 6 Dec 2024 18:17:34 +0800 Message-ID: <20241206101744.4161990-13-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) Split report_syscall() to two separate enter and exit functions. So it will be more clear when arm64 switch to generic entry. No functional changes. Suggested-by: Mark Rutland Signed-off-by: Jinjie Ruan --- arch/arm64/kernel/ptrace.c | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-) diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c index e4437f62a2cd..d0d801a4094a 100644 --- a/arch/arm64/kernel/ptrace.c +++ b/arch/arm64/kernel/ptrace.c @@ -2298,7 +2298,7 @@ enum ptrace_syscall_dir { PTRACE_SYSCALL_EXIT, }; -static void report_syscall(struct pt_regs *regs, enum ptrace_syscall_dir dir) +static void report_syscall_enter(struct pt_regs *regs) { int regno; unsigned long saved_reg; @@ -2321,13 +2321,24 @@ static void report_syscall(struct pt_regs *regs, enum ptrace_syscall_dir dir) */ regno = (is_compat_task() ? 12 : 7); saved_reg = regs->regs[regno]; - regs->regs[regno] = dir; + regs->regs[regno] = PTRACE_SYSCALL_ENTER; - if (dir == PTRACE_SYSCALL_ENTER) { - if (ptrace_report_syscall_entry(regs)) - forget_syscall(regs); - regs->regs[regno] = saved_reg; - } else if (!test_thread_flag(TIF_SINGLESTEP)) { + if (ptrace_report_syscall_entry(regs)) + forget_syscall(regs); + regs->regs[regno] = saved_reg; +} + +static void report_syscall_exit(struct pt_regs *regs) +{ + int regno; + unsigned long saved_reg; + + /* See comment for report_syscall_enter() */ + regno = (is_compat_task() ? 12 : 7); + saved_reg = regs->regs[regno]; + regs->regs[regno] = PTRACE_SYSCALL_EXIT; + + if (!test_thread_flag(TIF_SINGLESTEP)) { ptrace_report_syscall_exit(regs, 0); regs->regs[regno] = saved_reg; } else { @@ -2347,7 +2358,7 @@ int syscall_trace_enter(struct pt_regs *regs) unsigned long flags = read_thread_flags(); if (flags & (_TIF_SYSCALL_EMU | _TIF_SYSCALL_TRACE)) { - report_syscall(regs, PTRACE_SYSCALL_ENTER); + report_syscall_enter(regs); if (flags & _TIF_SYSCALL_EMU) return NO_SYSCALL; } @@ -2375,7 +2386,7 @@ void syscall_trace_exit(struct pt_regs *regs) trace_sys_exit(regs, syscall_get_return_value(current, regs)); if (flags & (_TIF_SYSCALL_TRACE | _TIF_SINGLESTEP)) - report_syscall(regs, PTRACE_SYSCALL_EXIT); + report_syscall_exit(regs); rseq_syscall(regs); } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:18:32 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:18:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850004.1264566 (Exim 4.92) (envelope-from ) id 1tJVPs-0005TQ-7E; Fri, 06 Dec 2024 10:18:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850004.1264566; Fri, 06 Dec 2024 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 1tJVPr-0005QM-Qq; Fri, 06 Dec 2024 10:18:31 +0000 Received: by outflank-mailman (input) for mailman id 850004; Fri, 06 Dec 2024 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 1tJVPq-0001of-D7 for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:30 +0000 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6e5c0c36-b3bb-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 11:18:28 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Y4RwQ3XBKzgZ8D; Fri, 6 Dec 2024 18:15:34 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id 41FA418009B; Fri, 6 Dec 2024 18:18:25 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:23 +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: 6e5c0c36-b3bb-11ef-a0d5-8be0dac302b0 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 15/22] arm64/ptrace: Refator el0_svc_common() Date: Fri, 6 Dec 2024 18:17:37 +0800 Message-ID: <20241206101744.4161990-16-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) As the generic entry, before report_syscall_exit(), it terminate the process if the syscall is issued within a restartable sequence. In preparation for moving arm64 over to the generic entry code, refator el0_svc_common() as below: - Extract syscall_exit_to_user_mode_prepare() helper to replace the the combination of read_thread_flags() and syscall_trace_exit(), also move the syscall exit check logic into it. - Move rseq_syscall() ahead, so the CONFIG_DEBUG_RSEQ check is not needed. - Move has_syscall_work() helper into asm/syscall.h to be reused for ptrace.c. Signed-off-by: Jinjie Ruan --- arch/arm64/include/asm/syscall.h | 7 ++++++- arch/arm64/kernel/ptrace.c | 10 +++++++++- arch/arm64/kernel/syscall.c | 26 +++++--------------------- 3 files changed, 20 insertions(+), 23 deletions(-) diff --git a/arch/arm64/include/asm/syscall.h b/arch/arm64/include/asm/syscall.h index 925a257145f9..6eeb1e7b033f 100644 --- a/arch/arm64/include/asm/syscall.h +++ b/arch/arm64/include/asm/syscall.h @@ -85,7 +85,12 @@ static inline int syscall_get_arch(struct task_struct *task) return AUDIT_ARCH_AARCH64; } +static inline bool has_syscall_work(unsigned long flags) +{ + return unlikely(flags & _TIF_SYSCALL_WORK); +} + int syscall_trace_enter(struct pt_regs *regs, long syscall, unsigned long flags); -void syscall_trace_exit(struct pt_regs *regs, unsigned long flags); +void syscall_exit_to_user_mode_prepare(struct pt_regs *regs); #endif /* __ASM_SYSCALL_H */ diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c index bb994d668d74..23df2e558fe9 100644 --- a/arch/arm64/kernel/ptrace.c +++ b/arch/arm64/kernel/ptrace.c @@ -2384,7 +2384,7 @@ int syscall_trace_enter(struct pt_regs *regs, long syscall, unsigned long flags) return regs->syscallno; } -void syscall_trace_exit(struct pt_regs *regs, unsigned long flags) +static void syscall_trace_exit(struct pt_regs *regs, unsigned long flags) { audit_syscall_exit(regs); @@ -2393,8 +2393,16 @@ void syscall_trace_exit(struct pt_regs *regs, unsigned long flags) if (flags & (_TIF_SYSCALL_TRACE | _TIF_SINGLESTEP)) report_syscall_exit(regs); +} + +void syscall_exit_to_user_mode_prepare(struct pt_regs *regs) +{ + unsigned long flags = read_thread_flags(); rseq_syscall(regs); + + if (has_syscall_work(flags) || flags & _TIF_SINGLESTEP) + syscall_trace_exit(regs, flags); } /* diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c index 064dc114fb9b..a50db885fc34 100644 --- a/arch/arm64/kernel/syscall.c +++ b/arch/arm64/kernel/syscall.c @@ -65,11 +65,6 @@ static void invoke_syscall(struct pt_regs *regs, unsigned int scno, choose_random_kstack_offset(get_random_u16()); } -static inline bool has_syscall_work(unsigned long flags) -{ - return unlikely(flags & _TIF_SYSCALL_WORK); -} - static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr, const syscall_fn_t syscall_table[]) { @@ -125,26 +120,15 @@ static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr, if (scno == NO_SYSCALL) syscall_set_return_value(current, regs, -ENOSYS, 0); scno = syscall_trace_enter(regs, regs->syscallno, flags); - if (scno == NO_SYSCALL) - goto trace_exit; + if (scno == NO_SYSCALL) { + syscall_exit_to_user_mode_prepare(regs); + return; + } } invoke_syscall(regs, scno, sc_nr, syscall_table); - /* - * The tracing status may have changed under our feet, so we have to - * check again. However, if we were tracing entry, then we always trace - * exit regardless, as the old entry assembly did. - */ - if (!has_syscall_work(flags) && !IS_ENABLED(CONFIG_DEBUG_RSEQ)) { - flags = read_thread_flags(); - if (!has_syscall_work(flags) && !(flags & _TIF_SINGLESTEP)) - return; - } - -trace_exit: - flags = read_thread_flags(); - syscall_trace_exit(regs, flags); + syscall_exit_to_user_mode_prepare(regs); } void do_el0_svc(struct pt_regs *regs) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:20:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:20:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850049.1264580 (Exim 4.92) (envelope-from ) id 1tJVRz-0001oj-N0; Fri, 06 Dec 2024 10:20:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850049.1264580; Fri, 06 Dec 2024 10:20: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 1tJVRz-0001oc-KH; Fri, 06 Dec 2024 10:20:43 +0000 Received: by outflank-mailman (input) for mailman id 850049; Fri, 06 Dec 2024 10:20: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 1tJVPu-0001om-In for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:34 +0000 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 711a417a-b3bb-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 11:18:32 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Y4Rxj60gFzqTYt; Fri, 6 Dec 2024 18:16:41 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id 13D7618009B; Fri, 6 Dec 2024 18:18:30 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:28 +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: 711a417a-b3bb-11ef-99a3-01e77a169b0f From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 19/22] arm64/ptrace: Use syscall_get_arguments() heleper Date: Fri, 6 Dec 2024 18:17:41 +0800 Message-ID: <20241206101744.4161990-20-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) The generic entry check audit context first and use syscall_get_arguments() helper. In order to switch to the generic entry for arm64, - Also use the helper. - Extract the syscall_enter_audit() helper to make it clear. - Check audit context for syscall_enter_audit(), which only adds one additional check without any other differences as audit_syscall_entry() check it first otherwise do nothing. No functional changes. Signed-off-by: Jinjie Ruan --- arch/arm64/kernel/ptrace.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c index c0c00e173f61..3a7a1eaca0a9 100644 --- a/arch/arm64/kernel/ptrace.c +++ b/arch/arm64/kernel/ptrace.c @@ -2357,6 +2357,17 @@ static void report_syscall_exit(struct pt_regs *regs) } } +static inline void syscall_enter_audit(struct pt_regs *regs, long syscall) +{ + if (unlikely(audit_context())) { + unsigned long args[6]; + + syscall_get_arguments(current, regs, args); + audit_syscall_entry(syscall, args[0], args[1], args[2], args[3]); + } + +} + int syscall_trace_enter(struct pt_regs *regs, long syscall, unsigned long flags) { int ret; @@ -2387,8 +2398,7 @@ int syscall_trace_enter(struct pt_regs *regs, long syscall, unsigned long flags) syscall = syscall_get_nr(current, regs); } - audit_syscall_entry(syscall, regs->orig_x0, regs->regs[1], - regs->regs[2], regs->regs[3]); + syscall_enter_audit(regs, syscall); return regs->syscallno; } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:20:52 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:20:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850055.1264591 (Exim 4.92) (envelope-from ) id 1tJVS7-0002CJ-Uz; Fri, 06 Dec 2024 10:20:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850055.1264591; Fri, 06 Dec 2024 10:20: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 1tJVS7-0002CA-SE; Fri, 06 Dec 2024 10:20:51 +0000 Received: by outflank-mailman (input) for mailman id 850055; Fri, 06 Dec 2024 10:20: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 1tJVQ7-0001of-GM for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:47 +0000 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 73399b33-b3bb-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 11:18:36 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.163.252]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Y4RwZ71KbzgZ88; Fri, 6 Dec 2024 18:15:42 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id B46F71800D9; Fri, 6 Dec 2024 18:18:33 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:32 +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: 73399b33-b3bb-11ef-a0d5-8be0dac302b0 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 22/22] arm64: entry: Convert to generic entry Date: Fri, 6 Dec 2024 18:17:44 +0800 Message-ID: <20241206101744.4161990-23-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) Currently, x86, Riscv, Loongarch use the generic entry. Convert arm64 to use the generic entry infrastructure from kernel/entry/*. The generic entry makes maintainers' work easier and codes more elegant. The changes are below: - Remove TIF_SYSCALL_* flag, _TIF_WORK_MASK, _TIF_SYSCALL_WORK - Remove syscall_trace_enter/exit() and use generic identical functions. Tested ok with following test cases on Qemu virt platform: - Perf tests. - Different `dynamic preempt` mode switch. - Pseudo NMI tests. - Stress-ng CPU stress test. - MTE test case in Documentation/arch/arm64/memory-tagging-extension.rst and all test cases in tools/testing/selftests/arm64/mte/*. Suggested-by: Mark Rutland Signed-off-by: Jinjie Ruan --- v5: - Rebased on the previous patch udapte. - Define ARCH_SYSCALL_WORK_EXIT. --- arch/arm64/Kconfig | 2 +- arch/arm64/include/asm/entry-common.h | 70 ++++++++++++++ arch/arm64/include/asm/syscall.h | 7 +- arch/arm64/include/asm/thread_info.h | 23 +---- arch/arm64/kernel/debug-monitors.c | 7 ++ arch/arm64/kernel/ptrace.c | 134 -------------------------- arch/arm64/kernel/signal.c | 2 +- arch/arm64/kernel/syscall.c | 6 +- 8 files changed, 87 insertions(+), 164 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 3751ab9f2a21..a1d96712428e 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -148,9 +148,9 @@ config ARM64 select GENERIC_CPU_DEVICES select GENERIC_CPU_VULNERABILITIES select GENERIC_EARLY_IOREMAP + select GENERIC_ENTRY select GENERIC_IDLE_POLL_SETUP select GENERIC_IOREMAP - select GENERIC_IRQ_ENTRY select GENERIC_IRQ_IPI select GENERIC_IRQ_KEXEC_CLEAR_VM_FORWARD select GENERIC_IRQ_PROBE diff --git a/arch/arm64/include/asm/entry-common.h b/arch/arm64/include/asm/entry-common.h index 1cc9d966a6c3..6082393c61f2 100644 --- a/arch/arm64/include/asm/entry-common.h +++ b/arch/arm64/include/asm/entry-common.h @@ -10,6 +10,12 @@ #include #include +enum ptrace_syscall_dir { + PTRACE_SYSCALL_ENTER = 0, + PTRACE_SYSCALL_EXIT, +}; + +#define ARCH_SYSCALL_WORK_EXIT (SYSCALL_WORK_SECCOMP | SYSCALL_WORK_SYSCALL_EMU) #define ARCH_EXIT_TO_USER_MODE_WORK (_TIF_MTE_ASYNC_FAULT | _TIF_FOREIGN_FPSTATE) static __always_inline void arch_exit_to_user_mode_work(struct pt_regs *regs, @@ -61,4 +67,68 @@ static inline bool arch_irqentry_exit_need_resched(void) #define arch_irqentry_exit_need_resched arch_irqentry_exit_need_resched +static inline int arch_ptrace_report_syscall_entry(struct pt_regs *regs) +{ + unsigned long saved_reg; + int regno, ret; + + /* + * We have some ABI weirdness here in the way that we handle syscall + * exit stops because we indicate whether or not the stop has been + * signalled from syscall entry or syscall exit by clobbering a general + * purpose register (ip/r12 for AArch32, x7 for AArch64) in the tracee + * and restoring its old value after the stop. This means that: + * + * - Any writes by the tracer to this register during the stop are + * ignored/discarded. + * + * - The actual value of the register is not available during the stop, + * so the tracer cannot save it and restore it later. + * + * - Syscall stops behave differently to seccomp and pseudo-step traps + * (the latter do not nobble any registers). + */ + regno = (is_compat_task() ? 12 : 7); + saved_reg = regs->regs[regno]; + regs->regs[regno] = PTRACE_SYSCALL_ENTER; + + ret = ptrace_report_syscall_entry(regs); + if (ret) + forget_syscall(regs); + + regs->regs[regno] = saved_reg; + + return ret; +} + +#define arch_ptrace_report_syscall_entry arch_ptrace_report_syscall_entry + +static inline void arch_ptrace_report_syscall_exit(struct pt_regs *regs, + int step) +{ + unsigned long saved_reg; + int regno; + + /* See comment for arch_ptrace_report_syscall_entry() */ + regno = (is_compat_task() ? 12 : 7); + saved_reg = regs->regs[regno]; + regs->regs[regno] = PTRACE_SYSCALL_EXIT; + + if (!test_thread_flag(TIF_SINGLESTEP)) { + ptrace_report_syscall_exit(regs, 0); + regs->regs[regno] = saved_reg; + } else { + regs->regs[regno] = saved_reg; + + /* + * Signal a pseudo-step exception since we are stepping but + * tracer modifications to the registers may have rewound the + * state machine. + */ + ptrace_report_syscall_exit(regs, 1); + } +} + +#define arch_ptrace_report_syscall_exit arch_ptrace_report_syscall_exit + #endif /* _ASM_ARM64_ENTRY_COMMON_H */ diff --git a/arch/arm64/include/asm/syscall.h b/arch/arm64/include/asm/syscall.h index 6eeb1e7b033f..9891b15da4c3 100644 --- a/arch/arm64/include/asm/syscall.h +++ b/arch/arm64/include/asm/syscall.h @@ -85,12 +85,9 @@ static inline int syscall_get_arch(struct task_struct *task) return AUDIT_ARCH_AARCH64; } -static inline bool has_syscall_work(unsigned long flags) +static inline bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs) { - return unlikely(flags & _TIF_SYSCALL_WORK); + return false; } -int syscall_trace_enter(struct pt_regs *regs, long syscall, unsigned long flags); -void syscall_exit_to_user_mode_prepare(struct pt_regs *regs); - #endif /* __ASM_SYSCALL_H */ diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h index 1114c1c3300a..543fdb00d713 100644 --- a/arch/arm64/include/asm/thread_info.h +++ b/arch/arm64/include/asm/thread_info.h @@ -43,6 +43,7 @@ struct thread_info { void *scs_sp; #endif u32 cpu; + unsigned long syscall_work; /* SYSCALL_WORK_ flags */ }; #define thread_saved_pc(tsk) \ @@ -64,11 +65,6 @@ void arch_setup_new_exec(void); #define TIF_UPROBE 4 /* uprobe breakpoint or singlestep */ #define TIF_MTE_ASYNC_FAULT 5 /* MTE Asynchronous Tag Check Fault */ #define TIF_NOTIFY_SIGNAL 6 /* signal notifications exist */ -#define TIF_SYSCALL_TRACE 8 /* syscall trace active */ -#define TIF_SYSCALL_AUDIT 9 /* syscall auditing */ -#define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */ -#define TIF_SECCOMP 11 /* syscall secure computing */ -#define TIF_SYSCALL_EMU 12 /* syscall emulation active */ #define TIF_MEMDIE 18 /* is terminating due to OOM killer */ #define TIF_FREEZE 19 #define TIF_RESTORE_SIGMASK 20 @@ -87,28 +83,13 @@ void arch_setup_new_exec(void); #define _TIF_NEED_RESCHED (1 << TIF_NEED_RESCHED) #define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME) #define _TIF_FOREIGN_FPSTATE (1 << TIF_FOREIGN_FPSTATE) -#define _TIF_SYSCALL_TRACE (1 << TIF_SYSCALL_TRACE) -#define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT) -#define _TIF_SYSCALL_TRACEPOINT (1 << TIF_SYSCALL_TRACEPOINT) -#define _TIF_SECCOMP (1 << TIF_SECCOMP) -#define _TIF_SYSCALL_EMU (1 << TIF_SYSCALL_EMU) -#define _TIF_UPROBE (1 << TIF_UPROBE) -#define _TIF_SINGLESTEP (1 << TIF_SINGLESTEP) +#define _TIF_UPROBE (1 << TIF_UPROBE) #define _TIF_32BIT (1 << TIF_32BIT) #define _TIF_SVE (1 << TIF_SVE) #define _TIF_MTE_ASYNC_FAULT (1 << TIF_MTE_ASYNC_FAULT) #define _TIF_NOTIFY_SIGNAL (1 << TIF_NOTIFY_SIGNAL) #define _TIF_TSC_SIGSEGV (1 << TIF_TSC_SIGSEGV) -#define _TIF_WORK_MASK (_TIF_NEED_RESCHED | _TIF_SIGPENDING | \ - _TIF_NOTIFY_RESUME | _TIF_FOREIGN_FPSTATE | \ - _TIF_UPROBE | _TIF_MTE_ASYNC_FAULT | \ - _TIF_NOTIFY_SIGNAL) - -#define _TIF_SYSCALL_WORK (_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | \ - _TIF_SYSCALL_TRACEPOINT | _TIF_SECCOMP | \ - _TIF_SYSCALL_EMU) - #ifdef CONFIG_SHADOW_CALL_STACK #define INIT_SCS \ .scs_base = init_shadow_call_stack, \ diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c index 460c09d03a73..95b70555a1a8 100644 --- a/arch/arm64/kernel/debug-monitors.c +++ b/arch/arm64/kernel/debug-monitors.c @@ -452,11 +452,18 @@ void user_enable_single_step(struct task_struct *task) if (!test_and_set_ti_thread_flag(ti, TIF_SINGLESTEP)) set_regs_spsr_ss(task_pt_regs(task)); + + /* + * Ensure that a trap is triggered once stepping out of a system + * call prior to executing any user instruction. + */ + set_task_syscall_work(task, SYSCALL_EXIT_TRAP); } NOKPROBE_SYMBOL(user_enable_single_step); void user_disable_single_step(struct task_struct *task) { clear_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP); + clear_task_syscall_work(task, SYSCALL_EXIT_TRAP); } NOKPROBE_SYMBOL(user_disable_single_step); diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c index 3a7a1eaca0a9..a09058b9b7fb 100644 --- a/arch/arm64/kernel/ptrace.c +++ b/arch/arm64/kernel/ptrace.c @@ -42,9 +42,6 @@ #include #include -#define CREATE_TRACE_POINTS -#include - struct pt_regs_offset { const char *name; int offset; @@ -2293,137 +2290,6 @@ long arch_ptrace(struct task_struct *child, long request, return ptrace_request(child, request, addr, data); } -enum ptrace_syscall_dir { - PTRACE_SYSCALL_ENTER = 0, - PTRACE_SYSCALL_EXIT, -}; - -static int report_syscall_enter(struct pt_regs *regs) -{ - unsigned long saved_reg; - int regno, ret; - - /* - * We have some ABI weirdness here in the way that we handle syscall - * exit stops because we indicate whether or not the stop has been - * signalled from syscall entry or syscall exit by clobbering a general - * purpose register (ip/r12 for AArch32, x7 for AArch64) in the tracee - * and restoring its old value after the stop. This means that: - * - * - Any writes by the tracer to this register during the stop are - * ignored/discarded. - * - * - The actual value of the register is not available during the stop, - * so the tracer cannot save it and restore it later. - * - * - Syscall stops behave differently to seccomp and pseudo-step traps - * (the latter do not nobble any registers). - */ - regno = (is_compat_task() ? 12 : 7); - saved_reg = regs->regs[regno]; - regs->regs[regno] = PTRACE_SYSCALL_ENTER; - - ret = ptrace_report_syscall_entry(regs); - if (ret) - forget_syscall(regs); - - regs->regs[regno] = saved_reg; - - return ret; -} - -static void report_syscall_exit(struct pt_regs *regs) -{ - int regno; - unsigned long saved_reg; - - /* See comment for report_syscall_enter() */ - regno = (is_compat_task() ? 12 : 7); - saved_reg = regs->regs[regno]; - regs->regs[regno] = PTRACE_SYSCALL_EXIT; - - if (!test_thread_flag(TIF_SINGLESTEP)) { - ptrace_report_syscall_exit(regs, 0); - regs->regs[regno] = saved_reg; - } else { - regs->regs[regno] = saved_reg; - - /* - * Signal a pseudo-step exception since we are stepping but - * tracer modifications to the registers may have rewound the - * state machine. - */ - ptrace_report_syscall_exit(regs, 1); - } -} - -static inline void syscall_enter_audit(struct pt_regs *regs, long syscall) -{ - if (unlikely(audit_context())) { - unsigned long args[6]; - - syscall_get_arguments(current, regs, args); - audit_syscall_entry(syscall, args[0], args[1], args[2], args[3]); - } - -} - -int syscall_trace_enter(struct pt_regs *regs, long syscall, unsigned long flags) -{ - int ret; - - if (flags & (_TIF_SYSCALL_EMU | _TIF_SYSCALL_TRACE)) { - ret = report_syscall_enter(regs); - if (ret || (flags & _TIF_SYSCALL_EMU)) - return NO_SYSCALL; - } - - /* Do the secure computing after ptrace; failures should be fast. */ - if (flags & _TIF_SECCOMP) { - ret = __secure_computing(NULL); - if (ret == -1L) - return NO_SYSCALL; - } - - /* Either of the above might have changed the syscall number */ - syscall = syscall_get_nr(current, regs); - - if (test_thread_flag(TIF_SYSCALL_TRACEPOINT)) { - trace_sys_enter(regs, syscall); - - /* - * Probes or BPF hooks in the tracepoint may have changed the - * system call number as well. - */ - syscall = syscall_get_nr(current, regs); - } - - syscall_enter_audit(regs, syscall); - - return regs->syscallno; -} - -static void syscall_trace_exit(struct pt_regs *regs, unsigned long flags) -{ - audit_syscall_exit(regs); - - if (flags & _TIF_SYSCALL_TRACEPOINT) - trace_sys_exit(regs, syscall_get_return_value(current, regs)); - - if (flags & (_TIF_SYSCALL_TRACE | _TIF_SINGLESTEP)) - report_syscall_exit(regs); -} - -void syscall_exit_to_user_mode_prepare(struct pt_regs *regs) -{ - unsigned long flags = read_thread_flags(); - - rseq_syscall(regs); - - if (has_syscall_work(flags) || flags & _TIF_SINGLESTEP) - syscall_trace_exit(regs, flags); -} - /* * SPSR_ELx bits which are always architecturally RES0 per ARM DDI 0487D.a. * We permit userspace to set SSBS (AArch64 bit 12, AArch32 bit 23) which is diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c index 84b6628647c7..6cc8fe19e6a0 100644 --- a/arch/arm64/kernel/signal.c +++ b/arch/arm64/kernel/signal.c @@ -8,8 +8,8 @@ #include #include +#include #include -#include #include #include #include diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c index a50db885fc34..5aa585111c4b 100644 --- a/arch/arm64/kernel/syscall.c +++ b/arch/arm64/kernel/syscall.c @@ -2,6 +2,7 @@ #include #include +#include #include #include #include @@ -68,6 +69,7 @@ static void invoke_syscall(struct pt_regs *regs, unsigned int scno, static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr, const syscall_fn_t syscall_table[]) { + unsigned long work = READ_ONCE(current_thread_info()->syscall_work); unsigned long flags = read_thread_flags(); regs->orig_x0 = regs->regs[0]; @@ -101,7 +103,7 @@ static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr, return; } - if (has_syscall_work(flags)) { + if (has_syscall_work(work)) { /* * The de-facto standard way to skip a system call using ptrace * is to set the system call to -1 (NO_SYSCALL) and set x0 to a @@ -119,7 +121,7 @@ static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr, */ if (scno == NO_SYSCALL) syscall_set_return_value(current, regs, -ENOSYS, 0); - scno = syscall_trace_enter(regs, regs->syscallno, flags); + scno = syscall_trace_enter(regs, regs->syscallno, work); if (scno == NO_SYSCALL) { syscall_exit_to_user_mode_prepare(regs); return; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:20:53 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:20:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850058.1264600 (Exim 4.92) (envelope-from ) id 1tJVS9-0002SB-9f; Fri, 06 Dec 2024 10:20:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850058.1264600; Fri, 06 Dec 2024 10:20: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 1tJVS9-0002S4-6o; Fri, 06 Dec 2024 10:20:53 +0000 Received: by outflank-mailman (input) for mailman id 850058; Fri, 06 Dec 2024 10:20: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 1tJVPr-0001om-GE for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:31 +0000 Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6f0b9801-b3bb-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 11:18:29 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.88.163]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4Y4S023RH5z1yrpl; Fri, 6 Dec 2024 18:18:42 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id 71C49180041; Fri, 6 Dec 2024 18:18:26 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:25 +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: 6f0b9801-b3bb-11ef-99a3-01e77a169b0f From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 16/22] entry: Make syscall_exit_to_user_mode_prepare() not static Date: Fri, 6 Dec 2024 18:17:38 +0800 Message-ID: <20241206101744.4161990-17-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) In order to switch to the generic entry for arm64, make syscall_exit_to_user_mode_prepare() not static and can be used by arm64. No functional changes. Signed-off-by: Jinjie Ruan --- include/linux/entry-common.h | 1 + kernel/entry/syscall-common.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/entry-common.h b/include/linux/entry-common.h index b3233e8328c5..d11bdb4679b3 100644 --- a/include/linux/entry-common.h +++ b/include/linux/entry-common.h @@ -172,5 +172,6 @@ void syscall_exit_to_user_mode_work(struct pt_regs *regs); * compelling architectural reason to use the separate functions. */ void syscall_exit_to_user_mode(struct pt_regs *regs); +void syscall_exit_to_user_mode_prepare(struct pt_regs *regs); #endif diff --git a/kernel/entry/syscall-common.c b/kernel/entry/syscall-common.c index 0eb036986ad4..f78285097111 100644 --- a/kernel/entry/syscall-common.c +++ b/kernel/entry/syscall-common.c @@ -115,7 +115,7 @@ static void syscall_exit_work(struct pt_regs *regs, unsigned long work) * Syscall specific exit to user mode preparation. Runs with interrupts * enabled. */ -static void syscall_exit_to_user_mode_prepare(struct pt_regs *regs) +void syscall_exit_to_user_mode_prepare(struct pt_regs *regs) { unsigned long work = READ_ONCE(current_thread_info()->syscall_work); unsigned long nr = syscall_get_nr(current, regs); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:20:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:20:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850059.1264611 (Exim 4.92) (envelope-from ) id 1tJVSC-0002pO-JE; Fri, 06 Dec 2024 10:20:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850059.1264611; Fri, 06 Dec 2024 10:20: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 1tJVSC-0002pF-Ef; Fri, 06 Dec 2024 10:20:56 +0000 Received: by outflank-mailman (input) for mailman id 850059; Fri, 06 Dec 2024 10:20: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 1tJVPv-0001om-TW for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:35 +0000 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 71ca7984-b3bb-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 11:18:33 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.162.254]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4Y4Rx80XRtz11Pbq; Fri, 6 Dec 2024 18:16:12 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id 41226180106; Fri, 6 Dec 2024 18:18:31 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:29 +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: 71ca7984-b3bb-11ef-99a3-01e77a169b0f From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 20/22] entry: Add arch_ptrace_report_syscall_entry/exit() Date: Fri, 6 Dec 2024 18:17:42 +0800 Message-ID: <20241206101744.4161990-21-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) Due to historical reasons, ARM64 need to save/restore during syscall entry/exit because ARM64 use a scratch register (ip(r12) on AArch32, x7 on AArch64) to denote syscall entry/exit, which differs from the implementation of the generic entry. Add arch_ptrace_report_syscall_entry/exit() as the default ptrace_report_syscall_entry/exit() implementation. This allows arm64 to implement the architecture specific version for switching over to the generic entry code. Suggested-by: Mark Rutland Suggested-by: Kevin Brodsky Suggested-by: Thomas Gleixner Signed-off-by: Jinjie Ruan --- kernel/entry/syscall-common.c | 43 +++++++++++++++++++++++++++++++++-- 1 file changed, 41 insertions(+), 2 deletions(-) diff --git a/kernel/entry/syscall-common.c b/kernel/entry/syscall-common.c index f78285097111..9ffa6349e769 100644 --- a/kernel/entry/syscall-common.c +++ b/kernel/entry/syscall-common.c @@ -17,6 +17,25 @@ static inline void syscall_enter_audit(struct pt_regs *regs, long syscall) } } +/** + * arch_ptrace_report_syscall_entry - Architecture specific + * ptrace_report_syscall_entry(). + * + * Invoked from syscall_trace_enter() to wrap ptrace_report_syscall_entry(). + * Defaults to ptrace_report_syscall_entry. + * + * The main purpose is to support arch-specific ptrace_report_syscall_entry() + * implementation. + */ +static inline int arch_ptrace_report_syscall_entry(struct pt_regs *regs); + +#ifndef arch_ptrace_report_syscall_entry +static inline int arch_ptrace_report_syscall_entry(struct pt_regs *regs) +{ + return ptrace_report_syscall_entry(regs); +} +#endif + long syscall_trace_enter(struct pt_regs *regs, long syscall, unsigned long work) { @@ -34,7 +53,7 @@ long syscall_trace_enter(struct pt_regs *regs, long syscall, /* Handle ptrace */ if (work & (SYSCALL_WORK_SYSCALL_TRACE | SYSCALL_WORK_SYSCALL_EMU)) { - ret = ptrace_report_syscall_entry(regs); + ret = arch_ptrace_report_syscall_entry(regs); if (ret || (work & SYSCALL_WORK_SYSCALL_EMU)) return -1L; } @@ -84,6 +103,26 @@ static inline bool report_single_step(unsigned long work) return work & SYSCALL_WORK_SYSCALL_EXIT_TRAP; } +/** + * arch_ptrace_report_syscall_exit - Architecture specific + * ptrace_report_syscall_exit. + * + * Invoked from syscall_exit_work() to wrap ptrace_report_syscall_exit(). + * + * The main purpose is to support arch-specific ptrace_report_syscall_exit + * implementation. + */ +static inline void arch_ptrace_report_syscall_exit(struct pt_regs *regs, + int step); + +#ifndef arch_ptrace_report_syscall_exit +static inline void arch_ptrace_report_syscall_exit(struct pt_regs *regs, + int step) +{ + ptrace_report_syscall_exit(regs, step); +} +#endif + static void syscall_exit_work(struct pt_regs *regs, unsigned long work) { bool step; @@ -108,7 +147,7 @@ static void syscall_exit_work(struct pt_regs *regs, unsigned long work) step = report_single_step(work); if (step || work & SYSCALL_WORK_SYSCALL_TRACE) - ptrace_report_syscall_exit(regs, step); + arch_ptrace_report_syscall_exit(regs, step); } /* -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:20:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:20:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850066.1264621 (Exim 4.92) (envelope-from ) id 1tJVSE-0003BQ-UA; Fri, 06 Dec 2024 10:20:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850066.1264621; Fri, 06 Dec 2024 10:20: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 1tJVSE-0003B8-Pr; Fri, 06 Dec 2024 10:20:58 +0000 Received: by outflank-mailman (input) for mailman id 850066; Fri, 06 Dec 2024 10: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 1tJVQ1-0001of-FF for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:41 +0000 Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 705420c8-b3bb-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 11:18:31 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.162.112]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4Y4Rx553lHz1kvW2; Fri, 6 Dec 2024 18:16:09 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id DBC6A1401DC; Fri, 6 Dec 2024 18:18:28 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18: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: 705420c8-b3bb-11ef-a0d5-8be0dac302b0 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 18/22] arm64/ptrace: Expand secure_computing() in place Date: Fri, 6 Dec 2024 18:17:40 +0800 Message-ID: <20241206101744.4161990-19-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) The generic entry expand secure_computing() in place and call __secure_computing() directly. In order to switch to the generic entry for arm64, refactor secure_computing() for syscall_trace_enter(). No functional changes. Signed-off-by: Jinjie Ruan --- arch/arm64/kernel/ptrace.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c index b53d3759baf8..c0c00e173f61 100644 --- a/arch/arm64/kernel/ptrace.c +++ b/arch/arm64/kernel/ptrace.c @@ -2368,8 +2368,11 @@ int syscall_trace_enter(struct pt_regs *regs, long syscall, unsigned long flags) } /* Do the secure computing after ptrace; failures should be fast. */ - if (secure_computing() == -1) - return NO_SYSCALL; + if (flags & _TIF_SECCOMP) { + ret = __secure_computing(NULL); + if (ret == -1L) + return NO_SYSCALL; + } /* Either of the above might have changed the syscall number */ syscall = syscall_get_nr(current, regs); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:20:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:20:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850068.1264623 (Exim 4.92) (envelope-from ) id 1tJVSF-0003Ey-8W; Fri, 06 Dec 2024 10:20:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850068.1264623; Fri, 06 Dec 2024 10: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 1tJVSF-0003EC-2Y; Fri, 06 Dec 2024 10:20:59 +0000 Received: by outflank-mailman (input) for mailman id 850068; Fri, 06 Dec 2024 10:20: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 1tJVPo-0001om-DT for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:28 +0000 Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6cb0849b-b3bb-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 11:18:25 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.163.17]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4Y4Rwz4YPxz1kvQ9; Fri, 6 Dec 2024 18:16:03 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id CA77B1A0188; Fri, 6 Dec 2024 18:18:22 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:21 +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: 6cb0849b-b3bb-11ef-99a3-01e77a169b0f From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 13/22] arm64/ptrace: Refactor syscall_trace_enter() Date: Fri, 6 Dec 2024 18:17:35 +0800 Message-ID: <20241206101744.4161990-14-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) The generic entry syscall_trace_enter() use the input syscall work flag and syscall number. In preparation for moving arm64 over to the generic entry code, refactor syscall_trace_enter() to also pass syscall number and thread flags, by using syscall_get_nr() helper. No functional changes. Signed-off-by: Jinjie Ruan --- arch/arm64/include/asm/syscall.h | 2 +- arch/arm64/kernel/ptrace.c | 20 ++++++++++++++------ arch/arm64/kernel/syscall.c | 2 +- 3 files changed, 16 insertions(+), 8 deletions(-) diff --git a/arch/arm64/include/asm/syscall.h b/arch/arm64/include/asm/syscall.h index ab8e14b96f68..6b71d335c224 100644 --- a/arch/arm64/include/asm/syscall.h +++ b/arch/arm64/include/asm/syscall.h @@ -85,7 +85,7 @@ static inline int syscall_get_arch(struct task_struct *task) return AUDIT_ARCH_AARCH64; } -int syscall_trace_enter(struct pt_regs *regs); +int syscall_trace_enter(struct pt_regs *regs, long syscall, unsigned long flags); void syscall_trace_exit(struct pt_regs *regs); #endif /* __ASM_SYSCALL_H */ diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c index d0d801a4094a..48bb813e0ef6 100644 --- a/arch/arm64/kernel/ptrace.c +++ b/arch/arm64/kernel/ptrace.c @@ -2353,10 +2353,8 @@ static void report_syscall_exit(struct pt_regs *regs) } } -int syscall_trace_enter(struct pt_regs *regs) +int syscall_trace_enter(struct pt_regs *regs, long syscall, unsigned long flags) { - unsigned long flags = read_thread_flags(); - if (flags & (_TIF_SYSCALL_EMU | _TIF_SYSCALL_TRACE)) { report_syscall_enter(regs); if (flags & _TIF_SYSCALL_EMU) @@ -2367,10 +2365,20 @@ int syscall_trace_enter(struct pt_regs *regs) if (secure_computing() == -1) return NO_SYSCALL; - if (test_thread_flag(TIF_SYSCALL_TRACEPOINT)) - trace_sys_enter(regs, regs->syscallno); + /* Either of the above might have changed the syscall number */ + syscall = syscall_get_nr(current, regs); + + if (test_thread_flag(TIF_SYSCALL_TRACEPOINT)) { + trace_sys_enter(regs, syscall); + + /* + * Probes or BPF hooks in the tracepoint may have changed the + * system call number as well. + */ + syscall = syscall_get_nr(current, regs); + } - audit_syscall_entry(regs->syscallno, regs->orig_x0, regs->regs[1], + audit_syscall_entry(syscall, regs->orig_x0, regs->regs[1], regs->regs[2], regs->regs[3]); return regs->syscallno; diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c index c442fcec6b9e..eb328ee1423c 100644 --- a/arch/arm64/kernel/syscall.c +++ b/arch/arm64/kernel/syscall.c @@ -124,7 +124,7 @@ static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr, */ if (scno == NO_SYSCALL) syscall_set_return_value(current, regs, -ENOSYS, 0); - scno = syscall_trace_enter(regs); + scno = syscall_trace_enter(regs, regs->syscallno, flags); if (scno == NO_SYSCALL) goto trace_exit; } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:21:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:21:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850078.1264641 (Exim 4.92) (envelope-from ) id 1tJVSK-0003yv-GL; Fri, 06 Dec 2024 10:21:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850078.1264641; Fri, 06 Dec 2024 10:21: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 1tJVSK-0003yj-Co; Fri, 06 Dec 2024 10:21:04 +0000 Received: by outflank-mailman (input) for mailman id 850078; Fri, 06 Dec 2024 10:21: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 1tJVPw-0001om-WF for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:37 +0000 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 727f161c-b3bb-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 11:18:35 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.163.252]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4Y4RwP2rcJz1V5h9; Fri, 6 Dec 2024 18:15:33 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id 728BD1800D9; Fri, 6 Dec 2024 18:18:32 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18:31 +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: 727f161c-b3bb-11ef-99a3-01e77a169b0f From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 21/22] entry: Add has_syscall_work() helepr Date: Fri, 6 Dec 2024 18:17:43 +0800 Message-ID: <20241206101744.4161990-22-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) Add has_syscall_work() heleper and use it in entry.h. The benefits of doing so lie in the fact that it can be used in the architecture code that uses generic entry. No functional changes. Signed-off-by: Jinjie Ruan --- include/linux/entry-common.h | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/include/linux/entry-common.h b/include/linux/entry-common.h index d11bdb4679b3..3bb5d7d839f4 100644 --- a/include/linux/entry-common.h +++ b/include/linux/entry-common.h @@ -43,6 +43,11 @@ SYSCALL_WORK_SYSCALL_EXIT_TRAP | \ ARCH_SYSCALL_WORK_EXIT) +static inline bool has_syscall_work(unsigned long work) +{ + return unlikely(work & SYSCALL_WORK_ENTER); +} + /** * syscall_enter_from_user_mode_prepare - Establish state and enable interrupts * @regs: Pointer to currents pt_regs @@ -90,7 +95,7 @@ static __always_inline long syscall_enter_from_user_mode_work(struct pt_regs *re { unsigned long work = READ_ONCE(current_thread_info()->syscall_work); - if (work & SYSCALL_WORK_ENTER) + if (has_syscall_work(work)) syscall = syscall_trace_enter(regs, syscall, work); return syscall; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:21:10 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:21:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850089.1264651 (Exim 4.92) (envelope-from ) id 1tJVSP-0004gq-Rs; Fri, 06 Dec 2024 10:21:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850089.1264651; Fri, 06 Dec 2024 10:21: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 1tJVSP-0004gd-ON; Fri, 06 Dec 2024 10:21:09 +0000 Received: by outflank-mailman (input) for mailman id 850089; Fri, 06 Dec 2024 10:21: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 1tJVPp-0001om-Ha for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:29 +0000 Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6da524d8-b3bb-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 11:18:27 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.163.17]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4Y4Rx06GcKz1kvVt; Fri, 6 Dec 2024 18:16:04 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id 118A51A0188; Fri, 6 Dec 2024 18:18:24 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18: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: 6da524d8-b3bb-11ef-99a3-01e77a169b0f From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 14/22] arm64/ptrace: Refactor syscall_trace_exit() Date: Fri, 6 Dec 2024 18:17:36 +0800 Message-ID: <20241206101744.4161990-15-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) The generic entry syscall_exit_work() use the input syscall work flag. In preparation for moving arm64 over to the generic entry code, refactor syscall_trace_exit() to also pass thread flags. No functional changes. Signed-off-by: Jinjie Ruan --- arch/arm64/include/asm/syscall.h | 2 +- arch/arm64/kernel/ptrace.c | 4 +--- arch/arm64/kernel/syscall.c | 3 ++- 3 files changed, 4 insertions(+), 5 deletions(-) diff --git a/arch/arm64/include/asm/syscall.h b/arch/arm64/include/asm/syscall.h index 6b71d335c224..925a257145f9 100644 --- a/arch/arm64/include/asm/syscall.h +++ b/arch/arm64/include/asm/syscall.h @@ -86,6 +86,6 @@ static inline int syscall_get_arch(struct task_struct *task) } int syscall_trace_enter(struct pt_regs *regs, long syscall, unsigned long flags); -void syscall_trace_exit(struct pt_regs *regs); +void syscall_trace_exit(struct pt_regs *regs, unsigned long flags); #endif /* __ASM_SYSCALL_H */ diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c index 48bb813e0ef6..bb994d668d74 100644 --- a/arch/arm64/kernel/ptrace.c +++ b/arch/arm64/kernel/ptrace.c @@ -2384,10 +2384,8 @@ int syscall_trace_enter(struct pt_regs *regs, long syscall, unsigned long flags) return regs->syscallno; } -void syscall_trace_exit(struct pt_regs *regs) +void syscall_trace_exit(struct pt_regs *regs, unsigned long flags) { - unsigned long flags = read_thread_flags(); - audit_syscall_exit(regs); if (flags & _TIF_SYSCALL_TRACEPOINT) diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c index eb328ee1423c..064dc114fb9b 100644 --- a/arch/arm64/kernel/syscall.c +++ b/arch/arm64/kernel/syscall.c @@ -143,7 +143,8 @@ static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr, } trace_exit: - syscall_trace_exit(regs); + flags = read_thread_flags(); + syscall_trace_exit(regs, flags); } void do_el0_svc(struct pt_regs *regs) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:21:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:21:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850124.1264661 (Exim 4.92) (envelope-from ) id 1tJVSY-0005kO-BG; Fri, 06 Dec 2024 10:21:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850124.1264661; Fri, 06 Dec 2024 10:21: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 1tJVSY-0005kC-7q; Fri, 06 Dec 2024 10:21:18 +0000 Received: by outflank-mailman (input) for mailman id 850124; Fri, 06 Dec 2024 10:21: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 1tJVQ0-0001of-Ey for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:18:40 +0000 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 702a6f21-b3bb-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 11:18:31 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.88.214]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4Y4Rx42B1tz2DhBL; Fri, 6 Dec 2024 18:16:08 +0800 (CST) Received: from kwepemg200008.china.huawei.com (unknown [7.202.181.35]) by mail.maildlp.com (Postfix) with ESMTPS id A739C1A016C; Fri, 6 Dec 2024 18:18:27 +0800 (CST) Received: from huawei.com (10.90.53.73) by kwepemg200008.china.huawei.com (7.202.181.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Dec 2024 18:18: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: 702a6f21-b3bb-11ef-a0d5-8be0dac302b0 From: Jinjie Ruan To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next v5 17/22] arm64/ptrace: Return early for ptrace_report_syscall_entry() error Date: Fri, 6 Dec 2024 18:17:39 +0800 Message-ID: <20241206101744.4161990-18-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241206101744.4161990-1-ruanjinjie@huawei.com> References: <20241206101744.4161990-1-ruanjinjie@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.90.53.73] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemg200008.china.huawei.com (7.202.181.35) As the comment said, the calling arch code should abort the system call and must prevent normal entry so no system call is made if ptrace_report_syscall_entry() return nonzero. As the generic entry check error for ptrace_report_syscall_entry(), in preparation for moving arm64 over to the generic entry code, also return early if it returns error. Signed-off-by: Jinjie Ruan --- arch/arm64/kernel/ptrace.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c index 23df2e558fe9..b53d3759baf8 100644 --- a/arch/arm64/kernel/ptrace.c +++ b/arch/arm64/kernel/ptrace.c @@ -2298,10 +2298,10 @@ enum ptrace_syscall_dir { PTRACE_SYSCALL_EXIT, }; -static void report_syscall_enter(struct pt_regs *regs) +static int report_syscall_enter(struct pt_regs *regs) { - int regno; unsigned long saved_reg; + int regno, ret; /* * We have some ABI weirdness here in the way that we handle syscall @@ -2323,9 +2323,13 @@ static void report_syscall_enter(struct pt_regs *regs) saved_reg = regs->regs[regno]; regs->regs[regno] = PTRACE_SYSCALL_ENTER; - if (ptrace_report_syscall_entry(regs)) + ret = ptrace_report_syscall_entry(regs); + if (ret) forget_syscall(regs); + regs->regs[regno] = saved_reg; + + return ret; } static void report_syscall_exit(struct pt_regs *regs) @@ -2355,9 +2359,11 @@ static void report_syscall_exit(struct pt_regs *regs) int syscall_trace_enter(struct pt_regs *regs, long syscall, unsigned long flags) { + int ret; + if (flags & (_TIF_SYSCALL_EMU | _TIF_SYSCALL_TRACE)) { - report_syscall_enter(regs); - if (flags & _TIF_SYSCALL_EMU) + ret = report_syscall_enter(regs); + if (ret || (flags & _TIF_SYSCALL_EMU)) return NO_SYSCALL; } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 10:48:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 10:48:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850214.1264670 (Exim 4.92) (envelope-from ) id 1tJVsO-0001nW-C8; Fri, 06 Dec 2024 10:48:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850214.1264670; Fri, 06 Dec 2024 10:48: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 1tJVsO-0001nP-9N; Fri, 06 Dec 2024 10:48:00 +0000 Received: by outflank-mailman (input) for mailman id 850214; Fri, 06 Dec 2024 10:47:59 +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 1tJVsM-0001nJ-WE for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 10:47:59 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on20628.outbound.protection.outlook.com [2a01:111:f403:2612::628]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8cfdb9bd-b3bf-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 11:47:56 +0100 (CET) Received: from DB9PR06CA0018.eurprd06.prod.outlook.com (2603:10a6:10:1db::23) by DBAPR08MB5592.eurprd08.prod.outlook.com (2603:10a6:10:1a8::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.12; Fri, 6 Dec 2024 10:47:49 +0000 Received: from DB3PEPF0000885B.eurprd02.prod.outlook.com (2603:10a6:10:1db:cafe::94) by DB9PR06CA0018.outlook.office365.com (2603:10a6:10:1db::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.11 via Frontend Transport; Fri, 6 Dec 2024 10:47:49 +0000 Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB3PEPF0000885B.mail.protection.outlook.com (10.167.242.6) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.7 via Frontend Transport; Fri, 6 Dec 2024 10:47:48 +0000 Received: ("Tessian outbound 6f08927dda96:v522"); Fri, 06 Dec 2024 10:47:48 +0000 Received: from Lca6abbf1f4eb.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id E006B807-D365-4DB6-8566-C9841BBC6AF2.1; Fri, 06 Dec 2024 10:47:42 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id Lca6abbf1f4eb.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 06 Dec 2024 10:47:42 +0000 Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24) by AS8PR08MB9292.eurprd08.prod.outlook.com (2603:10a6:20b:5a7::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.24; Fri, 6 Dec 2024 10:47:40 +0000 Received: from DB9PR08MB6588.eurprd08.prod.outlook.com ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8230.008; Fri, 6 Dec 2024 10:47: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: 8cfdb9bd-b3bf-11ef-99a3-01e77a169b0f ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=W7C+KNAMpZf2Dr0XU110b42uIMRxjidJpBXimwzZvlR35JQYgeK6AdHweQpVyRwstVqOV94jk54HEoh9M6zytO0aqdgRy0XAOZ0jKNq/tIjYSjDNM4f1QcF+P9G7VbmDXUIQlgzBMB16KkCvmDyrduB2FeGMWrBGvYQ6kbugJVdRIVd4sT6xZKD2YXLIW44fmj6Iwmc1+WKfkfsS+s+VKjkiaJO5B/pDp6emfh3hZWuiA+5OYbSYZ840d2N5HZ/izim5OsBlRA15pRjZFo2/5v2+w5r0pZMgTn7W8rlR8fzjpOUzx64fiiaBBUm/oYtmHfH2PyxopDx63XD1S3nlaw== 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=njios90dD7U0Q7dHlrhFvVFJSm4cXzISUZO+54rGHao=; b=gpAI8//+1Ndp285el6nkWjkNlTILRmpcO5al8KzJDTxb3/ow2z2gRkcSqkSJ4patgHXua+BmUvj4gle9tDJzBTVDjkiQj+9TvixO6fSrsEoxl21CKLT6UjX0l8WpcBL2uFWYqT3KmnVLlKvz/Z7T7QmhGOi+kAdg5xok7EpyVxscyyNSd764VdsjPXl581tmmQFuCH1qizKNdmhkYCAiWVXTFBAnGGPsMA/GCWygHE7AVkWbQgu8XBTeRjrSqTZg3aS+oTUI3qJfCidVDEfIX6tBc7AtAtlvwecWRSarB37MGwhXhH6AKeV7Ua56Sk0KAn5SQbQED/8gxtNrXCYbcQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=njios90dD7U0Q7dHlrhFvVFJSm4cXzISUZO+54rGHao=; b=qJiUwe9D2zMRtteYjbollWlSLnb1LoQt9voPh1hI0mYhRtX9mNXf0Fw8O6Un3XPHdvwA2WSk/6cWmVVNcnvnKzGP8Ox1mZa8oLL02MyB60p81r7uwOJcBZVf/9qeFACVf3b1hAg1hNlDJLIv4OLCHwUSWVeEc6ZV/EsozruCneI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) 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 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C X-CheckRecipientChecked: true X-CR-MTA-CID: 46fa36d804209ce4 X-TessianGatewayMetadata: 8Cz/NPgt/4SKLMqypk1re3ebrk/sa09DFZ5WttLqkyFiceE/yXxOrx/3wECuKWqfLAGmmZSHSxsAP+X5cXZ4w5uMSFKmy6wESHFr8JFygNcvsUaXRzv+lpyGYOByDHhbp4dr0Jau6qKRKKNezcGWiLxr16UW9ZjnzdKHUF8Qdwo= X-CR-MTA-TID: 64aa7808 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nwM1O8aULD5R+rUKkOgM3CDltZP97gkzQURrAxQVRq3/yx9x2y8ydcW5uqJiyNrCtvn6/YGrRAFQjt1w8TCkp+/naH+RWcPRQDX4frcInAl7aDJYi9+5x3nkSsGi5QlBiNKJ8gUwYOT4pK+QFzKkpNEBtuwMWXhoNQIdO0bSYNfVIeRv1PbeK07mT8Vrl60UQ3KMcSnkdgEWfGkqiEVEAAqCP5qQWH+f5T65w6Kh9xi9dYZXbKtJ7WsGQcLSmHca67pgdA9tfh1mpNwwEfcjV2UwJh615gp/SbwM0dzls7k0GrZeGIBtYha32TCp4a04qQT6UTJlXvEK3BDWkbI8tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=njios90dD7U0Q7dHlrhFvVFJSm4cXzISUZO+54rGHao=; b=GNjalRytH5qKCmqDZb2lyNDRsDdH05YyXkyTWn8XJIihv0EMKpwB4C/z6b/2VMYDkq3C+/B0+eY9MRwHbOmR0+xOYtqK+3KfKI36Ox3tYMIVzHZGedPvdy5a1QhC1wml8zDd6f4oS0IzYakfACPIXzoY7vqNTVMjtxGAdH/tsZiheR1zP/MsvD7Z9sNXbk2IIDMX5U+lfpk4ByTu4zZsGHldpXhBAEZWLVcEK2oHeN5qdd3VzNg1i+jUxV6ZuPc+RsNZrYF9I4+s3T1sCV2XYr1CFgsh1YEnIsW1nwGoiHRIiSNt8DNp2gMB6Z+J8Igj2hPUyeE2Lr9uOespWgf3iQ== 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=njios90dD7U0Q7dHlrhFvVFJSm4cXzISUZO+54rGHao=; b=qJiUwe9D2zMRtteYjbollWlSLnb1LoQt9voPh1hI0mYhRtX9mNXf0Fw8O6Un3XPHdvwA2WSk/6cWmVVNcnvnKzGP8Ox1mZa8oLL02MyB60p81r7uwOJcBZVf/9qeFACVf3b1hAg1hNlDJLIv4OLCHwUSWVeEc6ZV/EsozruCneI= From: Bertrand Marquis To: Jens Wiklander CC: "xen-devel@lists.xenproject.org" , Volodymyr Babchuk , Stefano Stabellini , Julien Grall , Michal Orzel Subject: Re: [PATCH v3 07/10] xen/arm: ffa: Transmit RXTX buffers to the SPMC Thread-Topic: [PATCH v3 07/10] xen/arm: ffa: Transmit RXTX buffers to the SPMC Thread-Index: AQHbQOaiujpt26xv7UijucaMZXJ1w7LY55WAgAAvG4A= Date: Fri, 6 Dec 2024 10:47:39 +0000 Message-ID: <8EA516E9-A660-436A-A64D-69DD04E9759E@arm.com> References: <56217f2f7b4c29a5f84fb02de3f4cbb8342c5560.1732702210.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.3826.200.121) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DB9PR08MB6588:EE_|AS8PR08MB9292:EE_|DB3PEPF0000885B:EE_|DBAPR08MB5592:EE_ X-MS-Office365-Filtering-Correlation-Id: 2bc8555e-5d96-43f8-42b2-08dd15e36cf7 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|38070700018; X-Microsoft-Antispam-Message-Info-Original: =?utf-8?B?ak0vcmdxZVE5T25hVW93ek1PUXVHREVZMS9ZMVAxOUh2RXdxRUQrV2JYOEVJ?= =?utf-8?B?NHJKTnBva25VcmhUNU1SM09rZEZWUDFuNGJNbzdZdnlXMzM5czA5QWtKYmhl?= =?utf-8?B?SG5JbmdGYld2NG1ETzBLZ0Q0WVNTU0tQMmt2cGRzanZNdkhEZkdWbFdQc3pD?= =?utf-8?B?eXNTK091WFJiSUVDeXBOOUFIQTRRVzVNOTRyR0dEOGE2TTF6Y3pqcjNOQXhy?= =?utf-8?B?ZXViejluM2lXRzMyRHQ0NkdGV21DY2RoR2t2dkFUcFBYQmZsZGR0Mk0rSUZJ?= =?utf-8?B?eFNId2dHTTR1Z1NLb0hIak9GNXFCc1JnUTlrTUhER3E2VmFyUkdxQzV1REtB?= =?utf-8?B?aStTN2NRMFRhRE9MM1VHcFNBZk1kTHdSUVNBTjlkM2l6R2ZBQXp0SHdaK2JF?= =?utf-8?B?VzRzOERiTng4QkRqSnpqV2tkVHBzQWZaNU1LeU9GNGdydCtOOUJXb3lSTWpx?= =?utf-8?B?Z3U5cXB4WGxydEwvQkF1OXc4TnhMTS9vWnRiYTIvbkJmTFdOUzk4YlQ3amdB?= =?utf-8?B?eUJxTFhWSnZZRDJIcUNwQ0doRDgzb2ZEY28yQzhnUkNNYm9NWnFrRTYyUG0v?= =?utf-8?B?clliLzZ1eE15SW1iaHFHUEwwN2xKRy9lazdBN3BRb05MU1VibnJ4SzdJVzFS?= =?utf-8?B?MnFzLzVRYWxlLzc5MnZUblJ4WHhGWUlEZW5obXo5WXdRN0l3ZTljTWYvWjJT?= =?utf-8?B?OTR4dFBkMmpmRm5JWXJNT1hVd1doVU5zRVQ4ZEY0Zng1R1R4c3JyeEExaGcy?= =?utf-8?B?NkRPUGNXZUtUK25lTVFZNWdObUxUa2FlZUJ2UUpWd0NUOVBmQkhtVVR2NUly?= =?utf-8?B?dlRLTUtXNEQzSjJiTWd0Q0lMVTNYMjNiZWlwWHM4dzNpekxqcmRjMXgxalNG?= =?utf-8?B?MExLaXhlQ2d2K2dUTEk5QTl5MzNHNjNuTG10QXkvN2dnd01vNFRyMTRJUit5?= =?utf-8?B?dTBvcDFCSFk2OUl0S2tDN2Zkb3Y5dDd6alVQdkVuc0ZtaFpIUklDajBRcXF4?= =?utf-8?B?eVY2NzlTVXc5U1RpNE9wYUJQYzdIY2h3M3pscUIwbzlMWkppb3ovUStUVGxn?= =?utf-8?B?aWV6ZWVGNGxzTWJldnF6RWg4UUZyZ1ZYanVpY1BoY3JXY2czNmRTMnFSNFEy?= =?utf-8?B?REVsMXVyOXYweFRwSDUwbnhEcm9mU3VsU3hhRnVsNVNlK2xaRHltUm5NZitO?= =?utf-8?B?bkRqeWhCNFFiajZ2bUoxUUlud09BNThUcU5vUUo2UmU4RmhQOVR2a2IyZSs3?= =?utf-8?B?VEtUYmlIZE1CYzV5UW1IbXNoRm4rc3NGdmZsUGZ3Vk9iVThiUGtSY1h2ejRG?= =?utf-8?B?M2dCTGM2dVpCWmIrNUlMUGV0L3Fxa3ZLQ3FEa1IvU2p0dlBtakRiS1N0eW5n?= =?utf-8?B?ZXk3QU1ZSEQrRDFwZExLb1BGS2RwNFNob1hTTTdyVldzQXJqc0NaY3YyWHZE?= =?utf-8?B?cjFHSnhucE9URUhIRDhxMjBTLzIvQ2xpbDNRN3cwUktDWng4djZWdHNjUVNY?= =?utf-8?B?ODVxK25QbDN2QTBDTG5iNWo4Yzh2dFpWbTJNWlh1b1AwNG9zREdJZUxaeGYy?= =?utf-8?B?T2RuYjY0b2UvcXNCS2pkdEZtekxMZXlmb1ovUGlhSk1mQ3ZnRm51VFowcVJI?= =?utf-8?B?cXk4ellyTVp6cWFKMXk3OXVLMlJaNDZzcGFsNjJ0ZkpjKzNyU2ROK1FPRjFR?= =?utf-8?B?TXpkTlVYUk1lV2ZCclRTRVhBenZkUHZKTUpGdXMrMEh6ZHhhczAwalEzMTE1?= =?utf-8?B?aks5bUhnMjRYQ2hlL283ZnVSMXN1WGxvbGxGbE5iZ3VycDVOQmt0VjFlQnhw?= =?utf-8?B?ZmhNdWJ3ZXF2cEhUYmZreTh1aERQbTZ0U1M4eWhSQXFmMjgrUHIzWTBhY2hT?= =?utf-8?B?Q2FvL1k4aDM1SXNsWllreUxJR1V5eVE4blVjcklvOFdUYmc9PQ==?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(10070799003)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="utf-8" Content-ID: <0FE5F6320AB975458EDF490D0F22CADD@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB9292 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-SkipListedInternetSender: ip=[2603:10a6:10:25a::24];domain=DB9PR08MB6588.eurprd08.prod.outlook.com X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB3PEPF0000885B.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 6d3908a5-a019-48c2-7da5-08dd15e367cf X-Microsoft-Antispam: BCL:0;ARA:13230040|35042699022|1800799024|36860700013|376014|82310400026|14060799003; X-Microsoft-Antispam-Message-Info: =?utf-8?B?aXdxMStGWEFHUFBPeVJRSjVUYkhBT2kxUG1HMmJFZ1l6VUZWL1ZiOVRVMUpi?= =?utf-8?B?QUNvaGdONVllMDdNTkxOcWpBeEwzcDIwemZEUXdEelJaT3V6eHRtenEwRVpt?= =?utf-8?B?VldwQjk1ZlFPOWtXMU0zVjJZdUZXamMyZ0c2alpLblZTenFTNkY3RUx1UFBn?= =?utf-8?B?dnNKdHBIVDBKdVJsay94ZmZhdE4rekt3TXlKOFQ1VjdPL010Z1lRODBhQ3Fs?= =?utf-8?B?RmpZbFpDVXJjZDZkN2RWcDRvd0hLckdWSlg4R01PUm5yRVJ1QTFlUmJsa3JB?= =?utf-8?B?TzZNMjZuRVdDS0dhcHJNTXFjVUxrUHJWNnVMaTh5TG9uMmZKRk5RbFdiZnlv?= =?utf-8?B?NmNxVjVrVTUraGo5UnZRMmpCYnFmbys5emJlWmxqREhnQ1poa3k5ck4zbDRE?= =?utf-8?B?SkE5SDNIZnFxUkkzSk56VUt6WmtaNWdNazZtdEVBbkZ5UVRIUGRmaTN0TGhs?= =?utf-8?B?T1F6MFNSTzFQMTZhU05Jc1ByNm5PTkJHSVRTa1F1MGhlYmV4Q3lja3UrR1ZU?= =?utf-8?B?NTFtOWxYQ2Q2WncvVWRvQ1hGTHRGMFNKZ3lkV3pmN0NJcGFWNG1RcmlHUGZY?= =?utf-8?B?Qk5OeDhCbjNwRWRxQm1nemQ0Qml2bG9JVmxZWmZzME1TSmZ6dCtCSzNveko3?= =?utf-8?B?elBsdmV3M1h4OTFWMCsySW5VcDZYeVpKSXdUdm1rbkE3STJkUzFwYXBVVC8r?= =?utf-8?B?Uk40MmVyOENhK3VtWkJYMFdJNEZVNzIrL1JvV3NxSmJicUlOK2srUk1MQndu?= =?utf-8?B?SEk5U3dKT3JFUmtad2ZUMm00cEVLNFkwVzNNV0paSHlubFdlWGZHcER0RXZj?= =?utf-8?B?a2xlR016VUczSU90MFR4QWplcW9xTzdFRmZSTjR0SzNyK1N2WkZ0NW9TbTJv?= =?utf-8?B?a1hLVFNyM3ZnVXRGMW14ZHNUUzh6VWVUMjNQaFFHcGgyRjBuU1hwWGxoSE1n?= =?utf-8?B?ZDdoTmwvTlMxQk81dHluSGEwbGFjODZ1TXFONWNRcHZkZlVPNDhkZVN0WnVE?= =?utf-8?B?OXlVUTNlaWNsRnhiRCtqUlRGSlBBSXR2Q09Gajh2bE1kRVRpWnh2bTA3SXB1?= =?utf-8?B?dVZreEE4YXlPQ2lUT0dmMkVreisrQ2hqcWJtVWJHQkJIZm9CbEwyY015REVO?= =?utf-8?B?VUQ5WXJmYTJsVXAyTjN5RzkxcWtubjZ0czdJNVdDTFp3Mk9DL0ZaNW1QV2R0?= =?utf-8?B?K294a3M1djlLNWE1ZjRMMmdUcmMwRm5jVzBkV2lISmtjSU5XSG4wdUJVbGZv?= =?utf-8?B?QXlOZWVjYVphK1NKMXZSczhuUjVYT2xvMENtRkdoRjNJMjF2Tk1zYm5LZnQ4?= =?utf-8?B?UkY5d1AzTDl6UGVEcHQ3WEdqTW85UUFpcXJBRU01NmlZUHl6d3VTOXFtUDcr?= =?utf-8?B?U2NXY2ZwQW4xbk9PWXhjaEJWeE5VVEx2TFVMRC9CUnJHSEpEdVRDa3U4Nk5N?= =?utf-8?B?cFZubzhYYm5sWXREekFJbzJ6V21PNkxRTTF1RWNaelJmUW11VzVHN3cvcysx?= =?utf-8?B?Ti9yZitUbmxtbVNzQ0JMODlZcGllWlE3WDdxQlBwUGprYkNLRzJ2MHEyZWM3?= =?utf-8?B?eWFPV2JQVE96eVNNVEVHdmZCVVZKL21DeFc5MlRyeGNyTVJQbTNHZnVtdTdt?= =?utf-8?B?Rm5Xc1ZiSnhpVlo0NlBGRDRvNEJSYnk2bnU0eVcvSnJFS0h3eXdRaHlHa0NL?= =?utf-8?B?dGtVeE13enJwSkkyVEpuWVdIZ1hkOCtnbnVxdGtoSXhLN2lHdkJFZ1FjRE14?= =?utf-8?B?ZVNvNFEyTktpNzBWWVNuTjhHSk9oeGFQRTd6UmFnL3ovOFRYZEV1N0Jodldx?= =?utf-8?B?S3Y2cWpoWjJ2clU2dkpjZXZsYUg3bUVpMkxWZm1iOVNCVHlLQWVWYUMxejZt?= =?utf-8?B?NjN5OExia0ZxQnRkYjdCRnpLUXhVVUo1NDNiUXVyRzhuY2pSQ3hHaHBpeGdt?= =?utf-8?B?ZU5lWHZUOVJJOEJYZ0NuTmowTFN2NDVVRFFwSnhOdzdJZTJKem4vRzVETkdI?= =?utf-8?B?OS9zSDh4OEdRPT0=?= X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(35042699022)(1800799024)(36860700013)(376014)(82310400026)(14060799003);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Dec 2024 10:47:48.5913 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2bc8555e-5d96-43f8-42b2-08dd15e36cf7 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB3PEPF0000885B.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR08MB5592 SGkgSmVucywNCg0KPiBPbiA2IERlYyAyMDI0LCBhdCAwODo1OCwgSmVucyBXaWtsYW5kZXIgPGpl bnMud2lrbGFuZGVyQGxpbmFyby5vcmc+IHdyb3RlOg0KPiANCj4gSGkgQmVydHJhbmQsDQo+IA0K PiBPbiBXZWQsIE5vdiAyNywgMjAyNCBhdCA1OjA44oCvUE0gQmVydHJhbmQgTWFycXVpcw0KPiA8 YmVydHJhbmQubWFycXVpc0Bhcm0uY29tPiB3cm90ZToNCj4+IA0KPj4gV2hlbiBhbiBSWFRYIGJ1 ZmZlciBpcyBtYXBwZWQgYnkgYSBWTSB0cmFuc21pdCBpdCB0byB0aGUgU1BNQyB3aGVuIGl0DQo+ PiBzdXBwb3J0cyBSWF9BQ1FVSVJFLg0KPj4gQXMgYSBjb25zZXF1ZW5jZSBvZiB0aGF0LCB3ZSBt dXN0IGFjcXVpcmUgdGhlIFJYIGJ1ZmZlciBvZiBhIFZNIGZyb20gdGhlDQo+PiBTUE1DIHdoZW4g d2Ugd2FudCB0byB1c2UgaXQ6DQo+PiAtIGNyZWF0ZSBhIGdlbmVyaWMgYWNxdWlyZSBhbmQgcmVs ZWFzZSBmdW5jdGlvbiB0byBnZXQgdGhlIHJ4IGJ1ZmZlciBvZg0KPj4gIGEgVk0gd2hpY2ggZ2V0 cyBpdCBmcm9tIHRoZSBTUE1DIHdoZW4gc3VwcG9ydGVkDQo+PiAtIHJlbmFtZSB0aGUgcnhfYWNx dWlyZSB0byBoeXBfcnhfYWNxdWlyZSB0byByZW1vdmUgY29uZnVzaW9uDQo+PiAtIHJld29yayB0 aGUgcnhfbG9jayB0byBvbmx5IGxvY2sgYWNjZXNzIHRvIHJ4X2lzX2ZyZWUgYW5kIG9ubHkgYWxs b3cNCj4+ICB1c2FnZSBvZiB0aGUgcnggYnVmZmVyIHRvIG9uZSB3aG8gbWFuYWdlZCB0byBhY3F1 aXJlIGl0LCB0aHVzIHJlbW92aW5nDQo+PiAgdGhlIHRyeWxvY2sgYW5kIHJldHVybmluZyBidXN5 IGlmIHJ4X2lzX2ZyZWUgaXMgZmFsc2UNCj4+IA0KPj4gQXMgcGFydCBvZiB0aGlzIGNoYW5nZSBt b3ZlIHNvbWUgc3RydWN0dXJlIGRlZmluaXRpb24gdG8gZmZhX3ByaXZhdGUNCj4+IGZyb20gZmZh X3NobSBhcyB0aG9zZSBhcmUgbmVlZCBmb3IgdGhlIE1BUCBjYWxsIHdpdGggdGhlIFNQTUMuDQo+ PiANCj4+IFdoaWxlIHRoZXJlIGFsc28gZml4IGZmYV9oYW5kbGVfcnh0eF9tYXAgd2hpY2ggd2Fz IHRlc3RpbmcgdGhlIHdyb25nDQo+PiB2YXJpYWJsZSBhZnRlciBnZXR0aW5nIHRoZSBwYWdlIGZv ciB0aGUgcnggYnVmZmVyLCB0ZXN0aW5nIHR4X3BnDQo+PiBpbnN0ZWFkIG9mIHJ4X3BnLg0KPj4g DQo+PiBGaXhlczogYmU3NWY2ODZlYjAzICgieGVuL2FybTogZmZhOiBzZXBhcmF0ZSByeHR4IGJ1 ZmZlciByb3V0aW5lcyIpDQo+PiANCj4+IFNpZ25lZC1vZmYtYnk6IEJlcnRyYW5kIE1hcnF1aXMg PGJlcnRyYW5kLm1hcnF1aXNAYXJtLmNvbT4NCj4+IC0tLQ0KPj4gQ2hhbmdlcyBpbiB2MzoNCj4+ IC0gYWRkIGEgY29tbWVudCB0byBleHBsYWluIHdoeSB3ZSBvbmx5IHJlbGVhc2UgdGhlIFJYIGJ1 ZmZlciBpZiBhbiBlcnJvcg0KPj4gIG9jY3VycyBkdXJpbmcgcGFydGl0aW9uX2luZm9fZ2V0DQo+ PiAtIGZpeCB0aGUgQlVJTERfQlVHX09OIGNoZWNrIGZvciBUWCBidWZmZXIgc2l6ZSBpbiByeHR4 X21hcCAoY29kaW5nDQo+PiAgc3R5bGUgYW5kIHVzZSBQQUdFX1NJWkUgKiBOVU1fUEFHRSkNCj4+ IC0gcmVtb3ZlIGludmFsaWQgMyBhcmd1bWVudCB0byBmZmFfcnh0eF9tYXAgd2hlbiBmb3J3YXJk aW5nIHRoZSBjYWxsIHRvDQo+PiAgdGhlIFNQTUMNCj4+IC0gZml4IGJ1ZyBpbiBmZmFfaGFuZGxl X3J4dHhfbWFwIHRlc3Rpbmcgd3JvbmcgdmFyaWFibGUNCj4+IENoYW5nZXMgaW4gdjI6DQo+PiAt IHVubWFwIFZNIHJ4dHggYnVmZmVyIGluIFNQTUMgb24gdW5tYXAgY2FsbCBvciBvbiBWTSBkZXN0 cm95DQo+PiAtIHJld29yayB0aGUgdW5tYXAgY2FsbCB0byB0aGUgU1BNQyB0byBwcm9wZXJseSBw YXNzIHRoZSBWTSBJRA0KPj4gLS0tDQo+PiB4ZW4vYXJjaC9hcm0vdGVlL2ZmYS5jICAgICAgICAg IHwgICAyICstDQo+PiB4ZW4vYXJjaC9hcm0vdGVlL2ZmYV9wYXJ0aW5mby5jIHwgIDM2ICsrKyst LS0NCj4+IHhlbi9hcmNoL2FybS90ZWUvZmZhX3ByaXZhdGUuaCAgfCAgMjIgKysrKy0NCj4+IHhl bi9hcmNoL2FybS90ZWUvZmZhX3J4dHguYyAgICAgfCAxNjEgKysrKysrKysrKysrKysrKysrKysr KysrKystLS0tLS0NCj4+IHhlbi9hcmNoL2FybS90ZWUvZmZhX3NobS5jICAgICAgfCAgMTUgLS0t DQo+PiA1IGZpbGVzIGNoYW5nZWQsIDE3MCBpbnNlcnRpb25zKCspLCA2NiBkZWxldGlvbnMoLSkN Cj4+IA0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS90ZWUvZmZhLmMgYi94ZW4vYXJjaC9h cm0vdGVlL2ZmYS5jDQo+PiBpbmRleCAwMDI2YWM5MTM0YWQuLmJjMjcyMmQ1M2ZkNyAxMDA2NDQN Cj4+IC0tLSBhL3hlbi9hcmNoL2FybS90ZWUvZmZhLmMNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS90 ZWUvZmZhLmMNCj4+IEBAIC0zNDcsNyArMzQ3LDcgQEAgc3RhdGljIGJvb2wgZmZhX2hhbmRsZV9j YWxsKHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KPj4gICAgICAgICBmZmFfaGFuZGxlX3Bh cnRpdGlvbl9pbmZvX2dldChyZWdzKTsNCj4+ICAgICAgICAgcmV0dXJuIHRydWU7DQo+PiAgICAg Y2FzZSBGRkFfUlhfUkVMRUFTRToNCj4+IC0gICAgICAgIGUgPSBmZmFfaGFuZGxlX3J4X3JlbGVh c2UoKTsNCj4+ICsgICAgICAgIGUgPSBmZmFfcnhfcmVsZWFzZShkKTsNCj4+ICAgICAgICAgYnJl YWs7DQo+PiAgICAgY2FzZSBGRkFfTVNHX1NFTkRfRElSRUNUX1JFUV8zMjoNCj4+ICAgICBjYXNl IEZGQV9NU0dfU0VORF9ESVJFQ1RfUkVRXzY0Og0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2Fy bS90ZWUvZmZhX3BhcnRpbmZvLmMgYi94ZW4vYXJjaC9hcm0vdGVlL2ZmYV9wYXJ0aW5mby5jDQo+ PiBpbmRleCA3NDMyNGUxZDlkM2YuLjkzOWVkNDlkZDNkYSAxMDA2NDQNCj4+IC0tLSBhL3hlbi9h cmNoL2FybS90ZWUvZmZhX3BhcnRpbmZvLmMNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS90ZWUvZmZh X3BhcnRpbmZvLmMNCj4+IEBAIC0xMjEsMTEgKzEyMSw5IEBAIHZvaWQgZmZhX2hhbmRsZV9wYXJ0 aXRpb25faW5mb19nZXQoc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpDQo+PiAgICAgICAgIGdv dG8gb3V0Ow0KPj4gICAgIH0NCj4+IA0KPj4gLSAgICBpZiAoICFzcGluX3RyeWxvY2soJmN0eC0+ cnhfbG9jaykgKQ0KPj4gLSAgICB7DQo+PiAtICAgICAgICByZXQgPSBGRkFfUkVUX0JVU1k7DQo+ PiArICAgIHJldCA9IGZmYV9yeF9hY3F1aXJlKGQpOw0KPj4gKyAgICBpZiAoIHJldCAhPSBGRkFf UkVUX09LICkNCj4+ICAgICAgICAgZ290byBvdXQ7DQo+PiAtICAgIH0NCj4+IA0KPj4gICAgIGRz dF9idWYgPSBjdHgtPnJ4Ow0KPj4gDQo+PiBAQCAtMTM1LDIyICsxMzMsMTYgQEAgdm9pZCBmZmFf aGFuZGxlX3BhcnRpdGlvbl9pbmZvX2dldChzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykNCj4+ ICAgICAgICAgZ290byBvdXRfcnhfcmVsZWFzZTsNCj4+ICAgICB9DQo+PiANCj4+IC0gICAgaWYg KCAhY3R4LT5wYWdlX2NvdW50IHx8ICFjdHgtPnJ4X2lzX2ZyZWUgKQ0KPj4gLSAgICB7DQo+PiAt ICAgICAgICByZXQgPSBGRkFfUkVUX0RFTklFRDsNCj4+IC0gICAgICAgIGdvdG8gb3V0X3J4X3Jl bGVhc2U7DQo+PiAtICAgIH0NCj4+IC0NCj4+ICAgICBzcGluX2xvY2soJmZmYV9yeF9idWZmZXJf bG9jayk7DQo+PiANCj4+ICAgICByZXQgPSBmZmFfcGFydGl0aW9uX2luZm9fZ2V0KHV1aWQsIDAs ICZmZmFfc3BfY291bnQsICZzcmNfc2l6ZSk7DQo+PiANCj4+ICAgICBpZiAoIHJldCApDQo+PiAt ICAgICAgICBnb3RvIG91dF9yeF9idWZfdW5sb2NrOw0KPj4gKyAgICAgICAgZ290byBvdXRfcnhf aHlwX3VubG9jazsNCj4+IA0KPj4gICAgIC8qDQo+PiAgICAgICogZmZhX3BhcnRpdGlvbl9pbmZv X2dldCgpIHN1Y2NlZWRlZCBzbyB3ZSBub3cgb3duIHRoZSBSWCBidWZmZXIgd2UNCj4+IC0gICAg ICogc2hhcmUgd2l0aCB0aGUgU1BNQy4gV2UgbXVzdCBnaXZlIGl0IGJhY2sgdXNpbmcgZmZhX3J4 X3JlbGVhc2UoKQ0KPj4gKyAgICAgKiBzaGFyZSB3aXRoIHRoZSBTUE1DLiBXZSBtdXN0IGdpdmUg aXQgYmFjayB1c2luZyBmZmFfaHlwX3J4X3JlbGVhc2UoKQ0KPj4gICAgICAqIG9uY2Ugd2UndmUg Y29waWVkIHRoZSBjb250ZW50Lg0KPj4gICAgICAqLw0KPj4gDQo+PiBAQCAtMTkwLDE1ICsxODIs MjAgQEAgdm9pZCBmZmFfaGFuZGxlX3BhcnRpdGlvbl9pbmZvX2dldChzdHJ1Y3QgY3B1X3VzZXJf cmVncyAqcmVncykNCj4+ICAgICAgICAgfQ0KPj4gICAgIH0NCj4+IA0KPj4gLSAgICBjdHgtPnJ4 X2lzX2ZyZWUgPSBmYWxzZTsNCj4+IC0NCj4+IG91dF9yeF9oeXBfcmVsZWFzZToNCj4+IC0gICAg ZmZhX3J4X3JlbGVhc2UoKTsNCj4+IC1vdXRfcnhfYnVmX3VubG9jazoNCj4+ICsgICAgZmZhX2h5 cF9yeF9yZWxlYXNlKCk7DQo+PiArb3V0X3J4X2h5cF91bmxvY2s6DQo+PiAgICAgc3Bpbl91bmxv Y2soJmZmYV9yeF9idWZmZXJfbG9jayk7DQo+PiBvdXRfcnhfcmVsZWFzZToNCj4+IC0gICAgc3Bp bl91bmxvY2soJmN0eC0+cnhfbG9jayk7DQo+PiAtDQo+PiArICAgIC8qDQo+PiArICAgICAqIFRo ZSBjYWxsaW5nIFZNIFJYIGJ1ZmZlciBvbmx5IGNvbnRhaW5zIGRhdGEgdG8gYmUgdXNlZCBieSB0 aGUgVk0gaWYgdGhlDQo+PiArICAgICAqIGNhbGwgd2FzIHN1Y2Nlc3NmdWxsLCBpbiB3aGljaCBj YXNlIHRoZSBWTSBoYXMgdG8gcmVsZWFzZSB0aGUgYnVmZmVyDQo+IA0KPiBzdWNjZXNzZnVsDQoN CkFjay4NCg0KPiANCj4+ICsgICAgICogb25jZSBpdCBoYXMgdXNlZCB0aGUgZGF0YS4NCj4+ICsg ICAgICogSWYgc29tZXRoaW5nIHdlbnQgd3JvbmcgZHVyaW5nIHRoZSBjYWxsLCB3ZSBoYXZlIHRv IHJlbGVhc2UgdGhlIFJYDQo+PiArICAgICAqIGJ1ZmZlciBiYWNrIHRvIHRoZSBTUE1DIGFzIHRo ZSBWTSB3aWxsIG5vdCBkbyBpdC4NCj4+ICsgICAgICovDQo+PiArICAgIGlmICggcmV0ICE9IEZG QV9SRVRfT0sgKQ0KPj4gKyAgICAgICAgZmZhX3J4X3JlbGVhc2UoZCk7DQo+PiBvdXQ6DQo+PiAg ICAgaWYgKCByZXQgKQ0KPj4gICAgICAgICBmZmFfc2V0X3JlZ3NfZXJyb3IocmVncywgcmV0KTsN Cj4+IEBAIC0zNjUsOCArMzYyLDcgQEAgYm9vbCBmZmFfcGFydGluZm9faW5pdCh2b2lkKQ0KPj4g ICAgIHJldCA9IGluaXRfc3Vic2NyaWJlcnMoY291bnQsIGZwaV9zaXplKTsNCj4+IA0KPj4gb3V0 Og0KPj4gLSAgICBmZmFfcnhfcmVsZWFzZSgpOw0KPj4gLQ0KPj4gKyAgICBmZmFfaHlwX3J4X3Jl bGVhc2UoKTsNCj4+ICAgICByZXR1cm4gcmV0Ow0KPj4gfQ0KPj4gDQo+PiBkaWZmIC0tZ2l0IGEv eGVuL2FyY2gvYXJtL3RlZS9mZmFfcHJpdmF0ZS5oIGIveGVuL2FyY2gvYXJtL3RlZS9mZmFfcHJp dmF0ZS5oDQo+PiBpbmRleCBhZmU2OWI0M2RiZWYuLjlhZGZlNjg3YzNjOSAxMDA2NDQNCj4+IC0t LSBhL3hlbi9hcmNoL2FybS90ZWUvZmZhX3ByaXZhdGUuaA0KPj4gKysrIGIveGVuL2FyY2gvYXJt L3RlZS9mZmFfcHJpdmF0ZS5oDQo+PiBAQCAtMjY1LDYgKzI2NSwyMSBAQA0KPj4gI2RlZmluZSBG RkFfQUJJX0JJVE5VTShpZCkgICAgKChGRkFfQUJJX0lEKGlkKSAtIEZGQV9BQklfTUlOKSA8PCAx IHwgXA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZGQV9BQklfQ09OVihpZCkp DQo+PiANCj4+ICsvKiBDb25zdGl0dWVudCBtZW1vcnkgcmVnaW9uIGRlc2NyaXB0b3IgKi8NCj4+ ICtzdHJ1Y3QgZmZhX2FkZHJlc3NfcmFuZ2Ugew0KPj4gKyAgICB1aW50NjRfdCBhZGRyZXNzOw0K Pj4gKyAgICB1aW50MzJfdCBwYWdlX2NvdW50Ow0KPj4gKyAgICB1aW50MzJfdCByZXNlcnZlZDsN Cj4+ICt9Ow0KPj4gKw0KPj4gKy8qIENvbXBvc2l0ZSBtZW1vcnkgcmVnaW9uIGRlc2NyaXB0b3Ig Ki8NCj4+ICtzdHJ1Y3QgZmZhX21lbV9yZWdpb24gew0KPj4gKyAgICB1aW50MzJfdCB0b3RhbF9w YWdlX2NvdW50Ow0KPj4gKyAgICB1aW50MzJfdCBhZGRyZXNzX3JhbmdlX2NvdW50Ow0KPj4gKyAg ICB1aW50NjRfdCByZXNlcnZlZDsNCj4+ICsgICAgc3RydWN0IGZmYV9hZGRyZXNzX3JhbmdlIGFk ZHJlc3NfcmFuZ2VfYXJyYXlbXTsNCj4+ICt9Ow0KPj4gKw0KPj4gc3RydWN0IGZmYV9jdHhfbm90 aWYgew0KPj4gICAgIGJvb2wgZW5hYmxlZDsNCj4+IA0KPj4gQEAgLTI5Miw3ICszMDcsNyBAQCBz dHJ1Y3QgZmZhX2N0eCB7DQo+PiAgICAgc3RydWN0IGZmYV9jdHhfbm90aWYgbm90aWY7DQo+PiAg ICAgLyoNCj4+ICAgICAgKiB0eF9sb2NrIGlzIHVzZWQgdG8gc2VyaWFsaXplIGFjY2VzcyB0byB0 eA0KPj4gLSAgICAgKiByeF9sb2NrIGlzIHVzZWQgdG8gc2VyaWFsaXplIGFjY2VzcyB0byByeA0K Pj4gKyAgICAgKiByeF9sb2NrIGlzIHVzZWQgdG8gc2VyaWFsaXplIGFjY2VzcyB0byByeF9pc19m cmVlDQo+PiAgICAgICogbG9jayBpcyB1c2VkIGZvciB0aGUgcmVzdCBpbiB0aGlzIHN0cnVjdA0K Pj4gICAgICAqLw0KPj4gICAgIHNwaW5sb2NrX3QgdHhfbG9jazsNCj4+IEBAIC0zMzEsNyArMzQ2 LDggQEAgdm9pZCBmZmFfcnh0eF9kb21haW5fZGVzdHJveShzdHJ1Y3QgZG9tYWluICpkKTsNCj4+ IHVpbnQzMl90IGZmYV9oYW5kbGVfcnh0eF9tYXAodWludDMyX3QgZmlkLCByZWdpc3Rlcl90IHR4 X2FkZHIsDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVnaXN0ZXJfdCByeF9hZGRy LCB1aW50MzJfdCBwYWdlX2NvdW50KTsNCj4+IHVpbnQzMl90IGZmYV9oYW5kbGVfcnh0eF91bm1h cCh2b2lkKTsNCj4+IC1pbnQzMl90IGZmYV9oYW5kbGVfcnhfcmVsZWFzZSh2b2lkKTsNCj4+ICtp bnQzMl90IGZmYV9yeF9hY3F1aXJlKHN0cnVjdCBkb21haW4gKmQpOw0KPj4gK2ludDMyX3QgZmZh X3J4X3JlbGVhc2Uoc3RydWN0IGRvbWFpbiAqZCk7DQo+PiANCj4+IHZvaWQgZmZhX25vdGlmX2lu aXQodm9pZCk7DQo+PiB2b2lkIGZmYV9ub3RpZl9pbml0X2ludGVycnVwdCh2b2lkKTsNCj4+IEBA IC00MjAsNyArNDM2LDcgQEAgc3RhdGljIGlubGluZSBpbnQzMl90IGZmYV9zaW1wbGVfY2FsbCh1 aW50MzJfdCBmaWQsIHJlZ2lzdGVyX3QgYTEsDQo+PiAgICAgcmV0dXJuIGZmYV9nZXRfcmV0X2Nv ZGUoJnJlc3ApOw0KPj4gfQ0KPj4gDQo+PiAtc3RhdGljIGlubGluZSBpbnQzMl90IGZmYV9yeF9y ZWxlYXNlKHZvaWQpDQo+PiArc3RhdGljIGlubGluZSBpbnQzMl90IGZmYV9oeXBfcnhfcmVsZWFz ZSh2b2lkKQ0KPj4gew0KPj4gICAgIHJldHVybiBmZmFfc2ltcGxlX2NhbGwoRkZBX1JYX1JFTEVB U0UsIDAsIDAsIDAsIDApOw0KPj4gfQ0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS90ZWUv ZmZhX3J4dHguYyBiL3hlbi9hcmNoL2FybS90ZWUvZmZhX3J4dHguYw0KPj4gaW5kZXggMTMyYTc5 ODI0MDdiLi5lMWNhYjdmYTVlNDYgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vdGVlL2Zm YV9yeHR4LmMNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS90ZWUvZmZhX3J4dHguYw0KPj4gQEAgLTMw LDYgKzMwLDE3IEBAIHN0cnVjdCBmZmFfZW5kcG9pbnRfcnh0eF9kZXNjcmlwdG9yXzFfMSB7DQo+ PiAgICAgdWludDMyX3QgdHhfcmVnaW9uX29mZnM7DQo+PiB9Ow0KPj4gDQo+PiArc3RhdGljIGlu dDMyX3QgZmZhX3J4dHhfbWFwKHBhZGRyX3QgdHhfYWRkciwgcGFkZHJfdCByeF9hZGRyLA0KPj4g KyAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBwYWdlX2NvdW50KQ0KPj4gK3sN Cj4+ICsgICAgcmV0dXJuIGZmYV9zaW1wbGVfY2FsbChGRkFfUlhUWF9NQVBfNjQsIHR4X2FkZHIs IHJ4X2FkZHIsIHBhZ2VfY291bnQsIDApOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW50MzJf dCBmZmFfcnh0eF91bm1hcCh1aW50MTZfdCBpZCkNCj4+ICt7DQo+PiArICAgIHJldHVybiBmZmFf c2ltcGxlX2NhbGwoRkZBX1JYVFhfVU5NQVAsICgodWludDY0X3QpaWQpPDwxNiwgMCwgMCwgMCk7 DQo+IA0KPiBQbGVhc2UgYWRkIGEgc3BhY2UgYmVmb3JlIGFuZCBhZnRlciB0aGUgIjw8IiBvcGVy YXRvci4NCg0KU3VyZS4NCg0KV2l0aCB0aG9zZSAyIGZpeGVzIGNhbiBJIGFkZCB5b3UgUi1iIGlu IHRoZSBuZXh0IHBhdGNoIHZlcnNpb24gPw0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXdzLg0KDQpD aGVlcnMNCkJlcnRyYW5kDQoNCj4gDQo+IENoZWVycywNCj4gSmVucw0KPiANCj4+ICt9DQo+PiAr DQo+PiB1aW50MzJfdCBmZmFfaGFuZGxlX3J4dHhfbWFwKHVpbnQzMl90IGZpZCwgcmVnaXN0ZXJf dCB0eF9hZGRyLA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlZ2lzdGVyX3Qgcnhf YWRkciwgdWludDMyX3QgcGFnZV9jb3VudCkNCj4+IHsNCj4+IEBAIC00Miw2ICs1Myw5IEBAIHVp bnQzMl90IGZmYV9oYW5kbGVfcnh0eF9tYXAodWludDMyX3QgZmlkLCByZWdpc3Rlcl90IHR4X2Fk ZHIsDQo+PiAgICAgdm9pZCAqcng7DQo+PiAgICAgdm9pZCAqdHg7DQo+PiANCj4+ICsgICAgLyog VGhlIGNvZGUgaXMgY29uc2lkZXJpbmcgdGhhdCB3ZSBvbmx5IGdldCBvbmUgcGFnZSBmb3Igbm93 ICovDQo+PiArICAgIEJVSUxEX0JVR19PTihGRkFfTUFYX1JYVFhfUEFHRV9DT1VOVCAhPSAxKTsN Cj4+ICsNCj4+ICAgICBpZiAoICFzbWNjY19pc19jb252XzY0KGZpZCkgKQ0KPj4gICAgIHsNCj4+ ICAgICAgICAgLyoNCj4+IEBAIC03Miw3ICs4Niw3IEBAIHVpbnQzMl90IGZmYV9oYW5kbGVfcnh0 eF9tYXAodWludDMyX3QgZmlkLCByZWdpc3Rlcl90IHR4X2FkZHIsDQo+PiAgICAgICAgIGdvdG8g ZXJyX3B1dF90eF9wZzsNCj4+IA0KPj4gICAgIHJ4X3BnID0gZ2V0X3BhZ2VfZnJvbV9nZm4oZCwg Z2ZuX3goZ2FkZHJfdG9fZ2ZuKHJ4X2FkZHIpKSwgJnQsIFAyTV9BTExPQyk7DQo+PiAtICAgIGlm ICggIXR4X3BnICkNCj4+ICsgICAgaWYgKCAhcnhfcGcgKQ0KPj4gICAgICAgICBnb3RvIGVycl9w dXRfdHhfcGc7DQo+PiANCj4+ICAgICAvKiBPbmx5IG5vcm1hbCBSVyBSQU0gZm9yIG5vdyAqLw0K Pj4gQEAgLTg3LDYgKzEwMSw2NiBAQCB1aW50MzJfdCBmZmFfaGFuZGxlX3J4dHhfbWFwKHVpbnQz Ml90IGZpZCwgcmVnaXN0ZXJfdCB0eF9hZGRyLA0KPj4gICAgIGlmICggIXJ4ICkNCj4+ICAgICAg ICAgZ290byBlcnJfdW5tYXBfdHg7DQo+PiANCj4+ICsgICAgLyoNCj4+ICsgICAgICogVHJhbnNt aXQgdGhlIFJYL1RYIGJ1ZmZlciBpbmZvcm1hdGlvbiB0byB0aGUgU1BNIGlmIGFjcXVpcmUgaXMg c3VwcG9ydGVkDQo+PiArICAgICAqIGFzIHRoZSBzcGVjIHNheXMgdGhhdCBpZiBub3QgdGhlcmUg aXMgbm90IG5lZWQgdG8gYWNxdWlyZS9yZWxlYXNlL21hcA0KPj4gKyAgICAgKiByeHR4IGJ1ZmZl cnMgZnJvbSB0aGUgU1BNQw0KPj4gKyAgICAgKi8NCj4+ICsgICAgaWYgKCBmZmFfZndfc3VwcG9y dHNfZmlkKEZGQV9SWF9BQ1FVSVJFKSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHN0cnVjdCBm ZmFfZW5kcG9pbnRfcnh0eF9kZXNjcmlwdG9yXzFfMSAqcnh0eF9kZXNjOw0KPj4gKyAgICAgICAg c3RydWN0IGZmYV9tZW1fcmVnaW9uICptZW1fcmVnOw0KPj4gKw0KPj4gKyAgICAgICAgLyogQWxs IG11c3QgZml0IGluIG91ciBUWCBidWZmZXIgKi8NCj4+ICsgICAgICAgIEJVSUxEX0JVR19PTihz aXplb2YoKnJ4dHhfZGVzYykgKyBzaXplb2YoKm1lbV9yZWcpICogMiArDQo+PiArICAgICAgICAg ICAgICAgICAgICAgc2l6ZW9mKHN0cnVjdCBmZmFfYWRkcmVzc19yYW5nZSkgKiAyID4NCj4+ICsg ICAgICAgICAgICAgICAgICAgICBGRkFfTUFYX1JYVFhfUEFHRV9DT1VOVCAqIEZGQV9QQUdFX1NJ WkUpOw0KPj4gKw0KPj4gKyAgICAgICAgc3Bpbl9sb2NrKCZmZmFfdHhfYnVmZmVyX2xvY2spOw0K Pj4gKyAgICAgICAgcnh0eF9kZXNjID0gZmZhX3R4Ow0KPj4gKw0KPj4gKyAgICAgICAgLyoNCj4+ ICsgICAgICAgICAqIFdlIGhhdmUgb25seSBvbmUgcGFnZSBmb3IgZWFjaCBzbyB3ZSBwYWNrIGV2 ZXJ5dGhpbmc6DQo+PiArICAgICAgICAgKiAtIHJ4IHJlZ2lvbiBkZXNjcmlwdG9yDQo+PiArICAg ICAgICAgKiAtIHJ4IHJlZ2lvbiByYW5nZQ0KPj4gKyAgICAgICAgICogLSB0eCByZWdpb24gZGVz Y3JpcHRvcg0KPj4gKyAgICAgICAgICogLSB0eCByZWdpb24gcmFuZ2UNCj4+ICsgICAgICAgICAq Lw0KPj4gKyAgICAgICAgcnh0eF9kZXNjLT5zZW5kZXJfaWQgPSBmZmFfZ2V0X3ZtX2lkKGQpOw0K Pj4gKyAgICAgICAgcnh0eF9kZXNjLT5yZXNlcnZlZCA9IDA7DQo+PiArICAgICAgICByeHR4X2Rl c2MtPnJ4X3JlZ2lvbl9vZmZzID0gc2l6ZW9mKCpyeHR4X2Rlc2MpOw0KPj4gKyAgICAgICAgcnh0 eF9kZXNjLT50eF9yZWdpb25fb2ZmcyA9IHNpemVvZigqcnh0eF9kZXNjKSArDQo+PiArICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb2Zmc2V0b2Yoc3RydWN0IGZmYV9tZW1fcmVn aW9uLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFk ZHJlc3NfcmFuZ2VfYXJyYXlbMV0pOw0KPj4gKw0KPj4gKyAgICAgICAgLyogcnggYnVmZmVyICov DQo+PiArICAgICAgICBtZW1fcmVnID0gZmZhX3R4ICsgc2l6ZW9mKCpyeHR4X2Rlc2MpOw0KPj4g KyAgICAgICAgbWVtX3JlZy0+dG90YWxfcGFnZV9jb3VudCA9IDE7DQo+PiArICAgICAgICBtZW1f cmVnLT5hZGRyZXNzX3JhbmdlX2NvdW50ID0gMTsNCj4+ICsgICAgICAgIG1lbV9yZWctPnJlc2Vy dmVkID0gMDsNCj4+ICsNCj4+ICsgICAgICAgIG1lbV9yZWctPmFkZHJlc3NfcmFuZ2VfYXJyYXlb MF0uYWRkcmVzcyA9IHBhZ2VfdG9fbWFkZHIocnhfcGcpOw0KPj4gKyAgICAgICAgbWVtX3JlZy0+ YWRkcmVzc19yYW5nZV9hcnJheVswXS5wYWdlX2NvdW50ID0gMTsNCj4+ICsgICAgICAgIG1lbV9y ZWctPmFkZHJlc3NfcmFuZ2VfYXJyYXlbMF0ucmVzZXJ2ZWQgPSAwOw0KPj4gKw0KPj4gKyAgICAg ICAgLyogdHggYnVmZmVyICovDQo+PiArICAgICAgICBtZW1fcmVnID0gZmZhX3R4ICsgcnh0eF9k ZXNjLT50eF9yZWdpb25fb2ZmczsNCj4+ICsgICAgICAgIG1lbV9yZWctPnRvdGFsX3BhZ2VfY291 bnQgPSAxOw0KPj4gKyAgICAgICAgbWVtX3JlZy0+YWRkcmVzc19yYW5nZV9jb3VudCA9IDE7DQo+ PiArICAgICAgICBtZW1fcmVnLT5yZXNlcnZlZCA9IDA7DQo+PiArDQo+PiArICAgICAgICBtZW1f cmVnLT5hZGRyZXNzX3JhbmdlX2FycmF5WzBdLmFkZHJlc3MgPSBwYWdlX3RvX21hZGRyKHR4X3Bn KTsNCj4+ICsgICAgICAgIG1lbV9yZWctPmFkZHJlc3NfcmFuZ2VfYXJyYXlbMF0ucGFnZV9jb3Vu dCA9IDE7DQo+PiArICAgICAgICBtZW1fcmVnLT5hZGRyZXNzX3JhbmdlX2FycmF5WzBdLnJlc2Vy dmVkID0gMDsNCj4+ICsNCj4+ICsgICAgICAgIHJldCA9IGZmYV9yeHR4X21hcCgwLCAwLCAwKTsN Cj4+ICsNCj4+ICsgICAgICAgIHNwaW5fdW5sb2NrKCZmZmFfdHhfYnVmZmVyX2xvY2spOw0KPj4g Kw0KPj4gKyAgICAgICAgaWYgKCByZXQgIT0gRkZBX1JFVF9PSyApDQo+PiArICAgICAgICAgICAg Z290byBlcnJfdW5tYXBfcng7DQo+PiArICAgIH0NCj4+ICsNCj4+ICAgICBjdHgtPnJ4ID0gcng7 DQo+PiAgICAgY3R4LT50eCA9IHR4Ow0KPj4gICAgIGN0eC0+cnhfcGcgPSByeF9wZzsNCj4+IEBA IC05NSw2ICsxNjksOCBAQCB1aW50MzJfdCBmZmFfaGFuZGxlX3J4dHhfbWFwKHVpbnQzMl90IGZp ZCwgcmVnaXN0ZXJfdCB0eF9hZGRyLA0KPj4gICAgIGN0eC0+cnhfaXNfZnJlZSA9IHRydWU7DQo+ PiAgICAgcmV0dXJuIEZGQV9SRVRfT0s7DQo+PiANCj4+ICtlcnJfdW5tYXBfcng6DQo+PiArICAg IHVubWFwX2RvbWFpbl9wYWdlX2dsb2JhbChyeCk7DQo+PiBlcnJfdW5tYXBfdHg6DQo+PiAgICAg dW5tYXBfZG9tYWluX3BhZ2VfZ2xvYmFsKHR4KTsNCj4+IGVycl9wdXRfcnhfcGc6DQo+PiBAQCAt MTA1LDggKzE4MSwyMiBAQCBlcnJfcHV0X3R4X3BnOg0KPj4gICAgIHJldHVybiByZXQ7DQo+PiB9 DQo+PiANCj4+IC1zdGF0aWMgdm9pZCByeHR4X3VubWFwKHN0cnVjdCBmZmFfY3R4ICpjdHgpDQo+ PiArc3RhdGljIHVpbnQzMl90ICByeHR4X3VubWFwKHN0cnVjdCBkb21haW4gKmQpDQo+PiB7DQo+ PiArICAgIHN0cnVjdCBmZmFfY3R4ICpjdHggPSBkLT5hcmNoLnRlZTsNCj4+ICsNCj4+ICsgICAg aWYgKCAhY3R4LT5wYWdlX2NvdW50ICkNCj4+ICsgICAgICAgIHJldHVybiBGRkFfUkVUX0lOVkFM SURfUEFSQU1FVEVSUzsNCj4+ICsNCj4+ICsgICAgaWYgKCBmZmFfZndfc3VwcG9ydHNfZmlkKEZG QV9SWF9BQ1FVSVJFKSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHVpbnQzMl90IHJldDsNCj4+ ICsNCj4+ICsgICAgICAgIHJldCA9IGZmYV9yeHR4X3VubWFwKGZmYV9nZXRfdm1faWQoZCkpOw0K Pj4gKyAgICAgICAgaWYgKCByZXQgIT0gRkZBX1JFVF9PSyApDQo+PiArICAgICAgICAgICAgcmV0 dXJuIHJldDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gICAgIHVubWFwX2RvbWFpbl9wYWdlX2dsb2Jh bChjdHgtPnJ4KTsNCj4+ICAgICB1bm1hcF9kb21haW5fcGFnZV9nbG9iYWwoY3R4LT50eCk7DQo+ PiAgICAgcHV0X3BhZ2UoY3R4LT5yeF9wZyk7DQo+PiBAQCAtMTE3LDMyICsyMDcsNjMgQEAgc3Rh dGljIHZvaWQgcnh0eF91bm1hcChzdHJ1Y3QgZmZhX2N0eCAqY3R4KQ0KPj4gICAgIGN0eC0+dHhf cGcgPSBOVUxMOw0KPj4gICAgIGN0eC0+cGFnZV9jb3VudCA9IDA7DQo+PiAgICAgY3R4LT5yeF9p c19mcmVlID0gZmFsc2U7DQo+PiArDQo+PiArICAgIHJldHVybiBGRkFfUkVUX09LOw0KPj4gfQ0K Pj4gDQo+PiB1aW50MzJfdCBmZmFfaGFuZGxlX3J4dHhfdW5tYXAodm9pZCkNCj4+IHsNCj4+IC0g ICAgc3RydWN0IGRvbWFpbiAqZCA9IGN1cnJlbnQtPmRvbWFpbjsNCj4+ICsgICAgcmV0dXJuIHJ4 dHhfdW5tYXAoY3VycmVudC0+ZG9tYWluKTsNCj4+ICt9DQo+PiArDQo+PiAraW50MzJfdCBmZmFf cnhfYWNxdWlyZShzdHJ1Y3QgZG9tYWluICpkKQ0KPj4gK3sNCj4+ICsgICAgaW50MzJfdCByZXQg PSBGRkFfUkVUX09LOw0KPj4gICAgIHN0cnVjdCBmZmFfY3R4ICpjdHggPSBkLT5hcmNoLnRlZTsN Cj4+IA0KPj4gLSAgICBpZiAoICFjdHgtPnJ4ICkNCj4+IC0gICAgICAgIHJldHVybiBGRkFfUkVU X0lOVkFMSURfUEFSQU1FVEVSUzsNCj4+ICsgICAgc3Bpbl9sb2NrKCZjdHgtPnJ4X2xvY2spOw0K Pj4gDQo+PiAtICAgIHJ4dHhfdW5tYXAoY3R4KTsNCj4+ICsgICAgaWYgKCAhY3R4LT5wYWdlX2Nv dW50ICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcmV0ID0gRkZBX1JFVF9ERU5JRUQ7DQo+PiAr ICAgICAgICBnb3RvIG91dDsNCj4+ICsgICAgfQ0KPj4gDQo+PiAtICAgIHJldHVybiBGRkFfUkVU X09LOw0KPj4gKyAgICBpZiAoICFjdHgtPnJ4X2lzX2ZyZWUgKQ0KPj4gKyAgICB7DQo+PiArICAg ICAgICByZXQgPSBGRkFfUkVUX0JVU1k7DQo+PiArICAgICAgICBnb3RvIG91dDsNCj4+ICsgICAg fQ0KPj4gKw0KPj4gKyAgICBpZiAoIGZmYV9md19zdXBwb3J0c19maWQoRkZBX1JYX0FDUVVJUkUp ICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcmV0ID0gZmZhX3NpbXBsZV9jYWxsKEZGQV9SWF9B Q1FVSVJFLCBmZmFfZ2V0X3ZtX2lkKGQpLCAwLCAwLCAwKTsNCj4+ICsgICAgICAgIGlmICggcmV0 ICE9IEZGQV9SRVRfT0sgKQ0KPj4gKyAgICAgICAgICAgIGdvdG8gb3V0Ow0KPj4gKyAgICB9DQo+ PiArICAgIGN0eC0+cnhfaXNfZnJlZSA9IGZhbHNlOw0KPj4gK291dDoNCj4+ICsgICAgc3Bpbl91 bmxvY2soJmN0eC0+cnhfbG9jayk7DQo+PiArDQo+PiArICAgIHJldHVybiByZXQ7DQo+PiB9DQo+ PiANCj4+IC1pbnQzMl90IGZmYV9oYW5kbGVfcnhfcmVsZWFzZSh2b2lkKQ0KPj4gK2ludDMyX3Qg ZmZhX3J4X3JlbGVhc2Uoc3RydWN0IGRvbWFpbiAqZCkNCj4+IHsNCj4+ICAgICBpbnQzMl90IHJl dCA9IEZGQV9SRVRfREVOSUVEOw0KPj4gLSAgICBzdHJ1Y3QgZG9tYWluICpkID0gY3VycmVudC0+ ZG9tYWluOw0KPj4gICAgIHN0cnVjdCBmZmFfY3R4ICpjdHggPSBkLT5hcmNoLnRlZTsNCj4+IA0K Pj4gLSAgICBpZiAoICFzcGluX3RyeWxvY2soJmN0eC0+cnhfbG9jaykgKQ0KPj4gLSAgICAgICAg cmV0dXJuIEZGQV9SRVRfQlVTWTsNCj4+ICsgICAgc3Bpbl9sb2NrKCZjdHgtPnJ4X2xvY2spOw0K Pj4gDQo+PiAgICAgaWYgKCAhY3R4LT5wYWdlX2NvdW50IHx8IGN0eC0+cnhfaXNfZnJlZSApDQo+ PiAgICAgICAgIGdvdG8gb3V0Ow0KPj4gKw0KPj4gKyAgICBpZiAoIGZmYV9md19zdXBwb3J0c19m aWQoRkZBX1JYX0FDUVVJUkUpICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcmV0ID0gZmZhX3Np bXBsZV9jYWxsKEZGQV9SWF9SRUxFQVNFLCBmZmFfZ2V0X3ZtX2lkKGQpLCAwLCAwLCAwKTsNCj4+ ICsgICAgICAgIGlmICggcmV0ICE9IEZGQV9SRVRfT0sgKQ0KPj4gKyAgICAgICAgICAgIGdvdG8g b3V0Ow0KPj4gKyAgICB9DQo+PiAgICAgcmV0ID0gRkZBX1JFVF9PSzsNCj4+ICAgICBjdHgtPnJ4 X2lzX2ZyZWUgPSB0cnVlOw0KPj4gb3V0Og0KPj4gQEAgLTE1MSwyMyArMjcyLDkgQEAgb3V0Og0K Pj4gICAgIHJldHVybiByZXQ7DQo+PiB9DQo+PiANCj4+IC1zdGF0aWMgaW50MzJfdCBmZmFfcnh0 eF9tYXAocGFkZHJfdCB0eF9hZGRyLCBwYWRkcl90IHJ4X2FkZHIsDQo+PiAtICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHVpbnQzMl90IHBhZ2VfY291bnQpDQo+PiAtew0KPj4gLSAgICByZXR1 cm4gZmZhX3NpbXBsZV9jYWxsKEZGQV9SWFRYX01BUF82NCwgdHhfYWRkciwgcnhfYWRkciwgcGFn ZV9jb3VudCwgMCk7DQo+PiAtfQ0KPj4gLQ0KPj4gLXN0YXRpYyBpbnQzMl90IGZmYV9yeHR4X3Vu bWFwKHZvaWQpDQo+PiAtew0KPj4gLSAgICByZXR1cm4gZmZhX3NpbXBsZV9jYWxsKEZGQV9SWFRY X1VOTUFQLCAwLCAwLCAwLCAwKTsNCj4+IC19DQo+PiAtDQo+PiB2b2lkIGZmYV9yeHR4X2RvbWFp bl9kZXN0cm95KHN0cnVjdCBkb21haW4gKmQpDQo+PiB7DQo+PiAtICAgIHN0cnVjdCBmZmFfY3R4 ICpjdHggPSBkLT5hcmNoLnRlZTsNCj4+IC0NCj4+IC0gICAgaWYgKCBjdHgtPnJ4ICkNCj4+IC0g ICAgICAgIHJ4dHhfdW5tYXAoY3R4KTsNCj4+ICsgICAgcnh0eF91bm1hcChkKTsNCj4+IH0NCj4+ IA0KPj4gdm9pZCBmZmFfcnh0eF9kZXN0cm95KHZvaWQpDQo+PiBAQCAtMTg2LDcgKzI5Myw3IEBA IHZvaWQgZmZhX3J4dHhfZGVzdHJveSh2b2lkKQ0KPj4gICAgIH0NCj4+IA0KPj4gICAgIGlmICgg bmVlZF91bm1hcCApDQo+PiAtICAgICAgICBmZmFfcnh0eF91bm1hcCgpOw0KPj4gKyAgICAgICAg ZmZhX3J4dHhfdW5tYXAoMCk7DQo+PiB9DQo+PiANCj4+IGJvb2wgZmZhX3J4dHhfaW5pdCh2b2lk KQ0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS90ZWUvZmZhX3NobS5jIGIveGVuL2FyY2gv YXJtL3RlZS9mZmFfc2htLmMNCj4+IGluZGV4IDI5Njc1ZjliYTNmNy4uZDYyOGMxYjcwNjA5IDEw MDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJtL3RlZS9mZmFfc2htLmMNCj4+ICsrKyBiL3hlbi9h cmNoL2FybS90ZWUvZmZhX3NobS5jDQo+PiBAQCAtMTYsMjEgKzE2LDYgQEANCj4+IA0KPj4gI2lu Y2x1ZGUgImZmYV9wcml2YXRlLmgiDQo+PiANCj4+IC0vKiBDb25zdGl0dWVudCBtZW1vcnkgcmVn aW9uIGRlc2NyaXB0b3IgKi8NCj4+IC1zdHJ1Y3QgZmZhX2FkZHJlc3NfcmFuZ2Ugew0KPj4gLSAg ICB1aW50NjRfdCBhZGRyZXNzOw0KPj4gLSAgICB1aW50MzJfdCBwYWdlX2NvdW50Ow0KPj4gLSAg ICB1aW50MzJfdCByZXNlcnZlZDsNCj4+IC19Ow0KPj4gLQ0KPj4gLS8qIENvbXBvc2l0ZSBtZW1v cnkgcmVnaW9uIGRlc2NyaXB0b3IgKi8NCj4+IC1zdHJ1Y3QgZmZhX21lbV9yZWdpb24gew0KPj4g LSAgICB1aW50MzJfdCB0b3RhbF9wYWdlX2NvdW50Ow0KPj4gLSAgICB1aW50MzJfdCBhZGRyZXNz X3JhbmdlX2NvdW50Ow0KPj4gLSAgICB1aW50NjRfdCByZXNlcnZlZDsNCj4+IC0gICAgc3RydWN0 IGZmYV9hZGRyZXNzX3JhbmdlIGFkZHJlc3NfcmFuZ2VfYXJyYXlbXTsNCj4+IC19Ow0KPj4gLQ0K Pj4gLyogTWVtb3J5IGFjY2VzcyBwZXJtaXNzaW9ucyBkZXNjcmlwdG9yICovDQo+PiBzdHJ1Y3Qg ZmZhX21lbV9hY2Nlc3NfcGVybSB7DQo+PiAgICAgdWludDE2X3QgZW5kcG9pbnRfaWQ7DQo+PiAt LQ0KPj4gMi40Ny4wDQoNCg0K From xen-devel-bounces@lists.xenproject.org Fri Dec 06 11:41:25 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 11:41:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850233.1264681 (Exim 4.92) (envelope-from ) id 1tJWhx-0001BW-GV; Fri, 06 Dec 2024 11:41:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850233.1264681; Fri, 06 Dec 2024 11:41:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJWhx-0001BP-DL; Fri, 06 Dec 2024 11:41:17 +0000 Received: by outflank-mailman (input) for mailman id 850233; Fri, 06 Dec 2024 11:41: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 1tJWhv-0001BJ-DX for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 11:41:15 +0000 Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [2607:f8b0:4864:20::233]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fe399a44-b3c6-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 12:41:13 +0100 (CET) Received: by mail-oi1-x233.google.com with SMTP id 5614622812f47-3ea4f9825f6so578770b6e.2 for ; Fri, 06 Dec 2024 03:41:13 -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: fe399a44-b3c6-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1733485271; x=1734090071; 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=1RAVKV8Jmr/nGqdophe+WlXf8Kzz0ypESc8Lf2O2m+U=; b=wNP0gMG4t9zmdTr/TXe77aQhvrQNwkZq+kO7GFZ5ZtKJswEP/D9a6F7g+LhYX7UG0A s0eIyOfboROj2NB4bT+rJVmJY0b3ESFlnhrLiqCkkWx3ziLBDa+N3NK6VG1Vvc3H7YJh rNvwEHxNyAWreOALv2/EWb33jnJsoRiAh1xKgJwrtcsDDm/wy402nhigmvOGuIYjOnEw FjEkuzuAwpGXS8fa04PehXEQ46h5KzF40lI+iCGha/JKSRDbi/FQLkFBhz7qIQMfqt5r bpe67fxwN4kNPf7YxWfFwnNgXNAs6Y8uDJhnE/ZlESDIjizFgs2+CaGn8j2eb1yEzIhf P9JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733485271; x=1734090071; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=1RAVKV8Jmr/nGqdophe+WlXf8Kzz0ypESc8Lf2O2m+U=; b=P0zdrlHmfzK2xzHLQ0KKuEupHbDq/6911G1T+YebrzLxk5PCJchas2Dzf0lr8lsR3a xFKvC4psTP86mvP1ukhciS08PyXVrj5fvJKNjLGpm5G3wVFRtvcAMCuSRgusoGML/2fz 4bsxCkHUgzPGr4q1o9AeGB/qUCtkl3IcTQWLWt00K7eR4peZbWNKNyd1olhmGAstizz2 EE10cIEL1Z5RG6ByFeUYDEXM4vUuahk/kH/gP1hxyT5wt23Gs4kY4Zo2L9O7CcvNU6Dg bbzikcoBGsp+YLMe1XWSKMA37LrGkDuwK91l3am199QLDZVxC2iZHg74F0XKt2SO4yy4 HGCQ== X-Gm-Message-State: AOJu0YzFlrvgAOgS3JzK0g6ZC+FGg6lz+DCs1vAb1KPeVVGDe5eJMffI jpF3DLO4RjLwzoqMQaBQFRfaz/Ck+mvuctz1E1famrjekgKEVCpjwvJpUlUCXDVouGbkk+7uExd E7NMmENkQvbtXMYqif4xZnEhMd7mj8/2xp45A5Q== X-Gm-Gg: ASbGncu3s1OfkEtQl6og9AVZIoI+lk1rIWHweH1ONYncUWT8f7GgSZpSKiw07BcIexb TYXvHkL7+rFeXO9Falv5HxKPCAFcROlE= X-Google-Smtp-Source: AGHT+IF9PRDCXlW8ET4CpEmd4brW04levfL4pqfRnbDKCQHlhj6Y7Y1svEAGuvPQKL0/AycSqeYgm7eASS0+4Gc8TA4= X-Received: by 2002:a05:6808:3849:b0:3ea:519e:cc71 with SMTP id 5614622812f47-3eb19e00bd3mr1187656b6e.39.1733485271557; Fri, 06 Dec 2024 03:41:11 -0800 (PST) MIME-Version: 1.0 References: <56217f2f7b4c29a5f84fb02de3f4cbb8342c5560.1732702210.git.bertrand.marquis@arm.com> <8EA516E9-A660-436A-A64D-69DD04E9759E@arm.com> In-Reply-To: <8EA516E9-A660-436A-A64D-69DD04E9759E@arm.com> From: Jens Wiklander Date: Fri, 6 Dec 2024 12:41:00 +0100 Message-ID: Subject: Re: [PATCH v3 07/10] xen/arm: ffa: Transmit RXTX buffers to the SPMC 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 On Fri, Dec 6, 2024 at 11:47=E2=80=AFAM Bertrand Marquis wrote: > > Hi Jens, > > > On 6 Dec 2024, at 08:58, Jens Wiklander wro= te: > > > > Hi Bertrand, > > > > On Wed, Nov 27, 2024 at 5:08=E2=80=AFPM Bertrand Marquis > > wrote: > >> > >> When an RXTX buffer is mapped by a VM transmit it to the SPMC when it > >> supports RX_ACQUIRE. > >> As a consequence of that, we must acquire the RX buffer of a VM from t= he > >> SPMC when we want to use it: > >> - create a generic acquire and release function to get the rx buffer o= f > >> a VM which gets it from the SPMC when supported > >> - rename the rx_acquire to hyp_rx_acquire to remove confusion > >> - rework the rx_lock to only lock access to rx_is_free and only allow > >> usage of the rx buffer to one who managed to acquire it, thus removin= g > >> the trylock and returning busy if rx_is_free is false > >> > >> As part of this change move some structure definition to ffa_private > >> from ffa_shm as those are need for the MAP call with the SPMC. > >> > >> While there also fix ffa_handle_rxtx_map which was testing the wrong > >> variable after getting the page for the rx buffer, testing tx_pg > >> instead of rx_pg. > >> > >> Fixes: be75f686eb03 ("xen/arm: ffa: separate rxtx buffer routines") > >> > >> Signed-off-by: Bertrand Marquis > >> --- > >> Changes in v3: > >> - add a comment to explain why we only release the RX buffer if an err= or > >> occurs during partition_info_get > >> - fix the BUILD_BUG_ON check for TX buffer size in rxtx_map (coding > >> style and use PAGE_SIZE * NUM_PAGE) > >> - remove invalid 3 argument to ffa_rxtx_map when forwarding the call t= o > >> the SPMC > >> - fix bug in ffa_handle_rxtx_map testing wrong variable > >> Changes in v2: > >> - unmap VM rxtx buffer in SPMC on unmap call or on VM destroy > >> - rework the unmap call to the SPMC to properly pass the VM ID > >> --- > >> xen/arch/arm/tee/ffa.c | 2 +- > >> xen/arch/arm/tee/ffa_partinfo.c | 36 ++++--- > >> xen/arch/arm/tee/ffa_private.h | 22 ++++- > >> xen/arch/arm/tee/ffa_rxtx.c | 161 ++++++++++++++++++++++++++------ > >> xen/arch/arm/tee/ffa_shm.c | 15 --- > >> 5 files changed, 170 insertions(+), 66 deletions(-) > >> > >> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c > >> index 0026ac9134ad..bc2722d53fd7 100644 > >> --- a/xen/arch/arm/tee/ffa.c > >> +++ b/xen/arch/arm/tee/ffa.c > >> @@ -347,7 +347,7 @@ static bool ffa_handle_call(struct cpu_user_regs *= regs) > >> ffa_handle_partition_info_get(regs); > >> return true; > >> case FFA_RX_RELEASE: > >> - e =3D ffa_handle_rx_release(); > >> + e =3D ffa_rx_release(d); > >> break; > >> case FFA_MSG_SEND_DIRECT_REQ_32: > >> case FFA_MSG_SEND_DIRECT_REQ_64: > >> diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_pa= rtinfo.c > >> index 74324e1d9d3f..939ed49dd3da 100644 > >> --- a/xen/arch/arm/tee/ffa_partinfo.c > >> +++ b/xen/arch/arm/tee/ffa_partinfo.c > >> @@ -121,11 +121,9 @@ void ffa_handle_partition_info_get(struct cpu_use= r_regs *regs) > >> goto out; > >> } > >> > >> - if ( !spin_trylock(&ctx->rx_lock) ) > >> - { > >> - ret =3D FFA_RET_BUSY; > >> + ret =3D ffa_rx_acquire(d); > >> + if ( ret !=3D FFA_RET_OK ) > >> goto out; > >> - } > >> > >> dst_buf =3D ctx->rx; > >> > >> @@ -135,22 +133,16 @@ void ffa_handle_partition_info_get(struct cpu_us= er_regs *regs) > >> goto out_rx_release; > >> } > >> > >> - if ( !ctx->page_count || !ctx->rx_is_free ) > >> - { > >> - ret =3D FFA_RET_DENIED; > >> - goto out_rx_release; > >> - } > >> - > >> spin_lock(&ffa_rx_buffer_lock); > >> > >> ret =3D ffa_partition_info_get(uuid, 0, &ffa_sp_count, &src_size); > >> > >> if ( ret ) > >> - goto out_rx_buf_unlock; > >> + goto out_rx_hyp_unlock; > >> > >> /* > >> * ffa_partition_info_get() succeeded so we now own the RX buffer = we > >> - * share with the SPMC. We must give it back using ffa_rx_release= () > >> + * share with the SPMC. We must give it back using ffa_hyp_rx_rel= ease() > >> * once we've copied the content. > >> */ > >> > >> @@ -190,15 +182,20 @@ void ffa_handle_partition_info_get(struct cpu_us= er_regs *regs) > >> } > >> } > >> > >> - ctx->rx_is_free =3D false; > >> - > >> out_rx_hyp_release: > >> - ffa_rx_release(); > >> -out_rx_buf_unlock: > >> + ffa_hyp_rx_release(); > >> +out_rx_hyp_unlock: > >> spin_unlock(&ffa_rx_buffer_lock); > >> out_rx_release: > >> - spin_unlock(&ctx->rx_lock); > >> - > >> + /* > >> + * The calling VM RX buffer only contains data to be used by the = VM if the > >> + * call was successfull, in which case the VM has to release the = buffer > > > > successful > > Ack. > > > > >> + * once it has used the data. > >> + * If something went wrong during the call, we have to release th= e RX > >> + * buffer back to the SPMC as the VM will not do it. > >> + */ > >> + if ( ret !=3D FFA_RET_OK ) > >> + ffa_rx_release(d); > >> out: > >> if ( ret ) > >> ffa_set_regs_error(regs, ret); > >> @@ -365,8 +362,7 @@ bool ffa_partinfo_init(void) > >> ret =3D init_subscribers(count, fpi_size); > >> > >> out: > >> - ffa_rx_release(); > >> - > >> + ffa_hyp_rx_release(); > >> return ret; > >> } > >> > >> diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_pri= vate.h > >> index afe69b43dbef..9adfe687c3c9 100644 > >> --- a/xen/arch/arm/tee/ffa_private.h > >> +++ b/xen/arch/arm/tee/ffa_private.h > >> @@ -265,6 +265,21 @@ > >> #define FFA_ABI_BITNUM(id) ((FFA_ABI_ID(id) - FFA_ABI_MIN) << 1 | \ > >> FFA_ABI_CONV(id)) > >> > >> +/* Constituent memory region descriptor */ > >> +struct ffa_address_range { > >> + uint64_t address; > >> + uint32_t page_count; > >> + uint32_t reserved; > >> +}; > >> + > >> +/* Composite memory region descriptor */ > >> +struct ffa_mem_region { > >> + uint32_t total_page_count; > >> + uint32_t address_range_count; > >> + uint64_t reserved; > >> + struct ffa_address_range address_range_array[]; > >> +}; > >> + > >> struct ffa_ctx_notif { > >> bool enabled; > >> > >> @@ -292,7 +307,7 @@ struct ffa_ctx { > >> struct ffa_ctx_notif notif; > >> /* > >> * tx_lock is used to serialize access to tx > >> - * rx_lock is used to serialize access to rx > >> + * rx_lock is used to serialize access to rx_is_free > >> * lock is used for the rest in this struct > >> */ > >> spinlock_t tx_lock; > >> @@ -331,7 +346,8 @@ void ffa_rxtx_domain_destroy(struct domain *d); > >> uint32_t ffa_handle_rxtx_map(uint32_t fid, register_t tx_addr, > >> register_t rx_addr, uint32_t page_count); > >> uint32_t ffa_handle_rxtx_unmap(void); > >> -int32_t ffa_handle_rx_release(void); > >> +int32_t ffa_rx_acquire(struct domain *d); > >> +int32_t ffa_rx_release(struct domain *d); > >> > >> void ffa_notif_init(void); > >> void ffa_notif_init_interrupt(void); > >> @@ -420,7 +436,7 @@ static inline int32_t ffa_simple_call(uint32_t fid= , register_t a1, > >> return ffa_get_ret_code(&resp); > >> } > >> > >> -static inline int32_t ffa_rx_release(void) > >> +static inline int32_t ffa_hyp_rx_release(void) > >> { > >> return ffa_simple_call(FFA_RX_RELEASE, 0, 0, 0, 0); > >> } > >> diff --git a/xen/arch/arm/tee/ffa_rxtx.c b/xen/arch/arm/tee/ffa_rxtx.c > >> index 132a7982407b..e1cab7fa5e46 100644 > >> --- a/xen/arch/arm/tee/ffa_rxtx.c > >> +++ b/xen/arch/arm/tee/ffa_rxtx.c > >> @@ -30,6 +30,17 @@ struct ffa_endpoint_rxtx_descriptor_1_1 { > >> uint32_t tx_region_offs; > >> }; > >> > >> +static int32_t ffa_rxtx_map(paddr_t tx_addr, paddr_t rx_addr, > >> + uint32_t page_count) > >> +{ > >> + return ffa_simple_call(FFA_RXTX_MAP_64, tx_addr, rx_addr, page_co= unt, 0); > >> +} > >> + > >> +static int32_t ffa_rxtx_unmap(uint16_t id) > >> +{ > >> + return ffa_simple_call(FFA_RXTX_UNMAP, ((uint64_t)id)<<16, 0, 0, = 0); > > > > Please add a space before and after the "<<" operator. > > Sure. > > With those 2 fixes can I add you R-b in the next patch version ? Yes, please do Reviewed-by: Jens Wiklander Cheers, Jens > > Thanks for the reviews. > > Cheers > Bertrand > > > > > Cheers, > > Jens > > > >> +} > >> + > >> uint32_t ffa_handle_rxtx_map(uint32_t fid, register_t tx_addr, > >> register_t rx_addr, uint32_t page_count) > >> { > >> @@ -42,6 +53,9 @@ uint32_t ffa_handle_rxtx_map(uint32_t fid, register_= t tx_addr, > >> void *rx; > >> void *tx; > >> > >> + /* The code is considering that we only get one page for now */ > >> + BUILD_BUG_ON(FFA_MAX_RXTX_PAGE_COUNT !=3D 1); > >> + > >> if ( !smccc_is_conv_64(fid) ) > >> { > >> /* > >> @@ -72,7 +86,7 @@ uint32_t ffa_handle_rxtx_map(uint32_t fid, register_= t tx_addr, > >> goto err_put_tx_pg; > >> > >> rx_pg =3D get_page_from_gfn(d, gfn_x(gaddr_to_gfn(rx_addr)), &t, P= 2M_ALLOC); > >> - if ( !tx_pg ) > >> + if ( !rx_pg ) > >> goto err_put_tx_pg; > >> > >> /* Only normal RW RAM for now */ > >> @@ -87,6 +101,66 @@ uint32_t ffa_handle_rxtx_map(uint32_t fid, registe= r_t tx_addr, > >> if ( !rx ) > >> goto err_unmap_tx; > >> > >> + /* > >> + * Transmit the RX/TX buffer information to the SPM if acquire is= supported > >> + * as the spec says that if not there is not need to acquire/rele= ase/map > >> + * rxtx buffers from the SPMC > >> + */ > >> + if ( ffa_fw_supports_fid(FFA_RX_ACQUIRE) ) > >> + { > >> + struct ffa_endpoint_rxtx_descriptor_1_1 *rxtx_desc; > >> + struct ffa_mem_region *mem_reg; > >> + > >> + /* All must fit in our TX buffer */ > >> + BUILD_BUG_ON(sizeof(*rxtx_desc) + sizeof(*mem_reg) * 2 + > >> + sizeof(struct ffa_address_range) * 2 > > >> + FFA_MAX_RXTX_PAGE_COUNT * FFA_PAGE_SIZE); > >> + > >> + spin_lock(&ffa_tx_buffer_lock); > >> + rxtx_desc =3D ffa_tx; > >> + > >> + /* > >> + * We have only one page for each so we pack everything: > >> + * - rx region descriptor > >> + * - rx region range > >> + * - tx region descriptor > >> + * - tx region range > >> + */ > >> + rxtx_desc->sender_id =3D ffa_get_vm_id(d); > >> + rxtx_desc->reserved =3D 0; > >> + rxtx_desc->rx_region_offs =3D sizeof(*rxtx_desc); > >> + rxtx_desc->tx_region_offs =3D sizeof(*rxtx_desc) + > >> + offsetof(struct ffa_mem_region, > >> + address_range_array[1]); > >> + > >> + /* rx buffer */ > >> + mem_reg =3D ffa_tx + sizeof(*rxtx_desc); > >> + mem_reg->total_page_count =3D 1; > >> + mem_reg->address_range_count =3D 1; > >> + mem_reg->reserved =3D 0; > >> + > >> + mem_reg->address_range_array[0].address =3D page_to_maddr(rx_= pg); > >> + mem_reg->address_range_array[0].page_count =3D 1; > >> + mem_reg->address_range_array[0].reserved =3D 0; > >> + > >> + /* tx buffer */ > >> + mem_reg =3D ffa_tx + rxtx_desc->tx_region_offs; > >> + mem_reg->total_page_count =3D 1; > >> + mem_reg->address_range_count =3D 1; > >> + mem_reg->reserved =3D 0; > >> + > >> + mem_reg->address_range_array[0].address =3D page_to_maddr(tx_= pg); > >> + mem_reg->address_range_array[0].page_count =3D 1; > >> + mem_reg->address_range_array[0].reserved =3D 0; > >> + > >> + ret =3D ffa_rxtx_map(0, 0, 0); > >> + > >> + spin_unlock(&ffa_tx_buffer_lock); > >> + > >> + if ( ret !=3D FFA_RET_OK ) > >> + goto err_unmap_rx; > >> + } > >> + > >> ctx->rx =3D rx; > >> ctx->tx =3D tx; > >> ctx->rx_pg =3D rx_pg; > >> @@ -95,6 +169,8 @@ uint32_t ffa_handle_rxtx_map(uint32_t fid, register= _t tx_addr, > >> ctx->rx_is_free =3D true; > >> return FFA_RET_OK; > >> > >> +err_unmap_rx: > >> + unmap_domain_page_global(rx); > >> err_unmap_tx: > >> unmap_domain_page_global(tx); > >> err_put_rx_pg: > >> @@ -105,8 +181,22 @@ err_put_tx_pg: > >> return ret; > >> } > >> > >> -static void rxtx_unmap(struct ffa_ctx *ctx) > >> +static uint32_t rxtx_unmap(struct domain *d) > >> { > >> + struct ffa_ctx *ctx =3D d->arch.tee; > >> + > >> + if ( !ctx->page_count ) > >> + return FFA_RET_INVALID_PARAMETERS; > >> + > >> + if ( ffa_fw_supports_fid(FFA_RX_ACQUIRE) ) > >> + { > >> + uint32_t ret; > >> + > >> + ret =3D ffa_rxtx_unmap(ffa_get_vm_id(d)); > >> + if ( ret !=3D FFA_RET_OK ) > >> + return ret; > >> + } > >> + > >> unmap_domain_page_global(ctx->rx); > >> unmap_domain_page_global(ctx->tx); > >> put_page(ctx->rx_pg); > >> @@ -117,32 +207,63 @@ static void rxtx_unmap(struct ffa_ctx *ctx) > >> ctx->tx_pg =3D NULL; > >> ctx->page_count =3D 0; > >> ctx->rx_is_free =3D false; > >> + > >> + return FFA_RET_OK; > >> } > >> > >> uint32_t ffa_handle_rxtx_unmap(void) > >> { > >> - struct domain *d =3D current->domain; > >> + return rxtx_unmap(current->domain); > >> +} > >> + > >> +int32_t ffa_rx_acquire(struct domain *d) > >> +{ > >> + int32_t ret =3D FFA_RET_OK; > >> struct ffa_ctx *ctx =3D d->arch.tee; > >> > >> - if ( !ctx->rx ) > >> - return FFA_RET_INVALID_PARAMETERS; > >> + spin_lock(&ctx->rx_lock); > >> > >> - rxtx_unmap(ctx); > >> + if ( !ctx->page_count ) > >> + { > >> + ret =3D FFA_RET_DENIED; > >> + goto out; > >> + } > >> > >> - return FFA_RET_OK; > >> + if ( !ctx->rx_is_free ) > >> + { > >> + ret =3D FFA_RET_BUSY; > >> + goto out; > >> + } > >> + > >> + if ( ffa_fw_supports_fid(FFA_RX_ACQUIRE) ) > >> + { > >> + ret =3D ffa_simple_call(FFA_RX_ACQUIRE, ffa_get_vm_id(d), 0, = 0, 0); > >> + if ( ret !=3D FFA_RET_OK ) > >> + goto out; > >> + } > >> + ctx->rx_is_free =3D false; > >> +out: > >> + spin_unlock(&ctx->rx_lock); > >> + > >> + return ret; > >> } > >> > >> -int32_t ffa_handle_rx_release(void) > >> +int32_t ffa_rx_release(struct domain *d) > >> { > >> int32_t ret =3D FFA_RET_DENIED; > >> - struct domain *d =3D current->domain; > >> struct ffa_ctx *ctx =3D d->arch.tee; > >> > >> - if ( !spin_trylock(&ctx->rx_lock) ) > >> - return FFA_RET_BUSY; > >> + spin_lock(&ctx->rx_lock); > >> > >> if ( !ctx->page_count || ctx->rx_is_free ) > >> goto out; > >> + > >> + if ( ffa_fw_supports_fid(FFA_RX_ACQUIRE) ) > >> + { > >> + ret =3D ffa_simple_call(FFA_RX_RELEASE, ffa_get_vm_id(d), 0, = 0, 0); > >> + if ( ret !=3D FFA_RET_OK ) > >> + goto out; > >> + } > >> ret =3D FFA_RET_OK; > >> ctx->rx_is_free =3D true; > >> out: > >> @@ -151,23 +272,9 @@ out: > >> return ret; > >> } > >> > >> -static int32_t ffa_rxtx_map(paddr_t tx_addr, paddr_t rx_addr, > >> - uint32_t page_count) > >> -{ > >> - return ffa_simple_call(FFA_RXTX_MAP_64, tx_addr, rx_addr, page_co= unt, 0); > >> -} > >> - > >> -static int32_t ffa_rxtx_unmap(void) > >> -{ > >> - return ffa_simple_call(FFA_RXTX_UNMAP, 0, 0, 0, 0); > >> -} > >> - > >> void ffa_rxtx_domain_destroy(struct domain *d) > >> { > >> - struct ffa_ctx *ctx =3D d->arch.tee; > >> - > >> - if ( ctx->rx ) > >> - rxtx_unmap(ctx); > >> + rxtx_unmap(d); > >> } > >> > >> void ffa_rxtx_destroy(void) > >> @@ -186,7 +293,7 @@ void ffa_rxtx_destroy(void) > >> } > >> > >> if ( need_unmap ) > >> - ffa_rxtx_unmap(); > >> + ffa_rxtx_unmap(0); > >> } > >> > >> bool ffa_rxtx_init(void) > >> diff --git a/xen/arch/arm/tee/ffa_shm.c b/xen/arch/arm/tee/ffa_shm.c > >> index 29675f9ba3f7..d628c1b70609 100644 > >> --- a/xen/arch/arm/tee/ffa_shm.c > >> +++ b/xen/arch/arm/tee/ffa_shm.c > >> @@ -16,21 +16,6 @@ > >> > >> #include "ffa_private.h" > >> > >> -/* Constituent memory region descriptor */ > >> -struct ffa_address_range { > >> - uint64_t address; > >> - uint32_t page_count; > >> - uint32_t reserved; > >> -}; > >> - > >> -/* Composite memory region descriptor */ > >> -struct ffa_mem_region { > >> - uint32_t total_page_count; > >> - uint32_t address_range_count; > >> - uint64_t reserved; > >> - struct ffa_address_range address_range_array[]; > >> -}; > >> - > >> /* Memory access permissions descriptor */ > >> struct ffa_mem_access_perm { > >> uint16_t endpoint_id; > >> -- > >> 2.47.0 > > From xen-devel-bounces@lists.xenproject.org Fri Dec 06 13:02:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 13:02:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850259.1264691 (Exim 4.92) (envelope-from ) id 1tJXyV-000372-Ao; Fri, 06 Dec 2024 13:02:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850259.1264691; Fri, 06 Dec 2024 13:02: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 1tJXyV-00036v-70; Fri, 06 Dec 2024 13:02:27 +0000 Received: by outflank-mailman (input) for mailman id 850259; Fri, 06 Dec 2024 13:02: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 1tJXyU-00036p-BF for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 13:02:26 +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 5634682c-b3d2-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 14:02:24 +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 BDACB1F38E; Fri, 6 Dec 2024 13:02:23 +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 723E113647; Fri, 6 Dec 2024 13:02:23 +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 o0tlGt/1Ume3TgAAD6G6ig (envelope-from ); Fri, 06 Dec 2024 13:02: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: 5634682c-b3d2-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733490143; 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=PlPMsMQtiCVtC9z4pQm+gdsBuDCsGGooLtyyGsYuM9Q=; b=N2OlNHAH6AWWYHrLx8ZoWTxIANLPiTpYZiV3ST3tFEio9X60CdkmgDPUr5/5/QV0S8I71z FrnVaj6UYTqWdQXE6I4PsNu4EWol9O4vvP+V8kagWw9sFrZXVe5z42xlSFz0bYI9KDttz7 zftg4/fuYnjUK5jPGWE3SH/bRLifOLw= Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=N2OlNHAH DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733490143; 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=PlPMsMQtiCVtC9z4pQm+gdsBuDCsGGooLtyyGsYuM9Q=; b=N2OlNHAH6AWWYHrLx8ZoWTxIANLPiTpYZiV3ST3tFEio9X60CdkmgDPUr5/5/QV0S8I71z FrnVaj6UYTqWdQXE6I4PsNu4EWol9O4vvP+V8kagWw9sFrZXVe5z42xlSFz0bYI9KDttz7 zftg4/fuYnjUK5jPGWE3SH/bRLifOLw= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , "Daniel P. Smith" , Anthony PERARD , Samuel Thibault Subject: [PATCH v2 0/7] remove libxenctrl usage from xenstored Date: Fri, 6 Dec 2024 14:02:14 +0100 Message-ID: <20241206130221.17773-1-jgross@suse.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: BDACB1F38E X-Spam-Level: X-Spamd-Result: default: False [-3.01 / 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)[]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[suse.com:+]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RCPT_COUNT_SEVEN(0.00)[9]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; ASN(0.00)[asn:25478, ipnet:::/0, country:RU]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:dkim,suse.com:mid] X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Action: no action X-Spam-Score: -3.01 X-Spam-Flag: NO Xenstored is using libxenctrl for only one purpose: to get information about state of domains. This patch series is removing that dependency by introducing a new stable interface which can be used by xenstored instead. There was a RFC series sent out 3 years ago, which I have taken as a base and by addressing all comments from back then. The main differences since that RFC series are: - Instead of introducing an new main hypercall for a stable management interface I have just added a new domctl sub-op, as requested in 2021. - I have added a new library libxenmanage for easy use of the new stable hypervisor interface. Main motivation for adding the library was the recent attempt to decouple oxenstored from the Xen git tree. By using the new library, oxenstored could benefit in the same way as xenstored from the new interface: it would be possible to rely on stable libraries only. - Mini-OS has gained some more config options recently, so it was rather easy to make xenstore[pvh]-stubdom independent from libxenctrl, too. - By moving the CPU barrier definitions out of xenctrl.h into a new dedicated header xenstored code no longer needs to #include xenctrl.h, thus removing any xenctrl reference from xenstored code. Please note that the last patch can be committed only after the related Mini-OS patch "config: add support for libxenmanage" has gone in AND the Mini-OS commit-id has been updated in Config.mk accordingly! The Mini-OS patch has been Acked already, so it can go in as soon as patch 6 of this series (the one introducing libxenmanage) has been committed. Changes in V2: - new patch 1 - former patch 5 mover earlier, now patch 2 (can go in without the rest of the series) - addressed comments Juergen Gross (7): xen/xsm: make getdomaininfo xsm dummy checks more stringent tools: add a dedicated header file for barrier definitions xen: add a domain unique id to each domain xen: add bitmap to indicate per-domain state changes xen: add new domctl get_changed_domain tools/libs: add a new libxenmanage library tools/xenstored: use new stable interface instead of libxenctrl stubdom/Makefile | 8 +- stubdom/mini-os.mk | 1 + tools/9pfsd/io.c | 5 +- tools/flask/policy/modules/dom0.te | 2 +- tools/flask/policy/modules/xen.if | 4 +- tools/flask/policy/modules/xenstore.te | 1 + tools/include/xen-barrier.h | 39 ++++++ tools/include/xenctrl.h | 28 +---- tools/include/xenmanage.h | 91 ++++++++++++++ tools/libs/Makefile | 1 + tools/libs/ctrl/Makefile | 2 +- tools/libs/manage/Makefile | 10 ++ tools/libs/manage/Makefile.common | 3 + tools/libs/manage/core.c | 166 +++++++++++++++++++++++++ tools/libs/manage/libxenmanage.map | 8 ++ tools/libs/uselibs.mk | 2 + tools/xenstored/Makefile | 2 +- tools/xenstored/Makefile.common | 2 +- tools/xenstored/core.h | 1 - tools/xenstored/domain.c | 52 +++----- tools/xenstored/lu.c | 1 + tools/xenstored/lu_daemon.c | 1 + xen/common/domain.c | 134 ++++++++++++++++++++ xen/common/domctl.c | 20 ++- xen/common/event_channel.c | 20 ++- xen/common/sysctl.c | 2 +- xen/include/public/domctl.h | 25 ++++ xen/include/xen/sched.h | 8 ++ xen/include/xsm/dummy.h | 10 +- xen/include/xsm/xsm.h | 6 + xen/xsm/dummy.c | 1 + xen/xsm/flask/hooks.c | 7 ++ xen/xsm/flask/policy/access_vectors | 2 + 33 files changed, 586 insertions(+), 79 deletions(-) create mode 100644 tools/include/xen-barrier.h create mode 100644 tools/include/xenmanage.h create mode 100644 tools/libs/manage/Makefile create mode 100644 tools/libs/manage/Makefile.common create mode 100644 tools/libs/manage/core.c create mode 100644 tools/libs/manage/libxenmanage.map -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 13:02:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 13:02:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850260.1264701 (Exim 4.92) (envelope-from ) id 1tJXyc-0003MK-Gi; Fri, 06 Dec 2024 13:02:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850260.1264701; Fri, 06 Dec 2024 13: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 1tJXyc-0003MD-DV; Fri, 06 Dec 2024 13:02:34 +0000 Received: by outflank-mailman (input) for mailman id 850260; Fri, 06 Dec 2024 13: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 1tJXya-0003LF-UR for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 13:02:32 +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 5965b8e2-b3d2-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 14:02:29 +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 6A46921186; Fri, 6 Dec 2024 13:02:29 +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 2ADE913647; Fri, 6 Dec 2024 13:02:29 +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 iSoBCeX1Ume7TgAAD6G6ig (envelope-from ); Fri, 06 Dec 2024 13:02: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: 5965b8e2-b3d2-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733490149; 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=6I/7sXWGYPIZHik0I/TGx8PR3rh5/YVoNt6JTXNC41g=; b=q4kwtdK6hNFrXHkyTcJNIw4I9/EGgXcCVd9hCJaEa72VinT42Pmf7I3cxdnIl8xdUu8RBx 0n2VY26EpxqDNmjePf93TWxuZHCoimRBhxSNXaiuJ3gCkknL6VLWEr8FB+IpAvY+00vSWS vYJwbvs+/bfFxDfDQL3avnam9pv2nuk= Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=q4kwtdK6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733490149; 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=6I/7sXWGYPIZHik0I/TGx8PR3rh5/YVoNt6JTXNC41g=; b=q4kwtdK6hNFrXHkyTcJNIw4I9/EGgXcCVd9hCJaEa72VinT42Pmf7I3cxdnIl8xdUu8RBx 0n2VY26EpxqDNmjePf93TWxuZHCoimRBhxSNXaiuJ3gCkknL6VLWEr8FB+IpAvY+00vSWS vYJwbvs+/bfFxDfDQL3avnam9pv2nuk= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , "Daniel P. Smith" Subject: [PATCH v2 1/7] xen/xsm: make getdomaininfo xsm dummy checks more stringent Date: Fri, 6 Dec 2024 14:02:15 +0100 Message-ID: <20241206130221.17773-2-jgross@suse.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241206130221.17773-1-jgross@suse.com> References: <20241206130221.17773-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 6A46921186 X-Spam-Score: -3.01 X-Rspamd-Action: no action X-Spamd-Result: default: False [-3.01 / 50.00]; BAYES_HAM(-3.00)[99.99%]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[suse.com:+]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; ASN(0.00)[asn:25478, ipnet:::/0, country:RU]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo] X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Spam-Flag: NO X-Spam-Level: Today the dummy XSM privilege checks for getdomaininfo are less stringent than possible: they basically rely on the general sysctl/domctl entry check to do all tests and then do the test with the XSM_HOOK privilege, which is an "allow all" default. Instead of XSM_HOOK use XSM_XS_PRIV, which is the privilege really wanted. Note that this test is still wider than the sysctl entry test, but there is now easy way to make both domctl and sysctl happy at the same time. Signed-off-by: Juergen Gross --- V2: - new patch --- xen/common/domctl.c | 2 +- xen/common/sysctl.c | 2 +- xen/include/xsm/dummy.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/common/domctl.c b/xen/common/domctl.c index ea16b75910..444e072fdc 100644 --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -539,7 +539,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) break; case XEN_DOMCTL_getdomaininfo: - ret = xsm_getdomaininfo(XSM_HOOK, d); + ret = xsm_getdomaininfo(XSM_XS_PRIV, d); if ( ret ) break; diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c index d02f44fe3a..c2d99ae12e 100644 --- a/xen/common/sysctl.c +++ b/xen/common/sysctl.c @@ -89,7 +89,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) if ( num_domains == op->u.getdomaininfolist.max_domains ) break; - if ( xsm_getdomaininfo(XSM_HOOK, d) ) + if ( xsm_getdomaininfo(XSM_XS_PRIV, d) ) continue; getdomaininfo(d, &info); diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h index 7956f27a29..f8a3c4b81e 100644 --- a/xen/include/xsm/dummy.h +++ b/xen/include/xsm/dummy.h @@ -137,7 +137,7 @@ static XSM_INLINE int cf_check xsm_domain_create( static XSM_INLINE int cf_check xsm_getdomaininfo( XSM_DEFAULT_ARG struct domain *d) { - XSM_ASSERT_ACTION(XSM_HOOK); + XSM_ASSERT_ACTION(XSM_XS_PRIV); return xsm_default_action(action, current->domain, d); } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 13:02:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 13:02:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850261.1264711 (Exim 4.92) (envelope-from ) id 1tJXyg-0003d3-NG; Fri, 06 Dec 2024 13:02:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850261.1264711; Fri, 06 Dec 2024 13: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 1tJXyg-0003cu-K7; Fri, 06 Dec 2024 13:02:38 +0000 Received: by outflank-mailman (input) for mailman id 850261; Fri, 06 Dec 2024 13:02: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 1tJXyf-00036p-92 for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 13:02:37 +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 5d7e2060-b3d2-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 14:02:36 +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 057F92115B; Fri, 6 Dec 2024 13:02:35 +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 D4B2813647; Fri, 6 Dec 2024 13:02:34 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id KW1iMur1UmfJTgAAD6G6ig (envelope-from ); Fri, 06 Dec 2024 13:02: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: 5d7e2060-b3d2-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733490156; 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=M6JXLGZ2C/uRkGXgqKjA/JAonnCDowTlDjW+0Nr5vSE=; b=WBi1dMfdkL1+kyYcJnkJlMMj0/wDZt+54N073axQ3CvPetlt27z9BjMupvpfbw8pOcUVGg wfPXuEGdz5xX9/qMJcxkxjBBk28LjEe3N4wcwtYTqhebXPPSgJ6KblYfWCFzEfVgVeV327 ECIsCkDN6fpHDIIoc8+ry4W9kr51mnM= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733490155; 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=M6JXLGZ2C/uRkGXgqKjA/JAonnCDowTlDjW+0Nr5vSE=; b=ZMKRBN7EYuzUyWlHLVV8fay6XG3Jnci5hCeUqqB6k7HctxFRQSqWRUdQyZM+PtWYfHEs5L goV4OA3NjiFvwm6KB3fMeQ7ijjVzFepXhBuPKRiA8VDG8uXTANiRIVTW9f5dNK2sPPeG2g YSDxbSts+7FHN4s3+X3VJL3pKGFjr48= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Anthony PERARD Subject: [PATCH v2 2/7] tools: add a dedicated header file for barrier definitions Date: Fri, 6 Dec 2024 14:02:16 +0100 Message-ID: <20241206130221.17773-3-jgross@suse.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241206130221.17773-1-jgross@suse.com> References: <20241206130221.17773-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Level: 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]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:email,suse.com:mid]; RCVD_TLS_ALL(0.00)[] X-Spam-Score: -2.80 X-Spam-Flag: NO Instead of having to include xenctrl.h for getting definitions of cpu barriers, add a dedicated header for that purpose. Switch the xen-9pfsd daemon to use the new header instead of xenctrl.h. This is in preparation of making Xenstore independent from libxenctrl. Signed-off-by: Juergen Gross --- V1: - new patch V2: - use SPDX - modify guard define (Anthony PERARD) - moved earlier in the series --- tools/9pfsd/io.c | 5 ++++- tools/include/xen-barrier.h | 39 +++++++++++++++++++++++++++++++++++++ tools/include/xenctrl.h | 28 +------------------------- tools/libs/ctrl/Makefile | 2 +- 4 files changed, 45 insertions(+), 29 deletions(-) create mode 100644 tools/include/xen-barrier.h diff --git a/tools/9pfsd/io.c b/tools/9pfsd/io.c index 468e0241f5..14cfcaf568 100644 --- a/tools/9pfsd/io.c +++ b/tools/9pfsd/io.c @@ -13,15 +13,18 @@ #include #include +#include #include +#include #include #include #include +#include #include #include #include #include -#include /* For cpu barriers. */ +#include #include #include "xen-9pfsd.h" diff --git a/tools/include/xen-barrier.h b/tools/include/xen-barrier.h new file mode 100644 index 0000000000..a716fb93cc --- /dev/null +++ b/tools/include/xen-barrier.h @@ -0,0 +1,39 @@ +/* SPDX-License-Identifier: LGPL-2.1 */ +/****************************************************************************** + * xen-barrier.h + * + * Definition of CPU barriers, part of libxenctrl. + * + * Copyright (c) 2003-2004, K A Fraser. + */ + +#ifndef XEN_BARRIER_H +#define XEN_BARRIER_H + +/* + * DEFINITIONS FOR CPU BARRIERS + */ + +#define xen_barrier() asm volatile ( "" : : : "memory") + +#if defined(__i386__) +#define xen_mb() asm volatile ( "lock addl $0, -4(%%esp)" ::: "memory" ) +#define xen_rmb() xen_barrier() +#define xen_wmb() xen_barrier() +#elif defined(__x86_64__) +#define xen_mb() asm volatile ( "lock addl $0, -32(%%rsp)" ::: "memory" ) +#define xen_rmb() xen_barrier() +#define xen_wmb() xen_barrier() +#elif defined(__arm__) +#define xen_mb() asm volatile ("dmb" : : : "memory") +#define xen_rmb() asm volatile ("dmb" : : : "memory") +#define xen_wmb() asm volatile ("dmb" : : : "memory") +#elif defined(__aarch64__) +#define xen_mb() asm volatile ("dmb sy" : : : "memory") +#define xen_rmb() asm volatile ("dmb sy" : : : "memory") +#define xen_wmb() asm volatile ("dmb sy" : : : "memory") +#else +#error "Define barriers" +#endif + +#endif /* XEN_BARRIER_H */ diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h index 29617585c5..ea57e9dbb9 100644 --- a/tools/include/xenctrl.h +++ b/tools/include/xenctrl.h @@ -48,6 +48,7 @@ #include #include "xentoollog.h" +#include "xen-barrier.h" #if defined(__i386__) || defined(__x86_64__) #include @@ -61,33 +62,6 @@ #define INVALID_MFN (~0UL) -/* - * DEFINITIONS FOR CPU BARRIERS - */ - -#define xen_barrier() asm volatile ( "" : : : "memory") - -#if defined(__i386__) -#define xen_mb() asm volatile ( "lock addl $0, -4(%%esp)" ::: "memory" ) -#define xen_rmb() xen_barrier() -#define xen_wmb() xen_barrier() -#elif defined(__x86_64__) -#define xen_mb() asm volatile ( "lock addl $0, -32(%%rsp)" ::: "memory" ) -#define xen_rmb() xen_barrier() -#define xen_wmb() xen_barrier() -#elif defined(__arm__) -#define xen_mb() asm volatile ("dmb" : : : "memory") -#define xen_rmb() asm volatile ("dmb" : : : "memory") -#define xen_wmb() asm volatile ("dmb" : : : "memory") -#elif defined(__aarch64__) -#define xen_mb() asm volatile ("dmb sy" : : : "memory") -#define xen_rmb() asm volatile ("dmb sy" : : : "memory") -#define xen_wmb() asm volatile ("dmb sy" : : : "memory") -#else -#error "Define barriers" -#endif - - #define XENCTRL_HAS_XC_INTERFACE 1 /* In Xen 4.0 and earlier, xc_interface_open and xc_evtchn_open would * both return ints being the file descriptor. In 4.1 and later, they diff --git a/tools/libs/ctrl/Makefile b/tools/libs/ctrl/Makefile index 5fe0bfad0c..acce8639d3 100644 --- a/tools/libs/ctrl/Makefile +++ b/tools/libs/ctrl/Makefile @@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk include Makefile.common -LIBHEADER := xenctrl.h xenctrl_compat.h +LIBHEADER := xenctrl.h xenctrl_compat.h xen-barrier.h PKG_CONFIG_FILE := xencontrol.pc PKG_CONFIG_NAME := Xencontrol -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 13:02:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 13:02:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850265.1264720 (Exim 4.92) (envelope-from ) id 1tJXyl-0003wb-Tj; Fri, 06 Dec 2024 13:02:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850265.1264720; Fri, 06 Dec 2024 13:02:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJXyl-0003wO-Qt; Fri, 06 Dec 2024 13:02:43 +0000 Received: by outflank-mailman (input) for mailman id 850265; Fri, 06 Dec 2024 13:02: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 1tJXyk-00036p-QZ for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 13:02:42 +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 60cf43f4-b3d2-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 14:02:42 +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 A5F7B2115B; Fri, 6 Dec 2024 13:02:40 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 69C7D13647; Fri, 6 Dec 2024 13:02:40 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id TjhjGPD1UmfdTgAAD6G6ig (envelope-from ); Fri, 06 Dec 2024 13:02: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: 60cf43f4-b3d2-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733490161; 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=FGgbqx71ndv5sBTrCP7+ufVgCN8ZAPJccnfCSLfUpqw=; b=FfeKbF348liT+jCxEDdX5HPMHtvulKMD2tYDD3pJSSF9i5+ulbRRX4iYiu0AaHQ3CSOA4R tFm6mskQfb5wgOYJmjzCx2h8X+CAmvbpT+nf+TF8uKtULLRESeF5zlPkPoNtYFrxBKZIqa RpolKqtCRtapMyqtNDGZd3egZvRVtPg= Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b="Ly55pB/H" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733490160; 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=FGgbqx71ndv5sBTrCP7+ufVgCN8ZAPJccnfCSLfUpqw=; b=Ly55pB/HxsCmMbK6Ky7T+ctjUh9B9yT2AkO4VqKFwpyjWRKTX4vchxaSXPPHdK6Rfv9a0p dv5gIN4Fb4w/WbrXcwIE0h1ln8xXNtaC036NayP5eB45o4EL5kjfXhLeHYfkmkHtocABgz EpZ3E85QHeaShslHXne8AynQjX9T6Bs= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Alejandro Vallejo Subject: [PATCH v2 3/7] xen: add a domain unique id to each domain Date: Fri, 6 Dec 2024 14:02:17 +0100 Message-ID: <20241206130221.17773-4-jgross@suse.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241206130221.17773-1-jgross@suse.com> References: <20241206130221.17773-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: A5F7B2115B X-Spam-Score: -3.01 X-Rspamd-Action: no action X-Spamd-Result: default: False [-3.01 / 50.00]; BAYES_HAM(-3.00)[99.99%]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[suse.com:+]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; ASN(0.00)[asn:25478, ipnet:::/0, country:RU]; DBL_BLOCKED_OPENRESOLVER(0.00)[cloud.com:email,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.com:dkim,suse.com:mid,suse.com:email,wikipedia.org:url] X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Spam-Flag: NO X-Spam-Level: Xenstore is referencing domains by their domid, but reuse of a domid can lead to the situation that Xenstore can't tell whether a domain with that domid has been deleted and created again without Xenstore noticing the domain is a new one now. Add a global domain creation unique id which is updated when creating a new domain, and store that value in struct domain of the new domain. The global unique id is initialized with the system time and updates are done via the xorshift algorithm which is used for pseudo random number generation, too (see https://en.wikipedia.org/wiki/Xorshift). Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Reviewed-by: Alejandro Vallejo --- V1: - make unique_id local to function (Jan Beulich) - add lock (Julien Grall) - add comment (Julien Grall) V2: - move reading unique_id into locked section (Julien Grall) - add comment (Alejandro Vallejo) --- xen/common/domain.c | 27 +++++++++++++++++++++++++++ xen/include/xen/sched.h | 3 +++ 2 files changed, 30 insertions(+) diff --git a/xen/common/domain.c b/xen/common/domain.c index 92263a4fbd..e33a0a5a21 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -562,6 +562,32 @@ static void _domain_destroy(struct domain *d) free_domain_struct(d); } +static uint64_t get_unique_id(void) +{ + static uint64_t unique_id; + static DEFINE_SPINLOCK(lock); + uint64_t x; + + spin_lock(&lock); + + x = unique_id ? : NOW(); + + /* + * Pseudo-randomize id in order to avoid consumers relying on sequence. + * Randomization algorithm has a period of 2^64 - 1. + * Unique id is not repeatable between resets and each id has the same + * lifetime as the domain it is associated with. + */ + x ^= x << 13; + x ^= x >> 7; + x ^= x << 17; + unique_id = x; + + spin_unlock(&lock); + + return x; +} + static int sanitise_domain_config(struct xen_domctl_createdomain *config) { bool hvm = config->flags & XEN_DOMCTL_CDF_hvm; @@ -654,6 +680,7 @@ struct domain *domain_create(domid_t domid, /* Sort out our idea of is_system_domain(). */ d->domain_id = domid; + d->unique_id = get_unique_id(); /* Holding CDF_* internal flags. */ d->cdf = flags; diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index 76e39378b3..711668e028 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -370,6 +370,9 @@ struct domain domid_t domain_id; unsigned int max_vcpus; + + uint64_t unique_id; /* Unique domain identifier */ + struct vcpu **vcpu; shared_info_t *shared_info; /* shared data area */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 13:02:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 13:02:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850267.1264731 (Exim 4.92) (envelope-from ) id 1tJXyr-0004Ls-9T; Fri, 06 Dec 2024 13:02:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850267.1264731; Fri, 06 Dec 2024 13:02: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 1tJXyr-0004LV-6E; Fri, 06 Dec 2024 13:02:49 +0000 Received: by outflank-mailman (input) for mailman id 850267; Fri, 06 Dec 2024 13:02: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 1tJXyq-0003LF-HJ for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 13:02:48 +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 6379ff92-b3d2-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 14:02:46 +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 529411F76B; Fri, 6 Dec 2024 13:02:46 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 1599C13647; Fri, 6 Dec 2024 13:02:46 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id zqHYA/b1UmflTgAAD6G6ig (envelope-from ); Fri, 06 Dec 2024 13:02: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: 6379ff92-b3d2-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733490166; 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=9YcuN8ElkBExKIjEcIVU7eWe7f3X3xjUNAlQzsns9+4=; b=pfNBc+fZ43MgD9kRknK5Qz+InZy5qejXzrftMh/e21Ofh9ySBSqPDesc1XkB31FFfS7Q2U oWrL7Vj9ggBAt+4YOi4KKF12QcyaU29Hi4DlmygC0rRAzRX2UZuZRCK1rfk4xmVpUQ31vL yn6hTiKmVHwaIkmJg5gznQzDik657Po= Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=pfNBc+fZ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733490166; 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=9YcuN8ElkBExKIjEcIVU7eWe7f3X3xjUNAlQzsns9+4=; b=pfNBc+fZ43MgD9kRknK5Qz+InZy5qejXzrftMh/e21Ofh9ySBSqPDesc1XkB31FFfS7Q2U oWrL7Vj9ggBAt+4YOi4KKF12QcyaU29Hi4DlmygC0rRAzRX2UZuZRCK1rfk4xmVpUQ31vL yn6hTiKmVHwaIkmJg5gznQzDik657Po= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v2 4/7] xen: add bitmap to indicate per-domain state changes Date: Fri, 6 Dec 2024 14:02:18 +0100 Message-ID: <20241206130221.17773-5-jgross@suse.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241206130221.17773-1-jgross@suse.com> References: <20241206130221.17773-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 529411F76B X-Spam-Level: X-Spamd-Result: default: False [-3.01 / 50.00]; BAYES_HAM(-3.00)[99.99%]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; MIME_TRACE(0.00)[0:+]; FUZZY_BLOCKED(0.00)[rspamd.com]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; TO_DN_SOME(0.00)[]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:25478, ipnet:::/0, country:RU]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[suse.com:+]; RCPT_COUNT_FIVE(0.00)[6]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:dkim,suse.com:mid,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns] X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Action: no action X-Spam-Score: -3.01 X-Spam-Flag: NO Add a bitmap with one bit per possible domid indicating the respective domain has changed its state (created, deleted, dying, crashed, shutdown). Registering the VIRQ_DOM_EXC event will result in setting the bits for all existing domains and resetting all other bits. Resetting a bit will be done in a future patch. This information is needed for Xenstore to keep track of all domains. Signed-off-by: Juergen Gross --- V2: - use DOMID_FIRST_RESERVED instead of DOMID_MASK + 1 (Jan Beulich) - use const (Jan Beulich) - move call of domain_reset_states() into evtchn_bind_virq() (Jan Beulich) - dynamically allocate dom_state_changed bitmap (Jan Beulich) --- xen/common/domain.c | 59 ++++++++++++++++++++++++++++++++++++++ xen/common/event_channel.c | 20 +++++++++++-- xen/include/xen/sched.h | 3 ++ 3 files changed, 79 insertions(+), 3 deletions(-) diff --git a/xen/common/domain.c b/xen/common/domain.c index e33a0a5a21..4e3a593a9d 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -138,6 +138,60 @@ bool __read_mostly vmtrace_available; bool __read_mostly vpmu_is_available; +static DEFINE_SPINLOCK(dom_state_changed_lock); +static unsigned long *dom_state_changed; + +int domain_init_states(void) +{ + const struct domain *d; + int rc = -ENOMEM; + + spin_lock(&dom_state_changed_lock); + + if ( dom_state_changed ) + bitmap_zero(dom_state_changed, DOMID_FIRST_RESERVED); + else + { + dom_state_changed = xzalloc_array(unsigned long, + BITS_TO_LONGS(DOMID_FIRST_RESERVED)); + if ( !dom_state_changed ) + goto unlock; + } + + rcu_read_lock(&domlist_read_lock); + + for_each_domain ( d ) + set_bit(d->domain_id, dom_state_changed); + + rcu_read_unlock(&domlist_read_lock); + + rc = 0; + + unlock: + spin_unlock(&dom_state_changed_lock); + + return rc; +} + +void domain_deinit_states(void) +{ + spin_lock(&dom_state_changed_lock); + + XFREE(dom_state_changed); + + spin_unlock(&dom_state_changed_lock); +} + +static void domain_changed_state(const struct domain *d) +{ + spin_lock(&dom_state_changed_lock); + + if ( dom_state_changed ) + set_bit(d->domain_id, dom_state_changed); + + spin_unlock(&dom_state_changed_lock); +} + static void __domain_finalise_shutdown(struct domain *d) { struct vcpu *v; @@ -152,6 +206,7 @@ static void __domain_finalise_shutdown(struct domain *d) return; d->is_shut_down = 1; + domain_changed_state(d); if ( (d->shutdown_code == SHUTDOWN_suspend) && d->suspend_evtchn ) evtchn_send(d, d->suspend_evtchn); else @@ -839,6 +894,7 @@ struct domain *domain_create(domid_t domid, */ domlist_insert(d); + domain_changed_state(d); memcpy(d->handle, config->handle, sizeof(d->handle)); return d; @@ -1104,6 +1160,7 @@ int domain_kill(struct domain *d) /* Mem event cleanup has to go here because the rings * have to be put before we call put_domain. */ vm_event_cleanup(d); + domain_changed_state(d); put_domain(d); send_global_virq(VIRQ_DOM_EXC); /* fallthrough */ @@ -1293,6 +1350,8 @@ static void cf_check complete_domain_destroy(struct rcu_head *head) xfree(d->vcpu); + domain_changed_state(d); + _domain_destroy(d); send_global_virq(VIRQ_DOM_EXC); diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c index 8db2ca4ba2..cd7bad68c0 100644 --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -485,20 +485,27 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port) if ( (v = domain_vcpu(d, vcpu)) == NULL ) return -ENOENT; + if ( virq == VIRQ_DOM_EXC ) + { + rc = domain_init_states(); + if ( rc ) + goto out; + } + write_lock(&d->event_lock); if ( read_atomic(&v->virq_to_evtchn[virq]) ) { rc = -EEXIST; gdprintk(XENLOG_WARNING, "EVTCHNOP failure: error %d\n", rc); - goto out; + goto unlock; } port = rc = evtchn_get_port(d, port); if ( rc < 0 ) { gdprintk(XENLOG_WARNING, "EVTCHNOP failure: error %d\n", rc); - goto out; + goto unlock; } rc = 0; @@ -524,9 +531,13 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port) */ write_atomic(&v->virq_to_evtchn[virq], port); - out: + unlock: write_unlock(&d->event_lock); + out: + if ( rc ) + domain_deinit_states(); + return rc; } @@ -730,6 +741,9 @@ int evtchn_close(struct domain *d1, int port1, bool guest) struct vcpu *v; unsigned long flags; + if ( chn1->u.virq == VIRQ_DOM_EXC ) + domain_deinit_states(); + v = d1->vcpu[virq_is_global(chn1->u.virq) ? 0 : chn1->notify_vcpu_id]; write_lock_irqsave(&v->virq_lock, flags); diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index 711668e028..16684bbaf9 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -800,6 +800,9 @@ void domain_resume(struct domain *d); int domain_soft_reset(struct domain *d, bool resuming); +int domain_init_states(void); +void domain_deinit_states(void); + int vcpu_start_shutdown_deferral(struct vcpu *v); void vcpu_end_shutdown_deferral(struct vcpu *v); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 13:02:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 13:02:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850272.1264742 (Exim 4.92) (envelope-from ) id 1tJXyw-0004qd-L5; Fri, 06 Dec 2024 13:02:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850272.1264742; Fri, 06 Dec 2024 13:02:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJXyw-0004qO-Eg; Fri, 06 Dec 2024 13:02:54 +0000 Received: by outflank-mailman (input) for mailman id 850272; Fri, 06 Dec 2024 13:02: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 1tJXyv-00036p-AH for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 13:02:53 +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 66e41601-b3d2-11ef-a0d5-8be0dac302b0; Fri, 06 Dec 2024 14:02:52 +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 10E281F397; Fri, 6 Dec 2024 13:02:52 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C008913647; Fri, 6 Dec 2024 13:02:51 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id Fkl+Lfv1UmfpTgAAD6G6ig (envelope-from ); Fri, 06 Dec 2024 13:02:51 +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: 66e41601-b3d2-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733490172; 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=2JSaXOp9FpeTqJT6d4dYOMtY2KIRtPosn3yQ8SlpOCU=; b=GmsKYDWQLaiIN2Z+9uYxcQenaHxzsidXPQ+D8O15m54pepe1zxguWeD8k/tRC1Tj+VYCS7 0ZL/mkMxEwuSTWNdby1I+fWvlJ7j8GbfLilntkDsOrQ/9akG6JpEV8u06EpyS0NYZZ/Lb9 jEbpOJoF8ul1d6d0ojgOXCyaDIjZ1oI= Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=GmsKYDWQ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733490172; 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=2JSaXOp9FpeTqJT6d4dYOMtY2KIRtPosn3yQ8SlpOCU=; b=GmsKYDWQLaiIN2Z+9uYxcQenaHxzsidXPQ+D8O15m54pepe1zxguWeD8k/tRC1Tj+VYCS7 0ZL/mkMxEwuSTWNdby1I+fWvlJ7j8GbfLilntkDsOrQ/9akG6JpEV8u06EpyS0NYZZ/Lb9 jEbpOJoF8ul1d6d0ojgOXCyaDIjZ1oI= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , "Daniel P. Smith" , Anthony PERARD , Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v2 5/7] xen: add new domctl get_changed_domain Date: Fri, 6 Dec 2024 14:02:19 +0100 Message-ID: <20241206130221.17773-6-jgross@suse.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241206130221.17773-1-jgross@suse.com> References: <20241206130221.17773-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 10E281F397 X-Spam-Level: X-Spamd-Result: default: False [-3.01 / 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)[]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[suse.com:+]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RCPT_COUNT_SEVEN(0.00)[8]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; ASN(0.00)[asn:25478, ipnet:::/0, country:RU]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:email,suse.com:dkim,suse.com:mid] X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Action: no action X-Spam-Score: -3.01 X-Spam-Flag: NO Add a new domctl sub-function to get data of a domain having changed state (this is needed by Xenstore). The returned state just contains the domid, the domain unique id, and some flags (existing, shutdown, dying). In order to enable Xenstore stubdom being built for multiple Xen versions, make this domctl stable. For stable domctls the interface_version is always 0. Signed-off-by: Juergen Gross --- V1: - use a domctl subop for the new interface (Jan Beulich) V2: - fix XSM hooks (Daniel P. Smith) - remove versioning of stable sub-ops (Jan Beulich) - use domctl.domain for retuning domid of a changed domain (Jan Beulich) - simplify locking in get_domain_state() (Jan Beulich) - undo stray change in event_channel.c (Jan Beulich) --- tools/flask/policy/modules/dom0.te | 2 +- tools/flask/policy/modules/xen.if | 4 +-- tools/flask/policy/modules/xenstore.te | 1 + xen/common/domain.c | 48 ++++++++++++++++++++++++++ xen/common/domctl.c | 18 +++++++++- xen/include/public/domctl.h | 25 ++++++++++++++ xen/include/xen/sched.h | 2 ++ xen/include/xsm/dummy.h | 8 +++++ xen/include/xsm/xsm.h | 6 ++++ xen/xsm/dummy.c | 1 + xen/xsm/flask/hooks.c | 7 ++++ xen/xsm/flask/policy/access_vectors | 2 ++ 12 files changed, 120 insertions(+), 4 deletions(-) diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te index 16b8c9646d..6043c01b12 100644 --- a/tools/flask/policy/modules/dom0.te +++ b/tools/flask/policy/modules/dom0.te @@ -40,7 +40,7 @@ allow dom0_t dom0_t:domain { }; allow dom0_t dom0_t:domain2 { set_cpu_policy gettsc settsc setscheduler set_vnumainfo - get_vnumainfo psr_cmt_op psr_alloc get_cpu_policy + get_vnumainfo psr_cmt_op psr_alloc get_cpu_policy get_domain_state }; allow dom0_t dom0_t:resource { add remove }; diff --git a/tools/flask/policy/modules/xen.if b/tools/flask/policy/modules/xen.if index 11c1562aa5..2e06f3ed94 100644 --- a/tools/flask/policy/modules/xen.if +++ b/tools/flask/policy/modules/xen.if @@ -54,7 +54,7 @@ define(`create_domain_common', ` allow $1 $2:domain2 { set_cpu_policy settsc setscheduler setclaim set_vnumainfo get_vnumainfo cacheflush psr_cmt_op psr_alloc soft_reset - resource_map get_cpu_policy }; + resource_map get_cpu_policy get_domain_state }; allow $1 $2:security check_context; allow $1 $2:shadow enable; allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp }; @@ -94,7 +94,7 @@ define(`manage_domain', ` getaddrsize pause unpause trigger shutdown destroy setaffinity setdomainmaxmem getscheduler resume setpodtarget getpodtarget getpagingmempool setpagingmempool }; - allow $1 $2:domain2 set_vnumainfo; + allow $1 $2:domain2 { set_vnumainfo get_domain_state }; ') # migrate_domain_out(priv, target) diff --git a/tools/flask/policy/modules/xenstore.te b/tools/flask/policy/modules/xenstore.te index 519566ab81..49de53ebe2 100644 --- a/tools/flask/policy/modules/xenstore.te +++ b/tools/flask/policy/modules/xenstore.te @@ -13,6 +13,7 @@ allow dom0_t xenstore_t:domain set_virq_handler; allow xenstore_t xen_t:xen writeconsole; # Xenstore queries domaininfo on all domains allow xenstore_t domain_type:domain getdomaininfo; +allow xenstore_t domain_type:domain2 get_domain_state; # As a shortcut, the following 3 rules are used instead of adding a domain_comms # rule between xenstore_t and every domain type that talks to xenstore diff --git a/xen/common/domain.c b/xen/common/domain.c index 4e3a593a9d..2c028c629e 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -192,6 +192,54 @@ static void domain_changed_state(const struct domain *d) spin_unlock(&dom_state_changed_lock); } +static void set_domain_state_info(struct xen_domctl_get_domain_state *info, + const struct domain *d) +{ + info->state = XEN_DOMCTL_GETDOMSTATE_STATE_EXIST; + if ( d->is_shut_down ) + info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN; + if ( d->is_dying == DOMDYING_dead ) + info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DYING; + info->unique_id = d->unique_id; +} + +int get_domain_state(struct xen_domctl_get_domain_state *info, struct domain *d, + domid_t *domid) +{ + unsigned int dom; + + memset(info, 0, sizeof(*info)); + + if ( d ) + { + set_domain_state_info(info, d); + + return 0; + } + + while ( (dom = find_first_bit(dom_state_changed, DOMID_MASK + 1)) < + DOMID_FIRST_RESERVED ) + { + if ( test_and_clear_bit(dom, dom_state_changed) ) + { + *domid = dom; + + d = rcu_lock_domain_by_id(dom); + + if ( d ) + { + set_domain_state_info(info, d); + + rcu_unlock_domain(d); + } + + return 0; + } + } + + return -ENOENT; +} + static void __domain_finalise_shutdown(struct domain *d) { struct vcpu *v; diff --git a/xen/common/domctl.c b/xen/common/domctl.c index 444e072fdc..802bd7596e 100644 --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -278,6 +278,11 @@ static struct vnuma_info *vnuma_init(const struct xen_domctl_vnuma *uinfo, return ERR_PTR(ret); } +static bool is_stable_domctl(uint32_t cmd) +{ + return cmd == XEN_DOMCTL_get_domain_state; +} + long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) { long ret = 0; @@ -288,7 +293,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) if ( copy_from_guest(op, u_domctl, 1) ) return -EFAULT; - if ( op->interface_version != XEN_DOMCTL_INTERFACE_VERSION ) + if ( op->interface_version != + (is_stable_domctl(op->cmd) ? 0 : XEN_DOMCTL_INTERFACE_VERSION) ) return -EACCES; switch ( op->cmd ) @@ -309,6 +315,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) fallthrough; case XEN_DOMCTL_test_assign_device: case XEN_DOMCTL_vm_event_op: + case XEN_DOMCTL_get_domain_state: if ( op->domain == DOMID_INVALID ) { d = NULL; @@ -866,6 +873,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) __HYPERVISOR_domctl, "h", u_domctl); break; + case XEN_DOMCTL_get_domain_state: + ret = xsm_get_domain_state(XSM_XS_PRIV, d); + if ( ret ) + break; + + copyback = 1; + ret = get_domain_state(&op->u.get_domain_state, d, &op->domain); + break; + default: ret = arch_do_domctl(op, d, u_domctl); break; diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h index 353f831e40..b8470bda54 100644 --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -28,6 +28,7 @@ * Pure additions (e.g. new sub-commands) or compatible interface changes * (e.g. adding semantics to 0-checked input fields or data to zeroed output * fields) don't require a change of the version. + * Stable ops are NOT covered by XEN_DOMCTL_INTERFACE_VERSION! * * Last version bump: Xen 4.19 */ @@ -1236,7 +1237,29 @@ struct xen_domctl_dt_overlay { }; #endif +/* + * XEN_DOMCTL_get_domain_state (stable interface) + * + * Get state information of a domain. + * + * In case domain is DOMID_INVALID, return information about a domain having + * changed state and reset the state change indicator for that domain. This + * function is usable only by a domain having registered the VIRQ_DOM_EXC + * event (normally Xenstore). + * NB. xen_domctl.domain is an IN/OUT parameter for this operation. + */ +struct xen_domctl_get_domain_state { + uint16_t state; +#define XEN_DOMCTL_GETDOMSTATE_STATE_EXIST 0x0001 /* Domain is existing. */ +#define XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN 0x0002 /* Shutdown finished. */ +#define XEN_DOMCTL_GETDOMSTATE_STATE_DYING 0x0004 /* Domain dying. */ + uint16_t pad0; + uint32_t pad1; /* Returned as 0. */ + uint64_t unique_id; /* Unique domain identifier. */ +}; + struct xen_domctl { +/* Stable domctl ops: interface_version is required to be 0. */ uint32_t cmd; #define XEN_DOMCTL_createdomain 1 #define XEN_DOMCTL_destroydomain 2 @@ -1325,6 +1348,7 @@ struct xen_domctl { #define XEN_DOMCTL_set_paging_mempool_size 86 #define XEN_DOMCTL_dt_overlay 87 #define XEN_DOMCTL_gsi_permission 88 +#define XEN_DOMCTL_get_domain_state 89 /* stable interface */ #define XEN_DOMCTL_gdbsx_guestmemio 1000 #define XEN_DOMCTL_gdbsx_pausevcpu 1001 #define XEN_DOMCTL_gdbsx_unpausevcpu 1002 @@ -1391,6 +1415,7 @@ struct xen_domctl { #if defined(__arm__) || defined(__aarch64__) struct xen_domctl_dt_overlay dt_overlay; #endif + struct xen_domctl_get_domain_state get_domain_state; uint8_t pad[128]; } u; }; diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index 16684bbaf9..5e9858c3ba 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -802,6 +802,8 @@ int domain_soft_reset(struct domain *d, bool resuming); int domain_init_states(void); void domain_deinit_states(void); +int get_domain_state(struct xen_domctl_get_domain_state *info, + struct domain *d, domid_t *domid); int vcpu_start_shutdown_deferral(struct vcpu *v); void vcpu_end_shutdown_deferral(struct vcpu *v); diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h index f8a3c4b81e..a1a5bb60e9 100644 --- a/xen/include/xsm/dummy.h +++ b/xen/include/xsm/dummy.h @@ -173,6 +173,7 @@ static XSM_INLINE int cf_check xsm_domctl( case XEN_DOMCTL_unbind_pt_irq: return xsm_default_action(XSM_DM_PRIV, current->domain, d); case XEN_DOMCTL_getdomaininfo: + case XEN_DOMCTL_get_domain_state: return xsm_default_action(XSM_XS_PRIV, current->domain, d); default: return xsm_default_action(XSM_PRIV, current->domain, d); @@ -815,6 +816,13 @@ static XSM_INLINE int cf_check xsm_argo_send( #endif /* CONFIG_ARGO */ +static XSM_INLINE int cf_check xsm_get_domain_state( + XSM_DEFAULT_ARG struct domain *d) +{ + XSM_ASSERT_ACTION(XSM_XS_PRIV); + return xsm_default_action(action, current->domain, d); +} + #include static XSM_INLINE int cf_check xsm_xen_version(XSM_DEFAULT_ARG uint32_t op) { diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h index 4dbff9d866..0689bf5c9f 100644 --- a/xen/include/xsm/xsm.h +++ b/xen/include/xsm/xsm.h @@ -200,6 +200,7 @@ struct xsm_ops { int (*argo_register_any_source)(const struct domain *d); int (*argo_send)(const struct domain *d, const struct domain *t); #endif + int (*get_domain_state)(struct domain *d); }; #ifdef CONFIG_XSM @@ -774,6 +775,11 @@ static inline int xsm_argo_send(const struct domain *d, const struct domain *t) #endif /* CONFIG_ARGO */ +static inline int xsm_get_domain_state(struct domain *d) +{ + return alternative_call(xsm_ops.get_domain_state, d); +} + #endif /* XSM_NO_WRAPPERS */ #ifdef CONFIG_MULTIBOOT diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c index e6ffa948f7..ce6fbdc6c5 100644 --- a/xen/xsm/dummy.c +++ b/xen/xsm/dummy.c @@ -148,6 +148,7 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = { .argo_register_any_source = xsm_argo_register_any_source, .argo_send = xsm_argo_send, #endif + .get_domain_state = xsm_get_domain_state, }; void __init xsm_fixup_ops(struct xsm_ops *ops) diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c index a79474ffe4..e110846ad9 100644 --- a/xen/xsm/flask/hooks.c +++ b/xen/xsm/flask/hooks.c @@ -688,6 +688,7 @@ static int cf_check flask_domctl(struct domain *d, unsigned int cmd, case XEN_DOMCTL_memory_mapping: case XEN_DOMCTL_set_target: case XEN_DOMCTL_vm_event_op: + case XEN_DOMCTL_get_domain_state: /* These have individual XSM hooks (arch/../domctl.c) */ case XEN_DOMCTL_bind_pt_irq: @@ -1856,6 +1857,11 @@ static int cf_check flask_argo_send( #endif +static int cf_check flask_get_domain_state(struct domain *d) +{ + return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GET_DOMAIN_STATE); +} + static const struct xsm_ops __initconst_cf_clobber flask_ops = { .set_system_active = flask_set_system_active, .security_domaininfo = flask_security_domaininfo, @@ -1992,6 +1998,7 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = { .argo_register_any_source = flask_argo_register_any_source, .argo_send = flask_argo_send, #endif + .get_domain_state = flask_get_domain_state, }; const struct xsm_ops *__init flask_init( diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors index a35e3d4c51..c9a8eeda4e 100644 --- a/xen/xsm/flask/policy/access_vectors +++ b/xen/xsm/flask/policy/access_vectors @@ -251,6 +251,8 @@ class domain2 resource_map # XEN_DOMCTL_get_cpu_policy get_cpu_policy +# XEN_DOMCTL_get_domain_state + get_domain_state } # Similar to class domain, but primarily contains domctls related to HVM domains -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 13:03:02 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 13:03:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850284.1264751 (Exim 4.92) (envelope-from ) id 1tJXz3-0005PD-QK; Fri, 06 Dec 2024 13:03:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850284.1264751; Fri, 06 Dec 2024 13:03: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 1tJXz3-0005P4-NH; Fri, 06 Dec 2024 13:03:01 +0000 Received: by outflank-mailman (input) for mailman id 850284; Fri, 06 Dec 2024 13:03: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 1tJXz1-0003LF-Uc for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 13:03:00 +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 6a4365cd-b3d2-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 14:02:58 +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 A06BD1F45A; Fri, 6 Dec 2024 13:02:57 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 771AB13647; Fri, 6 Dec 2024 13:02:57 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id keyNGwH2Umf0TgAAD6G6ig (envelope-from ); Fri, 06 Dec 2024 13:02: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: 6a4365cd-b3d2-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733490177; 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=njZByj3Fv1skLzdzIhzzAQM2aH7X5x2SGpdSn9+/xKI=; b=ULzM0uiuBBp8pklsF9UJEmbBykeUPwhJrR8nwwSmezkEnR4HZuJfFab7385gIByHv+7DNb KNiEahDxEs16IDOisiTajFs6njtJh4NBfqykH2GiVc0oplRQneSk0+PohfCenwJ8MsYI/V H4ElsS5IrRorATD+Y0cOc1XThKL0IzM= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733490177; 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=njZByj3Fv1skLzdzIhzzAQM2aH7X5x2SGpdSn9+/xKI=; b=ULzM0uiuBBp8pklsF9UJEmbBykeUPwhJrR8nwwSmezkEnR4HZuJfFab7385gIByHv+7DNb KNiEahDxEs16IDOisiTajFs6njtJh4NBfqykH2GiVc0oplRQneSk0+PohfCenwJ8MsYI/V H4ElsS5IrRorATD+Y0cOc1XThKL0IzM= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Anthony PERARD Subject: [PATCH v2 6/7] tools/libs: add a new libxenmanage library Date: Fri, 6 Dec 2024 14:02:20 +0100 Message-ID: <20241206130221.17773-7-jgross@suse.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241206130221.17773-1-jgross@suse.com> References: <20241206130221.17773-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.80 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]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid,suse.com:email]; RCVD_TLS_ALL(0.00)[] X-Spam-Flag: NO X-Spam-Level: In order to have a stable interface in user land for using stable domctl and possibly later sysctl interfaces, add a new library libxenmanage. Signed-off-by: Juergen Gross --- V1: - new patch V2: - define __XEN_TOOLS__ via Makefile (Anthony PERARD) - use SPDX in header file (Anthony PERARD) - change function name to xenmanage_poll_changed_domain() (Anthony PERARD) - add short library description (Anthony PERARD) - narrow scope of xen_domctl_get_domain_state pointer (Anthony PERARD) --- tools/include/xenmanage.h | 91 ++++++++++++++++ tools/libs/Makefile | 1 + tools/libs/manage/Makefile | 10 ++ tools/libs/manage/Makefile.common | 3 + tools/libs/manage/core.c | 166 +++++++++++++++++++++++++++++ tools/libs/manage/libxenmanage.map | 8 ++ tools/libs/uselibs.mk | 2 + 7 files changed, 281 insertions(+) create mode 100644 tools/include/xenmanage.h create mode 100644 tools/libs/manage/Makefile create mode 100644 tools/libs/manage/Makefile.common create mode 100644 tools/libs/manage/core.c create mode 100644 tools/libs/manage/libxenmanage.map diff --git a/tools/include/xenmanage.h b/tools/include/xenmanage.h new file mode 100644 index 0000000000..280b3840f9 --- /dev/null +++ b/tools/include/xenmanage.h @@ -0,0 +1,91 @@ +/* SPDX-License-Identifier: LGPL-2.1 */ +/* + * Copyright (c) 2024 SUSE Software Solutions Germany GmbH + * + * Interfaces of libxenmanage. + * + * libxenmanage provides management functions for the host using stable + * hypercall interfaces. + */ +#ifndef XENMANAGE_H +#define XENMANAGE_H + +#include + +/* Avoid the need to #include */ +struct xentoollog_logger; + +typedef struct xenmanage_handle xenmanage_handle; + +/* + * Open libxenmanage. + * + * Get a handle of the xenmanage library. The handle is required for all + * further operations of the library. + * Parameters: + * logger: Logging function to use. If NULL logging is done to stderr. + * open_flags: Only 0 supported. + * Return value: Handle or NULL if error. + */ +xenmanage_handle *xenmanage_open(struct xentoollog_logger *logger, + unsigned int open_flags); + +/* + * Close libxenmanage. + * + * Return a handle of the xenmanage library. + * Parameters: + * hdl: Handle obtained by xenmanage_open(). + * Return value: always 0. + */ +int xenmanage_close(xenmanage_handle *hdl); + +#define XENMANAGE_GETDOMSTATE_STATE_EXIST 0x0001 /* Domain is existing. */ +#define XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN 0x0002 /* Shutdown finished. */ +#define XENMANAGE_GETDOMSTATE_STATE_DYING 0x0004 /* Domain dying. */ + +/* + * Return state information of an existing domain. + * + * Returns the domain state and unique id of the given domain. + * Parameters: + * hdl: handle returned by xenmanage_open() + * domid: domain id of the domain to get the information for + * state: where to store the state (XENMANAGE_GETDOMSTATE_STATE_ flags, + * nothing stored if NULL) + * unique_id: where to store the unique id of the domain (nothing stored if + * NULL) + * Return value: 0 if information was stored, -1 else (errno is set) + */ +int xenmanage_get_domain_info(xenmanage_handle *hdl, unsigned int domid, + unsigned int *state, uint64_t *unique_id); + +/* + * Return information of a domain having changed state recently. + * + * Returns the domain id, state and unique id of a domain having changed + * state (any of the state bits was modified) since the last time information + * for that domain was returned by this function. Only usable by callers who + * have registered the VIRQ_DOM_EXC event (normally Xenstore). + * Parameters: + * hdl: handle returned by xenmanage_open() + * domid: where to store the domid of the domain (not NULL) + * state: where to store the state (XENMANAGE_GETDOMSTATE_STATE_ flags, + * nothing stored if NULL) + * unique_id: where to store the unique id of the domain (nothing stored if + * NULL) + * Return value: 0 if information was stored, -1 else (errno is set) + */ +int xenmanage_poll_changed_domain(xenmanage_handle *hdl, unsigned int *domid, + unsigned int *state, uint64_t *unique_id); +#endif /* XENMANAGE_H */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/tools/libs/Makefile b/tools/libs/Makefile index 1afcd12e2b..d39516c1b3 100644 --- a/tools/libs/Makefile +++ b/tools/libs/Makefile @@ -12,6 +12,7 @@ SUBDIRS-y += devicemodel SUBDIRS-y += ctrl SUBDIRS-y += guest SUBDIRS-y += hypfs +SUBDIRS-y += manage SUBDIRS-y += store SUBDIRS-y += stat SUBDIRS-$(CONFIG_Linux) += vchan diff --git a/tools/libs/manage/Makefile b/tools/libs/manage/Makefile new file mode 100644 index 0000000000..dbfe70d259 --- /dev/null +++ b/tools/libs/manage/Makefile @@ -0,0 +1,10 @@ +XEN_ROOT = $(CURDIR)/../../.. +include $(XEN_ROOT)/tools/Rules.mk + +MAJOR = 1 +MINOR = 0 +version-script := libxenmanage.map + +include Makefile.common + +include $(XEN_ROOT)/tools/libs/libs.mk diff --git a/tools/libs/manage/Makefile.common b/tools/libs/manage/Makefile.common new file mode 100644 index 0000000000..533ba30fba --- /dev/null +++ b/tools/libs/manage/Makefile.common @@ -0,0 +1,3 @@ +CFLAGS += -D__XEN_TOOLS__ + +OBJS-y += core.o diff --git a/tools/libs/manage/core.c b/tools/libs/manage/core.c new file mode 100644 index 0000000000..c0dc74815b --- /dev/null +++ b/tools/libs/manage/core.c @@ -0,0 +1,166 @@ +/* + * Copyright (c) 2024 SUSE Software Solutions Germany GmbH + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; + * version 2.1 of the License. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; If not, see . + */ + +#define _GNU_SOURCE + +#include +#include +#include + +#include +#include +#include +#include + +#include +#include + +struct xenmanage_handle { + xentoollog_logger *logger, *logger_tofree; + unsigned int flags; + xencall_handle *xcall; +}; + +xenmanage_handle *xenmanage_open(xentoollog_logger *logger, + unsigned open_flags) +{ + xenmanage_handle *hdl = calloc(1, sizeof(*hdl)); + int saved_errno; + + if ( !hdl ) + return NULL; + + if ( open_flags ) + { + errno = EINVAL; + goto err; + } + + hdl->flags = open_flags; + hdl->logger = logger; + hdl->logger_tofree = NULL; + + if ( !hdl->logger ) + { + hdl->logger = hdl->logger_tofree = + (xentoollog_logger *) + xtl_createlogger_stdiostream(stderr, XTL_PROGRESS, 0); + if ( !hdl->logger ) + goto err; + } + + hdl->xcall = xencall_open(hdl->logger, 0); + if ( !hdl->xcall ) + goto err; + + return hdl; + +err: + saved_errno = errno; + xenmanage_close(hdl); + errno = saved_errno; + + return NULL; +} + +int xenmanage_close(xenmanage_handle *hdl) +{ + if ( !hdl ) + return 0; + + xencall_close(hdl->xcall); + xtl_logger_destroy(hdl->logger_tofree); + free(hdl); + return 0; +} + +static int xenmanage_do_domctl_get_domain_state(xenmanage_handle *hdl, + unsigned int domid_in, + unsigned int *domid_out, + unsigned int *state, + uint64_t *unique_id) +{ + struct xen_domctl *buf; + int saved_errno; + int ret; + + buf = xencall_alloc_buffer(hdl->xcall, sizeof(*buf)); + if ( !buf ) + { + errno = ENOMEM; + return -1; + } + + memset(buf, 0, sizeof(*buf)); + + buf->cmd = XEN_DOMCTL_get_domain_state; + buf->domain = domid_in; + + ret = xencall1(hdl->xcall, __HYPERVISOR_domctl, (unsigned long)buf); + saved_errno = errno; + if ( !ret ) + { + struct xen_domctl_get_domain_state *st = &buf->u.get_domain_state; + + if ( domid_out ) + *domid_out = buf->domain; + if ( state ) + { + *state = 0; + if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_EXIST ) + *state |= XENMANAGE_GETDOMSTATE_STATE_EXIST; + if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN ) + *state |= XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN; + if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_DYING ) + *state |= XENMANAGE_GETDOMSTATE_STATE_DYING; + } + if ( unique_id ) + *unique_id = st->unique_id; + } + + xencall_free_buffer(hdl->xcall, buf); + + errno = saved_errno; + + return ret; +} + +int xenmanage_get_domain_info(xenmanage_handle *hdl, unsigned int domid, + unsigned int *state, uint64_t *unique_id) +{ + if ( !hdl || domid >= DOMID_FIRST_RESERVED ) + { + errno = EINVAL; + return -1; + } + + return xenmanage_do_domctl_get_domain_state(hdl, domid, NULL, state, + unique_id); +} + +int xenmanage_poll_changed_domain(xenmanage_handle *hdl, unsigned int *domid, + unsigned int *state, uint64_t *unique_id) +{ + if ( !hdl || !domid ) + { + errno = EINVAL; + return -1; + } + + return xenmanage_do_domctl_get_domain_state(hdl, DOMID_INVALID, domid, + state, unique_id); +} diff --git a/tools/libs/manage/libxenmanage.map b/tools/libs/manage/libxenmanage.map new file mode 100644 index 0000000000..64c793e603 --- /dev/null +++ b/tools/libs/manage/libxenmanage.map @@ -0,0 +1,8 @@ +VERS_1.0 { + global: + xenmanage_open; + xenmanage_close; + xenmanage_get_domain_info; + xenmanage_poll_changed_domain; + local: *; /* Do not expose anything by default */ +}; diff --git a/tools/libs/uselibs.mk b/tools/libs/uselibs.mk index 7aa8d83e06..c0a234cfec 100644 --- a/tools/libs/uselibs.mk +++ b/tools/libs/uselibs.mk @@ -16,6 +16,8 @@ LIBS_LIBS += devicemodel USELIBS_devicemodel := toollog toolcore call LIBS_LIBS += hypfs USELIBS_hypfs := toollog toolcore call +LIBS_LIBS += manage +USELIBS_manage := toollog toolcore call LIBS_LIBS += ctrl USELIBS_ctrl := toollog call evtchn gnttab foreignmemory devicemodel LIBS_LIBS += guest -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 13:05:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 13:05:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850303.1264761 (Exim 4.92) (envelope-from ) id 1tJY1e-00072l-EC; Fri, 06 Dec 2024 13:05:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850303.1264761; Fri, 06 Dec 2024 13:05: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 1tJY1e-00072e-Ao; Fri, 06 Dec 2024 13:05:42 +0000 Received: by outflank-mailman (input) for mailman id 850303; Fri, 06 Dec 2024 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 1tJY1c-00072T-TE for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 13:05:40 +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 c90d9514-b3d2-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 14:05:38 +0100 (CET) Received: by mx.zohomail.com with SMTPS id 1733490333542143.7719942594082; Fri, 6 Dec 2024 05:05: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: c90d9514-b3d2-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; t=1733490335; cv=none; d=zohomail.com; s=zohoarc; b=KoaIfVbklUbOk7hw23ynvy17UZqkFvpy3WM8NGPjJ2WePiCRnYXox89EJVgCLnp2pmYJV5LnZ8+NU1iCOBBTw/CMZVj0ffEWzDH+Pm9qdcM6rIZ92rK14PfHOD27pYLiUANxSXHcIRUjkVoYPcE6TK4bPyPv/68JneO4YafvR3I= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1733490335; 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=fJGFNkT53OGu1EkwfQiiz2VIKpzaEEezUdD09cwRUbE=; b=XM376aTAvH3xh0YzZNLrstO3YWyQTBk5lTWcq3ocKUVLshXuhFL/EeUK8F9AHqnKvPovGq5IKnH4RggSVpfkO2Ozl5asecwLwRQedgGEsR0hCQI8E6wrCtR6EGXYikqjNKmGSF1vF4JBDzHqY7U/0wIcE4H4LKkiyhy8bTJ8JCg= 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=1733490335; s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=fJGFNkT53OGu1EkwfQiiz2VIKpzaEEezUdD09cwRUbE=; b=rxq72BsQECD9oNl3U0nmgPe9RwlmLE+1SENOW2Dz05pkvy7nlgjjAafDXvZdkG5N cv6FvsltgMg/GuQx7AtUqGkezeo8pizTSP/ZUMIWNlBjMZHQJ5sZwEli912E0RbwC+z jUd5oCC1KQbFbXtNWXBrc35gO+irM5ubfBwUh+Y8= Message-ID: Date: Fri, 6 Dec 2024 08:05:32 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/7] xen/xsm: make getdomaininfo xsm dummy checks more stringent To: Juergen Gross , xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini References: <20241206130221.17773-1-jgross@suse.com> <20241206130221.17773-2-jgross@suse.com> Content-Language: en-US From: "Daniel P. Smith" In-Reply-To: <20241206130221.17773-2-jgross@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ZohoMailClient: External On 12/6/24 08:02, Juergen Gross wrote: > Today the dummy XSM privilege checks for getdomaininfo are less > stringent than possible: they basically rely on the general > sysctl/domctl entry check to do all tests and then do the test with > the XSM_HOOK privilege, which is an "allow all" default. > > Instead of XSM_HOOK use XSM_XS_PRIV, which is the privilege really > wanted. Note that this test is still wider than the sysctl entry test, > but there is now easy way to make both domctl and sysctl happy at the > same time. > > Signed-off-by: Juergen Gross Acked-by: Daniel P. Smith From xen-devel-bounces@lists.xenproject.org Fri Dec 06 13:10:47 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 13:10:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850335.1264770 (Exim 4.92) (envelope-from ) id 1tJY6V-0000GK-V0; Fri, 06 Dec 2024 13:10:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850335.1264770; Fri, 06 Dec 2024 13:10:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJY6V-0000GD-S4; Fri, 06 Dec 2024 13:10:43 +0000 Received: by outflank-mailman (input) for mailman id 850335; Fri, 06 Dec 2024 13:10: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 1tJXz7-0003LF-RK for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 13:03:05 +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 6d9ea9bc-b3d2-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 14:03:03 +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 46FEA210F9; Fri, 6 Dec 2024 13:03:03 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 0EB9F13647; Fri, 6 Dec 2024 13:03:03 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id oa3AAQf2Umf6TgAAD6G6ig (envelope-from ); Fri, 06 Dec 2024 13:03: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: 6d9ea9bc-b3d2-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733490183; 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=bhwLwinhL41mvl1g8G0nYehYCkjaRw7nKPlhqQuc6NM=; b=FLR6VpByAlVajvDhzk3Ez6z3P+bPf1RsGMx5G/NTPPbRoILd5yljq/NS97tmO5WPtzcoTG 8m6pSZQcjIP1ZauFVM74wtanTclo3yuPoheR1VM0rCJtRjnxqo8yd2znuGVf9vGv7Hdg+H zoJ79rJpLkry5CpHEosp3JXxElGdeRg= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1733490183; 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=bhwLwinhL41mvl1g8G0nYehYCkjaRw7nKPlhqQuc6NM=; b=FLR6VpByAlVajvDhzk3Ez6z3P+bPf1RsGMx5G/NTPPbRoILd5yljq/NS97tmO5WPtzcoTG 8m6pSZQcjIP1ZauFVM74wtanTclo3yuPoheR1VM0rCJtRjnxqo8yd2znuGVf9vGv7Hdg+H zoJ79rJpLkry5CpHEosp3JXxElGdeRg= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Anthony PERARD , Samuel Thibault , Julien Grall Subject: [PATCH v2 7/7] tools/xenstored: use new stable interface instead of libxenctrl Date: Fri, 6 Dec 2024 14:02:21 +0100 Message-ID: <20241206130221.17773-8-jgross@suse.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241206130221.17773-1-jgross@suse.com> References: <20241206130221.17773-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.80 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]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid,suse.com:email]; RCVD_TLS_ALL(0.00)[] X-Spam-Flag: NO X-Spam-Level: Replace the current use of the unstable xc_domain_getinfo_single() interface with the stable domctl XEN_DOMCTL_get_domain_state call via the new libxenmanage library. This will remove the last usage of libxenctrl by Xenstore, so update the library dependencies accordingly. For now only do a direct replacement without using the functionality of obtaining information about domains having changed the state. Signed-off-by: Juergen Gross --- V1: - use library instead of direct hypercall, only replace current libxenctrl use case Please note that this patch can be committed only after the related Mini-OS patch "config: add support for libxenmanage" has gone in AND the Mini-OS commit-id has been updated in Config.mk accordingly! Signed-off-by: Juergen Gross --- stubdom/Makefile | 8 ++--- stubdom/mini-os.mk | 1 + tools/xenstored/Makefile | 2 +- tools/xenstored/Makefile.common | 2 +- tools/xenstored/core.h | 1 - tools/xenstored/domain.c | 52 ++++++++++++--------------------- tools/xenstored/lu.c | 1 + tools/xenstored/lu_daemon.c | 1 + 8 files changed, 28 insertions(+), 40 deletions(-) diff --git a/stubdom/Makefile b/stubdom/Makefile index 2a81af28a1..ca800b243c 100644 --- a/stubdom/Makefile +++ b/stubdom/Makefile @@ -307,7 +307,7 @@ endif # libraries under tools/libs ####### -STUB_LIBS := toolcore toollog evtchn gnttab call foreignmemory devicemodel ctrl guest +STUB_LIBS := toolcore toollog evtchn gnttab call foreignmemory devicemodel ctrl guest manage LIBDEP_guest := cross-zlib @@ -465,7 +465,7 @@ grub: cross-polarssl grub-upstream $(CROSS_ROOT) grub-$(XEN_TARGET_ARCH)-minios- # xenstore ########## -xenstore-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog ctrl +xenstore-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog manage xenstore-minios.gen.cfg: xenstore-minios.cfg Makefile $(GEN_config) >$@ @@ -480,7 +480,7 @@ xenstore: $(CROSS_ROOT) xenstore-minios-config.mk # xenstorepvh ############# -xenstorepvh-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog ctrl +xenstorepvh-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog manage xenstorepvh-minios.gen.cfg: xenstorepvh-minios.cfg Makefile $(GEN_config) >$@ @@ -523,7 +523,7 @@ else pv-grub-if-enabled: endif -XENSTORE_DEPS := libxenevtchn libxengnttab libxenctrl +XENSTORE_DEPS := libxenevtchn libxengnttab libxenmanage .PHONY: xenstore-stubdom xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore $(XENSTORE_DEPS) xenstore diff --git a/stubdom/mini-os.mk b/stubdom/mini-os.mk index 7e4968e026..be32302f9e 100644 --- a/stubdom/mini-os.mk +++ b/stubdom/mini-os.mk @@ -13,5 +13,6 @@ GNTTAB_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/gnttab CALL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/call FOREIGNMEMORY_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/foreignmemory DEVICEMODEL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/devicemodel +MANAGE_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/manage CTRL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/ctrl GUEST_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/guest diff --git a/tools/xenstored/Makefile b/tools/xenstored/Makefile index 09adfe1d50..81c42838e0 100644 --- a/tools/xenstored/Makefile +++ b/tools/xenstored/Makefile @@ -5,7 +5,7 @@ include Makefile.common xenstored: LDLIBS += $(LDLIBS_libxenevtchn) xenstored: LDLIBS += $(LDLIBS_libxengnttab) -xenstored: LDLIBS += $(LDLIBS_libxenctrl) +xenstored: LDLIBS += $(LDLIBS_libxenmanage) xenstored: LDLIBS += -lrt xenstored: LDLIBS += $(SOCKET_LIBS) diff --git a/tools/xenstored/Makefile.common b/tools/xenstored/Makefile.common index 27fdb3b49e..271134fcc1 100644 --- a/tools/xenstored/Makefile.common +++ b/tools/xenstored/Makefile.common @@ -12,7 +12,7 @@ XENSTORED_OBJS-$(CONFIG_MiniOS) += minios.o lu_minios.o # Include configure output (config.h) CFLAGS += -include $(XEN_ROOT)/tools/config.h CFLAGS += $(CFLAGS_libxenevtchn) -CFLAGS += $(CFLAGS_libxenctrl) +CFLAGS += $(CFLAGS_libxenmanage) CFLAGS += $(CFLAGS_libxentoolcore) $(XENSTORED_OBJS-y): CFLAGS += $(CFLAGS_libxengnttab) diff --git a/tools/xenstored/core.h b/tools/xenstored/core.h index e58779e88c..632886cecf 100644 --- a/tools/xenstored/core.h +++ b/tools/xenstored/core.h @@ -19,7 +19,6 @@ #ifndef _XENSTORED_CORE_H #define _XENSTORED_CORE_H -#include #include #include diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c index 64c8fd0cc3..c0264d9477 100644 --- a/tools/xenstored/domain.c +++ b/tools/xenstored/domain.c @@ -34,14 +34,15 @@ #include "control.h" #include -#include +#include +#include #include #ifdef __MINIOS__ #include #endif -static xc_interface **xc_handle; +static xenmanage_handle *xm_handle; xengnttab_handle **xgt_handle; static evtchn_port_t virq_port; @@ -619,32 +620,28 @@ static int destroy_domain(void *_domain) return 0; } -static bool get_domain_info(unsigned int domid, xc_domaininfo_t *dominfo) -{ - return xc_domain_getinfo_single(*xc_handle, domid, dominfo) == 0; -} - static int check_domain(const void *k, void *v, void *arg) { - xc_domaininfo_t dominfo; + unsigned int state; struct connection *conn; - bool dom_valid; + int dom_invalid; struct domain *domain = v; bool *notify = arg; - dom_valid = get_domain_info(domain->domid, &dominfo); + dom_invalid = xenmanage_get_domain_info(xm_handle, domain->domid, + &state, NULL); if (!domain->introduced) { - if (!dom_valid) + if (dom_invalid) talloc_free(domain); return 0; } - if (dom_valid) { - if ((dominfo.flags & XEN_DOMINF_shutdown) + if (!dom_invalid) { + if ((state & XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN) && !domain->shutdown) { domain->shutdown = true; *notify = true; } - if (!(dominfo.flags & XEN_DOMINF_dying)) + if (!(state & XENMANAGE_GETDOMSTATE_STATE_DYING)) return 0; } if (domain->conn) { @@ -786,10 +783,9 @@ static struct domain *find_or_alloc_domain(const void *ctx, unsigned int domid) static struct domain *find_or_alloc_existing_domain(unsigned int domid) { struct domain *domain; - xc_domaininfo_t dominfo; domain = find_domain_struct(domid); - if (!domain && get_domain_info(domid, &dominfo)) + if (!domain && !xenmanage_get_domain_info(xm_handle, domid, NULL, NULL)) domain = alloc_domain(NULL, domid); return domain; @@ -1187,12 +1183,6 @@ int do_reset_watches(const void *ctx, struct connection *conn, return 0; } -static int close_xc_handle(void *_handle) -{ - xc_interface_close(*(xc_interface**)_handle); - return 0; -} - static int close_xgt_handle(void *_handle) { xengnttab_close(*(xengnttab_handle **)_handle); @@ -1258,15 +1248,9 @@ void domain_early_init(void) if (!domhash) barf_perror("Failed to allocate domain hashtable"); - xc_handle = talloc(talloc_autofree_context(), xc_interface*); - if (!xc_handle) - barf_perror("Failed to allocate domain handle"); - - *xc_handle = xc_interface_open(0,0,0); - if (!*xc_handle) - barf_perror("Failed to open connection to hypervisor"); - - talloc_set_destructor(xc_handle, close_xc_handle); + xm_handle = xenmanage_open(NULL, 0); + if (!xm_handle) + barf_perror("Failed to open connection to libxenmanage"); xgt_handle = talloc(talloc_autofree_context(), xengnttab_handle*); if (!xgt_handle) @@ -1306,6 +1290,8 @@ void domain_deinit(void) { if (virq_port) xenevtchn_unbind(xce_handle, virq_port); + + xenmanage_close(xm_handle); } /* @@ -1335,13 +1321,13 @@ int domain_alloc_permrefs(struct node_perms *perms) { unsigned int i, domid; struct domain *d; - xc_domaininfo_t dominfo; for (i = 0; i < perms->num; i++) { domid = perms->p[i].id; d = find_domain_struct(domid); if (!d) { - if (!get_domain_info(domid, &dominfo)) + if (xenmanage_get_domain_info(xm_handle, domid, + NULL, NULL)) perms->p[i].perms |= XS_PERM_IGNORE; else if (!alloc_domain(NULL, domid)) return ENOMEM; diff --git a/tools/xenstored/lu.c b/tools/xenstored/lu.c index bec2a84e10..4fccbbc195 100644 --- a/tools/xenstored/lu.c +++ b/tools/xenstored/lu.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include diff --git a/tools/xenstored/lu_daemon.c b/tools/xenstored/lu_daemon.c index 6df6c80a2a..88d8d9e1b3 100644 --- a/tools/xenstored/lu_daemon.c +++ b/tools/xenstored/lu_daemon.c @@ -6,6 +6,7 @@ */ #include +#include #include #include "talloc.h" -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 14:16:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 14:16:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850366.1264780 (Exim 4.92) (envelope-from ) id 1tJZ86-0001EM-7V; Fri, 06 Dec 2024 14:16:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850366.1264780; Fri, 06 Dec 2024 14: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 1tJZ86-0001EF-4v; Fri, 06 Dec 2024 14:16:26 +0000 Received: by outflank-mailman (input) for mailman id 850366; Fri, 06 Dec 2024 14:16: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 1tJZ85-0001E9-6B for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 14:16:25 +0000 Received: from mail180-17.suw31.mandrillapp.com (mail180-17.suw31.mandrillapp.com [198.2.180.17]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id aad574e1-b3dc-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 15:16:22 +0100 (CET) Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail180-17.suw31.mandrillapp.com (Mailchimp) with ESMTP id 4Y4YGD4RGfzRKMtvJ for ; Fri, 6 Dec 2024 14:16:20 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 4ca2d43c805d4cd3ad4ee2cb8912a549; Fri, 06 Dec 2024 14:16:20 +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: aad574e1-b3dc-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1733494580; x=1733755080; bh=Y0o1f3HA8+COSIdJmIZ/qovkjjUIMOVDZfQZHuY9OhQ=; 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=L0q3CzeC5wwg9fk1WmGeOIK3NLIvIiKF4xLOu48HW/5gkG7d5oWt7XPQDI8HDWI7f ubo59GjbmVbrFl7xWEVPIrLUIrigKWUnBFDyePJ2CtOXpvyhovyYsaUwFReNUhgqfy 7/AFLpAe4nGyEyLw9Biaf5kIKcoivQ6jxiP8LoX63b5ZvSy5DKd6N71bhB+4R6R1ei fXtFrPcEVDW3v6HGQ+D6wIP6zWgy0uwTY89e7xOIg2BIaGJt5ZLKCbvCBRDnXwf5Qc nkMk3PhZyCgf03A3hug79gVlIq2/v1PJkhCdZsh170yAuFmluSVV0NfNHRA7S59Y/y gVQuNyi2za2kg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1733494580; x=1733755080; i=ngoc-tu.dinh@vates.tech; bh=Y0o1f3HA8+COSIdJmIZ/qovkjjUIMOVDZfQZHuY9OhQ=; 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=DQgDLklNvaXSd27Jrl7Vk074nMTsEuSxx+x+k0U/IAn4BASsqoOAjLCX0ajcnCd/W b8bNRwHxiijYk0wqZuZWZw45xFta2irTv6oVPBNIelc+vJDibpuOLzPNCpwlW8t/+O 1KtOGp8LLE9FYkPTjKeXFQ5+lbP+CSzzQVGoplKoRKAdmXTvaeO/NTAJ8CX4kXUju0 8NOK7gayH+Tr7zHLz+VwWmCQzS3gTUUIYBrjTAgFkOkLWNrIM7q4C3sfouj3w1X/Lo w6AdzHDoVW2QNYpByxS6KMuAahUtWy+bgecVsfV2TocBxoqKS34CraoUMNmOsEqpa+ KJjS5+BZuvbWw== From: "Tu Dinh" Subject: =?utf-8?Q?Re:=20[PATCH=200/4]=20Virtualize=20architectural=20LBRs?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1733494579706 Message-Id: <953fed09-385c-4489-ae50-b59ebd444114@vates.tech> To: "Andrew Cooper" , "Jan Beulich" Cc: xen-devel@lists.xenproject.org References: <20241118084914.22268-1-ngoc-tu.dinh@vates.tech> <7706bd63-8f26-4eb8-8dc0-67b302597e3b@suse.com> <3f75df1d-f397-487f-9b81-d7740712b924@vates.tech> <78d9df73-c9b7-479d-8e05-e4efb823ea20@citrix.com> In-Reply-To: <78d9df73-c9b7-479d-8e05-e4efb823ea20@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.4ca2d43c805d4cd3ad4ee2cb8912a549?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20241206:md Date: Fri, 06 Dec 2024 14:16:20 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Andrew, On 18/11/2024 10:52, Andrew Cooper wrote: > On 18/11/2024 9:13 am, Tu Dinh wrote: >> On 18/11/2024 09:52, Jan Beulich wrote: >>> Looking over just the files touched: No change to XSAVE logic at all? >> XSAVE is hidden behind a new IA32_XSS bit. I'll try to implement that ne= xt. > > It's rather more severe than that. > > Without XSAVE support, Xen can't context-switch the LBR state when vCPUs > are scheduled in and out.=C2=A0 (In patch 4 you seem to have copied the > legacy way, which is extremely expensive.) > > Architecturally, ARCH_LBR depends on XSAVES so OSes can context switch > it easily(ish) per thread. > > There's also a reason why we haven't got this working yet.=C2=A0 There ar= e a > couple of areas of prerequisite work which need addressing before XSS > can be enabled properly. > > If you're willing to tackle this, then I can explain what needs doing, > and in roughly which order. > > ~Andrew Following the community call yesterday, I'd like to clarify my understanding of the issue: - Firstly, virtual XSS support for architectural LBR must be enabled. I noticed that XSS is already implemented, just not enabled; barring the LBR format issues below, are there any other issues with the current XSS implementation? - There are LBR format differences between some cores of the same CPU (e.g. in Intel hybrid CPUs: P-cores use effective IP while E-cores use linear IP). These differences are expected to be handled by XSAVES/XRSTORS. However, Xen would have to make sure that LBR MSRs are saved/restored by XSS instead of by manually poking MSRs. - A related issue is handling the compressed XSAVE format for migration streams. Xen currently expands/compacts XSAVE format manually during migration; are there any concerns with arch LBR breaking the XSAVE migration logic? My understanding is that as long as we don't manually poke the LBR state component, and that LBR state size remains consistent across hybrid cores in the same CPU (which it should be for XSAVE compatibility), there should be no concern with the XSAVE state itself. However, Xen must check CPU features of both sides during migration to make sure that XSAVE states are compatible, which is more complex in migrations involving hosts with hybrid CPUs. Please tell me if I'm missing any potential issues. Thanks, Ngoc Tu Dinh | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Fri Dec 06 18:37:50 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 18:37:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850384.1264794 (Exim 4.92) (envelope-from ) id 1tJdCn-0007xQ-Dy; Fri, 06 Dec 2024 18:37:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850384.1264794; Fri, 06 Dec 2024 18:37: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 1tJdCn-0007xJ-B9; Fri, 06 Dec 2024 18:37:33 +0000 Received: by outflank-mailman (input) for mailman id 850384; Fri, 06 Dec 2024 18:37:32 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJdCm-0007xD-BW for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 18:37:32 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tJdCl-0079Cz-1D; Fri, 06 Dec 2024 18:37:31 +0000 Received: from [2a02:8012:3a1:0:9908:37eb:1c5c:6583] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tJdCl-002xue-18; Fri, 06 Dec 2024 18:37: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" 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=M36lPwGgVQ2rydLocR7Bed9jbQbgEWWdTvQ4jMNkmF0=; b=IV2iRiD+gPQaupmuvRecVcDBIw gLTwHUm4FqPdz6/dPmLdRPCqC5M5lNJaRMoIcIg+erCSncnkbzJ9vfU7tCwzEajV+/T81ZsmPbw4g gPdJ8r4aJVwpyFItrvga7hUSail7TYcILNyh1UP8ZZ/SX1fEGYxLWdmX99+DLrmCRxTE=; Message-ID: <7ecc99c5-0cb5-4351-bede-cb03c9a4ac7e@xen.org> Date: Fri, 6 Dec 2024 18:37:29 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 03/12] xen/arm: permit non direct-mapped Dom0 construction Content-Language: en-GB To: Michal Orzel , Carlo Nonato , xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> <20241202165921.249585-4-carlo.nonato@minervasys.tech> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, Sorry for the late answer. On 05/12/2024 09:40, Michal Orzel wrote: > > > On 02/12/2024 17:59, Carlo Nonato wrote: >> >> >> Cache coloring requires Dom0 not to be direct-mapped because of its non >> contiguous mapping nature, so allocate_memory() is needed in this case. >> 8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a separate module") >> moved allocate_memory() in dom0less_build.c. In order to use it >> in Dom0 construction bring it back to domain_build.c and declare it in >> domain_build.h. >> >> Take the opportunity to adapt the implementation of allocate_memory() so >> that it uses the host layout when called on the hwdom, via >> find_unallocated_memory(). >> >> Signed-off-by: Carlo Nonato >> --- >> v11: >> - GUEST_RAM_BANKS instead of hardcoding the number of banks in allocate_memory() >> - hwdom_ext_regions -> hwdom_free_mem in allocate_memory() >> - added a comment in allocate_memory() when skipping small banks >> v10: >> - fixed a compilation bug that happened when dom0less support was disabled >> v9: >> - no changes >> v8: >> - patch adapted to new changes to allocate_memory() >> v7: >> - allocate_memory() now uses the host layout when called on the hwdom >> v6: >> - new patch >> --- >> xen/arch/arm/dom0less-build.c | 44 ----------- >> xen/arch/arm/domain_build.c | 97 ++++++++++++++++++++++++- >> xen/arch/arm/include/asm/domain_build.h | 1 + >> 3 files changed, 94 insertions(+), 48 deletions(-) >> >> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c >> index d93a85434e..67b1503647 100644 >> --- a/xen/arch/arm/dom0less-build.c >> +++ b/xen/arch/arm/dom0less-build.c >> @@ -49,50 +49,6 @@ bool __init is_dom0less_mode(void) >> return ( !dom0found && domUfound ); >> } >> >> -static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo) >> -{ >> - struct membanks *mem = kernel_info_get_mem(kinfo); >> - unsigned int i; >> - paddr_t bank_size; >> - >> - printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n", >> - /* Don't want format this as PRIpaddr (16 digit hex) */ >> - (unsigned long)(kinfo->unassigned_mem >> 20), d); >> - >> - mem->nr_banks = 0; >> - bank_size = MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem); >> - if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM0_BASE), >> - bank_size) ) >> - goto fail; >> - >> - bank_size = MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem); >> - if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM1_BASE), >> - bank_size) ) >> - goto fail; >> - >> - if ( kinfo->unassigned_mem ) >> - goto fail; >> - >> - for( i = 0; i < mem->nr_banks; i++ ) >> - { >> - printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n", >> - d, >> - i, >> - mem->bank[i].start, >> - mem->bank[i].start + mem->bank[i].size, >> - /* Don't want format this as PRIpaddr (16 digit hex) */ >> - (unsigned long)(mem->bank[i].size >> 20)); >> - } >> - >> - return; >> - >> -fail: >> - panic("Failed to allocate requested domain memory." >> - /* Don't want format this as PRIpaddr (16 digit hex) */ >> - " %ldKB unallocated. Fix the VMs configurations.\n", >> - (unsigned long)kinfo->unassigned_mem >> 10); >> -} >> - >> #ifdef CONFIG_VGICV2 >> static int __init make_gicv2_domU_node(struct kernel_info *kinfo) >> { >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c >> index 2c30792de8..2b8cba9b2f 100644 >> --- a/xen/arch/arm/domain_build.c >> +++ b/xen/arch/arm/domain_build.c >> @@ -416,7 +416,6 @@ static void __init allocate_memory_11(struct domain *d, >> } >> } >> >> -#ifdef CONFIG_DOM0LESS_BOOT >> bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size, >> alloc_domheap_mem_cb cb, void *extra) >> { >> @@ -508,7 +507,6 @@ bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn, >> >> return true; >> } >> -#endif >> >> /* >> * When PCI passthrough is available we want to keep the >> @@ -1003,6 +1001,94 @@ out: >> return res; >> } >> >> +void __init allocate_memory(struct domain *d, struct kernel_info *kinfo) >> +{ >> + struct membanks *mem = kernel_info_get_mem(kinfo); >> + unsigned int i, nr_banks = GUEST_RAM_BANKS; >> + paddr_t bank_start, bank_size; > Limit the scope > >> + struct membanks *hwdom_free_mem = NULL; >> + const uint64_t bankbase[] = GUEST_RAM_BANK_BASES; >> + const uint64_t banksize[] = GUEST_RAM_BANK_SIZES; > Limit the scope > >> + >> + printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n", >> + /* Don't want format this as PRIpaddr (16 digit hex) */ >> + (unsigned long)(kinfo->unassigned_mem >> 20), d); >> + >> + mem->nr_banks = 0; >> + /* >> + * Use host memory layout for hwdom. Only case for this is when LLC coloring >> + * is enabled. >> + */ >> + if ( is_hardware_domain(d) ) >> + { >> + ASSERT(llc_coloring_enabled); > This patch does not build because of declaration not being visible. You must include . Piggying back on this comment. AFAICT, the code below would work also in the non cache coloring case. So what's the assert is for? > >> + >> + hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank, >> + NR_MEM_BANKS); >> + if ( !hwdom_free_mem ) >> + goto fail; >> + >> + hwdom_free_mem->max_banks = NR_MEM_BANKS; >> + >> + if ( find_unallocated_memory(kinfo, hwdom_free_mem) ) > My remarks for the use of find_unallocated_memory() 1:1 have not been addressed. You did not even > change the comments inside the function. The problem is that the function is specifically designed > for finding extended regions and assumes being called at certain point i.e. dom0 RAM allocated, gnttab > region allocated, etc. So I agree that the function should be updated if we plan to use it for other purpose. My opinion is that we should attempt to make the function generic so that in your > case you can choose which regions to exclude, define even your own function to grab free regions (at the moment > add_ext_regions grabs banks >= 64M but you still discards banks >= 128M, so it's a bit wasteful. > > My very short attempt to make the function as generic as possible in the first iteration: > https://paste.debian.net/1338334/ This looks better, but I wonder why we need still need to exclude the static regions? Wouldn't it be sufficient to exclude just reserved regions? > > For coloring, you could define your own add_free_regions and only pass RSVD and GNTTAB banks to be excluded. > > As said before, I still wait for other Arm maintainers to provide their own opinion. > > ~Michal > -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Dec 06 19:04:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 19:04:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850399.1264803 (Exim 4.92) (envelope-from ) id 1tJdd0-0003dT-I2; Fri, 06 Dec 2024 19:04:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850399.1264803; Fri, 06 Dec 2024 19:04: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 1tJdd0-0003dM-FT; Fri, 06 Dec 2024 19:04:38 +0000 Received: by outflank-mailman (input) for mailman id 850399; Fri, 06 Dec 2024 19:04:36 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJdcy-0003dG-Rz for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 19:04:36 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tJdcy-0079lH-09; Fri, 06 Dec 2024 19:04:36 +0000 Received: from [2a02:8012:3a1:0:9908:37eb:1c5c:6583] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tJdcy-0030kM-0H; Fri, 06 Dec 2024 19:04: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" 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=jTmZubeF2xjm2jdqIE65r+jIoXT5bKUZf5xv+Zv9Ivw=; b=wBX/yFUkv3VPEUYgNrEdKkWDfQ rk1z0Vqn1C0XS1N+irDb6DEsi6e33u2zECJQQeoU6pODuP1Z9MA2OKYEToh4ZvUK6gYHSsVUygWbF ZUUdqVZpF7ncYNixVodn9fQ7bGeEUTB8p2cCwe6/e2LmQVRyycBqpzUoGLgW4kAh/ZDw=; Message-ID: Date: Fri, 6 Dec 2024 19:04:33 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/2] xen/mpu: Map early uart when earlyprintk on Content-Language: en-GB To: Ayan Kumar Halder , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Luca Fancellu References: <20241204172243.1229942-1-ayan.kumar.halder@amd.com> <20241204172243.1229942-2-ayan.kumar.halder@amd.com> From: Julien Grall In-Reply-To: <20241204172243.1229942-2-ayan.kumar.halder@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Ayan, On 04/12/2024 17:22, Ayan Kumar Halder wrote: > CONFIG_EARLY_UART_SIZE is introduced to let user provide physical size of > early UART. Unlike MMU where we map a page in the virtual address space, > here we need to know the exact physical size to be mapped. > As VA == PA in case of MPU, the memory layout follows exactly the hardware > configuration. As a consequence, we set EARLY_UART_VIRTUAL_ADDRESS as physical > address. > > EARLY_UART_BASE_ADDRESS and EARLY_UART_SIZE should be aligned to the minimum > size of MPU region (ie 64 bits) as per the hardware restrictions. Refer ARM > DDI 0600A.d ID120821 A1.3 "A minimum protection region size of 64 bytes.". > > UART is mapped as nGnRE region (as specified by ATTR=100 , refer G1.3.13, > MAIR_EL2, "---0100 Device memory nGnRE"). Also, it is mapped as outer shareable, > RW at EL2 only and execution of instructions from the region is not permitted. > > Signed-off-by: Ayan Kumar Halder > Reviewed-by: Luca Fancellu Acked-by: Julien Grall Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Dec 06 19:09:31 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 19:09:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850408.1264814 (Exim 4.92) (envelope-from ) id 1tJdhi-0004EE-2a; Fri, 06 Dec 2024 19:09:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850408.1264814; Fri, 06 Dec 2024 19: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 1tJdhh-0004E7-Vi; Fri, 06 Dec 2024 19:09:29 +0000 Received: by outflank-mailman (input) for mailman id 850408; Fri, 06 Dec 2024 19:09:28 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJdhg-0004E1-Ag for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 19:09:28 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tJdhf-0079r2-28; Fri, 06 Dec 2024 19:09:27 +0000 Received: from [2a02:8012:3a1:0:9908:37eb:1c5c:6583] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tJdhf-003171-2V; Fri, 06 Dec 2024 19:09: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" 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=fTBCRPbagEzZ2cfi9thYQHAX2abjVhONVOob/e+nDh0=; b=ShIwP3fMvCewJc+AkFulFwoJoA msbMQAwH6rkzlwCMKfP2H4WbOBUH6E3jTkovLGsvEq1bz0uhwZrsgcFRTbLmfc7RlMHRIOCR5S+6q FWqWzvWMSB1+v+8DgM0oxxxEc1noSbnk2JMiAg0rnBQdiqFdJ33qonQpLcMhyv93so2E=; Message-ID: Date: Fri, 6 Dec 2024 19:09:26 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 0/2] Enable early bootup of AArch64 MPU systems (Part 2) Content-Language: en-GB To: Ayan Kumar Halder , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20241204172243.1229942-1-ayan.kumar.halder@amd.com> From: Julien Grall In-Reply-To: <20241204172243.1229942-1-ayan.kumar.halder@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Ayan, On 04/12/2024 17:22, Ayan Kumar Halder wrote: > This patch serie concludes earlyboot support for Arm-v8R AArch64 MPU systems. > > Ayan Kumar Halder (1): > xen/mpu: Map early uart when earlyprintk on > > Penny Zheng (1): > xen/mmu: enable SMMU subsystem only in MMU I have committed this series. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Dec 06 19:20:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 19:20:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850421.1264832 (Exim 4.92) (envelope-from ) id 1tJdrt-0006Cs-29; Fri, 06 Dec 2024 19:20:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850421.1264832; Fri, 06 Dec 2024 19:20: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 1tJdrs-0006Cl-VR; Fri, 06 Dec 2024 19:20:00 +0000 Received: by outflank-mailman (input) for mailman id 850421; Fri, 06 Dec 2024 19:19:59 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJdrr-0006Cf-Ce for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 19:19:59 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tJdrq-007A2n-2K; Fri, 06 Dec 2024 19:19:59 +0000 Received: from [2a02:8012:3a1:0:9908:37eb:1c5c:6583] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tJdrq-00328v-2Z; Fri, 06 Dec 2024 19:19: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" 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=/N0gZ856hyqHnzXfqBWV8x3PA5VqxBkhEMB2LIKtkKs=; b=c3u9XjU1t0UcVKONZtLEELtjtq phFVBl9sSBIPrCqs1TKbUd9d11Nm3k0NKMcyeBSZfREsQ0itqE2pOrsx+KZkPyZlwTEkbrPLVadxs Gjga+Ci9LE1vVeFrdzxZImDlVAB/Hxx3xAPm43pkv6RHEHjC/dnf60lq6VMgfWqfCCqM=; Message-ID: <00c7c6ce-f50d-43ac-b411-3e051b9bb582@xen.org> Date: Fri, 6 Dec 2024 19:19:56 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 4/5] xen/arm: Check for Static Heap feature when freeing resources Content-Language: en-GB To: Luca Fancellu , xen-devel@lists.xenproject.org Cc: Penny Zheng , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Jan Beulich , Wei Chen References: <20241203094811.427076-1-luca.fancellu@arm.com> <20241203094811.427076-5-luca.fancellu@arm.com> From: Julien Grall In-Reply-To: <20241203094811.427076-5-luca.fancellu@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Luca, On 03/12/2024 09:48, Luca Fancellu wrote: > diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c > index 9664e85ee6c0..8c87649bc88e 100644 > --- a/xen/arch/arm/mmu/setup.c > +++ b/xen/arch/arm/mmu/setup.c > @@ -341,8 +341,12 @@ void free_init_memory(void) > if ( rc ) > panic("Unable to remove the init section (rc = %d)\n", rc); > > - init_domheap_pages(pa, pa + len); > - printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10); > + if ( !using_static_heap ) > + { > + init_domheap_pages(pa, pa + len); > + printk("Freed %ldkB init memory.\n", > + (long)(__init_end-__init_begin) >> 10); > + } > } > > /** > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c > index 2e27af4560a5..22ab342dc8f4 100644 > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -206,24 +206,25 @@ void __init discard_initial_modules(void) > struct bootmodules *mi = &bootinfo.modules; > int i; Looking at the change below, it seems that discard_initial_modules() is a NOP for static_heap. Do you forsee any reason where it would be different? If not, then I would prefer if the code would be: if (static_heap) return; This would reduce the indention in the most common case and also make easier to review the diff. The rest of this patch LGTM > > - for ( i = 0; i < mi->nr_mods; i++ ) > + if ( !using_static_heap ) > { > - paddr_t s = mi->module[i].start; > - paddr_t e = s + PAGE_ALIGN(mi->module[i].size); > - > - if ( mi->module[i].kind == BOOTMOD_XEN ) > - continue; > + for ( i = 0; i < mi->nr_mods; i++ ) > + { > + paddr_t s = mi->module[i].start; > + paddr_t e = s + PAGE_ALIGN(mi->module[i].size); > > - if ( !mfn_valid(maddr_to_mfn(s)) || > - !mfn_valid(maddr_to_mfn(e)) ) > - continue; > + if ( mi->module[i].kind == BOOTMOD_XEN ) > + continue; > > - fw_unreserved_regions(s, e, init_domheap_pages, 0); > - } > + if ( !mfn_valid(maddr_to_mfn(s)) || > + !mfn_valid(maddr_to_mfn(e)) ) > + continue; > > - mi->nr_mods = 0; > + fw_unreserved_regions(s, e, init_domheap_pages, 0); > + } > > - remove_early_mappings(); > + mi->nr_mods = 0; > + } > } > Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Dec 06 19:22:34 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 19:22:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850430.1264842 (Exim 4.92) (envelope-from ) id 1tJduK-0007vR-DQ; Fri, 06 Dec 2024 19:22:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850430.1264842; Fri, 06 Dec 2024 19:22:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJduK-0007vK-Ah; Fri, 06 Dec 2024 19:22:32 +0000 Received: by outflank-mailman (input) for mailman id 850430; Fri, 06 Dec 2024 19:22:30 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJduI-0007vC-Ub for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 19:22:30 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tJduI-007A4t-18; Fri, 06 Dec 2024 19:22:30 +0000 Received: from [2a02:8012:3a1:0:9908:37eb:1c5c:6583] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tJduI-0032X8-1P; Fri, 06 Dec 2024 19:22: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" 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=ofBFEHUsAOak1dWjpvSDp4Qw+UEplSp7KZHRIq6M7wE=; b=mvAIdacDdOfpOdK9spz8YRCHBQ nKqyUCoSKDMJ5U8zUPs2FiD9E6EKSzHLAjsxRwBIsXb5LhblXno2LFH8S5IGC6fWgBlyg2mk4EhZu bzfn5GJgls/r2sQspKG2DegPneUoEhScINpxzhmuWvWpFh8NTkA/EXa9PRlgMbgbUOUM=; Message-ID: Date: Fri, 6 Dec 2024 19:22:29 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 5/5] xen/arm: Move setup_frametable_mappings to arm/mmu Content-Language: en-GB To: Luca Fancellu , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20241203094811.427076-1-luca.fancellu@arm.com> <20241203094811.427076-6-luca.fancellu@arm.com> From: Julien Grall In-Reply-To: <20241203094811.427076-6-luca.fancellu@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Luca, On 03/12/2024 09:48, Luca Fancellu wrote: > Move the current setup_frametable_mappings implementation to > arm/mmu under a new file mm.c, this implementation depends on > virtual memory and won't be used as it is for MPU systems. > > Take the occasion to fix code style issues related to the line > length. > > Moved also frametable_virt_end since it is used only on MMU > systems. > > Signed-off-by: Luca Fancellu Reviewed-by: Julien Grall Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Dec 06 19:26:25 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 19:26:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850441.1264852 (Exim 4.92) (envelope-from ) id 1tJdxw-0008Vi-Sl; Fri, 06 Dec 2024 19:26:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850441.1264852; Fri, 06 Dec 2024 19:26: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 1tJdxw-0008Vb-QB; Fri, 06 Dec 2024 19:26:16 +0000 Received: by outflank-mailman (input) for mailman id 850441; Fri, 06 Dec 2024 19:26:16 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJdxw-0008VV-0B for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 19:26:16 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tJdxu-007AAA-39; Fri, 06 Dec 2024 19:26:15 +0000 Received: from [2a02:8012:3a1:0:9908:37eb:1c5c:6583] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tJdxv-0032oS-0C; Fri, 06 Dec 2024 19:26: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" 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=f2hV8vQerxdrLlUqlo7ZJV61XvPPtKY/LyMAxZY2f+A=; b=O4/BgEpfMb/KqCnrdEahIN1vdm 9TaL2emnlC9piXSxL1osEZCw+eWc3En8gyd3y11d+FTiDO/0Ralv2z9HsDJjc3KY+QKqcrT2PAJrI 8SU6fgXUB3aO9j/auc0VYgkNQyBJNISK7I6P5885lmz3q39HjvRiluyw2M0muIPL/NpU=; Message-ID: <64ae8244-f8d1-4d50-b3b8-f29f4ff3d584@xen.org> Date: Fri, 6 Dec 2024 19:26:13 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 0/5] Prerequisite patches for R82 upstreaming Content-Language: en-GB To: Luca Fancellu , xen-devel@lists.xenproject.org Cc: Andrew Cooper , Jan Beulich , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Ross Lagerwall References: <20241203094811.427076-1-luca.fancellu@arm.com> From: Julien Grall In-Reply-To: <20241203094811.427076-1-luca.fancellu@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Luca, On 03/12/2024 09:48, Luca Fancellu wrote: > In this serie I've taken out patches from the R82 branch already in the ML[1] > and some new patches I've done based on the current status of staging that will > not impact the current Armv8-R earlyboot work. > > [1] https://patchwork.kernel.org/project/xen-devel/cover/20230626033443.2943270-1-Penny.Zheng@arm.com/ > > Changes between v2 and v3: > - New patch > - changes to previous patch are listed inside them > > Luca Fancellu (4): I have committed all the patches but... > common/vmap: Fall back to simple allocator when !HAS_VMAP > arm/setup: Move MMU specific extern declarations to mmu/setup.h > xen/arm: Use vmap_contig instead of __vmap where it's possible > xen/arm: Move setup_frametable_mappings to arm/mmu> > Penny Zheng (1): > xen/arm: Check for Static Heap feature when freeing resources .. this one where I left a comment. This could possibly be handled on commit. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Dec 06 19:40:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 19:40:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850459.1264877 (Exim 4.92) (envelope-from ) id 1tJeBi-0003AA-80; Fri, 06 Dec 2024 19:40:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850459.1264877; Fri, 06 Dec 2024 19:40:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJeBi-0003A3-57; Fri, 06 Dec 2024 19:40:30 +0000 Received: by outflank-mailman (input) for mailman id 850459; Fri, 06 Dec 2024 19:40:28 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJeBg-00039r-SN for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 19:40:28 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tJeBg-007AQd-0R; Fri, 06 Dec 2024 19:40:28 +0000 Received: from 54-240-197-232.amazon.com ([54.240.197.232] helo=dev-dsk-jgrall-1b-035652ec.eu-west-1.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tJeBg-0034Np-0E; Fri, 06 Dec 2024 19:40: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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:Message-Id:Date: Subject:Cc:To:From; bh=eOgOAaOBj8tyU30Xd9ZQ++sw9kgVYwZFhk4V5vdXcEw=; b=AR2Fpw PwGgIysdagoNXnt/ErG9yOMT8QF9SFcM3EGSEDcAnAK7ST+VMl20n6D+KB4mGpPeA9Dhow4PETeEI jCzVl8WMOC6vL7Fev9amZnvBqe01tjvIxzrDC7XIK2IOqdZmhKSciPcg/CNSCr2IUXhdDNM6ly7gx PX6OQxA9o9g=; From: Julien Grall To: xen-devel@lists.xenproject.org Cc: julien@xen.org, Julien Grall , Andrew Cooper , Jan Beulich , Stefano Stabellini Subject: [PATCH for-4.20 0/2] docs/process: Update the branching checklist Date: Fri, 6 Dec 2024 19:40:23 +0000 Message-Id: <20241206194025.31662-1-julien@xen.org> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Julien Grall Hi all, As we approach Xen 4.20, update the branching checklist to match the current state of affair. Cheers, Julien Grall (2): docs/process: branching-checklist: Update the steps to generate the docs docs/process: branching-checklist: Remove any reference to OSSTest docs/process/branching-checklist.txt | 33 ++++------------------------ 1 file changed, 4 insertions(+), 29 deletions(-) -- 2.40.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 19:40:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 19:40:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850461.1264897 (Exim 4.92) (envelope-from ) id 1tJeBj-0003cH-Na; Fri, 06 Dec 2024 19:40:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850461.1264897; Fri, 06 Dec 2024 19:40:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJeBj-0003cA-Kl; Fri, 06 Dec 2024 19:40:31 +0000 Received: by outflank-mailman (input) for mailman id 850461; Fri, 06 Dec 2024 19:40:30 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJeBi-0003CK-CK for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 19:40:30 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tJeBh-007AQt-3A; Fri, 06 Dec 2024 19:40:30 +0000 Received: from 54-240-197-232.amazon.com ([54.240.197.232] helo=dev-dsk-jgrall-1b-035652ec.eu-west-1.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tJeBi-0034Np-02; Fri, 06 Dec 2024 19:40: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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References: In-Reply-To:Message-Id:Date:Subject:Cc:To:From; bh=gm627I+Am5o4i2sMn6yJhycalKKIFzp8/ayRvTb16zU=; b=DPHjrIe27p4eJs/PmpicXlzUIe Hiq4+j7QMeTXM/AVuj+pX2gcxl5SNdXgMoyAOIqinPr4njTpl1FtzPwB4GUxs9TaFw8S1o8ODLHXR 4enZYwgBfOsxMxXepIDUJdVrgGdjKcc0BUOCNKktqv+IuIfkUGDQFelJYbJwYSco/K4M=; From: Julien Grall To: xen-devel@lists.xenproject.org Cc: julien@xen.org, Julien Grall , Andrew Cooper , Jan Beulich , Stefano Stabellini Subject: [PATCH for-4.20 2/2] docs/process: branching-checklist: Remove any reference to OSSTest Date: Fri, 6 Dec 2024 19:40:25 +0000 Message-Id: <20241206194025.31662-3-julien@xen.org> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20241206194025.31662-1-julien@xen.org> References: <20241206194025.31662-1-julien@xen.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Julien Grall OSSTest was turned off a few weeks ago. So we don't need any steps related to OSSTest when branching off to a new Xen version. Signed-off-by: Julien Grall --- Do we need any specific steps for gitlab CI? --- docs/process/branching-checklist.txt | 24 ------------------------ 1 file changed, 24 deletions(-) diff --git a/docs/process/branching-checklist.txt b/docs/process/branching-checklist.txt index 372d7268d20a..582bc86d6a67 100644 --- a/docs/process/branching-checklist.txt +++ b/docs/process/branching-checklist.txt @@ -2,7 +2,6 @@ Access to the following accounts is necessary: * xenbits.xen.org: xen, xendocs - * osstest.osstest-test-lab: osstest === Check list === @@ -17,11 +16,6 @@ ov=4.0 cd ~/git/qemu-xen-traditional.git git branch stable-$v master -# make branch in libvirt - ssh xen@xenbits.xen.org - cd ~/git/libvirt.git/ - git branch osstest/frozen/xen-$v-testing xen-tested-master - # make branches in xenbits.xen.org xen.git ssh xen@xenbits.xen.org cd ~/git/xen.git @@ -43,17 +37,6 @@ ov=4.0 git add -p git commit -m "Branch for $v" -* make branches etc. in osstest - ssh osstest@osstest.test-lab - cd testing.git - OSSTEST_CONFIG=production-config ./mg-branch-setup xen-$v-testing bisect - OSSTEST_CONFIG=production-config ./mg-branch-setup qemu-upstream-$v-testing bisect - -* add branch to osstest - Add both qemu-upstream-$v-testing and xen-$v-testing to BRANCHES in cr-for-branches - git add -p - git commit -m "cr-for-branches: Add Xen and QEMU $v branch" - * add to patchbot ssh xen@xenbits.xen.org cd ~/HG/patchbot/ @@ -84,11 +67,4 @@ Update newly diverging staging-$v according to release-technician-checklist.txt section re README etc., including turning off debug. -Set off a manual osstest run, since the osstest cr-for-branches change -will take a while to take effect: - ssh osstest@osstest.test-lab - cd testing.git - screen -S $v - BRANCHES=xen-$v-testing ./cr-for-branches branches -w "./cr-daily-branch --real" - Send message to committers and RM. Use previous mail as a template. -- 2.40.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 19:40:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 19:40:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850460.1264882 (Exim 4.92) (envelope-from ) id 1tJeBi-0003Cb-Fz; Fri, 06 Dec 2024 19:40:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850460.1264882; Fri, 06 Dec 2024 19:40:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJeBi-0003BV-Bd; Fri, 06 Dec 2024 19:40:30 +0000 Received: by outflank-mailman (input) for mailman id 850460; Fri, 06 Dec 2024 19:40:29 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJeBh-00039x-F5 for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 19:40:29 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tJeBh-007AQk-06; Fri, 06 Dec 2024 19:40:29 +0000 Received: from 54-240-197-232.amazon.com ([54.240.197.232] helo=dev-dsk-jgrall-1b-035652ec.eu-west-1.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tJeBh-0034Np-08; Fri, 06 Dec 2024 19:40: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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References: In-Reply-To:Message-Id:Date:Subject:Cc:To:From; bh=OjhukXx7pWSIpn/U/kPGOQl9prDmsqkVlAfieaq68CM=; b=SZdik9db4AkCvzUuGYbtArpJS9 31zucKnWQNfy3KhcIm7D1NxIvkT4bLjHHLaYchuzP8fDbmLneymfr0HOwlLleomcrjreQEdWp0eaU lMBXvW5GgNm3EjdploGVqa071PITbgx3K96wsQx50K96sbr7Zk7vnGJxMr32ofnjA+F4=; From: Julien Grall To: xen-devel@lists.xenproject.org Cc: julien@xen.org, Julien Grall , Andrew Cooper , Jan Beulich , Stefano Stabellini Subject: [PATCH for-4.20 1/2] docs/process: branching-checklist: Update the steps to generate the docs Date: Fri, 6 Dec 2024 19:40:24 +0000 Message-Id: <20241206194025.31662-2-julien@xen.org> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20241206194025.31662-1-julien@xen.org> References: <20241206194025.31662-1-julien@xen.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Julien Grall The loop in xenbits-docs-all.sh has been rewritten to use a range rather than listing all the branch one by one. So update the steps accordingly. Signed-off-by: Julien Grall --- docs/process/branching-checklist.txt | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/docs/process/branching-checklist.txt b/docs/process/branching-checklist.txt index 3dfa8ec2570b..372d7268d20a 100644 --- a/docs/process/branching-checklist.txt +++ b/docs/process/branching-checklist.txt @@ -35,12 +35,11 @@ ov=4.0 # xenbits-docs-all.sh in the obvious way. git commit ssh xendocs@xenbits.xen.org cd cronjobs - ed xenbits-docs-all.sh - /for branch - s/$/ 4.6-testing + open xenbits-docs-all.sh with your favorite editor + Update the range on the line: + for branch in unstable-staging unstable 4.{18..15}-testing # ^ OR SIMILAR - w - q + save the file and exit the editor git add -p git commit -m "Branch for $v" -- 2.40.1 From xen-devel-bounces@lists.xenproject.org Fri Dec 06 19:47:26 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 19:47:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850492.1264908 (Exim 4.92) (envelope-from ) id 1tJeIM-0005Ac-Df; Fri, 06 Dec 2024 19:47:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850492.1264908; Fri, 06 Dec 2024 19:47: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 1tJeIM-0005AV-Aq; Fri, 06 Dec 2024 19:47:22 +0000 Received: by outflank-mailman (input) for mailman id 850492; Fri, 06 Dec 2024 19:47:21 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJeIL-0005AP-Si for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 19:47:21 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tJeIK-007AYY-13; Fri, 06 Dec 2024 19:47:20 +0000 Received: from [2a02:8012:3a1:0:9908:37eb:1c5c:6583] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tJeIK-00354i-1S; Fri, 06 Dec 2024 19:47:20 +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=wjRdal2gy2+JogKCKVtWGBw+/Ydy87n0Xyd2hXGUAa0=; b=Md4MxSCmI1QotOqGTQThz6JRuK 1gVZY03nWMa2JpDWUX+CIrYekcV7UJYR66ltxRbgVOc1kk5QBCooukRfKxbiryMJo65Gq043w1Cvm NB0JKWeomc7GYXP8WLcYJaTvbKixOv8Cg9DZL4sBxEhBG6V8jmz0dZKMzcxMbAEG2JVY=; Message-ID: Date: Fri, 6 Dec 2024 19:47:19 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC for-4.19] docs/checklist: Start tagging new dev windows Content-Language: en-GB To: Andrew Cooper Cc: Stefano Stabellini , Oleksii Kurochko , Xen-devel , Jan Beulich References: <20240715164639.3378294-1-andrew.cooper3@citrix.com> <7db0879f-93a3-4690-8ba5-1f0897027e47@xen.org> <81c65915-cecc-4edf-8636-3be56a411c50@suse.com> From: Julien Grall In-Reply-To: <81c65915-cecc-4edf-8636-3be56a411c50@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andrew, Reviving this thread as we are preparing for Xen 4.20. On 16/07/2024 07:57, Jan Beulich wrote: > On 15.07.2024 18:58, Julien Grall wrote: >> On 15/07/2024 17:46, Andrew Cooper wrote: >>> Signed-off-by: Andrew Cooper >> >> With one remark below: >> >> Reviewed-by: Julien Grall >> >>> --- >>> CC: Jan Beulich >>> CC: Stefano Stabellini >>> CC: Julien Grall >>> CC: Oleksii Kurochko >>> >>> This is about figuring out when a change was first introduced. Take >>> 10b719dc88 for example (completely random pick). >>> >>> The right answer is `git tag --contains $sha` and look for the oldest >>> RELEASE-$X. In this case it's Xen 4.6, but the tags are not numerically >>> sorted so the answer is towards the end of the list of 166 tags. >>> >>> The better answer would be to `git describe $sha` because git has an algorithm >>> to do this nicely. In this case, it's 4.5.0-rc4-934-g10b719dc8830 because we >>> branch first and tag RELEASE-4.6.0 on the branch, rather than releasing off >>> master. >>> >>> With 0082626f35af (opening of the 4.6 tree) containing an annotated tag of >>> 4.6-dev, git describe now gives 4.6-dev-902-g10b719dc8830 which far more >>> helpful when doing code archeology. >> >> I think some of this explanation should be in the commit message. > > Imo it could even be moved up verbatim. Would you be fine if I move your explanation in the commit message and commit it? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Dec 06 20:58:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Dec 2024 20:58:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850509.1264918 (Exim 4.92) (envelope-from ) id 1tJfP8-0006ur-1l; Fri, 06 Dec 2024 20:58:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850509.1264918; Fri, 06 Dec 2024 20: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 1tJfP7-0006uk-Ty; Fri, 06 Dec 2024 20:58:25 +0000 Received: by outflank-mailman (input) for mailman id 850509; Fri, 06 Dec 2024 20:58: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 1tJfP6-0006ue-If for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 20:58:24 +0000 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id d2aa23ba-b414-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 21:58:21 +0100 (CET) Received: from [100.65.128.154] (unknown [20.236.11.102]) by linux.microsoft.com (Postfix) with ESMTPSA id 8B63620ACD7A; Fri, 6 Dec 2024 12:58:18 -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: d2aa23ba-b414-11ef-99a3-01e77a169b0f DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 8B63620ACD7A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1733518699; bh=M9PuEUd7fHK0twjnpmT4sQ2WiGKSyXN5nPrU+06sRxI=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=opdIpAACnQeStJ33oACe6p52ZM8f0Sws7Fv8oVZEtnJ34oxYkj2Ifncn0UBE7+8VM /Rer5IHWNKL+Om4cBhthsawIs+kQdevr3ykVw21CBvfVnNLhAZ1lcWLQbVr0aJDoH2 0Lv+tHrW7mbf2ysXMzyMfTT7x/zNVB+cEVkkvmJU= Message-ID: Date: Fri, 6 Dec 2024 12:58:17 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: eahariha@linux.microsoft.com, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, ath11k@lists.infradead.org, linux-mm@kvack.org, linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, live-patching@vger.kernel.org, linux-sound@vger.kernel.org, etnaviv@lists.freedesktop.org, oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, Anna-Maria Behnsen Subject: Re: [PATCH v2 00/21] Converge on using secs_to_jiffies() To: Przemek Kitszel References: <20241115-converge-secs-to-jiffies-v2-0-911fb7595e79@linux.microsoft.com> From: Easwar Hariharan Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/29/2024 4:57 AM, Przemek Kitszel wrote: > > [removed most non-list recipients, it's just too much] > > On 11/15/24 10:26 PM, Easwar Hariharan wrote: >> >> --- >> Changes in v2: >> - EDITME: describe what is new in this series revision. >> - EDITME: use bulletpoints and terse descriptions. >> - Link to v1: https://lore.kernel.org/r/20241115-converge-secs-to- >> jiffies-v1-0-19aadc34941b@linux.microsoft.com > > that is not a proper changelog, you were supposed to edit those > placeholder entries; please look around for examples > > There is also just too much recipients. Please split up your patches > into smaller pieces. You will also learn the process on a smaller > sample. > > And definitively please wait for 48h before reposting such big series. Yes, sorry, I sent out a v2 in a moment of panic on including the already accepted patch in v1. I failed to edit the changelog in that same panic. I'll try to not panic and do better in the future. > > Regarding code - you could also convert msecs_to_jiffies(const * HZ), > there are 10 that are greppable. > Those seem to be mistakes. const*HZ is a seconds-denominated timeout, being passed to msecs_to_jiffies() which will treat it as a millisecond-denominated timeout resulting in an excessively long timeout. I suppose that's better than a too-short timeout, and apparently it's been working fine all along since hardware responds before the too-long timeout expires. Half of them are in drivers/scsi/arcmsr/arcmsr_hba.c and the pattern has apparently been there since 2010. Thanks, Easwar From xen-devel-bounces@lists.xenproject.org Sat Dec 07 07:04:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 07 Dec 2024 07:04:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850522.1264957 (Exim 4.92) (envelope-from ) id 1tJorL-0003NM-GO; Sat, 07 Dec 2024 07:04:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850522.1264957; Sat, 07 Dec 2024 07:04:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJorL-0003Mn-Ax; Sat, 07 Dec 2024 07:04:11 +0000 Received: by outflank-mailman (input) for mailman id 850522; Fri, 06 Dec 2024 21:40: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 1tJg3h-0004tw-TV for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 21:40:22 +0000 Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b07ca4cd-b41a-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 22:40:19 +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: b07ca4cd-b41a-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=obvfqx6jczfvvnv5aare5csz3u.protonmail; t=1733521218; x=1733780418; bh=mZRhc2iB7FrrSohk+3J3TNgbBs+IDDRJtYpJFl+k+Zk=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=f18ohYVDnqiUcpXJWJ1c4zPP3h8Ej3C/QdO0MZK+7hn7KSjKTP1d5PW7qOOWIPUJi PVcRWeppxIzDXaC/55MrERMns6hBbkh+sC4J1af1XWUT9ZwOaFvb5DtmRV2FrkZDnZ gQedHFaE27QpeJJXobTQsaJwT7AxNyaD3XJsYFGQ7g9+CZ3EioaGUjm7/UdQmU1Oix /R6vl1TzxV8dqA5819Oy7jzPO8bmXz2dvfF/B44gVCzZbiQfk7bz10Bsq5Fkw3sRbj BmKSdlBzi9F+1uzUIo6CQc0YPDJHcwQw6VAemXcPpKSDz7aKryqOc7tNmhE2sMmy4i o/u/780ukZYmw== Date: Fri, 06 Dec 2024 21:40:13 +0000 To: Andrew Cooper From: Denis Mukhin Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH 00/36] Introduce NS8250 UART emulator Message-ID: <9UHall6dGEJP7fCAeg7-Xx4wZ2Nsrsi6yUH-ViDUl3rMpk31wPzGOId82_u3rMc0dTNTLyUidIv-6c2ni_7n5YFgSCINSbXY6aS1JMardHU=@proton.me> In-Reply-To: References: <20241126-vuart-ns8250-v1-v1-0-87b9a8375b7a@ford.com> Feedback-ID: 123220910:user:proton X-Pm-Message-ID: 0f42e75e612e9467429412ae432aab55b1da5586 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tuesday, November 26th, 2024 at 3:57 PM, Andrew Cooper wrote: >=20 >=20 > On 26/11/2024 11:21 pm, Denis Mukhin via B4 Relay wrote: >=20 > > The patch series introduces initial in-hypervisor emulator for > > NS8250/NS16x50-compatible UARTs under CONFIG_HAS_VUART_NS8250. > >=20 > > In parallel domain creation scenario (hyperlaunch), NS8520 emulator hel= ps > > early guest OS bringup debugging, because it eliminates dependency on t= he > > external emulator being operational by the time domains are created. Al= so, > > there's no early console facility similar to vpl011 to support x86 gues= t OS > > bring up. > >=20 > > The NS8250 emulator is disabled by default. > >=20 > > Series > > =3D=3D=3D=3D=3D=3D > > - patches 1-2: some miscellaneous random fixes, added into the series > > because I stepped into those while debugging NS8250 emulator. > >=20 > > - patches 3-14: preparation fixes for xen console and NS8250 emulator. > >=20 > > - patches 15-29: xen console driver cleanup and preparation for enablin= g > > physical serial console focus assignment to the guest VM w/ virtual NS8= 250. > >=20 > > - patches 30-36: initial NS8250 emulator. That adds the I/O port emulat= or > > for legacy PC COM UARTs, Kconfig option, enabling emulator and libxl > > plumbing. > >=20 > > Limitations > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > - Only x86; > > - Only Linux guest tested so far; > > - Only legacy COM{1,2,3,4} resources, no customization; > > - Only Xen console as a backend, no inter-domain communication (similar= to > > vpl011 on Arm); > > - Only 8-bit characters; > > - Baud rate is not emulated; > > - FIFO-less mode is not emulated properly; > > - RX FIFO interrupt moderation (FCR) is not emulated properly, TL16C750 > > has special FCR handling; > > - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and > > friends); > > - Assumes no ISA-device IRQ sharing; > > - MMIO-based UART is not supported. > >=20 > > Testing > > =3D=3D=3D=3D=3D=3D=3D > >=20 > > I tested boot of HVM linux guest w/ OVMF as the virtual firmware. > >=20 > > The emulator, if enabled via CONFIG_HAS_VUART_NS8250=3Dy, will use COM1= (0x3f8) > > resources by default. > >=20 > > To test w/ virtual COM1, the guest kernel parameters should contain > > earlycon=3Duart,io,0x3f8,115200n8 console=3Duart,io,0x3f8,115200n8 > >=20 > > Xen is able to forward physical console input to the domain w/ virtual = NS8250. > > To switch the console focus press Ctrl+aaa. If console=3D is given to t= he HVM > > kernel, then the user shall be able to see the login prompt on xen cons= ole once > > console focus is switched to the HVM guest. > >=20 > > Signed-off-by: Denis Mukhin dmukhin@ford.com >=20 >=20 > Hello, >=20 > Thankyou for this. It's an excellent start for first posting to the list. >=20 > Two things stand out at a glance. >=20 > First, xmalloc/free are the expected functions to use, and kmalloc/free > are not equivalent. We have some drivers ported from Linux, hence the > compatibility, and if it needs to extend beyond smmu.c then there's > linux-compat.h where definitions can live, but we really don't want them > visible generally. Dropped in v2: https://lore.kernel.org/xen-devel/20241205-vuart-ns8250-v1-0-e9aa923127eb= @ford.com/ >=20 > Second and more importantly, I'm afraid this won't pass CI right now. > Your function pointees (e.g. ns8250_iir_check_lsi()/etc) need a cf_check > attribute on them, in order to function when running on CET-IBT capable > hardware. >=20 > From the root of the Xen tree, if you run: >=20 > CONTAINER=3Dbookworm-x86_64-gcc-ibt ./automation/scripts/containerize >=20 > then you'll get a build environment with suitable diagnostics. > Unfortunately we're still relying on an out-of-tree GCC patch to have a > compiler that can point out the problems at build time, as opposed to > encountering the #CP exceptions at runtime. Addressed in v2. Thanks for help w/ fixing CI! >=20 >=20 > I'll try to have a closer look at the rest of the series tomorrow. >=20 > ~Andrew From xen-devel-bounces@lists.xenproject.org Sat Dec 07 07:04:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 07 Dec 2024 07:04:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850524.1264963 (Exim 4.92) (envelope-from ) id 1tJorL-0003Ri-Of; Sat, 07 Dec 2024 07:04:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850524.1264963; Sat, 07 Dec 2024 07:04:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJorL-0003Ph-HR; Sat, 07 Dec 2024 07:04:11 +0000 Received: by outflank-mailman (input) for mailman id 850524; Fri, 06 Dec 2024 21:41: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 1tJg5D-00054E-MF for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 21:41:55 +0000 Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e884606d-b41a-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 22:41:53 +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: e884606d-b41a-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1733521312; x=1733780512; bh=BwyTENd53pWG9rVYikh7s1bzM6k0q6lHb4xRAhQc3nI=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=N9xYdg3CL0IGQsaFolGGKSJIjPQiztU+euwsA/KyL+GKhGjbJ876VFk6/Mr7RjBgr SPVN+eOKhZ6rfKpxlA08mT6MjfX8iJN8mGt5MzIgF9PKk7AIq/bBxAHuoLp3BMZ4iq /DRVjJmMWLthVKVA1r3UKhh2JJB2K8i899rg+kLSpBMwmZmIOPk2tW9SeUCSkWZqWs w9JlpXdIOEwB81mwzj0PhwxHUT/6GOdzaPxXRjazPL0l+cMVQ4/hahll7xC15E14+6 CC9UXITh1ivm7U9BehTvQAM9nRuzRhaSiuvrh2tHgwdQG2znuJTehdXqX//ac33pG9 I77iBFHItoKwA== Date: Fri, 06 Dec 2024 21:41:48 +0000 To: Jan Beulich From: Denis Mukhin Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH 00/36] Introduce NS8250 UART emulator Message-ID: In-Reply-To: <298c4fb8-4879-4471-90c0-3a4aa0151686@suse.com> References: <20241126-vuart-ns8250-v1-v1-0-87b9a8375b7a@ford.com> <298c4fb8-4879-4471-90c0-3a4aa0151686@suse.com> Feedback-ID: 123220910:user:proton X-Pm-Message-ID: e24b58036d791da080486844b71cbec556946bc6 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tuesday, November 26th, 2024 at 11:26 PM, Jan Beulich wrote: >=20 >=20 > On 27.11.2024 00:57, Andrew Cooper wrote: >=20 > > On 26/11/2024 11:21 pm, Denis Mukhin via B4 Relay wrote: > >=20 > > > The patch series introduces initial in-hypervisor emulator for > > > NS8250/NS16x50-compatible UARTs under CONFIG_HAS_VUART_NS8250. > > >=20 > > > In parallel domain creation scenario (hyperlaunch), NS8520 emulator h= elps > > > early guest OS bringup debugging, because it eliminates dependency on= the > > > external emulator being operational by the time domains are created. = Also, > > > there's no early console facility similar to vpl011 to support x86 gu= est OS > > > bring up. > > >=20 > > > The NS8250 emulator is disabled by default. > > >=20 > > > Series > > > =3D=3D=3D=3D=3D=3D > > > - patches 1-2: some miscellaneous random fixes, added into the series > > > because I stepped into those while debugging NS8250 emulator. > > >=20 > > > - patches 3-14: preparation fixes for xen console and NS8250 emulator= . > > >=20 > > > - patches 15-29: xen console driver cleanup and preparation for enabl= ing > > > physical serial console focus assignment to the guest VM w/ virtual N= S8250. > > >=20 > > > - patches 30-36: initial NS8250 emulator. That adds the I/O port emul= ator > > > for legacy PC COM UARTs, Kconfig option, enabling emulator and libxl > > > plumbing. > > >=20 > > > Limitations > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > - Only x86; > > > - Only Linux guest tested so far; > > > - Only legacy COM{1,2,3,4} resources, no customization; > > > - Only Xen console as a backend, no inter-domain communication (simil= ar to > > > vpl011 on Arm); > > > - Only 8-bit characters; > > > - Baud rate is not emulated; > > > - FIFO-less mode is not emulated properly; > > > - RX FIFO interrupt moderation (FCR) is not emulated properly, TL16C7= 50 > > > has special FCR handling; > > > - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and > > > friends); > > > - Assumes no ISA-device IRQ sharing; > > > - MMIO-based UART is not supported. > > >=20 > > > Testing > > > =3D=3D=3D=3D=3D=3D=3D > > >=20 > > > I tested boot of HVM linux guest w/ OVMF as the virtual firmware. > > >=20 > > > The emulator, if enabled via CONFIG_HAS_VUART_NS8250=3Dy, will use CO= M1 (0x3f8) > > > resources by default. > > >=20 > > > To test w/ virtual COM1, the guest kernel parameters should contain > > > earlycon=3Duart,io,0x3f8,115200n8 console=3Duart,io,0x3f8,115200n8 > > >=20 > > > Xen is able to forward physical console input to the domain w/ virtua= l NS8250. > > > To switch the console focus press Ctrl+aaa. If console=3D is given to= the HVM > > > kernel, then the user shall be able to see the login prompt on xen co= nsole once > > > console focus is switched to the HVM guest. > > >=20 > > > Signed-off-by: Denis Mukhin dmukhin@ford.com > >=20 > > Hello, > >=20 > > Thankyou for this. It's an excellent start for first posting to the lis= t. >=20 >=20 > +1 >=20 > > Two things stand out at a glance. > >=20 > > First, xmalloc/free are the expected functions to use, >=20 >=20 > Small correction - as of their introduction, it's xvmalloc() etc and xvfr= ee() > which are to be used in new code. Addressed in v2. >=20 > One other, more general remark: Please send patches To: the list, with > maintainers Cc-ed. And please compose the Cc: lists per-patch - looking a= t > patch 2, there should really have been just a single person (Daniel) on C= c. >=20 > Jan From xen-devel-bounces@lists.xenproject.org Sat Dec 07 07:04:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 07 Dec 2024 07:04:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850520.1264951 (Exim 4.92) (envelope-from ) id 1tJorL-0003L0-7u; Sat, 07 Dec 2024 07:04:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850520.1264951; Sat, 07 Dec 2024 07:04:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJorL-0003Kt-57; Sat, 07 Dec 2024 07:04:11 +0000 Received: by outflank-mailman (input) for mailman id 850520; Fri, 06 Dec 2024 21:33: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 1tJfwi-0003so-Sm for xen-devel@lists.xenproject.org; Fri, 06 Dec 2024 21:33:10 +0000 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id addd39ff-b419-11ef-99a3-01e77a169b0f; Fri, 06 Dec 2024 22:33:06 +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: addd39ff-b419-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=kachd45jjna2bfmskmv7qgdoua.protonmail; t=1733520784; x=1733779984; bh=a28murfzlss628d/kTMfKQcWna9mVpTv8n6pyLK5+sU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=OgHA6cn9+BTQmnZOw2/b7ZRNDyVf48ruoWTAupf81rdOPY8TJXotiml5R5xCm0cUE 4GC+EuHHs1GYDpPSRrCRGBSszt+Wqjx5CVr2oMM1wCUT6dYoQqG2FFFPixqarOZxNN TjgSkouMmbZdghTCzcgSpRtJC+FJRbToBozZDLQBFa7Y96bP0YW28gVjAsO0YYomXX npPIrFFtjZtyKCZKv5aZlepHQmFXnIjK9zZYPpxF7q/yvrnHi9m8LUjGXwslO9QJnC xGvIuPyg0IxOGIRU8wuuFu9bE3coynf0zupVI4IQqlEpIIx0jtBSkD9qbT1Su/GYSd wpgR4EozR3icg== Date: Fri, 06 Dec 2024 21:32:57 +0000 To: oleksii.kurochko@gmail.com From: Denis Mukhin Cc: dmukhin@ford.com, Jan Beulich , Andrew Cooper , =?utf-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Rahul Singh , Volodymyr Babchuk , Alistair Francis , Bob Eshleman , Connor Davis , Shawn Anastasio , Anthony PERARD , Juergen Gross , Christian Lindig , David Scott , =?utf-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel@lists.xenproject.org Subject: Re: [PATCH 09/36] riscv/domain: introduce domain_has_vuart() Message-ID: In-Reply-To: References: <20241126-vuart-ns8250-v1-v1-0-87b9a8375b7a@ford.com> <20241126-vuart-ns8250-v1-v1-9-87b9a8375b7a@ford.com> Feedback-ID: 123220910:user:proton X-Pm-Message-ID: b049a544b06de699c41cef9d7477863568cdd764 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wednesday, November 27th, 2024 at 5:02 AM, oleksii.kurochko@gmail.com wrote: >=20 >=20 > On Tue, 2024-11-26 at 15:21 -0800, Denis Mukhin via B4 Relay wrote: >=20 > > From: Denis Mukhin dmukhin@ford.com > >=20 > > Introduce domain_has_vuart() for RISC-V port to be used in the > > console driver. > >=20 > > Signed-off-by: Denis Mukhin dmukhin@ford.com > > --- > > xen/arch/riscv/include/asm/domain.h | 2 ++ > > 1 file changed, 2 insertions(+) > >=20 > > diff --git a/xen/arch/riscv/include/asm/domain.h > > b/xen/arch/riscv/include/asm/domain.h > > index > > c3d965a559b6ce3661bf17166d0c51853ff295a2..efbc4f1ea2619a187fe30ede17d > > 96de01e599220 100644 > > --- a/xen/arch/riscv/include/asm/domain.h > > +++ b/xen/arch/riscv/include/asm/domain.h > > @@ -10,6 +10,8 @@ struct hvm_domain > > uint64_t params[HVM_NR_PARAMS]; > > }; > >=20 > > +#define domain_has_vuart(d) false > > + > > struct arch_vcpu_io { > > }; >=20 >=20 > LGTM: Reviewed-by: Oleksii Kurochko oleksii.kurochko@gmail.com Thanks! >=20 >=20 > Probably it would be nice instead of having stub ( #define > domain_has_vuart(d) false ) in arch specific code, just ifdef-ing it > and put somewhere in > to not introduce this definition for each architecture >=20 > which doesn't support vuart now. Actually, my thought was adding arch-independent vuart layer which can call into vpl011, duart or ns8250. This way, domain_has_vuart() will move there, along w/ APIs which hooked into Xen console driver (e.g. ns8250's vuart_putchar()) will be all there as well. I kept this stub as is for now (in the follow on v2). >=20 > Thanks. >=20 > ~ Oleksii From xen-devel-bounces@lists.xenproject.org Sat Dec 07 07:15:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 07 Dec 2024 07:15:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850576.1264981 (Exim 4.92) (envelope-from ) id 1tJp1w-000665-Km; Sat, 07 Dec 2024 07:15:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850576.1264981; Sat, 07 Dec 2024 07:15: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 1tJp1w-00065y-Hg; Sat, 07 Dec 2024 07:15:08 +0000 Received: by outflank-mailman (input) for mailman id 850576; Sat, 07 Dec 2024 07:15: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 1tJp1u-00065s-Gn for xen-devel@lists.xenproject.org; Sat, 07 Dec 2024 07:15:06 +0000 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f970e34d-b46a-11ef-99a3-01e77a169b0f; Sat, 07 Dec 2024 08:15:02 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 0B1055C448A; Sat, 7 Dec 2024 07:14:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0CF90C4CECD; Sat, 7 Dec 2024 07:14:59 +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: f970e34d-b46a-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733555700; bh=oAnCIry7zz0LHB2JW5rkUj+VTlRZl6GeP5F62hw39yQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=py7KvUFtZppqNtobuVWrAtrD0KzRh3xrhqdYXD4b2BBIl+lqwCXNYgtsisWjkwNu4 H2AbmUTKTvXiw+Y85xQCkb57jphuQiRBjZrSBntJWxcGDgYBA0dgZWrvVbcqxduhVY 5iZcI15Cyhok4bRWttmALPJulLQ1zBaHTXWjhDgcSZxdjTdVTPGwOzv/B/9PJKpU6g 64nGyRFfxYBRm4tPoKnTtycZJfxHNNb9YyTnKlIP3LDkIFu1o00VS5XK6SaXz11ElV aLH/lhF6Qd+h+H1ZpDPlo9b57QnW/KbXG3hz/maOo0seAu0VG+Wtqz9TnT8JSYfTZF JKIVeHHZys28Q== Date: Sat, 7 Dec 2024 07:14:58 +0000 From: Wei Liu To: "Kirill A. Shutemov" Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , "H. Peter Anvin" , Paolo Bonzini , Vitaly Kuznetsov , Juergen Gross , Boris Ostrovsky , Gaosheng Cui , Michael Roth , Tom Lendacky , Ashish Kalra , Kai Huang , Andi Kleen , Sean Christopherson , Xiaoyao Li , linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org, Dave Hansen Subject: Re: [PATCH, RESEND] x86/mtrr: Rename mtrr_overwrite_state() to guest_force_mtrr_state() Message-ID: References: <20241202073139.448208-1-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241202073139.448208-1-kirill.shutemov@linux.intel.com> On Mon, Dec 02, 2024 at 09:31:39AM +0200, Kirill A. Shutemov wrote: > Rename the helper to better reflect its function. > > Signed-off-by: Kirill A. Shutemov > Suggested-by: Dave Hansen > Acked-by: Dave Hansen > --- > arch/x86/hyperv/ivm.c | 2 +- Acked-by: Wei Liu From xen-devel-bounces@lists.xenproject.org Sat Dec 07 10:51:46 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 07 Dec 2024 10:51:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850599.1264991 (Exim 4.92) (envelope-from ) id 1tJsPD-0007AD-8x; Sat, 07 Dec 2024 10:51:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850599.1264991; Sat, 07 Dec 2024 10:51: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 1tJsPD-0007A6-6G; Sat, 07 Dec 2024 10:51:23 +0000 Received: by outflank-mailman (input) for mailman id 850599; Sat, 07 Dec 2024 10:51: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 1tJsPB-0007A0-5J for xen-devel@lists.xenproject.org; Sat, 07 Dec 2024 10:51:21 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2062b.outbound.protection.outlook.com [2a01:111:f403:2415::62b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 30085372-b489-11ef-a0d5-8be0dac302b0; Sat, 07 Dec 2024 11:51:19 +0100 (CET) Received: from CH5PR05CA0024.namprd05.prod.outlook.com (2603:10b6:610:1f0::29) by BY5PR12MB4148.namprd12.prod.outlook.com (2603:10b6:a03:208::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.11; Sat, 7 Dec 2024 10:51:14 +0000 Received: from CH2PEPF0000013D.namprd02.prod.outlook.com (2603:10b6:610:1f0:cafe::d5) by CH5PR05CA0024.outlook.office365.com (2603:10b6:610:1f0::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.11 via Frontend Transport; Sat, 7 Dec 2024 10:51:14 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CH2PEPF0000013D.mail.protection.outlook.com (10.167.244.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Sat, 7 Dec 2024 10:51:13 +0000 Received: from jenkins-julia.amd.com (10.180.168.240) 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; Sat, 7 Dec 2024 04:51:08 -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: 30085372-b489-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mZLARswOq4vxTYQ5L/ALSx77d9uZfmI6AbW6OR4Er8WLOArUXFO0hX5DU9facAqstLizPTHp5VwQcxdc13/sgoRr/O9ButblsETIM5FjoJmbIFS+v/v6MTF5GnVI2CA85rOvUizSpUjKDOP0ZelfOiyZ9SoOlCdCeVELJXTq8/VWfq6nKvdrgq8vCWdidkvPXNcwC9m6aHjmw1Ge0eNygotFl7ZpRCKkPd5W39bEBUPydqObQRkVk07vIbuvvGL93l56lVK2wOXym6zwh2DU6LcpzIB2AVjvVgr+ucWgzAebMCCByAEukGGUFHb/Hujuemb+Kjl9dddUHGrVmRT1ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=j3NJSEdVo5KlzEiay2XUDjqLBYgfkv1hWCm9vS9ugrs=; b=XQbXfEQnMn0L+hqWbQVA+i1IDB+h2VQrfxIbPokL/Q0lShXSJhAvuHgx5RYdEiGpuI94oBlxPKkLeRndjwbha9F/JogRHIKChNbZLKeNg1ZaPouD6kA81gWMADB45AIyuv9kyybfzhwHB1GPMmQWMZaAd3dIO5YmUUyPhGQQGw8DHCQI0hqfXIwNSQ20RTctnX5+eDnf0P9Rt3dSCqgCK4++hR1Wjfw5e5M6INdxd5t/HrsTjU+W1LpUo5b2BxVtBjtNlp5tZFDT4oVf61VX8F7A0xa3Zokhn908A+issxIxeEaKhlj2US4Vp0qOoeU+q9/n2R2kJNJSDyQb2upbPA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=redhat.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=j3NJSEdVo5KlzEiay2XUDjqLBYgfkv1hWCm9vS9ugrs=; b=BDusMLbwmyovvjH3FCjJApxWII0hXqBuGEqabqQq33Wa0NK7pp5hFPLUFYAg1MG/cdu0CDTvcRuBQwGTbyVjrR61Ti7ylC85G9dgMKx9vnDTh+jlycaxCAQhSnAWMast48IKDpgvZ+veYZDaUv7fJRkr3HhJYwbmRxYeMROrpa0= 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=SATLEXMB04.amd.com; pr=C From: Julia Zhang To: David Airlie , Gerd Hoffmann , Gurchetan Singh , Chia-I Wu , , , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , CC: Alex Deucher , =?UTF-8?q?Christian=20K=C3=B6nig?= , Daniel Vetter , Chen Jiqian , Huang Rui , Penny Zheng , Zhu Lingshan , Anthony PERARD , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Paul Durrant , Julia Zhang Subject: [PATCH 0/3] virtgpu: check if P2P is possiable or not Date: Sat, 7 Dec 2024 18:50:20 +0800 Message-ID: <20241207105023.542399-1-julia.zhang@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PEPF0000013D:EE_|BY5PR12MB4148:EE_ X-MS-Office365-Filtering-Correlation-Id: e51dea4b-ee44-41df-ebbf-08dd16ad11c8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|1800799024|82310400026|7416014|376014|921020; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?YFw/sjdbC4eGfb4g5dXVndGFO2L7uImwUJh7oHYCsJsfdwT79Q9INuj3739D?= =?us-ascii?Q?V/Pa8HVNLZY8szM8uwH1ZwMqywy2B5I8HTE0AWiMws2A8r+ICBNq7QBBmiVO?= =?us-ascii?Q?xbe1tqagwffnN0DZvHszJRZvqPxMZEVXgihgdhwGoVCziMf7c8AYBlPvWANc?= =?us-ascii?Q?7KbyiLzoYgUSPHafUYOJeoFb0/Za3HjMy3PoqzBteHqJrp6xE+3TvAQSBFyE?= =?us-ascii?Q?EwisEZFQTkMLIb//N2CJvr856XTijzc0NB4u0zccr2fw6wteXEK279gh/uUz?= =?us-ascii?Q?Z//6Qpb9EMu4Wg53Fuyd8VG9tdrwNH+EK1mtGuu5gAYkoUt3mOpb+KQJttzH?= =?us-ascii?Q?ql/9PpvSXAjMlPLnz+KnFcff9hmnDrCrSO9TuGmuUUl/WHu/GsujrEO98M3H?= =?us-ascii?Q?TnPyypJpsghiFhJfq1jzU22dLhUFdVfRSu+Pzb/YkzG/scZjsraKqUQJhzZv?= =?us-ascii?Q?uxmUzI5DptNq/6aLO0QrClZ1sTh+g4QZNavIPbcbyngdzamnMq5j8zIg+Fed?= =?us-ascii?Q?t3Zd04IsldfNnp0UxIHOY33wzTXOrOz3Y/ipIEBu+Ci2oh4INR5CS3hqzDDA?= =?us-ascii?Q?GGSveS3NAimtp1tYz3WDVnVT0F9DjXiAOnVH9MW43xkzbfhOpadXSSE5k2kH?= =?us-ascii?Q?jb0dpuDWswG9x1m/1futWep5fJD7zDwNrY4WZVo8YLFQm7uWwMHKebIX7lKe?= =?us-ascii?Q?g/nl24KGV1E+OtV4dvwG8asmZUHtkq50Lw1djYhVy9RplmOSDPEPPp5p0E9w?= =?us-ascii?Q?P8mesnyC5hVssTrw+Rj1dsn+aYqaxoozJVc8LdS7mE39U14Q8TgH6xZ0OeJE?= =?us-ascii?Q?DK6AECVmvDq5yPomM5RqHJBjvyXYdqIHLhHwQ3cJO4cv7XEfXu9i0aYOtVJv?= =?us-ascii?Q?f5+HoS+UECkT481tmb7UrbnyiTMvRDElpEEPdNxpJmBoU0yHGxxwvrgOd6ef?= =?us-ascii?Q?g7kKrsxY43n64exIJZZTtU/cPFMxExrttK1cCVtIS59+h7L2FL0zxEji4Gbb?= =?us-ascii?Q?t+dCeWYuOFKokLSlTe2x211ZOXXNOiVCFLUyB52cKhRnjrCZum2PzA3DwmI5?= =?us-ascii?Q?Krp6SvYUL6KMODM5g2BmEWLmo7reU373MD6qrI4zvsZMzDhM4dkkbr3RJIsg?= =?us-ascii?Q?AyyX4VhRzOHCUI8pdPgR38VTaOQN6r6vfPgc5v1b3BAAHL7DizpQGSYtBbfQ?= =?us-ascii?Q?1fKRTdAS6OtcDpFknWDUb6c9+RVXvuAetzj4wcHXGAJsnetkufGtNijoOJJB?= =?us-ascii?Q?4dWmH7rT2yjvYuR70DQoTeQTyF5ZtzZW6NDcqJ7qQzG06y+kEbj9UGGDIpkr?= =?us-ascii?Q?TQ89nkMXlyqKk8AkdXXtKRnec8HyBU7tmZr7NnUFi0MkhwgAgiHHvtNAXUNe?= =?us-ascii?Q?UBMaIrkqTcRkxvbmW0F21JTfbwEixNfXchqhP6qc+Dj4oMmu9uojn3tE8+tW?= =?us-ascii?Q?vwjqtZSqhAIh72urGZHbcJBybq9UngI+axNsetqo8p4msM5YPSJ1gg=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(7416014)(376014)(921020);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2024 10:51:13.9074 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e51dea4b-ee44-41df-ebbf-08dd16ad11c8 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH2PEPF0000013D.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4148 To implement dGPU prime feature, virtgpu needs to import/export buffer between virtio iGPU and passthrough dGPU. Before that, virtgpu should check if P2P is possible or not. But calling function pci_p2pdma_distance in guest VM will only get virtual p2pdma_distance instead of real physical p2pdma_distance. So this series introduce an implementation of virtgpu device_attach callback to get p2pdma_distance. And also adds a new virtgpu command to pass PCI notations from guest to host and a new xen privcmd to get physical p2pdma_distance according to the PCI notations in host. Julia Zhang (3): xen:get p2pdma_distance virtgpu: get p2pdma_distance drm/virtio: Implement device_attach drivers/gpu/drm/virtio/virtgpu_drv.h | 17 ++++++++ drivers/gpu/drm/virtio/virtgpu_prime.c | 59 +++++++++++++++++++++++++- drivers/gpu/drm/virtio/virtgpu_vq.c | 53 +++++++++++++++++++++++ drivers/xen/privcmd.c | 42 ++++++++++++++++++ include/uapi/linux/virtio_gpu.h | 19 +++++++++ include/uapi/xen/privcmd.h | 12 ++++++ 6 files changed, 201 insertions(+), 1 deletion(-) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat Dec 07 10:52:30 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 07 Dec 2024 10:52:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850611.1265002 (Exim 4.92) (envelope-from ) id 1tJsQI-0007i4-Mn; Sat, 07 Dec 2024 10:52:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850611.1265002; Sat, 07 Dec 2024 10:52: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 1tJsQI-0007hx-Jn; Sat, 07 Dec 2024 10:52:30 +0000 Received: by outflank-mailman (input) for mailman id 850611; Sat, 07 Dec 2024 10:52: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 1tJsQH-0007hr-Q8 for xen-devel@lists.xenproject.org; Sat, 07 Dec 2024 10:52:29 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on20615.outbound.protection.outlook.com [2a01:111:f403:2416::615]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 59305827-b489-11ef-a0d5-8be0dac302b0; Sat, 07 Dec 2024 11:52:28 +0100 (CET) Received: from CH2PR18CA0023.namprd18.prod.outlook.com (2603:10b6:610:4f::33) by SA1PR12MB8119.namprd12.prod.outlook.com (2603:10b6:806:337::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Sat, 7 Dec 2024 10:52:21 +0000 Received: from CH2PEPF00000140.namprd02.prod.outlook.com (2603:10b6:610:4f:cafe::e1) by CH2PR18CA0023.outlook.office365.com (2603:10b6:610:4f::33) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.12 via Frontend Transport; Sat, 7 Dec 2024 10:52:17 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CH2PEPF00000140.mail.protection.outlook.com (10.167.244.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Sat, 7 Dec 2024 10:52:17 +0000 Received: from jenkins-julia.amd.com (10.180.168.240) 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; Sat, 7 Dec 2024 04:52:12 -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: 59305827-b489-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SlvR02hKEYgqecz9uAmyFruuuJEldYY2K2oz+/k5/jqjqpwPKQfUekkQnKpKc0mv47KjjSDn5v3O8r9YTLPVkoPPb9/G+6XTMomnrEcTj5GQsS6e192FtrDO7GkFSAFyQSC/OQWj91In3QSsJtaVT1AKBEd36cz3Fu82oI+5bS7gwSdydokkMCNTYErfx2ux2MaOIjQXjaJ08NBcgaGRqSmpxZXg6/pkx+R4+L1mQrOieMfb/vdloLoiUZWXiaLMBfwxZZUGLMpCBni2fZq51v2vLI6XpbBKtjYMrNtZNVCBAejqdJ1NhscRbY+L8ORvxJ6TXTui1AbXnfnokMt5Sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3z7f/RAhcwAHkXYmUepiHSK25Jlz0SNuaumnbydHfcc=; b=XlfTi3mH4Fu7BLO+vkBCMu3xvYGm6vgCBpORbxO6uetUBPOnJUCPXsVoRN9hAzESvASBLDkj9keVMZ5hZEEF44d07GiauQALwQ2z46YuxTMREhaX/AA6dHuKHaXk89xXNOMKyfJYsAeqjePQat0rhGYI4mVtW+xsXbK9L+nvjoQOuf0jWcxkLda+dh4iKu53eSJS9ICPx/FaI+farccp6Ff+YQBkgJ9wr2QrWCpyNJlGklAuMeYpiFk5/x/wL75nHL5EEo+Ff7lTeczp03qGeU9rLQjUvmdGCnOQLkEZo62sFNtpLCJSLILIN4Q/OMX5SldaAXxl+fRAG6kpeDaRiw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=redhat.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=3z7f/RAhcwAHkXYmUepiHSK25Jlz0SNuaumnbydHfcc=; b=Xhugr7oUoK1G6fhyrFgCD8kKP0JKFbNK8HWiq5awZ+LF78bVE7ecksUnCnTbU2V9FHJWLVvxFbcNHp1Aayufp8LyPu/WeA3ByXk2jKNMkgFpx4BujnF+mz9ZXjYYVXJyt0S4ygh+kXeIQnyghBYYRI3PxFIEvj/ogHTPjTpNVMk= 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=SATLEXMB04.amd.com; pr=C From: Julia Zhang To: David Airlie , Gerd Hoffmann , Gurchetan Singh , Chia-I Wu , , , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , CC: Alex Deucher , =?UTF-8?q?Christian=20K=C3=B6nig?= , Daniel Vetter , Chen Jiqian , Huang Rui , Penny Zheng , Zhu Lingshan , Anthony PERARD , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Paul Durrant , Julia Zhang Subject: [PATCH 1/3] xen:get p2pdma_distance Date: Sat, 7 Dec 2024 18:50:22 +0800 Message-ID: <20241207105023.542399-2-julia.zhang@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241207105023.542399-1-julia.zhang@amd.com> References: <20241207105023.542399-1-julia.zhang@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PEPF00000140:EE_|SA1PR12MB8119:EE_ X-MS-Office365-Filtering-Correlation-Id: ecae0a17-be8f-4c2e-da1a-08dd16ad37e1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|36860700013|7416014|376014|921020; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?DU1i4lB89NXMg++EWvDHebP0wVGJ0sI3UJ+iKv+sVi2uSJTyV7UjIJZzESkh?= =?us-ascii?Q?xsJ8sDlpy+OZD0o9cptA0TCn+aMbZV6P/W0WEbxeG+GyGGVKv2sTHBzY6/L4?= =?us-ascii?Q?qlIkhb9h23QT03iB6e3cTwxsdMANV5LmdvrX/iU/1hdj7uqDyVU6dC8vbAVA?= =?us-ascii?Q?ZmIcPs7aoGEl04/3GUX1tJ6qrAqFTO2pY27wKQDq/fBX1lTBZorHVP/d9gYl?= =?us-ascii?Q?ExJ1flL3I//ikRm3tXRVRmgH6Kb3lWLYjdR4qRLPP94oEbva+3Tp0599kx97?= =?us-ascii?Q?Xhsh2Qw6QACwe9m7zhRmmkWvkmVOVXciQMyhLdGZ7R20Nf9t6Tu5Vf8TJrti?= =?us-ascii?Q?PaV/HoSAF5vTSzlz/Jm9sLe8jUDkH08Z6AxDJLJs7tbfDWvb2K1y7ArN94kQ?= =?us-ascii?Q?C69eZuNwA90xnKKeFxyPDgfBCF9FnmFK5sRo/i05kPzqiMisbGw5Or528oGu?= =?us-ascii?Q?c18U5xwrpt3JDT5283MDFGV9SmKUo77dFIX4Eao6BYOs45Fjw2Z+QrxSNzih?= =?us-ascii?Q?cNSEb31XUiJvK5SDH0PuiLRP+rL6SRc4IVssKtqAlz9kgxUaNlk2FMEJNosw?= =?us-ascii?Q?yrK8PO+TG+EGemGeM1Gv/F16g1CK8PI9N/ccTcTubHl8BZjqhpT8X6161bQF?= =?us-ascii?Q?JejXn6NT5kD7yK3hWholwbsIltzvYrr0y4zxDMiyd+W5Uv4uGE+cmhFnXcVv?= =?us-ascii?Q?yh1ldoTqhBPdKHnWboNonA4a64gKYFPbiPLhtbbGrqM/Lv89gLYf3xfTb8kU?= =?us-ascii?Q?vVG37IKT+NsgVa7FVb0wdMX/IiYkWpQXgSWlBX/pkae8in/uUdJdCjDk/gIN?= =?us-ascii?Q?X66mcdX8hixyjuYdUmS3+BDvrCmYpi9HHvpiy5EqreGTESGXWHcJzfkUFWEy?= =?us-ascii?Q?M9ffIUkbYpYunh8dAeMfvVaLJ8oo28jsL6uF6QAcm3tSQOlG1X/+GPgEp+Wv?= =?us-ascii?Q?LHCI9rD2IMYpzfLp3Gkf0hNCUqrvFf08D3nGxcNKbprMfHG/spMbf3+TKgMx?= =?us-ascii?Q?2IhZnamIevGEMPzYrUxVb1x1nUWmNCWmsjGyg/I8lOGBYjvwo1bM0qt5hJnc?= =?us-ascii?Q?0dUaOjbcbHVN13tJatnu5DGNTZeuWNUpwU0vF0nZQMnAO8NXvEKAqxeb/ImO?= =?us-ascii?Q?eDeY+ySEiq8y6fDk0k1XfFoSj8jd4Rogc0Twgnc4VSwtbHQnjwz0DFhJrNVW?= =?us-ascii?Q?cZgl1OwjDxnoJzaCuIO6Cs1vJN6rfNY4blVg4LULy5DReVMhvIt02rkQ1Ar1?= =?us-ascii?Q?2M9mz4JIGW5aihL/uqcJcunjw8teB/pye7C8lEU1q22Rg6dkk9myvjR25kfT?= =?us-ascii?Q?Nls6CNN9MQaTawR5eKwxk5Swh1wpK6qXlgbV6A22HwhFqqyX4uZHRh/KLlqV?= =?us-ascii?Q?m/5UImk5FQbyJ0hBavBj9WWDCshUqoYmxdnBCSzF+6zwLxTgZIBpeCTa93TA?= =?us-ascii?Q?WwrhuWzEMU2uI7/F5U8Gbg3Munkp3msIzRIVpP12qLxzo3KgODkpMA=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(7416014)(376014)(921020);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2024 10:52:17.8242 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ecae0a17-be8f-4c2e-da1a-08dd16ad37e1 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH2PEPF00000140.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8119 To get the p2pdma_distance, this create a new privcmd ioctl to calculate p2pdma_distance for two pci devices on the host with pci notations sent from guest virtgpu driver. Signed-off-by: Julia Zhang --- drivers/xen/privcmd.c | 42 ++++++++++++++++++++++++++++++++++++++ include/uapi/xen/privcmd.h | 12 +++++++++++ 2 files changed, 54 insertions(+) diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index 72c161e94731..95f67815a2ef 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -31,6 +31,9 @@ #include #include #include +#include +#include +#include #include #include @@ -977,6 +980,42 @@ static long privcmd_ioctl_map_hva_to_gpfns(struct file *file, void __user *udata return ret; } +static int privcmd_ioctl_p2pdma_distance(struct file *file, void __user *udata) +{ + struct privcmd_p2pdma_distance kdata; + struct pci_dev *provider = NULL; + struct pci_dev *client = NULL; + struct pci_dev *dev = NULL; + enum pci_p2pdma_map_type map; + + if (copy_from_user(&kdata, udata, sizeof(kdata))) + return -EFAULT; + + for_each_pci_dev(dev) { + if (dev->bus->number == kdata.provider_bus && + dev->devfn == PCI_DEVFN(kdata.provider_slot, kdata.provider_func)) { + provider = dev; + } else if (dev->bus->number == kdata.client_bus && + dev->devfn == PCI_DEVFN(kdata.client_slot, kdata.client_func)) { + client = dev; + } else { + continue; + } + } + + if (!provider || !client) { + pr_err("%s fail to get provider or client.\n", __func__); + return -EINVAL; + } + + kdata.distance = pci_p2pdma_distance(provider, &client->dev, false); + + if (copy_to_user(udata, &kdata, sizeof(kdata))) + return -EFAULT; + + return 0; +} + #ifdef CONFIG_XEN_PRIVCMD_EVENTFD /* Irqfd support */ static struct workqueue_struct *irqfd_cleanup_wq; @@ -1684,6 +1723,9 @@ static long privcmd_ioctl(struct file *file, ret = privcmd_ioctl_map_hva_to_gpfns(file, udata); break; + case IOCTL_PRIVCMD_P2PDMA_DISTANCE: + ret = privcmd_ioctl_p2pdma_distance(file, udata); + break; default: break; diff --git a/include/uapi/xen/privcmd.h b/include/uapi/xen/privcmd.h index d131002dd48f..a7ec3704519f 100644 --- a/include/uapi/xen/privcmd.h +++ b/include/uapi/xen/privcmd.h @@ -141,6 +141,16 @@ struct privcmd_map_hva_to_gpfns { int add_mapping; }; +struct privcmd_p2pdma_distance { + __u32 provider_bus; + __u32 provider_slot; + __u32 provider_func; + __u32 client_bus; + __u32 client_slot; + __u32 client_func; + __u32 distance; +}; + /* * @cmd: IOCTL_PRIVCMD_HYPERCALL * @arg: &privcmd_hypercall_t @@ -174,6 +184,8 @@ struct privcmd_map_hva_to_gpfns { _IOW('P', 9, struct privcmd_ioeventfd) #define IOCTL_PRIVCMD_PCIDEV_GET_GSI \ _IOC(_IOC_NONE, 'P', 10, sizeof(struct privcmd_pcidev_get_gsi)) +#define IOCTL_PRIVCMD_P2PDMA_DISTANCE \ + _IOC(_IOC_NONE, 'P', 11, sizeof(struct privcmd_p2pdma_distance)) #define IOCTL_PRIVCMD_MAP_HVA_TO_GPFNS \ _IOC(_IOC_NONE, 'P', 13, sizeof(struct privcmd_map_hva_to_gpfns)) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat Dec 07 10:53:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 07 Dec 2024 10:53:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850620.1265011 (Exim 4.92) (envelope-from ) id 1tJsRE-0008HB-Vo; Sat, 07 Dec 2024 10:53:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850620.1265011; Sat, 07 Dec 2024 10:53: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 1tJsRE-0008H4-Sp; Sat, 07 Dec 2024 10:53:28 +0000 Received: by outflank-mailman (input) for mailman id 850620; Sat, 07 Dec 2024 10:53: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 1tJsRD-0007hr-Vj for xen-devel@lists.xenproject.org; Sat, 07 Dec 2024 10:53:28 +0000 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on20620.outbound.protection.outlook.com [2a01:111:f403:2009::620]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7c5ef923-b489-11ef-a0d5-8be0dac302b0; Sat, 07 Dec 2024 11:53:27 +0100 (CET) Received: from CH0PR03CA0393.namprd03.prod.outlook.com (2603:10b6:610:11b::21) by CY5PR12MB6060.namprd12.prod.outlook.com (2603:10b6:930:2f::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.24; Sat, 7 Dec 2024 10:53:20 +0000 Received: from CH2PEPF00000141.namprd02.prod.outlook.com (2603:10b6:610:11b:cafe::c8) by CH0PR03CA0393.outlook.office365.com (2603:10b6:610:11b::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.12 via Frontend Transport; Sat, 7 Dec 2024 10:53:20 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CH2PEPF00000141.mail.protection.outlook.com (10.167.244.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Sat, 7 Dec 2024 10:53:19 +0000 Received: from jenkins-julia.amd.com (10.180.168.240) 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; Sat, 7 Dec 2024 04:53:14 -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: 7c5ef923-b489-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=S3SgNuJloh2w7NsWi+dU6TBIPFnYbNUmssk0veB2tuuBEkL3QffELJL3sOfFuiS0rSLjirXmOcaE49zHPPJ/dtQaDcyaSxEXCYben+ToimaSCVicZ8aUHnAuGo1k6CW3hv2Ggdsk0Fqn/z797tOtPAzlFNgYkp1XAJc0duTodzG1YBrwdMyB/hSNb6o4A6gPnPGsc8nfk9LgQwrHA2cZST1vnFHjs1ZytPCeDj1uVGgh/RzmMhCLXkIdUFQHDY7NmG5a4O3B+H3+NP42Fe+3A18bd5tTfZvbMCuhA2MNs/5+pGUAxUSdCUZycfZUnVKOnTvyiRfb4H62HCct3XHHvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5cr/hCklb5oOa6uHklyD3rH+9Dy9jZjPa3XjRYdjDB4=; b=fUjCbtjZaPJRPX9eT7y2fM/rx5dj0rps+kBlBJ/QU3U43IgAb4KcI/5BeAETol4E5JvJeKZxTxKFmnsR379W+WSQ/V7yaqofpRWNL1eK7Xct94nmN2sFKYCgiyg7nGBA2F6aqaCFBSwDB2NMcCCmMKywJJE37J3jawfj5YrsfcKKwKXET7lAVUyaUdAbgSH5AnwtiggwR+gLZys6XtmcERdXEUCWImAqVwZ3bOPkpSL4bPAmCWAaO2fS021XsycAviUs4FVmFfflRcJOVAiCBrsuU+mkAvsqMWPvb693IwHRLMTGvxttof83WbxS8iGuadjyXplhsLPQsU/ukmZhbQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=redhat.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=5cr/hCklb5oOa6uHklyD3rH+9Dy9jZjPa3XjRYdjDB4=; b=YeLBTl+N+bwMF6SyPsYGEBI2UVB8ERc5fw12gv/RbKlEtro4JhTra08+C09GSej+yv00egzNcYvnYJZmwTRoRtO+hCwfGIJEr7hy/v7nfwwvOmtIrAZGbqyXmHi3ZC0HP4KW5iObolh1+52RRxaYBpeE9K1f1RpFMHsXFaWPuPo= 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=SATLEXMB04.amd.com; pr=C From: Julia Zhang To: David Airlie , Gerd Hoffmann , Gurchetan Singh , Chia-I Wu , , , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , CC: Alex Deucher , =?UTF-8?q?Christian=20K=C3=B6nig?= , Daniel Vetter , Chen Jiqian , Huang Rui , Penny Zheng , Zhu Lingshan , Anthony PERARD , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Paul Durrant , Julia Zhang Subject: [PATCH 2/3] virtgpu: get p2pdma_distance Date: Sat, 7 Dec 2024 18:50:24 +0800 Message-ID: <20241207105023.542399-3-julia.zhang@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241207105023.542399-1-julia.zhang@amd.com> References: <20241207105023.542399-1-julia.zhang@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PEPF00000141:EE_|CY5PR12MB6060:EE_ X-MS-Office365-Filtering-Correlation-Id: 384bd968-5a51-4c15-8272-08dd16ad5cdb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|82310400026|36860700013|1800799024|921020; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?xl0uOfUoHWJiimtLuJyJGWveCUw234A8KbbNeuLTEzB07oxaVkIS40rRHKOS?= =?us-ascii?Q?1lhOFoKgM6XR80EOvSzB6Cx0J2BV5qhVSXdE13cjNsHyJctIh1O/jV2kUQcR?= =?us-ascii?Q?CpRxoGyTrqnrl2AjUhNX5hYwBdPtJrzbHZQyqAGjvUTN/2GQtFp5htF4pFBm?= =?us-ascii?Q?zIdnNTDLgEcWye22apRsMK/gjWoma/WppMd8d7oNqoV0QyRRT1cvJZJPAHFf?= =?us-ascii?Q?P1jYxDXQPxnTVTWEnRpcGOQluwvKKKID43byi7CBK0sCs04SuOczhJVCqUbr?= =?us-ascii?Q?QiZninOOlZljjQ8gtpAE37jJJSy7hQtf81Ay+b+tWSzQH5YLIXavWnBnH5pW?= =?us-ascii?Q?KWSOOTJ3mE1n1rhTFvJclxZggULyi7o0sFBrzduY9HqOtw1jYExmTSWPH/D2?= =?us-ascii?Q?vxgvwQDAyMe3ebEcAuVFOfVJcjz5tKO3ASCHMLm9CupV/l3kURyaPpZL4W6A?= =?us-ascii?Q?ey1pbYWhRum6xqBuUrhzugsoed6UEFtr5RtLZuqpkXCtmg326/e1hJypOqbB?= =?us-ascii?Q?7Q2+Hx0X6jJ9cS9SVFglh/IxVbNrZQl37qr3ZkoAqBkhz68trGf84graU2xf?= =?us-ascii?Q?Vnif/NhovgNj8GMRaKkySqQ5+Dv6XKPfPK9VGlNdERaSuGDNte/gGkXdD0lI?= =?us-ascii?Q?e7QhqfA43YHK3ptr5y+ngnRh+oL+MCYZ1li/fRwFSZ+BXheLjh4u02a+0WZh?= =?us-ascii?Q?njSPKzZkgNf8ZE8omplAW9Hyu2tNPqnW8olGeHKXFj60KtSZO3eX9NJd042m?= =?us-ascii?Q?KuT8Pw02U+LSPFGMrlurYh/nzwFzv2FbHOYWnp2v2ExD27tuC0GVyWzItFrU?= =?us-ascii?Q?+aQwwrlLabshqPMYzvCTneUZwYesovQPh0rj980PCU9oTbtzVB0i8Ni4RZWD?= =?us-ascii?Q?WjZgdyRi+QspIRacXtZUjntdzs175B2McHdcijbMFW5tgQkIhkEZaxtolzl0?= =?us-ascii?Q?RP20Q+10s2jOqRX5UrfweHnAzU/W+b4S6p0c1TvP2kcV5MqKN4C7TfTeLIJH?= =?us-ascii?Q?ye/kiAkAjNolFe3oa+CiENI7tOdN8rzn9wl1fYaa1MZVTfZBatvFvPTzXdKM?= =?us-ascii?Q?cJEWwAOPnc35fkjNUIIEeJFU0DswXsqVlwTIJkFVZZhNPxYYDsIcsnFd6lMw?= =?us-ascii?Q?H2UJyH6ubNs9w9l9p/sqEUDTkj4A6LmN+gHRMjBXEWflzbtw4dau6FJLLNoY?= =?us-ascii?Q?miN4fHsjjGHJ52kevmx7KJzhqIbN0ROI6fXvo6Mf/nWSOu4ZDRpvR75MfqWP?= =?us-ascii?Q?YA6hZdoFZcjiDPeQ5O56tyctUENqQt7okMlJGaGWeatN29FGlsxyKyPRo525?= =?us-ascii?Q?flc7ksflnKziJA6/Kw+nSwlj9pudlt/S51VBJnn7IBWhMX/HvD/CR928+lwW?= =?us-ascii?Q?OasFCuerAYeYp1VUEpVO1FR25yTwYF/hGpAT0KCN/+2oBXemafti61EI2Fe+?= =?us-ascii?Q?FcphdFQJK2LAzCsu+a+NlzO5OZ80D1/g34h5ReOzitZ96cdR20Pqig=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(376014)(82310400026)(36860700013)(1800799024)(921020);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2024 10:53:19.8740 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 384bd968-5a51-4c15-8272-08dd16ad5cdb 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH2PEPF00000141.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6060 virtgpu driver need to get the p2pdma_distance to decide if virtio iGPU buffer can be imported by passthrough dGPU, which is the main step implement dGPU prime feature. To get the p2pdma_distance, this create a new virtgpu ioctl to send command of getting p2pdma_distance and pci notations of two pci devices from guest to host. Host will handle ioctl to calculate p2pdma_distance for this two pci devices on the host with pci notations sent from guest virtgpu driver. Signed-off-by: Julia Zhang --- drivers/gpu/drm/virtio/virtgpu_drv.h | 17 +++++++++ drivers/gpu/drm/virtio/virtgpu_prime.c | 45 ++++++++++++++++++++++ drivers/gpu/drm/virtio/virtgpu_vq.c | 53 ++++++++++++++++++++++++++ include/uapi/linux/virtio_gpu.h | 19 +++++++++ 4 files changed, 134 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index 64c236169db8..1bbe510c8410 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -87,6 +87,18 @@ struct virtio_gpu_object_params { uint64_t blob_id; }; +struct virtio_gpu_pci_notation { + uint32_t bus; + uint32_t slot; + uint32_t func; +}; + +struct virtio_gpu_p2pdma_distance { + atomic_t p2pdma_state; + uint32_t distance; +}; + + struct virtio_gpu_object { struct drm_gem_shmem_object base; uint32_t hw_res_handle; @@ -488,4 +500,9 @@ void virtio_gpu_vram_unmap_dma_buf(struct device *dev, int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data, struct drm_file *file); +int virtio_gpu_cmd_p2pdma_distance(struct virtio_gpu_device *vgdev, + struct virtio_gpu_pci_notation *provider_params, + struct virtio_gpu_pci_notation *client_params, + struct virtio_gpu_p2pdma_distance *p2pdma_dist); + #endif diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c b/drivers/gpu/drm/virtio/virtgpu_prime.c index 44425f20d91a..4960620eba02 100644 --- a/drivers/gpu/drm/virtio/virtgpu_prime.c +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c @@ -23,6 +23,8 @@ */ #include +#include +#include #include #include "virtgpu_drv.h" @@ -71,6 +73,49 @@ static void virtgpu_gem_unmap_dma_buf(struct dma_buf_attachment *attach, drm_gem_unmap_dma_buf(attach, sgt, dir); } +static int virtgpu_get_p2pdma_distance(struct dma_buf *dma_buf, + struct dma_buf_attachment *attach) +{ + struct drm_gem_object *obj = attach->dmabuf->priv; + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj); + struct drm_device *dev = obj->dev; + struct pci_dev *pdev = to_pci_dev(dev->dev); + struct pci_dev *pci_client; + struct virtio_gpu_pci_notation provider_params = {0}; + struct virtio_gpu_pci_notation client_params = {0}; + struct virtio_gpu_device *vgdev = dev->dev_private; + struct virtio_gpu_p2pdma_distance p2pdma_dist = {0}; + int ret = 0; + + attach->peer2peer = false; + if (pci_p2pdma_distance(pdev, attach->dev, false) < 0) + return 0; + + provider_params.bus = pdev->bus->number; + provider_params.slot = PCI_SLOT(pdev->devfn); + provider_params.func = PCI_FUNC(pdev->devfn); + pci_client = to_pci_dev(attach->dev); + client_params.bus = pci_client->bus->number; + client_params.slot = PCI_SLOT(pci_client->devfn); + client_params.func = PCI_FUNC(pci_client->devfn); + ret = virtio_gpu_cmd_p2pdma_distance(vgdev, &provider_params, &client_params, &p2pdma_dist); + if (ret) + return ret; + + ret = wait_event_timeout(vgdev->resp_wq, + atomic_read(&p2pdma_dist.p2pdma_state), + 5 * HZ); + if (!ret) + return -EBUSY; + + smp_rmb(); + + if (p2pdma_dist.distance >= 0) + attach->peer2peer = true; + + return 0; +} + static const struct virtio_dma_buf_ops virtgpu_dmabuf_ops = { .ops = { .cache_sgt_mapping = true, diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index 0d3d0d09f39b..69c33df61b88 100644 --- a/drivers/gpu/drm/virtio/virtgpu_vq.c +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c @@ -1197,6 +1197,28 @@ static void virtio_gpu_cmd_resource_map_cb(struct virtio_gpu_device *vgdev, wake_up_all(&vgdev->resp_wq); } +static void virtio_gpu_cmd_p2pdma_distance_cb(struct virtio_gpu_device *vgdev, + struct virtio_gpu_vbuffer *vbuf) +{ + struct virtio_gpu_resp_distance *resp = + (struct virtio_gpu_resp_distance *)vbuf->resp_buf; + struct virtio_gpu_p2pdma_distance *p2pdma_dist = vbuf->resp_cb_data; + + vbuf->resp_cb_data = NULL; + + if (resp->hdr.type != VIRTIO_GPU_RESP_OK_P2PDMA_DISTANCE) { + atomic_set(&p2pdma_dist->p2pdma_state, 0); + goto out; + } + + p2pdma_dist->distance = le32_to_cpu(resp->distance); + smp_wmb(); + atomic_set(&p2pdma_dist->p2pdma_state, 1); + +out: + wake_up_all(&vgdev->resp_wq); +} + int virtio_gpu_cmd_map(struct virtio_gpu_device *vgdev, struct virtio_gpu_object_array *objs, uint64_t offset) { @@ -1223,6 +1245,37 @@ int virtio_gpu_cmd_map(struct virtio_gpu_device *vgdev, return 0; } +int virtio_gpu_cmd_p2pdma_distance(struct virtio_gpu_device *vgdev, + struct virtio_gpu_pci_notation *provider_params, + struct virtio_gpu_pci_notation *client_params, + struct virtio_gpu_p2pdma_distance *p2pdma_dist) +{ + struct virtio_gpu_device_p2pdma_distance *cmd_p; + struct virtio_gpu_vbuffer *vbuf; + struct virtio_gpu_resp_distance *resp_buf; + + resp_buf = kzalloc(sizeof(*resp_buf), GFP_KERNEL); + if (!resp_buf) + return -ENOMEM; + + cmd_p = virtio_gpu_alloc_cmd_resp + (vgdev, virtio_gpu_cmd_p2pdma_distance_cb, &vbuf, sizeof(*cmd_p), + sizeof(struct virtio_gpu_resp_distance), resp_buf); + memset(cmd_p, 0, sizeof(*cmd_p)); + + cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_P2PDMA_DISTANCE); + cmd_p->provider_bus = cpu_to_le32(provider_params->bus); + cmd_p->provider_slot = cpu_to_le32(provider_params->slot); + cmd_p->provider_func = cpu_to_le32(provider_params->func); + cmd_p->client_bus = cpu_to_le32(client_params->bus); + cmd_p->client_slot = cpu_to_le32(client_params->slot); + cmd_p->client_func = cpu_to_le32(client_params->func); + vbuf->resp_cb_data = p2pdma_dist; + + virtio_gpu_queue_ctrl_buffer(vgdev, vbuf); + return 0; +} + void virtio_gpu_cmd_unmap(struct virtio_gpu_device *vgdev, struct virtio_gpu_object *bo) { diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h index bf2c9cabd207..18313cffaa62 100644 --- a/include/uapi/linux/virtio_gpu.h +++ b/include/uapi/linux/virtio_gpu.h @@ -95,6 +95,7 @@ enum virtio_gpu_ctrl_type { VIRTIO_GPU_CMD_SUBMIT_3D, VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB, VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB, + VIRTIO_GPU_CMD_P2PDMA_DISTANCE, /* cursor commands */ VIRTIO_GPU_CMD_UPDATE_CURSOR = 0x0300, @@ -108,6 +109,7 @@ enum virtio_gpu_ctrl_type { VIRTIO_GPU_RESP_OK_EDID, VIRTIO_GPU_RESP_OK_RESOURCE_UUID, VIRTIO_GPU_RESP_OK_MAP_INFO, + VIRTIO_GPU_RESP_OK_P2PDMA_DISTANCE, /* error responses */ VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200, @@ -429,6 +431,23 @@ struct virtio_gpu_set_scanout_blob { __le32 offsets[4]; }; +/* VIRTIO_GPU_CMD_P2PDMA_DISTANCE */ +struct virtio_gpu_device_p2pdma_distance { + struct virtio_gpu_ctrl_hdr hdr; + __le32 provider_bus; + __le32 provider_slot; + __le32 provider_func; + __le32 client_bus; + __le32 client_slot; + __le32 client_func; +}; + +/* VIRTIO_GPU_RESP_DISTANCE */ +struct virtio_gpu_resp_distance { + struct virtio_gpu_ctrl_hdr hdr; + __le32 distance; +}; + /* VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB */ struct virtio_gpu_resource_map_blob { struct virtio_gpu_ctrl_hdr hdr; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat Dec 07 10:53:55 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 07 Dec 2024 10:53:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850625.1265022 (Exim 4.92) (envelope-from ) id 1tJsRf-0000HX-8R; Sat, 07 Dec 2024 10:53:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850625.1265022; Sat, 07 Dec 2024 10:53:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJsRf-0000HQ-4Q; Sat, 07 Dec 2024 10:53:55 +0000 Received: by outflank-mailman (input) for mailman id 850625; Sat, 07 Dec 2024 10:53: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 1tJsRd-0007hr-L9 for xen-devel@lists.xenproject.org; Sat, 07 Dec 2024 10:53:53 +0000 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam04on20605.outbound.protection.outlook.com [2a01:111:f403:240a::605]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8b6dc2c4-b489-11ef-a0d5-8be0dac302b0; Sat, 07 Dec 2024 11:53:53 +0100 (CET) Received: from CH0P223CA0030.NAMP223.PROD.OUTLOOK.COM (2603:10b6:610:116::6) by CH3PR12MB7572.namprd12.prod.outlook.com (2603:10b6:610:144::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.11; Sat, 7 Dec 2024 10:53:45 +0000 Received: from CH2PEPF0000013C.namprd02.prod.outlook.com (2603:10b6:610:116:cafe::4) by CH0P223CA0030.outlook.office365.com (2603:10b6:610:116::6) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.12 via Frontend Transport; Sat, 7 Dec 2024 10:53:45 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CH2PEPF0000013C.mail.protection.outlook.com (10.167.244.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Sat, 7 Dec 2024 10:53:44 +0000 Received: from jenkins-julia.amd.com (10.180.168.240) 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; Sat, 7 Dec 2024 04:53: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: 8b6dc2c4-b489-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=p0ySH/xYkkF4lPN3bgTVsYZ/pjYLaN59aqVfBy34DJt1UJSAoe8lZpePXZAyZP3ZLtJIYACtJUgLf8Fd/SjiMjS4f4Cdw2+FQQ910r7hW2Mt1JAyYUyk3T+UI8HXxCfxMcddWP9wow/NpfGHPSXjIhG7IfEcTp16U4TpVL2vnnEsyP2AJH5ifTJSDloLYdzJ5mRWwC2ZE7xe2Xw4TLCLp6mWdW9fU19CcMXiUfgd23fykpya5J60X+y6lGkjcsKDXe0S+UGXIUDgdNajOWiEV3/KzA3JmpMkV9rNdd7+uInd0yLOckylnhr4Nc+nOytaKLTIm2I965pHpas5qoHoGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4ZkFtwcnYM2i/536XZMFv1NpvRLzNT6/8HZOgNw9APU=; b=IYYvzvc5qsR9GbQ0hGPfhNvHnebbOO5yTGBEPN1VZOqoGS8Nxw21XxNAmaVy+BqHlA6qnRCyMe9DD0z0cPEZaPrryUtEXUkdQKc9F6XFQDuVrWMSjcEuiZ0ykCxuN7oFd8au6/JPasHHzVXmzD8+NqNUzqyLBa7ZgBE9jshWQlwatA6jQIYYy/PYcq8t53Xijkx5vAOXR8w+EsSTAFDBARV+43DTHIvhGsXt5/WE8EvQUcERDuvuwhZCeJ7zJi2hgzpf2IKrb24sgdsNYiySnnbGoiATWBjgcssBQua9RHnhbgwQ556/ZX4RZGb7jgcA36C2v5sij/JiQWeJhPU+uQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=redhat.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=4ZkFtwcnYM2i/536XZMFv1NpvRLzNT6/8HZOgNw9APU=; b=YuZrRdDw32Gd5l4UpvOeTbHLgD56QTO10INg3o3T+Ac2L8srAH9J9EgJYQKOSpetZbPfpsvwu5jfTVlQ6KyyK+2knrpfzwW/ggvR0tKcfKrhGeIWpIg6foCzqs5e/Qv+tPzCRsfAdLUqXGZFCnMiYhUmv2kSdzfqdIBxPFJ1d9c= 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=SATLEXMB04.amd.com; pr=C From: Julia Zhang To: David Airlie , Gerd Hoffmann , Gurchetan Singh , Chia-I Wu , , , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , CC: Alex Deucher , =?UTF-8?q?Christian=20K=C3=B6nig?= , Daniel Vetter , Chen Jiqian , Huang Rui , Penny Zheng , Zhu Lingshan , Anthony PERARD , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Paul Durrant , Julia Zhang Subject: [PATCH 3/3] drm/virtio: Implement device_attach Date: Sat, 7 Dec 2024 18:50:26 +0800 Message-ID: <20241207105023.542399-4-julia.zhang@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241207105023.542399-1-julia.zhang@amd.com> References: <20241207105023.542399-1-julia.zhang@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PEPF0000013C:EE_|CH3PR12MB7572:EE_ X-MS-Office365-Filtering-Correlation-Id: 4d46a6a5-b8b5-453d-7fe6-08dd16ad6bca X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|82310400026|36860700013|921020; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?2wKtCKDtVexDsiIbKn+FuNmPsOgS/VWMc7nExyLAuNnJpD3SY7ed/9JncehJ?= =?us-ascii?Q?6IdZKDAdUrpX5RYeoDxcH44yYhMIdXsiZsfmxyhgZ11iAPX7+xhOsID0fRHW?= =?us-ascii?Q?hJyqKRHEvmGrHuacbZSDD6kPJV8vSDstb5R/E+TpelwgR5KfiDJflDiln8aC?= =?us-ascii?Q?vqFtEMxKjsQNX+bd6DaeMySzF8SMQQ/mcHJCeKcgDxx0aUH/5GNUWA+cOzw8?= =?us-ascii?Q?hBD5uZ3sWgPI1+xfXp5/US5etcK8wmltdyCo3lO/VyhK87kDdjhQbsLXHSzW?= =?us-ascii?Q?Q45utifk9uwOZijqvhPX7WIUqjERhzRif9sUKveJCdYi8SHHz+hFtjfVSyn8?= =?us-ascii?Q?FZATHaOzMrOggUqP2cu0QIxQD3WHlDu97C3+G1cR6wKHrjaxNXebycCF+BM9?= =?us-ascii?Q?WLv8WjqU5R6C6efWVntpdZ4xg9VwVMdXmR3XA8Rcm7bF8Hwij1Be2k8rrN7W?= =?us-ascii?Q?l58ZUjsZZLcBIuc+JO3TxEWvozHQFRn7BuEhLHjyViAqcqcdfIaq3VcVifS3?= =?us-ascii?Q?udlMf3ddm/jedtiQE8GlqPzL9d5A1rpphCCe/0KqaJF6u8RUGuwbBwT7B7Q9?= =?us-ascii?Q?bG6LjM6tPZCIyc4ySjyrRLvtFN1fgB5bln+0xo2eXjKheNlRPgvijXYO2QIm?= =?us-ascii?Q?EqALGPzaGXJ1HwkuDVobUDAOiVhP+HfeNX7C2TSPPNYasyke4PeSH4YPziRr?= =?us-ascii?Q?8qud9WGAH3znX9fna8cgh7kv0oS88jTLVhDxMhGN2bRTZbqkM8LoRM2vgXNd?= =?us-ascii?Q?XSaNPsg9fgMN7szZKLvCWS7+EMzAofbz6IRxgnAz+btmRldbEM9AnkCVbrWa?= =?us-ascii?Q?96pb+BrqDkL4uArbTtyunSHZS8tg/XAaasIi/W0wzpfuHVlO1+7SvEr2e8c3?= =?us-ascii?Q?ZmgNqslEmEYHVR6zxDJU1mgef2fk09dxj3iKKkLVWlq7ZGFYZ8tK9z6Xcexr?= =?us-ascii?Q?1I8v9VPBEGBtKBbPDsdOp/z7L6Zd3G0mKbJqRXtB9Qxc/URS3l3p3w3MlPY2?= =?us-ascii?Q?bdLWA8XfrEIqe3OZk2giSz4QReRDYCr+wPU8d8fZoDFrJ2xSg+0G/AqWxRpj?= =?us-ascii?Q?krPIlJSWhsnjCcd3mXcDOnvcD7B5jg4OmGFjemxk7gV9I5DYQ/yZivTlTb+M?= =?us-ascii?Q?JP+yIGEWc1KM5R3dBN+Qz6o4cRJKfWoai9oFov5JkMzWlpuaxjkH6Bmkas6O?= =?us-ascii?Q?uJdoVV9oAVDvsl/4Gg2X7Xk3f8gysiLhHO0+xzyIbMdfGPRow8Y/J+bfGzAN?= =?us-ascii?Q?+/3f4+y8eKBqx8/YiAOhZQD9ncEf5gab0SVypE8wdn2fQYebptIu3li5xaXF?= =?us-ascii?Q?lVNQI6ImNixFGnwoBYhc0P4QPCPBSYtKqiyms6kaamKIxZUcuAwYxe+ap1bP?= =?us-ascii?Q?+5tF5C3lZsCcWnQKkHUIGhdW2V8qFh6zJ5Rg7gy9WrQLAFAW6hc17QrVXe1Z?= =?us-ascii?Q?jQYEyBNF6aJiyaPrhy3TesM1ApUIpwKfaf6htWdFE4hAcItYfuKM5Q=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(82310400026)(36860700013)(921020);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2024 10:53:44.9127 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4d46a6a5-b8b5-453d-7fe6-08dd16ad6bca 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH2PEPF0000013C.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7572 As vram objects may be imported by other gpu drivers, peer2peer flag should be checked in dma_buf_ops->attach(). This reimplement virtio gpu dma_buf_ops->attach by adding a device_attach() function for virtio gpu. This function will get pci_p2pdma_distance and check attach->peer2peer before calling drm_gem_map_attach(). Signed-off-by: Julia Zhang --- drivers/gpu/drm/virtio/virtgpu_prime.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c b/drivers/gpu/drm/virtio/virtgpu_prime.c index 4960620eba02..4f6bce79e10e 100644 --- a/drivers/gpu/drm/virtio/virtgpu_prime.c +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c @@ -116,6 +116,18 @@ static int virtgpu_get_p2pdma_distance(struct dma_buf *dma_buf, return 0; } +static int virtgpu_gem_device_attach(struct dma_buf *dma_buf, + struct dma_buf_attachment *attach) +{ + int ret = virtgpu_get_p2pdma_distance(dma_buf, attach); + if (ret) + return ret; + if (!attach->peer2peer) + return -EBUSY; + + return drm_gem_map_attach(dma_buf, attach); +} + static const struct virtio_dma_buf_ops virtgpu_dmabuf_ops = { .ops = { .cache_sgt_mapping = true, @@ -128,7 +140,7 @@ static const struct virtio_dma_buf_ops virtgpu_dmabuf_ops = { .vmap = drm_gem_dmabuf_vmap, .vunmap = drm_gem_dmabuf_vunmap, }, - .device_attach = drm_gem_map_attach, + .device_attach = virtgpu_gem_device_attach, .get_uuid = virtgpu_virtio_get_uuid, }; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat Dec 07 10:56:25 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 07 Dec 2024 10:56:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850645.1265031 (Exim 4.92) (envelope-from ) id 1tJsU3-00013M-O3; Sat, 07 Dec 2024 10:56:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850645.1265031; Sat, 07 Dec 2024 10:56: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 1tJsU3-00013B-LA; Sat, 07 Dec 2024 10:56:23 +0000 Received: by outflank-mailman (input) for mailman id 850645; Sat, 07 Dec 2024 10:56: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 1tJsU2-00012y-5x for xen-devel@lists.xenproject.org; Sat, 07 Dec 2024 10:56:22 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2061b.outbound.protection.outlook.com [2a01:111:f403:2412::61b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e2f031ed-b489-11ef-99a3-01e77a169b0f; Sat, 07 Dec 2024 11:56:19 +0100 (CET) Received: from BN8PR12CA0009.namprd12.prod.outlook.com (2603:10b6:408:60::22) by LV3PR12MB9185.namprd12.prod.outlook.com (2603:10b6:408:199::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.11; Sat, 7 Dec 2024 10:56:14 +0000 Received: from BN3PEPF0000B372.namprd21.prod.outlook.com (2603:10b6:408:60:cafe::fd) by BN8PR12CA0009.outlook.office365.com (2603:10b6:408:60::22) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.10 via Frontend Transport; Sat, 7 Dec 2024 10:56:14 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by BN3PEPF0000B372.mail.protection.outlook.com (10.167.243.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8272.0 via Frontend Transport; Sat, 7 Dec 2024 10:56:14 +0000 Received: from jenkins-julia.amd.com (10.180.168.240) 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; Sat, 7 Dec 2024 04:56:09 -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: e2f031ed-b489-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yHPHu6pXdfHs081Mw/7q2vDkwN8NRL4YlrTtsdH7R+sZO2tYhIDXhQ8cA3Ps5m7vVHxeJBZRIYi3Nx0OZzjS/fF5rScqtTSHo5o2/pHy1Amaych+CSvCwJhxzgk32dQSb3sPxymNrlds7DZ6qEQtOC4iT4w6LuCg+lD/vKunaxtRSB58etCz85fPEPxL/JkJo54oMhU+yVssfwqEIvaT/79bsZwbvqgS1oLf2c8Hy4S0UoVzEjOYW/BiBpwTAre/QFsK9HgWHgIzE0fbya+pOibpyD7tbDP4RYDk6zVBW6R5Mm72prr2ir5x4wsG+twpmptJJ4h2I4Tsdbqn/Lwi/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=z4261N78RZ6zefSdf6LbgNLoktvOrHLnF03ZMxWyzmQ=; b=iTc0nK5/Vlmi2q1nB52p4HFlFldv+Wxp90Rzwwe21O133oN+uQ75OJ5+EavYwZLvsHqF+/TYzrt95YSarBhY2MdGVenc//xXcfQ2B7hKGegTaKFqWdU2OfvDh4N4FTrO880RMzhc4I0C00f6g4zAhn+r0tBM0o3qUyY1VYnHIIC5jvUDTBLMoNp+x8fG8/Tf42LabBFglIwHGEVs78tBDt8CzUzb7XoXxpSEC0llWHCTcjhHN/zuUrCe7DZjjNb0Bbn5wspK+3Llb+iBn55MQSeIvUVrizBSGuNWhnsJvtzXd9As3DoI0KwEf9uZX2z9NWK34QlVh0SZ1pmNPE1JjQ== 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=z4261N78RZ6zefSdf6LbgNLoktvOrHLnF03ZMxWyzmQ=; b=1oKPlguMMTnxoJwHt8V38Ob4HHB+9mPSYSIdHZtR7pAa6h4U3asIPrYgWAMhxKHt5yCaHVUV/HAVxbwWKOTUzwPFODOqSotTO65HhZvAZwhEV3gGv6btRKLvNJmvGtJx4ppvNRR1BOP+siVTIGzVeZfcYGanmWOWM4/mmePAZPA= 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=SATLEXMB04.amd.com; pr=C From: Julia Zhang To: Stefano Stabellini , Anthony PERARD , Paul Durrant , "Edgar E . Iglesias" , "Michael S . Tsirkin" , Marcel Apfelbaum , CC: Alex Deucher , =?UTF-8?q?Christian=20K=C3=B6nig?= , "Xenia Ragiadakou" , Julia Zhang , "Chen Jiqian" , Huang Rui , Penny Zheng , Zhu Lingshan , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Juergen Gross , Oleksandr Tyshchenko , Subject: [PATCH 0/3] Support getting p2pdma_distance Date: Sat, 7 Dec 2024 18:55:34 +0800 Message-ID: <20241207105537.542441-1-julia.zhang@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF0000B372:EE_|LV3PR12MB9185:EE_ X-MS-Office365-Filtering-Correlation-Id: aa9c35be-606c-4060-c2c3-08dd16adc4e9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|1800799024|36860700013|82310400026|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?9EPrNKWyXB2jffhGJwu6FONbnhxmpPnqjMVjmAU+oEtNU+cSqk7+YZniU1oM?= =?us-ascii?Q?zev8Wsp/joaRMxiUYDWVRiW0c9Q9Shc7uDInq2mJc1Fx3en/vupaj8fQqh5T?= =?us-ascii?Q?u6ePcwQwGExdSRtxSO3jpyZxKryL4w4pvrNnr2AYhWdgUcVtuHQ6htAbo3Us?= =?us-ascii?Q?shmdgzpoTDs/GiW1UPkF0Ppg/KCU1NQnA02cqD8fedJbpNDzGJZ4vhOjBgU0?= =?us-ascii?Q?ppTtWbW7UAUIPaTMCdVQCNS3c94B2YDJeqNivn6exkQIVRMCluaup9RMpHHq?= =?us-ascii?Q?HGO2vh+DK7NNpL+rKpD+sftBJwB2qH8YH0nkcEG3pMBff5qnl4tG+S7mCNTc?= =?us-ascii?Q?44KJ3sAWmcSuD9GQlFOzPavmE2aBFuISVd6SYO3HcOuLbNuVDaLWJID2JQz3?= =?us-ascii?Q?+A37W8+cdAwGFJ3tGdKfgHaGQvO70WjUPrVNR+kYnsTeDdNkaTc8KHn5pf/E?= =?us-ascii?Q?hqElxP9Ray6KAf0nQbRhppRRu3R9jeTpbRootsevWe/TLihhmP2vae/wP/tL?= =?us-ascii?Q?YyoHHN0ckcXgEoTpJNeCq0dyExKLcWgVoYnBaf2WRbveeeW0J3/z4kUT7rMn?= =?us-ascii?Q?0qXbC4oDsPC5hYCUZxTW1RyKrWO4Btghc+ywQJSXp2glemYunu5IHmwoucH1?= =?us-ascii?Q?HaD/HcApTnrk0/0V0DuLZetbI42/f8S7gKX/840FdYOgE7aN9jji/y8UbAZk?= =?us-ascii?Q?QPpVaYGz8kgZoXo1bKUiZdSy2UyohrzccXq/pg8BAi2MVt+eZRSICVu5cBTI?= =?us-ascii?Q?M3KTZdcvqv9rhB7nwti5CS1U33Dk5ZPt+uYPlpjPqUQ3UClzT3gIHwi4ggF2?= =?us-ascii?Q?EE2sg3q2QH+YhjJP927UQlhiUrY8wBU/PET4BPp+6iVxey6Fwh6bPKlj64zR?= =?us-ascii?Q?QPAsq+0PBNgHNDg4s9euLbFS+EeS/isTGRT9iAkw9/DaDOTt/gstaS5mATFc?= =?us-ascii?Q?ICysk89vQFEVUNv+lJa8iPuKmFeORVtoDrAelNSOxEvKsFQX1FwXe73xLf1j?= =?us-ascii?Q?kcUs7UvBVMBj2P7huSAyWtyfHo/DKuBIxrN3bj/iZgubIoMplqTmA1oUz3v6?= =?us-ascii?Q?Ts39gcol9xmzbVdBQgNYBeAwbVSgve+Pi47l/3fjUDhTJOjMNXQziqKvOg/9?= =?us-ascii?Q?hpQ2Fx2pC/3QLxM2Cf75DtPIlF/1tbn1J1PgfreLN2kkqvpPErTyXa/PUAtN?= =?us-ascii?Q?MwpPSUEAUKIVmHe+YiRTWBImViE+Dmdlwmr/XLtw5HbBpw5TeQMknoVWf3oe?= =?us-ascii?Q?sFghtmVkF2Zw2vTLzmFfondRb7aEASgLh7o2ly6NQjjPNKndfUOY1DXyd7aK?= =?us-ascii?Q?cKaAW43AQMxXwXDGGq9wus2ktTb+YA+akoBVH4YDFQ66B1QdrtiklSevfCnv?= =?us-ascii?Q?XjsCvlaWXxDKA/6czVCQegzffPenLboDnbsJNeoLBSm3IDbP1S3NZSEXUdN8?= =?us-ascii?Q?sCLV8DnS0y9BCPB1mn+aaPwvWPK/omX3?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2024 10:56:14.4504 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: aa9c35be-606c-4060-c2c3-08dd16adc4e9 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN3PEPF0000B372.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9185 To implement dGPU prime feature, virtgpu needs to import/export buffer between virtio iGPU and passthrough dGPU. Before that, virtgpu has to checkout p2pdma_distance. But calling function pci_p2pdma_distance in guest VM will only get virtual p2pdma_distance instead of real physical p2pdma_distance. This series is to support handling the new virtgpu command from the guest VM to get the physical p2pdma_distance of two PCI devices of guest VM. Julia Zhang (3): virtio-gpu: set hostaddr for virtio iGPU pci: introduce a function to get PCIDevice virtio-gpu: add a new command to calculate p2pdma_distance hw/display/virtio-gpu-virgl.c | 47 +++++++++++++++++++++ hw/display/virtio-gpu.c | 6 +++ hw/i386/xen/xen-hvm.c | 6 +++ hw/pci/pci.c | 22 ++++++++++ hw/xen/xen_pt.c | 10 ++--- hw/xen/xen_pt.h | 1 - include/hw/pci/pci.h | 2 + include/hw/pci/pci_device.h | 1 + include/hw/virtio/virtio-gpu-bswap.h | 12 ++++++ include/hw/virtio/virtio-gpu.h | 2 + include/hw/xen/xen.h | 3 ++ include/standard-headers/linux/virtio_gpu.h | 19 +++++++++ 12 files changed, 125 insertions(+), 6 deletions(-) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat Dec 07 10:56:57 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 07 Dec 2024 10:56:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850654.1265042 (Exim 4.92) (envelope-from ) id 1tJsUY-0001Qi-WD; Sat, 07 Dec 2024 10:56:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850654.1265042; Sat, 07 Dec 2024 10:56:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJsUY-0001Qb-TL; Sat, 07 Dec 2024 10:56:54 +0000 Received: by outflank-mailman (input) for mailman id 850654; Sat, 07 Dec 2024 10:56: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 1tJsUX-00012y-E3 for xen-devel@lists.xenproject.org; Sat, 07 Dec 2024 10:56:53 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on20631.outbound.protection.outlook.com [2a01:111:f403:2415::631]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f63f366d-b489-11ef-99a3-01e77a169b0f; Sat, 07 Dec 2024 11:56:51 +0100 (CET) Received: from BN9PR03CA0241.namprd03.prod.outlook.com (2603:10b6:408:ff::6) by DS0PR12MB8041.namprd12.prod.outlook.com (2603:10b6:8:147::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.19; Sat, 7 Dec 2024 10:56:47 +0000 Received: from BN3PEPF0000B36D.namprd21.prod.outlook.com (2603:10b6:408:ff:cafe::f5) by BN9PR03CA0241.outlook.office365.com (2603:10b6:408:ff::6) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.11 via Frontend Transport; Sat, 7 Dec 2024 10:56:47 +0000 Received: from SATLEXMB04.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_128_GCM_SHA256) id 15.20.8272.0 via Frontend Transport; Sat, 7 Dec 2024 10:56:47 +0000 Received: from jenkins-julia.amd.com (10.180.168.240) 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; Sat, 7 Dec 2024 04:56:42 -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: f63f366d-b489-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eTWqjXj/cHSYr9UurojeUnLoCM8xnLBh4kp2mmvwj+GNr0RCF09Fod71jpmoo2ed9v3XL2CWtoNOxMcE9CVBxrbm3HGucK6FjnEX+UgU5Cji7ykrh6cO5ayQJBmnThVZYRG1XgjQU6lKM8wBhuV1dKStdrxLJbL8GyJlVnulZ5lq0DRAuAFw/GZPZ4fYDVsq7A03B0Yw3VD5/7qZ6tan8Dx3q5LEdcoZxF/TyIzHGGv+GLxS2UDxqnKffZZyk3PWibkNyW9YbKA+cdhYxM1KrVYTyc1c1QolaqwMzGw8u920NXyLJtFREfD1W/m5K0rtxhdT0N0H8iXB+qnKtMP2YQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+vj8HPAjMVLVff8tdV9jtHw/j79hcngd7Jdhce14dQI=; b=V1aSL+g2kLX4ehPGo7eQuGWq5oFVXx0p69U3atB3mJMHJsO3AwRhGoJmxJA0NU7AKOnPYxcXU/D4lvTH9KNEEzC0od7Qm57sYx02OMLJvyzUEkF/apzlK4IBMF5jy9hu9yEYagLqZo/ym6+CFpZAaZ7prLI1024iSvz9GjuZHaSOc54G/dUmt87cm5H2Bv2pqCdIpJ1pw6OMEfFyuwEmcW3dG1og3bfbX6tp+1D7xxnbxKya5wkPN1jgYWayOM+ozTVGa14VEMVIspUAFUECLvLQSK+WFMCpkXsJQOnJfzYC0Kfp+2A2zBHZlebHOxAyUB6o2aL+JGx1TTV8j8gmDQ== 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=+vj8HPAjMVLVff8tdV9jtHw/j79hcngd7Jdhce14dQI=; b=o+VnPY4Z1urWpil7/gCAzKbcgLY1NC8IBY+R0T/vjnghfQPcotWLK2SM7zfawqGVL2cVtY/SbK1yMFiimVWlYLfZGv1pLR2Bthky8stzgB+JCVML1dOAXPjfsITkoKwVO0tXv925ZPLcJomXrHDzs7CnCBQ8qQaiIg8dQdkyxo8= 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=SATLEXMB04.amd.com; pr=C From: Julia Zhang To: Stefano Stabellini , Anthony PERARD , Paul Durrant , "Edgar E . Iglesias" , "Michael S . Tsirkin" , Marcel Apfelbaum , CC: Alex Deucher , =?UTF-8?q?Christian=20K=C3=B6nig?= , "Xenia Ragiadakou" , Julia Zhang , "Chen Jiqian" , Huang Rui , Penny Zheng , Zhu Lingshan , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Juergen Gross , Oleksandr Tyshchenko , Subject: [PATCH 1/3] virtio-gpu: set hostaddr for virtio iGPU Date: Sat, 7 Dec 2024 18:55:36 +0800 Message-ID: <20241207105537.542441-2-julia.zhang@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241207105537.542441-1-julia.zhang@amd.com> References: <20241207105537.542441-1-julia.zhang@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF0000B36D:EE_|DS0PR12MB8041:EE_ X-MS-Office365-Filtering-Correlation-Id: 6c3410e5-db36-45c2-9616-08dd16add859 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|376014|7416014|82310400026; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?WknFN806tZ1knN/IaQhDfbZpeHpc+X5jkDV1ej/vy5RKTgQiTRs1AY4nJQtr?= =?us-ascii?Q?xYfUR4j4wSxnYM2vdgCJIdBEVF/SFN/U2ndBjuAJpnOv/CfguQvvYMO/d5pY?= =?us-ascii?Q?DkCpdjytlOOTVWn/ZA8TNjhXoX5xPtVcZM7zKQIh9xoBuOiNQD0I+A6KSHhA?= =?us-ascii?Q?fvIhtoK0z2CBEWdnbp2yQohXS3MqR2QgCbDS+pDrtZti+1qamZtjTW1RpECu?= =?us-ascii?Q?c7Jjdmf/0cRWrSdQs2ngnbmQoJ0Upkofo3UGD9FLZCbP4Ctf4AwWFGC7dLw1?= =?us-ascii?Q?Q+vwnjnsILRazWalLfXvzVuVAs4wWaaMlyqdk6dqFyBNRtpb8hCVMT6IUoLv?= =?us-ascii?Q?TXF8EyAUNiiR3WILDNACIntp+yAA2SSQ1/EMLhNhz2c7gJaT3kRlTEvOteMv?= =?us-ascii?Q?ZOHsg/Z0YJoSAxepWorv0WHgN4KdeJCxF5zBjIwQfSYBdZNkfyiF/BoE5Zor?= =?us-ascii?Q?1BrsUuDgJ8HjHmJ4pD0/kkG4Q1g9AWtKoDrrDz0TF0ME2wYgIIZP87iP5tHm?= =?us-ascii?Q?ChMl9FNcf0PeTeB6oOYaHeaskiQeuorDf1dTpjEFrA2Ab2K5UVljKZ59K4/b?= =?us-ascii?Q?yHHGDeafUeNI7J8v9n3TnpNuvFDjDY144pmAG9HpXqnFq04+43rBP6xdQmDx?= =?us-ascii?Q?POi02eiF3c4EU4wrKxDh1P8j21fwrlfOOEraR6zHATNkf/7p6EHNegcbU617?= =?us-ascii?Q?qQ+5iAF0kelhW1EBDsnVvPPZwqAk3qKJBvWr125TbZoV6sNGU+33ctzGiXlq?= =?us-ascii?Q?QOQfihDHYYnbOuSW7NP/Q8OVOJHItqYHhkCpnN/9gysKkkm6k+iSHrpjVqfF?= =?us-ascii?Q?wwUwYBmZ7eUFwUSaB678pIqHRrOvp/pVq2FtrSdfbZ7ys0lEW+nis0BIBSnX?= =?us-ascii?Q?H4OMoDv/r87p6ZZbeHMt2XrE+tVsTaX4XJoVz6zqRpp+Fl8CQpiTX8c/01h8?= =?us-ascii?Q?NAsWfpQVyaoSDGbqNkPLgBbumkbVW8q9F2frOZSFiBaR5njNQ/zDJHvSprUy?= =?us-ascii?Q?Kt0Qfqj91GrVIApwVkktdAxBg/rhZfxesthvkdqtsdyBmiTswZsXTyH+TM5I?= =?us-ascii?Q?VxlBnK4ClVXF5Eh6nj9gqcCpuDmhlPlNXsOrP6GlKYSMjOgfz/CWHCkUuRv8?= =?us-ascii?Q?HhQtnMoG4i2s0DXPtZMDf/J89vFebAtAExaM8geiezN0vurtRDtkJjVCYKym?= =?us-ascii?Q?cn+7ezKUhmC+RVs/LvATyDnOBO1ZnOactmjBxUkQJbrMwU98qLFJailwp7qX?= =?us-ascii?Q?PphnsK2qdPPGnHawyx5zwyTDCfaGHsgzGF8z4N0sw24gnwYFFcW1cZNFv/MQ?= =?us-ascii?Q?YFFVxVtH08jZHDhuEFSwkZ2pEliuMJu8AxmtzFQ9em9GjP9gtye2Wl5CCm+p?= =?us-ascii?Q?ZjwHmTvsutpRo732VIgZ+oG0fhYu+V3TAUDyw9bXUEskfTIk0kqyyFgWi4zD?= =?us-ascii?Q?6EUKf1M+0wNJ16D6tvE5ypKVGSxIE0iI?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(7416014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2024 10:56:47.0600 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6c3410e5-db36-45c2-9616-08dd16add859 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=[SATLEXMB04.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: DS0PR12MB8041 Get physical pci notation from hvm file and set hostaddr for virtio iGPU. Signed-off-by: Julia Zhang --- hw/display/virtio-gpu.c | 6 ++++++ hw/xen/xen_pt.c | 10 +++++----- hw/xen/xen_pt.h | 1 - include/hw/pci/pci_device.h | 1 + include/hw/virtio/virtio-gpu.h | 2 ++ 5 files changed, 14 insertions(+), 6 deletions(-) diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c index c0570ef856..d68b64ac22 100644 --- a/hw/display/virtio-gpu.c +++ b/hw/display/virtio-gpu.c @@ -26,6 +26,7 @@ #include "hw/virtio/virtio-gpu-bswap.h" #include "hw/virtio/virtio-gpu-pixman.h" #include "hw/virtio/virtio-bus.h" +#include "hw/virtio/virtio-pci.h" #include "hw/qdev-properties.h" #include "qemu/log.h" #include "qemu/memfd.h" @@ -1458,6 +1459,8 @@ void virtio_gpu_device_realize(DeviceState *qdev, Error **errp) { VirtIODevice *vdev = VIRTIO_DEVICE(qdev); VirtIOGPU *g = VIRTIO_GPU(qdev); + BusState *qbus = BUS(qdev_get_parent_bus(qdev)); + VirtIOPCIProxy *proxy = VIRTIO_PCI(qbus->parent); if (virtio_gpu_blob_enabled(g->parent_obj.conf)) { if (!virtio_gpu_rutabaga_enabled(g->parent_obj.conf) && @@ -1508,6 +1511,8 @@ void virtio_gpu_device_realize(DeviceState *qdev, Error **errp) QTAILQ_INIT(&g->reslist); QTAILQ_INIT(&g->cmdq); QTAILQ_INIT(&g->fenceq); + + proxy->pci_dev.hostaddr = g->parent_obj.conf.hostaddr; } static void virtio_gpu_device_unrealize(DeviceState *qdev) @@ -1669,6 +1674,7 @@ static Property virtio_gpu_properties[] = { VIRTIO_GPU_FLAG_BLOB_ENABLED, false), DEFINE_PROP_SIZE("hostmem", VirtIOGPU, parent_obj.conf.hostmem, 0), DEFINE_PROP_UINT8("x-scanout-vmstate-version", VirtIOGPU, scanout_vmstate_version, 2), + DEFINE_PROP_PCI_HOST_DEVADDR("hostaddr", VirtIOGPU, parent_obj.conf.hostaddr), DEFINE_PROP_END_OF_LIST(), }; diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c index c0042b3515..8e5ff09b66 100644 --- a/hw/xen/xen_pt.c +++ b/hw/xen/xen_pt.c @@ -828,9 +828,9 @@ static void xen_pt_realize(PCIDevice *d, Error **errp) /* register real device */ XEN_PT_LOG(d, "Assigning real physical device %02x:%02x.%d" - " to devfn 0x%x\n", + " to devfn 0x%x, %02x:%02x.%d\n", s->hostaddr.bus, s->hostaddr.slot, s->hostaddr.function, - s->dev.devfn); + s->dev.devfn, pci_bus_num(pci_get_bus(&s->dev)), PCI_SLOT(s->dev.devfn), PCI_FUNC(s->dev.devfn)); s->is_virtfn = s->real_device.is_virtfn; if (s->is_virtfn) { @@ -991,7 +991,7 @@ static void xen_pt_unregister_device(PCIDevice *d) } static Property xen_pci_passthrough_properties[] = { - DEFINE_PROP_PCI_HOST_DEVADDR("hostaddr", XenPCIPassthroughState, hostaddr), + DEFINE_PROP_PCI_HOST_DEVADDR("hostaddr", XenPCIPassthroughState, dev.hostaddr), DEFINE_PROP_BOOL("permissive", XenPCIPassthroughState, permissive, false), DEFINE_PROP_END_OF_LIST(), }; @@ -1022,8 +1022,8 @@ static void xen_igd_clear_slot(DeviceState *qdev, Error **errp) PCIBus *pci_bus = pci_get_bus(pci_dev); xen_host_pci_device_get(&s->real_device, - s->hostaddr.domain, s->hostaddr.bus, - s->hostaddr.slot, s->hostaddr.function, + s->dev.hostaddr.domain, s->dev.hostaddr.bus, + s->dev.hostaddr.slot, s->dev.hostaddr.function, errp); if (*errp) { error_append_hint(errp, "Failed to \"open\" the real pci device"); diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h index 095a0f0365..f61a134ff5 100644 --- a/hw/xen/xen_pt.h +++ b/hw/xen/xen_pt.h @@ -233,7 +233,6 @@ typedef struct XenPTMSIX { struct XenPCIPassthroughState { PCIDevice dev; - PCIHostDeviceAddress hostaddr; bool is_virtfn; bool permissive; bool permissive_warned; diff --git a/include/hw/pci/pci_device.h b/include/hw/pci/pci_device.h index 8eaf0d58bb..b7acf3822d 100644 --- a/include/hw/pci/pci_device.h +++ b/include/hw/pci/pci_device.h @@ -56,6 +56,7 @@ typedef struct PCIReqIDCache PCIReqIDCache; struct PCIDevice { DeviceState qdev; + PCIHostDeviceAddress hostaddr; bool partially_hotplugged; bool has_power; diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h index 553799b8cc..e385794a06 100644 --- a/include/hw/virtio/virtio-gpu.h +++ b/include/hw/virtio/virtio-gpu.h @@ -24,6 +24,7 @@ #include "standard-headers/linux/virtio_gpu.h" #include "standard-headers/linux/virtio_ids.h" #include "qom/object.h" +#include "hw/pci/pci.h" #define TYPE_VIRTIO_GPU_BASE "virtio-gpu-base" OBJECT_DECLARE_TYPE(VirtIOGPUBase, VirtIOGPUBaseClass, @@ -125,6 +126,7 @@ struct virtio_gpu_base_conf { uint32_t xres; uint32_t yres; uint64_t hostmem; + PCIHostDeviceAddress hostaddr; }; struct virtio_gpu_ctrl_command { -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat Dec 07 10:57:19 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 07 Dec 2024 10:57:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850661.1265052 (Exim 4.92) (envelope-from ) id 1tJsUx-0001wW-8O; Sat, 07 Dec 2024 10:57:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850661.1265052; Sat, 07 Dec 2024 10:57: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 1tJsUx-0001wM-5T; Sat, 07 Dec 2024 10:57:19 +0000 Received: by outflank-mailman (input) for mailman id 850661; Sat, 07 Dec 2024 10:57: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 1tJsUw-0001tQ-Ll for xen-devel@lists.xenproject.org; Sat, 07 Dec 2024 10:57:18 +0000 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam04on20623.outbound.protection.outlook.com [2a01:111:f403:240a::623]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 05c6c1eb-b48a-11ef-a0d5-8be0dac302b0; Sat, 07 Dec 2024 11:57:18 +0100 (CET) Received: from BN8PR12CA0026.namprd12.prod.outlook.com (2603:10b6:408:60::39) by DS0PR12MB8343.namprd12.prod.outlook.com (2603:10b6:8:fd::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Sat, 7 Dec 2024 10:57:10 +0000 Received: from BN3PEPF0000B372.namprd21.prod.outlook.com (2603:10b6:408:60:cafe::18) by BN8PR12CA0026.outlook.office365.com (2603:10b6:408:60::39) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.10 via Frontend Transport; Sat, 7 Dec 2024 10:57:10 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by BN3PEPF0000B372.mail.protection.outlook.com (10.167.243.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8272.0 via Frontend Transport; Sat, 7 Dec 2024 10:57:10 +0000 Received: from jenkins-julia.amd.com (10.180.168.240) 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; Sat, 7 Dec 2024 04:57: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: 05c6c1eb-b48a-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FDSTIwzP2hCfkSDlD3jasev3OQMVtkVjWW9QvByL0AmhQjlT0EEfCPACwktnvZGYbST34jlXYK+o5SSIrmMOOpokXF1u6+IPZlwp1A2XFw3z8B4HzuMggj1kaOTH69DbTEV1kgghlxgqSmsU5dzEww3xof1xefhDX0GFz91tibC7ENLeqElrRtKsFed/VF9di6Tnean6b2M4o9PWyFay/uEkHXhti/TCp8O/mrtoU4LtaQf3zzeeDG5+8KDrgJVZP93E1ESRsJY9g6WWGWJjERmHb3hlysEEbZkkomFRM/xFxZnCPnDe3oN9H+Ugl9gh6cNYIgZqkGNMKLWi86YPoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YaHGUZgM04HQD0VdrKLIvWNrpeh66J4OqCg0Rby1C6g=; b=md9oZJFpqB0rYp5yKsqmkRnaXGuEwySykTGCesIzeQBVQ8BiZaukS3N56vzpV2Zq+9+Blq7ENHw0zLy+/NwqeHtEbOr8TmQY+0HMtAPU39Krs2uA9iPIbuuXbNNHKKN9Gvi8gIukKF2BnYrihZ2WJqxBVWV2zUAz0jLqD8J4zTvaJFJL9VW1YuOtNs//DIs5Hh1gVgg28jByfxfoWq5F2daxOHfs2bitzGkYVFx94rkuNyXA7uXaOfYa2nB4kY0rm3Xude90E8h5xRFBZ16/VztsVj4s7UFu2Qs5XZw36OcGUuKQsslRaqUVfJvo7Dvgf0vfZMKu3DjatNfhwoXXDw== 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=YaHGUZgM04HQD0VdrKLIvWNrpeh66J4OqCg0Rby1C6g=; b=KjWOBi2l/1Dc2KfPgZ+2nAqRejIp4pj7FgRzi3vmA1Lrf4iU8y+6htA0df0cxx/7P4zhJiGxkbDR8XsVZ7ssH7K5CJ7KxqTKjmGdQhz9q0ho3Zh1Dm5KexDPoBpa0uN8324Vxr13kJW1fJf2eBK2W/z/78AsfxQsZqWtwJSrjF8= 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=SATLEXMB04.amd.com; pr=C From: Julia Zhang To: Stefano Stabellini , Anthony PERARD , Paul Durrant , "Edgar E . Iglesias" , "Michael S . Tsirkin" , Marcel Apfelbaum , CC: Alex Deucher , =?UTF-8?q?Christian=20K=C3=B6nig?= , "Xenia Ragiadakou" , Julia Zhang , "Chen Jiqian" , Huang Rui , Penny Zheng , Zhu Lingshan , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Juergen Gross , Oleksandr Tyshchenko , Subject: [PATCH 2/3] pci: introduce a function to get PCIDevice Date: Sat, 7 Dec 2024 18:55:38 +0800 Message-ID: <20241207105537.542441-3-julia.zhang@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241207105537.542441-1-julia.zhang@amd.com> References: <20241207105537.542441-1-julia.zhang@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF0000B372:EE_|DS0PR12MB8343:EE_ X-MS-Office365-Filtering-Correlation-Id: 9529aba0-a848-47bc-c579-08dd16ade65d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|7416014|376014|82310400026; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?FalTgiIumSNSHIdOdM/HxAXB5s+CVh6ArP5TPCQfpVyXJJ9aAAfsuu8sF/ud?= =?us-ascii?Q?fg2PxYXXt6GPlLeQFhPIogNG4UMPeS/EhttpPqKPNANjqX3iaNinkGkwDgJE?= =?us-ascii?Q?K87cfsftxxklJdaBTHs26Y8I9hY4Bds/ZcUdw+FSakX9SinO2qGQ6stk7keT?= =?us-ascii?Q?fp8jpJG62wrpeVTBqNNOP//oTIHo02EX8VI9A46700Bdx6/ZNubtp8/8wdsF?= =?us-ascii?Q?VNujdJhO1wyQ1XQH4tpSZYDNxKISQhOjX+jGL8bTYDX/9vtEH3BxKzlKg5U0?= =?us-ascii?Q?+sv73XTdiO5JYFrRxLo0ECBKThUo86y01UyCDH9mif1lhAH2T+KPGvEXe8aa?= =?us-ascii?Q?MszjxaA9rJciTtiNhAFdDjigmNptdIT8A+QouRQO0sfiXvMqz129KBUxyai2?= =?us-ascii?Q?9XqDB7guzw1+AGQ36N/QN1tGrTYekwcg9av+eCosKy3ngkGEdDSLCsTjDIZm?= =?us-ascii?Q?+EpDMrzkc4q6djXNLX9WNjBFVXXWKajwP0qa6PKVW2a6zfjmb5aObJKnyzNV?= =?us-ascii?Q?JXyADrglmLAIdRrZpg6mt+PbTFN4jce/czUx6qq2UoRTj0r4B3lI6cIwf0s6?= =?us-ascii?Q?8zortQ8+kIsViJvil/I1nmBOnJzUELKe9lKFt61wPI6iN3Xibh/VPQt8KVLS?= =?us-ascii?Q?3HBO9h/eFeWGqwbynBWEp6Jcbhp5RgmgUO9AUjaxBP/QqCAi/unsveDfZPxw?= =?us-ascii?Q?vBevqhvbmEhqkcciNvuLDv0cobIo49Iwmd9/0Jim7elBdZN7RkIf1L9whf2C?= =?us-ascii?Q?R3BPrH40wSz79U/olhEC14I32UyD7NdRY3iFIN5vTMCqhx19wv8XQNXQHfEU?= =?us-ascii?Q?YPuEdKQBOaSPZQlQN1JEswYIFtKySzjzQ65koMSXL56WE5C1KomODV0AgL6u?= =?us-ascii?Q?IAP1nSQ4fxmh2qrKJff7RihtA8IZfJgqsifJazg4UYsKecz5YSGIVYUu2XCE?= =?us-ascii?Q?zdvy33ePc8ajMw8CThZH3g8YQBHGiDkYYuiE7oE7yg6HbaFW85cUyGpr9o0F?= =?us-ascii?Q?TRaIsQs/HjHCD78zVV2z6Vj5rUEn2CIfT8jUAg6/64Txz2mW3j75vJlSBab1?= =?us-ascii?Q?YI0uR5FEx3vpDWZqNIfDtqZH7uJIFsS/uO5uDWcxB8SYZWRwSl6L5aPQHxWI?= =?us-ascii?Q?4/6NllGRgAWuMkpRB8bMr6cABAxfYk63n9Ii/S+cvduAavBw8AVmWGYLmW+I?= =?us-ascii?Q?w6px845Q9FNBU2hPrmwJzyCZiv0m/bdkP58MUwrZcOTDebTH9vIhwaziNONC?= =?us-ascii?Q?1VIRUq5YusrkyptmHt2teTkp6TNydDVApSTkcmRh+vYAlgbLL+zDNG7HpQh8?= =?us-ascii?Q?HOODUIvQudGuiiCPzJrz+2VT+Z47oplaiV7zaNYPijfpVw0XQ0JkQ8ZhjMcb?= =?us-ascii?Q?LYHPefd6U/3lBl0A6Q7pEN06AoaZkJOaaYMgilv/jJKeSseJKBtjqxBJg4BC?= =?us-ascii?Q?XfWnto17SL2UL8uTCT8hiEEO9V8XwBz8?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(7416014)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2024 10:57:10.5911 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9529aba0-a848-47bc-c579-08dd16ade65d 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN3PEPF0000B372.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8343 Introduce a helper function to get PCIDevice from qdev pci notation. Signed-off-by: Julia Zhang --- hw/pci/pci.c | 22 ++++++++++++++++++++++ include/hw/pci/pci.h | 2 ++ 2 files changed, 24 insertions(+) diff --git a/hw/pci/pci.c b/hw/pci/pci.c index 1416ae202c..95806ead4f 100644 --- a/hw/pci/pci.c +++ b/hw/pci/pci.c @@ -2617,6 +2617,28 @@ static int pci_qdev_find_recursive(PCIBus *bus, return -EINVAL; } +int pci_qdev_get_device(uint32_t virt_bus, uint32_t virt_slot, uint32_t virt_func, + PCIDevice **pci_dev) +{ + PCIHostState *host_bridge; + PCIDevice *d; + int devfn; + int rc = -ENODEV; + + QLIST_FOREACH(host_bridge, &pci_host_bridges, next) { + for(devfn = 0; devfn < ARRAY_SIZE(host_bridge->bus->devices); devfn++) { + d = host_bridge->bus->devices[devfn]; + if (d && d->devfn == PCI_DEVFN(virt_slot, virt_func) && + pci_bus_num(pci_get_bus(d)) == virt_bus) { + *pci_dev = d; + rc = 0; + break; + } + } + } + return rc; +} + int pci_qdev_find_device(const char *id, PCIDevice **pdev) { PCIHostState *host_bridge; diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h index 463d9984b3..1b493ab95e 100644 --- a/include/hw/pci/pci.h +++ b/include/hw/pci/pci.h @@ -366,6 +366,8 @@ const char *pci_root_bus_path(PCIDevice *dev); bool pci_bus_bypass_iommu(PCIBus *bus); PCIDevice *pci_find_device(PCIBus *bus, int bus_num, uint8_t devfn); int pci_qdev_find_device(const char *id, PCIDevice **pdev); +int pci_qdev_get_device(uint32_t virt_bus, uint32_t virt_slot, + uint32_t virt_func, PCIDevice **pci_dev); void pci_bus_get_w64_range(PCIBus *bus, Range *range); void pci_device_deassert_intx(PCIDevice *dev); -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat Dec 07 10:57:55 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 07 Dec 2024 10:57:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850678.1265061 (Exim 4.92) (envelope-from ) id 1tJsVW-0002cC-KD; Sat, 07 Dec 2024 10:57:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850678.1265061; Sat, 07 Dec 2024 10:57:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJsVW-0002c5-HY; Sat, 07 Dec 2024 10:57:54 +0000 Received: by outflank-mailman (input) for mailman id 850678; Sat, 07 Dec 2024 10:57: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 1tJsVU-0001tQ-Sk for xen-devel@lists.xenproject.org; Sat, 07 Dec 2024 10:57:53 +0000 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on2062a.outbound.protection.outlook.com [2a01:111:f403:2406::62a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1a04e331-b48a-11ef-a0d5-8be0dac302b0; Sat, 07 Dec 2024 11:57:52 +0100 (CET) Received: from MN2PR19CA0065.namprd19.prod.outlook.com (2603:10b6:208:19b::42) by DM4PR12MB7501.namprd12.prod.outlook.com (2603:10b6:8:113::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.20; Sat, 7 Dec 2024 10:57:45 +0000 Received: from BN3PEPF0000B371.namprd21.prod.outlook.com (2603:10b6:208:19b:cafe::20) by MN2PR19CA0065.outlook.office365.com (2603:10b6:208:19b::42) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.16 via Frontend Transport; Sat, 7 Dec 2024 10:57:44 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by BN3PEPF0000B371.mail.protection.outlook.com (10.167.243.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8272.0 via Frontend Transport; Sat, 7 Dec 2024 10:57:44 +0000 Received: from jenkins-julia.amd.com (10.180.168.240) 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; Sat, 7 Dec 2024 04:57:40 -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: 1a04e331-b48a-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DdDe97pi0tc8ZHZA4Tp6eA1fulBtz6474uH156UNLqzXOXYNDdmZCfco/pJTD6U3HwBUgty6a4/nuNhBtA3bfmFobXdz3xPs542HnZKPLgJU6tX9X2huknnvP8tNVFQqbP8meCdFpkZbEdPujDVpVjuTbVq6ZIyJLOeh+zpGrxEZ54jXg5O7FJRwl7xDDibxcKNofjChG3hq9Lc1b625yEErR/jkzeRMHyqjoFEySGEeLK3BGjl57xzaKf4OVY2KHC1zERTjuuYPBgSL6/s9OgUmC5BTo2bl/Kj9yJ633+5NOz3AM/zCbU2dZ9Epr5GJVpky6hvxNxMYQEnCDRLGmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QB2v3p8xVBkoFTtj/OssK3eq3aeYBld67hSPE7XCRYE=; b=VrJdvEqSaFXdWuNz6YRJEcWBqb7loTgEJbBVP6387HHAqK57q16/kuoDFRxFfs/VwIQJ8Bpf1kVzh+0GO9AlZkZMUKGQvB6qupwVidBWpn+rXADBe4qHOheQrQvkaCJr+I9joePVkaCgeVczVgwd6xrbtd26dl31UAkkKxfTQyLRHNCtWPRW/4XqOPOqbJvPYZ6uBhVeKmFyn+jove30o9RRwlYF2cYaYqiVj2wRqcBw9wt8hysxgp/8uB+omWrpdo2+nVqQPnn426l/uU+nuFNbDTWXNyJZDrxV7wRiKm0iaZHQSlqM6SCOBZdtsBF7sBfKhFn/c2LDw9zjHjn5Ew== 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=QB2v3p8xVBkoFTtj/OssK3eq3aeYBld67hSPE7XCRYE=; b=bxMe+UBrFAPVtVlkMpBC5s3RhhrgLFmT+xrtuHSRWI2cTJIPlzB5iTjeQ0LJrT9PJbjShJ7Mi24oRfojYpq1rPmSb1yy8xAukdcFegY0/fw9pS0LOtG311cGDWCOsz+6AdZnlMqv32l8FC6v5CFQXC0UwvR3KlyTcjT5H6cC+v8= 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=SATLEXMB04.amd.com; pr=C From: Julia Zhang To: Stefano Stabellini , Anthony PERARD , Paul Durrant , "Edgar E . Iglesias" , "Michael S . Tsirkin" , Marcel Apfelbaum , CC: Alex Deucher , =?UTF-8?q?Christian=20K=C3=B6nig?= , "Xenia Ragiadakou" , Julia Zhang , "Chen Jiqian" , Huang Rui , Penny Zheng , Zhu Lingshan , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Juergen Gross , Oleksandr Tyshchenko , Subject: [PATCH 3/3] virtio-gpu: add a new command to get p2pdma_distance Date: Sat, 7 Dec 2024 18:55:40 +0800 Message-ID: <20241207105537.542441-4-julia.zhang@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241207105537.542441-1-julia.zhang@amd.com> References: <20241207105537.542441-1-julia.zhang@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF0000B371:EE_|DM4PR12MB7501:EE_ X-MS-Office365-Filtering-Correlation-Id: de85b411-cd99-41cf-2525-08dd16adfac7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|376014|7416014|82310400026|1800799024; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?+qa/yUL1d3QdPp0XvV+rfvpR0waCVpnNrP2Z6qcNRnuryjjeNRBJEERL51uj?= =?us-ascii?Q?weuuOZV0jJk4gAOVI+FF9DpMav+r8yJ+jTfT7TQw2/SuNtn9p7QYq8/yLHvm?= =?us-ascii?Q?gNgeUCpn/3pKsRlZZUf6AaVmaM7LR9lRITZchEKI4X64sfTT+dFwgFxymw59?= =?us-ascii?Q?O0rpDGUzZEVn0nDQ22n8DfAMbM8sr2dntAAImKsn7t3B6aHXjGuwRs+ikRn6?= =?us-ascii?Q?MOOjgV7CHgr8eF3YHZaMpsJPItEqNjcdl3vq9X7Q42/uQkVK6aSjsKO8n6bz?= =?us-ascii?Q?3Cei0JOIkPYNfVOzzrbk5erVR0WE5CsQUDYQqX5IQkF9fCZ84+y9sorxD5DP?= =?us-ascii?Q?oqLzpoGzat5dqyFcTCY+z22i41A/uNL/20g//KB1GOd2uKXb/AWpRCO+Xfh5?= =?us-ascii?Q?qeVE0WARvWXwtwEdpiVOwD5j6nCt0GHos5BcfJLXRj4T2BXJ1ghU8/1V5MBB?= =?us-ascii?Q?2nNQxjph0tE4wklH5qIilcCuXDPhOWROzxzuDK1Gdqru/Ne5kZCCO4F51RRe?= =?us-ascii?Q?GDvdwSHyE+Slk6XAbEPEu59PYZ5q9DwUjoDN6d7X4j6xNegfYcnWI2QGUU5c?= =?us-ascii?Q?ygLk8E4qXSnXQD6KBHAVDQxhVvp2BwauMBMObTOuGMifABQku11YFchgcOfx?= =?us-ascii?Q?zidK9Iz7MVW5yY+gA4gWTYGRlbh/JwnRF6MYZXhjEec217h3xjpMGJUlqjtJ?= =?us-ascii?Q?skbYAO8y4mW/8llD1hGYDQPWeUfQIA0tWELTEyZ6CN9yAEucVVwShpvcvCzU?= =?us-ascii?Q?M18584lDBHx9/ZOE69Uogfq8PYKUOa7zRhAQj6mgmQAhc5aLvxNNYD7a/ETN?= =?us-ascii?Q?tPvbT/9TdZ5OwVNVQ4tZRKb4U7vNjzVI4tsNXasbtLCSwJ6wUEdhwQmcj7BC?= =?us-ascii?Q?1ayHO8N3wZdXGVOqfw0HHcpYoxrDrLjGBWlLFwC9RYntowFneZ0u8U1DbZs+?= =?us-ascii?Q?IvMdAFS/9+QOPfybWhdVH75ctPjWXSVk6t5r1DFRhMFfu3taG+umnAalNfGm?= =?us-ascii?Q?OSosjeCioNmoUSqIE/L8WJJqQ03Ll8nyjoDOEmDM5jmDbokdxnxzq/lCg5oz?= =?us-ascii?Q?3kqrJoIBCQzqwGOwmI+LSoIL8kfWAR0B4SE//9pGnd4/Js9ImiwK9eCxPjEU?= =?us-ascii?Q?qtWlFHIX6Yn7vj4kXqWnjXKRWtFCZIHcJTHfHljBIPxa7HDthoa0FQQg5L6C?= =?us-ascii?Q?giwEzdlvr4w0lc7IRa/ugFCUwVohifqj3TeZ7ea6etVKlc+IrWC6UOOVW19z?= =?us-ascii?Q?AXdx6PwTle1ZvHQB9tf3Y6Bca/rOWOxcbzN7HxhamiHRS5vh+VuQOImCMN1h?= =?us-ascii?Q?5N1Jk7vqe2bY9IDf0yLFvo55zna62oJmfFJkVirK1lycmtBoutpgdnL8Rodh?= =?us-ascii?Q?fYcWSUeGnu8RH4/SlLcWQyXq7B3fYDilwWREqg555DavrEbW/CPxJfsryI44?= =?us-ascii?Q?RcK8IQgi9OTEh6ABpiBud4DN4+tlJ+t1?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(7416014)(82310400026)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2024 10:57:44.8361 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: de85b411-cd99-41cf-2525-08dd16adfac7 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN3PEPF0000B371.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7501 To implement passthrough dGPU prime in guest, virtio-gpu need to check p2pdma_distance of two GPUs. This adds a new command for guest to pass virtual pci notations of two pci devices to host and send xen privcmd to calculate physical p2pdma_distance. Signed-off-by: Julia Zhang --- hw/display/virtio-gpu-virgl.c | 47 +++++++++++++++++++++ hw/i386/xen/xen-hvm.c | 6 +++ include/hw/virtio/virtio-gpu-bswap.h | 12 ++++++ include/hw/xen/xen.h | 3 ++ include/standard-headers/linux/virtio_gpu.h | 19 +++++++++ 5 files changed, 87 insertions(+) diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c index 07faeb1834..eb9b193ade 100644 --- a/hw/display/virtio-gpu-virgl.c +++ b/hw/display/virtio-gpu-virgl.c @@ -16,6 +16,12 @@ #include "qemu/iov.h" #include "trace.h" #include "hw/virtio/virtio.h" +#include "hw/pci/pci.h" +#include "hw/pci/pci_bus.h" +#include "hw/virtio/virtio-pci.h" +#include "hw/virtio/virtio-bus.h" +#include "hw/xen/xen.h" + #include "hw/virtio/virtio-gpu.h" #include "hw/virtio/virtio-gpu-bswap.h" #include "hw/virtio/virtio-gpu-pixman.h" @@ -188,6 +194,44 @@ virtio_gpu_virgl_unmap_resource_blob(VirtIOGPU *g, return 0; } + +static void virgl_cmd_p2pdma_distance(VirtIOGPU *g, + struct virtio_gpu_ctrl_command *cmd) +{ + struct virtio_gpu_device_p2pdma_distance cmd_p; + struct virtio_gpu_resp_distance resp; + PCIDevice *client = NULL, *provider = NULL; + int ret; + + VIRTIO_GPU_FILL_CMD(cmd_p); + virtio_gpu_p2pdma_distance_bswap(&cmd_p); + + ret = pci_qdev_get_device(cmd_p.provider_bus, cmd_p.provider_slot, cmd_p.provider_func, &provider); + + if (ret) { + qemu_log_mask(LOG_GUEST_ERROR, "%s: virgl get physical device error: %s\n", + __func__, strerror(-ret)); + cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER; + return; + } + + ret = pci_qdev_get_device(cmd_p.client_bus, cmd_p.client_slot, cmd_p.client_func, &client); + if (ret) { + qemu_log_mask(LOG_GUEST_ERROR, "%s: virgl get physical device error: %s\n", + __func__, strerror(-ret)); + cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER; + return; + } + + int distance = xen_p2pdma_distance(provider->hostaddr.bus, provider->hostaddr.slot, + provider->hostaddr.function,client->hostaddr.bus, + client->hostaddr.slot, client->hostaddr.function); + + memset(&resp, 0, sizeof(resp)); + resp.hdr.type = VIRTIO_GPU_RESP_OK_P2PDMA_DISTANCE; + resp.distance = distance; + virtio_gpu_ctrl_response(g, cmd, &resp.hdr, sizeof(resp)); +} #endif static void virgl_cmd_create_resource_2d(VirtIOGPU *g, @@ -913,6 +957,9 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g, case VIRTIO_GPU_CMD_SUBMIT_3D: virgl_cmd_submit_3d(g, cmd); break; + case VIRTIO_GPU_CMD_P2PDMA_DISTANCE: + virgl_cmd_p2pdma_distance(g, cmd); + break; case VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D: virgl_cmd_transfer_to_host_2d(g, cmd); break; diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c index d3df488c48..c8dd27dad7 100644 --- a/hw/i386/xen/xen-hvm.c +++ b/hw/i386/xen/xen-hvm.c @@ -604,6 +604,12 @@ static bool xen_check_stubdomain(struct xs_handle *xsh) return is_stubdom; } +int xen_p2pdma_distance(uint32_t bus, uint32_t slot, uint32_t func, + uint32_t c_bus, uint32_t c_slot, uint32_t c_func) +{ + return xc_physdev_p2pdma_distance(xen_xc, bus, slot, func, c_bus, c_slot, c_func); +} + void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion **ram_memory) { MachineState *ms = MACHINE(pcms); diff --git a/include/hw/virtio/virtio-gpu-bswap.h b/include/hw/virtio/virtio-gpu-bswap.h index dd1975e2d4..b5c0c0adcd 100644 --- a/include/hw/virtio/virtio-gpu-bswap.h +++ b/include/hw/virtio/virtio-gpu-bswap.h @@ -78,6 +78,18 @@ virtio_gpu_map_blob_bswap(struct virtio_gpu_resource_map_blob *mblob) le64_to_cpus(&mblob->offset); } +static inline void +virtio_gpu_p2pdma_distance_bswap(struct virtio_gpu_device_p2pdma_distance *p2p_dist) +{ + virtio_gpu_ctrl_hdr_bswap(&p2p_dist->hdr); + le32_to_cpus(&p2p_dist->provider_bus); + le32_to_cpus(&p2p_dist->provider_slot); + le32_to_cpus(&p2p_dist->provider_func); + le32_to_cpus(&p2p_dist->client_bus); + le32_to_cpus(&p2p_dist->client_bus); + le32_to_cpus(&p2p_dist->client_bus); +} + static inline void virtio_gpu_unmap_blob_bswap(struct virtio_gpu_resource_unmap_blob *ublob) { diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h index ecb89ecfc1..fe1d628327 100644 --- a/include/hw/xen/xen.h +++ b/include/hw/xen/xen.h @@ -48,4 +48,7 @@ qemu_irq *xen_interrupt_controller_init(void); void xen_register_framebuffer(struct MemoryRegion *mr); +int xen_p2pdma_distance(uint32_t bus, uint32_t slot, uint32_t func, + uint32_t c_bus, uint32_t c_slot, uint32_t c_func); + #endif /* QEMU_HW_XEN_H */ diff --git a/include/standard-headers/linux/virtio_gpu.h b/include/standard-headers/linux/virtio_gpu.h index 6459fdb9fb..2e55dcc2fe 100644 --- a/include/standard-headers/linux/virtio_gpu.h +++ b/include/standard-headers/linux/virtio_gpu.h @@ -95,6 +95,7 @@ enum virtio_gpu_ctrl_type { VIRTIO_GPU_CMD_SUBMIT_3D, VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB, VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB, + VIRTIO_GPU_CMD_P2PDMA_DISTANCE, /* cursor commands */ VIRTIO_GPU_CMD_UPDATE_CURSOR = 0x0300, @@ -108,6 +109,7 @@ enum virtio_gpu_ctrl_type { VIRTIO_GPU_RESP_OK_EDID, VIRTIO_GPU_RESP_OK_RESOURCE_UUID, VIRTIO_GPU_RESP_OK_MAP_INFO, + VIRTIO_GPU_RESP_OK_P2PDMA_DISTANCE, /* error responses */ VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200, @@ -429,6 +431,23 @@ struct virtio_gpu_set_scanout_blob { uint32_t offsets[4]; }; +/* VIRTIO_GPU_CMD_P2PDMA_DISTANCE */ +struct virtio_gpu_device_p2pdma_distance { + struct virtio_gpu_ctrl_hdr hdr; + __le32 provider_bus; + __le32 provider_slot; + __le32 provider_func; + __le32 client_bus; + __le32 client_slot; + __le32 client_func; +}; + +/* VIRTIO_GPU_RESP_DISTANCE */ +struct virtio_gpu_resp_distance { + struct virtio_gpu_ctrl_hdr hdr; + __le32 distance; +}; + /* VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB */ struct virtio_gpu_resource_map_blob { struct virtio_gpu_ctrl_hdr hdr; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat Dec 07 11:00:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 07 Dec 2024 11:00:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850688.1265072 (Exim 4.92) (envelope-from ) id 1tJsXy-0004EM-0L; Sat, 07 Dec 2024 11:00:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850688.1265072; Sat, 07 Dec 2024 11:00:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tJsXx-0004EF-Tw; Sat, 07 Dec 2024 11:00:25 +0000 Received: by outflank-mailman (input) for mailman id 850688; Sat, 07 Dec 2024 11:00: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 1tJsXw-0004E9-NB for xen-devel@lists.xenproject.org; Sat, 07 Dec 2024 11:00:24 +0000 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on20627.outbound.protection.outlook.com [2a01:111:f403:2417::627]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7464947a-b48a-11ef-a0d5-8be0dac302b0; Sat, 07 Dec 2024 12:00:23 +0100 (CET) Received: from SJ0PR03CA0078.namprd03.prod.outlook.com (2603:10b6:a03:331::23) by LV8PR12MB9111.namprd12.prod.outlook.com (2603:10b6:408:189::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.12; Sat, 7 Dec 2024 11:00:17 +0000 Received: from CO1PEPF000044FD.namprd21.prod.outlook.com (2603:10b6:a03:331:cafe::c3) by SJ0PR03CA0078.outlook.office365.com (2603:10b6:a03:331::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.9 via Frontend Transport; Sat, 7 Dec 2024 11:00:16 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by CO1PEPF000044FD.mail.protection.outlook.com (10.167.241.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8272.0 via Frontend Transport; Sat, 7 Dec 2024 11:00:15 +0000 Received: from jenkins-julia.amd.com (10.180.168.240) 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; Sat, 7 Dec 2024 05:00:10 -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: 7464947a-b48a-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Er3g1LeEd+tDUQkY1k7rKlLf4GN/8cRHuiX3o1svnMQT53x4+jZyfivH4HcFVJMmFMGmbVBVfDJ2H210sgY9OG7EDIfgg2myOQI+CVg78p7C1EDdaaxCSzDbB7ZvUQ3E4gnVadzk8/Svsg4EQJMAU3Gasa1UYJ+ey2injg4oHHHJStJysK5cPj7O7Z5pNQHeIS69ViGJ/mSvqERP9iZ3B3VSmfUZDDqG4dWwpMs5M5goqaWxfLhsTYOcH0BaaDjJEiCX8irv2q3QEU9eL0RfC6kbgJWHkjJihc+qtH8P4DJ+eiutYBtWikwN307gON0XAN21Xl4GVkb3gL5zvfcTvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ijr4V8vm1YJGIO6GrqqHeyIQQ8oHc1GLvuA8nvRmTjY=; b=bjFUJH2jcoLL7qQB5r3Fu6w0KTG4UkOoVFLoURLRZ+PZY9bP0j5vj9tbzOaP/vhSM5ODzJHzfQCvkidFmi2oSCK6kG4mLQOILjfuN3qWIP5s/DLd47FHmkNJ6rbcddOTX01qYcAmU9pFKDxtv+6Tj4dSxIDG+hdldijtjIP5XLh1jR44vuoK6vmlU/er3OfNVXoiefFQg5lT3B5DGz0qNavsISwWlgAh035Nh/MjJW1qIngz58Q2bPwlyrZe0Gy+MWToUgc1/6UL/6qTZSqumqm2rU3k2l35aNj+zij3U28mY1YDS8VE4X4mvvndKbNgD+VG1+8rmlAjHMpRhZrNsg== 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=ijr4V8vm1YJGIO6GrqqHeyIQQ8oHc1GLvuA8nvRmTjY=; b=VlpbfAyOwDL1W22mpH+tsabVhtqy/ZSTmLTS0N6HHkAYVt0TXCYh1+6bAaoPPe5Z4o+f4RxAQ7APKIaOm4liLEeHf2gkDvPo+am2476UiFWUD7lGPlpiiIkocLpv9pwkBaFuGOEvJw+R88idmoJg6SMduvayCQGDMoe34h6EpG0= 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=SATLEXMB04.amd.com; pr=C From: Julia Zhang To: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jan Beulich , Anthony PERARD , CC: Stefano Stabellini , Alex Deucher , =?UTF-8?q?Christian=20K=C3=B6nig?= , Xenia Ragiadakou , "Julia Zhang" , Chen Jiqian , Huang Rui , Penny Zheng , Zhu Lingshan , Paul Durrant , "Edgar E . Iglesias" , "Michael S . Tsirkin" , "Marcel Apfelbaum" , Juergen Gross , Oleksandr Tyshchenko Subject: [PATCH] xen: add privcmd ioctl to get p2pdma_distance Date: Sat, 7 Dec 2024 18:59:46 +0800 Message-ID: <20241207105946.542491-1-julia.zhang@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PEPF000044FD:EE_|LV8PR12MB9111:EE_ X-MS-Office365-Filtering-Correlation-Id: 29263f75-f1d5-46e0-c003-08dd16ae54cd X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|376014|7416014|82310400026; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?5TbJt/kSUA6L5Q51rIhtBjQ4cWfnk4WhK3C3oZFRmvc1ZBcjAA+trd5onSIM?= =?us-ascii?Q?w9B1B7GLBMK674L4MYEU1knS4ptyyGeXfcZTGAjnvgYHxpPS/OL3CSblNktn?= =?us-ascii?Q?yPnSENmv7rUBz1C2s+RRdP+uRrOvUXQ9tI1Gy/iGOulbYEUhi473QNqdib1e?= =?us-ascii?Q?RhvkOKVew+A7rQw3rur4mex0uyyByJTfti69yJ5RYWn41MPLLlPWpWdWP6cR?= =?us-ascii?Q?jv37LT5yEFlFuxuvQVwNUeaS0oW319N1zgsNy4BofQtQ07C7UzzbJ4JbVNLm?= =?us-ascii?Q?BXWjmCj4GBrJYWnEjZVcD+3RtEWVvWwImf8KcLj+VdLemMIgWLs3SlEAq18I?= =?us-ascii?Q?jWT3gOHe4WiHPoPE+xbcjFv6Wd6UTh7+ufmAtzo+Uf/09Sj2Q2cAmXFPaThE?= =?us-ascii?Q?SUCQ43mgUd0AK4KKkqD6Oi0M3wH2bQLZM8WM/r3tJ/Yhf/5iuUI6FF1jhyoT?= =?us-ascii?Q?QXy71eeluoeFeJfrmkylWfqYyPjvMNQggNEBbPjnkH+65FkTm7pR6mpuonlR?= =?us-ascii?Q?LYHDtzH6gNF47qH2p7pFSM6YJgkY2E9vzmnRfVluFrkjeqFn8GcCaby5HfPe?= =?us-ascii?Q?+Gu4H8mGUnwJ1fZOEhk+R22GqOtysXIjEl1/yAM+5ZhGoVOdAML5dOaYYvJK?= =?us-ascii?Q?JveKQrt1X6w0y4Ck5lri7RAJYAQUe/slvW2KgKidHLsfFbwQi76JXjiRFcBu?= =?us-ascii?Q?RpFNmQpHsuu0Mxmbmw03YWhYL4qFQR7TiCwLw8kBaNhboxud3pTZo7sw+qZj?= =?us-ascii?Q?GsvY8xIKJC3KcQ/FNJA7TTxS8gDeoU8DwJDYUElF7goGwtPR8nnAh7Ov74Nm?= =?us-ascii?Q?2bJZ4QaL/U5WhveTuvBaF+fRmyDhrqqT8s9MR4J7iP7f3MIMZP9884Eseh6s?= =?us-ascii?Q?URyZy6v/2abxFaXw/+0c/gDUXzRh+KQS12JLA4o80TffBRnVHuHRPgTfzDXo?= =?us-ascii?Q?MhwRUsR+5USCp2oYVvUeeMKUrix2cxw98wUPitILzVS6K9Gejfscf4Rq9+wC?= =?us-ascii?Q?dUTkchFKldSx7FD5KqVDfSpl5vp5P9dFDGQASW4teMWMO+/DWDtFMSjHdWuq?= =?us-ascii?Q?pkBntXog6tHt2+INdz3FVmMoutQpZQinER1jms7fAV8GsE+JhzfsWtdeXhoI?= =?us-ascii?Q?BxxaG9mu+D7X7sOgq9GX7KpHKwXhioopjdyPl+k5CBhmwvAIxK2B82l4d0WI?= =?us-ascii?Q?+KONyawcLhpUEYngRjlMLm6zVnHh4VSt1+JaNB3Teb2ndOP3ApPd7+2LQjnG?= =?us-ascii?Q?dB+FZqmtDUvIfWPszwaWfEm/Sw7jTjNXpuxdpxiWOD5VOiw2O7dt41kT1Nh2?= =?us-ascii?Q?MzR4L8Gc0wMDXGVLnZKsos9ikSiKX0QpZPIYonMYKjbRwbfhD1QAMjwfmrQI?= =?us-ascii?Q?CGLQXcrgrmLbzz8poJ/0QEOKm7dPGjuF8vuNwRLsWOUAQWua2MysO+rZvz7X?= =?us-ascii?Q?ZdnSlWFRP4Xz9OlB0cjX9ev3UyUtlMNE?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(7416014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2024 11:00:15.7806 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 29263f75-f1d5-46e0-c003-08dd16ae54cd 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CO1PEPF000044FD.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9111 To implement dGPU prime feature, virtgpu driver need to get p2pdma_distance of two GPU from host side. This adds a new privcmd ioctl to get the real p2pdma_distance of two pci devices in the host with pci notations sent from guest side. Signed-off-by: Julia Zhang --- tools/include/xen-sys/Linux/privcmd.h | 12 ++++++++++++ tools/include/xenctrl.h | 17 +++++++++++++++++ tools/libs/ctrl/xc_freebsd.c | 11 +++++++++++ tools/libs/ctrl/xc_linux.c | 24 ++++++++++++++++++++++++ tools/libs/ctrl/xc_minios.c | 11 +++++++++++ tools/libs/ctrl/xc_netbsd.c | 11 +++++++++++ tools/libs/ctrl/xc_physdev.c | 12 ++++++++++++ tools/libs/ctrl/xc_solaris.c | 11 +++++++++++ 8 files changed, 109 insertions(+) diff --git a/tools/include/xen-sys/Linux/privcmd.h b/tools/include/xen-sys/Linux/privcmd.h index 5071ebcc8b..fbdc9aa927 100644 --- a/tools/include/xen-sys/Linux/privcmd.h +++ b/tools/include/xen-sys/Linux/privcmd.h @@ -110,6 +110,16 @@ typedef struct privcmd_map_hva_to_gpfns { int add_mapping; } privcmd_map_hva_to_gpfns_t; +typedef struct privcmd_p2pdma_distance { + __u32 provider_bus; + __u32 provider_slot; + __u32 provider_func; + __u32 client_bus; + __u32 client_slot; + __u32 client_func; + __u32 distance; +} privcmd_p2pdma_distance_t; + /* * @cmd: IOCTL_PRIVCMD_HYPERCALL * @arg: &privcmd_hypercall_t @@ -131,6 +141,8 @@ typedef struct privcmd_map_hva_to_gpfns { _IOC(_IOC_NONE, 'P', 7, sizeof(privcmd_mmap_resource_t)) #define IOCTL_PRIVCMD_PCIDEV_GET_GSI \ _IOC(_IOC_NONE, 'P', 10, sizeof(privcmd_pcidev_get_gsi_t)) +#define IOCTL_PRIVCMD_P2PDMA_DISTANCE \ + _IOC(_IOC_NONE, 'P', 11, sizeof(privcmd_p2pdma_distance_t)) #define IOCTL_PRIVCMD_MAP_HVA_TO_GPFNS \ _IOC(_IOC_NONE, 'P', 13, sizeof(privcmd_map_hva_to_gpfns_t)) #define IOCTL_PRIVCMD_UNIMPLEMENTED \ diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h index 29617585c5..42d15a22b8 100644 --- a/tools/include/xenctrl.h +++ b/tools/include/xenctrl.h @@ -1654,6 +1654,23 @@ int xc_physdev_unmap_pirq(xc_interface *xch, int xc_pcidev_get_gsi(xc_interface *xch, uint32_t sbdf); +int xc_physdev_p2pdma_distance(xc_interface *xch, + uint32_t bus, + uint32_t slot, + uint32_t func, + uint32_t c_bus, + uint32_t c_slot, + uint32_t c_func); + +int xc_pcidev_p2pdma_distance(xc_interface *xch, + uint32_t bus, + uint32_t slot, + uint32_t func, + uint32_t c_bus, + uint32_t c_slot, + uint32_t c_func); + + /* * LOGGING AND ERROR REPORTING */ diff --git a/tools/libs/ctrl/xc_freebsd.c b/tools/libs/ctrl/xc_freebsd.c index 9019fc6633..4e0df06b7c 100644 --- a/tools/libs/ctrl/xc_freebsd.c +++ b/tools/libs/ctrl/xc_freebsd.c @@ -60,6 +60,17 @@ void *xc_memalign(xc_interface *xch, size_t alignment, size_t size) return ptr; } +int xc_pcidev_p2pdma_distance(xc_interface *xch, + uint32_t bus, + uint32_t slot, + uint32_t func, + uint32_t c_bus, + uint32_t c_slot, + uint32_t c_func) +{ + return -1; +} + int xc_pcidev_get_gsi(xc_interface *xch, uint32_t sbdf) { errno = ENOSYS; diff --git a/tools/libs/ctrl/xc_linux.c b/tools/libs/ctrl/xc_linux.c index 92591e49a1..9aeff2328f 100644 --- a/tools/libs/ctrl/xc_linux.c +++ b/tools/libs/ctrl/xc_linux.c @@ -66,6 +66,30 @@ void *xc_memalign(xc_interface *xch, size_t alignment, size_t size) return ptr; } +int xc_pcidev_p2pdma_distance(xc_interface *xch, + uint32_t bus, + uint32_t slot, + uint32_t func, + uint32_t c_bus, + uint32_t c_slot, + uint32_t c_func) +{ + privcmd_p2pdma_distance_t p2pdma_distance = { + .provider_bus = bus, + .provider_slot = slot, + .provider_func = func, + .client_bus = c_bus, + .client_slot = c_slot, + .client_func = c_func, + .distance = -1, + }; + if (!ioctl(xencall_fd(xch->xcall), IOCTL_PRIVCMD_P2PDMA_DISTANCE, &p2pdma_distance)) { + return p2pdma_distance.distance; + } + + return -1; +} + int xc_pcidev_get_gsi(xc_interface *xch, uint32_t sbdf) { int ret; diff --git a/tools/libs/ctrl/xc_minios.c b/tools/libs/ctrl/xc_minios.c index 462af827b3..4698cca5ea 100644 --- a/tools/libs/ctrl/xc_minios.c +++ b/tools/libs/ctrl/xc_minios.c @@ -47,6 +47,17 @@ void *xc_memalign(xc_interface *xch, size_t alignment, size_t size) return memalign(alignment, size); } +int xc_pcidev_p2pdma_distance(xc_interface *xch, + uint32_t bus, + uint32_t slot, + uint32_t func, + uint32_t c_bus, + uint32_t c_slot, + uint32_t c_func) +{ + return -1; +} + int xc_pcidev_get_gsi(xc_interface *xch, uint32_t sbdf) { errno = ENOSYS; diff --git a/tools/libs/ctrl/xc_netbsd.c b/tools/libs/ctrl/xc_netbsd.c index 1318d4d906..7e0ee8417e 100644 --- a/tools/libs/ctrl/xc_netbsd.c +++ b/tools/libs/ctrl/xc_netbsd.c @@ -63,6 +63,17 @@ void *xc_memalign(xc_interface *xch, size_t alignment, size_t size) return valloc(size); } +int xc_pcidev_p2pdma_distance(xc_interface *xch, + uint32_t bus, + uint32_t slot, + uint32_t func, + uint32_t c_bus, + uint32_t c_slot, + uint32_t c_func) +{ + return -1; +} + int xc_pcidev_get_gsi(xc_interface *xch, uint32_t sbdf) { errno = ENOSYS; diff --git a/tools/libs/ctrl/xc_physdev.c b/tools/libs/ctrl/xc_physdev.c index 25e686d7b3..4ee8f39e09 100644 --- a/tools/libs/ctrl/xc_physdev.c +++ b/tools/libs/ctrl/xc_physdev.c @@ -138,3 +138,15 @@ int xc_physdev_unmap_pirq(xc_interface *xch, return rc; } +int xc_physdev_p2pdma_distance(xc_interface *xch, + uint32_t bus, + uint32_t slot, + uint32_t func, + uint32_t c_bus, + uint32_t c_slot, + uint32_t c_func) +{ + return xc_pcidev_p2pdma_distance(xch, bus, slot, func, + c_bus, c_slot, c_func); +} + diff --git a/tools/libs/ctrl/xc_solaris.c b/tools/libs/ctrl/xc_solaris.c index 049e28d55c..a054b40b31 100644 --- a/tools/libs/ctrl/xc_solaris.c +++ b/tools/libs/ctrl/xc_solaris.c @@ -32,6 +32,17 @@ void *xc_memalign(xc_interface *xch, size_t alignment, size_t size) return memalign(alignment, size); } +int xc_pcidev_p2pdma_distance(xc_interface *xch, + uint32_t bus, + uint32_t slot, + uint32_t func, + uint32_t c_bus, + uint32_t c_slot, + uint32_t c_func) +{ + return -1; +} + int xc_pcidev_get_gsi(xc_interface *xch, uint32_t sbdf) { errno = ENOSYS; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat Dec 07 14:23:16 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 07 Dec 2024 14:23:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850716.1265083 (Exim 4.92) (envelope-from ) id 1tJvhy-0005aV-5Y; Sat, 07 Dec 2024 14:22:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850716.1265083; Sat, 07 Dec 2024 14:22: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 1tJvhy-0005aO-1J; Sat, 07 Dec 2024 14:22:58 +0000 Received: by outflank-mailman (input) for mailman id 850716; Sat, 07 Dec 2024 14:22: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 1tJvhw-0005aI-T0 for xen-devel@lists.xenproject.org; Sat, 07 Dec 2024 14:22:57 +0000 Received: from EUR02-AM0-obe.outbound.protection.outlook.com (mail-am0eur02on2060e.outbound.protection.outlook.com [2a01:111:f403:2606::60e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bf2fa115-b4a6-11ef-99a3-01e77a169b0f; Sat, 07 Dec 2024 15:22:54 +0100 (CET) Received: from AS9PR06CA0110.eurprd06.prod.outlook.com (2603:10a6:20b:465::29) by AS2PR08MB8999.eurprd08.prod.outlook.com (2603:10a6:20b:5fb::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.24; Sat, 7 Dec 2024 14:22:49 +0000 Received: from AM4PEPF00025F97.EURPRD83.prod.outlook.com (2603:10a6:20b:465:cafe::94) by AS9PR06CA0110.outlook.office365.com (2603:10a6:20b:465::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.14 via Frontend Transport; Sat, 7 Dec 2024 14:22:49 +0000 Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM4PEPF00025F97.mail.protection.outlook.com (10.167.16.6) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8272.0 via Frontend Transport; Sat, 7 Dec 2024 14:22:49 +0000 Received: ("Tessian outbound c267e87e9f97:v522"); Sat, 07 Dec 2024 14:22:48 +0000 Received: from L75766dc71869.3 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 4AB1FB90-0ED1-47EB-A475-26219F216410.1; Sat, 07 Dec 2024 14:22:42 +0000 Received: from EUR03-AM7-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id L75766dc71869.3 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 07 Dec 2024 14:22:42 +0000 Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21) by DBAPR08MB5608.eurprd08.prod.outlook.com (2603:10a6:10:1a5::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Sat, 7 Dec 2024 14:22:37 +0000 Received: from DBAPR08MB5798.eurprd08.prod.outlook.com ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com ([fe80::4a66:d3e2:570:9632%5]) with mapi id 15.20.8230.016; Sat, 7 Dec 2024 14:22: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: bf2fa115-b4a6-11ef-99a3-01e77a169b0f ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=GN+uYZ7TbidrRLp3htBSEsJ+EMzCfq2O2gWIs3ihYuYbqc/IslMC/MyxHZNAso8x2aNHXGpXnxuq9LqLOEqi9Mt5NeXAZ0DsO2xIsp/A9PEY6V8FjDU0k1Td20zHNoKclpvlJ7ycZbzFB9cVbYsucXDcT7MrXDvL9bZ1lChk60eBZEmDLMNwPeT89DZL/ITpVzFoEjyKNEqy0GHO4YDWR8kzZ95MQCanOCDOmovsHYKRznGyFG9ywBtXJKn3DO8xP7tHnIfuQKS4fopRxsxegGtAZUcGLpkvQ7UcQ8BBXq6grgH2Jmbv+LyFF8zitqHGQ3b4ThqiBiLfqWC4GTe6hw== 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=mjg6SbQSrbWZeOUJmTnq+i/dGyvRusweKp9+LjxjinA=; b=swYlE1uX8Fxy30adtFWucCodK5A9UoT1/Zo3cs/eP50t1tkKCsbXSNNC8I1HuEk5M7liGE9uloJybHzrUxDhW/9O7DX1lcYXjQ8YqYVMBbv9UfOQL00UaujyCcT9ROMxijciD0bzAJazTi0gz1RYPtoFwHEhYEEKZbHI9zc9KRIricAbq7u1lv4I2wwaGe1ypDGRi2bMbAL0o5zc3GTDg9pyFX4Qz7HmobWSmavEcWQIOs8/B//n/T5vKZr/jA6tBqFWeMTfHc4KDu68GPByHqXxR8GEsBX9sfTb/bQWjOa1gKHzGC0Kg+hBB1ObCzTg9eOnrje1q1htKy2qDhLInQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=mjg6SbQSrbWZeOUJmTnq+i/dGyvRusweKp9+LjxjinA=; b=CWCHjm+xFG1vDrj758eesphLAY4sqkqJIfJKZucHxb4lNsmE749Y5Ypk9chcU7zqFfBpy24RkTTeThRG0wyAaLlYEgdynorW11sreaD3FUYj3RbVqNmiPwQj+UrEBfO8ceJZhl/i0i3y0kL2ROugAbAsoVuBCcXLzPwfFoZ3nxc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) 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 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C X-CheckRecipientChecked: true X-CR-MTA-CID: c39016705bb5611b X-TessianGatewayMetadata: KR2o1nWGUo/eDQS+JWXmKVp2wtmdWFhDMfm9zPmC8BIgQK/CqSL2z16xwvVizV/hqWrBANZOy6xY5vC4UxWbtaZK2291F0+k7m6B9Wih86gPSvuB4pQlmN6WqEYcZbMFnKx/8K3S7TeSKvViBnrytjzAxMv4ZbEdV0djWCaCUG8= X-CR-MTA-TID: 64aa7808 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ay1U1DwpJ5a/FZfNU8AP7Kpxl6xdn+BBmvHkP3AQ/GR7PKCw72CyU6JReyJW9ZZTmMX+R6W9VnkeZfX10QigrrKxoCB38MkJIW+lKKooZfh9wai6IecavgDv2coUBsw8ZnJ+6n2nDtRpWR7wy/+ZqSVf9y3Bb0rx8ew1Zp8nI3AF0WAW0PuovmbizXV+mc/Cg4wlJzfUJPRgDK+Xhgj1P18093wdMOhIVaCiyAJv8glLYKT1QRsvU/NUzgh6dcm6rax0kC9PjxIstYCdkFusvowObduBIcDPEOEgOIZ7vA13DojTVovNs7CQ37vosQ4sEbwVBYi3ERDv+S+gDJJlTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mjg6SbQSrbWZeOUJmTnq+i/dGyvRusweKp9+LjxjinA=; b=Q/YdKLbkkZF5p2wwMnHOKNEx98uI1YDSTtk4xE212WmkuCOWJi1ToLDWIJk238sjY5lUEl52s/nn37nWOoEDKHd8HJfIL3rXt5WR7PUG4CCXaPIEXSL8+xL/d3yCe1FFmHQQEdvJv+VfxT2IwpOGVhpRk9/aInF2bFbw3lmM8V/lGdbPI4TJ0biuLUXFR16Y7jg4hb8QsOHpzMgJ/enXB2oINCiYt83A120NFVRYWOY7WYgxlGZFKT71cTc/2DauULwnAaYWwvNf6YIJ2dP9Rmp6zXr4nMXQPBujutuQQEIa3VUxeDQNpqtJl5+IV5sX8gbwE1lnO3p61+QtQJ2NjQ== 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=mjg6SbQSrbWZeOUJmTnq+i/dGyvRusweKp9+LjxjinA=; b=CWCHjm+xFG1vDrj758eesphLAY4sqkqJIfJKZucHxb4lNsmE749Y5Ypk9chcU7zqFfBpy24RkTTeThRG0wyAaLlYEgdynorW11sreaD3FUYj3RbVqNmiPwQj+UrEBfO8ceJZhl/i0i3y0kL2ROugAbAsoVuBCcXLzPwfFoZ3nxc= From: Luca Fancellu To: Julien Grall CC: "xen-devel@lists.xenproject.org" , Penny Zheng , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Jan Beulich , Wei Chen Subject: Re: [PATCH v4 4/5] xen/arm: Check for Static Heap feature when freeing resources Thread-Topic: [PATCH v4 4/5] xen/arm: Check for Static Heap feature when freeing resources Thread-Index: AQHbRWiMK0NBCC8wPk6qtayhLuvPaLLZnNkAgAE/IIA= Date: Sat, 7 Dec 2024 14:22:37 +0000 Message-ID: References: <20241203094811.427076-1-luca.fancellu@arm.com> <20241203094811.427076-5-luca.fancellu@arm.com> <00c7c6ce-f50d-43ac-b411-3e051b9bb582@xen.org> In-Reply-To: <00c7c6ce-f50d-43ac-b411-3e051b9bb582@xen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3826.200.121) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DBAPR08MB5798:EE_|DBAPR08MB5608:EE_|AM4PEPF00025F97:EE_|AS2PR08MB8999:EE_ X-MS-Office365-Filtering-Correlation-Id: 147a22cc-0967-4522-e7f7-08dd16caa0b2 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|376014|1800799024|38070700018; X-Microsoft-Antispam-Message-Info-Original: =?utf-8?B?SGFPSGRKMDBQVkV2YVJMcGJLcEVOcGJsMTNaL1h3SU5ENElIL0VqZGIzZENy?= =?utf-8?B?c1BWZDBnekFQcXYwSW9ZN3BJRXRWRUM1bE1sYXVyZHpTSjNoV0VHM015bmFO?= =?utf-8?B?TCtOeVAyYnZtV3RhZU11L2lPTzJmT3RmalIxWHV0S2Q2dHNEdzBQY1lzRi95?= =?utf-8?B?L253ckNBdXJscXBVWGFUemw0NHpQVjA1R3pzVTcycDFtZ0R6K3pvVkZ4Z24z?= =?utf-8?B?TzJ3cEhXU3l0eHg0emJZVG9ncnFwcmlieVlnYXJvQnIwZTUzMk40UGhuM2pF?= =?utf-8?B?YkxLUHRwOGk4ekNDVExzeFh1c2pDeU1pMnRHTDhjWkF4dlJsWFp3cXA1OTls?= =?utf-8?B?TmNoNTNYN2tldXdpd1pUL1M0RnEzZVRUc2pxd3FLSGlFbEplNloyaFRxbGpu?= =?utf-8?B?c3NpMmdBVWgzRE9SYUtwUEdpSlhYazhqM3BSUDhmRVBtcUYyQmduaitpZUVu?= =?utf-8?B?cnlJbm5OeVBXeDJCNXJwMUUxUStlZlRsZ3A2V20vVmU0Y2N1dU4vdkdBUlFj?= =?utf-8?B?WTg0aUlOZkNSNDFHRzRkSHhRTXlseDhYY0kyU0JSQWk1aWxuV3EyZEZvWlpj?= =?utf-8?B?TTBHT0xkSkhlM3JOV1NLZDFVYmdYaWxGTlVlWGQzcFpWTTBRRklsRG9KZVJa?= =?utf-8?B?U1JKb2pzSVFveDlCTHFMMU00c1NpV0xkMFFIYmFvY2tDUmQ0eTUrWEtaTmd4?= =?utf-8?B?SGpkWEJPdDZxR1BVdU1iVDNnci9vZkN0cmR1SmE5d0I0REZlT3RyM0s1ZVE1?= =?utf-8?B?c1NJZXE3WE9vc1JHRmkyc09pRUhRdGZoU0pLeEdPeFlZVWtBRkVBVFY3dTlK?= =?utf-8?B?ZUlKNWkwaTVxSExRTDhZQVgzdGI5dHQ3azdPbFduaUNXdGVmMnJLNkt4NElP?= =?utf-8?B?ZWppVDU4UWFzdHNmcndKQkF0WG13MHhEdjRGekw3V3lnZHJFVFNaV2UzbVln?= =?utf-8?B?bzk5a3p5dG5PRWdhcWJtMTRQNERzb3lJOXkrQ0hvMWoyYXI5MHQ3OTh3SEkv?= =?utf-8?B?RjhtRlBzRWRZbG9QaTNpYlV5NWpPWTNHcmR3WXVXRnBRT0l4a2dpUGF2U3FC?= =?utf-8?B?MnJoQW5JOEFyQlF4RnQyLzBjbERUS3VSQzUwdnVlWFlIYWtVbFg0T3I0dEY0?= =?utf-8?B?dmJyQi9ieTc0MkJDWHMxemd5OWhJS29ONEo2M0UzQ3RyN0pyekp2TEw3QTEv?= =?utf-8?B?ZGlGRUtLdHdnY1VheWFuc2hZYUdxZGxWY0FSTW5OUnRCM2x5N3dBTDRxR3hq?= =?utf-8?B?ZGVaSTI2eEdTcXNHY1NIL3N1NmFpR1BrNXRCZFpqaHE0M1ZDTnRmUmM5azR1?= =?utf-8?B?UGNwbXN6WEZoRzN4ZlJpTUNadmUvU3VRZllQYzBGc0lsTkVPVnJmLzhlTGFN?= =?utf-8?B?U1BDT3gwWHVyUlREcEUrWUFnVTFMT0J4RWdrRjErZ2ErMmM0WGFmSWFzTkVZ?= =?utf-8?B?MmtDaWpJN242NVJJOGQ2Z2VhVWpiZjNIYitVWlhWSkROTzE5R0lDTTNUUlov?= =?utf-8?B?ZTNCSjFWbGF3cHoxeDRMUE9ZREpuSzd2Q0F0aG1Wdllwa1VOVjVaZ2hhRDQv?= =?utf-8?B?eHpVbk02bktxM2VPN001ekJKbklYeDZqeE1WOEJCMXdzdkFEcXMrK21JVHJ1?= =?utf-8?B?V1RMS1I4RS9oblNKeW96MkplUXJCUCszcFFPRjkzZjRrU2taclcyZW1hQWpK?= =?utf-8?B?WWZZZFZyMnB6TFFQaFhOZ0ZSWkxicnJVd2l2UWVSWXBVMEljQlRXc3hmeTJ0?= =?utf-8?B?RUxXSDFHVUhabFg1Mkk3NEJDNzNEMTZvcmFlcFM4WXhjUHdQam5WdytJTXlD?= =?utf-8?B?YlZ0cGR2WWUrY2lrUEU2RmgzbkRJSmtyYytoYkQrc1VKTXJRREd0cE5xdW1I?= =?utf-8?B?M1NLSTh3eVVsamNuRlRIb0M3QjhTdDZxcEhOeHR4NFNSVmc9PQ==?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="utf-8" Content-ID: <0B5CF9B46FE33043BE803C8E4F515933@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR08MB5608 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-SkipListedInternetSender: ip=[2603:10a6:10:1a6::21];domain=DBAPR08MB5798.eurprd08.prod.outlook.com X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM4PEPF00025F97.EURPRD83.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: ee9bf355-0f40-4df5-bc25-08dd16ca9984 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|35042699022|82310400026|14060799003|1800799024|36860700013; X-Microsoft-Antispam-Message-Info: =?utf-8?B?T090VldhYUFoUEtud3N6MkFaZXdOYUFqN0h4RGhiUDJJUzNKeTdpZGk5ZnRB?= =?utf-8?B?Zll2T2M5MW5KWFZYajVTTFNES3RKQkZGUVB1QUtMdkVlYkIxY2paYVJpbFE2?= =?utf-8?B?TWVPakJBN25MQ3dRa1Y3Mzcwbm9pZHFKR0NvTUJ6NXI3dG5KN3ZCYVFCREl3?= =?utf-8?B?RkNQQ3oyU2hZQzZMM00yZzViY29nZjdxV29obm1MMDU2Smx1bFptZksyOU5h?= =?utf-8?B?UVNZbnhQNXZVellYWkY5eGJCSG5nbEt3Vk0vaGxjSm9xdjN2R3NHdFN1cTBv?= =?utf-8?B?SzZkYXFsMHkvMC9CbU54Ymc3QllsbVNoTWxhQloyckRIYTNxT0RRNHlzT2Vq?= =?utf-8?B?MEpEUnlhbnoralhsRDVOaTlmVU02V1hXSjl2Njd5UmNPL1VlUzRJNXFmSUZn?= =?utf-8?B?Zm14a1NhNitXUnBWT2ZKaW1qZ1JUWm90V00vd0p3RDBZd2FiUlBaOVQwMmNH?= =?utf-8?B?eHFuL09GN2NUaW1XQkFNd1h3UHhoNFRXeTRpMFMvd3JNSjNzUUV5enlTcHNx?= =?utf-8?B?TzlOelJHQzB6TFhPc0lYazd5TUc4cnp2MjNqSzNsODVkbktlVFZYVDdXMlk2?= =?utf-8?B?bVhNaFJHYjliV2F1TFdBWVppTDFXampkL2JjV1UwMWtXenlqSVd6aVFodTRJ?= =?utf-8?B?NThlM1lhMXBpOUNaOUczbWx1L0dBa1JhTnQ1VVlGb3dELzNRNUZUWnRVcW54?= =?utf-8?B?Nzg1NmNYVExZcDlUVkpLN20xbWhWbVNjMExTaDQwOVZybmhxMUJjRFNQcm1l?= =?utf-8?B?UlVLekRtZDFPZnZQNXNNTGtUdkZCWHlPaTEwY2Y2ZnpQb2w2SHFWUDlyV3hj?= =?utf-8?B?NWJlV3hGYWxtbk5IMUlZamVHT3I0VjJjM0VzendKUnRzMmVyWWl6WU9oNWJv?= =?utf-8?B?T1lQa1ZMNHp4RzdiUDJKZ3BSdDJyczVVOWFSMlBOZjRkRmd6UXE3YUM2eTlr?= =?utf-8?B?Zm1jeWliclBaaTcwUVllZzZsc2tPanlvRVdsQ0RYcnZMejZ6WVRwTVIxYmVF?= =?utf-8?B?WXYvZzYwblVsNFIwQ0ZMdTloaVA1b0RBQlNPdHh6eFNBUHpyZkpHRng0QTg1?= =?utf-8?B?S0c2S054dGppanhFRGtVT2hLQTNNR2FuN1lOWFFWWE5POHcrcGEzUlExdWll?= =?utf-8?B?OUJ4cXc0MFJQYWNEM2U5bnk0V21jZ1pHZ1IvY2swaklaVHlMTElMaCtBdmdX?= =?utf-8?B?c2dOaFkycmszU3ZlK0FHOVp0OU1odHUvT1RaU09hajY4TzhlT0Fna3E5Y1dm?= =?utf-8?B?bDlHMWxCdEVMS0U4YkNQVlQ0NXVOLzZoYVVmdnVLK0FHbmhYSHEvMS9HUHpv?= =?utf-8?B?Vnc3SndtNExhN0VnVFlHM2FuOE96eHcreW9ycjhnT2tTL3FaajZLczNpT01E?= =?utf-8?B?QzZRV3pDTWlHWDdVWUhzY3Mwa1NUWlBaQWpXVDY3alhhTjJhUERwWU5uTnJG?= =?utf-8?B?Q0pGeU0wWHZBVk4xWk5YT0FabVRpK2x1Q1FubUhmVVkxRjEvRk9vLzdXa0gr?= =?utf-8?B?RlBGVGUyMitQdmFLVWFiZnVYSTUxVi9GMW05VmtGcFVUUzk2V2d6K0VHM3o4?= =?utf-8?B?TnN0NCt0MVFCaTFCclpCSlhGN3lVK0JBZDNqeENla2tDZkRnS0g3SU92bHYz?= =?utf-8?B?QVZxYmJXdGd3eENBQm5RT1kvTnJuY1FGY1l3T2ZoZUt5elludS85QVhxZjBV?= =?utf-8?B?VkVpL2c2c3h4MG9QOGphZk15V1RIN2VHRWlZMHBrakkxaGUxOStiMnd6RjZC?= =?utf-8?B?ZHlEdzZKNVRmWHVnM1l2cEdiTXd1WW8wWFdBejNkV0FDcDI1TGdWbnRsUnM4?= =?utf-8?B?THdTdDQzNWl6U0lDbnVIbjZQZ0ZzaDZSYXNTbXpKVEJ3akpEOGo4R2tuRzBG?= =?utf-8?B?NVFuNW5oa2NFdFphNjM3NUU0R3lrUGtlMms1U0RqaVEvSXBqVXJOTEpqaHZt?= =?utf-8?B?MEVNdEdIU1Jqano1U2Rwek5yOW5pSWxjTzducEtOa3ZzdXc5OWlKa3JXenhp?= =?utf-8?B?enJsYXFRYVpBPT0=?= X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(376014)(35042699022)(82310400026)(14060799003)(1800799024)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2024 14:22:49.1137 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 147a22cc-0967-4522-e7f7-08dd16caa0b2 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM4PEPF00025F97.EURPRD83.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB8999 SGkgSnVsaWVuLA0KDQo+IE9uIDYgRGVjIDIwMjQsIGF0IDE5OjE5LCBKdWxpZW4gR3JhbGwgPGp1 bGllbkB4ZW4ub3JnPiB3cm90ZToNCj4gDQo+IEhpIEx1Y2EsDQo+IA0KPiBPbiAwMy8xMi8yMDI0 IDA5OjQ4LCBMdWNhIEZhbmNlbGx1IHdyb3RlOg0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2Fy bS9tbXUvc2V0dXAuYyBiL3hlbi9hcmNoL2FybS9tbXUvc2V0dXAuYw0KPj4gaW5kZXggOTY2NGU4 NWVlNmMwLi44Yzg3NjQ5YmM4OGUgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vbW11L3Nl dHVwLmMNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9tbXUvc2V0dXAuYw0KPj4gQEAgLTM0MSw4ICsz NDEsMTIgQEAgdm9pZCBmcmVlX2luaXRfbWVtb3J5KHZvaWQpDQo+PiAgICAgIGlmICggcmMgKQ0K Pj4gICAgICAgICAgcGFuaWMoIlVuYWJsZSB0byByZW1vdmUgdGhlIGluaXQgc2VjdGlvbiAocmMg PSAlZClcbiIsIHJjKTsNCj4+ICAtICAgIGluaXRfZG9taGVhcF9wYWdlcyhwYSwgcGEgKyBsZW4p Ow0KPj4gLSAgICBwcmludGsoIkZyZWVkICVsZGtCIGluaXQgbWVtb3J5LlxuIiwgKGxvbmcpKF9f aW5pdF9lbmQtX19pbml0X2JlZ2luKT4+MTApOw0KPj4gKyAgICBpZiAoICF1c2luZ19zdGF0aWNf aGVhcCApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIGluaXRfZG9taGVhcF9wYWdlcyhwYSwgcGEg KyBsZW4pOw0KPj4gKyAgICAgICAgcHJpbnRrKCJGcmVlZCAlbGRrQiBpbml0IG1lbW9yeS5cbiIs DQo+PiArICAgICAgICAgICAgICAgKGxvbmcpKF9faW5pdF9lbmQtX19pbml0X2JlZ2luKSA+PiAx MCk7DQo+PiArICAgIH0NCj4+ICB9DQo+PiAgICAvKioNCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJj aC9hcm0vc2V0dXAuYyBiL3hlbi9hcmNoL2FybS9zZXR1cC5jDQo+PiBpbmRleCAyZTI3YWY0NTYw YTUuLjIyYWIzNDJkYzhmNCAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9zZXR1cC5jDQo+ PiArKysgYi94ZW4vYXJjaC9hcm0vc2V0dXAuYw0KPj4gQEAgLTIwNiwyNCArMjA2LDI1IEBAIHZv aWQgX19pbml0IGRpc2NhcmRfaW5pdGlhbF9tb2R1bGVzKHZvaWQpDQo+PiAgICAgIHN0cnVjdCBi b290bW9kdWxlcyAqbWkgPSAmYm9vdGluZm8ubW9kdWxlczsNCj4+ICAgICAgaW50IGk7DQo+IA0K PiBMb29raW5nIGF0IHRoZSBjaGFuZ2UgYmVsb3csIGl0IHNlZW1zIHRoYXQgZGlzY2FyZF9pbml0 aWFsX21vZHVsZXMoKQ0KPiBpcyBhIE5PUCBmb3Igc3RhdGljX2hlYXAuIERvIHlvdSBmb3JzZWUg YW55IHJlYXNvbiB3aGVyZSBpdCB3b3VsZCBiZSBkaWZmZXJlbnQ/DQoNCnlvdSBhcmUgcmlnaHQs IHRoZSBjb2RlIGNvdWxkIGJlIGEgbG90IHNpbXBsZXIuDQoNCknigJl2ZSBwcmVwYXJlZCBhIGRp ZmYgb24gdG9wIG9mIHRoaXMgcGF0Y2ggaWYgeW91IGFyZSBvayB0byBkbyB0aGF0IG9uIGNvbW1p dCwgYnV0DQpJdCB3b27igJl0IGJlIGEgcHJvYmxlbSBmb3IgbWUgdG8gc2VuZCBhbm90aGVyIHBh dGNoIGZvciB0aGF0Lg0KDQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL3NldHVwLmMgYi94ZW4v YXJjaC9hcm0vc2V0dXAuYw0KaW5kZXggMjJhYjM0MmRjOGY0Li44NWY3NDNhMmM2YWQgMTAwNjQ0 DQotLS0gYS94ZW4vYXJjaC9hcm0vc2V0dXAuYw0KKysrIGIveGVuL2FyY2gvYXJtL3NldHVwLmMN CkBAIC0yMDYsMjUgKzIwNiwyNyBAQCB2b2lkIF9faW5pdCBkaXNjYXJkX2luaXRpYWxfbW9kdWxl cyh2b2lkKQ0KICAgICBzdHJ1Y3QgYm9vdG1vZHVsZXMgKm1pID0gJmJvb3RpbmZvLm1vZHVsZXM7 DQogICAgIGludCBpOw0KIA0KLSAgICBpZiAoICF1c2luZ19zdGF0aWNfaGVhcCApDQotICAgIHsN Ci0gICAgICAgIGZvciAoIGkgPSAwOyBpIDwgbWktPm5yX21vZHM7IGkrKyApDQotICAgICAgICB7 DQotICAgICAgICAgICAgcGFkZHJfdCBzID0gbWktPm1vZHVsZVtpXS5zdGFydDsNCi0gICAgICAg ICAgICBwYWRkcl90IGUgPSBzICsgUEFHRV9BTElHTihtaS0+bW9kdWxlW2ldLnNpemUpOw0KKyAg ICBpZiAoIHVzaW5nX3N0YXRpY19oZWFwICkNCisgICAgICAgIHJldHVybjsNCiANCi0gICAgICAg ICAgICBpZiAoIG1pLT5tb2R1bGVbaV0ua2luZCA9PSBCT09UTU9EX1hFTiApDQotICAgICAgICAg ICAgICAgIGNvbnRpbnVlOw0KKyAgICBmb3IgKCBpID0gMDsgaSA8IG1pLT5ucl9tb2RzOyBpKysg KQ0KKyAgICB7DQorICAgICAgICBwYWRkcl90IHMgPSBtaS0+bW9kdWxlW2ldLnN0YXJ0Ow0KKyAg ICAgICAgcGFkZHJfdCBlID0gcyArIFBBR0VfQUxJR04obWktPm1vZHVsZVtpXS5zaXplKTsNCiAN Ci0gICAgICAgICAgICBpZiAoICFtZm5fdmFsaWQobWFkZHJfdG9fbWZuKHMpKSB8fA0KLSAgICAg ICAgICAgICAgICAgIW1mbl92YWxpZChtYWRkcl90b19tZm4oZSkpICkNCi0gICAgICAgICAgICAg ICAgY29udGludWU7DQorICAgICAgICBpZiAoIG1pLT5tb2R1bGVbaV0ua2luZCA9PSBCT09UTU9E X1hFTiApDQorICAgICAgICAgICAgY29udGludWU7DQogDQotICAgICAgICAgICAgZndfdW5yZXNl cnZlZF9yZWdpb25zKHMsIGUsIGluaXRfZG9taGVhcF9wYWdlcywgMCk7DQotICAgICAgICB9DQor ICAgICAgICBpZiAoICFtZm5fdmFsaWQobWFkZHJfdG9fbWZuKHMpKSB8fA0KKyAgICAgICAgICAg ICAhbWZuX3ZhbGlkKG1hZGRyX3RvX21mbihlKSkgKQ0KKyAgICAgICAgICAgIGNvbnRpbnVlOw0K IA0KLSAgICAgICAgbWktPm5yX21vZHMgPSAwOw0KKyAgICAgICAgZndfdW5yZXNlcnZlZF9yZWdp b25zKHMsIGUsIGluaXRfZG9taGVhcF9wYWdlcywgMCk7DQogICAgIH0NCisNCisgICAgbWktPm5y X21vZHMgPSAwOw0KKw0KKyAgICByZW1vdmVfZWFybHlfbWFwcGluZ3MoKTsNCiB9DQogDQogLyog UmVsb2NhdGUgdGhlIEZEVCBpbiBYZW4gaGVhcCAqLw0KDQoNCg0KDQo= From xen-devel-bounces@lists.xenproject.org Sat Dec 07 15:05:17 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 07 Dec 2024 15:05:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850727.1265092 (Exim 4.92) (envelope-from ) id 1tJwMo-0002KO-9J; Sat, 07 Dec 2024 15:05:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850727.1265092; Sat, 07 Dec 2024 15:05: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 1tJwMo-0002KH-5x; Sat, 07 Dec 2024 15:05:10 +0000 Received: by outflank-mailman (input) for mailman id 850727; Sat, 07 Dec 2024 15:05: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 1tJwMn-0002KB-09 for xen-devel@lists.xenproject.org; Sat, 07 Dec 2024 15:05:09 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on20600.outbound.protection.outlook.com [2a01:111:f403:2416::600]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a452d76a-b4ac-11ef-a0d5-8be0dac302b0; Sat, 07 Dec 2024 16:05:07 +0100 (CET) Received: from BL0PR0102CA0023.prod.exchangelabs.com (2603:10b6:207:18::36) by DS7PR12MB6287.namprd12.prod.outlook.com (2603:10b6:8:94::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.19; Sat, 7 Dec 2024 15:05:00 +0000 Received: from BL02EPF0001A101.namprd05.prod.outlook.com (2603:10b6:207:18:cafe::9d) by BL0PR0102CA0023.outlook.office365.com (2603:10b6:207:18::36) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.14 via Frontend Transport; Sat, 7 Dec 2024 15:04:59 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by BL02EPF0001A101.mail.protection.outlook.com (10.167.241.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Sat, 7 Dec 2024 15:04:59 +0000 Received: from SATLEXMB05.amd.com (10.181.40.146) 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; Sat, 7 Dec 2024 09:04:59 -0600 Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sat, 7 Dec 2024 09:04:59 -0600 Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Sat, 7 Dec 2024 09:04:57 -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: a452d76a-b4ac-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=V+xV5UCkagxsqwrsK//7NBd9QQfoR1cdZ/75Iou2SlGhTenxlneqF7vkYepM0C7QU/zQSyCpsG31JlyN8MXv6fnSbpSYAoL9v2i+aomS8PpWMzb7eirORHwAM7TKiMFziBTxhPPOw7FwI7Sg6mzEhbdQwnfKciwUeyo7bb29WDg2Qm1vtXKrC79kgWM01hsxQZZn++4fy742dFMfacYqHmIg1kPSjJ4cbo+gEUSORAeAsxqqIkcfESA2bL7oin9hmCl6qjzIIUljHJJAKZVD5cufUuFKsrKblwF9XXRhcJB53501cat8/loUAl5aUIhHlbjvI71Xkfstpfm1XNl/vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Goaf2cLRAl/AL80zw5mgkKLWyhL9ZglY54NrZBl+zd4=; b=CfaxSvdkxQa5DN1if0WV3ZAp4FbO+77Xt6caIpqd3JTQJp7B2fPW7BzUXOdcAIHiVdjE820iQtvrZSiblH7NEpyomj+cpyqC86JZpPx7ONLAwgOq9HGGfyjcgAetPJSHrtWUBR3D/RlCdZGZpBOcGdW7wcdmVFL7cmYMujc1IRXr7DWtYH9uqziu1+olgJq+/EYeo+XusuQZdkcuCIKm91sgSJeVAqqf0wJjZybAAZuzcbKlNBo7ks7kYjJrzEuuZKVRCFvXgtYmXgd/p5Qg/kLE3pkjDLCWfENNaW2dp+wKyakGFE7tOETwWw3RvkKKBEB8G1RhDs+mwZqpPOgYiA== 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=Goaf2cLRAl/AL80zw5mgkKLWyhL9ZglY54NrZBl+zd4=; b=fHGsLO1hoXNyqriMOBcgETF03JA7FkQBGbLrvjK0z5l9/0+dDdCz6q68HLf3wT1hEHuAhRJVdvW+7QMjb9Z206KS8hbzAlXsrgjqreVCjWVqkfv73zVI1s2lcp5SNFBTQYIzRznUX5UJxJcrN3p82l4jWKx7MbwHlraEoFkoSjE= 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=SATLEXMB04.amd.com; pr=C Message-ID: <293004fa-c87e-4a45-aa4c-b02456aaecea@amd.com> Date: Sat, 7 Dec 2024 16:04:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 03/12] xen/arm: permit non direct-mapped Dom0 construction To: Julien Grall , Carlo Nonato , CC: , , "Stefano Stabellini" , Bertrand Marquis , Volodymyr Babchuk References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> <20241202165921.249585-4-carlo.nonato@minervasys.tech> <7ecc99c5-0cb5-4351-bede-cb03c9a4ac7e@xen.org> Content-Language: en-US From: Michal Orzel In-Reply-To: <7ecc99c5-0cb5-4351-bede-cb03c9a4ac7e@xen.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB05.amd.com: michal.orzel@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF0001A101:EE_|DS7PR12MB6287:EE_ X-MS-Office365-Filtering-Correlation-Id: ce7debb1-de9a-462e-d190-08dd16d08531 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?a3ZNWVI1QmFtTjlHZ1JPWnZwV2ZMZ2NIc0Y3dTRTazNudEw1aUFad20xMGxn?= =?utf-8?B?S0FrQm1nRE1aL2RuVkxxdEFYU2QzbHd0dDFIcUY5ZjJoeXVjTmJRdmdFZWJJ?= =?utf-8?B?aWNaUUJOWkNzUE5CQmYyZGU1NlVsY2ZmTzhrZVhRbTVoWHV6V1VzNnZXV0Ns?= =?utf-8?B?RWkvNyt0dHJmL2E1a1lId0hITzFQUDVqc2thd2hSdzE4Tk5vdTNWVE51UUor?= =?utf-8?B?eVRsMjQrVUFnc05rRFVxSEdBd0JFNEsyQVJlRjArSG81dys3WGhoQXBZS2F2?= =?utf-8?B?QUJnU3NmZ1pJOXRNUFkwSmZvT0RhMFpsdmF2aWpOK3M3NUlkcWo4Qk9HN1U1?= =?utf-8?B?ZGhYeUwwZ2lEdzF2eHhVM1FUbXNRWUJ5bDZpblBOb09tV2Z6V2ZLNmt3blVz?= =?utf-8?B?UlZINVBING4waG9uR0cyS2l3QTRHSkxkblJGSWxvUnJPQWNHS0tyRTFETGk0?= =?utf-8?B?NERVb0Vmb2ZpWW5KU3FWR0I4eUtRMFFvRmI2ckVEdDJpY09JcDZ5ekNzNWpv?= =?utf-8?B?RmwvYS9VQTZOLzlKSXphdnZScFAvS2U5ZUx4T3R0T2xub2pCbHdpdVdLSnF3?= =?utf-8?B?bExveUlZbVVxWnU4UEpTdHQrT1FzSFlUU1p4NzF1c3VZQ29iQVY1TVNpTHk3?= =?utf-8?B?K3M2TnZSY09MVkV5QmRwZnF5V0dNZjFhZjdIaUc1eHpjRkd3WUtHOHVCdGtk?= =?utf-8?B?NlhVdTh2eVdsYzh5TTBLOTJuWmZEcEZQNi9NblVPY1ROVTZXUXkraUVlb1V3?= =?utf-8?B?Sk1NTmJ4Yy9rUk5Oc1dTNVNZYThBcldIU0twYU9SaW91R3kvdTVNNU4zeWJN?= =?utf-8?B?clRFOUNuYjJxU1RIaFZaNGQxQkZhQlVuUVdlenp3Q1ZaRlJMOW1tNjhSZGY5?= =?utf-8?B?TFJvMnJMYnQ1bS84TW1SMU83ZmZlVWRHdFBERHcvOG5lNnF0OVNRUnhYelU4?= =?utf-8?B?RVlpQ3E2L3o5ZkV6bi9KcERCRWFNRStlb1doT2VseDBOQ3pDYWZucnc5REdn?= =?utf-8?B?S3pIOEVXZTEyUld4ZTBRKzZNMDZKSklPY2FaWEo3ZHFBbXZWL0ordEx0QXkr?= =?utf-8?B?cnd6dDRkRm1UNTlRRkxOcFNwWHZBM3BPeHYxdDg2UFdNNDNZN2wybDVjNHov?= =?utf-8?B?UDRKRVBRODRDM09zQTFEYmtRM2NSY28xMnNVU1Y2ODd1M0kreXhOb2hKS2pG?= =?utf-8?B?Q0JYNnVJWUFiVStnRWhuVWZIdERld1VoYm5mT09GZW9LSEJ1NHE3dURNNGpP?= =?utf-8?B?cmhZNlFaRWowSWsxcXlxR2d4QVNYWFkxZk5JR0s4b1BYVU9oalVUM3UvY3Ni?= =?utf-8?B?Sm9NV1hpKzRidDZwNi9rdE9pNS9XZDBOZ2g0bHlJVFNsbTAya0RmR3FrcmJH?= =?utf-8?B?YlZHU0NUa0NhL3dIVXZtYnpwcFc2UHFZREVVcDR6T0NIeFFVTWJkMFZySzBi?= =?utf-8?B?OFp6VjVjL1VFRGcrN1FYVzZ2SEE1WnFaOWhUVXJrYlVRT1h3bExIb0VreUdO?= =?utf-8?B?Vmc0RzVpbmlqL2ZrVnFaQlJxT1plam1QYk9Fa2RFakxCallMck1KSURhK1Aw?= =?utf-8?B?aUNmMXE2WWdRU3I2UG5LRHlsVm9YdmVDSlJFVFhvR0NwNGRHekQ2VUJxeGJK?= =?utf-8?B?VzFsVFB0c2l6STUrRXBUYytZTUNPbTloSWRkZzh1K2QzSStjdSsxSzJiMVhX?= =?utf-8?B?OVBQZG1ld0FYeUJXU0FyY1J4WWNBaUlEc2Z5MVZRR2FZd2JRSmZVTTU2Ly8r?= =?utf-8?B?cEdZQ3hhZWdNUmUwenFMbFJmc0dkY205SVNHa2E1V2lJUDlkOURIUUp6N0hM?= =?utf-8?B?NnJpajRDYmhLWFVZTWhsa2hOeWVqVFFYdE9PcldvTzdNMGQyMW9MKzNFNFlo?= =?utf-8?B?NUMrRjk3ZkVxV2NTZWRkTnpZMmgzaEsrZFd3U3NvTkQrcmc9PQ==?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2024 15:04:59.9496 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ce7debb1-de9a-462e-d190-08dd16d08531 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL02EPF0001A101.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6287 On 06/12/2024 19:37, Julien Grall wrote: > > > Hi, > > Sorry for the late answer. > > On 05/12/2024 09:40, Michal Orzel wrote: >> >> >> On 02/12/2024 17:59, Carlo Nonato wrote: >>> >>> >>> Cache coloring requires Dom0 not to be direct-mapped because of its non >>> contiguous mapping nature, so allocate_memory() is needed in this case. >>> 8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a separate module") >>> moved allocate_memory() in dom0less_build.c. In order to use it >>> in Dom0 construction bring it back to domain_build.c and declare it in >>> domain_build.h. >>> >>> Take the opportunity to adapt the implementation of allocate_memory() so >>> that it uses the host layout when called on the hwdom, via >>> find_unallocated_memory(). >>> >>> Signed-off-by: Carlo Nonato >>> --- >>> v11: >>> - GUEST_RAM_BANKS instead of hardcoding the number of banks in allocate_memory() >>> - hwdom_ext_regions -> hwdom_free_mem in allocate_memory() >>> - added a comment in allocate_memory() when skipping small banks >>> v10: >>> - fixed a compilation bug that happened when dom0less support was disabled >>> v9: >>> - no changes >>> v8: >>> - patch adapted to new changes to allocate_memory() >>> v7: >>> - allocate_memory() now uses the host layout when called on the hwdom >>> v6: >>> - new patch >>> --- >>> xen/arch/arm/dom0less-build.c | 44 ----------- >>> xen/arch/arm/domain_build.c | 97 ++++++++++++++++++++++++- >>> xen/arch/arm/include/asm/domain_build.h | 1 + >>> 3 files changed, 94 insertions(+), 48 deletions(-) >>> >>> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c >>> index d93a85434e..67b1503647 100644 >>> --- a/xen/arch/arm/dom0less-build.c >>> +++ b/xen/arch/arm/dom0less-build.c >>> @@ -49,50 +49,6 @@ bool __init is_dom0less_mode(void) >>> return ( !dom0found && domUfound ); >>> } >>> >>> -static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo) >>> -{ >>> - struct membanks *mem = kernel_info_get_mem(kinfo); >>> - unsigned int i; >>> - paddr_t bank_size; >>> - >>> - printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n", >>> - /* Don't want format this as PRIpaddr (16 digit hex) */ >>> - (unsigned long)(kinfo->unassigned_mem >> 20), d); >>> - >>> - mem->nr_banks = 0; >>> - bank_size = MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem); >>> - if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM0_BASE), >>> - bank_size) ) >>> - goto fail; >>> - >>> - bank_size = MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem); >>> - if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM1_BASE), >>> - bank_size) ) >>> - goto fail; >>> - >>> - if ( kinfo->unassigned_mem ) >>> - goto fail; >>> - >>> - for( i = 0; i < mem->nr_banks; i++ ) >>> - { >>> - printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n", >>> - d, >>> - i, >>> - mem->bank[i].start, >>> - mem->bank[i].start + mem->bank[i].size, >>> - /* Don't want format this as PRIpaddr (16 digit hex) */ >>> - (unsigned long)(mem->bank[i].size >> 20)); >>> - } >>> - >>> - return; >>> - >>> -fail: >>> - panic("Failed to allocate requested domain memory." >>> - /* Don't want format this as PRIpaddr (16 digit hex) */ >>> - " %ldKB unallocated. Fix the VMs configurations.\n", >>> - (unsigned long)kinfo->unassigned_mem >> 10); >>> -} >>> - >>> #ifdef CONFIG_VGICV2 >>> static int __init make_gicv2_domU_node(struct kernel_info *kinfo) >>> { >>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c >>> index 2c30792de8..2b8cba9b2f 100644 >>> --- a/xen/arch/arm/domain_build.c >>> +++ b/xen/arch/arm/domain_build.c >>> @@ -416,7 +416,6 @@ static void __init allocate_memory_11(struct domain *d, >>> } >>> } >>> >>> -#ifdef CONFIG_DOM0LESS_BOOT >>> bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size, >>> alloc_domheap_mem_cb cb, void *extra) >>> { >>> @@ -508,7 +507,6 @@ bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn, >>> >>> return true; >>> } >>> -#endif >>> >>> /* >>> * When PCI passthrough is available we want to keep the >>> @@ -1003,6 +1001,94 @@ out: >>> return res; >>> } >>> >>> +void __init allocate_memory(struct domain *d, struct kernel_info *kinfo) >>> +{ >>> + struct membanks *mem = kernel_info_get_mem(kinfo); >>> + unsigned int i, nr_banks = GUEST_RAM_BANKS; >>> + paddr_t bank_start, bank_size; >> Limit the scope >> >>> + struct membanks *hwdom_free_mem = NULL; >>> + const uint64_t bankbase[] = GUEST_RAM_BANK_BASES; >>> + const uint64_t banksize[] = GUEST_RAM_BANK_SIZES; >> Limit the scope >> >>> + >>> + printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n", >>> + /* Don't want format this as PRIpaddr (16 digit hex) */ >>> + (unsigned long)(kinfo->unassigned_mem >> 20), d); >>> + >>> + mem->nr_banks = 0; >>> + /* >>> + * Use host memory layout for hwdom. Only case for this is when LLC coloring >>> + * is enabled. >>> + */ >>> + if ( is_hardware_domain(d) ) >>> + { >>> + ASSERT(llc_coloring_enabled); >> This patch does not build because of declaration not being visible. You must include . > > Piggying back on this comment. AFAICT, the code below would work also in > the non cache coloring case. So what's the assert is for? > >> >>> + >>> + hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank, >>> + NR_MEM_BANKS); >>> + if ( !hwdom_free_mem ) >>> + goto fail; >>> + >>> + hwdom_free_mem->max_banks = NR_MEM_BANKS; >>> + >>> + if ( find_unallocated_memory(kinfo, hwdom_free_mem) ) >> My remarks for the use of find_unallocated_memory() 1:1 have not been addressed. You did not even >> change the comments inside the function. The problem is that the function is specifically designed >> for finding extended regions and assumes being called at certain point i.e. dom0 RAM allocated, gnttab >> region allocated, etc. > > So I agree that the function should be updated if we plan to use it for > other purpose. > > My opinion is that we should attempt to make the function generic so > that in your >> case you can choose which regions to exclude, define even your own function to grab free regions (at the moment >> add_ext_regions grabs banks >= 64M but you still discards banks >= 128M, so it's a bit wasteful. >> >> My very short attempt to make the function as generic as possible in the first iteration: >> https://paste.debian.net/1338334/ > > This looks better, but I wonder why we need still need to exclude the > static regions? Wouldn't it be sufficient to exclude just reserved regions? Static shared memory banks are not part of reserved memory (i.e. bootinfo.reserved_mem) if that's what you're asking. They are stored in bootinfo.shmem, hence we need to take them into account when searching for unused address space. If you and Carlo are ok with my proposed solution for making the function generic, I can send a patch as a prerequisite patch for Carlo series. ~Michal From xen-devel-bounces@lists.xenproject.org Sun Dec 08 20:39:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 08 Dec 2024 20:39:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.850903.1265134 (Exim 4.92) (envelope-from ) id 1tKO3H-0006RV-H1; Sun, 08 Dec 2024 20:38:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 850903.1265134; Sun, 08 Dec 2024 20:38:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKO3H-0006RN-CZ; Sun, 08 Dec 2024 20:38:51 +0000 Received: by outflank-mailman (input) for mailman id 850903; Sun, 08 Dec 2024 20:38: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 1tKO3G-0006RG-9A for xen-devel@lists.xenproject.org; Sun, 08 Dec 2024 20:38:50 +0000 Received: from sonata.ens-lyon.org (sonata.ens-lyon.org [140.77.166.138]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6c075fb2-b5a4-11ef-99a3-01e77a169b0f; Sun, 08 Dec 2024 21:38:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sonata.ens-lyon.org (Postfix) with ESMTP id 33603A1F94; Sun, 8 Dec 2024 21:38:46 +0100 (CET) Received: from sonata.ens-lyon.org ([127.0.0.1]) by localhost (sonata.ens-lyon.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rbm3GzcPKTYY; Sun, 8 Dec 2024 21:38:46 +0100 (CET) Received: from begin.home (aamiens-653-1-40-48.w83-192.abo.wanadoo.fr [83.192.199.48]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by sonata.ens-lyon.org (Postfix) with ESMTPSA id B7DD3A1F72; Sun, 8 Dec 2024 21:38:45 +0100 (CET) Received: from samy by begin.home with local (Exim 4.98) (envelope-from ) id 1tKO3B-00000004HD0-0HE9; Sun, 08 Dec 2024 21:38:45 +0100 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6c075fb2-b5a4-11ef-99a3-01e77a169b0f Date: Sun, 8 Dec 2024 21:38:45 +0100 From: Samuel Thibault To: Juergen Gross Cc: xen-devel@lists.xenproject.org, Anthony PERARD , Julien Grall Subject: Re: [PATCH v2 7/7] tools/xenstored: use new stable interface instead of libxenctrl Message-ID: Mail-Followup-To: Samuel Thibault , Juergen Gross , xen-devel@lists.xenproject.org, Anthony PERARD , Julien Grall References: <20241206130221.17773-1-jgross@suse.com> <20241206130221.17773-8-jgross@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20241206130221.17773-8-jgross@suse.com> Organization: I am not organized Juergen Gross, le ven. 06 déc. 2024 14:02:21 +0100, a ecrit: > Replace the current use of the unstable xc_domain_getinfo_single() > interface with the stable domctl XEN_DOMCTL_get_domain_state call > via the new libxenmanage library. > > This will remove the last usage of libxenctrl by Xenstore, so update > the library dependencies accordingly. > > For now only do a direct replacement without using the functionality > of obtaining information about domains having changed the state. > > Signed-off-by: Juergen Gross Reviewed-by: Samuel Thibault > --- > V1: > - use library instead of direct hypercall, only replace current > libxenctrl use case > > Please note that this patch can be committed only after the related > Mini-OS patch "config: add support for libxenmanage" has gone in AND > the Mini-OS commit-id has been updated in Config.mk accordingly! > > Signed-off-by: Juergen Gross > --- > stubdom/Makefile | 8 ++--- > stubdom/mini-os.mk | 1 + > tools/xenstored/Makefile | 2 +- > tools/xenstored/Makefile.common | 2 +- > tools/xenstored/core.h | 1 - > tools/xenstored/domain.c | 52 ++++++++++++--------------------- > tools/xenstored/lu.c | 1 + > tools/xenstored/lu_daemon.c | 1 + > 8 files changed, 28 insertions(+), 40 deletions(-) > > diff --git a/stubdom/Makefile b/stubdom/Makefile > index 2a81af28a1..ca800b243c 100644 > --- a/stubdom/Makefile > +++ b/stubdom/Makefile > @@ -307,7 +307,7 @@ endif > # libraries under tools/libs > ####### > > -STUB_LIBS := toolcore toollog evtchn gnttab call foreignmemory devicemodel ctrl guest > +STUB_LIBS := toolcore toollog evtchn gnttab call foreignmemory devicemodel ctrl guest manage > > LIBDEP_guest := cross-zlib > > @@ -465,7 +465,7 @@ grub: cross-polarssl grub-upstream $(CROSS_ROOT) grub-$(XEN_TARGET_ARCH)-minios- > # xenstore > ########## > > -xenstore-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog ctrl > +xenstore-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog manage > xenstore-minios.gen.cfg: xenstore-minios.cfg Makefile > $(GEN_config) >$@ > > @@ -480,7 +480,7 @@ xenstore: $(CROSS_ROOT) xenstore-minios-config.mk > # xenstorepvh > ############# > > -xenstorepvh-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog ctrl > +xenstorepvh-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog manage > xenstorepvh-minios.gen.cfg: xenstorepvh-minios.cfg Makefile > $(GEN_config) >$@ > > @@ -523,7 +523,7 @@ else > pv-grub-if-enabled: > endif > > -XENSTORE_DEPS := libxenevtchn libxengnttab libxenctrl > +XENSTORE_DEPS := libxenevtchn libxengnttab libxenmanage > > .PHONY: xenstore-stubdom > xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore $(XENSTORE_DEPS) xenstore > diff --git a/stubdom/mini-os.mk b/stubdom/mini-os.mk > index 7e4968e026..be32302f9e 100644 > --- a/stubdom/mini-os.mk > +++ b/stubdom/mini-os.mk > @@ -13,5 +13,6 @@ GNTTAB_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/gnttab > CALL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/call > FOREIGNMEMORY_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/foreignmemory > DEVICEMODEL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/devicemodel > +MANAGE_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/manage > CTRL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/ctrl > GUEST_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/guest > diff --git a/tools/xenstored/Makefile b/tools/xenstored/Makefile > index 09adfe1d50..81c42838e0 100644 > --- a/tools/xenstored/Makefile > +++ b/tools/xenstored/Makefile > @@ -5,7 +5,7 @@ include Makefile.common > > xenstored: LDLIBS += $(LDLIBS_libxenevtchn) > xenstored: LDLIBS += $(LDLIBS_libxengnttab) > -xenstored: LDLIBS += $(LDLIBS_libxenctrl) > +xenstored: LDLIBS += $(LDLIBS_libxenmanage) > xenstored: LDLIBS += -lrt > xenstored: LDLIBS += $(SOCKET_LIBS) > > diff --git a/tools/xenstored/Makefile.common b/tools/xenstored/Makefile.common > index 27fdb3b49e..271134fcc1 100644 > --- a/tools/xenstored/Makefile.common > +++ b/tools/xenstored/Makefile.common > @@ -12,7 +12,7 @@ XENSTORED_OBJS-$(CONFIG_MiniOS) += minios.o lu_minios.o > # Include configure output (config.h) > CFLAGS += -include $(XEN_ROOT)/tools/config.h > CFLAGS += $(CFLAGS_libxenevtchn) > -CFLAGS += $(CFLAGS_libxenctrl) > +CFLAGS += $(CFLAGS_libxenmanage) > CFLAGS += $(CFLAGS_libxentoolcore) > > $(XENSTORED_OBJS-y): CFLAGS += $(CFLAGS_libxengnttab) > diff --git a/tools/xenstored/core.h b/tools/xenstored/core.h > index e58779e88c..632886cecf 100644 > --- a/tools/xenstored/core.h > +++ b/tools/xenstored/core.h > @@ -19,7 +19,6 @@ > #ifndef _XENSTORED_CORE_H > #define _XENSTORED_CORE_H > > -#include > #include > > #include > diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c > index 64c8fd0cc3..c0264d9477 100644 > --- a/tools/xenstored/domain.c > +++ b/tools/xenstored/domain.c > @@ -34,14 +34,15 @@ > #include "control.h" > > #include > -#include > +#include > +#include > #include > > #ifdef __MINIOS__ > #include > #endif > > -static xc_interface **xc_handle; > +static xenmanage_handle *xm_handle; > xengnttab_handle **xgt_handle; > static evtchn_port_t virq_port; > > @@ -619,32 +620,28 @@ static int destroy_domain(void *_domain) > return 0; > } > > -static bool get_domain_info(unsigned int domid, xc_domaininfo_t *dominfo) > -{ > - return xc_domain_getinfo_single(*xc_handle, domid, dominfo) == 0; > -} > - > static int check_domain(const void *k, void *v, void *arg) > { > - xc_domaininfo_t dominfo; > + unsigned int state; > struct connection *conn; > - bool dom_valid; > + int dom_invalid; > struct domain *domain = v; > bool *notify = arg; > > - dom_valid = get_domain_info(domain->domid, &dominfo); > + dom_invalid = xenmanage_get_domain_info(xm_handle, domain->domid, > + &state, NULL); > if (!domain->introduced) { > - if (!dom_valid) > + if (dom_invalid) > talloc_free(domain); > return 0; > } > - if (dom_valid) { > - if ((dominfo.flags & XEN_DOMINF_shutdown) > + if (!dom_invalid) { > + if ((state & XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN) > && !domain->shutdown) { > domain->shutdown = true; > *notify = true; > } > - if (!(dominfo.flags & XEN_DOMINF_dying)) > + if (!(state & XENMANAGE_GETDOMSTATE_STATE_DYING)) > return 0; > } > if (domain->conn) { > @@ -786,10 +783,9 @@ static struct domain *find_or_alloc_domain(const void *ctx, unsigned int domid) > static struct domain *find_or_alloc_existing_domain(unsigned int domid) > { > struct domain *domain; > - xc_domaininfo_t dominfo; > > domain = find_domain_struct(domid); > - if (!domain && get_domain_info(domid, &dominfo)) > + if (!domain && !xenmanage_get_domain_info(xm_handle, domid, NULL, NULL)) > domain = alloc_domain(NULL, domid); > > return domain; > @@ -1187,12 +1183,6 @@ int do_reset_watches(const void *ctx, struct connection *conn, > return 0; > } > > -static int close_xc_handle(void *_handle) > -{ > - xc_interface_close(*(xc_interface**)_handle); > - return 0; > -} > - > static int close_xgt_handle(void *_handle) > { > xengnttab_close(*(xengnttab_handle **)_handle); > @@ -1258,15 +1248,9 @@ void domain_early_init(void) > if (!domhash) > barf_perror("Failed to allocate domain hashtable"); > > - xc_handle = talloc(talloc_autofree_context(), xc_interface*); > - if (!xc_handle) > - barf_perror("Failed to allocate domain handle"); > - > - *xc_handle = xc_interface_open(0,0,0); > - if (!*xc_handle) > - barf_perror("Failed to open connection to hypervisor"); > - > - talloc_set_destructor(xc_handle, close_xc_handle); > + xm_handle = xenmanage_open(NULL, 0); > + if (!xm_handle) > + barf_perror("Failed to open connection to libxenmanage"); > > xgt_handle = talloc(talloc_autofree_context(), xengnttab_handle*); > if (!xgt_handle) > @@ -1306,6 +1290,8 @@ void domain_deinit(void) > { > if (virq_port) > xenevtchn_unbind(xce_handle, virq_port); > + > + xenmanage_close(xm_handle); > } > > /* > @@ -1335,13 +1321,13 @@ int domain_alloc_permrefs(struct node_perms *perms) > { > unsigned int i, domid; > struct domain *d; > - xc_domaininfo_t dominfo; > > for (i = 0; i < perms->num; i++) { > domid = perms->p[i].id; > d = find_domain_struct(domid); > if (!d) { > - if (!get_domain_info(domid, &dominfo)) > + if (xenmanage_get_domain_info(xm_handle, domid, > + NULL, NULL)) > perms->p[i].perms |= XS_PERM_IGNORE; > else if (!alloc_domain(NULL, domid)) > return ENOMEM; > diff --git a/tools/xenstored/lu.c b/tools/xenstored/lu.c > index bec2a84e10..4fccbbc195 100644 > --- a/tools/xenstored/lu.c > +++ b/tools/xenstored/lu.c > @@ -11,6 +11,7 @@ > #include > #include > #include > +#include > #include > #include > > diff --git a/tools/xenstored/lu_daemon.c b/tools/xenstored/lu_daemon.c > index 6df6c80a2a..88d8d9e1b3 100644 > --- a/tools/xenstored/lu_daemon.c > +++ b/tools/xenstored/lu_daemon.c > @@ -6,6 +6,7 @@ > */ > > #include > +#include > #include > > #include "talloc.h" > -- > 2.43.0 > -- Samuel Client: "This program has been successfully installed." Vendeur (surpris): "Et où voyez-vous une erreur ?" Client: "C'est << HAS BEEN >> !" From xen-devel-bounces@lists.xenproject.org Mon Dec 09 07:48:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 07:48:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851017.1265175 (Exim 4.92) (envelope-from ) id 1tKYUo-0006Oj-8R; Mon, 09 Dec 2024 07:47:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851017.1265175; Mon, 09 Dec 2024 07:47:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKYUo-0006Oc-5a; Mon, 09 Dec 2024 07:47:58 +0000 Received: by outflank-mailman (input) for mailman id 851017; Mon, 09 Dec 2024 07:47: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 1tKYUn-0006OW-GA for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 07:47:57 +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 e5462cec-b601-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 08:47:53 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-3863703258fso731856f8f.1 for ; Sun, 08 Dec 2024 23:47: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 d9443c01a7336-215f8f29bcbsm66471555ad.262.2024.12.08.23.47.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Dec 2024 23:47: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: e5462cec-b601-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733730472; x=1734335272; 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=kdL9pa8zg2D/vtJQ8p0OpsKeztnS4n38G46C8uqAF5k=; b=RRwFP0sz2vB1tItT2KzQMWC/yO1N1D3L9uhR4jsB/LHvj8ywS1R1XsYVHrZgeZIg94 pbYq8p/3gMinI6I+DVEVMJOMW3VBdFOFSPPTOWYZ5Ozi9XOJiSKFicUtF26em0v98oOk MA15cv08DEK9qEjirkyLCzQFPEjBKSl4l7ClW9pXw/fHc1txCxiT/dWD6/WTqik5IeTn /mETQ0+9iW0mg1y5gyyU5Hdwr+1kH24rD8vtAWWGRVHv33NNGuBTF3ivp48lXbgOloiP ghVFcV8NJqEnB0fGEbUCIvPrsHUOC/x9elqoahzwD+KgFCNfMIu/m3CF123zPEgNhbSQ PpAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733730472; x=1734335272; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=kdL9pa8zg2D/vtJQ8p0OpsKeztnS4n38G46C8uqAF5k=; b=Q7LNEoKWQVhxGyLQ2iyv+v1+DalTxwrNd/2yTgATmBVxb/pgM9pxywDvYs0/keDUN8 0awwiTVqpfUrKhOheJE6J4zU/B28kx41OaycB3RB/wKyLp/Vw50WkA6lyQm1Us4cVRbg NqvqXHBuSC8HBlVixPP3eXBsfHmjviQReQFEf9JcIK6oWCNGJBZ49KJaDYwVeMy6ULCf wJEPG54w6Yu5kfoChh6zjIYwVCvzZoJeBu9hpHE3vOcQI8wrRqHxDisuPoVTfXv/7guS diGw0Zg22uPP3TNVgAsn5oxZN5V9oHW4zEf19ulHQBnDPHKroeiyqEu7aWD9ZSEQgO1j 77JA== X-Forwarded-Encrypted: i=1; AJvYcCUSpuv+9kuh42BMRy0ZnRQEuNC7sQhTY9JwnyqIVckHeCbVUQMqTTU2/0+n5r0IJUGlklNnS5uUrUM=@lists.xenproject.org X-Gm-Message-State: AOJu0YxLZdCBSw+kGV3MV9HzOqKJb2SrnxeRyelY+oA9xJ6ykuH854iR Wi81vc1O8Cy2XNy4TjbCIYJaNJtEVoCoFJvW6uQyRnJRUiIK6c3hpeHexgoiVw== X-Gm-Gg: ASbGncuXkpFXhxVXJPtZz0amDB6MDNeDMMVdpDp7d7uUgXuXrsq4RXGbLSrFfY4jvRn PnMvM9Ubrl8a6p/fJCftuLQaWZ7j2UfcMzuVpl4UD/boZu+QDYWn0AnQURAyLZKMVV3DcvuioSl pUJWyj3Yz7ANJiu8ZWFVh+JSD+AD7YzvTcp5iPP4iTutmqZxcP5foBqvw7rBkZjlOs1E3HJrZID DgprcGahQDeZgb9pvghR0OClYl68jMmGfXBzYIj+sQ34YBxoW+UmQX+Nrb13FVQ3SazZ5ZBVXWb h1rfXLGSUBVu0C29dUZe3LqDmivf4MuJEys= X-Google-Smtp-Source: AGHT+IFapL3mmL/DnMdBRUqJz6XjyN2AxoKmN7nZtURRn70VMOnqVmyUj+PvKq+X2GmkRavYuUwPmA== X-Received: by 2002:a05:6000:178d:b0:386:3958:2ec5 with SMTP id ffacd0b85a97d-38639583627mr2811198f8f.28.1733730472443; Sun, 08 Dec 2024 23:47:52 -0800 (PST) Message-ID: <03504a1e-c801-47fc-ac66-ab7e10ab6695@suse.com> Date: Mon, 9 Dec 2024 08:47:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: add privcmd ioctl to get p2pdma_distance To: Julia Zhang , Stefano Stabellini Cc: Alex Deucher , =?UTF-8?Q?Christian_K=C3=B6nig?= , Xenia Ragiadakou , Chen Jiqian , Huang Rui , Penny Zheng , Zhu Lingshan , Paul Durrant , "Edgar E . Iglesias" , "Michael S . Tsirkin" , Marcel Apfelbaum , Juergen Gross , Oleksandr Tyshchenko , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241207105946.542491-1-julia.zhang@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: <20241207105946.542491-1-julia.zhang@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 07.12.2024 11:59, Julia Zhang wrote: > To implement dGPU prime feature, virtgpu driver need to get > p2pdma_distance of two GPU from host side. > > This adds a new privcmd ioctl to get the real p2pdma_distance of two pci > devices in the host with pci notations sent from guest side. > > Signed-off-by: Julia Zhang First - correcting Anthony's email address. He's no longer at Citrix/Cloud. Second, please send patches To: the list, with maintainers on Cc:. (Stefano, as this isn't the first such issue, can you please try to spread the knowledge of this across people starting to contribute?) Personally I'd question the length of the Cc: list of this submission, though. Plus - along with Roger I was on the To: list here despite not even being maintainer of any of the files touched. > --- a/tools/include/xen-sys/Linux/privcmd.h > +++ b/tools/include/xen-sys/Linux/privcmd.h > @@ -110,6 +110,16 @@ typedef struct privcmd_map_hva_to_gpfns { > int add_mapping; > } privcmd_map_hva_to_gpfns_t; > > +typedef struct privcmd_p2pdma_distance { > + __u32 provider_bus; > + __u32 provider_slot; > + __u32 provider_func; > + __u32 client_bus; > + __u32 client_slot; > + __u32 client_func; > + __u32 distance; > +} privcmd_p2pdma_distance_t; "Distance" typically is a symmetric thing. Why the asymmetry here? And why __u32 when __u8 will be fine for most fields? And where's the segment part of the device coordinates? Finally, with it being merely stub implementations that you add here, all details on where the needed info is to come from are missing. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 08:24:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 08:24:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851032.1265186 (Exim 4.92) (envelope-from ) id 1tKZ3e-0003Pz-TY; Mon, 09 Dec 2024 08:23:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851032.1265186; Mon, 09 Dec 2024 08:23: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 1tKZ3e-0003Ps-Pr; Mon, 09 Dec 2024 08:23:58 +0000 Received: by outflank-mailman (input) for mailman id 851032; Mon, 09 Dec 2024 08:23: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 1tKZ3d-0003Pm-Uc for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 08:23:57 +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 ee3dbb26-b606-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 09:23:55 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-434a736518eso43555235e9.1 for ; Mon, 09 Dec 2024 00:23:55 -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 41be03b00d2f7-7fd35331cf8sm3781898a12.44.2024.12.09.00.23.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 00:23: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: ee3dbb26-b606-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733732635; x=1734337435; 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=6eRBZmuTMo1Tl+si5QD9VHBzq6N8KEMy+nnbBobucyc=; b=LuXozQ0PrZFVG5u0GiCx+uXFx2sXzFJa5TmdA0IoSkEWp0MjmohFi1NMj79ADexs3y zde2NdqK3RXvIo5Nm9p2Hn58sj52g9gVT9JoqMli5t+npRulObEP2XwT7nF/3olhD7+G tHgjMzhVLYFan+aKq8CqmtT90TRhZYY2R7A8ePIKl7TfAbwe56VTk3F+u+Y528HUCK1M 4TSjZ5PeeS1G83TOyFJNHXQDe7d2Rtdbs8bjKKjzo+alNb36YL1vSv8/P84V4niaBS/U 0NhgJZ3euvvjvyJrtc+YzvVu20wc2LQzHTO2j3Plt1bFFPxnQY9JZ79N8OVoSBfuXeUI hO5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733732635; x=1734337435; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6eRBZmuTMo1Tl+si5QD9VHBzq6N8KEMy+nnbBobucyc=; b=rkSH3+28O0MmSqpRRHy2yWmteoS4XB1jUlej13pPLG4KHy4VjAxIjuZErGJIKyfaQq gyysosZGfH+aMZ/6np1ZB9HgRIvAvhD0RfvyXOClSEIrgGfpe6y404yvN7comNs2eW9i EjexhdDN1TIH2DefcK4hqCTNWEGjwwbveD9+ILIVOjsdTEOe52pwQoxvTMxBieSpHLNf 6Qa/8m/IS8F27gHAX+DUdpRNkmEZwpMqeD44vwKmeRDqBZdBPM+qr7+ygOoCo/q9Opcw CFDeoit5ob/s5Br8wn30RDSqxn0eO1SGVSO6I5lKcxkYkS9RcfAG4VySk1NX2EzQbiiP wQUw== X-Forwarded-Encrypted: i=1; AJvYcCXZM9CENpZHFVgf3R6pEiuPwSPxX9n/n2qo+YV0ts3M1mYiONZ/UxJLg2eU0JQ6dBU03EKSMJexYB0=@lists.xenproject.org X-Gm-Message-State: AOJu0YxL+sE0wN+nUwzhe+mYdm+DCiStydURg5jq6HSzCNtxtGn9+YqJ IktUfYgJR29L5MgqTdwSh6OfJmLKOEDCLPykgUAXZpAEeDKBT0hdGRie6wbGaA== X-Gm-Gg: ASbGncu2zaiZSwxAdOTPipSMTHFXAzN4wJWsM1/bhGA4aV6i/BL71IIFGJBBgGmGBTV 47uY3nrwfNGJ1LiPq5J3HhMLJB+jpKsx457Cqr4b40fHPdHZgKi0n70HKJOUwCRSP33QbaSZ5sI OeGsc5hOJaCtd1o4YLOMwGvuXaK13JjBibdaN4aliccqwds4eihV/qT45ev8xOvarruZ2zyL3gn 3MdJcLlSqK+p3rYXhJGDl2NSEUQ65gXr5eiykcng74gorvCVihvTn5KqjFjmbtsPpr4GgJ1xp1A YXP1SvW+2jFpTrmv1kyipPTo5zk1trdzbIY= X-Google-Smtp-Source: AGHT+IH9mChw61TwLtghbLmdbx+LyTaSYUllE11L5hN30/kToRSrLAVtNL0tqbLwcZJ9baqnP84fCw== X-Received: by 2002:a05:600c:4592:b0:430:57e8:3c7e with SMTP id 5b1f17b1804b1-434ddee10b6mr78521775e9.28.1733732634952; Mon, 09 Dec 2024 00:23:54 -0800 (PST) Message-ID: Date: Mon, 9 Dec 2024 09:23:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] SYSCTL_numainfo.memsize: Switch spanned to present memory To: Bernhard Kaindl Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <10466e8c29b5f69774915bcf6562985c75e98bb7.1733224306.git.bernhard.kaindl@cloud.com> <0299582c-7261-4947-a2ac-bf3d62ccac14@suse.com> <3f527685-e1bf-4a87-8986-2b9620d14646@cloud.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: <3f527685-e1bf-4a87-8986-2b9620d14646@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.12.2024 11:55, Bernhard Kaindl wrote: > On 03/12/2024 12:37, Jan Beulich wrote: >> On 03.12.2024 12:12, Bernhard Kaindl wrote: >>> This the 2nd part of my submission to fix the NUMA node memsize >>> retured in xen_sysctl_meminfo[].memsize by the XEN_SYSCTL_numainfo >>> hypercall to not count MMIO memory holes etc but only memory pages. >>> >>> For this, we introduced NODE_DATA->node_present_pages as a prereq. >>> With the prereq merged in master, I send this 2nd part for review: >>> >>> This RFC is for changing the value of xen_sysctl_meminfo[]->memsize >>> from NODE_DATA->node_spanned_pages << PAGE_SHIFT >>> to NODE_DATA->node_present_pages << PAGE_SHIFT >>> for returing total present NUMA node memory instead of spanned range. >>> >>> Sample of struct xen_sysctl_meminfo[].* as presented by in xl info -n: >>> >>> xl info -n: >>> [...] >>> node: memsize memfree distances >>> 0: -> 67584 <- 60672 10,21 >>> 1: 65536 60958 21,10 >>> >>> The -> memsize <- marked here is the value that we'd like to fix: >>> The current value based node_spanned_pages is often 2TB too large. >>> >>> We're currently not using these often false memsize values in XenServer >>> according to my code review and and Andrew seemed to confirm this as well. >>> >>> I think that the same is likely true for other Xen toolstacks, but of course >>> to review this change or propose an alternaive is the purpose of this RFC. >>> >>> Thanks, >>> Bernhard >> >> All of the above reads like a cover letter. What's missing is a patch >> description, part of which would be to clarify whether the field is >> indeed unused except for display purposes, or why respective users would >> at least not regress from this change. What's also unclear is what >> comments you're actually after (i.e. what question(s) you want to have >> answered), seeing this is tagged RFC. > [...] >> Jan > > Hi Jan! > > The answer I'm looking for is which users to check, or to check with. > > For example, I know that Xapi can use xen_sysctl_meminfo[].memfree to > get a preference about the NUMA node use use when creating a domain > (when the new mode `numa_affinity_policy.best_effort` is enabled): > https://xapi-project.github.io/new-docs/toolstack/features/NUMA/ > > A potential use of xen_sysctl_meminfo.memsize in Xen toolstacks is > less clear to me: > > The only potential use would be if some Xen toolstack would not like > to solely rely on [nid].memfree for NUMA placement. > > The question is if there are other NUMA aware toolstacks besides Xapi, > that would try to use it for e.g. planning the placement of domains. > > My in the Xapi and Xen repos only turned up a debug printf() in > xen-api's xen-api/xenopsd and in xen only the output of xl info -n. > > It seems questionable to me that any other toolstacks would rely on it, > especially as the value it returns currently is offset even 2GB on some > machines. I'd expect that this bug would have affected code using it. > > The answers I am looking for are acknowledgements of that or references > which users might use .memsize currently (that could be affected). IOW all questions to respective toolstack people. > Alternatively, I'd hope to get an idea what would be the method to > create a new revision of the numainfo hypercall: > > I guess it would be to add a new #define XEN_SYSCTL_numainfo_v2, > and if v2 is called, return [].memsize using [nid].node_present_pages > instead? That's a last resort, yes. Since sysctls aren't stable (yet), changing existing interfaces generally is an option. We merely want to figure how careful we need to be. It may be fine to do the change "silently", as you do now. A middle option might be to rename the field which has its meaning changed, such that anyone using the field will notice that they need to update their code, hopefully resulting in them checking what changed and hence what they may need to change. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 08:47:25 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 08:47:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851047.1265195 (Exim 4.92) (envelope-from ) id 1tKZQF-0006Gm-Oe; Mon, 09 Dec 2024 08:47:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851047.1265195; Mon, 09 Dec 2024 08: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 1tKZQF-0006Gf-Lw; Mon, 09 Dec 2024 08:47:19 +0000 Received: by outflank-mailman (input) for mailman id 851047; Mon, 09 Dec 2024 08: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 1tKZQD-0006GZ-Vn for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 08:47:17 +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 30b959d7-b60a-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 09:47:15 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-382610c7116so2075205f8f.0 for ; Mon, 09 Dec 2024 00:47:15 -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 d9443c01a7336-2162685c495sm39729085ad.38.2024.12.09.00.47.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 00:47: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: 30b959d7-b60a-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733734035; x=1734338835; 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=dxNOweMxEd9puvkP05C8dvU33hQOHGm77Fh+Ny5DHms=; b=T6chaM5e+du8QFO3snoJo4i7K/gnUe2zBSY2hlRlWtpEaMfq/O0EaW+r5rWsuP+Dj/ uhgBhx9rfzmbUcqOAH8YN9EclniITflYjDn45l/q+9yfxeBL6obFNisspFjvDJeMhA/D /TUVxVXxEJX0cZfwp/khNyK+nKUgByOLh0um6pRT0dfGb3lhcNkv3aSLIJ59ynUHA9Wb DVwTF4oCJeXUkPQNpk89Vbc2OIAnstcCySgkUMqdz4bWl7CJbB0sCkbM+dUKU1iUYlpf uHQODtqZyw3Rojlco9K61kp5s/8ljVWgq95pRNRD4PCFH73d+YyAbpOho7rEj65bqUHP hwbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733734035; x=1734338835; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dxNOweMxEd9puvkP05C8dvU33hQOHGm77Fh+Ny5DHms=; b=QX3a31IXDnUzs+K7hQunVDB0mJj+mUgZ7O86sap7joBadq8HFLKK0EB3bSsm40eqxe qTdkod0ElLIlypkhAQBDqYK5Tpff1ejrTWs/EVpEBxChFkDiX6hXFFcqaGVU4V0ZXdW5 VvaKQdZ+VwEHrLvXpV45elMjy9CDQWhSb9oTuu6MD4mVgyZ1GCp9pggdcspAWw+Layl+ CrsRozGbFfzRgsyPWUlA6TXrFfJKm+RrNF00KFhLrV6QPQtVJ10Uk6CWAkNBeYhpNDbM pRsv6HQ+uzZkPJdfabaiCvaRczY4mHCuYDjcyRsc99mk66j70hqEcZNivxgi2Jaaihg1 b0nw== X-Gm-Message-State: AOJu0YynzxOSu7ILxxK4oCbJE514c3Mya1bJHRZWGGof5tcTX4VUDV9Y Hp0Aqb6VrxuvdzSUtzH65mRymIO/DF/cIv9/xWQEat/zqan04NHddcHejVaHRw== X-Gm-Gg: ASbGnctE3nn3MKqjkyoNulXeR9dE68wP4KxU7XZE2FkrTv+5MSG5duYAYfkrq6V6hXC LrHgRa5s9B3VaWzOgBlF6EUWpwWXYO8EXOUepHlU75pTiOxW8L2Mb8Uxoo+d6ES0KHMF9oTyHT0 C2G7ExkaOsdq2EcF6916xSKL1byZAwexzMDgYUGMJAP08joymxpySXcKtCEXW11bFytSqRHor76 dlHJDhNBnXSv52TsPMTr9fYl/SwCb5P2s5/ZB7qksHdVPOD8elcqpimkZwpCXM2SJlVP6h50oBm XjB3CG0XuALv5/hxXXOqZh2JzGvpGvdLcyo= X-Google-Smtp-Source: AGHT+IEj8zaRdeB8IWX8JeQhJYj23gywJIiDOsDhWmlK6gnyezHiGkgGkcf6udSrSZnPWoaUj5q7iA== X-Received: by 2002:a5d:5f52:0:b0:386:2fc8:ef86 with SMTP id ffacd0b85a97d-3862fc8f19amr5933871f8f.14.1733734035021; Mon, 09 Dec 2024 00:47:15 -0800 (PST) Message-ID: Date: Mon, 9 Dec 2024 09:47:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/4] Virtualize architectural LBRs To: Tu Dinh Cc: xen-devel@lists.xenproject.org, Andrew Cooper References: <20241118084914.22268-1-ngoc-tu.dinh@vates.tech> <7706bd63-8f26-4eb8-8dc0-67b302597e3b@suse.com> <3f75df1d-f397-487f-9b81-d7740712b924@vates.tech> <78d9df73-c9b7-479d-8e05-e4efb823ea20@citrix.com> <953fed09-385c-4489-ae50-b59ebd444114@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: <953fed09-385c-4489-ae50-b59ebd444114@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06.12.2024 15:16, Tu Dinh wrote: > On 18/11/2024 10:52, Andrew Cooper wrote: >> On 18/11/2024 9:13 am, Tu Dinh wrote: >>> On 18/11/2024 09:52, Jan Beulich wrote: >>>> Looking over just the files touched: No change to XSAVE logic at all? >>> XSAVE is hidden behind a new IA32_XSS bit. I'll try to implement that next. >> >> It's rather more severe than that. >> >> Without XSAVE support, Xen can't context-switch the LBR state when vCPUs >> are scheduled in and out.  (In patch 4 you seem to have copied the >> legacy way, which is extremely expensive.) >> >> Architecturally, ARCH_LBR depends on XSAVES so OSes can context switch >> it easily(ish) per thread. >> >> There's also a reason why we haven't got this working yet.  There are a >> couple of areas of prerequisite work which need addressing before XSS >> can be enabled properly. >> >> If you're willing to tackle this, then I can explain what needs doing, >> and in roughly which order. > > Following the community call yesterday, I'd like to clarify my > understanding of the issue: > > - Firstly, virtual XSS support for architectural LBR must be enabled. I > noticed that XSS is already implemented, just not enabled; barring the > LBR format issues below, are there any other issues with the current XSS > implementation? At the very least, as with any code that exists be is effectively unused (and iiuc even DCE-ed by the compiler in at least some of the cases) it'll need to be determined whether what we have actually works. It seems more likely than not that some corrections here and there may be needed. > - There are LBR format differences between some cores of the same CPU > (e.g. in Intel hybrid CPUs: P-cores use effective IP while E-cores use > linear IP). These differences are expected to be handled by > XSAVES/XRSTORS. However, Xen would have to make sure that LBR MSRs are > saved/restored by XSS instead of by manually poking MSRs. How could XSAVES/XRSTORS take care of format differences? Something that was saved on one type of core and is to be restored on the other type of core would require CS.base at the time the LBR was originally written to be able to convert effective <=> linear IP. > - A related issue is handling the compressed XSAVE format for migration > streams. Xen currently expands/compacts XSAVE format manually during > migration; are there any concerns with arch LBR breaking the XSAVE > migration logic? That ought to be fine, I think, barring the first point I made above. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 08:55:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 08:55:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851057.1265205 (Exim 4.92) (envelope-from ) id 1tKZYD-0007vV-Ii; Mon, 09 Dec 2024 08:55:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851057.1265205; Mon, 09 Dec 2024 08:55: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 1tKZYD-0007vO-Fd; Mon, 09 Dec 2024 08:55:33 +0000 Received: by outflank-mailman (input) for mailman id 851057; Mon, 09 Dec 2024 08:55: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 1tKZYB-0007vI-IB for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 08:55:31 +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 56a1c995-b60b-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 09:55:28 +0100 (CET) Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-385e87b25f0so2969257f8f.0 for ; Mon, 09 Dec 2024 00:55: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 98e67ed59e1d1-2ef4600d14fsm7440557a91.45.2024.12.09.00.55.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 00:55: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: 56a1c995-b60b-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733734528; x=1734339328; 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=gKu8jIF81IdEzzup9N3m72LnSHXp6igxpM34Tbn8zvE=; b=cD9xCPkl8IiFf+XCuBzSz1mHik6MWn4Xb5//GHBKPJhabEEFIB9RP++7QhjlEfGt68 Db34n0HHxGPPahcuzAn+9kd7fVwN22G79/aWlWr0A6LuLq/OkYD7nmwBzYbaMLUy9TfP s2pUNGwD4uTTcp9JiCVlS847LoYebvmexlNk6G2kMal9bOe6cOSc6WLn2gIYvAtJZPV2 1l9GVbPpDl9vRmx53UWJVxCN8T0hdP/OQxCvDyquZXhJQonXJ8ILDumGQ1vpoX8Y4PT2 MxvElLPA3LMO814SiRjTAizNBXtjbrH7HCO/WCQummdoFR4vUoB+U6bmRvMhhoYV45q6 tNnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733734528; x=1734339328; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gKu8jIF81IdEzzup9N3m72LnSHXp6igxpM34Tbn8zvE=; b=lOKHkVgZmBf/yVOlwRj2QltNETDT21G3bzGQNDolBa/ZYL3MIuXzo1mdM9TAskh/Av zJ7peey3GYv4AjwnH1VjRBH5T2IUyzbMZBV2UL85gEvcGKRlQZlfCXyK/oGO5HJihNrJ JzX0RcLCpbN7ykfv9RTNt6fPup7eyh9v16XzmUZLQ0FJ4aUu6aL3YapwyKN42POUlGQX CrhUerQKbp46hDRzXiUbBnoDfqkXoJz9KWFA7Bc7RTAkMUR3tI3uSDYdKmn3KKLuqCma 3WWj2qn6pMpW0Ic2Ll3hAJbWTydSDENRS2ys+OdAPWhfJAt/XK5i+kV8QAs/2IS5uYBF jUJg== X-Forwarded-Encrypted: i=1; AJvYcCWm1/ipLF6ad+AAhUwpD2VtbR9QQ/9WIQiew5cIjBqjUPPj4+eaSEbkI2v/OOwGnUy4lseTmvM3unY=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx6Dza45w+jDE4+a/36gYDSR91u4clPggKNkKzrmvO3AMkx7zLN 6aK/Om1L21k5p7JrgAYdY8CTk1M7tmQdBbFCehM4gRNswoJScu2yIIptNxZV3w== X-Gm-Gg: ASbGncssvpaEX3rx94kEplNRXEQYthsIX/4TcDOYgpRJzV6rKeGwMm2UPlrLgciv6X4 yEQZORQAX9iGyX0f5eS2ConaHsBYqLtmYsOeQ6ALJH49Z2TPXeXRAMWyHWfU92kRnSqlkLZB5iS 4j7L+8plpq+vB9i6ry/EZ/HLVqRWXN6lU2VGihBBYk6EEsYjuK3jEYxhIBqJZYZdupPqr5LfFYV tDlsx3+aJuAiyxYDAgaqSIZQwq4S0uFhlxiwRr4TLzMahTnnmKUz++2EpZfmlzae5iHyzWPXd3V mlTJoBeBzaNeEmRLAzd3lkNjMLNUxcVx4J8= X-Google-Smtp-Source: AGHT+IHjR4jLu5DeaQ/1dilEB8XCModuXFf5dD4Hb05m/I/JOwjPmLMd5m+IjWuYrDArvOVbjvKqAQ== X-Received: by 2002:a05:6000:1864:b0:386:42b1:d7e4 with SMTP id ffacd0b85a97d-38642b1dab8mr866272f8f.19.1733734528233; Mon, 09 Dec 2024 00:55:28 -0800 (PST) Message-ID: <7f40d7ba-26ec-4301-abbc-aef5d1ade44c@suse.com> Date: Mon, 9 Dec 2024 09:55:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 5/6] x86/boot: introduce domid field to struct boot_domain To: "Daniel P. Smith" Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com, stefano.stabellini@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241115131204.32135-1-dpsmith@apertussolutions.com> <20241115131204.32135-6-dpsmith@apertussolutions.com> <83e3b0a9-e0e6-4d36-a3ce-4687b1886733@apertussolutions.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: <83e3b0a9-e0e6-4d36-a3ce-4687b1886733@apertussolutions.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.12.2024 17:45, Daniel P. Smith wrote: > On 11/27/24 05:32, Jan Beulich wrote: >> On 15.11.2024 14:12, Daniel P. Smith wrote: >>> init_dom0_cpuid_policy(d); >>> >>> if ( alloc_dom0_vcpu0(d) == NULL ) >>> - panic("Error creating d%uv0\n", domid); >>> + panic("Error creating d%uv0\n", bd->domid); >> >> Imo this would better use d->domain_id. And while touching it, %u would also >> want swapping for %d. > > hmm, I was actually considering s/d%u/%pd/ and just pass in d, but was > certain if there was an explicit reason it wasn't used before. If I am > going to change it, would %pd not be more desired here? When writing my original reply, I certainly considered this. The anomaly here is that you really mean to log a vCPU ID, which would require a struct vcpu * and use of %pv. Yet you don't have that here, precisely because the creation of the vCPU failed. That said, since vsprintf.c:print_vcpu() calls print_domain(), using %pd is certainly an option here (inconsistencies would arise if %pv and %pd presented domain IDs in [perhaps just slightly] different ways). Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 09:29:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 09:29:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851069.1265215 (Exim 4.92) (envelope-from ) id 1tKa54-0003hn-Sp; Mon, 09 Dec 2024 09:29:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851069.1265215; Mon, 09 Dec 2024 09: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 1tKa54-0003hg-QE; Mon, 09 Dec 2024 09:29:30 +0000 Received: by outflank-mailman (input) for mailman id 851069; Mon, 09 Dec 2024 09:29:29 +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 1tKa53-0003ha-1y for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 09:29:29 +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 1553d3a0-b610-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 10:29:26 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-385f06d0c8eso1886834f8f.0 for ; Mon, 09 Dec 2024 01:29: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 d9443c01a7336-2163562a838sm28491695ad.29.2024.12.09.01.29.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 01:29: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: 1553d3a0-b610-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733736566; x=1734341366; 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=iPW8IzMDXmotM73Xdn5AcC7VYXAkv0XlM1agX6PnN2Y=; b=KS8M6Fs/Sd3ZCl3KDDZEgTGEHnWCLa0ey60BWEH1YxGBTMUYC+6X06PIfL228hpGVa yEhwI4aUu+f16XMU7QkgClJB2w9uXdFNrWinF27gkTFXuudlUVa3P3KsJZwzEeBiyXNv RXPH3P7O4+99TPd8QR3MTNgoED+DOTqIZp/fLG1o+mxOdZVh40jLx8dxvBuCY4BXLgIW vc/TQOyQ29eM6j9wDTpEkOswEVMO5vphEB2dBtq0OFPmyukGHrGiBDW0R5mtvU3HNtIu sZvLbiP4iS2n4EnKFXfNZSEM1DKTvjhFGNujY9nSXYdfkjLq9FZFcauWqdDzk6qTJydW 2siQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733736566; x=1734341366; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=iPW8IzMDXmotM73Xdn5AcC7VYXAkv0XlM1agX6PnN2Y=; b=pLSsPDgZbnIYy9Bw3hYoMgqTqWHCxIXfxH7elgdED1hWHlU4q2gzSP3/SRtp6e7yp+ FlzXBxwNjrblLhd23jGSqj/Mx7tiqOcSiMY0XrFNrjuDEZfwvoxXkfr6krKkdL646ePE zLqr7IBJzaDNECbzkOkG5bqDxyVeMi8yeqgqQjPI2XWgDh5VoRnkfXjklCCZl9l7uhn5 8+oIrwqKE/iCST2WbKRCkC+lERvqbLVAmhq5vrDZcp+jQK5khMykfIrzMMi+e6hlbfVb aKI8XSEZx/HEY04hwXf0GRhEk3n0KDN+jzel/LCLVqY8y3//Ak4pQwGRwAM2y2s50S/A ksuA== X-Forwarded-Encrypted: i=1; AJvYcCVbfo9TUtqSYnTc16ch2uS4+QHarlPQKRuKOl+fmIVoB2oEXGMofooQRk270eKyT99BZeEFwAf+Oo8=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx3RdkEZ7dRFwySj3q3t6LZ7DIcmjjuF7g5Dg5s4xDBpcjjo3ur zIjfyVCyrsBtTNeLWm/qzhGAJXy681VPi/IQ1rwtRV0zi68iXTHlrZSez29oFQ== X-Gm-Gg: ASbGncu0LRZmuCXzn5/9b/RLus4ANbizdsLyXNmMZq9R6eiFYT9BCcLYn4h2Uf+reFj X2nnrc1F2BjXkJV9yNqgEmuEdkiw8cR1/G4aEeyvkdE2gbfysw8lgBxJkoHOTKBxLgiJjCZJefC krZ9jwwealPuIfeLN3J5xNU9OiQGYJr0kFSMsnJofRBFdJlwUwID0dq1d1pgYBgMUPPo+e6EzyK NjnhgYGT5g2NbZuTCB5hDH5iiNNn5dOkoQgZj2H8+BF+ziymWXl/axH9+7qAsaKl7wuzAjbkigc /8zqekNbhNZXBsthlkMS0QaG4/4k8Qf4388= X-Google-Smtp-Source: AGHT+IGN1mwOqXh7eJQtzyMjrXFDdGBkazNq8iseUVBzK2AGXlTscPbwH3yIhWFxDjMMY9Wn0H99ug== X-Received: by 2002:a5d:64e8:0:b0:385:e5d6:130c with SMTP id ffacd0b85a97d-3862b3e82a8mr7482729f8f.51.1733736566076; Mon, 09 Dec 2024 01:29:26 -0800 (PST) Message-ID: <638e4fe3-c346-4c03-a3db-2027986753a8@suse.com> Date: Mon, 9 Dec 2024 10:29:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] CHANGELOG: Mention xl suspend/resume To: Jason Andryuk Cc: Oleksii Kurochko , Community Manager , xen-devel@lists.xenproject.org References: <20241205195026.3523-1-jason.andryuk@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: <20241205195026.3523-1-jason.andryuk@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.12.2024 20:50, Jason Andryuk wrote: > Signed-off-by: Jason Andryuk > --- > It only works for x86, but it isn't x86-specific. I chose to add it as > a generic entry instead of listing it as x86. Which probably is fine, yet then ... > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -16,6 +16,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) > ### Added > - On Arm: > - Experimental support for Armv8-R. > + - xl suspend/resume subcommands. ... you'd want to name the limitation to x86 here anyway, I think. Unless there are firm plans to remove the limitation by 4.20 going out. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 09:36:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 09:36:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851078.1265225 (Exim 4.92) (envelope-from ) id 1tKaBT-0005O6-HT; Mon, 09 Dec 2024 09:36:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851078.1265225; Mon, 09 Dec 2024 09:36: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 1tKaBT-0005Nz-Ea; Mon, 09 Dec 2024 09:36:07 +0000 Received: by outflank-mailman (input) for mailman id 851078; Mon, 09 Dec 2024 09:36: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 1tKaBS-0005Nt-Rl for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 09:36: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 01d3752b-b611-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 10:36:06 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-38637614567so753587f8f.3 for ; Mon, 09 Dec 2024 01:36: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 d2e1a72fcca58-725a29caa6dsm7124171b3a.5.2024.12.09.01.35.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 01:36: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: 01d3752b-b611-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733736963; x=1734341763; 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=4MyR++MqGUbw3sOgY+sB0OXVcgZQHdxm3Y8npC31QRA=; b=BAylYyU+L84biSYWI4WxkZ/awMgGG5Mrgs7KIIAFoy01yUskTTRQq6Tk1XHEf65HxF gUZ+g34JIoAXnTGwPFRm8pxgX7cVIRtx6/lcdSOoK99e4IkLtbAnFBlFoiLg8d3ISf+6 3eus5aoUrx2UJQzLZuksDcjHW8D9S/zl4+dfI+59FRFU1LCyXTYnM5BexLS2PMEcG3dK mk7w/56dM0U+Pwx+/orNiihhjqStWtbQ65IMG3PpYJoM1OaLl6g1ie8cERyp6MmRUCHs Y9pl4WO96/f7KK9cJHIJYqdZGMyDRs1kigWlXsCFK0Bej2Jhk8znAd3Y4noyPEZJ8U3r plQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733736963; x=1734341763; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4MyR++MqGUbw3sOgY+sB0OXVcgZQHdxm3Y8npC31QRA=; b=ouLQC6dgBaHpH+t1aF52NvvFKah1955FZHg/JllVtLvSXrhGqU2higfNv4BiW56p2s UTISy+GrWqlciandouDvTlNX8EKFWvB0HKz1d3K+pBer+Fr0l1ZwruloGv2hQgK8VoF0 +dsEpQwL3n5g07D4IUNTAx1TEQiDF760My6/+PdqB34UlixuK2XYGMDLggoJyXobMyL7 +eehWabZ/UWkIiQvbSVf5hrQwyXdBnI1RgdCVMJFhyKj8ntWPz5AkzNaW2cs4pkcmLzk Q33j5G5ULccnzQLydFPOgG+b2d1I50eGt+xKntlqPvStLwBucC8fJLE9HhVoYtpJMzY3 nMFA== X-Forwarded-Encrypted: i=1; AJvYcCU35oiVR2coPkIpuxgoBT96vHCmqeN/p+z03fKCyvWspBVCqi4XQCpl/2Qo/YIBeKtQH7DcXk58jZw=@lists.xenproject.org X-Gm-Message-State: AOJu0YyKzIT2XsdbW5gcYW9S0jpX66FYfbskF0yKxrVai9dWyW1po6Qc p3msWaVeQ/NunRYF8xRE6weVyodDaAcAb4TPfIv3I5LHhxRLJWyjCcxUpT5Pnw== X-Gm-Gg: ASbGncszX+9c6cpqAkqnotm6zaLkd5hmR5Pm2hI0ywNHVdUxtVfXFezMsUfVNK24i83 YlvlsoemOEBUw7sCfwNAS50AAZO6crctk7WdUw6Z5056fwMNUpXwAz46WPVQ1Lzu1pmqsrq2xvQ 6xwro7/Ncm7gULVK5zwSSgvTQ9KH49eEatp0p1TAilq25JdH6+ouLihPMRfnd7X/Nq+FUFrnb5d dhGFqBfDdCu1vqQeHJcwQjydDWeCQsMwQwbfafxmclNs5Jzhuz/lklYZXshP1W7Q4K9OelErDB3 btOLiAVmDSwZSgnKQFWzILe5gxjo5POUF0s= X-Google-Smtp-Source: AGHT+IEtwqmgtUf7i9PFreWCQfnT5GS+R735A68IzyvL4zsrYMnF4xpgcr3GrZff9M7HvivjUeYclg== X-Received: by 2002:a5d:59a9:0:b0:382:6f3:a20f with SMTP id ffacd0b85a97d-3862b33f3dbmr8817750f8f.11.1733736962866; Mon, 09 Dec 2024 01:36:02 -0800 (PST) Message-ID: <0de3796a-b2b4-4661-b6d7-eee32be66014@suse.com> Date: Mon, 9 Dec 2024 10:36:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/4] xen: arm: enable stack protector feature To: Volodymyr Babchuk Cc: Julien Grall , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Andrew Cooper References: <20241130010954.36057-1-volodymyr_babchuk@epam.com> <20241130010954.36057-4-volodymyr_babchuk@epam.com> <79bb69b0-b00d-4e3c-966e-a341eac59499@citrix.com> <87a5d94dwk.fsf@epam.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: <87a5d94dwk.fsf@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06.12.2024 05:46, Volodymyr Babchuk wrote: > So, apart from already present > > static always_inline void boot_stack_chk_guard_setup(void); > > I did this: > > /* > * Initial value is chosen by fair dice roll. > * It will be updated during boot process. > */ > #if BITS_PER_LONG == 32 > unsigned long __ro_after_init __stack_chk_guard = 0xdd2cc927; At least this and ... > #else > unsigned long __ro_after_init __stack_chk_guard = 0x2d853605a4d9a09c; > #endif > > /* This function should be called from ASM only */ > void __init asmlinkage boot_stack_chk_guard_setup_early(void) > { > /* > * Linear congruent generator. Constant is taken from > * Tables Of Linear Congruential Generators > * Of Different Sizes And Good Lattice Structure by Pierre L’Ecuyer > */ > #if BITS_PER_LONG == 32 > const unsigned long a = 2891336453; ... this will need a UL suffix for Misra. Probably best to add UL on all four constants. As to the comment, please adhere to ./CODING_STYLE. > #else > const unsigned long a = 2862933555777941757; > #endif > const unsigned c = 1; I'm having a hard time seeing why this need to be a static variable. Its sole use is ... > unsigned long cycles = get_cycles(); > > if ( !cycles ) > return; > > __stack_chk_guard = cycles * a + c; ... here, where you can as well write a literal 1. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 09:47:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 09:47:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851094.1265235 (Exim 4.92) (envelope-from ) id 1tKaMT-0007E7-GA; Mon, 09 Dec 2024 09:47:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851094.1265235; Mon, 09 Dec 2024 09:47:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKaMT-0007E0-DT; Mon, 09 Dec 2024 09:47:29 +0000 Received: by outflank-mailman (input) for mailman id 851094; Mon, 09 Dec 2024 09:47: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 1tKaMS-0007Du-B7 for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 09:47:28 +0000 Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [2607:f8b0:4864:20::d33]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 988ffeb2-b612-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 10:47:26 +0100 (CET) Received: by mail-io1-xd33.google.com with SMTP id ca18e2360f4ac-84194e90c0fso298553039f.2 for ; Mon, 09 Dec 2024 01:47: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: 988ffeb2-b612-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1733737645; x=1734342445; 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=hNoixS+bSdns49ylC5jh5vsCyN5SjdzAMt56FHivZkk=; b=LRuGOXAixIhn9aqMGCeopTwdosFoYxn1S1QYkbu0Q3NbPlX4Lvbi9t04yLYTjZQEXC ClDY73XVaNsu9ZTiZZjC7YYzZQYUVsDtLNnvZGrsDW6uT0WaV95GxO9i8BoYcJlpPr20 EF7essspU8S2Qjs8uSa+d9NoupRHMhLNnOHxfwB1Gz8TiX9n3AJZr0VYhTWlrx4Ah3xo nIccnff3eE8hvPCvf1G5PYOcgkzQKpagNNPLF7HDbG3/DJvzxGUFsBZDG78vpm/vM+VX ZedbKEGlfekrfUndAPrI2CkGEfsb6Ax6BBwtpq92wG0FC7kpMpHDiznZsdmaEqZZlyXX xEGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733737645; x=1734342445; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hNoixS+bSdns49ylC5jh5vsCyN5SjdzAMt56FHivZkk=; b=B0Csma5VAu04C5mjNixuBJpU9wFD4LVC8C2uky7sCylT/e8rWAZCKMJ/OUgX1fBWLW KhyEtw4XuwuQaP/cFzargmALozlnw052NaSwUzoKQFFaGDwjM4/kwtl3IxVLDR2LUYlU sV/3cPfaTG3Xd1CPbOkJujlT9OAKK5N4kgwD176GroRclLOblrMOdABzWzwVP21jYgu+ NqApnRJ7ZVHK+hNWl899q80j9HbHFQSAjo0jgPuwrA5NDCoXuFUG5NpAgUcI1wac6d/M I99LPKMu4WlLX68VGS5qdyfr5pOtsGQvNLRGiUHiUmOT93cv7Q6V4eDZRczLu4fmX57D BzOw== X-Forwarded-Encrypted: i=1; AJvYcCXXHk5MXUg0DLim71ZJ0a4HtRMYOfuOC40hLffoJzHd95bQFcQhKzurw2jtgX5DvQsh3KeE5b+cniA=@lists.xenproject.org X-Gm-Message-State: AOJu0YznWi0wl3DBIPbdB11zyPyHFqJxj+LBOxyUAf2+rmKpeIzQSUgl Yf7gUBjubr1HDW8YdA/F1vVUyn3strXNmjKelG8W97I98ZjMeHknyOz/4uqvaevQRZRISOcnX77 OScGgKndxxwPu4SLI3+5wxOmNp6VEid9ewBP9Qw== X-Gm-Gg: ASbGncvxkwm2xLC0DPktxp1NUWKsWjsQLPUixSYDny4O/1mRh2OYSjiFDNgwgmxS3Cv zUw/orQc8w8jgoK085tVItElr6NB+pXP3fgjOAylB0f1iD3gZFuLdp/NDCn68esIS X-Google-Smtp-Source: AGHT+IEQMTymVgc2tzxE7kABtIENjkqkgMzj9GUXFf4K0HOZzp69B6BUNJbTBDiWxjIo4cbUjRZnANHoxSvO35knlho= X-Received: by 2002:a05:6e02:214a:b0:3a3:4175:79da with SMTP id e9e14a558f8ab-3a811dbaedamr95125945ab.13.1733737645134; Mon, 09 Dec 2024 01:47:25 -0800 (PST) MIME-Version: 1.0 References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> <20241202165921.249585-4-carlo.nonato@minervasys.tech> <7ecc99c5-0cb5-4351-bede-cb03c9a4ac7e@xen.org> <293004fa-c87e-4a45-aa4c-b02456aaecea@amd.com> In-Reply-To: <293004fa-c87e-4a45-aa4c-b02456aaecea@amd.com> From: Carlo Nonato Date: Mon, 9 Dec 2024 10:47:14 +0100 Message-ID: Subject: Re: [PATCH v11 03/12] xen/arm: permit non direct-mapped Dom0 construction To: Michal Orzel Cc: Julien Grall , xen-devel@lists.xenproject.org, andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Michal, Julien On Sat, Dec 7, 2024 at 4:05=E2=80=AFPM Michal Orzel = wrote: > > On 06/12/2024 19:37, Julien Grall wrote: > > > > > > Hi, > > > > Sorry for the late answer. > > > > On 05/12/2024 09:40, Michal Orzel wrote: > >> > >> > >> On 02/12/2024 17:59, Carlo Nonato wrote: > >>> > >>> > >>> Cache coloring requires Dom0 not to be direct-mapped because of its n= on > >>> contiguous mapping nature, so allocate_memory() is needed in this cas= e. > >>> 8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a separate = module") > >>> moved allocate_memory() in dom0less_build.c. In order to use it > >>> in Dom0 construction bring it back to domain_build.c and declare it i= n > >>> domain_build.h. > >>> > >>> Take the opportunity to adapt the implementation of allocate_memory()= so > >>> that it uses the host layout when called on the hwdom, via > >>> find_unallocated_memory(). > >>> > >>> Signed-off-by: Carlo Nonato > >>> --- > >>> v11: > >>> - GUEST_RAM_BANKS instead of hardcoding the number of banks in alloca= te_memory() > >>> - hwdom_ext_regions -> hwdom_free_mem in allocate_memory() > >>> - added a comment in allocate_memory() when skipping small banks > >>> v10: > >>> - fixed a compilation bug that happened when dom0less support was dis= abled > >>> v9: > >>> - no changes > >>> v8: > >>> - patch adapted to new changes to allocate_memory() > >>> v7: > >>> - allocate_memory() now uses the host layout when called on the hwdom > >>> v6: > >>> - new patch > >>> --- > >>> xen/arch/arm/dom0less-build.c | 44 ----------- > >>> xen/arch/arm/domain_build.c | 97 ++++++++++++++++++++++= ++- > >>> xen/arch/arm/include/asm/domain_build.h | 1 + > >>> 3 files changed, 94 insertions(+), 48 deletions(-) > >>> > >>> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-bu= ild.c > >>> index d93a85434e..67b1503647 100644 > >>> --- a/xen/arch/arm/dom0less-build.c > >>> +++ b/xen/arch/arm/dom0less-build.c > >>> @@ -49,50 +49,6 @@ bool __init is_dom0less_mode(void) > >>> return ( !dom0found && domUfound ); > >>> } > >>> > >>> -static void __init allocate_memory(struct domain *d, struct kernel_i= nfo *kinfo) > >>> -{ > >>> - struct membanks *mem =3D kernel_info_get_mem(kinfo); > >>> - unsigned int i; > >>> - paddr_t bank_size; > >>> - > >>> - printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:= \n", > >>> - /* Don't want format this as PRIpaddr (16 digit hex) */ > >>> - (unsigned long)(kinfo->unassigned_mem >> 20), d); > >>> - > >>> - mem->nr_banks =3D 0; > >>> - bank_size =3D MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem); > >>> - if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM0_BASE), > >>> - bank_size) ) > >>> - goto fail; > >>> - > >>> - bank_size =3D MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem); > >>> - if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM1_BASE), > >>> - bank_size) ) > >>> - goto fail; > >>> - > >>> - if ( kinfo->unassigned_mem ) > >>> - goto fail; > >>> - > >>> - for( i =3D 0; i < mem->nr_banks; i++ ) > >>> - { > >>> - printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (= %ldMB)\n", > >>> - d, > >>> - i, > >>> - mem->bank[i].start, > >>> - mem->bank[i].start + mem->bank[i].size, > >>> - /* Don't want format this as PRIpaddr (16 digit hex) = */ > >>> - (unsigned long)(mem->bank[i].size >> 20)); > >>> - } > >>> - > >>> - return; > >>> - > >>> -fail: > >>> - panic("Failed to allocate requested domain memory." > >>> - /* Don't want format this as PRIpaddr (16 digit hex) */ > >>> - " %ldKB unallocated. Fix the VMs configurations.\n", > >>> - (unsigned long)kinfo->unassigned_mem >> 10); > >>> -} > >>> - > >>> #ifdef CONFIG_VGICV2 > >>> static int __init make_gicv2_domU_node(struct kernel_info *kinfo) > >>> { > >>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.= c > >>> index 2c30792de8..2b8cba9b2f 100644 > >>> --- a/xen/arch/arm/domain_build.c > >>> +++ b/xen/arch/arm/domain_build.c > >>> @@ -416,7 +416,6 @@ static void __init allocate_memory_11(struct doma= in *d, > >>> } > >>> } > >>> > >>> -#ifdef CONFIG_DOM0LESS_BOOT > >>> bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_s= ize, > >>> alloc_domheap_mem_cb cb, void *= extra) > >>> { > >>> @@ -508,7 +507,6 @@ bool __init allocate_bank_memory(struct kernel_in= fo *kinfo, gfn_t sgfn, > >>> > >>> return true; > >>> } > >>> -#endif > >>> > >>> /* > >>> * When PCI passthrough is available we want to keep the > >>> @@ -1003,6 +1001,94 @@ out: > >>> return res; > >>> } > >>> > >>> +void __init allocate_memory(struct domain *d, struct kernel_info *ki= nfo) > >>> +{ > >>> + struct membanks *mem =3D kernel_info_get_mem(kinfo); > >>> + unsigned int i, nr_banks =3D GUEST_RAM_BANKS; > >>> + paddr_t bank_start, bank_size; > >> Limit the scope > >> > >>> + struct membanks *hwdom_free_mem =3D NULL; > >>> + const uint64_t bankbase[] =3D GUEST_RAM_BANK_BASES; > >>> + const uint64_t banksize[] =3D GUEST_RAM_BANK_SIZES; > >> Limit the scope > >> > >>> + > >>> + printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:= \n", > >>> + /* Don't want format this as PRIpaddr (16 digit hex) */ > >>> + (unsigned long)(kinfo->unassigned_mem >> 20), d); > >>> + > >>> + mem->nr_banks =3D 0; > >>> + /* > >>> + * Use host memory layout for hwdom. Only case for this is when = LLC coloring > >>> + * is enabled. > >>> + */ > >>> + if ( is_hardware_domain(d) ) > >>> + { > >>> + ASSERT(llc_coloring_enabled); > >> This patch does not build because of declaration not being visible. Yo= u must include . > > > > Piggying back on this comment. AFAICT, the code below would work also i= n > > the non cache coloring case. So what's the assert is for? > > > >> > >>> + > >>> + hwdom_free_mem =3D xzalloc_flex_struct(struct membanks, bank= , > >>> + NR_MEM_BANKS); > >>> + if ( !hwdom_free_mem ) > >>> + goto fail; > >>> + > >>> + hwdom_free_mem->max_banks =3D NR_MEM_BANKS; > >>> + > >>> + if ( find_unallocated_memory(kinfo, hwdom_free_mem) ) > >> My remarks for the use of find_unallocated_memory() 1:1 have not been = addressed. You did not even > >> change the comments inside the function. The problem is that the funct= ion is specifically designed > >> for finding extended regions and assumes being called at certain point= i.e. dom0 RAM allocated, gnttab > >> region allocated, etc. Answering Michal. Sorry about it, since we were waiting for comments and I wanted to keep the revision alive (it happend too many times that we (minervasys) left the discussion hanging for too long) I sent the v11 even if it was incomplete. I should have at least added commens, you're right. > > So I agree that the function should be updated if we plan to use it for > > other purpose. > > > > My opinion is that we should attempt to make the function generic so > > that in your > >> case you can choose which regions to exclude, define even your own fun= ction to grab free regions (at the moment > >> add_ext_regions grabs banks >=3D 64M but you still discards banks >=3D= 128M, so it's a bit wasteful. > >> > >> My very short attempt to make the function as generic as possible in t= he first iteration: > >> https://paste.debian.net/1338334/ > > > > This looks better, but I wonder why we need still need to exclude the > > static regions? Wouldn't it be sufficient to exclude just reserved regi= ons? > Static shared memory banks are not part of reserved memory (i.e. bootinfo= .reserved_mem) if that's what you're asking. > They are stored in bootinfo.shmem, hence we need to take them into accoun= t when searching for unused address space. > > If you and Carlo are ok with my proposed solution for making the function= generic, I can send a patch as a prerequisite > patch for Carlo series. I'm ok with that. > ~Michal Thanks both. - Carlo From xen-devel-bounces@lists.xenproject.org Mon Dec 09 10:05:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 10:05:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851105.1265245 (Exim 4.92) (envelope-from ) id 1tKadU-0001rP-RH; Mon, 09 Dec 2024 10:05:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851105.1265245; Mon, 09 Dec 2024 10:05: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 1tKadU-0001rI-Ok; Mon, 09 Dec 2024 10:05:04 +0000 Received: by outflank-mailman (input) for mailman id 851105; Mon, 09 Dec 2024 10:05: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 1tKadU-0001rC-4a for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 10:05:04 +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 0dea6862-b615-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 11:05:01 +0100 (CET) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-385dece873cso1882612f8f.0 for ; Mon, 09 Dec 2024 02:05:02 -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 98e67ed59e1d1-2ef2708b93dsm9497925a91.51.2024.12.09.02.04.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 02: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: 0dea6862-b615-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733738701; x=1734343501; 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=m7IgHTFnElHj8LHSL2zttzGa0TlfPS3g9WeiUH2crnw=; b=IVVbTrbp1HwhrqGg6YKxg3StJwlA/GjkJTBRwwNz1iCsdXjfGvz7Hbg9vv2G1BTkc8 KfVhJI2QwRmlc7LGP7ycShGeWiti27dsPDTsRL2FbbLz/nBGTAebGvJDKWXH/nSgpxgP NfWSbwJdNsqfNwj1pZh5pv562O3r/+bGoS7IsCr6n0LBflDlZPacwMpBpyPjxiUpBLtV o1YlPh+IlZL+nYYde/X21+N+Zy9LNiODaAY/RK8EcDLGN64CIy1EofaPRDdgAGj4jA90 r3XkQYaN+ZMpZQP9+sh1jZaneMmzYFYRgENHFEr3ZXg2doMa3qhMAeCNv4QjfcA1a6vh f0Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733738701; x=1734343501; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=m7IgHTFnElHj8LHSL2zttzGa0TlfPS3g9WeiUH2crnw=; b=emWO1FkvUoi1G2IHEup7HKBToz4Y8CFjkQ4qyboXHddDYkOk3Tyd4BM8wyDWIfEYaP AS3d9lzvE77B/4iwC+ufi+JNEUr+cjrDHZ9oZDDyen81yq8Wbk3pA9WH7LSQZVCBD0pH d5C0+iJp6XbCnFu1pawIbVJgd/pOgeBSUmMAeW4KGTTUX7slsf4OmKHF3dQNRi9xl57V h+5Y/VPu3AQZmqPavTwUOD0HNtZWCnE5DEUAEcUVUoYs98Jd228hl0PasULNNo6MWJSV fQAR2yWtFlmL0cWl1W2AvnoYgBvSR+8ZuoYtmC1SJdhRFzalBouCRifXM+4HqV0gtswX 8myw== X-Forwarded-Encrypted: i=1; AJvYcCV+xCXkI2n+viMcfFHDqNzVmgWFI19BNOygZnNszQUwd9mclvl8ezBKoXTsJ96Ni9NwpHPWUR32I4w=@lists.xenproject.org X-Gm-Message-State: AOJu0YyHCHKjaYharyJKePO0kdVC6xJLquboKJ3w1vkg9LaPLzQw4c4U EqHTLRNKk+2j/Xo1DTbOoi5+hEWSuitmz2dcyrMg/96c3Xzfwt4Tu8bxYVihMg== X-Gm-Gg: ASbGncux7DuejZ+BNJRc0HkhyHbQ5PUc3pjISUE+rpKHvtSpCmspdKBkRKvvR1wjnfa l4XxH3TjeRk45d7pCJjjiOOQOql8kwEvhDZzvkj0qjmXe1iCA1PtsalHuwxG2QsoJMiZJB3KT69 ZOmwDqI6W70qhbBt7Zxyc0T/MN2vFD7MAxlCheErVPTF7dbjjXAMIiycn2JaXdV8PoFdGKzL15J RccTjbtlKEdr1dm93S7LO4NExv/g2VBaCXQd7+1fWAvrM5O0RXc5/VO1XVO8Cg8QX43/+YoBJul sjEOYy86ABUW9jrRN4mbhR27QecKoLtlnHY= X-Google-Smtp-Source: AGHT+IEnfvCRcF0/n98UeB42/2lit+SYcQYhp9aQu4bytpgLstYwUybJ0NOfoPhXqV0YtAJFO/FmRA== X-Received: by 2002:a05:6000:1ac8:b0:385:fc32:1ec3 with SMTP id ffacd0b85a97d-3862b36b015mr8399209f8f.20.1733738701401; Mon, 09 Dec 2024 02:05:01 -0800 (PST) Message-ID: Date: Mon, 9 Dec 2024 11:04:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/xen/mmu: Increase MAX_CONTIG_ORDER To: Thierry Escande Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, xen-devel@lists.xenproject.org, Juergen Gross , linux-kernel@vger.kernel.org References: <20241204171346.458105-1-thierry.escande@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: <20241204171346.458105-1-thierry.escande@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.12.2024 18:14, Thierry Escande wrote: > With change 9f40ec84a797 (xen/swiotlb: add alignment check for dma > buffers), the driver mpt3sas fails to load because it cannot allocate > its DMA pool for an allocation size of ~2,3 MBytes. This is because the > alignement check added by 9f40ec84a797 fails and > xen_swiotlb_alloc_coherent() ends up calling > xen_create_contiguous_region() with a size order of 10 which is too high > for the current max value. > > This patch increases the MAX_CONTIG_ORDER from 9 to 10 (4MB) to allow > such allocations. > > Signed-off-by: Thierry Escande > --- > arch/x86/xen/mmu_pv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c > index 55a4996d0c04..7f110740e1a2 100644 > --- a/arch/x86/xen/mmu_pv.c > +++ b/arch/x86/xen/mmu_pv.c > @@ -2200,7 +2200,7 @@ void __init xen_init_mmu_ops(void) > } > > /* Protected by xen_reservation_lock. */ > -#define MAX_CONTIG_ORDER 9 /* 2MB */ > +#define MAX_CONTIG_ORDER 10 /* 4MB */ > static unsigned long discontig_frames[1< Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 12:02:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851136.1265256 (Exim 4.92) (envelope-from ) id 1tKcSq-0007UN-7N; Mon, 09 Dec 2024 12:02:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851136.1265256; Mon, 09 Dec 2024 12:02: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 1tKcSq-0007UG-4n; Mon, 09 Dec 2024 12:02:12 +0000 Received: by outflank-mailman (input) for mailman id 851136; Mon, 09 Dec 2024 12:02: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 1tKcSo-0007U4-1L for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 12:02:10 +0000 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 68ab95b2-b625-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 13:02:07 +0100 (CET) Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Dec 2024 04:02:04 -0800 Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by fmviesa002.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 09 Dec 2024 04:02:03 -0800 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 9 Dec 2024 04:02:01 -0800 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend Transport; Mon, 9 Dec 2024 04:02:01 -0800 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.173) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Mon, 9 Dec 2024 04:02:00 -0800 Received: from MN6PR11MB8102.namprd11.prod.outlook.com (2603:10b6:208:46d::9) by SA3PR11MB7416.namprd11.prod.outlook.com (2603:10b6:806:316::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.17; Mon, 9 Dec 2024 12:01:50 +0000 Received: from MN6PR11MB8102.namprd11.prod.outlook.com ([fe80::15b2:ee05:2ae7:cfd6]) by MN6PR11MB8102.namprd11.prod.outlook.com ([fe80::15b2:ee05:2ae7:cfd6%4]) with mapi id 15.20.8230.010; Mon, 9 Dec 2024 12:01: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: 68ab95b2-b625-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1733745728; x=1765281728; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=UyA0/Mw9n5WUzPQkDFh1rV7dTtFuvIKnJus0jafUjv8=; b=YH/GCkp41PmeHcs999cOnZUNfhMjzl7NHkeLEaofKKC2lKwzTQsEEeyo tvDF8goPB730jkeCLI6IrZ00U1Nv48sM3E3aR3kCAJQMo0nZX0fUBhmjl WmNKSQsk6QhWawReRIJBCAAteP0z6B6GCMvlvh9baLoIXZYDrejSlN/gN FAp/HJz620OuMbs9xCaAl3+Sf+Vo+F8GHJdi7DyRlCqmIbp4Yc9KqDwzh Or+3U1725ru5n2onFGVyyzq+gLryZNzy5wBoK556v1eAPoktPDs8VUx/W Fhn3T4cGoYR3uJlDpAEKjC/NFa2QWuDCrFM57qp9nIWHsx2cNY+QfnvA0 w==; X-CSE-ConnectionGUID: M9pGi/euSwOQMoi+H6Vhww== X-CSE-MsgGUID: RQJg9Q9sRjmQ0HhPuG39LA== X-IronPort-AV: E=McAfee;i="6700,10204,11281"; a="33376451" X-IronPort-AV: E=Sophos;i="6.12,219,1728975600"; d="scan'208";a="33376451" X-CSE-ConnectionGUID: RuB61iplQoa4buHZ6hF5iw== X-CSE-MsgGUID: HmL+y8muTr+ymH9yB2HFNg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,219,1728975600"; d="scan'208";a="118291933" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=uS+kjXWsgzoZdqSj/eSL5XfkfVfYq2cuSQRl6UEybBLULwbTmEJspFMDdwMArIfetvy4gYcDsuM4cqohT8R4TeOc8bsA48rDaCvAEqTFWn8nkGeUFJ9fVxLIEDzeFbHXhAR5WDHEBHCkJqbgHrphRZz8iNWQyfucmDPSXTq6bFAY7IP9iHDa+agBJFZ7fh4vfN0V8ruZ1jHj9aPaNXNfHPkAC1yW2/F4yT2ChxPpsBsbwc1799X8+RbJOLF3kcBnJRgN7dbK4tlBVJqg7+3pGAb2guhUk/KskQhz+9X/vLe/RosoqV8BvuwBKD1AC1yL/QitAEENUvcrg/5OuZaGmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cWO1vtST2RvN31AcCbA6YitT4GKod8x9EcWhSGYpNW4=; b=ANH8q43m/VKi3HisBqbPcLFAbHYlpaCn3rzQRLsHmO3482tc5Rwfwto41iHvFLw68zOiJ7zbZ47XSyoNddedhUlfTnupYAdArYW7cMguiTkY7nP9FfFc3eTKcuI4zYrlp+bVPvzs6G4CGhgvWEZUEgl3FpbBTDGGgMyYa+ItpquHoB/386C37g9Vk9F/pm9y7xBaM2Cr4Y3kfIY4xfaDlpDqYhNnE2FoYS+Bu4wAMeUNjS6Jgpo5K12GldF9o4pesXEwX+9ifVVuKbuGZSP081eJTtc56nD0Hot9bfDCkK/ncyQ/94MbMBgk0yN3e16g1yDNqZp4+Vf348elxgxKJw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Message-ID: <72c8eb66-eb67-4f8b-b0c0-13f1aa001698@intel.com> Date: Mon, 9 Dec 2024 13:01:42 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 00/21] Converge on using secs_to_jiffies() To: Easwar Hariharan CC: , , , , , , , , , , , , , , , , , , , , , , , , Anna-Maria Behnsen References: <20241115-converge-secs-to-jiffies-v2-0-911fb7595e79@linux.microsoft.com> From: Przemek Kitszel Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: ZR0P278CA0221.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:6a::29) To MN6PR11MB8102.namprd11.prod.outlook.com (2603:10b6:208:46d::9) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN6PR11MB8102:EE_|SA3PR11MB7416:EE_ X-MS-Office365-Filtering-Correlation-Id: fbc1c36e-1946-4347-72cf-08dd18494368 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7416014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?YWRaWVBuaVhybkhDN05KMFRwYUpmcjVnbStIR2hkVTg4cTI1T0JpWkNla1dM?= =?utf-8?B?Z0kzUy9jY0dENGFSWE1nVTVURmpWcjFGMWtvN2hZaGQzNVFCNDI1YTduM05a?= =?utf-8?B?b0JNZHZjZmh3S25PdjdiSDkvUWxYbHJtQVJoK1o1cW5Ic2FUVTN3YW1pZmNC?= =?utf-8?B?Sjl1UXpZU2N3ZCtEZkFlRjBQT0pZdHFjVWl4R0hRbDZBQmNBQnk4VHkwbXhC?= =?utf-8?B?ZzR3TWV6S1paSGpiemlJTDVKTjMyT1dHZ09zR2xFbE1jZkd1YTJuMUl2RGxp?= =?utf-8?B?OUxGY3ZaeWRRSnpqMU5jbWlHVGoybjYxd3NQWTVFZXFBa3JEdWpIbHF6ZDVN?= =?utf-8?B?K052M2xlNTZUMDJ4QmNvTEEzUURPNGxJR0VJV1dRNmQveGhCKysrVTRHNjcx?= =?utf-8?B?ZnVhUXpoNjJYWGdEMml0endxOTUxRTR0bUxZNVErd2NEZUNBZnhpMyttZlph?= =?utf-8?B?djd2bEdVVERYZzVpUFNIaVRmTC9wMzYxaGZSd0tvYkJaYXN0a1FOOGllK1BG?= =?utf-8?B?WmhRRWE5bTN2Y3RnUXU0ZFIrMStEYm1ONk1TMWhpR2Fwa1FaMzJXTzVHdUlH?= =?utf-8?B?OUMwZDZ0QVlxSjdocmVWWlJucUhsVE9uK01sK3VxWG9uRHQvSTRUanEwQ2NH?= =?utf-8?B?K3gwZVlHSWtVK2R0Um1wREZVbUkwTG1wWGVmN3ZCTnk3Sk1sMjYxbnZOVDRz?= =?utf-8?B?Y0ZYaE1yRFVaSWxaek1XM3hPOWNRbUtkaFM2Mm4wSnJpbjR3cEdlazNFLzVU?= =?utf-8?B?NkZGcU5pYkcyclNFYU1sMW1heXRzK0RjNnFyTlZKbGxqVjJhRW1MSlZXYTF2?= =?utf-8?B?bFhjSTJ5SG1TSEE5Uk5tVEN4WmxmeGQ3c3YxYloyZHUzODdEZDdqdnlmQk14?= =?utf-8?B?MEVPeXdSNmg5RXZTZVNFdjFmWlNobXJWdEQ3T0dzOXBFTklSL3BWakZhVWdm?= =?utf-8?B?ZTEyaDVJbVlNN2EzNUkwb0tyUG5WUjllWC92QjlTdVZrbWZUYTdlZnlSYUNh?= =?utf-8?B?NWVZOFo0bVRyd1BJK2Z1ZGZEL2cvRGZkV2ovdTFYaDFyeU80VzFjdDJnZkJJ?= =?utf-8?B?anpOcmh5SHZUOUhsbDFuTmR0WVJYSU5TUGVHY0YybEVtakdKT2lmMlErSHVs?= =?utf-8?B?VjV3MitiUFU3QitJdUtDMUl1YWxzamxMQldTSkVTVkZRcEt1TDdIOVY2Qzlw?= =?utf-8?B?Y21HQXBVZlJMMGlURUdxNHJ5L0MxQkFWVHM3Z3NpT1RUR1A3SGoxRVR2RndP?= =?utf-8?B?VVNPRkt1alhwd2dtcTJuQXRCZjZkZzljdjltdVIyV2RydjNwK0lxNE4rby9j?= =?utf-8?B?NFZZVWZwYW9uRHpGUElRdXdoNjBEV2t5MU1oaElnWVBiUXdBVnovNVViMy9z?= =?utf-8?B?aGtKU0VLcG5Gc04xVVFpZVhkZm1GaUJYNW9rd1FSc1pZNmFnVWFhQ0RBS0Vx?= =?utf-8?B?REQ4WFMzN0pNZi9HVEtMQVpJYWxtZXF1L3FZZ0tEdHg2Tk1ET1htMGVxQzA5?= =?utf-8?B?aExTblJJVTFyd04xT3dIeFJHV08xOHE2WWlSK3pDL2hhZ1Z5Q2hXRTV1NG5p?= =?utf-8?B?S3hSOGRIamdTR2t1ZFNvTGxONHhaYXp1MjQzNEZhM29nbkFIN2ovOWdDSmlp?= =?utf-8?B?OEhEbmk3YnR2TUNFNWxNUkliRDE3L2lhOGswOG1helkyVkpiS0FJM3pGNGt0?= =?utf-8?B?ODJSYXF4Y2p4YmVFaHpxM0RVNVlzelhEczZYS1BSc240b0R5ZnZDWjdUTllN?= =?utf-8?B?Rm5ZZUl2OHk3N1ZnTkVIQUZuRmpPUE1ramNyL0ZwOHBIVGpTTGE0c1NTbXp4?= =?utf-8?B?SjJxajJYSWNDR3dMODNkdz09?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN6PR11MB8102.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7416014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NTl2cUxMSWdXZWwzUWFBcnM3d2J0cTMxWlVDVldrajRnenBxakp0cDJpK2FB?= =?utf-8?B?eCtSeG5sdUFCV3BMY1F4Und2YVloKzlEUzBSWmlGSjNRNkw2amlnVjdkZDZ5?= =?utf-8?B?eGVWN1lRMUpjdStZUnZYWGNmb3o4QXozTE5ZaUYxd2UxaHFNS1BwenZicGhn?= =?utf-8?B?eTZkTkNLdzVSc3pydW1FK3Y4ZUZGSmFXeW5pS3QwZ1A4RmpiSTVMam9oM25Y?= =?utf-8?B?dGpkbVBUNTRMWTVRRXNHUFozUnRFUTA4dVpJcWsxOXZTeHhISW9CeE9mZ1Z4?= =?utf-8?B?N0FHV0NabUhYNDB2ZjhISGlEQ2pEZXNWdklzdDNPTUtRUnlsRTBEaWx3eHY2?= =?utf-8?B?RG5tZDNRR1I0alJITHA2N3VxN0QzOVBGR2NuNXVrNWtKTlIzMUdIYUNMbkVJ?= =?utf-8?B?aUhPaTRKdFQwdm1QZzNIT2YyQXpKL0tyU0d6SXh1RGl6dExmOGFFVE4vUCtt?= =?utf-8?B?ZUpEZmJwRis4WVF1bjkrUE5PTTNqWU5NdUV0RUdqaEZTQm81TER3UTJNNVl6?= =?utf-8?B?WGpHajF6enM2blFkQVFia1hDdnIvamk2S0txdG1Teld4Qk1IVjVpWENSSjR4?= =?utf-8?B?UHZVZzk3TWttVTlFTmxOR0t1R1BLMkZyTGNaZjAvVVRkSk9iZUZYMi9VN0Rq?= =?utf-8?B?aHdwZzBMcnNkVzFhVzZ0bys0Szc3TC9xZHBzY2NkS2ZLamhhTmM0Ryt5djVU?= =?utf-8?B?YWl2OHc3VGpvL1dJamtRSlFkN1dhSHpuNzBTa1ZPUTVlait4NGxoRkhhWFhC?= =?utf-8?B?eG9QTEpSZGJtenUxNVpYRUdicElVM1RHYlJJNTIwSWQ1emtiWkJaSVdoU0Zv?= =?utf-8?B?L2JoRUU4allJZXhmL1JBa1lyVTRCbDkzUUE3RDhmL2V2aEZYMnRzZmtwWmFz?= =?utf-8?B?SFZOSzB0clNVa0dpcmY5c3V3SkhtaG5TYWVYOHNwT3czUFdPSGw5bUpLa2lX?= =?utf-8?B?d0g4ODN6blFMNzFoL1VBWUtSVnIyMXloeFN5dlExWEowa1U2MWJnWDMvaFFU?= =?utf-8?B?VWluOCtNNi9oWHpWc29TOEFoekJlQjM0SHNETk5XVlFrcTI5TTNGVk5lRDFO?= =?utf-8?B?Y2lFMHBQZ2ZhYzdFNmxGTUhuVEE0eUpzUXkzM2c4WjdBSlU0RjhMNW9VeWl5?= =?utf-8?B?ZDNhZU9EUzE2VmdRMldRMUpCVmNQb0VuOGdPZDFLVTdJSnUrL0FMRnB1bm0v?= =?utf-8?B?L1NEWjl1MkFDdW1WcXdwZVdRLzZxZElvOVEwNnl4NHNFdUdhcFFQSEZWMEtl?= =?utf-8?B?NUxGT25ucDdZUllFbkd6OVduaFJLMm5kNlIySjI1djRTWjY4YmpDS056TXlU?= =?utf-8?B?SEVrcEwyV0JVeVpUQmFJZ0E2UmVNMkEyVXBrNThtcm9sWTMyT2s4cm9NNHdn?= =?utf-8?B?VkJJdkNFNUpBNkVEdmJkWjZnSlNldW10SVhWNHk3VHkwQSt2Nkk2U1Bvajli?= =?utf-8?B?SFVzOEg1VHg1QkEzdlhaYW5WZjhWQlFGVnk3czF5OWhRd3hLZC9qbm5uZ2g0?= =?utf-8?B?cVdYOGMxVFVzZ3MrUUxSSXZ1b2JucjRzekNzaHBrclVlbHptRTYveEtrN0Nu?= =?utf-8?B?VmZnSGlxQmN2b0RpZ0lKZ01qbEVJTWEyR2lYUWFremtaOGJ6TmF6ZHltZVhn?= =?utf-8?B?S0tDQXlMKzVPVU00KzNkOHlrbTZFVGNaWkIwNHRyVHA0WW1BVG1wb0o0c1Az?= =?utf-8?B?akRITDhPMUswY2hjTzFlcTNTN2cybnF1OE1Mc3pKNUhOMHp6MXV4R2J0Qnp4?= =?utf-8?B?Y1VISFRTUFVOZ3JCdms1d2xENkl6NHc4MGoxVjN4YTlRcVRzSjZpcGVjNTlu?= =?utf-8?B?NFFKMXIzSmhRQmI0VFB4dVFMNTgxdHQxVHNDQ3BzSlREeXU5Z0xnWm0wdkZK?= =?utf-8?B?WlJHSnpZZ1ZyT1hCaFRwZ0VHZHBlcHA3MnIvR0d1V3BTcGc1Rzd4b01rcGZJ?= =?utf-8?B?NVQxemhHclF4M2NJeUQwNXpZdDhXRmlOV3V6SzFtMlJ6a0ZCM091bXNFVUdy?= =?utf-8?B?R05iblBITWpVMGZ5U29nQlZNSWc4eTlZYm9pUEpsMzBXcUNFSkFvNlVGcmFH?= =?utf-8?B?TkFnN0R5ZklyVEoxQm94NTh6dzVYV1AzOStyUVo0SlA2TG1vZCtnMXA5M21K?= =?utf-8?B?blMweFNMRHRTbVQ5UGhjYUVWdWpkZ3NjL2ZmN1d4dGV1NnRZTUp1cjI1R1RW?= =?utf-8?B?UHc9PQ==?= X-MS-Exchange-CrossTenant-Network-Message-Id: fbc1c36e-1946-4347-72cf-08dd18494368 X-MS-Exchange-CrossTenant-AuthSource: MN6PR11MB8102.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Dec 2024 12:01:50.0336 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 90RppGftVpk3FnymRpMqElEbYRGNrvoy9BAT6DroNtYjNKooFKLbkYJkbD2fkW+MuR4qzs1oYqLeiuNTTK8T1TE04fQVC07aiB1zb/08NYs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR11MB7416 X-OriginatorOrg: intel.com On 12/6/24 9:58 PM, Easwar Hariharan wrote: > On 11/29/2024 4:57 AM, Przemek Kitszel wrote: >> >> [removed most non-list recipients, it's just too much] >> >> On 11/15/24 10:26 PM, Easwar Hariharan wrote: > >> >> Regarding code - you could also convert msecs_to_jiffies(const * HZ), >> there are 10 that are greppable. >> > > Those seem to be mistakes. const*HZ is a seconds-denominated timeout, > being passed to msecs_to_jiffies() which will treat it as a > millisecond-denominated timeout resulting in an excessively long > timeout. I suppose that's better than a too-short timeout, and > apparently it's been working fine all along since hardware responds > before the too-long timeout expires. Half of them are in > drivers/scsi/arcmsr/arcmsr_hba.c and the pattern has apparently been > there since 2010. my point was that, the default value of HZ is 1000, and most of the code that is just `$value*HZ` was meant as "$value seconds, in ms unit". Same for HZ/const, HZ/2 being 500ms. HZ is awful in that it is not 1s but 1/s, but it was easy to abuse the value in simple context. If you happen to touch this, please do in a separate series, to get more attention from drivers owners. > > Thanks, > Easwar From xen-devel-bounces@lists.xenproject.org Mon Dec 09 12:28:40 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 12:28:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851149.1265266 (Exim 4.92) (envelope-from ) id 1tKcsM-00021f-7a; Mon, 09 Dec 2024 12:28:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851149.1265266; Mon, 09 Dec 2024 12:28:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKcsM-00021Y-4s; Mon, 09 Dec 2024 12:28:34 +0000 Received: by outflank-mailman (input) for mailman id 851149; Mon, 09 Dec 2024 12:28: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 1tKcsK-00021S-Nx for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 12:28:32 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on20602.outbound.protection.outlook.com [2a01:111:f403:200a::602]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 18435e6d-b629-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 13:28:30 +0100 (CET) Received: from PH7PR12MB5685.namprd12.prod.outlook.com (2603:10b6:510:13c::22) by DM6PR12MB4266.namprd12.prod.outlook.com (2603:10b6:5:21a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.11; Mon, 9 Dec 2024 12:28:26 +0000 Received: from PH7PR12MB5685.namprd12.prod.outlook.com ([fe80::46fb:96f2:7667:7ca5]) by PH7PR12MB5685.namprd12.prod.outlook.com ([fe80::46fb:96f2:7667:7ca5%5]) with mapi id 15.20.8207.017; Mon, 9 Dec 2024 12:28: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: 18435e6d-b629-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=t9jWmPfEe8i1V9BuJJ0MpOMhVQ6PeK2yk5KaX2xxw9DNCWAkilSBzuLonWEsOLY3mOdJ0Xx6bNckplfE0bxwpTcYBClaBhK4evnHOcfIEb1B8iyOmh+mhv6nynkakXmzlqv4ihlEoHwunrpv4gCMb3+TQqeSTe9h8jv3TclsH2Hi7j91sOMywfvUMvj03q00yqVuNzryCvLh16Yakkx52xMinhpxk/2/Gnb1NvZre1vlVw9jAOrSCTpNXwgVulEfj9s41sfE9yho8ntMK5HQugENRgtytPA+yIRoD2XGTGMgcqpBHMXKFLIu7NmRBB7IIldPSm5EKO1d/goziXy1vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=U3gXwbLF7ec4E+qCH3HUJ9Yzg2Nirswc69Reb7raWrU=; b=v01uS9IZPdpWbIuU6t13VbzJALPAyUiWIUbIXR9Ra/KsmIWxoWABtYa6fiF2hsSefTLdDKkd43lvCqkHJLmxbZPKjMa1VuMbyBVXvFf2IwY7cBZX2FTNQVtZQb6vgma7fhMpRQzasCecmN5uOUwzQB34JqABVogbFd16TRQ+3t5omKQXaSlOLecVoSUZB3ml4J9Z/GmMGJ1wdG5GehGxecnO00DMMZfKqNsGK+Yi3ROzRx1ZyjX/i1SHIDfhcXJnhStXUmJyq7Av6yeb4l5D0pvYQoBXDcDRNaq6yJXs5q0l8PfDyqV5SlS1XTeUfUfYwTkXjAi4HuJf/7XtFUFCoQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U3gXwbLF7ec4E+qCH3HUJ9Yzg2Nirswc69Reb7raWrU=; b=E0dzUGWKwESCWA32waB9aTThOByKS5ULXygacoklpkmk0SJ0klqPMEwn7pneITw6ZP8oX/kM6TVeTfHWPtW6WGsXHkcYI5s5bMFP2Vb3n9o7RM9oEZ2CE8+OtK6Tk68p7K1i6hKVsSnK/ki0eBZEXncIxu8qxiLX0fScbpFBBuo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Message-ID: <36aa77a1-7a72-4cf4-850a-210e6f7f266a@amd.com> Date: Mon, 9 Dec 2024 13:28:16 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] drm/virtio: Implement device_attach To: Julia Zhang , David Airlie , Gerd Hoffmann , Gurchetan Singh , Chia-I Wu , dri-devel@lists.freedesktop.org, virtualization@lists.linux-foundation.org, Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org Cc: Alex Deucher , Daniel Vetter , Chen Jiqian , Huang Rui , Penny Zheng , Zhu Lingshan , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jan Beulich , Paul Durrant References: <20241207105023.542399-1-julia.zhang@amd.com> <20241207105023.542399-4-julia.zhang@amd.com> Content-Language: en-US From: =?UTF-8?Q?Christian_K=C3=B6nig?= In-Reply-To: <20241207105023.542399-4-julia.zhang@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: FR2P281CA0103.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:9c::13) To PH7PR12MB5685.namprd12.prod.outlook.com (2603:10b6:510:13c::22) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH7PR12MB5685:EE_|DM6PR12MB4266:EE_ X-MS-Office365-Filtering-Correlation-Id: a99ceac9-f966-4ac2-a6cd-08dd184cfabb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|7416014|366016|376014|921020; X-Microsoft-Antispam-Message-Info: =?utf-8?B?aUtSZzBNUllkdmtxWmdMczZRalZsU3BUSnlCYTNvaGtKNkFVM0hmR0s5a2p3?= =?utf-8?B?a1p6YUZ6ODlkWFZrYzN0OUo5c0o5Nkl1T2MvWmZuREFRS1FmTWpNMVRqU09o?= =?utf-8?B?ckZYWXE4U3ZOdGRoeEIxdjIwNHhyak0vRUpMcFNTclJXTi9sVmF5OCtsWldr?= =?utf-8?B?bTk5UUcrTDBHUE1IOEFXODZPVnVNYXZsbGZOWjhVMTFwYWlkUTlLb2Q1bXNs?= =?utf-8?B?OGNhVjlhRlVaa01VOStpNlJmaTB1UjJNSVRybUZ2TmFJNEo3NXVSZlBzeWtZ?= =?utf-8?B?N1pIVzhCVWJ2MG1HR0dXM1R4dVk2b3pGOXRsWHlzWmpPdkpFcXpxb3NhM1A4?= =?utf-8?B?ZkVjK3RCRml5RUI4eFZqekRYdGdDUVAwelFIelpyRXUvMHJPRUJpNklkd1RP?= =?utf-8?B?ckZJNCtBUG5QejBPZGZ2dE1oVC8rQWlLaS9JQ0E2OUpheDNyNDZKR2RjWTF6?= =?utf-8?B?U3VMQlNUYlZsajFva2dTa1FLMW1WNENTZHAvYXVScUd2c1RzSXVPSXlWS1I0?= =?utf-8?B?VGhlTktRMjdrRUxRdElYbXNOVWNBOUhjb2dlWnVZcjNZV3BqWUl6TDc2TjFP?= =?utf-8?B?VnBDL0F0THRZeldBWWltMlovRVFaZE9IMG56NkRqQlJBYVNISVRpMndxVkRa?= =?utf-8?B?VmhrMHlOd0wwQ3Bzb3FqQmw5NnB1NDA2dXJUTDhTaURmcVgvb0dXYW5DWXFW?= =?utf-8?B?ayszakx3RXQzM1ZkaDExcjg1YmRSbXRNZFM4Y3o2ekNuN1RiU25IeEJiQkVl?= =?utf-8?B?OSszY1RKR1E2eHdlMlhDeVp3SjFNbUdqNzRDeWF6WDQ2NmFHK3ozMzRlVnVD?= =?utf-8?B?TFhZaE1aTzFIOG12NHVNTE56NGZpaXN2dWd0MkZPUFhwME0zQVhrN1lXaUpZ?= =?utf-8?B?WStueSsvS1E5QTczbHZ3WGNtVWV4Q2tUVFNNcWVIN3hVZGs1cytaZGhXWDNw?= =?utf-8?B?d1dIZFZCUHZsU2pkNnFETWIrdDlUVDVoNzFWT3FUM2ljWGhNK3ZBaVZISnhX?= =?utf-8?B?eTg2RzR6dVpnS2tSZG1oZUhwMFlSbjdndDVtSndpcnE0K3NYajRRY0s1SHVC?= =?utf-8?B?T3JTQ0xDK2ZjcjhlUVoxOVEwNDJEbkc0elE4MWt3dEJtWEQzV3JPMjZxeUF4?= =?utf-8?B?TDF6RWJwYlh0djloS1VPT05tZC9RKzd5Wng4SlovOWlUUVEvQkdrQzJYbEdo?= =?utf-8?B?OEJtYnc1NFRXc1h2Y2Y3QnhpS2dHdUxyUkF3aWdmNmM4UEJIMVFyRDJzOGQy?= =?utf-8?B?b05hTHBYTkN3L2J0WGxyY0FFWUE3WEgwbmtoMk5lN3I2SCtubWpmMTNJTExj?= =?utf-8?B?dTZLZFhEUzR6QVNSYWlRVHVXanFHckt3SHkxdHVkcCtVbi9RWFMvYzhrTkgx?= =?utf-8?B?ZHNIYXFtT1RNOXUyUW9XZUF6a1lkaTByUWJaRTRBUjJSVFhTbVJzMXp1ZEJ2?= =?utf-8?B?UUh2VmxGa1VkNFJ0QkVsSGJOODhFalloeVVWNEUyTE1PRFJtYzFLNzZWNzA1?= =?utf-8?B?Mk9rZmVVMG9Fa1plK3BicDZPbG1icE1RYSt3WnVjalNBQlVObHBoOHgxdGRK?= =?utf-8?B?V3Bha3BjODZRUFM3RDQwa2lONHJibllZc3drRXdyamNpbDdnRjdvRmJOY1FQ?= =?utf-8?B?YTVZWEZLZVdTbWVNS2d5aDMwcWszWktQNVlNSFZxTGk2eUZvTjdUd01wTGk0?= =?utf-8?B?MDJoSjZGZE5DN0dNeEFPUnR6dmdkTkkzcW54eWN4VVZqY1k4aERTckVieTNa?= =?utf-8?B?SXV1Tzlsblpna1dWcjhCeXhoZENBU0FOWC8xaHV6TlkwU2p3SVRRODdTUWhn?= =?utf-8?B?NkljTUJFbk5JUHplTHROVEFETEpPSmp2N1pad1lWdS9vWnpIRXpkYS94TGZt?= =?utf-8?Q?VX4HN+C1VTNvR?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR12MB5685.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(366016)(376014)(921020);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aEZGMzJ1V282K3hVZ2Vzb0EwYjNZbEZiNUJZZ2dOS2RYa0FwcnlXSzJ3SmhX?= =?utf-8?B?dFcvcU5wODB3TW8xdFNGTFc0N0VtU3czSU1mRnVLZVREd3djd3J6ekd3S3l3?= =?utf-8?B?SU1XeE56UkxMZ2tvRXg0TEpQcEVOQ0VPZUN3WUF4b3B3b1pDZ1lUTHdacVli?= =?utf-8?B?OFBQb2t1ZHVJWXc4MjhXWE8yRHE2QWs0SExSRFZJdWdRLzhnUnN0cmhqS3ZU?= =?utf-8?B?eDExM2EwSTRVd3ozemxIckdRRmx1NTkxOXl3ME9SOGhORUZuTitUUmR0OHhJ?= =?utf-8?B?aCtCTVYya0xSQ3didlE1Ty9HYnBnSUpwK041a0dWR2hVT2E0ODJUVUlXWUtt?= =?utf-8?B?SS9taDZVZ01XR2d2TjdhbjV0UWdqdUkxeStKNTRnNWM2VUlBTTVRTEJRb2lR?= =?utf-8?B?bkxMcnphMWlVK0hCM1A2Q3ZZQUk0MlVlYW1YOExwcEU3WUMvQlJrWDFEcURl?= =?utf-8?B?VEk3NWNpK3ZOMHl6U3pEOStyTUthZWJmL25xWlhiUXkxbWhIb3RLbVFnN0NW?= =?utf-8?B?QTRNcTRrSmU0UEMrVDBuUnFORnVuSlFKTTNJcnN0ZFNBcnkvaHU3Y25TSElM?= =?utf-8?B?bzFwZVJSeWc0L3M2VDlnbVVwR3dCQWloelFDeDg4bDZGbWJmMjkvOFZXQU1l?= =?utf-8?B?T0F4djJsZXY0QjhWei9rTm4wY2FrQngwV1RJUGFrcTQ4NVEyZ2pYZmNOaUd6?= =?utf-8?B?dXhQbFExMmhYYXZKcTBDMVJIcjliNTVjT2dwYWxNTFBCRDZQVVVjR1cxanRO?= =?utf-8?B?RVZvZmtnT3p6dll2ODBHdWNsa2lvYmptR3RqcUhwUVdzUW8vZXhHeHZ0ZFdO?= =?utf-8?B?Vm5QOFZTMTIzU2V0Tk4vckkxL0x3QVhGMWhqcms0WnJEaDhydFNpMVhuc0Zj?= =?utf-8?B?djM5SjM2MmVXNzduUGx0a1JTNFo0THpmTElSRXMweXFVVTFCWjBnNkNSbU9k?= =?utf-8?B?RXJBdmMwTDRINEVoKzU0VW90RElaYys2cU9Mb3hhT1hRY1czem80R1VhZWxh?= =?utf-8?B?VUxPZ2xsazZMTHRPNS9SZUhDUHBXUFhUbjV1VXdVT2lWTlBRb25FbW1CUWJ5?= =?utf-8?B?OVdrcXFJY00rRzRWN3RYZnBjSHBhUXlobkhTQkF3azFKTEsxTmpBSW9WUUVE?= =?utf-8?B?Vms0eSt1dU90Z0doOFNZcXZkUDBoc1hKTUlPeGhmNzg5bFJ0VUdvQlFrc1Iz?= =?utf-8?B?N2Myblk5MkltVUtUM0duZmlMaHZsUlFwdVRPWkt2R2UzZWU5dzRacHN0U3hE?= =?utf-8?B?cSt0YjlSV1REVDhXQUZxU0pNZTRSRHlnMkNsRE5CTXYybzVIUnFpQituNjVN?= =?utf-8?B?Uk9NZTZUQnNybWViTWFpcXRnZzl0Q0xPVDdHcHFGUnlMcnRhaUdKWCs0a0J0?= =?utf-8?B?amVFR3hPdG5UOWdMb0NMSXJ5bzVNeHRqckpqQml5OTVkTkhFdkFLUmpwd09p?= =?utf-8?B?UWlYWFZGdFF1eDVjQVhHcCtIa0NJWjVlL1JucmJzL2U3WG52eHdHY1ZKbndk?= =?utf-8?B?aFdlelVqekpZSENFc0NlY2puTGtwS3pwU0h0Q3MyZXVDVEg1RlhZWmY5UEdv?= =?utf-8?B?anBvNU1UT29RV1dlSFNYVDJsc2lFT2VXNUpqUDl3UkR1REw5dUZYOW5iV0xG?= =?utf-8?B?ekpsa09tR211MFErRm1sejVhenRFTzVlMUg0SnRBUS9DUjJPOUxmaW5sY29S?= =?utf-8?B?cUtZVlcxUjVIQ0ZlSzBubUFjMy8wRjduMDY2Q2d2ZDVXTElCTC9HcHFlU1Jw?= =?utf-8?B?bUtMb09mYWllaUQ2WHFKQ1VmdWZEUnpHclcvMDBFOTkwY3JvVHQ1Q2xia0R3?= =?utf-8?B?UHJhdmtJS3JYdGxxS3M0b1AveGF5ZjE2NUF4Q281dW1SQm5Lb1JYaElQQzZY?= =?utf-8?B?V1JVSWcxSjQwV1M3VzVORCs2MUpzVUo5SGRxMkFFajNRMm5tOGZQbGZjRWZn?= =?utf-8?B?b3Y1U3hYTXBoc0M0MTM4eVJKRmRnMkNhMnpVNDJKVDVRZkZTUDEvSVVza1k1?= =?utf-8?B?RkRBZFJjYWZEVVk1QWJFaDFnY1Q0czJUVHNTdkZJVHhrVjhVanZITWRLYStz?= =?utf-8?B?em5OeDhneThSa1ZRcDcrcVF5UGpOM3IzS1RFMEFZMnJycXBDbEp2NS9WbnVI?= =?utf-8?Q?1Si7K9dvCFl7rbuaq/UwDDk5R?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: a99ceac9-f966-4ac2-a6cd-08dd184cfabb X-MS-Exchange-CrossTenant-AuthSource: PH7PR12MB5685.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Dec 2024 12:28:26.0910 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Y8vxxuHrWl3xKqjQj6hmnK6KwGJoAvtZS/wTC2xPE7wBsqVY/shgS6CENsL6qbdJ X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4266 Am 07.12.24 um 11:50 schrieb Julia Zhang: > As vram objects may be imported by other gpu drivers, peer2peer flag > should be checked in dma_buf_ops->attach(). This reimplement virtio gpu > dma_buf_ops->attach by adding a device_attach() function for virtio gpu. > This function will get pci_p2pdma_distance and check attach->peer2peer > before calling drm_gem_map_attach(). > > Signed-off-by: Julia Zhang I can't judge that virtgpu or XEN code path, but that here looks like it should work. Acked-by: Christian König > --- > drivers/gpu/drm/virtio/virtgpu_prime.c | 14 +++++++++++++- > 1 file changed, 13 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c b/drivers/gpu/drm/virtio/virtgpu_prime.c > index 4960620eba02..4f6bce79e10e 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_prime.c > +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c > @@ -116,6 +116,18 @@ static int virtgpu_get_p2pdma_distance(struct dma_buf *dma_buf, > return 0; > } > > +static int virtgpu_gem_device_attach(struct dma_buf *dma_buf, > + struct dma_buf_attachment *attach) > +{ > + int ret = virtgpu_get_p2pdma_distance(dma_buf, attach); > + if (ret) > + return ret; > + if (!attach->peer2peer) > + return -EBUSY; > + > + return drm_gem_map_attach(dma_buf, attach); > +} > + > static const struct virtio_dma_buf_ops virtgpu_dmabuf_ops = { > .ops = { > .cache_sgt_mapping = true, > @@ -128,7 +140,7 @@ static const struct virtio_dma_buf_ops virtgpu_dmabuf_ops = { > .vmap = drm_gem_dmabuf_vmap, > .vunmap = drm_gem_dmabuf_vunmap, > }, > - .device_attach = drm_gem_map_attach, > + .device_attach = virtgpu_gem_device_attach, > .get_uuid = virtgpu_virtio_get_uuid, > }; > From xen-devel-bounces@lists.xenproject.org Mon Dec 09 12:39:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 12:39:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851160.1265276 (Exim 4.92) (envelope-from ) id 1tKd33-0003mR-7C; Mon, 09 Dec 2024 12:39:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851160.1265276; Mon, 09 Dec 2024 12:39: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 1tKd33-0003mK-3F; Mon, 09 Dec 2024 12:39:37 +0000 Received: by outflank-mailman (input) for mailman id 851160; Mon, 09 Dec 2024 12:39: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 1tKd31-0003mE-TZ for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 12:39:36 +0000 Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [2607:f8b0:4864:20::736]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a41e208a-b62a-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 13:39:33 +0100 (CET) Received: by mail-qk1-x736.google.com with SMTP id af79cd13be357-7b6d24069b2so86025885a.0 for ; Mon, 09 Dec 2024 04:39:33 -0800 (PST) Received: from [192.168.1.76] ([188.91.253.160]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa6696acc74sm329635666b.134.2024.12.09.04.39.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 04:39: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: a41e208a-b62a-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exostellar.io; s=google; t=1733747973; x=1734352773; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=tRUTaSdtSTWDNx2ubmJEe+KjO9kK07Vwb4Eyr3Ojt1w=; b=nVkTQiGEMKEjlByXt9Xl0yNvzkyjSnU4bMuPNeZIba41GazicKNZ2EvLDQlGUnPZQC SMVhcb/MDgi9L1WDkzHckFtpRv+ZUESmb1VEzfuIOU3T3bU9vd/aQixUkSK6qevyxMOF EWaJ4QqT2zF5kDfPwElOavMJ+woO5bi4CWjSq0BBbCaFWgmwpbDRUE5+LTszDUEwoVuU OP/oVG2se1p7BzxtYoqCskGzwig7F5J6p3HS5yrMHlohm0B6MBLk5hywUyIeaStNkJGE 871gRZ7HLuq62ZQDKF0pAbmkQR9mVULdwqEIjCn2F5PEZylvnoSrdHN+Yad822c18K04 24nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733747973; x=1734352773; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tRUTaSdtSTWDNx2ubmJEe+KjO9kK07Vwb4Eyr3Ojt1w=; b=Yg3qGtf065Oj57QBf1fq/YWtzy/fuNxJGi03j9t9u+hUhG2XqVO5Rn/st2QvwxpIHD W5TbbDpqI2N8L7S8OCHwSfVLwM2y5rqRASNMKIAarZYke5keKBL/hAgfDKeEp35MHhrU 9/dUojL+mGI+F7kYmp5cpx7So0gwzbn9bVLw+C5PA1GgnTPh0dIdv5hUwtKSxpXo8gcT pbXOKMA3poMICnJjj709ia87OzBldZMg2gSMku+odccRhhuJ03GiQ+BRNdcyF0mAjX3q fhdngAbMc6ifk/li6Lp/uSXMoQe5GtQJqp15J64G/NHgp8oDL1MXUgFCLXQakrIfHi/5 f6eQ== X-Gm-Message-State: AOJu0YwxobWZdmRwoN9KpcMwaDy4QI02TdKXABLeuErAD1Q2Lw2Q1DiH N130pjQnR/IVpukqRGWQbDMmrkbtJNHzWg/JkfoMrfCWJUP8iw7/w5pZxoph2YI= X-Gm-Gg: ASbGnctiYPOnKzM9KE1evLPkTjhY9sSCiO2OdpVTYdRUOz0ywV2/tF1Koa3MQPg5pKq kTN+HZ/K5te71BGxk5+txreWNWqk5k1vM8z6Ui51aY4IFTxBo/khJ1m27WWxzpsW6fU1Vp4QCeA LUxd3CoLUy5tJeww/EYYvCicpe1E2BuYupQf/LIES8R36J1Xxk1GcVszBTIkCKBsh2lxBbc+sYg Cwk/cmbNMbRPlpwfKC6WuJOcJ6gg+QDM4zInbUqSUubEP16gSrJCI8= X-Google-Smtp-Source: AGHT+IGUN0y5tavLjGg8nctS+87f9zbgPbgkotfQ+C/sUG31IJkgL5wL2zKycZaYTebhyfsU6ab9rw== X-Received: by 2002:a05:620a:2b8d:b0:7b6:cedf:1b4b with SMTP id af79cd13be357-7b6dcdd0b6bmr28812585a.7.1733747972695; Mon, 09 Dec 2024 04:39:32 -0800 (PST) Message-ID: <813d9908-48e4-46ce-87c9-7414170e6a6e@exostellar.io> Date: Mon, 9 Dec 2024 13:39:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Grab mm lock before grabbing pt lock To: Dave Hansen , Juergen Gross , Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org References: <20241204103516.3309112-1-maksym@exostellar.io> <24b8d4a0-36c3-4404-98aa-7d8e2c67ac95@intel.com> From: Maksym Planeta Content-Language: en-US In-Reply-To: <24b8d4a0-36c3-4404-98aa-7d8e2c67ac95@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 05/12/2024 19:52, Dave Hansen wrote: > I have the _feeling_ it's just a big hack and this code throws caution > tot the wind because of: > >> * Expected to be called in stop_machine() ("equivalent to taking >> * every spinlock in the system"), so the locking doesn't really >> * matter all that much. > > So the patch here kinda doubles down on the hack and continues the theme > because "locking doesn't really matter all that much." > > If so, it's not super satisfying, but it is consistent with the existing > code. > I indeed could not find reasons why locking would be strictly necessary for correctness here. On the other hand a clearly benign warning should not be triggered, especially considering that panic_on_warn may be on on some systems. From xen-devel-bounces@lists.xenproject.org Mon Dec 09 12:45:57 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 12:45:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851173.1265286 (Exim 4.92) (envelope-from ) id 1tKd95-0005bT-V2; Mon, 09 Dec 2024 12:45:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851173.1265286; Mon, 09 Dec 2024 12:45: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 1tKd95-0005bM-Rm; Mon, 09 Dec 2024 12:45:51 +0000 Received: by outflank-mailman (input) for mailman id 851173; Mon, 09 Dec 2024 12:45: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 1tKd94-0005bE-SB for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 12:45:50 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20608.outbound.protection.outlook.com [2a01:111:f403:2613::608]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8476365a-b62b-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 13:45:49 +0100 (CET) Received: from GV1PR03MB10456.eurprd03.prod.outlook.com (2603:10a6:150:16a::21) by DB9PR03MB8260.eurprd03.prod.outlook.com (2603:10a6:10:308::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.18; Mon, 9 Dec 2024 12:45:44 +0000 Received: from GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e%7]) with mapi id 15.20.8230.010; Mon, 9 Dec 2024 12:45: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: 8476365a-b62b-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=pVZul+hHYNiMTSt/0UGR6MxECueAQmUl6tZybv9tVBt/P+RCvENbkGl5CmGnwMKh0Y0FMM1x3G4iaqqo5tTNujNFmeNy0R6CEmdX3hwRWxRZ4gIIvY5NWdsuPNk64bMJwQc/B3vr04fwaZCNByALEHEHHlLVtsR21PVzCyR4AnJ4+WgEx7ptPm6lO6FND375eswxaja54O7CxGiDpdKkckMQktHtw4SnqQ6IohVoIgTRz8gjYLwQEmxjRudAQhHuPStfmtb38aN0Q1inRGXeMZF2E4gKVS+nUo8zgPUSz5n5ZnI4YVTxIbPJZIqksSuJSMcPSbKWJxoR4hCMRw8YNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=y8bznm84kU0YtF2i42eNMqgCyDG4tsFHTXuze6cnOxY=; b=neESyKKaCguF2hzOXmLJTL1/gzA+B1BARAjDkLGp27W2D+bKuI7aCfc1lTLAoEU3EvKhT2IjLMtDrQsUUiXcVddsnkjbNZ5PT6q6gVNa81/9q8WoZoRpyp1Zbye26teyS7raKEAo0MWl1+wIDD8Ou7wifqzcuznHHEdC1amFJkP38DoHcVRDMJGrn5qwTktYEmaLC4l6f7nJO+BJmMolzjP2OQGh+tgnXtZEwtiIGCFL+1Gt+gA3cFCisSdmOt9tCtyM2/7uY1Grgm8KlLcfzTZ3SRHKgsRi0xerbTLjWZo+smpMLu36TZRvaKzoo8iQC3hbyzNw+XSOGewEyqx4TA== 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=y8bznm84kU0YtF2i42eNMqgCyDG4tsFHTXuze6cnOxY=; b=bv8h1ssjx96606Hms7118uLf5ghPuvoONxt9zAzsdAgge9cjsbz8nwCG9ZUEg4Ntz8ab0hA2nwp4NohZ4XI2kU7CaOIpDo0PC/GqgdtupGrR2gSLr9PgOIQdGzyoMuYAssBZZTxvVl6/nV1cUx4vWmAg++9jiOTcIlDQplgVhEb/hAaTpQalxqZO0edV1fSNDQoZgaIWhnmLIPJgJsHqSLZSOciVCFonNnTODwDEfX86A7FMJotIoqAmetLYM9brD+9A1pAuxp+NjmVVd/BOVoUulu18j8F+P0bNa/cEnt6PuldMJvTLBzruFjC7eH1bCPMFWJX7sVamT+bB3Lhthg== From: Volodymyr Babchuk To: Jan Beulich CC: Julien Grall , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Andrew Cooper Subject: Re: [PATCH v2 3/4] xen: arm: enable stack protector feature Thread-Topic: [PATCH v2 3/4] xen: arm: enable stack protector feature Thread-Index: AQHbQsSdZeSazgkTckCfCx9gDu8jUA== Date: Mon, 9 Dec 2024 12:45:44 +0000 Message-ID: <87v7vt2few.fsf@epam.com> References: <20241130010954.36057-1-volodymyr_babchuk@epam.com> <20241130010954.36057-4-volodymyr_babchuk@epam.com> <79bb69b0-b00d-4e3c-966e-a341eac59499@citrix.com> <87a5d94dwk.fsf@epam.com> <0de3796a-b2b4-4661-b6d7-eee32be66014@suse.com> In-Reply-To: <0de3796a-b2b4-4661-b6d7-eee32be66014@suse.com> (Jan Beulich's message of "Mon, 9 Dec 2024 10:36:00 +0100") 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: GV1PR03MB10456:EE_|DB9PR03MB8260:EE_ x-ms-office365-filtering-correlation-id: 4be2d1c5-9603-4495-31c0-08dd184f65c0 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?H1RHJESYl0tcwdPhLzratxPLfqttRJdutA3zBFIgyZodV7Llxe9x9uFSp9?= =?iso-8859-1?Q?X1ugMn6Ck4Qsl6OqEGZs5lw1WPKrhX5MbxeFqBvWbJyQuGjjb1et/SalW9?= =?iso-8859-1?Q?KB5dBB9jeQnfYAeKQFuiAp9SoskxU26kzS8Vq4ptOlmROM6/XNpNl4nGQ+?= =?iso-8859-1?Q?xxyseFfLCRgTdYAqQGYQqi49q07NixtXzum5zTTDrQ/76iWTwgNwU/Dwml?= =?iso-8859-1?Q?7jyyNSW2KqN/B/CNeLXlNiSTmn1iKxdXSmWoDht1P7d4iWELxucGaBS3Ub?= =?iso-8859-1?Q?1NePrX0eqy32xLSNDCz06v/iMKvg6wIDMf5r7alnptZjgr8Ju52Uo0jUSH?= =?iso-8859-1?Q?qoIhYVFeULx3k9pIiAB0TM8pEeJJYhMpwcLtVTSwIlyeV79TN2KmEuX7uT?= =?iso-8859-1?Q?34bCXNMDqHui2uNCy6PYpVHymsx+K0I99BBlyou9g/REoAbc+FwXwnJBV0?= =?iso-8859-1?Q?jUb+9UUuKfu9+dK/cTO/BTZUUmsWAQg8PBrId49dFrFGJymivsARTtPHAh?= =?iso-8859-1?Q?E22Qb87mF1u+iRjWKf5uUgOUuKPpyTCUgOGUMedwPnISOXYVVNP12xgdsE?= =?iso-8859-1?Q?kBu//CnsM5PgQSByHHrgFUbSdZIkRUfbv1Ow9vGqEgRznBP9etQuRwcYIV?= =?iso-8859-1?Q?zGpYWB26el5Tx2S+A1EbxCPXXrPztS34wdRIVSK/0jbhbPXJK++iMl/g6Q?= =?iso-8859-1?Q?D9A3Qvv2FycVKjrfHjWF9YlqzoQqJ/Rrugo55z2rJFvWWY6D56RinLRRM5?= =?iso-8859-1?Q?82ao5vd+W124umm1aIH1TXPcaPoHMM+zh9UND0NRxZFuBP19acuZjSJzDg?= =?iso-8859-1?Q?73XxhqDbDAype9llBAatYTHKpvV6vHWiPVj+gggAmrgMnwr9De7XyduQHo?= =?iso-8859-1?Q?l0lhvIticMf8DS1KNTWT3balDVvJyxurbJZjPwIjJKQEUYudV1IOpnwxuk?= =?iso-8859-1?Q?XZ5EgF1B7/IrU2/TP0X2f9ZKHq+kHKZhBad1rod03Rt9OgIwJOYFdRaqlg?= =?iso-8859-1?Q?SJkvc4UZIazyNkslT/yAi9OtPMurwiJE1PWB6h1Gq7i1Fl9aXp4eDGhs9R?= =?iso-8859-1?Q?zbYiFwSAYBDqVmWTX62V6zkAoFD3KATI/TcuNuy+Q21Wlhot0kVpxcSN/e?= =?iso-8859-1?Q?imwdhYLD6nz4QI4skA20SoFEjFLh5lqkouwSw890OIXpQSUNO3qhGyBXxr?= =?iso-8859-1?Q?ChcAKs+jOiT7ikx1gEwf1UVInvyGUBVOAp6KXLCzw/6wbk1m1S8BXK2Dy7?= =?iso-8859-1?Q?2YfyJZ1wnUpqNoy0r0HF9JP7gXdCsOtgHdoKtICr4D+r5F67tkT1RyJrPG?= =?iso-8859-1?Q?Qb09xB7M7DAMB1n6+8t8ayJs0G5nz8gNxQEKmf7ek0aJ4WdbpPBRBAAmrv?= =?iso-8859-1?Q?ZwMVAPwDMmXAk9LGlR8ITBUWv288pcnjy3ndcF8sicoD0HKsAcg6BFBbI9?= =?iso-8859-1?Q?nRHFqnPxiCE6mNyF8FkvwF0wtk0dP6tsG9cfWw=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?F6rY8kGg99gXsb1dMScMM8ia9BhEF4gJJ94NDZYR5eBSfcSzTAuCp7fy/G?= =?iso-8859-1?Q?l5u+RhMCIOb7/1lxV2TjUWvmsychlzjCB1ROX8yQLG5KZ33hrjTG/Bidav?= =?iso-8859-1?Q?bh/uZZSstEEzZUmjMyLXnUB7v3da28pDFt7kH0qpgRh4ctpzsAbEpdb+zB?= =?iso-8859-1?Q?G1zj4Td3dao8jR2QxNSkYZCm5edxSPBzSwzJOCx7/ca2nzC6p0oRCJKrkK?= =?iso-8859-1?Q?6Fxj/qKpHBlNTPmrNjEDhyvzNOXvpaHe0MQOd75Z8GETEtQ5zUFgdr6i8u?= =?iso-8859-1?Q?fAL/WSy2yi/9jzLFKqR4HG5gOdpwfDLa8fBx2p6U2ql87Jm9x3N6tU7txU?= =?iso-8859-1?Q?JfsBy023QreBLaC/etDA540vd1UYuabw3SJ6VJC9SJEO3JBsKmDKybxEYN?= =?iso-8859-1?Q?t9mfLT1I0ifg/5ubJ60MkiQa99YDDupaAOc3XVUFWdzRBCEvk4dp+1XX77?= =?iso-8859-1?Q?Y77NC2nVdBcYHUO6VSMNztwmJ8A2s0CdSmASxIDfUF5cju2UOpY4QCKUiW?= =?iso-8859-1?Q?TxXTsKaVI2NkRInZSzsdxbS27FGXv0QYYtMxp4zntV0e9f9Z4FqlKKbRIR?= =?iso-8859-1?Q?b7zItk6fQlj/iRe2Xa7pQ2JX/17PkkrNtahQYAJ1VBv4Hc+Y8nx7gVqbeo?= =?iso-8859-1?Q?w0Gocst1ZVtQOsi7FSOUhHggpUpOAHIMALQQFUUsi0zIjRn5v3anZ3BvRK?= =?iso-8859-1?Q?LmiPRNwAv6VLD5npxjv+tHnxQfN1rCR/RG6844qp/j2U7JzVxdq8QbYfsi?= =?iso-8859-1?Q?EJb7jeSA2NyUpvQuiNyW/5lzk8LwF+k0Q0ByqBcLw1WnQbtzUpm/pIhJdj?= =?iso-8859-1?Q?64x+ny32WOzeAFtaEy4JT0ddoauMSKsCb84c2OZsjPjsw1oFSZUtOH4Tsh?= =?iso-8859-1?Q?OxUzpa9jocIzWvbxNTRr8ofbnDlZouv29fXuvFHiv5NoVnRbqh8zx5Cc/M?= =?iso-8859-1?Q?oGP+Ci0MhAUzC41PZgpP+evR3gzKO3jZ46vbRMIYNM+7efomZUPUMkX8k9?= =?iso-8859-1?Q?MEjCzt8i7gr5N2556l/vRuIU7R2AUtg8Cp7EyHImBFY9AyNcjDLo+s5B4t?= =?iso-8859-1?Q?NbeakVgaTlirX6Wfy9JxmMvv2HUx5WNyZkgGK/S2AUMIvI9JsCoFpgJJ/O?= =?iso-8859-1?Q?e82yhQ+wx73uM3VcZR7DXOSvIblOOy+PE3+UKEVwNtOWcShOZdYOod3wlG?= =?iso-8859-1?Q?8CwxIt0t6nEDWh0zcO8QcxuqceWS04fhStnAXhJihUzBRtvNdYZTg1uVgP?= =?iso-8859-1?Q?g9dvWiI/u4GHCQK6Q6/y3IXtxcoeFC+YqLtCORbSuXqyNj+HQtkTIExDyW?= =?iso-8859-1?Q?DMcwFsFjAxV+5ggk/sobtGKJxR3kdAqmonX6cUoqfs5hdDoWrqGHU9ae7W?= =?iso-8859-1?Q?8/WxAOyIkFJo3bdB7h90TpW5QAFYW6rtnlyTpQfa1WA3c+yqdY+gtop52r?= =?iso-8859-1?Q?OHcrroIs8EvpVsATFZx9cymlgxsbPX4r88lkzBNQP/3+1h6bt6qX5Dx06C?= =?iso-8859-1?Q?CElB/AS2F1QcQJY6p+swIy+HBgGt9lFrjsJRKIsJGs+mBHaxMOMzyCM9tN?= =?iso-8859-1?Q?tWy5Cp2ZUsnuzPcrUci4cQGM3YZSD3xtgdiWtt9X0MTyO6N2hDp3hyZumL?= =?iso-8859-1?Q?6oP9YnqyuMYRSqIR2JHT3f1cBIPrZDvsQxGJnDXE7ejFhujA2Kg8HWjQ?= =?iso-8859-1?Q?=3D=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: GV1PR03MB10456.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4be2d1c5-9603-4495-31c0-08dd184f65c0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2024 12:45:44.4886 (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: UTGy4XD/qUL2yjb6jebczLZnC8JxuVhr7csbtchyK2PkT9G/1mJid86FsqFKsoN/QyEh1L93glfDO/Tvp1jMmIDdqokx49E5N2aqA2NbYXs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB8260 Hi Jan, Jan Beulich writes: [...] > >> #else >> const unsigned long a =3D 2862933555777941757; >> #endif >> const unsigned c =3D 1; > > I'm having a hard time seeing why this need to be a static variable. Its > sole use is ... It's a constant in a hope that compiler is smart enough to optimize it out. >> unsigned long cycles =3D get_cycles(); >>=20 >> if ( !cycles ) >> return; >>=20 >> __stack_chk_guard =3D cycles * a + c; > > ... here, where you can as well write a literal 1. For readability. Formula for LCG is X_n+1 =3D (X_n * a + c) mod m. --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Mon Dec 09 13:07:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 13:07:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851187.1265316 (Exim 4.92) (envelope-from ) id 1tKdTW-0000rK-4l; Mon, 09 Dec 2024 13:06:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851187.1265316; Mon, 09 Dec 2024 13:06: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 1tKdTW-0000rD-0h; Mon, 09 Dec 2024 13:06:58 +0000 Received: by outflank-mailman (input) for mailman id 851187; Mon, 09 Dec 2024 13:06: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 1tKdTV-0000ch-98 for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 13:06:57 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7654070e-b62e-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 14:06:55 +0100 (CET) Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-353-LOaZd975P36jbMOlT3Bxdw-1; Mon, 09 Dec 2024 08:06:52 -0500 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-434f15c1c8fso8812925e9.2 for ; Mon, 09 Dec 2024 05:06:52 -0800 (PST) Received: from eisenberg.redhat.com (nat-pool-muc-u.redhat.com. [149.14.88.27]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3862190965asm13200127f8f.82.2024.12.09.05.06.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2024 05:06: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: 7654070e-b62e-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733749614; 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=JzWiWxh4LRhHWrBZAH8gP8nNmxU8jwjjwHhpaGNecfw=; b=I2MU793kCJdxJqWTyIzOLeN324MDOAIZWMJja0gGcnDsxSHSaA29/T3dlUkmscviVXNiIS ITZ7sAM23lg0YyhO/j1V92jOxLUXwxC4+scckBibwmjVJ/pVr1z+cAqekNMX8/kw5Dtawo 9x5/6mPpQCGTNuvvADbsXdyJzSw2zQs= X-MC-Unique: LOaZd975P36jbMOlT3Bxdw-1 X-Mimecast-MFC-AGG-ID: LOaZd975P36jbMOlT3Bxdw X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733749611; x=1734354411; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JzWiWxh4LRhHWrBZAH8gP8nNmxU8jwjjwHhpaGNecfw=; b=IC8E8oD7z/QrNevycVXHIgUUs7YGZmtfwINnZEIyYllslclfY9OvpvWp2+O2qEHH3u 1of0E6UqcYFWu8rMHLDSQaqI/iTsSneqWK39aFPPMGsknRwE6GIAgPiOExgq43RYeAi0 PigQukEXbH9pkOr+LuQraexTKXEzJgSZhMOKDCfP9NQ2Bom58TsnTuA8H51YpM+A877R llwyeNpZgK/7JaUCoUlQmcEa3OSRg1QFqYrR9ewjZh/lqhE5xDsUeiHFJ2aipKgl+n49 iDPw8tDwfXN8/wZa5/aHyw80Tb5R2xm7HWRB5QA9pCJoxnmGOVMzK2YAw6mCVfoPZX7y q/rA== X-Forwarded-Encrypted: i=1; AJvYcCW7DuNs81tnxjaUVUsxYJhole7w8qTUrTGy2+mITE4apu/Y2rjoedMb7FeX0P3V6DYFzU7bb7FzazI=@lists.xenproject.org X-Gm-Message-State: AOJu0YyRySCvMopfj+qhvB+NCOAgdppeK/G+7nwoaiRMHjTYUSa58qvg k4OvdMT9MH5hNGybekGbXW2XUfYedVJfSxdIThWTGNtv4rzZdThCG+iK1J1Xuhne8gXw5Z2CaDu +XVdHJGm9IkmxSU7QNChwkeZv13EH/kVwuwR/QKnJDejY8ZR+y6sdNKTnySnb0cbq X-Gm-Gg: ASbGncsBuR1Oeax9Kmi5BTstQ9ZWcngF4giPqZfMDQ5v/7ZlYyxa2wEDnUFa+s7qHkM ZgOBoSLzfEY31JKjfoH6q6IxEJzEBy3qzEKHYCRv+effIBV3EAIY69xvMFH7+s49IUK6iGK1BLs e+9UYA3ebLw5c8RtsaijJDwhVXRJY81P+mwbJyxqhnUW3uYPOPgWIdXC/cvL8kqUIi3pwgyM7ZO f3OcsktdhSoE1lIGBBGdg6QI47qarizH9xog4SBAUSb11kA8ALyCeTUBldWd6SC9w/mJYkn5RPN 69aJTYhY X-Received: by 2002:a05:6000:186c:b0:385:f465:12f8 with SMTP id ffacd0b85a97d-386453f6891mr224945f8f.47.1733749611248; Mon, 09 Dec 2024 05:06:51 -0800 (PST) X-Google-Smtp-Source: AGHT+IEYLGzMuES8pL8UNwc6rduiHNSssmgKFMI0arqDxmQvwrHwV9r5BJKNGyDbmmGP7hHm3hITRA== X-Received: by 2002:a05:6000:186c:b0:385:f465:12f8 with SMTP id ffacd0b85a97d-386453f6891mr224791f8f.47.1733749609723; Mon, 09 Dec 2024 05:06:49 -0800 (PST) From: Philipp Stanner To: amien Le Moal , Niklas Cassel , Basavaraj Natikar , Jiri Kosina , Benjamin Tissoires , Arnd Bergmann , Greg Kroah-Hartman , Alex Dubov , Sudarsana Kalluru , Manish Chopra , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rasesh Mody , GR-Linux-NIC-Dev@marvell.com, Igor Mitsyanko , Sergey Matyukevich , Kalle Valo , Sanjay R Mehta , Shyam Sundar S K , Jon Mason , Dave Jiang , Allen Hubbe , Bjorn Helgaas , Alex Williamson , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Mario Limonciello , Chen Ni , Philipp Stanner , Ricky Wu , Al Viro , Breno Leitao , Thomas Gleixner , Kevin Tian , Andy Shevchenko , Mostafa Saleh , Jason Gunthorpe , Yi Liu , Kunwu Chan , Dan Carpenter , "Dr. David Alan Gilbert" , Ankit Agrawal , Reinette Chatre , Eric Auger , Ye Bin Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, ntb@lists.linux.dev, linux-pci@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Subject: [PATCH v3 02/11] drivers/xen: Use never-managed version of pci_intx() Date: Mon, 9 Dec 2024 14:06:24 +0100 Message-ID: <20241209130632.132074-4-pstanner@redhat.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20241209130632.132074-2-pstanner@redhat.com> References: <20241209130632.132074-2-pstanner@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 3gDdNv9p2cS8ouGS955YkhTnpQG_o4BuqQnhN5cId8o_1733749611 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true pci_intx() is a hybrid function which can sometimes be managed through devres. To remove this hybrid nature from pci_intx(), it is necessary to port users to either an always-managed or a never-managed version. xen enables its PCI-Device with pci_enable_device(). Thus, it needs the never-managed version. Replace pci_intx() with pci_intx_unmanaged(). Signed-off-by: Philipp Stanner Acked-by: Juergen Gross --- drivers/xen/xen-pciback/conf_space_header.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/xen-pciback/conf_space_header.c b/drivers/xen/xen-pciback/conf_space_header.c index fc0332645966..8d26d64232e8 100644 --- a/drivers/xen/xen-pciback/conf_space_header.c +++ b/drivers/xen/xen-pciback/conf_space_header.c @@ -106,7 +106,7 @@ static int command_write(struct pci_dev *dev, int offset, u16 value, void *data) if (dev_data && dev_data->allow_interrupt_control && ((cmd->val ^ value) & PCI_COMMAND_INTX_DISABLE)) - pci_intx(dev, !(value & PCI_COMMAND_INTX_DISABLE)); + pci_intx_unmanaged(dev, !(value & PCI_COMMAND_INTX_DISABLE)); cmd->val = value; -- 2.47.1 From xen-devel-bounces@lists.xenproject.org Mon Dec 09 13:07:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 13:07:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851188.1265326 (Exim 4.92) (envelope-from ) id 1tKdTZ-00018Y-AZ; Mon, 09 Dec 2024 13:07:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851188.1265326; Mon, 09 Dec 2024 13:07: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 1tKdTZ-00018N-70; Mon, 09 Dec 2024 13:07:01 +0000 Received: by outflank-mailman (input) for mailman id 851188; Mon, 09 Dec 2024 13:06: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 1tKdTX-0000ch-Qa for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 13:06:59 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 78b0736b-b62e-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 14:06:59 +0100 (CET) Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-60-xvUCrlphP5afoRypEeNXAg-1; Mon, 09 Dec 2024 08:06:55 -0500 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-385f0829430so2934808f8f.1 for ; Mon, 09 Dec 2024 05:06:54 -0800 (PST) Received: from eisenberg.redhat.com (nat-pool-muc-u.redhat.com. [149.14.88.27]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3862190965asm13200127f8f.82.2024.12.09.05.06.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2024 05:06: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: 78b0736b-b62e-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733749617; 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=BJlyFDGVHa1KIDhGsh03tIghv1/oE2/0tVlBeLCm6QY=; b=Qlr8oNK28eNpw682MBL8U6SKkhMY5HjbyugMJQqarq/kxKRPxLdwOlOcGk88idw0DAkY6g 9025gnylQ1//eg6ZsJ+2FkNeW819UX70LrXGgO17U6/Akb9yuSuM5D0ZwLYTnoxU8w1E1C /nDYcE0dnWaG1X8D0BBb4Q0hAw0rkMc= X-MC-Unique: xvUCrlphP5afoRypEeNXAg-1 X-Mimecast-MFC-AGG-ID: xvUCrlphP5afoRypEeNXAg X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733749613; x=1734354413; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BJlyFDGVHa1KIDhGsh03tIghv1/oE2/0tVlBeLCm6QY=; b=UmrWczkwFZ6DzVKtS+UvCHlehJ0K0AbkSGyEIweHQr0i1R9tpja9ULKHEkmqvWQM6i VxyUJsrHwXZpV22plcFZ/ERk7N/mp36Fo8now+/IazDwGCspKZHPe3/ZIOwIyQKcZz3b MOUmghjNuhskKc0Yj+al7oWdzNMaSfvcOzhkqEQcq8Y+tQomVSFstCvcaYs9wBh5YxJ0 b2kUr6wRyvhjjAgiUTzILrr6pyjKHQvDPckGHj7R8rWE/EH4xhaoZsHmhs3F2r8SCDKw aP3Giu/VGytFw3tBeM/modxNc7rQPZm7VWaiWnl/8zIO77aEid9c8tg5SfdeaG5zbWqp sVwA== X-Forwarded-Encrypted: i=1; AJvYcCUHl4CN4TIUl4n4HzANL9NCinl7ConNHq66t0JYWAZeNgNfBMyzBqgGoR1u///hl+nV3RMeI/lGqhQ=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywd1cIax3Biy6ZtFkPOmzP3oXXXUmwX/Gcuf+Y+BTN2XtWGhqzG Zh6YdtAzjjCqsFUP4ZupOTDBugENo2l+rg4JU86W5ukeQkYqo53qqexw2vcxMlFI3VtLJHs4pVL R9aMRN0wKWAaVtn2wTd9NlB2QB/yrmUTGVpM0sYOHKtQko1f+uoMPhYoiFmzSECHu X-Gm-Gg: ASbGncuwftnq+Cm+S2pJCmXWAuQMRu1eCpQQl2irt45JrH7/4AUtBUwL7FMJ0auWUaq FZEGEUaxi2lCahdpETzbohMJG6hBdeHJr0jfoAooz0xWu1PxaCvE1PdQzZKt3jOkLUHpBwM65Vh CSNsrauLHUnm72OeZ8iepuCllG2vqt94JiKIWO/xEKa+79q0MrBKuSJrHuiKntGQAkMxfkBBMwI G6XjQlzbRh/+1Ie36TrVvAJWcOQKkkmVv1dHx6OiZ4JU6cdEgirdpk0JedfzPAQCIsN/McDP2uW O3ww31Bn X-Received: by 2002:a05:6000:2d08:b0:386:144d:680f with SMTP id ffacd0b85a97d-386453fd870mr188104f8f.54.1733749613282; Mon, 09 Dec 2024 05:06:53 -0800 (PST) X-Google-Smtp-Source: AGHT+IFj1wppsmKOkdvfdKSfuff+I9JjxqlZHOEEdHEk5K3zylRh/0qa/2JfnJnGp4etqXepLTEqow== X-Received: by 2002:a05:6000:2d08:b0:386:144d:680f with SMTP id ffacd0b85a97d-386453fd870mr188043f8f.54.1733749612866; Mon, 09 Dec 2024 05:06:52 -0800 (PST) From: Philipp Stanner To: amien Le Moal , Niklas Cassel , Basavaraj Natikar , Jiri Kosina , Benjamin Tissoires , Arnd Bergmann , Greg Kroah-Hartman , Alex Dubov , Sudarsana Kalluru , Manish Chopra , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rasesh Mody , GR-Linux-NIC-Dev@marvell.com, Igor Mitsyanko , Sergey Matyukevich , Kalle Valo , Sanjay R Mehta , Shyam Sundar S K , Jon Mason , Dave Jiang , Allen Hubbe , Bjorn Helgaas , Alex Williamson , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Mario Limonciello , Chen Ni , Philipp Stanner , Ricky Wu , Al Viro , Breno Leitao , Thomas Gleixner , Kevin Tian , Andy Shevchenko , Mostafa Saleh , Jason Gunthorpe , Yi Liu , Kunwu Chan , Dan Carpenter , "Dr. David Alan Gilbert" , Ankit Agrawal , Reinette Chatre , Eric Auger , Ye Bin Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, ntb@lists.linux.dev, linux-pci@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Subject: [PATCH v3 03/11] net/ethernet: Use never-managed version of pci_intx() Date: Mon, 9 Dec 2024 14:06:25 +0100 Message-ID: <20241209130632.132074-5-pstanner@redhat.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20241209130632.132074-2-pstanner@redhat.com> References: <20241209130632.132074-2-pstanner@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: sRO3flFZN5rImIblnx9bF4jePElaLmy0JByv90d20Wo_1733749613 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true pci_intx() is a hybrid function which can sometimes be managed through devres. To remove this hybrid nature from pci_intx(), it is necessary to port users to either an always-managed or a never-managed version. broadcom/bnx2x and brocade/bna enable their PCI-Device with pci_enable_device(). Thus, they need the never-managed version. Replace pci_intx() with pci_intx_unmanaged(). Signed-off-by: Philipp Stanner --- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +- drivers/net/ethernet/brocade/bna/bnad.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c index 678829646cec..2ae63d6e6792 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c @@ -1669,7 +1669,7 @@ static void bnx2x_igu_int_enable(struct bnx2x *bp) REG_WR(bp, IGU_REG_PF_CONFIGURATION, val); if (val & IGU_PF_CONF_INT_LINE_EN) - pci_intx(bp->pdev, true); + pci_intx_unmanaged(bp->pdev, true); barrier(); diff --git a/drivers/net/ethernet/brocade/bna/bnad.c b/drivers/net/ethernet/brocade/bna/bnad.c index ece6f3b48327..2b37462d406e 100644 --- a/drivers/net/ethernet/brocade/bna/bnad.c +++ b/drivers/net/ethernet/brocade/bna/bnad.c @@ -2669,7 +2669,7 @@ bnad_enable_msix(struct bnad *bnad) } } - pci_intx(bnad->pcidev, 0); + pci_intx_unmanaged(bnad->pcidev, 0); return; -- 2.47.1 From xen-devel-bounces@lists.xenproject.org Mon Dec 09 13:07:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 13:07:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851185.1265295 (Exim 4.92) (envelope-from ) id 1tKdTT-0000Om-Il; Mon, 09 Dec 2024 13:06:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851185.1265295; Mon, 09 Dec 2024 13:06:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKdTT-0000Of-GB; Mon, 09 Dec 2024 13:06:55 +0000 Received: by outflank-mailman (input) for mailman id 851185; Mon, 09 Dec 2024 13:06: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 1tKdTR-0000OS-Oy for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 13:06:53 +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 73207570-b62e-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 14:06:49 +0100 (CET) Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-29-zJCvk5qUMeeQ4JH2xZ03sA-1; Mon, 09 Dec 2024 08:06:47 -0500 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-385e03f54d0so1754215f8f.3 for ; Mon, 09 Dec 2024 05:06:46 -0800 (PST) Received: from eisenberg.redhat.com (nat-pool-muc-u.redhat.com. [149.14.88.27]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3862190965asm13200127f8f.82.2024.12.09.05.06.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2024 05:06: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: 73207570-b62e-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733749608; 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; bh=ChZary8egFvw+XcfiLo4meSQA+SNlXlrlIPLWf6ynjo=; b=Nqop0jlJFPhx6vkmKGN5yOYfeNtJ8/q0KzbGiNl07YmdqpjzBVJoJ1YLko0cXo1i4f4QbD R2YqpWz8GbSRZ+lTburA5sjezTdr/kBwoTTgMhRf9LTG/OKC9OXkcdbPq7KVT21VxEy8c9 ZZvj8+W1ZxGZ4CE4Er/SB1tflYdMfWk= X-MC-Unique: zJCvk5qUMeeQ4JH2xZ03sA-1 X-Mimecast-MFC-AGG-ID: zJCvk5qUMeeQ4JH2xZ03sA X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733749606; x=1734354406; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ChZary8egFvw+XcfiLo4meSQA+SNlXlrlIPLWf6ynjo=; b=I5FiUIMJ0NjpS31/q33YzlXnCVZdDzi/08PmLkp8XYaLUiBxXbIbJwzRGzVNEjeGkX 5HSwcNIJDQfMlz24t4+cf2Z9olQz63Qoed9hzd4e+daYlhUUJU+zgtjyBACzRvEC1E1h o8ukYrKUGd+oFWy4VXjfWJfpzw+z7oWUSfWCDR+aiiC13s+aNKsCZRm5M6nGSPZmrYSa 6gkMz+yZ3tM+gjS6a5bd8u1fetg+CAcjSOXtLO3qTOOohYD4gNjd2sMIfh5PF/g0zh/4 ua6wZsux2Ny3QWRyE2Cbw6U21eOKhgErbVqPC6/M0JreAiNn2gHNJ++HgklMD663rwN3 0Mqw== X-Forwarded-Encrypted: i=1; AJvYcCUuyilzTC/9gdLzL4GzPUjUd6IJdUbR3XTUy7evV4dLsI2FYzpie+gNgSYDQf45l83lJdIowPpdqA8=@lists.xenproject.org X-Gm-Message-State: AOJu0YzfG1W6eGjn5tI3rHS3s3PS4CHJ1rapxLf4hBfr8ajEalQQqK8S TxqQAq6nWdhBXvqqtnlHjv5cskIJKljw146IYa2zQk062xED3Gvad/tzNj8b3UQTNTc0MkNJiq8 05HFiSJrgduJDwd77A7aRrvnsfi/4sOa52YxGkKbzJ/u3QfKg5aNEahe+IRyiB8br X-Gm-Gg: ASbGncuEPcsUA2lGKlgfIL8kxatDIBJlq9bP4oMoaPTGpxsLnXp+0jixTzBS6MMne2f aLY+PI1hQb4i5iPUWZiRfzFv5ig9t4keZjideTVpCwoIvUiVxo/6+GgOcf0NLW+VgzahiXIT+35 uFsuHNWU4JfXh7fPJL4GI1U1Qh9K2usc+wK6Uer4xwdC1BhIrecCVX8tqF5IUgwmNrCmjyDAXCO 8xZ2G+uFqkmCeboFR8/G2TtEw79NriwdwXnkAEmNRxzUgwBYb6tPYC/O61iZVqe2EMl1HHCoR98 evDQ6BSA X-Received: by 2002:a5d:5886:0:b0:385:f114:15d6 with SMTP id ffacd0b85a97d-3862b355e4bmr9451332f8f.13.1733749605786; Mon, 09 Dec 2024 05:06:45 -0800 (PST) X-Google-Smtp-Source: AGHT+IE3aZqcp+qWXyKCP+s6A/eeOG43m5kb4cM7P1FP5MJVsW/bqky4A5d7q1L7C7R7quzo+4CpVg== X-Received: by 2002:a5d:5886:0:b0:385:f114:15d6 with SMTP id ffacd0b85a97d-3862b355e4bmr9451253f8f.13.1733749605217; Mon, 09 Dec 2024 05:06:45 -0800 (PST) From: Philipp Stanner To: amien Le Moal , Niklas Cassel , Basavaraj Natikar , Jiri Kosina , Benjamin Tissoires , Arnd Bergmann , Greg Kroah-Hartman , Alex Dubov , Sudarsana Kalluru , Manish Chopra , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rasesh Mody , GR-Linux-NIC-Dev@marvell.com, Igor Mitsyanko , Sergey Matyukevich , Kalle Valo , Sanjay R Mehta , Shyam Sundar S K , Jon Mason , Dave Jiang , Allen Hubbe , Bjorn Helgaas , Alex Williamson , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Mario Limonciello , Chen Ni , Philipp Stanner , Ricky Wu , Al Viro , Breno Leitao , Thomas Gleixner , Kevin Tian , Andy Shevchenko , Mostafa Saleh , Jason Gunthorpe , Yi Liu , Kunwu Chan , Dan Carpenter , "Dr. David Alan Gilbert" , Ankit Agrawal , Reinette Chatre , Eric Auger , Ye Bin Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, ntb@lists.linux.dev, linux-pci@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Subject: [PATCH v3 00/11] Remove implicit devres from pci_intx() Date: Mon, 9 Dec 2024 14:06:22 +0100 Message-ID: <20241209130632.132074-2-pstanner@redhat.com> X-Mailer: git-send-email 2.47.1 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: qGP5dz2wQ5-wtETXDfYFgoBJZpKHWFvqjN-9k2mxuCU_1733749606 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true @Driver-Maintainers: Your driver might be touched by patch "Remove devres from pci_intx()". You might want to take a look. Changes in v3: - Add Thomas' RB. Changes in v2: - Drop pci_intx() deprecation patch. - ata: Add RB from Sergey and Niklas. - wifi: Add AB by Kalle. - Drop INTx deprecation patch - Drop ALSA / hda_intel patch because pci_intx() was removed from there in the meantime. Changes since the RFC [1]: - Add a patch deprecating pci{m}_intx(). (Heiner, Andy, Me) - Add Acked-by's already given. - Export pcim_intx() as a GPL function. (Alex) - Drop patch for rts5280, since this driver will be removed quite soon. (Philipp Hortmann, Greg) - Use early-return in pci_intx_unmanaged() and pci_intx(). (Andy) Hi all, this series removes a problematic feature from pci_intx(). That function sometimes implicitly uses devres for automatic cleanup. We should get rid of this implicit behavior. To do so, a pci_intx() version that is always-managed, and one that is never-managed are provided. Then, all pci_intx() users are ported to the version they need. Afterwards, pci_intx() can be cleaned up and the users of the never-managed version be ported back to pci_intx(). This way we'd get this PCI API consistent again. Patch "Remove devres from pci_intx()" obviously reverts the previous patches that made drivers use pci_intx_unmanaged(). But this way it's easier to review and approve. It also makes sure that each checked out commit should provide correct behavior, not just the entire series as a whole. Merge plan for this is to enter through the PCI tree. [1] https://lore.kernel.org/all/20241009083519.10088-1-pstanner@redhat.com/ Regards, P. Philipp Stanner (11): PCI: Prepare removing devres from pci_intx() drivers/xen: Use never-managed version of pci_intx() net/ethernet: Use never-managed version of pci_intx() net/ntb: Use never-managed version of pci_intx() misc: Use never-managed version of pci_intx() vfio/pci: Use never-managed version of pci_intx() PCI: MSI: Use never-managed version of pci_intx() ata: Use always-managed version of pci_intx() wifi: qtnfmac: use always-managed version of pcim_intx() HID: amd_sfh: Use always-managed version of pcim_intx() Remove devres from pci_intx() drivers/ata/ahci.c | 2 +- drivers/ata/ata_piix.c | 2 +- drivers/ata/pata_rdc.c | 2 +- drivers/ata/sata_sil24.c | 2 +- drivers/ata/sata_sis.c | 2 +- drivers/ata/sata_uli.c | 2 +- drivers/ata/sata_vsc.c | 2 +- drivers/hid/amd-sfh-hid/amd_sfh_pcie.c | 4 ++-- drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c | 2 +- .../wireless/quantenna/qtnfmac/pcie/pcie.c | 2 +- drivers/pci/devres.c | 24 +++---------------- drivers/pci/pci.c | 16 +++---------- include/linux/pci.h | 1 + 13 files changed, 18 insertions(+), 45 deletions(-) -- 2.47.1 From xen-devel-bounces@lists.xenproject.org Mon Dec 09 13:07:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 13:07:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851186.1265305 (Exim 4.92) (envelope-from ) id 1tKdTU-0000cp-PA; Mon, 09 Dec 2024 13:06:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851186.1265305; Mon, 09 Dec 2024 13:06: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 1tKdTU-0000ci-MS; Mon, 09 Dec 2024 13:06:56 +0000 Received: by outflank-mailman (input) for mailman id 851186; Mon, 09 Dec 2024 13:06: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 1tKdTT-0000OS-2L for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 13:06:55 +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 754b1de1-b62e-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 14:06:53 +0100 (CET) Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-573-RntLltv2P2OQe3fWt62NcQ-1; Mon, 09 Dec 2024 08:06:50 -0500 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-385e1339790so2818253f8f.2 for ; Mon, 09 Dec 2024 05:06:49 -0800 (PST) Received: from eisenberg.redhat.com (nat-pool-muc-u.redhat.com. [149.14.88.27]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3862190965asm13200127f8f.82.2024.12.09.05.06.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2024 05:06: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: 754b1de1-b62e-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733749612; 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=LjtlDqjVbjjdLVPvux+VnzDcjHru5NMyBrbq6sIUPEE=; b=boiqgX+io6aHOSt616ajLORqvl0bmi2llFO3yxsK1RvPY1KVt0Idnb2gruX6jHdUtGVdhc BEuVA1FDkOsx34vrEdLZtEw6iCkgS2szP3jZ3fSu9nIVUbAw5e2EunoxfZFsB1Utkc9iPA DjxDtQmnGW03pf7Lz41Dw93H8K3jtD0= X-MC-Unique: RntLltv2P2OQe3fWt62NcQ-1 X-Mimecast-MFC-AGG-ID: RntLltv2P2OQe3fWt62NcQ X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733749608; x=1734354408; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LjtlDqjVbjjdLVPvux+VnzDcjHru5NMyBrbq6sIUPEE=; b=ejDzf6VF5O+HnWi19qz5uwSu1gv5Lq2bzA4uUTsbhNLliOiXFuucInBhE/WaVZsfRp AH2w6NzGEotfuaaCdv3/WiUZMzr9MttvItiazJ9LY2Fa15xp0m5VxsDia7B+I60L7ENE F5yP/p7sx23WyyaUOSigCnqBtG5+JeJJL4WvpCN7nwPkmaFtZFp6ZbBRJW8LdrBJwrge IbdPhSdG0+ECrmFaMgWDCaduCprLLmEdraKzEzVo6clYbLjJ7B+av/oYBuG/YVzYYsR2 jMNUAX2owG4AiO5npkExeVdUHqwTLyLP050Mh6UOCdMwNsGzAiKR/MW5CWoct0Sf5aTE JuTQ== X-Forwarded-Encrypted: i=1; AJvYcCVTaYanweuSw46135x4DD1eM6nMI4gXEVzQuLCxazfpDynYextrJpMw5torbxRKrEMpQPUKQ3Jv6Jg=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx++8hSPVyIcX6kAHFrYMGODo+y/UMLSkQiYkJbttIEm2TZU8Lj M6fptLQjMvJJ0T86HpKdUY71I2RHARnrKPxr+G2Yms8xbGmalYaEFgt1/7Yxos145hNmrha0+yG 1/2LTkLEfHUYtjdDssx3p0jrsCGEBf9wvR4VEcUZPtMXpqIeUpPUusiAKcXrqJnx2 X-Gm-Gg: ASbGncs8WjLa+RLQ4VIM4ziaNSsWP0IYjwSkB9XAEEOfSybsK4DS7bNr8+dpID6t2r7 pjHL18hu81yL4UhzyaH/l40ChwiwqB6HXLaZkXlCBrnIXrruOcJggv8yBRP7129Q/3yf5XxHfYq j+4azQDqpz1yOsI76CYWme3YmBAr5z1c6Ec4oK0IroDBf+fMSdrtGg+R4JTQyC0l7G6kj9nsstZ YfobmhLmgOCpKYmCwZvjf9MduN0tcPeztKJhh28r/56npeORJEHq7QKWvPUyx1krFpQ5hAYLuYj l/8SZ240 X-Received: by 2002:a5d:6c65:0:b0:385:ebaf:3824 with SMTP id ffacd0b85a97d-386453e1638mr347887f8f.27.1733749608211; Mon, 09 Dec 2024 05:06:48 -0800 (PST) X-Google-Smtp-Source: AGHT+IFe4lx/EENwtCaRxhJCz0NOg0TrCmZKbhSzjlYB6+7PsBpCd1abctGiIUuR4mdyx/fkgNv7cA== X-Received: by 2002:a5d:6c65:0:b0:385:ebaf:3824 with SMTP id ffacd0b85a97d-386453e1638mr347789f8f.27.1733749607612; Mon, 09 Dec 2024 05:06:47 -0800 (PST) From: Philipp Stanner To: amien Le Moal , Niklas Cassel , Basavaraj Natikar , Jiri Kosina , Benjamin Tissoires , Arnd Bergmann , Greg Kroah-Hartman , Alex Dubov , Sudarsana Kalluru , Manish Chopra , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rasesh Mody , GR-Linux-NIC-Dev@marvell.com, Igor Mitsyanko , Sergey Matyukevich , Kalle Valo , Sanjay R Mehta , Shyam Sundar S K , Jon Mason , Dave Jiang , Allen Hubbe , Bjorn Helgaas , Alex Williamson , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Mario Limonciello , Chen Ni , Philipp Stanner , Ricky Wu , Al Viro , Breno Leitao , Thomas Gleixner , Kevin Tian , Andy Shevchenko , Mostafa Saleh , Jason Gunthorpe , Yi Liu , Kunwu Chan , Dan Carpenter , "Dr. David Alan Gilbert" , Ankit Agrawal , Reinette Chatre , Eric Auger , Ye Bin Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, ntb@lists.linux.dev, linux-pci@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Subject: [PATCH v3 01/11] PCI: Prepare removing devres from pci_intx() Date: Mon, 9 Dec 2024 14:06:23 +0100 Message-ID: <20241209130632.132074-3-pstanner@redhat.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20241209130632.132074-2-pstanner@redhat.com> References: <20241209130632.132074-2-pstanner@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 56JekqhS3SovCf_AbJ7MI7OlWXqVdw1HuXxTJv9Jbm8_1733749608 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true pci_intx() is a hybrid function which sometimes performs devres operations, depending on whether pcim_enable_device() has been used to enable the pci_dev. This sometimes-managed nature of the function is problematic. Notably, it causes the function to allocate under some circumstances which makes it unusable from interrupt context. To, ultimately, remove the hybrid nature from pci_intx(), it is first necessary to provide an always-managed and a never-managed version of that function. Then, all callers of pci_intx() can be ported to the version they need, depending whether they use pci_enable_device() or pcim_enable_device(). An always-managed function exists, namely pcim_intx(), for which __pcim_intx(), a never-managed version of pci_intx() has been implemented. Make __pcim_intx() a public function under the name pci_intx_unmanaged(). Make pcim_intx() a public function. Signed-off-by: Philipp Stanner Reviewed-by: Damien Le Moal --- drivers/pci/devres.c | 24 +++--------------------- drivers/pci/pci.c | 29 +++++++++++++++++++++++++++++ include/linux/pci.h | 2 ++ 3 files changed, 34 insertions(+), 21 deletions(-) diff --git a/drivers/pci/devres.c b/drivers/pci/devres.c index 3b59a86a764b..3594eea37993 100644 --- a/drivers/pci/devres.c +++ b/drivers/pci/devres.c @@ -411,31 +411,12 @@ static inline bool mask_contains_bar(int mask, int bar) return mask & BIT(bar); } -/* - * This is a copy of pci_intx() used to bypass the problem of recursive - * function calls due to the hybrid nature of pci_intx(). - */ -static void __pcim_intx(struct pci_dev *pdev, int enable) -{ - u16 pci_command, new; - - pci_read_config_word(pdev, PCI_COMMAND, &pci_command); - - if (enable) - new = pci_command & ~PCI_COMMAND_INTX_DISABLE; - else - new = pci_command | PCI_COMMAND_INTX_DISABLE; - - if (new != pci_command) - pci_write_config_word(pdev, PCI_COMMAND, new); -} - static void pcim_intx_restore(struct device *dev, void *data) { struct pci_dev *pdev = to_pci_dev(dev); struct pcim_intx_devres *res = data; - __pcim_intx(pdev, res->orig_intx); + pci_intx_unmanaged(pdev, res->orig_intx); } static struct pcim_intx_devres *get_or_create_intx_devres(struct device *dev) @@ -472,10 +453,11 @@ int pcim_intx(struct pci_dev *pdev, int enable) return -ENOMEM; res->orig_intx = !enable; - __pcim_intx(pdev, enable); + pci_intx_unmanaged(pdev, enable); return 0; } +EXPORT_SYMBOL_GPL(pcim_intx); static void pcim_disable_device(void *pdev_raw) { diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 0b29ec6e8e5e..30d17ec771fc 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -4482,6 +4482,35 @@ void pci_disable_parity(struct pci_dev *dev) } } +/** + * pci_intx_unmanaged - enables/disables PCI INTx for device dev, + * unmanaged version + * @pdev: the PCI device to operate on + * @enable: boolean: whether to enable or disable PCI INTx + * + * Enables/disables PCI INTx for device @pdev + * + * This function behavios identically to pci_intx(), but is never managed with + * devres. + */ +void pci_intx_unmanaged(struct pci_dev *pdev, int enable) +{ + u16 pci_command, new; + + pci_read_config_word(pdev, PCI_COMMAND, &pci_command); + + if (enable) + new = pci_command & ~PCI_COMMAND_INTX_DISABLE; + else + new = pci_command | PCI_COMMAND_INTX_DISABLE; + + if (new == pci_command) + return; + + pci_write_config_word(pdev, PCI_COMMAND, new); +} +EXPORT_SYMBOL_GPL(pci_intx_unmanaged); + /** * pci_intx - enables/disables PCI INTx for device dev * @pdev: the PCI device to operate on diff --git a/include/linux/pci.h b/include/linux/pci.h index db9b47ce3eef..b5eb8bda655d 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -1350,6 +1350,7 @@ int __must_check pcim_set_mwi(struct pci_dev *dev); int pci_try_set_mwi(struct pci_dev *dev); void pci_clear_mwi(struct pci_dev *dev); void pci_disable_parity(struct pci_dev *dev); +void pci_intx_unmanaged(struct pci_dev *pdev, int enable); void pci_intx(struct pci_dev *dev, int enable); bool pci_check_and_mask_intx(struct pci_dev *dev); bool pci_check_and_unmask_intx(struct pci_dev *dev); @@ -2297,6 +2298,7 @@ static inline void pci_fixup_device(enum pci_fixup_pass pass, struct pci_dev *dev) { } #endif +int pcim_intx(struct pci_dev *pdev, int enabled); int pcim_request_all_regions(struct pci_dev *pdev, const char *name); void __iomem *pcim_iomap(struct pci_dev *pdev, int bar, unsigned long maxlen); void __iomem *pcim_iomap_region(struct pci_dev *pdev, int bar, -- 2.47.1 From xen-devel-bounces@lists.xenproject.org Mon Dec 09 13:07:05 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 13:07:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851190.1265335 (Exim 4.92) (envelope-from ) id 1tKdTa-0001OA-HD; Mon, 09 Dec 2024 13:07:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851190.1265335; Mon, 09 Dec 2024 13: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 1tKdTa-0001Nz-EU; Mon, 09 Dec 2024 13:07:02 +0000 Received: by outflank-mailman (input) for mailman id 851190; Mon, 09 Dec 2024 13:07: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 1tKdTY-0000ch-Qn for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 13:07:00 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 78c5d02a-b62e-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 14:06:59 +0100 (CET) Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-113-i5JWUEMzO_issIoAJnJZig-1; Mon, 09 Dec 2024 08:06:56 -0500 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-434f47b0512so8002065e9.2 for ; Mon, 09 Dec 2024 05:06:56 -0800 (PST) Received: from eisenberg.redhat.com (nat-pool-muc-u.redhat.com. [149.14.88.27]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3862190965asm13200127f8f.82.2024.12.09.05.06.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2024 05:06: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: 78c5d02a-b62e-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733749618; 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=jVrHbQL/WtPUoVmg5iNOH6KPahEUlaDR0JYKoVLlaPE=; b=Fl0gD+S2thj/enHGWj1pLgTFSpSEagOMA/IAiOiFDBLpTIz/3DKEj6VO6Fq3OSifenkhGZ 0G6LVjMTW236fCuD0I6EMfwcVkkllQedkYIU2fwLFbTyyV+zNIE005udKqHN8lBDL8MUPQ 2E7d2CSFFh3xzB9gJsp7D3YMtRGiOl4= X-MC-Unique: i5JWUEMzO_issIoAJnJZig-1 X-Mimecast-MFC-AGG-ID: i5JWUEMzO_issIoAJnJZig X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733749615; x=1734354415; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jVrHbQL/WtPUoVmg5iNOH6KPahEUlaDR0JYKoVLlaPE=; b=gNsOB2IfARxHihQA4rybYJFltEvXDRBnPRVbYr75wWsZssDwQiRz0gBL3vOKCdw402 xRetAlX5XxQ7hlCaFJi+Es5mOfLAsGrRwOkh+U7B3tmG21QRKYvmd052FJW9LnoHOZY8 JTpYLx5CJ8bapIkF916W5V9rlBUpynVAWS+CSB86d3G0VDvb1F2kaIDJAz+EUNzeo461 BHng4aatJzMK95ghkZaGYznbPVXvK8+pUj+DCN3w5ufgU2lVhp6dYqy9nVWh/lpb5t+w 9PjgYOopMO74NW2kVLtbyaWWZ4VNb+qpKeMxovq9xzhk00pS8uKnOVwxR1qYEbS2XyQJ qrpA== X-Forwarded-Encrypted: i=1; AJvYcCXVGBMsMS10SHHuEafrfMrroz4SDCneGhKFIQvSgnPMB0qnWWcW3Rcfd0ug7/9KUMONIb16db6x8MQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YwUXbRulNIFMSa87Sdx9/IFrb5/e5Q4bL5ArZxNhLW9bthUjxUn 6sir2wOIeblMcW2vKHiUCNxqHadZA3mZlbyOBCJGlSamH4C9X8ZZW+cdepoQ6Tz9eRejJVLQXaI xAaFn1zcSA8dBaeC1ypmE/H8PSt2ZlDyI89H1kxgMxgT+dH72nKtvWvJD9o6mivls X-Gm-Gg: ASbGncvfz5+YZG13GPmruyVfi7Ytg+daF5blbP+IYt64bf6mehH6jIZeasXXDi/9SdG JRoY46iMF1JmTQL8eTBwL4aQrQ4GasN6O4cIBQs6nG1bgMg83xTZo2SPznTQWn22Kv7r9FXYTPh b6rnimnbhFCsnuoA4sUDeqEX5KWYf+PeE12lLvvuErCmdCpArhXa8yPsng8nF5mYLcCjmi/njc2 zs+EUuBjDFDOIZZjg6jH2BQvpvWNVYPv7BXIjXeYJFllS7Bs4oRCnL0srr4VWsH9qCOX4qPVE7v rOrvsJtO X-Received: by 2002:a05:600c:3544:b0:431:60ec:7a91 with SMTP id 5b1f17b1804b1-434ddeade70mr103095365e9.2.1733749615454; Mon, 09 Dec 2024 05:06:55 -0800 (PST) X-Google-Smtp-Source: AGHT+IG8dWBtsXMwPpsQh4FEW+o80sVo3gsVutdK8rZwCICXTNWn24DfDXUekpZhDfdomYwt5/+rkA== X-Received: by 2002:a05:600c:3544:b0:431:60ec:7a91 with SMTP id 5b1f17b1804b1-434ddeade70mr103094435e9.2.1733749614932; Mon, 09 Dec 2024 05:06:54 -0800 (PST) From: Philipp Stanner To: amien Le Moal , Niklas Cassel , Basavaraj Natikar , Jiri Kosina , Benjamin Tissoires , Arnd Bergmann , Greg Kroah-Hartman , Alex Dubov , Sudarsana Kalluru , Manish Chopra , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rasesh Mody , GR-Linux-NIC-Dev@marvell.com, Igor Mitsyanko , Sergey Matyukevich , Kalle Valo , Sanjay R Mehta , Shyam Sundar S K , Jon Mason , Dave Jiang , Allen Hubbe , Bjorn Helgaas , Alex Williamson , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Mario Limonciello , Chen Ni , Philipp Stanner , Ricky Wu , Al Viro , Breno Leitao , Thomas Gleixner , Kevin Tian , Andy Shevchenko , Mostafa Saleh , Jason Gunthorpe , Yi Liu , Kunwu Chan , Dan Carpenter , "Dr. David Alan Gilbert" , Ankit Agrawal , Reinette Chatre , Eric Auger , Ye Bin Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, ntb@lists.linux.dev, linux-pci@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Subject: [PATCH v3 04/11] net/ntb: Use never-managed version of pci_intx() Date: Mon, 9 Dec 2024 14:06:26 +0100 Message-ID: <20241209130632.132074-6-pstanner@redhat.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20241209130632.132074-2-pstanner@redhat.com> References: <20241209130632.132074-2-pstanner@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: FYlxY7uDdRJU2zmEYf023vX2f6xofWfouOB7XjsLfiQ_1733749616 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true pci_intx() is a hybrid function which can sometimes be managed through devres. To remove this hybrid nature from pci_intx(), it is necessary to port users to either an always-managed or a never-managed version. hw/amd and how/intel enable their PCI-Device with pci_enable_device(). Thus, they need the never-managed version. Replace pci_intx() with pci_intx_unmanaged(). Signed-off-by: Philipp Stanner Acked-by: Shyam Sundar S K #for ntb_hw_amd.c Acked-by: Dave Jiang # for ntb_hw_gen1.c --- drivers/ntb/hw/amd/ntb_hw_amd.c | 4 ++-- drivers/ntb/hw/intel/ntb_hw_gen1.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c index d687e8c2cc78..b146f170e839 100644 --- a/drivers/ntb/hw/amd/ntb_hw_amd.c +++ b/drivers/ntb/hw/amd/ntb_hw_amd.c @@ -791,7 +791,7 @@ static int ndev_init_isr(struct amd_ntb_dev *ndev, err_msi_enable: /* Try to set up intx irq */ - pci_intx(pdev, 1); + pci_intx_unmanaged(pdev, 1); rc = request_irq(pdev->irq, ndev_irq_isr, IRQF_SHARED, "ndev_irq_isr", ndev); @@ -831,7 +831,7 @@ static void ndev_deinit_isr(struct amd_ntb_dev *ndev) if (pci_dev_msi_enabled(pdev)) pci_disable_msi(pdev); else - pci_intx(pdev, 0); + pci_intx_unmanaged(pdev, 0); } } diff --git a/drivers/ntb/hw/intel/ntb_hw_gen1.c b/drivers/ntb/hw/intel/ntb_hw_gen1.c index 079b8cd79785..9ad9d7fe227e 100644 --- a/drivers/ntb/hw/intel/ntb_hw_gen1.c +++ b/drivers/ntb/hw/intel/ntb_hw_gen1.c @@ -445,7 +445,7 @@ int ndev_init_isr(struct intel_ntb_dev *ndev, /* Try to set up intx irq */ - pci_intx(pdev, 1); + pci_intx_unmanaged(pdev, 1); rc = request_irq(pdev->irq, ndev_irq_isr, IRQF_SHARED, "ndev_irq_isr", ndev); -- 2.47.1 From xen-devel-bounces@lists.xenproject.org Mon Dec 09 13:07:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 13:07:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851191.1265347 (Exim 4.92) (envelope-from ) id 1tKdTd-0001j3-Sg; Mon, 09 Dec 2024 13:07:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851191.1265347; Mon, 09 Dec 2024 13:07: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 1tKdTd-0001iq-Mv; Mon, 09 Dec 2024 13:07:05 +0000 Received: by outflank-mailman (input) for mailman id 851191; Mon, 09 Dec 2024 13:07: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 1tKdTb-0000ch-Ue for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 13:07:03 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7b3b88d6-b62e-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 14:07:03 +0100 (CET) Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-361-VorUt1UHNKeLt_5llKv9cA-1; Mon, 09 Dec 2024 08:07:01 -0500 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-385dcadffebso865060f8f.0 for ; Mon, 09 Dec 2024 05:07:00 -0800 (PST) Received: from eisenberg.redhat.com (nat-pool-muc-u.redhat.com. [149.14.88.27]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3862190965asm13200127f8f.82.2024.12.09.05.06.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2024 05:06: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: 7b3b88d6-b62e-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733749622; 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=J6O49TnPkNeMtIPoWkV2XdJjg3ziNzZQ3FlPq3drZuU=; b=ZMPrH0El9WXhGOxw0fW4XhShln57ftb7xbRSlGkLqeF1GR8+JmtAdxyBg2d89usufnZ69H RGAFkpaKKt52ugrmLBsTA/QM58pCS5RLfQT1eaqLw7C0cdkfaVJcPkXqdiH+9kAecvgxho Zw2tFH2NuVNgYuGyHJFP0mr6U8JxUE8= X-MC-Unique: VorUt1UHNKeLt_5llKv9cA-1 X-Mimecast-MFC-AGG-ID: VorUt1UHNKeLt_5llKv9cA X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733749620; x=1734354420; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=J6O49TnPkNeMtIPoWkV2XdJjg3ziNzZQ3FlPq3drZuU=; b=d20SdWIRx+5ScS531ktqOcaW9EaO9SF9uG0ipBtgzKtUBU2ACVm48H6SRnh+Tmd9oq Q0W+mPwNKAGeQbrwbF0+yhFkpnitExoLSdn1Qb+cD5/Q8OH7hPx6Ux6cCGisg34ZIiiF XmHtuvWymxiPoIwsQpbq///LufIlboToNkTeaRP7Quhva1z3aMG4t35vnXZ54+ZLUlpD Vn+EGtbmFdUQO43AIh1hTcEJD1p4sxN41RcfdJgLfU3VtdJVhkgWRN1dkgS542ahkWMp RpcW3yyFI6fxLHo4G+B0+WMFoy7Da4t57TFPlgi9GWosiEGm5dvOOEBeMw7MoHoIfspr ssYQ== X-Forwarded-Encrypted: i=1; AJvYcCXYu7wjrRbFfhcI3aEdnLe0U+4K4gD+38WT63R38aDLYGj4KXYeVN04eOL8zeQqPder6ablloI7k8I=@lists.xenproject.org X-Gm-Message-State: AOJu0YxGFtq13XoBeE6OqhL7oBZTCb7gbBTEmFCr9OW2TA2H5S2FwkuJ z5p3fpyrVA6kjT+tiAwpGlDLlqgmOUEGKWtC5k1Lu/Y1qGaTYjIMHOv+P6ZNus54Ty19SdvUyu4 2X5iMuyP5mQW019DyY8yV6UQngO6PoavuNOL4j28TkhrX4Jvtm6yUO20ptRwi3MWV X-Gm-Gg: ASbGncsmc9hQlJq2Syk15CNsQnuTG7VRI4K5xbJ6QhsAnnmEBd/skGnGcHqvjeQkw9w RNaGJ/eTCS9soxobyTbvvThBp4+Fi+qGB35WL2Lkjm2m/kJJaE2YuwljfUIgTDDDJg1Iebm4LSE glj6xsfk6D8/XIRYh6otXnzNdeLSJsuhiu/X5sq3UoIsiuGrCmv9ak4Jbb2xTX05/NRE7dqK83s Je4k5gtlUlPcleScQ5eovVoZArEHuA8rHsv7LryfTXmG4rw9OgXXyUR2M1oK7UiLTF+KxHLzsd2 1/b2zAOM X-Received: by 2002:a05:6000:481d:b0:386:1cd3:8a05 with SMTP id ffacd0b85a97d-38645402350mr183799f8f.54.1733749619736; Mon, 09 Dec 2024 05:06:59 -0800 (PST) X-Google-Smtp-Source: AGHT+IEtkNHnOC202GyBKEBPTwiG4UTLfJs2pkouVC4IktFgJYuC2xwE//LEhilVtJ79VvBlgBAiYw== X-Received: by 2002:a05:6000:481d:b0:386:1cd3:8a05 with SMTP id ffacd0b85a97d-38645402350mr183738f8f.54.1733749619256; Mon, 09 Dec 2024 05:06:59 -0800 (PST) From: Philipp Stanner To: amien Le Moal , Niklas Cassel , Basavaraj Natikar , Jiri Kosina , Benjamin Tissoires , Arnd Bergmann , Greg Kroah-Hartman , Alex Dubov , Sudarsana Kalluru , Manish Chopra , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rasesh Mody , GR-Linux-NIC-Dev@marvell.com, Igor Mitsyanko , Sergey Matyukevich , Kalle Valo , Sanjay R Mehta , Shyam Sundar S K , Jon Mason , Dave Jiang , Allen Hubbe , Bjorn Helgaas , Alex Williamson , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Mario Limonciello , Chen Ni , Philipp Stanner , Ricky Wu , Al Viro , Breno Leitao , Thomas Gleixner , Kevin Tian , Andy Shevchenko , Mostafa Saleh , Jason Gunthorpe , Yi Liu , Kunwu Chan , Dan Carpenter , "Dr. David Alan Gilbert" , Ankit Agrawal , Reinette Chatre , Eric Auger , Ye Bin Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, ntb@lists.linux.dev, linux-pci@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Subject: [PATCH v3 06/11] vfio/pci: Use never-managed version of pci_intx() Date: Mon, 9 Dec 2024 14:06:28 +0100 Message-ID: <20241209130632.132074-8-pstanner@redhat.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20241209130632.132074-2-pstanner@redhat.com> References: <20241209130632.132074-2-pstanner@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: OejXA53lW106SfX-Ga5FPGYnABT84rBGhxPuyjq_VME_1733749620 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true pci_intx() is a hybrid function which can sometimes be managed through devres. To remove this hybrid nature from pci_intx(), it is necessary to port users to either an always-managed or a never-managed version. vfio enables its PCI-Device with pci_enable_device(). Thus, it needs the never-managed version. Replace pci_intx() with pci_intx_unmanaged(). Signed-off-by: Philipp Stanner --- drivers/vfio/pci/vfio_pci_core.c | 2 +- drivers/vfio/pci/vfio_pci_intrs.c | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c index 1ab58da9f38a..90240c8d51aa 100644 --- a/drivers/vfio/pci/vfio_pci_core.c +++ b/drivers/vfio/pci/vfio_pci_core.c @@ -498,7 +498,7 @@ int vfio_pci_core_enable(struct vfio_pci_core_device *vdev) if (vfio_pci_nointx(pdev)) { pci_info(pdev, "Masking broken INTx support\n"); vdev->nointx = true; - pci_intx(pdev, 0); + pci_intx_unmanaged(pdev, 0); } else vdev->pci_2_3 = pci_intx_mask_supported(pdev); } diff --git a/drivers/vfio/pci/vfio_pci_intrs.c b/drivers/vfio/pci/vfio_pci_intrs.c index 8382c5834335..40abb0b937a2 100644 --- a/drivers/vfio/pci/vfio_pci_intrs.c +++ b/drivers/vfio/pci/vfio_pci_intrs.c @@ -118,7 +118,7 @@ static bool __vfio_pci_intx_mask(struct vfio_pci_core_device *vdev) */ if (unlikely(!is_intx(vdev))) { if (vdev->pci_2_3) - pci_intx(pdev, 0); + pci_intx_unmanaged(pdev, 0); goto out_unlock; } @@ -132,7 +132,7 @@ static bool __vfio_pci_intx_mask(struct vfio_pci_core_device *vdev) * mask, not just when something is pending. */ if (vdev->pci_2_3) - pci_intx(pdev, 0); + pci_intx_unmanaged(pdev, 0); else disable_irq_nosync(pdev->irq); @@ -178,7 +178,7 @@ static int vfio_pci_intx_unmask_handler(void *opaque, void *data) */ if (unlikely(!is_intx(vdev))) { if (vdev->pci_2_3) - pci_intx(pdev, 1); + pci_intx_unmanaged(pdev, 1); goto out_unlock; } @@ -296,7 +296,7 @@ static int vfio_intx_enable(struct vfio_pci_core_device *vdev, */ ctx->masked = vdev->virq_disabled; if (vdev->pci_2_3) { - pci_intx(pdev, !ctx->masked); + pci_intx_unmanaged(pdev, !ctx->masked); irqflags = IRQF_SHARED; } else { irqflags = ctx->masked ? IRQF_NO_AUTOEN : 0; @@ -569,7 +569,7 @@ static void vfio_msi_disable(struct vfio_pci_core_device *vdev, bool msix) * via their shutdown paths. Restore for NoINTx devices. */ if (vdev->nointx) - pci_intx(pdev, 0); + pci_intx_unmanaged(pdev, 0); vdev->irq_type = VFIO_PCI_NUM_IRQS; } -- 2.47.1 From xen-devel-bounces@lists.xenproject.org Mon Dec 09 13:07:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 13:07:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851196.1265356 (Exim 4.92) (envelope-from ) id 1tKdTh-00026A-CM; Mon, 09 Dec 2024 13:07:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851196.1265356; Mon, 09 Dec 2024 13:07: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 1tKdTh-00025x-7B; Mon, 09 Dec 2024 13:07:09 +0000 Received: by outflank-mailman (input) for mailman id 851196; Mon, 09 Dec 2024 13:07: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 1tKdTg-0000OS-8l for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 13:07:08 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7d204215-b62e-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 14:07:06 +0100 (CET) Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-562-W9DMkNCnNM6IcveM0LyOzw-1; Mon, 09 Dec 2024 08:06:58 -0500 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-385df115288so1806905f8f.2 for ; Mon, 09 Dec 2024 05:06:58 -0800 (PST) Received: from eisenberg.redhat.com (nat-pool-muc-u.redhat.com. [149.14.88.27]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3862190965asm13200127f8f.82.2024.12.09.05.06.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2024 05:06:56 -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: 7d204215-b62e-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733749625; 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=iGrvh/xDUNx0Zym0wN3Xe7A7dJtO5ZhSWVvmuSF27ww=; b=Z5+FKy7ioJjd8a8u3GNDGGSVChuU+Ji3ernXFZ5vODPI/JynNHeat5aeykaVEkoYK4SWQq YCqrzsCjamKy2JkM1ClyQvj/viB+BRPGuRnEjZu30nTJUIPngVk3hyENQoYcMycZ+rqfcu 4Z7F5FYHyyXM0HPXvivgNbzJtWom/CQ= X-MC-Unique: W9DMkNCnNM6IcveM0LyOzw-1 X-Mimecast-MFC-AGG-ID: W9DMkNCnNM6IcveM0LyOzw X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733749617; x=1734354417; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=iGrvh/xDUNx0Zym0wN3Xe7A7dJtO5ZhSWVvmuSF27ww=; b=gHJcg0AUcHUT4pzhzzyWpHPS7YoqicnkTqyRSLhudJuHydRvLWb77aeYgXodt4POoh xbotmjNoDt3I4NNKVrpw4CjxW5TI5N7/RFPwrlUE24YGvSox0OB7+Kx65O3wBXVkDJvj uq01klZTsjbdnAcXOQ/nVoCx0E1/PoJQsoZIoKBetNL7QhbY1LqnlvLroFjl/nIO5O0U 302bhKOkM/01RT2Btp2W/xdA/Edlz6W9p3v1b/IiM1N8uiMEYW7b1X3l3hldfOtFkqZT DCITgnFedYLpFC/cgHujN3h8L4ywAfJmlyhkkwyqAm9FPBuA9GLeRA9w+9WkLZH6oWIf l2yw== X-Forwarded-Encrypted: i=1; AJvYcCW+h0Dl2B4y/+XRvfewGq0u1GWpZSWjPkTxl1jhAibXqWdyiaeIzTJseONmsYzV03sRwHGlA1UZuW8=@lists.xenproject.org X-Gm-Message-State: AOJu0YwROzCNlnSamZGR9myCRMKMBQDN1GL4RRuHf5DE+OoS6v5Co+MT H7Xsjsj7bywYu1FyLuCqUFUw7BjshYpYLtAbooI4nehNCwXOzmeIys+cKdFK/G+OG44u09IuZEE af1cT0XyJTdel00w3YjJXNzIYb6D968lObMdcvzXf+/pBHZvDrSUJsHcf9CJXS5cy X-Gm-Gg: ASbGnctOoXd7Grr6ot/DRWrcUeADDNjPvVGTLhqoCOPZfmd29OnRokksnTnXDv/lrT1 v0nbwPO8mNaAMXe9/WH7orG7akaK1YEHg310iC1uJUG8+RoBU3e6YnIJHZrgV6AuOiUovfmnKI0 k0s7muy7LbTB4UZxHu7X/qOancvqPKe7kNOUMtFLzZZclE5HenryJDapeG458Mu9htFuA3aOHR5 DRZS7L9IJHZBgOeP+KpGSY3fvqb/dDDMBJGjUCTKRRGSK1TjlLSN2jFt8oZd7ArVO1mKQZp1S06 G9ok+ZeN X-Received: by 2002:a5d:47c9:0:b0:385:db11:badf with SMTP id ffacd0b85a97d-386453d6c46mr225651f8f.22.1733749617417; Mon, 09 Dec 2024 05:06:57 -0800 (PST) X-Google-Smtp-Source: AGHT+IF+w+VXnhTGgYCQrqoxE7Q0eQycE2/xL59lBRJp9LXmIJ3oiAACyABfaofCQ1IoSgKVucKxLg== X-Received: by 2002:a5d:47c9:0:b0:385:db11:badf with SMTP id ffacd0b85a97d-386453d6c46mr225568f8f.22.1733749616959; Mon, 09 Dec 2024 05:06:56 -0800 (PST) From: Philipp Stanner To: amien Le Moal , Niklas Cassel , Basavaraj Natikar , Jiri Kosina , Benjamin Tissoires , Arnd Bergmann , Greg Kroah-Hartman , Alex Dubov , Sudarsana Kalluru , Manish Chopra , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rasesh Mody , GR-Linux-NIC-Dev@marvell.com, Igor Mitsyanko , Sergey Matyukevich , Kalle Valo , Sanjay R Mehta , Shyam Sundar S K , Jon Mason , Dave Jiang , Allen Hubbe , Bjorn Helgaas , Alex Williamson , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Mario Limonciello , Chen Ni , Philipp Stanner , Ricky Wu , Al Viro , Breno Leitao , Thomas Gleixner , Kevin Tian , Andy Shevchenko , Mostafa Saleh , Jason Gunthorpe , Yi Liu , Kunwu Chan , Dan Carpenter , "Dr. David Alan Gilbert" , Ankit Agrawal , Reinette Chatre , Eric Auger , Ye Bin Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, ntb@lists.linux.dev, linux-pci@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Subject: [PATCH v3 05/11] misc: Use never-managed version of pci_intx() Date: Mon, 9 Dec 2024 14:06:27 +0100 Message-ID: <20241209130632.132074-7-pstanner@redhat.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20241209130632.132074-2-pstanner@redhat.com> References: <20241209130632.132074-2-pstanner@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: rogXN74MqKl5dDgRxmQ7IPX_Ruvc0sue5YY4JdVmxqI_1733749617 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true pci_intx() is a hybrid function which can sometimes be managed through devres. To remove this hybrid nature from pci_intx(), it is necessary to port users to either an always-managed or a never-managed version. cardreader/rtsx_pcr.c and tifm_7xx1.c enable their PCI-Device with pci_enable_device(). Thus, they need the never-managed version. Replace pci_intx() with pci_intx_unmanaged(). Signed-off-by: Philipp Stanner --- drivers/misc/cardreader/rtsx_pcr.c | 2 +- drivers/misc/tifm_7xx1.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/misc/cardreader/rtsx_pcr.c b/drivers/misc/cardreader/rtsx_pcr.c index be3d4e0e50cc..e25e6d560dd7 100644 --- a/drivers/misc/cardreader/rtsx_pcr.c +++ b/drivers/misc/cardreader/rtsx_pcr.c @@ -1057,7 +1057,7 @@ static int rtsx_pci_acquire_irq(struct rtsx_pcr *pcr) } pcr->irq = pcr->pci->irq; - pci_intx(pcr->pci, !pcr->msi_en); + pci_intx_unmanaged(pcr->pci, !pcr->msi_en); return 0; } diff --git a/drivers/misc/tifm_7xx1.c b/drivers/misc/tifm_7xx1.c index 1d54680d6ed2..5f9c7ccae8d2 100644 --- a/drivers/misc/tifm_7xx1.c +++ b/drivers/misc/tifm_7xx1.c @@ -327,7 +327,7 @@ static int tifm_7xx1_probe(struct pci_dev *dev, goto err_out; } - pci_intx(dev, 1); + pci_intx_unmanaged(dev, 1); fm = tifm_alloc_adapter(dev->device == PCI_DEVICE_ID_TI_XX21_XX11_FM ? 4 : 2, &dev->dev); @@ -368,7 +368,7 @@ static int tifm_7xx1_probe(struct pci_dev *dev, err_out_free: tifm_free_adapter(fm); err_out_int: - pci_intx(dev, 0); + pci_intx_unmanaged(dev, 0); pci_release_regions(dev); err_out: if (!pci_dev_busy) @@ -392,7 +392,7 @@ static void tifm_7xx1_remove(struct pci_dev *dev) tifm_7xx1_sock_power_off(tifm_7xx1_sock_addr(fm->addr, cnt)); iounmap(fm->addr); - pci_intx(dev, 0); + pci_intx_unmanaged(dev, 0); pci_release_regions(dev); pci_disable_device(dev); -- 2.47.1 From xen-devel-bounces@lists.xenproject.org Mon Dec 09 13:07:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 13:07:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851199.1265366 (Exim 4.92) (envelope-from ) id 1tKdTj-0002TY-LM; Mon, 09 Dec 2024 13:07:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851199.1265366; Mon, 09 Dec 2024 13:07: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 1tKdTj-0002TG-Gh; Mon, 09 Dec 2024 13:07:11 +0000 Received: by outflank-mailman (input) for mailman id 851199; Mon, 09 Dec 2024 13:07: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 1tKdTi-0000OS-8q for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 13:07:10 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7dcbea3c-b62e-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 14:07:07 +0100 (CET) Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-648-TAmSbDjWOA-EQIgmb-aQFA-1; Mon, 09 Dec 2024 08:07:03 -0500 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-385e03f54d0so1754316f8f.3 for ; Mon, 09 Dec 2024 05:07:02 -0800 (PST) Received: from eisenberg.redhat.com (nat-pool-muc-u.redhat.com. [149.14.88.27]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3862190965asm13200127f8f.82.2024.12.09.05.06.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2024 05:07: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: 7dcbea3c-b62e-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733749626; 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=oiILKR2a3QjvArtxAPrSG5MTRD3aI59eir0l7Eg71/Q=; b=eUs8Rv4TbziekXVV36RNSDyOsZlArC5rtz6d9u9rQoFTG+vS4M9tDgeorAfJWvQm6ptea1 bfgeURj/kezC2d8gbgNDqu2Rz72woxZmo9z+EsboN5RX/pbVl4nWJdOq73gRxyRKBuRH9V yG3+IbPi9adgB3f5N3QuLnCNAcmIwjg= X-MC-Unique: TAmSbDjWOA-EQIgmb-aQFA-1 X-Mimecast-MFC-AGG-ID: TAmSbDjWOA-EQIgmb-aQFA X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733749622; x=1734354422; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oiILKR2a3QjvArtxAPrSG5MTRD3aI59eir0l7Eg71/Q=; b=BiE2fl5L+PP6SALSEb4yf43I1cDcZZoxeDT60sZU5I87w+h59SLDh2dJ1LHjf4FgPw vQTxEBBvR0lj9wIlLVck7wV9+VCm6gCMeaPdqYO4BYscIpTcvarl6QaMwVa5a3wq2k9k JcJ4os4QlvpOD74cXVrDb3zibmwUsSiN17Eb9p8PZuPlAv9dkZhoHWAZxZI8iMRGCbRv CqJLHJaG+Ju7HjusElt1u0vv79ht1ofqO348j3HjUpudJ3anpOTJFFJUsT1cFvnhfDaJ ul9CT87lRjS1jbEp2B1MzSupqS4HCvv4NjTlpFnw9r6Wo67xjTig7kMFZ8/knpQdYaub qEqQ== X-Forwarded-Encrypted: i=1; AJvYcCVtqZeDxZ+8fxiXM8YAV6OgxnviWMsAzZ6VpFfhGWohoL1C2UIf80+FXLMqLXbevfmiQ4Te0aMjTGU=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx2ZPAjIbe2bMvcF//P1cSQXcTHnh8rY+3KlVB+mM9bGVfXIbNP Y6c7Q+cvEKJjW9l1MnwGbx29ReqOlr7LCkz19E6AL9dxMfZxMAB7tTFAAOwTVb8nTeWqScqJRvf 4pZG81WaCHUMNXiasGD2d9jA61k/VNNbiyiNoeRXh3mum3J1WXd9uY1LYiXEgRYL+ X-Gm-Gg: ASbGncvJJFznai54yBWT/jdmJkZNd75dRDYcEWJCtOp0ub5xJ2uQxoO3XIquiHHJv5O vk2o0visIu1J2lxCvonk87GmUoHVDIyPkK4SvbzmvCYfrTnoo9d/Cwg9JDb1jZ+NSRPyOHjEOqh OnUzxM6+G+ul51SydeWQbDaj1d6Nfjijb4Ek99N8s686dOkbPFnaQm0lVLXD3VgF3n7oTOostTi JcmlKsbWxm7kTJHVpEd/yiQXNTbtNfxZOUSBwwOaCjnmrCPAHf3tJTzUncXC9F4q47Bs8Q95PxU y1JZqzgB X-Received: by 2002:adf:e18a:0:b0:385:e3b8:f331 with SMTP id ffacd0b85a97d-3862b355ed9mr8982755f8f.14.1733749621852; Mon, 09 Dec 2024 05:07:01 -0800 (PST) X-Google-Smtp-Source: AGHT+IFEcWIoVaHlqXXOi6I/o8U0Sx4v85WRQCbXdmf3r6S4bXIGyWlICGFsXbMo+gcSn1pLdSeKWw== X-Received: by 2002:adf:e18a:0:b0:385:e3b8:f331 with SMTP id ffacd0b85a97d-3862b355ed9mr8982697f8f.14.1733749621414; Mon, 09 Dec 2024 05:07:01 -0800 (PST) From: Philipp Stanner To: amien Le Moal , Niklas Cassel , Basavaraj Natikar , Jiri Kosina , Benjamin Tissoires , Arnd Bergmann , Greg Kroah-Hartman , Alex Dubov , Sudarsana Kalluru , Manish Chopra , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rasesh Mody , GR-Linux-NIC-Dev@marvell.com, Igor Mitsyanko , Sergey Matyukevich , Kalle Valo , Sanjay R Mehta , Shyam Sundar S K , Jon Mason , Dave Jiang , Allen Hubbe , Bjorn Helgaas , Alex Williamson , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Mario Limonciello , Chen Ni , Philipp Stanner , Ricky Wu , Al Viro , Breno Leitao , Thomas Gleixner , Kevin Tian , Andy Shevchenko , Mostafa Saleh , Jason Gunthorpe , Yi Liu , Kunwu Chan , Dan Carpenter , "Dr. David Alan Gilbert" , Ankit Agrawal , Reinette Chatre , Eric Auger , Ye Bin Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, ntb@lists.linux.dev, linux-pci@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Subject: [PATCH v3 07/11] PCI: MSI: Use never-managed version of pci_intx() Date: Mon, 9 Dec 2024 14:06:29 +0100 Message-ID: <20241209130632.132074-9-pstanner@redhat.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20241209130632.132074-2-pstanner@redhat.com> References: <20241209130632.132074-2-pstanner@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: mcadjiQ_Y4gVOF9CqH3DI3k7t95Y-5oJv_VqqFlxR14_1733749622 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true pci_intx() is a hybrid function which can sometimes be managed through devres. To remove this hybrid nature from pci_intx(), it is necessary to port users to either an always-managed or a never-managed version. MSI sets up its own separate devres callback implicitly in pcim_setup_msi_release(). This callback ultimately uses pci_intx(), which is problematic since the callback of course runs on driver-detach. That problem has last been described here: https://lore.kernel.org/all/ee44ea7ac760e73edad3f20b30b4d2fff66c1a85.camel@redhat.com/ Replace the call to pci_intx() with one to the never-managed version pci_intx_unmanaged(). Signed-off-by: Philipp Stanner Reviewed-by: Thomas Gleixner --- drivers/pci/msi/api.c | 2 +- drivers/pci/msi/msi.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pci/msi/api.c b/drivers/pci/msi/api.c index b956ce591f96..c95e2e7dc9ab 100644 --- a/drivers/pci/msi/api.c +++ b/drivers/pci/msi/api.c @@ -289,7 +289,7 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs, */ if (affd) irq_create_affinity_masks(1, affd); - pci_intx(dev, 1); + pci_intx_unmanaged(dev, 1); return 1; } } diff --git a/drivers/pci/msi/msi.c b/drivers/pci/msi/msi.c index 3a45879d85db..53f13b09db50 100644 --- a/drivers/pci/msi/msi.c +++ b/drivers/pci/msi/msi.c @@ -268,7 +268,7 @@ EXPORT_SYMBOL_GPL(pci_write_msi_msg); static void pci_intx_for_msi(struct pci_dev *dev, int enable) { if (!(dev->dev_flags & PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG)) - pci_intx(dev, enable); + pci_intx_unmanaged(dev, enable); } static void pci_msi_set_enable(struct pci_dev *dev, int enable) -- 2.47.1 From xen-devel-bounces@lists.xenproject.org Mon Dec 09 13:07:12 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 13:07:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851200.1265371 (Exim 4.92) (envelope-from ) id 1tKdTk-0002X7-17; Mon, 09 Dec 2024 13:07:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851200.1265371; Mon, 09 Dec 2024 13:07: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 1tKdTj-0002WQ-Rw; Mon, 09 Dec 2024 13:07:11 +0000 Received: by outflank-mailman (input) for mailman id 851200; Mon, 09 Dec 2024 13:07: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 1tKdTi-0000ch-Kj for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 13:07:10 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7f3dac26-b62e-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 14:07:10 +0100 (CET) Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-56-IgpqTL54MBeCdSRbIwd3BA-1; Mon, 09 Dec 2024 08:07:07 -0500 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-3861cd03a89so1764675f8f.1 for ; Mon, 09 Dec 2024 05:07:07 -0800 (PST) Received: from eisenberg.redhat.com (nat-pool-muc-u.redhat.com. [149.14.88.27]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3862190965asm13200127f8f.82.2024.12.09.05.07.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2024 05:07:05 -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: 7f3dac26-b62e-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733749628; 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=QrzFiyozzKwphrmER/QLBGC9UXhx6Rbz0xOMvDA9uiM=; b=YmWQ6iKCwI3+3rUQkJ6JMqQOz5ieCLFkktJvs5VRw9t5MIcph5sZF+kuysSoNRhgITxqDV J+TF7DK+cacr44n9J5nDKKAqWFJVmoct8+8AsS5BOGKAeVk0EltnLlAxOncBJoHVgSyqFz qH7Z8Pvh9oCvATd5ibX9yO3BILxOEl8= X-MC-Unique: IgpqTL54MBeCdSRbIwd3BA-1 X-Mimecast-MFC-AGG-ID: IgpqTL54MBeCdSRbIwd3BA X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733749626; x=1734354426; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QrzFiyozzKwphrmER/QLBGC9UXhx6Rbz0xOMvDA9uiM=; b=SiONKch5O4kXiaQ5Gwdl469aUJ+tyAlPqGQtE3+QHaRYbScVucmGs2/S0lscKkfyHX 1fe3G34LtflX7zSMINX+wRBy+HaylHqBcmGX9FziK4n5BB3YohArjoiK2gk/anM7vM/w LJAv1aRjFsNpsPLcNHR96qTScAH5S2vyTJT+WjAJotKJ5vyGFbE+EoElEn7+dH1XAa1U Lj5uoMQNMF9w6TlORIgGZlF1nGeALXWKpN6HdwMFszy9otBapy4OXJcv3BsOUgHqV8xH yubcHvI+EPvxnjt/2Js3+XBw3YtLkgFX2dJDb0rVmGM1Cl8tcAn2ix7LoWmzv642Uru+ ppuw== X-Forwarded-Encrypted: i=1; AJvYcCVutv7NdzqJq8eZxiMVvPQF0CDVp+kJOsGbd1WmMHujOJYGc+OD7jtGYke7Hes+zaDFqCunpOjeNbc=@lists.xenproject.org X-Gm-Message-State: AOJu0YxQQAwqrhCMEgtku9TiTfkiewbuc9K2uJL9kJ1WuWhDXHWTT6XZ N55/Z7fsa7y85Nq9Ow1lHhOMjOn8NZdowBDtUT0esQSb/HKUIX4GRCkr/n8bALQkjQQlFrPl9YD DAK0744WSxXqJK7G8Qyk3JFwa9+KE807yb/Npt6zFWvFnqXY4iQmV23fYeWQhkzq8 X-Gm-Gg: ASbGncu+wUP6uE2rxfluOtjwx6+ne4y5IiCZtJtQJF6how2KkNLWm7RXGcY0SqNilN9 qQAVd/1GdLo3ugcKfLfsdfwlUJHm71eAmZlpqltzUV2TMOAKKS2WZXVPKObe8QFYKjgS759Ap1O 2JFJDow0ucbLtR5FLprCJphs6Vfeul8dJ7TbM/8E/dzRxQRlzLGO5RSXX1l2oiFYT9OTvIerU1t ddYPcsC1CBdp/Nl3/meH2HljDamjaWd0bWWoo8XH89bN7ZOPPWIIsudYow1mrKYvJJ9+dxzedFN qXs/HDex X-Received: by 2002:a05:6000:79e:b0:385:e9c0:c069 with SMTP id ffacd0b85a97d-3862b3d0941mr9603888f8f.57.1733749626167; Mon, 09 Dec 2024 05:07:06 -0800 (PST) X-Google-Smtp-Source: AGHT+IERHmOpW9Cz/hix9sJGhQKCFL65VOvqT0smHQwQu2JVZ9uttb5F5Byv3ep6mSTcPHbKk0ee2g== X-Received: by 2002:a05:6000:79e:b0:385:e9c0:c069 with SMTP id ffacd0b85a97d-3862b3d0941mr9603809f8f.57.1733749625729; Mon, 09 Dec 2024 05:07:05 -0800 (PST) From: Philipp Stanner To: amien Le Moal , Niklas Cassel , Basavaraj Natikar , Jiri Kosina , Benjamin Tissoires , Arnd Bergmann , Greg Kroah-Hartman , Alex Dubov , Sudarsana Kalluru , Manish Chopra , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rasesh Mody , GR-Linux-NIC-Dev@marvell.com, Igor Mitsyanko , Sergey Matyukevich , Kalle Valo , Sanjay R Mehta , Shyam Sundar S K , Jon Mason , Dave Jiang , Allen Hubbe , Bjorn Helgaas , Alex Williamson , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Mario Limonciello , Chen Ni , Philipp Stanner , Ricky Wu , Al Viro , Breno Leitao , Thomas Gleixner , Kevin Tian , Andy Shevchenko , Mostafa Saleh , Jason Gunthorpe , Yi Liu , Kunwu Chan , Dan Carpenter , "Dr. David Alan Gilbert" , Ankit Agrawal , Reinette Chatre , Eric Auger , Ye Bin Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, ntb@lists.linux.dev, linux-pci@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Subject: [PATCH v3 09/11] wifi: qtnfmac: use always-managed version of pcim_intx() Date: Mon, 9 Dec 2024 14:06:31 +0100 Message-ID: <20241209130632.132074-11-pstanner@redhat.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20241209130632.132074-2-pstanner@redhat.com> References: <20241209130632.132074-2-pstanner@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: ntTZ69gNOfwOYfO13OYiTTilOnNZ2L7BWMVgxKiek24_1733749626 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true pci_intx() is a hybrid function which can sometimes be managed through devres. To remove this hybrid nature from pci_intx(), it is necessary to port users to either an always-managed or a never-managed version. qtnfmac enables its PCI-Device with pcim_enable_device(). Thus, it needs the always-managed version. Replace pci_intx() with pcim_intx(). Signed-off-by: Philipp Stanner Acked-by: Kalle Valo --- drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c b/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c index f66eb43094d4..3adcfac2886f 100644 --- a/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c +++ b/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c @@ -204,7 +204,7 @@ static void qtnf_pcie_init_irq(struct qtnf_pcie_bus_priv *priv, bool use_msi) if (!priv->msi_enabled) { pr_warn("legacy PCIE interrupts enabled\n"); - pci_intx(pdev, 1); + pcim_intx(pdev, 1); } } -- 2.47.1 From xen-devel-bounces@lists.xenproject.org Mon Dec 09 13:07:14 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 13:07:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851204.1265386 (Exim 4.92) (envelope-from ) id 1tKdTm-00039M-Ci; Mon, 09 Dec 2024 13:07:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851204.1265386; Mon, 09 Dec 2024 13:07: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 1tKdTm-00038u-70; Mon, 09 Dec 2024 13:07:14 +0000 Received: by outflank-mailman (input) for mailman id 851204; Mon, 09 Dec 2024 13:07: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 1tKdTk-0000OS-9U for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 13:07:12 +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 7f0a196d-b62e-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 14:07:09 +0100 (CET) Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-661-k0VvuAkBNoGDssioiK_UpQ-1; Mon, 09 Dec 2024 08:07:05 -0500 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-385df115300so2533957f8f.2 for ; Mon, 09 Dec 2024 05:07:05 -0800 (PST) Received: from eisenberg.redhat.com (nat-pool-muc-u.redhat.com. [149.14.88.27]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3862190965asm13200127f8f.82.2024.12.09.05.07.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2024 05:07: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: 7f0a196d-b62e-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733749628; 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=nnuXTvhYTlwCBDrOS1s2G6F9Hq/4HeIeK8aJfi4Wc90=; b=iZbKJL8wiWWAHLaxPEEmQomjtPQWeJdGB+ViDqye9UvXGMZVXzT7z6mzy3PVUjl1RGpW6X xsHglo5TceUu95FXfFgar2MbdGZPlCbKcjGiPMxfkL5e2y7mGvc4RjUmZUXGZd9HZeij+O tMcB3ecJ7G28iU5OUlBoqOib+Ov9mxY= X-MC-Unique: k0VvuAkBNoGDssioiK_UpQ-1 X-Mimecast-MFC-AGG-ID: k0VvuAkBNoGDssioiK_UpQ X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733749624; x=1734354424; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nnuXTvhYTlwCBDrOS1s2G6F9Hq/4HeIeK8aJfi4Wc90=; b=gFSoSZqKnOXr9c1Et3X3Q92IuXxjyw+VccYv97W6MVZjajMKads064DYeKaWpT7BYq oLF6D2tHnAwuvpEHpbpiuPP2rXYeeqe8gdggciHkNCu5lRiNnHpID85o0sj9CEyOpEk7 C61kmi91E0qqRJ8qNQdT/zmymvKcv0AG7uT6hk1ppjeDgD6Q8oMJFvxHcx59nkVh3dwv GKEWtvEgW308z36Ps2/kL6Y1vxtsR1ol2aGTE7niykXxQKjbNDyH92A+6XGHrUk/HNJy 9mtvttVRjjWfHxHd8NW0vCYYMcIjQob9Hqhs87wlFMyy+39kZHJfRgIpLUR/f28ND/x1 SpKA== X-Forwarded-Encrypted: i=1; AJvYcCV3syEX2Kjjdgnv/l4/wJcBrcPJC6Zrg+0WdIw5P9DmmkJf3NFNe2hkt2+26VtY+PqyEqeoa6jOfXk=@lists.xenproject.org X-Gm-Message-State: AOJu0YzXytDaPGWEEzIA47I1ec1C4hFg3g2Xh5yuyNck+CKFWKcEzGsN Sew9vhH2XM2A4GBtjT72D/TVsDb7xEJofbp89rvVTV4hmNXCvQNyX/GVzmSlGRWlG7VwLpTQ8G0 Tloty/So7Aj7qfuFBWcYz2kSzSMDbhGpLeRv6NZ4WKJK4sUhlpeiFoYsnvMXQ5ljV X-Gm-Gg: ASbGncsvURBpTzGDd9EVwls1v6ILJlLmNlTJ1o1Xp1ZXrL0nEdEZqdLAi6Ay/IYxfCb 1F2eHzPS85OlA4bgHC6qDBZZgLEWtwDqLet2A7B4a7+uf8BuV4EDUVhM3nXpuEsaoHNe4ggjM2s 9bH5lfjUa4Qr89L7N0oiO8E7sznbVNszqIsTTn8QnTw6fua3nvEP3NeZ3E5ApjcY92aYgIriKyK YzbDtMbpvZQ7vy7kIo7Z6GbK07UCCmhZHvrxyAjcr6TFyP35JRUm+t6nT4ZEnChysouq1r6Dp3F IIRkfda4 X-Received: by 2002:a05:6000:a07:b0:386:1ba1:37dc with SMTP id ffacd0b85a97d-3862b3d02a7mr10541521f8f.47.1733749624044; Mon, 09 Dec 2024 05:07:04 -0800 (PST) X-Google-Smtp-Source: AGHT+IED6lK+xP3ASai9pzso97+PoKUV4QmBIbg3KzJDkAOewaSmInet03lP+u9hg0Iot8N8fifU+Q== X-Received: by 2002:a05:6000:a07:b0:386:1ba1:37dc with SMTP id ffacd0b85a97d-3862b3d02a7mr10541452f8f.47.1733749623572; Mon, 09 Dec 2024 05:07:03 -0800 (PST) From: Philipp Stanner To: amien Le Moal , Niklas Cassel , Basavaraj Natikar , Jiri Kosina , Benjamin Tissoires , Arnd Bergmann , Greg Kroah-Hartman , Alex Dubov , Sudarsana Kalluru , Manish Chopra , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rasesh Mody , GR-Linux-NIC-Dev@marvell.com, Igor Mitsyanko , Sergey Matyukevich , Kalle Valo , Sanjay R Mehta , Shyam Sundar S K , Jon Mason , Dave Jiang , Allen Hubbe , Bjorn Helgaas , Alex Williamson , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Mario Limonciello , Chen Ni , Philipp Stanner , Ricky Wu , Al Viro , Breno Leitao , Thomas Gleixner , Kevin Tian , Andy Shevchenko , Mostafa Saleh , Jason Gunthorpe , Yi Liu , Kunwu Chan , Dan Carpenter , "Dr. David Alan Gilbert" , Ankit Agrawal , Reinette Chatre , Eric Auger , Ye Bin Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, ntb@lists.linux.dev, linux-pci@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org, Sergey Shtylyov Subject: [PATCH v3 08/11] ata: Use always-managed version of pci_intx() Date: Mon, 9 Dec 2024 14:06:30 +0100 Message-ID: <20241209130632.132074-10-pstanner@redhat.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20241209130632.132074-2-pstanner@redhat.com> References: <20241209130632.132074-2-pstanner@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: UPqrqIGy0DeB6m8us0pT3QKU2uKvNDYpxz5f3H1elcM_1733749624 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true pci_intx() is a hybrid function which can sometimes be managed through devres. To remove this hybrid nature from pci_intx(), it is necessary to port users to either an always-managed or a never-managed version. All users in ata enable their PCI-Device with pcim_enable_device(). Thus, they need the always-managed version. Replace pci_intx() with pcim_intx(). Signed-off-by: Philipp Stanner Reviewed-by: Sergey Shtylyov Acked-by: Niklas Cassel --- drivers/ata/ahci.c | 2 +- drivers/ata/ata_piix.c | 2 +- drivers/ata/pata_rdc.c | 2 +- drivers/ata/sata_sil24.c | 2 +- drivers/ata/sata_sis.c | 2 +- drivers/ata/sata_uli.c | 2 +- drivers/ata/sata_vsc.c | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index 8d27c567be1c..f813dbdc2346 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -1987,7 +1987,7 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) if (ahci_init_msi(pdev, n_ports, hpriv) < 0) { /* legacy intx interrupts */ - pci_intx(pdev, 1); + pcim_intx(pdev, 1); } hpriv->irq = pci_irq_vector(pdev, 0); diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c index 093b940bc953..d441246fa357 100644 --- a/drivers/ata/ata_piix.c +++ b/drivers/ata/ata_piix.c @@ -1725,7 +1725,7 @@ static int piix_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) * message-signalled interrupts currently). */ if (port_flags & PIIX_FLAG_CHECKINTR) - pci_intx(pdev, 1); + pcim_intx(pdev, 1); if (piix_check_450nx_errata(pdev)) { /* This writes into the master table but it does not diff --git a/drivers/ata/pata_rdc.c b/drivers/ata/pata_rdc.c index 0a9689862f71..09792aac7f9d 100644 --- a/drivers/ata/pata_rdc.c +++ b/drivers/ata/pata_rdc.c @@ -340,7 +340,7 @@ static int rdc_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) return rc; host->private_data = hpriv; - pci_intx(pdev, 1); + pcim_intx(pdev, 1); host->flags |= ATA_HOST_PARALLEL_SCAN; diff --git a/drivers/ata/sata_sil24.c b/drivers/ata/sata_sil24.c index 72c03cbdaff4..b771ebd41252 100644 --- a/drivers/ata/sata_sil24.c +++ b/drivers/ata/sata_sil24.c @@ -1317,7 +1317,7 @@ static int sil24_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) if (sata_sil24_msi && !pci_enable_msi(pdev)) { dev_info(&pdev->dev, "Using MSI\n"); - pci_intx(pdev, 0); + pcim_intx(pdev, 0); } pci_set_master(pdev); diff --git a/drivers/ata/sata_sis.c b/drivers/ata/sata_sis.c index ef8724986de3..b8b6d9eff3b8 100644 --- a/drivers/ata/sata_sis.c +++ b/drivers/ata/sata_sis.c @@ -290,7 +290,7 @@ static int sis_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) } pci_set_master(pdev); - pci_intx(pdev, 1); + pcim_intx(pdev, 1); return ata_host_activate(host, pdev->irq, ata_bmdma_interrupt, IRQF_SHARED, &sis_sht); } diff --git a/drivers/ata/sata_uli.c b/drivers/ata/sata_uli.c index 60ea45926cd1..52894ff49dcb 100644 --- a/drivers/ata/sata_uli.c +++ b/drivers/ata/sata_uli.c @@ -221,7 +221,7 @@ static int uli_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) } pci_set_master(pdev); - pci_intx(pdev, 1); + pcim_intx(pdev, 1); return ata_host_activate(host, pdev->irq, ata_bmdma_interrupt, IRQF_SHARED, &uli_sht); } diff --git a/drivers/ata/sata_vsc.c b/drivers/ata/sata_vsc.c index d39b87537168..a53a2dfc1e17 100644 --- a/drivers/ata/sata_vsc.c +++ b/drivers/ata/sata_vsc.c @@ -384,7 +384,7 @@ static int vsc_sata_init_one(struct pci_dev *pdev, pci_write_config_byte(pdev, PCI_CACHE_LINE_SIZE, 0x80); if (pci_enable_msi(pdev) == 0) - pci_intx(pdev, 0); + pcim_intx(pdev, 0); /* * Config offset 0x98 is "Extended Control and Status Register 0" -- 2.47.1 From xen-devel-bounces@lists.xenproject.org Mon Dec 09 13:07:15 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 13:07:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851207.1265392 (Exim 4.92) (envelope-from ) id 1tKdTn-0003GL-10; Mon, 09 Dec 2024 13:07:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851207.1265392; Mon, 09 Dec 2024 13:07: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 1tKdTm-0003El-Pp; Mon, 09 Dec 2024 13:07:14 +0000 Received: by outflank-mailman (input) for mailman id 851207; Mon, 09 Dec 2024 13: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 1tKdTl-0000OS-Nm for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 13:07:13 +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 80721f25-b62e-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 14:07:12 +0100 (CET) Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-117-uac86oUmOFObv_Lg_jXchQ-1; Mon, 09 Dec 2024 08:07:09 -0500 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-434c214c05aso36610395e9.0 for ; Mon, 09 Dec 2024 05:07:09 -0800 (PST) Received: from eisenberg.redhat.com (nat-pool-muc-u.redhat.com. [149.14.88.27]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3862190965asm13200127f8f.82.2024.12.09.05.07.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2024 05:07: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: 80721f25-b62e-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733749630; 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=cg5FDrf0+9NG9f4wa7LEIeg49zn7uGzDf8HKpIKXKbU=; b=VM7y4uGewQosbc7LfMjsniDOAjbmfqEqTJM42BDCKc9Prxx5eOrQ9Nsp/YveAiXus5TM5u RdvYDaOP306MnCVwa/0Dtc58OJT5j3poeEwL5ne0FQHuohxfTjALZIn5hsALMbQ7VU494a FfncfBtBrqtNN+JsovTTGurqk97jNj0= X-MC-Unique: uac86oUmOFObv_Lg_jXchQ-1 X-Mimecast-MFC-AGG-ID: uac86oUmOFObv_Lg_jXchQ X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733749628; x=1734354428; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cg5FDrf0+9NG9f4wa7LEIeg49zn7uGzDf8HKpIKXKbU=; b=UM/DCV4uO3y2wmmhuGo2y7fpAF8WnvwEOtFTdnGCmhU9PWOpXpdUJ3uPt/AsAuhCxU xpEvUCneoqWvlMVV/79z4/YQGkTy4o65/WvtOQuktpMCwrbzXYRSKlxydQBtJRb7yCtv 1qwvR2XE3g3R7YKM5ivOhV8rXgE9+VL8JAfdmRiKvROY3CAF1vXz3S+BdlNjsNyPgGbh VTlua+1Wj5TPXhBK3hScteyIibOcDjmTyxzNrve2sexzKeX9ddngPiy+3rqsiKK8K0LJ KyFaoxzIsVE+aYrJsG0GSvOwkwxV0okgqEkOOd16RxUvJztinx+gYKZROO81CFLV9Mz9 hlxw== X-Forwarded-Encrypted: i=1; AJvYcCUxjBMTcbl5aG43oKgdn5T50BTxtA6+CPW/KnPeo2jUrX/d9T+sABX8CBUTY5qvpVDnlAuLN3bxyWo=@lists.xenproject.org X-Gm-Message-State: AOJu0YzQz4OB9aUhuAip86SGVP3KjwQX2BZcXv/PaF3oytCBEgSKkIXW fyB8G9SSI4p+kZrj+Xpfy1p8B6yU2b7tZz4rHOoi9cwy97yFpBnQm4HFIAsWsDDgnl7NPQwHmEJ fn1/7QuGfdZszL6kZ6/PTrxGA/m3xF6ljUQzAByQpi+ky00NdqhO9096+HJkqiwZL X-Gm-Gg: ASbGnculvldtMHU4GE1CvMRcpdpw67hIDzEXYV6utI9GrjhOfMDUl30oje3doc0Vq8B zTu5cyAQKMd/hyDEwiwE3kerEgRxf/FLOl4aVOgx1KlqSOEgnm++IoeJ9M6SXJvvm307ZRElSYW 416Dj+mxGL9bpDZtty+n8prmny6Hol8ZYf4I9UF4sU0Z6iFMfEKgXXpz9xB7oCM8Ir33FaNc3hG RLEuu1HLHw+nkZGK0fZAU/+6bUuwRtfFVND1+goZwKULWmdVuygt2JppTRKWq1DwA4WYyNh2h9v ZELL4Ufd X-Received: by 2002:a05:6000:2d12:b0:385:faec:d94d with SMTP id ffacd0b85a97d-3862b3e2f99mr6786250f8f.51.1733749628311; Mon, 09 Dec 2024 05:07:08 -0800 (PST) X-Google-Smtp-Source: AGHT+IGzvkT5DctzF6sU2GBgKgYj4TZMfZMHtf63D+x4hcRmPdkPLtxCBfCUCCjCewKM8z5+rRuxWg== X-Received: by 2002:a05:6000:2d12:b0:385:faec:d94d with SMTP id ffacd0b85a97d-3862b3e2f99mr6786186f8f.51.1733749627860; Mon, 09 Dec 2024 05:07:07 -0800 (PST) From: Philipp Stanner To: amien Le Moal , Niklas Cassel , Basavaraj Natikar , Jiri Kosina , Benjamin Tissoires , Arnd Bergmann , Greg Kroah-Hartman , Alex Dubov , Sudarsana Kalluru , Manish Chopra , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rasesh Mody , GR-Linux-NIC-Dev@marvell.com, Igor Mitsyanko , Sergey Matyukevich , Kalle Valo , Sanjay R Mehta , Shyam Sundar S K , Jon Mason , Dave Jiang , Allen Hubbe , Bjorn Helgaas , Alex Williamson , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Mario Limonciello , Chen Ni , Philipp Stanner , Ricky Wu , Al Viro , Breno Leitao , Thomas Gleixner , Kevin Tian , Andy Shevchenko , Mostafa Saleh , Jason Gunthorpe , Yi Liu , Kunwu Chan , Dan Carpenter , "Dr. David Alan Gilbert" , Ankit Agrawal , Reinette Chatre , Eric Auger , Ye Bin Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, ntb@lists.linux.dev, linux-pci@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org, Basavaraj Natikar Subject: [PATCH v3 10/11] HID: amd_sfh: Use always-managed version of pcim_intx() Date: Mon, 9 Dec 2024 14:06:32 +0100 Message-ID: <20241209130632.132074-12-pstanner@redhat.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20241209130632.132074-2-pstanner@redhat.com> References: <20241209130632.132074-2-pstanner@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: cokNTiC4lOpw8nwSmQlxwFLcd9thvpkkTOzojUKq7_k_1733749628 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true pci_intx() is a hybrid function which can sometimes be managed through devres. To remove this hybrid nature from pci_intx(), it is necessary to port users to either an always-managed or a never-managed version. All users of amd_mp2_pci_remove(), where pci_intx() is used, call pcim_enable_device(), which is why the driver needs the always-managed version. Replace pci_intx() with pcim_intx(). Signed-off-by: Philipp Stanner Acked-by: Basavaraj Natikar --- drivers/hid/amd-sfh-hid/amd_sfh_pcie.c | 4 ++-- drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c index 0c28ca349bcd..48cfd0c58241 100644 --- a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c +++ b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c @@ -122,7 +122,7 @@ int amd_sfh_irq_init_v2(struct amd_mp2_dev *privdata) { int rc; - pci_intx(privdata->pdev, true); + pcim_intx(privdata->pdev, true); rc = devm_request_irq(&privdata->pdev->dev, privdata->pdev->irq, amd_sfh_irq_handler, 0, DRIVER_NAME, privdata); @@ -248,7 +248,7 @@ static void amd_mp2_pci_remove(void *privdata) struct amd_mp2_dev *mp2 = privdata; amd_sfh_hid_client_deinit(privdata); mp2->mp2_ops->stop_all(mp2); - pci_intx(mp2->pdev, false); + pcim_intx(mp2->pdev, false); amd_sfh_clear_intr(mp2); } diff --git a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c index db36d87d5634..ec9feb8e023b 100644 --- a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c +++ b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c @@ -289,7 +289,7 @@ static void amd_mp2_pci_remove(void *privdata) sfh_deinit_emp2(); amd_sfh_hid_client_deinit(privdata); mp2->mp2_ops->stop_all(mp2); - pci_intx(mp2->pdev, false); + pcim_intx(mp2->pdev, false); amd_sfh_clear_intr(mp2); } -- 2.47.1 From xen-devel-bounces@lists.xenproject.org Mon Dec 09 13:10:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 13:10:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851256.1265406 (Exim 4.92) (envelope-from ) id 1tKdX3-0007Ue-LX; Mon, 09 Dec 2024 13:10:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851256.1265406; Mon, 09 Dec 2024 13:10: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 1tKdX3-0007UD-IQ; Mon, 09 Dec 2024 13:10:37 +0000 Received: by outflank-mailman (input) for mailman id 851256; Mon, 09 Dec 2024 13:10: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 1tKdTs-0000ch-NU for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 13:07:20 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 83007d97-b62e-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 14:07:16 +0100 (CET) Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-636-73G_LgCWMNy0xbJQsLo6Tw-1; Mon, 09 Dec 2024 08:07:14 -0500 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-434fff37885so888695e9.3 for ; Mon, 09 Dec 2024 05:07:13 -0800 (PST) Received: from eisenberg.redhat.com (nat-pool-muc-u.redhat.com. [149.14.88.27]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3862190965asm13200127f8f.82.2024.12.09.05.07.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2024 05:07:09 -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: 83007d97-b62e-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733749635; 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=6HNQFFZFNBo2fKXDk5eFuu7P7NBI6b9tUTkzIaFtOWU=; b=NRatnZhGonb65bvfPmdPRDr8bgEh0s0peyHC9oGS/z5Fz29Hy7/yD/2afUNByoTvVFK9lj TTXzjvfQNmvuXdNPpaLrso5IsuEffdZzk4XidNJxf9+nS44/saPeWdruAP2tELxIw1Wivt pEWg18GUxAe+EaBdIzY1sPkKOyL9r+k= X-MC-Unique: 73G_LgCWMNy0xbJQsLo6Tw-1 X-Mimecast-MFC-AGG-ID: 73G_LgCWMNy0xbJQsLo6Tw X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733749631; x=1734354431; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6HNQFFZFNBo2fKXDk5eFuu7P7NBI6b9tUTkzIaFtOWU=; b=UF7n6ToAGffhM3hDZZMnUd72FFV03BTVznosiQGqcL5X8rtRZjsojku26WTTnJVTSd ZUEBPoWVGH+fFnoMX99XZiYhskqRYJD8WhJQu6st+d4gP8Giu0azHOPII0QbPQ5qYlw8 bx6IGXYixZCw3afLxGHmlNGT8JASusUXHb2eN02cmZt7gJ1as1EXG0ixF8H52nD7pJa1 SKrtulA3cAst6wb50KEMNUWU6r2N9efko7wYg73UXmYphnG4a3KJjxsr4y+5EUsfnj1y YEeCWSPS1KK9Lav07HvUpcUkhLqJ8cc2zNod23U4tK77ZN5L0+n6FVmY9hhxldtrx3tw x2ig== X-Forwarded-Encrypted: i=1; AJvYcCWPinTjmHlp6+roiVZfigB/wSZhPb3wWHi186D1+PjurkAMaD6eLChz8cP9Ny6yNOxPRORF66yWKJQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YwoxK4907iqcL7vEjKQvERSAV84RQCkbepHhZyvhBgNLRXuTuwJ 7e/CD1+wdHBDrry6OugEBXoTpt6ND1+zmUuQI80U2bqqLCsw/h0j6OUXlaRCGeB8LYgzaNYAyeJ 45j6YWsdaMFUf3z5I7UDONsIacXn2kZDAph3sbNkn4VicCflqduwIRADp10qZZOmJ X-Gm-Gg: ASbGnctc0Joyp81BxpzLkjW366J00LJCvruqU+oi+W/4DJo5Xzz7bO041tN0qLYWF1V myVLf/q6pQ1fLtcNehzVmz7OY7j4tCXfVGEW+Pc1BQ697AUWeSObMcEJpE3W/2/2VuxFB+KAnay gRCHXHE8U90+Xd9jzI3jG/uRfGr8B1Ja+HA/Jhl2Ok5nCu/Z4O/UB8f3/OAMUWC81yXeJ00clYv fpJgUpt+EsRQHPbsLq0bLuTWLN9ZIU+UB1J5Lb12Lt7NHwi1ygHwMYO9FXtLanhY2caaVfjMbzS yp3koh5Y X-Received: by 2002:a05:600c:3547:b0:434:a525:7257 with SMTP id 5b1f17b1804b1-434fffd0490mr3116165e9.21.1733749630791; Mon, 09 Dec 2024 05:07:10 -0800 (PST) X-Google-Smtp-Source: AGHT+IELX86PBcQHpAJDUmCcFKSGck+5vkGUq7O4wFXOdXDUx7b79IoLlNFEza+cDwu9qun6lbiQKA== X-Received: by 2002:a05:600c:3547:b0:434:a525:7257 with SMTP id 5b1f17b1804b1-434fffd0490mr3115205e9.21.1733749630127; Mon, 09 Dec 2024 05:07:10 -0800 (PST) From: Philipp Stanner To: amien Le Moal , Niklas Cassel , Basavaraj Natikar , Jiri Kosina , Benjamin Tissoires , Arnd Bergmann , Greg Kroah-Hartman , Alex Dubov , Sudarsana Kalluru , Manish Chopra , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rasesh Mody , GR-Linux-NIC-Dev@marvell.com, Igor Mitsyanko , Sergey Matyukevich , Kalle Valo , Sanjay R Mehta , Shyam Sundar S K , Jon Mason , Dave Jiang , Allen Hubbe , Bjorn Helgaas , Alex Williamson , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Mario Limonciello , Chen Ni , Philipp Stanner , Ricky Wu , Al Viro , Breno Leitao , Thomas Gleixner , Kevin Tian , Andy Shevchenko , Mostafa Saleh , Jason Gunthorpe , Yi Liu , Kunwu Chan , Dan Carpenter , "Dr. David Alan Gilbert" , Ankit Agrawal , Reinette Chatre , Eric Auger , Ye Bin Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, ntb@lists.linux.dev, linux-pci@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Subject: [PATCH v3 11/11] Remove devres from pci_intx() Date: Mon, 9 Dec 2024 14:06:33 +0100 Message-ID: <20241209130632.132074-13-pstanner@redhat.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20241209130632.132074-2-pstanner@redhat.com> References: <20241209130632.132074-2-pstanner@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: xz6DGUNq0y1h8u6CeMDiaJ4kGfcKhmhrEydd4DKMdSg_1733749633 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true pci_intx() is a hybrid function which can sometimes be managed through devres. This hybrid nature is undesirable. Since all users of pci_intx() have by now been ported either to always-managed pcim_intx() or never-managed pci_intx_unmanaged(), the devres functionality can be removed from pci_intx(). Consequently, pci_intx_unmanaged() is now redundant, because pci_intx() itself is now unmanaged. Remove the devres functionality from pci_intx(). Have all users of pci_intx_unmanaged() call pci_intx(). Remove pci_intx_unmanaged(). Signed-off-by: Philipp Stanner --- drivers/misc/cardreader/rtsx_pcr.c | 2 +- drivers/misc/tifm_7xx1.c | 6 +-- .../net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +- drivers/net/ethernet/brocade/bna/bnad.c | 2 +- drivers/ntb/hw/amd/ntb_hw_amd.c | 4 +- drivers/ntb/hw/intel/ntb_hw_gen1.c | 2 +- drivers/pci/devres.c | 4 +- drivers/pci/msi/api.c | 2 +- drivers/pci/msi/msi.c | 2 +- drivers/pci/pci.c | 43 +------------------ drivers/vfio/pci/vfio_pci_core.c | 2 +- drivers/vfio/pci/vfio_pci_intrs.c | 10 ++--- drivers/xen/xen-pciback/conf_space_header.c | 2 +- include/linux/pci.h | 1 - 14 files changed, 22 insertions(+), 62 deletions(-) diff --git a/drivers/misc/cardreader/rtsx_pcr.c b/drivers/misc/cardreader/rtsx_pcr.c index e25e6d560dd7..be3d4e0e50cc 100644 --- a/drivers/misc/cardreader/rtsx_pcr.c +++ b/drivers/misc/cardreader/rtsx_pcr.c @@ -1057,7 +1057,7 @@ static int rtsx_pci_acquire_irq(struct rtsx_pcr *pcr) } pcr->irq = pcr->pci->irq; - pci_intx_unmanaged(pcr->pci, !pcr->msi_en); + pci_intx(pcr->pci, !pcr->msi_en); return 0; } diff --git a/drivers/misc/tifm_7xx1.c b/drivers/misc/tifm_7xx1.c index 5f9c7ccae8d2..1d54680d6ed2 100644 --- a/drivers/misc/tifm_7xx1.c +++ b/drivers/misc/tifm_7xx1.c @@ -327,7 +327,7 @@ static int tifm_7xx1_probe(struct pci_dev *dev, goto err_out; } - pci_intx_unmanaged(dev, 1); + pci_intx(dev, 1); fm = tifm_alloc_adapter(dev->device == PCI_DEVICE_ID_TI_XX21_XX11_FM ? 4 : 2, &dev->dev); @@ -368,7 +368,7 @@ static int tifm_7xx1_probe(struct pci_dev *dev, err_out_free: tifm_free_adapter(fm); err_out_int: - pci_intx_unmanaged(dev, 0); + pci_intx(dev, 0); pci_release_regions(dev); err_out: if (!pci_dev_busy) @@ -392,7 +392,7 @@ static void tifm_7xx1_remove(struct pci_dev *dev) tifm_7xx1_sock_power_off(tifm_7xx1_sock_addr(fm->addr, cnt)); iounmap(fm->addr); - pci_intx_unmanaged(dev, 0); + pci_intx(dev, 0); pci_release_regions(dev); pci_disable_device(dev); diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c index 2ae63d6e6792..678829646cec 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c @@ -1669,7 +1669,7 @@ static void bnx2x_igu_int_enable(struct bnx2x *bp) REG_WR(bp, IGU_REG_PF_CONFIGURATION, val); if (val & IGU_PF_CONF_INT_LINE_EN) - pci_intx_unmanaged(bp->pdev, true); + pci_intx(bp->pdev, true); barrier(); diff --git a/drivers/net/ethernet/brocade/bna/bnad.c b/drivers/net/ethernet/brocade/bna/bnad.c index 2b37462d406e..ece6f3b48327 100644 --- a/drivers/net/ethernet/brocade/bna/bnad.c +++ b/drivers/net/ethernet/brocade/bna/bnad.c @@ -2669,7 +2669,7 @@ bnad_enable_msix(struct bnad *bnad) } } - pci_intx_unmanaged(bnad->pcidev, 0); + pci_intx(bnad->pcidev, 0); return; diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c index b146f170e839..d687e8c2cc78 100644 --- a/drivers/ntb/hw/amd/ntb_hw_amd.c +++ b/drivers/ntb/hw/amd/ntb_hw_amd.c @@ -791,7 +791,7 @@ static int ndev_init_isr(struct amd_ntb_dev *ndev, err_msi_enable: /* Try to set up intx irq */ - pci_intx_unmanaged(pdev, 1); + pci_intx(pdev, 1); rc = request_irq(pdev->irq, ndev_irq_isr, IRQF_SHARED, "ndev_irq_isr", ndev); @@ -831,7 +831,7 @@ static void ndev_deinit_isr(struct amd_ntb_dev *ndev) if (pci_dev_msi_enabled(pdev)) pci_disable_msi(pdev); else - pci_intx_unmanaged(pdev, 0); + pci_intx(pdev, 0); } } diff --git a/drivers/ntb/hw/intel/ntb_hw_gen1.c b/drivers/ntb/hw/intel/ntb_hw_gen1.c index 9ad9d7fe227e..079b8cd79785 100644 --- a/drivers/ntb/hw/intel/ntb_hw_gen1.c +++ b/drivers/ntb/hw/intel/ntb_hw_gen1.c @@ -445,7 +445,7 @@ int ndev_init_isr(struct intel_ntb_dev *ndev, /* Try to set up intx irq */ - pci_intx_unmanaged(pdev, 1); + pci_intx(pdev, 1); rc = request_irq(pdev->irq, ndev_irq_isr, IRQF_SHARED, "ndev_irq_isr", ndev); diff --git a/drivers/pci/devres.c b/drivers/pci/devres.c index 3594eea37993..cc3195134721 100644 --- a/drivers/pci/devres.c +++ b/drivers/pci/devres.c @@ -416,7 +416,7 @@ static void pcim_intx_restore(struct device *dev, void *data) struct pci_dev *pdev = to_pci_dev(dev); struct pcim_intx_devres *res = data; - pci_intx_unmanaged(pdev, res->orig_intx); + pci_intx(pdev, res->orig_intx); } static struct pcim_intx_devres *get_or_create_intx_devres(struct device *dev) @@ -453,7 +453,7 @@ int pcim_intx(struct pci_dev *pdev, int enable) return -ENOMEM; res->orig_intx = !enable; - pci_intx_unmanaged(pdev, enable); + pci_intx(pdev, enable); return 0; } diff --git a/drivers/pci/msi/api.c b/drivers/pci/msi/api.c index c95e2e7dc9ab..b956ce591f96 100644 --- a/drivers/pci/msi/api.c +++ b/drivers/pci/msi/api.c @@ -289,7 +289,7 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs, */ if (affd) irq_create_affinity_masks(1, affd); - pci_intx_unmanaged(dev, 1); + pci_intx(dev, 1); return 1; } } diff --git a/drivers/pci/msi/msi.c b/drivers/pci/msi/msi.c index 53f13b09db50..3a45879d85db 100644 --- a/drivers/pci/msi/msi.c +++ b/drivers/pci/msi/msi.c @@ -268,7 +268,7 @@ EXPORT_SYMBOL_GPL(pci_write_msi_msg); static void pci_intx_for_msi(struct pci_dev *dev, int enable) { if (!(dev->dev_flags & PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG)) - pci_intx_unmanaged(dev, enable); + pci_intx(dev, enable); } static void pci_msi_set_enable(struct pci_dev *dev, int enable) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 30d17ec771fc..121eb7b0b1b7 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -4483,17 +4483,13 @@ void pci_disable_parity(struct pci_dev *dev) } /** - * pci_intx_unmanaged - enables/disables PCI INTx for device dev, - * unmanaged version + * pci_intx - enables/disables PCI INTx for device dev * @pdev: the PCI device to operate on * @enable: boolean: whether to enable or disable PCI INTx * * Enables/disables PCI INTx for device @pdev - * - * This function behavios identically to pci_intx(), but is never managed with - * devres. */ -void pci_intx_unmanaged(struct pci_dev *pdev, int enable) +void pci_intx(struct pci_dev *pdev, int enable) { u16 pci_command, new; @@ -4509,41 +4505,6 @@ void pci_intx_unmanaged(struct pci_dev *pdev, int enable) pci_write_config_word(pdev, PCI_COMMAND, new); } -EXPORT_SYMBOL_GPL(pci_intx_unmanaged); - -/** - * pci_intx - enables/disables PCI INTx for device dev - * @pdev: the PCI device to operate on - * @enable: boolean: whether to enable or disable PCI INTx - * - * Enables/disables PCI INTx for device @pdev - * - * NOTE: - * This is a "hybrid" function: It's normally unmanaged, but becomes managed - * when pcim_enable_device() has been called in advance. This hybrid feature is - * DEPRECATED! If you want managed cleanup, use pcim_intx() instead. - */ -void pci_intx(struct pci_dev *pdev, int enable) -{ - u16 pci_command, new; - - pci_read_config_word(pdev, PCI_COMMAND, &pci_command); - - if (enable) - new = pci_command & ~PCI_COMMAND_INTX_DISABLE; - else - new = pci_command | PCI_COMMAND_INTX_DISABLE; - - if (new != pci_command) { - /* Preserve the "hybrid" behavior for backwards compatibility */ - if (pci_is_managed(pdev)) { - WARN_ON_ONCE(pcim_intx(pdev, enable) != 0); - return; - } - - pci_write_config_word(pdev, PCI_COMMAND, new); - } -} EXPORT_SYMBOL_GPL(pci_intx); /** diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c index 90240c8d51aa..1ab58da9f38a 100644 --- a/drivers/vfio/pci/vfio_pci_core.c +++ b/drivers/vfio/pci/vfio_pci_core.c @@ -498,7 +498,7 @@ int vfio_pci_core_enable(struct vfio_pci_core_device *vdev) if (vfio_pci_nointx(pdev)) { pci_info(pdev, "Masking broken INTx support\n"); vdev->nointx = true; - pci_intx_unmanaged(pdev, 0); + pci_intx(pdev, 0); } else vdev->pci_2_3 = pci_intx_mask_supported(pdev); } diff --git a/drivers/vfio/pci/vfio_pci_intrs.c b/drivers/vfio/pci/vfio_pci_intrs.c index 40abb0b937a2..8382c5834335 100644 --- a/drivers/vfio/pci/vfio_pci_intrs.c +++ b/drivers/vfio/pci/vfio_pci_intrs.c @@ -118,7 +118,7 @@ static bool __vfio_pci_intx_mask(struct vfio_pci_core_device *vdev) */ if (unlikely(!is_intx(vdev))) { if (vdev->pci_2_3) - pci_intx_unmanaged(pdev, 0); + pci_intx(pdev, 0); goto out_unlock; } @@ -132,7 +132,7 @@ static bool __vfio_pci_intx_mask(struct vfio_pci_core_device *vdev) * mask, not just when something is pending. */ if (vdev->pci_2_3) - pci_intx_unmanaged(pdev, 0); + pci_intx(pdev, 0); else disable_irq_nosync(pdev->irq); @@ -178,7 +178,7 @@ static int vfio_pci_intx_unmask_handler(void *opaque, void *data) */ if (unlikely(!is_intx(vdev))) { if (vdev->pci_2_3) - pci_intx_unmanaged(pdev, 1); + pci_intx(pdev, 1); goto out_unlock; } @@ -296,7 +296,7 @@ static int vfio_intx_enable(struct vfio_pci_core_device *vdev, */ ctx->masked = vdev->virq_disabled; if (vdev->pci_2_3) { - pci_intx_unmanaged(pdev, !ctx->masked); + pci_intx(pdev, !ctx->masked); irqflags = IRQF_SHARED; } else { irqflags = ctx->masked ? IRQF_NO_AUTOEN : 0; @@ -569,7 +569,7 @@ static void vfio_msi_disable(struct vfio_pci_core_device *vdev, bool msix) * via their shutdown paths. Restore for NoINTx devices. */ if (vdev->nointx) - pci_intx_unmanaged(pdev, 0); + pci_intx(pdev, 0); vdev->irq_type = VFIO_PCI_NUM_IRQS; } diff --git a/drivers/xen/xen-pciback/conf_space_header.c b/drivers/xen/xen-pciback/conf_space_header.c index 8d26d64232e8..fc0332645966 100644 --- a/drivers/xen/xen-pciback/conf_space_header.c +++ b/drivers/xen/xen-pciback/conf_space_header.c @@ -106,7 +106,7 @@ static int command_write(struct pci_dev *dev, int offset, u16 value, void *data) if (dev_data && dev_data->allow_interrupt_control && ((cmd->val ^ value) & PCI_COMMAND_INTX_DISABLE)) - pci_intx_unmanaged(dev, !(value & PCI_COMMAND_INTX_DISABLE)); + pci_intx(dev, !(value & PCI_COMMAND_INTX_DISABLE)); cmd->val = value; diff --git a/include/linux/pci.h b/include/linux/pci.h index b5eb8bda655d..f05903dd7695 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -1350,7 +1350,6 @@ int __must_check pcim_set_mwi(struct pci_dev *dev); int pci_try_set_mwi(struct pci_dev *dev); void pci_clear_mwi(struct pci_dev *dev); void pci_disable_parity(struct pci_dev *dev); -void pci_intx_unmanaged(struct pci_dev *pdev, int enable); void pci_intx(struct pci_dev *dev, int enable); bool pci_check_and_mask_intx(struct pci_dev *dev); bool pci_check_and_unmask_intx(struct pci_dev *dev); -- 2.47.1 From xen-devel-bounces@lists.xenproject.org Mon Dec 09 13:20:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 13:20:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851330.1265417 (Exim 4.92) (envelope-from ) id 1tKdgD-0001Bc-L4; Mon, 09 Dec 2024 13:20:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851330.1265417; Mon, 09 Dec 2024 13:20: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 1tKdgD-0001BE-FJ; Mon, 09 Dec 2024 13:20:05 +0000 Received: by outflank-mailman (input) for mailman id 851330; Mon, 09 Dec 2024 13:20: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 1tKdgC-0000zr-O6 for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 13:20:04 +0000 Received: from pegase2.c-s.fr (pegase2.c-s.fr [93.17.235.10]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id 4c334225-b630-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 14:20:02 +0100 (CET) Received: from localhost (mailhub3.si.c-s.fr [172.26.127.67]) by localhost (Postfix) with ESMTP id 4Y6M5p179vz9tBf; Mon, 9 Dec 2024 13:45:18 +0100 (CET) Received: from pegase2.c-s.fr ([172.26.127.65]) by localhost (pegase2.c-s.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ad8aC7rBW98b; Mon, 9 Dec 2024 13:45:18 +0100 (CET) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase2.c-s.fr (Postfix) with ESMTP id 4Y6M5p0DxHz9tBd; Mon, 9 Dec 2024 13:45:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id E8A068B766; Mon, 9 Dec 2024 13:45:17 +0100 (CET) Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id OUa8UHFVNS_8; Mon, 9 Dec 2024 13:45:17 +0100 (CET) Received: from [10.25.209.139] (unknown [10.25.209.139]) by messagerie.si.c-s.fr (Postfix) with ESMTP id A70C18B763; Mon, 9 Dec 2024 13:45:17 +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: 4c334225-b630-11ef-99a3-01e77a169b0f X-Virus-Scanned: amavisd-new at c-s.fr X-Virus-Scanned: amavisd-new at c-s.fr Message-ID: <95a461ca-3ed6-4380-ad1a-da12e1109675@csgroup.eu> Date: Mon, 9 Dec 2024 13:45:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 00/21] Converge on using secs_to_jiffies() To: Przemek Kitszel , Easwar Hariharan Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, ath11k@lists.infradead.org, linux-mm@kvack.org, linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, live-patching@vger.kernel.org, linux-sound@vger.kernel.org, etnaviv@lists.freedesktop.org, oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, Anna-Maria Behnsen References: <20241115-converge-secs-to-jiffies-v2-0-911fb7595e79@linux.microsoft.com> <72c8eb66-eb67-4f8b-b0c0-13f1aa001698@intel.com> Content-Language: fr-FR From: Christophe Leroy In-Reply-To: <72c8eb66-eb67-4f8b-b0c0-13f1aa001698@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 09/12/2024 à 13:01, Przemek Kitszel a écrit : > On 12/6/24 9:58 PM, Easwar Hariharan wrote: >> On 11/29/2024 4:57 AM, Przemek Kitszel wrote: >>> >>> [removed most non-list recipients, it's just too much] >>> >>> On 11/15/24 10:26 PM, Easwar Hariharan wrote: >> > >>> >>> Regarding code - you could also convert msecs_to_jiffies(const * HZ), >>> there are 10 that are greppable. >>> >> >> Those seem to be mistakes. const*HZ is a seconds-denominated timeout, >> being passed to msecs_to_jiffies() which will treat it as a >> millisecond-denominated timeout resulting in an excessively long >> timeout. I suppose that's better than a too-short timeout, and >> apparently it's been working fine all along since hardware responds >> before the too-long timeout expires. Half of them are in >> drivers/scsi/arcmsr/arcmsr_hba.c and the pattern has apparently been >> there since 2010. > > my point was that, the default value of HZ is 1000, and most of the code > that is just `$value*HZ` was meant as "$value seconds, in ms unit". I can't follow you here. The default value of HZ is 250 as far as I can see. Regardless, HZ is the number of jiffies per second, nothing else. > > Same for HZ/const, HZ/2 being 500ms. > > HZ is awful in that it is not 1s but 1/s, but it was easy to abuse the > value in simple context. Why is that awful ? HZ is a nice macro that gives you the number of ticks per second, so that you are able to easily calculate the number of ticks for a given duration, regardless of the configured number of ticks per second. Christophe From xen-devel-bounces@lists.xenproject.org Mon Dec 09 13:24:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 13:24:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851341.1265426 (Exim 4.92) (envelope-from ) id 1tKdkc-0002yf-6n; Mon, 09 Dec 2024 13:24:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851341.1265426; Mon, 09 Dec 2024 13:24: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 1tKdkc-0002yY-3V; Mon, 09 Dec 2024 13:24:38 +0000 Received: by outflank-mailman (input) for mailman id 851341; Mon, 09 Dec 2024 13:24: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 1tKdkb-0002yS-AZ for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 13:24:37 +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 eeb2fd38-b630-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 14:24:35 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-434a2033562so41825035e9.1 for ; Mon, 09 Dec 2024 05:24: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 98e67ed59e1d1-2efc4230217sm1120711a91.8.2024.12.09.05.24.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 05:24: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: eeb2fd38-b630-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733750675; x=1734355475; 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=UabuauDlkqNJkT3tmMjByYaQcBGgy3Zfs3x9N9+um9I=; b=UInkd5euMqbGHyrstPcSiHaEw0MxvM/EfHj4YjA03BmrGDQ6cGAevrjC5Mg4QB6+AC yS0q145T0uxOyuVr4eWZUuboeQxDTaz/YBFYgmaRSz6AF8L2s/UKV/U50ZrT9IaqgqRT XzqAyomJ6Aw4aaQbw+RKIdoaiaTiqppp5ZYD/kajbw5mQxg1pDXE04ei57hAyavn8xGv EiBOX+ILq1nkzYz6ycK8r932GR9Vhpz681qfbcw3O9iINyAuJU03wmzD13pI2KsADC8f nO/+nNRofHXK+J4KVnLmDjgtv43VfJPvijVEATaG7KfIecx1R04e1SqHNcRql9fGPGzl e2Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733750675; x=1734355475; h=content-transfer-encoding:autocrypt:content-language:cc:to:subject :from:user-agent:mime-version:date:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UabuauDlkqNJkT3tmMjByYaQcBGgy3Zfs3x9N9+um9I=; b=Y+m1BLu3aTE6IQkPUFWgr8paal8NvNQHXJP2LSJhpm/T9XTmnnZ9W8xYoZR4QQCRyv a77avfUOMiYycmXYLbkOepsPlI5jsfjWta5tppMSJaW2eicdjSe4dXMLyrpL1xi542T7 cbDZjW4HY1g1YG3pq/umUkdFMBb1Tt7f/2hV5QI2QB8+OKDvqxNkDlCoUUWCLRbLUFJh LZHEf6puQx30UMxVx+OSGzzfAcTm4FyY/PuQlxyD5KSeUjgliQF0Xod4zLnNN+QJYahy vydVk7HVjcVx7+kI0Gcqk/v0Csppn23HIyE5xsSo0V3ZwaAupuLHtA9A+NDJZVgT2l0u pHyw== X-Gm-Message-State: AOJu0YzYOuC+ejzzgXrYS7v9Yg30htFv4wynlr1YH1mEKpb5ujwZVzhk lvHRSBaVOoa83bXCCOViU2OjEMCPIOA9R1jolu47YgPT/OiFYWyHHsUozmQWzbzdPnNlU6izgqw = X-Gm-Gg: ASbGncuubofkMApwjsRil5+ktMkR9boq/MQrRJfncZYLCqY//3PBJXHnKlM7X+N08Cm XlFZi/49noE+LQDBjvwVh+2xShabGw9dH4pHlFd9yU3Ub1nadQdp9UnGJfSXsD7pfXD/kpYtcOV zzOdMzvmv5/DTXW9niw3Jw3iOFTBqnFQwNt3k7/xQDqtyT1l9yfF8uWRBIcWOtyEY0yinFHc9MA hL8owy0ebTfSxF22KHFzVwxbugWHxrZK0rJWB7/6H9sS1ywcIcjZAz/dgebMnpd0E8UXJz8zYZf RTflj6liJs1tVFNIast2SJLvbaDiqJPqeNw= X-Google-Smtp-Source: AGHT+IGewJsUbgN85FRV9cm8gLBwkQRwj30ksA46/pwbpbAmKTvfnWP5LnoPDBBp/j9xiBeNDpDEpA== X-Received: by 2002:a05:6000:186b:b0:385:e170:d5b8 with SMTP id ffacd0b85a97d-3862b3ceaf7mr9832232f8f.42.1733750674654; Mon, 09 Dec 2024 05:24:34 -0800 (PST) Message-ID: <40186a29-406e-4380-b5a0-994ed3e77cc4@suse.com> Date: Mon, 9 Dec 2024 14:24:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jan Beulich Subject: Xen 4.19.1 and 4.16.7 released To: xen-announce@lists.xenproject.org Cc: "xen-devel@lists.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, we're pleased to announce the release of two bug fixing Xen versions. Xen 4.19.1 is available from its git repository http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.19 (tag RELEASE-4.19.1) or (eventually) from the XenProject download page https://xenproject.org/resources/downloads/. We recommend all users of the 4.19 stable series to update to this initial point release. Xen 4.16.7 is available from its git repository http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.16 (tag RELEASE-4.16.7) or (eventually) from the XenProject download page https://xenproject.org/resources/downloads/. We recommend all users of the 4.16 stable series to update to this final point release; the branch is being closed. Regards, Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 13:35:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 13:35:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851367.1265448 (Exim 4.92) (envelope-from ) id 1tKdvR-0006Mx-Cb; Mon, 09 Dec 2024 13:35:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851367.1265448; Mon, 09 Dec 2024 13: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 1tKdvR-0006Mq-9D; Mon, 09 Dec 2024 13:35:49 +0000 Received: by outflank-mailman (input) for mailman id 851367; Mon, 09 Dec 2024 13: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 1tKdvP-0006Mk-Fr for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 13:35:47 +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 7ec8eb76-b632-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 14:35:46 +0100 (CET) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-385dece873cso2028688f8f.0 for ; Mon, 09 Dec 2024 05:35: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 d2e1a72fcca58-725a29caa61sm7493656b3a.38.2024.12.09.05.35.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 05:35: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: 7ec8eb76-b632-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733751346; x=1734356146; 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=Oym1n1gz6oYIDqjTLUGh0T4ay/Ij7gdHT1riqSgfr5k=; b=RIW4asfFLzvV4vf8o1Keri/WvU4zueGkiUBMK2c5eGsqMkfJESnuB0fg17Glh0dFV4 0gk6t+bXPVjqf/dOOqADcrgGvPficCFUpBmqxHAptdzEY++boGrTgYVssLz6avRzPP35 wtuA18Igngz8N10RWka3z2rg3UyYB/qqsjqNIasmv1/NSuxXiqH0EFRuE5pxGQQJ3mxC CpCV3tsJSLcckumjRUywK8hNbvoKILuSssoq4CE/1MtkxETW0JIQZeSSR76KMwQ/UCXn Cm8fyvpDDnPnJmp9CqrZRgsCKz0fthzZGAOUgfRZX02CBovM2JRBNyZcMXTaKXExIjBW s8GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733751346; x=1734356146; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Oym1n1gz6oYIDqjTLUGh0T4ay/Ij7gdHT1riqSgfr5k=; b=MHCvjvCnFwW4VW55EWdZzx5AnzHKnC3s129VgXufQMeV30Ep3DOSpqe0WCYMULLOo9 IeM7EjkcieTb9JCX/qOqQPZ9DfZUchXLe+8hLsQbCPiY4vpymGwX89xAmOb32o56Fibl h/at/9UPPFQeRz+mRII1ILqwy1LNcabOkNWfEvED81vxgaJNORHxX2DqUOdqFF8zcOcO tV+kvxpHPm3onGUcHIkRsK1gyJnhCk2smvFAiV0daY2JUXW4ihdMr3qxhATdvzqXC0zD W3++4Xi4BoI/EmNBDzooYdVgFD6JE2niXMmZY83acUW3kA6xh2Sq9uxnGHv16+VJZLe6 JGiw== X-Forwarded-Encrypted: i=1; AJvYcCXmXdkNWg+kB9P9fFRGOuOubtDS89zXKbPn9DNkUAN+dvmCk0BZVn8dOehht35VZh+tqwV95xraChI=@lists.xenproject.org X-Gm-Message-State: AOJu0YyMIQNvE8u7utJH5H9xwfha5wKQC6p62+Rn91o1TgYImquBVeZy ztAxN0gzimcfylZ94VQkuPXay7MKj6PE1h+CUBWtNrpozhkjBHkmibhDL86RoA== X-Gm-Gg: ASbGncu79UYZxKmL6nZoWEZxJX8SDgSrgyJneUb55hVMsr9v/ojskO0O1dkuPk8p67t lsAknVAP6ExfMuUXkiq7kWJLNQ4Ek80l+st3xI2eyqCDLUR7m/C+WmU+7trssVGe3QWUFV8o/fH msNv4mG59IANmCnZ5Icfug5TL+jXLQ4T6ViZYNnYmcxD+b8gd9hKKubSzgOz/NiTgi+vxvP/K1Y 6ogdw4+e0TQgSMkwAgWwQn2ojY3pcUTIvFNEwvm6xcY3QaV+iXL91rmL/QF5v9PpGYsWTvrCu6y 99pRq2f/B+ORcsdX+sVybjOjw0wVwUHA4+Y= X-Google-Smtp-Source: AGHT+IH6MQntuFB6sthY5UiB2NZIhxqe/q0bu5WnD+GRhWual/toTmrx0cj6D0GYvpuQ/TjljelTkg== X-Received: by 2002:a05:6000:470a:b0:385:dfab:1643 with SMTP id ffacd0b85a97d-3862b378d0emr8099754f8f.27.1733751345930; Mon, 09 Dec 2024 05:35:45 -0800 (PST) Message-ID: <4dff4744-8ef3-4586-9b7b-be1d42d150a8@suse.com> Date: Mon, 9 Dec 2024 14:35:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 01/12] xen/common: add cache coloring common code To: Michal Orzel , Carlo Nonato Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Andrew Cooper , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> <20241202165921.249585-2-carlo.nonato@minervasys.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 03.12.2024 10:55, Michal Orzel wrote: > > > On 02/12/2024 17:59, Carlo Nonato wrote: >> >> >> Last Level Cache (LLC) coloring allows to partition the cache in smaller >> chunks called cache colors. >> >> Since not all architectures can actually implement it, add a HAS_LLC_COLORING >> Kconfig option. >> LLC_COLORS_ORDER Kconfig option has a range maximum of 10 (2^10 = 1024) >> because that's the number of colors that fit in a 4 KiB page when integers >> are 4 bytes long. >> >> LLC colors are a property of the domain, so struct domain has to be extended. >> >> Based on original work from: Luca Miccio >> >> Signed-off-by: Carlo Nonato >> Signed-off-by: Marco Solieri >> Acked-by: Michal Orzel > > [...] >> >> +### llc-coloring (arm64) >> +> `= ` >> + >> +> Default: `false` > By default, it is disabled. If CONFIG_ is enabled but ... > > [...] > >> + * -1: not specified (disabled unless llc-size and llc-nr-ways present) > the user doesn't specify any llc-* options, LLC feature should be disabled. > In your case llc_coloring_enabled is -1 and due to 'if ( llc_coloring_enabled ... )' checks > all around the code base, the LLC will be enabled even though it should not. > > You can either set it to 0 if (llc_coloring_enabled < 0) and other llc-* options have not been provided > (this would require modifying this comment to provide different meaning depending on the context) or > you could do sth like that: I agree the below is going to be better in terms of both readability and consistency. A few minor comments though: > --- a/xen/common/llc-coloring.c > +++ b/xen/common/llc-coloring.c > @@ -18,8 +18,10 @@ > * 0: explicitly disabled through cmdline > * 1: explicitly enabled through cmdline > */ > -int8_t __ro_after_init llc_coloring_enabled = -1; > -boolean_param("llc-coloring", llc_coloring_enabled); > +int8_t __init opt_llc_coloring = -1; __initdata > +boolean_param("llc-coloring", opt_llc_coloring); > + > +bool __ro_after_init llc_coloring_enabled = false; > > static unsigned int __initdata llc_size; > size_param("llc-size", llc_size); > @@ -147,15 +149,17 @@ void __init llc_coloring_init(void) > { > unsigned int way_size, i; > > - if ( (llc_coloring_enabled < 0) && (llc_size && llc_nr_ways) ) > + if ( (opt_llc_coloring < 0) && (llc_size && llc_nr_ways) ) Excess parentheses (&& doesn't need parenthesizing against another &&). > { > llc_coloring_enabled = true; This becomes appropriate only with the variable's type changing back to bool. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 13:41:26 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 13:41:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851378.1265458 (Exim 4.92) (envelope-from ) id 1tKe0o-0008Ff-0W; Mon, 09 Dec 2024 13:41:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851378.1265458; Mon, 09 Dec 2024 13:41: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 1tKe0n-0008FY-Sr; Mon, 09 Dec 2024 13:41:21 +0000 Received: by outflank-mailman (input) for mailman id 851378; Mon, 09 Dec 2024 13:41: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 1tKe0n-0008FS-Bd for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 13:41:21 +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 45b3babe-b633-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 14:41:20 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-385eed29d17so3235899f8f.0 for ; Mon, 09 Dec 2024 05:41:20 -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 d9443c01a7336-21656c4b072sm14136235ad.78.2024.12.09.05.41.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 05:41: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: 45b3babe-b633-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733751680; x=1734356480; 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=DOK+raQKQPXK0jBYDlFfWpw3pU6n5fUrIPMio1Ddi3s=; b=cxXz81MIJVZ6mhXuvUt+d1uIYiPsD6kOi+LxQ9SYBrHFoo1B+AxpWxJ/O0tHQ0qSex pO7n2mem0YfM8q1O9sm8oxIF5Y4PBtxTHEZmens6Cxhr/diIYWfXZBkP/H+hd0zONV3Q 03L9FJcKFgXHpz/baBJwyQPb76lEXDyiQXr8GPcouj3YvRfy7Pty3iTsGD1ACAVc4pO8 ykTnOmJzx+8qvWu0v/G8RkXRnaJZYT6JPJi3LrSwapEgHIm5DVDGHvC+jJR7MGjxbiNd xE1H0Z2fZyrqemB+0bNQSbkokW1euKQzG8EAQA163F5cZ9GE8B229/2X0H+N2830hRzz v0jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733751680; x=1734356480; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=DOK+raQKQPXK0jBYDlFfWpw3pU6n5fUrIPMio1Ddi3s=; b=KZ9rOWRCzXhi2LDqwHddDwu7z+TAwTBMVKNmnQ/7PXW0ImBz/VVgVqXVgfKxsqmXar 7u/x2u66UE3VbpTkPEd9KAoEccH3CJzGLkEaXpi9cuAXbm0CjVl3iUJVgDqeyWJHZPRj gQLnG6Tp6qoTxZY9JrsgDxsHutGDlpOf/IE71PCvIvjcScC+zkXysWW78VHSk9zLJsrB VJ4DDUke/i5CriqaOeBvUmc5qQXu9y1VonSay4Nqf0brZ3a+cTxnLZuQtGmZTSdqcpzT u1niKg5fj3tCL1LmRug3e5KViR/3JmuPbkyFwTDJkLEyiMMnM+gle+NLVAo7wv+W8pYg miKA== X-Forwarded-Encrypted: i=1; AJvYcCUYNcxvgr/ZLC1l81sOSdcATLhWTcJvXRiGWA1+ysFhbxYMfUxAnrxnzIeTSiy390kvEa/xju7+dpg=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy3zrHI1OmN0BUtFAxdalfVMOMEcn09Rpntt9Syv2epsZ/rwe7V PY/2kkZbbwIFXyUuYd6XBB4ZO+aPXCr5/T3EpEXw4CKrvq0H1H6izAxV2SA/xw== X-Gm-Gg: ASbGncvv+KhSkYb+0/CbLTax+KdyqNHOjNR3+GZkW3PoNiUxY6jBGnvXyclnpXWBixF rp6p/KtaXJeERtdzzSBDpkjwCwspGUwOk61ojM6zaiWfJ6DkYRbmDQJ3tq9piNATf0w/jWnvTqP tZlSzfqCHfQ8SwcPavcg62Nv7hco7Qh+HPzNY/rU9gRnVU5F1xK3W4UxyIRmwkHcHFk7GMTIsdt fEHSyw6So7UyqtU9s75DDVQmmQrvvghzxGOtGyyC9xjYWmuAZZbo4zUDt1pPrkgEg0qyNAKgrPL Q8y6Jse4HgMA2SeDd0iBrUBGN7yhBJVxIGE= X-Google-Smtp-Source: AGHT+IGSYojpu7sw7Qd1DtZ6+9Hi0jQc/RxqFfFhA132qTnXaPRcQ6sh8GUxA4aUQj0rG97HFY+yYw== X-Received: by 2002:adf:e184:0:b0:385:f1f2:13ee with SMTP id ffacd0b85a97d-3862b3ceddbmr10117706f8f.46.1733751679703; Mon, 09 Dec 2024 05:41:19 -0800 (PST) Message-ID: Date: Mon, 9 Dec 2024 14:41:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 09/12] xen: add cache coloring allocator for domains To: Carlo Nonato Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Andrew Cooper , Julien Grall , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , xen-devel@lists.xenproject.org References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> <20241202165921.249585-10-carlo.nonato@minervasys.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: <20241202165921.249585-10-carlo.nonato@minervasys.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 02.12.2024 17:59, Carlo Nonato wrote: > +static void __init init_color_heap_pages(struct page_info *pg, > + unsigned long nr_pages) > +{ > + unsigned long i; > + bool need_scrub = opt_bootscrub == BOOTSCRUB_IDLE; > + > +#ifdef buddy_alloc_size Did you mean #ifndef? Or #ifdef CONFIG_LLC_COLORING? The latter may be more logical here, given that no fallback #define is needed for the variable. Then Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 13:59:50 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 13:59:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851389.1265468 (Exim 4.92) (envelope-from ) id 1tKeIZ-0002Zc-Fv; Mon, 09 Dec 2024 13:59:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851389.1265468; Mon, 09 Dec 2024 13:59:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKeIZ-0002ZV-CQ; Mon, 09 Dec 2024 13:59:43 +0000 Received: by outflank-mailman (input) for mailman id 851389; Mon, 09 Dec 2024 13:59: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 1tKeIY-0002ZP-Ci for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 13:59:42 +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 d541022b-b635-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 14:59:40 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-385e1fcb0e1so2505035f8f.2 for ; Mon, 09 Dec 2024 05:59:40 -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 41be03b00d2f7-7fd4657a124sm2616205a12.2.2024.12.09.05.59.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 05:59:38 -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: d541022b-b635-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733752779; x=1734357579; 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=RHTOGzomTI+5DHJuDkaDJ1TQap05hXVmYm5I2YKajp4=; b=G02WQmEMkG9RsR67IkZqJaBsXelxNUAtVPbvQZf5zzgPnzcoewIdYSiKR+t9jsRFD2 4QLK+Z2ewAgFHUg9HJu7IXS2OHe60JdACEhavu8C7tYqQfEQ93gBdvxHWgtPMA+/uayt 4iRVY3iD4Q0mSUKHp08NOsYP3ayyzxHeD1rD67CPZogGRl6EtLn7k0uVpn/MqS/vhblj s6+USx41cG7lpfnP5fxU1MByThSNYInw6gjTPM0Bj/Kcj8GHUnA2YU5WATT+LkzTfqez kecl9/JBR9ifO9FekvgJxNYNmkqpZ1p2MXDFYDrxRO0jqHLennRoL2DTxfh/FS+L+p6/ MULw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733752779; x=1734357579; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=RHTOGzomTI+5DHJuDkaDJ1TQap05hXVmYm5I2YKajp4=; b=Gy7D8kuvIYRGCWP5nEbtoiByg/stWoK9rjoVyzwy4oNQPg4FVR4Ei9F9AID8WzkjQi f0IVE+9HXOmTX+8b61+JH/PDHCnarpcqXw+TKuK0Gk1RIBIhnFHqYk3PGuXwREMz5ts+ kEHsZ3H357CqQ890hrD5eLNueQj5cwWY/jyhZUyMm6Z7St3zEOEnnLyrt3ZF7UtL4RIQ TIfhV5VIwHIUQHshLdYAAhgtBtgd8RHvCDAF1FJczw7QeqHomhqitp6/Uil1OUntdo2/ uDMmDxRgn4XGKvs+Vi64nOJOR6O5roOUmkSwifnLkXDG4GIe4InQcEppstocgrXT2+Du MizQ== X-Forwarded-Encrypted: i=1; AJvYcCWJoDwbS7CZV0IF0m5M/fud9mDd0IRbOpyuXGbC3H9WHx+tQJ6RrX7z8l95TqmAPPnkomPrRiKqaVw=@lists.xenproject.org X-Gm-Message-State: AOJu0YwTIsE8y69oNE8DeF7PR67cjxFC1Nz83mn9amSD+U+hq/126yA2 lqYhFxvMgT+jKg3bgzW3Bl+/dHzNr2v7QrS/RPIKxC7bDFZzaBoUa4KtL4KRAg== X-Gm-Gg: ASbGncthMz8XkHgfcfqzJO+RRNZWRMhaPPJcXbHm6uhbIHT3cQFXHWHzhbRyChUByDG mf7l/WL3fTw/EgvoleIDxnZOEjCtrNosblgXOewvrm9UsTuG9tr1oDZSnLlvgYCtWHf/k54F9rD mzzeqylw4Le+kIWk6cLbUwqwT0pIR40yXtTIk/iD4dMTqRLYXQ3Qa38JPiYWs2r9CXICfdqDvRJ WM6PNfVTZmPdt2ToEjpsKUwrj89EN0ts+cAPT1WrSS/BkNUqEztEQSXDy+FJtvCRROmiIXiKX79 eskdFbfyHKkOqUycK+HNdVWkA59dn9BBqYE= X-Google-Smtp-Source: AGHT+IGixjyqAYxZhDsEI2vh1C4Z8EGpOpjgu3Sx7w2uAEdI69EDZpQfOCw0aeIrquRmzfj8rkU1Lg== X-Received: by 2002:a5d:64ef:0:b0:385:fb56:fb73 with SMTP id ffacd0b85a97d-3862b3553cfmr8341058f8f.15.1733752779393; Mon, 09 Dec 2024 05:59:39 -0800 (PST) Message-ID: <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com> Date: Mon, 9 Dec 2024 14:59:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support To: Jiqian Chen Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Andrew Cooper , Julien Grall , Stefano Stabellini , Huang Rui , xen-devel@lists.xenproject.org References: <20241202060956.1124162-1-Jiqian.Chen@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: <20241202060956.1124162-1-Jiqian.Chen@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 02.12.2024 07:09, Jiqian Chen wrote: > --- /dev/null > +++ b/xen/drivers/vpci/rebar.c > @@ -0,0 +1,93 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ Was this a deliberate decision? We default to GPL-2.0-only, I think. > +/* > + * Copyright (C) 2024 Advanced Micro Devices, Inc. All Rights Reserved. > + * > + * Author: Jiqian Chen > + */ > + > +#include > +#include > + > +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev, > + unsigned int reg, > + uint32_t val, > + void *data) > +{ > + uint64_t size; > + unsigned int index; > + struct vpci_bar *bars = data; > + > + if ( pci_conf_read16(pdev->sbdf, PCI_COMMAND) & PCI_COMMAND_MEMORY ) > + return; I don't think something like this can go uncommented. I don't think the spec mandates to drop writes in this situation? > + index = pci_conf_read32(pdev->sbdf, reg) & PCI_REBAR_CTRL_BAR_IDX; > + if ( index >= PCI_HEADER_NORMAL_NR_BARS ) > + return; > + > + if ( bars[index].type != VPCI_BAR_MEM64_LO && > + bars[index].type != VPCI_BAR_MEM32 ) > + return; > + > + size = PCI_REBAR_CTRL_SIZE(val); > + if ( !((size >> 20) & > + MASK_EXTR(pci_conf_read32(pdev->sbdf, reg - 4), PCI_REBAR_CAP_SIZES)) ) No such literal 4 please. What I think you mean is reg - PCI_REBAR_CTRL + PCI_REBAR_CAP. Also indentation is off (by 2) here. > + gprintk(XENLOG_WARNING, > + "%pp: new size %#lx for BAR%u isn't supported\n", > + &pdev->sbdf, size, index); > + > + bars[index].size = size; > + bars[index].addr = 0; > + bars[index].guest_addr = 0; > + pci_conf_write32(pdev->sbdf, reg, val); > +} > + > +static int cf_check init_rebar(struct pci_dev *pdev) > +{ > + uint32_t ctrl; > + unsigned int rebar_offset, nbars; > + > + rebar_offset = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_REBAR); > + > + if ( !rebar_offset ) > + return 0; > + > + ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL); > + nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK); > + > + for ( unsigned int i = 0; i < nbars; i++, rebar_offset += PCI_REBAR_CTRL ) > + { > + int rc; > + > + rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32, > + rebar_offset + PCI_REBAR_CAP, 4, NULL); The capability register is r/o aiui. While permitting hwdom to write it is fine, DomU-s shouldn't be permitted doing so, just in case. (An alternative to making handler selection conditional here would be to bail early for the !hwdom case, accompanied by a TODO comment. This would then also address the lack of virtualization of the extended capability chain, as we may not blindly expose all capabilities to DomU-s.) > + if ( rc ) > + { > + printk("%pp: add register for PCI_REBAR_CAP failed (rc=%d)\n", > + &pdev->sbdf, rc); > + break; > + } > + > + rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write, > + rebar_offset + PCI_REBAR_CTRL, 4, > + pdev->vpci->header.bars); > + if ( rc ) > + { > + printk("%pp: add register for PCI_REBAR_CTRL failed %d\n", > + &pdev->sbdf, rc); > + break; Is it correct to keep the other handler installed? After all ... > + } > + } > + > + return 0; ... you - imo sensibly - aren't communicating the error back up (to allow the device to be used without BAR resizing. > @@ -541,6 +542,16 @@ > #define PCI_VNDR_HEADER_REV(x) (((x) >> 16) & 0xf) > #define PCI_VNDR_HEADER_LEN(x) (((x) >> 20) & 0xfff) > > +/* Resizable BARs */ > +#define PCI_REBAR_CAP 4 /* capability register */ > +#define PCI_REBAR_CAP_SIZES 0xFFFFFFF0 /* supported BAR sizes */ Misra demands that this have a U suffix. > +#define PCI_REBAR_CTRL 8 /* control register */ > +#define PCI_REBAR_CTRL_BAR_IDX 0x00000007 /* BAR index */ > +#define PCI_REBAR_CTRL_NBAR_MASK 0x000000E0 /* # of resizable BARs */ > +#define PCI_REBAR_CTRL_BAR_SIZE 0x00001F00 /* BAR size */ > +#define PCI_REBAR_CTRL_SIZE(v) \ > + (1UL << (MASK_EXTR(v, PCI_REBAR_CTRL_BAR_SIZE) + 20)) The literal 20 (appearing here the 2nd time) also wants hiding behind a #define. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 14:24:20 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 14:24:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851407.1265477 (Exim 4.92) (envelope-from ) id 1tKeg7-0007w0-Gh; Mon, 09 Dec 2024 14:24:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851407.1265477; Mon, 09 Dec 2024 14:24:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKeg7-0007vt-E2; Mon, 09 Dec 2024 14:24:03 +0000 Received: by outflank-mailman (input) for mailman id 851407; Mon, 09 Dec 2024 14:24: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 1tKeg5-0007vn-NU for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 14:24:01 +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 3af2fac6-b639-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 15:23:59 +0100 (CET) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-385f07cd1a4so3047007f8f.1 for ; Mon, 09 Dec 2024 06:23: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 98e67ed59e1d1-2ef68b5272bsm6411984a91.37.2024.12.09.06.23.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 06:23: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: 3af2fac6-b639-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733754239; x=1734359039; 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=F5DZ+ock8zHt0R+/SU2irDxJUMssKf6St5OzoYVDPVk=; b=BXBReDfu9LKVsThRXbn3r/1lR5wBQOMEeGxl675aaDmfzLuXU5TNPnYaDb4V4hAyDf axVlg0WhrzBXl872/tNHTGEjqb/+FgCMSQ5P+j3USrknGwhPXgqavh7g07/LSWW+4nA2 6svCFb4CvU66hrIemrNhVvzrMCaPp69V0V+WWq3t4y3KOBsqP2QmLdnNCL5x569/l6zl Wwje/qPQuWSewPcMc1NpmozHgVfbKOr0bdqjFSuCaccN1fcA2kQ0vfluHf4kAkGgQQjF ZoPRvN97+zQdA/kcvw+pslgEdzN55rCcbO+aWXnKssLcPTsPTpzYkAKp5CIs6WKL5hsa vuqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733754239; x=1734359039; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=F5DZ+ock8zHt0R+/SU2irDxJUMssKf6St5OzoYVDPVk=; b=YF664JljtgzLIxVgSZmzxVoMOpJHVvQb+E/DmamUIKwpMXMR8nmF9CGQJjQbZBt0SP D7mwQ7T20RtjbSk8/JNMfB0OEBp+h9TZj8rs0GkIK6LEYlr7093tSisenFYsx03RLxAM 5NrzlVjkIhk6EgnoHAyFiFJ0ez+0LuGEeN72tz3GyXjsxmfWjxr/ZtB0mlS7V9+fRdCr zn9R/hGIZdk5yI8z+8dg0ZiD/2ErGHrknyc3vhfj6TZapoQkF6GMbOK/PZr8nOGVv9Xb 9SWfgpRXYtWqKcalgbU8XNju9rnuITm+N+Mxu/5Vb3+EfV0INsY+suPNmNe9L8zly/+0 iJbQ== X-Forwarded-Encrypted: i=1; AJvYcCVMKMae3cQQ64MX9vjBuWO5WPkCLKbupPs/So84pmw6xuXd2X7/H1DBUlBicz8eP4DqW3H0IDUWgeQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YwbEN0ZF6xiEjvDUf3lNgNes4VaMJA1vOoU1G47FlIsRTIElobf mGt0Ocm9r7EWUorGdGZUoXt6TutwJMYCDijLpxYXCO4nG3ImpFA/f8DuCJi3Yw== X-Gm-Gg: ASbGncv0DU9DLFIgZE7mWBvbKHqsV9TnQd4hgWDLLZ8+LwAXUdZriuQtAabp6bhC6Pw MDkO1XqiZBG3E2PRr4XuTwPpdlRkQmWl6nLg3aP5shKDyVn6pnzAGNqTPIq+9nSYhut0+ut+Ba9 fsLqzSEECUfLdnhuo3lgeqIJrBf0leL6sjSR7tEpcRTbBBA1WCqbOEDf8gichusckjOFsT9NjMh 2FKfadyjSbO7VvP1yogp9FE8MVWii16DUdcOqor3yC6cvk0HuARTuQw72SgYpjhqZ7P3ci/8KwR 4WoaDfvPctF+l4HsIK/vA5TsA+oz5YO75QI= X-Google-Smtp-Source: AGHT+IFppX50DV3BX7AecFmAA3NQDPtgFoSAx4oYg7nfJGxX92yUf54O3S30R2z//I0xxqcooS0mfw== X-Received: by 2002:a05:6000:3cc:b0:385:fc8c:24b6 with SMTP id ffacd0b85a97d-3862b382d9amr10978658f8f.27.1733754238842; Mon, 09 Dec 2024 06:23:58 -0800 (PST) Message-ID: <0640888f-3b9d-4f5c-9797-856374f16155@suse.com> Date: Mon, 9 Dec 2024 15:23:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/6] xen/riscv: add destroy_xen_mappings() to remove mappings in Xen page tables To: Oleksii Kurochko Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , Julien Grall , 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 27.11.2024 13:50, Oleksii Kurochko wrote: > Introduce the destroy_xen_mappings() function, which removes page > mappings in Xen's page tables between a start address s and an end > address e. > The function ensures that both s and e are page-aligned > and verifies that the start address is less than or equal to the end > address before calling pt_update() to invalidate the mappings. > The pt_update() function is called with INVALID_MFN and PTE_VALID=0 > in the flags, which tell pt_update() to remove mapping. No additional > ASSERT() is required to check these arguments, as they are hardcoded in > the call to pt_update() within destroy_xen_mappings(). > > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich However, ... > --- a/xen/arch/riscv/pt.c > +++ b/xen/arch/riscv/pt.c > @@ -421,6 +421,14 @@ int map_pages_to_xen(unsigned long virt, > return pt_update(virt, mfn, nr_mfns, flags); > } > > +int destroy_xen_mappings(unsigned long s, unsigned long e) > +{ > + ASSERT(IS_ALIGNED(s, PAGE_SIZE)); > + ASSERT(IS_ALIGNED(e, PAGE_SIZE)); > + ASSERT(s <= e); > + return pt_update(s, INVALID_MFN, PFN_DOWN(e - s), 0); > +} ... I'm unconvinced the constraints need to be this strict. You could, for example, very well just avoiding to call pt_update() when s > e (or really when s >= e). Thoughts? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 14:24:33 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 14:24:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851413.1265488 (Exim 4.92) (envelope-from ) id 1tKegb-0008Mr-PF; Mon, 09 Dec 2024 14:24:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851413.1265488; Mon, 09 Dec 2024 14:24: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 1tKegb-0008Mj-Lb; Mon, 09 Dec 2024 14:24:33 +0000 Received: by outflank-mailman (input) for mailman id 851413; Mon, 09 Dec 2024 14:24: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 1tKega-0007vn-7H for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 14:24:32 +0000 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [2a00:1450:4864:20::42f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4d935129-b639-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 15:24:30 +0100 (CET) Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-3863494591bso1023679f8f.1 for ; Mon, 09 Dec 2024 06:24: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 98e67ed59e1d1-2ef2708b8f7sm9846142a91.49.2024.12.09.06.24.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 06:24: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: 4d935129-b639-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733754270; x=1734359070; 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=xza+nitPHaeOIRJlQMRvXUUaHgI74PCwz8BIrlAVq8s=; b=f9ZBloRiZfZ8blZOukxRM4n71i9cYWvbryt7WKqrXR8Ebf4KRkpI6sZdwBkhPCQGyA uaHYZwo4EpRV3X3RKb4dyAFdGpuOHTBw8keNAcJKHwOj5v+hXdEWyjLgJurxWrXAw58O AfcRN9Nbws+uIWVv+UIH0NEw2/BSz2h5f2J6gLb1QtUWRpUnZrf2erCjz7EgCXcZyxMW ULhiEVRqH5rGzZB7F3guAd/wP1vg2tAcBJF1hbz1iUL6IxKpIV596XZ1lEzQ0FqV+MNc 6koz4ZWRYvoOiAGowuMV2kAEktoOl2m0UTMi+qlg8x/D09aI2OW+w9sYKuzp8oYKC7R6 0o3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733754270; x=1734359070; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xza+nitPHaeOIRJlQMRvXUUaHgI74PCwz8BIrlAVq8s=; b=liOdQnoCp4mpg0LrA/XXyadgUFiaIYhcSNqoNDWXVoFaJ1W2aCbBgZNfgzyRN14V2J J6Pp1LCIbYE/Pk4Vawk60UmGe4Ds1y1dghw0wzQKoFirF0XfvQUDqnXt27bUh29z2ij3 M/tK/sTaQ0iULyF0TvArM8/d12/E7DOAA40j+Hbh4Flc80oH0B5uTK6Lt7yro3mfwgVn jFHGbpd4LebaeM+89dQ86/IdhotgkUOTUsunR2YzyeXTfGCKxycIZ80S8fY3VyRA96VX Opn151NFi6+8cNNr2/ZuSGa+9PjDuZ6QzBZ0aY7YwAzsvz5V0k4oJKB2tOcgACW+tndV iBdQ== X-Forwarded-Encrypted: i=1; AJvYcCX/fzGLh+IJskSR+EMZIWrnUPE/D6fh2qZvXwdDtF5E+8VEo7FNamp3qdi4jI+No+8QgDZ1Z7KS7eo=@lists.xenproject.org X-Gm-Message-State: AOJu0Yymh1RvwGa5VzjDAhngYUydHjfWrrUxTveIzWjAlQWRoIaLXhVo M6jixHPTKgfVtl++mv5JIGcBchIs9d8bmffDPdH9ylYkGV8331X5RtNDL86ABw== X-Gm-Gg: ASbGncumnUd7zbAANQix5CyGErXW3gZhDIFbzTGT8GJ5CVLWmNl3XXRE37uVHD5XiTX psV3GnZ+N5p9N+FH2QnouXq0KCPllJXqcPWGEKnsXAayg4e/zlX6czjNlh7oNBZPVsnBwlRdv6N nV3NbEYpD82VR3zrC5PC/sarTu6PIUtElO3dzerJn9gYeta/6yHHqgV8kUVSe12xInaxEE3wrao Zzvnp53KKbtRwSnBfXKi9uMAJ9ycixe2G/Uu9Hf4/KvekajrIlHd0MwKlh2aQbf6OXTjbrrb9nL GekV9eQtlQUnOFfPf7XIMmsra13k32d7fOY= X-Google-Smtp-Source: AGHT+IFIwNCdqD80RGiAPLqkjZVd5JuPc2NnouMJsWWAwjoFRsp+/9MZJxLfuLNvelzeeR3axyfBhg== X-Received: by 2002:a5d:47c9:0:b0:385:db11:badf with SMTP id ffacd0b85a97d-386453d6c46mr471864f8f.22.1733754270185; Mon, 09 Dec 2024 06:24:30 -0800 (PST) Message-ID: <17acd01b-2342-4daa-b73c-9f118da38e17@suse.com> Date: Mon, 9 Dec 2024 15:24:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 2/6] xen/riscv: reorder includes in asm/page.h alphabetically To: Oleksii Kurochko Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <4b458dea207cc6f2c2ab5d5a3d67ca9f6d5958da.1732709650.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: <4b458dea207cc6f2c2ab5d5a3d67ca9f6d5958da.1732709650.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 27.11.2024 13:50, Oleksii Kurochko wrote: > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Dec 09 14:29:55 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 14:29:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851428.1265497 (Exim 4.92) (envelope-from ) id 1tKelj-0000qD-BS; Mon, 09 Dec 2024 14:29:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851428.1265497; Mon, 09 Dec 2024 14: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 1tKelj-0000q6-8p; Mon, 09 Dec 2024 14:29:51 +0000 Received: by outflank-mailman (input) for mailman id 851428; Mon, 09 Dec 2024 14:29: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 1tKeli-0000q0-6s for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 14:29:50 +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 0ae59508-b63a-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 15:29:48 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-434f80457a4so5982085e9.0 for ; Mon, 09 Dec 2024 06:29:48 -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 d2e1a72fcca58-725e71ce821sm2733662b3a.183.2024.12.09.06.29.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 06:29: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: 0ae59508-b63a-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733754588; x=1734359388; 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=2MlTmTWDs6VrTPaxU79Si5fl1PwiSEPiVUomIzVJ6dA=; b=arZcyP06aLx3X2l+nmWhc+W0VdPxxk5hK1xDQsNN0RPJjg6YEEx1KBq2UfsyWdp/zE JNgrYH7RfsiIjy77UO/Xb0qiu77CKiI4gzqR6M5j4Lht3rJ/G0axdl0vtBNnJOOkst8u qN6f8Pjz/G+/MCTaAHM7Z58qcGV67l8wTYkUT4QS4LYNj86IOKRK2ySJB3mbUxM1lj5O pi2CuNPpGuWRU72BpuFWottUF6Berp8MVwq82+7B60LHoiT2kC31SGDxIeFbOyoyMwYB DAQD0w9w7t0tbDO82gFy0zZZoLuQEJR712+SKPB1wrK2VhbSmH5QpTZduaKUSW2dI39h gNgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733754588; x=1734359388; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2MlTmTWDs6VrTPaxU79Si5fl1PwiSEPiVUomIzVJ6dA=; b=FMBEZwqpombwL2vubpjFp9ds465M6ElLvri4jMadr1jc2en51hZRxrHrScTGHBHunJ 9yH3WGxqFe1FKRp4mtaAXWD/f2RJ+90rKLHxezKnYuNexjCnlDjc39ENFPflCyAmYg24 xa1FKmls78F397aoRJt6P5Kb/XmU4Xz7xRnRN6vG3Ku6t3kCJttHh2ZyJiQrCDqYKzZv 06M+5GDqWcZRqvOP1HMzbDyL5tYdIQ/kJpWiugEGhZd9Md7NC3FYAQSU/ztqrp1fowh6 kdS1vD3UQbyw8G4OyBBzVl7aH86RNQZMHeO8jS7wODomb3ZllbAQVaJI1WsAcRF5hh3h dIXQ== X-Forwarded-Encrypted: i=1; AJvYcCVy73kihom7GzuxDtk3WNvtCZVnXbUFU4cztvu7QsTfwlewJljQ5RbCt51enMxv/g/eJ86FWRtnh+g=@lists.xenproject.org X-Gm-Message-State: AOJu0YwTegRV0//J9YvnHuVpo5fWBemcMXER5f/5ejvDWTwIocxr/qgX JK29k3fP0qdqBlrgJDO/+gRdNckNs/8QH0tqlaRkYduHspaPC3Ank0xu8RKw0A== X-Gm-Gg: ASbGncuvyWQrqrrZgGSTaoeSg3/y9MqO/SivcyI3+pMFf9h79jrsLhee6TLv/IaIqfc rv8iqRhOU5H+FKT+4pKJW7HgxADsVUZizW1OXKDkiHBsUmXSvXLUzZlzVSOwvsQ3B6fIoyAeCpA GDbb3sDz5ZJ/dfi0xmS6Dk6VPsxJ5zBoT5fW066TEIbXfk7RuntTQFYxe5uEDHKYHeXz2zFlOF8 ECH7JoEBaX/vLL2svZRb8IBNaxYlhR+mwty9RTIhFW9uEHxCVLnAqqJpme2eaVD937YBrT39DyH 7cTf2PlIrLyzKBl1y/0ull8xMbhNH4SZuXY= X-Google-Smtp-Source: AGHT+IGHTi5buNiVzOsovjRQgHKW1h3uDsUJdrOb9jadqUV7h7t0DcDXO5e91rh6NdChrlKyfrEE7g== X-Received: by 2002:a5d:5889:0:b0:386:3d33:a61a with SMTP id ffacd0b85a97d-3863d33a7d8mr3233896f8f.27.1733754587729; Mon, 09 Dec 2024 06:29:47 -0800 (PST) Message-ID: Date: Mon, 9 Dec 2024 15:29:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 3/6] xen/riscv: add {set,clear}_fixmap() functions for managing fixmap entries To: Oleksii Kurochko Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <2badea2de39b7614d38a620d1b718478de1fc82c.1732709650.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: <2badea2de39b7614d38a620d1b718478de1fc82c.1732709650.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 27.11.2024 13:50, Oleksii Kurochko wrote: > Introduce set_fixmap() and clear_fixmap() functions to manage mappings > in the fixmap region. The set_fixmap() function maps a 4k page ( as only L0 > is expected to be updated; look at setup_fixmap_mappings() ) at a specified > fixmap entry using map_pages_to_xen(), while clear_fixmap() removes the > mapping from a fixmap entry by calling destroy_xen_mappings(). > > Both functions ensure that the operations succeed by asserting that their > respective calls (map_pages_to_xen() and destroy_xen_mappings()) return 0. > A `BUG_ON` check is used to trigger a failure if any issues occur during > the mapping or unmapping process. > > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich However, ... > @@ -433,3 +434,21 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns) > { > return pt_update(virt, INVALID_MFN, nr_mfns, PTE_POPULATE); > } > + > +/* Map a 4k page in a fixmap entry */ > +void set_fixmap(unsigned int map, mfn_t mfn, unsigned int flags) > +{ > + int res; > + > + res = map_pages_to_xen(FIXMAP_ADDR(map), mfn, 1, flags | PTE_SMALL); > + BUG_ON(res != 0); > +} ... imo in such cases it is preferable to go without a local variable: if ( map_pages_to_xen(FIXMAP_ADDR(map), mfn, 1, flags | PTE_SMALL) != 0 ) BUG(); Just to double check: Iirc this BUG would in particular trigger when trying to set a fixmap slot that was already set, and not intermediately cleared? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 14:35:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 14:35:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851438.1265507 (Exim 4.92) (envelope-from ) id 1tKerK-0002ob-Ub; Mon, 09 Dec 2024 14:35:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851438.1265507; Mon, 09 Dec 2024 14:35:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKerK-0002oU-S4; Mon, 09 Dec 2024 14:35:38 +0000 Received: by outflank-mailman (input) for mailman id 851438; Mon, 09 Dec 2024 14:35: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 1tKerK-0002oO-1C for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 14:35:38 +0000 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [2a00:1450:4864:20::52b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id dad28a21-b63a-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 15:35:37 +0100 (CET) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5d122cf8dd1so7223563a12.2 for ; Mon, 09 Dec 2024 06:35: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: dad28a21-b63a-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1733754936; x=1734359736; darn=lists.xenproject.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=MgJHBj8dWe6d+WY6U/eQkzjv4lbdNoswat5wV0xftN0=; b=hQVQR/M2tPwiitbeNRG53277fzwoSgOrp8Ry+HNOnbrF29Id0cIFkd17WO/AkZWp6H x+oNejMPu50MvSJbTQtFKuvw9h8uqN7xkM9b9EFzZbxAADqZJP99OOdvbC/sFi7ic/6/ mY67kduXxJHC69VORygS7hNqKNfz61dOLWgAI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733754936; x=1734359736; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=MgJHBj8dWe6d+WY6U/eQkzjv4lbdNoswat5wV0xftN0=; b=jox+bzNOzae/M3q7BbbM7iV00gDBJjrwf56MXlLh2gNZoJSfNvrsUWMbhH/+cf2ou6 FWJZVB1fwfxlOJrZf2ixKykjrUyvvh8LZ7EOPujVfX4zWALm3mFIJduPVR8oUidoVeKl lNWiUvqyszyPwT5g3KO2Sf6FggzniHm/EJGxlGs1/k6O4v015kgNJ8DajRrb7AJj2X9A wm99ulNln+aO3sen3tmyKTN+kThQcW2l4XH0qQV0TtwLf845NodxRGJEvYhntETX6BGG zZS7JSBPYoLmTwyObXorv5YEGCtdEM5mf046JgG0BLIfzqEq5ZAiCY0mWKmGhq5wCWUY BU7A== X-Gm-Message-State: AOJu0YylEIRRZgt6ZhhYQyTMoSWClqXGneaUBVXVSHPEl5Wk9ioTlFtF LR1S439jv8HjkjDcVnINEGrzF4SxnNYqWFsA9Cv2rUNaueJsOupewPBruU/0IUAdLlpgB1vdZuR Wo2sUhdXhaYwf80nyleC8z0E8Vu5cqcJg8YShC3kW/weRfNn0jhQ= X-Gm-Gg: ASbGncvxzQi1JbAyPAbqmgW1b5BIx/cVqgWTtNovU86S8y1knrYJy/J6I3jzlGpnQFi 3pnvEaJaqhcLIC3r3SK3EiC7utxo83nnfWnb82COqXZI4bH23Sz6R99d5s36KzLfTUhgf9w== X-Google-Smtp-Source: AGHT+IELReHT6avVznhXJY7M6bz6KB4XMluedWzWmHuvu66Hc6YP1D2WPJzf7BLZVas6+sQVY8wO9bkWrOJzfudou3c= X-Received: by 2002:a05:6402:390a:b0:5d1:43e4:bcaf with SMTP id 4fb4d7f45d1cf-5d3be4656bemr13941689a12.0.1733754935795; Mon, 09 Dec 2024 06:35:35 -0800 (PST) MIME-Version: 1.0 From: Kelly Choi Date: Mon, 9 Dec 2024 14:34:59 +0000 Message-ID: Subject: Welcome Honda to the Xen Project Board To: xen-devel , xen-announce@lists.xenproject.org, "committers @ xenproject . org" , Xen Project Advisory Board Content-Type: multipart/alternative; boundary="000000000000137f070628d747c8" --000000000000137f070628d747c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, We're excited to announce our newest Advisory Board Member Honda, to the Xen Project. Since its foundation, Honda has been committed to "creating a society that is useful to people" by utilizing its technologies and ideas. Honda also focuses on environmental responsiveness and traffic safety, and continue to take on the challenge of realizing a sustainable future. I am sure that the community will agree that this is a huge step and achievement for our open source project. Honda's investment into supporting Xen means we are expanding our efforts to create a more secure and versatile hypervisor, with real world applications. Their commitment and partnership with Xen only increase the capabilities that our virtualization technology has achieved so far. With Honda joining, their insights will help us navigate new challenges, expand our outreach to new contributors and enhance policies surrounding our community. Their unique perspective will be invaluable as we tackle goals for the future, and we=E2=80=99re thrilled to have their voice guiding our strategy= and vision. Please join us in giving a warm welcome to Honda! We=E2=80=99re eager to se= e how their leadership and technical teams will help shape the future of the Xen Project. Together, we=E2=80=99ll continue building a strong, inclusive, and innovati= ve community. Kelly Choi Community Manager Xen Project --000000000000137f070628d747c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

= We're excited to announce our newest Advisory Board Member Honda, to th= e Xen Project.

Since its foundation, Honda has been committed to &qu= ot;creating a society that is useful to people" by utilizing its techn= ologies and ideas. Honda also focuses on environmental responsiveness and t= raffic safety, and continue to take on the challenge of realizing a sustain= able future.

I am sure that the community will agree that this is a = huge step and achievement for our open source project. Honda's investme= nt into supporting Xen means we are expanding our efforts to create a more = secure and versatile hypervisor, with real world applications. Their commit= ment and partnership with Xen only increase the capabilities that our virtu= alization technology has achieved so far.

With Honda joining, their = insights will help us navigate new challenges, expand our outreach to new c= ontributors and enhance policies surrounding our community.

Their un= ique perspective will be invaluable as we tackle goals for the future, and = we=E2=80=99re thrilled to have their voice guiding our strategy and vision.=

Please join us in giving a warm welcome to Honda! We=E2=80=99re eag= er to see how their leadership and technical teams will help shape the futu= re of the Xen Project.=C2=A0

Together, we=E2=80=99ll continue building a strong, inclusive, and innov= ative community.

Kelly Choi
Community Manager
--000000000000137f070628d747c8-- From xen-devel-bounces@lists.xenproject.org Mon Dec 09 14:38:16 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 14:38:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851461.1265534 (Exim 4.92) (envelope-from ) id 1tKetr-000460-NR; Mon, 09 Dec 2024 14:38:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851461.1265534; Mon, 09 Dec 2024 14:38:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKetr-00045t-J7; Mon, 09 Dec 2024 14:38:15 +0000 Received: by outflank-mailman (input) for mailman id 851461; Mon, 09 Dec 2024 14:38: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 1tKetq-00045b-AI for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 14:38:14 +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 36ea728c-b63b-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 15:38:11 +0100 (CET) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-3862b40a6e0so1756466f8f.0 for ; Mon, 09 Dec 2024 06:38: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 d2e1a72fcca58-725e6e024e4sm2681374b3a.153.2024.12.09.06.38.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 06:38: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: 36ea728c-b63b-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733755091; x=1734359891; 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=yjznvzia8L7cn+R9yJXaE8tIG2h0LZWNmkUvJzkbIH0=; b=TGOycM6ovN30mYI3KiemLrSDxgfbzVrx2JO1xo+d2HfEsB6wyLuotpQ5u/zt7TSIz/ 3kOXzfGtTlYD6BU0uB1G9GLDZWH1cdDyoFyL7lrTFdYezb6FWeoUFYa5W64KQHDR2bAW Wo9F+o3UE+T2mMiGCJflVWJvldp5AXkNO8t+Ef3q7Qfy9+xE6cuxXGaX0QKEaMLdzt0/ lJBWjeWOc3Lx9BWE9DYOyvgW9BpAerNOg+RZB59DTM7BiB2DsApY2skHkYUZgB0B25QI zOXF6AfpfNTGdo1ptYz3rKQXvZrc5/QcH2y54hmTEX4wNJFZkYLLUJrcclz9EPYwe+bV 6F7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733755091; x=1734359891; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yjznvzia8L7cn+R9yJXaE8tIG2h0LZWNmkUvJzkbIH0=; b=hH3t5lUxIxx56ToScLEU49lTwn9QbmkLozPt2QCRa0ewWLb+zZE3yNeyDBmx8kLVD7 YCa5ezOJOoKlV8Ag6+jjTaGQq7CTaEAOOUT+dWLtsq7EjbO4Zvfq4kOIkvgVQdpNKzuT ats1cbTLE4/84fj5nmz5IfsjLuXHZzNnF4frepDrJcADHKZU9Wf7ijSjAFFzUB5KYPYi 0yyJsG8et2Si99s1ZRAZLsUjHzifVzw/T9kHIca9L6g0P7q9iLji5S6mIeVmI0v3q/4t foufhwwNt/7GLcKtJ6aDJ4kmua7hbojaYmEfaXxbqJLznxhHlogD1xMyg0kz4OHMD7C0 ykCA== X-Forwarded-Encrypted: i=1; AJvYcCWU+O6QFHp4mTBJbyeZQI6+1Cd6Xa8GxIrlzL3QyI9B5em8QFVpFdrAanMdvNhYtXHgQ5wwNPqePGY=@lists.xenproject.org X-Gm-Message-State: AOJu0YwrHHNvdmAw5ktRjHlZTCco9pzXYWybJLSrPwixxe8hguuwGwm3 SYgkLCoyJOGttyh/FOtq1aIetHYauds91ZU5y8B19J12urngOQEwEgnae6rNBg== X-Gm-Gg: ASbGncufdf0g3cXlIyiEy/dytX3Iv4n5KX6gZbsrdEw93xVh35ndmi4PRCC4XlzLo8u /2dlVdpiBtl7Gxe7XlQB8arjYTNi0jtDBOj93crRO0FNLRPczXs0+aGcSjXZURQsaYoPyt4k1+e qhuyF94PDgvZLyDdzDi3Ch6TGx7lIFz4XLLUr4xoBfmr09odYklw3aDof/a6ZCLpEqq9LoEoPUx wqcp6Xp7zyvA0hs7ZuMy1s8qXNSJ/fI/0zk/rjemhNOYFBX2VDxGw6DmD7Ve8A/6P1IEIswt28x J+BQNGXJ9PX29HIX9vHWfYlY9n3cH0x0XfI= X-Google-Smtp-Source: AGHT+IGEYufCWGLGHCMog2quGHZZ/nnkpfO/i8j0k3l/4WmzgkUnIvSiDFDZonOlCZKoBK/mdYyw4w== X-Received: by 2002:adf:ffc6:0:b0:385:f979:7664 with SMTP id ffacd0b85a97d-38645402da0mr413804f8f.58.1733755091168; Mon, 09 Dec 2024 06:38:11 -0800 (PST) Message-ID: <9d49befe-4592-4e71-ad0b-9a0af34253f5@suse.com> Date: Mon, 9 Dec 2024 15:38:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 4/6] xen/riscv: introduce cache management operations (CMO) To: Oleksii Kurochko Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <1310a2fb3b9824ae66f850600925127fdfdb44fa.1732709650.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: <1310a2fb3b9824ae66f850600925127fdfdb44fa.1732709650.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 27.11.2024 13:50, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/Kconfig > +++ b/xen/arch/riscv/Kconfig > @@ -14,6 +14,9 @@ config ARCH_DEFCONFIG > string > default "arch/riscv/configs/tiny64_defconfig" > > +config HAS_CMO # Cache Management Operations > + bool Hmm, and nothing ever sets this, and hence ... > @@ -148,9 +149,24 @@ static inline bool pte_is_mapping(pte_t p) > return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK); > } > > +#ifndef HAS_CMO > +static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size) > +{ > + return -EOPNOTSUPP; > +} > + > +static inline int clean_dcache_va_range(const void *p, unsigned long size) > +{ > + return -EOPNOTSUPP; > +} > +#else > +int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size); > +int clean_dcache_va_range(const void *p, unsigned long size); > +#endif ... all you really provide are stubs and declarations, but no definition anywhere? Plus of course this gets us into feature detection territory again: If RISC-V provided a way to detect presence / absence of certain extensions, this really shouldn't be a compile time setting, but be determined dynamically. > static inline void invalidate_icache(void) > { > - BUG_ON("unimplemented"); > + asm volatile ( "fence.i" ::: "memory" ); > } That's a separate extension, Zifencei, which I don't think you can just assume to be present? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 15:00:31 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 15:00:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851481.1265543 (Exim 4.92) (envelope-from ) id 1tKfFH-0000Ee-DY; Mon, 09 Dec 2024 15:00:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851481.1265543; Mon, 09 Dec 2024 15:00: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 1tKfFH-0000EX-9g; Mon, 09 Dec 2024 15:00:23 +0000 Received: by outflank-mailman (input) for mailman id 851481; Mon, 09 Dec 2024 15:00: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 1tKfFG-0000ER-41 for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 15:00:22 +0000 Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [2a00:1450:4864:20::42d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4ec63f4d-b63e-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 16:00:20 +0100 (CET) Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-3863494591bso1048285f8f.1 for ; Mon, 09 Dec 2024 07:00:19 -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 98e67ed59e1d1-2ef45f958besm8031793a91.16.2024.12.09.07.00.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 07:00:18 -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: 4ec63f4d-b63e-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733756419; x=1734361219; 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=pRkhkVE1M4pT0otgBa8h2fRxOn6ExP/sAgfQXk+ukcI=; b=KkitFS+8MLznQ0o4kKmW097xG9ereA7r0Gs77cjxTErBxVRsGE6Ry0fidUXzgbTSm9 k6fQAwbaTznCoDebcUlK83S7PLxnynBocyDuCokotTJ3jduSGbs5cI5PlFABmIi4p8Na E1Wncmf3rpAMlmuyLdkmE00FW1LI+lhATT/qrkn80KhdKNxMa4VNmNfVSIXIdx1j3cmq z4uzRHGTqY9Bp+E/SJxexYbLAMTbTmDQzOB+mHu3sLQXL06N1hOtWjfAVsj7ZiYlf9cE na4KDbVO9p1dFXPdJ2OtxtafG7uCETp6Yckx+nxShU1Az+XDCvbTHKK/HpiDVh7dmrXh 2YuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733756419; x=1734361219; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pRkhkVE1M4pT0otgBa8h2fRxOn6ExP/sAgfQXk+ukcI=; b=pzFxLeYpjkdwgqAYg27x9fGrjj9oQ10k/7QxDTUpITYOEqj8up5kMwHGCExZGhqVWO D6daIMvyDm24rwiCYddnzh3dju12w+rMR1HewabXWusCXbVT05GrJCgXSkEQzETAj6jE kX0x/u+RTgUf+cJU1AVaftjfZyHqRlFi5LH4RdO3W+g9JKadVUT5aSnJry6fEdPlf2lG 5ZRwnU1rUi6vXslqD9BmWPjV0OWElusuXlaNUkhZbJeTb1EMZIjGA6a4qvT/fZ400W2+ vwICdXwrlWFw5j2KQvqbxtgCAHQVd+kGoYHzI0j2wu1cRE/UrAVlJtrWhZLAiW9K1C/i N1sQ== X-Forwarded-Encrypted: i=1; AJvYcCWMAWsWERkDlRFT+1d764YmEEC3+KLy283+Mi6QVKQmKBes75KthREs98d7Eiw9GUWyU4Nd+IFdk0Y=@lists.xenproject.org X-Gm-Message-State: AOJu0YxF9q4B///9CAyPmw3jpKftWyGMnjG/q2iys+jlPQM7oeo0XkOL luyHaDLtgArK/PNnppo8UgNF9INwME9biw4ba1Hgnf/u1unAwL3CtzywXYBsUw== X-Gm-Gg: ASbGnctwF7auQdSFifePPgBnNhRe5RtUtMCu/zViOgFDcJ5Xwdu8XNGLeDs+AkV88PL rJoJAN2iei6L0URMGhuhR4UGIieggGvw0vdwMepXQhRZnAt5mA3Tf9horsymJw9Eh39/Sz80Dld ocv8JHhOoECrHOfl9hgCLn7u0t4bOmFm/0iFjAD/RwxiyaxfTFVSzV3C/JZg7MlBzZlO/tqcDTf XLPfXTltjmvvEuUjiSFFi/ahr7IrALv1NZ6L7PUVz+TA2gk6mScYTlh0COhQ+4guo5mjn3HV68l heCeOz/pcoOsEE3vu/qs2Jh54z1yN8PPXI0= X-Google-Smtp-Source: AGHT+IGDLKKPuaH+JHItNb5vZbpBZHQfokqtWQHloTLNcL0BX86dA8c+yAtd/IRrYkU1mieG4tB65A== X-Received: by 2002:a5d:5f53:0:b0:386:5b2:a9d9 with SMTP id ffacd0b85a97d-386453fbd04mr577561f8f.53.1733756419223; Mon, 09 Dec 2024 07:00:19 -0800 (PST) Message-ID: Date: Mon, 9 Dec 2024 16:00:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 5/6] xen/riscv: implement relocate_fdt() To: Oleksii Kurochko Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , Julien Grall , 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 27.11.2024 13:50, Oleksii Kurochko wrote: > relocate_fdt() relocates FDT to Xen heap instead of using early mapping > as it is expected that discard_initial_modules() ( is supposed to call > in the future ) discards the FDT boot module and remove_early_mappings() > destroys the early mapping. > > To implement that the following things are introduced as they are called > by internals of xmalloc_bytes() which is used in relocate_fdt(): > 1. As RISC-V may have non-coherent access for RAM ( f.e., in case > of non-coherent IO devices ) flush_page_to_ram() is implemented > to ensure that cache and RAM are consistent for such platforms. This is a detail of the page allocator, yes. It can then be viewed as also a detail of xmalloc() et al, but I consider the wording a little misleading. > 2. copy_from_paddr() to copy FDT from a physical address to allocated > by xmalloc_bytes() in Xen heap. This doesn't look to be related to the internals of xmalloc() et al. > 3. virt_to_page() to convert virtual address to page. Also introduce > directmap_virt_end to check that VA argument of virt_to_page() is > inside directmap region. This is a need of free_xenheap_pages(), yes; see remark on point 1. > @@ -148,8 +150,12 @@ static inline void *page_to_virt(const struct page_info *pg) > /* Convert between Xen-heap virtual addresses and page-info structures. */ > static inline struct page_info *virt_to_page(const void *v) > { > - BUG_ON("unimplemented"); > - return NULL; > + unsigned long va = (unsigned long)v; > + > + ASSERT(va >= DIRECTMAP_VIRT_START); > + ASSERT(va <= directmap_virt_end); Why the difference compared to virt_to_maddr()? Also recall my comment on one of your earlier series, regarding inclusive vs exclusive ranges. Can that please be sorted properly as a prereq, to avoid extending the inconsistency? > @@ -172,10 +173,15 @@ static inline void invalidate_icache(void) > #define clear_page(page) memset((void *)(page), 0, PAGE_SIZE) > #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE) > > -/* TODO: Flush the dcache for an entire page. */ > static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache) > { > - BUG_ON("unimplemented"); > + void *v = map_domain_page(_mfn(mfn)); const void *? > + clean_and_invalidate_dcache_va_range(v, PAGE_SIZE); > + unmap_domain_page(v); > + > + if ( sync_icache ) > + invalidate_icache(); > } > > /* Write a pagetable entry. */ > --- a/xen/arch/riscv/mm.c > +++ b/xen/arch/riscv/mm.c > @@ -419,6 +419,7 @@ void * __init early_fdt_map(paddr_t fdt_paddr) > } > > vaddr_t __ro_after_init directmap_virt_start = DIRECTMAP_VIRT_START; > +vaddr_t __ro_after_init directmap_virt_end; If the variable is needed (see above) it pretty certainly wants an initializer, too. > @@ -26,6 +27,46 @@ void arch_get_xen_caps(xen_capabilities_info_t *info) > unsigned char __initdata cpu0_boot_stack[STACK_SIZE] > __aligned(STACK_SIZE); > > +/** > + * copy_from_paddr - copy data from a physical address > + * @dst: destination virtual address > + * @paddr: source physical address > + * @len: length to copy > + */ > +void __init copy_from_paddr(void *dst, paddr_t paddr, unsigned long len) Without a declaration in a header this function ought to be static. > +{ > + void *src = (void *)FIXMAP_ADDR(FIX_MISC); const void * > + while (len) { Nit: Style. > + unsigned long l, s; > + > + s = paddr & (PAGE_SIZE - 1); > + l = min(PAGE_SIZE - s, len); Make these the variables' initializers? > + set_fixmap(FIX_MISC, maddr_to_mfn(paddr), PAGE_HYPERVISOR_RW); > + memcpy(dst, src + s, l); > + clean_dcache_va_range(dst, l); Why is this necessary here? You're copying to plain RAM that Xen alone is using. > +/* Relocate the FDT in Xen heap */ > +static void * __init relocate_fdt(paddr_t dtb_paddr, size_t dtb_size) This function having no caller will - aiui - mean build breakage at this point of the series. > +{ > + void *fdt = xmalloc_bytes(dtb_size); New code ought to be using xvmalloc() et al. Unless there's a firm reason not to. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 15:04:01 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 15:04:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851491.1265553 (Exim 4.92) (envelope-from ) id 1tKfIk-0000xb-R7; Mon, 09 Dec 2024 15:03:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851491.1265553; Mon, 09 Dec 2024 15:03: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 1tKfIk-0000xU-OL; Mon, 09 Dec 2024 15:03:58 +0000 Received: by outflank-mailman (input) for mailman id 851491; Mon, 09 Dec 2024 15:03: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 1tKfIj-0000xO-P8 for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 15:03:57 +0000 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cd28fa91-b63e-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 16:03:55 +0100 (CET) Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Dec 2024 07:03:45 -0800 Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by fmviesa008.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 09 Dec 2024 07:03:44 -0800 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 9 Dec 2024 07:03:43 -0800 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend Transport; Mon, 9 Dec 2024 07:03:43 -0800 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.45) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Mon, 9 Dec 2024 07:03:42 -0800 Received: from MN6PR11MB8102.namprd11.prod.outlook.com (2603:10b6:208:46d::9) by PH0PR11MB7633.namprd11.prod.outlook.com (2603:10b6:510:26c::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Mon, 9 Dec 2024 15:03:39 +0000 Received: from MN6PR11MB8102.namprd11.prod.outlook.com ([fe80::15b2:ee05:2ae7:cfd6]) by MN6PR11MB8102.namprd11.prod.outlook.com ([fe80::15b2:ee05:2ae7:cfd6%4]) with mapi id 15.20.8230.010; Mon, 9 Dec 2024 15:03:39 +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: cd28fa91-b63e-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1733756635; x=1765292635; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=ojKY8VGrB0NUTTNKW1dlZ7YLMt791JXzjtxlmEN2aZU=; b=CPKu06quwI7B4At1ovDhgmO7c8o1X8+E0hKJnYf7NgGBmKWDfITEPpVr Nl7HqYWvSJdnuffJPqH3B1eps4l9UF8z3CZFh3jtdVhsNUz9J3jRUuJF3 mY58UIZ5Z4vouhiM1MB9NTJCriJdMzQNkBINJQkmGXfmkBdlmdi1kmciS 3W4/UQ/cZg66w2am5qugd/m1vk2WRJJPh/iXSEAaF4R4QW75KZAV/dFb6 wWM5n3zTahs3LLfm5kmREWXd2FOuPneUaTsBAv6/MsURkI618onalknWF cwkXN7+KWCDy59A4Lt0tKH8is7PkRwgajD5gfSbl/xSYLOyOxRcO+6i17 A==; X-CSE-ConnectionGUID: p99bQYSPQPOiaZzb5E1QNQ== X-CSE-MsgGUID: Qnc6uAVET4yaNLCWlCQLuA== X-IronPort-AV: E=McAfee;i="6700,10204,11281"; a="37740428" X-IronPort-AV: E=Sophos;i="6.12,219,1728975600"; d="scan'208";a="37740428" X-CSE-ConnectionGUID: HvJiLP3vSLae+wV9LKUE0Q== X-CSE-MsgGUID: 4qvw0x78RcOcXc7SMhO5wA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,219,1728975600"; d="scan'208";a="95297421" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eEvqP/svuQHePq6kDJJha03hfHB1suI+0GkfdhwThGQ6lFfV58msKNuvw+o5ZTgpkLC6Z5/WQiSuaE9mMJ5JrF1Mk1RNY0Sujclvn8JEfeMlx4WpEqj0CqEe/qqBsgvG96TUQxMDVlSvS0/hRiwnSGEnBTlY8Q4crO0de30XvBmNpRgLAh/C/BcQzK4zxc5GjwNCP8DnWeVL6yZ5vs9hiPgIpIZFJcjza+zZGRZoDeFlREpnNUtBCvdvZ2D0+tlrh9rHIy9foG6CqaFR52O+iaUSws5a7Uk56X2ExeHRJ6bjswTCjGgOWxlt4F5ePn9c3wN15WrhEYtH2fgiJ9Djcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=F4B11m+j+SDYKHTWgiQ51I/BvybU5Pv0AqswYdCIzeM=; b=yyGziDgGY3FQmopWALJEw4Iw8huHU9Iv6XqVZWe+cfsCqQwK3N1ZZwk+KXCOKa2VaX6vsGPqr0l+0lJhb5xq2i4UmuEMXXMsjMyB7druSe6IkQpjZNMwEQ5WG9w0jUSzyt6tG5dO8Ol3HwLsJAapsMmMlzkcBCMDViNeSRBwK3/c6W05/PsgrM22aEQT1T8XbDVJY2l1TwtpK1S2np9a+c1bJQQCnQvTvIdwMfkwpSXwWJ6SO4bklmimnteI6nwn1a6LWukzsJ3mkGth+SBMqfKkGIH41gP3v0dU7jYWjlmdod7kjepgCLHnEnvvKNKALvUT6m+hC/yo98t8nml8uQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Message-ID: <3113d4f4-4f8b-41d6-af89-f82cbc89da75@intel.com> Date: Mon, 9 Dec 2024 16:03:31 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 00/21] Converge on using secs_to_jiffies() To: Christophe Leroy , Easwar Hariharan CC: , , , , , , , , , , , , , , , , , , , , , References: <20241115-converge-secs-to-jiffies-v2-0-911fb7595e79@linux.microsoft.com> <72c8eb66-eb67-4f8b-b0c0-13f1aa001698@intel.com> <95a461ca-3ed6-4380-ad1a-da12e1109675@csgroup.eu> From: Przemek Kitszel Content-Language: en-US In-Reply-To: <95a461ca-3ed6-4380-ad1a-da12e1109675@csgroup.eu> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: VI1PR10CA0100.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:803:28::29) To MN6PR11MB8102.namprd11.prod.outlook.com (2603:10b6:208:46d::9) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN6PR11MB8102:EE_|PH0PR11MB7633:EE_ X-MS-Office365-Filtering-Correlation-Id: 19376c7c-35e3-4a5d-6282-08dd1862aa15 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7416014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?dERZaitoL0pnZEQ4aWhRMnd6b1BqY2lkQW54U3lxKzZ5RjExZXkrWEVMV1Jw?= =?utf-8?B?RTRrVkgwZjcvMGFFYXJkNjFtUXJmMm5LM0tWY3pTbE5uUytJc3VCdUhwT1Uy?= =?utf-8?B?Ym0wZ010TXNNY2UzbW8zVXBXL1MycE0wQTg2eHJuL2hKTWFUNmdaTVhBNHVR?= =?utf-8?B?Mk1BN2o5YXBYd3hudTZDN1RCOUMyN0ZSR1ZENlF4UFZOUG5ROHlJNE1GekRE?= =?utf-8?B?RTBjNlB3WUZuV256SHY0R1h4MlFHeTN1aFRMcTNucnZEaGYrRzFJMFRNZUNE?= =?utf-8?B?SFU1WTZ0SCtHR1gvc0RBdXJURzNkQzV0eG82eVJFNjNSM2FTZEs5S1FYNzJV?= =?utf-8?B?ZjVUU3hiZGN5VWRTNDQxaCtIQVR4ZjdkSjVDVndkOERyemJyWnlHNDZvQlFl?= =?utf-8?B?OFRxVytXUmFjelMvRTI4WE9jRk5abHRTcHZWRzRJWDRwSDhQNkJaVUw3am9L?= =?utf-8?B?eWZyWGlEbXBnUm5Zaytwbk92MjF0K09FUmlvY0FCcnRzSXhUNUo3djNyejBh?= =?utf-8?B?SmpuRjRLQVRCZWR0bXVtbGRJRmdxVzlKSURDb2ViMzN3SHNtVTZlc0ZsVGlp?= =?utf-8?B?S09LWVp0eXVCNE45aVBWOGs1QnM3NXltRldGdDJFSFk4RnVFaC9Zd3J0WVp6?= =?utf-8?B?RnRhcUE1OFV1TkxTU21DMTFIemc1THp6YkRsQmlmZjM2aitsaEhtN1JGY1dB?= =?utf-8?B?bVQ2cEtOS2NkQ3c5RHlDUWkycUg2bzZwT20xemFQMW9aam1OdU9GWXZ0SU9j?= =?utf-8?B?M29GWm5mRHdpR3p0ZGRreTlHc2ttSkpvQWdwOFpIUTRYcUpvUzh3NXFCTC9X?= =?utf-8?B?RUlKMWNCd0dFdmN2YlQ5WDZNR3BiVkVVdkpFbFRkS01pWkl5ZFFTeGxBMlkv?= =?utf-8?B?d2I3T1ZIS0c3UkQ1YnUvaWFtbTBqa0h2Rm9MdGUvSW5WMGVsNGFlVmtJems2?= =?utf-8?B?YkMrdnQ2OEN0SUNFTzRPM05CT3hpMkEvT0dRd29oUDAzZ09NakV0YzBrZmVN?= =?utf-8?B?c1VDdDJzdmFiRXdjODlmazhTNUZ2dER3Y1B1N1BEQ0FPWGFsTWVwN1BHUnVR?= =?utf-8?B?MzAvbnJSNG13dXZTYUdsdzJBSXZzTEMxOVhEYUl2SFBheStwZXROQXh1RnYw?= =?utf-8?B?aFZzanhNRVNDaGJCdTRXeENNbW80NklMOUwyR2hoOFBYKzZOWEpsY3RQc1NB?= =?utf-8?B?S0NXSmhvNzdSZXhGQjA0ZXZ1Tm1BN054Ukd4Y3pnRFM0Z1ZmRzBiWVU3SmF1?= =?utf-8?B?TmpDL1lROGVkOXFVK1hEWDBsQ0h3L21nalVvV2U0VVdzRlAyYmFCRjdqWUFF?= =?utf-8?B?M1c3WHkwd0t5NXZTanZ6YmF5djc0VzczdFhQL1JvVENwdW5adFgzcW9CVUhr?= =?utf-8?B?NVdzcjJNUm9IWE9xUWxCUnVzOFFpMTNhbWhHZHAvTnp4NmlTUTFiYXg1eWlz?= =?utf-8?B?TDF2SzkzbkNnZ2pQWlJrSkpzNUVaUWRFL2ZDdDAzcnhaUEpyUXJUU3NPSnlS?= =?utf-8?B?RjFMenpsN1RNL1R3blV5OVovaWM1WUNPanV5U1BOaWREKzBRWnY1RERPdVVu?= =?utf-8?B?L0N0bXhqd1FlbzZjZ0VPY1BKTDhtVFREWitvZHUzM0ptdnplTFVERW13Wlph?= =?utf-8?B?Q1dVdG5yWTJYSDZocGo1aHZ6ekV5YmlGZzV5Nk9Fd29WYVRjSFRjd01yTy9y?= =?utf-8?B?cWV0SHZxckNwZm9ha1ErNDVmakdnRzhwVmp5YXA0N1kzNWVMT3NBcUlNVksy?= =?utf-8?Q?wEL9oZQB6wix6G1QjQ=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN6PR11MB8102.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7416014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NTJoTjRHL0s2QmFqVDNvRGtIMFhRaVIzd21tTG9VTVJpSW1zdDl5QjRDUW02?= =?utf-8?B?d3FnMjJnSUtxS2FmcitLT1RuNzdaYThaZFJMWE93TnhmVW05dDRNdERva0gv?= =?utf-8?B?a0F1dEtSb0hSRUZKYmxSaGIzbzVIanVwNXRZSHFac1JTOUtLS3pxQWtoci9n?= =?utf-8?B?d3dGY1czWEdLL2tIanpwK1pQdGNKN1FVcWxpb0hmME45aTNnTTVHSTRZUjNN?= =?utf-8?B?UnV3OFFWcGd4ZTBBWENkRytDc3ZnVTZqWGJ0MXZXOVlySTJCRDI0R3RQVUNq?= =?utf-8?B?QUpYOVdwQXorRkJLSGNISDRpSjU0OUFoa1I3TklEeTJGY3FTbG9WUk9sUmcw?= =?utf-8?B?L3dyZmJQZ3YyL211RFZLZW1zdE1xN0xyai82cjdHZ25LUkc5Z3B0cnhOZnpG?= =?utf-8?B?RS9pbElJdHZZVDJKMitsSE0xRitKdXlhelRzNEZWcnp5YXRNSjlZcU1WZUV3?= =?utf-8?B?c0ZXUlRrTE80Q1NVcUszWStFbm91TmpvWlp0NVhndjRVajk4S0NuNzdVODRT?= =?utf-8?B?T2FZZmIrRE1oMDJQdWwvUHFqditUWDhyWEZidjJkdHBFTnRQNk0xVVRvT093?= =?utf-8?B?a3l2cmFieUtHL3pRRkxjN1NVR0RuWS9HN1FvanFXUzIyaTZqTkR5SzkxUWFn?= =?utf-8?B?VEJ6V1QrNXBZZHRhdkQzd005SXZwY2Z3bWNoc3NPcng0T3kwcDBkRGtEKzV1?= =?utf-8?B?RlJRdytOWmllTzg4ZkpCU2xISVpMdm5oUDZHYXB5UTRwVmYwTGRzWDcvYXRr?= =?utf-8?B?bUVMczZGeS9seWMzMnp4RFNYZnZ4b09Jby9URzE5WmRNeWF4REZFN3RBazRM?= =?utf-8?B?ckYxOGJxdXczWFNCYUliN01VclBuRkpua0VxbFRlLy9ydHRycUJRM2Z5ZW0w?= =?utf-8?B?V1ROd2VZSHJuSm1STVJhMXNKRTI1QlVhTVR1R1RvdEw0UEJXWitxK0ZzWFhU?= =?utf-8?B?Zi9vS0lGekIvMzlHMVNFN2V0OW5Ka2JrR0ZQOWRRVXlEcTVlYU5wdjJ1RTR5?= =?utf-8?B?aDl3YVF6Zi9IUFhjM2lDOW9WeldPL3lHdnpEdkpwdTFDU1FJSnUza1IzK0Zi?= =?utf-8?B?WGpRbFFMLzhFbTEzNmJPWFRvQXhQcUY1R1hFdnA4ZytXU1F0cXV3cUpIdStG?= =?utf-8?B?M1Zmd1AvTzNsWFZBWDJoMmxPOTdmQUExL005SmxhS2dXQ0h1SWU5QXlEbnFH?= =?utf-8?B?eGtMVERzckVIbTBtZ2F1MmVVcy9SL1o5ZHNGeS9NbHFEUzdIUVZZek9nMkc3?= =?utf-8?B?aFFUdndzMFBsTW5pNjN0cC8wRHhRaEhVcllYays1NndzblR6N2ZxbVB4RlRm?= =?utf-8?B?a3RtUUpZc0JuM0srZkc3djJZOUs4ZW5OVkYyT2VRTFljVkdWcFg5eXppMzQy?= =?utf-8?B?bVp5S1o3OGhFNk1VMXIyMFVjdGIveHNsaDdad0ZybGxXUlE2NVVpR2ZjaFE1?= =?utf-8?B?TDZDRnBEZGhSL2Rid0lWQThuZENNWENDQ3hvSFhFbFV2YjZlK0hNR0RhbkhS?= =?utf-8?B?TXkxdUdPV0NDOFJvMzdETi8wU3JCK1ZuSjh1R2xESWtOZk1rVUd3ZXZxN0hl?= =?utf-8?B?OHhKZGJkSW4vdVovTEF4WjZmd1luNFd5Q0NSZWI2SDZDMmVpSWtTYnZXaTdP?= =?utf-8?B?WERvWHJxUFFSRlg4OXUySkVJRlFWY1ZqbEExUXBVN00zQ212SVp5QmJ6YTBH?= =?utf-8?B?cHloUVdUMkN0UTlIVFJRbkUwMzh2S1RIckhyNll6Z3NXbVlGaG1FUEdZSFgx?= =?utf-8?B?ZnlucFlnN3FKemNQSTlRRUtXYWN0SC8yTmtrcjNURWQxTXk1SFRiWGN6MjNS?= =?utf-8?B?RytPR3pseHBSMzBqeWFmSHBmMkpnTXMzTmIzQlJhdmdtWjBNVWgzRGUyUFcv?= =?utf-8?B?N3RleTZQWjFhNWpnN0IzSUM5aVZtTzNFelR1b0Y5Nnc5MlI4UzlVNHNsSDRV?= =?utf-8?B?S2pLQUZzdzNTQ1lUNHdOekhRYnoyMmdwTEJZTGQwY0VEbDhVbEpmcjh3S1Zr?= =?utf-8?B?ODFyMDhpMXk4R2VLVjIySTBGRkJMbm5xYWMrTVRNMHllNGdHVEI5UTFNenBh?= =?utf-8?B?UW96ak9xdm1RdTcxY3BmY1NBRExKL1IvNkVIQ3oyejh1RXpraWwvUjllOWY0?= =?utf-8?B?TC9mMnlkYjF4ZmVrWFVKZVU2NzVVdlZpT0JMZVVJMjBZU0lUUm8xRGgzNWli?= =?utf-8?B?VHc9PQ==?= X-MS-Exchange-CrossTenant-Network-Message-Id: 19376c7c-35e3-4a5d-6282-08dd1862aa15 X-MS-Exchange-CrossTenant-AuthSource: MN6PR11MB8102.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Dec 2024 15:03:39.7381 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: aAwfYO53ax7O0HgtzbNHxDg4y4YIgk0CrCzgBW8cnkbVLdYnV/IAJaOB+cPgAGabZY4dGCuNoZovPhZ6+A3TkCFPUHvIA+3RncA26GujG54= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB7633 X-OriginatorOrg: intel.com On 12/9/24 1:45 PM, Christophe Leroy wrote: > > > Le 09/12/2024 à 13:01, Przemek Kitszel a écrit : >> On 12/6/24 9:58 PM, Easwar Hariharan wrote: >>> On 11/29/2024 4:57 AM, Przemek Kitszel wrote: >>>> >>>> [removed most non-list recipients, it's just too much] >>>> >>>> On 11/15/24 10:26 PM, Easwar Hariharan wrote: >>> >> >>>> >>>> Regarding code - you could also convert msecs_to_jiffies(const * HZ), >>>> there are 10 that are greppable. Thanks to Christope, I re-examined those ~10 cases, and that should be refactored by just dropping msec_to_jiffies() part, not replacing by sec_to_jiffies(). >>>> >>> >>> Those seem to be mistakes. const*HZ is a seconds-denominated timeout, >>> being passed to msecs_to_jiffies() which will treat it as a >>> millisecond-denominated timeout resulting in an excessively long >>> timeout. I suppose that's better than a too-short timeout, and >>> apparently it's been working fine all along since hardware responds >>> before the too-long timeout expires. Half of them are in >>> drivers/scsi/arcmsr/arcmsr_hba.c and the pattern has apparently been >>> there since 2010. >> >> my point was that, the default value of HZ is 1000, and most of the code >> that is just `$value*HZ` was meant as "$value seconds, in ms unit". > > I can't follow you here. The default value of HZ is 250 as far as I can > see. as default I understand "the value that is effective for those that don't tweak", not necessarily "the fallback that will be used when not set by any other means". On my RedHat and Fedora boxes it's 1000. > > Regardless, HZ is the number of jiffies per second, nothing else. That is true. But the name is wrong. > >> >> Same for HZ/const, HZ/2 being 500ms. >> >> HZ is awful in that it is not 1s but 1/s, but it was easy to abuse the >> value in simple context. > > Why is that awful ? so, 1Hertz = 1/1s == once per second, something happening twice per second, with freq of 2Hz, repeats each HZ/2 jiffies https://en.wikipedia.org/wiki/Hertz the #define name should be really JHZ -> JIFFIES_PER_SECOND > > HZ is a nice macro that gives you the number of ticks per second, so > that you are able to easily calculate the number of ticks for a given > duration, regardless of the configured number of ticks per second. Again, technically true, but default being eq to number of msec in sec, causes it to bite. From xen-devel-bounces@lists.xenproject.org Mon Dec 09 15:13:53 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 15:13:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851507.1265562 (Exim 4.92) (envelope-from ) id 1tKfSG-0003BL-R2; Mon, 09 Dec 2024 15:13:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851507.1265562; Mon, 09 Dec 2024 15:13: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 1tKfSG-0003BE-OU; Mon, 09 Dec 2024 15:13:48 +0000 Received: by outflank-mailman (input) for mailman id 851507; Mon, 09 Dec 2024 15:13: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 1tKfSF-0003B8-DH for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 15:13:47 +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 2ead4540-b640-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 16:13:45 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-434e406a547so15348155e9.3 for ; Mon, 09 Dec 2024 07:13: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 d9443c01a7336-216364e45d8sm32659085ad.175.2024.12.09.07.13.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 07:13: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: 2ead4540-b640-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733757224; x=1734362024; 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=zzrfAF2Vxlh90FlTHEHNpTSTTNMD975Zjla/Sj45Vx8=; b=Z9neWs8oEGiMyd/CwVemSy32D0Z3C/pyHBwSL9L1tvkY8TpMGRecb1LbROLFjxre8O /ucoWzh3mLI8wZ7pe3fvpae3cdDv5Gi0dJHF3I00fdVOoj/U056FUGHuDLbOEqZfYA54 Lhfz7tayhOYUVPBC7eV+JSa7scnVAcFoU3+shVrUtLGpxAr8eoFWRnHD+l4QZCC2PP3x buxRoL+NiRWYNau6CD84itnX0px+ZMl2n23XXtw4aeZmYg3+oN34UkNsmMP45wfo1bn6 ucsVUTTiAIMARBiUpJV7fg84jEdOt7CyTpoR2le499Jv8mrKxgFuRiHoxu3KQiJhvm3m Xo6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733757224; x=1734362024; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zzrfAF2Vxlh90FlTHEHNpTSTTNMD975Zjla/Sj45Vx8=; b=Ew3+QjOdYqLptFgvhwzvnOoHer+T5QLHHhc/t3PhnqJg6awl04VWwlyrjk901MX7E1 0q/JKXcNUjyNs+IGC4htoPtKZGbgYVRaRYeSXssztukoKKLgmI89Ek4irc7g3552WWFt ifPVvxxysYJgtCTr6X3SoYPHeloZpGMEzO3FOE0mlCY9s33cqVHmMB7+Z15v1c/keDXo vbrvRfjHZH2Je3pffaYMQUYD+LKpcNNY4BA4SuwBY1tWp5tWb30iITtaVh4dNTtcwwaW 7u4jxYG2g0PSejHZKzfMNZOsPDj/LJkPAVo14PLn01Y9P/9+OAH1G/2ZnKTIk5K63wt5 2BjA== X-Gm-Message-State: AOJu0Yzn6YwTVIbgeUSSRWznuR/QB+ezoIb2UU8OsfsyiT0Dzas7/3xW gLwGw3LLmMNVy+JhkEF91oihLwYqWXH3V9jnikZaSnyclTwEMihU5Nf+KEYjSuOaoNO+OSLfaCc = X-Gm-Gg: ASbGncvydRZY5ztAPI07uAJjReGbc6uMjT+W4TOsxlD6GwA+XHcpx2CQuEdA/Mg14BE c67h2j/shav7U41MmQTReZBYJ21kA3WojwG7T8HG1v7xBfZt24F0XU+DTJZ6Vor3FUWWCc4lcqr PKs1x2HjfbhZ9wJwVJCt0zC+glcwBkkOuLWTaY1snBhPqKAFRQ/tfLWSX3R8IskQOo22TS2F7I8 olDqt2QlUR5TUm0WA6Rp23XDe4jgD4Jy0uxFcsqJLSp3+9FFNZgFlzXeKQHII7Ivu6vkDDyXzno EfD/OyIz1Td98JImlpV7LDlhNR0w+pyyYHg= X-Google-Smtp-Source: AGHT+IGI4hi7Ie3whTXBH1YT8k3O/KIJNSflyKUUSEIrPBl62b2ZbCsjyV7jRVZu9tOcT20HMvuM4A== X-Received: by 2002:a5d:6daa:0:b0:385:fb34:d59f with SMTP id ffacd0b85a97d-386453d2acbmr839879f8f.11.1733757224478; Mon, 09 Dec 2024 07:13:44 -0800 (PST) Message-ID: Date: Mon, 9 Dec 2024 16:13:38 +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?= , Alejandro Vallejo From: Jan Beulich Subject: [PATCH] x86/FPU: make vcpu_reset_fpu() build again with old gcc Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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 Fields of anonymous structs/unions may not be part of an initializer for rather old gcc. Fixes: 49a068471d77 ("x86/fpu: Rework fpu_setup_fpu() uses to split it in two") Signed-off-by: Jan Beulich --- a/xen/arch/x86/i387.c +++ b/xen/arch/x86/i387.c @@ -306,13 +306,13 @@ void vcpu_reset_fpu(struct vcpu *v) { v->fpu_initialised = false; *v->arch.xsave_area = (struct xsave_struct) { - .fpu_sse = { - .mxcsr = MXCSR_DEFAULT, - .fcw = FCW_RESET, - .ftw = FXSAVE_FTW_RESET, - }, .xsave_hdr.xstate_bv = X86_XCR0_X87, }; + + /* Old gcc doesn't permit these to be part of the initializer. */ + v->arch.xsave_area->fpu_sse.mxcsr = MXCSR_DEFAULT; + v->arch.xsave_area->fpu_sse.fcw = FCW_RESET; + v->arch.xsave_area->fpu_sse.ftw = FXSAVE_FTW_RESET; } void vcpu_setup_fpu(struct vcpu *v, const void *data) From xen-devel-bounces@lists.xenproject.org Mon Dec 09 15:16:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 15:16:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851517.1265583 (Exim 4.92) (envelope-from ) id 1tKfUp-0003xV-Ce; Mon, 09 Dec 2024 15:16:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851517.1265583; Mon, 09 Dec 2024 15:16: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 1tKfUp-0003xM-9j; Mon, 09 Dec 2024 15:16:27 +0000 Received: by outflank-mailman (input) for mailman id 851517; Mon, 09 Dec 2024 15:16: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 1tKfUn-0003j3-TV for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 15:16:25 +0000 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [2a00:1450:4864:20::630]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8e4644ec-b640-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 16:16:25 +0100 (CET) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-aa5325af6a0so711518966b.2 for ; Mon, 09 Dec 2024 07:16:25 -0800 (PST) Received: from CSGPROD238885.citrite.net (cpc92320-cmbg19-2-0-cust1786.5-4.cable.virginm.net. [82.13.70.251]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa663334906sm365993466b.72.2024.12.09.07.16.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2024 07:16: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: 8e4644ec-b640-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1733757384; x=1734362184; 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=y4D25h9apZWWqcYaQPYHIl6EB6+ZFsV8yaOICIU50IY=; b=ZMaPOW6LR8gjbyle/Y7Gr3aXUr595Kd06lns4ItEMf9p4L6o8JdPTOulUAB29lYbpx nRTzYBtrPFAKmwSstojPdCxud5LbG4DGA9NJDTXp8M1uZIxHJ2pvNefqoeF7hmGHO/Ig 0XwKIGiCsoseiGzoLSleZeMu4bFjZjQuKPbg4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733757384; x=1734362184; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=y4D25h9apZWWqcYaQPYHIl6EB6+ZFsV8yaOICIU50IY=; b=VxN2xnYUfjXFMKqdSkIy/loKKtRt+L+INW4n/upH07AT+dyMQpAZSwysP3TlQSO999 P/Kp5lqIlNo81lHIlrRhQWqQ0u4KMFUbVJjBIhZ+XFI67VxME009QSX4n5AUTIl496MB SmlfkIzDnulZdG+Mbg2boOOW3NcNSJY3zgl/NHbuFCiwWjYDbYXXfzbAI+1uma1up6pb 3YSy9iyN+Hm6GHPUFNlEqd5ea98ERMBq7VttzGDVQ7KGw65hiMnuaK/GRCRwzEfS60Ug 4liRCOA4e8wqdS9AU9PeujSRi+wrEy5uC6dxmGJ0/q5/8TO16j/h+0Tr62zK1dJQAVfc LNXg== X-Gm-Message-State: AOJu0Ywf+ry9fOCLTsMverX8ux6/aiut8zetz8vzlpD9biHMY4v4e5IC 0ck13zi5PZnI367YsjpQaxZ+r/aQSgn2av3Ep6MA1czluzBd03oSKz/MtGsFRbDCijfAcHBrZG2 s X-Gm-Gg: ASbGncsE4CqGEHXmWSoTj3X78C69tu+pDyT7R17xnVBWD+QBVfgLXPFN5a19jLSrx4S lpfkP7NVlNX7KcufJSTrHvNZ2yug52KX7u0bbnnzEbqxLZ7Ngjte2LbdH7E0J5pVpWAkom0STPF OAcSHBUPmdQ2cD7Z/+LOYwPAIZa7ThwN6EgI/KoNAmkf5Wi5CQ0NhUSUQyxzu6on9VFMDYGjLB1 Z9/pLWftKK+EPkd3xVr3XNES0udg4QgzY2LSe3HF5OrsgFMB/wSEcLQpAa0f7iteh9c/0sI62IQ L9NYEfdVKIEL88iaR4l3E5jWiqKepfsJgkpZ2D4VNDYZ9+grGT0iIIgk X-Google-Smtp-Source: AGHT+IG0PpfUHGsCTEXkTZY+j/ytG3AMW4kHEO+LHjVjuBPfDj20tnTHu7qMy+atj5jud5QjmEDCbg== X-Received: by 2002:a17:906:2189:b0:aa5:391e:cadf with SMTP id a640c23a62f3a-aa69ce223c2mr91253666b.42.1733757384563; Mon, 09 Dec 2024 07:16:24 -0800 (PST) From: Andrii Sultanov To: xen-devel@lists.xenproject.org Cc: Andrii Sultanov , Christian Lindig , David Scott , Anthony PERARD Subject: [PATCH v1 1/1] tools/ocaml: Specify rpath correctly for ocamlmklib Date: Mon, 9 Dec 2024 15:16:18 +0000 Message-Id: <231f20e0c1dae7eadfeb4b806e1bb415f5f15b33.1733757256.git.andrii.sultanov@cloud.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ocamlmklib has special handling for C-like '-Wl,-rpath' option, but does not know how to handle '-Wl,-rpath-link', as evidenced by warnings like: "Unknown option -Wl,-rpath-link=$HOME/xen/tools/ocaml/libs/eventchn/../../../../tools/libs/toollog" Pass this option directly to the compiler with -ccopt instead. This prevents embedding absolute paths from buildtime into binary's RPATH. Fixes: f7b4e4558b42 ("tools/ocaml: Fix OCaml libs rules") Signed-off-by: Andrii Sultanov --- tools/ocaml/Makefile.rules | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/ocaml/Makefile.rules b/tools/ocaml/Makefile.rules index b9d4b51f0a..055725d910 100644 --- a/tools/ocaml/Makefile.rules +++ b/tools/ocaml/Makefile.rules @@ -63,7 +63,7 @@ mk-caml-lib-bytecode = $(call quiet-command, $(OCAMLC) $(OCAMLCFLAGS) -a -o $1 $ mk-caml-stubs = $(call quiet-command, $(OCAMLMKLIB) -o `basename $1 .a` $2,MKLIB,$1) mk-caml-lib-stubs = \ - $(call quiet-command, $(OCAMLMKLIB) -o `basename $1 .a | sed -e 's/^lib//'` $2 $3,MKLIB,$1) + $(call quiet-command, $(OCAMLMKLIB) -o `basename $1 .a | sed -e 's/^lib//'` $2 `echo $3 | sed -e 's/-ccopt \(-l\|-L\)/\1/g'`,MKLIB,$1) # define a library target .cmxa and .cma define OCAML_LIBRARY_template @@ -74,7 +74,7 @@ define OCAML_LIBRARY_template $(1)_stubs.a: $(foreach obj,$$($(1)_C_OBJS),$(obj).o) $(call mk-caml-stubs,$$@, $$+) lib$(1)_stubs.a: $(foreach obj,$($(1)_C_OBJS),$(obj).o) - $(call mk-caml-lib-stubs,$$@, $$+, $(foreach lib,$(LIBS_$(1)),$(lib))) + $(call mk-caml-lib-stubs,$$@, $$+, $(foreach lib,$(LIBS_$(1)),-ccopt $(lib))) endef # Dynamically linked OCaml libraries ("plugins" in Dynlink parlance) -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Dec 09 15:16:27 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 15:16:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851516.1265572 (Exim 4.92) (envelope-from ) id 1tKfUo-0003jL-6Z; Mon, 09 Dec 2024 15:16:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851516.1265572; Mon, 09 Dec 2024 15: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 1tKfUo-0003jE-40; Mon, 09 Dec 2024 15:16:26 +0000 Received: by outflank-mailman (input) for mailman id 851516; Mon, 09 Dec 2024 15: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 1tKfUm-0003j3-Ms for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 15:16:24 +0000 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [2a00:1450:4864:20::636]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8d62bf36-b640-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 16:16:23 +0100 (CET) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-aa684b6d9c7so206145166b.2 for ; Mon, 09 Dec 2024 07:16:23 -0800 (PST) Received: from CSGPROD238885.citrite.net (cpc92320-cmbg19-2-0-cust1786.5-4.cable.virginm.net. [82.13.70.251]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa663334906sm365993466b.72.2024.12.09.07.16.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2024 07:16: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: 8d62bf36-b640-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1733757383; x=1734362183; 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=gCamU80fNjuDATSjKEwbAHTRUpRYNPRSPAburm9D41E=; b=bZk4FP07yv/0bCKFDkzN+H4rEKto5KslJPwyMlJHRMZ/r9N6Kxtiya5NybSPzD7C+u cVz+wag1QUMYB1lS46cV6wZkFGrhfUujLYcYf1Pt+YZT/3Vz3KgHjlp6f95rYu6YLj2p QE2wHBa9TBsik/GafV32aFfCUzPwqtMFZfAas= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733757383; x=1734362183; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gCamU80fNjuDATSjKEwbAHTRUpRYNPRSPAburm9D41E=; b=uOpJFPXs6l/84iXls/tYbZp1VtsWgoE/DHEbrEmsmIUkK5JkhS++8Vc39Ngf4XxuBq iODsRQtNSveYKfNP1RV1tBcX+fOh8W5PvGgOCROHE75I5bjsYxEw1qpydWlwKAl31qUl xfDcf03Fe0+VExmj2lsr/tJlYeQObWQIgitbu71BC8pNezRdZakE0OSGf+HUErBoUZ9k MKpmF1MBzAmKrKHSP7gaHuHyYB/NJFlUCK6FhYcXCxWLlf+RSCWRO5gWmwKWzZR1emnB CPGM7HtYxb+gizn3Byai+KnDCtVBMCa/FzSEpENKbwpoSwJiA0VCwjizbnerWUVpfJVE U69Q== X-Gm-Message-State: AOJu0Yy2xLKb80s4hoLkK1UI3LQILph6Q9+tYB7bEpMmdt3HQpvPM3Ji nYCy/V+elqftkev693yS+nZVag7ARLVEFFx8iFO/pvRmRnhFhh5jJx8E33dmUA3nRQ/dHV9qROt O X-Gm-Gg: ASbGnctU06pn7145F0uy+l/4tDzoMlvXClCrNd2GKGGG2dXZo7KhSLgH/DMdY9ownUt AZeVR4pswhNLFo2DQXfqmaGg6ldBynIRpA1a23QEaQ9e32rwbfELbzydWGyAX2T5Sc/BbL9xt2a FTA7tLrhtvLu4/Ep70JvwofF8vfLVhhW+PYvCj7M0StGdd8z/K9kEw+/1I0WgEu+PJpqFQKt8G3 S2wQYyC0R9f/kgc7cVI2GOMyZ8fzKPxxDaeUDTOyix7Ct+LoDZBzIlJXbk6ZAottSsiD9o2YbQw Ot9i6zCef4xrX6hoN86kepICW3ZXPp2DWzx+kl3aaze2QtbOqCl6tXHW X-Google-Smtp-Source: AGHT+IFvfcjXlljV7VBApJAZ1OTOiNMf95sJGveV1De9xnZ0aMYx2trgV2R48AFApVvF2W/Tqr7WrQ== X-Received: by 2002:a17:906:18aa:b0:aa6:8096:2043 with SMTP id a640c23a62f3a-aa6809621a9mr396365766b.8.1733757382914; Mon, 09 Dec 2024 07:16:22 -0800 (PST) From: Andrii Sultanov To: xen-devel@lists.xenproject.org Cc: Andrii Sultanov , Christian Lindig , David Scott , Anthony PERARD Subject: [PATCH v1 0/1] Fix rpath handling in OCaml's Makefile.rules Date: Mon, 9 Dec 2024 15:16:17 +0000 Message-Id: X-Mailer: git-send-email 2.39.5 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit As reported by Nix's Xen team, OCaml stub libs would embed an absolute rpath in the binaries, which was picked up on by patchelf. This is a symptom of improper handling of -rpath-link in the first place, so correct that and get rid of the issue. Andrii Sultanov (1): tools/ocaml: Specify rpath correctly for ocamlmklib tools/ocaml/Makefile.rules | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Dec 09 15:26:46 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 15:26:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851541.1265593 (Exim 4.92) (envelope-from ) id 1tKfeb-0006Lz-A0; Mon, 09 Dec 2024 15:26:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851541.1265593; Mon, 09 Dec 2024 15:26: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 1tKfeb-0006Ls-6z; Mon, 09 Dec 2024 15:26:33 +0000 Received: by outflank-mailman (input) for mailman id 851541; Mon, 09 Dec 2024 15:26: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 1tKfeZ-0006Lm-QM for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 15:26:31 +0000 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [2a00:1450:4864:20::62e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f6b08819-b641-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 16:26:30 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-aa670ffe302so261430066b.2 for ; Mon, 09 Dec 2024 07:26:30 -0800 (PST) Received: from smtpclient.apple ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d3d69e5b72sm4121836a12.0.2024.12.09.07.26.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Dec 2024 07:26: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: f6b08819-b641-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1733757989; x=1734362789; darn=lists.xenproject.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HRPncsvYa3Esbmk/0nVF41JAamgPk5b3GpM4zUM1nuE=; b=MgcIDIDErd9VUp9+AYIS+VnoKoaaJcafEYHNXvlO/jyvwQMJ8hkyEcjdBOZGLbeXSa X8gViSp3mMCo1MzQ2UO6FVhBOafsEkLUROHEeGPf43eGkzwjK87IFdA6RVBXV/UsVIbm CPJHgWKcccN2R2bUhPxPJ8Y3SW2cKD9S/7TuA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733757989; x=1734362789; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HRPncsvYa3Esbmk/0nVF41JAamgPk5b3GpM4zUM1nuE=; b=ppo5HVERXIBOlrmy1QxUzU8h5vM9wvTjpbVWRzZ/uPzd9fSXLVl1xVyGykzXfzJvNU nFerTES6pmTjmyGkqdbsCE5d0VTipMR7W8ml/pn8LgC5FQbrsRyvgYhLgcyH64JQB1FH 4Gf9XwGuXprZ9gxMp2qRIdhtH9a2e5aBe69TNzJSGEy2E2wSFlIt7Gv8oUBu3or71AVx A9Ne1oZVJ4eAa7ZUP/qMDg5P8PsRpNYs+YaX4WLcQhU9dDSyiHYX66ieNHlEx0a1YL+K AKPxVrsQjgyqssKG1sBgQzrghMvYC47c3/r1lgLWWYVWaOF/x8qGXQ7eqJMA4YvDIT68 ReyA== X-Gm-Message-State: AOJu0YypFI77tCDndKlXE+au4iGXpYTextVYp9jzmtI+dya8aTm9PTZq f4Fw6UL0v/Z9DxrZLdmX2+g/qRagZUS66fx2VME4ckcwq4QXImGLIcf+Oe7WW7/WaLIWafINNQ1 a X-Gm-Gg: ASbGncvg0O+C2IH0WSBrnZvdMY9N5ST8wvv4rrRjY7/wfCupFtRIUNCq/rbqtZ56THX CGODlUhaOsz7DdcRRaWHdMyB0NXDIORYHELtO9wQ3OUIzkqx1wweMiXcUkPwZfUEEypUct2atxA HQTn6Pw7AfFPe92mWr38bKvjbrmaMQu3MX35aS4+7E0hZVXJ6Rl3nCBqzqB9TDUxLf55Bsw7Juj w1bYrqNnjYazxjtOiJ0PkoyLh4Ep0JIVlQ06mOPUM2Rv8+iQ8TBj/LqU4Hu5uSc5DF+0qaYGvs= X-Google-Smtp-Source: AGHT+IEcQCBZUX0XPvMU/HR/ZggPQb9gubzweghrLhqmKZOk0qUOd1eYBHNQBuV7X9nl0tD9O65LoA== X-Received: by 2002:a17:906:3158:b0:aa6:9b02:7fd9 with SMTP id a640c23a62f3a-aa69b0280f8mr156112966b.52.1733757989462; Mon, 09 Dec 2024 07:26:29 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: [PATCH v1 0/1] Fix rpath handling in OCaml's Makefile.rules From: Christian Lindig In-Reply-To: Date: Mon, 9 Dec 2024 15:26:16 +0000 Cc: Xen-devel , Christian Lindig , David Scott , Anthony PERARD Content-Transfer-Encoding: 7bit Message-Id: <6C856A94-576C-4AE8-9B81-5AD827EB3B52@cloud.com> References: To: Andrii Sultanov X-Mailer: Apple Mail (2.3774.600.62) > On 9 Dec 2024, at 15:16, Andrii Sultanov wrote: > > As reported by Nix's Xen team, OCaml stub libs would embed an absolute > rpath in the binaries, which was picked up on by patchelf. This is a > symptom of improper handling of -rpath-link in the first place, so > correct that and get rid of the issue. > > Andrii Sultanov (1): > tools/ocaml: Specify rpath correctly for ocamlmklib > > tools/ocaml/Makefile.rules | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > -- > 2.39.5 > Acked-by: Christian Lindig From xen-devel-bounces@lists.xenproject.org Mon Dec 09 15:38:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 15:38:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851555.1265603 (Exim 4.92) (envelope-from ) id 1tKfqN-0008Q6-Ci; Mon, 09 Dec 2024 15:38:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851555.1265603; Mon, 09 Dec 2024 15:38: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 1tKfqN-0008Pz-8p; Mon, 09 Dec 2024 15:38:43 +0000 Received: by outflank-mailman (input) for mailman id 851555; Mon, 09 Dec 2024 15:38: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 1tKfqM-0008Pd-2X for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 15:38:42 +0000 Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [2a00:1450:4864:20::22a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a9d145fb-b643-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 16:38:40 +0100 (CET) Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-3011c7b39c7so16051461fa.1 for ; Mon, 09 Dec 2024 07:38: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: a9d145fb-b643-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1733758719; x=1734363519; 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=ccC9Eq8UwboddNPj6Ku02PI/oYVoN5BHgAe0Mril9cI=; b=fMnn9P5Rd/dYyU2oYDcDyg1JpM3kcOYr/KTwluiHHSrlj+9aHucTgs/T0yk9470ALC 1Et6nvo4cUSShPBBVeTvHY/163379csRyDT8l0pClM7tWbicBYBZBC0tcM7tCqJOgk3r X9ewwyxDd+N66ClvpWQGAysI+z+ZGafWmckLc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733758719; x=1734363519; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ccC9Eq8UwboddNPj6Ku02PI/oYVoN5BHgAe0Mril9cI=; b=v0umk2Pqx+4WG/0WyicdJNkx4x1cwDhSZSI0jy1dY/lP3+9Ff/53BQ2hjTYhDfzr2U AIcYxtl0Qryq9F2q2iOkm4pRFONaXU4p700BMz+l3XR27yh9KK8NBgk4nrhgxAZQ1pE0 y+4rgABaG3A67F5BXnfWY7sy/EFjMWhzROR6ZlmWgvVwpLlG+J0LMeNSRtbnb4hBmRvI P1jLKql/5m9D8Z+fjkat+WzkqghAkbOzfy7tBhYYw7aBegstEEGrZJC5xDJfMt60/OU0 1GLjdGg7Si5Gis+B9k24LQVIYxdplVgM16F0yEH1O00uWs0WpI11HG1nsWcH+9dJ5jYz NRkA== X-Gm-Message-State: AOJu0Yyx3mDEK5hC16uRJNXgnXyY/9DTSFElelWVzqV+dTcnE57sxrw9 L3vwMfZ/wGQJdS2TyyOlrOikNRrGINvLNYF++Xe1AfVM4ljEujgDJGJ+pFA19tibUtDkJGh8Wai 3uPf/Js0sc9FBcqk2ZToX3SxqsPBA+iJNxj76CHSJvj492juf X-Gm-Gg: ASbGnctcYEjgoMursJnKvCclQOG/Q+Se1WnLsSgDHtIO3G5UrUaUXIJ1fBhCIRJq4nm Gyf/ZAoVqLTgE/HQbQZHg9PwHI/8Ljw== X-Google-Smtp-Source: AGHT+IGfX+1+uMO34+9NNJ5ZALAWJ/mnl+JSd/htRbdoc0N9tcHVvtamorOn9xzmseheuIgykuqe4sS2XnH1U6Wo7PM= X-Received: by 2002:a2e:bccb:0:b0:2ff:55f0:ae4b with SMTP id 38308e7fff4ca-3002fc2585amr67716231fa.21.1733758718815; Mon, 09 Dec 2024 07:38:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andrii Sultanov Date: Mon, 9 Dec 2024 15:38:27 +0000 Message-ID: Subject: Re: [PATCH v1 0/1] Fix rpath handling in OCaml's Makefile.rules To: xen-devel@lists.xenproject.org Cc: Christian Lindig , David Scott , Anthony PERARD Content-Type: multipart/alternative; boundary="0000000000008fd77b0628d828a3" --0000000000008fd77b0628d828a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DO NOT COMMIT - this patch is not correct, and I will send an updated version later. On Mon, Dec 9, 2024 at 3:16=E2=80=AFPM Andrii Sultanov wrote: > As reported by Nix's Xen team, OCaml stub libs would embed an absolute > rpath in the binaries, which was picked up on by patchelf. This is a > symptom of improper handling of -rpath-link in the first place, so > correct that and get rid of the issue. > > Andrii Sultanov (1): > tools/ocaml: Specify rpath correctly for ocamlmklib > > tools/ocaml/Makefile.rules | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > -- > 2.39.5 > > --0000000000008fd77b0628d828a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
DO NOT COMMIT - this patch is not correct, and I will send= an updated version later.

On Mon, Dec 9, 2024 at = 3:16=E2=80=AFPM Andrii Sultanov <andrii.sultanov@cloud.com> wrote:
As reported by Nix's Xen team, OCaml s= tub libs would embed an absolute
rpath in the binaries, which was picked up on by patchelf. This is a
symptom of improper handling of -rpath-link in the first place, so
correct that and get rid of the issue.

Andrii Sultanov (1):
=C2=A0 tools/ocaml: Specify rpath correctly for ocamlmklib

=C2=A0tools/ocaml/Makefile.rules | 4 ++--
=C2=A01 file changed, 2 insertions(+), 2 deletions(-)

--
2.39.5

--0000000000008fd77b0628d828a3-- From xen-devel-bounces@lists.xenproject.org Mon Dec 09 15:56:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 15:56:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851565.1265612 (Exim 4.92) (envelope-from ) id 1tKg7K-0003Sf-P9; Mon, 09 Dec 2024 15:56:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851565.1265612; Mon, 09 Dec 2024 15:56: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 1tKg7K-0003SY-Ma; Mon, 09 Dec 2024 15:56:14 +0000 Received: by outflank-mailman (input) for mailman id 851565; Mon, 09 Dec 2024 15:56: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 1tKg7J-0003SS-Lg for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 15:56: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 1cc0afc5-b646-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 16:56:12 +0100 (CET) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-385f07cd1a4so3121445f8f.1 for ; Mon, 09 Dec 2024 07:56: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 41be03b00d2f7-7fd1570ae4esm6615603a12.43.2024.12.09.07.56.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 07:56: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: 1cc0afc5-b646-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733759771; x=1734364571; 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=fJf0V9+Ju346hjZ87tma06reIxf/VkI1okYq5jwMPlA=; b=a7mT3D9TIJzAdtOJOdbVyfNMPiOl95SIruWxr57QEBjHYbvZUbA2mta0Vz0DA2krbg b/5X4N2aJlzx+fy+KXsWskz5gf6aXYtPmITSR6BY1gQIBMUKTrJVJrfu06OWfb5oUV89 zMDICFncxLEKr0Bu05X2cK4kZbZDn5SJ+daEke8m+USlY8iFordkCRy6QSSJ8VLmqPMr hrmKMyiHnpzapxEhJ/CC7Y1OoORZd8xUbUqKCIzi8Q3DKUZ+HgyAaT9ZFDigsG8SEGkJ d0xpaFOpb69tYWBjcOdjeYDLpWCZwSd2hQ0ltSOu7s9odMyX2Jvgq1T1IM+TEEjETaOI zlgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733759771; x=1734364571; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fJf0V9+Ju346hjZ87tma06reIxf/VkI1okYq5jwMPlA=; b=bA97tYrtPYc7Wr4/UcYgw0CZ6JGM8BWK5pQV1qNnj6+Rw/C5uV/8iRHkO2HPzVLfUL GLWMra0XRlMDb4cM8LPITE5V5kr0xibS3hxMf8MXalQrE2UFZGwdUpP1kexivI2oxl3P iUIsZYDwifqJqHK/Vi8aaf6S4Yz3JNOxnJuJRYVz71Tg60hA7mP2x36pOlgnIzWsKwaY MqhD1ipHkIX0Z4DsYJUQUyTeSk7LNjoKXXmoymbzjlhz4+dVCp7vklMHV46igRQ/hIhE PTryAONUSYR98Jk6MgUJZf5X6C0X0Jpdn2L5B9HiM3M1qQbrV6Yujk2emm0OmpL4RNQ2 wlzg== X-Forwarded-Encrypted: i=1; AJvYcCXW16mR8fSj4P7zkep8SqZQv4imMyLRzsiC3T93AQKMYxtX1IJloiWq38mLviE/n30tdYgvDK8VrLA=@lists.xenproject.org X-Gm-Message-State: AOJu0YwPlSAVnYVNXmMPPH0gB3oA8iwByBiz+tQAJDNdk/TxnncIp9y8 +G2BNSMIe6NG+zDcwJIrTgS8B98v5kor9qBz23T8uYiPFbP71tQ1h524bFKB8Q== X-Gm-Gg: ASbGncu0OoUwFaJHVaFpkq08Se/N0mdpfqGoh/i2jAdIqXp7n1I01mdOmxGPEpf80fW 7+jCqecM6iCDo7+HQXDSTStxBm2MapH8KBaUo7gg++lw5SmDHGdYg3C1oJcB1cR+fwEUqmDHuLr /IKXbnhoU1CIjFRD44a+S5lMzy3leff8SeELGRxwv/Fk5CnaXTw4wwg88cFxzkfOgManZ5+8h9C o8BcYl5wd7dYmDD4bEwKcD/xicOlLv1KhP6VWPhXUtpclvt7ZU8qAlhgm6VJnTTeRcgeXUVrTcJ gp1ik/s94ztQInNTxu/fm5XmzR8fR/boNLE= X-Google-Smtp-Source: AGHT+IHm4vYgr1ra2NZEQADIK7nrsLNhtwPlIqtmKQYwyjIT9i95aXHIonnPbJ7AuNkxg2hMThMIjw== X-Received: by 2002:a05:6000:461a:b0:385:f07b:93da with SMTP id ffacd0b85a97d-3862b3e43b0mr9004234f8f.47.1733759771353; Mon, 09 Dec 2024 07:56:11 -0800 (PST) Message-ID: Date: Mon, 9 Dec 2024 16:56:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 6/6] xen/riscv: relocating and unflattening host device tree To: Oleksii Kurochko Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , Julien Grall , 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 27.11.2024 13:50, Oleksii Kurochko wrote: > Relocate FDT to Xen heap instead of using early mapping as it is > expected that discard_initial_modules() ( is supposed to call in > the future ) discards the FDT boot module and remove_early_mappings() > destroys the early mapping. > > Unflatten a device tree, creating the tree of struct device_node. > It also fills the "name" and "type" pointers of the nodes so the normal > device-tree walking functions can be used. > > Set device_tree_flattened to NULL in the case when acpi_disabled is > equal to false. > > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich Albeit ... > @@ -71,6 +72,7 @@ void __init noreturn start_xen(unsigned long bootcpu_id, > paddr_t dtb_addr) > { > const char *cmdline; > + size_t fdt_size; > > remove_identity_mapping(); > > @@ -95,7 +97,7 @@ void __init noreturn start_xen(unsigned long bootcpu_id, > _end - _start, false) ) > panic("Failed to add BOOTMOD_XEN\n"); > > - if ( !boot_fdt_info(device_tree_flattened, dtb_addr) ) > + if ( !(fdt_size = boot_fdt_info(device_tree_flattened, dtb_addr)) ) > BUG(); ... perhaps better fdt_size = boot_fdt_info(device_tree_flattened, dtb_addr); BUG_ON(!fdt_size); ? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 15:58:07 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 15:58:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851578.1265623 (Exim 4.92) (envelope-from ) id 1tKg98-00043f-5q; Mon, 09 Dec 2024 15:58:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851578.1265623; Mon, 09 Dec 2024 15: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 1tKg98-00043Y-33; Mon, 09 Dec 2024 15:58:06 +0000 Received: by outflank-mailman (input) for mailman id 851578; Mon, 09 Dec 2024 15: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 1tKg96-00043P-Da for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 15:58:04 +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 5eaeeb6e-b646-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 16:58:02 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-385e06af753so2008818f8f.2 for ; Mon, 09 Dec 2024 07:58:02 -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 d9443c01a7336-216221db645sm51050685ad.46.2024.12.09.07.57.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 07:58: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: 5eaeeb6e-b646-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733759882; x=1734364682; 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=hPFWur24oZ0+j3v8fcdhH42mXvRL1EKpzLETRZJFrWs=; b=gNLWQ/2b2I2SZw3PqTiTypL5axdhqo08WZww4hDo6Dxv8dosBcaOwhv6mOnqHcMXwi OivM57RypInpG5wv2TPBK/Sy6UE+r3ezYRhPYxuEygp5RyAqRyEZ+WG27bjKBcc9pPMR O37qpjfRbcyRzguSwarPJODRv4HmkIWhklBEpk27yd3W3roljNV3VuIoG8r0N7Lb52Be DhaVgzMqAt76JsPf2Y4c+L3qIJ54moHIHYvMYHFv4bxtK4pOI3FqgwBkj3CR+83zaZCi sPmTdC/JDgLk7ML8JeJaZH5kmHTXQFBRPDj1yq+V9XehCdS0cYyUGHeyfRBfS+9aOVcU PjOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733759882; x=1734364682; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hPFWur24oZ0+j3v8fcdhH42mXvRL1EKpzLETRZJFrWs=; b=IRmkHd9atApOG13hb45n/n9Hqoh8ctuliK/ZIJaPFAjPdDxEOmAN3ol6cVJEY+GNM4 V16xCF+Nz/Z7EQMjkxdQET+wXT4PEGnlCYI4LgpRXLBLOycTjMixNs76hMOTTflcm7sD Ac4ZhfnboUrC7yRJNKl40bxXvjvkQtF7zvWm/5VrQzPvMEfX9KqRNbWEEFZZEfmYlOR2 zvXcTFoZZhHN0geOpilk5IdBy3RZJsMQnSDkZP4Wslf94KZTX5dWK+HnlOuWARYhjUsN i5N+x+TGRsmIiKKXOYtQXa7LarZ5UWFSLnSZpoWtHGQSgrCF8s7Sz63gFqv0ux99RrPh tSbg== X-Forwarded-Encrypted: i=1; AJvYcCWlmAF/0X408Iu040WgbVVIIEqMrOcXOM45WhvSxCnVjmWQR5VOpaZZQ7TQxzYwZqbHg8cKXAhk9QE=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxci0HuxWSPPBE9ltchISg+UC+14rQvyqEFUxpkkUlaAfke13wN 8AH6u04ibxkUP3ELgvI/a8Uu9Z02tE5OxKX1w73w6CG4bSBdkObcB/4Ab+SuKQ== X-Gm-Gg: ASbGncv/XKq9HpoQTNoru24toI7lY7CXu1Ie9+1EkbAXbPI9i+VA76XhoPhxM47UV5O UARoRbmTMptUF7aQOAtMPcR1tpkWqSWi2cHCU0UWl8x+QtfXTNmLRsWk2JTvKs4NKPfyGfDkCtk k/4JeapV3YdNiGyGE/kS4zkkBIZ3CLt4KCfJlDFUgdLeYYe8Uyayy7ciA+nNAAkVwoKA7N45Kwf jNYUS9AFViRGHcakyoGVDe7dscnB5lZeq7hd/aHl+KL1JbLcq6k15AVV35QD0tBGYV48FRL6meo gWwrBtNKxyd/0q2+qqRu2VL0hGnf8xmedjA= X-Google-Smtp-Source: AGHT+IGX4VXM/giAgAbWmaO5+dBhbJSUnPx++bO/X9g5YKVFH7twhK+oMUam3ZcAAMjQAvZB4PS6MQ== X-Received: by 2002:a05:6000:1887:b0:385:e2c4:1f8d with SMTP id ffacd0b85a97d-386453dd6b4mr573833f8f.19.1733759882029; Mon, 09 Dec 2024 07:58:02 -0800 (PST) Message-ID: <34fbc3bf-f740-47bd-90e4-2f8b9ce46cfd@suse.com> Date: Mon, 9 Dec 2024 16:57:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 6/6] xen/riscv: relocating and unflattening host device tree From: Jan Beulich To: Oleksii Kurochko Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: 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: 7bit On 09.12.2024 16:56, Jan Beulich wrote: > On 27.11.2024 13:50, Oleksii Kurochko wrote: >> Relocate FDT to Xen heap instead of using early mapping as it is >> expected that discard_initial_modules() ( is supposed to call in >> the future ) discards the FDT boot module and remove_early_mappings() >> destroys the early mapping. >> >> Unflatten a device tree, creating the tree of struct device_node. >> It also fills the "name" and "type" pointers of the nodes so the normal >> device-tree walking functions can be used. >> >> Set device_tree_flattened to NULL in the case when acpi_disabled is >> equal to false. >> >> Signed-off-by: Oleksii Kurochko > > Acked-by: Jan Beulich > > Albeit ... > >> @@ -71,6 +72,7 @@ void __init noreturn start_xen(unsigned long bootcpu_id, >> paddr_t dtb_addr) >> { >> const char *cmdline; >> + size_t fdt_size; >> >> remove_identity_mapping(); >> >> @@ -95,7 +97,7 @@ void __init noreturn start_xen(unsigned long bootcpu_id, >> _end - _start, false) ) >> panic("Failed to add BOOTMOD_XEN\n"); >> >> - if ( !boot_fdt_info(device_tree_flattened, dtb_addr) ) >> + if ( !(fdt_size = boot_fdt_info(device_tree_flattened, dtb_addr)) ) >> BUG(); > > ... perhaps better > > fdt_size = boot_fdt_info(device_tree_flattened, dtb_addr); > BUG_ON(!fdt_size); > > ? And then I notice that Arm has no such check at all. Better stay in sync? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 16:12:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 16:12:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851591.1265632 (Exim 4.92) (envelope-from ) id 1tKgMX-00083h-9i; Mon, 09 Dec 2024 16:11:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851591.1265632; Mon, 09 Dec 2024 16:11: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 1tKgMX-00083a-6q; Mon, 09 Dec 2024 16:11:57 +0000 Received: by outflank-mailman (input) for mailman id 851591; Mon, 09 Dec 2024 16:11: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 1tKgMV-00083S-As for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 16:11:55 +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 4cecf893-b648-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 17:11:51 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-434e3953b65so16333345e9.1 for ; Mon, 09 Dec 2024 08:11: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 d9443c01a7336-2162e21321asm40682655ad.279.2024.12.09.08.11.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 08:11: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: 4cecf893-b648-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733760711; x=1734365511; 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=Gyzqo7bRVYMufBR17kdjp7iMc+i69+DLutsfKr8+tTU=; b=Bh6rfJc58vkkRhmcqFVo+d/Ltzm3XDhCY/WO7+rpAB2wqIAYBq3NVxWMQ7IpvDvRMj Giqvr5IPlg3Lo1PnvE7bBq19qJKjdtAOx3ImReRsN1QB1+rka519sS5t+S9rui6WkYLR 3M+y1Zx79Sw4A/pzeAM+DAWy/DF+h4tU+dCUWwOdXE2kUSZrI7p+Mg5hADNatbr0+SM8 u475/uxQ/Btz2wHueHzFeUqy/7LEk56dXcLy/Dp4gka2/UmtHQKKYMhDes2DfC7jAUct zzLgtetkRmneiKE0nxCgkd2PzOzgDG93tiMqGDRRUJh9QDpoDIeDa0npwE297pVtRw35 soDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733760711; x=1734365511; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Gyzqo7bRVYMufBR17kdjp7iMc+i69+DLutsfKr8+tTU=; b=RmC9Yk/hrToU/TTnuHOHNYD5LxUbT4NEgYXQnZWaXE7bhCSERrHl+VLKemesIuF4/s K1qIi2xN3+WSYL0bt8hFLbGaNS7XNnVaRnXzxzkraofFtfYERXnioBdmvxX9m4BtWiZd N62tMIE7b7ejzmXoCGP78eDO4SU18OnEjPg7xuHL1U9SHR+c6elhO+u++Xs+rIpfBl+5 0rW/UVQEmhk89K2Qx2LYr8632Mder+yObRlOLZaa5BbvBKUryhF61t1risk+wHiO3nZO 8jui0+a7+zpJK2o3pJND4o6LrPJ5yn7vIQEQLOxVnqgEG3LkR672j211GkejMjrjLqAO hIlA== X-Forwarded-Encrypted: i=1; AJvYcCWsCgtqpY0l4hb2Yy038E9lsgt23MHFzgqw1rVvC5LY7xWwklfrV9fnseKZ2l7RjeaLlxdAdHTFQYc=@lists.xenproject.org X-Gm-Message-State: AOJu0YxjCSD8o4XNGUz4Hgy85LTQCFmWBQnzt+F4DMsDC2xk6pzEQUKK Dg6FPn7EJ3Qnkird4Q72HWT2kMpCW4+nR21tzL8jDhxrtSUyTh+I4y2Ngo9rHg== X-Gm-Gg: ASbGncuYZAhAu2OFxLN5y3Mu1W8QLCVAkzbVxQmR7UZhWpZo6tEX6O4ClTT0U4kltCx QZvTIzbcNuKAP37bKV/D2wF45IPOP0XzaER4cxvu5m1hJkEJVESWFF/k6cRiE9JKl2O66U+FiOP vivBAp0gjEG2qkgL8NtWV9T+z9PLpwd6+D3Vja0hFM/ugrOuctmDUVdj9dbAWZsSmYsugBQBqTC c46XTQkOE6mEP8kI6SkREgk6q1K+z5CqvBSVuBwXFQHECl5EQqYxlJEQ55hlumkAXYEDLTgerAy nKBt94sCeB9EgHu4FtNq3T4AMe2lXdnIEtE= X-Google-Smtp-Source: AGHT+IGmNpHaOT+4fLUqC65cWUDK16xQMCJs+oPNKzepCaHfISj0rWu5TYQwxkevxiPhyoXaYseAsw== X-Received: by 2002:a5d:59ab:0:b0:386:3f3e:ab11 with SMTP id ffacd0b85a97d-386453eaaffmr889480f8f.34.1733760711107; Mon, 09 Dec 2024 08:11:51 -0800 (PST) Message-ID: <2948b6c9-eb8b-400f-be0a-274cbf7ffde6@suse.com> Date: Mon, 9 Dec 2024 17:11:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 02/13] x86/xstate: Create map/unmap primitives for xsave areas To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241105143310.28301-1-alejandro.vallejo@cloud.com> <20241105143310.28301-3-alejandro.vallejo@cloud.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: <20241105143310.28301-3-alejandro.vallejo@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.11.2024 15:32, Alejandro Vallejo wrote: > --- a/xen/arch/x86/include/asm/xstate.h > +++ b/xen/arch/x86/include/asm/xstate.h > @@ -143,4 +143,46 @@ static inline bool xstate_all(const struct vcpu *v) > (v->arch.xcr0_accum & XSTATE_LAZY & ~XSTATE_FP_SSE); > } > > +/* > + * Fetch a pointer to a vCPU's XSAVE area > + * > + * TL;DR: If v == current, the mapping is guaranteed to already exist. > + * > + * Despite the name, this macro might not actually map anything. The only case > + * in which a mutation of page tables is strictly required is when ASI==on && > + * v!=current. For everything else the mapping already exists and needs not > + * be created nor destroyed. > + * > + * +-----------------+--------------+ > + * | v == current | v != current | > + * +--------------+-----------------+--------------+ > + * | ASI enabled | per-vCPU fixmap | actual map | > + * +--------------+-----------------+--------------+ > + * | ASI disabled | directmap | > + * +--------------+--------------------------------+ > + * > + * There MUST NOT be outstanding maps of XSAVE areas of the non-current vCPU > + * at the point of context switch. Otherwise, the unmap operation will > + * misbehave. > + * > + * TODO: Expand the macro to the ASI cases after infra to do so is in place. > + * > + * @param v Owner of the XSAVE area > + */ > +#define VCPU_MAP_XSAVE_AREA(v) ((v)->arch.xsave_area) When this is fleshed out, I expect (hope) type safety (type of "return value") will remain to be there. I think it would be nice ... > +/* > + * Drops the mapping of a vCPU's XSAVE area and nullifies its pointer on exit > + * > + * See VCPU_MAP_XSAVE_AREA() for additional information on the persistence of > + * these mappings. This macro only tears down the mappings in the ASI=on && > + * v!=current case. > + * > + * TODO: Expand the macro to the ASI cases after infra to do so is in place. > + * > + * @param v Owner of the XSAVE area > + * @param x XSAVE blob of v > + */ > +#define VCPU_UNMAP_XSAVE_AREA(v, x) ({ (x) = NULL; }) ... if this was typesafe (at least on x) from the very beginning as well. Thoughts? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 16:13:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 16:13:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851599.1265642 (Exim 4.92) (envelope-from ) id 1tKgNo-00007f-JC; Mon, 09 Dec 2024 16:13:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851599.1265642; Mon, 09 Dec 2024 16:13:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKgNo-00007W-GX; Mon, 09 Dec 2024 16:13:16 +0000 Received: by outflank-mailman (input) for mailman id 851599; Mon, 09 Dec 2024 16:13: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 1tKgNm-00007M-EA for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 16:13:14 +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 7db06b8b-b648-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 17:13:13 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-3862d161947so2246364f8f.3 for ; Mon, 09 Dec 2024 08:13: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 d2e1a72fcca58-72739e569e6sm823805b3a.162.2024.12.09.08.13.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 08:13: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: 7db06b8b-b648-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733760793; x=1734365593; 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=4KNYZ7a2I2dbgKZ1H8TKiU7KiDZpr7dlCDtIM0BRtjQ=; b=FN/3q/HcUYSsiGtO+YCqYrDCJwi1pkxw+FHLQMFjiFQdy8+r8UD8jh4uL5KTVKBE57 d9ux3sY6ibvVQLBeth+Jk5ORvYLwRqK11rtFe6r9S/LLDXXTRws9mrmizLOhbjN/1pxI EXeEMNB7ZDs1JP4POZn3kSEAHbuG5UJW2PqheIUtCVSd6DAF0ZEz3MbHuhen6DEzWuRz 1Yxz6m4Moa8xIvLksVub+yel1a4Sbrh3Xsm7y71zJvX1YgkWeZ+/w1RQGYACAm1DKSnZ FmrgnhRe9R04hsducCkqQCW0OWxj9kFrr60vpflLCMbqarkgni26J5+iyexWNAU/S577 NO9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733760793; x=1734365593; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4KNYZ7a2I2dbgKZ1H8TKiU7KiDZpr7dlCDtIM0BRtjQ=; b=Pb8zZzNxHzouO4EMpM1tlZoBmcHAntIbxwOxbbbzZZClE7n3Sab142xIbbKfEvipzR 4DTnKRoGAKbQ1y2t8AjfVLtJ8kdR4qzq752rofCgbmpGUL/lADxD1zv6ZnVsPHrMZCSS s0LbRfVq140Hw+SpYSugEr8t1CvddSGcm7GJUF4ujpAYgB91X3bxzlbSZVFrnNHRF04S 2iYiLLPHg5ov0mSGl2wrH6OKIbw5BDQzNBWdzz7tCevn+JDwD/cA21trgQmKAmnnZgMh ieuoLWkc9go1fl0+uV/VHx8Xu6gvuYSiZfOl8UaZxPnERfUvy8J8EKH5lbnNZyPr1P0a XB9w== X-Forwarded-Encrypted: i=1; AJvYcCWJySiHI/PAtwrvsyKNue5YWvoiykblGr69sR2Sf2a5qewPEcDyTL4QBxFsX6MTGSz3qsyUiUuadWE=@lists.xenproject.org X-Gm-Message-State: AOJu0YzjZr4tftTSn6H1C/49MLeUKrSamRlAN8ugY3MPK79Su8PRs/fA lOwBx/6wVYYitv6wkDUFrrpphiIrJHo9l765UYkL8eHX4SdPCOWU9S5glbnw1A== X-Gm-Gg: ASbGncvhHiEFqacGLFXhKZA5GaNb7VZJIb3D/UOobNSAbWevxiwuSsKf4fIgDA9cILr WOscMzFA80KX5RQE/0qYhCcU2yjMmrpD6khhOK9zrJLB4KpWjqBuZ2bhvzdFeac0VhL8exg8xYC cbBaAzfxwwKoC6vkJp0IhlfT2MHRlWDjyM46+8USE+NrdP7PdwcP9SGAvLPwXwZKQl0Hw7yDj9x PpuMBwIq8AplfTTUz8BnMyukzBOsrGrQfRIptS25506Ao2daUw/0wDeYF+lLJavqaSj7czPeZ8t sg2uNg/ZtwdLddGzi4BKluQzBYz0NK9R/OY= X-Google-Smtp-Source: AGHT+IEV3lXEEfLLZxYP/Fmsajh3IfZ+eGphhQ6hTXlH8z/dSjU6F0lpvnjUQT72ddwetC851Hr/JQ== X-Received: by 2002:a5d:588f:0:b0:385:f9db:3c4c with SMTP id ffacd0b85a97d-3862b33e5c1mr10241414f8f.9.1733760793043; Mon, 09 Dec 2024 08:13:13 -0800 (PST) Message-ID: <136986f9-29e1-4c73-b4e8-4c59c5204ec2@suse.com> Date: Mon, 9 Dec 2024 17:13:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/13] x86/hvm: Map/unmap xsave area in hvm_save_cpu_ctxt() To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241105143310.28301-1-alejandro.vallejo@cloud.com> <20241105143310.28301-4-alejandro.vallejo@cloud.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: <20241105143310.28301-4-alejandro.vallejo@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.11.2024 15:33, Alejandro Vallejo wrote: > No functional change. > > Signed-off-by: Alejandro Vallejo Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Dec 09 16:14:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 16:14:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851607.1265653 (Exim 4.92) (envelope-from ) id 1tKgOw-0000gv-TT; Mon, 09 Dec 2024 16:14:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851607.1265653; Mon, 09 Dec 2024 16:14: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 1tKgOw-0000go-Py; Mon, 09 Dec 2024 16:14:26 +0000 Received: by outflank-mailman (input) for mailman id 851607; Mon, 09 Dec 2024 16: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 1tKgOw-0000gg-BO for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 16:14:26 +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 a8822253-b648-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 17:14:25 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-385e0e224cbso2346717f8f.2 for ; Mon, 09 Dec 2024 08:14: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 d2e1a72fcca58-725e59ec54esm2902988b3a.85.2024.12.09.08.14.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 08:14: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: a8822253-b648-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733760865; x=1734365665; 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=4KNYZ7a2I2dbgKZ1H8TKiU7KiDZpr7dlCDtIM0BRtjQ=; b=MHTOmHH77TyE7KfmvmRZ585ekxXST92HTUbtbrShe/JYjJdghwpn+iWTTD4MwpLPqS X26hU+/o/KhJCqQoGIZTmS41Q0npjPHTLvDX9NCv8lNgNcOsdibapdhoSSgA9evdrygi GlNmxHEd9aN9wHEj/pj0hELRSWMWw3yiU8Asl8O5Ukkw05aI0vqDybScutG0uBJo3HQo t/Sae/bZ6wNSrspGHKHNzX/v5LaYtZw60sytZwWZCyZQrX7Gk3wDmfpN+fYRRrCOQOM3 25VZ3qFtPRpk5LZpxYFfAw2UNg+14A8J6bgFDXGWzL44HhXL1aPedR5kq0BElp3GuvkH KV+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733760865; x=1734365665; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4KNYZ7a2I2dbgKZ1H8TKiU7KiDZpr7dlCDtIM0BRtjQ=; b=ojGEjP3wHJ3M307h7X7niW7etOTOYjj0hk9X1yIRrQsn0VtGqp/BeIRdkwSdFI1djv qD8VY30ip3Rcu+TPCmDqXCJNevf3wlbCk/wtYlAD6wEjsbZ/ICQl78bDukXjDJCiEqVz K/4Pi+pHBw+hKsY3laeZJaK/c99cEcm5+6mqTRN7R1TTyqVuvArptsFKhi7cF3tVyWWS 7BVd3S6BQPwmkyYkYHIk1hyq2sVUE2NEiVbed+3Clb5OwQA4lUVQTxGeVSRupT27aeKe ulU00Ojn3deM8UndKeN09GOKC7+lN5tEwVwPTL/4Xrwq5upX/XkrzxghvTOlpJSx59hF frvw== X-Forwarded-Encrypted: i=1; AJvYcCWiYb4wyhK8ABttmrHqA7J3gLrnXG1RIyLQKR/TNiD6APsPn+OySy8new8A3oUvS8F9zzMIRatpqgg=@lists.xenproject.org X-Gm-Message-State: AOJu0YzccC9FF/3xH9LgYDI4agdHHxRKrRhJBZ6WQZHHjeQuvSeLoGZN XQlGqTEMpSoYluKV5TE+b3AjdabXtlNnVdtn8MVvF3QfVUjm4KTLTbD3s0hl4A== X-Gm-Gg: ASbGncs42lfAYJH+K8camyDV1VxEaOPpGajtpQVqFEityrWArhVe/EaxceobuGoitbe a4GYnTyplpnpB0rn2rF4w29PXJhOFy2nEmAeEivVWPprzoWfj+XGl3MDTyD2Y6I8OBOef8zaVDx Am97tZb22Puc104B4NZL+syq8HkIQRrx8GGV1C7pz8X797FwInHSNnVKrVUeR8CCKklMEhKmNm/ 60vAJmtkSt+0Dyu5gQzThMYgLHW9xiwidlwcVxBQZLdnkAbh0S/JRFM+5VUxZso4+vEm85CAzNB Nth+KwZJbTcn0kPVarQMshxPM2mFBthuq2c= X-Google-Smtp-Source: AGHT+IEDkqxHYEkoxi4V34u1EsaX3FathzMs6FKXU5lBOq87a8WdDlxtTFcU3xKN+w/Lols4fhlHPw== X-Received: by 2002:a05:6000:2a7:b0:386:3d16:9609 with SMTP id ffacd0b85a97d-386453dbb27mr907422f8f.17.1733760863481; Mon, 09 Dec 2024 08:14:23 -0800 (PST) Message-ID: Date: Mon, 9 Dec 2024 17:14:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 04/13] x86/fpu: Map/umap xsave area in vcpu_{reset,setup}_fpu() To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241105143310.28301-1-alejandro.vallejo@cloud.com> <20241105143310.28301-5-alejandro.vallejo@cloud.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: <20241105143310.28301-5-alejandro.vallejo@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.11.2024 15:33, Alejandro Vallejo wrote: > No functional change. > > Signed-off-by: Alejandro Vallejo Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Dec 09 16:17:30 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 16:17:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851621.1265662 (Exim 4.92) (envelope-from ) id 1tKgRp-0001HP-8p; Mon, 09 Dec 2024 16:17:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851621.1265662; Mon, 09 Dec 2024 16:17: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 1tKgRp-0001HI-6I; Mon, 09 Dec 2024 16:17:25 +0000 Received: by outflank-mailman (input) for mailman id 851621; Mon, 09 Dec 2024 16:17: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 1tKgRo-0001HC-2J for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 16:17:24 +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 1281ab45-b649-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 17:17:23 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-385d7b4da2bso3837031f8f.1 for ; Mon, 09 Dec 2024 08:17: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 d2e1a72fcca58-725e054b3bbsm3257948b3a.42.2024.12.09.08.16.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 08:16: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: 1281ab45-b649-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733761042; x=1734365842; 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=kgZBGhZwbc3YtaGwh0Sp7Dx1oAkn5DYtUhx1DnSqQPg=; b=QPrtKJV2yxRcED8oHXyUO9xqzVzmifbbxie6UzCjHHpyGMDgc1q3N/hyDB/7y127OO Ej8mRKRHOrqPZg4QpA1VcW1D4s+TNk+TUJ50rcHeXrO78ZHv6qnbEUF1Bym+gV2Mifwy vTw1++uRVEoSseYhIco9mgC+d5f39FJgwF2a/OUt/evIQfLDUB6QEgbnfbq5nDpIwezW Sb+E70hukh7kAxja6ItWKkaF0DBhH4YiclXe4OPo5cx/P2DdJiOxjn5cr+z7grDg5Zm1 EF17QZ96UR57OsDirGTBASngkrJIWXe8Q9RA2+gX5mCFmobd0mvl7LjGbTpqUzVDi8Fw S3sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733761042; x=1734365842; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=kgZBGhZwbc3YtaGwh0Sp7Dx1oAkn5DYtUhx1DnSqQPg=; b=C9q1CPuyJX1mtycZ9XlrlTbRsuIi9cP40b6U78U8R6YJnInOx1ReG9CDKwu29EmSm8 p1pxFLXP9wKuqxgw1Lj78OtoqlyySrdqpeli2hr9AlhLfG/PzrXZYs4oCfq5SYnT7xUP tBBkbnGIwX9uUGHUAi0WAvCFD7pFL0cKhKIWNQETFL9IDtX8xwR1wI5x0KiVH/ad6LWG A83+f5p8rfIe2I9d1m5L5wbfc9D2iUTyq9DvnIlX4zKgGkQrcfTbqGH01yKfEUODfK70 dSCuhmQqVF5IAPgSEKpyxNXrHsX5Xn8cv0O5dib5F9oLA34b+wU8gfQYY6/pJq1B/kYk 7KWA== X-Forwarded-Encrypted: i=1; AJvYcCXUmqLJGDX4vLH5gF+SCqJRhGHzFhBCcpp8mpIaKhqSdQIdVkcs/kMzL/6PmxCE5rAtygY7iDcLm3o=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx+TxWwCPZwP36j/WvziaguCXLaCQLK3dNwhsJtWlMQ7FYm9s6y E1evSbGTl/3ywY3hFpKKX9JRWGVL+V2L2RvBpsHmqdFRwwvFBK8GrAQEQ739HA== X-Gm-Gg: ASbGncth2cqQtd/IiwzdEOGiDq7MR0dFc/7Q/IPoIWS/AK8VaFXlLjqoYKCirJzqmno 8ExrBlcXPkMdD9J8LKRYxMEJ1bHuirqiIJwkSNp0K7uvIKUDzeVhdLuyEJVIcTRFEyqdmUW0YEh qtkyD69NzMI/iolPGWlYQgbeBEk3prej0saVyotbaDM5EzAwUWSQFVThgOKDG6c7jtGhVa+dj79 BLJKVDVKiShKoosoiqEpIX7PvziFUgb0Sn/yQ7KtRH/UrPxVVf98nn/PDhUN+HeNPEa8RAn/lPX Etia8dAaUni/uYy8G/q3P7N2xAL8riqqBGI= X-Google-Smtp-Source: AGHT+IGaWggHeLj4QU/2f1Mg8nIO+RF40XpSELE6qVsekFnWkJk05kr/mElKFOk9baJStEAdK/drpQ== X-Received: by 2002:a5d:584b:0:b0:386:3672:73c7 with SMTP id ffacd0b85a97d-386453d931amr1350434f8f.17.1733761012731; Mon, 09 Dec 2024 08:16:52 -0800 (PST) Message-ID: Date: Mon, 9 Dec 2024 17:16:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 05/13] x86/xstate: Map/unmap xsave area in xstate_set_init() and handle_setbv() To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241105143310.28301-1-alejandro.vallejo@cloud.com> <20241105143310.28301-6-alejandro.vallejo@cloud.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: <20241105143310.28301-6-alejandro.vallejo@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.11.2024 15:33, Alejandro Vallejo wrote: > No functional change. > > Signed-off-by: Alejandro Vallejo Acked-by: Jan Beulich with ... > --- a/xen/arch/x86/xstate.c > +++ b/xen/arch/x86/xstate.c > @@ -993,7 +993,13 @@ int handle_xsetbv(u32 index, u64 new_bv) > > clts(); > if ( curr->fpu_dirtied ) > - asm ( "stmxcsr %0" : "=m" (curr->arch.xsave_area->fpu_sse.mxcsr) ); > + { > + /* has a fastpath for `current`, so there's no actual map */ > + struct xsave_struct *xsave_area = VCPU_MAP_XSAVE_AREA(curr); ... comment style adhered to (capital 'H'). Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 16:17:35 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 16:17:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851623.1265673 (Exim 4.92) (envelope-from ) id 1tKgRz-0001aW-LE; Mon, 09 Dec 2024 16:17:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851623.1265673; Mon, 09 Dec 2024 16:17: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 1tKgRz-0001aK-HC; Mon, 09 Dec 2024 16:17:35 +0000 Received: by outflank-mailman (input) for mailman id 851623; Mon, 09 Dec 2024 16:17: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 1tKgRx-0001HC-IV for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 16:17:34 +0000 Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 16f48bbc-b649-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 17:17:30 +0100 (CET) Received: by mail.gandi.net (Postfix) with ESMTPSA id 895801C0005; Mon, 9 Dec 2024 16:17:28 +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: 16f48bbc-b649-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1733761049; 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=919IoHK8fqPsTQmbz5S8HS0P7OaLW9n/0ZAheVWxu1o=; b=LEC0ALmzfvNTu5X1bkuR3j2VHKj4LxPzirtcvPZKrnqGWcAdbLG0FqFScs51NQPhM/gwsG TWjk4HSzlFRNYUZVOcgfsdgsLOEFtYw8A+76ZARDo3TwwkfMegMEuo8C8s8J4xpk9w+xq6 GDZ4CXzd5v5vCZ8INJ/UliSm6U2zWQleZjSMuz28b6bb/rs5X91vsnc5178GTx4a0VEX6U BUS9eR7l8rEqm/i83L6Z98Nbxx/Ihb9QXLdcj0ZvMrvIJaLdL/YvRxdJ4sJAriTjl6ci3D iGX1qOhRFwyJ8WnM8jEDcs7cauBCYIEbHFiBAL7PTbEWGNFK+ohXaQC1rKEKsg== Date: Mon, 9 Dec 2024 17:17:27 +0100 From: Louis Chauvet To: Jani Nikula Cc: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org, Javier Martinez Canillas , Alex Deucher , Simon Ser , Jeffrey Hugo , David Airlie , Hamza Mahfooz , Maarten Lankhorst , Maxime Ripard , Oleksandr Andrushchenko , Simona Vetter , Thomas Zimmermann , Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , amd-gfx@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, nouveau@lists.freedesktop.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v2 3/3] drm: remove driver date from struct drm_driver and all drivers Message-ID: References: <1f2bf2543aed270a06f6c707fd6ed1b78bf16712.1733322525.git.jani.nikula@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1f2bf2543aed270a06f6c707fd6ed1b78bf16712.1733322525.git.jani.nikula@intel.com> X-GND-Sasl: louis.chauvet@bootlin.com On 04/12/24 - 16:31, Jani Nikula wrote: > We stopped using the driver initialized date in commit 7fb8af6798e8 > ("drm: deprecate driver date") and (eventually) started returning "0" > for drm_version ioctl instead. > > Finish the job, and remove the unused date member from struct > drm_driver, its initialization from drivers, along with the common > DRIVER_DATE macros. > > v2: Also update drivers/accel (kernel test robot) > > Reviewed-by: Javier Martinez Canillas > Acked-by: Alex Deucher > Acked-by: Simon Ser > Acked-by: Jeffrey Hugo > Signed-off-by: Jani Nikula Reviewed-by: Louis Chauvet > --- > > Cc: David Airlie > Cc: Hamza Mahfooz > Cc: Javier Martinez Canillas > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Oleksandr Andrushchenko > Cc: Simon Ser > Cc: Simona Vetter > Cc: Thomas Zimmermann > Cc: Ville Syrjälä > Cc: amd-gfx@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: nouveau@lists.freedesktop.org > Cc: xen-devel@lists.xenproject.org > --- > drivers/accel/habanalabs/common/habanalabs_drv.c | 1 - > drivers/accel/ivpu/ivpu_drv.c | 1 - > drivers/accel/qaic/qaic_drv.c | 1 - > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 -- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.h | 1 - > drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 1 - > drivers/gpu/drm/arm/hdlcd_drv.c | 1 - > drivers/gpu/drm/arm/malidp_drv.c | 1 - > drivers/gpu/drm/armada/armada_drv.c | 1 - > drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 1 - > drivers/gpu/drm/ast/ast_drv.c | 1 - > drivers/gpu/drm/ast/ast_drv.h | 1 - > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 1 - > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 1 - > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 -- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 1 - > drivers/gpu/drm/gma500/psb_drv.c | 1 - > drivers/gpu/drm/gma500/psb_drv.h | 1 - > drivers/gpu/drm/gud/gud_drv.c | 1 - > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 1 - > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 1 - > drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 2 -- > drivers/gpu/drm/i915/i915_driver.c | 1 - > drivers/gpu/drm/i915/i915_driver.h | 1 - > drivers/gpu/drm/i915/i915_gpu_error.c | 1 - > drivers/gpu/drm/imagination/pvr_drv.c | 1 - > drivers/gpu/drm/imagination/pvr_drv.h | 1 - > drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 - > drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 1 - > drivers/gpu/drm/imx/lcdc/imx-lcdc.c | 1 - > drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 1 - > drivers/gpu/drm/kmb/kmb_drv.c | 1 - > drivers/gpu/drm/kmb/kmb_drv.h | 1 - > drivers/gpu/drm/lima/lima_drv.c | 1 - > drivers/gpu/drm/logicvc/logicvc_drm.c | 1 - > drivers/gpu/drm/loongson/lsdc_drv.c | 2 -- > drivers/gpu/drm/mcde/mcde_drv.c | 1 - > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 -- > drivers/gpu/drm/meson/meson_drv.c | 1 - > drivers/gpu/drm/mgag200/mgag200_drv.c | 1 - > drivers/gpu/drm/mgag200/mgag200_drv.h | 1 - > drivers/gpu/drm/msm/msm_drv.c | 1 - > drivers/gpu/drm/mxsfb/lcdif_drv.c | 1 - > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 1 - > drivers/gpu/drm/nouveau/nouveau_drm.c | 5 ----- > drivers/gpu/drm/nouveau/nouveau_drv.h | 1 - > drivers/gpu/drm/omapdrm/omap_drv.c | 2 -- > drivers/gpu/drm/panfrost/panfrost_drv.c | 1 - > drivers/gpu/drm/panthor/panthor_drv.c | 1 - > drivers/gpu/drm/pl111/pl111_drv.c | 1 - > drivers/gpu/drm/qxl/qxl_drv.c | 1 - > drivers/gpu/drm/qxl/qxl_drv.h | 1 - > drivers/gpu/drm/radeon/radeon_drv.c | 1 - > drivers/gpu/drm/radeon/radeon_drv.h | 1 - > drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 1 - > drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 1 - > drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c | 1 - > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 -- > drivers/gpu/drm/solomon/ssd130x.c | 2 -- > drivers/gpu/drm/sprd/sprd_drm.c | 2 -- > drivers/gpu/drm/sti/sti_drv.c | 2 -- > drivers/gpu/drm/stm/drv.c | 1 - > drivers/gpu/drm/sun4i/sun4i_drv.c | 1 - > drivers/gpu/drm/tegra/drm.c | 2 -- > drivers/gpu/drm/tidss/tidss_drv.c | 1 - > drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 - > drivers/gpu/drm/tiny/arcpgu.c | 1 - > drivers/gpu/drm/tiny/bochs.c | 1 - > drivers/gpu/drm/tiny/cirrus-qemu.c | 2 -- > drivers/gpu/drm/tiny/gm12u320.c | 2 -- > drivers/gpu/drm/tiny/hx8357d.c | 1 - > drivers/gpu/drm/tiny/ili9163.c | 1 - > drivers/gpu/drm/tiny/ili9225.c | 1 - > drivers/gpu/drm/tiny/ili9341.c | 1 - > drivers/gpu/drm/tiny/ili9486.c | 1 - > drivers/gpu/drm/tiny/mi0283qt.c | 1 - > drivers/gpu/drm/tiny/ofdrm.c | 2 -- > drivers/gpu/drm/tiny/panel-mipi-dbi.c | 1 - > drivers/gpu/drm/tiny/repaper.c | 1 - > drivers/gpu/drm/tiny/sharp-memory.c | 1 - > drivers/gpu/drm/tiny/simpledrm.c | 2 -- > drivers/gpu/drm/tiny/st7586.c | 1 - > drivers/gpu/drm/tiny/st7735r.c | 1 - > drivers/gpu/drm/tve200/tve200_drv.c | 1 - > drivers/gpu/drm/udl/udl_drv.c | 1 - > drivers/gpu/drm/udl/udl_drv.h | 1 - > drivers/gpu/drm/v3d/v3d_drv.c | 2 -- > drivers/gpu/drm/vboxvideo/vbox_drv.c | 1 - > drivers/gpu/drm/vboxvideo/vbox_drv.h | 1 - > drivers/gpu/drm/vc4/vc4_drv.c | 3 --- > drivers/gpu/drm/vgem/vgem_drv.c | 2 -- > drivers/gpu/drm/virtio/virtgpu_drv.c | 1 - > drivers/gpu/drm/virtio/virtgpu_drv.h | 1 - > drivers/gpu/drm/vkms/vkms_drv.c | 2 -- > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 - > drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 - > drivers/gpu/drm/xe/xe_device.c | 1 - > drivers/gpu/drm/xe/xe_drv.h | 1 - > drivers/gpu/drm/xen/xen_drm_front.c | 1 - > drivers/gpu/drm/xlnx/zynqmp_kms.c | 1 - > include/drm/drm_drv.h | 2 -- > 101 files changed, 126 deletions(-) > > diff --git a/drivers/accel/habanalabs/common/habanalabs_drv.c b/drivers/accel/habanalabs/common/habanalabs_drv.c > index 708dfd10f39c..5409b2c656c8 100644 > --- a/drivers/accel/habanalabs/common/habanalabs_drv.c > +++ b/drivers/accel/habanalabs/common/habanalabs_drv.c > @@ -101,7 +101,6 @@ static const struct drm_driver hl_driver = { > .major = LINUX_VERSION_MAJOR, > .minor = LINUX_VERSION_PATCHLEVEL, > .patchlevel = LINUX_VERSION_SUBLEVEL, > - .date = "20190505", > > .fops = &hl_fops, > .open = hl_device_open, > diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c > index 1f359dbe5150..1e8ffbe25eee 100644 > --- a/drivers/accel/ivpu/ivpu_drv.c > +++ b/drivers/accel/ivpu/ivpu_drv.c > @@ -458,7 +458,6 @@ static const struct drm_driver driver = { > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > > - .date = UTS_RELEASE, > .major = 1, > }; > > diff --git a/drivers/accel/qaic/qaic_drv.c b/drivers/accel/qaic/qaic_drv.c > index 3575e0c984d6..542c5d24e499 100644 > --- a/drivers/accel/qaic/qaic_drv.c > +++ b/drivers/accel/qaic/qaic_drv.c > @@ -208,7 +208,6 @@ static const struct drm_driver qaic_accel_driver = { > > .name = QAIC_NAME, > .desc = QAIC_DESC, > - .date = "20190618", > > .fops = &qaic_accel_fops, > .open = qaic_open, > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > index 346746d6c233..eaeaaddb32cd 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > @@ -2916,7 +2916,6 @@ static const struct drm_driver amdgpu_kms_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = KMS_DRIVER_MAJOR, > .minor = KMS_DRIVER_MINOR, > .patchlevel = KMS_DRIVER_PATCHLEVEL, > @@ -2940,7 +2939,6 @@ const struct drm_driver amdgpu_partition_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = KMS_DRIVER_MAJOR, > .minor = KMS_DRIVER_MINOR, > .patchlevel = KMS_DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.h > index 5bc2cb661af7..2d86cc6f7f4d 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.h > @@ -40,7 +40,6 @@ > > #define DRIVER_NAME "amdgpu" > #define DRIVER_DESC "AMD GPU" > -#define DRIVER_DATE "20150101" > > extern const struct drm_driver amdgpu_partition_driver; > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c > index 1e7b1fcb2848..6ed504099188 100644 > --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c > @@ -63,7 +63,6 @@ static const struct drm_driver komeda_kms_driver = { > .fops = &komeda_cma_fops, > .name = "komeda", > .desc = "Arm Komeda Display Processor driver", > - .date = "20181101", > .major = 0, > .minor = 1, > }; > diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c > index 4af8fce7dab7..8617d10940d8 100644 > --- a/drivers/gpu/drm/arm/hdlcd_drv.c > +++ b/drivers/gpu/drm/arm/hdlcd_drv.c > @@ -233,7 +233,6 @@ static const struct drm_driver hdlcd_driver = { > .fops = &fops, > .name = "hdlcd", > .desc = "ARM HDLCD Controller DRM", > - .date = "20151021", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c > index 38b1b5b6bf69..3abc9339464b 100644 > --- a/drivers/gpu/drm/arm/malidp_drv.c > +++ b/drivers/gpu/drm/arm/malidp_drv.c > @@ -570,7 +570,6 @@ static const struct drm_driver malidp_driver = { > .fops = &fops, > .name = "mali-dp", > .desc = "ARM Mali Display Processor driver", > - .date = "20160106", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c > index ddf0eaf546a6..5d5b7435970a 100644 > --- a/drivers/gpu/drm/armada/armada_drv.c > +++ b/drivers/gpu/drm/armada/armada_drv.c > @@ -45,7 +45,6 @@ static const struct drm_driver armada_drm_driver = { > .minor = 0, > .name = "armada-drm", > .desc = "Armada SoC DRM", > - .date = "20120730", > .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC, > .ioctls = armada_ioctls, > .num_ioctls = ARRAY_SIZE(armada_ioctls), > diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c > index 55e90ab9b231..90189a3cf886 100644 > --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c > +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c > @@ -252,7 +252,6 @@ static const struct drm_driver aspeed_gfx_driver = { > .fops = &fops, > .name = "aspeed-gfx-drm", > .desc = "ASPEED GFX DRM", > - .date = "20180319", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c > index 8e9c9cb89a50..ff3bcdd1cff2 100644 > --- a/drivers/gpu/drm/ast/ast_drv.c > +++ b/drivers/gpu/drm/ast/ast_drv.c > @@ -60,7 +60,6 @@ static const struct drm_driver ast_driver = { > .fops = &ast_fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h > index 21ce3769bf0d..6b4305ac07d4 100644 > --- a/drivers/gpu/drm/ast/ast_drv.h > +++ b/drivers/gpu/drm/ast/ast_drv.h > @@ -43,7 +43,6 @@ > > #define DRIVER_NAME "ast" > #define DRIVER_DESC "AST" > -#define DRIVER_DATE "20120228" > > #define DRIVER_MAJOR 0 > #define DRIVER_MINOR 1 > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > index 506289a937e2..b51528b2166c 100644 > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > @@ -846,7 +846,6 @@ static const struct drm_driver atmel_hlcdc_dc_driver = { > .fops = &fops, > .name = "atmel-hlcdc", > .desc = "Atmel HLCD Controller DRM", > - .date = "20141504", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c > index 9b4e2f4b1bc7..c4ddabe3cabd 100644 > --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c > +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c > @@ -503,7 +503,6 @@ static const struct drm_driver etnaviv_drm_driver = { > .fops = &fops, > .name = "etnaviv", > .desc = "etnaviv DRM", > - .date = "20151214", > .major = 1, > .minor = 4, > }; > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c > index 7e517a2ec681..91ab42b56716 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c > @@ -35,7 +35,6 @@ > > #define DRIVER_NAME "exynos" > #define DRIVER_DESC "Samsung SoC DRM" > -#define DRIVER_DATE "20180330" > > /* > * Interface history: > @@ -118,7 +117,6 @@ static const struct drm_driver exynos_drm_driver = { > .fops = &exynos_drm_driver_fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > }; > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > index 12b2096b6c9d..e1183644ec39 100644 > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > @@ -174,7 +174,6 @@ static const struct drm_driver fsl_dcu_drm_driver = { > .fops = &fsl_dcu_drm_fops, > .name = "fsl-dcu-drm", > .desc = "Freescale DCU DRM", > - .date = "20160425", > .major = 1, > .minor = 1, > }; > diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c > index 2c56ece17d71..85d3557c2eb9 100644 > --- a/drivers/gpu/drm/gma500/psb_drv.c > +++ b/drivers/gpu/drm/gma500/psb_drv.c > @@ -513,7 +513,6 @@ static const struct drm_driver driver = { > .fops = &psb_gem_fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL > diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h > index de62cbfcdc72..7f77cb2b2751 100644 > --- a/drivers/gpu/drm/gma500/psb_drv.h > +++ b/drivers/gpu/drm/gma500/psb_drv.h > @@ -26,7 +26,6 @@ > > #define DRIVER_NAME "gma500" > #define DRIVER_DESC "DRM driver for the Intel GMA500, GMA600, GMA3600, GMA3650" > -#define DRIVER_DATE "20140314" > > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c > index 65a16f009ea6..cb405771d6e2 100644 > --- a/drivers/gpu/drm/gud/gud_drv.c > +++ b/drivers/gpu/drm/gud/gud_drv.c > @@ -381,7 +381,6 @@ static const struct drm_driver gud_drm_driver = { > > .name = "gud", > .desc = "Generic USB Display", > - .date = "20200422", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c > index 69bdae604982..7f814c32ed34 100644 > --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c > +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c > @@ -57,7 +57,6 @@ static const struct drm_driver hibmc_driver = { > .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC, > .fops = &hibmc_fops, > .name = "hibmc", > - .date = "20160828", > .desc = "hibmc drm driver", > .major = 1, > .minor = 0, > diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c > index 5616c3917c03..2eb49177ac42 100644 > --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c > +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c > @@ -929,7 +929,6 @@ static const struct drm_driver ade_driver = { > DRM_FBDEV_DMA_DRIVER_OPS, > .name = "kirin", > .desc = "Hisilicon Kirin620 SoC DRM Driver", > - .date = "20150718", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c > index c5ac240f7a7a..f59abfa7622a 100644 > --- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c > +++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c > @@ -20,7 +20,6 @@ > > #define DRIVER_NAME "hyperv_drm" > #define DRIVER_DESC "DRM driver for Hyper-V synthetic video device" > -#define DRIVER_DATE "2020" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -31,7 +30,6 @@ static struct drm_driver hyperv_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > > diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c > index c1edf5e1f61e..e35aa0274d76 100644 > --- a/drivers/gpu/drm/i915/i915_driver.c > +++ b/drivers/gpu/drm/i915/i915_driver.c > @@ -1797,7 +1797,6 @@ static const struct drm_driver i915_drm_driver = { > .fops = &i915_driver_fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/i915/i915_driver.h b/drivers/gpu/drm/i915/i915_driver.h > index 94a70d8ec5d5..4b67ad9a61cd 100644 > --- a/drivers/gpu/drm/i915/i915_driver.h > +++ b/drivers/gpu/drm/i915/i915_driver.h > @@ -15,7 +15,6 @@ struct drm_printer; > > #define DRIVER_NAME "i915" > #define DRIVER_DESC "Intel Graphics" > -#define DRIVER_DATE "20230929" > #define DRIVER_TIMESTAMP 1695980603 > > extern const struct dev_pm_ops i915_pm_ops; > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c > index 4eb58887819a..eb975b3815df 100644 > --- a/drivers/gpu/drm/i915/i915_gpu_error.c > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c > @@ -841,7 +841,6 @@ static void __err_print_to_sgl(struct drm_i915_error_state_buf *m, > err_printf(m, "Kernel: %s %s\n", > init_utsname()->release, > init_utsname()->machine); > - err_printf(m, "Driver: %s\n", DRIVER_DATE); > ts = ktime_to_timespec64(error->time); > err_printf(m, "Time: %lld s %ld us\n", > (s64)ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC); > diff --git a/drivers/gpu/drm/imagination/pvr_drv.c b/drivers/gpu/drm/imagination/pvr_drv.c > index 36c0e768698e..6ab023593476 100644 > --- a/drivers/gpu/drm/imagination/pvr_drv.c > +++ b/drivers/gpu/drm/imagination/pvr_drv.c > @@ -1387,7 +1387,6 @@ static struct drm_driver pvr_drm_driver = { > > .name = PVR_DRIVER_NAME, > .desc = PVR_DRIVER_DESC, > - .date = PVR_DRIVER_DATE, > .major = PVR_DRIVER_MAJOR, > .minor = PVR_DRIVER_MINOR, > .patchlevel = PVR_DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/imagination/pvr_drv.h b/drivers/gpu/drm/imagination/pvr_drv.h > index 378fe477b759..7fa147312dd1 100644 > --- a/drivers/gpu/drm/imagination/pvr_drv.h > +++ b/drivers/gpu/drm/imagination/pvr_drv.h > @@ -9,7 +9,6 @@ > > #define PVR_DRIVER_NAME "powervr" > #define PVR_DRIVER_DESC "Imagination PowerVR (Series 6 and later) & IMG Graphics" > -#define PVR_DRIVER_DATE "20230904" > > /* > * Driver interface version: > diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c b/drivers/gpu/drm/imx/dcss/dcss-kms.c > index 490b5c269f39..3633e8f3aff6 100644 > --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c > +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c > @@ -34,7 +34,6 @@ static const struct drm_driver dcss_kms_driver = { > .fops = &dcss_cma_fops, > .name = "imx-dcss", > .desc = "i.MX8MQ Display Subsystem", > - .date = "20190917", > .major = 1, > .minor = 0, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c > index 6b84429735d6..bcb35ba670fc 100644 > --- a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c > +++ b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c > @@ -163,7 +163,6 @@ static const struct drm_driver imx_drm_driver = { > .fops = &imx_drm_driver_fops, > .name = "imx-drm", > .desc = "i.MX DRM graphics", > - .date = "20120507", > .major = 1, > .minor = 0, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/imx/lcdc/imx-lcdc.c b/drivers/gpu/drm/imx/lcdc/imx-lcdc.c > index c5121fed80fd..d70981295f88 100644 > --- a/drivers/gpu/drm/imx/lcdc/imx-lcdc.c > +++ b/drivers/gpu/drm/imx/lcdc/imx-lcdc.c > @@ -352,7 +352,6 @@ static struct drm_driver imx_lcdc_drm_driver = { > DRM_FBDEV_DMA_DRIVER_OPS, > .name = "imx-lcdc", > .desc = "i.MX LCDC driver", > - .date = "20200716", > }; > > static const struct of_device_id imx_lcdc_of_dev_id[] = { > diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c > index 0a4eb3994cd6..6546d9ec410a 100644 > --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c > +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c > @@ -953,7 +953,6 @@ static const struct drm_driver ingenic_drm_driver_data = { > .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC, > .name = "ingenic-drm", > .desc = "DRM module for Ingenic SoCs", > - .date = "20200716", > .major = 1, > .minor = 1, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/kmb/kmb_drv.c b/drivers/gpu/drm/kmb/kmb_drv.c > index 4173344ba32c..c340b4c6a74b 100644 > --- a/drivers/gpu/drm/kmb/kmb_drv.c > +++ b/drivers/gpu/drm/kmb/kmb_drv.c > @@ -445,7 +445,6 @@ static const struct drm_driver kmb_driver = { > DRM_FBDEV_DMA_DRIVER_OPS, > .name = "kmb-drm", > .desc = "KEEMBAY DISPLAY DRIVER", > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > }; > diff --git a/drivers/gpu/drm/kmb/kmb_drv.h b/drivers/gpu/drm/kmb/kmb_drv.h > index bf085e95b28f..1f0c10d317fe 100644 > --- a/drivers/gpu/drm/kmb/kmb_drv.h > +++ b/drivers/gpu/drm/kmb/kmb_drv.h > @@ -16,7 +16,6 @@ > #define KMB_MIN_WIDTH 1920 /*Max width in pixels */ > #define KMB_MIN_HEIGHT 1080 /*Max height in pixels */ > > -#define DRIVER_DATE "20210223" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 1 > > diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c > index 10bce18b7c31..4b70c5189f7c 100644 > --- a/drivers/gpu/drm/lima/lima_drv.c > +++ b/drivers/gpu/drm/lima/lima_drv.c > @@ -271,7 +271,6 @@ static const struct drm_driver lima_drm_driver = { > .fops = &lima_drm_driver_fops, > .name = "lima", > .desc = "lima DRM", > - .date = "20191231", > .major = 1, > .minor = 1, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/logicvc/logicvc_drm.c b/drivers/gpu/drm/logicvc/logicvc_drm.c > index 9152034e54a3..bda2a689d928 100644 > --- a/drivers/gpu/drm/logicvc/logicvc_drm.c > +++ b/drivers/gpu/drm/logicvc/logicvc_drm.c > @@ -52,7 +52,6 @@ static struct drm_driver logicvc_drm_driver = { > .fops = &logicvc_drm_fops, > .name = "logicvc-drm", > .desc = "Xylon LogiCVC DRM driver", > - .date = "20200403", > .major = 1, > .minor = 0, > > diff --git a/drivers/gpu/drm/loongson/lsdc_drv.c b/drivers/gpu/drm/loongson/lsdc_drv.c > index a55aa1fe2c21..12193d2a301a 100644 > --- a/drivers/gpu/drm/loongson/lsdc_drv.c > +++ b/drivers/gpu/drm/loongson/lsdc_drv.c > @@ -26,7 +26,6 @@ > #define DRIVER_AUTHOR "Sui Jingfeng " > #define DRIVER_NAME "loongson" > #define DRIVER_DESC "drm driver for loongson graphics" > -#define DRIVER_DATE "20220701" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > #define DRIVER_PATCHLEVEL 0 > @@ -39,7 +38,6 @@ static const struct drm_driver lsdc_drm_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c > index f8c7aa9d7f33..324a95d7f15b 100644 > --- a/drivers/gpu/drm/mcde/mcde_drv.c > +++ b/drivers/gpu/drm/mcde/mcde_drv.c > @@ -208,7 +208,6 @@ static const struct drm_driver mcde_drm_driver = { > .fops = &drm_fops, > .name = "mcde", > .desc = DRIVER_DESC, > - .date = "20180529", > .major = 1, > .minor = 0, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > index 38297d705df6..723782e75c55 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > @@ -33,7 +33,6 @@ > > #define DRIVER_NAME "mediatek" > #define DRIVER_DESC "Mediatek SoC DRM" > -#define DRIVER_DATE "20150513" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -615,7 +614,6 @@ static const struct drm_driver mtk_drm_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > }; > diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c > index 83ee18024682..64c8c4bb60f1 100644 > --- a/drivers/gpu/drm/meson/meson_drv.c > +++ b/drivers/gpu/drm/meson/meson_drv.c > @@ -105,7 +105,6 @@ static const struct drm_driver meson_driver = { > .fops = &fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = "20161109", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c b/drivers/gpu/drm/mgag200/mgag200_drv.c > index b7ed763addfa..069fdd2dc8f6 100644 > --- a/drivers/gpu/drm/mgag200/mgag200_drv.c > +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c > @@ -97,7 +97,6 @@ static const struct drm_driver mgag200_driver = { > .fops = &mgag200_driver_fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h b/drivers/gpu/drm/mgag200/mgag200_drv.h > index 988967eafbf2..0608fc63e588 100644 > --- a/drivers/gpu/drm/mgag200/mgag200_drv.h > +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h > @@ -25,7 +25,6 @@ > > #define DRIVER_NAME "mgag200" > #define DRIVER_DESC "MGA G200 SE" > -#define DRIVER_DATE "20110418" > > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c > index b5fa715cbfb0..73e72aee6ec5 100644 > --- a/drivers/gpu/drm/msm/msm_drv.c > +++ b/drivers/gpu/drm/msm/msm_drv.c > @@ -910,7 +910,6 @@ static const struct drm_driver msm_driver = { > .fops = &fops, > .name = "msm", > .desc = "MSM Snapdragon DRM", > - .date = "20130625", > .major = MSM_VERSION_MAJOR, > .minor = MSM_VERSION_MINOR, > .patchlevel = MSM_VERSION_PATCHLEVEL, > diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c b/drivers/gpu/drm/mxsfb/lcdif_drv.c > index 81ec91cef66c..02fe6b89f3aa 100644 > --- a/drivers/gpu/drm/mxsfb/lcdif_drv.c > +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c > @@ -248,7 +248,6 @@ static const struct drm_driver lcdif_driver = { > .fops = &fops, > .name = "imx-lcdif", > .desc = "i.MX LCDIF Controller DRM", > - .date = "20220417", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c > index 1c27a97dce03..129cc3fb4448 100644 > --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c > +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c > @@ -336,7 +336,6 @@ static const struct drm_driver mxsfb_driver = { > .fops = &fops, > .name = "mxsfb-drm", > .desc = "MXSFB Controller DRM", > - .date = "20160824", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c > index a99c1d9855c9..744ae9d3305d 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_drm.c > +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c > @@ -1326,11 +1326,6 @@ driver_stub = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > -#ifdef GIT_REVISION > - .date = GIT_REVISION, > -#else > - .date = DRIVER_DATE, > -#endif > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h > index 685d6ca3d8aa..55abc510067b 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_drv.h > +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h > @@ -7,7 +7,6 @@ > > #define DRIVER_NAME "nouveau" > #define DRIVER_DESC "nVidia Riva/TNT/GeForce/Quadro/Tesla/Tegra K1+" > -#define DRIVER_DATE "20120801" > > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 4 > diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c > index 1796cd20a877..a80e0f375a0e 100644 > --- a/drivers/gpu/drm/omapdrm/omap_drv.c > +++ b/drivers/gpu/drm/omapdrm/omap_drv.c > @@ -28,7 +28,6 @@ > > #define DRIVER_NAME MODULE_NAME > #define DRIVER_DESC "OMAP DRM" > -#define DRIVER_DATE "20110917" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > #define DRIVER_PATCHLEVEL 0 > @@ -653,7 +652,6 @@ static const struct drm_driver omap_drm_driver = { > .fops = &omapdriver_fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c > index 04d615df5259..fbaef3afcd66 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_drv.c > +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c > @@ -636,7 +636,6 @@ static const struct drm_driver panfrost_drm_driver = { > .fops = &panfrost_drm_driver_fops, > .name = "panfrost", > .desc = "panfrost DRM", > - .date = "20180908", > .major = 1, > .minor = 3, > > diff --git a/drivers/gpu/drm/panthor/panthor_drv.c b/drivers/gpu/drm/panthor/panthor_drv.c > index ac7e53f6e3f0..ad46a40ed9e1 100644 > --- a/drivers/gpu/drm/panthor/panthor_drv.c > +++ b/drivers/gpu/drm/panthor/panthor_drv.c > @@ -1505,7 +1505,6 @@ static const struct drm_driver panthor_drm_driver = { > .fops = &panthor_drm_driver_fops, > .name = "panthor", > .desc = "Panthor DRM driver", > - .date = "20230801", > .major = 1, > .minor = 2, > > diff --git a/drivers/gpu/drm/pl111/pl111_drv.c b/drivers/gpu/drm/pl111/pl111_drv.c > index 4b96f48cf630..56ff6a3fb483 100644 > --- a/drivers/gpu/drm/pl111/pl111_drv.c > +++ b/drivers/gpu/drm/pl111/pl111_drv.c > @@ -220,7 +220,6 @@ static const struct drm_driver pl111_drm_driver = { > .fops = &drm_fops, > .name = "pl111", > .desc = DRIVER_DESC, > - .date = "20170317", > .major = 1, > .minor = 0, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c > index f15e9583b098..417061ae59eb 100644 > --- a/drivers/gpu/drm/qxl/qxl_drv.c > +++ b/drivers/gpu/drm/qxl/qxl_drv.c > @@ -300,7 +300,6 @@ static struct drm_driver qxl_driver = { > .num_ioctls = ARRAY_SIZE(qxl_ioctls), > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = 0, > .minor = 1, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h > index b5fc14c9525d..cc02b5f10ad9 100644 > --- a/drivers/gpu/drm/qxl/qxl_drv.h > +++ b/drivers/gpu/drm/qxl/qxl_drv.h > @@ -54,7 +54,6 @@ struct iosys_map; > > #define DRIVER_NAME "qxl" > #define DRIVER_DESC "RH QXL" > -#define DRIVER_DATE "20120117" > > #define DRIVER_MAJOR 0 > #define DRIVER_MINOR 1 > diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c > index 5ce7e91bedad..267f082bc430 100644 > --- a/drivers/gpu/drm/radeon/radeon_drv.c > +++ b/drivers/gpu/drm/radeon/radeon_drv.c > @@ -603,7 +603,6 @@ static const struct drm_driver kms_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = KMS_DRIVER_MAJOR, > .minor = KMS_DRIVER_MINOR, > .patchlevel = KMS_DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/radeon/radeon_drv.h b/drivers/gpu/drm/radeon/radeon_drv.h > index 02a65971d140..0f3dbffc492d 100644 > --- a/drivers/gpu/drm/radeon/radeon_drv.h > +++ b/drivers/gpu/drm/radeon/radeon_drv.h > @@ -43,7 +43,6 @@ > > #define DRIVER_NAME "radeon" > #define DRIVER_DESC "ATI Radeon" > -#define DRIVER_DATE "20080528" > > /* Interface history: > * > diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c > index 0f5204ef996e..be39b107b98c 100644 > --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c > +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c > @@ -611,7 +611,6 @@ static const struct drm_driver rcar_du_driver = { > .fops = &rcar_du_fops, > .name = "rcar-du", > .desc = "Renesas R-Car Display Unit", > - .date = "20130110", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c > index 0a03a20f663b..9bbdc4d63d88 100644 > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c > @@ -84,7 +84,6 @@ static const struct drm_driver rzg2l_du_driver = { > .fops = &rzg2l_du_fops, > .name = "rzg2l-du", > .desc = "Renesas RZ/G2L Display Unit", > - .date = "20230410", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c b/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c > index 40b582ee178e..387eb602dadf 100644 > --- a/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c > +++ b/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c > @@ -107,7 +107,6 @@ static const struct drm_driver shmob_drm_driver = { > .fops = &shmob_drm_fops, > .name = "shmob-drm", > .desc = "Renesas SH Mobile DRM", > - .date = "20120424", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > index 0393b48ad65b..1fe4399d6901 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > @@ -39,7 +39,6 @@ > > #define DRIVER_NAME "rockchip" > #define DRIVER_DESC "RockChip Soc DRM" > -#define DRIVER_DATE "20140818" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -235,7 +234,6 @@ static const struct drm_driver rockchip_drm_driver = { > .fops = &rockchip_drm_driver_fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > }; > diff --git a/drivers/gpu/drm/solomon/ssd130x.c b/drivers/gpu/drm/solomon/ssd130x.c > index a737f650c2bc..7b9f8fc193ac 100644 > --- a/drivers/gpu/drm/solomon/ssd130x.c > +++ b/drivers/gpu/drm/solomon/ssd130x.c > @@ -39,7 +39,6 @@ > > #define DRIVER_NAME "ssd130x" > #define DRIVER_DESC "DRM driver for Solomon SSD13xx OLED displays" > -#define DRIVER_DATE "20220131" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -1784,7 +1783,6 @@ static const struct drm_driver ssd130x_drm_driver = { > DRM_FBDEV_SHMEM_DRIVER_OPS, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .driver_features = DRIVER_ATOMIC | DRIVER_GEM | DRIVER_MODESET, > diff --git a/drivers/gpu/drm/sprd/sprd_drm.c b/drivers/gpu/drm/sprd/sprd_drm.c > index a74cd0caf645..867ee2d8997f 100644 > --- a/drivers/gpu/drm/sprd/sprd_drm.c > +++ b/drivers/gpu/drm/sprd/sprd_drm.c > @@ -23,7 +23,6 @@ > > #define DRIVER_NAME "sprd" > #define DRIVER_DESC "Spreadtrum SoCs' DRM Driver" > -#define DRIVER_DATE "20200201" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -59,7 +58,6 @@ static struct drm_driver sprd_drm_drv = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > }; > diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c > index a6c13318aa0b..46e6b674fa54 100644 > --- a/drivers/gpu/drm/sti/sti_drv.c > +++ b/drivers/gpu/drm/sti/sti_drv.c > @@ -29,7 +29,6 @@ > > #define DRIVER_NAME "sti" > #define DRIVER_DESC "STMicroelectronics SoC DRM" > -#define DRIVER_DATE "20140601" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -143,7 +142,6 @@ static const struct drm_driver sti_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > }; > diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c > index d181d11b277b..40a62c57e04c 100644 > --- a/drivers/gpu/drm/stm/drv.c > +++ b/drivers/gpu/drm/stm/drv.c > @@ -62,7 +62,6 @@ static const struct drm_driver drv_driver = { > .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC, > .name = "stm", > .desc = "STMicroelectronics SoC DRM", > - .date = "20170330", > .major = 1, > .minor = 0, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c > index a7c11b795e98..025b0bdcbfd9 100644 > --- a/drivers/gpu/drm/sun4i/sun4i_drv.c > +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c > @@ -50,7 +50,6 @@ static const struct drm_driver sun4i_drv_driver = { > .fops = &sun4i_drv_fops, > .name = "sun4i-drm", > .desc = "Allwinner sun4i Display Engine", > - .date = "20150629", > .major = 1, > .minor = 0, > > diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c > index 34878f5d2918..4596073fe28f 100644 > --- a/drivers/gpu/drm/tegra/drm.c > +++ b/drivers/gpu/drm/tegra/drm.c > @@ -35,7 +35,6 @@ > > #define DRIVER_NAME "tegra" > #define DRIVER_DESC "NVIDIA Tegra graphics" > -#define DRIVER_DATE "20120330" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > #define DRIVER_PATCHLEVEL 0 > @@ -901,7 +900,6 @@ static const struct drm_driver tegra_drm_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/tidss/tidss_drv.c b/drivers/gpu/drm/tidss/tidss_drv.c > index 53bc219c097f..ee1132d581f5 100644 > --- a/drivers/gpu/drm/tidss/tidss_drv.c > +++ b/drivers/gpu/drm/tidss/tidss_drv.c > @@ -113,7 +113,6 @@ static const struct drm_driver tidss_driver = { > DRM_FBDEV_DMA_DRIVER_OPS, > .name = "tidss", > .desc = "TI Keystone DSS", > - .date = "20180215", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c > index 821d0ba26287..8013f01dbdf0 100644 > --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c > +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c > @@ -481,7 +481,6 @@ static const struct drm_driver tilcdc_driver = { > .fops = &fops, > .name = "tilcdc", > .desc = "TI LCD Controller DRM", > - .date = "20121205", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/drivers/gpu/drm/tiny/arcpgu.c > index 5a0c8a874421..1e570f6f639f 100644 > --- a/drivers/gpu/drm/tiny/arcpgu.c > +++ b/drivers/gpu/drm/tiny/arcpgu.c > @@ -367,7 +367,6 @@ static const struct drm_driver arcpgu_drm_driver = { > .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC, > .name = "arcpgu", > .desc = "ARC PGU Controller", > - .date = "20160219", > .major = 1, > .minor = 0, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c > index 71a1f15d6ac9..89a699370a59 100644 > --- a/drivers/gpu/drm/tiny/bochs.c > +++ b/drivers/gpu/drm/tiny/bochs.c > @@ -680,7 +680,6 @@ static const struct drm_driver bochs_driver = { > .fops = &bochs_fops, > .name = "bochs-drm", > .desc = "bochs dispi vga interface (qemu stdvga)", > - .date = "20130925", > .major = 1, > .minor = 0, > DRM_GEM_SHMEM_DRIVER_OPS, > diff --git a/drivers/gpu/drm/tiny/cirrus-qemu.c b/drivers/gpu/drm/tiny/cirrus-qemu.c > index c0ae316888e2..52ec1e4ea9e5 100644 > --- a/drivers/gpu/drm/tiny/cirrus-qemu.c > +++ b/drivers/gpu/drm/tiny/cirrus-qemu.c > @@ -48,7 +48,6 @@ > > #define DRIVER_NAME "cirrus-qemu" > #define DRIVER_DESC "qemu cirrus vga" > -#define DRIVER_DATE "2019" > #define DRIVER_MAJOR 2 > #define DRIVER_MINOR 0 > > @@ -659,7 +658,6 @@ static const struct drm_driver cirrus_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > > diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c > index 47dbee84d58b..41e9bfb2e2ff 100644 > --- a/drivers/gpu/drm/tiny/gm12u320.c > +++ b/drivers/gpu/drm/tiny/gm12u320.c > @@ -34,7 +34,6 @@ MODULE_PARM_DESC(eco_mode, "Turn on Eco mode (less bright, more silent)"); > > #define DRIVER_NAME "gm12u320" > #define DRIVER_DESC "Grain Media GM12U320 USB projector display" > -#define DRIVER_DATE "2019" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -626,7 +625,6 @@ static const struct drm_driver gm12u320_drm_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > > diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c > index 910279ebbbaa..df263818f45f 100644 > --- a/drivers/gpu/drm/tiny/hx8357d.c > +++ b/drivers/gpu/drm/tiny/hx8357d.c > @@ -199,7 +199,6 @@ static const struct drm_driver hx8357d_driver = { > .debugfs_init = mipi_dbi_debugfs_init, > .name = "hx8357d", > .desc = "HX8357D", > - .date = "20181023", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/ili9163.c b/drivers/gpu/drm/tiny/ili9163.c > index e54ce120692f..62cadf5e033d 100644 > --- a/drivers/gpu/drm/tiny/ili9163.c > +++ b/drivers/gpu/drm/tiny/ili9163.c > @@ -118,7 +118,6 @@ static struct drm_driver ili9163_driver = { > .debugfs_init = mipi_dbi_debugfs_init, > .name = "ili9163", > .desc = "Ilitek ILI9163", > - .date = "20210208", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c > index f322e67f473a..6de44ff69b51 100644 > --- a/drivers/gpu/drm/tiny/ili9225.c > +++ b/drivers/gpu/drm/tiny/ili9225.c > @@ -364,7 +364,6 @@ static const struct drm_driver ili9225_driver = { > DRM_FBDEV_DMA_DRIVER_OPS, > .name = "ili9225", > .desc = "Ilitek ILI9225", > - .date = "20171106", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/ili9341.c b/drivers/gpu/drm/tiny/ili9341.c > index 356c7f107c3e..e55029433509 100644 > --- a/drivers/gpu/drm/tiny/ili9341.c > +++ b/drivers/gpu/drm/tiny/ili9341.c > @@ -155,7 +155,6 @@ static const struct drm_driver ili9341_driver = { > .debugfs_init = mipi_dbi_debugfs_init, > .name = "ili9341", > .desc = "Ilitek ILI9341", > - .date = "20180514", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c > index f5b1d21f7109..093661c771a0 100644 > --- a/drivers/gpu/drm/tiny/ili9486.c > +++ b/drivers/gpu/drm/tiny/ili9486.c > @@ -177,7 +177,6 @@ static const struct drm_driver ili9486_driver = { > .debugfs_init = mipi_dbi_debugfs_init, > .name = "ili9486", > .desc = "Ilitek ILI9486", > - .date = "20200118", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/mi0283qt.c b/drivers/gpu/drm/tiny/mi0283qt.c > index 61e33376fbc9..b6b4664908ae 100644 > --- a/drivers/gpu/drm/tiny/mi0283qt.c > +++ b/drivers/gpu/drm/tiny/mi0283qt.c > @@ -159,7 +159,6 @@ static const struct drm_driver mi0283qt_driver = { > .debugfs_init = mipi_dbi_debugfs_init, > .name = "mi0283qt", > .desc = "Multi-Inno MI0283QT", > - .date = "20160614", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/ofdrm.c b/drivers/gpu/drm/tiny/ofdrm.c > index b27ed3677bfd..cd5916752507 100644 > --- a/drivers/gpu/drm/tiny/ofdrm.c > +++ b/drivers/gpu/drm/tiny/ofdrm.c > @@ -25,7 +25,6 @@ > > #define DRIVER_NAME "ofdrm" > #define DRIVER_DESC "DRM driver for OF platform devices" > -#define DRIVER_DATE "20220501" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -1348,7 +1347,6 @@ static struct drm_driver ofdrm_driver = { > DRM_FBDEV_SHMEM_DRIVER_OPS, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .driver_features = DRIVER_ATOMIC | DRIVER_GEM | DRIVER_MODESET, > diff --git a/drivers/gpu/drm/tiny/panel-mipi-dbi.c b/drivers/gpu/drm/tiny/panel-mipi-dbi.c > index 79d5818cbbe6..4786b8144a9f 100644 > --- a/drivers/gpu/drm/tiny/panel-mipi-dbi.c > +++ b/drivers/gpu/drm/tiny/panel-mipi-dbi.c > @@ -269,7 +269,6 @@ static const struct drm_driver panel_mipi_dbi_driver = { > .debugfs_init = mipi_dbi_debugfs_init, > .name = "panel-mipi-dbi", > .desc = "MIPI DBI compatible display panel", > - .date = "20220103", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gpu/drm/tiny/repaper.c > index 9373063a13fc..52ba6c699bc8 100644 > --- a/drivers/gpu/drm/tiny/repaper.c > +++ b/drivers/gpu/drm/tiny/repaper.c > @@ -917,7 +917,6 @@ static const struct drm_driver repaper_driver = { > DRM_FBDEV_DMA_DRIVER_OPS, > .name = "repaper", > .desc = "Pervasive Displays RePaper e-ink panels", > - .date = "20170405", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/sharp-memory.c b/drivers/gpu/drm/tiny/sharp-memory.c > index d87068126f9b..03d2850310c4 100644 > --- a/drivers/gpu/drm/tiny/sharp-memory.c > +++ b/drivers/gpu/drm/tiny/sharp-memory.c > @@ -107,7 +107,6 @@ static const struct drm_driver sharp_memory_drm_driver = { > DRM_FBDEV_DMA_DRIVER_OPS, > .name = "sharp_memory_display", > .desc = "Sharp Display Memory LCD", > - .date = "20231129", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c > index b3a2fc11dcf0..b47ca2d902d9 100644 > --- a/drivers/gpu/drm/tiny/simpledrm.c > +++ b/drivers/gpu/drm/tiny/simpledrm.c > @@ -31,7 +31,6 @@ > > #define DRIVER_NAME "simpledrm" > #define DRIVER_DESC "DRM driver for simple-framebuffer platform devices" > -#define DRIVER_DATE "20200625" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -1015,7 +1014,6 @@ static struct drm_driver simpledrm_driver = { > DRM_FBDEV_SHMEM_DRIVER_OPS, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .driver_features = DRIVER_ATOMIC | DRIVER_GEM | DRIVER_MODESET, > diff --git a/drivers/gpu/drm/tiny/st7586.c b/drivers/gpu/drm/tiny/st7586.c > index 7bfd4296c1c9..a29672d84ede 100644 > --- a/drivers/gpu/drm/tiny/st7586.c > +++ b/drivers/gpu/drm/tiny/st7586.c > @@ -295,7 +295,6 @@ static const struct drm_driver st7586_driver = { > .debugfs_init = mipi_dbi_debugfs_init, > .name = "st7586", > .desc = "Sitronix ST7586", > - .date = "20170801", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tiny/st7735r.c b/drivers/gpu/drm/tiny/st7735r.c > index 6832ca590127..1d60f6e5b3bc 100644 > --- a/drivers/gpu/drm/tiny/st7735r.c > +++ b/drivers/gpu/drm/tiny/st7735r.c > @@ -160,7 +160,6 @@ static const struct drm_driver st7735r_driver = { > .debugfs_init = mipi_dbi_debugfs_init, > .name = "st7735r", > .desc = "Sitronix ST7735R", > - .date = "20171128", > .major = 1, > .minor = 0, > }; > diff --git a/drivers/gpu/drm/tve200/tve200_drv.c b/drivers/gpu/drm/tve200/tve200_drv.c > index cb66dbbe2801..65a0d4301160 100644 > --- a/drivers/gpu/drm/tve200/tve200_drv.c > +++ b/drivers/gpu/drm/tve200/tve200_drv.c > @@ -146,7 +146,6 @@ static const struct drm_driver tve200_drm_driver = { > .fops = &drm_fops, > .name = "tve200", > .desc = DRIVER_DESC, > - .date = "20170703", > .major = 1, > .minor = 0, > .patchlevel = 0, > diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c > index 6c182b21028e..05b3a152cc33 100644 > --- a/drivers/gpu/drm/udl/udl_drv.c > +++ b/drivers/gpu/drm/udl/udl_drv.c > @@ -78,7 +78,6 @@ static const struct drm_driver driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h > index 1eb716d9dad5..be00dc1d87a1 100644 > --- a/drivers/gpu/drm/udl/udl_drv.h > +++ b/drivers/gpu/drm/udl/udl_drv.h > @@ -26,7 +26,6 @@ struct drm_mode_create_dumb; > > #define DRIVER_NAME "udl" > #define DRIVER_DESC "DisplayLink" > -#define DRIVER_DATE "20120220" > > #define DRIVER_MAJOR 0 > #define DRIVER_MINOR 0 > diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c > index fb35c5c3f1a7..9d8de9146cb0 100644 > --- a/drivers/gpu/drm/v3d/v3d_drv.c > +++ b/drivers/gpu/drm/v3d/v3d_drv.c > @@ -31,7 +31,6 @@ > > #define DRIVER_NAME "v3d" > #define DRIVER_DESC "Broadcom V3D graphics" > -#define DRIVER_DATE "20180419" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > #define DRIVER_PATCHLEVEL 0 > @@ -248,7 +247,6 @@ static const struct drm_driver v3d_drm_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c b/drivers/gpu/drm/vboxvideo/vbox_drv.c > index d9d884aad97f..bb861f0a0a31 100644 > --- a/drivers/gpu/drm/vboxvideo/vbox_drv.c > +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c > @@ -189,7 +189,6 @@ static const struct drm_driver driver = { > .fops = &vbox_fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h b/drivers/gpu/drm/vboxvideo/vbox_drv.h > index e77bd6512eb1..dfa935f381a6 100644 > --- a/drivers/gpu/drm/vboxvideo/vbox_drv.h > +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h > @@ -25,7 +25,6 @@ > > #define DRIVER_NAME "vboxvideo" > #define DRIVER_DESC "Oracle VM VirtualBox Graphics Card" > -#define DRIVER_DATE "20130823" > > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c > index ee5df153c2a6..e88a7ee486c6 100644 > --- a/drivers/gpu/drm/vc4/vc4_drv.c > +++ b/drivers/gpu/drm/vc4/vc4_drv.c > @@ -47,7 +47,6 @@ > > #define DRIVER_NAME "vc4" > #define DRIVER_DESC "Broadcom VC4 graphics" > -#define DRIVER_DATE "20140616" > #define DRIVER_MAJOR 0 > #define DRIVER_MINOR 0 > #define DRIVER_PATCHLEVEL 0 > @@ -222,7 +221,6 @@ const struct drm_driver vc4_drm_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > @@ -244,7 +242,6 @@ const struct drm_driver vc5_drm_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c > index c5e3e5457737..2752ab4f1c97 100644 > --- a/drivers/gpu/drm/vgem/vgem_drv.c > +++ b/drivers/gpu/drm/vgem/vgem_drv.c > @@ -47,7 +47,6 @@ > > #define DRIVER_NAME "vgem" > #define DRIVER_DESC "Virtual GEM provider" > -#define DRIVER_DATE "20120112" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -121,7 +120,6 @@ static const struct drm_driver vgem_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > }; > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c > index e216123ce6a5..6a67c6297d58 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_drv.c > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c > @@ -201,7 +201,6 @@ static const struct drm_driver driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h > index 8328107edf78..f42ca9d8ed10 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h > @@ -45,7 +45,6 @@ > > #define DRIVER_NAME "virtio_gpu" > #define DRIVER_DESC "virtio GPU" > -#define DRIVER_DATE "0" > > #define DRIVER_MAJOR 0 > #define DRIVER_MINOR 1 > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c > index fa3331f612e3..e0409aba9349 100644 > --- a/drivers/gpu/drm/vkms/vkms_drv.c > +++ b/drivers/gpu/drm/vkms/vkms_drv.c > @@ -34,7 +34,6 @@ > > #define DRIVER_NAME "vkms" > #define DRIVER_DESC "Virtual Kernel Mode Setting" > -#define DRIVER_DATE "20180514" > #define DRIVER_MAJOR 1 > #define DRIVER_MINOR 0 > > @@ -116,7 +115,6 @@ static const struct drm_driver vkms_driver = { > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > }; > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > index ded48554568a..1699236fca5a 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > @@ -1634,7 +1634,6 @@ static const struct drm_driver driver = { > .fops = &vmwgfx_driver_fops, > .name = VMWGFX_DRIVER_NAME, > .desc = VMWGFX_DRIVER_DESC, > - .date = VMWGFX_DRIVER_DATE, > .major = VMWGFX_DRIVER_MAJOR, > .minor = VMWGFX_DRIVER_MINOR, > .patchlevel = VMWGFX_DRIVER_PATCHLEVEL > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h > index b21831ef214a..5275ef632d4b 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h > @@ -57,7 +57,6 @@ > > > #define VMWGFX_DRIVER_NAME "vmwgfx" > -#define VMWGFX_DRIVER_DATE "20211206" > #define VMWGFX_DRIVER_MAJOR 2 > #define VMWGFX_DRIVER_MINOR 20 > #define VMWGFX_DRIVER_PATCHLEVEL 0 > diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c > index d6fccea1e083..56d4ffb650da 100644 > --- a/drivers/gpu/drm/xe/xe_device.c > +++ b/drivers/gpu/drm/xe/xe_device.c > @@ -271,7 +271,6 @@ static struct drm_driver driver = { > .fops = &xe_driver_fops, > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > - .date = DRIVER_DATE, > .major = DRIVER_MAJOR, > .minor = DRIVER_MINOR, > .patchlevel = DRIVER_PATCHLEVEL, > diff --git a/drivers/gpu/drm/xe/xe_drv.h b/drivers/gpu/drm/xe/xe_drv.h > index d45b71426cc8..d61650d4aa0b 100644 > --- a/drivers/gpu/drm/xe/xe_drv.h > +++ b/drivers/gpu/drm/xe/xe_drv.h > @@ -10,7 +10,6 @@ > > #define DRIVER_NAME "xe" > #define DRIVER_DESC "Intel Xe Graphics" > -#define DRIVER_DATE "20201103" > > /* Interface history: > * > diff --git a/drivers/gpu/drm/xen/xen_drm_front.c b/drivers/gpu/drm/xen/xen_drm_front.c > index 931d855bfbe8..1bda7ef606cc 100644 > --- a/drivers/gpu/drm/xen/xen_drm_front.c > +++ b/drivers/gpu/drm/xen/xen_drm_front.c > @@ -478,7 +478,6 @@ static const struct drm_driver xen_drm_driver = { > .fops = &xen_drm_dev_fops, > .name = "xendrm-du", > .desc = "Xen PV DRM Display Unit", > - .date = "20180221", > .major = 1, > .minor = 0, > > diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c > index e272ecbce78d..b47463473472 100644 > --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c > +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c > @@ -409,7 +409,6 @@ static const struct drm_driver zynqmp_dpsub_drm_driver = { > > .name = "zynqmp-dpsub", > .desc = "Xilinx DisplayPort Subsystem Driver", > - .date = "20130509", > .major = 1, > .minor = 0, > }; > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h > index 1bbbcb8e2d23..1b6e59139e6c 100644 > --- a/include/drm/drm_drv.h > +++ b/include/drm/drm_drv.h > @@ -401,8 +401,6 @@ struct drm_driver { > char *name; > /** @desc: driver description */ > char *desc; > - /** @date: driver date, unused, to be removed */ > - char *date; > > /** > * @driver_features: > -- > 2.39.5 > From xen-devel-bounces@lists.xenproject.org Mon Dec 09 16:18:25 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 16:18:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851644.1265682 (Exim 4.92) (envelope-from ) id 1tKgSn-0002OR-3E; Mon, 09 Dec 2024 16:18:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851644.1265682; Mon, 09 Dec 2024 16: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 1tKgSn-0002OK-0Q; Mon, 09 Dec 2024 16:18:25 +0000 Received: by outflank-mailman (input) for mailman id 851644; Mon, 09 Dec 2024 16:18: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 1tKgSl-0001HC-A2 for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 16:18:23 +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 360b4c47-b649-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 17:18:22 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-385df53e559so3264109f8f.3 for ; Mon, 09 Dec 2024 08:18: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 d9443c01a7336-215f8e3ec6esm74417055ad.52.2024.12.09.08.18.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 08: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: 360b4c47-b649-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733761102; x=1734365902; 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=iQfmwdVgORMql7gpEwdLm0EaXOmhgf8vsnXgXGLuUjk=; b=KNAGFRADOrUD83ssOCvAUeMJ2X/J87kBMapqmk3d1RBLOLMxRavEkjIgA9uJhZ9MlM LqWstiNOBc5Ru2ObEtDRqX2k88ROpWx+cEN+IL4xwTMLVesiu/m2XKWaybVTP7to2cDU a5/PN0ljdWev6/CF2QEQG0scbs7XhQF4rulcJKtoF9MABJDjOINfh+aBuKpny8RAM2DL wQEhEJlO7rovNlE7sNp0Qzt53QkrXsSLp5PM6pw9UsvpH+guLqUJlLiif0ypzDbJhcoT xtrB7joOMS5gf1Q5f4SWtSY9i2N4Zn29c7jY6VGDdxuiyC+szwa35CX4obEZM5hxCF6M N2nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733761102; x=1734365902; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=iQfmwdVgORMql7gpEwdLm0EaXOmhgf8vsnXgXGLuUjk=; b=taWaeHUjMxuguqY+J1l0ZAN88Op2b2FmsgCTKx61B9fcU7nYR8y32wXUM9sRUEeEsr Lr0dOO4PLz+4blZibZgIRqWHR6kgw5xzMZ9dQxk+suVrCgUgTSZU0E94sX79mELf+7PJ 4oT4HXx5XI+jj+arEGYmdPO+QSGmEDqxIIpjtGOdEMEIO9U6T/63Crwr8+8XZZRjxN7a RqrQeCaJF/15s6KdSU5svejlxexExyhVfjMPWmH0bQei+S9+pHiB2Ycp07dHFLU3N8eM GW13Dyv3Jx7XwR0gBJo8LmDyE7BMlX5FWtPQVH0caL81JHV3GFvweB6XzdQORebdv4x8 rRAg== X-Forwarded-Encrypted: i=1; AJvYcCXuu4LVCUCtltvBi4YjsAzRQdIvgI/B/gl2rImaXGHYpv6mPwRGdzT5239BUQuAmY7K3/EEkcmBGnI=@lists.xenproject.org X-Gm-Message-State: AOJu0YxWkLNO0hXnUqMxWc28u1wwZ7bzC3UdmNOcRjT3SchMGfLFsfxq Wi7hg617PkK9y/ZfdGUn+75HPLfWMFarfc3aDxQEvGs3ncISMYsPWSZXi4X4i47XConnkvhgAXE = X-Gm-Gg: ASbGncsjE/Ia+jv6K/nxOmzrw+tdKu8bVq9uPYmiWDcQsGHz3AxS2kCZuh8fyoJ8rcS 7GijVVOHaH6XRpSGZrStGWNslyW4XHGnlKT5aqE+8rE4ZZsfLMQ8L00NVprBnkRsLfVJxYI47mS b88NeX9eg4grZxXHEQxmMwQZfvV9TqXHf+v8tK9QUrIFL3YMtzMNIZpzKbESR2bXYoGjH0bxQKH 7Od352xuAN69swGOHE0LNYKU9Phv6xfI7+iWraJ3Mb1uQKzbudYLu65jSpQmTJcJVGvePI0vyB2 mEXm4qSZ7FhbVoHXFJIxDAd/1+Mctp1MzXo= X-Google-Smtp-Source: AGHT+IGZlFvYdJ887lT8i65rNOzK9G9KUWUwQwRsQPQdB7BhQmB4iP5I9XiUiJ/xIDuT/8ajMmRCdQ== X-Received: by 2002:a05:6000:79e:b0:385:e9c0:c069 with SMTP id ffacd0b85a97d-3862b3d0941mr10259087f8f.57.1733761102342; Mon, 09 Dec 2024 08:18:22 -0800 (PST) Message-ID: <55c537f5-0fca-4524-b786-b3c5eac6ce92@suse.com> Date: Mon, 9 Dec 2024 17:18:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 06/13] x86/hvm: Map/unmap xsave area in hvmemul_{get,put}_fpu() To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241105143310.28301-1-alejandro.vallejo@cloud.com> <20241105143310.28301-7-alejandro.vallejo@cloud.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: <20241105143310.28301-7-alejandro.vallejo@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.11.2024 15:33, Alejandro Vallejo wrote: > No functional change. > > Signed-off-by: Alejandro Vallejo Again with comment style adjusted: Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 16:19:20 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 16:19:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851652.1265693 (Exim 4.92) (envelope-from ) id 1tKgTf-0002ym-BT; Mon, 09 Dec 2024 16:19:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851652.1265693; Mon, 09 Dec 2024 16:19:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKgTf-0002yf-8h; Mon, 09 Dec 2024 16:19:19 +0000 Received: by outflank-mailman (input) for mailman id 851652; Mon, 09 Dec 2024 16:19: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 1tKgTe-0001zq-Cm for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 16:19:18 +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 5633689a-b649-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 17:19:16 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-3862f32a33eso1298219f8f.3 for ; Mon, 09 Dec 2024 08: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 d9443c01a7336-2166fc21dd6sm99795ad.123.2024.12.09.08.19.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 08: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: 5633689a-b649-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733761156; x=1734365956; 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=4KNYZ7a2I2dbgKZ1H8TKiU7KiDZpr7dlCDtIM0BRtjQ=; b=Bu3EIIQA4M7h5mkTTI0Mnow4dRg5mdsb7nbFAf37RqshyYflt/s62qx5RPOu5D69YK gdA2EH7stBCUcBKBfIooaHl7URrDTt1wtHI7m7dn1AaKInW8S9zy8Z+4xWDs+uDjf0tB gvq0CmcC0Ylu2XgSdod2ET+vOcS3ACZWDDSPgXMVLRKtukvP2AEEPBdmHd7jLfWoApdk OBYrAgsRAHbP895kyUbdSNzyd1QiFydn9EiZe6T9EusKRumIp08efwNDsbXrdccnCyRw AdhBenhmBCeiR6839goqXPGSpxL8Zi1VEcLGp99coXpoG1PzKX0etZl9252Hkoo4iFbP X6Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733761156; x=1734365956; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4KNYZ7a2I2dbgKZ1H8TKiU7KiDZpr7dlCDtIM0BRtjQ=; b=HH01aHdm3zbmOBs6vpGmKbkZ2NWqny9MeGn9VfrKUN+4piXRfA5b8H5aThC4ZXlmgx xmYRKUtVVsV7Rw3bMHvkLPAOymSiylpRj7C+8XD4yH862/J0behrBdYjOTMte/mqmMSo YWLTzFQaDUPbctPeMDBEBbVQjscT5bla55Lf8k/Py93AK3kFUGwRqtiEF/U7Y239d/Gn mQyhkn/PhmicuiChp1SaI2DfJik0ps4SyhuZiINisUkFEjSymm4x+9MrinTkzBhaneGa ahwz4l0saFcO1Ok2eJsnJ7e1hMlbC8XlHb39SQEHsdyky1pktMbvwbFAbKnaoSh0tNOa Q/Rw== X-Forwarded-Encrypted: i=1; AJvYcCXxv8mOnjBx1NVdikVsmCR1t834Pxrd0UIAYftVBFw+SfFLnaHegxoE19T3o8kN0RIkEpL/2kP6UTw=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy4PurD0vUu2Ae7miwbp1aIyGgpxdSCPSiSZPXNljj/7dHt7Agx AKDvOwcwh1HipkioMf8H2+S1H88VchiNGb5v5+BOWxCjlZHqHYd/BSHOSy/ysw== X-Gm-Gg: ASbGnctrck5KpP5JyVEslYwXX37cpIL/H6kFLjVt8HkqqQFg8imj0EmvGR5/QFQ/jvj IEpuDKd8kpZGN00jpSIGTwnLP/vaKuDEEo8EnalQWnjvmOMLfldG6RNLJThVHrg+pylfTLKneWI xNN/w6JXm4elS6Il8aN7H5Hckw0yfb9zCyKVZQCbV0styLXQp2dBWy8IenFmb9Zhru+HX9I+7gW 9oocK3n3HJR6mv9oqLxWP7PvgNqYv+tpt0eF/Y8qgVQEZlxMN/QQ3Md43roIZqiVFu2/PpSBTbn bZgWN3iYcvjODa/SowMxv6T/9C/bxGXaeZE= X-Google-Smtp-Source: AGHT+IGHMC4PKrvmzierTpddzeWgX52jejqoxBwCbjTRX+3W4XaBPR77wH+bO106j33S39p0Cc4pHA== X-Received: by 2002:a5d:59ab:0:b0:386:3f3e:ab11 with SMTP id ffacd0b85a97d-386453eaaffmr916333f8f.34.1733761156304; Mon, 09 Dec 2024 08:19:16 -0800 (PST) Message-ID: Date: Mon, 9 Dec 2024 17:19:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 07/13] x86/domctl: Map/unmap xsave area in arch_get_info_guest() To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241105143310.28301-1-alejandro.vallejo@cloud.com> <20241105143310.28301-8-alejandro.vallejo@cloud.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: <20241105143310.28301-8-alejandro.vallejo@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.11.2024 15:33, Alejandro Vallejo wrote: > No functional change. > > Signed-off-by: Alejandro Vallejo Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Dec 09 16:21:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 16:21:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851661.1265703 (Exim 4.92) (envelope-from ) id 1tKgVQ-0004hx-Nh; Mon, 09 Dec 2024 16:21:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851661.1265703; Mon, 09 Dec 2024 16:21: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 1tKgVQ-0004hq-Ky; Mon, 09 Dec 2024 16:21:08 +0000 Received: by outflank-mailman (input) for mailman id 851661; Mon, 09 Dec 2024 16: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 1tKgVP-0004gL-8D for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 16:21:07 +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 9768ef09-b649-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 17:21:06 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-3862d161947so2252314f8f.3 for ; Mon, 09 Dec 2024 08:21:06 -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 d2e1a72fcca58-725d36e66e1sm4243570b3a.178.2024.12.09.08.21.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 08:21:05 -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: 9768ef09-b649-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733761266; x=1734366066; 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=pV39+Nn0PrJDNwThF+d37xy4owZWnGgFZSc46IgfvXk=; b=AYb+wYl7SGdh3ZXyZvl+J35Yu6yN20ch+0NGhvc7zdAqHBoIULDqO2CM7v1/Bggw4i Ps9RkziQWltwyoMrqOBdcSYC+dpFajP3oxlY+n0g6bin5Pvb5fv622TEhZlggFgBKmiA GWdDNSDe25HmhF82mrkA0mhLKRcTfXpoFU77PcIoGNU4xaBaa91BmIOBRQtNLECuVAYZ hWD3W/yGPc+USU7aYZN6c3KGEt2/ocJ2zaKJjzYZH1qVy3ZmyhmXZov3hqafhtOxTbFV naiGD+6pngb4zB0021CXG779iCpKD1M4THFr1ka4XbUQvHzpivBLf/u12SfFfbiI7cP1 WhMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733761266; x=1734366066; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pV39+Nn0PrJDNwThF+d37xy4owZWnGgFZSc46IgfvXk=; b=idP8wvsBwV1t+dF6PhFS2aKMoYYUKEtjSP2Pikr5Rx6EW7Kn1453bnSDCpwfRHjpMl uxBW8GJR1rBAl8tlmTlhhLtpxSdVqqI8YYw7gc3totBHosUlZp8vuIVK3rUmoUOolWwu 1+x9c/D12+blWrJY+KaUFeSuqTB7ukSSVBxnWXZW5MTUKnkgFvGl4Kg7WzBYWhQcZ6kR 3WwoN04luL0c0p1vmFFYMmUn8VFepGNpKf60yIpgYPzEalW0B4mYRm/IT/NVRur+3yLJ cdfmx5OxkYiRq8Fo3EpMjhVDwcm6cNZqFK753yKOK4SATPAGxSdGh5qXe9a1kwwj8COB hWvQ== X-Forwarded-Encrypted: i=1; AJvYcCV/xDNelviCmGCUDAqfLop88UrWN2hHJiHT0l1vntZx6EmuXW0EHMZMAAFuosZpxbtKRSndHWefT/o=@lists.xenproject.org X-Gm-Message-State: AOJu0YzZkkdgNVv+yulDH7McjWGVxoCbAsH6tF0wObGH/HyREo/03MYn jgWsv1KHjG/cYaSh/RypHaM7Rey65Hni9gL0afX6r0KD4XKdxnbXVN/G8hItmQ== X-Gm-Gg: ASbGncv9y1a/yJQEQNT7bi6pDBTLr+VF1LvEceDGzUW0JZBXkhCbbyYELbfM9Ri5TJL PjnFWYc1KNzrTOl7I4ZCalItvf87LEh/16jDnqB2nDTf3+l7ocD/1HbQYYdc/unvHYjzTl0/vxo 5/YKlG/cV4LCsYtvhNeQLiFqQMIIFEPX1cEhVKUWSBzXCpdCTZoT/uVJqx6WcXViX5QT27Gu4mT +OJI1QgqvdERpCF3xD7XL+iKDKy/QNAdiRoHxQFQsa8dXytjekbCVOi0NOzFoKTlrtJjDkmKSoo hNFZs7Hw4GMXrjKI8OAxfnpBwHY916zkfho= X-Google-Smtp-Source: AGHT+IG8sF0iHWglgZnU1gFjK5UvEcXKXgLHlC06cCopVW+xjaGA3xCBGO//gxXz/lFckclIKciv9g== X-Received: by 2002:a05:6000:4007:b0:382:4d54:2cde with SMTP id ffacd0b85a97d-3862b3cea94mr11557373f8f.37.1733761265621; Mon, 09 Dec 2024 08:21:05 -0800 (PST) Message-ID: <0edad037-f6df-4a9a-ba3f-73ea2405604d@suse.com> Date: Mon, 9 Dec 2024 17:20:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 08/13] x86/xstate: Map/unmap xsave area in {compress,expand}_xsave_states() To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241105143310.28301-1-alejandro.vallejo@cloud.com> <20241105143310.28301-9-alejandro.vallejo@cloud.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: <20241105143310.28301-9-alejandro.vallejo@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.11.2024 15:33, Alejandro Vallejo wrote: > No functional change. > > Signed-off-by: Alejandro Vallejo > --- > v2: > * No change > --- > xen/arch/x86/xstate.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c > index 401bdad2eb0d..6db7ec2ea6a9 100644 > --- a/xen/arch/x86/xstate.c > +++ b/xen/arch/x86/xstate.c > @@ -177,7 +177,7 @@ static void setup_xstate_comp(uint16_t *comp_offsets, > */ > void expand_xsave_states(const struct vcpu *v, void *dest, unsigned int size) > { > - const struct xsave_struct *xstate = v->arch.xsave_area; > + const struct xsave_struct *xstate = VCPU_MAP_XSAVE_AREA(v); > const void *src; > uint16_t comp_offsets[sizeof(xfeature_mask)*8]; > u64 xstate_bv = xstate->xsave_hdr.xstate_bv; > @@ -228,6 +228,8 @@ void expand_xsave_states(const struct vcpu *v, void *dest, unsigned int size) > > valid &= ~feature; > } > + > + VCPU_UNMAP_XSAVE_AREA(v, xstate); > } In the middle of these two hunks there's an early return. > @@ -242,7 +244,7 @@ void expand_xsave_states(const struct vcpu *v, void *dest, unsigned int size) > */ > void compress_xsave_states(struct vcpu *v, const void *src, unsigned int size) > { > - struct xsave_struct *xstate = v->arch.xsave_area; > + struct xsave_struct *xstate = VCPU_MAP_XSAVE_AREA(v); > void *dest; > uint16_t comp_offsets[sizeof(xfeature_mask)*8]; > u64 xstate_bv, valid; > @@ -294,6 +296,8 @@ void compress_xsave_states(struct vcpu *v, const void *src, unsigned int size) > > valid &= ~feature; > } > + > + VCPU_UNMAP_XSAVE_AREA(v, xstate); > } Same here. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 16:26:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 16:26:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851683.1265712 (Exim 4.92) (envelope-from ) id 1tKgao-0005fm-AQ; Mon, 09 Dec 2024 16:26:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851683.1265712; Mon, 09 Dec 2024 16:26: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 1tKgao-0005ff-7R; Mon, 09 Dec 2024 16:26:42 +0000 Received: by outflank-mailman (input) for mailman id 851683; Mon, 09 Dec 2024 16:26: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 1tKgan-0005f9-9t for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 16:26:41 +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 5dc417d2-b64a-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 17:26:39 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-38632b8ae71so1873019f8f.0 for ; Mon, 09 Dec 2024 08:26: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 d9443c01a7336-216410fd80asm27591685ad.270.2024.12.09.08.26.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 08:26: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: 5dc417d2-b64a-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733761598; x=1734366398; 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=Jq50I1G+0YYtc9QiJzWCI6fpX6PdDQYKBa4LPraZyuI=; b=ZMBII+7TqrUlY+yHzK43XX5XY8y8v4kT7Nzpvz3GXKcUX7JbSoEspGCQlde/BRtHyW 3Mc4eh+Vrb5/TvPjXqNF/Zy+lWBKbWDVF4VAUYTuFyowMhnbdHhBLH7W8Qoi3gIEPmTf 1pyINsTWVi5PP8pTao5qiVVUKX12pOIzQmpx6qcsfKojtz3Z0bRCbCZYTR6LwigKyJVA 5dRb+YaE+hYRWFrdlAOzMEsKYjeHpd8IG10l/ku7yxzg3TXzoClPHwp9PAD5VzySpQAX hb1F5aisNazTvt0iX5gzgzOcalnJwQcI/kvlHXso8txtLlfxI3dLSXU34shEFKrr08dk 8COA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733761598; x=1734366398; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Jq50I1G+0YYtc9QiJzWCI6fpX6PdDQYKBa4LPraZyuI=; b=m3XMH8Nwh9vB5S0P5YhfiSOT4zMmN/0J5EfVUSlrkh7omFgmzBBl+EBxGCs8Gvp7Ck 8RHH78D+ERzIv1uRozrpmdBJJ6ojXRc4eygBUZCzLsNOyVhxxWdlsSGCV+W6wF301Ety AGMXZ+0Wjd1nExFXHdrJyMwvHGT0CMNgRl8og5dtgOjVDN+4Ar0o9wqLORLzhfq7waTH MrKd6WtBSCRlCLCaQqwac2Se0XbthrO98yvk7Xoy1U6xRN82S2maIB2YJXAIYskWItxZ JFT+0qqDgmX5IEhZdviYk+mme+sDTZ2YUA2oYp4V16VGDc2Jk5XuzbFFu6P9zpBUQSG6 FYgg== X-Forwarded-Encrypted: i=1; AJvYcCVggdnMdDln/HL7uT1047H40oFjWqj8AVDNGZbDQ/HknZFQdhrpDDKLQX/u0DFm8xYr8h9qvrmC2IA=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxi1lceSMNBhDy82BmMniwvVv1U/brQPT/MCx2cG9hEFRUcg6+S ptIfo3HSf4RM1twABvIs/eoirAaSjqPaKlqatw761Nxf+pjgK/24mHHABr+Eqw== X-Gm-Gg: ASbGncsx8P8qHFnSCPeVnR//zKLhJAAiS80c3fnbF7sJAwkJNx0tmVzQyagROdi82el O1qLwhXIbsAuFLUiKpmOkWS2pHtXmeJUE9xtRMMEtB+Y72IxSp0XF65HM4vb7iGwR2QayFAYbM+ Gt11GmaE4ojfERgZbaaB+44O51Xf9vAu253vHIPHP7y3DxkZZfw7ZZo5M1kgRw40iLRJzd+JjRU XK7ScZ3tFgrKY22tZaicw9NIFaGGJ7gYkFMI9Sw3GWobcMXiZyz9BXNTOxQZY7xC243TlEOH18r /TbStKc2gWD6gtgEdu7DNgzAbohFoQlc60Y= X-Google-Smtp-Source: AGHT+IEBFQwYrHYLbkSbzaVcAfuT378XDcyZ3odij9a/7yQqHX4eQCLiRdUfs9OW+4Ev4UHqQ1hu0w== X-Received: by 2002:a05:6000:1862:b0:385:faaa:9d1d with SMTP id ffacd0b85a97d-386453e605dmr912922f8f.35.1733761598450; Mon, 09 Dec 2024 08:26:38 -0800 (PST) Message-ID: Date: Mon, 9 Dec 2024 17:26:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 09/13] x86/emulator: Refactor FXSAVE_AREA to use wrappers To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241105143310.28301-1-alejandro.vallejo@cloud.com> <20241105143310.28301-10-alejandro.vallejo@cloud.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: <20241105143310.28301-10-alejandro.vallejo@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.11.2024 15:33, Alejandro Vallejo wrote: > --- a/xen/arch/x86/x86_emulate/blk.c > +++ b/xen/arch/x86/x86_emulate/blk.c > @@ -11,9 +11,12 @@ > !defined(X86EMUL_NO_SIMD) > # ifdef __XEN__ > # include > -# define FXSAVE_AREA ((void *)¤t->arch.xsave_area->fpu_sse) > +/* has a fastpath for `current`, so there's no actual map */ > +# define FXSAVE_AREA ((void *)VCPU_MAP_XSAVE_AREA(current)) > +# define UNMAP_FXSAVE_AREA(x) VCPU_UNMAP_XSAVE_AREA(currt ent, x) The typo of the first argument strongly suggests that the macro should already now evaluate its parameters, also pleasing Misra. > # else > # define FXSAVE_AREA get_fpu_save_area() > +# define UNMAP_FXSAVE_AREA(x) ((void)x) If only for consistency and to avoid setting bad precedents - parentheses please around x. > @@ -292,6 +295,9 @@ int x86_emul_blk( > } > else > asm volatile ( "fxrstor %0" :: "m" (*fxsr) ); > + > + UNMAP_FXSAVE_AREA(fxsr); > + > break; > } > > @@ -320,6 +326,9 @@ int x86_emul_blk( > > if ( fxsr != ptr ) /* i.e. s->op_bytes < sizeof(*fxsr) */ > memcpy(ptr, fxsr, s->op_bytes); > + > + UNMAP_FXSAVE_AREA(fxsr); > + > break; > } So for now the emulator only supports FXSAVE / FXRSTOR. That'll need to change sooner or later. Is it really appropriate in that light to name the new macro after FXSAVE, when the underlying machinery uses all XSAVE? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 16:30:57 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 16:30:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851693.1265723 (Exim 4.92) (envelope-from ) id 1tKges-0007Jo-RY; Mon, 09 Dec 2024 16:30:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851693.1265723; Mon, 09 Dec 2024 16:30:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKges-0007Jh-Ou; Mon, 09 Dec 2024 16:30:54 +0000 Received: by outflank-mailman (input) for mailman id 851693; Mon, 09 Dec 2024 16:30: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 1tKger-0007Gv-Jf for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 16:30:53 +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 f46e7c73-b64a-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 17:30:51 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-385e27c75f4so3471879f8f.2 for ; Mon, 09 Dec 2024 08:30: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 d9443c01a7336-21637c96975sm32532835ad.25.2024.12.09.08.30.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 08:30: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: f46e7c73-b64a-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733761851; x=1734366651; 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=OgT9yQcxy5ylQ9TY0cyrN1Lr58fZdERdHTNBqjI9JIY=; b=DOE+dxZ/YggViBR8LqhNnNXCe2woQXTfBsXM1HY3OoUXYtxdSPx03uYtXnl+W6jibR qF7k9EoZ+KQyJ/uT7lJg61B7KckYP/6eZ0zC642QTNCRF+AkJED7XU2F75tFLPFWtdSO lst4LlIcNcEAL9QZanoViuJmUptlqRMVKzOOixXUYdhej8yFB3OYz34qxRyz3x9qcxdg pGn11vdYByyMF6M/XuOql1PZrC2XgtnEe6qIlQJdRjH4dGoYr5XcUyd8rKSkc1Q+M6uZ ldH2Pj8fJP1N/gFmvlVJfw7zeiLQwutyMQuEK9WL+M3i1uHoSU7awhEagVOWaLeJha7q kt5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733761851; x=1734366651; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=OgT9yQcxy5ylQ9TY0cyrN1Lr58fZdERdHTNBqjI9JIY=; b=U90cWT3c7feAilD60uAzehqsWxnGu4GOTd7RSA+cpvFT1ZiqDxwmfFHCksvFb54JOP mOxgwJdcBsYahQW8ThVEV/cMpI5vYI5kCHsMCCaqc2SeqIDyrrguIMMzL9wO485E2BNO WoFB/pWTNBoDRz6NJlZVcanFevdqBF62GxFpe3VgLGcO5htm08WPKQH/KKYFhYt8N+Zb OUQ+5Np5YqkdJnqZUVmpdnkX6uDqp9lZ0ksOyB4PYbp4B59eYspO8g24bpqod36bWYB9 ZBo3omURMlvBVcj+9JZNO4NHp5ya16CTdv24Wo3KUss5L3Ysq9IBsca/bu1Dr3gjH9hv KkzQ== X-Forwarded-Encrypted: i=1; AJvYcCUIBgAsAGIeHokmGe83PIEII3KBvqJqW4ww0BeSkePB98+et27BA2R3QXSdzSUq4VwW7iIbtutCw2U=@lists.xenproject.org X-Gm-Message-State: AOJu0YxgGt+CCv0zEXPIw6xnh8Vt4mu4sl8JM1frSs8Z3rqn2OzIr9Tw LLauxoAkuLnzWFmX21SEAwR7AHNOySaDvWI1FYctpcwZXgHZBAggMu36rGQTew== X-Gm-Gg: ASbGncuZLgmPuntPa9xehqIaLGp7F8zjGCikpQ0MSC526UgLLFR6Q+ncmB7inb/0VCi vUXLs18iybo8xhdwtnQJ0XxHbW8KDPjSgB0UX1ZgoNTlnoAqrNFDRqx1kLMisgCDtaYy9pigCcn TE7rk4bi5sdpIMxYUBcMD/w1qFzkkvftMZm4mQmOwDa2fpDwaETGolxiUOvUPkiyj3+aN0o9nmO OzZxo/VdeP3iHKp88EKYKN9yItemO3r1KgdBZ3tC5sfST0ll+Xfczo092RvqMZH33Cc1Uhz6MOZ XhmwVjp6RpgTwBf7U+GFX/p3s8+nyKRFK1c= X-Google-Smtp-Source: AGHT+IHrwxIJ1vlPzSGfYUj2/oul7ya/PxJfseCTKosApilHfeElst02rw35+HBDKHsGnu8f9K0FgA== X-Received: by 2002:a05:6000:1565:b0:385:e1f5:476f with SMTP id ffacd0b85a97d-386453fbd25mr705317f8f.39.1733761851181; Mon, 09 Dec 2024 08:30:51 -0800 (PST) Message-ID: <7e36137b-ce1f-4e78-9a41-fbfdbe9c0d87@suse.com> Date: Mon, 9 Dec 2024 17:30:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 10/13] x86/mpx: Map/unmap xsave area in in read_bndcfgu() To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241105143310.28301-1-alejandro.vallejo@cloud.com> <20241105143310.28301-11-alejandro.vallejo@cloud.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: <20241105143310.28301-11-alejandro.vallejo@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.11.2024 15:33, Alejandro Vallejo wrote: > --- a/xen/arch/x86/xstate.c > +++ b/xen/arch/x86/xstate.c > @@ -1022,9 +1022,10 @@ int handle_xsetbv(u32 index, u64 new_bv) > > uint64_t read_bndcfgu(void) > { > + uint64_t bndcfgu = 0; > unsigned long cr0 = read_cr0(); > - struct xsave_struct *xstate > - = idle_vcpu[smp_processor_id()]->arch.xsave_area; > + struct vcpu *v = idle_vcpu[smp_processor_id()]; Can this be pointer-to-const? Certainly right now, so the question is rather meant to be forward looking. > + struct xsave_struct *xstate = VCPU_MAP_XSAVE_AREA(v); This certainly can be pointer-to-const, just like ... > const struct xstate_bndcsr *bndcsr; ... this is. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 16:37:30 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 16:37:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851709.1265733 (Exim 4.92) (envelope-from ) id 1tKglA-0008V6-Kt; Mon, 09 Dec 2024 16:37:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851709.1265733; Mon, 09 Dec 2024 16:37: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 1tKglA-0008Uz-H4; Mon, 09 Dec 2024 16:37:24 +0000 Received: by outflank-mailman (input) for mailman id 851709; Mon, 09 Dec 2024 16:37: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 1tKgl9-0008Ur-BH for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 16:37:23 +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 dd31128d-b64b-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 17:37:22 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-435004228c0so4055905e9.0 for ; Mon, 09 Dec 2024 08:37: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 98e67ed59e1d1-2efafd98703sm2127929a91.4.2024.12.09.08.37.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 08:37: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: dd31128d-b64b-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733762242; x=1734367042; 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=nV7c6+ec09Q3/6qGaFyzjOvXH3R2CrH/dWqBxMXAQuk=; b=gCpqujbl+yfg7NVq0DsxLsiMq6W9x368Sy6Y4ThuN0JRdn1zBIpP7kB7D85ltz3CIH xIgUduNGtcRbabgZp091pZUw98KplfY565wGbJPK058KlEl7jpUOqcPJaKIPcqUaZaZx ATZwx0Ngq2oTz8r5P3GWbNovMic50C1Xqg0XFpoM4IU3wV7MTgQ70qJrcTXlv0EA1P9q CQ9fcKrOaRlxh7Tv+/ZYnSZRg3aBOp8fxKEKYKoMaZ7zJOPl8oreDoDc7k8j4Hbae667 MfahD1aXAMWHN6cAmu/koOnqr0NcI21sLdCuVML61xiIzvY2eySuapaScCpdhVCeuELt vOoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733762242; x=1734367042; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nV7c6+ec09Q3/6qGaFyzjOvXH3R2CrH/dWqBxMXAQuk=; b=D18cfyi0DrRnOu1S3Wl+ZOFrloK2MANivWG9cH15m48If6fwRrgf/34GnRdF9+s8VG 4nlXIYomT+iIHbP9wonfvx4BSKaBXCuCyCjhYci2VcduEvcYxvvlRm7ect8ZuQeWnYse P3sp0DwNwuBy/xTbarP6rTiQwTljerpaCD7uk8lJBov61UBomjPkoAf5G3P4r10DTUOd TjJ+wsElWboXQkkjiGoc0/EP/uJVNZsIC/Xg+FOt6dotYBiYLoSwx+z9N7a7SbWB6eAc 4NMJbSaOn8CU4dDPsF1Ay14xhYQae2LdKp0Nj8/jda5u42nXhM2OZQLvFCaqLbyQneM9 CRXg== X-Forwarded-Encrypted: i=1; AJvYcCW71lKmr8vZGuO00iYnCVNRm33pusUiZEPHjniTtwKATCvz5WMu/s0wC4EXy0hGBz37XLaH8awjrXw=@lists.xenproject.org X-Gm-Message-State: AOJu0YwPY1hLxnbdmWN3v7LAVGTDls2fPexEFmN4YcnznvtQOGQBpLr+ Xa8dLv6VleqllDbBiaCyVZqYLY1rEmhXCSOaIao7l+lp/EA3hI7q1jXCV8D40Q== X-Gm-Gg: ASbGnct74tv1VmmonLTdyKT8wDUeKAgAizBNdNlsskDVBRRkd0e2SfBuJyq1G0s2Gym IzlvxHa542Z/u/+DHH297mvX0rIrFNCNvUdq9rYDDcMH3XgF9zMhrNSubZZrHrRWKTi82QeQzQf 9QtfaKm8HfB2pI7Klb61OuaSoltGJjhvLNd0WcU+x8lA/OjuCSQkCIy6v2QgVjQj8t/ZAAhswlz FHgrYfiw8GhnuMR8hqS//QZVQdk+YJZoBN6RgeknScgNw9RQW33ZIFltiFDNEXjyeNNNMpZSfqV D9Roa1igiru+F8+gdpJC0ycK5X098BOhvDc= X-Google-Smtp-Source: AGHT+IFy6cBtmhUah5MhaQd32Usj39ZECAJNl8AbGI5Ts35NY084dpff0uWOXHvaSI58Ks1OflCjNA== X-Received: by 2002:a05:6000:481c:b0:385:e5dc:e285 with SMTP id ffacd0b85a97d-38645400f06mr1241594f8f.58.1733762241751; Mon, 09 Dec 2024 08:37:21 -0800 (PST) Message-ID: <6df9e623-933e-4cef-a273-b171b8990249@suse.com> Date: Mon, 9 Dec 2024 17:37:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 11/13] x86/fpu: Pass explicit xsave areas to fpu_(f)xsave() To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241105143310.28301-1-alejandro.vallejo@cloud.com> <20241105143310.28301-12-alejandro.vallejo@cloud.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: <20241105143310.28301-12-alejandro.vallejo@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.11.2024 15:33, Alejandro Vallejo wrote: > No functional change. > > Signed-off-by: Alejandro Vallejo > --- > v2: > * const-ified v Hmm, yes, you did ... > --- a/xen/arch/x86/i387.c > +++ b/xen/arch/x86/i387.c > @@ -129,7 +129,7 @@ static inline uint64_t vcpu_xsave_mask(const struct vcpu *v) > } > > /* Save x87 extended state */ > -static inline void fpu_xsave(struct vcpu *v) > +static inline void fpu_xsave(const struct vcpu *v, struct xsave_struct *xsave_area) ... here. > @@ -141,15 +141,14 @@ static inline void fpu_xsave(struct vcpu *v) > */ > ok = set_xcr0(v->arch.xcr0_accum | XSTATE_FP_SSE); > ASSERT(ok); > - xsave(v, mask); > + xsave(v, xsave_area, mask); > ok = set_xcr0(v->arch.xcr0 ?: XSTATE_FP_SSE); > ASSERT(ok); > } > > /* Save x87 FPU, MMX, SSE and SSE2 state */ > -static inline void fpu_fxsave(struct vcpu *v) > +static inline void fpu_fxsave(struct vcpu *v, fpusse_t *fpu_ctxt) But then not here. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 16:39:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 16:39:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851718.1265743 (Exim 4.92) (envelope-from ) id 1tKgnQ-0000dR-18; Mon, 09 Dec 2024 16:39:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851718.1265743; Mon, 09 Dec 2024 16:39:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKgnP-0000dK-Tr; Mon, 09 Dec 2024 16:39:43 +0000 Received: by outflank-mailman (input) for mailman id 851718; Mon, 09 Dec 2024 16:39: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 1tKgnP-0000cv-AL for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 16:39:43 +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 1bab094f-b64c-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 17:39:07 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-385e06af753so2031205f8f.2 for ; Mon, 09 Dec 2024 08:39:07 -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 41be03b00d2f7-7fd41a128ebsm3353887a12.85.2024.12.09.08.39.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 08:39: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: 1bab094f-b64c-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733762346; x=1734367146; 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=IRym/k5ihUH0BNJ6NqNMOufR94ioOhx+BhzE3219cIs=; b=EdQvcTgTCazWTakUlgss4dmSmWwGJRzolyrXnb1t3J9rRuxYrCGkC9eQ1SxBoOhui8 GivItVxJGarpLZbe9b4aO8Unw8NlzxNzP16PTaVp4L66txr0fuHuqw+1I/OLbJtDqZ3h bNk2SHUB2KTaDv6Ub6OxfHqriWnEeaFThHhqmCx0+DNaxkmo0A6JD4r0uDmhq+T18OZk ZO/HRNFYt61Gh5wk1EqW+mlpMTuA1BsGEvBsYMoaTypCmal+uICDjgE9kBFC8pZPIdP5 TWZl0IbF+OHp4pkHeyonZ17c36wfpDhlFe1rt+W3A/M2cbp/WbCh4+t1oq/zCDRc526f +pfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733762346; x=1734367146; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IRym/k5ihUH0BNJ6NqNMOufR94ioOhx+BhzE3219cIs=; b=jKXhZ6cXmLsc8mK2doiSSusfsdvdSZJZ+lXfx2FrqDAaJNcpbqYSIFWGSE4rFmuVbk 6bzen+UMwBLfCJ0DM1gVHUHmVJt2J0uZnrg8aqx350LZ5r+FvCrvhrtS2ceHGk7tpG5c stC/QWT3VYmjhq9kAhMy2l/TJTYcvjFaeGb5xZpQqX5DRZsLvVahqCf6nu44tzmSUvTH 5f3M1Wp4mFjm4w2a/Prtm7MGEoqNmDt8C++BpFTaK+R6KkabIOa0ss4ZE+U0COy7QAYu lZEgRPGpempF6OHgArOwerWYsdq2h8pljHGvSjaChZQasUErzBWANEMVIJC0GxeVHy5M z/zg== X-Forwarded-Encrypted: i=1; AJvYcCWdC+SVNkH1wp4uqpXLU/93S3yyTwUdzOIMEZ7ew68Y/2uZmpwwvtia6KgEmIMJ8pvmen8Z4PnZQtA=@lists.xenproject.org X-Gm-Message-State: AOJu0YxS990z4owTAWRgheM6bnLwmOKGY199/V3e1BoHs7rju+jMEmwU zZJDXvVW5oEszbu2eCznS/Guu6Xgr4Mjxz5VAOAx78bS3M4VBdTLA7T6/D3QFQ== X-Gm-Gg: ASbGnctniSKRcYc8o8UJROSpKfYkbhuyk7V3emiW2dcLUig0Eu1eJhMCDK6K5l2lztp EWYIMoKjffUqPodkupo2+ddgFyhLYSCh+YrCsmdyeORu8HmS+2e46JNVDA9CcoVopKv0On13g++ oEGD7NAzLXUgygpEqch8qihrMWJfGqaAaLbtQCgQHYjmqu6cHQGN2TKWvO6NMTOvsFby+wgXZ3s glvX5fmmPMUPVnNLfHfhXvNlzgCzetyGXoT+xu7sq7vbFWG0N9p7uUUS6LkziW1LnO/QnPhmucb rQrxfew8tcpt8/heeOK73NuVfnR5iyYeXi8= X-Google-Smtp-Source: AGHT+IHaEJET1nBz5d0IFS/lbZC8mbFLtjmjPrnrvzrEHiVsckh1ruVKSi1kCtSWirZDXObHxAQGVw== X-Received: by 2002:a05:6000:1f8b:b0:385:df4e:3691 with SMTP id ffacd0b85a97d-386453fe984mr938731f8f.42.1733762346558; Mon, 09 Dec 2024 08:39:06 -0800 (PST) Message-ID: <8ae8a465-4f15-4ec9-b902-54a8d9448616@suse.com> Date: Mon, 9 Dec 2024 17:39:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 12/13] x86/fpu: Pass explicit xsave areas to fpu_(f)xrstor() To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241105143310.28301-1-alejandro.vallejo@cloud.com> <20241105143310.28301-13-alejandro.vallejo@cloud.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: <20241105143310.28301-13-alejandro.vallejo@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.11.2024 15:33, Alejandro Vallejo wrote: > No functional change. > > Signed-off-by: Alejandro Vallejo > --- > v2: > * const-ified v in fpu_xrstor() Yet what about fpu_fxrstor()? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 16:41:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 16:41:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851728.1265753 (Exim 4.92) (envelope-from ) id 1tKgoz-0002JN-BT; Mon, 09 Dec 2024 16:41:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851728.1265753; Mon, 09 Dec 2024 16:41: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 1tKgoz-0002JE-8B; Mon, 09 Dec 2024 16:41:21 +0000 Received: by outflank-mailman (input) for mailman id 851728; Mon, 09 Dec 2024 16:41: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 1tKgoy-0002J6-IA for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 16:41:20 +0000 Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [2a00:1450:4864:20::42c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6abbf184-b64c-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 17:41:19 +0100 (CET) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-385e0e224cbso2362311f8f.2 for ; Mon, 09 Dec 2024 08:41:19 -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 d9443c01a7336-21631bd2c2dsm39345285ad.263.2024.12.09.08.41.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 08:41:18 -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: 6abbf184-b64c-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733762479; x=1734367279; 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=4KNYZ7a2I2dbgKZ1H8TKiU7KiDZpr7dlCDtIM0BRtjQ=; b=KPdBnifDNN+4YW696QHGCPkmqEh4ZaG58EjqQwejwyb/4LFpG0JyPsOiqs1f9tqkF0 GB6f7Gyq6KbCyPeEVLycuSM+s/hOomLk7vP6EAYImMIBbz8uluO0yIBZ4BnFWIgmEkXr 3+kTuscVYF5Crzf2aOaROdX3yzp8BYYvymt9boAC3w04MIK9y5hQcJJnOwn3iM6CVfgt 7zY5o2N0jRzN2G+yR2PyPZIeZdMlwdEKqpK9e1kymeBiWrbnu50hPbgLkyN/+NCGwK3F PRlHtWhZYMjPKoZM0R0AWKrF7JJQ8897a0MheuDAHJ4Bt0xXSQdXbyS3gRGX6B/Oftsw K4dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733762479; x=1734367279; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4KNYZ7a2I2dbgKZ1H8TKiU7KiDZpr7dlCDtIM0BRtjQ=; b=xAu485S/ZmDU/gTeVIwfj4iO5RJQtHG3m0sCr/8NtDMIDf4GysjQ6EgYq1/W2LZdEE O1MCAPRk2pIVUgZC6yEYnOPkhiJB0BrwR2wArFkaZGLkzwZCNaQN5xmQtZ6M9AAo+F+2 FsNlpmvUU0SYQCig6j+uF5hzgU3HGDYpf5oCfjfVu9vaE+2ockW4VjmTD9TIDQ3dep7+ +n1Fun2quVX9VEwyOF3lbGBurnXHC5oEaUGBTMTgtHPZoX6F6VQJyeoViqqUEBNYd6GL femeamhkc0VlyQVYllpjp4Cl3DLGvUlrDUTgBpiFE8Yh/YFqGae/2FWhX0sOtO6fANmc VEow== X-Forwarded-Encrypted: i=1; AJvYcCVytweop8XiE8+qTSnGleaUv1dBikyQuG5XGgi66kSxQ52WdkxPrUQ1VPS4+PPjU/5GRysGhfNPUAk=@lists.xenproject.org X-Gm-Message-State: AOJu0YyBtZZgYIATN5yB5R6QVJSAAgzBwemlZjcPBnXgU3zQTyAYC6mH h/EdHMTkQssRVAs9YGS0arf2AhmqqaDk4H//g/UOLh3msckq/i/3U+KlsBG5Ng== X-Gm-Gg: ASbGncutuxDMLBDyu96cRxFVKl+z06la1dxRqEwxLHdASkvhA8iwS5rHQhooPODD1fE Zl1h+7hKtUPfRXyGJVwPpbVcNmoV7TAkYTQErLh19xg0OK/KREhReiG9Jd9sXxsMjcX+jjSfGFo 8SmVwPySw/4lf9jtAZCyNYXTH97uf97zYDOXo/cI4NveZI7tghacoJbKo+k+3GsaPPl6YDTv3aX pgW0Ng/UmCWdTpcowcnvE16ec39+b/NMO13SZOzOPUL4EyAv5wg80s+FkoJXwOip3P1/3Ta4tZv enRhs43F8WpfrhgMJOGqpY4RpSGH88UpTPY= X-Google-Smtp-Source: AGHT+IGSswVdTz6RYfKM7Udf1KRZagQ99uGclDqxsm93sTcIJLE3syDKgE/xX7b8s4q7Ps0AkQwvsQ== X-Received: by 2002:a05:6000:2c3:b0:385:fae4:424e with SMTP id ffacd0b85a97d-386453fe4dfmr1028394f8f.52.1733762479247; Mon, 09 Dec 2024 08:41:19 -0800 (PST) Message-ID: <1eb18f87-eb50-454b-89f4-5e7431fde285@suse.com> Date: Mon, 9 Dec 2024 17:41:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 13/13] x86/xstate: Make xstate_all() and vcpu_xsave_mask() take explicit xstate To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241105143310.28301-1-alejandro.vallejo@cloud.com> <20241105143310.28301-14-alejandro.vallejo@cloud.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: <20241105143310.28301-14-alejandro.vallejo@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.11.2024 15:33, Alejandro Vallejo wrote: > No functional change. > > Signed-off-by: Alejandro Vallejo Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Dec 09 16:52:21 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 16:52:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851741.1265763 (Exim 4.92) (envelope-from ) id 1tKgzV-0004PX-9k; Mon, 09 Dec 2024 16:52:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851741.1265763; Mon, 09 Dec 2024 16:52: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 1tKgzV-0004PQ-6m; Mon, 09 Dec 2024 16:52:13 +0000 Received: by outflank-mailman (input) for mailman id 851741; Mon, 09 Dec 2024 16:52: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 1tKgzT-0004PI-H0 for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 16:52:11 +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 ee023b09-b64d-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 17:52:09 +0100 (CET) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-3862df95f92so2366383f8f.2 for ; Mon, 09 Dec 2024 08:52: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 d9443c01a7336-21627260937sm45821495ad.103.2024.12.09.08.52.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 08:52: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: ee023b09-b64d-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733763129; x=1734367929; 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=Oe7SIAzJ7RU6DukID+TlaLefZM63Iz7E9Xmln4k3LXc=; b=UBV1GmmWYQYVB6xSbeFivlnM3c9tIRve4yZDlVsTGDmCet61lHDqH/L2R3LT7uByeF U1BNRQgWNfAsPOHzJK20HNSs/4JCxg9st6Nc/mKLHIPd5WII5DyXbRAb31WdRXvFO5VT DQILlkIn1k/cXrLGCBPLnHgJgEUj4VerF/MycLgGNcKawOwY+laV+9fLDpA6kKAioGo4 OGTn92YH940DAmXypY6W8g2FNI5UqSGPE6wFzF+Ve6ZlgIFLxmmaiDAbZ3udrsId3H29 jSwxbBpSxTHvnkuD8KXil8HtLo8oD+TWBacqR2dd9nyJqgscJq0MbjtLNDR53oaf/jqK iRBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733763129; x=1734367929; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Oe7SIAzJ7RU6DukID+TlaLefZM63Iz7E9Xmln4k3LXc=; b=bqV48R6Apa0X3NqQOu8UqhGn4BS8AJDuGcRbVmpmDI5u9KPJt2bYTx/0KvbLEoJXLD NJ/Zto/TDk1h4b9LdEurw31OLL6s90uoPzJ9lbx5DPhfOge5ww4e4H5brimgl0Qi2ZZH vaGbGxBpr3fUW/RiaXFZoNmwdOSJr0QQtrHGUJP8gfMANwr2ls8fhYZHX/azdvL3ovK4 J3LX36+4RXzaX/RF21fWqsfqXu2U3AeHQ7Q2ck8fOpuNfUPbZ7Lm5KwwncYtIiaWfOfK ibsB3wHTdijJAquvrZ5lJE0ldfKSPANagXkbtviaOfsTgOwiuU+O7RS5gzlY5nX+mAts 6oog== X-Forwarded-Encrypted: i=1; AJvYcCUOrAY3ZcHW1NThUvWj6W+yoykWlO8J4fpZ+MBr/8WwCUA/HiTKGcbl+Nz1zT6Z4KtmKd7guzBeyZM=@lists.xenproject.org X-Gm-Message-State: AOJu0YxQbxrjQL4i17kSILNk6T7GgfVA5kXxekm+YsVO18PzhUF7dfiz gISwkXX65jg5KQaHrqIS8jaHQdPGHfD6fO9dc7p86MK7nBX83nLyiPYH1ZoPDA== X-Gm-Gg: ASbGncv8dLi4OPhDEchh1Vx9j0NP7k+UyzmAdz2eJ+Zfk0KOY15nEQrs5oOqZagfydL Bl3UwGRUotYJv4G55122EPFQb5tNxKux+PNTe+SGi/95RgHUCb+tvqfDUGNfnjCwINRLBx/zJ/2 2h9Cb8ucw7srCslmYuxfbU8NWYbbugGn/FiUwm1/WS1BnMrVFC7/VPw83T5vQFV5zteU0f3aB+S zPE5uoU/JBch2GzKLqtEKBjX4/jyJLJFUpBF6/pc8OSkBh2tsdXNLgnS0VjlhRHyz2cMUouhksX U0Fg6N+S9Blb8VUDrbD8IErf4J6JgaxNMmI= X-Google-Smtp-Source: AGHT+IGOubpyw9dAdIj8DXacrzzYXTafP+GlDAuI7a4WoomOhRf/3i7Stzg9gzQ4lpbvhjMzSlsmQA== X-Received: by 2002:a5d:64cb:0:b0:386:3cfa:62ad with SMTP id ffacd0b85a97d-3863cfa63acmr4611378f8f.1.1733763128911; Mon, 09 Dec 2024 08:52:08 -0800 (PST) Message-ID: <8acde5e5-7972-4f7a-ae31-92c3f323669c@suse.com> Date: Mon, 9 Dec 2024 17:52:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/7] xen: add bitmap to indicate per-domain state changes To: Juergen Gross Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20241206130221.17773-1-jgross@suse.com> <20241206130221.17773-5-jgross@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: <20241206130221.17773-5-jgross@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06.12.2024 14:02, Juergen Gross wrote: > Add a bitmap with one bit per possible domid indicating the respective > domain has changed its state (created, deleted, dying, crashed, > shutdown). > > Registering the VIRQ_DOM_EXC event will result in setting the bits for > all existing domains and resetting all other bits. > > Resetting a bit will be done in a future patch. > > This information is needed for Xenstore to keep track of all domains. > > Signed-off-by: Juergen Gross What I'm still missing is at least mention of the global-ness of all of this, and why that's deemed okay for now. > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -138,6 +138,60 @@ bool __read_mostly vmtrace_available; > > bool __read_mostly vpmu_is_available; > > +static DEFINE_SPINLOCK(dom_state_changed_lock); > +static unsigned long *dom_state_changed; > + > +int domain_init_states(void) > +{ > + const struct domain *d; > + int rc = -ENOMEM; > + > + spin_lock(&dom_state_changed_lock); > + > + if ( dom_state_changed ) > + bitmap_zero(dom_state_changed, DOMID_FIRST_RESERVED); > + else > + { > + dom_state_changed = xzalloc_array(unsigned long, > + BITS_TO_LONGS(DOMID_FIRST_RESERVED)); New code wants to use xvmalloc() et al. > --- a/xen/common/event_channel.c > +++ b/xen/common/event_channel.c > @@ -485,20 +485,27 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port) > if ( (v = domain_vcpu(d, vcpu)) == NULL ) > return -ENOENT; > > + if ( virq == VIRQ_DOM_EXC ) > + { > + rc = domain_init_states(); > + if ( rc ) > + goto out; > + } > + > write_lock(&d->event_lock); > > if ( read_atomic(&v->virq_to_evtchn[virq]) ) > { > rc = -EEXIST; > gdprintk(XENLOG_WARNING, "EVTCHNOP failure: error %d\n", rc); > - goto out; > + goto unlock; > } > > port = rc = evtchn_get_port(d, port); > if ( rc < 0 ) > { > gdprintk(XENLOG_WARNING, "EVTCHNOP failure: error %d\n", rc); > - goto out; > + goto unlock; > } > > rc = 0; > @@ -524,9 +531,13 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port) > */ > write_atomic(&v->virq_to_evtchn[virq], port); > > - out: > + unlock: > write_unlock(&d->event_lock); > > + out: > + if ( rc ) > + domain_deinit_states(); > + > return rc; > } Renaming the prior label (and hence needing to fiddle with existing goto-s) feels a little fragile. How about keeping "out" as is and introducing "deinit" or some such? Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 17:05:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 17:05:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851752.1265772 (Exim 4.92) (envelope-from ) id 1tKhBz-0007HV-Ag; Mon, 09 Dec 2024 17:05:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851752.1265772; Mon, 09 Dec 2024 17:05: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 1tKhBz-0007HO-88; Mon, 09 Dec 2024 17:05:07 +0000 Received: by outflank-mailman (input) for mailman id 851752; Mon, 09 Dec 2024 17:05: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 1tKhBx-0007HI-Gv for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 17:05:05 +0000 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [2a00:1450:4864:20::42f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bb6493cd-b64f-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 18:05:03 +0100 (CET) Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-385e1fcb0e1so2651755f8f.2 for ; Mon, 09 Dec 2024 09:05: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 d2e1a72fcca58-725def37e0asm3471489b3a.193.2024.12.09.09.04.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 09:05: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: bb6493cd-b64f-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733763903; x=1734368703; 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=8LM3m97fjq/BYaQF/gCO8ywrIRLHoxQl16S/jMd6ovw=; b=YYg29ONm/7F5kLNa5gnpEE+01PEEKbAhCr0r8/yBSQ5c1Edon6fG01e+mHhwFxhjxb PRgvHWrZOpKQu83jlbVhQGrEQt2Ret4ipLQ19d1EBYi+c8bkjoK6GMTYwAQmd5JWXDr2 NFoKZ5jIeOHwdCGqAr2NDQvj94oOsnv9+ygBHkd1ejPlSsjZdwaNOKgd7FkIAzvGv+i9 OnFHnIItdnqfLst+raDUo9I6P0MCXp69y6A5gIY0uP/SSkPDggFiiyCPsp9W3j4rTUtU fIcY5KyB+38tuLgcqrdMDyTVVMg6yzsZRAU5bzRXUP/agIaHtQAQ+w1YsIXftF159RK3 V5HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733763903; x=1734368703; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8LM3m97fjq/BYaQF/gCO8ywrIRLHoxQl16S/jMd6ovw=; b=Ps5Z7P01pOY0fCHdRISobih2PE4qhaJIiR+TbO/OUL3mGm0EJCbnrPVNKhpKdXUvlw mrDCOE9cBsnz3401cq1dMGNHScoevVTUca1ig34p3yBOz/nciFa+rchZehvRO/4MjY1x 0uxMrtojcFwhK9z6kJ8a85p/d9sGpb7YmUiEDlWjlLrU2chHUxSbhfWNddQMyNd0KjpB TcSmkDsXqQAeFWHY7mJBwuEUOTUu+h4AoEYD5qF51WbGk8EaLYVz7rE4Kw4XTzftEty+ xym4J01jJfxZuUNi2YOEL0ILc66Hf5iJpULlHma0AoOYidmDJENtDDH0KYY6ZsoGgI+E zJsw== X-Forwarded-Encrypted: i=1; AJvYcCVTH+jWm3R4UKx/YYTQFgZbJxFVKK0ThPOHLHJC6SLm64we23kEKRTSC6HW7mT+VzsVx57rcdYuCeo=@lists.xenproject.org X-Gm-Message-State: AOJu0YwgcK84zOuEuEPmtoUhQFO0X8vwj47ZFQVsnl+SN7ReXXWXAgwF 7chOxF5o05d0h5uLt6KbByKlMqXix9OHR9i77YjtqSp3ErxRxeSfSAX/buARgw== X-Gm-Gg: ASbGncs67ioewGuI4aq+omQ6dPrzo39ILSOeHa91BGj8of4b7inAKNWLLt8SzdSRbUl nulYmesBm23JrXJA/BDz2ujOnwuyWKuA9NZunaLcqWZmv7jG/2hLI5PQtkzr49qzsmCQsmtK6ms GvKdBPw3AOdfAXt3WHy1CI7b9DkdH86QNhifcrwUB/zYlzolZqHP9bV20RX6K+lnQu0ecqYtbBD 5rMEVJ0EBV97Z3ouOn0iiGEzoyUFPHIo+xHSRKnpaH1B6jKVxKNMQNcIlW7Dplrfvv2TNztGQio 1UGdT9VFiaiyndz6fmYPSMANz7A/IyPZKIQ= X-Google-Smtp-Source: AGHT+IGfBZfW3V2PiNGe7YaQ+VIiVhVfv2hXadI13zK1NiSKBE3IjDg3se99dmTCBLxgIHh4Jupsiw== X-Received: by 2002:a5d:64ab:0:b0:385:f271:a22c with SMTP id ffacd0b85a97d-3862b3f289emr10432682f8f.59.1733763902942; Mon, 09 Dec 2024 09:05:02 -0800 (PST) Message-ID: <69e08251-c227-42a5-a2e4-a4eb7d63961d@suse.com> Date: Mon, 9 Dec 2024 18:04:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/7] xen: add new domctl get_changed_domain To: Juergen Gross Cc: "Daniel P. Smith" , Anthony PERARD , Andrew Cooper , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20241206130221.17773-1-jgross@suse.com> <20241206130221.17773-6-jgross@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: <20241206130221.17773-6-jgross@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06.12.2024 14:02, Juergen Gross wrote: > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -192,6 +192,54 @@ static void domain_changed_state(const struct domain *d) > spin_unlock(&dom_state_changed_lock); > } > > +static void set_domain_state_info(struct xen_domctl_get_domain_state *info, > + const struct domain *d) > +{ > + info->state = XEN_DOMCTL_GETDOMSTATE_STATE_EXIST; > + if ( d->is_shut_down ) > + info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN; > + if ( d->is_dying == DOMDYING_dead ) > + info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DYING; The public constant saying "dying" isn't quite in line with the internal constant saying "dead". It may well be that Xenstore only cares about the "dead" state, but then it would better be nemaed this way also in the public interface, I think. > + info->unique_id = d->unique_id; > +} > + > +int get_domain_state(struct xen_domctl_get_domain_state *info, struct domain *d, > + domid_t *domid) > +{ > + unsigned int dom; > + > + memset(info, 0, sizeof(*info)); > + > + if ( d ) > + { > + set_domain_state_info(info, d); > + > + return 0; > + } > + > + while ( (dom = find_first_bit(dom_state_changed, DOMID_MASK + 1)) < I can't spot any check that dom_state_changed was actually allocated. Also, unlike the public header comments says, the new sub-op looks to be usable by _anyone_ (eligible privilege-wise) as long as _someone_ did set up the vIRQ. There looks to even be a race possible when a "wrong" caller tries to call this at jut the "right" time. > --- a/xen/common/domctl.c > +++ b/xen/common/domctl.c > @@ -278,6 +278,11 @@ static struct vnuma_info *vnuma_init(const struct xen_domctl_vnuma *uinfo, > return ERR_PTR(ret); > } > > +static bool is_stable_domctl(uint32_t cmd) > +{ > + return cmd == XEN_DOMCTL_get_domain_state; > +} Likely better as switch() from the very beginning. > @@ -866,6 +873,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) > __HYPERVISOR_domctl, "h", u_domctl); > break; > > + case XEN_DOMCTL_get_domain_state: > + ret = xsm_get_domain_state(XSM_XS_PRIV, d); > + if ( ret ) > + break; > + > + copyback = 1; > + ret = get_domain_state(&op->u.get_domain_state, d, &op->domain); > + break; Especially with this being a stable interface, surely the two padding fields want checking to be zero on input (to possibly allow their future use for something input-ish). Then even the memset() in the function may not really be needed. Jan From xen-devel-bounces@lists.xenproject.org Mon Dec 09 17:38:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 17:38:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851767.1265783 (Exim 4.92) (envelope-from ) id 1tKhhu-0003xw-Rz; Mon, 09 Dec 2024 17:38:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851767.1265783; Mon, 09 Dec 2024 17:38: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 1tKhhu-0003xp-Ok; Mon, 09 Dec 2024 17:38:06 +0000 Received: by outflank-mailman (input) for mailman id 851767; Mon, 09 Dec 2024 17:38: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 1tKhht-0003xj-Tw for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 17:38:06 +0000 Received: from EUR02-VI1-obe.outbound.protection.outlook.com (mail-vi1eur02on20625.outbound.protection.outlook.com [2a01:111:f403:2607::625]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 576ddaf0-b654-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 18:38:03 +0100 (CET) Received: from PA4PR04MB9565.eurprd04.prod.outlook.com (2603:10a6:102:26b::13) by AM0PR04MB7156.eurprd04.prod.outlook.com (2603:10a6:208:19b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Mon, 9 Dec 2024 17:37:56 +0000 Received: from PA4PR04MB9565.eurprd04.prod.outlook.com ([fe80::d8ae:2e16:5a97:1709]) by PA4PR04MB9565.eurprd04.prod.outlook.com ([fe80::d8ae:2e16:5a97:1709%5]) with mapi id 15.20.8207.017; Mon, 9 Dec 2024 17:37: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: 576ddaf0-b654-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RxqmTOPAq+IZYf8Z+NY/K1x3FCwXAZXYS4tyWk6Wh6ruV319fZ+AMVGvKtMUZIz1Tf4W6/6zRSM06NnqjfyLUyNFPEufRtGq3DWUfWcRej16qybFdH59eOnK3CdpirYsbdoz9WkK1xsLCJ/J/YE7CN/f1261ijQa+lGX+OJ2MeTnOyuwtBIQ6rXOxDZlqy8ErDIb5glg4ntGYcxLPX2VMjTHNAMfEfcFMN11HlBDDieI9VolP6++iJo/w9/LeRtduE/ay+mle+0W+Y+QMjy4bCeGgYsTTVsO0bSWmE7g0L243lKk/chTU990nI1ELhnok8VC+67nJ3O9EPiG9NrSWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yzxybjhZfS5Xoqr1xkLsFs1MW/KUCSim6B/zXoAdOic=; b=YILJrtxAuFsX0LPo8hPSjCcLm+Q/71JhOCDTshUz5HBcnT0Q5pbaQO2g3Nn2F/TpEI8OY0wrOoAP+fILszKMStdfu7iuE0Xc3jdie80VdvA5oZFBnGSwZ4sgCYm8t5aC7mcVmt/OqcZdg4/m2BXl1QvvffDGx2vPv+kWgr2fuAz5fTmiIZ3slEwoHDda5ZMSd22XgiOPnbjlttq3T+HJytRenNH3eRVBxzB7XbrqIqYVQvL4PV/zvQ1NlzvHpl82qaP2jxUP6Q5XquAekxSigYho9StkS7z41/mnWJh3VOGMwK0NvGrou2dCu3f/Zg9eRT2D9ypAlMcV/SYCUUocuw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com; dkim=pass header.d=oss.nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com; s=selector1-NXP1-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yzxybjhZfS5Xoqr1xkLsFs1MW/KUCSim6B/zXoAdOic=; b=ZBFjnAtRd14+wvWU+bmk89J3AKccTxKWgU7XLzzCjcm7Y6scSbY5DWa/xScWq+jC5BK5kZeSDscI+6t5YGsfBN4/6tQDN2KNKvabOafuXNy+6/iLORbSv+Hc85PTx1cV6Mh9HZrnqGVzl3eDEe68z8vBxCpbmbo2ZUwF1bxn4aiXshSl9AuBx5l0xa+UfYB441T+UUogGNqlWf1gwdBGATLFSDSfU/V/8u28wZXbP6hqy9QxGa7vv/ZmPLy/i5BPAuVjYoF/BgA4sLhVT8F/xh5cqn9Pkx03UdtcefKAwrBbnLc0EG7auQXienlc6aFDywNN44wIrIBi0UBNGN7xbQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=oss.nxp.com; Message-ID: Date: Mon, 9 Dec 2024 19:37:29 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/8] xen/arm: Add SCMI over SMC calls handling layer To: Julien Grall , Grygorii Strashko , xen-devel@lists.xenproject.org Cc: S32@nxp.com, Andrei Cherechesu , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20240930114715.642978-1-andrei.cherechesu@oss.nxp.com> <20240930114715.642978-4-andrei.cherechesu@oss.nxp.com> <59b54859-d893-4bf4-8118-7e4a00e7d87e@epam.com> <3d731902-d5eb-4f63-8501-5ddecf748cb9@xen.org> Content-Language: en-US From: Andrei Cherechesu In-Reply-To: <3d731902-d5eb-4f63-8501-5ddecf748cb9@xen.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM0PR02CA0111.eurprd02.prod.outlook.com (2603:10a6:20b:28c::8) To PA4PR04MB9565.eurprd04.prod.outlook.com (2603:10a6:102:26b::13) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PA4PR04MB9565:EE_|AM0PR04MB7156:EE_ X-MS-Office365-Filtering-Correlation-Id: fd05e4b2-bdf5-436a-4c8a-08dd18783780 X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True 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: =?utf-8?B?bnFGSUorVEJGMWxLWWJsMjJvQUNxOHM0YjFWZzZLN3QwWEg3ZmxFb2pRUnlL?= =?utf-8?B?SXZHdm9yV0VoRmtzcmFIYVpsVzlFSUY0NFJjK1Ira1kyM2M2OUZJNXV1aDEx?= =?utf-8?B?OTFXWlh5Q3BIZzdHQUU4YWUxUnR2Y3FUcEtxdUlFRlpNNlFPaWhBSGc1TXlL?= =?utf-8?B?LzY0bWQxdnRqdVMzbGduckZEN1NUeDlZaHgwbUp0UGxkR2tQWkZYZG1mdU1l?= =?utf-8?B?aHptQ3pDeWovZjJwWHpUeWJNWjJTNW53NFdFTmkwSHhkM2hpQUsvaldZa1Jp?= =?utf-8?B?K3VqWlhRdTNIQlMrNzJFVm5ESmhxS3BJdzkySHk3bnJEQ3hTV2Q5Q1QweElx?= =?utf-8?B?QmMwOUJBeGZDTTZnZmdBTmZQVndjSjZmNEtMNU05RG5GZUFNcnVtU3NqMmhu?= =?utf-8?B?Z3FjVUFlNzU0THpqODNHVUlRVnpOK21zTGVDbFFiVGpDL3lkZjdCZGpIUytF?= =?utf-8?B?R3RZdC9DeWNDWUl6Z3F2R2xjSGxMang1b3cvN3R4ZFhzallwOUVyTzUyN3NZ?= =?utf-8?B?MmpPbmx5dEpxTTdoNFpQM3V6QnV1QXU5amxOeGlEQWNBcGh4QVBHeGUvYVZU?= =?utf-8?B?YjJkcXR6Rk9xbFJOeXpYYnVLRmVYYVBEdVgvRzdyUllYRXJORlZPWE1qSzdV?= =?utf-8?B?ZmMrcExGWTZXTkU4MWR1cm55L3NHemRzaTV3Zy9kZFU4YzBKbDE0U01VamJz?= =?utf-8?B?blVCNnlDYzZBYWFtRTBTaVIwdUg1V1haY3l6RnJoOHQ4YWhDRk5kRkM3UVJS?= =?utf-8?B?YWJJOGhMUm5mdEduaVFtcGVGL3Y2Q3dBV1h4UVQ1WU9za0Fmald5MitBckta?= =?utf-8?B?RzFCUmZ2U0oveVlkSDNGbEpyVUhFY0JKc1VmOXdNQ2phWGY4WWJuWHF3aDBD?= =?utf-8?B?d1pWTWhtckFsNkZUZzU3VjBpUGo5NGRSdU4yVms0NVpuZ1l1MldDUFMzYU5z?= =?utf-8?B?U2tTU0NYdVBYcTBkVmtVUkNFSmRnMVlDdEJMTkx4L3g3K2xWQmJPa2xCanhY?= =?utf-8?B?d3ZxSklIUGtqTzJ2bzloN1dnUXlnUEp1N1RmZHNZVUhXNER2YWpjVnlmRGVE?= =?utf-8?B?VlVJc1JZVTRmYmtiOVBPK1FueFp0Qi9BbmozWTBtRXNKQlU1ajdQWHRUeUdO?= =?utf-8?B?dUx0TkN0Y3lQeDBoT1hKY01jUW9HRDNkUWdRM0xIdGRtWjVnZy9zOXlqd0My?= =?utf-8?B?dU5SZlUxSmUzVDVvRzRDM0tBSEs5eW5ubFNtY0N4UUM4VkxtSFhscENqczV0?= =?utf-8?B?WldDWGJpWGJPc25YTUxEWFBPd0w2a2NLT0taN2pwanlseExJM1RmK05DN0dp?= =?utf-8?B?SkhQUEI2NVNib0Z6dW1UVkJZSnh0UERLYlNTWjhiYmJVTWR1ODAvZWV4Vmp0?= =?utf-8?B?dW9nbDl1WDZid2kyK2FGZGdmS09UL0NFNi9LYytNKzlPaGFTdGJEWEJqUDZh?= =?utf-8?B?REgyb2RJT00xZDY3VDdLUlFTN1pZdzBOT3FJeGRwNXFqaTFZZEtoZkFjTjJi?= =?utf-8?B?T0l5eDZkYk00OXdvUUdSN2xldmJoeTc1d1pnSlVZdFc0aUw3RWVyUnBSU3lo?= =?utf-8?B?OTdKYmlFOVE4T0prSTc1MnFOdnVjeXEydkJsMkJ4bHVESllsKzhIVG0xVEw1?= =?utf-8?B?d011Y1haUE9ib2VtWkZ2NU9iZFBOdHM5SGdqcUd6b2dZNENvRUdSRjh1NWJT?= =?utf-8?B?Tm9UQVFrQUNpZkxvWDBFTHRLT0xscENhM0hndVVhK29sdG45d1g0Rm5xeVdV?= =?utf-8?B?Vk9POS9oTkNEK2VXa1hzck81OE4vWjhEYkVONWxIU0lTWGlBWHVaSXcva2ZN?= =?utf-8?B?L3NkRjN2Uno5VWtrdEJqZz09?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PA4PR04MB9565.eurprd04.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?aXZOSXZoSnoxQ3lEeHNTb05Yb0EwQlFKa1AyaXQrUzRuTlZic2dwQU5mRWhG?= =?utf-8?B?MHZpaHN4S29qdmZESXJBcUhkb0dJQ2czaUNDSkN4YTFrVnRRb3FkaU1HbGRk?= =?utf-8?B?RHpSWGQwRm40WWxlNmNOM1RmeEZIN1duWUZORXZ0cmxEN0svcFM1VmVzZmxS?= =?utf-8?B?UVZlUitTNjBObXNKQlZuQy9lay9NeWpIMU5ycDJjNVNrSmZERFVkNG5mSVJ0?= =?utf-8?B?bWwrYnhhOXRkQlUxR0tnTVE5Vi85MUpiSFNrY3VlN0ZrSlNFMjVqZ2wwRVpP?= =?utf-8?B?dnVyUWhwYU5MbTR5KzNvbWJVcnhVSWljS3JGN2RKWU5Wc3lQU2lLb3IrbDZD?= =?utf-8?B?Sk5zYWE5TjlwdkpBMG9sOE0vdFhJVCtYYmtrai9iWlVwMm9PRjM5Q0Nzckpz?= =?utf-8?B?K2VVU29nUE1PWmQvaGM2Q0V1ZnJRWTlUb1dNT09RLzMvWlkyamRmTWF1V3VB?= =?utf-8?B?NFdHTE8rQTloeVdPOEg4bFIzckwveXVxZC9tOUZiSlJ3ek5GU29DOVExdUE4?= =?utf-8?B?SHYxNCticE82U1Yzblk4UU84RGNsekFKaXlURGtlWDcwUit2eWsxQzdRUmVJ?= =?utf-8?B?SjJjdnFJc2hrYk80emp0ZGJxb0NNakczeTBaMkJOUFpLcnorVU94MzRUdnhH?= =?utf-8?B?UHBhTUU3UEdpZzFRUkdLYTBUazZvaWFmU3FCU280a1I1akxsRFFUKytFRHhv?= =?utf-8?B?dlhiTFljRVRBc2xmSlJaU3J6Tm94YTFnanJmSGlJUGpnV3RMeDIySk1STUcr?= =?utf-8?B?QXdURjRZK2VhNklZYlVWcHB6UFQxdUpGbmxvV1ZZbjA0WmNWdDRyVSthemNO?= =?utf-8?B?T3Jtc1lrZUhKbGUyMVVUME1ENlZRcnNJMjA2Z0phSUpQTk45dlBXejNScHZU?= =?utf-8?B?Vm9USUE0N292MHpXQ1drYk16K1hVV2ZVaGFLd3pHOWxnUUpGenFYaHBKWWtC?= =?utf-8?B?aGkyeVFMV2lTVUNmVkk1Z2gzTHk4N1VuWStRTkVEM0tJR1RLdVFnM2c3Y0Q2?= =?utf-8?B?SHVhcERJQmxVV1VjZDVyR1dGTlVwRnJLK0ZyYmthNW0rZ1ZpRFo5MkxQeGFF?= =?utf-8?B?WWtYdzlHUFJIVG9yWDZaUnRnbUx0aEFta1EzZ3NKcHpOUGVoNjgxUHdwVTJh?= =?utf-8?B?Sy9ZVkRCV1JGV09Wa2lvRW5zVnN6ZjM5RWt6d0xsTS9JemxUU29lMitQdHB0?= =?utf-8?B?WExxVk81b2RkRyt5NGtib1A5YjNLbTlDZXJpekUxTGF0RFJmZUJaSnNpVDBL?= =?utf-8?B?RFBtK2lwNDZxNUVBdHBkWitySG9PUGpsUEYvQ3MybEVNdkdOSFFLVVVZUmNj?= =?utf-8?B?OFpqcHo4VjlVZElhalk2V2xEa1RuOG1nNm1SK3pKNXZBakg4Y01OSDd6V3RM?= =?utf-8?B?bmRyeVNhTFdXeHNsSmNyNnA5S0hheXhKWU0wTjV5M1RwU0ZOREptaDRHWWov?= =?utf-8?B?WVpMSHJKQUgrSXhlU1dhODBpWHEyR001alFYYW1rNmFTYWp6elRRS3RtWW1U?= =?utf-8?B?aWUrK3I1UWRyaS9LazhSN0xNSUo2VjZZOXZDdHdFVFg0T1NJdHpzK0JkYjVk?= =?utf-8?B?ejJ2WkJicjEwRUNiazhXWklkbzZBYWZScDBtQ3ZOd2FHL0RCU2tIZ1ErVUpl?= =?utf-8?B?enErMGZNSG9sbUl0T2pSeGJzbDJkMW01MTR0WlUybnYxRDg0YVgrT0pFd3Fs?= =?utf-8?B?eG9BYWpmSGRwRnQ0RG5pZjlIM3l2M0xvWGI1QTFmQ2RwMU9PRTA4U0Z4ZUpF?= =?utf-8?B?alhYK1JLVDdHTzJvT1hmTWM0L09NdXcxZm04bzdxWlQraUpwZ2JZb0JURXhU?= =?utf-8?B?UG9DM2pGUmZWNktBd3RwR3pRV2xybWlVMllDM216VzhtVmo5elkrQmlLZCtL?= =?utf-8?B?THQ1TzQ1L0lhMjZZRXhTbXV3SGdHdTdUZmNPOW9lTTN2TUtTWUg4NzF6ZFo3?= =?utf-8?B?M2pscjRZSHdIY1A5NDMwMlNUUTdmWFF1QjN4UlU1Qm5MYzIyeUxnN2s3ZTUw?= =?utf-8?B?K2dyMEdLMWN4blNqYVdLdmJWS0NjRVNPVWhHL3pLd3VURmFzdFpnb3lsOVph?= =?utf-8?B?bUJXL041V0VaakUyeFBsNzdnZEJuNGxXMUFMMCtsd3pwZmY1YXRiLzRUajEz?= =?utf-8?B?NmJtckdlc0NlVVhWd0VpRy9XNmRqWTFDd2FlYXp4Y2VUL0dCNjViVTV5bGFw?= =?utf-8?B?UUE9PQ==?= X-OriginatorOrg: oss.nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: fd05e4b2-bdf5-436a-4c8a-08dd18783780 X-MS-Exchange-CrossTenant-AuthSource: PA4PR04MB9565.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Dec 2024 17:37:56.5608 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: EKsLKiMV4vQ6L/YFwASJzg+F0/a3AlaX0+BlbjV7qMNizPwwAvopxhSpmF5sF49+YRYSYy8oeniOKOj6WooiLZDWShfnKzJaPuWXceKNggk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR04MB7156 Hi Julien, Grygorii, On 11/11/2024 12:33, Julien Grall wrote: > Hi, > > On 01/11/2024 15:22, Grygorii Strashko wrote: >> Hi >> >> I'd be apprcieated if could consider my comments below. >> >> On 30.09.24 14:47, Andrei Cherechesu (OSS) wrote: >>> From: Andrei Cherechesu >>> >>> Introduce the SCMI layer to have some basic degree of awareness >>> about SMC calls that are based on the ARM System Control and >>> Management Interface (SCMI) specification (DEN0056E). >>> >>> The SCMI specification includes various protocols for managing >>> system-level resources, such as: clocks, pins, reset, system power, >>> power domains, performance domains, etc. The clients are named >>> "SCMI agents" and the server is named "SCMI platform". >>> >>> Only support the shared-memory based transport with SMCs as >>> the doorbell mechanism for notifying the platform. Also, this >>> implementation only handles the "arm,scmi-smc" compatible, >>> requiring the following properties: >>>     - "arm,smc-id" (unique SMC ID) >>>     - "shmem" (one or more phandles pointing to shmem zones >>>     for each channel) >>> >>> The initialization is done as 'presmp_initcall', since we need >>> SMCs and PSCI should already probe EL3 FW for supporting SMCCC. >>> If no "arm,scmi-smc" compatible node is found in Dom0's >>> DT, the initialization fails silently, as it's not mandatory. >>> Otherwise, we get the 'arm,smc-id' DT property from the node, >>> to know the SCMI SMC ID we handle. The 'shmem' memory ranges >>> are not validated, as the SMC calls are only passed through >>> to EL3 FW if coming from Dom0 and as if Dom0 would be natively >>> running. >>> >>> Signed-off-by: Andrei Cherechesu >>> Reviewed-by: Stefano Stabellini >>> --- >>>   xen/arch/arm/Kconfig                |  10 ++ >>>   xen/arch/arm/Makefile               |   1 + >>>   xen/arch/arm/include/asm/scmi-smc.h |  52 +++++++++ >>>   xen/arch/arm/scmi-smc.c             | 163 ++++++++++++++++++++++++++++ >> >> Could it be moved in separate folder - for example "sci" or "firmware"? >> There are definitely more SCMI specific code will be added in the future >> as this solution is little bit too simplified. >> >>>   4 files changed, 226 insertions(+) >>>   create mode 100644 xen/arch/arm/include/asm/scmi-smc.h >>>   create mode 100644 xen/arch/arm/scmi-smc.c >>> >>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig >>> index 323c967361..adf53e2de1 100644 >>> --- a/xen/arch/arm/Kconfig >>> +++ b/xen/arch/arm/Kconfig >>> @@ -245,6 +245,16 @@ config PARTIAL_EMULATION >>>         not been emulated to their complete functionality. Enabling this might >>>         result in unwanted/non-spec compliant behavior. >>> +config SCMI_SMC >> >> Could you please rename it to clearly specify that it is only dom0/hwdom >> specific? Like SCMI_SMC_DOM0 or SCMI_SMC_HW_DOM. > > I expect this series to be just a stop gap until we support SCMI for the VMs. Once this is merge, I don't expect we would want to keep a Kconfig to allow SCMI just for dom0. Therefore, I am not entirely convinced the proposed new name is a good idea. AFAIU, Julien, you don't agree with renaming the config, nor with moving the support to a separate folder since it's something temporary? That's my view as well. These changes do not introduce support for a layer of mediators for interacting with system firmware, but only for one simplified implementation. So I suppose the patch set that adds that support also creates the folder (named 'sci' - per Gregorii's proposal - or 'firmware' to align with Linux), and the required config. But I'm up for doing whatever you consider more suitable. > > >> >>> +    bool "Enable forwarding SCMI over SMC calls from Dom0 to EL3 firmware" >>> +    default y >>> +    help >>> +      This option enables basic awareness for SCMI calls using SMC as >>> +      doorbell mechanism and Shared Memory for transport ("arm,scmi-smc" >>> +      compatible only). The value of "arm,smc-id" DT property from SCMI >>> +      firmware node is used to trap and forward corresponding SCMI SMCs >>> +      to firmware running at EL3, if the call comes from Dom0. >>> + >>>   endmenu >>>   menu "ARM errata workaround via the alternative framework" >>> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile >>> index 7792bff597..b85ad9c13f 100644 >>> --- a/xen/arch/arm/Makefile >>> +++ b/xen/arch/arm/Makefile >>> @@ -45,6 +45,7 @@ obj-y += platform_hypercall.o >>>   obj-y += physdev.o >>>   obj-y += processor.o >>>   obj-y += psci.o >>> +obj-$(CONFIG_SCMI_SMC) += scmi-smc.o >>>   obj-y += setup.o >>>   obj-y += shutdown.o >>>   obj-y += smp.o >>> diff --git a/xen/arch/arm/include/asm/scmi-smc.h b/xen/arch/arm/ include/asm/scmi-smc.h >>> new file mode 100644 >>> index 0000000000..c6c0079e86 >>> --- /dev/null >>> +++ b/xen/arch/arm/include/asm/scmi-smc.h >>> @@ -0,0 +1,52 @@ >>> +/* SPDX-License-Identifier: GPL-2.0-or-later */ >>> +/* >>> + * xen/arch/arm/include/asm/scmi-smc.h >>> + * >>> + * ARM System Control and Management Interface (SCMI) over SMC >>> + * Generic handling layer >>> + * >>> + * Andrei Cherechesu >>> + * Copyright 2024 NXP >>> + */ >>> + >>> +#ifndef __ASM_SCMI_SMC_H__ >>> +#define __ASM_SCMI_SMC_H__ >>> + >>> +#include >>> +#include >>> + >>> +#ifdef CONFIG_SCMI_SMC >>> + >>> +bool scmi_is_enabled(void); >>> +bool scmi_is_valid_smc_id(uint32_t fid); >>> +bool scmi_handle_smc(struct cpu_user_regs *regs); >>> + >>> +#else >>> + >>> +static inline bool scmi_is_enabled(void) >>> +{ >>> +    return false; >>> +} >>> + >>> +static inline bool scmi_is_valid_smc_id(uint32_t fid) >>> +{ >>> +    return false; >>> +} >>> + >>> +static inline bool scmi_handle_smc(struct cpu_user_regs *regs) >> >> I propose to add "struct domain *d" as the first parameter to make it >> more abstract from Xen internals. > > I am not sure to understand why we would want the call to be more abstract. This function should *only* act on the vCPU currently loaded. So it makes sense to use "current->domain". So this should stay the same, right? @Grygorii, Regarding `scmi_is_valid_smc_id()`, I will make it private to the SCMI-SMC driver. And regarding squashing [v2,4/8] to [v2,3/8], IMO it is clearer this way: to have the implementation of the driver in a different commit than the usage/refactorings needed to accomodate it. And this makes it easier to revert the behaviour too, eventually. But I don't have a strong preference on this and I'm open to squash the commits if you believe it is better that way. > > Cheers, > Regards, Andrei Cherechesu From xen-devel-bounces@lists.xenproject.org Mon Dec 09 17:42:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 17:42:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851778.1265793 (Exim 4.92) (envelope-from ) id 1tKhls-0005lv-BD; Mon, 09 Dec 2024 17:42:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851778.1265793; Mon, 09 Dec 2024 17:42:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKhls-0005lo-82; Mon, 09 Dec 2024 17:42:12 +0000 Received: by outflank-mailman (input) for mailman id 851778; Mon, 09 Dec 2024 17:42: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 1tKhlr-0005li-6b for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 17:42:11 +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 e9e70dfd-b654-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 18:42:09 +0100 (CET) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5d122cf8dd1so7582947a12.2 for ; Mon, 09 Dec 2024 09:42:09 -0800 (PST) Received: from localhost ([217.156.233.154]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d3cf972f6dsm4800685a12.61.2024.12.09.09.42.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 09:42: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: e9e70dfd-b654-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1733766128; x=1734370928; darn=lists.xenproject.org; h=in-reply-to:references:subject:cc:to:from:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=sV0nsyX7vNkVSSafZpbxwKnujh7zQJgvV3AwYvXfYk8=; b=IK1cx1hnrneSudPGUHnWjRsz0hZKiwPS0lH2tBN3Q0V/b1KiPLiBPsZk9a0l04rQ2D I5H65UF/SBRCfE2UookpmB1JtwPfImh/RfNRihejA7aYpyTO66ec9XDmQfCVEWETJMgC IxMahf2OylNWoHaK9OaOsZNZkqGlyIaTHOBXI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733766128; x=1734370928; h=in-reply-to:references:subject:cc:to:from:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=sV0nsyX7vNkVSSafZpbxwKnujh7zQJgvV3AwYvXfYk8=; b=m7ZmmPFueF/JLzx/J/AIrTczprDZQR+9lpM/Yb4V/8dd7Dj191dg4cqUW4ZCmY6BJE otilgEAoLRWThagrPA2LbR5RlRdVpJ9qBxXGmPNyg1laxK86GipxjazTBTxnJUHEafcF Fa9hPOmvJPqoMzZpvJE/HkUKn/PrCgmaUUsCXWpD6E3ZToijv9Gp/FVQcLjP5QmR7js8 tXsearEkKkk1CWZ9athGeL9Ouc+3r/4CuA88f9eZxvmcNXe9Xs7QxXqlTOOP/GT+GKpn sB52VkXTvZ4nwR1MPWfsKOHHjy/ZqTXe8fN/vTL/Qk8+ah7IDaU75bkoqXLGx7X+ZCaM igZA== X-Forwarded-Encrypted: i=1; AJvYcCWtktXCqox7AN/6BjhPU3Ojk8KZ1ujJazhfPOzHpM5ZZ9qoMRqbM2TI9RuYiRg/oopbfONoZkx7ENM=@lists.xenproject.org X-Gm-Message-State: AOJu0YwVJcGbvTbaTLLEk6KYG0F17UiuPdiqmB3ygy1fNzoxb3qo30kW wFnAFyusSBzgHzCu9XvEqeDyklaNmgZCLskNhHbg7I2KCEBGj5MXwI/GY69LDrM= X-Gm-Gg: ASbGncvKzgZAI0GpnkKq7FJcE5lgzSGrod9suVXXS+8r5TGNfe5QZlGJuCtx//6Urzo z+hZ5aLazxZ0nbdgutig3L5vHEWTfiaIJ9rUTwzwnGpaE/ugoDjSfZ4ORbNT85W2e2MWEDu9CuO SUNfqNSAHiacghsIWpYMC6t/jQpWl3jPfUSj39Ar/qs1cBBuNUR6DvYZZzwGDZxypYgKa6qM9pY i/cpq2nfscRcYRRcQiXLIquL99zRiJZj+mjHoKCFgORHqRJj+hLZ3pJbhQ= X-Google-Smtp-Source: AGHT+IF5hpIyBgq5/JEjJxGu/gxd9cGo73IjdSD6QZUN/lnxjOGyvV5Sh9hQwuBebEbdUYuhZ2RjPw== X-Received: by 2002:a05:6402:3715:b0:5d0:ed71:3ce4 with SMTP id 4fb4d7f45d1cf-5d3be661883mr14529848a12.6.1733766128444; Mon, 09 Dec 2024 09:42:08 -0800 (PST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 09 Dec 2024 17:42:06 +0000 Message-Id: From: "Alejandro Vallejo" To: "Elias El Yandouzi" , Cc: , , , "Hongyan Xia" , "Julien Grall" Subject: Re: [PATCH V4 03/15] x86/pv: Rewrite how building PV dom0 handles domheap mappings X-Mailer: aerc 0.18.2 References: <20241111131148.52568-1-eliasely@amazon.com> <20241111131148.52568-4-eliasely@amazon.com> In-Reply-To: <20241111131148.52568-4-eliasely@amazon.com> Hi, I've been trying to run this series for a while, but it crashes very frequentyly starting from the patch that generalizes the mapcache. I think = I've tracked it down to this patch. On Mon Nov 11, 2024 at 1:11 PM GMT, Elias El Yandouzi wrote: > From: Hongyan Xia > > Building a PV dom0 is allocating from the domheap but uses it like the > xenheap. Use the pages as they should be. > > Signed-off-by: Hongyan Xia > Signed-off-by: Julien Grall > Signed-off-by: Elias El Yandouzi > > ---- > Changes in V4: > * Reduce the scope of l{1,2,4}start_mfn variables > * Make the macro `UNMAP_MAP_AND_ADVANCE` return the new virtual a= ddress > > Changes in V3: > * Fold following patch 'x86/pv: Map L4 page table for shim domain= ' > > Changes in V2: > * Clarify the commit message > * Break the patch in two parts > > Changes since Hongyan's version: > * Rebase > * Remove spurious newline > > diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c > index 18b7a3e4e025..b03df609cadb 100644 > --- a/xen/arch/x86/pv/dom0_build.c > +++ b/xen/arch/x86/pv/dom0_build.c > @@ -382,6 +382,7 @@ static int __init dom0_construct(struct domain *d, > l3_pgentry_t *l3tab =3D NULL, *l3start =3D NULL; > l2_pgentry_t *l2tab =3D NULL, *l2start =3D NULL; > l1_pgentry_t *l1tab =3D NULL, *l1start =3D NULL; > + mfn_t l3start_mfn =3D INVALID_MFN; > =20 > /* > * This fully describes the memory layout of the initial domain. All > @@ -719,22 +720,34 @@ static int __init dom0_construct(struct domain *d, > v->arch.pv.event_callback_cs =3D FLAT_COMPAT_KERNEL_CS; > } > =20 > +#define UNMAP_MAP_AND_ADVANCE(mfn_var, virt_var, maddr) ({ \ > + do { \ > + unmap_domain_page(virt_var); \ > + mfn_var =3D maddr_to_mfn(maddr); \ > + maddr +=3D PAGE_SIZE; \ > + virt_var =3D map_domain_page(mfn_var); \ > + } while ( false ); \ > + virt_var; \ > +}) > + > if ( !compat ) > { > + mfn_t l4start_mfn; > maddr_to_page(mpt_alloc)->u.inuse.type_info =3D PGT_l4_page_tabl= e; > - l4start =3D l4tab =3D __va(mpt_alloc); mpt_alloc +=3D PAGE_SIZE; > + l4tab =3D UNMAP_MAP_AND_ADVANCE(l4start_mfn, l4start, mpt_alloc)= ; In here l4start is mapped on the idle domain perdomain area, but... > clear_page(l4tab); > - init_xen_l4_slots(l4tab, _mfn(virt_to_mfn(l4start)), > - d, INVALID_MFN, true); > - v->arch.guest_table =3D pagetable_from_paddr(__pa(l4start)); > + init_xen_l4_slots(l4tab, l4start_mfn, d, INVALID_MFN, true); > + v->arch.guest_table =3D pagetable_from_mfn(l4start_mfn); > } > else > { > /* Monitor table already created by switch_compat(). */ > - l4start =3D l4tab =3D __va(pagetable_get_paddr(v->arch.guest_tab= le)); > + mfn_t l4start_mfn =3D pagetable_get_mfn(v->arch.guest_table); > + l4start =3D l4tab =3D map_domain_page(l4start_mfn); > /* See public/xen.h on why the following is needed. */ > maddr_to_page(mpt_alloc)->u.inuse.type_info =3D PGT_l3_page_tabl= e; > l3start =3D __va(mpt_alloc); mpt_alloc +=3D PAGE_SIZE; > + UNMAP_MAP_AND_ADVANCE(l3start_mfn, l3start, mpt_alloc); > } > =20 > l4tab +=3D l4_table_offset(v_start); > @@ -743,15 +756,17 @@ static int __init dom0_construct(struct domain *d, > { > if ( !((unsigned long)l1tab & (PAGE_SIZE-1)) ) > { > + mfn_t l1start_mfn; > maddr_to_page(mpt_alloc)->u.inuse.type_info =3D PGT_l1_page_= table; > - l1start =3D l1tab =3D __va(mpt_alloc); mpt_alloc +=3D PAGE_S= IZE; > + l1tab =3D UNMAP_MAP_AND_ADVANCE(l1start_mfn, l1start, mpt_al= loc); > clear_page(l1tab); > if ( count =3D=3D 0 ) > l1tab +=3D l1_table_offset(v_start); > if ( !((unsigned long)l2tab & (PAGE_SIZE-1)) ) > { > + mfn_t l2start_mfn; > maddr_to_page(mpt_alloc)->u.inuse.type_info =3D PGT_l2_p= age_table; > - l2start =3D l2tab =3D __va(mpt_alloc); mpt_alloc +=3D PA= GE_SIZE; > + l2tab =3D UNMAP_MAP_AND_ADVANCE(l2start_mfn, l2start, mp= t_alloc); > clear_page(l2tab); > if ( count =3D=3D 0 ) > l2tab +=3D l2_table_offset(v_start); > @@ -761,19 +776,19 @@ static int __init dom0_construct(struct domain *d, > { > maddr_to_page(mpt_alloc)->u.inuse.type_info =3D > PGT_l3_page_table; > - l3start =3D __va(mpt_alloc); mpt_alloc +=3D PAGE= _SIZE; > + UNMAP_MAP_AND_ADVANCE(l3start_mfn, l3start, mpt_= alloc); > } > l3tab =3D l3start; > clear_page(l3tab); > if ( count =3D=3D 0 ) > l3tab +=3D l3_table_offset(v_start); > - *l4tab =3D l4e_from_paddr(__pa(l3start), L4_PROT); > + *l4tab =3D l4e_from_mfn(l3start_mfn, L4_PROT); > l4tab++; > } > - *l3tab =3D l3e_from_paddr(__pa(l2start), L3_PROT); > + *l3tab =3D l3e_from_mfn(l2start_mfn, L3_PROT); > l3tab++; > } > - *l2tab =3D l2e_from_paddr(__pa(l1start), L2_PROT); > + *l2tab =3D l2e_from_mfn(l1start_mfn, L2_PROT); > l2tab++; > } > if ( count < initrd_pfn || count >=3D initrd_pfn + PFN_UP(initrd= _len) ) > @@ -792,27 +807,32 @@ static int __init dom0_construct(struct domain *d, > =20 > if ( compat ) > { > - l2_pgentry_t *l2t; > - > /* Ensure the first four L3 entries are all populated. */ > for ( i =3D 0, l3tab =3D l3start; i < 4; ++i, ++l3tab ) > { > if ( !l3e_get_intpte(*l3tab) ) > { > + mfn_t l2start_mfn; > maddr_to_page(mpt_alloc)->u.inuse.type_info =3D PGT_l2_p= age_table; > - l2tab =3D __va(mpt_alloc); mpt_alloc +=3D PAGE_SIZE; > - clear_page(l2tab); > - *l3tab =3D l3e_from_paddr(__pa(l2tab), L3_PROT); > + UNMAP_MAP_AND_ADVANCE(l2start_mfn, l2start, mpt_alloc); > + clear_page(l2start); > + *l3tab =3D l3e_from_mfn(l2start_mfn, L3_PROT); > } > if ( i =3D=3D 3 ) > l3e_get_page(*l3tab)->u.inuse.type_info |=3D PGT_pae_xen= _l2; > } > =20 > - l2t =3D map_l2t_from_l3e(l3start[3]); > - init_xen_pae_l2_slots(l2t, d); > - unmap_domain_page(l2t); > + UNMAP_DOMAIN_PAGE(l2start); > + l2start =3D map_l2t_from_l3e(l3start[3]); > + init_xen_pae_l2_slots(l2start, d); > } > =20 > +#undef UNMAP_MAP_AND_ADVANCE > + > + UNMAP_DOMAIN_PAGE(l1start); > + UNMAP_DOMAIN_PAGE(l2start); > + UNMAP_DOMAIN_PAGE(l3start); ... l4start is not unmapped here. This is a problem, because we're about to change the page tables into dom0's and start using its mapcache. IMO, we should be unmapping here, and remapping in dom0's context. Otherwis= e l4start becomes a transiently stale pointer. Any remaining pointer obtained= via map_domain_page() is a dangling pointer after the mapcache+pagetable switch= . > + > /* Pages that are part of page tables must be read only. */ > mark_pv_pt_pages_rdonly(d, l4start, vpt_start, nr_pt_pages, &flush_f= lags); > =20 > @@ -987,6 +1007,8 @@ static int __init dom0_construct(struct domain *d, > pv_shim_setup_dom(d, l4start, v_start, vxenstore_start, vconsole= _start, > vphysmap_start, si); > =20 > + UNMAP_DOMAIN_PAGE(l4start); As it is, this unmap is operating on the wrong mapcache, I think. I don't q= uite understand why I see intermittent boot crashes and not constant ones, but t= his seems like a bug. What we want, I think, is: 1. Increase the scope of l4start_mfn to be function-level. 2. Do UNMAP_DOMAIN_PAGE(l4start) along with l1start, l2start and l3start. 3. Include a pair of map_domain_page() and UNMAP_DOMAIN_PAGE() within the conditional, surrounding pv_shim_setup_dom. > + > #ifdef CONFIG_COMPAT > if ( compat ) > xlat_start_info(si, pv_shim ? XLAT_start_info_console_domU I'll keep testing it in case I missed something, but this seems to work. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Mon Dec 09 17:58:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 17:58:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851795.1265809 (Exim 4.92) (envelope-from ) id 1tKi1E-0007qr-2f; Mon, 09 Dec 2024 17:58:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851795.1265809; Mon, 09 Dec 2024 17: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 1tKi1D-0007qk-Sv; Mon, 09 Dec 2024 17:58:03 +0000 Received: by outflank-mailman (input) for mailman id 851795; Mon, 09 Dec 2024 17: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 1tKi1C-0007nO-PI for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 17:58:02 +0000 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [2a00:1450:4864:20::629]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2178b8c1-b657-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 18:58:01 +0100 (CET) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a9f1c590ecdso852409566b.1 for ; Mon, 09 Dec 2024 09:58:01 -0800 (PST) Received: from CSGPROD238885.citrite.net (cpc92320-cmbg19-2-0-cust1786.5-4.cable.virginm.net. [82.13.70.251]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa66c646e64sm353428266b.25.2024.12.09.09.57.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2024 09:58: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: 2178b8c1-b657-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1733767080; x=1734371880; 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=YerkWU1ZVB8kQItSuG2bqWDj4eonv2Uu+iny4UeDLCk=; b=ZUfIzAbjOZu1gtjSELpYWz5BYFVdkSGDNIDJ9ZMF5J7kpYti6+eA30xqD43HAgzAEz rSgvg8RvxbP38d8YCnxNkbPfwUNG9nWZRSSS91QVl2YXs0/PB9UKayVRcmGvRx76PF/w lhp8gi88yPLbG6zwYRB4i79+jyT1UZ3Xh8nM0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733767080; x=1734371880; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YerkWU1ZVB8kQItSuG2bqWDj4eonv2Uu+iny4UeDLCk=; b=WZAMwBv9Xch4QZK/IPxnYufEWHq9NAH/nLT4jjwE/+Jz5gQN2kTzrSJmNqcFHrJ3WP kL0ZYMi+33HhzSLMzCst9N/AJytjzV8ePqVXOliwNMUq+j6MO+hNGbYgSsQEBT7UbXcI iuFAFD9YHZ3LF2HaRIQM7yO608J8iegtAwndaJbosYJjP5xVDpunlfPTqW/MfkQk/WwX 4JPhmbP3v9pb8ILilxkxyxKKMnOyBN7LMJFf3djxB8VCLwugySpCVNXMiWvrYShjGEED gieiPsjgiqAZPiW+uvukhkUhSZvPgNznf+CfxasMXDIdQqLnqmKisVbIlPnDuyJvZPO3 Dfbg== X-Gm-Message-State: AOJu0Yw80OHJ1hT3h9WpHcIPoCUgeKjmkoc438ik4DbFVt66kiB2z70g sCg6OwVefBRUdGhOxBxdwqPQXxTO1EVN2ED2LPvVXVc0TqSLO4VIl/cpLPIOgXTA7BzMUZncZ99 + X-Gm-Gg: ASbGncteSpaXQZV2pOSrI+Hg4I4lAbLG+rCjJL3nsiPS5JaLe65RdPanBrQXHJ/NDZq /f1o+F9YKgmy7+M9nh6hpvNDYr3XBrUkcYvmUxPFCBk6mYE56/iN/Q/HWr3Rc/lH090d6EzW9FN KBitd7WllU+lwdlMQo5bm0w13uKSRlSF8uVHEA6wSHohgWXP1fENThJxgIcPl11u9+cuvpB58x0 jiPRgVnCABhYSUtJL3SUXigX3WMXcq3dLw51EDiXY2Tvp/J+wfeV6nthDBvoDW6VJVYO9HyAeID guMbv7CDT0wliWSbv1o6EHUALV63P8OQ+ZuxHuQSbfNGULapqiY3OYF4skkW X-Google-Smtp-Source: AGHT+IEogXZhboHVMPmdjZ8yCiLJxlJzcc3LoD1MI9vI4Je9KBT2G3r487MOZujzsYqPvjKBfQN34g== X-Received: by 2002:a17:907:619f:b0:aa6:6696:4072 with SMTP id a640c23a62f3a-aa69ce89910mr131820466b.49.1733767080410; Mon, 09 Dec 2024 09:58:00 -0800 (PST) From: Andrii Sultanov To: xen-devel@lists.xenproject.org Cc: Andrii Sultanov , Christian Lindig , David Scott , Anthony PERARD , Fernando Rodrigues , Christian Lindig Subject: [PATCH v2 1/1] tools/ocaml: Specify rpath correctly for ocamlmklib Date: Mon, 9 Dec 2024 17:57:49 +0000 Message-Id: X-Mailer: git-send-email 2.39.5 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ocamlmklib has special handling for C-like '-Wl,-rpath' option, but does not know how to handle '-Wl,-rpath-link', as evidenced by warnings like: "Unknown option -Wl,-rpath-link=$HOME/xen/tools/ocaml/libs/eventchn/../../../../tools/libs/toollog" Pass this option directly to the compiler with -ccopt instead. Also pass -L directly to the linker with -ldopt. This prevents embedding absolute paths from buildtime into binary's RPATH. Fixes: f7b4e4558b42 ("tools/ocaml: Fix OCaml libs rules") Reported-by: Fernando Rodrigues Tested-by: Fernando Rodrigues Signed-off-by: Andrii Sultanov Acked-by: Christian Lindig --- Changes in v2: - Pass -L directly to the linker --- tools/ocaml/Makefile.rules | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/ocaml/Makefile.rules b/tools/ocaml/Makefile.rules index b9d4b51f0a..43f7add072 100644 --- a/tools/ocaml/Makefile.rules +++ b/tools/ocaml/Makefile.rules @@ -63,7 +63,7 @@ mk-caml-lib-bytecode = $(call quiet-command, $(OCAMLC) $(OCAMLCFLAGS) -a -o $1 $ mk-caml-stubs = $(call quiet-command, $(OCAMLMKLIB) -o `basename $1 .a` $2,MKLIB,$1) mk-caml-lib-stubs = \ - $(call quiet-command, $(OCAMLMKLIB) -o `basename $1 .a | sed -e 's/^lib//'` $2 $3,MKLIB,$1) + $(call quiet-command, $(OCAMLMKLIB) -o `basename $1 .a | sed -e 's/^lib//'` $2 `echo $3 | sed -e 's/-ccopt -l/-l/g' | sed -e 's/-ccopt -L/-ldopt -L/g'`,MKLIB,$1) # define a library target .cmxa and .cma define OCAML_LIBRARY_template @@ -74,7 +74,7 @@ define OCAML_LIBRARY_template $(1)_stubs.a: $(foreach obj,$$($(1)_C_OBJS),$(obj).o) $(call mk-caml-stubs,$$@, $$+) lib$(1)_stubs.a: $(foreach obj,$($(1)_C_OBJS),$(obj).o) - $(call mk-caml-lib-stubs,$$@, $$+, $(foreach lib,$(LIBS_$(1)),$(lib))) + $(call mk-caml-lib-stubs,$$@, $$+, $(foreach lib,$(LIBS_$(1)),-ccopt $(lib))) endef # Dynamically linked OCaml libraries ("plugins" in Dynlink parlance) -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Dec 09 17:58:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 17:58:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851794.1265804 (Exim 4.92) (envelope-from ) id 1tKi1D-0007ng-Ph; Mon, 09 Dec 2024 17:58:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851794.1265804; Mon, 09 Dec 2024 17:58: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 1tKi1D-0007nZ-LB; Mon, 09 Dec 2024 17:58:03 +0000 Received: by outflank-mailman (input) for mailman id 851794; Mon, 09 Dec 2024 17:58: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 1tKi1B-0007nO-Sj for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 17:58:01 +0000 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [2a00:1450:4864:20::633]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2091f904-b657-11ef-99a3-01e77a169b0f; Mon, 09 Dec 2024 18:57:59 +0100 (CET) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-aa67ac42819so255780366b.0 for ; Mon, 09 Dec 2024 09:57:59 -0800 (PST) Received: from CSGPROD238885.citrite.net (cpc92320-cmbg19-2-0-cust1786.5-4.cable.virginm.net. [82.13.70.251]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa66c646e64sm353428266b.25.2024.12.09.09.57.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2024 09:57: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: 2091f904-b657-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1733767079; x=1734371879; 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=vvxsWYZGY25rWK0i2gMHKsDthRQUDhGDBPCU5tlH/5o=; b=H3f8xmEtMzDPzswLnRAm/m1up6tGAWUmUB+lUxZUVXtGyH4zzQLBfboaWCl4OVC6X9 TPM+dRwRbzKC6lgF6rB15PeIZth33+w5QP3/W0i1CGydE1wcIrmRZYsU0UzltJTV6BAN L9eRfisi3IfvhvYHUlTOlSj/kdikWL6nXosPA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733767079; x=1734371879; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vvxsWYZGY25rWK0i2gMHKsDthRQUDhGDBPCU5tlH/5o=; b=SMNGdhdvdfgPKuGJeKop5Q+Zrhyzo5WvL3vh/Ef1eMBHtOqDBEVbev3iUGyJ/v78oo fqN3JUMVLJFP+hn5FG3MrIYqWoVUzIOcHTTJCHbD5nymmaEe98sdZbYuadwmKF9RNWrv b6+XJhjREx1NY92nNyhsOvW5kAABwsmCjp0F6rMpxD8z0nj4rEicesU3Ivt3FVc64Cfm AI/mGZC0JMY0e6K46J9NgHo79D3jUtaVBaf5Jj2T7yEZPESFBntfBqTlcFsdrMsmQd0Z TLwSVTBLsiaSTG2SI6CkJONdxuzzaI01P608kBhBAgS/ITX5qkyszZCRu2ywuk/Pxdsu poBA== X-Gm-Message-State: AOJu0Yz8xxgEBzBdDK2zS9Ff62BsJ0w8TENUlREdJyTz6MKHT0FbOQzM wDS72QhyVsLNY7Ayl+XM/x8Vu9PVZCRXjM2yX5HF4ctqL9a+RREznzbCjoXgiHaaC2s9OLPuogo 5 X-Gm-Gg: ASbGncs4Exz8Y2WLMuvIbNQfd+ZjYxWkF5wjTNX75E8pDmPeyRjYvdFmGx1r7f/byr7 gETWc8NNhMAc3IjlzU9AlsH6kMoCE6q6r8dYt3VUvFLXThkxDtkw9R/R6TaYYWeZfsQTFglUozr yUvSkz1JiMd2ozA0U3jocR8VcJCSH2De5Dx2o3HuSjJZ2nWHuvTk1n/pemlA7Lg5bnmlHcEGkbP eX1pilKBJT44EV9RS/aWbPiqBolEG3Aopk3TF6gc2PyydCUrgzxC0dSvV3pv7W8c60QAYrSREM0 Ead8fR7t4Gq3NX/Zi6sAgJ1pSsWAMVs8eL7l8l3w6P6pqbF5Z/ZRcj7Mory3 X-Google-Smtp-Source: AGHT+IGZvQr/woSVfYu8SGNfWP4VHfrBEtaJm3m1X0KAemLihiBxtbD+J7S9JyMi+6R4/6Jb5RGfDQ== X-Received: by 2002:a17:907:7847:b0:aa6:834b:d138 with SMTP id a640c23a62f3a-aa6834be354mr477407066b.19.1733767078854; Mon, 09 Dec 2024 09:57:58 -0800 (PST) From: Andrii Sultanov To: xen-devel@lists.xenproject.org Cc: Andrii Sultanov , Christian Lindig , David Scott , Anthony PERARD Subject: [PATCH v2 0/1] Fix rpath handling in OCaml's Makefile.rules Date: Mon, 9 Dec 2024 17:57:48 +0000 Message-Id: X-Mailer: git-send-email 2.39.5 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit As reported by Nix's Xen team, OCaml stub libs would embed an absolute rpath in the binaries, which was picked up on by patchelf. This is a symptom of improper handling of -rpath-link in the first place, so correct that and get rid of the issue. Changes in v2: - Previous version mistakenly did not actually get rid of the absolute rpath, pass -L directly to the linker as well - Credit the original reporter Andrii Sultanov (1): tools/ocaml: Specify rpath correctly for ocamlmklib tools/ocaml/Makefile.rules | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Dec 09 19:17:53 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 19:17:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851819.1265823 (Exim 4.92) (envelope-from ) id 1tKjGA-0001pJ-Nc; Mon, 09 Dec 2024 19:17:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851819.1265823; Mon, 09 Dec 2024 19:17:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKjGA-0001pC-Jt; Mon, 09 Dec 2024 19:17:34 +0000 Received: by outflank-mailman (input) for mailman id 851819; Mon, 09 Dec 2024 19:17:33 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKjG9-0001p6-0e for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 19:17:33 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1tKjG8-00CClY-0W; Mon, 09 Dec 2024 19:17:32 +0000 Received: from [2a02:8012:3a1:0:b1c7:cb3b:4877:d8] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tKjG8-00AEeA-0a; Mon, 09 Dec 2024 19:17: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" 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=NuyzHtvw7j+22P/MzEihM1BbP+943BZEy5p3voqdxjY=; b=YfnXK5g4DBWcZoDQ4TKyXqhf8b hC6UwQPOkrgrZrv60Um3uUv6yqyc2UBW8ij3uEivxK8Cx6RExuw8n6npRe82CF/Nfp0WvLdy8EH0N eWpb/3IPmrJFu1KFMJvOdcasDTa4k72L/1HbTVQzPsseks9RWkf+p7rihPI2bMMp8YME=; Message-ID: <0bacfdb6-d4ad-4dea-85d4-2851873dca4e@xen.org> Date: Mon, 9 Dec 2024 19:17:30 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 03/12] xen/arm: permit non direct-mapped Dom0 construction Content-Language: en-GB To: Michal Orzel , Carlo Nonato , xen-devel@lists.xenproject.org Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk References: <20241202165921.249585-1-carlo.nonato@minervasys.tech> <20241202165921.249585-4-carlo.nonato@minervasys.tech> <7ecc99c5-0cb5-4351-bede-cb03c9a4ac7e@xen.org> <293004fa-c87e-4a45-aa4c-b02456aaecea@amd.com> From: Julien Grall In-Reply-To: <293004fa-c87e-4a45-aa4c-b02456aaecea@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Michal, On 07/12/2024 15:04, Michal Orzel wrote: > > > On 06/12/2024 19:37, Julien Grall wrote: >> >> >> Hi, >> >> Sorry for the late answer. >> >> On 05/12/2024 09:40, Michal Orzel wrote: >>> >>> >>> On 02/12/2024 17:59, Carlo Nonato wrote: >>>> >>>> >>>> Cache coloring requires Dom0 not to be direct-mapped because of its non >>>> contiguous mapping nature, so allocate_memory() is needed in this case. >>>> 8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a separate module") >>>> moved allocate_memory() in dom0less_build.c. In order to use it >>>> in Dom0 construction bring it back to domain_build.c and declare it in >>>> domain_build.h. >>>> >>>> Take the opportunity to adapt the implementation of allocate_memory() so >>>> that it uses the host layout when called on the hwdom, via >>>> find_unallocated_memory(). >>>> >>>> Signed-off-by: Carlo Nonato >>>> --- >>>> v11: >>>> - GUEST_RAM_BANKS instead of hardcoding the number of banks in allocate_memory() >>>> - hwdom_ext_regions -> hwdom_free_mem in allocate_memory() >>>> - added a comment in allocate_memory() when skipping small banks >>>> v10: >>>> - fixed a compilation bug that happened when dom0less support was disabled >>>> v9: >>>> - no changes >>>> v8: >>>> - patch adapted to new changes to allocate_memory() >>>> v7: >>>> - allocate_memory() now uses the host layout when called on the hwdom >>>> v6: >>>> - new patch >>>> --- >>>> xen/arch/arm/dom0less-build.c | 44 ----------- >>>> xen/arch/arm/domain_build.c | 97 ++++++++++++++++++++++++- >>>> xen/arch/arm/include/asm/domain_build.h | 1 + >>>> 3 files changed, 94 insertions(+), 48 deletions(-) >>>> >>>> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c >>>> index d93a85434e..67b1503647 100644 >>>> --- a/xen/arch/arm/dom0less-build.c >>>> +++ b/xen/arch/arm/dom0less-build.c >>>> @@ -49,50 +49,6 @@ bool __init is_dom0less_mode(void) >>>> return ( !dom0found && domUfound ); >>>> } >>>> >>>> -static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo) >>>> -{ >>>> - struct membanks *mem = kernel_info_get_mem(kinfo); >>>> - unsigned int i; >>>> - paddr_t bank_size; >>>> - >>>> - printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n", >>>> - /* Don't want format this as PRIpaddr (16 digit hex) */ >>>> - (unsigned long)(kinfo->unassigned_mem >> 20), d); >>>> - >>>> - mem->nr_banks = 0; >>>> - bank_size = MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem); >>>> - if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM0_BASE), >>>> - bank_size) ) >>>> - goto fail; >>>> - >>>> - bank_size = MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem); >>>> - if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM1_BASE), >>>> - bank_size) ) >>>> - goto fail; >>>> - >>>> - if ( kinfo->unassigned_mem ) >>>> - goto fail; >>>> - >>>> - for( i = 0; i < mem->nr_banks; i++ ) >>>> - { >>>> - printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n", >>>> - d, >>>> - i, >>>> - mem->bank[i].start, >>>> - mem->bank[i].start + mem->bank[i].size, >>>> - /* Don't want format this as PRIpaddr (16 digit hex) */ >>>> - (unsigned long)(mem->bank[i].size >> 20)); >>>> - } >>>> - >>>> - return; >>>> - >>>> -fail: >>>> - panic("Failed to allocate requested domain memory." >>>> - /* Don't want format this as PRIpaddr (16 digit hex) */ >>>> - " %ldKB unallocated. Fix the VMs configurations.\n", >>>> - (unsigned long)kinfo->unassigned_mem >> 10); >>>> -} >>>> - >>>> #ifdef CONFIG_VGICV2 >>>> static int __init make_gicv2_domU_node(struct kernel_info *kinfo) >>>> { >>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c >>>> index 2c30792de8..2b8cba9b2f 100644 >>>> --- a/xen/arch/arm/domain_build.c >>>> +++ b/xen/arch/arm/domain_build.c >>>> @@ -416,7 +416,6 @@ static void __init allocate_memory_11(struct domain *d, >>>> } >>>> } >>>> >>>> -#ifdef CONFIG_DOM0LESS_BOOT >>>> bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size, >>>> alloc_domheap_mem_cb cb, void *extra) >>>> { >>>> @@ -508,7 +507,6 @@ bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn, >>>> >>>> return true; >>>> } >>>> -#endif >>>> >>>> /* >>>> * When PCI passthrough is available we want to keep the >>>> @@ -1003,6 +1001,94 @@ out: >>>> return res; >>>> } >>>> >>>> +void __init allocate_memory(struct domain *d, struct kernel_info *kinfo) >>>> +{ >>>> + struct membanks *mem = kernel_info_get_mem(kinfo); >>>> + unsigned int i, nr_banks = GUEST_RAM_BANKS; >>>> + paddr_t bank_start, bank_size; >>> Limit the scope >>> >>>> + struct membanks *hwdom_free_mem = NULL; >>>> + const uint64_t bankbase[] = GUEST_RAM_BANK_BASES; >>>> + const uint64_t banksize[] = GUEST_RAM_BANK_SIZES; >>> Limit the scope >>> >>>> + >>>> + printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n", >>>> + /* Don't want format this as PRIpaddr (16 digit hex) */ >>>> + (unsigned long)(kinfo->unassigned_mem >> 20), d); >>>> + >>>> + mem->nr_banks = 0; >>>> + /* >>>> + * Use host memory layout for hwdom. Only case for this is when LLC coloring >>>> + * is enabled. >>>> + */ >>>> + if ( is_hardware_domain(d) ) >>>> + { >>>> + ASSERT(llc_coloring_enabled); >>> This patch does not build because of declaration not being visible. You must include . >> >> Piggying back on this comment. AFAICT, the code below would work also in >> the non cache coloring case. So what's the assert is for? >> >>> >>>> + >>>> + hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank, >>>> + NR_MEM_BANKS); >>>> + if ( !hwdom_free_mem ) >>>> + goto fail; >>>> + >>>> + hwdom_free_mem->max_banks = NR_MEM_BANKS; >>>> + >>>> + if ( find_unallocated_memory(kinfo, hwdom_free_mem) ) >>> My remarks for the use of find_unallocated_memory() 1:1 have not been addressed. You did not even >>> change the comments inside the function. The problem is that the function is specifically designed >>> for finding extended regions and assumes being called at certain point i.e. dom0 RAM allocated, gnttab >>> region allocated, etc. >> >> So I agree that the function should be updated if we plan to use it for >> other purpose. >> >> My opinion is that we should attempt to make the function generic so >> that in your >>> case you can choose which regions to exclude, define even your own function to grab free regions (at the moment >>> add_ext_regions grabs banks >= 64M but you still discards banks >= 128M, so it's a bit wasteful. >>> >>> My very short attempt to make the function as generic as possible in the first iteration: >>> https://paste.debian.net/1338334/ >> >> This looks better, but I wonder why we need still need to exclude the >> static regions? Wouldn't it be sufficient to exclude just reserved regions? > Static shared memory banks are not part of reserved memory (i.e. bootinfo.reserved_mem) if that's what you're asking. > They are stored in bootinfo.shmem, hence we need to take them into account when searching for unused address space. Oh I missed the fact you now pass "mem_banks" as a parameter. I thought they would still get excluded for cache coloring case. > > If you and Carlo are ok with my proposed solution for making the function generic, I can send a patch as a prerequisite > patch for Carlo series. I am fine with the approach. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Dec 09 19:20:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Dec 2024 19:20:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851828.1265833 (Exim 4.92) (envelope-from ) id 1tKjJ5-0003NG-5t; Mon, 09 Dec 2024 19:20:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851828.1265833; Mon, 09 Dec 2024 19:20: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 1tKjJ5-0003N9-1x; Mon, 09 Dec 2024 19:20:35 +0000 Received: by outflank-mailman (input) for mailman id 851828; Mon, 09 Dec 2024 19:20: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 1tKjJ3-0003N3-9R for xen-devel@lists.xenproject.org; Mon, 09 Dec 2024 19:20:33 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2061d.outbound.protection.outlook.com [2a01:111:f403:2413::61d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a7c10341-b662-11ef-a0d5-8be0dac302b0; Mon, 09 Dec 2024 20:20:32 +0100 (CET) Received: from SA0PR11CA0060.namprd11.prod.outlook.com (2603:10b6:806:d0::35) by DM6PR12MB4121.namprd12.prod.outlook.com (2603:10b6:5:220::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.14; Mon, 9 Dec 2024 19:20:24 +0000 Received: from SA2PEPF000015CB.namprd03.prod.outlook.com (2603:10b6:806:d0:cafe::bc) by SA0PR11CA0060.outlook.office365.com (2603:10b6:806:d0::35) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.12 via Frontend Transport; Mon, 9 Dec 2024 19:20:24 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by SA2PEPF000015CB.mail.protection.outlook.com (10.167.241.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Mon, 9 Dec 2024 19:20:24 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) 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; Mon, 9 Dec 2024 13:20:23 -0600 Received: from [172.28.102.118] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Mon, 9 Dec 2024 13:20: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: a7c10341-b662-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kXfI8uIlTQa+GQM3m3U3XKYisRNBPUXcw1Nhp0sS8C+ZSsUdulxtierLztKgjxxwXT0qsW0rSkYU+YQw7yl3LP5uJ16SCQ4trIQqaLpZHWE6a/dJFgQbkzuZvx/EHUSEAyZJGiQ/6EfhqeAcRfMGj1xlmtUdP3L8PwZk5/KbHS/iYnI++sZsBdjRYx+7i4P6HIDSp2B587WjXzVQ3IGNy5/Xo8SgGfgq18G+DNI/Sx3hkCaipPtx6B4rpXazgDbHSuUniBh5dkI7Rtgutjshtf5tzC+67mBS4UcZLbHge8EkVB5GEfLgeER6RY3qnGnvrurfNz+yCcwv7VUanI3twQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IXJDaz94dakxJ/TNQ7sC0pn1BJLya1iZ8TEfd2Rm6Yc=; b=tv3T1Nq2cSo9WEqmKgtyl9vogDAP2EFch4cDn6QOdqT4bAEYx8mAXJ8wdk/dIQdt9fE7diw7y77heYnJ1NCpQ7YTKVy5+3ii7VazPS6UU8PHALn5AHe7bBzZ1wIw4R9lRwLL7KQeCaid/Qn/n6mWxjBD9+b23MJXYonJGjUt9zooVFsO3U33kHs7SKHW3RIBaaRAoz7WF6VKTz21cUCvToFtYZsdaNUztU4qmd8Iojc4UZRQq6D5o+GuNOWyYdn52aOVRqz/8sFMUetXxKEu+D6EkYw7Ssj67dfMTpTmtdmA6dqFhJ1pjdtlz77XjdBJ6WzSeOsZctNXtaXx43nnZA== 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=IXJDaz94dakxJ/TNQ7sC0pn1BJLya1iZ8TEfd2Rm6Yc=; b=Gv3NImBJzAXywCSmmb2jURgb+/wfHsTNIN4emvaBFLQP+EHyFpJOGXVZWvTzmMkDvRqmLhhXDBzqKurnYnXcoAS9ZASNF2HXSIsDa7DNald/uTwQHU7jCVoMeDjzDX8I+p87Bjo4lHiFoeI9mbx2gUsEqPuDGDPbr8QzYat/+kE= 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=SATLEXMB04.amd.com; pr=C Message-ID: Date: Mon, 9 Dec 2024 14:20:24 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] CHANGELOG: Mention xl suspend/resume To: Jan Beulich CC: Oleksii Kurochko , Community Manager , References: <20241205195026.3523-1-jason.andryuk@amd.com> <638e4fe3-c346-4c03-a3db-2027986753a8@suse.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <638e4fe3-c346-4c03-a3db-2027986753a8@suse.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA2PEPF000015CB:EE_|DM6PR12MB4121:EE_ X-MS-Office365-Filtering-Correlation-Id: 028cc1e3-4688-49e3-0203-08dd188687f9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|82310400026|376014|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?UWtaU3gvdW5NeUZnNC9IalZONE54VnZCZnhXSGFONjh4Z1Y2dXd0VzZHVE9i?= =?utf-8?B?a3VxU1kxald6U2lqNEhDQzdFQ1UrcVRFMkNmVjd1MUJ1ZGFQVVRSdzBDczV4?= =?utf-8?B?RWNVajYwV0JDZEtINEhxaERVbEFjN3dVQmdZMmtVZzE2S0tXT1hoZkhwWTRE?= =?utf-8?B?TkkvaXdQbFVuRk4zSzlTRFZGcmloUnRCNExmQlZJK0k2MTNhNlB0SHY0VVox?= =?utf-8?B?MWFJcjUzeE40ay9OSnBMTlppU2ltaWlHQXdSQnJKY2Y1cHdVdXQrN2ZQZ0tw?= =?utf-8?B?aW1KcFhwVzFrUDFyTlQ2aG1sa0VnZkVXTEhwNEdxckk5eFIxSmJIQmVJK0g4?= =?utf-8?B?a1pPTmR4T09YM3ZjRWNRR2FMczdyb1pGWFVvbk1TTm9wb3dCK1JxQVFqNW5Z?= =?utf-8?B?dWlWTXZGVG1mdURZdWN1LysvbGV3NUVOZThuR1Vwci9adERXend2eUpkWkE2?= =?utf-8?B?a2VRZGp6RGh6ejFKWWVpT3l5ZTlSNHJkNEVTaStrK09wNUpaK2QrTDFXSVVD?= =?utf-8?B?eWltbElraUV4UG1ySVZEZGMzdFBFaVRWYStaUGtXRm9VUlFDN1E2RmdzdEdF?= =?utf-8?B?OUdFbDZ2di82OVNwZjNKaWR6Y1VSZS9wTk81Vnc4LzcveW1wMThOYVlmNGE1?= =?utf-8?B?SWJYVkxiaTNYY29SOGl3MXNXa2tmRmJRSUZsUittNTFvaWV2ck83K2FzTlhK?= =?utf-8?B?NnJiUTkrQzR6WTZzTzBodDdTTmJSMGpvNWlsNTV5cWJORTczWWlZT3RVQnQz?= =?utf-8?B?Mm9URElGOW9OQmwwZXdBZENRQUhaMUFxMEhDM3dkR2dmUFRJcFJTMHBGVmFT?= =?utf-8?B?WThxRlFWckdzNWhMYUlTNXd6YjZoZ1VpS0NZbkhkVGRDdTl1RUY5cDVPeHZo?= =?utf-8?B?bkdIWndpYXMweGNXZ0RXQ3RqNHA4YWt5VlRXcUlCVlFzM3pkS2lIcU9yY2NG?= =?utf-8?B?L3dBV1dsdVFDQTNwemFYVnNaTG9zWTFZOFFuVzlKbVg4dStOcFhWVCs0Y0NV?= =?utf-8?B?dzBrRVdLMk1iSlRPVjlIdk9CbUZtOXJvTXl5Tm5wUWI2cDhXQXNFb2xsNnU2?= =?utf-8?B?ZjNwUHpkclZxUE5NTkpKN2lIeC8yVjFrdFl0QU9GNXFxWVBGalk4UW14TVBT?= =?utf-8?B?Q0hBQ1YyZ2pvdkVYZTFlaWVscGhMeFNvT3dlQ2ZIMFBxcWxoR1QzQVJrRnls?= =?utf-8?B?YUdnUXFTdTE4bng1SmE3UTE2b3Z3cnByNEwwZHNnc0g3b0VmRU5hZm9EUkNH?= =?utf-8?B?REx1Vmo3cFROamUyVGdjamQxbVpuM1RHYzNTN3dOaExwa2E0Y2RIS3BoQ21H?= =?utf-8?B?VnlTZGF5U1BYNUxpdXgzSVQ3QjY4RVplQk5LY3Exb25XZWdWY3lmUlpLYXdW?= =?utf-8?B?R2lHU2VyWmFkRWhrK1plN1haeVRnRzBSdm15M0RrMG5GeWhKejBxS1UxTHdX?= =?utf-8?B?UExSeVNMUUticmVCUDFhLzByREFaeDIvOUY2SGNldGdmSW5RSHB3NzhBOTdy?= =?utf-8?B?Q2NUbkFNeElVdzR5UHVGb05zdC9IUXd4TzZZemJnZVJqZURYTFlIZUlrTU1w?= =?utf-8?B?SkxCUEZxUkNpTndlbzVlaS85b2orU2M0MEdLU201UVZScWE5Snp6RXBmVHlB?= =?utf-8?B?Q0JnWXBXbUQvc2J6aFVUVUNzOVJ5QzVyVENoU21kbmhHTm1tQnR3c0hvMjVI?= =?utf-8?B?bEZPUHVabjljQUNKODdFVnk5TlpkMkJkOThWczVrSXRiQ0ZaZCtONXB5NTVS?= =?utf-8?B?MVpsMTVvU0s0VnBreDNna29SSnhTVlFGWDV3WU1VQVlFYzR6dHRQMUp6eWR1?= =?utf-8?B?WWZEMkdmOXBWSCt3eU9WajJTdTlUSGI5V2RWK091THlpeWRuRzl1WThjM2Rl?= =?utf-8?Q?cThee3BBcY+rv?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(376014)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Dec 2024 19:20:24.1624 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 028cc1e3-4688-49e3-0203-08dd188687f9 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SA2PEPF000015CB.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4121 On 2024-12-09 04:29, Jan Beulich wrote: > On 05.12.2024 20:50, Jason Andryuk wrote: >> Signed-off-by: Jason Andryuk >> --- >> It only works for x86, but it isn't x86-specific. I chose to add it as >> a generic entry instead of listing it as x86. > > Which probably is fine, yet then ... > >> --- a/CHANGELOG.md >> +++ b/CHANGELOG.md >> @@ -16,6 +16,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) >> ### Added >> - On Arm: >> - Experimental support for Armv8-R. >> + - xl suspend/resume subcommands. > > ... you'd want to name the limitation to x86 here anyway, I think. Unless > there are firm plans to remove the limitation by 4.20 going out. No, I don't think there are any plans to remove the limitation. This seems weird since the feature depends on platform implementations of hypercalls and library plumbing: - On x86: - xl suspend/resume subcommands. Whereas this seems unusual since it's not following the above format: - xl suspend/resume subcommands (x86 only). I guess I'd put it under "On x86" if I had to choose. Regards, Jason From xen-devel-bounces@lists.xenproject.org Tue Dec 10 07:08:36 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Dec 2024 07:08:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851869.1265843 (Exim 4.92) (envelope-from ) id 1tKuLn-0003YP-Td; Tue, 10 Dec 2024 07:08:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851869.1265843; Tue, 10 Dec 2024 07:08: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 1tKuLn-0003YI-QU; Tue, 10 Dec 2024 07:08:07 +0000 Received: by outflank-mailman (input) for mailman id 851869; Tue, 10 Dec 2024 07: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 1tKuLm-0003YC-7j for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 07:08:06 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on20612.outbound.protection.outlook.com [2a01:111:f403:2412::612]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7f56a5f9-b6c5-11ef-a0d5-8be0dac302b0; Tue, 10 Dec 2024 08:08:04 +0100 (CET) Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18) by MN0PR12MB6317.namprd12.prod.outlook.com (2603:10b6:208:3c2::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Tue, 10 Dec 2024 07:07:59 +0000 Received: from BL1PR12MB5849.namprd12.prod.outlook.com ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com ([fe80::b77f:9333:3a5a:d285%3]) with mapi id 15.20.8230.010; Tue, 10 Dec 2024 07:07: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: 7f56a5f9-b6c5-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mmtUkGO2/0EwfOJ7cczLsETAPgW2WCvOyOnp0PaM6wJ8LTBAaqtFmwGRzT1/gVHMXK951SI0v7eTr745ULj5QFMSIBgEfUaUqjFRDzd7Z/wZJGWMNOhpjQ0t/XhFSg4w35k1Kz61HBitd0T3CeAcdRbsLnpDP2aF5sfugdQaf2ztWR2RZoO2wpbs3Pr1EgOMD8JRcKSnlG2EnWIsiR9sbhzi+FLDhLuHlGOVctt2I+K2c6txDDgRucfBHnGa0435ZQQuoLNjJ2UNWbC/gCAJxfR8GUUcIfrTUA8Yj9VSuSUc582/OQpU/uP0sLT9Fyl4ewCyTFU5nVRkkArTl++Sig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DBOBliRZGRZBOKFQQvycSboBBLwSj0hCe0qrusS684I=; b=CA3Clr0uNRvPqY73NGncZAcCE4ny7/h6jCn7hek2mPKIEUfXZQpqwOtTW3Wraasn7h3qQ4fn2L14wpo1oV/Ku1ytRrVLvHQx+97xLaplrW8b2BcJqwjQPnY3SdEac7JgU/Q/WliRRugbFMYLG+URh0XGHazfG2ot5xK/WfGwgWqhPtqVwaWJF2AGdM2Kf7MNvvE842rtKPatD59D54rqhR5yPlH9wrDimehBTJzqxuni4YV5v931LywjeVZZSmULBPdLUdY3BLDvRvYHfkD0ZJeZxBYsVN05G+OpRyqD06b2NaQmPhgDEfv42MPxERuV0GZ3e6KeXC7Qd/HS5mN6nw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DBOBliRZGRZBOKFQQvycSboBBLwSj0hCe0qrusS684I=; b=BN9uR6kccPuyfjdkECoOvZkWe9o2QS8AYgA7Cw2Iua8DM/1L1c8Xzl6/RVNrc3hrtLQhxE1DtXfmhOiZ0gaBRAcuGpJ+QooKDaQreOLBkSY8cMfi6lZReVOo2w00XQPY6+/o+YGGyN7EZWmtA8Q7ymfg8L7J6xVo3PMliITeLnA= From: "Chen, Jiqian" To: Jan Beulich , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= CC: Andrew Cooper , Julien Grall , Stefano Stabellini , "Huang, Ray" , "xen-devel@lists.xenproject.org" , "Chen, Jiqian" Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support Thread-Topic: [PATCH v2 1/1] vpci: Add resizable bar support Thread-Index: AQHbRIDgGHZ3ofHO0UuqqXvn+EZCabLd/CGAgAGXh4A= Date: Tue, 10 Dec 2024 07:07:59 +0000 Message-ID: References: <20241202060956.1124162-1-Jiqian.Chen@amd.com> <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com> In-Reply-To: <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com (15.20.8230.010) authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|MN0PR12MB6317:EE_ x-ms-office365-filtering-correlation-id: f58a2740-1e4b-48a2-284e-08dd18e96153 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018; x-microsoft-antispam-message-info: =?utf-8?B?a0FNQ09kUXBxOFhPTHg3R1puMWYwb0JLblcxUHdFTHVzUjVyYzhYUTJyMWJR?= =?utf-8?B?VVlkNHdpdjAxZWlTb1ZCTG4rWGF3WVhYQzNqZFdLOEZFMkVCY2g3alFQc01w?= =?utf-8?B?VFdzOXlhcmJqVGFWUG9vNENXTnFWY0ZTQ05temlXSHBxcWpzbFljc2NVYTJ0?= =?utf-8?B?VWR1VWt4SkRMVlJRZUFGQUtmcHRuL0NNQ05qeXJmc1dRaUZreVhTZ0RHRW9l?= =?utf-8?B?a0E0QmVWYkppeTFlbms5TksyZXBObWJSenVnbEFFZDFjNkdtQzhEWHJqMVBw?= =?utf-8?B?Ym5jZk5RRXp1SnpMZ0VqTnFTK3l4RHNURHo3RVV4eUJ2OExEQm9lbG1oVnFo?= =?utf-8?B?ZG1RUVN5dkRLMjRTckoyUHcyblBlVzJYV01Xb3IxYW4yTlRESjZ6aE5LMTVI?= =?utf-8?B?REhUVEdPaGFndnowUnRyUzRwT09rSUl0ME0xbGZTeVBGcU9jcnlOdnJ0RHdI?= =?utf-8?B?a0g2SklzZDNrZnNtcHNBTWRkbzAxQXBTYVFiaHJqRTZrMmd0eGZBVDBkaDI1?= =?utf-8?B?NDhNZlhuaXlKVnI2NWVmUTUzdVZ1OE5ZcGxQVjV3N1MrT0lCUEcwdk45SFV5?= =?utf-8?B?emZoSFZCM1NRaE1QTnFudnB2QVRsaCtMQkd4L2NmY29wM1IwS2thOVkxcWtZ?= =?utf-8?B?QVltQkFsZGN4Qk1TQXMrZ2plL2hGNVVnaWg2Yml4Y1Eyc0Y3VVFvTjBqeUFG?= =?utf-8?B?Zm8zQVJ6aElWUVRrY3U4Q2lDT3FZOTVjY3JUY0IwR0VURGlQbEVsUDlOYktX?= =?utf-8?B?T1JEWUVlQWRkTEliWDRkTDIvNm13ck9mVWYvZEExNGJqakw1VXlxY2FuaUJ5?= =?utf-8?B?SEFzK0xSWEdQeHA0RWtBVjlmblpBOFU5VzV6bkxYb1JpWjgrYjc4b0hWbVE0?= =?utf-8?B?cE1WOWxMREhGU1lnRUwyckxrUlg0S1hYNjE3OXB1Um5vekpTQ2Z3NkRNNGlk?= =?utf-8?B?Q1o2NGREdldPUHFmL2VId3IwVTVGdlRMWExNUHJ1V0kvaXd6Nzh2R05MbDQ4?= =?utf-8?B?dG1RVmFvSXF3aEN2ZkM5NnlXMWlJWnF1MFFsd3dydFlVN3hsaDY4MUxHeWcz?= =?utf-8?B?NU9lVkwzTktDdElFQTFqcldaODEvNFlmM0poSllaTDdIZlh1MWc4d0tKZ09V?= =?utf-8?B?S25VOUpDRnhUc0l3WTh6N285RFBVajhHWDkzZ2FuRjk4eWhWZlk4TnRJcFhi?= =?utf-8?B?RlpCR0ZLdEtoOVcyS0ZRRWxFQVhDNkxoRjVQcEl4eWNsWDRkT3hETVBPSjVU?= =?utf-8?B?N3Z1dmdQWm44ODRSbmpmWEl5U0d6Sy9kejlvTWtGQjNDKzM1Y1FCY25WUTRL?= =?utf-8?B?eXQxcndxdGVnWGhFU2VSQUtZekEzN0Zwamg2Vy9CRjQyMUJoVkF2MFFTN0x4?= =?utf-8?B?bERFaSt4MFczVjRSVTBvc0llbjV5aE1BeTJDeHV2cnlOYXBsY3JwVjZIa3RD?= =?utf-8?B?cGJab2RvWHNVNjhMZ09aLzZnNE9Laml2emNwai8welc3WHk1d09NTnVaemZa?= =?utf-8?B?dytHVFYxY3R2bHpnZFBqbnFyYy9qTkNLZmhMTjVEMDNxU1RQK3EvMjFRZVFk?= =?utf-8?B?WndDTFlselo0WnJseUlEaWJxdVZmQVZ6a1pwUFVQWGYyOUdNNitFOTRZckdw?= =?utf-8?B?bDJWUFllcmpTSFE3V3czSHFBaEx2Mm5JOUFsWEtLcUJJN1BTU2hOSE9kbWpP?= =?utf-8?B?eUhvOFVtd01DVk1iOVNUUTZHcUNtSkJiclBOSmlNT0E2MzRlMWhiWXNBQUdF?= =?utf-8?B?VEFyenlJTVhjWmFkd3Z4eWw5OExQSU9wS1ZUcjdJcFBpRHgzdktLbU1ZWFdv?= =?utf-8?B?aDdnNFNERUo5Vkdvc2FMa1VBRmZ5bks2amdlcE5kaE1nV2JZNk1WMzFvVkNi?= =?utf-8?B?TGJMSUdOUlNzWGNtMGdsQzE5aUhmK29LeW9JcXFVN0tVUmc9PQ==?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dXB5VU9ncEJMbnpQWlA4MGs2L3JjQml6NVROOFZUdjZsS1d5TWJodFc5S2lS?= =?utf-8?B?NUZOODMveVpJMU9PNjBlSm9oZDVHV0REeS9ycWlzUE05NFp1Q1ZFMmpCMElR?= =?utf-8?B?TTFGczBEZGNHVklVaXY0bkhKN2ZtS3lJSnNpZjRKVmpla3VxQ1MyMWlmSHhx?= =?utf-8?B?UkNYR0M2djN4MklEa0dpK2pJVHdOcVhGTlVoNkFJdVRrU2xTQjRpQmt2OVNj?= =?utf-8?B?VlJERUxnRVRxOU0vYnNJdVYxNUZxaUFsSGl0KzZHVnJBZjhDTExySVlTSGkr?= =?utf-8?B?ck9WZ3dpK0c4ZDFSMGJOVTFxRC9jSHRJeGVmYmdzS05xaGhIMkVUeEJPU2RE?= =?utf-8?B?LzRMaHFKdWlpMGRnMHZIOENod2JPQ3QrS2djdEt1MnJDOUN4TUJXOXl0c051?= =?utf-8?B?YkQ0VFlvc2hZcjBGc0tQaEMxc2ptRFZFem9TQjVwU3hWdXNabms5VzluYkln?= =?utf-8?B?REVzSGpLT1pMVjlLWWd1SUpFV0VqRGdnNytsM3d6eE1TUUtOK0lEUDl5YkIw?= =?utf-8?B?N1d0S0NISHdGdzBndmh2bnkrcEFFemxGdDBqc3EvZDVzQ3JGQURQNjRKRXZV?= =?utf-8?B?K2VpZ0NOVlVKVDhaTWU1dmRScTRyaFVSRWNuS3dkZW5VZDdqMmF6S0lpYlV0?= =?utf-8?B?cHlPT1grV2Q0cy9MMFFyS1JuL2tkaE1iazBCNzMxQ3M5b0hCaDRhQUNDb2sz?= =?utf-8?B?eWd6Y09GQVlGUnlaYVYwelFaY0VLY3d6SW16MGNBVDdtdDBLamU2anErOXZ2?= =?utf-8?B?MDgwTjAxSU9CM2k3eS9WeGtrQm5pQWk0RzhRdS9QcS9WTVBudlhwY3cvcElJ?= =?utf-8?B?clVYcmkwVkNqeHhzMlBmRDRNR3JVTWk5Z1h4YloxaDdtOEg1MEo3UlVPOHZ0?= =?utf-8?B?ak1OMzlISm5LS29OMVRaczVTWlpDR3F5WGYzQTRnSHRRWS9TM09HWTVOL2Vw?= =?utf-8?B?ZWtYZTZCWGFYWTNGZVRITnVtVVBIbDRQWTZPaEFsOEtxblJhM0ZGbWx5Ykxm?= =?utf-8?B?cWtNRjNGam1WRTlWcy9kNGhUTmRveTkwYXBHeEFPWkZHOUduRlhwbVhQci9J?= =?utf-8?B?RzRwd0VwNUlqRmtHai8wempmR25SOERzcUFVUjc3TUlDVXExRzZLTFJMQXkw?= =?utf-8?B?QndnVVpiUzNydmN2RFlpZFQwWjdqeGF5V1JNYWJoTnQxTWtuRzZkaVB3ZXA4?= =?utf-8?B?T0NBTzljOXNHdXFSbGo0UngrRis1b2NLTlErOXJKYTFKOTFTaUozUGVzWWEw?= =?utf-8?B?cHBtbVIvRDl2cXFadWY1bHE4S3QzNGdxVkc1aXI2aEZnS0VOVVIxYmsyVFc3?= =?utf-8?B?c3hWMUdzdW5hbEpMTzdUSmVxTU82am53Y1pJck9DTmdaQkVPVzdwM3V4VWJv?= =?utf-8?B?QWYrQ1ovMk1KekpQeHpzMlZBWVQ4YldMTFJKRmpSVWVpNlB6R2xuVlRMTCtv?= =?utf-8?B?RGNmUFI0TTlkK0JoU3pIWEV5bkpZWTN4NDVrVXVlSVllS2wyczBmcmdEdDd6?= =?utf-8?B?cXJwYzZMMkE1cEh2dE5VWXBzVEJ0WThWcFFBMmU4WVNvMjRqTENrRDRTeTl0?= =?utf-8?B?blBnTE5FSWJJNFRaMlg4bXQrakZ5MzVieWZjcGpGNkFOTFVTYytjQkYvY1hh?= =?utf-8?B?NnkvZFlaeFI1YnZhYksvQk5BZXhVUVFRbHI2bFo4MHNPWEpoK3RBZXRJRkZT?= =?utf-8?B?bHNacW5iL2FoazM4bSttZlBUeG9tcnBHeUNBQ1FnbnorTi9tNmhJOW1OemFm?= =?utf-8?B?U2d2QWxKZXM2SThyNlFOZWhqYStVN2RweXdZZU90N2pNY2oyVEVTdDB6a2Er?= =?utf-8?B?TzdJaU1QL2RqWkQ4OXorTU82eVFLZzNsTGgvbW1ybmZKb053enNRMUdzUHdE?= =?utf-8?B?SUY3aC8rRzY0eHI5RXAvVEZsM1BUZ0E5YW05Y2lTdFFzK2ZPNDFZS3IwN1RC?= =?utf-8?B?Nmh5T0dONTg4Z3JWdHVsNTF4di9Ja2Z5eEh0U0txWFJaNWNzcTZpb1d3eFlu?= =?utf-8?B?T1I4dVlER0NmZXU1ZFJzWElGdGFnWUc0QzkxV1Q3MVBPMkMyTVpkNUMvZFJE?= =?utf-8?B?a1FFMmNPSEEzeUd4VzVQUEdWeWRGQU1QZHNJOW5kK0dQR1FIaWFSNGF2QUZx?= =?utf-8?Q?uu28=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f58a2740-1e4b-48a2-284e-08dd18e96153 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2024 07:07:59.5741 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vo9+x5KufLYLVJ2GP8ZWmwa+F2uLXNunUxdLc6sKUChy+F/UhFIgE6nVqczaLCziHfBx6CicYhQyPhy+FQrCag== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6317 T24gMjAyNC8xMi85IDIxOjU5LCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMDIuMTIuMjAyNCAw NzowOSwgSmlxaWFuIENoZW4gd3JvdGU6DQo+PiAtLS0gL2Rldi9udWxsDQo+PiArKysgYi94ZW4v ZHJpdmVycy92cGNpL3JlYmFyLmMNCj4+IEBAIC0wLDAgKzEsOTMgQEANCj4+ICsvKiBTUERYLUxp Y2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMC1vci1sYXRlciAqLw0KPiANCj4gV2FzIHRoaXMgYSBk ZWxpYmVyYXRlIGRlY2lzaW9uPyBXZSBkZWZhdWx0IHRvIEdQTC0yLjAtb25seSwgSSB0aGluay4N CldpbGwgY2hhbmdlIHRvIEdQTC0yLjAtb25seS4NCldoYXQncyB0aGUgZGlmZmVyZW5jZSBiZXR3 ZWVuIEdQTC0yLjAtb25seSBhbmQgR1BMLTIuMC1vci1sYXRlcj8NCg0KPiANCj4+ICsvKg0KPj4g KyAqIENvcHlyaWdodCAoQykgMjAyNCBBZHZhbmNlZCBNaWNybyBEZXZpY2VzLCBJbmMuIEFsbCBS aWdodHMgUmVzZXJ2ZWQuDQo+PiArICoNCj4+ICsgKiBBdXRob3I6IEppcWlhbiBDaGVuIDxKaXFp YW4uQ2hlbkBhbWQuY29tPg0KPj4gKyAqLw0KPj4gKw0KPj4gKyNpbmNsdWRlIDx4ZW4vaHlwZXJj YWxsLmg+DQo+PiArI2luY2x1ZGUgPHhlbi92cGNpLmg+DQo+PiArDQo+PiArc3RhdGljIHZvaWQg Y2ZfY2hlY2sgcmViYXJfY3RybF93cml0ZShjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwNCj4+ ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGludCByZWcs DQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCB2YWws DQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2b2lkICpkYXRhKQ0K Pj4gK3sNCj4+ICsgICAgdWludDY0X3Qgc2l6ZTsNCj4+ICsgICAgdW5zaWduZWQgaW50IGluZGV4 Ow0KPj4gKyAgICBzdHJ1Y3QgdnBjaV9iYXIgKmJhcnMgPSBkYXRhOw0KPj4gKw0KPj4gKyAgICBp ZiAoIHBjaV9jb25mX3JlYWQxNihwZGV2LT5zYmRmLCBQQ0lfQ09NTUFORCkgJiBQQ0lfQ09NTUFO RF9NRU1PUlkgKQ0KPj4gKyAgICAgICAgcmV0dXJuOw0KPiANCj4gSSBkb24ndCB0aGluayBzb21l dGhpbmcgbGlrZSB0aGlzIGNhbiBnbyB1bmNvbW1lbnRlZC4gSSBkb24ndCB0aGluayB0aGUNCj4g c3BlYyBtYW5kYXRlcyB0byBkcm9wIHdyaXRlcyBpbiB0aGlzIHNpdHVhdGlvbj8NClNwZWMgc2F5 czogU29mdHdhcmUgbXVzdCBjbGVhciB0aGUgTWVtb3J5IFNwYWNlIEVuYWJsZSBiaXQgaW4gdGhl IENvbW1hbmQgcmVnaXN0ZXIgYmVmb3JlIHdyaXRpbmcgdGhlIEJBUiBTaXplIGZpZWxkLg0KVGhp cyBjaGVjayBpcyBzdWdnZXN0ZWQgYnkgUm9nZXIgYW5kIGl0IHJlYWxseSBoZWxwcyB0byBwcmV2 ZW50IGVycm9uZW91cyB3cml0ZXMgaW4gdGhpcyBjYXNlLA0Kc3VjaCBhcyB0aGUgcmVzdWx0IG9m IGRlYnVnZ2luZyB3aXRoIFJvZ2VyIGluIHRoZSBwcmV2aW91cyB2ZXJzaW9uLg0KSSB3aWxsIGFk ZCB0aGUgc3BlYydzIHNlbnRlbmNlcyBhcyBjb21tZW50cyBoZXJlIGluIG5leHQgdmVyc2lvbi4N Cg0KPiANCj4+ICsgICAgaW5kZXggPSBwY2lfY29uZl9yZWFkMzIocGRldi0+c2JkZiwgcmVnKSAm IFBDSV9SRUJBUl9DVFJMX0JBUl9JRFg7DQo+PiArICAgIGlmICggaW5kZXggPj0gUENJX0hFQURF Ul9OT1JNQUxfTlJfQkFSUyApDQo+PiArICAgICAgICByZXR1cm47DQo+PiArDQo+PiArICAgIGlm ICggYmFyc1tpbmRleF0udHlwZSAhPSBWUENJX0JBUl9NRU02NF9MTyAmJg0KPj4gKyAgICAgICAg IGJhcnNbaW5kZXhdLnR5cGUgIT0gVlBDSV9CQVJfTUVNMzIgKQ0KPj4gKyAgICAgICAgcmV0dXJu Ow0KPj4gKw0KPj4gKyAgICBzaXplID0gUENJX1JFQkFSX0NUUkxfU0laRSh2YWwpOw0KPj4gKyAg ICBpZiAoICEoKHNpemUgPj4gMjApICYNCj4+ICsgICAgICAgICBNQVNLX0VYVFIocGNpX2NvbmZf cmVhZDMyKHBkZXYtPnNiZGYsIHJlZyAtIDQpLCBQQ0lfUkVCQVJfQ0FQX1NJWkVTKSkgKQ0KPiAN Cj4gTm8gc3VjaCBsaXRlcmFsIDQgcGxlYXNlLiBXaGF0IEkgdGhpbmsgeW91IG1lYW4gaXMgcmVn IC0gUENJX1JFQkFSX0NUUkwgKw0KPiBQQ0lfUkVCQVJfQ0FQLg0KWWVzLCB3aWxsIGNoYW5nZSwg dGhhbmtzLg0KDQo+IA0KPiBBbHNvIGluZGVudGF0aW9uIGlzIG9mZiAoYnkgMikgaGVyZS4NCj4g DQo+PiArICAgICAgICBncHJpbnRrKFhFTkxPR19XQVJOSU5HLA0KPj4gKyAgICAgICAgICAgICAg ICAiJXBwOiBuZXcgc2l6ZSAlI2x4IGZvciBCQVIldSBpc24ndCBzdXBwb3J0ZWRcbiIsDQo+PiAr ICAgICAgICAgICAgICAgICZwZGV2LT5zYmRmLCBzaXplLCBpbmRleCk7DQo+PiArDQo+PiArICAg IGJhcnNbaW5kZXhdLnNpemUgPSBzaXplOw0KPj4gKyAgICBiYXJzW2luZGV4XS5hZGRyID0gMDsN Cj4+ICsgICAgYmFyc1tpbmRleF0uZ3Vlc3RfYWRkciA9IDA7DQo+PiArICAgIHBjaV9jb25mX3dy aXRlMzIocGRldi0+c2JkZiwgcmVnLCB2YWwpOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW50 IGNmX2NoZWNrIGluaXRfcmViYXIoc3RydWN0IHBjaV9kZXYgKnBkZXYpDQo+PiArew0KPj4gKyAg ICB1aW50MzJfdCBjdHJsOw0KPj4gKyAgICB1bnNpZ25lZCBpbnQgcmViYXJfb2Zmc2V0LCBuYmFy czsNCj4+ICsNCj4+ICsgICAgcmViYXJfb2Zmc2V0ID0gcGNpX2ZpbmRfZXh0X2NhcGFiaWxpdHko cGRldi0+c2JkZiwgUENJX0VYVF9DQVBfSURfUkVCQVIpOw0KPj4gKw0KPj4gKyAgICBpZiAoICFy ZWJhcl9vZmZzZXQgKQ0KPj4gKyAgICAgICAgcmV0dXJuIDA7DQo+PiArDQo+PiArICAgIGN0cmwg PSBwY2lfY29uZl9yZWFkMzIocGRldi0+c2JkZiwgcmViYXJfb2Zmc2V0ICsgUENJX1JFQkFSX0NU UkwpOw0KPj4gKyAgICBuYmFycyA9IE1BU0tfRVhUUihjdHJsLCBQQ0lfUkVCQVJfQ1RSTF9OQkFS X01BU0spOw0KPj4gKw0KPj4gKyAgICBmb3IgKCB1bnNpZ25lZCBpbnQgaSA9IDA7IGkgPCBuYmFy czsgaSsrLCByZWJhcl9vZmZzZXQgKz0gUENJX1JFQkFSX0NUUkwgKQ0KPj4gKyAgICB7DQo+PiAr ICAgICAgICBpbnQgcmM7DQo+PiArDQo+PiArICAgICAgICByYyA9IHZwY2lfYWRkX3JlZ2lzdGVy KHBkZXYtPnZwY2ksIHZwY2lfaHdfcmVhZDMyLCB2cGNpX2h3X3dyaXRlMzIsDQo+PiArICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHJlYmFyX29mZnNldCArIFBDSV9SRUJBUl9DQVAsIDQs IE5VTEwpOw0KPiANCj4gVGhlIGNhcGFiaWxpdHkgcmVnaXN0ZXIgaXMgci9vIGFpdWkuIFdoaWxl IHBlcm1pdHRpbmcgaHdkb20gdG8gd3JpdGUgaXQgaXMNCj4gZmluZSwgRG9tVS1zIHNob3VsZG4n dCBiZSBwZXJtaXR0ZWQgZG9pbmcgc28sIGp1c3QgaW4gY2FzZS4gKEFuIGFsdGVybmF0aXZlDQo+ IHRvIG1ha2luZyBoYW5kbGVyIHNlbGVjdGlvbiBjb25kaXRpb25hbCBoZXJlIHdvdWxkIGJlIHRv IGJhaWwgZWFybHkgZm9yIHRoZQ0KPiAhaHdkb20gY2FzZSwgYWNjb21wYW5pZWQgYnkgYSBUT0RP IGNvbW1lbnQuIFRoaXMgd291bGQgdGhlbiBhbHNvIGFkZHJlc3MNCj4gdGhlIGxhY2sgb2Ygdmly dHVhbGl6YXRpb24gb2YgdGhlIGV4dGVuZGVkIGNhcGFiaWxpdHkgY2hhaW4sIGFzIHdlIG1heSBu b3QNCj4gYmxpbmRseSBleHBvc2UgYWxsIGNhcGFiaWxpdGllcyB0byBEb21VLXMuKQ0KVGhhbmtz LCB3aWxsIGFkZCBpc19od2RvbSBjaGVjayBhbmQgYWRkICJUT0RPIiBjb21tZW50IGhlcmUuDQoN Cj4gDQo+PiArICAgICAgICBpZiAoIHJjICkNCj4+ICsgICAgICAgIHsNCj4+ICsgICAgICAgICAg ICBwcmludGsoIiVwcDogYWRkIHJlZ2lzdGVyIGZvciBQQ0lfUkVCQVJfQ0FQIGZhaWxlZCAocmM9 JWQpXG4iLA0KPj4gKyAgICAgICAgICAgICAgICAgICAmcGRldi0+c2JkZiwgcmMpOw0KPj4gKyAg ICAgICAgICAgIGJyZWFrOw0KPj4gKyAgICAgICAgfQ0KPj4gKw0KPj4gKyAgICAgICAgcmMgPSB2 cGNpX2FkZF9yZWdpc3RlcihwZGV2LT52cGNpLCB2cGNpX2h3X3JlYWQzMiwgcmViYXJfY3RybF93 cml0ZSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmViYXJfb2Zmc2V0ICsg UENJX1JFQkFSX0NUUkwsIDQsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBk ZXYtPnZwY2ktPmhlYWRlci5iYXJzKTsNCj4+ICsgICAgICAgIGlmICggcmMgKQ0KPj4gKyAgICAg ICAgew0KPj4gKyAgICAgICAgICAgIHByaW50aygiJXBwOiBhZGQgcmVnaXN0ZXIgZm9yIFBDSV9S RUJBUl9DVFJMIGZhaWxlZCAlZFxuIiwNCj4+ICsgICAgICAgICAgICAgICAgICAgJnBkZXYtPnNi ZGYsIHJjKTsNCj4+ICsgICAgICAgICAgICBicmVhazsNCj4gDQo+IElzIGl0IGNvcnJlY3QgdG8g a2VlcCB0aGUgb3RoZXIgaGFuZGxlciBpbnN0YWxsZWQ/IEFmdGVyIGFsbCAuLi4NCldpbGwgY2hh bmdlIHRvICJyZXR1cm4gcmM7IiBoZXJlIGFuZCBhYm92ZSBpbiBuZXh0IHZlcnNpb24uDQoNCj4g DQo+PiArICAgICAgICB9DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0dXJuIDA7DQo+IA0K PiAuLi4geW91IC0gaW1vIHNlbnNpYmx5IC0gYXJlbid0IGNvbW11bmljYXRpbmcgdGhlIGVycm9y IGJhY2sgdXAgKHRvIGFsbG93DQo+IHRoZSBkZXZpY2UgdG8gYmUgdXNlZCB3aXRob3V0IEJBUiBy ZXNpemluZy4NCj4gDQo+PiBAQCAtNTQxLDYgKzU0MiwxNiBAQA0KPj4gICNkZWZpbmUgIFBDSV9W TkRSX0hFQURFUl9SRVYoeCkJKCgoeCkgPj4gMTYpICYgMHhmKQ0KPj4gICNkZWZpbmUgIFBDSV9W TkRSX0hFQURFUl9MRU4oeCkJKCgoeCkgPj4gMjApICYgMHhmZmYpDQo+PiAgDQo+PiArLyogUmVz aXphYmxlIEJBUnMgKi8NCj4+ICsjZGVmaW5lIFBDSV9SRUJBUl9DQVAJCTQJLyogY2FwYWJpbGl0 eSByZWdpc3RlciAqLw0KPj4gKyNkZWZpbmUgIFBDSV9SRUJBUl9DQVBfU0laRVMJCTB4RkZGRkZG RjAgIC8qIHN1cHBvcnRlZCBCQVIgc2l6ZXMgKi8NCj4gDQo+IE1pc3JhIGRlbWFuZHMgdGhhdCB0 aGlzIGhhdmUgYSBVIHN1ZmZpeC4NCkRvIGJlbG93IFBDSV9SRUJBUl9DVFJMX0JBUl9JRFgsIFBD SV9SRUJBUl9DVFJMX05CQVJfTUFTSyBhbmQgUENJX1JFQkFSX0NUUkxfQkFSX1NJWkUgYWxzbyBu ZWVkIGEgVSBzdWZmaXg/DQoNCj4gDQo+PiArI2RlZmluZSBQQ0lfUkVCQVJfQ1RSTAkJOAkvKiBj b250cm9sIHJlZ2lzdGVyICovDQo+PiArI2RlZmluZSAgUENJX1JFQkFSX0NUUkxfQkFSX0lEWAkw eDAwMDAwMDA3ICAvKiBCQVIgaW5kZXggKi8NCj4+ICsjZGVmaW5lICBQQ0lfUkVCQVJfQ1RSTF9O QkFSX01BU0sJMHgwMDAwMDBFMCAgLyogIyBvZiByZXNpemFibGUgQkFScyAqLw0KPj4gKyNkZWZp bmUgIFBDSV9SRUJBUl9DVFJMX0JBUl9TSVpFCTB4MDAwMDFGMDAgIC8qIEJBUiBzaXplICovDQo+ PiArI2RlZmluZSAgUENJX1JFQkFSX0NUUkxfU0laRSh2KSBcDQo+PiArICAgICAgICAgICAgKDFV TCA8PCAoTUFTS19FWFRSKHYsIFBDSV9SRUJBUl9DVFJMX0JBUl9TSVpFKSArIDIwKSkNCj4gDQo+ IFRoZSBsaXRlcmFsIDIwIChhcHBlYXJpbmcgaGVyZSB0aGUgMm5kIHRpbWUpIGFsc28gd2FudHMg aGlkaW5nIGJlaGluZCBhDQo+ICNkZWZpbmUuDQpPSywgd2lsbCBhZGQgIiAjZGVmaW5lIFBDSV9S RUJBUl9TSVpFX1VOSVRfQllURVNfTEVOIDIwIiB0byByZXBsYWNlIGFib3ZlIHR3byAnMjAnIGNh c2UuDQoNCj4gDQo+IEphbg0KDQotLSANCkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K From xen-devel-bounces@lists.xenproject.org Tue Dec 10 07:10:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Dec 2024 07:10:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851878.1265853 (Exim 4.92) (envelope-from ) id 1tKuNz-0004zM-9A; Tue, 10 Dec 2024 07:10:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851878.1265853; Tue, 10 Dec 2024 07:10:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKuNz-0004zF-6O; Tue, 10 Dec 2024 07:10:23 +0000 Received: by outflank-mailman (input) for mailman id 851878; Tue, 10 Dec 2024 07:10: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 1tKuNx-0004z9-Q2 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 07:10: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 d1284579-b6c5-11ef-a0d5-8be0dac302b0; Tue, 10 Dec 2024 08:10:20 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-434a2033562so47463995e9.1 for ; Mon, 09 Dec 2024 23:10:20 -0800 (PST) Received: from ?IPV6:2003:ca:b746:63c:a58f:4219:ab5d:cf03? (p200300cab746063ca58f4219ab5dcf03.dip0.t-ipconnect.de. [2003:ca:b746:63c:a58f:4219:ab5d:cf03]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38621fbbdd8sm15077691f8f.95.2024.12.09.23.10.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 23: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: d1284579-b6c5-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733814620; x=1734419420; 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=GTFiWN/I8jtMOqAmrEtbxysEib3F+04J/YUa2umo0fk=; b=QlrxDdZzWK9iR9WLZ5GU68NvUXmyGPpqAujLrM0BDz9OJUwmOgZla7IeW92XCeeuFx I3Kcu3oxlwE2B9YhPd1xcXPyXX5aC1XgVx7J2gMHzZDbjUyvoybzrCJ3EIrd8ZUlevs0 mfAiYIu21KwjQSs2ngZrZYCb+7B0V/X/MG3q3RiH+wCO2Sdm80V2WtJ/x9L+YcZHW3nv FqPyJAorFP+DcfwOCdOdh6TvItG9wQEB8Tgfhsj+RbRHl/ZBDk+Hpw3hyJkSpwN9sfky C0h7lOUyXPJijUX518aTGLDNvrBcJm6yvcnJEmN2WSvtoTbAacNCmURZ9eNev4BEOUN8 /K/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733814620; x=1734419420; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=GTFiWN/I8jtMOqAmrEtbxysEib3F+04J/YUa2umo0fk=; b=R0sFeO+U6mdP88xuNP9RmRJwdUsY2pyhP/HsF/gEvNFJSfVvDHg8SzU71bpAVeWchO V9C/ViupYp7E+vbfJGy5NHst5BTBwbEvhEWqpR1GQQE5yN4gPtcwDiHJw/C74buh/DB+ 1BBYEvKXMUd/Ljvj/TcTq4/oalKyY85vgAhb7Z2sdxzNgOoWYEkCQiwZ4vNmACIQ4Zh9 FDCBeH2yDM9tI4xpjxVk8Ac507Vc8ZeUWAiac2rTjhKZxgca1WWvZdo+YbR09veFNFhY 895nxB4VOmTG/cUA6zSE6iInqpkFV1kkvN/zXQcGnH6KvXGv6DKsgY5/jVBwi2oorTfS hC0g== X-Forwarded-Encrypted: i=1; AJvYcCX6lsdcQaXQn+qJusS12GHjLvhKRgisp+qEqLTM3oPILv3Y0EkhXyKS3/POYRxfYj22BGr/CrXkyow=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz+UX4v58DHvdOg2FEB0TaPpCHCEI5lFmp5IGxdcldXxqnWaLDY Kqwu9i/2TWVYeKe6rrR1hs5M+bhnbLxMjBg2vgtdEBOJD0HcTTws+W+Z3pWViw== X-Gm-Gg: ASbGncuZcG5NABLndwvOIMSWEdL9imvgnjAYzGFTRqb/wW6RXocR7y1kpGWFp8xJxhN 4It4KZyky4DuWqlUeNisLaCiqB0/7z4/jJrbAbAqwvRas635s2f2+E46/sQsWlF3LHL6+gLsJM1 /o7PkysRvBlH3V+Hm6lJytUVmTfvHAflg5KCoP5s3VM8C0JZF2JGxCBnMDTJkJCSfVG6nst2oSi DruZNT312YglclAIzZvRYEAtgQiyjZKRWJtulAVKGvhRtYeSdO1l42/A9FtxPCBqZBnJLD1jl44 IkrgJYxE3ozIMhqnJsbn98CG1hsqfKKlyBaNr+h8ztcKPgEuoPjH8o2jk/Yl254Rk+u1mOvHXZ7 BgvSfjLbKaQ== X-Google-Smtp-Source: AGHT+IFK3ouiAOtSip3qbm9FBgxbL/q8AUc7IXBS2WERI5zq9OJRqlUhGGTzsLahb8rfanUtxlGTdA== X-Received: by 2002:a05:6000:1a86:b0:385:ec6e:e872 with SMTP id ffacd0b85a97d-3862b3cea1dmr13109617f8f.38.1733814620117; Mon, 09 Dec 2024 23:10:20 -0800 (PST) Message-ID: <24731167-3af6-447a-b61d-b1985360a2fe@suse.com> Date: Tue, 10 Dec 2024 08:10:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] CHANGELOG: Mention xl suspend/resume To: Jason Andryuk Cc: Oleksii Kurochko , Community Manager , xen-devel@lists.xenproject.org References: <20241205195026.3523-1-jason.andryuk@amd.com> <638e4fe3-c346-4c03-a3db-2027986753a8@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 09.12.2024 20:20, Jason Andryuk wrote: > On 2024-12-09 04:29, Jan Beulich wrote: >> On 05.12.2024 20:50, Jason Andryuk wrote: >>> Signed-off-by: Jason Andryuk >>> --- >>> It only works for x86, but it isn't x86-specific.  I chose to add it as >>> a generic entry instead of listing it as x86. >> >> Which probably is fine, yet then ... >> >>> --- a/CHANGELOG.md >>> +++ b/CHANGELOG.md >>> @@ -16,6 +16,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) >>>   ### Added >>>    - On Arm: >>>      - Experimental support for Armv8-R. >>> + - xl suspend/resume subcommands. >> >> ... you'd want to name the limitation to x86 here anyway, I think. Unless >> there are firm plans to remove the limitation by 4.20 going out. > > No, I don't think there are any plans to remove the limitation. > > This seems weird since the feature depends on platform implementations of hypercalls and library plumbing: > >  - On x86: >    - xl suspend/resume subcommands. > > Whereas this seems unusual since it's not following the above format: > >  - xl suspend/resume subcommands (x86 only). > > I guess I'd put it under "On x86" if I had to choose. I'd be fine with either; neither looks more "weird" to me than the other. Jan From xen-devel-bounces@lists.xenproject.org Tue Dec 10 07:17:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Dec 2024 07:17:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851891.1265873 (Exim 4.92) (envelope-from ) id 1tKuV1-0005ws-Ao; Tue, 10 Dec 2024 07:17:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851891.1265873; Tue, 10 Dec 2024 07:17: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 1tKuV1-0005wj-7w; Tue, 10 Dec 2024 07:17:39 +0000 Received: by outflank-mailman (input) for mailman id 851891; Tue, 10 Dec 2024 07:17: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 1tKuV0-0005pk-Jw for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 07:17:38 +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 d562cab3-b6c6-11ef-a0d5-8be0dac302b0; Tue, 10 Dec 2024 08:17:37 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-38633b5dbcfso2628099f8f.2 for ; Mon, 09 Dec 2024 23:17:37 -0800 (PST) Received: from ?IPV6:2003:ca:b746:63c:a58f:4219:ab5d:cf03? (p200300cab746063ca58f4219ab5dcf03.dip0.t-ipconnect.de. [2003:ca:b746:63c:a58f:4219:ab5d:cf03]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3862e52a96csm11645346f8f.33.2024.12.09.23.17.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 23:17: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: d562cab3-b6c6-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733815057; x=1734419857; 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=1Juq6WqKgwtWs4FOuT6Ymg/mdR62ofayr2Su4F4rhCw=; b=WeIbIa/AMUOHKCge5hYkz3wO8OdMH5lwLuBJoy1/RjDHTk1qI4BD3H1LlXSXf40C91 Lo4lIxMjp3Lx1Qc9PIkxsiNVyVYIEFY2V5ckC8Dmyg0gRe6QhcexBKjer4rEM3JZjJXp nwMGPPtfvUZj8HH1Ah3SeFOChMJvbtE5+xHUQAGrm1ye5YQ5yAvjQNuCoJmUMIRW9jL8 S0rK1gguFtEEOm/4zR+f0+pTSRd3dJxhHGGtyWgQXXwiV39C2uI9dg9CnBYZEojC74Td p8sYQDxrt0xtO5Flj1htbqmHkCiYCimXMEFiZZCdlFbtqlFkkv27oKNBod1RQcEV4U8/ RsaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733815057; x=1734419857; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=1Juq6WqKgwtWs4FOuT6Ymg/mdR62ofayr2Su4F4rhCw=; b=CLB4J/Iab8CR1lRojY2DaMVsO/D7UgC9UHtRQ5+ATKKnUNMgSMauu7NIVOyXA1Jklt oCAR2wRD3EdeHLz/WbSBmEEgkBUq385KOP3rONymGBHwjNEmfoM7yMGxThAshD+4z+Jy gH8kagmuW2qLvCs5pfSoUrPFFvgHG6CDuj/CemcdM+SOlo2T82nO9oXe04ai30/W5az4 a6hqc43k9qsNnf173duBOaJ0Tf00QbmDKBMJ/BfAM+48HCPGarOKoOyn08InFz3mO0vQ kKLoU+tL0s0T7iRXNjViCzukAxrOmFr1PgOpDW9EuDskLIIoT+6HkPQOnH8Vwf0tcQRm Q0vA== X-Forwarded-Encrypted: i=1; AJvYcCVAJ6EvJFb/w/veSRz16JWSht/jhVWnm6wIUp0XK90FEirLvGCsf0DfEVXQB7ikijtf8VXZ9d27OuY=@lists.xenproject.org X-Gm-Message-State: AOJu0YwatS61ork7t13PssPeVdvirNobBPfjvxtDkk95uHJiAfRNj99U fFF1SjQBoVj8Q8i74Tz07LmaJc4faaYqYNSO7MJQzBMaWNH3D96RNMLl0ggYQg== X-Gm-Gg: ASbGncv+mXj/v50B0lOxTPyYDrWCfSjX26yAw4qQyaA1EvtzEHn8Sl2hfhd8W5Mgy7q a2OvN+hCt7hF4ZZC15GgP1xH6GFESxMdMtffcFYrlkIDnD5huaT2HLVLL9HH9pBWWL67JpARE5z scL7dAzNVfZRxvlZmX72gzWUXd0VvKTmHWjKhNQlEf/3qbeH/jDBtNIpvXRL24SCMIMf5hecnft A746XEVITxIc+DnwQWZX1VsGRyoCVAJ154LVUtfGJdgle34d+rS6+XwO7qxy96mFdebfJAZxfJP /gV2ERo9tvhArYvskx/Qx9ABOkFlbD+7Ui0hauPe6UR8VjS19eIK7M0PuPc7t4hrOABeqdHjnYR jnr9XYXkl6w== X-Google-Smtp-Source: AGHT+IF7MlPoFurWAOAWaiWg1w/Hl3IzUGIlmSTlJxRJu2fF1BQJBBEROZJvaVxQjo9lHlg17MSICw== X-Received: by 2002:a5d:5f53:0:b0:385:ee3f:5cbf with SMTP id ffacd0b85a97d-386453da317mr2745873f8f.20.1733815056726; Mon, 09 Dec 2024 23:17:36 -0800 (PST) Message-ID: <1e0576d9-400e-4483-8dd1-061e215a00cd@suse.com> Date: Tue, 10 Dec 2024 08:17:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support To: "Chen, Jiqian" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , "Huang, Ray" , "xen-devel@lists.xenproject.org" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20241202060956.1124162-1-Jiqian.Chen@amd.com> <4e4df0ee-67f6-41e3-bfc7-e78011680015@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 10.12.2024 08:07, Chen, Jiqian wrote: > On 2024/12/9 21:59, Jan Beulich wrote: >> On 02.12.2024 07:09, Jiqian Chen wrote: >>> --- /dev/null >>> +++ b/xen/drivers/vpci/rebar.c >>> @@ -0,0 +1,93 @@ >>> +/* SPDX-License-Identifier: GPL-2.0-or-later */ >> >> Was this a deliberate decision? We default to GPL-2.0-only, I think. > Will change to GPL-2.0-only. > What's the difference between GPL-2.0-only and GPL-2.0-or-later? As the name says, the latter includes any known or yet to be written newer versions of the GPL. >>> +/* >>> + * Copyright (C) 2024 Advanced Micro Devices, Inc. All Rights Reserved. >>> + * >>> + * Author: Jiqian Chen >>> + */ >>> + >>> +#include >>> +#include >>> + >>> +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev, >>> + unsigned int reg, >>> + uint32_t val, >>> + void *data) >>> +{ >>> + uint64_t size; >>> + unsigned int index; >>> + struct vpci_bar *bars = data; >>> + >>> + if ( pci_conf_read16(pdev->sbdf, PCI_COMMAND) & PCI_COMMAND_MEMORY ) >>> + return; >> >> I don't think something like this can go uncommented. I don't think the >> spec mandates to drop writes in this situation? > Spec says: Software must clear the Memory Space Enable bit in the Command register before writing the BAR Size field. > This check is suggested by Roger and it really helps to prevent erroneous writes in this case, > such as the result of debugging with Roger in the previous version. > I will add the spec's sentences as comments here in next version. What you quote from the spec may not be enough as a comment here. There's no direct implication that the write would simply be dropped on the floor if the bit is still set. So I think you want to go a little beyond just quoting from the spec. >>> + if ( rc ) >>> + { >>> + printk("%pp: add register for PCI_REBAR_CAP failed (rc=%d)\n", >>> + &pdev->sbdf, rc); >>> + break; >>> + } >>> + >>> + rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write, >>> + rebar_offset + PCI_REBAR_CTRL, 4, >>> + pdev->vpci->header.bars); >>> + if ( rc ) >>> + { >>> + printk("%pp: add register for PCI_REBAR_CTRL failed %d\n", >>> + &pdev->sbdf, rc); >>> + break; >> >> Is it correct to keep the other handler installed? After all ... > Will change to "return rc;" here and above in next version. I'm not convinced this is what we want, as per ... >>> + } >>> + } >>> + >>> + return 0; >> >> ... you - imo sensibly - aren't communicating the error back up (to allow >> the device to be used without BAR resizing. ... what I said here. >>> @@ -541,6 +542,16 @@ >>> #define PCI_VNDR_HEADER_REV(x) (((x) >> 16) & 0xf) >>> #define PCI_VNDR_HEADER_LEN(x) (((x) >> 20) & 0xfff) >>> >>> +/* Resizable BARs */ >>> +#define PCI_REBAR_CAP 4 /* capability register */ >>> +#define PCI_REBAR_CAP_SIZES 0xFFFFFFF0 /* supported BAR sizes */ >> >> Misra demands that this have a U suffix. > Do below PCI_REBAR_CTRL_BAR_IDX, PCI_REBAR_CTRL_NBAR_MASK and PCI_REBAR_CTRL_BAR_SIZE also need a U suffix? They may want to gain them for consistency, but they don't strictly need them. I wanted to say "See the rest of the file", but it looks like the file wasn't cleaned up yet Misra-wise. >>> +#define PCI_REBAR_CTRL 8 /* control register */ >>> +#define PCI_REBAR_CTRL_BAR_IDX 0x00000007 /* BAR index */ >>> +#define PCI_REBAR_CTRL_NBAR_MASK 0x000000E0 /* # of resizable BARs */ >>> +#define PCI_REBAR_CTRL_BAR_SIZE 0x00001F00 /* BAR size */ >>> +#define PCI_REBAR_CTRL_SIZE(v) \ >>> + (1UL << (MASK_EXTR(v, PCI_REBAR_CTRL_BAR_SIZE) + 20)) >> >> The literal 20 (appearing here the 2nd time) also wants hiding behind a >> #define. > OK, will add " #define PCI_REBAR_SIZE_UNIT_BYTES_LEN 20" to replace above two '20' case. What is "UNIT_BYTES_LEN" there? There's nothing byte-ish here, I don't think, 20 is simply the shift bias. Jan From xen-devel-bounces@lists.xenproject.org Tue Dec 10 07:17:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Dec 2024 07:17:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851890.1265862 (Exim 4.92) (envelope-from ) id 1tKuUz-0005iM-Vf; Tue, 10 Dec 2024 07:17:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851890.1265862; Tue, 10 Dec 2024 07:17:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKuUz-0005iF-Ss; Tue, 10 Dec 2024 07:17:37 +0000 Received: by outflank-mailman (input) for mailman id 851890; Tue, 10 Dec 2024 07:17: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 1tKuUy-0005i9-4G for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 07:17:36 +0000 Received: from NAM02-DM3-obe.outbound.protection.outlook.com (mail-dm3nam02on20607.outbound.protection.outlook.com [2a01:111:f403:2405::607]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d2da0656-b6c6-11ef-99a3-01e77a169b0f; Tue, 10 Dec 2024 08:17:34 +0100 (CET) Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18) by DS7PR12MB9503.namprd12.prod.outlook.com (2603:10b6:8:251::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Tue, 10 Dec 2024 07:17:30 +0000 Received: from BL1PR12MB5849.namprd12.prod.outlook.com ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com ([fe80::b77f:9333:3a5a:d285%3]) with mapi id 15.20.8230.010; Tue, 10 Dec 2024 07:17: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: d2da0656-b6c6-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Kro/ipH8Q4KDMqv7ySHO0CHfWPyfqTgXIu9jmjew2qliVRPeP2N3gKl+6dmjTXEaAXHuIZNXKsIECWZYvBPKz+CMi8vG8QpAW2q4tH7aQAMQsle7Gk1pABweSAZ9R7s/gAsx2EQ2i2Rr8Bp82i2ZgP45b53VwZLy71DWIkP1hihKwJKrfpaa+P9OunCiPmkCvxPED6nxj73IhrgtlIMuxkEhWk6CBr/+twFHBrRrN+jsbpCFK1QVf29xdFQAajxLPU0E9yd0O/559O73e4dUqZm0cf8ytK7/OP3yTTdFgle/5v3QiE65hcTuSQHFbb4/PWjeawivWRUd2QNat98StA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+NGLjlrSD3dU4ZgxJf8dhYbDMLvlKQyK8dPKaHoyDmY=; b=nrTLgnjU0jSPtjNFQD/HnmBaX6pnutJQDITA13DIeTfSJ4rbhJydaLyG2crOLALpFJZNEToQcne8fgO+k/BC9QuO4OF12DlSB8TlGhmyVoPU5HfQMeLYEk0XUY2bZo86PNznTtxfrsU/vLrXSzVwIl8rL5HWL8r91IaeoFRc8qQv8RZTUvnyLC5JTSBgwRJ4RO1m+TKXcQwQIyNZEtrjaT1QvQQFeY/8+wK8749HsyHHPTitWuf5X1Eg8Hcan1M7Osm+FhsHVqIZqU6DzXgJQRX6sP/hxixLmrwsW7QE6hqnNEgAV4FrO+acXoqQqygfbjAzSiMcSdJYobe8jtIyEA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+NGLjlrSD3dU4ZgxJf8dhYbDMLvlKQyK8dPKaHoyDmY=; b=MtnM30QW85W5O783Mg1se2YDLGGaWN04yaYNjbKhFZde8hqUKHSZrOCJ70wkYr5bwyvlB5PeqaESrlfzwxU7ZHsMpWz88JsS8rxsRfxp+6xbru2Wrtv+MjwRxPD0zSXVbPanMWc4JQR+R/KpcvetbFZU0oD9sUkqSgqFqh3kwfA= From: "Chen, Jiqian" To: Anthony PERARD , "Hildebrand, Stewart" CC: Stefano Stabellini , Paul Durrant , "Edgar E . Iglesias" , "Michael S. Tsirkin" , Marcel Apfelbaum , "qemu-devel@nongnu.org" , "xen-devel@lists.xenproject.org" , "Huang, Ray" , "Chen, Jiqian" Subject: Re: [QEMU PATCH v10] xen/passthrough: use gsi to map pirq when dom0 is PVH Thread-Topic: [QEMU PATCH v10] xen/passthrough: use gsi to map pirq when dom0 is PVH Thread-Index: AQHbMBN9zgKXu6QHp0mudGAMtCr+w7K9RysAgCKFMIA= Date: Tue, 10 Dec 2024 07:17:30 +0000 Message-ID: References: <20241106061418.3655304-1-Jiqian.Chen@amd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com (15.20.8230.010) authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|DS7PR12MB9503:EE_ x-ms-office365-filtering-correlation-id: 19124c92-06ea-427c-492f-08dd18eab5b3 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018; x-microsoft-antispam-message-info: =?utf-8?B?a0lyRXd4TGRNREdIOElYbnM0WEVid3ZFb1JCZVg1U2tPTVFoUngxZzZnRXFh?= =?utf-8?B?LytxS0xCT1ZBZElzcDBTakV5ZnEvOVJqZk5QYUU5c1BlZmlZdGsvZDRGaE1Y?= =?utf-8?B?UkwvcVBnZDFSUmNVZkpSSjgwU2hGcHpUZmIwcnA4MFVUVGgxS25zeWhiRGpw?= =?utf-8?B?SUYwUVZMbm4vNllsR25EYlhxOFpVUFh6TlUzSWttaTJXZzVCK25BbUt5TTJn?= =?utf-8?B?QmJCTVlBTW0waktnRUpNNTlQMlM2aGFGakYyZnJNUUpRR1lvVmdjTFBvWDdZ?= =?utf-8?B?b2NjZWF1YmJQZnBBcHBJc3VzNDVISDZrbU9jY0ZJbzBvVTRuVnRaMmxCclky?= =?utf-8?B?bXljcklrU3NyZDJtUXFGWmdrcFVtZnA2NHh2Wkw0dWlwUDIweU5udklXdjh1?= =?utf-8?B?ZWVoMUdIUTdZcWRPOWJ1cVI0S3cvUkx5WmN4NW00OXRLOTRSWEZUOVdqQUFX?= =?utf-8?B?LzkxMWpPaC9pNWpsb016QkhlakdaSktURzlucU12MlBMMG91OFZERmJhbTl4?= =?utf-8?B?bWk2bitDZHBsdGxZcjJsZlBoRkQvMkVsc1NNWjMwK1lwSHVMd0szVGZHWWlk?= =?utf-8?B?THlXS1pQSnlGUXhwUXBIN1pSVjAyTVp2U055cXlEVEpGNEc2RWxOeHByV0Jj?= =?utf-8?B?WUJWaTB6RkQwY0xnQUNTellEYzhTZ1BQRCtBZHk0MS9QWHBYYlVSanVkeTlr?= =?utf-8?B?RjB4eHBOV0RGMmw4eVhKd2pxNW1sS2NIcVN6b2VuL2JhaWVpS3RoL3h4UkJw?= =?utf-8?B?c2hTK0JpSXBneWwrMXhqb2E0SHZud3lEQ1AzVEZaODJOZDR5SjAzbXV2a2Zk?= =?utf-8?B?RXVyZjR4eEwzRzBPNkhjN3l6R3NMbUxIYVZNVHhOWGlqdWlndk55SGRTKzlz?= =?utf-8?B?Q08vNGdXZ29BVEQwTkhqS0dwei8wZjVtTEVsanZvaWFycmM1bWdpZmNQQVBk?= =?utf-8?B?YUZubWFGUTU4M24rN0gzSTJPM1J2YUd5ZjZMTFR0M2tqUjJJNUhRcklOU2pU?= =?utf-8?B?VnUrOTdWcnhpSE8zVG51UnpQUkpnRkZWNFd4c2E3cHAzRGc3OEJiOFBsWGZq?= =?utf-8?B?Wm4yaUsvMHowQkJFTzlsQVg1UC9mYWJqRGV1REVrdDNPclZBTEF6SEpPRWdN?= =?utf-8?B?QUhFK1hOQ3E5RXFRVDBac1BpZkdsVUpZcVdEbzk1cXZLOXpPLzRIOTgxaHZ4?= =?utf-8?B?WmE4L1hjQkNiZUdTODlhSHhxTExCV3d5a0Z1UGc2ZjBlYXJsaTBDd2U1KzND?= =?utf-8?B?b0tyZ29OQ0RTQnI0Wi9vT2lZSzRvQk5Xc2c2UG5SZHpSVUgxbkZMRG1WUE4x?= =?utf-8?B?WnRjRFdkeUdVaWhtK1d3R2R5b2huMGtUTjFMWjBQb0ZNQTdxOEtKN1B4Z1gx?= =?utf-8?B?dVVUb0NpMlFsdy8yOVg5ZWsyUTV2L2JBaWlkZXRDMHIxQXUxYmxVRXNZYmtH?= =?utf-8?B?VTdpNVlNYUFsU2tUMHJrbEpKV012blMvVmg2Mlo2b0hsbjhxTi9haEtrK05x?= =?utf-8?B?Y2xsT3ZOQzhUTDZMTFZ0K3d3Rm4yN0E3a0ZwRzJvdlc0VU1sRW5nWGdBV3Ez?= =?utf-8?B?U2txUVZOUjhkOUY0eUhOUFFhU0NBdnNhUUdNNG5SNEIzSyt6NGJ3N1MzYkEv?= =?utf-8?B?YU9FbW5XV0xNYnhjYmN4d3ZvVTdQVVJkWjZZdmNmMGVpWkRDTEtjeW5GZ3pk?= =?utf-8?B?UG93V24yY3ZJYVN6b0luY1RHM0tDdGNGNXhuMXkrTjB6ck9jNzBxVldoYXRD?= =?utf-8?B?RUx1TFc5TkFNaTd4b3lsdkxza3RtQmRXT0lzSXJHVE9vOVZsbHVKUmV1WXE4?= =?utf-8?B?Um1LM2Mwa3dFdk9rOENKeWoyQi8ycXBENWRpUU9DZ0FUeTZQSEI3SXEzeWhS?= =?utf-8?B?RlQ5WlIxUGlLbXZzalRVWEVvZUVSV0oyYytRRmJkUjg4SXc9PQ==?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bldiVVB5Y2JpZEptUWdCY2Y3ekErNTk2cGlRUGRERU1oU3pac1lMUXBYR2kv?= =?utf-8?B?SE9jTG8veHFkTnBlRUtEODFhSHRwN3hEcFJORDV2RXBCNlVNbm1YejNmSlhE?= =?utf-8?B?QkM0cHFvZEdVbTJRQlBzUzJnSEZSRjVxOGYrOTBncVdGQjBTNHNDZUE2bGJ3?= =?utf-8?B?c1FmZ3BxWkVkV0ZmUkFlTEcvem9oTzRYcDhTdHcyU2thQm56MzVUS3piV1dy?= =?utf-8?B?VlR6WjZmSElSbTJ0SWJDZW1rMlBrNWlhcXp1MWhzdjdyNE5xZ3d1bSsrS2Zy?= =?utf-8?B?b0VJdzRyc04yUDI0WVJVZHlIem5VVDRqcG1ncnpHcDU0Y2NxT3MrVVFUVW95?= =?utf-8?B?Wk80aUFSVmc2ajFMczdtbGllTjhHc2c2Vk9wV2szbFRHS0ZJM1lXZW5mRTdo?= =?utf-8?B?WUo5enZJSi82czFTbW40Vi95dkQzYzhkL2pJQU9ONkhkRWg5OHErcFlSV2VI?= =?utf-8?B?SXlaR2dPaWNLNCtNOCtaVHhqWE04UDQ1UzQyU0I1OUVYRVZZRjVHVDBWa0JP?= =?utf-8?B?THBPckhubk5yTkRlR0E0TFBqdUFrcGwraTlOMis0VDd6anNGSXVVZkdrZTRQ?= =?utf-8?B?WHdkNDVmQzNBdTdMUGI4L053cU9ldTRreEg1RlhpTTZOSEJlNVBhQ0p0Qmdh?= =?utf-8?B?d29WSVZ5UHlIRzRFbUdHTUZYeUg5RzhvUVovQnJUYnlwWHJma0ZnOWlyeUFp?= =?utf-8?B?azRqOGdDWWNNampFRnJmbkJFMkdyQzY5QWc3NXJEeEdtWk5abVIwQWVWSnRV?= =?utf-8?B?b0ZlNFA0Tms5My8zd3RYYVhCVDhnRGI3S0x4VitnZzI2YWQ2c2Y2bmQyZDk5?= =?utf-8?B?RWFQb0hkUzRDNG9RZGZuT2NScXFUdUNNTUNaT0VtYUdCWCt0dm1WRDB5K21B?= =?utf-8?B?ZzJMM3NScFY2TVlBVTcvR1BBSzYvNFl2ZFB6bDlKdUlKaDk4MmFDekVWbmtL?= =?utf-8?B?Q3VEa3VxZEdHRjNGTTFXR2kzSlMyRE42ck1ISzV6Vld2bERNa3R6Q1R3QjND?= =?utf-8?B?Qld1N3Z3UXJRQ1o4SDFJK0R0VFNtRWcwL3lHY3MxcVRtT1QrY0ZJZVo3cHZ5?= =?utf-8?B?WDNLeDk4WXkrUEZNUFNkYUxNbHpkOXAwWlh0a2JaNGkwa2JUTTYvYVJBQ2pK?= =?utf-8?B?QTFPZDRBODZuRjdIcWFnTWd4TlhpQ3hxWXlOMUI5SnRtOU1RVkdJdjVCMHRN?= =?utf-8?B?QktQYVBWd0ZkMVo3V24zZ3Fzd20vRlZLeGViMXVENWo0d1p5RXNSckxkUU96?= =?utf-8?B?VWRwVkpzTkN1azNQK00wRGxwbGFTa0JodlMxSkNOYnR4R01DbEExa3lqaStI?= =?utf-8?B?dHdFM25zbmJpSlhuc2xqM1NWTk5QcGNZUE1NUVBBdnBpaHRBWW5zMnl2bWxQ?= =?utf-8?B?bmZ5Wk5mMEZQcTFZcDMzV0tFNGJXOFhPV1VHWXZ3V005R3c5dmdxRlludWpD?= =?utf-8?B?SzV2M0dNQUhVZy9ER3UzdWVvQnpveWNXMkR3MlZQdldIa2RUcVZuN1E1MWdH?= =?utf-8?B?MWFBSHc0c0hQdDFvd09TYUpvcHRla3UyOHZIVmVCSHhHaVREZmR3dGdma01s?= =?utf-8?B?MWk2WVhDeDBEVnNkd0daSkgrOTE0OGloZ2NKMmJRQkptSGgzT3BQOGFmaDF5?= =?utf-8?B?b0J0N2RtZEdsa3JLbHlna3lsbWd1R1BzcFd3NVdNU01pQjUxUFJTS2FuWUla?= =?utf-8?B?SWlrRGs0SXV5Z2F4TDVoallvdjd5ZWxncVA2OStGNVZITkZ4STg0MnpTUmlM?= =?utf-8?B?VUorTHhaUjIybkpaY3pSTm03U0NCRG5ZRjdKUHh3QVZYOGVnM09tVFVwZERz?= =?utf-8?B?RHgrNXBTUDlGVldhL1FoTkcwSy9lSUsycC9wSDRpTjdRV1c1SjJTOTdCYU9J?= =?utf-8?B?SjdoOGNQZkdkeC9yR1dlTUZmL2d0dkJ0WkkySWhYZmp4UlhnS29XN2lCUUtZ?= =?utf-8?B?Ykx3Y1RjbDRWOURPUy9tOG9WbU8xVXRnN1dYTmp0Nnh0U1pVWmVIaFR3Ym95?= =?utf-8?B?Tkc5NEMyV2RVUDNHMnZQOC9BbVNtOFNURHhHRUN0SnF6dW43SE40N0NsVDJv?= =?utf-8?B?dFBzYzdLVzJNblQxOVpRRStxdm5qT2RQSk4xaXV5MTE2cmM1OVowekQ3KzMz?= =?utf-8?Q?PY4s=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <4DDD392F4AB7F8419E1F05A0129F2A5E@amdcloud.onmicrosoft.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 19124c92-06ea-427c-492f-08dd18eab5b3 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2024 07:17:30.6029 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZLY4M0g6ndmXQH5E/Y347Z2PdI/Vp3AJyEgByYqAQVT+Pk7b5Xe3GGhzCH7yBL/xcA8SAXKxbuSTkCbnfJ7aYQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB9503 T24gMjAyNC8xMS8xOSAwMDowNSwgQW50aG9ueSBQRVJBUkQgd3JvdGU6DQo+IE9uIFdlZCwgTm92 IDA2LCAyMDI0IGF0IDAyOjE0OjE4UE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4gSW4g UFZIIGRvbTAsIHdoZW4gcGFzc3Rocm91Z2ggYSBkZXZpY2UgdG8gZG9tVSwgUUVNVSBjb2RlDQo+ PiB4ZW5fcHRfcmVhbGl6ZS0+eGNfcGh5c2Rldl9tYXBfcGlycSB3YW50cyB0byB1c2UgZ3NpLCBi dXQgaW4gY3VycmVudCBjb2Rlcw0KPj4gdGhlIGdzaSBudW1iZXIgaXMgZ290IGZyb20gZmlsZSAv c3lzL2J1cy9wY2kvZGV2aWNlcy88c2JkZj4vaXJxLCB0aGF0IGlzDQo+PiB3cm9uZywgYmVjYXVz ZSBpcnEgaXMgbm90IGVxdWFsIHdpdGggZ3NpLCB0aGV5IGFyZSBpbiBkaWZmZXJlbnQgc3BhY2Vz LCBzbw0KPj4gcGlycSBtYXBwaW5nIGZhaWxzLg0KPj4NCj4+IFRvIHNvbHZlIGFib3ZlIHByb2Js ZW0sIHVzZSBuZXcgaW50ZXJmYWNlIG9mIFhlbiwgeGNfcGNpZGV2X2dldF9nc2kgdG8gZ2V0DQo+ PiBnc2kgYW5kIHVzZSB4Y19waHlzZGV2X21hcF9waXJxX2dzaSB0byBtYXAgcGlycSB3aGVuIGRv bTAgaXMgUFZILg0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IEppcWlhbiBDaGVuIDxKaXFpYW4uQ2hl bkBhbWQuY29tPg0KPj4gU2lnbmVkLW9mZi1ieTogSHVhbmcgUnVpIDxyYXkuaHVhbmdAYW1kLmNv bT4NCj4+IFNpZ25lZC1vZmYtYnk6IEppcWlhbiBDaGVuIDxKaXFpYW4uQ2hlbkBhbWQuY29tPg0K PiANCj4gQWNrZWQtYnk6IEFudGhvbnkgUEVSQVJEIDxhbnRob255QHhlbnByb2plY3Qub3JnPg0K PiANCj4gQnV0LCB0aGlzIGZvbGxvd2luZyBjaGFuZ2UgcHJvYmFibHkgbmVlZHMgYW4gYWNrIGZy b20gUENJIG1haW50YW5lcnMsDQo+IENDZWQuDQpBcyBQQ0kgbWFpbnRhaW5lcnMgZGlkbid0IHJl c3BvbnNlIGZvciB3ZWVrcywNCmNhbiBJIGp1c3QgbW92ZSB0aGUgZGVmaW5pdGlvbiBvZiB0aGUg bWFjcm8gYmFjayB0byB4ZW5fcHQuYyBmaWxlID8NCg0KPiANCj4+IGRpZmYgLS1naXQgYS9pbmNs dWRlL2h3L3BjaS9wY2kuaCBiL2luY2x1ZGUvaHcvcGNpL3BjaS5oDQo+PiBpbmRleCBlYjI2Y2Fj ODEwOTguLjA3ODA1YWE4YTVmMyAxMDA2NDQNCj4+IC0tLSBhL2luY2x1ZGUvaHcvcGNpL3BjaS5o DQo+PiArKysgYi9pbmNsdWRlL2h3L3BjaS9wY2kuaA0KPj4gQEAgLTIzLDYgKzIzLDEwIEBAIGV4 dGVybiBib29sIHBjaV9hdmFpbGFibGU7DQo+PiAgI2RlZmluZSBQQ0lfU0xPVF9NQVggICAgICAg ICAgICAzMg0KPj4gICNkZWZpbmUgUENJX0ZVTkNfTUFYICAgICAgICAgICAgOA0KPj4gIA0KPj4g KyNkZWZpbmUgUENJX1NCREYoc2VnLCBidXMsIGRldiwgZnVuYykgXA0KPj4gKyAgICAgICAgICAg ICgoKCh1aW50MzJfdCkoc2VnKSkgPDwgMTYpIHwgXA0KPj4gKyAgICAgICAgICAgIChQQ0lfQlVJ TERfQkRGKGJ1cywgUENJX0RFVkZOKGRldiwgZnVuYykpKSkNCj4+ICsNCj4+ICAvKiBDbGFzcywg VmVuZG9yIGFuZCBEZXZpY2UgSURzIGZyb20gTGludXgncyBwY2lfaWRzLmggKi8NCj4+ICAjaW5j bHVkZSAiaHcvcGNpL3BjaV9pZHMuaCINCj4gDQo+IFRoYW5rcywNCj4gDQoNCi0tIA0KQmVzdCBy ZWdhcmRzLA0KSmlxaWFuIENoZW4uDQo= From xen-devel-bounces@lists.xenproject.org Tue Dec 10 07:57:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Dec 2024 07:57:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851918.1265883 (Exim 4.92) (envelope-from ) id 1tKv7g-00040Y-AR; Tue, 10 Dec 2024 07:57:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851918.1265883; Tue, 10 Dec 2024 07:57: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 1tKv7g-00040R-6c; Tue, 10 Dec 2024 07:57:36 +0000 Received: by outflank-mailman (input) for mailman id 851918; Tue, 10 Dec 2024 07:57: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 1tKv7f-00040L-3T for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 07:57:35 +0000 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on20615.outbound.protection.outlook.com [2a01:111:f403:2418::615]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 695e50a6-b6cc-11ef-a0d5-8be0dac302b0; Tue, 10 Dec 2024 08:57:33 +0100 (CET) Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18) by SJ0PR12MB7083.namprd12.prod.outlook.com (2603:10b6:a03:4ae::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Tue, 10 Dec 2024 07:57:28 +0000 Received: from BL1PR12MB5849.namprd12.prod.outlook.com ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com ([fe80::b77f:9333:3a5a:d285%3]) with mapi id 15.20.8230.010; Tue, 10 Dec 2024 07:57: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: 695e50a6-b6cc-11ef-a0d5-8be0dac302b0 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xFwxfVc7Of3WbKsz2LltFCPhCjg2BeSCfJ1PpRBpsJ4P7wA72CGo4GCWs/UsU5hZuINynxo+EdG60wxNmALlLahrt2kRdHsJ6SJnD+wiJReu2bKgw8vZ0/t2JXHrIlCv37opoXlx6i3gdHx6sjT0xKVVko5EqFW9x9bat7AX219d3tAfZi7WGVCU9w36OJJkWQGDApzOpHP66uSwFnRYoe+Aico6JLvcbnqCcaH0hZNfdfhrfJo7RELRM57dWQ3qB7hUGTbjxv2913o19vdZhhdKhdGMd8ek1n5UuHsCV7nyBcl79UkQxFZlNAbRkNu4FEmIhE4uRnxhP/XFeY7oIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3elfN4RTw+8FCfJOKqQC7EiHtRdqbV/rdh8IiPozV5k=; b=WPdmHo/FdMhGuzpfl0RqaKm0P/Gj3EAh5qbGkj8WDmWi7oT6tBgibbGAHis69x9XKmvDs4k0kSY4OTiNdgxRP8jMdx4qphX8zv3CRCH1UZGCWDUzvaKH6xY8Qp97ZpjBM0IOhyjwoTXLlZGgc6x0HbyUlGHrVAdwNFUiHKwPXkUQo/8rMAaLOwN5Llxx6s5oE8yQfsD1w3WB6IcKG5wkd18AgThGWRioLEiSvOcyNpOT4NVZdU28KdbNL8FkTgvmzdWUZ/LTUprLkjbezPG7p4uI0Y2F7AnIlNwahUvyIbkJjUTaSlUg+FvLyfzsXvfM5BD/EI6d0SGtItC3u7RC/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3elfN4RTw+8FCfJOKqQC7EiHtRdqbV/rdh8IiPozV5k=; b=Uju2jukkezL8JilPQUbzjc5zUHU2ULyLzlZBXqJsfsNqVBIT0X+XP8MSvIBkhtEhHVO5uhlFhlwc/YX6RAXhbRS/1oQclTRD1NP+FAE4FLZe6cOypTSmXppYKgc7DuPvfOJgMxjCqOHyT8/4bIiaKE7auqL5VTvHrEjsPM8Aov0= From: "Chen, Jiqian" To: Jan Beulich CC: Andrew Cooper , Julien Grall , Stefano Stabellini , "Huang, Ray" , "xen-devel@lists.xenproject.org" , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , "Chen, Jiqian" Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support Thread-Topic: [PATCH v2 1/1] vpci: Add resizable bar support Thread-Index: AQHbRIDgGHZ3ofHO0UuqqXvn+EZCabLd/CGAgAGXh4D//4qBgIAAiieA Date: Tue, 10 Dec 2024 07:57:28 +0000 Message-ID: References: <20241202060956.1124162-1-Jiqian.Chen@amd.com> <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com> <1e0576d9-400e-4483-8dd1-061e215a00cd@suse.com> In-Reply-To: <1e0576d9-400e-4483-8dd1-061e215a00cd@suse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com (15.20.8230.010) authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|SJ0PR12MB7083:EE_ x-ms-office365-filtering-correlation-id: 19ce63c0-2597-4a59-857b-08dd18f04af6 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700018; x-microsoft-antispam-message-info: =?utf-8?B?ZVgyRWJFOXlROEdLRE5vamFhRHVDQi9vVVRNejQzVkhadE4vcTJOc3MxbDBR?= =?utf-8?B?UzYza21QWENjcHVZdWVGQkI2emlLOHJ4dDB1OXF6N1l0dmxXWFBEY3g5Q1VM?= =?utf-8?B?Um1EUjJPekxtdDBRMzYxMFUzeFhXREkvZkVIeTk4SGNQbUVEN0k3eGowZ0JT?= =?utf-8?B?NGlHcE9QaFIyOC9tR3NXdDZ0YWRtSk9RTEVna3FISmorVCtaQXRNRkRtZkxH?= =?utf-8?B?WXZoTzJZR3VsbmZrYURtRXhEd2xnNG5xNjU1ZGNoZ2I4WDhHdE12OXJsSkcv?= =?utf-8?B?eHNBRXI5WEY4UGlSbVRkRWcxZkZhSTd4T1FBZmVqTjBid0tHRmdHNW1ENXhh?= =?utf-8?B?Y08reUZ6NE1rRnF6VndGUG00VDZQWk5US3BkU2dkbSsyZUIyNk8xdEx1UWd2?= =?utf-8?B?WXc5Y0hTT1pmb24yc0p2WHNLNW12aTJvVEFmUzFZbTZ6cDRpaWphNnpoanRJ?= =?utf-8?B?eHB1V3BHYkl6WjNlUnYxMHZjajVSRGo3WlNCb0o4cDhvcURPRE9vK0gyTE1P?= =?utf-8?B?aG11N3VxSjVUMGUzRjdiSHdla3UzS1BUZlZuRkRBZE0rbkdFZnlVMGlTcndl?= =?utf-8?B?M2JadEJvWHdNU0U0MmhiQmkxdndrZ0QydkJZZGtjL3RQV0dSMVRSdnBPaGJG?= =?utf-8?B?L2dkcWxMZGNJbkpQRHB5RFdFZWlieUxBdm43Z2syN1pYN0dhYUFQRW1oWHNH?= =?utf-8?B?UmlSQ1B0Zi9MYzZKYjBOempJYWFXeWZHOS9IZEhmVEliMTFaVEw2STc5ZDdt?= =?utf-8?B?NDBFNXBEdUQxYnBqZmcycE0ycmtZODJDVHBpcXNUdDYvSHFHL2d1Z01zMHcw?= =?utf-8?B?VEtYWE41RDdobW1iL0RES3MwVWNqcGRSM1pZaUg5NExzZW1QR2ZOdDRRTW5C?= =?utf-8?B?d1lYRWVzcHBwN1hhbHhaeHEzVkJmalpCTE9zMWJuRkdaRExBOEN5ZFQwOG1H?= =?utf-8?B?RTAySUo2Sk9NMVA4VzZPNGxTbjI3bGUzMFF6a2psZmpBczN1eThMUlJ1VGhU?= =?utf-8?B?dHN4TFdYMWkyaTFmM3VpZmJrc0h1b0RIT1pBaFV3bmpEcVdGL1JBR01CZzVG?= =?utf-8?B?QS9ndElWcVNKT2NMaGx3bENlNXQ4YVl1SDJ6UjBqWjdQZkZYdVl6TTZzaXcr?= =?utf-8?B?Y1hVaE9lZHVzR0ZXQWY0MExEYXp6NjlFb0I4UkJyZDNKRWJUczZzRXVlZ01p?= =?utf-8?B?RWJ4WXNzYUVlRnFxbnQ3RGZ1a25pR3hFaXIrNWxiY2lSM0I4L2xXM29ZMGdn?= =?utf-8?B?T1Y3ZWhpaG1wd1Q2MGdEeGNoQnhVSWZWQkFKeDFtK3BiOWJhYm1ERTkxNjFx?= =?utf-8?B?MUZKdmlUR1BlSFA4bnJSdXNBc1FvamRqcitUZXdWalREbFRrZlpnMUF3cHNP?= =?utf-8?B?dHdwdFcvZlplbklxakppQk1BUG1BTjJNZWFoUmNqMUpCc3N6MEV6bGRra2hC?= =?utf-8?B?SEx5bE9YWWVCSmQrbmdhTllNdlp0Y2lBZHVCakVnRmx6ZDh2ZkhRUXl5cnQ3?= =?utf-8?B?Vy9CdjJoblJZZ0lYeWxJcnQ1dzg5QlFYaHprQ0sxNmU1bmZ1MWdUbU1ZY2oy?= =?utf-8?B?WnFpc0QwR1QvQ3pKYWZBL29UaXBsTkE0bG1HZkhjcFVlNGw4alR2RStrYUJa?= =?utf-8?B?eXpkU3NFd3JuMEJYV1FpbFd1QmdiUXJ1RmFGMWdUcUFEemxDYXI0NWhJTHhZ?= =?utf-8?B?R3VWT3N0V21CVEptMjZ6bGFhVXVSTzN0eUNRMmdza2VNYnJEVjdsODRCVGFj?= =?utf-8?B?STMvWVUxRWMvcHBzWGljOStJY0hibjlkVEVLdUR0aGtSZ0pjcFE4RmczOWw4?= =?utf-8?B?bEZ6TjZVNE5sNnpCLzhxYjNyd0pUWC9wR1BGOWhrY3VScUQyTCtyS0RTMHpk?= =?utf-8?B?UkdWU0c1U0xqY2xrY1ExbTluMUpOZDhqYjdWSjZBTS94cFE9PQ==?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MThJTU9BOUZJMlBHTEFDam12NVlCdzFXR3pra0dzcEp2WXRXZWYvMzNSSUt1?= =?utf-8?B?YVZ1N2lubUpGQlB6VGRZeXpHMStUaTk4eHBnVnhXbVhIVDRlb2lWbjdiTlJE?= =?utf-8?B?Uyt4OHo1QzZpeFB1Z3pKNnJjaFpvd3E2Q3B1ZVJ5cm1mb05ZbVlERGZiTGhw?= =?utf-8?B?K2NkSklWb3p6aitIbVdCTG9FazdwRldKS2haQjY5QXBDcGxKSEJzNW9oVm1I?= =?utf-8?B?QWMreGxTZ0FVYnNla3IzZUgxSVVNVForUEx2a2FlRjFJcDk4d3RieUd3aWZs?= =?utf-8?B?bUpna1NSdUVDOUtQQzVNOEV3UGtML1JwRkJ3aGxxUVhGMUhUT1Z5T1RQL0pw?= =?utf-8?B?ckEvdnY1MTV6dmZkbVc3d2xkOEtpU2FLcFppb1hkQ25uRWx5b2pFaTlhYk9T?= =?utf-8?B?UUx0R2hTT0pabVp1NXlwRFdYdVhTL3dnSVpBSlUwSFRpUmhIck5MeExwWEJt?= =?utf-8?B?RHN5eFkxcytkVGNXUmZPZjcydW10MlU5clNrd0Q5ZDVuK0s5a2NycXI4NGRG?= =?utf-8?B?SGlCbnNhZTI1cXNtbkVBQndwNm5EdmtWWGVhSE5MNzhSL1hEd0FmVW5haTNL?= =?utf-8?B?YTNoQnA0bVZYOG1aVlNnZUlMSzdNcXF6WjdwVU5QbE56MU5SUzJtTFFVS0tk?= =?utf-8?B?V2x6clcrR3hlb2xOWndKZ1k2bjIxbmU3bHF0ZEtWVFJiK09vbjVFRFVEdnp6?= =?utf-8?B?WVEvcE9JV3pwUHAxbzJkQnpxTnpOU2gzblNJMlJUVW5SdjFVaFU2WnRDYW95?= =?utf-8?B?RG1PZGh2cGNPMmx1SFJTSFhPZy8vMHBQQjRpclowNnJrM1pqcFhUeHdCUlYv?= =?utf-8?B?TGFvMUowOGpFV1BtakxTb05sdTlhWVBqcEZhcytTb1d4K1dMUjlGNmNNV2o0?= =?utf-8?B?aCtJZ1gvRHRFM3llUXR3REcrNmQrM2JTZDFwRnFjYXFmS25vcWhFRENvRy9Z?= =?utf-8?B?cjljczA2RFR5VnVrUU1DK280cVd2aG45TDh1VWc2Q2lreGh0VFBsMmxsQVp0?= =?utf-8?B?ZTBwVElNUDNHRWdLZUVOYm53MlNSU2FINnU4dWVZd0ZueUpJeGhLV2lmTFNp?= =?utf-8?B?S3VmSWNYSzdoWHBGZ2NpeUNhS0ZDL2VjSDA4Ujl3RUY0ZFNHWEdZNjRQa0tC?= =?utf-8?B?bE9rNmxjS2pQb2toVVdZWnYydzVjK1o4dStJU2k0a2hPMGlHSDF0dUN0S3FL?= =?utf-8?B?c1BaSFNUWmV2UTFZQ0oxczVxRWhVMk16VHpoL1NnR2pLOERiTUdBSXN0MlpV?= =?utf-8?B?VC9ETFBCNG1UQTZjQVJ1dlVtNlgzUmxXQVBSNDdVQ2VRNisrcERmdnYxSGVl?= =?utf-8?B?WTA4YVFGSXJYZDBoY0kyRVpPS0lCcDhXVlRsbGdlOURPMXd5SzgvdndEMkYz?= =?utf-8?B?N2oyUTdWRW9ic1RjMDNoQkluTnN1T09XaFJRcFg4SVVtVFRZL3VCVkdsT2hz?= =?utf-8?B?cSttSWc2QkVSZXFHSm5LekFKTGJ6NVN2RTY2WVRQVVVsRC9LWnRwWHl2Wjlw?= =?utf-8?B?RGNZWEdxYjZuVFdPK1J1eFgzRS9zL0ozb1hDb1huVjJPV0h0b0xGdEZ2Y0F0?= =?utf-8?B?dEVFUkozdXFudmlFb0pZYmp1V3pWc1o5YllmYnJ2bUQ5NnhMUEhvUGpCZ0kz?= =?utf-8?B?NHduZlI5Skt6Wmp5WmRSUEFPREQwRk1MTUJIQTRXaHBJaVpNYjhGYitFTEo5?= =?utf-8?B?emJOYUpvcjhkaUtTQlRZQVFkRjJTK0lKeW5uOEovcWdwcnhWWEgvL0lqSFlq?= =?utf-8?B?MnlhRE9INXkwMi9aSjdTRWJTUzFObzZiQUVHSGN0b3JhWjVHWE5oVUxhbkdn?= =?utf-8?B?K2puWUdpd3J5VXFEclB3VGIxbVZlTXZ4WGEzUDgxRElydXJhRVV1dG1OVmdX?= =?utf-8?B?dmczck5mcjlkdS9xejQwdFRveFNUaDNIUW84WEwvNkNRZ2t0S1BnQ0NZa1JN?= =?utf-8?B?U3krdVBxY0krZCtOUWlUQldDMHF3bjB4MmJ4NmxhUEgzRFM2ZHFMbFBmbHVE?= =?utf-8?B?N1FYancvZUxQQ1k2V1RlK3k3NzY1UGEzOUR0RHNwM01QTmVHdksyMW9xeGNS?= =?utf-8?B?akRWRVB2akFjbS82NDlqYnRIVXpvY3VlQVZjeWpVTVQ3S1l6WVdBa3lOSWZQ?= =?utf-8?Q?UU94=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 19ce63c0-2597-4a59-857b-08dd18f04af6 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2024 07:57:28.5074 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 52+G5c0kYa9IS4Q3R8J2hFNcyVI1ejk++PPWIBh32m5cmN0lPI55N7UfJVAJsVFaFZtipKuZqcS3KeNxHdCumw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB7083 T24gMjAyNC8xMi8xMCAxNToxNywgSmFuIEJldWxpY2ggd3JvdGU6DQo+IE9uIDEwLjEyLjIwMjQg MDg6MDcsIENoZW4sIEppcWlhbiB3cm90ZToNCj4+IE9uIDIwMjQvMTIvOSAyMTo1OSwgSmFuIEJl dWxpY2ggd3JvdGU6DQo+Pj4gT24gMDIuMTIuMjAyNCAwNzowOSwgSmlxaWFuIENoZW4gd3JvdGU6 DQo+Pj4+IC0tLSAvZGV2L251bGwNCj4+Pj4gKysrIGIveGVuL2RyaXZlcnMvdnBjaS9yZWJhci5j DQo+Pj4+IEBAIC0wLDAgKzEsOTMgQEANCj4+Pj4gKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVy OiBHUEwtMi4wLW9yLWxhdGVyICovDQo+Pj4NCj4+PiBXYXMgdGhpcyBhIGRlbGliZXJhdGUgZGVj aXNpb24/IFdlIGRlZmF1bHQgdG8gR1BMLTIuMC1vbmx5LCBJIHRoaW5rLg0KPj4gV2lsbCBjaGFu Z2UgdG8gR1BMLTIuMC1vbmx5Lg0KPj4gV2hhdCdzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gR1BM LTIuMC1vbmx5IGFuZCBHUEwtMi4wLW9yLWxhdGVyPw0KPiANCj4gQXMgdGhlIG5hbWUgc2F5cywg dGhlIGxhdHRlciBpbmNsdWRlcyBhbnkga25vd24gb3IgeWV0IHRvIGJlIHdyaXR0ZW4gbmV3ZXIN Cj4gdmVyc2lvbnMgb2YgdGhlIEdQTC4NCj4gDQo+Pj4+ICsvKg0KPj4+PiArICogQ29weXJpZ2h0 IChDKSAyMDI0IEFkdmFuY2VkIE1pY3JvIERldmljZXMsIEluYy4gQWxsIFJpZ2h0cyBSZXNlcnZl ZC4NCj4+Pj4gKyAqDQo+Pj4+ICsgKiBBdXRob3I6IEppcWlhbiBDaGVuIDxKaXFpYW4uQ2hlbkBh bWQuY29tPg0KPj4+PiArICovDQo+Pj4+ICsNCj4+Pj4gKyNpbmNsdWRlIDx4ZW4vaHlwZXJjYWxs Lmg+DQo+Pj4+ICsjaW5jbHVkZSA8eGVuL3ZwY2kuaD4NCj4+Pj4gKw0KPj4+PiArc3RhdGljIHZv aWQgY2ZfY2hlY2sgcmViYXJfY3RybF93cml0ZShjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwN Cj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50 IHJlZywNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMy X3QgdmFsLA0KPj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2b2lk ICpkYXRhKQ0KPj4+PiArew0KPj4+PiArICAgIHVpbnQ2NF90IHNpemU7DQo+Pj4+ICsgICAgdW5z aWduZWQgaW50IGluZGV4Ow0KPj4+PiArICAgIHN0cnVjdCB2cGNpX2JhciAqYmFycyA9IGRhdGE7 DQo+Pj4+ICsNCj4+Pj4gKyAgICBpZiAoIHBjaV9jb25mX3JlYWQxNihwZGV2LT5zYmRmLCBQQ0lf Q09NTUFORCkgJiBQQ0lfQ09NTUFORF9NRU1PUlkgKQ0KPj4+PiArICAgICAgICByZXR1cm47DQo+ Pj4NCj4+PiBJIGRvbid0IHRoaW5rIHNvbWV0aGluZyBsaWtlIHRoaXMgY2FuIGdvIHVuY29tbWVu dGVkLiBJIGRvbid0IHRoaW5rIHRoZQ0KPj4+IHNwZWMgbWFuZGF0ZXMgdG8gZHJvcCB3cml0ZXMg aW4gdGhpcyBzaXR1YXRpb24/DQo+PiBTcGVjIHNheXM6IFNvZnR3YXJlIG11c3QgY2xlYXIgdGhl IE1lbW9yeSBTcGFjZSBFbmFibGUgYml0IGluIHRoZSBDb21tYW5kIHJlZ2lzdGVyIGJlZm9yZSB3 cml0aW5nIHRoZSBCQVIgU2l6ZSBmaWVsZC4NCj4+IFRoaXMgY2hlY2sgaXMgc3VnZ2VzdGVkIGJ5 IFJvZ2VyIGFuZCBpdCByZWFsbHkgaGVscHMgdG8gcHJldmVudCBlcnJvbmVvdXMgd3JpdGVzIGlu IHRoaXMgY2FzZSwNCj4+IHN1Y2ggYXMgdGhlIHJlc3VsdCBvZiBkZWJ1Z2dpbmcgd2l0aCBSb2dl ciBpbiB0aGUgcHJldmlvdXMgdmVyc2lvbi4NCj4+IEkgd2lsbCBhZGQgdGhlIHNwZWMncyBzZW50 ZW5jZXMgYXMgY29tbWVudHMgaGVyZSBpbiBuZXh0IHZlcnNpb24uDQo+IA0KPiBXaGF0IHlvdSBx dW90ZSBmcm9tIHRoZSBzcGVjIG1heSBub3QgYmUgZW5vdWdoIGFzIGEgY29tbWVudCBoZXJlLiBU aGVyZSdzDQo+IG5vIGRpcmVjdCBpbXBsaWNhdGlvbiB0aGF0IHRoZSB3cml0ZSB3b3VsZCBzaW1w bHkgYmUgZHJvcHBlZCBvbiB0aGUgZmxvb3INCj4gaWYgdGhlIGJpdCBpcyBzdGlsbCBzZXQuIFNv IEkgdGhpbmsgeW91IHdhbnQgdG8gZ28gYSBsaXR0bGUgYmV5b25kIGp1c3QNCj4gcXVvdGluZyBm cm9tIHRoZSBzcGVjLg0KSG93IGFib3V0IHF1b3RpbmcgUm9nZXIncyBwcmV2aW91cyB3b3Jkczog IiBUaGUgbWVtb3J5IGRlY29kaW5nIG11c3QgYmUgZGlzYWJsZWQgYmVmb3JlIHdyaXRpbmcgdGhl IEJBUiBzaXplIGZpZWxkLg0KT3RoZXJ3aXNlIGNoYW5naW5nIHRoZSBCQVIgc2l6ZSB3aWxsIGxl YWQgdG8gdGhlIGFjdGl2ZSBwMm0gbWFwcGluZ3MgZ2V0dGluZyBvdXQgb2Ygc3luYyB3LnIudC4g dGhlIG5ldyBCQVIgc2l6ZS4iID8NCg0KPiANCj4+Pj4gKyAgICAgICAgaWYgKCByYyApDQo+Pj4+ ICsgICAgICAgIHsNCj4+Pj4gKyAgICAgICAgICAgIHByaW50aygiJXBwOiBhZGQgcmVnaXN0ZXIg Zm9yIFBDSV9SRUJBUl9DQVAgZmFpbGVkIChyYz0lZClcbiIsDQo+Pj4+ICsgICAgICAgICAgICAg ICAgICAgJnBkZXYtPnNiZGYsIHJjKTsNCj4+Pj4gKyAgICAgICAgICAgIGJyZWFrOw0KPj4+PiAr ICAgICAgICB9DQo+Pj4+ICsNCj4+Pj4gKyAgICAgICAgcmMgPSB2cGNpX2FkZF9yZWdpc3Rlcihw ZGV2LT52cGNpLCB2cGNpX2h3X3JlYWQzMiwgcmViYXJfY3RybF93cml0ZSwNCj4+Pj4gKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICByZWJhcl9vZmZzZXQgKyBQQ0lfUkVCQVJfQ1RSTCwg NCwNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwZGV2LT52cGNpLT5oZWFk ZXIuYmFycyk7DQo+Pj4+ICsgICAgICAgIGlmICggcmMgKQ0KPj4+PiArICAgICAgICB7DQo+Pj4+ ICsgICAgICAgICAgICBwcmludGsoIiVwcDogYWRkIHJlZ2lzdGVyIGZvciBQQ0lfUkVCQVJfQ1RS TCBmYWlsZWQgJWRcbiIsDQo+Pj4+ICsgICAgICAgICAgICAgICAgICAgJnBkZXYtPnNiZGYsIHJj KTsNCj4+Pj4gKyAgICAgICAgICAgIGJyZWFrOw0KPj4+DQo+Pj4gSXMgaXQgY29ycmVjdCB0byBr ZWVwIHRoZSBvdGhlciBoYW5kbGVyIGluc3RhbGxlZD8gQWZ0ZXIgYWxsIC4uLg0KPj4gV2lsbCBj aGFuZ2UgdG8gInJldHVybiByYzsiIGhlcmUgYW5kIGFib3ZlIGluIG5leHQgdmVyc2lvbi4NCj4g DQo+IEknbSBub3QgY29udmluY2VkIHRoaXMgaXMgd2hhdCB3ZSB3YW50LCBhcyBwZXIgLi4uDQo+ IA0KPj4+PiArICAgICAgICB9DQo+Pj4+ICsgICAgfQ0KPj4+PiArDQo+Pj4+ICsgICAgcmV0dXJu IDA7DQo+Pj4NCj4+PiAuLi4geW91IC0gaW1vIHNlbnNpYmx5IC0gYXJlbid0IGNvbW11bmljYXRp bmcgdGhlIGVycm9yIGJhY2sgdXAgKHRvIGFsbG93DQo+Pj4gdGhlIGRldmljZSB0byBiZSB1c2Vk IHdpdGhvdXQgQkFSIHJlc2l6aW5nLg0KPiANCj4gLi4uIHdoYXQgSSBzYWlkIGhlcmUuDQpTb3Jy eSwgSSBkaWRu4oCZdCB1bmRlcnN0YW5kLg0KRG8geW91IG1lYW4gaXQgaXMgbm90IGVub3VnaCB0 byByZXR1cm4gZXJyb3IgY29kZSBvbmNlIGEgaGFuZGxlciBmYWlsZWQgdG8gYmUgaW5zdGFsbGVk LCBJIG5lZWQgdG8gcmVtb3ZlIHRoZSBhbHJlYWR5IGluc3RhbGxlZCBoYW5kbGVycz8NCg0KPiAN Cj4+Pj4gQEAgLTU0MSw2ICs1NDIsMTYgQEANCj4+Pj4gICNkZWZpbmUgIFBDSV9WTkRSX0hFQURF Ul9SRVYoeCkJKCgoeCkgPj4gMTYpICYgMHhmKQ0KPj4+PiAgI2RlZmluZSAgUENJX1ZORFJfSEVB REVSX0xFTih4KQkoKCh4KSA+PiAyMCkgJiAweGZmZikNCj4+Pj4gIA0KPj4+PiArLyogUmVzaXph YmxlIEJBUnMgKi8NCj4+Pj4gKyNkZWZpbmUgUENJX1JFQkFSX0NBUAkJNAkvKiBjYXBhYmlsaXR5 IHJlZ2lzdGVyICovDQo+Pj4+ICsjZGVmaW5lICBQQ0lfUkVCQVJfQ0FQX1NJWkVTCQkweEZGRkZG RkYwICAvKiBzdXBwb3J0ZWQgQkFSIHNpemVzICovDQo+Pj4NCj4+PiBNaXNyYSBkZW1hbmRzIHRo YXQgdGhpcyBoYXZlIGEgVSBzdWZmaXguDQo+PiBEbyBiZWxvdyBQQ0lfUkVCQVJfQ1RSTF9CQVJf SURYLCBQQ0lfUkVCQVJfQ1RSTF9OQkFSX01BU0sgYW5kIFBDSV9SRUJBUl9DVFJMX0JBUl9TSVpF IGFsc28gbmVlZCBhIFUgc3VmZml4Pw0KPiANCj4gVGhleSBtYXkgd2FudCB0byBnYWluIHRoZW0g Zm9yIGNvbnNpc3RlbmN5LCBidXQgdGhleSBkb24ndCBzdHJpY3RseSBuZWVkDQo+IHRoZW0uIEkg d2FudGVkIHRvIHNheSAiU2VlIHRoZSByZXN0IG9mIHRoZSBmaWxlIiwgYnV0IGl0IGxvb2tzIGxp a2UgdGhlDQo+IGZpbGUgd2Fzbid0IGNsZWFuZWQgdXAgeWV0IE1pc3JhLXdpc2UuDQpZZXMsIEkg bm90aWNlZCB0aGF0IHRoZSByZXN0IG9mIHRoZSBmaWxlIGRpZG4ndCBhZGQgVSBzdWZmaXggdG9v Lg0KU28sIEkganVzdCBuZWVkIHRvIGFkZCBVIHN1ZmZpeGVzIGZvciBteSBuZXcgbWFjcm9zPw0K DQo+IA0KPj4+PiArI2RlZmluZSBQQ0lfUkVCQVJfQ1RSTAkJOAkvKiBjb250cm9sIHJlZ2lzdGVy ICovDQo+Pj4+ICsjZGVmaW5lICBQQ0lfUkVCQVJfQ1RSTF9CQVJfSURYCTB4MDAwMDAwMDcgIC8q IEJBUiBpbmRleCAqLw0KPj4+PiArI2RlZmluZSAgUENJX1JFQkFSX0NUUkxfTkJBUl9NQVNLCTB4 MDAwMDAwRTAgIC8qICMgb2YgcmVzaXphYmxlIEJBUnMgKi8NCj4+Pj4gKyNkZWZpbmUgIFBDSV9S RUJBUl9DVFJMX0JBUl9TSVpFCTB4MDAwMDFGMDAgIC8qIEJBUiBzaXplICovDQo+Pj4+ICsjZGVm aW5lICBQQ0lfUkVCQVJfQ1RSTF9TSVpFKHYpIFwNCj4+Pj4gKyAgICAgICAgICAgICgxVUwgPDwg KE1BU0tfRVhUUih2LCBQQ0lfUkVCQVJfQ1RSTF9CQVJfU0laRSkgKyAyMCkpDQo+Pj4NCj4+PiBU aGUgbGl0ZXJhbCAyMCAoYXBwZWFyaW5nIGhlcmUgdGhlIDJuZCB0aW1lKSBhbHNvIHdhbnRzIGhp ZGluZyBiZWhpbmQgYQ0KPj4+ICNkZWZpbmUuDQo+PiBPSywgd2lsbCBhZGQgIiAjZGVmaW5lIFBD SV9SRUJBUl9TSVpFX1VOSVRfQllURVNfTEVOIDIwIiB0byByZXBsYWNlIGFib3ZlIHR3byAnMjAn IGNhc2UuDQo+IA0KPiBXaGF0IGlzICJVTklUX0JZVEVTX0xFTiIgdGhlcmU/IFRoZXJlJ3Mgbm90 aGluZyBieXRlLWlzaCBoZXJlLCBJIGRvbid0DQo+IHRoaW5rLCAyMCBpcyBzaW1wbHkgdGhlIHNo aWZ0IGJpYXMuDQpJdCdzIGEgbmFtaW5nIHByb2JsZW0uIFdoYXQgSSB3YW50IHRvIGV4cHJlc3Mg aGVyZSBpcyB0aGF0IHRoZSBiYXNpYyB1bml0IGlzIDFNQiwgd2hpY2ggaXMgMl4yMCBvZiBieXRl cy4NClNpbmNlIHRoZSBzcGVjIGhhcyB0aGUgZGVmaW5pdGlvbiBhYm91dCB0aGUgdmFsdWUgb2Yg dGhlIGJhciBzaXplIGJpdHMgb2YgcmVnaXN0ZXI6DQpCQVIgU2l6ZSAtIFRoaXMgaXMgYW4gZW5j b2RlZCB2YWx1ZS4NCjAJMSBNQiAoMl4yMCBieXRlcykNCjEJMiBNQiAoMl4yMSBieXRlcykNCjIJ NCBNQiAoMl4yMiBieXRlcykNCjMJOCBNQiAoMl4yMyBieXRlcykNCuKApg0KNDMJOCBFQiAoMl42 MyBieXRlcykNCkRvIHlvdSBoYXZlIHN1Z2dlc3Rpb24gYWJvdXQgdGhpcyBtYWNybyBuYW1lPw0K DQo+IA0KPiBKYW4NCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpKaXFpYW4gQ2hlbi4NCg== From xen-devel-bounces@lists.xenproject.org Tue Dec 10 09:29:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Dec 2024 09:29:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851937.1265896 (Exim 4.92) (envelope-from ) id 1tKwYd-00078m-UJ; Tue, 10 Dec 2024 09:29:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851937.1265896; Tue, 10 Dec 2024 09:29: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 1tKwYd-00078f-Qa; Tue, 10 Dec 2024 09:29:31 +0000 Received: by outflank-mailman (input) for mailman id 851937; Tue, 10 Dec 2024 09:19: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 1tKwPE-00063s-On for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 09:19:48 +0000 Received: from JPN01-TYC-obe.outbound.protection.outlook.com (mail-tycjpn01on20605.outbound.protection.outlook.com [2a01:111:f403:2019::605]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e254a948-b6d7-11ef-99a3-01e77a169b0f; Tue, 10 Dec 2024 10:19:42 +0100 (CET) Received: from TYWP301MB0483.JPNP301.PROD.OUTLOOK.COM (2603:1096:400:2bc::10) by OS3P301MB0038.JPNP301.PROD.OUTLOOK.COM (2603:1096:604:209::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.17; Tue, 10 Dec 2024 09:19:36 +0000 Received: from TYWP301MB0483.JPNP301.PROD.OUTLOOK.COM ([fe80::1aeb:c01e:25ef:b97a]) by TYWP301MB0483.JPNP301.PROD.OUTLOOK.COM ([fe80::1aeb:c01e:25ef:b97a%4]) with mapi id 15.20.8230.016; Tue, 10 Dec 2024 09:19: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: e254a948-b6d7-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FRg+SFE4mhHKt5h3XupUYSVN3jA3TXEvzf9GugM5DRCN/Jgmz0MBd3tA0VSG2gevUvlFGaoSo6C8ri7LG0AYj4ZQNUxyJ7WnguVo0w7O0KMEWVjxVwgZQUyERutCQC8RLjJceD/iEMkqI7FDQEMz5Q0eshCvBwPvBTLpWbjOxwfPW8tWJa2Z5gnGkoLrlqQnMlsIPGxLISTjoiqx24gPDeTtxUimegyjoSsu6poerAvGjVMTTqRTwqCYdQhWntI579ngpUsb2TvgzmSQkExQkcBgEG31u4fZbhICGTZiQXc0T4U4kMIp4G9VhXfR7RgrfjFip0MXP/SLhCHi3BRmJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2P1Vn9h8B78VQckZV0zMLebKHEnxQIzwspwwvDayiZw=; b=wsaSOdAGO1qP9/a51J3wtHMElJVZ8DAuRw0qQyzU7ookeNOZ/fYzDeJf+4dxah0yxN7uaYIn+5fuqsUmdZkyl7cXt5jl0tN77+v/ruqlbw9RBQDagG3f1IkBd9HeadPQJC9n1eYYdf4i72h9G9UiQU8eFMGiTbxWvW2CvYxG4c4/fHtet2uba6+HM0EyZe/5JgacBQIrZmDv2t0wm8zOox1MBFoHs6+bpOZXjMuC/tPZdF9QaglE/kvapKfP1yf41Rd0KRp6Pgvs3Zs3reArXAezQGXO8MTq7iUZMYmqb6NYDwBPaq0ymncR2G+QmPoPbMt6UjxNUw2pBIE2ctGC+Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jp.honda; dmarc=pass action=none header.from=jp.honda; dkim=pass header.d=jp.honda; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jp.honda; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2P1Vn9h8B78VQckZV0zMLebKHEnxQIzwspwwvDayiZw=; b=GB6XNfSWDugxiFKTFLLAfJ4YUq7S+OY+rSX2W80Q+mlqVhHaQ4IkC970w87kZ3BK1ca5gE9yMmTQ7R/3yfCLGY/BdXiU4JSI5wPLQ3iehSBbHYUq26dQ21KIaHOM7HnN91zX3GtON6wNojOTX32AS96poT4V5hSPGkHE388wQFwOS1w1+gLhyr6Ip85wVIc5TKNJnzNolPmulF3bURp6HhGV9ssMdRXRHVCKxCW/lfBIhI+M62Jm7z+5qRC0CNkbyJ/IYG5r8Wpdg8IzszFZGsOOE2mlzg4eCDPLY5YLbnmwFBwRvsh8NMERTVaShcPmbvKGI8nxMRElK301d9sA6w== From: =?utf-8?B?WVVJQ0hJIEtVU0FLQUJFICjml6XkuIvpg6gg6ZuE5LiAKQ==?= To: Kelly Choi , xen-devel , "xen-announce@lists.xenproject.org" , "committers @ xenproject . org" , Xen Project Advisory Board Subject: RE: Welcome Honda to the Xen Project Board Thread-Topic: Welcome Honda to the Xen Project Board Thread-Index: AQHbSkeg1eQVbNUJ8k6kRbtJc5zLVrLfMfLg Date: Tue, 10 Dec 2024 09:19:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXGowMTMzOTgyXGFwcGRhdGFccm9hbWluZ1wwOWQ4NDliNi0zMmQzLTRhNDAtODVlZS02Yjg0YmEyOWUzNWJcbXNnc1xtc2ctZGU3YTRiNjEtYjZkNy0xMWVmLThjOWMtNTgxY2Y4MDY4Mjc2XGFtZS10ZXN0XGRlN2E0YjYyLWI2ZDctMTFlZi04YzljLTU4MWNmODA2ODI3NmJvZHkuaHRtbCIgc3o9IjE4MDU4IiB0PSIxMzM3ODI5NTk3NDkxMzkyMjQiIGg9IkVpanBCVHVZRThmejBuTmRIeFc4QkdDQ0UxMD0iIGlkPSIiIGJsPSIwIiBibz0iMSIvPjwvbWV0YT4= x-dg-rorf: true authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=jp.honda; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: TYWP301MB0483:EE_|OS3P301MB0038:EE_ x-ms-office365-filtering-correlation-id: 73e71510-67ef-4500-cccf-08dd18fbc3f7 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|8096899003|7053199007|38070700018; x-microsoft-antispam-message-info: =?utf-8?B?eEpWRUg3QWpQYitBTkZnQ3Brdi9FUFgzL2E2MXRwc0pEM0VTR3NIZWxEdWtL?= =?utf-8?B?c3lBUnphMjkzeVJ0ZC9yZkdXM0VLbUhFNWZEVGh6cmk1eUlUOHp3QUlFM0hT?= =?utf-8?B?NUdUQUd6alVNb0FCdWhMOU54eWJya2NyODllcE9vajhnNUMvT2cxd1o5RkN5?= =?utf-8?B?TTRVOUhkY1BUVzVXL2s2djdGSEhyWkluTWcvWFpjVmR5aHZFeVRVeUtxb0ti?= =?utf-8?B?MURVckQ5ZG1FUnZmbGl0YlkrRFZLL00zWmttWkpXbmZlSG5lZmd2ZkQwVGJ0?= =?utf-8?B?amVXVHg3U25mTDlHNjVvU3ZlOGdyRjFOc2psUzR1Ynh0eU5aMVFDK1lMdXdx?= =?utf-8?B?Q3RRWnpUT2pGUFBlU3lXTDhxajk5MEVUQXJhQldJZlFpNlBuZnhxbHFDOFBq?= =?utf-8?B?Vjhia04rbkZYOElXOXNYUHU4SENzcU9UK290Qk4vd21ObVVLUWRqNXVpeFRF?= =?utf-8?B?YmdwQmpGcVJ6K1pSRFVDSWVYU3dybnJFOW9PVllFeHhaV2RUekNWWStOYkll?= =?utf-8?B?eDNjQjF4N2JVWjUwcDdOQTI0U0IyQStGN1NNa2wvWDcrVzMwcGloY0FMejRy?= =?utf-8?B?ZmhzS0V6LzYzTDhWYVBGUzhxcVA0TVJHcHZNV3hHOXoxbks4dXlsVHA0NUY0?= =?utf-8?B?MzZISDR0R05YeUJ4bDZsNkZXRHRMVW9TcXVndE1pOTlIZWx2YU9rVlNsOWY4?= =?utf-8?B?Wk5keXdXZ3J6NG1hNmJndnVKMHhHRmFwamg2RXFic2lLaDcxUVJGaHNqcHh3?= =?utf-8?B?ZHN0QXh2YzVzVXZJcGhJOWNGdStJNkZRMkNlRzdlekhHTGNwb0pVUS9UWi80?= =?utf-8?B?SkxjbGpqTjhxWm5EaEVMRklNcXhhTlphSlY2cFBlNDdnUEhSRldEVnpCWHpW?= =?utf-8?B?bmlMOFphNlVaRWZlRHpxMHVYZEYxaXdnRlhEeks1aTlPZDVnNnhiTnhHN1Fr?= =?utf-8?B?TThVQkdYZG5SNDd0K3lsM0swZFRoU3Fid0N3Vyt3SGU4L3BxalJYVGVoWW1C?= =?utf-8?B?bjlpaUlyUUNpUWVBZWlTa3QwUnNWSlVQYkpOenlLNTMyUERuc2pMOGFSdFdq?= =?utf-8?B?NzVXa0YrcHREbjZib29LRnk3RHN6aGtDNkhDTW5FL0dJbEpKeEZKM3pUS0pR?= =?utf-8?B?Y0ZjK0pvUlJBRFJtNDlYaGo5WjdTMkRJNnBUTEl1WGlEaGZXMWJQNURzSjNX?= =?utf-8?B?ZGRHN0ZFWlNEQmJiSFBSLzQ1WUZsWCtzOFVBVUNncW1SVEV5bk5ER2ZQQjhR?= =?utf-8?B?TEpqTVJDMEs3ckIybHlIRGRMT1BWWWxyTFV5d1VuWHg1c3hPcVIvTzRmN3h6?= =?utf-8?B?bVEvcmtsSm5vRFBVZDdRV245cVRSSmVidWkzN0dLTTkvZS83OTRkMm5lREoz?= =?utf-8?B?a1c1aUdUR244SEdnMFhPUFJJOGhMMzVmRFlyaEpCZGJHY0VXQmRReFdlRk84?= =?utf-8?B?UmZMeDAyWGpnSnh6RFBORUNRSHhoVG1FbDRPbHg0WCtxWTNpUVYvOVdDdmFN?= =?utf-8?B?Ukhpa3F5LytSQTFoNzBNdmtEQ2VEZFJYSlcybzBIWVlySmRnRDM2YjZhL0F0?= =?utf-8?B?ejBLZ3NXaEZpR2NCb2Z0SXlHMWNjdjBUSm90K1NwQ09RTnE5b0tRc2ZiWEda?= =?utf-8?B?R1dLcHVTdTVxaTBQSnFVUEtkdEdXRVI0LzlqdzhIQ3RsUzZvcGpnczZYWE4x?= =?utf-8?B?cXoxaGpwZlYwVWxNd0dueFRHRkRVL2llaTJwTVV4L05WLzVRYWRzQWErLzEr?= =?utf-8?B?dXdTbVFFeEFMMnlXVmdDdE02YjJsU1g5d2hXdytPZmdRSGFhWXRRbEw0OHVN?= =?utf-8?Q?CgN+BpiFYzwI8CspaPkUPl6gwnTkAQ2lkTSFk=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:ja;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TYWP301MB0483.JPNP301.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(8096899003)(7053199007)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MGpaYWYxMTVKMFUzR0dTbllQRHRVSGdLUFlUVVREUjltcGNYNjNOK2E5MVNN?= =?utf-8?B?UTZYdUlnOFRNWGdpZW5BcURvSTBuSExWdlhvZTV2ekFnVVE3SlY4SlJFVENN?= =?utf-8?B?WXhJN2JkT05TdGJwKytwNHNoL0gwQThSdVc3Q2dHamVmT0tQdnhMMzZ6clFL?= =?utf-8?B?bzIrQzhOYXkxdm9xWWNRUm85eEFiV2xJTmJUSStVejRpVW51Q2YxVnV6Lys0?= =?utf-8?B?c3VjYXZHSmk3dWR3RkprN0FKUjI3S011TVR0bHJTSXVHeGNiVWV0Y2xSUER3?= =?utf-8?B?NlRZSnZMRCtSM25tYzNuV2pMRzZKbmx2Q1ZndjY1MFoxZ3l3ZEZOUVAwcE1t?= =?utf-8?B?ZGNCVGJIR0YyTTlnV0NSL29LeWllbUZTQzdEa2tYQWxnWFZzMzNWeTc0bThE?= =?utf-8?B?bCtaMDg4WGZLekN6SUpsdlpSSkY5SENyWHZMRWk0MmhBNUxhV2YyeitLWkJ4?= =?utf-8?B?akhuWTlINW8ya3BoSklRT3lkUm51eDhLNFRaS2hwK2IyNHV3dEFob2xaQzBS?= =?utf-8?B?Y0JNTk90MUp1VXNpWUlISVdnQTdpeFk4N0IzR09lUnh3OC9tek1QYU5BNjlq?= =?utf-8?B?RlkyYTRJUC9FYlErYSsvN2N1WXkyZkpMYWhkc08yZmNaYlB5RURnT2h0NE13?= =?utf-8?B?WlNKM3g4cEVpYjFDd3UxcjYvenkxNHBVN0h1TW1OQjNjWTA5TGlld1NreWUx?= =?utf-8?B?dFFuT2ZMRGZNTTUzeHJSNE51d05kYjlCaUdMb0dLbXdsaEZXUHgxWXhyVWw1?= =?utf-8?B?d3pjL0FjanNqbGtGVWNDZk4yRU03c29XWUVJVlZaTGo2NHNkTjluaHZCWmND?= =?utf-8?B?M0g2cS9jREhXK2ZNT0VNZlJhck1QdS9RempPK21keTFqNWtHK2pKV29nSmF4?= =?utf-8?B?bk1Ic0xNaHNhNFBucFdjOC9DTGp1WVpndkI1akxXNG92eFJGZ25oRWZmbzVn?= =?utf-8?B?VG16ekQxbUsxVDRBdERtYjdoWG5hdWVZaTVRZkY2Q3RrZXk0MVdMVHNWTHpS?= =?utf-8?B?N0NiRHZhTVo4a08zcnRwQWQ5d2lVcXJPdXlxUEp6NVhZREpxMWJEb0ZMbnZ5?= =?utf-8?B?SkN2MDBQY2FVd1lKU2NzaFMybkhHTmVZbzlpNU9KVmxGNFRwb3k4cStaN1hq?= =?utf-8?B?ZWFyQmZiVWE2Vi9DWlhSQm5Tck1HV3FjSXVnZ2Q2SkZDZmJZdnc4RFE4Mm4w?= =?utf-8?B?UFMvZUE0QTNWQ2NHOWtuTFV0eHozUjNtMDJiTUczWGZITGVhVFRVTWhGdVlO?= =?utf-8?B?d2dNV2tsMnZKTVlaRjNNYjJNQTlXRkVpdkhHY045MllwSE54OUpJYUpnODhz?= =?utf-8?B?bGllMVQwTDRTNVNidkVXcExFMFNIb1ErcWdJWndFS3hvUEhKelFuWlorMkNC?= =?utf-8?B?cmJVVlg1TVpCNkVTZC9SdVI1SXFrZy9WTTgrNVhBT1lwZXVsZjVELysyS3dz?= =?utf-8?B?RXVmQVZoYjdWTXZ2azBUUWVxTGdFOHlRR2hESENPZ2x5aEdMTHFIcysvYkNC?= =?utf-8?B?cHVtS2pXNXZjelpPdnJOY2s5OFBDNnJJTzc2K0twWTRUalFvTTh2LzVuRG5v?= =?utf-8?B?WlNTOEVKR0grK1k3U3FCVHNBc1hDaU9zZmdvRVFRUnlnYVVOd2piRC9SZStE?= =?utf-8?B?eHZ6c3E0MytDOXFkclVneGVDWkJRVjhQa3dRZEcwN1pCMFJNZHZwZG1ZN1Jr?= =?utf-8?B?OVlGZ3lyaXFCSWNrR0xCY2VRYkRmMVdaZ1Z2amhJZUZCSkM0QnJGSEZJY0hk?= =?utf-8?B?YXlJbjVJdTF2akZJOWN5NHdLTW9VVVdtRjQzU3h1cXl5SCtabzRHTTdscDRt?= =?utf-8?B?REQ1bEVwdFJBTVVtTGdPNDJzZTMwYmFVV3d2VFp5cTVEUVFJRWcwN1N5V2FB?= =?utf-8?B?T21UUUM4Uks0V2NOZkdiVlVteWVpMXNtYjJmQnJmeVE4VmxjRmpJWWhjakNZ?= =?utf-8?B?MzNUWk1zRHlES0RMTDlxRUEvWFp2dU5OVW1yTytSM05aaFk4SE5lbk5nUmRB?= =?utf-8?B?YWRPY1NOQWNQU3A2VjYweVhGYVFJZmFNVGtMQncrU1EyRDBMSno3bVgwbGZw?= =?utf-8?B?WStIa1Bxc1d4ZGdUN21hMTJ0OW5NL0FRdGpIOEpKYXJlRkpqVitXLytOWFN5?= =?utf-8?B?azRGT0U2TFg0cGlReXFHa09WcVp4dUhsM0JYdkpXcUY2dGRGR2lYV0I2UDND?= =?utf-8?B?N0E9PQ==?= Content-Type: multipart/alternative; boundary="_000_TYWP301MB04835A3401AA61594113EA29FB3D2TYWP301MB0483JPNP_" MIME-Version: 1.0 X-OriginatorOrg: jp.honda X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: TYWP301MB0483.JPNP301.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 73e71510-67ef-4500-cccf-08dd18fbc3f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2024 09:19:35.9988 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cc138ffb-9c4d-433b-b211-d4549ae62e8b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dYoqzhrizXsgktXUmu37/9EiqHLArE3qSz+FqXmQH5lJrO0slJegh8rIaH661mkcSjIZymM0ndtco5iVooruDX8aWh2wUmyoaDvhoqGtyZA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS3P301MB0038 --_000_TYWP301MB04835A3401AA61594113EA29FB3D2TYWP301MB0483JPNP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQWxsDQoNCldlIGFyZSBoYXBweSB0byBiZSBhYmxlIHRvIGpvaW4gdGhlIG1lbWJlciBv ZiBYZW4gUHJvamVjdC4NClRvIGhlbHAgdXMgYWNoaWV2ZSB3aGF0IHdlIGNvbnNpZGVyIHRvIGJl IFNEViwNCmh0dHBzOi8vc3RhdGljLnNjaGVkLmNvbS9ob3N0ZWRfZmlsZXMvYWdsYW1tc3VtbWVy MjAyNC9mMi9rZXlub3RlLTI0MDcxOEFHTF9BTU0tSG9uZGEucGRmP19nbD0xKjE4N2NvYWMqX2dj bF9hdSpNVGsxTmpRNE1qRTJOUzR4TnpNeE56WXpPRE0zKkZQQVUqTVRrMU5qUTRNakUyTlM0eE56 TXhOell6T0RNMw0KWGVuIGlzIHRoZSBiZXN0IG9wdGlvbiB0byBhY2hpZXZlIG91ciBTRFYgdmlz aW9uLg0KDQpJIGxvb2sgZm9yd2FyZCB0byBzZWVpbmcgeW91IGFsbC4NCg0KQlIuDQpZdWljaGkg S3VzYWthYmUuDQpDaGllZiBBcmNoaXRlY3QgLSBJVkkgc29mdHdhcmUgUEYvT1NQTyBUZWNoIExl YWQNCkhvbmRhIE1vdG9yIENvLiwgTHRkLg0KDQpGcm9tOiBLZWxseSBDaG9pIDxrZWxseS5jaG9p QGNsb3VkLmNvbT4NClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgOSwgMjAyNCAxMTozNSBQTQ0KVG86 IHhlbi1kZXZlbCA8eGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnPjsgeGVuLWFubm91bmNl QGxpc3RzLnhlbnByb2plY3Qub3JnOyBjb21taXR0ZXJzIEAgeGVucHJvamVjdCAuIG9yZyA8Y29t bWl0dGVyc0B4ZW5wcm9qZWN0Lm9yZz47IFhlbiBQcm9qZWN0IEFkdmlzb3J5IEJvYXJkIDxhZHZp c29yeS1ib2FyZEBsaXN0cy54ZW5wcm9qZWN0Lm9yZz4NClN1YmplY3Q6IFdlbGNvbWUgSG9uZGEg dG8gdGhlIFhlbiBQcm9qZWN0IEJvYXJkDQoNCkhpIGFsbCwNCg0KV2UncmUgZXhjaXRlZCB0byBh bm5vdW5jZSBvdXIgbmV3ZXN0IEFkdmlzb3J5IEJvYXJkIE1lbWJlciBIb25kYSwgdG8gdGhlIFhl biBQcm9qZWN0Lg0KDQpTaW5jZSBpdHMgZm91bmRhdGlvbiwgSG9uZGEgaGFzIGJlZW4gY29tbWl0 dGVkIHRvICJjcmVhdGluZyBhIHNvY2lldHkgdGhhdCBpcyB1c2VmdWwgdG8gcGVvcGxlIiBieSB1 dGlsaXppbmcgaXRzIHRlY2hub2xvZ2llcyBhbmQgaWRlYXMuIEhvbmRhIGFsc28gZm9jdXNlcyBv biBlbnZpcm9ubWVudGFsIHJlc3BvbnNpdmVuZXNzIGFuZCB0cmFmZmljIHNhZmV0eSwgYW5kIGNv bnRpbnVlIHRvIHRha2Ugb24gdGhlIGNoYWxsZW5nZSBvZiByZWFsaXppbmcgYSBzdXN0YWluYWJs ZSBmdXR1cmUuDQoNCkkgYW0gc3VyZSB0aGF0IHRoZSBjb21tdW5pdHkgd2lsbCBhZ3JlZSB0aGF0 IHRoaXMgaXMgYSBodWdlIHN0ZXAgYW5kIGFjaGlldmVtZW50IGZvciBvdXIgb3BlbiBzb3VyY2Ug cHJvamVjdC4gSG9uZGEncyBpbnZlc3RtZW50IGludG8gc3VwcG9ydGluZyBYZW4gbWVhbnMgd2Ug YXJlIGV4cGFuZGluZyBvdXIgZWZmb3J0cyB0byBjcmVhdGUgYSBtb3JlIHNlY3VyZSBhbmQgdmVy c2F0aWxlIGh5cGVydmlzb3IsIHdpdGggcmVhbCB3b3JsZCBhcHBsaWNhdGlvbnMuIFRoZWlyIGNv bW1pdG1lbnQgYW5kIHBhcnRuZXJzaGlwIHdpdGggWGVuIG9ubHkgaW5jcmVhc2UgdGhlIGNhcGFi aWxpdGllcyB0aGF0IG91ciB2aXJ0dWFsaXphdGlvbiB0ZWNobm9sb2d5IGhhcyBhY2hpZXZlZCBz byBmYXIuDQoNCldpdGggSG9uZGEgam9pbmluZywgdGhlaXIgaW5zaWdodHMgd2lsbCBoZWxwIHVz IG5hdmlnYXRlIG5ldyBjaGFsbGVuZ2VzLCBleHBhbmQgb3VyIG91dHJlYWNoIHRvIG5ldyBjb250 cmlidXRvcnMgYW5kIGVuaGFuY2UgcG9saWNpZXMgc3Vycm91bmRpbmcgb3VyIGNvbW11bml0eS4N Cg0KVGhlaXIgdW5pcXVlIHBlcnNwZWN0aXZlIHdpbGwgYmUgaW52YWx1YWJsZSBhcyB3ZSB0YWNr bGUgZ29hbHMgZm9yIHRoZSBmdXR1cmUsIGFuZCB3ZeKAmXJlIHRocmlsbGVkIHRvIGhhdmUgdGhl aXIgdm9pY2UgZ3VpZGluZyBvdXIgc3RyYXRlZ3kgYW5kIHZpc2lvbi4NCg0KUGxlYXNlIGpvaW4g dXMgaW4gZ2l2aW5nIGEgd2FybSB3ZWxjb21lIHRvIEhvbmRhISBXZeKAmXJlIGVhZ2VyIHRvIHNl ZSBob3cgdGhlaXIgbGVhZGVyc2hpcCBhbmQgdGVjaG5pY2FsIHRlYW1zIHdpbGwgaGVscCBzaGFw ZSB0aGUgZnV0dXJlIG9mIHRoZSBYZW4gUHJvamVjdC4NCg0KVG9nZXRoZXIsIHdl4oCZbGwgY29u dGludWUgYnVpbGRpbmcgYSBzdHJvbmcsIGluY2x1c2l2ZSwgYW5kIGlubm92YXRpdmUgY29tbXVu aXR5Lg0KDQpLZWxseSBDaG9pDQpDb21tdW5pdHkgTWFuYWdlcg0KWGVuIFByb2plY3Q8aHR0cHM6 Ly94ZW5wcm9qZWN0Lm9yZy8+DQo= --_000_TYWP301MB04835A3401AA61594113EA29FB3D2TYWP301MB0483JPNP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65ri444K044K344OD44KvOw0KCXBhbm9z ZS0xOjIgMTEgNCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2Fs aWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiLvvK3vvLMg77yw44K044K344OD44KvIjsNCglwYW5vc2UtMToyIDExIDYgMCA3 IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOa4uOOCtOOCt+ODg+OC ryI7DQoJcGFub3NlLTE6MiAxMSA0IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEDvvK3vvLMg77yw44K044K344OD44KvIjt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MG1tOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Iu+8re+8syDvvLDjgrTjgrfj g4Pjgq8iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLjE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5Oua4uOOCtOOC t+ODg+OCrzsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46OTkuMjVwdCAzMC4wbW0gMzAuMG1tIDMwLjBtbTt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8N CkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjc3NTUxNTY0NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6MTUzOTA4OTc1MDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBtbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBtbTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiI+DQo8djp0ZXh0Ym94IGluc2V0PSI1Ljg1cHQsLjdw dCw1Ljg1cHQsLjdwdCIgLz4NCjwvbzpzaGFwZWRlZmF1bHRzPjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJKQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65ri444K044K344OD44KvIj5IZWxsbyBBbGw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65ri444K044K344OD44KvIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65ri444K044K3 44OD44KvIj5XZSBhcmUgaGFwcHkgdG8gYmUgYWJsZSB0byBqb2luIHRoZSBtZW1iZXIgb2YgWGVu IFByb2plY3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oua4uOOC tOOCt+ODg+OCryI+VG8gaGVscCB1cyBhY2hpZXZlIHdoYXQgd2UgY29uc2lkZXIgdG8gYmUgU0RW LA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oua4uOOCtOOCt+OD g+OCryI+PGEgaHJlZj0iaHR0cHM6Ly9zdGF0aWMuc2NoZWQuY29tL2hvc3RlZF9maWxlcy9hZ2xh bW1zdW1tZXIyMDI0L2YyL2tleW5vdGUtMjQwNzE4QUdMX0FNTS1Ib25kYS5wZGY/X2dsPTEqMTg3 Y29hYypfZ2NsX2F1Kk1UazFOalE0TWpFMk5TNHhOek14TnpZek9ETTMqRlBBVSpNVGsxTmpRNE1q RTJOUzR4TnpNeE56WXpPRE0zIj5odHRwczovL3N0YXRpYy5zY2hlZC5jb20vaG9zdGVkX2ZpbGVz L2FnbGFtbXN1bW1lcjIwMjQvZjIva2V5bm90ZS0yNDA3MThBR0xfQU1NLUhvbmRhLnBkZj9fZ2w9 MSoxODdjb2FjKl9nY2xfYXUqTVRrMU5qUTRNakUyTlM0eE56TXhOell6T0RNMypGUEFVKk1UazFO alE0TWpFMk5TNHhOek14TnpZek9ETTM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5Oua4uOOCtOOCt+ODg+OCryI+WGVuIGlzIHRoZSBiZXN0IG9wdGlvbiB0byBh Y2hpZXZlIG91ciBTRFYgdmlzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTrmuLjjgrTjgrfjg4Pjgq8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTrmuLjjgrTjgrfjg4Pjgq8iPkkgbG9vayBmb3J3YXJkIHRvIHNlZWlu ZyB5b3UgYWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrmuLjj grTjgrfjg4Pjgq8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTrmuLjjgrTjgrfjg4Pjgq8iPkJSLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTrmuLjjgrTjgrfjg4Pjgq8iPll1aWNoaSBLdXNha2FiZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65ri444K044K344OD44KvIj5DaGllZiBBcmNo aXRlY3QgLSBJVkkgc29mdHdhcmUgUEYvT1NQTyBUZWNoIExlYWQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65ri444K044K344OD44KvIj5Ib25kYSBNb3RvciBDby4s IEx0ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65ri444K044K3 44OD44KvIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MG1tIDBtbSAwbW0gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBtbSAwbW0gMG1tIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gS2VsbHkgQ2hvaSAmbHQ7a2VsbHkuY2hvaUBjbG91 ZC5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBEZWNlbWJlciA5LCAyMDI0IDEx OjM1IFBNPGJyPg0KPGI+VG86PC9iPiB4ZW4tZGV2ZWwgJmx0O3hlbi1kZXZlbEBsaXN0cy54ZW5w cm9qZWN0Lm9yZyZndDs7IHhlbi1hbm5vdW5jZUBsaXN0cy54ZW5wcm9qZWN0Lm9yZzsgY29tbWl0 dGVycyBAIHhlbnByb2plY3QgLiBvcmcgJmx0O2NvbW1pdHRlcnNAeGVucHJvamVjdC5vcmcmZ3Q7 OyBYZW4gUHJvamVjdCBBZHZpc29yeSBCb2FyZCAmbHQ7YWR2aXNvcnktYm9hcmRAbGlzdHMueGVu cHJvamVjdC5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFdlbGNvbWUgSG9uZGEgdG8gdGhl IFhlbiBQcm9qZWN0IEJvYXJkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldlJ3JlIGV4Y2l0ZWQgdG8gYW5ub3VuY2Ugb3VyIG5l d2VzdCBBZHZpc29yeSBCb2FyZCBNZW1iZXIgSG9uZGEsIHRvIHRoZSBYZW4gUHJvamVjdC48YnI+ DQo8YnI+DQpTaW5jZSBpdHMgZm91bmRhdGlvbiwgSG9uZGEgaGFzIGJlZW4gY29tbWl0dGVkIHRv ICZxdW90O2NyZWF0aW5nIGEgc29jaWV0eSB0aGF0IGlzIHVzZWZ1bCB0byBwZW9wbGUmcXVvdDsg YnkgdXRpbGl6aW5nIGl0cyB0ZWNobm9sb2dpZXMgYW5kIGlkZWFzLiBIb25kYSBhbHNvIGZvY3Vz ZXMgb24gZW52aXJvbm1lbnRhbCByZXNwb25zaXZlbmVzcyBhbmQgdHJhZmZpYyBzYWZldHksIGFu ZCBjb250aW51ZSB0byB0YWtlIG9uIHRoZSBjaGFsbGVuZ2Ugb2YgcmVhbGl6aW5nDQogYSBzdXN0 YWluYWJsZSBmdXR1cmUuPGJyPg0KPGJyPg0KSSBhbSBzdXJlIHRoYXQgdGhlIGNvbW11bml0eSB3 aWxsIGFncmVlIHRoYXQgdGhpcyBpcyBhIGh1Z2Ugc3RlcCBhbmQgYWNoaWV2ZW1lbnQgZm9yIG91 ciBvcGVuIHNvdXJjZSBwcm9qZWN0LiBIb25kYSdzIGludmVzdG1lbnQgaW50byBzdXBwb3J0aW5n IFhlbiBtZWFucyB3ZSBhcmUgZXhwYW5kaW5nIG91ciBlZmZvcnRzIHRvIGNyZWF0ZSBhIG1vcmUg c2VjdXJlIGFuZCB2ZXJzYXRpbGUgaHlwZXJ2aXNvciwgd2l0aCByZWFsIHdvcmxkIGFwcGxpY2F0 aW9ucy4NCiBUaGVpciBjb21taXRtZW50IGFuZCBwYXJ0bmVyc2hpcCB3aXRoIFhlbiBvbmx5IGlu Y3JlYXNlIHRoZSBjYXBhYmlsaXRpZXMgdGhhdCBvdXIgdmlydHVhbGl6YXRpb24gdGVjaG5vbG9n eSBoYXMgYWNoaWV2ZWQgc28gZmFyLjxicj4NCjxicj4NCldpdGggSG9uZGEgam9pbmluZywgdGhl aXIgaW5zaWdodHMgd2lsbCBoZWxwIHVzIG5hdmlnYXRlIG5ldyBjaGFsbGVuZ2VzLCBleHBhbmQg b3VyIG91dHJlYWNoIHRvIG5ldyBjb250cmlidXRvcnMgYW5kIGVuaGFuY2UgcG9saWNpZXMgc3Vy cm91bmRpbmcgb3VyIGNvbW11bml0eS48YnI+DQo8YnI+DQpUaGVpciB1bmlxdWUgcGVyc3BlY3Rp dmUgd2lsbCBiZSBpbnZhbHVhYmxlIGFzIHdlIHRhY2tsZSBnb2FscyBmb3IgdGhlIGZ1dHVyZSwg YW5kIHdl4oCZcmUgdGhyaWxsZWQgdG8gaGF2ZSB0aGVpciB2b2ljZSBndWlkaW5nIG91ciBzdHJh dGVneSBhbmQgdmlzaW9uLjxicj4NCjxicj4NClBsZWFzZSBqb2luIHVzIGluIGdpdmluZyBhIHdh cm0gd2VsY29tZSB0byBIb25kYSEgV2XigJlyZSBlYWdlciB0byBzZWUgaG93IHRoZWlyIGxlYWRl cnNoaXAgYW5kIHRlY2huaWNhbCB0ZWFtcyB3aWxsIGhlbHAgc2hhcGUgdGhlIGZ1dHVyZSBvZiB0 aGUgWGVuIFByb2plY3QuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5Ub2dldGhlciwgd2XigJlsbCBjb250aW51ZSBidWlsZGluZyBhIHN0cm9u ZywgaW5jbHVzaXZlLCBhbmQgaW5ub3ZhdGl2ZSBjb21tdW5pdHkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+S2VsbHkgQ2hvaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOiM4ODg4ODgiPkNvbW11bml0eSBNYW5hZ2VyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YSBocmVmPSJodHRwczovL3hlbnByb2pl Y3Qub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPlhlbiBQcm9qZWN0PC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_TYWP301MB04835A3401AA61594113EA29FB3D2TYWP301MB0483JPNP_-- From xen-devel-bounces@lists.xenproject.org Tue Dec 10 09:54:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Dec 2024 09:54:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851954.1265906 (Exim 4.92) (envelope-from ) id 1tKwx5-0002aA-TR; Tue, 10 Dec 2024 09:54:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851954.1265906; Tue, 10 Dec 2024 09: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 1tKwx5-0002a3-QE; Tue, 10 Dec 2024 09:54:47 +0000 Received: by outflank-mailman (input) for mailman id 851954; Tue, 10 Dec 2024 09:54: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 1tKwx5-0002Zx-8t for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 09:54:47 +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 c912b434-b6dc-11ef-a0d5-8be0dac302b0; Tue, 10 Dec 2024 10:54:46 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-434fef8203fso8939895e9.1 for ; Tue, 10 Dec 2024 01:54:45 -0800 (PST) Received: from ?IPV6:2003:ca:b746:63c:3d8c:c505:78ea:f982? (p200300cab746063c3d8cc50578eaf982.dip0.t-ipconnect.de. [2003:ca:b746:63c:3d8c:c505:78ea:f982]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-434f82bc754sm72415315e9.9.2024.12.10.01.54.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Dec 2024 01:54: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: c912b434-b6dc-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733824485; x=1734429285; 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=3pDMHKsd4uD3RZV9HYnVz5B5Oqa/KJqR0y987XV/fzY=; b=N+jm6ZJD3mrKCsBAeglH3v6qEB89BJjqXrMdZE1dmZ7PaYOXFZ+2VRlpvMaLk73nwj Sxl0ZutiPmXqfBbXrToXY3VWsHOp02M7+HNs8T8BHTn8z2E3E3lrev3n+LRKg9oxpbmn PwMPJwbYjFxrmweWFuCZPOOxNtN/Fhs9CTMWWxXrzHMbaTxIqDnb9UkETxh8ay0xM0xM 37SKcOXhPjQC65AS3InfoHMNZooB6oKBV1+EO4PuVUIVUefCVc+WcamPZykGwJnxpAtL CEizaaCI2fyenl/CcJqu813j5Nx6mEQZxKRtFc4dWnJZOBJ8jxn6tYyRPqYLk44Nx99B WV9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733824485; x=1734429285; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3pDMHKsd4uD3RZV9HYnVz5B5Oqa/KJqR0y987XV/fzY=; b=UizT9wPNpyInZx4zLLpNEycTDeyq8wbUyNvzQEXCMAHydjHpoQK/VtMma1yffmKy66 7LUsnaTuv3a5AvY9H16Y8F1t86V4nfHDsW5ki6F1QTGrMxtTtI8jdxZ4rLJcVhQggoDQ rziJY4pLCd/MRjgRwVHRz4UtGWx5+XRsv9A9BcLXaIljSGiKrE0Yn0ypme8lf3AitMuw 7p3A0cUwwwJrItqx/zCzti9qH7xv6H7XTOwFIsKENzbwuNvg6rupdnIPrH2AympEjhng ElIqgTJCSUh9dMEo81VyPPFlViGLjisZzWN6YPRUsSCXaK+xdgME/MTlBLPa3oAJ8MRq bJ/Q== X-Forwarded-Encrypted: i=1; AJvYcCW7HxgSsDmQuPulS8QHwUQ27EGVlc/VYRd2x2UpkW64uDz6SC5PhxWUBxjCqb5A9G76FZqqZ2EaRcs=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyq++Q5WMQ/rWbGKdMLfRF7h6bcUajqSS15GGMx6zxlzpsamYtH ZqWHWPh6ul00VvkmmQDb6Bl4n1olnodJES/lB+P2cNJ44fXm4gRhg038GEubRA== X-Gm-Gg: ASbGncsTicBX+Ij2ewiLP+33vPBeAr/isB2bQoB9sI/wCWNXKI52hn3HOEYx7LJvUwF 5FtsLzvJxiidYknCcB3Z5UTvP2aiYegMkdN52IEnlwPi3wFVmaBDeYwcbLv2bfn/aRaVYdtW77R 4PxINOF/CNEc5Se/6z7eMFGMR7EYUU8NraYDmhPpQrVV1QgSFsjqxBDSsZPQphVxm6SVWjZ/EVS tr99R7b5LQ3BB8i2DKGqXdnAbazuqacF5TSWAF/dngVa70GBfc6qXMLpGecGlpwRX3AOds+s4R+ by+h68mfUT4Tw7o9Izo/nwSyCF5MhZv9LRB3PVFb1qSvXI3BQzxCv9wqRjhmlhV0O+UMKcZRfBj pLJm4lX9Ewg== X-Google-Smtp-Source: AGHT+IHDzWR/J8nSjYkC513izSujcmoN2wOTvMsK/FVlDQYQmCeAmdSweR7LA/+JMC5nyBCY6hsFrA== X-Received: by 2002:a05:600c:46c6:b0:434:eb73:b0c0 with SMTP id 5b1f17b1804b1-434fff5b51dmr30610645e9.5.1733824484844; Tue, 10 Dec 2024 01:54:44 -0800 (PST) Message-ID: Date: Tue, 10 Dec 2024 10:54:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support To: "Chen, Jiqian" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , "Huang, Ray" , "xen-devel@lists.xenproject.org" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <20241202060956.1124162-1-Jiqian.Chen@amd.com> <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com> <1e0576d9-400e-4483-8dd1-061e215a00cd@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.12.2024 08:57, Chen, Jiqian wrote: > On 2024/12/10 15:17, Jan Beulich wrote: >> On 10.12.2024 08:07, Chen, Jiqian wrote: >>> On 2024/12/9 21:59, Jan Beulich wrote: >>>> On 02.12.2024 07:09, Jiqian Chen wrote: >>>>> +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev, >>>>> + unsigned int reg, >>>>> + uint32_t val, >>>>> + void *data) >>>>> +{ >>>>> + uint64_t size; >>>>> + unsigned int index; >>>>> + struct vpci_bar *bars = data; >>>>> + >>>>> + if ( pci_conf_read16(pdev->sbdf, PCI_COMMAND) & PCI_COMMAND_MEMORY ) >>>>> + return; >>>> >>>> I don't think something like this can go uncommented. I don't think the >>>> spec mandates to drop writes in this situation? >>> Spec says: Software must clear the Memory Space Enable bit in the Command register before writing the BAR Size field. >>> This check is suggested by Roger and it really helps to prevent erroneous writes in this case, >>> such as the result of debugging with Roger in the previous version. >>> I will add the spec's sentences as comments here in next version. >> >> What you quote from the spec may not be enough as a comment here. There's >> no direct implication that the write would simply be dropped on the floor >> if the bit is still set. So I think you want to go a little beyond just >> quoting from the spec. > How about quoting Roger's previous words: " The memory decoding must be disabled before writing the BAR size field. > Otherwise changing the BAR size will lead to the active p2m mappings getting out of sync w.r.t. the new BAR size." ? That'll be better, but imo still not enough to explain the outright ignoring of the write. >>>>> + if ( rc ) >>>>> + { >>>>> + printk("%pp: add register for PCI_REBAR_CAP failed (rc=%d)\n", >>>>> + &pdev->sbdf, rc); >>>>> + break; >>>>> + } >>>>> + >>>>> + rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write, >>>>> + rebar_offset + PCI_REBAR_CTRL, 4, >>>>> + pdev->vpci->header.bars); >>>>> + if ( rc ) >>>>> + { >>>>> + printk("%pp: add register for PCI_REBAR_CTRL failed %d\n", >>>>> + &pdev->sbdf, rc); >>>>> + break; >>>> >>>> Is it correct to keep the other handler installed? After all ... >>> Will change to "return rc;" here and above in next version. >> >> I'm not convinced this is what we want, as per ... >> >>>>> + } >>>>> + } >>>>> + >>>>> + return 0; >>>> >>>> ... you - imo sensibly - aren't communicating the error back up (to allow >>>> the device to be used without BAR resizing. >> >> ... what I said here. > Sorry, I didn’t understand. > Do you mean it is not enough to return error code once a handler failed to be installed, I need to remove the already installed handlers? No, if you return an error here, nothing else needs doing. However, I question that returning an error here is good or even necessary. In the event of an error, the device ought to still be usable, just without the BAR-resizing capability. >>>>> @@ -541,6 +542,16 @@ >>>>> #define PCI_VNDR_HEADER_REV(x) (((x) >> 16) & 0xf) >>>>> #define PCI_VNDR_HEADER_LEN(x) (((x) >> 20) & 0xfff) >>>>> >>>>> +/* Resizable BARs */ >>>>> +#define PCI_REBAR_CAP 4 /* capability register */ >>>>> +#define PCI_REBAR_CAP_SIZES 0xFFFFFFF0 /* supported BAR sizes */ >>>> >>>> Misra demands that this have a U suffix. >>> Do below PCI_REBAR_CTRL_BAR_IDX, PCI_REBAR_CTRL_NBAR_MASK and PCI_REBAR_CTRL_BAR_SIZE also need a U suffix? >> >> They may want to gain them for consistency, but they don't strictly need >> them. I wanted to say "See the rest of the file", but it looks like the >> file wasn't cleaned up yet Misra-wise. > Yes, I noticed that the rest of the file didn't add U suffix too. > So, I just need to add U suffixes for my new macros? You only strictly need to add U to values with the top bit set. >>>>> +#define PCI_REBAR_CTRL 8 /* control register */ >>>>> +#define PCI_REBAR_CTRL_BAR_IDX 0x00000007 /* BAR index */ >>>>> +#define PCI_REBAR_CTRL_NBAR_MASK 0x000000E0 /* # of resizable BARs */ >>>>> +#define PCI_REBAR_CTRL_BAR_SIZE 0x00001F00 /* BAR size */ >>>>> +#define PCI_REBAR_CTRL_SIZE(v) \ >>>>> + (1UL << (MASK_EXTR(v, PCI_REBAR_CTRL_BAR_SIZE) + 20)) >>>> >>>> The literal 20 (appearing here the 2nd time) also wants hiding behind a >>>> #define. >>> OK, will add " #define PCI_REBAR_SIZE_UNIT_BYTES_LEN 20" to replace above two '20' case. >> >> What is "UNIT_BYTES_LEN" there? There's nothing byte-ish here, I don't >> think, 20 is simply the shift bias. > It's a naming problem. What I want to express here is that the basic unit is 1MB, which is 2^20 of bytes. > Since the spec has the definition about the value of the bar size bits of register: > BAR Size - This is an encoded value. > 0 1 MB (2^20 bytes) > 1 2 MB (2^21 bytes) > 2 4 MB (2^22 bytes) > 3 8 MB (2^23 bytes) > … > 43 8 EB (2^63 bytes) > Do you have suggestion about this macro name? PCI_REBAR_SIZE_BIAS? PCI_REBAR_SIZE_SHIFT_BIAS? PCI_REBAR_SIZE_SHIFT? Jan From xen-devel-bounces@lists.xenproject.org Tue Dec 10 10:10:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Dec 2024 10:10:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851968.1265915 (Exim 4.92) (envelope-from ) id 1tKxC3-0005KS-4X; Tue, 10 Dec 2024 10:10:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851968.1265915; Tue, 10 Dec 2024 10:10: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 1tKxC3-0005KL-1u; Tue, 10 Dec 2024 10:10:15 +0000 Received: by outflank-mailman (input) for mailman id 851968; Tue, 10 Dec 2024 10:10: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 1tKxC1-0005KE-Oq for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 10:10:13 +0000 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on20624.outbound.protection.outlook.com [2a01:111:f403:2414::624]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f0368c6d-b6de-11ef-99a3-01e77a169b0f; Tue, 10 Dec 2024 11:10:11 +0100 (CET) Received: from BL1PR13CA0131.namprd13.prod.outlook.com (2603:10b6:208:2bb::16) by CH2PR12MB4247.namprd12.prod.outlook.com (2603:10b6:610:7c::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.12; Tue, 10 Dec 2024 10:10:05 +0000 Received: from BN1PEPF00004682.namprd03.prod.outlook.com (2603:10b6:208:2bb:cafe::7a) by BL1PR13CA0131.outlook.office365.com (2603:10b6:208:2bb::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.9 via Frontend Transport; Tue, 10 Dec 2024 10:10:05 +0000 Received: from SATLEXMB04.amd.com (165.204.84.17) by BN1PEPF00004682.mail.protection.outlook.com (10.167.243.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.8230.7 via Frontend Transport; Tue, 10 Dec 2024 10:10:05 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) 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; Tue, 10 Dec 2024 04:10:04 -0600 Received: from SATLEXMB03.amd.com (10.181.40.144) 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; Tue, 10 Dec 2024 04:10:03 -0600 Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Tue, 10 Dec 2024 04:10: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: f0368c6d-b6de-11ef-99a3-01e77a169b0f ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xKMeFi5kGJ5YOgwe6+Hir+HdL2LgLAtTDjEUlWqwg1MnF/c0qdl++0q3w7wkkWdSOJkmDp7ix8uyvDLlSwJ3IsSqe7LZIJaJTc7UPs8tusV5EZn6hjsH0yovneL+7PYkGFDokOK+dPDyEsf7DZifC+3UbVdvXHHskSAOZ5i48tzLF/QWhAou9DgcFG62TzE0YMzWmR7daLsfL+Nj/gFGvf6XGxV6t7UxNWLP8pgYvUfhGobfCwo94CrBxeDKLS41riA5C3eYlSg97B/sv0gkXWZDUCm0WezoOyaABTQu4r7r70MQFJQB/lyLR8BE2D6v/HWl+xSJ2GA27oQBZzkaUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2FWwb6WTcr2dSFjW7+fCV8K6mYtPDhpAzQSoFWhD5xs=; b=mF9uZzt3IzYBBR4ZYqU485u7tXUgVuGP/XlO34nfbXI+n0yFgb/nSbBZ0i0k0/pkD7YGh9HnQINbvZ7Mtwa09onPVZzHv0K3gpv9wPpN2eweBfdHWjlavJ8cG5tkAG7IUcrInNO6GBTKYnwBnK3fb94o8IcH90LlkfmzTPnbTCJjThxjwkKk5qOcuAzAh+pqXHz6PUVqU0V2zENDquFlj65DeXMjw0dNgJSk45xVTg5KCSnuSZVnaGvuuHyr68PxP9yrqIHKTe2BlWH+5WFysOPvrTGx+Uz8fsG8UNgVnco2GZEmZbHwlTD/+yLUT81KD813GRjmsg6SBzTCnS9l4A== 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=2FWwb6WTcr2dSFjW7+fCV8K6mYtPDhpAzQSoFWhD5xs=; b=KB8Ym2CygfE6ssBLNHEiqmeKiXNp0qoQdzTwZx6V1TLb1jwLXwZXpzX2+r6+30uI7N8v4ycJ4eUMJpQDQ7BrIsMZm47G24xvoQJwb9i2ijoy+Rt5xY4kw4CwRtn87xDWVo2gTwDy9jBsuPVExRgNXks9ZXhWeefBIKuMP/mDfVc= 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=SATLEXMB04.amd.com; pr=C From: Michal Orzel To: CC: Michal Orzel , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Subject: [PATCH] arm/domain_build: Make find_unallocated_memory() more generic Date: Tue, 10 Dec 2024 11:10:01 +0100 Message-ID: <20241210101001.91578-1-michal.orzel@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: BN1PEPF00004682:EE_|CH2PR12MB4247:EE_ X-MS-Office365-Filtering-Correlation-Id: e31a1813-eb57-4ccc-15a7-08dd1902d18b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700013|82310400026|1800799024; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?pcSvCFoB95DEqhqPoW5wZxGMPmnahcNw1Gn4z/uzD6uGNlkmtECMC0aAdXZm?= =?us-ascii?Q?e9+jfnsriwvVE47CpfPZaIrMrOAjceIkBipwaCcEJ3f+J1bsqMkKsJlfOcfu?= =?us-ascii?Q?yJIZzzS0ITtH3F+bDOCLJL9jFFMXhsaAIzqY8fcOWcTcB+sncA+auvNAYzaC?= =?us-ascii?Q?bQf3SvkZ6zuSGrnr3/uRfNoqJX7GBo67uxQJOq69x5Urm+MARHmtEChBQJMo?= =?us-ascii?Q?RWhrBDkmgu7N6N6+aWveAKTTz5bQV/AAT1fvjFCYlZqf/p1l5Ti1lbTpSB3b?= =?us-ascii?Q?bdgtlYjnFp/NrHhr4L/lLbZA6EOh8JaQW40gea3t9Nk8vF3HXbVIjvMyoGSH?= =?us-ascii?Q?zIXOjYrX4/wBNPwUzFsP+tg3MNYnOhDalKt2yIYQEM7N3Jqdmrpl5U59Kxmg?= =?us-ascii?Q?sYAd70pLdngJSGLv9Ky9N8zfBXmUdhZEKyTlAZK7cVhwoNH4FiDG0oWML85z?= =?us-ascii?Q?Q1edkGAFbhDX3c6WipaUYefrpcptppfdpfzIhJ0dDlir0+uV02UddTz/OgTx?= =?us-ascii?Q?P1kbmBtKc5dIbyi3Zz8rvE3F9u1XSNfltUH1X1R/pqJTSwasZ+Qy9D3cU78b?= =?us-ascii?Q?n4/j5sdElgyXJi11kCEA6M0kSLdbuIo6tTMAXV5P9QS35QY+TSik0KR+MxNT?= =?us-ascii?Q?LS5HQAe3fqQm5weJzAUL//cL6pJxA7r09voSMbxI2ZpWxU0dF9+OdCleF94m?= =?us-ascii?Q?pGOGD2kuLhG5KwLXcPuhFa+zu7rajSLWSnFSKpZwn9XS9hhjc3NrOqKiY3Ue?= =?us-ascii?Q?/ozso08fElfT5sBx6ieHtqwNU/WMFgphW3peJ449WE2O7vzWiE5KqeDMGZjE?= =?us-ascii?Q?D066XhFLdyXTVNXWOdC4Ly+i4+Wbv8ZOsW7VqOqb6h5CIc5JDFgmQDWB/doe?= =?us-ascii?Q?BDuNiPPzDXfYnyOmwfNXwf2721mGrKyAiZpqgI0skocXHmEJNvrwU7hUDtqq?= =?us-ascii?Q?+3UFDEEaM6gM2dhHwYCFG3Ajm4E7g1qyzsAk/stL9TOoTzdQjFPrUm7G/+1w?= =?us-ascii?Q?V3OX423FwIswy/D9Lb7vwS+HpgFx/Duq2TQTHcF5AtLawMdERnXPTgnmsKq3?= =?us-ascii?Q?Zd9ZI6iVYqVOGT2Drz21lpXaQEZPF8p16w6Ghje/mcCkzxarsorZVmidvRzj?= =?us-ascii?Q?368p2yhYtW3tzOj82hpb2nMCNI5d2hDH29maeZ6qEii20IR125I4x6H3+HDm?= =?us-ascii?Q?6uD3dP3hAzaptt1hh/UZZq2mnif7XF6GUf7oCZdrLuQ0mxjtSm5+xfuDlHXZ?= =?us-ascii?Q?uUXMKX50X9bdjGjjFgc9DRuEpFJpK4/dsyBP29XCVuq9iYrfi6uBZOtVDo6o?= =?us-ascii?Q?lFdcylNGQXgr1FRwFQ8xQznvmZAMFNkfiRdAEMqOoHZ5f0LcJXLPXfclzQhv?= =?us-ascii?Q?/3+OXA05tljZee1hdA4LFBpFiNIgKXN25PGUvG39PxNm9n1EjfAbi1KHusB9?= =?us-ascii?Q?COLcPfOVqPGXe09X433FP9CzkAxzTQcJ?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(82310400026)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2024 10:10:05.2035 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e31a1813-eb57-4ccc-15a7-08dd1902d18b 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=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN1PEPF00004682.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4247 At the moment, find_unallocated_memory() is only used to retrieve free memory ranges for direct mapped domains in order to find extended regions. It is not generic as it makes assumptions as for the place at which it's being called (domain memory already allocated, gnttab region already found) and hardcodes the memory banks to be excluded. Make the function more generic, so that it can be used for other purposes whenever there is a need to find free host memory regions (e.g. upcoming LLC coloring series). Allow passing array with memory banks as a parameter together with a callback to populate free regions structure, as the logic may differ depending on the needs. Add find_host_extended_regions() to be called from make_hypervisor_node() to contain the logic to find extended regions for domains using host memory layout that are not permitted to use IOMMU. Signed-off-by: Michal Orzel --- This is a prerequisite patch for LLC coloring series patch 3. For dom0 LLC coloring, we just need to pass resmem and gnttab in mem_banks. --- xen/arch/arm/domain_build.c | 97 +++++++++++++++++++++---------------- 1 file changed, 55 insertions(+), 42 deletions(-) diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 2c30792de88b..500005079b88 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -901,31 +901,26 @@ int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn, } /* - * Find unused regions of Host address space which can be exposed to Dom0 - * as extended regions for the special memory mappings. In order to calculate - * regions we exclude every region assigned to Dom0 from the Host RAM: - * - domain RAM - * - reserved-memory - * - static shared memory - * - grant table space + * Find unused regions of Host address space which can be exposed to domain + * using the host memory layout (i.e. direct mapped or hardware domain). In + * order to calculate regions we exclude every region passed in mem_banks from + * the Host RAM. */ static int __init find_unallocated_memory(const struct kernel_info *kinfo, - struct membanks *ext_regions) + const struct membanks *mem_banks[], + unsigned int nr_mem_banks, + struct membanks *free_regions, + int (*cb)(unsigned long s_gfn, + unsigned long e_gfn, + void *data)) { const struct membanks *mem = bootinfo_get_mem(); - const struct membanks *mem_banks[] = { - kernel_info_get_mem_const(kinfo), - bootinfo_get_reserved_mem(), -#ifdef CONFIG_STATIC_SHM - bootinfo_get_shmem(), -#endif - }; struct rangeset *unalloc_mem; paddr_t start, end; unsigned int i, j; int res; - dt_dprintk("Find unallocated memory for extended regions\n"); + ASSERT(domain_use_host_layout(kinfo->d)); unalloc_mem = rangeset_new(NULL, NULL, 0); if ( !unalloc_mem ) @@ -946,13 +941,8 @@ static int __init find_unallocated_memory(const struct kernel_info *kinfo, } } - /* - * Exclude the following regions: - * 1) Remove RAM assigned to Dom0 - * 2) Remove reserved memory - * 3) Remove static shared memory (when the feature is enabled) - */ - for ( i = 0; i < ARRAY_SIZE(mem_banks); i++ ) + /* Remove all regions listed in mem_banks */ + for ( i = 0; i < nr_mem_banks; i++ ) for ( j = 0; j < mem_banks[i]->nr_banks; j++ ) { start = mem_banks[i]->bank[j].start; @@ -973,28 +963,13 @@ static int __init find_unallocated_memory(const struct kernel_info *kinfo, } } - /* Remove grant table region */ - if ( kinfo->gnttab_size ) - { - start = kinfo->gnttab_start; - end = kinfo->gnttab_start + kinfo->gnttab_size; - res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start), - PFN_DOWN(end - 1)); - if ( res ) - { - printk(XENLOG_ERR "Failed to remove: %#"PRIpaddr"->%#"PRIpaddr"\n", - start, end); - goto out; - } - } - start = 0; end = (1ULL << p2m_ipa_bits) - 1; res = rangeset_report_ranges(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end), - add_ext_regions, ext_regions); + cb, free_regions); if ( res ) - ext_regions->nr_banks = 0; - else if ( !ext_regions->nr_banks ) + free_regions->nr_banks = 0; + else if ( !free_regions->nr_banks ) res = -ENOENT; out: @@ -1170,6 +1145,44 @@ static int __init find_domU_holes(const struct kernel_info *kinfo, return remove_shm_holes_for_domU(kinfo, ext_regions); } +static int __init find_host_extended_regions(const struct kernel_info *kinfo, + struct membanks *ext_regions) +{ + int res; + struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1); + + /* + * Exclude the following regions: + * 1) Remove RAM assigned to domain + * 2) Remove reserved memory + * 3) Grant table assigned to domain + * 4) Remove static shared memory (when the feature is enabled) + */ + const struct membanks *mem_banks[] = { + kernel_info_get_mem_const(kinfo), + bootinfo_get_reserved_mem(), + gnttab, +#ifdef CONFIG_STATIC_SHM + bootinfo_get_shmem(), +#endif + }; + + dt_dprintk("Find unallocated memory for extended regions\n"); + + if ( !gnttab ) + return -ENOMEM; + + gnttab->nr_banks = 1; + gnttab->bank[0].start = kinfo->gnttab_start; + gnttab->bank[0].size = kinfo->gnttab_size; + + res = find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks), + ext_regions, add_ext_regions); + xfree(gnttab); + + return res; +} + int __init make_hypervisor_node(struct domain *d, const struct kernel_info *kinfo, int addrcells, int sizecells) @@ -1226,7 +1239,7 @@ int __init make_hypervisor_node(struct domain *d, if ( is_domain_direct_mapped(d) ) { if ( !is_iommu_enabled(d) ) - res = find_unallocated_memory(kinfo, ext_regions); + res = find_host_extended_regions(kinfo, ext_regions); else res = find_memory_holes(kinfo, ext_regions); } -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Tue Dec 10 10:14:32 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Dec 2024 10:14:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.851979.1265927 (Exim 4.92) (envelope-from ) id 1tKxG9-0005zL-LF; Tue, 10 Dec 2024 10:14:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 851979.1265927; Tue, 10 Dec 2024 10:14: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 1tKxG9-0005zE-GL; Tue, 10 Dec 2024 10:14:29 +0000 Received: by outflank-mailman (input) for mailman id 851979; Tue, 10 Dec 2024 10:14: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 1tKxG8-0005z8-3x for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 10:14:28 +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 88a5126c-b6df-11ef-99a3-01e77a169b0f; Tue, 10 Dec 2024 11:14:26 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-385ed7f6605so2384744f8f.3 for ; Tue, 10 Dec 2024 02:14:26 -0800 (PST) Received: from ?IPV6:2003:ca:b746:63c:3d8c:c505:78ea:f982? (p200300cab746063c3d8cc50578eaf982.dip0.t-ipconnect.de. [2003:ca:b746:63c:3d8c:c505:78ea:f982]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3862c611242sm12502355f8f.36.2024.12.10.02.14.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Dec 2024 02:14: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: 88a5126c-b6df-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733825665; x=1734430465; 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=DsI5p3w9uIOUaInC22Ag0qJ2SDd5cFjUuOkhV0irGuM=; b=Gh9hT90FT515fZhjTLrLSV6OUlWsI1xKW3Z2wPw6K0yasbsfFb0O5+82w1XFIOf9P8 6s+OTef/IB2/VS1e56E5lOwYT57vjabNBloiBcHeY601xN3zVv1zVycm8oWIuOAAXt9r +YurdQl2+hsVO9L0P12IoT2iN+NokTx1j7P5MvSYjTKqbC26ZHaApmIcg9iMN4oK6BZF X8i7aPwCOP02Xf4XM/Nrmng/WYTcWHbFn4lrwWh4JFskdRytIPAfyTs6bTeaBzJH/TfE T5134UTfb368+7WbmhVw+Pm9LEy+n8kxaF3Mgk1F9uJ/Gm6G450l4DV3/j5ySr4CuPPD 3Upw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733825665; x=1734430465; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=DsI5p3w9uIOUaInC22Ag0qJ2SDd5cFjUuOkhV0irGuM=; b=K5zaznMdnpiZCCgOy6yfAS5D1I6DPA6/peEJBMfrD/yXkUgQrBFlrKS8SHTKbR7MpQ hPCkKSg+rc6FyMkbwtANfIl9WO8G6ksREqH8xZPT6kE2mcoltaTkGtziET0ZOa1+AuBe Hmj0UlFWms2ini5v+XWiWCEkfAp8xui3rfDTbMOn2LaVPE60GvWcN7MTofXwrtE2AgRW J/iRl0N3+1EHYSYFol6K2lEZ2GEjfoCAk/M1MGu5ALlBeGQdwFQF1qEiHrS8dXQRnhA7 0skc71It5nMo2nedkqdkAOSrGHY4c/YiQcijPO18bMo361ZcMBK5SXGEKWTZdxy8/Xga A15A== X-Forwarded-Encrypted: i=1; AJvYcCVzjzmx1z1j2n9E1SJ3ymQXuKtH4jZRAhyekqBNhi2HTST8oVFGhB0R08477V9aSnAqD/SkEzkZ4vg=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz+Kgzb0yq927nFAIrdvbuNaRxaExczcw0j53X4E78oj1c6wSkw ksXkoHKEyi3PbMEaWYqYb0l9UzyhS5IpupEAxZ+GZOQz6PELqP0lDpe+6brXXA== X-Gm-Gg: ASbGncsec1uXh8yRnW0WHq4bn1bC51RjuoywBj0tfIlPTMe9RM5sT4ZlW/Fk83wVGVC +ELs+duuV7cxDk5eHx/JuxUX+7vJtA27Xr0eFamDqpaB7Gg6hdYcuA/I1ulGy+ggKoMWdfskCsj VzCGS869hW8IcY0OsPtVhAMpEFgkbuIcjc/3SrEqmMa5uNmwtCOdc6VEVK9m0tmGsNkBZSA1bdI XTlGl0DZo0E0sk0/pcVkto792Hd+AE+3Da3WDmPmyinjXYcb79lBJIddNdyGVtGznzMLdqoZL2N ZigOClq78cDWwW/TAczuhpsWCmaDOzsZVILpAv4PB0DxPlcqmKmQW50mGKtRYKU9YlhQuXvy4p6 EsVWVeHfSYw== X-Google-Smtp-Source: AGHT+IH4pgzcrpDhGrT0rX+Vc3XOdrrsrao9+nRtXM1BqRqOsH4OU1IeH8nyDCUOhEM31RCoVlw0Gg== X-Received: by 2002:a05:6000:2707:b0:386:39fd:5ec with SMTP id ffacd0b85a97d-38645401ec3mr2146932f8f.57.1733825665448; Tue, 10 Dec 2024 02:14:25 -0800 (PST) Message-ID: Date: Tue, 10 Dec 2024 11:14:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/4] Use an include/boot directory to override headers for boot code To: Frediano Ziglio Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241122093358.478774-1-frediano.ziglio@cloud.com> <20241122093358.478774-2-frediano.ziglio@cloud.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: <20241122093358.478774-2-frediano.ziglio@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22.11.2024 10:33, Frediano Ziglio wrote: > Not all headers can be used by 32 bit boot code. > Allows to override some headers, we don't want to mess up with > main headers as most of the code is only 64 bit so the easy stuff should > be done for 64 bit declarations. > Boot headers should be 64 bit compatibles to avoid having multiple > declarations. I'm afraid that in isolation it's not clear what is intended. Boot code is all located in a single directory. Can't we use local headers there, using #include "...", instead of ... > --- a/xen/arch/x86/boot/Makefile > +++ b/xen/arch/x86/boot/Makefile > @@ -18,7 +18,7 @@ CFLAGS_x86_32 := $(subst -m64,-m32 -march=i686,$(XEN_TREEWIDE_CFLAGS)) > $(call cc-options-add,CFLAGS_x86_32,CC,$(EMBEDDED_EXTRA_CFLAGS)) > CFLAGS_x86_32 += -Werror -fno-builtin -g0 -msoft-float -mregparm=3 > CFLAGS_x86_32 += -nostdinc -include $(filter %/include/xen/config.h,$(XEN_CFLAGS)) > -CFLAGS_x86_32 += $(filter -I% -O%,$(XEN_CFLAGS)) -D__XEN__ > +CFLAGS_x86_32 += -I$(srctree)/arch/x86/include/boot $(filter -I% -O%,$(XEN_CFLAGS)) -D__XEN__ ... introducing a arch-wide subdir, which non-boot code could easily (ab)use? Jan From xen-devel-bounces@lists.xenproject.org Tue Dec 10 10:30:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Dec 2024 10:30:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.852007.1265936 (Exim 4.92) (envelope-from ) id 1tKxV6-0007uV-4H; Tue, 10 Dec 2024 10:29:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 852007.1265936; Tue, 10 Dec 2024 10:29:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKxV6-0007uO-0g; Tue, 10 Dec 2024 10:29:56 +0000 Received: by outflank-mailman (input) for mailman id 852007; Tue, 10 Dec 2024 10:29: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 1tKxV4-0007tz-1L for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 10:29:54 +0000 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [2a00:1450:4864:20::12a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b0ddb979-b6e1-11ef-a0d5-8be0dac302b0; Tue, 10 Dec 2024 11:29:52 +0100 (CET) Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-54021daa6cbso1582879e87.0 for ; Tue, 10 Dec 2024 02:29:52 -0800 (PST) Received: from [192.168.219.191] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5401b7d350asm812878e87.238.2024.12.10.02.29.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Dec 2024 02: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: b0ddb979-b6e1-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733826592; x=1734431392; darn=lists.xenproject.org; h=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=e56HJFEuP8xSKu7tpdVZwz0YulVxvs3x9gEPcdQhG60=; b=nej2/mAy9fEPaBhkkwOeGV5GMaH0Q8MgEJ89dMthKHaDrwoyWS1EoHl9N86ebKVv8D rk9qnO50aBOChH56Dn8BfcjdTaNBpz+r4c0NUSaSRANdkQEQHbd3hw9GblW8FrG+iJaa nqxahTAOjDmHOxtLe0AHXlbGMIs+Mpv8fOPJq2Q2cK42XYdvegZCLI8KrI354HmgQrKp a4agnn/Z7exe8tBRFw0wKrBjeSbcXRmD2Mm64ubPyPlcIx58JQWrCsWXxE/SrRK1n2rz W27TGJL5QeU3ib17pvVfFOHbh4fJmiN66nuGLVT32+mwwT9GYQu4y6QcsM3MhUQaJeCn X3aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733826592; x=1734431392; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=e56HJFEuP8xSKu7tpdVZwz0YulVxvs3x9gEPcdQhG60=; b=ifvro0BzKnkfSgXGIkizFMSVw2E1ORztJ9hTR1/0lLbSrIPqRnOKRF5Tmu2aPQ4kOA KWz+cAioD9rkc1b6xsj4hS4etAoz0c4ZQzrAku5jTO/McTM54ATdct/EnrD+oSJ1x4OZ l5RGz9hlrbWNxLxV+C8ac+WlXvlMjkPnsvZqOlAKERaxlBKxdlhGtdV6FDI3bOhYg55m +7eAjIPZPt5kmcC+XvzS5mtKhGDkjcZtOgQGa4D2LApWjlWGFmC/+P2M/5S6a1nfhJuK 9e2AQvsRueGX84ZlXjX2kMRJo3TRGm1nzW9vwUWBd+jRTpl4rRkYzvBbcT4RIlJIZLCr eSjw== X-Forwarded-Encrypted: i=1; AJvYcCX/frzblRhyFS9JY49lpUpfxpVTWuVSiGV64DeW6mEtJjg8W+mAMbgkwdFL9Mr0tGD9iaDDhZmSa0c=@lists.xenproject.org X-Gm-Message-State: AOJu0YypPKTPkmYyfeWfVQyQeFi3ccFMLoGvSyQWWiLigjDbTwoQsZms vm3advoiR/S+1akhO29UzHX/rVIKgqxaALgpurdawU0NwPRG7OR9 X-Gm-Gg: ASbGncvkdLlVjy7K1Nx00ckmOYSSJ1aGekZ+AuMtvaYvL8UFTpxzNhlQNpnoSctm4zq QYtwIgbV1JnAM78VJwNWD1oHWLbFTlPwwkm7fkQDjkmvCyx8tO7+5dIvfet1jDF5j2KnJ1h5Qhh uVGF043I0/vR2uu9sSEoYtOPCp6An2lxzvUCJwQZReUtI5nvFD1HE2zebuQlNirxGaMFK0FIF9b EmiV9hFLUJ5zW1BwxrZ+ft6k87hUqeGBIHIWbfQNBDMWpvNx9wLVRvmknZQPvJttUY= X-Google-Smtp-Source: AGHT+IFEhK3Pb7KyI7IehUsjMIScysqERkg6gQLVRPFbMGMyzXi8FSCSr9nH00fU5bscgVYl+GYiUQ== X-Received: by 2002:a05:6512:e88:b0:540:20a9:9abd with SMTP id 2adb3069b0e04-540240ac5ecmr1407854e87.6.1733826591289; Tue, 10 Dec 2024 02:29:51 -0800 (PST) Content-Type: multipart/alternative; boundary="------------Nj5vBLRcso470spXc9TpPFbO" Message-ID: <412fabb2-04e2-49cd-a204-340fea3ad940@gmail.com> Date: Tue, 10 Dec 2024 11:29:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Xen 4.20 Development Update [November] To: Jan Beulich Cc: committers@xenproject.org, kelly.choi@cloud.com, xen-devel@lists.xenproject.org References: <20241204102035.22505-1-oleksii.kurochko@gmail.com> <3e4e504e-f4d4-4ac2-be66-3f32a9f31c9a@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <3e4e504e-f4d4-4ac2-be66-3f32a9f31c9a@suse.com> This is a multi-part message in MIME format. --------------Nj5vBLRcso470spXc9TpPFbO Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/4/24 12:01 PM, Jan Beulich wrote: > On 04.12.2024 11:20, Oleksii Kurochko wrote: >> === x86 === >> >> * Expose consistent topology to guests (v7) >> - Alejandro Vallejo >> -https://lore.kernel.org/xen-devel/20241021154600.11745-1-alejandro.vallejo@cloud.com/T/#m6033f95c660675039d7789d3af1ba2f292a3a69b >> >> * Boot modules for Hyperlaunch (v8 -> v9) >> - Daniel P. Smith >> -https://patchew.org/Xen/20241115131204.32135-1-dpsmith@apertussolutions.com/ >> >> * x86/mm: miscellaneous fixes (v2 -> v3) >> - Roger Pau Monne >> -https://patchew.org/Xen/20241114145715.59777-1-roger.pau@citrix.com/ > This went in, didn't it? Yes, you are right. It is fully in staging now. > >> * Address Space Isolation FPU preparations (v2) >> - Alejandro Vallejo >> -https://lore.kernel.org/xen-devel/20241105143310.28301-1-alejandro.vallejo@cloud.com/T/#mbca5192d7e5636ef5ea005a083e5ff28ebe6317d >> >> * x86/alternatives: Adjust all insn-relative fields (v2) >> - Andrew Cooper >> -https://lore.kernel.org/xen-devel/20241002152725.1841575-1-andrew.cooper3@citrix.com/T/#mac2deaea7e02a343210d61887486433d946ad129 >> >> * Support device passthrough when dom0 is PVH on Xen (v16) >> - Jiqian Chen >> -https://lore.kernel.org/xen-devel/20240930034250.2682265-1-Jiqian.Chen@amd.com/T/#m5d557d76f290ff5b5550c1443cab5774d397e526 > Some of this went in too, I think? "Support device passthrough when dom0 is PVH on Xen" should be moved to Completed. ( Accidentally did a grep for the cover letter subject not for the subject of the 1st patch so though that 1st patch isn't merged. And it seems to me that it should be mentioned in CHANGELOG.md, shouldn't it? > >> * x86emul: misc additions (v5 -> v7) >> - Jan Beulich >> -https://patchew.org/Xen/3a25cd59-e1cb-4bfc-b868-fb11599d22f5@suse.com/ >> >> * x86/HVM: emulation (MMIO) improvements (v2) >> - Jan Beulich >> -https://lore.kernel.org/xen-devel/3294f629-f91f-4b5d-9eb0-40a34aa2ec3e@suse.com/ >> >> * x86: support AVX10.1 (v2) >> - Jan Beulich >> -https://lore.kernel.org/xen-devel/bcfea345-57c1-43d9-82b3-240b685486cc@suse.com/ > In v2 the title had changed to "x86: support AVX10", dealing with a first > aspect of AVX10.2 as well. I have long completed AVX10.2 work, yet there > was little reason to re-post without having got any feedback. Thanks, I will update the subject. > >> * APX support (v?) >> - Jan Beulich >> - ? > I think you want to remove this from the list. While I have completed work > there, I'm not fancying re-basing ahead of the AVX10 work, and hence that > needs to go in first anyway. Which seems unlikely enough at this point, for > 4.20. > >> * VT-d: SATC handling; ATS: tidying (v2) >> - Jan Beulich >> -https://patchew.org/Xen/64b028be-2197-4951-ae5b-32f9eabfa84a@suse.com/ >> >> * x86: parallelize AP bring-up during boot (v1) >> - Krystian Hebel >> -https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.hebel@3mdeb.com/ >> >> * x86: memcpy() / memset() (non-)ERMS flavors plus (v3) >> - Jan Beulich >> -https://lore.kernel.org/xen-devel/e7314ac8-ed09-4da8-b915-09409b01fe77@suse.com/ > Isn't this the same as ... > >> * x86/spec-ctrl: IBPB improvements (v4) >> - Jan Beulich >> -https://patchew.org/Xen/06591b64-2f05-a4cc-a2f3-a74c3c4a76d6@suse.com/ >> >> * Move some boot code from assembly to C (v2) >> - Frediano Ziglio >> -https://patchew.org/Xen/20241122093358.478774-1-frediano.ziglio@cloud.com/ >> >> * Hyperlaunch device tree for dom0 (v1) >> - Daniel P. Smith >> -https://patchew.org/Xen/20241123182044.30687-1-dpsmith@apertussolutions.com/ >> >> * x86: memcpy() / memset() (non-)ERMS flavors plus fallout (v3) >> - Jan Beulich >> -https://patchew.org/Xen/e7314ac8-ed09-4da8-b915-09409b01fe77@suse.com/ > ... this? This is the same and one of them I will drop for the next report. > >> * amd-pstate CPU Performance Scaling Driver (v1) >> - Penny Zheng >> -https://patchew.org/Xen/20241203081111.463400-1-Penny.Zheng@amd.com/ > This series was posted only this week, and upon asking it was clarified that > it's indeed not aiming at 4.20. Yes, it is definitely not for the current one release. Probably it would make sense to add the extra line information that it is for the next one release. ~ Oleksii --------------Nj5vBLRcso470spXc9TpPFbO Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 12/4/24 12:01 PM, Jan Beulich wrote:
On 04.12.2024 11:20, Oleksii Kurochko wrote:

=== x86 === 

*  Expose consistent topology to guests (v7)
  -  Alejandro Vallejo
  -  https://lore.kernel.org/xen-devel/20241021154600.11745-1-alejandro.vallejo@cloud.com/T/#m6033f95c660675039d7789d3af1ba2f292a3a69b

*  Boot modules for Hyperlaunch (v8 -> v9)
  -  Daniel P. Smith
  -  https://patchew.org/Xen/20241115131204.32135-1-dpsmith@apertussolutions.com/

*  x86/mm: miscellaneous fixes (v2 -> v3)
  -  Roger Pau Monne
  -  https://patchew.org/Xen/20241114145715.59777-1-roger.pau@citrix.com/

This went in, didn't it?
Yes, you are right. It is fully in staging now.




*  Address Space Isolation FPU preparations (v2)
  -  Alejandro Vallejo
  -  https://lore.kernel.org/xen-devel/20241105143310.28301-1-alejandro.vallejo@cloud.com/T/#mbca5192d7e5636ef5ea005a083e5ff28ebe6317d

*  x86/alternatives: Adjust all insn-relative fields (v2)
  -  Andrew Cooper
  -  https://lore.kernel.org/xen-devel/20241002152725.1841575-1-andrew.cooper3@citrix.com/T/#mac2deaea7e02a343210d61887486433d946ad129

*  Support device passthrough when dom0 is PVH on Xen (v16)
  -  Jiqian Chen
  -  https://lore.kernel.org/xen-devel/20240930034250.2682265-1-Jiqian.Chen@amd.com/T/#m5d557d76f290ff5b5550c1443cab5774d397e526

Some of this went in too, I think?
"Support device passthrough when dom0 is PVH on Xen" should be moved to Completed. ( Accidentally did a grep for the cover letter subject not
for the subject of the 1st patch so though that 1st patch isn't merged.

And it seems to me that it should be mentioned in CHANGELOG.md, shouldn't it?





*  x86emul: misc additions (v5 -> v7)
  -  Jan Beulich
  -  https://patchew.org/Xen/3a25cd59-e1cb-4bfc-b868-fb11599d22f5@suse.com/

*  x86/HVM: emulation (MMIO) improvements (v2)
  -  Jan Beulich
  -  https://lore.kernel.org/xen-devel/3294f629-f91f-4b5d-9eb0-40a34aa2ec3e@suse.com/

*  x86: support AVX10.1 (v2)
  -  Jan Beulich
  -  https://lore.kernel.org/xen-devel/bcfea345-57c1-43d9-82b3-240b685486cc@suse.com/

In v2 the title had changed to "x86: support AVX10", dealing with a first
aspect of AVX10.2 as well. I have long completed AVX10.2 work, yet there
was little reason to re-post without having got any feedback.

Thanks, I will update the subject.




*  APX support (v?)
  -  Jan Beulich
  -  ?

I think you want to remove this from the list. While I have completed work
there, I'm not fancying re-basing ahead of the AVX10 work, and hence that
needs to go in first anyway. Which seems unlikely enough at this point, for
4.20.


*  VT-d: SATC handling; ATS: tidying (v2)
  -  Jan Beulich
  -  https://patchew.org/Xen/64b028be-2197-4951-ae5b-32f9eabfa84a@suse.com/

*  x86: parallelize AP bring-up during boot (v1)
  -  Krystian Hebel
  -  https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.hebel@3mdeb.com/

*  x86: memcpy() / memset() (non-)ERMS flavors plus (v3)
  -  Jan Beulich
  -  https://lore.kernel.org/xen-devel/e7314ac8-ed09-4da8-b915-09409b01fe77@suse.com/

Isn't this the same as ...


*  x86/spec-ctrl: IBPB improvements (v4)
  -  Jan Beulich
  -  https://patchew.org/Xen/06591b64-2f05-a4cc-a2f3-a74c3c4a76d6@suse.com/

*  Move some boot code from assembly to C (v2)
  -  Frediano Ziglio
  -  https://patchew.org/Xen/20241122093358.478774-1-frediano.ziglio@cloud.com/

*  Hyperlaunch device tree for dom0 (v1)
  -  Daniel P. Smith
  -  https://patchew.org/Xen/20241123182044.30687-1-dpsmith@apertussolutions.com/

*  x86: memcpy() / memset() (non-)ERMS flavors plus fallout (v3)
  -  Jan Beulich
  -  https://patchew.org/Xen/e7314ac8-ed09-4da8-b915-09409b01fe77@suse.com/

... this?

This is the same and one of them I will drop for the next report.




*  amd-pstate CPU Performance Scaling Driver (v1)
  -  Penny Zheng
  -  https://patchew.org/Xen/20241203081111.463400-1-Penny.Zheng@amd.com/

This series was posted only this week, and upon asking it was clarified that
it's indeed not aiming at 4.20.
Yes, it is definitely not for the current one release. Probably it would make sense to add the extra line information
that it is for the next one release.


~ Oleksii
--------------Nj5vBLRcso470spXc9TpPFbO-- From xen-devel-bounces@lists.xenproject.org Tue Dec 10 10:32:16 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Dec 2024 10:32:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.852018.1265945 (Exim 4.92) (envelope-from ) id 1tKxXL-00017Y-Fr; Tue, 10 Dec 2024 10:32:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 852018.1265945; Tue, 10 Dec 2024 10:32: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 1tKxXL-00017R-DC; Tue, 10 Dec 2024 10:32:15 +0000 Received: by outflank-mailman (input) for mailman id 852018; Tue, 10 Dec 2024 10:32: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 1tKxXJ-00017J-MJ for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 10:32:13 +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 047e52df-b6e2-11ef-a0d5-8be0dac302b0; Tue, 10 Dec 2024 11:32:12 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-43618283d48so1628475e9.1 for ; Tue, 10 Dec 2024 02:32:12 -0800 (PST) Received: from ?IPV6:2003:ca:b746:63c:3d8c:c505:78ea:f982? (p200300cab746063c3d8cc50578eaf982.dip0.t-ipconnect.de. [2003:ca:b746:63c:3d8c:c505:78ea:f982]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-386257de681sm15319206f8f.30.2024.12.10.02.32.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Dec 2024 02:32: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: 047e52df-b6e2-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733826732; x=1734431532; 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=wrsaL8lPzdJBljcZkobWdtbfzHFiATXp4JkNcdUAd8A=; b=KtczgWFzdwh1tmQNcDNKsahViWV/OChoAci9zSkZlaTxNGuZa+54Hz1JZnF15ksPTj FIUi+s+POxq/QjcPEwUlueizc6QBTfZ83M+u6QFLjvAXFdUDbRcLBWD1U0EflM6myPka JHzuxS6/RX7zhGA4w3dAmuR7HhGZB8TvXOPSbjU94aNJvCQQPp82HIItzM79mEQ3SOAr kt1u5VAwchf9GGjHUSBXO6fBcvKQioaKXw2v3umuAxdre43zJ7wJKBDf1GgikWui+Cff VtYScG1O5uIZvoL5UAB5JKAnTGI/nCHuia/RLLUXA1YXlPshbBWflXF2P9CeYX/D3+NR +6Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733826732; x=1734431532; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wrsaL8lPzdJBljcZkobWdtbfzHFiATXp4JkNcdUAd8A=; b=SosWicGWISqn63EQ7pP+S+zOwbVv9pmdZTJ9Gi8pF/o3LfE6StC9bCS9KcrbZeTOms 78vTWC4FllhekMskZq3dL8xvp+FPf/qJijenK8EoKHDmibxAOASqyqcr7T0Jdd/QrJVg iBMqBdI0y7uOX9h8Lf2ynKnuWUgZD/k8y+oRUk/K/OXfkugYdz4uD/IJZgjU4okyrsC7 ygCt2Pj7Vo+ffl2bxiYfUyLAN8rIPsucVkShQFnZUh8K3BukB35pRa6SrUEzirwrXCuS qgdbykFKPk/Zdo4iu0pJc2fHuIM/c1d4EB327vHbtdMOYIeKmUvhFDOMUi1bcWWh89gX p/YQ== X-Forwarded-Encrypted: i=1; AJvYcCVp3ceda5Je0nKkYip34KM+FggYE1eUeBdjPljfmC0jZw0SPbLpFpVT/HdnjkYnG5+fYk3xpOrMNyI=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx0/TbiXOEzHZrwawrJEZyMVT01vPsDfJ0cEngNfxeOah07UDzZ Fd/aVoOll30JEXbKj21Fb0Cb7bxPGJD48YtQyQrX9WuAs943J4sz29eX8ahD2w== X-Gm-Gg: ASbGncvlEeLgj/0CRd0d8LKL4CrWUZQ33ggjsdjZG6JXqjRFDPADErI/k2rDg0raLfT Rd5JbyqPHsOvB3C2t2Wlab199s+Cqlt5y22M3hLLWoKZeqv/xokV8GLRSS4v2+TeCKMZeuaseCZ E6fdWdnC8fLHubjAfJfkxP0TGDfJVr23tkV1lNNpwbKUUwi2D58OWTBGR/WD9GIjVN6T9woz6xB +xIK0tWrsIj7lo3m//q1SilPyzF+0tkIHbrTxHBLwxsynHh9aK7ik5dEj1oL79gaNBQ8VK7HRPe DHaXs9y/kssgdn1V2hZe502v+e9+7UOyZ5dWfEolzCWR3nHuf4DKc1+IFgqkFPjb7i1PcQBozM0 UafQ3Nn9HsA== X-Google-Smtp-Source: AGHT+IHqTWTgBSfA6rJVH6up5w7JiHh4p33WXWoKym+rcgwNTN/gnpuH43b/xfXQFyBcLrIbn4gVoQ== X-Received: by 2002:a05:6000:1ac9:b0:385:e429:e59e with SMTP id ffacd0b85a97d-3862b3e5ffcmr10879417f8f.52.1733826732178; Tue, 10 Dec 2024 02:32:12 -0800 (PST) Message-ID: <7f74b7a9-1869-4efa-a213-04d56ba48fb1@suse.com> Date: Tue, 10 Dec 2024 11:32:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/4] x86/boot: Use header to allows inclusion of public xen.h header To: Frediano Ziglio Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241122093358.478774-1-frediano.ziglio@cloud.com> <20241122093358.478774-3-frediano.ziglio@cloud.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: <20241122093358.478774-3-frediano.ziglio@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22.11.2024 10:33, Frediano Ziglio wrote: > This allows to include other headers and avoid duplicated declarations. > > Signed-off-by: Frediano Ziglio Again it's left unclear what the purpose / goal is. > --- /dev/null > +++ b/xen/arch/x86/include/boot/public/xen.h > @@ -0,0 +1,28 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +/* This header allows the inclusion of public xen.h */ > + > +#ifndef BOOT__PUBLIC__XEN_H > +#define BOOT__PUBLIC__XEN_H > + > +#if !defined(__XEN__) || defined(__XEN_TOOLS__) || __XEN__ != 1 > +#error Unexpected defines > +#endif What is this to guard against? We're in the Xen tree, building Xen. > +#include > + > +#ifdef __i386__ > + > +# define __XEN_TOOLS__ 1 > +# undef __XEN__ > +# include > +# define __XEN__ 1 > +# undef __XEN_TOOLS__ Why would __XEN__ need un-defining and __XEN_TOOLS__ (seemingly wrongly) need defining? (As an aside, I don't think the expansion of either macro really matters. IOW I don#t see the need for the two 1-s.) Jan From xen-devel-bounces@lists.xenproject.org Tue Dec 10 10:37:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Dec 2024 10:37:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.852034.1265955 (Exim 4.92) (envelope-from ) id 1tKxcl-0001kg-2U; Tue, 10 Dec 2024 10:37:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 852034.1265955; Tue, 10 Dec 2024 10:37: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 1tKxck-0001kZ-W0; Tue, 10 Dec 2024 10:37:50 +0000 Received: by outflank-mailman (input) for mailman id 852034; Tue, 10 Dec 2024 10:37: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 1tKxci-0001kT-Vt for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 10:37:49 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cb528a1c-b6e2-11ef-a0d5-8be0dac302b0; Tue, 10 Dec 2024 11:37:46 +0100 (CET) Received: from delta.homenet.telecomitalia.it (host-82-59-161-229.retail.telecomitalia.it [82.59.161.229]) by support.bugseng.com (Postfix) with ESMTPSA id 520A84EE0738; Tue, 10 Dec 2024 11:37:42 +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: cb528a1c-b6e2-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail; t=1733827065; bh=MbyAmK6EtCdvkh728s5BCk2UUEejS9A5MX8MGgKIuoU=; h=From:To:Cc:Subject:Date:From; b=CH46Vw4/ABdtl27wMiGRcMVLm+VVwf8jTzF/b9ducilOV9UtvAUfG+Om/rdsqh0XX IGO/3ssAv+nhRkfjekXf5x4JgyhPjbHBwc4ukQRApt9TjUkRgAAlXAFtYDJm2v42nf KCm/f8ATef6CkgqsA6HLnOmUYBvF5xvABI4q21n0TyZysbmYaOB7vLn47yVYTtTvz6 jciwv3g/q+wvDxm0DwjECrzLx6VoiLVjaAB9aov3E/u+udO8nKScqHNwm7UkAxFClw FrlyViJfO+naOTdo5p9sSnLEHvTmcK0QXe5z9ByKRAFSdBjJotxbejo4Pt5n7AZ6hR cF9vQah2bSVBQ== From: Alessandro Zucchelli To: xen-devel@lists.xenproject.org Cc: consulting@bugseng.com, Alessandro Zucchelli , Simone Ballarin , Doug Goldstein , Stefano Stabellini , Andrew Cooper , Jan Beulich , Julien Grall Subject: [PATCH] xen: update ECLAIR service identifiers from MC3R1 to MC3A2. Date: Tue, 10 Dec 2024 11:37:23 +0100 Message-ID: X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Rename all instances of ECLAIR MISRA C:2012 service identifiers, identified by the prefix MC3R1, to use the prefix MC3A2, which refers to MISRA C:2012 Amendment 2 guidelines. This update is motivated by the need to upgrade ECLAIR GitLab runners that use the new naming scheme for MISRA C:2012 Amendment 2 guidelines. Changes to the docs/misra directory are needed in order to keep comment-based deviation up to date. Signed-off-by: Alessandro Zucchelli --- The change was made using the following command: find . -type f -exec sed -i 's/MC3R1/MC3A2/g' {} + In order to avoid CI failures this patch and the ECLAIR runners must be updated at roughly the same time. This backwards-incompatible change is needed to bring to the runners other bugfixes. --- .../eclair_analysis/ECLAIR/B.UNEVALEFF.ecl | 2 +- .../ECLAIR/accepted_guidelines.sh | 2 +- .../eclair_analysis/ECLAIR/analysis.ecl | 6 +- .../eclair_analysis/ECLAIR/deviations.ecl | 244 +++++++++--------- .../eclair_analysis/ECLAIR/monitored.ecl | 208 +++++++-------- automation/eclair_analysis/ECLAIR/tagging.ecl | 176 ++++++------- docs/misra/documenting-violations.rst | 6 +- docs/misra/safe.json | 32 +-- 8 files changed, 338 insertions(+), 338 deletions(-) diff --git a/automation/eclair_analysis/ECLAIR/B.UNEVALEFF.ecl b/automation/eclair_analysis/ECLAIR/B.UNEVALEFF.ecl index 92d8db8986..fa249b8e36 100644 --- a/automation/eclair_analysis/ECLAIR/B.UNEVALEFF.ecl +++ b/automation/eclair_analysis/ECLAIR/B.UNEVALEFF.ecl @@ -1,4 +1,4 @@ --clone_service=MC3R1.R13.6,B.UNEVALEFF +-clone_service=MC3A2.R13.6,B.UNEVALEFF -config=B.UNEVALEFF,summary="The operand of the `alignof' and `typeof' operators shall not contain any expression which has potential side effects" -config=B.UNEVALEFF,stmt_child_matcher= diff --git a/automation/eclair_analysis/ECLAIR/accepted_guidelines.sh b/automation/eclair_analysis/ECLAIR/accepted_guidelines.sh index 368135122c..2c4b339d0d 100755 --- a/automation/eclair_analysis/ECLAIR/accepted_guidelines.sh +++ b/automation/eclair_analysis/ECLAIR/accepted_guidelines.sh @@ -10,6 +10,6 @@ script_dir="$( accepted_rst=$1 grep -Eo "\`(Dir|Rule) [0-9]+\.[0-9]+" ${accepted_rst} \ - | sed -e 's/`Rule /MC3R1.R/' -e 's/`Dir /MC3R1.D/' -e 's/.*/-enable=&/' > ${script_dir}/accepted.ecl + | sed -e 's/`Rule /MC3A2.R/' -e 's/`Dir /MC3A2.D/' -e 's/.*/-enable=&/' > ${script_dir}/accepted.ecl echo "-enable=B.UNEVALEFF" >> ${script_dir}/accepted.ecl diff --git a/automation/eclair_analysis/ECLAIR/analysis.ecl b/automation/eclair_analysis/ECLAIR/analysis.ecl index df0b551812..824283a989 100644 --- a/automation/eclair_analysis/ECLAIR/analysis.ecl +++ b/automation/eclair_analysis/ECLAIR/analysis.ecl @@ -22,15 +22,15 @@ setq(analysis_kind,getenv("ANALYSIS_KIND")) -doc_begin="These configurations serve the purpose of recognizing the 'mem*' macros as their Standard Library equivalents." --config=MC3R1.R21.14,call_select+= +-config=MC3A2.R21.14,call_select+= {"macro(^memcmp$)&&any_arg(1..2, skip(__non_syntactic_paren_cast_stmts, node(string_literal)))", "any()", violation, "%{__callslct_any_base_fmt()}", {{arg, "%{__callslct_arg_fmt()}"}}} --config=MC3R1.R21.15,call_args+= +-config=MC3A2.R21.15,call_args+= {"macro(^mem(cmp|move|cpy)$)", {1, 2}, "unqual_pointee_compatible", "%{__argscmpr_culprit_fmt()}", "%{__argscmpr_evidence_fmt()}"} --config=MC3R1.R21.16,call_select+= +-config=MC3A2.R21.16,call_select+= {"macro(^memcmp$)&&any_arg(1..2, skip(__non_syntactic_paren_stmts, type(canonical(__memcmp_pte_types))))", "any()", violation, "%{__callslct_any_base_fmt()}", {{arg,"%{__callslct_arg_type_fmt()}"}}} diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl index 2f58f29203..ae25eeb76a 100644 --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -4,36 +4,36 @@ -doc_begin="The compiler implementation guarantees that the unreachable code is removed. Constant expressions and unreachable branches of if and switch statements are expected." --config=MC3R1.R2.1,+reports={safe,"first_area(^.*has an invariantly.*$)"} --config=MC3R1.R2.1,+reports={safe,"first_area(^.*incompatible with labeled statement$)"} +-config=MC3A2.R2.1,+reports={safe,"first_area(^.*has an invariantly.*$)"} +-config=MC3A2.R2.1,+reports={safe,"first_area(^.*incompatible with labeled statement$)"} -doc_end -doc_begin="Some functions are intended to be not referenced." --config=MC3R1.R2.1,+reports={deliberate,"first_area(^.*is never referenced$)"} +-config=MC3A2.R2.1,+reports={deliberate,"first_area(^.*is never referenced$)"} -doc_end -doc_begin="Unreachability caused by calls to the following functions or macros is deliberate and there is no risk of code being unexpectedly left out." --config=MC3R1.R2.1,statements+={deliberate,"macro(name(BUG||assert_failed))"} --config=MC3R1.R2.1,statements+={deliberate, "call(decl(name(__builtin_unreachable||panic||do_unexpected_trap||machine_halt||machine_restart||reboot_or_halt)))"} +-config=MC3A2.R2.1,statements+={deliberate,"macro(name(BUG||assert_failed))"} +-config=MC3A2.R2.1,statements+={deliberate, "call(decl(name(__builtin_unreachable||panic||do_unexpected_trap||machine_halt||machine_restart||reboot_or_halt)))"} -doc_end -doc_begin="Unreachability inside an ASSERT_UNREACHABLE() and analogous macro calls is deliberate and safe." --config=MC3R1.R2.1,reports+={deliberate, "any_area(any_loc(any_exp(macro(name(ASSERT_UNREACHABLE||PARSE_ERR_RET||PARSE_ERR||FAIL_MSR||FAIL_CPUID)))))"} +-config=MC3A2.R2.1,reports+={deliberate, "any_area(any_loc(any_exp(macro(name(ASSERT_UNREACHABLE||PARSE_ERR_RET||PARSE_ERR||FAIL_MSR||FAIL_CPUID)))))"} -doc_end -doc_begin="The asm-offset files are not linked deliberately, since they are used to generate definitions for asm modules." -file_tag+={asm_offsets, "^xen/arch/(arm|x86)/(arm32|arm64|x86_64)/asm-offsets\\.c$"} --config=MC3R1.R2.1,reports+={deliberate, "any_area(any_loc(file(asm_offsets)))"} +-config=MC3A2.R2.1,reports+={deliberate, "any_area(any_loc(file(asm_offsets)))"} -doc_end -doc_begin="Pure declarations (i.e., declarations without initialization) are not executable, and therefore it is safe for them to be unreachable." --config=MC3R1.R2.1,ignored_stmts+={"any()", "pure_decl()"} +-config=MC3A2.R2.1,ignored_stmts+={"any()", "pure_decl()"} -doc_end -doc_begin="The following autogenerated file is not linked deliberately." -file_tag+={C_runtime_failures,"^automation/eclair_analysis/C-runtime-failures\\.rst\\.c$"} --config=MC3R1.R2.1,reports+={deliberate, "any_area(any_loc(file(C_runtime_failures)))"} +-config=MC3A2.R2.1,reports+={deliberate, "any_area(any_loc(file(C_runtime_failures)))"} -doc_end -doc_begin="Proving compliance with respect to Rule 2.2 is generally impossible: @@ -42,11 +42,11 @@ confidence that no evidence of errors in the program's logic has been missed due to undetected violations of Rule 2.2, if any. Testing on time behavior gives us confidence on the fact that, should the program contain dead code that is not removed by the compiler, the resulting slowdown is negligible." --config=MC3R1.R2.2,reports+={disapplied,"any()"} +-config=MC3A2.R2.2,reports+={disapplied,"any()"} -doc_end -doc_begin="Some labels are unused in certain build configurations, or are deliberately marked as unused, so that the compiler is entitled to remove them." --config=MC3R1.R2.6,reports+={deliberate, "any_area(text(^.*__maybe_unused.*$))"} +-config=MC3A2.R2.6,reports+={deliberate, "any_area(text(^.*__maybe_unused.*$))"} -doc_end # @@ -55,7 +55,7 @@ removed by the compiler, the resulting slowdown is negligible." -doc_begin="Comments starting with '/*' and containing hyperlinks are safe as they are not instances of commented-out code." --config=MC3R1.R3.1,reports+={safe, "first_area(text(^.*https?://.*$))"} +-config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*https?://.*$))"} -doc_end # @@ -63,25 +63,25 @@ they are not instances of commented-out code." # -doc_begin="The directive has been accepted only for the ARM codebase." --config=MC3R1.D4.3,reports+={disapplied,"!(any_area(any_loc(file(^xen/arch/arm/arm64/.*$))))"} +-config=MC3A2.D4.3,reports+={disapplied,"!(any_area(any_loc(file(^xen/arch/arm/arm64/.*$))))"} -doc_end -doc_begin="The inline asm in 'arm64/lib/bitops.c' is tightly coupled with the surronding C code that acts as a wrapper, so it has been decided not to add an additional encapsulation layer." -file_tag+={arm64_bitops, "^xen/arch/arm/arm64/lib/bitops\\.c$"} --config=MC3R1.D4.3,reports+={deliberate, "all_area(any_loc(file(arm64_bitops)&&any_exp(macro(^(bit|test)op$))))"} --config=MC3R1.D4.3,reports+={deliberate, "any_area(any_loc(file(arm64_bitops))&&context(name(int_clear_mask16)))"} +-config=MC3A2.D4.3,reports+={deliberate, "all_area(any_loc(file(arm64_bitops)&&any_exp(macro(^(bit|test)op$))))"} +-config=MC3A2.D4.3,reports+={deliberate, "any_area(any_loc(file(arm64_bitops))&&context(name(int_clear_mask16)))"} -doc_end -doc_begin="Files that are intended to be included more than once do not need to conform to the directive." --config=MC3R1.D4.10,reports+={safe, "first_area(text(^/\\* This file is legitimately included multiple times\\. \\*/$, begin-4))"} --config=MC3R1.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not edit! \\*/$, begin-3))"} --config=MC3R1.D4.10,reports+={safe, "all_area(all_loc(file(^xen/include/generated/autoconf.h$)))"} +-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* This file is legitimately included multiple times\\. \\*/$, begin-4))"} +-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not edit! \\*/$, begin-3))"} +-config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(file(^xen/include/generated/autoconf.h$)))"} -doc_end -doc_begin="Including multiple times a .c file is safe because every function or data item it defines would (in the common case) be already defined. Peer reviewed by the community." --config=MC3R1.D4.10,reports+={safe, "all_area(all_loc(^.*\\.c$))"} +-config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(^.*\\.c$))"} -doc_end # @@ -90,50 +90,50 @@ it defines would (in the common case) be already defined. Peer reviewed by the c -doc_begin="The project adopted the rule with an exception listed in 'docs/misra/rules.rst'" --config=MC3R1.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^READ_SYSREG$))&&any_exp(macro(^WRITE_SYSREG$))))"} --config=MC3R1.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^max(_t)?$))&&any_exp(macro(^min(_t)?$))))"} --config=MC3R1.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^read[bwlq]$))&&any_exp(macro(^read[bwlq]_relaxed$))))"} --config=MC3R1.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^per_cpu$))&&any_exp(macro(^this_cpu$))))"} --config=MC3R1.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^__emulate_2op$))&&any_exp(macro(^__emulate_2op_nobyte$))))"} --config=MC3R1.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^read_debugreg$))&&any_exp(macro(^write_debugreg$))))"} +-config=MC3A2.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^READ_SYSREG$))&&any_exp(macro(^WRITE_SYSREG$))))"} +-config=MC3A2.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^max(_t)?$))&&any_exp(macro(^min(_t)?$))))"} +-config=MC3A2.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^read[bwlq]$))&&any_exp(macro(^read[bwlq]_relaxed$))))"} +-config=MC3A2.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^per_cpu$))&&any_exp(macro(^this_cpu$))))"} +-config=MC3A2.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^__emulate_2op$))&&any_exp(macro(^__emulate_2op_nobyte$))))"} +-config=MC3A2.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^read_debugreg$))&&any_exp(macro(^write_debugreg$))))"} -doc_end -doc_begin="Macros expanding to their own identifier (e.g., \"#define x x\") are deliberate." --config=MC3R1.R5.5,reports+={deliberate, "all_area(macro(same_id_body())||!macro(!same_id_body()))"} +-config=MC3A2.R5.5,reports+={deliberate, "all_area(macro(same_id_body())||!macro(!same_id_body()))"} -doc_end -doc_begin="There is no clash between function like macros and not callable objects." --config=MC3R1.R5.5,reports+={deliberate, "all_area(macro(function_like())||decl(any()))&&all_area(macro(any())||!decl(kind(function))&&!decl(__function_pointer_decls))"} +-config=MC3A2.R5.5,reports+={deliberate, "all_area(macro(function_like())||decl(any()))&&all_area(macro(any())||!decl(kind(function))&&!decl(__function_pointer_decls))"} -doc_end -doc_begin="Clashes between function names and macros are deliberate for string handling functions since some architectures may want to use their own arch-specific implementation." --config=MC3R1.R5.5,reports+={deliberate, "all_area(all_loc(file(^xen/arch/x86/string\\.c|xen/include/xen/string\\.h|xen/lib/.*$)))"} +-config=MC3A2.R5.5,reports+={deliberate, "all_area(all_loc(file(^xen/arch/x86/string\\.c|xen/include/xen/string\\.h|xen/lib/.*$)))"} -doc_end -doc_begin="In libelf, clashes between macros and function names are deliberate and needed to prevent the use of undecorated versions of memcpy, memset and memmove." --config=MC3R1.R5.5,reports+={deliberate, "any_area(decl(kind(function))||any_loc(macro(name(memcpy||memset||memmove))))&&any_area(any_loc(file(^xen/common/libelf/libelf-private\\.h$)))"} +-config=MC3A2.R5.5,reports+={deliberate, "any_area(decl(kind(function))||any_loc(macro(name(memcpy||memset||memmove))))&&any_area(any_loc(file(^xen/common/libelf/libelf-private\\.h$)))"} -doc_end -doc_begin="The type \"ret_t\" is deliberately defined multiple times, depending on the guest." --config=MC3R1.R5.6,reports+={deliberate,"any_area(any_loc(text(^.*ret_t.*$)))"} +-config=MC3A2.R5.6,reports+={deliberate,"any_area(any_loc(text(^.*ret_t.*$)))"} -doc_end -doc_begin="On X86, the types \"guest_intpte_t\", \"guest_l1e_t\" and \"guest_l2e_t\" are deliberately defined multiple times, depending on the number of guest paging levels." --config=MC3R1.R5.6,reports+={deliberate,"any_area(any_loc(file(^xen/arch/x86/include/asm/guest_pt\\.h$)))&&any_area(any_loc(text(^.*(guest_intpte_t|guest_l[12]e_t).*$)))"} +-config=MC3A2.R5.6,reports+={deliberate,"any_area(any_loc(file(^xen/arch/x86/include/asm/guest_pt\\.h$)))&&any_area(any_loc(text(^.*(guest_intpte_t|guest_l[12]e_t).*$)))"} -doc_end -doc_begin="The following files are imported from the gnu-efi package." -file_tag+={adopted_r5_6,"^xen/include/efi/.*$"} -file_tag+={adopted_r5_6,"^xen/arch/.*/include/asm/.*/efibind\\.h$"} --config=MC3R1.R5.6,reports+={deliberate,"any_area(any_loc(file(adopted_r5_6)))"} +-config=MC3A2.R5.6,reports+={deliberate,"any_area(any_loc(file(adopted_r5_6)))"} -doc_end -doc_begin="The project intentionally reuses tag names in order to have identifiers matching the applicable external specifications as well as established internal conventions. As there is little possibility for developer confusion not resulting into compilation errors, the risk of renaming outweighs the potential advantages of compliance." --config=MC3R1.R5.7,reports+={deliberate,"any()"} +-config=MC3A2.R5.7,reports+={deliberate,"any()"} -doc_end # @@ -142,7 +142,7 @@ As there is little possibility for developer confusion not resulting into compil -doc_begin="It is safe to use certain octal constants the way they are defined in specifications, manuals, and algorithm descriptions." --config=MC3R1.R7.1,reports+={safe, "any_area(any_loc(any_exp(text(^.*octal-ok.*$))))"} +-config=MC3A2.R7.1,reports+={safe, "any_area(any_loc(any_exp(text(^.*octal-ok.*$))))"} -doc_end -doc_begin="Violations in files that maintainers have asked to not modify in the @@ -155,17 +155,17 @@ context of R7.2." -file_tag+={adopted_r7_2,"^xen/arch/x86/cpu/intel\\.c$"} -file_tag+={adopted_r7_2,"^xen/arch/x86/cpu/amd\\.c$"} -file_tag+={adopted_r7_2,"^xen/arch/x86/cpu/common\\.c$"} --config=MC3R1.R7.2,reports+={deliberate,"any_area(any_loc(file(adopted_r7_2)))"} +-config=MC3A2.R7.2,reports+={deliberate,"any_area(any_loc(file(adopted_r7_2)))"} -doc_end -doc_begin="Violations caused by __HYPERVISOR_VIRT_START are related to the particular use of it done in xen_mk_ulong." --config=MC3R1.R7.2,reports+={deliberate,"any_area(any_loc(macro(name(BUILD_BUG_ON))))"} +-config=MC3A2.R7.2,reports+={deliberate,"any_area(any_loc(macro(name(BUILD_BUG_ON))))"} -doc_end -doc_begin="Allow pointers of non-character type as long as the pointee is const-qualified." --config=MC3R1.R7.4,same_pointee=false +-config=MC3A2.R7.4,same_pointee=false -doc_end # @@ -173,7 +173,7 @@ const-qualified." # -doc_begin="The type ret_t is deliberately used and defined as int or long depending on the architecture." --config=MC3R1.R8.3,reports+={deliberate,"any_area(any_loc(text(^.*ret_t.*$)))"} +-config=MC3A2.R8.3,reports+={deliberate,"any_area(any_loc(text(^.*ret_t.*$)))"} -doc_end -doc_begin="The following files are imported from Linux and decompress.h defines a unique and documented interface towards all the (adopted) decompress functions." @@ -183,71 +183,71 @@ const-qualified." -file_tag+={adopted_decompress_r8_3,"^xen/common/unlzo\\.c$"} -file_tag+={adopted_decompress_r8_3,"^xen/common/unxz\\.c$"} -file_tag+={adopted_decompress_r8_3,"^xen/common/unzstd\\.c$"} --config=MC3R1.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_decompress_r8_3)))&&any_area(any_loc(file(^xen/include/xen/decompress\\.h$)))"} +-config=MC3A2.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_decompress_r8_3)))&&any_area(any_loc(file(^xen/include/xen/decompress\\.h$)))"} -doc_end -doc_begin="Parameter name \"unused\" (with an optional numeric suffix) is deliberate and makes explicit the intention of not using such parameter within the function." --config=MC3R1.R8.3,reports+={deliberate, "any_area(^.*parameter `unused[0-9]*'.*$)"} +-config=MC3A2.R8.3,reports+={deliberate, "any_area(^.*parameter `unused[0-9]*'.*$)"} -doc_end -doc_begin="The following file is imported from Linux: ignore for now." -file_tag+={adopted_time_r8_3,"^xen/arch/x86/time\\.c$"} --config=MC3R1.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_time_r8_3)))&&(any_area(any_loc(file(^xen/include/xen/time\\.h$)))||any_area(any_loc(file(^xen/arch/x86/include/asm/setup\\.h$))))"} +-config=MC3A2.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_time_r8_3)))&&(any_area(any_loc(file(^xen/include/xen/time\\.h$)))||any_area(any_loc(file(^xen/arch/x86/include/asm/setup\\.h$))))"} -doc_end -doc_begin="The following file is imported from Linux: ignore for now." -file_tag+={adopted_cpu_idle_r8_3,"^xen/arch/x86/acpi/cpu_idle\\.c$"} --config=MC3R1.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_cpu_idle_r8_3)))&&any_area(any_loc(file(^xen/include/xen/pmstat\\.h$)))"} +-config=MC3A2.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_cpu_idle_r8_3)))&&any_area(any_loc(file(^xen/include/xen/pmstat\\.h$)))"} -doc_end -doc_begin="The following file is imported from Linux: ignore for now." -file_tag+={adopted_mpparse_r8_3,"^xen/arch/x86/mpparse\\.c$"} --config=MC3R1.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_mpparse_r8_3)))&&any_area(any_loc(file(^xen/arch/x86/include/asm/mpspec\\.h$)))"} +-config=MC3A2.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_mpparse_r8_3)))&&any_area(any_loc(file(^xen/arch/x86/include/asm/mpspec\\.h$)))"} -doc_end -doc_begin="The definitions present in this file are meant to generate definitions for asm modules, and are not called by C code. Therefore the absence of prior declarations is safe." -file_tag+={asm_offsets, "^xen/arch/(arm|x86)/(arm32|arm64|x86_64)/asm-offsets\\.c$"} --config=MC3R1.R8.4,reports+={safe, "first_area(any_loc(file(asm_offsets)))"} +-config=MC3A2.R8.4,reports+={safe, "first_area(any_loc(file(asm_offsets)))"} -doc_end -doc_begin="The functions defined in this file are meant to be called from gcc-generated code in a non-release build configuration. Therefore the absence of prior declarations is safe." -file_tag+={gcov, "^xen/common/coverage/gcov_base\\.c$"} --config=MC3R1.R8.4,reports+={safe, "first_area(any_loc(file(gcov)))"} +-config=MC3A2.R8.4,reports+={safe, "first_area(any_loc(file(gcov)))"} -doc_end -doc_begin="Recognize the occurrence of current_stack_pointer as a declaration." -file_tag+={asm_defns, "^xen/arch/x86/include/asm/asm_defns\\.h$"} --config=MC3R1.R8.4,declarations+={safe, "loc(file(asm_defns))&&^current_stack_pointer$"} +-config=MC3A2.R8.4,declarations+={safe, "loc(file(asm_defns))&&^current_stack_pointer$"} -doc_end -doc_begin="The function apei_(read|check|clear)_mce are dead code and are excluded from non-debug builds, therefore the absence of prior declarations is safe." --config=MC3R1.R8.4,declarations+={safe, "^apei_(read|check|clear)_mce\\(.*$"} +-config=MC3A2.R8.4,declarations+={safe, "^apei_(read|check|clear)_mce\\(.*$"} -doc_end -doc_begin="asmlinkage is a marker to indicate that the function is only used to interface with asm modules." --config=MC3R1.R8.4,declarations+={safe,"loc(text(^(?s).*asmlinkage.*$, -1..0))"} +-config=MC3A2.R8.4,declarations+={safe,"loc(text(^(?s).*asmlinkage.*$, -1..0))"} -doc_end -doc_begin="Given that bsearch and sort are defined with the attribute 'gnu_inline', it's deliberate not to have a prior declaration. See Section \"6.33.1 Common Function Attributes\" of \"GCC_MANUAL\" for a full explanation of gnu_inline." -file_tag+={bsearch_sort, "^xen/include/xen/(sort|lib)\\.h$"} --config=MC3R1.R8.4,reports+={deliberate, "any_area(any_loc(file(bsearch_sort))&&decl(name(bsearch||sort)))"} +-config=MC3A2.R8.4,reports+={deliberate, "any_area(any_loc(file(bsearch_sort))&&decl(name(bsearch||sort)))"} -doc_end -doc_begin="first_valid_mfn is defined in this way because the current lack of NUMA support in Arm and PPC requires it." -file_tag+={first_valid_mfn, "^xen/common/page_alloc\\.c$"} --config=MC3R1.R8.4,declarations+={deliberate,"loc(file(first_valid_mfn))"} +-config=MC3A2.R8.4,declarations+={deliberate,"loc(file(first_valid_mfn))"} -doc_end -doc_begin="The following variables are compiled in multiple translation units belonging to different executables and therefore are safe." --config=MC3R1.R8.6,declarations+={safe, "name(current_stack_pointer||bsearch||sort)"} +-config=MC3A2.R8.6,declarations+={safe, "name(current_stack_pointer||bsearch||sort)"} -doc_end -doc_begin="Declarations without definitions are allowed (specifically when the definition is compiled-out or optimized-out by the compiler)" --config=MC3R1.R8.6,reports+={deliberate, "first_area(^.*has no definition$)"} +-config=MC3A2.R8.6,reports+={deliberate, "first_area(^.*has no definition$)"} -doc_end -doc_begin="The search procedure for Unix linkers is well defined, see ld(1) @@ -258,11 +258,11 @@ the linker will include the appropriate file(s) from the archive\". In Xen, thanks to the order in which file names appear in the build commands, if arch-specific definitions are present, they get always linked in before searching in the lib.a archive resulting from xen/lib." --config=MC3R1.R8.6,declarations+={deliberate, "loc(file(^xen/lib/.*$))"} +-config=MC3A2.R8.6,declarations+={deliberate, "loc(file(^xen/lib/.*$))"} -doc_end -doc_begin="The gnu_inline attribute without static is deliberately allowed." --config=MC3R1.R8.10,declarations+={deliberate,"property(gnu_inline)"} +-config=MC3A2.R8.10,declarations+={deliberate,"property(gnu_inline)"} -doc_end # @@ -272,12 +272,12 @@ searching in the lib.a archive resulting from xen/lib." -doc_begin="Violations in files that maintainers have asked to not modify in the context of R9.1." -file_tag+={adopted_r9_1,"^xen/arch/arm/arm64/lib/find_next_bit\\.c$"} --config=MC3R1.R9.1,reports+={deliberate,"any_area(any_loc(file(adopted_r9_1)))"} +-config=MC3A2.R9.1,reports+={deliberate,"any_area(any_loc(file(adopted_r9_1)))"} -doc_end -doc_begin="The possibility of committing mistakes by specifying an explicit dimension is higher than omitting the dimension." --config=MC3R1.R9.5,reports+={deliberate, "any()"} +-config=MC3A2.R9.5,reports+={deliberate, "any()"} -doc_end # @@ -285,45 +285,45 @@ dimension is higher than omitting the dimension." # -doc_begin="The value-preserving conversions of integer constants are safe" --config=MC3R1.R10.1,etypes={safe,"any()","preserved_integer_constant()"} --config=MC3R1.R10.3,etypes={safe,"any()","preserved_integer_constant()"} --config=MC3R1.R10.4,etypes={safe,"any()","preserved_integer_constant()||sibling(rhs,preserved_integer_constant())"} +-config=MC3A2.R10.1,etypes={safe,"any()","preserved_integer_constant()"} +-config=MC3A2.R10.3,etypes={safe,"any()","preserved_integer_constant()"} +-config=MC3A2.R10.4,etypes={safe,"any()","preserved_integer_constant()||sibling(rhs,preserved_integer_constant())"} -doc_end -doc_begin="Shifting non-negative integers to the right is safe." --config=MC3R1.R10.1,etypes+={safe, +-config=MC3A2.R10.1,etypes+={safe, "stmt(node(binary_operator)&&operator(shr))", "src_expr(definitely_in(0..))"} -doc_end -doc_begin="Shifting non-negative integers to the left is safe if the result is still non-negative." --config=MC3R1.R10.1,etypes+={safe, +-config=MC3A2.R10.1,etypes+={safe, "stmt(node(binary_operator)&&operator(shl)&&definitely_in(0..))", "src_expr(definitely_in(0..))"} -doc_end -doc_begin="Bitwise logical operations on non-negative integers are safe." --config=MC3R1.R10.1,etypes+={safe, +-config=MC3A2.R10.1,etypes+={safe, "stmt(node(binary_operator)&&operator(and||or||xor))", "src_expr(definitely_in(0..))"} -doc_end -doc_begin="The implicit conversion to Boolean for logical operator arguments is well known to all Xen developers to be a comparison with 0" --config=MC3R1.R10.1,etypes+={safe, "stmt(operator(logical)||node(conditional_operator||binary_conditional_operator))", "dst_type(ebool||boolean)"} +-config=MC3A2.R10.1,etypes+={safe, "stmt(operator(logical)||node(conditional_operator||binary_conditional_operator))", "dst_type(ebool||boolean)"} -doc_end -doc_begin="The macro ISOLATE_LSB encapsulates a well-known pattern to obtain a mask where only the lowest bit set in the argument is set, if any, for unsigned integers arguments on two's complement architectures (all the architectures supported by Xen satisfy this requirement)." --config=MC3R1.R10.1,reports+={safe, "any_area(any_loc(any_exp(macro(^ISOLATE_LSB$))))"} +-config=MC3A2.R10.1,reports+={safe, "any_area(any_loc(any_exp(macro(^ISOLATE_LSB$))))"} -doc_end -doc_begin="XEN only supports architectures where signed integers are representend using two's complement and all the XEN developers are aware of this." --config=MC3R1.R10.1,etypes+={safe, +-config=MC3A2.R10.1,etypes+={safe, "stmt(operator(and||or||xor||not||and_assign||or_assign||xor_assign))", "any()"} -doc_end @@ -334,7 +334,7 @@ C language, GCC does not use the latitude given in C99 and C11 only to treat certain aspects of signed `<<' as undefined. However, -fsanitize=shift (and -fsanitize=undefined) will diagnose such cases. They are also diagnosed where constant expressions are required.\"" --config=MC3R1.R10.1,etypes+={safe, +-config=MC3A2.R10.1,etypes+={safe, "stmt(operator(shl||shr||shl_assign||shr_assign))", "any()"} -doc_end @@ -344,7 +344,7 @@ constant expressions are required.\"" # -doc_begin="The conversion from a function pointer to unsigned long or (void *) does not lose any information, provided that the target type has enough bits to store it." --config=MC3R1.R11.1,casts+={safe, +-config=MC3A2.R11.1,casts+={safe, "from(type(canonical(__function_pointer_types))) &&to(type(canonical(builtin(unsigned long)||pointer(builtin(void))))) &&relation(definitely_preserves_value)" @@ -352,14 +352,14 @@ constant expressions are required.\"" -doc_end -doc_begin="The conversion from a function pointer to a boolean has a well-known semantics that do not lead to unexpected behaviour." --config=MC3R1.R11.1,casts+={safe, +-config=MC3A2.R11.1,casts+={safe, "from(type(canonical(__function_pointer_types))) &&kind(pointer_to_boolean)" } -doc_end -doc_begin="The conversion from a pointer to an incomplete type to unsigned long does not lose any information, provided that the target type has enough bits to store it." --config=MC3R1.R11.2,casts+={safe, +-config=MC3A2.R11.2,casts+={safe, "from(type(any())) &&to(type(canonical(builtin(unsigned long)))) &&relation(definitely_preserves_value)" @@ -367,20 +367,20 @@ constant expressions are required.\"" -doc_end -doc_begin="Conversions to object pointers that have a pointee type with a smaller (i.e., less strict) alignment requirement are safe." --config=MC3R1.R11.3,casts+={safe, +-config=MC3A2.R11.3,casts+={safe, "!relation(more_aligned_pointee)" } -doc_end -doc_begin="Conversions from and to integral types are safe, in the assumption that the target type has enough bits to store the value. See also Section \"4.7 Arrays and Pointers\" of \"GCC_MANUAL\"" --config=MC3R1.R11.6,casts+={safe, +-config=MC3A2.R11.6,casts+={safe, "(from(type(canonical(integral())))||to(type(canonical(integral())))) &&relation(definitely_preserves_value)"} -doc_end -doc_begin="The conversion from a pointer to a boolean has a well-known semantics that do not lead to unexpected behaviour." --config=MC3R1.R11.6,casts+={safe, +-config=MC3A2.R11.6,casts+={safe, "from(type(canonical(__pointer_types))) &&kind(pointer_to_boolean)" } @@ -390,11 +390,11 @@ See also Section \"4.7 Arrays and Pointers\" of \"GCC_MANUAL\"" with the provided offset. The resulting pointer is then immediately cast back to its original type, which preserves the qualifier. This use is deemed safe. Fixing this violation would require to increase code complexity and lower readability." --config=MC3R1.R11.8,reports+={safe,"any_area(any_loc(any_exp(macro(^container_of$))))"} +-config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(any_exp(macro(^container_of$))))"} -doc_end -doc_begin="This construct is used to check if the type is scalar, and for this purpose the use of 0 as a null pointer constant is deliberate." --config=MC3R1.R11.9,reports+={deliberate, "any_area(any_loc(any_exp(macro(^__ACCESS_ONCE$))))" +-config=MC3A2.R11.9,reports+={deliberate, "any_area(any_loc(any_exp(macro(^__ACCESS_ONCE$))))" } -doc_end @@ -404,16 +404,16 @@ Fixing this violation would require to increase code complexity and lower readab -doc_begin="All developers and reviewers can be safely assumed to be well aware of the short-circuit evaluation strategy of such logical operators." --config=MC3R1.R13.5,reports+={disapplied,"any()"} +-config=MC3A2.R13.5,reports+={disapplied,"any()"} -doc_end -doc_begin="Macros alternative_v?call[0-9] use sizeof and typeof to check that the argument types match the corresponding parameter ones." --config=MC3R1.R13.6,reports+={deliberate,"any_area(any_loc(any_exp(macro(^alternative_vcall[0-9]$))&&file(^xen/arch/x86/include/asm/alternative\\.h*$)))"} +-config=MC3A2.R13.6,reports+={deliberate,"any_area(any_loc(any_exp(macro(^alternative_vcall[0-9]$))&&file(^xen/arch/x86/include/asm/alternative\\.h*$)))"} -config=B.UNEVALEFF,reports+={deliberate,"any_area(any_loc(any_exp(macro(^alternative_v?call[0-9]$))&&file(^xen/arch/x86/include/asm/alterantive\\.h*$)))"} -doc_end -doc_begin="Anything, no matter how complicated, inside the BUILD_BUG_ON macro is subject to a compile-time evaluation without relevant side effects." --config=MC3R1.R13.6,reports+={safe,"any_area(any_loc(any_exp(macro(name(BUILD_BUG_ON)))))"} +-config=MC3A2.R13.6,reports+={safe,"any_area(any_loc(any_exp(macro(name(BUILD_BUG_ON)))))"} -config=B.UNEVALEFF,reports+={safe,"any_area(any_loc(any_exp(macro(name(BUILD_BUG_ON)))))"} -doc_end @@ -424,31 +424,31 @@ of the short-circuit evaluation strategy of such logical operators." -doc_begin="The severe restrictions imposed by this rule on the use of for statements are not balanced by the presumed facilitation of the peer review activity." --config=MC3R1.R14.2,reports+={disapplied,"any()"} +-config=MC3A2.R14.2,reports+={disapplied,"any()"} -doc_end -doc_begin="The XEN team relies on the fact that invariant conditions of 'if' statements and conditional operators are deliberate" --config=MC3R1.R14.3,statements+={deliberate, "wrapped(any(),node(if_stmt||conditional_operator||binary_conditional_operator))" } +-config=MC3A2.R14.3,statements+={deliberate, "wrapped(any(),node(if_stmt||conditional_operator||binary_conditional_operator))" } -doc_end -doc_begin="Switches having a 'sizeof' operator as the condition are deliberate and have limited scope." --config=MC3R1.R14.3,statements+={deliberate, "wrapped(any(),node(switch_stmt)&&child(cond, operator(sizeof)))" } +-config=MC3A2.R14.3,statements+={deliberate, "wrapped(any(),node(switch_stmt)&&child(cond, operator(sizeof)))" } -doc_end -doc_begin="The use of an invariant size argument in {put,get}_unsafe_size and array_access_ok, as defined in arch/x86(_64)?/include/asm/uaccess.h is deliberate and is deemed safe." -file_tag+={x86_uaccess, "^xen/arch/x86(_64)?/include/asm/uaccess\\.h$"} --config=MC3R1.R14.3,reports+={deliberate, "any_area(any_loc(file(x86_uaccess)&&any_exp(macro(^(put|get)_unsafe_size$))))"} --config=MC3R1.R14.3,reports+={deliberate, "any_area(any_loc(file(x86_uaccess)&&any_exp(macro(^array_access_ok$))))"} +-config=MC3A2.R14.3,reports+={deliberate, "any_area(any_loc(file(x86_uaccess)&&any_exp(macro(^(put|get)_unsafe_size$))))"} +-config=MC3A2.R14.3,reports+={deliberate, "any_area(any_loc(file(x86_uaccess)&&any_exp(macro(^array_access_ok$))))"} -doc_end -doc_begin="A controlling expression of 'if' and iteration statements having integer, character or pointer type has a semantics that is well-known to all Xen developers." --config=MC3R1.R14.4,etypes+={deliberate, "any()", "src_type(integer||character)||src_expr(type(desugar(pointer(any()))))"} +-config=MC3A2.R14.4,etypes+={deliberate, "any()", "src_type(integer||character)||src_expr(type(desugar(pointer(any()))))"} -doc_end -doc_begin="The XEN team relies on the fact that the enum is_dying has the constant with assigned value 0 act as false and the other ones as true, therefore have the same behavior of a boolean" --config=MC3R1.R14.4,etypes+={deliberate, "stmt(child(cond,child(expr,ref(^?::is_dying$))))","src_type(enum)"} +-config=MC3A2.R14.4,etypes+={deliberate, "stmt(child(cond,child(expr,ref(^?::is_dying$))))","src_type(enum)"} -doc_end # @@ -459,58 +459,58 @@ therefore have the same behavior of a boolean" therefore it is deemed better to leave such files as is." -file_tag+={x86_emulate,"^xen/arch/x86/x86_emulate/.*$"} -file_tag+={x86_svm_emulate,"^xen/arch/x86/hvm/svm/emulate\\.c$"} --config=MC3R1.R16.2,reports+={deliberate, "any_area(any_loc(file(x86_emulate||x86_svm_emulate)))"} +-config=MC3A2.R16.2,reports+={deliberate, "any_area(any_loc(file(x86_emulate||x86_svm_emulate)))"} -doc_end -doc_begin="Statements that change the control flow (i.e., break, continue, goto, return) and calls to functions that do not return the control back are \"allowed terminal statements\"." -stmt_selector+={r16_3_allowed_terminal, "node(break_stmt||continue_stmt||goto_stmt||return_stmt)||call(property(noreturn))"} --config=MC3R1.R16.3,terminals+={safe, "r16_3_allowed_terminal"} +-config=MC3A2.R16.3,terminals+={safe, "r16_3_allowed_terminal"} -doc_end -doc_begin="An if-else statement having both branches ending with an allowed terminal statement is itself an allowed terminal statement." -stmt_selector+={r16_3_if, "node(if_stmt)&&(child(then,r16_3_allowed_terminal)||child(then,any_stmt(stmt,-1,r16_3_allowed_terminal)))"} -stmt_selector+={r16_3_else, "node(if_stmt)&&(child(else,r16_3_allowed_terminal)||child(else,any_stmt(stmt,-1,r16_3_allowed_terminal)))"} -stmt_selector+={r16_3_if_else, "r16_3_if&&r16_3_else"} --config=MC3R1.R16.3,terminals+={safe, "r16_3_if_else"} +-config=MC3A2.R16.3,terminals+={safe, "r16_3_if_else"} -doc_end -doc_begin="An if-else statement having an always true condition and the true branch ending with an allowed terminal statement is itself an allowed terminal statement." -stmt_selector+={r16_3_if_true, "r16_3_if&&child(cond,definitely_in(1..))"} --config=MC3R1.R16.3,terminals+={safe, "r16_3_if_true"} +-config=MC3A2.R16.3,terminals+={safe, "r16_3_if_true"} -doc_end -doc_begin="A switch clause ending with a statement expression which, in turn, ends with an allowed terminal statement is safe." --config=MC3R1.R16.3,terminals+={safe, "node(stmt_expr)&&child(stmt,node(compound_stmt)&&any_stmt(stmt,-1,r16_3_allowed_terminal||r16_3_if_else||r16_3_if_true))"} +-config=MC3A2.R16.3,terminals+={safe, "node(stmt_expr)&&child(stmt,node(compound_stmt)&&any_stmt(stmt,-1,r16_3_allowed_terminal||r16_3_if_else||r16_3_if_true))"} -doc_end -doc_begin="A switch clause ending with a do-while-false the body of which, in turn, ends with an allowed terminal statement is safe. An exception to that is the macro ASSERT_UNREACHABLE() which is effective in debug build only: a switch clause ending with ASSERT_UNREACHABLE() is not considered safe." --config=MC3R1.R16.3,terminals+={safe, "!macro(name(ASSERT_UNREACHABLE))&&node(do_stmt)&&child(cond,definitely_in(0))&&child(body,any_stmt(stmt,-1,r16_3_allowed_terminal||r16_3_if_else||r16_3_if_true))"} +-config=MC3A2.R16.3,terminals+={safe, "!macro(name(ASSERT_UNREACHABLE))&&node(do_stmt)&&child(cond,definitely_in(0))&&child(body,any_stmt(stmt,-1,r16_3_allowed_terminal||r16_3_if_else||r16_3_if_true))"} -doc_end -doc_begin="Switch clauses ending with pseudo-keyword \"fallthrough\" are safe." --config=MC3R1.R16.3,reports+={safe, "any_area(end_loc(any_exp(text(/fallthrough;/))))"} +-config=MC3A2.R16.3,reports+={safe, "any_area(end_loc(any_exp(text(/fallthrough;/))))"} -doc_end -doc_begin="Switch clauses ending with failure method \"BUG()\" are safe." --config=MC3R1.R16.3,reports+={safe, "any_area(end_loc(any_exp(text(/BUG\\(\\);/))))"} +-config=MC3A2.R16.3,reports+={safe, "any_area(end_loc(any_exp(text(/BUG\\(\\);/))))"} -doc_end -doc_begin="Switch clauses ending with an explicit comment indicating the fallthrough intention are safe." --config=MC3R1.R16.3,reports+={safe, "any_area(end_loc(any_exp(text(^(?s).*/\\* [fF]all ?through\\.? \\*/.*$,0..2))))"} +-config=MC3A2.R16.3,reports+={safe, "any_area(end_loc(any_exp(text(^(?s).*/\\* [fF]all ?through\\.? \\*/.*$,0..2))))"} -doc_end -doc_begin="Switch statements having a controlling expression of enum type deliberately do not have a default case: gcc -Wall enables -Wswitch which warns (and breaks the build as we use -Werror) if one of the enum labels is missing from the switch." --config=MC3R1.R16.4,reports+={deliberate,'any_area(kind(context)&&^.* has no `default.*$&&stmt(node(switch_stmt)&&child(cond,skip(__non_syntactic_paren_stmts,type(canonical(enum_underlying_type(any())))))))'} +-config=MC3A2.R16.4,reports+={deliberate,'any_area(kind(context)&&^.* has no `default.*$&&stmt(node(switch_stmt)&&child(cond,skip(__non_syntactic_paren_stmts,type(canonical(enum_underlying_type(any())))))))'} -doc_end -doc_begin="A switch statement with a single switch clause and no default label may be used in place of an equivalent if statement if it is considered to improve readability." --config=MC3R1.R16.4,switch_clauses+={deliberate,"switch(1)&&default(0)"} +-config=MC3A2.R16.4,switch_clauses+={deliberate,"switch(1)&&default(0)"} -doc_end -doc_begin="A switch statement with a single switch clause and no default label may be used in place of an equivalent if statement if it is considered to improve readability." --config=MC3R1.R16.6,switch_clauses+={deliberate, "default(0)"} +-config=MC3A2.R16.6,switch_clauses+={deliberate, "default(0)"} -doc_end # @@ -518,16 +518,16 @@ safe." # -doc_begin="printf()-like functions are allowed to use the variadic features provided by stdarg.h." --config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printk\\(.*\\)$)))"} --config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printf\\(.*\\)$)))"} --config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"} --config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"} --config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"} --config=MC3R1.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"} +-config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printk\\(.*\\)$)))"} +-config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printf\\(.*\\)$)))"} +-config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"} +-config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"} +-config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"} +-config=MC3A2.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"} -doc_end -doc_begin="Not using the return value of a function does not endanger safety if it coincides with an actual argument." --config=MC3R1.R17.7,calls+={safe, "any()", "decl(name(__builtin_memcpy||__builtin_memmove||__builtin_memset||cpumask_check))"} +-config=MC3A2.R17.7,calls+={safe, "any()", "decl(name(__builtin_memcpy||__builtin_memmove||__builtin_memset||cpumask_check))"} -doc_end # @@ -538,16 +538,16 @@ safe." are guaranteed not to be exploited by a compiler that relies on the absence of C99 Undefined Behaviour 45: Pointers that do not point into, or just beyond, the same array object are subtracted (6.5.6)." -eval_file=linker_symbols.ecl --config=MC3R1.R18.2,reports+={safe, "any_area(stmt(operator(sub)&&child(lhs||rhs, skip(__non_syntactic_paren_stmts, ref(linker_symbols)))))"} +-config=MC3A2.R18.2,reports+={safe, "any_area(stmt(operator(sub)&&child(lhs||rhs, skip(__non_syntactic_paren_stmts, ref(linker_symbols)))))"} -doc_end -doc_begin="The following macro performs a subtraction between pointers to obtain the mfn, but does not lead to undefined behaviour." --config=MC3R1.R18.2,reports+={safe, "any_area(any_loc(any_exp(macro(^page_to_mfn$))))"} +-config=MC3A2.R18.2,reports+={safe, "any_area(any_loc(any_exp(macro(^page_to_mfn$))))"} -doc_end -doc_begin="Flexible array members are deliberately used and XEN developers are aware of the dangers related to them: unexpected result when the structure is given as argument to a sizeof() operator and the truncation in assignment between structures." --config=MC3R1.R18.7,reports+={deliberate, "any()"} +-config=MC3A2.R18.7,reports+={deliberate, "any()"} -doc_end # @@ -558,7 +558,7 @@ unexpected result when the structure is given as argument to a sizeof() operator as function arguments; (2) as macro arguments; (3) as array indices; (4) as lhs in assignments; (5) as initializers, possibly designated, in initalizer lists; (6) as the constant expression in a switch clause label." --config=MC3R1.R20.7,expansion_context= +-config=MC3A2.R20.7,expansion_context= {safe, "context(__call_expr_arg_contexts)"}, {safe, "left_right(^[(,\\[]$,^[),\\]]$)"}, {safe, "context(skip_to(__expr_non_syntactic_contexts, stmt_child(node(array_subscript_expr), subscript)))"}, @@ -571,62 +571,62 @@ in assignments; (5) as initializers, possibly designated, in initalizer lists; breaking the macro's logic; futhermore, the macro is only ever used in the context of the IS_ENABLED or STATIC_IF/STATIC_IF_NOT macros, so it always receives a literal 0 or 1 as input, posing no risk to safety." --config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^___config_enabled$))))"} +-config=MC3A2.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^___config_enabled$))))"} -doc_end -doc_begin="Violations due to the use of macros defined in files that are not in scope for compliance are allowed, as that is imported code." -file_tag+={gnu_efi_include, "^xen/include/efi/.*$"} -file_tag+={acpi_cpu_idle, "^xen/arch/x86/acpi/cpu_idle\\.c$"} --config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(file(gnu_efi_include)||any_exp(macro(^NextMemoryDescriptor$))))"} --config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(file(acpi_cpu_idle)))"} +-config=MC3A2.R20.7,reports+={safe, "any_area(any_loc(file(gnu_efi_include)||any_exp(macro(^NextMemoryDescriptor$))))"} +-config=MC3A2.R20.7,reports+={safe, "any_area(any_loc(file(acpi_cpu_idle)))"} -doc_end -doc_begin="To avoid compromising readability, the macros alternative_(v)?call[0-9] are allowed not to parenthesize their arguments." --config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^alternative_(v)?call[0-9]$))))"} +-config=MC3A2.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^alternative_(v)?call[0-9]$))))"} -doc_end -doc_begin="The argument 'x' of the count_args_ macro can't be parenthesized as the rule would require, without breaking the functionality of the macro. The uses of this macro do not lead to developer confusion, and can thus be deviated." --config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^count_args_$))))"} +-config=MC3A2.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^count_args_$))))"} -doc_end -doc_begin="The argument \"fn\" in macros {COMPILE,RUNTIME}_CHECK is not parenthesized on purpose, to be able to test function-like macros. Given the specialized and limited use of this macro, it is deemed ok to deviate them." --config=MC3R1.R20.7,reports+={deliberate, "any_area(any_loc(any_exp(macro(^(COMPILE_CHECK|RUNTIME_CHECK)$))))"} +-config=MC3A2.R20.7,reports+={deliberate, "any_area(any_loc(any_exp(macro(^(COMPILE_CHECK|RUNTIME_CHECK)$))))"} -doc_end -doc_begin="Problems related to operator precedence can not occur if the expansion of the macro argument is surrounded by tokens '{', '}' and ';'." --config=MC3R1.R20.7,expansion_context+={safe, "left_right(^[\\{;]$,^[;\\}]$)"} +-config=MC3A2.R20.7,expansion_context+={safe, "left_right(^[\\{;]$,^[;\\}]$)"} -doc_end -doc_begin="Uses of variadic macros that have one of their arguments defined as a macro and used within the body for both ordinary parameter expansion and as an operand to the # or ## operators have a behavior that is well-understood and deliberate." --config=MC3R1.R20.12,macros+={deliberate, "variadic()"} +-config=MC3A2.R20.12,macros+={deliberate, "variadic()"} -doc_end -doc_begin="Uses of a macro parameter for ordinary expansion and as an operand to the # or ## operators within the following macros are deliberate, to provide useful diagnostic messages to the user." --config=MC3R1.R20.12,macros+={deliberate, "name(ASSERT||BUILD_BUG_ON||BUILD_BUG_ON_ZERO||RUNTIME_CHECK)"} +-config=MC3A2.R20.12,macros+={deliberate, "name(ASSERT||BUILD_BUG_ON||BUILD_BUG_ON_ZERO||RUNTIME_CHECK)"} -doc_end -doc_begin="The helper macro GENERATE_CASE may use a macro parameter for ordinary expansion and token pasting to improve readability. Only instances where this leads to a violation of the Rule are deviated." -file_tag+={deliberate_generate_case, "^xen/arch/arm/vcpreg\\.c$"} --config=MC3R1.R20.12,macros+={deliberate, "name(GENERATE_CASE)&&loc(file(deliberate_generate_case))"} +-config=MC3A2.R20.12,macros+={deliberate, "name(GENERATE_CASE)&&loc(file(deliberate_generate_case))"} -doc_end -doc_begin="The macro DEFINE is defined and used in excluded files asm-offsets.c. This may still cause violations if entities outside these files are referred to in the expansion." --config=MC3R1.R20.12,macros+={deliberate, "name(DEFINE)&&loc(file(asm_offsets))"} +-config=MC3A2.R20.12,macros+={deliberate, "name(DEFINE)&&loc(file(asm_offsets))"} -doc_end # @@ -636,7 +636,7 @@ in the expansion." -doc_begin="or, and and xor are reserved identifiers because they constitute alternate spellings for the corresponding operators (they are defined as macros by iso646.h). However, Xen doesn't use standard library headers, so there is no risk of overlap." --config=MC3R1.R21.2,reports+={safe, "any_area(stmt(ref(kind(label)&&^(or|and|xor|not)$)))"} +-config=MC3A2.R21.2,reports+={safe, "any_area(stmt(ref(kind(label)&&^(or|and|xor|not)$)))"} -doc_end -doc_begin="Xen does not use the functions provided by the Standard Library, but @@ -645,8 +645,8 @@ The implementation of these functions is available in source form, so the undefi or implementation-defined behaviors contemplated by the C Standard do not apply. If some undefined or unspecified behavior does arise in the implementation, it falls under the jurisdiction of other MISRA rules." --config=MC3R1.R21.9,reports+={deliberate, "any()"} --config=MC3R1.R21.10,reports+={deliberate, "any()"} +-config=MC3A2.R21.9,reports+={deliberate, "any()"} +-config=MC3A2.R21.10,reports+={deliberate, "any()"} -doc_end # @@ -671,7 +671,7 @@ falls under the jurisdiction of other MISRA rules." programmers:no developers' confusion is not possible. In addition, adopted code is assumed to work as is. Reports that are fully contained in adopted code are hidden/tagged with the 'adopted' tag." --service_selector={developer_confusion_guidelines,"^(MC3R1\\.R2\\.1|MC3R1\\.R2\\.2|MC3R1\\.R2\\.3|MC3R1\\.R2\\.4|MC3R1\\.R2\\.5|MC3R1\\.R2\\.6|MC3R1\\.R2\\.7|MC3R1\\.R4\\.1|MC3R1\\.R5\\.3|MC3R1\\.R5\\.6|MC3R1\\.R5\\.7|MC3R1\\.R5\\.8|MC3R1\\.R5\\.9|MC3R1\\.R7\\.1|MC3R1\\.R7\\.2|MC3R1\\.R7\\.3|MC3R1\\.R8\\.7|MC3R1\\.R8\\.8|MC3R1\\.R8\\.9|MC3R1\\.R8\\.11|MC3R1\\.R8\\.12|MC3R1\\.R8\\.13|MC3R1\\.R9\\.3|MC3R1\\.R9\\.4|MC3R1\\.R9\\.5|MC3R1\\.R10\\.2|MC3R1\\.R10\\.5|MC3R1\\.R10\\.6|MC3R1\\.R10\\.7|MC3R1\\.R10\\.8|MC3R1\\.R11\\.9|MC3R1\\.R12\\.1|MC3R1\\.R12\\.3|MC3R1\\.R12\\.4|MC3R1\\.R13\\.5|MC3R1\\.R14\\.1|MC3R1\\.R14\\.2|MC3R1\\.R14\\.3|MC3R1\\.R15\\.1|MC3R1\\.R15\\.2|MC3R1\\.R15\\.3|MC3R1\\.R15\\.4|MC3R1\\.R15\\.5|MC3R1\\.R15\\.6|MC3R1\\.R15\\.7|MC3R1\\.R16\\.1|MC3R1\\.R16\\.2|MC3R1\\.R16\\.3|MC3R1\\.R16\\.4|MC3R1\\.R16\\.5|MC3R1\\.R16\\.6|MC3R1\\.R16\\.7|MC3R1\\.R17\\.7|MC3R1\\.R17\\.8|MC3R1\\.R18\\.4|MC3R1\\.R18\\.5)$" +-service_selector={developer_confusion_guidelines,"^(MC3A2\\.R2\\.1|MC3A2\\.R2\\.2|MC3A2\\.R2\\.3|MC3A2\\.R2\\.4|MC3A2\\.R2\\.5|MC3A2\\.R2\\.6|MC3A2\\.R2\\.7|MC3A2\\.R4\\.1|MC3A2\\.R5\\.3|MC3A2\\.R5\\.6|MC3A2\\.R5\\.7|MC3A2\\.R5\\.8|MC3A2\\.R5\\.9|MC3A2\\.R7\\.1|MC3A2\\.R7\\.2|MC3A2\\.R7\\.3|MC3A2\\.R8\\.7|MC3A2\\.R8\\.8|MC3A2\\.R8\\.9|MC3A2\\.R8\\.11|MC3A2\\.R8\\.12|MC3A2\\.R8\\.13|MC3A2\\.R9\\.3|MC3A2\\.R9\\.4|MC3A2\\.R9\\.5|MC3A2\\.R10\\.2|MC3A2\\.R10\\.5|MC3A2\\.R10\\.6|MC3A2\\.R10\\.7|MC3A2\\.R10\\.8|MC3A2\\.R11\\.9|MC3A2\\.R12\\.1|MC3A2\\.R12\\.3|MC3A2\\.R12\\.4|MC3A2\\.R13\\.5|MC3A2\\.R14\\.1|MC3A2\\.R14\\.2|MC3A2\\.R14\\.3|MC3A2\\.R15\\.1|MC3A2\\.R15\\.2|MC3A2\\.R15\\.3|MC3A2\\.R15\\.4|MC3A2\\.R15\\.5|MC3A2\\.R15\\.6|MC3A2\\.R15\\.7|MC3A2\\.R16\\.1|MC3A2\\.R16\\.2|MC3A2\\.R16\\.3|MC3A2\\.R16\\.4|MC3A2\\.R16\\.5|MC3A2\\.R16\\.6|MC3A2\\.R16\\.7|MC3A2\\.R17\\.7|MC3A2\\.R17\\.8|MC3A2\\.R18\\.4|MC3A2\\.R18\\.5)$" } -config=developer_confusion_guidelines,reports+={relied,adopted_report} -doc_end diff --git a/automation/eclair_analysis/ECLAIR/monitored.ecl b/automation/eclair_analysis/ECLAIR/monitored.ecl index 4e1deef7a7..8351996ec8 100644 --- a/automation/eclair_analysis/ECLAIR/monitored.ecl +++ b/automation/eclair_analysis/ECLAIR/monitored.ecl @@ -1,106 +1,106 @@ -doc_begin="A set of guidelines that are clean or that only have few violations left." --enable=MC3R1.D1.1 --enable=MC3R1.D2.1 --enable=MC3R1.D4.1 --enable=MC3R1.D4.3 --enable=MC3R1.D4.7 --enable=MC3R1.D4.10 --enable=MC3R1.D4.11 --enable=MC3R1.D4.14 --enable=MC3R1.R1.1 --enable=MC3R1.R1.3 --enable=MC3R1.R1.4 --enable=MC3R1.R2.1 --enable=MC3R1.R2.6 --enable=MC3R1.R3.1 --enable=MC3R1.R3.2 --enable=MC3R1.R4.1 --enable=MC3R1.R4.2 --enable=MC3R1.R5.1 --enable=MC3R1.R5.2 --enable=MC3R1.R5.3 --enable=MC3R1.R5.4 --enable=MC3R1.R5.5 --enable=MC3R1.R5.6 --enable=MC3R1.R6.1 --enable=MC3R1.R6.2 --enable=MC3R1.R7.1 --enable=MC3R1.R7.2 --enable=MC3R1.R7.3 --enable=MC3R1.R7.4 --enable=MC3R1.R8.1 --enable=MC3R1.R8.2 --enable=MC3R1.R8.3 --enable=MC3R1.R8.4 --enable=MC3R1.R8.5 --enable=MC3R1.R8.6 --enable=MC3R1.R8.8 --enable=MC3R1.R8.10 --enable=MC3R1.R8.12 --enable=MC3R1.R8.14 --enable=MC3R1.R9.2 --enable=MC3R1.R9.3 --enable=MC3R1.R9.4 --enable=MC3R1.R10.1 --enable=MC3R1.R10.2 --enable=MC3R1.R11.1 --enable=MC3R1.R11.2 --enable=MC3R1.R11.7 --enable=MC3R1.R11.8 --enable=MC3R1.R11.9 --enable=MC3R1.R12.5 --enable=MC3R1.R13.1 --enable=MC3R1.R13.2 --enable=MC3R1.R13.6 --enable=MC3R1.R14.1 --enable=MC3R1.R14.4 --enable=MC3R1.R16.2 --enable=MC3R1.R16.3 --enable=MC3R1.R16.4 --enable=MC3R1.R16.6 --enable=MC3R1.R16.7 --enable=MC3R1.R17.1 --enable=MC3R1.R17.3 --enable=MC3R1.R17.4 --enable=MC3R1.R17.5 --enable=MC3R1.R17.6 --enable=MC3R1.R18.1 --enable=MC3R1.R18.2 --enable=MC3R1.R18.6 --enable=MC3R1.R18.8 --enable=MC3R1.R19.1 --enable=MC3R1.R20.2 --enable=MC3R1.R20.3 --enable=MC3R1.R20.4 --enable=MC3R1.R20.6 --enable=MC3R1.R20.7 --enable=MC3R1.R20.9 --enable=MC3R1.R20.11 --enable=MC3R1.R20.12 --enable=MC3R1.R20.13 --enable=MC3R1.R20.14 --enable=MC3R1.R21.3 --enable=MC3R1.R21.4 --enable=MC3R1.R21.5 --enable=MC3R1.R21.7 --enable=MC3R1.R21.8 --enable=MC3R1.R21.9 --enable=MC3R1.R21.10 --enable=MC3R1.R21.12 --enable=MC3R1.R21.13 --enable=MC3R1.R21.17 --enable=MC3R1.R21.18 --enable=MC3R1.R21.19 --enable=MC3R1.R21.20 --enable=MC3R1.R21.21 --enable=MC3R1.R22.1 --enable=MC3R1.R22.2 --enable=MC3R1.R22.3 --enable=MC3R1.R22.4 --enable=MC3R1.R22.5 --enable=MC3R1.R22.6 --enable=MC3R1.R22.7 --enable=MC3R1.R22.8 --enable=MC3R1.R22.9 --enable=MC3R1.R22.10 +-enable=MC3A2.D1.1 +-enable=MC3A2.D2.1 +-enable=MC3A2.D4.1 +-enable=MC3A2.D4.3 +-enable=MC3A2.D4.7 +-enable=MC3A2.D4.10 +-enable=MC3A2.D4.11 +-enable=MC3A2.D4.14 +-enable=MC3A2.R1.1 +-enable=MC3A2.R1.3 +-enable=MC3A2.R1.4 +-enable=MC3A2.R2.1 +-enable=MC3A2.R2.6 +-enable=MC3A2.R3.1 +-enable=MC3A2.R3.2 +-enable=MC3A2.R4.1 +-enable=MC3A2.R4.2 +-enable=MC3A2.R5.1 +-enable=MC3A2.R5.2 +-enable=MC3A2.R5.3 +-enable=MC3A2.R5.4 +-enable=MC3A2.R5.5 +-enable=MC3A2.R5.6 +-enable=MC3A2.R6.1 +-enable=MC3A2.R6.2 +-enable=MC3A2.R7.1 +-enable=MC3A2.R7.2 +-enable=MC3A2.R7.3 +-enable=MC3A2.R7.4 +-enable=MC3A2.R8.1 +-enable=MC3A2.R8.2 +-enable=MC3A2.R8.3 +-enable=MC3A2.R8.4 +-enable=MC3A2.R8.5 +-enable=MC3A2.R8.6 +-enable=MC3A2.R8.8 +-enable=MC3A2.R8.10 +-enable=MC3A2.R8.12 +-enable=MC3A2.R8.14 +-enable=MC3A2.R9.2 +-enable=MC3A2.R9.3 +-enable=MC3A2.R9.4 +-enable=MC3A2.R10.1 +-enable=MC3A2.R10.2 +-enable=MC3A2.R11.1 +-enable=MC3A2.R11.2 +-enable=MC3A2.R11.7 +-enable=MC3A2.R11.8 +-enable=MC3A2.R11.9 +-enable=MC3A2.R12.5 +-enable=MC3A2.R13.1 +-enable=MC3A2.R13.2 +-enable=MC3A2.R13.6 +-enable=MC3A2.R14.1 +-enable=MC3A2.R14.4 +-enable=MC3A2.R16.2 +-enable=MC3A2.R16.3 +-enable=MC3A2.R16.4 +-enable=MC3A2.R16.6 +-enable=MC3A2.R16.7 +-enable=MC3A2.R17.1 +-enable=MC3A2.R17.3 +-enable=MC3A2.R17.4 +-enable=MC3A2.R17.5 +-enable=MC3A2.R17.6 +-enable=MC3A2.R18.1 +-enable=MC3A2.R18.2 +-enable=MC3A2.R18.6 +-enable=MC3A2.R18.8 +-enable=MC3A2.R19.1 +-enable=MC3A2.R20.2 +-enable=MC3A2.R20.3 +-enable=MC3A2.R20.4 +-enable=MC3A2.R20.6 +-enable=MC3A2.R20.7 +-enable=MC3A2.R20.9 +-enable=MC3A2.R20.11 +-enable=MC3A2.R20.12 +-enable=MC3A2.R20.13 +-enable=MC3A2.R20.14 +-enable=MC3A2.R21.3 +-enable=MC3A2.R21.4 +-enable=MC3A2.R21.5 +-enable=MC3A2.R21.7 +-enable=MC3A2.R21.8 +-enable=MC3A2.R21.9 +-enable=MC3A2.R21.10 +-enable=MC3A2.R21.12 +-enable=MC3A2.R21.13 +-enable=MC3A2.R21.17 +-enable=MC3A2.R21.18 +-enable=MC3A2.R21.19 +-enable=MC3A2.R21.20 +-enable=MC3A2.R21.21 +-enable=MC3A2.R22.1 +-enable=MC3A2.R22.2 +-enable=MC3A2.R22.3 +-enable=MC3A2.R22.4 +-enable=MC3A2.R22.5 +-enable=MC3A2.R22.6 +-enable=MC3A2.R22.7 +-enable=MC3A2.R22.8 +-enable=MC3A2.R22.9 +-enable=MC3A2.R22.10 -doc_end diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl index 755ea3271f..b524318591 100644 --- a/automation/eclair_analysis/ECLAIR/tagging.ecl +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl @@ -20,93 +20,93 @@ -doc_begin="Clean guidelines: new violations for these guidelines are not accepted." -service_selector={clean_guidelines_common, -"MC3R1.D1.1|| -MC3R1.D2.1|| -MC3R1.D4.1|| -MC3R1.D4.11|| -MC3R1.D4.14|| -MC3R1.R1.1|| -MC3R1.R1.3|| -MC3R1.R1.4|| -MC3R1.R2.6|| -MC3R1.R3.1|| -MC3R1.R3.2|| -MC3R1.R4.1|| -MC3R1.R4.2|| -MC3R1.R5.1|| -MC3R1.R5.2|| -MC3R1.R5.3|| -MC3R1.R5.4|| -MC3R1.R5.6|| -MC3R1.R6.1|| -MC3R1.R6.2|| -MC3R1.R7.1|| -MC3R1.R7.2|| -MC3R1.R7.3|| -MC3R1.R7.4|| -MC3R1.R8.1|| -MC3R1.R8.2|| -MC3R1.R8.3|| -MC3R1.R8.4|| -MC3R1.R8.5|| -MC3R1.R8.6|| -MC3R1.R8.8|| -MC3R1.R8.10|| -MC3R1.R8.12|| -MC3R1.R8.14|| -MC3R1.R9.2|| -MC3R1.R9.3|| -MC3R1.R9.4|| -MC3R1.R10.2|| -MC3R1.R11.6|| -MC3R1.R11.7|| -MC3R1.R11.9|| -MC3R1.R12.5|| -MC3R1.R13.6|| -MC3R1.R14.1|| -MC3R1.R14.3|| -MC3R1.R14.4|| -MC3R1.R16.2|| -MC3R1.R16.3|| -MC3R1.R16.7|| -MC3R1.R17.1|| -MC3R1.R17.3|| -MC3R1.R17.4|| -MC3R1.R17.5|| -MC3R1.R17.6|| -MC3R1.R18.6|| -MC3R1.R18.8|| -MC3R1.R20.2|| -MC3R1.R20.3|| -MC3R1.R20.4|| -MC3R1.R20.6|| -MC3R1.R20.9|| -MC3R1.R20.11|| -MC3R1.R20.12|| -MC3R1.R20.13|| -MC3R1.R20.14|| -MC3R1.R21.3|| -MC3R1.R21.4|| -MC3R1.R21.5|| -MC3R1.R21.7|| -MC3R1.R21.8|| -MC3R1.R21.9|| -MC3R1.R21.10|| -MC3R1.R21.11|| -MC3R1.R21.12|| -MC3R1.R21.13|| -MC3R1.R21.19|| -MC3R1.R21.21|| -MC3R1.R22.1|| -MC3R1.R22.2|| -MC3R1.R22.3|| -MC3R1.R22.4|| -MC3R1.R22.5|| -MC3R1.R22.6|| -MC3R1.R22.7|| -MC3R1.R22.8|| -MC3R1.R22.9|| -MC3R1.R22.10" +"MC3A2.D1.1|| +MC3A2.D2.1|| +MC3A2.D4.1|| +MC3A2.D4.11|| +MC3A2.D4.14|| +MC3A2.R1.1|| +MC3A2.R1.3|| +MC3A2.R1.4|| +MC3A2.R2.6|| +MC3A2.R3.1|| +MC3A2.R3.2|| +MC3A2.R4.1|| +MC3A2.R4.2|| +MC3A2.R5.1|| +MC3A2.R5.2|| +MC3A2.R5.3|| +MC3A2.R5.4|| +MC3A2.R5.6|| +MC3A2.R6.1|| +MC3A2.R6.2|| +MC3A2.R7.1|| +MC3A2.R7.2|| +MC3A2.R7.3|| +MC3A2.R7.4|| +MC3A2.R8.1|| +MC3A2.R8.2|| +MC3A2.R8.3|| +MC3A2.R8.4|| +MC3A2.R8.5|| +MC3A2.R8.6|| +MC3A2.R8.8|| +MC3A2.R8.10|| +MC3A2.R8.12|| +MC3A2.R8.14|| +MC3A2.R9.2|| +MC3A2.R9.3|| +MC3A2.R9.4|| +MC3A2.R10.2|| +MC3A2.R11.6|| +MC3A2.R11.7|| +MC3A2.R11.9|| +MC3A2.R12.5|| +MC3A2.R13.6|| +MC3A2.R14.1|| +MC3A2.R14.3|| +MC3A2.R14.4|| +MC3A2.R16.2|| +MC3A2.R16.3|| +MC3A2.R16.7|| +MC3A2.R17.1|| +MC3A2.R17.3|| +MC3A2.R17.4|| +MC3A2.R17.5|| +MC3A2.R17.6|| +MC3A2.R18.6|| +MC3A2.R18.8|| +MC3A2.R20.2|| +MC3A2.R20.3|| +MC3A2.R20.4|| +MC3A2.R20.6|| +MC3A2.R20.9|| +MC3A2.R20.11|| +MC3A2.R20.12|| +MC3A2.R20.13|| +MC3A2.R20.14|| +MC3A2.R21.3|| +MC3A2.R21.4|| +MC3A2.R21.5|| +MC3A2.R21.7|| +MC3A2.R21.8|| +MC3A2.R21.9|| +MC3A2.R21.10|| +MC3A2.R21.11|| +MC3A2.R21.12|| +MC3A2.R21.13|| +MC3A2.R21.19|| +MC3A2.R21.21|| +MC3A2.R22.1|| +MC3A2.R22.2|| +MC3A2.R22.3|| +MC3A2.R22.4|| +MC3A2.R22.5|| +MC3A2.R22.6|| +MC3A2.R22.7|| +MC3A2.R22.8|| +MC3A2.R22.9|| +MC3A2.R22.10" } -setq=target,getenv("XEN_TARGET_ARCH") @@ -116,7 +116,7 @@ if(string_equal(target,"x86_64"), ) if(string_equal(target,"arm64"), - service_selector({"additional_clean_guidelines","MC3R1.R2.1||MC3R1.R5.3||MC3.R11.2||MC3R1.R16.6||MC3R1.R20.7"}) + service_selector({"additional_clean_guidelines","MC3A2.R2.1||MC3A2.R5.3||MC3.R11.2||MC3A2.R16.6||MC3A2.R20.7"}) ) -reports+={clean:added,"service(clean_guidelines_common||additional_clean_guidelines)"} diff --git a/docs/misra/documenting-violations.rst b/docs/misra/documenting-violations.rst index 8f1cbd83b8..d26377d5aa 100644 --- a/docs/misra/documenting-violations.rst +++ b/docs/misra/documenting-violations.rst @@ -53,7 +53,7 @@ Here is an example to add a new justification in safe.json:: | "analyser": { | "cppcheck": "misra-c2012-20.7", | "coverity": "misra_c_2012_rule_20_7_violation", -| "eclair": "MC3R1.R20.7" +| "eclair": "MC3A2.R20.7" | }, | "name": "R20.7 C macro parameters not used as expression", | "text": "The macro parameters used in this [...]" @@ -138,7 +138,7 @@ for the Rule 8.6: Eclair reports it in its web report, file xen/include/xen/kernel.h, line 68: -| MC3R1.R8.6 for program 'xen/xen-syms', variable '_start' has no definition +| MC3A2.R8.6 for program 'xen/xen-syms', variable '_start' has no definition Also coverity reports it, here is an extract of the finding: @@ -165,7 +165,7 @@ We will prepare our entry in the safe.json database:: | { | "id": "SAF-1-safe", | "analyser": { -| "eclair": "MC3R1.R8.6", +| "eclair": "MC3A2.R8.6", | "coverity": "misra_c_2012_rule_8_6_violation" | }, | "name": "Rule 8.6: linker script defined symbols", diff --git a/docs/misra/safe.json b/docs/misra/safe.json index 684346386e..b8a4f878ea 100644 --- a/docs/misra/safe.json +++ b/docs/misra/safe.json @@ -4,7 +4,7 @@ { "id": "SAF-0-safe", "analyser": { - "eclair": "MC3R1.R8.6", + "eclair": "MC3A2.R8.6", "coverity": "misra_c_2012_rule_8_6_violation" }, "name": "Rule 8.6: linker script defined symbols", @@ -13,7 +13,7 @@ { "id": "SAF-1-safe", "analyser": { - "eclair": "MC3R1.R8.4" + "eclair": "MC3A2.R8.4" }, "name": "Rule 8.4: asm-only definition", "text": "Functions and variables used only by asm modules do not need to have a visible declaration prior to their definition." @@ -21,23 +21,23 @@ { "id": "SAF-2-safe", "analyser": { - "eclair": "MC3R1.R10.1" + "eclair": "MC3A2.R10.1" }, - "name": "MC3R1.R10.1: use of an enumeration constant in an arithmetic operation", + "name": "MC3A2.R10.1: use of an enumeration constant in an arithmetic operation", "text": "This violation can be fixed with a cast to (int) of the enumeration constant, but a deviation was chosen due to code readability (see also the comment in BITS_TO_LONGS)." }, { "id": "SAF-3-safe", "analyser": { - "eclair": "MC3R1.R20.4" + "eclair": "MC3A2.R20.4" }, - "name": "MC3R1.R20.4: allow the definition of a macro with the same name as a keyword in some special cases", + "name": "MC3A2.R20.4: allow the definition of a macro with the same name as a keyword in some special cases", "text": "The definition of a macro with the same name as a keyword can be useful in certain configurations to improve the guarantees that can be provided by Xen. See docs/misra/deviations.rst for a precise rationale for all such cases." }, { "id": "SAF-4-safe", "analyser": { - "eclair": "MC3R1.R17.1" + "eclair": "MC3A2.R17.1" }, "name": "Rule 17.1: internal helper functions made to break long running hypercalls into multiple calls.", "text": "They need to take a variable number of arguments depending on the original hypercall they are trying to continue." @@ -45,31 +45,31 @@ { "id": "SAF-5-safe", "analyser": { - "eclair": "MC3R1.R16.2" + "eclair": "MC3A2.R16.2" }, - "name": "MC3R1.R16.2: using a case label when the most closely-enclosing compound statement is not a switch statement", + "name": "MC3A2.R16.2: using a case label when the most closely-enclosing compound statement is not a switch statement", "text": "A switch label enclosed by some compound statement that is not the body of a switch is permitted within local helper macros that are unlikely to be misused or misunderstood." }, { "id": "SAF-6-safe", "analyser": { - "eclair": "MC3R1.R20.12" + "eclair": "MC3A2.R20.12" }, - "name": "MC3R1.R20.12: use of a macro argument that deliberately violates the Rule", + "name": "MC3A2.R20.12: use of a macro argument that deliberately violates the Rule", "text": "A macro parameter that is itself a macro is intentionally used within the macro both as a regular parameter and for text replacement." }, { "id": "SAF-7-safe", "analyser": { - "eclair": "MC3R1.R20.7" + "eclair": "MC3A2.R20.7" }, - "name": "MC3R1.R20.7: deliberately non-parenthesized macro argument", + "name": "MC3A2.R20.7: deliberately non-parenthesized macro argument", "text": "A macro parameter expands to an expression that is non-parenthesized, as doing so would break the functionality." }, { "id": "SAF-8-safe", "analyser": { - "eclair": "MC3R1.D4.10" + "eclair": "MC3A2.D4.10" }, "name": "Dir 4.10: headers that leave it up to the caller to include them correctly", "text": "Headers that deliberatively leave the responsability of their correct inclusion to the caller are allowed." @@ -77,7 +77,7 @@ { "id": "SAF-9-safe", "analyser": { - "eclair": "MC3R1.D4.10" + "eclair": "MC3A2.D4.10" }, "name": "Dir 4.10: empty headers", "text": "Empty headers pose no risk if included more than once." @@ -85,7 +85,7 @@ { "id": "SAF-10-safe", "analyser": { - "eclair": "MC3R1.D4.10" + "eclair": "MC3A2.D4.10" }, "name": "Dir 4.10: direct inclusion guard before", "text": "Headers with just the direct inclusion guard before the inclusion guard are safe." -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Dec 10 10:38:31 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Dec 2024 10:38:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.852046.1265966 (Exim 4.92) (envelope-from ) id 1tKxdP-0002Ii-Fv; Tue, 10 Dec 2024 10:38:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 852046.1265966; Tue, 10 Dec 2024 10:38: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 1tKxdP-0002Ib-DB; Tue, 10 Dec 2024 10:38:31 +0000 Received: by outflank-mailman (input) for mailman id 852046; Tue, 10 Dec 2024 10:38: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 1tKxdO-00022t-If for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 10:38:30 +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 e4b6c95e-b6e2-11ef-99a3-01e77a169b0f; Tue, 10 Dec 2024 11:38:28 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-432d86a3085so35614645e9.2 for ; Tue, 10 Dec 2024 02:38:29 -0800 (PST) Received: from ?IPV6:2003:ca:b746:63c:3d8c:c505:78ea:f982? (p200300cab746063c3d8cc50578eaf982.dip0.t-ipconnect.de. [2003:ca:b746:63c:3d8c:c505:78ea:f982]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-434fb9bf04esm52959495e9.26.2024.12.10.02.38.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Dec 2024 02:38: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: e4b6c95e-b6e2-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733827108; x=1734431908; 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=OcNfAuYKkkJ781yY56TSb+Ua7bh73KAS+xQSN/RbB1g=; b=dL6TFSYOpE6nPxoK/RmkYRLF/pjYelXyjj9hkypCsWpD0YVfF4BX7DOE9tnPC2q2DG f2JtBmccOIdkQO+XzcBRRxTcVr5tJtOz6PC9YNNWmghZJxMzvaFMyjPjD/APnmeFqBrJ YuG1qgQzYqnV7O5paQ1pZC3aFZg8b6Pd/VYMBg/SA5DGjyRLDRMUn9rlYdeCiG7SAaDn J6yeCnjCT+jMtV9r7lOXiyqR6MGIz1vhU9um1OBAddsJ6OAZPJBev3QGJV72BsXPq7yA zSqC3w7RscEM3onWG09t9Ijvfg4oj6x/Cfd3N4OkfXGH/S9cPgnCFt8TSoMCT981PMIY VAWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733827108; x=1734431908; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=OcNfAuYKkkJ781yY56TSb+Ua7bh73KAS+xQSN/RbB1g=; b=Lt1eb/zdmpHLbN+6DhgNPOUQq798Uc/XQEuQK27UAQCwlvJy3KovQHNbDM+MfW0ghE zsZSi9oX2cKb6SIurFOrbN4PSDVInxS5c/2ryL9UJBRl8ONw1hRMDkah2fBzwH/Besey 4epyAddhmy4h8TxW/dojhfkkV41n1D5VDKqxUnXHS+zvpq3yqaKFO8G734d7k7gwCWDM imcoZV39O7cboskoZj9/dR0NhF0dLUUZHnYleDh4p2V4bA8YTvq8u5RAWlq/l4nh8kUu HGbZqYOkR/VRV/mTUZYG15D1D6I7CMq3HsAH36wrwv5tTf2TjHT9vISw4qW9zUZgnUgv bzZA== X-Forwarded-Encrypted: i=1; AJvYcCUxylW9SrCcueSkG/opCOFv9b0i2YYZUftQwgFJ1Z8BVeBvD56FUVi4G+AjZeH05TBbmmNvN2SVMEI=@lists.xenproject.org X-Gm-Message-State: AOJu0YyRx7mZZ2y77Qbyq/6zGsbShJPVZxw/XKAybIZ7Q0BizsEQAw1d vPwiaM+3yCBNXT1uwTbV+pMAc+SFY53QfXm6W5REu2Mx87kInrQqSiwMvamYuAqPaQfCOpt0ekY = X-Gm-Gg: ASbGncu1UoSRWfgXNEn3Vh6J2p8IOpcyUfTH4RLhX39oIXCsmcbREbJAcaWXcvk75gC XGwf9n2MEnWazBdWxjFQ6XWxwvpXNqnL0T/VBOGAQATRmyH5sUSQwyiG+2ygRVPPxo7lOJ82Pnq q+Fq1UG/fJDS60r6vC64i1NtE5Uum93+kV7+h8gnyeYkF8t8CnwdRN2zUWhliFxi+ZBXUJZB2a9 LJl1fj+MBtRorWcPEz9+n2398P/cGr4vy3qjO7AZzCW7C1MQdhBXTxyhsNwCqI3RS7ZmYb8NyP0 wLEYMcH1zQVp/gyDUwDXNiyA8KHF5FhI1sjm1QbbLh+2xj9mBQ/alirdXkkaPVbUCm0toDJsP+6 EZdS5+tu6wQ== X-Google-Smtp-Source: AGHT+IHb1waYUOD+i+h023do9krN08k5i7QI04vnesyxgIZpfZIwnQsjaIjo+W1Wb1e7mmu0YWs8Mw== X-Received: by 2002:a05:600c:1e87:b0:434:e9ee:c1e with SMTP id 5b1f17b1804b1-434fffc6caamr37350475e9.31.1733827108359; Tue, 10 Dec 2024 02:38:28 -0800 (PST) Message-ID: Date: Tue, 10 Dec 2024 11:38:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/4] x86/boot: Move some settings to C To: Frediano Ziglio Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241122093358.478774-1-frediano.ziglio@cloud.com> <20241122093358.478774-4-frediano.ziglio@cloud.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: <20241122093358.478774-4-frediano.ziglio@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22.11.2024 10:33, Frediano Ziglio wrote: > Initialise multiboot_ptr and pvh_start_info_pa from C code. > > Signed-off-by: Frediano Ziglio > --- > xen/arch/x86/boot/build32.lds.S | 3 +++ > xen/arch/x86/boot/head.S | 10 -------- > xen/arch/x86/boot/reloc.c | 28 ++++++++++++++++++----- > xen/arch/x86/include/asm/guest/pvh-boot.h | 1 + > 4 files changed, 26 insertions(+), 16 deletions(-) >From the diffstat alone - is this really a win? > --- a/xen/arch/x86/boot/head.S > +++ b/xen/arch/x86/boot/head.S > @@ -517,16 +517,6 @@ trampoline_setup: > /* reloc(magic/eax, info/edx) using fastcall. */ > call reloc > > -#ifdef CONFIG_PVH_GUEST > - cmpb $0, sym_esi(pvh_boot) > - je 1f > - mov %eax, sym_esi(pvh_start_info_pa) > - jmp 2f > -#endif > -1: > - mov %eax, sym_esi(multiboot_ptr) > -2: > - > /* Interrogate CPU extended features via CPUID. */ > mov $1, %eax > cpuid > --- a/xen/arch/x86/boot/reloc.c > +++ b/xen/arch/x86/boot/reloc.c > @@ -17,13 +17,15 @@ > #include > > #include > -#include > #include > #include > +#include > > #include > +#include > > #include > +#include > > #ifdef CONFIG_VIDEO > # include "video.h" > @@ -347,27 +349,41 @@ static multiboot_info_t *mbi2_reloc(uint32_t mbi_in, memctx *ctx) > } > > /* SAF-1-safe */ > -void *reloc(uint32_t magic, uint32_t in) > +void reloc(uint32_t magic, uint32_t in) > { > memctx ctx = { trampoline_phys + TRAMPOLINE_HEAP_END }; > > + void *res; > + Nit: Please avoid blank lines between declarations unless the set of locals is huge, or some really need to stand out. > switch ( magic ) > { > case MULTIBOOT_BOOTLOADER_MAGIC: > - return mbi_reloc(in, &ctx); > + res = mbi_reloc(in, &ctx); > + break; > > case MULTIBOOT2_BOOTLOADER_MAGIC: > - return mbi2_reloc(in, &ctx); > + res = mbi2_reloc(in, &ctx); > + break; > > case XEN_HVM_START_MAGIC_VALUE: > if ( IS_ENABLED(CONFIG_PVH_GUEST) ) > - return pvh_info_reloc(in, &ctx); > + { > + res = pvh_info_reloc(in, &ctx); > + break; > + } > /* Fallthrough */ > > default: > /* Nothing we can do */ > - return NULL; > + res = NULL; Simply keep returning here? No need to write the NULL when the variables start out zeroed? > } > + > +#ifdef CONFIG_PVH_GUEST > + if ( pvh_boot ) > + pvh_start_info_pa = (unsigned long)res; > +#endif > + > + multiboot_ptr = (unsigned long)res; In the assembly original this is an "else" to the if(). Jan From xen-devel-bounces@lists.xenproject.org Tue Dec 10 10:49:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Dec 2024 10:49:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.852067.1265976 (Exim 4.92) (envelope-from ) id 1tKxoO-0004HW-GD; Tue, 10 Dec 2024 10:49:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 852067.1265976; Tue, 10 Dec 2024 10:49: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 1tKxoO-0004HP-D4; Tue, 10 Dec 2024 10:49:52 +0000 Received: by outflank-mailman (input) for mailman id 852067; Tue, 10 Dec 2024 10:49: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 1tKxoM-0004HJ-Sk for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 10:49: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 79ea0c1a-b6e4-11ef-99a3-01e77a169b0f; Tue, 10 Dec 2024 11:49:48 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-385de9f789cso4042682f8f.2 for ; Tue, 10 Dec 2024 02:49:48 -0800 (PST) Received: from ?IPV6:2003:ca:b746:63c:3d8c:c505:78ea:f982? (p200300cab746063c3d8cc50578eaf982.dip0.t-ipconnect.de. [2003:ca:b746:63c:3d8c:c505:78ea:f982]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-386408549b9sm5028734f8f.89.2024.12.10.02.49.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Dec 2024 02:49: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: 79ea0c1a-b6e4-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733827788; x=1734432588; 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=T1+JtpJhKjuJZC0M0gDGzIMy8kIn7FafaJ7/N9niL/4=; b=Byh2Jf9UR8r9bEssXxP1bBDhCRkhCd6d1GWV+iK0gNAGFAb6va6uGckoQj7Xgcn7+7 mRU3d5YVsEMAMzom499kDudX2QI+FSdW4Uo6NCquDmah4z+tl+aR6avmeK9tRstCe2pD YZlMgR4H3SKcRFyRP9vTOt3+qhHbT2lCSeS2fmSU6fRMseOjvDHIxX4zFZfc0PFPRSj7 tHzl9G4+GL5hqvC8yzlHn6BxgGIEWZX2mWCYEnMxu+myEQX5n2LdL4kqgHNXdftq758z DK2RAV/pRVNE8kk4I1FYnQYbEEwCneXPq9nfjPguHGO84VnQ2VqxZdaredC4HZVd8TMq bmZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733827788; x=1734432588; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=T1+JtpJhKjuJZC0M0gDGzIMy8kIn7FafaJ7/N9niL/4=; b=HVAe4/UYf1FfyHpKXCCwSFyVjeeVWRlc0M0v5Ns+xZZkYE9n5LHuh0l8EAnxlMlkuz TB2bh2qrwC2Xey3wukoPd+DsujBTwr1QlXjlJ60mwUXTiftSjTeGQbUmfU/r+LQI/OPA +EWgsKw/lA4wzZKMiG96ogdOVwMIjjxACu5ZTtQZ6cohhJMy+H7gQeAgKRMyPujxFoIp mjXfDRJtfBcMBWIBnUO+v6JXGgYXwBb6C91eJYEVpaNLKZYDq/lzMQfB1klUjrI0tnf0 xdbTLQ7D+hSp7M8Tx3Sm1u67LfHepeNeJFdtZDQBa9AuZ9t+xsihbXtGNQ0ZsS4/LUGM 4rCw== X-Forwarded-Encrypted: i=1; AJvYcCVCuDvcJyRvylNx2chJfrGZ0cRgDaBXwH50+plJZvnmMB8LK0xeikeUM1aqCfViBG5I9xP5I4Scn3c=@lists.xenproject.org X-Gm-Message-State: AOJu0YxN7oyoK1O8WVZj0wPWPs/6/tHqHszzn6wJCvJl7wrXoysgY0zH FELHZWSBTxCmIuQiFxJBi7fg90KFDrYSpAd1folVwhb4HetXP77bzXdpaF5O3w== X-Gm-Gg: ASbGncuC+qr06Q8DE5UZlwBW3ud1W8s2Xb6Qe6yu71p0toF0kFJmQEyhJWCzsBsJUQ0 qPdK8lDvlSVWHPYhavPPeDEmr/IifDJymg30nNpy5ekOrK3QNBr3f+fyH6te6NtOaA7kY76uTdF suagstFNYdPHqv/YerX0VE81LEJDr8Ljf/m9/Mzg+r3vapUCxlfKVevb3AYg0s3lij11Ikhnaz7 NDw/5eD+tSZoWCkzQOPXY2s02/IhZhoDcleJFGPJDIkoR0o3lBPBzRRAnbfAlVP4x8jmMz5YxrQ jfwYZRlo/ErYcOEFC5MG3vh+t2747D9/Q8etXF2sNF7g6KCdbGGZKI2UBzVUyrYs0R8+UJzKjCv xYKvYgWFayw== X-Google-Smtp-Source: AGHT+IH6BbkofEd6yAgOijFDW/kZuqjmE6GbsbnG1dpsH2I3LmNsZc9IjRK+xNQaFgQoivID+MlejQ== X-Received: by 2002:a05:6000:1446:b0:386:42a6:21f2 with SMTP id ffacd0b85a97d-38642a624f0mr3941528f8f.10.1733827786694; Tue, 10 Dec 2024 02:49:46 -0800 (PST) Message-ID: <0b990a3c-4803-4d18-a42f-bf9601e14ca1@suse.com> Date: Tue, 10 Dec 2024 11:49:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/4] x86/boot: Use external symbols from cmdline_parse_early To: Frediano Ziglio Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20241122093358.478774-1-frediano.ziglio@cloud.com> <20241122093358.478774-5-frediano.ziglio@cloud.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: <20241122093358.478774-5-frediano.ziglio@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22.11.2024 10:33, Frediano Ziglio wrote: > Move some assembly code to C. > > Signed-off-by: Frediano Ziglio > --- > xen/arch/x86/boot/build32.lds.S | 1 + > xen/arch/x86/boot/cmdline.c | 14 ++++++++++++-- > xen/arch/x86/boot/head.S | 9 +-------- > xen/arch/x86/boot/trampoline.S | 2 +- > xen/arch/x86/include/asm/setup.h | 2 ++ > xen/arch/x86/include/boot/xen/cpumask.h | 1 + > xen/arch/x86/include/boot/xen/string.h | 10 ++++++++++ > 7 files changed, 28 insertions(+), 11 deletions(-) > create mode 100644 xen/arch/x86/include/boot/xen/cpumask.h > create mode 100644 xen/arch/x86/include/boot/xen/string.h Again the diffstat doesn't really suggest this is a win. As an upside I can see that the argument passing to the function is somewhat ugly when done from assembly, especially when the function needs new parameters added or ones removed / changed. The downside is that now you're switching to dealing with globals, which generally seems less desirable. > --- a/xen/arch/x86/include/asm/setup.h > +++ b/xen/arch/x86/include/asm/setup.h > @@ -16,6 +16,8 @@ extern uint64_t boot_tsc_stamp; > extern void *stack_start; > extern unsigned int multiboot_ptr; > > +struct domain; > + > void early_cpu_init(bool verbose); > void early_time_init(void); > While I think I can see why this would be needed, personally I think such forward decls belong either immediately past all #include-s or immediately ahead of where they are first needed. > --- /dev/null > +++ b/xen/arch/x86/include/boot/xen/cpumask.h > @@ -0,0 +1 @@ > +/* Empty. */ Are there perhaps better ways to deal with whatever needs dealing with (which sadly isn't obvious and also isn't mentioned anywhere)? At a guess, asm/numa.h may be where the problem is, yet then setup.h includes that just to get a decl of nodeid_t afaics. As we're meaning to split headers into two or perhaps even three parts anyway (to allow reducing dependency chains), maybe we should do so here and introduce e.g. asm/types/numa.h? Jan From xen-devel-bounces@lists.xenproject.org Tue Dec 10 10:55:40 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Dec 2024 10:55:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.852082.1265987 (Exim 4.92) (envelope-from ) id 1tKxtv-000676-3Q; Tue, 10 Dec 2024 10:55:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 852082.1265987; Tue, 10 Dec 2024 10:55:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKxtu-00066z-Vg; Tue, 10 Dec 2024 10:55:34 +0000 Received: by outflank-mailman (input) for mailman id 852082; Tue, 10 Dec 2024 10:55: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 1tKxtt-00066r-1T for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 10:55:33 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 469137f3-b6e5-11ef-a0d5-8be0dac302b0; Tue, 10 Dec 2024 11:55:32 +0100 (CET) Received: from nico.bugseng.com (unknown [46.228.253.214]) by support.bugseng.com (Postfix) with ESMTPSA id 440BC4EE0738; Tue, 10 Dec 2024 11:55: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: 469137f3-b6e5-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail; t=1733828131; bh=u5yI1U7QpCEc+V1D8jZzLmbdJwaI+XFI2TgvkxNxhqI=; h=From:To:Cc:Subject:Date:From; b=Pty/NXKj9MrTQYz2nCS7fwAzCDxVsujkExwwPeo3xaNsu+NEfeRtdkGjU1z9K1ioh h2Ni5n7DOOGqevwySZY+gbV+hGH8qVNPoYbZSsGHEyXwM3PPOn6IzB8EWEirdw1O1T 9JGTsBjtLR39tjy49TabP01mm4gwYZrhVPgXjG40kM4rKtPjc+21xljgHSoh3p7FYD 8hJlPJ402lVTSiWv8CPbkXcQEaImFIsJkqyoe70sWRqxAsNP4DKvjfWgw+F8JU8WZS x/bv11b/2uoCu0WdL4e7nAAdNg992vRQEOI2b+w2Le6U6suMC5xS54gWErnZMrJM0b T8W8/VFIpekxg== From: Nicola Vetrini To: xen-devel@lists.xenproject.org Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, Nicola Vetrini , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [XEN PATCH v3] x86: p2m-pod: address violation of MISRA C Rule 2.1 Date: Tue, 10 Dec 2024 11:54:59 +0100 Message-ID: <05b5fd3a85d033adacd5aa08ca81ce579cb1a120.1733827766.git.nicola.vetrini@bugseng.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Rule 2.1 states: "A project shall not contain unreachable code". The placement of the loop after "out_unmap" can be moved earlier in order to avoid the unconditional return to be marked as a cause of unreachability for the loop, as this is a consequence of "__builtin_unreachable" being configured in ECLAIR as being deliberately unreachable, and therefore not reported as causing the code after the "out_unmap" label to be unreachable. Replacing one instance of "goto out_unmap" with the loop avoids considering the unconditional return at the end of the function as a cause of unreachability, while preserving the semantics of the function. No functional change intended. Signed-off-by: Nicola Vetrini --- Changes in v2: - rebased against current staging Changes in v3: - move the loop inside the if and avoid one goto --- xen/arch/x86/mm/p2m-pod.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c index bd84fe9e27ee..8b6f9909c5a1 100644 --- a/xen/arch/x86/mm/p2m-pod.c +++ b/xen/arch/x86/mm/p2m-pod.c @@ -1005,7 +1005,14 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count { ASSERT_UNREACHABLE(); domain_crash(d); - goto out_unmap; +out_unmap: + /* + * Something went wrong, probably crashing the domain. Unmap + * everything and return. + */ + for ( i = 0; i < count; i++ ) + if ( map[i] ) + unmap_domain_page(map[i]); } } else @@ -1032,17 +1039,6 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count ioreq_request_mapcache_invalidate(d); } } - - return; - -out_unmap: - /* - * Something went wrong, probably crashing the domain. Unmap - * everything and return. - */ - for ( i = 0; i < count; i++ ) - if ( map[i] ) - unmap_domain_page(map[i]); } static void -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Dec 10 11:00:59 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Dec 2024 11:00:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.852092.1265996 (Exim 4.92) (envelope-from ) id 1tKxz3-0007rr-Kw; Tue, 10 Dec 2024 11:00:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 852092.1265996; Tue, 10 Dec 2024 11:00: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 1tKxz3-0007rk-Hx; Tue, 10 Dec 2024 11:00:53 +0000 Received: by outflank-mailman (input) for mailman id 852092; Tue, 10 Dec 2024 11:00: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 1tKxz3-0007re-2J for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 11:00:53 +0000 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [2a00:1450:4864:20::635]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 052a6c1c-b6e6-11ef-a0d5-8be0dac302b0; Tue, 10 Dec 2024 12:00:51 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-aa6a3c42400so95649366b.0 for ; Tue, 10 Dec 2024 03:00:51 -0800 (PST) Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d3ecef4c07sm3922013a12.1.2024.12.10.03.00.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Dec 2024 03:00: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: 052a6c1c-b6e6-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1733828451; x=1734433251; 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=XEBeKYCCu64IPF0XgaOrtuu0z+8g7mPMzXrZeOCpmn4=; b=kzB/hzx6xS8IEgyLl3xHXZoEA/CMo0dYdPtZIoh7G0BM/yBr9kFJS5jvCcrRbU2EV3 EKRKqJQ8S3t9iO86YmlT/n92tar5WCXDVmWbGqNO7tugZOe8Ew4iqPphfJlOYgkXCjTP /P0vgp0nFL6FwK0gNkUu0fRRuvwTuiR8POVyg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733828451; x=1734433251; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XEBeKYCCu64IPF0XgaOrtuu0z+8g7mPMzXrZeOCpmn4=; b=mmdL3zMv8xJzVzahyrXZzfhm5JsGmQxGjYBNslpT9atioTwrnEpPpgmrgSdPcC7W1Q u0lh//j8PWUuxjGdkSjl5aXD7FLAVLSgWrlOODddbMcDayQNejBtIn/q3Bbws8DDLZDf X49XIvs/QrYB7CKIB3SS0VQxsptre3/NQ6ZQ1idp1qLMlQJ2qPm7C95DRUihoOhwL+ci rPyq3Cf8x4FzmhHcTEzS8Hg00oe3kRxHUCcBUTOg+eYzJkhYTbumAhALlX0lT2Mpcud8 3VcvwUJvBcSpedv+EznOcuwwCQmpyWWm5nKW2b/6S/hlYoDkORAcrByKEuNKVXZop8xA OAbA== X-Forwarded-Encrypted: i=1; AJvYcCWX/gf4X/cJcGpjKY7B20+OMutbRhMGH+efkgzawTJ6Ja+5gVle8Fnm6tcjsKUEiQ4ei9+f3jbeJlQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YwwSCHmN8M5rvIuBiJghqqbRIZkgsROeTMpkQYijMbv5UwpOj+E FeRdZyU+vlQ2qK0hbAFgzqt122gCV+AWKdlmWbI9QmyVtehKQgbtAYN9sa1w1qI= X-Gm-Gg: ASbGnct0G1pYsbePTXfmfjLzQtRqhKLVpQFtm2t/Do/h/oVX04od496q2Olf99L5esk lM9sYK4tfRSWWggrkcJYZIEUU2/RCUboLQqdiLbSXy1SbPBAgjZ2sL6+xvtXTSTZ6wYplXntIZa pbIDTvc0ibDvBvQ7Xntd9cGzlmbj+tmuEg4Yrw4X2Z1VN7tSeKTMGbCJQciiHOzQyeF91NoTF5T 1NSWrxN9haBuhkl5dsEfan5z+JzTAVAM65ABzLW/4cCPF2AFvh4KqwQTPJrQm0= X-Google-Smtp-Source: AGHT+IHSL9AamaKsgshnWGUpG5RDf6Peh0p8cvpBi3P9+5fw2YJx1zPvcrUsVqmzgsUtTQi3XDlSug== X-Received: by 2002:a17:907:7213:b0:aa6:4a87:3c4 with SMTP id a640c23a62f3a-aa69ffdbbbfmr261572766b.3.1733828451260; Tue, 10 Dec 2024 03:00:51 -0800 (PST) Date: Tue, 10 Dec 2024 12:00:49 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Jiqian Chen , Andrew Cooper , Julien Grall , Stefano Stabellini , Huang Rui , xen-devel@lists.xenproject.org Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support Message-ID: References: <20241202060956.1124162-1-Jiqian.Chen@amd.com> <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com> On Mon, Dec 09, 2024 at 02:59:31PM +0100, Jan Beulich wrote: > On 02.12.2024 07:09, Jiqian Chen wrote: > > +static int cf_check init_rebar(struct pci_dev *pdev) > > +{ > > + uint32_t ctrl; > > + unsigned int rebar_offset, nbars; > > + > > + rebar_offset = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_REBAR); > > + > > + if ( !rebar_offset ) > > + return 0; > > + > > + ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL); > > + nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK); > > + > > + for ( unsigned int i = 0; i < nbars; i++, rebar_offset += PCI_REBAR_CTRL ) > > + { > > + int rc; > > + > > + rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32, > > + rebar_offset + PCI_REBAR_CAP, 4, NULL); > > The capability register is r/o aiui. While permitting hwdom to write it is > fine, DomU-s shouldn't be permitted doing so, just in case. (An alternative > to making handler selection conditional here would be to bail early for the > !hwdom case, accompanied by a TODO comment. This would then also address > the lack of virtualization of the extended capability chain, as we may not > blindly expose all capabilities to DomU-s.) I don't think we can safely expose this capability to domUs by default, so my preference would be a returning an error in that case (and printing a log message indicating ReBAR is not supported for domUs). Note it's already not exposed to domUs by not being part of supported_caps in init_header(). Regards, Roger From xen-devel-bounces@lists.xenproject.org Tue Dec 10 11:03:52 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Dec 2024 11:03:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.852105.1266006 (Exim 4.92) (envelope-from ) id 1tKy1v-0008UD-2f; Tue, 10 Dec 2024 11:03:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 852105.1266006; Tue, 10 Dec 2024 11:03:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tKy1u-0008U6-Uc; Tue, 10 Dec 2024 11:03:50 +0000 Received: by outflank-mailman (input) for mailman id 852105; Tue, 10 Dec 2024 11:03: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 1tKy1u-0008U0-Bz for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 11:03:50 +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 6f091f28-b6e6-11ef-a0d5-8be0dac302b0; Tue, 10 Dec 2024 12:03:49 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-385e87b25f0so3760822f8f.0 for ; Tue, 10 Dec 2024 03:03:49 -0800 (PST) Received: from ?IPV6:2003:ca:b746:63c:3d8c:c505:78ea:f982? (p200300cab746063c3d8cc50578eaf982.dip0.t-ipconnect.de. [2003:ca:b746:63c:3d8c:c505:78ea:f982]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3863afc16b0sm7247176f8f.37.2024.12.10.03.03.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Dec 2024 03:03: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: 6f091f28-b6e6-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733828629; x=1734433429; 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=OXIX+4qELLkm2iATGIFnUkN8RiljZvitomEBLL4mB8s=; b=Ci2xKpldBkbxdY34uOZ9VhMuvelRWc/C1/xYecGAyjqkHgP8O0T8KNDIULmPSaKWMe QyHjwqBddjjrVIoglOzdbW4qTayBqNDCfS5Pk3nTJ+UJ7qvysaC8EqwEYJA/dP5aN4i3 BPOwdLqhFHNmFgo8aY940tKFU5fmXIGrd/KhXuaVT53vaC4cZxSG15AozHVY79Vcj5Lf 3Z8o68HNLW9umSz/7tLNzf2PSf4PnnBTcdlrmuBgHsyB/v0TxrLnRU/aIltYVnPKPyES dZMvTpBSmF4cX6tGTzJvM5hKgfDc+0cxk6xar6IpukbLJ3eRKltl+eZNBvDZBi5OkYbR jREw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733828629; x=1734433429; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=OXIX+4qELLkm2iATGIFnUkN8RiljZvitomEBLL4mB8s=; b=vRRtXpgHp+rYE8eODDl4wb1wk0mvZdC6YJeuIfXN/Is5xmkrlfWqAQ47XV2NCFIO/l 52lUTXAfM2/UEk5/O6OO11C/Wg851RyMoqLOAef2652gYZU8qIOD4p7JSR9Nouw+QpBt EVOjfIhbQnY6IDuewR496bHcZkfmVFcdKLXEqU8RICwgR2c+5OCntZrd91dR6TMTs4E1 6laWjxkzDNE2IZybFdoOZ+9bssTx2YXpxP8OGudwVFq/PMnGKGOgt9dNvGuhsksbnwVJ w9J/KokC8h9k/uibVdI8sPXgqjwRt5+ExNJMmVjwzNtDzLQmvjdE6dVh06Q8NEpU1y2i OTGQ== X-Forwarded-Encrypted: i=1; AJvYcCUR4c6v1DpCfW0QpjHtG2VsEicrGah7jgK+G1mlO7wU4ZwzFCJ3C2urFiAu3XaK55qi0Ff8vmQ8YxM=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy/ELGnZElSQfozmfxtSyluJVlF8Mb3q43WEMmq/0yGeP6HI2c4 vxoA+ykO5E4Pl0G0SBIeo+ACCNWMYxrwKGzU7/YSrAfPz57/LHxnc1OH/a5ubA== X-Gm-Gg: ASbGncu/52RAxsSg+GFjd5eSbTiY+fCFM3a2p4sAjaYyOZJFOCe1aK7KbyWg9hNSueV A61pcLCx2xXzMYrIjvtm0DnVsPAPRcgQ0oFAypRmsPcjkSV8rCBkueaaVp3FJlDQkb8Hgw/90Ym zjUpV2BCK8ta5572RFPnqdt0IIYDa+2qDbSEMpy8FHIRJ/Gw75UkVGbiLUncvHlXlGujrIqhrXn yI5XYcDw1KXAAENkmh4Dd5EM+WeHV23Ve+Adp2AroWBOdeg9sHY9VEQuAnwIJNUe9jcGmFh3YHb j48Rg2BtjdG2JLWmFwi6KEpRwXyEMrGpCuD0c7n8nqOVH75IbTNd0v5pkWn/mvWVvYHU+8ExL1P vXKparN/53Q== X-Google-Smtp-Source: AGHT+IGd+8b1Bwje2BKjl1Vo5u3xODS04RUVwUwUha0bPnqtDWtMoxjhtaDwEaFDVqAMmkk1ChciRg== X-Received: by 2002:a05:6000:2ad:b0:382:45db:6a1e with SMTP id ffacd0b85a97d-386469ad719mr1955396f8f.14.1733828628937; Tue, 10 Dec 2024 03:03:48 -0800 (PST) Message-ID: <361bcfe8-6c76-4508-bbd9-961f75baa10f@suse.com> Date: Tue, 10 Dec 2024 12:03:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Xen 4.20 Development Update [November] To: Oleksii Kurochko Cc: committers@xenproject.org, kelly.choi@cloud.com, xen-devel@lists.xenproject.org References: <20241204102035.22505-1-oleksii.kurochko@gmail.com> <3e4e504e-f4d4-4ac2-be66-3f32a9f31c9a@suse.com> <412fabb2-04e2-49cd-a204-340fea3ad940@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: <412fabb2-04e2-49cd-a204-340fea3ad940@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 10.12.2024 11:29, Oleksii Kurochko wrote: > On 12/4/24 12:01 PM, Jan Beulich wrote: >> On 04.12.2024 11:20, Oleksii Kurochko wrote: >>> *  Support device passthrough when dom0 is PVH on Xen (v16) >>>    -  Jiqian Chen >>>    -https://lore.kernel.org/xen-devel/20240930034250.2682265-1-Jiqian.Chen@amd.com/T/#m5d557d76f290ff5b5550c1443cab5774d397e526 >> Some of this went in too, I think? > > "Support device passthrough when dom0 is PVH on Xen" should be moved to Completed. ( Accidentally did a grep for the cover letter subject not > for the subject of the 1st patch so though that 1st patch isn't merged. > > And it seems to me that it should be mentioned in CHANGELOG.md, shouldn't it? If that work is deemed to be complete, perhaps. Jan From xen-devel-bounces@lists.xenproject.org Tue Dec 10 11:05:44 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Dec 2024 11:05:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.852117.1266016 (Exim 4.92) (envelope-from ) id 1tKy3i-0000eh-GS; Tue, 10 Dec 2024 11:05:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 852117.1266016; Tue, 10 Dec 2024 11:05: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 1tKy3i-0000ea-DI; Tue, 10 Dec 2024 11:05:42 +0000 Received: by outflank-mailman (input) for mailman id 852117; Tue, 10 Dec 2024 11:05: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 1tKy3h-0000eO-Dv for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 11:05:41 +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 b1231254-b6e6-11ef-a0d5-8be0dac302b0; Tue, 10 Dec 2024 12:05:40 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-434e3953b65so21973215e9.1 for ; Tue, 10 Dec 2024 03:05:40 -0800 (PST) Received: from ?IPV6:2003:ca:b746:63c:3d8c:c505:78ea:f982? (p200300cab746063c3d8cc50578eaf982.dip0.t-ipconnect.de. [2003:ca:b746:63c:3d8c:c505:78ea:f982]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-386219096b8sm16049294f8f.84.2024.12.10.03.05.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Dec 2024 03:05: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: b1231254-b6e6-11ef-a0d5-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733828740; x=1734433540; 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=IFcdD2jm1JS2uLl6E5zYjBh52nJmsDjO8uQkSwxPF7g=; b=QBqX3dnmENDeUWNEbnBFrpY5aP5uSSlqtEMksCx2aAFfP9RZfx2draXXo++X7q1WsX rn/kOPEAWSixE0PEGgOCuPS6eIeaZTTgdhb2lPcMDGC3CW4wEBngRnj2Lsr7n0Z0Rg2E eTWGsDOtkhEwuy8zYheCYM7hMBJMrUU0GReiw2iat4kHDL/OPjeHnG0lIX626o7Jq7ft tY7DH5Tp1drr40JW0qKud8KwmY03P+Ce5t9Dqb+HzaAqEpLBILB/VCGBqxAB5jmZAqXz IaS7q/nlLXih6GqMVBRWaJuPsRBsS3iWlM6frgqZ2niKs6/YK7AM2OBSpaLihu70+hgw pXCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733828740; x=1734433540; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IFcdD2jm1JS2uLl6E5zYjBh52nJmsDjO8uQkSwxPF7g=; b=NFg3HPapc3yVSF5CU6gGhWLym1ZOP6UPDy/6kh8cpmRJRugc3env0QrDk0dzrupf+v 2mKpyrgj08WvK0vZOasZWgCJ6A2EClVtG5RnBxlGMmv9+8+IkMpzcptcyvaj5ip29S5I RVg8xPKV+/CSpbCkWdXZHYayKQG4xN4f6EXbaF4gMYNcbRKHCqUjb82nEPIHwyjY1m2m 5WxNZ/PDYLlmMoYGlQUEeDVDjem3L4ZkI2jl5ra8EB+jA9+ozTRUXIQ/HAFZDmqaJ0v6 S3Y8Z7rQV1ChIvpGCcrQv/EL/ea1bH0TVY5y7mokU3BecUI4ksU5rj5uOlNoBeXZOoZj NREA== X-Forwarded-Encrypted: i=1; AJvYcCXkKn32KljN7iVcxOA86lcvVXzqkI4rzZExbSkKcF3kcee1LLmfARg9q5MzqQVNRuSDaA38cIdGBUM=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywhd87xlqlZUraQzpWKVuwyz2+k1CtCQZv1FVTuvmsbhdCDzY6Q sqfoj5Ol+jtGXtq4goFcukWKDHCfiOvaDZAR0WJ6LSfOCexJt8kC2HK+ano8SYNHfLl7bzwSqn0 = X-Gm-Gg: ASbGncvaI1etwfrAKbzibDY2rImMr1mrUGAHyKFUdvZYKywuNikqT8cI8r61AQ8YsJn UO9yXisnPpZHzEKQtpMaz/i4SbKH9wypbOIBsg0zar6YbWKUhW1vtZCz4xhmFxPDd3yErI1Rrb0 anRl0tByE1q+9r3CFPiF63KrwceOgfxIqx+PJqjqO8CtqpK7CqmZOEF6/U1sN1Upo1Q3o2SLpZd TUEPvbib86MxiB6dFbjKgfeG/rDbxmj5MDWMS+RgeZqCvsTdQaMb4G6/rbzS/q0nsm6tUfv/DdB IVO5OMwyjQgVnUo91sgAkXDMiggZfTemaKkb0cd4QabEzet8xKCRv2ncd/zr/9OtegxxtRvVXE/ XB5EnnCXytQ== X-Google-Smtp-Source: AGHT+IGr9mw9OCitLaVF5hjLM7Jvh3nieaza+nKcxv2x8+A5VeCt8W2K9I8HQay68DpiBUJr0VoGDQ== X-Received: by 2002:adf:f38f:0:b0:385:ec6e:e899 with SMTP id ffacd0b85a97d-38645405137mr2350023f8f.59.1733828739817; Tue, 10 Dec 2024 03:05:39 -0800 (PST) Message-ID: Date: Tue, 10 Dec 2024 12:05:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Jiqian Chen , Andrew Cooper , Julien Grall , Stefano Stabellini , Huang Rui , xen-devel@lists.xenproject.org References: <20241202060956.1124162-1-Jiqian.Chen@amd.com> <4e4df0ee-67f6-41e3-bfc7-e78011680015@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.12.2024 12:00, Roger Pau Monné wrote: > On Mon, Dec 09, 2024 at 02:59:31PM +0100, Jan Beulich wrote: >> On 02.12.2024 07:09, Jiqian Chen wrote: >>> +static int cf_check init_rebar(struct pci_dev *pdev) >>> +{ >>> + uint32_t ctrl; >>> + unsigned int rebar_offset, nbars; >>> + >>> + rebar_offset = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_REBAR); >>> + >>> + if ( !rebar_offset ) >>> + return 0; >>> + >>> + ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL); >>> + nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK); >>> + >>> + for ( unsigned int i = 0; i < nbars; i++, rebar_offset += PCI_REBAR_CTRL ) >>> + { >>> + int rc; >>> + >>> + rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32, >>> + rebar_offset + PCI_REBAR_CAP, 4, NULL); >> >> The capability register is r/o aiui. While permitting hwdom to write it is >> fine, DomU-s shouldn't be permitted doing so, just in case. (An alternative >> to making handler selection conditional here would be to bail early for the >> !hwdom case, accompanied by a TODO comment. This would then also address >> the lack of virtualization of the extended capability chain, as we may not >> blindly expose all capabilities to DomU-s.) > > I don't think we can safely expose this capability to domUs by > default, so my preference would be a returning an error in that case > (and printing a log message indicating ReBAR is not supported for > domUs). I understood Jiqian's recent reply to mean that that's what he's going to do. > Note it's already not exposed to domUs by not being part of > supported_caps in init_header(). Just to mention it - supported_caps is, aiui, about "traditional" caps only anyway, not extended ones. Jan From xen-devel-bounces@lists.xenproject.org Tue Dec 10 11:14:16 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Dec 2024 11:14:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.852134.1266025 (Exim 4.92) (envelope-from ) id 1tKyBt-0002aW-7h; Tue, 10 Dec 2024 11:14:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 852134.1266025; Tue, 10 Dec 2024 11:14: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 1tKyBt-0002aP-5A; Tue, 10 Dec 2024 11:14:09 +0000 Received: by outflank-mailman (input) for mailman id 852134; Tue, 10 Dec 2024 11:14: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 1tKyBs-0002aJ-13 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 11:14:08 +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 de7c9e1b-b6e7-11ef-99a3-01e77a169b0f; Tue, 10 Dec 2024 12:14:05 +0100 (CET) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-5d2726c0d45so8271875a12.2 for ; Tue, 10 Dec 2024 03:14:05 -0800 (PST) Received: from [192.168.219.191] ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d3cf972f6dsm5830550a12.61.2024.12.10.03.14.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Dec 2024 03:14: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: de7c9e1b-b6e7-11ef-99a3-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733829245; x=1734434045; darn=lists.xenproject.org; h=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=PanCeP32sCOlzvOWZ2FsBznZgpJOGljF9olnOzuk8VE=; b=RcNltJA8qd3NdRc0slSQ9CDtUf8ktWztHosZ5sSzomPQWf2LocfdVeMtu8CZfkiw8F fPwqEbhpQGe16/GrZy+LHvKnogRYU5FPTdl0dMTrDlDaWUG3iC0P9nu9nqDu715kIWeZ zGt3h6IrNxOU5bcnuX7xS00p9AHOM2FNx3CsgqBWXmSP2DzGmK183olp5+k8cfBu04Uw 3JebCdlH7HtJroBEkDn3xugGqjyfFa2ez+4ZGM/NnSD/7raxyBW5BpZHAvT5OYwCLwrQ UHebo62skBwRIubHEWt5g4/NV0xKqfoPYsrD2G/HhGIAiu17xeojuZFE3UTk6AG4EooV hRNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733829245; x=1734434045; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=PanCeP32sCOlzvOWZ2FsBznZgpJOGljF9olnOzuk8VE=; b=btsCS+cHWAG7v1hxFqi77Jlw9dYn4CuNrzNe7MuXMlA3Sq51QvBgwJNx+fC5tkWCyo 8Z8GB76X7f/NGAEk1XOrMIcvAVY4YDpzk1Nv2UoV2K+zwqKJpoHklm98+rmmDNZVZhEm /rCj2LEsotdJkgxqf2dYsLe1A802p2X1AQdhQc/v+68+54hREVjiLGvScf04Dtz6IStT 1qN7rR3AITzW5MUHXJDYG9vZwAKWOW6D8jr++LuN3SOFv2mEUm/fysUp67c//Rg4o2Y5 H2RRxGzYgWcAsu9OLW9+dM6QAUAPs+MEWFQLI+6gaJxpBg3NtFCbWDr6D7dWeG0qpXp3 Esxg== X-Forwarded-Encrypted: i=1; AJvYcCU1bvHBivLvG7dx/v2r0SITU3NSH6uZ248b+eeiy04e3LV0PO02tMMsvnMoSh+wtWmbvKMQqPE2yZ0=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywh2HnGbsmKK/D/TMzudzU393yO2c4O4gqz+eZtRrDZ3KnM88DO WseHLtpwU3HmQSw3DiTzc1e0RCSUzgZf96w17CNPt2dKj/N+KvD4 X-Gm-Gg: ASbGncuVH/xmSc/WFc7v7F5SsQr+OHsln6/m95qsC+qIx2h7WqHrc5Gqi4BejTjBOTf PZLnztqI4KNx3RYRhVa9/fmKL4CI9l8UBZ0gxrALpIcf2fFlkUzQ7L11elVi1U87D34kfnlWONh ra4LXqsG1t/0ITLIOhSPh3HBZVL8nOjMmPTe02Sww37EJl2SE1oyVmnISpE2RpqnfIsgZbu3BIQ 1/mcrrqfQvyKqLttUVr1tP3TZlYiZJ+xFZrJMZTmnzKMl2aTIXNOwk+fh0ugMJawWA= X-Google-Smtp-Source: AGHT+IEvm9kcCXTVGnyWs5XOpmf4fe7Q66fbqNPsMyRbvKdmtWWwEM+RCds0qLO3agb61X3Aqobjqg== X-Received: by 2002:a05:6402:388f:b0:5d2:73b0:81ef with SMTP id 4fb4d7f45d1cf-5d4185fdeebmr4637559a12.22.1733829245093; Tue, 10 Dec 2024 03:14:05 -0800 (PST) Content-Type: multipart/alternative; boundary="------------eSPJsR1z4PnPkS5pjaIYUzk5" Message-ID: Date: Tue, 10 Dec 2024 12:14:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/6] xen/riscv: add destroy_xen_mappings() to remove mappings in Xen page tables To: Jan Beulich Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <0640888f-3b9d-4f5c-9797-856374f16155@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <0640888f-3b9d-4f5c-9797-856374f16155@suse.com> This is a multi-part message in MIME format. --------------eSPJsR1z4PnPkS5pjaIYUzk5 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/9/24 3:23 PM, Jan Beulich wrote: > On 27.11.2024 13:50, Oleksii Kurochko wrote: >> Introduce the destroy_xen_mappings() function, which removes page >> mappings in Xen's page tables between a start address s and an end >> address e. >> The function ensures that both s and e are page-aligned >> and verifies that the start address is less than or equal to the end >> address before calling pt_update() to invalidate the mappings. >> The pt_update() function is called with INVALID_MFN and PTE_VALID=0 >> in the flags, which tell pt_update() to remove mapping. No additional >> ASSERT() is required to check these arguments, as they are hardcoded in >> the call to pt_update() within destroy_xen_mappings(). >> >> Signed-off-by: Oleksii Kurochko > Acked-by: Jan Beulich > > However, ... > >> --- a/xen/arch/riscv/pt.c >> +++ b/xen/arch/riscv/pt.c >> @@ -421,6 +421,14 @@ int map_pages_to_xen(unsigned long virt, >> return pt_update(virt, mfn, nr_mfns, flags); >> } >> >> +int destroy_xen_mappings(unsigned long s, unsigned long e) >> +{ >> + ASSERT(IS_ALIGNED(s, PAGE_SIZE)); >> + ASSERT(IS_ALIGNED(e, PAGE_SIZE)); >> + ASSERT(s <= e); >> + return pt_update(s, INVALID_MFN, PFN_DOWN(e - s), 0); >> +} > ... I'm unconvinced the constraints need to be this strict. You could, > for example, very well just avoiding to call pt_update() when s > e > (or really when s >= e). Thoughts? On one hand, we could simply avoid calling |pt_update()|, but on the other hand, this approach might cause us to miss a bug without any notification. Given that this is an|ASSERT()| that only triggers in debug builds and is unlikely to occur, I believe it is not critical to include the|ASSERT()| here. Additionally, avoiding an extra |if| condition helps prevent any potential performance impact. However, the|if| condition would likely evaluate to true most of the time, allowing hardware optimizations to handle it efficiently. ~ Oleksii --------------eSPJsR1z4PnPkS5pjaIYUzk5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


On 12/9/24 3:23 PM, Jan Beulich wrote:
On 27.11.2024 13:50, Oleksii Kurochko wrote:

Introduce the destroy_xen_mappings() function, which removes page
mappings in Xen's page tables between a start address s and an end
address e.
The function ensures that both s and e are page-aligned
and verifies that the start address is less than or equal to the end
address before calling pt_update() to invalidate the mappings.
The pt_update() function is called with INVALID_MFN and PTE_VALID=0
in the flags, which tell pt_update() to remove mapping. No additional
ASSERT() is required to check these arguments, as they are hardcoded in
the call to pt_update() within destroy_xen_mappings().

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

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

However, ...


--- a/xen/arch/riscv/pt.c
+++ b/xen/arch/riscv/pt.c
@@ -421,6 +421,14 @@ int map_pages_to_xen(unsigned long virt,
     return pt_update(virt, mfn, nr_mfns, flags);
 }
 
+int destroy_xen_mappings(unsigned long s, unsigned long e)
+{
+    ASSERT(IS_ALIGNED(s, PAGE_SIZE));
+    ASSERT(IS_ALIGNED(e, PAGE_SIZE));
+    ASSERT(s <= e);
+    return pt_update(s, INVALID_MFN, PFN_DOWN(e - s), 0);
+}

... I'm unconvinced the constraints need to be this strict. You could,
for example, very well just avoiding to call pt_update() when s > e
(or really when s >= e). Thoughts?
On one hand, we could simply avoid calling pt_update(), but on the other hand,
this approach might cause us to miss a bug without any notification.
Given that this is an ASSERT() that only triggers in debug builds and is unlikely to occur,
I believe it is not critical to include the ASSERT() here. Additionally, avoiding an extra
if condition helps prevent any potential performance impact. However, the if condition
would likely evaluate to true most of the time, allowing hardware optimizations to handle
it efficiently.

    
~ Oleksii

  


--------------eSPJsR1z4PnPkS5pjaIYUzk5--


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 11:22:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 11:22:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852147.1266036 (Exim 4.92)
	(envelope-from )
	id 1tKyKG-0004S3-0i; Tue, 10 Dec 2024 11:22:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852147.1266036; Tue, 10 Dec 2024 11: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 1tKyKF-0004Rw-T1; Tue, 10 Dec 2024 11:22:47 +0000
Received: by outflank-mailman (input) for mailman id 852147;
 Tue, 10 Dec 2024 11:22: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 1tKyKE-0004Rq-OB
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 11:22:46 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 13a8e3e9-b6e9-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 12:22:44 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5d3e8f64d5dso4532868a12.3
 for ; Tue, 10 Dec 2024 03:22:44 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d3dd4f641bsm4848120a12.51.2024.12.10.03.22.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 03:22: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: 13a8e3e9-b6e9-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1733829764; x=1734434564; darn=lists.xenproject.org;
        h=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=Qup0cVCyJDRhtn49zetXW1dYP3Q8KNLLw66dhKfZx4g=;
        b=EQU6K672ohkKGL5UONFwVH3oA6YwRF4BtrO9+mvJL2h3dIfxRj59JEZN/vnarCBikX
         iv6bkiAV7JrzgzUMZfDUpANFxcv9mL1hvil5uBmoQ9tJp/YFj881XMxoQ6c4BK83oV1b
         XNIf9ZexoqX3AQoJsWaVWHI3FzP5QjpfA1OY5x/jtkv5l98S7ftKeRiiannHgiNgW2Gy
         ruZZ3GKYUadHoYHRn0MrmqN+xSWxHPa7/78CF+/wVGvBlUnAcODwLEt/9y8vZwxxV6Y8
         WB0J64PhKWo8Cpg6fSnVS77ErPVkqDWSKFX9eU7WvHcW097XSWXcmAgK2cTuILq99zG/
         DTIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733829764; x=1734434564;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=Qup0cVCyJDRhtn49zetXW1dYP3Q8KNLLw66dhKfZx4g=;
        b=Yg9p7DWUJJvMGWmu99W/1+2IMxgSkNtlJ8ZfBGS0FKQ4y/nh5gT67+6WjWXH2M99X8
         kygvabnmJVfCtSX02wSVsm/v/tJpSqXbyaxFuVSlx5k1WLs6yLgE7AgntPqU6qKQfaBL
         SZCJ7V+IshfLPVczmy0PQ1KREbY4G2SJqCHtHreWFI7j6LM7fXbwJzTID+Tf1o7CEhYl
         ugh0c1LS830NkC0S9Tsjr/wAfLL5qNgMGVh/WSHS/N5Q216HfOUo0ogHcyHyjbE3yPcD
         FpV6SbhQkw9f+vIWJrAs026CHR/qlJZL4Gkziuari5ZWc6ldto9y9SVZyPaFXtxtYoEB
         q7GQ==
X-Forwarded-Encrypted: i=1; AJvYcCXF+qRY1ccgT4yFRZQIU5uuggRfFAyDPgZYcsqBY5K2GxBac9MC2dN6l8S0yhAzg7cHfYy/ahyoWi4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyO9h2SXmbl1TJ+yGTx977giwMD7ptIcpTJOspHfsgEdj26paOE
	7H4wlC7Th+qRTL2huOQVBb7kCbxq0CtqetT8fuymvlPiBU6TyVdG
X-Gm-Gg: ASbGnctTlbSsTzrzDnjBrF9bXjMYgbHdbVJoaNnaUidv1+TAcRVXJX+Ia8/EIErPOO5
	uAVYX89eGX12Qvt7iNb730K6cG+mNpqXJRlDj4IfywFYaNpReOuBre8qb8bE5cY/gXj6zUqe01U
	Iq/YBL65qZ9gjzHWQdLkklIWAkvEqAIMZHmp6wOGopjtXLSrlnJmV4hLzV3xOMeUPnOri3b9P4b
	Rf4iymHqAw8QWj1WDif02mQv3RYY/q7yCCny0fNU4IDrewmHhAp6zM/resKep5gYa8=
X-Google-Smtp-Source: AGHT+IHy7HLHJb/Z4w9KFW7LMCJnE9kNeh1ylA+9qdjdxp72cmUkT9s5CVTz8AHmCDdhsFkVAZXgfQ==
X-Received: by 2002:a05:6402:3582:b0:5d0:b7c5:c409 with SMTP id 4fb4d7f45d1cf-5d3be694a4emr17057445a12.14.1733829763939;
        Tue, 10 Dec 2024 03:22:43 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------j9VG0DoQf7FRS7fgqusUDU50"
Message-ID: <8ca7a15a-bdc4-44fb-8702-33ba03a38207@gmail.com>
Date: Tue, 10 Dec 2024 12:22:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 3/6] xen/riscv: add {set,clear}_fixmap() functions for
 managing fixmap entries
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: 
 <2badea2de39b7614d38a620d1b718478de1fc82c.1732709650.git.oleksii.kurochko@gmail.com>
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

This is a multi-part message in MIME format.
--------------j9VG0DoQf7FRS7fgqusUDU50
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 12/9/24 3:29 PM, Jan Beulich wrote:
> On 27.11.2024 13:50, Oleksii Kurochko wrote:
>> Introduce set_fixmap() and clear_fixmap() functions to manage mappings
>> in the fixmap region. The set_fixmap() function maps a 4k page ( as only L0
>> is expected to be updated; look at setup_fixmap_mappings() ) at a specified
>> fixmap entry using map_pages_to_xen(), while clear_fixmap() removes the
>> mapping from a fixmap entry by calling destroy_xen_mappings().
>>
>> Both functions ensure that the operations succeed by asserting that their
>> respective calls (map_pages_to_xen() and destroy_xen_mappings()) return 0.
>> A `BUG_ON` check is used to trigger a failure if any issues occur during
>> the mapping or unmapping process.
>>
>> Signed-off-by: Oleksii Kurochko
> Acked-by: Jan Beulich
>
> However, ...
>
>> @@ -433,3 +434,21 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns)
>>   {
>>       return pt_update(virt, INVALID_MFN, nr_mfns, PTE_POPULATE);
>>   }
>> +
>> +/* Map a 4k page in a fixmap entry */
>> +void set_fixmap(unsigned int map, mfn_t mfn, unsigned int flags)
>> +{
>> +    int res;
>> +
>> +    res = map_pages_to_xen(FIXMAP_ADDR(map), mfn, 1, flags | PTE_SMALL);
>> +    BUG_ON(res != 0);
>> +}
> ... imo in such cases it is preferable to go without a local variable:
>
>      if ( map_pages_to_xen(FIXMAP_ADDR(map), mfn, 1, flags | PTE_SMALL) != 0 )
>          BUG();

I will update that in the next patch version.

>
> Just to double check: Iirc this BUG would in particular trigger when trying
> to set a fixmap slot that was already set, and not intermediately cleared?

Yes, correct.

Thanks.

~ Oleksii

--------------j9VG0DoQf7FRS7fgqusUDU50
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    


    

    
On 12/9/24 3:29 PM, Jan Beulich wrote:

    

    

      
On 27.11.2024 13:50, Oleksii Kurochko wrote:


      

        
Introduce set_fixmap() and clear_fixmap() functions to manage mappings
in the fixmap region. The set_fixmap() function maps a 4k page ( as only L0
is expected to be updated; look at setup_fixmap_mappings() ) at a specified
fixmap entry using map_pages_to_xen(), while clear_fixmap() removes the
mapping from a fixmap entry by calling destroy_xen_mappings().

Both functions ensure that the operations succeed by asserting that their
respective calls (map_pages_to_xen() and destroy_xen_mappings()) return 0.
A `BUG_ON` check is used to trigger a failure if any issues occur during
the mapping or unmapping process.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>


      

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

However, ...



      

        
@@ -433,3 +434,21 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns)
 {
     return pt_update(virt, INVALID_MFN, nr_mfns, PTE_POPULATE);
 }
+
+/* Map a 4k page in a fixmap entry */
+void set_fixmap(unsigned int map, mfn_t mfn, unsigned int flags)
+{
+    int res;
+
+    res = map_pages_to_xen(FIXMAP_ADDR(map), mfn, 1, flags | PTE_SMALL);
+    BUG_ON(res != 0);
+}


      

      
... imo in such cases it is preferable to go without a local variable:

    if ( map_pages_to_xen(FIXMAP_ADDR(map), mfn, 1, flags | PTE_SMALL) != 0 )
        BUG();

    

    
I will update that in the next patch version.



    

      

Just to double check: Iirc this BUG would in particular trigger when trying
to set a fixmap slot that was already set, and not intermediately cleared?

    

    
Yes, correct.

Thanks.

~ Oleksii


  


--------------j9VG0DoQf7FRS7fgqusUDU50--


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 11:25:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 11:25:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852156.1266045 (Exim 4.92)
	(envelope-from )
	id 1tKyMd-00050x-Ch; Tue, 10 Dec 2024 11:25:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852156.1266045; Tue, 10 Dec 2024 11:25: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 1tKyMd-00050q-9U; Tue, 10 Dec 2024 11:25:15 +0000
Received: by outflank-mailman (input) for mailman id 852156;
 Tue, 10 Dec 2024 11:25: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 1tKyMc-00050k-35
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 11:25:14 +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 6c17b7f9-b6e9-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 12:25:13 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5cfa1ec3b94so7110830a12.2
 for ; Tue, 10 Dec 2024 03:25:13 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa653a95e90sm518661366b.173.2024.12.10.03.25.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Dec 2024 03:25: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: 6c17b7f9-b6e9-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733829912; x=1734434712; 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=E60N0SEVUwo/nJDsVvbVs3YkHOZ5b7Qy4u9k+Vr0HpM=;
        b=D5WB0WdsBFhZF+kLXm2GIsTHf95nuCWDCr4VDerDrNCnAjNy99NVSqJ/8qJhsLnasm
         zL9QeI5AukaD47fTU410dssOblUO+gY/+YD1gVVPktbXphw8FB2rbStd60h29DgkPLzn
         8WGIAZdvuds7djdIbJDW58BGOMzQCotq9MXUc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733829912; x=1734434712;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=E60N0SEVUwo/nJDsVvbVs3YkHOZ5b7Qy4u9k+Vr0HpM=;
        b=ntINwlfJG0oB7cBdO9CO7FPnhAXSeLMfhcRap5IPz1Ji6Di22ssQG2ErePOHiBbShU
         zuvp6O+iBwiQjxxcC/XaZTQ6qWnYztLPerLu5BPe1sZMPKOq+bPiiNXlZJcPW41OFwUi
         T73swxXJ9evQ5TsZM1EnBLShoYnZEAqhUpPTyrgunzNiYXgGYIyRJ0kPs4zVjXnVV8mE
         nmVyb44S9gL2A2EaH2fsaKhUxXgHV4q+ilMZkvkMtQCCLAKBuWTUzJYFz0aCmzngtvX8
         qSY7pawVyGyJcIWoGBJCnFz294Xlf6YH6/meZUDm9l9zeKoPEbOdoP325dP2ORo0L1YY
         zcfQ==
X-Forwarded-Encrypted: i=1; AJvYcCX53roQvvZ2WW+2mcnRZiP2RII3yBV6DeZksaTm1Vp/Uz9Lvb5iQD+B4YDczEWQot1JtY28SoM3Fp0=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw8aa9sFJ9QOb9d6zVz4C5FAjr40UcEMAW5fDF/HBM1kdCR6jlB
	UBzN6ZKEJGW3RWG0pieVjPUeY2X79WUTu7R0GZzY9JhIaeJI6/Oad6TevK8D79o=
X-Gm-Gg: ASbGncv8dV9VlSWAmnYLyPBrufqimyPQLqxh+AVKLU/bBjjQFAnrjiv9al86ko3eAIj
	X8Cv6l8NanX0T+a7TjfI54vJHcFElUqQ7mg7EhrZC1xJU8hbl7FNvyBkdqmp1TR4C7X6kHvXzhV
	oY8+VduiJgBdkyjgFW5YdoieiW1gORrNDtg+sTZqJzqRdY/RSLl1rQtux8WNHjjZFL8A0YfpXvH
	8GHe5K80gTjPZGO5pE9wz9cPanTS9utkp1xnSKv3MVFKBwF5NyRgSSLQDKkaJc=
X-Google-Smtp-Source: AGHT+IGpZ+5h+V/OaKu4rLAugAtiBQKs062BZz7VmOi8ggU8c101z4hNIazRY5yuslTKV40QBj+UGQ==
X-Received: by 2002:a17:906:4d1:b0:aa6:aa8a:9088 with SMTP id a640c23a62f3a-aa6aa8a90a2mr48494966b.41.1733829912445;
        Tue, 10 Dec 2024 03:25:12 -0800 (PST)
Date: Tue, 10 Dec 2024 12:25:11 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "Chen, Jiqian" ,
	Andrew Cooper ,
	Julien Grall ,
	Stefano Stabellini ,
	"Huang, Ray" ,
	"xen-devel@lists.xenproject.org" 
Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support
Message-ID: 
References: <20241202060956.1124162-1-Jiqian.Chen@amd.com>
 <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com>
 
 <1e0576d9-400e-4483-8dd1-061e215a00cd@suse.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Tue, Dec 10, 2024 at 10:54:43AM +0100, Jan Beulich wrote:
> On 10.12.2024 08:57, Chen, Jiqian wrote:
> > On 2024/12/10 15:17, Jan Beulich wrote:
> >> On 10.12.2024 08:07, Chen, Jiqian wrote:
> >>> On 2024/12/9 21:59, Jan Beulich wrote:
> >>>> On 02.12.2024 07:09, Jiqian Chen wrote:
> >>>>> +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
> >>>>> +                                      unsigned int reg,
> >>>>> +                                      uint32_t val,
> >>>>> +                                      void *data)
> >>>>> +{
> >>>>> +    uint64_t size;
> >>>>> +    unsigned int index;
> >>>>> +    struct vpci_bar *bars = data;
> >>>>> +
> >>>>> +    if ( pci_conf_read16(pdev->sbdf, PCI_COMMAND) & PCI_COMMAND_MEMORY )
> >>>>> +        return;
> >>>>
> >>>> I don't think something like this can go uncommented. I don't think the
> >>>> spec mandates to drop writes in this situation?
> >>> Spec says: Software must clear the Memory Space Enable bit in the Command register before writing the BAR Size field.
> >>> This check is suggested by Roger and it really helps to prevent erroneous writes in this case,
> >>> such as the result of debugging with Roger in the previous version.
> >>> I will add the spec's sentences as comments here in next version.
> >>
> >> What you quote from the spec may not be enough as a comment here. There's
> >> no direct implication that the write would simply be dropped on the floor
> >> if the bit is still set. So I think you want to go a little beyond just
> >> quoting from the spec.
> > How about quoting Roger's previous words: " The memory decoding must be disabled before writing the BAR size field.
> > Otherwise changing the BAR size will lead to the active p2m mappings getting out of sync w.r.t. the new BAR size." ?
> 
> That'll be better, but imo still not enough to explain the outright ignoring
> of the write.

I think we might want to do something along the lines of:

uint64_t size = PCI_REBAR_CTRL_SIZE(val);
struct vpci_bar *bar = data;

if ( bar->enabled )
{
    if ( size == bar->size )
        return;

    /*
     * Refuse to resize a BAR while memory decoding is enabled, as
     * otherwise the size of the mapped region in the p2m would become
     * stale with the newly set BAR size, and the position of the BAR
     * would be reset to undefined.  Note the PCIe specification also
     * forbids resizing a BAR with memory decoding enabled.
     */
    gprintk(XENLOG_ERR,
            "%pp: refuse to resize BAR with memory decoding enabled\n",
	    &pci->sbdf);
    return;
}

Note this requires that the data parameter points to the BAR that
matches the ReBAR control register, this needs adjusting in
init_rebar().

> >>>>> +        if ( rc )
> >>>>> +        {
> >>>>> +            printk("%pp: add register for PCI_REBAR_CAP failed (rc=%d)\n",
> >>>>> +                   &pdev->sbdf, rc);
> >>>>> +            break;
> >>>>> +        }
> >>>>> +
> >>>>> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
> >>>>> +                               rebar_offset + PCI_REBAR_CTRL, 4,
> >>>>> +                               pdev->vpci->header.bars);
> >>>>> +        if ( rc )
> >>>>> +        {
> >>>>> +            printk("%pp: add register for PCI_REBAR_CTRL failed %d\n",
> >>>>> +                   &pdev->sbdf, rc);
> >>>>> +            break;
> >>>>
> >>>> Is it correct to keep the other handler installed? After all ...
> >>> Will change to "return rc;" here and above in next version.
> >>
> >> I'm not convinced this is what we want, as per ...
> >>
> >>>>> +        }
> >>>>> +    }
> >>>>> +
> >>>>> +    return 0;
> >>>>
> >>>> ... you - imo sensibly - aren't communicating the error back up (to allow
> >>>> the device to be used without BAR resizing.
> >>
> >> ... what I said here.
> > Sorry, I didn’t understand.
> > Do you mean it is not enough to return error code once a handler failed to be installed, I need to remove the already installed handlers?
> 
> No, if you return an error here, nothing else needs doing. However, I
> question that returning an error here is good or even necessary. In
> the event of an error, the device ought to still be usable, just
> without the BAR-resizing capability.

So you suggest that the capability should be hidden in that case?  We
have logic to hide capabilities, just not used for the hardware
domain.  It would need some extra wiring to be capable of hiding
failed capabilities.

Regards, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 11:28:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 11:28:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852172.1266055 (Exim 4.92)
	(envelope-from )
	id 1tKyPv-0005ew-Ub; Tue, 10 Dec 2024 11:28:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852172.1266055; Tue, 10 Dec 2024 11:28: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 1tKyPv-0005ep-Ro; Tue, 10 Dec 2024 11:28:39 +0000
Received: by outflank-mailman (input) for mailman id 852172;
 Tue, 10 Dec 2024 11:28: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 1tKyPu-0005ej-V1
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 11:28:39 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20612.outbound.protection.outlook.com
 [2a01:111:f403:2613::612])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e5576fa2-b6e9-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 12:28:36 +0100 (CET)
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com (2603:10a6:20b:5e4::22)
 by AS8PR03MB7336.eurprd03.prod.outlook.com (2603:10a6:20b:2ec::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.14; Tue, 10 Dec
 2024 11:28:34 +0000
Received: from AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593]) by AS2PR03MB8907.eurprd03.prod.outlook.com
 ([fe80::804:c187:252a:9593%4]) with mapi id 15.20.8230.016; Tue, 10 Dec 2024
 11:28: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: e5576fa2-b6e9-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hUdp3m8KB1lo/JhqEaYn7Iudj/I7oKGU6mxwRqdhyMfnqjtPNz5xL2+ajBvwxs0cmycfQDd7NT9gyBpsJjX3F3T0VZpwjvnPcrvMOHy1KaPPaCF8oDg1HXFoXG3dc1+s4ePhoJHtl26cTv6AVJQpe75OuVxWcMl/aQNnKqhyboW9EG2mwl8/KsAHVZRQG+FTxsUy644nGUksLVrisMTi60wn3Wjp8VBfPuJklyNVaJD/Q2bogug6eQMG2iKxsiqWYCp1jlfHdNnScEYy+IDKfXZwXJSM6jfW9yFGqfDqDagKEwWPwRyQEt7bpBnD6EddZl84om2QU4UsO/huPvso0g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=uWlJa9smDsPR1K3hbPl/gjgw2AoH+Vl0K27G8ISMxpg=;
 b=aZvvxn0GHUz8j4HJM8yYXsD12u1hp6Yd19HWPV3GDF2X6dmEQZnSIptqdr5nD+yib7Vbj8sDVmB5tuGRqvNLRDOD+cdZBD039Lhsp1Sc8Ti8NwejXVhP/HV6jhvlAQiTYZFRmYzhQWSSjdGnXLf8Fye9d+5rh7qKWVNkNmuGPGGElYJIPW8iskCeA0YSDuByBpjSQbHYvyYbXGu/zA+o5dyHQG1k75rBIIEyQGn7OL6KDQgBGJ3uDq7U/5FTcFV/eFVch83s7yESM4BvfZb759NVV0nyNxIc86rNezRFbl2jH1hcsvXXQd13i7Xys4JDRBlj5tKitRLXZ0b6slXvng==
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=uWlJa9smDsPR1K3hbPl/gjgw2AoH+Vl0K27G8ISMxpg=;
 b=SAhI13iFXwABZccH4jLF+X30miTu+LgVB6XSbjJAUZPdLb+5b0oGimYcO5Zr6oLRdLvkVe074W5cQsXUizXua+nJJ7RLeENbL2aXj7tf6TomSHf4at/e4Rmf4CjwPzI12+MMenEKJF74ngiIIOje9r2eYPzZAolD6f0tdLVC19OsDUy8SdEA7dTNt5WD9KbuYrK1Ez7k2ZRGZshkZiJN5DOIvQsUFGllW6ye9qB2KgIeZ3uFQVl8qyyKI9GvnS5VQFgE0dM1GKVdP/bjvcDOse2Kr/tUcTS50vXk1dtbtf+XAukTBkWnO494xXyV6VKFa0YkPyM2UyC6HhpyR5e2Tw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <364982fa-53b7-4e41-80a0-4511babdabe0@epam.com>
Date: Tue, 10 Dec 2024 13:28:31 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/8] xen/arm: Add SCMI over SMC calls handling layer
To: Andrei Cherechesu ,
 Julien Grall , xen-devel@lists.xenproject.org
Cc: S32@nxp.com, Andrei Cherechesu ,
 Stefano Stabellini ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20240930114715.642978-1-andrei.cherechesu@oss.nxp.com>
 <20240930114715.642978-4-andrei.cherechesu@oss.nxp.com>
 <59b54859-d893-4bf4-8118-7e4a00e7d87e@epam.com>
 <3d731902-d5eb-4f63-8501-5ddecf748cb9@xen.org>
 
Content-Language: en-US
From: Grygorii Strashko 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: FR0P281CA0072.DEUP281.PROD.OUTLOOK.COM
 (2603:10a6:d10:49::9) To AS2PR03MB8907.eurprd03.prod.outlook.com
 (2603:10a6:20b:5e4::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR03MB8907:EE_|AS8PR03MB7336:EE_
X-MS-Office365-Filtering-Correlation-Id: 4f02654e-76a3-4465-5080-08dd190dc7f3
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:
	=?utf-8?B?MXZaOGo4eC9ZMXhRY2FiWHk3S1p2ZzN4aklIaHdWeENjbURxcEppOUd1TjdC?=
 =?utf-8?B?MEI0eElKL0l3bkpTS1grSDg5enVrSHdEUXUvZWNWYnUrRmwwdVR0bi9XWm5r?=
 =?utf-8?B?SlhzbEd3Yk01Wml5Vk1OdTVwOXRiLzQyeWVrQWR5VndscDM3Y0ovVVdXQlVw?=
 =?utf-8?B?ODFPVzUrTVJabFM3NDFicFp1ZTFRSmhaVXNYUnFaRFpma2wrcVM3Q0hNd3du?=
 =?utf-8?B?VFZ1UWpVOGRTbnJkSFdnSVZVTGFHMDhyTWJ3RVVKWlpWOFU5NHNyeCt6SHRJ?=
 =?utf-8?B?SmNZWUNJSS9uN2JUT3ptRUN3M3huanZNQkR3SThtUzE0dWQ0dERZMkcvRTRT?=
 =?utf-8?B?clRxUGRXV0VwTEF0UnNhSGZRS3FVNHRZcTllL1NwcE1Hcms5cHZuWjFtL0lU?=
 =?utf-8?B?eGh1TEphWERxT1djaHlraG04WmNOaTFqSXZLNnRoZExRRXIvanlGaCtuSnBw?=
 =?utf-8?B?Skh1ZUhubUp0aWJvdTAwNnltVFU5b2VGcXNHWFFIeldFQTJ3ZHlnaFBJWXlx?=
 =?utf-8?B?TmpOQ3d6NHlkS1JGOFBxS1VTTXdyeFNXb013VDRzT0hXZmVpa0NFMnUwTHdi?=
 =?utf-8?B?NVN5cHBjUkdOaE5aUXZRYzhxQzVDY2NZWGNaS0U3VjJLMnlsT0Z6WFg3b2J2?=
 =?utf-8?B?NUVscUVxR1ZzRW9haHkrRVBhTHUzc2cvTkFhRU5kVjJzL2lzTFJlaFIzWTNW?=
 =?utf-8?B?Rld3dWZzMTJpN2ZZRkdvY2hHVHhmMGM1OFZzMnVrRVNmVnBDbGRHQ00wM2R2?=
 =?utf-8?B?blNZd3pUTFNzNUdPN3U0RXBJWVBrRmhCL0swYm40anhORzFRZldkUUpVeW96?=
 =?utf-8?B?aXJqbkFUK1dwekI3Q2N2U29XMXloQU9OWm5kb2pHTHJ3UUo3dVRkQ3grbWtK?=
 =?utf-8?B?UHFkWC9JelVEYXJDMG5CTlArcko2aXZpS2I0Rjlva1JCSFFkY3pNdFMxWmV5?=
 =?utf-8?B?UkpkSlpOODg1b2V6bm9UaHFLendWUmFKa2h3MGxHYXA2SzdVZFVIbFhrQ3Bl?=
 =?utf-8?B?UW15bmZueThhZ3EwZnk4dVdVc2ZTTEpScTBzSGtGc2RVMTc2bkEwanp6V01Y?=
 =?utf-8?B?dUhXaUJ1dnZQUDdudnVXV1hzZ1o5cnpXTkZsektUYndLV2QvOWQvb3Bpejgx?=
 =?utf-8?B?Tk9tUzlmbzdqRmJHdENuV3laVUtxdG1Bb3ZXSWpkQ1loWDZrckt4dXNaM1hJ?=
 =?utf-8?B?am1JRWFxYStRMFhpUytoUzVnTk1CYVBQNEdpbldIbXRqK0R5YWhHOVFDTjNE?=
 =?utf-8?B?ZE93a1kwWU8rUVlnNUxuNmZsWlhLRTAyL3VCaW1qNnc0NmhXYXZReUtZYUJj?=
 =?utf-8?B?aUE3a3JoNkFSazM1ckErc2JDbFBTNVhYVVpZV2dGR0tlTmVLZVhIYmM2akNZ?=
 =?utf-8?B?Z3RzcUNHUlBIQ2ROd2FvZk9VcGVhYi9uZVZxYjRRaUwwMGFidVltd3IybTdB?=
 =?utf-8?B?dWFoZzZlSUhKUzVIeTZ3N1ljNHpRKzBWa0VDQlkzcU9lcUpSSjlZZWc1UW0v?=
 =?utf-8?B?Mkd2aWZtb2tGRzgvS2txb2lINHZ5aU9tM2o4eDJVUjZ4S2R6d3QzRURrNGFR?=
 =?utf-8?B?WEVjT0JXMFhHcjdUTnRHbWxKSEV2cW1ONWsySzlwTGJ3UUdGQnpraGVIMVo0?=
 =?utf-8?B?aG1BdmRrTEcvUnpiK294bEFZeG4wM05CdGNZOC9jMXdWVDBvRnZkYktsZWhy?=
 =?utf-8?B?K0VhUEgzY2g2djJxeW5rVkxndFg2SnFzWEtCYksySGM1V0d0MDZyTG9jVm8v?=
 =?utf-8?B?YmlxZnJ1MHZGTjFGZFRpZzFXTkgvQkJDNExnOG1KRkJ1cnBoaVQ1OGpQQlps?=
 =?utf-8?B?S3h0L2lCZVU3czU5NGZmZz09?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB8907.eurprd03.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?NnU5czgwMXc5OEpERzlOTnBYWUV0NGZJYjFCMkRJSU90NXd3L1dZZ2Zrc2Nr?=
 =?utf-8?B?cXdkRTBVcFFBcjFEREg1aXN5U0tPS0tZb0V6cjE4SlJndEFSS2pUSkg0R093?=
 =?utf-8?B?RWNTMzBtaHRsWW1mOXFNKzVoZE1teWQ2OE9zVnBNc3pBZmV3R1NoYUN5QXBv?=
 =?utf-8?B?dEhkaG5TUS9iR2k3L1dUZ1RrSDl5SUdOSjBlTFhodWVjSERXamx3N2FDNEhZ?=
 =?utf-8?B?YThFdzNUZzA3UHhnNUZJL2thWUVkeER3ZHJpRmQvRDc0UWtBM2VVay8zQzE5?=
 =?utf-8?B?Ny94cEhnNjBkUk5ob0VzdUJQUGdQdnQzVTVPcWJlREJqMk9WbnpWdUpVVk81?=
 =?utf-8?B?ZlRxODhWSFBNOU5Cd2F5WUtZUGp5Y25sdGtJa25WQWNFNC9jakowb2F0TXc2?=
 =?utf-8?B?OWdjWVJzOVJqSHZ1ZDhNY29hWFNOdHc4T0FDWnd2aXZZTkF6cUc5ZlA0elFW?=
 =?utf-8?B?cjhmZ1V4MTUvZTJnMjlhdExFeGJVZWhmRlRKMXdKTUREblZHVTAycThvL3pG?=
 =?utf-8?B?UVlxM2taS2dESGxkclZReUtCcjBWNzdUVVMzM1lHZ3BmY0hJdWJhWHBmMkdj?=
 =?utf-8?B?S2UrNlYwdjk3djNEaVlnb1djOTM0V0NvK0ZWRy85S2dwbnZBQ1NORHZmOHZF?=
 =?utf-8?B?S3AwMzV1WnRXWU9CbGRIamFqd3pGZ3k0aWxRa2FzcFo2ZGtJUUNlemZYWE9z?=
 =?utf-8?B?TDU2eDl1Vlowc1d5c1ZkVWVqeVhLTXFFT2t4c3JKT0x4ZC9Xa1BRTElCZmVr?=
 =?utf-8?B?SHYya05OV3V4c0JmMDZOUjBja3RmckJWcHJ0dGdzcTdYRnpMbVVWUDBCaGVr?=
 =?utf-8?B?MStRNEc3Qm5BRXhxYlpwanVxNnpQZENwZnkrdnczeVErUk9ZTVRjQS9BVXJQ?=
 =?utf-8?B?SnhIQ0NBaTlzUGNmSk5WT2Q3MTBXZDVzcjZSZnFLYWVTUWZJM2I1VkEyVmdL?=
 =?utf-8?B?S3I5bjVuWGlpRnphTU9KNnJVdUxHZmlOU2hIam1MaGl3aERHUFQ0TUdTZDhP?=
 =?utf-8?B?YWs1eXZxK3B0KzNRZm9DamJ0SHNEdkswaEVRMHl1SUQ4Q3RqN2hiWnUvSkpl?=
 =?utf-8?B?bmdIbzQvUTMrVHRnRlMzUjFUUFp4dGRZMTNGSzNmaUszNFZWRld3em1kL2Zo?=
 =?utf-8?B?cmV3QjdLa3FLQUdycVZJZHg5U2pPNkh0bFE4LzZ5d2YxbVQ5aVg4VUNZTTRi?=
 =?utf-8?B?cDcxVGlTaDV3ZzBFdEd4bXhVUHdWUWRjcHpKM2VXOHdUMGt3TU9uMGlQRk1S?=
 =?utf-8?B?dk0wZW5xalRvenlLNTlWLzVWT1djYWEzam1Fd2xRRSt0akx5T3lNNVM1dW84?=
 =?utf-8?B?QjFmWFBMVU9Tdk02bmRhVG9tZFpWbVRwR1B6Q1Nmb2tLK1pEYjhaMHhadG03?=
 =?utf-8?B?bmhwd2psN1ZBS21JT0FYVkxDdE4vdGhyNkFKNDVZb0x2ME44M01IazUydkFw?=
 =?utf-8?B?SkJaSDMxZWtXcm01WmxnazZRRFhLR3JlZnUxT1JER0t6aFVSKy91T2Jsb2RT?=
 =?utf-8?B?aHVTMnVIYXltbFVyN0owVEIwSFJBMkJPRi9vVWVCTmJMT25PZUFiZzczNDFV?=
 =?utf-8?B?Y2xRbkE2VktwSG8yRE9nZW1TeXFndWUwTC94bUZnN2FSN0dhSDMyWUxmRWhD?=
 =?utf-8?B?VzNZQXFFQ3FVMHpCa0tzSXIySHpvL3hWUXd5UkdiRFpXUU56dERWK1J4b0Rv?=
 =?utf-8?B?OEVxS0xkUkN2VDZTT1k2T3Iyd2V4VUlXMVhaMDhwOFFNbm1IQ0dKdmxNcFkw?=
 =?utf-8?B?RHZNV2FQbmxCeFQ5MzlUeC9jWEk5dVBjZ2tncjZmY25uOHpXZjNxVXJXc1lw?=
 =?utf-8?B?MGxzVzlMRGhtaS9BakVhaFQ3ZFlVbDBOR3ZiVS80OUZNM3lFMi82aDFjYVJZ?=
 =?utf-8?B?ZHJxejRkcE1FYzFxSGFzbFNjTkNpWVpFS2JWL2xkdDBBbzhOU00zZFVZTVlB?=
 =?utf-8?B?cmRla2haUVF3K0JabFZUUVJRUmxka3dGUmIzM2JKQWlMUkNPWWpGdzlQRVd0?=
 =?utf-8?B?bjd3aG9OSHV5aGFPdXBzVVhpc1ZtUVNGM2NGQU9LZi85bUx0dHRNaE5qbXdr?=
 =?utf-8?B?ZlhLRUFaVWM4ZTh2WGUrcC9DUGRVZjNVNmlhNXdTZ0p6QnlIM0p4YTNmMUFk?=
 =?utf-8?B?RTEwSGhOTjdNNlZuQldvM3pDM0ltUnJDeWJWZWNFajhOR1ppd3lyN2R5V0VL?=
 =?utf-8?B?eUE9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4f02654e-76a3-4465-5080-08dd190dc7f3
X-MS-Exchange-CrossTenant-AuthSource: AS2PR03MB8907.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2024 11:28:33.8365
 (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: C+exEZLIp7mwsXGHQvwkXQpV0mzneoTv9B+zUEY3PBRCDcS5WguzJA+L8+FEMRoZcjiBw7eQgPOZmE6WcAi/VA0ZKmn4e/VKeWfjbQrqmJw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7336



On 09.12.24 19:37, Andrei Cherechesu wrote:
> Hi Julien, Grygorii,
> 
> On 11/11/2024 12:33, Julien Grall wrote:
>> Hi,
>>
>> On 01/11/2024 15:22, Grygorii Strashko wrote:
>>> Hi
>>>
>>> I'd be apprcieated if could consider my comments below.
>>>
>>> On 30.09.24 14:47, Andrei Cherechesu (OSS) wrote:
>>>> From: Andrei Cherechesu 
>>>>
>>>> Introduce the SCMI layer to have some basic degree of awareness
>>>> about SMC calls that are based on the ARM System Control and
>>>> Management Interface (SCMI) specification (DEN0056E).
>>>>
>>>> The SCMI specification includes various protocols for managing
>>>> system-level resources, such as: clocks, pins, reset, system power,
>>>> power domains, performance domains, etc. The clients are named
>>>> "SCMI agents" and the server is named "SCMI platform".
>>>>
>>>> Only support the shared-memory based transport with SMCs as
>>>> the doorbell mechanism for notifying the platform. Also, this
>>>> implementation only handles the "arm,scmi-smc" compatible,
>>>> requiring the following properties:
>>>>      - "arm,smc-id" (unique SMC ID)
>>>>      - "shmem" (one or more phandles pointing to shmem zones
>>>>      for each channel)
>>>>
>>>> The initialization is done as 'presmp_initcall', since we need
>>>> SMCs and PSCI should already probe EL3 FW for supporting SMCCC.
>>>> If no "arm,scmi-smc" compatible node is found in Dom0's
>>>> DT, the initialization fails silently, as it's not mandatory.
>>>> Otherwise, we get the 'arm,smc-id' DT property from the node,
>>>> to know the SCMI SMC ID we handle. The 'shmem' memory ranges
>>>> are not validated, as the SMC calls are only passed through
>>>> to EL3 FW if coming from Dom0 and as if Dom0 would be natively
>>>> running.
>>>>
>>>> Signed-off-by: Andrei Cherechesu 
>>>> Reviewed-by: Stefano Stabellini 
>>>> ---
>>>>    xen/arch/arm/Kconfig                |  10 ++
>>>>    xen/arch/arm/Makefile               |   1 +
>>>>    xen/arch/arm/include/asm/scmi-smc.h |  52 +++++++++
>>>>    xen/arch/arm/scmi-smc.c             | 163 ++++++++++++++++++++++++++++
>>>
>>> Could it be moved in separate folder - for example "sci" or "firmware"?
>>> There are definitely more SCMI specific code will be added in the future
>>> as this solution is little bit too simplified.
>>>
>>>>    4 files changed, 226 insertions(+)
>>>>    create mode 100644 xen/arch/arm/include/asm/scmi-smc.h
>>>>    create mode 100644 xen/arch/arm/scmi-smc.c
>>>>
>>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>>>> index 323c967361..adf53e2de1 100644
>>>> --- a/xen/arch/arm/Kconfig
>>>> +++ b/xen/arch/arm/Kconfig
>>>> @@ -245,6 +245,16 @@ config PARTIAL_EMULATION
>>>>          not been emulated to their complete functionality. Enabling this might
>>>>          result in unwanted/non-spec compliant behavior.
>>>> +config SCMI_SMC
>>>
>>> Could you please rename it to clearly specify that it is only dom0/hwdom
>>> specific? Like SCMI_SMC_DOM0 or SCMI_SMC_HW_DOM.
>>
>> I expect this series to be just a stop gap until we support SCMI for the VMs. Once this is merge, I don't expect we would want to keep a Kconfig to allow SCMI just for dom0. Therefore, I am not entirely convinced the proposed new name is a good idea.
> 
> AFAIU, Julien, you don't agree with renaming the config, nor with moving the
> support to a separate folder since it's something temporary? That's my view
> as well.
> 
> These changes do not introduce support for a layer of mediators for
> interacting with system firmware, but only for one simplified implementation.
> So I suppose the patch set that adds that support also creates the folder
> (named 'sci' - per Gregorii's proposal - or 'firmware' to align with Linux),
> and the required config.
> 
> But I'm up for doing whatever you consider more suitable.
> 
>>
>>
>>>
>>>> +    bool "Enable forwarding SCMI over SMC calls from Dom0 to EL3 firmware"
>>>> +    default y
>>>> +    help
>>>> +      This option enables basic awareness for SCMI calls using SMC as
>>>> +      doorbell mechanism and Shared Memory for transport ("arm,scmi-smc"
>>>> +      compatible only). The value of "arm,smc-id" DT property from SCMI
>>>> +      firmware node is used to trap and forward corresponding SCMI SMCs
>>>> +      to firmware running at EL3, if the call comes from Dom0.
>>>> +
>>>>    endmenu
>>>>    menu "ARM errata workaround via the alternative framework"
>>>> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
>>>> index 7792bff597..b85ad9c13f 100644
>>>> --- a/xen/arch/arm/Makefile
>>>> +++ b/xen/arch/arm/Makefile
>>>> @@ -45,6 +45,7 @@ obj-y += platform_hypercall.o
>>>>    obj-y += physdev.o
>>>>    obj-y += processor.o
>>>>    obj-y += psci.o
>>>> +obj-$(CONFIG_SCMI_SMC) += scmi-smc.o
>>>>    obj-y += setup.o
>>>>    obj-y += shutdown.o
>>>>    obj-y += smp.o
>>>> diff --git a/xen/arch/arm/include/asm/scmi-smc.h b/xen/arch/arm/ include/asm/scmi-smc.h
>>>> new file mode 100644
>>>> index 0000000000..c6c0079e86
>>>> --- /dev/null
>>>> +++ b/xen/arch/arm/include/asm/scmi-smc.h
>>>> @@ -0,0 +1,52 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>>>> +/*
>>>> + * xen/arch/arm/include/asm/scmi-smc.h
>>>> + *
>>>> + * ARM System Control and Management Interface (SCMI) over SMC
>>>> + * Generic handling layer
>>>> + *
>>>> + * Andrei Cherechesu 
>>>> + * Copyright 2024 NXP
>>>> + */
>>>> +
>>>> +#ifndef __ASM_SCMI_SMC_H__
>>>> +#define __ASM_SCMI_SMC_H__
>>>> +
>>>> +#include 
>>>> +#include 
>>>> +
>>>> +#ifdef CONFIG_SCMI_SMC
>>>> +
>>>> +bool scmi_is_enabled(void);
>>>> +bool scmi_is_valid_smc_id(uint32_t fid);
>>>> +bool scmi_handle_smc(struct cpu_user_regs *regs);
>>>> +
>>>> +#else
>>>> +
>>>> +static inline bool scmi_is_enabled(void)
>>>> +{
>>>> +    return false;
>>>> +}
>>>> +
>>>> +static inline bool scmi_is_valid_smc_id(uint32_t fid)
>>>> +{
>>>> +    return false;
>>>> +}
>>>> +
>>>> +static inline bool scmi_handle_smc(struct cpu_user_regs *regs)
>>>
>>> I propose to add "struct domain *d" as the first parameter to make it
>>> more abstract from Xen internals.
>>
>> I am not sure to understand why we would want the call to be more abstract. This function should *only* act on the vCPU currently loaded. So it makes sense to use "current->domain".
> 
> So this should stay the same, right?
> 
> @Grygorii,
> 
> Regarding `scmi_is_valid_smc_id()`, I will make it private to the
> SCMI-SMC driver.
> 
> And regarding squashing [v2,4/8] to [v2,3/8], IMO it is clearer
> this way: to have the implementation of the driver in a different
> commit than the usage/refactorings needed to accomodate it. And
> this makes it easier to revert the behaviour too, eventually. But
> I don't have a strong preference on this and I'm open to squash
> the commits if you believe it is better that way.

I'm ok with other comments - means it's up to you and maintainers.

But in my opinion it'll be better to consolidate the scmi code in standalone folder from
the beginning to avoid possible future files moving/renaming. It's optional, new features
and it looks not right to mix it with generic Arm code.

Best regards,
Grygorii



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 11:30:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 11:30:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852182.1266066 (Exim 4.92)
	(envelope-from )
	id 1tKyRd-00075W-9B; Tue, 10 Dec 2024 11:30:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852182.1266066; Tue, 10 Dec 2024 11:30:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tKyRd-00075P-5Y; Tue, 10 Dec 2024 11:30:25 +0000
Received: by outflank-mailman (input) for mailman id 852182;
 Tue, 10 Dec 2024 11:30: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 1tKyRc-00075H-4l
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 11:30:24 +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 2304eded-b6ea-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 12:30:19 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-a9a977d6cc7so805733366b.3
 for ; Tue, 10 Dec 2024 03:30:19 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa6260a3832sm822436766b.166.2024.12.10.03.30.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Dec 2024 03:30: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: 2304eded-b6ea-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733830219; x=1734435019; 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=yCIIPd0459B6cAccuKf52qBHLnigjf0mgiU8nw4HT4s=;
        b=N8v/AvZiZKK7/YlVxEkaQ/9toVkxMqSGt/mEWBghqzlmwCfFMrP2/OTcPkbU9nVyLJ
         xUjA7O/XNn0eDj5A7mjYS9aJBKEXPEoRlrFm8/ol3DIN7RMUMPcqw6f5VewGFEdGRMK2
         pd9Ahou6eZ6lgJMx5rtVgivcIT60uBVYIpOOE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733830219; x=1734435019;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=yCIIPd0459B6cAccuKf52qBHLnigjf0mgiU8nw4HT4s=;
        b=oMVtIHvX7+VP7t72QBkQ3ODkacQTAAoAg0z2iRsHYXBmauurP16gEnzt7ZSC8MhdDB
         WBBTVNSv0z9ykk6VwzY8M+D0Bpwr7jtc8fNOnMBhk60lrXHl00M/SfchbnEM2RmqvGUd
         +eMmA650XjbrZkPpXBzUTJemztQNWS3uwiPv0D9PCq/WjTmL2lrvvlhCtek4C4r07Yr5
         /TGxg/ccScK0SsH8Doo3qkMX+1a/uD8Z34jKhGWzh7kvOnRCHKp+f6XWI3nSIVdfujdT
         JMliAiUQ/L2sQ8HYylZbdyvfFgo7RfX5LtunI/JwGwUeXXsRwvuxAevbgHtxxyqkeqkx
         Q41w==
X-Gm-Message-State: AOJu0YwIQMZ/Nb2knqUVwuT8ZPeLeiWnDHh1UCYOnRJqLq08D6lagvQZ
	EOCqpY71JAB3yOREYzkhrshh+qbCBUUVqd2gnYWi4H0QUZSqR7Sq6d0CYo3U1mk=
X-Gm-Gg: ASbGncuWYPD/nPBeYWUKnSRI+sSxE0QSGgn8dh+zZxoSOi6veBE/GMxWZrmZTzUmMlA
	8gdJVihg4x4MW1iHvc2nnws0Amunfiv9xj8aFZIS7c9zk2hdmcMBussqfFAiPWzlqOW5FGkPQLp
	F9h4HTX6ypRWgAQwR1J3zfL1LAhXyz4AvLK6Jdcvbqi/43RKjYiwSyJZhdRtL+N5QQ4VsMFJCvX
	boOGYbhGAdWtwurMbAGGAbz6MZHuITrCgpIHf/9dN48lT+flsdTkZk0m0D9n/Y=
X-Google-Smtp-Source: AGHT+IGwm1ZsvGprxO0EMIRJrWjFCGFgOD23UCUwso6Vm6r3lrHKZnXhLWg1dCbfkOTixPYFYAZaMQ==
X-Received: by 2002:a05:6402:274d:b0:5d0:9054:b119 with SMTP id 4fb4d7f45d1cf-5d4185d5fb5mr9731519a12.21.1733830217787;
        Tue, 10 Dec 2024 03:30:17 -0800 (PST)
Date: Tue, 10 Dec 2024 12:30:16 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	Huang Rui 
Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support
Message-ID: 
References: <20241202060956.1124162-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241202060956.1124162-1-Jiqian.Chen@amd.com>

On Mon, Dec 02, 2024 at 02:09:56PM +0800, Jiqian Chen wrote:
> Some devices, like discrete GPU of amd, support resizable bar
> capability, but vpci of Xen doesn't support this feature, so
> they fail to resize bars and then cause probing failure.
> 
> According to PCIe spec, each bar that supports resizing has
> two registers, PCI_REBAR_CAP and PCI_REBAR_CTRL. So, add
> handlers for them to support resizing the size of BARs.
> 
> Signed-off-by: Jiqian Chen 
> ---
> Hi all,
> 
> v2->v1 changes:
> *In rebar_ctrl_write, to check if memory decoding is enabled, and added
> some checks for the type of Bar.
> *Added vpci_hw_write32 to handle PCI_REBAR_CAP's write, since there is
> no write limitation of dom0.
> *And has many other minor modifications as well.
> 
> Best regards,
> Jiqian Chen.
> ---
>  xen/drivers/vpci/Makefile  |  2 +-
>  xen/drivers/vpci/rebar.c   | 93 ++++++++++++++++++++++++++++++++++++++
>  xen/drivers/vpci/vpci.c    |  6 +++
>  xen/include/xen/pci_regs.h | 11 +++++
>  xen/include/xen/vpci.h     |  2 +
>  5 files changed, 113 insertions(+), 1 deletion(-)
>  create mode 100644 xen/drivers/vpci/rebar.c
> 
> diff --git a/xen/drivers/vpci/Makefile b/xen/drivers/vpci/Makefile
> index 1a1413b93e76..a7c8a30a8956 100644
> --- a/xen/drivers/vpci/Makefile
> +++ b/xen/drivers/vpci/Makefile
> @@ -1,2 +1,2 @@
> -obj-y += vpci.o header.o
> +obj-y += vpci.o header.o rebar.o
>  obj-$(CONFIG_HAS_PCI_MSI) += msi.o msix.o
> diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
> new file mode 100644
> index 000000000000..156e8d337426
> --- /dev/null
> +++ b/xen/drivers/vpci/rebar.c
> @@ -0,0 +1,93 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (C) 2024 Advanced Micro Devices, Inc. All Rights Reserved.
> + *
> + * Author: Jiqian Chen 
> + */
> +
> +#include 
> +#include 
> +
> +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
> +                                      unsigned int reg,
> +                                      uint32_t val,
> +                                      void *data)
> +{
> +    uint64_t size;
> +    unsigned int index;
> +    struct vpci_bar *bars = data;
> +
> +    if ( pci_conf_read16(pdev->sbdf, PCI_COMMAND) & PCI_COMMAND_MEMORY )
> +        return;
> +
> +    index = pci_conf_read32(pdev->sbdf, reg) & PCI_REBAR_CTRL_BAR_IDX;
> +    if ( index >= PCI_HEADER_NORMAL_NR_BARS )
> +        return;
> +
> +    if ( bars[index].type != VPCI_BAR_MEM64_LO &&
> +         bars[index].type != VPCI_BAR_MEM32 )
> +        return;

For those early returns that don't propagate the write to the
register, we need to log a message to notice the write has been
dropped, otherwise there's no way to identify such cases.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 12:15:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 12:15:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852223.1266075 (Exim 4.92)
	(envelope-from )
	id 1tKz8r-0005ES-HH; Tue, 10 Dec 2024 12:15:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852223.1266075; Tue, 10 Dec 2024 12:15:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tKz8r-0005EL-Ed; Tue, 10 Dec 2024 12:15:05 +0000
Received: by outflank-mailman (input) for mailman id 852223;
 Tue, 10 Dec 2024 12:15: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 1tKz8q-0005EF-Se
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 12:15:04 +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 621f79e7-b6f0-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 13:15:02 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-434e69857d9so18468325e9.0
 for ; Tue, 10 Dec 2024 04:15:02 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-435d4cd4a78sm15432415e9.28.2024.12.10.04.15.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 04:15: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: 621f79e7-b6f0-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733832902; x=1734437702; 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=VN/XkDuVaTjolMOyGf7nGyHdqQnIcuNJJVWfTZMVHSA=;
        b=N+NM4r9hNymfzVRw/rtgXXStVHL2Gw9lGD/AFnOkXIqqnrSc+XGQEaVSLhd5asGoJi
         vptJpykasJjFkyRonmtmoLX8tRLASRoJJHUZZsTAo2MhHNh03rRC2gra2D+ZdUsGbtdR
         20vITjb5q+XGpSHfQQzYOUE797kANefL5x7M9ZSAegfw2ZvQPTb1UPPz/5ML0PAH/uGs
         AiqUH2NaynlY1ib1pYOMkaVCMlMLw25Jhb3SWTukKuxoJPES7GK/PM+/mB3MEb0luCzm
         l7mJqDCh5/fgmXvHcQ0yD1Z4a0RkeEbvw8ZjEK8itSoq7Dke/VmFmulpQt+jhS/JTleI
         v9kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733832902; x=1734437702;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=VN/XkDuVaTjolMOyGf7nGyHdqQnIcuNJJVWfTZMVHSA=;
        b=nxMHyoPxm69dAh3bt2vpiP2+bpWkqahMlZ7aRZL0jb5eKMk8SIRMEcY2+GEulAsHfa
         5jOxhNnFLJqVJDVwgYT5Xp11l1CFDuVHx0vj8u5XsKxETlrveZ13riHUgqYDTx/GOAPw
         emKBElYhKs0fMTPivo0hylbCir3wOwJ+DZmACkcH4iBV71ApDpdbU/gPwDvLPSMLnMIt
         BvTSLu2Ywt9WSJbEIiSjb6+ULKQWdGKrNLD40k6XWxhdlT1SH7xPpkvPcjISSBykuJvq
         VNBq+GEiAjHbWY6OfnTbp8UuSBBlfemRiuOvltVMsW4MCaKkbB52YSjWa5UFhB96YBpE
         E2Vg==
X-Forwarded-Encrypted: i=1; AJvYcCUSF2TCbIQn78d3WtPluItu0O2dlFiDZeoY8rD1SQVJstmzgnDBLLhTnfA1z4n8rdGfLG9zDG0DwcY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwEOntdSrLNUKK/JBR2Q6c0ewnvi5P/gOCs49bnjAixnlPzxPZW
	V7KXvjmzx+gOPY9T2LrQfv+ctPY0uhogtn68/t/02Ca4B1Gk37UidtTRzpHDSQ==
X-Gm-Gg: ASbGnctQsJxZykvblLTWa6O7A1H7HLHITz29S8wp5ToCAxWAFnqPg3BnV9Di+2givYT
	FmcipfS79Jy9vUyi9zAYiaCiMZ5jHT2DLctri6SY8WYrLwSRGZJ6Uhd1UHSotpHLh7onHifltR+
	VUfcgh+4Tj98ne74Tg+uJz1wEolOvZKVrtNzk1eNf44f7D/l00fjllupxQQ9cDjH5DVQ7kltiRJ
	/gXKfX/AEXTijdG9A03yevAUU31+k+w33L0fqhwvq9QpbjpF9Ifr03c91Pd7fXvdSveINL2+d9H
	K3Ew3wMs00f9WUi++it1hJ2HBk/BReMxKz9TYydp4xZDCuYXZOMK99CjayqL17Fs73zYr44YRIm
	b4sZLblmysg==
X-Google-Smtp-Source: AGHT+IESlpRT9UqqU1MpPU2RVpcxcxGVuYoc9i+dSELlevqa/ftR1J9ZyoIBmRo42ahrwYs7YaTujA==
X-Received: by 2002:a05:600c:4ed2:b0:434:e69c:d338 with SMTP id 5b1f17b1804b1-43502182706mr21046805e9.5.1733832902136;
        Tue, 10 Dec 2024 04:15:02 -0800 (PST)
Message-ID: 
Date: Tue, 10 Dec 2024 13:15:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "Chen, Jiqian" ,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini , "Huang, Ray"
 ,
 "xen-devel@lists.xenproject.org" 
References: <20241202060956.1124162-1-Jiqian.Chen@amd.com>
 <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com>
 
 <1e0576d9-400e-4483-8dd1-061e215a00cd@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.12.2024 12:25, Roger Pau Monné wrote:
> On Tue, Dec 10, 2024 at 10:54:43AM +0100, Jan Beulich wrote:
>> On 10.12.2024 08:57, Chen, Jiqian wrote:
>>> On 2024/12/10 15:17, Jan Beulich wrote:
>>>> On 10.12.2024 08:07, Chen, Jiqian wrote:
>>>>> On 2024/12/9 21:59, Jan Beulich wrote:
>>>>>> On 02.12.2024 07:09, Jiqian Chen wrote:
>>>>>>> +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
>>>>>>> +                                      unsigned int reg,
>>>>>>> +                                      uint32_t val,
>>>>>>> +                                      void *data)
>>>>>>> +{
>>>>>>> +    uint64_t size;
>>>>>>> +    unsigned int index;
>>>>>>> +    struct vpci_bar *bars = data;
>>>>>>> +
>>>>>>> +    if ( pci_conf_read16(pdev->sbdf, PCI_COMMAND) & PCI_COMMAND_MEMORY )
>>>>>>> +        return;
>>>>>>
>>>>>> I don't think something like this can go uncommented. I don't think the
>>>>>> spec mandates to drop writes in this situation?
>>>>> Spec says: Software must clear the Memory Space Enable bit in the Command register before writing the BAR Size field.
>>>>> This check is suggested by Roger and it really helps to prevent erroneous writes in this case,
>>>>> such as the result of debugging with Roger in the previous version.
>>>>> I will add the spec's sentences as comments here in next version.
>>>>
>>>> What you quote from the spec may not be enough as a comment here. There's
>>>> no direct implication that the write would simply be dropped on the floor
>>>> if the bit is still set. So I think you want to go a little beyond just
>>>> quoting from the spec.
>>> How about quoting Roger's previous words: " The memory decoding must be disabled before writing the BAR size field.
>>> Otherwise changing the BAR size will lead to the active p2m mappings getting out of sync w.r.t. the new BAR size." ?
>>
>> That'll be better, but imo still not enough to explain the outright ignoring
>> of the write.
> 
> I think we might want to do something along the lines of:
> 
> uint64_t size = PCI_REBAR_CTRL_SIZE(val);
> struct vpci_bar *bar = data;
> 
> if ( bar->enabled )
> {
>     if ( size == bar->size )
>         return;
> 
>     /*
>      * Refuse to resize a BAR while memory decoding is enabled, as
>      * otherwise the size of the mapped region in the p2m would become
>      * stale with the newly set BAR size, and the position of the BAR
>      * would be reset to undefined.  Note the PCIe specification also
>      * forbids resizing a BAR with memory decoding enabled.
>      */
>     gprintk(XENLOG_ERR,
>             "%pp: refuse to resize BAR with memory decoding enabled\n",
> 	    &pci->sbdf);
>     return;
> }
> 
> Note this requires that the data parameter points to the BAR that
> matches the ReBAR control register, this needs adjusting in
> init_rebar().

SGTM.

>>>>>>> +        if ( rc )
>>>>>>> +        {
>>>>>>> +            printk("%pp: add register for PCI_REBAR_CAP failed (rc=%d)\n",
>>>>>>> +                   &pdev->sbdf, rc);
>>>>>>> +            break;
>>>>>>> +        }
>>>>>>> +
>>>>>>> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
>>>>>>> +                               rebar_offset + PCI_REBAR_CTRL, 4,
>>>>>>> +                               pdev->vpci->header.bars);
>>>>>>> +        if ( rc )
>>>>>>> +        {
>>>>>>> +            printk("%pp: add register for PCI_REBAR_CTRL failed %d\n",
>>>>>>> +                   &pdev->sbdf, rc);
>>>>>>> +            break;
>>>>>>
>>>>>> Is it correct to keep the other handler installed? After all ...
>>>>> Will change to "return rc;" here and above in next version.
>>>>
>>>> I'm not convinced this is what we want, as per ...
>>>>
>>>>>>> +        }
>>>>>>> +    }
>>>>>>> +
>>>>>>> +    return 0;
>>>>>>
>>>>>> ... you - imo sensibly - aren't communicating the error back up (to allow
>>>>>> the device to be used without BAR resizing.
>>>>
>>>> ... what I said here.
>>> Sorry, I didn’t understand.
>>> Do you mean it is not enough to return error code once a handler failed to be installed, I need to remove the already installed handlers?
>>
>> No, if you return an error here, nothing else needs doing. However, I
>> question that returning an error here is good or even necessary. In
>> the event of an error, the device ought to still be usable, just
>> without the BAR-resizing capability.
> 
> So you suggest that the capability should be hidden in that case?

Yes.

>  We
> have logic to hide capabilities, just not used for the hardware
> domain.  It would need some extra wiring to be capable of hiding
> failed capabilities.

Indeed.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 12:19:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 12:19:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852234.1266086 (Exim 4.92)
	(envelope-from )
	id 1tKzDQ-0005p2-2D; Tue, 10 Dec 2024 12:19:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852234.1266086; Tue, 10 Dec 2024 12: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 1tKzDP-0005ov-Vc; Tue, 10 Dec 2024 12:19:47 +0000
Received: by outflank-mailman (input) for mailman id 852234;
 Tue, 10 Dec 2024 12:19: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 1tKzDP-0005op-CA
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 12:19:47 +0000
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com
 [2a00:1450:4864:20::12a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0b2b965d-b6f1-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 13:19:46 +0100 (CET)
Received: by mail-lf1-x12a.google.com with SMTP id
 2adb3069b0e04-54025432becso903080e87.1
 for ; Tue, 10 Dec 2024 04:19:46 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5401d2aab5csm721225e87.168.2024.12.10.04.19.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 04:19: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: 0b2b965d-b6f1-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1733833186; x=1734437986; darn=lists.xenproject.org;
        h=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=LgcqTNrVfOBJ9uwgrvP3jJcEtD74Nx2GTUvqY74CY+4=;
        b=NErQiXQuvKYW21TilPqAPjd3jb+wB9Xg1KwSb9jGvQTCZJaiVZni/cxEpQFSsBOfcS
         NT89cwT0aQDCMUz0VlyQ2LUE8z9e9Sf6Zjf51Fv1kSz4oz/uyvOuGCSoHPObpbqGEtEz
         QTb8uiEvoR9lh7vSgAyTVFBGT7UfSI1wKhFv52MsEZIhK+xcRWOx/OJsEw9zr1qFH6RK
         hwfGIPjamV9jIpQdX6pZ+mBpQeQ8t+8ixNada1v3MFZ522Du0J9RerwrMxLLq53Z4KMe
         UAa0XX1kWI+Hv46pILawHvAKj2vsNDrMf1bHFIETO+zbmoiXIA56s1bX9QxmoC5/ySfA
         1eNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733833186; x=1734437986;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=LgcqTNrVfOBJ9uwgrvP3jJcEtD74Nx2GTUvqY74CY+4=;
        b=cC3AbD7+xBUu+lekCQGQgH+ihr6/qgC9lSSNz8SE0oXKpeDuZ5P6c7hFmQ2ZNGrYl9
         87CFl8vQqIe+YW7XvqoSW760MtaNXwuGuxxx6G1IjHZsPyTwa9a9e6QH9obSfY5ZDZoB
         YPBjTwfdBTvv3qq1uFBPW3eXVKlWMgXY/4dfkeIHChB1AcnDxI3ea1ToogwrHF0P/Gca
         c9iN7GXAnjPGbOSbxSAi2vf2ifKY6a7rW7wML4V/7kJR1L3/SSBhuI6qj9vYW5+EGDyx
         DzCtvnuDUmfS3VluJvlGDzt9xxUhm+b6q7+vKUDtj1zf/z6KfXm7gYdaUZzpTAqKi4p5
         Qi3w==
X-Forwarded-Encrypted: i=1; AJvYcCV3MnqqTNZ/X1u6C3/Ltm2uLFY+PE9YLVqsdBdbpN0aOZ3FlXVAQz69Kd5nkvYPG0ITi0asR0secNc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzOA4o3oavOpIUNVQUe1U0BfUbM4QZDke0S3u0uImOogtu5ssPO
	RxvJMeDzHRI3xaF19y7mnwt5iZC2fToy0+cp6Aw1SUwfGm2q228k
X-Gm-Gg: ASbGncuBpVIKrRKAzN7Sl2X9u4Z5nLCiosOxhqnSHgZXtx3qjMwHrMFFBl+FyUEPsQC
	XriRQa0BrO5nahRo9UA5ks1+5muTZNQDhIcFR6LEIcpQX1/r3i8WcvzelGi+hEcyO7zM08jJ5f5
	KvbI8W2A3pEf8W7k0jsXQQ39oK/Py3KeBkUxHpV5w2qXkwfsiGkl4Ht9o2awZLCPK+GQxZpfnMi
	sPqqlKvSFHq6ajJazhihAuG1tPCYPChqywIwKY5bOQSZwYXXPeUNlRJk4qPrBrRrYQ=
X-Google-Smtp-Source: AGHT+IH3Mqx6wcZJQ8KT9JLikkYEvGtdVJ5len2jFu7r4XW6F6I79x4gGoHLEmQqwajtY+NAGrsbHA==
X-Received: by 2002:a05:6512:318e:b0:53e:39f0:4bbd with SMTP id 2adb3069b0e04-540240c982amr1388787e87.21.1733833185342;
        Tue, 10 Dec 2024 04:19:45 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------jmoKaTs5QomEdFFe7PM0f7KF"
Message-ID: 
Date: Tue, 10 Dec 2024 13:19:44 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 4/6] xen/riscv: introduce cache management operations
 (CMO)
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: 
 <1310a2fb3b9824ae66f850600925127fdfdb44fa.1732709650.git.oleksii.kurochko@gmail.com>
 <9d49befe-4592-4e71-ad0b-9a0af34253f5@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <9d49befe-4592-4e71-ad0b-9a0af34253f5@suse.com>

This is a multi-part message in MIME format.
--------------jmoKaTs5QomEdFFe7PM0f7KF
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 12/9/24 3:38 PM, Jan Beulich wrote:
> On 27.11.2024 13:50, Oleksii Kurochko wrote:
>> --- a/xen/arch/riscv/Kconfig
>> +++ b/xen/arch/riscv/Kconfig
>> @@ -14,6 +14,9 @@ config ARCH_DEFCONFIG
>>   	string
>>   	default "arch/riscv/configs/tiny64_defconfig"
>>   
>> +config HAS_CMO # Cache Management Operations
>> +	bool
> Hmm, and nothing ever sets this, and hence ...
>
>> @@ -148,9 +149,24 @@ static inline bool pte_is_mapping(pte_t p)
>>       return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK);
>>   }
>>   
>> +#ifndef HAS_CMO
>> +static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
>> +{
>> +    return -EOPNOTSUPP;
>> +}
>> +
>> +static inline int clean_dcache_va_range(const void *p, unsigned long size)
>> +{
>> +    return -EOPNOTSUPP;
>> +}
>> +#else
>> +int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size);
>> +int clean_dcache_va_range(const void *p, unsigned long size);
>> +#endif
> ... all you really provide are stubs and declarations, but no
> definition anywhere?

Yes, this was done intentionally because:
- I don't have hardware with the CMO extension, so I can't test it. ( QEMU doesn't model cache and so
   there is no need for CMO extension emulation IIUC )
- The instructions used for these functions may be hardware-specific and exist only for particular devices.

It seems useful to have something similar to Linux:
https://elixir.bootlin.com/linux/v6.6.64/source/arch/riscv/include/asm/errata_list.h#L135 
(There are also custom instructions for THEAD above this macro.)

We could use|ALT_CMO_OP(...)| inside|clean_and_invalidate_dcache_va_range()| and|clean_dcache_va_range()|.
However, I think it would be better to introduce or implement these functions when|HAS_CMO| is set to|y| someday.

As an alternative, we could implement these functions as|panic("need to be implemented\n")| in case when HAS_CMO=y.

Another option is to drop|HAS_CMO| entirely for now and keep the current implementation (|return -EOPNOTSUPP|).
However, with this approach, there's a risk of encountering hard-to-debug issues on platforms with the CMO extension.
And necessity of implementation of these could be missed because there is no any notification...

>
> Plus of course this gets us into feature detection territory again: If
> RISC-V provided a way to detect presence / absence of certain extensions,
> this really shouldn't be a compile time setting, but be determined
> dynamically.

This is the next patch I plan to send after this patch series:
https://gitlab.com/xen-project/people/olkur/xen/-/commit/f81ae67c42854073da5403210c9e31de6b0ee5bd 

It "detects" available extensions based on a device tree property. While this is not the best approach
(the ideal solution would be hardware having a register that lists all available extensions), it seems to be
the best option available at the moment.

Another option I considered was introducing a new SBI call, delegating the responsibility to OpenSBI
to provide this information.

>
>>   static inline void invalidate_icache(void)
>>   {
>> -    BUG_ON("unimplemented");
>> +    asm volatile ( "fence.i" ::: "memory" );
>>   }
> That's a separate extension, Zifencei, which I don't think you can just
> assume to be present?

Based on the specification:
```
Chapter 34. RV32/64G Instruction Set Listings
One goal of the RISC-V project is that it be used as a stable software development target. For this
purpose, we define a combination of a base ISA (RV32I or RV64I) plus selected standard extensions
(IMAFD, Zicsr, Zifencei) as a "general-purpose" ISA, and we use the abbreviation G for the
IMAFDZicsr_Zifencei combination of instruction-set extensions. This chapter presents opcode maps
and instruction-set listings for RV32G and RV64G
```
and that G is needed to boot Linux kernel ( and so Xen ) I make an assumption that Zifencei will be always
present.

And based on Linux code (https://elixir.bootlin.com/linux/v6.12.4/source/arch/riscv/kernel/cpufeature.c#L676 )
when 'i' is present in riscv,isa property zifencei is present unconditionally.

~ Oleksii

--------------jmoKaTs5QomEdFFe7PM0f7KF
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    


    

    
On 12/9/24 3:38 PM, Jan Beulich wrote:

    

    

      
On 27.11.2024 13:50, Oleksii Kurochko wrote:


      

        
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -14,6 +14,9 @@ config ARCH_DEFCONFIG
 	string
 	default "arch/riscv/configs/tiny64_defconfig"
 
+config HAS_CMO # Cache Management Operations
+	bool


      

      
Hmm, and nothing ever sets this, and hence ...



      

        
@@ -148,9 +149,24 @@ static inline bool pte_is_mapping(pte_t p)
     return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK);
 }
 
+#ifndef HAS_CMO
+static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
+{
+    return -EOPNOTSUPP;
+}
+
+static inline int clean_dcache_va_range(const void *p, unsigned long size)
+{
+    return -EOPNOTSUPP;
+}
+#else
+int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size);
+int clean_dcache_va_range(const void *p, unsigned long size);
+#endif


      

      
... all you really provide are stubs and declarations, but no
definition anywhere?

    

    
Yes, this was done intentionally because:
- I don't have hardware with the CMO extension, so I can't test it. ( QEMU doesn't model cache and so
  there is no need for CMO extension emulation IIUC )
- The instructions used for these functions may be hardware-specific and exist only for particular devices.



    
It seems useful to have something similar to Linux:
https://elixir.bootlin.com/linux/v6.6.64/source/arch/riscv/include/asm/errata_list.h#L135
(There are also custom instructions for THEAD above this macro.)

    
We could use ALT_CMO_OP(...) inside clean_and_invalidate_dcache_va_range() and clean_dcache_va_range().
However, I think it would be better to introduce or implement these functions when HAS_CMO is set to y someday.



    
As an alternative, we could implement these functions as panic("need to be implemented\n") in case when HAS_CMO=y.

Another option is to drop HAS_CMO entirely for now and keep the current implementation (return -EOPNOTSUPP).
However, with this approach, there's a risk of encountering hard-to-debug issues on platforms with the CMO extension.
And necessity of implementation of these could be missed because there is no any notification...



    

      

Plus of course this gets us into feature detection territory again: If
RISC-V provided a way to detect presence / absence of certain extensions,
this really shouldn't be a compile time setting, but be determined
dynamically.

    

    
This is the next patch I plan to send after this patch series:
https://gitlab.com/xen-project/people/olkur/xen/-/commit/f81ae67c42854073da5403210c9e31de6b0ee5bd

    
It "detects" available extensions based on a device tree property. While this is not the best approach
(the ideal solution would be hardware having a register that lists all available extensions), it seems to be
the best option available at the moment.

    
Another option I considered was introducing a new SBI call, delegating the responsibility to OpenSBI
to provide this information.

    

    

      



      

        
 static inline void invalidate_icache(void)
 {
-    BUG_ON("unimplemented");
+    asm volatile ( "fence.i" ::: "memory" );
 }


      

      
That's a separate extension, Zifencei, which I don't think you can just
assume to be present?

    

    
Based on the specification:
```
Chapter 34. RV32/64G Instruction Set Listings
One goal of the RISC-V project is that it be used as a stable software development target. For this
purpose, we define a combination of a base ISA (RV32I or RV64I) plus selected standard extensions
(IMAFD, Zicsr, Zifencei) as a "general-purpose" ISA, and we use the abbreviation G for the
IMAFDZicsr_Zifencei combination of instruction-set extensions. This chapter presents opcode maps
and instruction-set listings for RV32G and RV64G
```
and that G is needed to boot Linux kernel ( and so Xen ) I make an assumption that Zifencei will be always
present.

And based on Linux code ( https://elixir.bootlin.com/linux/v6.12.4/source/arch/riscv/kernel/cpufeature.c#L676 )
when 'i' is present in riscv,isa property zifencei is present unconditionally.

~ Oleksii


  


--------------jmoKaTs5QomEdFFe7PM0f7KF--


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 12:22:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 12:22:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852246.1266096 (Exim 4.92)
	(envelope-from )
	id 1tKzFc-0007Ni-E5; Tue, 10 Dec 2024 12:22:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852246.1266096; Tue, 10 Dec 2024 12:22:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tKzFc-0007Nb-B7; Tue, 10 Dec 2024 12:22:04 +0000
Received: by outflank-mailman (input) for mailman id 852246;
 Tue, 10 Dec 2024 12:22: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 1tKzFa-0007NT-Px
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 12:22:02 +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 5bd79948-b6f1-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 13:22:01 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3863703258fso1648820f8f.1
 for ; Tue, 10 Dec 2024 04:22:01 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3861ecf4087sm16087832f8f.5.2024.12.10.04.22.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 04:22: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: 5bd79948-b6f1-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733833321; x=1734438121; 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=tayK09O9V2YvhZOVOPCZMeyApOgLsEm6NDR9iprI1IQ=;
        b=QMA1n5mJO4u0+Uy9uHCV+KahHFNT12AOJg62pXhv0UwC6FiJZBb2RRs3bjCaY0xtCK
         gtdSg4SJkDM8vY7twJ7jUIumf19U+POu4uhlRoY+Y49bFGYaM5hUzWRAa/0Qh9JYO+Hf
         W0NilWC2miy8p04VkHxJ56SLD1/0i+TTo0ditpM6EyDaO+4dWTGGqv3hHZB9WJKtWq6v
         rGYQh2ub/X6ViUIjhWxy5zge7QioJKAKrnMsxFHfpcXwv7j4ztz49m85n1z3+YI1dw9J
         zhcCujtXAfQ4gSRnXiDWlCNhgOtgs21DP4WbpcN9uYD4pSyAUuMOrP5Cnfvl/Jmb0rAV
         jhkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733833321; x=1734438121;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=tayK09O9V2YvhZOVOPCZMeyApOgLsEm6NDR9iprI1IQ=;
        b=Qfenc/fEqyK06Q5XKGU7vVhAIZ2hCKT/ukKJ0TtdvHTtqSF2WV5GuggLeHWlf8zD8b
         Fi/qkMCWufrPv1fqCId0mc9fpqjtAsoR5zSjROAgeldcvLIkbCVxijf/mVGlhiWJlN0/
         FqEFirvLtaB5xpydHIGtHSJ8yh6XxgLK7vheVHTLNT1VS7fl3ozN0F7ZSzPxSTkB+Gpp
         u5KurwojcX6H6gkQo1Cmcng9ArrCRIholQg4i8r6w+w7Eoo2lnF4+3J8ITgUHS/s+YlR
         DNMmmj3n8GOB8XVKSPXkxyBIX8tJ0YjgyU+DWlYmsWsFXWlsB/4BI8zEp3JkzaiI/6A7
         u+Eg==
X-Forwarded-Encrypted: i=1; AJvYcCUNz/pawwyYEwDyRW5FrnmM/nmBro9xAr1B+NcNdXcs7SgOoNS+42KnYSFL7dPHBHWWIGyyWguiVMY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwLTFSKd5dxFEW5usKM2PC7DRrSWGsmGXcWNBwWW/Vg9jF1kuRe
	dEY1E78uHAulbabRiYq0eq6HK3Yyr2+KhgAI61x467Z3kc1lqHcboxw99//TRQ==
X-Gm-Gg: ASbGncvQntFlq48snibK9MfpNpIE3uLsH34mqu9dJjB0HUBRg18TrciCE6Nr/USwziW
	fOsW1kVQYOX89MpWrB36yPwxH3Lbj5AIRUs9IT3WV8jqftBM7Lij4pqdCTV8AQYPYoIVUNU3g6g
	SoB9vyMhp7WjSaQH9Ml7EUXXXh6qZAIfG4TyWmXPbQh5aShutKEpayekEtPQ3ibj2YOmXKC5UjP
	YqmFafLf71509gtUfxdb3oUqLZ5FhKKZnl9gaOgj1kq6C6s8M2jkCcxwhgnQGRX8QW8nRf7YWV0
	20Vnz9dBSADGW20YcE1KP8pxBiY+k5nNuajzYPUHbcCVZEMF9PPAxzOYB1M7plunKv7ZUshAEDV
	m3k4CrJb3Dg==
X-Google-Smtp-Source: AGHT+IHBff18TpQrZ7l55qRtfAJPv8Riv8OkT9BgpM5nJv1K477QQe9EvbhsZgOyVTrAuZUfS2uJgQ==
X-Received: by 2002:a05:6000:154c:b0:386:3213:5b80 with SMTP id ffacd0b85a97d-386469e9a9fmr2247470f8f.24.1733833321227;
        Tue, 10 Dec 2024 04:22:01 -0800 (PST)
Message-ID: 
Date: Tue, 10 Dec 2024 13:21:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 1/6] xen/riscv: add destroy_xen_mappings() to remove
 mappings in Xen page tables
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: 
 
 <0640888f-3b9d-4f5c-9797-856374f16155@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.12.2024 12:14, Oleksii Kurochko wrote:
> 
> On 12/9/24 3:23 PM, Jan Beulich wrote:
>> On 27.11.2024 13:50, Oleksii Kurochko wrote:
>>> Introduce the destroy_xen_mappings() function, which removes page
>>> mappings in Xen's page tables between a start address s and an end
>>> address e.
>>> The function ensures that both s and e are page-aligned
>>> and verifies that the start address is less than or equal to the end
>>> address before calling pt_update() to invalidate the mappings.
>>> The pt_update() function is called with INVALID_MFN and PTE_VALID=0
>>> in the flags, which tell pt_update() to remove mapping. No additional
>>> ASSERT() is required to check these arguments, as they are hardcoded in
>>> the call to pt_update() within destroy_xen_mappings().
>>>
>>> Signed-off-by: Oleksii Kurochko
>> Acked-by: Jan Beulich
>>
>> However, ...
>>
>>> --- a/xen/arch/riscv/pt.c
>>> +++ b/xen/arch/riscv/pt.c
>>> @@ -421,6 +421,14 @@ int map_pages_to_xen(unsigned long virt,
>>>       return pt_update(virt, mfn, nr_mfns, flags);
>>>   }
>>>   +int destroy_xen_mappings(unsigned long s, unsigned long e)
>>> +{
>>> +    ASSERT(IS_ALIGNED(s, PAGE_SIZE));
>>> +    ASSERT(IS_ALIGNED(e, PAGE_SIZE));
>>> +    ASSERT(s <= e);
>>> +    return pt_update(s, INVALID_MFN, PFN_DOWN(e - s), 0);
>>> +}
>> ... I'm unconvinced the constraints need to be this strict. You could,
>> for example, very well just avoiding to call pt_update() when s > e
>> (or really when s >= e). Thoughts?
> 
> On one hand, we could simply avoid calling |pt_update()|, but on the other hand, this approach might cause us to miss a bug without any notification.
> 
> Given that this is an|ASSERT()| that only triggers in debug builds and is unlikely to occur,
> I believe it is not critical to include the|ASSERT()| here.

Right, and that is one of the points. In release builds a potential
bad call here wouldn't be prevented if there's just an assertion.
Unlike if there was an if() instead (perhaps with ASSERT_UNREACHABLE()
on its "else" path).

> Additionally, avoiding an extra
> |if| condition helps prevent any potential performance impact. However, the|if| condition
> would likely evaluate to true most of the time, allowing hardware optimizations to handle
> it efficiently.

I don't think we need to be afraid of performance issues here.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 12:39:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 12:39:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852266.1266105 (Exim 4.92)
	(envelope-from )
	id 1tKzWS-0001Dg-V0; Tue, 10 Dec 2024 12:39:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852266.1266105; Tue, 10 Dec 2024 12:39: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 1tKzWS-0001DZ-Ro; Tue, 10 Dec 2024 12:39:28 +0000
Received: by outflank-mailman (input) for mailman id 852266;
 Tue, 10 Dec 2024 12:39: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 1tKzWR-0001DT-Cc
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 12:39:27 +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 ca6fd7da-b6f3-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 13:39:26 +0100 (CET)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-3862d161947so2672682f8f.3
 for ; Tue, 10 Dec 2024 04:39:26 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-434eba653a0sm115534275e9.22.2024.12.10.04.39.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 04:39: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: ca6fd7da-b6f3-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733834366; x=1734439166; 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=nQnCOqjD9HNe0OPZOevfaMkGzBLAhpg7NAJMwx3emW4=;
        b=OXKBnyWpwJAKvnMsgggCvsr9X82qhJwsp7MScXbQsk6Uvo+r8/nvMInOyU0AS0P86i
         sX9UMntYm1Nw1UyquZaFK9DtISpUliClapEbn8oj9fLIvd2Ea2bGyN4+sC0l/YgUdL0D
         tdw0KiikaMVXU6Siq1Our4F9No3Jr0y6adE0BtkmwJ3s3VlOQh6ct1iHm5TSaHfjixnt
         vw+6H9Zo9gpM8WA1pH9Pjbs8/QYhixG5widFlC3hhsFGKYRophmAxd9dw5V7F/wfVNTP
         mhox8tBp3ZKNZTTUxQreW7Yf7IMdE7WH75Mh//mvlEwQKZriONhuMY9ngU71zvqIUe6B
         Z7Xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733834366; x=1734439166;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nQnCOqjD9HNe0OPZOevfaMkGzBLAhpg7NAJMwx3emW4=;
        b=QDieXVsUwATto+fUgcUmibv36EXZKFYq9Sq7GqpZX353nwBRonmony1UQHENZ341Zo
         nyI6gJXFYagKZ9xfSvUtI3isk8f05Hq6jukjPmPBvhI2vIsRW0g9wKd72BDV+5jeZ8NN
         6WLG05n6dd96FdNbl0si5MuDkCcRcgyvOMh19crmwMl1/E63DljvyZadVMyLtjpUHCd0
         D5BNTOy1ZM3a+3u8UUyywHmgXiGS4v/XQvNFnCcRi8TF42GLfYuQoUZzJOhbCYQiqUfD
         /7EVtlP5U26IicnvD64XelTXblePJBm8QjIVoPh+zY3TSSk4nHSEv6+sp+CmXiCIhALH
         RS7g==
X-Forwarded-Encrypted: i=1; AJvYcCXOg4Yyup+axYVTepIx3axnC4vR7t8AILyC6tKqBA1oPiXmNivuIy+V0rDVyhWdPyCNFtO1IFatHrA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzyBHGVgYxcg4CdGCnpnbWiRJE5dkRY2Ow7Pe3L4pLcREHzogq1
	B6AT2di11vLQoY8PJt2nxfezrelRF0qH1LfQt2k/Rvfi7xKwGGN7chfQFOLjWA==
X-Gm-Gg: ASbGncv3avOIz8uOpmEeR7fShT65Y2DvK63gJ0E+0tFY2y6egR7yypxQ1Iur5NsUft3
	TfSdlm3FYx6k5laApeGUUkvR+wqXP9nIOaqNtRuwJ6JgrCX9Z8RRogfr2/oDmmzm8Wuq6tnFYuV
	UrsaG/d45lx0ETZ/a6rOU0eWmqbmwnZV4wZ1Jc3pwat1zQzD0YvmljqTTqwedN9PxLz3TTu8Yto
	v7F2U89Rnx4/Y94OuYzOtTkQR/D0kP/DDe8+x/zadTawMG/NW424gbGiDFft7Wg5ndAkhP7x5A0
	BYiSh0CyEpmER08jPvsKiujcyJLNdjiFe3nPUnGDvJEA+I3aOmD/efLIIhI33o1MCbeaWvSzzWJ
	NsAkflPM0XA==
X-Google-Smtp-Source: AGHT+IF08IQmU458koaI7BcoexpauYQv3EpG09qh+uRyfrLGzT1+7z4olE/29xgJfIrmB+HYaza1rw==
X-Received: by 2002:a05:6000:4028:b0:386:4acd:4d77 with SMTP id ffacd0b85a97d-3864acd502amr548041f8f.44.1733834365671;
        Tue, 10 Dec 2024 04:39:25 -0800 (PST)
Message-ID: 
Date: Tue, 10 Dec 2024 13:39:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 4/6] xen/riscv: introduce cache management operations
 (CMO)
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: 
 <1310a2fb3b9824ae66f850600925127fdfdb44fa.1732709650.git.oleksii.kurochko@gmail.com>
 <9d49befe-4592-4e71-ad0b-9a0af34253f5@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.12.2024 13:19, Oleksii Kurochko wrote:
> 
> On 12/9/24 3:38 PM, Jan Beulich wrote:
>> On 27.11.2024 13:50, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/Kconfig
>>> +++ b/xen/arch/riscv/Kconfig
>>> @@ -14,6 +14,9 @@ config ARCH_DEFCONFIG
>>>       string
>>>       default "arch/riscv/configs/tiny64_defconfig"
>>>   +config HAS_CMO # Cache Management Operations
>>> +    bool
>> Hmm, and nothing ever sets this, and hence ...
>>
>>> @@ -148,9 +149,24 @@ static inline bool pte_is_mapping(pte_t p)
>>>       return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK);
>>>   }
>>>   +#ifndef HAS_CMO
>>> +static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
>>> +{
>>> +    return -EOPNOTSUPP;
>>> +}
>>> +
>>> +static inline int clean_dcache_va_range(const void *p, unsigned long size)
>>> +{
>>> +    return -EOPNOTSUPP;
>>> +}
>>> +#else
>>> +int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size);
>>> +int clean_dcache_va_range(const void *p, unsigned long size);
>>> +#endif
>> ... all you really provide are stubs and declarations, but no
>> definition anywhere?
> 
> Yes, this was done intentionally because:
> - I don't have hardware with the CMO extension, so I can't test it. ( QEMU doesn't model cache and so
>   there is no need for CMO extension emulation IIUC )
> - The instructions used for these functions may be hardware-specific and exist only for particular devices.
> 
> It seems useful to have something similar to Linux:
> https://elixir.bootlin.com/linux/v6.6.64/source/arch/riscv/include/asm/errata_list.h#L135 
> (There are also custom instructions for THEAD above this macro.)
> 
> We could use|ALT_CMO_OP(...)| inside|clean_and_invalidate_dcache_va_range()| and|clean_dcache_va_range()|.
> However, I think it would be better to introduce or implement these functions when|HAS_CMO| is set to|y| someday.
> 
> As an alternative, we could implement these functions as|panic("need to be implemented\n")| in case when HAS_CMO=y.

I think this would be well in line with various other stubs you have.

> Another option is to drop|HAS_CMO| entirely for now and keep the current implementation (|return -EOPNOTSUPP|).
> However, with this approach, there's a risk of encountering hard-to-debug issues on platforms with the CMO extension.
> And necessity of implementation of these could be missed because there is no any notification...

Well, callers ought to check return values?

>>>   static inline void invalidate_icache(void)
>>>   {
>>> -    BUG_ON("unimplemented");
>>> +    asm volatile ( "fence.i" ::: "memory" );
>>>   }
>> That's a separate extension, Zifencei, which I don't think you can just
>> assume to be present?
> 
> Based on the specification:
> ```
> Chapter 34. RV32/64G Instruction Set Listings
> One goal of the RISC-V project is that it be used as a stable software development target. For this
> purpose, we define a combination of a base ISA (RV32I or RV64I) plus selected standard extensions
> (IMAFD, Zicsr, Zifencei) as a "general-purpose" ISA, and we use the abbreviation G for the
> IMAFDZicsr_Zifencei combination of instruction-set extensions. This chapter presents opcode maps
> and instruction-set listings for RV32G and RV64G
> ```

Hmm, indeed. That's well hidden in a place I didn't expect it to live at.
Maybe worth a sentence in the description?

> and that G is needed to boot Linux kernel ( and so Xen ) I make an assumption that Zifencei will be always
> present.

I'd be a little careful here. Xen may be used in Linux-free environments.
I notice arch.mk specifies rv64g, yet I'm uncertain we shouldn't relax
that at some point.

> And based on Linux code (https://elixir.bootlin.com/linux/v6.12.4/source/arch/riscv/kernel/cpufeature.c#L676 )
> when 'i' is present in riscv,isa property zifencei is present unconditionally.

That looks questionable to me. I don't think Zifencei can be inferred from
I. Historically it was, and imo that's what the comment there says. Plus
it is dependent upon acpi_disabled.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 12:43:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 12:43:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852281.1266116 (Exim 4.92)
	(envelope-from )
	id 1tKzaF-00030W-EJ; Tue, 10 Dec 2024 12:43:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852281.1266116; Tue, 10 Dec 2024 12:43: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 1tKzaF-00030P-BC; Tue, 10 Dec 2024 12:43:23 +0000
Received: by outflank-mailman (input) for mailman id 852281;
 Tue, 10 Dec 2024 12:43: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 1tKzaD-00030J-Ll
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 12:43:21 +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 56398323-b6f4-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 13:43:20 +0100 (CET)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-385dece873cso2633151f8f.0
 for ; Tue, 10 Dec 2024 04:43:20 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-386396af76esm8294233f8f.0.2024.12.10.04.43.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 04:43:20 -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: 56398323-b6f4-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733834600; x=1734439400; 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=6dmuzEL6vNF13tBP+ZS3JeVgP6/ZgrvBAjRDYPlOpMM=;
        b=cUK3Qmu+hFOkliIL4YC/AV1mPxna9VUbR65UABv8ykFKUs7sh/iIqnzk5iUho9eVla
         VlyZ6JSdj9biqdzx3cxVphjNceLgYG90EEfwsIffebHuzsUpupbeWPwmc46MvsAbpZXv
         EEYrvMrr8PbzEIDgcVkA8nDr8a1rf92BkJTSWJ3AFCUWCChaN+YE6nHZhYMs4/Zsj8JV
         n5TdYrUb+JGuEO319edo6rw2VE0GMoBQdj4qTUpv5wMJik/TQpIKGsqfDYDK0Nrkl/ga
         ooar8DivJ18Lw+xPU/3AK8d9pszY7AoQjwNMifQAAmclSF33jtUtc5pigW/xr8hV7Wpv
         ceJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733834600; x=1734439400;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6dmuzEL6vNF13tBP+ZS3JeVgP6/ZgrvBAjRDYPlOpMM=;
        b=geEDrTA1slLWu6cjA4dzDC8pALjVrx0PjWlpBC8R6ZigWBv9KU1mMkBP90Yj9j23kG
         qPeVWufU6r+AAKIhfAfe/1cbgBHLFG08fYiOiW4TJGvSSrLRF6QZfdX4j29A8+lbTrLc
         0H2HqLqBL0lul13Vi3W07hvHHIAbn2cwnYLUZPUymWO4pKd+zrlxZP3RaZCUNiSm/OCr
         hVcMN8s2kCYX80bL8058sN4FFQQmuk6Uia9/O7WDuDDt1E81okhIyEEFM2HHsYNLjCeN
         /IMKchnK75p6LZTNPvPt0pyQN9mC+FHtnWnnVUU1rO1sLGc+maQ4RirACtFFMmfb4DmS
         frmA==
X-Forwarded-Encrypted: i=1; AJvYcCUmRQNKLsghoN0nsn6e/tc0ge6kjQG6WfMG7Z+E4ycNG9VzCYUDhC7nEu/J/jBV8Sen0RMwlQhEMIM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzKitziGOF63PUX/EHnJX06MfHGHy9JjhkQga+X5Jx5q0aAU6bG
	ns2Hzq1Eg2rQwrM8zv/mMX5erthnu6gl3AkNkWTh/bzXwIagdeOQPVuFv3wyN95ELJrAIi6qkvw
	=
X-Gm-Gg: ASbGnctaGMl30AWYNk0BvlumL9rifN+iY+7jCxxHmFotEH7nAXOn6I9xYknj7lcI5zv
	m3PZp7BeqRF7nIg1GPcceDrVGFNpgTu+uTeBh4VIpD6sb6NYYZnE5TLmLFDNiU++F1X8/HwwyFv
	S3wDO/M7QRX2AEH5dNIR0uHCT1pJcuCldVIGRjVyVVSeNQgyye82XSaaBgIZ/Qfkvovy3QQMmd8
	yVOqLlMrPFWR0OwDOAPouJd1j9prZnpSD8mM0JsfXZTAJVmoMUNSuy4Zi2+ftxmsnHMd8BYrbw5
	zVtCPmXyu2wnispDIIZ4+rKGJmDhfPpc4M4nMjxF8x8hNE3HC0m/tkkneSyibEkWvKeACVvfnyB
	T9DQLWw7xAQ==
X-Google-Smtp-Source: AGHT+IF1zxvBhYF/o/bm6NSeh2b9BA0tIfr4em13GJ6uUgZ21I1gBnhfeJXBkXK33c75KJc+v1EbUw==
X-Received: by 2002:a05:6000:156f:b0:385:fd24:3303 with SMTP id ffacd0b85a97d-3862abdcca4mr10437270f8f.0.1733834600293;
        Tue, 10 Dec 2024 04:43:20 -0800 (PST)
Message-ID: 
Date: Tue, 10 Dec 2024 13:43:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v3] x86: p2m-pod: address violation of MISRA C Rule
 2.1
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <05b5fd3a85d033adacd5aa08ca81ce579cb1a120.1733827766.git.nicola.vetrini@bugseng.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: <05b5fd3a85d033adacd5aa08ca81ce579cb1a120.1733827766.git.nicola.vetrini@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.12.2024 11:54, Nicola Vetrini wrote:
> Rule 2.1 states: "A project shall not contain unreachable code".
> 
> The placement of the loop after "out_unmap" can be moved earlier
> in order to avoid the unconditional return to be marked as a cause of
> unreachability for the loop, as this is a consequence of
> "__builtin_unreachable" being configured in ECLAIR as being deliberately
> unreachable, and therefore not reported as causing the code after the
> "out_unmap" label to be unreachable.
> 
> Replacing one instance of "goto out_unmap" with the loop avoids
> considering the unconditional return at the end of the function as a cause
> of unreachability, while preserving the semantics of the function.
> 
> No functional change intended.
> 
> Signed-off-by: Nicola Vetrini 

Reviewed-by: Jan Beulich 
with ...

> --- a/xen/arch/x86/mm/p2m-pod.c
> +++ b/xen/arch/x86/mm/p2m-pod.c
> @@ -1005,7 +1005,14 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const gfn_t *gfns, unsigned int count
>              {
>                  ASSERT_UNREACHABLE();
>                  domain_crash(d);
> -                goto out_unmap;
> +out_unmap:

... the label indented by one or more blanks, as per ./CODING_STYLE.
Happy to adjust while committing.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 12:55:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 12:55:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852295.1266125 (Exim 4.92)
	(envelope-from )
	id 1tKzlS-0004tN-DC; Tue, 10 Dec 2024 12:54:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852295.1266125; Tue, 10 Dec 2024 12:54:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tKzlS-0004tG-Ag; Tue, 10 Dec 2024 12:54:58 +0000
Received: by outflank-mailman (input) for mailman id 852295;
 Tue, 10 Dec 2024 12:54: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 1tKzlR-0004tA-RO
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 12:54:57 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f4fa2376-b6f5-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 13:54:56 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5d3ea065b79so4069141a12.3
 for ; Tue, 10 Dec 2024 04:54:56 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d3d0f93d54sm5993599a12.68.2024.12.10.04.54.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Dec 2024 04: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: f4fa2376-b6f5-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733835296; x=1734440096; 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=t4FHQghY5NHT28aQifRvJszhRcycJD9eQp9/X19JOAo=;
        b=ODp+KRSY1S7NfLqeihpZg/jYAGDLjly7GyfMT5Y8SNqHulY6AXRt2fwSyPjuPGtVKl
         6FPvVwJhculTEPA47MD1/6M0oF4wh/VAd2ay+2IzhbUeYb6uV+X9OMl348Tr9yidh4gS
         v/eYpRdJiUTsWUOqNGiHy+nOcXUfvgzU6NeGY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733835296; x=1734440096;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=t4FHQghY5NHT28aQifRvJszhRcycJD9eQp9/X19JOAo=;
        b=hXaXvhGwhS24QAGGkfbAHvkfyXKZwCNfXDDE8IiHMrZ75e04QM2ppgZPTlnf3qWEEo
         QYsvx0oJqTcsn52ozssk+IX/vyi6BzgF+laP/yunHmd61v3O/ijjuBmzr1TPnmVMSyAu
         hJ8rbRMDlMBllCFHgS3j3UFmpo8lm4BnjcczlVlY5J95Z8ildDXMHRa/XC/kGIIa4Vn6
         L5YYhPhLPTt0Lj+SZASKPH7iBSDCMJxvriqDd1DfA1Gl2xXdIm8krcI+Vq8WHV0B8kUb
         5XGCWMYPiHVx5ytn47W9oBa3QtohlLiKnHX0uZrGj85Hx+Uc1+oitZnq7+TYojld28t9
         Ebuw==
X-Forwarded-Encrypted: i=1; AJvYcCWZ9XTIOtnzI+FUShwrZFcDxxIbJeio/BHY4kOuGDNvm/lgwRavuPLZlrAOzYtQhmgPwxrFaWViBck=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx9wtpUmi9aE6X7VKiQE3wECPlPFWytIfk9e99rtbi7SgLvWoIm
	VK/JIpfMQszpfIaSTfH1phIgVeV3UqsJ3RyUwlUvqwxzu3+S54MinWYhxxKMmcE=
X-Gm-Gg: ASbGncsZzg+A/1u2QIfGxtFiDezvyhyQCXXjkCqrXpm40JXQFWz9vzaEjyu2pERGBn1
	qUeesL5m2L3X1dDLLmZTv4w6PGXCdKTYVZzvkAQJGbrCmOQ5ZwYbBpdC7/0Bsgb1tUVsm/5Oagn
	RfXPluxL5ctBGsxIHo6nEA4bMvpiFenZi6PWHxcplMp+JefNl9ZhSysDUlxqaaMH6umbxlt0jOe
	CnspH2knDgjypebqYe8SzvxleAnfp2jf2hlfpXuLWthemmRwzzzdgrO12lMARw=
X-Google-Smtp-Source: AGHT+IHxZXYum4p28zMZQkx84l+YU6NFwuzHrQpuV+qKlnbgSpLdI9epxpsIqaoi4IiQBq5LnXrT5g==
X-Received: by 2002:a05:6402:3490:b0:5d2:7396:b0ce with SMTP id 4fb4d7f45d1cf-5d4185029c2mr5927451a12.3.1733835296092;
        Tue, 10 Dec 2024 04:54:56 -0800 (PST)
Date: Tue, 10 Dec 2024 13:54:54 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "Chen, Jiqian" ,
	Andrew Cooper ,
	Julien Grall ,
	Stefano Stabellini ,
	"Huang, Ray" ,
	"xen-devel@lists.xenproject.org" 
Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support
Message-ID: 
References: <20241202060956.1124162-1-Jiqian.Chen@amd.com>
 <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com>
 
 <1e0576d9-400e-4483-8dd1-061e215a00cd@suse.com>
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Tue, Dec 10, 2024 at 01:15:00PM +0100, Jan Beulich wrote:
> On 10.12.2024 12:25, Roger Pau Monné wrote:
> > On Tue, Dec 10, 2024 at 10:54:43AM +0100, Jan Beulich wrote:
> >> On 10.12.2024 08:57, Chen, Jiqian wrote:
> >>> On 2024/12/10 15:17, Jan Beulich wrote:
> >>>> On 10.12.2024 08:07, Chen, Jiqian wrote:
> >>>>> On 2024/12/9 21:59, Jan Beulich wrote:
> >>>>>> On 02.12.2024 07:09, Jiqian Chen wrote:
> >>>>>>> +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
> >>>>>>> +                                      unsigned int reg,
> >>>>>>> +                                      uint32_t val,
> >>>>>>> +                                      void *data)
> >>>>>>> +{
> >>>>>>> +    uint64_t size;
> >>>>>>> +    unsigned int index;
> >>>>>>> +    struct vpci_bar *bars = data;
> >>>>>>> +
> >>>>>>> +    if ( pci_conf_read16(pdev->sbdf, PCI_COMMAND) & PCI_COMMAND_MEMORY )
> >>>>>>> +        return;
> >>>>>>
> >>>>>> I don't think something like this can go uncommented. I don't think the
> >>>>>> spec mandates to drop writes in this situation?
> >>>>> Spec says: Software must clear the Memory Space Enable bit in the Command register before writing the BAR Size field.
> >>>>> This check is suggested by Roger and it really helps to prevent erroneous writes in this case,
> >>>>> such as the result of debugging with Roger in the previous version.
> >>>>> I will add the spec's sentences as comments here in next version.
> >>>>
> >>>> What you quote from the spec may not be enough as a comment here. There's
> >>>> no direct implication that the write would simply be dropped on the floor
> >>>> if the bit is still set. So I think you want to go a little beyond just
> >>>> quoting from the spec.
> >>> How about quoting Roger's previous words: " The memory decoding must be disabled before writing the BAR size field.
> >>> Otherwise changing the BAR size will lead to the active p2m mappings getting out of sync w.r.t. the new BAR size." ?
> >>
> >> That'll be better, but imo still not enough to explain the outright ignoring
> >> of the write.
> > 
> > I think we might want to do something along the lines of:
> > 
> > uint64_t size = PCI_REBAR_CTRL_SIZE(val);
> > struct vpci_bar *bar = data;
> > 
> > if ( bar->enabled )
> > {
> >     if ( size == bar->size )
> >         return;
> > 
> >     /*
> >      * Refuse to resize a BAR while memory decoding is enabled, as
> >      * otherwise the size of the mapped region in the p2m would become
> >      * stale with the newly set BAR size, and the position of the BAR
> >      * would be reset to undefined.  Note the PCIe specification also
> >      * forbids resizing a BAR with memory decoding enabled.
> >      */
> >     gprintk(XENLOG_ERR,
> >             "%pp: refuse to resize BAR with memory decoding enabled\n",
> > 	    &pci->sbdf);
> >     return;
> > }
> > 
> > Note this requires that the data parameter points to the BAR that
> > matches the ReBAR control register, this needs adjusting in
> > init_rebar().
> 
> SGTM.

One nit that I'm kind of unsure, is whether writing the ReBAR with the
same BAR size as it's currently set also causes the matching BAR
register to be reset.  I'm unsure whether dropping the write when size
== bar->size without logging a message is appropriate, as it could be
a change in behavior if the software expects the BAR position to be
reset.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 13:10:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 13:10:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852315.1266136 (Exim 4.92)
	(envelope-from )
	id 1tL00b-0007k2-OD; Tue, 10 Dec 2024 13:10:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852315.1266136; Tue, 10 Dec 2024 13:10: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 1tL00b-0007jv-Kv; Tue, 10 Dec 2024 13:10:37 +0000
Received: by outflank-mailman (input) for mailman id 852315;
 Tue, 10 Dec 2024 13:10: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 1tL00a-0007jp-CH
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 13:10:36 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 23bdc95e-b6f8-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 14:10:34 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 11BAE4EE0738;
 Tue, 10 Dec 2024 14:10:33 +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: 23bdc95e-b6f8-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1733836233; bh=ZLb419UtYIiSd+C8NJrDogsdQjYSzrnVggMezwZxMZ0=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=BquhtKY6qEW8ahSfeja92GRZKSRV5gj6hxmWYP1yWO/81gnzHx7W4r53T8qosDg6K
	 g38U365dCpetsSBoo4/MhSG2rT9hQlUNYUvAGbT8x+GTPzj4Adba+z5jKp9RApc70j
	 1h3wctwcYerE/4ftSe8MscKA3PCgvX0yvKIKmHrlkip0y5E15syxwLH7Z4vUxqAg07
	 IXF3ZSfLsC8mwFp6fuGtslj3GRFdMVw/C9/1hwX7n6JOHgv19rYxsdtNh5f5JX6exX
	 GBdHwhOamVY7w9+g5PYzUzZh5DFWIK7d0+9r+ao7OHBvURln3YTWQeexV/icu3id4n
	 eEtjLElMXgbcQ==
MIME-Version: 1.0
Date: Tue, 10 Dec 2024 14:10:33 +0100
From: Nicola Vetrini 
To: Jan Beulich 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com, Andrew Cooper
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH v3] x86: p2m-pod: address violation of MISRA C Rule
 2.1
In-Reply-To: 
References: <05b5fd3a85d033adacd5aa08ca81ce579cb1a120.1733827766.git.nicola.vetrini@bugseng.com>
 
Message-ID: <7684e75d33c741c532a65014473e2f92@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-12-10 13:43, Jan Beulich wrote:
> On 10.12.2024 11:54, Nicola Vetrini wrote:
>> Rule 2.1 states: "A project shall not contain unreachable code".
>> 
>> The placement of the loop after "out_unmap" can be moved earlier
>> in order to avoid the unconditional return to be marked as a cause of
>> unreachability for the loop, as this is a consequence of
>> "__builtin_unreachable" being configured in ECLAIR as being 
>> deliberately
>> unreachable, and therefore not reported as causing the code after the
>> "out_unmap" label to be unreachable.
>> 
>> Replacing one instance of "goto out_unmap" with the loop avoids
>> considering the unconditional return at the end of the function as a 
>> cause
>> of unreachability, while preserving the semantics of the function.
>> 
>> No functional change intended.
>> 
>> Signed-off-by: Nicola Vetrini 
> 
> Reviewed-by: Jan Beulich 
> with ...
> 

Thanks

>> --- a/xen/arch/x86/mm/p2m-pod.c
>> +++ b/xen/arch/x86/mm/p2m-pod.c
>> @@ -1005,7 +1005,14 @@ p2m_pod_zero_check(struct p2m_domain *p2m, 
>> const gfn_t *gfns, unsigned int count
>>              {
>>                  ASSERT_UNREACHABLE();
>>                  domain_crash(d);
>> -                goto out_unmap;
>> +out_unmap:
> 
> ... the label indented by one or more blanks, as per ./CODING_STYLE.
> Happy to adjust while committing.
> 

Right, I followed the style used in this file assuming that it was in 
line with CODING_STYLE, but I now see that this is not the case. No 
problem either way.

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 13:13:26 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 13:13:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852332.1266157 (Exim 4.92)
	(envelope-from )
	id 1tL03J-0000KB-Fw; Tue, 10 Dec 2024 13:13:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852332.1266157; Tue, 10 Dec 2024 13:13: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 1tL03J-0000K4-DE; Tue, 10 Dec 2024 13:13:25 +0000
Received: by outflank-mailman (input) for mailman id 852332;
 Tue, 10 Dec 2024 13:13: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 1tL03H-0000Ju-On
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 13:13:23 +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 87af9be5-b6f8-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 14:13:21 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-434f3d934fcso15859965e9.3
 for ; Tue, 10 Dec 2024 05:13:21 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3861f59ccd6sm15794407f8f.32.2024.12.10.05.13.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 05:13:20 -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: 87af9be5-b6f8-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733836401; x=1734441201; 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=1aF7XpvhQ6Apl9P2KccD9VrasN0wSy21pMmLhIayMSI=;
        b=MeH+w+h/L3w8QgtOMXK3h8JhAF+Oau7EKmQdBhAuv+17UgEriCv8lP6Xmr63vcVHSD
         Mqc0xehCJHlqEO0iDgSOBM5BuAFYAD01zj44Pct4dKCUp02hWYlVFhoPJ57BQu9zXBu/
         9Ds48ZytUsAqaM72ISmY2O70xx2Dmqyy7LnVGqnRfdn1OqjT1MuFjykm+hrNoXOeVTEV
         YguMuQSfBmC7wqhB3GKntqBoA9lvzC8ZRt9qwODAjGdB4l2bUWozLhMx4GGt6z2fAAi0
         X7/sssDJj+i2pS3pSu51yYippY8NZpJ6DJ8+J8m9HLic5I6XhZVd1VceZWKzan6jrHSe
         9mYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733836401; x=1734441201;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1aF7XpvhQ6Apl9P2KccD9VrasN0wSy21pMmLhIayMSI=;
        b=YaEFbjukPPp9oVzJ9329eO7qy3hLc97elTayH42qrSwxqv3lXofD/S62BTHUloh/u4
         czjt4vG2CBzMAolS6eHgk8kzXtP0oA/Hzbfsdk0X6Pyd5Wk6KfempCuG74kuNn2ZDn8J
         xnqFxJkrHGgtyRR90DlQTW1PM2oEpxVScBFtDtucjD+F1ROw9S5nKJz2UnhbAM88ImGr
         tDCZRLf/Fzv3GGzskLTGBMX4G8910DiMhs8LEhkgspAFGPQsR4/xPoQVv1T0kQgHDb4F
         YfCvmMCrPeSD1hQaevMSAvyV+IxPAJa7nNzqsf/Q57xybJ8uYZWbxYfgnANYuNhvTdSF
         Ao3A==
X-Forwarded-Encrypted: i=1; AJvYcCV57gKmEVlu5v5k0CEUaBgYCcs4yUfc+j6TgGIDqtxMcCqiZnb+hh/I59I7tarV0I5ZHVbQoz/wAoQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzDErKMf5F9sY8moSqZdTUebRfJwNqpmekd1/OzUnka2tYuevN4
	mELqx8zgRP7eX8kgpQpTEqtKnnvwsomIMsKzI1DertLdhikgxurH6OVycWe4Vg==
X-Gm-Gg: ASbGnctYKaR5G9F7OuFRv8AV+8L/UjZZzuyWQ+/JM/Iz1vz7EkDYgrTniOiPguVFopE
	PGDOgxZ2S+cbhNUbKhnDBCWyUdQmXU0ibz2U6IbNXRHDK4Tj4yzwfV9O8+kbpI2+dUPHU1rPMZ8
	ps/97v1rlcuWOwjIeWIRUXFzJuYMrttgyoawLlB2MmcURDfryIy+iZFTMyf6br0+r7psk3EmS7b
	M4RRjQ/333yq+gtzf8C/5wg/gCkP6LuQxFaPDA8pnbnf/v3Oq4W3H175ZQGOLhUWbtp7n/YNvyL
	uLmQourh07fY3WjvGOl3M3mrPKAsRFdBrD2nwct9By7Zw73o19ygnFxkEKFjHGnCHJkpeg3quBy
	aWCmJ9ag+YQ==
X-Google-Smtp-Source: AGHT+IETrVvJzmw157A1fHLwbSDF/caGV7/c67mf5FT4o98dZEkOnt4NLUWdBp7iWO6MDLfH7A811w==
X-Received: by 2002:a5d:5989:0:b0:385:dfab:1644 with SMTP id ffacd0b85a97d-386453e316fmr2922258f8f.33.1733836401084;
        Tue, 10 Dec 2024 05:13:21 -0800 (PST)
Message-ID: 
Date: Tue, 10 Dec 2024 14:13:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 01/35] xen: introduce resource.h
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-1-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-1-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> --- /dev/null
> +++ b/xen/include/xen/resource.h
> @@ -0,0 +1,40 @@
> +/* SPDX-License-Identifier: GPL-2.0 */

GPL-2.0-only

> +/*
> + * System resource description.
> + *
> + * Reference:
> + *   include/linux/ioport.h

I'm unsure of the usefulness of such a reference.

> + */
> +#if !defined(XEN__RESOURCE_H)

Nit: #ifdef / #ifndef please whenever possible (as long as not inconsistent
with adjacent code).

> +#define XEN__RESOURCE_H
> +
> +#define IORESOURCE_BITS         0x000000FFU      /* Bus-specific bits */
> +
> +#define IORESOURCE_TYPE_BITS    0x00001F00U      /* Resource type */
> +#define IORESOURCE_IO           0x00000100U      /* PCI/ISA I/O ports */
> +#define IORESOURCE_MEM          0x00000200U
> +#define IORESOURCE_REG          0x00000300U      /* Register offsets */
> +#define IORESOURCE_IRQ          0x00000400U
> +#define IORESOURCE_DMA          0x00000800U
> +#define IORESOURCE_BUS          0x00001000U
> +
> +#define IORESOURCE_PREFETCH     0x00002000U      /* No side effects */
> +#define IORESOURCE_READONLY     0x00004000U
> +#define IORESOURCE_CACHEABLE    0x00008000U
> +#define IORESOURCE_RANGELENGTH  0x00010000U
> +#define IORESOURCE_SHADOWABLE   0x00020000U
> +
> +#define IORESOURCE_UNKNOWN      (~0U)
> +
> +struct resource {
> +    paddr_t addr;
> +    paddr_t size;
> +    unsigned int type;
> +};
> +
> +#define resource_size(res) (res)->size;

The semicolon surely was wrong before and is wrong now. Plus Misra
demands that such macro expansions be parenthesized, I think.

> +#define foreach_resource(res) \
> +    for (; res && res->type != IORESOURCE_UNKNOWN; res++)

This one isn't being moved, but is being added. It's not used here,
which makes it difficult to judge its correctness. Perhaps better to
introduce this when its first needed, and then right away with the
required parentheses around uses of the macro parameter.

> +#endif /* #if !defined(XEN__RESOURCE_H) */

Just the guard identifier in the comment please.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 13:17:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 13:17:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852357.1266168 (Exim 4.92)
	(envelope-from )
	id 1tL06w-0001L1-VL; Tue, 10 Dec 2024 13:17:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852357.1266168; Tue, 10 Dec 2024 13:17: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 1tL06w-0001Ku-Rs; Tue, 10 Dec 2024 13:17:10 +0000
Received: by outflank-mailman (input) for mailman id 852357;
 Tue, 10 Dec 2024 13:17: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 1tL06v-0001Kk-Ny
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 13:17:09 +0000
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com
 [2a00:1450:4864:20::42c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0ed2e5fe-b6f9-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 14:17:08 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3862d16b4f5so2436787f8f.0
 for ; Tue, 10 Dec 2024 05:17:08 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-386220b071dsm15629457f8f.101.2024.12.10.05.17.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 05:17: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: 0ed2e5fe-b6f9-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733836628; x=1734441428; 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=7NnMrJ1jCt3SXxiczbCnK0KjHO4wCfNpPKuiIhRFoUM=;
        b=R3UqxoszpFfSJlatOfGrm7LaQ0EPiT4kSpGGxQ3Dlj1NfV7SPqZ6EJiQ3jh8J2tTJP
         uCAFvoOc91t0nUxzZQouvPoy/c8XIVtIYWQjvn0767WIuRtIRpttUUkodXclrAInHcLa
         Wl4tOjFOV2ONelH14o9xGIrYC3nwN8l6yz5jSQy3tZePhNdG2UE6hE/i4GcaeCnnJCWV
         AaYrVBdlCgG4GU0/EXUxkM4Icnk2WxMQpQmnYki+vM055FgKalJiEuan6/GsDAwxQDZF
         Tm8IFZDOsC2Xs+nvJaLH8cFqAgQv2h5pLoDTaaNWnbiSfSZ3qcVW5FZs/jEyOAiByerO
         ceyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733836628; x=1734441428;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7NnMrJ1jCt3SXxiczbCnK0KjHO4wCfNpPKuiIhRFoUM=;
        b=fVLEemJvcDj98uI8rZWE7tWaSAn9kY50A88I3nSTXDUMGj4Xn/Pvxmf1F8gcVvxAEp
         oWh9Xj5FPWsnEI/j1SaMWKAu0Myp9psOLrBi4lDt+qgqBoT4RwdzqgInOwmlB/gbJpft
         wHFegBCsodRs2ZXbtBgKm0hCs/tHiZ2HlFv4BixwVrXFXAki8O9mk7zpjL4QWEMKHsSh
         daWWi0F9ATHZ9Sr0xQ1Oq3RvM3eG1X1Yk+h1RtjIkiipwNvUSctrpBldv8GlrqpTujWk
         PHfMZW0NJd2TRNyGc5tiZq513XF0oJKglWmwhE83cqifXbsp3dJCLp2yBSXiruP1W2tJ
         QvCQ==
X-Forwarded-Encrypted: i=1; AJvYcCV+GL8p9OIg0dt582QFrVuH1J0fswq7kYj9opr7m65ziyxqpU3B8nGRgis4PakFCCPI2HnzQbI/DvE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YympZn7XrfyXO/7NksWLM3njq+2+E/md87UFUYaXOCFSZdXeZDR
	+3j8Fq+T4bwIlDVQEzb4pp9VuVweU7HP4d1YFCMGHjcBGsmpGCE6nFzUFOUI9A==
X-Gm-Gg: ASbGncu5X8/DEwKSLV1iF511Eb4VDoRTpOvcq7icZjya1U58bdrK7FGbUpwx8Ossob7
	ikH/345dB7zlA5Qos23EKZ2h4TmKy1SQRcNL1dyAZ67U6pzUEa3bDcvVJ7mVN4rO1AGFpzPGo0O
	yKxfaSoVPT7I7fxSXAtJ85gbXAe3lSnDC8opv8oVaCIXfrN+NsNjG396Cy1FEDcF9aFw/dgf3ke
	gtCg1PIRH5KaKzW2RNSUKz2RKcuDe5TxMXpn8KdwFe0VFuE3OqEDwwr1BMtMskmJXplY/jXAdws
	Gmf8vab01Aw3r8Vo4tIylrIfCcsUJmhLR8kWIMhQyw5HzacLgQpDdebz1KnzA70R0Bm08UbjTjW
	CciCftvuL/g==
X-Google-Smtp-Source: AGHT+IFPB3t+svpamS6wHJE6uW8uhwUbVL/32mp39xubyJa6AAMR1jQcgRdgl34mzS+hU3KO58e6AA==
X-Received: by 2002:a5d:47c9:0:b0:385:f349:ffe5 with SMTP id ffacd0b85a97d-38646a09222mr2319330f8f.29.1733836627973;
        Tue, 10 Dec 2024 05:17:07 -0800 (PST)
Message-ID: <8c7daeda-2a00-476a-9a86-806139035cd0@suse.com>
Date: Tue, 10 Dec 2024 14:17:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 02/35] xen/irq: introduce NO_IRQ
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-2-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-2-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Introduce definition for IRQ resource checks.

How does this fit ...

> --- a/xen/include/xen/irq.h
> +++ b/xen/include/xen/irq.h
> @@ -53,6 +53,7 @@ struct irqaction {
>  #define AUTO_ASSIGN_IRQ         (-1)
>  #define NEVER_ASSIGN_IRQ        (-2)
>  #define FREE_TO_ASSIGN_IRQ      (-3)
> +#define NO_IRQ                  (-4)

... the grouping here? The constants in context aren't used anywhere,
so it's hard to see whether / how the new one fits here (and doesn't
instead belong into the new resource.h you introduce in patch 1). Once
again likely best to have this in the patch where it's first needed,
thus providing at least some context.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 13:22:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 13:22:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852370.1266178 (Exim 4.92)
	(envelope-from )
	id 1tL0Bg-00031k-HG; Tue, 10 Dec 2024 13:22:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852370.1266178; Tue, 10 Dec 2024 13:22:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tL0Bg-00031d-DL; Tue, 10 Dec 2024 13:22:04 +0000
Received: by outflank-mailman (input) for mailman id 852370;
 Tue, 10 Dec 2024 13:22: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 1tL0Bf-00031X-HN
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 13:22:03 +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 be280da0-b6f9-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 14:22:02 +0100 (CET)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3862a921123so3082136f8f.3
 for ; Tue, 10 Dec 2024 05:22:02 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-386408549b9sm5336627f8f.89.2024.12.10.05.22.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 05:22: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: be280da0-b6f9-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733836922; x=1734441722; 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=TPUMltX8XIUJm/7wB9nigVccIpZNB3od1WZv2QsS/ZU=;
        b=KE9uyNSk1E1uPG+DMZSh5Gtc/jjIpW2EvtQbo+B5OciXKjeY2OLiSuQDz+Xrkrjc23
         j9DBM5ARE7oDXbHO15KA++KQ+Mlu7KAP8XtLKiyGYP68lrMfiJPUhU3Rom5Nf6GPlu8x
         BJJKztpu1LycF9RwzSXBgN6JdKzsrSnYbFmcm4Wk1KytZ9A10R0SL546kGJeHUijj76S
         ZT7Wx2s15N/ub8rkmGHSfsTzFcKFklI44sNopd15iWt/r+XQBcM+ofm8N/TZedRsAD2n
         0mZbTShk0+loLfa+vwJXBhIEGUDc2PbgmEYd9nR2IyfefQ8Kn1Bnni1SP7hclx5+aG4/
         E/1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733836922; x=1734441722;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=TPUMltX8XIUJm/7wB9nigVccIpZNB3od1WZv2QsS/ZU=;
        b=VTu0zrA1d+vxM4A9PoruoYVHLlcAxDXaw3XxhOmJQUgl2iiNMZmRycF5NPiTkOLQtR
         I9AEh+UynQWemF8tDK2Es7xfAzjcZOt+mb49wBdo9ay3QapsHz9+bnpoK/7+rmslRsIm
         2UpXyZ8+l9IOj2hYQvQy/kaAHCRW6/B438lSFUDTh8BftXXmVySxqSbJNSZDv1MDmw33
         LEQML4wKOncFDzLQ5pl4hKnePUvkbnaQjQxfICBRgkc/qBNScAPEnTysomyegjWxJu6w
         d/sG9O1QzqkgEdH1R5T+I0QxfWmzOlExzIHwopucUqMN3k6OzbZrXs09pgBjGayHy2oJ
         CEyw==
X-Forwarded-Encrypted: i=1; AJvYcCXZR6Mz83F4gEzA5f9/fgkxGdWZ2w/HEMjoAipshnYKinOS2g9P+0/JEk24pZzLU/dMjnlNG2IDkV8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxkin65udYNiNgAhcNJn6jdjt8dc7ILK8XL3RcJdKHL9J0KeIjc
	pC7TpDg4xR5s8CBV4uVjTKxmCFXov8cIlqFvHqCAQn7aenUQ1IQ8dI+abWxOUA==
X-Gm-Gg: ASbGnctYXlD12G8ZgAcazaoCtAzn4ywPwWzjh7kGvI8lR/ty91pNMW6tisvm+fRnXj9
	+xHlZ/EiP17RtLyFPaC3niH3Z48idg7vOYsj+ZkDBHx8Vxs5o1woM15TwQ9DPZ7+dR2QcEjibqn
	dGZNKGBxvl2zNDm9syiF4i5UrWwcrI09ScWVljGaQ0p9wng0kOdFx1mHdZ8m/KJ37DEAIjnnnJ5
	jPof/EUC/r2lkg+UBpjN0Kgl30EWhl5CxnIV7vGqbqdPoSmgO+u5nMP+ii4LypAa0lPb1VUHPO/
	tv7XswyZzJJSC5puZhxy5FnhjKgSNjIPkD+DhCsz16ui5z88IJ1xyveNMbdln6mjEyBT214cweZ
	tyQiXHstn3g==
X-Google-Smtp-Source: AGHT+IEiOIBBwEahoL7AvBbAmDnWY9uVatHf3/+LF2azpN7mfBX+CHzx383tAeFQnV84bZYZFhR9Qg==
X-Received: by 2002:a05:6000:709:b0:385:e1e8:40db with SMTP id ffacd0b85a97d-3862b37b40fmr14793077f8f.24.1733836922155;
        Tue, 10 Dec 2024 05:22:02 -0800 (PST)
Message-ID: 
Date: Tue, 10 Dec 2024 14:22:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/35] xen/ctype: introduce isconsole()
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-3-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-3-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> There are several console drivers which have same checks w.r.t. printable
> characters. The check is moved to new isconsole() macro and re-used in
> the console drivers.

Something named isconsole() imo can't be expected to do what is checked for
...

> --- a/xen/arch/arm/vuart.c
> +++ b/xen/arch/arm/vuart.c
> @@ -79,8 +79,7 @@ static void vuart_print_char(struct vcpu *v, char c)
>      struct domain *d = v->domain;
>      struct vuart *uart = &d->arch.vuart;
>  
> -    /* Accept only printable characters, newline, and horizontal tab. */
> -    if ( !isprint(c) && (c != '\n') && (c != '\t') )
> +    if ( !isconsole(c) )
>          return ;

... e.g. here. If we really want such a further abstraction (of which I'm
unconvinced), then maybe isprintable() or (getting ling-ish)
is_console_printable().

> --- a/xen/include/xen/ctype.h
> +++ b/xen/include/xen/ctype.h
> @@ -4,6 +4,8 @@
>  /*
>   * NOTE! This ctype does not handle EOF like the standard C
>   * library is required to.
> + *
> + * See Rule 21.13 in docs/misra/rules.rst.
>   */

How's this change related to the purpose of the patch?

> @@ -30,6 +32,7 @@ extern const unsigned char _ctype[];
>  #define isspace(c)	((__ismask(c)&(_S)) != 0)
>  #define isupper(c)	((__ismask(c)&(_U)) != 0)
>  #define isxdigit(c)	((__ismask(c)&(_D|_X)) != 0)
> +#define isconsole(c)	(isprint(c) || (c) == '\n' || (c) == '\t')

In a pretty general purpose macro like this one I'm afraid I view it as
risky to evaluate the parameter more than once.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 13:25:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 13:25:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852382.1266188 (Exim 4.92)
	(envelope-from )
	id 1tL0Ea-0003lN-TY; Tue, 10 Dec 2024 13:25:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852382.1266188; Tue, 10 Dec 2024 13:25: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 1tL0Ea-0003lG-Qp; Tue, 10 Dec 2024 13:25:04 +0000
Received: by outflank-mailman (input) for mailman id 852382;
 Tue, 10 Dec 2024 13:25: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 1tL0EZ-0003lA-NP
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 13:25:03 +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 28f8e2b5-b6fa-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 14:25:01 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-434e9716feaso18935525e9.3
 for ; Tue, 10 Dec 2024 05:25:01 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-434fb9bf04esm56993525e9.26.2024.12.10.05.25.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 05:25: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: 28f8e2b5-b6fa-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733837101; x=1734441901; 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=RBcklUltirvQY9PSNc7XysIqku7VkeVi7jrUQuk4484=;
        b=B8kEU/dNvxaflT90k57t3cbOFRfhLnTEqWpYkmN7I3W6kwjri0BSvEj+WHwZkUcqyM
         1f3D59FrYm23uRTCcUS80nl8JGnSFw4tKlax9Xj0QpVfRuYJldUfP344w1iwudOTznAy
         5mghU1531W9PMi2bVbRin2CPQkd9GuyrnScRhdQlir51wPqqIm/zSkWGrzw2YeFh3KoR
         fF1fEA4OHpUrJYSSCEQzdL4NokVlWLCd627gIUw6iH0kXbaZoalQMF3HZRg4BGA0OGop
         K28bPrOSB5SDX6Krsj19lDD69mLWTY9NF3HKr8G/P6JxBkiy7PnSRHztX9JfNtOdxDlk
         dXuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733837101; x=1734441901;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=RBcklUltirvQY9PSNc7XysIqku7VkeVi7jrUQuk4484=;
        b=cDKVFNrO/muorJt79cgOx4u8Kz9bBCESiiH5xLcAwcO8d0zb+Fr96KVxRrQvFRKsby
         KsD4KPv1u5FpP8t5cgEkwJ3LBA+fdlvVyxTu/WDKl3QyNIVQDh0ff7ve4rNqxXSEm+Vb
         n2NIUdplA0e+YJq0Hajkcrdz4HfYJsESo3625AIevVhk1a7uW6dToIcKzumYB4Ft9ZVc
         4Ld0642qVHfNSpOPL+RphuUg2b66uh3Sz/0O7yNlG3ZSrVUTSPP1OAWoF3UPBA24lJPC
         lonO6QWTid34Pg/519zb+2GX7E7+6D4eUGMG+HsWCJORnTpUMGXGLD5eOkAMlrZUtZWu
         G87Q==
X-Forwarded-Encrypted: i=1; AJvYcCX1C12arfdrMDDJ0duPNA4aRifzivfOjI5W/0cs137tXDAHLO3DNgmDXk44PqsVHXnmAPdJnJ9oBos=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxKGB9nTaxIawee7mVftXNKTdVwNNmNLleTlQShrxXaoj5hX3Qn
	2P/cQszVj68WebYUf/tfR98Egt/uJsyjB1bfQY8k4aRWUmZQjyupsDGG7JSwpQ==
X-Gm-Gg: ASbGnctxp83WPmwQm2YpMpppj4GwskJH4/fM2kOA++S0jnsVSm5h8sRjQaptks3HBOa
	cf18d9G4NyyctqOlupT0FVFtc+6IzhAdadeKMzyysiMxd6AlEEfZKnKvltA9wDdBIa5elrreJLK
	wfCP3NDpVecFokdfT31JLmEkuchKKruc0KUsUQ8U6It9fx7e6ZeK4SBDpIsiW4Hjl3SFgJ97AAT
	LdgZ3EANRvTSEe9zlFg19G7RO9nzDh2IvI+w3okRCAeKQ8ph1WWT8/K1ot/OBTpxqxSGqEoj9CC
	8ipNajkZeoaZPlGOxIa9pxSDGA+s1rRbBC1WDzE0Qra9zb2sw7x6i0VRMQzh17B9ttL+fhEB4Q4
	UdI6V2PJ0tQ==
X-Google-Smtp-Source: AGHT+IEI48tSbAuXlSNltoXFGqhCWWgRlD7UOBfVnfjD3qAJgPCcyceWva5xeqqDIXezifka2/ISBg==
X-Received: by 2002:a05:600c:1f96:b0:431:55af:a230 with SMTP id 5b1f17b1804b1-434ddee050emr112747885e9.33.1733837101189;
        Tue, 10 Dec 2024 05:25:01 -0800 (PST)
Message-ID: 
Date: Tue, 10 Dec 2024 14:24:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 07/35] ppc/domain: introduce domain_has_vuart()
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Shawn Anastasio ,
 xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-7-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-7-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Introduce domain_has_vuart() for PPC port to be used in the console driver.
> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/arch/ppc/include/asm/domain.h | 2 ++
>  1 file changed, 2 insertions(+)

Please be sure to Cc the maintainer(s) of the file(s) you change. Else
it may be pretty unlikely that you'll ever get an ack.

Jan

> --- a/xen/arch/ppc/include/asm/domain.h
> +++ b/xen/arch/ppc/include/asm/domain.h
> @@ -10,6 +10,8 @@ struct hvm_domain
>      uint64_t              params[HVM_NR_PARAMS];
>  };
>  
> +#define domain_has_vuart(d)         false
> +
>  /* TODO: Implement */
>  #define guest_mode(r) ({ (void)(r); BUG_ON("unimplemented"); 0; })
>  
> 



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 13:26:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 13:26:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852396.1266198 (Exim 4.92)
	(envelope-from )
	id 1tL0GQ-0004N7-BQ; Tue, 10 Dec 2024 13:26:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852396.1266198; Tue, 10 Dec 2024 13:26: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 1tL0GQ-0004N0-8o; Tue, 10 Dec 2024 13:26:58 +0000
Received: by outflank-mailman (input) for mailman id 852396;
 Tue, 10 Dec 2024 13:26: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 1tL0GO-0004Mc-Ga
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 13:26:56 +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 6c296b24-b6fa-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 14:26:54 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-435005192d1so12279945e9.3
 for ; Tue, 10 Dec 2024 05:26:54 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3861ecf3cd1sm15724820f8f.11.2024.12.10.05.26.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 05:26: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: 6c296b24-b6fa-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733837214; x=1734442014; 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=jJMXFVxMugF63Nop9kk5EIhsyJ/0PX6YgvNpqTxhmV4=;
        b=F7nrgCVlCpglRHwDYuODJgNRg1FzBgp6ZHGb4LFsznyEKQxpBmQ+AittFxZoyRUNYP
         BsBz6PLhxk7xsmPAgFzPQpQnzRpAnGDMYdO+2Q5ssIfdGubVwtCcn3nru7KF71ucSBUo
         Orb3xKFKDV6tnktLf/wG68Nr7DBG+Chad635Ae1Ake2f90cMCdTOqnjit1iNFXPyRxB7
         HpprjCCScb3c7X+xxSs/XrFAg2+NvgRkPw2ATmJ+tBVY0LurxDFrsxvAkVKdfyK75VNV
         zXRoE5bP7v2uuJJHQz9qC4GUNlJcg3av49TIu8IZGJdKqd1mAuXIKYtYZ5IyF4cntjKM
         X5cA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733837214; x=1734442014;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jJMXFVxMugF63Nop9kk5EIhsyJ/0PX6YgvNpqTxhmV4=;
        b=e2r6XSjas/d7jbPfuVdP23osSQorF/xHAz3E3OkcOVIjq4OHWh3fQSjzd2K1nY5ERc
         WW480BbTc95i7mPZTRrFu6Tvd6JqGoKccLzsUFjoG7/Hgl5t96CkvGbJNv/DmK2fo1fo
         /gh/t863342GQi4T2Fac0IGP8T/28kRpvttmWJ58Wj2K8E90mbNILVXx8N4pQ6sv9IDj
         YnwKirRz927Y79YSxLTz4jEO9acc+/8qzaENeO3q4Ld2lgMplPd46gfvshJl9kWX4GkS
         OwsRoRPIPsOUOS3rcxPOUhIC1qpGzc+CJGaAo7WCEWvr1tW5R81lcjEEMcwU+NatAqMk
         2VCw==
X-Forwarded-Encrypted: i=1; AJvYcCVwP3eGkTOx2TIF6xmb13h8l3U9BGHq79CCjP7Y1XyFNqBHdMjgQsAuU9zIpHoGMT99Iq3LeWg0el4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzRjJtf99SrRyCLyLaYnbmv4dFMcgpvaGYP9l60OZB/86OowNeV
	RvDNZfpJJ54D9vG6p4iVN2Qcy7JFgpbv5Moe8ptFfmOXH0PIY7TTnVlaWK0NYQ==
X-Gm-Gg: ASbGncu6IlzpcTYIZZR6AbADveEMewkzl2lvYslVpIKxXQ5rqwEHw7buWGz1RH2dLzu
	k1DMAQNrRHG+hZrjtMZSy2aiDNjj7pAOCpBLDr+5emxIyMTFjHB92sp/KFIOmhC3wSKtMGR4JSA
	08IehEIvAVAq3mJHdVAFnRklsz7OT9frMsK7OY65It/0OXJCtLosbSz6/d7pb1iwwASdg4T7kKW
	qSd3S2/tPU7stoUbqw/kE+QG2/t3Xcz3aTbktc7MTAkV8djfvig2IpYR6hRkqTVsw4bh73nLzO+
	8G8d9yBk1rbvkTbi3q75RCYMYCF8SEpyVaEkFKc8RAr/gWW+/FBTIiNWHHtGOoWFbWktaCq1cW0
	YnUGh3w+oDQ==
X-Google-Smtp-Source: AGHT+IHJy5jf/nkFHcTuKmAZWrxeF0bdXR3TuRJ5r+3ScchBmI/bhZB5G506a0q+8dzai4Bbb1dnrQ==
X-Received: by 2002:a05:6000:794:b0:385:f64e:f163 with SMTP id ffacd0b85a97d-3862b397b58mr12534704f8f.32.1733837214035;
        Tue, 10 Dec 2024 05:26:54 -0800 (PST)
Message-ID: <904a209f-a917-4767-baf4-333b1cf8c084@suse.com>
Date: Tue, 10 Dec 2024 14:26:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/35] x86/domain: introduce domain_has_vuart()
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-8-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-8-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> --- a/xen/arch/x86/include/asm/domain.h
> +++ b/xen/arch/x86/include/asm/domain.h
> @@ -506,6 +506,9 @@ struct arch_domain
>  #define has_pirq(d)        (!!((d)->arch.emulation_flags & X86_EMU_USE_PIRQ))
>  #define has_vpci(d)        (!!((d)->arch.emulation_flags & X86_EMU_VPCI))
>  
> +/* NB: same symbol as in Arm port */
> +#define domain_has_vuart(d) false

This being the 3rd effectively identical patch, perhaps instead we want
to default domain_has_vuart() to false unless an arch provides its own
definition? Much like we do for a few other such items?

Jan



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 13:30:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 13:30:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852407.1266207 (Exim 4.92)
	(envelope-from )
	id 1tL0Jq-0005rb-PJ; Tue, 10 Dec 2024 13:30:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852407.1266207; Tue, 10 Dec 2024 13:30: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 1tL0Jq-0005rU-Mg; Tue, 10 Dec 2024 13:30:30 +0000
Received: by outflank-mailman (input) for mailman id 852407;
 Tue, 10 Dec 2024 13:30:29 +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 1tL0Jp-0005rO-Fn
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 13:30:29 +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 eb1ba314-b6fa-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 14:30:27 +0100 (CET)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3863c36a731so1720034f8f.1
 for ; Tue, 10 Dec 2024 05:30:27 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-434d52cbd72sm230709945e9.44.2024.12.10.05.30.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 05:30: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: eb1ba314-b6fa-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733837427; x=1734442227; 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=XyJBdey3p6iuG1n18uVDr94Cn3NvsWWrH930guGT5y4=;
        b=TTG5B18DgY5c4y8ISPKkg+yi1eCN3v6Xp01M5XvwsgrFRLOPL6+1EVDbgNDcwYKwxR
         d2hT1S8GTQ8dRZaShPA6U3IqOZxIiOkIG18mJKE0BeV9+Q+cMM81aSyA4w30EBFxNixy
         6jIzTl+CxwJ/ztUJ0w2Kh5euwt2kWLW7R3/kyj2yOCxnA4ezJu+tKQ5d9uN28xnfjMUa
         rqr0i8TwKpTjwR0qaGm8qNuSmSPlNMNlLtT9smpbFRKtXHcOwJL9/jmH4qsTZVaSmaJP
         qjvka/gpTzSjGNQY/VTqJqe8KqsWZFr1uVi9PcTnLhVplzPcBlGjBvqNEdZ8mbFluDP5
         SZ5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733837427; x=1734442227;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=XyJBdey3p6iuG1n18uVDr94Cn3NvsWWrH930guGT5y4=;
        b=VoWfoFulfmCV3l0H88WS+u7qhM6qc97kFB7/KVKrXyrqO0+2AaQ74JIZunopPQh9Zh
         E9UgKh3bRfisd5G0FKsiWq4gHVnmiMUV2qyZ7hCXAY3MsTSxfgvwzssp3VyQ1erSHEoZ
         KFlnxxzAPWaQAGJ/P1vqKlCldteIcDcVgCfq7XcAX+gapq6Oieicurw38ABf9IZQ380t
         VyeH3YXv6nfnomv8V9B7VIDq5z4GkXCBThAXVkTPVQtaNNbof4evduqBSGJmJp1jxYxT
         z4a0UfHCRl+qN6vH7y7nzdYplK2ZUFCzdjWQpP2WrmY34MOVVXnIiONfjCYKpVOEPQr9
         RfyQ==
X-Forwarded-Encrypted: i=1; AJvYcCWYhLGKBIBntGWoWCkDAlDROnhtr6VgKLenQBl0HQdJJC/LNNPTIIy01dno8SwlqQn3SPnnsRhsF8o=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwmLQPXyd54d0pvt1sv+xXv7XuQQOCrapAyG98kVPji0ibmoAwt
	b6Wp3hUrv8H2GSXMCdfZggimBZ5yhyhgdCFK8eaFaJhdU/5jMkvmrUkfd1Wn3Q==
X-Gm-Gg: ASbGncvAja6D252vE8eL0502W6TQRKkHyrkBOBV7dDiR6LqAskywrWfIY6iZABT2inj
	rtc/OIO0ykU2BrFe78BuhvRBs2RMhLRyzRuuiESoon84cHswG0gtxKW4HR4ut2EHVZSupy2wL0D
	YJa1SMkJBAciPyCKMU9ZNZgYCuzU390oJ1raid2k7dre8GStzw1gmzsFuHZMGH//C/OrjqJUzEu
	D9Mavy6SN8TcndtB8e4ANsRfTi8RsI07CIEuAB6JSrWKpcDlUFRba8vzFStwjivoeLEU85ieyIo
	MJiPICoPTyE62uChc9eXdRGFBw+kPMOG9Dkp1911ta4hShKaIUJEfwAYGUnKMLNWf0UvUcrma6C
	levNtmlqVfw==
X-Google-Smtp-Source: AGHT+IFVRfAlkqJnjo2m8OY8QXIAgnvdEmrVrQESMpo6C4LWjkxN2vihnMeWp/rx3gDjRil0s/z/lw==
X-Received: by 2002:a5d:6daa:0:b0:385:e176:4420 with SMTP id ffacd0b85a97d-386453c5e67mr3616947f8f.10.1733837426841;
        Tue, 10 Dec 2024 05:30:26 -0800 (PST)
Message-ID: 
Date: Tue, 10 Dec 2024 14:30:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 09/35] x86/domain: print emulation_flags
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-9-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-9-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> Print d->arch.emulation_flags on the console for better traceability while
> debugging in-hypervisor hardware emulators.

Personally I disagree with such extra printing. And that would in this case
even apply if you used dprintk() or gdprintk(). However, if others support
the idea, I don't mean to stand in the way. Just that ...

> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -818,11 +818,15 @@ int arch_domain_create(struct domain *d,
>  
>      if ( !emulation_flags_ok(d, emflags) )
>      {
> -        printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation "
> +        printk(XENLOG_G_ERR "d%d: Xen does not allow %s %sdomain creation "
>                 "with the current selection of emulators: %#x\n",
> -               d->domain_id, is_hvm_domain(d) ? "HVM" : "PV", emflags);
> +               d->domain_id,

... if already you touch this, please switch to %pd and also ...

> +               is_hvm_domain(d) ? "HVM" : "PV",
> +               is_hardware_domain(d) ? "(hardware) " : "",
> +               emflags);
>          return -EOPNOTSUPP;
>      }
> +    printk(XENLOG_G_INFO "d%d: emulation_flags %#x\n", d->domain_id, emflags);

.. use that here.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 13:33:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 13:33:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852422.1266217 (Exim 4.92)
	(envelope-from )
	id 1tL0Mk-0006tT-6N; Tue, 10 Dec 2024 13:33:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852422.1266217; Tue, 10 Dec 2024 13:33: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 1tL0Mk-0006tM-3t; Tue, 10 Dec 2024 13:33:30 +0000
Received: by outflank-mailman (input) for mailman id 852422;
 Tue, 10 Dec 2024 13:33: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 1tL0Mi-0006t0-45
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 13:33:28 +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 55a10427-b6fb-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 14:33:26 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-435005192d1so12343215e9.3
 for ; Tue, 10 Dec 2024 05:33:26 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-434fbec5ee6sm56777465e9.35.2024.12.10.05.33.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 05:33: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: 55a10427-b6fb-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733837606; x=1734442406; 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=OuWYudG9spRJE1PJmgun6GbyDsZzVlaB16S+5fdWykU=;
        b=Q0lDtLRRnUCCbCvw0qx9W2aYrobba1/uLIkd0xYV/sjiOW5yA1BX6UvYIO+WF90DAj
         XUwsejZTskZqhLsKJcB1yWOMnDp6PBz30PsL7svfVllaknmU3N33NEcg/0Z6CpsmswF+
         518adDMFebqaoRjkJcPAAnmgsFBBOrF4Fo20rByknZ6Kz+6WadWan9PHj5qL4QLkXzmg
         BmAjZVqGi/kRrEuuUARGFTXRMETYqvH4c04j85j1rENuu0BGQcDu5nWrP6FOeh35zWQC
         Dxf5XZ39Y8s6aUcbvjfYb4jtAOfR1K8Pokky1DYTZD5uJxaovTGl8m4sGEVA0wmOZSkO
         cLPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733837606; x=1734442406;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=OuWYudG9spRJE1PJmgun6GbyDsZzVlaB16S+5fdWykU=;
        b=OFkp2Or+T0kbELB4QMCrw8dytRaXxcwJls48pGMzuKHTlxWuKpFbLfbEHYq/m2M2YZ
         EydWFWnzPNk2oK+70y3SyiMQRoOV498Xt/uGWe6heflUoUIeMaMDesYdJSktcNIVQwe6
         UPFwnWRJk81cM+tnbuf0CtVtjbFzthXmP515z3zuIiI4rPCfLUpvsrcgecd8nezMUIhy
         kdqzxtAaVvjVKCHcQaaaiHMV3HLIIBFNX+p7r/6phruZegIDXVv6SrB5dL3ZPoloAYsE
         D5Ok/44agpxU3IoQZdU8rQarCw7/p1d19Lht0S19qEqMmfxULO8ngpgsXyD7dsZ44BAZ
         IS9A==
X-Forwarded-Encrypted: i=1; AJvYcCUwLwaE/GRiXtCatMJWC/GYv9FcHxl9MNYZJhYF/Ha6dS0ZxtsQ4+oACyJEQM4myfAcZtJC/OunWuU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyBdp8FKwJ7v/vmEX1VNBGH9UfakCJjSl3GLepvBjHtSEtaV5GH
	nHbMHKH3L1J5Fcxfs0dFu32KZdpLIF6/3085YS319ab8+lnA6oiILQCtw2rCPQ==
X-Gm-Gg: ASbGncuMiF77c74/tzGJRFgmfEvbxSSUQwGZthOJCTTNarBEjze/5RyBrcS6WXc9gvs
	4tuoQGmFmXMB8bvy1xOnbYfjHO39Un6YwmMs1Dysaz0QNX5BjQ8p2C03wO5IQ1sVrrpvCeMx0cf
	KngmrLN34pldLKFMr7w05EPNh7OtXF0tGOzK2IYfOjlTgcJuyjXvqw2popPDkrJuj4by2UtEJck
	e5O4UGgw3OQWtW1KQ+4f/rbZex4GJfmUeGJhLGvD/b6waWWYXUsf+v1b+qHUY48ZGdcJ5DH4Ppc
	13SScGIJq0ukL0BkMwagpoAd0f7OSrvGht1rL4gWNYylsoAbfzJsof6zNahyWNHFgS9/SxfxDwn
	AsXj6iQD4gA==
X-Google-Smtp-Source: AGHT+IENzRvwwzRbPyaZKA3r1zjrC6iztnsDJifXbpt78lzCcRJ2BCDl9fV0LZ3/kZSUFybBaZHnaw==
X-Received: by 2002:a05:600c:1e27:b0:434:f804:a992 with SMTP id 5b1f17b1804b1-434f804ac4emr57309265e9.32.1733837605644;
        Tue, 10 Dec 2024 05:33:25 -0800 (PST)
Message-ID: 
Date: Tue, 10 Dec 2024 14:33:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 12/35] xen/console: move vpl011-related code to vpl011
 emulator
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-12-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-12-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> --- a/xen/arch/arm/include/asm/vpl011.h
> +++ b/xen/arch/arm/include/asm/vpl011.h
> @@ -69,7 +69,7 @@ struct vpl011_init_info {
>  int domain_vpl011_init(struct domain *d,
>                         struct vpl011_init_info *info);
>  void domain_vpl011_deinit(struct domain *d);
> -void vpl011_rx_char_xen(struct domain *d, char c);
> +int vpl011_rx_char_xen(struct domain *d, char c);

If you make the function return an error indicator, ...

> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -559,9 +559,7 @@ static void __serial_rx(char c)
>           * domain, without a full PV ring to Dom0 (in that case input
>           * comes from the PV ring), then send the character to it.
>           */
> -        if ( d != NULL &&
> -             !d->arch.vpl011.backend_in_domain &&
> -             d->arch.vpl011.backend.xen != NULL )
> +        if ( d != NULL )
>              vpl011_rx_char_xen(d, c);
>          else
>              printk("Cannot send chars to Dom%d: no UART available\n",
> 

... how come that return value then isn't used anywhere?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 13:51:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 13:51:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852440.1266227 (Exim 4.92)
	(envelope-from )
	id 1tL0dQ-0001f9-Hv; Tue, 10 Dec 2024 13:50:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852440.1266227; Tue, 10 Dec 2024 13:50: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 1tL0dQ-0001f2-F4; Tue, 10 Dec 2024 13:50:44 +0000
Received: by outflank-mailman (input) for mailman id 852440;
 Tue, 10 Dec 2024 13:50: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 1tL0dP-0001ew-W4
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 13:50: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 bf86a9de-b6fd-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 14:50:43 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-434f7f6179aso17959115e9.0
 for ; Tue, 10 Dec 2024 05:50:43 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-434faba810csm63638035e9.18.2024.12.10.05.50.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 05:50: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: bf86a9de-b6fd-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733838642; x=1734443442; 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=yRQRnTQLxVfC9hbW2AtxPky8ROS9dCdc4ZirtoB7yCs=;
        b=Dtx1N7WtD0LxB+TRK7Kwj9H5Mz5TbiCLlEmrJa20pWswdKjU5s8hy4PCcj1TduQxhZ
         TuZ7+7BA1D2nQ8SPdCwFU8Yhn6XLFl10Ta4WlvX0m6bCFdeKK8hVTiALstGJH4lByyx4
         nXI8mAhVhBJkTsnDZqwgKV30kn07rlHQJ0BSwOIv8xlk9uf5nwwI01ptRCzwvtvfWSet
         N0gEhc3rQowURJ7NcvEYp6eaIrUk+mrsAGStLqz28KJfU0mPR7gGnhBtHaVGj6TCBZMd
         E7JMIbj66J0ZAbC6SHaBe98fRFVlJk6Lg0EqppjNFImbN7YRafGWIbVy0xfHqX9eQBBH
         DUmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733838642; x=1734443442;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=yRQRnTQLxVfC9hbW2AtxPky8ROS9dCdc4ZirtoB7yCs=;
        b=jVfosl/fpmLjx4yWKWn2cg/GOigX4idANpUCc9oMrYfb6JRe8+wTpzWiPWArGDBazK
         ZzVQ04oaBohGpjUFMJUnUuXQiEGKIQHIKmD9JJNox4R7Knsuubbe3YG57UgERjgB05qR
         jY6yGE5O5O69EcAzFKOYe38xDXk2s/P+ToEUnSuM1dFKWrFqDilJTu1B023P5ixf4sfB
         +7S/A/QCZyLL5PUHDs3uzH43oqF0wTRisyf1fYSA9tv8Y/Dbyj3ZalIM9M7TYE4OU96K
         Wxmro8PKIHw9b5Uq8qUeGObRsPT2c/sqFFxwkrp7Wg8qmYqJx5aj9YnS6cdGrp2sxga8
         BTfA==
X-Forwarded-Encrypted: i=1; AJvYcCXJ3s0dBNQiFfTYQmNUZjHRiQF9BVBjNz/f7XLjHjqfBtbYswy3NOollX0RSjblBpkvuPqj7UY+8Gw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwejTVoLjraN2oUZhjZVF1aQkWgNn3f+AQV4RyX1M6ReXVyZv2s
	Rx7ZAVOUVBorNPvQs4wecYZLFcjrmadBzXqL4niyxidNKEJKnJokyWZXihPkDQ==
X-Gm-Gg: ASbGncuBoaH/hnFnCBNoQanwQI/HGx0vnrHXYKVtSfZcA5HUzUqjEo0VGf+06gAu3EV
	MFtWrl2QwRE0xEtnOgh4wvH8pq2mg5eKPRwUa6yC1bH+YrUji3RLE6IAzb4DDO6btx2QWEMRuaS
	3snX30o6rT7Q294+VRmZPxl7idm4FzYDMqr9I63UZT2YMYLHq7VolYExM6yqPaUNSjWzHiEEq78
	Y5xqri6KCGz5XeYM0nCOm+Z50Lv5RF6gxqaYV8XozgUqRxhxxAVrfSoLJMNRMj3l1S1gvYSMxOH
	F+E2hJaZEym7B3UEx3+57Ln5nmhGAaZdu5FoeEzcv6aHNJLZ/yG9U63uDFMHYabMaGWyWT0yQWT
	4vHw4dd79OA==
X-Google-Smtp-Source: AGHT+IH9fPaC9k0MIgG4llyYPXB92eNDu1KuAWTYRNy1irO0JU3QOctiS+lKXX2cjqm4jUpem7l76Q==
X-Received: by 2002:a05:600c:4e89:b0:434:f609:1afa with SMTP id 5b1f17b1804b1-434f6092328mr69898625e9.4.1733838642424;
        Tue, 10 Dec 2024 05:50:42 -0800 (PST)
Message-ID: 
Date: Tue, 10 Dec 2024 14:50:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 10/35] xen/domain: add get_initial_domain_id()
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-10-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-10-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> Move get_initial_domain_id() to a public API and enable for all architectures.
> That is pre-requisite change for console focus switch logic cleanup.

Yet then how does this fit with dom0less, let alone hyperlaunch,
where multiple domains may be created right when Xen starts?

Plus, if you make this generic, shouldn't Arm also be adjusted to
use this function (if nothing else then to avoid things going out
of sync later on)?

> @@ -2229,6 +2230,15 @@ int continue_hypercall_on_cpu(
>      return 0;
>  }
>  
> +domid_t get_initial_domain_id(void)
> +{
> +#ifdef CONFIG_X86
> +    return pv_shim_initial_domain_id();
> +#else
> +    return 0;
> +#endif
> +}

Imo this either wants to use CONFIG_PV_SHIM instead, eliminating the
need for the pv_shim_initial_domain_id() stub.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 13:57:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 13:57:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852454.1266238 (Exim 4.92)
	(envelope-from )
	id 1tL0kE-0002dg-7L; Tue, 10 Dec 2024 13:57:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852454.1266238; Tue, 10 Dec 2024 13:57:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tL0kE-0002dZ-4e; Tue, 10 Dec 2024 13:57:46 +0000
Received: by outflank-mailman (input) for mailman id 852454;
 Tue, 10 Dec 2024 13:57: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 1tL0kD-0002dT-5Y
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 13:57:45 +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 ba14e0d5-b6fe-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 14:57:43 +0100 (CET)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-434a2033562so50578275e9.1
 for ; Tue, 10 Dec 2024 05:57:43 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-434f5774454sm84508125e9.13.2024.12.10.05.57.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 05:57: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: ba14e0d5-b6fe-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733839063; x=1734443863; 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=mexqWB4ToY1R/WZwNIYERX0OQh2A1Jz2DsN4cZ8rjSg=;
        b=UvAVDN0q2ujrXIxkK1kmbIh8iNqhnND0dxw9yNlcjozPYqpoThKzz4DAeOJ7FVRzlB
         nsuvU2iNkFS/Iu09myt89J5byIRD/OOOud01GdyKmR4wG1kORDcNnwCNHFBXPPfggDYi
         UdqJ9EZ8hggJZd4eB3O4K+QQgOvuNS+6fokcvX6NHhmIeBf/LeAPj9ug2+TN8rorbOSB
         cG07FEGpq73q8ni3NBWanGBQOgWkodWk7n+OS9yeXKe5XOMYias2UyZSZvR3f8IBb+C7
         JWH9tMniAlnPvF7S9VzFqnW4dY2PRkhga0e28NAZh6rp7aUClTb9ZU0gx8fs/pBS933y
         o4yQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733839063; x=1734443863;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=mexqWB4ToY1R/WZwNIYERX0OQh2A1Jz2DsN4cZ8rjSg=;
        b=uuOCiJwjUMqp0IWmS3QFd2OAlZhDimjpw0YXhZbAVlCWt30e2k/ANFKRgkEWZVwEbB
         uomRntirBd8sdjxqzSxurqR9kz6LwbeyH7uy3hzGiy+dFi0O6kuyBWJllRaqrXx4Pz0g
         f8o074ONzHF1t+Ko1Py4C9DTpW1p/hpguSxxqEONj1uM2htOobXYaFR4bvK1veUxD1io
         TUuq8quVRPwPR22A2LCkIGxseT6GK/G97COla7/TlXogdF3+hyzHUlZo4pBIVI+Nfk9w
         ZnymUjy1pSmguvJQZ1v0EwvWk8grc8YcZi0XTIBA4w8CA5W7cwnPQ7mfbjpcIWs2vS1n
         XFag==
X-Forwarded-Encrypted: i=1; AJvYcCVyUPJ0b1rkPwXsQBXJFG64Gdgni5yAoSmbdeBfqY6itGEKc9KDoS5vptg6bY3R4FWZ2ce3f/7dzPc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwPYaDsY1UpcLWCrKsL6pYk9hgJnt59C+CJjPCnyKG6+tlHMuAd
	kVmsjBsovNb8R0Vyoz3pw7sRZmxRVE2OfJtRqQFAGjpVWCbTYHnwyRCRHo9XfQ==
X-Gm-Gg: ASbGncsb1ppOy0xJtqN+WT/GBrnr2Ru6RZt67TZe/EiXrvfhImTOOcA/2r7dpE4fTbc
	CbOevHOPblnCK4ekMLVm79ZtA2ahqdMb87VSaye2xRgdpzQk4Qk9xvmqVTU/Df+8ozfr5B2HXtx
	w3HedICiWMTOQZv6gZKWz59a4q+OHsJpoGcvQEdp5Pg3TMEElMwcx3xDRH3xNYC3Va7lnzCgLqT
	MIPrJeL0RHoX05RvsO0NmtGduWwGqD1JUCfXzvNRMmDk1If/prLegPg3mEXBwzA1lWeMzTcukcI
	/BKseEIuXCEMvzRxrUj1z8I2eBFWPMUp0Den2Qh0yWxlbQczBmJEaVk+b1ZLofthRnHz3E6LXKr
	mnf/pMXvx+g==
X-Google-Smtp-Source: AGHT+IGolCklT8SvwQB74vZ9/3UsfKXlQmL45/6LYQlnpxh+LVG/V1QWUQVLDMWKDB+4Oukcevn5Bg==
X-Received: by 2002:a05:6000:1fa9:b0:385:dc45:ea26 with SMTP id ffacd0b85a97d-3862b33e10cmr11153970f8f.12.1733839062714;
        Tue, 10 Dec 2024 05:57:42 -0800 (PST)
Message-ID: <32065c58-ca83-4a18-8831-6044da2377e9@suse.com>
Date: Tue, 10 Dec 2024 14:57:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 11/35] xen/domain: enable max_init_domid for all
 architectures
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-11-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-11-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -65,6 +65,9 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
>  static struct domain *domain_hash[DOMAIN_HASH_SIZE];
>  struct domain *domain_list;
>  
> +/* Last known non-system domain ID. */
> +domid_t __read_mostly max_init_domid;
> +
>  /*
>   * Insert a domain into the domlist/hash.  This allows the domain to be looked
>   * up by domid, and therefore to be the subject of hypercalls/etc.
> @@ -815,6 +818,12 @@ struct domain *domain_create(domid_t domid,
>  
>      memcpy(d->handle, config->handle, sizeof(d->handle));
>  
> +    /*
> +     * Housekeeping for physical console forwarding to the domain.
> +     */
> +    if ( !is_system_domain(d) && max_init_domid < domid )
> +        max_init_domid = domid;

Yet this affects all domains, not just init ones. Either the variable
name is wrong then, or the updating logic needs adjustment. The comment
in the earlier hunk suggests the former, yet then this is a behavioral
change for Arm, correctness of which needs explaining.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 14:01:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 14:01:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852470.1266248 (Exim 4.92)
	(envelope-from )
	id 1tL0oF-0004NB-PW; Tue, 10 Dec 2024 14:01:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852470.1266248; Tue, 10 Dec 2024 14:01:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tL0oF-0004N4-MM; Tue, 10 Dec 2024 14:01:55 +0000
Received: by outflank-mailman (input) for mailman id 852470;
 Tue, 10 Dec 2024 14:01: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 1tL0oE-0004My-AS
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 14:01:54 +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 4f27f97f-b6ff-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 15:01:53 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-434e69857d9so19234175e9.0
 for ; Tue, 10 Dec 2024 06:01:53 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-434f7160599sm80630135e9.23.2024.12.10.06.01.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 06:01: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: 4f27f97f-b6ff-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733839313; x=1734444113; 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=FhyBiK50u5Rd3uOWBiKxO6LYM0ifTZtCXe5MmUy31r8=;
        b=d9AR4isoDVCjR2nRdHJouT6IRM7/jwSKDNE7uOmsahsNMfFv40MtVMPmlTuxkZuu5F
         byeGFTnVoLM3d4PCo8tKPjRYHKgiYzi3V913D6QBUN55tHtLL+IQi+W+InMy3n0HBr5R
         ZOilNoxxr3mqsi+0vyXAw+8LQ2f3uZ8ev/7th71qeU8xjPu7j1DVj2KaMtryF/SkC+/a
         L8krHF0by9I4w7tGeuus3aFQQ4fC7M/Qcmbo/R0QBgZyaGi+JHNnHa2G//Q9vQ8WjyBV
         pXOZFC/3KXZ/zUA5x8HsFTiJPbCzyxXDPAGVE8FGJBkgCaT1/e+k1+NosL4jQpj6Wtbh
         rIhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733839313; x=1734444113;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=FhyBiK50u5Rd3uOWBiKxO6LYM0ifTZtCXe5MmUy31r8=;
        b=rrKAwNdfgLMywxffT/ryZOs4XqAEYjM4Gprm9+M0jTON6zDMFwCEm7OwF1jvI2YT/m
         /4iFboWgF1aTBdoQviRbvcc+KxXQx2UslBB6KqaE2sIJgr9UPQEZ4/jVhVXLWsYqpSIH
         IzoztUxImiHdSI4fPjAKZ9tLB1xm3nsXyarldAMOh9VBAir31V8U9UuwhVeTj8ln3ibL
         o3ueXcNpL4TJfrfN6v+Qo+36hn2OSumKjBL1qyYcBX1/y5jBYXMbahSaGqCbD1v2B7pL
         uyyCBI4M2AnOC+SazDMHSMcytLNSV4Fu/GK2mvVK10zNcxtf+lG2hxwwdvno0kNzV0Fg
         PMmQ==
X-Forwarded-Encrypted: i=1; AJvYcCX/6OXRCNdeXyOj/P5AGpAGDLBqmIVnfbfpRKrJX0o8zGNphDvcI2fGlAh7AIWiX55w4j17lWPhZFE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyP+MMAx4M4keLzN8hGHWtBr5EOcD5vDBmsoozacNBaWwy8mGLB
	Xp+5ZZYtv+H8nhBd3mOneyhkOeFYp5Ma52EadTtJv3wsEr34QNz9v1My+bzPSA==
X-Gm-Gg: ASbGncsv6Q/zweoXFhYIuZDgPnjPqkZOP5ORe5NcEy3bw/lFXk4AP31yrLpQzg2GEZf
	8zr8zHZy7xyKAtRAGBN7Qeor+0Ffb77E/bTsYlROB0Rf6xVwaCVNc2VFf+ju8BAekOe0ln1APrn
	bN596DiZSRZwFVriLPIiEe3hVe3KodFCqMWYhOGAcblw+P5bp+Rupr5mi1dQheC1FIsh9U7wE+t
	dJkieHQXKkERTS6xLK7LPyzQzemy35bixgxdHu+kT7zZqZbVLSH/89H+QiqmCLgE6maw/B1F9hx
	/9bxaWU/yVLnMtsUcA0LKStJStRaizjnW7M6BiNab2dipPCi2m2MhgIAnAnOJRudkgyPCE/vm7Q
	nxbqWkn/wNA==
X-Google-Smtp-Source: AGHT+IFPvNa89RJ2EH7MzLqGmZipbEFkMLfA0VNKlZBj9TakpSiv7RIPDCX+e+gofaYn3JKQ054Dgg==
X-Received: by 2002:a05:600c:510e:b0:435:edb0:5d27 with SMTP id 5b1f17b1804b1-435edb05f57mr15977715e9.9.1733839312129;
        Tue, 10 Dec 2024 06:01:52 -0800 (PST)
Message-ID: <16b43ca4-d56d-4c1c-b43e-1e3bd4919857@suse.com>
Date: Tue, 10 Dec 2024 15:01:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 13/35] xen/console: rename console_input_domain
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-13-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-13-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> console_input_domain() takes an RCU lock to protect domain structure.
> That implies call to rcu_unlock_domain() after use.
> 
> Rename console_input_domain() to rcu_lock_domain_console_owner() to
> highlight the need of calling rcu_unlock_domain().

While I can see where you're coming from, ...

> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -477,7 +477,7 @@ static unsigned int __read_mostly console_rx = 0;
>  
>  #ifdef CONFIG_SBSA_VUART_CONSOLE
>  /* Make sure to rcu_unlock_domain after use */
> -struct domain *console_input_domain(void)
> +struct domain *rcu_lock_domain_console_owner(void)
>  {
>      if ( console_rx == 0 )
>              return NULL;

... the new name no longer expresses that a domain pointer is being returned
(out of thin air). I'm uncertain this is an improvement.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 14:13:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 14:13:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852483.1266257 (Exim 4.92)
	(envelope-from )
	id 1tL0zO-0006eO-Nw; Tue, 10 Dec 2024 14:13:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852483.1266257; Tue, 10 Dec 2024 14:13: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 1tL0zO-0006eH-LN; Tue, 10 Dec 2024 14:13:26 +0000
Received: by outflank-mailman (input) for mailman id 852483;
 Tue, 10 Dec 2024 14:13: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 1tL0zN-0006eB-BK
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 14:13:25 +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 ea4e553c-b700-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 15:13:23 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-435005192d1so12775175e9.3
 for ; Tue, 10 Dec 2024 06:13:23 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-386220b047dsm15975045f8f.100.2024.12.10.06.13.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 06:13: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: ea4e553c-b700-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733840002; x=1734444802; 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=LEi4sYW9tslY79x0s7lrA3FZuLBUhpRBvUZs1d+7ffM=;
        b=RRggAGu+Xfb/jRSrSYuYMVODMNLappNPySwxMwsdOkNy6GsYEH9n6sua8hdG0HSQY2
         M+TJ1oshqY5Fsthm8JJnEeLZ/y7yT6I9Fsh7CI47kfuXfT6ZaAWI41LZVAjAMRNwBinT
         0m/pTwG0mqSasENewJcn64U8r+WcEWbv6ACf9O1cvr0TBTfvOWXcaZ9DxHc8X0p9fJWV
         stm24iRgeN6niwgoq2wKIM33AT4wpLOJiBZ5ybE3iIoJJKb8/snPIjV7BDaJHmhOnYCr
         JZfsQcp2x8+Y8ynjLKV05689A77VbHrQgKyGn3Rjt4Cr8/OlY/oO6MRoR5fP9Gd0+U6V
         E6Gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733840002; x=1734444802;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=LEi4sYW9tslY79x0s7lrA3FZuLBUhpRBvUZs1d+7ffM=;
        b=XsQygHcu0vp7hWunnhaiLxgDUs0VN3d1341r5X4RzQvLGmTMWAKukaTLMmg94177fM
         oVfJPFS+WfjnxT80WI+vRRbrg/ZekTSEdxvPY35wcpg+R+/Itt/KRTXk3hG5YGj0Z1OU
         CJYJ+cw7o7qwzgqkeesL1RQ8IMjLaaXHrAkq/imifKNQICahDf8ca1N50Kz+vkE0QAAf
         ggmBM0FY/NkI7hzsgFeoramJsuBpmn9SJD5tLRMgvw3shDvDKY4KxXwFH4Vg+DTAD/Vy
         71jHSCSL4vUkmeU4G1zbWdORv0tKjojYm+CWtCizHxPzEOliEMdo5Vhtn7fcKIzLpoaS
         sztw==
X-Forwarded-Encrypted: i=1; AJvYcCXGkhIckOhXsHac0IdBLuBpkrm/lmo27K0vmNz54r09blYSvq7ef3g39qgff4vm/aG699mnKocyLsk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyt7G0duOOEvOEdIbDUhHaj3Tt5e0xwr0TgIZy3zo3wuBqDXhJa
	y9AivO2aMHN3VE9a78iGtooq0T7s76LQWeJbrNKRiRv4entfh1wqHogqYGucLw==
X-Gm-Gg: ASbGnctKlhgfblU54MjPdvf6ArFrs0val9WATkYch41+FI6t+TxpdOTejwP2lYuUq8d
	2KlbfGfcvvD8T26Mw6YKSgHuu3R7BDY7uxWJmY5b0pIzn8R/1SlRuaePgsBnn2pJb78lD/NUbWZ
	/HlUwSaqUiq9PG3vadv7hxubv0gGqDltXxjYO3pPvkODLKjp9V2iv9vV34Ax9C7h1RxNS2l4lVs
	MHW2JgFecQV1tja2j+fzFmSbaF1vTzoRaNaNUaBdLxlovwRy2dfpmtsKfUR+04go3tECd1v1CpO
	V50+3zmkdbdqEn7hvnYddlpKDMM9mL/IZim00e4pW1xwulr3DMFQ51CwTCOavhaDXzD+YUzzoJ/
	KdlIToMi1Yg==
X-Google-Smtp-Source: AGHT+IGZhYb2KtlxKgJzXm8nhnYihwQ2Vni/SzK1O4MOiNxsfFZT/PBQGG4t4U7N7DG66PVKnjCRHQ==
X-Received: by 2002:a05:6000:4704:b0:385:f44a:a68 with SMTP id ffacd0b85a97d-3862b39d760mr11555402f8f.35.1733840002548;
        Tue, 10 Dec 2024 06:13:22 -0800 (PST)
Message-ID: 
Date: Tue, 10 Dec 2024 15:13:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 14/35] xen/console: rename switch_serial_input() to
 console_find_owner()
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-14-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-14-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Updated the name to highlight the logic of selection the physical console
> owner: existing code does not switch only serial console, it also switches
> video console and debugging console (debug I/O port and console hypercall).

I'm especially surprised you mention "video console" here. Afaics all of
this is only about console _input_, and no input comes from a video device.
Arguably "serial" in the original name is too narrow now. Yet "input"
continues to be quite appropriate.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 14:23:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 14:23:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852498.1266268 (Exim 4.92)
	(envelope-from )
	id 1tL18z-0008Vo-Ll; Tue, 10 Dec 2024 14:23:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852498.1266268; Tue, 10 Dec 2024 14:23: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 1tL18z-0008Vh-Iq; Tue, 10 Dec 2024 14:23:21 +0000
Received: by outflank-mailman (input) for mailman id 852498;
 Tue, 10 Dec 2024 14:23: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 1tL18x-0008Vb-JO
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 14:23:19 +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 4cb58324-b702-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 15:23:17 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-434e9716feaso19434335e9.3
 for ; Tue, 10 Dec 2024 06:23:17 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-434f7676d45sm78958245e9.33.2024.12.10.06.23.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 06:23: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: 4cb58324-b702-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733840597; x=1734445397; 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=TK3qUKMI9El/3oT5DKlkszXI6r0GfSJAYOm6NcZVniw=;
        b=btoCCQve0Z1ervu975a8m0DGyyg6YetQpagKDpMxCi7I8sUPZO1WLjMbjrOBiDbQYy
         Xd7i7ZMBVIX0eSz6FLT1IZPA3jYj/jeH64Br3+wkm/yqReAicHUxYW7t/gEuuwpzAq5L
         unOzhPZlFWjH4QvSwPL0boL9KV3PQGQP7ch1FIu110JygMmTLOooU3+49MQm2HdZnF0N
         0/d/gGhAinYlo3ysiEmn2bmNws/+9kCzfQUdReRmz+iDMbYoY6aEmvuzIVNfLg9lSEX4
         gOrVssLkRNwyoq3WUeP7uNOdPOb0rQHlI3exVCtYiTu91x/WO4YcGMLWLfEhGFycwTxs
         DalA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733840597; x=1734445397;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=TK3qUKMI9El/3oT5DKlkszXI6r0GfSJAYOm6NcZVniw=;
        b=vZCAPc7ZuZ4AsX8XBxQdjOIFZFMcSFMbvnJafFpiN052NrcHvZEBPiNZibyTWusVNL
         tZ89tOIVC3g5a5/Q8z6qQKwoW3TN71hPkm3yb1orz/NSLK0/mvMDJPscSCIIfqGaB6+u
         Bpf0qIeS3Jh7sU21u+0OAyQ0jHVVWYgU44nrCONQWz7shaoykTI1E6CcwUqXMVXJZl8m
         cSFUX2BFVf7h+2tw5Dxkwe8RPMj5srMrlH7eGCpI/yr/QxAaTa+tbAwP710tR5FagPDN
         dUpjJyZ0TXFoWQBzClHkvcYDmTEcItPsy/MNc15musUVBTC2mv/qQhGxZpATDRz9+GgY
         BE6w==
X-Forwarded-Encrypted: i=1; AJvYcCXNDKJWcO88eIgUZWTQvg54OOiM47Tctsg5yTdrdzTCZ+T2O+FzFSamvzldSCq5V39PUpYra4VITPY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyX4Rog5q23UG5B5oeZnJ6gyhj5rAxO9LwOseTOVKp2UCvbLQhv
	netOkBSX86zrPaOcSUpuEE85tO2hn3974pHKHuGL3I0uKD95YUWcX278sc/DSw==
X-Gm-Gg: ASbGncs/KEbmLk6YoinRe1zP6BZrq4fgpZAiz+n8etIJRE2ebM8E++tM1PcqA7GmIA6
	bcX0S8zHDDpOkwkcqGe7kYqqVkZ4CHciH5gQiLPOt/KlyhcVHvjPUJuicsQFbn2cPYJMcVP16kX
	glwOBGd8X8wkBL/dbfVb+BxeLrKs2L8SpPldI8XedIZreEiahDZU4i+C2gKc7lYsoDIAp/mhZGZ
	hBBFoPdk3GuUKNOuAnEOUwJkV2rAsb0N6l+gJe/U17s6rHBef6WzvuPicmiFb1Rr31ZMQ91BxtI
	YVMCtBfj6JeBbSwrQbvvlr7Ako43LueREIQEL/W+4sG+I1I6A2JKnkC575geIP8F/hm5QP2eaFF
	WEt07Vom/HA==
X-Google-Smtp-Source: AGHT+IEHsyuhq+DGhOeH8Zdb6gHwYoyo7v7x5zc6xIzjI5Q8Y3e4O/1NrZt2cCqJVDq1OgCctx5Vnw==
X-Received: by 2002:a05:600c:4710:b0:431:55c1:f440 with SMTP id 5b1f17b1804b1-434ddeddac4mr148869445e9.30.1733840597153;
        Tue, 10 Dec 2024 06:23:17 -0800 (PST)
Message-ID: <5ced20ec-44d2-40ec-870c-e7f5f256186f@suse.com>
Date: Tue, 10 Dec 2024 15:23:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 15/35] xen/console: rename console_rx to console_owner
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-15-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-15-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> Preparation for the follow on change to switch console_owner to
> domid_t address space.

As with the earlier change - it's one thing to (plan to) change the
number space, and another to go from input only to general console.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 14:25:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 14:25:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852507.1266277 (Exim 4.92)
	(envelope-from )
	id 1tL1B9-0000eE-1V; Tue, 10 Dec 2024 14:25:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852507.1266277; Tue, 10 Dec 2024 14:25:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tL1B8-0000e7-VH; Tue, 10 Dec 2024 14:25:34 +0000
Received: by outflank-mailman (input) for mailman id 852507;
 Tue, 10 Dec 2024 14:25: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 1tL1B8-0000e1-3b
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 14:25:34 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9cd1f0e2-b702-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 15:25:32 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-aa66ead88b3so521224866b.0
 for ; Tue, 10 Dec 2024 06:25:32 -0800 (PST)
Received: from localhost ([217.156.233.154]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa6707a5110sm448345366b.36.2024.12.10.06.25.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 06:25: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: 9cd1f0e2-b702-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1733840731; x=1734445531; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NEofE3HrwNK50C5MWDNYe5n8nJp/eQjHZSP9LC4WWcU=;
        b=lakQIxO1njjVtMNNUqiNWswK+jFhyuodPNo+VO3vdKTt+6+8DjPBnsVbaFRszALZWP
         kbMcgZxiEZykWXZ9xpgRo+L5zDJEhyOYX40oDBok/XeD6M+RS8yHLFz0NRKAgUcsR+bP
         xT5FZWLBtB8Iv7cVlHQbUm8xbYJjUwaSP7yI0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733840731; x=1734445531;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=NEofE3HrwNK50C5MWDNYe5n8nJp/eQjHZSP9LC4WWcU=;
        b=xHSpoHbSMgzH2QGCeEjdoJ7K8Mn4cQ7Q3GOJpSiwkkd7K8tF8IGqxdpAI9xxNm9+/l
         +eEtbu6f2+W+/T9hM2o+R59RpbE7Hd+gNHkf81BBr8TyGQA6x3cPShcCXxoHCE71lc9W
         2TUGVHCWNZiy9MRxBL2zVo9WKN2CXSkLS77bYV6kwT3REdAkufgjLZ03DMvXwfk/lPvJ
         BtIflKiDoqlGr1Y/zGB3JV4HA3k0zAioJmDbdTZdwgxbs2K+ex+VBfAE2R3c97qMxdNr
         +egsXsOMUUBMdSZKZGHDsfanvDl1OzrFJmfNdsNK2HgADOWFL1yWsFgTIHxusPdwFEzx
         6Dbw==
X-Forwarded-Encrypted: i=1; AJvYcCUhEMLt2MxZpWrG0BzFx3dEcE76wIfolEZIQ1YkWfpZaDeP0awW9+9PU4oP7AJMLS/dki/63XKMr5A=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy0HLGkUDQo5Lz2RUdgHbSLCWkSClmtnnI6aiy9S1mBR42bPGn+
	CFg+Nzz//FZmMNsfoMGXYDH7tiGA661PtVuUWgWuoBFJZOPTPIVsITOvyW3LLhA=
X-Gm-Gg: ASbGncsHwFyWNFfaX/A8pEjPABjnloy6T64o0GaDCJHll8+tF8wVsOY+V54oG/NYrX5
	9niQ7VuWQHqsqG0QxnIbh+XBNpiFUe9vc3YE7KpLTsRUykojYqvW+4xssIPrNvXAU9fiMp2hXzD
	9ZGDSXfYL9jriWzlbYqIvsYamJ+ej+fV+dhi3qcB/w3FkovgqUsF/b3JBBGKsf3VBlq8GHUudi1
	cPTAE/bnfPa0Xj97NpowFu0kSB2fvNvqJCQ1neVvokC9w/EG+3bsgadRKv0hvw=
X-Google-Smtp-Source: AGHT+IFqoO8jyHrhvAG1IBFxy2Z6cpDlsKT+KPu2mgmpUZ10cpjmSX1y9hQpdi+4iwraJ7IJ77xIzw==
X-Received: by 2002:a17:906:1da9:b0:aa6:77a4:f675 with SMTP id a640c23a62f3a-aa69cd468d3mr451613566b.13.1733840731491;
        Tue, 10 Dec 2024 06:25:31 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 10 Dec 2024 14:25:29 +0000
Message-Id: 
Cc: "Andrew Cooper" ,
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH] x86/FPU: make vcpu_reset_fpu() build again with old gcc
From: "Alejandro Vallejo" 
To: "Jan Beulich" , "xen-devel@lists.xenproject.org"
 
X-Mailer: aerc 0.18.2
References: 
In-Reply-To: 

On Mon Dec 9, 2024 at 3:13 PM GMT, Jan Beulich wrote:
> Fields of anonymous structs/unions may not be part of an initializer for
> rather old gcc.

Can you add the specific version for tracking purposes?

>
> Fixes: 49a068471d77 ("x86/fpu: Rework fpu_setup_fpu() uses to split it in=
 two")
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/i387.c
> +++ b/xen/arch/x86/i387.c
> @@ -306,13 +306,13 @@ void vcpu_reset_fpu(struct vcpu *v)
>  {
>      v->fpu_initialised =3D false;
>      *v->arch.xsave_area =3D (struct xsave_struct) {
> -        .fpu_sse =3D {
> -            .mxcsr =3D MXCSR_DEFAULT,
> -            .fcw =3D FCW_RESET,
> -            .ftw =3D FXSAVE_FTW_RESET,
> -        },
>          .xsave_hdr.xstate_bv =3D X86_XCR0_X87,
>      };
> +
> +    /* Old gcc doesn't permit these to be part of the initializer. */
> +    v->arch.xsave_area->fpu_sse.mxcsr =3D MXCSR_DEFAULT;
> +    v->arch.xsave_area->fpu_sse.fcw =3D FCW_RESET;
> +    v->arch.xsave_area->fpu_sse.ftw =3D FXSAVE_FTW_RESET;

That's not quite the same though. A more apt equivalence would be to memset=
 the
area to zero ahead of the assignments. Otherwise rubble will be left behind=
.

>  }
> =20
>  void vcpu_setup_fpu(struct vcpu *v, const void *data)

Out of context and not triggering the GCC bug, but vcpu_setup_fpu() should
probably share the same initialization style as vcpu_reset_fpu(), imo.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 14:27:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 14:27:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852520.1266288 (Exim 4.92)
	(envelope-from )
	id 1tL1DK-0001CW-Dq; Tue, 10 Dec 2024 14:27:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852520.1266288; Tue, 10 Dec 2024 14:27: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 1tL1DK-0001CP-AE; Tue, 10 Dec 2024 14:27:50 +0000
Received: by outflank-mailman (input) for mailman id 852520;
 Tue, 10 Dec 2024 14:27: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 1tL1DI-0001CJ-RZ
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 14:27:48 +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 edbaedde-b702-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 15:27:48 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-434a044dce2so62502685e9.2
 for ; Tue, 10 Dec 2024 06:27:48 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-434f13f735csm106567245e9.16.2024.12.10.06.27.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 06:27: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: edbaedde-b702-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733840867; x=1734445667; 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=vOfm/yyzMif7rTbZnMfCUGikliN+PsefgdIovXgOM8s=;
        b=bEaXM0lXAufVkkUnxgqxyuss5f5feTYQtL1fnHs4UgXggyowFF/dRJP2LNIt2HHbra
         Uf700HrQjGKwol6y07Bb4sgvKyrA+dZgiRkzACMnsY63powysnM2LID6EIMZs1S6AChK
         ncPgG5gWjPv+B2zLd40h6CfhTFgmEmaEdf69Srfa80tJ0Gn1Pa7/14KhFi2++x7fILSD
         D5jm8F03HJ+UQYR0sShEa3869b9Ttb8lsR/9yRHjY/kcdfHVFRGHWExoZ1mh4tovTxhD
         XLc3FXg4fOUDH33PUJAfaaPoD8LLv2Ds31bQ74nmmZLicYV1DSDG95V6c75KitLivo6p
         gypA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733840867; x=1734445667;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=vOfm/yyzMif7rTbZnMfCUGikliN+PsefgdIovXgOM8s=;
        b=TNQngOHh+SJ5CzEklf7kp1i3GNZlBxGUZJwoUh5vZK+h6vYjPhnuJrTLll3Kcn/c+0
         ZY0X+lGuRvD5UwjkbFbDjASZCh+rZZWtmM/CuYBmcfiG3DUjtjlzM+NhlLILXF8Ni1O0
         BBNJruMSiOBAgCmhtCa/RWmL6VCm5BX9+GP199OMEaigELRxOAxdfu9lGwhzB+PeSHLA
         mIovKQio212vWFubY/3pMRU/3pGNK6BxxjHwBR79dTCthXmPEjIcMk1U7swGGXC1fcuj
         sEjnMio/FPgjUIfFMPbcXQIzgV3J1cLYCeuGt3EaO38mrKKr91Phroh2smU6UBzNPZx+
         6rWw==
X-Forwarded-Encrypted: i=1; AJvYcCWor4khDPIR1Or1gdtD/lbUAorEY4IPzYw/KwYz1zHkSwdOgYVByP5pLkrZ7J+TdvLBSI35ZhzgDgY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz2G5sf3gpt/piOF/ND45Yc3/cE8hfP/EXFTqN94kkOwEmGUfFY
	maUIyqQPPaf+kG8T8i+MXtUN4OKJvqBnJtdxKJbhnZ5pEaPJV2vuJuSP34jVwQ==
X-Gm-Gg: ASbGnctDeB0aQAfwvXZ1XCdlRfffgukuihAGd2xTmwSRD3/zC3z9GD5mxJs9xUqcB7A
	JfJTK3cV9uniXVbhaFWLWjPnhNhVa5PI1C8WHwe14dWZKlnzwF+tmWTIuqMUJTOh+zR2Xyrz304
	KDUAUQmzSrnoRrI3k8NIL+HsvzmwvX5DcKpXcnmugZH33/heaZWjHdwl1EaYpwyDC0yPfKSRtDb
	V5Pcl8LViA4YxQWf4uPz91belBweYZ14cEO9LlaNP50FuS+N7tmrZI7661MmNixtWqtxaI+YyfR
	pnKp6oOtXjRawx16s60LpMzF4jXkxWPVCW/2/oet85C7o/Qp/A9ySZYf+Tyh0MuofEPZbMGyrpZ
	8lIUvh1PZeg==
X-Google-Smtp-Source: AGHT+IGSJmpfOgBa8eaJ1maR+aoW7hB4KKXHezkINdsXXzapSjcC2LG3rg+b5Or6rg8Echa5s6BjyA==
X-Received: by 2002:a05:600c:4447:b0:434:a26c:8291 with SMTP id 5b1f17b1804b1-434fff9c4fbmr48367715e9.24.1733840867409;
        Tue, 10 Dec 2024 06:27:47 -0800 (PST)
Message-ID: <9c9120f6-6291-43d1-93ac-deebdc222f3e@suse.com>
Date: Tue, 10 Dec 2024 15:27:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 16/35] xen/console: introduce printk_common()
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-16-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-16-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> Introduce new printk() variant for convenient printouts which skip '(XEN)'
> prefix on xen console. This is needed for the case when physical console is
> owned by a domain w/ in-hypervisor UART emulation enabled.

Imo it should still be guest_printk() which is then used from there.

> --- a/xen/include/xen/lib.h
> +++ b/xen/include/xen/lib.h
> @@ -61,6 +61,9 @@ debugtrace_printk(const char *fmt, ...) {}
>  extern void printk(const char *fmt, ...)
>      __attribute__ ((format (printf, 1, 2), cold));
>  
> +extern void printk_common(const char *fmt, ...)
> +    __attribute__ ((format (printf, 1, 2)));

No "cold" attribute, compared to printk()?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 14:29:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 14:29:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852535.1266298 (Exim 4.92)
	(envelope-from )
	id 1tL1Ew-0001qU-RJ; Tue, 10 Dec 2024 14:29:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852535.1266298; Tue, 10 Dec 2024 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 1tL1Ew-0001qN-NN; Tue, 10 Dec 2024 14:29:30 +0000
Received: by outflank-mailman (input) for mailman id 852535;
 Tue, 10 Dec 2024 14:29:29 +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 1tL1Eu-0001ph-V5
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 14:29:28 +0000
Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com
 [2607:f8b0:4864:20::234])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 28a5722d-b703-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 15:29:27 +0100 (CET)
Received: by mail-oi1-x234.google.com with SMTP id
 5614622812f47-3eb7934a948so143023b6e.2
 for ; Tue, 10 Dec 2024 06:29: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: 28a5722d-b703-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1733840966; x=1734445766; 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=cWW5naczYNd45v8bpPkM9yKFkCN9DJw7HpGuugwtxdk=;
        b=NWo8Ye8/egWykI7kv23k/HidX7uBVSlgPOgF9eEunBNpNgKKQalG91dLwza4kRxWyW
         l8q5deUScBLU+3U8WdVLO6eGR3K5uizNQGkIaHI8BEW5nTekaiFMnQyCUI2wFXDXomwE
         L4n6cJfVYEuV8K/r6BQ4KumWf7NfrhqN865ww=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733840966; x=1734445766;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=cWW5naczYNd45v8bpPkM9yKFkCN9DJw7HpGuugwtxdk=;
        b=gZauvtffjjfyBNnQ7KKEHakQjtSK0edWbSzyN4LdwQN1biG1u0zCU+qQ/iHLDr/exd
         eWzfxumnf6rlRWtbgZUjFpsk6GFep/RT1X1EKBVYMiFc6jSZDhRVNtaPHrzEJViiYECq
         DS63rlfTV8YX3tN1DsCXY+G5IhBmDAaSe61nV+4rkBS67uPtVyk8R99Uo9Mqyb/mi6eo
         S2UhZ8t0N9wWAjVNYJf3rqR4E1usDl/Yr66QLP1akpMaaSfLRn7wWoFRUkmZ39if4Ub4
         cXghhWXNBk3LNfE+R4JDQW3gAdvAFPkC07UfJ29nHRpSweVXFtzSGpUOeXegJ30m4+uE
         P+6g==
X-Forwarded-Encrypted: i=1; AJvYcCVxSCyKdjl37UxHVeGTk3g4QNR/I9CC7xfKZJFWiCE4FeLiZzTHjOyRYN/b+Xt+4O8cE4MEUGB8cqo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwAuNzjl9g22LhT6/jJAg4v7PuXnV22yckpUpag1/PnrTzjSiSo
	VKlQwePbNyZNQ2l0VVz81fvh+/K2WCH9PMf/Pt4b1LLyTRPDXjBD48l3x+Ilh7TMIZmUNMaog7i
	yJswKCu6+H1RCTy3W37mStWMkXKYKpLs5g956OQ==
X-Gm-Gg: ASbGncuEwZqSucA38ZcgrIMRc0ti+6fERtCT/krbEsQc9aNu46PGW7mo+7VBrLGMAmr
	ddeFmFdmPiDcDUM0Qr/mdGsRrqQXUl2svCU70mw==
X-Google-Smtp-Source: AGHT+IFVNmBT0BEW3PUcKek50XhjepwVDT5qVOlUfiNLlnvrhgPcEwwNjf/QWMTnIWl1b1UrkRVkTJuJ7fc+d0GoX4M=
X-Received: by 2002:a05:6870:9d05:b0:29e:526a:eeef with SMTP id
 586e51a60fabf-29f7389c828mr11009779fac.34.1733840966093; Tue, 10 Dec 2024
 06:29:26 -0800 (PST)
MIME-Version: 1.0
References: <20241122093358.478774-1-frediano.ziglio@cloud.com>
 <20241122093358.478774-2-frediano.ziglio@cloud.com> 
In-Reply-To: 
From: Frediano Ziglio 
Date: Tue, 10 Dec 2024 14:29:15 +0000
Message-ID: 
Subject: Re: [PATCH v2 1/4] Use an include/boot directory to override headers
 for boot code
To: Jan Beulich 
Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 10, 2024 at 10:14=E2=80=AFAM Jan Beulich  wr=
ote:
>
> On 22.11.2024 10:33, Frediano Ziglio wrote:
> > Not all headers can be used by 32 bit boot code.
> > Allows to override some headers, we don't want to mess up with
> > main headers as most of the code is only 64 bit so the easy stuff shoul=
d
> > be done for 64 bit declarations.
> > Boot headers should be 64 bit compatibles to avoid having multiple
> > declarations.
>
> I'm afraid that in isolation it's not clear what is intended. Boot code i=
s
> all located in a single directory. Can't we use local headers there, usin=
g
> #include "...", instead of ...
>

That approach was refused. Some definitions are in the headers (like
CPU features for instance) but duplicating the definitions was
rejected as a solution.
So the idea is to reuse such definitions. But, as stated in the
comment, the "x86" includes are not for x86, but most of them are just
for x64.This for historic reasons. But most of the code is x64 only so
changing headers to be x86 compatible would complicate them for a
minimal gain.

> > --- a/xen/arch/x86/boot/Makefile
> > +++ b/xen/arch/x86/boot/Makefile
> > @@ -18,7 +18,7 @@ CFLAGS_x86_32 :=3D $(subst -m64,-m32 -march=3Di686,$(=
XEN_TREEWIDE_CFLAGS))
> >  $(call cc-options-add,CFLAGS_x86_32,CC,$(EMBEDDED_EXTRA_CFLAGS))
> >  CFLAGS_x86_32 +=3D -Werror -fno-builtin -g0 -msoft-float -mregparm=3D3
> >  CFLAGS_x86_32 +=3D -nostdinc -include $(filter %/include/xen/config.h,=
$(XEN_CFLAGS))
> > -CFLAGS_x86_32 +=3D $(filter -I% -O%,$(XEN_CFLAGS)) -D__XEN__
> > +CFLAGS_x86_32 +=3D -I$(srctree)/arch/x86/include/boot $(filter -I% -O%=
,$(XEN_CFLAGS)) -D__XEN__
>
> ... introducing a arch-wide subdir, which non-boot code could easily (ab)=
use?
>

You would have to explicitly add the "boot" into the path, it does not
seem "easy" to me, but if you really want to do it you can do with
these or any other headers, like simply "#include "../arch/arm/..." in
x64 code. Same easiness.

> Jan

Frediano


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 14:32:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 14:32:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852550.1266308 (Exim 4.92)
	(envelope-from )
	id 1tL1HL-0003L3-67; Tue, 10 Dec 2024 14:31:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852550.1266308; Tue, 10 Dec 2024 14:31:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tL1HL-0003Kw-3D; Tue, 10 Dec 2024 14:31:59 +0000
Received: by outflank-mailman (input) for mailman id 852550;
 Tue, 10 Dec 2024 14:31: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 1tL1HJ-0003It-IP
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 14:31:57 +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 81867389-b703-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 15:31:55 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-434a2033562so50898245e9.1
 for ; Tue, 10 Dec 2024 06:31:55 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-434e83f3958sm127960075e9.25.2024.12.10.06.31.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 06:31: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: 81867389-b703-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733841115; x=1734445915; 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=NtlEXwh6yYBs/wbgm42hE/EwOq6DI8mNTFjnOTacq1w=;
        b=Khcfm+d9xy59XeOKTvcfHDMJLrj/W3CmQKDA+8YUjek6oHQjD6Btqi4AF90xkaK848
         yljSZO/SsCEQYGcmHWM1wjV3m971WNG8cFxAxK2mXrC4nV84uR3IxwSZLVjKshto6Mu4
         +QOJ3xnSQY+yzxTpvnxbroNdoua+5Ahd16gPzlTJOsc5oolOpCviQjbWeBVC2RrfaXQa
         q2EfHly4/cHtD/gGLjpAlyDvzDsQ5d3e3yKXFTmb4rNG+/UrbGXtqCwmDBWBj99cCxjJ
         Wmf8GaZFTiGhfZwnZdJjZEmJDm2jj1CDj06e/TeS+dyBOmBqus6AMoNpOdrfUP+YVFmt
         gRJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733841115; x=1734445915;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NtlEXwh6yYBs/wbgm42hE/EwOq6DI8mNTFjnOTacq1w=;
        b=kPcEPfnvm43XWDqiYiA5rsH3Obxmjq60mgjJHnl16MIBcqs4bqrAk3M+VKi+On1srm
         6jYyQe6trpaVbV4vlLkp/a1YK7M6ngpm/L6kEcLwykVru1dFiW6OUPvP+vua6HaMnNeq
         Vaay4nhj/7G+xWMWwmtJRfdY0xF+jqzdj0r1X9Xtz7PGBLSxU3ZldoMSpTUlwLNuPAbW
         J5gdtAh07hHvN6Qq7I2CmGkP7acLJApc7HZ4S62a+pz8aAm36BIW2StQHxIx6e6qi1jw
         I/StrbDV1+pmItg0II2oi0xpX/VvNHG7V/J5phWB/htRrGMtzB3qf4DEZz7KGGl0Vzlp
         yvkg==
X-Forwarded-Encrypted: i=1; AJvYcCUVbs/Dm4sW1o/AfxpXCDhZ86TVTkuqxnp4FunNQUE+LTe0G1feR1vRygSHIqh8XuftO4E80JO2tn8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxG2AVvciXcUFyNFrnpSu3Mod85A8u/DVmKFUwaBSOxkI6mcf8E
	McSp0CTRo0rc0M7JsR5Q/ujJVw/sWy1jvHDXZHjFRuayLJ29fAD4349ve2vJbeeTn41gNDVfK/g
	=
X-Gm-Gg: ASbGncvwvWnugMiEtPXCHJH8jKmb3ymi/n5j30TBu1GBVPMYU2jGcxnWBjEVEmnVJXl
	R8IpgR6Qd5mhXDajJ9c630+S4naSLcl5Aj2zN+RxfbZz3VQdvLex0aBWymuWL2lrVea2iKUGfyt
	K5q5lKlesagnW83mPDNeYgMkD5hA0hDdbbSam6yaPPU2BYfECWGlNUGkpMvc2q4WG4zfCOEeEi/
	zOQZeBloCFvE/SrizujZEuW8kAhqknGJ6b//M29Cg97OciMI4yjc2q2cL7ZxzzxvDENMIQgPsbL
	6gFdDbJOkL0NKYXV/UtHMFy8A24Hyb/ivgG/ZXBUYTopuTbcUT7gv9128j7x+mXzsWLmLo1mTd4
	TmW0FJT1y8Q==
X-Google-Smtp-Source: AGHT+IFEmtvnklM3nnmWYiGcdCWSYmgaDSYQKIRk6zstYoaZarNl1fAnEoK8VltncZOBNphpZM6/Rg==
X-Received: by 2002:a05:600c:5587:b0:434:effb:9f8a with SMTP id 5b1f17b1804b1-434effba0e8mr104257545e9.15.1733841115150;
        Tue, 10 Dec 2024 06:31:55 -0800 (PST)
Message-ID: <1968c658-595d-4d36-8558-8f178f8ed531@suse.com>
Date: Tue, 10 Dec 2024 15:31:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 17/35] xen/console: introduce consoled_is_enabled()
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-17-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-17-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> --- a/xen/drivers/char/consoled.c
> +++ b/xen/drivers/char/consoled.c
> @@ -43,13 +43,13 @@ struct xencons_interface *consoled_get_ring_addr(void)
>  static char buf[BUF_SZ + 1];
>  
>  /* Receives characters from a domain's PV console */
> -void consoled_guest_rx(void)
> +int consoled_guest_rx(void)
>  {
>      size_t idx = 0;
>      XENCONS_RING_IDX cons, prod;
>  
>      if ( !cons_ring )
> -        return;
> +        return 0;
>  
>      spin_lock(&rx_lock);
>  
> @@ -91,15 +91,17 @@ void consoled_guest_rx(void)
>  
>   out:
>      spin_unlock(&rx_lock);
> +
> +    return 0;
>  }
>  
>  /* Sends a character into a domain's PV console */
> -void consoled_guest_tx(char c)
> +int consoled_guest_tx(char c)
>  {
>      XENCONS_RING_IDX cons, prod;
>  
>      if ( !cons_ring )
> -        return;
> +        return 0;
>  
>      cons = ACCESS_ONCE(cons_ring->in_cons);
>      prod = cons_ring->in_prod;
> @@ -118,6 +120,7 @@ void consoled_guest_tx(char c)
>  
>      cons_ring->in[MASK_XENCONS_IDX(prod++, cons_ring->in)] = c;
>  
> +
>      /* Write to the ring before updating the pointer */

No excess blank lines please.

> @@ -125,6 +128,13 @@ void consoled_guest_tx(char c)
>   notify:
>      /* Always notify the guest: prevents receive path from getting stuck. */
>      pv_shim_inject_evtchn(pv_console_evtchn());
> +
> +    return 0;
> +}

For both of the functions - what use is it to make the functions return
a value, when all they'd ever return is zero (and callers don't care)?
I'm also having a hard time seeing how this adjustment is related to ...

> +bool consoled_is_enabled(void)
> +{
> +    return pv_shim && pv_console;
>  }

... the introduction of this function (which by itself is probably fine).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 14:34:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 14:34:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852562.1266319 (Exim 4.92)
	(envelope-from )
	id 1tL1Jm-00046p-JO; Tue, 10 Dec 2024 14:34:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852562.1266319; Tue, 10 Dec 2024 14:34:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tL1Jm-00046i-FE; Tue, 10 Dec 2024 14:34:30 +0000
Received: by outflank-mailman (input) for mailman id 852562;
 Tue, 10 Dec 2024 14:34: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 1tL1Jk-000443-Um
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 14:34:28 +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 dc438098-b703-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 15:34:28 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-385eed29d17so3836639f8f.0
 for ; Tue, 10 Dec 2024 06:34:28 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-434f39653c6sm97268075e9.7.2024.12.10.06.34.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 06:34: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: dc438098-b703-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733841267; x=1734446067; 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=eP4phFgs+v8HUdiuLF/dOdt+yySmdFu8NJLZ/FDbxtk=;
        b=Qc8J4DbIF4M+BkjHiGMSVe1i4V6q3CM4rEPgtZ01UELGcAptQdZhjdvM0VAuNcsrJk
         qGHYic4kPoDPDfTmqhuVnjns95Gqkh93fzJz33goWtQZ4d3zb5AgNFSFQtb3jyyT2LtY
         5UIeS1jgoMfjakZo8ZnIn0sZieLaj4TvkSk/ayiqAUqCZGeTIcEGOc/FLYvXBzMQen9e
         pgkun1xSLSYJZm7OdcS4z/e+HQ5hFTBjpkndJoDrHeMPZHLsRMSEhD9UMvQeufeMyeQP
         f+vhp8mBJdmfQqLFtxlUzUp4yVrESTkstQziwQ4n/2dhq+bujf2aIfx6TPoicXBYTNsF
         BMQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733841267; x=1734446067;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=eP4phFgs+v8HUdiuLF/dOdt+yySmdFu8NJLZ/FDbxtk=;
        b=GUBk1PdZAj17u6mW6WlljdOBLoxkKZPVGCTYQSifs2gEaPGqGH/zH7Oa01YTuUxWlH
         +xZpuuFWqHQ7WLqhfLXTEE804SoiMCorxm+vZz4ZPs1ccD06ZHNW7ykDpeAbzVmmUw4d
         FeiDwq/+WElg8wYH1ETOra/jPQ71n9VjZxOjsx5RZnaAjmQsFy10ECxFUCiJfGFGTxyL
         vZRxwkCRhCKCMAU9N07pzT21Llv9J3PKpropGytNXzrpXaetcCHEgRcBXVuTdnk3jNjN
         uCLcplGXUkbFVFi0BNgLxqMebmRV7PyzcfyZzsfbiR4cjcNmLntCh4vXZL14RM/7MlOz
         63GA==
X-Forwarded-Encrypted: i=1; AJvYcCX5PYeL/RohugxrdjO1YoW8LKSAvecqqDrlBDAlGRBt+yqJQNv+yoT4GRWn0Y9w9NK4TirTChnZi/E=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxmRBzNc7sij70XepHcg+K9wvshgoSNLUMcnAyXbQZVdRx5/q90
	fzvzWg0dYxHjVH2BtwbNBaWcAa17Uf2JjWdrwDrv+2jKdhDXJlQuFuVCuf9a8w==
X-Gm-Gg: ASbGnctiEWD8sCbPuJLcmndlL+jar44bfrx8Jjk4IsE6JWwyk/L1jYjS1XY4ykpAUv6
	/WhzA2mUpzFM7gWwOI8Lfn1H18Ir1Wdcjemd4jgh+wKSdMRDe6eRaLc4OnAv4FMU2NWc7wqrteL
	YCNt+FwR3tG9UxcM5Sru65QAi4dHwFSiVLXCmjF42jhfEnfZmqekFAtHjQokbjMdEGg6sFp5bFm
	8brasFCmiZXCLx72nYRd91o82tRY3z2InkFpk5t8u/lYEDH9uG7p3KXeUDM+nCEsp5fCnAY1oey
	RWSi1GmXXmFx+nJc5QHzYW48SPFEZXGX8Ib5kIYiNGI7cedwsyrLtYZJ7syK/cDAyO4cyQdPMwz
	i9YS5CPO6KA==
X-Google-Smtp-Source: AGHT+IGMEUdfaVBKCCQfllGOU2wQDuHePuGnVYs2LyFayWJtBfpFkwjwB1Lz6QkYAZW6SWr4gyn+Wg==
X-Received: by 2002:a5d:47ac:0:b0:386:3e48:f732 with SMTP id ffacd0b85a97d-3863e48f812mr7193837f8f.16.1733841267573;
        Tue, 10 Dec 2024 06:34:27 -0800 (PST)
Message-ID: <4e9c0566-bed7-47a6-aa6d-2ac76c0a1bfe@suse.com>
Date: Tue, 10 Dec 2024 15:34:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/FPU: make vcpu_reset_fpu() build again with old gcc
To: Alejandro Vallejo 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "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 10.12.2024 15:25, Alejandro Vallejo wrote:
> On Mon Dec 9, 2024 at 3:13 PM GMT, Jan Beulich wrote:
>> Fields of anonymous structs/unions may not be part of an initializer for
>> rather old gcc.
> 
> Can you add the specific version for tracking purposes?

It's all the same as before, and I really didn't want to waste time on
once again figuring out which exact version it was that the behavior
changed to the better.

>> Fixes: 49a068471d77 ("x86/fpu: Rework fpu_setup_fpu() uses to split it in two")
>> Signed-off-by: Jan Beulich 
>>
>> --- a/xen/arch/x86/i387.c
>> +++ b/xen/arch/x86/i387.c
>> @@ -306,13 +306,13 @@ void vcpu_reset_fpu(struct vcpu *v)
>>  {
>>      v->fpu_initialised = false;
>>      *v->arch.xsave_area = (struct xsave_struct) {
>> -        .fpu_sse = {
>> -            .mxcsr = MXCSR_DEFAULT,
>> -            .fcw = FCW_RESET,
>> -            .ftw = FXSAVE_FTW_RESET,
>> -        },
>>          .xsave_hdr.xstate_bv = X86_XCR0_X87,
>>      };
>> +
>> +    /* Old gcc doesn't permit these to be part of the initializer. */
>> +    v->arch.xsave_area->fpu_sse.mxcsr = MXCSR_DEFAULT;
>> +    v->arch.xsave_area->fpu_sse.fcw = FCW_RESET;
>> +    v->arch.xsave_area->fpu_sse.ftw = FXSAVE_FTW_RESET;
> 
> That's not quite the same though. A more apt equivalence would be to memset the
> area to zero ahead of the assignments. Otherwise rubble will be left behind.

No. I didn't delete the initializer. All fields not mentioned there will
be default-initialized.

>>  }
>>  
>>  void vcpu_setup_fpu(struct vcpu *v, const void *data)
> 
> Out of context and not triggering the GCC bug, but vcpu_setup_fpu() should
> probably share the same initialization style as vcpu_reset_fpu(), imo.

Why?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 14:35:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 14:35:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852573.1266328 (Exim 4.92)
	(envelope-from )
	id 1tL1Kz-0004oY-RQ; Tue, 10 Dec 2024 14:35:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852573.1266328; Tue, 10 Dec 2024 14:35:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tL1Kz-0004oR-Oh; Tue, 10 Dec 2024 14:35:45 +0000
Received: by outflank-mailman (input) for mailman id 852573;
 Tue, 10 Dec 2024 14:35: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 1tL1Kz-0004oL-7L
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 14:35:45 +0000
Received: from mail-oo1-xc2f.google.com (mail-oo1-xc2f.google.com
 [2607:f8b0:4864:20::c2f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 08b6a268-b704-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 15:35:43 +0100 (CET)
Received: by mail-oo1-xc2f.google.com with SMTP id
 006d021491bc7-5f2d7868ef0so45888eaf.3
 for ; Tue, 10 Dec 2024 06:35: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: 08b6a268-b704-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1733841342; x=1734446142; 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=aPQWL52sDB07hxUgxfqzaFDxM5n8BY42D5DBK04WM8Q=;
        b=CQrceG/ECeD0JWL86ieAxgBdLXg+Kj6powVzP0/fQ+OemooVt5Tk0h2KqG3aEAUDp/
         TPKnL1bnffqxkEnZPQyg4ynQWpcTUIJ3FWDQ2rzegeg8XwObA0UCK7aYCFhTHYIRgg+N
         L9FMQb7QtJNMNo1dpHVSNSD+HxnbiXBbqNXVs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733841342; x=1734446142;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=aPQWL52sDB07hxUgxfqzaFDxM5n8BY42D5DBK04WM8Q=;
        b=mKWSBTbkygg6lgpKUfigCw+ZQE+i6Mbtl44iwswM59GoL0aB2ngByHDxqjRoZ4SV0B
         xdf8PRfSiuaJYY9/dckcq/ydjpng8UUWcU8/5IRFE4XpIq0HHSRIqzNb+tKYZnOtnVS4
         pK2bQerTqPjA2UX0REWCoFi06GKSMhIX6fesW45s1RnOvLMCBNcpjO+ulWomwLE3vhtw
         t7dkBqqWAcSK9YSiDKuNiY5jW3PJeeeJqTxQapYZkdVWyTNMBxlDj14xmNfuc9oRh5z4
         8tqCLZ9sMxMX9xq7GN515Xiuy3qnHXg8pYC2NeunLpgBN0EOZ7uF4LUlxvkMAypbNFA5
         w6ZQ==
X-Forwarded-Encrypted: i=1; AJvYcCVB5LlJrqmM87br5gz1zwaUsiMr44fjY+83Y1Vqsv/wipvtsnF97sFDj6RE/TQ9C9zDhcM870TP1aE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyPKni7ZkuZXIkPUekgROeE4kToS2oBrhs3H4vyXvNa19bj2OkT
	/cx6yJfuVQOS6/aPjvKy/7gkDrpHOoVXULGIKaM7AARfC8yW+OzA5dfnwON6SuZcbZdDZTjqvpB
	oefHJtXkcPfjSJ47nuj7xQQWBU8VH2xVuPUux3b34PpZ0ah4wyWY=
X-Gm-Gg: ASbGncsGtjrmLJe9qU83zXYnSCG4GaU5Sr+K/qf0tGwzcvdY3JcyrMRUynSy7QJL0sP
	j2LOlum6SaR8/1bYMEEC0ivwoSAA211V/ppd7cQ==
X-Google-Smtp-Source: AGHT+IEKBIjJp8JJXKee7DpZlhntVYlevga4jcE585kWN92/1T9MtcBBqzHDusVgi7H9JdcIk7FlRhHGjiLKhKPZNhE=
X-Received: by 2002:a05:6871:4185:b0:297:27b5:4d30 with SMTP id
 586e51a60fabf-29fee506fd7mr2901909fac.2.1733841341998; Tue, 10 Dec 2024
 06:35:41 -0800 (PST)
MIME-Version: 1.0
References: <20241122093358.478774-1-frediano.ziglio@cloud.com>
 <20241122093358.478774-3-frediano.ziglio@cloud.com> <7f74b7a9-1869-4efa-a213-04d56ba48fb1@suse.com>
In-Reply-To: <7f74b7a9-1869-4efa-a213-04d56ba48fb1@suse.com>
From: Frediano Ziglio 
Date: Tue, 10 Dec 2024 14:35:30 +0000
Message-ID: 
Subject: Re: [PATCH v2 2/4] x86/boot: Use header to allows inclusion of public
 xen.h header
To: Jan Beulich 
Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 10, 2024 at 10:32=E2=80=AFAM Jan Beulich  wr=
ote:
>
> On 22.11.2024 10:33, Frediano Ziglio wrote:
> > This allows to include other headers and avoid duplicated declarations.
> >
> > Signed-off-by: Frediano Ziglio 
>
> Again it's left unclear what the purpose / goal is.
>

Reduce duplication avoiding duplicate declarations. The alternative
would be to duplicate them, which was proposed already and refused as
duplication was not good.

> > --- /dev/null
> > +++ b/xen/arch/x86/include/boot/public/xen.h
> > @@ -0,0 +1,28 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +
> > +/* This header allows the inclusion of public xen.h */
> > +
> > +#ifndef BOOT__PUBLIC__XEN_H
> > +#define BOOT__PUBLIC__XEN_H
> > +
> > +#if !defined(__XEN__) || defined(__XEN_TOOLS__) || __XEN__ !=3D 1
> > +#error Unexpected defines
> > +#endif
>
> What is this to guard against? We're in the Xen tree, building Xen.
>

In include/public/arch-x86/xen.h file there are these declarations:

#if defined(__i386__)
# ifdef __XEN__
__DeFiNe__ __DECL_REG_LO8(which) uint32_t e ## which ## x
__DeFiNe__ __DECL_REG_LO16(name) union { uint32_t e ## name; }
# endif
#include "xen-x86_32.h"
# ifdef __XEN__
__UnDeF__ __DECL_REG_LO8
__UnDeF__ __DECL_REG_LO16
__DeFiNe__ __DECL_REG_LO8(which) e ## which ## x
__DeFiNe__ __DECL_REG_LO16(name) e ## name
# endif
#elif defined(__x86_64__)
#include "xen-x86_64.h"
#endif

This header allows us to include that part without compiler errors due
to __DeFiNe__ and __UnDeF__ not being C code.

> > +#include 
> > +
> > +#ifdef __i386__
> > +
> > +# define __XEN_TOOLS__ 1
> > +# undef __XEN__
> > +# include 
> > +# define __XEN__ 1
> > +# undef __XEN_TOOLS__
>
> Why would __XEN__ need un-defining and __XEN_TOOLS__ (seemingly wrongly)
> need defining? (As an aside, I don't think the expansion of either macro
> really matters. IOW I don#t see the need for the two 1-s.)
>
> Jan

The "1"-s are the default definitions, simply I define them
temporarily and then restore them.

Frediano


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 14:39:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 14:39:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852584.1266337 (Exim 4.92)
	(envelope-from )
	id 1tL1OP-0005PW-9z; Tue, 10 Dec 2024 14:39:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852584.1266337; Tue, 10 Dec 2024 14:39: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 1tL1OP-0005PP-7K; Tue, 10 Dec 2024 14:39:17 +0000
Received: by outflank-mailman (input) for mailman id 852584;
 Tue, 10 Dec 2024 14:39: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 1tL1OO-0005PJ-EW
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 14:39:16 +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 86a26286-b704-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 15:39:14 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-434fa6bf744so13724535e9.2
 for ; Tue, 10 Dec 2024 06:39:13 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-434f2b08972sm98608735e9.27.2024.12.10.06.39.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 06:39:13 -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: 86a26286-b704-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733841553; x=1734446353; 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=0P87S9AqnrrzFSb7FApiqbW/7L/KL0GWFbBmHRsto34=;
        b=JcWM5K2k4POZnwG+B/aAwODhyB4wCswuYWS4ZEaPdrfY9RX4/zdFa2qh0VlBqIZjUC
         1QFRc737g3oqliyhDfbnkKz68ZjZQhGU2Io1+JpCYPmdxmdq+7lsdfqdoPjKG9clVool
         0CXbXiYTDE8kbFtAAxzpoB2/sPKUDb+0Jb16en/5e0GA0LoVZ4JQfbnER/WLQjA1n3Vg
         9w4GfPpH9tuMD7855lkakq23K64mxkCSA5iDmqZAkz4MyE9YrP4CpAkEGogHqdTRXv/b
         w93HBxSOZIreLq+4g9o7aQioqDLpq23RuMBAFhufw2x7WG9VFlvU76NUscWrTOIp9MBv
         LnRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733841553; x=1734446353;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=0P87S9AqnrrzFSb7FApiqbW/7L/KL0GWFbBmHRsto34=;
        b=Su2/w8OWLfow113EhXDAfPIMXY0huzxwy91MPLtRoUzy8L4EYdSUdt3ZIO5jsCRSS/
         +1Gtrc2Rd62ZO4E3GreQDNFQ7f5sGk0PAuI7l/0fcvw1Ok4sO8p8rHOnoWTYP3mE4oML
         UVtzWUKLLAoMGWaU+bB+SWZE7opw/3gI/0J7XvpF1u1FeP+1OLjG8m4QMxnIbqOikCTU
         6i4kNz/1nNanF9M1HcyFzA6KW1V9ganH37PfAThLPk9G36DkMH0X0cbC3XCI33kscRlX
         iaiC/VuCSure21Ll/o+SHImiw5ms+pSdvncM5q5T0ao6W7jE5tKcf286Zl0S62wpqQdr
         65Mw==
X-Forwarded-Encrypted: i=1; AJvYcCWC1MjyYZKrYCRLAdFc5xkWE1EzUR8FVKLoqgwxVx12dTSL6+or6F8txxBjZgphQYy/CYssqKaXdoM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywo+iSApSLEEWXgvc/j/8SL5p4xSjxbt91mosJ7HXhEFuQ6bNvv
	x4VxQaYwZBxVGoTWwePhxqktBmcUlSy4hYxxhbevMRyb4VXmTprrBwMd9c7G1g==
X-Gm-Gg: ASbGncs9CdvSFhXm4vdERaNiolQFINiKqOgBHGL/IucMIosmJ51e59wxmFM04pbKPzy
	m/X/PyB84IhI6c2YMt7g/sotYcHu53jskJ5akXribomAAZ7JV08Cc3GjBNBLB6RQii11bJpmxyc
	t0vsENVe0v+4LG7Ptx0baxi4ZSXVp2PoiD6OuqJggTRvibhOWje8fBJQxamR4YPBGEGQ8sbFXxr
	iNzloeNp4YxWLsLQevOxLxQwk384qmdz7wJnPSJzHCRuCmIxS4nBPysy+WKXy319k+qhgX7DEbl
	aLTiyzqGKJwRGjkTE1/+bADDmvEEiuHazRTV+IOo/D7dfLeS1RanMGmlSzShzQMwcyFqWsfc3BD
	j//tISliokA==
X-Google-Smtp-Source: AGHT+IGeCh8DWj4ljOdgiQly71nMWQkQiPeQf1qMDrkM8OjKMwFO2AH+mgF1DzZT0TfeGeXEA4QloQ==
X-Received: by 2002:a05:600c:3547:b0:434:a525:7257 with SMTP id 5b1f17b1804b1-434fffd0490mr36276975e9.21.1733841553361;
        Tue, 10 Dec 2024 06:39:13 -0800 (PST)
Message-ID: 
Date: Tue, 10 Dec 2024 15:39:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/4] Use an include/boot directory to override headers
 for boot code
To: Frediano Ziglio 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241122093358.478774-1-frediano.ziglio@cloud.com>
 <20241122093358.478774-2-frediano.ziglio@cloud.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.12.2024 15:29, Frediano Ziglio wrote:
> On Tue, Dec 10, 2024 at 10:14 AM Jan Beulich  wrote:
>>
>> On 22.11.2024 10:33, Frediano Ziglio wrote:
>>> Not all headers can be used by 32 bit boot code.
>>> Allows to override some headers, we don't want to mess up with
>>> main headers as most of the code is only 64 bit so the easy stuff should
>>> be done for 64 bit declarations.
>>> Boot headers should be 64 bit compatibles to avoid having multiple
>>> declarations.
>>
>> I'm afraid that in isolation it's not clear what is intended. Boot code is
>> all located in a single directory. Can't we use local headers there, using
>> #include "...", instead of ...
>>
> 
> That approach was refused.

Can you provide a reference please?

> Some definitions are in the headers (like
> CPU features for instance) but duplicating the definitions was
> rejected as a solution.
> So the idea is to reuse such definitions. But, as stated in the
> comment, the "x86" includes are not for x86, but most of them are just
> for x64.This for historic reasons. But most of the code is x64 only so
> changing headers to be x86 compatible would complicate them for a
> minimal gain.

Yet the amount of what wants sharing ought to be low. It might even help
to clarify what it is that is meant to become shared.

>>> --- a/xen/arch/x86/boot/Makefile
>>> +++ b/xen/arch/x86/boot/Makefile
>>> @@ -18,7 +18,7 @@ CFLAGS_x86_32 := $(subst -m64,-m32 -march=i686,$(XEN_TREEWIDE_CFLAGS))
>>>  $(call cc-options-add,CFLAGS_x86_32,CC,$(EMBEDDED_EXTRA_CFLAGS))
>>>  CFLAGS_x86_32 += -Werror -fno-builtin -g0 -msoft-float -mregparm=3
>>>  CFLAGS_x86_32 += -nostdinc -include $(filter %/include/xen/config.h,$(XEN_CFLAGS))
>>> -CFLAGS_x86_32 += $(filter -I% -O%,$(XEN_CFLAGS)) -D__XEN__
>>> +CFLAGS_x86_32 += -I$(srctree)/arch/x86/include/boot $(filter -I% -O%,$(XEN_CFLAGS)) -D__XEN__
>>
>> ... introducing a arch-wide subdir, which non-boot code could easily (ab)use?
> 
> You would have to explicitly add the "boot" into the path,

No different from "hvm" or "guest", just to give two examples.

> it does not
> seem "easy" to me, but if you really want to do it you can do with
> these or any other headers, like simply "#include "../arch/arm/..." in
> x64 code. Same easiness.

Well, no, the ".." in #include directives certainly stands out.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 14:44:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 14:44:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852604.1266347 (Exim 4.92)
	(envelope-from )
	id 1tL1TH-0007Vl-St; Tue, 10 Dec 2024 14:44:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852604.1266347; Tue, 10 Dec 2024 14: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 1tL1TH-0007Ve-QN; Tue, 10 Dec 2024 14:44:19 +0000
Received: by outflank-mailman (input) for mailman id 852604;
 Tue, 10 Dec 2024 14:44: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 1tL1TG-0007VW-W5
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 14:44: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 3a1273b2-b705-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 15:44:15 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-385ef8b64b3so4614002f8f.0
 for ; Tue, 10 Dec 2024 06:44:15 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38621fbbc14sm16394589f8f.87.2024.12.10.06.44.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 06:44: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: 3a1273b2-b705-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733841854; x=1734446654; 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=XfeWjf0t/1mknC8RdFDvvPEXQ/H4yqP4bWUHMvESMBA=;
        b=JaEtW5n8vqGOqENiT1p3/B15rDsnehBevr3l7mzouxjkpdLtO7t4hDWnRufSKR3Luc
         SVsYglyRUOP81PU5H+CZoeEwe98FTYQmzmv4avFD6COzZV4RgwD73M4xwiPEGiHOuPku
         HYP3WQOY64AZ1ZARSiQ86lYENkEmEQIOTJdYs3wt56v5Dx1oRZUaiOeSjU2NWNdAdOKD
         FZmMcYr40UJZNSb8+fn+74LcO2W3DGvErnNYbv6NI1ZKp1Bbc3ffM6/cHC38M8IvMXzX
         kGU4IfQ2SInIvWfzFVp2s9QZ+t9uRSXDkjr/WPnQIeQgw+i4l56GnJ7l2n2Ta2ctagVR
         bLCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733841854; x=1734446654;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=XfeWjf0t/1mknC8RdFDvvPEXQ/H4yqP4bWUHMvESMBA=;
        b=d16Io77OzPUKzPbWa/wsQEBrRvoytQh+VBDOlFDYirLtLI5RgP+XflydQpR8uMZCJg
         C+zFCzJvMpzP4WmdDs3nVqtSqVrYj1bvB4TarrsmLBeZj9Wmg857r7BAoUawjVHDafee
         sQtnUcc6wVf56M87DoknILOVCq2nv+A0FRSmiDMrUmIg4tBN9WA0dFy8V/ZpHDhE4SDY
         O/mgQ8zlIkqaiEAndePgBR5RR+GNZTqtHLXqHCfBTEgTdfMjTsHnGlWvFCwjkC1sBSP/
         +z4pDvxgXI4uNqflqx2xSiCn04GVXSqxGSgICg+wUX9tXoU6llXbqgtr71othpqZNhbu
         xgcQ==
X-Forwarded-Encrypted: i=1; AJvYcCWvQre86pHoXzqS1wh5o6H8JvrCZoLmxkZoOUALJECkXUpzIUgRm1wKYx0UftMvwDVkTdWPNAT9TDM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwBJq4Zc5QSfGfjbTKzJ/08GRHR664GCU8sh8dYsusON7C0wLU2
	XuEQOSP9uB0XlzbfGs9p5wRIe2YS6s6Rbg2sn1ypKFGlejNuijHQD7Lk1wPVmg==
X-Gm-Gg: ASbGncu2szP75a6RqT+8leKar+2a0DbgQ+g7Wekf8X5aX+hnBk6NJ7n6Q97A8WGJxLi
	f8ApYNrpawrb/QRdtPWCK1rdgibCt9TpFAiI1CmU0H1uaaUU20MwOH3uHJ35GUKvj3u4J9K4Ttk
	sTLpmbwmW6XCx857lBj0iHkGMHS6XYLmcnpd6o+y2Ze36qDvLIuvaP63k193DxtjPdzP7bTsRGx
	uawNMuCMlWdcT0MHH3e8fRFWtOJfyPugmXQtTV2IhbvE/qiTgweBwqSeMtO/8DfYYtSYhJ02tw1
	8ybXBTD4K4aIp+5x30tFsWx5SSVTmMrTa1kMuJYPDlcFfcNo+laL9W10Ehzb+q9eSzTagP+pnee
	ufoQcf/U/TQ==
X-Google-Smtp-Source: AGHT+IG/VQGTvrTw23EQ2Hd2U27ZhxdlPVzMM0CGbP867h1vG3IX5LVMTsdHPDkYy4WQZMZt6P7IZg==
X-Received: by 2002:a05:6000:18a5:b0:386:3e87:2cd6 with SMTP id ffacd0b85a97d-3863e8737fcmr6516907f8f.38.1733841854367;
        Tue, 10 Dec 2024 06:44:14 -0800 (PST)
Message-ID: 
Date: Tue, 10 Dec 2024 15:44:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/4] x86/boot: Use header to allows inclusion of public
 xen.h header
To: Frediano Ziglio 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241122093358.478774-1-frediano.ziglio@cloud.com>
 <20241122093358.478774-3-frediano.ziglio@cloud.com>
 <7f74b7a9-1869-4efa-a213-04d56ba48fb1@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.12.2024 15:35, Frediano Ziglio wrote:
> On Tue, Dec 10, 2024 at 10:32 AM Jan Beulich  wrote:
>>
>> On 22.11.2024 10:33, Frediano Ziglio wrote:
>>> This allows to include other headers and avoid duplicated declarations.
>>>
>>> Signed-off-by: Frediano Ziglio 
>>
>> Again it's left unclear what the purpose / goal is.
>>
> 
> Reduce duplication avoiding duplicate declarations. The alternative
> would be to duplicate them, which was proposed already and refused as
> duplication was not good.

Which declarations specifically?

>>> --- /dev/null
>>> +++ b/xen/arch/x86/include/boot/public/xen.h
>>> @@ -0,0 +1,28 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +
>>> +/* This header allows the inclusion of public xen.h */
>>> +
>>> +#ifndef BOOT__PUBLIC__XEN_H
>>> +#define BOOT__PUBLIC__XEN_H
>>> +
>>> +#if !defined(__XEN__) || defined(__XEN_TOOLS__) || __XEN__ != 1
>>> +#error Unexpected defines
>>> +#endif
>>
>> What is this to guard against? We're in the Xen tree, building Xen.
>>
> 
> In include/public/arch-x86/xen.h file there are these declarations:
> 
> #if defined(__i386__)
> # ifdef __XEN__
> __DeFiNe__ __DECL_REG_LO8(which) uint32_t e ## which ## x
> __DeFiNe__ __DECL_REG_LO16(name) union { uint32_t e ## name; }
> # endif
> #include "xen-x86_32.h"
> # ifdef __XEN__
> __UnDeF__ __DECL_REG_LO8
> __UnDeF__ __DECL_REG_LO16
> __DeFiNe__ __DECL_REG_LO8(which) e ## which ## x
> __DeFiNe__ __DECL_REG_LO16(name) e ## name
> # endif
> #elif defined(__x86_64__)
> #include "xen-x86_64.h"
> #endif
> 
> This header allows us to include that part without compiler errors due
> to __DeFiNe__ and __UnDeF__ not being C code.

And why exactly can't 32-bit code simply include the compat variant of
the public header, which is being generated by processing those non-C
constructs?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 14:45:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 14:45:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852614.1266358 (Exim 4.92)
	(envelope-from )
	id 1tL1Uc-00081u-6I; Tue, 10 Dec 2024 14:45:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852614.1266358; Tue, 10 Dec 2024 14:45: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 1tL1Uc-00081n-3a; Tue, 10 Dec 2024 14:45:42 +0000
Received: by outflank-mailman (input) for mailman id 852614;
 Tue, 10 Dec 2024 14:45: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 1tL1Ua-00081f-Jy
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 14:45:40 +0000
Received: from mail-oa1-x2a.google.com (mail-oa1-x2a.google.com
 [2001:4860:4864:20::2a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6b5b357d-b705-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 15:45:38 +0100 (CET)
Received: by mail-oa1-x2a.google.com with SMTP id
 586e51a60fabf-29e65257182so2801830fac.2
 for ; Tue, 10 Dec 2024 06:45:38 -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: 6b5b357d-b705-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1733841937; x=1734446737; 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=GLGVs3NXHjHw02oEprwUAflxGkcXVQa78J4wQ2tWkj4=;
        b=LjRKvv/4Pm9hOxz69vzNQoUDvSyqkD2T0yPsoNh7fyRPY+2LO/wcWNQM8NMryD+Pd3
         FhizCZhhbvx7KASw/c5ETjn92y3xi1qXHt8zXMitXWtsUWt7EZntgsYPfVJjjkNP2cQH
         cgYNNprIaQIgduCgvjSAXcYcTUiJouDAu+ZeQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733841937; x=1734446737;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=GLGVs3NXHjHw02oEprwUAflxGkcXVQa78J4wQ2tWkj4=;
        b=FGIn2z59cteli+utgEftBTJqJDYOX1JBYvLWttlWN9pR4euoFf6s9+j777gcomCvpd
         yksyPI+L9RS2/fPQzxJJ8lAz6jXevfC7wQxaOwKTTjEKCCrz+ytOshsVHCMhX67GRTei
         5ikSM/MEwrt8rJ2mK7ZOIJWdF8rW8HzChfkcj5TC5CQmEOsDN1Dq7UVCinK4H+y2bUHu
         1/JeF/J8V2S6wM/r88GaWqaGCnt6qcci+4OknTrzRZ6yKOV6E+Fs+OL5F0W1GSKX3DYt
         3Imwdhlq+zThQqUpWropi0m+4uaMyFtQbtQ2indtZuWemiTBaAeVmM2MmCG3Qg3z1VaM
         +OMQ==
X-Forwarded-Encrypted: i=1; AJvYcCUAGxzZegUX5apXQw4m67WjXwW53s92cOi9lgAPIUpAyogQ3z1ujbzoar9Cg/zNTtFiNs9Pp5DRjXk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YycVwilWfk3qpwvzIUdFHZAJgdO+ROjUz0sNVFhRxwnySLLqtwS
	zjIvZ5xGvOcpunUGieUBqYTjVAOJgCfyCISvvJj4rqRm50Y4qBhsRc7a7ZHnE/amG/fHD8RE57g
	NBxR+OXfYwlwNC7ff7kLWPpmn1q7ICHJpFllNwA==
X-Gm-Gg: ASbGncsbWVHqtOKKuONrV9apa8XCx/WFlCKZsrgDGinDWVmBzpDhcCWR3ONoWwNJEOO
	1MwPMVX8kB0mnOqnjEDoGSCWwchtLDlwSHdGtwQ==
X-Google-Smtp-Source: AGHT+IHfLhkUU9Q/x2HFvJrzmbTQYOVH0nDtxC1AMjgRc038cg9iEnoY+ZNw24tNOhWiqiePi9EJoqOfqov9WEDpF9A=
X-Received: by 2002:a05:6870:6b07:b0:297:241b:c48 with SMTP id
 586e51a60fabf-29f735a0d3cmr12413565fac.40.1733841937004; Tue, 10 Dec 2024
 06:45:37 -0800 (PST)
MIME-Version: 1.0
References: <20241122093358.478774-1-frediano.ziglio@cloud.com>
 <20241122093358.478774-4-frediano.ziglio@cloud.com> 
In-Reply-To: 
From: Frediano Ziglio 
Date: Tue, 10 Dec 2024 14:45:25 +0000
Message-ID: 
Subject: Re: [PATCH v2 3/4] x86/boot: Move some settings to C
To: Jan Beulich 
Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 10, 2024 at 10:38=E2=80=AFAM Jan Beulich  wr=
ote:
>
> On 22.11.2024 10:33, Frediano Ziglio wrote:
> > Initialise multiboot_ptr and pvh_start_info_pa from C code.
> >
> > Signed-off-by: Frediano Ziglio 
> > ---
> >  xen/arch/x86/boot/build32.lds.S           |  3 +++
> >  xen/arch/x86/boot/head.S                  | 10 --------
> >  xen/arch/x86/boot/reloc.c                 | 28 ++++++++++++++++++-----
> >  xen/arch/x86/include/asm/guest/pvh-boot.h |  1 +
> >  4 files changed, 26 insertions(+), 16 deletions(-)
>
> From the diffstat alone - is this really a win?
>

Yes, C can be longer then assembly, consider calling a function, assembly:

    foo:

    call foo

C:

   void foo(int x); // declaration (maybe in a separate header)

   void foo(int x) {
       ...
   }

   foo(123);

yes, much longer. Actually we could avoid the declaration, but usually
we explicitly force the compiler to complains about a missing
declaration. The reason is that usually programmers prefer the
compiler to avoid crashes and check for the passed parameters. This
requires more code but pay back the time not having to debug crashes.

If you look more at wide range (so, not only at this patch) the code
for a bit increases adding new files and symbols but after a while the
code starts to reduce (once added headers and preparation).

> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@ -517,16 +517,6 @@ trampoline_setup:
> >          /*      reloc(magic/eax, info/edx) using fastcall. */
> >          call    reloc
> >
> > -#ifdef CONFIG_PVH_GUEST
> > -        cmpb    $0, sym_esi(pvh_boot)
> > -        je      1f
> > -        mov     %eax, sym_esi(pvh_start_info_pa)
> > -        jmp     2f
> > -#endif
> > -1:
> > -        mov     %eax, sym_esi(multiboot_ptr)
> > -2:
> > -
> >          /* Interrogate CPU extended features via CPUID. */
> >          mov     $1, %eax
> >          cpuid
> > --- a/xen/arch/x86/boot/reloc.c
> > +++ b/xen/arch/x86/boot/reloc.c
> > @@ -17,13 +17,15 @@
> >  #include 
> >
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include 
> > +#include 
> >
> >  #include 
> > +#include 
> >
> >  #ifdef CONFIG_VIDEO
> >  # include "video.h"
> > @@ -347,27 +349,41 @@ static multiboot_info_t *mbi2_reloc(uint32_t mbi_=
in, memctx *ctx)
> >  }
> >
> >  /* SAF-1-safe */
> > -void *reloc(uint32_t magic, uint32_t in)
> > +void reloc(uint32_t magic, uint32_t in)
> >  {
> >      memctx ctx =3D { trampoline_phys + TRAMPOLINE_HEAP_END };
> >
> > +    void *res;
> > +
>
> Nit: Please avoid blank lines between declarations unless the set of loca=
ls
> is huge, or some really need to stand out.
>

Noted.

> >      switch ( magic )
> >      {
> >      case MULTIBOOT_BOOTLOADER_MAGIC:
> > -        return mbi_reloc(in, &ctx);
> > +        res =3D mbi_reloc(in, &ctx);
> > +        break;
> >
> >      case MULTIBOOT2_BOOTLOADER_MAGIC:
> > -        return mbi2_reloc(in, &ctx);
> > +        res =3D mbi2_reloc(in, &ctx);
> > +        break;
> >
> >      case XEN_HVM_START_MAGIC_VALUE:
> >          if ( IS_ENABLED(CONFIG_PVH_GUEST) )
> > -            return pvh_info_reloc(in, &ctx);
> > +        {
> > +            res =3D pvh_info_reloc(in, &ctx);
> > +            break;
> > +        }
> >          /* Fallthrough */
> >
> >      default:
> >          /* Nothing we can do */
> > -        return NULL;
> > +        res =3D NULL;
>
> Simply keep returning here? No need to write the NULL when the variables
> start out zeroed?
>

Yes, considering pvh_start_info_pa and multiboot_ptr should be already
NULL it makes sense

> >      }
> > +
> > +#ifdef CONFIG_PVH_GUEST
> > +    if ( pvh_boot )
> > +        pvh_start_info_pa =3D (unsigned long)res;
> > +#endif
> > +
> > +    multiboot_ptr =3D (unsigned long)res;
>
> In the assembly original this is an "else" to the if().
>

I suppose the return change above would solve also this.

> Jan

Frediano


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 14:49:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 14:49:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852625.1266368 (Exim 4.92)
	(envelope-from )
	id 1tL1Xr-0000Bn-Jv; Tue, 10 Dec 2024 14:49:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852625.1266368; Tue, 10 Dec 2024 14:49: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 1tL1Xr-0000Bg-Gq; Tue, 10 Dec 2024 14:49:03 +0000
Received: by outflank-mailman (input) for mailman id 852625;
 Tue, 10 Dec 2024 14:49: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 1tL1Xp-0000Ba-KS
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 14:49:01 +0000
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com
 [2607:f8b0:4864:20::231])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e3659c5c-b705-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 15:48:59 +0100 (CET)
Received: by mail-oi1-x231.google.com with SMTP id
 5614622812f47-3eb790888c6so121004b6e.2
 for ; Tue, 10 Dec 2024 06:48: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: e3659c5c-b705-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1733842138; x=1734446938; 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=lgtrdQl4jJcRWigYwaWojZ9z2pPJNU33XrppaF+9j5E=;
        b=LT+qmExJHfcAOYADRA09imqiUOCRUDE5DMIRTyo5kwxLgwFPUCEWdpmCxpBj71Z17N
         q8bofFJOewg1LAZz4h9eQ9maA/dnwlUuKZi6t268zrydHhpysgJf5p2/nbq4XJAix5yr
         +FN7qO+Z5BfFiYHCzeHgNzZZ97YQxUNUSy4bs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733842138; x=1734446938;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=lgtrdQl4jJcRWigYwaWojZ9z2pPJNU33XrppaF+9j5E=;
        b=cyIwPnp12CgMsHONcuYVRnMN/6ulw+4lJcYCc69sCfhf8TdvUlkQf98a7fTkus3FRv
         zj3IfFk3fLiZfcCgpjkV1TmTOWznQiMoNpLqvMHBnxh8sXkVDHQImgDpqFCaySvYEFTa
         2iJLdznxmUw8Hov66KA6IBqhj1PROPrzVkkEFwHqAd5qMr1ZdVRY1gcJZFFIbtW8zNwj
         ifc4BNe88TO2O8dQxk5myGOb8QBBx6el/RGL0Fn9VnRGjGOcr34MZIL0RwqLvXUoeZeh
         vn9hYxzymPJKYO+/5yrX0ilAx0KBQEtyLb76m8Dk7nIARDwL7XFJtdezpLZrP2dEyQ7z
         BDmg==
X-Forwarded-Encrypted: i=1; AJvYcCXVoyKgTqdWllRZN1mMRjqIqVtERSxZWB+AZeNHX3wzE+rztSLk/fq3ZVaqY+B1ymFykYwKb+obfUQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyzRiiBxlA1iOe6ShhzyuCV5RFSy3/f+oCbmFkA+pJp119/JxrJ
	WB/i48sTMAKKQTxWRA71dXMttfoZikYbmbcGW/+N3h7LA2KkA92dnsxbxUplKRZr64juETDq/S6
	JFH0BA33OddgzltJdJgPQGMcby1kAnBZkeSXLRTcFYdMvy6Vn
X-Gm-Gg: ASbGnctXdqCJ87okniQELQfhASHoQ+QIoERT5iKmxWBPrgVmws0Hao4WSQmZqoIeAy9
	bDP3vkUr9JIGflOjySn1XTure4/qzZUur8iaijQ==
X-Google-Smtp-Source: AGHT+IGABqJQfwluXS5vdz2E6nETL+dL80NQkworXSk9lb23QutIK5vNp1ypfeMLMK1hoUAfSkuSdTTu2mM7M+kxsjQ=
X-Received: by 2002:a05:6870:b529:b0:29e:503a:7ea3 with SMTP id
 586e51a60fabf-29fee71c5b9mr2589715fac.36.1733842138442; Tue, 10 Dec 2024
 06:48:58 -0800 (PST)
MIME-Version: 1.0
References: <20241122093358.478774-1-frediano.ziglio@cloud.com>
 <20241122093358.478774-3-frediano.ziglio@cloud.com> <7f74b7a9-1869-4efa-a213-04d56ba48fb1@suse.com>
  
In-Reply-To: 
From: Frediano Ziglio 
Date: Tue, 10 Dec 2024 14:48:47 +0000
Message-ID: 
Subject: Re: [PATCH v2 2/4] x86/boot: Use header to allows inclusion of public
 xen.h header
To: Jan Beulich 
Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 10, 2024 at 2:44=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 10.12.2024 15:35, Frediano Ziglio wrote:
> > On Tue, Dec 10, 2024 at 10:32=E2=80=AFAM Jan Beulich  wrote:
> >>
> >> On 22.11.2024 10:33, Frediano Ziglio wrote:
> >>> This allows to include other headers and avoid duplicated declaration=
s.
> >>>
> >>> Signed-off-by: Frediano Ziglio 
> >>
> >> Again it's left unclear what the purpose / goal is.
> >>
> >
> > Reduce duplication avoiding duplicate declarations. The alternative
> > would be to duplicate them, which was proposed already and refused as
> > duplication was not good.
>
> Which declarations specifically?
>
> >>> --- /dev/null
> >>> +++ b/xen/arch/x86/include/boot/public/xen.h
> >>> @@ -0,0 +1,28 @@
> >>> +/* SPDX-License-Identifier: GPL-2.0-only */
> >>> +
> >>> +/* This header allows the inclusion of public xen.h */
> >>> +
> >>> +#ifndef BOOT__PUBLIC__XEN_H
> >>> +#define BOOT__PUBLIC__XEN_H
> >>> +
> >>> +#if !defined(__XEN__) || defined(__XEN_TOOLS__) || __XEN__ !=3D 1
> >>> +#error Unexpected defines
> >>> +#endif
> >>
> >> What is this to guard against? We're in the Xen tree, building Xen.
> >>
> >
> > In include/public/arch-x86/xen.h file there are these declarations:
> >
> > #if defined(__i386__)
> > # ifdef __XEN__
> > __DeFiNe__ __DECL_REG_LO8(which) uint32_t e ## which ## x
> > __DeFiNe__ __DECL_REG_LO16(name) union { uint32_t e ## name; }
> > # endif
> > #include "xen-x86_32.h"
> > # ifdef __XEN__
> > __UnDeF__ __DECL_REG_LO8
> > __UnDeF__ __DECL_REG_LO16
> > __DeFiNe__ __DECL_REG_LO8(which) e ## which ## x
> > __DeFiNe__ __DECL_REG_LO16(name) e ## name
> > # endif
> > #elif defined(__x86_64__)
> > #include "xen-x86_64.h"
> > #endif
> >
> > This header allows us to include that part without compiler errors due
> > to __DeFiNe__ and __UnDeF__ not being C code.
>
> And why exactly can't 32-bit code simply include the compat variant of
> the public header, which is being generated by processing those non-C
> constructs?
>

I suppose I could solve that specific issue in that way. Where are
they generated?

> Jan

Frediano


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 14:53:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 14:53:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852638.1266377 (Exim 4.92)
	(envelope-from )
	id 1tL1bX-0002Fe-0w; Tue, 10 Dec 2024 14:52:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852638.1266377; Tue, 10 Dec 2024 14:52: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 1tL1bW-0002FX-UT; Tue, 10 Dec 2024 14:52:50 +0000
Received: by outflank-mailman (input) for mailman id 852638;
 Tue, 10 Dec 2024 14:52: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 1tL1bV-0002FR-Q5
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 14:52:49 +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 6c486547-b706-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 15:52:48 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-434ab114753so37838925e9.0
 for ; Tue, 10 Dec 2024 06:52:48 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3864a8e4db3sm819979f8f.47.2024.12.10.06.52.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 06:52: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: 6c486547-b706-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733842368; x=1734447168; 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=YRW5wH+yNRZJL2JIni570vNgX6sMwNHhrgnxkmfz5Js=;
        b=dA/s6wIGS/71uVl0GVFlcnhtK51mNDotHlW9p8puhBcK+Aw0CJrx/gCwkwjvxZT47F
         iEmiD+lgTIvc0mOTbH5sghd3Ca0d965ailcjJz3DQUYiyDMyQv64jndOMv/HCxWMsfd6
         UHVzV7vtwCBc+1xzTQpM/3/asXaybdQphAAPsLEWaKQbXvzi+HoeCODuq0wFbSqRGA6g
         PdpQL4o8/P7kxy5R0kxuNllb1EEFXJph9PLCKm3VADZRasvnc1RL702JRSKujF1xAiO3
         HGrJQ60zNUAyqZbiySddF01sYmao1+TpRftx46pmi4zfqS3HWnvN2Xh21tuJUXRtABrH
         1tcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733842368; x=1734447168;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=YRW5wH+yNRZJL2JIni570vNgX6sMwNHhrgnxkmfz5Js=;
        b=KZxErDlmQOQVzLXFzGnQ+n3gA7PEc1S8f+vZPZNCqyU/u0WLq9BEhTPMS7m5BIlswE
         DerWQB9L+5C63fvAXMKhBhgkg7CUkYPd/W+iN1D7DT8MuQJJrML8KuolyGYVPy7yb5Gx
         jp9+nPxROH4YwM6nRt4Ntpk9Ql/ehy3GLbsiYfw34Zp0qKh/E7n/pdZAqS67rd/TKfmd
         /L7F/fB2diCniu9en9pQNfULT0jY3f4WGjqclzoFarr3R2sz1gtqDAA0FgJVJVmHmd7G
         UaRhjbV1mUqKZpTS8upqCafKgzWNO3C6q215+sr6N9m9ktGggvYCZ9vAHspOzNNbyo2f
         3qsw==
X-Forwarded-Encrypted: i=1; AJvYcCVOYkeuqh7RRvdRRTjttrrV7omANe/KDOjhLqv7r+no4zsOJwEwdPhc8UVoU/VlE/tyQ7zuFWIY2ik=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz2hboPwok0Tt1LZtSQzikrJ5XWntyAcma2tcXWnXeD53uVtDPU
	5d0vnvrt9dsqbLrk8I+1h5LTkyh1biMQPa8b/kyRwo71DccZQsdiyPJV++FDrw==
X-Gm-Gg: ASbGncvZFzztTlCKG8bUUeDvQD+WRzIvdZapKBsf1LLULsWsumlbmNsXYYu+B4aogSs
	cio/2sK+oN8cq1JefNEBFvDnWamnzsJ5XRpREIVaCPj/fqbys/KjXxav6Y1QOiJSBSORQSNXtW/
	ubQ0ZWHDXbgB1bcmtptPtRI7LieVfyPSlNGnbys9ZDZ7uqeOJn+KrgsD3Xs6LongbMTxUNZRpef
	mfXkvrYwY7rONyrAC1Wg99bavrNrpaT7VP2ukhSnSQm32eAZ7QPmBscF44zOyG6PfUBsMiksXcB
	BTpukqn7IVKk5EQ2j8FnWjKOyZPNKuLMwQilLZbFZ3HniwThDE/wJIRTpUWYy+iNHgH2w7RYis0
	1usvLP2i7jg==
X-Google-Smtp-Source: AGHT+IG1svCsZ0wdtLZw99ZEPrnDOHNcWHl3wiEhcidgqkjoBDz+hU3y0KGnIQmr6hLlewC2Wr1R0Q==
X-Received: by 2002:a05:600c:4ecb:b0:434:f270:a513 with SMTP id 5b1f17b1804b1-434fffc627dmr39028945e9.29.1733842368209;
        Tue, 10 Dec 2024 06:52:48 -0800 (PST)
Message-ID: <7ab4786b-15fa-4504-9694-f63b0f71c5a2@suse.com>
Date: Tue, 10 Dec 2024 15:52:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 18/35] xen/console: introduce use of 'is_console' flag
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-18-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-18-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> The code now inspects d->is_console flag to decide whether the console focus
> should move to the domain w/ console after administrator presses .
> 
> Console owner domain switch logic updated accordingly.
> 
> Signed-off-by: Denis Mukhin 

Just as a remark, as it's a pre-existing problem: I'm unconvinced that
"is_console" is a good name here.

> @@ -509,14 +509,20 @@ static void console_find_owner(void)
>              domid = get_initial_domain_id();
>          else
>              domid = next_rx - 1;
> +
>          d = rcu_lock_domain_by_id(domid);
> -        if ( d )
> +        if ( d == NULL )

Seeing the original code, the more "natural" transformation would be to
!d (as we use elsewhere as well, to keep code short).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 14:56:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 14:56:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852653.1266388 (Exim 4.92)
	(envelope-from )
	id 1tL1eq-0002tW-Iw; Tue, 10 Dec 2024 14:56:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852653.1266388; Tue, 10 Dec 2024 14:56: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 1tL1eq-0002tP-Fs; Tue, 10 Dec 2024 14:56:16 +0000
Received: by outflank-mailman (input) for mailman id 852653;
 Tue, 10 Dec 2024 14:56: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 1tL1ep-0002tJ-EO
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 14:56:15 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20610.outbound.protection.outlook.com
 [2a01:111:f403:2414::610])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e40b8f43-b706-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 15:56:13 +0100 (CET)
Received: from BN9PR03CA0865.namprd03.prod.outlook.com (2603:10b6:408:13d::30)
 by DS0PR12MB6390.namprd12.prod.outlook.com (2603:10b6:8:ce::7) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8207.28; Tue, 10 Dec 2024 14:56:05 +0000
Received: from BL02EPF0001A103.namprd05.prod.outlook.com
 (2603:10b6:408:13d:cafe::a7) by BN9PR03CA0865.outlook.office365.com
 (2603:10b6:408:13d::30) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.15 via Frontend Transport; Tue,
 10 Dec 2024 14:56:05 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BL02EPF0001A103.mail.protection.outlook.com (10.167.241.133) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8230.7 via Frontend Transport; Tue, 10 Dec 2024 14:56:05 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 10 Dec
 2024 08:56:04 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) 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; Tue, 10 Dec
 2024 08:56:04 -0600
Received: from fedora.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 10 Dec 2024 08:56:04 -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: e40b8f43-b706-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=r3ugzgyr7CB6VNkr5y7KZUGG0vpXvruxmR3lo6Pt1bu/AfSsBgJ4I2xCmoz8x2MuBkZOPegrIm53c5jqbwDhFBRBnprMJ4G73/0k434qxDRt1QFlkABN/eZTo8OY02rfUxYbYTQ8x3KBL9U8qPbkq1JYGhBTJFudtMoLZvvmXub9hFYUEQSnXV+Ty+nyjovG85McBDFiHbFW6n7ZPZkCp/vqL1eL+DbHzbTJ78A97c6HR5Yvne3+3eV9k5mU9SVrDMs8pYvULBEJPVhZZpph9cUPv3J67rkr5ipptcMxIEzhQazCwXFzgaDKkWUflajQQjtpDi8tyoRk9fUvI7TeiA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nGbJ9fV7XYUtJgil4OU1lzyHGewiTFFjCBZYOQYbn9Q=;
 b=inJDXc9WvzM8OvuD2eJaIQN8xnWqGD/m2CewpQKvT9y9n0dN7HYal7cNLLrVE+rdu3EhynSpXfHckS5XDH/j0ntVdlnxtRFAAkpq0K7Tuv6RsTgVbbkVL6wgxvz8vyrJb9+7SDmzNxIOiB7fG64ouTmkmkDAC+d/Mym2s2NzpCqf+iX6SDG3V+durKM2rM7quLUECrZYrXoZkY/D+LPVNI5H0lmcUIIPucenVWSHgYqbDIsUThfvP7VZkS94JROsAWBfqw4sjpH8wbTM+N5dBOEe7Ht8mFHIRWEqhJ5a10RAjErnM13GyqVEX6hpfTJjDKkViSGRn9t5nbZ8Xj8hAQ==
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=nGbJ9fV7XYUtJgil4OU1lzyHGewiTFFjCBZYOQYbn9Q=;
 b=vkLhhdWEtRlEtItKh3q2X/tGuQWaPPC9jfEDqxNIGuNjXD7n8lie35pGNdE3fwGr3QbnJYMYOED8T2xKaEGCbP0SQRPJRa++YjLwzGCOfttVXBaPZ9pkDK6nn2hn7lkkWzjy0cWf/0SosaAaIwANUP2csxi7sD2zPup2xUBThOs=
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=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Oleksii Kurochko
	, Community Manager
	
Subject: [PATCH v2] CHANGELOG: Mention xl suspend/resume
Date: Tue, 10 Dec 2024 09:56:02 -0500
Message-ID: <20241210145602.5039-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0001A103:EE_|DS0PR12MB6390:EE_
X-MS-Office365-Filtering-Correlation-Id: 3284a644-cd31-4438-9eba-08dd192ac5d0
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?jrQ5TZEfo9mph3oN1fO2vEtFKXPje2xe1oFLQ6RqerUM1j3rMXVieHoPisgk?=
 =?us-ascii?Q?PAXU+6CuN2BZtBq8XsFOm5J2D4U64dpjUg1TuP0PZvE/KfQQbuYYwwv+GroO?=
 =?us-ascii?Q?Wpzl9VePdM+j7jh8aeJ41sdF6yV21ONABsAcaw+paftZd919eTfe8TysE+JB?=
 =?us-ascii?Q?118H9reEVv3GF4Av5XtgnV9AlG7Mo00Dd5YA0fxIJhWx18tzS4xQaVBYKAhy?=
 =?us-ascii?Q?Z4DiU6x7hlSNnm2g9CGpLfUvwlFqNRJSyA1GcQXT8Z+aAZXuny3/WLHd9pKV?=
 =?us-ascii?Q?yQK84hEHnJpqrO3/sYqbq6BQDM3ZHkAg5laAh+K8sCjJN2K4rzswNAfXkTGa?=
 =?us-ascii?Q?MlXlmJqCwLCllU/Ta9DffcKO4k7LYgUubpLywYbVhBwlyhLd32fHfp/iHWpy?=
 =?us-ascii?Q?zBQ31aSk7CV8FSWHsKHsgLBkZIRDOe23tdcxuD5vT5bHYW4coSNlNDo50FMr?=
 =?us-ascii?Q?i9OurpCDyuycI8JJy9MiRsEskN0NoosxUB1kw4/M1iaOxScEm4peEITQIcvH?=
 =?us-ascii?Q?afGnj7BW3D3dDZgcHfFtGuEjoheNjmldwdGLe0nbbI8zknumtPW4nrxIEbGJ?=
 =?us-ascii?Q?tc1Ou98BaviE9qZP+iFbmeYV+88iv/2AIlAxK2JXRMAwGoc2cbOU1ISs8bGn?=
 =?us-ascii?Q?NCpxeORonOQrBzWkbptmOXcn8khAFys39M3STgUANYpnfliPtyzn5nDZ8Aag?=
 =?us-ascii?Q?YIJ71ckiLj1n1YWJpD0blxgPlvAe0AgtdMGBX4ywfgbE5xKdhUK6Vf5J/LyC?=
 =?us-ascii?Q?k2JA8u0T5iKMC74G6VhhdfLaj3N2gHBc+vIjKtRjzMSUI8gna9AfTsFhg6Rt?=
 =?us-ascii?Q?kjAySkjpD+3mMBLfAZp67XErxE/f30rJKCUKAP1YCZiFZkemJL9mRyTq+kjM?=
 =?us-ascii?Q?47PPPgOeE1bf/HRbDFcodZWnBQwdZrOThOaobCo68tYAuh5IPsVAjcddpr4Q?=
 =?us-ascii?Q?8MR+qUElw1kQAZ/M3TdS32FGbImGsDq/af9g55sLOjZ0s7kNb98O0/05da0J?=
 =?us-ascii?Q?Rul01A78ig08VacVRi2vPYXzBnfj6ZrCWfeMn9OFv5pHGVvPIFW1Eot8vLnf?=
 =?us-ascii?Q?HmCu/vMJsuBth81wK4pIkFhosyl/4brbRPPZn5XTqp7Qs7gn7gVtPYk34RSq?=
 =?us-ascii?Q?yfYTWucjkjKhLyA/0oRhidq6UZz9fYbWVR39YAP55vk8pMTqy9FYIjZAkr6E?=
 =?us-ascii?Q?IjSFzXx39SzwGzhfoF1QICjSvrrmiSL7OUJDO+Em7XqYkq9WFc9n0vuXJ16X?=
 =?us-ascii?Q?kw4ipu1VYGO7dBN9h48cJTLFYgtIMRntJbK6Se+148NZBaolCzkdEIA54fp8?=
 =?us-ascii?Q?/gWpnBrQbGT+3MdYG23hJxHGaSJGt3im7CoE/r3sjG2QDlDCvmvHDxckwHd3?=
 =?us-ascii?Q?cPPV+bgX0lN/ryVLTtI7bt6iKWIG?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2024 14:56:05.3801
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3284a644-cd31-4438-9eba-08dd192ac5d0
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0001A103.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6390

The xl subcommands are generic, but only built when
LIBXL_HAVE_NO_SUSPEND_RESUME is false.  Currently that is only x86, so
list them there.

Signed-off-by: Jason Andryuk 
---
v2:
Nest under "On X86"
Expand commit message
---
 CHANGELOG.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 8553b2e451..15f681459f 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -16,6 +16,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 ### Added
  - On Arm:
    - Experimental support for Armv8-R.
+ - On x86:
+   - xl suspend/resume subcommands.
 
 ### Removed
  - On x86:
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 15:02:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 15:02:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852668.1266397 (Exim 4.92)
	(envelope-from )
	id 1tL1kn-0004oO-7H; Tue, 10 Dec 2024 15:02:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852668.1266397; Tue, 10 Dec 2024 15:02: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 1tL1kn-0004oH-4W; Tue, 10 Dec 2024 15:02:25 +0000
Received: by outflank-mailman (input) for mailman id 852668;
 Tue, 10 Dec 2024 15:02: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 1tL1kl-0004oB-VD
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 15:02:23 +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 c1fa8230-b707-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 16:02:22 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-435005192d1so13289915e9.3
 for ; Tue, 10 Dec 2024 07:02:22 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-434d526b14csm233964905e9.2.2024.12.10.07.02.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 07:02:18 -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: c1fa8230-b707-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733842941; x=1734447741; 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=bb9Oh6qPfmYGYfIHj6Xn37SN/ofn6fyXEsmuTdhqT3I=;
        b=JGOJywEg27YNwgUrxqvz9SUgMw+JnFGjY/sOTpr/8lbK4HCZcoiip1binGxqpTTw/l
         imLxhPEIG+ZTXssc9J7PecHOnR5oTocLy/jyw+EKs15WvskXn2jADJSuoQgojXV5ZAMx
         d8ri+EM4qkc78DMvvwgDxRjaGJO4TpST1zP/bypNesmVXTd/cdEMTeL87lvuFe4t7EgH
         RN6BSslVm2yuQ4RHpX5i/Aq8+sinCfRL89IoctVHks9V3mphOhubzn3mX5fQTOQWtmzO
         hU/hJDdClHjJu+ccqAMouObX1WrIynjO7yRgaJk9lS/L7djLXBTi5/AAYtJNiuRUD87o
         cIug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733842941; x=1734447741;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bb9Oh6qPfmYGYfIHj6Xn37SN/ofn6fyXEsmuTdhqT3I=;
        b=NX/MUg8exyEHcISiiCB0PqnSGMklE8X0mA/unQKbk4vYA+V7YTR8nOWnuRfgCsAcui
         tW/Ir1W6us/nLZqnJ/bnoJpLIuEZhNACrGr1/qPzjCgj5IEtFcniTeBeuuLu7IpNrEXM
         tzCfW6gxJt2yMCMJ6QHtKMaeVYiNQgjq1UEQb+/K+WgO5YyLtCa3/nfkqK7g3BnNSOiG
         vZ68u36Exo3WpiTkysH4cJIhuKDWlAx8idxWzoDcqKlFGNzMRXopkKZ0P8PT0YCH5fM8
         6bXCFSXTKmXVAloWuCqLBoB64LjGfztnLQ1qm/UDVCd6wc6Gh5IkXW0xsRyIHzqKFVdA
         RJPA==
X-Forwarded-Encrypted: i=1; AJvYcCUAN7oDil53RmXTgsRHUyeJ3AsIK9l+FBbMGl+vBUBgSSfluFcu4l5Ps+H5+jAbj0bw6YkXQ/4F23s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwIWkJGTtsOOAG2cUC61bVm/3VcvuOcvGmjDirEuy27uxEhRBJ2
	T07R8MqnW1pTCO2hTB7XBrXjjIaUa/DBHffodt1gxBTovgODWdo/nMeepBihmg==
X-Gm-Gg: ASbGncsHHPZEddAzlYCyi65oXLiCi0gNHG2nh+p9EETm2kSf1wH85oAzJO11ZNEfDY6
	djjiI78vq7Q8I5d1VPWH5bi8BsvsFvdiCEGOFnT9QriCuTIeN/VdcmAS5aa7R6e838FM5BGoauz
	hgamuXFoyKqiYhH/ZDXf8MDrVqqSuXBb7b6s5fj2XdBLB+z48UpXJhwUhahRMY8uVyBnqvqnuDa
	Phnbbjdocoipe95cKfj0YoPZKhqPCGzhw9DD49hyhBgdNObe4Z/RIvJ2UeDhdewATvWLwrbPviV
	jpvomk+L6ph5GYmGfexNAHTzNeL/ZJAVzyzPCjJZkx5w8mcmOoPzfNPdcL0MwRNwOV+wvIcdHyD
	xf0HdbzrcGQ==
X-Google-Smtp-Source: AGHT+IF+SnNeqfzWXB4C/zAu8mzlcHdNMZsencT8PWXd1u4eA1ouO1cVGEq0RSZ+SCgKNk4BR/+xUQ==
X-Received: by 2002:a05:600c:4750:b0:435:192:63fb with SMTP id 5b1f17b1804b1-435019266f3mr39988945e9.3.1733842939143;
        Tue, 10 Dec 2024 07:02:19 -0800 (PST)
Message-ID: 
Date: Tue, 10 Dec 2024 16:02:17 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 19/35] xen/console: introduce console_set_owner()
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-19-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-19-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -463,82 +463,100 @@ static void cf_check dump_console_ring_key(unsigned char key)
>  
>  /*
>   * CTRL- changes input direction, rotating among Xen, Dom0,
> - * and the DomUs started from Xen at boot.
> + * and the DomUs.
>   */
>  #define switch_code (opt_conswitch[0]-'a'+1)
> +
>  /*
> - * console_owner=0 => input to xen
> - * console_owner=1 => input to dom0 (or the sole shim domain)
> - * console_owner=N => input to dom(N-1)
> + * Current console owner domain ID: either Xen or domain w/ d->is_console ==
> + * true.

The switching of number space may better have been a separate patch.
Albeit maybe I'm just not seeing why it wants combining with the
introduction of console_set_owner().

Actually, is this switching actually complete? What about late hwdom,
which has a non-zero domain ID?

> + * Initialized in console_endboot().
>   */
> -static unsigned int __read_mostly console_owner = 0;
> +static domid_t __read_mostly console_owner;
>  
> -#define max_console_rx (max_init_domid + 1)
> +static struct domain *rcu_lock_domain_console_by_id(domid_t domid)

I think "domain" and "console" want switching in the name, as it's a
domain you're locking, not a console.

> +int console_set_owner(domid_t domid)

static? Iirc Misra doesn't like non-static functions which aren't called
from any other CU.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 15:04:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 15:04:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852678.1266408 (Exim 4.92)
	(envelope-from )
	id 1tL1mT-0005V0-Hb; Tue, 10 Dec 2024 15:04:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852678.1266408; Tue, 10 Dec 2024 15:04: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 1tL1mT-0005Ut-Em; Tue, 10 Dec 2024 15:04:09 +0000
Received: by outflank-mailman (input) for mailman id 852678;
 Tue, 10 Dec 2024 15:04: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 1tL1mR-0005Un-Mp
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 15:04:07 +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 00725e62-b708-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 16:04:06 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-434f09d18e2so31913105e9.0
 for ; Tue, 10 Dec 2024 07:04:06 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-434da1133cesm197888385e9.34.2024.12.10.07.03.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 07:03: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: 00725e62-b708-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733843046; x=1734447846; 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=kXIJpB3d5xD/yfT0gORF9PGfBtAAQGS0YGx+1HxJP3Y=;
        b=fZ6lCEAKlN7XpYJLM83hWisNhXyRVSolCnpZmSfuXA7voXBuncGksfM41aCDjOhWDU
         QjBQbdIcOsq30TF/3gmQnyHT9039GP8hlg+D28JTHAMxR8FtVIXhIgrHH0CJKXdXexDR
         /xyYoKQ6zjNZFz7OeaZ9TYoob5So74xgIRsRS/zmsNf5ihFwwZaCUtAWHuVsAUvYIo7C
         kLZTMtMWlbd9n0sRp0444hNy8mgNoDZv/Ufo7g18mFKctWtyeuuPKKa/eK0W6oGFFxES
         /aAmp7deVsu2El8JVWDrbvAo3D5enKBYqRkoSdpLR8eGf+rC8UH0S+GnZkMswqpHwF6G
         dfvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733843046; x=1734447846;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=kXIJpB3d5xD/yfT0gORF9PGfBtAAQGS0YGx+1HxJP3Y=;
        b=GQCGczjjVv05kphLE4rfSvupBGUL7MNz0taIxt8/Utw7eopYpFROn4w+chc/Evwzzd
         H5Ud2T8w6Xj4B4O7XCPeY5b4g2T4YotElp+TMMpprepl2YaAjjaHe2lmdMvLE1OOWzju
         Vg6X4nx2m2TkGiE5gX5Q4UtU7+LOGeG2Qx58XeSXJUvfwRhYdjUC9trBaD5DbR4fPwsN
         cg1hQt0NTTT8ZHiByHWekYo2xingTXcl27vBKwr1KExJn1hXsgnDOqcCpulA/BcKKjjw
         mCf7tfXVLyN3kxlRJ2pL7r8rqZRjfKWxW4dWmenlSSMDqJUO1f4/+vCwOn09NNt1cA4e
         HPBA==
X-Forwarded-Encrypted: i=1; AJvYcCV/b4b3VTt0+kT7HIdTwlxzgO45yr7FWg4zOmjF+j72caB5kJFhwMj3NUvgcruO7T5DtbjDlS2v+To=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx4xbp2Ec4I73byalmdWk98IlZp+SbkBBbd/1U2tkaxtHYMNZ2C
	+SsS9jd4xnVon2c9/2Bw3MNRYbSlO+YeNI3FcMMXh2MLBknXEBaEWMaD5NBLUg==
X-Gm-Gg: ASbGnct7PiXcCpM3vhsG9gGYDNktfwQa59lJcnNfD/eUGwM/CzXm60aqsd9bhpjADQU
	N4a6XuZOm2YtADBFmRSN0sdP7svn6xxo4XcY6UJPkfB46kMXjW5j2amKKaSjlqM0SR9MzPGAkQ1
	a9rk08tOFTdvjhFz2lnTnDuY8ojq5zZZiGvwc0muc/DM/W8T8mYgqlrdSc8RUuXCnyJsxqOJ5SO
	hCVlBPb7Ylomccxwb2qOfh9/PBfgmgxVknpYjFvLqGYVfAJPKi9OkUZNLdoxVu8rr0mixNLaVTp
	yccIqrBwTt0/Pi2UMbSupp2OwL6Xb16V7OcAMMlT23TVKrLzrbn8ieE9VCSn5rIedHv6fzIYe+3
	bD7zsADoz+g==
X-Google-Smtp-Source: AGHT+IGWpgkI+RA/wQxW9UPZdIueInhetDNWn7P+7wmoXg2NoZ8XeBRUABUYzaujX02qm8LtFaPrgQ==
X-Received: by 2002:a05:600c:3649:b0:436:1971:2a4 with SMTP id 5b1f17b1804b1-436197104acmr13697945e9.17.1733843038727;
        Tue, 10 Dec 2024 07:03:58 -0800 (PST)
Message-ID: <36a51e99-0066-4f0d-b189-9eab11dd51df@suse.com>
Date: Tue, 10 Dec 2024 16:03:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/4] x86/boot: Use header to allows inclusion of public
 xen.h header
To: Frediano Ziglio 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241122093358.478774-1-frediano.ziglio@cloud.com>
 <20241122093358.478774-3-frediano.ziglio@cloud.com>
 <7f74b7a9-1869-4efa-a213-04d56ba48fb1@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.12.2024 15:48, Frediano Ziglio wrote:
> On Tue, Dec 10, 2024 at 2:44 PM Jan Beulich  wrote:
>> On 10.12.2024 15:35, Frediano Ziglio wrote:
>>> On Tue, Dec 10, 2024 at 10:32 AM Jan Beulich  wrote:
>>>> On 22.11.2024 10:33, Frediano Ziglio wrote:
>>>>> --- /dev/null
>>>>> +++ b/xen/arch/x86/include/boot/public/xen.h
>>>>> @@ -0,0 +1,28 @@
>>>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>>>> +
>>>>> +/* This header allows the inclusion of public xen.h */
>>>>> +
>>>>> +#ifndef BOOT__PUBLIC__XEN_H
>>>>> +#define BOOT__PUBLIC__XEN_H
>>>>> +
>>>>> +#if !defined(__XEN__) || defined(__XEN_TOOLS__) || __XEN__ != 1
>>>>> +#error Unexpected defines
>>>>> +#endif
>>>>
>>>> What is this to guard against? We're in the Xen tree, building Xen.
>>>>
>>>
>>> In include/public/arch-x86/xen.h file there are these declarations:
>>>
>>> #if defined(__i386__)
>>> # ifdef __XEN__
>>> __DeFiNe__ __DECL_REG_LO8(which) uint32_t e ## which ## x
>>> __DeFiNe__ __DECL_REG_LO16(name) union { uint32_t e ## name; }
>>> # endif
>>> #include "xen-x86_32.h"
>>> # ifdef __XEN__
>>> __UnDeF__ __DECL_REG_LO8
>>> __UnDeF__ __DECL_REG_LO16
>>> __DeFiNe__ __DECL_REG_LO8(which) e ## which ## x
>>> __DeFiNe__ __DECL_REG_LO16(name) e ## name
>>> # endif
>>> #elif defined(__x86_64__)
>>> #include "xen-x86_64.h"
>>> #endif
>>>
>>> This header allows us to include that part without compiler errors due
>>> to __DeFiNe__ and __UnDeF__ not being C code.
>>
>> And why exactly can't 32-bit code simply include the compat variant of
>> the public header, which is being generated by processing those non-C
>> constructs?
> 
> I suppose I could solve that specific issue in that way. Where are
> they generated?

include/Makefile generates them into include/compat/.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 15:05:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 15:05:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852687.1266417 (Exim 4.92)
	(envelope-from )
	id 1tL1nm-000629-Qh; Tue, 10 Dec 2024 15:05:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852687.1266417; Tue, 10 Dec 2024 15:05:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tL1nm-000622-O9; Tue, 10 Dec 2024 15:05:30 +0000
Received: by outflank-mailman (input) for mailman id 852687;
 Tue, 10 Dec 2024 15:05:29 +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 1tL1nl-00061W-5F
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 15:05:29 +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 30879482-b708-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 16:05:27 +0100 (CET)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3862b364538so2427579f8f.1
 for ; Tue, 10 Dec 2024 07:05:27 -0800 (PST)
Received: from ?IPV6:2003:ca:b746:63c:8df1:d232:d9a2:1ff9?
 (p200300cab746063c8df1d232d9a21ff9.dip0.t-ipconnect.de.
 [2003:ca:b746:63c:8df1:d232:d9a2:1ff9])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3861f4a859esm15966484f8f.23.2024.12.10.07.05.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 07:05: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: 30879482-b708-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733843127; x=1734447927; 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=abNTXu84lOkHxjOFMdNsvofnXqxH/OgUrvNNoWc4Bco=;
        b=PPFBdkr2p3eupcsQgLqrdJtAW5XV0sG5jMWqZPQc5rvk5e4s2Lc2B88/luXXl2Cd6z
         SuBoz+POf0Wh89G1PTZtPO5pSfz9AG0d3xqbz35VA0zaomwO8ONHnwYYKRMVKIhz8bAw
         Lx/8pM9pA7qEseZusEp5233+el8DxGNAGU7AtYcAWLNibW9akCEE9FI2KoOjgnPHZPVB
         v6DAAtMaYVrx8ISBmEgum64azNm0tPU1e1P1zjWvBk4Hom3nPG0zuLnVfHGe1RKtB46H
         a057lnJuSwSmUXNcZptBd01GBKsIh8mLfaqWOK3HR3PJTui9KyR9Cm/7WX08UBqsFuS8
         0/6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733843127; x=1734447927;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=abNTXu84lOkHxjOFMdNsvofnXqxH/OgUrvNNoWc4Bco=;
        b=wPz/78gX5uG8M4DYdvhVTjaOmkOC8eBHnUZMNZNdBw2xr34eYTPevJRumwf5Yh34M/
         5n5npFYmuYQZjzZgisgUD7KyxpiG8YkBR1YVz0MCDyPPYrwOt3U+xwx/eER0M9fBtk3V
         F3cPXOvvNkycaEC4iGtq91lcXX4tBKaBXEwetY/Gy9F6HoNcA8+MSjj0RU4mMfDNEoBK
         sRDDr7uLpJ/P6A6j9srboos5tTFGKLExJmxZlm2b3UFTpXRcf/TbJujiCHDMnxlS1Uau
         ZxwaIsLCZHYDjpo+FsZ+4jw8gUqFpsUBDvVGAhTklWzVAB0rpTi+diVrPnyeEVe3GWMG
         6jwA==
X-Forwarded-Encrypted: i=1; AJvYcCWqSclbJ+NxCsgYtra334/g4wjGC+Yg1LlbUqycPybi6oKcaClzV3/UXX+nZ33qS9XhmpVzzqJTz+U=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz4uQSstBRtAWgLjyFCZ5zDDK7zXOSn9EKihG+YblMQpHlnZkfV
	6C1W5tOg8DsWbGyI2ZIjNS5krplxy9fCEqqYkz2NWcf3lpIp1amLMLRo/UJg3w==
X-Gm-Gg: ASbGncvjKErk9s1vjIm7/EDPYlfL5gNpNNuF2fcraM/SUPa8TjLlHtfERYlljSoQYii
	PfNYlIrsz7vRVUUMMknfpGbzaTwA73i0PoqEFU8i8EmB00PfMIbLn8e5KNGmG0YZU4keOXOzLSc
	m+/jzMPpkO+WKXXSimgvpqWnQrv43Yt9F2K4NzXuj8LA09JISuM8DBQcVNR3F14v3zkIAirpUex
	32Wq7zjBpnbMB0rQvC6DTzrph0ZkAp5roM1rwly6rXRmQvBWA55T7bNZIV0aLbpujEW5H0rnpUC
	M29AEQnryefeOUAUqCROgPmhnBkxGVdMM174VQmo7uYfV8aXlGyv6kajWOI8oCQMwON59nTi1hG
	8nG52tJNcDw==
X-Google-Smtp-Source: AGHT+IH3ObJYbSJ1fFbKHM8kXFe3iKy7E43Qc5t6RHVHD62Ri4kPRvCoMmAzFFaij7pUPVRoxYU+Pw==
X-Received: by 2002:a5d:6c6d:0:b0:385:df17:2148 with SMTP id ffacd0b85a97d-386469d513bmr2905347f8f.20.1733843126650;
        Tue, 10 Dec 2024 07:05:26 -0800 (PST)
Message-ID: <492bd49b-a0a1-4d86-b5c2-304a7deac755@suse.com>
Date: Tue, 10 Dec 2024 16:05:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/4] x86/boot: Move some settings to C
To: Frediano Ziglio 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241122093358.478774-1-frediano.ziglio@cloud.com>
 <20241122093358.478774-4-frediano.ziglio@cloud.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.12.2024 15:45, Frediano Ziglio wrote:
> On Tue, Dec 10, 2024 at 10:38 AM Jan Beulich  wrote:
>> On 22.11.2024 10:33, Frediano Ziglio wrote:
>>>      switch ( magic )
>>>      {
>>>      case MULTIBOOT_BOOTLOADER_MAGIC:
>>> -        return mbi_reloc(in, &ctx);
>>> +        res = mbi_reloc(in, &ctx);
>>> +        break;
>>>
>>>      case MULTIBOOT2_BOOTLOADER_MAGIC:
>>> -        return mbi2_reloc(in, &ctx);
>>> +        res = mbi2_reloc(in, &ctx);
>>> +        break;
>>>
>>>      case XEN_HVM_START_MAGIC_VALUE:
>>>          if ( IS_ENABLED(CONFIG_PVH_GUEST) )
>>> -            return pvh_info_reloc(in, &ctx);
>>> +        {
>>> +            res = pvh_info_reloc(in, &ctx);
>>> +            break;
>>> +        }
>>>          /* Fallthrough */
>>>
>>>      default:
>>>          /* Nothing we can do */
>>> -        return NULL;
>>> +        res = NULL;
>>
>> Simply keep returning here? No need to write the NULL when the variables
>> start out zeroed?
>>
> 
> Yes, considering pvh_start_info_pa and multiboot_ptr should be already
> NULL it makes sense
> 
>>>      }
>>> +
>>> +#ifdef CONFIG_PVH_GUEST
>>> +    if ( pvh_boot )
>>> +        pvh_start_info_pa = (unsigned long)res;
>>> +#endif
>>> +
>>> +    multiboot_ptr = (unsigned long)res;
>>
>> In the assembly original this is an "else" to the if().
>>
> 
> I suppose the return change above would solve also this.

I'm not convinced of this.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 15:12:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 15:12:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852709.1266427 (Exim 4.92)
	(envelope-from )
	id 1tL1uI-0007fq-KT; Tue, 10 Dec 2024 15:12:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852709.1266427; Tue, 10 Dec 2024 15:12:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tL1uI-0007fj-Hw; Tue, 10 Dec 2024 15:12:14 +0000
Received: by outflank-mailman (input) for mailman id 852709;
 Tue, 10 Dec 2024 15:12: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 1tL1uH-0007fd-PV
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 15:12:13 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 221d651c-b709-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 16:12:12 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-aa6a3c42400so138762966b.0
 for ; Tue, 10 Dec 2024 07:12:12 -0800 (PST)
Received: from localhost ([217.156.233.154]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d149a49f79sm7749154a12.32.2024.12.10.07.12.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 07:12: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: 221d651c-b709-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1733843532; x=1734448332; darn=lists.xenproject.org;
        h=in-reply-to:references:subject:cc:to:from:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=65Em8QSlUXLFR8ulOa1t0ycxHy3COnuTlh9s0EWbqSk=;
        b=NXc3UqVF87fzkWpzVidV9LXMeHCKPosrWgZFy0V8TMKL7GxXrBGG7cGmZf0t5AJDEY
         uLlWRzqRpyl0pt2kr4T/e04jAB0f3W4nWKWYzqw6cZKI/W6GNNsDGayUk1d5OnbnzWuD
         MPJJu2AKTTf+eiMmotiC+tJH53So+IFR64EEU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733843532; x=1734448332;
        h=in-reply-to:references:subject:cc:to:from:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=65Em8QSlUXLFR8ulOa1t0ycxHy3COnuTlh9s0EWbqSk=;
        b=YovfYVpKsFuqh7NlO+MiM3HR1VHlCiznAAO5ltW7xz6sfIyb7ffrwLbj7d3u4vZRV5
         42tVXE6/l1ZbjODtNTZ9+unBk91R2SRtAXYsJv8Be6surfvyxI3bnbFoGdIjpRSQq6aB
         nzstgpDZCChu2ddA0oz+TgYIsVF1EK/yhu0sNfYUkA1XkfHToC+hrP9PhsdNjjybN9tX
         EtKwXy5ZHoquSLeEKZ97czVQ9cXxpT/vXt2j/pTptiljKZBE7P7F6PFNORamzwYctCdQ
         JTZRRwWztaZ5X8tf1fzKc5JmG0D6hfcEd+0BgKQHuaDzyqTh6M67kJdFZyqtgKoc/j6u
         HjxQ==
X-Forwarded-Encrypted: i=1; AJvYcCXWvlCU9TlFlxq/xEt8z2G6q9RhQuC94zpUwPwrZJsi1B+QO3sqPoBy7LEMClt6CCp3vXU9D3jY4+Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzKXJPyKgHV4tpAO+bH/d3JuJf8qTL1Eb77ofU6HgSNEuOpW5O6
	hrkGfr+l94mhwxpGxE558L/F3clw3k2LenwR8yyKAE+VTxLXs0VCH31Ql7M+698=
X-Gm-Gg: ASbGnctglyKp4REShRAKkr+av+J9QJGHXGXC8nVL94l5R3EBwCSzl+2s88t3W/H3XWl
	odzyT6AcrGr89H+V9jn1bYP1/CPV7Ca643grQrXyY00sYviHhGREULA1ciEdiKivgQli14YXstM
	ucExe8e8+4JSArno4Jnkb9qlOfKneTg1QEu9PCiBUcli8FjFPT1YzCwoZOEoVTLM1n0JtYCk9YD
	iI/WTZqH/IgSjFm6ab2dDxxoOzGw2vzMmBk4hfgzJ4tkmd9nbcAPS7K8UsnZXo=
X-Google-Smtp-Source: AGHT+IFIUHccvHq+Av5npUzk+AJpA5aiV6QG7iPrplhLCKBUdR0VTOwGyDMQI7HBRLhthRO0bdwFpg==
X-Received: by 2002:a17:907:3da1:b0:a9a:6c41:50a8 with SMTP id a640c23a62f3a-aa6a01bebf7mr397425366b.17.1733843532191;
        Tue, 10 Dec 2024 07:12:12 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 10 Dec 2024 15:12:09 +0000
Message-Id: 
From: "Alejandro Vallejo" 
To: "Jan Beulich" 
Cc: "Andrew Cooper" ,
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" 
Subject: Re: [PATCH] x86/FPU: make vcpu_reset_fpu() build again with old gcc
X-Mailer: aerc 0.18.2
References: 
 
 <4e9c0566-bed7-47a6-aa6d-2ac76c0a1bfe@suse.com>
In-Reply-To: <4e9c0566-bed7-47a6-aa6d-2ac76c0a1bfe@suse.com>

On Tue Dec 10, 2024 at 2:34 PM GMT, Jan Beulich wrote:
> On 10.12.2024 15:25, Alejandro Vallejo wrote:
> > On Mon Dec 9, 2024 at 3:13 PM GMT, Jan Beulich wrote:
> >> Fields of anonymous structs/unions may not be part of an initializer f=
or
> >> rather old gcc.
> >=20
> > Can you add the specific version for tracking purposes?
>
> It's all the same as before, and I really didn't want to waste time on
> once again figuring out which exact version it was that the behavior
> changed to the better.

Just checked on Godbolt. 4.7.1 works and 4.6.4 doesn't. Adding that data po=
int
to the commit message really helps when navigating git-blame, even if it's =
not
as precise as it could be. Particularly if one wants to understand exactly
which quirk of which version of which compiler is being dealt with.

>
> >> Fixes: 49a068471d77 ("x86/fpu: Rework fpu_setup_fpu() uses to split it=
 in two")
> >> Signed-off-by: Jan Beulich 
> >>
> >> --- a/xen/arch/x86/i387.c
> >> +++ b/xen/arch/x86/i387.c
> >> @@ -306,13 +306,13 @@ void vcpu_reset_fpu(struct vcpu *v)
> >>  {
> >>      v->fpu_initialised =3D false;
> >>      *v->arch.xsave_area =3D (struct xsave_struct) {
> >> -        .fpu_sse =3D {
> >> -            .mxcsr =3D MXCSR_DEFAULT,
> >> -            .fcw =3D FCW_RESET,
> >> -            .ftw =3D FXSAVE_FTW_RESET,
> >> -        },
> >>          .xsave_hdr.xstate_bv =3D X86_XCR0_X87,
> >>      };
> >> +
> >> +    /* Old gcc doesn't permit these to be part of the initializer. */
> >> +    v->arch.xsave_area->fpu_sse.mxcsr =3D MXCSR_DEFAULT;
> >> +    v->arch.xsave_area->fpu_sse.fcw =3D FCW_RESET;
> >> +    v->arch.xsave_area->fpu_sse.ftw =3D FXSAVE_FTW_RESET;
> >=20
> > That's not quite the same though. A more apt equivalence would be to me=
mset the
> > area to zero ahead of the assignments. Otherwise rubble will be left be=
hind.
>
> No. I didn't delete the initializer. All fields not mentioned there will
> be default-initialized.

Right. I misread the diff and thought you had nuked the initializer. That's
indeed all fine. Which means...

>
> >>  }
> >> =20
> >>  void vcpu_setup_fpu(struct vcpu *v, const void *data)
> >=20
> > Out of context and not triggering the GCC bug, but vcpu_setup_fpu() sho=
uld
> > probably share the same initialization style as vcpu_reset_fpu(), imo.
>
> Why?

... there's indeed no reason to touch that.

>
> Jan

With the commit message adjusted with the offending GCC version (i.e: <4.7.=
1):

  Acked-by: Alejandro Vallejo 

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 15:20:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 15:20:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852723.1266438 (Exim 4.92)
	(envelope-from )
	id 1tL21y-0001Et-C3; Tue, 10 Dec 2024 15:20:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852723.1266438; Tue, 10 Dec 2024 15:20: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 1tL21y-0001Em-9O; Tue, 10 Dec 2024 15:20:10 +0000
Received: by outflank-mailman (input) for mailman id 852723;
 Tue, 10 Dec 2024 15:20: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 1tL21x-0001Eg-63
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 15:20:09 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3cb4d10d-b70a-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 16:20:06 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5ceb03aadb1so7484029a12.0
 for ; Tue, 10 Dec 2024 07:20:06 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d149a25cc5sm7769797a12.7.2024.12.10.07.20.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 07:20:05 -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: 3cb4d10d-b70a-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1733844006; x=1734448806; darn=lists.xenproject.org;
        h=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=bxPWbcyQkXK3DbcOT5Txw9CYnYS9nNlgk/VKoJT2ke8=;
        b=Z+4Yq7oI74GKsaMS3t0nT6oj9ZAdqzcTP6xG2CVCxxJkZycDA+z4sRCiMJcLiDjAGd
         7cdDFFwYs7CqA5czj/tp8iVs/PsTnz+wDjE4DRZ/ni7tFHi6fhHfBtn1UF5Q+w51Fkda
         SqltyySWg2Gey3p7b6x/JT9aVsr6sxqoihnlXyQOnLYYNVzSAU8h2ezmroyj5+/gFKXx
         njwvGlz9xuvrWAHhsfoE8fvB3tmWZivz1x1xKR5V8rKRiHchsYzjA2fjQ2yFy5lQb6W8
         T7n7TWnYTEuA2t5GHKCvcjMpVMM0mkyuovZLpE9j7wRjQYebvcZcC2bgejvvhjN4N5Rr
         Fuvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733844006; x=1734448806;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=bxPWbcyQkXK3DbcOT5Txw9CYnYS9nNlgk/VKoJT2ke8=;
        b=RR+TX5sUWdFCAMiGCmb/SWga0iFcU8YEH0/dIdn6IIXWMO0bxDw/Xgf3/R7SrPRIlU
         BA0pzFjFVmG5sS+3r//VSmOzCYAeLl4PfDPJ3PmkW3CPvidq0y+bSVRASz0RvAqyJ88S
         UpGArRFqoxzlM/WohNPyZ6Di6F36gMwyKesJrmgQMAhoqnAPMpKGnD2s9hOh2SVvywJR
         asGRFMitC43sfNZHbfa7/5dTLFE/WbcCiqfyGqIplx/n+2hlvrQkhVZQ/NSmfdOYNTvH
         AjFJn8hEXcmYQ4zyypAxjDMtoOvEw4v5EASgWd/MBZQDgqIrSNthKaApK1TJ2CNU1/8B
         /KgQ==
X-Forwarded-Encrypted: i=1; AJvYcCX3CNZBPehQzugPknxzRiOiXaa7KXMYOye8+YO5eOWpECOSUyBiydSByzJ8BOIefHHP13bBwbgHLy4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YySHnhWMENG3IOV0+/mq/hM6R4AH0a7ivWs1AUvVqF3PhV/S67Q
	8/FGBT0APzanHqhz15cYgPAvNs5JKC34Nsx6IdtWDM/FK3NkgVz4
X-Gm-Gg: ASbGnctaHfIHL77b8l09OYmgMXpg2TqlXSPJQIm4xh8LhOVKgI1JRnG1Dd3lpE6IAtA
	9qxkJnx0wut73PzW5+qkuJnD/NysciN8OW1YZOF/XQvzx7iR1Pq55ZsvAG+dcWO9Iq/XEHo7SoH
	t+VXSZKy3fGNktQHYKdhG4IxyfH2M1e4DDFHTuK+Z96vnKjorQcqh/MZfSOJpPkHwdMhLhWHLaK
	4ZtJDIRMwevSuYYOET/VZmEhas6U69CCH8i3Zgf1REyzsLuljiWp9aj8FIpDbxhcks=
X-Google-Smtp-Source: AGHT+IFzQTMEUufvLhW9qAKJc2lYfIlmMwY2roIuqVqsjlbrhPCtygbEpyiGybwfIUo+gSBaG+2XIQ==
X-Received: by 2002:a05:6402:4408:b0:5d3:cf08:d64d with SMTP id 4fb4d7f45d1cf-5d41863c2a7mr5482664a12.32.1733844006124;
        Tue, 10 Dec 2024 07:20:06 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------8KaSZ7d0SlsDntNHQ88047u1"
Message-ID: <4dd6a2e9-d2b9-4402-907b-b9314d2346f7@gmail.com>
Date: Tue, 10 Dec 2024 16:20:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 5/6] xen/riscv: implement relocate_fdt()
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: 
 
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

This is a multi-part message in MIME format.
--------------8KaSZ7d0SlsDntNHQ88047u1
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 12/9/24 4:00 PM, Jan Beulich wrote:
> On 27.11.2024 13:50, Oleksii Kurochko wrote:
>> relocate_fdt() relocates FDT to Xen heap instead of using early mapping
>> as it is expected that discard_initial_modules() ( is supposed to call
>> in the future ) discards the FDT boot module and remove_early_mappings()
>> destroys the early mapping.
>>
>> To implement that the following things are introduced as they are called
>> by internals of xmalloc_bytes() which is used in relocate_fdt():
>> 1. As RISC-V may have non-coherent access for RAM ( f.e., in case
>>     of non-coherent IO devices ) flush_page_to_ram() is implemented
>>     to ensure that cache and RAM are consistent for such platforms.
> This is a detail of the page allocator, yes. It can then be viewed as also
> a detail of xmalloc() et al, but I consider the wording a little misleading.
>
>> 2. copy_from_paddr() to copy FDT from a physical address to allocated
>>     by xmalloc_bytes() in Xen heap.
> This doesn't look to be related to the internals of xmalloc() et al.
>
>> 3. virt_to_page() to convert virtual address to page. Also introduce
>>     directmap_virt_end to check that VA argument of virt_to_page() is
>>     inside directmap region.
> This is a need of free_xenheap_pages(), yes; see remark on point 1.

Actually I faced the usage of virt_to_page() in xmalloc_whole_page():
```
   static void *xmalloc_whole_pages(unsigned long size, unsigned long align)
   {
     ...
     PFN_ORDER(virt_to_page(res)) = PFN_UP(size);
     /* Check that there was no truncation: */
     ASSERT(PFN_ORDER(virt_to_page(res)) == PFN_UP(size));

     return res;
   }
```
which is called from xmalloc().

Do we need a second paragraph of the commit message at all? Or it is just obvious if
flush_page_to_ram(), virt_to_page() and copy_from_paddr() are introduces that they are needed for
relocate_fdt()?

Or perhaps rephrasing in the following way would be enough?
```
For internal use of|xmalloc|, the functions|flush_page_to_ram()| and|virt_to_page()| are introduced.
|virt_to_page()| is also required for|free_xenheap_pages()|. These additions are used to support
|xmalloc|, which is utilized within|relocate_fdt()|. Additionally,|copy_from_paddr()| is introduced
for use in|relocate_fdt()|.
```

>> @@ -148,8 +150,12 @@ static inline void *page_to_virt(const struct page_info *pg)
>>   /* Convert between Xen-heap virtual addresses and page-info structures. */
>>   static inline struct page_info *virt_to_page(const void *v)
>>   {
>> -    BUG_ON("unimplemented");
>> -    return NULL;
>> +    unsigned long va = (unsigned long)v;
>> +
>> +    ASSERT(va >= DIRECTMAP_VIRT_START);
>> +    ASSERT(va <= directmap_virt_end);
> Why the difference compared to virt_to_maddr()?

It is just a mistake as `directmap_virt_end` is directmap_virt_start-relative but `v` is DIRECTMAP_VIRT_START-relative.
The check should be following:
   ASSERT((va >= DIRECTMAP_VIRT_START) && (va <= DIRECTMAP_VIRT_END));
and then directmap_virt_end should be dropped at all.

>
> Also recall my comment on one of your earlier series, regarding inclusive
> vs exclusive ranges. Can that please be sorted properly as a prereq, to
> avoid extending the inconsistency?

Yes, I remember that and at the moment everything ( DIRECTMAP_VIRT_END, FRAMETABLE_VIRT_END )
is following "inclusive" way. Considering that you remind me that could you please tell me more time
what I am missing?

>> +        set_fixmap(FIX_MISC, maddr_to_mfn(paddr), PAGE_HYPERVISOR_RW);
>> +        memcpy(dst, src + s, l);
>> +        clean_dcache_va_range(dst, l);
> Why is this necessary here? You're copying to plain RAM that Xen alone
> is using.

It is Arm specific:
```
commit c60209d77e2c02de110ca0fdaa2582ef4e53d8fd
Author: Stefano Stabellini
Date:   Mon Jan 21 12:40:31 2013 +0000

     xen/arm: flush dcache after memcpy'ing the kernel image
     
     After memcpy'ing the kernel in guest memory we need to flush the dcache
     to make sure that the data actually reaches the memory before we start
     executing guest code with caches disabled.
     
     copy_from_paddr is the function that does the copy, so add a
     flush_xen_dcache_va_range there.
```
I wanted to put copy_from_paddr() to some common place at the end but in RISC-V cache is always enabled
( I don't see an instruction in the spec for disable/enable cache ) so this issue isn't present for RISC-V
and clean_dcache_va_range() should/could be dropped.

>> +/* Relocate the FDT in Xen heap */
>> +static void * __init relocate_fdt(paddr_t dtb_paddr, size_t dtb_size)
> This function having no caller will - aiui - mean build breakage at
> this point of the series.

Yes, it should be a problem, missed that. Then I have to merge it with the next one patch.

Thanks.

~ Oleksii

--------------8KaSZ7d0SlsDntNHQ88047u1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    


    

    
On 12/9/24 4:00 PM, Jan Beulich wrote:

    

    

      
On 27.11.2024 13:50, Oleksii Kurochko wrote:


      

        
relocate_fdt() relocates FDT to Xen heap instead of using early mapping
as it is expected that discard_initial_modules() ( is supposed to call
in the future ) discards the FDT boot module and remove_early_mappings()
destroys the early mapping.

To implement that the following things are introduced as they are called
by internals of xmalloc_bytes() which is used in relocate_fdt():
1. As RISC-V may have non-coherent access for RAM ( f.e., in case
   of non-coherent IO devices ) flush_page_to_ram() is implemented
   to ensure that cache and RAM are consistent for such platforms.


      

      
This is a detail of the page allocator, yes. It can then be viewed as also
a detail of xmalloc() et al, but I consider the wording a little misleading.



      

        
2. copy_from_paddr() to copy FDT from a physical address to allocated
   by xmalloc_bytes() in Xen heap.


      

      
This doesn't look to be related to the internals of xmalloc() et al.



      

        
3. virt_to_page() to convert virtual address to page. Also introduce
   directmap_virt_end to check that VA argument of virt_to_page() is
   inside directmap region.


      

      
This is a need of free_xenheap_pages(), yes; see remark on point 1.

    

    
Actually I faced the usage of virt_to_page() in xmalloc_whole_page():
```
  static void *xmalloc_whole_pages(unsigned long size, unsigned long align)
  {
    ...
    PFN_ORDER(virt_to_page(res)) = PFN_UP(size);
    /* Check that there was no truncation: */
    ASSERT(PFN_ORDER(virt_to_page(res)) == PFN_UP(size));

    return res;
  }
```
which is called from xmalloc().


    
Do we need a second paragraph of the commit message at all? Or it is just obvious if 
flush_page_to_ram(), virt_to_page() and copy_from_paddr() are introduces that they are needed for
relocate_fdt()?


    
Or perhaps rephrasing in the following way would be enough?
```
For internal use of xmalloc, the functions flush_page_to_ram() and virt_to_page() are introduced.
virt_to_page() is also required for free_xenheap_pages(). These additions are used to support
xmalloc, which is utilized within relocate_fdt(). Additionally, copy_from_paddr() is introduced
for use in relocate_fdt().
```



    

      

      

        
@@ -148,8 +150,12 @@ static inline void *page_to_virt(const struct page_info *pg)
 /* Convert between Xen-heap virtual addresses and page-info structures. */
 static inline struct page_info *virt_to_page(const void *v)
 {
-    BUG_ON("unimplemented");
-    return NULL;
+    unsigned long va = (unsigned long)v;
+
+    ASSERT(va >= DIRECTMAP_VIRT_START);
+    ASSERT(va <= directmap_virt_end);


      

      
Why the difference compared to virt_to_maddr()?

    

    
It is just a mistake as `directmap_virt_end` is directmap_virt_start-relative but `v` is DIRECTMAP_VIRT_START-relative.
The check should be following:
  ASSERT((va >= DIRECTMAP_VIRT_START) && (va <= DIRECTMAP_VIRT_END));
and then directmap_virt_end should be dropped at all.



    

      

Also recall my comment on one of your earlier series, regarding inclusive
vs exclusive ranges. Can that please be sorted properly as a prereq, to
avoid extending the inconsistency?

    

    
Yes, I remember that and at the moment everything ( DIRECTMAP_VIRT_END, FRAMETABLE_VIRT_END )
is following "inclusive" way. Considering that you remind me that could you please tell me more time
what I am missing?



    

      

        
+        set_fixmap(FIX_MISC, maddr_to_mfn(paddr), PAGE_HYPERVISOR_RW);
+        memcpy(dst, src + s, l);
+        clean_dcache_va_range(dst, l);


      

      
Why is this necessary here? You're copying to plain RAM that Xen alone
is using.


    

    
It is Arm specific:
```
commit c60209d77e2c02de110ca0fdaa2582ef4e53d8fd
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Mon Jan 21 12:40:31 2013 +0000

    xen/arm: flush dcache after memcpy'ing the kernel image
    
    After memcpy'ing the kernel in guest memory we need to flush the dcache
    to make sure that the data actually reaches the memory before we start
    executing guest code with caches disabled.
    
    copy_from_paddr is the function that does the copy, so add a
    flush_xen_dcache_va_range there.
```
I wanted to put copy_from_paddr() to some common place at the end but in RISC-V cache is always enabled
( I don't see an instruction in the spec for disable/enable cache ) so this issue isn't present for RISC-V
and clean_dcache_va_range() should/could be dropped.



    

      

      

        
+/* Relocate the FDT in Xen heap */
+static void * __init relocate_fdt(paddr_t dtb_paddr, size_t dtb_size)


      

      
This function having no caller will - aiui - mean build breakage at
this point of the series.

    

    
Yes, it should be a problem, missed that. Then I have to merge it with the next one patch.

    
Thanks.

~ Oleksii


  


--------------8KaSZ7d0SlsDntNHQ88047u1--


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 15:21:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 15:21:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852734.1266448 (Exim 4.92)
	(envelope-from )
	id 1tL23f-00027N-Ob; Tue, 10 Dec 2024 15:21:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852734.1266448; Tue, 10 Dec 2024 15:21: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 1tL23f-00027G-LF; Tue, 10 Dec 2024 15:21:55 +0000
Received: by outflank-mailman (input) for mailman id 852734;
 Tue, 10 Dec 2024 15:21: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 1tL23e-00027A-AM
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 15:21:54 +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 7c312303-b70a-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 16:21:53 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-435004228c0so16856515e9.0
 for ; Tue, 10 Dec 2024 07:21:53 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa68c894472sm299651766b.87.2024.12.10.07.21.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 07:21: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: 7c312303-b70a-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1733844113; x=1734448913; darn=lists.xenproject.org;
        h=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=09jUxtKKNci42VhtTFd6c+JmlQ8B/KYHoGduA44v89c=;
        b=jk3hNEGEvU3qbfrbJ122y7zxXswvJPgFx3KILUOMeSGk1oOxCTTxciZCMR+yPfFJv0
         fy+c/Mn4bERySeLRmZowL6Us9UKzrxtkLu0yYTiEb7uhhWYst1xNR0j7VUz8nDagYk95
         xhuN+u4VG8WwanY8kO6AxU9eR7mx1CIhD6543UYcAuLYYdJUnbwgccq68UAVLBtTHG8T
         f9Rb52kFP+kz4O98EsAuwTaj3cO/EMoZRhquhm+iLBYYZbvYLWzU0K7LABUN+ubTopKG
         vZcXlQAnhDhEHPg4HvpxhuL7sHRJb4CFEpgsXmrNKnd3Hdk8JAdCHA1fk8MiwdhIWCvB
         c6gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733844113; x=1734448913;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=09jUxtKKNci42VhtTFd6c+JmlQ8B/KYHoGduA44v89c=;
        b=dmo+XvHlV6/ieMb5gwGxk2cvHYh2tfPqNSsG3SZaj1Bwswgjf5rB7WWK9xYU6bjscR
         JNyfPQudYcynyoddeJaIAUhYWr90Q588sNtfXF4HIztDPrBUWkT/5vtcu6T5CaCGIw6+
         RCzMbLXJdbuIXZkU6Asz9abIIYCJAPA3sHkkNsDcIxNB0JyoR31xuNcNCbDhnzM+5q4N
         hEOnCkiFIhC/ws8q+z/w8nMbUydMZeabDx5KuS6ywqSPkMaWAOL+mCycUiqhGcTRuerv
         q0jZ4BwOqklIu3WYqbGm9I9dLWAq/aTqO6NdD9HBlahLu8hF312RzWHq3iFnlNzBGswj
         lhpQ==
X-Forwarded-Encrypted: i=1; AJvYcCVWpaC4X4zPboO5Ny4OCIU+KyErlySrSojtvkS8fJH1U8vnJyKyyQRCRSt/8y2AW0ETA7MxqU9XdcA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwLU9ljadlOUvWpQe/vjyDOa3Yd0RpQuloCUn6/eMfEYpkclI9f
	CVRxu177+5kimjBHphdDe+5yV1Ws7lK4eI4OiBevlsZM2EzS3GIN
X-Gm-Gg: ASbGncsbIQeac0ySNsUNIStJC+p0UcAYUlqA3EaFjj5Pt/WBEWfUYslYk5X2/364J+M
	7VQikEwSWbjDVa9gKyUsJJv1qs8XBIN79FYcb6/4mihERKv/SfO5/kO79dvLmINa2LjUFAMNCGC
	FHoWCej3AcmXW87379u9pviBBT2i2TLutOwrD6il6Lo0zegsLl9k8aViHlWNSgXVasFyyuSF57Q
	BmfyWMbjkgBwrszZjcWaz9LyUYl5LuPQKioaFH7ONTHIlhyDW4Kr0xrPB1ohLxXDJI=
X-Google-Smtp-Source: AGHT+IFs7iIQmreKKmGdZTBsmvII9u88NSMDD37+TggqNMFJ5WlL8bQ8B4cEqJwadt9QNadej/dq5Q==
X-Received: by 2002:a05:6000:4604:b0:385:d7f9:f16c with SMTP id ffacd0b85a97d-386453f9740mr4857763f8f.46.1733844112659;
        Tue, 10 Dec 2024 07:21:52 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------mzpJtawHAmPIUL3RdtV0eFmM"
Message-ID: 
Date: Tue, 10 Dec 2024 16:21:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 6/6] xen/riscv: relocating and unflattening host device
 tree
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: 
 
 
 <34fbc3bf-f740-47bd-90e4-2f8b9ce46cfd@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <34fbc3bf-f740-47bd-90e4-2f8b9ce46cfd@suse.com>

This is a multi-part message in MIME format.
--------------mzpJtawHAmPIUL3RdtV0eFmM
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 12/9/24 4:57 PM, Jan Beulich wrote:
> On 09.12.2024 16:56, Jan Beulich wrote:
>> On 27.11.2024 13:50, Oleksii Kurochko wrote:
>>> Relocate FDT to Xen heap instead of using early mapping as it is
>>> expected that discard_initial_modules() ( is supposed to call in
>>> the future ) discards the FDT boot module and remove_early_mappings()
>>> destroys the early mapping.
>>>
>>> Unflatten a device tree, creating the tree of struct device_node.
>>> It also fills the "name" and "type" pointers of the nodes so the normal
>>> device-tree walking functions can be used.
>>>
>>> Set device_tree_flattened to NULL in the case when acpi_disabled is
>>> equal to false.
>>>
>>> Signed-off-by: Oleksii Kurochko
>> Acked-by: Jan Beulich
>>
>> Albeit ...
>>
>>> @@ -71,6 +72,7 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
>>>                                  paddr_t dtb_addr)
>>>   {
>>>       const char *cmdline;
>>> +    size_t fdt_size;
>>>   
>>>       remove_identity_mapping();
>>>   
>>> @@ -95,7 +97,7 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
>>>                             _end - _start, false) )
>>>           panic("Failed to add BOOTMOD_XEN\n");
>>>   
>>> -    if ( !boot_fdt_info(device_tree_flattened, dtb_addr) )
>>> +    if ( !(fdt_size = boot_fdt_info(device_tree_flattened, dtb_addr)) )
>>>           BUG();
>> ... perhaps better
>>
>>      fdt_size = boot_fdt_info(device_tree_flattened, dtb_addr);
>>      BUG_ON(!fdt_size);
>>
>> ?
> And then I notice that Arm has no such check at all. Better stay in sync?

Agree, it is better to be in sync. I will drop the BUG_ON().

Thanks.

~ Oleksii


--------------mzpJtawHAmPIUL3RdtV0eFmM
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    


    

    
On 12/9/24 4:57 PM, Jan Beulich wrote:

    

    

      
On 09.12.2024 16:56, Jan Beulich wrote:


      

        
On 27.11.2024 13:50, Oleksii Kurochko wrote:


        

          
Relocate FDT to Xen heap instead of using early mapping as it is
expected that discard_initial_modules() ( is supposed to call in
the future ) discards the FDT boot module and remove_early_mappings()
destroys the early mapping.

Unflatten a device tree, creating the tree of struct device_node.
It also fills the "name" and "type" pointers of the nodes so the normal
device-tree walking functions can be used.

Set device_tree_flattened to NULL in the case when acpi_disabled is
equal to false.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>


        

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

Albeit ...



        

          
@@ -71,6 +72,7 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
                                paddr_t dtb_addr)
 {
     const char *cmdline;
+    size_t fdt_size;
 
     remove_identity_mapping();
 
@@ -95,7 +97,7 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
                           _end - _start, false) )
         panic("Failed to add BOOTMOD_XEN\n");
 
-    if ( !boot_fdt_info(device_tree_flattened, dtb_addr) )
+    if ( !(fdt_size = boot_fdt_info(device_tree_flattened, dtb_addr)) )
         BUG();


        

        
... perhaps better

    fdt_size = boot_fdt_info(device_tree_flattened, dtb_addr);
    BUG_ON(!fdt_size);

?


      

      
And then I notice that Arm has no such check at all. Better stay in sync?

    

    
Agree, it is better to be in sync. I will drop the BUG_ON().

Thanks.

~ Oleksii

    

  


--------------mzpJtawHAmPIUL3RdtV0eFmM--


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 15:23:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 15:23:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852749.1266458 (Exim 4.92)
	(envelope-from )
	id 1tL25N-0002ut-8D; Tue, 10 Dec 2024 15:23:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852749.1266458; Tue, 10 Dec 2024 15:23: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 1tL25N-0002um-4H; Tue, 10 Dec 2024 15:23:41 +0000
Received: by outflank-mailman (input) for mailman id 852749;
 Tue, 10 Dec 2024 15:23: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 1tL25L-0002ug-Ml
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 15:23:40 +0000
Received: from DB3PR0202CU003.outbound.protection.outlook.com
 (mail-northeuropeazlp170110001.outbound.protection.outlook.com
 [2a01:111:f403:c200::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id baa66576-b70a-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 16:23:38 +0100 (CET)
Received: from DUZP191CA0012.EURP191.PROD.OUTLOOK.COM (2603:10a6:10:4f9::6) by
 DB5PR08MB10164.eurprd08.prod.outlook.com (2603:10a6:10:4a1::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.12; Tue, 10 Dec
 2024 15:23:34 +0000
Received: from DB1PEPF000509F4.eurprd02.prod.outlook.com
 (2603:10a6:10:4f9:cafe::ad) by DUZP191CA0012.outlook.office365.com
 (2603:10a6:10:4f9::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.15 via Frontend Transport; Tue,
 10 Dec 2024 15:23:34 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DB1PEPF000509F4.mail.protection.outlook.com (10.167.242.150) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.7
 via Frontend Transport; Tue, 10 Dec 2024 15:23:32 +0000
Received: ("Tessian outbound b1586bb311c4:v524");
 Tue, 10 Dec 2024 15:23:32 +0000
Received: from L32fae9d7032c.2
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 4F2F7C41-8A61-4BF1-9A60-721D2B33B88F.1; 
 Tue, 10 Dec 2024 15:23:26 +0000
Received: from AM0PR83CU005.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 L32fae9d7032c.2 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Tue, 10 Dec 2024 15:23:26 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21)
 by GV1PR08MB10503.eurprd08.prod.outlook.com (2603:10a6:150:16a::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Tue, 10 Dec
 2024 15:23:24 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632%5]) with mapi id 15.20.8230.016; Tue, 10 Dec 2024
 15:23: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: baa66576-b70a-11ef-a0d5-8be0dac302b0
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=I8TKGExsqMS7kEyH1HGB2iABCpsjFtABavcEKKWXms8cPaT3blY6WoI8CvBkKWCv98LVL4Z/deJqDWvkNqS5QdmhIea38K+v1g/6G/sUKTCIL0QkrvGkLVyKc9fqEfLUi5QgRpUkR1vZCaGGAK1KbP9Q35h8xQ4qNTYaSHVO1Pijdnu7Lzl4nRXfKCtGmZpa9mmRIg69/rFVjCUvGJ7E/vtqWDjrJHGLLQaClGSj9ZUXNArbFAbo8Zefg+5xYt87StkqpEoCv6BoSBMaeSOcM6fXZxUP79jCsA56OIqQ+Ji3JnguQo9X9S8vhvsyLRNZRBoMVKk9CxuHASqQL1+Svg==
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=FqDKqoHswHoUumjOcdGZj78TBiNQbQgoGNZSJzRwtxs=;
 b=YYT6WUXEoipXzVL2PrAKxMxTH926+8lIldlbEH0bp1llOt8TiNgUZpP1DdG35A/cx6EEHM69X5vXhST+t7+xHquuNI8NfA7SU7L3g1N9uKYQa5jaLJBUh9FZcqTmVrU2w1KOOER0b6qeO8ni2MrspD3rWrVwGY2TKFtPfOVYe8lOTU+rUeNVItG8TRwIDGGXghH2RZkSCNkkzq47auUQg5lBMK/BtxfH2td6vwMJ+6nISDIWE0p22mKJHCkff3+Z0gKhlT2ne/KM/WEujJDs3Uo1XKVfehzCvbPcF6u2Nh3rgzb16qzng6De+HD/hfmD+32RZvhQCboTTyJsHRidjw==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=FqDKqoHswHoUumjOcdGZj78TBiNQbQgoGNZSJzRwtxs=;
 b=Swp0LPA2qs534y37gOvxXn4FXKeQAUWS9QOV5sCUp7TGKcxJ9nwsWbRotcqvXCyphlbZCODNB6Fsr63n2FBcC4nagKKheF8YL9UZHPTwDb8m/dUt2SwiZc3PEKlhRIBoaCLdPjNQFkyhUEyMoh1EipjIOkJzSfSUXSSdHzj08PA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 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
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: a6838905a198f812
X-TessianGatewayMetadata: Xvz1KgZgyOCSk1lSZb/Pqk1zp0nKQdLihH0nXzSnypCS17SObXbGQn98DePxHMt+/ym8jjA4hKBNWtkYHyv1A6EYmF76gwZpghjLcdPUvMi7l+tXwmJgUSmhCPyllVH97f1LokT9sZ8FzA9uCIGapVzYWjBPhadwtavJt0VqsAY=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hwB8hVME3oQDKdNkomX/BTcQ5VaB8YMllzSnydL0a4WtHi/QBcbMwiH58SxcwDZhZQKmGTaR58AmWYpujfpPZviPUK21tzsoVMHSb6pBkgU4Npw7reTiEOY7No7A9fg4JL3BpfvhflgZyworORZaHf3GXjSsUKqziPjHqDtst85hM0MGfOEWHkn4iVfw01kymWd5zJ5IyaG75B3wMDiXqoVNOqLRpNijtiiVpPNl0smqd7vW3zjFRBZyRs0OLjd3ddFycGmeNZ1u1QVIkg25HW3PC8B7vtYY0gpXUMDOtk370zEuLi543Ko/UOpCfGB1Nbg/DVkiYKjzDKadYVBlBg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=FqDKqoHswHoUumjOcdGZj78TBiNQbQgoGNZSJzRwtxs=;
 b=AAvA9E+3qIih33wmW90ExZGPKu5PYEWpqQr1Cmc5AYUnJKjGOwGDyIdIKK/cbAFhuFW+8AwX0nFGxC8BWT+xjWWSE7Pc5pB8myGd67JRvi4sSiqsZIUCW7PNQSm/uKtojXCkZ+8srszCKijKeLdqKn36Gh5m/aC4JUrphh0y70MxhmXj51gVeCHtfqWwkctlAc0Fr3+71ii5C0w6Cy5ae6WKM80yJRSDQ5C+x7xTinl6U+iLkkK1whSbCJE8WO7UTxzhr8wwrt5jMWJLsVu3sVJfDVfIC5bYKJfmxhUaFyBxFmSViG++rasA6VP/h5iHl34cvsN34Y3CTINMS2jyNg==
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=FqDKqoHswHoUumjOcdGZj78TBiNQbQgoGNZSJzRwtxs=;
 b=Swp0LPA2qs534y37gOvxXn4FXKeQAUWS9QOV5sCUp7TGKcxJ9nwsWbRotcqvXCyphlbZCODNB6Fsr63n2FBcC4nagKKheF8YL9UZHPTwDb8m/dUt2SwiZc3PEKlhRIBoaCLdPjNQFkyhUEyMoh1EipjIOkJzSfSUXSSdHzj08PA=
From: Luca Fancellu 
To: Michal Orzel 
CC: "xen-devel@lists.xenproject.org" , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Volodymyr Babchuk
	
Subject: Re: [PATCH] arm/domain_build: Make find_unallocated_memory() more
 generic
Thread-Topic: [PATCH] arm/domain_build: Make find_unallocated_memory() more
 generic
Thread-Index: AQHbSuu+5rMu+POVOUWRmNRoDUJ5vLLfmOuA
Date: Tue, 10 Dec 2024 15:23:23 +0000
Message-ID: <093FBC90-7C6E-4ECD-8D9E-3D1DFBEAF435@arm.com>
References: <20241210101001.91578-1-michal.orzel@amd.com>
In-Reply-To: <20241210101001.91578-1-michal.orzel@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DBAPR08MB5798:EE_|GV1PR08MB10503:EE_|DB1PEPF000509F4:EE_|DB5PR08MB10164:EE_
X-MS-Office365-Filtering-Correlation-Id: 6223400c-cc7b-4770-f2f6-08dd192e9bbf
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|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?MHNYaGNqaFNFRVpEQlBmVWN6bEtXSlg2eE5jbnFxMkRkS1EwYWhtS0Q3U1dj?=
 =?utf-8?B?bzZVaFFidHdNS0MxQzdFdHNFcFdHTDVlMlB1TWx3Tkh0WGJNS3l6Rk9SQWxs?=
 =?utf-8?B?dVgwK05NMDJJVlgzYXRuei9wRG5seVY3dzN3QVg4RTUwYTNZVFZwaFNrREZp?=
 =?utf-8?B?V2ZWQmNIeGhRalI4aElGSUhlSHJuSnhnWC9XeEo5NTFkTmFWdVRFTkgyL3ZI?=
 =?utf-8?B?UzBZa3RVMGdlTjBCdjZ6NmpKRFN2eDNpcTJqODc0eWxCZ2ZEUGZEZzFNSlJ6?=
 =?utf-8?B?R2ZIZmFmVUw0L0U4TFJ3MlY3cmVZbjBXVzFjb21kOHgwaVhTS2R4Q3V0dFlO?=
 =?utf-8?B?N0Jxak1PZTl0K1RpQllmTkJ5UXFZbXV3OWpNSFhwSFUvbWNxQnBLQndjdE80?=
 =?utf-8?B?MTNLTnVmRVZNcm8yOEF5cGRKUTc4T1JBM3ZzTERCS1o0SzgrTVhvOVphZ2NN?=
 =?utf-8?B?L0pKZGNjcTJpTWpKMDM4T3JOT0RiUWxjTEcxMUFmSW8wQzFGZlg2NG1ZdUVU?=
 =?utf-8?B?cloyZDhWMWUvSC8xeU9jcERNSzVxbEMyOVQyVklOcHIybllNd3ZuZG9reGYx?=
 =?utf-8?B?VGpPemkxazRpeVl6VlRkUnNTT2JGbnpRWW04T1R1U0ZJeURvaldxTGF3em9T?=
 =?utf-8?B?dVdrU2tlZ1UzVnpScnNnb3dVZndJL1F1TnhSVnVqcnFkQm93M015RVJFSGNr?=
 =?utf-8?B?am5peGE2c0lGZnkyblFrYXlEdzVXb2lGK0tyUEw5cVBPcXJTSHJ3QmJ0ZGpk?=
 =?utf-8?B?MVlSMU1zWnZqUkR2bzRQT3Q2dmdtaHdkUkxKSm8wNE9ZSWtjUmZpTFhNb0J0?=
 =?utf-8?B?aGtDUm1QQmJBWkRTcmlNemFYWG5xMzJDclZlMHNwK1kzLzBMa0N6RDdOSTJq?=
 =?utf-8?B?enZqcThNOGtMUVQrQmFFdEVyM085d0ZnbkJzMXBSVTczZ2VRdUpNYy93NVpx?=
 =?utf-8?B?TkdJQS9ZS2FPK1dPZWtLSG5zbW9CS0xSZHpITkhVS0ZaSndOeHdscjhXTWNh?=
 =?utf-8?B?N2tJRkJPN2FIY2tJbTBXM0EwaW9Mb2JGQkRzUHBoMEdpcFZXOVRGQi9oaXc0?=
 =?utf-8?B?L2RXL3RKU29vNnFhTkJiZk5aclpHQjBxQ0hYZ3RrRWFGeThVNDluQVZxZFdp?=
 =?utf-8?B?TUpMcmFxM3hJaTRQNGc0TENTdUFaa3RiQmtqTnpHazVsUFVxWDc3d09lNFdw?=
 =?utf-8?B?eGc3dzU5V0Y3cHQ4REpHM2dQS2p5KzgyWTdlZS8vZVRBb291WDZ6a01YeFc2?=
 =?utf-8?B?MWZITlBiQzUrWi9XbUt5Rmd0VDYycnIva0g2WUlmMGdXVjB0aSt1aEVNWHBy?=
 =?utf-8?B?dG9NUEI1dEdybDV6MHl4NzhRcXdJNTFMWDdPdnhDT2xHLzA2djNZVncrZXRH?=
 =?utf-8?B?Z25nb2gwR3VQRmh2eXVPUWg2WjdKZXVoUjFZRDkxdVFmTk5tdGlQYmdETXp6?=
 =?utf-8?B?a2granFFMG1KYk1OZkg2cWoyd1lwQ1FCMm9HaFZwL3QrM29iSER5bFA0eDhT?=
 =?utf-8?B?SGdPNHhjcDV5UUMrL2dQR09iNGpwUS9xMHBBMHU2NVU3SURkMEJGN0tmQk9a?=
 =?utf-8?B?bXJLY3ArTUV1eDRTZVlkeUUwdTQvQlZkZjR3VzlNcFBVUWp6YURtdEY4N3Rq?=
 =?utf-8?B?c3VpTk9lVHh1VWdyK3dOaUZxK0J5TnZCRS8raHQvOWRPQWJ5LzZzeFVFZ1RL?=
 =?utf-8?B?bGJlMmNPcmhhS3dXYWl4OXdiSG83c1VDR2RocXdmQjlMaFVVV2lVejBjT3lo?=
 =?utf-8?B?bkV3bDh4YU9TUDJWUjVYWHJtUDBJSitsWTlnNUZ3NFZOQWt4clRFNUtoNll3?=
 =?utf-8?B?SDFjR1BOeE4xRnM0cURiOFRnLytZVE1MTnNqalRsV2dmckd6NGt3dWJjQ25a?=
 =?utf-8?B?OXJDYWFqRldUd0NmK1dOY1VneEJxRjM4YkNyeWtzWWcwZ3c9PQ==?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <46541C600F01D84A999BDEAF44CF9801@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR08MB10503
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender:
 ip=[2603:10a6:10:1a6::21];domain=DBAPR08MB5798.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB1PEPF000509F4.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	366e325e-76ac-451d-49c0-08dd192e9676
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|376014|14060799003|35042699022|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Q2xwdSsvSHdEMDI0RkV4ajNVN1h4enYxbjRCeEZaUGJMTWtac1BCVGJOeEFL?=
 =?utf-8?B?ZWJscEJHMG9LcUVVcnZUakRvTy9GRHRsNmowRFdTY3FMYUlEQzZlZUYvRW83?=
 =?utf-8?B?Vmg3VHdWL0tpRDlIRXJWa09vNUpMOXBRREtaQ2JleEJ4WjBCeVNlYnBDaWky?=
 =?utf-8?B?Q3RSTW53VW93ZzVDaU9IK3ByaU9NdnFnOUtEekFGcW9kQlljUzhnTmVheHRx?=
 =?utf-8?B?WUFhOVJDT09KSVNmcFBhVnUxSVpNMGwrY3hLSldaQ2JLOTdsdkdjbGoveGFr?=
 =?utf-8?B?OEhycmdVU2lubEV6bDFXcmZ5STdpT0tEQXY2VVJ0dmdnS3ZNTDg3M2ZJKzNq?=
 =?utf-8?B?NzA4dFRpY01CVmgyMjhaVkNNb1kzaSs4VHBRTFN3bjBSNnZURUVWNGtnaHI5?=
 =?utf-8?B?dDFMNFM5cWs1T20zK3NvYzVIVCtzYlJNRzZIblhDM2RMSUdXb0dScHBNb2JM?=
 =?utf-8?B?Z2gxTW8vRWNvZTNFTm5GU0I2MjNvZENIaGlTWm8vV1dOOTcwY0NNdFN0Sm9K?=
 =?utf-8?B?S0pxQmYyVkY1WnJxT3RVanhEeEJZVThzQkp5L2tBREpDOFhUWEM1QXFvL212?=
 =?utf-8?B?Vnpkd3FFaVpmRkZ6RWkzZVVOWGdYcVVmN3FsdjBrMTF4b0phWm1wK3JHN0hO?=
 =?utf-8?B?UE1iQTFuREgyRmhVWUxsdE9oaU5waUxZV0pMRTZuTVdMZ1A3dyt3RDh5MVNw?=
 =?utf-8?B?aWpuTTc5WlVBMW5ObkY3Q3A3VzJRYzhJUGFsTDNZaDdySWhPSVJpa2FrRFlX?=
 =?utf-8?B?Smh5VkQyRzN5VXp2dGlsWmF6T3gzVmVJZ1NCbE5xZU1WUXRiMDRJOFBYMERk?=
 =?utf-8?B?amFOWlJtREZybjh4RGFMSGJxanc2K2NRR1g2blBjb21VTUsvcmd0eDdzR29G?=
 =?utf-8?B?eHN2a05nM0pKd1pkZmlyM2hGMTl2cFNtNXRjcXE0MG1zUVY0eXUxVjJ1U3ZL?=
 =?utf-8?B?eTJTNUZFTnBZY2M3Y3p6Ryt4TWFyRlBiSmFGUFZ3eHR1TkhNckRGMWd4YnpH?=
 =?utf-8?B?Q0tnU1BJYmprSklVSXBERlR2RGxuMWc0L1BUZkQ0K3dIeUV2MlI0K2JoQmxx?=
 =?utf-8?B?R1h2UU16MnFiWThkLzhyNDJHY2hDWTd6Z1JUSmRuMTRkRG9pZ3gyZXdDSmQ5?=
 =?utf-8?B?M0VVRHowcVdXM0c3WmxrVlpLWXU3TkdCSC94RWdscmVTcmRvT0h4cG1ySDhy?=
 =?utf-8?B?bkxabUhzbmVQVTh4cTNscy9jRVhobTZPNmtvK2trYURMUGY5bEo4Y3E4UHZx?=
 =?utf-8?B?bjArYU55c2h3b21USTZrbWF1WklSVHROV0dhSDl2WEJTNUZyb0xVdVkvelcv?=
 =?utf-8?B?eVlXY3YrUFJUbERuYkhEVkl6WkxTUUNRaktHaks3OWxxME9oYlVFaFJ5U0sy?=
 =?utf-8?B?QlZYTzc0dGxZM0EwbXc3bUpzMHZTaWJjWW5rUnp2bkZKVG8zbStkVnFoVHNm?=
 =?utf-8?B?S0lSTkRZaXROQ3h3K01GS0Y2aXJ4a1E3MUZKMVoxd1ZmRGUrVWM3WGE4M1Ix?=
 =?utf-8?B?NHQ0U1lFRHFBSnlxM0xJL1VGNVJ5NTNVR0k1aFc3dTdGam5zc05GUXNMZXh1?=
 =?utf-8?B?VHA3bVRCa1RFbDh0Y0d2UVRYb2RoZDlZQ0VEQnVLWG1KdWdMdzBKL24vMC9S?=
 =?utf-8?B?WXgyelpRYVNuaVpGZm5uTk9CWUZsTWx4RVRkR3BINnZrTXQ4QUdIVmNBWmNu?=
 =?utf-8?B?dy9PZldEYjVWL0N3aURML3JBMU5OcDZSU3JnYlZ6aDkrdzRGRkpja0dkYW56?=
 =?utf-8?B?dGFtWHB4aEZSS0Z5OTRuT0RNcG9kSC9RaU5oQW1UTTltWTRLejFHQzB2TkJl?=
 =?utf-8?B?K3lJTFgzU2k4ZHVWV0oxWDVNYWZRckxYcTk1a2xxNGpYd3VsYmZzZVFjeGFB?=
 =?utf-8?B?cXFQNEtTR09OUEN3eEJpVlczZk5jbm9zKzFJR0NBamVmYm1nU01SOU5SNWxJ?=
 =?utf-8?B?NTZtd2lLNU5Oc1kyL1Rucmo4VEhHZ1hhaEwxSnFVZnZRU2tZM1NRTDl6dUg0?=
 =?utf-8?B?eGJ2cStxZUJnPT0=?=
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(14060799003)(35042699022)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2024 15:23:32.8247
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6223400c-cc7b-4770-f2f6-08dd192e9bbf
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB1PEPF000509F4.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR08MB10164

DQoNCj4gT24gMTAgRGVjIDIwMjQsIGF0IDEwOjEwLCBNaWNoYWwgT3J6ZWwgPG1pY2hhbC5vcnpl
bEBhbWQuY29tPiB3cm90ZToNCj4gDQo+IEF0IHRoZSBtb21lbnQsIGZpbmRfdW5hbGxvY2F0ZWRf
bWVtb3J5KCkgaXMgb25seSB1c2VkIHRvIHJldHJpZXZlIGZyZWUNCj4gbWVtb3J5IHJhbmdlcyBm
b3IgZGlyZWN0IG1hcHBlZCBkb21haW5zIGluIG9yZGVyIHRvIGZpbmQgZXh0ZW5kZWQNCj4gcmVn
aW9ucy4gSXQgaXMgbm90IGdlbmVyaWMgYXMgaXQgbWFrZXMgYXNzdW1wdGlvbnMgYXMgZm9yIHRo
ZSBwbGFjZSBhdA0KPiB3aGljaCBpdCdzIGJlaW5nIGNhbGxlZCAoZG9tYWluIG1lbW9yeSBhbHJl
YWR5IGFsbG9jYXRlZCwgZ250dGFiIHJlZ2lvbg0KPiBhbHJlYWR5IGZvdW5kKSBhbmQgaGFyZGNv
ZGVzIHRoZSBtZW1vcnkgYmFua3MgdG8gYmUgZXhjbHVkZWQuDQo+IA0KPiBNYWtlIHRoZSBmdW5j
dGlvbiBtb3JlIGdlbmVyaWMsIHNvIHRoYXQgaXQgY2FuIGJlIHVzZWQgZm9yIG90aGVyDQo+IHB1
cnBvc2VzIHdoZW5ldmVyIHRoZXJlIGlzIGEgbmVlZCB0byBmaW5kIGZyZWUgaG9zdCBtZW1vcnkg
cmVnaW9ucyAoZS5nLg0KPiB1cGNvbWluZyBMTEMgY29sb3Jpbmcgc2VyaWVzKS4gQWxsb3cgcGFz
c2luZyBhcnJheSB3aXRoIG1lbW9yeSBiYW5rcyBhcyBhDQo+IHBhcmFtZXRlciB0b2dldGhlciB3
aXRoIGEgY2FsbGJhY2sgdG8gcG9wdWxhdGUgZnJlZSByZWdpb25zIHN0cnVjdHVyZSwNCj4gYXMg
dGhlIGxvZ2ljIG1heSBkaWZmZXIgZGVwZW5kaW5nIG9uIHRoZSBuZWVkcy4NCj4gDQo+IEFkZCBm
aW5kX2hvc3RfZXh0ZW5kZWRfcmVnaW9ucygpIHRvIGJlIGNhbGxlZCBmcm9tIG1ha2VfaHlwZXJ2
aXNvcl9ub2RlKCkNCj4gdG8gY29udGFpbiB0aGUgbG9naWMgdG8gZmluZCBleHRlbmRlZCByZWdp
b25zIGZvciBkb21haW5zIHVzaW5nIGhvc3QNCj4gbWVtb3J5IGxheW91dCB0aGF0IGFyZSBub3Qg
cGVybWl0dGVkIHRvIHVzZSBJT01NVS4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IE1pY2hhbCBPcnpl
bCA8bWljaGFsLm9yemVsQGFtZC5jb20+DQo+IC0tLQ0KPiBUaGlzIGlzIGEgcHJlcmVxdWlzaXRl
IHBhdGNoIGZvciBMTEMgY29sb3Jpbmcgc2VyaWVzIHBhdGNoIDMuDQo+IEZvciBkb20wIExMQyBj
b2xvcmluZywgd2UganVzdCBuZWVkIHRvIHBhc3MgcmVzbWVtIGFuZCBnbnR0YWIgaW4gbWVtX2Jh
bmtzLg0KPiAtLS0NCg0KSGkgTWljaGFsLA0KDQppdCBsb29rcyBnb29kIHRvIG1lLCBJ4oCZdmUg
YWxzbyB0ZXN0ZWQgaW4gb3VyIENJIGFuZCBubyBpc3N1ZXMhDQoNClJldmlld2VkLWJ5OiBMdWNh
IEZhbmNlbGx1IDxsdWNhLmZhbmNlbGx1QGFybS5jb20+DQpUZXN0ZWQtYnk6IEx1Y2EgRmFuY2Vs
bHUgPGx1Y2EuZmFuY2VsbHVAYXJtLmNvbT4NCg0K


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 15:31:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 15:31:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852763.1266467 (Exim 4.92)
	(envelope-from )
	id 1tL2DF-0004gm-0I; Tue, 10 Dec 2024 15:31:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852763.1266467; Tue, 10 Dec 2024 15:31: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 1tL2DE-0004gf-To; Tue, 10 Dec 2024 15:31:48 +0000
Received: by outflank-mailman (input) for mailman id 852763;
 Tue, 10 Dec 2024 15: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 1tL2DE-0004ZK-9K
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 15:31:48 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dd9f893d-b70b-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 16:31:46 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5d3e829ff44so5354502a12.0
 for ; Tue, 10 Dec 2024 07:31:46 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa6260e8af8sm847810266b.191.2024.12.10.07.31.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 07:31: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: dd9f893d-b70b-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1733844706; x=1734449506; darn=lists.xenproject.org;
        h=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=mQQwyrOiXs9wQRzf6OTbTRmqzabvPyR2Prbr4nAcO0M=;
        b=T3mPCMW1snBqQiZ1kv2snNnIzh20F6CWDFvfEWEFu5rMVV02n2oKokPByL11On6OLb
         dPq81n3WGXzj78dUguuzIU4Cgf/pa6BJrQmj0eANbN17ItDmE6pPHOQ1ZWOuHrJOrO08
         8dmQ4mHc+ah/zsV4y0dQSEQ1xU/CG3wfSrXnFPaWCgPkTyxPJS5+75UY6E4FXePsUyEN
         8qipR8eLKjHAcXEgUrSyVJPkQAh9lLd6IbaAxX6QG5dV/YTIAK99Sa/XGH6wxLNaURGA
         9prnb3BSfE+8egSaJ52ZLoiaxkMMJ5J5ldwXwno40THSOAvFS0kiqPej0w5vK68B63N6
         BTrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733844706; x=1734449506;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=mQQwyrOiXs9wQRzf6OTbTRmqzabvPyR2Prbr4nAcO0M=;
        b=d8V49jOxGa8ByqJcZLZuiUpdG0lhZAb9glux+Yn75vrl6YQSAlOa6yrs/rnJXvltF9
         w1JyoyqLLadrdQNVvK6kGRBPOTtw/gSCAXqNlnVTMIoC/i/2Wg3JOCcDhgb4fnIGGm48
         eh6kF3IS0POrOPyGfjE9A8x4Sdwe8MtEdxDofcc2gOPubFIDVMmr0M2Kpvlfc/is3QUt
         N7eClP+UTgoLqSlue0nlCwmRiTsoePqjHMTaYQkqYzIFnR53BrQ2zoTj6ddUdZufmQUp
         IMEvcIy2+cSK5fXLXptPGQQLy4vyAGQul1M4diJ1OOqVjhmNLZYC7j5bxpQjfP9Ppd7I
         V+pA==
X-Forwarded-Encrypted: i=1; AJvYcCU4Iv66eG3ygADUAXwdeIiCMgrEIbtbe+gUlvMbzo7FLfWRwTvNZ6sWNh884gP6Lan8KyR5dUzsGFA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzt8J6kYlzwRPsFBjCUDgXXFIwSShjKMwiLsxAEl8AAEpi43/up
	k6e5iiWBjsbd/U8/5UP2EPgmoo1r/oBq+MNH7flHFWhJ8AWBA8Ku
X-Gm-Gg: ASbGncvofAOo81lxZEJmv2PE/aINI9p8HdfilfYccgcnW4ttwNHgKbTE6+xSCDrFKc/
	1oWpEZuoqI3bBfiEaUgF9g7FPc4s7En5SgZ3lfOqXgC2mnuWCHNj3vZbenFz15GT1vaCkllWhfI
	WDfhfwpqxfK3yyXABdeH8b2ePzSFZuMvRgRNpAM0OptnccefoaqRk8k3tmxLwgnYn16od2OT+uy
	S6VHrwcpmrGG5JTWAZ4+5Q6eihtleaQhiMFhchy0PQ7CuESY4vkO84oHb6ap7pGNOw=
X-Google-Smtp-Source: AGHT+IHsEqH3wph9DEBW4OgU4CKgPaWwJMMKcRMkm/WeSjCVMHfz3u3XRRUrPFyRJRT2rwBg7qC96g==
X-Received: by 2002:a17:907:6092:b0:aa6:9229:352a with SMTP id a640c23a62f3a-aa6a02fabeamr328396266b.26.1733844705509;
        Tue, 10 Dec 2024 07:31:45 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------W5ULcycpnm84ThRl3A4dX1ps"
Message-ID: <5b3b23a6-6e73-40af-95b6-65be22ad63bb@gmail.com>
Date: Tue, 10 Dec 2024 16:31:44 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 4/6] xen/riscv: introduce cache management operations
 (CMO)
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: 
 <1310a2fb3b9824ae66f850600925127fdfdb44fa.1732709650.git.oleksii.kurochko@gmail.com>
 <9d49befe-4592-4e71-ad0b-9a0af34253f5@suse.com>
 
 
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: 

This is a multi-part message in MIME format.
--------------W5ULcycpnm84ThRl3A4dX1ps
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 12/10/24 1:39 PM, Jan Beulich wrote:
> On 10.12.2024 13:19, Oleksii Kurochko wrote:
>> On 12/9/24 3:38 PM, Jan Beulich wrote:
>>> On 27.11.2024 13:50, Oleksii Kurochko wrote:
>>>> --- a/xen/arch/riscv/Kconfig
>>>> +++ b/xen/arch/riscv/Kconfig
>>>> @@ -14,6 +14,9 @@ config ARCH_DEFCONFIG
>>>>        string
>>>>        default "arch/riscv/configs/tiny64_defconfig"
>>>>    +config HAS_CMO # Cache Management Operations
>>>> +    bool
>>> Hmm, and nothing ever sets this, and hence ...
>>>
>>>> @@ -148,9 +149,24 @@ static inline bool pte_is_mapping(pte_t p)
>>>>        return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK);
>>>>    }
>>>>    +#ifndef HAS_CMO
>>>> +static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
>>>> +{
>>>> +    return -EOPNOTSUPP;
>>>> +}
>>>> +
>>>> +static inline int clean_dcache_va_range(const void *p, unsigned long size)
>>>> +{
>>>> +    return -EOPNOTSUPP;
>>>> +}
>>>> +#else
>>>> +int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size);
>>>> +int clean_dcache_va_range(const void *p, unsigned long size);
>>>> +#endif
>>> ... all you really provide are stubs and declarations, but no
>>> definition anywhere?
>> Yes, this was done intentionally because:
>> - I don't have hardware with the CMO extension, so I can't test it. ( QEMU doesn't model cache and so
>>    there is no need for CMO extension emulation IIUC )
>> - The instructions used for these functions may be hardware-specific and exist only for particular devices.
>>
>> It seems useful to have something similar to Linux:
>> https://elixir.bootlin.com/linux/v6.6.64/source/arch/riscv/include/asm/errata_list.h#L135 
>> (There are also custom instructions for THEAD above this macro.)
>>
>> We could use|ALT_CMO_OP(...)| inside|clean_and_invalidate_dcache_va_range()| and|clean_dcache_va_range()|.
>> However, I think it would be better to introduce or implement these functions when|HAS_CMO| is set to|y| someday.
>>
>> As an alternative, we could implement these functions as|panic("need to be implemented\n")| in case when HAS_CMO=y.
> I think this would be well in line with various other stubs you have.
>
>> Another option is to drop|HAS_CMO| entirely for now and keep the current implementation (|return -EOPNOTSUPP|).
>> However, with this approach, there's a risk of encountering hard-to-debug issues on platforms with the CMO extension.
>> And necessity of implementation of these could be missed because there is no any notification...
> Well, callers ought to check return values?

Yeah, callers should check return value but we still have to introduce then a new KConfig ( config QEMU ) and then implementation
will look like:
   static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
   {
   #ifdef CONFIG_QEMU
     return 0;
   #else
     return -EOPNOTSUPP;
   #endif
   }

   static inline int clean_dcache_va_range(const void *p, unsigned long size)
   {
   #ifdef CONFIG_QEMU
     return 0;
   #else
     return -EOPNOTSUPP;
   #endif
   }

>
>>>>    static inline void invalidate_icache(void)
>>>>    {
>>>> -    BUG_ON("unimplemented");
>>>> +    asm volatile ( "fence.i" ::: "memory" );
>>>>    }
>>> That's a separate extension, Zifencei, which I don't think you can just
>>> assume to be present?
>> Based on the specification:
>> ```
>> Chapter 34. RV32/64G Instruction Set Listings
>> One goal of the RISC-V project is that it be used as a stable software development target. For this
>> purpose, we define a combination of a base ISA (RV32I or RV64I) plus selected standard extensions
>> (IMAFD, Zicsr, Zifencei) as a "general-purpose" ISA, and we use the abbreviation G for the
>> IMAFDZicsr_Zifencei combination of instruction-set extensions. This chapter presents opcode maps
>> and instruction-set listings for RV32G and RV64G
>> ```
> Hmm, indeed. That's well hidden in a place I didn't expect it to live at.
> Maybe worth a sentence in the description?

Sure, I will update the description. ( and probably add the comment above invalidate_icache() function )

>> and that G is needed to boot Linux kernel ( and so Xen ) I make an assumption that Zifencei will be always
>> present.
> I'd be a little careful here. Xen may be used in Linux-free environments.
> I notice arch.mk specifies rv64g, yet I'm uncertain we shouldn't relax
> that at some point.
>
>> And based on Linux code (https://elixir.bootlin.com/linux/v6.12.4/source/arch/riscv/kernel/cpufeature.c#L676 )
>> when 'i' is present in riscv,isa property zifencei is present unconditionally.
> That looks questionable to me. I don't think Zifencei can be inferred from
> I. Historically it was, and imo that's what the comment there says. Plus
> it is dependent upon acpi_disabled.

Agree with you here. And it was the reason why I dropped this if-condition when I ported cpufeature.c to Xen.



~ Oleksii

--------------W5ULcycpnm84ThRl3A4dX1ps
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    


    

    
On 12/10/24 1:39 PM, Jan Beulich wrote:

    

    

      
On 10.12.2024 13:19, Oleksii Kurochko wrote:


      

        
On 12/9/24 3:38 PM, Jan Beulich wrote:


        

          
On 27.11.2024 13:50, Oleksii Kurochko wrote:


          

            
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -14,6 +14,9 @@ config ARCH_DEFCONFIG
      string
      default "arch/riscv/configs/tiny64_defconfig"
  +config HAS_CMO # Cache Management Operations
+    bool


          

          
Hmm, and nothing ever sets this, and hence ...



          

            
@@ -148,9 +149,24 @@ static inline bool pte_is_mapping(pte_t p)
      return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK);
  }
  +#ifndef HAS_CMO
+static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
+{
+    return -EOPNOTSUPP;
+}
+
+static inline int clean_dcache_va_range(const void *p, unsigned long size)
+{
+    return -EOPNOTSUPP;
+}
+#else
+int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size);
+int clean_dcache_va_range(const void *p, unsigned long size);
+#endif


          

          
... all you really provide are stubs and declarations, but no
definition anywhere?


        

        
Yes, this was done intentionally because:
- I don't have hardware with the CMO extension, so I can't test it. ( QEMU doesn't model cache and so
  there is no need for CMO extension emulation IIUC )
- The instructions used for these functions may be hardware-specific and exist only for particular devices.

It seems useful to have something similar to Linux:
https://elixir.bootlin.com/linux/v6.6.64/source/arch/riscv/include/asm/errata_list.h#L135 <https://elixir.bootlin.com/linux/v6.6.64/source/arch/riscv/include/asm/errata_list.h#L135>
(There are also custom instructions for THEAD above this macro.)

We could use|ALT_CMO_OP(...)| inside|clean_and_invalidate_dcache_va_range()| and|clean_dcache_va_range()|.
However, I think it would be better to introduce or implement these functions when|HAS_CMO| is set to|y| someday.

As an alternative, we could implement these functions as|panic("need to be implemented\n")| in case when HAS_CMO=y.


      

      
I think this would be well in line with various other stubs you have.



      

        
Another option is to drop|HAS_CMO| entirely for now and keep the current implementation (|return -EOPNOTSUPP|).
However, with this approach, there's a risk of encountering hard-to-debug issues on platforms with the CMO extension.
And necessity of implementation of these could be missed because there is no any notification...


      

      
Well, callers ought to check return values?

    

    
Yeah, callers should check return value but we still have to introduce then a new KConfig ( config QEMU ) and then implementation
will look like:
  static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
  {
  #ifdef CONFIG_QEMU
    return 0;
  #else
    return -EOPNOTSUPP;
  #endif
  }

  static inline int clean_dcache_va_range(const void *p, unsigned long size)
  {
  #ifdef CONFIG_QEMU
    return 0;
  #else
    return -EOPNOTSUPP;
  #endif
  }

    

      



      

        

          

            
  static inline void invalidate_icache(void)
  {
-    BUG_ON("unimplemented");
+    asm volatile ( "fence.i" ::: "memory" );
  }


          

          
That's a separate extension, Zifencei, which I don't think you can just
assume to be present?


        

        
Based on the specification:
```
Chapter 34. RV32/64G Instruction Set Listings
One goal of the RISC-V project is that it be used as a stable software development target. For this
purpose, we define a combination of a base ISA (RV32I or RV64I) plus selected standard extensions
(IMAFD, Zicsr, Zifencei) as a "general-purpose" ISA, and we use the abbreviation G for the
IMAFDZicsr_Zifencei combination of instruction-set extensions. This chapter presents opcode maps
and instruction-set listings for RV32G and RV64G
```


      

      
Hmm, indeed. That's well hidden in a place I didn't expect it to live at.
Maybe worth a sentence in the description?

    

    
Sure, I will update the description. ( and probably add the comment above invalidate_icache() function )



    

      

      

        
and that G is needed to boot Linux kernel ( and so Xen ) I make an assumption that Zifencei will be always
present.


      

      
I'd be a little careful here. Xen may be used in Linux-free environments.
I notice arch.mk specifies rv64g, yet I'm uncertain we shouldn't relax
that at some point.

    

    

      



      

        
And based on Linux code (https://elixir.bootlin.com/linux/v6.12.4/source/arch/riscv/kernel/cpufeature.c#L676 )
when 'i' is present in riscv,isa property zifencei is present unconditionally.


      

      
That looks questionable to me. I don't think Zifencei can be inferred from
I. Historically it was, and imo that's what the comment there says. Plus
it is dependent upon acpi_disabled.

    

    
Agree with you here. And it was the reason why I dropped this if-condition when I ported cpufeature.c to Xen.



~ Oleksii


  


--------------W5ULcycpnm84ThRl3A4dX1ps--


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 15:33:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 15:33:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852777.1266477 (Exim 4.92)
	(envelope-from )
	id 1tL2Ea-0005VM-D9; Tue, 10 Dec 2024 15:33:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852777.1266477; Tue, 10 Dec 2024 15:33:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tL2Ea-0005VF-AH; Tue, 10 Dec 2024 15:33:12 +0000
Received: by outflank-mailman (input) for mailman id 852777;
 Tue, 10 Dec 2024 15:33: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 1tL2EZ-0005RG-7T
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 15:33:11 +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 0ec2eb67-b70c-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 16:33:08 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-5d414b8af7bso2876622a12.0
 for ; Tue, 10 Dec 2024 07:33:08 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d3f4ecdd02sm3773276a12.81.2024.12.10.07.33.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 07:33: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: 0ec2eb67-b70c-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1733844788; x=1734449588; darn=lists.xenproject.org;
        h=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=+tUWJCQZhlnB2O1JeWYFe/NJj+v1SWZkC/CgvXh7ynU=;
        b=mes7l+UbRoCetMTwU+0eIVSFrSoqZzuQc4/ZSOl+l5VZLBDSvC2BUELsRpBlfaggGP
         y46bsd5Ijoas6BUYeKRZ9xFlkgh6nRrU7UTQki/RoM5QoKA/eHhcnQUDcnpYdVMq3iXK
         PCupu/mXoC4YUE1/CZZ+hmT5XQF8ylzq92B9TeJGHXjeuycP9gtPaxE4FkUbT76v6qH0
         0rdb6a3psf3/pg6skoyt0JAWiJl1fjWTZpYXopqjEMWCd7WbAyppAobA5fZZ0UcS0ZMj
         vgNoZVj0N10qyBH2XpH4EkmLCzoxNkWJBzlmvpjRUexltFVO8g5p094ZjWkw6Xz4/iaI
         0lDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733844788; x=1734449588;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=+tUWJCQZhlnB2O1JeWYFe/NJj+v1SWZkC/CgvXh7ynU=;
        b=c9MQUheYqhIeRcCk9LWaDMn0LR1ZCgTXHkwjGkgPKmg9JYegofvlELxmhodF9xIoFP
         /OPzqlVCyN0WKzsj8YuxsXbYc250nEQLXNHbsWga50JNy0C6cURD9jG8pgcNuvn1IaR/
         7wBaNmjD+DVJE3Dm1PIW0EnbXEHXuxcu8XnZofiSLGKxVDOjTZV2FfT+qYnaDuR4SYKL
         Er1Dc999AhcccpGJtekCn+3G/cK/RKz4BIvIogmLG+t5sKXUd7Vv6ErCtt4VDE+vn3DF
         4fT70+tzywLW/EY6pzmb5x0cmK9PjdbojUSfxguW3sNR+tjw2C8xjG+UStvlIfjoHNIr
         1YIw==
X-Forwarded-Encrypted: i=1; AJvYcCUq5wGJl9YeUkVoNMHj8MfJbJRfnt9GtVDgwsY97I0YrMhNIomDU+vUbKyt6fMGMSwA6rdqzf0ydTg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxtnypbMTjzlLcb/o4fBWIeOM0HkwCPscE78DoNvNpG9tr00XIc
	hB82evJ3Czh9oKVamQpNzeGRi2iiXKl0dQfFxI3kOENLrUXHcFj4gKWJBPOE
X-Gm-Gg: ASbGncv2uR3q7cwsQwXJNM13Vre8AVcj3/7IOH+SgDwpI3bbVjtUdgMXgIauLhMgVqc
	UBYdczlOkQxoec4arMHun+/N8SkCuRweR9qU4wuQyk3moRv5ZKQ591OllrcHrw0iFDRW3+8eA1n
	2wjMgAN7n0dvv2/yUwLlfB558MXnyKNfUAXLy86rkBrlYmvpEXPGO5pLB/vd6d4CuaCVT6WZHVP
	6zL0cA3q9flpa6DSaX3JseWV+uzflva//EpxwHgYTsiPQ0c2FmRrw3lZVMwq7H2Uiw=
X-Google-Smtp-Source: AGHT+IEREuU1s6tSGUeVOTfsA7rZadKzqUPMyam7yAG74ldtFegyeZj1CmMMxkNON9BSlnWvi0O6aA==
X-Received: by 2002:a05:6402:5405:b0:5d0:cfdd:2ac1 with SMTP id 4fb4d7f45d1cf-5d3be66098cmr15129682a12.6.1733844788068;
        Tue, 10 Dec 2024 07:33:08 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------2ihRBdaY2wCB1mTC7cCBzf72"
Message-ID: 
Date: Tue, 10 Dec 2024 16:33:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] CHANGELOG: Mention xl suspend/resume
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: Community Manager 
References: <20241210145602.5039-1-jason.andryuk@amd.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <20241210145602.5039-1-jason.andryuk@amd.com>

This is a multi-part message in MIME format.
--------------2ihRBdaY2wCB1mTC7cCBzf72
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 12/10/24 3:56 PM, Jason Andryuk wrote:
> The xl subcommands are generic, but only built when
> LIBXL_HAVE_NO_SUSPEND_RESUME is false.  Currently that is only x86, so
> list them there.
>
> Signed-off-by: Jason Andryuk

LGTM: Reviewed-by: Oleksii Kurochko

Thanks.

~ Oleksii


> ---
> v2:
> Nest under "On X86"
> Expand commit message
> ---
>   CHANGELOG.md | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 8553b2e451..15f681459f 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -16,6 +16,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>   ### Added
>    - On Arm:
>      - Experimental support for Armv8-R.
> + - On x86:
> +   - xl suspend/resume subcommands.
>   
>   ### Removed
>    - On x86:
--------------2ihRBdaY2wCB1mTC7cCBzf72
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    


    

    
On 12/10/24 3:56 PM, Jason Andryuk
      wrote:

    

    

      
The xl subcommands are generic, but only built when
LIBXL_HAVE_NO_SUSPEND_RESUME is false.  Currently that is only x86, so
list them there.

Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>

    

    
LGTM: Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii


    


    

    

      
---
v2:
Nest under "On X86"
Expand commit message
---
 CHANGELOG.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 8553b2e451..15f681459f 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -16,6 +16,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 ### Added
  - On Arm:
    - Experimental support for Armv8-R.
+ - On x86:
+   - xl suspend/resume subcommands.
 
 ### Removed
  - On x86:


    

  


--------------2ihRBdaY2wCB1mTC7cCBzf72--


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 15:44:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 15:44:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852794.1266487 (Exim 4.92)
	(envelope-from )
	id 1tL2Pb-0007bL-CP; Tue, 10 Dec 2024 15:44:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852794.1266487; Tue, 10 Dec 2024 15:44: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 1tL2Pb-0007bE-9m; Tue, 10 Dec 2024 15:44:35 +0000
Received: by outflank-mailman (input) for mailman id 852794;
 Tue, 10 Dec 2024 15:44: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 1tL2PZ-0007b7-CX
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 15:44:33 +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 a5a0b50c-b70d-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 16:44:31 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5d3e6274015so5062470a12.0
 for ; Tue, 10 Dec 2024 07:44:31 -0800 (PST)
Received: from ?IPV6:2003:e5:8701:7700:f2d:e3aa:8e9e:99bf?
 (p200300e5870177000f2de3aa8e9e99bf.dip0.t-ipconnect.de.
 [2003:e5:8701:7700:f2d:e3aa:8e9e:99bf])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa67f26cff7sm391100966b.57.2024.12.10.07.44.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 07:44: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: a5a0b50c-b70d-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733845471; x=1734450271; 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=dNPnrE7XWnt+zLtq1pKSkvTLF/s7F/MO3dxMCRBovyo=;
        b=FtZYuM2A6JGG8s+K4q2zFyEnHCBZt7MP0CQ96oJkz1LDHbN7ApJCdqE6Jep5sR0goR
         lDpgah6E77YiUgIrb+JnfEJOMIXLsX2058vLemfEQi19B3tTFu+ifdaOfBCAgO/4eocL
         BK0vatLipqyDHMRtSAQiFjmq3Vmu8i17CvwcA+WpT3qq0lZVGak1Y/3KI2qSGlWTF5TB
         p4nm1saINNGM0p5cSTqmYcg2Tn8KjuWQv25f4wSzN0/Jh7bPQ9CoKZE8Yk4fgDioTOWy
         vum2OcxrsmfIylS7iO2iLMKv+HMhPFc7/dmUlbkpHaQkZro+tRxyTAnVUTJIoLVURcuF
         Ejaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733845471; x=1734450271;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=dNPnrE7XWnt+zLtq1pKSkvTLF/s7F/MO3dxMCRBovyo=;
        b=pFkbCBjBXl059+2lZ0nSVV1pYDz1cIQCUvhVRHYtf0FcB3P/q6lKn5ZEUEF55Tlvc9
         eUO1xNuMVYTWrSJWYlZOcuFnZjgeUYrXS7GEOH+ZWrNBNqffonX5zBu7vBG1Ht4dYbQ+
         xmQWrZAA2irPJ9cJTUpI677GVlfEuEkj9ORyPuY25f1FMA1yQq8UB+7vHdw4gdJScvNk
         dwn2F6xvuJupsYsXTa+XV8t9gDU4E2OnzVCs6bs537RHpVPMZxulipUKCKNQJ20iTNal
         KXdYXB/I+f8RtGuaTqtmu3Wse1ivvQipldgaQcmxr7wNqNUarXXjNGU/zazmecLPACE3
         lkCg==
X-Forwarded-Encrypted: i=1; AJvYcCXGealukSHS3Xaa5oi9SitMTSd+GJAF2ZK/Mc8Oj5NVga3t7EpqikKhTPdhHio3dUjBlWDvJGwMRJ8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzRTGpMK4wvnDLfa+ctnlqZcHnX5Vgmu/efOhQWm7cb9+W9mOwf
	oT7MQt8oOpL5WL9XP+2O4ZOJp4JDrVDh2piVYWuqmocWOMGjs20S4hVLUrq1aeo=
X-Gm-Gg: ASbGncu61tz5NvNHD0QDiNU49X7aIIr/r74YAZJYGNLdgwPKNj0U24+4fGe+pZytNhq
	dJsAybeXgHZiMPT7ZS9xthg1Rgrz9oN40wyIS/gRw7uTpaslQll5L7VICpYej1GE+zQ6qbvAr3d
	MoV/vvu9ItSKfPmWuymAClE50DR+crwkS2Cv0gbyCNBG2NysxXemduG/BmHxa8RQasOx3Efikcm
	EKEMozbiDoeLxLyvfzxnc0QTD5mx0ujS4kDz1Cx2vMt7kIosY+u8U41PdRV+f0cJ/GMy5xNw+uW
	6aOxuw8InAhHy7+GuMkXXdTFb9BN6U3rU59iB48QPbIRHpfZxaougfScMgBsZRb7Ll+TShYghnv
	P
X-Google-Smtp-Source: AGHT+IGt3siNw8wCrXWooFfJ5vcgraHSurcHzLoXTUlpcJgDL+HlrGNpIZMOiFdIMokvmXBUKrRgPg==
X-Received: by 2002:a17:906:308a:b0:aa6:650f:cf35 with SMTP id a640c23a62f3a-aa6650fd388mr1212625666b.47.1733845470750;
        Tue, 10 Dec 2024 07:44:30 -0800 (PST)
Message-ID: <32a580a6-4a38-4c8f-b5e6-4166b8cf004f@suse.com>
Date: Tue, 10 Dec 2024 16:44:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/7] xen: add bitmap to indicate per-domain state
 changes
To: Jan Beulich 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241206130221.17773-1-jgross@suse.com>
 <20241206130221.17773-5-jgross@suse.com>
 <8acde5e5-7972-4f7a-ae31-92c3f323669c@suse.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: <8acde5e5-7972-4f7a-ae31-92c3f323669c@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------LyMN4q0w2NWt80ISQEnQ4BY7"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------LyMN4q0w2NWt80ISQEnQ4BY7
Content-Type: multipart/mixed; boundary="------------0TDIASmdRJDVbbLIpHdE0lhE";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jan Beulich 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
Message-ID: <32a580a6-4a38-4c8f-b5e6-4166b8cf004f@suse.com>
Subject: Re: [PATCH v2 4/7] xen: add bitmap to indicate per-domain state
 changes
References: <20241206130221.17773-1-jgross@suse.com>
 <20241206130221.17773-5-jgross@suse.com>
 <8acde5e5-7972-4f7a-ae31-92c3f323669c@suse.com>
In-Reply-To: <8acde5e5-7972-4f7a-ae31-92c3f323669c@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------0TDIASmdRJDVbbLIpHdE0lhE
Content-Type: multipart/mixed; boundary="------------gmp0ElYS7QfKzpkZI0JhRfu3"

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

T24gMDkuMTIuMjQgMTc6NTIsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNi4xMi4yMDI0
IDE0OjAyLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gQWRkIGEgYml0bWFwIHdpdGggb25l
IGJpdCBwZXIgcG9zc2libGUgZG9taWQgaW5kaWNhdGluZyB0aGUgcmVzcGVjdGl2ZQ0KPj4g
ZG9tYWluIGhhcyBjaGFuZ2VkIGl0cyBzdGF0ZSAoY3JlYXRlZCwgZGVsZXRlZCwgZHlpbmcs
IGNyYXNoZWQsDQo+PiBzaHV0ZG93bikuDQo+Pg0KPj4gUmVnaXN0ZXJpbmcgdGhlIFZJUlFf
RE9NX0VYQyBldmVudCB3aWxsIHJlc3VsdCBpbiBzZXR0aW5nIHRoZSBiaXRzIGZvcg0KPj4g
YWxsIGV4aXN0aW5nIGRvbWFpbnMgYW5kIHJlc2V0dGluZyBhbGwgb3RoZXIgYml0cy4NCj4+
DQo+PiBSZXNldHRpbmcgYSBiaXQgd2lsbCBiZSBkb25lIGluIGEgZnV0dXJlIHBhdGNoLg0K
Pj4NCj4+IFRoaXMgaW5mb3JtYXRpb24gaXMgbmVlZGVkIGZvciBYZW5zdG9yZSB0byBrZWVw
IHRyYWNrIG9mIGFsbCBkb21haW5zLg0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IEp1ZXJnZW4g
R3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4NCj4gDQo+IFdoYXQgSSdtIHN0aWxsIG1pc3Npbmcg
aXMgYXQgbGVhc3QgbWVudGlvbiBvZiB0aGUgZ2xvYmFsLW5lc3Mgb2YgYWxsIG9mDQo+IHRo
aXMsIGFuZCB3aHkgdGhhdCdzIGRlZW1lZCBva2F5IGZvciBub3cuDQoNCkknbGwgYWRkOg0K
DQogICBBcyB0aGUgdXNhZ2Ugb2YgdGhpcyBiaXRtYXAgaXMgdGlnaHRseSBjb3VwbGVkIHdp
dGggdGhlIFZJUlFfRE9NX0VYQyBldmVudCwNCiAgIGl0IGlzIG1lYW50IHRvIGJlIHVzZWQg
b25seSBieSBhIHNpbmdsZSBjb25zdW1lciBpbiB0aGUgc3lzdGVtLCBqdXN0IGxpa2UNCiAg
IHRoZSBWSVJRX0RPTV9FWEMgZXZlbnQuDQoNCj4gDQo+PiAtLS0gYS94ZW4vY29tbW9uL2Rv
bWFpbi5jDQo+PiArKysgYi94ZW4vY29tbW9uL2RvbWFpbi5jDQo+PiBAQCAtMTM4LDYgKzEz
OCw2MCBAQCBib29sIF9fcmVhZF9tb3N0bHkgdm10cmFjZV9hdmFpbGFibGU7DQo+PiAgIA0K
Pj4gICBib29sIF9fcmVhZF9tb3N0bHkgdnBtdV9pc19hdmFpbGFibGU7DQo+PiAgIA0KPj4g
K3N0YXRpYyBERUZJTkVfU1BJTkxPQ0soZG9tX3N0YXRlX2NoYW5nZWRfbG9jayk7DQo+PiAr
c3RhdGljIHVuc2lnbmVkIGxvbmcgKmRvbV9zdGF0ZV9jaGFuZ2VkOw0KPj4gKw0KPj4gK2lu
dCBkb21haW5faW5pdF9zdGF0ZXModm9pZCkNCj4+ICt7DQo+PiArICAgIGNvbnN0IHN0cnVj
dCBkb21haW4gKmQ7DQo+PiArICAgIGludCByYyA9IC1FTk9NRU07DQo+PiArDQo+PiArICAg
IHNwaW5fbG9jaygmZG9tX3N0YXRlX2NoYW5nZWRfbG9jayk7DQo+PiArDQo+PiArICAgIGlm
ICggZG9tX3N0YXRlX2NoYW5nZWQgKQ0KPj4gKyAgICAgICAgYml0bWFwX3plcm8oZG9tX3N0
YXRlX2NoYW5nZWQsIERPTUlEX0ZJUlNUX1JFU0VSVkVEKTsNCj4+ICsgICAgZWxzZQ0KPj4g
KyAgICB7DQo+PiArICAgICAgICBkb21fc3RhdGVfY2hhbmdlZCA9IHh6YWxsb2NfYXJyYXko
dW5zaWduZWQgbG9uZywNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBCSVRTX1RPX0xPTkdTKERPTUlEX0ZJUlNUX1JFU0VSVkVEKSk7DQo+IA0KPiBO
ZXcgY29kZSB3YW50cyB0byB1c2UgeHZtYWxsb2MoKSBldCBhbC4NCg0KT2theS4NCg0KPiAN
Cj4+IC0tLSBhL3hlbi9jb21tb24vZXZlbnRfY2hhbm5lbC5jDQo+PiArKysgYi94ZW4vY29t
bW9uL2V2ZW50X2NoYW5uZWwuYw0KPj4gQEAgLTQ4NSwyMCArNDg1LDI3IEBAIGludCBldnRj
aG5fYmluZF92aXJxKGV2dGNobl9iaW5kX3ZpcnFfdCAqYmluZCwgZXZ0Y2huX3BvcnRfdCBw
b3J0KQ0KPj4gICAgICAgaWYgKCAodiA9IGRvbWFpbl92Y3B1KGQsIHZjcHUpKSA9PSBOVUxM
ICkNCj4+ICAgICAgICAgICByZXR1cm4gLUVOT0VOVDsNCj4+ICAgDQo+PiArICAgIGlmICgg
dmlycSA9PSBWSVJRX0RPTV9FWEMgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICByYyA9IGRv
bWFpbl9pbml0X3N0YXRlcygpOw0KPj4gKyAgICAgICAgaWYgKCByYyApDQo+PiArICAgICAg
ICAgICAgZ290byBvdXQ7DQo+PiArICAgIH0NCj4+ICsNCj4+ICAgICAgIHdyaXRlX2xvY2so
JmQtPmV2ZW50X2xvY2spOw0KPj4gICANCj4+ICAgICAgIGlmICggcmVhZF9hdG9taWMoJnYt
PnZpcnFfdG9fZXZ0Y2huW3ZpcnFdKSApDQo+PiAgICAgICB7DQo+PiAgICAgICAgICAgcmMg
PSAtRUVYSVNUOw0KPj4gICAgICAgICAgIGdkcHJpbnRrKFhFTkxPR19XQVJOSU5HLCAiRVZU
Q0hOT1AgZmFpbHVyZTogZXJyb3IgJWRcbiIsIHJjKTsNCj4+IC0gICAgICAgIGdvdG8gb3V0
Ow0KPj4gKyAgICAgICAgZ290byB1bmxvY2s7DQo+PiAgICAgICB9DQo+PiAgIA0KPj4gICAg
ICAgcG9ydCA9IHJjID0gZXZ0Y2huX2dldF9wb3J0KGQsIHBvcnQpOw0KPj4gICAgICAgaWYg
KCByYyA8IDAgKQ0KPj4gICAgICAgew0KPj4gICAgICAgICAgIGdkcHJpbnRrKFhFTkxPR19X
QVJOSU5HLCAiRVZUQ0hOT1AgZmFpbHVyZTogZXJyb3IgJWRcbiIsIHJjKTsNCj4+IC0gICAg
ICAgIGdvdG8gb3V0Ow0KPj4gKyAgICAgICAgZ290byB1bmxvY2s7DQo+PiAgICAgICB9DQo+
PiAgIA0KPj4gICAgICAgcmMgPSAwOw0KPj4gQEAgLTUyNCw5ICs1MzEsMTMgQEAgaW50IGV2
dGNobl9iaW5kX3ZpcnEoZXZ0Y2huX2JpbmRfdmlycV90ICpiaW5kLCBldnRjaG5fcG9ydF90
IHBvcnQpDQo+PiAgICAgICAgKi8NCj4+ICAgICAgIHdyaXRlX2F0b21pYygmdi0+dmlycV90
b19ldnRjaG5bdmlycV0sIHBvcnQpOw0KPj4gICANCj4+IC0gb3V0Og0KPj4gKyB1bmxvY2s6
DQo+PiAgICAgICB3cml0ZV91bmxvY2soJmQtPmV2ZW50X2xvY2spOw0KPj4gICANCj4+ICsg
b3V0Og0KPj4gKyAgICBpZiAoIHJjICkNCj4+ICsgICAgICAgIGRvbWFpbl9kZWluaXRfc3Rh
dGVzKCk7DQo+PiArDQo+PiAgICAgICByZXR1cm4gcmM7DQo+PiAgIH0NCj4gDQo+IFJlbmFt
aW5nIHRoZSBwcmlvciBsYWJlbCAoYW5kIGhlbmNlIG5lZWRpbmcgdG8gZmlkZGxlIHdpdGgg
ZXhpc3RpbmcgZ290by1zKQ0KPiBmZWVscyBhIGxpdHRsZSBmcmFnaWxlLiBIb3cgYWJvdXQg
a2VlcGluZyAib3V0IiBhcyBpcyBhbmQgaW50cm9kdWNpbmcgImRlaW5pdCINCj4gb3Igc29t
ZSBzdWNoPw0KDQpGaW5lIHdpdGggbWUuDQoNCg0KSnVlcmdlbg0K
--------------gmp0ElYS7QfKzpkZI0JhRfu3
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-----

--------------gmp0ElYS7QfKzpkZI0JhRfu3--

--------------0TDIASmdRJDVbbLIpHdE0lhE--

--------------LyMN4q0w2NWt80ISQEnQ4BY7
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/Ey8FAmdYYd0FAwAAAAAACgkQsN6d1ii/Ey8O
Jgf+Ls6KGXP/x+wv+chOgsbEmSoTyChIoNbHXg+cFs8FAPweZhL8LKuKmR0p5TTjaBewGeP8e4ID
vHCs3npLg+5aLs/8thgiozYMhFFtS4y1PrgM4qgO/Yo+NEkUAXJilY8MV+FOyTA0nJCiv+BA9VMe
rURYenU+ib//n+jxWh65hhbu9EX7fWytQvF/5rznAfGFrH7SiKmPDXKN4A7gYEZcs91NzJzC94/O
NER1Zus/oo+U0m62UFvxUQN5+942uTkpkEz3Qubi10RMoGTBxPb7NbsbElt33V42ri5Jm6YeW/iB
y1xE/WlH0SB9+CcVxWhV69OZ0o9cKumUDEamDO4j1Q==
=11aP
-----END PGP SIGNATURE-----

--------------LyMN4q0w2NWt80ISQEnQ4BY7--


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 15:52:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 15:52:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852807.1266497 (Exim 4.92)
	(envelope-from )
	id 1tL2Wu-00017q-4D; Tue, 10 Dec 2024 15:52:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852807.1266497; Tue, 10 Dec 2024 15:52: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 1tL2Wu-000170-13; Tue, 10 Dec 2024 15:52:08 +0000
Received: by outflank-mailman (input) for mailman id 852807;
 Tue, 10 Dec 2024 15:52: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 1tL2Ws-00016u-9f
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 15:52:06 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b427617c-b70e-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 16:52:05 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5d2726c0d45so8784016a12.2
 for ; Tue, 10 Dec 2024 07:52:05 -0800 (PST)
Received: from ?IPV6:2003:e5:8701:7700:f2d:e3aa:8e9e:99bf?
 (p200300e5870177000f2de3aa8e9e99bf.dip0.t-ipconnect.de.
 [2003:e5:8701:7700:f2d:e3aa:8e9e:99bf])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa6260e2c3csm861105866b.182.2024.12.10.07.52.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 07:52: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: b427617c-b70e-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733845925; x=1734450725; 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=E9W9UjaUHTHPDhOTQbrcnxr4xWiDnouU048thPKHzB4=;
        b=VAyFzosBex0X2K9ZQzedgxok/k4Ric/eIflwsY1UqSzh1bPRXDpV0kc17sJZo4oOOD
         gsmhdX2FDqblGseY59Q9OZx3/iLqMysWJqj5CfLsAbeCzxFPVAodKlPjPIudeac2ewlV
         yM42SJmWWAcyVrOT1xdgx8pMJkWO2zC1KbnzU6ZeDhKxIA2WuBBpbrR9tN10Wklmuans
         0yXmW9GKYfuuFLiIhelm8MEeO0uka/ZaVdx8i4d7bmj+gbWTt6xVNMcZ9KhwhVqUtgYl
         LwVi4spHkKbOlBor/bNhDf3Al2gqZkS2TAFuc59HYWoqpjifF9Indw+OAKp1AkoFqKaW
         Ni+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733845925; x=1734450725;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=E9W9UjaUHTHPDhOTQbrcnxr4xWiDnouU048thPKHzB4=;
        b=KXOwudHc/6KMKbpugMXPKFOG6v4+H9gnBFSD02rVEdCmmIC5+fJC1SH8L60oGVzTCF
         nffYNSHdkOW4uBzMMJJ7c0SHD5j7xuAroMf7vcxv/2E6REaY98hIiuEOGg24nssTihzG
         Dm7fhGDhySbIEVihhGjx1WuN7e4rt2juO43YMmZBvPcOSgrMa6TwE6mzEyzUvVlzkX7Z
         hplvvzCLbXUd/TYWaVHaYVcepnGBzEOHMhdfzGD9ZpmaspcvnuRqqAabVL9+r/AXK6ZR
         EjQi/rB9YPqSt607UBIZX4TQVLZJLc4jRIBLHqwzL5JTpk/j52M6Tfp9tGARUNdmWaWY
         mmbQ==
X-Forwarded-Encrypted: i=1; AJvYcCWEVBOjMvO7ra7OuDHQ7vzVrf6ZoivoKLeLWzbY64LUzzXKd8gh5aZGyBdQKGwTg3yoYdBjbTN7ZGE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxQRvAGAQTX3RPAiglBoXRm6/AyWp5ws0NtJjRpCq9iT2CRUJy2
	x3hVEWgmPXZGaQoYCbY2g53QmMsoI+7jVj8dtT9zEwJB+uutMH6G/iICzkoQKVI=
X-Gm-Gg: ASbGncuTZ+t0FqeCmjBdhyt3TASaPT+HLy8r2hbTPDvPH/bi1kd9ckdONZBRpQSiGqj
	NbpvKIv33hCwlrvvyogQWwZGNWmWYYeBKURlSK8owh9T53y8oY1YBLkq3ZMLhql+aAZ16Ilx6mm
	im/BB7HPzZm6FrjFC5iJNyyNg9303dcxvpVjoVdEU4myEmK08XtFLrmFO29vbOMXJIJ9Z9Jyk3I
	vevjA66bxzv+Z2S/MBsTlA4ulE/lPE4ZqYF+3bDnTDnxnMNLxIHUSbiO0RqQ5JYMMNoSn5/ks+X
	q4jjU5pLWW5v9nc8VzuWVpSMND4+LRq8ICkNJUE1+YmeboUVi4hzOzypudFM6ehQp5G8gRRgZZ6
	j
X-Google-Smtp-Source: AGHT+IHlAQsDFneSYZ9EANLPOKRjq8aXRXDlIY5vfZuNEuKGa1z7h5bR2dH9eQzJsXOz7mEfGov9bQ==
X-Received: by 2002:a17:907:7708:b0:aa6:79fa:b475 with SMTP id a640c23a62f3a-aa69cd5b3e7mr489602766b.25.1733845924689;
        Tue, 10 Dec 2024 07:52:04 -0800 (PST)
Message-ID: <30304914-f0c5-4053-ae23-890fa5b8a0c2@suse.com>
Date: Tue, 10 Dec 2024 16:52:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/7] xen: add new domctl get_changed_domain
To: Jan Beulich 
Cc: "Daniel P. Smith" ,
 Anthony PERARD ,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241206130221.17773-1-jgross@suse.com>
 <20241206130221.17773-6-jgross@suse.com>
 <69e08251-c227-42a5-a2e4-a4eb7d63961d@suse.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: <69e08251-c227-42a5-a2e4-a4eb7d63961d@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------NgzSoGpeRPNOUr4RUIEap0FU"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------NgzSoGpeRPNOUr4RUIEap0FU
Content-Type: multipart/mixed; boundary="------------WseeoFvbjq7j9Mgw9dxk1Ol0";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jan Beulich 
Cc: "Daniel P. Smith" ,
 Anthony PERARD ,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
Message-ID: <30304914-f0c5-4053-ae23-890fa5b8a0c2@suse.com>
Subject: Re: [PATCH v2 5/7] xen: add new domctl get_changed_domain
References: <20241206130221.17773-1-jgross@suse.com>
 <20241206130221.17773-6-jgross@suse.com>
 <69e08251-c227-42a5-a2e4-a4eb7d63961d@suse.com>
In-Reply-To: <69e08251-c227-42a5-a2e4-a4eb7d63961d@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------WseeoFvbjq7j9Mgw9dxk1Ol0
Content-Type: multipart/mixed; boundary="------------t068PHNO1099a9u0RTSL3SfF"

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

T24gMDkuMTIuMjQgMTg6MDQsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAwNi4xMi4yMDI0
IDE0OjAyLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gLS0tIGEveGVuL2NvbW1vbi9kb21h
aW4uYw0KPj4gKysrIGIveGVuL2NvbW1vbi9kb21haW4uYw0KPj4gQEAgLTE5Miw2ICsxOTIs
NTQgQEAgc3RhdGljIHZvaWQgZG9tYWluX2NoYW5nZWRfc3RhdGUoY29uc3Qgc3RydWN0IGRv
bWFpbiAqZCkNCj4+ICAgICAgIHNwaW5fdW5sb2NrKCZkb21fc3RhdGVfY2hhbmdlZF9sb2Nr
KTsNCj4+ICAgfQ0KPj4gICANCj4+ICtzdGF0aWMgdm9pZCBzZXRfZG9tYWluX3N0YXRlX2lu
Zm8oc3RydWN0IHhlbl9kb21jdGxfZ2V0X2RvbWFpbl9zdGF0ZSAqaW5mbywNCj4+ICsgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qgc3RydWN0IGRvbWFpbiAqZCkN
Cj4+ICt7DQo+PiArICAgIGluZm8tPnN0YXRlID0gWEVOX0RPTUNUTF9HRVRET01TVEFURV9T
VEFURV9FWElTVDsNCj4+ICsgICAgaWYgKCBkLT5pc19zaHV0X2Rvd24gKQ0KPj4gKyAgICAg
ICAgaW5mby0+c3RhdGUgfD0gWEVOX0RPTUNUTF9HRVRET01TVEFURV9TVEFURV9TSFVURE9X
TjsNCj4+ICsgICAgaWYgKCBkLT5pc19keWluZyA9PSBET01EWUlOR19kZWFkICkNCj4+ICsg
ICAgICAgIGluZm8tPnN0YXRlIHw9IFhFTl9ET01DVExfR0VURE9NU1RBVEVfU1RBVEVfRFlJ
Tkc7DQo+IA0KPiBUaGUgcHVibGljIGNvbnN0YW50IHNheWluZyAiZHlpbmciIGlzbid0IHF1
aXRlIGluIGxpbmUgd2l0aCB0aGUgaW50ZXJuYWwNCj4gY29uc3RhbnQgc2F5aW5nICJkZWFk
Ii4gSXQgbWF5IHdlbGwgYmUgdGhhdCBYZW5zdG9yZSBvbmx5IGNhcmVzIGFib3V0IHRoZQ0K
PiAiZGVhZCIgc3RhdGUsIGJ1dCB0aGVuIGl0IHdvdWxkIGJldHRlciBiZSBuZW1hZWQgdGhp
cyB3YXkgYWxzbyBpbiB0aGUNCj4gcHVibGljIGludGVyZmFjZSwgSSB0aGluay4NCg0KT2th
eSwgSSdsbCByZW5hbWUgaXQgdG8gIlhFTl9ET01DVExfR0VURE9NU1RBVEVfU1RBVEVfREVB
RCIuDQoNCj4gDQo+PiArICAgIGluZm8tPnVuaXF1ZV9pZCA9IGQtPnVuaXF1ZV9pZDsNCj4+
ICt9DQo+PiArDQo+PiAraW50IGdldF9kb21haW5fc3RhdGUoc3RydWN0IHhlbl9kb21jdGxf
Z2V0X2RvbWFpbl9zdGF0ZSAqaW5mbywgc3RydWN0IGRvbWFpbiAqZCwNCj4+ICsgICAgICAg
ICAgICAgICAgICAgICBkb21pZF90ICpkb21pZCkNCj4+ICt7DQo+PiArICAgIHVuc2lnbmVk
IGludCBkb207DQo+PiArDQo+PiArICAgIG1lbXNldChpbmZvLCAwLCBzaXplb2YoKmluZm8p
KTsNCj4+ICsNCj4+ICsgICAgaWYgKCBkICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgc2V0
X2RvbWFpbl9zdGF0ZV9pbmZvKGluZm8sIGQpOw0KPj4gKw0KPj4gKyAgICAgICAgcmV0dXJu
IDA7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgd2hpbGUgKCAoZG9tID0gZmluZF9maXJz
dF9iaXQoZG9tX3N0YXRlX2NoYW5nZWQsIERPTUlEX01BU0sgKyAxKSkgPA0KPiANCj4gSSBj
YW4ndCBzcG90IGFueSBjaGVjayB0aGF0IGRvbV9zdGF0ZV9jaGFuZ2VkIHdhcyBhY3R1YWxs
eSBhbGxvY2F0ZWQuIEFsc28sDQo+IHVubGlrZSB0aGUgcHVibGljIGhlYWRlciBjb21tZW50
cyBzYXlzLCB0aGUgbmV3IHN1Yi1vcCBsb29rcyB0byBiZSB1c2FibGUNCj4gYnkgX2FueW9u
ZV8gKGVsaWdpYmxlIHByaXZpbGVnZS13aXNlKSBhcyBsb25nIGFzIF9zb21lb25lXyBkaWQg
c2V0IHVwIHRoZQ0KPiB2SVJRLiBUaGVyZSBsb29rcyB0byBldmVuIGJlIGEgcmFjZSBwb3Nz
aWJsZSB3aGVuIGEgIndyb25nIiBjYWxsZXIgdHJpZXMgdG8NCj4gY2FsbCB0aGlzIGF0IGp1
dCB0aGUgInJpZ2h0IiB0aW1lLg0KDQpSaWdodCwgSSdsbCBhZGQgYSBjaGVjayB0aGF0IHRo
ZSBjYWxsaW5nIGRvbWFpbiBpcyByZWdpc3RlcmVkIGZvciB0aGUNCnZJUlEuIEFkZGl0aW9u
YWxseSBJJ2xsIHB1dCBpbiBhbiAiQVNTRVJUKGRvbV9zdGF0ZV9jaGFuZ2VkKTsiLg0KDQo+
IA0KPj4gLS0tIGEveGVuL2NvbW1vbi9kb21jdGwuYw0KPj4gKysrIGIveGVuL2NvbW1vbi9k
b21jdGwuYw0KPj4gQEAgLTI3OCw2ICsyNzgsMTEgQEAgc3RhdGljIHN0cnVjdCB2bnVtYV9p
bmZvICp2bnVtYV9pbml0KGNvbnN0IHN0cnVjdCB4ZW5fZG9tY3RsX3ZudW1hICp1aW5mbywN
Cj4+ICAgICAgIHJldHVybiBFUlJfUFRSKHJldCk7DQo+PiAgIH0NCj4+ICAgDQo+PiArc3Rh
dGljIGJvb2wgaXNfc3RhYmxlX2RvbWN0bCh1aW50MzJfdCBjbWQpDQo+PiArew0KPj4gKyAg
ICByZXR1cm4gY21kID09IFhFTl9ET01DVExfZ2V0X2RvbWFpbl9zdGF0ZTsNCj4+ICt9DQo+
IA0KPiBMaWtlbHkgYmV0dGVyIGFzIHN3aXRjaCgpIGZyb20gdGhlIHZlcnkgYmVnaW5uaW5n
Lg0KPiANCj4+IEBAIC04NjYsNiArODczLDE1IEBAIGxvbmcgZG9fZG9tY3RsKFhFTl9HVUVT
VF9IQU5ETEVfUEFSQU0oeGVuX2RvbWN0bF90KSB1X2RvbWN0bCkNCj4+ICAgICAgICAgICAg
ICAgICAgIF9fSFlQRVJWSVNPUl9kb21jdGwsICJoIiwgdV9kb21jdGwpOw0KPj4gICAgICAg
ICAgIGJyZWFrOw0KPj4gICANCj4+ICsgICAgY2FzZSBYRU5fRE9NQ1RMX2dldF9kb21haW5f
c3RhdGU6DQo+PiArICAgICAgICByZXQgPSB4c21fZ2V0X2RvbWFpbl9zdGF0ZShYU01fWFNf
UFJJViwgZCk7DQo+PiArICAgICAgICBpZiAoIHJldCApDQo+PiArICAgICAgICAgICAgYnJl
YWs7DQo+PiArDQo+PiArICAgICAgICBjb3B5YmFjayA9IDE7DQo+PiArICAgICAgICByZXQg
PSBnZXRfZG9tYWluX3N0YXRlKCZvcC0+dS5nZXRfZG9tYWluX3N0YXRlLCBkLCAmb3AtPmRv
bWFpbik7DQo+PiArICAgICAgICBicmVhazsNCj4gDQo+IEVzcGVjaWFsbHkgd2l0aCB0aGlz
IGJlaW5nIGEgc3RhYmxlIGludGVyZmFjZSwgc3VyZWx5IHRoZSB0d28gcGFkZGluZyBmaWVs
ZHMNCj4gd2FudCBjaGVja2luZyB0byBiZSB6ZXJvIG9uIGlucHV0ICh0byBwb3NzaWJseSBh
bGxvdyB0aGVpciBmdXR1cmUgdXNlIGZvcg0KPiBzb21ldGhpbmcgaW5wdXQtaXNoKS4gVGhl
biBldmVuIHRoZSBtZW1zZXQoKSBpbiB0aGUgZnVuY3Rpb24gbWF5IG5vdCByZWFsbHkNCj4g
YmUgbmVlZGVkLg0KDQpJJ2xsIGFkZCB0aGUgY2hlY2suIFJlbW92aW5nIHRoZSBtZW1zZXQo
KSBpcyBhIGxpdHRsZSBiaXQgZG91YnRmdWwsIGFzIHRoaXMNCm1pZ2h0IHJlc3VsdCBpbiBs
ZWFraW5nIGh5cGVydmlzb3IgZGF0YSBlLmcuIGluIGNhc2UgYSBkb21haW4gaXNuJ3QgZXhp
c3RpbmcNCih0aGlzIHdpbGwgY29weSB0aGUgaW50ZXJuYWwgc3RydWN0IHRvIHRoZSB1c2Vy
IGV2ZW4gaW4gdGhlIC1FTk9FTlQgY2FzZSkuDQoNCg0KSnVlcmdlbg0K
--------------t068PHNO1099a9u0RTSL3SfF
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-----

--------------t068PHNO1099a9u0RTSL3SfF--

--------------WseeoFvbjq7j9Mgw9dxk1Ol0--

--------------NgzSoGpeRPNOUr4RUIEap0FU
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/Ey8FAmdYY6MFAwAAAAAACgkQsN6d1ii/Ey9X
QQf/X7B+uWzWXCtIq+yztH0nJ/GyeJ0AMZe89LNAFJx8sOxJaDMedYJ51+UjczY8DjRVhi141jEg
qP2dlEsrvnHuVDu5/ZceSJES0MOnAIYxeZ4OTq40t+PPLWZkZ4t7A7oJp3F0rreOb8EvEzly9kzS
lvJu8vPn7Vh7Vrgdws93y9qNtgo6RVAkJH2OqFv9W5zNbR+8yMiFv7p0bgdyUNkiA5ltOOlCLvMC
a50kEA/WBM54xlCduGAduFQ+egBfuIrmlikKvAoqt7HKRXDG1Uniftnw2/iRqMPj17J9NrREkEMB
Z/z0YoWd8BkyFd46ZUxZgtwvGmw64a9WWGXJm3gOBQ==
=mHbd
-----END PGP SIGNATURE-----

--------------NgzSoGpeRPNOUr4RUIEap0FU--


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 16:14:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 16:14:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852829.1266508 (Exim 4.92)
	(envelope-from )
	id 1tL2sP-00057C-Tx; Tue, 10 Dec 2024 16:14:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852829.1266508; Tue, 10 Dec 2024 16:14: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 1tL2sP-000575-QF; Tue, 10 Dec 2024 16:14:21 +0000
Received: by outflank-mailman (input) for mailman id 852829;
 Tue, 10 Dec 2024 16:14: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 1tL2sO-00056z-Ts
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 16:14:20 +0000
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com
 [2a00:1450:4864:20::42d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cf0942b1-b711-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 17:14:18 +0100 (CET)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-385ed7f6605so2590700f8f.3
 for ; Tue, 10 Dec 2024 08:14: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
 d9443c01a7336-216659c88f0sm26581595ad.102.2024.12.10.08.14.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 08:14: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: cf0942b1-b711-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733847258; x=1734452058; 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=R7G0DwzfFV7vHIhYjMaoAW2txuQp0kwPai3yGt9U9oE=;
        b=dRaXiIZLmnRDaAg7u+cNIW1Ua366jDHjuPzHlXyZeJDDP0QGhdSxUWVkpyOhZZFakf
         xmD7qPwlkQaVyY5vBqKogm1M6E6KFBX8jSjGO1qLd5l9RdjZgLNGhwQB0fqMFW9Rlqew
         QDFDzCqZjz8ycntXvelFUd+R15FYI+r+IJ8gIL6z2u1dArFxZ/+oPZqhsUHsp+WbMkAU
         mLNyLlqj+JtAz0QOLU9w+Zx0PCQpca1Px1we2SVuRyH7pd96bsqGz5RvExMzs3NeYKMD
         AbT0HUucYEiuNLqNX1Le+YuagH65MIXDAs2jxzx+TMOV5PqPJrCDZmuCHp3q5cT6w3zY
         wpKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733847258; x=1734452058;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=R7G0DwzfFV7vHIhYjMaoAW2txuQp0kwPai3yGt9U9oE=;
        b=tGzZyDJq8iQri0ElkISAQFU/Ss0esG83GF3DneymBLKQi1GD47c31KN07oPEdOvQH4
         wA1fJEZqmL6OT0bTU4YghZOBJTDQhJE/CD9JSGXhamk/RvM/nIu58uyMqzSbKDXjLjgt
         U90h0zc6raBkO7O/KrZabB2YaU5AsVjUiYtDsUMihJB3zd+uSgy2fuC870XwWdAngsxs
         /+PdYzGvX3JCJT5Yg3IsOpqzY1eK/AdTnVD/JuF/NySDrD59DAovwcQxpWavqDisB8Ct
         f15XzXUGiz06WZZq9DIZIkhzirVWPrEOoRtzg10IuiCmmYhO7JhKl++ESjGAyL4xG9ip
         2xrg==
X-Forwarded-Encrypted: i=1; AJvYcCW3Ln/8Fsd5PyayPb8Vk0XOQ6EQvERqKTrG0gNIVQ9JklChKFwdJ0F8nW54uMfcTE1QY4ogIpCJX+c=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzQTjBZU4U7FfZNkK5zDD8UojIAgptyiT2Xd6u9CQNc6lo6LykR
	S+38rZV1wN6RdJzUPdRWm9MpRzQGX1KgMSF8XcdH44FCXzTdUehbrUWO2nN07g==
X-Gm-Gg: ASbGncu1FOZWs6RjEjsrN/slnm4suQOVOn30dNvLRSbYdW6ijj6ZFsKW6Ezxl98SRgU
	0bpSQFxIDzoGJYnIbr91BLaiJLhZr0YoLyu6j6aV4iMYPqhxNMqwwcEYtE6Z6vDtpsr7QIn+5ny
	g4fRYCJ52Es6y8ZD+51mltYMgtFMPFzyPdzPX1H6yuh4J/kUZEgmqeFbSGmhsn8nnrvFOIFDAW8
	1fKo7U0/XZnxiPBxC3qQrpLpEXVSBrx5t3e/WWFTzyTES/D/9o1pIZAuT8oEFbcbTcVrAjmOLkO
	byCZ11ndIXOnhLK0PaQxuNNAWjpFhlBs9K3uEpE=
X-Google-Smtp-Source: AGHT+IFMMhvo0UXLG0ZiYTVBKNlBFOzu4+8/IBE86EGz3HCuSm5dH5klDBPBkDrPOnjQcEnuE1BWiA==
X-Received: by 2002:a05:6000:144c:b0:385:e5d8:3ef1 with SMTP id ffacd0b85a97d-386453f9e06mr4157831f8f.44.1733847258273;
        Tue, 10 Dec 2024 08:14:18 -0800 (PST)
Message-ID: <6b15ccd8-9525-4a85-9fde-bb53ee34761a@suse.com>
Date: Tue, 10 Dec 2024 17:14:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/FPU: make vcpu_reset_fpu() build again with old gcc
To: Alejandro Vallejo 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" 
References: 
 
 <4e9c0566-bed7-47a6-aa6d-2ac76c0a1bfe@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 10.12.2024 16:12, Alejandro Vallejo wrote:
> On Tue Dec 10, 2024 at 2:34 PM GMT, Jan Beulich wrote:
>> On 10.12.2024 15:25, Alejandro Vallejo wrote:
>>> On Mon Dec 9, 2024 at 3:13 PM GMT, Jan Beulich wrote:
>>>> Fields of anonymous structs/unions may not be part of an initializer for
>>>> rather old gcc.
>>>
>>> Can you add the specific version for tracking purposes?
>>
>> It's all the same as before, and I really didn't want to waste time on
>> once again figuring out which exact version it was that the behavior
>> changed to the better.
> 
> Just checked on Godbolt. 4.7.1 works and 4.6.4 doesn't. Adding that data point
> to the commit message really helps when navigating git-blame, even if it's not
> as precise as it could be. Particularly if one wants to understand exactly
> which quirk of which version of which compiler is being dealt with.

Well, thanks for sorting that out. I've added that info.

> With the commit message adjusted with the offending GCC version (i.e: <4.7.1):
> 
>   Acked-by: Alejandro Vallejo 

Thanks here as well. Any chance though you would be willing to upgrade that
to R-b? Only that would allow me to put in the patch without waiting for yet
another tag.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 16:21:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 16:21:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852844.1266517 (Exim 4.92)
	(envelope-from )
	id 1tL2yo-0006mM-HA; Tue, 10 Dec 2024 16:20:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852844.1266517; Tue, 10 Dec 2024 16:20: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 1tL2yo-0006mF-EC; Tue, 10 Dec 2024 16:20:58 +0000
Received: by outflank-mailman (input) for mailman id 852844;
 Tue, 10 Dec 2024 16:20: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 1tL2yn-0006gz-FE
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 16:20:57 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bb825052-b712-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 17:20:55 +0100 (CET)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-38632b8ae71so2639528f8f.0
 for ; Tue, 10 Dec 2024 08:20:55 -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
 41be03b00d2f7-7fdde228459sm1697539a12.40.2024.12.10.08.20.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 08:20: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: bb825052-b712-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733847655; x=1734452455; 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=TJWHtqg7dHTZgr9KAeu3wq9Ix5+1j1Kkx+wn30IbGEI=;
        b=Sbjvndk952xkVpWAACNbrdRQzf1Wo5iv0HxNrjR494JKmJNhNMCHXKLIcFbgkIEktq
         W726sbFQFrVkSIanuFP17Epafxlo2iQF3Y62fUxbCNY72bmTX/z5YwdtmedIMXpJa1xD
         GaFo2FPfuO+tPRLXgNQQD3n5LIlEcMtHZGSLf0XyX1xIENHqk95Q/pbfXCbgokgyX/dZ
         YwJVh8Tnnv6M4bEakj95uQ/X3x3w/U3XH216sO9P2WM4aDR+a9zrN4VR9jdQnNZ/ICS8
         7S5cJA/j7jzpCbV1UaAW7mZdeD0X00wxiiGdzrPmV6SHqxTOe3QDA5KVc4taafTOliAs
         MPZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733847655; x=1734452455;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=TJWHtqg7dHTZgr9KAeu3wq9Ix5+1j1Kkx+wn30IbGEI=;
        b=DCs5x9OrAGHLphSR7kpMstqj2KmE1c34J2i5NBjQP7DLx5IgZzmW14kipRfjI2WECd
         g2omaP+Y+TiCoJ8mLZasLcG2A7dtLSj/jVoT+06j2pxQUj2o5Ddz6t8eufSmby6nK8I7
         KBojUF/fWYWqL3vnWI++yQz3F2bpYu30DA4EVrl+wuM3SOcbLPx9YFB3wjDobOfXqj+s
         4MYpreWpx0jObqhN9OF/keyFXoOmvZhTtocaByaDUd5bahyCTlWj5bT3PZV3yHRkrcJP
         17K45dTdoiaVsV+ZSDU6Z8ZTax8xqmukrj6k0OuXooq75LKxqhoeZ7FWSaNa3MeYRbO2
         YD9w==
X-Forwarded-Encrypted: i=1; AJvYcCUnNCPIYAwgU9dL6uXK0s+00eZtMBnwPEbl/VdylZbQfB+ZhRrmqM7wCbXTdpg/QFl9VW3XtOgFtC8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzTtzUy96h12MTvmH7Eom7Hmqo2rVa7z3zDohS6g3FkP4ZDSs72
	AKej+4LeULswAJfAs2GycQchjVL0axlJhodgoWl7kdbs67xtIvyQeBgk8zEPiQ==
X-Gm-Gg: ASbGncvgt7aA2NripKCxL025kvJSt1XQIyjZu6G1vFG+lcp+3ywOK9OUVaQtpbMZ92+
	U52Q4yL6QWBGuRfvzrKf3Xvamqo6YbBFEG1Y1cstDXTP+Qcj+mGo+8686bzxkGMyZEaPk22dY/l
	X9mFU/FXKxAWvtxmxgQVaH52+mxN5hCoCcsNaKo9o5giApdXYENvVqfTR9nlV6T1DORzKi6Ew3Y
	+DNkUVwsDnXbQtDQToXdDQnZU5iTDuD6aPW2LlGBybkKbNtmDjdIj3lZ/lqDPkxSzVSJ0cnN0GG
	jpeKKVNG7mI52gGMBwSnKVAzrgmagFNCXyZfIus=
X-Google-Smtp-Source: AGHT+IGCL0ALXcGOZeBsCP4hpuiIT0N4jx5LCt6lX2ugg3Bowoj8gV/kD6liD4gBac3OaOMwjUY1dA==
X-Received: by 2002:a05:6000:18a5:b0:385:f6b9:e762 with SMTP id ffacd0b85a97d-386453fbc6emr4049678f8f.36.1733847655043;
        Tue, 10 Dec 2024 08:20:55 -0800 (PST)
Message-ID: <929d657d-ffe8-4243-ba01-fffa20b26205@suse.com>
Date: Tue, 10 Dec 2024 17:20:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 5/6] xen/riscv: implement relocate_fdt()
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: 
 
 
 <4dd6a2e9-d2b9-4402-907b-b9314d2346f7@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: <4dd6a2e9-d2b9-4402-907b-b9314d2346f7@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.12.2024 16:20, Oleksii Kurochko wrote:
> On 12/9/24 4:00 PM, Jan Beulich wrote:
>> On 27.11.2024 13:50, Oleksii Kurochko wrote:
>>> relocate_fdt() relocates FDT to Xen heap instead of using early mapping
>>> as it is expected that discard_initial_modules() ( is supposed to call
>>> in the future ) discards the FDT boot module and remove_early_mappings()
>>> destroys the early mapping.
>>>
>>> To implement that the following things are introduced as they are called
>>> by internals of xmalloc_bytes() which is used in relocate_fdt():
>>> 1. As RISC-V may have non-coherent access for RAM ( f.e., in case
>>>     of non-coherent IO devices ) flush_page_to_ram() is implemented
>>>     to ensure that cache and RAM are consistent for such platforms.
>> This is a detail of the page allocator, yes. It can then be viewed as also
>> a detail of xmalloc() et al, but I consider the wording a little misleading.
>>
>>> 2. copy_from_paddr() to copy FDT from a physical address to allocated
>>>     by xmalloc_bytes() in Xen heap.
>> This doesn't look to be related to the internals of xmalloc() et al.
>>
>>> 3. virt_to_page() to convert virtual address to page. Also introduce
>>>     directmap_virt_end to check that VA argument of virt_to_page() is
>>>     inside directmap region.
>> This is a need of free_xenheap_pages(), yes; see remark on point 1.
> 
> Actually I faced the usage of virt_to_page() in xmalloc_whole_page():
> ```
>    static void *xmalloc_whole_pages(unsigned long size, unsigned long align)
>    {
>      ...
>      PFN_ORDER(virt_to_page(res)) = PFN_UP(size);
>      /* Check that there was no truncation: */
>      ASSERT(PFN_ORDER(virt_to_page(res)) == PFN_UP(size));
> 
>      return res;
>    }
> ```
> which is called from xmalloc().
> 
> Do we need a second paragraph of the commit message at all? Or it is just obvious if
> flush_page_to_ram(), virt_to_page() and copy_from_paddr() are introduces that they are needed for
> relocate_fdt()?
> 
> Or perhaps rephrasing in the following way would be enough?
> ```
> For internal use of|xmalloc|, the functions|flush_page_to_ram()| and|virt_to_page()| are introduced.
> |virt_to_page()| is also required for|free_xenheap_pages()|. These additions are used to support
> |xmalloc|, which is utilized within|relocate_fdt()|. Additionally,|copy_from_paddr()| is introduced
> for use in|relocate_fdt()|.
> ```

I think that would do.

>> Also recall my comment on one of your earlier series, regarding inclusive
>> vs exclusive ranges. Can that please be sorted properly as a prereq, to
>> avoid extending the inconsistency?
> 
> Yes, I remember that and at the moment everything ( DIRECTMAP_VIRT_END, FRAMETABLE_VIRT_END )
> is following "inclusive" way. Considering that you remind me that could you please tell me more time
> what I am missing?

First the table azt the top of config.h uses all exclusive upper bounds.
And then DIRECTMAP_SIZE's definition assumes DIRECTMAP_SLOT_END would be
exclusive, when it's inclusive.

>>> +        set_fixmap(FIX_MISC, maddr_to_mfn(paddr), PAGE_HYPERVISOR_RW);
>>> +        memcpy(dst, src + s, l);
>>> +        clean_dcache_va_range(dst, l);
>> Why is this necessary here? You're copying to plain RAM that Xen alone
>> is using.
> 
> It is Arm specific:
> ```
> commit c60209d77e2c02de110ca0fdaa2582ef4e53d8fd
> Author: Stefano Stabellini
> Date:   Mon Jan 21 12:40:31 2013 +0000
> 
>      xen/arm: flush dcache after memcpy'ing the kernel image
>      
>      After memcpy'ing the kernel in guest memory we need to flush the dcache
>      to make sure that the data actually reaches the memory before we start
>      executing guest code with caches disabled.
>      
>      copy_from_paddr is the function that does the copy, so add a
>      flush_xen_dcache_va_range there.
> ```
> I wanted to put copy_from_paddr() to some common place at the end but in RISC-V cache is always enabled
> ( I don't see an instruction in the spec for disable/enable cache ) so this issue isn't present for RISC-V
> and clean_dcache_va_range() should/could be dropped.

That plus there's no kernel in sight just yet.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 16:26:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 16:26:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852857.1266528 (Exim 4.92)
	(envelope-from )
	id 1tL33m-0007Ti-2w; Tue, 10 Dec 2024 16:26:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852857.1266528; Tue, 10 Dec 2024 16:26: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 1tL33m-0007Tb-05; Tue, 10 Dec 2024 16:26:06 +0000
Received: by outflank-mailman (input) for mailman id 852857;
 Tue, 10 Dec 2024 16:26: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 1tL33k-0007TV-Kc
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 16:26:04 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2415::61c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6f2123ec-b713-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 17:25:58 +0100 (CET)
Received: from DM6PR03CA0061.namprd03.prod.outlook.com (2603:10b6:5:100::38)
 by SJ2PR12MB8134.namprd12.prod.outlook.com (2603:10b6:a03:4fa::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.11; Tue, 10 Dec
 2024 16:25:53 +0000
Received: from CY4PEPF0000EE3E.namprd03.prod.outlook.com
 (2603:10b6:5:100:cafe::8e) by DM6PR03CA0061.outlook.office365.com
 (2603:10b6:5:100::38) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.21 via Frontend Transport; Tue,
 10 Dec 2024 16:25:52 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CY4PEPF0000EE3E.mail.protection.outlook.com (10.167.242.16) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8230.7 via Frontend Transport; Tue, 10 Dec 2024 16:25:52 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 10 Dec
 2024 10:25:51 -0600
Received: from ubuntu.mshome.net (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 10 Dec 2024 10:25:50 -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: 6f2123ec-b713-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=dpg8UA8H54lDTM5Kvk8Sp/AVG+uxiWqjIafLNnyQXCrAdaboVNU7hC9+ZZ5yij8ZSOBambIE+mWQhnwJvpPfIUtUVQZKwufPz6273DikiCFNfxoha5yBeLpnEOqh3Gyd7+d1D424ThfPPmcxliy2gO6P851gJrEQaEhqEVgzlgjA4kqfgnlTNv2BDw9KuMYmfgcy1S2CkPIsZyK6ow+r9v8+1YFpcDhNegnTR7N5GX58mYuPn9pY8JFh+gRmJbB4db9r+WpG9IV6S+lzzuGjmh9N8ZowNLH4I3TiDWTUSw97Zoag7+C5S/IU6NjSebHnv7IirO7czjAUJKQ+NRJkPw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kONbcCgZKsO4TiqNQq87LzjeGcYkS85qkaJxmB0oPi0=;
 b=b2QPZFhqg0fFu44c2hn0zXPiXh9uQ8/5bEMKwKygdx1TvjkB7GYRj9Cjakau53vzOcZlLhL8xttIYh6e3TiYx4vWyCBcvVkqyrM/DyPvucTTt7L2L906gt5GWL0FtgmWq6jpIO67vFK6HvSsBf5BCJOk/erzhSyXNsf2IekI21DgbAV6bnI/+wz6s0YMruKxcYDCNpPOML1yW5CYGH4dzuPERXUxMe2EOyzuxFVRZ5oHGWhQs/2ug1vFottsL4E4b/mt6aVN25k8L5kCneGpF75MTkwSRz/LQtQAP8y5NlK686ptuHZLrEwIa34/d2ePCkwOKNpcIyhmSwZZ3y3LJw==
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=kONbcCgZKsO4TiqNQq87LzjeGcYkS85qkaJxmB0oPi0=;
 b=5obwKfiV5CT81J4dxepM94w1TQMWJxCPUweGLht5rzuFkKrsZJ3U1oE2aWxM8Y9beKUdt3za+llfnIydyDx9XubRC47v/WQIszRFdh+8Dqnb6cH374jaWEkthz/E68YX0onsoLYAFs/WPI7A/xlB+VfcOnmnWBogNRtXurzXgxo=
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=SATLEXMB03.amd.com; pr=C
From: Stewart Hildebrand 
To: 
CC: Stewart Hildebrand ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] xen/vpci: fix memory type in guest_mem_bar_read()
Date: Tue, 10 Dec 2024 11:25:44 -0500
Message-ID: <20241210162546.403882-1-stewart.hildebrand@amd.com>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB03.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EE3E:EE_|SJ2PR12MB8134:EE_
X-MS-Office365-Filtering-Correlation-Id: 6f5fcdc2-dd1b-49cb-d6fd-08dd193750ae
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:
	=?us-ascii?Q?W0S1nDz+Nudm3xlEH4rT1yVfPHkTgCiwDREjkJtWga6NhFCPHL83JHlPahJt?=
 =?us-ascii?Q?DIn+bcP7vjcGzPpEi3SWO66ybuKx0sVPrT4fOI58iA89SoR030v/KYbjf8RA?=
 =?us-ascii?Q?x4UneeF6vUQJqxZNQCmLe+5cBCffJBx67UtUVEpV6Nym26ujD7bUqPWLdASn?=
 =?us-ascii?Q?y8r5/Lai2f06sIqaBbPSStk9YB7A7zAgTHJ9vqc5CbAiE0R4MHou1rzey7xf?=
 =?us-ascii?Q?eDAHh2gjiYCBT8EU8npzFtzCk67qiOlSMWo8XxJKoZkwJVD9RcawWQ1Dzdm9?=
 =?us-ascii?Q?ywHCkvYfkgJcAEe+eHH5BaXmJ74EBu7vobLQkglXklKpuY0psULPToVb7Dmj?=
 =?us-ascii?Q?Bp535FiZwhudZqAeXzF0A/hkkPzLWwQmKEpBu2E3I0fBURxgyvUPIsQTZo1i?=
 =?us-ascii?Q?MHSSxhaF5p6Lk6rihXRVRvTAyHtRKt0v5oX4Z5SdyBwNQh1gzxcwGgP2Of4K?=
 =?us-ascii?Q?VnZGN09Ovz1DBPlj5IZTKSgH+2LO1DmmCtoQYltuLlflvzBb566QaaLuFl+G?=
 =?us-ascii?Q?8fUpWjNETLb/L4unzSsRYjJLZBsFx1fiSPIz1i1Jy4bM9V/G91C4hd6hqMmk?=
 =?us-ascii?Q?m3t83LbaxVO7EbexOYQyrdojSGlyzpgUVXVLwd1mYp8v6fLIx/eHeerVRz1y?=
 =?us-ascii?Q?FA/WGKZDul/ZOuY82aFs2JNNAcPUmr8QuF0OcVZjihMBpIwi+/WV4bQPlipa?=
 =?us-ascii?Q?GdZnWvTIdyMkJCyM3SKPtme8fleTH/jbPEtk8Mcm3+yyq9gxJfklcViY4TcF?=
 =?us-ascii?Q?jWPCi8PMa/mXc9pOy1v+q4dNCP2D517QmKDlJ6gFId+YAD6+Ir7btuVLnenZ?=
 =?us-ascii?Q?IJuE/CpNbU2fSwn1zFoofuI1bquIT3GeGfxLgaqEWupFcnpq7/hTVUPJd5e0?=
 =?us-ascii?Q?ntRBuRk+CWmFNINWktMIqf50MryEYALKAflF5+fAZ0GLkKPCbNBK0FUXBnPY?=
 =?us-ascii?Q?SsgXKMCs56E+hfhXzdgX2U4rTkUzwUM+VMTNJbrIRfBUVl2G1jx6XCEb4Mz1?=
 =?us-ascii?Q?xC+oyfmqh/x7SuNzT23IMKco51ZDx3dKCJbWvKmlDumX4najVUrSIAoVqJ09?=
 =?us-ascii?Q?Q3s63j04CjvUQpwao9w5/8y76/o+nglT7kWFn316bCrv5q9ltvt36q49d5Aa?=
 =?us-ascii?Q?GKkp92zd4QQIuu9tKQ0nlui68jEy6NrMFDZV82RZDqbjIf6aM19aYLQS4tYA?=
 =?us-ascii?Q?c1bCvVkFqv75wyXJ5LkMK7XZEnmdChpLm7WOojRygCkEnZMkUg342Vv4IM4P?=
 =?us-ascii?Q?wQcm6qmEiV6HBuOuMgmrABBiujFnl9s5zUm2+fqyAl3EJIabtvMvOPqhrRDY?=
 =?us-ascii?Q?K9eJmaeUTskjq18YluxfIMm7EnscoWoN7ow/LyZOw3Bc6pYrABF7a8sFP6BJ?=
 =?us-ascii?Q?pnKlExYBfI0xTb4O/k/CS7FyKS4yZvW6G5eaHiW4AxJLV4HalNsHlwmkHJqG?=
 =?us-ascii?Q?Xr5Ie28ZYRI5iK5NZyZuFgrV1HwwDYod?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(36860700013)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2024 16:25:52.2290
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6f5fcdc2-dd1b-49cb-d6fd-08dd193750ae
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000EE3E.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8134

Currently, if bar->type is anything other than VPCI_BAR_MEM32, the
memory type bits get set to PCI_BASE_ADDRESS_MEM_TYPE_64 in the returned
value. This leads to the wrong memory type for, e.g. VPCI_BAR_EMPTY.
Only set PCI_BASE_ADDRESS_MEM_TYPE_64 when the bar type is
VPCI_BAR_MEM64_LO.

Fixes: 8c5bca70742c ("vpci/header: implement guest BAR register handlers")
Signed-off-by: Stewart Hildebrand 
---
 xen/drivers/vpci/header.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index ef6c965c081c..493ca5de032d 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -668,8 +668,10 @@ static uint32_t cf_check guest_mem_bar_read(const struct pci_dev *pdev,
     }
 
     reg_val = bar->guest_addr;
-    reg_val |= bar->type == VPCI_BAR_MEM32 ? PCI_BASE_ADDRESS_MEM_TYPE_32 :
-                                             PCI_BASE_ADDRESS_MEM_TYPE_64;
+    if ( bar->type == VPCI_BAR_MEM32 )
+        reg_val |= PCI_BASE_ADDRESS_MEM_TYPE_32;
+    else if ( bar->type == VPCI_BAR_MEM64_LO )
+        reg_val |= PCI_BASE_ADDRESS_MEM_TYPE_64;
     reg_val |= bar->prefetchable ? PCI_BASE_ADDRESS_MEM_PREFETCH : 0;
 
     return reg_val;

base-commit: 1645bb7997cb1eccb45235ab350872733c74b305
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 16:29:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 16:29:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852870.1266538 (Exim 4.92)
	(envelope-from )
	id 1tL36x-00083n-HN; Tue, 10 Dec 2024 16:29:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852870.1266538; Tue, 10 Dec 2024 16:29: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 1tL36x-00083g-Eq; Tue, 10 Dec 2024 16:29:23 +0000
Received: by outflank-mailman (input) for mailman id 852870;
 Tue, 10 Dec 2024 16: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 1tL36v-00083a-OI
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 16:29:21 +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 e89ad5a4-b713-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 17:29:20 +0100 (CET)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-385e27c75f4so4279495f8f.2
 for ; Tue, 10 Dec 2024 08:29:20 -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
 41be03b00d2f7-7fd3891dc95sm5975595a12.42.2024.12.10.08.29.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 08: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: e89ad5a4-b713-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733848160; x=1734452960; 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=5lnSf05nwTVWJKi+tgZCBqtG2UysvUg321LfM1SKTFA=;
        b=FGAOzSy1JtE4L2Yajd709ZsiDrfjSOm5Xt7+eLq27Q5bWruQKH+kjfjzwZlAJxiVUr
         3rNkZ2DimtsK9bBsDdUcTGRccNzfBkwJKDvHzneiBsNgOLCaoCiXTQ6VqpwoEbuwsYcw
         303oyR5OU5fX8GadNihf0LINYmryrB7AQIXxs1Aq9Hdk8Wks+eptBY1/jZ21qizy7Sr8
         zeNadbNm6zm9quZWjyd7JEMNRmz7NMXbSgWdk/CefDmfuCuOgOfgVNlepfIH7ZuDLmP5
         h/BDi46hw+wuJfo+F7UeY6c5qOD3MDl8TwkN1L6i0ymh5uPMxuIRvEyxgBVdPQu8jA+o
         REWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733848160; x=1734452960;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=5lnSf05nwTVWJKi+tgZCBqtG2UysvUg321LfM1SKTFA=;
        b=JanKXyq+vzjeHiljNGNA7uIIqqdcgGZqK1ToLPs+8U+JGdtMYjIs7u+0XuNQkDJiOe
         DCvA/fv/AIlcS5gORYgJ9bgv3lUHNU5jP5FIMtKSS0Bm1ktKZDJyFkwE/soekc9r/2Nx
         zP229pJTW6yno987D+eA4h/DFq8s2dkfCHCsg0mNSdfUBLVERKkIlVyL9G4Dh7jLkYUD
         OUECHLLOavgJsbOLY7u3XlpSMdc+JWOd9sqkUxmjWEzNK0ugrmYMAPE7KyiFJzSSvDKT
         q4oJb4tqWeKn0fiaHA85a+wR+9IPKM+iJyGynTUAKh4O9op80oLDHjec9NGmG3STytsE
         fBWw==
X-Forwarded-Encrypted: i=1; AJvYcCUgf4l33cDdoUsDtVfBgK8SH6jawt+QCNQBicUk1Bkx99gsPDUipUXJ5bViYji8Zg1kqKF3aR8dzE8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxZ5yMVBhQAnqN43jka2yXdADSkKBsZXggDvJoVBUe8PFNvZMMf
	Qy1u2DaZmqw+Pw20xEHH84VKCTQX6ACK8jZY2fUnBumn33cEqhgiNk1mwLPzLg==
X-Gm-Gg: ASbGncsZUCeKRcapZP2Srt2Y5dEScix61eQcxZvQEFMBYckplbNvgjUqPcYkBSc1N6q
	h7AuXwBLmFoJO5q0mWqdCvwy0zzllH29jRJc3hAPVdWl0TyaQDl+S7AL0ECoCnvBCGH2KoqoK9V
	ATat9TXAcWY+GiGqf+vSdpunpYbcbn8mLmOiT14u93Lyu7doQGbkgMPy6JbRxaY2b69FJWLMWGF
	e5cJ0mNTtNNXg8fugwKVAdTZiCd6OFDWJhDce9mp6lXVidyYwcfDI6EzpHhqZ/2+VIZL0AxhpMN
	aRr/TJxyE1yUCrwtbZ/iFytCXT8c8bt5N0qXhpc=
X-Google-Smtp-Source: AGHT+IFuf9JNaiEBCW5wCIJN0XU5iIw+DLOP0RrU+9KfGH8ZJMiDC8PTcE+u/8gVRyz29nrzQgJigQ==
X-Received: by 2002:a5d:5983:0:b0:386:3835:9fec with SMTP id ffacd0b85a97d-386453fbb9cmr3909104f8f.44.1733848160226;
        Tue, 10 Dec 2024 08:29:20 -0800 (PST)
Message-ID: 
Date: Tue, 10 Dec 2024 17:29:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/7] xen: add new domctl get_changed_domain
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Cc: "Daniel P. Smith" ,
 Anthony PERARD ,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241206130221.17773-1-jgross@suse.com>
 <20241206130221.17773-6-jgross@suse.com>
 <69e08251-c227-42a5-a2e4-a4eb7d63961d@suse.com>
 <30304914-f0c5-4053-ae23-890fa5b8a0c2@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: <30304914-f0c5-4053-ae23-890fa5b8a0c2@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 10.12.2024 16:52, Jürgen Groß wrote:
> On 09.12.24 18:04, Jan Beulich wrote:
>> On 06.12.2024 14:02, Juergen Gross wrote:
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -192,6 +192,54 @@ static void domain_changed_state(const struct domain *d)
>>>       spin_unlock(&dom_state_changed_lock);
>>>   }
>>>   
>>> +static void set_domain_state_info(struct xen_domctl_get_domain_state *info,
>>> +                                  const struct domain *d)
>>> +{
>>> +    info->state = XEN_DOMCTL_GETDOMSTATE_STATE_EXIST;
>>> +    if ( d->is_shut_down )
>>> +        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN;
>>> +    if ( d->is_dying == DOMDYING_dead )
>>> +        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DYING;
>>
>> The public constant saying "dying" isn't quite in line with the internal
>> constant saying "dead". It may well be that Xenstore only cares about the
>> "dead" state, but then it would better be nemaed this way also in the
>> public interface, I think.
> 
> Okay, I'll rename it to "XEN_DOMCTL_GETDOMSTATE_STATE_DEAD".

Well, maybe have both DYING and DEAD, even if Xenstore right now needs only one?

>>> @@ -866,6 +873,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>>>                   __HYPERVISOR_domctl, "h", u_domctl);
>>>           break;
>>>   
>>> +    case XEN_DOMCTL_get_domain_state:
>>> +        ret = xsm_get_domain_state(XSM_XS_PRIV, d);
>>> +        if ( ret )
>>> +            break;
>>> +
>>> +        copyback = 1;
>>> +        ret = get_domain_state(&op->u.get_domain_state, d, &op->domain);
>>> +        break;
>>
>> Especially with this being a stable interface, surely the two padding fields
>> want checking to be zero on input (to possibly allow their future use for
>> something input-ish). Then even the memset() in the function may not really
>> be needed.
> 
> I'll add the check. Removing the memset() is a little bit doubtful, as this
> might result in leaking hypervisor data e.g. in case a domain isn't existing
> (this will copy the internal struct to the user even in the -ENOENT case).

Which internal struct? The function is passed &op->... for both parameters.
And op is fully copied from guest space.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 16:33:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 16:33:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852885.1266547 (Exim 4.92)
	(envelope-from )
	id 1tL3B2-0001aJ-4q; Tue, 10 Dec 2024 16:33:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852885.1266547; Tue, 10 Dec 2024 16:33: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 1tL3B2-0001aC-2H; Tue, 10 Dec 2024 16:33:36 +0000
Received: by outflank-mailman (input) for mailman id 852885;
 Tue, 10 Dec 2024 16:33: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 1tL3B0-0001a6-Fl
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 16:33:34 +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 7f525918-b714-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 17:33:33 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-385ddcfc97bso4484304f8f.1
 for ; Tue, 10 Dec 2024 08:33: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
 98e67ed59e1d1-2ef45fa64e0sm9925215a91.26.2024.12.10.08.33.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 08:33: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: 7f525918-b714-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733848413; x=1734453213; 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=FOniwqFGYbZUAFwVqgKH+rDg7KBiSEkg0U77NxhobA0=;
        b=NyuZQHD5Enr68m7X09vQxZFCBXkB/pDiT0V/NUfwqtNLDoBLXsUjXJQPdArXwAIuPn
         DalEWHweuDfvVNkHUvivUoK6DDnc9LUhJvq8wfzavyE7mL83hsrCHycbpoqcJGnIUJZR
         c7sG9iCjkyOjB/hXPvKXxkrJIzOcPc7DQHGHGC5bkjUtBkYRL2oaPB/aUEEu4Ol7fVr6
         TLqoNJkoBmzEmLrvmqJNYWUTYVYBsKX3gK95k9F/Rz9Kxwzl6QuAVte3MrYfOTEczEAN
         82GTFIwkicu5qHV/ThbbU+le3b4oYIXpYoC6EKHA7ZPvLSCrO+SZUXpur1y4TmNe4tu7
         dF4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733848413; x=1734453213;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=FOniwqFGYbZUAFwVqgKH+rDg7KBiSEkg0U77NxhobA0=;
        b=dkMXpSUVC0YA1tbRcqkjpJU7/+bKo7BBmOPjtWd/XVY6V/AaYJboKCj7B3ZrxsXLBp
         DV1eloTQxanxTp4dU8eRPrqPDoxPKzAfP7GOBGp6kE6X8R3IuILaQK+zdWYwR+aDdVni
         MHxOFeakBT26EoGlWiJ0En7Ix9UTOJqoD5E4Iym0ogF6pOQtbmMyc2VKHMIjROsZ4Wty
         xeYX8kJ1hbxnXM0oIehDitlvzW4VsznOOcAzbO9KTu6cGWw6TKHtHdNYdfmtmRAAaLAB
         5DJ6MD5v7zZM/8tNo2BP7hFgehfhPwtDf3AuiLK9XkgXKDQ5+r+LBG2IEjh+No7TYdWe
         xHHw==
X-Forwarded-Encrypted: i=1; AJvYcCXf0Q3/cKR1RRgi6/DhMnoD10zjoM/clqv1LeAS6bi93xuVQFFXP/2qJAFPMc5RJiKQ0qxLTVs+sjM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz7kUx+NZWFuwXWBG03DJLKmYBp+tYRL2uTBxTdpw9xlq9PzRZS
	oFxEFUSP2WIS7JS69uxDz73FoGxb0Apc6Ez+pjbacb7thi/KtFxa1sF62PTU+WMDBkf6sVacO60
	=
X-Gm-Gg: ASbGnctVTRBSLij4PeqJX7EtfCI9ojhhmZ55QwnJCQEojchp10W5ZBqQPcEbECZihce
	Ha9BfnY40ifW9bVC6m1P25f2DqOGCh5hCIkZ8d3nQ93lAHW7+1rWcTk2ANY3JJ4+RwTjpBYwy+p
	zfHhbyU4cwlDRMlQWh4GFdeaavxjgzHcodBric7aXpXDyGO/CXTvNlphknIeGRJDDQyPE/+C7Fr
	qS4hK9OMTBUtLIwdVejXF6Ny3DtQNCyZxTU+8E3z1EYHXwNdcdh0FfSX0Hm1vWWK7gw88+eJgV+
	eLDjjW4d3nLwYhMxZY2EtRdd2/bAYpz3RUmazaI=
X-Google-Smtp-Source: AGHT+IHagAhhONRePRDNl4DOQihr5Ufus4/Egzhax8s3bFsJ1ShmiySAlNBbGU7wYAQlW7yUETNKFQ==
X-Received: by 2002:a05:6000:20c7:b0:385:f10a:335 with SMTP id ffacd0b85a97d-3862b350a83mr10636973f8f.21.1733848413110;
        Tue, 10 Dec 2024 08:33:33 -0800 (PST)
Message-ID: 
Date: Tue, 10 Dec 2024 17:33:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/vpci: fix memory type in guest_mem_bar_read()
To: Stewart Hildebrand 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241210162546.403882-1-stewart.hildebrand@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: <20241210162546.403882-1-stewart.hildebrand@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.12.2024 17:25, Stewart Hildebrand wrote:
> Currently, if bar->type is anything other than VPCI_BAR_MEM32, the
> memory type bits get set to PCI_BASE_ADDRESS_MEM_TYPE_64 in the returned
> value. This leads to the wrong memory type for, e.g. VPCI_BAR_EMPTY.
> Only set PCI_BASE_ADDRESS_MEM_TYPE_64 when the bar type is
> VPCI_BAR_MEM64_LO.

Yet would guest_mem_bar_read() ever be installed as a handler for an
empty BAR? If so, that's the mistake, I think.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 16:37:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 16:37:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852899.1266558 (Exim 4.92)
	(envelope-from )
	id 1tL3Ey-00029E-K8; Tue, 10 Dec 2024 16:37:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852899.1266558; Tue, 10 Dec 2024 16:37: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 1tL3Ey-000297-HB; Tue, 10 Dec 2024 16:37:40 +0000
Received: by outflank-mailman (input) for mailman id 852899;
 Tue, 10 Dec 2024 16:37: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 1tL3Ew-00028v-PX
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 16:37:38 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 111170af-b715-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 17:37:38 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-aa543c4db92so348806366b.0
 for ; Tue, 10 Dec 2024 08:37:38 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa69e874fa3sm172516866b.114.2024.12.10.08.37.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 10 Dec 2024 08:37: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: 111170af-b715-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733848657; x=1734453457; 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=6+v6qyh0QPV3NY4BNC990GyixrxR4cFnNB0rO8+l/c0=;
        b=sFFJECP34uC3LaRb+J0zL+WEkufcjJyPVD2yfpp/pwJSEqhInEVhyJ6CX5zluOxT3E
         HuBtu+Y5OXvvBTLz4xjVKJ6pY1OBq/DQrlTBfCH79lTr3jeUxjpV8IEDLAwldrHazQfM
         IZzPxdxd0TL58ZwqblTgq/+l8/wN6xGTqRo/I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733848657; x=1734453457;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6+v6qyh0QPV3NY4BNC990GyixrxR4cFnNB0rO8+l/c0=;
        b=lGl27PlwhZ3nZLNAtfMcEpeDT0CV/3e1Wcg/UR62PVSUL6sVopVmd4KGQxi+tPeEGL
         wlqrmc9mugdnHhrFfd45uXeQ8TU2Dh8HCdSLJKYcu9tis63LXLck6xLnoqMZrKIWgDrp
         yVpUvyv8f9FRv2wSLWYdT5sHYfxCoCYDxw2Twmk8VFMOh8VqFbAZrDKHJdTxH2pIPvdb
         GCjI5RNFWOe9EbO6rUSc3r5qm1wSsdjcx8FmTAQT7YezwueyV/75MSqBuEJ2g0FJSZUY
         DL9Mi8GkcOAQjW9omw6F5XUXgqJdL11TP3V1dYchiP4aE8VJ+TqVCgRfR2jJ1LQEohbA
         DRYA==
X-Gm-Message-State: AOJu0YzXcYt89LB4x8YndIGhTs9HuJdPQd+SjA3KJolQHVnnJ6tMhEgd
	tpSM34F93NmDG/5DLiqYPx7Lipu8tZFTfaJrBN6cPUv1BqSQ3R7e0Ty+dQ13KKuuTGlQqgcUMO6
	F
X-Gm-Gg: ASbGncvswVhjln5Yw25AIsdzMXv3RRfTYeu34Ul0Bzhsgxw92/iSMPS14RYjDhVyy+L
	A1woENl0L34RrdlYjreGqSZKFKV0daFXQE91RmtiSLrJ5X01zSifP3ERj2QVfLN8bMStTulVeew
	+wPXONRpQJvpzOqkXhnvk4g5xfHfeP7m0GRrG/Bcsu69kEjoP9tytM8zjg7jevfbHC8Vk/uD1M1
	h1mz9/YSSHnpiKbScK2XYyM/3h3/1HpklHqZp9mhrBT4Gx6u8zIwu1yHAWPnco=
X-Google-Smtp-Source: AGHT+IE4kD/ZaUWrj0I6I2DrNKxxyKDg/Daa9Ojnzwli/zW7wBC4BUz8sdYONdu1Bq+JE6vekqtUvw==
X-Received: by 2002:a17:906:1db2:b0:aa6:8d51:8fdb with SMTP id a640c23a62f3a-aa69cd37751mr519015766b.19.1733848657463;
        Tue, 10 Dec 2024 08:37:37 -0800 (PST)
Date: Tue, 10 Dec 2024 17:37:36 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stewart Hildebrand 
Cc: xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/vpci: fix memory type in guest_mem_bar_read()
Message-ID: 
References: <20241210162546.403882-1-stewart.hildebrand@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241210162546.403882-1-stewart.hildebrand@amd.com>

On Tue, Dec 10, 2024 at 11:25:44AM -0500, Stewart Hildebrand wrote:
> Currently, if bar->type is anything other than VPCI_BAR_MEM32, the
> memory type bits get set to PCI_BASE_ADDRESS_MEM_TYPE_64 in the returned
> value. This leads to the wrong memory type for, e.g. VPCI_BAR_EMPTY.
> Only set PCI_BASE_ADDRESS_MEM_TYPE_64 when the bar type is
> VPCI_BAR_MEM64_LO.

I'm confused, VPCI_BAR_EMPTY shouldn't use guest_mem_bar_read() in the
first place, as its read handler should be vpci_read_val() instead.

Is there something I'm missing from init_header()?

        if ( size == 0 )
        {
            bars[i].type = VPCI_BAR_EMPTY;

            if ( !is_hwdom )
            {
                rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL,
                                       reg, 4, (void *)0);
                if ( rc )
                    goto fail;
            }

            continue;
        }

AFAICT guest_mem_bar_read() should only handle BAR types that are
either VPCI_BAR_MEM32, VPCI_BAR_MEM64_HI or VPCI_BAR_MEM64_LO, and
that seems to be correctly handled?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 16:59:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 16:59:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852917.1266567 (Exim 4.92)
	(envelope-from )
	id 1tL3Zn-0005fZ-44; Tue, 10 Dec 2024 16:59:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852917.1266567; Tue, 10 Dec 2024 16:59: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 1tL3Zn-0005fS-1X; Tue, 10 Dec 2024 16:59:11 +0000
Received: by outflank-mailman (input) for mailman id 852917;
 Tue, 10 Dec 2024 16:59: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 1tL3Zl-0005fI-5V
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 16:59:09 +0000
Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com
 [2607:f8b0:4864:20::f30])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 110dc6bb-b718-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 17:59:07 +0100 (CET)
Received: by mail-qv1-xf30.google.com with SMTP id
 6a1803df08f44-6d8fa32d3d6so41822826d6.2
 for ; Tue, 10 Dec 2024 08:59: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: 110dc6bb-b718-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1733849946; x=1734454746; 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=r7vN7jpHairKQm0qZI5k4oOx70lgfLVBYXPZclRFKLE=;
        b=gO4hPq5IxhfdI24IOBrdnXvuVLMq+1STV6dr2X0II5vxC0YliZe2C7ryUCQlGYuJEK
         TM6SeRS/mp7WXbNtAg2VOjrlzuCJU6zS5+KjSAzL01GCrfVu/AVbW3ZAzcuYdXipIySz
         WAQvn5bI28ja5vbbPQ2SZ/7J4lBJJ8TH4NItk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733849946; x=1734454746;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=r7vN7jpHairKQm0qZI5k4oOx70lgfLVBYXPZclRFKLE=;
        b=ub8PKbS+bzWMgU+AMqnUrsa8OroyH8pRtq2xVxbCwi+iTBm/gTi97z7tM28IE1GyuC
         W89OGZslSAOh8I0bfJJ3rOUm+iHtuPoo1Jwt6Ws1ktPrmCG+J9St0hlvlns1yPCfRyAd
         CQamxAsRoQOoJve8U7ObTNgC7vNavksAB5I2mc5ck/bK5GypwMBtNRSMFim7pr0bs0LA
         zZW1249SiYiI9k9PHKYnykFhq+GLDsYlvInOjnrejrXvAPk8vora7Vk/MUzifLjJkDSO
         ZeSai4wghdCDYxuP7Ai7nHViRU2WiBZ6GSdAbzQh3KchHq4aFYacgHyjUJjT69ymwxF1
         hC1Q==
X-Forwarded-Encrypted: i=1; AJvYcCUD66oq9hpQNsqtF/675Zp53FXxoV61DocgpasvJPGUZ9jRWLiE7BDlKgih1gFc2WSxNTiH9R4t8Z0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwZCdxolddBWT0S6niG5iM8txQrhb1fNskVBBIoxmXpYwfRGglr
	uOLEJOtrWfSFD8UQ6luxfD7ewXXCkVG24zr/93pOzqXSn36svOxCfwhvJMIZM8ca89AfxUy4Nt2
	SCGf3PrvnKVro+e7E25CE78lvBoR6TDKP0sVFDg==
X-Gm-Gg: ASbGncv9BjEytUebtbj059cWtC13d3zhL4iBUU5ZFcWnOJCVhI1jsJSjcNzoIV1M70i
	StFAk52BFs5E0Y/uFFppCIjFvhBx1B+pdhRIUSQ==
X-Google-Smtp-Source: AGHT+IGNw3JumkGkMivKX7EpPjqOd7xReLyS2c97oPwFQoKaNQUI4q156SPv2hADn0JT83VNkWvZlPwBqPH0ussKcvc=
X-Received: by 2002:a05:6214:f06:b0:6d8:ab7e:e55e with SMTP id
 6a1803df08f44-6d91e40b22amr78997926d6.34.1733849945888; Tue, 10 Dec 2024
 08:59:05 -0800 (PST)
MIME-Version: 1.0
References: 
  <4e9c0566-bed7-47a6-aa6d-2ac76c0a1bfe@suse.com>
  <6b15ccd8-9525-4a85-9fde-bb53ee34761a@suse.com>
In-Reply-To: <6b15ccd8-9525-4a85-9fde-bb53ee34761a@suse.com>
From: Alejandro Vallejo 
Date: Tue, 10 Dec 2024 16:58:54 +0000
Message-ID: 
Subject: Re: [PATCH] x86/FPU: make vcpu_reset_fpu() build again with old gcc
To: Jan Beulich 
Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	"xen-devel@lists.xenproject.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 10, 2024 at 4:14=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 10.12.2024 16:12, Alejandro Vallejo wrote:
> > On Tue Dec 10, 2024 at 2:34 PM GMT, Jan Beulich wrote:
> >> On 10.12.2024 15:25, Alejandro Vallejo wrote:
> >>> On Mon Dec 9, 2024 at 3:13 PM GMT, Jan Beulich wrote:
> >>>> Fields of anonymous structs/unions may not be part of an initializer=
 for
> >>>> rather old gcc.
> >>>
> >>> Can you add the specific version for tracking purposes?
> >>
> >> It's all the same as before, and I really didn't want to waste time on
> >> once again figuring out which exact version it was that the behavior
> >> changed to the better.
> >
> > Just checked on Godbolt. 4.7.1 works and 4.6.4 doesn't. Adding that dat=
a point
> > to the commit message really helps when navigating git-blame, even if i=
t's not
> > as precise as it could be. Particularly if one wants to understand exac=
tly
> > which quirk of which version of which compiler is being dealt with.
>
> Well, thanks for sorting that out. I've added that info.
>
> > With the commit message adjusted with the offending GCC version (i.e: <=
4.7.1):
> >
> >   Acked-by: Alejandro Vallejo 
>
> Thanks here as well. Any chance though you would be willing to upgrade th=
at
> to R-b? Only that would allow me to put in the patch without waiting for =
yet
> another tag.
>
> Jan

Sure.

  Reviewed-by: Alejandro Vallejo 

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 17:11:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 17:11:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.852932.1266578 (Exim 4.92)
	(envelope-from )
	id 1tL3lH-0000Ki-43; Tue, 10 Dec 2024 17:11:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 852932.1266578; Tue, 10 Dec 2024 17:11: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 1tL3lH-0000Kb-1L; Tue, 10 Dec 2024 17:11:03 +0000
Received: by outflank-mailman (input) for mailman id 852932;
 Tue, 10 Dec 2024 17:11: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 1tL3lG-0000KU-Dz
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 17:11:02 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2409::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b9935888-b719-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 18:11:00 +0100 (CET)
Received: from BN1PR14CA0028.namprd14.prod.outlook.com (2603:10b6:408:e3::33)
 by SN7PR12MB8601.namprd12.prod.outlook.com (2603:10b6:806:26e::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Tue, 10 Dec
 2024 17:10:54 +0000
Received: from BN3PEPF0000B06C.namprd21.prod.outlook.com
 (2603:10b6:408:e3:cafe::83) by BN1PR14CA0028.outlook.office365.com
 (2603:10b6:408:e3::33) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.15 via Frontend Transport; Tue,
 10 Dec 2024 17:10:53 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN3PEPF0000B06C.mail.protection.outlook.com (10.167.243.71) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8272.0 via Frontend Transport; Tue, 10 Dec 2024 17:10:53 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 10 Dec
 2024 11:10:52 -0600
Received: from [172.21.132.86] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 10 Dec 2024 11:10: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: b9935888-b719-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=O1WLPk6NHYqlM5b2VqmA4xxiXY/QhTwTEjuAMvrBchAb8EyBIQhEXev3aBanNOo+YH9rNCKkKo3p8OpyPk6kCJjZ2LllGHHSUPe5hRscek5AxHUHcLEfg3oE1YANzIwxFT8Ph19qIreqrRn7jZ2umWNJ6gDLN3xFWgHX95M3d19XRWUa+i6JhN9PIaogrtSq/K98Xf1ZpnBiVG2kZzGUwEwyZAwJlQ4+1997KdIagndYr6Y4sj1EyHndWuGqSWY9BXqZbj711MDg1D688KlyAZe1wH57k5kjUJNCR/kvGdlIN3jAzUSFy4xh/XqsY/SFcS1uIqhH+Tc8P4jr2tTv1A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Gu6eYOa3khxPcVYL956PzomvkQ877K0g6poQ1WpNxyA=;
 b=plMC6o98c49jT8QGvGRBG8/Y3T6ow8sdLf9akz1LorglBukVfQy2Eo/3FSqnI3dW+LdmAEGmIcbPMw5RhflKfIapXhznfLxdrl56e0QBXW7JXESPdBNKV4P6M2CVzKh6rtmp0zwWuOBAJ4p85HTmES82+xvoVIKc6it/7+XXhDC+vii8uMDgc1WRtOxBFWJaldK5XZWqQO8hdMXoawC3TeSgJ1NFFxtPTG/WUb3HpVH5/8Co2XuE5pH2geF0Z6aw1azMe7n/XOqG/57qC1vUBNcj8On6JTLzP0vh4BK/9++pmLRjShplAShWEWa0ZjTc96iIewzmqQOX4aQHFJ8f8g==
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=Gu6eYOa3khxPcVYL956PzomvkQ877K0g6poQ1WpNxyA=;
 b=LtOJgCU+CkKVBzT4Z0oPUH7/SimrxmWwiUZTWR+Fd4UfH0riINYkIyGGKMW4pRwkJyqivSmfsbB1Q2ZUTRN+0HMF8xvlyfLAPxkdCD9ZwkU8rLUQYECdVnpA7QXF3n/JCM2EIEfSwk2a8cX5nZRWQC3Gku2hgabKWQr00ws/o8A=
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=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Tue, 10 Dec 2024 12:10:52 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/vpci: fix memory type in guest_mem_bar_read()
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
CC: 
References: <20241210162546.403882-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
Received-SPF: None (SATLEXMB03.amd.com: stewart.hildebrand@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B06C:EE_|SN7PR12MB8601:EE_
X-MS-Office365-Filtering-Correlation-Id: 90bd10cc-9e4e-47a2-0d84-08dd193d9aaa
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?UVIxcnpkdjBsSzdJV0FYNzdCc1R2R2pHWGV1WjgzbmFKZS93Q1lJdTVVQkdV?=
 =?utf-8?B?b05NRzBLY1BKWTd6QStHcDNtVHppaEJ0b1Y4cG9xMlB1K1NGUmdyOUdBSXJY?=
 =?utf-8?B?ZUlwSDRNS3dHTExRbzRmckl2ZkxnMHh3Y1ZTeHREMnBPZDVpbnNhVEt6NmVT?=
 =?utf-8?B?a0xWWmZoRjNRMG1RSzNqZkJsSkhTdlpiWUhEdWNBb1liZEZKUGpFN2UySVNV?=
 =?utf-8?B?S0xQSklHYS9ONlUxMGlpZm4zTEFuQ1RnT3VzL3h1dWZmeXRUVXI0R2tHbmcr?=
 =?utf-8?B?SVpKaEhmaHpQQ254MlBEa0oxUEd3MEtEcDNuUERvbXlPR040T3UwbWNueGVD?=
 =?utf-8?B?ODV1NDJTMk9OazhwUERXK3FHOWhUWkUxTURwR3UxSnArZUM5QVBzeVFsbyt3?=
 =?utf-8?B?cTQyK0dXaGhMVnpHb0doOHNqRlpXOWhpY0psYnE0R2t5a2QzYmpDSW5aWEJm?=
 =?utf-8?B?V2hVY2hJeDl1N1hKaHhVZWNMZHpPbURTRllaanVUdTBsck1ZY05KMDNjenE1?=
 =?utf-8?B?VFJNVUc0TDVXQkYrcXQ5dzdIZEU3YUJqZjRPUFpPaUIzQytieXJHeXBsNjJI?=
 =?utf-8?B?OERPVUxmVTdpZWdRS3dLZVk1ZlhrcDIycTZudmpXVG1TTFVGbk5KM3I1dEto?=
 =?utf-8?B?czA0MHdLNy9KVXMrbTJKR3R6MkJCby9WLzFxemNBUjcvSGRrakZqNjlQRHJz?=
 =?utf-8?B?UHZXalJsa2xWazJWNGJIaTROMGlrSTVucXk3dlBqeW9iOGdxbkhRWVdQZHEx?=
 =?utf-8?B?NHhJVkpnMUp1cUwrbGdmbTNQRFhjWWxtQVRsYnNVZzRwbWpjYmhzazQ4YUgx?=
 =?utf-8?B?N05reDNPVUNybGxKN2NSZHJEY2t1T2tLL1A0aWlmdEMvdFJwNTlad1Bqdndu?=
 =?utf-8?B?dE5MZlNnbjM1THpyamREdnFCQng3Y1N4dXJXRDNyZkxkKzExUXRPa25ITUIw?=
 =?utf-8?B?ZldZS05HL3lrRXpQYStqdUh1RVdqNFo2cDRsUFYwdE5TL2QwOVpldEhzRlBT?=
 =?utf-8?B?TjduTFNBZ0o4RWRpazZzL21PWFFFYi9tT3NieEJnaUl4SXFsSXg3dkJDdGYr?=
 =?utf-8?B?WkNuUS9QUm5vMC96NFk4bnliNzFIOHM5UFNzMHVCVk1MVXAvV1VrcG5ZREx3?=
 =?utf-8?B?Mm1PWWw1blU4dFRLalJrb1VCZC8yeHAyVmZSZzhhUTVzS0ZMUy95UU9TdytT?=
 =?utf-8?B?UzhnanVndGlYWGNLT1BwamU2V1RZNkQ1MGhQcDFKdVdVWlBzaUNKbnZybUpS?=
 =?utf-8?B?UkpYNUg4K2E5UzN6cnJLZDRJaEtuY3BjRm5ycW5NOEs1M3BkdTdnNXhvQ09H?=
 =?utf-8?B?YmsvcmpTaVRHckM2SE5ncmlRQWJCS3NWUFVvSGFFVllLTWxZMHZoQlZESldH?=
 =?utf-8?B?ZVFTMnBiTFFxZVZwekN3azZrRkhFeVh5R1hkN0wxVlE4VVIxbUt4a2NtQ1N5?=
 =?utf-8?B?ejZJVkJJcERYZ0tLZUlWTlNTbVVaeFNGN3BJME9kVE54NkErcTlWOERWeE9N?=
 =?utf-8?B?Z2c1eWw0bE8wOStaNkR4VWtHMHlsTFhxdmpBekExTUNrUFo1MFVtOHZEOGlu?=
 =?utf-8?B?NUJEbEJYNHpxMFFHTzU1aW9zQ2FxUk5CcGh4UWN1SFpTRUQ0TzdkTXBUSjUv?=
 =?utf-8?B?aWJNRDRGREdJZEZ5dm9YMFhVTVNWbTZGWndPOGd4MkY3TnFYYTMwUUwvME55?=
 =?utf-8?B?VnFtWU8yMU9CUjQ5Tkp4NFFSZWRDc0poVm1jUlJPVWdjNkl3LzZueml4ODVn?=
 =?utf-8?B?TXlhQ2ZwVFF4a0JkQzBJQThiSzM1cjZrTUg0L3U0NC8rakthdlgvTG0wYUJV?=
 =?utf-8?B?VmZIdTkxUEZWWXppdFZucjBWblg0c3JuMjlIU3dhS2xEazFIdHduejdSOTE3?=
 =?utf-8?B?UmlQdGZ0cStndzZuUFEwbDVUMVh4dFdDUGRjVHNoRUxFYlE9PQ==?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2024 17:10:53.4388
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 90bd10cc-9e4e-47a2-0d84-08dd193d9aaa
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B06C.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8601

On 12/10/24 11:37, Roger Pau Monné wrote:
> On Tue, Dec 10, 2024 at 11:25:44AM -0500, Stewart Hildebrand wrote:
>> Currently, if bar->type is anything other than VPCI_BAR_MEM32, the
>> memory type bits get set to PCI_BASE_ADDRESS_MEM_TYPE_64 in the returned
>> value. This leads to the wrong memory type for, e.g. VPCI_BAR_EMPTY.
>> Only set PCI_BASE_ADDRESS_MEM_TYPE_64 when the bar type is
>> VPCI_BAR_MEM64_LO.
> 
> I'm confused, VPCI_BAR_EMPTY shouldn't use guest_mem_bar_read() in the
> first place, as its read handler should be vpci_read_val() instead.
> 
> Is there something I'm missing from init_header()?
> 
>         if ( size == 0 )
>         {
>             bars[i].type = VPCI_BAR_EMPTY;
> 
>             if ( !is_hwdom )
>             {
>                 rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL,
>                                        reg, 4, (void *)0);
>                 if ( rc )
>                     goto fail;
>             }
> 
>             continue;
>         }
> 
> AFAICT guest_mem_bar_read() should only handle BAR types that are
> either VPCI_BAR_MEM32, VPCI_BAR_MEM64_HI or VPCI_BAR_MEM64_LO, and
> that seems to be correctly handled?

Ah, you're right, sorry. I pulled this patch out of another series that
I'm working on, but failed to realize that guest_mem_bar_read shouldn't
be used for VPCI_BAR_EMPTY. Please disregard.


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:02:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:02:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853123.1266723 (Exim 4.92)
	(envelope-from )
	id 1tL8Ja-0003H6-9L; Tue, 10 Dec 2024 22:02:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853123.1266723; Tue, 10 Dec 2024 22:02: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 1tL8JZ-0003FP-W6; Tue, 10 Dec 2024 22:02:46 +0000
Received: by outflank-mailman (input) for mailman id 853123;
 Tue, 10 Dec 2024 22:02: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 1tL8JY-0001xA-ME
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:44 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 7a90b097-b742-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 23:02:42 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id D4E6A204722D;
 Tue, 10 Dec 2024 14:02: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: 7a90b097-b742-11ef-a0d5-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com D4E6A204722D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868158;
	bh=DhJBfAD2d6ET0f+MR7PDWaX6CpgYhpsGb+RQrMGIOAY=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
	b=IIAWMyJ8NzQC8a9Pk8dz0U3jdNgu9NGd3SiawGSbAFHI2lBJj9kVVY+Jrn6mOAaem
	 Wm2Q0riPqkUNNLsJAJDVn84Us2zbSxk2FObucA7BvA+Ci0Obga6BtVUEDHD7pm4PpM
	 tPAQA1jtOYji99byX6HP0p2SzC0hDQD6638LF7MQ=
From: Easwar Hariharan 
Date: Tue, 10 Dec 2024 22:02:39 +0000
Subject: [PATCH v3 08/19] drm/xe: Convert timeout to secs_to_jiffies()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Message-Id: <20241210-converge-secs-to-jiffies-v3-8-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan 
X-Mailer: b4 0.14.2

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Reviewed-by: Thomas Hellström 
Signed-off-by: Easwar Hariharan 
---
 drivers/gpu/drm/xe/xe_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index 56d4ffb650dade8622cc25026a96155fa5572434..9093469a275f46f7bf58ff1049c1c9cc712cdd33 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -519,7 +519,7 @@ static int wait_for_lmem_ready(struct xe_device *xe)
 	drm_dbg(&xe->drm, "Waiting for lmem initialization\n");
 
 	start = jiffies;
-	timeout = start + msecs_to_jiffies(60 * 1000); /* 60 sec! */
+	timeout = start + secs_to_jiffies(60); /* 60 sec! */
 
 	do {
 		if (signal_pending(current))

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:02:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:02:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853122.1266717 (Exim 4.92)
	(envelope-from )
	id 1tL8JZ-00038J-QT; Tue, 10 Dec 2024 22:02:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853122.1266717; Tue, 10 Dec 2024 22:02: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 1tL8JZ-00036S-FJ; Tue, 10 Dec 2024 22:02:45 +0000
Received: by outflank-mailman (input) for mailman id 853122;
 Tue, 10 Dec 2024 22:02: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 1tL8JX-0001xA-Lu
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:43 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 7a3a455b-b742-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 23:02:42 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id A7DE320BCAEA;
 Tue, 10 Dec 2024 14:02: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: 7a3a455b-b742-11ef-a0d5-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com A7DE320BCAEA
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868157;
	bh=WjXR/e+Bt5J36pfaIEwWXUE8wYei/ElgtSssYeLrLS0=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
	b=k1q7WXOxk1qYLVn196G3sb8s3XVjdPiH9giyU/vMWpK4NQiBox8ErAeTFxnenHayv
	 1NLSp5g4CPg/qfYp440BlKTVCcToWDafQQXFfUYhXGaNJP4LCGPckmvvkPFrzQ2ykv
	 8WoFkMMhJxjwt/2RQ+Oo6g69AunqDN5xYmAoTPZY=
From: Easwar Hariharan 
Date: Tue, 10 Dec 2024 22:02:38 +0000
Subject: [PATCH v3 07/19] accel/habanalabs: Convert timeouts to
 secs_to_jiffies()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20241210-converge-secs-to-jiffies-v3-7-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan 
X-Mailer: b4 0.14.2

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan 
---
 drivers/accel/habanalabs/common/device.c         | 2 +-
 drivers/accel/habanalabs/common/habanalabs_drv.c | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/accel/habanalabs/common/device.c b/drivers/accel/habanalabs/common/device.c
index e0cf3b4343bb081638430f2552ed27431b488ff9..30277ae410d4b742ffb7bddc35498564ff96fe62 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -817,7 +817,7 @@ static void device_hard_reset_pending(struct work_struct *work)
 		}
 
 		queue_delayed_work(hdev->reset_wq, &device_reset_work->reset_work,
-					msecs_to_jiffies(HL_PENDING_RESET_PER_SEC * 1000));
+					secs_to_jiffies(HL_PENDING_RESET_PER_SEC));
 	}
 }
 
diff --git a/drivers/accel/habanalabs/common/habanalabs_drv.c b/drivers/accel/habanalabs/common/habanalabs_drv.c
index 5409b2c656c803f6d172dd882711357061f30022..596c52e8aa266bf48e2be45e719adb202604577b 100644
--- a/drivers/accel/habanalabs/common/habanalabs_drv.c
+++ b/drivers/accel/habanalabs/common/habanalabs_drv.c
@@ -361,8 +361,7 @@ static void fixup_device_params_per_asic(struct hl_device *hdev, int timeout)
 		 * a different default timeout for Gaudi
 		 */
 		if (timeout == HL_DEFAULT_TIMEOUT_LOCKED)
-			hdev->timeout_jiffies = msecs_to_jiffies(GAUDI_DEFAULT_TIMEOUT_LOCKED *
-										MSEC_PER_SEC);
+			hdev->timeout_jiffies = secs_to_jiffies(GAUDI_DEFAULT_TIMEOUT_LOCKED);
 
 		hdev->reset_upon_device_release = 0;
 		break;

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:02:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:02:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853118.1266690 (Exim 4.92)
	(envelope-from )
	id 1tL8JX-0002dI-SK; Tue, 10 Dec 2024 22:02:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853118.1266690; Tue, 10 Dec 2024 22:02:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tL8JX-0002cc-Mg; Tue, 10 Dec 2024 22:02:43 +0000
Received: by outflank-mailman (input) for mailman id 853118;
 Tue, 10 Dec 2024 22:02: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 1tL8JV-0001xA-La
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:41 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 79172c0e-b742-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 23:02:40 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id 1CDB6204722B;
 Tue, 10 Dec 2024 14:02: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: 79172c0e-b742-11ef-a0d5-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 1CDB6204722B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868157;
	bh=q4DaHZqCWeIKQe7TTG2rV3K7PdI1M/As9LhjCxxNuts=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
	b=Cha0cDHP2vqeI8GSgKLIifsRbCjhIP9dfadMSDrPMIXzCzmN2lfENv6VOGo3TWGGc
	 RhOk4eEHD3feUGZkxL7/wUYX3ev+tB6zBroy0qt0RlqU7ha1EGeg6x38R1w2x8kfbl
	 wuStr/zn04e6xBcfNPjBsiQEchSCZugge2XzJeQs=
From: Easwar Hariharan 
Date: Tue, 10 Dec 2024 22:02:35 +0000
Subject: [PATCH v3 04/19] s390: kernel: Convert timeouts to use
 secs_to_jiffies()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20241210-converge-secs-to-jiffies-v3-4-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan 
X-Mailer: b4 0.14.2

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the values here are a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan 
---
 arch/s390/kernel/lgr.c      | 2 +-
 arch/s390/kernel/time.c     | 4 ++--
 arch/s390/kernel/topology.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/s390/kernel/lgr.c b/arch/s390/kernel/lgr.c
index 6652e54cf3db9fbdd8cfb06f8a0dc1d4c05ae7d7..6d1ffca5f798086160112990cb947ec8deed0659 100644
--- a/arch/s390/kernel/lgr.c
+++ b/arch/s390/kernel/lgr.c
@@ -166,7 +166,7 @@ static struct timer_list lgr_timer;
  */
 static void lgr_timer_set(void)
 {
-	mod_timer(&lgr_timer, jiffies + msecs_to_jiffies(LGR_TIMER_INTERVAL_SECS * MSEC_PER_SEC));
+	mod_timer(&lgr_timer, jiffies + secs_to_jiffies(LGR_TIMER_INTERVAL_SECS));
 }
 
 /*
diff --git a/arch/s390/kernel/time.c b/arch/s390/kernel/time.c
index 34a65c141ea076ba97b3238f1f36f077b15961df..e9f47c3a61978a45c72aee23bc44dcb128113c8c 100644
--- a/arch/s390/kernel/time.c
+++ b/arch/s390/kernel/time.c
@@ -662,12 +662,12 @@ static void stp_check_leap(void)
 		if (ret < 0)
 			pr_err("failed to set leap second flags\n");
 		/* arm Timer to clear leap second flags */
-		mod_timer(&stp_timer, jiffies + msecs_to_jiffies(14400 * MSEC_PER_SEC));
+		mod_timer(&stp_timer, jiffies + secs_to_jiffies(14400));
 	} else {
 		/* The day the leap second is scheduled for hasn't been reached. Retry
 		 * in one hour.
 		 */
-		mod_timer(&stp_timer, jiffies + msecs_to_jiffies(3600 * MSEC_PER_SEC));
+		mod_timer(&stp_timer, jiffies + secs_to_jiffies(3600));
 	}
 }
 
diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
index 4f9c301a705b63f8dd0e7bc33e7206ad1222e7a7..0fd56a1cadbd4f41a9876a3a3fec7f5dc08ac2db 100644
--- a/arch/s390/kernel/topology.c
+++ b/arch/s390/kernel/topology.c
@@ -371,7 +371,7 @@ static void set_topology_timer(void)
 	if (atomic_add_unless(&topology_poll, -1, 0))
 		mod_timer(&topology_timer, jiffies + msecs_to_jiffies(100));
 	else
-		mod_timer(&topology_timer, jiffies + msecs_to_jiffies(60 * MSEC_PER_SEC));
+		mod_timer(&topology_timer, jiffies + secs_to_jiffies(60));
 }
 
 void topology_expect_change(void)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:02:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:02:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853115.1266660 (Exim 4.92)
	(envelope-from )
	id 1tL8JW-0001xc-0c; Tue, 10 Dec 2024 22:02:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853115.1266660; Tue, 10 Dec 2024 22:02: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 1tL8JV-0001xV-Sr; Tue, 10 Dec 2024 22:02:41 +0000
Received: by outflank-mailman (input) for mailman id 853115;
 Tue, 10 Dec 2024 22:02: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 1tL8JV-0001xA-0Y
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:41 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 78a3501f-b742-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 23:02:39 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id E562F204722A;
 Tue, 10 Dec 2024 14:02: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: 78a3501f-b742-11ef-a0d5-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com E562F204722A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868157;
	bh=c41QzYd4hhSXlS6Xp2pgWqH2EB3T3v3i9Pb37cjnO/o=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
	b=qVCIV9cfYQFUEbAPN5oHTbVOOCMPtJTRnplX1niaLB3lEuL2MM5F44Gr4RM6lOTTS
	 WXCIz2JA6aYjhurN56TEZJEQV0OG8AVSPHDGlGJRGWabTGSgGWE+1I7d1M8c078PhJ
	 k5GeR3RvYMN/zDxLHn2xchQHWB1a1MyycuJ1TrJU=
From: Easwar Hariharan 
Date: Tue, 10 Dec 2024 22:02:34 +0000
Subject: [PATCH v3 03/19] arm: pxa: Convert timeouts to use
 secs_to_jiffies()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20241210-converge-secs-to-jiffies-v3-3-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan 
X-Mailer: b4 0.14.2

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan 
---
 arch/arm/mach-pxa/sharpsl_pm.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-pxa/sharpsl_pm.c b/arch/arm/mach-pxa/sharpsl_pm.c
index 0c8d9000df5a6384d615cf231ff986c0c6b71681..dd930e3a61a493293597815782d2ffd36605a700 100644
--- a/arch/arm/mach-pxa/sharpsl_pm.c
+++ b/arch/arm/mach-pxa/sharpsl_pm.c
@@ -31,10 +31,10 @@
 /*
  * Constants
  */
-#define SHARPSL_CHARGE_ON_TIME_INTERVAL        (msecs_to_jiffies(1*60*1000))  /* 1 min */
-#define SHARPSL_CHARGE_FINISH_TIME             (msecs_to_jiffies(10*60*1000)) /* 10 min */
-#define SHARPSL_BATCHK_TIME                    (msecs_to_jiffies(15*1000))    /* 15 sec */
-#define SHARPSL_BATCHK_TIME_SUSPEND            (60*10)                        /* 10 min */
+#define SHARPSL_CHARGE_ON_TIME_INTERVAL        (secs_to_jiffies(60))
+#define SHARPSL_CHARGE_FINISH_TIME             (secs_to_jiffies(10*60))
+#define SHARPSL_BATCHK_TIME                    (secs_to_jiffies(15))
+#define SHARPSL_BATCHK_TIME_SUSPEND            (60*10) /* 10 min */
 
 #define SHARPSL_WAIT_CO_TIME                   15  /* 15 sec */
 #define SHARPSL_WAIT_DISCHARGE_ON              100 /* 100 msec */

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:02:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:02:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853116.1266665 (Exim 4.92)
	(envelope-from )
	id 1tL8JW-00020M-8e; Tue, 10 Dec 2024 22:02:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853116.1266665; Tue, 10 Dec 2024 22:02: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 1tL8JW-0001zQ-2y; Tue, 10 Dec 2024 22:02:42 +0000
Received: by outflank-mailman (input) for mailman id 853116;
 Tue, 10 Dec 2024 22:02: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 1tL8JV-0001x9-5y
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:41 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 77b2fc8f-b742-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 23:02:37 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id 5C8092047227;
 Tue, 10 Dec 2024 14:02: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: 77b2fc8f-b742-11ef-99a3-01e77a169b0f
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 5C8092047227
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868156;
	bh=3tkOAM1zqG9JeFOtral7Lfs9u46U15/2RBF6sWmMcg4=;
	h=From:Subject:Date:To:Cc:From;
	b=Q4SOEP0Y7h5zO78UBiHUhYnGicCTwnpmdGyeJ2NXra3aSgp4pliiNVajI48sltiC5
	 krxOdne8IbeYxRwBBWcjRMbkm4dRwXWKZALmzr8Eqfc6Ado8XqXrVleqMCFQbV/jTu
	 DEly4DyEWnbV/UU33Q7NVotbdGyJFxTE5SxdsOl8=
From: Easwar Hariharan 
Subject: [PATCH v3 00/19] Converge on using secs_to_jiffies()
Date: Tue, 10 Dec 2024 22:02:31 +0000
Message-Id: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-B4-Tracking: v=1; b=H4sIAHe6WGcC/42NwQ6CMBAFf4X0bAlbQFJP/ofxAO1W1ijVFhoM4
 d8tGONFE49vkjczMY+O0LNdMjGHgTzZLo58kzDV1t0JOem4mchEAQCCK9sFdJF7VJ73lp/JmGj
 gWkoNGWwbDcDi/ebQ0LiqD8fXdngfYqH/wJZ8b91jzQdY6LtU/i4F4BkHWdda5YUsoNlfqBvG9
 ErKWW9Nnyp7ZYs+iH+VIiolgGmqUpZYye/KeZ6fTjplmTIBAAA=
X-Change-ID: 20241112-converge-secs-to-jiffies-d99d1016bd11
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan , 
 Jeff Johnson 
X-Mailer: b4 0.14.2

This is a series that follows up on my previous series to introduce
secs_to_jiffies() and convert a few initial users.[1] In the review for
that series, Anna-Maria requested converting other users with
Coccinelle. [2] This is part 1 that converts users of msecs_to_jiffies()
that use the multiply pattern of either of:
- msecs_to_jiffies(N*1000), or
- msecs_to_jiffies(N*MSEC_PER_SEC)

where N is a constant, to avoid the multiplication.

The entire conversion is made with Coccinelle in the script added in
patch 2. Some changes suggested by Coccinelle have been deferred to
later parts that will address other possible variant patterns.

CC: Anna-Maria Behnsen 
Signed-off-by: Easwar Hariharan 

[1] https://lore.kernel.org/all/20241030-open-coded-timeouts-v3-0-9ba123facf88@linux.microsoft.com/
[2] https://lore.kernel.org/all/8734kngfni.fsf@somnus/

---
Changes in v3:
- Rebase on next-20241210
- Fix typo'ed timeout in net/netfilter/nf_conntrack_proto_sctp.c (Stephen Rothwell)
- Use Coccinelle operation modes for Coccinelle script (Markus Elfring)
- Remove redundant comments in arch/arm/mach-pxa/sharpsl_pm.c
  (Christophe Leroy)
- Remove excess line breaks (Heiko Carstens, Christophe Leroy)
- Add more detail into the commit messages throughout (Christophe Leroy)
- Pick up Reviewed-by Thomas Hellström for drm/xe
- Drop drm/etnaviv patch already queued into etnaviv/next
- Replace call to [m]secs_to_jiffies(0) with just 0 for livepatch (Dan
  Carpenter, Christophe Leroy)
- Split out nfp patch to send to net-next (Christophe Leroy)
- Pick up Acked-by from Jeff Johnson for ath11k
- Link to v2: https://lore.kernel.org/r/20241115-converge-secs-to-jiffies-v2-0-911fb7595e79@linux.microsoft.com
Changes in v2:
- Exclude already accepted patch adding secs_to_jiffies() https://git.kernel.org/tip/b35108a51cf7bab58d7eace1267d7965978bcdb8
- Link to v1: https://lore.kernel.org/r/20241115-converge-secs-to-jiffies-v1-0-19aadc34941b@linux.microsoft.com

---
Easwar Hariharan (19):
      netfilter: conntrack: Cleanup timeout definitions
      coccinelle: misc: Add secs_to_jiffies script
      arm: pxa: Convert timeouts to use secs_to_jiffies()
      s390: kernel: Convert timeouts to use secs_to_jiffies()
      powerpc/papr_scm: Convert timeouts to secs_to_jiffies()
      mm: kmemleak: Convert timeouts to secs_to_jiffies()
      accel/habanalabs: Convert timeouts to secs_to_jiffies()
      drm/xe: Convert timeout to secs_to_jiffies()
      scsi: lpfc: Convert timeouts to secs_to_jiffies()
      scsi: arcmsr: Convert timeouts to secs_to_jiffies()
      scsi: pm8001: Convert timeouts to secs_to_jiffies()
      xen/blkback: Convert timeouts to secs_to_jiffies()
      gve: Convert timeouts to secs_to_jiffies()
      wifi: ath11k: Convert timeouts to secs_to_jiffies()
      Bluetooth: MGMT: Convert timeouts to secs_to_jiffies()
      staging: vc04_services: Convert timeouts to secs_to_jiffies()
      ceph: Convert timeouts to secs_to_jiffies()
      livepatch: Convert timeouts to secs_to_jiffies()
      ALSA: line6: Convert timeouts to secs_to_jiffies()

 arch/arm/mach-pxa/sharpsl_pm.c                     |  8 ++++----
 arch/powerpc/platforms/pseries/papr_scm.c          |  2 +-
 arch/s390/kernel/lgr.c                             |  2 +-
 arch/s390/kernel/time.c                            |  4 ++--
 arch/s390/kernel/topology.c                        |  2 +-
 drivers/accel/habanalabs/common/device.c           |  2 +-
 drivers/accel/habanalabs/common/habanalabs_drv.c   |  3 +--
 drivers/block/xen-blkback/blkback.c                |  2 +-
 drivers/gpu/drm/xe/xe_device.c                     |  2 +-
 drivers/net/ethernet/google/gve/gve_tx_dqo.c       |  6 ++----
 drivers/net/wireless/ath/ath11k/debugfs.c          |  2 +-
 drivers/scsi/arcmsr/arcmsr_hba.c                   |  2 +-
 drivers/scsi/lpfc/lpfc_init.c                      | 18 +++++++++---------
 drivers/scsi/lpfc/lpfc_nportdisc.c                 |  8 ++++----
 drivers/scsi/lpfc/lpfc_nvme.c                      |  2 +-
 drivers/scsi/lpfc/lpfc_sli.c                       |  4 ++--
 drivers/scsi/lpfc/lpfc_vmid.c                      |  2 +-
 drivers/scsi/pm8001/pm8001_init.c                  |  2 +-
 .../vc04_services/bcm2835-audio/bcm2835-vchiq.c    |  2 +-
 fs/ceph/quota.c                                    |  2 +-
 mm/kmemleak.c                                      |  4 ++--
 net/bluetooth/mgmt.c                               |  2 +-
 net/netfilter/nf_conntrack_proto_sctp.c            | 21 ++++++++-------------
 samples/livepatch/livepatch-callbacks-busymod.c    |  3 +--
 samples/livepatch/livepatch-shadow-fix1.c          |  3 +--
 samples/livepatch/livepatch-shadow-mod.c           | 15 +++++----------
 scripts/coccinelle/misc/secs_to_jiffies.cocci      | 22 ++++++++++++++++++++++
 sound/usb/line6/toneport.c                         |  2 +-
 28 files changed, 78 insertions(+), 71 deletions(-)
---
base-commit: 1b2ab8149928c1cea2d7eca30cd35bb7fe014053
change-id: 20241112-converge-secs-to-jiffies-d99d1016bd11

Best regards,
-- 
Easwar Hariharan 



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:02:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:02:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853120.1266704 (Exim 4.92)
	(envelope-from )
	id 1tL8JY-0002u4-T6; Tue, 10 Dec 2024 22:02:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853120.1266704; Tue, 10 Dec 2024 22:02: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 1tL8JY-0002sE-Jq; Tue, 10 Dec 2024 22:02:44 +0000
Received: by outflank-mailman (input) for mailman id 853120;
 Tue, 10 Dec 2024 22:02: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 1tL8JW-0001xA-Lc
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:42 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 79dbf702-b742-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 23:02:41 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id 7A91220BCAD0;
 Tue, 10 Dec 2024 14:02: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: 79dbf702-b742-11ef-a0d5-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 7A91220BCAD0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868157;
	bh=0JE1mCMNDTStNy3f4QrS8yzg/qXwB8sbyOMa5sLnc+M=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
	b=YCfQzuzz84XSOxCFulDwBJMyeJsDcssJlAQbcNcDqVlVY42CJOIL+UK9ammaKlGe+
	 y0+S9QnHRdg/p6H9mSyPRo+qXk+3dcsFcITb9kFGHGdUIwdzitxdUdxS6Zxb9FQSzr
	 04JqDqdWTuFBsk1ZmtqL88EM/bwJOE39+Tw6Eck4=
From: Easwar Hariharan 
Date: Tue, 10 Dec 2024 22:02:37 +0000
Subject: [PATCH v3 06/19] mm: kmemleak: Convert timeouts to
 secs_to_jiffies()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20241210-converge-secs-to-jiffies-v3-6-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan 
X-Mailer: b4 0.14.2

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan 
---
 mm/kmemleak.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 2a945c07ae99525815c8fb733e8eb1b4da60668e..a2ded75cc0c03838bc048c82990c8524f25549b6 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1855,7 +1855,7 @@ static int kmemleak_scan_thread(void *arg)
 	 * Wait before the first scan to allow the system to fully initialize.
 	 */
 	if (first_run) {
-		signed long timeout = msecs_to_jiffies(SECS_FIRST_SCAN * 1000);
+		signed long timeout = secs_to_jiffies(SECS_FIRST_SCAN);
 		first_run = 0;
 		while (timeout && !kthread_should_stop())
 			timeout = schedule_timeout_interruptible(timeout);
@@ -2241,7 +2241,7 @@ void __init kmemleak_init(void)
 		return;
 
 	jiffies_min_age = msecs_to_jiffies(MSECS_MIN_AGE);
-	jiffies_scan_wait = msecs_to_jiffies(SECS_SCAN_WAIT * 1000);
+	jiffies_scan_wait = secs_to_jiffies(SECS_SCAN_WAIT);
 
 	object_cache = KMEM_CACHE(kmemleak_object, SLAB_NOLEAKTRACE);
 	scan_area_cache = KMEM_CACHE(kmemleak_scan_area, SLAB_NOLEAKTRACE);

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:02:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:02:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853117.1266671 (Exim 4.92)
	(envelope-from )
	id 1tL8JW-00024e-IH; Tue, 10 Dec 2024 22:02:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853117.1266671; Tue, 10 Dec 2024 22:02: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 1tL8JW-00021l-9n; Tue, 10 Dec 2024 22:02:42 +0000
Received: by outflank-mailman (input) for mailman id 853117;
 Tue, 10 Dec 2024 22:02: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 1tL8JV-0001x9-Cp
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:41 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 77f8bf7b-b742-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 23:02:38 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id 8EC1F2047228;
 Tue, 10 Dec 2024 14:02: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: 77f8bf7b-b742-11ef-99a3-01e77a169b0f
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 8EC1F2047228
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868156;
	bh=oAoRcxFx6r3qiWDnRBBsiLzbuwo4yEAyTzO1K822O7I=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
	b=U3VeWMEj1NoccyfU44IlXr+eH+dIb+Y1FX88FHYXU4q03PECflKzMMc2KhmQfWdxA
	 2LtcSsTBowp5J1k4JjK8tQOvB5yIwMjDbVNHxvHTREwcCEJZMCYyv+0rZVYLLCY+lW
	 lVwyzMWVt2MunqqkcT6KDTr1TpTutKDRbWdkcUjw=
From: Easwar Hariharan 
Date: Tue, 10 Dec 2024 22:02:32 +0000
Subject: [PATCH v3 01/19] netfilter: conntrack: Cleanup timeout definitions
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20241210-converge-secs-to-jiffies-v3-1-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan 
X-Mailer: b4 0.14.2

None of the higher order definitions are used anymore, so remove
definitions for minutes, hours, and days timeouts. Convert the seconds
denominated timeouts to secs_to_jiffies()

Signed-off-by: Easwar Hariharan 
---
 net/netfilter/nf_conntrack_proto_sctp.c | 21 ++++++++-------------
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/net/netfilter/nf_conntrack_proto_sctp.c b/net/netfilter/nf_conntrack_proto_sctp.c
index 4cc97f971264ed779434ab4597dd0162586b3736..7c6f7c9f73320dd208bd0940f539bd9e662e62d0 100644
--- a/net/netfilter/nf_conntrack_proto_sctp.c
+++ b/net/netfilter/nf_conntrack_proto_sctp.c
@@ -39,20 +39,15 @@ static const char *const sctp_conntrack_names[] = {
 	[SCTP_CONNTRACK_HEARTBEAT_SENT]		= "HEARTBEAT_SENT",
 };
 
-#define SECS  * HZ
-#define MINS  * 60 SECS
-#define HOURS * 60 MINS
-#define DAYS  * 24 HOURS
-
 static const unsigned int sctp_timeouts[SCTP_CONNTRACK_MAX] = {
-	[SCTP_CONNTRACK_CLOSED]			= 10 SECS,
-	[SCTP_CONNTRACK_COOKIE_WAIT]		= 3 SECS,
-	[SCTP_CONNTRACK_COOKIE_ECHOED]		= 3 SECS,
-	[SCTP_CONNTRACK_ESTABLISHED]		= 210 SECS,
-	[SCTP_CONNTRACK_SHUTDOWN_SENT]		= 3 SECS,
-	[SCTP_CONNTRACK_SHUTDOWN_RECD]		= 3 SECS,
-	[SCTP_CONNTRACK_SHUTDOWN_ACK_SENT]	= 3 SECS,
-	[SCTP_CONNTRACK_HEARTBEAT_SENT]		= 30 SECS,
+	[SCTP_CONNTRACK_CLOSED]			= secs_to_jiffies(10),
+	[SCTP_CONNTRACK_COOKIE_WAIT]		= secs_to_jiffies(3),
+	[SCTP_CONNTRACK_COOKIE_ECHOED]		= secs_to_jiffies(3),
+	[SCTP_CONNTRACK_ESTABLISHED]		= secs_to_jiffies(210),
+	[SCTP_CONNTRACK_SHUTDOWN_SENT]		= secs_to_jiffies(3),
+	[SCTP_CONNTRACK_SHUTDOWN_RECD]		= secs_to_jiffies(3),
+	[SCTP_CONNTRACK_SHUTDOWN_ACK_SENT]	= secs_to_jiffies(3),
+	[SCTP_CONNTRACK_HEARTBEAT_SENT]		= secs_to_jiffies(30),
 };
 
 #define	SCTP_FLAG_HEARTBEAT_VTAG_FAILED	1

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:02:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:02:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853119.1266695 (Exim 4.92)
	(envelope-from )
	id 1tL8JY-0002gM-5r; Tue, 10 Dec 2024 22:02:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853119.1266695; Tue, 10 Dec 2024 22:02: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 1tL8JY-0002fu-0m; Tue, 10 Dec 2024 22:02:44 +0000
Received: by outflank-mailman (input) for mailman id 853119;
 Tue, 10 Dec 2024 22:02: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 1tL8JW-0001x9-4H
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:42 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 783d496d-b742-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 23:02:38 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id B8E722047229;
 Tue, 10 Dec 2024 14:02: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: 783d496d-b742-11ef-99a3-01e77a169b0f
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com B8E722047229
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868156;
	bh=p+8g58BSBlt5b8YhFCU18nddw3DZx2oHU0RyK/mdTxg=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
	b=D0ztEAtB7CqvQGSZsYp+tRN4xkI1U+Pf0qGPT6ILcEXORWxv5WkL8NhY8sec+1ep2
	 o0YIUC89qlYyBwdj7sp7PypSXEaSKBYajv+HMKS2o/OP0mphIdTsuM5S4VkeWurXmd
	 SYBz6bHa118hfuIgWOgwAoVQLPZwu51P6o2dfTvU=
From: Easwar Hariharan 
Date: Tue, 10 Dec 2024 22:02:33 +0000
Subject: [PATCH v3 02/19] coccinelle: misc: Add secs_to_jiffies script
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20241210-converge-secs-to-jiffies-v3-2-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan 
X-Mailer: b4 0.14.2

This script finds and suggests conversions of timeout patterns that
result in seconds-denominated timeouts to use the new secs_to_jiffies()
API in include/linux/jiffies.h for better readability.

Suggested-by: Anna-Maria Behnsen 
Signed-off-by: Easwar Hariharan 
---
 scripts/coccinelle/misc/secs_to_jiffies.cocci | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/scripts/coccinelle/misc/secs_to_jiffies.cocci b/scripts/coccinelle/misc/secs_to_jiffies.cocci
new file mode 100644
index 0000000000000000000000000000000000000000..8bbb2884ea5db939c63fd4513cf5ca8c977aa8cb
--- /dev/null
+++ b/scripts/coccinelle/misc/secs_to_jiffies.cocci
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-only
+///
+/// Find usages of:
+/// - msecs_to_jiffies(value*1000)
+/// - msecs_to_jiffies(value*MSEC_PER_SEC)
+///
+// Confidence: High
+// Copyright: (C) 2024 Easwar Hariharan, Microsoft
+// Keywords: secs, seconds, jiffies
+//
+
+virtual patch
+
+@depends on patch@ constant C; @@
+
+- msecs_to_jiffies(C * 1000)
++ secs_to_jiffies(C)
+
+@depends on patch@ constant C; @@
+
+- msecs_to_jiffies(C * MSEC_PER_SEC)
++ secs_to_jiffies(C)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:02:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:02:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853124.1266739 (Exim 4.92)
	(envelope-from )
	id 1tL8Jb-0003j5-O4; Tue, 10 Dec 2024 22:02:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853124.1266739; Tue, 10 Dec 2024 22: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 1tL8Jb-0003hX-Da; Tue, 10 Dec 2024 22:02:47 +0000
Received: by outflank-mailman (input) for mailman id 853124;
 Tue, 10 Dec 2024 22:02: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 1tL8JZ-0001xA-MY
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:45 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 7adbea83-b742-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 23:02:43 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id 102E5204722E;
 Tue, 10 Dec 2024 14:02:38 -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: 7adbea83-b742-11ef-a0d5-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 102E5204722E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868158;
	bh=4PsoF6SsPfbe/epEx07m/H71eMXFwTragWU3TWb95lc=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
	b=h7xNg+CJMXTd5DQ9X3jMinLoN7vSFDg8Wc8ctVRvzEZXRU6zr2IuGvATvzcH5C5mv
	 8tZpWnxa3guMlnaHImjL8p97Vyif6Q4iPn6nrKcU0WRTq12Y7YJw/78q0d2IIYZwV/
	 HU4b3GuDdaH6l3YJ/3viq/heQZ5TTvrnm5sB3x44=
From: Easwar Hariharan 
Date: Tue, 10 Dec 2024 22:02:40 +0000
Subject: [PATCH v3 09/19] scsi: lpfc: Convert timeouts to secs_to_jiffies()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20241210-converge-secs-to-jiffies-v3-9-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan 
X-Mailer: b4 0.14.2

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan 
---
 drivers/scsi/lpfc/lpfc_init.c      | 18 +++++++++---------
 drivers/scsi/lpfc/lpfc_nportdisc.c |  8 ++++----
 drivers/scsi/lpfc/lpfc_nvme.c      |  2 +-
 drivers/scsi/lpfc/lpfc_sli.c       |  4 ++--
 drivers/scsi/lpfc/lpfc_vmid.c      |  2 +-
 5 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 7f57397d91a90d8fea689a6d095c30c974fd63f6..4fed2e1243e05896c7e67902b6a9924bed1a5ea9 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -598,7 +598,7 @@ lpfc_config_port_post(struct lpfc_hba *phba)
 		  jiffies + msecs_to_jiffies(1000 * timeout));
 	/* Set up heart beat (HB) timer */
 	mod_timer(&phba->hb_tmofunc,
-		  jiffies + msecs_to_jiffies(1000 * LPFC_HB_MBOX_INTERVAL));
+		  jiffies + secs_to_jiffies(LPFC_HB_MBOX_INTERVAL));
 	clear_bit(HBA_HBEAT_INP, &phba->hba_flag);
 	clear_bit(HBA_HBEAT_TMO, &phba->hba_flag);
 	phba->last_completion_time = jiffies;
@@ -1267,7 +1267,7 @@ lpfc_hb_mbox_cmpl(struct lpfc_hba * phba, LPFC_MBOXQ_t * pmboxq)
 	    !test_bit(FC_UNLOADING, &phba->pport->load_flag))
 		mod_timer(&phba->hb_tmofunc,
 			  jiffies +
-			  msecs_to_jiffies(1000 * LPFC_HB_MBOX_INTERVAL));
+			  secs_to_jiffies(LPFC_HB_MBOX_INTERVAL));
 	return;
 }
 
@@ -1555,7 +1555,7 @@ lpfc_hb_timeout_handler(struct lpfc_hba *phba)
 		/* If IOs are completing, no need to issue a MBX_HEARTBEAT */
 		spin_lock_irq(&phba->pport->work_port_lock);
 		if (time_after(phba->last_completion_time +
-				msecs_to_jiffies(1000 * LPFC_HB_MBOX_INTERVAL),
+				secs_to_jiffies(LPFC_HB_MBOX_INTERVAL),
 				jiffies)) {
 			spin_unlock_irq(&phba->pport->work_port_lock);
 			if (test_bit(HBA_HBEAT_INP, &phba->hba_flag))
@@ -3354,7 +3354,7 @@ lpfc_block_mgmt_io(struct lpfc_hba *phba, int mbx_action)
 	spin_unlock_irqrestore(&phba->hbalock, iflag);
 	if (mbx_action == LPFC_MBX_NO_WAIT)
 		return;
-	timeout = msecs_to_jiffies(LPFC_MBOX_TMO * 1000) + jiffies;
+	timeout = secs_to_jiffies(LPFC_MBOX_TMO) + jiffies;
 	spin_lock_irqsave(&phba->hbalock, iflag);
 	if (phba->sli.mbox_active) {
 		actcmd = phba->sli.mbox_active->u.mb.mbxCommand;
@@ -4924,14 +4924,14 @@ int lpfc_scan_finished(struct Scsi_Host *shost, unsigned long time)
 		stat = 1;
 		goto finished;
 	}
-	if (time >= msecs_to_jiffies(30 * 1000)) {
+	if (time >= secs_to_jiffies(30)) {
 		lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
 				"0461 Scanning longer than 30 "
 				"seconds.  Continuing initialization\n");
 		stat = 1;
 		goto finished;
 	}
-	if (time >= msecs_to_jiffies(15 * 1000) &&
+	if (time >= secs_to_jiffies(15) &&
 	    phba->link_state <= LPFC_LINK_DOWN) {
 		lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
 				"0465 Link down longer than 15 "
@@ -4945,7 +4945,7 @@ int lpfc_scan_finished(struct Scsi_Host *shost, unsigned long time)
 	if (vport->num_disc_nodes || vport->fc_prli_sent)
 		goto finished;
 	if (!atomic_read(&vport->fc_map_cnt) &&
-	    time < msecs_to_jiffies(2 * 1000))
+	    time < secs_to_jiffies(2))
 		goto finished;
 	if ((phba->sli.sli_flag & LPFC_SLI_MBOX_ACTIVE) != 0)
 		goto finished;
@@ -5179,8 +5179,8 @@ lpfc_vmid_poll(struct timer_list *t)
 		lpfc_worker_wake_up(phba);
 
 	/* restart the timer for the next iteration */
-	mod_timer(&phba->inactive_vmid_poll, jiffies + msecs_to_jiffies(1000 *
-							LPFC_VMID_TIMER));
+	mod_timer(&phba->inactive_vmid_poll,
+		  jiffies + secs_to_jiffies(LPFC_VMID_TIMER));
 }
 
 /**
diff --git a/drivers/scsi/lpfc/lpfc_nportdisc.c b/drivers/scsi/lpfc/lpfc_nportdisc.c
index 4d88cfe71caed398d376030c9ae06d3aad6ae00c..08a7f5c6157ff984d6e37751ca5398adbf80b607 100644
--- a/drivers/scsi/lpfc/lpfc_nportdisc.c
+++ b/drivers/scsi/lpfc/lpfc_nportdisc.c
@@ -906,7 +906,7 @@ lpfc_rcv_logo(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp,
 		    (ndlp->nlp_state >= NLP_STE_ADISC_ISSUE ||
 		     ndlp->nlp_state <= NLP_STE_PRLI_ISSUE)) {
 			mod_timer(&ndlp->nlp_delayfunc,
-				  jiffies + msecs_to_jiffies(1000 * 1));
+				  jiffies + secs_to_jiffies(1));
 			set_bit(NLP_DELAY_TMO, &ndlp->nlp_flag);
 			ndlp->nlp_last_elscmd = ELS_CMD_PLOGI;
 			lpfc_printf_vlog(vport, KERN_INFO,
@@ -1332,7 +1332,7 @@ lpfc_rcv_els_plogi_issue(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp,
 	}
 
 	/* Put ndlp in npr state set plogi timer for 1 sec */
-	mod_timer(&ndlp->nlp_delayfunc, jiffies + msecs_to_jiffies(1000 * 1));
+	mod_timer(&ndlp->nlp_delayfunc, jiffies + secs_to_jiffies(1));
 	set_bit(NLP_DELAY_TMO, &ndlp->nlp_flag);
 	ndlp->nlp_last_elscmd = ELS_CMD_PLOGI;
 	ndlp->nlp_prev_state = NLP_STE_PLOGI_ISSUE;
@@ -1936,7 +1936,7 @@ lpfc_cmpl_reglogin_reglogin_issue(struct lpfc_vport *vport,
 
 		/* Put ndlp in npr state set plogi timer for 1 sec */
 		mod_timer(&ndlp->nlp_delayfunc,
-			  jiffies + msecs_to_jiffies(1000 * 1));
+			  jiffies + secs_to_jiffies(1));
 		set_bit(NLP_DELAY_TMO, &ndlp->nlp_flag);
 		ndlp->nlp_last_elscmd = ELS_CMD_PLOGI;
 
@@ -2743,7 +2743,7 @@ lpfc_rcv_prlo_npr_node(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp,
 
 	if (!test_bit(NLP_DELAY_TMO, &ndlp->nlp_flag)) {
 		mod_timer(&ndlp->nlp_delayfunc,
-			  jiffies + msecs_to_jiffies(1000 * 1));
+			  jiffies + secs_to_jiffies(1));
 		set_bit(NLP_DELAY_TMO, &ndlp->nlp_flag);
 		clear_bit(NLP_NPR_ADISC, &ndlp->nlp_flag);
 		ndlp->nlp_last_elscmd = ELS_CMD_PLOGI;
diff --git a/drivers/scsi/lpfc/lpfc_nvme.c b/drivers/scsi/lpfc/lpfc_nvme.c
index 43dc1da4a1567c05d6ac5f8bda19032737998e64..b1adb9f59097d083a3ae24f4ddf6413350a0368d 100644
--- a/drivers/scsi/lpfc/lpfc_nvme.c
+++ b/drivers/scsi/lpfc/lpfc_nvme.c
@@ -2237,7 +2237,7 @@ lpfc_nvme_lport_unreg_wait(struct lpfc_vport *vport,
 	 * wait. Print a message if a 10 second wait expires and renew the
 	 * wait. This is unexpected.
 	 */
-	wait_tmo = msecs_to_jiffies(LPFC_NVME_WAIT_TMO * 1000);
+	wait_tmo = secs_to_jiffies(LPFC_NVME_WAIT_TMO);
 	while (true) {
 		ret = wait_for_completion_timeout(lport_unreg_cmp, wait_tmo);
 		if (unlikely(!ret)) {
diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index 874644b31a3ebd815d5bf55bc4b3464c94d9cfa6..3fd9723cd271c8a024b6f34e583668e973404e6f 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -9012,7 +9012,7 @@ lpfc_sli4_hba_setup(struct lpfc_hba *phba)
 
 	/* Start heart beat timer */
 	mod_timer(&phba->hb_tmofunc,
-		  jiffies + msecs_to_jiffies(1000 * LPFC_HB_MBOX_INTERVAL));
+		  jiffies + secs_to_jiffies(LPFC_HB_MBOX_INTERVAL));
 	clear_bit(HBA_HBEAT_INP, &phba->hba_flag);
 	clear_bit(HBA_HBEAT_TMO, &phba->hba_flag);
 	phba->last_completion_time = jiffies;
@@ -13323,7 +13323,7 @@ lpfc_sli_mbox_sys_shutdown(struct lpfc_hba *phba, int mbx_action)
 		lpfc_sli_mbox_sys_flush(phba);
 		return;
 	}
-	timeout = msecs_to_jiffies(LPFC_MBOX_TMO * 1000) + jiffies;
+	timeout = secs_to_jiffies(LPFC_MBOX_TMO) + jiffies;
 
 	/* Disable softirqs, including timers from obtaining phba->hbalock */
 	local_bh_disable();
diff --git a/drivers/scsi/lpfc/lpfc_vmid.c b/drivers/scsi/lpfc/lpfc_vmid.c
index cc3e4736f2fe29e1fd4afe221c9c7c40ecf382d4..14dbfe954e423acc47d1b1c80160ff193783f500 100644
--- a/drivers/scsi/lpfc/lpfc_vmid.c
+++ b/drivers/scsi/lpfc/lpfc_vmid.c
@@ -278,7 +278,7 @@ int lpfc_vmid_get_appid(struct lpfc_vport *vport, char *uuid,
 		if (!(vport->phba->pport->vmid_flag & LPFC_VMID_TIMER_ENBLD)) {
 			mod_timer(&vport->phba->inactive_vmid_poll,
 				  jiffies +
-				  msecs_to_jiffies(1000 * LPFC_VMID_TIMER));
+				  secs_to_jiffies(LPFC_VMID_TIMER));
 			vport->phba->pport->vmid_flag |= LPFC_VMID_TIMER_ENBLD;
 		}
 	}

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:02:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:02:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853121.1266710 (Exim 4.92)
	(envelope-from )
	id 1tL8JZ-0002zE-9Z; Tue, 10 Dec 2024 22:02:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853121.1266710; Tue, 10 Dec 2024 22:02: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 1tL8JZ-0002yF-1O; Tue, 10 Dec 2024 22:02:45 +0000
Received: by outflank-mailman (input) for mailman id 853121;
 Tue, 10 Dec 2024 22:02: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 1tL8JX-0001x9-4M
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:43 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 797fbd87-b742-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 23:02:40 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id 4B3EA204722C;
 Tue, 10 Dec 2024 14:02: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: 797fbd87-b742-11ef-99a3-01e77a169b0f
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 4B3EA204722C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868157;
	bh=pNf1urZZ7beXITMyG6cNpTQM4ujE/reyCjI7dxR8TrA=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
	b=ey2u4hFur56upsg36Bzzf5E6sp9TxIQJWauHtVHyZKWxl2TYAXbOMES9gB/LrtTHt
	 EMIcdvfnDr4nFfA+fPKgnRb6wrIZBNFQYmxUUa3IOMgJ6rbLPy51pP+s0wIlgpVbyY
	 W7PI6jGCodUt7pK+WAXoxoZrhQg9ZJ/5kGvj+4iw=
From: Easwar Hariharan 
Date: Tue, 10 Dec 2024 22:02:36 +0000
Subject: [PATCH v3 05/19] powerpc/papr_scm: Convert timeouts to
 secs_to_jiffies()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20241210-converge-secs-to-jiffies-v3-5-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan 
X-Mailer: b4 0.14.2

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan 
---
 arch/powerpc/platforms/pseries/papr_scm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index f84ac9fbe203c111046464b9100866dddae687bb..f7c9271bda58433f395648063e60409a8d3c11d9 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -544,7 +544,7 @@ static int drc_pmem_query_health(struct papr_scm_priv *p)
 
 	/* Jiffies offset for which the health data is assumed to be same */
 	cache_timeout = p->lasthealth_jiffies +
-		msecs_to_jiffies(MIN_HEALTH_QUERY_INTERVAL * 1000);
+		secs_to_jiffies(MIN_HEALTH_QUERY_INTERVAL);
 
 	/* Fetch new health info is its older than MIN_HEALTH_QUERY_INTERVAL */
 	if (time_after(jiffies, cache_timeout))

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:02:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:02:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853127.1266752 (Exim 4.92)
	(envelope-from )
	id 1tL8Jd-0004Bp-No; Tue, 10 Dec 2024 22:02:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853127.1266752; Tue, 10 Dec 2024 22:02: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 1tL8Jd-00049R-Bx; Tue, 10 Dec 2024 22:02:49 +0000
Received: by outflank-mailman (input) for mailman id 853127;
 Tue, 10 Dec 2024 22: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 1tL8Ja-0001xA-Mb
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:46 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 7b3cc5e1-b742-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 23:02:43 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id 40433204722F;
 Tue, 10 Dec 2024 14:02:38 -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: 7b3cc5e1-b742-11ef-a0d5-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 40433204722F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868158;
	bh=BGnsC+198VTSc2YUOR+tnnzodlQEmbpaf1xRkHMeOLA=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
	b=f8FLrazoOSnG7X8aDWVI3nVNlHmQntetz0EU8Jiq9ArRSLgklxjGdYHhwJFkuGOqx
	 IH/VjuOQp54aRZNV03h5piA8Q49loXnKOX2ThzuLLFf9IwCIw5oEVNJs8TgQ/6gM17
	 zOuBTvw2xYfRYO0jrQtMw2wpWhKIeaajYB7zt3gs=
From: Easwar Hariharan 
Date: Tue, 10 Dec 2024 22:02:41 +0000
Subject: [PATCH v3 10/19] scsi: arcmsr: Convert timeouts to
 secs_to_jiffies()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20241210-converge-secs-to-jiffies-v3-10-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan 
X-Mailer: b4 0.14.2

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan 
---
 drivers/scsi/arcmsr/arcmsr_hba.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
index 6a32e3e0d516881fd87a56a394607930582644ee..fe7de7705b7e2c84324f1a493f7825343d6476c6 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -1045,7 +1045,7 @@ static void arcmsr_init_get_devmap_timer(struct AdapterControlBlock *pacb)
 static void arcmsr_init_set_datetime_timer(struct AdapterControlBlock *pacb)
 {
 	timer_setup(&pacb->refresh_timer, arcmsr_set_iop_datetime, 0);
-	pacb->refresh_timer.expires = jiffies + msecs_to_jiffies(60 * 1000);
+	pacb->refresh_timer.expires = jiffies + secs_to_jiffies(60);
 	add_timer(&pacb->refresh_timer);
 }
 

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:02:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:02:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853128.1266759 (Exim 4.92)
	(envelope-from )
	id 1tL8Je-0004LQ-Eu; Tue, 10 Dec 2024 22:02:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853128.1266759; Tue, 10 Dec 2024 22:02: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 1tL8Je-0004JL-3P; Tue, 10 Dec 2024 22:02:50 +0000
Received: by outflank-mailman (input) for mailman id 853128;
 Tue, 10 Dec 2024 22:02: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 1tL8Jb-0001xA-Md
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:47 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 7b9287cf-b742-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 23:02:44 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id 6FF4C2047230;
 Tue, 10 Dec 2024 14:02:38 -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: 7b9287cf-b742-11ef-a0d5-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 6FF4C2047230
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868158;
	bh=U++D0WKRUcBPTXKKmA8ay83+fBnoO24djfuDhPxnmd0=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
	b=i9DsTNH+sl/IoEAtSjlSJHTOE30TcOTSfxv7yvCJsXzsKYC64wXa+LBK94U2wED8+
	 6hMcKIbUoHeurUTa3oCFtWHdRYvf3LnrkdYUlQGzEUBgp5Wh7dgkbASpnSVSuIShxl
	 Qe59P7FSrX+a5TC/+UUUxnQ63OeNqL5idRg6Tx5c=
From: Easwar Hariharan 
Date: Tue, 10 Dec 2024 22:02:42 +0000
Subject: [PATCH v3 11/19] scsi: pm8001: Convert timeouts to
 secs_to_jiffies()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20241210-converge-secs-to-jiffies-v3-11-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan 
X-Mailer: b4 0.14.2

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan 
---
 drivers/scsi/pm8001/pm8001_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/pm8001/pm8001_init.c b/drivers/scsi/pm8001/pm8001_init.c
index f8c81e53e93f7849bbe7fe9cbc861f22b964bc39..22e0e79e88ab0a60965ff3809de116eb4a6851e2 100644
--- a/drivers/scsi/pm8001/pm8001_init.c
+++ b/drivers/scsi/pm8001/pm8001_init.c
@@ -736,7 +736,7 @@ static int pm8001_init_sas_add(struct pm8001_hba_info *pm8001_ha)
 		return -EIO;
 	}
 	time_remaining = wait_for_completion_timeout(&completion,
-				msecs_to_jiffies(60*1000)); // 1 min
+				secs_to_jiffies(60)); // 1 min
 	if (!time_remaining) {
 		kfree(payload.func_specific);
 		pm8001_dbg(pm8001_ha, FAIL, "get_nvmd_req timeout\n");

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:02:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:02:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853129.1266769 (Exim 4.92)
	(envelope-from )
	id 1tL8Jf-0004Ys-IH; Tue, 10 Dec 2024 22:02:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853129.1266769; Tue, 10 Dec 2024 22:02: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 1tL8Je-0004Rg-OT; Tue, 10 Dec 2024 22:02:50 +0000
Received: by outflank-mailman (input) for mailman id 853129;
 Tue, 10 Dec 2024 22:02: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 1tL8Jc-0001xA-Mk
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:48 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 7c02e4cd-b742-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 23:02:44 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id 9DC932047231;
 Tue, 10 Dec 2024 14:02:38 -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: 7c02e4cd-b742-11ef-a0d5-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 9DC932047231
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868158;
	bh=gKZLAOaJwfAP+6Kmm8Uoact7ay9fLs6b2uIK/ai8VsE=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
	b=svAtqGWUfwwxhkPtOsHM9wFpOe5H7V37CPLpc1efEJB+hZDbAOkD4T5b6sfMzxhZ+
	 yP7ZIp8mBgs9llSr4qUZT5sBXpDyffL9kReLgTxKKh0F7Rks+AtMLKTRz+ik8N0b4l
	 Co5R1xYnpZA/XZN3kdMilWWEgRejdEMkmjUvT5B4=
From: Easwar Hariharan 
Date: Tue, 10 Dec 2024 22:02:43 +0000
Subject: [PATCH v3 12/19] xen/blkback: Convert timeouts to
 secs_to_jiffies()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20241210-converge-secs-to-jiffies-v3-12-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan 
X-Mailer: b4 0.14.2

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan 
---
 drivers/block/xen-blkback/blkback.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 838064593f62b75f3d937c0c041ea78dedbbaf84..a7c2b04ab943de9cbd69b596aad177a0534f7762 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -544,7 +544,7 @@ static void print_stats(struct xen_blkif_ring *ring)
 		 ring->st_rd_req, ring->st_wr_req,
 		 ring->st_f_req, ring->st_ds_req,
 		 ring->persistent_gnt_c, max_pgrants);
-	ring->st_print = jiffies + msecs_to_jiffies(10 * 1000);
+	ring->st_print = jiffies + secs_to_jiffies(10);
 	ring->st_rd_req = 0;
 	ring->st_wr_req = 0;
 	ring->st_oo_req = 0;

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:02:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:02:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853130.1266775 (Exim 4.92)
	(envelope-from )
	id 1tL8Jg-0004nX-56; Tue, 10 Dec 2024 22:02:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853130.1266775; Tue, 10 Dec 2024 22:02: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 1tL8Jf-0004hd-PD; Tue, 10 Dec 2024 22:02:51 +0000
Received: by outflank-mailman (input) for mailman id 853130;
 Tue, 10 Dec 2024 22:02: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 1tL8Jd-0001xA-Mz
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:49 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 7c604f7f-b742-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 23:02:45 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id CC9872047232;
 Tue, 10 Dec 2024 14:02:38 -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: 7c604f7f-b742-11ef-a0d5-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com CC9872047232
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868158;
	bh=Nu1FTDRwT3eJ8G3TZ1SOaVXDK1brjinK2gy4k85VNBc=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
	b=MyS1GphFvmGr2JHW6tyCf5nlmMH9PAcPu/qJOqDicxYHN3ga/E8mPiUpYdOmKe+08
	 ESmMPf61fW9R/vd5fEqw2UI0IyMH9O+5zBGiCitLbR/PLOMP+sV+LtAwK3GV6cBnMZ
	 qMuvwZX6TCbpYuenDC/gzSBNDFt3OVWamZA4/4ys=
From: Easwar Hariharan 
Date: Tue, 10 Dec 2024 22:02:44 +0000
Subject: [PATCH v3 13/19] gve: Convert timeouts to secs_to_jiffies()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20241210-converge-secs-to-jiffies-v3-13-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan 
X-Mailer: b4 0.14.2

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan 
---
 drivers/net/ethernet/google/gve/gve_tx_dqo.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/google/gve/gve_tx_dqo.c b/drivers/net/ethernet/google/gve/gve_tx_dqo.c
index f879426cb5523a7e150f363b5e57b9d472b5817c..394debc62268aadf2579f9b516e045cb48287e7c 100644
--- a/drivers/net/ethernet/google/gve/gve_tx_dqo.c
+++ b/drivers/net/ethernet/google/gve/gve_tx_dqo.c
@@ -1146,8 +1146,7 @@ static void gve_handle_miss_completion(struct gve_priv *priv,
 	/* jiffies can wraparound but time comparisons can handle overflows. */
 	pending_packet->timeout_jiffies =
 			jiffies +
-			msecs_to_jiffies(GVE_REINJECT_COMPL_TIMEOUT *
-					 MSEC_PER_SEC);
+			secs_to_jiffies(GVE_REINJECT_COMPL_TIMEOUT);
 	add_to_list(tx, &tx->dqo_compl.miss_completions, pending_packet);
 
 	*bytes += pending_packet->skb->len;
@@ -1191,8 +1190,7 @@ static void remove_miss_completions(struct gve_priv *priv,
 		pending_packet->state = GVE_PACKET_STATE_TIMED_OUT_COMPL;
 		pending_packet->timeout_jiffies =
 				jiffies +
-				msecs_to_jiffies(GVE_DEALLOCATE_COMPL_TIMEOUT *
-						 MSEC_PER_SEC);
+				secs_to_jiffies(GVE_DEALLOCATE_COMPL_TIMEOUT);
 		/* Maintain pending packet in another list so the packet can be
 		 * unallocated at a later time.
 		 */

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:10:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:10:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853203.1266800 (Exim 4.92)
	(envelope-from )
	id 1tL8R3-00022Y-73; Tue, 10 Dec 2024 22:10:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853203.1266800; Tue, 10 Dec 2024 22:10:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tL8R3-00022R-4I; Tue, 10 Dec 2024 22:10:29 +0000
Received: by outflank-mailman (input) for mailman id 853203;
 Tue, 10 Dec 2024 22:10: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 1tL8Jg-0001xA-NQ
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:52 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 7db198bb-b742-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 23:02:47 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id 6531B20ACD6B;
 Tue, 10 Dec 2024 14:02: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: 7db198bb-b742-11ef-a0d5-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 6531B20ACD6B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868159;
	bh=bkW4y6ENFXKRD3xTlI1AhDo8V7CjSAjUn/pFIvR2ry8=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
	b=dOK8RnNQMEEDnIPfeOf2mTH3/slP0EgBsz1RphSjHbLnDrQKEVkY9HcyDwOhMk5R6
	 eaO83rvpJomkJuzNdNBxnuRf37TDgqADuidRQb6NchFG64SiUCMfdU7nMnXJqoCbUe
	 LiFzIadqv43ZC7HtDm7c2pnyXRduc6YAQ9XNwlB0=
From: Easwar Hariharan 
Date: Tue, 10 Dec 2024 22:02:47 +0000
Subject: [PATCH v3 16/19] staging: vc04_services: Convert timeouts to
 secs_to_jiffies()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20241210-converge-secs-to-jiffies-v3-16-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan 
X-Mailer: b4 0.14.2

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan 
---
 drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
index dc0d715ed97078ad0f0a41db78428db4f4135a76..0dbe76ee557032d7861acfc002cc203ff2e6971d 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
@@ -59,7 +59,7 @@ static int bcm2835_audio_send_msg_locked(struct bcm2835_audio_instance *instance
 
 	if (wait) {
 		if (!wait_for_completion_timeout(&instance->msg_avail_comp,
-						 msecs_to_jiffies(10 * 1000))) {
+						 secs_to_jiffies(10))) {
 			dev_err(instance->dev,
 				"vchi message timeout, msg=%d\n", m->type);
 			return -ETIMEDOUT;

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:11:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:11:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853247.1266809 (Exim 4.92)
	(envelope-from )
	id 1tL8Rw-0003In-I2; Tue, 10 Dec 2024 22:11:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853247.1266809; Tue, 10 Dec 2024 22:11: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 1tL8Rw-0003Ig-FR; Tue, 10 Dec 2024 22:11:24 +0000
Received: by outflank-mailman (input) for mailman id 853247;
 Tue, 10 Dec 2024 22:11: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 1tL8Jk-0001xA-OT
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:56 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 7eb6107b-b742-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 23:02:49 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id F1ABA20ACD6F;
 Tue, 10 Dec 2024 14:02: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: 7eb6107b-b742-11ef-a0d5-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com F1ABA20ACD6F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868160;
	bh=zXBBaQqpACacMQS0Kj7gcrwl6nw/WBuJMa6i20JWtiI=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
	b=Vt8vx6jKTs+Ctim/qcZbBmxzvKglLplBaf8u3Ss1TuSPMlqyDk6c0iiPlA+LzR+m0
	 YPZ/Qdi+1XcZwtu1UmEnzASc3HPTGQ/HgM/xmF7CmRGYf/aXx12mOKI6ka1aNTAUbz
	 /gGdJ/+VOZh0/gOcfBkHqPOaIC1SiZYddw+BwdBw=
From: Easwar Hariharan 
Date: Tue, 10 Dec 2024 22:02:50 +0000
Subject: [PATCH v3 19/19] ALSA: line6: Convert timeouts to
 secs_to_jiffies()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20241210-converge-secs-to-jiffies-v3-19-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan 
X-Mailer: b4 0.14.2

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan 
---
 sound/usb/line6/toneport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/usb/line6/toneport.c b/sound/usb/line6/toneport.c
index ca2c6f5de407ece21ab69a39ed603e3f10069039..c073b38cd6738176fc6a276d05ed553526573341 100644
--- a/sound/usb/line6/toneport.c
+++ b/sound/usb/line6/toneport.c
@@ -386,7 +386,7 @@ static int toneport_setup(struct usb_line6_toneport *toneport)
 		toneport_update_led(toneport);
 
 	schedule_delayed_work(&toneport->line6.startup_work,
-			      msecs_to_jiffies(TONEPORT_PCM_DELAY * 1000));
+			      secs_to_jiffies(TONEPORT_PCM_DELAY));
 	return 0;
 }
 

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:11:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:11:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853283.1266825 (Exim 4.92)
	(envelope-from )
	id 1tL8SL-00049h-2k; Tue, 10 Dec 2024 22:11:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853283.1266825; Tue, 10 Dec 2024 22: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 1tL8SK-00049B-U2; Tue, 10 Dec 2024 22:11:48 +0000
Received: by outflank-mailman (input) for mailman id 853283;
 Tue, 10 Dec 2024 22:11: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 1tL8Je-0001xA-NN
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:50 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 7cbba81b-b742-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 23:02:46 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id 05ECB20ACD66;
 Tue, 10 Dec 2024 14:02: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: 7cbba81b-b742-11ef-a0d5-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 05ECB20ACD66
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868159;
	bh=VvjxiqfKxbyi9uGzXsW8xZpGKBVs2F3SKydD57RgoIM=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
	b=WbJnm80TvYnXykJB9DgMtqoZ50ou8AhS1efFy3dCoV03536YA3dJhXmL0IMKChnpw
	 CujNWFZtiMOuyACXPjtJ3tU0PrbAysQ8+2RTG/TU5ekLFjjJ/pUAEWKon7ssztFoiO
	 F9frqglM8e2VebaFFRHMBRJ+sqXulRejbFKVUSag=
From: Easwar Hariharan 
Date: Tue, 10 Dec 2024 22:02:45 +0000
Subject: [PATCH v3 14/19] wifi: ath11k: Convert timeouts to
 secs_to_jiffies()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20241210-converge-secs-to-jiffies-v3-14-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan , 
 Jeff Johnson 
X-Mailer: b4 0.14.2

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Acked-by: Jeff Johnson 
Signed-off-by: Easwar Hariharan 
---
 drivers/net/wireless/ath/ath11k/debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath11k/debugfs.c b/drivers/net/wireless/ath/ath11k/debugfs.c
index 57281a135dd7fa6b8610636f47873c8bba21053c..bf192529e3fe26a91e72105a77b4c6f849b905ec 100644
--- a/drivers/net/wireless/ath/ath11k/debugfs.c
+++ b/drivers/net/wireless/ath/ath11k/debugfs.c
@@ -178,7 +178,7 @@ static int ath11k_debugfs_fw_stats_request(struct ath11k *ar,
 	 * received 'update stats' event, we keep a 3 seconds timeout in case,
 	 * fw_stats_done is not marked yet
 	 */
-	timeout = jiffies + msecs_to_jiffies(3 * 1000);
+	timeout = jiffies + secs_to_jiffies(3);
 
 	ath11k_debugfs_fw_stats_reset(ar);
 

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:11:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:11:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853280.1266819 (Exim 4.92)
	(envelope-from )
	id 1tL8SK-00046f-Pe; Tue, 10 Dec 2024 22:11:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853280.1266819; Tue, 10 Dec 2024 22:11: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 1tL8SK-00046Y-N5; Tue, 10 Dec 2024 22:11:48 +0000
Received: by outflank-mailman (input) for mailman id 853280;
 Tue, 10 Dec 2024 22:11: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 1tL8Jf-0001xA-NQ
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:51 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 7d3095b5-b742-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 23:02:46 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id 3576020ACD6C;
 Tue, 10 Dec 2024 14:02: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: 7d3095b5-b742-11ef-a0d5-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 3576020ACD6C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868159;
	bh=2KdSABVpHGeIl3K+Zfq51kwhEReKGYYzt3DUWqeHGog=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
	b=R9JyWtdIUEb4/zKyVfibrupVtLSA8I4Ge9h6DsznbqwDXYuMt91s9gMK2E8wvHrfF
	 DAI6C0uY79rteNLP8XN3j0zl2c4hIe69V64Jd/WfL7mt75W43sZOrZK3S3e5zHR6NX
	 Fb6Kd6ZyvfvV2PAG+yCh6AjQd+L5BQfffwiXvwAk=
From: Easwar Hariharan 
Date: Tue, 10 Dec 2024 22:02:46 +0000
Subject: [PATCH v3 15/19] Bluetooth: MGMT: Convert timeouts to
 secs_to_jiffies()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20241210-converge-secs-to-jiffies-v3-15-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan 
X-Mailer: b4 0.14.2

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan 
---
 net/bluetooth/mgmt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index b31192d473d09b663dc7babd107b4894088ebf6d..8c993763ee0f0360e0d92705f9035f47754b793b 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -210,7 +210,7 @@ static const u16 mgmt_untrusted_events[] = {
 	MGMT_EV_EXP_FEATURE_CHANGED,
 };
 
-#define CACHE_TIMEOUT	msecs_to_jiffies(2 * 1000)
+#define CACHE_TIMEOUT	secs_to_jiffies(2)
 
 #define ZERO_KEY "\x00\x00\x00\x00\x00\x00\x00\x00" \
 		 "\x00\x00\x00\x00\x00\x00\x00\x00"

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:11:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:11:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853306.1266841 (Exim 4.92)
	(envelope-from )
	id 1tL8ST-0004sT-9V; Tue, 10 Dec 2024 22:11:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853306.1266841; Tue, 10 Dec 2024 22:11: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 1tL8ST-0004sM-4P; Tue, 10 Dec 2024 22:11:57 +0000
Received: by outflank-mailman (input) for mailman id 853306;
 Tue, 10 Dec 2024 22:11: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 1tL8Ji-0001xA-Nj
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:54 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 7e705e6e-b742-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 23:02:49 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id C173C20ACD6E;
 Tue, 10 Dec 2024 14:02: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: 7e705e6e-b742-11ef-a0d5-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com C173C20ACD6E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868159;
	bh=RbQWNnMSFMFriUk4NuHYTwiGcsEx+EnrYdZ9JaogvX4=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
	b=e/J9gwCA4uBKGknzsmiO3oet8slWv1kdiClhfZ9LTUvDcAr8km71ONqn/wjRdmpri
	 4EyHjbbYG4CKX/8T2eN5ATCPWVrLNipH5jKYYefAMdH+qlSBTJn1LIV6HX/UxzfdGn
	 9DHlxQpHUKnw1xm9c/b/XukYCVTGP1/9SF9qgehM=
From: Easwar Hariharan 
Date: Tue, 10 Dec 2024 22:02:49 +0000
Subject: [PATCH v3 18/19] livepatch: Convert timeouts to secs_to_jiffies()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20241210-converge-secs-to-jiffies-v3-18-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan 
X-Mailer: b4 0.14.2

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan 
---
 samples/livepatch/livepatch-callbacks-busymod.c |  3 +--
 samples/livepatch/livepatch-shadow-fix1.c       |  3 +--
 samples/livepatch/livepatch-shadow-mod.c        | 15 +++++----------
 3 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/samples/livepatch/livepatch-callbacks-busymod.c b/samples/livepatch/livepatch-callbacks-busymod.c
index 378e2d40271a9717d09eff51d3d3612c679736fc..69105596e72e6826aa2815cb2599eea56a0055ba 100644
--- a/samples/livepatch/livepatch-callbacks-busymod.c
+++ b/samples/livepatch/livepatch-callbacks-busymod.c
@@ -44,8 +44,7 @@ static void busymod_work_func(struct work_struct *work)
 static int livepatch_callbacks_mod_init(void)
 {
 	pr_info("%s\n", __func__);
-	schedule_delayed_work(&work,
-		msecs_to_jiffies(1000 * 0));
+	schedule_delayed_work(&work, 0);
 	return 0;
 }
 
diff --git a/samples/livepatch/livepatch-shadow-fix1.c b/samples/livepatch/livepatch-shadow-fix1.c
index 6701641bf12d454a770e49abeeb0dea92560e55e..f3f153895d6ce751fc91ae1224d91b220cba3e37 100644
--- a/samples/livepatch/livepatch-shadow-fix1.c
+++ b/samples/livepatch/livepatch-shadow-fix1.c
@@ -72,8 +72,7 @@ static struct dummy *livepatch_fix1_dummy_alloc(void)
 	if (!d)
 		return NULL;
 
-	d->jiffies_expire = jiffies +
-		msecs_to_jiffies(1000 * EXPIRE_PERIOD);
+	d->jiffies_expire = jiffies + secs_to_jiffies(EXPIRE_PERIOD);
 
 	/*
 	 * Patch: save the extra memory location into a SV_LEAK shadow
diff --git a/samples/livepatch/livepatch-shadow-mod.c b/samples/livepatch/livepatch-shadow-mod.c
index 7e753b0d2fa611524c9e2adbe02c8fa3e9b6015e..5d83ad5a8118dbbac897dfcbb92e6d5f399d1dc3 100644
--- a/samples/livepatch/livepatch-shadow-mod.c
+++ b/samples/livepatch/livepatch-shadow-mod.c
@@ -101,8 +101,7 @@ static __used noinline struct dummy *dummy_alloc(void)
 	if (!d)
 		return NULL;
 
-	d->jiffies_expire = jiffies +
-		msecs_to_jiffies(1000 * EXPIRE_PERIOD);
+	d->jiffies_expire = jiffies + secs_to_jiffies(EXPIRE_PERIOD);
 
 	/* Oops, forgot to save leak! */
 	leak = kzalloc(sizeof(*leak), GFP_KERNEL);
@@ -152,8 +151,7 @@ static void alloc_work_func(struct work_struct *work)
 	list_add(&d->list, &dummy_list);
 	mutex_unlock(&dummy_list_mutex);
 
-	schedule_delayed_work(&alloc_dwork,
-		msecs_to_jiffies(1000 * ALLOC_PERIOD));
+	schedule_delayed_work(&alloc_dwork, secs_to_jiffies(ALLOC_PERIOD));
 }
 
 /*
@@ -184,16 +182,13 @@ static void cleanup_work_func(struct work_struct *work)
 	}
 	mutex_unlock(&dummy_list_mutex);
 
-	schedule_delayed_work(&cleanup_dwork,
-		msecs_to_jiffies(1000 * CLEANUP_PERIOD));
+	schedule_delayed_work(&cleanup_dwork, secs_to_jiffies(CLEANUP_PERIOD));
 }
 
 static int livepatch_shadow_mod_init(void)
 {
-	schedule_delayed_work(&alloc_dwork,
-		msecs_to_jiffies(1000 * ALLOC_PERIOD));
-	schedule_delayed_work(&cleanup_dwork,
-		msecs_to_jiffies(1000 * CLEANUP_PERIOD));
+	schedule_delayed_work(&alloc_dwork, secs_to_jiffies(ALLOC_PERIOD));
+	schedule_delayed_work(&cleanup_dwork, secs_to_jiffies(CLEANUP_PERIOD));
 
 	return 0;
 }

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:12:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:12:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853317.1266851 (Exim 4.92)
	(envelope-from )
	id 1tL8Sa-0005OS-ML; Tue, 10 Dec 2024 22:12:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853317.1266851; Tue, 10 Dec 2024 22:12:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tL8Sa-0005Ny-GU; Tue, 10 Dec 2024 22:12:04 +0000
Received: by outflank-mailman (input) for mailman id 853317;
 Tue, 10 Dec 2024 22:12: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 1tL8Jh-0001xA-NN
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:02:53 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 7e0df6c0-b742-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 23:02:48 +0100 (CET)
Received: from eahariha-devbox.internal.cloudapp.net (unknown [40.91.112.99])
 by linux.microsoft.com (Postfix) with ESMTPSA id 93EFE20ACD6D;
 Tue, 10 Dec 2024 14:02: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: 7e0df6c0-b742-11ef-a0d5-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 93EFE20ACD6D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733868159;
	bh=2Yxce1Hb0/0P5cE6q+zb1yt8qEYqdCG+5Hx3X7W7CLE=;
	h=From:Date:Subject:References:In-Reply-To:To:Cc:From;
	b=VsljeNAYadFajIAeGJ9FMKFBGspy6ozrhBqU582XvcWkNMj13LfQdRwOadXZG5Pxf
	 Argps4EtZvFIc7JynbCTgqDrOVF3u5K7Ah2l9+nekqV0coL2L+cEZsIcBHPG5GDao7
	 B4HNxmwT4io4VbogtubQ+pF0xj14MXNsqvxe10Z0=
From: Easwar Hariharan 
Date: Tue, 10 Dec 2024 22:02:48 +0000
Subject: [PATCH v3 17/19] ceph: Convert timeouts to secs_to_jiffies()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20241210-converge-secs-to-jiffies-v3-17-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
To: Pablo Neira Ayuso , 
 Jozsef Kadlecsik , 
 "David S. Miller" , Eric Dumazet , 
 Jakub Kicinski , Paolo Abeni , 
 Simon Horman , Julia Lawall , 
 Nicolas Palix , Daniel Mack , 
 Haojian Zhuang , 
 Robert Jarzmik , 
 Russell King , Heiko Carstens , 
 Vasily Gorbik , 
 Alexander Gordeev , 
 Christian Borntraeger , 
 Sven Schnelle , Ofir Bitton , 
 Oded Gabbay , 
 Lucas De Marchi , 
 =?utf-8?q?Thomas_Hellstr=C3=B6m?= , 
 Rodrigo Vivi , 
 Maarten Lankhorst , 
 Maxime Ripard , Thomas Zimmermann , 
 David Airlie , Simona Vetter , 
 Jeroen de Borst , 
 Praveen Kaligineedi , 
 Shailend Chand , Andrew Lunn , 
 James Smart , 
 Dick Kennedy , 
 "James E.J. Bottomley" , 
 "Martin K. Petersen" , 
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= , 
 Jens Axboe , Kalle Valo , 
 Jeff Johnson , 
 Catalin Marinas , 
 Andrew Morton , 
 Jack Wang , 
 Marcel Holtmann , 
 Johan Hedberg , 
 Luiz Augusto von Dentz , 
 Greg Kroah-Hartman , 
 Florian Fainelli , 
 Ray Jui , Scott Branden , 
 Broadcom internal kernel review list , 
 Xiubo Li , Ilya Dryomov , 
 Josh Poimboeuf , Jiri Kosina , 
 Miroslav Benes , Petr Mladek , 
 Joe Lawrence , Jaroslav Kysela , 
 Takashi Iwai , Louis Peens , 
 Michael Ellerman , Nicholas Piggin , 
 Christophe Leroy , 
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org, 
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr, 
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
 ath11k@lists.infradead.org, linux-mm@kvack.org, 
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
 Anna-Maria Behnsen , 
 Easwar Hariharan 
X-Mailer: b4 0.14.2

Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@@ constant C; @@

- msecs_to_jiffies(C * 1000)
+ secs_to_jiffies(C)

@@ constant C; @@

- msecs_to_jiffies(C * MSEC_PER_SEC)
+ secs_to_jiffies(C)

Signed-off-by: Easwar Hariharan 
---
 fs/ceph/quota.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ceph/quota.c b/fs/ceph/quota.c
index 06ee397e0c3a6172592e62dba95cd267cfff0db1..d90eda19bcc4618f98bfed833c10a6071cf2e2ac 100644
--- a/fs/ceph/quota.c
+++ b/fs/ceph/quota.c
@@ -166,7 +166,7 @@ static struct inode *lookup_quotarealm_inode(struct ceph_mds_client *mdsc,
 	if (IS_ERR(in)) {
 		doutc(cl, "Can't lookup inode %llx (err: %ld)\n", realm->ino,
 		      PTR_ERR(in));
-		qri->timeout = jiffies + msecs_to_jiffies(60 * 1000); /* XXX */
+		qri->timeout = jiffies + secs_to_jiffies(60); /* XXX */
 	} else {
 		qri->timeout = 0;
 		qri->inode = in;

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:26:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:26:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853357.1266859 (Exim 4.92)
	(envelope-from )
	id 1tL8ga-0000cK-RD; Tue, 10 Dec 2024 22:26:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853357.1266859; Tue, 10 Dec 2024 22:26: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 1tL8ga-0000cD-OP; Tue, 10 Dec 2024 22:26:32 +0000
Received: by outflank-mailman (input) for mailman id 853357;
 Tue, 10 Dec 2024 22:26: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 1tL8Sl-0003Bb-By
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:12:15 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on2060e.outbound.protection.outlook.com
 [2a01:111:f403:2407::60e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ce6d69c0-b743-11ef-a0d5-8be0dac302b0;
 Tue, 10 Dec 2024 23:12:14 +0100 (CET)
Received: from CY8P220CA0017.NAMP220.PROD.OUTLOOK.COM (2603:10b6:930:46::17)
 by IA1PR12MB7520.namprd12.prod.outlook.com (2603:10b6:208:42f::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Tue, 10 Dec
 2024 22:12:06 +0000
Received: from CY4PEPF0000EDD3.namprd03.prod.outlook.com
 (2603:10b6:930:46:cafe::e6) by CY8P220CA0017.outlook.office365.com
 (2603:10b6:930:46::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.14 via Frontend Transport; Tue,
 10 Dec 2024 22:12:04 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EDD3.mail.protection.outlook.com (10.167.241.199) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Tue, 10 Dec 2024 22:12:04 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) 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; Tue, 10 Dec
 2024 16:12:02 -0600
Received: from [172.28.102.118] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 10 Dec 2024 16:12:01 -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: ce6d69c0-b743-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Srkl9rnBGopXD1t21xpZfu8b4RzuZkleS+9X7nM2UriTWZ41p50MhlmpfFO5YODgxQ0ppUPnjjdw/ahaLijIQRUbG24RZBjYNFmPCtUaMkaMZ5BwYKVMehvpJJHKGgr+/8ELggj2rrXWgGQcfa76DGVAFiw0qpTHz0OWvkIN+KOu9MlJRz2RkcY+C4dwpY6YWo124tdP1FTR4mYsEj5ymf8Ch/5QaXhn9C5MdQCqmdMpwxWVmoYQOrzrpZRP8l2evh8yxq78Z/qopyksQuu6cdtEe/1UVoGOKhOHQfkDfoEEwucu6b5EnXaZZRWfdzW5HjnxVonkDJ9NmQdivTqaDA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=aTwujxVMXCGU4xDb47YM76dAP1HfsbXuTjoKxljROnE=;
 b=aXgOwny9yfRoFnFF+pFfcuSyVojwA2DCFefmNBI60ONqDf1Gpe4jYkU5qLePM0YvuoEu6kRE1Dx77F7IamaUteHPP0lIewaw9LNwhVWCqKur+U7lESXlgUvUdN1cJBIx9zjhyUyi0q4L7L5KSJcD+Lu5QT1qB/5YgBlkoIsbHvHjb37of7YoPy1b9oFLFgyWf/9TSqqQYydFRrKb25IZel+ocdqDUiYTyeh4YxqYsHFY5MrrWYje2UvJ6x7TjQl6uJ6vFSIBCqesyAv/LNuuTcgQEpYX0V7iJgTv+u8krc0YHP27OnMNpV6lIqDSA527S0/N9Y5NJwc5j8mdXaSWCA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=ford.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=aTwujxVMXCGU4xDb47YM76dAP1HfsbXuTjoKxljROnE=;
 b=V7gdBmRJOybIdMDmcxsGwJfEtxzHvM5JURwVyDD7uxjlLf4SIqdRcRn43jKzyUFdwQYC/492RlUlPfdTfMaYGRDMDfyEp9ubsW0FqxEnpb8exeW3FOjd4ksI+bAYNRMpp5YbHoAtnx0ItJQY7p5Big3fh85qC8zAqHayL1Hn6D8=
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=SATLEXMB04.amd.com; pr=C
Message-ID: <9be0addc-d4cf-47c4-937d-e1937898c010@amd.com>
Date: Tue, 10 Dec 2024 17:11:56 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
To: , 
CC: Andrew Cooper , Jan Beulich
	, Julien Grall , Stefano Stabellini
	
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EDD3:EE_|IA1PR12MB7520:EE_
X-MS-Office365-Filtering-Correlation-Id: 89ba0afd-78d7-42c6-7903-08dd1967adb9
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|376014|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?dUY1cm1jNUdPWFpvMVVCS1IvMzhWV2hLTzFMSHlkWEoyY1g0Y0c2SjRhVFFy?=
 =?utf-8?B?ODdEd3d2emNUcGZuZjZ4L3Q1UGlTenJWcXNKd0ZnUGhXa0NhTlhYS0F6dEtP?=
 =?utf-8?B?eHdQKytsT2RqWGh0eUhhK0o5MFVxYkFKbGNwYUhDZVpnL1RyNXlyU3dmczNN?=
 =?utf-8?B?ZXdMTDlGN3o1ZXBwVTU0TVBSejBnTXI2ZTNMSjVNZ2g2N1Z0UkppYVNsaUM0?=
 =?utf-8?B?V0l5ckpwZ1pzc0JGMXBXRmU3VlJnaUpSQU5QaE5rV25NU0I3NE44THQxb2kr?=
 =?utf-8?B?eWxDUWI0NndEL09MTkpYRDBYR3pLWkViTFd5aUNJZnI3QzVjVnVwZ3lGSXp4?=
 =?utf-8?B?ZXFWZC9IWXVENHF2eFVxak1LUVF2N2FRTmhEd3dBNDBoSEVpM1R4NDN4dnRk?=
 =?utf-8?B?czJUOXE0eHZmU1RKZGNpNytlMFFPc0FkZDRNUHYxWU5YL1doZStjSWJMS3Vl?=
 =?utf-8?B?aDBTbWdBbEx3NFlrODEzbkl4QkRwU3RNUU42OVE1ZzhGRnNiQWpxaHpkb3Za?=
 =?utf-8?B?WG5vS2JlWFZITWF6bW5kTjM0Nm9LL1dCQzY3VzUzSnMxR2dzbUFtUXViMi9L?=
 =?utf-8?B?eWZPVHUzNFYySW5OOTQ2L0psbDgzTi9SUEdEU2NqbitPNkgxR3g2TlJWZWNa?=
 =?utf-8?B?aGVLWW9qVWFRWHpMMVA0TFJURmdmaXdKelh2eVRhbE0xUU9iVTY4am4wLzFR?=
 =?utf-8?B?VldTcm1IYXYybFJXdXRnNjNzc1M0TXVYUG8wYnJxc2JPaVNHTDRRVi82MC9a?=
 =?utf-8?B?VkJYMXFTS3BrTm9rS25JNzhuNFpjVFRUS2k4eWtzQkk2c3dZeWtsRlUrM2ky?=
 =?utf-8?B?N0dMSkJpQ0V5S0lYVGpNSU9XdzFjRGp4a2VYWlVQSDlieWQzcHg0am4waEo1?=
 =?utf-8?B?SUtXSURmK0N1VkJGZ0pSTkxJUHNHa3Zkc1N0a0gwbTZFT3IzdnZsRjdnNUFy?=
 =?utf-8?B?RmpzOThnM21RYTIyMGdQOTRVUnRGY05qR0dFdzNLeTJCTDQya1FTWXJpM0xX?=
 =?utf-8?B?aE9SQXpFVzVkcHFjanhGdFgxTWNpa2dCazVxKzZndWZ6UGxpaWFmOEZjR293?=
 =?utf-8?B?V3JwRnVqeDJ5UFN5L2NvdUFzWXljdmtVbXJSUTV0aGhKSHNVWUtnaE9VTlJD?=
 =?utf-8?B?M1RGYXdyK2JqQWRmU3cxU3ppUUNXVFBEWWxNNml4cmNldFd3OXdQa1MyM2Nl?=
 =?utf-8?B?YldBS0JiYmJOZXkzWHdua3YvT1NUbVJoMTluQnhwTVJETXJEUEhSRzVaWkh0?=
 =?utf-8?B?aUtKRXRmdTZNSjRWeUNjNTBIazlEdlJYdldlVUxzY1MxNEZKdFRZRlFyNjNr?=
 =?utf-8?B?SU91UXlodXdkTnRoU2RwUXIyaForUGN1YkY4VVI2bkZDOXFxYzFOT1RoeDNk?=
 =?utf-8?B?NllzMEd4N1JqWUZHN0t4Y1N0dmNCSTFtcG1UYzBDUy9PNEdMem96N3JKc1hs?=
 =?utf-8?B?MnRjMkVUKzhUdzlWbXZxNWdvQU1yOGZkajRPL3N5eUY0RGxpUFlXNy9vOWI2?=
 =?utf-8?B?Yy96azZ2dlh6U25jYlc3SnQ3cVIxTmdPanZLLzIveEtuZis1UmdLaTV5dkp3?=
 =?utf-8?B?cmNVL2pvL01EVWNYeTFzeUNubTJoeXJkaGx5QTRCSG1jemszZzlsUysvNUdX?=
 =?utf-8?B?Z2hxZXhWdmtETjdia1hXdVdPcFpHTVhOU3dpRyttVU1tUWlIZXo1dGlkaURF?=
 =?utf-8?B?dGFYZWw5NVUwYzRJdStoTmRmOUwxQzU2WXpOK0FSaHJKa0U0NlhvYzBJUUhU?=
 =?utf-8?B?RHc3Y1IyMEJoYlhZOGdqckpreFNpN1lIUDJTS1g0Nyt4YjRiQWQ4U0ZRZ0lh?=
 =?utf-8?B?d0tMTktQK2pXV1QrdEFCbDQxcFkxdGFhMnd1NUQ1Q2Q5N2VGcjJKVUN0L05C?=
 =?utf-8?B?MzhtY2xHMG1SQWM5czBJbFQ5YjRscnZLRjdoMm9MMUZ4TE45dHF4NHlrNlZk?=
 =?utf-8?Q?Q2gC+0BEZGV+DesPACvPemNZI1KqrTsK?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(36860700013)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2024 22:12:04.1699
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 89ba0afd-78d7-42c6-7903-08dd1967adb9
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000EDD3.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB7520

On 2024-12-05 23:41, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> console_owner_domid() is introduced to obtain the "console owner" domain ID.
> 
> The call is used in NS8250 emulator to identify the case when physical xen
> console focus is owned by the domain w/ NS8250 emulator, in which case,
> messages from guest OS are formatted w/o '(XEN)' prefix.
> 
> Signed-off-by: Denis Mukhin 

Reviewed-by: Jason Andryuk 

I expected this to be used immediately by patch 21, but it is not.  You 
might want to re-order it directly before its first use is introduced. 
I haven't gotten far enough to know when that is.

Regards,
Jason


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:30:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:30:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853372.1266870 (Exim 4.92)
	(envelope-from )
	id 1tL8kP-0002OG-Ad; Tue, 10 Dec 2024 22:30:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853372.1266870; Tue, 10 Dec 2024 22:30: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 1tL8kP-0002O9-83; Tue, 10 Dec 2024 22:30:29 +0000
Received: by outflank-mailman (input) for mailman id 853372;
 Tue, 10 Dec 2024 22:30: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 1tL8kO-0002O3-4x
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:30:28 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2062e.outbound.protection.outlook.com
 [2a01:111:f403:2414::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 595237aa-b746-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 23:30:25 +0100 (CET)
Received: from MW4PR03CA0143.namprd03.prod.outlook.com (2603:10b6:303:8c::28)
 by PH7PR12MB9222.namprd12.prod.outlook.com (2603:10b6:510:2ef::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Tue, 10 Dec
 2024 22:30:14 +0000
Received: from MWH0EPF000989E6.namprd02.prod.outlook.com
 (2603:10b6:303:8c:cafe::37) by MW4PR03CA0143.outlook.office365.com
 (2603:10b6:303:8c::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.15 via Frontend Transport; Tue,
 10 Dec 2024 22:30:14 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MWH0EPF000989E6.mail.protection.outlook.com (10.167.241.133) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8230.7 via Frontend Transport; Tue, 10 Dec 2024 22:30:13 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) 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; Tue, 10 Dec
 2024 16:30:11 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) 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; Tue, 10 Dec
 2024 16:30:11 -0600
Received: from [172.28.102.118] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 10 Dec 2024 16:30:11 -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: 595237aa-b746-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=t29HFYiotTPks+eMFbLznKA2FZNhzEjgZtRFu8ZuX+vUR1XR9SajH2QV3mWdlPRqpY8WAkmKGHHiDMq1dLaPf3q8EVP3etzCjjfuiB2GOC+x3+Ynxk5RW+/uRGfJ208fSwQ/xeUFiobjeChPH6/MhgNx8R6p1GTIvYUIEImoRoLg30qGiL2TyoPf61X4jJ1CHIV6csQS+4l/9lheshj8paEbI7Ks43nMmocmKhMO/7I3oSzlISscmNDNhw84nUTsEy4isuz/7VqZUnLEvcV/pvxfOBC5ioQEri0bFfMUYcQV9JLgBHAvLLq+APcfGd5WG/gWUyB6yvBaXT1MqeP3Lg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=80MVolOrC1kIq5fwE9Wbt7KtU7fQQfhWlNkf6dCDonk=;
 b=oiBhJ1gpZeSNYIWI52U6QRpex0gjfMYGf97TshnD9sXoA26VKCqk9rhau3XiM8VnBXUagiT7PDpuiVKjVkMYk39bvrJM1pJek8i1zCK7TtIpt2jhYk+viko84pui9LMua9KL8PYXMnbu+2kKJGnMrjj+K8pt12bteJtr+WsUEjJsX/0yRC3vemm9wlK0U+72OwHVRO+pTSD8grrEUUcBZjXxF9UNocbuOSSxWD6Iof8PipN3jMRfVfOKBAmxg77pltZPrK0f9s38cXU3IEuFPGsyvIksS4pxKUp/DZXxBowOBkAKm3T74hMPyiLPeCkoES4M+9olZDIg5VGGNpjPmA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=ford.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=80MVolOrC1kIq5fwE9Wbt7KtU7fQQfhWlNkf6dCDonk=;
 b=EOkunJQ6oZ/l0f5ZO74rfZhlGk6LXYzKwvOof8ruPNozaRkrjTq6PFcJ3kF26gpyZgfGTZT9V8mhlIgchGFA/4fpVUOksF2EvMcyKFhJoKe5o0kw+DQzm8LD4SNS+neGuBE8YG/1wAQ8XP7OgCD+UKasY3YpOyYNRTG61ld41Fo=
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=SATLEXMB04.amd.com; pr=C
Message-ID: 
Date: Tue, 10 Dec 2024 17:30:10 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 21/35] xen/console: introduce console_init_owner()
To: , 
CC: Andrew Cooper , Jan Beulich
	, Julien Grall , Stefano Stabellini
	
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-21-e9aa923127eb@ford.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20241205-vuart-ns8250-v1-21-e9aa923127eb@ford.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000989E6:EE_|PH7PR12MB9222:EE_
X-MS-Office365-Filtering-Correlation-Id: 276c4c6a-bf0e-4194-399b-08dd196a374a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|376014|1800799024|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?OGpkREtPRUJicmFJcnJyL0VnaGU5eFJSelM2S3VSRmFJUzNhMVhGVFNLM1Z3?=
 =?utf-8?B?dXNSS3lyeXlJdlJ5NCtKNW93M3JEcm5TcHFxdWc2OVlWUlFYaHQ5bThKdm95?=
 =?utf-8?B?YnlWSXBGQ0V0c2ZHOFRJQUxzZHJVY1NxR1hVSVBsaktSbXJrcUZtSndCODhB?=
 =?utf-8?B?bS9RNlkwVUhPak9FRnRmSk1Qam1MYUsyeXZpSkFGZG1hWXFwNDh0ZlY2OUVT?=
 =?utf-8?B?UTRMc3h0YThrS21sRDF2Y2lIQzVNanBITFIvWUNKSzJKTURMSkx6MU1oZXRX?=
 =?utf-8?B?dXZPM2JRVElKajZIQTF1NElRaVB2U0kxMCt2WWFGaEcwUHkva0tRM3h1Uzdi?=
 =?utf-8?B?ckwwYWx5bVlsMnYxQ0dCQ3JsZ2xmR1FURW9wODNRNUVhNnNuc2F6NDkwVEJq?=
 =?utf-8?B?WGlsdmlqbXpmVjdVcUkwZEVsVGVNbzlyRGZHTzR4dnNwNFM0V0p5YkRFT3JY?=
 =?utf-8?B?Wm5iRzNwMlZGajBqRFQvaHAyUTNLYXpFSzF0L2FIdWRuRTh5YzFKMDVFV0Vi?=
 =?utf-8?B?cWZ3bXJKSFlhSUd5eUhEN3QzSDdTUXdzNm1TNDVEL1Mwa2RDSWg1cWJjK2Nl?=
 =?utf-8?B?VXJTeG8wOTJrenZrV3NmK0hxeFk5Q1NVTmFmejcrdW56RSttVkZ2OFZ2TklT?=
 =?utf-8?B?VzdNejJhc3F1dWwxL0k0SFlEcWlHeDlXYjlaeHJXQ0hPZyt1Z3JManorV0pV?=
 =?utf-8?B?VHZmTlk4Q0FXWnp6REczSXk1eGFHelUvMDZpM1NGMm5ZM0RwMDFzR0FRRWtp?=
 =?utf-8?B?QUdPTGl4Zk0zMnBMSzJUbkQ4MWFoVmk0aE1LZFNaY1Q2eS9Ed1YvZWVEeVJS?=
 =?utf-8?B?cVI5NndLd2VxQzFTbHNPcXFLanNTRnlmWllheHUyWmZwRGltKzkzZEc4RnFa?=
 =?utf-8?B?S0JVcVpxdkpiajFOeUJ5ZlZjRmFRNWhKZi8ySUZMb2lRWHdtSEZaUElZVi9V?=
 =?utf-8?B?WElQTmQxYi9BYlVJWHBqSWszOUxRS0ZSMWVnL1RoNjFWZVIwVWpCWkpwR1Qv?=
 =?utf-8?B?UHRLcW9NU2JGdmRRNDNYZituTkxTSWZ5NXZTZFdYUzhrTXpoTXN1WmZTcGM2?=
 =?utf-8?B?czhxZ2U1Z3FoV2hMVVV0MVZHTG02ZFhKNVF4Vm9GY1JqYXBUMXRRZ2lzem4z?=
 =?utf-8?B?aThuQmpHL3FFOU85d1pYS3Ewbm5WWUtVVHNMQVZwbVhCUVowN2RxdG9HSlhF?=
 =?utf-8?B?YmJHSVdRWDBUTUNGR3pvaUZOa0tGTGQ1Ui9zU0Z5RnZ6b0RaSmlHak15cU1t?=
 =?utf-8?B?c2l5b2Rla3J3TXJPQzQ1dVJNRkRQeWdmT2g2bFAwTWtKUVJoaStMUXFwa3pF?=
 =?utf-8?B?VlMvYjVWTW1rOUhPaEs4aDRSamI0VG5RRVpFUHU0dHh3Nmo0ZW15ZU55M3Ju?=
 =?utf-8?B?L0I4UG8xVXd4OUcycnVTVkM2YWVSK2hGODBTSnhRalVLWjBGSG8wNWdHd09w?=
 =?utf-8?B?Q08xdEFTSWxST3B5dHNKcThRakk5dVY4UzVXT0hwaGdsb0xDTkE0My94Smpk?=
 =?utf-8?B?Nmk3YjM1MVZuTE52NnhzdHlvQXpWSVA4N1F5TWhjdjBZWlEwYVJsaENYT0lB?=
 =?utf-8?B?M0hjMnBQdEtXTjM1NzNSbFJVU0l0ditMTzliakdyVFVLVmpTbjFMZndPTVZ6?=
 =?utf-8?B?YmIzK3Q4cXBpdFJnUjM4Y2dNVFpqS3QydGdUTnhZUi9GVnZJT3dFNXNYbTZU?=
 =?utf-8?B?N1JWYmtoL3F0VmJjV2NSNWhKdlJKbnVPbTRwc3BwaHhMRnN1cDJocUx0K0dQ?=
 =?utf-8?B?aFB2V2hZRk51OStzaHRIQ1VVTTlzcitJeU5SbitZaEZHZVhQbjlsYTkzTWRw?=
 =?utf-8?B?WmU1OXFZaEwvSzlTaUtwRHlWVFNwVDdRb0UzS1NTMy84dHR3WUY3RS92VHpy?=
 =?utf-8?B?U3VKTUlrTm9tRTk0VjJGdDExK1dOdFNCZ05sYU9lYnNIL2ZJSW5BMHBPY1c4?=
 =?utf-8?Q?vxB8DOfnzw3MR0/jAp+ZMdwzn9RaM/II?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(1800799024)(36860700013)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2024 22:30:13.9755
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 276c4c6a-bf0e-4194-399b-08dd196a374a
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000989E6.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB9222

On 2024-12-05 23:41, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> console_init_owner() is introduced for selecting the boot-time console owner.
> 
> Signed-off-by: Denis Mukhin 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 22:46:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 22:46:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853402.1266880 (Exim 4.92)
	(envelope-from )
	id 1tL8zt-00084h-MK; Tue, 10 Dec 2024 22:46:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853402.1266880; Tue, 10 Dec 2024 22:46: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 1tL8zt-00084a-I9; Tue, 10 Dec 2024 22:46:29 +0000
Received: by outflank-mailman (input) for mailman id 853402;
 Tue, 10 Dec 2024 22:46: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 1tL8zr-00084S-Ew
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 22:46:27 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20624.outbound.protection.outlook.com
 [2a01:111:f403:200a::624])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 94f8413a-b748-11ef-99a3-01e77a169b0f;
 Tue, 10 Dec 2024 23:46:25 +0100 (CET)
Received: from BY5PR17CA0068.namprd17.prod.outlook.com (2603:10b6:a03:167::45)
 by IA1PR12MB6604.namprd12.prod.outlook.com (2603:10b6:208:3a0::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Tue, 10 Dec
 2024 22:46:19 +0000
Received: from CO1PEPF000066EB.namprd05.prod.outlook.com
 (2603:10b6:a03:167:cafe::41) by BY5PR17CA0068.outlook.office365.com
 (2603:10b6:a03:167::45) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.19 via Frontend Transport; Tue,
 10 Dec 2024 22:46:19 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000066EB.mail.protection.outlook.com (10.167.249.7) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Tue, 10 Dec 2024 22:46:18 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) 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; Tue, 10 Dec
 2024 16:46:17 -0600
Received: from [172.28.102.118] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 10 Dec 2024 16:46:17 -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: 94f8413a-b748-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=q/u33+/uEyTRcYjudWTLzoyngQyU5j9LHkMBa/qmrJTpXUOygrImDVVGaLWZu7KVLepPq3NN1nzlh2Q08xma5l4i84xQwxwL8KZl7flMu6tps+aKNctrmwwSl57Yg8e22onGlJX63aKnHCq3pa9C7gGXZ1qW23LGyKtz15ZbPRpeek5JTjBLciZmLuBgoaDHHfPbLZBX7vyYf44QQ/G2BrcLTh+4m8cG+8G/WHqVxn6fE7NrVsIEBXwpeKfanlbIJit2P0RZkXVsG6W34Qfwqxzfy9/aaQZz9BnQAVmlCzodlad0UOf36FhNNh3QFLc6xdKu6F9y1r81u8RUyHv+RQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=r79r4zDLpxcaMFheGyKd3Wb6ZfryLky/aY/0Wn0XtQc=;
 b=a+tvlKkNQu7Ax9L6+E4o8kzITXaa0kPX2hzHQAUtbvfyiOPPa25nzH2gRUwnzq7SeEgmBo3+g/F5mCNSfF6KP4X7h2E9/F78ldWglWyK5pwQ46Re3jqqpgjyVgW/fbQ5t+24Yr6r3sCZYiFd8iZaHnNNEmLkxHvr6WDwwz9nQu83s1/KJWengkt7hYyFh+fDN8e93stWf3WEFiYnS2rNoNx94qdE1xxQPQNfdI++QaeuMblqhuOh60nYWXaG5eTa7L96gwPctVwfU0ZKJg9uKL4GoLOfXLfU0QJ4aM8L3O5jdOaQOUE+bJdCVmmy3Yb/mV1MTvduPtu7hXVA7Xyt7w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=ford.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=r79r4zDLpxcaMFheGyKd3Wb6ZfryLky/aY/0Wn0XtQc=;
 b=vNiseCnxflngo/e0nDJGZlnkYKyIroc+N/fNU/yIR2oKbCxWowf8lQrEOlZxojcMJ9qtt5FV94YZ/FgDiVs6eoJRqb/4gFwqPCttSbB6cx5a+QHLuYy1DdxGTDma3OOSBNiaHtRGYRgS61Zran15GigmwrZ5kUUQfDjo7EpG3kk=
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=SATLEXMB04.amd.com; pr=C
Message-ID: <1b55c7eb-3e39-43d1-80d2-2d4caf6a0c76@amd.com>
Date: Tue, 10 Dec 2024 17:46:15 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 34/35] xen/console: enable console owners w/ emulated
 NS8250
To: , 
CC: Andrew Cooper , Jan Beulich
	, Julien Grall , Stefano Stabellini
	
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-34-e9aa923127eb@ford.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20241205-vuart-ns8250-v1-34-e9aa923127eb@ford.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000066EB:EE_|IA1PR12MB6604:EE_
X-MS-Office365-Filtering-Correlation-Id: 308f0978-f5d3-40b8-32bd-08dd196c7659
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|82310400026|376014|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cC92dkl1NFRJUUNMdmNPbWoxb2cxNktFZVdVVFg1TmNmZWlCR2lQMFVXNDRW?=
 =?utf-8?B?V0JPUXljSVNTUTRlZEorMFlrQlFEVGI2RHk1b1Z2M1p4NmNTWnhWcURNeXBB?=
 =?utf-8?B?MkMzcURSeWs5dTVHeGxmYlMvb0NSdWVmNTNvV2NMWjlQYy80cGxNMWNFdDlw?=
 =?utf-8?B?M2thWGNSMEV4QVhmMFlMWkJkVDF0cW0zRFN2TUd3WmFNZWhaUWtTRWMrMkc0?=
 =?utf-8?B?RnZQRTVvYURwTWRHZ1l2UnB5cUk4azcvUE1YcEYrdEFJL0dFLzIrVVJuQXhT?=
 =?utf-8?B?dDFvSnZVckpIV2JrcDFJVVZxOFlETGx1U2ZYMHhQbU1VWGpMeTYzVzhhSGVX?=
 =?utf-8?B?c2t1cS9iYWhjL01RVjhKMHptWHJFZFlZVHZ4cWE5a0tOUGpaNDhpYjhoOWxD?=
 =?utf-8?B?K01OQjY2SURISmtOdWRBYThmUWlBaGNhRFZtNGlhYzNNNTB0bTR4dmlENHY5?=
 =?utf-8?B?WTlrV1dFRmFLN2VyNnBpRXQxcnBPL2FXRjl4R2VDTlVLbDdvTW5NOUcydnA4?=
 =?utf-8?B?L0g4US9vbmlYcFJYVjROdVZxNFIzRDJRaklSSVhOSzk1WEdRUks4NlJnZ2VJ?=
 =?utf-8?B?Skliem92azBkWVJ1dGlUd09CdGJpajZMbVBya0l3QVJleU9OZGF5TUt4ODNp?=
 =?utf-8?B?VE1OTm4wN2NtY2tycFduRVpRck5FSHRqSit2WHdQaUJZTW0yYUpoMlU5QXl0?=
 =?utf-8?B?MmovWSszOXhjL05BK1RjTUM2RjZLeW83a01ta1ZSWTM0UkRKRC9ZMlhFd3Jn?=
 =?utf-8?B?Y2VndVExNHYrYW5Cd3NKOHJIUlNKdjRCWnJkNXdyT1ZGVm1IV1RZSjhNMkxP?=
 =?utf-8?B?Zm1vSy9jWXhhL2ZJeXZlUjF1eE04UjJjWGdEeDk1T0habkpQd3lhcDFwckdu?=
 =?utf-8?B?QTV2ODFYeDh0cDR0QUsyQ2gvUXJDaVZkR2o0dVhyRDE2Q2xPdyttNVZINnBo?=
 =?utf-8?B?YmxCL21WZzJnZHNKOGVveGRhazlzclM5WUZYQng4UVpxck9nSURQR0dMUVJz?=
 =?utf-8?B?dWNLaUtZcldXdEpZaGxzeENYRFp4eE9MMHVMeUdhSkhPZWR4UmhDc1pBSnIx?=
 =?utf-8?B?YWxqbmhYUW0vMllSUktGMCthZWg2NVFRQld0eFFPVEoxaFg1czBrZzlFRFNY?=
 =?utf-8?B?U0w4VXAzNnhDY3g2b0tQSmxFVkRwWFZESCtOanZ6dHEyM2thYmgzSnMzZzFp?=
 =?utf-8?B?VnJBdzgzMlorbXdHbjRYL2dralpOVDdOYVhnTW1sTW9LSUtwYjNaQ1NrdDVm?=
 =?utf-8?B?UDBBcThBNis3ZWRFaUtvYWJJODRUU0NsdGVJMThDUms1UXROU0Juakp4eVZF?=
 =?utf-8?B?NlpmZ2V2WnZtUDlJZmRoazMrSERpWHhHKzc2UGZza0RSdkwzeHRSS0VJUld6?=
 =?utf-8?B?RGtKWXZIYlRWSzYySnhVNFJqT2V1SElXVlZkRGYvUjk1L0hadXpoODhjU3Uz?=
 =?utf-8?B?NE5GSmlYVkV4Tzg3MjVGVXVFN1U4akNRMGhoVUVYREtvY2NZZ0U2VlB5ZGdv?=
 =?utf-8?B?VFVGNFZPeXl0dUk5c1QwYkN5cXgyeG9tUHV5azM2YVZCckV4MHRES2drdmdS?=
 =?utf-8?B?YXhIWTNkVjlsQVJRc0ZDZW4xZTk4QzVKWkh6S3IrRjV5M0Q3djRpNS80bnVH?=
 =?utf-8?B?cEJHQWEvQThlL0lvZkhpZkRTOG1CbXA3TUpxaUhDaThLVEc5Z1lPNExIdE9Q?=
 =?utf-8?B?UndKcmVrUnd3RFdUaWZRaWxnN0t1WTB5d2JlUWd5MFp3WmtVcWVHMjB0ckRr?=
 =?utf-8?B?THo0OXJCMGd2SXFWZi9DZ2cvU0xXVGczblRMWEJaOG9FSTNiUHFTdWxMT1Na?=
 =?utf-8?B?Q3BmM1dLcjdvc2o4OG84V1lyS2FZYnhoblgzRjF3RDg0bW9vNVpZL2hURGhL?=
 =?utf-8?B?and1UEVkVW96bmlqd08xSmM2SVZyUnBTUHN5YlI0Z05CVzlvYVFjeDNMMnNa?=
 =?utf-8?Q?YctFbeZ65cs5YjWUo0HMuCHHJyOG16mx?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(36860700013)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2024 22:46:18.7635
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 308f0978-f5d3-40b8-32bd-08dd196c7659
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000066EB.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6604

On 2024-12-05 23:42, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Enable console focus for domains w/ virtual NS8250.
> 
> Code change allows to capture the output from the guest OS now and send it to
> the physical console device.
> 
> Signed-off-by: Denis Mukhin 
> ---
>   xen/drivers/char/console.c | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index a26daee9c4c4b1134d0ae3d105ffdb656340b6df..798dfdf3412a2feef35e72946d6c59bee59a9251 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -41,6 +41,9 @@
>   #ifdef CONFIG_SBSA_VUART_CONSOLE
>   #include 
>   #endif
> +#if defined(CONFIG_HAS_VUART_NS8250)
> +#include 
> +#endif
>   
>   /* console: comma-separated list of console outputs. */
>   static char __initdata opt_console[30] = OPT_CONSOLE_STR;
> @@ -627,6 +630,8 @@ static void handle_keypress_in_domain(struct domain *d, char c)
>       {
>   #if defined(CONFIG_SBSA_VUART_CONSOLE)
>           rc = vpl011_rx_char_xen(d, c);
> +#elif defined(CONFIG_HAS_VUART_NS8250)
> +        rc = vuart_putchar(&d->arch.hvm.vuart, c);
>   #endif

I think it would be nicer to just use a single name and avoid ifdef-ery. 
  vuart_putchar() is generic and matches domain_has_vuart(), so that 
seems good.

You can then have a default stub that returns -ENODEV for when an 
implementation is not built.  (This goes along with Jan's suggestion of 
a common, default domain_has_vuart().)  Something like:

#ifndef vuart_putchar
static inline int vuart_putchar(struct domain *d, char c) {
     return -ENODEV;
}
#define vuart_putchar vuart_putchar
#endif

and ARM can do:
#define vuart_putchar vpl011_rx_char_xen

x86 would need to change its arguments, but that should be straight forward.

What do you think?

Regards,
Jason



From xen-devel-bounces@lists.xenproject.org Tue Dec 10 23:36:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 23:36:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853435.1266890 (Exim 4.92)
	(envelope-from )
	id 1tL9m2-0000Dn-CP; Tue, 10 Dec 2024 23:36:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853435.1266890; Tue, 10 Dec 2024 23:36: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 1tL9m2-0000Dg-9m; Tue, 10 Dec 2024 23:36:14 +0000
Received: by outflank-mailman (input) for mailman id 853435;
 Tue, 10 Dec 2024 23:36: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 1tL9m1-0000CJ-7n
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 23:36:13 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 885138b0-b74f-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 00:36:10 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id D5AF6A41CB8;
 Tue, 10 Dec 2024 23:34:16 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 557E2C4CED6;
 Tue, 10 Dec 2024 23:36:05 +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: 885138b0-b74f-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org;
	s=korg; t=1733873767;
	bh=HHHMPXzhb0ErTbk6JDPXkklA5yJiK4ykiwi4ou5ZnCc=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=JEUFC7jHRCmHI3pSRcaodXf1l/diOVpYu0xkyvRNQH8mQQn7b8CBtOxBJCrSzxiPd
	 x5Ao+At5E5iCnmOoRtx4XFH3yzCpaefWwlAOlUrwnX+e1Xpsqclis9IS5OMX5ZHkAC
	 NceJVwBIegWzfPrxO3hIAUaRVAN7EpBlmQG/j2MY=
Date: Tue, 10 Dec 2024 15:36:04 -0800
From: Andrew Morton 
To: Jeff Johnson 
Cc: Easwar Hariharan , Pablo Neira Ayuso
 , Jozsef Kadlecsik ,
 "David S. Miller" , Eric Dumazet
 , Jakub Kicinski , Paolo Abeni
 , Simon Horman , Julia Lawall
 , Nicolas Palix , Daniel Mack
 , Haojian Zhuang , Robert
 Jarzmik , Russell King ,
 Heiko Carstens , Vasily Gorbik ,
 Alexander Gordeev , Christian Borntraeger
 , Sven Schnelle , Ofir
 Bitton , Oded Gabbay , Lucas De
 Marchi , Thomas =?ISO-8859-1?Q?Hellstr=F6m?=
 , Rodrigo Vivi ,
 Maarten Lankhorst , Maxime Ripard
 , Thomas Zimmermann , David Airlie
 , Simona Vetter , Jeroen de Borst
 , Praveen Kaligineedi ,
 Shailend Chand , Andrew Lunn ,
 James Smart , Dick Kennedy
 , "James E.J. Bottomley"
 , "Martin K. Petersen"
 , Roger Pau =?ISO-8859-1?Q?Monn=E9?=
 , Jens Axboe , Kalle Valo
 , Jeff Johnson , Catalin Marinas
 , Jack Wang , Marcel
 Holtmann , Johan Hedberg ,
 Luiz Augusto von Dentz , Greg Kroah-Hartman
 , Florian Fainelli
 , Ray Jui , Scott Branden
 , Broadcom internal kernel review list
 , Xiubo Li , Ilya
 Dryomov , Josh Poimboeuf , Jiri
 Kosina , Miroslav Benes , Petr Mladek
 , Joe Lawrence , Jaroslav Kysela
 , Takashi Iwai , Louis Peens
 , Michael Ellerman , Nicholas
 Piggin , Christophe Leroy ,
 Naveen N Rao , Madhavan Srinivasan
 , netfilter-devel@vger.kernel.org,
 coreteam@netfilter.org, netdev@vger.kernel.org,
 linux-kernel@vger.kernel.org, cocci@inria.fr,
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org,
 ath11k@lists.infradead.org, linux-mm@kvack.org,
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev,
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org,
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org,
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, Anna-Maria Behnsen
 
Subject: Re: [PATCH v3 00/19] Converge on using secs_to_jiffies()
Message-Id: <20241210153604.cf99699f264f12740ffce5c7@linux-foundation.org>
In-Reply-To: <315e9178-5b10-4de0-bdcf-7243e0e355bb@oss.qualcomm.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
	<315e9178-5b10-4de0-bdcf-7243e0e355bb@oss.qualcomm.com>
X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 10 Dec 2024 15:14:22 -0800 Jeff Johnson  wrote:

> On 12/10/2024 2:02 PM, Easwar Hariharan wrote:
> > This is a series that follows up on my previous series to introduce
> > secs_to_jiffies() and convert a few initial users.[1] In the review for
> > that series, Anna-Maria requested converting other users with
> > Coccinelle. [2] This is part 1 that converts users of msecs_to_jiffies()
> > that use the multiply pattern of either of:
> > - msecs_to_jiffies(N*1000), or
> > - msecs_to_jiffies(N*MSEC_PER_SEC)
> > 
> > where N is a constant, to avoid the multiplication.
> > 
> > The entire conversion is made with Coccinelle in the script added in
> > patch 2. Some changes suggested by Coccinelle have been deferred to
> > later parts that will address other possible variant patterns.
> > 
> > CC: Anna-Maria Behnsen 
> > Signed-off-by: Easwar Hariharan 
> 
> I have the same question as before: How do you expect these to land?
> Do you now have a maintainer who will take all of them?
> Or do you want individual maintainers to take the ones applicable to them?

I'll just grab everything and see if anyone complains ;)


From xen-devel-bounces@lists.xenproject.org Tue Dec 10 23:58:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Dec 2024 23:58:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853449.1266900 (Exim 4.92)
	(envelope-from )
	id 1tLA7I-0007aj-Vn; Tue, 10 Dec 2024 23:58:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853449.1266900; Tue, 10 Dec 2024 23:58: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 1tLA7I-0007a4-RZ; Tue, 10 Dec 2024 23:58:12 +0000
Received: by outflank-mailman (input) for mailman id 853449;
 Tue, 10 Dec 2024 23:58: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 1tLA7H-0007Zi-O9
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 23:58:11 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9a7d47e5-b752-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 00:58:08 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 19E96A41BCD;
 Tue, 10 Dec 2024 23:56:16 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4081EC4CED6;
 Tue, 10 Dec 2024 23:58: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: 9a7d47e5-b752-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1733875087;
	bh=GH8NOQPYYEdNNrAcx2somaPYxu6r/O8X7+ylgFu/Pus=;
	h=Date:From:To:cc:Subject:From;
	b=Eh3zr1TzHz5j0NZw/ZrsMgRU8AZhxWJGIhsQStC9YeA2en6374OSxeFftRUsM+ncx
	 uRd+bZSUG6tXvCtPMUb/WMTayzqXIWtJ7JsqxYpLbqqkLx/5Mskjyvxyjt1DzBKoMB
	 +Bib0oyPGDlmFp1ZeqMV+8/cDQ5haLrjitgJmdaSA09LfXVndyqo+cPGv4ZmqF6gAA
	 QDpPOHJQVVVx64vJekGA83KUnN5yf3b2Nnp5snNCecXUPO93LK4NkStukGY3btg6Zx
	 IHBe2DGmPZab00JpIRs4d50efVMZOSEBoGHhQ3yWuFkQExLD3EWKv05bhOXwnHrMvc
	 V2TYe/HlFqHww==
Date: Tue, 10 Dec 2024 15:58:04 -0800 (PST)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: xen-devel@lists.xenproject.org
cc: sstabellini@kernel.org, kelly.choi@cloud.com, anthony.perard@vates.tech, 
    michal.orzel@amd.com, roger.pau@cloud.com, committers@xenproject.org
Subject: [PATCH] MAINTAINERS: add Anthony, Michal, Roger to THE REST
Message-ID: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1197079066-1733873006=:463523"
Content-ID: 

  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-1197079066-1733873006=:463523
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

In recognition of their outstanding work and years of service to the Xen
Community, please join me in welcoming Anthony, Michal, and Roger as
Committers and REST Maintainers.

Signed-off-by: Stefano Stabellini 

diff --git a/MAINTAINERS b/MAINTAINERS
index 026aa25a53..34ad49bc39 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -662,8 +662,11 @@ K:	\b(xsm|XSM)\b
 
 THE REST
 M:	Andrew Cooper 
+M:	Anthony PERARD 
+M:	Michal Orzel 
 M:	Jan Beulich 
 M:	Julien Grall 
+M:	Roger Pau Monné 
 M:	Stefano Stabellini 
 L:	xen-devel@lists.xenproject.org
 S:	Supported
--8323329-1197079066-1733873006=:463523--


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 00:20:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 00:20:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853467.1266910 (Exim 4.92)
	(envelope-from )
	id 1tLASY-0007jF-8P; Wed, 11 Dec 2024 00:20:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853467.1266910; Wed, 11 Dec 2024 00:20: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 1tLASY-0007j8-5p; Wed, 11 Dec 2024 00:20:10 +0000
Received: by outflank-mailman (input) for mailman id 853467;
 Wed, 11 Dec 2024 00:20: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 1tLASW-0007j2-Jx
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 00:20:08 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id accc2136-b755-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 01:20:07 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-a9a977d6cc7so910977466b.3
 for ; Tue, 10 Dec 2024 16:20:07 -0800 (PST)
Received: from [10.0.3.247] ([62.212.134.114])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa68770c481sm378332366b.110.2024.12.10.16.20.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 16:20: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: accc2136-b755-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733876407; x=1734481207; 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=oE3UnuNvh6vbg3Berxt4tcutNImUfhA+K8+EG0UGIms=;
        b=SJUhtgMVT8IgALgtFYH6O3jgIVSuyzRRGvveaLD0voZVMNYmV2Y+esT5Yowlec7Nri
         YmvVf/6wLPBZ/KFwqiTi2fRERjfFL4xvUHOgWpRnxyFVSjPKi4Owwh3N2ciKLncjQbrp
         o1jQYL6ANniQqynYGaVkXLfcd8UZf0jPpqBQQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733876407; x=1734481207;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=oE3UnuNvh6vbg3Berxt4tcutNImUfhA+K8+EG0UGIms=;
        b=DwzVpUi6sxto+sIHQLYuI0QbOutwtaaaGuapkasjFLKRmmqAOFkzo6jubOU6kfo4dE
         9RDH8Wu3hHQ304U1JUihrLmll0Om1SKU9KjOiX2n/HF03EVOHQhZAa4JN1kyvuu0/sQw
         hFVPaXWjrY9eHFEsYW3JikjY57xPzkDR4TXG7V4qgEg8DZj0YKbzfsQ50Bk9SCahFS5n
         9/Wuc72R9xGjMR2F3OZG2bJaBki3B5BjkLRegAWdcSAyuCgjz7wKQM6Fiw79RxO0ALbM
         /Cg3oyNbfm/GD/GJDnfgoBrwSKGvxUGrY6enJS1b8aExRSRiPwx+0FqrknK3QT/LP6LG
         aIug==
X-Forwarded-Encrypted: i=1; AJvYcCUfwA6x9d6mQyKRCh9ot1XNOVpgaoH497ZJZXHU9XB2+gDOpnwHYoqdHmEfmO+SaQNBXcqqkxqMgbY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwVNc8AV4DMdT1KdL1PR/3oqJ+rcPnMQdd96Qp2/dCithoQaLqf
	2YpssaswNRBWCH7T12Ya0sKunwjE+8vHA7fkdHkmb0Xp1s6C6i+++p5uT8bBXEw=
X-Gm-Gg: ASbGnctnjaLU+AoNS4WTuF8Zpy7EqMM7iqjF44CYjryG2thYtR/Ff9QyC/I7RHGIVQ1
	UP6ZW636i0ir/LbIdUjV5lQXkZIvWyi+X1ordycVZWnTR2S8VgD2PMI+xtD95xlBuhPYvrBbOVi
	Xj0QPHDn3gz7zYU6nci1sGKxfgr2Ck+URAmw0vg4R14DrfcmD+Q0LEzbeos2/zLmppCmVj9RhTC
	txDZ3+t+/4FpHrXOtOZ/DedDtTaxsLdt7WODx4UhkOcFFOmDOOLWzgKJZCKQLZX9w==
X-Google-Smtp-Source: AGHT+IFKmU1uMKO53LmLI93NLSsoRYmL5ZqeM82YXKwxnVSN4L3c3a+wNsVlvKYhDWb+aN6ejYyfcA==
X-Received: by 2002:a05:6402:3806:b0:5d0:abb8:7a3 with SMTP id 4fb4d7f45d1cf-5d433035673mr1865241a12.6.1733876406725;
        Tue, 10 Dec 2024 16:20:06 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 00:20:05 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] MAINTAINERS: add Anthony, Michal, Roger to THE REST
To: Stefano Stabellini ,
 xen-devel@lists.xenproject.org
Cc: kelly.choi@cloud.com, anthony.perard@vates.tech, michal.orzel@amd.com,
 roger.pau@cloud.com, committers@xenproject.org
References: 
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10/12/2024 11:58 pm, Stefano Stabellini wrote:
> In recognition of their outstanding work and years of service to the Xen
> Community, please join me in welcoming Anthony, Michal, and Roger as
> Committers and REST Maintainers.
>
> Signed-off-by: Stefano Stabellini 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 00:20:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 00:20:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853475.1266919 (Exim 4.92)
	(envelope-from )
	id 1tLATE-0008RC-HS; Wed, 11 Dec 2024 00:20:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853475.1266919; Wed, 11 Dec 2024 00:20: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 1tLATE-0008QS-EB; Wed, 11 Dec 2024 00:20:52 +0000
Received: by outflank-mailman (input) for mailman id 853475;
 Wed, 11 Dec 2024 00:20: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 1tLATD-00080F-1d
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 00:20:51 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c44d42ce-b755-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 01:20:47 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 113BC5C5E44;
 Wed, 11 Dec 2024 00:20:03 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 121ADC4CED6;
 Wed, 11 Dec 2024 00:20:43 +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: c44d42ce-b755-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1733876445;
	bh=IaQ5PEFSSBLojhKyCdvM1Z3HAopf2lDGrNXNZPv6dCs=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=q0ysTf1l4qjQAn+Tn5YZsMLp/QOSCuvVCCf8xrzgFgQ10MxSQlg1CoTLa55GdFGgd
	 kaLfeuBjoKHQTJ0s9OPY0V1P97fIpdHpCsyBY809Kakxww6Zp04pFXj8XGSu2h5hUp
	 Nxg9Pb+NcpBbJW+EsCicpSS+ySa1otsgpclW51Hp9BB+MS/Ce7D9EEXd9d/x5yhsV7
	 QVDCT3Z6m99ymVV0Jmz19O2fkHv0aCRBJmVvGHQpVdtSLPQyi77pgiZT+DAo6QJaex
	 949e0vg+SrMTVqX/OZBaSxhjbBv8ZCFzNkUFs4h/p63k2MVUuM82Ow4lasDMjwRQ1z
	 8k20rNSomGV0Q==
Date: Tue, 10 Dec 2024 16:20:42 -0800 (PST)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alessandro Zucchelli 
cc: xen-devel@lists.xenproject.org, consulting@bugseng.com, 
    Simone Ballarin , 
    Doug Goldstein , 
    Stefano Stabellini , 
    Andrew Cooper , Jan Beulich , 
    Julien Grall 
Subject: Re: [PATCH] xen: update ECLAIR service identifiers from MC3R1 to
 MC3A2.
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Tue, 10 Dec 2024, Alessandro Zucchelli wrote:
> Rename all instances of ECLAIR MISRA C:2012 service identifiers,
> identified by the prefix MC3R1, to use the prefix MC3A2, which
> refers to MISRA C:2012 Amendment 2 guidelines.
> 
> This update is motivated by the need to upgrade ECLAIR GitLab runners
> that use the new naming scheme for MISRA C:2012 Amendment 2 guidelines.
> 
> Changes to the docs/misra directory are needed in order to keep
> comment-based deviation up to date.
> 
> Signed-off-by: Alessandro Zucchelli 

Reviewed-by: Stefano Stabellini 


> ---
> The change was made using the following command:
> find . -type f -exec sed -i 's/MC3R1/MC3A2/g' {} +
> 
> In order to avoid CI failures this patch and the ECLAIR runners must
> be updated at roughly the same time. This backwards-incompatible
> change is needed to bring to the runners other bugfixes.
> ---
>  .../eclair_analysis/ECLAIR/B.UNEVALEFF.ecl    |   2 +-
>  .../ECLAIR/accepted_guidelines.sh             |   2 +-
>  .../eclair_analysis/ECLAIR/analysis.ecl       |   6 +-
>  .../eclair_analysis/ECLAIR/deviations.ecl     | 244 +++++++++---------
>  .../eclair_analysis/ECLAIR/monitored.ecl      | 208 +++++++--------
>  automation/eclair_analysis/ECLAIR/tagging.ecl | 176 ++++++-------
>  docs/misra/documenting-violations.rst         |   6 +-
>  docs/misra/safe.json                          |  32 +--
>  8 files changed, 338 insertions(+), 338 deletions(-)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/B.UNEVALEFF.ecl b/automation/eclair_analysis/ECLAIR/B.UNEVALEFF.ecl
> index 92d8db8986..fa249b8e36 100644
> --- a/automation/eclair_analysis/ECLAIR/B.UNEVALEFF.ecl
> +++ b/automation/eclair_analysis/ECLAIR/B.UNEVALEFF.ecl
> @@ -1,4 +1,4 @@
> --clone_service=MC3R1.R13.6,B.UNEVALEFF
> +-clone_service=MC3A2.R13.6,B.UNEVALEFF
>  
>  -config=B.UNEVALEFF,summary="The operand of the `alignof' and `typeof'  operators shall not contain any expression which has potential side effects"
>  -config=B.UNEVALEFF,stmt_child_matcher=
> diff --git a/automation/eclair_analysis/ECLAIR/accepted_guidelines.sh b/automation/eclair_analysis/ECLAIR/accepted_guidelines.sh
> index 368135122c..2c4b339d0d 100755
> --- a/automation/eclair_analysis/ECLAIR/accepted_guidelines.sh
> +++ b/automation/eclair_analysis/ECLAIR/accepted_guidelines.sh
> @@ -10,6 +10,6 @@ script_dir="$(
>  accepted_rst=$1
>  
>  grep -Eo "\`(Dir|Rule) [0-9]+\.[0-9]+" ${accepted_rst} \
> -     | sed -e 's/`Rule /MC3R1.R/' -e  's/`Dir /MC3R1.D/' -e 's/.*/-enable=&/' > ${script_dir}/accepted.ecl
> +     | sed -e 's/`Rule /MC3A2.R/' -e  's/`Dir /MC3A2.D/' -e 's/.*/-enable=&/' > ${script_dir}/accepted.ecl
>  
>  echo "-enable=B.UNEVALEFF" >> ${script_dir}/accepted.ecl
> diff --git a/automation/eclair_analysis/ECLAIR/analysis.ecl b/automation/eclair_analysis/ECLAIR/analysis.ecl
> index df0b551812..824283a989 100644
> --- a/automation/eclair_analysis/ECLAIR/analysis.ecl
> +++ b/automation/eclair_analysis/ECLAIR/analysis.ecl
> @@ -22,15 +22,15 @@ setq(analysis_kind,getenv("ANALYSIS_KIND"))
>  -doc_begin="These configurations serve the purpose of recognizing the 'mem*' macros as
>  their Standard Library equivalents."
>  
> --config=MC3R1.R21.14,call_select+=
> +-config=MC3A2.R21.14,call_select+=
>  {"macro(^memcmp$)&&any_arg(1..2, skip(__non_syntactic_paren_cast_stmts, node(string_literal)))",
>   "any()", violation, "%{__callslct_any_base_fmt()}", {{arg, "%{__callslct_arg_fmt()}"}}}
>  
> --config=MC3R1.R21.15,call_args+=
> +-config=MC3A2.R21.15,call_args+=
>  {"macro(^mem(cmp|move|cpy)$)", {1, 2}, "unqual_pointee_compatible",
>   "%{__argscmpr_culprit_fmt()}", "%{__argscmpr_evidence_fmt()}"}
>  
> --config=MC3R1.R21.16,call_select+=
> +-config=MC3A2.R21.16,call_select+=
>  {"macro(^memcmp$)&&any_arg(1..2, skip(__non_syntactic_paren_stmts, type(canonical(__memcmp_pte_types))))",
>   "any()", violation, "%{__callslct_any_base_fmt()}", {{arg,"%{__callslct_arg_type_fmt()}"}}}
>  
> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index 2f58f29203..ae25eeb76a 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -4,36 +4,36 @@
>  
>  -doc_begin="The compiler implementation guarantees that the unreachable code is removed.
>  Constant expressions and unreachable branches of if and switch statements are expected."
> --config=MC3R1.R2.1,+reports={safe,"first_area(^.*has an invariantly.*$)"}
> --config=MC3R1.R2.1,+reports={safe,"first_area(^.*incompatible with labeled statement$)"}
> +-config=MC3A2.R2.1,+reports={safe,"first_area(^.*has an invariantly.*$)"}
> +-config=MC3A2.R2.1,+reports={safe,"first_area(^.*incompatible with labeled statement$)"}
>  -doc_end
>  
>  -doc_begin="Some functions are intended to be not referenced."
> --config=MC3R1.R2.1,+reports={deliberate,"first_area(^.*is never referenced$)"}
> +-config=MC3A2.R2.1,+reports={deliberate,"first_area(^.*is never referenced$)"}
>  -doc_end
>  
>  -doc_begin="Unreachability caused by calls to the following functions or macros is deliberate and there is no risk of code being unexpectedly left out."
> --config=MC3R1.R2.1,statements+={deliberate,"macro(name(BUG||assert_failed))"}
> --config=MC3R1.R2.1,statements+={deliberate, "call(decl(name(__builtin_unreachable||panic||do_unexpected_trap||machine_halt||machine_restart||reboot_or_halt)))"}
> +-config=MC3A2.R2.1,statements+={deliberate,"macro(name(BUG||assert_failed))"}
> +-config=MC3A2.R2.1,statements+={deliberate, "call(decl(name(__builtin_unreachable||panic||do_unexpected_trap||machine_halt||machine_restart||reboot_or_halt)))"}
>  -doc_end
>  
>  -doc_begin="Unreachability inside an ASSERT_UNREACHABLE() and analogous macro calls is deliberate and safe."
> --config=MC3R1.R2.1,reports+={deliberate, "any_area(any_loc(any_exp(macro(name(ASSERT_UNREACHABLE||PARSE_ERR_RET||PARSE_ERR||FAIL_MSR||FAIL_CPUID)))))"}
> +-config=MC3A2.R2.1,reports+={deliberate, "any_area(any_loc(any_exp(macro(name(ASSERT_UNREACHABLE||PARSE_ERR_RET||PARSE_ERR||FAIL_MSR||FAIL_CPUID)))))"}
>  -doc_end
>  
>  -doc_begin="The asm-offset files are not linked deliberately, since they are used to generate definitions for asm modules."
>  -file_tag+={asm_offsets, "^xen/arch/(arm|x86)/(arm32|arm64|x86_64)/asm-offsets\\.c$"}
> --config=MC3R1.R2.1,reports+={deliberate, "any_area(any_loc(file(asm_offsets)))"}
> +-config=MC3A2.R2.1,reports+={deliberate, "any_area(any_loc(file(asm_offsets)))"}
>  -doc_end
>  
>  -doc_begin="Pure declarations (i.e., declarations without initialization) are
>  not executable, and therefore it is safe for them to be unreachable."
> --config=MC3R1.R2.1,ignored_stmts+={"any()", "pure_decl()"}
> +-config=MC3A2.R2.1,ignored_stmts+={"any()", "pure_decl()"}
>  -doc_end
>  
>  -doc_begin="The following autogenerated file is not linked deliberately."
>  -file_tag+={C_runtime_failures,"^automation/eclair_analysis/C-runtime-failures\\.rst\\.c$"}
> --config=MC3R1.R2.1,reports+={deliberate, "any_area(any_loc(file(C_runtime_failures)))"}
> +-config=MC3A2.R2.1,reports+={deliberate, "any_area(any_loc(file(C_runtime_failures)))"}
>  -doc_end
>  
>  -doc_begin="Proving compliance with respect to Rule 2.2 is generally impossible:
> @@ -42,11 +42,11 @@ confidence that no evidence of errors in the program's logic has been missed due
>  to undetected violations of Rule 2.2, if any. Testing on time behavior gives us
>  confidence on the fact that, should the program contain dead code that is not
>  removed by the compiler, the resulting slowdown is negligible."
> --config=MC3R1.R2.2,reports+={disapplied,"any()"}
> +-config=MC3A2.R2.2,reports+={disapplied,"any()"}
>  -doc_end
>  
>  -doc_begin="Some labels are unused in certain build configurations, or are deliberately marked as unused, so that the compiler is entitled to remove them."
> --config=MC3R1.R2.6,reports+={deliberate, "any_area(text(^.*__maybe_unused.*$))"}
> +-config=MC3A2.R2.6,reports+={deliberate, "any_area(text(^.*__maybe_unused.*$))"}
>  -doc_end
>  
>  #
> @@ -55,7 +55,7 @@ removed by the compiler, the resulting slowdown is negligible."
>  
>  -doc_begin="Comments starting with '/*' and containing hyperlinks are safe as
>  they are not instances of commented-out code."
> --config=MC3R1.R3.1,reports+={safe, "first_area(text(^.*https?://.*$))"}
> +-config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*https?://.*$))"}
>  -doc_end
>  
>  #
> @@ -63,25 +63,25 @@ they are not instances of commented-out code."
>  #
>  
>  -doc_begin="The directive has been accepted only for the ARM codebase."
> --config=MC3R1.D4.3,reports+={disapplied,"!(any_area(any_loc(file(^xen/arch/arm/arm64/.*$))))"}
> +-config=MC3A2.D4.3,reports+={disapplied,"!(any_area(any_loc(file(^xen/arch/arm/arm64/.*$))))"}
>  -doc_end
>  
>  -doc_begin="The inline asm in 'arm64/lib/bitops.c' is tightly coupled with the surronding C code that acts as a wrapper, so it has been decided not to add an additional encapsulation layer."
>  -file_tag+={arm64_bitops, "^xen/arch/arm/arm64/lib/bitops\\.c$"}
> --config=MC3R1.D4.3,reports+={deliberate, "all_area(any_loc(file(arm64_bitops)&&any_exp(macro(^(bit|test)op$))))"}
> --config=MC3R1.D4.3,reports+={deliberate, "any_area(any_loc(file(arm64_bitops))&&context(name(int_clear_mask16)))"}
> +-config=MC3A2.D4.3,reports+={deliberate, "all_area(any_loc(file(arm64_bitops)&&any_exp(macro(^(bit|test)op$))))"}
> +-config=MC3A2.D4.3,reports+={deliberate, "any_area(any_loc(file(arm64_bitops))&&context(name(int_clear_mask16)))"}
>  -doc_end
>  
>  -doc_begin="Files that are intended to be included more than once do not need to
>  conform to the directive."
> --config=MC3R1.D4.10,reports+={safe, "first_area(text(^/\\* This file is legitimately included multiple times\\. \\*/$, begin-4))"}
> --config=MC3R1.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not edit! \\*/$, begin-3))"}
> --config=MC3R1.D4.10,reports+={safe, "all_area(all_loc(file(^xen/include/generated/autoconf.h$)))"}
> +-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* This file is legitimately included multiple times\\. \\*/$, begin-4))"}
> +-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not edit! \\*/$, begin-3))"}
> +-config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(file(^xen/include/generated/autoconf.h$)))"}
>  -doc_end
>  
>  -doc_begin="Including multiple times a .c file is safe because every function or data item
>  it defines would (in the common case) be already defined. Peer reviewed by the community."
> --config=MC3R1.D4.10,reports+={safe, "all_area(all_loc(^.*\\.c$))"}
> +-config=MC3A2.D4.10,reports+={safe, "all_area(all_loc(^.*\\.c$))"}
>  -doc_end
>  
>  #
> @@ -90,50 +90,50 @@ it defines would (in the common case) be already defined. Peer reviewed by the c
>  
>  -doc_begin="The project adopted the rule with an exception listed in
>  'docs/misra/rules.rst'"
> --config=MC3R1.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^READ_SYSREG$))&&any_exp(macro(^WRITE_SYSREG$))))"}
> --config=MC3R1.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^max(_t)?$))&&any_exp(macro(^min(_t)?$))))"}
> --config=MC3R1.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^read[bwlq]$))&&any_exp(macro(^read[bwlq]_relaxed$))))"}
> --config=MC3R1.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^per_cpu$))&&any_exp(macro(^this_cpu$))))"}
> --config=MC3R1.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^__emulate_2op$))&&any_exp(macro(^__emulate_2op_nobyte$))))"}
> --config=MC3R1.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^read_debugreg$))&&any_exp(macro(^write_debugreg$))))"}
> +-config=MC3A2.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^READ_SYSREG$))&&any_exp(macro(^WRITE_SYSREG$))))"}
> +-config=MC3A2.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^max(_t)?$))&&any_exp(macro(^min(_t)?$))))"}
> +-config=MC3A2.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^read[bwlq]$))&&any_exp(macro(^read[bwlq]_relaxed$))))"}
> +-config=MC3A2.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^per_cpu$))&&any_exp(macro(^this_cpu$))))"}
> +-config=MC3A2.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^__emulate_2op$))&&any_exp(macro(^__emulate_2op_nobyte$))))"}
> +-config=MC3A2.R5.3,reports+={safe, "any_area(any_loc(any_exp(macro(^read_debugreg$))&&any_exp(macro(^write_debugreg$))))"}
>  -doc_end
>  
>  -doc_begin="Macros expanding to their own identifier (e.g., \"#define x x\") are deliberate."
> --config=MC3R1.R5.5,reports+={deliberate, "all_area(macro(same_id_body())||!macro(!same_id_body()))"}
> +-config=MC3A2.R5.5,reports+={deliberate, "all_area(macro(same_id_body())||!macro(!same_id_body()))"}
>  -doc_end
>  
>  -doc_begin="There is no clash between function like macros and not callable objects."
> --config=MC3R1.R5.5,reports+={deliberate, "all_area(macro(function_like())||decl(any()))&&all_area(macro(any())||!decl(kind(function))&&!decl(__function_pointer_decls))"}
> +-config=MC3A2.R5.5,reports+={deliberate, "all_area(macro(function_like())||decl(any()))&&all_area(macro(any())||!decl(kind(function))&&!decl(__function_pointer_decls))"}
>  -doc_end
>  
>  -doc_begin="Clashes between function names and macros are deliberate for string handling functions since some architectures may want to use their own arch-specific implementation."
> --config=MC3R1.R5.5,reports+={deliberate, "all_area(all_loc(file(^xen/arch/x86/string\\.c|xen/include/xen/string\\.h|xen/lib/.*$)))"}
> +-config=MC3A2.R5.5,reports+={deliberate, "all_area(all_loc(file(^xen/arch/x86/string\\.c|xen/include/xen/string\\.h|xen/lib/.*$)))"}
>  -doc_end
>  
>  -doc_begin="In libelf, clashes between macros and function names are deliberate and needed to prevent the use of undecorated versions of memcpy, memset and memmove."
> --config=MC3R1.R5.5,reports+={deliberate, "any_area(decl(kind(function))||any_loc(macro(name(memcpy||memset||memmove))))&&any_area(any_loc(file(^xen/common/libelf/libelf-private\\.h$)))"}
> +-config=MC3A2.R5.5,reports+={deliberate, "any_area(decl(kind(function))||any_loc(macro(name(memcpy||memset||memmove))))&&any_area(any_loc(file(^xen/common/libelf/libelf-private\\.h$)))"}
>  -doc_end
>  
>  -doc_begin="The type \"ret_t\" is deliberately defined multiple times,
>  depending on the guest."
> --config=MC3R1.R5.6,reports+={deliberate,"any_area(any_loc(text(^.*ret_t.*$)))"}
> +-config=MC3A2.R5.6,reports+={deliberate,"any_area(any_loc(text(^.*ret_t.*$)))"}
>  -doc_end
>  
>  -doc_begin="On X86, the types \"guest_intpte_t\", \"guest_l1e_t\" and
>  \"guest_l2e_t\" are deliberately defined multiple times, depending on the
>  number of guest paging levels."
> --config=MC3R1.R5.6,reports+={deliberate,"any_area(any_loc(file(^xen/arch/x86/include/asm/guest_pt\\.h$)))&&any_area(any_loc(text(^.*(guest_intpte_t|guest_l[12]e_t).*$)))"}
> +-config=MC3A2.R5.6,reports+={deliberate,"any_area(any_loc(file(^xen/arch/x86/include/asm/guest_pt\\.h$)))&&any_area(any_loc(text(^.*(guest_intpte_t|guest_l[12]e_t).*$)))"}
>  -doc_end
>  
>  -doc_begin="The following files are imported from the gnu-efi package."
>  -file_tag+={adopted_r5_6,"^xen/include/efi/.*$"}
>  -file_tag+={adopted_r5_6,"^xen/arch/.*/include/asm/.*/efibind\\.h$"}
> --config=MC3R1.R5.6,reports+={deliberate,"any_area(any_loc(file(adopted_r5_6)))"}
> +-config=MC3A2.R5.6,reports+={deliberate,"any_area(any_loc(file(adopted_r5_6)))"}
>  -doc_end
>  
>  -doc_begin="The project intentionally reuses tag names in order to have identifiers matching the applicable external specifications as well as established internal conventions.
>  As there is little possibility for developer confusion not resulting into compilation errors, the risk of renaming outweighs the potential advantages of compliance."
> --config=MC3R1.R5.7,reports+={deliberate,"any()"}
> +-config=MC3A2.R5.7,reports+={deliberate,"any()"}
>  -doc_end
>  
>  #
> @@ -142,7 +142,7 @@ As there is little possibility for developer confusion not resulting into compil
>  
>  -doc_begin="It is safe to use certain octal constants the way they are defined
>  in specifications, manuals, and algorithm descriptions."
> --config=MC3R1.R7.1,reports+={safe, "any_area(any_loc(any_exp(text(^.*octal-ok.*$))))"}
> +-config=MC3A2.R7.1,reports+={safe, "any_area(any_loc(any_exp(text(^.*octal-ok.*$))))"}
>  -doc_end
>  
>  -doc_begin="Violations in files that maintainers have asked to not modify in the
> @@ -155,17 +155,17 @@ context of R7.2."
>  -file_tag+={adopted_r7_2,"^xen/arch/x86/cpu/intel\\.c$"}
>  -file_tag+={adopted_r7_2,"^xen/arch/x86/cpu/amd\\.c$"}
>  -file_tag+={adopted_r7_2,"^xen/arch/x86/cpu/common\\.c$"}
> --config=MC3R1.R7.2,reports+={deliberate,"any_area(any_loc(file(adopted_r7_2)))"}
> +-config=MC3A2.R7.2,reports+={deliberate,"any_area(any_loc(file(adopted_r7_2)))"}
>  -doc_end
>  
>  -doc_begin="Violations caused by __HYPERVISOR_VIRT_START are related to the
>  particular use of it done in xen_mk_ulong."
> --config=MC3R1.R7.2,reports+={deliberate,"any_area(any_loc(macro(name(BUILD_BUG_ON))))"}
> +-config=MC3A2.R7.2,reports+={deliberate,"any_area(any_loc(macro(name(BUILD_BUG_ON))))"}
>  -doc_end
>  
>  -doc_begin="Allow pointers of non-character type as long as the pointee is
>  const-qualified."
> --config=MC3R1.R7.4,same_pointee=false
> +-config=MC3A2.R7.4,same_pointee=false
>  -doc_end
>  
>  #
> @@ -173,7 +173,7 @@ const-qualified."
>  #
>  
>  -doc_begin="The type ret_t is deliberately used and defined as int or long depending on the architecture."
> --config=MC3R1.R8.3,reports+={deliberate,"any_area(any_loc(text(^.*ret_t.*$)))"}
> +-config=MC3A2.R8.3,reports+={deliberate,"any_area(any_loc(text(^.*ret_t.*$)))"}
>  -doc_end
>  
>  -doc_begin="The following files are imported from Linux and decompress.h defines a unique and documented interface towards all the (adopted) decompress functions."
> @@ -183,71 +183,71 @@ const-qualified."
>  -file_tag+={adopted_decompress_r8_3,"^xen/common/unlzo\\.c$"}
>  -file_tag+={adopted_decompress_r8_3,"^xen/common/unxz\\.c$"}
>  -file_tag+={adopted_decompress_r8_3,"^xen/common/unzstd\\.c$"}
> --config=MC3R1.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_decompress_r8_3)))&&any_area(any_loc(file(^xen/include/xen/decompress\\.h$)))"}
> +-config=MC3A2.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_decompress_r8_3)))&&any_area(any_loc(file(^xen/include/xen/decompress\\.h$)))"}
>  -doc_end
>  
>  -doc_begin="Parameter name \"unused\" (with an optional numeric suffix) is deliberate and makes explicit the intention of not using such parameter within the function."
> --config=MC3R1.R8.3,reports+={deliberate, "any_area(^.*parameter `unused[0-9]*'.*$)"}
> +-config=MC3A2.R8.3,reports+={deliberate, "any_area(^.*parameter `unused[0-9]*'.*$)"}
>  -doc_end
>  
>  -doc_begin="The following file is imported from Linux: ignore for now."
>  -file_tag+={adopted_time_r8_3,"^xen/arch/x86/time\\.c$"}
> --config=MC3R1.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_time_r8_3)))&&(any_area(any_loc(file(^xen/include/xen/time\\.h$)))||any_area(any_loc(file(^xen/arch/x86/include/asm/setup\\.h$))))"}
> +-config=MC3A2.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_time_r8_3)))&&(any_area(any_loc(file(^xen/include/xen/time\\.h$)))||any_area(any_loc(file(^xen/arch/x86/include/asm/setup\\.h$))))"}
>  -doc_end
>  
>  -doc_begin="The following file is imported from Linux: ignore for now."
>  -file_tag+={adopted_cpu_idle_r8_3,"^xen/arch/x86/acpi/cpu_idle\\.c$"}
> --config=MC3R1.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_cpu_idle_r8_3)))&&any_area(any_loc(file(^xen/include/xen/pmstat\\.h$)))"}
> +-config=MC3A2.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_cpu_idle_r8_3)))&&any_area(any_loc(file(^xen/include/xen/pmstat\\.h$)))"}
>  -doc_end
>  
>  -doc_begin="The following file is imported from Linux: ignore for now."
>  -file_tag+={adopted_mpparse_r8_3,"^xen/arch/x86/mpparse\\.c$"}
> --config=MC3R1.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_mpparse_r8_3)))&&any_area(any_loc(file(^xen/arch/x86/include/asm/mpspec\\.h$)))"}
> +-config=MC3A2.R8.3,reports+={deliberate,"any_area(any_loc(file(adopted_mpparse_r8_3)))&&any_area(any_loc(file(^xen/arch/x86/include/asm/mpspec\\.h$)))"}
>  -doc_end
>  
>  -doc_begin="The definitions present in this file are meant to generate definitions for asm modules, and are not called by C code. Therefore the absence of prior declarations is safe."
>  -file_tag+={asm_offsets, "^xen/arch/(arm|x86)/(arm32|arm64|x86_64)/asm-offsets\\.c$"}
> --config=MC3R1.R8.4,reports+={safe, "first_area(any_loc(file(asm_offsets)))"}
> +-config=MC3A2.R8.4,reports+={safe, "first_area(any_loc(file(asm_offsets)))"}
>  -doc_end
>  
>  -doc_begin="The functions defined in this file are meant to be called from gcc-generated code in a non-release build configuration.
>  Therefore the absence of prior declarations is safe."
>  -file_tag+={gcov, "^xen/common/coverage/gcov_base\\.c$"}
> --config=MC3R1.R8.4,reports+={safe, "first_area(any_loc(file(gcov)))"}
> +-config=MC3A2.R8.4,reports+={safe, "first_area(any_loc(file(gcov)))"}
>  -doc_end
>  
>  -doc_begin="Recognize the occurrence of current_stack_pointer as a declaration."
>  -file_tag+={asm_defns, "^xen/arch/x86/include/asm/asm_defns\\.h$"}
> --config=MC3R1.R8.4,declarations+={safe, "loc(file(asm_defns))&&^current_stack_pointer$"}
> +-config=MC3A2.R8.4,declarations+={safe, "loc(file(asm_defns))&&^current_stack_pointer$"}
>  -doc_end
>  
>  -doc_begin="The function apei_(read|check|clear)_mce are dead code and are excluded from non-debug builds, therefore the absence of prior declarations is safe."
> --config=MC3R1.R8.4,declarations+={safe, "^apei_(read|check|clear)_mce\\(.*$"}
> +-config=MC3A2.R8.4,declarations+={safe, "^apei_(read|check|clear)_mce\\(.*$"}
>  -doc_end
>  
>  -doc_begin="asmlinkage is a marker to indicate that the function is only used to interface with asm modules."
> --config=MC3R1.R8.4,declarations+={safe,"loc(text(^(?s).*asmlinkage.*$, -1..0))"}
> +-config=MC3A2.R8.4,declarations+={safe,"loc(text(^(?s).*asmlinkage.*$, -1..0))"}
>  -doc_end
>  
>  -doc_begin="Given that bsearch and sort are defined with the attribute 'gnu_inline', it's deliberate not to have a prior declaration.
>  See Section \"6.33.1 Common Function Attributes\" of \"GCC_MANUAL\" for a full explanation of gnu_inline."
>  -file_tag+={bsearch_sort, "^xen/include/xen/(sort|lib)\\.h$"}
> --config=MC3R1.R8.4,reports+={deliberate, "any_area(any_loc(file(bsearch_sort))&&decl(name(bsearch||sort)))"}
> +-config=MC3A2.R8.4,reports+={deliberate, "any_area(any_loc(file(bsearch_sort))&&decl(name(bsearch||sort)))"}
>  -doc_end
>  
>  -doc_begin="first_valid_mfn is defined in this way because the current lack of NUMA support in Arm and PPC requires it."
>  -file_tag+={first_valid_mfn, "^xen/common/page_alloc\\.c$"}
> --config=MC3R1.R8.4,declarations+={deliberate,"loc(file(first_valid_mfn))"}
> +-config=MC3A2.R8.4,declarations+={deliberate,"loc(file(first_valid_mfn))"}
>  -doc_end
>  
>  -doc_begin="The following variables are compiled in multiple translation units
>  belonging to different executables and therefore are safe."
> --config=MC3R1.R8.6,declarations+={safe, "name(current_stack_pointer||bsearch||sort)"}
> +-config=MC3A2.R8.6,declarations+={safe, "name(current_stack_pointer||bsearch||sort)"}
>  -doc_end
>  
>  -doc_begin="Declarations without definitions are allowed (specifically when the
>  definition is compiled-out or optimized-out by the compiler)"
> --config=MC3R1.R8.6,reports+={deliberate, "first_area(^.*has no definition$)"}
> +-config=MC3A2.R8.6,reports+={deliberate, "first_area(^.*has no definition$)"}
>  -doc_end
>  
>  -doc_begin="The search procedure for Unix linkers is well defined, see ld(1)
> @@ -258,11 +258,11 @@ the linker will include the appropriate file(s) from the archive\".
>  In Xen, thanks to the order in which file names appear in the build commands,
>  if arch-specific definitions are present, they get always linked in before
>  searching in the lib.a archive resulting from xen/lib."
> --config=MC3R1.R8.6,declarations+={deliberate, "loc(file(^xen/lib/.*$))"}
> +-config=MC3A2.R8.6,declarations+={deliberate, "loc(file(^xen/lib/.*$))"}
>  -doc_end
>  
>  -doc_begin="The gnu_inline attribute without static is deliberately allowed."
> --config=MC3R1.R8.10,declarations+={deliberate,"property(gnu_inline)"}
> +-config=MC3A2.R8.10,declarations+={deliberate,"property(gnu_inline)"}
>  -doc_end
>  
>  #
> @@ -272,12 +272,12 @@ searching in the lib.a archive resulting from xen/lib."
>  -doc_begin="Violations in files that maintainers have asked to not modify in the
>  context of R9.1."
>  -file_tag+={adopted_r9_1,"^xen/arch/arm/arm64/lib/find_next_bit\\.c$"}
> --config=MC3R1.R9.1,reports+={deliberate,"any_area(any_loc(file(adopted_r9_1)))"}
> +-config=MC3A2.R9.1,reports+={deliberate,"any_area(any_loc(file(adopted_r9_1)))"}
>  -doc_end
>  
>  -doc_begin="The possibility of committing mistakes by specifying an explicit
>  dimension is higher than omitting the dimension."
> --config=MC3R1.R9.5,reports+={deliberate, "any()"}
> +-config=MC3A2.R9.5,reports+={deliberate, "any()"}
>  -doc_end
>  
>  #
> @@ -285,45 +285,45 @@ dimension is higher than omitting the dimension."
>  #
>  
>  -doc_begin="The value-preserving conversions of integer constants are safe"
> --config=MC3R1.R10.1,etypes={safe,"any()","preserved_integer_constant()"}
> --config=MC3R1.R10.3,etypes={safe,"any()","preserved_integer_constant()"}
> --config=MC3R1.R10.4,etypes={safe,"any()","preserved_integer_constant()||sibling(rhs,preserved_integer_constant())"}
> +-config=MC3A2.R10.1,etypes={safe,"any()","preserved_integer_constant()"}
> +-config=MC3A2.R10.3,etypes={safe,"any()","preserved_integer_constant()"}
> +-config=MC3A2.R10.4,etypes={safe,"any()","preserved_integer_constant()||sibling(rhs,preserved_integer_constant())"}
>  -doc_end
>  
>  -doc_begin="Shifting non-negative integers to the right is safe."
> --config=MC3R1.R10.1,etypes+={safe,
> +-config=MC3A2.R10.1,etypes+={safe,
>    "stmt(node(binary_operator)&&operator(shr))",
>    "src_expr(definitely_in(0..))"}
>  -doc_end
>  
>  -doc_begin="Shifting non-negative integers to the left is safe if the result is
>  still non-negative."
> --config=MC3R1.R10.1,etypes+={safe,
> +-config=MC3A2.R10.1,etypes+={safe,
>    "stmt(node(binary_operator)&&operator(shl)&&definitely_in(0..))",
>    "src_expr(definitely_in(0..))"}
>  -doc_end
>  
>  -doc_begin="Bitwise logical operations on non-negative integers are safe."
> --config=MC3R1.R10.1,etypes+={safe,
> +-config=MC3A2.R10.1,etypes+={safe,
>    "stmt(node(binary_operator)&&operator(and||or||xor))",
>    "src_expr(definitely_in(0..))"}
>  -doc_end
>  
>  -doc_begin="The implicit conversion to Boolean for logical operator arguments is well known to all Xen developers to be a comparison with 0"
> --config=MC3R1.R10.1,etypes+={safe, "stmt(operator(logical)||node(conditional_operator||binary_conditional_operator))", "dst_type(ebool||boolean)"}
> +-config=MC3A2.R10.1,etypes+={safe, "stmt(operator(logical)||node(conditional_operator||binary_conditional_operator))", "dst_type(ebool||boolean)"}
>  -doc_end
>  
>  -doc_begin="The macro ISOLATE_LSB encapsulates a well-known pattern to obtain
>  a mask where only the lowest bit set in the argument is set, if any, for unsigned
>  integers arguments on two's complement architectures
>  (all the architectures supported by Xen satisfy this requirement)."
> --config=MC3R1.R10.1,reports+={safe, "any_area(any_loc(any_exp(macro(^ISOLATE_LSB$))))"}
> +-config=MC3A2.R10.1,reports+={safe, "any_area(any_loc(any_exp(macro(^ISOLATE_LSB$))))"}
>  -doc_end
>  
>  -doc_begin="XEN only supports architectures where signed integers are
>  representend using two's complement and all the XEN developers are aware of
>  this."
> --config=MC3R1.R10.1,etypes+={safe,
> +-config=MC3A2.R10.1,etypes+={safe,
>    "stmt(operator(and||or||xor||not||and_assign||or_assign||xor_assign))",
>    "any()"}
>  -doc_end
> @@ -334,7 +334,7 @@ C language, GCC does not use the latitude given in C99 and C11 only to treat
>  certain aspects of signed `<<' as undefined. However, -fsanitize=shift (and
>  -fsanitize=undefined) will diagnose such cases. They are also diagnosed where
>  constant expressions are required.\""
> --config=MC3R1.R10.1,etypes+={safe,
> +-config=MC3A2.R10.1,etypes+={safe,
>    "stmt(operator(shl||shr||shl_assign||shr_assign))",
>    "any()"}
>  -doc_end
> @@ -344,7 +344,7 @@ constant expressions are required.\""
>  #
>  
>  -doc_begin="The conversion from a function pointer to unsigned long or (void *) does not lose any information, provided that the target type has enough bits to store it."
> --config=MC3R1.R11.1,casts+={safe,
> +-config=MC3A2.R11.1,casts+={safe,
>    "from(type(canonical(__function_pointer_types)))
>     &&to(type(canonical(builtin(unsigned long)||pointer(builtin(void)))))
>     &&relation(definitely_preserves_value)"
> @@ -352,14 +352,14 @@ constant expressions are required.\""
>  -doc_end
>  
>  -doc_begin="The conversion from a function pointer to a boolean has a well-known semantics that do not lead to unexpected behaviour."
> --config=MC3R1.R11.1,casts+={safe,
> +-config=MC3A2.R11.1,casts+={safe,
>    "from(type(canonical(__function_pointer_types)))
>     &&kind(pointer_to_boolean)"
>  }
>  -doc_end
>  
>  -doc_begin="The conversion from a pointer to an incomplete type to unsigned long does not lose any information, provided that the target type has enough bits to store it."
> --config=MC3R1.R11.2,casts+={safe,
> +-config=MC3A2.R11.2,casts+={safe,
>    "from(type(any()))
>     &&to(type(canonical(builtin(unsigned long))))
>     &&relation(definitely_preserves_value)"
> @@ -367,20 +367,20 @@ constant expressions are required.\""
>  -doc_end
>  
>  -doc_begin="Conversions to object pointers that have a pointee type with a smaller (i.e., less strict) alignment requirement are safe."
> --config=MC3R1.R11.3,casts+={safe,
> +-config=MC3A2.R11.3,casts+={safe,
>    "!relation(more_aligned_pointee)"
>  }
>  -doc_end
>  
>  -doc_begin="Conversions from and to integral types are safe, in the assumption that the target type has enough bits to store the value.
>  See also Section \"4.7 Arrays and Pointers\" of \"GCC_MANUAL\""
> --config=MC3R1.R11.6,casts+={safe,
> +-config=MC3A2.R11.6,casts+={safe,
>      "(from(type(canonical(integral())))||to(type(canonical(integral()))))
>       &&relation(definitely_preserves_value)"}
>  -doc_end
>  
>  -doc_begin="The conversion from a pointer to a boolean has a well-known semantics that do not lead to unexpected behaviour."
> --config=MC3R1.R11.6,casts+={safe,
> +-config=MC3A2.R11.6,casts+={safe,
>    "from(type(canonical(__pointer_types)))
>     &&kind(pointer_to_boolean)"
>  }
> @@ -390,11 +390,11 @@ See also Section \"4.7 Arrays and Pointers\" of \"GCC_MANUAL\""
>  with the provided offset. The resulting pointer is then immediately cast back to its
>  original type, which preserves the qualifier. This use is deemed safe.
>  Fixing this violation would require to increase code complexity and lower readability."
> --config=MC3R1.R11.8,reports+={safe,"any_area(any_loc(any_exp(macro(^container_of$))))"}
> +-config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(any_exp(macro(^container_of$))))"}
>  -doc_end
>  
>  -doc_begin="This construct is used to check if the type is scalar, and for this purpose the use of 0 as a null pointer constant is deliberate."
> --config=MC3R1.R11.9,reports+={deliberate, "any_area(any_loc(any_exp(macro(^__ACCESS_ONCE$))))"
> +-config=MC3A2.R11.9,reports+={deliberate, "any_area(any_loc(any_exp(macro(^__ACCESS_ONCE$))))"
>  }
>  -doc_end
>  
> @@ -404,16 +404,16 @@ Fixing this violation would require to increase code complexity and lower readab
>  
>  -doc_begin="All developers and reviewers can be safely assumed to be well aware
>  of the short-circuit evaluation strategy of such logical operators."
> --config=MC3R1.R13.5,reports+={disapplied,"any()"}
> +-config=MC3A2.R13.5,reports+={disapplied,"any()"}
>  -doc_end
>  
>  -doc_begin="Macros alternative_v?call[0-9] use sizeof and typeof to check that the argument types match the corresponding parameter ones."
> --config=MC3R1.R13.6,reports+={deliberate,"any_area(any_loc(any_exp(macro(^alternative_vcall[0-9]$))&&file(^xen/arch/x86/include/asm/alternative\\.h*$)))"}
> +-config=MC3A2.R13.6,reports+={deliberate,"any_area(any_loc(any_exp(macro(^alternative_vcall[0-9]$))&&file(^xen/arch/x86/include/asm/alternative\\.h*$)))"}
>  -config=B.UNEVALEFF,reports+={deliberate,"any_area(any_loc(any_exp(macro(^alternative_v?call[0-9]$))&&file(^xen/arch/x86/include/asm/alterantive\\.h*$)))"}
>  -doc_end
>  
>  -doc_begin="Anything, no matter how complicated, inside the BUILD_BUG_ON macro is subject to a compile-time evaluation without relevant side effects."
> --config=MC3R1.R13.6,reports+={safe,"any_area(any_loc(any_exp(macro(name(BUILD_BUG_ON)))))"}
> +-config=MC3A2.R13.6,reports+={safe,"any_area(any_loc(any_exp(macro(name(BUILD_BUG_ON)))))"}
>  -config=B.UNEVALEFF,reports+={safe,"any_area(any_loc(any_exp(macro(name(BUILD_BUG_ON)))))"}
>  -doc_end
>  
> @@ -424,31 +424,31 @@ of the short-circuit evaluation strategy of such logical operators."
>  -doc_begin="The severe restrictions imposed by this rule on the use of for
>  statements are not balanced by the presumed facilitation of the peer review
>  activity."
> --config=MC3R1.R14.2,reports+={disapplied,"any()"}
> +-config=MC3A2.R14.2,reports+={disapplied,"any()"}
>  -doc_end
>  
>  -doc_begin="The XEN team relies on the fact that invariant conditions of 'if' statements and conditional operators are deliberate"
> --config=MC3R1.R14.3,statements+={deliberate, "wrapped(any(),node(if_stmt||conditional_operator||binary_conditional_operator))" }
> +-config=MC3A2.R14.3,statements+={deliberate, "wrapped(any(),node(if_stmt||conditional_operator||binary_conditional_operator))" }
>  -doc_end
>  
>  -doc_begin="Switches having a 'sizeof' operator as the condition are deliberate and have limited scope."
> --config=MC3R1.R14.3,statements+={deliberate, "wrapped(any(),node(switch_stmt)&&child(cond, operator(sizeof)))" }
> +-config=MC3A2.R14.3,statements+={deliberate, "wrapped(any(),node(switch_stmt)&&child(cond, operator(sizeof)))" }
>  -doc_end
>  
>  -doc_begin="The use of an invariant size argument in {put,get}_unsafe_size and array_access_ok, as defined in arch/x86(_64)?/include/asm/uaccess.h is deliberate and is deemed safe."
>  -file_tag+={x86_uaccess, "^xen/arch/x86(_64)?/include/asm/uaccess\\.h$"}
> --config=MC3R1.R14.3,reports+={deliberate, "any_area(any_loc(file(x86_uaccess)&&any_exp(macro(^(put|get)_unsafe_size$))))"}
> --config=MC3R1.R14.3,reports+={deliberate, "any_area(any_loc(file(x86_uaccess)&&any_exp(macro(^array_access_ok$))))"}
> +-config=MC3A2.R14.3,reports+={deliberate, "any_area(any_loc(file(x86_uaccess)&&any_exp(macro(^(put|get)_unsafe_size$))))"}
> +-config=MC3A2.R14.3,reports+={deliberate, "any_area(any_loc(file(x86_uaccess)&&any_exp(macro(^array_access_ok$))))"}
>  -doc_end
>  
>  -doc_begin="A controlling expression of 'if' and iteration statements having integer, character or pointer type has a semantics that is well-known to all Xen developers."
> --config=MC3R1.R14.4,etypes+={deliberate, "any()", "src_type(integer||character)||src_expr(type(desugar(pointer(any()))))"}
> +-config=MC3A2.R14.4,etypes+={deliberate, "any()", "src_type(integer||character)||src_expr(type(desugar(pointer(any()))))"}
>  -doc_end
>  
>  -doc_begin="The XEN team relies on the fact that the enum is_dying has the
>  constant with assigned value 0 act as false and the other ones as true,
>  therefore have the same behavior of a boolean"
> --config=MC3R1.R14.4,etypes+={deliberate, "stmt(child(cond,child(expr,ref(^?::is_dying$))))","src_type(enum)"}
> +-config=MC3A2.R14.4,etypes+={deliberate, "stmt(child(cond,child(expr,ref(^?::is_dying$))))","src_type(enum)"}
>  -doc_end
>  
>  #
> @@ -459,58 +459,58 @@ therefore have the same behavior of a boolean"
>  therefore it is deemed better to leave such files as is."
>  -file_tag+={x86_emulate,"^xen/arch/x86/x86_emulate/.*$"}
>  -file_tag+={x86_svm_emulate,"^xen/arch/x86/hvm/svm/emulate\\.c$"}
> --config=MC3R1.R16.2,reports+={deliberate, "any_area(any_loc(file(x86_emulate||x86_svm_emulate)))"}
> +-config=MC3A2.R16.2,reports+={deliberate, "any_area(any_loc(file(x86_emulate||x86_svm_emulate)))"}
>  -doc_end
>  
>  -doc_begin="Statements that change the control flow (i.e., break, continue, goto, return) and calls to functions that do not return the control back are \"allowed terminal statements\"."
>  -stmt_selector+={r16_3_allowed_terminal, "node(break_stmt||continue_stmt||goto_stmt||return_stmt)||call(property(noreturn))"}
> --config=MC3R1.R16.3,terminals+={safe, "r16_3_allowed_terminal"}
> +-config=MC3A2.R16.3,terminals+={safe, "r16_3_allowed_terminal"}
>  -doc_end
>  
>  -doc_begin="An if-else statement having both branches ending with an allowed terminal statement is itself an allowed terminal statement."
>  -stmt_selector+={r16_3_if, "node(if_stmt)&&(child(then,r16_3_allowed_terminal)||child(then,any_stmt(stmt,-1,r16_3_allowed_terminal)))"}
>  -stmt_selector+={r16_3_else, "node(if_stmt)&&(child(else,r16_3_allowed_terminal)||child(else,any_stmt(stmt,-1,r16_3_allowed_terminal)))"}
>  -stmt_selector+={r16_3_if_else, "r16_3_if&&r16_3_else"}
> --config=MC3R1.R16.3,terminals+={safe, "r16_3_if_else"}
> +-config=MC3A2.R16.3,terminals+={safe, "r16_3_if_else"}
>  -doc_end
>  
>  -doc_begin="An if-else statement having an always true condition and the true branch ending with an allowed terminal statement is itself an allowed terminal statement."
>  -stmt_selector+={r16_3_if_true, "r16_3_if&&child(cond,definitely_in(1..))"}
> --config=MC3R1.R16.3,terminals+={safe, "r16_3_if_true"}
> +-config=MC3A2.R16.3,terminals+={safe, "r16_3_if_true"}
>  -doc_end
>  
>  -doc_begin="A switch clause ending with a statement expression which, in turn, ends with an allowed terminal statement is safe."
> --config=MC3R1.R16.3,terminals+={safe, "node(stmt_expr)&&child(stmt,node(compound_stmt)&&any_stmt(stmt,-1,r16_3_allowed_terminal||r16_3_if_else||r16_3_if_true))"}
> +-config=MC3A2.R16.3,terminals+={safe, "node(stmt_expr)&&child(stmt,node(compound_stmt)&&any_stmt(stmt,-1,r16_3_allowed_terminal||r16_3_if_else||r16_3_if_true))"}
>  -doc_end
>  
>  -doc_begin="A switch clause ending with a do-while-false the body of which, in turn, ends with an allowed terminal statement is safe.
>  An exception to that is the macro ASSERT_UNREACHABLE() which is effective in debug build only: a switch clause ending with ASSERT_UNREACHABLE() is not considered safe."
> --config=MC3R1.R16.3,terminals+={safe, "!macro(name(ASSERT_UNREACHABLE))&&node(do_stmt)&&child(cond,definitely_in(0))&&child(body,any_stmt(stmt,-1,r16_3_allowed_terminal||r16_3_if_else||r16_3_if_true))"}
> +-config=MC3A2.R16.3,terminals+={safe, "!macro(name(ASSERT_UNREACHABLE))&&node(do_stmt)&&child(cond,definitely_in(0))&&child(body,any_stmt(stmt,-1,r16_3_allowed_terminal||r16_3_if_else||r16_3_if_true))"}
>  -doc_end
>  
>  -doc_begin="Switch clauses ending with pseudo-keyword \"fallthrough\" are
>  safe."
> --config=MC3R1.R16.3,reports+={safe, "any_area(end_loc(any_exp(text(/fallthrough;/))))"}
> +-config=MC3A2.R16.3,reports+={safe, "any_area(end_loc(any_exp(text(/fallthrough;/))))"}
>  -doc_end
>  
>  -doc_begin="Switch clauses ending with failure method \"BUG()\" are safe."
> --config=MC3R1.R16.3,reports+={safe, "any_area(end_loc(any_exp(text(/BUG\\(\\);/))))"}
> +-config=MC3A2.R16.3,reports+={safe, "any_area(end_loc(any_exp(text(/BUG\\(\\);/))))"}
>  -doc_end
>  
>  -doc_begin="Switch clauses ending with an explicit comment indicating the fallthrough intention are safe."
> --config=MC3R1.R16.3,reports+={safe, "any_area(end_loc(any_exp(text(^(?s).*/\\* [fF]all ?through\\.? \\*/.*$,0..2))))"}
> +-config=MC3A2.R16.3,reports+={safe, "any_area(end_loc(any_exp(text(^(?s).*/\\* [fF]all ?through\\.? \\*/.*$,0..2))))"}
>  -doc_end
>  
>  -doc_begin="Switch statements having a controlling expression of enum type deliberately do not have a default case: gcc -Wall enables -Wswitch which warns (and breaks the build as we use -Werror) if one of the enum labels is missing from the switch."
> --config=MC3R1.R16.4,reports+={deliberate,'any_area(kind(context)&&^.* has no `default.*$&&stmt(node(switch_stmt)&&child(cond,skip(__non_syntactic_paren_stmts,type(canonical(enum_underlying_type(any())))))))'}
> +-config=MC3A2.R16.4,reports+={deliberate,'any_area(kind(context)&&^.* has no `default.*$&&stmt(node(switch_stmt)&&child(cond,skip(__non_syntactic_paren_stmts,type(canonical(enum_underlying_type(any())))))))'}
>  -doc_end
>  
>  -doc_begin="A switch statement with a single switch clause and no default label may be used in place of an equivalent if statement if it is considered to improve readability."
> --config=MC3R1.R16.4,switch_clauses+={deliberate,"switch(1)&&default(0)"}
> +-config=MC3A2.R16.4,switch_clauses+={deliberate,"switch(1)&&default(0)"}
>  -doc_end
>  
>  -doc_begin="A switch statement with a single switch clause and no default label may be used in place of an equivalent if statement if it is considered to improve readability."
> --config=MC3R1.R16.6,switch_clauses+={deliberate, "default(0)"}
> +-config=MC3A2.R16.6,switch_clauses+={deliberate, "default(0)"}
>  -doc_end
>  
>  #
> @@ -518,16 +518,16 @@ safe."
>  #
>  
>  -doc_begin="printf()-like functions are allowed to use the variadic features provided by stdarg.h."
> --config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printk\\(.*\\)$)))"}
> --config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printf\\(.*\\)$)))"}
> --config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"}
> --config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"}
> --config=MC3R1.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"}
> --config=MC3R1.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"}
> +-config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printk\\(.*\\)$)))"}
> +-config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printf\\(.*\\)$)))"}
> +-config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"}
> +-config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"}
> +-config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"}
> +-config=MC3A2.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"}
>  -doc_end
>  
>  -doc_begin="Not using the return value of a function does not endanger safety if it coincides with an actual argument."
> --config=MC3R1.R17.7,calls+={safe, "any()", "decl(name(__builtin_memcpy||__builtin_memmove||__builtin_memset||cpumask_check))"}
> +-config=MC3A2.R17.7,calls+={safe, "any()", "decl(name(__builtin_memcpy||__builtin_memmove||__builtin_memset||cpumask_check))"}
>  -doc_end
>  
>  #
> @@ -538,16 +538,16 @@ safe."
>  are guaranteed not to be exploited by a compiler that relies on the absence of
>  C99 Undefined Behaviour 45: Pointers that do not point into, or just beyond, the same array object are subtracted (6.5.6)."
>  -eval_file=linker_symbols.ecl
> --config=MC3R1.R18.2,reports+={safe, "any_area(stmt(operator(sub)&&child(lhs||rhs, skip(__non_syntactic_paren_stmts, ref(linker_symbols)))))"}
> +-config=MC3A2.R18.2,reports+={safe, "any_area(stmt(operator(sub)&&child(lhs||rhs, skip(__non_syntactic_paren_stmts, ref(linker_symbols)))))"}
>  -doc_end
>  
>  -doc_begin="The following macro performs a subtraction between pointers to obtain the mfn, but does not lead to undefined behaviour."
> --config=MC3R1.R18.2,reports+={safe, "any_area(any_loc(any_exp(macro(^page_to_mfn$))))"}
> +-config=MC3A2.R18.2,reports+={safe, "any_area(any_loc(any_exp(macro(^page_to_mfn$))))"}
>  -doc_end
>  
>  -doc_begin="Flexible array members are deliberately used and XEN developers are aware of the dangers related to them:
>  unexpected result when the structure is given as argument to a sizeof() operator and the truncation in assignment between structures."
> --config=MC3R1.R18.7,reports+={deliberate, "any()"}
> +-config=MC3A2.R18.7,reports+={deliberate, "any()"}
>  -doc_end
>  
>  #
> @@ -558,7 +558,7 @@ unexpected result when the structure is given as argument to a sizeof() operator
>  as function arguments; (2) as macro arguments; (3) as array indices; (4) as lhs
>  in assignments; (5) as initializers, possibly designated, in initalizer lists;
>  (6) as the constant expression in a switch clause label."
> --config=MC3R1.R20.7,expansion_context=
> +-config=MC3A2.R20.7,expansion_context=
>  {safe, "context(__call_expr_arg_contexts)"},
>  {safe, "left_right(^[(,\\[]$,^[),\\]]$)"},
>  {safe, "context(skip_to(__expr_non_syntactic_contexts, stmt_child(node(array_subscript_expr), subscript)))"},
> @@ -571,62 +571,62 @@ in assignments; (5) as initializers, possibly designated, in initalizer lists;
>  breaking the macro's logic; futhermore, the macro is only ever used in the context
>  of the IS_ENABLED or STATIC_IF/STATIC_IF_NOT macros, so it always receives a literal
>  0 or 1 as input, posing no risk to safety."
> --config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^___config_enabled$))))"}
> +-config=MC3A2.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^___config_enabled$))))"}
>  -doc_end
>  
>  -doc_begin="Violations due to the use of macros defined in files that are
>  not in scope for compliance are allowed, as that is imported code."
>  -file_tag+={gnu_efi_include, "^xen/include/efi/.*$"}
>  -file_tag+={acpi_cpu_idle, "^xen/arch/x86/acpi/cpu_idle\\.c$"}
> --config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(file(gnu_efi_include)||any_exp(macro(^NextMemoryDescriptor$))))"}
> --config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(file(acpi_cpu_idle)))"}
> +-config=MC3A2.R20.7,reports+={safe, "any_area(any_loc(file(gnu_efi_include)||any_exp(macro(^NextMemoryDescriptor$))))"}
> +-config=MC3A2.R20.7,reports+={safe, "any_area(any_loc(file(acpi_cpu_idle)))"}
>  -doc_end
>  
>  -doc_begin="To avoid compromising readability, the macros alternative_(v)?call[0-9] are allowed
>  not to parenthesize their arguments."
> --config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^alternative_(v)?call[0-9]$))))"}
> +-config=MC3A2.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^alternative_(v)?call[0-9]$))))"}
>  -doc_end
>  
>  -doc_begin="The argument 'x' of the count_args_ macro can't be parenthesized as
>  the rule would require, without breaking the functionality of the macro. The uses
>  of this macro do not lead to developer confusion, and can thus be deviated."
> --config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^count_args_$))))"}
> +-config=MC3A2.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^count_args_$))))"}
>  -doc_end
>  
>  -doc_begin="The argument \"fn\" in macros {COMPILE,RUNTIME}_CHECK is not parenthesized
>  on purpose, to be able to test function-like macros. Given the specialized and limited
>  use of this macro, it is deemed ok to deviate them."
> --config=MC3R1.R20.7,reports+={deliberate, "any_area(any_loc(any_exp(macro(^(COMPILE_CHECK|RUNTIME_CHECK)$))))"}
> +-config=MC3A2.R20.7,reports+={deliberate, "any_area(any_loc(any_exp(macro(^(COMPILE_CHECK|RUNTIME_CHECK)$))))"}
>  -doc_end
>  
>  -doc_begin="Problems related to operator precedence can not occur if the expansion of the macro argument is surrounded by tokens '{', '}' and ';'."
> --config=MC3R1.R20.7,expansion_context+={safe, "left_right(^[\\{;]$,^[;\\}]$)"}
> +-config=MC3A2.R20.7,expansion_context+={safe, "left_right(^[\\{;]$,^[;\\}]$)"}
>  -doc_end
>  
>  -doc_begin="Uses of variadic macros that have one of their arguments defined as
>  a macro and used within the body for both ordinary parameter expansion and as an
>  operand to the # or ## operators have a behavior that is well-understood and
>  deliberate."
> --config=MC3R1.R20.12,macros+={deliberate, "variadic()"}
> +-config=MC3A2.R20.12,macros+={deliberate, "variadic()"}
>  -doc_end
>  
>  -doc_begin="Uses of a macro parameter for ordinary expansion and as an operand
>  to the # or ## operators within the following macros are deliberate, to provide
>  useful diagnostic messages to the user."
> --config=MC3R1.R20.12,macros+={deliberate, "name(ASSERT||BUILD_BUG_ON||BUILD_BUG_ON_ZERO||RUNTIME_CHECK)"}
> +-config=MC3A2.R20.12,macros+={deliberate, "name(ASSERT||BUILD_BUG_ON||BUILD_BUG_ON_ZERO||RUNTIME_CHECK)"}
>  -doc_end
>  
>  -doc_begin="The helper macro GENERATE_CASE may use a macro parameter for ordinary
>  expansion and token pasting to improve readability. Only instances where this
>  leads to a violation of the Rule are deviated."
>  -file_tag+={deliberate_generate_case, "^xen/arch/arm/vcpreg\\.c$"}
> --config=MC3R1.R20.12,macros+={deliberate, "name(GENERATE_CASE)&&loc(file(deliberate_generate_case))"}
> +-config=MC3A2.R20.12,macros+={deliberate, "name(GENERATE_CASE)&&loc(file(deliberate_generate_case))"}
>  -doc_end
>  
>  -doc_begin="The macro DEFINE is defined and used in excluded files asm-offsets.c.
>  This may still cause violations if entities outside these files are referred to
>  in the expansion."
> --config=MC3R1.R20.12,macros+={deliberate, "name(DEFINE)&&loc(file(asm_offsets))"}
> +-config=MC3A2.R20.12,macros+={deliberate, "name(DEFINE)&&loc(file(asm_offsets))"}
>  -doc_end
>  
>  #
> @@ -636,7 +636,7 @@ in the expansion."
>  -doc_begin="or, and and xor are reserved identifiers because they constitute alternate
>  spellings for the corresponding operators (they are defined as macros by iso646.h).
>  However, Xen doesn't use standard library headers, so there is no risk of overlap."
> --config=MC3R1.R21.2,reports+={safe, "any_area(stmt(ref(kind(label)&&^(or|and|xor|not)$)))"}
> +-config=MC3A2.R21.2,reports+={safe, "any_area(stmt(ref(kind(label)&&^(or|and|xor|not)$)))"}
>  -doc_end
>  
>  -doc_begin="Xen does not use the functions provided by the Standard Library, but
> @@ -645,8 +645,8 @@ The implementation of these functions is available in source form, so the undefi
>  or implementation-defined behaviors contemplated by the C Standard do not apply.
>  If some undefined or unspecified behavior does arise in the implementation, it
>  falls under the jurisdiction of other MISRA rules."
> --config=MC3R1.R21.9,reports+={deliberate, "any()"}
> --config=MC3R1.R21.10,reports+={deliberate, "any()"}
> +-config=MC3A2.R21.9,reports+={deliberate, "any()"}
> +-config=MC3A2.R21.10,reports+={deliberate, "any()"}
>  -doc_end
>  
>  #
> @@ -671,7 +671,7 @@ falls under the jurisdiction of other MISRA rules."
>  programmers:no developers' confusion is not possible. In addition, adopted code
>  is assumed to work as is. Reports that are fully contained in adopted code are
>  hidden/tagged with the 'adopted' tag."
> --service_selector={developer_confusion_guidelines,"^(MC3R1\\.R2\\.1|MC3R1\\.R2\\.2|MC3R1\\.R2\\.3|MC3R1\\.R2\\.4|MC3R1\\.R2\\.5|MC3R1\\.R2\\.6|MC3R1\\.R2\\.7|MC3R1\\.R4\\.1|MC3R1\\.R5\\.3|MC3R1\\.R5\\.6|MC3R1\\.R5\\.7|MC3R1\\.R5\\.8|MC3R1\\.R5\\.9|MC3R1\\.R7\\.1|MC3R1\\.R7\\.2|MC3R1\\.R7\\.3|MC3R1\\.R8\\.7|MC3R1\\.R8\\.8|MC3R1\\.R8\\.9|MC3R1\\.R8\\.11|MC3R1\\.R8\\.12|MC3R1\\.R8\\.13|MC3R1\\.R9\\.3|MC3R1\\.R9\\.4|MC3R1\\.R9\\.5|MC3R1\\.R10\\.2|MC3R1\\.R10\\.5|MC3R1\\.R10\\.6|MC3R1\\.R10\\.7|MC3R1\\.R10\\.8|MC3R1\\.R11\\.9|MC3R1\\.R12\\.1|MC3R1\\.R12\\.3|MC3R1\\.R12\\.4|MC3R1\\.R13\\.5|MC3R1\\.R14\\.1|MC3R1\\.R14\\.2|MC3R1\\.R14\\.3|MC3R1\\.R15\\.1|MC3R1\\.R15\\.2|MC3R1\\.R15\\.3|MC3R1\\.R15\\.4|MC3R1\\.R15\\.5|MC3R1\\.R15\\.6|MC3R1\\.R15\\.7|MC3R1\\.R16\\.1|MC3R1\\.R16\\.2|MC3R1\\.R16\\.3|MC3R1\\.R16\\.4|MC3R1\\.R16\\.5|MC3R1\\.R16\\.6|MC3R1\\.R16\\.7|MC3R1\\.R17\\.7|MC3R1\\.R17\\.8|MC3R1\\.R18\\.4|MC3R1\\.R18\\.5)$"
> +-service_selector={developer_confusion_guidelines,"^(MC3A2\\.R2\\.1|MC3A2\\.R2\\.2|MC3A2\\.R2\\.3|MC3A2\\.R2\\.4|MC3A2\\.R2\\.5|MC3A2\\.R2\\.6|MC3A2\\.R2\\.7|MC3A2\\.R4\\.1|MC3A2\\.R5\\.3|MC3A2\\.R5\\.6|MC3A2\\.R5\\.7|MC3A2\\.R5\\.8|MC3A2\\.R5\\.9|MC3A2\\.R7\\.1|MC3A2\\.R7\\.2|MC3A2\\.R7\\.3|MC3A2\\.R8\\.7|MC3A2\\.R8\\.8|MC3A2\\.R8\\.9|MC3A2\\.R8\\.11|MC3A2\\.R8\\.12|MC3A2\\.R8\\.13|MC3A2\\.R9\\.3|MC3A2\\.R9\\.4|MC3A2\\.R9\\.5|MC3A2\\.R10\\.2|MC3A2\\.R10\\.5|MC3A2\\.R10\\.6|MC3A2\\.R10\\.7|MC3A2\\.R10\\.8|MC3A2\\.R11\\.9|MC3A2\\.R12\\.1|MC3A2\\.R12\\.3|MC3A2\\.R12\\.4|MC3A2\\.R13\\.5|MC3A2\\.R14\\.1|MC3A2\\.R14\\.2|MC3A2\\.R14\\.3|MC3A2\\.R15\\.1|MC3A2\\.R15\\.2|MC3A2\\.R15\\.3|MC3A2\\.R15\\.4|MC3A2\\.R15\\.5|MC3A2\\.R15\\.6|MC3A2\\.R15\\.7|MC3A2\\.R16\\.1|MC3A2\\.R16\\.2|MC3A2\\.R16\\.3|MC3A2\\.R16\\.4|MC3A2\\.R16\\.5|MC3A2\\.R16\\.6|MC3A2\\.R16\\.7|MC3A2\\.R17\\.7|MC3A2\\.R17\\.8|MC3A2\\.R18\\.4|MC3A2\\.R18\\.5)$"
>  }
>  -config=developer_confusion_guidelines,reports+={relied,adopted_report}
>  -doc_end
> diff --git a/automation/eclair_analysis/ECLAIR/monitored.ecl b/automation/eclair_analysis/ECLAIR/monitored.ecl
> index 4e1deef7a7..8351996ec8 100644
> --- a/automation/eclair_analysis/ECLAIR/monitored.ecl
> +++ b/automation/eclair_analysis/ECLAIR/monitored.ecl
> @@ -1,106 +1,106 @@
>  -doc_begin="A set of guidelines that are clean or that only have few violations left."
> --enable=MC3R1.D1.1
> --enable=MC3R1.D2.1
> --enable=MC3R1.D4.1
> --enable=MC3R1.D4.3
> --enable=MC3R1.D4.7
> --enable=MC3R1.D4.10
> --enable=MC3R1.D4.11
> --enable=MC3R1.D4.14
> --enable=MC3R1.R1.1
> --enable=MC3R1.R1.3
> --enable=MC3R1.R1.4
> --enable=MC3R1.R2.1
> --enable=MC3R1.R2.6
> --enable=MC3R1.R3.1
> --enable=MC3R1.R3.2
> --enable=MC3R1.R4.1
> --enable=MC3R1.R4.2
> --enable=MC3R1.R5.1
> --enable=MC3R1.R5.2
> --enable=MC3R1.R5.3
> --enable=MC3R1.R5.4
> --enable=MC3R1.R5.5
> --enable=MC3R1.R5.6
> --enable=MC3R1.R6.1
> --enable=MC3R1.R6.2
> --enable=MC3R1.R7.1
> --enable=MC3R1.R7.2
> --enable=MC3R1.R7.3
> --enable=MC3R1.R7.4
> --enable=MC3R1.R8.1
> --enable=MC3R1.R8.2
> --enable=MC3R1.R8.3
> --enable=MC3R1.R8.4
> --enable=MC3R1.R8.5
> --enable=MC3R1.R8.6
> --enable=MC3R1.R8.8
> --enable=MC3R1.R8.10
> --enable=MC3R1.R8.12
> --enable=MC3R1.R8.14
> --enable=MC3R1.R9.2
> --enable=MC3R1.R9.3
> --enable=MC3R1.R9.4
> --enable=MC3R1.R10.1
> --enable=MC3R1.R10.2
> --enable=MC3R1.R11.1
> --enable=MC3R1.R11.2
> --enable=MC3R1.R11.7
> --enable=MC3R1.R11.8
> --enable=MC3R1.R11.9
> --enable=MC3R1.R12.5
> --enable=MC3R1.R13.1
> --enable=MC3R1.R13.2
> --enable=MC3R1.R13.6
> --enable=MC3R1.R14.1
> --enable=MC3R1.R14.4
> --enable=MC3R1.R16.2
> --enable=MC3R1.R16.3
> --enable=MC3R1.R16.4
> --enable=MC3R1.R16.6
> --enable=MC3R1.R16.7
> --enable=MC3R1.R17.1
> --enable=MC3R1.R17.3
> --enable=MC3R1.R17.4
> --enable=MC3R1.R17.5
> --enable=MC3R1.R17.6
> --enable=MC3R1.R18.1
> --enable=MC3R1.R18.2
> --enable=MC3R1.R18.6
> --enable=MC3R1.R18.8
> --enable=MC3R1.R19.1
> --enable=MC3R1.R20.2
> --enable=MC3R1.R20.3
> --enable=MC3R1.R20.4
> --enable=MC3R1.R20.6
> --enable=MC3R1.R20.7
> --enable=MC3R1.R20.9
> --enable=MC3R1.R20.11
> --enable=MC3R1.R20.12
> --enable=MC3R1.R20.13
> --enable=MC3R1.R20.14
> --enable=MC3R1.R21.3
> --enable=MC3R1.R21.4
> --enable=MC3R1.R21.5
> --enable=MC3R1.R21.7
> --enable=MC3R1.R21.8
> --enable=MC3R1.R21.9
> --enable=MC3R1.R21.10
> --enable=MC3R1.R21.12
> --enable=MC3R1.R21.13
> --enable=MC3R1.R21.17
> --enable=MC3R1.R21.18
> --enable=MC3R1.R21.19
> --enable=MC3R1.R21.20
> --enable=MC3R1.R21.21
> --enable=MC3R1.R22.1
> --enable=MC3R1.R22.2
> --enable=MC3R1.R22.3
> --enable=MC3R1.R22.4
> --enable=MC3R1.R22.5
> --enable=MC3R1.R22.6
> --enable=MC3R1.R22.7
> --enable=MC3R1.R22.8
> --enable=MC3R1.R22.9
> --enable=MC3R1.R22.10
> +-enable=MC3A2.D1.1
> +-enable=MC3A2.D2.1
> +-enable=MC3A2.D4.1
> +-enable=MC3A2.D4.3
> +-enable=MC3A2.D4.7
> +-enable=MC3A2.D4.10
> +-enable=MC3A2.D4.11
> +-enable=MC3A2.D4.14
> +-enable=MC3A2.R1.1
> +-enable=MC3A2.R1.3
> +-enable=MC3A2.R1.4
> +-enable=MC3A2.R2.1
> +-enable=MC3A2.R2.6
> +-enable=MC3A2.R3.1
> +-enable=MC3A2.R3.2
> +-enable=MC3A2.R4.1
> +-enable=MC3A2.R4.2
> +-enable=MC3A2.R5.1
> +-enable=MC3A2.R5.2
> +-enable=MC3A2.R5.3
> +-enable=MC3A2.R5.4
> +-enable=MC3A2.R5.5
> +-enable=MC3A2.R5.6
> +-enable=MC3A2.R6.1
> +-enable=MC3A2.R6.2
> +-enable=MC3A2.R7.1
> +-enable=MC3A2.R7.2
> +-enable=MC3A2.R7.3
> +-enable=MC3A2.R7.4
> +-enable=MC3A2.R8.1
> +-enable=MC3A2.R8.2
> +-enable=MC3A2.R8.3
> +-enable=MC3A2.R8.4
> +-enable=MC3A2.R8.5
> +-enable=MC3A2.R8.6
> +-enable=MC3A2.R8.8
> +-enable=MC3A2.R8.10
> +-enable=MC3A2.R8.12
> +-enable=MC3A2.R8.14
> +-enable=MC3A2.R9.2
> +-enable=MC3A2.R9.3
> +-enable=MC3A2.R9.4
> +-enable=MC3A2.R10.1
> +-enable=MC3A2.R10.2
> +-enable=MC3A2.R11.1
> +-enable=MC3A2.R11.2
> +-enable=MC3A2.R11.7
> +-enable=MC3A2.R11.8
> +-enable=MC3A2.R11.9
> +-enable=MC3A2.R12.5
> +-enable=MC3A2.R13.1
> +-enable=MC3A2.R13.2
> +-enable=MC3A2.R13.6
> +-enable=MC3A2.R14.1
> +-enable=MC3A2.R14.4
> +-enable=MC3A2.R16.2
> +-enable=MC3A2.R16.3
> +-enable=MC3A2.R16.4
> +-enable=MC3A2.R16.6
> +-enable=MC3A2.R16.7
> +-enable=MC3A2.R17.1
> +-enable=MC3A2.R17.3
> +-enable=MC3A2.R17.4
> +-enable=MC3A2.R17.5
> +-enable=MC3A2.R17.6
> +-enable=MC3A2.R18.1
> +-enable=MC3A2.R18.2
> +-enable=MC3A2.R18.6
> +-enable=MC3A2.R18.8
> +-enable=MC3A2.R19.1
> +-enable=MC3A2.R20.2
> +-enable=MC3A2.R20.3
> +-enable=MC3A2.R20.4
> +-enable=MC3A2.R20.6
> +-enable=MC3A2.R20.7
> +-enable=MC3A2.R20.9
> +-enable=MC3A2.R20.11
> +-enable=MC3A2.R20.12
> +-enable=MC3A2.R20.13
> +-enable=MC3A2.R20.14
> +-enable=MC3A2.R21.3
> +-enable=MC3A2.R21.4
> +-enable=MC3A2.R21.5
> +-enable=MC3A2.R21.7
> +-enable=MC3A2.R21.8
> +-enable=MC3A2.R21.9
> +-enable=MC3A2.R21.10
> +-enable=MC3A2.R21.12
> +-enable=MC3A2.R21.13
> +-enable=MC3A2.R21.17
> +-enable=MC3A2.R21.18
> +-enable=MC3A2.R21.19
> +-enable=MC3A2.R21.20
> +-enable=MC3A2.R21.21
> +-enable=MC3A2.R22.1
> +-enable=MC3A2.R22.2
> +-enable=MC3A2.R22.3
> +-enable=MC3A2.R22.4
> +-enable=MC3A2.R22.5
> +-enable=MC3A2.R22.6
> +-enable=MC3A2.R22.7
> +-enable=MC3A2.R22.8
> +-enable=MC3A2.R22.9
> +-enable=MC3A2.R22.10
>  -doc_end
> diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
> index 755ea3271f..b524318591 100644
> --- a/automation/eclair_analysis/ECLAIR/tagging.ecl
> +++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
> @@ -20,93 +20,93 @@
>  -doc_begin="Clean guidelines: new violations for these guidelines are not accepted."
>  
>  -service_selector={clean_guidelines_common,
> -"MC3R1.D1.1||
> -MC3R1.D2.1||
> -MC3R1.D4.1||
> -MC3R1.D4.11||
> -MC3R1.D4.14||
> -MC3R1.R1.1||
> -MC3R1.R1.3||
> -MC3R1.R1.4||
> -MC3R1.R2.6||
> -MC3R1.R3.1||
> -MC3R1.R3.2||
> -MC3R1.R4.1||
> -MC3R1.R4.2||
> -MC3R1.R5.1||
> -MC3R1.R5.2||
> -MC3R1.R5.3||
> -MC3R1.R5.4||
> -MC3R1.R5.6||
> -MC3R1.R6.1||
> -MC3R1.R6.2||
> -MC3R1.R7.1||
> -MC3R1.R7.2||
> -MC3R1.R7.3||
> -MC3R1.R7.4||
> -MC3R1.R8.1||
> -MC3R1.R8.2||
> -MC3R1.R8.3||
> -MC3R1.R8.4||
> -MC3R1.R8.5||
> -MC3R1.R8.6||
> -MC3R1.R8.8||
> -MC3R1.R8.10||
> -MC3R1.R8.12||
> -MC3R1.R8.14||
> -MC3R1.R9.2||
> -MC3R1.R9.3||
> -MC3R1.R9.4||
> -MC3R1.R10.2||
> -MC3R1.R11.6||
> -MC3R1.R11.7||
> -MC3R1.R11.9||
> -MC3R1.R12.5||
> -MC3R1.R13.6||
> -MC3R1.R14.1||
> -MC3R1.R14.3||
> -MC3R1.R14.4||
> -MC3R1.R16.2||
> -MC3R1.R16.3||
> -MC3R1.R16.7||
> -MC3R1.R17.1||
> -MC3R1.R17.3||
> -MC3R1.R17.4||
> -MC3R1.R17.5||
> -MC3R1.R17.6||
> -MC3R1.R18.6||
> -MC3R1.R18.8||
> -MC3R1.R20.2||
> -MC3R1.R20.3||
> -MC3R1.R20.4||
> -MC3R1.R20.6||
> -MC3R1.R20.9||
> -MC3R1.R20.11||
> -MC3R1.R20.12||
> -MC3R1.R20.13||
> -MC3R1.R20.14||
> -MC3R1.R21.3||
> -MC3R1.R21.4||
> -MC3R1.R21.5||
> -MC3R1.R21.7||
> -MC3R1.R21.8||
> -MC3R1.R21.9||
> -MC3R1.R21.10||
> -MC3R1.R21.11||
> -MC3R1.R21.12||
> -MC3R1.R21.13||
> -MC3R1.R21.19||
> -MC3R1.R21.21||
> -MC3R1.R22.1||
> -MC3R1.R22.2||
> -MC3R1.R22.3||
> -MC3R1.R22.4||
> -MC3R1.R22.5||
> -MC3R1.R22.6||
> -MC3R1.R22.7||
> -MC3R1.R22.8||
> -MC3R1.R22.9||
> -MC3R1.R22.10"
> +"MC3A2.D1.1||
> +MC3A2.D2.1||
> +MC3A2.D4.1||
> +MC3A2.D4.11||
> +MC3A2.D4.14||
> +MC3A2.R1.1||
> +MC3A2.R1.3||
> +MC3A2.R1.4||
> +MC3A2.R2.6||
> +MC3A2.R3.1||
> +MC3A2.R3.2||
> +MC3A2.R4.1||
> +MC3A2.R4.2||
> +MC3A2.R5.1||
> +MC3A2.R5.2||
> +MC3A2.R5.3||
> +MC3A2.R5.4||
> +MC3A2.R5.6||
> +MC3A2.R6.1||
> +MC3A2.R6.2||
> +MC3A2.R7.1||
> +MC3A2.R7.2||
> +MC3A2.R7.3||
> +MC3A2.R7.4||
> +MC3A2.R8.1||
> +MC3A2.R8.2||
> +MC3A2.R8.3||
> +MC3A2.R8.4||
> +MC3A2.R8.5||
> +MC3A2.R8.6||
> +MC3A2.R8.8||
> +MC3A2.R8.10||
> +MC3A2.R8.12||
> +MC3A2.R8.14||
> +MC3A2.R9.2||
> +MC3A2.R9.3||
> +MC3A2.R9.4||
> +MC3A2.R10.2||
> +MC3A2.R11.6||
> +MC3A2.R11.7||
> +MC3A2.R11.9||
> +MC3A2.R12.5||
> +MC3A2.R13.6||
> +MC3A2.R14.1||
> +MC3A2.R14.3||
> +MC3A2.R14.4||
> +MC3A2.R16.2||
> +MC3A2.R16.3||
> +MC3A2.R16.7||
> +MC3A2.R17.1||
> +MC3A2.R17.3||
> +MC3A2.R17.4||
> +MC3A2.R17.5||
> +MC3A2.R17.6||
> +MC3A2.R18.6||
> +MC3A2.R18.8||
> +MC3A2.R20.2||
> +MC3A2.R20.3||
> +MC3A2.R20.4||
> +MC3A2.R20.6||
> +MC3A2.R20.9||
> +MC3A2.R20.11||
> +MC3A2.R20.12||
> +MC3A2.R20.13||
> +MC3A2.R20.14||
> +MC3A2.R21.3||
> +MC3A2.R21.4||
> +MC3A2.R21.5||
> +MC3A2.R21.7||
> +MC3A2.R21.8||
> +MC3A2.R21.9||
> +MC3A2.R21.10||
> +MC3A2.R21.11||
> +MC3A2.R21.12||
> +MC3A2.R21.13||
> +MC3A2.R21.19||
> +MC3A2.R21.21||
> +MC3A2.R22.1||
> +MC3A2.R22.2||
> +MC3A2.R22.3||
> +MC3A2.R22.4||
> +MC3A2.R22.5||
> +MC3A2.R22.6||
> +MC3A2.R22.7||
> +MC3A2.R22.8||
> +MC3A2.R22.9||
> +MC3A2.R22.10"
>  }
>  
>  -setq=target,getenv("XEN_TARGET_ARCH")
> @@ -116,7 +116,7 @@ if(string_equal(target,"x86_64"),
>  )
>  
>  if(string_equal(target,"arm64"),
> -    service_selector({"additional_clean_guidelines","MC3R1.R2.1||MC3R1.R5.3||MC3.R11.2||MC3R1.R16.6||MC3R1.R20.7"})
> +    service_selector({"additional_clean_guidelines","MC3A2.R2.1||MC3A2.R5.3||MC3.R11.2||MC3A2.R16.6||MC3A2.R20.7"})
>  )
>  
>  -reports+={clean:added,"service(clean_guidelines_common||additional_clean_guidelines)"}
> diff --git a/docs/misra/documenting-violations.rst b/docs/misra/documenting-violations.rst
> index 8f1cbd83b8..d26377d5aa 100644
> --- a/docs/misra/documenting-violations.rst
> +++ b/docs/misra/documenting-violations.rst
> @@ -53,7 +53,7 @@ Here is an example to add a new justification in safe.json::
>  |            "analyser": {
>  |                "cppcheck": "misra-c2012-20.7",
>  |                "coverity": "misra_c_2012_rule_20_7_violation",
> -|                "eclair": "MC3R1.R20.7"
> +|                "eclair": "MC3A2.R20.7"
>  |            },
>  |            "name": "R20.7 C macro parameters not used as expression",
>  |            "text": "The macro parameters used in this [...]"
> @@ -138,7 +138,7 @@ for the Rule 8.6:
>  
>  Eclair reports it in its web report, file xen/include/xen/kernel.h, line 68:
>  
> -| MC3R1.R8.6 for program 'xen/xen-syms', variable '_start' has no definition
> +| MC3A2.R8.6 for program 'xen/xen-syms', variable '_start' has no definition
>  
>  Also coverity reports it, here is an extract of the finding:
>  
> @@ -165,7 +165,7 @@ We will prepare our entry in the safe.json database::
>  |        {
>  |            "id": "SAF-1-safe",
>  |            "analyser": {
> -|                "eclair": "MC3R1.R8.6",
> +|                "eclair": "MC3A2.R8.6",
>  |                "coverity": "misra_c_2012_rule_8_6_violation"
>  |            },
>  |            "name": "Rule 8.6: linker script defined symbols",
> diff --git a/docs/misra/safe.json b/docs/misra/safe.json
> index 684346386e..b8a4f878ea 100644
> --- a/docs/misra/safe.json
> +++ b/docs/misra/safe.json
> @@ -4,7 +4,7 @@
>          {
>              "id": "SAF-0-safe",
>              "analyser": {
> -                "eclair": "MC3R1.R8.6",
> +                "eclair": "MC3A2.R8.6",
>                  "coverity": "misra_c_2012_rule_8_6_violation"
>              },
>              "name": "Rule 8.6: linker script defined symbols",
> @@ -13,7 +13,7 @@
>          {
>              "id": "SAF-1-safe",
>              "analyser": {
> -                "eclair": "MC3R1.R8.4"
> +                "eclair": "MC3A2.R8.4"
>              },
>              "name": "Rule 8.4: asm-only definition",
>              "text": "Functions and variables used only by asm modules do not need to have a visible declaration prior to their definition."
> @@ -21,23 +21,23 @@
>          {
>              "id": "SAF-2-safe",
>              "analyser": {
> -                "eclair": "MC3R1.R10.1"
> +                "eclair": "MC3A2.R10.1"
>              },
> -            "name": "MC3R1.R10.1: use of an enumeration constant in an arithmetic operation",
> +            "name": "MC3A2.R10.1: use of an enumeration constant in an arithmetic operation",
>              "text": "This violation can be fixed with a cast to (int) of the enumeration constant, but a deviation was chosen due to code readability (see also the comment in BITS_TO_LONGS)."
>          },
>          {
>              "id": "SAF-3-safe",
>              "analyser": {
> -                "eclair": "MC3R1.R20.4"
> +                "eclair": "MC3A2.R20.4"
>              },
> -            "name": "MC3R1.R20.4: allow the definition of a macro with the same name as a keyword in some special cases",
> +            "name": "MC3A2.R20.4: allow the definition of a macro with the same name as a keyword in some special cases",
>              "text": "The definition of a macro with the same name as a keyword can be useful in certain configurations to improve the guarantees that can be provided by Xen. See docs/misra/deviations.rst for a precise rationale for all such cases."
>          },
>          {
>              "id": "SAF-4-safe",
>              "analyser": {
> -                "eclair": "MC3R1.R17.1"
> +                "eclair": "MC3A2.R17.1"
>              },
>              "name": "Rule 17.1: internal helper functions made to break long running hypercalls into multiple calls.",
>              "text": "They need to take a variable number of arguments depending on the original hypercall they are trying to continue."
> @@ -45,31 +45,31 @@
>          {
>              "id": "SAF-5-safe",
>              "analyser": {
> -                "eclair": "MC3R1.R16.2"
> +                "eclair": "MC3A2.R16.2"
>              },
> -            "name": "MC3R1.R16.2: using a case label when the most closely-enclosing compound statement is not a switch statement",
> +            "name": "MC3A2.R16.2: using a case label when the most closely-enclosing compound statement is not a switch statement",
>              "text": "A switch label enclosed by some compound statement that is not the body of a switch is permitted within local helper macros that are unlikely to be misused or misunderstood."
>          },
>          {
>              "id": "SAF-6-safe",
>              "analyser": {
> -                "eclair": "MC3R1.R20.12"
> +                "eclair": "MC3A2.R20.12"
>              },
> -            "name": "MC3R1.R20.12: use of a macro argument that deliberately violates the Rule",
> +            "name": "MC3A2.R20.12: use of a macro argument that deliberately violates the Rule",
>              "text": "A macro parameter that is itself a macro is intentionally used within the macro both as a regular parameter and for text replacement."
>          },
>          {
>              "id": "SAF-7-safe",
>              "analyser": {
> -                "eclair": "MC3R1.R20.7"
> +                "eclair": "MC3A2.R20.7"
>              },
> -            "name": "MC3R1.R20.7: deliberately non-parenthesized macro argument",
> +            "name": "MC3A2.R20.7: deliberately non-parenthesized macro argument",
>              "text": "A macro parameter expands to an expression that is non-parenthesized, as doing so would break the functionality."
>          },
>          {
>              "id": "SAF-8-safe",
>              "analyser": {
> -                "eclair": "MC3R1.D4.10"
> +                "eclair": "MC3A2.D4.10"
>              },
>              "name": "Dir 4.10: headers that leave it up to the caller to include them correctly",
>              "text": "Headers that deliberatively leave the responsability of their correct inclusion to the caller are allowed."
> @@ -77,7 +77,7 @@
>          {
>              "id": "SAF-9-safe",
>              "analyser": {
> -                "eclair": "MC3R1.D4.10"
> +                "eclair": "MC3A2.D4.10"
>              },
>              "name": "Dir 4.10: empty headers",
>              "text": "Empty headers pose no risk if included more than once."
> @@ -85,7 +85,7 @@
>          {
>              "id": "SAF-10-safe",
>              "analyser": {
> -                "eclair": "MC3R1.D4.10"
> +                "eclair": "MC3A2.D4.10"
>              },
>              "name": "Dir 4.10: direct inclusion guard before",
>              "text": "Headers with just the direct inclusion guard before the inclusion guard are safe."
> -- 
> 2.43.0
> 


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 00:35:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 00:35:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853496.1266930 (Exim 4.92)
	(envelope-from )
	id 1tLAhM-0005v9-T4; Wed, 11 Dec 2024 00:35:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853496.1266930; Wed, 11 Dec 2024 00:35:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLAhM-0005v2-PU; Wed, 11 Dec 2024 00:35:28 +0000
Received: by outflank-mailman (input) for mailman id 853496;
 Wed, 11 Dec 2024 00:35: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 1tLAhL-0005uw-Dl
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 00:35:27 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cf92d5bf-b757-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 01:35:25 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 9CDD4A41BC1;
 Wed, 11 Dec 2024 00:33:32 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 08A68C4CED6;
 Wed, 11 Dec 2024 00:35:20 +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: cf92d5bf-b757-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org;
	s=korg; t=1733877323;
	bh=JacV5V+VE+iRUgZxF+CyNriRT0L3gGNH3mNPIEp8PtQ=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=SAfmO1AXcxfNbXeA1lt2ARS5JA4aoca5GZCiMS3IsanyDv7yL62uuNcWrh+aSXiVP
	 AePvXROpCDcKvBJXxbvGsZk9klohSs7XOvzlFRp1o6jpcriieZaxAhKmQ+7F8mdfh1
	 fRbKx1TTHL0AKtGcnVGrRVHy0Uy+i6x4JaMqirKE=
Date: Tue, 10 Dec 2024 16:35:20 -0800
From: Andrew Morton 
To: Easwar Hariharan 
Cc: Pablo Neira Ayuso , Jozsef Kadlecsik
 , "David S. Miller" , Eric
 Dumazet , Jakub Kicinski , Paolo
 Abeni , Simon Horman , Julia Lawall
 , Nicolas Palix , Daniel Mack
 , Haojian Zhuang , Robert
 Jarzmik , Russell King ,
 Heiko Carstens , Vasily Gorbik ,
 Alexander Gordeev , Christian Borntraeger
 , Sven Schnelle , Ofir
 Bitton , Oded Gabbay , Lucas De
 Marchi , Thomas =?ISO-8859-1?Q?Hellstr=F6m?=
 , Rodrigo Vivi ,
 Maarten Lankhorst , Maxime Ripard
 , Thomas Zimmermann , David Airlie
 , Simona Vetter , Jeroen de Borst
 , Praveen Kaligineedi ,
 Shailend Chand , Andrew Lunn ,
 James Smart , Dick Kennedy
 , "James E.J. Bottomley"
 , "Martin K. Petersen"
 , Roger Pau =?ISO-8859-1?Q?Monn=E9?=
 , Jens Axboe , Kalle Valo
 , Jeff Johnson , Catalin Marinas
 , Jack Wang , Marcel
 Holtmann , Johan Hedberg ,
 Luiz Augusto von Dentz , Greg Kroah-Hartman
 , Florian Fainelli
 , Ray Jui , Scott Branden
 , Broadcom internal kernel review list
 , Xiubo Li , Ilya
 Dryomov , Josh Poimboeuf , Jiri
 Kosina , Miroslav Benes , Petr Mladek
 , Joe Lawrence , Jaroslav Kysela
 , Takashi Iwai , Louis Peens
 , Michael Ellerman , Nicholas
 Piggin , Christophe Leroy ,
 Naveen N Rao , Madhavan Srinivasan
 , netfilter-devel@vger.kernel.org,
 coreteam@netfilter.org, netdev@vger.kernel.org,
 linux-kernel@vger.kernel.org, cocci@inria.fr,
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org,
 ath11k@lists.infradead.org, linux-mm@kvack.org,
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev,
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org,
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org,
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, Anna-Maria Behnsen
 , Jeff Johnson 
Subject: Re: [PATCH v3 00/19] Converge on using secs_to_jiffies()
Message-Id: <20241210163520.95fa1c8aa83e1915004ed884@linux-foundation.org>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 10 Dec 2024 22:02:31 +0000 Easwar Hariharan  wrote:

> This is a series that follows up on my previous series to introduce
> secs_to_jiffies() and convert a few initial users.

Thanks, I added this to mm.git.  I suppressed the usual added-to-mm
emails because soooo many cc's!

I'd ask relevant maintainers to send in any acks and I'll paste them
into the relevant changelogs.



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 00:51:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 00:51:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853511.1266943 (Exim 4.92)
	(envelope-from )
	id 1tLAx3-0003jT-68; Wed, 11 Dec 2024 00:51:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853511.1266943; Wed, 11 Dec 2024 00:51: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 1tLAx3-0003jM-3S; Wed, 11 Dec 2024 00:51:41 +0000
Received: by outflank-mailman (input) for mailman id 853511;
 Wed, 11 Dec 2024 00:51: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 1tLAx2-0003fX-7b
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 00:51:40 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 11ac933c-b75a-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 01:51:37 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 8325EA41BC0;
 Wed, 11 Dec 2024 00:49:42 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD4C4C4CED6;
 Wed, 11 Dec 2024 00:51:32 +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: 11ac933c-b75a-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1733878293;
	bh=vVNYVpyCDSlCfdj17iInh8wKbOxm59Gi8/qHAVwiUwo=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=T3Re0M939BY6+8omsCLUtd/Dfg/EDrwpR12e3gHHmOc/7vcHGQw+7RAneLtS3uje3
	 TFdHjQ29sV1FgAbJ0XmMx/SX1GlzTjhjn+CL5gK97oFS+xsHkBb5/p60mjsSTg/dPg
	 UkVHcIOJuyvF4cGw6DxlkHJSU5IK6D2ehMApuEuZw2XabgzJlgmCJHmQXpiPgo3XJw
	 f1SkoiFyGsfNQ6SyhIsSfCkFT9vwj6Ew+ZH1byZXCGNkvRovNzaGYsVlkMbHNrKxws
	 y+N7G9u5UGLbBFqZTmzWjlu8fgq093jfCFLNkIc+Er7V4CXAxS/zAspW1z7Y5mnh6B
	 rI9lW41WVj3gw==
Date: Tue, 10 Dec 2024 16:51:31 -0800 (PST)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: "=?UTF-8?Q?YUICHI_KUSAKABE_=28=E6=97=A5=E4=B8=8B=E9=83=A8_=E9=9B=84?=
 =?UTF-8?Q?=E4=B8=80=29?=" 
cc: Kelly Choi , 
    xen-devel , 
    "xen-announce@lists.xenproject.org" , 
    "committers @ xenproject . org" , 
    Xen Project Advisory Board 
Subject: RE: Welcome Honda to the Xen Project Board
In-Reply-To: 
Message-ID: 
References:  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-977437683-1733872775=:463523"
Content-ID: 

  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-977437683-1733872775=:463523
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

Hi Yuichi,

Welcome onboard! It is great to have you as part of our community, and
we are looking forward to working together to enhance Xen in automotive.

Cheers,

Stefano


On Tue, 10 Dec 2024, YUICHI KUSAKABE (日下部 雄一) wrote:
> Hello All
> 
>  
> 
> We are happy to be able to join the member of Xen Project.
> 
> To help us achieve what we consider to be SDV,
> 
> https://static.sched.com/hosted_files/aglammsummer2024/f2/keynote-240718AGL_AMM-Honda.pdf?_gl=1*187coac*_gcl_au*MTk1NjQ4MjE2NS4xNzMxNzYzOD
> M3*FPAU*MTk1NjQ4MjE2NS4xNzMxNzYzODM3
> 
> Xen is the best option to achieve our SDV vision.
> 
>  
> 
> I look forward to seeing you all.
> 
>  
> 
> BR.
> 
> Yuichi Kusakabe.
> 
> Chief Architect - IVI software PF/OSPO Tech Lead
> 
> Honda Motor Co., Ltd.
> 
>  
> 
> From: Kelly Choi 
> Sent: Monday, December 9, 2024 11:35 PM
> To: xen-devel ; xen-announce@lists.xenproject.org; committers @ xenproject . org
> ; Xen Project Advisory Board 
> Subject: Welcome Honda to the Xen Project Board
> 
>  
> 
> Hi all,
> 
>  
> 
> We're excited to announce our newest Advisory Board Member Honda, to the Xen Project.
> 
> Since its foundation, Honda has been committed to "creating a society that is useful to people" by utilizing its technologies and ideas.
> Honda also focuses on environmental responsiveness and traffic safety, and continue to take on the challenge of realizing a sustainable
> future.
> 
> I am sure that the community will agree that this is a huge step and achievement for our open source project. Honda's investment into
> supporting Xen means we are expanding our efforts to create a more secure and versatile hypervisor, with real world applications. Their
> commitment and partnership with Xen only increase the capabilities that our virtualization technology has achieved so far.
> 
> With Honda joining, their insights will help us navigate new challenges, expand our outreach to new contributors and enhance policies
> surrounding our community.
> 
> Their unique perspective will be invaluable as we tackle goals for the future, and we’re thrilled to have their voice guiding our strategy
> and vision.
> 
> Please join us in giving a warm welcome to Honda! We’re eager to see how their leadership and technical teams will help shape the future of
> the Xen Project. 
> 
>  
> 
> Together, we’ll continue building a strong, inclusive, and innovative community.
> 
>  
> 
> Kelly Choi
> 
> Community Manager
> 
> Xen Project
> 
> 
> 
--8323329-977437683-1733872775=:463523--


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 00:57:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 00:57:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853525.1266952 (Exim 4.92)
	(envelope-from )
	id 1tLB32-0005P4-PT; Wed, 11 Dec 2024 00:57:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853525.1266952; Wed, 11 Dec 2024 00:57: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 1tLB32-0005Ox-Mu; Wed, 11 Dec 2024 00:57:52 +0000
Received: by outflank-mailman (input) for mailman id 853525;
 Wed, 11 Dec 2024 00:57: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 1tLB30-0005Or-Vr
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 00:57:51 +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 ef33b6f1-b75a-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 01:57:48 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733878658727540.469110684163;
 Tue, 10 Dec 2024 16:57:38 -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: ef33b6f1-b75a-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1733878661; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=jpeaWtvOOhwLlouOtQU/Pw/h2E3SdTOU/Rgb6MiyQ+5oBp1hbDUc8aef4WmwnIVEzNrA9TCXIgmsGH0fh8DJYypR9yZnBGG3hjYS1K0YuKVXfyUxLenQMI9P/zXH99T2wsaXcYy65Fnsh/0HBbMIDaqner4eRMFdpuUx0du8vEg=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733878661; 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=+OPkbT16o3bYHk6acl1lNzdU3SOOeeF6WOeEkuYsQWY=; 
	b=IR+c9gb9FWmkQGJIFlx7somppyqT7gLGEsQMxiW5qEoWL3SQqCOuBHc7d+o3KaEtV7q8O+kNBL1eprDbrzeqzkuszKsSqO6zqDCsxqkxauJWwUWwBBaZiloD7oY7UOqH7LbkH38V/V+oc9k/C5+ypHfuRC423ojfDkSQsCD8af0=
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=1733878661;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=+OPkbT16o3bYHk6acl1lNzdU3SOOeeF6WOeEkuYsQWY=;
	b=DdolmXwLioHlczhdUol04lWwwiqmpbbyMzGl/2RQApNdfZd+Oec6BEm/CVkkI2FW
	ov0ii6YfJP95XFL/pums4QKNo5kMksMu4CankHRvGY/pm0aE+3E448ykGIi5Bko4Knu
	JXAmIPt0ASplUg6nTOQb9psLQqVhyvf7rhYbX22Q=
Message-ID: 
Date: Tue, 10 Dec 2024 19:57:37 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 5/6] x86/boot: introduce domid field to struct
 boot_domain
To: Jan Beulich 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241115131204.32135-1-dpsmith@apertussolutions.com>
 <20241115131204.32135-6-dpsmith@apertussolutions.com>
 
 <83e3b0a9-e0e6-4d36-a3ce-4687b1886733@apertussolutions.com>
 <7f40d7ba-26ec-4301-abbc-aef5d1ade44c@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <7f40d7ba-26ec-4301-abbc-aef5d1ade44c@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 12/9/24 03:55, Jan Beulich wrote:
> On 04.12.2024 17:45, Daniel P. Smith wrote:
>> On 11/27/24 05:32, Jan Beulich wrote:
>>> On 15.11.2024 14:12, Daniel P. Smith wrote:
>>>>        init_dom0_cpuid_policy(d);
>>>>    
>>>>        if ( alloc_dom0_vcpu0(d) == NULL )
>>>> -        panic("Error creating d%uv0\n", domid);
>>>> +        panic("Error creating d%uv0\n", bd->domid);
>>>
>>> Imo this would better use d->domain_id. And while touching it, %u would also
>>> want swapping for %d.
>>
>> hmm, I was actually considering s/d%u/%pd/ and just pass in d, but was
>> certain if there was an explicit reason it wasn't used before. If I am
>> going to change it, would %pd not be more desired here?
> 
> When writing my original reply, I certainly considered this. The anomaly
> here is that you really mean to log a vCPU ID, which would require a
> struct vcpu * and use of %pv. Yet you don't have that here, precisely
> because the creation of the vCPU failed. That said, since
> vsprintf.c:print_vcpu() calls print_domain(), using %pd is certainly an
> option here (inconsistencies would arise if %pv and %pd presented domain
> IDs in [perhaps just slightly] different ways).

Will do, thanks!

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 01:00:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 01:00:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853535.1266963 (Exim 4.92)
	(envelope-from )
	id 1tLB5b-0000zX-6c; Wed, 11 Dec 2024 01:00:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853535.1266963; Wed, 11 Dec 2024 01: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 1tLB5b-0000z2-2N; Wed, 11 Dec 2024 01:00:31 +0000
Received: by outflank-mailman (input) for mailman id 853535;
 Wed, 11 Dec 2024 01:00:29 +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 1tLB5Z-00008o-Dl
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 01:00:29 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 4f05589b-b75b-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 02:00:27 +0100 (CET)
Received: from [100.65.224.195] (unknown [20.236.10.66])
 by linux.microsoft.com (Postfix) with ESMTPSA id 3DB3C204722A;
 Tue, 10 Dec 2024 17:00: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: 4f05589b-b75b-11ef-99a3-01e77a169b0f
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 3DB3C204722A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733878825;
	bh=QUGnAohdjtquVH/2okVPvYsuli7DzTd7KNzArXZ6FX8=;
	h=Date:Cc:Subject:To:References:From:In-Reply-To:From;
	b=oU8Wxq8f38kSwtMyloVNW6CTihWbqiihpmp0Kmbf9489s89C/Z1o5JZmtxg0WiGWP
	 5xvVb1XhicfPH1o/xdUSq84/qeX5nOMyN7dJOgbbvoyqRelv8RbAXLy4i6uQ7bi++o
	 Gm59sZekWoiwe5TvchRr+7Gxo8CyNIMiE5EA50Kw=
Message-ID: <422470cd-84f0-469e-93c2-493c5091391d@linux.microsoft.com>
Date: Tue, 10 Dec 2024 17:00:21 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Cc: eahariha@linux.microsoft.com, Pablo Neira Ayuso ,
 Jozsef Kadlecsik ,
 "David S. Miller" , Eric Dumazet ,
 Jakub Kicinski , Paolo Abeni ,
 Simon Horman , Julia Lawall ,
 Nicolas Palix , Daniel Mack ,
 Haojian Zhuang ,
 Robert Jarzmik , Russell King
 , Heiko Carstens ,
 Vasily Gorbik , Alexander Gordeev
 , Christian Borntraeger ,
 Sven Schnelle , Ofir Bitton ,
 Oded Gabbay , Lucas De Marchi
 ,
 =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= ,
 Rodrigo Vivi ,
 Maarten Lankhorst ,
 Maxime Ripard , Thomas Zimmermann ,
 David Airlie , Simona Vetter ,
 Jeroen de Borst ,
 Praveen Kaligineedi ,
 Shailend Chand , Andrew Lunn ,
 James Smart ,
 Dick Kennedy ,
 "James E.J. Bottomley" ,
 "Martin K. Petersen" ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Jens Axboe , Kalle Valo ,
 Jeff Johnson , Catalin Marinas
 , Jack Wang ,
 Marcel Holtmann ,
 Johan Hedberg ,
 Luiz Augusto von Dentz ,
 Greg Kroah-Hartman ,
 Florian Fainelli , Ray Jui
 , Scott Branden ,
 Broadcom internal kernel review list
 , Xiubo Li ,
 Ilya Dryomov , Josh Poimboeuf ,
 Jiri Kosina , Miroslav Benes ,
 Petr Mladek , Joe Lawrence ,
 Jaroslav Kysela , Takashi Iwai ,
 Louis Peens , Michael Ellerman
 , Nicholas Piggin ,
 Christophe Leroy ,
 Naveen N Rao , Madhavan Srinivasan ,
 netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr,
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org,
 ath11k@lists.infradead.org, linux-mm@kvack.org,
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev,
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org,
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org,
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org,
 Anna-Maria Behnsen ,
 Jeff Johnson 
Subject: Re: [PATCH v3 00/19] Converge on using secs_to_jiffies()
To: Andrew Morton 
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
 <20241210163520.95fa1c8aa83e1915004ed884@linux-foundation.org>
From: Easwar Hariharan 
Content-Language: en-US
In-Reply-To: <20241210163520.95fa1c8aa83e1915004ed884@linux-foundation.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12/10/2024 4:35 PM, Andrew Morton wrote:
> On Tue, 10 Dec 2024 22:02:31 +0000 Easwar Hariharan  wrote:
> 
>> This is a series that follows up on my previous series to introduce
>> secs_to_jiffies() and convert a few initial users.
> 
> Thanks, I added this to mm.git.  I suppressed the usual added-to-mm
> emails because soooo many cc's!
> 
> I'd ask relevant maintainers to send in any acks and I'll paste them
> into the relevant changelogs.

Thank you, Andrew!

- Easwar


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 01:36:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 01:36:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853555.1266972 (Exim 4.92)
	(envelope-from )
	id 1tLBdt-000219-Mp; Wed, 11 Dec 2024 01:35:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853555.1266972; Wed, 11 Dec 2024 01:35:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLBdt-000212-KH; Wed, 11 Dec 2024 01:35:57 +0000
Received: by outflank-mailman (input) for mailman id 853555;
 Wed, 11 Dec 2024 01:35: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 1tLBds-00020w-QH
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 01:35:56 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 42c446da-b760-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 02:35:54 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 92254A41CA1;
 Wed, 11 Dec 2024 01:34:01 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 199D6C4CED6;
 Wed, 11 Dec 2024 01:35:49 +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: 42c446da-b760-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1733880952;
	bh=Dz1h0dkmrv6Ze1cxU8t5rn465fyVUykxbTsS0X2OpsA=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=lWXuqS/OGpuLDDn3e6rd0Ny3W9lOBqxl6ouihxGY5DI5BnIAz9k8OvBxV/WkkoGKL
	 hvX4IUIFhNQrpaU/cm1/wigfic0JSqIb6VAvnSxeGoBEhxQ8j23ePZ7Up9KKZysBId
	 uO/7yQ7qC/+pZb6ESDTBeZAbwesJTCLTy1XLYAF4mlcKRBKyoFjzB5pZOEDAYCVUSK
	 PtvZkQ2HN8nf8vIhBE/HaUtHV2aj4U1eGeFDoHxYziwThc1ReVtXl39rfXh3mERvJ2
	 23iH30lOevYf8TCz5YvtH3bGmPPNofPB05oCl1pJa3BU8K8c+a39qY+xcVUgGWrb0g
	 vGjoGdbfKJTPg==
Date: Tue, 10 Dec 2024 17:35:48 -0800
From: Jakub Kicinski 
To: Andrew Morton , Easwar Hariharan
 
Cc: Jeff Johnson , Pablo Neira Ayuso
 , Jozsef Kadlecsik , "David S.
 Miller" , Eric Dumazet , Paolo
 Abeni , Simon Horman , Julia Lawall
 , Nicolas Palix , Daniel Mack
 , Haojian Zhuang , Robert
 Jarzmik , Russell King ,
 Heiko Carstens , Vasily Gorbik ,
 Alexander Gordeev , Christian Borntraeger
 , Sven Schnelle , Ofir
 Bitton , Oded Gabbay , Lucas De
 Marchi , Thomas =?UTF-8?B?SGVsbHN0csO2bQ==?=
 , Rodrigo Vivi ,
 Maarten Lankhorst , Maxime Ripard
 , Thomas Zimmermann , David Airlie
 , Simona Vetter , Jeroen de Borst
 , Praveen Kaligineedi ,
 Shailend Chand , Andrew Lunn ,
 James Smart , Dick Kennedy
 , "James E.J. Bottomley"
 , "Martin K. Petersen"
 , Roger Pau =?UTF-8?B?TW9ubsOp?=
 , Jens Axboe , Kalle Valo
 , Jeff Johnson , Catalin Marinas
 , Jack Wang , Marcel
 Holtmann , Johan Hedberg ,
 Luiz Augusto von Dentz , Greg Kroah-Hartman
 , Florian Fainelli
 , Ray Jui , Scott Branden
 , Broadcom internal kernel review list
 , Xiubo Li , Ilya
 Dryomov , Josh Poimboeuf , Jiri
 Kosina , Miroslav Benes , Petr Mladek
 , Joe Lawrence , Jaroslav Kysela
 , Takashi Iwai , Louis Peens
 , Michael Ellerman , Nicholas
 Piggin , Christophe Leroy ,
 Naveen N Rao , Madhavan Srinivasan
 , netfilter-devel@vger.kernel.org,
 coreteam@netfilter.org, netdev@vger.kernel.org,
 linux-kernel@vger.kernel.org, cocci@inria.fr,
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org,
 ath11k@lists.infradead.org, linux-mm@kvack.org,
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev,
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org,
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org,
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, Anna-Maria Behnsen
 
Subject: Re: [PATCH v3 00/19] Converge on using secs_to_jiffies()
Message-ID: <20241210173548.5d32efe0@kernel.org>
In-Reply-To: <20241210153604.cf99699f264f12740ffce5c7@linux-foundation.org>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
	<315e9178-5b10-4de0-bdcf-7243e0e355bb@oss.qualcomm.com>
	<20241210153604.cf99699f264f12740ffce5c7@linux-foundation.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 10 Dec 2024 15:36:04 -0800 Andrew Morton wrote:
> > I have the same question as before: How do you expect these to land?
> > Do you now have a maintainer who will take all of them?
> > Or do you want individual maintainers to take the ones applicable to them?  
> 
> I'll just grab everything and see if anyone complains ;)

I may, if this leads to a conflict :(

Easwar, please break this up per subsystem.


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 02:04:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 02:04:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853574.1266983 (Exim 4.92)
	(envelope-from )
	id 1tLC5d-0004aM-1D; Wed, 11 Dec 2024 02:04:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853574.1266983; Wed, 11 Dec 2024 02:04: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 1tLC5c-0004aF-Tb; Wed, 11 Dec 2024 02:04:36 +0000
Received: by outflank-mailman (input) for mailman id 853574;
 Wed, 11 Dec 2024 02:04: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 1tLC5c-0004a4-8f
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 02:04:36 +0000
Received: from EUR02-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur02on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2607::60a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 44d2ef2b-b764-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 03:04:35 +0100 (CET)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by AS8PR03MB9365.eurprd03.prod.outlook.com
 (2603:10a6:20b:57d::20) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Wed, 11 Dec
 2024 02:04:31 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%7]) with mapi id 15.20.8251.008; Wed, 11 Dec 2024
 02:04: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: 44d2ef2b-b764-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ateuc/89uYLq+AWZwc/O/XrrNINlCu1oghvI7Q/QydrfTVCw1DLblhLtS0qnRiV8XE2QCwpzXKAjG+joj4KUG5tt8VFurtq7PoKzi1sPSZ7khxuagjCJpakX5qhdsJPGowY/ofkmJQ28AftkYzxed/P60x/iHVR2AmJGUMQNpt+JJ7luTpgOcR9CihM6is2tqCLWaiM1iI4x5/xblAUAuxzPd56Euy4lxsNtL/fKE8WqEj3tnJtMXx//Ym4HxwU/vHy5RwVjpM/G2Fybt6B8md1QgT5H+kABt4YYmR/+YTHvGoKc/zaTBTJO34jk4Z338dTSSmuMufgGSQHggNi3tA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=0uyBEB374CkngndbajozsDBZqYCopKoEd2ngGW9fDSo=;
 b=mscycyAlL259n0oPg0QusTRbSe9jQ6OruQR7hMzDbDgY85ptBQLoa9WBeZJMn7YkXQoR6zRUJd9adso83D9k0ZFVYwn4twC6ehgfQC65TbzAOn++6ZLKEgjslQD92F8rKVVapSgoKix5u7BWLlKlV3XdHDPZWrG4pZtjPma3lLey1opAGDKFYDcErVQUj/+oHeEvv26FBEqkwLmaQ9RhkEvWZWQxoh9YYanCKwjQif7luKnCvb/XSDbVxBIjUQepiWR0Na6PqvLyrkZ6FW+hmjrda2m+uRePKSLSrizBiNZPgYcBiiiyqY3Wv6lxYc7RSFjoV7Btc8s/aFQOYl8RNA==
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=0uyBEB374CkngndbajozsDBZqYCopKoEd2ngGW9fDSo=;
 b=s9NurQTpMoQH5RbjDWihsCXawiE2+8SoQqLxDCVP1OjWDDx+MqwLsHNwfPi1Ws5jm8RZ3hhrk7YnvOm4JFUJg3iSVI00wdcQqM15xlrzMe19Z+416aF5AO6eMlUSCDiVJ/cA+arh7Iy2lbr/wTe7khIiZ14v9F9Cc1L1Tdh7NYAqgAMKE54gj9oF1erSIqw+Gip+7Gz8kxg9tSCDb2FqiA5QRptDYiy9osL3tXnBMrKSbGDM45prrIPwsVgH3kpfwmtlbJyBUeE9+Tyx9gtGaOrbDXExbENLo3iOtlX7b5fbkQ/06+1e/YL0Hl6lllPBMHOAKp/sTPB8EF88zLlZ6g==
From: Volodymyr Babchuk 
To: "xen-devel@lists.xenproject.org" 
CC: Volodymyr Babchuk , Andrew Cooper
	, Jan Beulich , Julien Grall
	, Stefano Stabellini , Anthony PERARD
	, Samuel Thibault ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk 
Subject: [PATCH v3 0/3] Add stack protector
Thread-Topic: [PATCH v3 0/3] Add stack protector
Thread-Index: AQHbS3EDPfnUwIrgWUmXfq3bo38udA==
Date: Wed, 11 Dec 2024 02:04:29 +0000
Message-ID: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: git-send-email 2.47.1
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: GV1PR03MB10456:EE_|AS8PR03MB9365:EE_
x-ms-office365-filtering-correlation-id: dd24ca12-a166-495e-106a-08dd198825ec
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|7416014|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?pfQRhg3l/RI6QZfYOm6U5donfnKRg2D8OET4SpphdqdcK4c30yJuTeiPH8?=
 =?iso-8859-1?Q?zJb0CKuYpe86WgtLrmpcX+YYTIAgyegOWCSBy6BUt7y4sTKvKTYIP9saAE?=
 =?iso-8859-1?Q?M8uj6szn2/u434rSVqGWco9hFb2IZCmTLgeB+K/4BMbllDdck77xsSpBms?=
 =?iso-8859-1?Q?aYC0zSRVB0HyLfd7Mf7mmdck0l6e6dLXL+U2o4ltwDIIUROutD4muGFSPi?=
 =?iso-8859-1?Q?bxA8o3G9JrHh7DqADKCxgar2jReOgzrEpq+llb3RprlVZW4YLeLAEgg3Rg?=
 =?iso-8859-1?Q?oNItC2S3hqWdrytgD3iPbVRnPAXPEt4vuwEGjvW2TaOeaE2ak+whP71ya3?=
 =?iso-8859-1?Q?7lkN9thX9sWxI4yArGr5Ujc5FupHtRo/wznSmfXlXZVWAFp1VyM3rGvAHX?=
 =?iso-8859-1?Q?8ZeyPw385grvfjz1tW38PVjart6RCamN6alrdT3FyCIKmga3/j4ZvjgmgB?=
 =?iso-8859-1?Q?0EDz63dSxnn0rdfnS6/gra6/H6bY+Nik2XAHhFscR2OQZ8FCG45vxWiRuY?=
 =?iso-8859-1?Q?I8C2P+ja3yAp2izOSA80tc0ji5R6ya1u6hr8IrWbdnu0BRhRCwRWbP9aI6?=
 =?iso-8859-1?Q?iKO0GdIept6wPv2zty+570nhM88yuurzB5p0SWCoNUbhwuLhoYWOr5cFYx?=
 =?iso-8859-1?Q?5mFQ89j28A52nOaNbyydhBKtWwoHyd+Pwj29vXxQBKFOtcVg5iahmb2D42?=
 =?iso-8859-1?Q?N/63LHAuuLBK5wDLFA8tpPFnIr9yXUTsptV45/1LekYBE2fW1MTJwJbDGB?=
 =?iso-8859-1?Q?PWk42QJkLQxnZymFOgHwNEX4bwwj78p6SCOQ/5tEtdz6ERpxj5VZLIYFl8?=
 =?iso-8859-1?Q?KSy0Ia8NUtnOyPGkG1ebSa/fcum4gqY2MujHy2tW2QeHXK/j/gYDAA5KhH?=
 =?iso-8859-1?Q?XOYVSpgUCKGJp60uXvYCUK/CPuzfpdt6GXvzJJVuSS6gujuxgEYaSHw2Lt?=
 =?iso-8859-1?Q?Cb6I9Y4onv+ZA0tWh9b2+SXhZb8F2mC4Mn3rSJTHvJbfqApL970jiVU9TU?=
 =?iso-8859-1?Q?ShXxbUJdRhjdsyOXRGRS5rsLTx3Mv4eUPjUyV1u9TDyS0VLzOjd22HuqGt?=
 =?iso-8859-1?Q?Llr+yZsDG8T5W3nmExUvlgvfBSFGyEiPzTiw1H0YHq2dE7Q0U01ysvKe4w?=
 =?iso-8859-1?Q?NYRRtXaO2LGdzoJb+58P+73rgzYZZL93iA5QRIHDGbdzD6rddCtFIE//86?=
 =?iso-8859-1?Q?VKVYxwUnXwFJhZPtweOzfdr0piDQZcCYkpAHrOx/Unb7Sz63EZSW1f3CTS?=
 =?iso-8859-1?Q?D5aAnqUNHp9N7HG5gNmoUlbMQ/8LKp4/BdBsGf4jIP5yU0IGsAZSCiGofh?=
 =?iso-8859-1?Q?1XXgV0Q7DtRwu6YlWJ2Iqd3KNJuHajJW1MucYWucMHdeV1bno0G2i3vLul?=
 =?iso-8859-1?Q?PSE7JoGmzWnxde2+HEutOS5averLIwTAamk0GeRqUbsfVoZsagsqQ/5z15?=
 =?iso-8859-1?Q?dVuItg2sYMI+NZ9ngdVV8B/bAYdpGNbn5OaPyw=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?zz3CLDNp7SH81XDGzigaXfz7dTv8QhrxcO5zWkJ4jvKKn7A0CApwsj64Jn?=
 =?iso-8859-1?Q?uPk6sbxY0CLtj8RAcTNCYfl23rI+X1hfeko2EPOtA0X1lMqvP64YI4r25g?=
 =?iso-8859-1?Q?8CRJL4C09hihWSWSco6mNZniU669+IMnJnbrwFSSKmvMzj24QgONLk+zrn?=
 =?iso-8859-1?Q?Ft4a5f1jV6FUeUJi0WumEzPZu+C5z4tMNQn9sQ38mGbkrk8qbw7MnqODMY?=
 =?iso-8859-1?Q?GxuM75nuNZJksXlkuXB2bOKjDaL/cjY0pacUT/ib0wu1mhMpvWqXcoQGR+?=
 =?iso-8859-1?Q?vi89B3Xks832F+C1EGGcOVLjufC7ZpeE62hi1A5XSnKFABCFT1TrJ1LksK?=
 =?iso-8859-1?Q?JwCJn/ZhVCwtPTdXvLk7b8zxC2maeyJdEqi6bbii/Jquw9welrSbry7yHQ?=
 =?iso-8859-1?Q?SawOKyvFYgwdI52oWlOKz+2VCInDLSRKsq/XfBEI1BDDtfka+b1lMwzrSS?=
 =?iso-8859-1?Q?d7XV7mxXXhIzbdKqcJIUEek7CzbvEsUol9Q7SEqlDZXG6/c8Zc8VWUEA6L?=
 =?iso-8859-1?Q?rIu8AaHaRjKyKi4EC47Vy/vwkx7xXSk994S2w2OAlBQo/Dm96MoGNfUfnR?=
 =?iso-8859-1?Q?7vDjSqjUDA2Nwv5XAOb94NHQD67nrDbMF432f65bQNgM3mfrmlS4V/WlUp?=
 =?iso-8859-1?Q?L2KWnILokkxyekg/5MKJHje5qy901F3uqRU4Om5PIgGoEXvZk3WFKMW42V?=
 =?iso-8859-1?Q?QSXxo7vuP8FCEONRjRjQGY/cjubmrPn3qZuKG5Gj7jAiIkHH+190AWKUhv?=
 =?iso-8859-1?Q?TL9iBZvPU3iitE4mA2T8rMazdwJt53+lFEAoeXLBSb1GZ8iAtG6ndGpeaR?=
 =?iso-8859-1?Q?7RVe2bmMA0SstlZYR1kE/MnplCa38/X9A+9/HbzrgCrAzCf+kxSYCUZHe2?=
 =?iso-8859-1?Q?pSJozd6XS26bSJcXSWraMehNDbyVtFJOk1UUHL9tbxtI2yt/9fvOZaMMiZ?=
 =?iso-8859-1?Q?gp7XA67DiWJu6Dt55WwItxqeknQFJQRt9Yvk1BskThN8SsfbcfrtFk800r?=
 =?iso-8859-1?Q?NLDdQq0o59ncTuTz0UvVWHNUM7jXX1vvWYDJlG6AdIXGlYeeTnvxF2ec0f?=
 =?iso-8859-1?Q?/1SWGG9V9nHypZeFNjhOQohvGLWiExQsZ2TmnnM8bQoDFn0o3SWegjnyJi?=
 =?iso-8859-1?Q?c/2oD1lG+Z8I65Zyg6OL8iZlHKGNHRPy5708svpSbHtSGnzfbSQf/sot6U?=
 =?iso-8859-1?Q?935Wqu40MCuqMYsLJnD2Si7n0uEoU8Eei8OtAjek/4kszZudUjHQbDx5Dz?=
 =?iso-8859-1?Q?0bdYINPSkpMBC4HZ/ID8zOaNlbchQqOW3dqjC8aLyq5qxmyA3H0m0Caerv?=
 =?iso-8859-1?Q?/ttXO1sKqGqZKqMc+28lrqi9fNC4QhbHqXgnMzZt4CdPJVTbzHb5O2TJ0s?=
 =?iso-8859-1?Q?Qq1bvgzhtzOiF0G1z8vIeD+B6q3/pC5DOBkZNvc1z4knL3SUJUjoldNeaE?=
 =?iso-8859-1?Q?VO2AaxLSFNV4DlbSDY44L67gWYNtw2nPJbk4ZLVSYujxM04kzaVvr3R6fg?=
 =?iso-8859-1?Q?yy3ERBLyRMm5J8CXVqKDMwtwoAnl9NdX6t6SzKR21J76eDrovyP0UIn5wu?=
 =?iso-8859-1?Q?/XVsOEk0xkopp13g6TH0yeDVFXKNg5sbtPeg5Bj8+gIsxQxoJg2ltFZLsr?=
 =?iso-8859-1?Q?1Sj/OjMH6+x7B6g50lRVm1NZI6Cm6WLfbT0ps3uEyQpZ9VDpQ5iLq8+A?=
 =?iso-8859-1?Q?=3D=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: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dd24ca12-a166-495e-106a-08dd198825ec
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2024 02:04:29.8916
 (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: L0bjWrczd/9bM4om1FGVNX2uU1gsNkWqpEI1T/oum5xSjuYv0Mny1F4HtY3o2oOJzE5yVQbtGQDTAFJg89I60z1nKvsYMSOPehrqBXh6ITQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9365

Both GCC and Clang support -fstack-protector feature, which add stack
canaries to functions where stack corruption is possible. This series
makes possible to use this feature in Xen. I tested this on ARM64 and
it is working as intended. Tested both with GCC and Clang.

It is hard to enable this feature on x86, as GCC stores stack canary
in %fs:40 by default, but Xen can't use %fs for various reasons. It is
possibly to change stack canary location new newer GCC versions, but
this will change minimal GCC requirement, which is also hard due to
various reasons. So, this series focus mostly on ARM and RISCV.

Changes in v3:

 - Removed patch for riscv
 - Changes in individual patches are covered in their respect commit
 messages

Changes in v2:

 - Patch "xen: common: add ability to enable stack protector" was
   divided into two patches.
 - Rebase onto Andrew's patch that removes -fno-stack-protector-all
 - Tested on RISC-V thanks to Oleksii Kurochko
 - Changes in individual patches covered in their respect commit
 messages


Volodymyr Babchuk (3):
  common: remove -fno-stack-protector from EMBEDDED_EXTRA_CFLAGS
  xen: common: add ability to enable stack protector
  xen: arm: enable stack protector feature

 Config.mk                            |  2 +-
 stubdom/Makefile                     |  3 ++
 tools/firmware/Rules.mk              |  2 ++
 tools/tests/x86_emulator/testcase.mk |  2 +-
 xen/Makefile                         |  6 ++++
 xen/arch/arm/Kconfig                 |  1 +
 xen/arch/arm/arm64/head.S            |  3 ++
 xen/arch/arm/setup.c                 |  3 ++
 xen/common/Kconfig                   | 15 +++++++++
 xen/common/Makefile                  |  1 +
 xen/common/stack-protector.c         | 47 ++++++++++++++++++++++++++++
 xen/include/asm-generic/random.h     |  5 +++
 xen/include/xen/stack-protector.h    | 30 ++++++++++++++++++
 13 files changed, 118 insertions(+), 2 deletions(-)
 create mode 100644 xen/common/stack-protector.c
 create mode 100644 xen/include/xen/stack-protector.h

--=20
2.47.1


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 02:04:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 02:04:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853575.1266993 (Exim 4.92)
	(envelope-from )
	id 1tLC5e-0004oR-7a; Wed, 11 Dec 2024 02:04:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853575.1266993; Wed, 11 Dec 2024 02:04: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 1tLC5e-0004oK-43; Wed, 11 Dec 2024 02:04:38 +0000
Received: by outflank-mailman (input) for mailman id 853575;
 Wed, 11 Dec 2024 02:04: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 1tLC5d-0004a4-8x
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 02:04:37 +0000
Received: from EUR02-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur02on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2607::60a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4575a80b-b764-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 03:04:36 +0100 (CET)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by AS8PR03MB9365.eurprd03.prod.outlook.com
 (2603:10a6:20b:57d::20) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Wed, 11 Dec
 2024 02:04:31 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%7]) with mapi id 15.20.8251.008; Wed, 11 Dec 2024
 02:04: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: 4575a80b-b764-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=uqsXJqDz9igsmEp6Br/L++gm0CBerS4O09IZEZUzmZaGtkTlELYnajTMtHIHPfrvTjgF0Rt5miJwN8Oz7sUzUESdeqQPUyoT011L5VUIcvnJi2asQ90vSYZUrqXrn77yBTh4+0ammVNAQLNUfn0lYhdkVZfufV5C4+Iimufx+h3GBBBrEwhx+EfQ7xecRk9pp8Pg3oQyeC9Lcm3FcgcpVpXfYWO3ZTeyK7jZ4RdJxx4t+ixzmmFOk4DXhlV9opKY2wO8o80/25YL45N72L+/6jzOaput/MdAF/epkZL9MRrwP4SgxNfLLy7+b+5oAfX6vOFriocGLFux8NiUvx0fpQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=+SBVbnyLD0YPGsHrZbGEmWYLQu4GIjmGITJeCVcu8vk=;
 b=fNnkVxVw61t8Oa3qbWWo0MTbeD1J+F9g8mZoiq1lSTPfGWpYWpyCX2DuvOE1VYL3lYWvdA6Ger8EYjl2GDdloG7w4QUGSck3vxOg0MHZDK5jH0mf+q01UykhqtUU0wxOfquD47S/vnf4Evb/j7yLi6Ik4onHqh7Ep4dXzNjmNR4b1Cecl8osIhfQk/sIkxAlIFD7kObW36haeHAWIm6eI9ozUY0M3z+WLVyGGXPcIQ5f753c5oP6NHk/Bpsm3RBso8dC+DToX1lyQ7PsulIgu2Jj6sDu9NZUL+uk4toPLbsGks2jaVO9Zo2xBJJw0NsJsX2gOj3EZpQSe91CbWYW4w==
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=+SBVbnyLD0YPGsHrZbGEmWYLQu4GIjmGITJeCVcu8vk=;
 b=UEGY2LCgSvh5EQ5iIwGEdFVE5kWvND8GihaXi7iBdGpNihebU/yBumi8K/qkaoPdbsmRfkWlfEBWzwrb+c942lB3AjabfJkrAwt7KYH5wdAoS37312zZpDHL8OzS/vKMe4ghXN53DtPXINjO12v/8ITm9chAA/H7F5E5V2vErCX4r21nULKWofbz0qe3mxiS22ld774XjeQyH010BguCwH7UHQJjObHhmQVbJCmVqPYQMqVY+CDPwlohEN/n4f1UhS8gBw0TJY2mB2vnQHc4FunkwWCJPLx4kfQIuCX4JZqu5jbDdYXuB//HbdVIo6H4eaZRteYnYxPgqiRhGHVwlw==
From: Volodymyr Babchuk 
To: "xen-devel@lists.xenproject.org" 
CC: Volodymyr Babchuk , Andrew Cooper
	, Jan Beulich , Julien Grall
	, Stefano Stabellini , Anthony PERARD
	, Samuel Thibault ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= 
Subject: [PATCH v3 1/3] common: remove -fno-stack-protector from
 EMBEDDED_EXTRA_CFLAGS
Thread-Topic: [PATCH v3 1/3] common: remove -fno-stack-protector from
 EMBEDDED_EXTRA_CFLAGS
Thread-Index: AQHbS3EDx5+OWqJotkip8Dq3lsA6Cw==
Date: Wed, 11 Dec 2024 02:04:30 +0000
Message-ID: <20241211020424.401614-2-volodymyr_babchuk@epam.com>
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
In-Reply-To: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: git-send-email 2.47.1
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: GV1PR03MB10456:EE_|AS8PR03MB9365:EE_
x-ms-office365-filtering-correlation-id: 85d67761-3a4e-4e58-b5df-08dd19882702
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?L7L4DO48bdEtrdL4IhxWVjAp2nULU1eNfoeBmhimrjO6nwT0Ty4lCfIUHe?=
 =?iso-8859-1?Q?lzrxNAcfPgYzpaUA9O068zUKgLaepD92YUHkDvuFOBoJw81LgiDnKjjimd?=
 =?iso-8859-1?Q?zqCSfkokaCioqW4Pb0n5SXdTUMPxfmDv/egPB06H1SRQJUAHEqPEw6juLV?=
 =?iso-8859-1?Q?NwWsEYk8vZoprUwsiCssZuBEV0y2BfBfmiHgKVuOe8eLP36hcqJiUSMc6l?=
 =?iso-8859-1?Q?sOfaVvazwSAm90sGXJLesj7sjRya3JJIQmfnr5cObn1/S5Zvz3Tw2kNg2X?=
 =?iso-8859-1?Q?AE+NC0PNu4xyYEqGO4lKwvZ2/Q3thSAr77eFKXR6x1QKH38MskWKsIpBOX?=
 =?iso-8859-1?Q?b+g7L8AAwUtA8I0kw+nc2SXVx96uLQIA9QfpSRQ+aFVkrEJbmX3F0juR6C?=
 =?iso-8859-1?Q?kIsAWrQ588NOMF609kF8igvstOuE+XFVYUUqpfWzSlHZ2wHJVKopbx2H5H?=
 =?iso-8859-1?Q?Nm5r3XJ1n5K4ztfErdYVPbZC2humGuS/LS0bs6eRSdZhFsY7l/7rw2d4nA?=
 =?iso-8859-1?Q?c0wOhun5xMNnuBXZczlX9U73DDzcoOqpUaF1twIi/4iF9LXlEIRCjqKigu?=
 =?iso-8859-1?Q?53pFLUEomMkAb4oJ2x57uUNneqn/aDOHBxJdenGkAKltEv29eTwpDSIroE?=
 =?iso-8859-1?Q?wtED5u3Z8fgqZtA6ajoZlZQGoapivFiUEaOSjzR/F8uF1ok4bMdl3ntmFN?=
 =?iso-8859-1?Q?2hW5OP0btMiUdHuCx9Snw1FIHEyKEj9/dkcQ4aU/x2sDcbk0omenneTiBe?=
 =?iso-8859-1?Q?33Bmn6lkEbw5IP1zw881z+Lo5rxJrF6yvVe5uCZnJcGyevyDDPVIEZoswz?=
 =?iso-8859-1?Q?/Co5ygKpt1Pp37Wwm0fVXRH8WylxhdChmL3RQH1MAajuSJfTfWM7QjA5gL?=
 =?iso-8859-1?Q?xJvpUvD/Usg+h1aW82QV/HSJlj0NxNhj4USQEqj+AnKrgNtllITj2ntip+?=
 =?iso-8859-1?Q?IjA/B8r5fTYqPs+Q16AyeaLTaN5ZDCnb8Uq8/ZxxIu7U2dTo1ixPCnJJQh?=
 =?iso-8859-1?Q?H48HtBhVu0462O/dMgBpJEQhCtLv+IUsjuwY50DjJSo30toDIosKDBaTIy?=
 =?iso-8859-1?Q?dDwX0qYIwgUCN4cszWHQ+naqxzgwAMcou/CMWgoIvC1//P+Wpfq0hDZjNu?=
 =?iso-8859-1?Q?uhT4sfvBBvhgZs+SPQDh8OFF0XpnZux7s662YcgC92dEflP7HNYv+yrkis?=
 =?iso-8859-1?Q?Et7/+5J7adeXzOvO0eStXFnl5XKuVxvY0mfUzp0jQrwtSiKzAxnFBfXytZ?=
 =?iso-8859-1?Q?M+8ofZ4fgh0YJloqims3+74Bb5R2C4jetggANV4tuUn9zRFVGlobIRkwiZ?=
 =?iso-8859-1?Q?Il3vmx9sinKdXJ0NwLHwvqlS4+u7KrsfBSH+/s40ORGtrtbH6aJvV1i57e?=
 =?iso-8859-1?Q?DDjXjKeELZEodksvKcEmkFWEfD28wu3FEv7BVrFycBUPtjPrNswGi8AhSn?=
 =?iso-8859-1?Q?PKpYsTZIDSJBsVO/R32j2runrd3ERqvYDwfcWA=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?PBTosIs+MohPGckGf68nIKsdSyx47ohfCF9DAwZDWDcReFgw4aGrZMR6/3?=
 =?iso-8859-1?Q?l2tJjEO64ODzszXl4u6YmXsZZ8rscfLQOqCOMcIKpyXzPZgSu/EK9K7hlo?=
 =?iso-8859-1?Q?KKeQKgmkaBuUClN5h2epe1quwzJZXVCBBRg4vWQsJ+TxVOJKGW7zQemRsT?=
 =?iso-8859-1?Q?SfYuyzQOmeLXu6Q4wWUp40tvs32ojZOZlwKAizW/ZHJjAQGCdSlvTENvfL?=
 =?iso-8859-1?Q?QQ5qSvqa2bUc41XM9FmwG2XAYsUuJVMSlhbvciRmbGY3aXw8Pga+TLksI7?=
 =?iso-8859-1?Q?xZJur4Nc2CMIPyWHDTCVTNboLUYn/GtZpYQ+LKPefPIn1YhcsfMlulsiOg?=
 =?iso-8859-1?Q?umHqDQTiDt3/idP5Z+MjAYctAtWapvl0GoVq4WVLX4vZcIITUK24ZN2jEM?=
 =?iso-8859-1?Q?En3mEAZHaPzrJ+DlXl7lPKVvkfuUL0//XHCOhHHiSg4REKwdliSteMdWrU?=
 =?iso-8859-1?Q?HLaPK6SczRIMZfrLWwUWK7r1o1TUcW6ZOv1TBr9qohCqsNhqcMhHjDri+y?=
 =?iso-8859-1?Q?NBlODKO/3WZ4/qsr1LtvcSXasEjX0C1BxqRMCRr6uJLKYaUD92dUVbRzrJ?=
 =?iso-8859-1?Q?NU3BSgmegnoidJUF9ut/OubQVfII54r8otjwv5OtonObwALzH8Ca82IdI3?=
 =?iso-8859-1?Q?pp519gpe51wcMRMHzreDfC2UXQ/S2qcuj9oEdaZc0B2XqhtHZkEjvtETt+?=
 =?iso-8859-1?Q?PI6a4FU1oxbOxSRtXp39+v4L5MDAUjoHMTjfNIB4Yf/xFdeMV2cCrdltri?=
 =?iso-8859-1?Q?bxJ7lFCmZuJsHQehNRYkGrWLCUDZypj2xQ2+LzLYQMjP73tcrc6s9Okbq6?=
 =?iso-8859-1?Q?R/2Kp4+4Irc547ejsMDrE/hTN8ykaO3uumcIZFpqDKb8X6u6d1LEgMSUyG?=
 =?iso-8859-1?Q?U/5yajxCrazxdwz+KWBGHqamaE9xc4gUJ+FDzPRX6wnsBVfwfDP3dfEGV2?=
 =?iso-8859-1?Q?gpsCDqK0zpSQ4kVfKT5H52s57DpghFDwHt52/srUCBLdX+iamjuJ6XjDaX?=
 =?iso-8859-1?Q?LufoL8bVitj7lMZv5eUucHhoXdpctcQeYp6MruvXzdaTUWlegZtGGxpngC?=
 =?iso-8859-1?Q?fWRmo2vvZ7FxC11APNsXO8/x2kAWT1eW/jwDZb2tFOatmkonuLgYnwdbzo?=
 =?iso-8859-1?Q?jd86UDE/rQvfxXkW/TIzn2TDcVvk13QH0ZA0cdLeYOck2zz7IR6vVMz7DT?=
 =?iso-8859-1?Q?ccNxKfC2/omyuLTmuULK8neTeuLGTq5VMWfCvvjFA/KYTB3FRIVsdwFhyx?=
 =?iso-8859-1?Q?5kERgDtghIceb/7AOEgrI5qO5kgflrwPdkCmfwgpcSuxvaPZMG5bon7ICw?=
 =?iso-8859-1?Q?mMG8b4Ma29Zi3TStvlfgzR3EMPih2Z75uYb3kA/ikjZreirVhKxMx/AHGF?=
 =?iso-8859-1?Q?+EePH+Ksd+OHPKBmjaJ1PWi9Iq+bOCAjVeuU28AfsnrusihxvBZ+nyq/Pg?=
 =?iso-8859-1?Q?XxKWuOnEl71AfGekKOzcDrbvSYlcFlUNdC3yLGsrjTCRVz6EiVu0siZHo0?=
 =?iso-8859-1?Q?8jvCUH9/XsiwffVedHsluRvX6gMfm+BfbsyktTg5/TDP0yKQB6o34vXrdr?=
 =?iso-8859-1?Q?RMrBuclfQ/s3YJYKqUJ4LaVS1E9LCzs3qfaBBrcLJ9w2U6SJIZR6i5Mb3s?=
 =?iso-8859-1?Q?OSP048ojnuDdsGsin7YixpGjP8LR2ZFlxMZuT8+V127+I5/Z1P12HoHQ?=
 =?iso-8859-1?Q?=3D=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: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 85d67761-3a4e-4e58-b5df-08dd19882702
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2024 02:04:30.2690
 (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: igq6fdkktG3Hpo2lOAzuztof057LWBbvvv0PG0S6RVCspnQ8jEb6JE7NBfnlucAI3cv7bVYgk7MT6NrrXqXHp+LJ+KTLdL+Qx7ERui52vd4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9365

This patch is preparation for making stack protector
configurable. First step is to remove -fno-stack-protector flag from
EMBEDDED_EXTRA_CFLAGS so separate components (Hypervisor in this case)
can enable/disable this feature by themselves.

Signed-off-by: Volodymyr Babchuk 

---

Changes in v3:
 - Reword commit message
 - Use CFLAGS +=3D instead of cc-optios-add
Changes in v2:
 - New in v2
---
 Config.mk                            | 2 +-
 stubdom/Makefile                     | 3 +++
 tools/firmware/Rules.mk              | 2 ++
 tools/tests/x86_emulator/testcase.mk | 2 +-
 xen/Makefile                         | 2 ++
 5 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/Config.mk b/Config.mk
index fa0414055b..c9fef4659f 100644
--- a/Config.mk
+++ b/Config.mk
@@ -190,7 +190,7 @@ endif
 APPEND_LDFLAGS +=3D $(foreach i, $(APPEND_LIB), -L$(i))
 APPEND_CFLAGS +=3D $(foreach i, $(APPEND_INCLUDES), -I$(i))
=20
-EMBEDDED_EXTRA_CFLAGS :=3D -fno-pie -fno-stack-protector
+EMBEDDED_EXTRA_CFLAGS :=3D -fno-pie
 EMBEDDED_EXTRA_CFLAGS +=3D -fno-exceptions -fno-asynchronous-unwind-tables
=20
 XEN_EXTFILES_URL ?=3D https://xenbits.xen.org/xen-extfiles
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 2a81af28a1..4c9186499d 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -14,6 +14,8 @@ export debug=3Dy
 # Moved from config/StdGNU.mk
 CFLAGS +=3D -O1 -fno-omit-frame-pointer
=20
+CFLAGS +=3D -fno-stack-protector
+
 ifeq (,$(findstring clean,$(MAKECMDGOALS)))
   ifeq ($(wildcard $(MINI_OS)/Config.mk),)
     $(error Please run 'make mini-os-dir' in top-level directory)
@@ -54,6 +56,7 @@ TARGET_CFLAGS +=3D $(CFLAGS)
 TARGET_CPPFLAGS +=3D $(CPPFLAGS)
 $(call cc-options-add,TARGET_CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
=20
+
 # Do not use host headers and libs
 GCC_INSTALL =3D $(shell LANG=3DC gcc -print-search-dirs | sed -n -e 's/ins=
tall: \(.*\)/\1/p')
 TARGET_CPPFLAGS +=3D -U __linux__ -U __FreeBSD__ -U __sun__
diff --git a/tools/firmware/Rules.mk b/tools/firmware/Rules.mk
index d3482c9ec4..be2692695d 100644
--- a/tools/firmware/Rules.mk
+++ b/tools/firmware/Rules.mk
@@ -11,6 +11,8 @@ ifneq ($(debug),y)
 CFLAGS +=3D -DNDEBUG
 endif
=20
+CFLAGS +=3D -fno-stack-protector
+
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
=20
 $(call cc-option-add,CFLAGS,CC,-fcf-protection=3Dnone)
diff --git a/tools/tests/x86_emulator/testcase.mk b/tools/tests/x86_emulato=
r/testcase.mk
index fc95e24589..7875b95d7c 100644
--- a/tools/tests/x86_emulator/testcase.mk
+++ b/tools/tests/x86_emulator/testcase.mk
@@ -4,7 +4,7 @@ include $(XEN_ROOT)/tools/Rules.mk
=20
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
=20
-CFLAGS +=3D -fno-builtin -g0 $($(TESTCASE)-cflags)
+CFLAGS +=3D -fno-builtin -fno-stack-protector -g0 $($(TESTCASE)-cflags)
=20
 LDFLAGS_DIRECT +=3D $(shell { $(LD) -v --warn-rwx-segments; } >/dev/null 2=
>&1 && echo --no-warn-rwx-segments)
=20
diff --git a/xen/Makefile b/xen/Makefile
index 2e1a925c84..34ed8c0fc7 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -432,6 +432,8 @@ else
 CFLAGS_UBSAN :=3D
 endif
=20
+CFLAGS +=3D -fno-stack-protector
+
 ifeq ($(CONFIG_LTO),y)
 CFLAGS +=3D -flto
 LDFLAGS-$(CONFIG_CC_IS_CLANG) +=3D -plugin LLVMgold.so
--=20
2.47.1


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 02:04:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 02:04:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853577.1267010 (Exim 4.92)
	(envelope-from )
	id 1tLC5f-00059P-UM; Wed, 11 Dec 2024 02:04:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853577.1267010; Wed, 11 Dec 2024 02:04:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLC5f-00057Z-Nq; Wed, 11 Dec 2024 02:04:39 +0000
Received: by outflank-mailman (input) for mailman id 853577;
 Wed, 11 Dec 2024 02:04: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 1tLC5f-0004a4-9a
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 02:04:39 +0000
Received: from EUR02-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur02on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2607::60a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 460fbfa0-b764-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 03:04:37 +0100 (CET)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by AS8PR03MB9365.eurprd03.prod.outlook.com
 (2603:10a6:20b:57d::20) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Wed, 11 Dec
 2024 02:04:32 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%7]) with mapi id 15.20.8251.008; Wed, 11 Dec 2024
 02:04: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: 460fbfa0-b764-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=OT78h65K4E9xQWiZ7n65iJPNFV5XhFzfqBj/3omUeJ1E7tD5XIX/iESfZPfJgAhdPz3mNc3oD93nH+xpI4dsAWYjXZX826XXTRbrKTd0iqUDrLLuGKHpzFeljWh15O1yUIsD8PUKwhhMHzmlf0Dhx/yntGuiEEg+V1cKnI9avH9t6RiiBGo6tARkFEqaWwKBmruCaQ0vLeZxhV7XE9tAkSCATU5txi0EfEbso+YgpXMg6Jb762k8YOMd2+ar5ycPdPC17GyvnNJfmlzAK38T60J0krsOXvL8KnMTPdwlXndtWXqZ1t0z5rmJ5bHUC1mWPJbvc0YJKBuAXaBlqVbV6w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=pj/nhgXuxO2BrnIrOHAoc56dHIEuF1g5kUOJqX9YgsA=;
 b=jj/Yg9F6HmwqkQUL7de8jIcL0uvlOvloUL5Iwi55RDBK//mWk84i2NoTfEe+DWCG3Fto+E0O78Qy5aiHo215vd+R+Lxsu2QLSYBblOCy1xHaeRtAMJNxr4u9Vn5uW6KpJ+OoIzbzKU03jXm7dOJ7mBK/wOs/s8GDdDk0tTuceYUwBEpJK8h2iidsgloy5y7I5JIegWv+O6llB1pqXV+UYjVs3cpJPldGaCYxTXfCt/gTa7q1q/0PbUk+Ax+YUhCsboNSSQdInLkqGlQt1okTbFjqx+p4QqIx4rbxTnksL6DaL//aZLllwqUa4BFSyWXDHqdBON0vLKcCtuCpzQEePQ==
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=pj/nhgXuxO2BrnIrOHAoc56dHIEuF1g5kUOJqX9YgsA=;
 b=voZhMb8qzCJ/xuIwjPXo29EdKK3USyXGlLVRvi4HbLfS76lDjLS6pube1vTzaqyiRm2sCtVdx5p3E3JrW8KkQEXUCcGGJryKQziGxo0djoO27X+omimlfRBXiKZvtqxofwSxNN2k0O+4XFywx8sbERuW1gSx5COv6J+Cq/JPJX3O3It0UEb3C9wkqzFKyAPvKrx3Tjt+0l6lXSDNDFPCO3LO5i6Vt9sgTd0O65Bl1IwI6C8oEcOd1k2kmQ1LjgCaFxBrMA530BN5MJfTxsHYNBIucnqHIc9KXK786tD8pEXOrwjOOH/qsYUzQ1onNfTRT+ZnmYglk8ROOs+iOmqdgQ==
From: Volodymyr Babchuk 
To: "xen-devel@lists.xenproject.org" 
CC: Volodymyr Babchuk , Andrew Cooper
	, Jan Beulich , Julien Grall
	, Stefano Stabellini 
Subject: [PATCH v3 2/3] xen: common: add ability to enable stack protector
Thread-Topic: [PATCH v3 2/3] xen: common: add ability to enable stack
 protector
Thread-Index: AQHbS3ED5ZENsqu4Z0+AIfWfHmGdmQ==
Date: Wed, 11 Dec 2024 02:04:30 +0000
Message-ID: <20241211020424.401614-3-volodymyr_babchuk@epam.com>
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
In-Reply-To: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: git-send-email 2.47.1
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: GV1PR03MB10456:EE_|AS8PR03MB9365:EE_
x-ms-office365-filtering-correlation-id: 52bfae58-3baa-4e48-f333-08dd19882730
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?MnpDMnVWZElTYXFlclgzN3hVQ3B1WjhTQWMvMDE3NW56bW9tZWhjb0xPbytu?=
 =?utf-8?B?dXpnRTFqUWN5U1pvN1ZQeVVOT21sSnBuVXFUWEFoUWFUa2hkSDJ3dCtnc1hJ?=
 =?utf-8?B?am9kTzJmRG50NXhvb3M5ZTFBRHN5V2FBVVdSZjN3N25iSm93aTlwK2xLN1ls?=
 =?utf-8?B?RGdRaHdOZC83QVZzYnlKaVVFRXFYNThkYStKcmF1QktmemR3dy9tU1NpajBw?=
 =?utf-8?B?ZWZFcG4vVGthVzRhekV4N2xtYzRYM3ZXbGFvS0lCdFY4VThhUTl6UC9OSC9m?=
 =?utf-8?B?b3lpUnF6OXhqK1Uvby9TNmQ4N0FnWkdxbkIyeEdNV0tVQkM4emVkbk9oYWg4?=
 =?utf-8?B?L0VkV25mYTdmQnhlcTQ2amtNVmRSZXMzSUZTNXdhZkxFSzI5azFPdmJMelNM?=
 =?utf-8?B?aTU0TExxcjUrU2FDODhrdDA5bm5JZ1l6QXZRSSt6MFgxQjRSQmpSOGQrV21w?=
 =?utf-8?B?RlEyekhVN1lRbEFjODR1SXJIL0JjNytXd25mNmVqTFp5S1Zhb3RhbTRnOU9q?=
 =?utf-8?B?cUFLRXZwNXhIczJJQlVUZTdXK3JlYlBXeWNxTm5TZm40ckdodi9XN3VDYnNq?=
 =?utf-8?B?ckxmcDFLQmlWQTFZVGNnbmZURUNGcURXdEdvQURjVk1WNDUyc3RTK29mZ1Vw?=
 =?utf-8?B?a1Vhb1BuU092K1YvYm9aRW5DN0RoeFJjVWlPR0lxeWxiUVZ2N1I0b1RveXBQ?=
 =?utf-8?B?MFplT2dJUHkzUWRDRnhXSGNYV1JqNG5sVUhxMVJyRE5nd3FGZHJZZEpKNlJa?=
 =?utf-8?B?VnZtcko0OHNGTGdPenJOT1NSTWF4ekM1NGl1L0JFY0hLNThJRXh6aXB5Z2tw?=
 =?utf-8?B?dGRpZXEvaVdOR0RxMVFRK1o2S2IwUjIyQmRNczhXdW5EUFJQR0tyWG1EWGtW?=
 =?utf-8?B?ZFplUWlnT1l4dXUyQ1M5V3FDRFBFVGJ5dEJKeHN6WEFPRW5tdG5qT2pDbW5u?=
 =?utf-8?B?ZTJZM2NpKzJqOVF0MSt6SVYyaFc0bEtCWlE0ZFh3UEpjM09Vei94N3JLK0tD?=
 =?utf-8?B?V1E5RzMrbk41WVVPcjZyK2haSFN3K3pOeU9abFJNalU5U2k5VlF6SWQ1cnBa?=
 =?utf-8?B?UFZXa29McHloSm5FUktEUkV3U2U3TWVNU2dOQ3pDaElLSC8vVWljWmIwRzhC?=
 =?utf-8?B?dU5URG5CRmNla2xqUjMyS0FyWGxGNUlQUFlTRktVaVJGK1MzMDI5bWJPcEtX?=
 =?utf-8?B?aURmWVp3b2NJZkw3OGI4Z09uTnpxbHpQSWkrTkU0Y3llVG5EN1FHcDJETzVa?=
 =?utf-8?B?K21qS1h0QVZNcktuZHNLV0l4S2hMZFE1TVRnMTRnWGYreGpKVmZzby9aMFFG?=
 =?utf-8?B?bmg0akdhWStxUm9IVWlKSXhVdkxBZjhTMmM4elFkampkZVg0emNDRGJ6aGov?=
 =?utf-8?B?eUdacHBDcC83MHI3Ujh6V2JvSnZ3Vy9ZaERXTXY0K2FNUjRsL0lsMFdkU3RX?=
 =?utf-8?B?azE0b2l0NEpZanFqeGh4WDhEVEtHVWF6eFZhai9wR2pxQndYTktvRHRkeHNU?=
 =?utf-8?B?QUU1Ly9ac0tGWGljMXNCajBYTDMxUnIyMCs4TEFwaDBkWVR4dTk4ZERpTGVD?=
 =?utf-8?B?VW5KV3BaVVdvOWtnalcvcTg3V2NOelNuWlMybjJvZjlvREM2TUQ2NDZZWDBp?=
 =?utf-8?B?U3Bibm1uVXJqNlc2S3dVdkdxKzJJTWkvV09pT0VmN2tEL0lhTVFnUCtzQjNh?=
 =?utf-8?B?RE5XQ1YyelRkTExpMGcydUpybE5PUnE2V08zZHEvMmlXNEJGMVpROVBiM0kr?=
 =?utf-8?B?VzhKNkx2ZERRZVdqcVJlTlhhOWdSdFk4eFZ0NE92aks4T09wcGFPaEF4Ly9n?=
 =?utf-8?B?MzFmS1JwRWdLV05TL1E5ejNqamN5THpKN3FDVlNOWFpuZTJ1UDBWckNQUEt6?=
 =?utf-8?B?ZE1peWpFQXZlUWlkVUJjRmU1dDViMkk4VG5JYnhqaHYyQ0E9PQ==?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?bk1CWHIxM1NZMnNyZzE2b3dYUUw2MFZDMUpGOE1CclY0aHkvMHJBVnJlclNi?=
 =?utf-8?B?YlpGMGRkZDVPY3pxSnFRWVZlR3JyMkhDNFpHUVlVVkFITjdwV0R3NHZxbzds?=
 =?utf-8?B?TWNiajRrczNkY21TUTA5M0ZMbmpPMkhsa2l0M2J1RmdUSnVFaFNuT1B5dWNH?=
 =?utf-8?B?WU45YVdSaDM2NC8rLzR0cHNPc25HblY3TCtCWUdxWkwvbHFIaXcrWUlEb3dn?=
 =?utf-8?B?S1VzNzdGUUtDWWVwbUJja2hkSnlxRE1iNFlaNkZOY1IvaGVkbEFkZy9WV2hu?=
 =?utf-8?B?QitXZ1F1NHZmaVZqbTM1d3ZGVExLVnB2bG9rUHFzNG9CYWV0L25weTVEem9W?=
 =?utf-8?B?amIwWW4wM1VDb1pvWmwxMkVTYWlROElsZExJeTNqYTd1YmxwZ2tWbnU2RmxP?=
 =?utf-8?B?ekRyVk9vSGdEcVJzOHpZVzFCalF0aVJLbjFqVmtKYzJWd2JjR0RxSm92Q29S?=
 =?utf-8?B?bjllWUF6MldPKzhyaWV0N05jR0k3d01TRGx1TG1UM1dOVGJHSlJ4eUowT2Fw?=
 =?utf-8?B?QnIyeFMvTkVBYXE4OFI4aktkNEFrQVhTOHpLa3FqS2crZzB3eTNjMjRacXp1?=
 =?utf-8?B?b203TXhYcDQ5UURESE1OSFVwTVNTVkF1MStFSVQ3aTBuMzZpUXo2VHdOckRn?=
 =?utf-8?B?ZXFNMC9selQ4UlpqQVN0ZlFNNDlvV3piazB5Y0xCQVBHVEhkeU5BNGdRVnEv?=
 =?utf-8?B?cDlQbkpxNEd3Q0xjK1lqNmZ1TzhjYnhjWWlZRTVZTTNRRjZpUVoxR05OWlEw?=
 =?utf-8?B?azc0RlpxVXlsVXgvcGdFemlMc2RZY0poQzRra0J2emwxU0tyS2h0WnpJUnRW?=
 =?utf-8?B?dEJ2TnB3MHhOdVAvZTBoaDQ5blFQZk14WjY3QzhDd0Zxa3NPb2JwaThXeXRr?=
 =?utf-8?B?bXJ4RUFNQm5Ca1c0QkFmVzJhUWd4ODV3MkM0RDN0YXhrMjlEMXh3L3VVWUN4?=
 =?utf-8?B?VTlHMEJGL05haFhuam1WdXYzc0s2N0ZsZlhOOFFqRGJ2UDcwdEpBY2RJeHVT?=
 =?utf-8?B?aEViWlR1c2lTNXJ5SnBJS3IxUDhtTGpsUzVGZElWM0JKNytXZ3Z1ZGI1NG15?=
 =?utf-8?B?WUt0SW1WQVE3RTZlSE9rREV0TXREckFMZVhpUGZsbkRvVVo3ZG9PODFhRG5M?=
 =?utf-8?B?QkloL2k0dThHOWJYRHZGVkk0QjJyeG4zNFVwUUVWZmRHM2RZeFFieTAyS1NM?=
 =?utf-8?B?ZThFWmFzbXFFVzdMVHZnQWR6NXV6ZnN5RWZLWXJPZG1ZNkhvVjc5d1J5c0FN?=
 =?utf-8?B?L1B0RGN1cTIwa3R2VzlHZ0VGQmdSWW9qc1JrRWhjQVNEZkwzTWJ0VVRQZzJH?=
 =?utf-8?B?VFVtcmFFUFhMY29xK1p3MmwzYnBMVG9iNmxWbmR3TE84T2pwSHc0S3k4MXRK?=
 =?utf-8?B?RG00all5ZXowQXE5blVIUjJWWW02cnExZU04d2hxUUR3VE5TMFpVY1M5cVVQ?=
 =?utf-8?B?SVhlOU1GTGI3RVRWUkl2R3k3WW02ZEg1UzBXV1I1eHF0b214VVBGZlBQKzN1?=
 =?utf-8?B?eDVhdmJycXVGbWNIc1FLeGlPaTBvN0dWNVo5aER4Z2pTeklLZ29XQWJCL2tt?=
 =?utf-8?B?dXRybW1TZVJOUTFHckIzRlRpakI0K3FPSlB4NWl0ZzVjRlhITHUyQzlhZmhU?=
 =?utf-8?B?SUtWbHh4MG1sdmtucWphMUFBYkpjMWEyczQvOHl3UnFSamVTNFVBSHNmdElQ?=
 =?utf-8?B?UmRGclU3T29CbzU4OEwyRWxjVDg0N3JRaXM5bTkrc1pwdm9hakduenl0OS9w?=
 =?utf-8?B?N2Nza1pyeTRjS0lBS3FoaW41TERmZ1JEaWpSaVRlRnFHajM2N0FkTjE2YVpr?=
 =?utf-8?B?akd0MnJqcTRXWVJBN2ZMTUw2V1dlQURVZ3dJcjBRdmxZRVNLWFhybnVDZFBx?=
 =?utf-8?B?V3l0ZXltT0FYRlp6aytQNVVUb3BtNms1VTFnMm1VemhLZ0h4bVc5UkdOYXJY?=
 =?utf-8?B?bEtRYjRoVll5dGN4VS9lMXhaKzdFUnR3L0J6cmJMMjJ5dDNxMkJTTlhHSFVN?=
 =?utf-8?B?Zm03L0IvQUVsMmMraXNZakhuVHdMdTU0M2tVRkEzSEJweE5TMDVuZkNmUGNi?=
 =?utf-8?B?bG92QmtKRTFPMUZHSEk1WFIrd3dzSFMzeEYzbzd5UEFZN3R5VXh6ZDZxcWdZ?=
 =?utf-8?B?WFUzUVJjc1NrWmpNVFZOMFUzd2RPblYxcE85RXlRZkdFeHpydUZCcm1JalB2?=
 =?utf-8?B?R2c9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <549BB8EE78CD0E44856ABAF33634CF3D@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: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 52bfae58-3baa-4e48-f333-08dd19882730
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2024 02:04:30.6083
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: und5uM0Y6qfmy3kFhAOaLA9gHjBVUXlMDrlOS+vGfshN3Oq4ZaX+4xv7sbS8L4ooynsDL9zxC7aB33VeiLtD7EqLE87kLpWA7qV0Pg0r9/Q=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9365

Qm90aCBHQ0MgYW5kIENsYW5nIHN1cHBvcnQgLWZzdGFjay1wcm90ZWN0b3IgZmVhdHVyZSwgd2hp
Y2ggYWRkIHN0YWNrDQpjYW5hcmllcyB0byBmdW5jdGlvbnMgd2hlcmUgc3RhY2sgY29ycnVwdGlv
biBpcyBwb3NzaWJsZS4gVGhpcyBwYXRjaA0KbWFrZXMgZ2VuZXJhbCBwcmVwYXJhdGlvbnMgdG8g
ZW5hYmxlIHRoaXMgZmVhdHVyZSBvbiBkaWZmZXJlbnQNCnN1cHBvcnRlZCBhcmNoaXRlY3R1cmVz
Og0KDQogLSBBZGRlZCBDT05GSUdfSEFTX1NUQUNLX1BST1RFQ1RPUiBvcHRpb24gc28gZWFjaCBh
cmNoaXRlY3R1cmUNCiAgIGNhbiBlbmFibGUgdGhpcyBmZWF0dXJlIGluZGl2aWR1YWxseQ0KIC0g
QWRkZWQgdXNlci1zZWxlY3RhYmxlIENPTkZJR19TVEFDS19QUk9URUNUT1Igb3B0aW9uDQogLSBJ
bXBsZW1lbnRlZCBjb2RlIHRoYXQgc2V0cyB1cCByYW5kb20gc3RhY2sgY2FuYXJ5IGFuZCBhIGJh
c2ljDQogICBoYW5kbGVyIGZvciBzdGFjayBwcm90ZWN0b3IgZmFpbHVyZXMNCg0KU3RhY2sgZ3Vh
cmQgdmFsdWUgaXMgaW5pdGlhbGl6ZWQgaW4gdGhyZWUgcGhhc2VzOg0KDQoxLiBQcmUtZGVmaW5l
ZCByYW5kb21seS1zZWxlY3RlZCB2YWx1ZS4NCg0KMi4gRWFybHkgdXNlIG9mIGxpbmVhciBjb25n
cnVlbnQgcmFuZG9tIG51bWJlciBnZW5lcmF0b3IuIEl0IHJlbGllcyBvbg0KZ2V0X2N5Y2xlcygp
IGJlaW5nIGF2YWlsYWJsZSB2ZXJ5IGVhcmx5LiBJZiBnZXRfY3ljbGVzKCkgcmV0dXJucyB6ZXJv
LA0KaXQgd291bGQgbGVhdmUgcHJlLWRlZmluZWQgdmFsdWUgZnJvbSB0aGUgcHJldmlvdXMgc3Rl
cC4gRXZlbiB3aGVuDQpnZXRfY3ljbGVzKCkgaXMgYXZhaWxhYmxlLCBpdCdzIHJldHVybiB2YWx1
ZSBtYXkgYmUgZWFzaWx5IHByZWRpY3RlZCwNCmVzcGVjaWFsbHkgb24gZW1iZWRkZWQgc3lzdGVt
cywgd2hlcmUgYm9vdCB0aW1lIGlzIHF1aXRlIGNvbnNpc3RlbnQuDQoNCjMuIEFmdGVyIGh5cGVy
dmlzb3IgaXMgc3VmZmljaWVudGx5IGluaXRpYWxpemVkLCBzdGFjayBndWFyZCBjYW4gYmUNCnNl
dC11cCB3aXRoIGdldF9yYW5kb20oKSBmdW5jdGlvbiwgd2hpY2ggaXMgZXhwZWN0ZWQgdG8gcHJv
dmlkZSBiZXR0ZXINCnJhbmRvbW5lc3MuDQoNCkFsc28gdGhpcyBwYXRjaCBhZGRzIGNvbW1lbnQg
dG8gYXNtLWdlbmVyaWMvcmFuZG9tLmggYWJvdXQgc3RhY2sNCnByb3RlY3RvciBkZXBlbmRlbmN5
IG9uIGl0Lg0KDQpTaWduZWQtb2ZmLWJ5OiBWb2xvZHlteXIgQmFiY2h1ayA8dm9sb2R5bXlyX2Jh
YmNodWtAZXBhbS5jb20+DQoNCi0tLQ0KDQpDaGFuZ2VzIGluIHYzOg0KIC0gRml4ZWQgY29kaW5n
IHN0eWxlIGluIHN0YWNrLXByb3RlY3Rvci5oDQogLSBFeHRlbmRlZCBwYW5pYygpIG1lc3NhZ2UN
CiAtIEluY2x1ZGVkIG1pc3NlZCByYW5kb20uaA0KIC0gUmVuYW1lZCBLY29uZmlnIG9wdGlvbg0K
IC0gVXNlZCBBbmRyZXcncyBzdWdnZXN0aW9uIGZvciB0aGUgS2NvbmZpZyBoZWxwIHRleHQNCiAt
IEFkZGVkICJhc21saW5rYWdlIiBhdHRyaWJ1dGUgdG8gX19zdGFja19jaGtfZmFpbCgpIHRvIG1h
a2UgRWNsYWlyDQogaGFwcHkNCiAtIEluaXRpYWwgc3RhY2sgZ3VhcmQgdmFsdWUgaXMgcmFuZG9t
DQogLSBBZGRlZCBMQ0cgdG8gZ2VuZXJhdGUgc3RhY2sgZ3VhcmQgdmFsdWUgYXQgZWFybHkgYm9v
dCBzdGFnZXMNCiAtIEFkZGVkIGNvbW1lbnQgdG8gYXNtLWdlbmVyaWMvcmFuZG9tLmggYWJvdXQg
ZGVwZW5kZW5jaWVzDQogLSBFeHRlbmRlZCB0aGUgY29tbWl0IG1lc3NhZ2UNCg0KQ2hhbmdlcyBp
biB2MjoNCiAtIE1vdmVkIGNoYW5nZXMgdG8gRU1CRURERURfRVhUUkFfQ0ZMQUdTIGludG8gc2Vw
YXJhdGUgcGF0Y2gNCiAtIFJlbmFtZWQgc3RhY2tfcHJvdGVjdG9yLmMgdG8gc3RhY2stcHJvdGVj
dG9yLmMNCiAtIFJlbmFtZWQgc3RhY2tfcHJvdGVjdG9yLmggdG8gc3RhY2stcHJvdGVjdG9yLmgN
CiAtIFJlbW92ZWQgI2lmZGVmIENPTkZJR19YODYgaW4gc3RhY2stcHJvdGVjdG9yLmgNCiAtIFVw
ZGF0ZWQgY29tbWVudCBpbiBzdGFjay1wcm90ZWN0b3IuaA0KICAgKGFsc28sIHdlIGNhbid0IGNh
bGwgYm9vdF9zdGFja19jaGtfZ3VhcmRfc2V0dXAoKSBmcm9tIGFzbSBjb2RlIGluDQogICBnZW5l
cmFsIGNhc2UsIGJlY2F1c2UgaXQgY2FsbHMgZ2V0X3JhbmRvbSgpIGFuZCBnZXRfcmFuZG9tKCkg
bWF5DQogICBkZXBlbmQgaW4gcGVyX2NwdSBpbmZyYXN0cnVjdHVyZSwgd2hpY2ggaXMgaW5pdGlh
bGl6ZWQgbGF0ZXIpDQogLSBGaXhlZCBjb2Rpbmcgc3R5bGUNCiAtIE1vdmVkIENPTkZJR19TVEFD
S19QUk9URUNUT1IgaW50byBuZXdseSBhZGRlZCAiQ29tcGlsZXIgb3B0aW9ucyINCiBzdWJtZW51
DQogLSBNYXJrZWQgX19zdGFja19jaGtfZ3VhcmQgYXMgX19yb19hZnRlcl9pbml0DQotLS0NCiB4
ZW4vTWFrZWZpbGUgICAgICAgICAgICAgICAgICAgICAgfCAgNCArKysNCiB4ZW4vY29tbW9uL0tj
b25maWcgICAgICAgICAgICAgICAgfCAxNSArKysrKysrKysrDQogeGVuL2NvbW1vbi9NYWtlZmls
ZSAgICAgICAgICAgICAgIHwgIDEgKw0KIHhlbi9jb21tb24vc3RhY2stcHJvdGVjdG9yLmMgICAg
ICB8IDQ3ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4vaW5jbHVkZS9hc20t
Z2VuZXJpYy9yYW5kb20uaCAgfCAgNSArKysrDQogeGVuL2luY2x1ZGUveGVuL3N0YWNrLXByb3Rl
Y3Rvci5oIHwgMzAgKysrKysrKysrKysrKysrKysrKysNCiA2IGZpbGVzIGNoYW5nZWQsIDEwMiBp
bnNlcnRpb25zKCspDQogY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9jb21tb24vc3RhY2stcHJvdGVj
dG9yLmMNCiBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUveGVuL3N0YWNrLXByb3RlY3Rv
ci5oDQoNCmRpZmYgLS1naXQgYS94ZW4vTWFrZWZpbGUgYi94ZW4vTWFrZWZpbGUNCmluZGV4IDM0
ZWQ4YzBmYzcuLjBkZTAxMDFmZDAgMTAwNjQ0DQotLS0gYS94ZW4vTWFrZWZpbGUNCisrKyBiL3hl
bi9NYWtlZmlsZQ0KQEAgLTQzMiw3ICs0MzIsMTEgQEAgZWxzZQ0KIENGTEFHU19VQlNBTiA6PQ0K
IGVuZGlmDQogDQoraWZlcSAoJChDT05GSUdfU1RBQ0tfUFJPVEVDVE9SKSx5KQ0KK0NGTEFHUyAr
PSAtZnN0YWNrLXByb3RlY3Rvcg0KK2Vsc2UNCiBDRkxBR1MgKz0gLWZuby1zdGFjay1wcm90ZWN0
b3INCitlbmRpZg0KIA0KIGlmZXEgKCQoQ09ORklHX0xUTykseSkNCiBDRkxBR1MgKz0gLWZsdG8N
CmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL0tjb25maWcgYi94ZW4vY29tbW9uL0tjb25maWcNCmlu
ZGV4IDkwMjY4ZDkyNDkuLjU2NzYzMzlhNjYgMTAwNjQ0DQotLS0gYS94ZW4vY29tbW9uL0tjb25m
aWcNCisrKyBiL3hlbi9jb21tb24vS2NvbmZpZw0KQEAgLTg2LDYgKzg2LDkgQEAgY29uZmlnIEhB
U19VQlNBTg0KIGNvbmZpZyBIQVNfVk1BUA0KIAlib29sDQogDQorY29uZmlnIEhBU19TVEFDS19Q
Uk9URUNUT1INCisJYm9vbA0KKw0KIGNvbmZpZyBNRU1fQUNDRVNTX0FMV0FZU19PTg0KIAlib29s
DQogDQpAQCAtMjEzLDYgKzIxNiwxOCBAQCBjb25maWcgU1BFQ1VMQVRJVkVfSEFSREVOX0xPQ0sN
CiANCiBlbmRtZW51DQogDQorbWVudSAiQ29tcGlsZXIgb3B0aW9ucyINCisNCitjb25maWcgU1RB
Q0tfUFJPVEVDVE9SDQorCWJvb2wgIlN0YWNrIHByb3RlY3RvciINCisJZGVwZW5kcyBvbiBIQVNf
U1RBQ0tfUFJPVEVDVE9SDQorCWhlbHANCisJICBFbmFibGUgdGhlIFN0YWNrIFByb3RlY3RvciBj
b21waWxlciBoYXJkZW5pbmcgb3B0aW9uLiBUaGlzIGluc2VydHMgYQ0KKwkgIGNhbmFyeSB2YWx1
ZSBpbiB0aGUgc3RhY2sgZnJhbWUgb2YgZnVuY3Rpb25zLCBhbmQgcGVyZm9ybXMgYW4gaW50ZWdy
aXR5DQorCSAgY2hlY2sgb24gZXhpdC4NCisNCitlbmRtZW51DQorDQogY29uZmlnIERJVF9ERUZB
VUxUDQogCWJvb2wgIkRhdGEgSW5kZXBlbmRlbnQgVGltaW5nIGRlZmF1bHQiDQogCWRlcGVuZHMg
b24gSEFTX0RJVA0KZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vTWFrZWZpbGUgYi94ZW4vY29tbW9u
L01ha2VmaWxlDQppbmRleCBiMjc5YjA5YmZiLi5jZWI1YjJmMzJiIDEwMDY0NA0KLS0tIGEveGVu
L2NvbW1vbi9NYWtlZmlsZQ0KKysrIGIveGVuL2NvbW1vbi9NYWtlZmlsZQ0KQEAgLTQ1LDYgKzQ1
LDcgQEAgb2JqLXkgKz0gc2h1dGRvd24ubw0KIG9iai15ICs9IHNvZnRpcnEubw0KIG9iai15ICs9
IHNtcC5vDQogb2JqLXkgKz0gc3BpbmxvY2subw0KK29iai0kKENPTkZJR19TVEFDS19QUk9URUNU
T1IpICs9IHN0YWNrLXByb3RlY3Rvci5vDQogb2JqLXkgKz0gc3RvcF9tYWNoaW5lLm8NCiBvYmot
eSArPSBzeW1ib2xzLm8NCiBvYmoteSArPSB0YXNrbGV0Lm8NCmRpZmYgLS1naXQgYS94ZW4vY29t
bW9uL3N0YWNrLXByb3RlY3Rvci5jIGIveGVuL2NvbW1vbi9zdGFjay1wcm90ZWN0b3IuYw0KbmV3
IGZpbGUgbW9kZSAxMDA2NDQNCmluZGV4IDAwMDAwMDAwMDAuLjkyMjUxMTU1NWYNCi0tLSAvZGV2
L251bGwNCisrKyBiL3hlbi9jb21tb24vc3RhY2stcHJvdGVjdG9yLmMNCkBAIC0wLDAgKzEsNDcg
QEANCisvLyBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMC1vbmx5DQorI2luY2x1ZGUg
PHhlbi9pbml0Lmg+DQorI2luY2x1ZGUgPHhlbi9saWIuaD4NCisjaW5jbHVkZSA8eGVuL3JhbmRv
bS5oPg0KKyNpbmNsdWRlIDx4ZW4vdGltZS5oPg0KKw0KKy8qDQorICogSW5pdGlhbCB2YWx1ZSBp
cyBjaG9zZW4gYnkgYSBmYWlyIGRpY2Ugcm9sbC4NCisgKiBJdCB3aWxsIGJlIHVwZGF0ZWQgZHVy
aW5nIGJvb3QgcHJvY2Vzcy4NCisgKi8NCisjaWYgQklUU19QRVJfTE9ORyA9PSAzMg0KK3Vuc2ln
bmVkIGxvbmcgX19yb19hZnRlcl9pbml0IF9fc3RhY2tfY2hrX2d1YXJkID0gMHhkZDJjYzkyN1VM
Ow0KKyNlbHNlDQordW5zaWduZWQgbG9uZyBfX3JvX2FmdGVyX2luaXQgX19zdGFja19jaGtfZ3Vh
cmQgPSAweDJkODUzNjA1YTRkOWEwOWNVTDsNCisjZW5kaWYNCisNCisvKiBUaGlzIGZ1bmN0aW9u
IHNob3VsZCBiZSBjYWxsZWQgZnJvbSBBU00gb25seSAqLw0KK3ZvaWQgX19pbml0IGFzbWxpbmth
Z2UgYm9vdF9zdGFja19jaGtfZ3VhcmRfc2V0dXBfZWFybHkodm9pZCkNCit7DQorICAgIC8qDQor
ICAgICAqIExpbmVhciBjb25ncnVlbnQgZ2VuZXJhdG9yIChYX24rMSA9IFhfbiAqIGEgKyBjKS4N
CisgICAgICoNCisgICAgICogQ29uc3RhbnQgaXMgdGFrZW4gZnJvbSAiVGFibGVzIE9mIExpbmVh
ciBDb25ncnVlbnRpYWwNCisgICAgICogR2VuZXJhdG9ycyBPZiBEaWZmZXJlbnQgU2l6ZXMgQW5k
IEdvb2QgTGF0dGljZSBTdHJ1Y3R1cmUiIGJ5DQorICAgICAqIFBpZXJyZSBM4oCZRWN1eWVyLg0K
KyAgICAgKi8NCisjaWYgQklUU19QRVJfTE9ORyA9PSAzMg0KKyAgICBjb25zdCB1bnNpZ25lZCBs
b25nIGEgPSAyODkxMzM2NDUzVUw7DQorI2Vsc2UNCisgICAgY29uc3QgdW5zaWduZWQgbG9uZyBh
ID0gMjg2MjkzMzU1NTc3Nzk0MTc1N1VMOw0KKyNlbmRpZg0KKyAgICBjb25zdCB1bnNpZ25lZCBs
b25nIGMgPSAxOw0KKw0KKyAgICB1bnNpZ25lZCBsb25nIGN5Y2xlcyA9IGdldF9jeWNsZXMoKTsN
CisNCisgICAgLyogVXNlIHRoZSBpbml0aWFsIHZhbHVlIGlmIHdlIGNhbid0IGdlbmVyYXRlIHJh
bmRvbSBvbmUgKi8NCisgICAgaWYgKCAhY3ljbGVzICkNCisJICAgIHJldHVybjsNCisNCisgICAg
X19zdGFja19jaGtfZ3VhcmQgPSBjeWNsZXMgKiBhICsgYzsNCit9DQorDQordm9pZCBhc21saW5r
YWdlIF9fc3RhY2tfY2hrX2ZhaWwodm9pZCkNCit7DQorICAgIHBhbmljKCJTdGFjayBQcm90ZWN0
b3IgaW50ZWdyaXR5IHZpb2xhdGlvbiBpZGVudGlmaWVkIGluICVwc1xuIiwNCisJICBfX2J1aWx0
aW5fcmV0dXJuX2FkZHJlc3MoMCkpOw0KK30NCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9hc20t
Z2VuZXJpYy9yYW5kb20uaCBiL3hlbi9pbmNsdWRlL2FzbS1nZW5lcmljL3JhbmRvbS5oDQppbmRl
eCBkMGQzNWRkMjE3Li43ZjZkODc5MGM0IDEwMDY0NA0KLS0tIGEveGVuL2luY2x1ZGUvYXNtLWdl
bmVyaWMvcmFuZG9tLmgNCisrKyBiL3hlbi9pbmNsdWRlL2FzbS1nZW5lcmljL3JhbmRvbS5oDQpA
QCAtMiw2ICsyLDExIEBADQogI2lmbmRlZiBfX0FTTV9HRU5FUklDX1JBTkRPTV9IX18NCiAjZGVm
aW5lIF9fQVNNX0dFTkVSSUNfUkFORE9NX0hfXw0KIA0KKy8qDQorICogV2hlbiBpbXBsZW1lbnRp
bmcgYXJjaF9nZXRfcmFuZG9tKCksIHBsZWFzZSBtYWtlIHN1cmUgdGhhdA0KKyAqIGl0IGNhbiBw
cm92aWRlIHJhbmRvbSBkYXRhIGJlZm9yZSBzdGFjayBwcm90ZWN0b3IgaXMgaW5pdGlhbGl6ZWQN
CisgKiAoaS5lLiBiZWZvcmUgYm9vdF9zdGFja19jaGtfZ3VhcmRfc2V0dXAoKSBpcyBjYWxsZWQp
Lg0KKyAqLw0KIHN0YXRpYyBpbmxpbmUgdW5zaWduZWQgaW50IGFyY2hfZ2V0X3JhbmRvbSh2b2lk
KQ0KIHsNCiAgICAgcmV0dXJuIDA7DQpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVuL3N0YWNr
LXByb3RlY3Rvci5oIGIveGVuL2luY2x1ZGUveGVuL3N0YWNrLXByb3RlY3Rvci5oDQpuZXcgZmls
ZSBtb2RlIDEwMDY0NA0KaW5kZXggMDAwMDAwMDAwMC4uYmQzMjRkOTAwMw0KLS0tIC9kZXYvbnVs
bA0KKysrIGIveGVuL2luY2x1ZGUveGVuL3N0YWNrLXByb3RlY3Rvci5oDQpAQCAtMCwwICsxLDMw
IEBADQorLyogU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6IEdQTC0yLjAtb25seSAqLw0KKw0KKyNp
Zm5kZWYgWEVOX19TVEFDS19QUk9URUNUT1JfSA0KKyNkZWZpbmUgWEVOX19TVEFDS19QUk9URUNU
T1JfSA0KKw0KKyNpZmRlZiBDT05GSUdfU1RBQ0tfUFJPVEVDVE9SDQorDQorI2luY2x1ZGUgPHhl
bi9yYW5kb20uaD4NCisNCitleHRlcm4gdW5zaWduZWQgbG9uZyBfX3N0YWNrX2Noa19ndWFyZDsN
CisNCisvKg0KKyAqIFRoaXMgZnVuY3Rpb24gc2hvdWxkIGJlIGFsd2F5cyBpbmxpbmVkLiBBbHNv
IGl0IHNob3VsZCBiZSBjYWxsZWQNCisgKiBmcm9tIGEgZnVuY3Rpb24gdGhhdCBuZXZlciByZXR1
cm5zIG9yIGEgZnVuY3Rpb24gdGhhdCBoYXMNCisgKiBzdGFjay1wcm90ZWN0b3IgZGlzYWJsZWQu
DQorICovDQorc3RhdGljIGFsd2F5c19pbmxpbmUgdm9pZCBib290X3N0YWNrX2Noa19ndWFyZF9z
ZXR1cCh2b2lkKQ0KK3sNCisgICAgX19zdGFja19jaGtfZ3VhcmQgPSBnZXRfcmFuZG9tKCk7DQor
ICAgIGlmIChCSVRTX1BFUl9MT05HID09IDY0KQ0KKyAgICAgICAgX19zdGFja19jaGtfZ3VhcmQg
fD0gKCh1bnNpZ25lZCBsb25nKWdldF9yYW5kb20oKSkgPDwgMzI7DQorfQ0KKw0KKyNlbHNlDQor
DQorc3RhdGljIGlubGluZSB2b2lkIGJvb3Rfc3RhY2tfY2hrX2d1YXJkX3NldHVwKHZvaWQpIHt9
DQorDQorI2VuZGlmIC8qIENPTkZJR19TVEFDS19QUk9URUNUT1IgICovDQorDQorI2VuZGlmIC8q
IFhFTl9fU1RBQ0tfUFJPVEVDVE9SX0ggKi8NCi0tIA0KMi40Ny4xDQo=


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 02:04:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 02:04:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853576.1267003 (Exim 4.92)
	(envelope-from )
	id 1tLC5f-00052i-Dt; Wed, 11 Dec 2024 02:04:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853576.1267003; Wed, 11 Dec 2024 02:04:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLC5f-00052b-Ab; Wed, 11 Dec 2024 02:04:39 +0000
Received: by outflank-mailman (input) for mailman id 853576;
 Wed, 11 Dec 2024 02:04: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 1tLC5e-0004a4-9E
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 02:04:38 +0000
Received: from EUR02-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur02on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2607::60a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 45c0db06-b764-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 03:04:36 +0100 (CET)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by AS8PR03MB9365.eurprd03.prod.outlook.com
 (2603:10a6:20b:57d::20) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Wed, 11 Dec
 2024 02:04:32 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%7]) with mapi id 15.20.8251.008; Wed, 11 Dec 2024
 02:04: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: 45c0db06-b764-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ge1XlQbgH1UdvXJE/zBdwMM2tr9pint8/IVqDbnY23Vuc2xRCSaSH/mcrW1GSGysffF99uWSk4PDlRnXeKD6lVFgbuRCyNzrnd+xmCtAvb+TSmHgjz4r6JTZqPVtNjOt0+7mHAHNKCuti40MUM2phKD9Lrhf4atS6ggaqMIIAZX6QMa7gTPcPJ0eKQR3cMf7UVZQTnxEhGj/IrGPkRr7ti87mVehX+8vLpy54caluz2bLNzn49skrcQM9JD1egXOdl9/xmrX1iJzJfMDaryFugzAuF7xyPEitUqEVOMB+PaLjPX5DOiEn6jNxEz78/38sMfZiZgFf/iYniGSEHcBqw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7IPKT9OsPoDBg5bm90YN85uCTHQcge+IDT3Vd6o2ITA=;
 b=kfdsdpr1YmBYed+3+BE0uKapBXpbhffr3W5CNd6dCGqrreqdWdxrrFWkDpRf1DWv+2lSWhR5rjRtu9m/tAEfCJ5qj9spQ4o6P3vGC5HlwJEtqji3vij/XkZuDkfpeynhNBx4BYlQUy0BIM+kg8TJQPFOAsJmaOQ4uW0ukRI2B0liQWyGZtdgKpaDzdknKAb6r8VBQaO6K5EBLD4FG8p5880w1n9+vO5yghBrVTOANrN91H0y8Moyx8LLrOrcGg4L190522IkmNccS+ItTYKUysXcnwstYiNUe8euND81/6ja76Pose3sTR7AfN0c7ojDnBs70/sCzqkXacTW14YjLw==
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=7IPKT9OsPoDBg5bm90YN85uCTHQcge+IDT3Vd6o2ITA=;
 b=Md2K9cE77jlIxbt/OCJj1y8uelR4NjHUlqevPKRQ+vu2sNlDKg09O/RH93HYfhIW8pXHQ8if3cvKYui2w4SxuuzHZZ0MlHEXUGG1PWLhgGs9eKh10YV+SoRtOc6qPcJREQoiwrlE9y2ZLQ94Iu6fdaHOga10DSU6BU+Q2TdCR+4BOLfj1U1uad/a5uvk80fewSfZCOfSWJQUNDmMZ6ztLcjlSUR6HSRoNWzr+PfHBHmE/6dOnID516fvbvxxAVlGPt0EQox5aEMssaGMbRleWLRpOzft0X1wD98+EeMWW3dmQ36Lcwc4jjbwYWnBl8iq34ccDmD7iA9lxqnP0vIoFQ==
From: Volodymyr Babchuk 
To: "xen-devel@lists.xenproject.org" 
CC: Volodymyr Babchuk , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Michal Orzel , Volodymyr
 Babchuk 
Subject: [PATCH v3 3/3] xen: arm: enable stack protector feature
Thread-Topic: [PATCH v3 3/3] xen: arm: enable stack protector feature
Thread-Index: AQHbS3EEEJvy+ytb5UyNE3P+n1UzAQ==
Date: Wed, 11 Dec 2024 02:04:30 +0000
Message-ID: <20241211020424.401614-4-volodymyr_babchuk@epam.com>
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
In-Reply-To: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: git-send-email 2.47.1
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: GV1PR03MB10456:EE_|AS8PR03MB9365:EE_
x-ms-office365-filtering-correlation-id: 6e5c4183-8777-428b-92d9-08dd19882762
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?hVPl6/Ig6716rtq6aoGkm0navVKZuwGYQAQfGQDQ5qvOEGDaEHdMqHJgeF?=
 =?iso-8859-1?Q?GPwI8OLIkbc+jkWs99X2LjPtj9KOnKhmDReD8mexFAWRMuwDbG9jeGYS+0?=
 =?iso-8859-1?Q?cJA78ULyDF40yh9Dcsv0cpb41ee/S26kbdzDr5BpBC3c8hmWFKS94Hg/SX?=
 =?iso-8859-1?Q?CB/pMjexRwzfWwcCUgET/8rX+LUPnYFjNTNdBDtTb0pWjYm0dlZ/SWBePL?=
 =?iso-8859-1?Q?n0xq+kpmxOjVcBMqyfDnePdccZ3gHJVAY/HRP1LmL8ctHUU9geD1xU8df7?=
 =?iso-8859-1?Q?GejT7VZD3FherS5mvtsTUentO+RuP/aORLyVlQwYlsEH0bkxOFAImXJL+a?=
 =?iso-8859-1?Q?koEkHml2Nnm+9Zx1EoIno50k+GNO/91Nh4h5n7ri2cdIKBJSnmWZOzPHt8?=
 =?iso-8859-1?Q?cJx+FO5MO6Pny89Jvml5cK8hvUcL++3XuyNXAxCWQqg8eyyJvX/qawRTET?=
 =?iso-8859-1?Q?my66BXEV00n0mDv5YyPk5HAS4FxxBXzWJ2btBPL3zJyEXhGh8T9GxSVI5e?=
 =?iso-8859-1?Q?b0dnnkyLYrvTlEw0Hl7+WYOyNHukMvJaHfhZQ6R2huvzelWFEzZRMAiQag?=
 =?iso-8859-1?Q?TNB4JWNn2bj2oE1/MBXOJI84RV+lqsFhajtmPvrRnonUITPY0sI2bpnDNX?=
 =?iso-8859-1?Q?npXzGPryn9POE/xaOBNa+9XGyDnxcSDv5GDJ69jJ0DYGjguNDHc5J4DFcc?=
 =?iso-8859-1?Q?o+4Rau2wDWauLH4MokpkIm0nI9vdbuCOUfb8HQoZhp2LXwONm+1GusTnKa?=
 =?iso-8859-1?Q?1yj82dhoDojS/sJRM5P68+MNZEhOPVaEDv6dyP4rL2/n8yHKPCtmecvCTF?=
 =?iso-8859-1?Q?5jmW1eAOjIlLCcKvzYYqZWJpv8Vz9ZGWfPiuB381N15lDgf39Z7zuLGlXg?=
 =?iso-8859-1?Q?+FG8R4rz7kE+kS1NT1uvYn177uxMRQfwVKVoF7mbJbV6D59o+E7xXX9HKa?=
 =?iso-8859-1?Q?VH+41C4hatC8ijX1bW/0W936H9UmhvzPHswOUddDRnZIvL/3aGQCro9bYb?=
 =?iso-8859-1?Q?86kSI2sC58dKtxay67zGN+pj1HqsDellkizvjlaVvXgoT0BiBrWtJZc/Tn?=
 =?iso-8859-1?Q?kZesuD0ANdGWmj0tjszUWJyfn7O8Rfob1mTKmk0+PWCvDvSR522K7+2Lhg?=
 =?iso-8859-1?Q?IYYXH9XqAZ/4uIjZd9f0ukTwUZxbf2kLSJSqkmCvOchzq4rjVlZVrAmj6S?=
 =?iso-8859-1?Q?nH+sAfjwHVhyJSFqhFiXIyyqLX1Dpf8lcyRVpkTSugA+lT7WYbZcT9xQtW?=
 =?iso-8859-1?Q?eyFX+eAo5zrJ5J2FKxqQGVrf2yIKRaBWo3KRTaqYaxoLX19pcaS+seFaq1?=
 =?iso-8859-1?Q?euQdQQMpK4YeUy7bMFQYk1wyx70OaaKIhrEY4tmqFxcKZF7ipPWn6xJO76?=
 =?iso-8859-1?Q?qWr46nsWzWfMcV1xyT6zeGIxcAjB37U/JfEJ+mkXNaVydVmLWU/kEMOOZT?=
 =?iso-8859-1?Q?ZQ3WpXEjXtduOGbkYdu0DDUSNuE/YCn5rN5APA=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?pD0sBpJOYKmmehoupz++PSwernoJYdJl7f/12ljuTNjBL+cCWLEbiaOyKp?=
 =?iso-8859-1?Q?fX06RlqffU1/UaP68ZmOTRB4Agc1ch0p05s5tQl6xe70h8z6/7CJhPxyQu?=
 =?iso-8859-1?Q?hu3duBBbcSVLPklkSIZu/tc3O03RFQwldGryTUc+rcMUbEAkMQ5yKa3twr?=
 =?iso-8859-1?Q?QJoLg7HhH8gGM4+S4ZyDfJH+iQSN3N7XCTWFBPKZqxVKTvQBJvtEogFbfU?=
 =?iso-8859-1?Q?LXGJ56YeqgBTy32d4r+UmMR3mhEyMoqA9a+1lgm0Rr5ShNij1ZbnAUhs+F?=
 =?iso-8859-1?Q?RYyBYuLdHMgeBSC5h3DNmD0Kg5ArgwrmwlV6gCKXaN7+isJTDlKfh2l6B+?=
 =?iso-8859-1?Q?x9npubACfSUhveIil+IkOfbVN5umiMzX6riSFER6Gv5xMzntFBObOoU/SX?=
 =?iso-8859-1?Q?An8WdFiIoLINJJ+A4YOMUjazPLqLLpwwNVKFoxn2o1k8KbadQjdEGUuEQ7?=
 =?iso-8859-1?Q?sHe8RQ42/O50vR/bMuLgUIpF4sae6ctA47VgflV55or4/4fTo1Fs0E+oDw?=
 =?iso-8859-1?Q?dKnwnE9RTXbwSD3a2WBDWv5nAedQKpiRnJ2MTujH1LG3qw4KKx5CBW57Ga?=
 =?iso-8859-1?Q?hHTWE244AM0dGByes6WWbqwrcPlx7KEUCphNWkIWlyZnPohnnYHV44DjEj?=
 =?iso-8859-1?Q?jJ06UOZum0iJSEiCMRIHZfz0rlEyEWVzjVQK/Ws40PXYjpifCLXBr4X1+X?=
 =?iso-8859-1?Q?jp2N1UtS89JK+3kfcQk31KTXOsmjXyOvQgEV/wvz56f9fM9y+JB5gzogOy?=
 =?iso-8859-1?Q?zzmBChNnfUh1DsQ/0r02u659H6/Jnmm2SS+qUxcbKUp83zhpjIq9jK0Puz?=
 =?iso-8859-1?Q?aRXAnG5p/urHoSqtl3cF/Ai+z6s4FP2YdEiJq/HnlKyvnY3LLt16/v/jOK?=
 =?iso-8859-1?Q?JpklWDpqF3uqlNm9gRTPglx/TQc94r73z7frM26fHxqomk4Chj0ESzpfDT?=
 =?iso-8859-1?Q?/mbloAXkKTV2V9biRHNxpZysk72ZVyLJjFQj7aAML7EPuQrpCu7nVdZ7wU?=
 =?iso-8859-1?Q?Z0IThgRIMWckp63z9BTkq3/dr5txWbldybmo+pd4/UGEes9rPjCmt0mIrn?=
 =?iso-8859-1?Q?s++oFlwZIAXJW2QPQm/rMR/FS6VkVlNJpAX5Pn8OpJ7XMAOjLcMMWLicVj?=
 =?iso-8859-1?Q?8WOIhv85orc2eAT4joa3//8ORPPmCA9h7O9xYP+Ct4ZLvBEIFJKfQjIj9w?=
 =?iso-8859-1?Q?kCbKZYHECQ/wTAH8UuJp5KZt/D80bz/Mf2PQrKfv/FjSjZwH8P0u1NX561?=
 =?iso-8859-1?Q?1CZP5WBTtgFVChVWpedM6Co/jUK3M5Bqs6u12yk0x3QcTLW+OwktJzo3H0?=
 =?iso-8859-1?Q?QEQDGYr04MGs9R4JAf7Y1wntO9GJ54gmgPttKQL4a3TD0W34Q7sXIpSpst?=
 =?iso-8859-1?Q?sLhGenk1BNKW/X1KxJlGlUSF9uN7OlcOEma4q8cs+uUiP1sl/Xq0whhu/S?=
 =?iso-8859-1?Q?TxmrGqFaRTScndeTVWSCAI4GkrkMf3jRLpPa8gBu/qvm10iVn5ErQgcWYw?=
 =?iso-8859-1?Q?K9kLYrCf5CJHrs6XED0ASphsFNSGa0szWyrpnCst4/h2V/cE1o35c36L9Y?=
 =?iso-8859-1?Q?rvC6Xv9Uzx607aiukzwQALs+H6nnfSaU7E6DXCtTbp7yk8kTxqbz1+IvdF?=
 =?iso-8859-1?Q?G8iipinlU8vMiNvrWeM+NDvheWs2gikKki4GK9E8ueN/hIX9u8NM7VCw?=
 =?iso-8859-1?Q?=3D=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: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6e5c4183-8777-428b-92d9-08dd19882762
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2024 02:04:30.8888
 (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: ABwBQlfrdAtLHOy924ucylAJfEmT8zySnjxFlbC8bJt3K7r+4+xW0i5gchVFJoI04RqNInswVjiYE0mHdZ1PSH6gRGOIrfa2w0LwCkX89Es=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9365

Enable previously added CONFIG_STACK_PROTECTOR feature for ARM
platform. We initialize stack protector in two stages: from head.S
using boot_stack_chk_guard_setup_early() function and from start_xen()
using  boot_stack_chk_guard_setup(). This ensures that all C code from
the very beginning can use stack protector.

We call boot_stack_chk_guard_setup() only after time subsystem was
initialized to make sure that generic random number generator will
be working properly.

Signed-off-by: Volodymyr Babchuk 

---

In v3:
 - Call boot_stack_chk_guard_setup_early from head.S to ensure
   that stack is protected from early boot stages
 - Call boot_stack_chk_guard_setup() later, when time subsystem is
   sufficiently initialized to provide values for the random number
   generator.
In v2:
 - Reordered Kconfig entry
---
 xen/arch/arm/Kconfig      | 1 +
 xen/arch/arm/arm64/head.S | 3 +++
 xen/arch/arm/setup.c      | 3 +++
 3 files changed, 7 insertions(+)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 23bbc91aad..a24c88c327 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -16,6 +16,7 @@ config ARM
 	select HAS_ALTERNATIVE if HAS_VMAP
 	select HAS_DEVICE_TREE
 	select HAS_PASSTHROUGH
+	select HAS_STACK_PROTECTOR
 	select HAS_UBSAN
 	select IOMMU_FORCE_PT_SHARE
=20
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 72c7b24498..535969e9c0 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -250,6 +250,9 @@ real_start_efi:
 #endif
         PRINT("- Boot CPU booting -\r\n")
=20
+#ifdef CONFIG_STACK_PROTECTOR
+        bl    boot_stack_chk_guard_setup_early
+#endif
         bl    check_cpu_mode
         bl    cpu_init
=20
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 2e27af4560..3587baab21 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -359,6 +360,8 @@ void asmlinkage __init start_xen(unsigned long fdt_padd=
r)
=20
     preinit_xen_time();
=20
+    boot_stack_chk_guard_setup();
+
     gic_preinit();
=20
     uart_init();
--=20
2.47.1


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 02:31:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 02:31:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853627.1267023 (Exim 4.92)
	(envelope-from )
	id 1tLCVl-0006lG-Tz; Wed, 11 Dec 2024 02:31:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853627.1267023; Wed, 11 Dec 2024 02:31: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 1tLCVl-0006l9-RA; Wed, 11 Dec 2024 02:31:37 +0000
Received: by outflank-mailman (input) for mailman id 853627;
 Wed, 11 Dec 2024 02:31: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 1tLCVl-0006jj-5f
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 02:31:37 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0a69317b-b768-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 03:31:35 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 3EA1CA41D8F;
 Wed, 11 Dec 2024 02:29:43 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88D37C4CED6;
 Wed, 11 Dec 2024 02:31: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: 0a69317b-b768-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org;
	s=korg; t=1733884294;
	bh=sLhMhQmowIvyDOZaQSUrMhLsPhwddTfrbVNYlnBcDH4=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=LFzIAbjeVxr5ODQPOZZgTBsZ9VPv2qRYsjzufXTmy2VjrkolY7we/T3El5L3bI4tv
	 ZwBBxonZW6D/7UDB8GmpeizZX1si0/2Sixxb/Y/AoqhAb098fytUnRjDBW3AgAqPQ/
	 xwSsay0w7F9KyDeJ3A+YhVB7Vf6NOdXZjnEFoERY=
Date: Tue, 10 Dec 2024 18:31:30 -0800
From: Andrew Morton 
To: Jakub Kicinski 
Cc: Easwar Hariharan , Jeff Johnson
 , Pablo Neira Ayuso ,
 Jozsef Kadlecsik , "David S. Miller"
 , Eric Dumazet , Paolo Abeni
 , Simon Horman , Julia Lawall
 , Nicolas Palix , Daniel Mack
 , Haojian Zhuang , Robert
 Jarzmik , Russell King ,
 Heiko Carstens , Vasily Gorbik ,
 Alexander Gordeev , Christian Borntraeger
 , Sven Schnelle , Ofir
 Bitton , Oded Gabbay , Lucas De
 Marchi , Thomas =?ISO-8859-1?Q?Hellstr=F6m?=
 , Rodrigo Vivi ,
 Maarten Lankhorst , Maxime Ripard
 , Thomas Zimmermann , David Airlie
 , Simona Vetter , Jeroen de Borst
 , Praveen Kaligineedi ,
 Shailend Chand , Andrew Lunn ,
 James Smart , Dick Kennedy
 , "James E.J. Bottomley"
 , "Martin K. Petersen"
 , Roger Pau =?ISO-8859-1?Q?Monn=E9?=
 , Jens Axboe , Kalle Valo
 , Jeff Johnson , Catalin Marinas
 , Jack Wang , Marcel
 Holtmann , Johan Hedberg ,
 Luiz Augusto von Dentz , Greg Kroah-Hartman
 , Florian Fainelli
 , Ray Jui , Scott Branden
 , Broadcom internal kernel review list
 , Xiubo Li , Ilya
 Dryomov , Josh Poimboeuf , Jiri
 Kosina , Miroslav Benes , Petr Mladek
 , Joe Lawrence , Jaroslav Kysela
 , Takashi Iwai , Louis Peens
 , Michael Ellerman , Nicholas
 Piggin , Christophe Leroy ,
 Naveen N Rao , Madhavan Srinivasan
 , netfilter-devel@vger.kernel.org,
 coreteam@netfilter.org, netdev@vger.kernel.org,
 linux-kernel@vger.kernel.org, cocci@inria.fr,
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org,
 ath11k@lists.infradead.org, linux-mm@kvack.org,
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev,
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org,
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org,
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, Anna-Maria Behnsen
 
Subject: Re: [PATCH v3 00/19] Converge on using secs_to_jiffies()
Message-Id: <20241210183130.81111d05148c41278a299aad@linux-foundation.org>
In-Reply-To: <20241210173548.5d32efe0@kernel.org>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
	<315e9178-5b10-4de0-bdcf-7243e0e355bb@oss.qualcomm.com>
	<20241210153604.cf99699f264f12740ffce5c7@linux-foundation.org>
	<20241210173548.5d32efe0@kernel.org>
X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 10 Dec 2024 17:35:48 -0800 Jakub Kicinski  wrote:

> On Tue, 10 Dec 2024 15:36:04 -0800 Andrew Morton wrote:
> > > I have the same question as before: How do you expect these to land?
> > > Do you now have a maintainer who will take all of them?
> > > Or do you want individual maintainers to take the ones applicable to them?  
> > 
> > I'll just grab everything and see if anyone complains ;)
> 
> I may, if this leads to a conflict :(

Very unlikely, and any such conflict will be trivial.

> Easwar, please break this up per subsystem.

The series is already one-patch-per-changed-file.


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 02:41:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 02:41:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853639.1267033 (Exim 4.92)
	(envelope-from )
	id 1tLCfS-0001lv-QC; Wed, 11 Dec 2024 02:41:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853639.1267033; Wed, 11 Dec 2024 02:41: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 1tLCfS-0001lo-Mw; Wed, 11 Dec 2024 02:41:38 +0000
Received: by outflank-mailman (input) for mailman id 853639;
 Wed, 11 Dec 2024 02:41: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 1tLCfR-0001li-90
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 02:41:37 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7021d693-b769-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 03:41:35 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 6B6E7A41D8D;
 Wed, 11 Dec 2024 02:39:43 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2728C4CED6;
 Wed, 11 Dec 2024 02:41:30 +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: 7021d693-b769-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1733884894;
	bh=00K8MMiI4zi+Ut/RW/eta+vMQomu0Giei3szpffQQOQ=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=Da4qREKhLmCm8yz23HYMcnYhvUPIhwEMSq3e2xy5eHqmd+lk3xFCqCL8gMV2d1qZM
	 OX/nYhIL+8FVEAH5j2G8jreOCn4t5aDyk2A67ZSa2Mkyc9Pdlwt9HWePiQrPKYupQD
	 HqnoKIQmX31F4DdpsyABbQ15F6Ui5dY/VyDtBpBstL8y1jhriA+kdAfBMPTAXFbWnS
	 63C0vjQwg5Lmz+BJiiuG775DcGC4erU4pOGbFjbFCfGrajmvqQlFUpggTSjU+aLgVs
	 HKqzofl4MBLxzwaLLU/QjjetYigVK4WMW1awwyb5uskvci+1KuE5L5PLpPOgzSWNQz
	 YP2aWNyh8AjbA==
Date: Tue, 10 Dec 2024 18:41:29 -0800
From: Jakub Kicinski 
To: Andrew Morton 
Cc: Easwar Hariharan , Jeff Johnson
 , Pablo Neira Ayuso ,
 Jozsef Kadlecsik , "David S. Miller"
 , Eric Dumazet , Paolo Abeni
 , Simon Horman , Julia Lawall
 , Nicolas Palix , Daniel Mack
 , Haojian Zhuang , Robert
 Jarzmik , Russell King ,
 Heiko Carstens , Vasily Gorbik ,
 Alexander Gordeev , Christian Borntraeger
 , Sven Schnelle , Ofir
 Bitton , Oded Gabbay , Lucas De
 Marchi , Thomas =?UTF-8?B?SGVsbHN0csO2bQ==?=
 , Rodrigo Vivi ,
 Maarten Lankhorst , Maxime Ripard
 , Thomas Zimmermann , David Airlie
 , Simona Vetter , Jeroen de Borst
 , Praveen Kaligineedi ,
 Shailend Chand , Andrew Lunn ,
 James Smart , Dick Kennedy
 , "James E.J. Bottomley"
 , "Martin K. Petersen"
 , Roger Pau =?UTF-8?B?TW9ubsOp?=
 , Jens Axboe , Kalle Valo
 , Jeff Johnson , Catalin Marinas
 , Jack Wang , Marcel
 Holtmann , Johan Hedberg ,
 Luiz Augusto von Dentz , Greg Kroah-Hartman
 , Florian Fainelli
 , Ray Jui , Scott Branden
 , Broadcom internal kernel review list
 , Xiubo Li , Ilya
 Dryomov , Josh Poimboeuf , Jiri
 Kosina , Miroslav Benes , Petr Mladek
 , Joe Lawrence , Jaroslav Kysela
 , Takashi Iwai , Louis Peens
 , Michael Ellerman , Nicholas
 Piggin , Christophe Leroy ,
 Naveen N Rao , Madhavan Srinivasan
 , netfilter-devel@vger.kernel.org,
 coreteam@netfilter.org, netdev@vger.kernel.org,
 linux-kernel@vger.kernel.org, cocci@inria.fr,
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org,
 ath11k@lists.infradead.org, linux-mm@kvack.org,
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev,
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org,
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org,
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, Anna-Maria Behnsen
 
Subject: Re: [PATCH v3 00/19] Converge on using secs_to_jiffies()
Message-ID: <20241210184129.41aaf371@kernel.org>
In-Reply-To: <20241210183130.81111d05148c41278a299aad@linux-foundation.org>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
	<315e9178-5b10-4de0-bdcf-7243e0e355bb@oss.qualcomm.com>
	<20241210153604.cf99699f264f12740ffce5c7@linux-foundation.org>
	<20241210173548.5d32efe0@kernel.org>
	<20241210183130.81111d05148c41278a299aad@linux-foundation.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 10 Dec 2024 18:31:30 -0800 Andrew Morton wrote:
> > > I'll just grab everything and see if anyone complains ;)  
> > 
> > I may, if this leads to a conflict :(  
> 
> Very unlikely, and any such conflict will be trivial.

Agreed, mainly I don't understand why we'd make an exception
and take the patchset via a special tree.

> > Easwar, please break this up per subsystem.  
> 
> The series is already one-patch-per-changed-file.

More confusingly still, they did send one standalone patch for 
an Ethernet driver:
https://lore.kernel.org/all/20241210-converge-secs-to-jiffies-v3-20-59479891e658@linux.microsoft.com/
And yet another Ethernet driver (drivers/net/ethernet/google/gve/) 
is converted in this series.


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 02:50:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 02:50:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853652.1267044 (Exim 4.92)
	(envelope-from )
	id 1tLCoK-0005N0-SW; Wed, 11 Dec 2024 02:50:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853652.1267044; Wed, 11 Dec 2024 02: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 1tLCoK-0005Mt-Np; Wed, 11 Dec 2024 02:50:48 +0000
Received: by outflank-mailman (input) for mailman id 853652;
 Wed, 11 Dec 2024 02:50: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 1tLCoJ-0005KQ-1k
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 02:50:47 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b7e0f4a2-b76a-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 03:50:45 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 8E954A41B57;
 Wed, 11 Dec 2024 02:48:52 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2F66C4CEDF;
 Wed, 11 Dec 2024 02:50: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: b7e0f4a2-b76a-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org;
	s=korg; t=1733885443;
	bh=C1p1Ur5QCo63c2pabe6pdtPHc4DXD/edWuUg2c5W1rI=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=u5fZ/gpW5jFRGO7MUBQaaZ7EgRL5SbKSrvY7yk4XgnrXQ7iTXlQdgNQuxkXW8XsEU
	 DrSY2RvgO3myem+8+0r+fPnEVkJ622gxoAvBGZmHq1GHcjqcIgbi0UiHZMQHG1FvHq
	 abSWtb/hxC5Xk4n2V4Wr5FYMY7W0R77+cgVDL+GA=
Date: Tue, 10 Dec 2024 18:50:40 -0800
From: Andrew Morton 
To: Jakub Kicinski 
Cc: Easwar Hariharan , Jeff Johnson
 , Pablo Neira Ayuso ,
 Jozsef Kadlecsik , "David S. Miller"
 , Eric Dumazet , Paolo Abeni
 , Simon Horman , Julia Lawall
 , Nicolas Palix , Daniel Mack
 , Haojian Zhuang , Robert
 Jarzmik , Russell King ,
 Heiko Carstens , Vasily Gorbik ,
 Alexander Gordeev , Christian Borntraeger
 , Sven Schnelle , Ofir
 Bitton , Oded Gabbay , Lucas De
 Marchi , Thomas =?ISO-8859-1?Q?Hellstr=F6m?=
 , Rodrigo Vivi ,
 Maarten Lankhorst , Maxime Ripard
 , Thomas Zimmermann , David Airlie
 , Simona Vetter , Jeroen de Borst
 , Praveen Kaligineedi ,
 Shailend Chand , Andrew Lunn ,
 James Smart , Dick Kennedy
 , "James E.J. Bottomley"
 , "Martin K. Petersen"
 , Roger Pau =?ISO-8859-1?Q?Monn=E9?=
 , Jens Axboe , Kalle Valo
 , Jeff Johnson , Catalin Marinas
 , Jack Wang , Marcel
 Holtmann , Johan Hedberg ,
 Luiz Augusto von Dentz , Greg Kroah-Hartman
 , Florian Fainelli
 , Ray Jui , Scott Branden
 , Broadcom internal kernel review list
 , Xiubo Li , Ilya
 Dryomov , Josh Poimboeuf , Jiri
 Kosina , Miroslav Benes , Petr Mladek
 , Joe Lawrence , Jaroslav Kysela
 , Takashi Iwai , Louis Peens
 , Michael Ellerman , Nicholas
 Piggin , Christophe Leroy ,
 Naveen N Rao , Madhavan Srinivasan
 , netfilter-devel@vger.kernel.org,
 coreteam@netfilter.org, netdev@vger.kernel.org,
 linux-kernel@vger.kernel.org, cocci@inria.fr,
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org,
 ath11k@lists.infradead.org, linux-mm@kvack.org,
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev,
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org,
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org,
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, Anna-Maria Behnsen
 
Subject: Re: [PATCH v3 00/19] Converge on using secs_to_jiffies()
Message-Id: <20241210185040.96c81a25f098f59191223c9f@linux-foundation.org>
In-Reply-To: <20241210184129.41aaf371@kernel.org>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
	<315e9178-5b10-4de0-bdcf-7243e0e355bb@oss.qualcomm.com>
	<20241210153604.cf99699f264f12740ffce5c7@linux-foundation.org>
	<20241210173548.5d32efe0@kernel.org>
	<20241210183130.81111d05148c41278a299aad@linux-foundation.org>
	<20241210184129.41aaf371@kernel.org>
X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 10 Dec 2024 18:41:29 -0800 Jakub Kicinski  wrote:

> On Tue, 10 Dec 2024 18:31:30 -0800 Andrew Morton wrote:
> > > > I'll just grab everything and see if anyone complains ;)  
> > > 
> > > I may, if this leads to a conflict :(  
> > 
> > Very unlikely, and any such conflict will be trivial.
> 
> Agreed, mainly I don't understand why we'd make an exception
> and take the patchset via a special tree.

It saves work for everyone?

The patches are super-simple.  If a maintainer chooses to merge one of
them, Stephen tells us and I drop the mm.git copy.  It's all so easy.



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 02:57:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 02:57:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853667.1267053 (Exim 4.92)
	(envelope-from )
	id 1tLCuK-0007kY-FS; Wed, 11 Dec 2024 02:57:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853667.1267053; Wed, 11 Dec 2024 02:57:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLCuK-0007kR-Ch; Wed, 11 Dec 2024 02:57:00 +0000
Received: by outflank-mailman (input) for mailman id 853667;
 Wed, 11 Dec 2024 02:56: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 1tLCuI-0007kL-FH
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 02:56:58 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9462ee14-b76b-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 03:56:56 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733885809871328.87598938491556;
 Tue, 10 Dec 2024 18:56: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: 9462ee14-b76b-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1733885812; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=WWNuNS/+8T+BOtKhGhSMLDssYNPPBI6H93XBiI06fTCDGtPK/5RljmURxdvY1h8Ip5Q3Nn2Kx/L0XDm4MNfqE/NG8e7XRgi+4vSaXQw9e8CHvPsbLli9Q7LhyEbrkku1UHXT/RMunBAZu7Un7zGT+fYRpuDg5OpHl6zFtcickW0=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733885812; 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=0/lcSUI7yx2cadlAd5k8XLGYiNGTpCtlXl0eD75AemM=; 
	b=HFN28VVa0sQaKVPKLWq/cIUmnp0qE65SNgP1Kb9h17Yj7su3AfLE1skv+UwJK28yK8DdHNkDc6Ppnw+dcUV8l8QgUDwXnBrZdiAOPxQ1U0JybwjNyWM8JNLFMVRSwouhPd/yeUIeeTgEpxgJzFNq5LYQce3ZiOjtdFaohUH1k7M=
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=1733885812;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=0/lcSUI7yx2cadlAd5k8XLGYiNGTpCtlXl0eD75AemM=;
	b=IfVseuyP9fEXtbfs5qLbLfZQGxxq6/NHcXVM284bxzrhccyWxtGvgwgU/M7GY3nM
	XFGjEXVVtspFRD8C0/nKaToVMxdEl46y6iL3cdzKrTrmTjawlLfQZOJCdT2T7rZyKkp
	c68HRiCSWtfdrjfBajBks8ldze8+vfMK1xfK3XL4=
Message-ID: <4ac5e90c-d0e8-4958-a694-dfa49bf0360d@apertussolutions.com>
Date: Tue, 10 Dec 2024 21:56:48 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 03/15] x86/boot: add cmdline to struct boot_domain
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com,
 Jan Beulich , Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-4-dpsmith@apertussolutions.com>
 
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

On 11/25/24 10:36, Jason Andryuk wrote:
> On 2024-11-23 13:20, Daniel P. Smith wrote:
>> Add a container for the "cooked" command line for a domain. This 
>> provides for
>> the backing memory to be directly associated with the domain being 
>> constructed.
>> This is done in anticipation that the domain construction path may 
>> need to be
>> invoked multiple times, thus ensuring each instance had a distinct memory
>> allocation.
>>
>> Signed-off-by: Daniel P. Smith 
>> ---
>> Changes since v9 boot modules:
>> - convert pvh_load_kernel to boot domain to directly use cmdline
>> - adjustments to domain_cmdline_size
>>    - remove ASSERT and return 0 instead
>>    - use strlen() of values instead of hardcoded sizes
>> - update cmdline parsing check to inspect multiboot string and not 
>> just pointer
>> - add goto to skip cmdline processing if domain_cmdline_size returns 0
>> - drop updating cmdline_pa with dynamic buffer with change of its last 
>> consumer
>>    pvh_load_kernel
>>
>> Changes since v8:
>> - switch to a dynamically allocated buffer
>> - dropped local cmdline var in pv dom0_construct()
>>
>> Changes since v7:
>> - updated commit message to expand on intent and purpose
>> ---
>>   xen/arch/x86/hvm/dom0_build.c         | 12 +++---
>>   xen/arch/x86/include/asm/bootdomain.h |  2 +
>>   xen/arch/x86/pv/dom0_build.c          |  4 +-
>>   xen/arch/x86/setup.c                  | 54 ++++++++++++++++++++++-----
>>   4 files changed, 54 insertions(+), 18 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/ 
>> dom0_build.c
>> index a9384af14304..cbc365d678d2 100644
>> --- a/xen/arch/x86/hvm/dom0_build.c
>> +++ b/xen/arch/x86/hvm/dom0_build.c
>> @@ -644,9 +644,11 @@ static bool __init check_and_adjust_load_address(
>>   }
>>   static int __init pvh_load_kernel(
>> -    struct domain *d, struct boot_module *image, struct boot_module 
>> *initrd,
>> -    paddr_t *entry, paddr_t *start_info_addr)
>> +    struct boot_domain *bd, paddr_t *entry, paddr_t *start_info_addr)
>>   {
>> +    struct domain *d = bd->d;
>> +    struct boot_module *image = bd->kernel;
>> +    struct boot_module *initrd = bd->ramdisk;
>>       void *image_base = bootstrap_map_bm(image);
>>       void *image_start = image_base + image->headroom;
>>       unsigned long image_len = image->size;
> 
> cmdline_pa is used just outside of view below here.
> 
> const char *cmdline = image->cmdline_pa ? __va(image->cmdline_pa) : NULL;

As you mentioned below, this should have been converted to bd->cmdline, 
there's no need for the intermediate variable.

>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>> index a2178d5e8cc5..e6580382d247 100644
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -965,10 +965,29 @@ static unsigned int __init copy_bios_e820(struct 
>> e820entry *map, unsigned int li
>>       return n;
>>   }
>> -static struct domain *__init create_dom0(struct boot_info *bi)
>> +static size_t __init domain_cmdline_size(
>> +    struct boot_info *bi, struct boot_domain *bd)
>>   {
>> -    static char __initdata cmdline[MAX_GUEST_CMDLINE];
>> +    size_t s = bi->kextra ? strlen(bi->kextra) : 0;
>> +
>> +    s += bd->kernel->cmdline_pa ? strlen(__va(bd->kernel- 
>> >cmdline_pa)) : 0;
>> +
>> +    if ( s == 0 )
>> +        return s;
>> +
>> +    /*
>> +     * Certain parameters from the Xen command line may be added to 
>> the dom0
>> +     * command line. Add additional space for the possible cases 
>> along with one
>> +     * extra char to hold \0.
>> +     */
>> +    s += strlen(" noapic") + strlen(" acpi=") + sizeof(acpi_param) + 1;
>> +
>> +    return s;
>> +}
>> +static struct domain *__init create_dom0(struct boot_info *bi)
>> +{
>> +    char *cmdline = NULL;
>>       struct xen_domctl_createdomain dom0_cfg = {
>>           .flags = IS_ENABLED(CONFIG_TBOOT) ? 
>> XEN_DOMCTL_CDF_s3_integrity : 0,
>>           .max_evtchn_port = -1,
>> @@ -1008,19 +1027,30 @@ static struct domain *__init 
>> create_dom0(struct boot_info *bi)
>>           panic("Error creating d%uv0\n", bd->domid);
>>       /* Grab the DOM0 command line. */
>> -    if ( bd->kernel->cmdline_pa || bi->kextra )
>> +    if ( (bd->kernel->cmdline_pa &&
>> +          ((char *)__va(bd->kernel->cmdline_pa))[0]) ||
>> +         bi->kextra )
> 
> Here you are checking pointers.
> 
>>       {
>> +        size_t cmdline_size = domain_cmdline_size(bi, bd);
> 
> Internally, domain_cmdline_size() checks the pointers.
> 
>> +
>> +        if ( cmdline_size == 0 )
>> +            goto skip_cmdline;
>> +
> 
> Maybe just use:
> 
> cmdline_size = domain_cmdline_size(bi, bd);
> if ( cmdline_size )
> {
> 
> and eliminate the goto?

Sure.

>> +        if ( !(cmdline = xzalloc_array(char, cmdline_size)) )
>> +            panic("Error allocating cmdline buffer for %pd\n", d);
>> +
>>           if ( bd->kernel->cmdline_pa )
>> -            safe_strcpy(cmdline,
>> -                        cmdline_cook(__va(bd->kernel->cmdline_pa), 
>> bi->loader));
>> +            strlcpy(cmdline,
>> +                    cmdline_cook(__va(bd->kernel->cmdline_pa),bi- 
>> >loader),
>> +                    cmdline_size);
>>           if ( bi->kextra )
>>               /* kextra always includes exactly one leading space. */
>> -            safe_strcat(cmdline, bi->kextra);
>> +            strlcat(cmdline, bi->kextra, cmdline_size);
>>           /* Append any extra parameters. */
>>           if ( skip_ioapic_setup && !strstr(cmdline, "noapic") )
>> -            safe_strcat(cmdline, " noapic");
>> +            strlcat(cmdline, " noapic", cmdline_size);
>>           if ( (strlen(acpi_param) == 0) && acpi_disabled )
>>           {
>> @@ -1030,17 +1060,21 @@ static struct domain *__init 
>> create_dom0(struct boot_info *bi)
>>           if ( (strlen(acpi_param) != 0) && !strstr(cmdline, "acpi=") )
>>           {
>> -            safe_strcat(cmdline, " acpi=");
>> -            safe_strcat(cmdline, acpi_param);
>> +            strlcat(cmdline, " acpi=", cmdline_size);
>> +            strlcat(cmdline, acpi_param, cmdline_size);
>>           }
>> -        bd->kernel->cmdline_pa = __pa(cmdline);
>> +        bd->cmdline = cmdline;
> 
> As mentioned above, it looks like you still inadvertently use bd- 
>  >kernel->cmdline_pa and not the new bd->cmdline.  I think clearing bd- 
>  >kernel->cmdline_pa would have helped identify that.  Or do you want to 
> retain cmdline_pa for some reason?  It's less error prone if only one is 
> usable at a time.

When it was just the boot module, it was requested that the pa be 
updated to be the cooked command line. I dropped it here, as we begin to 
transition to multi-domain construction. It is a good point that 
zero-ing will stop inadvertent use of the old/original buffer.

>>       }
>> + skip_cmdline:
>>       bd->d = d;
>>       if ( construct_dom0(bd) != 0 )
>>           panic("Could not construct domain 0\n");
>> +    if ( cmdline )
>> +        xfree(cmdline);
> 
> You can drop the if - xfree() handles NULL.

ack.

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 03:01:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 03:01:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853678.1267063 (Exim 4.92)
	(envelope-from )
	id 1tLCyh-0001me-0X; Wed, 11 Dec 2024 03:01:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853678.1267063; Wed, 11 Dec 2024 03:01:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLCyg-0001mX-TK; Wed, 11 Dec 2024 03:01:30 +0000
Received: by outflank-mailman (input) for mailman id 853678;
 Wed, 11 Dec 2024 03: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 1tLCyf-0001mL-RH
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 03:01:29 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 366a2a6b-b76c-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 04:01:28 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 173388608040281.05351460689235;
 Tue, 10 Dec 2024 19:01:20 -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: 366a2a6b-b76c-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1733886082; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=VMMjOSTRr2vvppv2ZbRLUfLWUuvNfg9lyxQn20QN1d24SJhGWzsyl+LQ/FQer6D4+MbdasxdFLhAhzChNw3Wk5hjBSun6p33Rb8i1QPT4aFlqvHPooEfyWBNVl/ysomyc78/NXNAhLrgHFpJlCrtEecmsle1Eke3076w7WbLLxA=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733886082; 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=yB8V84d+Bxgzr5yKILVDci8Mq4G8EyFx1FSObp71k5Q=; 
	b=bPbuVN/RA9Cv4bBdBy+prxr3dkYHGEhtIL5aUvrwVrvcRYBqVuUqpBbOF2lGLdNRbZB622ElL4VZ8zNLsvu/8IXPBBjcZcR7Hdk40FIOQ74buIvlWcrQUr7L6Oo9LfbWfX7SAPLP5Aie4bcJQxv32Ea2NtrtWysORIJ/YtXKi3w=
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=1733886082;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=yB8V84d+Bxgzr5yKILVDci8Mq4G8EyFx1FSObp71k5Q=;
	b=okk4ofrrSmi9BJKWXhMpJKWjhVntnrphgZ0B2koHpot5DIVt6k5oZJMgYR7RhLm8
	k281oJN9cixGgB30YxPTpftOpCvQ98x8I+hrd9wfUtx0MoDfYDTasnLc4gZZyv+eios
	zOe5ez6dUyUqNhm5CTE54crv+L9/lDWSuq5jHElc=
Message-ID: <5deb8f9f-75bb-43b9-98c3-1b5e02076e61@apertussolutions.com>
Date: Tue, 10 Dec 2024 22:01:18 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 03/15] x86/boot: add cmdline to struct boot_domain
To: Jan Beulich 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-4-dpsmith@apertussolutions.com>
 <43ce0519-5717-4d59-922d-10dc2c663747@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <43ce0519-5717-4d59-922d-10dc2c663747@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 12/2/24 04:49, Jan Beulich wrote:
> On 23.11.2024 19:20, Daniel P. Smith wrote:
>> --- a/xen/arch/x86/hvm/dom0_build.c
>> +++ b/xen/arch/x86/hvm/dom0_build.c
>> @@ -644,9 +644,11 @@ static bool __init check_and_adjust_load_address(
>>   }
>>   
>>   static int __init pvh_load_kernel(
>> -    struct domain *d, struct boot_module *image, struct boot_module *initrd,
>> -    paddr_t *entry, paddr_t *start_info_addr)
>> +    struct boot_domain *bd, paddr_t *entry, paddr_t *start_info_addr)
>>   {
>> +    struct domain *d = bd->d;
>> +    struct boot_module *image = bd->kernel;
>> +    struct boot_module *initrd = bd->ramdisk;
>>       void *image_base = bootstrap_map_bm(image);
>>       void *image_start = image_base + image->headroom;
>>       unsigned long image_len = image->size;
>> @@ -1304,14 +1306,12 @@ static void __hwdom_init pvh_setup_mmcfg(struct domain *d)
>>   int __init dom0_construct_pvh(struct boot_domain *bd)
>>   {
>>       paddr_t entry, start_info;
>> -    struct boot_module *image = bd->kernel;
>> -    struct boot_module *initrd = bd->ramdisk;
>>       struct domain *d = bd->d;
>>       int rc;
>>   
>>       printk(XENLOG_INFO "*** Building a PVH Dom%d ***\n", d->domain_id);
>>   
>> -    if ( image == NULL )
>> +    if ( bd->kernel == NULL )
>>           panic("Missing kernel boot module for %pd construction\n", d);
>>   
>>       if ( is_hardware_domain(d) )
>> @@ -1351,7 +1351,7 @@ int __init dom0_construct_pvh(struct boot_domain *bd)
>>           return rc;
>>       }
>>   
>> -    rc = pvh_load_kernel(d, image, initrd, &entry, &start_info);
>> +    rc = pvh_load_kernel(bd, &entry, &start_info);
>>       if ( rc )
>>       {
>>           printk("Failed to load Dom0 kernel\n");
> 
> None of this looks command line related - do these changes rather belong into
> patch 1?

Hmmm, yah, it looks like it. This must have been a cherry-pick artifact 
that I missed when updating these commits on top of the version from the 
boot module reviews. I will review and move/drop the chunks.

v/r,
dps




From xen-devel-bounces@lists.xenproject.org Wed Dec 11 03:01:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 03:01:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853681.1267073 (Exim 4.92)
	(envelope-from )
	id 1tLCyt-0002EY-7P; Wed, 11 Dec 2024 03:01:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853681.1267073; Wed, 11 Dec 2024 03:01: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 1tLCyt-0002EM-4S; Wed, 11 Dec 2024 03:01:43 +0000
Received: by outflank-mailman (input) for mailman id 853681;
 Wed, 11 Dec 2024 03:01: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 1tLCyr-0001mL-Pm
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 03:01:41 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3d6f291e-b76c-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 04:01:39 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id C7872A41D8E;
 Wed, 11 Dec 2024 02:59:46 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 097C6C4CED6;
 Wed, 11 Dec 2024 03:01:33 +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: 3d6f291e-b76c-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1733886097;
	bh=08Gv+rg+muCd4b+QXxh4lSp3ciy5sU1jyZsQ2rNGCQs=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=EmcE4/ljfCRY3RJanBjxtPhT62/nJjxk7ELO0ZGNbc2mhHWfd391knNb2HOuZGhSx
	 1e9fTFNcZABywOnqpoRKAEZbgjlix3qU4Qd2lcLQX3AgcLKJ4vrIgfKpyVm37bJMAM
	 wiwQScSc5AP2YRJa64ls0Q4PrRlmeIvzeFuzlqiXSS0E4b38+g1f5LgHQjP+e4bxxF
	 EWfJBUd/sx64BPsSVOGtlrnzPfoqLHGXyBoBKFxBYI5CCDVF2OYRXR0K/LPrQzVMJu
	 IZkEdyC65OkC/1hbUFTVO1xckc1Src7rjo3nhww+SaTgc+dkPD8qefo1Jh9IYKWx27
	 gFWQHpinQ+82w==
Date: Tue, 10 Dec 2024 19:01:33 -0800
From: Jakub Kicinski 
To: Andrew Morton 
Cc: Easwar Hariharan , Jeff Johnson
 , Pablo Neira Ayuso ,
 Jozsef Kadlecsik , "David S. Miller"
 , Eric Dumazet , Paolo Abeni
 , Simon Horman , Julia Lawall
 , Nicolas Palix , Daniel Mack
 , Haojian Zhuang , Robert
 Jarzmik , Russell King ,
 Heiko Carstens , Vasily Gorbik ,
 Alexander Gordeev , Christian Borntraeger
 , Sven Schnelle , Ofir
 Bitton , Oded Gabbay , Lucas De
 Marchi , Thomas =?UTF-8?B?SGVsbHN0csO2bQ==?=
 , Rodrigo Vivi ,
 Maarten Lankhorst , Maxime Ripard
 , Thomas Zimmermann , David Airlie
 , Simona Vetter , Jeroen de Borst
 , Praveen Kaligineedi ,
 Shailend Chand , Andrew Lunn ,
 James Smart , Dick Kennedy
 , "James E.J. Bottomley"
 , "Martin K. Petersen"
 , Roger Pau =?UTF-8?B?TW9ubsOp?=
 , Jens Axboe , Kalle Valo
 , Jeff Johnson , Catalin Marinas
 , Jack Wang , Marcel
 Holtmann , Johan Hedberg ,
 Luiz Augusto von Dentz , Greg Kroah-Hartman
 , Florian Fainelli
 , Ray Jui , Scott Branden
 , Broadcom internal kernel review list
 , Xiubo Li , Ilya
 Dryomov , Josh Poimboeuf , Jiri
 Kosina , Miroslav Benes , Petr Mladek
 , Joe Lawrence , Jaroslav Kysela
 , Takashi Iwai , Louis Peens
 , Michael Ellerman , Nicholas
 Piggin , Christophe Leroy ,
 Naveen N Rao , Madhavan Srinivasan
 , netfilter-devel@vger.kernel.org,
 coreteam@netfilter.org, netdev@vger.kernel.org,
 linux-kernel@vger.kernel.org, cocci@inria.fr,
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org,
 ath11k@lists.infradead.org, linux-mm@kvack.org,
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev,
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org,
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org,
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, Anna-Maria Behnsen
 
Subject: Re: [PATCH v3 00/19] Converge on using secs_to_jiffies()
Message-ID: <20241210190133.44818a76@kernel.org>
In-Reply-To: <20241210185040.96c81a25f098f59191223c9f@linux-foundation.org>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
	<315e9178-5b10-4de0-bdcf-7243e0e355bb@oss.qualcomm.com>
	<20241210153604.cf99699f264f12740ffce5c7@linux-foundation.org>
	<20241210173548.5d32efe0@kernel.org>
	<20241210183130.81111d05148c41278a299aad@linux-foundation.org>
	<20241210184129.41aaf371@kernel.org>
	<20241210185040.96c81a25f098f59191223c9f@linux-foundation.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 10 Dec 2024 18:50:40 -0800 Andrew Morton wrote:
> > > Very unlikely, and any such conflict will be trivial.  
> > 
> > Agreed, mainly I don't understand why we'd make an exception
> > and take the patchset via a special tree.  
> 
> It saves work for everyone?
> 
> The patches are super-simple.  If a maintainer chooses to merge one of
> them, Stephen tells us and I drop the mm.git copy.  It's all so easy.

If it's just to save work - we're fine.
Please don't apply the networking changes.


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 03:03:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 03:03:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853700.1267083 (Exim 4.92)
	(envelope-from )
	id 1tLD0Q-0004GK-Kr; Wed, 11 Dec 2024 03:03:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853700.1267083; Wed, 11 Dec 2024 03:03: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 1tLD0Q-0004GD-Hj; Wed, 11 Dec 2024 03:03:18 +0000
Received: by outflank-mailman (input) for mailman id 853700;
 Wed, 11 Dec 2024 03:03: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 1tLD0P-0004En-3Z
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 03:03:17 +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 750ab3a4-b76c-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 04:03:14 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733886186956718.379389784205;
 Tue, 10 Dec 2024 19:03: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: 750ab3a4-b76c-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1733886189; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=ksxwnsMfVW8oRE0UojpZzYhV640/C4iuNc9cUwY7QSPQZgO7UGPHMJmtUUCEz3DOeNCEJgVymhnr/BhwNX+nyGuyqY8wF5dq1Dli8r4hsiTJQZHJt2pRedAjsni4D05yMdz35uwct4Am32qUitVQoPOmf45Fp1YSJK+IKY/7x/k=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733886189; 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=7DFb3vLMOPYI/O6UDb1gJySxpRV+8/scDyN5yvxffJQ=; 
	b=iPMQtCGgXdHYTpNiyB43L03f39kEH3k63SJ29pJvoGWhWN1y+Q6KIlADYaw5kkSUV5E/L2GgZjScMMzN1mYgNU4nPbCoifTIUeYPiw7RPFDvWuAsTGb5fgHoqEBmerjVTUtKSivSPhYKYlU9R2UvC5lyA2168PB9Mkro/mGzgJY=
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=1733886189;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=7DFb3vLMOPYI/O6UDb1gJySxpRV+8/scDyN5yvxffJQ=;
	b=eVDK5UG9TQGTFC58S4FpKZq+OUvvq2FnTayMmWotFzOWMnN/dNkyTQOTEQUCAgvY
	PuoHpeH9vJACWJX8rNP4WN+5+xJnXg51ZagrM/rFwpCnd96HUKHPNDMOyaEWuadlW3o
	MGzpUbQ0CK6EfWFr6wwbfxDUiAgLRsYW9398iVVU=
Message-ID: 
Date: Tue, 10 Dec 2024 22:03:05 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 04/15] kconfig: introduce option to independently enable
 libfdt
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com,
 Andrew Cooper , Jan Beulich ,
 Julien Grall , Stefano Stabellini 
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-5-dpsmith@apertussolutions.com>
 <20753f5c-bdf5-4f87-aa94-6a32a96f4b94@amd.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <20753f5c-bdf5-4f87-aa94-6a32a96f4b94@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 11/25/24 10:42, Jason Andryuk wrote:
> On 2024-11-23 13:20, Daniel P. Smith wrote:
>> Currently the inclusion of libfdt is controlled by the 
>> CONFIG_HAS_DEVICE_TREE
>> kconfig flag. This flag also changes behvaior in a few places, such as 
>> boot
> 
> behavior

ack.

>> module processing for XSM. To support the ability to include libfdt 
>> without
>> changing these behaviors, introduce CONFIG_LIB_DEVICE_TREE. The 
>> inclusion of
>> libfdt is then moved under CONFIG_LIB_DEVICE_TREE.
>>
>> Signed-off-by: Daniel P. Smith 
> 
> Reviewed-by: Jason Andryuk 

thanks!

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 03:05:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 03:05:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853712.1267092 (Exim 4.92)
	(envelope-from )
	id 1tLD25-0004vK-V7; Wed, 11 Dec 2024 03:05:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853712.1267092; Wed, 11 Dec 2024 03:05: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 1tLD25-0004vD-Rv; Wed, 11 Dec 2024 03:05:01 +0000
Received: by outflank-mailman (input) for mailman id 853712;
 Wed, 11 Dec 2024 03:05: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 1tLD24-0004v5-7G
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 03:05:00 +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 b354f2b5-b76c-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 04:04:58 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 173388629130453.03034218146195;
 Tue, 10 Dec 2024 19:04: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: b354f2b5-b76c-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1733886293; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=e5zBj31BpktjizRmwdGGldjnzao9kGakPtYHaG4P2AwtcQeDq2NN5IJi4nLvCrnpWjGQh6N27KyL+x8bR6LG0UbKBEfZps44zSydcX/gSBmZvvg7DnX2q5K6R4RNR1AQ7RwqHVNQoUkDWx0+QJUY7WMpbLMvt27ynKBLolegCZw=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733886293; 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=ePD0rpqMJrzjGMJQhFsfTVZen5FA6VVlGPmJoiSkJBk=; 
	b=fZJToY5wzGDYH/sNWaEwLv/9lczazAIJb1gPJO+3AvDdNJx5iXwhU1T/gaoeAEPJphXme6V3zgQIOz+hoPiWRppJ1044uC86y+tvOuGdMixK/Yt5IyXGjcDH6eqVDkca2AtzdFAe/oG8keP/cqcDfn2MZBgTK2HvmSUGHUhUrOw=
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=1733886293;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=ePD0rpqMJrzjGMJQhFsfTVZen5FA6VVlGPmJoiSkJBk=;
	b=p1Nbxs/Kb7z6xR6vJjUUolZTr2/OPk5sU0edsSClIC/HkvDlxl/OzVILzm6CUDtS
	eEo9sqNYpS1+iK5ChXbqD+TNDH1Po+pQpI7R8CvePWusVerwwMnV4AhQB80Y6Va2IW5
	lA07ITIvyvbQOOovLouKsbX+LBSDvWeUyY0Sfh1Q=
Message-ID: <9a5625c8-b73e-4b21-8ca7-2f8ef6faedde@apertussolutions.com>
Date: Tue, 10 Dec 2024 22:04:48 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 04/15] kconfig: introduce option to independently enable
 libfdt
To: Jan Beulich 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-5-dpsmith@apertussolutions.com>
 <1c920063-efc9-4004-8670-fa3aae1389ef@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <1c920063-efc9-4004-8670-fa3aae1389ef@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 11/26/24 05:03, Jan Beulich wrote:
> On 23.11.2024 19:20, Daniel P. Smith wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -53,8 +53,12 @@ config HAS_ALTERNATIVE
>>   config HAS_COMPAT
>>   	bool
>>   
>> +config LIB_DEVICE_TREE
>> +    bool
> 
> Nit: Indentation is wrong here and ...
> 
>>   config HAS_DEVICE_TREE
>>   	bool
>> +    select LIB_DEVICE_TREE
> 
> ... here.

ack.

v/r,
dps



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 03:05:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 03:05:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853721.1267103 (Exim 4.92)
	(envelope-from )
	id 1tLD2v-0005QF-7i; Wed, 11 Dec 2024 03:05:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853721.1267103; Wed, 11 Dec 2024 03:05: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 1tLD2v-0005Q8-4O; Wed, 11 Dec 2024 03:05:53 +0000
Received: by outflank-mailman (input) for mailman id 853721;
 Wed, 11 Dec 2024 03:05: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 1tLD2t-0004v5-CI
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 03:05:51 +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 d05216c8-b76c-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 04:05:49 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733886337935142.06994430560655;
 Tue, 10 Dec 2024 19:05: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: d05216c8-b76c-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1733886339; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=Jq3cB01e+q6IoRNReQp6lmHqAnZZf3NambExyUlCaJS26QyxiKJ7qXl4vkhuqqPfyzQrpqOgRBGE8aTVN9ecfx0dUTi+xX/UnmyT/OMJBSFu54HV/KHlJLkv7fafSHtHzn9KVnihjdojAAemoysZzJa3cPBxu8rWrUXwY+dRcvg=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733886339; 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=FBwm+DVWo17DNhDVIoOYs3CG1EuER4iJJ7HL5yW7lN8=; 
	b=mKhs1SBOhMPrYzi/dA4IeDYI6W2z69CF5evhFuNb6/fDp0b7Ez+bfuB6yACsT0eEjXMUWsTvz5pY7TM0BfD32sibd57PqjPJ2Fkg/WsPED2HAuEtnARagw2/3YB7UuwJr1/jneqVE6fmRao8KKFzeatscTvIXTezY/+LCxHC5GY=
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=1733886339;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=FBwm+DVWo17DNhDVIoOYs3CG1EuER4iJJ7HL5yW7lN8=;
	b=iTDilk1jr2I2dTP311drMfI9Df0PGHfOyy9DLI2C3Y6M+AEe6vK7PevJtHe72KbH
	+6NhUnEQOAP3qI+QVFWteZbMPaNt9+bCM4rgyLMmGMBymVzJUUDu2JKrT/RJjDEqPOF
	Ri8PGxHpka4lBRPvsrfGI9Z3419FMoXUAtiPQdBY=
Message-ID: <3b508660-f584-429e-8721-31b7d026cf0a@apertussolutions.com>
Date: Tue, 10 Dec 2024 22:05:34 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 04/15] kconfig: introduce option to independently enable
 libfdt
To: Jan Beulich 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-5-dpsmith@apertussolutions.com>
 <1c920063-efc9-4004-8670-fa3aae1389ef@suse.com>
 <87779b38-c027-45c3-a7af-f3e2b4b2a0f5@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <87779b38-c027-45c3-a7af-f3e2b4b2a0f5@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 11/26/24 05:05, Jan Beulich wrote:
> On 26.11.2024 11:03, Jan Beulich wrote:
>> On 23.11.2024 19:20, Daniel P. Smith wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -53,8 +53,12 @@ config HAS_ALTERNATIVE
>>>   config HAS_COMPAT
>>>   	bool
>>>   
>>> +config LIB_DEVICE_TREE
>>> +    bool
>>
>> Nit: Indentation is wrong here and ...
>>
>>>   config HAS_DEVICE_TREE
>>>   	bool
>>> +    select LIB_DEVICE_TREE
>>
>> ... here.
> 
> Oh, and - please don't put LIB_DEVICE_TREE in the middle of (sorted) HAS_*.
> It wants to move past them, before MEM_*.

ack.

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 03:14:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 03:14:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853738.1267113 (Exim 4.92)
	(envelope-from )
	id 1tLDAj-0000pn-V7; Wed, 11 Dec 2024 03:13:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853738.1267113; Wed, 11 Dec 2024 03:13:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLDAj-0000pg-SC; Wed, 11 Dec 2024 03:13:57 +0000
Received: by outflank-mailman (input) for mailman id 853738;
 Wed, 11 Dec 2024 03:13: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 1tLDAi-0000mA-OJ
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 03:13:56 +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 f29b0b79-b76d-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 04:13:53 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733886827398706.3806840203956;
 Tue, 10 Dec 2024 19:13: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: f29b0b79-b76d-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1733886829; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=N7hBbLL3inN7mqF1mJV69T0pAk6Rp9rYqZTXxZkefpUGLCSdss6lf7pUUzwcJDq3Nb7IzXWu3h2bjMjuKH66dJlWkOHDxHqphfRDUIuRxXhOIkV8NOTIKCRX5+VVcLJC9I8YPcf/+wYP8iWbkrZex0LUPHtIl/YuMiAG42URBNk=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733886829; 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=+ZV6I/NgstiBhyVEqKTX60i171W5W3XGpeYJhsvctzE=; 
	b=IbDTAWa5ERfxu5KLgwF5yMZi4XqfXJwQUsN1cKhDRwT0DDIhzImQWw2lg15o37I0XOQwHR3YZ4Mlfos5e99QAhF9mjsVjP8oYkPu7tM2aJKU4vENuiItgy3Nl1voNGGwfmP0pjFIZKXw03fxzHPrkfYlaUSGepNuL24/1gBY5Q8=
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=1733886828;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=+ZV6I/NgstiBhyVEqKTX60i171W5W3XGpeYJhsvctzE=;
	b=PJLeMl8z9bd1ZnIUGFDUSwJEMELVzGN7nBJ+EX58awzVrl61Fcg3EdvUaY0D12Mn
	//pz4J8+Clrf0ttoYtbyLwizfBQRFzfkddFe/8mvyFLP7RcF25Vr67lBdKg01IfdNxg
	3NwXoKYsUTMDiTeVw6cC8OVnhgvcUb3QKevMSANo=
Message-ID: 
Date: Tue, 10 Dec 2024 22:13:44 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 05/15] kconfig: introduce domain builder config option
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com,
 Jan Beulich , Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-6-dpsmith@apertussolutions.com>
 <45787e79-87e3-4583-aecb-4155195ab230@amd.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <45787e79-87e3-4583-aecb-4155195ab230@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

On 11/25/24 12:55, Jason Andryuk wrote:
> On 2024-11-23 13:20, Daniel P. Smith wrote:
>> Hyperlaunch domain builder will be the consolidated boot time domain 
>> building
>> logic framework. Introduces the config option to enable this domain 
>> builder to
>> and turn on the ability to load the domain configuration via a 
>> flattened device
> 
> "to and"?
> 
>> tree.
> 
> Maybe:
> "Hyperlaunch is the boot time domain building framework where domain 
> configuration is loaded via a flattened device tree.  Introduce a 
> kconfig variable to control the feature."

Sure.

>> Signed-off-by: Daniel P. Smith 
> 
>> diff --git a/xen/arch/x86/domain_builder/Kconfig b/xen/arch/x86/ 
>> domain_builder/Kconfig
>> new file mode 100644
>> index 000000000000..7be2ec3ed00f
>> --- /dev/null
>> +++ b/xen/arch/x86/domain_builder/Kconfig
>> @@ -0,0 +1,15 @@
>> +
>> +menu "Domain Builder Features"
>> +
>> +config DOMAIN_BUILDER
>> +    bool "Domain builder (UNSUPPORTED)" if UNSUPPORTED
>> +    select LIB_DEVICE_TREE
>> +    help
>> +      Enables the domain builder capability to configure boot domain
> 
> Indent is off.

ack

>> +      construction using a flattened device tree.
>> +
>> +      This feature is currently experimental.
> 
> Does this need to be unsupported and experimental?  What makes this more 
> experimental and/or unsupported than any other new feature?

I don't believe it is a unilateral decision I get to make. In fact, with 
the directory introduction, a new HYPERLAUNCH section in MAINTAINERS 
might be warranted with this commit. If so, I would think myself, 
Christopher, and the x86 maintainers would all be set as maintainers for 
the feature.

> At least with the commit message and indent fixes:
> 
> Reviewed-by: Jason Andryuk 

thanks!

v/r,
dps



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 03:15:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 03:15:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853748.1267122 (Exim 4.92)
	(envelope-from )
	id 1tLDC1-0001pm-6L; Wed, 11 Dec 2024 03:15:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853748.1267122; Wed, 11 Dec 2024 03:15: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 1tLDC1-0001pf-3s; Wed, 11 Dec 2024 03:15:17 +0000
Received: by outflank-mailman (input) for mailman id 853748;
 Wed, 11 Dec 2024 03:15: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 1tLDC0-0001Nc-KR
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 03:15:16 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 236945cb-b76e-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 04:15:15 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733886904287260.9778254562499;
 Tue, 10 Dec 2024 19:15: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: 236945cb-b76e-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1733886907; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=W2ORHf/mKbQQAfTZA9Onw3fPGJ+6144y9v5XhV3f6bIIrjUjmWSYjp5ZT3jG4Gm/RSlrjXX1WnnkjLAWfqFW3Rbl8ddPs4Kyb/E3duQHIGm/N78BREQFt9/ANVRGcut+7Aroayncl3ogg2VkGmADWYjuJZl4Ho5UQJH47Etd/UE=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733886907; 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=fFufXiXPkg6kDgH9fpNCf7zCQc40rCir74TbHskC/Mc=; 
	b=YOCA8nA2FTIBnoGEWOHwiEFiu8lW7n/eQJftEtXxUxgaKK51WiGNesSm5dUrJkWdLyVz48Wylovw3HKitMIbDt1mGEWAb/fxOOh7u13YiFqzwGWjxudGzS+t8oIYCnNJoCqxmbIrSVoifgbz8t/MbWdxjMG+ijqitwrH5W9n+1o=
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=1733886907;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=fFufXiXPkg6kDgH9fpNCf7zCQc40rCir74TbHskC/Mc=;
	b=AWUY3GQ9bH5pf9vA8Q9CsMkSheiyzfAe9pWPa3x0k+8wiK/A9IzTgnD6QTQwtOTG
	uyAVWmf3SNyJSCyWIoh1zI4hOnhWAzZfrw2udhz3oC8SPWVbok3IwJ/mYs17epbEzHl
	yU+snm1Z27PvrbX57p4QLllhm6Htjmo4xDC78ozs=
Message-ID: 
Date: Tue, 10 Dec 2024 22:15:02 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 05/15] kconfig: introduce domain builder config option
To: Jan Beulich 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-6-dpsmith@apertussolutions.com>
 
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 11/26/24 05:09, Jan Beulich wrote:
> On 23.11.2024 19:20, Daniel P. Smith wrote:
>> Hyperlaunch domain builder will be the consolidated boot time domain building
>> logic framework. Introduces the config option to enable this domain builder to
>> and turn on the ability to load the domain configuration via a flattened device
>> tree.
>>
>> Signed-off-by: Daniel P. Smith 
>> ---
>>   xen/arch/x86/Kconfig                |  2 ++
>>   xen/arch/x86/domain_builder/Kconfig | 15 +++++++++++++++
>>   2 files changed, 17 insertions(+)
>>   create mode 100644 xen/arch/x86/domain_builder/Kconfig
> 
> I think I mentioned this already back when the much bigger series was first
> posted: Please no underscores in new file (or directory) names; dashes are
> to be preferred.

You are correct, my apologies for dropping that and I will fix it.

v/r,
dps



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 04:35:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 04:35:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853768.1267132 (Exim 4.92)
	(envelope-from )
	id 1tLER0-00031O-Ro; Wed, 11 Dec 2024 04:34:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853768.1267132; Wed, 11 Dec 2024 04: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 1tLER0-00031H-P1; Wed, 11 Dec 2024 04:34:50 +0000
Received: by outflank-mailman (input) for mailman id 853768;
 Wed, 11 Dec 2024 04:34: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 1tLEQz-00031B-Lo
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 04:34:49 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 407e9c8b-b779-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 05:34:47 +0100 (CET)
Received: from [100.65.208.14] (unknown [20.236.11.185])
 by linux.microsoft.com (Postfix) with ESMTPSA id C44BD204722B;
 Tue, 10 Dec 2024 20:34: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: 407e9c8b-b779-11ef-a0d5-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com C44BD204722B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1733891686;
	bh=SKADluaoUiTETH1UwG/V5DVCwgNdNCuMvx/YiXR3rAc=;
	h=Date:Cc:Subject:To:References:From:In-Reply-To:From;
	b=IJPud503TZQ7qC+nAh33r29ZAguv/DZaDYDmYDAbJHqsXv7vFEisx4C+2Bx4/X0Ny
	 QNmGT6WWiLLDSDyIxMX24BlKcPvLa2DRjFmS0GhpoB9JmvKOYeEniEHPcKfYI5Rx3Y
	 UFvay1FmNXEMmTdeKu7+xEJKV27TsW4+ndYHIugA=
Message-ID: 
Date: Tue, 10 Dec 2024 20:34:43 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Cc: Andrew Morton , eahariha@linux.microsoft.com,
 Jeff Johnson ,
 Pablo Neira Ayuso ,
 Jozsef Kadlecsik ,
 "David S. Miller" , Eric Dumazet ,
 Paolo Abeni , Simon Horman ,
 Julia Lawall , Nicolas Palix ,
 Daniel Mack , Haojian Zhuang ,
 Robert Jarzmik , Russell King
 , Heiko Carstens ,
 Vasily Gorbik , Alexander Gordeev
 , Christian Borntraeger ,
 Sven Schnelle , Ofir Bitton ,
 Oded Gabbay , Lucas De Marchi
 ,
 =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= ,
 Rodrigo Vivi ,
 Maarten Lankhorst ,
 Maxime Ripard , Thomas Zimmermann ,
 David Airlie , Simona Vetter ,
 Jeroen de Borst ,
 Praveen Kaligineedi ,
 Shailend Chand , Andrew Lunn ,
 James Smart ,
 Dick Kennedy ,
 "James E.J. Bottomley" ,
 "Martin K. Petersen" ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Jens Axboe , Kalle Valo ,
 Jeff Johnson , Catalin Marinas
 , Jack Wang ,
 Marcel Holtmann ,
 Johan Hedberg ,
 Luiz Augusto von Dentz ,
 Greg Kroah-Hartman ,
 Florian Fainelli , Ray Jui
 , Scott Branden ,
 Broadcom internal kernel review list
 , Xiubo Li ,
 Ilya Dryomov , Josh Poimboeuf ,
 Jiri Kosina , Miroslav Benes ,
 Petr Mladek , Joe Lawrence ,
 Jaroslav Kysela , Takashi Iwai ,
 Louis Peens , Michael Ellerman
 , Nicholas Piggin ,
 Christophe Leroy ,
 Naveen N Rao , Madhavan Srinivasan ,
 netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr,
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org,
 ath11k@lists.infradead.org, linux-mm@kvack.org,
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev,
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org,
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org,
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org,
 Anna-Maria Behnsen 
Subject: Re: [PATCH v3 00/19] Converge on using secs_to_jiffies()
To: Jakub Kicinski 
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
 <315e9178-5b10-4de0-bdcf-7243e0e355bb@oss.qualcomm.com>
 <20241210153604.cf99699f264f12740ffce5c7@linux-foundation.org>
 <20241210173548.5d32efe0@kernel.org>
 <20241210183130.81111d05148c41278a299aad@linux-foundation.org>
 <20241210184129.41aaf371@kernel.org>
From: Easwar Hariharan 
Content-Language: en-US
In-Reply-To: <20241210184129.41aaf371@kernel.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12/10/2024 6:41 PM, Jakub Kicinski wrote:
> On Tue, 10 Dec 2024 18:31:30 -0800 Andrew Morton wrote:
>>>> I'll just grab everything and see if anyone complains ;)  
>>>
>>> I may, if this leads to a conflict :(  
>>
>> Very unlikely, and any such conflict will be trivial.
> 
> Agreed, mainly I don't understand why we'd make an exception
> and take the patchset via a special tree.
> 
>>> Easwar, please break this up per subsystem.  
>>
>> The series is already one-patch-per-changed-file.
> 
> More confusingly still, they did send one standalone patch for 
> an Ethernet driver:
> https://lore.kernel.org/all/20241210-converge-secs-to-jiffies-v3-20-59479891e658@linux.microsoft.com/
> And yet another Ethernet driver (drivers/net/ethernet/google/gve/) 
> is converted in this series.

Sorry about the confusion, I missed pulling the gve patch from this
series. I'll send that (and ath11k) separately as well. I'll pull all
these together into a series so you can merge them together if you prefer.

Thanks,
Easwar


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 06:18:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 06:18:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853791.1267142 (Exim 4.92)
	(envelope-from )
	id 1tLG3A-0004XU-UZ; Wed, 11 Dec 2024 06:18:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853791.1267142; Wed, 11 Dec 2024 06: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 1tLG3A-0004XN-Rw; Wed, 11 Dec 2024 06:18:20 +0000
Received: by outflank-mailman (input) for mailman id 853791;
 Wed, 11 Dec 2024 06:18: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 1tLG39-0004XF-TU
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 06:18:20 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2060a.outbound.protection.outlook.com
 [2a01:111:f403:2416::60a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b3180352-b787-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 07:18:16 +0100 (CET)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SA1PR12MB8119.namprd12.prod.outlook.com (2603:10b6:806:337::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Wed, 11 Dec
 2024 06:18:09 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%3]) with mapi id 15.20.8230.010; Wed, 11 Dec 2024
 06:18: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: b3180352-b787-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xLk616lIsirvVSDq6Erp3+h+mUd7VtYtcEF2mrjrID8OUQjDjva5Hz6t+q+ObMOxy51PbVodKVOvZNfmK3cRsqq5gHRmsE3y+mAkKQIT81WVJUOs+LZe6+oVmhg6umCHbXTrtGEx83iW3ooFvNH4Ae9kQdepJ4uxLuB28aiweApKlHiMm+UK87I/AxO4EmGK3UYhJwUF+AvkJciVV7jRt8iTzFvrCO7Xy1MO95nbYhS+XYltj7tp89QPl8O5f2PsPQ4Yqz70yDwUpx1wLGyepAtLzoK2is9f6C58qBKvTuPyCDc86sM5AW2M4JGBQ68RMBYOmDjypPIUf3dr8HVqVQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=p3cuRtZVFKQZhbCSadEnodG3ElAzkN+6o38Q8YwXpJQ=;
 b=TaCZppcA1wUzwtEaeEZMdZmxCaEy/6bDIM3oyxwZG+uSI/9lelVdzzxiTGjxWEoWZ4npYpbfYAcz42icRP3W7BXAPhdYhDu0UAGIlN5k7m8iNTl7YvgYD2ksKRUc2Vjsrs+MLjJ1LKi0dOQTnOQCH7Fyg04guYiAQjdrTm5q2A9UPYfVKWK3KtZvjY1xhFrmsdwSLj8+K/edwvoc9EW8CNJ+UpkBbYpDd7zv0WA8TjzXQEE4GcSmpJdax1fCFSRGCWBS8t8zDYT4DwqUx0xIYQRyFrAOM2W4rmsFkBz/+FCW69VuZcoWlJ+qVtRvqMcW0HUEdvtUZeWjEYqwU3/GnA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=p3cuRtZVFKQZhbCSadEnodG3ElAzkN+6o38Q8YwXpJQ=;
 b=mU/ibUwcUu5lnWn1aiL34zi/N0yfuis6D9YFY7NDpn3/ezcjp/FEIFho7GPCAQ1RfXiA7oSEB4q7OzpCnf8vrQe1z2ah9MdFnB8wrqUbEtNgmC4zrnSgHk7onnZfW5Y+s/UeWQXZ4inxMuXIG9OYJ/5y7uCnPyFRefYYZl2ZN3Q=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: Andrew Cooper , Julien Grall ,
	Stefano Stabellini , "Huang, Ray"
	, "xen-devel@lists.xenproject.org"
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "Chen, Jiqian" 
Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support
Thread-Topic: [PATCH v2 1/1] vpci: Add resizable bar support
Thread-Index:
 AQHbRIDgGHZ3ofHO0UuqqXvn+EZCabLd/CGAgAGXh4D//4qBgIAAiieA//+hwICAAdt2gA==
Date: Wed, 11 Dec 2024 06:18:09 +0000
Message-ID:
 
References: <20241202060956.1124162-1-Jiqian.Chen@amd.com>
 <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com>
 
 <1e0576d9-400e-4483-8dd1-061e215a00cd@suse.com>
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8230.010)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|SA1PR12MB8119:EE_
x-ms-office365-filtering-correlation-id: 500ee935-bdc2-43f4-b46c-08dd19ab9542
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?OXl6UHA0SkZueEg3aUFURWQ4UmZCWkQrY2pqcUhnMDlMbkp2bUdsUS95aXVH?=
 =?utf-8?B?N0JHTzdFbHFTOFhCVTJneEZoaFJnMVlyL2VTbW5XbXVqQWIvTE9zeW51Y0ZG?=
 =?utf-8?B?OWNkbFY5dHo0Z1lUN3dOa0xRc3lJUXlMak03V0J3R1NCbDZBQ3czb1lPNlF2?=
 =?utf-8?B?UkxzMjltRlJ5emc1K1Erc1BKTTVFaHdxKzdpZ3ZnbW5QaDJkS2NyK1QwQWUx?=
 =?utf-8?B?bFNYVGNHbTFsWXIyRlA5YU1acFFtM2s4WVE0dUJIdG9Hd0djVmdWeHFlbGtm?=
 =?utf-8?B?Q2ZpYmZ6VXR3Q2QzWnB0QXAzdzlYNDZ3a0pSc2FJS0pNMEZNSnBOWi84M0dV?=
 =?utf-8?B?Zkk4ZlQrdHZMRDlIVnlkUXgzQWlhN0IrVnF3c3AwNWZhZUtXSG1jNmNLc2xB?=
 =?utf-8?B?NWo4Y1EyZ2NBNVptdUlRbjQ2TWZkdFY0NjZCS1VwelpuZXl5VGJjMnE3QTJK?=
 =?utf-8?B?SWJnOEFheS8zL1VtS2lHRGZ0aHZ1aDg5SkthWFhTclFrcU1iS3JCZmd0Z1pR?=
 =?utf-8?B?L2hEdHFwT3NXbEhRUG96Y2cxWjVJTGlYRG82ZkVxNVpuODUrMnYzeFZZK1R5?=
 =?utf-8?B?Q0NmaUFMT09LYW5ZSXpXTTUxQUQ3NzZ5RkZxMG9mVmc1Z1VadkcxVnlGMWZ3?=
 =?utf-8?B?WXp1elV4bXdIK3VFeDR6RUwwYW1Mc3p0ejhsdzBCaGd1TDZScktkVUUvQm1U?=
 =?utf-8?B?NHo5MEx6cnFyUXp6VHFEdWVkZTZySlJLRWo2Nkxwa3VhM1p2cEpERzh4UFpm?=
 =?utf-8?B?ekxKQW5iV3p0T290NWd5R3pQLzB5bXU0dmRzMEUvdnlVdnZ3NzhkbnhUUFkx?=
 =?utf-8?B?cnhUVW8zUmgzU1ZNVXZlZWwvWDVoSjh0ZmZmUGE1NFdsMUdxNUlEaDJGZWdu?=
 =?utf-8?B?dDRtbkdIallUblRpTlpHL01yWjJ1aGJaVThjcWcrS04yaU1GRUlLUGxOQVRH?=
 =?utf-8?B?Z2pWUVRsVlhZQWU2bzUyNlQydmJHeXdLSGxCSXJmdG1EampTbFlycFk4bzAr?=
 =?utf-8?B?V1BDYjB0ZkRjM0EzMU1sZkJFTlBQR1M2V09VdlYxNVBITWk4Q2J5MWdmZll1?=
 =?utf-8?B?ZlV1LysyWlFzTVF6RjJ1YmlnKyswS0o0Y1lZb2ZVYnVtTXRSZVlDc2Zha2ZO?=
 =?utf-8?B?OSs0Tlk1WnRobmI3c2Y0dERZZzlReUxPYjg0T0xUYUgvYks4d2o1d25pcG5l?=
 =?utf-8?B?TDBRQlludkFBeTh4dDhXby9GS0VUL1doWmRoVmR5UXVERlZkcmRTcEZ2M2lY?=
 =?utf-8?B?bjgrRHdxYVZaVjRtQ0MvcmZhNHkxakhVOVoxSlpEaThVLzZabGZyZVpjT09M?=
 =?utf-8?B?TTlpMkNJNjM1NjEvT1RpdlJPQk1UWkJYZEhwZTQ5ODRxbURyWmZtcEhZSkk3?=
 =?utf-8?B?cGI2L251WEQzaEhjWk5iVnMzc1RhYVQ1VGFDaHlkM0lGWU12RkdTZEYvc2lz?=
 =?utf-8?B?enRNc0hETUF1U1dKN1dlUjZSUDQ5QmFPMnVaUEI4Rk84OEpUVzE1SW5ONURq?=
 =?utf-8?B?THorb2EzMEllckZzRElJT2xweGlRZXRGZGdIUlBBZWRBUnFsT3lkbG1MeG9B?=
 =?utf-8?B?M1NUV1lva0RBaHFNS3BMR2tZc2JuclBlaDU3c2N5ajVQeGtFOEJJQXNzZWpK?=
 =?utf-8?B?UXpvT1lEQjF1WmJScnVrdnJyRVJ2bi9iS01MNVNRMWoxT3FDbCtRcUNLNlhL?=
 =?utf-8?B?NHpRK0c0dUZyYlIxZmhOUi9SdUJRWUF1NVRNOGJjb2xVZ2R6VllSRXBuQklr?=
 =?utf-8?B?ODVWUG02VTlzSnFCT3hLUEFaQ3g2L2hrem5aejVsemw4WUlDZ1pJN21OdHNO?=
 =?utf-8?B?Qlhidk1VeWk3cjhVUldDblRBaVRGMkpMc1NJL0pWMnNwbWdhbE4vTzJLcEll?=
 =?utf-8?B?dWJqbFEzQjNOQjdIam9zb1hCTXRBenV6TFFlQVFsUHcrUkE9PQ==?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?TitHVy8rTUdtKzYvazgrVmZpeGJiZjg2SkVsMEpxaFcxamg4RCtnREZmZGlo?=
 =?utf-8?B?ZmlIdnB4ZUdZQXFHc2ZHZW0vM0pKaWtFY09GL09wQlJCN0E1T2tQU21Oc3dO?=
 =?utf-8?B?TzJkUFJ1TUVKMU1jcEdCRVA3ZDlFWTJWc3pGU2J2NHhISEFnQnVuenN1cVBM?=
 =?utf-8?B?NnhOaUZoN0MxTUxCdndCeW5SWFdIZ0gvNlgxbHY2TWt3VUtaMXV1bDFSb0s0?=
 =?utf-8?B?VUswQnJuQTF0NkdBTWZPenRDRGdlN2JKSXZDcldOaksrc3RCM1ZrR1FVM1g2?=
 =?utf-8?B?T2ZIVHVrcnBSazN3RllhREdHMnA0RFJDei9yZ09Ld3dDbzl2MWg3eUNIa1do?=
 =?utf-8?B?a2lIckQvY2ZheUhRbi8wM3lKZmdzclZTU2xWZU4xMmtpTnZLZ0tUS0o0UTdh?=
 =?utf-8?B?MFo2N2ZKa2R1MUJiRlNkdHhDUWtUN21QT2tzZ1FVVkRTdzhYU0pJVVMxajlu?=
 =?utf-8?B?amM3MGh2L1h0SStlZFZidUw5NkhEQVp3OW9oUFFMUWpNbCs4ZE03U2ZoTUJV?=
 =?utf-8?B?QUQ2NkIxSks5bEhWNE1IcitUd24yclZrbDFBT2Q1L3VSRVdJMGRBWEJXVWcw?=
 =?utf-8?B?U1czUFBiU1dPZm0vWXFGcUtPL2c2cGkzZFEzMDdlbDVtKzU4dGY3S1FNLzRH?=
 =?utf-8?B?dUNvSFpEZUZTLzg5TVNaUmpsdjE5RlpHbzh4dzBOb053MFJFSjZRS2dBdnJP?=
 =?utf-8?B?eDlOR2h0R3RieUg0cFArRW03dnhraVZCaVZFS1NYSld4QWRPWVUrMGVDc0N2?=
 =?utf-8?B?Z0hVWHVxRFNiWlpyVWJIM1dQZUNsT0VGU2Q0WDVhZHJHZXJvS0t1ai9uQ0RU?=
 =?utf-8?B?WmJ3ODVuSTVnY2dKQUJWeWdtMnNJM1BaQUR4ZGROY0lZZ0hFZ096NENEN2lC?=
 =?utf-8?B?Mmpta05rV2dMK2tHRnBjMHN6aURsKzFSTUkraVk3Tk9FN2dXbmpoVFFNWkgv?=
 =?utf-8?B?NG9WVzNNZjZBYUNPSWZ1c0ZrdVo3L3NKZzc2SDZWVDZjYWpxK1o1R0xaQXZn?=
 =?utf-8?B?U01Pb1VtWU1xTVY1QUlISE9XeUs1UFdDNW52cjZIa01kaXdjeDN1a2xpSG9P?=
 =?utf-8?B?V3A0YlROaG5VUGRTRkRuaHZCcVRaNHBWTDZOYVIvTXUxMEJMRC9pSTRmL3VU?=
 =?utf-8?B?Z2lsN3NTVXBhMDFIdVMvN3lOcDc3OENVOERqVzcwYm9BWXdQcDBQUVBrcmda?=
 =?utf-8?B?dmtXTE83V3VDbmZpN2wyZTNWdjFCcWtnY2lXQWxielc2WTZReUYrMVZRb21v?=
 =?utf-8?B?cjlnWVk1YTl0VWIzNi9aNTgya1h6cnZRQW9MREJFZVB3aGhjQWtISGwyd2xo?=
 =?utf-8?B?Ylg2S2l4VUo3V1RIdkRNUnpQYytialc4S3lIZ2krdmd2RW95Vk1BWnRaanRh?=
 =?utf-8?B?dm5uK2JmV28yRU9wSG1DYUZwRWV5WDQ3QTZvZytLMERYam04dDk1MzdPN1pU?=
 =?utf-8?B?Z1dVUFkzbXdvdDYrQWFCMS95T0hxVDZHU0w5WVdsVkVCSE5kSmtXZm5KTWRt?=
 =?utf-8?B?em9jeWtsQklYWFJSQ3lmQlRhOTJxSmZ2MVZ2TkR0QUU2anhBSXMvYzNVZFJ2?=
 =?utf-8?B?bnRtUzRGb0ZJTSt0QW1Weks5UGU1c3kxU28xa3dXMzNRc0JHZWJGS1hMaVRw?=
 =?utf-8?B?eWdsREJUcnVyay8ydTdBSm4yWHF2NHRnM29PQjZrM2M2cHBvRkdvT0daVThO?=
 =?utf-8?B?ZmNVZTlQWHNBL2Z5TzBZa082c1pnYlRCZU15enVJeHQwUjBoQmtyMHNQUkpG?=
 =?utf-8?B?YS95Sm5JYnhrTTl0eDhFaE5KS0toczNxM1UvL0VmZVBIVmY3M2YwYzRibUJj?=
 =?utf-8?B?R0VMRGtpMXczSkR3TjJ3dldYOWRRbjFCbGNVdTYxQ0JmNFVDMmtqNXpTNjBV?=
 =?utf-8?B?OE5BMmR3RzM4bnd0KzY2T0J4REp1aFlNS05QY0c4OUgrenBMamRjSTFyTkxC?=
 =?utf-8?B?THovM2dIMmtzNE1MMFNZV1pNR3BEaXErY2hkbjd0Y2pUak1WU2lMaTM5Y0NS?=
 =?utf-8?B?Zm1SUmJ6U3p2US84bkkyWHduZVBDSkx1ZjcvSWF1R1owbURNUlN2UXNEUzRx?=
 =?utf-8?B?Q29aSER5blhJbnYvZXJHbUN6VVFRLzMrOGlqWS9BOTU2U1JCYzlYKzhDUlJK?=
 =?utf-8?Q?Fbak=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <30ADA8F23712414F8A4AA8E8CD481F74@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 500ee935-bdc2-43f4-b46c-08dd19ab9542
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2024 06:18:09.0207
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 7y/lY6/RqOmU+FGPBZdcfEUDhQqNtJjHsN9oR0/pleYMAqLNS9RBSKjportMik3JcSfKoHxLaWZpkpK481LIFw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8119

T24gMjAyNC8xMi8xMCAxNzo1NCwgSmFuIEJldWxpY2ggd3JvdGU6DQo+IE9uIDEwLjEyLjIwMjQg
MDg6NTcsIENoZW4sIEppcWlhbiB3cm90ZToNCj4+IE9uIDIwMjQvMTIvMTAgMTU6MTcsIEphbiBC
ZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDEwLjEyLjIwMjQgMDg6MDcsIENoZW4sIEppcWlhbiB3cm90
ZToNCj4+Pj4gT24gMjAyNC8xMi85IDIxOjU5LCBKYW4gQmV1bGljaCB3cm90ZToNCj4+Pj4+IE9u
IDAyLjEyLjIwMjQgMDc6MDksIEppcWlhbiBDaGVuIHdyb3RlOiANCj4+Pj4+PiBAQCAtNTQxLDYg
KzU0MiwxNiBAQA0KPj4+Pj4+ICAjZGVmaW5lICBQQ0lfVk5EUl9IRUFERVJfUkVWKHgpCSgoKHgp
ID4+IDE2KSAmIDB4ZikNCj4+Pj4+PiAgI2RlZmluZSAgUENJX1ZORFJfSEVBREVSX0xFTih4KQko
KCh4KSA+PiAyMCkgJiAweGZmZikNCj4+Pj4+PiAgDQo+Pj4+Pj4gKy8qIFJlc2l6YWJsZSBCQVJz
ICovDQo+Pj4+Pj4gKyNkZWZpbmUgUENJX1JFQkFSX0NBUAkJNAkvKiBjYXBhYmlsaXR5IHJlZ2lz
dGVyICovDQo+Pj4+Pj4gKyNkZWZpbmUgIFBDSV9SRUJBUl9DQVBfU0laRVMJCTB4RkZGRkZGRjAg
IC8qIHN1cHBvcnRlZCBCQVIgc2l6ZXMgKi8NCj4+Pj4+DQo+Pj4+PiBNaXNyYSBkZW1hbmRzIHRo
YXQgdGhpcyBoYXZlIGEgVSBzdWZmaXguDQo+Pj4+IERvIGJlbG93IFBDSV9SRUJBUl9DVFJMX0JB
Ul9JRFgsIFBDSV9SRUJBUl9DVFJMX05CQVJfTUFTSyBhbmQgUENJX1JFQkFSX0NUUkxfQkFSX1NJ
WkUgYWxzbyBuZWVkIGEgVSBzdWZmaXg/DQo+Pj4NCj4+PiBUaGV5IG1heSB3YW50IHRvIGdhaW4g
dGhlbSBmb3IgY29uc2lzdGVuY3ksIGJ1dCB0aGV5IGRvbid0IHN0cmljdGx5IG5lZWQNCj4+PiB0
aGVtLiBJIHdhbnRlZCB0byBzYXkgIlNlZSB0aGUgcmVzdCBvZiB0aGUgZmlsZSIsIGJ1dCBpdCBs
b29rcyBsaWtlIHRoZQ0KPj4+IGZpbGUgd2Fzbid0IGNsZWFuZWQgdXAgeWV0IE1pc3JhLXdpc2Uu
DQo+PiBZZXMsIEkgbm90aWNlZCB0aGF0IHRoZSByZXN0IG9mIHRoZSBmaWxlIGRpZG4ndCBhZGQg
VSBzdWZmaXggdG9vLg0KPj4gU28sIEkganVzdCBuZWVkIHRvIGFkZCBVIHN1ZmZpeGVzIGZvciBt
eSBuZXcgbWFjcm9zPw0KPiANCj4gWW91IG9ubHkgc3RyaWN0bHkgbmVlZCB0byBhZGQgVSB0byB2
YWx1ZXMgd2l0aCB0aGUgdG9wIGJpdCBzZXQuDQpHb3QgaXQsIHRoYW5rcyENCg0KPiANCj4+Pj4+
PiArI2RlZmluZSBQQ0lfUkVCQVJfQ1RSTAkJOAkvKiBjb250cm9sIHJlZ2lzdGVyICovDQo+Pj4+
Pj4gKyNkZWZpbmUgIFBDSV9SRUJBUl9DVFJMX0JBUl9JRFgJMHgwMDAwMDAwNyAgLyogQkFSIGlu
ZGV4ICovDQo+Pj4+Pj4gKyNkZWZpbmUgIFBDSV9SRUJBUl9DVFJMX05CQVJfTUFTSwkweDAwMDAw
MEUwICAvKiAjIG9mIHJlc2l6YWJsZSBCQVJzICovDQo+Pj4+Pj4gKyNkZWZpbmUgIFBDSV9SRUJB
Ul9DVFJMX0JBUl9TSVpFCTB4MDAwMDFGMDAgIC8qIEJBUiBzaXplICovDQo+Pj4+Pj4gKyNkZWZp
bmUgIFBDSV9SRUJBUl9DVFJMX1NJWkUodikgXA0KPj4+Pj4+ICsgICAgICAgICAgICAoMVVMIDw8
IChNQVNLX0VYVFIodiwgUENJX1JFQkFSX0NUUkxfQkFSX1NJWkUpICsgMjApKQ0KPj4+Pj4NCj4+
Pj4+IFRoZSBsaXRlcmFsIDIwIChhcHBlYXJpbmcgaGVyZSB0aGUgMm5kIHRpbWUpIGFsc28gd2Fu
dHMgaGlkaW5nIGJlaGluZCBhDQo+Pj4+PiAjZGVmaW5lLg0KPj4+PiBPSywgd2lsbCBhZGQgIiAj
ZGVmaW5lIFBDSV9SRUJBUl9TSVpFX1VOSVRfQllURVNfTEVOIDIwIiB0byByZXBsYWNlIGFib3Zl
IHR3byAnMjAnIGNhc2UuDQo+Pj4NCj4+PiBXaGF0IGlzICJVTklUX0JZVEVTX0xFTiIgdGhlcmU/
IFRoZXJlJ3Mgbm90aGluZyBieXRlLWlzaCBoZXJlLCBJIGRvbid0DQo+Pj4gdGhpbmssIDIwIGlz
IHNpbXBseSB0aGUgc2hpZnQgYmlhcy4NCj4+IEl0J3MgYSBuYW1pbmcgcHJvYmxlbS4gV2hhdCBJ
IHdhbnQgdG8gZXhwcmVzcyBoZXJlIGlzIHRoYXQgdGhlIGJhc2ljIHVuaXQgaXMgMU1CLCB3aGlj
aCBpcyAyXjIwIG9mIGJ5dGVzLg0KPj4gU2luY2UgdGhlIHNwZWMgaGFzIHRoZSBkZWZpbml0aW9u
IGFib3V0IHRoZSB2YWx1ZSBvZiB0aGUgYmFyIHNpemUgYml0cyBvZiByZWdpc3RlcjoNCj4+IEJB
UiBTaXplIC0gVGhpcyBpcyBhbiBlbmNvZGVkIHZhbHVlLg0KPj4gMAkxIE1CICgyXjIwIGJ5dGVz
KQ0KPj4gMQkyIE1CICgyXjIxIGJ5dGVzKQ0KPj4gMgk0IE1CICgyXjIyIGJ5dGVzKQ0KPj4gMwk4
IE1CICgyXjIzIGJ5dGVzKQ0KPj4g4oCmDQo+PiA0Mwk4IEVCICgyXjYzIGJ5dGVzKQ0KPj4gRG8g
eW91IGhhdmUgc3VnZ2VzdGlvbiBhYm91dCB0aGlzIG1hY3JvIG5hbWU/DQo+IA0KPiBQQ0lfUkVC
QVJfU0laRV9CSUFTPyBQQ0lfUkVCQVJfU0laRV9TSElGVF9CSUFTPyBQQ0lfUkVCQVJfU0laRV9T
SElGVD8NCldpbGwgY2hhbmdlIHRvIFBDSV9SRUJBUl9TSVpFX0JJQVMsIHRoYW5rcy4NCg0KPiAN
Cj4gSmFuDQoNCi0tIA0KQmVzdCByZWdhcmRzLA0KSmlxaWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 06:20:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 06:20:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853800.1267152 (Exim 4.92)
	(envelope-from )
	id 1tLG5e-0006Je-Bd; Wed, 11 Dec 2024 06:20:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853800.1267152; Wed, 11 Dec 2024 06:20: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 1tLG5e-0006JX-91; Wed, 11 Dec 2024 06:20:54 +0000
Received: by outflank-mailman (input) for mailman id 853800;
 Wed, 11 Dec 2024 06:20: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 1tLG5c-0006JR-K4
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 06:20:52 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20612.outbound.protection.outlook.com
 [2a01:111:f403:2415::612])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 104cec5f-b788-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 07:20:50 +0100 (CET)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by PH8PR12MB6746.namprd12.prod.outlook.com (2603:10b6:510:1c1::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.19; Wed, 11 Dec
 2024 06:20:45 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%3]) with mapi id 15.20.8230.010; Wed, 11 Dec 2024
 06:20:45 +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: 104cec5f-b788-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QiNn6XWwFs4K5WNOKXIfvIn64ARBbRLHAOGvNEp9BAN7+I8PHUJUOaopDRzs76l5dn6RIPG9XjqnllwziHzBWKvfbhi3e8djh61M6T9+hR92aq3RzcybNZDYwamA0a35zKcGdqpX4Yxk86VnHudC+Lana1nB+eURCWwJuhpc1UzRvgGbzNrwuAxTWizBNjy+icySO4sCa72YvpnZEq2y76gNzKrXvVLSabRiMRflZE7C8ogyl8rdUyTxgHy0UFOl2tKZ9WvSxuE0zrYtORYTFnQg0P1FhIWy2UIl7xiSa5C5yywenrQ2OkmiPKfS75iaP2OzrEiJmSmhCqlN7KRwZw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=tVLQK9Pf9WHFE7oiO52yZyICFfodqAd77gyssO5JpEU=;
 b=ygpx+K+ZNhyv0rX8yJdrrXdrgAyYPknQDMwyPgPNP4sHcMC++eqd7F5c9hSu+0B1Q760668xgK3+DRLuKOJEVUp3Od1Ubj3z9aHtpv29W539BwmJUVkiS4nFjlGeLz0IESudgDOIujbwpGRhStnQfK1tscmafcyopLX+rZl5SVJVqV9lSB1NK8+zBsBeCJ1zQciCgXjaq7Li9CRwUhe1tey2jhSRRDCa/idBQ/SDeixcVcdyvFbHb/1jnniYP4QKZ8UiGDqW1PwsGHd3K1KiIN2udfkm2P7a0NVGthiXg1fxqsNmY41ckf59G90q+bfnexAtAcgP0vCyxghFfdUd1w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=tVLQK9Pf9WHFE7oiO52yZyICFfodqAd77gyssO5JpEU=;
 b=ZScLXRMTs20Jf8Z/A/ABJfo7knO6CdjBG6Xye/g0sWHnDxOvjFIq2Z/d8COMK0EVYzV2gF0AwUL/6w+kGPAgd+gTU8zw3rf8mmcxz2Kg1GaP0wvE0r9ZxjOKOJRq/9VcahyE6PZs/r0OZCKVvfUfDpoEtHLV5uMYZ6eey9RipMw=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Jan Beulich
	
CC: "Chen, Jiqian" , Andrew Cooper
	, Julien Grall , Stefano
 Stabellini , "Huang, Ray" ,
	"xen-devel@lists.xenproject.org" 
Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support
Thread-Topic: [PATCH v2 1/1] vpci: Add resizable bar support
Thread-Index: AQHbRIDgGHZ3ofHO0UuqqXvn+EZCabLd/CGAgAFgZ4CAAcmtAA==
Date: Wed, 11 Dec 2024 06:20:45 +0000
Message-ID:
 
References: <20241202060956.1124162-1-Jiqian.Chen@amd.com>
 <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com>
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8230.010)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|PH8PR12MB6746:EE_
x-ms-office365-filtering-correlation-id: 0a3021ec-7536-4394-4e42-08dd19abf2b8
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?RGNPeTVRcHBpK29rOWZmbTdCd3Ywa0pyNklXSnRhajUzbGVMNjd2N0wrQUV5?=
 =?utf-8?B?eHBNRWpMSk9hUENyT2V5MElidFBseG9jYkx6SXZ4RXRNd2ZKNXNjb2JDOXI3?=
 =?utf-8?B?QWxBdGNTeks3UEQ3Qmx4MHgxTXZ4aENzaGF0NUorS3hpT2hVNHNQR3hqdHBl?=
 =?utf-8?B?SVhlWEc2T3kzWWR4aVBiUHRhRjBlZW9kMitmNWJIbGVjMGxJUDFmZ3IzbXAx?=
 =?utf-8?B?ZjFpSUxuTi94NkVGOXNPTjhnMk1mZ3dXdnJEbEt1dlpZZlJiUnRyeG5oa215?=
 =?utf-8?B?QUUrMldDNnpsVDBDYnlRaGJZekpxSzQwQ1NZSThvUk5pcjdIWEpFcFJwbGpZ?=
 =?utf-8?B?bXJIM29xWGVwWVI2Ym9Cbk9LdzRrdTA2SzRScFNHU2xUY1EvSHMzR3pPaXll?=
 =?utf-8?B?QldtZWlhc1RkRE1UbEVGMSs3YXM1bmpjUFhJS1pnTkR3NXcvZVFVb0swbUhn?=
 =?utf-8?B?b1BFZllXVEhyeGJKK1daV21YMi9UQWxkRnMwc3dUMjNKMENIeDROVjVBbEpk?=
 =?utf-8?B?enI5TkM3OE40dzZDMGcwcDRVMnFSYUt1SWNYd2w2RUllNFYzNkVzMXYycS9r?=
 =?utf-8?B?Z0IyeGh6R29ZQWZPek1pemlScGlqN2VGVkVYdTdMWG0wVnlja3poemtFNUx6?=
 =?utf-8?B?OVlTRE5paGlQVU0wOGZnS0hNZng3cXJ5OElqU0R4V2x6dUtQWDZsQ2IyM0FE?=
 =?utf-8?B?b1lYYWlmYjU4SFEzK3c3QWI0S1ZTWDA0SGx5WjIvZERMKzhVTG1ac0tCQ05z?=
 =?utf-8?B?ejR0dDRKcEZlWXFXTDhNWHczTE1mR3dzWXJ5V1NEODlXSzBNejRJODY1c2hI?=
 =?utf-8?B?UUJOOG1jck5TU1hpbkUvWXlDYktadjhpaHZidmhnTitLOE50V3ZoNTd3dnAz?=
 =?utf-8?B?a000RUhMdS9mY2VacmtLSGJGKzZrMUl1TXNlaDd5ei9LTmNGaGJTTXZ5RUd4?=
 =?utf-8?B?bjdkV1c4RVFmeUpIZS9BYzBUc0I5Yzh2b2V5Z2MzUDRCY2ZSSkJxVi9vcXlL?=
 =?utf-8?B?bnRIdldqd2UvNE9xd0xCbnZIQ0k1ZGgxa0N0QU1qV3JseFdKOU1qRFJHNk9y?=
 =?utf-8?B?ZytFRzh0VE1wUDdZUGFPYlpTZ3F5L1VVaGcyM3k2ODVsdUdyUUtNTkxNdGhG?=
 =?utf-8?B?VFVWQjAyYmVxL0lxSGVlOEhHODNKeWdYVHVUMWgyUUhIYzNLRmV5ZjIzOVdL?=
 =?utf-8?B?QkoybnNYcHlqVzFtMUxpT0xDa1NGMTMxUEtTWDhwSjc3NGo1UHFJb0YwSlEr?=
 =?utf-8?B?aTFvWVJNZjBCdWFmMXYrT3o4ZUhDakNBSEpGdVVqUnA0elpuOGhHaitvUStx?=
 =?utf-8?B?eTBCLzBmS3huc2RuUXNQaVp1OEhMQzVSRHhERDR5T2xhQmlEZkJjZGFyY0Ri?=
 =?utf-8?B?eHY3bWdVOVNJa3VmZHFNVzdNa3R5cVF1b3VHNlE4U0JvODJROUNBRisxcTJi?=
 =?utf-8?B?RE9Zazc4Z1lJd3RxTHVzQi9MSUZ4dDl6NlpHa1NtN1VsV0pVcGYvNStiaDFy?=
 =?utf-8?B?R1FqNmp3ZHUwRGt1ZjNTSE52THc4OTNSZFlLejd5blZRUEFxYXhhdTlZbVFS?=
 =?utf-8?B?MkE0MnpjMVRJSUViOVNTSDRZZXpOMW5uWFdPT1pBSlkwelp2aHJqbVVsaTRq?=
 =?utf-8?B?WGpITm5VaktDVGlWU3ZOeFhzdGF4K2p6cS9JZTVkVUdwTXJVKyswTW9OWXg3?=
 =?utf-8?B?a3ZsRStkcVJhaW9kQnZtRGlpTWRJZGFpQUNnMnJWQUhMZFZVRUxGTldWaXdv?=
 =?utf-8?B?NGNFNmthOGFwb3JLRHMvdlI0WjlPQlJzd2pBWU1Fd3lVemZQZmpFcFZmU2JY?=
 =?utf-8?B?dUgwc0F3TEQwTEJBRzNUZ3NpYzk1UlU1cXJTUWJkeWg0d0R6dkpSdWpGRWJv?=
 =?utf-8?B?VHhFdXlxTXJybk9IbWJ6bWFxOHVJdzZXS3B3V3Vzc3ozUmc9PQ==?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?WURWbVB2ZmdkZUNGdWEvK3VHZGQxVklPWWc5V0g0L1grNlltT21qcVFJNHRh?=
 =?utf-8?B?M0RLUjhjaE1xZXdWZm4vN01zZ1RZR09KZTN0RWtkbXNuSVB1VDFTYUwydUVm?=
 =?utf-8?B?dDRjaTE2ZDJqemxQc2NybUg3ZGpuUEk0Y0FkSjBlTXBLREVhTGc5UElrVFpU?=
 =?utf-8?B?dHg1c3RXZFB6M0M3YUo4VWpOeldQMG85blNzRU9QcnlyTHBFcWo3ajluYTdS?=
 =?utf-8?B?MFkvSDJSYjNFeDEyZWs4MWtpZkZuVERETVd0NzJlSDBjd2VjYzVycEhQenE0?=
 =?utf-8?B?eUdRWU9QS0VXL2JmYkNWcFNRb1NGSDJWbEsvZENEMVdZTHpTVzFMUjR4M0lC?=
 =?utf-8?B?S0l2bHNyWG0wZXFSVk5DQzZkZEVtVkdWekhmK3BmY2Rta21TQ3VQNEtjb29O?=
 =?utf-8?B?Ri9YamhESjFreXFoWnZ1YjVCbC9rNDJHNGp3UlU5NndzdzhMMlNvZU9MZ2Zy?=
 =?utf-8?B?VW5oV2dJbkxqZ0paaVhzZmRIMFlHNGtPaStJblg3M0J2cHhNbVptc0twSkxE?=
 =?utf-8?B?bXBMbnY2bUZsdkZwSHZQYTJaZERyUGpOcEZrMFBiYlYyWlZzbWpSQ20vNjQw?=
 =?utf-8?B?VlhFa01WVFFKLzN2ZllJaGN1emEyNTBRRCtTUXFaN2MzellhR1orQllNT2c1?=
 =?utf-8?B?Tlhoem42SzNhTTU2MDVneldLVndlTC9qalFMdzUzc09qRlZjUDVYN2gvSEJi?=
 =?utf-8?B?K3pNK21rd1JlSm5OZFkrNytKWWxQOGtMeEFBekdrRTZqOGNTeVdZa2F3bmxr?=
 =?utf-8?B?NFZIbXRRMElhOG1WQWZLb2xqdCs5aEo2YjZnUXpVN0Uzd2hVMXlkeFd1UVJW?=
 =?utf-8?B?NEpVd0FUMmhCSXVta0ZNZUNBR1llSGNLTGZsTy9TRkN6aTl1a2pEa3cyRGF4?=
 =?utf-8?B?bXp1VFFHcDc1MlcvcG1oajE1ZWQrZ2NSZU5mV0t5ZWtjeXpKY0lqRzFPYWRB?=
 =?utf-8?B?MWgvVEh1REdDTm9JdFNtWllyM0NIZ1E3TDFmd21WRXdqUDVGM3BSUnFkUVRo?=
 =?utf-8?B?LzZKR3hLelBFMnhWUkZPTGFWNXFXS1BHeUxQb0tIZ0hsQmJyUzR6MExTZVRk?=
 =?utf-8?B?MzEwMmoxbXpXSHVxT1ZlcVNya0lSMGFMZDF2YnpkZFJzWUd0Z3pmNUoyaDBx?=
 =?utf-8?B?M0UrRW9GdmZSU01Ib0d2N3NlWEJyYWNVTnhlUWoxRHVMdnZFWVZQeHJIUEZL?=
 =?utf-8?B?RDl1QXpzZDkrRTBTNGdvMzNkWGk0VTVMTG5qbm5pVTRYSFlLNTFtclA1d3BH?=
 =?utf-8?B?ZHpscWt1Nm9Ka1c3SU1Ma3FKSWVuQk5lY0NOTjF1TDBoTUpCOGVwdEFJb2dh?=
 =?utf-8?B?MHIrTVdVdU9XR0ttaUY4MlpvWFo3RXNNNGF2aUtvM3FjaWt1anhXMytyYTlS?=
 =?utf-8?B?bGhubGdoZmJKZUFnb3dFUlFmVGlseVJaWUFnWlNpTlh0b2JrSzQ2V0tQaHNs?=
 =?utf-8?B?UE1pcUZZNzNEQ04zclVwZXpFVVprbVVzakp0QWZ0NzBXVFBOanF4S3FEbzJC?=
 =?utf-8?B?Z0RRTTZvNkw1Y2ljRVZOTWFJMURPa2NCaHlmb05ZU29HeVdGSElqUGNxQVUv?=
 =?utf-8?B?U3BrWmt4ODVrY0NWNm82cnZXWUdtK2lwZW9CQWpWUjVjd25velZSUFUyNnRF?=
 =?utf-8?B?YXFjd25UVjVMMyt2bTNRdG9JNWxuRHV5cmZCT0dWOHZsV29WcmFuR3hydmlm?=
 =?utf-8?B?N1p1WFZPTkZxYkJkdWhLcVdNNmNHREM2bDZVK3Fud0lkeEdxZ1VjL3dqcTRh?=
 =?utf-8?B?N0xOYXBMZUtyV2NYbXBJYzhWOEtHUEUwVEk1RGZYSDVsbUtaVUl3WW1YcGtY?=
 =?utf-8?B?SVd4N0lOVW4wc2lyMHdLMXlQVVhzcnl4QnVHS3d1Q3hUQmhCVGZRcm1yYTBS?=
 =?utf-8?B?VFk3S3pUU21YVlVPRlg2SVVnZVl2OFB6eEhZVk1PaUk4SFRaZ2Q0M2JwWmlV?=
 =?utf-8?B?U2d1Yk5ZSXZEQ1BicGh0Y1dwbkMvWFRkR1EyeWs3YnNQMTRwSlZKWVZ0REhY?=
 =?utf-8?B?YklOZFNKZHc0dTB1S0dvN0JOWExuR0RodjhKR09NUjNJd0R3TS9GLzNxOHV5?=
 =?utf-8?B?Q2IxYTVlcHg0M09QbThCTEpCR3ExSmViUnpnUmlMUlQvaVBIbHhEWkthdkpo?=
 =?utf-8?Q?+Fr8=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0a3021ec-7536-4394-4e42-08dd19abf2b8
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2024 06:20:45.8312
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: c3fErXYxxWCyC0laqPlGUYuozj2hhd+eMIBzh6eIXLjAe4lqW3C3lQ26nmGAtqZyM0IQYl08I1xjxwNkSM1bkw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB6746

T24gMjAyNC8xMi8xMCAxOTowMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToNCj4gT24gTW9uLCBE
ZWMgMDksIDIwMjQgYXQgMDI6NTk6MzFQTSArMDEwMCwgSmFuIEJldWxpY2ggd3JvdGU6DQo+PiBP
biAwMi4xMi4yMDI0IDA3OjA5LCBKaXFpYW4gQ2hlbiB3cm90ZToNCj4+PiArc3RhdGljIGludCBj
Zl9jaGVjayBpbml0X3JlYmFyKHN0cnVjdCBwY2lfZGV2ICpwZGV2KQ0KPj4+ICt7DQo+Pj4gKyAg
ICB1aW50MzJfdCBjdHJsOw0KPj4+ICsgICAgdW5zaWduZWQgaW50IHJlYmFyX29mZnNldCwgbmJh
cnM7DQo+Pj4gKw0KPj4+ICsgICAgcmViYXJfb2Zmc2V0ID0gcGNpX2ZpbmRfZXh0X2NhcGFiaWxp
dHkocGRldi0+c2JkZiwgUENJX0VYVF9DQVBfSURfUkVCQVIpOw0KPj4+ICsNCj4+PiArICAgIGlm
ICggIXJlYmFyX29mZnNldCApDQo+Pj4gKyAgICAgICAgcmV0dXJuIDA7DQo+Pj4gKw0KPj4+ICsg
ICAgY3RybCA9IHBjaV9jb25mX3JlYWQzMihwZGV2LT5zYmRmLCByZWJhcl9vZmZzZXQgKyBQQ0lf
UkVCQVJfQ1RSTCk7DQo+Pj4gKyAgICBuYmFycyA9IE1BU0tfRVhUUihjdHJsLCBQQ0lfUkVCQVJf
Q1RSTF9OQkFSX01BU0spOw0KPj4+ICsNCj4+PiArICAgIGZvciAoIHVuc2lnbmVkIGludCBpID0g
MDsgaSA8IG5iYXJzOyBpKyssIHJlYmFyX29mZnNldCArPSBQQ0lfUkVCQVJfQ1RSTCApDQo+Pj4g
KyAgICB7DQo+Pj4gKyAgICAgICAgaW50IHJjOw0KPj4+ICsNCj4+PiArICAgICAgICByYyA9IHZw
Y2lfYWRkX3JlZ2lzdGVyKHBkZXYtPnZwY2ksIHZwY2lfaHdfcmVhZDMyLCB2cGNpX2h3X3dyaXRl
MzIsDQo+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWJhcl9vZmZzZXQgKyBQ
Q0lfUkVCQVJfQ0FQLCA0LCBOVUxMKTsNCj4+DQo+PiBUaGUgY2FwYWJpbGl0eSByZWdpc3RlciBp
cyByL28gYWl1aS4gV2hpbGUgcGVybWl0dGluZyBod2RvbSB0byB3cml0ZSBpdCBpcw0KPj4gZmlu
ZSwgRG9tVS1zIHNob3VsZG4ndCBiZSBwZXJtaXR0ZWQgZG9pbmcgc28sIGp1c3QgaW4gY2FzZS4g
KEFuIGFsdGVybmF0aXZlDQo+PiB0byBtYWtpbmcgaGFuZGxlciBzZWxlY3Rpb24gY29uZGl0aW9u
YWwgaGVyZSB3b3VsZCBiZSB0byBiYWlsIGVhcmx5IGZvciB0aGUNCj4+ICFod2RvbSBjYXNlLCBh
Y2NvbXBhbmllZCBieSBhIFRPRE8gY29tbWVudC4gVGhpcyB3b3VsZCB0aGVuIGFsc28gYWRkcmVz
cw0KPj4gdGhlIGxhY2sgb2YgdmlydHVhbGl6YXRpb24gb2YgdGhlIGV4dGVuZGVkIGNhcGFiaWxp
dHkgY2hhaW4sIGFzIHdlIG1heSBub3QNCj4+IGJsaW5kbHkgZXhwb3NlIGFsbCBjYXBhYmlsaXRp
ZXMgdG8gRG9tVS1zLikNCj4gDQo+IEkgZG9uJ3QgdGhpbmsgd2UgY2FuIHNhZmVseSBleHBvc2Ug
dGhpcyBjYXBhYmlsaXR5IHRvIGRvbVVzIGJ5DQo+IGRlZmF1bHQsIHNvIG15IHByZWZlcmVuY2Ug
d291bGQgYmUgYSByZXR1cm5pbmcgYW4gZXJyb3IgaW4gdGhhdCBjYXNlDQo+IChhbmQgcHJpbnRp
bmcgYSBsb2cgbWVzc2FnZSBpbmRpY2F0aW5nIFJlQkFSIGlzIG5vdCBzdXBwb3J0ZWQgZm9yDQo+
IGRvbVVzKS4NCg0KSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseS4NCkkgbmVlZCB0byBhZGQgYmVs
b3cgY2hlY2sgaW4gaW5pdF9yZWJhcigpOg0KICAgIC8qIFRPRE8gKi8NCiAgICBpZiAoICFpc19o
YXJkd2FyZV9kb21haW4ocGRldi0+ZG9tYWluKSApDQogICAgew0KICAgICAgICBwcmludGsoIlJl
QmFyIGlzIG5vdCBzdXBwb3J0ZWQgZm9yIGRvbVVzXG4iKTsNCiAgICAgICAgcmV0dXJuIC1FT1BO
T1RTVVBQOw0KICAgIH0NCg0KPiANCj4gTm90ZSBpdCdzIGFscmVhZHkgbm90IGV4cG9zZWQgdG8g
ZG9tVXMgYnkgbm90IGJlaW5nIHBhcnQgb2YNCj4gc3VwcG9ydGVkX2NhcHMgaW4gaW5pdF9oZWFk
ZXIoKS4NCj4gDQo+IFJlZ2FyZHMsIFJvZ2VyDQoNCi0tIA0KQmVzdCByZWdhcmRzLA0KSmlxaWFu
IENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 06:37:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 06:37:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853815.1267163 (Exim 4.92)
	(envelope-from )
	id 1tLGLs-0001Dd-Mf; Wed, 11 Dec 2024 06:37:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853815.1267163; Wed, 11 Dec 2024 06:37: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 1tLGLs-0001DW-Ju; Wed, 11 Dec 2024 06:37:40 +0000
Received: by outflank-mailman (input) for mailman id 853815;
 Wed, 11 Dec 2024 06:37: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 1tLGLr-0001DQ-C5
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 06:37:39 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20625.outbound.protection.outlook.com
 [2a01:111:f403:200a::625])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 689efd9a-b78a-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 07:37:37 +0100 (CET)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by PH7PR12MB7987.namprd12.prod.outlook.com (2603:10b6:510:27c::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.20; Wed, 11 Dec
 2024 06:37:31 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%3]) with mapi id 15.20.8230.010; Wed, 11 Dec 2024
 06:37: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: 689efd9a-b78a-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=pvsSrLexAzEiFpstDdjzqRPTkd4n+PKrcSHcBr6X8Vyp3XfG6XkHTAoS8iWwiVNRjwsMFxxU5e1ZxMVOh56n873Mx2GtwBRfSR2cHx1zNqUVuTeg09hV1p9NSv5STtBJs48CFlegN6yLCN6Duq/sDKsQu2GkNg90XvH3GiyP/PcsPi1O3R1Nu5CU7e30J5XLMJnoX8UWSEjPYfd8sl3qqOHmUYPrPv0Oc7U8M4bbAjKnvRAY59PvAt0bLTqfddRSrN6Y4+GfcEcMUNvznDip/0cSv13zTN7hm3L4Ky0GmzQjpaEJB7VIa11pMyTHJI827kKIsqZ9fa8ZcwdwNXpU1A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/6H1DN4Vl2+itDT8nAUxwUcdyfzbprc+cQRbD0aMLq8=;
 b=YqKgdF+TSisZ7aEAwV4M9/cPkJ5Xo2/5ACd+bUifyar/gHBP227GANZTJ3BaoRgcIq519cMXXfZGgxP2V0t+QV/bJSNyY7Hr/7ou+wKlzlV447Kv7Yx/J+oE3y1BDUjRALUW/bhkQuLhsJqw3E9iq3gIZ1OufnQ4PYS5IiFklI5a22FVQCe68btB2QmA528T815FhiuzL904sQpzOtWnoFDmPhbe/u47Oc0XQy+udMDjv/ydMBP0KGLgvEbtWfFfJWOl4LfYhbQt1I470HYGjDf6CHgC0uCvYygb3yENeBzSImPGRwdWs5TJlsStea5tnUTQMGmcfRfo4PumGL7b0Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=/6H1DN4Vl2+itDT8nAUxwUcdyfzbprc+cQRbD0aMLq8=;
 b=TrtI24T0iwuucy52fqhZoCf+oQYk58GHKcYfWi0YMySp68muy++d0pZvdB8smiFNG/nNxiiXg7UeZcvl/EjZGxOUFv4eLMjcLTJmFg9/4AGWsMoesyLrvCJF5McwpxAXG/T958KhlcOdwhkfAEGKvV7Z/UG++ZNrv5X4d8AKrzA=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: Jan Beulich , Andrew Cooper
	, Julien Grall , Stefano
 Stabellini , "Huang, Ray" ,
	"xen-devel@lists.xenproject.org" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support
Thread-Topic: [PATCH v2 1/1] vpci: Add resizable bar support
Thread-Index:
 AQHbRIDgGHZ3ofHO0UuqqXvn+EZCabLd/CGAgAGXh4D//4qBgIAAiieA//+hwICAABlHgIABx3CA
Date: Wed, 11 Dec 2024 06:37:30 +0000
Message-ID:
 
References: <20241202060956.1124162-1-Jiqian.Chen@amd.com>
 <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com>
 
 <1e0576d9-400e-4483-8dd1-061e215a00cd@suse.com>
 
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8230.010)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|PH7PR12MB7987:EE_
x-ms-office365-filtering-correlation-id: 3df5ebf4-e0bd-4807-c22a-08dd19ae49d1
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?RjQvbll6V1JBcnZSMHppNDVYRWlGd0Nwa1kxQ2RLNHBUQnhBRjhwRCttcHlj?=
 =?utf-8?B?Nkp0emllcWVkTTFFRmRlNHdoNGwyN3dRTm9CaW1OSTc3U3c0cGxadTZlalJX?=
 =?utf-8?B?MHlDaHEydk54dXZySWRxRDdoNCt5aHdtMURYYWpXT00rOXBEMkMvYlJQbjhw?=
 =?utf-8?B?VTdEV20yb01IbWRqSmFyY2JPNktZQkQ4Vk0zbVVRMllQM3RNdFE2K0ZRaCtr?=
 =?utf-8?B?N2J1b3BnenQvR3pwZUNxbVFTQXZsdnJUSWI4WXJlQXpINDB0NTMxVjRjUTBB?=
 =?utf-8?B?aHV2WnpCeUpJeWFRMEVxVHdaME1XNC9veGtobXRKNEJuSWNrbWNMaGN4QVph?=
 =?utf-8?B?ZzVTUCtQeGdXcGJrU2ZLN2VsSGVjbUVXbHltWVU5d1B6VDVLaHBtL1Z6ZDRi?=
 =?utf-8?B?OTljMkVSVTZ1M0ttL0dKTllJZGkyQVA1WjdEQkRjRnE5QW1zdldVdGEzQXNW?=
 =?utf-8?B?Q01TMWJYU3ZRVzVCQzR0VTNsVGFpSVNJOWFCWU1wTkZLTWlnRWlKMXV3cWdx?=
 =?utf-8?B?ak5DNzZxV2pQZ1Jhd3cwNkczWVNVOGpsSFZyNVRJNE9xQ2xQeWlaeTVzTDF2?=
 =?utf-8?B?Q2tVSzIzMHVQZ09YUXIvbXJqd1hYSEhmeUVORm5kYSt6Z0VTd1J1WUtZb1RI?=
 =?utf-8?B?RjYrV004S1F4ZFlNazFmSEJxZWR2eWd6SUZ4OVQrRHoyYkF1Y1F3M3dFbE5F?=
 =?utf-8?B?aUdWb3gvUTJpYklMZXZCNWtVWkZYMFhxNHU3R3ppaFZQcllFdUU2aERHNzE3?=
 =?utf-8?B?VXU4bTZsd0R5MzdGRWhyTndYSVZWbWxKaTA2Y2ZxUTQrU1llWEhYYnRQTGJ2?=
 =?utf-8?B?T0ZFb1hIV1hRRXdmYTZuSDE3UWVCTnZqM2dTMC9jaDkzejcxRXpzSWxQVThF?=
 =?utf-8?B?QUdaaVJiTWgvUXBFSjh3WUREWkJZMjJQek5VSm1ERHUwNWpUaWtmdXJkWWRy?=
 =?utf-8?B?YnlRNWpOemNuVU43Z052NHJDWHVGWnF6L09ETHN3Ukt6U1dlRFZ2SzdRT2Ez?=
 =?utf-8?B?UXNIVHlQbWFscEFQZmx4N1RFN2hWdXk5UWxXZkpJb3g5NjIxTFBoVks5U0Zz?=
 =?utf-8?B?b2p4K1lnRXowMFJsV2RxRTQ1cVFqbU9CemptN0VlQytMcXkyQ2h2cm5HK2px?=
 =?utf-8?B?UHFyQlBaTEQvT1pxbGpkSjcrdUt1cE42NXQ5YjF0TmJwU1QrY3NJSVZFUXor?=
 =?utf-8?B?Q2hRMHZvV2FkL09oeVVGSWxGZ2lJZ2RrS0FNSlJRQzBWc3V1SVh6dFJrR3pj?=
 =?utf-8?B?M3F3SUk4WGFzcjduMzNpN0pYcndWa2JFeGVQV2kvWlJreXpDaEVuSzhCNXQx?=
 =?utf-8?B?OTM1anQwRzlGZHdvaEt4OU5lQVRVRjZuUmhoZG1ia1A1U3BkUTI3clQrVlN5?=
 =?utf-8?B?RXZDR1BJR1pmZlhrUDBvV2tydVpPeElCN2xUb0s5VUxKRUdrN045SGxod2JZ?=
 =?utf-8?B?eWczVFdIcTdiYjBwa1NnRDFaVjRPQm9zYzRlL0k5NjVORXpITkgzRU1MMkF0?=
 =?utf-8?B?cXQ1aWVCV2I4LzVXR2pPeld4UTI1R09EUzRnWW9CbmVTSkkwQktTZTFiWEJQ?=
 =?utf-8?B?bHc2MG9wa2YzVllRSmZUL0xoRzZRZnV5cFhsbC96ZVBOTjlNL3ZBRitycC9T?=
 =?utf-8?B?cjF0c0tXQXNOMjRIdUNkUVJneG9ndjl5Y0lwOEpxR3BBZGRzUENhY2toUUt3?=
 =?utf-8?B?ZkY1WWVGcFdyb2tWNW9wOUhZY0hqeXdqTzAzZmlBU3BkRFg1K0ExK3p1M0pp?=
 =?utf-8?B?ZkhPbUk2c2MwcHVIZzBNbkJYVFVvejMxdElYM0xySTNvcEJaWVhlanBxZDd6?=
 =?utf-8?B?K1hDbHVGMlI2VmJCS1ZYVE1KNnpTUldRbUJxOGdQNjBTMXNvU0NaYUdmWkha?=
 =?utf-8?B?dm1xK2dRNzZuSEZpY1BPeVJFbituSG1LNW1GeSttcEZxV1E9PQ==?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?U09iSFJDWEQxWGFmQkdZaGlYU1FzVEhzZW0ySk5NcFZBSnVGcDd1UzZ6UldU?=
 =?utf-8?B?VUhPTURrOTdla2c0Wk93K01UMzl1NDlCK0xhVnQvcjJxVjF5bE9NSnNxVGcw?=
 =?utf-8?B?dWtVSCszTTNUdmx6bmYzRXpYODRFd1Byc0JFTjRUcnJ3dGw3ejZSem5abWxO?=
 =?utf-8?B?ZnBzd1QyTjRDVDZJY1BGcmVzZk1WODhKUmg5Ni8zRDZYQ0EwRlZrSG9KelJQ?=
 =?utf-8?B?cTVCc1FNRkcyeTdYM1RaaThQSWliNFlMUGtxWE9JV3VZaldFaU45MFhoQUY2?=
 =?utf-8?B?L05FRXpkSjlYaDdBM3FLakVVaSt0eldzcU1qS0dLUk1yS1ROcC9wY1ErSVpj?=
 =?utf-8?B?aU91VFczOG12bkRObTFBUWVqWjBpUmNEOHU2K1JjTGh5c2VrM1BsTlg5RU02?=
 =?utf-8?B?VlRoQ011aWFJQkJGSEthY1lnNTdBU0hpL2RyNkxRV1IwNnA2Rm5IUTZpRWRX?=
 =?utf-8?B?dFhRdE9KYWJETzh6a0xiaStEclRCQkN1c1ZUeTVWYW9EeXJhYWNteHF0Y0s1?=
 =?utf-8?B?ZnlSdVY1cmhvcEFWSGtrb1ZnSXBVc1RDNU5DcU1JVTk2bDhuTWhOQXFON0dt?=
 =?utf-8?B?U3hGdnNHYzQ1SjB6OGhDNVlsWGlEMkwzY1ZYdlkrOW55N0pkb013TjFvdXhS?=
 =?utf-8?B?ZVhhb3ZUMFJXUFZvMTFpUysvWk5HS2pORFdMLytBTVdHaGhHNmtUS004ZGNv?=
 =?utf-8?B?VGtlaGYzYzZvOUJHbWxKaCtNcS9SeW92WktZMDlxTEFWQkMyQTIvZzluYmlO?=
 =?utf-8?B?Y3dOeDZMemh1cDhwVjlXYTBSdGcrVWlwT1BEL3pXS3lIdWVwU0lQNUQxamF1?=
 =?utf-8?B?KzhMYkJPYmxqaElrNVUvSVpFZE5ja2UzOG9JcVJHVXNaMEZKYU0vdlR6ek9K?=
 =?utf-8?B?bFJ4TFBRN2FLclYzT1Z2NlpaeXJpT3Mvb2d6SSsrNEhmZDFhSGphOHRzUDRM?=
 =?utf-8?B?NFE1by8wdXFMU21EWXpiWW8relQvSUlyVEVDMk4xcGQwZURoTEFQTm9KSTIx?=
 =?utf-8?B?WnBkUkd2Y0FUZnZFQjBvTXM4dnNRLzlYbW1iaCs0cnlVTW4ybVZlYU1rWFp4?=
 =?utf-8?B?QmxlcFlHMHd6aDlmVWtYYmY4SUhiUklpMThmWWtmMUdVY0tCcWdiQ1lPUS9X?=
 =?utf-8?B?RXpia0tjQkFCQkh4NTdWR1IvV3JqWUVnbEtxM0xFcnRxS0FLSUplRGdrWU0v?=
 =?utf-8?B?Qy9LZ0Y3VnFCYU1RV3JCY1hSRHFTdnpSVXBhZkpoZlFMbWczYTVPK0IwNjNY?=
 =?utf-8?B?TTBFRWs3SGljQ0ttUXBXRHJNL21xU21wcVVsYWE2b2syWFBUcXhxb0RjTnFw?=
 =?utf-8?B?VXZRa1d3a1dxSVllaDlMYjhLVmpPWTFXc1dSVkJmaTlmTWRCUmdZZWNZWTN6?=
 =?utf-8?B?bzNUQ0U0TEhiSldmb3RrSXlKNE1RcXlCRW9HdXBlVWI0UUdCTS9hNjFhRGJu?=
 =?utf-8?B?bzc2WFozTkxBcU5wRTMvUHN3cCtEeHJ0ZFFzUlFwVUtQMmlYUXh5cTMvYVp4?=
 =?utf-8?B?RVoreDFRSlJod1lIMXFQTSt0WnlnT05aVHI2Mi9zMWVqRjdNUGYzVHBtbXVG?=
 =?utf-8?B?Qk1DcWRYOEpRVUFJRENqMmhTTWZxK2hJQVl5M3dBQUtxVmpNOHJpbzB4RE9q?=
 =?utf-8?B?ZmtkeWF2NmhjNDNITlBCRGdpWUlHdmNnRXlDeGRaUGNNUmI0RW41UndBOEdE?=
 =?utf-8?B?ZGFmRnppSld1aFhDQ0s3OE9UemFKOTRUTWRORnlKeUZrY1loTVY5L3VwZU9t?=
 =?utf-8?B?WnNWN1hteUJPei8vL1ZxMSttdHBXY1d3L0JpZDJlT0d2dXhRcmZlWWZBV1hG?=
 =?utf-8?B?Zm11TFc2YnhqYXZaWk1ZTzlxbXJvc1pMd0dPU1RON2RoRDlGTjNzT3l5a2ts?=
 =?utf-8?B?SUlLcG8vMHRONGlabTJZaVlGVHZxVk1LVlBhb09wanh5c0FVMGxmemRQOWdS?=
 =?utf-8?B?bmpBdkI5YmdybXU5VFNnWHNIWVdUMDlqUkEvK0xwWXhZMWFzamhjM0RhRVNS?=
 =?utf-8?B?K3JWUlh6MUpsaS85anM3OWxRU1RoOEx3RVd1anZKNkdpUHRrK2hxNW1lMk96?=
 =?utf-8?B?QThmb2lzd1pKRlVYdlR1dE1aNXZPaU5razNxeFB6emU0K3RqQmtCblNEUktj?=
 =?utf-8?Q?h7UI=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <93CD2AB74CF2EB49AD12E09410402B17@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3df5ebf4-e0bd-4807-c22a-08dd19ae49d1
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2024 06:37:30.9932
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 93FiICccmjuGnyfkp5ZbkV2qeHjYoe9osXeLKC1sPXkuTYLDqem/7FwEah061tWjxVLMYHbANb2S9SZIuJlEFQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7987

T24gMjAyNC8xMi8xMCAxOToyNSwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToNCj4gT24gVHVlLCBE
ZWMgMTAsIDIwMjQgYXQgMTA6NTQ6NDNBTSArMDEwMCwgSmFuIEJldWxpY2ggd3JvdGU6DQo+PiBP
biAxMC4xMi4yMDI0IDA4OjU3LCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+Pj4gT24gMjAyNC8xMi8x
MCAxNToxNywgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+IE9uIDEwLjEyLjIwMjQgMDg6MDcsIENo
ZW4sIEppcWlhbiB3cm90ZToNCj4+Pj4+IE9uIDIwMjQvMTIvOSAyMTo1OSwgSmFuIEJldWxpY2gg
d3JvdGU6DQo+Pj4+Pj4gT24gMDIuMTIuMjAyNCAwNzowOSwgSmlxaWFuIENoZW4gd3JvdGU6DQo+
Pj4+Pj4+ICtzdGF0aWMgdm9pZCBjZl9jaGVjayByZWJhcl9jdHJsX3dyaXRlKGNvbnN0IHN0cnVj
dCBwY2lfZGV2ICpwZGV2LA0KPj4+Pj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB1bnNpZ25lZCBpbnQgcmVnLA0KPj4+Pj4+PiArICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB1aW50MzJfdCB2YWwsDQo+Pj4+Pj4+ICsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHZvaWQgKmRhdGEpDQo+Pj4+Pj4+ICt7DQo+Pj4+Pj4+ICsg
ICAgdWludDY0X3Qgc2l6ZTsNCj4+Pj4+Pj4gKyAgICB1bnNpZ25lZCBpbnQgaW5kZXg7DQo+Pj4+
Pj4+ICsgICAgc3RydWN0IHZwY2lfYmFyICpiYXJzID0gZGF0YTsNCj4+Pj4+Pj4gKw0KPj4+Pj4+
PiArICAgIGlmICggcGNpX2NvbmZfcmVhZDE2KHBkZXYtPnNiZGYsIFBDSV9DT01NQU5EKSAmIFBD
SV9DT01NQU5EX01FTU9SWSApDQo+Pj4+Pj4+ICsgICAgICAgIHJldHVybjsNCj4+Pj4+Pg0KPj4+
Pj4+IEkgZG9uJ3QgdGhpbmsgc29tZXRoaW5nIGxpa2UgdGhpcyBjYW4gZ28gdW5jb21tZW50ZWQu
IEkgZG9uJ3QgdGhpbmsgdGhlDQo+Pj4+Pj4gc3BlYyBtYW5kYXRlcyB0byBkcm9wIHdyaXRlcyBp
biB0aGlzIHNpdHVhdGlvbj8NCj4+Pj4+IFNwZWMgc2F5czogU29mdHdhcmUgbXVzdCBjbGVhciB0
aGUgTWVtb3J5IFNwYWNlIEVuYWJsZSBiaXQgaW4gdGhlIENvbW1hbmQgcmVnaXN0ZXIgYmVmb3Jl
IHdyaXRpbmcgdGhlIEJBUiBTaXplIGZpZWxkLg0KPj4+Pj4gVGhpcyBjaGVjayBpcyBzdWdnZXN0
ZWQgYnkgUm9nZXIgYW5kIGl0IHJlYWxseSBoZWxwcyB0byBwcmV2ZW50IGVycm9uZW91cyB3cml0
ZXMgaW4gdGhpcyBjYXNlLA0KPj4+Pj4gc3VjaCBhcyB0aGUgcmVzdWx0IG9mIGRlYnVnZ2luZyB3
aXRoIFJvZ2VyIGluIHRoZSBwcmV2aW91cyB2ZXJzaW9uLg0KPj4+Pj4gSSB3aWxsIGFkZCB0aGUg
c3BlYydzIHNlbnRlbmNlcyBhcyBjb21tZW50cyBoZXJlIGluIG5leHQgdmVyc2lvbi4NCj4+Pj4N
Cj4+Pj4gV2hhdCB5b3UgcXVvdGUgZnJvbSB0aGUgc3BlYyBtYXkgbm90IGJlIGVub3VnaCBhcyBh
IGNvbW1lbnQgaGVyZS4gVGhlcmUncw0KPj4+PiBubyBkaXJlY3QgaW1wbGljYXRpb24gdGhhdCB0
aGUgd3JpdGUgd291bGQgc2ltcGx5IGJlIGRyb3BwZWQgb24gdGhlIGZsb29yDQo+Pj4+IGlmIHRo
ZSBiaXQgaXMgc3RpbGwgc2V0LiBTbyBJIHRoaW5rIHlvdSB3YW50IHRvIGdvIGEgbGl0dGxlIGJl
eW9uZCBqdXN0DQo+Pj4+IHF1b3RpbmcgZnJvbSB0aGUgc3BlYy4NCj4+PiBIb3cgYWJvdXQgcXVv
dGluZyBSb2dlcidzIHByZXZpb3VzIHdvcmRzOiAiIFRoZSBtZW1vcnkgZGVjb2RpbmcgbXVzdCBi
ZSBkaXNhYmxlZCBiZWZvcmUgd3JpdGluZyB0aGUgQkFSIHNpemUgZmllbGQuDQo+Pj4gT3RoZXJ3
aXNlIGNoYW5naW5nIHRoZSBCQVIgc2l6ZSB3aWxsIGxlYWQgdG8gdGhlIGFjdGl2ZSBwMm0gbWFw
cGluZ3MgZ2V0dGluZyBvdXQgb2Ygc3luYyB3LnIudC4gdGhlIG5ldyBCQVIgc2l6ZS4iID8NCj4+
DQo+PiBUaGF0J2xsIGJlIGJldHRlciwgYnV0IGltbyBzdGlsbCBub3QgZW5vdWdoIHRvIGV4cGxh
aW4gdGhlIG91dHJpZ2h0IGlnbm9yaW5nDQo+PiBvZiB0aGUgd3JpdGUuDQo+IA0KPiBJIHRoaW5r
IHdlIG1pZ2h0IHdhbnQgdG8gZG8gc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZjoNCj4gDQo+
IHVpbnQ2NF90IHNpemUgPSBQQ0lfUkVCQVJfQ1RSTF9TSVpFKHZhbCk7DQo+IHN0cnVjdCB2cGNp
X2JhciAqYmFyID0gZGF0YTsNCj4gDQo+IGlmICggYmFyLT5lbmFibGVkICkNCj4gew0KPiAgICAg
aWYgKCBzaXplID09IGJhci0+c2l6ZSApDQo+ICAgICAgICAgcmV0dXJuOw0KPiANCj4gICAgIC8q
DQo+ICAgICAgKiBSZWZ1c2UgdG8gcmVzaXplIGEgQkFSIHdoaWxlIG1lbW9yeSBkZWNvZGluZyBp
cyBlbmFibGVkLCBhcw0KPiAgICAgICogb3RoZXJ3aXNlIHRoZSBzaXplIG9mIHRoZSBtYXBwZWQg
cmVnaW9uIGluIHRoZSBwMm0gd291bGQgYmVjb21lDQo+ICAgICAgKiBzdGFsZSB3aXRoIHRoZSBu
ZXdseSBzZXQgQkFSIHNpemUsIGFuZCB0aGUgcG9zaXRpb24gb2YgdGhlIEJBUg0KPiAgICAgICog
d291bGQgYmUgcmVzZXQgdG8gdW5kZWZpbmVkLiAgTm90ZSB0aGUgUENJZSBzcGVjaWZpY2F0aW9u
IGFsc28NCj4gICAgICAqIGZvcmJpZHMgcmVzaXppbmcgYSBCQVIgd2l0aCBtZW1vcnkgZGVjb2Rp
bmcgZW5hYmxlZC4NCj4gICAgICAqLw0KPiAgICAgZ3ByaW50ayhYRU5MT0dfRVJSLA0KPiAgICAg
ICAgICAgICAiJXBwOiByZWZ1c2UgdG8gcmVzaXplIEJBUiB3aXRoIG1lbW9yeSBkZWNvZGluZyBl
bmFibGVkXG4iLA0KPiAJICAgICZwY2ktPnNiZGYpOw0KPiAgICAgcmV0dXJuOw0KPiB9DQpUaGFu
ayB5b3UgdmVyeSBtdWNoIQ0KDQo+IA0KPiBOb3RlIHRoaXMgcmVxdWlyZXMgdGhhdCB0aGUgZGF0
YSBwYXJhbWV0ZXIgcG9pbnRzIHRvIHRoZSBCQVIgdGhhdA0KPiBtYXRjaGVzIHRoZSBSZUJBUiBj
b250cm9sIHJlZ2lzdGVyLCB0aGlzIG5lZWRzIGFkanVzdGluZyBpbg0KPiBpbml0X3JlYmFyKCku
DQpJIHRoaW5rIEkgY2FuIGtlZXAgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBvZiBpbml0X3JlYmFy
KCkgYW5kIHVzZSBiYXJzW2luZGV4XSB0byBnZXQgdGhlIGNvcnJlc3BvbmRpbmcgQkFSLg0KDQot
LSANCkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 06:42:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 06:42:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853830.1267173 (Exim 4.92)
	(envelope-from )
	id 1tLGQq-0003ZI-Ch; Wed, 11 Dec 2024 06:42:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853830.1267173; Wed, 11 Dec 2024 06:42:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLGQq-0003ZB-9A; Wed, 11 Dec 2024 06:42:48 +0000
Received: by outflank-mailman (input) for mailman id 853830;
 Wed, 11 Dec 2024 06:42: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 1tLGQo-0003Z4-KL
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 06:42:46 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on2061b.outbound.protection.outlook.com
 [2a01:111:f403:2407::61b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 205342c6-b78b-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 07:42:44 +0100 (CET)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SJ0PR12MB8168.namprd12.prod.outlook.com (2603:10b6:a03:4e7::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Wed, 11 Dec
 2024 06:42:40 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%3]) with mapi id 15.20.8230.010; Wed, 11 Dec 2024
 06:42: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: 205342c6-b78b-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FG89ccoHizAEj2RNBtj/9gibK/EtvsSVAXjvC/YfGix6Hs3cGAUZaRwTg1XmZ2OXzzQlWvFvdQZvoNutUMcubGWFqwah476Aqp2wHqjKVirIQjm7k4lDoZ9KTck2pCVMLy2B+xEDKqZHHOYHL57ymjzL33tWWhjlOY5AR9NYZmtGq6VyUQloBs59J1foY6/+cMmw/dRFzDSIRHATdEJugjZm6XdYmpbpQ4grXBlbkLXqYz+hn3kPr5IOZGEmFrFyIAM5UigR7eaQR6qzafR/ehrwrg08RWWCK0QxCLg/2OYzkgUsAm+QKwGsxg5DguXPmNqlZVE75O6w3Uzdnf+hXA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=OckdZyXq+hyEbVegF9sQo8GThKAZJ90kZa6yPpyH1yk=;
 b=xTwdeP9a39530VVj2/Lr4ldP98jiCzwlnp9R625dkKQz5xL0RuEGckNKncuEEs+XPRRw8dE0OJf6YKGWxzpqlIrRyQfhC0VWweCSqxlu5CdjlY3zo2AgxzYh+E0NG1ftf6kcHMxyMU2tsmzKl1wN2t7saXMkoyMUIhEOTiTNkncN/rHuJtNgrI51fvBZjYVDW8cwyRXJcAvH4zZudGRi0lNEsa+SOAh0WW+WoGsStyXIEdMEEp22QDAWp8LO0XyCni60wESwlG0rSn8TTBwbDs3Fk2coK7OrOGqvhuZtb31SpIYGViQEYjg1punATD/2wbUD/apapQ128tHyBpGVOQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=OckdZyXq+hyEbVegF9sQo8GThKAZJ90kZa6yPpyH1yk=;
 b=1KlvX11dOq2xxR9Xo8FaeYqmf9iDzknV+QRJdluaJIYJWvRcFxyXdNXLLgHslvmKzLieTFbbycseSxu/XJS1A7VXNY0ROEbild74V4pzEtpY1dHvjP0OINeb2tOUyfmDaZHsDwtAKPab7VoJJfX0FhhSJ7fl/7locldIxqNZrFE=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Jan Beulich , Julien
 Grall , Stefano Stabellini , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support
Thread-Topic: [PATCH v2 1/1] vpci: Add resizable bar support
Thread-Index: AQHbRIDgGHZ3ofHO0UuqqXvn+EZCabLfZMMAgAHH6IA=
Date: Wed, 11 Dec 2024 06:42:39 +0000
Message-ID:
 
References: <20241202060956.1124162-1-Jiqian.Chen@amd.com>
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8230.010)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|SJ0PR12MB8168:EE_
x-ms-office365-filtering-correlation-id: 4cca72c8-2f26-43c1-90fd-08dd19af0202
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?Mm01cXhodER4d0xJUndGNnB0VlNwMi9LSjRYMjhkeWxhTldTMUtjdnZGdFdW?=
 =?utf-8?B?YjVSNnZ5Qm5yb2ZtMCs3YVFaV2o0WUJSdXEyaVQrMnNudTRtVEttSlBxbmlG?=
 =?utf-8?B?WWduSWRSeVAxT2FmbXdvTElhaVdXMHdxdTk1ZlRGcENNdkcxNitmQVRaelJT?=
 =?utf-8?B?bGpwV0pjbHVRMUJCbFZLUHFqTlVHb3lNWDJNbkxlSndaeHJtcU05cGM1YnFH?=
 =?utf-8?B?RUNRd1ZrdG5XZksrVVNEYzFjNEpJVW82M0xzaXhZK2IwUENqZXhxOXdzRUJh?=
 =?utf-8?B?dklmQXRYQjJRaG1xRi90cFdwY09HT2dEL1JzNzdpL0djYTVhR1ZFSU9vc2dK?=
 =?utf-8?B?Q2orYzc4bEZEcWw1UllWTVczUzZhTkx2djRsbUFxTDNIT2NIV2JEREJ5YzVQ?=
 =?utf-8?B?Tnp2eEYwVlJOZG9YUzJRc040TUNCYmZSNkR5aXpETjZuZW8zRURBL3hPVmNn?=
 =?utf-8?B?TWhaN0VNRHJHTEpkNzh6NitGS3V6OUNKT0Y0Z3J5cElSSXdsUWtvSE5qOTNJ?=
 =?utf-8?B?a2RKSS9CS0N4NHVqdnpkZmFtb0VrNmpWTXJOUHpDM3c2YzdRcFpxM3lKQUw4?=
 =?utf-8?B?d0g4MnVJVzU2UEYvOVlZVlQ5S1lJVmhQc05RZVllYUJ2QjU1RjIvd3ZlL0JY?=
 =?utf-8?B?R3VOeHR0VjNpWldYUXFYSVN4WVpKM2JiYkc0aTZiN0RUNG1US2ptV1B4TzBB?=
 =?utf-8?B?bHdEMjV6cm9uMkZJa2FSMVdteksxNTljN0JjY3FGMzZXRW1lNW82WFlhN1BT?=
 =?utf-8?B?Q0s0NXMzWjZkZ3FSREpLQm5WSUt3UTh3MVI1b09tOUlQdExRdTRNNC9SemVk?=
 =?utf-8?B?SzFoVU9xdmRUelJ1UEhQbW9WWWxzZXlMWGxCZGdmMm9OUkxCWURxWTN6OEUx?=
 =?utf-8?B?Y0dlZmZLdWxjRkN1OEJkV21FZVVsR3F6QmxSQ0J6QmtHbC81RXE5VTlpUnB2?=
 =?utf-8?B?cHNVaTUyTXdhSnNSZGlnZkJ0REhZelJRMERRRzh5RnB6TDgzenF0MG5nbFdO?=
 =?utf-8?B?SmJlUDJsOWhpUXhpMExWdVVtK3hSRXhjNU53eFBlRUJmbk1kZksyS0d1bExr?=
 =?utf-8?B?TFdhZkg1MXpJNDIyOVdUcWJlMCtSYThxTFBxQ0N4QThNS1l6Y3pMNTlYKzlY?=
 =?utf-8?B?UFRCSFROeCtzSEU4U1BoNFJQbElUSnF1dWpvaGdzTW4za0xCaFZ6T09DWm1S?=
 =?utf-8?B?ZlVLNkpFK3FMNzZ6UWdPSGdmS3c3UllDQnF0bFNYUHJhN2xEWFRiZ1c4QmJw?=
 =?utf-8?B?Vk90NkM5MGhUaWF3RUhvR1B0SE05RUVWTFV4Tzc2VGZSc2ZpeGQ1NElYbi9a?=
 =?utf-8?B?WHc2aVo1dmg0ZlF5bk11Q3dWcUFSRVY5OERaUHBsbkFQYVhJemNJMjg3K1RT?=
 =?utf-8?B?N3FFZkVJOVhQK1JuZGlMTUJRNHBIcFN6b3pHbGpuRGhEK1hidFR4YW5ZOVI4?=
 =?utf-8?B?WTY1Nkd0OWZ1RjQvSStPSnNEeWJZR1dmbW1oSlc4aXRSRXlnK3N3b2NzeGU0?=
 =?utf-8?B?VWM0OGVnQUo3NnNnUGhiT3FJTGZXdjlkbzN5YkEwNStXNE9nNWJRSnlKbXNB?=
 =?utf-8?B?cE9EaUd4RTFIRmVMamd1YlZjczBUMGUwdGNBVTZPa21xRTRtVGdudHFjc2Ew?=
 =?utf-8?B?dFZtU0t5T0RxUFh0OTQzVThseE5EMy9CbzVGb3J4YUZsbTRlWjJQdzVLUHcr?=
 =?utf-8?B?UEovSFRpRVVwS3Fpby9kM29CdkVGKzVFY1EvRFJaVVRYdEFBVHFJS0ViNUox?=
 =?utf-8?B?NEZqMDcwTStCYTVtRm5sdG8zN09raE8zOFl6enordVY5NGVCR3V3OGdDZVB2?=
 =?utf-8?B?Yys2SzRyRTJJdC80S3k4ZnQ3SWp5dVBMM1NmWllJNWVUWDUwcW9SSHZIMGVr?=
 =?utf-8?B?TmNrRW9XVkZQeEkzWkFXU0NuM2NlMlJtYnZ3L1NFV01uRGc9PQ==?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?TWdBaDF1by9tcjhXUVpSMFpVQ2ZtR0VmU2tRaUxmWFY5RnpNOXMwTW5QRy9s?=
 =?utf-8?B?RTJyOUxiRGQ4U1o1QmhCQVBYYWJLenlzbEFmOE5XQ1RIenpEWWhNQ2hvNUNo?=
 =?utf-8?B?YWFTcWhwUUFGOENQbVB1czl4VHNobG9aQTkrMmMzUTFXWDdwQlBRSU1xYW1r?=
 =?utf-8?B?Y2wzcWFwL0l6TWFqZzdUdWc1MVh3Wnh6Ky83UHQvY0s3dDFFc1ZGS2d1QlJt?=
 =?utf-8?B?SWZScC85TzZseVpVZm1uZExQWTVVeVkvaml3cm9Qa0lKd1pEemxpMHZac2Q0?=
 =?utf-8?B?djAzeDdnTTJ3ekMzQldIM1hpaWlVUzR4Y1MwN2Rmb3JGdkF2aGFHRzVjdUwy?=
 =?utf-8?B?VWdQTU9lYXQvc2s4QzRLb3VpM2FYQzVOd1VST05vakJyZlF6a1c4eEdLYlpM?=
 =?utf-8?B?UjRwbEd6T084bzRNeEprZlY1aS95VjV5L3ZwUngyMWxOSEFWSTRMbWR3cjZK?=
 =?utf-8?B?d3c2NjhhaTIwbmVhUGdsTmd0eW1XKzFOMGhTS1hrTFIxcmd5S3FTOThsQnJl?=
 =?utf-8?B?aG8vdWZCdkc4Z2ZDT3NOSFNGV0hHREhqL0xqbTNPS0Qrc1IvcUJBZDF4dDMr?=
 =?utf-8?B?ZVh2b3NkK3N2dkFGdEJLVU41eTlRSU5HT2ttazZENFgrZHppMzVIMFNoS3dB?=
 =?utf-8?B?cmFRSTVxbEhwdjBWRnlEc2N3eVB6ZkhVQ25tcXp2M05qdWpJZVhjVGpnRFZ5?=
 =?utf-8?B?Yk5wYnR4YzhBOUV1MnI5bjNyNFhaSHgzRTFpb2txSGNsTmpoRTZuMkdHSGk1?=
 =?utf-8?B?ejJoZkpNbXpFcmY0Z1NFcHBUaE8xYndTb3NSOEsrVzAvbW5hcFlwM1luV1lC?=
 =?utf-8?B?NjhyYkpxUnVac3UzMlZ0NG9HUGp1Tm55eTBDeWtYSFAvYTcvZWhhbWRXamxV?=
 =?utf-8?B?dmgzVC9lbkdmeGw3Mi8vN2lzNUI5Sm1OSGdOMmV3VFNObW9PY2VRUVJmUEZJ?=
 =?utf-8?B?aThFVXBiRzl2UlZpaWo2clVUTXo4VTUxa1ZOMlVOWGk5RmNkRHliSkdTdGJH?=
 =?utf-8?B?OVFDeHV2aGNRNmNJUmROVDcyTFBqSDdMQXpXSzkzS01iYzdZckpYSThxTGpW?=
 =?utf-8?B?SXZJdGRkemM4NFZ6dVdHSitwdGxZN1dJVnhDWXU0ZGNNUnMybGlkTjhPVkhn?=
 =?utf-8?B?WEp2RWY3VUJ4aURYY1l1SVl6bnVwcWJIMmFObEl6bmlpaHBKZVJFYVV3U0d0?=
 =?utf-8?B?M3crakRZTmxjUGdySkQ0ZlJxWGdTZzNOc1A2TFpyTDJvaC8vY0p2azQvdDJm?=
 =?utf-8?B?MmZ5TGhMWUpMNmlWb1duUDg2bFJPMjAzdjM5V3MwVEZJOWc5QWNtck9wWktQ?=
 =?utf-8?B?RnNVQmRreUZCaWpnZDFXT0Y1TnY1Tkp6NzlmcUgzdzgyYnoreUZVcm90em91?=
 =?utf-8?B?L1I4QWJyUEpXUVFjdlJPY2dZK2FyUzF3OXpGbXpKMXZ0S3ZZMUpvb1BOREww?=
 =?utf-8?B?S1dzY090bGRtdEFpbW5icXdBbnBHYi9lMnlEcm9CMHdQWmhNUWNyckVyZCtJ?=
 =?utf-8?B?OUU2OEUyclZhbFpKMnllVkdEcHZjd3VHeTZGb0IxS1VWSFNpdFplZThQajQ0?=
 =?utf-8?B?ZEZ6T05ra2l3QkVKUHNKSWVTSG1JUWh2RWJWRHhQVlNOVm9PcHl3T242L1RI?=
 =?utf-8?B?U0VmOW5JWi8yYWhXbGkyVldlVE4zcXlYOUJPMUJUNUhwclBZWUdhZzcxNm83?=
 =?utf-8?B?dDRBa2dpUnlRN3g5bGltZnpZVHhiWWlMSnpqQWtNSUY1NUx0Rkt4QUpocVNq?=
 =?utf-8?B?MS9MQU04V28vZjlIcHBqM3FQeFpDeFZKMUN5RVNLWlcyOUFMV0pvN2V5bUw5?=
 =?utf-8?B?amRIc3hJMndqbjJYRURtRUJESkUzTElwamlkVGZlc240b0c5SUJ5QVZNKzBW?=
 =?utf-8?B?eGNhd1VpdUdTTWVva0tpVFFTWXcwOUUrZkZSSDhLaGdzTmhsbTRBeUdTdFc3?=
 =?utf-8?B?Q1kvcmRuRVVOT3E2Y0poek51NmFGMHQ4TDdFNXY5QVZ5ZElQWml6MHc1M3Uy?=
 =?utf-8?B?SGUrSTN1OE9DTVk3R2JtdnNyTVdXRnFmYVN0cEFFZFdnZkQ0bFFtamQxQzNm?=
 =?utf-8?B?aXUzVjc3WHA1QmNIZkMrSU9zZVl3R3JlMStmajcyN0NUUmFBcWV3cEMwWDRC?=
 =?utf-8?Q?QSqE=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4cca72c8-2f26-43c1-90fd-08dd19af0202
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2024 06:42:39.9549
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 0/Yqlx47vKunR0Evyox28ZEepPWALWFpqqZ+2KcDi0eO2UZgu5fjA/5nVv0OqCcifbBdjrh8d93CNvR5DeYG5g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB8168

T24gMjAyNC8xMi8xMCAxOTozMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToNCj4gT24gTW9uLCBE
ZWMgMDIsIDIwMjQgYXQgMDI6MDk6NTZQTSArMDgwMCwgSmlxaWFuIENoZW4gd3JvdGU6DQo+PiBT
b21lIGRldmljZXMsIGxpa2UgZGlzY3JldGUgR1BVIG9mIGFtZCwgc3VwcG9ydCByZXNpemFibGUg
YmFyDQo+PiBjYXBhYmlsaXR5LCBidXQgdnBjaSBvZiBYZW4gZG9lc24ndCBzdXBwb3J0IHRoaXMg
ZmVhdHVyZSwgc28NCj4+IHRoZXkgZmFpbCB0byByZXNpemUgYmFycyBhbmQgdGhlbiBjYXVzZSBw
cm9iaW5nIGZhaWx1cmUuDQo+Pg0KPj4gQWNjb3JkaW5nIHRvIFBDSWUgc3BlYywgZWFjaCBiYXIg
dGhhdCBzdXBwb3J0cyByZXNpemluZyBoYXMNCj4+IHR3byByZWdpc3RlcnMsIFBDSV9SRUJBUl9D
QVAgYW5kIFBDSV9SRUJBUl9DVFJMLiBTbywgYWRkDQo+PiBoYW5kbGVycyBmb3IgdGhlbSB0byBz
dXBwb3J0IHJlc2l6aW5nIHRoZSBzaXplIG9mIEJBUnMuDQo+Pg0KPj4gU2lnbmVkLW9mZi1ieTog
SmlxaWFuIENoZW4gPEppcWlhbi5DaGVuQGFtZC5jb20+DQo+PiAtLS0NCj4+IEhpIGFsbCwNCj4+
DQo+PiB2Mi0+djEgY2hhbmdlczoNCj4+ICpJbiByZWJhcl9jdHJsX3dyaXRlLCB0byBjaGVjayBp
ZiBtZW1vcnkgZGVjb2RpbmcgaXMgZW5hYmxlZCwgYW5kIGFkZGVkDQo+PiBzb21lIGNoZWNrcyBm
b3IgdGhlIHR5cGUgb2YgQmFyLg0KPj4gKkFkZGVkIHZwY2lfaHdfd3JpdGUzMiB0byBoYW5kbGUg
UENJX1JFQkFSX0NBUCdzIHdyaXRlLCBzaW5jZSB0aGVyZSBpcw0KPj4gbm8gd3JpdGUgbGltaXRh
dGlvbiBvZiBkb20wLg0KPj4gKkFuZCBoYXMgbWFueSBvdGhlciBtaW5vciBtb2RpZmljYXRpb25z
IGFzIHdlbGwuDQo+Pg0KPj4gQmVzdCByZWdhcmRzLA0KPj4gSmlxaWFuIENoZW4uDQo+PiAtLS0N
Cj4+ICB4ZW4vZHJpdmVycy92cGNpL01ha2VmaWxlICB8ICAyICstDQo+PiAgeGVuL2RyaXZlcnMv
dnBjaS9yZWJhci5jICAgfCA5MyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
Kw0KPj4gIHhlbi9kcml2ZXJzL3ZwY2kvdnBjaS5jICAgIHwgIDYgKysrDQo+PiAgeGVuL2luY2x1
ZGUveGVuL3BjaV9yZWdzLmggfCAxMSArKysrKw0KPj4gIHhlbi9pbmNsdWRlL3hlbi92cGNpLmgg
ICAgIHwgIDIgKw0KPj4gIDUgZmlsZXMgY2hhbmdlZCwgMTEzIGluc2VydGlvbnMoKyksIDEgZGVs
ZXRpb24oLSkNCj4+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2RyaXZlcnMvdnBjaS9yZWJhci5j
DQo+Pg0KPj4gZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3ZwY2kvTWFrZWZpbGUgYi94ZW4vZHJp
dmVycy92cGNpL01ha2VmaWxlDQo+PiBpbmRleCAxYTE0MTNiOTNlNzYuLmE3YzhhMzBhODk1NiAx
MDA2NDQNCj4+IC0tLSBhL3hlbi9kcml2ZXJzL3ZwY2kvTWFrZWZpbGUNCj4+ICsrKyBiL3hlbi9k
cml2ZXJzL3ZwY2kvTWFrZWZpbGUNCj4+IEBAIC0xLDIgKzEsMiBAQA0KPj4gLW9iai15ICs9IHZw
Y2kubyBoZWFkZXIubw0KPj4gK29iai15ICs9IHZwY2kubyBoZWFkZXIubyByZWJhci5vDQo+PiAg
b2JqLSQoQ09ORklHX0hBU19QQ0lfTVNJKSArPSBtc2kubyBtc2l4Lm8NCj4+IGRpZmYgLS1naXQg
YS94ZW4vZHJpdmVycy92cGNpL3JlYmFyLmMgYi94ZW4vZHJpdmVycy92cGNpL3JlYmFyLmMNCj4+
IG5ldyBmaWxlIG1vZGUgMTAwNjQ0DQo+PiBpbmRleCAwMDAwMDAwMDAwMDAuLjE1NmU4ZDMzNzQy
Ng0KPj4gLS0tIC9kZXYvbnVsbA0KPj4gKysrIGIveGVuL2RyaXZlcnMvdnBjaS9yZWJhci5jDQo+
PiBAQCAtMCwwICsxLDkzIEBADQo+PiArLyogU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6IEdQTC0y
LjAtb3ItbGF0ZXIgKi8NCj4+ICsvKg0KPj4gKyAqIENvcHlyaWdodCAoQykgMjAyNCBBZHZhbmNl
ZCBNaWNybyBEZXZpY2VzLCBJbmMuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuDQo+PiArICoNCj4+ICsg
KiBBdXRob3I6IEppcWlhbiBDaGVuIDxKaXFpYW4uQ2hlbkBhbWQuY29tPg0KPj4gKyAqLw0KPj4g
Kw0KPj4gKyNpbmNsdWRlIDx4ZW4vaHlwZXJjYWxsLmg+DQo+PiArI2luY2x1ZGUgPHhlbi92cGNp
Lmg+DQo+PiArDQo+PiArc3RhdGljIHZvaWQgY2ZfY2hlY2sgcmViYXJfY3RybF93cml0ZShjb25z
dCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHVuc2lnbmVkIGludCByZWcsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB1aW50MzJfdCB2YWwsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB2b2lkICpkYXRhKQ0KPj4gK3sNCj4+ICsgICAgdWludDY0X3Qgc2l6ZTsN
Cj4+ICsgICAgdW5zaWduZWQgaW50IGluZGV4Ow0KPj4gKyAgICBzdHJ1Y3QgdnBjaV9iYXIgKmJh
cnMgPSBkYXRhOw0KPj4gKw0KPj4gKyAgICBpZiAoIHBjaV9jb25mX3JlYWQxNihwZGV2LT5zYmRm
LCBQQ0lfQ09NTUFORCkgJiBQQ0lfQ09NTUFORF9NRU1PUlkgKQ0KPj4gKyAgICAgICAgcmV0dXJu
Ow0KPj4gKw0KPj4gKyAgICBpbmRleCA9IHBjaV9jb25mX3JlYWQzMihwZGV2LT5zYmRmLCByZWcp
ICYgUENJX1JFQkFSX0NUUkxfQkFSX0lEWDsNCj4+ICsgICAgaWYgKCBpbmRleCA+PSBQQ0lfSEVB
REVSX05PUk1BTF9OUl9CQVJTICkNCj4+ICsgICAgICAgIHJldHVybjsNCj4+ICsNCj4+ICsgICAg
aWYgKCBiYXJzW2luZGV4XS50eXBlICE9IFZQQ0lfQkFSX01FTTY0X0xPICYmDQo+PiArICAgICAg
ICAgYmFyc1tpbmRleF0udHlwZSAhPSBWUENJX0JBUl9NRU0zMiApDQo+PiArICAgICAgICByZXR1
cm47DQo+IA0KPiBGb3IgdGhvc2UgZWFybHkgcmV0dXJucyB0aGF0IGRvbid0IHByb3BhZ2F0ZSB0
aGUgd3JpdGUgdG8gdGhlDQo+IHJlZ2lzdGVyLCB3ZSBuZWVkIHRvIGxvZyBhIG1lc3NhZ2UgdG8g
bm90aWNlIHRoZSB3cml0ZSBoYXMgYmVlbg0KPiBkcm9wcGVkLCBvdGhlcndpc2UgdGhlcmUncyBu
byB3YXkgdG8gaWRlbnRpZnkgc3VjaCBjYXNlcy4NCldpbGwgYWRkIHNvbWUgd2FybmluZyBsb2dz
IGluIG5leHQgdmVyc2lvbi4NCg0KPiANCj4gVGhhbmtzLCBSb2dlci4NCg0KLS0gDQpCZXN0IHJl
Z2FyZHMsDQpKaXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 06:58:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 06:58:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853426.1267184 (Exim 4.92)
	(envelope-from )
	id 1tLGfc-0005to-Mt; Wed, 11 Dec 2024 06:58:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853426.1267184; Wed, 11 Dec 2024 06: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 1tLGfc-0005th-I8; Wed, 11 Dec 2024 06:58:04 +0000
Received: by outflank-mailman (input) for mailman id 853426;
 Tue, 10 Dec 2024 23: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 1tL9R4-0001CY-Td
 for xen-devel@lists.xenproject.org; Tue, 10 Dec 2024 23: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 82ced2c6-b74c-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 00:14:32 +0100 (CET)
Received: from pps.filterd (m0279873.ppops.net [127.0.0.1])
 by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BAHIhS3002489
 for ; Tue, 10 Dec 2024 23:14:30 GMT
Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com
 [209.85.216.71])
 by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 43dxw45tda-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT)
 for ; Tue, 10 Dec 2024 23:14:30 +0000 (GMT)
Received: by mail-pj1-f71.google.com with SMTP id
 98e67ed59e1d1-2ef728e36d5so4354188a91.3
 for ; Tue, 10 Dec 2024 15:14:30 -0800 (PST)
Received: from [192.168.1.111] (c-73-202-227-126.hsd1.ca.comcast.net.
 [73.202.227.126]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-2ef779bace5sm7621993a91.31.2024.12.10.15.14.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 15:14: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: 82ced2c6-b74c-11ef-99a3-01e77a169b0f
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=
	PS7l0d33ZO6FBTryro+pjfe77l6D5X7/u/fq40BAyts=; b=lHLPUz2eKaNKUox1
	Ub5dhzdNAOoET8wh+maovCNDPMy6t9eby0VQUopQ/MZLa6olLQwy25+UgpQb8ro5
	VlaMWxZAETVnPKvlzO71jszhSUnevwYHdclz20ywMSlVphBPRa3l4C1hylijowi6
	Bk3QIOrIkCQ+2EOFX/Sdw0b2IpZEpF1kH2IJP81FgU3tYlzhsESrVAf/9ob9ocEp
	ghZvyaVc4lOYnIZDKgvxAUu3jssYTEMSXzRSX3MWUGVMwFilQ0CtwOxrY/ufjUY6
	/bXYCyJGZj10oYxR+tKJcKdW/M9cw92yDO1a0dD+j2PcKvi8rQ2zfcQIOo+BmC3o
	GqzWSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733872469; x=1734477269;
        h=content-transfer-encoding:in-reply-to:content-language:from
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=PS7l0d33ZO6FBTryro+pjfe77l6D5X7/u/fq40BAyts=;
        b=fnwtslGc3hza3fbFTdjpf1jGYgJxtCKEFX2mzHCcDlvejNLlyKCFGerWVCNof+mmBv
         qHGQ7BmmXupa8HSPWwZm7vSmhpuSNqSAoBls++cU0g69Mw9pWyXs1G1+P4QHnLZtSN61
         LXl1jTjDq/GdTpaeYYUv2QHoRvmb+i+Ik84/JnS2wWk3D86+h3NPsKnlb7g3Z4xsMC50
         YXgPINl1bF0CWN2bDe008CepPOy7ObUbaMI+Sm5mvooFcYDUByDl/vdYvvWpPYooYTcf
         yI/E4xDLFVwMZqY/fDuUKGWFozmUDtJn/DWq5pMRs1w3vDlkoXoWqiFeiIGamze4p94I
         tnBA==
X-Forwarded-Encrypted: i=1; AJvYcCXrOPQMjXF/Um+VYnBFOZhuLj4z3PcU2sTDjxZFMETEm2zf52C84q6hGohNzVACEJNAIlQ8rNBZ93Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyKSL0sWJXj1Lva0zlP1tYRCQzpFOA4cYAhqCxNqXNMPQq8NBMg
	NGp+OxHRJRXviGIJmArDvoZT4IfpkTldQVP8kaeUUCUmIqO/qA6YYrOnRHM7oPA1vsaZzGlQ0q3
	BjJdvVfWzbnY3POZe0GE3sdJLpz6EeKuiNLT5IUfGd4NCXVYKXKUkycgPCiDhCLNz6w==
X-Gm-Gg: ASbGncvNj/XyVLai9ypWryiknZHIcOItaLde5FAmm/HBPvACxriMUVQnTePm9vldMdR
	9oEYKcbayBFgyN7eURsRcv+WyMNVtDGodO5LQUUbbLU6CofDpxtO3E7WVw60DsrmWBW4OupUamw
	FVlVy9HDtV5dP7z1KcLFdw2LVZxNTlHHyf1Nw+ygmXT1CZJn+EVKoR5kgrNnELllAXt6VuCDGAf
	qC45zflbtV40QFkPVQlw/QvSXQJIlx5geA/yWv+VR0KW7NzFlMbAL/wmxNSNBJdik/ZgcOCgNjR
	gwYWppUnCB9cRjT/PAUzV7g8RzMAEbq2cYzQAcU90TcnlA4=
X-Received: by 2002:a17:90b:2d81:b0:2ee:dd9b:e402 with SMTP id 98e67ed59e1d1-2f127fc6f84mr1521927a91.12.1733872468889;
        Tue, 10 Dec 2024 15:14:28 -0800 (PST)
X-Google-Smtp-Source: AGHT+IFBBY7t9Ty+FaaMWRfRUoSNUm5Sp5vin1MZzPlySUpMdXEhND47a5JS9XP+rCTHee3d0P0EmA==
X-Received: by 2002:a17:90b:2d81:b0:2ee:dd9b:e402 with SMTP id 98e67ed59e1d1-2f127fc6f84mr1521809a91.12.1733872468344;
        Tue, 10 Dec 2024 15:14:28 -0800 (PST)
Message-ID: <315e9178-5b10-4de0-bdcf-7243e0e355bb@oss.qualcomm.com>
Date: Tue, 10 Dec 2024 15:14:22 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 00/19] Converge on using secs_to_jiffies()
To: Easwar Hariharan ,
        Pablo Neira Ayuso ,
        Jozsef Kadlecsik ,
        "David S. Miller" ,
        Eric Dumazet , Jakub Kicinski ,
        Paolo Abeni , Simon Horman ,
        Julia Lawall ,
        Nicolas Palix , Daniel Mack ,
        Haojian Zhuang ,
        Robert Jarzmik ,
        Russell King
 ,
        Heiko Carstens , Vasily Gorbik ,
        Alexander Gordeev
 ,
        Christian Borntraeger ,
        Sven Schnelle , Ofir Bitton ,
        Oded Gabbay ,
        Lucas De Marchi
 ,
        =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= ,
        Rodrigo Vivi ,
        Maarten Lankhorst ,
        Maxime Ripard ,
        Thomas Zimmermann ,
        David Airlie , Simona Vetter ,
        Jeroen de Borst ,
        Praveen Kaligineedi ,
        Shailend Chand ,
        Andrew Lunn ,
        James Smart ,
        Dick Kennedy ,
        "James E.J. Bottomley" ,
        "Martin K. Petersen" ,
        =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
        Jens Axboe , Kalle Valo ,
        Jeff Johnson ,
        Catalin Marinas
 ,
        Andrew Morton ,
        Jack Wang ,
        Marcel Holtmann
 ,
        Johan Hedberg ,
        Luiz Augusto von Dentz ,
        Greg Kroah-Hartman ,
        Florian Fainelli ,
        Ray Jui
 , Scott Branden ,
        Broadcom internal kernel review list
 ,
        Xiubo Li , Ilya Dryomov ,
        Josh Poimboeuf , Jiri Kosina ,
        Miroslav Benes , Petr Mladek ,
        Joe Lawrence ,
        Jaroslav Kysela , Takashi Iwai ,
        Louis Peens ,
        Michael Ellerman
 ,
        Nicholas Piggin ,
        Christophe Leroy ,
        Naveen N Rao ,
        Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr,
        linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
        dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
        linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-block@vger.kernel.org, linux-wireless@vger.kernel.org,
        ath11k@lists.infradead.org, linux-mm@kvack.org,
        linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev,
        linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org,
        live-patching@vger.kernel.org, linux-sound@vger.kernel.org,
        oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org,
        Anna-Maria Behnsen 
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
From: Jeff Johnson 
Content-Language: en-US
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Proofpoint-ORIG-GUID: 8mKxYhmoWNru6SgfjUCI1JA-0MeTRAsn
X-Proofpoint-GUID: 8mKxYhmoWNru6SgfjUCI1JA-0MeTRAsn
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.60.29
 definitions=2024-09-06_09,2024-09-06_01,2024-09-02_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 bulkscore=0
 suspectscore=0 priorityscore=1501 adultscore=0 mlxlogscore=895
 clxscore=1011 spamscore=0 mlxscore=0 lowpriorityscore=0 phishscore=0
 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.19.0-2411120000 definitions=main-2412100166

On 12/10/2024 2:02 PM, Easwar Hariharan wrote:
> This is a series that follows up on my previous series to introduce
> secs_to_jiffies() and convert a few initial users.[1] In the review for
> that series, Anna-Maria requested converting other users with
> Coccinelle. [2] This is part 1 that converts users of msecs_to_jiffies()
> that use the multiply pattern of either of:
> - msecs_to_jiffies(N*1000), or
> - msecs_to_jiffies(N*MSEC_PER_SEC)
> 
> where N is a constant, to avoid the multiplication.
> 
> The entire conversion is made with Coccinelle in the script added in
> patch 2. Some changes suggested by Coccinelle have been deferred to
> later parts that will address other possible variant patterns.
> 
> CC: Anna-Maria Behnsen 
> Signed-off-by: Easwar Hariharan 

I have the same question as before: How do you expect these to land?
Do you now have a maintainer who will take all of them?
Or do you want individual maintainers to take the ones applicable to them?

/jeff


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 07:11:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 07:11:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853853.1267192 (Exim 4.92)
	(envelope-from )
	id 1tLGsm-0001HH-P8; Wed, 11 Dec 2024 07:11:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853853.1267192; Wed, 11 Dec 2024 07:11: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 1tLGsm-0001HA-MR; Wed, 11 Dec 2024 07:11:40 +0000
Received: by outflank-mailman (input) for mailman id 853853;
 Wed, 11 Dec 2024 07:11: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 1tLGsk-0001H0-Tj
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 07:11:39 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20620.outbound.protection.outlook.com
 [2a01:111:f403:2613::620])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 290eea46-b78f-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 08:11:37 +0100 (CET)
Received: from AS4P189CA0009.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:5d7::13)
 by GV1PR08MB10670.eurprd08.prod.outlook.com (2603:10a6:150:169::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.15; Wed, 11 Dec
 2024 07:11:30 +0000
Received: from AM2PEPF0001C70A.eurprd05.prod.outlook.com
 (2603:10a6:20b:5d7:cafe::d5) by AS4P189CA0009.outlook.office365.com
 (2603:10a6:20b:5d7::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.15 via Frontend Transport; Wed,
 11 Dec 2024 07:11:30 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 AM2PEPF0001C70A.mail.protection.outlook.com (10.167.16.198) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.7
 via Frontend Transport; Wed, 11 Dec 2024 07:11:28 +0000
Received: ("Tessian outbound 9c6259131e4d:v524");
 Wed, 11 Dec 2024 07:11:27 +0000
Received: from L229aa7588b07.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 B547018F-72C8-4261-BC98-0E8C61EA0F2E.1; 
 Wed, 11 Dec 2024 07:11:20 +0000
Received: from AM0PR83CU005.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 L229aa7588b07.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 11 Dec 2024 07:11:20 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by DB8PR08MB5498.eurprd08.prod.outlook.com (2603:10a6:10:11c::24)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.15; Wed, 11 Dec
 2024 07:11:18 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8251.008; Wed, 11 Dec 2024
 07:11: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: 290eea46-b78f-11ef-a0d5-8be0dac302b0
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=G582q1hc2KB4nvk2+jE/M1Vdvx/F6GK3muFwPNv6YnE/+UcTBVC//dagWlzuPcFsDnEVin9WfDZGK7OnGNA3BpRa22V+zfYdeHYX1gemK/0UfYttj26YokdDNCxS1upWGaXmfhjzc1KcK2HzpspIcxFK3uPu5Ido4QkuIzo96MrGVXDoUOvkFq2ZELV/BUDq64UtKVqD9bMBcb9rsO2rUjy99792z7LWcykTX2y5DxqiRnqYWTcyd4SO8fp5mBN0uPcfFCXPGHSprHBPUChbPQcbhGLqjnF/40XV5+ullrxA+i+1BJVd985rbhNV/pcAOs/WioQnMnGevy+0sQERxQ==
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=1Lz8Yf+pNspBp7XiamSDOKZUHdeou7wJ8dh6tyrRdIA=;
 b=gN6onhuev8R/9DObG6wM20gCbnAVrZWfdVXk6+dCOW9daH1rlusBwtu6G8l0rzthMhTghuKKJqRkQt7oLhtD75STquCshs/PSJ72dRKsmE0mePMkTAzLppXKntD8Fy8cQ0y3VhYfQMX4WEurn5DR3+weopZiC4pFMNpOdO4rg8ZOYrfU/fkLACn0mFPi8a646mJTHlHTV0bzTb/BcyWx68vHfxcxt/w29wDaTEprvrdItk3Ltf+Uu788klD2DIlCaWYtqNyyUf2bC8IdpACnfVCQcHXU0+4ekfwxkF1sM0S8w0/SSLkOchX9Ft0LMYfvn2tYnk0ucuapMEdV3CwMDw==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=1Lz8Yf+pNspBp7XiamSDOKZUHdeou7wJ8dh6tyrRdIA=;
 b=h6DrPD8/C69xSSQJ4vImIaPeMPjf1SWJ6tt6vYBeWbTsBJAhLSbzuGANNNp+svQtJ1Zc0iWtwi1zb01wCQN/kKXxGRNZFhephIj4fuK1lhw2bsY0hwpyOXvXbP7Ms5kHvsi5lTS5SQdo98GQuAXN7HumuIOQrS1bne4aKWOqbDc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 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
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: e74550dce57392cf
X-TessianGatewayMetadata: pyGUq/2KiIqAWtSf6px8sWqdyhzNMeKOwxOqcq8jrk9uyWKuovn9s7aBPJ43lplZtIaak0/4vCZTtRX8kyQubCZPtmRBFc3h9K5gmd4p2b/gVlxNAPPZuNuCHPsfsUb9k9ceqfQQgNEF6jjDBl/wZyO/CDzLBg2e2Sz1Uoardfo=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=hagxs4ET/gOWk2YmoU/Um2/dRP6QKgQyLRcnyV3pK9F+9U5euQarA2AfPapKn0iRM9lqWvz5jumKlgxBovIu6GgWb3Vrb+y8L7ORXO9pusaza1VwUbSAakKLFoF4DTuxbCcTZlD6YRvm0CnWj5uay0Rr6qDJEGlNQBjKLrIaWXIqRwbYYmkawgHdiHqw3mjrb5PLm/rkyRrLRFZqCWK+c1WcfHu43JsIooxKPLIJ8RFibFdoW4wBGBj7PLhoBzoaF45Ijuelj/by7m92ANEVXsbJYt8rPy4pM64wl8yNeRNzruCaUFSB+WFLEkruKN0NTBUlvGMCAGo+dOd5qpJC5g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=1Lz8Yf+pNspBp7XiamSDOKZUHdeou7wJ8dh6tyrRdIA=;
 b=rtgMBAWzgjwbp+6+rlHdbrko/52OX5/aAtMmRnOX/d/L8vRHvZ3hwt8LEh3CTGgMDm4E8Us/oKhjrWoFT/zR1AV1wAEqVA2V+cOEbS3RIekoTCpPsR2tGUnDbRI2PB0xEBUsDnwW4hlNVN1MKaEKTGpeJdTbWdKrUnGqlMm+QXboKnJLafJshy/rww0zYUar/o35++0fNptzNod4Z3p2Z29uhWT8aviGear76emZGZTqGRBxtx6N/RDkjiPJbDwLPp0nXQzDAotSKV3izeiNi2BhrcmJdH4s5x5CshWrx5XCal6wv/pO/sJdxW6+NL4tLBfaSxVxncfcY/QOiNTPLg==
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=1Lz8Yf+pNspBp7XiamSDOKZUHdeou7wJ8dh6tyrRdIA=;
 b=h6DrPD8/C69xSSQJ4vImIaPeMPjf1SWJ6tt6vYBeWbTsBJAhLSbzuGANNNp+svQtJ1Zc0iWtwi1zb01wCQN/kKXxGRNZFhephIj4fuK1lhw2bsY0hwpyOXvXbP7Ms5kHvsi5lTS5SQdo98GQuAXN7HumuIOQrS1bne4aKWOqbDc=
From: Bertrand Marquis 
To: Stefano Stabellini 
CC: "xen-devel@lists.xenproject.org" ,
	"kelly.choi@cloud.com" , "anthony.perard@vates.tech"
	, "michal.orzel@amd.com" ,
	"roger.pau@cloud.com" , "committers@xenproject.org"
	
Subject: Re: [PATCH] MAINTAINERS: add Anthony, Michal, Roger to THE REST
Thread-Topic: [PATCH] MAINTAINERS: add Anthony, Michal, Roger to THE REST
Thread-Index: AQHbS19p4yeriQH2lEerZ8Qjjr/HOLLgoPEA
Date: Wed, 11 Dec 2024 07:11:17 +0000
Message-ID: 
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.3826.200.121)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|DB8PR08MB5498:EE_|AM2PEPF0001C70A:EE_|GV1PR08MB10670:EE_
X-MS-Office365-Filtering-Correlation-Id: 0da51311-433e-48c1-a552-08dd19b30841
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|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?d0yMdm+GO4mQngIhz9LgSXEIbcTY4I7aPxdV8AL93+OmLf/8GWIW7Oc0TTsN?=
 =?us-ascii?Q?KI4friVMyVjxGEKSLXcPyiV7IX5y0H8S6FhccSIJ3HKOxdt3NNTeY9vB4nYm?=
 =?us-ascii?Q?fG+cC42jVlvZ48xDJgpln5Q3uRYLiPyKkAXZor0LU/GT6w6kB+JyN7nwf2eu?=
 =?us-ascii?Q?NA7/fyFm37t0FT53c1aErKApPm9FICQiVxaZCib6Csb8S6dVSqumBuFPBXHj?=
 =?us-ascii?Q?640953xEIpt1g7vh+ev0dmuirmHGcE8mxDqhVPpr2DnMW5/HlUMeleRqHeil?=
 =?us-ascii?Q?3yvDorD7/InPpKW86zWd+xCyPyHMdV6KDf0YNTc6AQTxM+ApiKp0MJZmkbcP?=
 =?us-ascii?Q?OEDKPg3Rw7PLx5srqTGMll8IzTGyRy38xpnZRNERQcOEKV4F9FPsKI7+24vR?=
 =?us-ascii?Q?+TSUIDHzo8ZU7obwfiaIgLfWVbow6IiDEPuwhJaa1ax5zZEFbUXS6bXw5o+n?=
 =?us-ascii?Q?zQtUva7hIxWKZxxMwK3H1Ef81rvjBWCquzou9RinFmGi7cu9ExSwK9JyYmEP?=
 =?us-ascii?Q?mgzL6gzNBJNPJQKD+2PkK93H51b9t2RXVfZPbK+2RD21K4fKEIeYLfFVJr+F?=
 =?us-ascii?Q?jV6a8hd3t7+m95l+i5bWU/ruqRFhzpN50L2SvXugc03nuiSlthZQxEKWxSpM?=
 =?us-ascii?Q?6Av9HQkSxlz4B9wYoXB8x1qcFdEzE7yLMXmWiOJh3NJxHbBNmL+U8I5LHSeZ?=
 =?us-ascii?Q?1V091d13C6NdTPuGvkYPDJ1R84ugt8/VP5l4f7SDEfOQychiUUTawees1F2S?=
 =?us-ascii?Q?Xr4ekGSF1sTG3DNN/ps9zR+A/sNXuNZsGeuahFOV34cvXcHpR/e2DpE3+yNW?=
 =?us-ascii?Q?NoZDXRyB7zV+wsuNC+/CVBSZt/kNj1ClHPM7EP40j2lOcCdIrX9Lfk0YZFoG?=
 =?us-ascii?Q?v8/XPJbs8MnAMc+CeXeg3D6Bu3xcOQ1viW8yJxbNs9dykasULK7tdY1ubU8z?=
 =?us-ascii?Q?QWUMairIRzGeAvUM5aJCIU+h6Y6JRCaL5JwRPa+KIshNRY7XchsA778WMhbf?=
 =?us-ascii?Q?DCA6Ik7UoP4haIT1/rb+BKWxBE6n62wF90Q2aHcIF4QTLNfLWqkVshnIM1Ne?=
 =?us-ascii?Q?5kUM/AXJk84M8UzetY2FrCLoaaJQZEep7ABIcMI5j0RmRRhjdPcEIl4GyQuw?=
 =?us-ascii?Q?NzWGvh22wwxy7dxa+9eswAcwB3IhyEgPlzCWbweiQmj4rIaviXbhNbgQDscI?=
 =?us-ascii?Q?nL7T3Y0QXAZlB2BE+UiWfccElcG4nksDWd4aRRtCFb52fJZ27f0o+VdSSXeJ?=
 =?us-ascii?Q?mRYUmvi8BojZVMcH2ySdylN9GpEjmWDtpEYRJAb6DktAgdKvb1W0JLyqIjPc?=
 =?us-ascii?Q?bNHX7AwC9xqP1KVab1is5YB2HFBOBxpnx07AVRjnDPV9PqkpuFUFEdkU13fs?=
 =?us-ascii?Q?9LBcV0NJuRBgpbxPzyX5UlmSkPmmaobtPzJ1T+wetJnLuYfjiQ=3D=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(10070799003)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5498
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender:
 ip=[2603:10a6:10:25a::24];domain=DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM2PEPF0001C70A.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	cc2dcd6f-c810-4cdd-5ead-08dd19b301d8
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|35042699022|14060799003|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?8dYGqblNXN1NmU10g7NvEEIYdlvBwvwKqclkeNmLQT5oIfbtrAzrZVCIg1co?=
 =?us-ascii?Q?qcrqOKRQChrS7gx1+1aoZOWmMMah44i3/FzWEQaA3BtuxoRuCxzyK5iijNJg?=
 =?us-ascii?Q?3wZk4v7+VJzjLaafsI3e3CSIHa0otA7Hqo0JIQ3EFYPUtqYslauJJjPQIsWA?=
 =?us-ascii?Q?W+kq16uTrmWDxdckW95NToX1jLx0lFoRx8wXEjl/k5oMHSuT3fal+hvrqKT5?=
 =?us-ascii?Q?KI2hO/vBvfIdJ7M195orPqCvjDKFJT55tWjTUNQFXEhAhouYdfz2hJp3i/5w?=
 =?us-ascii?Q?QWdeT7U3N9J2sFJC08gX3rxc8/jqcKQYKTiRT2Urq/qDGZVdfhni+AJxKWG9?=
 =?us-ascii?Q?aFLWumZr8D8PSJLhMuLnED9yZhmHHQ8yI4plhyq4gZL+Ddxm3AyfzzBd1J0B?=
 =?us-ascii?Q?0oHI/cuVr/kIvU52Bh1XAzVyacxKVIXj66/jot9Kea2g9EIIOS94R514WqRA?=
 =?us-ascii?Q?IQ4aDS3Pxy4aD7y3Eii0sDc846IGcPmJeWhmuoeFJ+1qB3seclWrfo7UfGQV?=
 =?us-ascii?Q?ZTprGjUdfu+TYiEVsuzK1KgHQssBIxfqSiBLgw6GAZ4l2viThM+GCG+gxdtc?=
 =?us-ascii?Q?Zg9+BPCTd89IMzMG1+dv2hl1+311VWFTGLR2x86d/C9sY2Nt8n/wu5ZAk9TE?=
 =?us-ascii?Q?tfKgDh4yf+n3ItC9veOvQN9IXZjDOkrGdzXrDwLZ9MPihxXEISCfV9tZUq3L?=
 =?us-ascii?Q?c7faujpZ/E5FrrslZ/6mk5vASttQt9YzmskL86JdHB2KKeHrpYMbAZPQxDwt?=
 =?us-ascii?Q?e/+LTzVDyZb45W6D8yjj027tBWXDUlBCwzdvrsvhTLeyTxDSYr1tz8bjQLnl?=
 =?us-ascii?Q?G/QQvvefcDeVYQWy9qV9mTlCQxwiCtWxZV8aAuCkIbJJjt7Et50GdnVprz2W?=
 =?us-ascii?Q?Yd+RoiRshpd8g0dkQnAhMvDrJ2taYbQC/Ax8u71XinVRxw+qVKWRk7ICxib0?=
 =?us-ascii?Q?xzy7YqfKmW7yRCI8BIgXAin1H8kv0B2fkT/gYdineSzc94mycMiT21dWJO+2?=
 =?us-ascii?Q?hScjD1W9AD6Dc4UDiBh7LiAuLomfx78DSOq0Ae56UqANsVpq55NYyEuul3WF?=
 =?us-ascii?Q?rpF80fXX8VKLCj+bz+igP0lh6VJovlIYk/RBbMuaw4SErIfDPVlTu63n9uPB?=
 =?us-ascii?Q?hKSnliHzVFdrvGCw4WhHcGxbMtK91OP11znwibiiQ5p97lLvckYIQMSvm6YE?=
 =?us-ascii?Q?f1X8fSm//t/QMNT/pzCGO9s3Y58D4DHsyHb/1amTCHrfluMYdBP84z+FvOI9?=
 =?us-ascii?Q?2qXGd98VcmxNk1LdEeDylSWoTlvFF4sapA+ductPEV9BnXYHF0/IRg7mr/p6?=
 =?us-ascii?Q?3DYeHTiHNRifMlZ3TvJjWBuWmYaUXXiZWQKlP+k0tcGhhVHXgqBTc25cDtMR?=
 =?us-ascii?Q?BgZL8bGbHmOm9qaegC3jBZ2lPe/GreQuNL87cb7JaoUpPWUgr0jbheQzaZrl?=
 =?us-ascii?Q?HpzD5pff15WASVT5NkVbeFiIOUNINR0aeqq2cTNaDQpHS6f1qEo+Dw=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ErrorRetry;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(35042699022)(14060799003)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Dec 2024 07:11:28.4370
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0da51311-433e-48c1-a552-08dd19b30841
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AM2PEPF0001C70A.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR08MB10670



> On 11 Dec 2024, at 00:58, Stefano Stabellini  wro=
te:
>=20
> In recognition of their outstanding work and years of service to the Xen
> Community, please join me in welcoming Anthony, Michal, and Roger as
> Committers and REST Maintainers.
>=20
> Signed-off-by: Stefano Stabellini 

Acked-by: Bertrand Marquis 



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 07:20:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 07:20:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853869.1267208 (Exim 4.92)
	(envelope-from )
	id 1tLH0x-0002wD-WF; Wed, 11 Dec 2024 07:20:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853869.1267208; Wed, 11 Dec 2024 07:20: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 1tLH0x-0002vN-R1; Wed, 11 Dec 2024 07:20:07 +0000
Received: by outflank-mailman (input) for mailman id 853869;
 Wed, 11 Dec 2024 07:20: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 1tLH0w-0002Uu-Hx
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 07:20:06 +0000
Received: from pegase2.c-s.fr (pegase2.c-s.fr [93.17.235.10])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 56493c8b-b790-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 08:20:02 +0100 (CET)
Received: from localhost (mailhub3.si.c-s.fr [172.26.127.67])
 by localhost (Postfix) with ESMTP id 4Y7RPY1fW8z9t4Z;
 Wed, 11 Dec 2024 08:02:41 +0100 (CET)
Received: from pegase2.c-s.fr ([172.26.127.65])
 by localhost (pegase2.c-s.fr [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ke-WcrxaszkX; Wed, 11 Dec 2024 08:02:41 +0100 (CET)
Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192])
 by pegase2.c-s.fr (Postfix) with ESMTP id 4Y7RPY0Vj8z9t4W;
 Wed, 11 Dec 2024 08:02:41 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by messagerie.si.c-s.fr (Postfix) with ESMTP id ED9BB8B76E;
 Wed, 11 Dec 2024 08:02:40 +0100 (CET)
Received: from messagerie.si.c-s.fr ([127.0.0.1])
 by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023)
 with ESMTP id BSgjR7epYr8H; Wed, 11 Dec 2024 08:02:40 +0100 (CET)
Received: from [10.25.209.139] (unknown [10.25.209.139])
 by messagerie.si.c-s.fr (Postfix) with ESMTP id 2664A8B763;
 Wed, 11 Dec 2024 08:02:40 +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: 56493c8b-b790-11ef-99a3-01e77a169b0f
X-Virus-Scanned: amavisd-new at c-s.fr
X-Virus-Scanned: amavisd-new at c-s.fr
Message-ID: <427e840b-d4f5-4554-b798-c70a5b67040e@csgroup.eu>
Date: Wed, 11 Dec 2024 08:02:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 05/19] powerpc/papr_scm: Convert timeouts to
 secs_to_jiffies()
To: Easwar Hariharan ,
 Pablo Neira Ayuso ,
 Jozsef Kadlecsik ,
 "David S. Miller" , Eric Dumazet ,
 Jakub Kicinski , Paolo Abeni ,
 Simon Horman , Julia Lawall ,
 Nicolas Palix , Daniel Mack ,
 Haojian Zhuang ,
 Robert Jarzmik , Russell King
 , Heiko Carstens ,
 Vasily Gorbik , Alexander Gordeev
 , Christian Borntraeger ,
 Sven Schnelle , Ofir Bitton ,
 Oded Gabbay , Lucas De Marchi
 ,
 =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= ,
 Rodrigo Vivi ,
 Maarten Lankhorst ,
 Maxime Ripard , Thomas Zimmermann ,
 David Airlie , Simona Vetter ,
 Jeroen de Borst ,
 Praveen Kaligineedi ,
 Shailend Chand , Andrew Lunn ,
 James Smart ,
 Dick Kennedy ,
 "James E.J. Bottomley" ,
 "Martin K. Petersen" ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Jens Axboe , Kalle Valo ,
 Jeff Johnson , Catalin Marinas
 , Andrew Morton ,
 Jack Wang , Marcel Holtmann
 , Johan Hedberg ,
 Luiz Augusto von Dentz ,
 Greg Kroah-Hartman ,
 Florian Fainelli , Ray Jui
 , Scott Branden ,
 Broadcom internal kernel review list
 , Xiubo Li ,
 Ilya Dryomov , Josh Poimboeuf ,
 Jiri Kosina , Miroslav Benes ,
 Petr Mladek , Joe Lawrence ,
 Jaroslav Kysela , Takashi Iwai ,
 Louis Peens , Michael Ellerman
 , Nicholas Piggin ,
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr,
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org,
 ath11k@lists.infradead.org, linux-mm@kvack.org,
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev,
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org,
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org,
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org,
 Anna-Maria Behnsen 
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
 <20241210-converge-secs-to-jiffies-v3-5-ddfefd7e9f2a@linux.microsoft.com>
Content-Language: fr-FR
From: Christophe Leroy 
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-5-ddfefd7e9f2a@linux.microsoft.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



Le 10/12/2024 à 23:02, Easwar Hariharan a écrit :
> Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
> secs_to_jiffies(). As the value here is a multiple of 1000, use
> secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
> 
> This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
> the following Coccinelle rules:
> 
> @@ constant C; @@
> 
> - msecs_to_jiffies(C * 1000)
> + secs_to_jiffies(C)
> 
> @@ constant C; @@
> 
> - msecs_to_jiffies(C * MSEC_PER_SEC)
> + secs_to_jiffies(C)
> 
> Signed-off-by: Easwar Hariharan 

Reviewed-by: Christophe Leroy 

> ---
>   arch/powerpc/platforms/pseries/papr_scm.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> index f84ac9fbe203c111046464b9100866dddae687bb..f7c9271bda58433f395648063e60409a8d3c11d9 100644
> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> @@ -544,7 +544,7 @@ static int drc_pmem_query_health(struct papr_scm_priv *p)
>   
>   	/* Jiffies offset for which the health data is assumed to be same */
>   	cache_timeout = p->lasthealth_jiffies +
> -		msecs_to_jiffies(MIN_HEALTH_QUERY_INTERVAL * 1000);
> +		secs_to_jiffies(MIN_HEALTH_QUERY_INTERVAL);
>   
>   	/* Fetch new health info is its older than MIN_HEALTH_QUERY_INTERVAL */
>   	if (time_after(jiffies, cache_timeout))
> 



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 07:20:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 07:20:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853870.1267203 (Exim 4.92)
	(envelope-from )
	id 1tLH0x-0002tT-Ni; Wed, 11 Dec 2024 07:20:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853870.1267203; Wed, 11 Dec 2024 07:20: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 1tLH0x-0002tM-KQ; Wed, 11 Dec 2024 07:20:07 +0000
Received: by outflank-mailman (input) for mailman id 853870;
 Wed, 11 Dec 2024 07: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 1tLH0w-0002nr-IC
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 07:20:06 +0000
Received: from pegase2.c-s.fr (pegase2.c-s.fr [93.17.235.10])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 58346e61-b790-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 08:20:05 +0100 (CET)
Received: from localhost (mailhub3.si.c-s.fr [172.26.127.67])
 by localhost (Postfix) with ESMTP id 4Y7RLj3GV8z9t4d;
 Wed, 11 Dec 2024 08:00:13 +0100 (CET)
Received: from pegase2.c-s.fr ([172.26.127.65])
 by localhost (pegase2.c-s.fr [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id c0Dk1hMGM9_h; Wed, 11 Dec 2024 08:00:13 +0100 (CET)
Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192])
 by pegase2.c-s.fr (Postfix) with ESMTP id 4Y7RLY2gbNz9t4Z;
 Wed, 11 Dec 2024 08:00:05 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by messagerie.si.c-s.fr (Postfix) with ESMTP id 3FA418B76E;
 Wed, 11 Dec 2024 08:00:05 +0100 (CET)
Received: from messagerie.si.c-s.fr ([127.0.0.1])
 by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023)
 with ESMTP id lblUBnLQKeTT; Wed, 11 Dec 2024 08:00:05 +0100 (CET)
Received: from [10.25.209.139] (unknown [10.25.209.139])
 by messagerie.si.c-s.fr (Postfix) with ESMTP id A13268B763;
 Wed, 11 Dec 2024 08:00:03 +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: 58346e61-b790-11ef-a0d5-8be0dac302b0
X-Virus-Scanned: amavisd-new at c-s.fr
X-Virus-Scanned: amavisd-new at c-s.fr
Message-ID: <07784753-6874-4dda-a080-2d2812f4a10a@csgroup.eu>
Date: Wed, 11 Dec 2024 08:00:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 18/19] livepatch: Convert timeouts to secs_to_jiffies()
To: Easwar Hariharan ,
 Pablo Neira Ayuso ,
 Jozsef Kadlecsik ,
 "David S. Miller" , Eric Dumazet ,
 Jakub Kicinski , Paolo Abeni ,
 Simon Horman , Julia Lawall ,
 Nicolas Palix , Daniel Mack ,
 Haojian Zhuang ,
 Robert Jarzmik , Russell King
 , Heiko Carstens ,
 Vasily Gorbik , Alexander Gordeev
 , Christian Borntraeger ,
 Sven Schnelle , Ofir Bitton ,
 Oded Gabbay , Lucas De Marchi
 ,
 =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= ,
 Rodrigo Vivi ,
 Maarten Lankhorst ,
 Maxime Ripard , Thomas Zimmermann ,
 David Airlie , Simona Vetter ,
 Jeroen de Borst ,
 Praveen Kaligineedi ,
 Shailend Chand , Andrew Lunn ,
 James Smart ,
 Dick Kennedy ,
 "James E.J. Bottomley" ,
 "Martin K. Petersen" ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Jens Axboe , Kalle Valo ,
 Jeff Johnson , Catalin Marinas
 , Andrew Morton ,
 Jack Wang , Marcel Holtmann
 , Johan Hedberg ,
 Luiz Augusto von Dentz ,
 Greg Kroah-Hartman ,
 Florian Fainelli , Ray Jui
 , Scott Branden ,
 Broadcom internal kernel review list
 , Xiubo Li ,
 Ilya Dryomov , Josh Poimboeuf ,
 Jiri Kosina , Miroslav Benes ,
 Petr Mladek , Joe Lawrence ,
 Jaroslav Kysela , Takashi Iwai ,
 Louis Peens , Michael Ellerman
 , Nicholas Piggin ,
 Naveen N Rao , Madhavan Srinivasan 
Cc: netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr,
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org,
 ath11k@lists.infradead.org, linux-mm@kvack.org,
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev,
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org,
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org,
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org,
 Anna-Maria Behnsen 
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
 <20241210-converge-secs-to-jiffies-v3-18-ddfefd7e9f2a@linux.microsoft.com>
Content-Language: fr-FR
From: Christophe Leroy 
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-18-ddfefd7e9f2a@linux.microsoft.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



Le 10/12/2024 à 23:02, Easwar Hariharan a écrit :
> Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
> secs_to_jiffies(). As the value here is a multiple of 1000, use
> secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
> 
> This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
> the following Coccinelle rules:
> 
> @@ constant C; @@
> 
> - msecs_to_jiffies(C * 1000)
> + secs_to_jiffies(C)
> 
> @@ constant C; @@
> 
> - msecs_to_jiffies(C * MSEC_PER_SEC)
> + secs_to_jiffies(C)
> 
> Signed-off-by: Easwar Hariharan 
> ---
>   samples/livepatch/livepatch-callbacks-busymod.c |  3 +--
>   samples/livepatch/livepatch-shadow-fix1.c       |  3 +--
>   samples/livepatch/livepatch-shadow-mod.c        | 15 +++++----------
>   3 files changed, 7 insertions(+), 14 deletions(-)
> 
> diff --git a/samples/livepatch/livepatch-callbacks-busymod.c b/samples/livepatch/livepatch-callbacks-busymod.c
> index 378e2d40271a9717d09eff51d3d3612c679736fc..69105596e72e6826aa2815cb2599eea56a0055ba 100644
> --- a/samples/livepatch/livepatch-callbacks-busymod.c
> +++ b/samples/livepatch/livepatch-callbacks-busymod.c
> @@ -44,8 +44,7 @@ static void busymod_work_func(struct work_struct *work)
>   static int livepatch_callbacks_mod_init(void)
>   {
>   	pr_info("%s\n", __func__);
> -	schedule_delayed_work(&work,
> -		msecs_to_jiffies(1000 * 0));
> +	schedule_delayed_work(&work, 0);

This hunk is not in line with the patch description.

This is probably OK to have in this patch, but you should add additional 
description to mention that special case with a 0 delay.

Allthough you should probably change it to schedule_work() instead of 
using a 0 delay.

Christophe


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 07:29:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 07:29:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853890.1267223 (Exim 4.92)
	(envelope-from )
	id 1tLH9V-0004fu-Pg; Wed, 11 Dec 2024 07:28:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853890.1267223; Wed, 11 Dec 2024 07:28:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLH9V-0004fn-Mx; Wed, 11 Dec 2024 07:28:57 +0000
Received: by outflank-mailman (input) for mailman id 853890;
 Wed, 11 Dec 2024 07:28: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 1tLH9U-0004fg-Ei
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 07:28:56 +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 93ff1425-b791-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 08:28:55 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-4361f65ca01so1502955e9.1
 for ; Tue, 10 Dec 2024 23:28:55 -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
 d9443c01a7336-216796e213bsm20618955ad.126.2024.12.10.23.28.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 23:28: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: 93ff1425-b791-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733902135; x=1734506935; 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=01PaaWgxANIyZIvIY2UKbBezgzZGv6uv67val1nTgtE=;
        b=Xgo1dOhCicpyQbHnnuCeK+PpWfqDwLbGv4QF8QDo0FxzuSX+E+pBan45zhrpJsIGhr
         dD9ia2lCI/bvc0YSEoSLTBeD8X7xQF+bHGvDKMM0DgFwn3VGck+Fc9std7H/vLZpedq0
         NTV2rTcqOBWceKcrgqGmXkKKmUU2cqqgJBP4yFPnNc55ttE1Nhi8gi5l1hKTGSm2vbO0
         +pje7e7u+gzXkaM15V5Y6l6ShUBewuQWDLPIJUEh5Z4C5UTkvIO3UB5lwIheT39RenaE
         lozirXHYqCuybyNy4cxwmT5xa67W3sjWxulWnrqTZQ0aQx50SkvfVd47wd8G7rBjmg0C
         MBKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733902135; x=1734506935;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=01PaaWgxANIyZIvIY2UKbBezgzZGv6uv67val1nTgtE=;
        b=HXon+I1ysJNyM3RPZDSr6CLg2yepdM5b60A06pB7Q9c0RZH/pCs1ipq8fEFWb2HTCP
         J4LHE4veMhYBmREtAWkv0kivO0+2gfez+3Ir5ngSe4XYi7X+/miBqUTHespHp/9irIGe
         EDZQT1KIJP5agBz2zxFMeq6eNzuMwQcopK95JTFVqTqKG7J6o46jVTwQTnD6V3peubJL
         BASDXW5vPqNBZVTrpnN8eJgpF9EjlU00MycXr9BFipfXiQWjd+FYWBfGL7Yuv2qy2U7o
         MQ9yKt4FGod57gLOjC7pSo79cgA08I4kQWQ2urYtqdUp03JbMZ7kAcL+fPPuya63DdKI
         bZXQ==
X-Forwarded-Encrypted: i=1; AJvYcCXuqbeLgapyOx9sq2XuPq9i9lrBJYDpxXFNBZ114N4acOORxDQbSQqJi2QalCM22ilXSokq+pMfhIA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx1JbFSUQkxJFJe80lbenXqoUEzVg9vO5qoSkNOTawRi0Vtq4QL
	6S70AHbKwOLNKzXXylYsp/wyI+fpTIQu/FZAspVtn9hIg1JcMnjp/2tYQb/RCg==
X-Gm-Gg: ASbGnctFNHm9nlero0DVKnZasqGwuz+I/OeQiqnCmGjU4nqKngn1YqSJYTFoyoK/lIk
	sPLwYpnsyWyfk2BF1O+94feCnEWaN6N44hFJ4OpaFnk0mra2iePWkr+4AR8aQkEu8usWPOXtcYV
	hh8ZohVqY6ldEL+5a8jALkJ2Z9PExq3GhRpAfx2NX/n8dlc2GxTzYNqqiu1je9dsBiZkFJu98kC
	2iYG/9VOEvUrjFprkJaId5VwBXIPRtap5K+cCSS0piwNsoX11wn9urP7dyBqau7xyGjtCmMyIYz
	ClFKOW9GkWg3Ro7COn0FrZzVIYgWO+Fq+wDRCN0=
X-Google-Smtp-Source: AGHT+IHFOuHPWmuprje6fIwUTemXq+3Jp5ArCtETqJawgQh6kGYzFfSlitgtcwAnb6J6+nYvZ3f8oA==
X-Received: by 2002:a5d:5989:0:b0:386:3e0f:944b with SMTP id ffacd0b85a97d-3864cec582bmr1021468f8f.37.1733902134885;
        Tue, 10 Dec 2024 23:28:54 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 08:28:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
To: dmukhin@ford.com, xen-devel@lists.xenproject.org
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> console_owner_domid() is introduced to obtain the "console owner" domain ID.
> 
> The call is used in NS8250 emulator to identify the case when physical xen
> console focus is owned by the domain w/ NS8250 emulator, in which case,
> messages from guest OS are formatted w/o '(XEN)' prefix.

Such messages ought to be processed through guest_printk(), which wants a
domain pointer, not a domid_t anyway. Plus isn't that going to be
current->domain anyway at the callsite, eliminating the need for such a
helper altogether?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 07:32:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 07:32:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853898.1267233 (Exim 4.92)
	(envelope-from )
	id 1tLHCY-0006nY-6p; Wed, 11 Dec 2024 07:32:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853898.1267233; Wed, 11 Dec 2024 07:32: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 1tLHCY-0006nR-41; Wed, 11 Dec 2024 07:32:06 +0000
Received: by outflank-mailman (input) for mailman id 853898;
 Wed, 11 Dec 2024 07:32: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 1tLHCX-0006nL-1t
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 07:32:05 +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 04704712-b792-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 08:32:04 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-434ab938e37so41322035e9.0
 for ; Tue, 10 Dec 2024 23:32: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
 d2e1a72fcca58-725ea154427sm5513039b3a.23.2024.12.10.23.32.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 23:32: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: 04704712-b792-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733902323; x=1734507123; 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=TQj1Q/Dg1IBa6lfDQC9U5T3P7xWYQIqiU48W0LtOGq8=;
        b=Svv197jIIC0GEdFmhpdGPSCWeHF4cjPTfuAQDo6OLHcbeH/1f1lulUYxHyKfgew2qK
         XF/auASBOVHpf/KS6CJjiY78yfUZQ8WiUX8vEfTADTNGvLOLxHN7tKwDjq0+pbdAomfZ
         552TXBhFRYVMYKLSJmvkmN50+qsphHKsEsas6P4phvlW8LNoKLPoJhdgQGI8XAukFuQF
         vwAuq0mRLxv/+lVlc/vRG+YJcALQRWGb9ZEsF3UrBVkN37TFEwM4fRhz1FRTShkuGBtW
         WGL/PtbZl0sqRII620q4QWczBNuXmc/NCFOarXC6iwhxslG2khoGM0dlcK+pS6G6PJ5B
         RHZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733902323; x=1734507123;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=TQj1Q/Dg1IBa6lfDQC9U5T3P7xWYQIqiU48W0LtOGq8=;
        b=nSgkl7O/myw4sV3q/CCmUmqEalJyyqo4tZid6lLHnJRJHLNFDJWDXknOy90EmDkGIF
         goo80WhcwMGChOab1BHXTAcfEiTLQocWvS1QZTLVFcKyUL0pOHAld5E3Y4Xi0xoGuVQ5
         Og/0Lr3aqI8JY6WO1kk1R4KdQ85k7UuYSWVaQYKgwV4x414IuisnczO8WO01ikfcBf+B
         EZ7vhXMFyh4NLLG09r7V+XATU4BFC4voUhB84AZMm9x/XPMDd5DN32ml6mUOdwofLjDI
         p7Qd/9FfePt3WNOpljhh5IjnMmBWz9tsDktgtEckZJbN5a1W1Z0ptx10qnSFVoL2ubEj
         GYKw==
X-Forwarded-Encrypted: i=1; AJvYcCVxhZf9FHA/nfnFnZ5DhpX/Ilp15kjB9oNbw72MnovegyjVEWSPkgiFbEzOVsh5yHrJbRn6KJN9LyM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyIIgOI/w/9AVLqixD6M92FFmV01P1R9gr705saC8GkTylMrJ8M
	x1aVZ4WtNJxoLyuIa1YQ6y19dRUo5VnLn8QoAq5z2lUB7RvGu+J580ww3Bn2YQ==
X-Gm-Gg: ASbGncum50gsTczvk7lPJYEYhxXne4wEjRk5K/P/ck57PsAMUeZXvgz/Por9BqsWgiQ
	HRq1pyNIK43XsZVc2EGSeOectraaC9Z2WyNEOauXz074ri5Xx0fEgXTVG+cixzYQXzGrVLQ7q9M
	KI9fBM453c6zWKFQsgYLuhehWs8BPbk62GX7gPmpCy9xidMhVgosjr4JgwRRwxDQG5v1OvFTV4J
	o0Qi//pyWNW1myre8hX9o8ax2aOMA+L7Kogk1lJkqmmipZ/YCiixqVt/iGw3Wzhz2p0vlEwCP8+
	bkEQCqfZg7GGzEjo2TrWTStxFvAgHDm+gbfZYlc=
X-Google-Smtp-Source: AGHT+IFmYBh8Cq49+S6xL3YoRdA5+LNnvf/gnBwTyzN40NUvOv0ippOHJ3mgvl/VoRF0lg+EbdCnWw==
X-Received: by 2002:a5d:64aa:0:b0:385:e0d6:fb48 with SMTP id ffacd0b85a97d-3864ce894b6mr1313976f8f.7.1733902323515;
        Tue, 10 Dec 2024 23:32:03 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 08:31:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 21/35] xen/console: introduce console_init_owner()
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-21-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-21-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -554,6 +554,22 @@ static void console_find_owner(void)
>          console_set_owner(DOMID_XEN);
>  }
>  
> +static void console_init_owner(void)
> +{
> +    domid_t domid;
> +
> +    /*
> +     * If user specifies so, we fool the switch routine to redirect input
> +     * straight back to Xen.
> +     */
> +    if ( opt_conswitch[1] == 'x' )
> +        domid = DOMID_XEN;
> +    else
> +        domid = get_initial_domain_id();
> +
> +    console_set_owner(domid);
> +}

Is this function meant to gain a 2nd user? If not, what exactly is the goal
of introducing this new function?

If the function's addition is warranted, it wants to be __init, matching ...

> @@ -1160,8 +1168,7 @@ void __init console_endboot(void)
>      register_irq_keyhandler('G', &do_toggle_guest,
>                              "toggle host/guest log level adjustment", 0);
>  
> -    /* Serial input is directed to DOM0 by default. */
> -    console_find_owner();
> +    console_init_owner();
>  }

... sole caller.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 07:34:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 07:34:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853912.1267243 (Exim 4.92)
	(envelope-from )
	id 1tLHES-0007QL-M0; Wed, 11 Dec 2024 07:34:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853912.1267243; Wed, 11 Dec 2024 07:34:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLHES-0007QE-JN; Wed, 11 Dec 2024 07:34:04 +0000
Received: by outflank-mailman (input) for mailman id 853912;
 Wed, 11 Dec 2024 07:34: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 1tLHEQ-0007Pr-Qs
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 07:34:02 +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 4a41087c-b792-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 08:34:01 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-434f3d934fcso21177935e9.3
 for ; Tue, 10 Dec 2024 23:34: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
 98e67ed59e1d1-2ef7315fd3asm8644326a91.44.2024.12.10.23.33.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 23:34: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: 4a41087c-b792-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733902440; x=1734507240; 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=x1zWuERKWHXpk3QeEuDiUP2J1ewr49478Cn28QWMU38=;
        b=OVb7F5R1/CCjNcNvrvc1wHcUI8LtPQ4G5O9MBL1dWRSiwcNZ2PkiSrkELqmFicUDYw
         kIXLdAI+7ki8hRKpfNHUZAbMzSh86w+yQ/mDHAGaVxIA9aqhlu98DsRPceXh804Pz156
         tMQM75lrQKgWr5izgUo3rWRJkX7kW81ncPmlmE9G6AmQvlh4WcAxNhxPQoNAQNuiFw0x
         ftQgrSFI6www7r4mex+JrrHNFzzxouxEQWWQNrAhWLt0/H1En25isVb6+RpnBf6I0iUq
         Tx4RWJ8i32i+vO40a7Ysh7uCEbBnEAUbzSfxWYP6AO7UBLsPUyEpi47KEmP6BY8HBYmL
         Fqng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733902440; x=1734507240;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=x1zWuERKWHXpk3QeEuDiUP2J1ewr49478Cn28QWMU38=;
        b=vdfPrIKxZQYPWF/IxtWpYuov1SvIaECjYIVSthnbWeK5WvRnMVU1lFYN8kvAx/Cyh6
         UxNO8xLgfKeJBziZTaKcMkgyunMUlcoNGqd1ccHGtHpnRzX9dItZJf+lGOl6V2ns+vri
         iCuUOSzQQ6yvj3jYbtSRfa3BmFtCWV+Ymut+xVVmpU4PPkJ/fkynk09HkF9bhA2YQrEM
         kh6SMIPZVJm92LrDNip0UXZD/IBbaYukXQ0NJce5r/184uXR6qVhvD/5FF5kB9iFSMZM
         sB2Ut8uup5A9zTWnmT2uka9Q4IupPARwHfZmEaVBudLb7nXQYo0xn/89kSySFH0tABO8
         fp5g==
X-Forwarded-Encrypted: i=1; AJvYcCWAW0/vXaOmI56jEYqMX6BJHzoGtnmzVXKAkCN2hutVtObFtYuIYRuHC/GZSmkM1B5oUxSnP0lBybY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyWftFsDCMUlXXD2V2SmjiDQofAKulKKZ/jk10dqKyeSWjeJtBO
	t6LEhufqNfmzGycuY97MgU86QQZdXZUymIQzQx/9Km1mLM7h2k9XLGJuep5U/g==
X-Gm-Gg: ASbGnctsBBdJfaDVIAk8q+J5IT5Pho4wPzPVMhqyBiM9HjBbY3wdcd7HH7jbnGoKTvn
	HRGf2jtTGVNzrURPbWSRfvbxf+7ryBa0Y3R0mvj7v/DI3wP4NXSlp9uuvy6AGyRpKnTI6D0QIrO
	iDOCAYR3axJ1f5ltedDqH2Tqo5JdN3JZVmqp3c3WwvySjD/gkQjocmllurQosnm5WqnquVPWIg3
	edFoedmaUZVohh5pepgEBOPuDexeFUEwP0OE3vr1+HVX3WLfvtweVLOvvyipxpItz7Eu4EUQsks
	ccpYhuD+uRXRt3db3UxVzZaGl5Ik/HFSe1pyyGg=
X-Google-Smtp-Source: AGHT+IFAMa17/9TzroTdAhsrXHnUHuM9rM3YnPfYxz1ataWhtwKwJ4+OXc38dZbdFXlhUWRujuPaXg==
X-Received: by 2002:a5d:5f50:0:b0:385:e22e:288f with SMTP id ffacd0b85a97d-3864ce60b85mr1273073f8f.31.1733902440582;
        Tue, 10 Dec 2024 23:34:00 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 08:33:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
To: Jason Andryuk , dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com>
 <9be0addc-d4cf-47c4-937d-e1937898c010@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: <9be0addc-d4cf-47c4-937d-e1937898c010@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.12.2024 23:11, Jason Andryuk wrote:
> On 2024-12-05 23:41, Denis Mukhin via B4 Relay wrote:
>> From: Denis Mukhin 
>>
>> console_owner_domid() is introduced to obtain the "console owner" domain ID.
>>
>> The call is used in NS8250 emulator to identify the case when physical xen
>> console focus is owned by the domain w/ NS8250 emulator, in which case,
>> messages from guest OS are formatted w/o '(XEN)' prefix.
>>
>> Signed-off-by: Denis Mukhin 
> 
> Reviewed-by: Jason Andryuk 
> 
> I expected this to be used immediately by patch 21, but it is not.  You 
> might want to re-order it directly before its first use is introduced. 
> I haven't gotten far enough to know when that is.

Plus, no matter how far in the future it is, there'll be a window where the
Misra rule of not having unreachable code in the project is violated. New
functions now really need introducing when their first caller appears.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 07:35:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 07:35:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853923.1267253 (Exim 4.92)
	(envelope-from )
	id 1tLHFb-0007x4-WC; Wed, 11 Dec 2024 07:35:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853923.1267253; Wed, 11 Dec 2024 07:35: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 1tLHFb-0007wx-SG; Wed, 11 Dec 2024 07:35:15 +0000
Received: by outflank-mailman (input) for mailman id 853923;
 Wed, 11 Dec 2024 07:35: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 1tLHFa-0007wp-8u
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 07:35:14 +0000
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com
 [2a00:1450:4864:20::42d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 748a0781-b792-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 08:35:12 +0100 (CET)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-38634c35129so2970831f8f.3
 for ; Tue, 10 Dec 2024 23:35: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
 98e67ed59e1d1-2ef45ff77b9sm10951345a91.36.2024.12.10.23.35.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 23:35: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: 748a0781-b792-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733902511; x=1734507311; 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=0te3i6s3e3e9P1sHuBoAmyFLAx8P4clDSX5l8m/TTUU=;
        b=MmNce2K7lV3XnQ6WPNkfYCnAsY8S8sqdbJpzHoX5AFZCt83tAwrHSeN1cOl8ebfVoa
         ztI0/kbrkzttj8ads/jrIvRLzg1SftP3d6CL+L3Ku7GOnZzfZeYf6utzGZJcPaQBR4BE
         L6BL7USTn4KEj6I0vackD50ScL2hk9YMebw3FDCawlLLmGobmIoJOwXO1+iYYnFLnYny
         tyw744JRDO+PIZHETE+gJay89OwblkDaV7h3jN/wx0lHmIHHpCpmkEp5QPEOpGqRzzql
         r7STNsXnlUNeuGHKvL1lPYoaqXTnQoF+DTluAoTKzRH5BPDhSTQDLI6OvK1S5PEqt+t7
         Dcww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733902511; x=1734507311;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=0te3i6s3e3e9P1sHuBoAmyFLAx8P4clDSX5l8m/TTUU=;
        b=l0s+7/3N06ogazMkM4N0Zpd1UbJ0DTcLD1XKyaa2DuEqqf6yJnqPXUG0gNqH/Y7O0Y
         ZaoARvWZ3pVe1z2QUH6eQ/iZdGVJRXJIVQxejNE6nNJ6pITKZjWWA8xvwWT71bxTBWJB
         FduDyB19pYtMraY+m9EI6DAuXJXvbASZ7Yi8LsCFSNnw7FM2SgJ5kGDz3Gjuaw7b0L8e
         WvVzqzleWCDS2c7HQJBa4d19pt3WIe5WAA/Hk+ZxMUnwkox62BOFsJME+vxEv/pBSL2D
         EUybL4OjXSBH2tcMEOeJj469XHD8u0jiVHpwXHeo/xqN47uDzhfcUP2Z0AZkerhJjPRT
         X1Ew==
X-Forwarded-Encrypted: i=1; AJvYcCUf5ok7PsWkcVf/hVv/5Z/DxMCekwZ2vsX1k7yqNJCmHLiwXa1x3dJ9z4Nb/iTsLf/fjIbn5oYeNPc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyhledQa+54BauW9bbPgxfcHqCeMHS+67K/ymJLm+Dq+xeL9aMY
	IXaOHUjhzs8M4ni+ni0csM+nuOi4e2GBVO6Ch3bvD/y4n4XpZu4KU49fadZ4XA==
X-Gm-Gg: ASbGncugZnthcYHJp2kPIypyaOXDosNHxdUPjRkL2Hfp8JtYZxvr1Opj3UPVMUtxFhV
	gpWYgUN/JifgGBfSevtabCCaK7G8QXVrMrgUk2VlzHk0e6WrCN/uBReaL+CwJK5bypEt/Ibzf9j
	YEEiX/cojD/CIENJJ7uUAbRNjvYaIPvkhGDn/fmM6Q2wjwF/2ra4kJUYRkewyvPKmWmlCJb9YM5
	h+f9q7/zuqZieeMsI+Q/y4yesS81oDtOmGxmKd6E8VikqllgYB/eAPcxEpfOSy9HAcKTzHp4HK8
	poJtfxbuRb/R6KJCCF4ep9U/quP+KjdPTcgdPnk=
X-Google-Smtp-Source: AGHT+IFeMeerjoDELT58pwYtFBTLaoTzYHv5JumaFPflPpwERj0FG3o4rGMDm4mkXuy8eMrO8VGs9Q==
X-Received: by 2002:a05:6000:440c:b0:386:1cf9:b96e with SMTP id ffacd0b85a97d-3864ced8b04mr916435f8f.55.1733902511574;
        Tue, 10 Dec 2024 23:35:11 -0800 (PST)
Message-ID: <3f9d8b51-4542-4ac4-af60-d1afcf6281b5@suse.com>
Date: Wed, 11 Dec 2024 08:35:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 34/35] xen/console: enable console owners w/ emulated
 NS8250
To: Jason Andryuk , dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-34-e9aa923127eb@ford.com>
 <1b55c7eb-3e39-43d1-80d2-2d4caf6a0c76@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: <1b55c7eb-3e39-43d1-80d2-2d4caf6a0c76@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.12.2024 23:46, Jason Andryuk wrote:
> On 2024-12-05 23:42, Denis Mukhin via B4 Relay wrote:
>> From: Denis Mukhin 
>>
>> Enable console focus for domains w/ virtual NS8250.
>>
>> Code change allows to capture the output from the guest OS now and send it to
>> the physical console device.
>>
>> Signed-off-by: Denis Mukhin 
>> ---
>>   xen/drivers/char/console.c | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
>> index a26daee9c4c4b1134d0ae3d105ffdb656340b6df..798dfdf3412a2feef35e72946d6c59bee59a9251 100644
>> --- a/xen/drivers/char/console.c
>> +++ b/xen/drivers/char/console.c
>> @@ -41,6 +41,9 @@
>>   #ifdef CONFIG_SBSA_VUART_CONSOLE
>>   #include 
>>   #endif
>> +#if defined(CONFIG_HAS_VUART_NS8250)
>> +#include 
>> +#endif
>>   
>>   /* console: comma-separated list of console outputs. */
>>   static char __initdata opt_console[30] = OPT_CONSOLE_STR;
>> @@ -627,6 +630,8 @@ static void handle_keypress_in_domain(struct domain *d, char c)
>>       {
>>   #if defined(CONFIG_SBSA_VUART_CONSOLE)
>>           rc = vpl011_rx_char_xen(d, c);
>> +#elif defined(CONFIG_HAS_VUART_NS8250)
>> +        rc = vuart_putchar(&d->arch.hvm.vuart, c);
>>   #endif
> 
> I think it would be nicer to just use a single name and avoid ifdef-ery. 
>   vuart_putchar() is generic and matches domain_has_vuart(), so that 
> seems good.
> 
> You can then have a default stub that returns -ENODEV for when an 
> implementation is not built.  (This goes along with Jan's suggestion of 
> a common, default domain_has_vuart().)  Something like:
> 
> #ifndef vuart_putchar
> static inline int vuart_putchar(struct domain *d, char c) {
>      return -ENODEV;
> }
> #define vuart_putchar vuart_putchar
> #endif
> 
> and ARM can do:
> #define vuart_putchar vpl011_rx_char_xen

+1

Jan


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 07:38:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 07:38:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853939.1267262 (Exim 4.92)
	(envelope-from )
	id 1tLHIT-00004q-CC; Wed, 11 Dec 2024 07:38:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853939.1267262; Wed, 11 Dec 2024 07:38: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 1tLHIT-0008WP-9a; Wed, 11 Dec 2024 07:38:13 +0000
Received: by outflank-mailman (input) for mailman id 853939;
 Wed, 11 Dec 2024 07:38: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 1tLHIR-0008WJ-6l
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 07:38:11 +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 de84ea60-b792-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 08:38:10 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-385ddcfc97bso4857170f8f.1
 for ; Tue, 10 Dec 2024 23:38: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
 41be03b00d2f7-7fd4757691dsm5229682a12.18.2024.12.10.23.38.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 23:38: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: de84ea60-b792-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733902689; x=1734507489; 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=w8Hkm5oEcWa2S6aIY72eEl0XhJPFVlHxv7JbIStkNP4=;
        b=AiDZX/eOA+0GBjDwMIFuVditf5For4k0OnD6hmSc/qONJGkYz5p1BUx+4uuC5DZsJs
         9Mo8mqIBmpSoQ2GZMZrx5/XrC3CpfgPU2w0Bwif3XgkWvpm6l1iJoP65UJINpqegWNFw
         qJ4+o1EmgWakGMBGBgG6rM3uNLSLVM8gSuzbID3NyTJz3U28e0Vlpu3/HpVR2MiWbLwT
         9yP0A2lqdSLI0XnS25jdq+Sp7XxensVnSlVohm8CwRapdEiDb/O1ysATA0CD4STPA7wC
         tddcjFUYEufxQeMH1DAJxSuRfsCSN8F+fEE1CitvFf8TPWyuNpr0iosc+HsuGLQxZ4T+
         DMWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733902689; x=1734507489;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=w8Hkm5oEcWa2S6aIY72eEl0XhJPFVlHxv7JbIStkNP4=;
        b=vVw654vbioGVJyXRoI4Vi+HkSDIcm04MaLAfpR7f1gFI8Td7ijJDlBvMCYd2XX1l0l
         yoea0TF3qCqC6WPYcmEYW18W1WipKsTFzWFBxuCZTlaYlcoScDIkkgVcOHxnV8BG3PkB
         /g0l51WY5JHLvHifdJyBsJKuM0NlpbJPYe4BjTLkyCme7E2FN/yvtPflSdP4sM6neb2p
         am8Rd5MluqdmeSrq/lNxWOSv2Qt1fMs21R6IhihkOrZRYqf5vfSBMYmQwHtb1yXIkuj0
         JV2N1cAbhF9DaBUVgKfJ+n0uC3C/wu4nTCbJqPJbU0gxJdAVdCCH8fx6XweZczbiNvqt
         XDRA==
X-Forwarded-Encrypted: i=1; AJvYcCWnGZ/3T0HOThaN5GTVt9edU/SSeKIWuFAAujmvOUqY1fs6CRwtv7gkVWcSyfKDsln7emsk3u+GD+A=@lists.xenproject.org
X-Gm-Message-State: AOJu0YylHXy5TKhEshP3WOcvGWFqMTyXlfpP3zUBChZxR885v8tBwe7k
	5Ip2OY7C5mBj9YIod5QbItkmRtBdRjXLRbtZKMRtd++1BzhUXoNiS8ancK3ALQ==
X-Gm-Gg: ASbGnctT13U6tdiTEIV0Z+GRhJNc6UzDpqebWHeg7h1nwjYXGCC5WeVngK/A7LQO7JK
	gmjoeX+XKoGuNJP+EKsMDwyMe8EeKFpleTbaBU8vA56CQZUYAoamCCKoyOAepTZsN6KKH+oBPZB
	JuC6r5t+JI5EQcdEYw2Z2EWHohTwbE7y0dbmiVj04xxOimhX1U2g1cilCLuU1DHq5eOXfkyQ3+z
	YZT6eq/Z+m7S408LsYWLoFxQS492w+MT+InjW2xtagmqskMzewhbYZi+xiTBM9cPU7oAAFo65Dn
	V6Xw7c4KFJ5a0YrOYsOyk+h8ERUM8MwkvElbCC4=
X-Google-Smtp-Source: AGHT+IGSeIg3dtIAR19TTb84TzLuFh9cJKbVrXrKNsucUCpcBVGpL2CpFxl2NeBDSoKs8rtNEoFcXg==
X-Received: by 2002:a05:6000:1a86:b0:386:3e87:2cd6 with SMTP id ffacd0b85a97d-3864cec5761mr1294399f8f.38.1733902689429;
        Tue, 10 Dec 2024 23:38:09 -0800 (PST)
Message-ID: <9fbe795c-f580-4084-9ab4-dede708cd777@suse.com>
Date: Wed, 11 Dec 2024 08:38:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 34/35] xen/console: enable console owners w/ emulated
 NS8250
To: Jason Andryuk , dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-34-e9aa923127eb@ford.com>
 <1b55c7eb-3e39-43d1-80d2-2d4caf6a0c76@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: <1b55c7eb-3e39-43d1-80d2-2d4caf6a0c76@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 10.12.2024 23:46, Jason Andryuk wrote:
> On 2024-12-05 23:42, Denis Mukhin via B4 Relay wrote:
>> From: Denis Mukhin 
>>
>> Enable console focus for domains w/ virtual NS8250.
>>
>> Code change allows to capture the output from the guest OS now and send it to
>> the physical console device.
>>
>> Signed-off-by: Denis Mukhin 
>> ---
>>   xen/drivers/char/console.c | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
>> index a26daee9c4c4b1134d0ae3d105ffdb656340b6df..798dfdf3412a2feef35e72946d6c59bee59a9251 100644
>> --- a/xen/drivers/char/console.c
>> +++ b/xen/drivers/char/console.c
>> @@ -41,6 +41,9 @@
>>   #ifdef CONFIG_SBSA_VUART_CONSOLE
>>   #include 
>>   #endif
>> +#if defined(CONFIG_HAS_VUART_NS8250)
>> +#include 
>> +#endif
>>   
>>   /* console: comma-separated list of console outputs. */
>>   static char __initdata opt_console[30] = OPT_CONSOLE_STR;
>> @@ -627,6 +630,8 @@ static void handle_keypress_in_domain(struct domain *d, char c)
>>       {
>>   #if defined(CONFIG_SBSA_VUART_CONSOLE)
>>           rc = vpl011_rx_char_xen(d, c);
>> +#elif defined(CONFIG_HAS_VUART_NS8250)
>> +        rc = vuart_putchar(&d->arch.hvm.vuart, c);
>>   #endif
> 
> I think it would be nicer to just use a single name and avoid ifdef-ery. 
>   vuart_putchar() is generic and matches domain_has_vuart(), so that 
> seems good.
> 
> You can then have a default stub that returns -ENODEV for when an 
> implementation is not built.  (This goes along with Jan's suggestion of 
> a common, default domain_has_vuart().)  Something like:
> 
> #ifndef vuart_putchar
> static inline int vuart_putchar(struct domain *d, char c) {
>      return -ENODEV;
> }
> #define vuart_putchar vuart_putchar
> #endif
> 
> and ARM can do:
> #define vuart_putchar vpl011_rx_char_xen
> 
> x86 would need to change its arguments, but that should be straight forward.

Actually, I don't even see a need for the stub:

    {
#ifdef vuart_putchar
        rc = vuart_putchar(d, c);
#endif
     }

This way behavior won't change from what there is now, when vuart_putchar()
isn't defined.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 07:42:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 07:42:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853952.1267273 (Exim 4.92)
	(envelope-from )
	id 1tLHMh-0002VF-U7; Wed, 11 Dec 2024 07:42:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853952.1267273; Wed, 11 Dec 2024 07:42: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 1tLHMh-0002V8-Ps; Wed, 11 Dec 2024 07:42:35 +0000
Received: by outflank-mailman (input) for mailman id 853952;
 Wed, 11 Dec 2024 07:42: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 1tLHMg-0002V2-Iq
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 07:42:34 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7af6d434-b793-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 08:42:33 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 0D3F25C5531;
 Wed, 11 Dec 2024 07:41:49 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6363CC4CED2;
 Wed, 11 Dec 2024 07:42: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: 7af6d434-b793-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1733902951;
	bh=2uMUDx+CZ3m3qrGORQssIpf9SkBZEr5sXYGVq8CLbbk=;
	h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
	b=lzCs9W07TRdYy9JWVA19UEcEu4CvACr8Yh0wQYYSfGHV9Xmm3k/fpbGlRqmHhrV+4
	 m+NXNTf0ojEsKvo2HABNezvu0E3y4f8qwtj50O+Tpecim7ilciV/YQzBLNsRpBxgh2
	 kFcAO8hw1xQeAKLLWrzRXln1VFfP4BsLZkJYWlflCYYKj1xjZBYezOsESJaMXsh8Tr
	 hQ+/FOtWX9XeTV7X9iJbxMRHo8S8Byh7AJhYOGIti6Ul764xlpsl746ormGsN6d2KW
	 ZfV5twBXO7B+t0Fxemw7h0pYOWhdCFQdt/A+Rzvz9BButSX+3CHe4CYkaTdr1ABqIe
	 IMFDpd1/B9rEg==
From: Kalle Valo 
To: Easwar Hariharan 
Cc: Pablo Neira Ayuso ,  Jozsef Kadlecsik
 ,  "David S. Miller" ,  Eric
 Dumazet ,  Jakub Kicinski ,  Paolo
 Abeni ,  Simon Horman ,  Julia Lawall
 ,  Nicolas Palix ,  Daniel
 Mack ,  Haojian Zhuang ,
  Robert Jarzmik ,  Russell King
 ,  Heiko Carstens ,  Vasily
 Gorbik ,  Alexander Gordeev ,
  Christian Borntraeger ,  Sven Schnelle
 ,  Ofir Bitton ,  Oded Gabbay
 ,  Lucas De Marchi ,  Thomas
 =?utf-8?Q?Hellstr=C3=B6m?= ,  Rodrigo
 Vivi
 ,  Maarten Lankhorst
 ,  Maxime Ripard ,
  Thomas Zimmermann ,  David Airlie
 ,  Simona Vetter ,  Jeroen de Borst
 ,  Praveen Kaligineedi ,
  Shailend Chand ,  Andrew Lunn
 ,  James Smart ,  Dick
 Kennedy ,  "James E.J. Bottomley"
 ,  "Martin K. Petersen"
 ,  Roger Pau =?utf-8?Q?Monn=C3=A9?=
 ,
  Jens Axboe ,  Jeff Johnson ,
  Catalin Marinas ,  Andrew Morton
 ,  Jack Wang ,
  Marcel Holtmann ,  Johan Hedberg
 ,  Luiz Augusto von Dentz ,
  Greg Kroah-Hartman ,  Florian Fainelli
 ,  Ray Jui ,  Scott
 Branden ,  Broadcom internal kernel review list
 ,  Xiubo Li ,
  Ilya Dryomov ,  Josh Poimboeuf ,
  Jiri Kosina ,  Miroslav Benes ,  Petr
 Mladek ,  Joe Lawrence ,
  Jaroslav Kysela ,  Takashi Iwai ,  Louis
 Peens ,  Michael Ellerman ,
  Nicholas Piggin ,  Christophe Leroy
 ,  Naveen N Rao ,
  Madhavan Srinivasan ,
  netfilter-devel@vger.kernel.org,  coreteam@netfilter.org,
  netdev@vger.kernel.org,  linux-kernel@vger.kernel.org,  cocci@inria.fr,
  linux-arm-kernel@lists.infradead.org,  linux-s390@vger.kernel.org,
  dri-devel@lists.freedesktop.org,  intel-xe@lists.freedesktop.org,
  linux-scsi@vger.kernel.org,  xen-devel@lists.xenproject.org,
  linux-block@vger.kernel.org,  linux-wireless@vger.kernel.org,
  ath11k@lists.infradead.org,  linux-mm@kvack.org,
  linux-bluetooth@vger.kernel.org,  linux-staging@lists.linux.dev,
  linux-rpi-kernel@lists.infradead.org,  ceph-devel@vger.kernel.org,
  live-patching@vger.kernel.org,  linux-sound@vger.kernel.org,
  oss-drivers@corigine.com,  linuxppc-dev@lists.ozlabs.org,  Anna-Maria
 Behnsen ,  Jeff Johnson
 
Subject: Re: [PATCH v3 14/19] wifi: ath11k: Convert timeouts to
 secs_to_jiffies()
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
	<20241210-converge-secs-to-jiffies-v3-14-ddfefd7e9f2a@linux.microsoft.com>
Date: Wed, 11 Dec 2024 09:42:11 +0200
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-14-ddfefd7e9f2a@linux.microsoft.com>
	(Easwar Hariharan's message of "Tue, 10 Dec 2024 22:02:45 +0000")
Message-ID: <87sequr7ho.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain

Easwar Hariharan  writes:

> Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
> secs_to_jiffies(). As the value here is a multiple of 1000, use
> secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
>
> This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
> the following Coccinelle rules:
>
> @@ constant C; @@
>
> - msecs_to_jiffies(C * 1000)
> + secs_to_jiffies(C)
>
> @@ constant C; @@
>
> - msecs_to_jiffies(C * MSEC_PER_SEC)
> + secs_to_jiffies(C)
>
> Acked-by: Jeff Johnson 
> Signed-off-by: Easwar Hariharan 
> ---
>  drivers/net/wireless/ath/ath11k/debugfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I assume we can take this to our ath.git tree, please let us know if
that's not the case.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 07:43:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 07:43:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853965.1267282 (Exim 4.92)
	(envelope-from )
	id 1tLHNZ-00035f-8b; Wed, 11 Dec 2024 07:43:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853965.1267282; Wed, 11 Dec 2024 07:43: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 1tLHNZ-00035Y-5i; Wed, 11 Dec 2024 07:43:29 +0000
Received: by outflank-mailman (input) for mailman id 853965;
 Wed, 11 Dec 2024 07:43: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 1tLHNY-0002V2-Gq
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 07:43:28 +0000
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com
 [2a00:1450:4864:20::42c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9b1fc504-b793-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 08:43:26 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3862a921123so3732739f8f.3
 for ; Tue, 10 Dec 2024 23:43: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
 41be03b00d2f7-7fd50fe6a58sm3540740a12.11.2024.12.10.23.43.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 23:43: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: 9b1fc504-b793-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733903006; x=1734507806; 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=yecfDviozleLFbgf+wyb3xikWvF3rFEw92atT8UgzD0=;
        b=bR/EQE5753bQJ1Oz3Sdc5tyUKPtLKOJFIL6KB6fm6p9cvewEO1+LMdXfwwh5aGz0l8
         r30pvxZsd75akkomust8Rcoz5tRJGidrg8k9yxiJzzYm6zpcf3SARRktOcBx48Oxcnmf
         /E+EorHlYiLwxgVJSDjGrvB+ztdB3C77O5XC+qaLh4z6pTK6J18TAkuSPw0omGNCOQ+Q
         vrCEGXHxDuxqIwwmw7loQAB9IYiMsugSzAM0La3ZppKguUVwiPYnOTx13PuNu4dL3BOC
         9DzwSmfV/ctgqAhlDexLZ+XgC7/1meLD/rSWl/3k0ACnUvD4VRaqLDTDgsOcrQIFOI7g
         mtvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733903006; x=1734507806;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=yecfDviozleLFbgf+wyb3xikWvF3rFEw92atT8UgzD0=;
        b=h+9XJYZBib5b5UKE0Uon6b7m8XRJyJn8MSwszwv1b9qFQfpHdyWlYV8lENsujYtmnp
         cVlM82LifuotM5Lial1NwDSgCMCqwsOWaK4xuk2A3HoaRwsZDsmowt2WQhqIE/1NdZNm
         NPJuGD/4HTJ/OLad2jKDadNgU9hoGm2QeDD87ca8OyRGSGbVxZ8PKiyt/KR2YcO0Sxt1
         F1EFQ3JfmU2gR1LJtW1lwTTrc84BTzuqLIcFWcCP1foYh/hqGZP0tUclTSpHJFB53xw4
         oAHEdGO2h5Cx1/ZNb/GIkjEecECd3bKqoi2KCVwvMGH6daJrPzGrt021yL0eDAHR8+tJ
         3adA==
X-Forwarded-Encrypted: i=1; AJvYcCVdw3dWdPIeXLAkwZ7IkcEu7PGNQT74CtqdcJbwsbjMtCwJkHGHsO0r+pe5vymyx6t3VadlMNAhp6Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw3uhrzMHBMuI27t77JPCoR+ILm9GxF/elSuxrkJPMANOLCnAsP
	n3mPRMPEHUIluOz3iDRGy4YzE4eAzjO3T3sbakOJWpnepqhAFS7RbqtsfLQUFA==
X-Gm-Gg: ASbGncvQJfGkH1XMXDqYwnKYyPy1XkwKibuR5J+/zeih+vId5nbs6ARZIHaGdvsblW4
	cNlqkJEdSfAGUzhGjE1LtFxg1JRLOW0ifghQeGlz48cOkM2LsyGL73TrmjacoU8OuOwzt5Fg9rb
	CxlQgA218WIbgip+86kZS6mAjek0ojQk0hPScuz+XzsSdbbtXTpXmi1eewrEEbzeipxImkotR7w
	AU3RI7lSsZj4osI0OSBeN2DBLfXHbKgsW4BezME8YJX+2mCIad2A3WxUi2WUxqokxrlPYqpsvm2
	YaNPsIMkwle4PcNVpSe0+GzC5KNKWRfSQFFYoEU=
X-Google-Smtp-Source: AGHT+IGRB4Ux5OMiNJKTPqsP7hwft1q5TrVt1iybNQhpEfThW7Q7LDvpNRHt1y3M5ZPniC2hBAX66Q==
X-Received: by 2002:a05:6000:400c:b0:386:3560:477f with SMTP id ffacd0b85a97d-3864ce96ec6mr990134f8f.23.1733903005715;
        Tue, 10 Dec 2024 23:43:25 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 08:43:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] MAINTAINERS: add Anthony, Michal, Roger to THE REST
To: Stefano Stabellini ,
 xen-devel@lists.xenproject.org
Cc: kelly.choi@cloud.com, anthony.perard@vates.tech, michal.orzel@amd.com,
 roger.pau@cloud.com, committers@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 11.12.2024 00:58, Stefano Stabellini wrote:
> In recognition of their outstanding work and years of service to the Xen
> Community, please join me in welcoming Anthony, Michal, and Roger as
> Committers and REST Maintainers.
> 
> Signed-off-by: Stefano Stabellini 

Acked-by: Jan Beulich 
albeit ...

> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -662,8 +662,11 @@ K:	\b(xsm|XSM)\b
>  
>  THE REST
>  M:	Andrew Cooper 
> +M:	Anthony PERARD 
> +M:	Michal Orzel 
>  M:	Jan Beulich 
>  M:	Julien Grall 
> +M:	Roger Pau Monné 
>  M:	Stefano Stabellini 
>  L:	xen-devel@lists.xenproject.org
>  S:	Supported

... isn't this meant to be alphabetically sorted, in which case Michal would
need to move down a little?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 07:44:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 07:44:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853976.1267293 (Exim 4.92)
	(envelope-from )
	id 1tLHOt-0003e3-Ij; Wed, 11 Dec 2024 07:44:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853976.1267293; Wed, 11 Dec 2024 07: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 1tLHOt-0003dw-Fn; Wed, 11 Dec 2024 07:44:51 +0000
Received: by outflank-mailman (input) for mailman id 853976;
 Wed, 11 Dec 2024 07:44: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 1tLHOs-0003do-63
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 07:44:50 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cbcce425-b793-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 08:44:48 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-385df53e559so4334749f8f.3
 for ; Tue, 10 Dec 2024 23:44:48 -0800 (PST)
Received: from ?IPV6:2003:e5:8701:7700:f2d:e3aa:8e9e:99bf?
 (p200300e5870177000f2de3aa8e9e99bf.dip0.t-ipconnect.de.
 [2003:e5:8701:7700:f2d:e3aa:8e9e:99bf])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3878251bc16sm647457f8f.86.2024.12.10.23.44.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 23:44: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: cbcce425-b793-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733903087; x=1734507887; 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=lple0WAmTTtnF6BRMys+naYMN3+WtKjnqDz2VMiUppw=;
        b=DD3I6k7idVUyDKRw6cR1mRGi309cfY6v41vHuj0LNsNl9ds5tS9+xti/NdeIqGlxLu
         OSyQxO/5nqPiAlLUYTOVDgsqTBafKJiZHykDQnI7CPekBjr3YePr/SMoHiFvmPVgj9vf
         JSP9orlgD1coMrLcxFyIudSq95WzHzVAPVvRMfP/kvJclL3XfLuzDX/p2DdZFQVGjt0Q
         hLp/3lkQpdiuRb89bF32lIo3V36VFZU3ZfKrY8+gE9xsosQJNJLqnwRDQIUCnqW5GnYd
         dRkP8Bp7WH65E3zeLyQkZxjyBe1VKVzIHWo5UaQ4mUA4Fc2P4X1jAL9M6oy9Lv2jE4qm
         Ilpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733903087; x=1734507887;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=lple0WAmTTtnF6BRMys+naYMN3+WtKjnqDz2VMiUppw=;
        b=AeBUXLWeUHr5RjCSgkmo17tQ7kK10bES60zKi0wrd9nDyjPnECj7tT83E1OYaBUCHC
         aBYnAjpiKhS+TLrCQ4O3cZdCPA4Z7SFczkmwlbK3pJvSzj4DY8I+Rs1mpjmvJthbGuqj
         UDL33TTolNgPL8a/QwGl70LYPrfYB7iiNcvzl6zthy99iyf6F1Vrvik94Eb/w47CU6JY
         iFFma6I40BbrO/CIpazhB7oJ0pk/Fxr//Y+FOTUproSDNI+lckDvZGffpPYcOYPx7Nm/
         ahQEy06BAzztq4o+r9Z8b14u+6UPMb81ZmBvt4rW52VXN1UbV134PSNauCNKKmjp9LS/
         jzUw==
X-Forwarded-Encrypted: i=1; AJvYcCUe+RGXV/pSIwRdDjMInmIvX974VHQSVUl8NEAXQSx3IySk5EEYlqlreeQAd3O7UHKvjwMYB5BMR90=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyTOR00DHcinWQD3ePia/FlzK3qSv3r5BIcoFp0yX/JRWWibWwb
	C4YOt4aEpBbwGR7KRwqCpDUiDXX5hKfCNOnbU2snpLssE3qrImd+p8UKRnNV2wY=
X-Gm-Gg: ASbGnct9iiRCMRKhE/symwNludCDATwln72YZdctsHvY+9YLEfG/s4K8Q9uYw9FeqFx
	E6a0ODdsoRH2aedHxaZtew9UGFYGnfkSuFIeB65IWsal8fNR63kVhtsXat6BsxQ48diZZGNszlQ
	EPlakA54e/29+O8pUyq5FBy4CXEGoS9eODgYA/d9Pu+aOI5Og3ODNc8aIrVe6tFfGbqTu8qhUyg
	tEYuyWzcvmkXUqHkGOiq8IsS9N6il5nXL1L+PF3RI0pGd1LjxmtKkb7YBc5uBWWpJsH3MpjSr4J
	N1Fd4U1U1vkywd9pueB6ZcZCpPp4X7mCXJcSYkt94X0XAvhfz2EuEMxvrXAcp4Hi6RB4YrSvKP1
	F
X-Google-Smtp-Source: AGHT+IGNv5YP2juyGZpQMEuKqJ56fqDC5Wjnlh9aX5OLHc7/75vnWKFnHFg2nhjIGWCicO+uuSqPEg==
X-Received: by 2002:a05:6000:42c6:b0:385:f6de:6266 with SMTP id ffacd0b85a97d-3864cea1eaamr915170f8f.24.1733903087382;
        Tue, 10 Dec 2024 23:44:47 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 08:44:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/7] xen: add new domctl get_changed_domain
To: Jan Beulich 
Cc: "Daniel P. Smith" ,
 Anthony PERARD ,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241206130221.17773-1-jgross@suse.com>
 <20241206130221.17773-6-jgross@suse.com>
 <69e08251-c227-42a5-a2e4-a4eb7d63961d@suse.com>
 <30304914-f0c5-4053-ae23-890fa5b8a0c2@suse.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: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------2GlcpF0tg9LWXT80a5IV1pVz"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------2GlcpF0tg9LWXT80a5IV1pVz
Content-Type: multipart/mixed; boundary="------------FYiImZLX7DTBYS6ytuvThDdZ";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jan Beulich 
Cc: "Daniel P. Smith" ,
 Anthony PERARD ,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
Message-ID: 
Subject: Re: [PATCH v2 5/7] xen: add new domctl get_changed_domain
References: <20241206130221.17773-1-jgross@suse.com>
 <20241206130221.17773-6-jgross@suse.com>
 <69e08251-c227-42a5-a2e4-a4eb7d63961d@suse.com>
 <30304914-f0c5-4053-ae23-890fa5b8a0c2@suse.com>
 
In-Reply-To: 
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------FYiImZLX7DTBYS6ytuvThDdZ
Content-Type: multipart/mixed; boundary="------------8trdgdO3bPLJNafea9Cwkvbh"

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

T24gMTAuMTIuMjQgMTc6MjksIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxMC4xMi4yMDI0
IDE2OjUyLCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPj4gT24gMDkuMTIuMjQgMTg6MDQsIEph
biBCZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDA2LjEyLjIwMjQgMTQ6MDIsIEp1ZXJnZW4gR3Jv
c3Mgd3JvdGU6DQo+Pj4+IC0tLSBhL3hlbi9jb21tb24vZG9tYWluLmMNCj4+Pj4gKysrIGIv
eGVuL2NvbW1vbi9kb21haW4uYw0KPj4+PiBAQCAtMTkyLDYgKzE5Miw1NCBAQCBzdGF0aWMg
dm9pZCBkb21haW5fY2hhbmdlZF9zdGF0ZShjb25zdCBzdHJ1Y3QgZG9tYWluICpkKQ0KPj4+
PiAgICAgICAgc3Bpbl91bmxvY2soJmRvbV9zdGF0ZV9jaGFuZ2VkX2xvY2spOw0KPj4+PiAg
ICB9DQo+Pj4+ICAgIA0KPj4+PiArc3RhdGljIHZvaWQgc2V0X2RvbWFpbl9zdGF0ZV9pbmZv
KHN0cnVjdCB4ZW5fZG9tY3RsX2dldF9kb21haW5fc3RhdGUgKmluZm8sDQo+Pj4+ICsgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qgc3RydWN0IGRvbWFpbiAqZCkN
Cj4+Pj4gK3sNCj4+Pj4gKyAgICBpbmZvLT5zdGF0ZSA9IFhFTl9ET01DVExfR0VURE9NU1RB
VEVfU1RBVEVfRVhJU1Q7DQo+Pj4+ICsgICAgaWYgKCBkLT5pc19zaHV0X2Rvd24gKQ0KPj4+
PiArICAgICAgICBpbmZvLT5zdGF0ZSB8PSBYRU5fRE9NQ1RMX0dFVERPTVNUQVRFX1NUQVRF
X1NIVVRET1dOOw0KPj4+PiArICAgIGlmICggZC0+aXNfZHlpbmcgPT0gRE9NRFlJTkdfZGVh
ZCApDQo+Pj4+ICsgICAgICAgIGluZm8tPnN0YXRlIHw9IFhFTl9ET01DVExfR0VURE9NU1RB
VEVfU1RBVEVfRFlJTkc7DQo+Pj4NCj4+PiBUaGUgcHVibGljIGNvbnN0YW50IHNheWluZyAi
ZHlpbmciIGlzbid0IHF1aXRlIGluIGxpbmUgd2l0aCB0aGUgaW50ZXJuYWwNCj4+PiBjb25z
dGFudCBzYXlpbmcgImRlYWQiLiBJdCBtYXkgd2VsbCBiZSB0aGF0IFhlbnN0b3JlIG9ubHkg
Y2FyZXMgYWJvdXQgdGhlDQo+Pj4gImRlYWQiIHN0YXRlLCBidXQgdGhlbiBpdCB3b3VsZCBi
ZXR0ZXIgYmUgbmVtYWVkIHRoaXMgd2F5IGFsc28gaW4gdGhlDQo+Pj4gcHVibGljIGludGVy
ZmFjZSwgSSB0aGluay4NCj4+DQo+PiBPa2F5LCBJJ2xsIHJlbmFtZSBpdCB0byAiWEVOX0RP
TUNUTF9HRVRET01TVEFURV9TVEFURV9ERUFEIi4NCj4gDQo+IFdlbGwsIG1heWJlIGhhdmUg
Ym90aCBEWUlORyBhbmQgREVBRCwgZXZlbiBpZiBYZW5zdG9yZSByaWdodCBub3cgbmVlZHMg
b25seSBvbmU/DQoNClllcywgbWlnaHQgYmUgaW50ZXJlc3RpbmcgaW4gdGhlIGZ1dHVyZS4N
Cg0KPiANCj4+Pj4gQEAgLTg2Niw2ICs4NzMsMTUgQEAgbG9uZyBkb19kb21jdGwoWEVOX0dV
RVNUX0hBTkRMRV9QQVJBTSh4ZW5fZG9tY3RsX3QpIHVfZG9tY3RsKQ0KPj4+PiAgICAgICAg
ICAgICAgICAgICAgX19IWVBFUlZJU09SX2RvbWN0bCwgImgiLCB1X2RvbWN0bCk7DQo+Pj4+
ICAgICAgICAgICAgYnJlYWs7DQo+Pj4+ICAgIA0KPj4+PiArICAgIGNhc2UgWEVOX0RPTUNU
TF9nZXRfZG9tYWluX3N0YXRlOg0KPj4+PiArICAgICAgICByZXQgPSB4c21fZ2V0X2RvbWFp
bl9zdGF0ZShYU01fWFNfUFJJViwgZCk7DQo+Pj4+ICsgICAgICAgIGlmICggcmV0ICkNCj4+
Pj4gKyAgICAgICAgICAgIGJyZWFrOw0KPj4+PiArDQo+Pj4+ICsgICAgICAgIGNvcHliYWNr
ID0gMTsNCj4+Pj4gKyAgICAgICAgcmV0ID0gZ2V0X2RvbWFpbl9zdGF0ZSgmb3AtPnUuZ2V0
X2RvbWFpbl9zdGF0ZSwgZCwgJm9wLT5kb21haW4pOw0KPj4+PiArICAgICAgICBicmVhazsN
Cj4+Pg0KPj4+IEVzcGVjaWFsbHkgd2l0aCB0aGlzIGJlaW5nIGEgc3RhYmxlIGludGVyZmFj
ZSwgc3VyZWx5IHRoZSB0d28gcGFkZGluZyBmaWVsZHMNCj4+PiB3YW50IGNoZWNraW5nIHRv
IGJlIHplcm8gb24gaW5wdXQgKHRvIHBvc3NpYmx5IGFsbG93IHRoZWlyIGZ1dHVyZSB1c2Ug
Zm9yDQo+Pj4gc29tZXRoaW5nIGlucHV0LWlzaCkuIFRoZW4gZXZlbiB0aGUgbWVtc2V0KCkg
aW4gdGhlIGZ1bmN0aW9uIG1heSBub3QgcmVhbGx5DQo+Pj4gYmUgbmVlZGVkLg0KPj4NCj4+
IEknbGwgYWRkIHRoZSBjaGVjay4gUmVtb3ZpbmcgdGhlIG1lbXNldCgpIGlzIGEgbGl0dGxl
IGJpdCBkb3VidGZ1bCwgYXMgdGhpcw0KPj4gbWlnaHQgcmVzdWx0IGluIGxlYWtpbmcgaHlw
ZXJ2aXNvciBkYXRhIGUuZy4gaW4gY2FzZSBhIGRvbWFpbiBpc24ndCBleGlzdGluZw0KPj4g
KHRoaXMgd2lsbCBjb3B5IHRoZSBpbnRlcm5hbCBzdHJ1Y3QgdG8gdGhlIHVzZXIgZXZlbiBp
biB0aGUgLUVOT0VOVCBjYXNlKS4NCj4gDQo+IFdoaWNoIGludGVybmFsIHN0cnVjdD8gVGhl
IGZ1bmN0aW9uIGlzIHBhc3NlZCAmb3AtPi4uLiBmb3IgYm90aCBwYXJhbWV0ZXJzLg0KPiBB
bmQgb3AgaXMgZnVsbHkgY29waWVkIGZyb20gZ3Vlc3Qgc3BhY2UuDQoNClNpZ2guIEkgc2hv
dWxkbid0IGhhdmUgYW5zd2VyZWQgc28gcXVpY2tseSB3aGlsZSBiZWluZyBkZWVwIGludG8g
b3RoZXINCnRvcGljcy4gOi0oDQoNCldoaWxlIEkgYWdyZWUgdGhhdCB0aGUgY2FsbGVyIF9z
aG91bGRfIHBhc3MgdGhlc2UgZmllbGRzIHplcm9lZCwgSSdtIHN0aWxsDQpub3Qgc3VyZSB3
ZSBzaG91bGQgcmVseSBvbiBpdC4gRG8geW91IGluc2lzdCBvbiByZW1vdmluZyB0aGUgbWVt
c2V0KCk/IElmDQpub3QgSSdkIHJhdGhlciBrZWVwIGl0Lg0KDQoNCkp1ZXJnZW4NCg==
--------------8trdgdO3bPLJNafea9Cwkvbh
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-----

--------------8trdgdO3bPLJNafea9Cwkvbh--

--------------FYiImZLX7DTBYS6ytuvThDdZ--

--------------2GlcpF0tg9LWXT80a5IV1pVz
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/Ey8FAmdZQu0FAwAAAAAACgkQsN6d1ii/Ey/K
xwf+PNHwnTJ1h+RjEAvIxs/GmAWVsOw+COOzzhzjmG8YKU8JvGxQ1ZZ8plu8AELRYlFZ/4xBxozq
7n9lebFDhov/jR0o0oxt06eWzMlvd32118kWvGrnvAJ9Ozu+fRFtU1/EWFUxU/UR/rfgNSa8QxcB
fSHzhIQehTMVP73z9d2eE/kzgl43vKAzM2PTwRGya4aT9eCiMBvvtRvklzDcsuoyzclkMznnUgiv
5yF7ujLXKNl+1DW5c3G9ETc2s3U+emE7RkL0Mw3TwPUP4ECeK4Qq/T4D2hDZIcEUneuqsDP7zaMA
2tBCNX08qnkxwbd22gYA9ftW3NR4ABKE1L3XS4YFkQ==
=6105
-----END PGP SIGNATURE-----

--------------2GlcpF0tg9LWXT80a5IV1pVz--


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 07:45:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 07:45:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.853986.1267302 (Exim 4.92)
	(envelope-from )
	id 1tLHPn-0004Ad-Rm; Wed, 11 Dec 2024 07:45:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 853986.1267302; Wed, 11 Dec 2024 07:45: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 1tLHPn-0004AW-Od; Wed, 11 Dec 2024 07:45:47 +0000
Received: by outflank-mailman (input) for mailman id 853986;
 Wed, 11 Dec 2024 07:45: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 1tLHPm-0003do-Kr
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 07:45:46 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ed66f1c5-b793-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 08:45:44 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 7D087A41F45;
 Wed, 11 Dec 2024 07:43:52 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8A77C4CED2;
 Wed, 11 Dec 2024 07:45:25 +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: ed66f1c5-b793-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1733903143;
	bh=KM5Of7mM53fIwBBiaYiiUQ9BfxtVrpykBzubAzmUdlE=;
	h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
	b=ZaN44YyjhRMRn1ZZ+GmTOS40UgIRbhL4wBsfJy8XjSPG4QXarlwE2h8LLmlSyCwwE
	 mhsyVMxQDuDVaxW28PxQeU8er7lMNhKnh1DPb1k4CbIDr8a5tkumkBV/uTN9xwnFYp
	 h1HNwJmQE+rv8LC4BNlfDvTcPd5XXQGZmdVG4PmZqn4aLOwa4oWj50GSY3CEXVAf2K
	 4s9JO62HtV4AyzHzBTTKIyxerUXbJDme/tcsfk9nrdzoiXAN6SWU/JWU3UcTsBRxgt
	 rxzg89ETMye2AN+BOVUz+OAR29EzCnQNdPIoMqWIY7xMbpGfvp3pWcUv4qGp3pyh75
	 7MY47GTKlC4gQ==
From: Kalle Valo 
To: Easwar Hariharan 
Cc: Pablo Neira Ayuso ,  Jozsef Kadlecsik
 ,  "David S. Miller" ,  Eric
 Dumazet ,  Jakub Kicinski ,  Paolo
 Abeni ,  Simon Horman ,  Julia Lawall
 ,  Nicolas Palix ,  Daniel
 Mack ,  Haojian Zhuang ,
  Robert Jarzmik ,  Russell King
 ,  Heiko Carstens ,  Vasily
 Gorbik ,  Alexander Gordeev ,
  Christian Borntraeger ,  Sven Schnelle
 ,  Ofir Bitton ,  Oded Gabbay
 ,  Lucas De Marchi ,  Thomas
 =?utf-8?Q?Hellstr=C3=B6m?= ,  Rodrigo
 Vivi
 ,  Maarten Lankhorst
 ,  Maxime Ripard ,
  Thomas Zimmermann ,  David Airlie
 ,  Simona Vetter ,  Jeroen de Borst
 ,  Praveen Kaligineedi ,
  Shailend Chand ,  Andrew Lunn
 ,  James Smart ,  Dick
 Kennedy ,  "James E.J. Bottomley"
 ,  "Martin K. Petersen"
 ,  Roger Pau =?utf-8?Q?Monn=C3=A9?=
 ,
  Jens Axboe ,  Jeff Johnson ,
  Catalin Marinas ,  Andrew Morton
 ,  Jack Wang ,
  Marcel Holtmann ,  Johan Hedberg
 ,  Luiz Augusto von Dentz ,
  Greg Kroah-Hartman ,  Florian Fainelli
 ,  Ray Jui ,  Scott
 Branden ,  Broadcom internal kernel review list
 ,  Xiubo Li ,
  Ilya Dryomov ,  Josh Poimboeuf ,
  Jiri Kosina ,  Miroslav Benes ,  Petr
 Mladek ,  Joe Lawrence ,
  Jaroslav Kysela ,  Takashi Iwai ,  Louis
 Peens ,  Michael Ellerman ,
  Nicholas Piggin ,  Christophe Leroy
 ,  Naveen N Rao ,
  Madhavan Srinivasan ,
  netfilter-devel@vger.kernel.org,  coreteam@netfilter.org,
  netdev@vger.kernel.org,  linux-kernel@vger.kernel.org,  cocci@inria.fr,
  linux-arm-kernel@lists.infradead.org,  linux-s390@vger.kernel.org,
  dri-devel@lists.freedesktop.org,  intel-xe@lists.freedesktop.org,
  linux-scsi@vger.kernel.org,  xen-devel@lists.xenproject.org,
  linux-block@vger.kernel.org,  linux-wireless@vger.kernel.org,
  ath11k@lists.infradead.org,  linux-mm@kvack.org,
  linux-bluetooth@vger.kernel.org,  linux-staging@lists.linux.dev,
  linux-rpi-kernel@lists.infradead.org,  ceph-devel@vger.kernel.org,
  live-patching@vger.kernel.org,  linux-sound@vger.kernel.org,
  oss-drivers@corigine.com,  linuxppc-dev@lists.ozlabs.org,  Anna-Maria
 Behnsen ,  Jeff Johnson
 
Subject: Re: [PATCH v3 14/19] wifi: ath11k: Convert timeouts to
 secs_to_jiffies()
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
	<20241210-converge-secs-to-jiffies-v3-14-ddfefd7e9f2a@linux.microsoft.com>
	<87sequr7ho.fsf@kernel.org>
Date: Wed, 11 Dec 2024 09:45:24 +0200
In-Reply-To: <87sequr7ho.fsf@kernel.org> (Kalle Valo's message of "Wed, 11 Dec
	2024 09:42:11 +0200")
Message-ID: <87o71ir7cb.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain

Kalle Valo  writes:

> Easwar Hariharan  writes:
>
>> Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
>> secs_to_jiffies(). As the value here is a multiple of 1000, use
>> secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
>>
>> This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
>> the following Coccinelle rules:
>>
>> @@ constant C; @@
>>
>> - msecs_to_jiffies(C * 1000)
>> + secs_to_jiffies(C)
>>
>> @@ constant C; @@
>>
>> - msecs_to_jiffies(C * MSEC_PER_SEC)
>> + secs_to_jiffies(C)
>>
>> Acked-by: Jeff Johnson 
>> Signed-off-by: Easwar Hariharan 
>> ---
>>  drivers/net/wireless/ath/ath11k/debugfs.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> I assume we can take this to our ath.git tree, please let us know if
> that's not the case.

Nevermind, I now saw the discussion in the cover letter and assume that
this patch will be sent separately.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 07:46:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 07:46:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854003.1267313 (Exim 4.92)
	(envelope-from )
	id 1tLHQm-0004m8-8j; Wed, 11 Dec 2024 07:46:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854003.1267313; Wed, 11 Dec 2024 07: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 1tLHQm-0004m1-5j; Wed, 11 Dec 2024 07:46:48 +0000
Received: by outflank-mailman (input) for mailman id 854003;
 Wed, 11 Dec 2024 07:46: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 1tLHQl-0004Wu-0n
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 07:46:47 +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 1268239c-b794-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 08:46:46 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-434e8aa84f7so37327025e9.0
 for ; Tue, 10 Dec 2024 23:46: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
 98e67ed59e1d1-2ef2708b807sm12793724a91.43.2024.12.10.23.46.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 23:46: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: 1268239c-b794-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733903206; x=1734508006; 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=cBqtTvH3R1pz0NEETzJ3MOIMbUmBCgNF/TTgWnNyT2U=;
        b=Il+XtDdB/evBxWLNk1WU2y/2SEW7TN1RA/9yYySrsFLF82vdp6LREBzqdiGra88458
         d+YEmv/KL5DaujvK8DGzjH9O1vOWMD7yXLpncvx/YeiAMNxC2JaF+BghDu85Ry4Qxt3R
         ASmIMBs8dBFo9BV+YrVsfdke/ZPB9uJkLDqieXDxN4+IU7di27RE3dOOd0+JQgw/KiaB
         W6eepLCsdYtZPa/OVzBKs3P9AKc98sQwwJopl4yQ98PStXphStjdw+EiRxW4VTqliy+C
         ZLA6gpjWi6fa7/Hokpodam7k2NMqcmQi3V1u/vHapCahx45qJykMyHeNdNoruAS95uir
         HaUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733903206; x=1734508006;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=cBqtTvH3R1pz0NEETzJ3MOIMbUmBCgNF/TTgWnNyT2U=;
        b=EWCxR2M1WT9GWzGFDunrpxJlmCy4NhGOssnrJ5MSamFfrYU2CafyDnOC6z7ixZm0zG
         1VqOvOYQWE9WB1I/zkTIKu5CHVrqwPbfwPYTnui6l5t695q+spYinsAGSst7bcyDNqmM
         fZsv2Jo3fkeKQdW/HrIkcpJlEwWvH1x1/bRCPy2z4dEcLarmVEpvwyIDh5cwJhGPQU4N
         fIl4Gb1OgpPXcEjxIlGWJYwAxEwokYd9ZMXoQ/gnwsBkevGIVMPs1NEWKCrV2hmO1Yee
         BclgWcQ67jVy9U7+nU4tDh+B1fODnKoazsFsGwwWUj/g3cNoiolleUOloJZyRE7ghVIJ
         NPbw==
X-Forwarded-Encrypted: i=1; AJvYcCW0bqWDQLKYN/5fmJvSRXfIty2iZhvoh1LGp6HUmoGSRQWpbPujmFIXwvuPHXpWvBbGZtUPcnFGvjU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwyGYXqO5igWAwuL0rk/N0fPeoQCGjuN4Dj8i0C1otDFdXlBM8/
	Ae52vE86Z/6Yic6+G5fMtyQ5BSC4O6vqu4Pkr3WiybaKgbB0pVcbhyso1uMvfw==
X-Gm-Gg: ASbGncuWvBOXo0nn1JoWrSutnWYlMRq1pRbAT6z0543Z2IlpBq/9B7OavmcRdQYT6pc
	ukfL936Oxxe4BjQFwTTXsTvK0p9eayo/pf55wKx0tZFcXqD/TCGjSjFpTym2BCdytr5p9g9rDr0
	I6mzd/D7+wRLwiyies2HAyh22CGf+j+07kzIwdhQX8vw8UmcgD9M0rqKaG6tEN3GQ804eEnuSDJ
	kWX4bJUf41c67N7gDYZxLo6S91cUYtdBNhW86e+WSjvX3m/AzadDCyzYkUM9/wgk/pWNPoKK0hu
	awJXqR+IxTp3bz3m+mMiGqC2riiCvRcT5dxsQGs=
X-Google-Smtp-Source: AGHT+IFDST+NwUbVRb9fWZdqCIA2B/IhslDvmwuJVfkQxy9k6AEgkAzPTBoXFSJXDTYH/meUNN2z3A==
X-Received: by 2002:a5d:5989:0:b0:385:fb2c:6034 with SMTP id ffacd0b85a97d-3864cec3a6emr1238840f8f.47.1733903205941;
        Tue, 10 Dec 2024 23:46:45 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 08:46:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/3] Add stack protector
To: Volodymyr Babchuk 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Samuel Thibault ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Bertrand Marquis ,
 Michal Orzel ,
 "xen-devel@lists.xenproject.org" 
References: <20241211020424.401614-1-volodymyr_babchuk@epam.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: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.12.2024 03:04, Volodymyr Babchuk wrote:
> Both GCC and Clang support -fstack-protector feature, which add stack
> canaries to functions where stack corruption is possible. This series
> makes possible to use this feature in Xen. I tested this on ARM64 and
> it is working as intended. Tested both with GCC and Clang.
> 
> It is hard to enable this feature on x86, as GCC stores stack canary
> in %fs:40 by default, but Xen can't use %fs for various reasons. It is
> possibly to change stack canary location new newer GCC versions, but
> this will change minimal GCC requirement, which is also hard due to
> various reasons. So, this series focus mostly on ARM and RISCV.

Why exactly would it not be possible to offer the feature when new enough
gcc is in use?

Jan


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 07:49:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 07:49:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854013.1267322 (Exim 4.92)
	(envelope-from )
	id 1tLHT8-0005MU-MM; Wed, 11 Dec 2024 07:49:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854013.1267322; Wed, 11 Dec 2024 07:49: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 1tLHT8-0005MN-J4; Wed, 11 Dec 2024 07:49:14 +0000
Received: by outflank-mailman (input) for mailman id 854013;
 Wed, 11 Dec 2024 07:49: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 1tLHT7-0005MH-9G
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 07:49:13 +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 689706ff-b794-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 08:49:11 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-4361c705434so2567825e9.3
 for ; Tue, 10 Dec 2024 23:49: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
 98e67ed59e1d1-2ef2700bb9asm12900735a91.19.2024.12.10.23.49.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 10 Dec 2024 23:49: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: 689706ff-b794-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733903350; x=1734508150; 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=YfmqqyM7+ybeKmdpaT8e8CdFNymTsVJO6P0YDkmCAXE=;
        b=aYdxVt61Lq71wiP12bxofLGPD6T0ZE71sRbkc1qRZ5jJOFlPlNlpB0ZPW2rFNEW5ND
         Y346hoVfl2ZgoGD/AhGM6TuZOWAn8yD4VtghZpCiQGzJ/A4/8lPoZvRx/ASp7QY4a0LL
         tRrf6HzweGM1RLkZ+OS0kdJ7Yn9ns7LaGqinxG3NJe4kuKMTzszayhvhBQLNTQE/uTYr
         ZN6qBczmf7TEZj/XOP3jAa05D/50xvrud9X86jiNVLHOsdmCJnELmnffvasXDOCNQuIb
         gDYdDEdqzfeqL5rMfB6mviF0SPJWdzbHAZwXUlNGvf85LIKigjPVNb08IN1Hz0xNLpta
         kRqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733903350; x=1734508150;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=YfmqqyM7+ybeKmdpaT8e8CdFNymTsVJO6P0YDkmCAXE=;
        b=Y/n0IFvlKnv2fmT5B/QqJjhkd8d08wFhSVco4R0GU/LcT2af/Ro8fd89/bBTl+HsF7
         etbZz0k3EIOBbNDFfoHuQnI+sQGm1MgsnXNP1ePCQT+5xfAJIHON1gxUoOnd0HSW4m9/
         mgzkTrlwbaVslE2sGMVwjgRzaLniTVAqyMzvY8b4WGzAeXW2Aq6yRAag4SJpVUazzXg9
         GkJB8A0chvE/Lvv3/F3+MNBSjiJ093PsEUnkEw283Q4oS+4Up2oeiVeXUFrI1O2jr/lX
         xTpfkI5jG6byRp9fIGTtHlI4jq1t5abSrwtt1QHGcippf+5zVXJTVPgWWZzO3DJma6eA
         TSXA==
X-Forwarded-Encrypted: i=1; AJvYcCXI0stEaTGkMrltG1sGPGPXXyqKvB5F1XRFKgX5pcXonZ8jgCsI9iIy3p67V8gAH2K67WGyqRC/C38=@lists.xenproject.org
X-Gm-Message-State: AOJu0YysgzUrQckvkMTK5WUfMUSTwCjT/8lypYarHPOjyXd43EosSJ66
	Y5vG0PtGTwUmWV7ajGcyORnE+oLuQoXraHU76fht49nU29r4MUSssjpuTturxQ==
X-Gm-Gg: ASbGncsES9ECrR9+Jv8W0jgeww9MShWXR0ZJoKW7+ky6Q4/vr9WkKuujZd8wbPYtwWK
	xgsjEFqmo/yfoLPe5cZa0fF2pNpj91iLpgKeGSIoZyo3aZdWEpvljL7/bkAwFY9/nkfH/mxatZ0
	m3x6vKaKE1JVQ8GlDBh/MtXH3/z2QdDgha0cMoD092+HTkmhEM+a6hr+IPPf/06EULQqKOl1i8o
	MFGcPzVudWucfyqIyEuc7VZBQHB8QU0DloyZDyE6zbcjSsNnHhvQXoTpctq3Y+bzEFpJoOBY+eu
	oMwVGQYtMzhGt3IQrtcIiYTmRfEKez1gWy2wRcs=
X-Google-Smtp-Source: AGHT+IEVDCxU28Pl+GetfoEJREW01k+uw+1DriVfuOiYtS1vhAwfBZm6TTQ1DWH8QQE6MndaMgTvlA==
X-Received: by 2002:a05:6000:184d:b0:385:fc97:9c63 with SMTP id ffacd0b85a97d-3864ce894a8mr1471863f8f.9.1733903350573;
        Tue, 10 Dec 2024 23:49:10 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 08:49:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/3] common: remove -fno-stack-protector from
 EMBEDDED_EXTRA_CFLAGS
To: Volodymyr Babchuk 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Samuel Thibault ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" 
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
 <20241211020424.401614-2-volodymyr_babchuk@epam.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: <20241211020424.401614-2-volodymyr_babchuk@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.12.2024 03:04, Volodymyr Babchuk wrote:
> This patch is preparation for making stack protector
> configurable. First step is to remove -fno-stack-protector flag from
> EMBEDDED_EXTRA_CFLAGS so separate components (Hypervisor in this case)
> can enable/disable this feature by themselves.
> 
> Signed-off-by: Volodymyr Babchuk 

Reviewed-by: Jan Beulich 
with ...

> --- a/stubdom/Makefile
> +++ b/stubdom/Makefile
> @@ -14,6 +14,8 @@ export debug=y
>  # Moved from config/StdGNU.mk
>  CFLAGS += -O1 -fno-omit-frame-pointer
>  
> +CFLAGS += -fno-stack-protector
> +
>  ifeq (,$(findstring clean,$(MAKECMDGOALS)))
>    ifeq ($(wildcard $(MINI_OS)/Config.mk),)
>      $(error Please run 'make mini-os-dir' in top-level directory)
> @@ -54,6 +56,7 @@ TARGET_CFLAGS += $(CFLAGS)
>  TARGET_CPPFLAGS += $(CPPFLAGS)
>  $(call cc-options-add,TARGET_CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
>  
> +
>  # Do not use host headers and libs
>  GCC_INSTALL = $(shell LANG=C gcc -print-search-dirs | sed -n -e 's/install: \(.*\)/\1/p')
>  TARGET_CPPFLAGS += -U __linux__ -U __FreeBSD__ -U __sun__

... this stray (and wrong) hunk dropped. Can likely be done while committing.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 07:57:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 07:57:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854031.1267332 (Exim 4.92)
	(envelope-from )
	id 1tLHbE-0008DW-EV; Wed, 11 Dec 2024 07:57:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854031.1267332; Wed, 11 Dec 2024 07:57: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 1tLHbE-0008DP-Bl; Wed, 11 Dec 2024 07:57:36 +0000
Received: by outflank-mailman (input) for mailman id 854031;
 Wed, 11 Dec 2024 07:57: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 1tLHbD-0008DJ-IZ
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 07:57:35 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20613.outbound.protection.outlook.com
 [2a01:111:f403:2009::613])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 93c34ba3-b795-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 08:57:33 +0100 (CET)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SA1PR12MB5638.namprd12.prod.outlook.com (2603:10b6:806:229::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Wed, 11 Dec
 2024 07:57:29 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%3]) with mapi id 15.20.8230.010; Wed, 11 Dec 2024
 07:57: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: 93c34ba3-b795-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=p0BvR4MdCjvNmqPvsSpBfrwpPpx61dwWUNvwwk0phDpgEYEGx+32Bq7eC/l04fRxCKzJe0wdRJbubh9IQFeKxyc4udeaQBYHO3FUFrTSvpmwUCjt3s5G8P9Knco01em5C6bBoOiQn+D0THeyqPLVu72rHWqOx0GGRv/0Zix/w0VP2hjmzxivD1VTlEwEZpen/2Yh2g5fkfu7RTED5skTUvxzAapaIxVPI8CfWQ2h6ukUPjLFuaU0QKI4YJ6P7B/wkiQywYxLDbMLTQvdUa+02pwu4xOhlnYg31URXIEQTQlVWLvsmD8fG3bqLYfAsoFVwqU6mhfd6tzNk42TQBmPlQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xAH43cGBL4j2MZBBksdqGyVk+alJRkttCFpKKRpYgjI=;
 b=bGv18+DJvnFQBXBxoBm0KLgqhForZbhK0sx/GBPAknLKIFVWF1EJMgphJHuzJLBvJ603P9kKTuhCt22tq3oKIqtk0fP92pF8aGx8WKKk5l3KQB7njupgmQ3Gouf/KiKdCz1TGgK7Y6VP/ZXGjd5K3QPDxTLjnfj4Kq4I39nlv6BXJ70suH9tj3v0jlbW53qRJifTTseui1n/Vi8JNvozsp7CdxNVH2OZ2aWkqGpD6ui5e1sqfOdctqTrTrr1r86UcwBhxg3zdbOFLLCBwUIpC498UGVws1l4n3efzk+8LgDfNCwsg7/LvQbiyGDY6mBiYxRJ/QgEn6Uyp3vi4sEhwg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xAH43cGBL4j2MZBBksdqGyVk+alJRkttCFpKKRpYgjI=;
 b=h9tssph8V+JgrERjL3avXKKGR/LHjtsOK97PHJvvcGGfQCAuUn6kfkjE779mRuHRBxwtFwwWKu4XPQK2XlyGQyDQe/QLs+S7Gx8w8gfMpyuVw8kx7oJEnXY2e0T00E2Xy/HdVog5csg19Wkos/CswQ5hjpDQjoXdwReaWVkeJKg=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Jan Beulich
	
CC: "Chen, Jiqian" , Andrew Cooper
	, Julien Grall , Stefano
 Stabellini , "Huang, Ray" ,
	"xen-devel@lists.xenproject.org" 
Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support
Thread-Topic: [PATCH v2 1/1] vpci: Add resizable bar support
Thread-Index:
 AQHbRIDgGHZ3ofHO0UuqqXvn+EZCabLd/CGAgAGXh4D//4qBgIAAiieA//+hwICAABlHgIAB3TaA
Date: Wed, 11 Dec 2024 07:57:29 +0000
Message-ID:
 
References: <20241202060956.1124162-1-Jiqian.Chen@amd.com>
 <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com>
 
 <1e0576d9-400e-4483-8dd1-061e215a00cd@suse.com>
 
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8230.010)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|SA1PR12MB5638:EE_
x-ms-office365-filtering-correlation-id: be088f42-3038-401b-6694-08dd19b97627
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?a2tJb1A2MloxcnVlWjdQejQ3ZHpmcDNKWUdHMllUNlpxaFp2Z3BFZTFRSVB6?=
 =?utf-8?B?R01LVXdnZVRUNVpFZHl5K3ZIOUFvZElFV3BlNkk0RnczdUlBV0NadTg3aWN0?=
 =?utf-8?B?S2ljZ2VFMDFRQUZMSUppZHZHa0o4RVBFajNYOUdPRFdxeVJxSFJwL0s5RzVj?=
 =?utf-8?B?K2VIc2ZZSjdIYndaRUFqUEplQUFuVEFFaHJwdHNSV0svMUw4Q25vekdHeHdP?=
 =?utf-8?B?RjMxQXY5R0c3Y2lXWUx5aEZKaHFmV2YyTjhCelV3Nk1UZ1dvWklwYmJLbmJL?=
 =?utf-8?B?M1FhM1V1K0pkM0VJWnF5S3dHVFNNKzJxOWsvRVQxQUJsOTQxUTJIamVCL0pm?=
 =?utf-8?B?ZWE2eXMrZkZBL0JxelYvNFpZQ1VabERhNVkvNlBLY0xUOCtkS1RTR2lMSUs3?=
 =?utf-8?B?Y0RiRGovVmRFMXFvTWJKNVRWYUxqaWx6UlhXM1R3cGVjRmxpRm5RT0hlMDlv?=
 =?utf-8?B?MWlJdGlDeWFpOERFQmlkMmVVaHJHSVZCMDlRNExUZVE5OUZFU0IycEx4MXly?=
 =?utf-8?B?c0FwRFNmUFp3QWc1bUpTZWFtVUt5TjMrWEJidU5wYlNvUGU3eitSTjNocE9t?=
 =?utf-8?B?NnF6YzV2NG92NVlGUWljSEQ3VG5hV3FuN3NyeTlwOGI4cGFaZWFBUERQejk5?=
 =?utf-8?B?ZUEvb1UxVjV1c2g1WXNRZ2o2d1RNc0xyVW5xTXFqd21QeUFZaTF5VkszLzRU?=
 =?utf-8?B?V0lRSVMyY1VwaDZPZTdwSGVranhIenNKSmlHVVpNMng5M0RpMDJTRldhTGJt?=
 =?utf-8?B?TEpGTVNHdmFBM0FGR2UzWWt4MDhNbysraGplbE0vZGRBRG0yQmpHcThTMTZx?=
 =?utf-8?B?RzUvbHc1NnROU1lIQzBZQnFmV1BwcTJJTWEyOHREWC9reGE5Tks3bEg2UWhj?=
 =?utf-8?B?bW5wamFKMm5weHNGUkl2cm5TTDFVMTI0N0pFOXhOZ2pOMENzUDUvWEZheThK?=
 =?utf-8?B?RGVoMzZVNkwzTlJHb3FWSDNTQ3E0d21IdFdBbzNIbmZsWTd1VVRYM0tsL3Ew?=
 =?utf-8?B?WmVBa0gyVFBUNzlhSFBQbkNsdVFKdjliUk9KZmdZZENZYU40aGpST2FjQVdo?=
 =?utf-8?B?cWE5WGJrbklsaTRjZGZBVVlHV0Q2aE9ZQmR1WnRaMUI4bTRmUzMvelZoWFhk?=
 =?utf-8?B?amFBbWhpWkRFNEdSTlJSazBCaDNENlFXUHduZVdUTFp6aHRxbUVGN2crMjdN?=
 =?utf-8?B?dFMyVTdJRkZYb0NONEFpZEJMQWVTL3F3UUNmeDlYVHpUNUI5a2JKb2lpZ1Y3?=
 =?utf-8?B?Q2JSd2VCM2lsMHRlOGdlNWVna1ZBRkk2RHN4UW81MURNNXNJMm11K2lVWVRH?=
 =?utf-8?B?a2tGek1VbWpQUE5CUGhIMzZsY3VLK3RmV3IrdnptcmVXNmkzRU9WK3hYSkx3?=
 =?utf-8?B?NDliTXF5WENlQTAwTVpEdm02Skc2bDRrV0pRRlh3WFc4NFViRkI5bjhKdWtY?=
 =?utf-8?B?cVlUblN1ajliTWYyS2t4bFBLejh4dnIwNjZDREJNWDBBcmQ1Y0UzTXpRQjBo?=
 =?utf-8?B?WEtubzlJemlFRmVGemJXVC9UT01IS3FndWhtSXhzQTNWN3djVHR1TTR1b3NV?=
 =?utf-8?B?SVR2TEx0TGNMUXo2b0tTTy9xdnozMVlOYmE2dEJJKzdFM0I3WmhBRUozQWJZ?=
 =?utf-8?B?WnpRVng0ckIxTUFMMDV0ZExndk1WQ0QwMHhWb0lvZFd3cWVpMXJqRzNScUJ5?=
 =?utf-8?B?bzdSb2JuN1pzcHVaQVJGOHRXZW1maXIyaC8vZTNnN2dtV3FIeDVvRWJFUlJz?=
 =?utf-8?B?eDQzQVhCRTZicmJZcUpuaTZOY3VMUEtBb0t1MVlnRWhEMks3SkxUbzZ2WjRn?=
 =?utf-8?B?TG5neXV1bjhwSmtJRTZuQU9VWlluNzBuVXlyREZKdXRiZ0hWYmRYZzBZYlA3?=
 =?utf-8?B?ajIzRmlQRlNkQXJkcG5NeGh3VkorNmlSQ1hkR2Z1Y0ZMSmc9PQ==?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?MXZQVUE0UmRwK0lGMlNjaHhLM2E0Y24vVEMxeGVxWWdDSmNpVUZZTjVoWitn?=
 =?utf-8?B?MzBnTExpQW9XMGszUW5ybTlxVGgyak1PK2h3OWt6UllRVitaOGdLS2JhU2M2?=
 =?utf-8?B?QWRPdHNLR3NUQ01YcUFVbDh1NjJqV1BCcnJNTVZBVVZPYy9weTQrbjFjcHhV?=
 =?utf-8?B?SmpDVmdEUTY2dUhiOGs2dmpveHYwL0ZHbEh0bk02dmlGcmlKT1ZQVkdSYUlH?=
 =?utf-8?B?WkV3SkRNL1N5WXZPbjF2eTE3SXJIVjRIV04yREhvbUR5ei96c2NFYlQ4RGtQ?=
 =?utf-8?B?MmFsbGpVVU9sZUhsSTNRZFJ3SWhkeGovcHFVL1UvdHFHOUpLVHhlYXNlOW5V?=
 =?utf-8?B?aURJRTg2SkZQOU8zbGFXTHVMY1BIRlE4ZUgxK3Nob0hZbUdUV2JFQ29wdytN?=
 =?utf-8?B?TldaRzR5RXVhREc4bGJndXNKZGZDYWRHYkUwYkFsN0JSNjkwd3ovNVhOY1NU?=
 =?utf-8?B?RGc5YzdrMzJWZXJIcGtoNGp2RDhxcHVKdUxLcElCbEJiTU5Sd1NBOFhFM2Mv?=
 =?utf-8?B?T1IwSGYzc3MwRG45N1FYTXV3TDJXUmtjRjlDOXZ0QWpnWndoVUhzZnFvbTUv?=
 =?utf-8?B?WHYxWGUzL2NtZEptNmM5bWd6NUlyRTRkUjk5Z2MwanNpL0lRSjhhU3F2Skpw?=
 =?utf-8?B?eWVQemtabzZSMUZsZVZUOWdRcTdzNUlqcmllVHh2bjVFWHhaL2VDbGtXM2Jh?=
 =?utf-8?B?RU1EYTl6SXo4MWh2RHVHQVJaU0o0Nk5pNmIvcWg1c1J3Y1BId1J4OUxwcWV2?=
 =?utf-8?B?WTFHUzdvSFY5aUJIaFllWjVGZjlkSmhiMXBoNTIxWmZSWnlXWG84UjNGUUQ5?=
 =?utf-8?B?RGdzTlJhZDZ6UC96anl0Vlltc1FseXZrS2E0VE9zbUM4T3J2ZTNveGh2dzhi?=
 =?utf-8?B?M0dpK1dEYkxBR3JIczh1U09nekhkZnpSRUxPc1BDMCtHUFVPKzVySldCU0pP?=
 =?utf-8?B?QWJhNkxxWmRqTkFuRU8yWjdhNG1uUUIwYVdHbjBhMHhCVTRmUjNpY1VkZGk5?=
 =?utf-8?B?cGI0cXJJaVpHMksvNmNEZk4vcmhjc3NWQnY0eSt6eDcvL1RQek90emx5NU5x?=
 =?utf-8?B?K1pUaUw3aS9sYk0wSnRKV2xLeERyejJjb09iTlYyemhVTXA2TTlyNUVxbFZS?=
 =?utf-8?B?ZnhPb015dXFJa1NUWnE0NjlWeWZYN01JYmpkTVhDNjdpd3hlWGhUYndKMkpY?=
 =?utf-8?B?aWpzQ0ZjYjFhWDNKMHhWMHd5ajZXQk10cXFuQUV5RWRxUEM1Q3dPbzJiL3dj?=
 =?utf-8?B?S2ljT3lGbm9uWG5NR3F2WnJWaWY3eUZUUWVLVGEzTTZ0akhHd2gzODZKN1Fs?=
 =?utf-8?B?TlBHaEp4emhWVlBZZWQwbXNBN3grYko4c2dtSzEyVjZvNzkxR0dKdE1DeUhy?=
 =?utf-8?B?KzlrNWRiLzB2UEV2ODRudmRLNDRvMmYydTJYOFlidzhjaEM4Vm44dHhJWG1a?=
 =?utf-8?B?ZHkzZTZSNkVra1ZCR2MwNURaVytYb3RzNzVNR2JnKy9MNzc5RXBWeFZHL2Fv?=
 =?utf-8?B?NFdOTksrSk1lc3V1RXljZndOTFdjY1VNNmI0K3hNUHRrVlpzaEo2NExtQkZD?=
 =?utf-8?B?L3pCTlRrVHdncWFNWFJLSlV5ZXVJQWpZa1cyUDkrOUdtQ0NTY1R2dnpLY0Z5?=
 =?utf-8?B?MjNoY08rSWpsSjV3alNud05ZUDI4cFdtbFVwcWpQYVh0bkJYZmxoNE00TWpW?=
 =?utf-8?B?OFprN0E0enltNEkrcVkrbEZQQTE3STNkMnpSRlJJQStCMlRTdExURUh1Mi9I?=
 =?utf-8?B?MTNMREpEdWsrQ0Y4NGxweWtGQ21MdU8wbkYyRGRMdDlrdUs4cnJ4MmIzVWp3?=
 =?utf-8?B?cnBDQm95R2thcWpUd0RNM09OUTErRXFMYWc3Z2tPQjQxREE0TXplSW9iOGtj?=
 =?utf-8?B?K3dFRndnN3poS2xGY2puZ2QyQ2xPdmR0VUVNN1hhdW9HMzFhSWFuNlV1S2c0?=
 =?utf-8?B?SDhjSGNWdzR6N25MSkplc2NCdU8yaG14THYzVmhHeDhlMmVSczY3NEVoa01C?=
 =?utf-8?B?YmhuamVFclMycWdlTXhkNHhqUFNVd1RWdXpCeXVFWWpZK3JKMjdmQXRlTFFz?=
 =?utf-8?B?TW9Ga3RlUFg0QTZpN0Z5TUkzT1RPbDBpa0QyZkxmRWFtN21VQWJFUDU2Kzll?=
 =?utf-8?Q?xTXY=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: be088f42-3038-401b-6694-08dd19b97627
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2024 07:57:29.7837
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Tu2HLeTVCTGoTs6BYcTbHOt/Ut4y6eSrYwr0WkrUHNi9pbSAztUyA3KoT52IuOen35zfD15nFnzyojzVIxZHLw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB5638

T24gMjAyNC8xMi8xMCAxOToyNSwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToNCj4gT24gVHVlLCBE
ZWMgMTAsIDIwMjQgYXQgMTA6NTQ6NDNBTSArMDEwMCwgSmFuIEJldWxpY2ggd3JvdGU6DQo+PiBP
biAxMC4xMi4yMDI0IDA4OjU3LCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+Pj4gT24gMjAyNC8xMi8x
MCAxNToxNywgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+IE9uIDEwLjEyLjIwMjQgMDg6MDcsIENo
ZW4sIEppcWlhbiB3cm90ZToNCj4+Pj4+IE9uIDIwMjQvMTIvOSAyMTo1OSwgSmFuIEJldWxpY2gg
d3JvdGU6DQo+Pj4+Pj4gT24gMDIuMTIuMjAyNCAwNzowOSwgSmlxaWFuIENoZW4gd3JvdGU6DQo+
Pj4+Pj4+ICsgICAgICAgIGlmICggcmMgKQ0KPj4+Pj4+PiArICAgICAgICB7DQo+Pj4+Pj4+ICsg
ICAgICAgICAgICBwcmludGsoIiVwcDogYWRkIHJlZ2lzdGVyIGZvciBQQ0lfUkVCQVJfQ0FQIGZh
aWxlZCAocmM9JWQpXG4iLA0KPj4+Pj4+PiArICAgICAgICAgICAgICAgICAgICZwZGV2LT5zYmRm
LCByYyk7DQo+Pj4+Pj4+ICsgICAgICAgICAgICBicmVhazsNCj4+Pj4+Pj4gKyAgICAgICAgfQ0K
Pj4+Pj4+PiArDQo+Pj4+Pj4+ICsgICAgICAgIHJjID0gdnBjaV9hZGRfcmVnaXN0ZXIocGRldi0+
dnBjaSwgdnBjaV9od19yZWFkMzIsIHJlYmFyX2N0cmxfd3JpdGUsDQo+Pj4+Pj4+ICsgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgcmViYXJfb2Zmc2V0ICsgUENJX1JFQkFSX0NUUkwsIDQs
DQo+Pj4+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGRldi0+dnBjaS0+aGVh
ZGVyLmJhcnMpOw0KPj4+Pj4+PiArICAgICAgICBpZiAoIHJjICkNCj4+Pj4+Pj4gKyAgICAgICAg
ew0KPj4+Pj4+PiArICAgICAgICAgICAgcHJpbnRrKCIlcHA6IGFkZCByZWdpc3RlciBmb3IgUENJ
X1JFQkFSX0NUUkwgZmFpbGVkICVkXG4iLA0KPj4+Pj4+PiArICAgICAgICAgICAgICAgICAgICZw
ZGV2LT5zYmRmLCByYyk7DQo+Pj4+Pj4+ICsgICAgICAgICAgICBicmVhazsNCj4+Pj4+Pg0KPj4+
Pj4+IElzIGl0IGNvcnJlY3QgdG8ga2VlcCB0aGUgb3RoZXIgaGFuZGxlciBpbnN0YWxsZWQ/IEFm
dGVyIGFsbCAuLi4NCj4+Pj4+IFdpbGwgY2hhbmdlIHRvICJyZXR1cm4gcmM7IiBoZXJlIGFuZCBh
Ym92ZSBpbiBuZXh0IHZlcnNpb24uDQo+Pj4+DQo+Pj4+IEknbSBub3QgY29udmluY2VkIHRoaXMg
aXMgd2hhdCB3ZSB3YW50LCBhcyBwZXIgLi4uDQo+Pj4+DQo+Pj4+Pj4+ICsgICAgICAgIH0NCj4+
Pj4+Pj4gKyAgICB9DQo+Pj4+Pj4+ICsNCj4+Pj4+Pj4gKyAgICByZXR1cm4gMDsNCj4+Pj4+Pg0K
Pj4+Pj4+IC4uLiB5b3UgLSBpbW8gc2Vuc2libHkgLSBhcmVuJ3QgY29tbXVuaWNhdGluZyB0aGUg
ZXJyb3IgYmFjayB1cCAodG8gYWxsb3cNCj4+Pj4+PiB0aGUgZGV2aWNlIHRvIGJlIHVzZWQgd2l0
aG91dCBCQVIgcmVzaXppbmcuDQo+Pj4+DQo+Pj4+IC4uLiB3aGF0IEkgc2FpZCBoZXJlLg0KPj4+
IFNvcnJ5LCBJIGRpZG7igJl0IHVuZGVyc3RhbmQuDQo+Pj4gRG8geW91IG1lYW4gaXQgaXMgbm90
IGVub3VnaCB0byByZXR1cm4gZXJyb3IgY29kZSBvbmNlIGEgaGFuZGxlciBmYWlsZWQgdG8gYmUg
aW5zdGFsbGVkLCBJIG5lZWQgdG8gcmVtb3ZlIHRoZSBhbHJlYWR5IGluc3RhbGxlZCBoYW5kbGVy
cz8NCj4+DQo+PiBObywgaWYgeW91IHJldHVybiBhbiBlcnJvciBoZXJlLCBub3RoaW5nIGVsc2Ug
bmVlZHMgZG9pbmcuIEhvd2V2ZXIsIEkNCj4+IHF1ZXN0aW9uIHRoYXQgcmV0dXJuaW5nIGFuIGVy
cm9yIGhlcmUgaXMgZ29vZCBvciBldmVuIG5lY2Vzc2FyeS4gSW4NCj4+IHRoZSBldmVudCBvZiBh
biBlcnJvciwgdGhlIGRldmljZSBvdWdodCB0byBzdGlsbCBiZSB1c2FibGUsIGp1c3QNCj4+IHdp
dGhvdXQgdGhlIEJBUi1yZXNpemluZyBjYXBhYmlsaXR5Lg0KPiANCj4gU28geW91IHN1Z2dlc3Qg
dGhhdCB0aGUgY2FwYWJpbGl0eSBzaG91bGQgYmUgaGlkZGVuIGluIHRoYXQgY2FzZT8gIFdlDQo+
IGhhdmUgbG9naWMgdG8gaGlkZSBjYXBhYmlsaXRpZXMsIGp1c3Qgbm90IHVzZWQgZm9yIHRoZSBo
YXJkd2FyZQ0KPiBkb21haW4uICBJdCB3b3VsZCBuZWVkIHNvbWUgZXh0cmEgd2lyaW5nIHRvIGJl
IGNhcGFibGUgb2YgaGlkaW5nDQo+IGZhaWxlZCBjYXBhYmlsaXRpZXMuDQpDYW4geW91IGdpdmUg
bWUgYSBndWlkYW5jZSBvbiBob3cgdG8gaGlkZSBhIGZhaWxlZCBjYXBhYmlsaXR5Pw0KV2hhdCBj
b2RlcyBhcmUgY3VycmVudCBsb2dpYyB0byBoaWRlIGNhcGFiaWxpdGllcz8NClRoZW4gbWF5YmUg
SSBjYW4gYWRkIGEgcGF0Y2ggdG8gaW1wbGVtZW50IGl0Lg0KDQo+IA0KPiBSZWdhcmRzLCBSb2dl
ci4NCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpKaXFpYW4gQ2hlbi4NCg==


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 08:16:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 08:16:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854046.1267343 (Exim 4.92)
	(envelope-from )
	id 1tLHtE-0005Dq-1s; Wed, 11 Dec 2024 08:16:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854046.1267343; Wed, 11 Dec 2024 08:16: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 1tLHtD-0005Dj-VN; Wed, 11 Dec 2024 08:16:11 +0000
Received: by outflank-mailman (input) for mailman id 854046;
 Wed, 11 Dec 2024 08:16: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 1tLHtC-0005Dd-Mg
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 08:16:10 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2c60fdb3-b798-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 09:16:08 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5d3f57582a2so785879a12.1
 for ; Wed, 11 Dec 2024 00:16:08 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa678f34c68sm513174566b.38.2024.12.11.00.16.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 00:16:05 -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: 2c60fdb3-b798-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733904967; x=1734509767; 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=Tq3dxAWXy5XJWm3IGlsikCO2oYUrgklOmjblU5npweg=;
        b=TbfhdnpoqvcvQ4UT/xYHrgvgsDlTpGo1swCt4fvb5Md5PseoM/UDliOQq6Ng879smu
         1kpp/lCmekbMSP7Y/ZI9inRMO7XKSY5shyVe2UOvchTMr1NJiEFzJIx9gcJ8BDUTHctr
         +EgKlTqxCTSJT4afP0gbFMDWDBXVorj6cVv3A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733904967; x=1734509767;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Tq3dxAWXy5XJWm3IGlsikCO2oYUrgklOmjblU5npweg=;
        b=t7YxSL+IgBXKQ5wGJcyEoWUYkLOP1tqGnfnWk2yonIIRTlVroZadTkS2NZg4pil3aj
         tO0pENe2YjJNif4pQ0tz4Rl350eqj1uzNebU5iy6a6UocNkVoyM6DNMZj8cJxNUj5lHU
         ok5oQUjyc1Vyo2qW9PXirySZeNTp+1xGRuRpMlP4M/fZlKkr99D6hrxc/S7ekQc8+764
         nxGZM/E1zcEk7zxEJWBVrD1zB1Fr7qO75rpLBOphvqdoaEoGwOYGGwXdWWsNdkA4Wxmg
         Gbk+WGuvdpjAs3XvRItq5+dB2tOKCqxQEGRDV0S3c+E3ry+Uce+nG0RMVvKdPnaatVxc
         pH4Q==
X-Forwarded-Encrypted: i=1; AJvYcCUxvn+yun9RXBt7o9PhzHW6pGQ40SpBEQRNmzvDi75juPch15xQO8ASlnXUP76GY906jM8lF7QGXbM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy8JqLlOfItQFoV2NKySP7IO1uawTa7rIeYXIJlg/4zTZB+0p9Q
	vxVxC87E6pNa3lrRqap/Pu7RVQppBBLdn2QTeRVMj9DzXACEYhTw6dn6vqrd0Ew=
X-Gm-Gg: ASbGnctYwGcICIRbxNzRftKwYtPPYdGPxDk6L5zsVUhvDiaMJ97sQAJ9GeFucuN6MI3
	7Z4tG36N/0Q8AZBF7Mlpl/fPgH0nkw2UOFfQiOx47XnP4cCZg0plOCJmzyxX28rgz3Ad5df1pRA
	O+fsZtdjIdAuz99aAabr9um8hBinBo/90d+g5v86wW4hyV5L7TuasYDQSeGKK/UFm/7Tm7jqsHH
	38819fOX4+OHboJU9K5c0KadeV8jOj36kZK63/T9WWTrbwvj/m21aAag2Ve21Y=
X-Google-Smtp-Source: AGHT+IFrdx5HjkKQlEgwR0HsqKg8XmEK5Ssr9r9FiZ/JK+6HRbVX7201jJyze882Or/9nWIcZ/FAjQ==
X-Received: by 2002:a17:907:7251:b0:aa6:743e:d621 with SMTP id a640c23a62f3a-aa6b16fcbc7mr160640566b.30.1733904965967;
        Wed, 11 Dec 2024 00:16:05 -0800 (PST)
Date: Wed, 11 Dec 2024 09:16:04 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: Jan Beulich ,
	Andrew Cooper ,
	Julien Grall ,
	Stefano Stabellini ,
	"Huang, Ray" ,
	"xen-devel@lists.xenproject.org" 
Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support
Message-ID: 
References: <20241202060956.1124162-1-Jiqian.Chen@amd.com>
 <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com>
 
 <1e0576d9-400e-4483-8dd1-061e215a00cd@suse.com>
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, Dec 11, 2024 at 06:37:30AM +0000, Chen, Jiqian wrote:
> On 2024/12/10 19:25, Roger Pau Monné wrote:
> > On Tue, Dec 10, 2024 at 10:54:43AM +0100, Jan Beulich wrote:
> >> On 10.12.2024 08:57, Chen, Jiqian wrote:
> >>> On 2024/12/10 15:17, Jan Beulich wrote:
> >>>> On 10.12.2024 08:07, Chen, Jiqian wrote:
> >>>>> On 2024/12/9 21:59, Jan Beulich wrote:
> >>>>>> On 02.12.2024 07:09, Jiqian Chen wrote:
> >>>>>>> +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
> >>>>>>> +                                      unsigned int reg,
> >>>>>>> +                                      uint32_t val,
> >>>>>>> +                                      void *data)
> >>>>>>> +{
> >>>>>>> +    uint64_t size;
> >>>>>>> +    unsigned int index;
> >>>>>>> +    struct vpci_bar *bars = data;
> >>>>>>> +
> >>>>>>> +    if ( pci_conf_read16(pdev->sbdf, PCI_COMMAND) & PCI_COMMAND_MEMORY )
> >>>>>>> +        return;
> >>>>>>
> >>>>>> I don't think something like this can go uncommented. I don't think the
> >>>>>> spec mandates to drop writes in this situation?
> >>>>> Spec says: Software must clear the Memory Space Enable bit in the Command register before writing the BAR Size field.
> >>>>> This check is suggested by Roger and it really helps to prevent erroneous writes in this case,
> >>>>> such as the result of debugging with Roger in the previous version.
> >>>>> I will add the spec's sentences as comments here in next version.
> >>>>
> >>>> What you quote from the spec may not be enough as a comment here. There's
> >>>> no direct implication that the write would simply be dropped on the floor
> >>>> if the bit is still set. So I think you want to go a little beyond just
> >>>> quoting from the spec.
> >>> How about quoting Roger's previous words: " The memory decoding must be disabled before writing the BAR size field.
> >>> Otherwise changing the BAR size will lead to the active p2m mappings getting out of sync w.r.t. the new BAR size." ?
> >>
> >> That'll be better, but imo still not enough to explain the outright ignoring
> >> of the write.
> > 
> > I think we might want to do something along the lines of:
> > 
> > uint64_t size = PCI_REBAR_CTRL_SIZE(val);
> > struct vpci_bar *bar = data;
> > 
> > if ( bar->enabled )
> > {
> >     if ( size == bar->size )
> >         return;
> > 
> >     /*
> >      * Refuse to resize a BAR while memory decoding is enabled, as
> >      * otherwise the size of the mapped region in the p2m would become
> >      * stale with the newly set BAR size, and the position of the BAR
> >      * would be reset to undefined.  Note the PCIe specification also
> >      * forbids resizing a BAR with memory decoding enabled.
> >      */
> >     gprintk(XENLOG_ERR,
> >             "%pp: refuse to resize BAR with memory decoding enabled\n",
> > 	    &pci->sbdf);
> >     return;
> > }
> Thank you very much!
> 
> > 
> > Note this requires that the data parameter points to the BAR that
> > matches the ReBAR control register, this needs adjusting in
> > init_rebar().
> I think I can keep current implementation of init_rebar() and use bars[index] to get the corresponding BAR.

IMO it would be best if you can pass the corresponding bar struct into
the handler directly, as that will avoid having to do a PCI read just
to get the BAR index from PCI_REBAR_CTRL.  It should also avoid the
need for the index and BAR type checks in rebar_ctrl_write().

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 08:16:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 08:16:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854060.1267353 (Exim 4.92)
	(envelope-from )
	id 1tLHtw-0005kU-Dc; Wed, 11 Dec 2024 08:16:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854060.1267353; Wed, 11 Dec 2024 08:16: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 1tLHtw-0005kN-9g; Wed, 11 Dec 2024 08:16:56 +0000
Received: by outflank-mailman (input) for mailman id 854060;
 Wed, 11 Dec 2024 08:16: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 1tLHtu-0005Ut-V5
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 08:16:54 +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 47dc4dbb-b798-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 09:16:54 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-38632b8ae71so3040037f8f.0
 for ; Wed, 11 Dec 2024 00:16: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
 d2e1a72fcca58-728eb09fbbcsm1289485b3a.44.2024.12.11.00.16.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 00:16: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: 47dc4dbb-b798-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733905013; x=1734509813; 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=xt/vhDq6tvtRtAp65Oap9JwGCMVSXroswoLz9opvCjU=;
        b=ex1i9Htj9a0Xqixx/70MYouJFWt9w7Lll/uVR2fcrT3ouMIM2cNwOVmADPwXH59dJX
         AaSODCEVHPtoEWXLIAzLWKMzJzUhZ61QlghG+VdfjUl1KUiHFBotrvQjhH17ZOI6u3al
         g435p+6cC3+caJj2yZ0DlGRG8mziOyfzEugUzQz6ntMoov9+Yv+yPGddpeH7pL8ST5nE
         piL5X9e36l153LYRuWggwQpVWDZSS5eb0Zhq2fS3jlKrJ3J460FKZ1VrTdy2LW+9dNSe
         m1FuJVYBuHt1I26z3Idyr11gFY/qh4EjowCxOFNgjZ+9pK4qOfOm1SRduiD+ChjLonu7
         jbCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733905013; x=1734509813;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=xt/vhDq6tvtRtAp65Oap9JwGCMVSXroswoLz9opvCjU=;
        b=vn3JN4ipVIEY0e9LnpZE6KCMJecHrbZihqkbVZw11Wq076cdh+ReZMTyB9foUn5+iu
         gqXCC1rF0T7yNTYTEfpLDpG7YseBksHTjfeJsLq+7mxE9HoQRoDHc9qvQcNMAjXEFkiY
         bA+lAUdGqa9iIVZwBbQlo8HYhBegLoaoGKebNvdi86YRghIahrAq+GoGtJSsPq26z5qf
         FckDAeKtmyfG/qSY2Kr2PODpgmVm1ovw5VEUNbyrP8HmM8Vy9YbdYkyO3A21Lakg9BXh
         ibQ9rksxNSfdw6U8xOZnE+Bt3SPhHYnBHaU+u7F1Loixm2+Z5bUs9ARRR7Mts4sjvGHE
         BQGQ==
X-Forwarded-Encrypted: i=1; AJvYcCVlqO8SL4ARRKVbQFWnP7u4fjh8dha4NMKb4UtEEZdwPgI5Apqn70LQxuUD4SqHpHLuO5UvAKZdnmA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz9IxfV1WglqHcr/TE82GVtOPD3D/4R3LBVvu/EQzYziAtZRS3c
	sk4hjIet6roa/lYpnfkLkyvlyqu7pFdTeVoWLxXB5eKmqN4zRbebe9ZxwTzfag==
X-Gm-Gg: ASbGnctDr8I52oMtmMHg2L+g+nS8uHaB8KaL/0KWMgWhyVnQMljbgBgZ3B8tTXIuy1P
	jqb+tqnGe1X5AfzHcmlao/AidFiZCEvBFpqKurKdw1rg/PKknXaT+2JyOUk2oIp5KNJQ+Behfrc
	z/xcn0ZOpJIJ8mtnAnFXBPOqDrSUpJBZCSsxhjY3uMRE4yRsqUMI1VVEpsgaa1FX8mqu3X12+S0
	YpfqSXeBshPTyNXORLuFZpn7SZfyzgKanyFwReDfo77aHcoo509ZK4wP96y0WoDA039ZZJwv1HY
	omGnzpH4cwWI6TZxd2tXBy/7auoKZkBbJWhomtI=
X-Google-Smtp-Source: AGHT+IGg7YdYyWOgyoU4IzGC41llIXBd4pWw8wCA3r7WqaRRxAR7HcSpRm32WreOv64slQQR5FfXSQ==
X-Received: by 2002:a5d:6d03:0:b0:385:f9ed:1632 with SMTP id ffacd0b85a97d-3864ce9d5b4mr1415511f8f.28.1733905013586;
        Wed, 11 Dec 2024 00:16:53 -0800 (PST)
Message-ID: <0d04abb1-dae1-47d1-93e3-23d88399fa64@suse.com>
Date: Wed, 11 Dec 2024 09:16:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/3] xen: common: add ability to enable stack protector
To: Volodymyr Babchuk 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
 <20241211020424.401614-3-volodymyr_babchuk@epam.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: <20241211020424.401614-3-volodymyr_babchuk@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 11.12.2024 03:04, Volodymyr Babchuk wrote:
> Both GCC and Clang support -fstack-protector feature, which add stack
> canaries to functions where stack corruption is possible. This patch
> makes general preparations to enable this feature on different
> supported architectures:
> 
>  - Added CONFIG_HAS_STACK_PROTECTOR option so each architecture
>    can enable this feature individually
>  - Added user-selectable CONFIG_STACK_PROTECTOR option
>  - Implemented code that sets up random stack canary and a basic
>    handler for stack protector failures
> 
> Stack guard value is initialized in three phases:
> 
> 1. Pre-defined randomly-selected value.
> 
> 2. Early use of linear congruent random number generator. It relies on
> get_cycles() being available very early. If get_cycles() returns zero,
> it would leave pre-defined value from the previous step. Even when
> get_cycles() is available, it's return value may be easily predicted,
> especially on embedded systems, where boot time is quite consistent.
> 
> 3. After hypervisor is sufficiently initialized, stack guard can be
> set-up with get_random() function, which is expected to provide better
> randomness.
> 
> Also this patch adds comment to asm-generic/random.h about stack
> protector dependency on it.
> 
> Signed-off-by: Volodymyr Babchuk 
> 
> ---
> 
> Changes in v3:
>  - Fixed coding style in stack-protector.h
>  - Extended panic() message
>  - Included missed random.h
>  - Renamed Kconfig option
>  - Used Andrew's suggestion for the Kconfig help text
>  - Added "asmlinkage" attribute to __stack_chk_fail() to make Eclair
>  happy
>  - Initial stack guard value is random
>  - Added LCG to generate stack guard value at early boot stages
>  - Added comment to asm-generic/random.h about dependencies
>  - Extended the commit message
> 
> Changes in v2:
>  - Moved changes to EMBEDDED_EXTRA_CFLAGS into separate patch
>  - Renamed stack_protector.c to stack-protector.c
>  - Renamed stack_protector.h to stack-protector.h
>  - Removed #ifdef CONFIG_X86 in stack-protector.h
>  - Updated comment in stack-protector.h
>    (also, we can't call boot_stack_chk_guard_setup() from asm code in
>    general case, because it calls get_random() and get_random() may
>    depend in per_cpu infrastructure, which is initialized later)
>  - Fixed coding style
>  - Moved CONFIG_STACK_PROTECTOR into newly added "Compiler options"
>  submenu
>  - Marked __stack_chk_guard as __ro_after_init
> ---
>  xen/Makefile                      |  4 +++
>  xen/common/Kconfig                | 15 ++++++++++
>  xen/common/Makefile               |  1 +
>  xen/common/stack-protector.c      | 47 +++++++++++++++++++++++++++++++
>  xen/include/asm-generic/random.h  |  5 ++++
>  xen/include/xen/stack-protector.h | 30 ++++++++++++++++++++
>  6 files changed, 102 insertions(+)
>  create mode 100644 xen/common/stack-protector.c
>  create mode 100644 xen/include/xen/stack-protector.h
> 
> diff --git a/xen/Makefile b/xen/Makefile
> index 34ed8c0fc7..0de0101fd0 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -432,7 +432,11 @@ else
>  CFLAGS_UBSAN :=
>  endif
>  
> +ifeq ($(CONFIG_STACK_PROTECTOR),y)
> +CFLAGS += -fstack-protector
> +else
>  CFLAGS += -fno-stack-protector
> +endif

Personally I'd prefer if we consistently used the list approach we use
in various places, whenever possible:

CFLAGS-stack-protector-y := -fno-stack-protector
CFLAGS-stack-protector-$(CONFIG_STACK_PROTECTOR) := -fstack-protector
CFLAGS += $(CFLAGS-stack-protector-y)

> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -86,6 +86,9 @@ config HAS_UBSAN
>  config HAS_VMAP
>  	bool
>  
> +config HAS_STACK_PROTECTOR
> +	bool

Please obey to alphabetic sorting in this region of the file.

> @@ -213,6 +216,18 @@ config SPECULATIVE_HARDEN_LOCK
>  
>  endmenu
>  
> +menu "Compiler options"
> +
> +config STACK_PROTECTOR
> +	bool "Stack protector"
> +	depends on HAS_STACK_PROTECTOR
> +	help
> +	  Enable the Stack Protector compiler hardening option. This inserts a
> +	  canary value in the stack frame of functions, and performs an integrity
> +	  check on exit.
> +
> +endmenu

"Compiler options" reads a little odd to me as a menu title. The preceding one
is "Speculative hardening"; how about making this one "Other hardening" or some
such?

> --- /dev/null
> +++ b/xen/common/stack-protector.c
> @@ -0,0 +1,47 @@
> +// SPDX-License-Identifier: GPL-2.0-only

Nit: I don't think we permit C++ comments as per our style.

> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Initial value is chosen by a fair dice roll.
> + * It will be updated during boot process.
> + */
> +#if BITS_PER_LONG == 32
> +unsigned long __ro_after_init __stack_chk_guard = 0xdd2cc927UL;
> +#else
> +unsigned long __ro_after_init __stack_chk_guard = 0x2d853605a4d9a09cUL;
> +#endif
> +
> +/* This function should be called from ASM only */

And with no (stack-protector enabled) C functions up the call stack. This
may be as easy to express in the comment as by simply adding "early".
However, considering the so far hypothetical case of offering the feature
also on x86: What about xen.efi, which from the very start uses C code?

> +void __init asmlinkage boot_stack_chk_guard_setup_early(void)
> +{
> +    /*
> +     * Linear congruent generator (X_n+1 = X_n * a + c).
> +     *
> +     * Constant is taken from "Tables Of Linear Congruential
> +     * Generators Of Different Sizes And Good Lattice Structure" by
> +     * Pierre L’Ecuyer.
> +     */
> +#if BITS_PER_LONG == 32
> +    const unsigned long a = 2891336453UL;
> +#else
> +    const unsigned long a = 2862933555777941757UL;
> +#endif
> +    const unsigned long c = 1;
> +
> +    unsigned long cycles = get_cycles();
> +
> +    /* Use the initial value if we can't generate random one */
> +    if ( !cycles )
> +	    return;

Nit: Indentation (no hard tabs please).

> +    __stack_chk_guard = cycles * a + c;
> +}
> +
> +void asmlinkage __stack_chk_fail(void)
> +{
> +    panic("Stack Protector integrity violation identified in %ps\n",
> +	  __builtin_return_address(0));

Again.

Is panic() really the right construct to use here, though?
__builtin_return_address() will merely identify the immediate caller. A
full stack trace (from BUG()) would likely be more useful in identifying
the offender.

> --- a/xen/include/asm-generic/random.h
> +++ b/xen/include/asm-generic/random.h
> @@ -2,6 +2,11 @@
>  #ifndef __ASM_GENERIC_RANDOM_H__
>  #define __ASM_GENERIC_RANDOM_H__
>  
> +/*
> + * When implementing arch_get_random(), please make sure that
> + * it can provide random data before stack protector is initialized
> + * (i.e. before boot_stack_chk_guard_setup() is called).
> + */
>  static inline unsigned int arch_get_random(void)
>  {
>      return 0;

What exactly will go (entirely) wrong if the comment isn't followed?
(I'm afraid anyway that the comment living here is easy to miss.)

> --- /dev/null
> +++ b/xen/include/xen/stack-protector.h
> @@ -0,0 +1,30 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef XEN__STACK_PROTECTOR_H
> +#define XEN__STACK_PROTECTOR_H
> +
> +#ifdef CONFIG_STACK_PROTECTOR
> +
> +#include 
> +
> +extern unsigned long __stack_chk_guard;
> +
> +/*
> + * This function should be always inlined. Also it should be called
> + * from a function that never returns or a function that has
> + * stack-protector disabled.
> + */

As to the latter - that's not just "a function" but an entire call
stack that would need to have stack protector disabled.

> +static always_inline void boot_stack_chk_guard_setup(void)
> +{
> +    __stack_chk_guard = get_random();
> +    if (BITS_PER_LONG == 64)

Nit: Style (missing blanks).

> +        __stack_chk_guard |= ((unsigned long)get_random()) << 32;

Nit: No real need for the outer pair of parentheses.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 08:25:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 08:25:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854074.1267363 (Exim 4.92)
	(envelope-from )
	id 1tLI2D-0008SV-5d; Wed, 11 Dec 2024 08:25:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854074.1267363; Wed, 11 Dec 2024 08: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 1tLI2D-0008SO-2i; Wed, 11 Dec 2024 08:25:29 +0000
Received: by outflank-mailman (input) for mailman id 854074;
 Wed, 11 Dec 2024 08:25: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 1tLI2C-0008SI-3K
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 08:25:28 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7830c9ad-b799-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 09:25:24 +0100 (CET)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3862f32a33eso2132199f8f.3
 for ; Wed, 11 Dec 2024 00:25: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
 d2e1a72fcca58-725eed5233esm4814734b3a.4.2024.12.11.00.25.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 00:25: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: 7830c9ad-b799-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733905524; x=1734510324; 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=armvY1GmuT03/EcYCs/Jw28Tj6XbxfWCtucb8n9l/rU=;
        b=RVvPZ/R0BbRulXjt9CV5a3xtCd1IgpB67srM0kAnPlMaTi7j7TE/EylKLHu3vDkscn
         NUcmTbjF5laWxmGIghPaNOcJpjGziT5/1c2jr93+qPtnh63uDALzzeguYa3RcwntYYge
         oDR5VmaKAkVtRJEOGvjSg87xyyg9P/a9iawcmYLMFRfWcipKWWb3qpqeGrXo/TQmwyfi
         7V0FkskNaq4TwLaIUt/N024LJY2bqOebS7KAd/zSxighgu6zoN03zG9MibDdeHHPjUSX
         0dd+tNbwfG9E/YUA6QX9ZV7l/jt2JtApUbXY5d7SNrzn5eXlEzld/GGC8yDEKG+638BZ
         X8ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733905524; x=1734510324;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=armvY1GmuT03/EcYCs/Jw28Tj6XbxfWCtucb8n9l/rU=;
        b=musp0q66w1scwkndkDAljkJpR5VZRdkJVyd5rffY853yVZ2YNrdrVAIg91HYtf1J6Y
         +zbowtVQBb/VT6hCcvKWpf1qVOKqUBRaW9HGPpJsIxeEcR45DJdcuWrLQ2ne9yPKWCYG
         gbkIHXdad5+H5M/CmPrQItYcPW2xHeJx+HX9lirz2sTfLGRXW8qkE82Lv7UahjwG0NXr
         qEXZEeVwMNi1VM3/3+Lq66gVbgM9+4PFFARrJEEs3ZQ9lZ2Lid/Tm4Me86lAPVLxwBh0
         sTdDMaACcRcvu2s9YONFUvAOmMkoPzAfw7CyJ0Wsv+YjkiSyrBsiummAlg0v55j8L8iI
         S3mQ==
X-Forwarded-Encrypted: i=1; AJvYcCU/5TUC3Oh1H1y/zGvycxZMOLfUe7dcxL+ApPA7le/+IJvybMwhVjT/eYsz4o6AFIg6J5Cb1sTAPmk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwjqtZluhVUV6J0yNQCGQcfpBz7abdWYGS7kjna80wJsQio78rs
	LzhPS//swwHxV8/gcaD3t/mHgLDInZqT77Z7FHq87aM2mrCqdhftK923ezqd3w==
X-Gm-Gg: ASbGncsy6PeMj4Hi/IIZA3GvavzRcZDlSZ/hMYn0eogEtVKCCC2xIeYFtLr3/ZuNNUo
	eMNmp90jOXdmJvToyHy/CBdQ4E/jDgDxJSf1s66cb1AnqyieE01skYpy2ymGxlMpZpzTMrVGuBR
	toYcd/4YJULdp1FRn8NBpl0MMRfRhgqRDMt9X8Sd1M4vhStYqpI1dd5GX+4dqrN0ziWOhE4rqjc
	gJs3IQZaxwMjlZQjPyqxPn5HB8c0nvQNLFy3BrwgjYWp4StTenPD0ciPup4fkoYM86Z46mRYwgZ
	+FoT+WO5+VFopSy8Ac9We3MRghB6nR7xvzBmEAc=
X-Google-Smtp-Source: AGHT+IG3rmi4UCsJMboa/LGF1Mgeehvedn9Jp0g4R8lWp9f5oc1VslPX0YrzC9W6/ODC3uisJzoJHA==
X-Received: by 2002:a05:6000:154a:b0:385:ef2f:92ad with SMTP id ffacd0b85a97d-3864ce86a7fmr1585356f8f.10.1733905524188;
        Wed, 11 Dec 2024 00:25:24 -0800 (PST)
Message-ID: <328c3bb6-1adf-4c64-81d4-40704ea1f19e@suse.com>
Date: Wed, 11 Dec 2024 09:25:16 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support
To: "Chen, Jiqian" 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , "Huang, Ray"
 ,
 "xen-devel@lists.xenproject.org" ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20241202060956.1124162-1-Jiqian.Chen@amd.com>
 <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com>
 
 <1e0576d9-400e-4483-8dd1-061e215a00cd@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.12.2024 08:57, Chen, Jiqian wrote:
> On 2024/12/10 19:25, Roger Pau Monné wrote:
>> So you suggest that the capability should be hidden in that case?  We
>> have logic to hide capabilities, just not used for the hardware
>> domain.  It would need some extra wiring to be capable of hiding
>> failed capabilities.
> Can you give me a guidance on how to hide a failed capability?
> What codes are current logic to hide capabilities?
> Then maybe I can add a patch to implement it.

It's really the other way around right now for "normal" capabilities:
We whitelist what we expose. See init_header()'s logic after checking
the PCI_STATUS_CAP_LIST bit. Actually past that block there's

        /* Extended capabilities read as zero, write ignore */
        rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL, 0x100, 4,
                               (void *)0);

I.e. no extended capabilities are exposed at all right now to DomU-s.
For Dom0 I guess we shouldn't use whitelisting, but the (extended)
capability list(s) would need similarly virtualizing to be able to
hide some.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 08:29:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 08:29:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854087.1267373 (Exim 4.92)
	(envelope-from )
	id 1tLI5c-0000ck-Jq; Wed, 11 Dec 2024 08:29:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854087.1267373; Wed, 11 Dec 2024 08:29: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 1tLI5c-0000cd-Gw; Wed, 11 Dec 2024 08:29:00 +0000
Received: by outflank-mailman (input) for mailman id 854087;
 Wed, 11 Dec 2024 08:28: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 1tLI5b-0000cX-94
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 08:28:59 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2417::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f72b463d-b799-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 09:28:57 +0100 (CET)
Received: from CH0PR03CA0093.namprd03.prod.outlook.com (2603:10b6:610:cd::8)
 by CH3PR12MB8331.namprd12.prod.outlook.com (2603:10b6:610:12f::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Wed, 11 Dec
 2024 08:28:54 +0000
Received: from CH2PEPF00000099.namprd02.prod.outlook.com
 (2603:10b6:610:cd:cafe::4f) by CH0PR03CA0093.outlook.office365.com
 (2603:10b6:610:cd::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.15 via Frontend Transport; Wed,
 11 Dec 2024 08:28:53 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH2PEPF00000099.mail.protection.outlook.com (10.167.244.20) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Wed, 11 Dec 2024 08:28:53 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 11 Dec
 2024 02:28:53 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 11 Dec 2024 02:28: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: f72b463d-b799-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NKv36r8ipnZ6AKp1hKmHwtEZ4xRg7frw1YXSDNeDFaQD1x3ZNAz1jPCIAP54o/+zCKxw4bMKWDmeSB4+Lh8iuCSLzKFAZbI5NjNlMtOLNF/pypQctOskGAjft/iAmJBXEocKQPkFTIAFCbKOSFe8uoaByphdQmw4r4syD9bjystEte61Lg5dDPaHEts2O6hqm24zQCSHzMfxmOMJJiJvnwAPE6ev1pNnZ6Z7lPp8VlPAmwi6O+cEynw5sMmL6jSFjPx+YQ3nIwm+3OOswyL8tzpfo8bmOjaFCeiX+QnGI2Vgarwp2gumk7wvZRpWx68xL2SMKNu3qAiIMFLxoBPq1A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=eLzfNi0grz/VmUoUxhLB8I2Zxu5Hrcj1Raz7s7mg02s=;
 b=POb56IF3ad2CU/uNWG9bhdHO1Gu5oaah1bwGoYuse64TpjddhovYJc0TBbufrlCxvvxuDQtuDSOA/IBdQVxTrrGr1SjkbE/28jPJ453ZlvZ+lQmQwGITbrtxXR/oaQLR5nuATle7F8CmruYwRZGPUcOM3n4uaaOKtM2aOyxIjOq4wAugxWw/RcZ59qC/XaPr5kOVQl/BEcFRlNRYGiu/yNDyZL/cQAez1dKVil1gNk7X87aV+bjK9h0WkK+6LiAttDS0rfm/6YgLCpDjJOmxc6ulQlz6r7U8+MYZmZCVT0duIJI6i3ZiCDIO2ulmf8uii99rXeVUOMkz9n5lta7A1w==
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=eLzfNi0grz/VmUoUxhLB8I2Zxu5Hrcj1Raz7s7mg02s=;
 b=AQafi4/Tfj0sj6uiOPVnu2yZjwM0hcvOu40twmy4iAupECW9JhpxqD/lc00Vz+awSZptIatoWfwF//blRuyzA7AybNLqWx7VAQvUGE1uYsVjofSUtQlTVoJ0z0Qs1BxXY1kYtqWqMyvET7jHwbF0wJ3q+tNXbiQ91ZtOPnFPHm8=
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=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Wed, 11 Dec 2024 09:28:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] MAINTAINERS: add Anthony, Michal, Roger to THE REST
To: Stefano Stabellini ,
	
CC: , ,
	, 
References: 
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000099:EE_|CH3PR12MB8331:EE_
X-MS-Office365-Filtering-Correlation-Id: 1b513a57-85b4-49c1-d7ef-08dd19bdd91e
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|36860700013|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?N2NEU2FzSyt4UmJwMmNJb0N1TTZJRkYvc1M3dkUzczRHdDFVTVNRTjYrZ2ZP?=
 =?utf-8?B?d3dnK1BvOUFhQWZTNksxU3FyME41Z0tmZlBYc0JXeUJvcXNqeVYva0dyblpP?=
 =?utf-8?B?VnlTYUFiNWNnNTB0Tk0zeHJTRFB6TG5kb2oxdklDNGZKUjMyNlcvcmtPYVkv?=
 =?utf-8?B?Q2JUU2FUY0Evc1VOQzdUTzZDODBvcnFkTitMQ1Vib3RZVGtDbWsxTEZ6MmJm?=
 =?utf-8?B?a3lNZ1YyTW42UGttNlA4N2JXbmxaQWpRcENCaVJabExVR2YvWHZWc0VXNVVi?=
 =?utf-8?B?N21kV0RPTTlWMnY5S01ZZloxVkdPUEhlMm1zRk1ocDRxV0Ywd0NnbVlYdmx1?=
 =?utf-8?B?aVp2N01xeHBpMTVMdkRhU1V4MnF3cDk3OGVHM1BJVmhOVDE3dzZGSHo5dllw?=
 =?utf-8?B?bXhnTGh6V3I4b1FNczhLVkh0VkRyTjVTdGUyRnpSai9yRnM2Szc0NWhqUXB1?=
 =?utf-8?B?aDBFVGlZRU16WDJkTFE1UEY3Rk1sdUhlWXUxMXdINWdHSlRnbm5vWklhNytB?=
 =?utf-8?B?Mk1abW8vWVZlZ3puYk5TajNpT2QwaHpxRFUxUzRqMmhRZm02Tlc0dmlzREcv?=
 =?utf-8?B?WmJ2cmlncFhkK0hjNmhnYXB2VTZDc1M4TCtSRUg1VlZpQTZ4OUF5R2RxR2NX?=
 =?utf-8?B?Ui9kVEVHSHowUzB6NjN6SDV1TlovVUFHVFNCVGxpNzErQlZNUE9BUDl1NmNn?=
 =?utf-8?B?eDdpSkxvNlUwKzI0SDJ6WHp2RFpuc1hMWUtydkJXUTdkTXowTWt3bTN4eDFy?=
 =?utf-8?B?aEd0aXRUWWJMdkV5bkl3MFhmL2p2K2MwbmZENldyMXdzbmFwSzVHTWFha2tE?=
 =?utf-8?B?OHlyZHFlTW1aeEllL3EyN2FVUGFXdnQvWFNveHFxejUvQUJLcm5NclZJeTdW?=
 =?utf-8?B?aExwTitxTW9yYWw0S2hJcktIR3d5RXNrQnJ3aWx4RlRoUmtuYm81NlpjVnRs?=
 =?utf-8?B?RXNWdTRjSWwrZnJzWVBtSWpjMzFudjZBanRpbzRoM05uL3RvNUlEOUc4b1pL?=
 =?utf-8?B?dDJjYmNZN0k4UnVsbUIvYWF6SkgyRjltRWg3KzJ4dU1hY0Zid3I4YW9YU1JE?=
 =?utf-8?B?ek0vZUU2RFhyWWNJZzVVemM3bDNqbnZlSVRoUkk1Z3ZVMUV2aWVNY01raExq?=
 =?utf-8?B?cUN6TVhUa0NZK0t4dlMwSkg3aEdOTDdHb3Fja200NlBXTnc2ZGtwLzlnMjNZ?=
 =?utf-8?B?TlJDbkFOOG1TQ2JjRDYzWEFkSDdvRVNPekREWk8xRUFrVkN0bXdLOHNjR1Qr?=
 =?utf-8?B?WEFTbHl2T0tOSnlPV0J2Zlc1Q0JiMDJnRVZnU2NCOXpqWUJ3Qk1IM3lZSDlq?=
 =?utf-8?B?R0ZjUlNHQTdzbGNNZ3Z6anlVdERTRTNhdU5sc3NrQUc1WlVKMG1iMGJXUHhi?=
 =?utf-8?B?Q0ViUCtJL3E1M1VSL2xVTmpFUjJHVmdPRFlTQ3JVNjRhTWxGSXV4akJSVUYy?=
 =?utf-8?B?R21KUll4Sk5ReTBXZWxKV2hjbG5WRDhIUFBBN0ZaUmRJUDQ4M2xYTEEvT1Ar?=
 =?utf-8?B?MExya3NFamgxOEovL29ERSt0QzJ5OVN0ZXZYVDZxeTdLeXVRbmw1ZEJJOHNt?=
 =?utf-8?B?ZmJuaU1vQlA3NzkrTFl3VDFLdVBCVE1jMUdiTVQyZFZOZmpjT0p3Z2kzNTMx?=
 =?utf-8?B?cGxwREVmaHFPMFZtdDRXZFVVbHhLSTlmQXBmTzN2UmxHNUxLMHAwNmxiMGt3?=
 =?utf-8?B?V2dFOW1SUm5LNkNSVUlWaStZZHBVWWkwc0IrN0tkeFZJM3dHZjNBOGJibWQ1?=
 =?utf-8?B?YmkyQWZZR1VtdURydk9NQ2xsaFdpZmtCUkVRb1J0L3BnUmJqWEgySUpaaDhq?=
 =?utf-8?B?czQ1ZlRVeUhwNHRPeFFUbWFiemZJS2s5T2JhRW5PcW8wSTk0aTFVVVZwWlZN?=
 =?utf-8?B?TUdBd0ZVYndvbU5LWmsxWHdtU2pHdk8wUlVuN1JzOHVHaHZiSVlReXA5cWRP?=
 =?utf-8?Q?I1qJPqqu7VXj/SJtEHNvICRKE36PFYvm?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Dec 2024 08:28:53.7887
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1b513a57-85b4-49c1-d7ef-08dd19bdd91e
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000099.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8331



On 11/12/2024 00:58, Stefano Stabellini wrote:
> 
> 
> In recognition of their outstanding work and years of service to the Xen
> Community, please join me in welcoming Anthony, Michal, and Roger as
> Committers and REST Maintainers.
> 
> Signed-off-by: Stefano Stabellini 
Acked-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 08:33:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 08:33:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854102.1267382 (Exim 4.92)
	(envelope-from )
	id 1tLI9a-00038K-6C; Wed, 11 Dec 2024 08:33:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854102.1267382; Wed, 11 Dec 2024 08:33: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 1tLI9a-00038D-3g; Wed, 11 Dec 2024 08:33:06 +0000
Received: by outflank-mailman (input) for mailman id 854102;
 Wed, 11 Dec 2024 08:33: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 1tLI9Y-00036j-Tl
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 08:33:04 +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 8668a82a-b79a-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 09:32:58 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-434a742481aso55816195e9.3
 for ; Wed, 11 Dec 2024 00:33:02 -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
 41be03b00d2f7-7fd332db74asm6210066a12.52.2024.12.11.00.32.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 00:33: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: 8668a82a-b79a-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733905982; x=1734510782; 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=potnQE8cNDslURE4XZUisgZLG40sqRbJrJmKaGg8/6Y=;
        b=gPWbmlwH89Gx08Lu3MPMnICWugxnDr1QZEKP1ichypNJPONQVk7giFEYZQ7Yv23cjb
         3oqUoHVkwtcmSx29TFT69S2nwyodx15uqo6AwpA9Cb1mrHw1pol8nrtND9pLy18lk8FW
         x5YhAHQjmjrcWZwzXRFe1+1Y47EYbvU6heUbAAGJ6KLOX0CHMubeKxIzjUtiaz3N9RRI
         RbcjzLIChyXfETyNUxnWWcKBlB4R8VlZV7kxLyiCeGqA0ttcWdB/cDK+QZXU2X9V93nN
         J7Fq/TNWTXO6Z5famJhp72kYYuOurOqsfHSb0fHZhNLLCb4WnQhAdAY5XNFJ0OVonKQ/
         bG4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733905982; x=1734510782;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=potnQE8cNDslURE4XZUisgZLG40sqRbJrJmKaGg8/6Y=;
        b=BInkg/xDXNXQsNrQMIF88gehKGj7bVWk2ZrXtBxX7AmKbLvzltPkCHIKknDWa8j+VI
         SLlNHrZjW090JXwgXfNM2dVXiZ6scH/31ht8hkDn97YKIio00QVbva0neNK2u1az3fHN
         C+xSbA62iiqh/4VIU4UaIS18ey0d9xFcfAAH2iCkC33/PVirZHofl/HqU20juS3fMi9D
         LNPX8w4JCwEGHqYBqt/rozjPQsz+kMw8aUt/8gT+RHSqGA5s6AuMNKW0sdX/p90fKz57
         mCZf5K9UtrOdBg7/xDihJv0GVQTZYsQOPBN3slOVkCUH7UqDtS0BiaMhUSIC6s3UHAp1
         K7Dw==
X-Forwarded-Encrypted: i=1; AJvYcCWtf3tPJ6RErW8HBYyNf1MA3JLqhS+5gIOsxIqXJ+Z7Anz8cMSP/H5c8h+t9ZLSBSCRP+NqwN5l5AM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyoxlQz5DfcD6C0n9j1weSVjN6n5R9UnVsf7EhiLqgYyGWnIRuT
	6t7BxsgyYBf19KACd5UNtSi0FCZrjueJCUCM4PEJ2fDq5mBUPUYsBTdkMCgi0w==
X-Gm-Gg: ASbGncs/SKaVofcY1rMM3x8n9gaJi9+GE7lDJZsejFb2AOWzqjsWq1uohtdKEapFbj9
	cTkJ+rJ2Ht0TWAZpO8C8Jnh5eHDes6cQ4q4jd2PnpT7Aj0XSlzYiOhKEtul3DIBRp9bEV0jP8Ju
	T4SVs7h1e1evWLvBG6MYEsozlMzJvBVYV2Vy9PBRYq3COxsx03R+ILEnlyDKOcSqzpcScOlHXoE
	oXzzGj9OBxwp3YNtmVYAQyEk2RXN80LDF1To4e0IUSpV3JLjArXPzIDeAYgNW0ree04mUCIl3qm
	Vq6tKzIstH7j0hzjoH0Dx6KsJczbkkhcVYdTHqM=
X-Google-Smtp-Source: AGHT+IGvV3H8by3kN9gkg5+hVtaSObhyhGye3WT6Uyla5YEWbw1O8MK/nlP9MRuZFBOpaGytJg8Vrg==
X-Received: by 2002:a5d:47c9:0:b0:386:1ba1:37dc with SMTP id ffacd0b85a97d-3864cea39ebmr1354595f8f.47.1733905982280;
        Wed, 11 Dec 2024 00:33:02 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 09:32:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/7] xen: add new domctl get_changed_domain
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Cc: "Daniel P. Smith" ,
 Anthony PERARD ,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241206130221.17773-1-jgross@suse.com>
 <20241206130221.17773-6-jgross@suse.com>
 <69e08251-c227-42a5-a2e4-a4eb7d63961d@suse.com>
 <30304914-f0c5-4053-ae23-890fa5b8a0c2@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.12.2024 08:44, Jürgen Groß wrote:
> On 10.12.24 17:29, Jan Beulich wrote:
>> On 10.12.2024 16:52, Jürgen Groß wrote:
>>> On 09.12.24 18:04, Jan Beulich wrote:
>>>> On 06.12.2024 14:02, Juergen Gross wrote:
>>>>> --- a/xen/common/domain.c
>>>>> +++ b/xen/common/domain.c
>>>>> @@ -192,6 +192,54 @@ static void domain_changed_state(const struct domain *d)
>>>>>        spin_unlock(&dom_state_changed_lock);
>>>>>    }
>>>>>    
>>>>> +static void set_domain_state_info(struct xen_domctl_get_domain_state *info,
>>>>> +                                  const struct domain *d)
>>>>> +{
>>>>> +    info->state = XEN_DOMCTL_GETDOMSTATE_STATE_EXIST;
>>>>> +    if ( d->is_shut_down )
>>>>> +        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN;
>>>>> +    if ( d->is_dying == DOMDYING_dead )
>>>>> +        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DYING;
>>>>
>>>> The public constant saying "dying" isn't quite in line with the internal
>>>> constant saying "dead". It may well be that Xenstore only cares about the
>>>> "dead" state, but then it would better be nemaed this way also in the
>>>> public interface, I think.
>>>
>>> Okay, I'll rename it to "XEN_DOMCTL_GETDOMSTATE_STATE_DEAD".
>>
>> Well, maybe have both DYING and DEAD, even if Xenstore right now needs only one?
> 
> Yes, might be interesting in the future.
> 
>>
>>>>> @@ -866,6 +873,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>>>>>                    __HYPERVISOR_domctl, "h", u_domctl);
>>>>>            break;
>>>>>    
>>>>> +    case XEN_DOMCTL_get_domain_state:
>>>>> +        ret = xsm_get_domain_state(XSM_XS_PRIV, d);
>>>>> +        if ( ret )
>>>>> +            break;
>>>>> +
>>>>> +        copyback = 1;
>>>>> +        ret = get_domain_state(&op->u.get_domain_state, d, &op->domain);
>>>>> +        break;
>>>>
>>>> Especially with this being a stable interface, surely the two padding fields
>>>> want checking to be zero on input (to possibly allow their future use for
>>>> something input-ish). Then even the memset() in the function may not really
>>>> be needed.
>>>
>>> I'll add the check. Removing the memset() is a little bit doubtful, as this
>>> might result in leaking hypervisor data e.g. in case a domain isn't existing
>>> (this will copy the internal struct to the user even in the -ENOENT case).
>>
>> Which internal struct? The function is passed &op->... for both parameters.
>> And op is fully copied from guest space.
> 
> Sigh. I shouldn't have answered so quickly while being deep into other
> topics. :-(
> 
> While I agree that the caller _should_ pass these fields zeroed, I'm still
> not sure we should rely on it.

You said you'd add the check. Then we not just rely on caller zeroing, but
we actually refuse non-zero fields there. And we fill all other fields.
Hence ...

> Do you insist on removing the memset()? If not I'd rather keep it.

... while I guess I wouldn't insist, to me such a memset() effectively
would count as dead code (for having no recognizable effect). And you know
what Misra thinks of dead code, even if strictly by their criteria this
wouldn't count as "dead". Yet it would violate the underlying principle of
there wanting to be a (functional) reason for everything there is.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 08:41:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 08:41:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854115.1267393 (Exim 4.92)
	(envelope-from )
	id 1tLIH8-000553-Up; Wed, 11 Dec 2024 08:40:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854115.1267393; Wed, 11 Dec 2024 08:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLIH8-00054H-Rj; Wed, 11 Dec 2024 08:40:54 +0000
Received: by outflank-mailman (input) for mailman id 854115;
 Wed, 11 Dec 2024 08:40: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 1tLIH6-00053S-VA
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 08:40:52 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9d6d6599-b79b-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 09:40:46 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-aa6b4cc7270so58575966b.0
 for ; Wed, 11 Dec 2024 00:40:51 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa6841eece0sm452938666b.56.2024.12.11.00.40.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 00:40: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: 9d6d6599-b79b-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733906450; x=1734511250; 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=LZXiN7dOF3YMKu7Pm2MUwWBz8ub48mTQD04O+vFfaX8=;
        b=ubCmlC3IW3AZZM4onksusjrBrtXTodcxZcZ1x9OpyHidpIUIdkLMcMPxHqbIGJGWRW
         ky4NXY5QtyFdKCocMKSoG1iLRd7qTPJq9CT2/uyFddV0ycs8kXYPNvwSEuuMPlnlK9GI
         /ao/JZSwPbC70D/4cL+5NvBLTrbJW1QLboefc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733906450; x=1734511250;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=LZXiN7dOF3YMKu7Pm2MUwWBz8ub48mTQD04O+vFfaX8=;
        b=D77dFcFs59hsipH5O7TeE8coE+iYe3korAiFb11+niWU8140jjqeTIpbcXKMhYMEMW
         rK07aLVgIvOpNpA4OYZaE8jDvi1I5pKZq7SpiZWcJYhLmZYEmgNfurd4p8L5W4QsxHUR
         CPbjDrqKKfLev791WQkwj39rV9snDQgXhYI8NqhDwglA8nzxCgWVqqgwaaHC2S9Ym8qo
         GaeGe1RQ6V5o0ixc/SIq5CciqboLfaXLS/oi28SiUWuHLz9w3gXGTs8PpQKVN4DSjOjc
         50+NkWI4lWpTk+/voT3AjIUvVnroVv+pPSvXpj1kyh6pBIuuo0tDnGSqNTGx/R5TXEkF
         MMTQ==
X-Forwarded-Encrypted: i=1; AJvYcCWxpOKdCi5kS5rPDeSG769TiaJXVGeD3OytGNKvidoYotCFYuJE4CK2Zx58Moo2gIFSHL4Hlr8RX6c=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy+2xzNd+KnH8zvXK9Q6hsEA9tmHn3UT1Z3wsiXIXrmIcsKCM5W
	YAjVvR38vtAWpwafS4Ewf19NevJHOSbYgjrCRAF8jK54nRRQ5pQCWN320HU/l98=
X-Gm-Gg: ASbGncsyu+EGxCrWWIPmQFpZIgeaggs4zjr0t0hJRr3zIINnwMYBUnfkF1p8kxVzlo8
	k7R0wBjTJNxNcT/G+YX4QnsdN0V3CRfKEP67JPCQMpUdIS54JxlEPJSOPAfsbBnMvuR4OcTr7tC
	Fb9Oy0wB2sifcEL2MRbeWsx5bXLcjAGotLjNLKdci4GfNLXNvWxOkZy5HfY/zHGFRiOfQQbGV8Q
	8z1OOqzw4lCM6ss1odWX/o/NOdvxc5roe28w2+vb6w2QpR89sRGRtNvWPazesE=
X-Google-Smtp-Source: AGHT+IGBvXnPWIBOzRk4ggwvbOXDCPdNb4d4GtEuPWeTAKiVck0QnniMgPkQhnfc33kT4t8AwUFuwA==
X-Received: by 2002:a05:6402:2105:b0:5d0:cfad:f71 with SMTP id 4fb4d7f45d1cf-5d43316510amr4120628a12.32.1733906450410;
        Wed, 11 Dec 2024 00:40:50 -0800 (PST)
Date: Wed, 11 Dec 2024 09:40:49 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: Jan Beulich ,
	Andrew Cooper ,
	Julien Grall ,
	Stefano Stabellini ,
	"Huang, Ray" ,
	"xen-devel@lists.xenproject.org" 
Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support
Message-ID: 
References: <20241202060956.1124162-1-Jiqian.Chen@amd.com>
 <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com>
 
 <1e0576d9-400e-4483-8dd1-061e215a00cd@suse.com>
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, Dec 11, 2024 at 07:57:29AM +0000, Chen, Jiqian wrote:
> On 2024/12/10 19:25, Roger Pau Monné wrote:
> > On Tue, Dec 10, 2024 at 10:54:43AM +0100, Jan Beulich wrote:
> >> On 10.12.2024 08:57, Chen, Jiqian wrote:
> >>> On 2024/12/10 15:17, Jan Beulich wrote:
> >>>> On 10.12.2024 08:07, Chen, Jiqian wrote:
> >>>>> On 2024/12/9 21:59, Jan Beulich wrote:
> >>>>>> On 02.12.2024 07:09, Jiqian Chen wrote:
> >>>>>>> +        if ( rc )
> >>>>>>> +        {
> >>>>>>> +            printk("%pp: add register for PCI_REBAR_CAP failed (rc=%d)\n",
> >>>>>>> +                   &pdev->sbdf, rc);
> >>>>>>> +            break;
> >>>>>>> +        }
> >>>>>>> +
> >>>>>>> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
> >>>>>>> +                               rebar_offset + PCI_REBAR_CTRL, 4,
> >>>>>>> +                               pdev->vpci->header.bars);
> >>>>>>> +        if ( rc )
> >>>>>>> +        {
> >>>>>>> +            printk("%pp: add register for PCI_REBAR_CTRL failed %d\n",
> >>>>>>> +                   &pdev->sbdf, rc);
> >>>>>>> +            break;
> >>>>>>
> >>>>>> Is it correct to keep the other handler installed? After all ...
> >>>>> Will change to "return rc;" here and above in next version.
> >>>>
> >>>> I'm not convinced this is what we want, as per ...
> >>>>
> >>>>>>> +        }
> >>>>>>> +    }
> >>>>>>> +
> >>>>>>> +    return 0;
> >>>>>>
> >>>>>> ... you - imo sensibly - aren't communicating the error back up (to allow
> >>>>>> the device to be used without BAR resizing.
> >>>>
> >>>> ... what I said here.
> >>> Sorry, I didn’t understand.
> >>> Do you mean it is not enough to return error code once a handler failed to be installed, I need to remove the already installed handlers?
> >>
> >> No, if you return an error here, nothing else needs doing. However, I
> >> question that returning an error here is good or even necessary. In
> >> the event of an error, the device ought to still be usable, just
> >> without the BAR-resizing capability.
> > 
> > So you suggest that the capability should be hidden in that case?  We
> > have logic to hide capabilities, just not used for the hardware
> > domain.  It would need some extra wiring to be capable of hiding
> > failed capabilities.
> Can you give me a guidance on how to hide a failed capability?
> What codes are current logic to hide capabilities?

This was done by Stewart for the legacy PCI capabilities, but not
exactly to hide the capabilities that fail to init.  Take a look at
commit:

d830b0a7bc7e xen/vpci: header: filter PCI capabilities

However that was designed to expose a fixed set of capabilities,
always known when init_header() is executed.  If we want to hide
capabilities on failure we will need a bit more flexible interface I
think.

Ideally we would like to tie this to initialization hooks themselves,
so that in vpci_assign_device() an init function failing automatically
triggers the hiding of the failing capability.  That would need an
interface similar to:

#define REGISTER_VPCI_INIT(, , ,
)

REGISTER_VPCI_INIT(PCI_CAP_ID_MSI, init_msi, VPCI_PRIORITY_LOW,
false);

And then in vpci_assign_device() any init function that has a
capability ID different than 0 and fails to initialize would lead to
the capability being masked.

It would be great to have an interface like this in place, because the
current error handling in vPCI is not great.  For the hardware domain
init functions failing will just lead to the device being fully
accessible by dom0 without any mediation.

Anyway, we don't do any of this for dom0 at the moment when MSI or
MSI-X fail to init, so I'm not sure it's fair to ask that you do this
for ReBAR.  It would be great if you want to, but it's not a trivial
amount of work.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 08:43:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 08:43:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854125.1267402 (Exim 4.92)
	(envelope-from )
	id 1tLIJF-0006bJ-9i; Wed, 11 Dec 2024 08:43:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854125.1267402; Wed, 11 Dec 2024 08:43: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 1tLIJF-0006bC-6r; Wed, 11 Dec 2024 08:43:05 +0000
Received: by outflank-mailman (input) for mailman id 854125;
 Wed, 11 Dec 2024 08:43: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 1tLIJD-0006b2-V3
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 08:43:03 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id eed35da1-b79b-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 09:43:03 +0100 (CET)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-5d3e6f6cf69so5954803a12.1
 for ; Wed, 11 Dec 2024 00:43:03 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa686bb8cb2sm431282366b.153.2024.12.11.00.43.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 00:43: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: eed35da1-b79b-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733906582; x=1734511382; 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=Aa5Vrcx5q+gTRsOkd2CZPk0FNP9WuAT4SSQqgaB83Bw=;
        b=i6qe9cZ5//C/yCCdm38UbzOoN9G1c2uB1WQph3SOuwZuIbegKQb+GcELm0E8Ik2roR
         G925joqEhGrCQEKANzkh2z+Jooa2iSYbv3ObDwFOhUBjj3bTlf2Vx1QTJ5r3MG7Qxv+q
         GFq3H0z9JrTqCtbx+Wc8jLZcfnYABUFM2SEto=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733906582; x=1734511382;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Aa5Vrcx5q+gTRsOkd2CZPk0FNP9WuAT4SSQqgaB83Bw=;
        b=vcQHb35fAdi0PxcuWwzZOe+PENazEJxy8KgLMSffLX0UCg2nysuvMbYLFsCCtCWsdO
         GvJWI+AeNaovFQsqzKfAg7VkriW0zXqamY+iN5K9+D1EyIlRGEQ/BweR547JJ23F63zS
         UmRRSnAC0n5Sv68kn0U8g8AlWILaS0ynKziK2tUkwhKSqSZVHnw/sZDbqOTwQ3nhCSDr
         Gx34SdUtXtZIWlg6iAPSJ25qVi6LI5RR1bKpTho6rvXrCu1X+3d+TDYd6N9ZyFnuUO+H
         zztmjD0tmqv+DBCBSGcFfw7fsQflbpsivEO/7Xs8y8t+XGQLD84ICMndv4jRfABLEsRi
         c0tg==
X-Forwarded-Encrypted: i=1; AJvYcCV0NXtJAsYlAjBgEshdA0hn5mxBuBn5+VkrMgAFhZRnCBEGYG6IFr0hQ2NUxIasZF+ZHlKQUfSj3YM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyjxYRshOmvwrKtnNQ2vem6KrOOHjTcbEhFFKSplH6gYxvq1CeP
	eEhx0IwHb8V2rK4TrKTI5G/o81rv3itUI3vfLNJRo5P4WA+fm9rv/sYLpp+9I/Q=
X-Gm-Gg: ASbGncteM9d/BSL1TRPbcniD2DHGOmmWSUDZmDQ/9Bp4jxLDIp1Djdqdc88JRH4ELkM
	cjwu4kfcnX/fnEjTOulcusNR/R9U2/k1RY79Pu29eZ+HG4tS1G7aOA7W7HOaFeT/bYwdczdSoEc
	HYIcLE+o2pQdhKSjIYJeYC7ZejjfEWG0mG70crshnbhStVodk7BZNKr2lEAd9jtYaIxiInba5l0
	x25ATRqpqOpwkQYNexzt9z6DrmItGKs5BcXH6aUnwkSRkhJqvjHr3XSPPI8XVw=
X-Google-Smtp-Source: AGHT+IEgTeSO/dr5GlQL6Ty94FwJHTJKnzcaeb48LkRYats9DGf5NTZt1ug21u+MT9B3npbo6gdrHA==
X-Received: by 2002:a05:6402:3806:b0:5d2:7199:ad4 with SMTP id 4fb4d7f45d1cf-5d433066180mr1639622a12.6.1733906582265;
        Wed, 11 Dec 2024 00:43:02 -0800 (PST)
Date: Wed, 11 Dec 2024 09:43:01 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: "Chen, Jiqian" ,
	Andrew Cooper ,
	Julien Grall ,
	Stefano Stabellini ,
	"Huang, Ray" ,
	"xen-devel@lists.xenproject.org" 
Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support
Message-ID: 
References: <20241202060956.1124162-1-Jiqian.Chen@amd.com>
 <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com>
 
 <1e0576d9-400e-4483-8dd1-061e215a00cd@suse.com>
 
 
 
 
 <328c3bb6-1adf-4c64-81d4-40704ea1f19e@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <328c3bb6-1adf-4c64-81d4-40704ea1f19e@suse.com>

On Wed, Dec 11, 2024 at 09:25:16AM +0100, Jan Beulich wrote:
> On 11.12.2024 08:57, Chen, Jiqian wrote:
> > On 2024/12/10 19:25, Roger Pau Monné wrote:
> >> So you suggest that the capability should be hidden in that case?  We
> >> have logic to hide capabilities, just not used for the hardware
> >> domain.  It would need some extra wiring to be capable of hiding
> >> failed capabilities.
> > Can you give me a guidance on how to hide a failed capability?
> > What codes are current logic to hide capabilities?
> > Then maybe I can add a patch to implement it.
> 
> It's really the other way around right now for "normal" capabilities:
> We whitelist what we expose. See init_header()'s logic after checking
> the PCI_STATUS_CAP_LIST bit. Actually past that block there's
> 
>         /* Extended capabilities read as zero, write ignore */
>         rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL, 0x100, 4,
>                                (void *)0);
> 
> I.e. no extended capabilities are exposed at all right now to DomU-s.
> For Dom0 I guess we shouldn't use whitelisting, but the (extended)
> capability list(s) would need similarly virtualizing to be able to
> hide some.

Given this capability is only to be exposed to the hw domain (at least
for now), I'm not sure it's fair to ask to add all this
infrastructure as part of adding the new capability.  It would be great
to have it, but doesn't seem fair when there's already MSI and MSI-X
implemented without such support.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 08:53:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 08:53:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854139.1267412 (Exim 4.92)
	(envelope-from )
	id 1tLITK-0000g0-5h; Wed, 11 Dec 2024 08:53:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854139.1267412; Wed, 11 Dec 2024 08:53: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 1tLITK-0000ft-38; Wed, 11 Dec 2024 08:53:30 +0000
Received: by outflank-mailman (input) for mailman id 854139;
 Wed, 11 Dec 2024 08:53:29 +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 1tLITJ-0000ed-BX
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 08:53:29 +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 602c114c-b79d-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 09:53:22 +0100 (CET)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-38634c35129so3022787f8f.3
 for ; Wed, 11 Dec 2024 00:53: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
 d9443c01a7336-215f8e41e52sm101740845ad.3.2024.12.11.00.53.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 00:53: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: 602c114c-b79d-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733907206; x=1734512006; 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=nzGRk8qqkY3xMW9o1TOCpGG+6aY06zQZYsDHdVAAimE=;
        b=WMLpKLeAkpdsBRlNDsDBA4kvujlf7CbwKGQCSXDgY7u+d2Mt7Dm8zXcxHxSRN05u5G
         Ozp1HH8FLlTTKVs9PE71M61NtzZFYjJelSuDE7P/yPoCUPaMpgpKn2+TQK4ITl7RHi/7
         UFQMja4QKgT0T9bhzGLds2tH3e2nN/+oe6h1YjQ6lidBJT3v5XH9aoN85kXIv7IVp1Ph
         Bf7GO2+9VXHhGFN2tfB0ij1FqIvscJtWUgAqOtvgCBOE+oREnCUnb6UCvJt8WO72ECC0
         XAFki0Qx7/byNpQ3bPaqskrIjUKa0Ik5B8dvxzRHiA08IORI/xGjlXOe+gb9lR6VFpBW
         jS5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733907206; x=1734512006;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nzGRk8qqkY3xMW9o1TOCpGG+6aY06zQZYsDHdVAAimE=;
        b=Tqcm6d4ffSMuVBMHl/ZVa7SLdst07jH22b+aMf1aNkBeMzQ0H5ME+Krbs0eI4wjJQt
         rn3SPz9TTToa/xoKPgzMBob5xTiN1lzkPUhefpgF3/9tB6ljqcxAiuVViBv3KVpDmPqk
         oSOYbmSQ9WBti4unnzaDBKDjcDS4FfWDLwAbXIG9kZ7+CY3tvtCUNBWfn/V6A8Pc/cff
         vLcaFygNrDImZ7HTrDQrfDmrh9R7GOcRVB9N6jVJTIxMwtEppWpz+e0Ck4lNM5G0mDfF
         cTU1cCMPSbW9GXqWR4xFKBPNM4EzebmxIoUkJVMJTBX8MFVICIa8aaC/MbJyrlwnzxwm
         yRAQ==
X-Forwarded-Encrypted: i=1; AJvYcCWQ0l7VBZ33apXq7udDQh4VkELVEaDPrSQQ3NQyjfD9DDpNDRCHRaD7l2znt36y6SEGjgFfuXu884c=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx8KDHgVF7qscOZ1yTqCC79hNbRFt+REpUpXGEwc4y6VhKV6qnZ
	7Bi17/zuqC9mttx7yzYNjUwiq7fd8ax65N7qIpTCtzEq8K109Gdjeg4OTPmi7A==
X-Gm-Gg: ASbGnctWb3aJ+CVhKZ2JtHXPOPvQ6B3hAFCiPwHhdx1nujWaZC7dRk5RxhXXnzHWwv4
	CktaaXFlUjRClSrn37JA4bfWrfcl0aR8OrbGDOxlDfNGph+ezF2l33DwqdppBkb/L7Tsv8AmZx9
	1+EdyrQphd7Z6g9PHJ3TbwWIZ2GWJF3sxXvt2VW/7SIJZukvxSS8v1xth6pzRGseaVpbShvruvr
	ypnvPNYwEZ2HF94/oSjLN5levLZ91WOu9HvW3Yk1YJANIfVCEjpmgpOichhC5x8Zn0MDx04+W07
	cSUHPZzca28NfWtOnQZHy9QUE77gCFK4Y7CzwMo=
X-Google-Smtp-Source: AGHT+IEv60cWKKtjALTP5VYOTdMOWUJ+4dAaZ65DGlP4bxpww8yyP36qUDIQL8La9WwNF/gHBt+k8g==
X-Received: by 2002:a05:6000:2aa:b0:385:dedb:a12f with SMTP id ffacd0b85a97d-3864ce7fa47mr1374377f8f.6.1733907206527;
        Wed, 11 Dec 2024 00:53:26 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 09:53:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: "Chen, Jiqian" ,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini , "Huang, Ray"
 ,
 "xen-devel@lists.xenproject.org" 
References: <20241202060956.1124162-1-Jiqian.Chen@amd.com>
 <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com>
 
 <1e0576d9-400e-4483-8dd1-061e215a00cd@suse.com>
 
 
 
 
 <328c3bb6-1adf-4c64-81d4-40704ea1f19e@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.12.2024 09:43, Roger Pau Monné wrote:
> On Wed, Dec 11, 2024 at 09:25:16AM +0100, Jan Beulich wrote:
>> On 11.12.2024 08:57, Chen, Jiqian wrote:
>>> On 2024/12/10 19:25, Roger Pau Monné wrote:
>>>> So you suggest that the capability should be hidden in that case?  We
>>>> have logic to hide capabilities, just not used for the hardware
>>>> domain.  It would need some extra wiring to be capable of hiding
>>>> failed capabilities.
>>> Can you give me a guidance on how to hide a failed capability?
>>> What codes are current logic to hide capabilities?
>>> Then maybe I can add a patch to implement it.
>>
>> It's really the other way around right now for "normal" capabilities:
>> We whitelist what we expose. See init_header()'s logic after checking
>> the PCI_STATUS_CAP_LIST bit. Actually past that block there's
>>
>>         /* Extended capabilities read as zero, write ignore */
>>         rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL, 0x100, 4,
>>                                (void *)0);
>>
>> I.e. no extended capabilities are exposed at all right now to DomU-s.
>> For Dom0 I guess we shouldn't use whitelisting, but the (extended)
>> capability list(s) would need similarly virtualizing to be able to
>> hide some.
> 
> Given this capability is only to be exposed to the hw domain (at least
> for now), I'm not sure it's fair to ask to add all this
> infrastructure as part of adding the new capability.  It would be great
> to have it, but doesn't seem fair when there's already MSI and MSI-X
> implemented without such support.

Well, of course this can also be modeled after MSI/MSI-X, failing
assignment when initialization for a capability fails. Yet while for
MSI / MSI-X this feels okay-ish (considering that many devices now
can't even operate very well without either of the two), I'd expect
BAR resizing to not be something that drivers (typically) rely on.
"Typically" because iirc Jiqian said the AMD display driver actually
does.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 09:17:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 09:17:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854158.1267426 (Exim 4.92)
	(envelope-from )
	id 1tLIqo-0005aN-6z; Wed, 11 Dec 2024 09:17:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854158.1267426; Wed, 11 Dec 2024 09: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 1tLIqo-0005aG-3X; Wed, 11 Dec 2024 09:17:46 +0000
Received: by outflank-mailman (input) for mailman id 854158;
 Wed, 11 Dec 2024 09: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 1tLIqm-0005aA-K8
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 09:17:44 +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 c6b32ebd-b7a0-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 10:17:43 +0100 (CET)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-385e2880606so5236198f8f.3
 for ; Wed, 11 Dec 2024 01:17:43 -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
 d9443c01a7336-21641f46e3csm55154195ad.181.2024.12.11.01.17.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 01:17: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: c6b32ebd-b7a0-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733908662; x=1734513462; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=+NEGAqMfxPspZz6I0r7gy+rR8o+E5BntXw2Fa0wOKdo=;
        b=fJ+MvGn1YEuGMQUjTPDa/qXs3Uth6oI5iBk2zBmL7x/Kx/35vlOZr8NAIRTcDN4iil
         EVRO+MVgVlw1bVNCxtXegNRuA94ZTLXa1/ko/nVhlc3IBuro86VWFM9g1XwUOLUpj+RR
         39Eja0dNqa9U7UPdTE6cpIuFYv3aOFP20Is5+b4Lf4eytXpvje019x+UTFJN7GzVvl0g
         Zt8qSNYfex+7Lq6m3Is6dLAjKbpx32g97jbBX1A6Grg28IGiv/N+9YaEXH/UvfDD5xbM
         eK0XbiXPkwtlsmi+NAIy6Tw7l/gWuvtYlyNGQZ6+ZdpP8fZPjbroZFB8BZ4UZSTMQA5I
         11vQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733908662; x=1734513462;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:subject:from:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=+NEGAqMfxPspZz6I0r7gy+rR8o+E5BntXw2Fa0wOKdo=;
        b=QknDjGA2sBYbIVNjQJMWZVhClI3stK1iUPrLyRWanR1xf8jH230/GhsLvmpS1rZ2dJ
         ZGDoHatEyVpzb7dZqkJWEalo+cTp6byAe8qyyIMlcU9IChqJIsASJv4LOYIbzIzGJZuu
         MsXDNOy4V4mNR97UdNgSAsStQSQFuht8rtS+tI+nE1S3LDIPtqzZgFVE7bPGfmI6VNEm
         JMm2dsG/Y90YH+b3H3Hv2/c18bO/uj7wJ+0lNFDOdOycAEpi84QVxdosy3z2b4Fe9iF8
         xn6KpH96g9MB5eOSsgeK7Vvt9gxD/+woqdA8MOJNPrn2ppCyaNNn0PBs/KzfCLHAfWG/
         iUIA==
X-Gm-Message-State: AOJu0YxczpHfAknY2FO/wMc/PC7VQbsTyZt8TdHoUGu2jeuXHUO3C6mY
	rmxFqrA7/lL0o1g6lC4QjzBstz8atPkLXtt4qPcAOwqycpNV8Jh/84ovao1i3wJ7ETjM+IRcRnQ
	=
X-Gm-Gg: ASbGncsiqTZyxKwDQPxqpzO4tCSAymPLj4szpGafCY6390AhsW2Cb7e7jnW0hecHk7V
	p0vnyYr7sH+n7lwGjzLNY1dsAo4mY1Nw+c3TzU3/eZjg5VmSlCb/LnZk5L0OIq02dxDdb7kI2t+
	CbTv3a7kTGVvVym8gxuOLfKJnS0RW84qkYfJT4c9m6nh4aEW7dyBSECdD7SVIAuuhM84FJ2pdPF
	p6fogelp/KdSNagOPx3xVkbZxokt2bXiaaUE95afM35hfWoBXAteTkV2niO+VZUhRanISTQGJXk
	ORwG923amWTdG9TMnELk6XgLIy0Zn2bjRAUtD38=
X-Google-Smtp-Source: AGHT+IFmQRx+JXsbVb4HIKmv79sqi0y7F+lum66/Ggoqn1fkOdgVL/f3rj2bEbLeBKYemIBu/GwcxA==
X-Received: by 2002:a05:6000:4011:b0:385:d143:138b with SMTP id ffacd0b85a97d-3864ced3841mr1511464f8f.51.1733908662226;
        Wed, 11 Dec 2024 01:17:42 -0800 (PST)
Message-ID: <199a47ac-582d-47ad-b5c6-7847ac16831d@suse.com>
Date: Wed, 11 Dec 2024 10:17:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich 
Subject: [PATCH v7.1 3/7] x86emul: support USER_MSR instructions
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <3a25cd59-e1cb-4bfc-b868-fb11599d22f5@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: <3a25cd59-e1cb-4bfc-b868-fb11599d22f5@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

While UWRMSR probably isn't of much use as long as we don't support
UINTR, URDMSR may well be useful to guests even without that (depending
on what OSes are willing to permit access to).

Since the two VEX encodings introduce a lonely opcode point in map 7,
for now don't bother introducing a full 256-entry table.

Signed-off-by: Jan Beulich 
---
The retaining of (possible) #PF from the bitmap access is "speculative"
(the spec doesn't mention #PF as a possible exception; conceivably this
might also need converting to #GP).

I'm a little wary of the "MSRs Writeable by UWRMSR" table that the spec
has, and that our code thus also enforces: As new MSRs are added to that
table, we'll need piecemeal updates to that switch() statement.

The forced setting of cpu_policy.feat.utmr could likely be done
globally, i.e. early in main(). Limiting its scope is merely "just in
case". Thoughts?
---
v7.1: Add MSR-specific feature checks for UWRMSR (incl the UTMR feature
      bit and its overriding in the test harness).
v7: Add missing vcpu_must_have() and override in emul_test_init(). Use
    MSR constants even more.
v6: Add MSR_UINTR_TIMER to header. Use MSR constants in test harness.
    Re-base.
v5: Correct ModR/M.reg check for VEX-encoded forms. Cosmetic test
    harness adjustment. Re-base.
v4: MSR index input regs are 64-bit (albeit only the APX spec has it
    this way for now).
v3: New.

--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -864,7 +864,9 @@ static const struct {
     { { 0xf6 }, { 2, 2 }, T, R, pfx_66 }, /* adcx */
     { { 0xf6 }, { 2, 2 }, T, R, pfx_f3 }, /* adox */
     { { 0xf8 }, { 2, 2 }, F, W, pfx_66 }, /* movdir64b */
+    { { 0xf8, 0xc0 }, { 0, 2 }, F, N, pfx_f3 }, /* uwrmsr */
     { { 0xf8 }, { 2, 2 }, F, W, pfx_f3 }, /* enqcmds */
+    { { 0xf8, 0xc0 }, { 0, 2 }, F, N, pfx_f2 }, /* urdmsr */
     { { 0xf8 }, { 2, 2 }, F, W, pfx_f2 }, /* enqcmd */
     { { 0xf9 }, { 2, 2 }, F, W }, /* movdiri */
 };
@@ -1516,6 +1518,9 @@ static const struct vex {
     { { 0xde }, 3, T, R, pfx_66, W0, L0 }, /* vsm3rnds2 */
     { { 0xdf }, 3, T, R, pfx_66, WIG, Ln }, /* vaeskeygenassist */
     { { 0xf0 }, 3, T, R, pfx_f2, Wn, L0 }, /* rorx */
+}, vex_map7[] = {
+    { { 0xf8, 0xc0 }, 6, F, N, pfx_f3, W0, L0 }, /* uwrmsr */
+    { { 0xf8, 0xc0 }, 6, F, N, pfx_f2, W0, L0 }, /* urdmsr */
 };
 
 static const struct {
@@ -1525,6 +1530,10 @@ static const struct {
     { vex_0f,   ARRAY_SIZE(vex_0f) },
     { vex_0f38, ARRAY_SIZE(vex_0f38) },
     { vex_0f3a, ARRAY_SIZE(vex_0f3a) },
+    { NULL,     0 }, /* map 4 */
+    { NULL,     0 }, /* map 5 */
+    { NULL,     0 }, /* map 6 */
+    { vex_map7, ARRAY_SIZE(vex_map7) },
 };
 
 static const struct xop {
@@ -2420,7 +2429,8 @@ void predicates_test(void *instr, struct
 
                 if ( vex[x].tbl[t].w == WIG || (vex[x].tbl[t].w & W0) )
                 {
-                    memcpy(ptr, vex[x].tbl[t].opc, vex[x].tbl[t].len);
+                    memcpy(ptr, vex[x].tbl[t].opc,
+                           MIN(vex[x].tbl[t].len, ARRAY_SIZE(vex->tbl->opc)));
 
                     if ( vex[x].tbl[t].l == LIG || (vex[x].tbl[t].l & L0) )
                         do_test(instr, vex[x].tbl[t].len + ((void *)ptr - instr),
@@ -2430,7 +2440,8 @@ void predicates_test(void *instr, struct
                     if ( vex[x].tbl[t].l == LIG || (vex[x].tbl[t].l & L1) )
                     {
                         ptr[-1] |= 4;
-                        memcpy(ptr, vex[x].tbl[t].opc, vex[x].tbl[t].len);
+                        memcpy(ptr, vex[x].tbl[t].opc,
+                               MIN(vex[x].tbl[t].len, ARRAY_SIZE(vex->tbl->opc)));
 
                         do_test(instr, vex[x].tbl[t].len + ((void *)ptr - instr),
                                 vex[x].tbl[t].modrm ? (void *)ptr - instr + 1 : 0,
@@ -2441,7 +2452,8 @@ void predicates_test(void *instr, struct
                 if ( vex[x].tbl[t].w == WIG || (vex[x].tbl[t].w & W1) )
                 {
                     ptr[-1] = 0xf8 | vex[x].tbl[t].pfx;
-                    memcpy(ptr, vex[x].tbl[t].opc, vex[x].tbl[t].len);
+                    memcpy(ptr, vex[x].tbl[t].opc,
+                           MIN(vex[x].tbl[t].len, ARRAY_SIZE(vex->tbl->opc)));
 
                     if ( vex[x].tbl[t].l == LIG || (vex[x].tbl[t].l & L0) )
                         do_test(instr, vex[x].tbl[t].len + ((void *)ptr - instr),
@@ -2451,7 +2463,8 @@ void predicates_test(void *instr, struct
                     if ( vex[x].tbl[t].l == LIG || (vex[x].tbl[t].l & L1) )
                     {
                         ptr[-1] |= 4;
-                        memcpy(ptr, vex[x].tbl[t].opc, vex[x].tbl[t].len);
+                        memcpy(ptr, vex[x].tbl[t].opc,
+                               MIN(vex[x].tbl[t].len, ARRAY_SIZE(vex->tbl->opc)));
 
                         do_test(instr, vex[x].tbl[t].len + ((void *)ptr - instr),
                                 vex[x].tbl[t].modrm ? (void *)ptr - instr + 1 : 0,
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -674,6 +674,7 @@ static int blk(
 
 #ifdef __x86_64__
 static unsigned long gs_base, gs_base_shadow;
+static unsigned long uintr_timer;
 #endif
 
 static int read_segment(
@@ -708,6 +709,15 @@ static int write_segment(
 
     return X86EMUL_OKAY;
 }
+
+static const uint8_t __attribute__((aligned(0x1000))) umsr_bitmap[0x1000] = {
+#define RD(msr) [(msr) >> 3] = 1 << ((msr) & 7)
+#define WR(msr) [0x800 + ((msr) >> 3)] = 1 << ((msr) & 7)
+    RD(MSR_IA32_APERF),
+    WR(MSR_UINTR_TIMER),
+#undef WR
+#undef RD
+};
 #endif
 
 static int read_msr(
@@ -717,10 +727,22 @@ static int read_msr(
 {
     switch ( reg )
     {
+#ifdef __x86_64__
+    case MSR_USER_MSR_CTL:
+        *val = (unsigned long)umsr_bitmap | 1;
+        return X86EMUL_OKAY;
+#endif
+
     case MSR_BARRIER:
         *val = 0;
         return X86EMUL_OKAY;
 
+    case MSR_IA32_APERF:
+#define APERF_LO_VALUE 0xAEAEAEAE
+#define APERF_HI_VALUE 0xEAEAEAEA
+        *val = ((uint64_t)APERF_HI_VALUE << 32) | APERF_LO_VALUE;
+        return X86EMUL_OKAY;
+
     case MSR_EFER:
         *val = ctxt->addr_size > 32 ? EFER_LME | EFER_LMA : 0;
         return X86EMUL_OKAY;
@@ -756,6 +778,12 @@ static int write_msr(
 {
     switch ( reg )
     {
+    case MSR_UINTR_TIMER:
+        if ( ctxt->addr_size < 64 )
+            break;
+        uintr_timer = val;
+        return X86EMUL_OKAY;
+
     case MSR_GS_BASE:
         if ( ctxt->addr_size < 64 || !is_canonical_address(val) )
             break;
@@ -1484,6 +1512,68 @@ int main(int argc, char **argv)
          (gs_base != 0x0000222244446666UL) ||
          (gs_base_shadow != 0x0000111122224444UL) )
         goto fail;
+    printf("okay\n");
+
+    printf("%-40s", "Testing urdmsr %rdx,%rcx...");
+    instr[0] = 0xf2; instr[1] = 0x0f; instr[2] = 0x38; instr[3] = 0xf8; instr[4] = 0xd1;
+    regs.rip = (unsigned long)&instr[0];
+    regs.rdx = MSR_IA32_APERF;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.rip != (unsigned long)&instr[5]) ||
+         (regs.rcx != (((uint64_t)APERF_HI_VALUE << 32) | APERF_LO_VALUE)) )
+        goto fail;
+    printf("okay\n");
+
+    printf("%-40s", "Testing urdmsr $MSR_IA32_APERF,%rdx...");
+    instr[0] = 0xc4; instr[1] = 0xe7; instr[2] = 0x7b; instr[3] = 0xf8; instr[4] = 0xc2;
+    *(uint32_t *)&instr[5] = MSR_IA32_APERF;
+    regs.rip = (unsigned long)&instr[0];
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.rip != (unsigned long)&instr[9]) ||
+         (regs.rdx != (((uint64_t)APERF_HI_VALUE << 32) | APERF_LO_VALUE)) )
+        goto fail;
+    printf("okay\n");
+
+    /* Our write_msr() knows of MSR_UINTR_TIMER. */
+    i = cpu_policy.feat.utmr;
+    cpu_policy.feat.utmr = true;
+
+    printf("%-40s", "Testing uwrmsr %rdi,%rsi...");
+    instr[0] = 0xf3; instr[1] = 0x0f; instr[2] = 0x38; instr[3] = 0xf8; instr[4] = 0xf7;
+    regs.rip = (unsigned long)&instr[0];
+    regs.rsi = MSR_UINTR_TIMER;
+    regs.rdi = 0x0011223344556677UL;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.rip != (unsigned long)&instr[5]) ||
+         (uintr_timer != 0x0011223344556677UL) )
+        goto fail;
+    printf("okay\n");
+
+    printf("%-40s", "Testing uwrmsr %rsi,$MSR_UINTR_TIMER...");
+    instr[0] = 0xc4; instr[1] = 0xe7; instr[2] = 0x7a; instr[3] = 0xf8; instr[4] = 0xc6;
+    *(uint32_t *)&instr[5] = MSR_UINTR_TIMER;
+    regs.rip = (unsigned long)&instr[0];
+    regs.rsi = 0x8877665544332211UL;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_OKAY) ||
+         (regs.rip != (unsigned long)&instr[9]) ||
+         (uintr_timer != 0x8877665544332211UL) )
+        goto fail;
+    printf("okay\n");
+
+    cpu_policy.feat.utmr = i;
+
+    printf("%-40s", "Testing uwrmsr %rsi,$MSR_UARCH_MISC_CTRL...");
+    *(uint32_t *)&instr[5] = MSR_UARCH_MISC_CTRL;
+    regs.rip = (unsigned long)&instr[0];
+    regs.rsi = 0;
+    rc = x86_emulate(&ctxt, &emulops);
+    if ( (rc != X86EMUL_EXCEPTION) ||
+         (regs.rip != (unsigned long)&instr[0]) )
+        goto fail;
 
     emulops.write_msr     = NULL;
 #endif
--- a/tools/tests/x86_emulator/x86-emulate.c
+++ b/tools/tests/x86_emulator/x86-emulate.c
@@ -88,6 +88,7 @@ bool emul_test_init(void)
     cpu_policy.feat.lkgs = true;
     cpu_policy.feat.wrmsrns = true;
     cpu_policy.feat.msrlist = true;
+    cpu_policy.feat.user_msr = true;
     cpu_policy.extd.clzero = true;
 
     if ( cpu_has_xsave )
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -24,6 +24,10 @@
 #define  APIC_BASE_ENABLE                   (_AC(1, ULL) << 11)
 #define  APIC_BASE_ADDR_MASK                _AC(0x000ffffffffff000, ULL)
 
+#define MSR_USER_MSR_CTL                    0x0000001c
+#define  USER_MSR_ENABLE                    (_AC(1, ULL) <<  0)
+#define  USER_MSR_ADDR_MASK                 0xfffffffffffff000ULL
+
 #define MSR_BARRIER                         0x0000002f
 
 #define MSR_TEST_CTRL                       0x00000033
@@ -192,6 +196,8 @@
 #define  MCU_CONTROL_DIS_MCU_LOAD           (_AC(1, ULL) <<  1)
 #define  MCU_CONTROL_EN_SMM_BYPASS          (_AC(1, ULL) <<  2)
 
+#define MSR_UINTR_TIMER                     0x00001b00
+
 #define MSR_UARCH_MISC_CTRL                 0x00001b01
 #define  UARCH_CTRL_DOITM                   (_AC(1, ULL) <<  0)
 
--- a/xen/arch/x86/x86_emulate/decode.c
+++ b/xen/arch/x86/x86_emulate/decode.c
@@ -903,7 +903,7 @@ decode_0f38(struct x86_emulate_state *s,
     {
     case 0x00 ... 0xef:
     case 0xf2 ... 0xf5:
-    case 0xf7 ... 0xf8:
+    case 0xf7:
     case 0xfa ... 0xff:
         s->op_bytes = 0;
         /* fall through */
@@ -948,6 +948,18 @@ decode_0f38(struct x86_emulate_state *s,
     case X86EMUL_OPC_VEX_F2(0, 0xf7): /* shrx */
         break;
 
+    case 0xf8:
+        if ( s->modrm_mod == 3 ) /* u{rd,wr}msr */
+        {
+            s->desc = DstMem | SrcReg | Mov;
+            s->op_bytes = 8;
+            s->simd_size = simd_none;
+        }
+        else /* movdir64b / enqcmd{,s} */
+            s->op_bytes = 0;
+        ctxt->opcode |= MASK_INSR(s->vex.pfx, X86EMUL_OPC_PFX_MASK);
+        break;
+
     default:
         s->op_bytes = 0;
         break;
@@ -1246,6 +1258,16 @@ int x86emul_decode(struct x86_emulate_st
                          */
                         d = twobyte_table[0x38].desc;
                         break;
+
+                    case vex_map7:
+                        opcode |= MASK_INSR(7, X86EMUL_OPC_EXT_MASK);
+                        /*
+                         * No table lookup here for now, as there's only a single
+                         * opcode point (0xf8) populated in map 7.
+                         */
+                        d = DstMem | SrcImm | ModRM | Mov;
+                        s->op_bytes = 8;
+                        break;
                     }
                 }
                 else if ( s->ext < ext_8f08 + ARRAY_SIZE(xop_table) )
@@ -1602,6 +1624,7 @@ int x86emul_decode(struct x86_emulate_st
             s->simd_size = ext8f09_table[b].simd_size;
             break;
 
+        case ext_map7:
         case ext_8f08:
         case ext_8f0a:
             /*
@@ -1816,6 +1839,7 @@ int x86emul_decode(struct x86_emulate_st
 
     case ext_map5:
     case ext_map6:
+    case ext_map7:
     case ext_8f09:
     case ext_8f0a:
         break;
--- a/xen/arch/x86/x86_emulate/private.h
+++ b/xen/arch/x86/x86_emulate/private.h
@@ -189,6 +189,7 @@ enum vex_opcx {
     vex_0f3a,
     evex_map5 = 5,
     evex_map6,
+    vex_map7,
 };
 
 enum vex_pfx {
@@ -245,6 +246,7 @@ struct x86_emulate_state {
         ext_0f3a = vex_0f3a,
         ext_map5 = evex_map5,
         ext_map6 = evex_map6,
+        ext_map7 = vex_map7,
         /*
          * For XOP use values such that the respective instruction field
          * can be used without adjustment.
@@ -601,6 +603,7 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_avx_vnni_int8() (ctxt->cpuid->feat.avx_vnni_int8)
 #define vcpu_has_avx_ne_convert() (ctxt->cpuid->feat.avx_ne_convert)
 #define vcpu_has_avx_vnni_int16() (ctxt->cpuid->feat.avx_vnni_int16)
+#define vcpu_has_user_msr()    (ctxt->cpuid->feat.user_msr)
 
 #define vcpu_must_have(feat) \
     generate_exception_if(!vcpu_has_##feat(), X86_EXC_UD)
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -7038,10 +7038,73 @@ x86_emulate(
         state->simd_size = simd_none;
         break;
 
-    case X86EMUL_OPC_F2(0x0f38, 0xf8): /* enqcmd r,m512 */
-    case X86EMUL_OPC_F3(0x0f38, 0xf8): /* enqcmds r,m512 */
+    case X86EMUL_OPC_F3(0x0f38, 0xf8): /* enqcmds r,m512 / uwrmsr r64,r32 */
+    case X86EMUL_OPC_F2(0x0f38, 0xf8): /* enqcmd r,m512 / urdmsr r32,r64 */
+        if ( ea.type == OP_MEM )
+            goto enqcmd;
+        imm1 = src.val;
+        /* fall through */
+    case X86EMUL_OPC_VEX_F3(7, 0xf8): /* uwrmsr r64,imm32 */
+    case X86EMUL_OPC_VEX_F2(7, 0xf8): /* urdmsr imm32,r64 */
+        generate_exception_if(!mode_64bit() || ea.type != OP_REG, X86_EXC_UD);
+        generate_exception_if(vex.l || vex.w, X86_EXC_UD);
+        generate_exception_if(vex.opcx && ((modrm_reg & 7) || vex.reg != 0xf),
+                              X86_EXC_UD);
+        vcpu_must_have(user_msr);
+        fail_if(!ops->read_msr);
+        if ( ops->read_msr(MSR_USER_MSR_CTL, &msr_val, ctxt) != X86EMUL_OKAY )
+        {
+            x86_emul_reset_event(ctxt);
+            msr_val = 0;
+        }
+        generate_exception_if(!(msr_val & USER_MSR_ENABLE), X86_EXC_UD);
+        generate_exception_if(imm1 & ~0x3fff, X86_EXC_GP, 0);
+
+        /* Check the corresponding bitmap. */
+        ea.mem.off = msr_val & ~0xfff;
+        if ( vex.pfx != vex_f2 )
+            ea.mem.off += 0x800;
+        ea.mem.off += imm1 >> 3;
+        if ( (rc = ops->read(x86_seg_sys, ea.mem.off, &b, 1,
+                             ctxt)) != X86EMUL_OKAY )
+            goto done;
+        generate_exception_if(!(b & (1 << (imm1 & 7))), X86_EXC_GP, 0);
+
+        /* Carry out the actual MSR access. */
+        if ( vex.pfx == vex_f2 )
+        {
+            /* urdmsr */
+            if ( (rc = ops->read_msr(imm1, &msr_val, ctxt)) != X86EMUL_OKAY )
+                goto done;
+            dst.val = msr_val;
+            ASSERT(dst.type == OP_REG);
+            dst.bytes = 8;
+        }
+        else
+        {
+            /* uwrmsr */
+            switch ( imm1 )
+            {
+            case 0x1b00: /* UINTR_TIMER */
+                generate_exception_if(!cp->feat.utmr, X86_EXC_GP, 0);
+                break;
+
+            case 0x1b01: /* UARCH_MISC_CTL */
+                generate_exception_if(!cp->arch_caps.doitm, X86_EXC_GP, 0);
+                break;
+
+            default:
+                generate_exception(X86_EXC_GP, 0);
+            }
+            fail_if(!ops->write_msr);
+            if ( (rc = ops->write_msr(imm1, dst.val, ctxt)) != X86EMUL_OKAY )
+                goto done;
+            dst.type = OP_NONE;
+        }
+        break;
+
+    enqcmd:
         host_and_vcpu_must_have(enqcmd);
-        generate_exception_if(ea.type != OP_MEM, X86_EXC_UD);
         generate_exception_if(vex.pfx != vex_f2 && !mode_ring0(), X86_EXC_GP, 0);
         src.val = truncate_ea(*dst.reg);
         generate_exception_if(!is_aligned(x86_seg_es, src.val, 64, ctxt, ops),
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -349,7 +349,9 @@ XEN_CPUFEATURE(AVX_VNNI_INT8,      15*32
 XEN_CPUFEATURE(AVX_NE_CONVERT,     15*32+ 5) /*A  AVX-NE-CONVERT Instructions */
 XEN_CPUFEATURE(AMX_COMPLEX,        15*32+ 8) /*   AMX Complex Instructions */
 XEN_CPUFEATURE(AVX_VNNI_INT16,     15*32+10) /*A  AVX-VNNI-INT16 Instructions */
+XEN_CPUFEATURE(UTMR,               15*32+13) /*   User Timer */
 XEN_CPUFEATURE(PREFETCHI,          15*32+14) /*A  PREFETCHIT{0,1} Instructions */
+XEN_CPUFEATURE(USER_MSR,           15*32+15) /*   U{RD,WR}MSR Instructions */
 XEN_CPUFEATURE(CET_SSS,            15*32+18) /*   CET Supervisor Shadow Stacks safe to use */
 
 /* Intel-defined CPU features, MSR_ARCH_CAPS 0x10a.eax, word 16 */
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -275,7 +275,7 @@ def crunch_numbers(state):
         # NO_LMSL indicates the absense of Long Mode Segment Limits, which
         # have been dropped in hardware.
         LM: [CX16, PCID, LAHF_LM, PAGE1GB, PKU, NO_LMSL, AMX_TILE, CMPCCXADD,
-             LKGS, MSRLIST],
+             LKGS, MSRLIST, USER_MSR],
 
         # AMD K6-2+ and K6-III processors shipped with 3DNow+, beyond the
         # standard 3DNow in the earlier K6 processors.


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 09:19:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 09:19:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854167.1267435 (Exim 4.92)
	(envelope-from )
	id 1tLIsd-00068s-Gu; Wed, 11 Dec 2024 09:19:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854167.1267435; Wed, 11 Dec 2024 09:19:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLIsd-00068l-EK; Wed, 11 Dec 2024 09:19:39 +0000
Received: by outflank-mailman (input) for mailman id 854167;
 Wed, 11 Dec 2024 09:19:38 +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 1tLIsc-00068d-JV
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 09:19:38 +0000
Received: from mail180-34.suw31.mandrillapp.com
 (mail180-34.suw31.mandrillapp.com [198.2.180.34])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 071b9ec5-b7a1-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 10:19:31 +0100 (CET)
Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail180-34.suw31.mandrillapp.com (Mailchimp) with ESMTP id
 4Y7VRW15QDzS62GfK
 for ; Wed, 11 Dec 2024 09:19:35 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 b80dabdd87a045679bd37280ca1c8e60; Wed, 11 Dec 2024 09:19: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: 071b9ec5-b7a1-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1733908775; x=1734169275;
	bh=pT9B4PdumFBWIdOPG9d3JVLYS0KHd7B2GBDJnzQAJyg=;
	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=fJfeuJRLkj3rgut4I32nRbcyaTZ1+I2kscV7y7cNnM3n9QnEzow53Thm2nr8Le2Gf
	 mcaKrMMZxbgDFRTQI9qX7domkSyFnIz0WIQustGDgzzNnBr13xkYvLsA5RaqDCo9wh
	 dtxRZEZ3rHwGOvHy1pfF85kaUoCcxB473fD+RaGOO7Ity2x9g6cPTTxmimzccTyarp
	 f/eq89k1IgE0ZKrE2SeubB8aAsGPAtFo2PhB6YVwFOkvHGkjfXLbE8yOYMniTDcK5D
	 4id9/y9kKh/+Miqj29D52HP7upS0GobqnSFpqcji2q50JVvDPN4bgBedrCw3l6B8Wd
	 yxULeWOhoPaew==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1733908775; x=1734169275; i=anthony.perard@vates.tech;
	bh=pT9B4PdumFBWIdOPG9d3JVLYS0KHd7B2GBDJnzQAJyg=;
	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=EaoIGdJJ9GeKdMo13VqOvNz3FWR1b8xhEtzE3T6qYxQmPB/NJj1uwSLk3L2gAP/Zi
	 Ukg2eAELiPLqDU8VSdGSR79hQzXLoBd4T8hKw8WdPmtoxhUu7MlrmdIozytPxh98Gw
	 jpNySWZDY59JPthIkOl3PTMZG5st97G0cqU8ENj/0n2QGWMepqPMRF2z26/SeIqYmH
	 qRdxd9BEJ0FIXwT2oXaQwwW/XPHYtyUJXrsZSLUXegHLuoWoueAFPnX2SFEzxWt2oW
	 iecjmKorFF96E5e10Y0J9pe30wb1P6d7SArTcktmgyqvUxw0DJS5imoI+sMNPMULCB
	 SCKqYL/DNtP8Q==
From: "Anthony PERARD" 
Subject: =?utf-8?Q?Re:=20[PATCH]=20MAINTAINERS:=20add=20Anthony,=20Michal,=20Roger=20to=20THE=20REST?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1733908772161
To: "Stefano Stabellini" 
Cc: xen-devel@lists.xenproject.org, kelly.choi@cloud.com, michal.orzel@amd.com, roger.pau@cloud.com, committers@xenproject.org
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.b80dabdd87a045679bd37280ca1c8e60?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20241211:md
Date: Wed, 11 Dec 2024 09:19:35 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 10, 2024 at 03:58:04PM -0800, Stefano Stabellini wrote:
> In recognition of their outstanding work and years of service to the Xen
> Community, please join me in welcoming Anthony, Michal, and Roger as
> Committers and REST Maintainers.
> 
> Signed-off-by: Stefano Stabellini 
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 026aa25a53..34ad49bc39 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -662,8 +662,11 @@ K:=09\b(xsm|XSM)\b
>  
>  THE REST
>  M:=09Andrew Cooper 
> +M:=09Anthony PERARD 
> +M:=09Michal Orzel 
>  M:=09Jan Beulich 
>  M:=09Julien Grall 
> +M:=09Roger Pau Monn=C3=A9 
>  M:=09Stefano Stabellini 
>  L:=09xen-devel@lists.xenproject.org
>  S:=09Supported

Acked-by: Anthony PERARD 

Cheers,

-- 

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 09:33:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 09:33:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854183.1267445 (Exim 4.92)
	(envelope-from )
	id 1tLJ5v-0001y2-M5; Wed, 11 Dec 2024 09:33:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854183.1267445; Wed, 11 Dec 2024 09:33:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLJ5v-0001xv-Iw; Wed, 11 Dec 2024 09:33:23 +0000
Received: by outflank-mailman (input) for mailman id 854183;
 Wed, 11 Dec 2024 09:33: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 1tLJ5u-0001xp-JW
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 09:33:22 +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 f60a6a65-b7a2-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 10:33:21 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-aa662795ca3so95626766b.1
 for ; Wed, 11 Dec 2024 01:33:21 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa68e800a9csm391032466b.34.2024.12.11.01.33.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 01:33:20 -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: f60a6a65-b7a2-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733909601; x=1734514401; 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=BXuBYDt05BnuAXAVqrMEUaGgT7+IQnfbB9u0B2U4mF0=;
        b=YXxD1zQXTUqcpjQk5YhFUzNFzMABL1MsKUgPCYqv7nhMvmClWag1OyM7uepzXM4uzP
         qffUJ6AbOqUenJQbTwfvUv2pqyVy5Bzd+tcb0vRw12QKVaBkoeupXG29fW59RSrTzRIS
         J44seI5kiqUrVQpoWi9bjXuKZF5uv+vzLBL5o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733909601; x=1734514401;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=BXuBYDt05BnuAXAVqrMEUaGgT7+IQnfbB9u0B2U4mF0=;
        b=P29HRVAIneNc5syRruU9cM+QWdQKO7FGNWxvWMocA+tGHzKeGGG17wYiaNx0iWyCau
         yMNtj5OkvmtkgUFFnz3QwXuC0QMMLDyOnCeizDqX05oAmUCutSSb62WDeP3I3dPu1DvX
         V/UD+axuXnOTESLasHXWr4r7aOPPpLSCv4zmOnQN2G4u3YEBQvXGCfkkGaDQ2Utz0nWi
         QpcCGvrLa/Ias7dIVT4T3qX0f0G28+6IdA5kG8hLv5ePVDv4VN9xmN23Q5vJkzr+0lrE
         TN4R1VhN/cg9UTIRS3zJRYqM9seJgvReqLGP5d86pBcTZDDeZdJDMJCqAXm0/+6EB+w/
         EbAQ==
X-Gm-Message-State: AOJu0YwJ/fN6tB0DyJxG1pv0A67RgEEsX2EX2+zf8oa765F7S9gi8rhG
	OL78F7YWBul0/v2lWEbal8oT4tIsPp5KqQAN119EpMvsI3yrYDvmudXM1QX3wxU=
X-Gm-Gg: ASbGncsAxO7aBo8w5XD1IvpIjynwc81beN1WqnZGIye1DNG56IHrgl5Epz7TbUVTdmf
	/5/q/glPKPL0RPV9u9qu7B12TZRCRi+S+izI1JN4yMWz3FpllLV1du4rswRJvNV7bvBIaaxnGCS
	Y3gE8E7v59atfHApWtJx3zHB8pBQuzMBr84e7BHyH5jKnkM1iDfQPPp/DwXXx8dNKM23e7Oi6Ax
	DFOxjz1ztp4v03mQVl4jBbPVO82MtrREU5mWNxL1J/2OyK2umWHkPW/RvjjfxE=
X-Google-Smtp-Source: AGHT+IFg/luXNUqkJFneClsPr/d3INheKFhUcK4J6ws6dqoguOKS59wC7a+EzBdbEMcl/P1iG2hNhw==
X-Received: by 2002:a17:907:96ac:b0:aa6:9c69:f52a with SMTP id a640c23a62f3a-aa6b16a0dd8mr179348866b.19.1733909600836;
        Wed, 11 Dec 2024 01:33:20 -0800 (PST)
Date: Wed, 11 Dec 2024 10:33:19 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stefano Stabellini 
Cc: xen-devel@lists.xenproject.org, kelly.choi@cloud.com,
	anthony.perard@vates.tech, michal.orzel@amd.com,
	roger.pau@cloud.com, committers@xenproject.org
Subject: Re: [PATCH] MAINTAINERS: add Anthony, Michal, Roger to THE REST
Message-ID: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Tue, Dec 10, 2024 at 03:58:04PM -0800, Stefano Stabellini wrote:
> In recognition of their outstanding work and years of service to the Xen
> Community, please join me in welcoming Anthony, Michal, and Roger as
> Committers and REST Maintainers.
> 
> Signed-off-by: Stefano Stabellini 

Acked-by: Roger Pau Monné 

Thanks.


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 09:36:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 09:36:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854196.1267455 (Exim 4.92)
	(envelope-from )
	id 1tLJ8d-0002b8-5G; Wed, 11 Dec 2024 09:36:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854196.1267455; Wed, 11 Dec 2024 09:36:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLJ8d-0002b1-2e; Wed, 11 Dec 2024 09:36:11 +0000
Received: by outflank-mailman (input) for mailman id 854196;
 Wed, 11 Dec 2024 09:36: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 1tLJ8b-0002aX-GM
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 09:36:09 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20618.outbound.protection.outlook.com
 [2a01:111:f403:2417::618])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 57d7988b-b7a3-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 10:36:06 +0100 (CET)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SA1PR12MB7409.namprd12.prod.outlook.com (2603:10b6:806:29c::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.15; Wed, 11 Dec
 2024 09:36:00 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%3]) with mapi id 15.20.8230.010; Wed, 11 Dec 2024
 09:36: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: 57d7988b-b7a3-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ilZ6BLWq/Rzqx9TxHXFImWwoyvl02jWsizADWqopEzRjTitZ5/EvPYFYpA0LinJcfBXHJcAqP7Ne8ngR90lzRwYuxa4Udg3IanXl6CG2K4ZQ39LXVoQanRYKA/Bo2hVj8f6Gim2stcYCrOTAVZFA9TibErxyIwDzoWvwPXZzBTudncknxAJKcrAFjgDhmTqCI9Sat3FQezN39KxzC4X0WIxdnCfFR59DY1xkgxAlWMQDrOo6wb3nGQrqQNeq+8nMUz914H/x4pfh+F6HPVK/NpyYXxVN1pwLrPRN3tKave9sG2M5awBTrNS57mj815MkjIaATLptp6weNInf+eJeVg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=8JiLX/zyj4DDjCmIMZb5KyLG0RQYZl2sZpAhoa/iYos=;
 b=QWcennDchDC4nmAY7j13GS5El7y4roJT8VvsNU5BtFkS2pbW0q4CdjzNnIfgB0UEl0jbRz3Bh0fbYqfgy3jr136hbhCmhqwhGakNU2hABDkpufA20KjoEY84UdPlKWhhyR4SjuC3HVdmoG2Fq07zZuYjpvz0/zQWZB92cbWIgH0yRlWVrrIsQClHxT6rIObiFZxKYFZyGQi1sX3ZE051t5qzqeuUK8cmCycyWvBUj3E/RMXNE2ceAs/PSq6vGThVgfnKnwH5/SPOuIlihCBb1AWgwPd4J9dz4dmGPaggzUhLHgvouZJoY6PNLDMuAxEeBhkA18TkE+yy3KcW2DtmHQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=8JiLX/zyj4DDjCmIMZb5KyLG0RQYZl2sZpAhoa/iYos=;
 b=3fnOKzajRoPRR5kzkt/BAl4BvJqxab2Dili4d/nUSo7NkSy/oM99ozAfDwXY//af7ryAlyPqWaRCNWSpMmRcNptpXarWhfSwPjyiJkJMcHF477oQveCOcTl4RZTiq5MMf6f7GPbZtv9YYpM4RKI2E9Z7yxIb9PLJzXLU7mbLwxI=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: Jan Beulich , Andrew Cooper
	, Julien Grall , Stefano
 Stabellini , "Huang, Ray" ,
	"xen-devel@lists.xenproject.org" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support
Thread-Topic: [PATCH v2 1/1] vpci: Add resizable bar support
Thread-Index:
 AQHbRIDgGHZ3ofHO0UuqqXvn+EZCabLd/CGAgAGXh4D//4qBgIAAiieA//+hwICAABlHgIABx3CA//+WDgAAE2rUAA==
Date: Wed, 11 Dec 2024 09:36:00 +0000
Message-ID:
 
References: <20241202060956.1124162-1-Jiqian.Chen@amd.com>
 <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com>
 
 <1e0576d9-400e-4483-8dd1-061e215a00cd@suse.com>
 
 
 
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8230.010)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|SA1PR12MB7409:EE_
x-ms-office365-filtering-correlation-id: bcf9015b-e512-454f-8a93-08dd19c73969
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?Nkt5QjBiNStTdENOTmZjdG00bXRGa1BjS1dJK1MwelduRllNR1cwRFM5RFFI?=
 =?utf-8?B?TkpWM0kzSzFRWFYzT1BEbXhlWnVIclNyWXN2UWlTTCtZdm54WlpickY0MWZS?=
 =?utf-8?B?TWdCS0I3RVJ5cTZ0SVZxaDJzZ1k4TWJOaHhMdnVCdjhvV0xKM2IzZ1J5dUdX?=
 =?utf-8?B?eFUyKy9LWFUzWDhrR3dtUk8vK3BDN3gxUFFPcndPR0ViZVhKT29wZ1NrZ3k5?=
 =?utf-8?B?V1ZieVNEMk1iVDZyRExvOGlpZ0NZOFYrbXZKRnJRdnNyKzkycW1sSHdxYXRE?=
 =?utf-8?B?ZUEySGRocHZLRklHVklZakI0d1cvaW1rRkIwanFGUTNIU3VQazBMSkdOMFRs?=
 =?utf-8?B?bjFoOS9PSW95ZWk0T09aRElXK0JEZkVUd2pXVzNLakNTZXc5a0dxdDUvaUNP?=
 =?utf-8?B?V0ZsMTYwcE5ZL1ozSnBqTmt3WUZ3V2pGa0tFTWhHQm1FaitHRytWOVNWVFVh?=
 =?utf-8?B?WDFzbGV3SDhkdUYrdnMrRkxydDcxb1ZMTmtSd3MrTGFxL1ZjOS8xeUo1K0Z6?=
 =?utf-8?B?TVk4RHhkV1Z2TzVOalJ4MEZpaFV1c0hKaTlhNEdTcVEzNUJNbW5yYThuSEVC?=
 =?utf-8?B?WEpQcGFwSWk0YXBKbkRvTUhvemJnVnVsaEhZNUNqR0dCRWJOUkFka3lFRzRv?=
 =?utf-8?B?ckIrTCtOWXlPT0pyNDBrRnJmS1pPeEZUYjN1S1lWdWc0a3ZNZ2l5cVUzSDNj?=
 =?utf-8?B?dkVkWEkvdTVYcXp1MWVSYXgxQ3ZKSW5wMWljdGJ6U2w0UEZZWDV0cEFjZFY1?=
 =?utf-8?B?anVQVmdKb2IrWGNJbHc1MGdpUmZPM1B1UnpwLzVnaXJyRlNiN20wdjFjcjZm?=
 =?utf-8?B?RGkwRGpEM2lzdm9sN2h3ZlJWdm1CNG9PV2dWUytKb0JzSDEweWxzeWg4S2I0?=
 =?utf-8?B?cHM3UWJYMDV0L2R0VCt6WWl0VzRnbjhWSkNBRWE0b2xkV21uQlMyY1J2c0Zt?=
 =?utf-8?B?Rys5cVRqSTVvTmtMUFkreGNraWEzd3NLdHpyWFdTWWVNalpLMEVYQ3FFT3BU?=
 =?utf-8?B?MTVmNk00SDJqb2ZyQ0NabGVtekp5L0YwYVRQeEF1Z096SGZEdmdCeEJXLzRj?=
 =?utf-8?B?WFdYT3kxZXY3RFU0Myt0Mzc3dVhDZGFSb3FGSmc4UXVTbDZYdTdWSlp1a0xt?=
 =?utf-8?B?ZFl1WU1iOUE0amdCU2VJMUhZTjBYUEFPT05abTB1eU91OUtPMmw1TmttMHFh?=
 =?utf-8?B?V010R05VUlFFL3JIMnN1UkgzUEJneVdBL1I4QlovVXhGZFlqVDF4Vy9qMjFI?=
 =?utf-8?B?dU05YmRBQUZjejR1WmI5cUpBQURKdVE5R2dSOWhwWm9hNlZ2V0J5Y0FsOWxN?=
 =?utf-8?B?VHFMclFid1ZYN2xzRVkzWG1mQXRjMlBneDFrUUt1Skx2L0VRKzJTbG1IaXV1?=
 =?utf-8?B?RUFEYTlIZTg4VDJvNEllZjNrNHJkdCtTS2VYbXpDOWVZUmhhTllQOGFmWDJU?=
 =?utf-8?B?dzVYbFFsWDlrWkZYMjBEZ0RWd1VLTzBTdjc3YWFxZWJVdWZPVHdCbkhWNXp2?=
 =?utf-8?B?MTlJRHVuVXFUN01lcHRrTldiRkJ4SnZiYll5SHo2VWRDanVXY2FGancxS05C?=
 =?utf-8?B?dnpEYTA5aFpSdjk1b1dHcEFRZnd5MFRnZTJWMFhoOVI4elpJMS9oRmpsVzZJ?=
 =?utf-8?B?aytQcGlFck42dVVoTzdxNlovVTZKQ2RGOWxIdXRBWU50dDdmR21JNXJMUHZZ?=
 =?utf-8?B?VEdwcEY5dlJJTWJ5eVRNM2ZZWFNUYi9mWE00ZGVFRE83MHhDeW1CUlRkZE00?=
 =?utf-8?B?Z0tZcFVJVXduWUpZT2NNOWhFV3lubWxhSmdacWR1WXE0TyszUkVZa0x2cjcv?=
 =?utf-8?B?K1p5b282K1RneHlBa0twYUFPK3ZMRnNNWFFUb1F4NWVtelBKTHk0eTNGblAy?=
 =?utf-8?B?S3UrTTVFQytrWkFiRi9Da201Nm1GcE9yOXZUYWRjOW9YOVE9PQ==?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?OWVLVjg5TjNXaUt5b2ZXN01oclNtZzJEamx3ZVhvaUplUzA0TTdMTEVvKzQ4?=
 =?utf-8?B?WkVzMVdHOFRac0xtSXkwUy83L2RkQ012T1ZiVDVBbnZJbFNwTzhDc3JsQ2JM?=
 =?utf-8?B?cXlHdnVOeW42OTJndGlpWWM1NURGQjBtelFnUDd3QlJJSjBWdVBKVnNtS2or?=
 =?utf-8?B?ODAzK0U5bmt3Um55aDROK2E0WlR1b3FrQVhNeWpTR2Fza01iM2htQU5qejNt?=
 =?utf-8?B?SGxtdytVUWFKYXlEbGNQak52Nk1Kc3NFT0ZLUDZldTlsOGdKY1NhY3VWY1Uw?=
 =?utf-8?B?K1Y0VkJUdjY0aWNWcDRITG1Tc0toSmwvcDVDanhFbDdtQmJrQ2plSEtkNzg4?=
 =?utf-8?B?ajBRQW9Wak1EUnNKeXZzckJDVzQvZnB3S1U3Zy9pbzlJc0pzODNnY0JiVGVi?=
 =?utf-8?B?OHNPbUYyZEVxZzhEZ0xBa1Z2L3lBK2s2dzlDS2p0V05YN3dqVmhjUk1teWFC?=
 =?utf-8?B?U2JhWFR6Z0FQWnZ2eVkwV1hkWHh4bXU1eGo2ek4vMjZsVlo1bmFoaFpBcEFs?=
 =?utf-8?B?Ui81L2dTQThpa09BRHlYRlN3dzNtdTlkbllIN2s5OERObmtJS2ZPSTZKS0xN?=
 =?utf-8?B?MGMwOGszT05MZFV0T0R4djFCMlpvSkx3amplTDkxVnZGdEpkWUdBcU5CaTNV?=
 =?utf-8?B?bVdScG5paUtTTmsxbkR4WlJjNzd5djlyQWpGVjc2cHVDdHdsdlhKNDhFWTZ2?=
 =?utf-8?B?M0RYdzFidXVyM1Z0clJSdFVFV0VpR0RJd1M1R3M3dTc3L2YveXdOY2dvTmEw?=
 =?utf-8?B?a1RuRmx0NjRjUHFocWtBOGN0bTFha3FpcDI1aG1LOXZlMEtxTkY5dEJjNHFO?=
 =?utf-8?B?VnArbC9nY2ZCYVJnUENvbU5zUmZlQWRYUXRRMExPWm85aVBKWGRXSVhLL1Yr?=
 =?utf-8?B?c1RTVXpYalVzaVQ3SGMyYjl5TndGVnl5Y3hOa3JUdW52SnBUbTNTS1Z1NmlV?=
 =?utf-8?B?QXdtbjBPeHYxOHRjTlZwYlpZV3dzcTMrWkU3N0F0YWl4UmQ2UjQ1WCtRQ1Jv?=
 =?utf-8?B?SmpibkdRVW1PazF0akJEMExhSVV6Vk90cXBYMktMdkdIRU5CdGRxdStCWmhR?=
 =?utf-8?B?ZTJjejFzU1pEc3c4YUJicmpqRTI3dkdzRVd6MEpoa3RCd1p0aHE5ZDlLUzlC?=
 =?utf-8?B?Qi9YcGZYeHluMFFYaEVwNkJDNnUwSGJTN012SDcvUTh3NlVtUjBmUXhqMUli?=
 =?utf-8?B?NDZSYUZtODNSU05LTnJuM2puNkloVDJCcmYxdkFRd0d1M2M4RXVDL0pWNDJE?=
 =?utf-8?B?NnI0Rzl3eldZUWJZVFVCQ1pGMmx4eUJtN1VKRElZWG5BdnhWdGRsS3hPeWxk?=
 =?utf-8?B?SVVwUEdJby91MXVSN3Y4dytzcENvVG84RlhlajFnVEw4YVhlTndmSVVrTnQ0?=
 =?utf-8?B?SWlUWDRDU0NMeHNDMzZZVzE1RVc2K3RscXdTZ0J1NnllWU5lVU5aNUtGd1kv?=
 =?utf-8?B?cG9WQVZwcTN4bGh0MUJtQ29ka2FGTVRtN3RyV1MvUUNvK29WUHRIUU5jbHFC?=
 =?utf-8?B?NDAxckFMRGVwRFJwUmEvRVU2RDhaREZJT3BqMlhxbHZ3emgydCt1bWZnd1Fq?=
 =?utf-8?B?UzVmcmNlU0Q5MW9LU1d5SVcvZi9CbXpWcklJQlhnVU15WTdBVS8wbFBkQmJW?=
 =?utf-8?B?Q2N6UDdFYmtkeVBtMEZzdFJSZmFBSlVEMEp6bUNWUEl2cFp5anBmRlVSVVJM?=
 =?utf-8?B?b3paRUUrQThEMFRJU1ptME1GTHNBemtnV1EzclRRKzMxM092cDRTc3lReVBm?=
 =?utf-8?B?ZGhQaTBKNG9GUFVBbUFEQTBHSU5uQUViRFE1U2tldk9QQWtpckVOMTdNaTBB?=
 =?utf-8?B?UkxWOXhiMHUxaVpBVUtSaVdPWW1UbzJ3eFRhdEZrUkY1a0NENzhOaHFuWGph?=
 =?utf-8?B?bWc5Z2gzSHZQRjdidkc3cURQMnZpWDIrdTdROFJ2WHpmcjB5SmRlaWdNcTlD?=
 =?utf-8?B?UVozMkxDQmhwK3pROHZSNWRYMmF3bWlFNlZQQ3NJb3E4SG1mVzduMmNacEsr?=
 =?utf-8?B?d1ppQXRYVEI3aDloaXFNYlNlWUZWQkt2SDNqQ2pMaVY1UXdSMDdxLzJSRThM?=
 =?utf-8?B?YldIdHVQSmpheXpLcVluQzdsSGN2QUZiNGExYnBGZFVNVjBONWQwK0dRcnMx?=
 =?utf-8?Q?AA3U=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <9C1CF23925528248A8760FE4FB6DD408@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bcf9015b-e512-454f-8a93-08dd19c73969
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2024 09:36:00.8384
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bXav9Fzu1Iy0tbqUgXZLH1Olj3WjHrqnfyHAlx2ajcF9/HQLFD7BoLL9mr1F9gb+SSjM0hLtaUsdGdHL+mxwNQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB7409

T24gMjAyNC8xMi8xMSAxNjoxNiwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToNCj4gT24gV2VkLCBE
ZWMgMTEsIDIwMjQgYXQgMDY6Mzc6MzBBTSArMDAwMCwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4g
T24gMjAyNC8xMi8xMCAxOToyNSwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToNCj4+PiBPbiBUdWUs
IERlYyAxMCwgMjAyNCBhdCAxMDo1NDo0M0FNICswMTAwLCBKYW4gQmV1bGljaCB3cm90ZToNCj4+
Pj4gT24gMTAuMTIuMjAyNCAwODo1NywgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4+Pj4gT24gMjAy
NC8xMi8xMCAxNToxNywgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+Pj4gT24gMTAuMTIuMjAyNCAw
ODowNywgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4+Pj4+PiBPbiAyMDI0LzEyLzkgMjE6NTksIEph
biBCZXVsaWNoIHdyb3RlOg0KPj4+Pj4+Pj4gT24gMDIuMTIuMjAyNCAwNzowOSwgSmlxaWFuIENo
ZW4gd3JvdGU6DQo+Pj4+Pj4+Pj4gK3N0YXRpYyB2b2lkIGNmX2NoZWNrIHJlYmFyX2N0cmxfd3Jp
dGUoY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYsDQo+Pj4+Pj4+Pj4gKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IHJlZywNCj4+Pj4+Pj4+PiArICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCB2YWwsDQo+Pj4+Pj4+
Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdm9pZCAqZGF0YSkNCj4+
Pj4+Pj4+PiArew0KPj4+Pj4+Pj4+ICsgICAgdWludDY0X3Qgc2l6ZTsNCj4+Pj4+Pj4+PiArICAg
IHVuc2lnbmVkIGludCBpbmRleDsNCj4+Pj4+Pj4+PiArICAgIHN0cnVjdCB2cGNpX2JhciAqYmFy
cyA9IGRhdGE7DQo+Pj4+Pj4+Pj4gKw0KPj4+Pj4+Pj4+ICsgICAgaWYgKCBwY2lfY29uZl9yZWFk
MTYocGRldi0+c2JkZiwgUENJX0NPTU1BTkQpICYgUENJX0NPTU1BTkRfTUVNT1JZICkNCj4+Pj4+
Pj4+PiArICAgICAgICByZXR1cm47DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gSSBkb24ndCB0aGluayBz
b21ldGhpbmcgbGlrZSB0aGlzIGNhbiBnbyB1bmNvbW1lbnRlZC4gSSBkb24ndCB0aGluayB0aGUN
Cj4+Pj4+Pj4+IHNwZWMgbWFuZGF0ZXMgdG8gZHJvcCB3cml0ZXMgaW4gdGhpcyBzaXR1YXRpb24/
DQo+Pj4+Pj4+IFNwZWMgc2F5czogU29mdHdhcmUgbXVzdCBjbGVhciB0aGUgTWVtb3J5IFNwYWNl
IEVuYWJsZSBiaXQgaW4gdGhlIENvbW1hbmQgcmVnaXN0ZXIgYmVmb3JlIHdyaXRpbmcgdGhlIEJB
UiBTaXplIGZpZWxkLg0KPj4+Pj4+PiBUaGlzIGNoZWNrIGlzIHN1Z2dlc3RlZCBieSBSb2dlciBh
bmQgaXQgcmVhbGx5IGhlbHBzIHRvIHByZXZlbnQgZXJyb25lb3VzIHdyaXRlcyBpbiB0aGlzIGNh
c2UsDQo+Pj4+Pj4+IHN1Y2ggYXMgdGhlIHJlc3VsdCBvZiBkZWJ1Z2dpbmcgd2l0aCBSb2dlciBp
biB0aGUgcHJldmlvdXMgdmVyc2lvbi4NCj4+Pj4+Pj4gSSB3aWxsIGFkZCB0aGUgc3BlYydzIHNl
bnRlbmNlcyBhcyBjb21tZW50cyBoZXJlIGluIG5leHQgdmVyc2lvbi4NCj4+Pj4+Pg0KPj4+Pj4+
IFdoYXQgeW91IHF1b3RlIGZyb20gdGhlIHNwZWMgbWF5IG5vdCBiZSBlbm91Z2ggYXMgYSBjb21t
ZW50IGhlcmUuIFRoZXJlJ3MNCj4+Pj4+PiBubyBkaXJlY3QgaW1wbGljYXRpb24gdGhhdCB0aGUg
d3JpdGUgd291bGQgc2ltcGx5IGJlIGRyb3BwZWQgb24gdGhlIGZsb29yDQo+Pj4+Pj4gaWYgdGhl
IGJpdCBpcyBzdGlsbCBzZXQuIFNvIEkgdGhpbmsgeW91IHdhbnQgdG8gZ28gYSBsaXR0bGUgYmV5
b25kIGp1c3QNCj4+Pj4+PiBxdW90aW5nIGZyb20gdGhlIHNwZWMuDQo+Pj4+PiBIb3cgYWJvdXQg
cXVvdGluZyBSb2dlcidzIHByZXZpb3VzIHdvcmRzOiAiIFRoZSBtZW1vcnkgZGVjb2RpbmcgbXVz
dCBiZSBkaXNhYmxlZCBiZWZvcmUgd3JpdGluZyB0aGUgQkFSIHNpemUgZmllbGQuDQo+Pj4+PiBP
dGhlcndpc2UgY2hhbmdpbmcgdGhlIEJBUiBzaXplIHdpbGwgbGVhZCB0byB0aGUgYWN0aXZlIHAy
bSBtYXBwaW5ncyBnZXR0aW5nIG91dCBvZiBzeW5jIHcuci50LiB0aGUgbmV3IEJBUiBzaXplLiIg
Pw0KPj4+Pg0KPj4+PiBUaGF0J2xsIGJlIGJldHRlciwgYnV0IGltbyBzdGlsbCBub3QgZW5vdWdo
IHRvIGV4cGxhaW4gdGhlIG91dHJpZ2h0IGlnbm9yaW5nDQo+Pj4+IG9mIHRoZSB3cml0ZS4NCj4+
Pg0KPj4+IEkgdGhpbmsgd2UgbWlnaHQgd2FudCB0byBkbyBzb21ldGhpbmcgYWxvbmcgdGhlIGxp
bmVzIG9mOg0KPj4+DQo+Pj4gdWludDY0X3Qgc2l6ZSA9IFBDSV9SRUJBUl9DVFJMX1NJWkUodmFs
KTsNCj4+PiBzdHJ1Y3QgdnBjaV9iYXIgKmJhciA9IGRhdGE7DQo+Pj4NCj4+PiBpZiAoIGJhci0+
ZW5hYmxlZCApDQo+Pj4gew0KPj4+ICAgICBpZiAoIHNpemUgPT0gYmFyLT5zaXplICkNCj4+PiAg
ICAgICAgIHJldHVybjsNCj4+Pg0KPj4+ICAgICAvKg0KPj4+ICAgICAgKiBSZWZ1c2UgdG8gcmVz
aXplIGEgQkFSIHdoaWxlIG1lbW9yeSBkZWNvZGluZyBpcyBlbmFibGVkLCBhcw0KPj4+ICAgICAg
KiBvdGhlcndpc2UgdGhlIHNpemUgb2YgdGhlIG1hcHBlZCByZWdpb24gaW4gdGhlIHAybSB3b3Vs
ZCBiZWNvbWUNCj4+PiAgICAgICogc3RhbGUgd2l0aCB0aGUgbmV3bHkgc2V0IEJBUiBzaXplLCBh
bmQgdGhlIHBvc2l0aW9uIG9mIHRoZSBCQVINCj4+PiAgICAgICogd291bGQgYmUgcmVzZXQgdG8g
dW5kZWZpbmVkLiAgTm90ZSB0aGUgUENJZSBzcGVjaWZpY2F0aW9uIGFsc28NCj4+PiAgICAgICog
Zm9yYmlkcyByZXNpemluZyBhIEJBUiB3aXRoIG1lbW9yeSBkZWNvZGluZyBlbmFibGVkLg0KPj4+
ICAgICAgKi8NCj4+PiAgICAgZ3ByaW50ayhYRU5MT0dfRVJSLA0KPj4+ICAgICAgICAgICAgICIl
cHA6IHJlZnVzZSB0byByZXNpemUgQkFSIHdpdGggbWVtb3J5IGRlY29kaW5nIGVuYWJsZWRcbiIs
DQo+Pj4gCSAgICAmcGNpLT5zYmRmKTsNCj4+PiAgICAgcmV0dXJuOw0KPj4+IH0NCj4+IFRoYW5r
IHlvdSB2ZXJ5IG11Y2ghDQo+Pg0KPj4+DQo+Pj4gTm90ZSB0aGlzIHJlcXVpcmVzIHRoYXQgdGhl
IGRhdGEgcGFyYW1ldGVyIHBvaW50cyB0byB0aGUgQkFSIHRoYXQNCj4+PiBtYXRjaGVzIHRoZSBS
ZUJBUiBjb250cm9sIHJlZ2lzdGVyLCB0aGlzIG5lZWRzIGFkanVzdGluZyBpbg0KPj4+IGluaXRf
cmViYXIoKS4NCj4+IEkgdGhpbmsgSSBjYW4ga2VlcCBjdXJyZW50IGltcGxlbWVudGF0aW9uIG9m
IGluaXRfcmViYXIoKSBhbmQgdXNlIGJhcnNbaW5kZXhdIHRvIGdldCB0aGUgY29ycmVzcG9uZGlu
ZyBCQVIuDQo+IA0KPiBJTU8gaXQgd291bGQgYmUgYmVzdCBpZiB5b3UgY2FuIHBhc3MgdGhlIGNv
cnJlc3BvbmRpbmcgYmFyIHN0cnVjdCBpbnRvDQo+IHRoZSBoYW5kbGVyIGRpcmVjdGx5LCBhcyB0
aGF0IHdpbGwgYXZvaWQgaGF2aW5nIHRvIGRvIGEgUENJIHJlYWQganVzdA0KPiB0byBnZXQgdGhl
IEJBUiBpbmRleCBmcm9tIFBDSV9SRUJBUl9DVFJMLiAgSXQgc2hvdWxkIGFsc28gYXZvaWQgdGhl
DQo+IG5lZWQgZm9yIHRoZSBpbmRleCBhbmQgQkFSIHR5cGUgY2hlY2tzIGluIHJlYmFyX2N0cmxf
d3JpdGUoKS4NCk9LLCBpZiBzbywgdGhlbiBJIG5lZWQgdG8gbW92ZSB0aGUgbG9naWMgb2YgZ2V0
dGluZyBpbmRleCBmcm9tIFBDSV9SRUJBUl9DVFJMIHJlZ2lzdGVyIGFuZCBjaGVja2luZyB0aGUg
QkFSIHR5cGUgaW50byBpbml0X3JlYmFyKCksIHJpZ2h0Pw0KDQo+IA0KPiBUaGFua3MsIFJvZ2Vy
Lg0KDQotLSANCkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 09:42:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 09:42:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854209.1267466 (Exim 4.92)
	(envelope-from )
	id 1tLJEk-0004pF-Qf; Wed, 11 Dec 2024 09:42:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854209.1267466; Wed, 11 Dec 2024 09:42: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 1tLJEk-0004p8-O3; Wed, 11 Dec 2024 09:42:30 +0000
Received: by outflank-mailman (input) for mailman id 854209;
 Wed, 11 Dec 2024 09:42: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 1tLJEk-0004p2-3j
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 09:42:30 +0000
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com
 [2a00:1450:4864:20::42c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3c66c2dc-b7a4-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 10:42:29 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-385e2880606so5261402f8f.3
 for ; Wed, 11 Dec 2024 01:42: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
 d9443c01a7336-21650ccdc7esm47310585ad.133.2024.12.11.01.42.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 01:42: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: 3c66c2dc-b7a4-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733910148; x=1734514948; 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=LxfsH0IvaZ6DORJtKTr8c1gGWyqnf4G8nOzb2qvXqbo=;
        b=cgXFZJ0rO4fncbEUvq2gDMNlEg8eKG4+ppmo2dSt2XvKw4W3mthpuZ8hl/bmekuETw
         SP6y79NWrITgK/fa8FpKnCnzo6ZZ8HomZvs6R4Gpq+OQhtFLuZdUQsuBmKWFnpVlPp3S
         GzW4+o/fJXP1h/pTfcbs5E78uEvFR2RJUIvGIf2s6WvllhUMUhcZ7LXCXIAuiP+MtMgE
         uJ8HII67HJXX1lLwf2rYhdKUsZr5gb5HdO20frvBdZuSC28tuxk0vfEW1RWCBl4zp0YE
         bExpjHduViLoYc6rY7A68vd1stUXwCkh060D0NBBPZdQk0cAfz1P3H0okBHwH5Nog5It
         onlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733910148; x=1734514948;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:cc
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=LxfsH0IvaZ6DORJtKTr8c1gGWyqnf4G8nOzb2qvXqbo=;
        b=xPjFZ5Dp5BR1DuvNFfA9qmDfqev1V1X0UZCD+QEI/HkoI4EO9o2Msf00KqOrJojAPF
         cEIw9NiEKulyuJbFDYwfllIvVmd4x7OaEYaaqNXcSwOeHBnTVAe1rHSeCVeiFriGfVby
         ireHH9zxbG+usn/8JRmamEon0i09ytYqrp5stSgl8pb8srbgJ9jYnSBLCOtZQeX/TM3R
         q/UyYeeTBigeDIW+hDqySdpQC/dgUHyOq5M9Sq8rl3cJTDqbP+c275kp4ZgciHhbBA/2
         Bo6C8OMZOYi+9Lh3nxuAKuQuiw97IlybgFhZlIGB7DD1mVoO1Cw3B5K8US8nSQT7byvT
         ZhDg==
X-Gm-Message-State: AOJu0Ywe0D5qY3uuh0FJBv/8ZEjBPjURUAg4hQYziwojCY1vCykdPv2R
	aiFrlmAnfyH8XlUAQuZkCbez1Xk6av3jdZGTn/LdN0a8deDcdNpVRCdHCNxygiWUsbFEmEdgN+8
	=
X-Gm-Gg: ASbGnctaXYB6mpHfpUTxbjink+8iyEJ7BlwLahuDPVv6Ja838DRUEkiSXGSJos9Xc0B
	yIVxB4DLq7AmQy8MCUgEuxBFzblKcmD9y8X+TUdd2SbffdeuQ99rcYhCsFVxdR65+gBD79hhLb/
	0u1ZTJzDFg/onBp6o1EsqLfyMavTnSvri9+gL79JTS4lc/CtaSpR++gyQT5hzyi6A0dteQqcVZm
	LTDGlJm4nv3vrCa3Hg/+YnSi8low8c+1dw+/0R3FbCRonRcLA4TU6Tflg4pWJjLJsk5dgYA2ru0
	nhnefu6sBR/mM0grjsxSW2m7mQdKDa6AZZ/uFGo=
X-Google-Smtp-Source: AGHT+IF2Bab2kHi3b3WcHH/j4ZuggAGFrG5FDmLjqeDhVuPwUUjj9RZEGfR8U2RCLzzJlgOXki47Fg==
X-Received: by 2002:a05:6000:1882:b0:385:eb17:cd18 with SMTP id ffacd0b85a97d-3864cec7423mr1884699f8f.45.1733910148341;
        Wed, 11 Dec 2024 01:42:28 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 10:42:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] x86: Add Intel architectural LBR featureset bits
To: ngoc-tu.dinh@vates.tech
References: <20241118084914.22268-1-ngoc-tu.dinh@vates.tech>
 <20241118084914.22268-2-ngoc-tu.dinh@vates.tech>
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: <20241118084914.22268-2-ngoc-tu.dinh@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.11.2024 09:49, ngoc-tu.dinh@vates.tech wrote:
> --- a/tools/libs/guest/xg_cpuid_x86.c
> +++ b/tools/libs/guest/xg_cpuid_x86.c
> @@ -656,7 +656,7 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore,
>              p->policy.feat.mpx = test_bit(X86_FEATURE_MPX, host_featureset);
>          }
>  
> -        p->policy.basic.max_leaf = min(p->policy.basic.max_leaf, 0xdu);
> +        p->policy.basic.max_leaf = min(p->policy.basic.max_leaf, 0x1cu);
>          p->policy.feat.max_subleaf = 0;
>          p->policy.extd.max_leaf = min(p->policy.extd.max_leaf, 0x8000001c);
>      }

When I saw this change I took note of there being an omission in the AVX10
series I'm carrying. Yet now that I wanted to make the adjustment there, I
found that this code needs leaving alone (also in your case). Please see
the comment at the top of the enclosing if().

Jan



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 09:44:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 09:44:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854218.1267476 (Exim 4.92)
	(envelope-from )
	id 1tLJGo-0005Ru-7Q; Wed, 11 Dec 2024 09:44:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854218.1267476; Wed, 11 Dec 2024 09:44: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 1tLJGo-0005Rn-3f; Wed, 11 Dec 2024 09:44:38 +0000
Received: by outflank-mailman (input) for mailman id 854218;
 Wed, 11 Dec 2024 09:44: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 1tLJGn-0005Rh-79
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 09:44:37 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20605.outbound.protection.outlook.com
 [2a01:111:f403:2416::605])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 877dd6c8-b7a4-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 10:44:36 +0100 (CET)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SA1PR12MB9247.namprd12.prod.outlook.com (2603:10b6:806:3af::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.16; Wed, 11 Dec
 2024 09:44:31 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%3]) with mapi id 15.20.8230.010; Wed, 11 Dec 2024
 09:44: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: 877dd6c8-b7a4-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=n8XiTdAtYyAKPuipMt4HGbCZ2PKPo92s/2EwtUFDCumDLMgYVCnaATR6P22ETBwXFPfH9yos6nL6+gK0mMjqxgGUVO2TG1Q/MnbT/4zU4CntRp2m22uC3gwt2keg80/wL/EPl0tJTeNN9904fPOw8a5fCSgUD0mf5qbuNA5BMgWMGvV3nqtrr2h17zCh6w0I9AHrvkIJNPbFCBUc3ewXh4Wu+sTOjzCige+Lcd4b13fVx6dFN01xRrklj5bUTT8ZsfVODjsKt9Aw9EqmxQ8H9+nWVCdOtRRNBnGU64AAUmbxfGBeDc/T9xJzV9S48xS0IDA+ZY4qHmeh4zj7C8M1pg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=P7x0wzU8pbPNe3Kl4q9awbFtWXBJVc4ESh/0VCrA5QA=;
 b=FCIXdF9TJ0flKte2yCH8WCVXXBZgr510vwWqlvY0vzAWXMSKWq93wF0WwQi2PgYey8UY8F8X8Y4WrViB1XOcIRBvIffoXpEj58kf8VIatmOw9yA3Vj++FnWijuDCtCfxP0ljLR/rjc31q+xG0cS4E+UMWjvxDbZbtOXY2lSVYuKNwk6igD6/GdKvzCkP4kKbWUfkM0tV4kVIHPtuI5HG0oP3NntGcpO1O9uA1y4nqmrKLL35HmwqVwVFO6AczlRV7oFcT2SD3u3oezGWf0Pm09tVbQefgJNGTYvAyme3NE6YlVS+ULxbR2BMZRyVeBuf2IE2ZXoGgCt1npQy3Gn1Ug==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=P7x0wzU8pbPNe3Kl4q9awbFtWXBJVc4ESh/0VCrA5QA=;
 b=2Ws/td/9UJJ+ZNLKXxjr3CDNXveT3b8eNgQzzJDuSEJH4kX/j43aPmsWOL/pcFsCThbXF5BpJJxJVmhcJcDqjx+f+mhlQH/Pwgz+T2zlCOGXTc+MGrTev9Br4fjrrlZh0vzrNorr4VYRiVEkONA0+ZAsrEUdvBuZhMouQgzbHGM=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: Jan Beulich , Andrew Cooper
	, Julien Grall , Stefano
 Stabellini , "Huang, Ray" ,
	"xen-devel@lists.xenproject.org" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support
Thread-Topic: [PATCH v2 1/1] vpci: Add resizable bar support
Thread-Index:
 AQHbRIDgGHZ3ofHO0UuqqXvn+EZCabLd/CGAgAGXh4D//4qBgIAAiieA//+hwICAABlHgIAB3TaA//+HM4AAEuLWgA==
Date: Wed, 11 Dec 2024 09:44:25 +0000
Message-ID:
 
References: <20241202060956.1124162-1-Jiqian.Chen@amd.com>
 <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com>
 
 <1e0576d9-400e-4483-8dd1-061e215a00cd@suse.com>
 
 
 
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8230.010)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|SA1PR12MB9247:EE_
x-ms-office365-filtering-correlation-id: 272af18f-3c94-419c-2a32-08dd19c8667c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?Uy8yV0p3SWJXcnNycW5QaDVaQ2E4bUlNaDRETkhxOXB6S3M1YVlIT0VwYkFC?=
 =?utf-8?B?Vkw1bVFOV0hTQWgvMTA1emV5azYxR1I2aEx6K0lFalF6dkhjaERHamg4dHR2?=
 =?utf-8?B?dURLYkV3S2pJbFNXV0U4K3h4SjdGMTZxcGR5SFZScjl4T3JQWmZZMFdSUXJT?=
 =?utf-8?B?d1l0MWMxRXhvdlIrcStsMjUrRW9WUDBMamVhOWVhV1F1Wjc1Ti91NHZncFhs?=
 =?utf-8?B?ajFNVnJUVXpXdUZ2enlWeTlXaEx3RW5LM1pRU1lOL2tFL3l0b0Uza1RRY0xT?=
 =?utf-8?B?d203SUxVakgrbENmR043ODNQeUYyOUR2UXZvSURLKytMVElJRnBZS2RTTktD?=
 =?utf-8?B?eXBDakZvMHQ3eXFrM0Q3RXdDNEZUVXkxM2FldDJZS3hEUnZxa3dnb3hjMzBD?=
 =?utf-8?B?dzIwQVp6RGFVamxDSFhVV0VLbktDYTRYOXI4ZlZVUVFhRlB5TjA2b3MraFc2?=
 =?utf-8?B?VUpGYzRxd3NjbVozOVRRQURwdDhvcTd6UG5Gc2RKU2J1MEFLMXlldnR5a29n?=
 =?utf-8?B?N2tuL0JhZ1RkQ3Zzc0QxQ1NiQUlPdWhtTXYwR2N4VmNlSTh2STBMdERqOE1y?=
 =?utf-8?B?Y1FUTWptaXcwTWM0YXl6dEg4bCtldXN3U25hRGRJS3BWUU9TR1plS2lydmkv?=
 =?utf-8?B?eUlHOWdkdTh1Mk1oMkhJQVhKRkhGcHpnd3p4UGNvZnhnTDRtSkd0WVd1RzZ5?=
 =?utf-8?B?MWZWZEFVYU5UT0dsK3Bia1A2WnlaVEhHR1FPYnlqM01ZS2JsL2c2c2crWlRE?=
 =?utf-8?B?bWo1djRCcnJSZmNwRGxIWEUxZmltNEJWTGVvaDkvbUhzajhzbENLRXVVVlk3?=
 =?utf-8?B?QTdzVDlmSXhPVHdTV2taclg2ZXA2MVl5am0zeExMREI0WStIM2czNSs0WW1z?=
 =?utf-8?B?THNGbEVCV1RIZThlY0dkME5waFM3b3J0a3FtUWhMM0JMMnNkRGxmZEpiRWlG?=
 =?utf-8?B?R0k1NWc2YWhpUDFNaHhvd3EzVW5WbW9JTCtWazVhMGNpd1JoVmdjVXpNZDlK?=
 =?utf-8?B?RitENXZpaHRtWVVRMDN2eTIrRDcrbGY0dEZEb29SaU9Qc3VFZXpQekpXeHdY?=
 =?utf-8?B?ZDNnaUNvSk9sL1BmSUF0a050bFR2bXZtdnFPcXY0cmZkT2NkRFEydWUwSk1a?=
 =?utf-8?B?cEd1WEtUVWtOS2hDcjJLdk43ZGVxWGhJQjV4RXp4R1l0bUU2L2JTZmNNVG4x?=
 =?utf-8?B?aUxkbmszcDRXMDExQXB3MUloN3FtczB4WCtCMUMwT0ViL3NzMWhpb0tKNVpD?=
 =?utf-8?B?dVRTV1kxbjJtd1JBYXZMcjQ0SVBCK0prT0F1NU9GQ2JGMEJsYytSa0NHZXha?=
 =?utf-8?B?NklOYUVlcnVIK2hzbG9yazVpcGZQMmEyZnc0U0U0VUd6U0RyeEpTekNPMEE3?=
 =?utf-8?B?NmJySkppV1FrZC9XZmNMd05qOFI3NThEcEIyNllTamlOV1dXMVZ6OXYrTFUz?=
 =?utf-8?B?WDhWK0YwYkl2NzJNbzRJN0VBUzBYMHYvVVY5WUN4V0FXR2IzR0llV3RiOUh2?=
 =?utf-8?B?VzFnbDluSW5aY0dTMzgwNEFQRDJQOHBZeVczbGcyTFdrZHIxL0ZraWFLVjRi?=
 =?utf-8?B?Q2lCNi83R2lod2VtT0pad0NrbVV1cy9MWjk4THhxQ08xeEVzcVBFRXdUYkFn?=
 =?utf-8?B?SUtFTG90a1RDM3BKYXNFOVJFTGhtN1RIM3VKYS9TbjFFcGt1Z0lCT0paNWc5?=
 =?utf-8?B?M2tCbjd6bHZKbHladEthazUxU01HL01rU2lseGhkUWFvVTZaZHhFVGx2YVBZ?=
 =?utf-8?B?UmdKb2w3TXQwZVhFTGk4N3J4aEtKbm5FeWhJZ0VMTkpWU2JLaXgrdUhpZi9u?=
 =?utf-8?B?MXVxMmJ3VTNFcW5ISGFRVjB4SjB4OFlqOTRoNkJqRm9PbTRDbFdUTzYxcWZS?=
 =?utf-8?B?MHdoZjQ4OFJsZzVYd0YvbnltczQ4d0tiOCt6dTFqcWZyVkE9PQ==?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?WklCNWE1L3JyaXIwcGFaRDBwdmVMdW9CTkRyck1kRGJwbEJtLzZ1WXkwUTZ6?=
 =?utf-8?B?TlV2Y25WaXY4dmxnN082L1dETFJmbXRyUVV1Y1VlUVdPOVJOYVlwN2pFVGVh?=
 =?utf-8?B?a0d2bmxtVi9BcFU3ajRWQlFGcWVxdWNKQ3BETzNQdXdsT3NpRWNYY1JyR2N1?=
 =?utf-8?B?SGVNTjdWSUEvLzdxTDhTRWppSW40cHNMODBURE5sMUMwK09NczJFMXBKQmQx?=
 =?utf-8?B?RGRBQ1dGdndvY3VOT2RrOHNNRXU2blUzNVhoRWJaQm5mZVpPYXRYYnJMNngx?=
 =?utf-8?B?TlBDU0M0QjRtdG5jS0l3NGpOVlA4MmNvR1k1M3lrS3p5Skg0eFNsUWVFQUZq?=
 =?utf-8?B?dUdnUy9YeEhUeWFDVk5oMURzOHR6NDd0T0s4TWIvNGVrUVpGZWt0eDF2eDFC?=
 =?utf-8?B?QS9SWUZGdk5odnRTS3cwamZQNFA0aXQ2Q09YcFE1V1NaeEVDdXllY0p6RFpi?=
 =?utf-8?B?dTJUOVFoNVZ3TmlxMkg4TkZzbzU5TEREYUw4aGhmaXV6L1RWQUR0OWpLZ0xF?=
 =?utf-8?B?YUgvN2Q5VS9JTHBIQ3RTWEdVbUlhelN0akl3YUpsWnBTVWI0ckYwN0FHYVI4?=
 =?utf-8?B?QjlXWEIvWEFiY3E3cGZmRE1TYkNIVmFrTFBUcWhFZTNnVWEzQ045Z3ZoOCtz?=
 =?utf-8?B?Z1BiaTRCSm9SbjN0RHBmTXFOTWNtYUtEZ3piOUlDTW1CRS9xeit1MXRPNVlF?=
 =?utf-8?B?Y1FTSjB0bHNCUkhYM0JxWC9Zc1dVcGRKaTIvNEp0Wnk3Q0RpeFNjWGhtK0FD?=
 =?utf-8?B?ZHNRbjRrYk1QMnlrNU1JQ2trS2w2YUxoMlBIa2FHb01QaFQ0Zm9uRjQ2TTVU?=
 =?utf-8?B?dS9NeW1CbnJyTzBqS3FGejljOXhXaisyWjVwMGI5OWd2d1VsOGZPaEc4SS9v?=
 =?utf-8?B?L1JDeWFsL0R1NG1HOVM4OFdxUUs4cXNKTDBzQXVreHpXWXd1VmFsRVh1V2d1?=
 =?utf-8?B?eVhHenNxOVA2dUdtaVhVUUxOdVFkbi9iQ01IVjhLdUpycWVjMmh2U3JMemMv?=
 =?utf-8?B?V01uVnpQTm5DMk9XZ3dMYTd6VzZDTXhUTXhHcmRxOW8xWE9YMUowaGt4QmFH?=
 =?utf-8?B?VFk2NnphOUFaaWNHaS83dEVCcUJ2NlhkRExyTER2eXIwdXo3U2hhdFRhcUNu?=
 =?utf-8?B?TXhPai8xQnNmTGhRVkRXZUFuanVoWVV0N09pZHF4QTVOanp3emNFVCtQZk0y?=
 =?utf-8?B?d0h0WkwvVWpndW9ZM2szVkllRUk1bDhUaHFiUDBXalRmZ0VzVGtUc1cvOWw2?=
 =?utf-8?B?ZkJYbkpDQzJTZUpHK2FERk4rUWJnYnYyRENYaHF5MjZ5MktVNW9QbGhHc3dE?=
 =?utf-8?B?TElBbkVyK3JOZzViKzhPOEJKOU1RVEpqbjBRVndhbld1UHp3TVJlVk55cXEy?=
 =?utf-8?B?M0dwZ3E4TGhPakhFdzIzQlZUUStqTzZZOStCVEpLdVhBcGxiby9IRmFmcXBN?=
 =?utf-8?B?YnZvRVFBSUlhdDNGL3c3NVZZempzWVdCU0VkVG5ua3B3UnJUL05nTm5DVC8y?=
 =?utf-8?B?WGdSYWtHVUttUm43aG1pdXFzVzd6RnJSSEJPOVlIV09lWTFlU1ZOU1N3c0c5?=
 =?utf-8?B?azF5QUptWXQzWm9aU1RyV1lHek1ZTlEwdTdKMUpMNDdjOW1Jc0szSlE1QjR3?=
 =?utf-8?B?VVcxZC9PM3FiVlZsWGFXY01PeXNKREpib0dEQmM2cCsyZ2N6aHVUUldhcUhU?=
 =?utf-8?B?Z2ozT3MxYmZQendtWVFXNzd4eUo4UUlEZjkyQXdJVEtmcEhqRUthSUpHL09m?=
 =?utf-8?B?Vi9waytnRFp2QXdVZ0prNGQyZExqV3JUczJVcXhnVGhPZ3FKeFQ1QUhsa2pV?=
 =?utf-8?B?SzNjaU5JeGFRVHZ6eExta1RxeWtpZ2RsMnlxeEhZZXFHb2JTZllWdG0rR3JI?=
 =?utf-8?B?VlN5NHVXNURtV0F1S0s5ekRwQzhIL0NUcWFaR1Z2aHdQVFduMkRaTFFQWFZn?=
 =?utf-8?B?N1kwOUxTc0U1bGl3Qm1NSkJ6SjNESzhHcGVkVXJTU1ViNjhFcGFxSTdyU1px?=
 =?utf-8?B?dDM4UmpLeW5YNkdNSHFid01zNXNTYzZzMHd5aVlDVUtpeGlKelFnT0w2WkRY?=
 =?utf-8?B?aklaeHZadVR6anIzV0dMZDlrWGk0WFd0cGxFT0lySnpWVUpTSGFMQjQxQ0py?=
 =?utf-8?Q?ZpM0=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 272af18f-3c94-419c-2a32-08dd19c8667c
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2024 09:44:25.9911
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: nAr34QUkemz/fb43LwOvyVuTGuwFHfIwV5fYOH9G5FTSRVBpadPTUVxm7k5cgxKWwS08Tj+IZvBfD4Lcq4aLIA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB9247

T24gMjAyNC8xMi8xMSAxNjo0MCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToNCj4gT24gV2VkLCBE
ZWMgMTEsIDIwMjQgYXQgMDc6NTc6MjlBTSArMDAwMCwgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4g
T24gMjAyNC8xMi8xMCAxOToyNSwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToNCj4+PiBPbiBUdWUs
IERlYyAxMCwgMjAyNCBhdCAxMDo1NDo0M0FNICswMTAwLCBKYW4gQmV1bGljaCB3cm90ZToNCj4+
Pj4gT24gMTAuMTIuMjAyNCAwODo1NywgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4+Pj4gT24gMjAy
NC8xMi8xMCAxNToxNywgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4+Pj4gT24gMTAuMTIuMjAyNCAw
ODowNywgQ2hlbiwgSmlxaWFuIHdyb3RlOg0KPj4+Pj4+PiBPbiAyMDI0LzEyLzkgMjE6NTksIEph
biBCZXVsaWNoIHdyb3RlOg0KPj4+Pj4+Pj4gT24gMDIuMTIuMjAyNCAwNzowOSwgSmlxaWFuIENo
ZW4gd3JvdGU6DQo+Pj4+Pj4+Pj4gKyAgICAgICAgaWYgKCByYyApDQo+Pj4+Pj4+Pj4gKyAgICAg
ICAgew0KPj4+Pj4+Pj4+ICsgICAgICAgICAgICBwcmludGsoIiVwcDogYWRkIHJlZ2lzdGVyIGZv
ciBQQ0lfUkVCQVJfQ0FQIGZhaWxlZCAocmM9JWQpXG4iLA0KPj4+Pj4+Pj4+ICsgICAgICAgICAg
ICAgICAgICAgJnBkZXYtPnNiZGYsIHJjKTsNCj4+Pj4+Pj4+PiArICAgICAgICAgICAgYnJlYWs7
DQo+Pj4+Pj4+Pj4gKyAgICAgICAgfQ0KPj4+Pj4+Pj4+ICsNCj4+Pj4+Pj4+PiArICAgICAgICBy
YyA9IHZwY2lfYWRkX3JlZ2lzdGVyKHBkZXYtPnZwY2ksIHZwY2lfaHdfcmVhZDMyLCByZWJhcl9j
dHJsX3dyaXRlLA0KPj4+Pj4+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVi
YXJfb2Zmc2V0ICsgUENJX1JFQkFSX0NUUkwsIDQsDQo+Pj4+Pj4+Pj4gKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBwZGV2LT52cGNpLT5oZWFkZXIuYmFycyk7DQo+Pj4+Pj4+Pj4gKyAg
ICAgICAgaWYgKCByYyApDQo+Pj4+Pj4+Pj4gKyAgICAgICAgew0KPj4+Pj4+Pj4+ICsgICAgICAg
ICAgICBwcmludGsoIiVwcDogYWRkIHJlZ2lzdGVyIGZvciBQQ0lfUkVCQVJfQ1RSTCBmYWlsZWQg
JWRcbiIsDQo+Pj4+Pj4+Pj4gKyAgICAgICAgICAgICAgICAgICAmcGRldi0+c2JkZiwgcmMpOw0K
Pj4+Pj4+Pj4+ICsgICAgICAgICAgICBicmVhazsNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBJcyBpdCBj
b3JyZWN0IHRvIGtlZXAgdGhlIG90aGVyIGhhbmRsZXIgaW5zdGFsbGVkPyBBZnRlciBhbGwgLi4u
DQo+Pj4+Pj4+IFdpbGwgY2hhbmdlIHRvICJyZXR1cm4gcmM7IiBoZXJlIGFuZCBhYm92ZSBpbiBu
ZXh0IHZlcnNpb24uDQo+Pj4+Pj4NCj4+Pj4+PiBJJ20gbm90IGNvbnZpbmNlZCB0aGlzIGlzIHdo
YXQgd2Ugd2FudCwgYXMgcGVyIC4uLg0KPj4+Pj4+DQo+Pj4+Pj4+Pj4gKyAgICAgICAgfQ0KPj4+
Pj4+Pj4+ICsgICAgfQ0KPj4+Pj4+Pj4+ICsNCj4+Pj4+Pj4+PiArICAgIHJldHVybiAwOw0KPj4+
Pj4+Pj4NCj4+Pj4+Pj4+IC4uLiB5b3UgLSBpbW8gc2Vuc2libHkgLSBhcmVuJ3QgY29tbXVuaWNh
dGluZyB0aGUgZXJyb3IgYmFjayB1cCAodG8gYWxsb3cNCj4+Pj4+Pj4+IHRoZSBkZXZpY2UgdG8g
YmUgdXNlZCB3aXRob3V0IEJBUiByZXNpemluZy4NCj4+Pj4+Pg0KPj4+Pj4+IC4uLiB3aGF0IEkg
c2FpZCBoZXJlLg0KPj4+Pj4gU29ycnksIEkgZGlkbuKAmXQgdW5kZXJzdGFuZC4NCj4+Pj4+IERv
IHlvdSBtZWFuIGl0IGlzIG5vdCBlbm91Z2ggdG8gcmV0dXJuIGVycm9yIGNvZGUgb25jZSBhIGhh
bmRsZXIgZmFpbGVkIHRvIGJlIGluc3RhbGxlZCwgSSBuZWVkIHRvIHJlbW92ZSB0aGUgYWxyZWFk
eSBpbnN0YWxsZWQgaGFuZGxlcnM/DQo+Pj4+DQo+Pj4+IE5vLCBpZiB5b3UgcmV0dXJuIGFuIGVy
cm9yIGhlcmUsIG5vdGhpbmcgZWxzZSBuZWVkcyBkb2luZy4gSG93ZXZlciwgSQ0KPj4+PiBxdWVz
dGlvbiB0aGF0IHJldHVybmluZyBhbiBlcnJvciBoZXJlIGlzIGdvb2Qgb3IgZXZlbiBuZWNlc3Nh
cnkuIEluDQo+Pj4+IHRoZSBldmVudCBvZiBhbiBlcnJvciwgdGhlIGRldmljZSBvdWdodCB0byBz
dGlsbCBiZSB1c2FibGUsIGp1c3QNCj4+Pj4gd2l0aG91dCB0aGUgQkFSLXJlc2l6aW5nIGNhcGFi
aWxpdHkuDQo+Pj4NCj4+PiBTbyB5b3Ugc3VnZ2VzdCB0aGF0IHRoZSBjYXBhYmlsaXR5IHNob3Vs
ZCBiZSBoaWRkZW4gaW4gdGhhdCBjYXNlPyAgV2UNCj4+PiBoYXZlIGxvZ2ljIHRvIGhpZGUgY2Fw
YWJpbGl0aWVzLCBqdXN0IG5vdCB1c2VkIGZvciB0aGUgaGFyZHdhcmUNCj4+PiBkb21haW4uICBJ
dCB3b3VsZCBuZWVkIHNvbWUgZXh0cmEgd2lyaW5nIHRvIGJlIGNhcGFibGUgb2YgaGlkaW5nDQo+
Pj4gZmFpbGVkIGNhcGFiaWxpdGllcy4NCj4+IENhbiB5b3UgZ2l2ZSBtZSBhIGd1aWRhbmNlIG9u
IGhvdyB0byBoaWRlIGEgZmFpbGVkIGNhcGFiaWxpdHk/DQo+PiBXaGF0IGNvZGVzIGFyZSBjdXJy
ZW50IGxvZ2ljIHRvIGhpZGUgY2FwYWJpbGl0aWVzPw0KPiANCj4gVGhpcyB3YXMgZG9uZSBieSBT
dGV3YXJ0IGZvciB0aGUgbGVnYWN5IFBDSSBjYXBhYmlsaXRpZXMsIGJ1dCBub3QNCj4gZXhhY3Rs
eSB0byBoaWRlIHRoZSBjYXBhYmlsaXRpZXMgdGhhdCBmYWlsIHRvIGluaXQuICBUYWtlIGEgbG9v
ayBhdA0KPiBjb21taXQ6DQo+IA0KPiBkODMwYjBhN2JjN2UgeGVuL3ZwY2k6IGhlYWRlcjogZmls
dGVyIFBDSSBjYXBhYmlsaXRpZXMNCj4gDQo+IEhvd2V2ZXIgdGhhdCB3YXMgZGVzaWduZWQgdG8g
ZXhwb3NlIGEgZml4ZWQgc2V0IG9mIGNhcGFiaWxpdGllcywNCj4gYWx3YXlzIGtub3duIHdoZW4g
aW5pdF9oZWFkZXIoKSBpcyBleGVjdXRlZC4gIElmIHdlIHdhbnQgdG8gaGlkZQ0KPiBjYXBhYmls
aXRpZXMgb24gZmFpbHVyZSB3ZSB3aWxsIG5lZWQgYSBiaXQgbW9yZSBmbGV4aWJsZSBpbnRlcmZh
Y2UgSQ0KPiB0aGluay4NCj4gDQo+IElkZWFsbHkgd2Ugd291bGQgbGlrZSB0byB0aWUgdGhpcyB0
byBpbml0aWFsaXphdGlvbiBob29rcyB0aGVtc2VsdmVzLA0KPiBzbyB0aGF0IGluIHZwY2lfYXNz
aWduX2RldmljZSgpIGFuIGluaXQgZnVuY3Rpb24gZmFpbGluZyBhdXRvbWF0aWNhbGx5DQo+IHRy
aWdnZXJzIHRoZSBoaWRpbmcgb2YgdGhlIGZhaWxpbmcgY2FwYWJpbGl0eS4gIFRoYXQgd291bGQg
bmVlZCBhbg0KPiBpbnRlcmZhY2Ugc2ltaWxhciB0bzoNCj4gDQo+ICNkZWZpbmUgUkVHSVNURVJf
VlBDSV9JTklUKDxjYXBhYmlsaXR5IGlkPiwgPGZ1bmN0aW9uPiwgPHByaW9yaXR5PiwNCj4gPHBj
aWU/PikNCj4gDQo+IFJFR0lTVEVSX1ZQQ0lfSU5JVChQQ0lfQ0FQX0lEX01TSSwgaW5pdF9tc2ks
IFZQQ0lfUFJJT1JJVFlfTE9XLA0KPiBmYWxzZSk7DQo+IA0KPiBBbmQgdGhlbiBpbiB2cGNpX2Fz
c2lnbl9kZXZpY2UoKSBhbnkgaW5pdCBmdW5jdGlvbiB0aGF0IGhhcyBhDQo+IGNhcGFiaWxpdHkg
SUQgZGlmZmVyZW50IHRoYW4gMCBhbmQgZmFpbHMgdG8gaW5pdGlhbGl6ZSB3b3VsZCBsZWFkIHRv
DQo+IHRoZSBjYXBhYmlsaXR5IGJlaW5nIG1hc2tlZC4NCj4gDQo+IEl0IHdvdWxkIGJlIGdyZWF0
IHRvIGhhdmUgYW4gaW50ZXJmYWNlIGxpa2UgdGhpcyBpbiBwbGFjZSwgYmVjYXVzZSB0aGUNCj4g
Y3VycmVudCBlcnJvciBoYW5kbGluZyBpbiB2UENJIGlzIG5vdCBncmVhdC4gIEZvciB0aGUgaGFy
ZHdhcmUgZG9tYWluDQo+IGluaXQgZnVuY3Rpb25zIGZhaWxpbmcgd2lsbCBqdXN0IGxlYWQgdG8g
dGhlIGRldmljZSBiZWluZyBmdWxseQ0KPiBhY2Nlc3NpYmxlIGJ5IGRvbTAgd2l0aG91dCBhbnkg
bWVkaWF0aW9uLg0KPiANCj4gQW55d2F5LCB3ZSBkb24ndCBkbyBhbnkgb2YgdGhpcyBmb3IgZG9t
MCBhdCB0aGUgbW9tZW50IHdoZW4gTVNJIG9yDQo+IE1TSS1YIGZhaWwgdG8gaW5pdCwgc28gSSdt
IG5vdCBzdXJlIGl0J3MgZmFpciB0byBhc2sgdGhhdCB5b3UgZG8gdGhpcw0KPiBmb3IgUmVCQVIu
ICBJdCB3b3VsZCBiZSBncmVhdCBpZiB5b3Ugd2FudCB0bywgYnV0IGl0J3Mgbm90IGEgdHJpdmlh
bA0KPiBhbW91bnQgb2Ygd29yay4NClRoYW5rcyENCkl0IHNvdW5kcyBsaWtlIG5vdCBlYXN5IHRv
IGRvLg0KQnV0IEkgd2lsbCB0cnkgdG8gaW1wbGVtZW50IHRoaXMgaWYgSSBoYXZlIHRpbWUuDQoN
Cj4gDQo+IFRoYW5rcywgUm9nZXIuDQoNCi0tIA0KQmVzdCByZWdhcmRzLA0KSmlxaWFuIENoZW4u
DQo=


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 09:45:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 09:45:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854230.1267485 (Exim 4.92)
	(envelope-from )
	id 1tLJHM-0005zw-I7; Wed, 11 Dec 2024 09:45:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854230.1267485; Wed, 11 Dec 2024 09:45: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 1tLJHM-0005zp-FT; Wed, 11 Dec 2024 09:45:12 +0000
Received: by outflank-mailman (input) for mailman id 854230;
 Wed, 11 Dec 2024 09:45: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 1tLJHL-0005jB-Bn
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 09:45:11 +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 99489c16-b7a4-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 10:45:04 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-5d3f57582a2so939164a12.1
 for ; Wed, 11 Dec 2024 01:45:09 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa6656f306csm632081066b.61.2024.12.11.01.45.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 01:45: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: 99489c16-b7a4-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733910309; x=1734515109; 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=MatPXrZkv5pN4xoMbDj8qSwvawl6FUHH2KG/qu9qqbM=;
        b=CtwL04R2hjrPiYMM6euhZRcJDTeFcN3i/N3ByJr5C2D8+czLTLBvZ0cieJ3SNJfn4w
         ApAGxrk9VxExNUpSm2Ozhd4wxziXSR7hW0FPbHQngHl0FnztfxF8Rb+OxOjhbp6AT4eY
         bITX7K0RSgF5UgCBaN2iYzWqdEFN1/ZhZBxPA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733910309; x=1734515109;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=MatPXrZkv5pN4xoMbDj8qSwvawl6FUHH2KG/qu9qqbM=;
        b=EwXGwS36PDclsTYw2btglgqaUD4eoV82RNnXNhq2OCxOX3t2UE45LbqyH59Z9tk5oV
         Ka2hwtRd+AXkfA+JWGKxSJ+cbIEnJ0kv+ypgqAWh2ITILKres+oMxo1cL2UWt1emD7DH
         zKp7X1heje5xShAd7dea+l2AgdHQ4VfyR5pU1kJtvRWpCuHNPXLr96ZnWaATxGB8ZlXo
         hPP97elXIIprg9sWCb2WJ5SgzEnOjCecCMubvha9zmg8orRKHMJO0lxVMDT4wUdzc7Jq
         6l15egxTdq6YGjys2rkMnaEf7CG/1IQFo7SFxe8G+2SNpjOk0s2Sthdc2cnWHpLj4dPy
         K9jQ==
X-Forwarded-Encrypted: i=1; AJvYcCWfkd2Gk9xjrKAT6kwjmrssHmFiBRJ+QTMB8JycBGD33xgTzxyK1xmyu4D0pwkH90s9UyRJmUOci4I=@lists.xenproject.org
X-Gm-Message-State: AOJu0YybTba1vkPLPqmHjzumGikYDPnwMMpkYBdAuLoNKl7j4WF+nxyp
	wQYNFzTHqZ6GAwFjn9UFYmzDM8V4Bs/Ewiv9CKYBRswqUZekhwqYTbmXW7nkBF0=
X-Gm-Gg: ASbGnctiShq4CfCd7c8FBD6J/Ama9qnTCv//ifQLlVigfAq4gEwYK2Vq49runOtmUT6
	mPV/fRGUNGYFTvnqBo6zsLts6TC6/IumMTnZ+m4dkliyh99vARvExZ/J3tW2zRLkvn4mG4T4gqN
	IjlmfETnopUzOff6fWYlao6y3rMg3dqlpDc+kHqkhiXsYemsxt1JcLVr6wWJ2s1mrBIr4idPWXi
	QV9WApAYKzUVJPvvuTpcZiixe/O8KsA3HD+ytO24Wz176n5U4KcoQ0hvk8UxHY=
X-Google-Smtp-Source: AGHT+IHJiqKn+BHt/6DzziOoe6q7lQrs4+z4LGDX9qSrfzNyO7JMg1cjTJwqBuMnYYOTMNBcphuzxA==
X-Received: by 2002:a17:907:3eaa:b0:aa6:7ff9:d248 with SMTP id a640c23a62f3a-aa6b159d7a7mr204683866b.8.1733910308905;
        Wed, 11 Dec 2024 01:45:08 -0800 (PST)
Date: Wed, 11 Dec 2024 10:45:07 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: "Chen, Jiqian" 
Cc: Jan Beulich ,
	Andrew Cooper ,
	Julien Grall ,
	Stefano Stabellini ,
	"Huang, Ray" ,
	"xen-devel@lists.xenproject.org" 
Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support
Message-ID: 
References: <20241202060956.1124162-1-Jiqian.Chen@amd.com>
 <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com>
 
 <1e0576d9-400e-4483-8dd1-061e215a00cd@suse.com>
 
 
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, Dec 11, 2024 at 09:36:00AM +0000, Chen, Jiqian wrote:
> On 2024/12/11 16:16, Roger Pau Monné wrote:
> > On Wed, Dec 11, 2024 at 06:37:30AM +0000, Chen, Jiqian wrote:
> >> On 2024/12/10 19:25, Roger Pau Monné wrote:
> >>> On Tue, Dec 10, 2024 at 10:54:43AM +0100, Jan Beulich wrote:
> >>>> On 10.12.2024 08:57, Chen, Jiqian wrote:
> >>>>> On 2024/12/10 15:17, Jan Beulich wrote:
> >>>>>> On 10.12.2024 08:07, Chen, Jiqian wrote:
> >>>>>>> On 2024/12/9 21:59, Jan Beulich wrote:
> >>>>>>>> On 02.12.2024 07:09, Jiqian Chen wrote:
> >>>>>>>>> +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
> >>>>>>>>> +                                      unsigned int reg,
> >>>>>>>>> +                                      uint32_t val,
> >>>>>>>>> +                                      void *data)
> >>>>>>>>> +{
> >>>>>>>>> +    uint64_t size;
> >>>>>>>>> +    unsigned int index;
> >>>>>>>>> +    struct vpci_bar *bars = data;
> >>>>>>>>> +
> >>>>>>>>> +    if ( pci_conf_read16(pdev->sbdf, PCI_COMMAND) & PCI_COMMAND_MEMORY )
> >>>>>>>>> +        return;
> >>>>>>>>
> >>>>>>>> I don't think something like this can go uncommented. I don't think the
> >>>>>>>> spec mandates to drop writes in this situation?
> >>>>>>> Spec says: Software must clear the Memory Space Enable bit in the Command register before writing the BAR Size field.
> >>>>>>> This check is suggested by Roger and it really helps to prevent erroneous writes in this case,
> >>>>>>> such as the result of debugging with Roger in the previous version.
> >>>>>>> I will add the spec's sentences as comments here in next version.
> >>>>>>
> >>>>>> What you quote from the spec may not be enough as a comment here. There's
> >>>>>> no direct implication that the write would simply be dropped on the floor
> >>>>>> if the bit is still set. So I think you want to go a little beyond just
> >>>>>> quoting from the spec.
> >>>>> How about quoting Roger's previous words: " The memory decoding must be disabled before writing the BAR size field.
> >>>>> Otherwise changing the BAR size will lead to the active p2m mappings getting out of sync w.r.t. the new BAR size." ?
> >>>>
> >>>> That'll be better, but imo still not enough to explain the outright ignoring
> >>>> of the write.
> >>>
> >>> I think we might want to do something along the lines of:
> >>>
> >>> uint64_t size = PCI_REBAR_CTRL_SIZE(val);
> >>> struct vpci_bar *bar = data;
> >>>
> >>> if ( bar->enabled )
> >>> {
> >>>     if ( size == bar->size )
> >>>         return;
> >>>
> >>>     /*
> >>>      * Refuse to resize a BAR while memory decoding is enabled, as
> >>>      * otherwise the size of the mapped region in the p2m would become
> >>>      * stale with the newly set BAR size, and the position of the BAR
> >>>      * would be reset to undefined.  Note the PCIe specification also
> >>>      * forbids resizing a BAR with memory decoding enabled.
> >>>      */
> >>>     gprintk(XENLOG_ERR,
> >>>             "%pp: refuse to resize BAR with memory decoding enabled\n",
> >>> 	    &pci->sbdf);
> >>>     return;
> >>> }
> >> Thank you very much!
> >>
> >>>
> >>> Note this requires that the data parameter points to the BAR that
> >>> matches the ReBAR control register, this needs adjusting in
> >>> init_rebar().
> >> I think I can keep current implementation of init_rebar() and use bars[index] to get the corresponding BAR.
> > 
> > IMO it would be best if you can pass the corresponding bar struct into
> > the handler directly, as that will avoid having to do a PCI read just
> > to get the BAR index from PCI_REBAR_CTRL.  It should also avoid the
> > need for the index and BAR type checks in rebar_ctrl_write().
> OK, if so, then I need to move the logic of getting index from PCI_REBAR_CTRL register and checking the BAR type into init_rebar(), right?

Yes, I think that would be better, as then the check is done only once
at init rather than on every access.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:09:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:09:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854248.1267496 (Exim 4.92)
	(envelope-from )
	id 1tLJfF-0001p7-Gg; Wed, 11 Dec 2024 10:09:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854248.1267496; Wed, 11 Dec 2024 10:09: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 1tLJfF-0001p0-Cm; Wed, 11 Dec 2024 10:09:53 +0000
Received: by outflank-mailman (input) for mailman id 854248;
 Wed, 11 Dec 2024 10:09: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 1tLJfD-0001ot-Mc
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:09:51 +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 0b6f926f-b7a8-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 11:09:44 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-434a766b475so62579995e9.1
 for ; Wed, 11 Dec 2024 02:09: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
 d2e1a72fcca58-725e438f169sm6054831b3a.168.2024.12.11.02.09.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:09: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: 0b6f926f-b7a8-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733911789; x=1734516589; 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=9VF63jh67GR8YssO15HmIu+Lzqwn3Nr4Bl5Tf2bmtiA=;
        b=PH3glYjDzomB/kdTIVFqbiLAko4Rg0rLEk9o3bXld80NW+wHMVbgimmMQutyLmArp4
         wllD6zX5UUNDlGqmrjVSAq+amdk4IKJnbKgJknA/qIpbLrKAZCjIreJu/m4t26pRpsdx
         32ZAZ09ijcWNpHVZC3UIIIEq/uhYEzuGdI/PJ1MO2hdqBF/kSE4cQZOndGc4WEiyPDOP
         XhbFp/HRDhPtOtHrVM+fJTp0Z71I9LsmOxT+xzJiQbqzJmlKZbQVZsS69nd4f3JS1Z7r
         Uo2Yrcp/Zn6LZbfQFCx4iL2ERBko1VtrWM4oxIjbiIeqlDjzAv/OtQxKLOxbhEUStEhk
         Jieg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733911789; x=1734516589;
        h=content-transfer-encoding:autocrypt:content-language:cc:to:subject
         :from:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=9VF63jh67GR8YssO15HmIu+Lzqwn3Nr4Bl5Tf2bmtiA=;
        b=wImXkvBLocY9FK1FaLcYnYhktNQBqvPW7L9sy98Eag2f8fx1FkSTf8uognjroNOQ7m
         ouqP7s0vthPzyOYmyK8HuZTlmccHikRFO1nno/eLL2mxKRjZTPaySNS15L/b+QeJIvqi
         BldCZtiTQqhlxLfGXxO4FzOz9SgsCuBZ4XaOVr/QXuRKQ6sp8ef3A6YyPpCufZCMe3el
         ieOBQy8PuR2uSRuJcNH1HKf1YiDQx0Crxs08DBhp9nLRVu1xwQh6pGwYGTdr/aKzbM0U
         bsONbCNP1CiT1IOnqPq0Jt88zkqhml9k8tJepG8Xb1GEBkg1uCqNIWYvJv5mkqbebW3+
         vk9Q==
X-Gm-Message-State: AOJu0YwvrnbvVa6jMhsHKA3+aMkB5R5PzjOEqQam9HX1VnnRX+Dk55hF
	0jdqNo3thDfo3gj424OVwwr8oz69CtxqrtbddaoOtfYCe2AElTwfAJS2HgGfCYnIbyYTJU0fFWM
	=
X-Gm-Gg: ASbGncv5EAfH3gJ+W2eQQk3ojVd4k4jNSfgEoXxGNsXfBoNbGsm6/M0YWY06fC1IErE
	mw9Z1qa7gW43k81h3oBVbXAuP/vsov20k88fvMbikQeSrUOvVJNKsWgQwxy7pZIKXmjpEQDr+uK
	f2fMJKG6ykkCIXy/E530ckY2L5p40CmqgV4LQ/jLIERee81edr9j//vF3wcojMjBnz2aGqA0UVC
	3A6ixjkupyWBOnY7kkdGhN1/1u9k+SDk+MpMCAUWWl+I26VdopKaUtYQGwIsNJ24pHyeUPo5QLP
	sbAd2KSJR85GLK/5rtyNKJoJ2xuqZu2VhDU0sLk=
X-Google-Smtp-Source: AGHT+IFQAMjfwX9ZaaqGr30Rpz73/TDE348NQPYZonqo+z3puNHSuaFHwQF18KYZGXiXB4rEQgehEA==
X-Received: by 2002:a05:6000:2d85:b0:385:f3fb:46a5 with SMTP id ffacd0b85a97d-3864cecff63mr1306951f8f.52.1733911788969;
        Wed, 11 Dec 2024 02:09:48 -0800 (PST)
Message-ID: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com>
Date: Wed, 11 Dec 2024 11:09:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich 
Subject: [PATCH v3 00/16] x86: support AVX10
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?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

AVX10.1 is just a re-branding of certain AVX512 (sub)features, i.e.
adds no new instructions. Therefore it's mostly relaxation that needs
doing, plus dealing with the 256-bit-only case that AVX512 itself
does not allow for. Luckily an unnecessary restriction on the mask
register insns was taken out again, simplifying the actual emulator
adjustments quite a bit.

AVX10.2 is adding quite a few new insns, support for which (new in v3)
is roughly added chapter-wise as the spec has them (perhaps not in the
order of the chapters there).

While it probably can be rebased ahead, the series in this form
depends on the previously submitted "[PATCH v5 0/3] x86/CPUID: leaf
pruning". It also is assumed to go on top of "[PATCH v7 0/7] x86emul:
misc additions", albeit at most contextual dependencies ought to exit
there.

I've tried to be very careful in rebasing ahead of other emulator
patches I've been carrying, but almost all testing I've done is with
all of those collectively in place.

01: x86/CPUID: enable AVX10 leaf
02: x86emul: support AVX10.1
03: x86emul/test: use simd_check_avx512*() in main()
04: x86emul/test: drop cpu_has_avx512vl
05: x86emul: AVX10.1 testing
06: x86emul/test: engage AVX512VL via command line option
07: x86emul: support AVX10.2 256-bit embedded rounding / SAE
08: x86emul: support AVX10.2 scalar compare insns
09: x86emul: support AVX10.2 partial copy insns
10: x86emul: support AVX10.2 media insns
11: x86emul: support AVX10.2 minmax insns
12: x86emul: support AVX10.2 media insns
13: x86emul: support AVX10.2 saturating convert insns
14: x86emul: support other AVX10.2 convert insns
15: x86emul: support SIMD MOVRS
16: x86emul: support AVX10.2 forms of SM4 insns

Jan


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:11:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:11:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854258.1267506 (Exim 4.92)
	(envelope-from )
	id 1tLJgi-0003dq-PR; Wed, 11 Dec 2024 10:11:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854258.1267506; Wed, 11 Dec 2024 10:11: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 1tLJgi-0003dj-Mb; Wed, 11 Dec 2024 10:11:24 +0000
Received: by outflank-mailman (input) for mailman id 854258;
 Wed, 11 Dec 2024 10:11: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 1tLJgh-0003db-GX
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:11:23 +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 459ab123-b7a8-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 11:11:22 +0100 (CET)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3862a921123so3839670f8f.3
 for ; Wed, 11 Dec 2024 02:11: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
 d2e1a72fcca58-725eccf0c91sm5407421b3a.100.2024.12.11.02.11.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:11: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: 459ab123-b7a8-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733911882; x=1734516682; 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=ZuBh/F1oH3q7Tih7C7Y9Sp04iSX23XH5E4IlV6QEhGw=;
        b=UnKW1q135Si6nl/mOBlRzMK2Q6R/+ZcPk2y5FNGr8nqHqVnQoFm0OMGZ41Ps8r9lqN
         OQRU1aPcN624TlzjAGMMiL/r0JxHcx2r0ysfhSxR1DGZqdLnHLGnkqaxoPY5fLqv/USx
         dEqClr4JyUjwQ3PdQeOuXxNRvTegjHJG/MAgaH6eDxlCKs+6Yrfrh1f2rSWfP3VoE09n
         ecavGiNYYaJADAoTitmdKgbSBotWCqTjTR3pY3kf7iTRedoUO7nqeVqLnboPiSq0YDUs
         fogTa5hIoGQCHr+VYkVQ54RyNCtMExa/wbzQr0w0EtFh5Z824ng04lQTsFNXfYeyC58P
         bEPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733911882; x=1734516682;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=ZuBh/F1oH3q7Tih7C7Y9Sp04iSX23XH5E4IlV6QEhGw=;
        b=HVTUxf0l6w3cbaf9VGUy+NkhHeVf1BdAirYVD89e6kA5JMDswXgAvb96BK8S/D0tqm
         zMYrUSVzVFA6hSRbtvNCkYVsynblbuEvXM8YLelTq+80+NCNwBAqSYfKbHJWFl40eAZg
         jXd8kveUc3KmCOuLI836PJ8l8855X6fEPWS18MYcZez6VwSHHzN/mDkgKdPc4DbeizeK
         ir/NCFOhpQs5FMaEbNmjfoSJCxVFam242KwXcdKVryKmPRBwU+IVf6s/28nQrEJFPezl
         Ce9E6nj2lGGXx6RhVRMvCNGJT+W6ZjSWUNNpXFq3Bf4LlhFses6UHdFRL1oJ4KVWbMN0
         JdSQ==
X-Gm-Message-State: AOJu0YwaH6LBotlfLizahR17HwbdwtZY7kf1UY66BQbhASVxfWHJmNrt
	Au66ta4vakvyVM0mGYaIbyITNIeNiCkt9fUMLizyoNi6Ca7d7vr0ebiOZNOKaDn099KWIjNLsQw
	=
X-Gm-Gg: ASbGnctE71/mdDaxa23gcrssXgLZC6KpiLeQDC3LungmtKTGVzTlo2r+Gx+YeumXo8A
	F75qk/WK835yLbIZ5wUyors5Y3JGabV7yFIUYsdKjoOFqunRwK79ng/qyu3dmwqLEOW1rk0g+Pq
	ERMzdOW9mU2BAc5cVik67fpXxsWTq3EBxeogmMC8gjYRIrwjCZQXWm3qcZBed7w+8+73MU3e2e5
	VmJgpzky+xCfA2FuoVHW4mYb1dtlyPJPzKXrvhgW6g4vcwOG3NK8dpF10adceVizE2symoHyKoA
	hg51P/+TbHLvR6E4pLIHpSTy9bu7x2hbcRAlYv4=
X-Google-Smtp-Source: AGHT+IGAStCRdzqX1B9AAzuRgGdBaa4Vqj4WKL3apHiiTmf58IOp/+ELWyw1OL7Fi5HVI9RmLlALvg==
X-Received: by 2002:a5d:47ac:0:b0:386:1cd3:8a00 with SMTP id ffacd0b85a97d-3864cec5a2cmr1728227f8f.40.1733911881625;
        Wed, 11 Dec 2024 02:11:21 -0800 (PST)
Message-ID: <0b543263-2c66-4e35-a822-09c0b6ca016a@suse.com>
Date: Wed, 11 Dec 2024 11:11:16 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v3 01/16] x86/CPUID: enable AVX10 leaf
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@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: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

This requires bumping the number of basic leaves we support. Apart from
this the logic is modeled as closely as possible after that of leaf 7
handling.

Signed-off-by: Jan Beulich 
---
The gen-cpuid.py adjustment is merely the minimum needed. It's not
really clear to me whether someone turning off e.g. AVX512BW might then
also validly expect AVX10 to be turned off.

Spec version 2 leaves unclear what the xstate components are which would
need enabling for AVX10/256. recalculate_{xstate,misc}() are therefore
conservative for now.

Do we want to synthesize AVX10 in the policy when all necessary AVX512*
features are available, thus allowing migration from an AVX10 host to a
suitable non-AVX10 one?

The prior vsz128 bit is now defined as reserved-at-1: No idea yet how to
represent this.

How a toolstack side equivalent (if any) of the init_dom0_cpuid_policy()
change would look like is entirely unclear to me. How much should we
take from the max policy, and how much should we require the user to
specify (and how would the latter look like)?
---
v3: Re-base.
v2: Add logic to init_dom0_cpuid_policy(). Drop vsz128 field. Re-base.

--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -210,7 +210,7 @@ static void recalculate_xstate(struct cp
     if ( p->feat.mpx )
         xstates |= X86_XCR0_BNDREGS | X86_XCR0_BNDCSR;
 
-    if ( p->feat.avx512f )
+    if ( p->feat.avx512f || (p->feat.avx10 && p->avx10.vsz512) )
         xstates |= X86_XCR0_OPMASK | X86_XCR0_ZMM | X86_XCR0_HI_ZMM;
 
     if ( p->feat.pku )
@@ -271,6 +271,16 @@ static void recalculate_misc(struct cpu_
 
     p->basic.raw[0xc] = EMPTY_LEAF;
 
+    zero_leaves(p->basic.raw, 0xe, 0x23);
+
+    p->avx10.raw[0].b &= 0x000700ff;
+    p->avx10.raw[0].c = p->avx10.raw[0].d = 0;
+    if ( !p->feat.avx10 || !p->avx10.version || !p->avx10.vsz512 )
+    {
+        p->feat.avx10 = false;
+        memset(p->avx10.raw, 0, sizeof(p->avx10.raw));
+    }
+
     p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
 
     /* Most of Power/RAS hidden from guests. */
@@ -394,6 +404,7 @@ static void __init guest_common_max_leav
 {
     p->basic.max_leaf       = ARRAY_SIZE(p->basic.raw) - 1;
     p->feat.max_subleaf     = ARRAY_SIZE(p->feat.raw) - 1;
+    p->avx10.max_subleaf    = ARRAY_SIZE(p->avx10.raw) - 1;
     p->extd.max_leaf        = 0x80000000U + ARRAY_SIZE(p->extd.raw) - 1;
 }
 
@@ -402,6 +413,7 @@ static void __init guest_common_default_
 {
     p->basic.max_leaf       = host_cpu_policy.basic.max_leaf;
     p->feat.max_subleaf     = host_cpu_policy.feat.max_subleaf;
+    p->avx10.max_subleaf    = host_cpu_policy.avx10.max_subleaf;
     p->extd.max_leaf        = host_cpu_policy.extd.max_leaf;
 }
 
@@ -905,6 +917,7 @@ void recalculate_cpuid_policy(struct dom
 
     p->basic.max_leaf   = min(p->basic.max_leaf,   max->basic.max_leaf);
     p->feat.max_subleaf = min(p->feat.max_subleaf, max->feat.max_subleaf);
+    p->avx10.max_subleaf = min(p->avx10.max_subleaf, max->avx10.max_subleaf);
     p->extd.max_leaf    = 0x80000000U | min(p->extd.max_leaf & 0xffff,
                                             ((p->x86_vendor & (X86_VENDOR_AMD |
                                                                X86_VENDOR_HYGON))
@@ -951,6 +964,8 @@ void recalculate_cpuid_policy(struct dom
 
     if ( p->basic.max_leaf < XSTATE_CPUID )
         __clear_bit(X86_FEATURE_XSAVE, fs);
+    if ( p->basic.max_leaf < 0x24 )
+        __clear_bit(X86_FEATURE_AVX10, fs);
 
     sanitise_featureset(fs);
 
@@ -1020,9 +1035,18 @@ void __init init_dom0_cpuid_policy(struc
     /* Apply dom0-cpuid= command line settings, if provided. */
     if ( dom0_cpuid_cmdline )
     {
+        const struct cpu_policy *max = is_pv_domain(d)
+            ? (IS_ENABLED(CONFIG_PV)  ?  &pv_max_cpu_policy : NULL)
+            : (IS_ENABLED(CONFIG_HVM) ? &hvm_max_cpu_policy : NULL);
         uint32_t fs[FSCAPINTS];
         unsigned int i;
 
+        if ( !max )
+        {
+            ASSERT_UNREACHABLE();
+            return;
+        }
+
         x86_cpu_policy_to_featureset(p, fs);
 
         for ( i = 0; i < ARRAY_SIZE(fs); ++i )
@@ -1032,6 +1056,13 @@ void __init init_dom0_cpuid_policy(struc
         }
 
         x86_cpu_featureset_to_policy(fs, p);
+
+        /*
+         * Default-off features with their own leaves need those leaves
+         * re-populated from the max policy.
+         */
+        if ( p->feat.avx10 )
+            p->avx10 = max->avx10;
     }
 
     /*
@@ -1064,6 +1095,8 @@ static void __init __maybe_unused build_
                  sizeof(raw_cpu_policy.feat.raw));
     BUILD_BUG_ON(sizeof(raw_cpu_policy.xstate) !=
                  sizeof(raw_cpu_policy.xstate.raw));
+    BUILD_BUG_ON(sizeof(raw_cpu_policy.avx10) !=
+                 sizeof(raw_cpu_policy.avx10.raw));
     BUILD_BUG_ON(sizeof(raw_cpu_policy.extd) !=
                  sizeof(raw_cpu_policy.extd.raw));
 }
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -87,6 +87,15 @@ void guest_cpuid(const struct vcpu *v, u
             *res = array_access_nospec(p->xstate.raw, subleaf);
             break;
 
+        case 0x24:
+            ASSERT(p->avx10.max_subleaf < ARRAY_SIZE(p->avx10.raw));
+            if ( subleaf > min_t(uint32_t, p->avx10.max_subleaf,
+                                 ARRAY_SIZE(p->avx10.raw) - 1) )
+                return;
+
+            *res = array_access_nospec(p->avx10.raw, subleaf);
+            break;
+
         default:
             *res = array_access_nospec(p->basic.raw, leaf);
             break;
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -355,6 +355,7 @@ XEN_CPUFEATURE(UTMR,               15*32
 XEN_CPUFEATURE(PREFETCHI,          15*32+14) /*A  PREFETCHIT{0,1} Instructions */
 XEN_CPUFEATURE(USER_MSR,           15*32+15) /*s  U{RD,WR}MSR Instructions */
 XEN_CPUFEATURE(CET_SSS,            15*32+18) /*   CET Supervisor Shadow Stacks safe to use */
+XEN_CPUFEATURE(AVX10,              15*32+19) /*   AVX10 Converged Vector ISA */
 
 /* Intel-defined CPU features, MSR_ARCH_CAPS 0x10a.eax, word 16 */
 XEN_CPUFEATURE(RDCL_NO,            16*32+ 0) /*A  No Rogue Data Cache Load (Meltdown) */
--- a/xen/include/xen/lib/x86/cpu-policy.h
+++ b/xen/include/xen/lib/x86/cpu-policy.h
@@ -85,11 +85,12 @@ unsigned int x86_cpuid_lookup_vendor(uin
  */
 const char *x86_cpuid_vendor_to_str(unsigned int vendor);
 
-#define CPUID_GUEST_NR_BASIC      (0xdu + 1)
+#define CPUID_GUEST_NR_BASIC      (0x24u + 1)
 #define CPUID_GUEST_NR_CACHE      (5u + 1)
 #define CPUID_GUEST_NR_FEAT       (2u + 1)
 #define CPUID_GUEST_NR_TOPO       (1u + 1)
 #define CPUID_GUEST_NR_XSTATE     (62u + 1)
+#define CPUID_GUEST_NR_AVX10      (0u + 1)
 #define CPUID_GUEST_NR_EXTD_INTEL (0x8u + 1)
 #define CPUID_GUEST_NR_EXTD_AMD   (0x21u + 1)
 #define CPUID_GUEST_NR_EXTD       MAX(CPUID_GUEST_NR_EXTD_INTEL, \
@@ -255,6 +256,19 @@ struct cpu_policy
         } comp[CPUID_GUEST_NR_XSTATE];
     } xstate;
 
+    /* Structured AVX10 information leaf: 0x000000024[xx] */
+    union {
+        struct cpuid_leaf raw[CPUID_GUEST_NR_AVX10];
+        struct {
+            /* Subleaf 0. */
+            uint32_t max_subleaf;
+            uint32_t version:8, :9;
+            bool vsz256:1, vsz512:1;
+            uint32_t :13;
+            uint32_t /* c */:32, /* d */:32;
+        };
+    } avx10;
+
     /* Extended leaves: 0x800000xx */
     union {
         struct cpuid_leaf raw[CPUID_GUEST_NR_EXTD];
--- a/xen/lib/x86/cpuid.c
+++ b/xen/lib/x86/cpuid.c
@@ -123,6 +123,7 @@ void x86_cpu_policy_fill_native(struct c
         switch ( i )
         {
         case 0x4: case 0x7: case 0xb: case 0xd:
+        case 0x24:
             /* Multi-invocation leaves.  Deferred. */
             continue;
         }
@@ -216,6 +217,15 @@ void x86_cpu_policy_fill_native(struct c
         }
     }
 
+    if ( p->basic.max_leaf >= 0x24 )
+    {
+        cpuid_count_leaf(0x24, 0, &p->avx10.raw[0]);
+
+        for ( i = 1; i <= MIN(p->avx10.max_subleaf,
+                              ARRAY_SIZE(p->avx10.raw) - 1); ++i )
+            cpuid_count_leaf(0x24, i, &p->avx10.raw[i]);
+    }
+
     /* Extended leaves. */
     cpuid_leaf(0x80000000U, &p->extd.raw[0]);
     for ( i = 1; i <= MIN(p->extd.max_leaf & 0xffffU,
@@ -285,6 +295,9 @@ void x86_cpu_policy_clear_out_of_range_l
                     ARRAY_SIZE(p->xstate.raw) - 1);
     }
 
+    if ( p->basic.max_leaf < 0x24 )
+        memset(p->avx10.raw, 0, sizeof(p->avx10.raw));
+
     zero_leaves(p->extd.raw,
                 ((p->extd.max_leaf >> 16) == 0x8000
                  ? (p->extd.max_leaf & 0xffff) + 1 : 0),
@@ -297,6 +310,8 @@ void __init x86_cpu_policy_bound_max_lea
         min_t(uint32_t, p->basic.max_leaf, ARRAY_SIZE(p->basic.raw) - 1);
     p->feat.max_subleaf =
         min_t(uint32_t, p->feat.max_subleaf, ARRAY_SIZE(p->feat.raw) - 1);
+    p->avx10.max_subleaf =
+        min_t(uint32_t, p->avx10.max_subleaf, ARRAY_SIZE(p->avx10.raw) - 1);
     p->extd.max_leaf = 0x80000000U | min_t(uint32_t, p->extd.max_leaf & 0xffff,
                                            ARRAY_SIZE(p->extd.raw) - 1);
 }
@@ -324,6 +339,8 @@ void x86_cpu_policy_shrink_max_leaves(st
      */
     p->basic.raw[0xd] = p->xstate.raw[0];
 
+    p->basic.raw[0x24] = p->avx10.raw[0];
+
     for ( i = p->basic.max_leaf; i; --i )
         if ( p->basic.raw[i].a | p->basic.raw[i].b |
              p->basic.raw[i].c | p->basic.raw[i].d )
@@ -457,6 +474,13 @@ int x86_cpuid_copy_to_buffer(const struc
             break;
         }
 
+        case 0x24:
+            for ( subleaf = 0;
+                  subleaf <= MIN(p->avx10.max_subleaf,
+                                 ARRAY_SIZE(p->avx10.raw) - 1); ++subleaf )
+                COPY_LEAF(leaf, subleaf, &p->avx10.raw[subleaf]);
+            break;
+
         default:
             COPY_LEAF(leaf, XEN_CPUID_NO_SUBLEAF, &p->basic.raw[leaf]);
             break;
@@ -549,6 +573,13 @@ int x86_cpuid_copy_from_buffer(struct cp
                 array_access_nospec(p->xstate.raw, data.subleaf) = l;
                 break;
 
+            case 0x24:
+                if ( data.subleaf >= ARRAY_SIZE(p->avx10.raw) )
+                    goto out_of_range;
+
+                array_access_nospec(p->avx10.raw, data.subleaf) = l;
+                break;
+
             default:
                 if ( data.subleaf != XEN_CPUID_NO_SUBLEAF )
                     goto out_of_range;
--- a/xen/lib/x86/policy.c
+++ b/xen/lib/x86/policy.c
@@ -21,6 +21,12 @@ int x86_cpu_policies_are_compatible(cons
     if ( guest->feat.max_subleaf > host->feat.max_subleaf )
         FAIL_CPUID(7, 0);
 
+    if ( guest->avx10.version > host->avx10.version ||
+         (guest->avx10.vsz512
+          ? !host->avx10.vsz512
+          : guest->avx10.vsz256 && !host->avx10.vsz256 && !host->avx10.vsz512) )
+        FAIL_CPUID(0x24, 0);
+
     if ( guest->extd.max_leaf > host->extd.max_leaf )
         FAIL_CPUID(0x80000000U, NA);
 
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -286,7 +286,7 @@ def crunch_numbers(state):
         # enabled.  Certain later extensions, acting on 256-bit vectors of
         # integers, better depend on AVX2 than AVX.
         AVX2: [AVX512F, VAES, VPCLMULQDQ, AVX_VNNI, AVX_IFMA, AVX_VNNI_INT8,
-               AVX_VNNI_INT16, SHA512, SM4],
+               AVX_VNNI_INT16, SHA512, SM4, AVX10],
 
         # AVX512F is taken to mean hardware support for 512bit registers
         # (which in practice depends on the EVEX prefix to encode) as well



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:11:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:11:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854270.1267516 (Exim 4.92)
	(envelope-from )
	id 1tLJhD-0004LL-4L; Wed, 11 Dec 2024 10:11:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854270.1267516; Wed, 11 Dec 2024 10:11:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLJhD-0004LD-1U; Wed, 11 Dec 2024 10:11:55 +0000
Received: by outflank-mailman (input) for mailman id 854270;
 Wed, 11 Dec 2024 10:11: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 1tLJhB-0003z3-P5
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:11:54 +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 53ce5ed7-b7a8-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 11:11:46 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-434a736518eso72550585e9.1
 for ; Wed, 11 Dec 2024 02:11: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
 d2e1a72fcca58-725e67ec497sm6093103b3a.125.2024.12.11.02.11.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:11: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: 53ce5ed7-b7a8-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733911910; x=1734516710; 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=qZjwkU1zfDESdoMN4mfxEFe4CEUvDIL1q+y4iBCYT98=;
        b=KdN2bVHef7NAfewwsvC3q6vz/02EDCZshLk23Vtgsj1ByxrHA6mpMXk8rwHvKW8fuX
         BMZIX1CjYPf/h+9X8oajJvfEJiKcavqsBVLsdTyA+ngifWF4JBOT5Xj1l7vRn3iRndtZ
         A/U1hYXJPKYyLVd4HxESLO+lj0fnp0bXHgi3ouxj2geILgs0q93/Dck4YNfunY2ikgva
         tLK56HuRJOYld+nBCLOP0WSTO7pfOHeqhpEMdE5Tenm++vq4WAsb0ojtStUh4VbnsBT0
         zP5gOdQmHRANXnAZVsdtCnsdlx9EvfjzCT7bQpr9CGRjLORxmDwP6zlr9YscqZBkqrDt
         zHvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733911910; x=1734516710;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=qZjwkU1zfDESdoMN4mfxEFe4CEUvDIL1q+y4iBCYT98=;
        b=OnTLjMDnnt77Ch2aa0jNHsOjSB8HJJyzUpa9ys52CCrB98R9Rt6wcWiheNje2D90T3
         48soC4L6O0geYKlJ61RxM41BQ8+VadiVg9fTE1rl5e44g6yhbG5qYdMDdTKwcOiM/QiQ
         9DelmGA/Ur+sDLcew4gHh4oyenvyxVQXQZliaTzHrrkWq7UPgpYxKloSID0E0ny3x/D6
         atgOt1aBvRtVuH+eC3ggahv3rnyrT16iXcPxfNEjzADRhCyU8YjwA/AaKNNrZWz/MUoB
         7FKGohK5kzbszvdrz76HuAWiQi5yzW8ctxmWVA8zynWp9dl4sRztKas4QbsdwxIqJtg+
         3XRA==
X-Gm-Message-State: AOJu0YyEGMqb1u6aTTvPY1dkdCg0z4Ha1CG6xLsnO18lG4lGQKNTDrg8
	fowRpyHXYcPedk6mAls1AEID2DFFMXthKGfiNpNgnsMMfhNXX2eMZkj7hcLBaVzz73qdHYy7+6M
	=
X-Gm-Gg: ASbGncueAaWzcCWQ8IymcUnYPl3mQI1z+V8HY1XP4LH/r3Tvubtk/eBbYhk6LIXYCx1
	IBvOTXAz+WnBXrYGZ6gv02+V4qa04Z8nbUMCMQhU/Q8xLxBbaDThxrfIlWkiC0XE3tPiqVZTIw9
	UeAr+BXETnSDqXAN8MjGqxTqWBOCq2OGHqKyoQXzTJ9F9ThK2MiIB7oAXwBJMPE4B9+Ih2imama
	5EpLbXg57PQvmaEyCrTHhNrWU8832i8lI9juidwKTLh13I26Kv/d9R5a0PUsdzarlZYs7mtym2q
	3C2jhkTPmqSYQ1LQroMDn+9ruB7X/1cuYkDewgY=
X-Google-Smtp-Source: AGHT+IGzov3JM+76iGkVOVPnrySD2x8Umb9bZ43hO3YHGzCCM6SFVFHotA7HMpKq6U74eAJ2hUjDCQ==
X-Received: by 2002:a05:6000:1fae:b0:385:e88a:7037 with SMTP id ffacd0b85a97d-3864ce888a6mr1669008f8f.6.1733911910122;
        Wed, 11 Dec 2024 02:11:50 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 11:11:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v3 02/16] x86emul: support AVX10.1
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Oleksii Kurochko 
References: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@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: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

This requires relaxing various pre-existing AVX512* checks, as AVX10.1
covers all AVX512* except PF, ER, 4FMAPS, 4VNNIW (support for all of
which was removed meanwhile anyway), and VP2INTERSECT. Yet potentially
with only less than 512-bit vector width, while otoh guaranteeing more
narrow widths being available when wider are (i.e. unlike AVX512VL being
an add-on feature on top of AVX512F).

Note that visa_check(), replacing host_and_vcpu_must_have() uses, checks
only the guest capability: We wouldn't expose AVX512* (nor AVX10)
without the hardware supporting it. Similarly in vlen_check() the
original host_and_vcpu_must_have() is reduced to the equivalent of just
vcpu_must_have(). This also simplifies (resulting) code in the test and
fuzzing harnesses, as there the XCR0 checks that are part of
cpu_has_avx512* are only needed in local code, not in the emulator
itself (where respective checking occurs elsewhere anyway, utilizing
emul_test_read_xcr()).

While in most cases the changes to x86_emulate() are entirely
mechanical, for opmask insns earlier unconditional AVX512F checks are
converted into "else" clauses to existing if/else-if ones.

To be certain that no uses remain, also drop respective cpu_has_avx512*
(except in the test harness) and vcpu_has_avx512*().

Signed-off-by: Jan Beulich 
---
Probably avx512_vlen_check() should have the avx512_ prefix dropped, now
that it also covers AVX10. But if so that wants to be either a prereq or
a follow-on patch.

visa_check() won't cover AVX10.2 and higher, but probably we will want
independent checking logic for that anyway.

Spec version 2 still leaves unclear what the xstate components are which
would need enabling for AVX10/256. x86emul_get_fpu() is therefore
untouched for now.

Since it'll be reducing code size, we may want to further convert
host_and_vcpu_must_have() to just vcpu_must_have() where appropriate
(should be [almost?] everywhere).
---
v3: Add ChangeLog entry.
v2: Drop use of vsz128 field. Re-base, in particular over dropping of
    Xeon Phi support.

--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -18,6 +18,7 @@ The format is based on [Keep a Changelog
    - Experimental support for Armv8-R.
  - On x86:
    - xl suspend/resume subcommands.
+   - Add support for AVX10.1. (Experimental)
 
 ### Removed
  - On x86:
--- a/xen/arch/x86/include/asm/cpufeature.h
+++ b/xen/arch/x86/include/asm/cpufeature.h
@@ -133,29 +133,18 @@ static inline bool boot_cpu_has(unsigned
 #define cpu_has_pqe             boot_cpu_has(X86_FEATURE_PQE)
 #define cpu_has_fpu_sel         (!boot_cpu_has(X86_FEATURE_NO_FPU_SEL))
 #define cpu_has_mpx             boot_cpu_has(X86_FEATURE_MPX)
-#define cpu_has_avx512f         boot_cpu_has(X86_FEATURE_AVX512F)
-#define cpu_has_avx512dq        boot_cpu_has(X86_FEATURE_AVX512DQ)
 #define cpu_has_rdseed          boot_cpu_has(X86_FEATURE_RDSEED)
 #define cpu_has_smap            boot_cpu_has(X86_FEATURE_SMAP)
-#define cpu_has_avx512_ifma     boot_cpu_has(X86_FEATURE_AVX512_IFMA)
 #define cpu_has_clflushopt      boot_cpu_has(X86_FEATURE_CLFLUSHOPT)
 #define cpu_has_clwb            boot_cpu_has(X86_FEATURE_CLWB)
-#define cpu_has_avx512cd        boot_cpu_has(X86_FEATURE_AVX512CD)
 #define cpu_has_proc_trace      boot_cpu_has(X86_FEATURE_PROC_TRACE)
 #define cpu_has_sha             boot_cpu_has(X86_FEATURE_SHA)
-#define cpu_has_avx512bw        boot_cpu_has(X86_FEATURE_AVX512BW)
-#define cpu_has_avx512vl        boot_cpu_has(X86_FEATURE_AVX512VL)
 
 /* CPUID level 0x00000007:0.ecx */
-#define cpu_has_avx512_vbmi     boot_cpu_has(X86_FEATURE_AVX512_VBMI)
 #define cpu_has_pku             boot_cpu_has(X86_FEATURE_PKU)
-#define cpu_has_avx512_vbmi2    boot_cpu_has(X86_FEATURE_AVX512_VBMI2)
 #define cpu_has_gfni            boot_cpu_has(X86_FEATURE_GFNI)
 #define cpu_has_vaes            boot_cpu_has(X86_FEATURE_VAES)
 #define cpu_has_vpclmulqdq      boot_cpu_has(X86_FEATURE_VPCLMULQDQ)
-#define cpu_has_avx512_vnni     boot_cpu_has(X86_FEATURE_AVX512_VNNI)
-#define cpu_has_avx512_bitalg   boot_cpu_has(X86_FEATURE_AVX512_BITALG)
-#define cpu_has_avx512_vpopcntdq boot_cpu_has(X86_FEATURE_AVX512_VPOPCNTDQ)
 #define cpu_has_rdpid           boot_cpu_has(X86_FEATURE_RDPID)
 #define cpu_has_movdiri         boot_cpu_has(X86_FEATURE_MOVDIRI)
 #define cpu_has_movdir64b       boot_cpu_has(X86_FEATURE_MOVDIR64B)
@@ -180,7 +169,6 @@ static inline bool boot_cpu_has(unsigned
 #define cpu_has_tsx_force_abort boot_cpu_has(X86_FEATURE_TSX_FORCE_ABORT)
 #define cpu_has_serialize       boot_cpu_has(X86_FEATURE_SERIALIZE)
 #define cpu_has_hybrid          boot_cpu_has(X86_FEATURE_HYBRID)
-#define cpu_has_avx512_fp16     boot_cpu_has(X86_FEATURE_AVX512_FP16)
 #define cpu_has_arch_caps       boot_cpu_has(X86_FEATURE_ARCH_CAPS)
 
 /* CPUID level 0x00000007:1.eax */
@@ -188,7 +176,6 @@ static inline bool boot_cpu_has(unsigned
 #define cpu_has_sm3             boot_cpu_has(X86_FEATURE_SM3)
 #define cpu_has_sm4             boot_cpu_has(X86_FEATURE_SM4)
 #define cpu_has_avx_vnni        boot_cpu_has(X86_FEATURE_AVX_VNNI)
-#define cpu_has_avx512_bf16     boot_cpu_has(X86_FEATURE_AVX512_BF16)
 #define cpu_has_cmpccxadd       boot_cpu_has(X86_FEATURE_CMPCCXADD)
 #define cpu_has_avx_ifma        boot_cpu_has(X86_FEATURE_AVX_IFMA)
 
--- a/xen/arch/x86/x86_emulate/private.h
+++ b/xen/arch/x86/x86_emulate/private.h
@@ -562,26 +562,15 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_invpcid()     (ctxt->cpuid->feat.invpcid)
 #define vcpu_has_rtm()         (ctxt->cpuid->feat.rtm)
 #define vcpu_has_mpx()         (ctxt->cpuid->feat.mpx)
-#define vcpu_has_avx512f()     (ctxt->cpuid->feat.avx512f)
-#define vcpu_has_avx512dq()    (ctxt->cpuid->feat.avx512dq)
 #define vcpu_has_rdseed()      (ctxt->cpuid->feat.rdseed)
 #define vcpu_has_adx()         (ctxt->cpuid->feat.adx)
 #define vcpu_has_smap()        (ctxt->cpuid->feat.smap)
-#define vcpu_has_avx512_ifma() (ctxt->cpuid->feat.avx512_ifma)
 #define vcpu_has_clflushopt()  (ctxt->cpuid->feat.clflushopt)
 #define vcpu_has_clwb()        (ctxt->cpuid->feat.clwb)
-#define vcpu_has_avx512cd()    (ctxt->cpuid->feat.avx512cd)
 #define vcpu_has_sha()         (ctxt->cpuid->feat.sha)
-#define vcpu_has_avx512bw()    (ctxt->cpuid->feat.avx512bw)
-#define vcpu_has_avx512vl()    (ctxt->cpuid->feat.avx512vl)
-#define vcpu_has_avx512_vbmi() (ctxt->cpuid->feat.avx512_vbmi)
-#define vcpu_has_avx512_vbmi2() (ctxt->cpuid->feat.avx512_vbmi2)
 #define vcpu_has_gfni()        (ctxt->cpuid->feat.gfni)
 #define vcpu_has_vaes()        (ctxt->cpuid->feat.vaes)
 #define vcpu_has_vpclmulqdq()  (ctxt->cpuid->feat.vpclmulqdq)
-#define vcpu_has_avx512_vnni() (ctxt->cpuid->feat.avx512_vnni)
-#define vcpu_has_avx512_bitalg() (ctxt->cpuid->feat.avx512_bitalg)
-#define vcpu_has_avx512_vpopcntdq() (ctxt->cpuid->feat.avx512_vpopcntdq)
 #define vcpu_has_rdpid()       (ctxt->cpuid->feat.rdpid)
 #define vcpu_has_movdiri()     (ctxt->cpuid->feat.movdiri)
 #define vcpu_has_movdir64b()   (ctxt->cpuid->feat.movdir64b)
@@ -589,12 +578,10 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_avx512_vp2intersect() (ctxt->cpuid->feat.avx512_vp2intersect)
 #define vcpu_has_serialize()   (ctxt->cpuid->feat.serialize)
 #define vcpu_has_tsxldtrk()    (ctxt->cpuid->feat.tsxldtrk)
-#define vcpu_has_avx512_fp16() (ctxt->cpuid->feat.avx512_fp16)
 #define vcpu_has_sha512()      (ctxt->cpuid->feat.sha512)
 #define vcpu_has_sm3()         (ctxt->cpuid->feat.sm3)
 #define vcpu_has_sm4()         (ctxt->cpuid->feat.sm4)
 #define vcpu_has_avx_vnni()    (ctxt->cpuid->feat.avx_vnni)
-#define vcpu_has_avx512_bf16() (ctxt->cpuid->feat.avx512_bf16)
 #define vcpu_has_cmpccxadd()   (ctxt->cpuid->feat.cmpccxadd)
 #define vcpu_has_lkgs()        (ctxt->cpuid->feat.lkgs)
 #define vcpu_has_wrmsrns()     (ctxt->cpuid->feat.wrmsrns)
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1126,19 +1126,40 @@ static unsigned long *decode_vex_gpr(
     return decode_gpr(regs, ~vex_reg & (mode_64bit() ? 0xf : 7));
 }
 
-#define avx512_vlen_check(lig) do { \
-    switch ( evex.lr ) \
-    { \
-    default: \
-        generate_exception(X86_EXC_UD); \
-    case 2: \
-        break; \
-    case 0: case 1: \
-        if ( !(lig) ) \
-            host_and_vcpu_must_have(avx512vl); \
-        break; \
-    } \
-} while ( false )
+#define visa_check(subfeat) \
+        generate_exception_if(!cp->feat.avx512 ## subfeat && !cp->feat.avx10, \
+                              X86_EXC_UD)
+
+static bool _vlen_check(
+    const struct x86_emulate_state *s,
+    const struct cpu_policy *cp,
+    bool lig)
+{
+    if ( s->evex.lr > 2 )
+        return false;
+
+    if ( lig )
+        return true;
+
+    if ( cp->feat.avx10 )
+        switch ( s->evex.lr )
+        {
+        case 0:
+        case 1:
+            if ( cp->avx10.vsz256 )
+                return true;
+            /* fall through */
+        case 2:
+            if ( cp->avx10.vsz512 )
+                return true;
+            break;
+        }
+
+    return s->evex.lr == 2 || cp->feat.avx512vl;
+}
+
+#define avx512_vlen_check(lig) \
+        generate_exception_if(!_vlen_check(state, cp, lig), X86_EXC_UD)
 
 static bool is_branch_step(struct x86_emulate_ctxt *ctxt,
                            const struct x86_emulate_ops *ops)
@@ -1370,7 +1391,9 @@ x86_emulate(
         /* KMOV{W,Q} %k, (%rax) */
         stb[0] = 0xc4;
         stb[1] = 0xe1;
-        stb[2] = cpu_has_avx512bw ? 0xf8 : 0x78;
+        stb[2] = cp->feat.avx512bw || cp->feat.avx10
+                 ? 0xf8 /* L0.NP.W1 - kmovq */
+                 : 0x78 /* L0.NP.W0 - kmovw */;
         stb[3] = 0x91;
         stb[4] = evex.opmsk << 3;
         insn_bytes = 5;
@@ -3395,7 +3418,7 @@ x86_emulate(
                                (ea.type != OP_REG && evex.brs &&
                                 (evex.pfx & VEX_PREFIX_SCALAR_MASK))),
                               X86_EXC_UD);
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         if ( ea.type != OP_REG || !evex.brs )
             avx512_vlen_check(evex.pfx & VEX_PREFIX_SCALAR_MASK);
     simd_zmm:
@@ -3451,7 +3474,7 @@ x86_emulate(
         generate_exception_if((evex.lr || evex.opmsk || evex.brs ||
                                evex.w != (evex.pfx & VEX_PREFIX_DOUBLE_MASK)),
                               X86_EXC_UD);
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         if ( (d & DstMask) != DstMem )
             d &= ~TwoOp;
         op_bytes = 8;
@@ -3478,7 +3501,7 @@ x86_emulate(
         generate_exception_if((evex.brs ||
                                evex.w != (evex.pfx & VEX_PREFIX_DOUBLE_MASK)),
                               X86_EXC_UD);
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         avx512_vlen_check(false);
         d |= TwoOp;
         op_bytes = !(evex.pfx & VEX_PREFIX_DOUBLE_MASK) || evex.lr
@@ -3515,7 +3538,7 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x64): /* vpblendm{d,q} [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x65): /* vblendmp{s,d} [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     avx512f_no_sae:
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         generate_exception_if(ea.type != OP_MEM && evex.brs, X86_EXC_UD);
         avx512_vlen_check(false);
         goto simd_zmm;
@@ -3595,13 +3618,13 @@ x86_emulate(
 
     case X86EMUL_OPC_EVEX_F3(5, 0x2a):      /* vcvtsi2sh r/m,xmm,xmm */
     case X86EMUL_OPC_EVEX_F3(5, 0x7b):      /* vcvtusi2sh r/m,xmm,xmm */
-        host_and_vcpu_must_have(avx512_fp16);
+        visa_check(_fp16);
         /* fall through */
     CASE_SIMD_SCALAR_FP(_EVEX, 0x0f, 0x2a): /* vcvtsi2s{s,d} r/m,xmm,xmm */
     CASE_SIMD_SCALAR_FP(_EVEX, 0x0f, 0x7b): /* vcvtusi2s{s,d} r/m,xmm,xmm */
         generate_exception_if(evex.opmsk || (ea.type != OP_REG && evex.brs),
                               X86_EXC_UD);
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         if ( !evex.brs )
             avx512_vlen_check(true);
         get_fpu(X86EMUL_FPU_zmm);
@@ -3711,7 +3734,7 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_F3(5, 0x2d):      /* vcvtsh2si xmm/mem,reg */
     case X86EMUL_OPC_EVEX_F3(5, 0x78):      /* vcvttsh2usi xmm/mem,reg */
     case X86EMUL_OPC_EVEX_F3(5, 0x79):      /* vcvtsh2usi xmm/mem,reg */
-        host_and_vcpu_must_have(avx512_fp16);
+        visa_check(_fp16);
         /* fall through */
     CASE_SIMD_SCALAR_FP(_EVEX, 0x0f, 0x2c): /* vcvtts{s,d}2si xmm/mem,reg */
     CASE_SIMD_SCALAR_FP(_EVEX, 0x0f, 0x2d): /* vcvts{s,d}2si xmm/mem,reg */
@@ -3721,7 +3744,7 @@ x86_emulate(
                                evex.opmsk ||
                                (ea.type != OP_REG && evex.brs)),
                               X86_EXC_UD);
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         if ( !evex.brs )
             avx512_vlen_check(true);
         get_fpu(X86EMUL_FPU_zmm);
@@ -3787,7 +3810,7 @@ x86_emulate(
 
     case X86EMUL_OPC_EVEX(5, 0x2e): /* vucomish xmm/m16,xmm */
     case X86EMUL_OPC_EVEX(5, 0x2f): /* vcomish xmm/m16,xmm */
-        host_and_vcpu_must_have(avx512_fp16);
+        visa_check(_fp16);
         generate_exception_if(evex.w, X86_EXC_UD);
         /* fall through */
     CASE_SIMD_PACKED_FP(_EVEX, 0x0f, 0x2e): /* vucomis{s,d} xmm/mem,xmm */
@@ -3796,7 +3819,7 @@ x86_emulate(
                                (ea.type != OP_REG && evex.brs) ||
                                evex.w != evex.pfx),
                               X86_EXC_UD);
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         if ( !evex.brs )
             avx512_vlen_check(true);
         get_fpu(X86EMUL_FPU_zmm);
@@ -3940,7 +3963,7 @@ x86_emulate(
 
     case X86EMUL_OPC_VEX(0x0f, 0x4a):    /* kadd{w,q} k,k,k */
         if ( !vex.w )
-            host_and_vcpu_must_have(avx512dq);
+            visa_check(dq);
         /* fall through */
     case X86EMUL_OPC_VEX(0x0f, 0x41):    /* kand{w,q} k,k,k */
     case X86EMUL_OPC_VEX_66(0x0f, 0x41): /* kand{b,d} k,k,k */
@@ -3956,11 +3979,12 @@ x86_emulate(
         generate_exception_if(!vex.l, X86_EXC_UD);
     opmask_basic:
         if ( vex.w )
-            host_and_vcpu_must_have(avx512bw);
+            visa_check(bw);
         else if ( vex.pfx )
-            host_and_vcpu_must_have(avx512dq);
+            visa_check(dq);
+        else
+            visa_check(f);
     opmask_common:
-        host_and_vcpu_must_have(avx512f);
         generate_exception_if(!vex.r || (mode_64bit() && !(vex.reg & 8)) ||
                               ea.type != OP_REG, X86_EXC_UD);
 
@@ -3983,13 +4007,14 @@ x86_emulate(
         generate_exception_if(vex.l || vex.reg != 0xf, X86_EXC_UD);
         goto opmask_basic;
 
-    case X86EMUL_OPC_VEX(0x0f, 0x4b):    /* kunpck{w,d}{d,q} k,k,k */
+    case X86EMUL_OPC_VEX(0x0f, 0x4b):    /* kunpck{wd,dq} k,k,k */
         generate_exception_if(!vex.l, X86_EXC_UD);
-        host_and_vcpu_must_have(avx512bw);
+        visa_check(bw);
         goto opmask_common;
 
     case X86EMUL_OPC_VEX_66(0x0f, 0x4b): /* kunpckbw k,k,k */
         generate_exception_if(!vex.l || vex.w, X86_EXC_UD);
+        visa_check(f);
         goto opmask_common;
 
 #endif /* X86EMUL_NO_SIMD */
@@ -4057,7 +4082,7 @@ x86_emulate(
         generate_exception_if((evex.w != (evex.pfx & VEX_PREFIX_DOUBLE_MASK) ||
                                (ea.type != OP_MEM && evex.brs)),
                               X86_EXC_UD);
-        host_and_vcpu_must_have(avx512dq);
+        visa_check(dq);
         avx512_vlen_check(false);
         goto simd_zmm;
 
@@ -4096,12 +4121,12 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_F2(0x0f, 0x7a): /* vcvtudq2ps [xyz]mm/mem,[xyz]mm{k} */
                                           /* vcvtuqq2ps [xyz]mm/mem,{x,y}mm{k} */
         if ( evex.w )
-            host_and_vcpu_must_have(avx512dq);
+            visa_check(dq);
         else
         {
     case X86EMUL_OPC_EVEX(0x0f, 0x78):    /* vcvttp{s,d}2udq [xyz]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX(0x0f, 0x79):    /* vcvtp{s,d}2udq [xyz]mm/mem,[xyz]mm{k} */
-            host_and_vcpu_must_have(avx512f);
+            visa_check(f);
         }
         if ( ea.type != OP_REG || !evex.brs )
             avx512_vlen_check(false);
@@ -4318,7 +4343,7 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x0b): /* vpmulhrsw [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x1c): /* vpabsb [xyz]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x1d): /* vpabsw [xyz]mm/mem,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512bw);
+        visa_check(bw);
         generate_exception_if(evex.brs, X86_EXC_UD);
         elem_bytes = 1 << (b & 1);
         goto avx512f_no_sae;
@@ -4350,7 +4375,7 @@ x86_emulate(
             generate_exception_if(b != 0x27 && evex.w != (b & 1), X86_EXC_UD);
             goto avx512f_no_sae;
         }
-        host_and_vcpu_must_have(avx512bw);
+        visa_check(bw);
         generate_exception_if(evex.brs, X86_EXC_UD);
         elem_bytes = 1 << (ext == ext_0f ? b & 1 : evex.w);
         avx512_vlen_check(false);
@@ -4423,7 +4448,7 @@ x86_emulate(
             dst.bytes = 2;
         /* fall through */
     case X86EMUL_OPC_EVEX_66(5, 0x6e): /* vmovw r/m16,xmm */
-        host_and_vcpu_must_have(avx512_fp16);
+        visa_check(_fp16);
         generate_exception_if(evex.w, X86_EXC_UD);
         /* fall through */
     case X86EMUL_OPC_EVEX_66(0x0f, 0x6e): /* vmov{d,q} r/m,xmm */
@@ -4431,7 +4456,7 @@ x86_emulate(
         generate_exception_if((evex.lr || evex.opmsk || evex.brs ||
                                evex.reg != 0xf || !evex.RX),
                               X86_EXC_UD);
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         get_fpu(X86EMUL_FPU_zmm);
 
         opc = init_evex(stub);
@@ -4489,7 +4514,7 @@ x86_emulate(
 
     case X86EMUL_OPC_EVEX_F2(0x0f, 0x6f): /* vmovdqu{8,16} [xyz]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_F2(0x0f, 0x7f): /* vmovdqu{8,16} [xyz]mm,[xyz]mm/mem{k} */
-        host_and_vcpu_must_have(avx512bw);
+        visa_check(bw);
         elem_bytes = 1 << evex.w;
         goto vmovdqa;
 
@@ -4582,7 +4607,7 @@ x86_emulate(
             generate_exception_if(evex.w, X86_EXC_UD);
         else
         {
-            host_and_vcpu_must_have(avx512bw);
+            visa_check(bw);
             generate_exception_if(evex.brs, X86_EXC_UD);
         }
         d = (d & ~SrcMask) | SrcMem | TwoOp;
@@ -4830,7 +4855,7 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_F3(0x0f, 0xe6):   /* vcvtdq2pd {x,y}mm/mem,[xyz]mm{k} */
                                             /* vcvtqq2pd [xyz]mm/mem,[xyz]mm{k} */
         if ( evex.pfx != vex_f3 )
-            host_and_vcpu_must_have(avx512f);
+            visa_check(f);
         else if ( evex.w )
         {
     case X86EMUL_OPC_EVEX_66(0x0f, 0x78):   /* vcvttps2uqq {x,y}mm/mem,[xyz]mm{k} */
@@ -4841,11 +4866,11 @@ x86_emulate(
                                             /* vcvttpd2qq [xyz]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f, 0x7b):   /* vcvtps2qq {x,y}mm/mem,[xyz]mm{k} */
                                             /* vcvtpd2qq [xyz]mm/mem,[xyz]mm{k} */
-            host_and_vcpu_must_have(avx512dq);
+            visa_check(dq);
         }
         else
         {
-            host_and_vcpu_must_have(avx512f);
+            visa_check(f);
             generate_exception_if(ea.type != OP_MEM && evex.brs, X86_EXC_UD);
         }
         if ( ea.type != OP_REG || !evex.brs )
@@ -4883,7 +4908,7 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_66(0x0f, 0xd6): /* vmovq xmm,xmm/m64 */
         generate_exception_if(evex.lr || !evex.w || evex.opmsk || evex.brs,
                               X86_EXC_UD);
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         d |= TwoOp;
         op_bytes = 8;
         goto simd_zmm;
@@ -4909,19 +4934,21 @@ x86_emulate(
     case X86EMUL_OPC_VEX(0x0f, 0x90):    /* kmov{w,q} k/mem,k */
     case X86EMUL_OPC_VEX_66(0x0f, 0x90): /* kmov{b,d} k/mem,k */
         generate_exception_if(vex.l || !vex.r, X86_EXC_UD);
-        host_and_vcpu_must_have(avx512f);
         if ( vex.w )
         {
-            host_and_vcpu_must_have(avx512bw);
+            visa_check(bw);
             op_bytes = 4 << !vex.pfx;
         }
         else if ( vex.pfx )
         {
-            host_and_vcpu_must_have(avx512dq);
+            visa_check(dq);
             op_bytes = 1;
         }
         else
+        {
+            visa_check(f);
             op_bytes = 2;
+        }
 
         get_fpu(X86EMUL_FPU_opmask);
 
@@ -4943,14 +4970,15 @@ x86_emulate(
         generate_exception_if(vex.l || !vex.r || vex.reg != 0xf ||
                               ea.type != OP_REG, X86_EXC_UD);
 
-        host_and_vcpu_must_have(avx512f);
         if ( vex.pfx == vex_f2 )
-            host_and_vcpu_must_have(avx512bw);
+            visa_check(bw);
         else
         {
             generate_exception_if(vex.w, X86_EXC_UD);
             if ( vex.pfx )
-                host_and_vcpu_must_have(avx512dq);
+                visa_check(dq);
+            else
+                visa_check(f);
         }
 
         get_fpu(X86EMUL_FPU_opmask);
@@ -4982,10 +5010,9 @@ x86_emulate(
         dst = ea;
         dst.reg = decode_gpr(&_regs, modrm_reg);
 
-        host_and_vcpu_must_have(avx512f);
         if ( vex.pfx == vex_f2 )
         {
-            host_and_vcpu_must_have(avx512bw);
+            visa_check(bw);
             dst.bytes = 4 << (mode_64bit() && vex.w);
         }
         else
@@ -4993,7 +5020,9 @@ x86_emulate(
             generate_exception_if(vex.w, X86_EXC_UD);
             dst.bytes = 4;
             if ( vex.pfx )
-                host_and_vcpu_must_have(avx512dq);
+                visa_check(dq);
+            else
+                visa_check(f);
         }
 
         get_fpu(X86EMUL_FPU_opmask);
@@ -5015,20 +5044,18 @@ x86_emulate(
         ASSERT(!state->simd_size);
         break;
 
-    case X86EMUL_OPC_VEX(0x0f, 0x99):    /* ktest{w,q} k,k */
-        if ( !vex.w )
-            host_and_vcpu_must_have(avx512dq);
-        /* fall through */
     case X86EMUL_OPC_VEX(0x0f, 0x98):    /* kortest{w,q} k,k */
     case X86EMUL_OPC_VEX_66(0x0f, 0x98): /* kortest{b,d} k,k */
+    case X86EMUL_OPC_VEX(0x0f, 0x99):    /* ktest{w,q} k,k */
     case X86EMUL_OPC_VEX_66(0x0f, 0x99): /* ktest{b,d} k,k */
         generate_exception_if(vex.l || !vex.r || vex.reg != 0xf ||
                               ea.type != OP_REG, X86_EXC_UD);
-        host_and_vcpu_must_have(avx512f);
         if ( vex.w )
-            host_and_vcpu_must_have(avx512bw);
-        else if ( vex.pfx )
-            host_and_vcpu_must_have(avx512dq);
+            visa_check(bw);
+        else if ( vex.pfx || (b & 1) )
+            visa_check(dq);
+        else
+            visa_check(f);
 
         get_fpu(X86EMUL_FPU_opmask);
 
@@ -5366,7 +5393,7 @@ x86_emulate(
                                 (evex.pfx & VEX_PREFIX_SCALAR_MASK)) ||
                                !evex.r || !evex.R || evex.z),
                               X86_EXC_UD);
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         if ( ea.type != OP_REG || !evex.brs )
             avx512_vlen_check(evex.pfx & VEX_PREFIX_SCALAR_MASK);
     simd_imm8_zmm:
@@ -5410,9 +5437,9 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x22): /* vpinsr{d,q} $imm8,r/m,xmm,xmm */
         generate_exception_if(evex.lr || evex.opmsk || evex.brs, X86_EXC_UD);
         if ( b & 2 )
-            host_and_vcpu_must_have(avx512dq);
+            visa_check(dq);
         else
-            host_and_vcpu_must_have(avx512bw);
+            visa_check(bw);
         if ( !mode_64bit() )
             evex.w = 0;
         memcpy(mmvalp, &src.val, src.bytes);
@@ -5449,7 +5476,7 @@ x86_emulate(
         /* fall through */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x25): /* vpternlog{d,q} $imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     avx512f_imm8_no_sae:
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         generate_exception_if(ea.type != OP_MEM && evex.brs, X86_EXC_UD);
         avx512_vlen_check(false);
         goto simd_imm8_zmm;
@@ -5548,7 +5575,7 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_66(0x0f, 0xe4): /* vpmulhuw [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f, 0xea): /* vpminsw [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f, 0xee): /* vpmaxsw [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512bw);
+        visa_check(bw);
         generate_exception_if(evex.brs, X86_EXC_UD);
         elem_bytes = b & 0x10 ? 1 : 2;
         goto avx512f_no_sae;
@@ -5773,7 +5800,7 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x10): /* vpsrlvw [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x11): /* vpsravw [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x12): /* vpsllvw [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512bw);
+        visa_check(bw);
         generate_exception_if(!evex.w || evex.brs, X86_EXC_UD);
         elem_bytes = 2;
         goto avx512f_no_sae;
@@ -5783,7 +5810,7 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_F3(0x0f38, 0x20): /* vpmovswb [xyz]mm,{x,y}mm/mem{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x30): /* vpmovzxbw {x,y}mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_F3(0x0f38, 0x30): /* vpmovwb [xyz]mm,{x,y}mm/mem{k} */
-        host_and_vcpu_must_have(avx512bw);
+        visa_check(bw);
         if ( evex.pfx != vex_f3 )
         {
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x21): /* vpmovsxbd xmm/mem,[xyz]mm{k} */
@@ -5831,7 +5858,7 @@ x86_emulate(
 
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x13): /* vcvtph2ps {x,y}mm/mem,[xyz]mm{k} */
         generate_exception_if(evex.w || (ea.type != OP_REG && evex.brs), X86_EXC_UD);
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         if ( !evex.brs )
             avx512_vlen_check(false);
         op_bytes = 8 << evex.lr;
@@ -5885,7 +5912,7 @@ x86_emulate(
             op_bytes = 8;
         generate_exception_if(evex.brs, X86_EXC_UD);
         if ( !evex.w )
-            host_and_vcpu_must_have(avx512dq);
+            visa_check(dq);
         goto avx512_broadcast;
 
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x1a): /* vbroadcastf32x4 m128,{y,z}mm{k} */
@@ -5895,7 +5922,7 @@ x86_emulate(
         generate_exception_if(ea.type != OP_MEM || !evex.lr || evex.brs,
                               X86_EXC_UD);
         if ( evex.w )
-            host_and_vcpu_must_have(avx512dq);
+            visa_check(dq);
         goto avx512_broadcast;
 
     case X86EMUL_OPC_VEX_66(0x0f38, 0x20): /* vpmovsxbw xmm/mem,{x,y}mm */
@@ -5920,9 +5947,9 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_F3(0x0f38, 0x28): /* vpmovm2{b,w} k,[xyz]mm */
     case X86EMUL_OPC_EVEX_F3(0x0f38, 0x38): /* vpmovm2{d,q} k,[xyz]mm */
         if ( b & 0x10 )
-            host_and_vcpu_must_have(avx512dq);
+            visa_check(dq);
         else
-            host_and_vcpu_must_have(avx512bw);
+            visa_check(bw);
         generate_exception_if(evex.opmsk || ea.type != OP_REG, X86_EXC_UD);
         d |= TwoOp;
         op_bytes = 16 << evex.lr;
@@ -5965,7 +5992,7 @@ x86_emulate(
         fault_suppression = false;
         /* fall through */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x44): /* vplzcnt{d,q} [xyz]mm/mem,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512cd);
+        visa_check(cd);
         goto avx512f_no_sae;
 
     case X86EMUL_OPC_VEX_66(0x0f38, 0x2c): /* vmaskmovps mem,{x,y}mm,{x,y}mm */
@@ -6041,7 +6068,7 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_66(0x0f38, 0xba): /* vfmsub231p{s,d} [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0xbc): /* vfnmadd231p{s,d} [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0xbe): /* vfnmsub231p{s,d} [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         if ( ea.type != OP_REG || !evex.brs )
             avx512_vlen_check(false);
         goto simd_zmm;
@@ -6060,7 +6087,7 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_66(0x0f38, 0xbb): /* vfmsub231s{s,d} xmm/mem,xmm,xmm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0xbd): /* vfnmadd231s{s,d} xmm/mem,xmm,xmm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0xbf): /* vfnmsub231s{s,d} xmm/mem,xmm,xmm{k} */
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         generate_exception_if(ea.type != OP_REG && evex.brs, X86_EXC_UD);
         if ( !evex.brs )
             avx512_vlen_check(true);
@@ -6074,14 +6101,14 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x3a): /* vpminuw [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x3c): /* vpmaxsb [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x3e): /* vpmaxuw [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512bw);
+        visa_check(bw);
         generate_exception_if(evex.brs, X86_EXC_UD);
         elem_bytes = b & 2 ?: 1;
         goto avx512f_no_sae;
 
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x40): /* vpmull{d,q} [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
         if ( evex.w )
-            host_and_vcpu_must_have(avx512dq);
+            visa_check(dq);
         goto avx512f_no_sae;
 
     case X86EMUL_OPC_66(0x0f38, 0xdb):     /* aesimc xmm/m128,xmm */
@@ -6121,7 +6148,7 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x51): /* vpdpbusds [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x52): /* vpdpwssd [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x53): /* vpdpwssds [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512_vnni);
+        visa_check(_vnni);
         generate_exception_if(evex.w, X86_EXC_UD);
         goto avx512f_no_sae;
 
@@ -6133,7 +6160,7 @@ x86_emulate(
             d |= TwoOp;
         /* fall through */
     case X86EMUL_OPC_EVEX_F3(0x0f38, 0x52): /* vdpbf16ps [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512_bf16);
+        visa_check(_bf16);
         generate_exception_if(evex.w, X86_EXC_UD);
         op_bytes = 16 << evex.lr;
         goto avx512f_no_sae;
@@ -6150,7 +6177,7 @@ x86_emulate(
 
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x4d): /* vrcp14s{s,d} xmm/mem,xmm,xmm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x4f): /* vrsqrt14s{s,d} xmm/mem,xmm,xmm{k} */
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         generate_exception_if(evex.brs, X86_EXC_UD);
         avx512_vlen_check(true);
         goto simd_zmm;
@@ -6159,16 +6186,16 @@ x86_emulate(
         generate_exception_if(evex.w || !evex.r || !evex.R || evex.z, X86_EXC_UD);
         /* fall through */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x54): /* vpopcnt{b,w} [xyz]mm/mem,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512_bitalg);
+        visa_check(_bitalg);
         /* fall through */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x66): /* vpblendm{b,w} [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512bw);
+        visa_check(bw);
         generate_exception_if(evex.brs, X86_EXC_UD);
         elem_bytes = 1 << evex.w;
         goto avx512f_no_sae;
 
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x55): /* vpopcnt{d,q} [xyz]mm/mem,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512_vpopcntdq);
+        visa_check(_vpopcntdq);
         goto avx512f_no_sae;
 
     case X86EMUL_OPC_VEX_66(0x0f38, 0x5a): /* vbroadcasti128 m128,ymm */
@@ -6177,14 +6204,14 @@ x86_emulate(
 
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x62): /* vpexpand{b,w} [xyz]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x63): /* vpcompress{b,w} [xyz]mm,[xyz]mm/mem{k} */
-        host_and_vcpu_must_have(avx512_vbmi2);
+        visa_check(_vbmi2);
         elem_bytes = 1 << evex.w;
         /* fall through */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x88): /* vexpandp{s,d} [xyz]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x89): /* vpexpand{d,q} [xyz]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x8a): /* vcompressp{s,d} [xyz]mm,[xyz]mm/mem{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x8b): /* vpcompress{d,q} [xyz]mm,[xyz]mm/mem{k} */
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         generate_exception_if(evex.brs, X86_EXC_UD);
         avx512_vlen_check(false);
         /*
@@ -6218,7 +6245,7 @@ x86_emulate(
         /* fall through */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x71): /* vpshldv{d,q} [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x73): /* vpshrdv{d,q} [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512_vbmi2);
+        visa_check(_vbmi2);
         goto avx512f_no_sae;
 
     case X86EMUL_OPC_VEX   (0x0f38, 0xb0): /* vcvtneoph2ps mem,[xy]mm */
@@ -6238,16 +6265,16 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x7d): /* vpermt2{b,w} [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x8d): /* vperm{b,w} [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
         if ( !evex.w )
-            host_and_vcpu_must_have(avx512_vbmi);
+            visa_check(_vbmi);
         else
-            host_and_vcpu_must_have(avx512bw);
+            visa_check(bw);
         generate_exception_if(evex.brs, X86_EXC_UD);
         fault_suppression = false;
         goto avx512f_no_sae;
 
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x78): /* vpbroadcastb xmm/m8,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x79): /* vpbroadcastw xmm/m16,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512bw);
+        visa_check(bw);
         generate_exception_if(evex.w || evex.brs, X86_EXC_UD);
         op_bytes = elem_bytes = 1 << (b & 1);
         /* See the comment at the avx512_broadcast label. */
@@ -6256,14 +6283,14 @@ x86_emulate(
 
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x7a): /* vpbroadcastb r32,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x7b): /* vpbroadcastw r32,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512bw);
+        visa_check(bw);
         generate_exception_if(evex.w, X86_EXC_UD);
         /* fall through */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x7c): /* vpbroadcast{d,q} reg,[xyz]mm{k} */
         generate_exception_if((ea.type != OP_REG || evex.brs ||
                                evex.reg != 0xf || !evex.RX),
                               X86_EXC_UD);
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         avx512_vlen_check(false);
         get_fpu(X86EMUL_FPU_zmm);
 
@@ -6332,7 +6359,7 @@ x86_emulate(
 
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x83): /* vpmultishiftqb [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
         generate_exception_if(!evex.w, X86_EXC_UD);
-        host_and_vcpu_must_have(avx512_vbmi);
+        visa_check(_vbmi);
         fault_suppression = false;
         goto avx512f_no_sae;
 
@@ -6490,8 +6517,8 @@ x86_emulate(
                                evex.reg != 0xf ||
                                modrm_reg == state->sib_index),
                               X86_EXC_UD);
+        visa_check(f);
         avx512_vlen_check(false);
-        host_and_vcpu_must_have(avx512f);
         get_fpu(X86EMUL_FPU_zmm);
 
         /* Read destination and index registers. */
@@ -6652,8 +6679,8 @@ x86_emulate(
                                evex.reg != 0xf ||
                                modrm_reg == state->sib_index),
                               X86_EXC_UD);
+        visa_check(f);
         avx512_vlen_check(false);
-        host_and_vcpu_must_have(avx512f);
         get_fpu(X86EMUL_FPU_zmm);
 
         /* Read source and index registers. */
@@ -6769,7 +6796,7 @@ x86_emulate(
 
     case X86EMUL_OPC_EVEX_66(0x0f38, 0xb4): /* vpmadd52luq [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0xb5): /* vpmadd52huq [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512_ifma);
+        visa_check(_ifma);
         generate_exception_if(!evex.w, X86_EXC_UD);
         goto avx512f_no_sae;
 
@@ -7239,7 +7266,7 @@ x86_emulate(
         /* fall through */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x08): /* vrndscaleps $imm8,[xyz]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x09): /* vrndscalepd $imm8,[xyz]mm/mem,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         generate_exception_if(evex.w != (b & 1), X86_EXC_UD);
         avx512_vlen_check(b & 2);
         goto simd_imm8_zmm;
@@ -7248,7 +7275,7 @@ x86_emulate(
         generate_exception_if(ea.type != OP_REG && evex.brs, X86_EXC_UD);
         /* fall through */
     case X86EMUL_OPC_EVEX(0x0f3a, 0x08): /* vrndscaleph $imm8,[xyz]mm/mem,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512_fp16);
+        visa_check(_fp16);
         generate_exception_if(evex.w, X86_EXC_UD);
         avx512_vlen_check(b & 2);
         goto simd_imm8_zmm;
@@ -7361,11 +7388,11 @@ x86_emulate(
                                evex.opmsk || evex.brs),
                               X86_EXC_UD);
         if ( !(b & 2) )
-            host_and_vcpu_must_have(avx512bw);
+            visa_check(bw);
         else if ( !(b & 1) )
-            host_and_vcpu_must_have(avx512dq);
+            visa_check(dq);
         else
-            host_and_vcpu_must_have(avx512f);
+            visa_check(f);
         get_fpu(X86EMUL_FPU_zmm);
         opc = init_evex(stub);
         goto pextr;
@@ -7379,7 +7406,7 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x39): /* vextracti32x4 $imm8,{y,z}mm,xmm/m128{k} */
                                             /* vextracti64x2 $imm8,{y,z}mm,xmm/m128{k} */
         if ( evex.w )
-            host_and_vcpu_must_have(avx512dq);
+            visa_check(dq);
         generate_exception_if(evex.brs, X86_EXC_UD);
         /* fall through */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x23): /* vshuff32x4 $imm8,{y,z}mm/mem,{y,z}mm,{y,z}mm{k} */
@@ -7399,7 +7426,7 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x3b): /* vextracti32x8 $imm8,zmm,ymm/m256{k} */
                                             /* vextracti64x4 $imm8,zmm,ymm/m256{k} */
         if ( !evex.w )
-            host_and_vcpu_must_have(avx512dq);
+            visa_check(dq);
         generate_exception_if(evex.lr != 2 || evex.brs, X86_EXC_UD);
         fault_suppression = false;
         goto avx512f_imm8_no_sae;
@@ -7415,7 +7442,7 @@ x86_emulate(
             generate_exception_if((evex.w || evex.reg != 0xf || !evex.RX ||
                                    (ea.type != OP_REG && (evex.z || evex.brs))),
                                   X86_EXC_UD);
-            host_and_vcpu_must_have(avx512f);
+            visa_check(f);
             avx512_vlen_check(false);
             opc = init_evex(stub);
         }
@@ -7507,7 +7534,7 @@ x86_emulate(
         if ( !(b & 0x20) )
             goto avx512f_imm8_no_sae;
     avx512bw_imm:
-        host_and_vcpu_must_have(avx512bw);
+        visa_check(bw);
         generate_exception_if(evex.brs, X86_EXC_UD);
         elem_bytes = 1 << evex.w;
         avx512_vlen_check(false);
@@ -7546,7 +7573,7 @@ x86_emulate(
         goto simd_0f_imm8_avx;
 
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x21): /* vinsertps $imm8,xmm/m32,xmm,xmm */
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         generate_exception_if(evex.lr || evex.w || evex.opmsk || evex.brs,
                               X86_EXC_UD);
         op_bytes = 4;
@@ -7554,18 +7581,18 @@ x86_emulate(
 
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x50): /* vrangep{s,d} $imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x56): /* vreducep{s,d} $imm8,[xyz]mm/mem,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512dq);
+        visa_check(dq);
         /* fall through */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x26): /* vgetmantp{s,d} $imm8,[xyz]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x54): /* vfixupimmp{s,d} $imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         if ( ea.type != OP_REG || !evex.brs )
             avx512_vlen_check(false);
         goto simd_imm8_zmm;
 
     case X86EMUL_OPC_EVEX(0x0f3a, 0x26): /* vgetmantph $imm8,[xyz]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX(0x0f3a, 0x56): /* vreduceph $imm8,[xyz]mm/mem,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512_fp16);
+        visa_check(_fp16);
         generate_exception_if(evex.w, X86_EXC_UD);
         if ( ea.type != OP_REG || !evex.brs )
             avx512_vlen_check(false);
@@ -7573,11 +7600,11 @@ x86_emulate(
 
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x51): /* vranges{s,d} $imm8,xmm/mem,xmm,xmm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x57): /* vreduces{s,d} $imm8,xmm/mem,xmm,xmm{k} */
-        host_and_vcpu_must_have(avx512dq);
+        visa_check(dq);
         /* fall through */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x27): /* vgetmants{s,d} $imm8,xmm/mem,xmm,xmm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x55): /* vfixupimms{s,d} $imm8,xmm/mem,xmm,xmm{k} */
-        host_and_vcpu_must_have(avx512f);
+        visa_check(f);
         generate_exception_if(ea.type != OP_REG && evex.brs, X86_EXC_UD);
         if ( !evex.brs )
             avx512_vlen_check(true);
@@ -7585,7 +7612,7 @@ x86_emulate(
 
     case X86EMUL_OPC_EVEX(0x0f3a, 0x27): /* vgetmantsh $imm8,xmm/mem,xmm,xmm{k} */
     case X86EMUL_OPC_EVEX(0x0f3a, 0x57): /* vreducesh $imm8,xmm/mem,xmm,xmm{k} */
-        host_and_vcpu_must_have(avx512_fp16);
+        visa_check(_fp16);
         generate_exception_if(evex.w, X86_EXC_UD);
         if ( !evex.brs )
             avx512_vlen_check(true);
@@ -7596,18 +7623,19 @@ x86_emulate(
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x30): /* kshiftr{b,w} $imm8,k,k */
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x32): /* kshiftl{b,w} $imm8,k,k */
         if ( !vex.w )
-            host_and_vcpu_must_have(avx512dq);
+            visa_check(dq);
+        else
+            visa_check(f);
     opmask_shift_imm:
         generate_exception_if(vex.l || !vex.r || vex.reg != 0xf ||
                               ea.type != OP_REG, X86_EXC_UD);
-        host_and_vcpu_must_have(avx512f);
         get_fpu(X86EMUL_FPU_opmask);
         op_bytes = 1; /* Any non-zero value will do. */
         goto simd_0f_imm8;
 
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x31): /* kshiftr{d,q} $imm8,k,k */
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x33): /* kshiftl{d,q} $imm8,k,k */
-        host_and_vcpu_must_have(avx512bw);
+        visa_check(bw);
         goto opmask_shift_imm;
 
     case X86EMUL_OPC_66(0x0f3a, 0x44):     /* pclmulqdq $imm8,xmm/m128,xmm */
@@ -7748,7 +7776,7 @@ x86_emulate(
 
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x66): /* vfpclassp{s,d} $imm8,[xyz]mm/mem,k{k} */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x67): /* vfpclasss{s,d} $imm8,xmm/mem,k{k} */
-        host_and_vcpu_must_have(avx512dq);
+        visa_check(dq);
         generate_exception_if(!evex.r || !evex.R || evex.z, X86_EXC_UD);
         if ( !(b & 1) )
             goto avx512f_imm8_no_sae;
@@ -7758,7 +7786,7 @@ x86_emulate(
 
     case X86EMUL_OPC_EVEX(0x0f3a, 0x66): /* vfpclassph $imm8,[xyz]mm/mem,k{k} */
     case X86EMUL_OPC_EVEX(0x0f3a, 0x67): /* vfpclasssh $imm8,xmm/mem,k{k} */
-        host_and_vcpu_must_have(avx512_fp16);
+        visa_check(_fp16);
         generate_exception_if(evex.w || !evex.r || !evex.R || evex.z, X86_EXC_UD);
         if ( !(b & 1) )
             goto avx512f_imm8_no_sae;
@@ -7773,14 +7801,14 @@ x86_emulate(
         /* fall through */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x71): /* vpshld{d,q} $imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x73): /* vpshrd{d,q} $imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512_vbmi2);
+        visa_check(_vbmi2);
         goto avx512f_imm8_no_sae;
 
     case X86EMUL_OPC_EVEX_F3(0x0f3a, 0xc2): /* vcmpsh $imm8,xmm/mem,xmm,k{k} */
         generate_exception_if(ea.type != OP_REG && evex.brs, X86_EXC_UD);
         /* fall through */
     case X86EMUL_OPC_EVEX(0x0f3a, 0xc2): /* vcmpph $imm8,[xyz]mm/mem,[xyz]mm,k{k} */
-        host_and_vcpu_must_have(avx512_fp16);
+        visa_check(_fp16);
         generate_exception_if(evex.w || !evex.r || !evex.R || evex.z, X86_EXC_UD);
         if ( ea.type != OP_REG || !evex.brs )
             avx512_vlen_check(evex.pfx & VEX_PREFIX_SCALAR_MASK);
@@ -7856,13 +7884,13 @@ x86_emulate(
     CASE_SIMD_SINGLE_FP(_EVEX, 5, 0x5d): /* vmin{p,s}h [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     CASE_SIMD_SINGLE_FP(_EVEX, 5, 0x5e): /* vdiv{p,s}h [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     CASE_SIMD_SINGLE_FP(_EVEX, 5, 0x5f): /* vmax{p,s}h [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512_fp16);
+        visa_check(_fp16);
         generate_exception_if(evex.w, X86_EXC_UD);
         goto avx512f_all_fp;
 
     CASE_SIMD_ALL_FP(_EVEX, 5, 0x5a):  /* vcvtp{h,d}2p{h,d} [xyz]mm/mem,[xyz]mm{k} */
                                        /* vcvts{h,d}2s{h,d} xmm/mem,xmm,xmm{k} */
-        host_and_vcpu_must_have(avx512_fp16);
+        visa_check(_fp16);
         if ( vex.pfx & VEX_PREFIX_SCALAR_MASK )
             d &= ~TwoOp;
         op_bytes = 2 << (((evex.pfx & VEX_PREFIX_SCALAR_MASK) ? 0 : 1 + evex.lr) +
@@ -7873,7 +7901,7 @@ x86_emulate(
                                        /* vcvtqq2ph [xyz]mm/mem,xmm{k} */
     case X86EMUL_OPC_EVEX_F2(5, 0x7a): /* vcvtudq2ph [xyz]mm/mem,[xy]mm{k} */
                                        /* vcvtuqq2ph [xyz]mm/mem,xmm{k} */
-        host_and_vcpu_must_have(avx512_fp16);
+        visa_check(_fp16);
         if ( ea.type != OP_REG || !evex.brs )
             avx512_vlen_check(false);
         op_bytes = 16 << evex.lr;
@@ -7883,7 +7911,7 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_F3(5, 0x5b): /* vcvttph2dq [xy]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX   (5, 0x78): /* vcvttph2udq [xy]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX   (5, 0x79): /* vcvtph2udq [xy]mm/mem,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512_fp16);
+        visa_check(_fp16);
         generate_exception_if(evex.w, X86_EXC_UD);
         if ( ea.type != OP_REG || !evex.brs )
             avx512_vlen_check(false);
@@ -7894,7 +7922,7 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_66(5, 0x79): /* vcvtph2uqq xmm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(5, 0x7a): /* vcvttph2qq xmm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(5, 0x7b): /* vcvtph2qq xmm/mem,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512_fp16);
+        visa_check(_fp16);
         generate_exception_if(evex.w, X86_EXC_UD);
         if ( ea.type != OP_REG || !evex.brs )
             avx512_vlen_check(false);
@@ -7931,7 +7959,7 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_66(6, 0xba): /* vfmsub231ph [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(6, 0xbc): /* vfnmadd231ph [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(6, 0xbe): /* vfnmsub231ph [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512_fp16);
+        visa_check(_fp16);
         generate_exception_if(evex.w, X86_EXC_UD);
         if ( ea.type != OP_REG || !evex.brs )
             avx512_vlen_check(false);
@@ -7953,7 +7981,7 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_66(6, 0xbb): /* vfmsub231sh xmm/m16,xmm,xmm{k} */
     case X86EMUL_OPC_EVEX_66(6, 0xbd): /* vfnmadd231sh xmm/m16,xmm,xmm{k} */
     case X86EMUL_OPC_EVEX_66(6, 0xbf): /* vfnmsub231sh xmm/m16,xmm,xmm{k} */
-        host_and_vcpu_must_have(avx512_fp16);
+        visa_check(_fp16);
         generate_exception_if(evex.w || (ea.type != OP_REG && evex.brs),
                               X86_EXC_UD);
         if ( !evex.brs )
@@ -7962,13 +7990,13 @@ x86_emulate(
 
     case X86EMUL_OPC_EVEX_66(6, 0x4c): /* vrcpph [xyz]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(6, 0x4e): /* vrsqrtph [xyz]mm/mem,[xyz]mm{k} */
-        host_and_vcpu_must_have(avx512_fp16);
+        visa_check(_fp16);
         generate_exception_if(evex.w, X86_EXC_UD);
         goto avx512f_no_sae;
 
     case X86EMUL_OPC_EVEX_66(6, 0x4d): /* vrcpsh xmm/m16,xmm,xmm{k} */
     case X86EMUL_OPC_EVEX_66(6, 0x4f): /* vrsqrtsh xmm/m16,xmm,xmm{k} */
-        host_and_vcpu_must_have(avx512_fp16);
+        visa_check(_fp16);
         generate_exception_if(evex.w || evex.brs, X86_EXC_UD);
         avx512_vlen_check(true);
         goto simd_zmm;
@@ -7986,7 +8014,7 @@ x86_emulate(
     {
         unsigned int src1 = ~evex.reg;
 
-        host_and_vcpu_must_have(avx512_fp16);
+        visa_check(_fp16);
         generate_exception_if(evex.w || ((b & 1) && ea.type != OP_REG && evex.brs),
                               X86_EXC_UD);
         if ( mode_64bit() )
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -795,7 +795,7 @@ static void __init noinline xstate_check
     if ( cpu_has_mpx )
         check_new_xstate(&s, X86_XCR0_BNDCSR | X86_XCR0_BNDREGS);
 
-    if ( cpu_has_avx512f )
+    if ( boot_cpu_has(X86_FEATURE_AVX512F) || boot_cpu_has(X86_FEATURE_AVX10) )
         check_new_xstate(&s, X86_XCR0_HI_ZMM | X86_XCR0_ZMM | X86_XCR0_OPMASK);
 
     /*
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -355,7 +355,7 @@ XEN_CPUFEATURE(UTMR,               15*32
 XEN_CPUFEATURE(PREFETCHI,          15*32+14) /*A  PREFETCHIT{0,1} Instructions */
 XEN_CPUFEATURE(USER_MSR,           15*32+15) /*s  U{RD,WR}MSR Instructions */
 XEN_CPUFEATURE(CET_SSS,            15*32+18) /*   CET Supervisor Shadow Stacks safe to use */
-XEN_CPUFEATURE(AVX10,              15*32+19) /*   AVX10 Converged Vector ISA */
+XEN_CPUFEATURE(AVX10,              15*32+19) /*a  AVX10 Converged Vector ISA */
 
 /* Intel-defined CPU features, MSR_ARCH_CAPS 0x10a.eax, word 16 */
 XEN_CPUFEATURE(RDCL_NO,            16*32+ 0) /*A  No Rogue Data Cache Load (Meltdown) */



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:12:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:12:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854283.1267525 (Exim 4.92)
	(envelope-from )
	id 1tLJhn-00050c-Gf; Wed, 11 Dec 2024 10:12:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854283.1267525; Wed, 11 Dec 2024 10:12: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 1tLJhn-00050V-E8; Wed, 11 Dec 2024 10:12:31 +0000
Received: by outflank-mailman (input) for mailman id 854283;
 Wed, 11 Dec 2024 10:12:29 +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 1tLJhl-0003z3-OZ
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:12:29 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 69d981eb-b7a8-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 11:12:23 +0100 (CET)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3862f32a33eso2182391f8f.3
 for ; Wed, 11 Dec 2024 02:12: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
 98e67ed59e1d1-2ef68c07bfcsm9657745a91.12.2024.12.11.02.12.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:12: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: 69d981eb-b7a8-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733911947; x=1734516747; 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=ZqFYw/nizVXDm7kHbUCaTgxJOMEM5PPDM0bi8pFmXx4=;
        b=IOtFSqR1Eul+3lfMhZFJ+muVvqs3eRz6aBpzDN+G4y3jpP1jWyKMR0uDVi8nQoi5/b
         jcUY3E/pVl1jiV/fmjlT3EOQ1X2o8HJZkSnOLQbQk+nmRk5AJ553v5osqzlgnfAJKBS4
         /oVFFjHwb/vHke9NgJI39fcajUyzzTRrBDf7pfHMve45dayLKTJrV6wrXs+vOVJYGURR
         2J9mi8FKcxpDpSoZFZGS4ldvOOJP7rawPDEsKuFrIMXkzQmr2qBloJBfmf+9O8PsLA+m
         esQ87LmNUl/vK9NiPaD9n3qi14oxrTRBfwQHiZ2BoMEOjup+vrMEAFNjqPqvVxPmKmS/
         6cdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733911947; x=1734516747;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=ZqFYw/nizVXDm7kHbUCaTgxJOMEM5PPDM0bi8pFmXx4=;
        b=er6acMPSlMqs/0uaQ+k81njNF3yIIIcy7FZm6nfVnUbV7z3VJlRfHM42japvkmrZN0
         g3Ibs0gj1Tp0iM5OHo93LX1Oa38U3coDXZhiBy89hEqLPDcIg9WK9LuCjzEyInVSIjHd
         CCZJDZMBeQQ/+BjwemChi3sDPSDpKvPeBxW7Gai0tDjQb6C7z06rIcfuTH0iG6Fbw7wI
         LmJRah+mhtc5Wqkg8IXgZobOwuogjjgNy2Rz/aUe2qjmj+zjgfe8sUV+4n/h3eaxIRvy
         +102ziDO9KkDGxn3LXKuvJ5/vP5/wR+ssxZKhMbkRid1jkxzrwWW4wOSeRCIFn27W2WA
         86cg==
X-Gm-Message-State: AOJu0YxaU14yEP+zuh1gh9E3sC66eky/diCwthEB09540i/E/eWmPiOW
	oK85ap0/M2LnBhaO0fjs3sIm7LrauGT1kJ7u95tSMUsDpko4mo4Z66dWEDllIJqCnTJumA2efCI
	=
X-Gm-Gg: ASbGncv4bdnW5TjxCV7oqZmf8JlH8SBSSpMhVzmz12KV1KOQ0HqC0KrztbG9/Rp2s+G
	3yfOILtSEyfkDL16pVogLamm69JhZk45vdKzmjlkpp/Ku+hpwLRZBRDr20jcpLZ25y5fFLRpmJx
	Lbtxdi5yXNHmbtKFDXvivWeU+PbruMgwLTWMnY80bhk/TC5kFQ3a/XqLsGfK170ElxXNtuKemXE
	Lkbtrxe5V/rtPHiFvIeAQrFjwS4tv/abCVElmbH0EHgBGia5cZwfX/xjtNGOM9cU357yNGbJ6Ze
	eBOiFbf9xJz7cRd37xR8mMUNh31Qpz28rKXyJDA=
X-Google-Smtp-Source: AGHT+IEjw1VR6RvKQ56Pj7s0pHYojoghsUb91BvgzPodD1nm29nl21v8UUvBBmPiK4/ZlBLg7jD27w==
X-Received: by 2002:a5d:47ab:0:b0:385:fb34:d59f with SMTP id ffacd0b85a97d-3864ce86a74mr2122464f8f.11.1733911947260;
        Wed, 11 Dec 2024 02:12:27 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 11:12:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v3 03/16] x86emul/test: use simd_check_avx512*() in main()
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@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: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

In preparation for having these also cover AVX10, use the helper
functions in preference of open-coded cpu_has_avx512* for those features
that AVX10 includes. Introduce a couple further helper functions where
they weren't previously needed.

Note that this way simd_check_avx512f_sha_vl() gains an AVX512F check
(which is likely benign) and simd_check_avx512bw_gf_vl() gains an
AVX512BW check (which was clearly missing). 

Signed-off-by: Jan Beulich 
---
v2: Re-base over dropping of Xeon Phi support.

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -167,6 +167,11 @@ static bool simd_check_avx512vbmi_vl(voi
     return cpu_has_avx512_vbmi && cpu_has_avx512vl;
 }
 
+static bool simd_check_avx512vbmi2(void)
+{
+    return cpu_has_avx512_vbmi2;
+}
+
 static bool simd_check_sse4_sha(void)
 {
     return cpu_has_sha && cpu_has_sse4_2;
@@ -179,7 +184,7 @@ static bool simd_check_avx_sha(void)
 
 static bool simd_check_avx512f_sha_vl(void)
 {
-    return cpu_has_sha && cpu_has_avx512vl;
+    return cpu_has_sha && simd_check_avx512f_vl();
 }
 
 static bool simd_check_avx2_vaes(void)
@@ -189,13 +194,13 @@ static bool simd_check_avx2_vaes(void)
 
 static bool simd_check_avx512bw_vaes(void)
 {
-    return cpu_has_aesni && cpu_has_vaes && cpu_has_avx512bw;
+    return cpu_has_aesni && cpu_has_vaes && simd_check_avx512bw();
 }
 
 static bool simd_check_avx512bw_vaes_vl(void)
 {
     return cpu_has_aesni && cpu_has_vaes &&
-           cpu_has_avx512bw && cpu_has_avx512vl;
+           simd_check_avx512bw_vl();
 }
 
 static bool simd_check_avx2_vpclmulqdq(void)
@@ -205,22 +210,22 @@ static bool simd_check_avx2_vpclmulqdq(v
 
 static bool simd_check_avx512bw_vpclmulqdq(void)
 {
-    return cpu_has_vpclmulqdq && cpu_has_avx512bw;
+    return cpu_has_vpclmulqdq && simd_check_avx512bw();
 }
 
 static bool simd_check_avx512bw_vpclmulqdq_vl(void)
 {
-    return cpu_has_vpclmulqdq && cpu_has_avx512bw && cpu_has_avx512vl;
+    return cpu_has_vpclmulqdq && simd_check_avx512bw_vl();
 }
 
 static bool simd_check_avx512vbmi2_vpclmulqdq(void)
 {
-    return cpu_has_avx512_vbmi2 && simd_check_avx512bw_vpclmulqdq();
+    return simd_check_avx512vbmi2() && simd_check_avx512bw_vpclmulqdq();
 }
 
 static bool simd_check_avx512vbmi2_vpclmulqdq_vl(void)
 {
-    return cpu_has_avx512_vbmi2 && simd_check_avx512bw_vpclmulqdq_vl();
+    return simd_check_avx512vbmi2() && simd_check_avx512bw_vpclmulqdq_vl();
 }
 
 static bool simd_check_sse2_gf(void)
@@ -235,12 +240,17 @@ static bool simd_check_avx2_gf(void)
 
 static bool simd_check_avx512bw_gf(void)
 {
-    return cpu_has_gfni && cpu_has_avx512bw;
+    return cpu_has_gfni && simd_check_avx512bw();
 }
 
 static bool simd_check_avx512bw_gf_vl(void)
 {
-    return cpu_has_gfni && cpu_has_avx512vl;
+    return cpu_has_gfni && simd_check_avx512bw_vl();
+}
+
+static bool simd_check_avx512vnni(void)
+{
+    return cpu_has_avx512_vnni;
 }
 
 static bool simd_check_avx512fp16(void)
@@ -3195,7 +3205,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing {evex} vmovq %xmm1,32(%edx)...");
-    if ( stack_exec && cpu_has_avx512f )
+    if ( stack_exec && simd_check_avx512f() )
     {
         decl_insn(evex_vmovq_to_mem);
 
@@ -3219,7 +3229,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing {evex} vmovq 32(%edx),%xmm0...");
-    if ( stack_exec && cpu_has_avx512f )
+    if ( stack_exec && simd_check_avx512f() )
     {
         decl_insn(evex_vmovq_from_mem);
 
@@ -3342,7 +3352,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing vmovdqu32 %zmm2,(%ecx){%k1}...");
-    if ( stack_exec && cpu_has_avx512f )
+    if ( stack_exec && simd_check_avx512f() )
     {
         decl_insn(vmovdqu32_to_mem);
 
@@ -3372,7 +3382,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing vmovdqu32 64(%edx),%zmm2{%k2}...");
-    if ( stack_exec && cpu_has_avx512f )
+    if ( stack_exec && simd_check_avx512f() )
     {
         decl_insn(vmovdqu32_from_mem);
 
@@ -3397,7 +3407,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing vmovdqu16 %zmm3,(%ecx){%k1}...");
-    if ( stack_exec && cpu_has_avx512bw )
+    if ( stack_exec && simd_check_avx512bw() )
     {
         decl_insn(vmovdqu16_to_mem);
 
@@ -3429,7 +3439,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing vmovdqu16 64(%edx),%zmm3{%k2}...");
-    if ( stack_exec && cpu_has_avx512bw )
+    if ( stack_exec && simd_check_avx512bw() )
     {
         decl_insn(vmovdqu16_from_mem);
 
@@ -3557,7 +3567,7 @@ int main(int argc, char **argv)
     printf("%-40s", "Testing vmovsd %xmm5,16(%ecx){%k3}...");
     memset(res, 0x88, 128);
     memset(res + 20, 0x77, 8);
-    if ( stack_exec && cpu_has_avx512f )
+    if ( stack_exec && simd_check_avx512f() )
     {
         decl_insn(vmovsd_masked_to_mem);
 
@@ -3592,7 +3602,7 @@ int main(int argc, char **argv)
     }
 
     printf("%-40s", "Testing vmovaps (%edx),%zmm7{%k3}{z}...");
-    if ( stack_exec && cpu_has_avx512f )
+    if ( stack_exec && simd_check_avx512f() )
     {
         decl_insn(vmovaps_masked_from_mem);
 
@@ -3775,7 +3785,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing {evex} vmovd %xmm3,32(%ecx)...");
-    if ( stack_exec && cpu_has_avx512f )
+    if ( stack_exec && simd_check_avx512f() )
     {
         decl_insn(evex_vmovd_to_mem);
 
@@ -3800,7 +3810,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing {evex} vmovd 32(%ecx),%xmm4...");
-    if ( stack_exec && cpu_has_avx512f )
+    if ( stack_exec && simd_check_avx512f() )
     {
         decl_insn(evex_vmovd_from_mem);
 
@@ -3990,7 +4000,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing {evex} vmovd %xmm2,%ebx...");
-    if ( stack_exec && cpu_has_avx512f )
+    if ( stack_exec && simd_check_avx512f() )
     {
         decl_insn(evex_vmovd_to_reg);
 
@@ -4016,7 +4026,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing {evex} vmovd %ebx,%xmm1...");
-    if ( stack_exec && cpu_has_avx512f )
+    if ( stack_exec && simd_check_avx512f() )
     {
         decl_insn(evex_vmovd_from_reg);
 
@@ -4118,7 +4128,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing {evex} vmovq %xmm11,32(%ecx)...");
-    if ( stack_exec && cpu_has_avx512f )
+    if ( stack_exec && simd_check_avx512f() )
     {
         decl_insn(evex_vmovq_to_mem2);
 
@@ -4208,7 +4218,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing vmovq %xmm22,%rbx...");
-    if ( stack_exec && cpu_has_avx512f )
+    if ( stack_exec && simd_check_avx512f() )
     {
         decl_insn(evex_vmovq_to_reg);
 
@@ -4401,7 +4411,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing vmovntdqa 64(%ecx),%zmm4...");
-    if ( stack_exec && cpu_has_avx512f )
+    if ( stack_exec && simd_check_avx512f() )
     {
         decl_insn(evex_vmovntdqa);
 
@@ -4997,7 +5007,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing vcvtph2ps 32(%ecx),%zmm7{%k4}...");
-    if ( stack_exec && cpu_has_avx512f )
+    if ( stack_exec && simd_check_avx512f() )
     {
         decl_insn(evex_vcvtph2ps);
         decl_insn(evex_vcvtps2ph);
@@ -5040,7 +5050,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing vfixupimmpd $0,8(%edx){1to8},%zmm3,%zmm4...");
-    if ( stack_exec && cpu_has_avx512f )
+    if ( stack_exec && simd_check_avx512f() )
     {
         decl_insn(vfixupimmpd);
         static const struct {
@@ -5079,7 +5089,7 @@ int main(int argc, char **argv)
 
 
     printf("%-40s", "Testing vfpclasspsz $0x46,64(%edx),%k2...");
-    if ( stack_exec && cpu_has_avx512dq )
+    if ( stack_exec && simd_check_avx512dq() )
     {
         decl_insn(vfpclassps);
 
@@ -5111,7 +5121,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing vfpclassphz $0x46,128(%ecx),%k3...");
-    if ( stack_exec && cpu_has_avx512_fp16 )
+    if ( stack_exec && simd_check_avx512fp16() )
     {
         decl_insn(vfpclassph);
 
@@ -5154,7 +5164,7 @@ int main(int argc, char **argv)
      * on the mapping boundaries) that elements controlled by clear mask
      * bits don't get accessed.
      */
-    if ( stack_exec && cpu_has_avx512f )
+    if ( stack_exec && simd_check_avx512f() )
     {
         decl_insn(vpcompressd);
         decl_insn(vpcompressq);
@@ -5256,7 +5266,7 @@ int main(int argc, char **argv)
     }
 
 #if __GNUC__ > 7 /* can't check for __AVX512VBMI2__ here */
-    if ( stack_exec && cpu_has_avx512_vbmi2 )
+    if ( stack_exec && simd_check_avx512vbmi2() )
     {
         decl_insn(vpcompressb);
         decl_insn(vpcompressw);
@@ -5444,7 +5454,7 @@ int main(int argc, char **argv)
     }
 
     printf("%-40s", "Testing vpdpwssd (%ecx),%{y,z}mmA,%{y,z}mmB...");
-    if ( stack_exec && cpu_has_avx512_vnni && cpu_has_avx_vnni )
+    if ( stack_exec && simd_check_avx512vnni() && cpu_has_avx_vnni )
     {
         /* Do the same operation two ways and compare the results. */
         decl_insn(vpdpwssd_vex1);
@@ -5499,7 +5509,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing vmovsh 8(%ecx),%xmm5...");
-    if ( stack_exec && cpu_has_avx512_fp16 )
+    if ( stack_exec && simd_check_avx512fp16() )
     {
         decl_insn(vmovsh_from_mem);
         decl_insn(vmovw_to_gpr);



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:14:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:14:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854293.1267536 (Exim 4.92)
	(envelope-from )
	id 1tLJjG-0005cD-QZ; Wed, 11 Dec 2024 10:14:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854293.1267536; Wed, 11 Dec 2024 10:14: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 1tLJjG-0005c6-NI; Wed, 11 Dec 2024 10:14:02 +0000
Received: by outflank-mailman (input) for mailman id 854293;
 Wed, 11 Dec 2024 10:14: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 1tLJjE-0005bt-Rp
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:14:00 +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 a016e5b8-b7a8-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 11:13:54 +0100 (CET)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-385f06d0c8eso3045246f8f.0
 for ; Wed, 11 Dec 2024 02:13: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
 d2e1a72fcca58-725d3dd4cbasm7469337b3a.142.2024.12.11.02.13.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:13: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: a016e5b8-b7a8-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733912038; x=1734516838; 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=VGSyTsew86/TrCcru/Rk7R/2beYcoXHkI1pXLpAyXsw=;
        b=WUB+Wcy01N562dCQj3yuiN1GKPumclfXSSO3WNIMZwNJcXIpGhmiB2snCwO0LbIpK8
         Mc+A+m6DwKqNNJdjH7wSEMozx6ULv4/Dl9OXms0u/koTvJt002Pjp4XKIIBBxrrZKfxM
         E8qaG8hHR7U8MSopH9lhqMct1MlHruOu3FiNWsV0WovoWEoYIcW14L1aQL9rkcHWS36n
         hb1gvKiO1MoW5OXsAJt/v/mrDBZ9lxDhG4/3QUkLmceUdbcOe77JcejavlPVdjW6gcag
         jpTwy4vRtkEAw6mz/nIX4HYvWH/PCwuLto6EHyypHCVUw0PMMXXFhPPd3L+GlJWu5FeM
         vK5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733912038; x=1734516838;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=VGSyTsew86/TrCcru/Rk7R/2beYcoXHkI1pXLpAyXsw=;
        b=I0j0qeAUxsY0ng9lLDTWv6PQLiOZgAU3unYahakOVxIxRTQ5DBpED7WextOF/Ubr4q
         N/Frm94zLN2pzs6r6brqd1ZfsNAj78iKhuH2ZLg+MP9reKbjVLnXXXeZdODD0VBSVetS
         vigcvK5FZQ1nmkYrGP9OHQpyzsu+5K3fntUBz/v90jDKLXHLo1RD3wqbSo/4Yv587jSn
         DFavvwaQx/Xty1uab6rKQJDAPay4thd1XfnqwrtvaS5xJDEgNRjm4lUM2enQaNJl5WBN
         RYx3m9RaZWk+CfFsYx1U5K/ZRvzRLmxR/JJzMD9oSefjwZtMYP/mi2WbZ4au20y4NO9g
         asVg==
X-Gm-Message-State: AOJu0Yz5L3Ce1H7/nW2+BFiZ51b0o/v030FSZUH+GJPyFXTaJUgLFHgH
	+PRnbqmLmmdLIh7vZtQ5Myv9cRTBfdYmn+RN+p2xAbTSrqxAVeRt51Hhkt7U32/xLVYeu2iSXa8
	=
X-Gm-Gg: ASbGncuRqgpUEyTMmBukUKYGnz989KGgsr+aThy4Ek2t+t6sUd3Uoj5KWNoIp25gpNQ
	BwiuPB+DuXv7Az+k+XmOdHPzBUORAcEJJkH5Jiyf7AKdsa7wfixxoAIwEoNgK8IR/fk86wNh2OF
	6pNM87WvzFp8qwnwxpajrEc9WCLKoa8tlWHsKvQfsXaiApDTfpVuEaQvTLGcLJURENB02Ari82V
	Pbhqr35aXxELuG2LPXTg+xsL6N/tQ5AjTUzh2TWMt9/crnL3gg2TZiKOlj8VgRmOdwCWBm28p8j
	lwtf4mjkrimeaBg3bjYDjAAf28CiAf2zmQl5ZsE=
X-Google-Smtp-Source: AGHT+IFAUVdTKd07IUIk75oNNDJmg2YpV/i6O60WN6iY0a4ljixpKTvnt8a9OaU/jl5nY+M/q+dXzw==
X-Received: by 2002:a5d:6c64:0:b0:385:fab3:c56d with SMTP id ffacd0b85a97d-3864cdc1132mr1836657f8f.0.1733912038370;
        Wed, 11 Dec 2024 02:13:58 -0800 (PST)
Message-ID: <59222198-afca-4ff4-8a47-8c3e6d3e922c@suse.com>
Date: Wed, 11 Dec 2024 11:13:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v3 06/16] x86emul/test: engage AVX512VL via command line
 option
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@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: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Now that we have machinery in testcase.mk to set vector length dependent
flags for AVX512 tests, let's avoid using a pragma to enable AVX512VL
insns for the compiler. This way, correct settings are in place from the
very beginning of compilation.

No change to the generated test blobs, and hence no functional change.

Signed-off-by: Jan Beulich 

--- a/tools/tests/x86_emulator/simd.h
+++ b/tools/tests/x86_emulator/simd.h
@@ -215,10 +215,6 @@ DECL_OCTET(half);
 # define __builtin_ia32_shuf_i32x4_512_mask __builtin_ia32_shuf_i32x4_mask
 # define __builtin_ia32_shuf_i64x2_512_mask __builtin_ia32_shuf_i64x2_mask
 
-# if VEC_SIZE > ELEM_SIZE && (defined(VEC_MAX) ? VEC_MAX : VEC_SIZE) < 64
-#  pragma GCC target ( "avx512vl" )
-# endif
-
 # define REN(insn, old, new)                     \
     asm ( ".macro v" #insn #old " o:vararg \n\t" \
           "v" #insn #new " \\o             \n\t" \
--- a/tools/tests/x86_emulator/testcase.mk
+++ b/tools/tests/x86_emulator/testcase.mk
@@ -7,8 +7,8 @@ $(call cc-options-add,CFLAGS,CC,$(EMBEDD
 ifneq ($(filter -mavx512%,$($(TESTCASE)-cflags)),)
 
 cflags-vsz64 :=
-cflags-vsz32 := -mprefer-vector-width=256
-cflags-vsz16 := -mprefer-vector-width=128
+cflags-vsz32 := -mavx512vl -mprefer-vector-width=256
+cflags-vsz16 := -mavx512vl -mprefer-vector-width=128
 # Scalar tests don't set VEC_SIZE (and VEC_MAX is used by S/G ones only)
 cflags-vsz   := -mprefer-vector-width=128
 



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:14:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:14:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854299.1267547 (Exim 4.92)
	(envelope-from )
	id 1tLJjd-00065U-3B; Wed, 11 Dec 2024 10:14:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854299.1267547; Wed, 11 Dec 2024 10:14: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 1tLJjc-00065N-UE; Wed, 11 Dec 2024 10:14:24 +0000
Received: by outflank-mailman (input) for mailman id 854299;
 Wed, 11 Dec 2024 10:14: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 1tLJjc-00060E-G7
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:14:24 +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 b1b1f941-b7a8-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 11:14:23 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-38632b8ae71so3132864f8f.0
 for ; Wed, 11 Dec 2024 02:14: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
 d2e1a72fcca58-725e438f169sm6062727b3a.168.2024.12.11.02.14.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:14: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: b1b1f941-b7a8-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733912063; x=1734516863; 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=LdaGVXA10IBcCRzlLDHPVJ5Jo7qKqPrDjPHTX/kabAE=;
        b=aqHMLQpQjpM4sfwpdhSJ+e7aRqxDVSVEBc78CSADlAUOIkPNivpcqHfw0fxHe0vrK8
         7prCNT4CEVMVOQRrXp2d9ND9u+C0I8sQIASMfQVy1hUEUkfn5ul7blXlv496kk8J3XR0
         8paY8fgnr/s3wyFi1275c3OO+MCg2rAbesoUEVaa80EztLe91BGGNyh2chk3hoWwqnhq
         dcx7SWYKJpsuaKwRkOwBhCfbk/80JdNF2knfpa6pXJFKP6/E3jhn18vuCs0HEu5p6ySo
         Zzr21EnLOJ9ejNgyDquXtWxEjLrOHXq/YL4Mw2zMNZ6lrnUlbtuJ1u2b3Q2lioTezri1
         5hrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733912063; x=1734516863;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=LdaGVXA10IBcCRzlLDHPVJ5Jo7qKqPrDjPHTX/kabAE=;
        b=aEbkHQgiAWjDPyGzp++1or2YwdZfTCdsH26AzkrKisjkCkD0KWh9ELE1E7D+xYwWhE
         yZVuHvEiRTsD6inO9EBr0xEerZ7AW3Fbiheg9ngA/BQidYw8Ro5KofakIY7hpfpm2ofq
         FsEW97Q1mPOjHcTcCXh2D0pNt4nSXL2S/A+kBoOnW87/+7dvl120sz0Ljc1vwPV+dZYU
         6xZ3/qvZ1Vt5KwaLJIDRsYpBrQ0CEiOXzC2jJRY+tzftA37eLl/QB+NxO55AXGtTAYe4
         OMeEJ/FOHjh901mCCPeBIM/RzjCkEFuFk8xk84nG0KKiNm6jYfQ9hb1kEURzFmbvPjKh
         XVgg==
X-Gm-Message-State: AOJu0YygmxPc3BOTARsC4h8f3+tBt0dhCYHFzJ1GPytKwNIdfpEcl7IF
	MQnM1zLVOvQkFrS8rQ7LUD61FbsWUQ5pZmfttwruKStw2ASVp0Oi2JIQ9EXJd4Ay0G2BuLVRmJQ
	=
X-Gm-Gg: ASbGnctIgVsKHHBmzG7Kbq7o5dAjt5ogDtzntXNjncVOgoE8+HfNyDHRLo7Zxx31vnF
	RT2I607qqyWmuh6vTu+nlktNHzngiI3ybAaLb6ReH7xkf5yyNgdO6BqG/BBfu9V9UwXbLcb5TKs
	LYlz8Icg1z/tPEscWhyxTdDdJuida639R4N6dybEEFDDE4RfQzzVEIgnSFnqwBOkqsIz16gbiZL
	///tzEieaFkM7+pghv+yt82pkvfCGB6zu/K6M9Ryw2TRs4UIRgoEICIIPFmnnOcum9M9aJfcsr2
	QynPa2W0IPa98opUTzIulIWdCjCJoScubHz3tnc=
X-Google-Smtp-Source: AGHT+IHbmK8rQyhYlnEZ/56i71MHJERRZ3R+gFaRtnYt48oWR9ePFEk/7foCXiqMM7Lketo+OfwWbA==
X-Received: by 2002:a05:6000:18ae:b0:385:fd07:8616 with SMTP id ffacd0b85a97d-3864cdeb11fmr1770022f8f.0.1733912063058;
        Wed, 11 Dec 2024 02:14:23 -0800 (PST)
Message-ID: <995a7961-2a28-426c-85b8-2ee3dd505f4b@suse.com>
Date: Wed, 11 Dec 2024 11:14:17 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v3 07/16] x86emul: support AVX10.2 256-bit embedded rounding /
 SAE
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@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: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

AVX10.2 (along with APX) assigns new meaning to the bit that previsouly
distinguished EVEX from the Phi co-processor's MVEX. Therefore
evex_encoded() now needs to key off of something else: Use the opcode
mapping field for this, leveraging that map 0 has no assigned opcodes
(and appears unlikely to gain any).

Place the check of EVEX.U such that it'll cover most insns. EVEX.b is
being checked for individual insns as applicable - whenever that's valid
for (register-only) 512-bit forms, it becomes valid for 256-bit forms as
well when AVX10.2 is permitted for a guest. Scalar insns permitting
embedded rounding / SAE, otoh, have individual EVEX.U checks added (where
applicable with minor adjustments to the logic to avoid - where easily
possible - testing the same bit multiple times).

Signed-off-by: Jan Beulich 
---
To raise the question early: It is entirely unclear to me how we want to
allow control over the AVX10 minor version number from guest configs, as
that's not a boolean field and hence not suitable for simple bit-wise
masking of feature sets.
---
v3: Take care of scalar insns individually.
v2: New.

--- a/xen/arch/x86/x86_emulate/decode.c
+++ b/xen/arch/x86/x86_emulate/decode.c
@@ -16,7 +16,7 @@
 # define ERR_PTR(val) NULL
 #endif
 
-#define evex_encoded() (s->evex.mbs)
+#define evex_encoded() (s->evex.opcx)
 
 struct x86_emulate_state *
 x86_decode_insn(
@@ -1198,8 +1198,15 @@ int x86emul_decode(struct x86_emulate_st
                         s->evex.raw[1] = s->vex.raw[1];
                         s->evex.raw[2] = insn_fetch_type(uint8_t);
 
-                        generate_exception_if(!s->evex.mbs || s->evex.mbz, X86_EXC_UD);
-                        generate_exception_if(!s->evex.opmsk && s->evex.z, X86_EXC_UD);
+                        /*
+                         * .opcx is being checked here just to be on the safe
+                         * side, especially as long as evex_encoded() uses
+                         * this field.
+                         */
+                        generate_exception_if(s->evex.mbz || !s->evex.opcx,
+                                              X86_EXC_UD);
+                        generate_exception_if(!s->evex.opmsk && s->evex.z,
+                                              X86_EXC_UD);
 
                         if ( !mode_64bit() )
                             s->evex.R = 1;
@@ -1777,6 +1784,16 @@ int x86emul_decode(struct x86_emulate_st
     if ( override_seg != x86_seg_none )
         s->ea.mem.seg = override_seg;
 
+    /*
+     * While this generic check takes care of most insns, scalar ones (with
+     * EVEX.b set) need checking individually (elsewhere).
+     */
+    generate_exception_if((evex_encoded() &&
+                           !s->evex.u &&
+                           (s->modrm_mod != 3 ||
+                            !vcpu_has_avx10(2) || !s->evex.brs)),
+                          X86_EXC_UD);
+
     /* Fetch the immediate operand, if present. */
     switch ( d & SrcMask )
     {
--- a/xen/arch/x86/x86_emulate/private.h
+++ b/xen/arch/x86/x86_emulate/private.h
@@ -225,7 +225,7 @@ union evex {
         uint8_t x:1;     /* X */
         uint8_t r:1;     /* R */
         uint8_t pfx:2;   /* pp */
-        uint8_t mbs:1;
+        uint8_t u:1;     /* U */
         uint8_t reg:4;   /* vvvv */
         uint8_t w:1;     /* W */
         uint8_t opmsk:3; /* aaa */
@@ -594,6 +594,8 @@ amd_like(const struct x86_emulate_ctxt *
 #define vcpu_has_avx_vnni_int16() (ctxt->cpuid->feat.avx_vnni_int16)
 #define vcpu_has_user_msr()    (ctxt->cpuid->feat.user_msr)
 
+#define vcpu_has_avx10(minor)  (ctxt->cpuid->avx10.version >= (minor))
+
 #define vcpu_must_have(feat) \
     generate_exception_if(!vcpu_has_##feat(), X86_EXC_UD)
 
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1241,7 +1241,7 @@ int cf_check x86emul_unhandleable_rw(
 #define lock_prefix (state->lock_prefix)
 #define vex (state->vex)
 #define evex (state->evex)
-#define evex_encoded() (evex.mbs)
+#define evex_encoded() (evex.opcx)
 #define ea (state->ea)
 
 /* Undo DEBUG wrapper. */
@@ -3415,8 +3415,8 @@ x86_emulate(
     CASE_SIMD_ALL_FP(_EVEX, 0x0f, 0x5f):    /* vmax{p,s}{s,d} [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     avx512f_all_fp:
         generate_exception_if((evex.w != (evex.pfx & VEX_PREFIX_DOUBLE_MASK) ||
-                               (ea.type != OP_REG && evex.brs &&
-                                (evex.pfx & VEX_PREFIX_SCALAR_MASK))),
+                               ((evex.pfx & VEX_PREFIX_SCALAR_MASK) &&
+                                (ea.type != OP_REG ? evex.brs : !evex.u))),
                               X86_EXC_UD);
         visa_check(f);
         if ( ea.type != OP_REG || !evex.brs )
@@ -3622,11 +3622,12 @@ x86_emulate(
         /* fall through */
     CASE_SIMD_SCALAR_FP(_EVEX, 0x0f, 0x2a): /* vcvtsi2s{s,d} r/m,xmm,xmm */
     CASE_SIMD_SCALAR_FP(_EVEX, 0x0f, 0x7b): /* vcvtusi2s{s,d} r/m,xmm,xmm */
-        generate_exception_if(evex.opmsk || (ea.type != OP_REG && evex.brs),
-                              X86_EXC_UD);
+        generate_exception_if(evex.opmsk, X86_EXC_UD);
         visa_check(f);
         if ( !evex.brs )
             avx512_vlen_check(true);
+        else
+            generate_exception_if(ea.type != OP_REG || !evex.u, X86_EXC_UD);
         get_fpu(X86EMUL_FPU_zmm);
 
         if ( ea.type == OP_MEM )
@@ -3741,12 +3742,13 @@ x86_emulate(
     CASE_SIMD_SCALAR_FP(_EVEX, 0x0f, 0x78): /* vcvtts{s,d}2usi xmm/mem,reg */
     CASE_SIMD_SCALAR_FP(_EVEX, 0x0f, 0x79): /* vcvts{s,d}2usi xmm/mem,reg */
         generate_exception_if((evex.reg != 0xf || !evex.RX || !evex.R ||
-                               evex.opmsk ||
-                               (ea.type != OP_REG && evex.brs)),
+                               evex.opmsk),
                               X86_EXC_UD);
         visa_check(f);
         if ( !evex.brs )
             avx512_vlen_check(true);
+        else
+            generate_exception_if(ea.type != OP_REG || !evex.u, X86_EXC_UD);
         get_fpu(X86EMUL_FPU_zmm);
         opc = init_evex(stub);
         goto cvts_2si;
@@ -3816,12 +3818,13 @@ x86_emulate(
     CASE_SIMD_PACKED_FP(_EVEX, 0x0f, 0x2e): /* vucomis{s,d} xmm/mem,xmm */
     CASE_SIMD_PACKED_FP(_EVEX, 0x0f, 0x2f): /* vcomis{s,d} xmm/mem,xmm */
         generate_exception_if((evex.reg != 0xf || !evex.RX || evex.opmsk ||
-                               (ea.type != OP_REG && evex.brs) ||
                                evex.w != evex.pfx),
                               X86_EXC_UD);
         visa_check(f);
         if ( !evex.brs )
             avx512_vlen_check(true);
+        else
+            generate_exception_if(ea.type != OP_REG || !evex.u, X86_EXC_UD);
         get_fpu(X86EMUL_FPU_zmm);
 
         opc = init_evex(stub);
@@ -5389,8 +5392,8 @@ x86_emulate(
 
     CASE_SIMD_ALL_FP(_EVEX, 0x0f, 0xc2): /* vcmp{p,s}{s,d} $imm8,[xyz]mm/mem,[xyz]mm,k{k} */
         generate_exception_if((evex.w != (evex.pfx & VEX_PREFIX_DOUBLE_MASK) ||
-                               (ea.type != OP_REG && evex.brs &&
-                                (evex.pfx & VEX_PREFIX_SCALAR_MASK)) ||
+                               ((evex.pfx & VEX_PREFIX_SCALAR_MASK) &&
+                                (ea.type != OP_REG ? evex.brs : !evex.u)) ||
                                !evex.r || !evex.R || evex.z),
                               X86_EXC_UD);
         visa_check(f);
@@ -6088,9 +6091,10 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_66(0x0f38, 0xbd): /* vfnmadd231s{s,d} xmm/mem,xmm,xmm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0xbf): /* vfnmsub231s{s,d} xmm/mem,xmm,xmm{k} */
         visa_check(f);
-        generate_exception_if(ea.type != OP_REG && evex.brs, X86_EXC_UD);
         if ( !evex.brs )
             avx512_vlen_check(true);
+        else
+            generate_exception_if(ea.type != OP_REG || !evex.u, X86_EXC_UD);
         goto simd_zmm;
 
     case X86EMUL_OPC_66(0x0f38, 0x37): /* pcmpgtq xmm/m128,xmm */
@@ -7262,7 +7266,8 @@ x86_emulate(
 
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x0a): /* vrndscaless $imm8,xmm/mem,xmm,xmm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x0b): /* vrndscalesd $imm8,xmm/mem,xmm,xmm{k} */
-        generate_exception_if(ea.type != OP_REG && evex.brs, X86_EXC_UD);
+        generate_exception_if(ea.type != OP_REG ? evex.brs : !evex.u,
+                              X86_EXC_UD);
         /* fall through */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x08): /* vrndscaleps $imm8,[xyz]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x09): /* vrndscalepd $imm8,[xyz]mm/mem,[xyz]mm{k} */
@@ -7272,7 +7277,8 @@ x86_emulate(
         goto simd_imm8_zmm;
 
     case X86EMUL_OPC_EVEX(0x0f3a, 0x0a): /* vrndscalesh $imm8,xmm/mem,xmm,xmm{k} */
-        generate_exception_if(ea.type != OP_REG && evex.brs, X86_EXC_UD);
+        generate_exception_if(ea.type != OP_REG ? evex.brs : !evex.u,
+                              X86_EXC_UD);
         /* fall through */
     case X86EMUL_OPC_EVEX(0x0f3a, 0x08): /* vrndscaleph $imm8,[xyz]mm/mem,[xyz]mm{k} */
         visa_check(_fp16);
@@ -7605,9 +7611,10 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x27): /* vgetmants{s,d} $imm8,xmm/mem,xmm,xmm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f3a, 0x55): /* vfixupimms{s,d} $imm8,xmm/mem,xmm,xmm{k} */
         visa_check(f);
-        generate_exception_if(ea.type != OP_REG && evex.brs, X86_EXC_UD);
         if ( !evex.brs )
             avx512_vlen_check(true);
+        else
+            generate_exception_if(ea.type != OP_REG || !evex.u, X86_EXC_UD);
         goto simd_imm8_zmm;
 
     case X86EMUL_OPC_EVEX(0x0f3a, 0x27): /* vgetmantsh $imm8,xmm/mem,xmm,xmm{k} */
@@ -7617,7 +7624,7 @@ x86_emulate(
         if ( !evex.brs )
             avx512_vlen_check(true);
         else
-            generate_exception_if(ea.type != OP_REG, X86_EXC_UD);
+            generate_exception_if(ea.type != OP_REG || !evex.u, X86_EXC_UD);
         goto simd_imm8_zmm;
 
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x30): /* kshiftr{b,w} $imm8,k,k */
@@ -7805,7 +7812,7 @@ x86_emulate(
         goto avx512f_imm8_no_sae;
 
     case X86EMUL_OPC_EVEX_F3(0x0f3a, 0xc2): /* vcmpsh $imm8,xmm/mem,xmm,k{k} */
-        generate_exception_if(ea.type != OP_REG && evex.brs, X86_EXC_UD);
+        generate_exception_if(ea.type != OP_REG ? evex.brs : !evex.u, X86_EXC_UD);
         /* fall through */
     case X86EMUL_OPC_EVEX(0x0f3a, 0xc2): /* vcmpph $imm8,[xyz]mm/mem,[xyz]mm,k{k} */
         visa_check(_fp16);
@@ -7982,10 +7989,11 @@ x86_emulate(
     case X86EMUL_OPC_EVEX_66(6, 0xbd): /* vfnmadd231sh xmm/m16,xmm,xmm{k} */
     case X86EMUL_OPC_EVEX_66(6, 0xbf): /* vfnmsub231sh xmm/m16,xmm,xmm{k} */
         visa_check(_fp16);
-        generate_exception_if(evex.w || (ea.type != OP_REG && evex.brs),
-                              X86_EXC_UD);
+        generate_exception_if(evex.w, X86_EXC_UD);
         if ( !evex.brs )
             avx512_vlen_check(true);
+        else
+            generate_exception_if(ea.type != OP_REG || !evex.u, X86_EXC_UD);
         goto simd_zmm;
 
     case X86EMUL_OPC_EVEX_66(6, 0x4c): /* vrcpph [xyz]mm/mem,[xyz]mm{k} */
@@ -8015,7 +8023,9 @@ x86_emulate(
         unsigned int src1 = ~evex.reg;
 
         visa_check(_fp16);
-        generate_exception_if(evex.w || ((b & 1) && ea.type != OP_REG && evex.brs),
+        generate_exception_if((evex.w ||
+                               ((b & 1) &&
+                                (ea.type != OP_REG ? evex.brs : !evex.u))),
                               X86_EXC_UD);
         if ( mode_64bit() )
             src1 = (src1 & 0xf) | (!evex.RX << 4);



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:18:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:18:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854328.1267556 (Exim 4.92)
	(envelope-from )
	id 1tLJn7-0006nc-JY; Wed, 11 Dec 2024 10:18:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854328.1267556; Wed, 11 Dec 2024 10:18: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 1tLJn7-0006nV-G3; Wed, 11 Dec 2024 10:18:01 +0000
Received: by outflank-mailman (input) for mailman id 854328;
 Wed, 11 Dec 2024 10:18: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 1tLJn6-0006nP-Lx
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:18:00 +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 326ac184-b7a9-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 11:17:59 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-385deda28b3so4860142f8f.0
 for ; Wed, 11 Dec 2024 02:17: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
 d2e1a72fcca58-725e7efb381sm5737540b3a.117.2024.12.11.02.17.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:17: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: 326ac184-b7a9-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733912279; x=1734517079; 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=TmwKGqF6AW3IbD/rb2R5K+/4oOCjyt+s+wwmxJjKZqw=;
        b=WHBbSdivPbj8QnfyI4nJs7kYN9keDWnxKOHsvM9r7jLOISJCTSUTUUV6R2iiAuxZUv
         wGAzwD1AfQAfg0j/r4DvFrE/eallWF+hz6ZYvFs93jikpMhathCKdXU/weonKp2pmEqF
         3DQut5BxEL2Wej3qVxASuH5v5WeBareGOM1O7vRqhUp7X+45Z55FuSffLOrVuz1Z84v5
         FJiP/YQof4bSuhxjBYkPDyMlpCzNbyoZyy8oLN4vawarXktfzEfUD5+B6OqxR1qCmczx
         6T0LgpAWLHf0kbacCRlokrTSQET199oUVO5b1UlWC1B1kSdvEg1fFnzNm7bxN78qfZgb
         NOqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733912279; x=1734517079;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=TmwKGqF6AW3IbD/rb2R5K+/4oOCjyt+s+wwmxJjKZqw=;
        b=PYykFGtEm1M0Hm4bBihyFvejB7z8TaEBSfZUuI62l4s5Lb0iHsbIbUyMqRPmdG0gVB
         edmAxPPwtJNTFjOKeMBdzY81ld0k9Poc3f2bQY+8HjFPxPsnI1q/3eFuQbtUqQTMU7A9
         LLiuGoE7XiDTTeeysiB+fWFioiuht8zf7Nz2/S2laJpEvOqpAKkkYvax0C1IxSD34Xno
         c6IQFv+bXBiJKPY4/zFFF/UYvAb5NgajB5TzQKfIOQTx+yjhaqydNCt+aDNqKCYmWsEU
         2YnLBzMjQVm8+ITnDf0TcTKgwGCUrGb+BtpR/XDGMkl4hiGajOYsmnGyAHeNgNfbcLeZ
         dxow==
X-Gm-Message-State: AOJu0Ywgy3FikTeb0uVlFm4EcVA21AKAWK7IWjriAzPd86Tg+CTspUje
	BrdAIW4uBtuV1Wj54ZGgKwje5GLMiVaCQvwfe5tXVYdd2iVUDELrSnokj/LZUH5wwAVLYEM/qf4
	=
X-Gm-Gg: ASbGncudO08ioTxUvtedtQ5uuqutMIMIQvAyQKGceOJKXmhXxsuSz5ayOF1+LOLjPdM
	vmXqJTrTBkffPvL/jB9Odm1euzfJB10GVoTOYY/cjf/3J1vjzA2UZwVDchK5XtjuC72DgU78OWI
	bIP7H2n5WEfbJf7dOeIvc/kt0IL2ob3WRRXrpNCDTeZyPrMDrhNnFZOXkunXo/3tsmjHKKsOUqI
	dlnzH+MGVC1Od1U1K3/XcyRR4vWChTfeJpm7MrWvdrMkUaBJaoIzcr8trTf0FgmC/PsgViU3ebt
	zkYy6ioQnQkUjmJotqxn7cDxnrSBSMcKI2TFmBg=
X-Google-Smtp-Source: AGHT+IHYns+zJ5XF2WPWdcbChZWerdH81qBQTWuW0SCyy4+qXESeEqWRgnO/PWMjzFjdWwZV1Hu7Ow==
X-Received: by 2002:a05:6000:440e:b0:385:fae2:f443 with SMTP id ffacd0b85a97d-3864cea43dcmr1329849f8f.34.1733912278995;
        Wed, 11 Dec 2024 02:17:58 -0800 (PST)
Message-ID: <6e2423e1-1dc0-44c2-b5ad-8ebae0a91566@suse.com>
Date: Wed, 11 Dec 2024 11:17:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v3 08/16] x86emul: support AVX10.2 scalar compare insns
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@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: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Simply clone code from their V{,U}COMIS{S,D,H} counterparts.

While there drop a redundant EVEX.W check from V{,U}COMISH handling.

Signed-off-by: Jan Beulich 
---
This still follows what spec version 001 says wrt embedded prefixed.
They were swapped to match other insns, yet so far no SDE is available
to run the test harness there with the flipped encoding.
---
SDE: ???
---
v3: New.

--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -81,6 +81,7 @@ enum esz {
     ESZ_w,
     ESZ_bw,
     ESZ_fp16,
+#define ESZ_bf16 ESZ_fp16
 };
 
 #ifndef __i386__
@@ -711,6 +712,16 @@ static const struct test vpclmulqdq_all[
     INSN(pclmulqdq, 66, 0f3a, 44, vl, q_nb, vl)
 };
 
+static const struct test avx10_2_all[] = {
+    INSN(comsbf16,         66, map5, 2f,    el, bf16, el),
+    INSN(comxsd,           f3,   0f, 2f,    el,    q, el),
+    INSN(comxsh,           f2, map5, 2f,    el, fp16, el),
+    INSN(comxss,           f2,   0f, 2f,    el,    d, el),
+    INSN(ucomxsd,          f3,   0f, 2e,    el,    q, el),
+    INSN(ucomxsh,          f2, map5, 2e,    el, fp16, el),
+    INSN(ucomxss,          f2,   0f, 2e,    el,    d, el),
+};
+
 static const unsigned char vl_all[] = { VL_512, VL_128, VL_256 };
 static const unsigned char vl_128[] = { VL_128 };
 static const unsigned char vl_no128[] = { VL_512, VL_256 };
@@ -1130,5 +1141,8 @@ void evex_disp8_test(void *instr, struct
         RUN(vpclmulqdq, all);
 #undef RUN
     }
+
+    run(cpu_has_avx10_2, avx10_2, all);
+
 #undef run
 }
--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -1682,8 +1682,12 @@ static const struct evex {
     { { 0x2d }, 2, T, R, pfx_f2, Wn, LIG }, /* vcvtsd2si */
     { { 0x2e }, 2, T, R, pfx_no, W0, LIG }, /* vucomiss */
     { { 0x2e }, 2, T, R, pfx_66, W1, LIG }, /* vucomisd */
+    { { 0x2e }, 2, T, R, pfx_f3, W1, LIG }, /* vucomxsd */
+    { { 0x2e }, 2, T, R, pfx_f2, W0, LIG }, /* vucomxss */
     { { 0x2f }, 2, T, R, pfx_no, W0, LIG }, /* vcomiss */
     { { 0x2f }, 2, T, R, pfx_66, W1, LIG }, /* vcomisd */
+    { { 0x2f }, 2, T, R, pfx_f3, W1, LIG }, /* vcomxsd */
+    { { 0x2f }, 2, T, R, pfx_f2, W0, LIG }, /* vcomxss */
     { { 0x51 }, 2, T, R, pfx_no, W0, Ln }, /* vsqrtps */
     { { 0x51 }, 2, T, R, pfx_66, W1, Ln }, /* vsqrtpd */
     { { 0x51 }, 2, T, R, pfx_f3, W0, LIG }, /* vsqrtss */
@@ -2100,7 +2104,10 @@ static const struct evex {
     { { 0x2c }, 2, T, R, pfx_f3, Wn, LIG }, /* vcvttsh2si */
     { { 0x2d }, 2, T, R, pfx_f3, Wn, LIG }, /* vcvtsh2si */
     { { 0x2e }, 2, T, R, pfx_no, W0, LIG }, /* vucomish */
+    { { 0x2e }, 2, T, R, pfx_f2, W0, LIG }, /* vucomxsh */
     { { 0x2f }, 2, T, R, pfx_no, W0, LIG }, /* vcomish */
+    { { 0x2f }, 2, T, R, pfx_66, W0, LIG }, /* vcomsbf16 */
+    { { 0x2f }, 2, T, R, pfx_f2, W0, LIG }, /* vcomxsh */
     { { 0x51 }, 2, T, R, pfx_no, W0, Ln }, /* vsqrtph */
     { { 0x51 }, 2, T, R, pfx_f3, W0, LIG }, /* vsqrtsh */
     { { 0x58 }, 2, T, R, pfx_no, W0, Ln }, /* vaddph */
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -213,6 +213,8 @@ void wrpkru(unsigned int val);
                                      (cpu_policy.avx10.vsz256 || \
                                       cpu_policy.avx10.vsz512))
 #define cpu_has_avx10_1_512         (cpu_has_avx10_1 && cpu_policy.avx10.vsz512)
+#define cpu_has_avx10_2             (cpu_policy.avx10.version >= 2 && \
+                                     xcr0_mask(0xe6))
 
 #define cpu_has_xgetbv1             (cpu_has_xsave && cpu_policy.xstate.xgetbv1)
 
--- a/xen/arch/x86/x86_emulate/decode.c
+++ b/xen/arch/x86/x86_emulate/decode.c
@@ -1521,9 +1521,8 @@ int x86emul_decode(struct x86_emulate_st
                     s->fp16 = true;
                 break;
 
-            case 0x2e: case 0x2f: /* v{,u}comish */
-                if ( !s->evex.pfx )
-                    s->fp16 = true;
+            case 0x2e: case 0x2f: /* v{,u}com{i,x}sh, vcomsbf16 */
+                s->fp16 = true;
                 s->simd_size = simd_none;
                 break;
 
--- a/xen/arch/x86/x86_emulate/private.h
+++ b/xen/arch/x86/x86_emulate/private.h
@@ -304,7 +304,7 @@ struct x86_emulate_state {
     bool lock_prefix;
     bool not_64bit; /* Instruction not available in 64bit. */
     bool fpu_ctrl;  /* Instruction is an FPU control one. */
-    bool fp16;      /* Instruction has half-precision FP source operand. */
+    bool fp16;      /* Instruction has half-precision FP or BF16 source. */
     opcode_desc_t desc;
     union vex vex;
     union evex evex;
@@ -596,8 +596,8 @@ amd_like(const struct x86_emulate_ctxt *
 
 #define vcpu_has_avx10(minor)  (ctxt->cpuid->avx10.version >= (minor))
 
-#define vcpu_must_have(feat) \
-    generate_exception_if(!vcpu_has_##feat(), X86_EXC_UD)
+#define vcpu_must_have(feat, ...) \
+    generate_exception_if(!vcpu_has_##feat(__VA_ARGS__), X86_EXC_UD)
 
 #ifdef __XEN__
 /*
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3813,7 +3813,6 @@ x86_emulate(
     case X86EMUL_OPC_EVEX(5, 0x2e): /* vucomish xmm/m16,xmm */
     case X86EMUL_OPC_EVEX(5, 0x2f): /* vcomish xmm/m16,xmm */
         visa_check(_fp16);
-        generate_exception_if(evex.w, X86_EXC_UD);
         /* fall through */
     CASE_SIMD_PACKED_FP(_EVEX, 0x0f, 0x2e): /* vucomis{s,d} xmm/mem,xmm */
     CASE_SIMD_PACKED_FP(_EVEX, 0x0f, 0x2f): /* vcomis{s,d} xmm/mem,xmm */
@@ -3821,6 +3820,7 @@ x86_emulate(
                                evex.w != evex.pfx),
                               X86_EXC_UD);
         visa_check(f);
+    vcomi_evex:
         if ( !evex.brs )
             avx512_vlen_check(true);
         else
@@ -3831,6 +3831,17 @@ x86_emulate(
         op_bytes = 2 << (!state->fp16 + evex.w);
         goto vcomi;
 
+    CASE_SIMD_SCALAR_FP(_EVEX, 0x0f, 0x2e): /* vucomxs{s,d} xmm/mem,xmm */
+    CASE_SIMD_SCALAR_FP(_EVEX, 0x0f, 0x2f): /* vcomxs{s,d} xmm/mem,xmm */
+    case X86EMUL_OPC_EVEX_F2(5, 0x2e):      /* vucomxsh xmm/m16,xmm */
+    case X86EMUL_OPC_EVEX_66(5, 0x2f):      /* vcomsbf16 xmm/m16,xmm */
+    case X86EMUL_OPC_EVEX_F2(5, 0x2f):      /* vcomxsh xmm/m16,xmm */
+        generate_exception_if((evex.reg != 0xf || !evex.RX || evex.opmsk ||
+                               evex.w != !(evex.pfx & 1)),
+                              X86_EXC_UD);
+        vcpu_must_have(avx10, 2);
+        goto vcomi_evex;
+
 #endif
 
     case X86EMUL_OPC(0x0f, 0x30): /* wrmsr */



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:18:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:18:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854335.1267565 (Exim 4.92)
	(envelope-from )
	id 1tLJnV-0007Ee-QC; Wed, 11 Dec 2024 10:18:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854335.1267565; Wed, 11 Dec 2024 10: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 1tLJnV-0007EX-Nd; Wed, 11 Dec 2024 10:18:25 +0000
Received: by outflank-mailman (input) for mailman id 854335;
 Wed, 11 Dec 2024 10:18: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 1tLJnU-00076S-Im
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:18:24 +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 3d680ad7-b7a9-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 11:18:18 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-434a766b475so62665745e9.1
 for ; Wed, 11 Dec 2024 02:18: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
 d9443c01a7336-2161b77ea74sm84612825ad.229.2024.12.11.02.18.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02: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: 3d680ad7-b7a9-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733912302; x=1734517102; 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=uETdII7euK3qqaPzdHHMKooaoTcHvrw5Jiuv6BUwztM=;
        b=JummlVuX2ups2MOVRktAtBXnSGZjGhPVCoP00rHEoJel94nd+cdT/qo99Q0Coqvb6y
         z66xtcKEo9IbE9ZLmU3GMP1PtxEHIlW7JWp8B6rRhIDMLj7wVaQHeDQ5khgYmDDRNoMv
         DI9kEbB9g8mi0cSzDQpYzNyLiDWmE/VkD/7aPy5bdaOwUypvf0VVS2Lyu+sSXM0b6pJH
         oy8w/vEVeQuw0DXU28fU8Noh1AcwCa3t7feTf3D8dx9pBcTU/YJRcBwFHX2uQdk+ACBZ
         62KTS65GWquEbwsEAF9sOvF3ltq8IQkxrRUMlXLenK+qSUVspN9MPMhK3oAdyXRs18Dw
         nHhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733912302; x=1734517102;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=uETdII7euK3qqaPzdHHMKooaoTcHvrw5Jiuv6BUwztM=;
        b=cf3axYNXSV4OW+CMR/yxhnOUQ8ZcDwStWyAS0oQrlzZY+49wlp0axeqBG/BxSgwThV
         cXi1VCN4qN1WEdBP2yilQE8RP3TuDKRzPsEzPOmdTu7qLOvey6Lv4v+PrZxoNKcMiOAX
         T29ANmDUf70m35tD6yfIPuhULr3lEkAknS4pwdZ9k4iacBvMf44Hr/We1a+Q/3Ut7YJy
         WGXFvI+FK8Xm9fOez1WkKBUstuNXlnJ/CuY+5RAIElBbwbcNDJXjsKpNJzChrGGxSI5F
         sTY38xSTaiOX7TuUH4OfVkAEQG216K5fCj0Rbx8/bZ0tjimN3+NU30GNV2eP1XWN/hRH
         wKQA==
X-Gm-Message-State: AOJu0Ywr8qjGHoRhz3KafhtjAllmadvPTwSqJE+VThutaNt53UWlYBqg
	XtK3NnOxqyW87i4bFl7/Od/POLoGdX1tY5MuouzoAsFWN5CchdMUvWzWEuOoG5jgQcSD8M+fruU
	=
X-Gm-Gg: ASbGncsHk+Zu08kGNmEOq3BF5fUpGw6V7qc3T7nTJlbT3ZUtaF8004pktYdKW8UcLuG
	z6eA53B4pwtGysdrRT0zy7Hj1XCZN4rqfkY2NkMY9rsJmDhL9PE7aQ0KIgM/LeTXFslRkjWOpx/
	Dp1sOZsa5N89jvJ/NoxCSzNODFyQdaeKbCmjISnV5sfOHKXfA9liQ58mzfRNuokRrFt8hjL65ZG
	AF8Z6wwXWM/zK9DuNeWsbBSmvHKX+xbnacN+yacCIPKBkTO76l8eEiLe6hk8eI8f3ofhXPpVG8g
	8wBFKe1USGzuJ47AER8KrdW0ik9DxBELy0e6ur4=
X-Google-Smtp-Source: AGHT+IHaFe19BiEV4+Ua81mrbHn9BwgnIH9jKCMyNs9d+fOf2PyjAFL2ZHLg0EyFDdQU4jGyo3qFNw==
X-Received: by 2002:a5d:47a1:0:b0:386:3a8e:64c1 with SMTP id ffacd0b85a97d-3864ce90f89mr1685137f8f.19.1733912302270;
        Wed, 11 Dec 2024 02:18:22 -0800 (PST)
Message-ID: <4bed4638-98f6-4a1d-b41f-f0c25d9af526@suse.com>
Date: Wed, 11 Dec 2024 11:18:16 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v3 09/16] x86emul: support AVX10.2 partial copy insns
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@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: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Extend existing VMOV{Q,W} logic accordingly.

Signed-off-by: Jan Beulich 
---
SDE: ???
---
v3: New.

--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -722,6 +722,13 @@ static const struct test avx10_2_all[] =
     INSN(ucomxss,          f2,   0f, 2e,    el,    d, el),
 };
 
+static const struct test avx10_2_128[] = {
+    INSN(movd, f3,   0f, 7e, el,    d, el),
+    INSN(movd, 66,   0f, d6, el,    d, el),
+    INSN(movw, f3, map5, 6e, el, fp16, el),
+    INSN(movw, f3, map5, 7e, el, fp16, el),
+};
+
 static const unsigned char vl_all[] = { VL_512, VL_128, VL_256 };
 static const unsigned char vl_128[] = { VL_128 };
 static const unsigned char vl_no128[] = { VL_512, VL_256 };
@@ -1143,6 +1150,7 @@ void evex_disp8_test(void *instr, struct
     }
 
     run(cpu_has_avx10_2, avx10_2, all);
+    run(cpu_has_avx10_2, avx10_2, 128);
 
 #undef run
 }
--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -1782,7 +1782,7 @@ static const struct evex {
     { { 0x7b }, 2, T, R, pfx_f3, Wn, LIG }, /* vcvtusi2ss */
     { { 0x7b }, 2, T, R, pfx_f2, Wn, LIG }, /* vcvtusi2sd */
     { { 0x7e }, 2, T, W, pfx_66, Wn, L0 }, /* vmov{d,q} */
-    { { 0x7e }, 2, T, R, pfx_f3, W1, L0 }, /* vmovq */
+    { { 0x7e }, 2, T, R, pfx_f3, Wn, L0 }, /* vmov{d,q} */
     { { 0x7f }, 2, T, W, pfx_66, Wn, Ln }, /* vmovdqa{32,64} */
     { { 0x7f }, 2, T, W, pfx_f3, Wn, Ln }, /* vmovdqu{32,64} */
     { { 0x7f }, 2, T, W, pfx_f2, Wn, Ln }, /* vmovdqu{8,16} */
@@ -1799,7 +1799,7 @@ static const struct evex {
     { { 0xd3 }, 2, T, R, pfx_66, W1, Ln }, /* vpsrlq */
     { { 0xd4 }, 2, T, R, pfx_66, W1, Ln }, /* vpaddq */
     { { 0xd5 }, 2, T, R, pfx_66, WIG, Ln }, /* vpmullw */
-    { { 0xd6 }, 2, T, W, pfx_66, W1, L0 }, /* vmovq */
+    { { 0xd6 }, 2, T, W, pfx_66, Wn, L0 }, /* vmov{d,q} */
     { { 0xd8 }, 2, T, R, pfx_66, WIG, Ln }, /* vpsubusb */
     { { 0xd9 }, 2, T, R, pfx_66, WIG, Ln }, /* vpsubusw */
     { { 0xda }, 2, T, R, pfx_66, WIG, Ln }, /* vpminub */
@@ -2131,6 +2131,7 @@ static const struct evex {
     { { 0x5f }, 2, T, R, pfx_no, W0, Ln }, /* vmaxph */
     { { 0x5f }, 2, T, R, pfx_f3, W0, LIG }, /* vmaxsh */
     { { 0x6e }, 2, T, R, pfx_66, WIG, L0 }, /* vmovw */
+    { { 0x6e }, 2, T, R, pfx_f3, W0, L0 }, /* vmovw */
     { { 0x78 }, 2, T, R, pfx_no, W0, Ln }, /* vcvttph2udq */
     { { 0x78 }, 2, T, R, pfx_66, W0, Ln }, /* vcvttph2uqq */
     { { 0x78 }, 2, T, R, pfx_f3, Wn, LIG }, /* vcvttsh2usi */
@@ -2149,6 +2150,7 @@ static const struct evex {
     { { 0x7d }, 2, T, R, pfx_f3, W0, Ln }, /* vcvtw2ph */
     { { 0x7d }, 2, T, R, pfx_f2, W0, Ln }, /* vcvtuwph */
     { { 0x7e }, 2, T, W, pfx_66, WIG, L0 }, /* vmovw */
+    { { 0x7e }, 2, T, W, pfx_f3, W0, L0 }, /* vmovw */
 }, evex_map6[] = {
     { { 0x13 }, 2, T, R, pfx_66, W0, Ln }, /* vcvtph2psx */
     { { 0x13 }, 2, T, R, pfx_no, W0, LIG }, /* vcvtsh2ss */
--- a/xen/arch/x86/x86_emulate/decode.c
+++ b/xen/arch/x86/x86_emulate/decode.c
@@ -293,7 +293,7 @@ static const struct twobyte_table {
     [0xd0] = { DstImplicit|SrcMem|ModRM, simd_other },
     [0xd1 ... 0xd3] = { DstImplicit|SrcMem|ModRM, simd_128, 4 },
     [0xd4 ... 0xd5] = { DstImplicit|SrcMem|ModRM, simd_packed_int, d8s_vl },
-    [0xd6] = { DstMem|SrcImplicit|ModRM|Mov, simd_other, 3 },
+    [0xd6] = { DstMem|SrcImplicit|ModRM|Mov, simd_other, d8s_dq },
     [0xd7] = { DstReg|SrcImplicit|ModRM|Mov },
     [0xd8 ... 0xdf] = { DstImplicit|SrcMem|ModRM, simd_packed_int, d8s_vl },
     [0xe0] = { DstImplicit|SrcMem|ModRM, simd_packed_int, d8s_vl },
@@ -802,7 +802,7 @@ decode_twobyte(struct x86_emulate_state
         if ( s->vex.pfx == vex_f3 ) /* movq xmm/m64,xmm */
         {
     case X86EMUL_OPC_VEX_F3(0, 0x7e): /* vmovq xmm/m64,xmm */
-    case X86EMUL_OPC_EVEX_F3(0, 0x7e): /* vmovq xmm/m64,xmm */
+    case X86EMUL_OPC_EVEX_F3(0, 0x7e): /* vmov{d,q} xmm/mem,xmm */
             s->desc = DstImplicit | SrcMem | TwoOp;
             s->simd_size = simd_other;
             /* Avoid the s->desc clobbering of TwoOp below. */
@@ -1422,7 +1422,7 @@ int x86emul_decode(struct x86_emulate_st
                 break;
 
             case 0x7e: /* vmovq xmm/m64,xmm needs special casing */
-                if ( disp8scale == 2 && s->evex.pfx == vex_f3 )
+                if ( disp8scale == 2 && s->evex.pfx == vex_f3 && s->evex.w )
                     disp8scale = 3;
                 break;
 
@@ -1531,13 +1531,13 @@ int x86emul_decode(struct x86_emulate_st
                     s->fp16 = true;
                 break;
 
-            case 0x6e: /* vmovw r/m16, xmm */
+            case 0x6e: /* vmovw r/x/m16, xmm */
                 d = (d & ~SrcMask) | SrcMem16;
                 /* fall through */
-            case 0x7e: /* vmovw xmm, r/m16 */
+            case 0x7e: /* vmovw xmm, r/x/m16 */
+                s->fp16 = true;
                 if ( s->evex.pfx == vex_66 )
-                    s->fp16 = true;
-                s->simd_size = simd_none;
+                    s->simd_size = simd_none;
                 break;
 
             case 0x78: case 0x79: /* vcvt{,t}ph2u{d,q}q, vcvt{,t}sh2usi */
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4918,13 +4918,17 @@ x86_emulate(
         op_bytes = 8;
         goto simd_0f_int;
 
-    case X86EMUL_OPC_EVEX_F3(0x0f, 0x7e): /* vmovq xmm/m64,xmm */
-    case X86EMUL_OPC_EVEX_66(0x0f, 0xd6): /* vmovq xmm,xmm/m64 */
-        generate_exception_if(evex.lr || !evex.w || evex.opmsk || evex.brs,
-                              X86_EXC_UD);
-        visa_check(f);
+    case X86EMUL_OPC_EVEX_F3(0x0f, 0x7e): /* vmov{d,q} xmm/mem,xmm */
+    case X86EMUL_OPC_EVEX_66(0x0f, 0xd6): /* vmov{d,q} xmm,xmm/mem */
+    case X86EMUL_OPC_EVEX_F3(5, 0x6e): /* vmovw xmm/m16,xmm */
+    case X86EMUL_OPC_EVEX_F3(5, 0x7e): /* vmovw xmm,xmm/m16 */
+        generate_exception_if(evex.lr || evex.opmsk || evex.brs, X86_EXC_UD);
+        if ( evex.w )
+            visa_check(f);
+        else
+            vcpu_must_have(avx10, 2);
         d |= TwoOp;
-        op_bytes = 8;
+        op_bytes = 2 << (!state->fp16 + evex.w);
         goto simd_zmm;
 
 #endif /* !X86EMUL_NO_SIMD */



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:18:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:18:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854344.1267576 (Exim 4.92)
	(envelope-from )
	id 1tLJnr-0007lT-1P; Wed, 11 Dec 2024 10:18:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854344.1267576; Wed, 11 Dec 2024 10:18: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 1tLJnq-0007lM-Ug; Wed, 11 Dec 2024 10:18:46 +0000
Received: by outflank-mailman (input) for mailman id 854344;
 Wed, 11 Dec 2024 10:18: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 1tLJnp-0006nP-UQ
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:18:45 +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 4d895a98-b7a9-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 11:18:45 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-38634c35129so3090165f8f.3
 for ; Wed, 11 Dec 2024 02:18: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
 98e67ed59e1d1-2ef4600d14fsm11233196a91.45.2024.12.11.02.18.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:18: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: 4d895a98-b7a9-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733912324; x=1734517124; 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=JX8A7wpZkzT/ToT7H0QDSiHEuQp9oj/HteeDtBUydIE=;
        b=OsaMjN7iw79ezQKnbqjjzCqfhoFbFBSNtJXk/lOwffLtnwqHMM5rGnUX9F11nxPGKg
         CPTLiv+BQESLFSqAFm84jBAEd2tdH69ncu+vcqeu7sFDsJHafV+XdpwEHJITsSchUy9n
         MGvzn+IWZ1uP2RFJD4O4lX6zU+zjadOIauA32cCbKqDKjeYWIaTnPnXwjTydxcA1ftJ4
         TX4f1hQJBvZN3978sRkafjCWfEbu0zfJCl7jRR6WlG5xoyww4W2jvfrIg2HBteuALcxJ
         JhamPiIWBBnrpsXop5/g9p8xk7lVJUHo0ff56fC60cYV/JrtJgGPRfYriupb4XhN+kbg
         fOdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733912324; x=1734517124;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=JX8A7wpZkzT/ToT7H0QDSiHEuQp9oj/HteeDtBUydIE=;
        b=UO6VAwPAXgbLPd46jAf565kcxu7P05pA3o5OZ2g0emmFgzE9shEPTlMUpe37L1fr8c
         aMSqn7Bj10Imq5Mli443+idokWtcYjMBBBss7N+5DH62mXKse0J8uzJxId6f/KChbd9o
         HqNzFc62OTut5Gc7pM+0WVrYnVlkMF8dkupvJ/ltERqCncyv8mXuhfPikNHsvkmAb3BI
         BWlM4+Ei2cbYusRAB4ChFBc8mWNU7JjvVgu25py/zbAxfE3dmD73URyatmq64xzzGjB0
         dvScgHilAhE/dhbwSjWtefmREXoAhr8A61Fsxnd+oxXiEGp2Ey4GjxkvL4gqlIIksizt
         8ikw==
X-Gm-Message-State: AOJu0Yxw8aNnoDlN5dTAKLCII1OoII0YaQOU+zf40eWW5iUUJxbcymXc
	7nyqQze2cmMQXelY1L2vDHHr3oHnx+gVRoWzjM/q781bOlAtY62IHMe7pDybkRJ98upR7aMeQjs
	=
X-Gm-Gg: ASbGncvTpwczlO4NuNjXTByjqQyiRjr4lDfg1OZtFpBA8o3rIaRoJTtuHG8dlgQNErq
	dx59R0qp2qJGhzL2xuE3vMY8sU7uJUTyjo1gQXzNkeRMxjX136J+2CFGS9yrTssbRVlxImv2v32
	BSPi7yMR91x6qLXbX1SZA0MvLiy/ZpmeRDUvLS2VTUnbrXWgXZwHY6aB86X5uhHigilONUWQ4we
	ANCtyX1BRjSUD+tcHf7rpzb1abm4sWD6s8b3GNNJFa5KTUpDS0SxPRQrJUUhOlXqEMPdhjX/1J2
	U4aklf74e1qE9No/XdV7usDU1JiGDHnaK1WH/vw=
X-Google-Smtp-Source: AGHT+IE2HAta4jh6z8md2+tzdwRYLSsgaYg8DUe98j9Af2So7N5jx9qFg0/VCxv+aOXkHhKxHecw2A==
X-Received: by 2002:a5d:5846:0:b0:385:df4e:3645 with SMTP id ffacd0b85a97d-3864cecfaefmr1852440f8f.50.1733912324538;
        Wed, 11 Dec 2024 02:18:44 -0800 (PST)
Message-ID: <953301b9-4cd6-4742-9486-bf31121cb3ef@suse.com>
Date: Wed, 11 Dec 2024 11:18:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v3 10/16] x86emul: support AVX10.2 media insns
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@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: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

These are all very similar to various existing insns.

Signed-off-by: Jan Beulich 
---
SDE: ???
---
v3: New.

--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -717,6 +717,20 @@ static const struct test avx10_2_all[] =
     INSN(comxsd,           f3,   0f, 2f,    el,    q, el),
     INSN(comxsh,           f2, map5, 2f,    el, fp16, el),
     INSN(comxss,           f2,   0f, 2f,    el,    d, el),
+    INSN(dpphps,             , 0f38, 52,    vl,    d, vl),
+    INSN(mpsadbw,          f3, 0f3a, 42,    vl, d_nb, vl),
+    INSN(pdpbssd,          f2, 0f38, 50,    vl,    d, vl),
+    INSN(pdpbssds,         f2, 0f38, 51,    vl,    d, vl),
+    INSN(pdpbsud,          f3, 0f38, 50,    vl,    d, vl),
+    INSN(pdpbsuds,         f3, 0f38, 51,    vl,    d, vl),
+    INSN(pdpbuud,            , 0f38, 50,    vl,    d, vl),
+    INSN(pdpbuuds,           , 0f38, 51,    vl,    d, vl),
+    INSN(pdpwsud,          f3, 0f38, d2,    vl,    d, vl),
+    INSN(pdpwsuds,         f3, 0f38, d3,    vl,    d, vl),
+    INSN(pdpwusd,          66, 0f38, d2,    vl,    d, vl),
+    INSN(pdpwusds,         66, 0f38, d3,    vl,    d, vl),
+    INSN(pdpwuud,            , 0f38, d2,    vl,    d, vl),
+    INSN(pdpwuuds,           , 0f38, d3,    vl,    d, vl),
     INSN(ucomxsd,          f3,   0f, 2e,    el,    q, el),
     INSN(ucomxsh,          f2, map5, 2e,    el, fp16, el),
     INSN(ucomxss,          f2,   0f, 2e,    el,    d, el),
--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -1927,8 +1927,15 @@ static const struct evex {
     { { 0x4d }, 2, T, R, pfx_66, Wn, LIG }, /* vrcp14s{s,d} */
     { { 0x4e }, 2, T, R, pfx_66, Wn, Ln }, /* vrsqrt14p{s,d} */
     { { 0x4f }, 2, T, R, pfx_66, Wn, LIG }, /* vrsqrt14s{s,d} */
+    { { 0x50 }, 2, T, R, pfx_no, W0, Ln }, /* vpdpbuud */
     { { 0x50 }, 2, T, R, pfx_66, W0, Ln }, /* vpdpbusd */
+    { { 0x50 }, 2, T, R, pfx_f3, W0, Ln }, /* vpdpbsud */
+    { { 0x50 }, 2, T, R, pfx_f2, W0, Ln }, /* vpdpbssd */
+    { { 0x51 }, 2, T, R, pfx_no, W0, Ln }, /* vpdpbuuds */
     { { 0x51 }, 2, T, R, pfx_66, W0, Ln }, /* vpdpbusds */
+    { { 0x51 }, 2, T, R, pfx_f3, W0, Ln }, /* vpdpbsuds */
+    { { 0x51 }, 2, T, R, pfx_f2, W0, Ln }, /* vpdpbssds */
+    { { 0x52 }, 2, T, R, pfx_no, W0, Ln }, /* vdpphps */
     { { 0x52 }, 2, T, R, pfx_66, W0, Ln }, /* vpdpwssd */
     { { 0x52 }, 2, T, R, pfx_f3, W0, Ln }, /* vdpbf16ps */
     { { 0x52 }, 2, T, R, pfx_f2, W0, L2 }, /* vp4dpwssd */
@@ -2029,6 +2036,12 @@ static const struct evex {
     { { 0xcc }, 2, T, R, pfx_66, Wn, L2 }, /* vrsqrt28p{s,d} */
     { { 0xcd }, 2, T, R, pfx_66, Wn, LIG }, /* vrsqrt28s{s,d} */
     { { 0xcf }, 2, T, R, pfx_66, W0, Ln }, /* vgf2p8mulb */
+    { { 0xd2 }, 2, T, R, pfx_no, W0, Ln }, /* vpdpwuud */
+    { { 0xd2 }, 2, T, R, pfx_66, W0, Ln }, /* vpdpwusd */
+    { { 0xd2 }, 2, T, R, pfx_f3, W0, Ln }, /* vpdpwsud */
+    { { 0xd3 }, 2, T, R, pfx_no, W0, Ln }, /* vpdpwuuds */
+    { { 0xd3 }, 2, T, R, pfx_66, W0, Ln }, /* vpdpwusds */
+    { { 0xd3 }, 2, T, R, pfx_f3, W0, Ln }, /* vpdpwsuds */
     { { 0xdc }, 2, T, R, pfx_66, WIG, Ln }, /* vaesenc */
     { { 0xdd }, 2, T, R, pfx_66, WIG, Ln }, /* vaesenclast */
     { { 0xde }, 2, T, R, pfx_66, WIG, Ln }, /* vaesdec */
@@ -2073,6 +2086,7 @@ static const struct evex {
     { { 0x3e }, 3, T, R, pfx_66, Wn, Ln }, /* vpcmpu{b,w} */
     { { 0x3f }, 3, T, R, pfx_66, Wn, Ln }, /* vpcmp{b,w} */
     { { 0x42 }, 3, T, R, pfx_66, W0, Ln }, /* vdbpsadbw */
+    { { 0x42 }, 3, T, R, pfx_f3, W0, Ln }, /* vmpsadbw */
     { { 0x43 }, 3, T, R, pfx_66, Wn, L1|L2 }, /* vshufi{32x4,64x2} */
     { { 0x44 }, 3, T, R, pfx_66, WIG, Ln }, /* vpclmulqdq */
     { { 0x50 }, 3, T, R, pfx_66, Wn, Ln }, /* vrangep{s,d} */
--- a/xen/arch/x86/x86_emulate/decode.c
+++ b/xen/arch/x86/x86_emulate/decode.c
@@ -433,8 +433,8 @@ static const struct ext0f38_table {
     [0xcb] = { .simd_size = simd_other, .d8s = d8s_vl },
     [0xcc ... 0xcd] = { .simd_size = simd_other, .two_op = 1, .d8s = d8s_vl },
     [0xcf] = { .simd_size = simd_packed_int, .d8s = d8s_vl },
-    [0xd2] = { .simd_size = simd_other },
-    [0xd3] = { .simd_size = simd_other },
+    [0xd2] = { .simd_size = simd_other, .d8s = d8s_vl },
+    [0xd3] = { .simd_size = simd_other, .d8s = d8s_vl },
     [0xd6] = { .simd_size = simd_other, .d8s = d8s_vl },
     [0xd7] = { .simd_size = simd_scalar_vexw, .d8s = d8s_dq },
     [0xda] = { .simd_size = simd_other },
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -6201,6 +6201,24 @@ x86_emulate(
         avx512_vlen_check(true);
         goto simd_zmm;
 
+    case X86EMUL_OPC_EVEX   (0x0f38, 0x50): /* vpdpbuud [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_F3(0x0f38, 0x50): /* vpdpbsud [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_F2(0x0f38, 0x50): /* vpdpbssd [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX   (0x0f38, 0x51): /* vpdpbuuds [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_F3(0x0f38, 0x51): /* vpdpbsuds [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_F2(0x0f38, 0x51): /* vpdpbssds [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX   (0x0f38, 0xd2): /* vpdpwuud [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_66(0x0f38, 0xd2): /* vpdpwusd [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_F3(0x0f38, 0xd2): /* vpdpwsud [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX   (0x0f38, 0xd3): /* vpdpwuuds [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_66(0x0f38, 0xd3): /* vpdpwusds [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_F3(0x0f38, 0xd3): /* vpdpwsuds [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX   (0x0f38, 0x52): /* vdpphps [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+        generate_exception_if(evex.w, X86_EXC_UD);
+        vcpu_must_have(avx10, 2);
+        op_bytes = 16 << evex.lr;
+        goto avx512f_no_sae;
+
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x8f): /* vpshufbitqmb [xyz]mm/mem,[xyz]mm,k{k} */
         generate_exception_if(evex.w || !evex.r || !evex.R || evex.z, X86_EXC_UD);
         /* fall through */
@@ -7660,6 +7678,14 @@ x86_emulate(
         visa_check(bw);
         goto opmask_shift_imm;
 
+    case X86EMUL_OPC_EVEX_F3(0x0f3a, 0x42): /* vmpsadbw $imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+        generate_exception_if(evex.w || evex.brs, X86_EXC_UD);
+        vcpu_must_have(avx10, 2);
+        avx512_vlen_check(false);
+        op_bytes = 16 << evex.lr;
+        fault_suppression = false;
+        goto simd_imm8_zmm;
+
     case X86EMUL_OPC_66(0x0f3a, 0x44):     /* pclmulqdq $imm8,xmm/m128,xmm */
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x44): /* vpclmulqdq $imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
         host_and_vcpu_must_have(pclmulqdq);



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:20:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:20:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854358.1267586 (Exim 4.92)
	(envelope-from )
	id 1tLJp9-0000vs-EQ; Wed, 11 Dec 2024 10:20:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854358.1267586; Wed, 11 Dec 2024 10:20: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 1tLJp9-0000vl-BZ; Wed, 11 Dec 2024 10:20:07 +0000
Received: by outflank-mailman (input) for mailman id 854358;
 Wed, 11 Dec 2024 10: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 1tLJp8-0000mx-1K
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:20: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 7cee6b84-b7a9-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 11:20:04 +0100 (CET)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-385d7b4da2bso5354183f8f.1
 for ; Wed, 11 Dec 2024 02:20: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
 d2e1a72fcca58-725e34bbb22sm6192335b3a.81.2024.12.11.02.20.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:20: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: 7cee6b84-b7a9-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733912404; x=1734517204; 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=OZVqOnW0T4/VwuftVOiXwu0ymxGzeAMEDZBrCeulqK0=;
        b=Xnp+RTSzifYDM3ChjTDz7SyJS2o/puiHh7Wahyco46XN66+qx7WSfFAEGLLwuIA8d/
         1dWYbvCYlfBVEINUg93BwItV92QYqw0iKgJgn3ri6y/nSBWma+xI8a5O4BaOll6PQgWQ
         yFIxSN3Lyd+9U9dHN3RMRG20v1o8uSD6IRd8p53tHnjA8blhbwr3xmfzxtwjlQmRA8c5
         Abwg5gHruoeIgDvpe5OCPve9y8K+TgOb+gRKcOuCpOvezUFNVl0EW7Lbf6auoTRE1fVz
         NhLYhx1qLN84jtEVQWRXL83I7abaaMWQw0wiJ88cD7canPGjOZlGpBcok8klNXH33fy8
         F32w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733912404; x=1734517204;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=OZVqOnW0T4/VwuftVOiXwu0ymxGzeAMEDZBrCeulqK0=;
        b=KvcruY96wi+8ufxT8WV1pYKvUC1EPyT2S8KchwFkrvNnSiZAFa0Sjl+R4mEApoD4Np
         bhzF2kZU8TFLleavmHf1zRYOHK4UftFfoVWp9rOqbVRf2ULPIswwQJK5Sr5EM2e5pK32
         rTm/rvbWiaEsuVzmQkoOWaXJUObpWydoDfcxPTsgDfL9VyjpGoCYYVacXCzdKv5UPVTl
         19cB9CtgRaR+O4OzDTAcsN5OuA8/WjNmdASR/7ubQJFSZS5g+jppnsUtCjzCBbwaJUwc
         L2uljAERNX5K97C/F087SsH6oTTYrksBpUN9UMynV+JSkWJnwNUdMRIlYQFAm3+9Dorg
         epNA==
X-Gm-Message-State: AOJu0YxRxIAvwxKjZbhFGNlh3R2NpnfinDTq7X5KyQ16+BPjy7z+9G8i
	1sTDXCzYRD0FB1j0sj+qxzBU0ZjUlpS0ERxvhQ3rkTBFVEU9Tk+b7d/c2sZ9L5vfQR95XPoEyG4
	=
X-Gm-Gg: ASbGncsp2TcB6JsxI5JbFmVhliv+umRDcmRcqwRHT4ltnBs4l6ptCj3RVh4QG2II0V8
	Zle3r0HTntw54HEzOrG9aBxzSHcboY7Bc+n1BftZTZoO0aLaVVXoY85c3Dg7LNesZ3WyA6NqSaj
	1AdMgsDmyBnMdwk96HH9fbyfAgksumXlYGVZkCxc0lLYZCxRR/1+g0udTHxHSu7VkZWRGrkn73Y
	/jF22g+oy5R7UoT0TQR/oFFe1An544TaXEAXpiwXgnjgVVSaeZH0lz+k77NsdxMuUBeC6PNTqc9
	qSQUq2uxnGhowZALcBTjZMmuZwzClIOkmp8H1ko=
X-Google-Smtp-Source: AGHT+IEnYB0mCxJXoFvqhkvEObE+G0wTsBnjv1+dBmq8FgYKn17WizFNj6MO1LxNR4eYOWGVqUnalw==
X-Received: by 2002:a5d:6da4:0:b0:386:1ab5:f0e1 with SMTP id ffacd0b85a97d-3864ce968c0mr1868450f8f.14.1733912403910;
        Wed, 11 Dec 2024 02:20:03 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 11:19:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v3 12/16] x86emul: support AVX10.2 BFloat16 insns
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@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: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

These are all very similar to various existing insns. VGETEXPPBF16, not
living in the expected place, benefits from the respective
twobyte_table[] entry already having Mov (aka TwoOp).

Signed-off-by: Jan Beulich 
---
This still follows what spec version 001 says for VGETEXPPBF16. It moved
to map 6 (and be NP), yet so far no SDE is available to run the test
harness there with the changed encoding.

Spec rev 002 says VSCALEFPBF16, yet that's going to change to
VSCALEFNEPBF16.
---
SDE: ???
---
v3: New.

--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -713,16 +713,37 @@ static const struct test vpclmulqdq_all[
 };
 
 static const struct test avx10_2_all[] = {
+    INSN(addnepbf16,       66, map5, 58,    vl, bf16, vl),
+    INSN(cmppbf16,         f2, 0f3a, c2,    vl, bf16, vl),
     INSN(comsbf16,         66, map5, 2f,    el, bf16, el),
     INSN(comxsd,           f3,   0f, 2f,    el,    q, el),
     INSN(comxsh,           f2, map5, 2f,    el, fp16, el),
     INSN(comxss,           f2,   0f, 2f,    el,    d, el),
+    INSN(divnepbf16,       66, map5, 5e,    vl, bf16, vl),
     INSN(dpphps,             , 0f38, 52,    vl,    d, vl),
+    INSN(fmadd132nepbf16,    , map6, 98,    vl, bf16, vl),
+    INSN(fmadd213nepbf16,    , map6, a8,    vl, bf16, vl),
+    INSN(fmadd231nepbf16,    , map6, b8,    vl, bf16, vl),
+    INSN(fmsub132nepbf16,    , map6, 9a,    vl, bf16, vl),
+    INSN(fmsub213nepbf16,    , map6, aa,    vl, bf16, vl),
+    INSN(fmsub231nepbf16,    , map6, ba,    vl, bf16, vl),
+    INSN(fnmadd132nepbf16,   , map6, 9c,    vl, bf16, vl),
+    INSN(fnmadd213nepbf16,   , map6, ac,    vl, bf16, vl),
+    INSN(fnmadd231nepbf16,   , map6, bc,    vl, bf16, vl),
+    INSN(fnmsub132nepbf16,   , map6, 9e,    vl, bf16, vl),
+    INSN(fnmsub213nepbf16,   , map6, ae,    vl, bf16, vl),
+    INSN(fnmsub231nepbf16,   , map6, be,    vl, bf16, vl),
+    INSN(fpclasspbf16,     f2, 0f3a, 66,    vl, bf16, vl),
+    INSN(getexppbf16,      66, map5, 42,    vl, bf16, vl),
+    INSN(getmantpbf16,     f2, 0f3a, 26,    vl, bf16, vl),
+    INSN(maxpbf16,         66, map5, 5f,    vl, bf16, vl),
+    INSN(minpbf16,         66, map5, 5d,    vl, bf16, vl),
     INSN(minmax,           66, 0f3a, 52,    vl,   sd, vl),
     INSN(minmax,           66, 0f3a, 53,    el,   sd, el),
     INSN(minmaxpbf16,      f2, 0f3a, 52,    vl, bf16, vl),
     INSN(minmaxph,           , 0f3a, 52,    vl, fp16, vl),
     INSN(minmaxsh,           , 0f3a, 53,    el, fp16, el),
+    INSN(mulnepbf16,       66, map5, 59,    vl, bf16, vl),
     INSN(mpsadbw,          f3, 0f3a, 42,    vl, d_nb, vl),
     INSN(pdpbssd,          f2, 0f38, 50,    vl,    d, vl),
     INSN(pdpbssds,         f2, 0f38, 51,    vl,    d, vl),
@@ -736,6 +757,13 @@ static const struct test avx10_2_all[] =
     INSN(pdpwusds,         66, 0f38, d3,    vl,    d, vl),
     INSN(pdpwuud,            , 0f38, d2,    vl,    d, vl),
     INSN(pdpwuuds,           , 0f38, d3,    vl,    d, vl),
+    INSN(rcpph,              , map6, 4c,    vl, bf16, vl),
+    INSN(reducenepbf16,    f2, 0f3a, 56,    vl, bf16, vl),
+    INSN(rndscalenepbf16,  f2, 0f3a, 08,    vl, bf16, vl),
+    INSN(rsqrtph,            , map6, 4e,    vl, bf16, vl),
+    INSN(scalefnepbf16,      , map6, 2c,    vl, bf16, vl),
+    INSN(sqrtnepbf16,      66, map5, 51,    vl, bf16, vl),
+    INSN(subnepbf16,       66, map5, 5c,    vl, bf16, vl),
     INSN(ucomxsd,          f3,   0f, 2e,    el,    q, el),
     INSN(ucomxsh,          f2, map5, 2e,    el, fp16, el),
     INSN(ucomxss,          f2,   0f, 2e,    el,    d, el),
--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -2054,6 +2054,7 @@ static const struct evex {
     { { 0x05 }, 3, T, R, pfx_66, W1, Ln }, /* vpermilpd */
     { { 0x08 }, 3, T, R, pfx_no, W0, Ln }, /* vrndscaleph */
     { { 0x08 }, 3, T, R, pfx_66, W0, Ln }, /* vrndscaleps */
+    { { 0x08 }, 3, T, R, pfx_f2, W0, Ln }, /* vrndscalenepbf16 */
     { { 0x09 }, 3, T, R, pfx_66, W1, Ln }, /* vrndscalepd */
     { { 0x0a }, 3, T, R, pfx_no, W0, LIG }, /* vrndscalesh */
     { { 0x0a }, 3, T, R, pfx_66, W0, LIG }, /* vrndscaless */
@@ -2077,6 +2078,7 @@ static const struct evex {
     { { 0x25 }, 3, T, R, pfx_66, Wn, Ln }, /* vpternlog{d,q} */
     { { 0x26 }, 3, T, R, pfx_no, W0, Ln }, /* vgetmantph */
     { { 0x26 }, 3, T, R, pfx_66, Wn, Ln }, /* vgetmantp{s,d} */
+    { { 0x26 }, 3, T, R, pfx_f2, W0, Ln }, /* vgetmantpbf16 */
     { { 0x27 }, 3, T, R, pfx_no, W0, LIG }, /* vgetmantsh */
     { { 0x27 }, 3, T, R, pfx_66, Wn, LIG }, /* vgetmants{s,d} */
     { { 0x38 }, 3, T, R, pfx_66, Wn, L1|L2 }, /* vinserti{32x4,64x2} */
@@ -2100,10 +2102,12 @@ static const struct evex {
     { { 0x55 }, 3, T, R, pfx_66, Wn, LIG }, /* vfixumpimms{s,d} */
     { { 0x56 }, 3, T, R, pfx_no, W0, Ln }, /* vreduceph */
     { { 0x56 }, 3, T, R, pfx_66, Wn, Ln }, /* vreducep{s,d} */
+    { { 0x56 }, 3, T, R, pfx_f2, W0, Ln }, /* vreducenepbf16 */
     { { 0x57 }, 3, T, R, pfx_no, W0, LIG }, /* vreducesh */
     { { 0x57 }, 3, T, R, pfx_66, Wn, LIG }, /* vreduces{s,d} */
     { { 0x66 }, 3, T, R, pfx_no, W0, Ln }, /* vfpclassph */
     { { 0x66 }, 3, T, R, pfx_66, Wn, Ln }, /* vfpclassp{s,d} */
+    { { 0x66 }, 3, T, R, pfx_f2, W0, Ln }, /* vfpclasspbf16 */
     { { 0x67 }, 3, T, R, pfx_no, W0, LIG }, /* vfpclasssh */
     { { 0x67 }, 3, T, R, pfx_66, Wn, LIG }, /* vfpclasss{s,d} */
     { { 0x70 }, 3, T, R, pfx_66, W1, Ln }, /* vshldw */
@@ -2112,6 +2116,7 @@ static const struct evex {
     { { 0x73 }, 3, T, R, pfx_66, Wn, Ln }, /* vshrd{d,q} */
     { { 0xc2 }, 3, T, R, pfx_no, W0, Ln }, /* vcmpph */
     { { 0xc2 }, 3, T, R, pfx_f3, W0, LIG }, /* vcmpsh */
+    { { 0xc2 }, 3, T, R, pfx_f2, W0, Ln }, /* vcmppbf16 */
     { { 0xce }, 3, T, R, pfx_66, W1, Ln }, /* vgf2p8affineqb */
     { { 0xcf }, 3, T, R, pfx_66, W1, Ln }, /* vgf2p8affineinvqb */
 }, evex_map5[] = {
@@ -2127,11 +2132,15 @@ static const struct evex {
     { { 0x2f }, 2, T, R, pfx_no, W0, LIG }, /* vcomish */
     { { 0x2f }, 2, T, R, pfx_66, W0, LIG }, /* vcomsbf16 */
     { { 0x2f }, 2, T, R, pfx_f2, W0, LIG }, /* vcomxsh */
+    { { 0x42 }, 2, T, R, pfx_66, W0, Ln }, /* vgetexppbf16 */
     { { 0x51 }, 2, T, R, pfx_no, W0, Ln }, /* vsqrtph */
+    { { 0x51 }, 2, T, R, pfx_66, W0, Ln }, /* vsqrtnepbf16 */
     { { 0x51 }, 2, T, R, pfx_f3, W0, LIG }, /* vsqrtsh */
     { { 0x58 }, 2, T, R, pfx_no, W0, Ln }, /* vaddph */
+    { { 0x58 }, 2, T, R, pfx_66, W0, Ln }, /* vaddnepbf16 */
     { { 0x58 }, 2, T, R, pfx_f3, W0, LIG }, /* vaddsh */
     { { 0x59 }, 2, T, R, pfx_no, W0, Ln }, /* vmulph */
+    { { 0x59 }, 2, T, R, pfx_66, W0, Ln }, /* vmulnepbf16 */
     { { 0x59 }, 2, T, R, pfx_f3, W0, LIG }, /* vmulsh */
     { { 0x5a }, 2, T, R, pfx_no, W0, Ln }, /* vcvtph2pd */
     { { 0x5a }, 2, T, R, pfx_66, W1, Ln }, /* vcvtpd2ph */
@@ -2142,12 +2151,16 @@ static const struct evex {
     { { 0x5b }, 2, T, R, pfx_66, W0, Ln }, /* vcvtph2dq */
     { { 0x5b }, 2, T, R, pfx_f3, W0, Ln }, /* vcvttph2dq */
     { { 0x5c }, 2, T, R, pfx_no, W0, Ln }, /* vsubph */
+    { { 0x5c }, 2, T, R, pfx_66, W0, Ln }, /* vsubnepbf16 */
     { { 0x5c }, 2, T, R, pfx_f3, W0, LIG }, /* vsubsh */
     { { 0x5d }, 2, T, R, pfx_no, W0, Ln }, /* vminph */
+    { { 0x5d }, 2, T, R, pfx_66, W0, Ln }, /* vminpbf16 */
     { { 0x5d }, 2, T, R, pfx_f3, W0, LIG }, /* vminsh */
     { { 0x5e }, 2, T, R, pfx_no, W0, Ln }, /* vdivph */
+    { { 0x5e }, 2, T, R, pfx_66, W0, Ln }, /* vdivnepbf16 */
     { { 0x5e }, 2, T, R, pfx_f3, W0, LIG }, /* vdivsh */
     { { 0x5f }, 2, T, R, pfx_no, W0, Ln }, /* vmaxph */
+    { { 0x5f }, 2, T, R, pfx_66, W0, Ln }, /* vmaxpbf16 */
     { { 0x5f }, 2, T, R, pfx_f3, W0, LIG }, /* vmaxsh */
     { { 0x6e }, 2, T, R, pfx_66, WIG, L0 }, /* vmovw */
     { { 0x6e }, 2, T, R, pfx_f3, W0, L0 }, /* vmovw */
@@ -2173,12 +2186,15 @@ static const struct evex {
 }, evex_map6[] = {
     { { 0x13 }, 2, T, R, pfx_66, W0, Ln }, /* vcvtph2psx */
     { { 0x13 }, 2, T, R, pfx_no, W0, LIG }, /* vcvtsh2ss */
+    { { 0x2c }, 2, T, R, pfx_no, W0, Ln }, /* vscalefnepbf16 */
     { { 0x2c }, 2, T, R, pfx_66, W0, Ln }, /* vscalefph */
     { { 0x2d }, 2, T, R, pfx_66, W0, LIG }, /* vscalefsh */
     { { 0x42 }, 2, T, R, pfx_66, W0, Ln }, /* vgetexpph */
     { { 0x43 }, 2, T, R, pfx_66, W0, LIG }, /* vgetexpsh */
+    { { 0x4c }, 2, T, R, pfx_no, W0, Ln }, /* vrcppbf16 */
     { { 0x4c }, 2, T, R, pfx_66, W0, Ln }, /* vrcpph */
     { { 0x4d }, 2, T, R, pfx_66, W0, LIG }, /* vrcpsh */
+    { { 0x4e }, 2, T, R, pfx_no, W0, Ln }, /* vrsqrtpbf16 */
     { { 0x4e }, 2, T, R, pfx_66, W0, Ln }, /* vrsqrtph */
     { { 0x4f }, 2, T, R, pfx_66, W0, LIG }, /* vrsqrtsh */
     { { 0x56 }, 2, T, R, pfx_f3, W0, Ln }, /* vfmaddcph */
--- a/xen/arch/x86/x86_emulate/decode.c
+++ b/xen/arch/x86/x86_emulate/decode.c
@@ -1472,31 +1472,34 @@ int x86emul_decode(struct x86_emulate_st
             {
                 switch ( b )
                 {
-                case 0x08: /* vrndscaleph */
+                case 0x08: /* vrndscale{ph,nepbf16} */
+                case 0x26: /* vfpclassp{h,bf16} */
+                case 0x52: /* vminmaxp{h,bf16} */
+                case 0x56: /* vgetmantp{h,bf16} */
+                case 0x66: /* vreduce{ph,nepbf16} */
+                    if ( !s->evex.pfx || s->evex.pfx == vex_f2 )
+                        s->fp16 = true;
+                    break;
+
                 case 0x0a: /* vrndscalesh */
-                case 0x26: /* vfpclassph */
                 case 0x27: /* vfpclasssh */
                 case 0x53: /* vminmaxsh */
-                case 0x56: /* vgetmantph */
                 case 0x57: /* vgetmantsh */
-                case 0x66: /* vreduceph */
                 case 0x67: /* vreducesh */
                     if ( !s->evex.pfx )
                         s->fp16 = true;
                     break;
 
-                case 0x52: /* vminmaxp{h,bf16} */
-                    if ( !s->evex.pfx || s->evex.pfx == vex_f2 )
-                        s->fp16 = true;
-                    break;
-
-                case 0xc2: /* vpcmp{p,s}h */
-                    if ( !(s->evex.pfx & VEX_PREFIX_DOUBLE_MASK) )
+                case 0xc2: /* vpcmp{p,s}h, vcmppbf16 */
+                    if ( s->evex.pfx != vex_66 )
                         s->fp16 = true;
                     break;
                 }
 
-                disp8scale = decode_disp8scale(ext0f3a_table[b].d8s, s);
+                if ( s->fp16 && s->evex.pfx == vex_f2 && !s->evex.brs )
+                    disp8scale = 4 + s->evex.lr;
+                else
+                    disp8scale = decode_disp8scale(ext0f3a_table[b].d8s, s);
             }
             break;
 
@@ -1504,7 +1507,7 @@ int x86emul_decode(struct x86_emulate_st
             switch ( b )
             {
             default:
-                if ( !(s->evex.pfx & VEX_PREFIX_DOUBLE_MASK) )
+                if ( s->evex.pfx != vex_f2 )
                     s->fp16 = true;
                 break;
 
@@ -1534,6 +1537,11 @@ int x86emul_decode(struct x86_emulate_st
                 s->simd_size = simd_none;
                 break;
 
+            case 0x5a: /* vcvt{p,s}d2{p,s}h, vcvt{p,s}h2{p,s}d */
+                if ( !(s->evex.pfx & VEX_PREFIX_DOUBLE_MASK) )
+                    s->fp16 = true;
+                break;
+
             case 0x5b: /* vcvt{d,q}q2ph, vcvt{,t}ph2dq */
                 if ( s->evex.pfx && s->evex.pfx != vex_f2 )
                     s->fp16 = true;
@@ -1586,6 +1594,14 @@ int x86emul_decode(struct x86_emulate_st
                 disp8scale = 1;
                 break;
 
+            case 0x42: /* vgetexppbf16 needs special casing */
+                if ( s->evex.pfx == vex_66 )
+                {
+                    s->simd_size = simd_packed_fp;
+                    disp8scale = s->evex.brs ? 1 : 4 + s->evex.lr;
+                }
+                break;
+
             case 0x5a: /* vcvtph2pd needs special casing */
                 if ( !s->evex.pfx && !s->evex.brs )
                     disp8scale -= 2;
@@ -1618,7 +1634,7 @@ int x86emul_decode(struct x86_emulate_st
             switch ( b )
             {
             default:
-                if ( s->evex.pfx == vex_66 )
+                if ( !(s->evex.pfx & VEX_PREFIX_SCALAR_MASK) )
                     s->fp16 = true;
                 break;
 
@@ -1950,6 +1966,13 @@ int x86emul_decode(struct x86_emulate_st
             s->op_bytes = 4 >> s->fp16;
             break;
         case vex_f2:
+            if ( s->fp16 )
+            {
+                ASSERT(evex_encoded());
+                generate_exception_if(s->evex.w, X86_EXC_UD);
+                s->op_bytes = 0;
+                break;
+            }
             generate_exception_if(evex_encoded() && !s->evex.w, X86_EXC_UD);
             s->op_bytes = 8;
             break;
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -7319,6 +7319,20 @@ x86_emulate(
         avx512_vlen_check(b & 2);
         goto simd_imm8_zmm;
 
+    case X86EMUL_OPC_EVEX_F2(0x0f3a, 0x66): /* vfpclasspbf16 $imm8,[xyz]mm/mem,k{k} */
+    case X86EMUL_OPC_EVEX_F2(0x0f3a, 0xc2): /* vcmppbf16 $imm8,[xyz]mm/mem,[xyz]mm,k{k} */
+        generate_exception_if(!evex.r || !evex.R || evex.z, X86_EXC_UD);
+        /* fall through */
+    case X86EMUL_OPC_EVEX_F2(0x0f3a, 0x08): /* vrndscalenepbf16 $imm8,[xyz]mm/mem,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_F2(0x0f3a, 0x26): /* vgetmantpbf16 $imm8,[xyz]mm/mem,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_F2(0x0f3a, 0x56): /* vreducenepbf16 $imm8,[xyz]mm/mem,[xyz]mm{k} */
+        generate_exception_if(evex.w || (ea.type != OP_MEM && evex.brs),
+                              X86_EXC_UD);
+        vcpu_must_have(avx10, 2);
+        avx512_vlen_check(false);
+        op_bytes = 16 << evex.lr;
+        goto simd_imm8_zmm;
+
 #endif /* X86EMUL_NO_SIMD */
 
     CASE_SIMD_PACKED_INT(0x0f3a, 0x0f): /* palignr $imm8,{,x}mm/mem,{,x}mm */
@@ -7951,6 +7965,36 @@ x86_emulate(
         generate_exception_if(evex.w, X86_EXC_UD);
         goto avx512f_all_fp;
 
+    case X86EMUL_OPC_EVEX_66(5, 0x42): /* vgetexppbf16 [xyz]mm/mem,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_66(5, 0x51): /* vsqrtnepbf16 [xyz]mm/mem,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_66(5, 0x58): /* vaddnepbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_66(5, 0x59): /* vmulnepbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_66(5, 0x5c): /* vsubnepbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_66(5, 0x5d): /* vminpbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_66(5, 0x5e): /* vdivnepbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_66(5, 0x5f): /* vmaxpbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX(6, 0x2c): /* vscalefnepbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX(6, 0x4c): /* vrcppbf16 [xyz]mm/mem,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX(6, 0x4e): /* vrsqrtpbf16 [xyz]mm/mem,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX(6, 0x98): /* vfmadd132nepbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX(6, 0x9a): /* vfmsub132nepbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX(6, 0x9c): /* vfnmadd132nepbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX(6, 0x9e): /* vfnmsub132nepbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX(6, 0xa8): /* vfmadd213nepbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX(6, 0xaa): /* vfmsub213nepbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX(6, 0xac): /* vfnmadd213nepbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX(6, 0xae): /* vfnmsub213nepbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX(6, 0xb8): /* vfmadd231nepbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX(6, 0xba): /* vfmsub231nepbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX(6, 0xbc): /* vfnmadd231nepbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX(6, 0xbe): /* vfnmsub231nepbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+        generate_exception_if(evex.w || (ea.type != OP_MEM && evex.brs),
+                              X86_EXC_UD);
+        vcpu_must_have(avx10, 2);
+        avx512_vlen_check(false);
+        op_bytes = 16 << evex.lr;
+        goto simd_zmm;
+
     CASE_SIMD_ALL_FP(_EVEX, 5, 0x5a):  /* vcvtp{h,d}2p{h,d} [xyz]mm/mem,[xyz]mm{k} */
                                        /* vcvts{h,d}2s{h,d} xmm/mem,xmm,xmm{k} */
         visa_check(_fp16);



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:21:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:21:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854369.1267596 (Exim 4.92)
	(envelope-from )
	id 1tLJqA-0001jq-NL; Wed, 11 Dec 2024 10:21:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854369.1267596; Wed, 11 Dec 2024 10:21: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 1tLJqA-0001jj-Kh; Wed, 11 Dec 2024 10:21:10 +0000
Received: by outflank-mailman (input) for mailman id 854369;
 Wed, 11 Dec 2024 10:21: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 1tLJi8-0003z3-H0
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:12:52 +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 778aacfc-b7a8-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 11:12:46 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-385ed7f6605so2929507f8f.3
 for ; Wed, 11 Dec 2024 02:12:50 -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
 d9443c01a7336-216281f45a2sm73565155ad.250.2024.12.11.02.12.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:12: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: 778aacfc-b7a8-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733911970; x=1734516770; 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=PydLQvHGoQVq8w5xg8EGioPd9dUoTx6VVtqXrfukRCE=;
        b=B0KGl3zOeF6/BNdIQe/oizfe0wxJdGCTAHmbGhW1zjZv1tJs5h/nClSnqzfykpSNi1
         bI63XkqmEGmAj6ijAcEQXha06dHnJKTEvKgHX3fBtzy8GVOIwS/BIgUlblsOL9tU/LFm
         c2ghapV6ov70RdmLZsjzcpDf3PCHwjpXGicuC5h0YSwOnmRZdm9zWQcwbH99Az1muJX6
         h015GBFDnTgRkqvb4J95wIysPb2yfKsLrDFVEby8RzCmIQEVwlQa0xUkKPfAdEgDJoyZ
         KJVEVK+H2KAGG0djWajpT3cFk227TTPVIe0e7UmgV0C4AvudnF/qvMinXRnMfCG3bpZs
         wJ5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733911970; x=1734516770;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=PydLQvHGoQVq8w5xg8EGioPd9dUoTx6VVtqXrfukRCE=;
        b=vy90BgtRV2GcxVxWn2DViZeZBjDeXva0s3so297HZZG7EnvP6uLCkAarv0CwLL5yqW
         CDHP0i1r9Nxlj/rSycn+0uD82xX8JCu6jl/9sJV/rAh3/Lhb7h1LkhAeD67SZ9lGVZic
         Z+X/TKsvM8BBLSVp1S61K2hM8k+xGbgNhQRUQr7HQBnmCpEFxqDpv63/GfnThd8/pGyg
         74nCzp7xFIRA9jHLImlHjfEtW/wAyTs6+P7TkdvM8+1wf3A7K7PT+Lbr0pjUyvBaPIao
         Za/+rUgnm/vV721qq84Inj9jUkpFmuHNFnJMBXTOqqsmYPVTRtjlHFDscKSc41ws+7k0
         iK/w==
X-Gm-Message-State: AOJu0Yx+JpKoj3bdKn/+YbyNqc9N5HkQhtjCco83AuMBFeiXvq4Tq7lh
	RVpMap8bp6kawbLfJ1D8OkW8SCCYFu4nmR8J/J23TLB/M9IHiutQri6Rk0/iarTWzuYMhKxR4hY
	=
X-Gm-Gg: ASbGnctVAmmj5m+osKKRC8r+/xMSbhUuiV5w5kcAd7KTmOXZEyrASDJ3W6y0GjGf3qs
	syvTcAiK2/D7owmFLBt9XsKTF60zzKIhGKS9cP1O/YcQhSzVM5AkldRhvSDaq6XSw6YRUPO7UIH
	sReldD3DjcALFzy4Cbn9cd36pSwV7Mc0bWZgEhER8RNWGCrBADbvDRJc3mLYnw5sewMYJUoeEaX
	cyZk9s6ttxW4DZEqITlAN/RUUv+MONB0P0xe8CZm0AavXMcMa6hb/Ub1bCqq3T3giTdPQ5OvbDX
	yT2mpI46ZAcojsV8Vr/9DYhC1DI771nBWuLbJ+E=
X-Google-Smtp-Source: AGHT+IEro+kMo0mF+/+xCqXl0B2cpDKIo4tuw+YhiyKniL4zHBG5DCm6pWtj55giIqFS3fR3cndu5Q==
X-Received: by 2002:a5d:6dab:0:b0:385:f909:eb28 with SMTP id ffacd0b85a97d-3864ce985a5mr1647222f8f.45.1733911970348;
        Wed, 11 Dec 2024 02:12:50 -0800 (PST)
Message-ID: <35109b64-87bb-435a-b3e9-2c5b378532e9@suse.com>
Date: Wed, 11 Dec 2024 11:12:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v3 04/16] x86emul/test: drop cpu_has_avx512vl
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@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: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

AVX512VL not being a standalone feature anyway, but always needing
to be combined with some other AVX512*, replace uses of
cpu_has_avx512vl by just the feature bit check.

Signed-off-by: Jan Beulich 
---
v2: Re-base over dropping of Xeon Phi support.

--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -998,7 +998,8 @@ static void test_group(const struct test
     {
         for ( j = 0; j < nr_vl; ++j )
         {
-            if ( vl[0] == VL_512 && vl[j] != VL_512 && !cpu_has_avx512vl )
+            if ( vl[0] == VL_512 && vl[j] != VL_512 &&
+                 !cpu_policy.feat.avx512vl )
                 continue;
 
             switch ( tests[i].esz )
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -131,7 +131,7 @@ static bool simd_check_avx512f(void)
 
 static bool simd_check_avx512f_vl(void)
 {
-    return cpu_has_avx512f && cpu_has_avx512vl;
+    return cpu_has_avx512f && cpu_policy.feat.avx512vl;
 }
 #define simd_check_avx512vl_sg simd_check_avx512f_vl
 
@@ -143,7 +143,7 @@ static bool simd_check_avx512dq(void)
 
 static bool simd_check_avx512dq_vl(void)
 {
-    return cpu_has_avx512dq && cpu_has_avx512vl;
+    return cpu_has_avx512dq && cpu_policy.feat.avx512vl;
 }
 
 static bool simd_check_avx512bw(void)
@@ -154,7 +154,7 @@ static bool simd_check_avx512bw(void)
 
 static bool simd_check_avx512bw_vl(void)
 {
-    return cpu_has_avx512bw && cpu_has_avx512vl;
+    return cpu_has_avx512bw && cpu_policy.feat.avx512vl;
 }
 
 static bool simd_check_avx512vbmi(void)
@@ -164,7 +164,7 @@ static bool simd_check_avx512vbmi(void)
 
 static bool simd_check_avx512vbmi_vl(void)
 {
-    return cpu_has_avx512_vbmi && cpu_has_avx512vl;
+    return cpu_has_avx512_vbmi && cpu_policy.feat.avx512vl;
 }
 
 static bool simd_check_avx512vbmi2(void)
@@ -260,7 +260,7 @@ static bool simd_check_avx512fp16(void)
 
 static bool simd_check_avx512fp16_vl(void)
 {
-    return cpu_has_avx512_fp16 && cpu_has_avx512vl;
+    return cpu_has_avx512_fp16 && cpu_policy.feat.avx512vl;
 }
 
 static void simd_set_regs(struct cpu_user_regs *regs)
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -173,8 +173,6 @@ void wrpkru(unsigned int val);
 #define cpu_has_sha                  cpu_policy.feat.sha
 #define cpu_has_avx512bw            (cpu_policy.feat.avx512bw && \
                                      xcr0_mask(0xe6))
-#define cpu_has_avx512vl            (cpu_policy.feat.avx512vl && \
-                                     xcr0_mask(0xe6))
 #define cpu_has_avx512_vbmi         (cpu_policy.feat.avx512_vbmi && \
                                      xcr0_mask(0xe6))
 #define cpu_has_avx512_vbmi2        (cpu_policy.feat.avx512_vbmi2 && \



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:21:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:21:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854376.1267606 (Exim 4.92)
	(envelope-from )
	id 1tLJqV-0002Es-2e; Wed, 11 Dec 2024 10:21:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854376.1267606; Wed, 11 Dec 2024 10:21:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLJqU-0002Eg-VS; Wed, 11 Dec 2024 10:21:30 +0000
Received: by outflank-mailman (input) for mailman id 854376;
 Wed, 11 Dec 2024 10:21: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 1tLJqU-0002Dh-3e
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:21:30 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id abdf14bb-b7a9-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 11:21:23 +0100 (CET)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-385e06af753so2882868f8f.2
 for ; Wed, 11 Dec 2024 02:21: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
 d2e1a72fcca58-728e8c46a84sm1880755b3a.130.2024.12.11.02.21.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:21: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: abdf14bb-b7a9-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733912487; x=1734517287; 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=nCKajekOUINBVbNX77/s6Kb1O6XuDQGofayJhNlpP6I=;
        b=JxYOjeyJVsuDril8zvJ3nsmKvGS30lgUCqRmLP4kFYNM8GWsFPZ7X3FDD9VqWTisTu
         tNzeXUDbX9jTLKsSknfCUwxRaM1AKzilYSOVTRQ/PY3fOlD0R1b83tRYXLFsHXnYC+Ru
         dj4jJepDLqZWlck8p+mXVufIksIGMjMpiuCHIbPgT4IPCp/jQI5VaX383iKCkiARvzlp
         /I2I8kqVz8xx4rbzBu1u4T5n8bpW93olY+M/LZ7TuNS87nl1wJPwYWIvNwLT7yhSPTiv
         5tZayctyJXT8VzK+561dKEPvzq+7O66id/zbxEyBF3WCRSMrI9QSp563uj4IFYqR+F8j
         uLWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733912487; x=1734517287;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=nCKajekOUINBVbNX77/s6Kb1O6XuDQGofayJhNlpP6I=;
        b=JFpQgFTGCxsgvEFpggjRDS8Hy/2S+xhhcLGYRx+ZWccTVxGRMw/C6VAtjSS7qMHUiA
         AUrbGCVtRwLMQzKZYXYBmE62oaDkKXtBwMwvmpKJKq2Vfnz3jy19LNxMIfU5NiLnPifL
         tfMzCcVfwENvEAj4WZ1vqQexvqxmQ5Hwv+TPe+xkTL7Z4YHJ4MEn1L9ZBpumRYUodDO3
         VlROCiX7F/kTscRBi5uLwanmm9zPXbLu0wbzsnPW8LVW9yxKhhDFjanT0g7hMTES+vSZ
         40TtjVcs9wYA5opqHCq2LopXpal1zuOKODiNg0foEbS8q3J+Jkn/gsOCOYZbSYzejD2F
         0IiA==
X-Gm-Message-State: AOJu0Yy2m5FcW9EnLgkCNMp82PszKUjr/pNKYufkFHql1cxqflJjMEUe
	cfSaj3bLB4wLLM3RuMOCca37exBi9Qwtf5TfzfqqXSV63gMm7Yn3dcZ3Uzc/kBNaRxb7FZXOJLo
	=
X-Gm-Gg: ASbGncuGOTbXeMlqkyKLfvKJcOjek2M5Nuc5/1xmEzwfhJlHNBy9saANwTF5EN3KtZ3
	+vlMWLgyr3kNBObTU9CsMj3K6R32utZ8lT5taaclO6Zf9jQQagvyUoem457CvFdmsNP2O3dfeo3
	awqe8kqdMTLhFLmkf59OUs3EwV9+m+Eytiwl4eFEPePfxotACn6gzhoPM5TFieKRvxPtznhtgye
	Bopu8ls4r/jR34Gl2MRe6QL7kzgj7ii8kXXeKAmX0sWXDFJUg1CaT13hq3SqHaKjI6qm79ygz2Q
	ycReD/CnaTRpfqZD4bOyTWbpYcAusldlFjcXnMs=
X-Google-Smtp-Source: AGHT+IHS2U2/7bxUzfRckX1RsUkJ6lGs3X+OPidIK3ypTK+HqRiConptVoA2lOKWVperV7Xm98ZOmA==
X-Received: by 2002:a5d:59a7:0:b0:382:4926:98fa with SMTP id ffacd0b85a97d-3864cec56f0mr1823654f8f.40.1733912487589;
        Wed, 11 Dec 2024 02:21:27 -0800 (PST)
Message-ID: <6252b702-d204-4e10-acb9-9e8b3e06e5b4@suse.com>
Date: Wed, 11 Dec 2024 11:21:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v3 15/16] x86emul: support SIMD MOVRS
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@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: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

As we ignore cachability aspects of insns, they're treated like simple
VMOVs.

Signed-off-by: Jan Beulich 
---
SDE: -???
---
v3: New.

--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -814,6 +814,13 @@ static const struct test avx10_2_128[] =
     INSN(movw, f3, map5, 7e, el, fp16, el),
 };
 
+static const struct test movrs_all[] = {
+    INSN(movrsb, f2, map5, 6f, vl,    b, vl),
+    INSN(movrsd, f3, map5, 6f, vl, d_nb, vl),
+    INSN(movrsq, f3, map5, 6f, vl, q_nb, vl),
+    INSN(movrsw, f2, map5, 6f, vl,    w, vl),
+};
+
 static const unsigned char vl_all[] = { VL_512, VL_128, VL_256 };
 static const unsigned char vl_128[] = { VL_128 };
 static const unsigned char vl_no128[] = { VL_512, VL_256 };
@@ -1236,6 +1243,10 @@ void evex_disp8_test(void *instr, struct
 
     run(cpu_has_avx10_2, avx10_2, all);
     run(cpu_has_avx10_2, avx10_2, 128);
+    if ( cpu_has_avx10_2 )
+    {
+        run(ctxt->addr_size == 64 && cpu_has_movrs, movrs, all);
+    }
 
 #undef run
 }
--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -2195,6 +2195,8 @@ static const struct evex {
     { { 0x6d }, 2, T, R, pfx_f2, Wn, LIG }, /* vcvttsd2sis */
     { { 0x6e }, 2, T, R, pfx_66, WIG, L0 }, /* vmovw */
     { { 0x6e }, 2, T, R, pfx_f3, W0, L0 }, /* vmovw */
+    { { 0x6f }, 2, T, R, pfx_f3, Wn, Ln }, /* vmovrs{d,q} */
+    { { 0x6f }, 2, T, R, pfx_f2, Wn, Ln }, /* vmovrs{b,w} */
     { { 0x74 }, 2, T, R, pfx_no, W0, Ln }, /* vcvtbiasph2bf8s */
     { { 0x74 }, 2, T, R, pfx_f3, W0, Ln }, /* vcvtneph2bf8s */
     { { 0x74 }, 2, T, R, pfx_f2, W0, Ln }, /* vcvtne2ph2bf8s */
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -201,6 +201,7 @@ void wrpkru(unsigned int val);
                                      xcr0_mask(0xe6))
 #define cpu_has_cmpccxadd            cpu_policy.feat.cmpccxadd
 #define cpu_has_avx_ifma            (cpu_policy.feat.avx_ifma && xcr0_mask(6))
+#define cpu_has_movrs                cpu_policy.feat.movrs
 #define cpu_has_avx_vnni_int8       (cpu_policy.feat.avx_vnni_int8 && \
                                      xcr0_mask(6))
 #define cpu_has_avx_ne_convert      (cpu_policy.feat.avx_ne_convert && \
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -6298,6 +6298,17 @@ x86_emulate(
         op_bytes = 16 << evex.lr;
         goto avx512f_no_sae;
 
+    case X86EMUL_OPC_EVEX_F2(0x0f38, 0x6f): /* vmovrs{b,w} mem,[xyz]mm{k} */
+        elem_bytes = 1 << evex.w;
+        /* fall through */
+    case X86EMUL_OPC_EVEX_F3(0x0f38, 0x6f): /* vmovrs{d,q} mem,[xyz]mm{k} */
+        generate_exception_if(ea.type != OP_MEM || evex.brs, X86_EXC_UD);
+        vcpu_must_have(avx10, 2);
+        vcpu_must_have(movrs);
+        avx512_vlen_check(false);
+        op_bytes = 16 << evex.lr;
+        goto simd_zmm;
+
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x70): /* vpshldvw [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(0x0f38, 0x72): /* vpshrdvw [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
         generate_exception_if(!evex.w, X86_EXC_UD);



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:22:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:22:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854395.1267615 (Exim 4.92)
	(envelope-from )
	id 1tLJrE-0003EL-9h; Wed, 11 Dec 2024 10:22:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854395.1267615; Wed, 11 Dec 2024 10:22: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 1tLJrE-0003EE-72; Wed, 11 Dec 2024 10:22:16 +0000
Received: by outflank-mailman (input) for mailman id 854395;
 Wed, 11 Dec 2024 10:22: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 1tLJoN-00076S-JK
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:19:19 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20630.outbound.protection.outlook.com
 [2a01:111:f403:2405::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5d9cbd3d-b7a9-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 11:19:13 +0100 (CET)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by BL1PR12MB5972.namprd12.prod.outlook.com (2603:10b6:208:39b::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Wed, 11 Dec
 2024 10:19:13 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%3]) with mapi id 15.20.8230.010; Wed, 11 Dec 2024
 10:19: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: 5d9cbd3d-b7a9-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=q9ARRE1n+10RkBCpvHLylg82sJOWHG3OmwcIQ14pxiw6/2syn+ISaoqLfkVsy6+eOfnkZ7h7VZ2jDSmTnroqV6n/gbJffZ6jTjrsSaCpJjdVRY2hMqvSiAmBLyuzaLGQ4GaCabdgNeChDXC+wGMmN0hSKbkeqR+vNT6L48Sv5xt+6e4/vkRzR2iiVyAyvZA+Y7PR5TBH7s4e7X0vqRv8WhCqMRX0+iGenLXDm+AsDBHh6nbbV6D1RmowiqmESZuCLa9vCL94WYmodbks/q/pCOVDBMZhEakSVicCFWfEZPl0G2WN1W9r9y08d69naEPUTSN47q5/6Np8bcukZ6GC6A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=rePncN1oKWiZgGBMICaWrgUjE3bUSDg2tNc8amZb7zM=;
 b=iYOXeNkHwPSKXtIhVGwc5kGbtbURRhbS13vCh2ISxfmKDInB9ic8hEju1xv4ZHpdoQBKK+CtrVkNMlNUt780mA1qZyNCabj+tOepIBjbVhmktp5ncKiVaaYaCIv2+Atf+J5XIA9mOcmJIeHDb8O3yfhmZsSrPcSsJLb19l3s+XyWIFkntrQzk0XZ8APFO1bMP6HwqDvhIKfpjmmzLAYB8teeQt2Ceo4B+RJC6t+Cwwd2VFguWnVbD6GWkJ/lgdjrBv5y8kIfQvbs0rZhIo/CI11gHX/OKBbt2UJPZw5kN/dim1KwD3EeaB/xVR3Gm26TOZIBgcgCxCb8egB1ZkEKOQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=rePncN1oKWiZgGBMICaWrgUjE3bUSDg2tNc8amZb7zM=;
 b=UcYJ+g5mX+iJv+7KokDYeW5plwAfvYmuqK5xnCKfRlvLXpAW85ES9CVO7NtH+me5d+MUfMmAcbefroXYxuCgP5hWkVy596pJRwDfp17mwXlW2Y8WS6rp+R26a50Bgfyt5spe9kp3D12ki1BgBFlZw5lwXm9wQP1xvlAb1SDQ3A4=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: "Chen, Jiqian" , Andrew Cooper
	, Julien Grall , Stefano
 Stabellini , "Huang, Ray" ,
	"xen-devel@lists.xenproject.org" ,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support
Thread-Topic: [PATCH v2 1/1] vpci: Add resizable bar support
Thread-Index:
 AQHbRIDgGHZ3ofHO0UuqqXvn+EZCabLd/CGAgAGXh4D//4qBgIAAiieA//+hwICAABlHgIAB3TaA//+C2gAAAJ7NgAAAXBeAABKP+4A=
Date: Wed, 11 Dec 2024 10:19:13 +0000
Message-ID:
 
References: <20241202060956.1124162-1-Jiqian.Chen@amd.com>
 <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com>
 
 <1e0576d9-400e-4483-8dd1-061e215a00cd@suse.com>
 
 
 
 
 <328c3bb6-1adf-4c64-81d4-40704ea1f19e@suse.com>
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8230.010)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|BL1PR12MB5972:EE_
x-ms-office365-filtering-correlation-id: 51f41514-c393-4e3f-448b-08dd19cd42f6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?TXNPQVZndnJmcTZmM2twdi91YkgzVGNRTk02ZFpwcWZEYjcxdElNcEZzbXF3?=
 =?utf-8?B?bUZUNTFGNEptOE1abzVNNkVDc1BiQy9VSEdGVGg2b1B4cmRrOW1IQmhjanlq?=
 =?utf-8?B?U1FhZEVHaS8xNytGaWpQcmRPU2FFdFdrYStpK3Q0TG5HNUxJdVkwaFVyUkhm?=
 =?utf-8?B?WERqVFI0aTBBWHY0VUt5cVRGNlRUOExnQ0orQ1I2RmoxM3NZajBjVzVRZkd4?=
 =?utf-8?B?YjJDQndvb1d0ekt0ejlmNG5Uck8yV3VDOFdxTFVPcU9CSE5JZnRtZXdoWHJJ?=
 =?utf-8?B?MVg0d3NRRlBhQWljcWczUkxIY2l0eTUycW83QjJVcktSaFQvSDM1VGc4VlY3?=
 =?utf-8?B?MnIyc0sxNmVNcHFiQ28zQ21rNU52QlU2TGNZU3BLTmM5WkJmZGlqMzhJWjkv?=
 =?utf-8?B?QVRUZmNDbzU4MVROTldLY3hFdDFRT3ZLQVlHOGJHQzZiRWFVekZQZGdZRjVM?=
 =?utf-8?B?N3NmaGNjRDBwM1k2b2xmRFBtcW1hVkI3Njlvb0x5bytIWmFrZGQ0amhiYlNX?=
 =?utf-8?B?MGFXVFhBSG1DZUZJWmt6ZVN4ajRHNVg0SW10Y3dKRVpHMHZwbFJDMVA0eHRN?=
 =?utf-8?B?VW9PVS9FUDhnQjJoSmxET1RZK0FoNkpUQUdMNXhpTjZGWUtGd1B5SExlS1lK?=
 =?utf-8?B?SXRUb3dYM0hUNldYZ1cyWElPc1d6MkFidFJkYy8vY3kvOGNIZ1dndHhycGtq?=
 =?utf-8?B?M0JKNVJ4SW1kWEcxWVM3SkJHZnpEa2czRkVTa0JkVkhNdmFOSWtBajNBYW5j?=
 =?utf-8?B?M1EvVUpEUWVBWDlwNWM2NXhrNlNueUNFdXR1dVkwMklmOC9BTGhyRElMMThC?=
 =?utf-8?B?dTRCeVhJMm1uNUJSc1ZuWkdXV3ViTm5ya2VOd0hZd0w5WXZRMUR6YnNHVEhN?=
 =?utf-8?B?OTlYZ1lob2J0bGdudnV3NmpFOXVRY3RDSmViak5sY1BHbTdQb2FyVjJYaFE3?=
 =?utf-8?B?c1JDa1VNVVYyUThTZDV5U3o5VlM2K0tCSW5hMHovb0Vwd2pxMEJtL1hoUk9F?=
 =?utf-8?B?bklQWXovS1c4cGdRbkJLKzJmaHNxU1hielo0K1VrM0lZQXp1QjBkYStkREdn?=
 =?utf-8?B?NFU0bkk3YUhuU1RyRTh6WDZHeDh5T1NFZktWNHRUTUdKd1hmZzB5YytMT25W?=
 =?utf-8?B?QWZpa1pkZFBSb0VpKzRRd0JSRDEwSTBQY3U2YzNmRkZaejVpR0luV01maXB0?=
 =?utf-8?B?Tnp1RlFTTFl3MlNKR3BVeUVXTmZaWWlIRis2cTJiVk1JaTFrU2NqMnJYdVJR?=
 =?utf-8?B?V0NoRWtkT2dlRDFhY0wrUWdKVE8zbkVvTzg1YzcvN1pBMjc4empBeStrNUpl?=
 =?utf-8?B?UmVyRUw4YlE3R2lsdXUydzR0WlFNOEZmMDdXNEMrTU9nNWx6NnRtUkFrem9w?=
 =?utf-8?B?N2dQNUJpVWpYNDFTdWhUandid3FBTGJadjhKRHM5MmxCNXJPMjgvdmZGcmhi?=
 =?utf-8?B?UDhhNTB0b1pBTC9ZSnFoeXdLOTN6OGVqTFpRcTg3Vy81K2VmclZjQWN2WVRl?=
 =?utf-8?B?a0Y0MWtibVMrUVNLOG1nemU2Y3hXbXRQNTlkZ3NFeWZGOXpSVFhpeWo4Nmh3?=
 =?utf-8?B?ZFhkeW12Q3Q2U3dsZGFxSTVmUXN2SC9tQkVKdGxzWEVrc2QrSFpheVdGSkFp?=
 =?utf-8?B?eDZNcDh5SnVETzMremZCSFM1NUhWT3crVUZjMjc3RW1xbDVKQkEwYjJPMFNj?=
 =?utf-8?B?Wml6ekQyNWJDY2JJMlVVUjlJRHVSa05WREpBdnhMeU5RQUQxQnA5dWJpWmQ5?=
 =?utf-8?B?Y2RVWldNdkJjWjZoSWE1TUtXd1J3RG94UnA5aFJNWkhzdThWWVBRRUtmNld4?=
 =?utf-8?B?bCtFb05ndGUzUmIwSVE1aUVHZ1J0RytRQVRvMCszTzNpMWwrMVE2YlJmTzM5?=
 =?utf-8?B?Vi92ZFdUSGRYd2lrbWZUTU9RNmFuSFpBWmExRlFtWWlZbEE9PQ==?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?WlFLWERJMCsrL0RwYXZOWWFQN1liWXc3L1p3WjNLUnlZTkxIQmdoSE42ZGQ3?=
 =?utf-8?B?UVhRbU9icmpHVG1KZTZvamFWZ1JmK0Uvem1jUWoremxydktQTHprbDY4MFFP?=
 =?utf-8?B?TGNNZ0lsS2xXVkpTYkZIcnQyRmtRK3VESTNXWEhOWFk5dnFTaURPRGdCNERY?=
 =?utf-8?B?WCsvTjRiM0N4YWh1ektMTUhhS2ZueDR4N0xIeHJvNHJ0S2Z0ZG1EbXNVbFFQ?=
 =?utf-8?B?QVp6Sm9oWU9DM0h4TEZwVzVDWFFQUlEvc2t3VVplZHlCaWQvN01uaktzMjA5?=
 =?utf-8?B?OEc1bXhUcmhCSWRsd3hpT0RhSWt5ODF2MjZSRFlVaDlueFV3RVV5MkliMTdj?=
 =?utf-8?B?VFIvY2U4aWRjTmFDY3lTblRZOXRBWjFXK29BYlFEbFFwSUw1NDVxWVVxQ1pW?=
 =?utf-8?B?V0thWE15MTJLV09yN3pXT25SMkVuaitJTzhzTFN0VUN3RmxOSVhtaWdaLzEz?=
 =?utf-8?B?dElMK0Zac3U5bVRmdnJtS01uazcrRFQxSEdSZkMzcHVIYXBDeWxVWWI3Z1Ja?=
 =?utf-8?B?MWd6c29qREgrOWRaaEQrNW5CaVBldXNGb0x0dllTMjl2TmN5d2xnMHM3L3Q5?=
 =?utf-8?B?QVZQRWNqYzEvVUVvejJSSmZiLzliRUIwcFA2bVBvS2dvSkxPYTV1QTlvcjI3?=
 =?utf-8?B?UzR3T1RhaXduQU1uV0QyWVowUDFKMHFlUTlmM2h4Y1FkWkFyNkpwTHRqdG9F?=
 =?utf-8?B?SnhUYkZmdWZUMVhhVzNkK3NtOTIwY0MyZU9ZdEpGVm9OaWNxQ3RFd1VnNmdy?=
 =?utf-8?B?cGpOajVZak5OSlhKbVZHaWxoUERUajB0M1BieVlKZEJiam5yZFczejFFUEo3?=
 =?utf-8?B?RkhwaC9BcmhTSUwrL2s4L2RqZEFrdXFrVmRqaDYwRFRtbTJNdUJoNGNvemx6?=
 =?utf-8?B?bnFaTUtLNkpjTzhiWm51VzZYZE1ORU1yS013SnQ4U0Q3QzlHRlRsS0ZPanA3?=
 =?utf-8?B?U3doNlk0WWx4YWFaLzFXY2J3TnlVeVp6M0Zrdkd3Zk91NEZsWmcxR0NCOUZy?=
 =?utf-8?B?bWVtRmlEQnhVMFBUMHJYdWJGM1gyQzFSNjE2SkUyY2hzdm1DNURLZHUyaGh0?=
 =?utf-8?B?QmZPQmpkMjRlUXh5TlRncHJFWngxUldYYnd3TDRKVlkxWGc4allqTEI4ZGpq?=
 =?utf-8?B?YUN1MEVnOEFMTTdzdUVxSGhBOTdqZVFDZm1IOE1VR1ZualN2aFRpN3ZmVzB3?=
 =?utf-8?B?VE41VUVvUi9WeG94endJbFBPUXNBbnZmZjZmaExnQ3hhUDAzeVp4bExDandL?=
 =?utf-8?B?eXluUVA4bzZqT1U4VjJMbHd1Nno4WUtHRFg0R2dqY2xSdjNGcXhRVm4zS0pp?=
 =?utf-8?B?ZHRjdUl3cUJzWEZDelk1eE44dmc5c2xEZ3Z6Z2ZTWFFQUTFudGZEdWtMRkUx?=
 =?utf-8?B?UjErc2pFczBON3c3ZURqNCtDRmlrR25YbUZpUEpKM0pNdkhWVjhoRldZV1JY?=
 =?utf-8?B?Z2tvM2dSS1BWV3FTcVBsVldzNDJWVTlPZktKUW5ubmJ4S3JCcS9ia1d0UDc4?=
 =?utf-8?B?eHB0cmY2Qk02NWhzNWpMK3l1WHloTE5NMW05UytYaU4zdEY4eGx1bDhJZ3Zw?=
 =?utf-8?B?RElueWtuUk5pR3N6U215T0xqWkhVRmpQNzRwSlMzZFVjQ0dYMXZwd2hMTXUv?=
 =?utf-8?B?KzlPT0lXeEtKaUZvMExWU2tNcGloK1VPa0U3RVFzNy9ZY09hZ2Zld2JzWDNX?=
 =?utf-8?B?Wkw0WXNXd0EveUY0RkQ1QzZFTitveDVwWnBUNW51R2ZlNEVjeUYydUJUN3gy?=
 =?utf-8?B?L1huczQ5WFh6MnlubWJONTZMTkllay9adDFuQkZZY0dFM2VOZE1sTUc2b2d5?=
 =?utf-8?B?M0wvYW54Unh3b1EvYUJ0RkVPR0UvSTNycCszVGlNZlNEbkVxQ0xVaU83MGM4?=
 =?utf-8?B?SjhoZFlyeXQ2Ry96YVJiajJpWXpyT2hXT21jVVlNNVU2NW9jUWxNZ0ZpdGJn?=
 =?utf-8?B?aFd4SmpUQ25lMzUzWUFqdVNyOUhXRmE0NW9lUDRybllYVngvNmI4RUJ3am95?=
 =?utf-8?B?akJOQ2VDTDdGZUppQ2hhNkQxaTZ3dlgrT1VLN3U5ZnRTWERWZGdNZ0JPNlpk?=
 =?utf-8?B?aHRDUUF1bU5GY3ZmTG5DTVM5OWpaeTFEaFVpbGp0MHlVOVNaQ3JodWRGYlBM?=
 =?utf-8?Q?9+IY=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 51f41514-c393-4e3f-448b-08dd19cd42f6
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2024 10:19:13.8624
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: YlcYqsU9DfEDY9ZvxnjNC0MWl7lu90RM3h3DNZoffbTzsKV5aGATg+Ts9FQkZHrCV6j2OcSb96CkyAoP3lGQgg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5972

T24gMjAyNC8xMi8xMSAxNjo1MywgSmFuIEJldWxpY2ggd3JvdGU6DQo+IE9uIDExLjEyLjIwMjQg
MDk6NDMsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+PiBPbiBXZWQsIERlYyAxMSwgMjAyNCBh
dCAwOToyNToxNkFNICswMTAwLCBKYW4gQmV1bGljaCB3cm90ZToNCj4+PiBPbiAxMS4xMi4yMDI0
IDA4OjU3LCBDaGVuLCBKaXFpYW4gd3JvdGU6DQo+Pj4+IE9uIDIwMjQvMTIvMTAgMTk6MjUsIFJv
Z2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+Pj4+PiBTbyB5b3Ugc3VnZ2VzdCB0aGF0IHRoZSBjYXBh
YmlsaXR5IHNob3VsZCBiZSBoaWRkZW4gaW4gdGhhdCBjYXNlPyAgV2UNCj4+Pj4+IGhhdmUgbG9n
aWMgdG8gaGlkZSBjYXBhYmlsaXRpZXMsIGp1c3Qgbm90IHVzZWQgZm9yIHRoZSBoYXJkd2FyZQ0K
Pj4+Pj4gZG9tYWluLiAgSXQgd291bGQgbmVlZCBzb21lIGV4dHJhIHdpcmluZyB0byBiZSBjYXBh
YmxlIG9mIGhpZGluZw0KPj4+Pj4gZmFpbGVkIGNhcGFiaWxpdGllcy4NCj4+Pj4gQ2FuIHlvdSBn
aXZlIG1lIGEgZ3VpZGFuY2Ugb24gaG93IHRvIGhpZGUgYSBmYWlsZWQgY2FwYWJpbGl0eT8NCj4+
Pj4gV2hhdCBjb2RlcyBhcmUgY3VycmVudCBsb2dpYyB0byBoaWRlIGNhcGFiaWxpdGllcz8NCj4+
Pj4gVGhlbiBtYXliZSBJIGNhbiBhZGQgYSBwYXRjaCB0byBpbXBsZW1lbnQgaXQuDQo+Pj4NCj4+
PiBJdCdzIHJlYWxseSB0aGUgb3RoZXIgd2F5IGFyb3VuZCByaWdodCBub3cgZm9yICJub3JtYWwi
IGNhcGFiaWxpdGllczoNCj4+PiBXZSB3aGl0ZWxpc3Qgd2hhdCB3ZSBleHBvc2UuIFNlZSBpbml0
X2hlYWRlcigpJ3MgbG9naWMgYWZ0ZXIgY2hlY2tpbmcNCj4+PiB0aGUgUENJX1NUQVRVU19DQVBf
TElTVCBiaXQuIEFjdHVhbGx5IHBhc3QgdGhhdCBibG9jayB0aGVyZSdzDQo+Pj4NCj4+PiAgICAg
ICAgIC8qIEV4dGVuZGVkIGNhcGFiaWxpdGllcyByZWFkIGFzIHplcm8sIHdyaXRlIGlnbm9yZSAq
Lw0KPj4+ICAgICAgICAgcmMgPSB2cGNpX2FkZF9yZWdpc3RlcihwZGV2LT52cGNpLCB2cGNpX3Jl
YWRfdmFsLCBOVUxMLCAweDEwMCwgNCwNCj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgKHZvaWQgKikwKTsNCj4+Pg0KPj4+IEkuZS4gbm8gZXh0ZW5kZWQgY2FwYWJpbGl0aWVzIGFy
ZSBleHBvc2VkIGF0IGFsbCByaWdodCBub3cgdG8gRG9tVS1zLg0KPj4+IEZvciBEb20wIEkgZ3Vl
c3Mgd2Ugc2hvdWxkbid0IHVzZSB3aGl0ZWxpc3RpbmcsIGJ1dCB0aGUgKGV4dGVuZGVkKQ0KPj4+
IGNhcGFiaWxpdHkgbGlzdChzKSB3b3VsZCBuZWVkIHNpbWlsYXJseSB2aXJ0dWFsaXppbmcgdG8g
YmUgYWJsZSB0bw0KPj4+IGhpZGUgc29tZS4NCj4+DQo+PiBHaXZlbiB0aGlzIGNhcGFiaWxpdHkg
aXMgb25seSB0byBiZSBleHBvc2VkIHRvIHRoZSBodyBkb21haW4gKGF0IGxlYXN0DQo+PiBmb3Ig
bm93KSwgSSdtIG5vdCBzdXJlIGl0J3MgZmFpciB0byBhc2sgdG8gYWRkIGFsbCB0aGlzDQo+PiBp
bmZyYXN0cnVjdHVyZSBhcyBwYXJ0IG9mIGFkZGluZyB0aGUgbmV3IGNhcGFiaWxpdHkuICBJdCB3
b3VsZCBiZSBncmVhdA0KPj4gdG8gaGF2ZSBpdCwgYnV0IGRvZXNuJ3Qgc2VlbSBmYWlyIHdoZW4g
dGhlcmUncyBhbHJlYWR5IE1TSSBhbmQgTVNJLVgNCj4+IGltcGxlbWVudGVkIHdpdGhvdXQgc3Vj
aCBzdXBwb3J0Lg0KPiANCj4gV2VsbCwgb2YgY291cnNlIHRoaXMgY2FuIGFsc28gYmUgbW9kZWxl
ZCBhZnRlciBNU0kvTVNJLVgsIGZhaWxpbmcNCj4gYXNzaWdubWVudCB3aGVuIGluaXRpYWxpemF0
aW9uIGZvciBhIGNhcGFiaWxpdHkgZmFpbHMuIFlldCB3aGlsZSBmb3INCj4gTVNJIC8gTVNJLVgg
dGhpcyBmZWVscyBva2F5LWlzaCAoY29uc2lkZXJpbmcgdGhhdCBtYW55IGRldmljZXMgbm93DQo+
IGNhbid0IGV2ZW4gb3BlcmF0ZSB2ZXJ5IHdlbGwgd2l0aG91dCBlaXRoZXIgb2YgdGhlIHR3byks
IEknZCBleHBlY3QNCj4gQkFSIHJlc2l6aW5nIHRvIG5vdCBiZSBzb21ldGhpbmcgdGhhdCBkcml2
ZXJzICh0eXBpY2FsbHkpIHJlbHkgb24uDQo+ICJUeXBpY2FsbHkiIGJlY2F1c2UgaWlyYyBKaXFp
YW4gc2FpZCB0aGUgQU1EIGRpc3BsYXkgZHJpdmVyIGFjdHVhbGx5DQo+IGRvZXMuDQpZb3UgbWVh
biB3aGF0IEkgc2FpZCBpbiBsYXN0IHZlcnNpb24/IEl0IGlzICJhbWRncHUgZHJpdmVyIHNhdmVz
IGFuZCByZXN0b3JlcyB0aGUgc2FtZSBwY2kgc3RhdGUgZHVyaW5nIGluaXRpYXphdGlvbiB3aXRo
b3V0IGRpc2FibGluZyBtZW1vcnkgZGVjb2RpbmcsIHRoYXQgY2F1c2VkIFJvZ2VyJ3MgbWV0aG9k
IG5vdCB3b3JrIi4NCkFuZCBjdXJyZW50bHkgcnVubmluZyBhbWRncHUgb24gWGVuIGh5cGVydmlz
b3IgaGFzIHR3byBzY2VuYXJpb3MsIA0KMS4gQVBVIGRvZXMgbm90IHJlbHkgb24gUmVCYXIgY2Fw
YWJpbGl0eSwgYmVjYXVzZSBBUFUncyB2cmFtIGFyZSBhbGwgQ1BVIGFjY2Vzc2libGUuDQoyLiBC
dXQgZm9yIGRpc2NyZXRlIEdQVSwgdGhleSBjYW4ndCB3b3JrIGJhc2VkIG9uIGN1cnJlbnQgWGVu
IGNvZGVzLCBpdCBuZWVkcyByZXNpemUgQmFyIHRvIG1ha2UgYWxsIHZyYW0gQ1BVIGFjY2Vzc2li
bGUuIFRoYXQgaXMgd2h5IEkgc2VudCB0aGlzIHBhdGNoIHRvIGFkZCBSZWJhciBzdXBwb3J0IGlu
IFhlbi4NCg0KPiANCj4gSmFuDQoNCi0tIA0KQmVzdCByZWdhcmRzLA0KSmlxaWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:22:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:22:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854396.1267626 (Exim 4.92)
	(envelope-from )
	id 1tLJrT-0003g1-Io; Wed, 11 Dec 2024 10:22:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854396.1267626; Wed, 11 Dec 2024 10:22: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 1tLJrT-0003ft-ER; Wed, 11 Dec 2024 10:22:31 +0000
Received: by outflank-mailman (input) for mailman id 854396;
 Wed, 11 Dec 2024 10:22: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 1tLJic-0003z3-2s
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:13:22 +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 88e60d75-b7a8-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 11:13:15 +0100 (CET)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-37ed3bd6114so2778937f8f.2
 for ; Wed, 11 Dec 2024 02:13:20 -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
 d9443c01a7336-2162b052ee8sm71237215ad.45.2024.12.11.02.13.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:13:18 -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: 88e60d75-b7a8-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733911999; x=1734516799; 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=/gKnwhepsCOgjaSpf1xV3UdHomhomuoQ6+ggqo6U/2M=;
        b=PUvpnQuxMxUJkmf5ImqLv1OJc4BfI+odugiKr64+g4ii0ACE6WVAUtK50jRX8YFMN7
         fjN56MLjNyNi5m80uaXlgooL+xL1veIMnRokN4AIL46gO1BAYaxpqFrMFbNQPTNCbQfJ
         5xHRV6VXXf6tmoys7z02eogcyk+nivBrrgoqiw3nVotO1WLvxnHOJ0K82Ic4qGbd3Fti
         UbuUwE/oNhGqTn2NdylBwx6lCVNovlLFl4v9iAHNwOrAIZS1thHBasDS8DAMx0EBTNwz
         1a0mS2G9RV8s3E8ZnX72/5to8zrQPbAaAk+VL4iD6vv0pRwNzqxuWkBivn4dWcKP6VvU
         MAVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733911999; x=1734516799;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=/gKnwhepsCOgjaSpf1xV3UdHomhomuoQ6+ggqo6U/2M=;
        b=BH6UIuQKrPEwsuSrythON8hnjPkE4tQ/LXp005jhVteqXl14J55f3KGFTyuYmUNPqW
         /dvq3t6VHwh4VSI8hzeTnqF68IVrvSNHxvPY8xkCAI3+HbYH/GDfA4anLU8nGTr0WfsI
         suEBvqYQgS+JsRZWgNHY/nkAh1H3ARCMiAFGDA5lzb7Orf2RDdoYRXNb+E4URF8hyw3g
         Yrs4Z3byzdFZh/RVkx+eXBTkMLBrvmEDG0Ccn22HuHEPjx8AwyHKu7FW76PVgKEJEHZ7
         chXM1a3l4QqJFwK35Pbx7cnJpMSy6k/eB8N34Ca+5z/l6QzTH5qqIohWkjAVidoPJXKO
         iCdw==
X-Gm-Message-State: AOJu0Yy4OkAb0FBKWIFHBsriHwUsrnzxPSQcOhFNPTy4DfNdgUA/3RlY
	L4n5iT9xFhPOb379JmwL7YrTIuIC1EFYwXvyAX+5KqfcdSlUuonDa/aQnCC4mkZmfmy5wuiqZcQ
	=
X-Gm-Gg: ASbGnctUir6stUT45q3E4tzDgvmbDRoSrGJtY3oy2ZKaKJ/RT5Mk8Dk5StfrPLz/CeM
	Fr81qVmLd4RMHTf9slKoPpnPHRNynI63SbrX/bHw12zxbd9EZbtfIebPImRidQltlqHVPWLU2Sk
	n/rY/+5DIZCnQSlxzdWE6S69dmdiKyH9M96EAfQ1byAt7DfB3d+vLCNPct68dixSxfGx4xve/yR
	8mxDa3XoDtfr8kpwm8nj4R3bfYDsV7zXkkB7/O58KC+GC49Pl4LxZRR3OH14NYcuD4FCe1aE9XT
	0W0NO1QmQCsx9NmP4scMpTLnDK2zSk8C46A3VHU=
X-Google-Smtp-Source: AGHT+IGsZsYbOWcOvFkSsDe/ZCxaKgvyW2utiM0OkHWW3WWFzTJAB9L4DI+w6D8MflzmGvzJcGklqg==
X-Received: by 2002:a5d:47c6:0:b0:385:f062:c2df with SMTP id ffacd0b85a97d-3864ce4968emr1994195f8f.11.1733911999302;
        Wed, 11 Dec 2024 02:13:19 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 11:13:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v3 05/16] x86emul: AVX10.1 testing
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@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: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Re-use respective AVX512 tests, by suitably adjusting the predicate
functions. This leaves test names ("Testing ... NN-bit code sequence")
somewhat misleading, but I think we can live with that.

Note that the AVX512{BW,DQ} opmask tests cannot be run as-is for the
AVX10/256 case, as they include 512-bit vector <-> opmask insn tests.

Signed-off-by: Jan Beulich 
---
SDE: -gnr / -gnr256
---
TBD: For AVX10.1/256 need to somehow guarantee that the generated blobs
     really don't use 512-bit insns (it's uncertain whether passing
     -mprefer-vector-width= is enough). Right now according to my
     testing on SDE this is all fine. May need to probe for support of
     the new -mno-evex512 compiler option.

The AVX512{BW,DQ} opmask tests could of course be cloned (i.e. rebuilt
another time with -mavx512vl passed) accordingly, but the coverage gain
wouldbe pretty marginal.
---
v2: Drop SDE 9.27.0 workaround. Re-base over dropping of Xeon Phi
    support.

--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -999,7 +999,11 @@ static void test_group(const struct test
         for ( j = 0; j < nr_vl; ++j )
         {
             if ( vl[0] == VL_512 && vl[j] != VL_512 &&
-                 !cpu_policy.feat.avx512vl )
+                 !cpu_policy.feat.avx512vl && !cpu_policy.feat.avx10 )
+                continue;
+
+            if ( vl[j] == VL_512 && !cpu_policy.feat.avx512f &&
+                 !cpu_policy.avx10.vsz512 )
                 continue;
 
             switch ( tests[i].esz )
@@ -1050,6 +1054,27 @@ static void test_group(const struct test
     }
 }
 
+/* AVX512 (sub)features implied by AVX10. */
+#define avx10_has_avx512f             true
+#define avx10_has_avx512bw            true
+#define avx10_has_avx512cd            true
+#define avx10_has_avx512dq            true
+#define avx10_has_avx512_bf16         true
+#define avx10_has_avx512_bitalg       true
+#define avx10_has_avx512_fp16         true
+#define avx10_has_avx512_ifma         true
+#define avx10_has_avx512_vbmi         true
+#define avx10_has_avx512_vbmi2        true
+#define avx10_has_avx512_vnni         true
+#define avx10_has_avx512_vpopcntdq    true
+
+/* AVX512 sub-features /not/ implied by AVX10. */
+#define avx10_has_avx512er            false
+#define avx10_has_avx512pf            false
+#define avx10_has_avx512_4fmaps       false
+#define avx10_has_avx512_4vnniw       false
+#define avx10_has_avx512_vp2intersect false
+
 void evex_disp8_test(void *instr, struct x86_emulate_ctxt *ctxt,
                      const struct x86_emulate_ops *ops)
 {
@@ -1057,8 +1082,8 @@ void evex_disp8_test(void *instr, struct
     emulops.read = read;
     emulops.write = write;
 
-#define RUN(feat, vl) do { \
-    if ( cpu_has_##feat ) \
+#define run(cond, feat, vl) do { \
+    if ( cond ) \
     { \
         printf("%-40s", "Testing " #feat "/" #vl " disp8 handling..."); \
         test_group(feat ## _ ## vl, ARRAY_SIZE(feat ## _ ## vl), \
@@ -1067,6 +1092,12 @@ void evex_disp8_test(void *instr, struct
     } \
 } while ( false )
 
+#define RUN(feat, vl) \
+    run(cpu_has_ ## feat || \
+        (cpu_has_avx10_1 && cpu_policy.avx10.vsz256 && avx10_has_ ## feat && \
+         (ARRAY_SIZE(vl_ ## vl) > 1 || &vl_ ## vl[0] != &vl_512[0])), \
+       feat, vl)
+
     RUN(avx512f, all);
     RUN(avx512f, 128);
     RUN(avx512f, no128);
@@ -1089,10 +1120,15 @@ void evex_disp8_test(void *instr, struct
     RUN(avx512_fp16, all);
     RUN(avx512_fp16, 128);
 
-    if ( cpu_has_avx512f )
+#undef RUN
+
+    if ( cpu_has_avx512f || cpu_has_avx10_1 )
     {
+#define RUN(feat, vl) run(cpu_has_ ## feat, feat, vl)
         RUN(gfni, all);
         RUN(vaes, all);
         RUN(vpclmulqdq, all);
+#undef RUN
     }
+#undef run
 }
--- a/tools/tests/x86_emulator/testcase.mk
+++ b/tools/tests/x86_emulator/testcase.mk
@@ -4,7 +4,27 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
 
-CFLAGS += -fno-builtin -g0 $($(TESTCASE)-cflags)
+ifneq ($(filter -mavx512%,$($(TESTCASE)-cflags)),)
+
+cflags-vsz64 :=
+cflags-vsz32 := -mprefer-vector-width=256
+cflags-vsz16 := -mprefer-vector-width=128
+# Scalar tests don't set VEC_SIZE (and VEC_MAX is used by S/G ones only)
+cflags-vsz   := -mprefer-vector-width=128
+
+ifneq ($(filter -DVEC_SIZE=%,$($(TESTCASE)-cflags)),)
+CFLAGS-VSZ := $(cflags-vsz$(patsubst -DVEC_SIZE=%,%,$(filter -DVEC_SIZE=%,$($(TESTCASE)-cflags))))
+else
+CFLAGS-VSZ := $(cflags-vsz$(patsubst -DVEC_MAX=%,%,$(filter -DVEC_MAX=%,$($(TESTCASE)-cflags))))
+endif
+
+else
+
+CFLAGS-VSZ :=
+
+endif
+
+CFLAGS += -fno-builtin -g0 $($(TESTCASE)-cflags) $(CFLAGS-VSZ)
 
 LDFLAGS_DIRECT += $(shell { $(LD) -v --warn-rwx-segments; } >/dev/null 2>&1 && echo --no-warn-rwx-segments)
 
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -124,52 +124,61 @@ static bool simd_check_avx_pclmul(void)
 
 static bool simd_check_avx512f(void)
 {
-    return cpu_has_avx512f;
+    return cpu_has_avx512f || cpu_has_avx10_1_512;
 }
-#define simd_check_avx512f_opmask simd_check_avx512f
 #define simd_check_avx512f_sg simd_check_avx512f
 
+static bool simd_check_avx512f_sc(void)
+{
+    return cpu_has_avx512f || cpu_has_avx10_1;
+}
+#define simd_check_avx512f_opmask simd_check_avx512f_sc
+
 static bool simd_check_avx512f_vl(void)
 {
-    return cpu_has_avx512f && cpu_policy.feat.avx512vl;
+    return (cpu_has_avx512f && cpu_policy.feat.avx512vl) ||
+           cpu_has_avx10_1_256;
 }
 #define simd_check_avx512vl_sg simd_check_avx512f_vl
 
 static bool simd_check_avx512dq(void)
 {
-    return cpu_has_avx512dq;
+    return cpu_has_avx512dq || cpu_has_avx10_1_512;
 }
 #define simd_check_avx512dq_opmask simd_check_avx512dq
 
 static bool simd_check_avx512dq_vl(void)
 {
-    return cpu_has_avx512dq && cpu_policy.feat.avx512vl;
+    return (cpu_has_avx512dq && cpu_policy.feat.avx512vl) ||
+           cpu_has_avx10_1_256;
 }
 
 static bool simd_check_avx512bw(void)
 {
-    return cpu_has_avx512bw;
+    return cpu_has_avx512bw || cpu_has_avx10_1_512;
 }
 #define simd_check_avx512bw_opmask simd_check_avx512bw
 
 static bool simd_check_avx512bw_vl(void)
 {
-    return cpu_has_avx512bw && cpu_policy.feat.avx512vl;
+    return (cpu_has_avx512bw && cpu_policy.feat.avx512vl) ||
+           cpu_has_avx10_1_256;
 }
 
 static bool simd_check_avx512vbmi(void)
 {
-    return cpu_has_avx512_vbmi;
+    return cpu_has_avx512_vbmi || cpu_has_avx10_1_512;
 }
 
 static bool simd_check_avx512vbmi_vl(void)
 {
-    return cpu_has_avx512_vbmi && cpu_policy.feat.avx512vl;
+    return (cpu_has_avx512_vbmi && cpu_policy.feat.avx512vl) ||
+           cpu_has_avx10_1_256;
 }
 
 static bool simd_check_avx512vbmi2(void)
 {
-    return cpu_has_avx512_vbmi2;
+    return cpu_has_avx512_vbmi2 || cpu_has_avx10_1_512;
 }
 
 static bool simd_check_sse4_sha(void)
@@ -250,17 +259,23 @@ static bool simd_check_avx512bw_gf_vl(vo
 
 static bool simd_check_avx512vnni(void)
 {
-    return cpu_has_avx512_vnni;
+    return cpu_has_avx512_vnni || cpu_has_avx10_1_512;
 }
 
 static bool simd_check_avx512fp16(void)
 {
-    return cpu_has_avx512_fp16;
+    return cpu_has_avx512_fp16 || cpu_has_avx10_1_512;
+}
+
+static bool simd_check_avx512fp16_sc(void)
+{
+    return cpu_has_avx512_fp16 || cpu_has_avx10_1;
 }
 
 static bool simd_check_avx512fp16_vl(void)
 {
-    return cpu_has_avx512_fp16 && cpu_policy.feat.avx512vl;
+    return (cpu_has_avx512_fp16 && cpu_policy.feat.avx512vl) ||
+           cpu_has_avx10_1_256;
 }
 
 static void simd_set_regs(struct cpu_user_regs *regs)
@@ -433,9 +448,13 @@ static const struct {
     SIMD(OPMASK+DQ/w, avx512dq_opmask,         2),
     SIMD(OPMASK+BW/d, avx512bw_opmask,         4),
     SIMD(OPMASK+BW/q, avx512bw_opmask,         8),
-    SIMD(AVX512F f32 scalar,  avx512f,        f4),
+#define avx512f_sc_x86_32_D_f4 avx512f_x86_32_D_f4
+#define avx512f_sc_x86_64_D_f4 avx512f_x86_64_D_f4
+    SIMD(AVX512F f32 scalar,  avx512f_sc,     f4),
     SIMD(AVX512F f32x16,      avx512f,      64f4),
-    SIMD(AVX512F f64 scalar,  avx512f,        f8),
+#define avx512f_sc_x86_32_D_f8 avx512f_x86_32_D_f8
+#define avx512f_sc_x86_64_D_f8 avx512f_x86_64_D_f8
+    SIMD(AVX512F f64 scalar,  avx512f_sc,     f8),
     SIMD(AVX512F f64x8,       avx512f,      64f8),
     SIMD(AVX512F s32x16,      avx512f,      64i4),
     SIMD(AVX512F u32x16,      avx512f,      64u4),
@@ -523,7 +542,9 @@ static const struct {
     AVX512VL(_VBMI+VL u16x8, avx512vbmi,    16u2),
     AVX512VL(_VBMI+VL s16x16, avx512vbmi,   32i2),
     AVX512VL(_VBMI+VL u16x16, avx512vbmi,   32u2),
-    SIMD(AVX512_FP16 f16 scal,avx512fp16,     f2),
+#define avx512fp16_sc_x86_32_D_f2 avx512fp16_x86_32_D_f2
+#define avx512fp16_sc_x86_64_D_f2 avx512fp16_x86_64_D_f2
+    SIMD(AVX512_FP16 f16 scal,avx512fp16_sc,  f2),
     SIMD(AVX512_FP16 f16x32, avx512fp16,    64f2),
     AVX512VL(_FP16+VL f16x8, avx512fp16,    16f2),
     AVX512VL(_FP16+VL f16x16,avx512fp16,    32f2),
@@ -3205,7 +3226,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing {evex} vmovq %xmm1,32(%edx)...");
-    if ( stack_exec && simd_check_avx512f() )
+    if ( stack_exec && simd_check_avx512f_sc() )
     {
         decl_insn(evex_vmovq_to_mem);
 
@@ -3229,7 +3250,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing {evex} vmovq 32(%edx),%xmm0...");
-    if ( stack_exec && simd_check_avx512f() )
+    if ( stack_exec && simd_check_avx512f_sc() )
     {
         decl_insn(evex_vmovq_from_mem);
 
@@ -3241,11 +3262,22 @@ int main(int argc, char **argv)
         rc = x86_emulate(&ctxt, &emulops);
         if ( rc != X86EMUL_OKAY || !check_eip(evex_vmovq_from_mem) )
             goto fail;
-        asm ( "vmovq %1, %%xmm1\n\t"
-              "vpcmpeqq %%zmm0, %%zmm1, %%k0\n"
-              "kmovw %%k0, %0" : "=r" (rc) : "m" (res[8]) );
-        if ( rc != 0xff )
-            goto fail;
+        if ( simd_check_avx512f() )
+        {
+            asm ( "vmovq %1, %%xmm1\n\t"
+                  "vpcmpeqq %%zmm0, %%zmm1, %%k0\n"
+                  "kmovw %%k0, %0" : "=r" (rc) : "m" (res[8]) );
+            if ( rc != 0x00ff )
+                goto fail;
+        }
+        else
+        {
+            asm ( "vmovq %1, %%xmm1\n\t"
+                  "vpcmpeqq %%xmm0, %%xmm1, %%k0\n"
+                  "kmovb %%k0, %0" : "=r" (rc) : "m" (res[8]) );
+            if ( rc != 0x03 )
+                goto fail;
+        }
         printf("okay\n");
     }
     else
@@ -3567,7 +3599,7 @@ int main(int argc, char **argv)
     printf("%-40s", "Testing vmovsd %xmm5,16(%ecx){%k3}...");
     memset(res, 0x88, 128);
     memset(res + 20, 0x77, 8);
-    if ( stack_exec && simd_check_avx512f() )
+    if ( stack_exec && simd_check_avx512f_sc() )
     {
         decl_insn(vmovsd_masked_to_mem);
 
@@ -3785,7 +3817,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing {evex} vmovd %xmm3,32(%ecx)...");
-    if ( stack_exec && simd_check_avx512f() )
+    if ( stack_exec && simd_check_avx512f_sc() )
     {
         decl_insn(evex_vmovd_to_mem);
 
@@ -3810,7 +3842,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing {evex} vmovd 32(%ecx),%xmm4...");
-    if ( stack_exec && simd_check_avx512f() )
+    if ( stack_exec && simd_check_avx512f_sc() )
     {
         decl_insn(evex_vmovd_from_mem);
 
@@ -3823,11 +3855,22 @@ int main(int argc, char **argv)
         rc = x86_emulate(&ctxt, &emulops);
         if ( rc != X86EMUL_OKAY || !check_eip(evex_vmovd_from_mem) )
             goto fail;
-        asm ( "vmovd %1, %%xmm0\n\t"
-              "vpcmpeqd %%zmm4, %%zmm0, %%k0\n\t"
-              "kmovw %%k0, %0" : "=r" (rc) : "m" (res[8]) );
-        if ( rc != 0xffff )
-            goto fail;
+        if ( simd_check_avx512f() )
+        {
+            asm ( "vmovd %1, %%xmm0\n\t"
+                  "vpcmpeqd %%zmm4, %%zmm0, %%k0\n\t"
+                  "kmovw %%k0, %0" : "=r" (rc) : "m" (res[8]) );
+            if ( rc != 0xffff )
+                goto fail;
+        }
+        else
+        {
+            asm ( "vmovd %1, %%xmm0\n\t"
+                  "vpcmpeqd %%xmm4, %%xmm0, %%k0\n\t"
+                  "kmovb %%k0, %0" : "=r" (rc) : "m" (res[8]) );
+            if ( rc != 0x0f )
+                goto fail;
+        }
         printf("okay\n");
     }
     else
@@ -4000,7 +4043,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing {evex} vmovd %xmm2,%ebx...");
-    if ( stack_exec && simd_check_avx512f() )
+    if ( stack_exec && simd_check_avx512f_sc() )
     {
         decl_insn(evex_vmovd_to_reg);
 
@@ -4026,7 +4069,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing {evex} vmovd %ebx,%xmm1...");
-    if ( stack_exec && simd_check_avx512f() )
+    if ( stack_exec && simd_check_avx512f_sc() )
     {
         decl_insn(evex_vmovd_from_reg);
 
@@ -4040,11 +4083,22 @@ int main(int argc, char **argv)
         rc = x86_emulate(&ctxt, &emulops);
         if ( (rc != X86EMUL_OKAY) || !check_eip(evex_vmovd_from_reg) )
             goto fail;
-        asm ( "vmovd %1, %%xmm0\n\t"
-              "vpcmpeqd %%zmm1, %%zmm0, %%k0\n\t"
-              "kmovw %%k0, %0" : "=r" (rc) : "m" (res[8]) );
-        if ( rc != 0xffff )
-            goto fail;
+        if ( simd_check_avx512f() )
+        {
+            asm ( "vmovd %1, %%xmm0\n\t"
+                  "vpcmpeqd %%zmm1, %%zmm0, %%k0\n\t"
+                  "kmovw %%k0, %0" : "=r" (rc) : "m" (res[8]) );
+            if ( rc != 0xffff )
+                goto fail;
+        }
+        else
+        {
+            asm ( "vmovd %1, %%xmm0\n\t"
+                  "vpcmpeqd %%xmm1, %%xmm0, %%k0\n\t"
+                  "kmovb %%k0, %0" : "=r" (rc) : "m" (res[8]) );
+            if ( rc != 0x0f )
+                goto fail;
+        }
         printf("okay\n");
     }
     else
@@ -4128,7 +4182,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing {evex} vmovq %xmm11,32(%ecx)...");
-    if ( stack_exec && simd_check_avx512f() )
+    if ( stack_exec && simd_check_avx512f_sc() )
     {
         decl_insn(evex_vmovq_to_mem2);
 
@@ -4218,7 +4272,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing vmovq %xmm22,%rbx...");
-    if ( stack_exec && simd_check_avx512f() )
+    if ( stack_exec && simd_check_avx512f_sc() )
     {
         decl_insn(evex_vmovq_to_reg);
 
@@ -5509,7 +5563,7 @@ int main(int argc, char **argv)
         printf("skipped\n");
 
     printf("%-40s", "Testing vmovsh 8(%ecx),%xmm5...");
-    if ( stack_exec && simd_check_avx512fp16() )
+    if ( stack_exec && simd_check_avx512fp16_sc() )
     {
         decl_insn(vmovsh_from_mem);
         decl_insn(vmovw_to_gpr);
@@ -5527,14 +5581,28 @@ int main(int argc, char **argv)
         rc = x86_emulate(&ctxt, &emulops);
         if ( (rc != X86EMUL_OKAY) || !check_eip(vmovsh_from_mem) )
             goto fail;
-        asm volatile ( "kmovw     %2, %%k1\n\t"
-                       "vmovdqu16 %1, %%zmm4%{%%k1%}%{z%}\n\t"
-                       "vpcmpeqw  %%zmm4, %%zmm5, %%k0\n\t"
-                       "kmovw     %%k0, %0"
-                       : "=g" (rc)
-                       : "m" (res[2]), "r" (1) );
-        if ( rc != 0xffff )
-            goto fail;
+        if ( simd_check_avx512fp16() )
+        {
+            asm volatile ( "kmovw     %2, %%k1\n\t"
+                           "vmovdqu16 %1, %%zmm4%{%%k1%}%{z%}\n\t"
+                           "vpcmpeqw  %%zmm4, %%zmm5, %%k0\n\t"
+                           "kmovw     %%k0, %0"
+                           : "=g" (rc)
+                           : "m" (res[2]), "r" (1) );
+            if ( rc != 0xffff )
+                goto fail;
+        }
+        else
+        {
+            asm volatile ( "kmovb     %2, %%k1\n\t"
+                           "vmovdqu16 %1, %%xmm4%{%%k1%}%{z%}\n\t"
+                           "vpcmpeqw  %%xmm4, %%xmm5, %%k0\n\t"
+                           "kmovb     %%k0, %0"
+                           : "=g" (rc)
+                           : "m" (res[2]), "r" (1) );
+            if ( rc != 0xff )
+                goto fail;
+        }
         printf("okay\n");
 
         printf("%-40s", "Testing vmovsh %xmm4,2(%eax){%k3}...");
--- a/tools/tests/x86_emulator/x86-emulate.c
+++ b/tools/tests/x86_emulator/x86-emulate.c
@@ -244,7 +244,7 @@ int emul_test_get_fpu(
             break;
     case X86EMUL_FPU_opmask:
     case X86EMUL_FPU_zmm:
-        if ( cpu_has_avx512f )
+        if ( cpu_has_avx512f || cpu_has_avx10_1 )
             break;
     default:
         return X86EMUL_UNHANDLEABLE;
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -207,6 +207,12 @@ void wrpkru(unsigned int val);
                                      xcr0_mask(6))
 #define cpu_has_avx_vnni_int16      (cpu_policy.feat.avx_vnni_int16 && \
                                      xcr0_mask(6))
+                                    /* TBD: Is bit 6 (ZMM_Hi256) really needed here? */
+#define cpu_has_avx10_1             (cpu_policy.feat.avx10 && xcr0_mask(0xe6))
+#define cpu_has_avx10_1_256         (cpu_has_avx10_1 && \
+                                     (cpu_policy.avx10.vsz256 || \
+                                      cpu_policy.avx10.vsz512))
+#define cpu_has_avx10_1_512         (cpu_has_avx10_1 && cpu_policy.avx10.vsz512)
 
 #define cpu_has_xgetbv1             (cpu_has_xsave && cpu_policy.xstate.xgetbv1)
 



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:23:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:23:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854417.1267636 (Exim 4.92)
	(envelope-from )
	id 1tLJrv-0004Yp-Ud; Wed, 11 Dec 2024 10:22:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854417.1267636; Wed, 11 Dec 2024 10:22: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 1tLJrv-0004Yi-Qz; Wed, 11 Dec 2024 10:22:59 +0000
Received: by outflank-mailman (input) for mailman id 854417;
 Wed, 11 Dec 2024 10:22: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 1tLJoF-00076S-9d
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:19:11 +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 594722d0-b7a9-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 11:19:04 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3862d6d5765so2860917f8f.3
 for ; Wed, 11 Dec 2024 02:19: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
 d2e1a72fcca58-725e4b13545sm6224682b3a.126.2024.12.11.02.19.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:19: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: 594722d0-b7a9-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733912349; x=1734517149; 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=Zb0r/1KGI0Knl/6PQXuJWXBeJ6RFMwkqP6qhC8BvpLo=;
        b=b0yYPgrMW9B/O9aMBKenRzu672l5dWYTyE5kJPw0g+Sng4ISfuOMCVw5Jk/82yVcmq
         HOKggKMSBKUQ+qthlsV6BJp0/oUFn73UPE2U80UyNmUHb5ix0WY0qLNHVY+/kqiBSw48
         cgtgI+lsR7C5jfvdk78mOFDY5ZTP8t05QXfMPI+Odwm0rQoc3hPbUADUHR/3rSgeU2oB
         0+cm78ADRL9dNBnnhgXMz+CJOcSvi5K6qmftU+CDpPJLyqYLIHQJ9TMaE8PRye6CHBhH
         +WMhL8fz0G6PsVThj+45PladPvxsRrii+tg2ko/0U+1vQaZIFlK5VD9xB6sb8k/BEjl9
         rSlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733912349; x=1734517149;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Zb0r/1KGI0Knl/6PQXuJWXBeJ6RFMwkqP6qhC8BvpLo=;
        b=AfRcEeKffOSo1GuatKlNwRH1T/1M4xjLMEx8hrj5kta1iGhUQOedhhV1w8+epuJMZX
         OKsr0g1G4ABOzWTvaMMkUjkbfZDCp3vx5KUka95YSaZPSLZc8hZPlcjBBCFIpwP5Lw7t
         MyfLBuVZOzzkAu+5XHUb22NH+F3lrkRSvXyLnW3tSIz1chBGMEJWL9D5PA9PcLYUXLdq
         VCkbmj7XCxNfsQj//XsqYUx/29Svf2aJiWPdqRa+p6m7G9hX9KiN7ps1N9NRGzkmQKIL
         NSNSYnr1EvKTNs/bRGtr5Et4gTQMF+jsyKUPu8kHvATyAD9jMeBAbO7NVp9vrB75FB6a
         0iWA==
X-Gm-Message-State: AOJu0YzjT6n8JE0nvEElMNO5mOVTs+Vz+fF3YaZyha5oi9pNxxwtM4Kz
	LwL7dfs6QDGDXKIWvEl1kMGmJCHcDxBZb0W1hIRawjJKZagSrd1vAnwqFeV6PnBOrUI9oQWSqnU
	=
X-Gm-Gg: ASbGncu/+axGyXfOVYWv8uhN7K6kKgkLTckOXz46ZwUFz3+vSAu6+6Q3o+YcF6C6Kgu
	Ev5OaZqBKVzWLkb8TCvbtKYTqYaQgd7KSeNIJGeobr2ttuD1LSKaanEnwN3SeSJIpci5P87smX5
	b+xA97b3S21/4gvwPSCXPSALNWOxqTIBz4NUhSwQ2U/X9Wf2n3KKr6wRCDndO/lP7Dqcy9zD8F8
	6vICKbnl+bEvFht5OPkmIk5AcNYLPEnRjAi8x4+1LXrJ7bmIPh2l/Pph97qXcGhX/XYAfc3iM6D
	UtdgY4ha2Alwcpw5ArMLLEhbg3ONMu5qOE0/B0Y=
X-Google-Smtp-Source: AGHT+IGboT55AhabOdd2V6EwEZ/3tiKMObX482bdzmGsnPOVsItqG7tYDEPePdf8k2BNhmZSelFdew==
X-Received: by 2002:a5d:584c:0:b0:382:4115:1ccb with SMTP id ffacd0b85a97d-3864ce49607mr1940850f8f.7.1733912349031;
        Wed, 11 Dec 2024 02:19:09 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 11:19:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v3 11/16] x86emul: support AVX10.2 minmax insns
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@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: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

While they use new major opcodes, they are still pretty similar to
various existing insns.

Signed-off-by: Jan Beulich 
---
Spec rev 002 says VMINMAXNEPBF16, yet that's going to change to
VMINMAXPBF16.
---
SDE: ???
---
v3: New.

--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -718,6 +718,11 @@ static const struct test avx10_2_all[] =
     INSN(comxsh,           f2, map5, 2f,    el, fp16, el),
     INSN(comxss,           f2,   0f, 2f,    el,    d, el),
     INSN(dpphps,             , 0f38, 52,    vl,    d, vl),
+    INSN(minmax,           66, 0f3a, 52,    vl,   sd, vl),
+    INSN(minmax,           66, 0f3a, 53,    el,   sd, el),
+    INSN(minmaxpbf16,      f2, 0f3a, 52,    vl, bf16, vl),
+    INSN(minmaxph,           , 0f3a, 52,    vl, fp16, vl),
+    INSN(minmaxsh,           , 0f3a, 53,    el, fp16, el),
     INSN(mpsadbw,          f3, 0f3a, 42,    vl, d_nb, vl),
     INSN(pdpbssd,          f2, 0f38, 50,    vl,    d, vl),
     INSN(pdpbssds,         f2, 0f38, 51,    vl,    d, vl),
--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -2091,6 +2091,11 @@ static const struct evex {
     { { 0x44 }, 3, T, R, pfx_66, WIG, Ln }, /* vpclmulqdq */
     { { 0x50 }, 3, T, R, pfx_66, Wn, Ln }, /* vrangep{s,d} */
     { { 0x51 }, 3, T, R, pfx_66, Wn, LIG }, /* vranges{s,d} */
+    { { 0x52 }, 3, T, R, pfx_no, W0, Ln }, /* vminmaxph */
+    { { 0x52 }, 3, T, R, pfx_66, Wn, Ln }, /* vminmaxp{s,d} */
+    { { 0x52 }, 3, T, R, pfx_f2, W0, Ln }, /* vminmaxpbf16 */
+    { { 0x53 }, 3, T, R, pfx_no, W0, LIG }, /* vminmaxsh */
+    { { 0x53 }, 3, T, R, pfx_66, Wn, LIG }, /* vminmaxs{s,d} */
     { { 0x54 }, 3, T, R, pfx_66, Wn, Ln }, /* vfixupimmp{s,d} */
     { { 0x55 }, 3, T, R, pfx_66, Wn, LIG }, /* vfixumpimms{s,d} */
     { { 0x56 }, 3, T, R, pfx_no, W0, Ln }, /* vreduceph */
--- a/xen/arch/x86/x86_emulate/decode.c
+++ b/xen/arch/x86/x86_emulate/decode.c
@@ -499,6 +499,8 @@ static const struct ext0f3a_table {
     [0x4c] = { .simd_size = simd_packed_int, .four_op = 1 },
     [0x50] = { .simd_size = simd_packed_fp, .d8s = d8s_vl },
     [0x51] = { .simd_size = simd_scalar_vexw, .d8s = d8s_dq },
+    [0x52] = { .simd_size = simd_packed_fp, .d8s = d8s_vl },
+    [0x53] = { .simd_size = simd_scalar_vexw, .d8s = d8s_dq },
     [0x54] = { .simd_size = simd_packed_fp, .d8s = d8s_vl },
     [0x55] = { .simd_size = simd_scalar_vexw, .d8s = d8s_dq },
     [0x56] = { .simd_size = simd_packed_fp, .two_op = 1, .d8s = d8s_vl },
@@ -1474,6 +1476,7 @@ int x86emul_decode(struct x86_emulate_st
                 case 0x0a: /* vrndscalesh */
                 case 0x26: /* vfpclassph */
                 case 0x27: /* vfpclasssh */
+                case 0x53: /* vminmaxsh */
                 case 0x56: /* vgetmantph */
                 case 0x57: /* vgetmantsh */
                 case 0x66: /* vreduceph */
@@ -1482,6 +1485,11 @@ int x86emul_decode(struct x86_emulate_st
                         s->fp16 = true;
                     break;
 
+                case 0x52: /* vminmaxp{h,bf16} */
+                    if ( !s->evex.pfx || s->evex.pfx == vex_f2 )
+                        s->fp16 = true;
+                    break;
+
                 case 0xc2: /* vpcmp{p,s}h */
                     if ( !(s->evex.pfx & VEX_PREFIX_DOUBLE_MASK) )
                         s->fp16 = true;
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -7716,6 +7716,21 @@ x86_emulate(
         generate_exception_if(vex.w, X86_EXC_UD);
         goto simd_0f_int_imm8;
 
+    case X86EMUL_OPC_EVEX_F2(0x0f3a, 0x52): /* vminmaxpbf16 $imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+        generate_exception_if(ea.type != OP_MEM && evex.brs, X86_EXC_UD);
+        op_bytes = 16 << evex.lr;
+        /* fall through */
+    case X86EMUL_OPC_EVEX(0x0f3a, 0x52): /* vminmaxph $imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX(0x0f3a, 0x53): /* vminmaxsh $imm,xmm/m16,xmm,xmm,xmm{k} */
+        generate_exception_if(vex.w, X86_EXC_UD);
+        /* fall through */
+    case X86EMUL_OPC_EVEX_66(0x0f3a, 0x52): /* vminmaxp{s,d} $imm8,[xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_66(0x0f3a, 0x53): /* vminmaxs{s,d} $imm8,xmm/mem,xmm,xmm{k} */
+        vcpu_must_have(avx10, 2);
+        if ( ea.type != OP_REG || !evex.brs )
+            avx512_vlen_check(b & 1);
+        goto simd_imm8_zmm;
+
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x5c): /* vfmaddsubps {x,y}mm,{x,y}mm/mem,{x,y}mm,{x,y}mm */
                                            /* vfmaddsubps {x,y}mm/mem,{x,y}mm,{x,y}mm,{x,y}mm */
     case X86EMUL_OPC_VEX_66(0x0f3a, 0x5d): /* vfmaddsubpd {x,y}mm,{x,y}mm/mem,{x,y}mm,{x,y}mm */



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:25:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:25:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854426.1267646 (Exim 4.92)
	(envelope-from )
	id 1tLJuU-0005Li-Ai; Wed, 11 Dec 2024 10:25:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854426.1267646; Wed, 11 Dec 2024 10:25: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 1tLJuU-0005Lb-6s; Wed, 11 Dec 2024 10:25:38 +0000
Received: by outflank-mailman (input) for mailman id 854426;
 Wed, 11 Dec 2024 10:25: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 1tLJuT-0005LV-6S
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:25:37 +0000
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com
 [2a00:1450:4864:20::42d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3f1e8cec-b7aa-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 11:25:30 +0100 (CET)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-385d7b4da2bso5359185f8f.1
 for ; Wed, 11 Dec 2024 02:25: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
 d9443c01a7336-215f8f29bcbsm103307385ad.262.2024.12.11.02.25.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:25: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: 3f1e8cec-b7aa-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733912735; x=1734517535; 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=Q3MJb1KfqWFsFw4tyXv9SWQKoj9MO+pwCgMweM5Me9w=;
        b=dBnu8PczrMw0XR65IVtF+9gXlrWvL8dl185+MNxcvX49ufWqg4kWlEBjRjUV72hjau
         lYWqTnnrjXYbXMRgAJLIqwuBoiSyaFWnrlK/AnqN2ufcKlSeDtwI/LmVbHgvU9BLjBlq
         UoojkA4iuDwEZsHqoNUXKGLzWzbVJ8qEPU2ZiInHKdqSrgU3WNywCNlDxeZmlg8rUqPS
         P1OHHU+zaBmTpPbPD1KvB6XQGghXZCJI1c2ntW2r+cLQ24rBO913e2aFkoaGDp987n12
         O7DnBsjPrrXMcnebiUWWLRAtUpmzICJTQ2PNa2tNC35KWBwvJyuVpe6IkuRe9rnabK6u
         cfNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733912735; x=1734517535;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Q3MJb1KfqWFsFw4tyXv9SWQKoj9MO+pwCgMweM5Me9w=;
        b=jjA34PvvV2SSxLh/xWfQm5vbyafvt+9vw9k2MpS3fweZZ5GLNycmolsXTwZJBJpVOA
         ofqs7RMBqH3ChWDjNYBLX1Fl6XHXOwf+/Dsu+vSOeQFG4oTZkXt7ZcHf8kpr2fvpCbQW
         hR1aWFSXA8l6Y1zRju1fMqy+d9stLPGjNpkBfUHBN960BNaAqRuZVp8XqK/dx2VuYTPK
         XQPrUTejeq9fvkUW7VwoNJQX2oTGguiCDJFUnHSq+RCC+tIk4rwsPGsX1DIJ7zMHLdVM
         QH1pjWIrol0u/vkCMqPHkgy8Fwca4Nlwx0ETWMoLtC+a3uBcPfQO8L6RyTdtmwJQcnt6
         /2jA==
X-Forwarded-Encrypted: i=1; AJvYcCVONpQDEXxzQ/JqCqT4xIx+bHCHeIorVK6CjHEPGqc7A+uAUVt331FSg/VdtXObHDElqnD0ao+DcjU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxPxtxc5tYzur8I+NgB5hI2nT777kJ6Z8Lm5XAk0yHJWVKr300M
	5B04+DLieJ8uBjRESHYVLCyujcGvJA649njM3qvsYHWCVQ/shSHjD5lsNSr7SA==
X-Gm-Gg: ASbGncsorjKS0I7JVEqLlt7haQhgEDLjDlZH/9YGI+/jo2AHF4NfntUYG82xhbfkY/K
	fz2J51jPuRKjeTAoN7/BJHxI4ZZd06o5bIwmkQRojCk5wJD7zY7N+kn6exHEQw9o2IPauDy0d/U
	boxClSdBMlDkX8jIafU6nWxxT3uXFnU1CW+fIpHjgWvxgXOgurXOArNEkdg9O7ndRVnwV6nZf49
	8Hu2cHN08JYXd/JHNrv8iIKZkT8zFfOjkRu9yqw4ZQGCx+LAQ5jHnrcw6AI0DhRXonM9G1DGT6E
	NQiwynQ+qpUlH4Fc+wwj5HG4bTZa6aULsgZD7us=
X-Google-Smtp-Source: AGHT+IEQNV5/xVxKUOUmU+DRXTtDlMzAs3saKN83rxXFG0hE9JGr9oNSa5u+OWdVKxPThLHN3TWAow==
X-Received: by 2002:a05:6000:4026:b0:385:e9de:d521 with SMTP id ffacd0b85a97d-3864ce867a0mr1815684f8f.8.1733912734611;
        Wed, 11 Dec 2024 02:25:34 -0800 (PST)
Message-ID: <0ac6dc04-f90f-4540-b1cb-dc825cc1a0db@suse.com>
Date: Wed, 11 Dec 2024 11:25:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/1] vpci: Add resizable bar support
To: "Chen, Jiqian" 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , "Huang, Ray"
 ,
 "xen-devel@lists.xenproject.org" ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20241202060956.1124162-1-Jiqian.Chen@amd.com>
 <4e4df0ee-67f6-41e3-bfc7-e78011680015@suse.com>
 
 <1e0576d9-400e-4483-8dd1-061e215a00cd@suse.com>
 
 
 
 
 <328c3bb6-1adf-4c64-81d4-40704ea1f19e@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.12.2024 11:19, Chen, Jiqian wrote:
> On 2024/12/11 16:53, Jan Beulich wrote:
>> On 11.12.2024 09:43, Roger Pau Monné wrote:
>>> On Wed, Dec 11, 2024 at 09:25:16AM +0100, Jan Beulich wrote:
>>>> On 11.12.2024 08:57, Chen, Jiqian wrote:
>>>>> On 2024/12/10 19:25, Roger Pau Monné wrote:
>>>>>> So you suggest that the capability should be hidden in that case?  We
>>>>>> have logic to hide capabilities, just not used for the hardware
>>>>>> domain.  It would need some extra wiring to be capable of hiding
>>>>>> failed capabilities.
>>>>> Can you give me a guidance on how to hide a failed capability?
>>>>> What codes are current logic to hide capabilities?
>>>>> Then maybe I can add a patch to implement it.
>>>>
>>>> It's really the other way around right now for "normal" capabilities:
>>>> We whitelist what we expose. See init_header()'s logic after checking
>>>> the PCI_STATUS_CAP_LIST bit. Actually past that block there's
>>>>
>>>>         /* Extended capabilities read as zero, write ignore */
>>>>         rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL, 0x100, 4,
>>>>                                (void *)0);
>>>>
>>>> I.e. no extended capabilities are exposed at all right now to DomU-s.
>>>> For Dom0 I guess we shouldn't use whitelisting, but the (extended)
>>>> capability list(s) would need similarly virtualizing to be able to
>>>> hide some.
>>>
>>> Given this capability is only to be exposed to the hw domain (at least
>>> for now), I'm not sure it's fair to ask to add all this
>>> infrastructure as part of adding the new capability.  It would be great
>>> to have it, but doesn't seem fair when there's already MSI and MSI-X
>>> implemented without such support.
>>
>> Well, of course this can also be modeled after MSI/MSI-X, failing
>> assignment when initialization for a capability fails. Yet while for
>> MSI / MSI-X this feels okay-ish (considering that many devices now
>> can't even operate very well without either of the two), I'd expect
>> BAR resizing to not be something that drivers (typically) rely on.
>> "Typically" because iirc Jiqian said the AMD display driver actually
>> does.
> You mean what I said in last version?

Yes.

Jan

> It is "amdgpu driver saves and restores the same pci state during initiazation without disabling memory decoding, that caused Roger's method not work".
> And currently running amdgpu on Xen hypervisor has two scenarios, 
> 1. APU does not rely on ReBar capability, because APU's vram are all CPU accessible.
> 2. But for discrete GPU, they can't work based on current Xen codes, it needs resize Bar to make all vram CPU accessible. That is why I sent this patch to add Rebar support in Xen.
> 
>>
>> Jan
> 



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:26:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:26:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854444.1267656 (Exim 4.92)
	(envelope-from )
	id 1tLJvO-0005rn-Ie; Wed, 11 Dec 2024 10:26:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854444.1267656; Wed, 11 Dec 2024 10:26: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 1tLJvO-0005rg-FH; Wed, 11 Dec 2024 10:26:34 +0000
Received: by outflank-mailman (input) for mailman id 854444;
 Wed, 11 Dec 2024 10:26: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 1tLJvN-0005k1-OD
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:26:33 +0000
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com
 [2a00:1450:4864:20::234])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 648bc4bd-b7aa-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 11:26:33 +0100 (CET)
Received: by mail-lj1-x234.google.com with SMTP id
 38308e7fff4ca-2ffa49f623cso71087231fa.1
 for ; Wed, 11 Dec 2024 02:26:33 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3021de5c435sm10205201fa.9.2024.12.11.02.26.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:26: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: 648bc4bd-b7aa-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1733912793; x=1734517593; darn=lists.xenproject.org;
        h=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=eNBfv73uiEz1X8g9TbVw7Zgoo8BUPUn9uAQLa0yatfE=;
        b=PnNH/hk3+oEwZGRB7GLfAvDxc2jLhEVDfoQa7xPK8KfeBOfQmkY17dfh/ydzhVYMcQ
         VwOOZI7zYnKOYR0kjQ+HdJYJpBOM8b2bm65qnXLg98s5/u1zEt1f90/LIAVuHen14Gdh
         7RFCLqQ9/ePeDJWtsSUegof8O58FTQYEnFLoQaLtMlBf4jwAiW4dqXHSJ4RcDCg5C70y
         dO3A0CsH1Y1qg1vgSSXYtKg69han/jfaq6xb5TuNkcZ0daMo7W4tPYF399ZQe8INg7FQ
         LyhbbiVRYp4lAFQODhZ+XKCTL2MqwqfzbT/BwFDb66LKM6Uy0OjSWeZmmBv0RrC28BEf
         Q5Zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733912793; x=1734517593;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=eNBfv73uiEz1X8g9TbVw7Zgoo8BUPUn9uAQLa0yatfE=;
        b=bh6JVRz+UK+YoJWNFSBh1n8IpdJ6JwSaU+RSoDgu5e+UqIA2/E9uyoJvZ+i/Na6IQt
         hnoeJFxQP72p28BT6UH4vOYAThWeuKeYLGHB54jano7vv79b8vRAv33DaNyCYc51NWMs
         Y3lQeTA43n5E55R8jMt4HOG8su/nCcdKoCOLaRirFu0fYssjwqpzb8PnRasK3M4aHA4R
         SWqDA1HMSEZ9X/JKxLJ2khzpz9Z3cKbo19fRbsKfMlnrEm6SXp3ETTsGwJ1F0xA6Dkic
         /cmFnUMFQt8KEH6wB8rSDN/9vkhOhPjjRdykTl2/HqMhh2peDI94ZlFWXY53Qh3dBJI1
         GSTA==
X-Forwarded-Encrypted: i=1; AJvYcCXCPmMZWTQMI/VrczCwQxRm/y1rVrZv0xl5T84mgwNv++bwLg7y9JyZBphwhozi05O/7uip6ftVlm4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyNozOkDACoyt9xz0cYxYbGxzhQUwBdMoQRZJU2eCM/2iqiDXOO
	PMQEhBuyR7omMzUZ9Mf4EZrXWpg5f6PrBhlikEN0mmhZhaYdM62l
X-Gm-Gg: ASbGncuVIluQwjanUTKnV7km4E8sCPvNNvewEpY0EcnSatK1/vMSLE0utPpaMZo2Gzy
	BwFJON+E1ZChbDZDfNHp9QJIEWoKlk5XixkCE9bYRmt3y0ZMEJAt604f7KwzwrLRFappmDYgl4D
	WIoHgIlOIzLZ0KSH8HBnvRvIaaOSoQy2A5HdSmI5Ka3ttYtAp6z2AKkhQP/gc6JOn6WffXB5pCd
	kaceaDqqPrdsv2LfQU4DhkOR+vneHvDSev4Jd/mYQcXqCw6PNfvYKQZZpiCH9S+3Ls=
X-Google-Smtp-Source: AGHT+IHmpm6wMs9vI8yQJhSjHFPvzcpGTGZFbDnnObopqUanpQiHPjRUKrVVBkGkfCGecGzmC+wwUg==
X-Received: by 2002:a05:651c:b06:b0:302:18fa:3be0 with SMTP id 38308e7fff4ca-30240d64e8cmr8474311fa.22.1733912792237;
        Wed, 11 Dec 2024 02:26:32 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------HpJlsZP4b9kDAnNiqGYz1zoG"
Message-ID: 
Date: Wed, 11 Dec 2024 11:26:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 5/6] xen/riscv: implement relocate_fdt()
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: 
 
 
 <4dd6a2e9-d2b9-4402-907b-b9314d2346f7@gmail.com>
 <929d657d-ffe8-4243-ba01-fffa20b26205@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <929d657d-ffe8-4243-ba01-fffa20b26205@suse.com>

This is a multi-part message in MIME format.
--------------HpJlsZP4b9kDAnNiqGYz1zoG
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 12/10/24 5:20 PM, Jan Beulich wrote:
>>> Also recall my comment on one of your earlier series, regarding inclusive
>>> vs exclusive ranges. Can that please be sorted properly as a prereq, to
>>> avoid extending the inconsistency?
>> Yes, I remember that and at the moment everything ( DIRECTMAP_VIRT_END, FRAMETABLE_VIRT_END )
>> is following "inclusive" way. Considering that you remind me that could you please tell me more time
>> what I am missing?
> First the table azt the top of config.h uses all exclusive upper bounds.
> And then DIRECTMAP_SIZE's definition assumes DIRECTMAP_SLOT_END would be
> exclusive, when it's inclusive.

Really missed to update the tale on the top of config.h.

But it seems to me like any *_SIZE will be defined in exclusive way by its nature, doesn't it?
For example, size of directmap is (509-200+1)<<30 = 0x7F80000000 and it is not really (
0x7F80000000 - 1 ) = 7F7FFFFFFF.

I prefer to have DIRECTMAP_{SIZE,VIRT_END} defined as now:
   #define DIRECTMAP_SIZE          (SLOTN(DIRECTMAP_SLOT_END + 1) - SLOTN(DIRECTMAP_SLOT_START))
   #define DIRECTMAP_VIRT_END      (DIRECTMAP_VIRT_START + DIRECTMAP_SIZE - 1)
( of course with making upper bounds inclusive in the table on the top of config.h )

>
>>>> +        set_fixmap(FIX_MISC, maddr_to_mfn(paddr), PAGE_HYPERVISOR_RW);
>>>> +        memcpy(dst, src + s, l);
>>>> +        clean_dcache_va_range(dst, l);
>>> Why is this necessary here? You're copying to plain RAM that Xen alone
>>> is using.
>> It is Arm specific:
>> ```
>> commit c60209d77e2c02de110ca0fdaa2582ef4e53d8fd
>> Author: Stefano Stabellini
>> Date:   Mon Jan 21 12:40:31 2013 +0000
>>
>>       xen/arm: flush dcache after memcpy'ing the kernel image
>>       
>>       After memcpy'ing the kernel in guest memory we need to flush the dcache
>>       to make sure that the data actually reaches the memory before we start
>>       executing guest code with caches disabled.
>>       
>>       copy_from_paddr is the function that does the copy, so add a
>>       flush_xen_dcache_va_range there.
>> ```
>> I wanted to put copy_from_paddr() to some common place at the end but in RISC-V cache is always enabled
>> ( I don't see an instruction in the spec for disable/enable cache ) so this issue isn't present for RISC-V
>> and clean_dcache_va_range() should/could be dropped.
> That plus there's no kernel in sight just yet.

( clarification ) will it change something if kernel will be loaded now? It seems even if we are copying kernel in guest
memory we still don't need to flush the dcache as cache is enabled and cache coherence protocol will do a work automatically.

~ Oleksii

--------------HpJlsZP4b9kDAnNiqGYz1zoG
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    
On 12/10/24 5:20 PM, Jan Beulich wrote:

    

      

        

          
Also recall my comment on one of your earlier series, regarding inclusive
vs exclusive ranges. Can that please be sorted properly as a prereq, to
avoid extending the inconsistency?


        

        
Yes, I remember that and at the moment everything ( DIRECTMAP_VIRT_END, FRAMETABLE_VIRT_END )
is following "inclusive" way. Considering that you remind me that could you please tell me more time
what I am missing?


      

      
First the table azt the top of config.h uses all exclusive upper bounds.
And then DIRECTMAP_SIZE's definition assumes DIRECTMAP_SLOT_END would be
exclusive, when it's inclusive.

    

    
Really missed to update the tale on the top of config.h.

But it seems to me like any *_SIZE will be defined in exclusive way by its nature, doesn't it?
For example, size of directmap is (509-200+1)<<30 = 0x7F80000000 and it is not really (
0x7F80000000 - 1 ) = 7F7FFFFFFF.

I prefer to have DIRECTMAP_{SIZE,VIRT_END} defined as now:
  #define DIRECTMAP_SIZE          (SLOTN(DIRECTMAP_SLOT_END + 1) - SLOTN(DIRECTMAP_SLOT_START))
  #define DIRECTMAP_VIRT_END      (DIRECTMAP_VIRT_START + DIRECTMAP_SIZE - 1)
( of course with making upper bounds inclusive in the table on the top of config.h )



    

      



      

        

          

            
+        set_fixmap(FIX_MISC, maddr_to_mfn(paddr), PAGE_HYPERVISOR_RW);
+        memcpy(dst, src + s, l);
+        clean_dcache_va_range(dst, l);


          

          
Why is this necessary here? You're copying to plain RAM that Xen alone
is using.


        

        
It is Arm specific:
```
commit c60209d77e2c02de110ca0fdaa2582ef4e53d8fd
Author: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
Date:   Mon Jan 21 12:40:31 2013 +0000

     xen/arm: flush dcache after memcpy'ing the kernel image
     
     After memcpy'ing the kernel in guest memory we need to flush the dcache
     to make sure that the data actually reaches the memory before we start
     executing guest code with caches disabled.
     
     copy_from_paddr is the function that does the copy, so add a
     flush_xen_dcache_va_range there.
```
I wanted to put copy_from_paddr() to some common place at the end but in RISC-V cache is always enabled
( I don't see an instruction in the spec for disable/enable cache ) so this issue isn't present for RISC-V
and clean_dcache_va_range() should/could be dropped.


      

      
That plus there's no kernel in sight just yet.

    

    
( clarification ) will it change something if kernel will be loaded now? It seems even if we are copying kernel in guest
memory we still don't need to flush the dcache as cache is enabled and cache coherence protocol will do a work automatically.

~ Oleksii

  


--------------HpJlsZP4b9kDAnNiqGYz1zoG--


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:29:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:29:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854455.1267666 (Exim 4.92)
	(envelope-from )
	id 1tLJyK-0006XG-3c; Wed, 11 Dec 2024 10:29:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854455.1267666; Wed, 11 Dec 2024 10:29: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 1tLJyK-0006X9-0i; Wed, 11 Dec 2024 10:29:36 +0000
Received: by outflank-mailman (input) for mailman id 854455;
 Wed, 11 Dec 2024 10:29: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 1tLJyI-0006X3-RM
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:29:34 +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 cba5fd8c-b7aa-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 11:29:26 +0100 (CET)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3862a921123so3854826f8f.3
 for ; Wed, 11 Dec 2024 02: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
 98e67ed59e1d1-2ef68b5272bsm9668798a91.37.2024.12.11.02.29.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:29: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: cba5fd8c-b7aa-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733912970; x=1734517770; 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=ujBTJkvmO2v8Y+beaFy0sSs/m/XktSxubv6Dq+sEiHU=;
        b=WpepBenUEtHcd9eP9p44o1TQhaimP5b+uJgdYqsmkRilxx0g9Mc8CIJNH+s4Ydort7
         X/v+/95BSgPGhcSDIvzWwPpkKGZHEBiD9jxK2dOCJ7yYnKuzwIX6+twYFR0FYKtpyWu7
         AYmXurHLzuko3lL+W5aqkVmxwfISWD7wRFNtlSv2B/Rz3/PJ8zlamh4uvjufIbglDfJe
         Hw+mPcZLr/eFahRKE0m48ZVbBd7vIlRxoeL7159KhWBcG7EW/+urO2sVGwayaqH/ADn6
         dB1k13JgyBXxjaLKf3lE587BkPlWGp1F6Q3W0FFUtlhUCkZYRrUnIM/arNzN9+jkTkFT
         Pxtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733912970; x=1734517770;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=ujBTJkvmO2v8Y+beaFy0sSs/m/XktSxubv6Dq+sEiHU=;
        b=C33MYCOkEE4LFDBmHbAggKIKsoxuNZ8m0jCEJ4noKbQkYEJklxYjMHc74zhKlQcTf6
         cXsgKuIppHspJybtEgEiSFIOgYBU0BzrwRZHux8DvEkaH53ZmAFhkIZtsZ/bvC5hfZhR
         Ql37+Dk1BXWormueD2uGQF6nxru8X0noAkQeFgYTzMB3sd8492TrBMCuvA9qucbv/4xi
         zywFo/AMyyK60wXR0fAEAxrv5mQ3BnyyyZ/dARq4qgr/8K+bhQAdDE+RS4LjW6L/qE0t
         3R56RN7MKYWwRe1y18qAbm0qDi8uuQb/rn0kVcGCxi5Fek2OO00FDxX1vkhWnjTczpUC
         RADA==
X-Gm-Message-State: AOJu0Yw5J6nyGsiWlYgmC6rwp1g13aKebGiZqQlk5nKdNT/2l3cI5k7d
	9SIGC652cRyLYUMbCVgAXV2yjhlH6TwUMrbJfXBLOv5hvaGw92DbT7NXdUF/lY9/UTY88JPqDkI
	=
X-Gm-Gg: ASbGncvcH+ji23/IqHDeBbkJIkzPDdl/dDhyrNcYEHj0nfZyCTOmDnCUAvhwMO3+Tcl
	EQIfhKedWNp/BXFPOHB8fhMPuMthVtkTWMfBI42GBeI3mZwGRgI8u8f5a6BwfcTyqghSNLwqxzJ
	e82tmAnKWSauOZN9wDMto4ZmjDqqk3EQRKhWfjLSoKhktR6tgifCkJXiU+6UMg+EIBcyiuX1gWK
	h4uUiV+a5eJDYsbjqZzMqGqVsest0GTSoiGAaQjxluF5caxyXhR3gCo/WZua+rcmhv/0rucmjPu
	ZkYfYCU0k87IcgyNqQ4a9rG19sk4LnrXtM1QEE0=
X-Google-Smtp-Source: AGHT+IFsmYFIMF3UuxSbdCOdljfJU7H1TPXBRv4T6CKWO7LHMapK36wjCrqk58u7z9THYP5g6P/L+Q==
X-Received: by 2002:a5d:47a4:0:b0:385:e5d8:3ec2 with SMTP id ffacd0b85a97d-3864cea39aemr1896480f8f.28.1733912968951;
        Wed, 11 Dec 2024 02:29:28 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 11:29:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 00/16] x86: support AVX10
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@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: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.12.2024 11:09, Jan Beulich wrote:
> AVX10.1 is just a re-branding of certain AVX512 (sub)features, i.e.
> adds no new instructions. Therefore it's mostly relaxation that needs
> doing, plus dealing with the 256-bit-only case that AVX512 itself
> does not allow for. Luckily an unnecessary restriction on the mask
> register insns was taken out again, simplifying the actual emulator
> adjustments quite a bit.
> 
> AVX10.2 is adding quite a few new insns, support for which (new in v3)
> is roughly added chapter-wise as the spec has them (perhaps not in the
> order of the chapters there).
> 
> While it probably can be rebased ahead, the series in this form
> depends on the previously submitted "[PATCH v5 0/3] x86/CPUID: leaf
> pruning". It also is assumed to go on top of "[PATCH v7 0/7] x86emul:
> misc additions", albeit at most contextual dependencies ought to exit
> there.
> 
> I've tried to be very careful in rebasing ahead of other emulator
> patches I've been carrying, but almost all testing I've done is with
> all of those collectively in place.
> 
> 01: x86/CPUID: enable AVX10 leaf
> 02: x86emul: support AVX10.1
> 03: x86emul/test: use simd_check_avx512*() in main()
> 04: x86emul/test: drop cpu_has_avx512vl
> 05: x86emul: AVX10.1 testing
> 06: x86emul/test: engage AVX512VL via command line option
> 07: x86emul: support AVX10.2 256-bit embedded rounding / SAE
> 08: x86emul: support AVX10.2 scalar compare insns
> 09: x86emul: support AVX10.2 partial copy insns
> 10: x86emul: support AVX10.2 media insns
> 11: x86emul: support AVX10.2 minmax insns
> 12: x86emul: support AVX10.2 media insns
> 13: x86emul: support AVX10.2 saturating convert insns
> 14: x86emul: support other AVX10.2 convert insns
> 15: x86emul: support SIMD MOVRS
> 16: x86emul: support AVX10.2 forms of SM4 insns

I should probably have mentioned here two further opens:
1) Testing. So far I haven't been able to think of a good approach to test
   some (most?) of the new insns, beyond the EVEX Disp8 and predicates
   testing that's being taken care of in individual patches.
2) Supposedly there is a way to constrain guests to 256-bit vector size via
   a VMCS setting. The spec has no details beyond mentioning this fact.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:32:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:32:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854478.1267675 (Exim 4.92)
	(envelope-from )
	id 1tLK0n-0008Vu-GV; Wed, 11 Dec 2024 10:32:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854478.1267675; Wed, 11 Dec 2024 10:32: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 1tLK0n-0008Vn-Da; Wed, 11 Dec 2024 10:32:09 +0000
Received: by outflank-mailman (input) for mailman id 854478;
 Wed, 11 Dec 2024 10:32: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 1tLJpt-00076S-2v
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:20:53 +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 95e169e3-b7a9-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 11:20:46 +0100 (CET)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-385dece873cso3145205f8f.0
 for ; Wed, 11 Dec 2024 02:20: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
 d9443c01a7336-2162a479fc7sm72313335ad.47.2024.12.11.02.20.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:20: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: 95e169e3-b7a9-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733912451; x=1734517251; 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=EYrG6X8uwp+bs8ww0EgrMry1siCkDx4rXslRN+kZ534=;
        b=I9tDmfXpNDdMnWdAx45uwAji31lrAQty28jPDs38DEhMhsLai5N4X+IluaX17W45nf
         EEQ5AZj37KXEYOlVeVIKblB+GGs9Pacd7jZbAFxzaCqcztr98F6GFrwOscVvLdAPtXd0
         1IH+AMV6e0xHcOhBc5SvTCckm9phkPoAbR1Sc1cWDctTZC24kehKW0unkxLxcUE8PXa0
         1hJq1YOL1iaV13OWT0/Ytk9jffzxiB1nfOOkT01+NnKSazBt3/k1t3dO5YVAI8nx3FDV
         QcplgEllvycZNXIEXenFUArfbtsxGKPCOxmMzPDk2s1GV5UGu+CYohvRani0htFEup7V
         Q0dA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733912451; x=1734517251;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=EYrG6X8uwp+bs8ww0EgrMry1siCkDx4rXslRN+kZ534=;
        b=uVs8xEqp0kr2ogsYOrcZPtzCu7XeRdDfXm3hTslbEy1sKLYVbECeIt19dj4KMK6dWi
         E/FwVVXFb23LYaGwW3sxdXLX+yXdORba1YqKen2SVeHhFYFB1CE0sZ3LF4ozy+L5reeH
         FNi4ztrBwj8jcpHL+sjAdM66CB16X2iQL35iLphD3fZutCOwZrtW7NZhFuDex4apxfWl
         vlLel8NMozctrfN6d1Twmq/xAp0nruqj1SfLvGLpIQCYRTgRMn5lZ6G4fFYz8lsR1cV4
         grvUBOnNM6zN+Qv4QOrKW9aJ+UZheY6ydKVLaQy2Imgjf2ipySvUOEES5xloRGS4uZmK
         zjng==
X-Gm-Message-State: AOJu0YyQRk3mnhhxl3t3oQPuCGJH3xT/St5pibKqdWTqixA4elG9bhT7
	YaNLtiyN151yk0fehsbp/M+Wppz25oZJxhRUKLw3Nd3VKWDz0Sey+Bf5zGCCE4nf7tUGbbEgzx8
	=
X-Gm-Gg: ASbGncsK66NpLmo4B1YzLIqgAzqpu9juXTGvF7nhYPQ5APpOoVOkea/+j71M+q/ZSu2
	fW57O3VUycBIYIpCE68437kET1yQvLx+D4lsSb8GNwXFZiAx5eLpOlIg9kltynUmHPq+t4NrAXF
	hKsc+xIDkw5Ec2v/HeqntflGXQqL8SL429RoUDLhwee2n1lvnpjfdlEq7eGsfJsjELbcBKPv27D
	xhWdJruQWSdnuFzhs2Lxov9UbUgBt17ATSHYG68448+V+a+GSOx8G9yYdVH/98B7T7dF2HIyVGF
	YQfIGp9LmmsgBxHDUbmlDTQGtcp8l1aIoOqX2hI=
X-Google-Smtp-Source: AGHT+IHkPNXTc+Yha08gY4NqV2a4G7lJgQZ5Wt4aKB4fhNh+fd/5wUpTc08FUCVRmN9GgaLUv4O4pw==
X-Received: by 2002:a05:6000:18a3:b0:385:f5b6:9c9d with SMTP id ffacd0b85a97d-3864cea5696mr1748859f8f.33.1733912450680;
        Wed, 11 Dec 2024 02:20:50 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 11:20:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v3 14/16] x86emul: support other AVX10.2 convert insns
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@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: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Despite most of them being about conversion to BF8/HF8, they are still
somewhat similar to various existing convert insns.

Signed-off-by: Jan Beulich 
---
SDE: ???
---
v3: New.

--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -719,8 +719,22 @@ static const struct test avx10_2_all[] =
     INSN(comxsd,           f3,   0f, 2f,    el,    q, el),
     INSN(comxsh,           f2, map5, 2f,    el, fp16, el),
     INSN(comxss,           f2,   0f, 2f,    el,    d, el),
+    INSN(cvt2ps2phx,       66, 0f38, 67,    vl,    d, vl),
+    INSN(cvtbiasph2bf8,      , 0f38, 74,    vl, fp16, vl),
+    INSN(cvtbiasph2bf8s,     , map5, 74,    vl, fp16, vl),
+    INSN(cvtbiasph2hf8,      , map5, 18,    vl, fp16, vl),
+    INSN(cvtbiasph2hf8s,     , map5, 1b,    vl, fp16, vl),
+    INSN(cvthf82ph,        f2, map5, 1e,  vl_2,    b, vl),
+    INSN(cvtne2ph2bf8,     f2, 0f38, 74,    vl, fp16, vl),
+    INSN(cvtne2ph2bf8s,    f2, map5, 74,    vl, fp16, vl),
+    INSN(cvtne2ph2hf8,     f2, map5, 18,    vl, fp16, vl),
+    INSN(cvtne2ph2hf8s,    f2, map5, 1b,    vl, fp16, vl),
     INSN(cvtnebf162ibs,    f2, map5, 69,    vl, bf16, vl),
     INSN(cvtnebf162iubs,   f2, map5, 6b,    vl, bf16, vl),
+    INSN(cvtneph2bf8,      f3, 0f38, 74,    vl, fp16, vl),
+    INSN(cvtneph2bf8s,     f3, map5, 74,    vl, fp16, vl),
+    INSN(cvtneph2hf8,      f3, map5, 18,    vl, fp16, vl),
+    INSN(cvtneph2hf8s,     f3, map5, 1b,    vl, fp16, vl),
     INSN(cvtph2ibs,          , map5, 69,    vl, fp16, vl),
     INSN(cvtph2iubs,         , map5, 6b,    vl, fp16, vl),
     INSN(cvtps2ibs,        66, map5, 69,    vl,    d, vl),
--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -1952,6 +1952,7 @@ static const struct evex {
     { { 0x64 }, 2, T, R, pfx_66, Wn, Ln }, /* vpblendm{d,q} */
     { { 0x65 }, 2, T, R, pfx_66, Wn, Ln }, /* vblendmp{s,d} */
     { { 0x66 }, 2, T, R, pfx_66, Wn, Ln }, /* vpblendm{b,w} */
+    { { 0x67 }, 2, T, R, pfx_66, W0, Ln }, /* vcvt2ps2phx */
     { { 0x68 }, 2, T, R, pfx_f2, Wn, Ln }, /* vp2intersect{d,q} */
     { { 0x70 }, 2, T, R, pfx_66, W1, Ln }, /* vpshldvw */
     { { 0x71 }, 2, T, R, pfx_66, Wn, Ln }, /* vpshldv{d,q} */
@@ -1959,6 +1960,9 @@ static const struct evex {
     { { 0x72 }, 2, T, R, pfx_f3, W1, Ln }, /* vcvtneps2bf16 */
     { { 0x72 }, 2, T, R, pfx_f2, W1, Ln }, /* vcvtne2ps2bf16 */
     { { 0x73 }, 2, T, R, pfx_66, Wn, Ln }, /* vpshrdv{d,q} */
+    { { 0x74 }, 2, T, R, pfx_no, W0, Ln }, /* vcvtbiasph2bf8 */
+    { { 0x74 }, 2, T, R, pfx_f3, W0, Ln }, /* vcvtneph2bf8 */
+    { { 0x74 }, 2, T, R, pfx_f2, W0, Ln }, /* vcvtne2ph2bf8 */
     { { 0x75 }, 2, T, R, pfx_66, Wn, Ln }, /* vpermi2{b,w} */
     { { 0x76 }, 2, T, R, pfx_66, Wn, Ln }, /* vpermi2{d,q} */
     { { 0x77 }, 2, T, R, pfx_66, Wn, Ln }, /* vpermi2p{s,d} */
@@ -2122,8 +2126,15 @@ static const struct evex {
 }, evex_map5[] = {
     { { 0x10 }, 2, T, R, pfx_f3, W0, LIG }, /* vmovsh */
     { { 0x11 }, 2, T, W, pfx_f3, W0, LIG }, /* vmovsh */
+    { { 0x18 }, 2, T, R, pfx_no, W0, Ln }, /* vcvtbiasph2hf8 */
+    { { 0x18 }, 2, T, R, pfx_f3, W0, Ln }, /* vcvtneph2hf8 */
+    { { 0x18 }, 2, T, R, pfx_f2, W0, Ln }, /* vcvtne2ph2hf8 */
+    { { 0x1b }, 2, T, R, pfx_no, W0, Ln }, /* vcvtbiasph2hf8s */
+    { { 0x1b }, 2, T, R, pfx_f3, W0, Ln }, /* vcvtneph2hf8s */
+    { { 0x1b }, 2, T, R, pfx_f2, W0, Ln }, /* vcvtne2ph2hf8s */
     { { 0x1d }, 2, T, R, pfx_66, W0, Ln }, /* vcvtps2phx */
     { { 0x1d }, 2, T, R, pfx_no, W0, LIG }, /* vcvtss2sh */
+    { { 0x1e }, 2, T, R, pfx_f2, W0, Ln }, /* cvthf82ph */
     { { 0x2a }, 2, T, R, pfx_f3, Wn, LIG }, /* vcvtsi2sh */
     { { 0x2c }, 2, T, R, pfx_f3, Wn, LIG }, /* vcvttsh2si */
     { { 0x2d }, 2, T, R, pfx_f3, Wn, LIG }, /* vcvtsh2si */
@@ -2184,6 +2195,9 @@ static const struct evex {
     { { 0x6d }, 2, T, R, pfx_f2, Wn, LIG }, /* vcvttsd2sis */
     { { 0x6e }, 2, T, R, pfx_66, WIG, L0 }, /* vmovw */
     { { 0x6e }, 2, T, R, pfx_f3, W0, L0 }, /* vmovw */
+    { { 0x74 }, 2, T, R, pfx_no, W0, Ln }, /* vcvtbiasph2bf8s */
+    { { 0x74 }, 2, T, R, pfx_f3, W0, Ln }, /* vcvtneph2bf8s */
+    { { 0x74 }, 2, T, R, pfx_f2, W0, Ln }, /* vcvtne2ph2bf8s */
     { { 0x78 }, 2, T, R, pfx_no, W0, Ln }, /* vcvttph2udq */
     { { 0x78 }, 2, T, R, pfx_66, W0, Ln }, /* vcvttph2uqq */
     { { 0x78 }, 2, T, R, pfx_f3, Wn, LIG }, /* vcvttsh2usi */
--- a/xen/arch/x86/x86_emulate/decode.c
+++ b/xen/arch/x86/x86_emulate/decode.c
@@ -378,8 +378,10 @@ static const struct ext0f38_table {
     [0x62] = { .simd_size = simd_packed_int, .two_op = 1, .d8s = d8s_bw },
     [0x63] = { .simd_size = simd_packed_int, .to_mem = 1, .two_op = 1, .d8s = d8s_bw },
     [0x64 ... 0x66] = { .simd_size = simd_packed_int, .d8s = d8s_vl },
+    [0x67] = { .simd_size = simd_other, .d8s = d8s_vl },
     [0x68] = { .simd_size = simd_packed_int, .d8s = d8s_vl },
     [0x70 ... 0x73] = { .simd_size = simd_packed_int, .d8s = d8s_vl },
+    [0x74] = { .simd_size = simd_other, .d8s = d8s_vl },
     [0x75 ... 0x76] = { .simd_size = simd_packed_int, .d8s = d8s_vl },
     [0x77] = { .simd_size = simd_packed_fp, .d8s = d8s_vl },
     [0x78] = { .simd_size = simd_other, .two_op = 1 },
@@ -1445,6 +1447,15 @@ int x86emul_decode(struct x86_emulate_st
             s->simd_size = ext0f38_table[b].simd_size;
             if ( evex_encoded() )
             {
+                switch ( b )
+                {
+                case 0x74: /* cvt{bias,ne,ne2}ph2bf8 */
+                    s->fp16 = true;
+                    if ( s->evex.pfx != vex_f2 )
+                        d |= TwoOp;
+                    break;
+                }
+
                 /*
                  * VPMOVUS* are identical to VPMOVS* Disp8-scaling-wise, but
                  * their attributes don't match those of the vex_66 encoded
@@ -1592,6 +1603,23 @@ int x86emul_decode(struct x86_emulate_st
 
             switch ( b )
             {
+            case 0x18: /* vcvt{bias,ne,ne2}ph2hf8 */
+            case 0x1b: /* vcvt{bias,ne,ne2}ph2hf8s */
+            case 0x74: /* vcvt{bias,ne,ne2}ph2bf8s */
+                s->fp16 = true;
+                d = DstReg | SrcMem;
+                if ( s->evex.pfx != vex_f2 )
+                    d |= TwoOp;
+                s->simd_size = simd_other;
+                disp8scale = s->evex.brs ? 1 : 4 + s->evex.lr;
+                break;
+
+            case 0x1e: /* vcvthf82ph */
+                d = DstReg | SrcMem | TwoOp;
+                s->simd_size = simd_other;
+                disp8scale = 3 + s->evex.lr;
+                break;
+
             case 0x78:
             case 0x79:
                 /* vcvt{,t}ph2u{d,q}q need special casing */
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -6269,6 +6269,29 @@ x86_emulate(
         }
         goto simd_zmm;
 
+    case X86EMUL_OPC_EVEX   (0x0f38, 0x74): /* vcvtbiasph2bf8 [xyz]mm,[xyz]mm/mem{k} */
+    case X86EMUL_OPC_EVEX_F3(0x0f38, 0x74): /* vcvtneph2bf8 [xyz]mm,[xyz]mm/mem{k} */
+    case X86EMUL_OPC_EVEX_F2(0x0f38, 0x74): /* vcvtne2ph2bf8 [xyz]mm,[xyz]mm,[xyz]mm/mem{k} */
+    case X86EMUL_OPC_EVEX   (     5, 0x18): /* vcvtbiasph2hf8 [xyz]mm,[xyz]mm/mem{k} */
+    case X86EMUL_OPC_EVEX_F3(     5, 0x18): /* vcvtneph2hf8 [xyz]mm,[xyz]mm/mem{k} */
+    case X86EMUL_OPC_EVEX_F2(     5, 0x18): /* vcvtne2ph2hf8 [xyz]mm,[xyz]mm,[xyz]mm/mem{k} */
+    case X86EMUL_OPC_EVEX   (     5, 0x1b): /* vcvtbiasph2hf8s [xyz]mm,[xyz]mm/mem{k} */
+    case X86EMUL_OPC_EVEX_F3(     5, 0x1b): /* vcvtneph2hf8s [xyz]mm,[xyz]mm/mem{k} */
+    case X86EMUL_OPC_EVEX_F2(     5, 0x1b): /* vcvtne2ph2hf8s [xyz]mm,[xyz]mm,[xyz]mm/mem{k} */
+    case X86EMUL_OPC_EVEX   (     5, 0x74): /* vcvtbiasph2bf8s [xyz]mm,[xyz]mm/mem{k} */
+    case X86EMUL_OPC_EVEX_F3(     5, 0x74): /* vcvtneph2bf8s [xyz]mm,[xyz]mm/mem{k} */
+    case X86EMUL_OPC_EVEX_F2(     5, 0x74): /* vcvtne2ph2bf8s [xyz]mm,[xyz]mm,[xyz]mm/mem{k} */
+        generate_exception_if(ea.type != OP_MEM && evex.brs, X86_EXC_UD);
+        /* fall through */
+    case X86EMUL_OPC_EVEX_66(0x0f38, 0x67): /* vcvt2ps2phx [xyz]mm,[xyz]mm,[xyz]mm/mem{k} */
+        generate_exception_if(evex.w, X86_EXC_UD);
+        vcpu_must_have(avx10, 2);
+        if ( ea.type != OP_REG || !evex.brs )
+            avx512_vlen_check(false);
+        op_bytes = 16 << evex.lr;
+        fault_suppression = false;
+        goto simd_zmm;
+
     case X86EMUL_OPC_EVEX_F2(0x0f38, 0x68): /* vp2intersect{d,q} [xyz]mm/mem,[xyz]mm,k+1 */
         host_and_vcpu_must_have(avx512_vp2intersect);
         generate_exception_if(evex.opmsk || !evex.r || !evex.R, X86_EXC_UD);
@@ -7965,6 +7988,14 @@ x86_emulate(
         generate_exception_if(evex.w, X86_EXC_UD);
         goto avx512f_all_fp;
 
+    case X86EMUL_OPC_EVEX_F2(5, 0x1e): /* vcvthf82ph [xyz]mm,[xyz]mm/mem{k} */
+        generate_exception_if(evex.w || evex.brs, X86_EXC_UD);
+        vcpu_must_have(avx10, 2);
+        if ( ea.type != OP_REG || !evex.brs )
+            avx512_vlen_check(false);
+        op_bytes = 8 << evex.lr;
+        goto simd_zmm;
+
     case X86EMUL_OPC_EVEX_66(5, 0x42): /* vgetexppbf16 [xyz]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(5, 0x51): /* vsqrtnepbf16 [xyz]mm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(5, 0x58): /* vaddnepbf16 [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:33:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:33:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854497.1267686 (Exim 4.92)
	(envelope-from )
	id 1tLK1w-00017x-RM; Wed, 11 Dec 2024 10:33:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854497.1267686; Wed, 11 Dec 2024 10:33:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLK1w-00017q-Nd; Wed, 11 Dec 2024 10:33:20 +0000
Received: by outflank-mailman (input) for mailman id 854497;
 Wed, 11 Dec 2024 10:33: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 1tLJpV-00076S-TC
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:20:30 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 881658d2-b7a9-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 11:20:23 +0100 (CET)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-385deda28b3so4861984f8f.0
 for ; Wed, 11 Dec 2024 02:20: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
 d9443c01a7336-21654207719sm46391835ad.48.2024.12.11.02.20.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:20: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: 881658d2-b7a9-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733912427; x=1734517227; 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=Qs9XBOYAp6IPbLweUtrtvMK28FTozTB4amhvJ+Ev7XE=;
        b=EFy3BIdPkxdw2hPS9QoXek5Gke1/idor5PwcfdtIpmtbpwAmcHlmwxbkKNTH3XJNrH
         q3wkLOJe4fWL4daEyFAaeQUTz+T4xQcMjtMm/etm/0T2xCSDLiuzg2CLJnoCrojeQmOr
         kBqMdvF6uNGwJAL5R/4ysnPkKgg1NnhnK0hF6SVpznM0sRVcUGnvDUtWiESZkz8B2ANn
         BivG7mEmb/vyUNLXOZrST84BpW8HaF2can0herkk4JLwrrs+tC6DY38VLYM2R3fg+rbZ
         JOZUckDyaI5DTDB1c+8nYccS3yD5u+iswYiGOpW3C24aDIbRT/BNdni8dTJd1MsCuSSz
         ODSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733912427; x=1734517227;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Qs9XBOYAp6IPbLweUtrtvMK28FTozTB4amhvJ+Ev7XE=;
        b=p5hef0F3Aoe1TXczAnn0XohVkLVVSpUpNioWpfc3oJsFXcUGPVYpjAwkupcMspQ9B4
         5U/rNSVUXwBLQQoXpO3iPWY/ojSoCJ3DWHQGMXijREbSJ5aWCYjowCRCb0Kqx9g2AoXR
         mtspx+xOiMQrLvPz8vpLyP3BYi+PIfxs1fYXIzbdGnwJ6TkDelZueu0Ib1SofVUz6ljw
         3eZvRPJlfx6H+xFHsPPy3jPe1NcetgLldGnJuSd7JxRKjgpNL9QgyuRJyZcRYoRMGiC/
         yreA3mXLvxzAuv6CJhpHQ+XIvZ/h/dwB2+ChjM0yLKpIgql826WHKN5i1kCyYCMqfUnY
         hpGQ==
X-Gm-Message-State: AOJu0YwFipWu+uEYs3JAJ76zmkG0ueIJZROZWsWH0YcxmxvhxOI4reqj
	0/JQTOi0pomkbwH0mCxTsmUuecuyXHBULHa7sv4dXenYkgTibpoa4OOWXipE859ub2++y1QUipM
	=
X-Gm-Gg: ASbGncu5lD8caThvxmdV7uQjhFQ3GntpqI9LFXUhKuHisS3efZB4qXSSOi0y/AX0wdu
	JCAxMgewNUVZJwAIgEBtTzgnCvqhgcvMSwuiNifs3EQdhx0lo5+NUWaUNHTzVE84C3yEUrM+ro7
	i9D4SUypvTL5FPbOVy28jM7SiT975++a/XOwEG7yeoJJCCa+C5hGp025MBokhqP5fpQv6eFj0PU
	J4CJr2isKkmN7E08vVMaV/N6NA0iiVvPHOiUnlWD3ehB/MAc2/O111+F/W1rDpxHIJfkkP4BGba
	GxnhhIF4Gj53M0yFT7roj2mDK21U2fs2GkCXNvw=
X-Google-Smtp-Source: AGHT+IHAgKRVLhZdPu84qjCA+WUGRppKHkhPCiergvw2aQApDglRU+3P8PqJnD8kte/0JD8RAwKvCg==
X-Received: by 2002:a05:6000:144f:b0:385:f60b:f5c4 with SMTP id ffacd0b85a97d-3864cea3ca5mr1737545f8f.29.1733912427525;
        Wed, 11 Dec 2024 02:20:27 -0800 (PST)
Message-ID: <9ea8d2d5-632a-465c-852f-47b0feeda69b@suse.com>
Date: Wed, 11 Dec 2024 11:20:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v3 13/16] x86emul: support AVX10.2 saturating convert insns
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@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: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

While the to-byte ones are somewhat different from what has been there
(yet then nicely regular from an operands perspective), the others are
pretty similar to various existing insns.

Signed-off-by: Jan Beulich 
---
Spec rev 002 says VCVTTNEBF162I{,U}BS, yet that's going to change to
VCVTTBF162I{,U}BS.
---
SDE: ???
---
v3: New.

--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -719,6 +719,30 @@ static const struct test avx10_2_all[] =
     INSN(comxsd,           f3,   0f, 2f,    el,    q, el),
     INSN(comxsh,           f2, map5, 2f,    el, fp16, el),
     INSN(comxss,           f2,   0f, 2f,    el,    d, el),
+    INSN(cvtnebf162ibs,    f2, map5, 69,    vl, bf16, vl),
+    INSN(cvtnebf162iubs,   f2, map5, 6b,    vl, bf16, vl),
+    INSN(cvtph2ibs,          , map5, 69,    vl, fp16, vl),
+    INSN(cvtph2iubs,         , map5, 6b,    vl, fp16, vl),
+    INSN(cvtps2ibs,        66, map5, 69,    vl,    d, vl),
+    INSN(cvtps2iubs,       66, map5, 6b,    vl,    d, vl),
+    INSN(cvttbf162ibs,     f2, map5, 68,    vl, bf16, vl),
+    INSN(cvttbf162iubs,    f2, map5, 6a,    vl, bf16, vl),
+    INSN(cvttpd2dqs,         , map5, 6d,    vl,    q, vl),
+    INSN(cvttpd2qqs,       66, map5, 6d,    vl,    q, vl),
+    INSN(cvttpd2udqs,        , map5, 6c,    vl,    q, vl),
+    INSN(cvttpd2uqqs,      66, map5, 6c,    vl,    q, vl),
+    INSN(cvttph2ibs,         , map5, 68,    vl, fp16, vl),
+    INSN(cvttph2iubs,        , map5, 6a,    vl, fp16, vl),
+    INSN(cvttps2dqs,         , map5, 6d,    vl,    d, vl),
+    INSN(cvttps2ibs,       66, map5, 68,    vl,    d, vl),
+    INSN(cvttps2iubs,      66, map5, 6a,    vl,    d, vl),
+    INSN(cvttps2qqs,       66, map5, 6d,  vl_2,    d, vl),
+    INSN(cvttps2udqs,        , map5, 6c,    vl,    d, vl),
+    INSN(cvttps2uqqs,      66, map5, 6c,  vl_2,    d, vl),
+    INSN(cvttsd2sis,       f2, map5, 6d,    el,    q, el),
+    INSN(cvttsd2usis,      f2, map5, 6c,    el,    q, el),
+    INSN(cvttss2sis,       f3, map5, 6d,    el,    d, el),
+    INSN(cvttss2usis,      f3, map5, 6c,    el,    d, el),
     INSN(divnepbf16,       66, map5, 5e,    vl, bf16, vl),
     INSN(dpphps,             , 0f38, 52,    vl,    d, vl),
     INSN(fmadd132nepbf16,    , map6, 98,    vl, bf16, vl),
--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -2162,6 +2162,26 @@ static const struct evex {
     { { 0x5f }, 2, T, R, pfx_no, W0, Ln }, /* vmaxph */
     { { 0x5f }, 2, T, R, pfx_66, W0, Ln }, /* vmaxpbf16 */
     { { 0x5f }, 2, T, R, pfx_f3, W0, LIG }, /* vmaxsh */
+    { { 0x68 }, 2, T, R, pfx_no, W0, Ln }, /* vcvttph2ibs */
+    { { 0x68 }, 2, T, R, pfx_66, W0, Ln }, /* vcvttps2ibs */
+    { { 0x68 }, 2, T, R, pfx_f2, W0, Ln }, /* vcvttbf162ibs */
+    { { 0x69 }, 2, T, R, pfx_no, W0, Ln }, /* vcvtph2ibs */
+    { { 0x69 }, 2, T, R, pfx_66, W0, Ln }, /* vcvtps2ibs */
+    { { 0x69 }, 2, T, R, pfx_f2, W0, Ln }, /* vcvtnebf162ibs */
+    { { 0x6a }, 2, T, R, pfx_no, W0, Ln }, /* vcvttph2iubs */
+    { { 0x6a }, 2, T, R, pfx_66, W0, Ln }, /* vcvttps2iubs */
+    { { 0x6a }, 2, T, R, pfx_f2, W0, Ln }, /* vcvttbf162iubs */
+    { { 0x6b }, 2, T, R, pfx_no, W0, Ln }, /* vcvtph2iubs */
+    { { 0x6b }, 2, T, R, pfx_66, W0, Ln }, /* vcvtps2iubs */
+    { { 0x6b }, 2, T, R, pfx_f2, W0, Ln }, /* vcvtnebf162iubs */
+    { { 0x6c }, 2, T, R, pfx_no, Wn, Ln }, /* vcvttp{s,d}2udqs */
+    { { 0x6c }, 2, T, R, pfx_66, Wn, Ln }, /* vcvttp{s,d}2uqqs */
+    { { 0x6c }, 2, T, R, pfx_f3, Wn, LIG }, /* vcvttss2usis */
+    { { 0x6c }, 2, T, R, pfx_f2, Wn, LIG }, /* vcvttsd2usis */
+    { { 0x6d }, 2, T, R, pfx_no, Wn, Ln }, /* vcvttp{s,d}2dqs */
+    { { 0x6d }, 2, T, R, pfx_66, Wn, Ln }, /* vcvttp{s,d}2qqs */
+    { { 0x6d }, 2, T, R, pfx_f3, Wn, LIG }, /* vcvttss2sis */
+    { { 0x6d }, 2, T, R, pfx_f2, Wn, LIG }, /* vcvttsd2sis */
     { { 0x6e }, 2, T, R, pfx_66, WIG, L0 }, /* vmovw */
     { { 0x6e }, 2, T, R, pfx_f3, W0, L0 }, /* vmovw */
     { { 0x78 }, 2, T, R, pfx_no, W0, Ln }, /* vcvttph2udq */
--- a/xen/arch/x86/x86_emulate/decode.c
+++ b/xen/arch/x86/x86_emulate/decode.c
@@ -1547,6 +1547,19 @@ int x86emul_decode(struct x86_emulate_st
                     s->fp16 = true;
                 break;
 
+            case 0x68: /* vcvtt{ph,ps,bf16}2ibs */
+            case 0x69: /* vcvt{ph,ps,nebf16}2ibs */
+            case 0x6a: /* vcvtt{ph,ps,bf16}2iubs */
+            case 0x6b: /* vcvt{ph,ps,nebf16}2iubs */
+                if ( !s->evex.pfx || s->evex.pfx == vex_f2 )
+                    s->fp16 = true;
+                /* fall through */
+            case 0x6c: /* vcvttp{s,d}2u{d,q}qs, vcvtts{s,d}2usis */
+            case 0x6d: /* vcvttp{s,d}2{d,q}qs, vcvtts{s,d}2sis */
+                d |= TwoOp;
+                s->simd_size = simd_other;
+                break;
+
             case 0x6e: /* vmovw r/x/m16, xmm */
                 d = (d & ~SrcMask) | SrcMem16;
                 /* fall through */
@@ -1612,6 +1625,14 @@ int x86emul_decode(struct x86_emulate_st
                     --disp8scale;
                 break;
 
+            case 0x6c: /* vcvttps2uqqs and vcvts{s,d}2usi need special casing */
+            case 0x6d: /* vcvttps2qqs and vcvts{s,d}2si need special casing */
+                if ( s->evex.pfx == vex_66 && !s->evex.w && !s->evex.brs )
+                    --disp8scale;
+                else if ( s->evex.pfx & VEX_PREFIX_SCALAR_MASK )
+                    disp8scale = s->evex.pfx & VEX_PREFIX_DOUBLE_MASK ? 3 : 2;
+                break;
+
             case 0x7a: case 0x7b: /* vcvt{,t}ph2qq need special casing */
                 if ( s->evex.pfx == vex_66 && !s->evex.brs )
                     disp8scale = s->evex.brs ? 1 : 2 + s->evex.lr;
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -8025,6 +8025,55 @@ x86_emulate(
         op_bytes = 8 << evex.lr;
         goto simd_zmm;
 
+    case X86EMUL_OPC_EVEX_F2(5, 0x68): /* vcvttbf162ibs [xyz]mm/mem,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_F2(5, 0x69): /* vcvtnebf162ibs [xyz]mm/mem,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_F2(5, 0x6a): /* vcvttbf162iubs [xyz]mm/mem,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_F2(5, 0x6b): /* vcvtnebf162iubs [xyz]mm/mem,[xyz]mm{k} */
+        generate_exception_if(ea.type != OP_MEM && evex.brs, X86_EXC_UD);
+        /* fall through */
+    case X86EMUL_OPC_EVEX   (5, 0x68): /* vcvttph2ibs [xyz]mm/mem,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_66(5, 0x68): /* vcvttps2ibs [xyz]mm/mem,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX   (5, 0x69): /* vcvtph2ibs [xyz]mm/mem,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_66(5, 0x69): /* vcvtps2ibs [xyz]mm/mem,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX   (5, 0x6a): /* vcvttph2iubs [xyz]mm/mem,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_66(5, 0x6a): /* vcvttps2iubs [xyz]mm/mem,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX   (5, 0x6b): /* vcvtph2iubs [xyz]mm/mem,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX_66(5, 0x6b): /* vcvtps2iubs [xyz]mm/mem,[xyz]mm{k} */
+        generate_exception_if(evex.w, X86_EXC_UD);
+        vcpu_must_have(avx10, 2);
+        if ( ea.type != OP_REG || !evex.brs )
+            avx512_vlen_check(false);
+        op_bytes = 16 << evex.lr;
+        goto simd_zmm;
+
+    case X86EMUL_OPC_EVEX   (5, 0x6c): /* vcvttps2udqs [xyz]mm/mem,[xyz]mm{k} */
+                                       /* vcvttpd2udqs [xyz]mm/mem,{x,y}mm{k} */
+    case X86EMUL_OPC_EVEX_66(5, 0x6c): /* vcvttps2uqqs {x,y}mm/mem,[xyz]mm{k} */
+                                       /* vcvttpd2uqqs [xyz]mm/mem,[xyz]mm{k} */
+    case X86EMUL_OPC_EVEX   (5, 0x6d): /* vcvttps2dqs [xyz]mm/mem,[xyz]mm{k} */
+                                       /* vcvttpd2dqs [xyz]mm/mem,{x,y}mm{k} */
+    case X86EMUL_OPC_EVEX_66(5, 0x6d): /* vcvttps2qqs {x,y}mm/mem,[xyz]mm{k} */
+                                       /* vcvttpd2qqs [xyz]mm/mem,[xyz]mm{k} */
+        vcpu_must_have(avx10, 2);
+        if ( ea.type != OP_REG || !evex.brs )
+            avx512_vlen_check(false);
+        op_bytes = 8 << ((evex.w || !evex.pfx) + evex.lr);
+        goto simd_zmm;
+
+    CASE_SIMD_SCALAR_FP(_EVEX, 5, 0x6c): /* vcvtts{s,d}2usis xmm/mem,reg */
+    CASE_SIMD_SCALAR_FP(_EVEX, 5, 0x6d): /* vcvtts{s,d}2sis xmm/mem,reg */
+        generate_exception_if((evex.reg != 0xf || !evex.RX || !evex.R ||
+                               evex.opmsk),
+                              X86_EXC_UD);
+        vcpu_must_have(avx10, 2);
+        if ( !evex.brs )
+            avx512_vlen_check(true);
+        else
+            generate_exception_if(ea.type != OP_REG || !evex.u, X86_EXC_UD);
+        get_fpu(X86EMUL_FPU_zmm);
+        opc = init_evex(stub);
+        goto cvts_2si;
+
     case X86EMUL_OPC_EVEX_66(5, 0x78): /* vcvttph2uqq xmm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(5, 0x79): /* vcvtph2uqq xmm/mem,[xyz]mm{k} */
     case X86EMUL_OPC_EVEX_66(5, 0x7a): /* vcvttph2qq xmm/mem,[xyz]mm{k} */



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:33:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:33:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854508.1267695 (Exim 4.92)
	(envelope-from )
	id 1tLK2K-0001kZ-6i; Wed, 11 Dec 2024 10:33:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854508.1267695; Wed, 11 Dec 2024 10: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 1tLK2K-0001k1-3L; Wed, 11 Dec 2024 10:33:44 +0000
Received: by outflank-mailman (input) for mailman id 854508;
 Wed, 11 Dec 2024 10: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 1tLJr6-00024A-3C
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:22:08 +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 c5c4e683-b7a9-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 11:22:07 +0100 (CET)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-385e27c75f4so4774851f8f.2
 for ; Wed, 11 Dec 2024 02:22:07 -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
 41be03b00d2f7-7fd35331cf8sm7308250a12.44.2024.12.11.02.22.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:22:05 -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: c5c4e683-b7a9-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733912526; x=1734517326; 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=hO8Qikz+f0D+oVjxqRCd7QOvjmKJ9NgkZPKMop33tuo=;
        b=fKt9Oy2QezJGe/jtR8oZ32NVgN1yGkuUvcraO7rDdbDWNuVuFG0pE/PfArof6BMyAy
         WtADKRkc9Oa3+PUBPbpw4ZUx+jn3zRkodU2WJKrWkImc+OJnWssXgkkG7NmllXsJ4gq6
         bC0QrkKj78NSxxLX2QGTQLuSIAyt/pmUNn/6Uts3RR/R4KCkpFBmnAGZqDNIDYytwC8E
         PdpZUb6SIsfYigDiDVY65kwbWaB9w6Sqek5eK9TuNLWg3kvVUH54UGfTCEo+ji1DDjzB
         vB2mJ71ti/F/gTRdXMGOik8Nr3TRizsBvrPo5A8bXVv5/p6MuGwhGYi8mdDVw84dprim
         UIYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733912526; x=1734517326;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=hO8Qikz+f0D+oVjxqRCd7QOvjmKJ9NgkZPKMop33tuo=;
        b=Fr63OCGfCQovIra6UOOwAvtc4WLJv0AWPMmUyWODqVIfQR/lmcf7aB0sigkC8VQbCN
         59W2Pb1iXtoCxrqtgLK6ed00nqLJXLEypQcyAz2UOQaPXLmykHh1ZczRoJwA2TA4yMhZ
         fAVV2pqheQUzbWhXVxhm4+MUyKRy+Jpjmkk0p8FNMFeCRYp3+MDnNmSuQ/9v8cHa1dcD
         h4uqTi7QdbwmKGtVCfV/DryZaXiNn3Y7AjFivFwwGjWkAeisiTPI61d7UnwiiVJRhdLP
         e9LXxucc76PgNkAmYnRlKOBagx8qWDTiPkTHUFakLv/4YAp4ji855zRNRCxlmU3ECn4T
         mqJg==
X-Gm-Message-State: AOJu0YyLqi3NHR4gHuFqE6JcL1PGqO1/ITfFUPqLWa1ZdC6aTc9c1UNF
	1NloJQ4p67zEpNFSKMxOHgPM9qzMSfG79033w8oX4EyopfUq9PtxHZk5HuMuAvLtP3ccTptxRu8
	=
X-Gm-Gg: ASbGncvxXLF3xkPoxwPpyFRVYluUNXhEM+U4cbtkaSX8FPY6gsbnyctIs0UwLi8Qgos
	krZ/dpus3+IGCUXBAmlEVzLnIUsUrcU32X0WPQ+JyHO2VUYuciJY5W6ZtQkdxVQyn9bSTKwuoiy
	TeMqCofsxCs7c0nvcNe2jLL2waT737ypRTdFV6X13GzW92ll4e5511gWX90TTB2VAswjJCogJwH
	nz5rNFld+2tddd7SgaRh+odty8h20ntHtTqB8B8BSyo1I774H3sFTSqnfr/04dNPkkEURbWquGk
	xkGGXXDko2m+YRMCJarEZCCR9SzXJCw++MoGcys=
X-Google-Smtp-Source: AGHT+IEJfMcOa7CTrg2kHbvf5IWOAllNdNS6uSJAV6DeZb0RyD3Ak294+pH58jQrJQ1zlKlOi47rUw==
X-Received: by 2002:a5d:47a1:0:b0:386:3a8e:64c1 with SMTP id ffacd0b85a97d-3864ce90f89mr1695738f8f.19.1733912526329;
        Wed, 11 Dec 2024 02:22:06 -0800 (PST)
Message-ID: <9da1258a-86dd-46fb-9d38-95a2c2f3d902@suse.com>
Date: Wed, 11 Dec 2024 11:22:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PATCH v3 16/16] x86emul: support AVX10.2 forms of SM4 insns
From: Jan Beulich 
To: "xen-devel@lists.xenproject.org" 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@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: <516b7f9a-048e-409d-8a4e-89aeb8ffacc4@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Simply clone the VEX-encoded handling to cover the EVEX forms.

Signed-off-by: Jan Beulich 
---
There's a TODO left due to lack of SDE support. Invoking the test would
fail at present, for SDE 9.44.0 advertising both AVX10.2 and SM4, while
not supporting the new EVEX encodings just yet.
---
SDE: -???
---
v3: New.

--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -821,6 +821,11 @@ static const struct test movrs_all[] = {
     INSN(movrsw, f2, map5, 6f, vl,    w, vl),
 };
 
+static const struct test sm4_all[] = {
+    INSN(sm4key4,  f3, 0f38, da, vl, d_nb, vl),
+    INSN(sm4rnds4, f2, 0f38, da, vl, d_nb, vl),
+};
+
 static const unsigned char vl_all[] = { VL_512, VL_128, VL_256 };
 static const unsigned char vl_128[] = { VL_128 };
 static const unsigned char vl_no128[] = { VL_512, VL_256 };
@@ -1246,6 +1251,7 @@ void evex_disp8_test(void *instr, struct
     if ( cpu_has_avx10_2 )
     {
         run(ctxt->addr_size == 64 && cpu_has_movrs, movrs, all);
+        (void)sm4_all;//todo run(cpu_has_sm4, sm4, all);
     }
 
 #undef run
--- a/tools/tests/x86_emulator/predicates.c
+++ b/tools/tests/x86_emulator/predicates.c
@@ -2046,6 +2046,8 @@ static const struct evex {
     { { 0xd3 }, 2, T, R, pfx_no, W0, Ln }, /* vpdpwuuds */
     { { 0xd3 }, 2, T, R, pfx_66, W0, Ln }, /* vpdpwusds */
     { { 0xd3 }, 2, T, R, pfx_f3, W0, Ln }, /* vpdpwsuds */
+    { { 0xda }, 2, T, R, pfx_f3, W0, Ln }, /* vsm4key4 */
+    { { 0xda }, 2, T, R, pfx_f2, W0, Ln }, /* vsm4rnds4 */
     { { 0xdc }, 2, T, R, pfx_66, WIG, Ln }, /* vaesenc */
     { { 0xdd }, 2, T, R, pfx_66, WIG, Ln }, /* vaesenclast */
     { { 0xde }, 2, T, R, pfx_66, WIG, Ln }, /* vaesdec */
--- a/xen/arch/x86/x86_emulate/decode.c
+++ b/xen/arch/x86/x86_emulate/decode.c
@@ -439,7 +439,7 @@ static const struct ext0f38_table {
     [0xd3] = { .simd_size = simd_other, .d8s = d8s_vl },
     [0xd6] = { .simd_size = simd_other, .d8s = d8s_vl },
     [0xd7] = { .simd_size = simd_scalar_vexw, .d8s = d8s_dq },
-    [0xda] = { .simd_size = simd_other },
+    [0xda] = { .simd_size = simd_other, .d8s = d8s_vl },
     [0xdb] = { .simd_size = simd_packed_int, .two_op = 1 },
     [0xdc ... 0xdf] = { .simd_size = simd_packed_int, .d8s = d8s_vl },
     [0xe0 ... 0xef] = { .to_mem = 1 },
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -6928,6 +6928,14 @@ x86_emulate(
         op_bytes = 16 << vex.l;
         goto simd_0f_ymm;
 
+    case X86EMUL_OPC_EVEX_F3(0x0f38, 0xda): /* vsm4key4 [xyz]mm/mem,[xyz]mm,[xyz]mm */
+    case X86EMUL_OPC_EVEX_F2(0x0f38, 0xda): /* vsm4rnds4 [xyz]mm/mem,[xyz]mm,[xyz]mm */
+        vcpu_must_have(avx10, 2);
+        host_and_vcpu_must_have(sm4);
+        generate_exception_if(evex.w || evex.brs || evex.opmsk, X86_EXC_UD);
+        op_bytes = 16 << evex.lr;
+        goto simd_zmm;
+
     case X86EMUL_OPC_VEX_66(0x0f38, 0xdc):  /* vaesenc {x,y}mm/mem,{x,y}mm,{x,y}mm */
     case X86EMUL_OPC_VEX_66(0x0f38, 0xdd):  /* vaesenclast {x,y}mm/mem,{x,y}mm,{x,y}mm */
     case X86EMUL_OPC_VEX_66(0x0f38, 0xde):  /* vaesdec {x,y}mm/mem,{x,y}mm,{x,y}mm */



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 10:34:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 10:34:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854514.1267706 (Exim 4.92)
	(envelope-from )
	id 1tLK2c-0002Hi-Ey; Wed, 11 Dec 2024 10:34:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854514.1267706; Wed, 11 Dec 2024 10:34: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 1tLK2c-0002HY-B7; Wed, 11 Dec 2024 10:34:02 +0000
Received: by outflank-mailman (input) for mailman id 854514;
 Wed, 11 Dec 2024 10:34: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 1tLK2b-0001aQ-0C
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 10:34:01 +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 6f01c5fd-b7ab-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 11:34:00 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-434ab114753so43533335e9.0
 for ; Wed, 11 Dec 2024 02:34: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
 41be03b00d2f7-7fd560985e0sm3804655a12.79.2024.12.11.02.33.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 02:33: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: 6f01c5fd-b7ab-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733913240; x=1734518040; 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=zTT2fI8Lh1KYGwkqJ4HYUDlHCdYmKmMDp5k482eZu/k=;
        b=Q8qxDWBcchuUbFo9zuJ6sZmq6LcXKzsPEeRDcd/J8Aohts7u+xeNrq7VYU3ZCVvNon
         jfNEqsYuKbSOxWBdeJdrywLuSsd5v7t0VWHu/TIH9TICz/Vnq5dzxtFrKI1WdSjRyHRh
         JD5TA/d+sfXUy5CL7Ic3qd3OQAZ0Rm51rU62uAibbRzB8tXNzs1lbCYW5i1UonyljEGp
         Mi+cpfYcOUD/Aiz6HVLaamypkSHf+0KiLfmHUfP2rHoQUTkxOgpaCLqpC/uvVtT4arrv
         Wn404rtqyIyiYyPFA6NrC5N7FeSscmmLycPMmozFpQNV7lEgptq12tvdnNRGJGH/DxUK
         Zceg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733913240; x=1734518040;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=zTT2fI8Lh1KYGwkqJ4HYUDlHCdYmKmMDp5k482eZu/k=;
        b=m+mHPFpLWQHdsul+Rd0NQ+yPptM1IatqdJUf+sNTCfCJdZ4FaqhuG1gwIi8KUrDWel
         ut2lQ3UGuad887OOQ6YyBXExZdlNG5TIX6D5UI4dDpuPPzZuPgRR4dSPj1C4tEOYZH87
         Zcl2iA752g0AvwIw2HLDh6DZOoH1F2QcszAx+HVlAz1UUOCAiSvkCp2cixK3wUCAe8X5
         4amtD3/09+vxyG1UsBax5Ufe1uAevWKv0BJli4/xO3wjrn2Pk9xil5YQbxZprYNdsc0o
         VUbOlW9dadaC948RoLt80YdIlEMWbypnmlaZ32KCENAlrjYB+EvUsICjZ7YHhdo7zrFE
         bRnQ==
X-Forwarded-Encrypted: i=1; AJvYcCWyuRRl9zm1EGHc2p2/myAn6GmzW63dWl2AA40+k+bdVIUoj7bvssEYVf3Y928pTZouPauqj6aWMKk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxA6iHM7Bhl3ZFUlPnlntvZJCY67HzxtwcWUXtqoeQ2Pwaw4iI5
	5VuO/4lINq9JcZ1CML3wwoKwbA0baWUHPWwFB1E86l6wcVZMWLQ8ceL7jD02TA==
X-Gm-Gg: ASbGncvTR0eI3NLXl+OqRfpG41vI9iSdXXKPZK/nVC8szk4jF3lkcIIVPs0Qg7oZdoJ
	lSb0a2AQu5v57ZYgSzqtH8ei4URZYKXJYFNylNs+OsntjsABT2qHk1jNrrfDIIPc72yt4ByRZ97
	fmE5ttEViMSHP9FRnCrA1luZFZ82BzAy4OmiuwKQnryY4+juMQViz8K9vr4rsku8+VPGx6OzaUq
	lsMxPmIIT0u9F3XTFhjsdT7ANHM3x9pKgdCx7qZn35w4wUbYZSafY0wKSfTEFj7XsJhsnzfTfc6
	8u+yvOiML/tu26lD52/+48jktsSY3DtaGy6XnUw=
X-Google-Smtp-Source: AGHT+IG3A3P+FFDPJp7dUdCzkWzaG63tsDLnhw5PjtLpyZVCAzHMyEiQJDqoxigCtW6HvY9ezR4IgA==
X-Received: by 2002:a05:6000:188f:b0:386:62f:cf18 with SMTP id ffacd0b85a97d-3864ce9faa0mr1331702f8f.49.1733913239569;
        Wed, 11 Dec 2024 02:33:59 -0800 (PST)
Message-ID: <9e05dcb0-ae71-4efe-9f1b-effa7a60cf9f@suse.com>
Date: Wed, 11 Dec 2024 11:33:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 5/6] xen/riscv: implement relocate_fdt()
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Andrew Cooper ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: 
 
 
 <4dd6a2e9-d2b9-4402-907b-b9314d2346f7@gmail.com>
 <929d657d-ffe8-4243-ba01-fffa20b26205@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.12.2024 11:26, Oleksii Kurochko wrote:
> On 12/10/24 5:20 PM, Jan Beulich wrote:
>>>> Also recall my comment on one of your earlier series, regarding inclusive
>>>> vs exclusive ranges. Can that please be sorted properly as a prereq, to
>>>> avoid extending the inconsistency?
>>> Yes, I remember that and at the moment everything ( DIRECTMAP_VIRT_END, FRAMETABLE_VIRT_END )
>>> is following "inclusive" way. Considering that you remind me that could you please tell me more time
>>> what I am missing?
>> First the table azt the top of config.h uses all exclusive upper bounds.
>> And then DIRECTMAP_SIZE's definition assumes DIRECTMAP_SLOT_END would be
>> exclusive, when it's inclusive.
> 
> Really missed to update the tale on the top of config.h.
> 
> But it seems to me like any *_SIZE will be defined in exclusive way by its nature, doesn't it?

Of course. I'm not even sure "size" can be reasonably qualified as "exclusive" or
"inclusive".

> For example, size of directmap is (509-200+1)<<30 = 0x7F80000000 and it is not really (
> 0x7F80000000 - 1 ) = 7F7FFFFFFF.
> 
> I prefer to have DIRECTMAP_{SIZE,VIRT_END} defined as now:
>    #define DIRECTMAP_SIZE          (SLOTN(DIRECTMAP_SLOT_END + 1) - SLOTN(DIRECTMAP_SLOT_START))
>    #define DIRECTMAP_VIRT_END      (DIRECTMAP_VIRT_START + DIRECTMAP_SIZE - 1)
> ( of course with making upper bounds inclusive in the table on the top of config.h )

Right.

>>>>> +        set_fixmap(FIX_MISC, maddr_to_mfn(paddr), PAGE_HYPERVISOR_RW);
>>>>> +        memcpy(dst, src + s, l);
>>>>> +        clean_dcache_va_range(dst, l);
>>>> Why is this necessary here? You're copying to plain RAM that Xen alone
>>>> is using.
>>> It is Arm specific:
>>> ```
>>> commit c60209d77e2c02de110ca0fdaa2582ef4e53d8fd
>>> Author: Stefano Stabellini
>>> Date:   Mon Jan 21 12:40:31 2013 +0000
>>>
>>>       xen/arm: flush dcache after memcpy'ing the kernel image
>>>       
>>>       After memcpy'ing the kernel in guest memory we need to flush the dcache
>>>       to make sure that the data actually reaches the memory before we start
>>>       executing guest code with caches disabled.
>>>       
>>>       copy_from_paddr is the function that does the copy, so add a
>>>       flush_xen_dcache_va_range there.
>>> ```
>>> I wanted to put copy_from_paddr() to some common place at the end but in RISC-V cache is always enabled
>>> ( I don't see an instruction in the spec for disable/enable cache ) so this issue isn't present for RISC-V
>>> and clean_dcache_va_range() should/could be dropped.
>> That plus there's no kernel in sight just yet.
> 
> ( clarification ) will it change something if kernel will be loaded now? It seems even if we are copying kernel in guest
> memory we still don't need to flush the dcache as cache is enabled and cache coherence protocol will do a work automatically.

Correct. My point merely was that there are two reasons this isn't needed, each
of which is by itself sufficient to justify omitting that call.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 11:02:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 11:02:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854547.1267724 (Exim 4.92)
	(envelope-from )
	id 1tLKTe-0000SR-J1; Wed, 11 Dec 2024 11:01:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854547.1267724; Wed, 11 Dec 2024 11:01: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 1tLKTe-0000SK-F7; Wed, 11 Dec 2024 11:01:58 +0000
Received: by outflank-mailman (input) for mailman id 854547;
 Wed, 11 Dec 2024 11:01: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 1tLKTd-0000SE-5m
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 11:01:57 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 55b592e0-b7af-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 12:01:55 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-aa68b513abcso566422166b.0
 for ; Wed, 11 Dec 2024 03:01:55 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa684773405sm471516466b.46.2024.12.11.03.01.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 03:01: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: 55b592e0-b7af-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733914915; x=1734519715; 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=Qkoaac2Af3nuHnWQBsYSkjmez2OYYRG9z9cf1RbQfYU=;
        b=FCAWK6qv9YyLmKgi3e6rSiYGCsUWSJXaBTItCLPcfrexMP13ETk4hkscwTWQjCUg2e
         frfL5Xd9zrTpu7m4WVcqZ7mJ0VGgYrZDfHHMI++QPXI7owIe781DlVHjX3yWjexJ2GbS
         gdVAQStfYLaJ0wJxYUVpXZnjZD1Y8TdQDLhUw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733914915; x=1734519715;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Qkoaac2Af3nuHnWQBsYSkjmez2OYYRG9z9cf1RbQfYU=;
        b=mC3SI+q7qINlWatKDtHYtcu14tRxso96WkTMO6noTRmi0N9PqeyqQkTg8WTr2VZy8q
         d6IqvnMkfgpoYLHLZDb85txHO6gi+yYR+emnU+DvRBKrjGFP6NsotUpwSIMLu/JSNk5e
         vQjTa5XTGbaC5ZHu88/nQK5sv5jePH9R6ovDTqOCbVm2b7bxeQGXfrWhg9tkWXRNbSdw
         gyXKDk73VKDP0qIMeXDCJn5AqBdqw9M576T3G32j6TZZNBdVkkT1BeUm6H6SlTR0WocN
         uzvMRHveUhz9yCU2HdHxdqGullI+5uHaMStPYIp8X31Bro5v1XugQjqLhOFCAf64IdDk
         ni7w==
X-Gm-Message-State: AOJu0YzSMUorXU+d6BRe+FE9WhHIq3c4Mrz7nQSd0glq8jVCg6NLYwjB
	ZPjUlXMTQFpGlki3raMNaK8h+rUgtzChAsUErj40NnlCwNoarFTzz9P7INcBAMI=
X-Gm-Gg: ASbGncukwBiY1bmAuKpi8kIeZodTAaeb+HORothPq2oyEYgNDWpdBeFE80UMkAjt8X3
	nttJXezz51xWorRi6XhlbG1UmzbSczRVX4MQV6W11XJ2/iC5drfKep2pMrJ/3N4QvGabtR5VcYa
	MQ2/CjsO4wJS1wMDSAT2gVaLY/W46wxKFANoUZ3jJInAV2AReiXnqPjhJ9AALsrKeMcDtx8MPbk
	KLk6LuaQ7A7Y3NVGL4yih9/xgvvPihJNVhsFMtniBKZsF4KHTaqMQd3ckvWrB0=
X-Google-Smtp-Source: AGHT+IHSfY9vvcBNZmgjC6Nnb02wOpLHre4CMeomt91OB9ohhRrMa1s5mm9Seo80LzOwfB+EScccGQ==
X-Received: by 2002:a17:906:23f2:b0:a9a:161:8da4 with SMTP id a640c23a62f3a-aa6b13e0eecmr227033166b.55.1733914915248;
        Wed, 11 Dec 2024 03:01:55 -0800 (PST)
Date: Wed, 11 Dec 2024 12:01:54 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 01/35] xen: introduce resource.h
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-1-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-1-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:41:31PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Move resource definitions to a new architecture-agnostic shared header file.
> 
> It will be used in follow on NS8250 emulator code to describe legacy
> PC COM resources.
> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/common/device-tree/device-tree.c | 21 +------------------
>  xen/drivers/passthrough/arm/smmu.c   | 15 +-------------
>  xen/include/xen/resource.h           | 40 ++++++++++++++++++++++++++++++++++++
>  3 files changed, 42 insertions(+), 34 deletions(-)
> 
> diff --git a/xen/common/device-tree/device-tree.c b/xen/common/device-tree/device-tree.c
> index d0528c5825651f7cc9ebca0c949229c9083063c6..e8f810b2fe10890c033ed3a9d4ca627010ad019b 100644
> --- a/xen/common/device-tree/device-tree.c
> +++ b/xen/common/device-tree/device-tree.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  const void *device_tree_flattened;
>  dt_irq_xlate_func dt_irq_xlate;
> @@ -535,26 +536,6 @@ int dt_child_n_size_cells(const struct dt_device_node *parent)
>      return __dt_n_size_cells(parent, true);
>  }
>  
> -/*
> - * These are defined in Linux where much of this code comes from, but
> - * are currently unused outside this file in the context of Xen.
> - */
> -#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
> -
> -#define IORESOURCE_TYPE_BITS    0x00001f00      /* Resource type */
> -#define IORESOURCE_IO           0x00000100      /* PCI/ISA I/O ports */
> -#define IORESOURCE_MEM          0x00000200
> -#define IORESOURCE_REG          0x00000300      /* Register offsets */
> -#define IORESOURCE_IRQ          0x00000400
> -#define IORESOURCE_DMA          0x00000800
> -#define IORESOURCE_BUS          0x00001000
> -
> -#define IORESOURCE_PREFETCH     0x00002000      /* No side effects */
> -#define IORESOURCE_READONLY     0x00004000
> -#define IORESOURCE_CACHEABLE    0x00008000
> -#define IORESOURCE_RANGELENGTH  0x00010000
> -#define IORESOURCE_SHADOWABLE   0x00020000
> -
>  /*
>   * Default translator (generic bus)
>   */
> diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c
> index 03d22bce1e497e41834c273f9048b98dcbd48a54..aa6a968b574dce7cc753e8070fad3a6e585cd9e7 100644
> --- a/xen/drivers/passthrough/arm/smmu.c
> +++ b/xen/drivers/passthrough/arm/smmu.c
> @@ -50,6 +50,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -70,22 +71,8 @@
>  #define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, out))
>  #define of_property_read_bool dt_property_read_bool
>  #define of_parse_phandle_with_args dt_parse_phandle_with_args
> -
> -/* Xen: Helpers to get device MMIO and IRQs */
> -struct resource
> -{
> -	paddr_t addr;
> -	paddr_t size;
> -	unsigned int type;
> -};
> -
> -#define resource_size(res) (res)->size;
> -
>  #define platform_device dt_device_node
>  
> -#define IORESOURCE_MEM 0
> -#define IORESOURCE_IRQ 1
> -
>  static struct resource *platform_get_resource(struct platform_device *pdev,
>  					      unsigned int type,
>  					      unsigned int num)
> diff --git a/xen/include/xen/resource.h b/xen/include/xen/resource.h
> new file mode 100644
> index 0000000000000000000000000000000000000000..4962e17da8387b7f324317482b19cc9fe71433fc
> --- /dev/null
> +++ b/xen/include/xen/resource.h
> @@ -0,0 +1,40 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * System resource description.
> + *
> + * Reference:
> + *   include/linux/ioport.h
> + */
> +#if !defined(XEN__RESOURCE_H)
> +#define XEN__RESOURCE_H
> +
> +#define IORESOURCE_BITS         0x000000FFU      /* Bus-specific bits */
> +
> +#define IORESOURCE_TYPE_BITS    0x00001F00U      /* Resource type */
> +#define IORESOURCE_IO           0x00000100U      /* PCI/ISA I/O ports */
> +#define IORESOURCE_MEM          0x00000200U
> +#define IORESOURCE_REG          0x00000300U      /* Register offsets */
> +#define IORESOURCE_IRQ          0x00000400U
> +#define IORESOURCE_DMA          0x00000800U
> +#define IORESOURCE_BUS          0x00001000U
> +
> +#define IORESOURCE_PREFETCH     0x00002000U      /* No side effects */
> +#define IORESOURCE_READONLY     0x00004000U
> +#define IORESOURCE_CACHEABLE    0x00008000U
> +#define IORESOURCE_RANGELENGTH  0x00010000U
> +#define IORESOURCE_SHADOWABLE   0x00020000U
> +
> +#define IORESOURCE_UNKNOWN      (~0U)
> +
> +struct resource {
> +    paddr_t addr;
> +    paddr_t size;
> +    unsigned int type;
> +};
> +
> +#define resource_size(res) (res)->size;
> +
> +#define foreach_resource(res) \

Nit: we usually name those for_each_foo instead of foreach_foo.

> +    for (; res && res->type != IORESOURCE_UNKNOWN; res++)

Missing spaces between parentheses:

for ( ; res && res->type != IORESOURCE_UNKNOWN; res++ )

Note that this macro will modify (advance) the res pointer, which is
maybe unexpected by the caller?

Also, the current logic forces the array of resources to always have a
trailing IORESOURCE_UNKNOWN element in order to break the loop, it
might be better to pass an explicit number of elements to iterate
against if possible?

As Jan said, it would be helpful to have an example usage of the
macro.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 11:03:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 11:03:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854557.1267734 (Exim 4.92)
	(envelope-from )
	id 1tLKUm-0001Cx-S0; Wed, 11 Dec 2024 11:03:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854557.1267734; Wed, 11 Dec 2024 11:03: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 1tLKUm-0001Cq-Nt; Wed, 11 Dec 2024 11:03:08 +0000
Received: by outflank-mailman (input) for mailman id 854557;
 Wed, 11 Dec 2024 11:03: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 1tLKUk-0001Ch-2u
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 11:03:06 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7ea22e79-b7af-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 12:03:04 +0100 (CET)
Received: from delta.homenet.telecomitalia.it
 (host-82-59-161-229.retail.telecomitalia.it [82.59.161.229])
 by support.bugseng.com (Postfix) with ESMTPSA id D00484EE073C;
 Wed, 11 Dec 2024 12:02:59 +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: 7ea22e79-b7af-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1733914983; bh=7j8r/F7MsJqKq9M3+20mKheIJOo4WeDF5Oz3cppvmFY=;
	h=From:To:Cc:Subject:Date:From;
	b=MmFo/hmj1kDRxuieH8lygwwdU2o9F5jUxbmC7UBpna4hcjCWqmVy45b+g6dyJ+Kts
	 3yUT3L8dWYezNKzUEZCXfQ4o+3ovA6IaQu+HJxims/39+K+J5a4iFv30c5TspoPrw8
	 sdwqnPkKuJjlez12kMKwjacdtdCBqhjMQX2u7gHQiIa5WkS4NDH/XZp7bRKby+coBK
	 eruqixTsuCV/gkHCcoMG5OcQGk1GorzClopYg8JQaZFjELg6r0MED8ggzDY/2k1D6r
	 1mPscwRz/frtAsS0phWnRGj2MQfdCrUaXTj//69VcYOGNC2cp20EPTp/hD1mwZw0YA
	 mKQ4TGf03kFvg==
From: Alessandro Zucchelli 
To: xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com,
	Alessandro Zucchelli ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] xen: address violation of MISRA C Rule 11.1
Date: Wed, 11 Dec 2024 12:02:48 +0100
Message-ID: <7debd63f3900bad62bcbcc03081e4c04e6099135.1733914487.git.alessandro.zucchelli@bugseng.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Rule 11.1 states as following: "Conversions shall not be performed
between a pointer to a function and any other type".

Functions "__machine_restart" and "__machine_halt" in "x86/shutdown.c"
and "halt_this_cpu" in "arm/shutdown.c" are defined as noreturn
functions and subsequently passed as parameters to function calls.
This violates the rule in Clang, where the "noreturn" attribute is
considered part of the function"s type. By removing the "noreturn"
attribbute and replacing it with uses of the ASSERT_UNREACHABLE macro,
these violations are addressed.

Signed-off-by: Alessandro Zucchelli 
---
 xen/arch/arm/shutdown.c | 3 ++-
 xen/arch/x86/shutdown.c | 7 +++++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/shutdown.c b/xen/arch/arm/shutdown.c
index c9778e5786..e679ae8d72 100644
--- a/xen/arch/arm/shutdown.c
+++ b/xen/arch/arm/shutdown.c
@@ -8,7 +8,7 @@
 #include 
 #include 
 
-static void noreturn halt_this_cpu(void *arg)
+static void halt_this_cpu(void *arg)
 {
     local_irq_disable();
     /* Make sure the write happens before we sleep forever */
@@ -38,6 +38,7 @@ void machine_halt(void)
     /* Alternative halt procedure */
     platform_poweroff();
     halt_this_cpu(NULL);
+    ASSERT_UNREACHABLE();
 }
 
 void machine_restart(unsigned int delay_millisecs)
diff --git a/xen/arch/x86/shutdown.c b/xen/arch/x86/shutdown.c
index 902076cf67..b684e19754 100644
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -118,7 +118,7 @@ static inline void kb_wait(void)
             break;
 }
 
-static void noreturn cf_check __machine_halt(void *unused)
+static void cf_check __machine_halt(void *unused)
 {
     local_irq_disable();
 
@@ -127,6 +127,7 @@ static void noreturn cf_check __machine_halt(void *unused)
 
     for ( ; ; )
         halt();
+    ASSERT_UNREACHABLE();
 }
 
 void machine_halt(void)
@@ -141,6 +142,7 @@ void machine_halt(void)
     }
 
     __machine_halt(NULL);
+    ASSERT_UNREACHABLE();
 }
 
 static void default_reboot_type(void)
@@ -520,9 +522,10 @@ static int __init cf_check reboot_init(void)
 }
 __initcall(reboot_init);
 
-static void cf_check noreturn __machine_restart(void *pdelay)
+static void cf_check __machine_restart(void *pdelay)
 {
     machine_restart(*(unsigned int *)pdelay);
+    ASSERT_UNREACHABLE();
 }
 
 void machine_restart(unsigned int delay_millisecs)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 11:05:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 11:05:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854572.1267743 (Exim 4.92)
	(envelope-from )
	id 1tLKXH-0001rf-AD; Wed, 11 Dec 2024 11:05:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854572.1267743; Wed, 11 Dec 2024 11:05: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 1tLKXH-0001rY-7Z; Wed, 11 Dec 2024 11:05:43 +0000
Received: by outflank-mailman (input) for mailman id 854572;
 Wed, 11 Dec 2024 11:05: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 1tLKXG-0001rS-Ai
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 11:05:42 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d8c71119-b7af-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 12:05:35 +0100 (CET)
Received: from delta.homenet.telecomitalia.it
 (host-82-59-161-229.retail.telecomitalia.it [82.59.161.229])
 by support.bugseng.com (Postfix) with ESMTPSA id EC8894EE073C;
 Wed, 11 Dec 2024 12:05:37 +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: d8c71119-b7af-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1733915140; bh=wC1Aqf8BmRMuPcItSpajMDm16p7p3y9cXkXxpzBiXb8=;
	h=From:To:Cc:Subject:Date:From;
	b=UPepWeu0m+YZOoIkElhcQJtmaZTv0b+ceOJm8GfXRT5aYk6qRcWkpGXlYwE7pMlB3
	 bMIca0SpMChJrsRBubNrujQb3DDGFff2AyszPoeXfCyiajWtUlzERvKqJiMTfdlqfU
	 kahtfVxQnoQXv1FuSSxeAdgsEbIrZKAJc0rirz1pcur4ptvRPvz0XFr4m0KbUdKcsH
	 d6EQRCBSFUex0HySXIFdo0SCNxb4YJt+X+nsuPODKOPDFduBp31Ot0z826fRogEEyK
	 1sCtxtamwLio71S/iqSkbv2R1LQXBx9Lvht9Hjlt4x75osfsfpV+1BMdAdIhLcuDDb
	 WFBLuBuQCu+AA==
From: Alessandro Zucchelli 
To: xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com,
	Alessandro Zucchelli ,
	Andrew Cooper ,
	Jan Beulich ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [PATCH] misra: add deviation for MISRA C Rule R11.1.
Date: Wed, 11 Dec 2024 12:05:30 +0100
Message-ID: <8db58416ce215a3c5fdba8074dc21f32116e8a41.1733915076.git.alessandro.zucchelli@bugseng.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Rule 11.1 states as following: "Conversions shall not be performed
between a pointer to a function and any other type".

In "xen/common/bug.c", in order to get additional debug information,
pointer "bug_fn_t *fn" in the data section is converted to a function
pointer, which is then used to get such information. This specific
conversion has been reviewed and found to have no undefined behaviour
associated to it, therefore it can be exempted from compliance.

Signed-off-by: Alessandro Zucchelli 
---
As this patch introduces a deviation for service MC3A2.R11.1, it
depends on the following patch and shall not be applied prior to its
application.
https://lore.kernel.org/xen-devel/cf13be4779f15620e94b99b3b91f9cb040319989.1733826952.git.alessandro.zucchelli@bugseng.com/T/#u
---
 docs/misra/safe.json | 8 ++++++++
 xen/common/bug.c     | 1 +
 2 files changed, 9 insertions(+)

diff --git a/docs/misra/safe.json b/docs/misra/safe.json
index 684346386e..d80fb3a48f 100644
--- a/docs/misra/safe.json
+++ b/docs/misra/safe.json
@@ -92,6 +92,14 @@
         },
         {
             "id": "SAF-11-safe",
+            "analyser": {
+                "eclair": "MC3A2.R11.1"
+            },
+            "name": "Rule 11.1: conversion for debugging purposes",
+            "text": "conversion of selected pointers to function pointers for debugging purposes are safe."
+        },
+        {
+            "id": "SAF-12-safe",
             "analyser": {},
             "name": "Sentinel",
             "text": "Next ID to be used"
diff --git a/xen/common/bug.c b/xen/common/bug.c
index 75cb35fcfa..2d08bb3d41 100644
--- a/xen/common/bug.c
+++ b/xen/common/bug.c
@@ -44,6 +44,7 @@ int do_bug_frame(const struct cpu_user_regs *regs, unsigned long pc)
 
     if ( id == BUGFRAME_run_fn )
     {
+        /* SAF-11-safe conversion for debugging purposes */
         bug_fn_t *fn = bug_ptr(bug);
 
         fn(regs);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 11:06:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 11:06:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854586.1267754 (Exim 4.92)
	(envelope-from )
	id 1tLKYC-0002OC-JJ; Wed, 11 Dec 2024 11:06:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854586.1267754; Wed, 11 Dec 2024 11:06: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 1tLKYC-0002O5-GH; Wed, 11 Dec 2024 11:06:40 +0000
Received: by outflank-mailman (input) for mailman id 854586;
 Wed, 11 Dec 2024 11:06: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 1tLKYB-0002FC-KM
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 11:06:39 +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 fe8034e4-b7af-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 12:06:39 +0100 (CET)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-385e0e224cbso3341992f8f.2
 for ; Wed, 11 Dec 2024 03:06: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
 98e67ed59e1d1-2ef7ad1293fsm8215969a91.34.2024.12.11.03.06.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 03:06: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: fe8034e4-b7af-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733915198; x=1734519998; 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=FVwGXCYqnGM2KQQ89YrkC8wzN7koOMttXNKxKa5aFa0=;
        b=ZzrTWSyGA8k5OfEI0rH4xBsLBbasM3POTMlGbLYKap3gdKDrIXoM5AbrXwCBPWjOXS
         yCWutNWp8s0uoHbDBQDIF+WUyL89KLoZz5dinPGLgLsX26/Ox1DDSx8/1t1yxNn8hXOT
         LeMk4pBo4nmpoFbBVanJgvfE78b4TKQAc4Z7jTttGKmG40xd/4a4HK8EwdA3SJ9eR/VS
         TiWSJgjd46LYnKG8h9MtpOVhoG50jIRySWZMTks0K7QckFChzrbgr3KPiEU+BRfEK/EA
         If91t5153auFCNUTfDQQWnA/XVc2G94zHA4wD42lFlUVKJ8Nkgbld1tO7sYAwj2tq6EK
         xwTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733915198; x=1734519998;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=FVwGXCYqnGM2KQQ89YrkC8wzN7koOMttXNKxKa5aFa0=;
        b=J371zh8PIfory2xw+j0bVzlmn7IRfMZOQTZk277+R9k8WgifM6trrpdiYFccCRubYX
         Gl5Fs1+Sy8DkF6AMxB5SeRdYS5avF+baWUux+/slN2NAYgigmA5iBn+Uyy22+hqaE0Dj
         1cJtXfGwZgSQOpUrGlQpev0rChYyFyjZ3IgUyg7fPj2SsxK0sCol+D1bNTDF6XwmmoWU
         OmHDx3ZVv8IqBJVLWAMjWT+xOs7H0xP0z1U5DehA4Gfsp8mDHUsjqCdFRMhnkuFnxEHk
         4GKd7EtSNzxlr+xvyvDKtoCVXmB/J+AAcNpaycM/xuiCuNdO7J10UdntdBVL5TkU2f7h
         D6ig==
X-Forwarded-Encrypted: i=1; AJvYcCV46yTrZWbNCu53sqrA+M3iwOXi0NofqTLO2FgCJf2V5fTpSdmWZ2kYIZ1OlcvQwTDlbb2wP49tAcw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzFXwPuYgdp4XDRuNuJoe5AuhRegLZ4vPDVqzgZUBKYHINWsH8E
	Vn9geDtCIviBlZoH+3fFyqYvO3hP9e8YNAUq91n2IDUP2TNkKYI/hMRV5w7VHQ==
X-Gm-Gg: ASbGncs/MIlXnNe8L8dRy2UIw/pmGvZ1OE2kDFvn657hhM+zVoIN98cozpjGwvRJ+Br
	xs8wqSlYLSKymKCXami7ApE0rFpQXZnOzM9QrRwMgJfzyeKDAEcaW0+VmLfFrn3UD1u97ru2eCI
	QQEkHee9vP6WFbxW7FUpOg+WX9g6ra8cPN+/gH13IcTA223zL7noeC25DbZYJuMsoj09bx8P6eZ
	EIORDLvD8xwKmqSxZ65AZ4XgWGHuXpKtQHh5e0NMsXKvaXL3AXv80GppQWIzeVftqS5tL5roq7L
	JXHIKT2TOx7vwM/OGDT4Ne3yCOpiLD1jvv/eG4M=
X-Google-Smtp-Source: AGHT+IFo2h5iCBNMatHzi43MTB9SpwrqCPAQGJSUAmvyLhBVco2wnV3x/O/n7wj2BfhgDtD10oV1PQ==
X-Received: by 2002:a5d:64c2:0:b0:385:decf:52bc with SMTP id ffacd0b85a97d-3864ce606b1mr1667407f8f.32.1733915198424;
        Wed, 11 Dec 2024 03:06:38 -0800 (PST)
Message-ID: <9e373326-5b20-4d47-ab3c-3b33da2d03c8@suse.com>
Date: Wed, 11 Dec 2024 12:06:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/1] tools/ocaml: Specify rpath correctly for
 ocamlmklib
To: Andrii Sultanov 
Cc: Christian Lindig ,
 David Scott , Anthony PERARD ,
 Fernando Rodrigues ,
 Christian Lindig , 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 09.12.2024 18:57, Andrii Sultanov wrote:
> ocamlmklib has special handling for C-like '-Wl,-rpath' option, but does
> not know how to handle '-Wl,-rpath-link', as evidenced by warnings like:
> "Unknown option
> -Wl,-rpath-link=$HOME/xen/tools/ocaml/libs/eventchn/../../../../tools/libs/toollog"
> Pass this option directly to the compiler with -ccopt instead.
> 
> Also pass -L directly to the linker with -ldopt. This prevents embedding absolute
> paths from buildtime into binary's RPATH.
> 
> Fixes: f7b4e4558b42 ("tools/ocaml: Fix OCaml libs rules")

Just to mention it: The hash is that of a backport, the staging commit is
8ffcf184affb afaict. Please use the canonical (staging) hash whenever
available.

Jan



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 11:12:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 11:12:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854598.1267764 (Exim 4.92)
	(envelope-from )
	id 1tLKdN-0004M1-53; Wed, 11 Dec 2024 11:12:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854598.1267764; Wed, 11 Dec 2024 11:12: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 1tLKdN-0004Lu-26; Wed, 11 Dec 2024 11:12:01 +0000
Received: by outflank-mailman (input) for mailman id 854598;
 Wed, 11 Dec 2024 11:12: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 1tLKdM-0004KX-2E
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 11:12:00 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id bc972ee6-b7b0-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 12:11:58 +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 813071063;
 Wed, 11 Dec 2024 03:12:25 -0800 (PST)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D0B813F5A1;
 Wed, 11 Dec 2024 03:11: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: bc972ee6-b7b0-11ef-a0d5-8be0dac302b0
From: Luca Fancellu 
To: xen-devel@lists.xenproject.org
Cc: Penny Zheng ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Jan Beulich ,
	Penny Zheng ,
	Wei Chen 
Subject: [PATCH v5] xen/arm: Check for Static Heap feature when freeing resources
Date: Wed, 11 Dec 2024 11:11:46 +0000
Message-Id: <20241211111146.2827727-1-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Penny Zheng 

If the Xen heap is statically configured in Device Tree, its size is
definite, so only the defined memory shall be given to the boot
allocator. Have a check where init_domheap_pages() is called
which takes into account if static heap feature is used.

Extract static_heap flag from init data bootinfo, as it will be needed
after destroying the init data section, rename it to using_static_heap
and use it to tell whether the Xen static heap feature is enabled.

Signed-off-by: Penny Zheng 
Signed-off-by: Wei Chen 
Signed-off-by: Luca Fancellu 
Reviewed-by: Jan Beulich  # common
---
Changes from v4:
 - Add R-by Jan
 - Changed code to reduce nesting in discard_initial_modules (Julien)
Changes from v3:
 - Removed helper using_static_heap(), renamed static_heap variable
   to using_static_heap and simplified #ifdef-ary (Jan suggestion)
Changes from v2:
 - Change xen_is_using_staticheap() to using_static_heap()
 - Move declaration of static_heap to xen/mm.h and import that in
   bootfdt.h
 - Reprased first part of the commit message
Changes from v1:
 - moved static_heap to common/page_alloc.c
 - protect static_heap access with CONFIG_STATIC_MEMORY
 - update comment in arm/kernel.c kernel_decompress()
---
---
 xen/arch/arm/arm32/mmu/mm.c       | 4 ++--
 xen/arch/arm/kernel.c             | 7 ++++---
 xen/arch/arm/mmu/setup.c          | 8 ++++++--
 xen/arch/arm/setup.c              | 3 +++
 xen/common/device-tree/bootfdt.c  | 4 +++-
 xen/common/device-tree/bootinfo.c | 2 +-
 xen/common/page_alloc.c           | 5 +++++
 xen/include/xen/bootfdt.h         | 1 -
 xen/include/xen/mm.h              | 6 ++++++
 9 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/arm32/mmu/mm.c b/xen/arch/arm/arm32/mmu/mm.c
index 063611412be0..0824d61323b5 100644
--- a/xen/arch/arm/arm32/mmu/mm.c
+++ b/xen/arch/arm/arm32/mmu/mm.c
@@ -199,7 +199,7 @@ void __init setup_mm(void)
 
     total_pages = ram_size >> PAGE_SHIFT;
 
-    if ( bootinfo.static_heap )
+    if ( using_static_heap )
     {
         const struct membanks *reserved_mem = bootinfo_get_reserved_mem();
 
@@ -246,7 +246,7 @@ void __init setup_mm(void)
 
     do
     {
-        e = bootinfo.static_heap ?
+        e = using_static_heap ?
             fit_xenheap_in_static_heap(pfn_to_paddr(xenheap_pages), MB(32)) :
             consider_modules(ram_start, ram_end,
                              pfn_to_paddr(xenheap_pages),
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 293d7efaed9c..8270684246ea 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -244,10 +244,11 @@ static __init int kernel_decompress(struct bootmodule *mod, uint32_t offset)
     size += offset;
 
     /*
-     * Free the original kernel, update the pointers to the
-     * decompressed kernel
+     * In case Xen is not using the static heap feature, free the original
+     * kernel, update the pointers to the decompressed kernel
      */
-    fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
+    if ( !using_static_heap )
+        fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
 
     return 0;
 }
diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c
index 9664e85ee6c0..8c87649bc88e 100644
--- a/xen/arch/arm/mmu/setup.c
+++ b/xen/arch/arm/mmu/setup.c
@@ -341,8 +341,12 @@ void free_init_memory(void)
     if ( rc )
         panic("Unable to remove the init section (rc = %d)\n", rc);
 
-    init_domheap_pages(pa, pa + len);
-    printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10);
+    if ( !using_static_heap )
+    {
+        init_domheap_pages(pa, pa + len);
+        printk("Freed %ldkB init memory.\n",
+               (long)(__init_end-__init_begin) >> 10);
+    }
 }
 
 /**
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 2e27af4560a5..85f743a2c6ad 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -206,6 +206,9 @@ void __init discard_initial_modules(void)
     struct bootmodules *mi = &bootinfo.modules;
     int i;
 
+    if ( using_static_heap )
+        return;
+
     for ( i = 0; i < mi->nr_mods; i++ )
     {
         paddr_t s = mi->module[i].start;
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index fc93d86e8232..61ad24c3ddc8 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -410,7 +410,9 @@ static int __init process_chosen_node(const void *fdt, int node,
         if ( rc )
             return rc;
 
-        bootinfo.static_heap = true;
+#ifdef CONFIG_STATIC_MEMORY
+        using_static_heap = true;
+#endif
     }
 
     printk("Checking for initrd in /chosen\n");
diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c
index 0daf5e941a51..76d652c0de0b 100644
--- a/xen/common/device-tree/bootinfo.c
+++ b/xen/common/device-tree/bootinfo.c
@@ -407,7 +407,7 @@ void __init populate_boot_allocator(void)
     const struct membanks *reserved_mem = bootinfo_get_reserved_mem();
     paddr_t s, e;
 
-    if ( bootinfo.static_heap )
+    if ( using_static_heap )
     {
         for ( i = 0 ; i < reserved_mem->nr_banks; i++ )
         {
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 92abed6514b4..013a1057cc7c 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -165,6 +165,11 @@
 #define PGT_TYPE_INFO_INITIALIZER 0
 #endif
 
+#ifdef CONFIG_STATIC_MEMORY
+/* Flag saved when Xen is using the static heap feature */
+bool __ro_after_init using_static_heap;
+#endif
+
 unsigned long __read_mostly max_page;
 unsigned long __read_mostly total_pages;
 paddr_t __ro_after_init mem_hotplug;
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 343c48b73d2c..c8bbfd8979b2 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -139,7 +139,6 @@ struct bootinfo {
 #ifdef CONFIG_STATIC_SHM
     struct shared_meminfo shmem;
 #endif
-    bool static_heap;
 };
 
 #ifdef CONFIG_ACPI
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index d7dcf0f06330..88536e8132f5 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -72,6 +72,12 @@
 
 struct page_info;
 
+#ifdef CONFIG_STATIC_MEMORY
+extern bool using_static_heap;
+#else
+#define using_static_heap false
+#endif
+
 void put_page(struct page_info *page);
 bool __must_check get_page(struct page_info *page,
                            const struct domain *domain);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 11:14:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 11:14:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854608.1267774 (Exim 4.92)
	(envelope-from )
	id 1tLKfp-0005C4-HP; Wed, 11 Dec 2024 11:14:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854608.1267774; Wed, 11 Dec 2024 11:14: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 1tLKfp-0005Bx-EY; Wed, 11 Dec 2024 11:14:33 +0000
Received: by outflank-mailman (input) for mailman id 854608;
 Wed, 11 Dec 2024 11:14: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 1tLKfn-0005Br-NI
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 11:14:31 +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 15db968a-b7b1-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 12:14:29 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733915660137679.3236455454473;
 Wed, 11 Dec 2024 03:14:20 -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: 15db968a-b7b1-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1733915663; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=V/OB6RMlhL4pXjbn9JWIe+DC/Vdbi3x9JySlvENYDEKO1XBbk2iXbbRyj7cD+UiyggVlSNTkdd5nJK+dLyYPx9fDDMJstD+1F7yZc6ylU4apq36daZoDhLGFFpaUJTqXogw51hu7wvVkOH1gqiamqrfyOJIsyo9bk7r1ZtNxXw8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733915663; 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=3TgrnbL4CAatymIXhWuE2IW+ubJfSKB9fy+QUWuG6bs=; 
	b=XuC0icdz3qqVM6Zoevk+q4RjiCQgLRY/pUZNjtDceWrnYxjzheMBj9CYQMzfiCiXts5w+UZcnYScrsil9vXbc5PRu3yjyQKR4pl6GEm4JywY+Hl0l3uJyOfRGyn5ckw2f6eYUx4+MizKnqvCDaTpXWpthrV53GWbp/Z3B9VPKew=
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=1733915663;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=3TgrnbL4CAatymIXhWuE2IW+ubJfSKB9fy+QUWuG6bs=;
	b=KaejwQyxWxNTCj00AEaIhmng0zIecdmhx0Dk2THCjDeYXlg2jIrwYl5ybtER3/96
	EPYuh2dhFPD2EsHwRWxdq/a2jLzKlclOdzXfVpgq9WfG6nBwf8x8StOClnV5+gbciBe
	+oTgPONEVNIiLgtMLvu2IDlUYHDdXFWG2b4aVHWA=
Message-ID: 
Date: Wed, 11 Dec 2024 06:14:18 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 06/15] x86/hyperlaunch: introduce the domain builder
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com,
 Jan Beulich , Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-7-dpsmith@apertussolutions.com>
 
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

On 11/25/24 12:52, Jason Andryuk wrote:
> On 2024-11-23 13:20, Daniel P. Smith wrote:
>> Introduce the domain builder which is capable of consuming a device 
>> tree as the
>> first boot module. If it finds a device tree as the first boot module, 
>> it will
>> set its type to BOOTMOD_FDT. This change only detects the boot module and
>> continues to boot with slight change to the boot convention that the dom0
>> kernel is no longer first boot module but is the second.
>>
>> No functional change intended.
>>
>> Signed-off-by: Daniel P. Smith 



>> +            bi->hyperlaunch_enabled = false;
>> +            bi->mods[0].type = BOOTMOD_FDT;
>> +            break;
>> +        default:
>> +            printk("Unknown error (%d) occured checking for 
>> hyperlaunch device tree\n",
>> +                   ret);
>> +            bi->hyperlaunch_enabled = false;
>> +        }
>> +
> 
> Stray blank line

ack.

>> +    }
>> +}
>> +
>> +/*
>> + * Local variables:
>> + * mode: C
>> + * c-file-style: "BSD"
>> + * c-basic-offset: 4
>> + * tab-width: 4
>> + * indent-tabs-mode: nil
>> + * End:
>> + */
>> diff --git a/xen/arch/x86/domain_builder/fdt.c b/xen/arch/x86/ 
>> domain_builder/fdt.c
>> new file mode 100644
>> index 000000000000..3f9dda8c34c3
>> --- /dev/null
>> +++ b/xen/arch/x86/domain_builder/fdt.c
>> @@ -0,0 +1,38 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Copyright (C) 2024, Apertus Solutions, LLC
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include  /* required for asm/setup.h */
> 
> Should asm/setup.h just be changed?

Will drop per the follow-

>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "fdt.h"
>> +
> 
>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>> index e6580382d247..8041aeb3dcfd 100644
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
> 
>> @@ -1591,7 +1596,8 @@ void asmlinkage __init noreturn __start_xen(void)
>>   #endif
>>       }
>> -    if ( bi->mods[0].headroom && !bi->mods[0].relocated )
>> +    i = first_boot_module_index(bi, BOOTMOD_KERNEL);
>> +    if ( bi->mods[i].headroom && !bi->mods[0].relocated )
> 
> Switch .relocated index to i?

ack.

v//r,
dps


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 11:17:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 11:17:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854623.1267784 (Exim 4.92)
	(envelope-from )
	id 1tLKie-0005kk-UE; Wed, 11 Dec 2024 11:17:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854623.1267784; Wed, 11 Dec 2024 11: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 1tLKie-0005kd-Rg; Wed, 11 Dec 2024 11:17:28 +0000
Received: by outflank-mailman (input) for mailman id 854623;
 Wed, 11 Dec 2024 11:17: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 1tLKic-0005kX-Q5
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 11:17:26 +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 7f743e05-b7b1-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 12:17:24 +0100 (CET)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-38637614567so1967895f8f.3
 for ; Wed, 11 Dec 2024 03:17: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
 d2e1a72fcca58-725e7efb381sm5832019b3a.117.2024.12.11.03.17.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 03:17: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: 7f743e05-b7b1-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733915844; x=1734520644; 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=V6HeZY8oKnERKqJlkDSm77F1uu3Cub+TrzX0rtTybfE=;
        b=GKWscZyWJjT0ZYkAT4W8zeDq5n+V0tYry+5IFwBqig0TrsbtIGyAzkOZInVrUKnYKL
         zqT486uetSI5PIA9Y44Iqh0ye70TZE+rV8ao11kUj9uAaST6KW2A4vsn0H/j8KQwYltj
         Mf8GRQaaBhLpQjBCFnXBjNrlOWN4LU3rpPMfFp/njN+hKVJB8hF5Zb/DBZMGc7yAKBDQ
         c3Tb24jKOqRnll9EeRJNqSDonXHGKJZZFnPDK+2PMw8DmtzJtEv+E3jLVBE9eehsA5du
         Fpxf+s1lKvLPSwFlxEZK/uoQB1pLFFznlWH8qp9z/7JNAuaKqs99aVOiDASTXMdUrmJo
         3axA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733915844; x=1734520644;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=V6HeZY8oKnERKqJlkDSm77F1uu3Cub+TrzX0rtTybfE=;
        b=rsjieLhVK1t+0BweOjwUwFv3PL3pBaXPmbLUd7ybpHUpumEIpFSkSUWNeSKQg9sVk4
         bHbmToVQ6BB8e7Yy6sk49umDFKKadW61/AQDa3CBj3E531OgVD8VRc9tu/rBEkGrKqVp
         3W0Gq17PEcFr8h7TzgeH9bRcSv5vVnaq4lPZhbwGBGDZpDdRGtsbODYd5PfqG0e8AOaU
         ZxC3mdzhppzGcY2qGyCNMDmsKQnUm3g+9O+k049THzvLx5yGfNy4LW4CNjXxImFY8AbC
         QB+KEDovPwW6uQF/hu5XNnVhNoVGFnpSjiHRs4rxL3PaHLQaSEXA6YZDjL7ybykhbFJj
         JaTQ==
X-Forwarded-Encrypted: i=1; AJvYcCURh64xcsnxQpCNnDwsZPdfa5uCNYSqQ3mK12GuDiiAsMcAXhVIwtzuGhxTKPH0OKV0XoRHs5PLLZI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx5r0OxeKFLAlGfla2EaKgXoN4Isjahe408FHLaWCay4hV6WviQ
	GQ7xw/gf14nON8m0ionn3HlYZkEMj8ii3CV0MnzSQef/xbqVTjkEd+KposP+Dg==
X-Gm-Gg: ASbGncupnf/J2Xlatz8yMTwfrDePz+2X2CEk2v5S7BNVOlMro4fyandeFmqEn0lZSBQ
	++QzAw9Jcx/XIQWII/8QPPTCrR7e2UKWEEayXceshgt6xBEUMw5zJrdQoDbGPgDDSNcBhvhRUi/
	fj58iSAdKxoK/3qIzEtCTaR/1oY3U+B8gCDYPJlpMl1U0WT9HNFjkAno0YLcKSPfaYimS0n2wYg
	lmtN1ErC4wiUaRUuCyPQs8dMFZuSxDG+TZo2Vnjl1vFwNVhNiMpghMLWafO79hCnn/VhkpoZvfT
	BXjSMCSadrb6UPCYvSQDQ++f3pOoIsBhTO0A+vY=
X-Google-Smtp-Source: AGHT+IGBA81eJaPEYhr2B8xEx9gTIr9BwlfSsIFjW4M4dBpyQUv8IWTzLOmJEjx4Uc/49Bkx/z6Mog==
X-Received: by 2002:a05:6000:188e:b0:385:f847:aa40 with SMTP id ffacd0b85a97d-3864cec5c19mr1642931f8f.38.1733915844253;
        Wed, 11 Dec 2024 03:17:24 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 12:17:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: address violation of MISRA C Rule 11.1
To: Alessandro Zucchelli 
Cc: consulting@bugseng.com, Stefano Stabellini ,
 Julien Grall , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <7debd63f3900bad62bcbcc03081e4c04e6099135.1733914487.git.alessandro.zucchelli@bugseng.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: <7debd63f3900bad62bcbcc03081e4c04e6099135.1733914487.git.alessandro.zucchelli@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.12.2024 12:02, Alessandro Zucchelli wrote:
> Rule 11.1 states as following: "Conversions shall not be performed
> between a pointer to a function and any other type".
> 
> Functions "__machine_restart" and "__machine_halt" in "x86/shutdown.c"
> and "halt_this_cpu" in "arm/shutdown.c" are defined as noreturn
> functions and subsequently passed as parameters to function calls.
> This violates the rule in Clang, where the "noreturn" attribute is
> considered part of the function"s type.

I'm unaware of build issues with Clang, hence can you clarify how Clang's
view comes into play here? In principle various attributes ought to be
part of a function's type; iirc that's also the case for gcc. Yet how
that matters to Eclair is still entirely unclear to me.

> By removing the "noreturn"
> attribbute and replacing it with uses of the ASSERT_UNREACHABLE macro,
> these violations are addressed.

Papered over, I'd say. What about release builds, for example?

Deleting the attribute also has a clear downside documentation-wise. If
we really mean to remove them from what the compiler gets to see, I think
we ought to still retain them in commented-out shape.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 11:25:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 11:25:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854638.1267794 (Exim 4.92)
	(envelope-from )
	id 1tLKpt-0007xx-P6; Wed, 11 Dec 2024 11:24:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854638.1267794; Wed, 11 Dec 2024 11:24:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLKpt-0007xq-MO; Wed, 11 Dec 2024 11:24:57 +0000
Received: by outflank-mailman (input) for mailman id 854638;
 Wed, 11 Dec 2024 11:24: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 1tLKpt-0007xk-6H
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 11:24: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 8bdfb97d-b7b2-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 12:24:55 +0100 (CET)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3862d161947so3213040f8f.3
 for ; Wed, 11 Dec 2024 03:24:55 -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
 41be03b00d2f7-7fd41ff3e42sm5315773a12.66.2024.12.11.03.24.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 03:24: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: 8bdfb97d-b7b2-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733916294; x=1734521094; 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=uEOy6GUTe9DcIrZM/FqY1amRjFDGbsZuoJuVNsttO5c=;
        b=I1iFrhispkLmezTdxgHkVl0zi6JXa9RCqjBAuTbQ1F1rvn2eFDNP940sIl/kWPYPwl
         TFSZrVi+cdIkbVHdzv413wkVr1upJUmgvZIZJ/QREkFH3vGW459612cmLzj1EFRpSPAw
         yP7psEBHr6AZMeu1Ww8FPB/+5L77wPtrqYK/VdT/QHWofmG2s7UpFqZBV1s+OgR7QicG
         EK5VF2b52eCJ5lVPBJ5ZZf0UZT3+bJb1q3YIRp355a8ZqRZBMSrRtvQqMSVo6XIiQgtY
         NbhiiSvUWBEIrJGuOvbBtpxqenP3GayIroDa5E7R4uoJCPZukMtXPtKWNHm6nF2eGu1a
         VAHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733916294; x=1734521094;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=uEOy6GUTe9DcIrZM/FqY1amRjFDGbsZuoJuVNsttO5c=;
        b=K3gYeiPSNXHyZrDuVzmXyNtKd5GsSflJNxbXy1sxr8GI9f1gK7+DVnO/GUwhNhiUKk
         TBDG7+zRzOqYg6CmSvKpwssbjiZ+w5q5OqRUMNjnt7gIRHb3/e8vfCJYcd5u/6j1z63H
         nQjUMwj2rS3UpFtWLeyKOfT2J4q34XWp2HBI5EAtoFZuMLb9kUzK6yDRBXkqVrBNH5CG
         jlYe+tWfm25m6cBH3eOg/EY9vksRYvLd0hXsveJvxZeW3Jf34e0csBV2GXvNVUIThoEb
         hXx61cXMdi+tYirg33Vv1vdaU/BdeFY7wqeyhmSvg2RjlZBwyqvoY3+4VZgRVMyNi6dQ
         X/DA==
X-Forwarded-Encrypted: i=1; AJvYcCX4Yxhq56+8shMx+02Hoa1+qK9pZ9kCfWo0y3RGI40aP0WJhY0U+Ga13JMkkFDbvzcr8mKI4fBYllg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz2jYZGXL2/Kz4y5NB3tgxkRdyonMtWkdMs2XmFvrVbRQmDlVhx
	CI1To+EJfpyoAPZyTMunHGd8C1PadP5VDds7C4QZ/gWTebhkfg+cF2laVuQUHQ==
X-Gm-Gg: ASbGncsGVPuJtl5+bvjLSzl82lMsqcbjQPTllS+FOl5KV+AyhMHs9uEEFYg7W1gUhDi
	ITO6rGBdDNPuF9+wx+B/PRRIBnPc0oc5IGi7OwC5rsY0EBRBVY+1XoPmlWMkhBiWFVPopwL05OK
	Qfoj81hb5o3xW3ertEwqtr1JeTV314mKMB5iqXelYM7CapnT/3p7I2lrl3fv8+IDyCY3Ve+BdBg
	CD8uy3jts81fx4OVjQTFSLh3x9a9A6JpO9bY1rcp12CxUP6l4m/cq9aIkYQGW5OCHGyUq6AFWR+
	dHg/hIyXDHd3vzFLwJ68gFeAMlZCDZW2WXsGo9s=
X-Google-Smtp-Source: AGHT+IHSkUmhnIRGJjWHsZUlSQIE6ZcKlxR20+lwKTRXEsCbQeOZVk7IQ8235ZtZ+Y4r799QN9pDJA==
X-Received: by 2002:a05:6000:42c5:b0:386:3dad:8147 with SMTP id ffacd0b85a97d-3864ce6e6f2mr1190089f8f.32.1733916294683;
        Wed, 11 Dec 2024 03:24:54 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 12:24:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] misra: add deviation for MISRA C Rule R11.1.
To: Alessandro Zucchelli 
Cc: consulting@bugseng.com, Andrew Cooper ,
 Julien Grall , Stefano Stabellini ,
 xen-devel@lists.xenproject.org
References: <8db58416ce215a3c5fdba8074dc21f32116e8a41.1733915076.git.alessandro.zucchelli@bugseng.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: <8db58416ce215a3c5fdba8074dc21f32116e8a41.1733915076.git.alessandro.zucchelli@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.12.2024 12:05, Alessandro Zucchelli wrote:
> Rule 11.1 states as following: "Conversions shall not be performed
> between a pointer to a function and any other type".
> 
> In "xen/common/bug.c", in order to get additional debug information,
> pointer "bug_fn_t *fn" in the data section is converted to a function
> pointer, which is then used to get such information.

If the pointer converted pointed into the data section, it would fault
upon being used to call what it points to, for the lack of execute
permissions there.

The change itself looks okay to me, but the description imo needs
updating, to be as precise as possible.

Jan


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 11:41:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 11:41:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854652.1267804 (Exim 4.92)
	(envelope-from )
	id 1tLL5p-0002y9-4F; Wed, 11 Dec 2024 11:41:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854652.1267804; Wed, 11 Dec 2024 11:41: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 1tLL5p-0002y2-0x; Wed, 11 Dec 2024 11:41:25 +0000
Received: by outflank-mailman (input) for mailman id 854652;
 Wed, 11 Dec 2024 11:41: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 1tLL5n-0002xu-Tf
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 11:41:24 +0000
Received: from fhigh-a7-smtp.messagingengine.com
 (fhigh-a7-smtp.messagingengine.com [103.168.172.158])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d7654565-b7b4-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 12:41:21 +0100 (CET)
Received: from phl-compute-07.internal (phl-compute-07.phl.internal
 [10.202.2.47])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 1879B1140105;
 Wed, 11 Dec 2024 06:41:20 -0500 (EST)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-07.internal (MEProxy); Wed, 11 Dec 2024 06:41:20 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 11 Dec 2024 06:41:18 -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: d7654565-b7b4-11ef-a0d5-8be0dac302b0
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=fm1; t=1733917280; x=1734003680; bh=px
	oXU/wqIbkzSyF/1YFlLcAuQp8pdCkQQkcCxhXVQ7Y=; b=I6lbiXY+9bniIdq/Em
	hEfmzBKVGFS94QrshSkXBEM2MxrYvx9VW86kvyLk1zkk5RWrqqXttfc747f4qJap
	S6c5HMy2mXcHx5l00L/FC6h5yIgxdjPDCk84Lxt+2l6BhROQ+AURFJLYPX7igisT
	eBu92tvugr94clH2/GPfDwNXOMv/v54jYeUnvPLD/sfVAZDivEfCvTEUCSJhOOxF
	AvFZMYxYIvoHE2giUUhnBMl1IOeoeu7KAYIwbJ61mr/vXakPbqaz2txfmDIjUyMA
	wNnh3raIJ/xW0dsnYsbFMlX2NcK/CMAwuiYGBLKPvU7xWcVuQ4ylcII5q9nxEdrK
	vhWA==
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=1733917280; x=
	1734003680; bh=pxoXU/wqIbkzSyF/1YFlLcAuQp8pdCkQQkcCxhXVQ7Y=; b=Y
	2i29EQn3cr69Y/DJsv30iVlWTrqSdDeLFi2U1vzjmFO7jgngeoFZHuzk6W64VDVW
	ptD93mOf3ZyVwCLyYiVvqDPTbC2sqisGUeMFhI3A2PJNhqwkjx7of9hhmks3Jsyf
	5B72pqqli8hEVE74iR0JcdJx2d6v4rP5ei3Mo0cAAtRh5nRPN6aPltz1lsHrNUZc
	wKlPg80sE93EuO2WRdtYqyBq1S7a2Zyx1YxV95i5IkS+OffwaovtM/4x9MQytg6A
	tefblPRKD7GPBoGrv0G2joqMECm7+LFQcr4dGvjXyr44BbsmInJQjo/GEp0o6Aaw
	I4fbL55yypP8bCIotDAXg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrkedtgdeftdcutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr
    tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth
    hsucdlqddutddtmdenucfjughrpeffhffvvefukfggtggusehgtderredttdejnecuhfhr
    ohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmh
    grrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrght
    thgvrhhnpedugffgieelueeukedthfffledvhfejfeefheeuieekhfeludeljeejleegje
    duffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm
    rghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprh
    gtphhtthhopeehpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopeigvghnqdguvghv
    vghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopehjghhroh
    hsshesshhushgvrdgtohhmpdhrtghpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhn
    vghlrdhorhhgpdhrtghpthhtohepohhlvghkshgrnhgurhgpthihshhhtghhvghnkhhose
    gvphgrmhdrtghomhdprhgtphhtthhopehrvghgrhgvshhsihhonhhssehlihhsthhsrdhl
    ihhnuhigrdguvghv
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Wed, 11 Dec 2024 12:41:17 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel 
Cc: Juergen Gross ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	regressions@lists.linux.dev
Subject: [REGRESSION] Linux 6.6.64 crashes when booting as PVH domU
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="GmdDK/bWMBAmn8YR"
Content-Disposition: inline


--GmdDK/bWMBAmn8YR
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 11 Dec 2024 12:41:17 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel 
Cc: Juergen Gross ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	regressions@lists.linux.dev
Subject: [REGRESSION] Linux 6.6.64 crashes when booting as PVH domU

Hi,

With Linux 6.6.64 I get the following crash on domU boot:

(XEN) d5v0 Triple fault - invoking HVM shutdown action 1
(XEN) *** Dumping Dom5 vcpu#0 state: ***
(XEN) ----[ Xen-4.19.0  x86_64  debug=3Dn  Tainted:  M     ]----
(XEN) CPU:    4
(XEN) RIP:    0008:[]
(XEN) RFLAGS: 0000000000010086   CONTEXT: hvm guest (d5v0)
(XEN) rax: ffffffff82b64050   rbx: ffffffffffe00000   rcx: 00000000c0000101
(XEN) rdx: 0000000000000000   rsi: 0000000003a00038   rdi: 0000000002a9bc98
(XEN) rbp: 0000000000000000   rsp: 0000000002aa0ce8   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 0000000080000011   cr4: 0000000000000020
(XEN) cr3: 0000000002022000   cr2: 0000000000000000
(XEN) fsb: 0000000000000000   gsb: 0000000002a9ccc0   gss: 0000000000000000
(XEN) ds: 0010   es: 0010   fs: 0000   gs: 0000   ss: 0010   cs: 0008

Linux 6.6.63 works fine.

Looking at the changes, I suspect one of those:

    83d123e27623 x86/pvh: Call C code via the kernel virtual mapping
    f662b4a69e1d x86/pvh: Set phys_base when calling xen_prepare_pvh()

But I haven't tested this hypothesis yet.

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

--GmdDK/bWMBAmn8YR
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmdZel0ACgkQ24/THMrX
1ywnkAf7B78k0a25zBk76rTR71NW+VMvQKr2hh5quoNnasjgSp2Avq6Rs7CSA8Kq
o1LTT6WtYXzcDLRzOvlrrb25RT/wXJhaKYcl3S40L1atfCVOtx7uTsKbRjpLmHLf
HxZeV1AIzk/JlbJyUFJ6bCFzyIncOzIp4GGyb+NeUKanK2g3tWDj1+7P4qgdHaYl
X1QKBqwpZpeOM4TcYoR0NnflOqoseguGz4ARJihvGWtNIs7ahvkhsS9sbFDOJhGT
5mE/MGL2v3W2Q3ifAM9UXYl1oufZ5ye4cFXCeFsZ8qR8LjzeY2LAdeYxFzE/rVZ4
toWQ3eWCiZGVXTh0E0yNCCVeP7tY9Q==
=nPqk
-----END PGP SIGNATURE-----

--GmdDK/bWMBAmn8YR--


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 11:53:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 11:53:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854665.1267822 (Exim 4.92)
	(envelope-from )
	id 1tLLHr-0005Pw-AN; Wed, 11 Dec 2024 11:53:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854665.1267822; Wed, 11 Dec 2024 11:53: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 1tLLHr-0005Pp-7K; Wed, 11 Dec 2024 11:53:51 +0000
Received: by outflank-mailman (input) for mailman id 854665;
 Wed, 11 Dec 2024 11:53: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 1tLLHp-0005Pj-Qc
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 11:53:49 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9510e7db-b7b6-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 12:53:48 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5d3f65844deso5384545a12.0
 for ; Wed, 11 Dec 2024 03:53:48 -0800 (PST)
Received: from ?IPV6:2003:e5:8701:7700:f2d:e3aa:8e9e:99bf?
 (p200300e5870177000f2de3aa8e9e99bf.dip0.t-ipconnect.de.
 [2003:e5:8701:7700:f2d:e3aa:8e9e:99bf])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d3eb109bc9sm5613036a12.42.2024.12.11.03.53.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 03:53: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: 9510e7db-b7b6-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733918028; x=1734522828; 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=+R0+7C5nvllYcIQQ4mNgtqM96poYNitgNFUx4o4mftA=;
        b=b4aSUBynoIpbBG1CsB9Kh0TjOqdyHSOxUuxgTI+39M9oh/5PxuMVXSFpg0z3jUBQfn
         mWVCu8ucpZMlJgDDDj1A55IHS7sgbzDl8887/IlHuO7CJiNzj/veXfWRPsJ1jlEHbwat
         56hHOB1ruhMz8yt2M5JECn56afMu9oYtfDDU7t9YNcJs9fLTRqtgLuOE9LhwmKAMZ6Fi
         /dNICaUynBwactNvN+9jE5xsmOAdhl0mXFyB4JaQqZkQUrK6uzqh63YnY8xQD/KSKRBg
         be9Jg1nsnnR5XEEgMO6sMbhe4tXLnbh43V/LcMzpSSf3pbRt/UbNv2175dpH2+0sVErz
         R5yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733918028; x=1734522828;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=+R0+7C5nvllYcIQQ4mNgtqM96poYNitgNFUx4o4mftA=;
        b=m5VWN5cwdpgAg85OLi7dVTBHDyuxleiN1jAoWEhBzfp76Qeu7YlaDNQP53nIlYm/a5
         Tc8CQPPiEFULat1yxkeXUBi5SA3JmjLrh/AO75DTHm51XXMAchrOkiv11l/UHzAsoEIg
         A7a26UQrfTIHlMvFtrDHsfdC2sKRkS3DVY5jXRKhgtI5LkZWGYYoZqNhKwlycW3i/MTg
         1Cny2qJcuufEsMdXp4nMOZU6aeWQHbwDuJacCrF+MG6fOf6y49y11UbFpsV+GRvtpLaD
         p5TEm1zvBrhi95Nb60QjcEhcOU33jjtE8y3lqHkevfCv9rlFmRHqX0GgTGIQkXbKl7Vp
         F0og==
X-Forwarded-Encrypted: i=1; AJvYcCWvWspnUtqv1GvI+BaiwhqTQLMVRchEz/OFiIwWrIkmUO8OaKEaaLaITYQ4eLKgAHXSjsONarjCR5g=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxSdnI3ruKVRPN7oOpvPSq935/8X6srLvr3VzSTn1iYhEXJQpC3
	7tyB8i28ehkTptmhHqFSL+XdU69U9FT89dMoXLNr2VoqIbxlAlpzeZc/Zi/chXI=
X-Gm-Gg: ASbGncuqxHNPf2PiSzGSXLWLZNW9lMhHRi/xlZ2EVau4fuDz2C8qUmL+BHM/uMrQyMr
	XXS54bP5UwL0AoHjOSJ1L8Ztxo/+SBfXWjnHbnkQ8+v+ldoYiyXZwnBL93W88CHPjfhXZjIQFIk
	hMHp2uo8P4nljLm57xh2/5ELZAPcYZ8sYiyJrZQmZWVyQEGPJBEGk0XSdMCad7gz0wwBG8uWwYY
	SteZhNjQeEhs1Km9PXCqJpHZIsU6m1i33Xu4nRnTHzYcLRAHrVXpcNzkIOf535795M00RWCDrcA
	/U6jr2+o6Bb6EjdSUmidH0bjRZa5rNjzuqviMu8lgI04eEYaqgtubYzUlWFrEbACPdUwX96OPYn
	x
X-Google-Smtp-Source: AGHT+IGO03Vy7/Zpc9Wz/aZOtOyjaC+nhsiaDKnU4Xri1dTiaKaNObvvpV9PhW20SnxQPeC6/DM3Yg==
X-Received: by 2002:a05:6402:3513:b0:5d3:cd5b:64a9 with SMTP id 4fb4d7f45d1cf-5d433170507mr2468066a12.34.1733918027892;
        Wed, 11 Dec 2024 03:53:47 -0800 (PST)
Message-ID: 
Date: Wed, 11 Dec 2024 12:53:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [REGRESSION] Linux 6.6.64 crashes when booting as PVH domU
To: Jason Andryuk , Ard Biesheuvel 
Cc: Stefano Stabellini ,
 Oleksandr Tyshchenko ,
 regressions@lists.linux.dev, xen-devel ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
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="------------dnr5QCG4S9m0K4gz5yYaxenH"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------dnr5QCG4S9m0K4gz5yYaxenH
Content-Type: multipart/mixed; boundary="------------TQhMIvn8ggQ2o6nwyvX7vp6m";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jason Andryuk , Ard Biesheuvel 
Cc: Stefano Stabellini ,
 Oleksandr Tyshchenko ,
 regressions@lists.linux.dev, xen-devel ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Message-ID: 
Subject: Re: [REGRESSION] Linux 6.6.64 crashes when booting as PVH domU
References: 
In-Reply-To: 

--------------TQhMIvn8ggQ2o6nwyvX7vp6m
Content-Type: multipart/mixed; boundary="------------60F0NlJqcb3DyRKIqqsR10rj"

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

SmFzb24sIEFyZCwNCg0KSSBndWVzcyB0aGVyZSBhcmUgc29tZSBwcmVyZXEgcGF0Y2hlcyBt
aXNzaW5nIGluIHN0YWJsZSA2LjYueSBicmFuY2g/DQoNCg0KSnVlcmdlbg0KDQpPbiAxMS4x
Mi4yNCAxMjo0MSwgTWFyZWsgTWFyY3p5a293c2tpLUfDs3JlY2tpIHdyb3RlOg0KPiBIaSwN
Cj4gDQo+IFdpdGggTGludXggNi42LjY0IEkgZ2V0IHRoZSBmb2xsb3dpbmcgY3Jhc2ggb24g
ZG9tVSBib290Og0KPiANCj4gKFhFTikgZDV2MCBUcmlwbGUgZmF1bHQgLSBpbnZva2luZyBI
Vk0gc2h1dGRvd24gYWN0aW9uIDENCj4gKFhFTikgKioqIER1bXBpbmcgRG9tNSB2Y3B1IzAg
c3RhdGU6ICoqKg0KPiAoWEVOKSAtLS0tWyBYZW4tNC4xOS4wICB4ODZfNjQgIGRlYnVnPW4g
IFRhaW50ZWQ6ICBNICAgICBdLS0tLQ0KPiAoWEVOKSBDUFU6ICAgIDQNCj4gKFhFTikgUklQ
OiAgICAwMDA4Ols8ZmZmZmZmZmY4MmI2NDA1MD5dDQo+IChYRU4pIFJGTEFHUzogMDAwMDAw
MDAwMDAxMDA4NiAgIENPTlRFWFQ6IGh2bSBndWVzdCAoZDV2MCkNCj4gKFhFTikgcmF4OiBm
ZmZmZmZmZjgyYjY0MDUwICAgcmJ4OiBmZmZmZmZmZmZmZTAwMDAwICAgcmN4OiAwMDAwMDAw
MGMwMDAwMTAxDQo+IChYRU4pIHJkeDogMDAwMDAwMDAwMDAwMDAwMCAgIHJzaTogMDAwMDAw
MDAwM2EwMDAzOCAgIHJkaTogMDAwMDAwMDAwMmE5YmM5OA0KPiAoWEVOKSByYnA6IDAwMDAw
MDAwMDAwMDAwMDAgICByc3A6IDAwMDAwMDAwMDJhYTBjZTggICByODogIDAwMDAwMDAwMDAw
MDAwMDANCj4gKFhFTikgcjk6ICAwMDAwMDAwMDAwMDAwMDAwICAgcjEwOiAwMDAwMDAwMDAw
MDAwMDAwICAgcjExOiAwMDAwMDAwMDAwMDAwMDAwDQo+IChYRU4pIHIxMjogMDAwMDAwMDAw
MDAwMDAwMCAgIHIxMzogMDAwMDAwMDAwMDAwMDAwMCAgIHIxNDogMDAwMDAwMDAwMDAwMDAw
MA0KPiAoWEVOKSByMTU6IDAwMDAwMDAwMDAwMDAwMDAgICBjcjA6IDAwMDAwMDAwODAwMDAw
MTEgICBjcjQ6IDAwMDAwMDAwMDAwMDAwMjANCj4gKFhFTikgY3IzOiAwMDAwMDAwMDAyMDIy
MDAwICAgY3IyOiAwMDAwMDAwMDAwMDAwMDAwDQo+IChYRU4pIGZzYjogMDAwMDAwMDAwMDAw
MDAwMCAgIGdzYjogMDAwMDAwMDAwMmE5Y2NjMCAgIGdzczogMDAwMDAwMDAwMDAwMDAwMA0K
PiAoWEVOKSBkczogMDAxMCAgIGVzOiAwMDEwICAgZnM6IDAwMDAgICBnczogMDAwMCAgIHNz
OiAwMDEwICAgY3M6IDAwMDgNCj4gDQo+IExpbnV4IDYuNi42MyB3b3JrcyBmaW5lLg0KPiAN
Cj4gTG9va2luZyBhdCB0aGUgY2hhbmdlcywgSSBzdXNwZWN0IG9uZSBvZiB0aG9zZToNCj4g
DQo+ICAgICAgODNkMTIzZTI3NjIzIHg4Ni9wdmg6IENhbGwgQyBjb2RlIHZpYSB0aGUga2Vy
bmVsIHZpcnR1YWwgbWFwcGluZw0KPiAgICAgIGY2NjJiNGE2OWUxZCB4ODYvcHZoOiBTZXQg
cGh5c19iYXNlIHdoZW4gY2FsbGluZyB4ZW5fcHJlcGFyZV9wdmgoKQ0KPiANCj4gQnV0IEkg
aGF2ZW4ndCB0ZXN0ZWQgdGhpcyBoeXBvdGhlc2lzIHlldC4NCj4gDQoNCg==
--------------60F0NlJqcb3DyRKIqqsR10rj
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-----

--------------60F0NlJqcb3DyRKIqqsR10rj--

--------------TQhMIvn8ggQ2o6nwyvX7vp6m--

--------------dnr5QCG4S9m0K4gz5yYaxenH
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/Ey8FAmdZfUsFAwAAAAAACgkQsN6d1ii/Ey8c
pQf6AiwcXh+1f9XIHbWJ3nN6sG+5OefKvcmQVyzazmY6dytj2wKZuV1J2hf2x0kn/Xv6BfkPNG/b
2IW5jWLHKDb3JPwGGh8w2HyUSxBJ9LI+jCJSTaZ6r+JKpn+FcV3Lvh4FZbCdC8SdXyEEW48xmaG5
fzD6gfRjxBv/Y0AeN/MB6vF06vvwLnCoVa3WdxI6sENZL2ypFSV4QPvl0wjm3HTkYtyeEczgS03M
/lvQPCBm45D09fi+r2v7QxpQFT7b4q9aUVUOKGD75lgfrII9NxKGlfds6c39dCUbMazFWGsjI3Nj
3itHMU8P5xVFQY+R/GZ3vo/zsp1QgIScQfmqFV6H7A==
=9l5Q
-----END PGP SIGNATURE-----

--------------dnr5QCG4S9m0K4gz5yYaxenH--


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 11:59:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 11:59:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854678.1267833 (Exim 4.92)
	(envelope-from )
	id 1tLLNX-00061b-0F; Wed, 11 Dec 2024 11:59:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854678.1267833; Wed, 11 Dec 2024 11:59: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 1tLLNW-00061U-Rm; Wed, 11 Dec 2024 11:59:42 +0000
Received: by outflank-mailman (input) for mailman id 854678;
 Wed, 11 Dec 2024 11:59: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 1tLLNV-00061O-In
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 11:59:41 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2060e.outbound.protection.outlook.com
 [2a01:111:f403:2415::60e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 660b3054-b7b7-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 12:59:39 +0100 (CET)
Received: from PH7P220CA0007.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:326::13)
 by SA1PR12MB8642.namprd12.prod.outlook.com (2603:10b6:806:383::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.12; Wed, 11 Dec
 2024 11:59:35 +0000
Received: from CY4PEPF0000EDD1.namprd03.prod.outlook.com
 (2603:10b6:510:326:cafe::a9) by PH7P220CA0007.outlook.office365.com
 (2603:10b6:510:326::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.15 via Frontend Transport; Wed,
 11 Dec 2024 11:59:34 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CY4PEPF0000EDD1.mail.protection.outlook.com (10.167.241.197) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Wed, 11 Dec 2024 11:59:34 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 11 Dec
 2024 05:59:33 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) 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, 11 Dec
 2024 05:59:18 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 11 Dec 2024 05:59:16 -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: 660b3054-b7b7-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=gpSQDH3y0fYsH096SNJxkHtUFokDOmf6fYnN09bxj6a7iyBcj5B0BpldPRPNTw8UQEDrJLSEhb4tWSGnz8o3Hnag7VmRYKbaJp9+7nNqEuHKZ0FnRgRt79b2l8QA1T2vIn29TAjW9j/44OiLPfsgB/aD4vD9fCLmtUEcPiHBSR6IZmJd2CXhCGZy8ofsegJJkx+HtqVZQXDM0jOeBIlUPJGg4Ecs8Rt+KCQNQSCu+RLJSfrw+g+SWWI2gDKkMWFgJw3hlcSrqipSJ5/bO2OoHxHH/kWreS6tHnu0664WtRkxokgMA5YJ7irChaum2j1h1dikzWPNAfF4BnlLWToMFg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=IuRQHK89G/HNx5Gca97LlUCXEdGKy20FhP/9AKb8fkQ=;
 b=hpAJjJoTYjmkFBWOI3Qc7ZtzFQHbkFtcMtxL+PK1Pz2Q2YTSiWH+hD5vQKA+a7yBzIrB0/hskWHgJKHTY3hn6NLrZw/zn410Kpu0GGZyBefsSgD7c9N+d0mRNRQ7CSfsTfyqETlHvTrc6v5dWy8SXPNXAvY6nHlTUpQqaNNN/j+SuK5KZgVc4/Nfg6rY65U2eX0q6bEaEz3s1FrnUk54p1UxJP2JP3pGcBgrxWZZAQ+YnR0XZkk0MVngeEIULInRSt4hJGw6pPOlNL/3nUuw0tuoO7fCXkK8VgvXBDQztvZsKXbih/8PvaSWQhAmb4GfL+vuZ1t5uZYNlHrr4AhXuA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=IuRQHK89G/HNx5Gca97LlUCXEdGKy20FhP/9AKb8fkQ=;
 b=vEz6lwA5jHUA8Z3B7wBMWB7jYTHoTPZZ8bImPtRM5q42T8LpyFXN+D5xRZyZlzaUCjguP5yLXl1ZUtDWXLf0cefd0lH3GrmSUC1xL8vbQayTvhQLu7kZ7vatkKqo1qMvIcTDjTOmRHIZYOjOPevGMclf7CtpHEhvG8yE74Arq7I=
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=SATLEXMB03.amd.com; pr=C
Message-ID: <4dfbf14e-25b2-4d16-9323-b711e7e29752@amd.com>
Date: Wed, 11 Dec 2024 12:59:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5] xen/arm: Check for Static Heap feature when freeing
 resources
To: Luca Fancellu , 
CC: Penny Zheng , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Volodymyr Babchuk ,
	Andrew Cooper , Jan Beulich ,
	Wei Chen 
References: <20241211111146.2827727-1-luca.fancellu@arm.com>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <20241211111146.2827727-1-luca.fancellu@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EDD1:EE_|SA1PR12MB8642:EE_
X-MS-Office365-Filtering-Correlation-Id: c1ceca26-e7a5-45de-b21e-08dd19db4774
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024|7416014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?NTFaUnJOWk5TLytSMkw2S3ZVbU5ZdVAyRW12cGJYSkhzNW04b3JwYU55SHlk?=
 =?utf-8?B?blNaU2g2WkZMR3Y0MXBNTXJYaFZxdm5NN1J5bXFiaGltNEJvSysxMmo3aitN?=
 =?utf-8?B?b0EySy8rMnkrTzR2VFJndkpXaXZLQWVtMHAwNThYOVlsT0dqbXZEZVJCUkVk?=
 =?utf-8?B?K2s5UEhDMzhlOVNWeUI3cW9PZXFsRHVWMzdKNmkvaHdYNlU5RS8vUG54T25o?=
 =?utf-8?B?cktzaURjNzVhY3pyQmZpbGV3c0MyTUs1dE1PY21XQlZIS28zZ1VCeUFRN3U1?=
 =?utf-8?B?QnAyTmV2Z0dNa2xKMVBiWFhka3BjdWhLQWdkOU0wUlBGdXpZNk16VDU1bnk1?=
 =?utf-8?B?ZjRSbWtLUzRWSWVWQ1JzM05jZnU1S3F4NXo2cjRPT004SjBnckk0LzJEWEZF?=
 =?utf-8?B?KzFxY3M2cVBhZWFjTkw3NzhzbWRYaEU3WHRRSnN5eFRaVFJZMFdGQ0NsYlhK?=
 =?utf-8?B?YUZtcVBxelFDQktiUDhoUU9DbWpnck95U0UyOVdRTTRFUGl2Wk03M1JmQmdP?=
 =?utf-8?B?dzZUeGg4SFBta2VnWTl3bjlKRGQ0cG9HdW9rZlNvMUwxSVQ0c3dIaWFjNmE4?=
 =?utf-8?B?R2JzUUNXelhZUUlFYUFsUVNscms4MmErb3F2ZlNzUGd5b1RhNk1MWlJScE5t?=
 =?utf-8?B?V3RHcURLQk5DSnJJSnp6cmV3YkNuK0grUnN6VXRUZk9wUXNNam5wR1JmYTJm?=
 =?utf-8?B?UU5Dd1d3b3JpelIvYUxGY2ZBU0RaNWZFazdSVERWVXd2alhuUHQ4Q1NyUUxR?=
 =?utf-8?B?ajcwMzQvUVpPQlFHN25SdHlCM0greTEvZmp0aUtFejhuaXcyeXV6bHVFMldB?=
 =?utf-8?B?T1d3ZVg2bWZBM0RLcnZRSklWVmJCVkpIMDZKZ2hsTXBsc2s4eE9pcStQSzE5?=
 =?utf-8?B?UGIrL3VMUmJielZ1cEo3dGMwZGlwRFZwdkpTcHhlWHFJNmpSVCtybnBRaHlE?=
 =?utf-8?B?N1Evazl0RWcveGdMeGRWRG1wUVJXSnUxbDJOTWl4RGUrRm9ZdHpLZ0wrdzk2?=
 =?utf-8?B?WnY1V1hhYmpFK280b3J1cnJpWXpaOTdXYnRFbGZpVHdtbnRaM1dITGZ5VVY3?=
 =?utf-8?B?RzFzcGVic01Yc041NVFrRFJ6Vi92YW5OSVdDd0RlcVBsVm5BamE1UWxTOGd5?=
 =?utf-8?B?TVMvSGJBdW5XVUFsL3RTNUlsMllvU0hKejVnRm53VWtRN2hGaDBOMFJ0SnZJ?=
 =?utf-8?B?VUV3SWNVMGpWNXhVWEdtMVlvWUVBWDdYU01PSFVXSmk0bXkrRWZjTEpPV09t?=
 =?utf-8?B?Q2VCa0k5NEhHV3pkRFIzR25xMVh5eWtlZWhFN0l6QUxLRDJnNjBwNFlMamFQ?=
 =?utf-8?B?MlI4cXBzNnpmMEhIMjYzSlR2NFQzSVh2eFdQcllabGYrb2FxejhYQk5oMjk0?=
 =?utf-8?B?NjlhN1c3ZDFidzZTR2ptVzFybktYTndTbTB6bGhsMlBTZDhOZ0UzTzNLbElD?=
 =?utf-8?B?bnFMVnd4OE9iTTU3YjYyWE1GRWtCeVBJR2hQQVppVGpxMk1YZWhXbGRUODho?=
 =?utf-8?B?WVFzTDNySlMrTVJPWU8rSG42K0lldzAyQzh1ZllZbjJvK3BCR2ZaeHJBYkFm?=
 =?utf-8?B?NUxmbnUvRlR2cjFiNmE5empkNGxFYUhadUQ2WDBEZi9acW5QeW5Hc05RcmZ5?=
 =?utf-8?B?ZVhWRHhWalZ6YlhLNDVndjVPQTF0REphd0JPbi9qSEZ2WFk4RUlXYUhlVTBv?=
 =?utf-8?B?NXpDMjIyamdXbEN3K1pwclF1Y3g0bW50OTl6dXpTMm5aQWUwemhCcWtML2lQ?=
 =?utf-8?B?SEsxVFUzdTE0MW00NldKV3NOSm5xU3RaUGxXbmRYQlRWbWhGTEI2cExGV0Ju?=
 =?utf-8?B?WGZWbDhUSWpLdDJGQXY0SHNDSzNOZ1QySUxHRzNwZW9xOElINDh5NXh0Tkdw?=
 =?utf-8?B?Y3JsMGlqU09Cbm0vY05sc2dWQnczdUZjcmZzamI1TXZFZTZrZ1hzUUkvOHFn?=
 =?utf-8?Q?ImWHmqGENSakJUBn+ysQ7Gi3Ih/DHsNj?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(1800799024)(7416014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Dec 2024 11:59:34.2278
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c1ceca26-e7a5-45de-b21e-08dd19db4774
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000EDD1.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8642



On 11/12/2024 12:11, Luca Fancellu wrote:
> 
> 
> From: Penny Zheng 
> 
> If the Xen heap is statically configured in Device Tree, its size is
> definite, so only the defined memory shall be given to the boot
> allocator. Have a check where init_domheap_pages() is called
> which takes into account if static heap feature is used.
> 
> Extract static_heap flag from init data bootinfo, as it will be needed
> after destroying the init data section, rename it to using_static_heap
> and use it to tell whether the Xen static heap feature is enabled.
> 
> Signed-off-by: Penny Zheng 
> Signed-off-by: Wei Chen 
> Signed-off-by: Luca Fancellu 
> Reviewed-by: Jan Beulich  # common

[...]

> +#ifdef CONFIG_STATIC_MEMORY
> +extern bool using_static_heap;
> +#else
> +#define using_static_heap false
> +#endif
Why?

Static heap feature is not protected by CONFIG_STATIC_MEMORY today, so you would introduce a silent regression
(i.e. without config enabled, property would be ignored and there would be no static heap with no error message).

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 12:19:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 12:19:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854710.1267842 (Exim 4.92)
	(envelope-from )
	id 1tLLgQ-0001XP-UC; Wed, 11 Dec 2024 12:19:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854710.1267842; Wed, 11 Dec 2024 12: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 1tLLgQ-0001XI-RR; Wed, 11 Dec 2024 12:19:14 +0000
Received: by outflank-mailman (input) for mailman id 854710;
 Wed, 11 Dec 2024 12:19: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 1tLLgP-0001XC-3d
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 12:19:13 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 (mail-db8eur05on2061d.outbound.protection.outlook.com
 [2a01:111:f403:2614::61d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2090fbf8-b7ba-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 13:19:11 +0100 (CET)
Received: from DU7P189CA0013.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:552::18)
 by DBBPR08MB5996.eurprd08.prod.outlook.com (2603:10a6:10:201::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.15; Wed, 11 Dec
 2024 12:19:08 +0000
Received: from DB3PEPF0000885C.eurprd02.prod.outlook.com
 (2603:10a6:10:552:cafe::e9) by DU7P189CA0013.outlook.office365.com
 (2603:10a6:10:552::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.15 via Frontend Transport; Wed,
 11 Dec 2024 12:19:08 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DB3PEPF0000885C.mail.protection.outlook.com (10.167.242.7) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.15
 via Frontend Transport; Wed, 11 Dec 2024 12:19:06 +0000
Received: ("Tessian outbound 2d228e31de9a:v524");
 Wed, 11 Dec 2024 12:19:06 +0000
Received: from L948dd1a0abef.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 DE5BF4EF-BCC0-4AC8-8732-DB6C76BEE37D.1; 
 Wed, 11 Dec 2024 12:18:59 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 L948dd1a0abef.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 11 Dec 2024 12:18:59 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21)
 by AS8PR08MB8111.eurprd08.prod.outlook.com (2603:10a6:20b:54d::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.15; Wed, 11 Dec
 2024 12:18:57 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632%5]) with mapi id 15.20.8251.008; Wed, 11 Dec 2024
 12:18: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: 2090fbf8-b7ba-11ef-a0d5-8be0dac302b0
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=ZW5YPIatvUXRYRzrF5uWoAvZE04BmUR96A+gfNUpmxqY79r4DgB/3cXUAinwNY0B/herJ08ce0JOPrLezqKJJ61b+/Z7moK5asMxjzjzoo2hDi2SQRKRJThSdKtOLHrbvcpzdrKZF7NoTAIOUdLY/pzGb1eCmhYmUo0dk3pLMDbmr1jopKkrTDg52T04oxa46M/qILmRzhBQuD5FbLR4AsUxvrTzse/yQJFU2QqoWENYvQeq3hrGw0SVAdE5OHRFOIlD9N/p9aL4apaCnaxNO5Pl9r3Z1ZdT1uFxbfi+JIV+7N469YPr3xeFkes87yCMoBQnxsbie0rG1iTWSfM19g==
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=tNX26RZp2IJJcVJeS8hXI8ZhhvBhOwf+/QnOaB9Ck4Y=;
 b=jOj9PSfV08w39NmU+Ez1EjfRBvnVP4khVGhBbEDn3cMV/rkYMimDzHwKD9Vqt6hybxT61RMI5+LI46opTB7Q6eVZFy8ErlHXPzBaaT67YFYi/qQC14VZ5xvEcbcYc0wuISJr7vJDk5J1KNSUk3T1l6jAaWSbYl/usiOpxKrGYalIWJmt8YFuHixUD92/pkjIp6msxDgxSXwzmc7t5k4l8yAJWNyTukNa6tgcLUK1HFTqtPbc+p2hJcmuAB1rLCk46RJNT41vHk130BrlnttVlbEyhmVoPU4rmOPbs2/WRt0JWJI/yJNwoOdnviVfdsbZKNHqFchPAxv+B+vD+q0AjA==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=tNX26RZp2IJJcVJeS8hXI8ZhhvBhOwf+/QnOaB9Ck4Y=;
 b=eTP9ezwBhpHBjjfjdK8FPwfk/DqXvCEdNEMFc7XaZ/5jmwUPxOgsdUIcy0czLoh/ntOmZGycUOdH6O4duhT+l7Zlhp/IWaEandEPfLRS9oWMnmWx3eibOVy3eUnwNxzGMhuy6NdfJqPMsEqzZfgeb+B7+lFYJGIfOxxc906/CSA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 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
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: d128d359b7199913
X-TessianGatewayMetadata: 93+zrbEsSL+hyhhikeWk4ebkuNDv2FYHp15K1WFvYkrpsTqnym2+eE8w56Ff59iNqG6UrxL31CS+e40MurOlkyN95sBK1NGYlxdo5XtBmfSd3GuyuIOzz1FAtWv4EFIhS6CERFdb6vp2oLg08uuPi7jXkAgmIhok0DDJcODFsVU=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rHTUf1a6Zd9DxsVv14+AN1SjdPWn2tM+01LeZlHbS4DYYM8T4UY/eg0y/LyLU3nbm1A3GKwe9rDtpJznwwO3v8FQ0kHOOzDzyYYRTB29ryYx7IcEBqSVRTfci35NNQeaka6spqu2BDyJiDdAGR7Oq1iD09ZPFqQGez4YXl0VI95ovtNmwv3nF/g8xuDueEmAvbjNGq/ucCMNxCIRpDksCSmrIZ2iq2n6rzskxab9VRHblQHW3ckkGQyibxopHIL6mwPRq+zZ18WObo72+v4WqO3w1TtQZhmhXDI5/GyUBgJB7k24+ELA3LjOiP1TWRPb0+2ngAKkiLEQyNQmaGIglg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=tNX26RZp2IJJcVJeS8hXI8ZhhvBhOwf+/QnOaB9Ck4Y=;
 b=j2Dpbt/E2VXnddY4zsyPp018oMdWagIDPoKLncaMbyhPByo/zS2pFqvnNn5T/IouQl7nHZvybxouK5NiwGHto5I5MiL+tKwuLm9Gak5lVUFiITmBWPeXTsyBXi3GeFly7HiN+on8X54my+amTS0nlTrYTmdRl1ErI3U1w8kJYL0zNKMdVqFlbIpfG1mgUo9N0uTcP75Zym5raCqvtg6CAMV372SaUwXF0mAXOuma0tbNZnbqKyZ0+9ErMbJgM7wWck52/2V2GUdwhR9gaMZx/zvstKUEbdBsGt3ozP2aw0wS+WzoMkoxctbXhan4pZLImefXSumWKld55hxnCG5k6A==
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=tNX26RZp2IJJcVJeS8hXI8ZhhvBhOwf+/QnOaB9Ck4Y=;
 b=eTP9ezwBhpHBjjfjdK8FPwfk/DqXvCEdNEMFc7XaZ/5jmwUPxOgsdUIcy0czLoh/ntOmZGycUOdH6O4duhT+l7Zlhp/IWaEandEPfLRS9oWMnmWx3eibOVy3eUnwNxzGMhuy6NdfJqPMsEqzZfgeb+B7+lFYJGIfOxxc906/CSA=
From: Luca Fancellu 
To: Michal Orzel 
CC: "xen-devel@lists.xenproject.org" , Penny
 Zheng , Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Volodymyr Babchuk , Andrew Cooper
	, Jan Beulich , Wei Chen
	
Subject: Re: [PATCH v5] xen/arm: Check for Static Heap feature when freeing
 resources
Thread-Topic: [PATCH v5] xen/arm: Check for Static Heap feature when freeing
 resources
Thread-Index: AQHbS72LrOmoHoF88U+ox0p78LJ4nbLg8LeAgAAFXAA=
Date: Wed, 11 Dec 2024 12:18:56 +0000
Message-ID: <53D4B47C-5411-4F6A-ACDE-A183E830CDD7@arm.com>
References: <20241211111146.2827727-1-luca.fancellu@arm.com>
 <4dfbf14e-25b2-4d16-9323-b711e7e29752@amd.com>
In-Reply-To: <4dfbf14e-25b2-4d16-9323-b711e7e29752@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DBAPR08MB5798:EE_|AS8PR08MB8111:EE_|DB3PEPF0000885C:EE_|DBBPR08MB5996:EE_
X-MS-Office365-Filtering-Correlation-Id: 3a81f980-e1b4-404b-58a1-08dd19de025f
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|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?V3M4U251YlRCUHhnbjJmbmR2bVdmT0RWV1luNUhEVDNFNE51MWVXTUhwaDlo?=
 =?utf-8?B?bndQZkdpRmxHUk9rdjBwTithM21SdDIyd3Z0Z3F5ZGF3VDhGblJLS2JoaU85?=
 =?utf-8?B?RjhVVFBnNkhXQnBZVFBKNlNHSVN6Uit0WnZ0SFlYakdmaVFVTlM2YmlIVTYz?=
 =?utf-8?B?LzFoQ1FNbTlJcHJTWWVJem1sdUhtaWt0Yi96SHd6dWl3YmkxMTlmVDY2aTlS?=
 =?utf-8?B?YzFjQWlMTWxhYStYZnNpeTVCd20yOFhyRTYyUkFrbVFwYXVlbWJDTlVBWG1U?=
 =?utf-8?B?S1lTdytrYmV2NDJsc2dQMytKcXA4U25VbEZ1OS82U3ltVStvZ1o1TncvMDRq?=
 =?utf-8?B?ajhjMEhCRzNhVC9aa2IxQWk5dlVLWVdzMWllMWpJcGhRTW5VY09WdVlFRUxN?=
 =?utf-8?B?ZWtUM0NXRXQ4OEJqcDdCK1BBUnhGNm10ekdER2lIYmZLR3VZTmhKaTNqckc0?=
 =?utf-8?B?N2VaNTZQR2l6WnVtVXdUOGkyc3o2bVVmYk5qWTFDa1FtWlBrUWZYMWNlT0VB?=
 =?utf-8?B?ckpOY2RKaFpqZGczWit4Nm1xUmlSYXVhNi8rNWs3cStEUGpackY3YjR1ZzVO?=
 =?utf-8?B?TVQ5Zk1za0ZCY2RpQ2huamxzTndKaFdONDlhRjRDVzVWL0x6TUV6dkNYNWJM?=
 =?utf-8?B?NVVuUXdaYUU4d2RYQVhqWVJCdE1PUHE4MW5uTXozOXRJdGpsNmRraVNVS3VR?=
 =?utf-8?B?cytzRjl1QWhYc3BKK0tySEpIZkZQUlNKV1BzWDZ3YzhsWEFBcTdYY2I2b2Iy?=
 =?utf-8?B?VFIza3B1SnlLdWhNaHB1RVE4ZW5DRElQalFCRktMczQ5eEtob3o3TktPazlH?=
 =?utf-8?B?WnVYSjJlWHlwbTN5bFlOR0IyVjE3Sm5oZU52RHBvNXZiQmhUa21QSkxsY1ZI?=
 =?utf-8?B?NFNFV1dpbEVUdmtzWUxLYTltVk4wNGJOSXFScnVtcXkvd0NiN1BsR0NRYXRM?=
 =?utf-8?B?MFVydDNIQVdtVjVFditzVDNGV1RJQnYrSmJjdXArMElFS1JJNWkxZ0p0MFVE?=
 =?utf-8?B?V0V2VmtWMUFOMUczNjhBWkRmVVFVR2RTRDh5aXJ4dGpjWS8vZXI2cDBTMzBn?=
 =?utf-8?B?T0RNZWk2Rno5ZVJZb1pzY2ZVbXRoQXJ4NEw0S0N3RW5ZblkwQzVWSTNqM0Y1?=
 =?utf-8?B?ak42aFZOcDFlUmRGMjJLekoxcXFHMmF5cUhiOVpFWC90MGdUYytjeGJUQmVO?=
 =?utf-8?B?R1hSUG9yYUFzQzlkb2M0VUM2ZUtxREViYm5qSWFYc1d0ekhwMTdaNE9iSFVr?=
 =?utf-8?B?Y0Mxb3dTeUFnQXBPZmI1MldTVzRrQmJHSjlONzhzSFZUWGczTG1NSjBHY0NG?=
 =?utf-8?B?UEdNa3AyS3k5WlJjMnFzTjhmZE51MWtBVmJlaHVwNkMwK1l4ZC9LU2Yvam9m?=
 =?utf-8?B?Vzc4V3pDMVFHZ09CN2E4REl6TVpEQTRhTVJmT3BmdndLd2Y3dmRtazJnMGZX?=
 =?utf-8?B?WW40ajB4SFVYS2Z5NlNOME1COGUyN2VKa3BWYnA0MDFnN3hVbmFWSlFFa1ZE?=
 =?utf-8?B?S2JEWkxvNjF6QUJ4eDNpdG15RjdOWDNKYmE4aW1DdmtGcVBYTUJJUkY4YmVs?=
 =?utf-8?B?NGZxR1p4UFFXQlg5Qm90VDNTVVR6VWJ2YmdDM0JMcmk4MURVUmhiaVpjZUlD?=
 =?utf-8?B?aGNqUDNlQkd0ejNIRXRzY2VYZW10ZTlPODA2eko5TGtwakRuNk9rNlhyN2FF?=
 =?utf-8?B?SWJWN0MrS0p2MUpmdVdxRi91Y3kzMmo4TTRTNzM5UjVMTGZvSWo4amJ6YTd1?=
 =?utf-8?B?dkJ4NjgyL3JxSkpwL3A1NmNLRk15MTVZSCsxbkdwZk9abzREdFVqaVN4OVJ2?=
 =?utf-8?B?WTR0OW82Y2RvaytNZ0RyYk5UcENpV3J6M09hUVI1STlWaEVrSnNtQWp2aU45?=
 =?utf-8?B?dDRoVTU2bzZJRnN0UW5MQk1JeFg2bGJwa0pBd2t3dElUS3c9PQ==?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="utf-8"
Content-ID: <5DA124A5EFEF4E42878DBFABA10A9DE7@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB8111
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender:
 ip=[2603:10a6:10:1a6::21];domain=DBAPR08MB5798.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB3PEPF0000885C.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	d7c5193a-ab12-4c08-7a1b-08dd19ddfc63
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|14060799003|376014|35042699022|82310400026|1800799024|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?ekd3bVpvVU1ra2VkdkwwdldkZ2xpNytLc0hUMFNrWU92RFNkSzM1YzBZRi9V?=
 =?utf-8?B?Z1IvRzBtWlp5dlR1RmVtRUhhS3VHd04zR0FsOTFKa3E5bERNUjNseDBWSk54?=
 =?utf-8?B?Y2w0amYveUI0TEdhN3c4ZGNpaHRLRk44Y1YxeUZlTjZQR1JzTU1RTEZvSzJh?=
 =?utf-8?B?ajU1UGtTazRqOGhRM3cwaGc5c0dpT0kvTHNVTDdldUN4cVVZUUFXdGxSMGZo?=
 =?utf-8?B?Z0dmRFFDQ2lTcGh2ZFZZMEJmWXh2TEtzRFRna1B1Y0ltNDF6ZSt2V00xWStu?=
 =?utf-8?B?K0wyVkZjUWZTcC9pQnljRkVzSUhEOGEvSTNabHpsNWE0UE1JdlZqNk13SEJ6?=
 =?utf-8?B?M2dRYnRsYjdBY1lVUmx1Mms5R1lveExReFBZdXhEQm1aNHpwbEZaZk1BbUp1?=
 =?utf-8?B?Skl5c2RiWFFyaTBVS29JaWt5N292ZXh6dXZlaXY5aHBJYXhVemNhNjQwNStJ?=
 =?utf-8?B?T0xET2MzdVVaM3ZrOVM3cWdsSVRVcEQ2WGZoL2hsZjJSVjRVSXQwelZtSXJ6?=
 =?utf-8?B?emlQTzJCby9lQlQ5V3Z6N1RqKzhmTHZRczJBbnQ2Wk9zTThTVDZtOWlVNVdv?=
 =?utf-8?B?QnVTNXZZVmF0SXlkc3BIbUI4OWJKQW1STEpGdkFScVNsN2xuNHB3eVV6RWdX?=
 =?utf-8?B?UzJPRmpvV2VEa0xvSDRrL1dqYWM5K1JwaVVLN1dpYmxrbVFBTDIzUTZEckZN?=
 =?utf-8?B?RUM0cXFpRjB1QVR5T3pTSjBSZkFIOUtTOXpOeFU0SmdJamxHMUgzOVNuYm04?=
 =?utf-8?B?WFBrUG4ybjdFN2ppNzRMV0VQMDlaTnIvZzVSd3o2Y3pHdHQ5Z3QyN0ZCM0FH?=
 =?utf-8?B?a0hTM0pPZ3pDTnBvWFNrbE1sUEJJcmRWZHJzTFdEbVZyZllDNXA0RWViNmhY?=
 =?utf-8?B?YmlKUHhPbVZaUWU4UUZyamNObE14V1JwS3RORGNIbVMwMDhpeEtUMVNEYits?=
 =?utf-8?B?YmVhbytKTDdLc3dQS1d2UUxJZXBqSU5Mb2ZtTkhCZ09Dc1owYndXdnhVVCtW?=
 =?utf-8?B?bnd4MDFMWDdMc3NwUHhHZ0hjSExteDJEdGlMcXM2VzZDV0VRdGwxUm10S0gy?=
 =?utf-8?B?Z3FHSHA4VmxWQ0NWTHlkV20vZXN0d1BORVNWbTFxZVc1dnZSUXBWOWtkK1BP?=
 =?utf-8?B?dldwTUhGMjBQWFJjL2R0OEFQMmlXUHJWK011WExEZmF3MVc5OFNSeGdXNXFL?=
 =?utf-8?B?N0Nuenpwd0NnVEdQa0N5WVhidFRpdjBnRTI5S1FSQ25obEZuY1F1Uy9YTHdp?=
 =?utf-8?B?UlF0NW5rYVp5TFdwZzI4YnRZS09SZ0ZNM09KUmhlalBFRXJaYzJQNUpJaktJ?=
 =?utf-8?B?MWh2bkJKUllIczc3UEJqM3pFMjRReWMzcVRvbW5ISWU4OTA1MGtqZWNWOURW?=
 =?utf-8?B?UTU0REM3TzRlVHB6T21sYksyeVRGV1VMWlNESDd5Y0xqeHIrZ1BoREozTFBo?=
 =?utf-8?B?dXVUdVBMM3VUZmtaTlFQdkFnYlFEOEx6RE1rRGNWVUJHVTVpdk1aS0p6ZU45?=
 =?utf-8?B?dEhpNGluSjd6UnRBa3I1R3VtSTlIME9ZVWNEZkFPcEx2dndRdXdPQ3BhRGF6?=
 =?utf-8?B?OVFoUUZFd2xReTdzbTMyemJOcGZ4SjQ2RkRIM2ZLV0VwQ3ZuNVFRMmpMVm5t?=
 =?utf-8?B?d0RSSE9sS3dkdXZlSDZpWENBd0RTdUZUVG1WMHpHSWpmZ054NklFTUJ0U3JF?=
 =?utf-8?B?LzgvUFdMZUFyVzcza2FXUEQ1czVyNDBScHF2ODVNYWh4cFdWT3NoWjhYSzhJ?=
 =?utf-8?B?TVBkY0RMNEg3N3RvU3dsNnJUUkpJK0ZRTFRlWTRGS3MyaE1qTUdoNm1tenYw?=
 =?utf-8?B?djdvU3paVEdsK0YwcVFwK0NBdkdoYzhXcjQxZkZsMFNDUDYzaUpCSzF3Yno5?=
 =?utf-8?B?V2JFMG4yS0lza0FhSmw3NEVEalMxUXVpUVdZbWdjc1ZlZkprZFRqSlJmQmpa?=
 =?utf-8?B?bHFJT0xINUFvbUtIUWhaL29SRXYyQ1JTTGl0T1VlSmhTWXhFVCsxaTByR1Jh?=
 =?utf-8?B?cnVzMmJOSUZBPT0=?=
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(14060799003)(376014)(35042699022)(82310400026)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Dec 2024 12:19:06.9403
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a81f980-e1b4-404b-58a1-08dd19de025f
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB3PEPF0000885C.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB5996

SGkgTWljaGFsLA0KDQo+IE9uIDExIERlYyAyMDI0LCBhdCAxMTo1OSwgTWljaGFsIE9yemVsIDxt
aWNoYWwub3J6ZWxAYW1kLmNvbT4gd3JvdGU6DQo+IA0KPiANCj4gDQo+IE9uIDExLzEyLzIwMjQg
MTI6MTEsIEx1Y2EgRmFuY2VsbHUgd3JvdGU6DQo+PiANCj4+IA0KPj4gRnJvbTogUGVubnkgWmhl
bmcgPFBlbm55LlpoZW5nQGFybS5jb20+DQo+PiANCj4+IElmIHRoZSBYZW4gaGVhcCBpcyBzdGF0
aWNhbGx5IGNvbmZpZ3VyZWQgaW4gRGV2aWNlIFRyZWUsIGl0cyBzaXplIGlzDQo+PiBkZWZpbml0
ZSwgc28gb25seSB0aGUgZGVmaW5lZCBtZW1vcnkgc2hhbGwgYmUgZ2l2ZW4gdG8gdGhlIGJvb3QN
Cj4+IGFsbG9jYXRvci4gSGF2ZSBhIGNoZWNrIHdoZXJlIGluaXRfZG9taGVhcF9wYWdlcygpIGlz
IGNhbGxlZA0KPj4gd2hpY2ggdGFrZXMgaW50byBhY2NvdW50IGlmIHN0YXRpYyBoZWFwIGZlYXR1
cmUgaXMgdXNlZC4NCj4+IA0KPj4gRXh0cmFjdCBzdGF0aWNfaGVhcCBmbGFnIGZyb20gaW5pdCBk
YXRhIGJvb3RpbmZvLCBhcyBpdCB3aWxsIGJlIG5lZWRlZA0KPj4gYWZ0ZXIgZGVzdHJveWluZyB0
aGUgaW5pdCBkYXRhIHNlY3Rpb24sIHJlbmFtZSBpdCB0byB1c2luZ19zdGF0aWNfaGVhcA0KPj4g
YW5kIHVzZSBpdCB0byB0ZWxsIHdoZXRoZXIgdGhlIFhlbiBzdGF0aWMgaGVhcCBmZWF0dXJlIGlz
IGVuYWJsZWQuDQo+PiANCj4+IFNpZ25lZC1vZmYtYnk6IFBlbm55IFpoZW5nIDxwZW5ueS56aGVu
Z0Bhcm0uY29tPg0KPj4gU2lnbmVkLW9mZi1ieTogV2VpIENoZW4gPHdlaS5jaGVuQGFybS5jb20+
DQo+PiBTaWduZWQtb2ZmLWJ5OiBMdWNhIEZhbmNlbGx1IDxsdWNhLmZhbmNlbGx1QGFybS5jb20+
DQo+PiBSZXZpZXdlZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPiAjIGNvbW1v
bg0KPiANCj4gWy4uLl0NCj4gDQo+PiArI2lmZGVmIENPTkZJR19TVEFUSUNfTUVNT1JZDQo+PiAr
ZXh0ZXJuIGJvb2wgdXNpbmdfc3RhdGljX2hlYXA7DQo+PiArI2Vsc2UNCj4+ICsjZGVmaW5lIHVz
aW5nX3N0YXRpY19oZWFwIGZhbHNlDQo+PiArI2VuZGlmDQo+IFdoeT8NCj4gDQo+IFN0YXRpYyBo
ZWFwIGZlYXR1cmUgaXMgbm90IHByb3RlY3RlZCBieSBDT05GSUdfU1RBVElDX01FTU9SWSB0b2Rh
eSwgc28geW91IHdvdWxkIGludHJvZHVjZSBhIHNpbGVudCByZWdyZXNzaW9uDQo+IChpLmUuIHdp
dGhvdXQgY29uZmlnIGVuYWJsZWQsIHByb3BlcnR5IHdvdWxkIGJlIGlnbm9yZWQgYW5kIHRoZXJl
IHdvdWxkIGJlIG5vIHN0YXRpYyBoZWFwIHdpdGggbm8gZXJyb3IgbWVzc2FnZSkuDQo+IA0KPiB+
TWljaGFsDQo+IA0KDQpUaGFua3MgZm9yIHBvaW50aW5nIHRoYXQgb3V0LCBJIGJhc2VkIG15IGFz
c3VtcHRpb24gb24gdHJ1c3RpbmcgdGhlIGZ1bmN0aW9uYWwgY2hhbmdlcyBmb3JtIHRoZSBvcmln
aW5hbCBwYXRjaCwgbm93IHRoYXQNCnlvdSBwb2ludCBvdXQgdGhhdCwgc2VlbXMgYWxzbyB0byBt
ZSB0aGF0IHRoZSBzdGF0aWMgaGVhcCBmZWF0dXJlIGlzIG5vdCBkZXBlbmRlbnQgb24gdGhlIHN0
YXRpYyBtZW1vcnksIGl0IGNhbiB3b3JrIHdpdGgNCm9yIHdpdGhvdXQgaXQuDQoNCknigJlsbCBk
byB0aGUgY2hhbmdlcyBpbiBvcmRlciB0byBhZGRyZXNzIHRoYXQuDQoNCkNoZWVycywNCkx1Y2EN
Cg0K


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 12:24:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 12:24:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854721.1267851 (Exim 4.92)
	(envelope-from )
	id 1tLLlT-0003OX-Ft; Wed, 11 Dec 2024 12:24:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854721.1267851; Wed, 11 Dec 2024 12:24: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 1tLLlT-0003OQ-DK; Wed, 11 Dec 2024 12:24:27 +0000
Received: by outflank-mailman (input) for mailman id 854721;
 Wed, 11 Dec 2024 12:24: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 1tLLlR-0003OJ-Gu
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 12:24:25 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id da3aa3a1-b7ba-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 13:24:23 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id BC3B0A420DE
 for ; Wed, 11 Dec 2024 12:22:30 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C787C4AF0B
 for ; Wed, 11 Dec 2024 12:24:21 +0000 (UTC)
Received: by mail-lf1-f46.google.com with SMTP id
 2adb3069b0e04-53f22fd6887so3994686e87.2
 for ; Wed, 11 Dec 2024 04:24: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: da3aa3a1-b7ba-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1733919861;
	bh=DsXfp69fj2fRqzzDFgqUyNg8ViPXWlKIo43PfinZuFs=;
	h=References:In-Reply-To:From:Date:Subject:To:Cc:From;
	b=hbBGffLG09YowJve8o2b2lzExQfsrf3VQXWFB8Xtk06XrXMUwu8qfiY9DHU9o1848
	 VrsVvUN/EA7cvw933gACaa9OvZX6sqlLNIq02WNb1asVKkuwUbAFS1EnwzA93i4VZL
	 i6hqVluyEO9kH4saaXyezegM7E3n9Y0Ywd/Yd1ClCB4u95ZrtACPreUzpn094pVniF
	 weqU4p/6AhkK4jc/4tZvsMwG/X49rjFChcSz6Pj/ZJhbS8jEQXOCvAk6ogmNxGmidE
	 26PBXcIvNmFkd2z7ZDu9YX7SWwbd6ldzX1RtpMuc95BFC7YNZ2x6E4++8SPA59AWgf
	 LaSSkWlpcigtQ==
X-Forwarded-Encrypted: i=1; AJvYcCVR85md++qAkWOiNvkOqPNOexO2ppi4MBR7X8Fl4V4VTrShxL5oHqaQnM0wnhaFDHnzslMb7fHdPgU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyltz3Xttml09TkA3Cyw2ybtlGWB6NS/yljunNQc54h9l4u10pY
	KD5HAM36cK5vQMWfEffd99Sx5L9nY85L6UJHXaNjb+wf43IlactBT9c5bmt7PQRjj3COEZ8xtqV
	hk/8t3+cGrUoklSB0vIGfy0eg6tA=
X-Google-Smtp-Source: AGHT+IGGcmOcREgNPBxszaP86ASREHMb1Gbb7UNcEMwpTi1i2aaMzaHU//SFUnwFwNZQnYbltrR5CTAM3YNBIp6px58=
X-Received: by 2002:a05:6512:3d18:b0:53e:398c:bf8f with SMTP id
 2adb3069b0e04-5402a5e5f9cmr849575e87.32.1733919859838; Wed, 11 Dec 2024
 04:24:19 -0800 (PST)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Ard Biesheuvel 
Date: Wed, 11 Dec 2024 13:24:08 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: [REGRESSION] Linux 6.6.64 crashes when booting as PVH domU
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Cc: Jason Andryuk , Stefano Stabellini , 
	Oleksandr Tyshchenko , regressions@lists.linux.dev, 
	xen-devel , 
	=?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 11 Dec 2024 at 12:53, J=C3=BCrgen Gro=C3=9F  wrote=
:
>
> Jason, Ard,
>
> I guess there are some prereq patches missing in stable 6.6.y branch?
>
>
> Juergen
>
> On 11.12.24 12:41, Marek Marczykowski-G=C3=B3recki wrote:
> > Hi,
> >
> > With Linux 6.6.64 I get the following crash on domU boot:
> >
> > (XEN) d5v0 Triple fault - invoking HVM shutdown action 1
> > (XEN) *** Dumping Dom5 vcpu#0 state: ***
> > (XEN) ----[ Xen-4.19.0  x86_64  debug=3Dn  Tainted:  M     ]----
> > (XEN) CPU:    4
> > (XEN) RIP:    0008:[]
> > (XEN) RFLAGS: 0000000000010086   CONTEXT: hvm guest (d5v0)
> > (XEN) rax: ffffffff82b64050   rbx: ffffffffffe00000   rcx: 00000000c000=
0101
> > (XEN) rdx: 0000000000000000   rsi: 0000000003a00038   rdi: 0000000002a9=
bc98
> > (XEN) rbp: 0000000000000000   rsp: 0000000002aa0ce8   r8:  000000000000=
0000
> > (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 000000000000=
0000
> > (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 000000000000=
0000
> > (XEN) r15: 0000000000000000   cr0: 0000000080000011   cr4: 000000000000=
0020
> > (XEN) cr3: 0000000002022000   cr2: 0000000000000000
> > (XEN) fsb: 0000000000000000   gsb: 0000000002a9ccc0   gss: 000000000000=
0000
> > (XEN) ds: 0010   es: 0010   fs: 0000   gs: 0000   ss: 0010   cs: 0008
> >
> > Linux 6.6.63 works fine.
> >
> > Looking at the changes, I suspect one of those:
> >
> >      83d123e27623 x86/pvh: Call C code via the kernel virtual mapping
> >      f662b4a69e1d x86/pvh: Set phys_base when calling xen_prepare_pvh()
> >

The second patch shouldn't have been backported. It is unnecessary,
given that in the old situation, the kernel image needs to be loaded
at a fixed address. And it assumes  that %rbp is set to the physical
load offset, but those patches were not backported.


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 12:30:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 12:30:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854735.1267862 (Exim 4.92)
	(envelope-from )
	id 1tLLr8-0004ts-3l; Wed, 11 Dec 2024 12:30:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854735.1267862; Wed, 11 Dec 2024 12:30: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 1tLLr8-0004tl-0e; Wed, 11 Dec 2024 12:30:18 +0000
Received: by outflank-mailman (input) for mailman id 854735;
 Wed, 11 Dec 2024 12:30: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 1tLLr6-0004tf-0E
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 12:30:16 +0000
Received: from fhigh-b2-smtp.messagingengine.com
 (fhigh-b2-smtp.messagingengine.com [202.12.124.153])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aaf003f6-b7bb-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 13:30:13 +0100 (CET)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 0272C2540260;
 Wed, 11 Dec 2024 07:30:11 -0500 (EST)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-06.internal (MEProxy); Wed, 11 Dec 2024 07:30:12 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 11 Dec 2024 07:30:10 -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: aaf003f6-b7bb-11ef-99a3-01e77a169b0f
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=1733920211;
	 x=1734006611; bh=4bUVCNxlLLsfq6OFY06A5OLQ0L1wV01UZdhndtveAMU=; b=
	I8Eya5twAQM5obhHH7eChwe9cAz2crqW7dupEat7/fDVBRBhKgA2ris/oAlhAwTg
	hA0oDcr5C/zp2YE+xNbNiPS8k8uMnJ8A7gZpiOgFNwMm9VdNRB+LrpYCZv8PQkbQ
	OEUetmNBlLwQ5NGKd5s77RYtKaGAH4w3vppfrq5HjiWJA/rTMz8I/Vm6te2YZtbf
	EPq490v8RUskIQPmm1NLRZ7fTIjKkC+iHLLxYleMGTFrLwa+jYKQZkHHd05sh5MS
	BhMe/a4uDhzg93xqWjQPjxAIKNPguTXtMGzeCqDS9NUlezdo0XYFBy/SuTC5K/dh
	5ll482V9Zt3KgLULvp+lLg==
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=
	1733920211; x=1734006611; bh=4bUVCNxlLLsfq6OFY06A5OLQ0L1wV01UZdh
	ndtveAMU=; b=wLju/yEA8UQY2xaIngAa2kBrRyRCyr7U+FBTlWZ21s3lb20kn/4
	QTliJTUrnYtSj0oNjXXgLq8LDCR8JajtMKPVvuZpX2TUrB3vCGlGDyFawQvaDBvw
	ZbnMgsbbW2dGT6ZiZtJa2jZ/vNoQO1kruOgQh+A8xOtJhWprVjAx8TZ8pdSaRROo
	SqonOm+eMHyhMCSiKbVKWVesGMeUmWw3Cj6PNUCxZhzeKxzOSvwSuJG0KSLrjv3n
	Xds4k9k/kO7j6mUxV0sM9FwPyayrDPvvKzJRfb9Otjq5DuAGYuKMozlrIqyd85B0
	QhDWbH1ZZOK3k+oE6IjYbmlksppmIrYbbwg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrkedtgdegtdcutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr
    tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth
    hsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecu
    hfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrg
    hrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffr
    rghtthgvrhhnpefgudelteefvefhfeehieetleeihfejhfeludevteetkeevtedtvdegue
    etfeejudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm
    pehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsg
    gprhgtphhtthhopeejpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegrrhgusges
    khgvrhhnvghlrdhorhhgpdhrtghpthhtohepjhhgrhhoshhssehsuhhsvgdrtghomhdprh
    gtphhtthhopehjrghnughrhihukhesghhmrghilhdrtghomhdprhgtphhtthhopehsshht
    rggsvghllhhinhhisehkvghrnhgvlhdrohhrghdprhgtphhtthhopeholhgvkhhsrghnug
    hrpghthihshhgthhgvnhhkohesvghprghmrdgtohhmpdhrtghpthhtoheprhgvghhrvghs
    shhiohhnsheslhhishhtshdrlhhinhhugidruggvvhdprhgtphhtthhopeigvghnqdguvg
    hvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Wed, 11 Dec 2024 13:30:08 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Ard Biesheuvel 
Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
	Jason Andryuk ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	regressions@lists.linux.dev,
	xen-devel 
Subject: Re: [REGRESSION] Linux 6.6.64 crashes when booting as PVH domU
Message-ID: 
References: 
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="/VG+ezqUWUhYwfd+"
Content-Disposition: inline
In-Reply-To: 


--/VG+ezqUWUhYwfd+
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 11 Dec 2024 13:30:08 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Ard Biesheuvel 
Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
	Jason Andryuk ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	regressions@lists.linux.dev,
	xen-devel 
Subject: Re: [REGRESSION] Linux 6.6.64 crashes when booting as PVH domU

On Wed, Dec 11, 2024 at 01:24:08PM +0100, Ard Biesheuvel wrote:
> On Wed, 11 Dec 2024 at 12:53, J=C3=BCrgen Gro=C3=9F  wro=
te:
> >
> > Jason, Ard,
> >
> > I guess there are some prereq patches missing in stable 6.6.y branch?
> >
> >
> > Juergen
> >
> > On 11.12.24 12:41, Marek Marczykowski-G=C3=B3recki wrote:
> > > Hi,
> > >
> > > With Linux 6.6.64 I get the following crash on domU boot:
> > >
> > > (XEN) d5v0 Triple fault - invoking HVM shutdown action 1
> > > (XEN) *** Dumping Dom5 vcpu#0 state: ***
> > > (XEN) ----[ Xen-4.19.0  x86_64  debug=3Dn  Tainted:  M     ]----
> > > (XEN) CPU:    4
> > > (XEN) RIP:    0008:[]
> > > (XEN) RFLAGS: 0000000000010086   CONTEXT: hvm guest (d5v0)
> > > (XEN) rax: ffffffff82b64050   rbx: ffffffffffe00000   rcx: 00000000c0=
000101
> > > (XEN) rdx: 0000000000000000   rsi: 0000000003a00038   rdi: 0000000002=
a9bc98
> > > (XEN) rbp: 0000000000000000   rsp: 0000000002aa0ce8   r8:  0000000000=
000000
> > > (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000=
000000
> > > (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000=
000000
> > > (XEN) r15: 0000000000000000   cr0: 0000000080000011   cr4: 0000000000=
000020
> > > (XEN) cr3: 0000000002022000   cr2: 0000000000000000
> > > (XEN) fsb: 0000000000000000   gsb: 0000000002a9ccc0   gss: 0000000000=
000000
> > > (XEN) ds: 0010   es: 0010   fs: 0000   gs: 0000   ss: 0010   cs: 0008
> > >
> > > Linux 6.6.63 works fine.
> > >
> > > Looking at the changes, I suspect one of those:
> > >
> > >      83d123e27623 x86/pvh: Call C code via the kernel virtual mapping
> > >      f662b4a69e1d x86/pvh: Set phys_base when calling xen_prepare_pvh=
()
> > >
>=20
> The second patch shouldn't have been backported. It is unnecessary,
> given that in the old situation, the kernel image needs to be loaded
> at a fixed address. And it assumes  that %rbp is set to the physical
> load offset, but those patches were not backported.

It has this tag:

    Stable-dep-of: e8fbc0d9cab6 ("x86/pvh: Call C code via the kernel virtu=
al mapping")

Does it mean neither of them should be backported?

But then, the e8fbc0d9cab6 has "Fixes:" tag (pointing at very old
commit).

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

--/VG+ezqUWUhYwfd+
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmdZhdEACgkQ24/THMrX
1yyjMQf9FzYK4Yw9Mm1IB6080FxLcOdQKmLoy8zrgu/4DPqQr+eN8jte4FbvsL18
ilp4g8VystkEOyUOA7M6TI54ottRMRdM3KPQ2Cny9LV6SPsq5PKL3DFl5pYaAbgM
BgxJye/H36pS3A7D++w88A37dd7Orc6S9r4xo/VTskL9zAx3eqTeBclA5wazsSJ+
wjOOwGxeDrfrHL+gWXL7P4lEXDSRYZsEa7W90DNqnBuKM0TFSinUeuyP8urI2yDZ
3a81wUDPuLaj3UijeFkp8lGlpBciUzvslgJWNSbp/pbZWoZdwQeZzV3yQIfZAxbw
5CAEDyZinCheMVPTB/jTfKdBb+l7RQ==
=OW2f
-----END PGP SIGNATURE-----

--/VG+ezqUWUhYwfd+--


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 12:36:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 12:36:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854751.1267871 (Exim 4.92)
	(envelope-from )
	id 1tLLxU-0005uq-Nf; Wed, 11 Dec 2024 12:36:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854751.1267871; Wed, 11 Dec 2024 12:36: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 1tLLxU-0005uj-Kz; Wed, 11 Dec 2024 12:36:52 +0000
Received: by outflank-mailman (input) for mailman id 854751;
 Wed, 11 Dec 2024 12:36: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 1tLLxT-0005ud-HK
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 12:36:51 +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 9639f611-b7bc-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 13:36:48 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733920596953812.0479903054511;
 Wed, 11 Dec 2024 04: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: 9639f611-b7bc-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1733920600; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=Ge4yvzxj5bzSiib1TlJtpzhNOwhaFDZbPWOX7x1IrurJKqlZY8leypeUA0aA6YlxRqvA17SggoETAFzfWhcIVQLwYO4lvpYLaRw3bOauumIltPbS1skSGM1n5hyXuBeEiWqTw92oLpuNIqNd3YKQne23GpGgTgvVtMjLAjeTjFU=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733920600; 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=taiWLPkkd1RGLNZZfH7WpU7OdhKq56EX7eDXFXwXVlI=; 
	b=d3yIAPXRYnKCvpdWkA+IbcldfLdzCrVXSUMWVqH1Lyu65scAxKG6tTFg783+zOyNk2+2kTc1Wity9Yf5/eRYq06mtdE5s8IhMX63l1KurqLhO0eeyn3Xt/hIk7ilXNQ0z8jOFqGz5H1GnE5mM8ep6Pgqs51dAhqjn+3nS6wX52E=
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=1733920600;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=taiWLPkkd1RGLNZZfH7WpU7OdhKq56EX7eDXFXwXVlI=;
	b=jtdfx+MxVYfpkJKLnH8ZQP7sfXZSdBSHrjzQN86fYba6ATgJP9VvNjsPStmrRApx
	iK6yOsW5wEjrBVbIIpASajRudAYwohhnItqSVXtGHRlQKObtcJYepdyHY0/Bq74Ljd+
	cPi0Kyg4D0NBbnrPmSkRzgwYccVPXBSFneAayhRc=
Message-ID: <71d62f74-91d9-498f-80a7-d0dc01fb51da@apertussolutions.com>
Date: Wed, 11 Dec 2024 07:36:35 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 06/15] x86/hyperlaunch: introduce the domain builder
To: Jan Beulich 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-7-dpsmith@apertussolutions.com>
 
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 12/2/24 05:10, Jan Beulich wrote:
> On 23.11.2024 19:20, Daniel P. Smith wrote:
>> Introduce the domain builder which is capable of consuming a device tree as the
>> first boot module. If it finds a device tree as the first boot module, it will
>> set its type to BOOTMOD_FDT. This change only detects the boot module and
>> continues to boot with slight change to the boot convention that the dom0
>> kernel is no longer first boot module but is the second.
>>
>> No functional change intended.
>>
>> Signed-off-by: Daniel P. Smith 
>> ---
>>   xen/arch/x86/Makefile                    |  2 +
>>   xen/arch/x86/domain_builder/Makefile     |  3 ++
>>   xen/arch/x86/domain_builder/core.c       | 55 ++++++++++++++++++++++++
>>   xen/arch/x86/domain_builder/fdt.c        | 38 ++++++++++++++++
>>   xen/arch/x86/domain_builder/fdt.h        | 21 +++++++++
>>   xen/arch/x86/include/asm/bootinfo.h      |  3 ++
>>   xen/arch/x86/include/asm/domainbuilder.h |  8 ++++
>>   xen/arch/x86/setup.c                     | 18 +++++---
>>   8 files changed, 142 insertions(+), 6 deletions(-)
>>   create mode 100644 xen/arch/x86/domain_builder/Makefile
>>   create mode 100644 xen/arch/x86/domain_builder/core.c
>>   create mode 100644 xen/arch/x86/domain_builder/fdt.c
>>   create mode 100644 xen/arch/x86/domain_builder/fdt.h
> 
> As I'm sure I indicated before: Dashes instead of underscores please in new
> files' names.
> 
>>   create mode 100644 xen/arch/x86/include/asm/domainbuilder.h
> 
> Why is there no separator in this file's name?

Name was getting a bit long, but can add separator if desired.

> Similar question as on an earlier patch: Why is all of this x86-specific, when
> a goal was generalization?
> 
>> --- /dev/null
>> +++ b/xen/arch/x86/domain_builder/core.c
>> @@ -0,0 +1,55 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Copyright (C) 2024, Apertus Solutions, LLC
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +#include "fdt.h"
>> +
>> +void __init builder_init(struct boot_info *bi)
>> +{
>> +    if ( IS_ENABLED(CONFIG_DOMAIN_BUILDER) )
>> +    {
>> +        int ret;
>> +
>> +        switch ( ret = has_hyperlaunch_fdt(bi) )
>> +        {
>> +        case 0:
>> +            printk("Hyperlaunch device tree detected\n");
>> +            bi->hyperlaunch_enabled = true;
>> +            bi->mods[0].type = BOOTMOD_FDT;
>> +            break;
>> +        case -EINVAL:
>> +            printk("Hyperlaunch device tree was not detected\n");
>> +            bi->hyperlaunch_enabled = false;
>> +            break;
>> +        case -ENOENT:
>> +            fallthrough;
> 
> No need for this.

I thought MISRA called for explicit fallthrough?

>> +        case -ENODATA:
>> +            printk("Device tree found, but not hyperlaunch (%d)\n", ret);
>> +            bi->hyperlaunch_enabled = false;
>> +            bi->mods[0].type = BOOTMOD_FDT;
>> +            break;
>> +        default:
>> +            printk("Unknown error (%d) occured checking for hyperlaunch device tree\n",
>> +                   ret);
>> +            bi->hyperlaunch_enabled = false;
>> +        }
> 
> Nit: Misra demands "break" at the end of default as well.

ack.

> Blank lines between non-fallthrough blocks would also be nice.

sure.

>> +
> 
> Nit: Excess blank line.

ack.

>> --- /dev/null
>> +++ b/xen/arch/x86/domain_builder/fdt.c
>> @@ -0,0 +1,38 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Copyright (C) 2024, Apertus Solutions, LLC
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include  /* required for asm/setup.h */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "fdt.h"
>> +
>> +int __init has_hyperlaunch_fdt(struct boot_info *bi)
>> +{
>> +    int ret = 0;
>> +    void *fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);
> 
> const void *?

Hmm. it should be.

>> @@ -1277,9 +1278,12 @@ void asmlinkage __init noreturn __start_xen(void)
>>                  bi->nr_modules);
>>       }
>>   
>> -    /* Dom0 kernel is always first */
>> -    bi->mods[0].type = BOOTMOD_KERNEL;
>> -    bi->domains[0].kernel = &bi->mods[0];
>> +    builder_init(bi);
>> +
>> +    /* Find first unknown boot module to use as Dom0 kernel */
>> +    i = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
>> +    bi->mods[i].type = BOOTMOD_KERNEL;
>> +    bi->domains[0].kernel = &bi->mods[i];
> 
> Better latch the result here into a separate local variable, for use ...
> 
>> @@ -1466,8 +1470,9 @@ void asmlinkage __init noreturn __start_xen(void)
>>           xen->size  = __2M_rwdata_end - _stext;
>>       }
>>   
>> -    bi->mods[0].headroom =
>> -        bzimage_headroom(bootstrap_map_bm(&bi->mods[0]), bi->mods[0].size);
>> +    i = first_boot_module_index(bi, BOOTMOD_KERNEL);
>> +    bi->mods[i].headroom =
>> +        bzimage_headroom(bootstrap_map_bm(&bi->mods[i]), bi->mods[i].size);
>>       bootstrap_unmap();
>>   
>>   #ifndef highmem_start
>> @@ -1591,7 +1596,8 @@ void asmlinkage __init noreturn __start_xen(void)
>>   #endif
>>       }
>>   
>> -    if ( bi->mods[0].headroom && !bi->mods[0].relocated )
>> +    i = first_boot_module_index(bi, BOOTMOD_KERNEL);
>> +    if ( bi->mods[i].headroom && !bi->mods[0].relocated )
>>           panic("Not enough memory to relocate the dom0 kernel image\n");
>>       for ( i = 0; i < bi->nr_modules; ++i )
>>       {
> 
> ... in these two places?

I don't know if a local variable is need. I assume your suggestion is to 
drop the first_boot_module_index() call, but thinking about it, not sure 
why I kept the walk. A direct use of bi->domains[0].kernel could be used 
without the intermediate variable while removing the call.

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 12:38:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 12:38:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854761.1267881 (Exim 4.92)
	(envelope-from )
	id 1tLLyl-0006RI-0s; Wed, 11 Dec 2024 12:38:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854761.1267881; Wed, 11 Dec 2024 12:38:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLLyk-0006RB-UZ; Wed, 11 Dec 2024 12:38:10 +0000
Received: by outflank-mailman (input) for mailman id 854761;
 Wed, 11 Dec 2024 12:38: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 1tLLyk-0006QZ-Ai
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 12:38:10 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c5d643fd-b7bc-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 13:38:08 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 13F5F5C66F0
 for ; Wed, 11 Dec 2024 12:37:24 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 402A2C4CEE3
 for ; Wed, 11 Dec 2024 12:38:06 +0000 (UTC)
Received: by mail-lj1-f174.google.com with SMTP id
 38308e7fff4ca-3022598e213so28209941fa.0
 for ; Wed, 11 Dec 2024 04:38: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: c5d643fd-b7bc-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1733920686;
	bh=6A/dn3jhCarDUX1HaOcKFvjQuIdb9vSoHfumK815F90=;
	h=References:In-Reply-To:From:Date:Subject:To:Cc:From;
	b=q4DSz1GLCbO8+y0aP5+TQn+JjZKD3ctl3GQzExXHYIGHidHL7mAXgTvSucnbISs3A
	 uLFE4RwEqMyU3BH2GzAeSvtYS3n8goBVm08DdxqEhH2bf6HkTHTeiSe3DkrplF7F9z
	 CB4DlVQmKTKRyWVPwAomyA63vGwAa+y0GZ9oOZrz7WkCRVWKQS7JTib8/P6sEc4dtS
	 s82zbC5xFXIVoDQsiAZJZtjNmqcw71X+IQ2KFj77WCggvT5zhBz20C3QtKU/bjDmax
	 /blejr9s+lXe7vJEBZAI9JCOtkiwnOV8fiKXhEs+yGs+dfZcYWazx1LGfnTuPAYGp1
	 QCLHJY2AI5gHA==
X-Forwarded-Encrypted: i=1; AJvYcCUbd2GA2n3AZd3DJd7dzbsqVBUIOngY/zH0++N+ZfCL301WPHv5TNQwujFtkgWQxr5dgKlirW36ltM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywd8qf4SYVkDUa3ZuLfufDgVCmPsHtzdzNy/MI0vt/GNNa5r7dT
	xxwYRJ4ZJrJzOTgA7vxocsbn90Jwj1Z9MU9q6YLbOE8KtXgylV3FLwtnb6SDH6qm+dxil7yl2B8
	jEUmiKtgWxsgjKzpKY04R+KHfVbc=
X-Google-Smtp-Source: AGHT+IG209dne0Tl3T71dc7VTtvkNHUQ3p5KRJK5FqQ+uJfsXMe55P5rmszraCwAe9lOAQ+gFW57du1YR1C48KbWC1I=
X-Received: by 2002:a2e:bc25:0:b0:300:1aa5:4938 with SMTP id
 38308e7fff4ca-30240cfb89amr8571701fa.18.1733920684444; Wed, 11 Dec 2024
 04:38:04 -0800 (PST)
MIME-Version: 1.0
References:  
  
In-Reply-To: 
From: Ard Biesheuvel 
Date: Wed, 11 Dec 2024 13:37:52 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: [REGRESSION] Linux 6.6.64 crashes when booting as PVH domU
To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	Greg Kroah-Hartman 
Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , 
	Jason Andryuk , Stefano Stabellini , 
	Oleksandr Tyshchenko , regressions@lists.linux.dev, 
	xen-devel 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

(cc Greg)

On Wed, 11 Dec 2024 at 13:30, Marek Marczykowski-G=C3=B3recki
 wrote:
>
> On Wed, Dec 11, 2024 at 01:24:08PM +0100, Ard Biesheuvel wrote:
> > On Wed, 11 Dec 2024 at 12:53, J=C3=BCrgen Gro=C3=9F  w=
rote:
> > >
> > > Jason, Ard,
> > >
> > > I guess there are some prereq patches missing in stable 6.6.y branch?
> > >
> > >
> > > Juergen
> > >
> > > On 11.12.24 12:41, Marek Marczykowski-G=C3=B3recki wrote:
> > > > Hi,
> > > >
> > > > With Linux 6.6.64 I get the following crash on domU boot:
> > > >
> > > > (XEN) d5v0 Triple fault - invoking HVM shutdown action 1
> > > > (XEN) *** Dumping Dom5 vcpu#0 state: ***
> > > > (XEN) ----[ Xen-4.19.0  x86_64  debug=3Dn  Tainted:  M     ]----
...
> > > >
> > > > Linux 6.6.63 works fine.
> > > >
> > > > Looking at the changes, I suspect one of those:
> > > >
> > > >      83d123e27623 x86/pvh: Call C code via the kernel virtual mappi=
ng
> > > >      f662b4a69e1d x86/pvh: Set phys_base when calling xen_prepare_p=
vh()
> > > >
> >
> > The second patch shouldn't have been backported. It is unnecessary,
> > given that in the old situation, the kernel image needs to be loaded
> > at a fixed address. And it assumes  that %rbp is set to the physical
> > load offset, but those patches were not backported.
>
> It has this tag:
>
>     Stable-dep-of: e8fbc0d9cab6 ("x86/pvh: Call C code via the kernel vir=
tual mapping")
>

That was added by the stable maintainers - someone grabbed a patch
from the middle of an unrelated series to make e8fbc0d9cab6 apply
without lexical conflicts.

> Does it mean neither of them should be backported?
>
> But then, the e8fbc0d9cab6 has "Fixes:" tag (pointing at very old
> commit).
>

If someone thinks e8fbc0d9cab6 should be backported, they should
rebase it onto v6.6.y, not backport random other patches until
git-apply stops complaining. And ideally, someone would build and boot
the result to check whether it works.

For now, it would be better to revert both.


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 12:50:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 12:50:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854776.1267891 (Exim 4.92)
	(envelope-from )
	id 1tLMA8-0000PU-0e; Wed, 11 Dec 2024 12:49:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854776.1267891; Wed, 11 Dec 2024 12:49: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 1tLMA7-0000PN-UM; Wed, 11 Dec 2024 12:49:55 +0000
Received: by outflank-mailman (input) for mailman id 854776;
 Wed, 11 Dec 2024 12:49: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 1tLMA6-0000PF-R4
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 12:49:54 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 69536bbd-b7be-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 13:49:52 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733921385340942.4450878369379;
 Wed, 11 Dec 2024 04:49: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: 69536bbd-b7be-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1733921387; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=QmGQxh8A+hpECqzG4Rgrp+hLqIvAtC+hCt+skPtGEOVzCYrNpL4xKVMdtYhRQ5oxEiSvmItsoyI8lmFYenPciaitH4ert1LchoM2aCGvQFentuNQOIjwSl3OcoZPU2GGsrIqwHp6U6kjM5whneDR8N68RTwIWv3hrKm0drudYvc=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733921387; 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=kK0++IHAxwDlZnYWDMNx2hSGO3o1dKumlrnPUHek3ZM=; 
	b=L2TresWJl26OzM+AkMB2qc0E/1A15AsRL8OY7qKHv7TRKsJNko8MnjWdUj+28RM1FEPwHyI9/88+jj1Xuvqaa1Q0yvhwHB0XVyTc70nDfye9a+l90W8X56PWSYbcIuJs7rfFsBC/19uD9flXK060T04JZW28MdxO7n+gYnKqEKE=
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=1733921387;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=kK0++IHAxwDlZnYWDMNx2hSGO3o1dKumlrnPUHek3ZM=;
	b=tyv57vFnTZBJUDGL2DfugYh8wa+o0yRZvQmkLUz3JHsF2kYARfW3ilaS2rCS4WBA
	G6ywCoD4niacKoU4f/byvI+DsjrJoQ+lrSIXU0XvNhZASOOenXMQt8ToNRh+2RWOBTe
	fHsycak8C3ZaAO/uJJs+PrHP0+3UIm+DVn1Iws+s=
Message-ID: <819cab1c-a7b7-4898-9f6b-bd383b7cbd31@apertussolutions.com>
Date: Wed, 11 Dec 2024 07:49:43 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 07/15] x86/hyperlaunch: initial support for hyperlaunch
 device tree
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com,
 Jan Beulich , Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-8-dpsmith@apertussolutions.com>
 <6843e4c8-1b72-4b3f-be45-1854051dbd40@amd.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <6843e4c8-1b72-4b3f-be45-1854051dbd40@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

On 11/25/24 15:11, Jason Andryuk wrote:
> On 2024-11-23 13:20, Daniel P. Smith wrote:
>> Add the ability to detect both a formal hyperlaunch device tree or a 
>> dom0less
>> device tree. If the hyperlaunch device tree is found, then count the 
>> number of
>> domain entries, reporting if more than one is found.
>>
>> Signed-off-by: Daniel P. Smith 
>> ---
>>   xen/arch/x86/domain_builder/core.c  | 14 +++++++
>>   xen/arch/x86/domain_builder/fdt.c   | 64 ++++++++++++++++++++++++++++-
>>   xen/arch/x86/domain_builder/fdt.h   |  5 +++
>>   xen/arch/x86/include/asm/bootinfo.h |  1 +
>>   4 files changed, 83 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/x86/domain_builder/core.c b/xen/arch/x86/ 
>> domain_builder/core.c
>> index 211359895d84..a80f3711c306 100644
>> --- a/xen/arch/x86/domain_builder/core.c
>> +++ b/xen/arch/x86/domain_builder/core.c
>> @@ -40,7 +40,21 @@ void __init builder_init(struct boot_info *bi)
>>                      ret);
>>               bi->hyperlaunch_enabled = false;
>>           }
>> +    }
>> +
>> +    if ( bi->hyperlaunch_enabled )
>> +    {
>> +        int ret;
>> +
>> +        printk(XENLOG_INFO "Hyperlauch configuration:\n");
> 
> Hyperlaunch

Ack.

>> +        if ( (ret = walk_hyperlaunch_fdt(bi)) < 0 )
>> +        {
>> +            printk(XENLOG_INFO "  walk of device tree failed (%d)\n", 
>> ret);
>> +            bi->hyperlaunch_enabled = false;
>> +            return;
>> +        }
>> +        printk(XENLOG_INFO "  Number of domains: %d\n", bi->nr_domains);
>>       }
>>   }
>> diff --git a/xen/arch/x86/domain_builder/fdt.c b/xen/arch/x86/ 
>> domain_builder/fdt.c
>> index 3f9dda8c34c3..ff1ba58b6907 100644
>> --- a/xen/arch/x86/domain_builder/fdt.c
>> +++ b/xen/arch/x86/domain_builder/fdt.c
> 
>> +int __init walk_hyperlaunch_fdt(struct boot_info *bi)
>> +{
>> +    int ret = 0, hv_node, node;
>> +    void *fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);
>> +
>> +    if ( unlikely(!fdt) )
>> +        return -EINVAL;
>> +
>> +    hv_node = find_hyperlaunch_node(fdt);
>> +    if ( hv_node < 0 )
>> +    {
>> +        ret = hv_node;
>> +        goto err_out;
>> +    }
>> +
>> +    fdt_for_each_subnode(node, fdt, hv_node)
>> +    {
>> +        ret = fdt_node_check_compatible(fdt, node, "xen,domain");
>> +        if ( ret == 0 )
>> +            bi->nr_domains++;
>> +    }
>> +
>> +    /* Until multi-domain construction is added, throw an error */
>> +    if ( !bi->nr_domains || bi->nr_domains > 1 )
>> +        printk(XENLOG_ERR "Hyperlaunch only supports dom0 
>> construction\n");
> 
> You continue execution - is that intended?  It'll take the next module 
> as the kernel and try to boot?  Would you rather panic?

Yes, it was intended, and as of this commit, it will use the next module 
as the kernel. That is the boot convention at this point. In this 
scenario, the system was given a valid HL device tree that happen to 
have multiple domains defined in it. At this point in the series, a 
domain definition literally has zero effect on the boot process, so 
there is no reason to panic.

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 12:56:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 12:56:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854787.1267902 (Exim 4.92)
	(envelope-from )
	id 1tLMG6-0002Sf-L1; Wed, 11 Dec 2024 12:56:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854787.1267902; Wed, 11 Dec 2024 12:56: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 1tLMG6-0002SY-Ha; Wed, 11 Dec 2024 12:56:06 +0000
Received: by outflank-mailman (input) for mailman id 854787;
 Wed, 11 Dec 2024 12:56: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 1tLMG4-0002S9-Ni
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 12:56:04 +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 45555380-b7bf-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 13:56:01 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733921754815984.1324331564064;
 Wed, 11 Dec 2024 04:55: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: 45555380-b7bf-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1733921756; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=Lsl2ylJLN41Tku0prPda7vepjA4owF1bl6PyPeFIFS4+UK17HBb/W0zKhBRqi7djk+DK9/sUy8pX80expII4tfop5QZ4iMK9PbAgL/2ltWjSQHLKB7mN+jfYbVePNSqCkNYmYPuRPBIJyzms9nwqcBAtUdVYICs7FLghXR90hw0=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733921756; 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=WqCnRw5mQECy6J4x3YUdWuo+CzPSZcc+qQtrCAgcYAs=; 
	b=f5bzd4Se7mPy/M/1tVaw3YbZvjaxeyal0DVmJFIzrHyIgDC+xXPjAqsIunOixkpXK52hfYwQBAs/pHeXAPlyvfwgMAeQxEbYGcdLPHLEtTax3jQSJmzUq3+W3uUjGtkum6TBE1tSjMpw4HkhinC8Kd1Osi7ANxyTcINU2yXwBds=
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=1733921756;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=WqCnRw5mQECy6J4x3YUdWuo+CzPSZcc+qQtrCAgcYAs=;
	b=NJ9V+UN2HIkGOhoz7hPUpENcBCWYfLCxSWUphhk9EPHZoaVdSKrIbZeldlKIAOEb
	KVdEqdTardywBv3Eur3R1M6S3pdE3IlMrbtodjl3CLhLaBnZ1xrhscJB+zbIggREO2x
	DPNm/7yQb4qDI1BFMhaShsbjXMpgerQBGwmlRQAE=
Message-ID: 
Date: Wed, 11 Dec 2024 07:55:52 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 07/15] x86/hyperlaunch: initial support for hyperlaunch
 device tree
To: Jan Beulich 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-8-dpsmith@apertussolutions.com>
 
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 12/2/24 06:37, Jan Beulich wrote:
> On 23.11.2024 19:20, Daniel P. Smith wrote:
>> Add the ability to detect both a formal hyperlaunch device tree or a dom0less
>> device tree. If the hyperlaunch device tree is found, then count the number of
>> domain entries, reporting if more than one is found.
> 
> "reporting" reads like informational logging, when comment and printk() in
> walk_hyperlaunch_fdt() indicate this is actually an error (for now).

That is not a shared assumptive reading. It is equally correct to say I 
will report info and I will report an error. With that said, I can make 
it explicit.

>> --- a/xen/arch/x86/domain_builder/fdt.c
>> +++ b/xen/arch/x86/domain_builder/fdt.c
>> @@ -14,14 +14,76 @@
>>   
>>   #include "fdt.h"
>>   
>> +static int __init find_hyperlaunch_node(void *fdt)
>> +{
>> +    int hv_node = fdt_path_offset(fdt, "/chosen/hypervisor");
>> +    if ( hv_node >= 0 )
> 
> Nit: Blank line between declaration(s) and statement(s) please (also
> elsewhere).

ack.

>> --- a/xen/arch/x86/domain_builder/fdt.h
>> +++ b/xen/arch/x86/domain_builder/fdt.h
>> @@ -11,11 +11,16 @@
>>   
>>   #ifdef CONFIG_DOMAIN_BUILDER
>>   int has_hyperlaunch_fdt(struct boot_info *bi);
>> +int walk_hyperlaunch_fdt(struct boot_info *bi);
>>   #else
>>   static inline int __init has_hyperlaunch_fdt(struct boot_info *bi)
>>   {
>>       return -EINVAL;
>>   }
>> +static int __init walk_hyperlaunch_fdt(struct boot_info *bi)
> 
> inline?

Should have been.

v/r,
dps



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 13:39:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 13:39:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854806.1267912 (Exim 4.92)
	(envelope-from )
	id 1tLMwI-0000xx-8X; Wed, 11 Dec 2024 13:39:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854806.1267912; Wed, 11 Dec 2024 13:39: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 1tLMwI-0000xq-5U; Wed, 11 Dec 2024 13:39:42 +0000
Received: by outflank-mailman (input) for mailman id 854806;
 Wed, 11 Dec 2024 13:39: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 1tLMwG-0000xk-KU
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 13:39:40 +0000
Received: from fhigh-b3-smtp.messagingengine.com
 (fhigh-b3-smtp.messagingengine.com [202.12.124.154])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5d39a259-b7c5-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 14:39:38 +0100 (CET)
Received: from phl-compute-11.internal (phl-compute-11.phl.internal
 [10.202.2.51])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 7F42A2540206;
 Wed, 11 Dec 2024 08:39:36 -0500 (EST)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-11.internal (MEProxy); Wed, 11 Dec 2024 08:39:36 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 11 Dec 2024 08:39: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: 5d39a259-b7c5-11ef-a0d5-8be0dac302b0
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=1733924376;
	 x=1734010776; bh=G59R63w7pp1XzMR3o2VnXf8tL/viZNZpLW1rWOzSo18=; b=
	GSTLnue2+Wl7lKboa0ziFMuIxJ6J4FWaAqXpX2a5BrOtcDrAMv/DMXGEhdElNhcJ
	8yuhdG5CeTGhkw5skMSe1Rnriwveg1cB3W82Gm6tU+eac4Vz60xJEXaXwQm1MuMd
	VW1JKoB3x2pjYbqhguD+KOH51J5FtwlzLa/suYwuWO4Q8aMNPO0CwdV+SFU5FOCq
	QlQhgsxqN4jTbGRumoLuhmtYlUm8k4qDwnVh5AE0sv7rx6AhaVLRCZpmgXg0u3TF
	DtoD1Gtbex5pJjI/mLP1i+YfbMeFO2AB8xVI4fGs6C8NnnrQzXKqVBhYEKprYucs
	eezBbv1jGS9syw7w8UL3BQ==
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=
	1733924376; x=1734010776; bh=G59R63w7pp1XzMR3o2VnXf8tL/viZNZpLW1
	rWOzSo18=; b=Mt3v68gh2wcMs3WFmNoSVvNN+T76pQqmJrYq1XMVrvARs0vZSCH
	7lkt+6Gb/PsyW5A9lxgRtFfF4AzyALIRMPD3LUd13DMo212Efp4YGHOYwva5Zp7f
	wx3qLZNsiHKT9nCyeYv2sQzIcTkaML+L6W+m8JiLkIZ0y+t6Kdk3aSH3t5apHOr0
	vrRkFwlMk4OzpKU612yH7ezvWRwr8L39OEsJ2TF08kYACpst27z9iPfo2V1J3Hqc
	axr0iWSuIiDhWOtX3uFkEKxUCX4eUfUKSbW8v0F4tY5bza0bxrTBClWu4sdevQNp
	0MgU42F5w+7cGewTUO57XFra1kw02HuzxgA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrkedtgdehgecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr
    tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth
    hsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecu
    hfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrg
    hrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffr
    rghtthgvrhhnpefgudelteefvefhfeehieetleeihfejhfeludevteetkeevtedtvdegue
    etfeejudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm
    pehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsg
    gprhgtphhtthhopeekpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegrrhgusges
    khgvrhhnvghlrdhorhhgpdhrtghpthhtohepghhrvghgkhhhsehlihhnuhigfhhouhhnug
    grthhiohhnrdhorhhgpdhrtghpthhtohepjhhgrhhoshhssehsuhhsvgdrtghomhdprhgt
    phhtthhopehjrghnughrhihukhesghhmrghilhdrtghomhdprhgtphhtthhopehsshhtrg
    gsvghllhhinhhisehkvghrnhgvlhdrohhrghdprhgtphhtthhopeholhgvkhhsrghnughr
    pghthihshhgthhgvnhhkohesvghprghmrdgtohhmpdhrtghpthhtoheprhgvghhrvghssh
    hiohhnsheslhhishhtshdrlhhinhhugidruggvvhdprhgtphhtthhopeigvghnqdguvghv
    vghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Wed, 11 Dec 2024 14:39:33 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Ard Biesheuvel 
Cc: Greg Kroah-Hartman ,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
	Jason Andryuk ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	regressions@lists.linux.dev,
	xen-devel 
Subject: Re: [REGRESSION] Linux 6.6.64 crashes when booting as PVH domU
Message-ID: 
References: 
 
 
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="ixZe9eDMs4Thjeq6"
Content-Disposition: inline
In-Reply-To: 


--ixZe9eDMs4Thjeq6
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 11 Dec 2024 14:39:33 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Ard Biesheuvel 
Cc: Greg Kroah-Hartman ,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
	Jason Andryuk ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	regressions@lists.linux.dev,
	xen-devel 
Subject: Re: [REGRESSION] Linux 6.6.64 crashes when booting as PVH domU

On Wed, Dec 11, 2024 at 01:37:52PM +0100, Ard Biesheuvel wrote:
> (cc Greg)
>=20
> On Wed, 11 Dec 2024 at 13:30, Marek Marczykowski-G=C3=B3recki
>  wrote:
> >
> > On Wed, Dec 11, 2024 at 01:24:08PM +0100, Ard Biesheuvel wrote:
> > > On Wed, 11 Dec 2024 at 12:53, J=C3=BCrgen Gro=C3=9F =
 wrote:
> > > >
> > > > Jason, Ard,
> > > >
> > > > I guess there are some prereq patches missing in stable 6.6.y branc=
h?
> > > >
> > > >
> > > > Juergen
> > > >
> > > > On 11.12.24 12:41, Marek Marczykowski-G=C3=B3recki wrote:
> > > > > Hi,
> > > > >
> > > > > With Linux 6.6.64 I get the following crash on domU boot:
> > > > >
> > > > > (XEN) d5v0 Triple fault - invoking HVM shutdown action 1
> > > > > (XEN) *** Dumping Dom5 vcpu#0 state: ***
> > > > > (XEN) ----[ Xen-4.19.0  x86_64  debug=3Dn  Tainted:  M     ]----
> ...
> > > > >
> > > > > Linux 6.6.63 works fine.
> > > > >
> > > > > Looking at the changes, I suspect one of those:
> > > > >
> > > > >      83d123e27623 x86/pvh: Call C code via the kernel virtual map=
ping
> > > > >      f662b4a69e1d x86/pvh: Set phys_base when calling xen_prepare=
_pvh()
> > > > >
> > >
> > > The second patch shouldn't have been backported. It is unnecessary,
> > > given that in the old situation, the kernel image needs to be loaded
> > > at a fixed address. And it assumes  that %rbp is set to the physical
> > > load offset, but those patches were not backported.
> >
> > It has this tag:
> >
> >     Stable-dep-of: e8fbc0d9cab6 ("x86/pvh: Call C code via the kernel v=
irtual mapping")
> >
>=20
> That was added by the stable maintainers - someone grabbed a patch
> from the middle of an unrelated series to make e8fbc0d9cab6 apply
> without lexical conflicts.
>=20
> > Does it mean neither of them should be backported?
> >
> > But then, the e8fbc0d9cab6 has "Fixes:" tag (pointing at very old
> > commit).
> >
>=20
> If someone thinks e8fbc0d9cab6 should be backported, they should
> rebase it onto v6.6.y, not backport random other patches until
> git-apply stops complaining. And ideally, someone would build and boot
> the result to check whether it works.
>=20
> For now, it would be better to revert both.

I can confirm that reverting both commits fixes the issue.

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

--ixZe9eDMs4Thjeq6
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmdZlhUACgkQ24/THMrX
1yw7uQgAjf99iAKxgm+xGSQu3KZ7qFwugk8wI83J91QhOVb49AgP8xARFwT/OAqR
DTg9gsbJqBlYrlYel3vcsTSLzOnSyifIKO5wlDid6Yf8MkIRbaPoIR+RAm7cN2sc
R4qkljZT4dpt3Pd9mb91LjaGVo2LdNeHXNZs/ZDlkrZezYATfnJhhVc5LxWL8fo1
O6+Jmrtb9d5DccpBU58E6dCD4H6lh5iOTWOQdWLy4AlQsC8Ea9GU/S0w5VZXrSkW
6WMhsG9y9yN/S7nkfk4EBqIIsbGqsxBxyUTA+Pb4fpmBMtlwG4K9xBpOnNxgaI6S
mpNisy29Un4rTXLJjkgJU5xUkKWeMQ==
=+wW6
-----END PGP SIGNATURE-----

--ixZe9eDMs4Thjeq6--


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 13:46:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 13:46:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854822.1267922 (Exim 4.92)
	(envelope-from )
	id 1tLN2o-00036b-Vn; Wed, 11 Dec 2024 13:46:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854822.1267922; Wed, 11 Dec 2024 13:46: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 1tLN2o-00036S-T8; Wed, 11 Dec 2024 13:46:26 +0000
Received: by outflank-mailman (input) for mailman id 854822;
 Wed, 11 Dec 2024 13:46: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 1tLN2m-00036B-Ru
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 13:46:25 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4ea288f0-b7c6-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 14:46:23 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 5C369A420DF;
 Wed, 11 Dec 2024 13:44:30 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D15CFC4CED2;
 Wed, 11 Dec 2024 13:46:20 +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: 4ea288f0-b7c6-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1733924781;
	bh=HWXtI3f+E3Tiyx/D2Axaq2OXYBsQB19LK8Y6k/NMFa4=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=GNzfBd674DDIOAg5OzFCuPFaVwl6fbNgxNIu1CkZanOXGwI+NrhDOXBsHHeBPkeTt
	 UrNtTMANfXbCfoJE2TQTtQHOA9Oan73/P823xcRHVCqUJjbwBCE3R/+oipXBUom/gA
	 +wKAaoiJkQqd627paFrzhARWOUajZ4uSAjbZC84c=
Date: Wed, 11 Dec 2024 14:46:19 +0100
From: Greg Kroah-Hartman 
To: Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= 
Cc: Ard Biesheuvel ,
	=?iso-8859-1?Q?J=FCrgen_Gro=DF?= ,
	Jason Andryuk ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	regressions@lists.linux.dev,
	xen-devel 
Subject: Re: [REGRESSION] Linux 6.6.64 crashes when booting as PVH domU
Message-ID: <2024121144-false-playtime-968e@gregkh>
References: 
 
 
 
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, Dec 11, 2024 at 02:39:33PM +0100, Marek Marczykowski-Górecki wrote:
> On Wed, Dec 11, 2024 at 01:37:52PM +0100, Ard Biesheuvel wrote:
> > (cc Greg)
> > 
> > On Wed, 11 Dec 2024 at 13:30, Marek Marczykowski-Górecki
> >  wrote:
> > >
> > > On Wed, Dec 11, 2024 at 01:24:08PM +0100, Ard Biesheuvel wrote:
> > > > On Wed, 11 Dec 2024 at 12:53, Jürgen Groß  wrote:
> > > > >
> > > > > Jason, Ard,
> > > > >
> > > > > I guess there are some prereq patches missing in stable 6.6.y branch?
> > > > >
> > > > >
> > > > > Juergen
> > > > >
> > > > > On 11.12.24 12:41, Marek Marczykowski-Górecki wrote:
> > > > > > Hi,
> > > > > >
> > > > > > With Linux 6.6.64 I get the following crash on domU boot:
> > > > > >
> > > > > > (XEN) d5v0 Triple fault - invoking HVM shutdown action 1
> > > > > > (XEN) *** Dumping Dom5 vcpu#0 state: ***
> > > > > > (XEN) ----[ Xen-4.19.0  x86_64  debug=n  Tainted:  M     ]----
> > ...
> > > > > >
> > > > > > Linux 6.6.63 works fine.
> > > > > >
> > > > > > Looking at the changes, I suspect one of those:
> > > > > >
> > > > > >      83d123e27623 x86/pvh: Call C code via the kernel virtual mapping
> > > > > >      f662b4a69e1d x86/pvh: Set phys_base when calling xen_prepare_pvh()
> > > > > >
> > > >
> > > > The second patch shouldn't have been backported. It is unnecessary,
> > > > given that in the old situation, the kernel image needs to be loaded
> > > > at a fixed address. And it assumes  that %rbp is set to the physical
> > > > load offset, but those patches were not backported.
> > >
> > > It has this tag:
> > >
> > >     Stable-dep-of: e8fbc0d9cab6 ("x86/pvh: Call C code via the kernel virtual mapping")
> > >
> > 
> > That was added by the stable maintainers - someone grabbed a patch
> > from the middle of an unrelated series to make e8fbc0d9cab6 apply
> > without lexical conflicts.
> > 
> > > Does it mean neither of them should be backported?
> > >
> > > But then, the e8fbc0d9cab6 has "Fixes:" tag (pointing at very old
> > > commit).
> > >
> > 
> > If someone thinks e8fbc0d9cab6 should be backported, they should
> > rebase it onto v6.6.y, not backport random other patches until
> > git-apply stops complaining. And ideally, someone would build and boot
> > the result to check whether it works.
> > 
> > For now, it would be better to revert both.
> 
> I can confirm that reverting both commits fixes the issue.

Ok, thanks, let me go rip all of these out and do a new release now to
fix the issue.  Sorry about that, and thanks so much for the testing and
letting us know!

greg k-h


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 14:20:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 14:20:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854836.1267931 (Exim 4.92)
	(envelope-from )
	id 1tLNZ8-0000GK-81; Wed, 11 Dec 2024 14:19:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854836.1267931; Wed, 11 Dec 2024 14:19: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 1tLNZ8-0000GD-5G; Wed, 11 Dec 2024 14:19:50 +0000
Received: by outflank-mailman (input) for mailman id 854836;
 Wed, 11 Dec 2024 14:19: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 1tLNZ6-0000G7-Oc
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 14:19:48 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f8d96aba-b7ca-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 15:19:47 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733926779863348.3438017134732;
 Wed, 11 Dec 2024 06:19: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: f8d96aba-b7ca-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1733926781; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=AGDApV+s5XYq8WBtDCHZkkpxMwiI+Urp/Rm1OFgVcgdwDV1GhNHBl0MaZETJGMjDS7EKCqLrApWwYq9lNXt57+zayz2AcoMMt3FMxtbuV+rOJvZLDB8aRkAeKvafPLJQ1ltgrXo0FLLh5DPeSVXTfezP74/i+Y/xftxNFRZ9xo0=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733926781; 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=M7nuzwWoGz53YA2QOgeNmV/5BGs45A7H+bZyTd1aieQ=; 
	b=j3Q8uoQoL7oZhBTG2kR5B4TVMT4g0RL9Lny8stMtPfLFDK1aLfKlZOvvbPW+nqV97FKsqqibZUwaekqelCo71VzfZ9W55D9r1ImIS7PAl//kWjP/eKHaWV3CN5qoVwmUL3KgNgGDdLs0/2tqdCXFStwNBt1daytt8RFhW38/k/8=
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=1733926781;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=M7nuzwWoGz53YA2QOgeNmV/5BGs45A7H+bZyTd1aieQ=;
	b=SCLlvxyJZcaNSNY1WOK6NILY/F6Xx1LOhguxDJ1QrV6OhC5db8kJFF8oKjqt01YV
	cBaRNyoMg9+5JYmUy7z7lFnG0LGJELq1vPVITvCS94evGApPoTzCHUCWAbNNSFAHolZ
	5UA993u+juNji953vl34qFJ0duagYLwJmUsDhUAQ=
Message-ID: <6d36dacc-a5ae-460d-806c-55e1365b9533@apertussolutions.com>
Date: Wed, 11 Dec 2024 09:19:38 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 08/15] x86/hyperlaunch: locate dom0 kernel with
 hyperlaunch
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com,
 Jan Beulich , Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-9-dpsmith@apertussolutions.com>
 
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

On 11/25/24 17:54, Jason Andryuk wrote:
> On 2024-11-23 13:20, Daniel P. Smith wrote:
>> Look for a subnode of type `multiboot,kernel` within a domain node. If 
>> found,
>> process the reg property for the MB1 module index. If the bootargs 
>> property is
>> present and there was not an MB1 string, then use the command line 
>> from the
>> device tree definition.
>>
>> Signed-off-by: Daniel P. Smith 
> 
>> diff --git a/xen/arch/x86/domain_builder/core.c b/xen/arch/x86/ 
>> domain_builder/core.c
>> index a80f3711c306..9335f3a9ebef 100644
>> --- a/xen/arch/x86/domain_builder/core.c
>> +++ b/xen/arch/x86/domain_builder/core.c
>> @@ -56,6 +56,18 @@ void __init builder_init(struct boot_info *bi)
>>           printk(XENLOG_INFO "  Number of domains: %d\n", bi- 
>> >nr_domains);
>>       }
>> +    else
>> +    {
>> +        int i;
>> +
>> +        /* Find first unknown boot module to use as Dom0 kernel */
>> +        printk("Falling back to using first boot module as dom0\n");
>> +        i = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
>> +        bi->mods[i].type = BOOTMOD_KERNEL;
>> +        bi->domains[0].kernel = &bi->mods[i];
>> +        bi->nr_domains = 1;
>> +    }
>> +
> 
> extra newline.

ack.

>>   }
>>   /*
>> diff --git a/xen/arch/x86/domain_builder/fdt.c b/xen/arch/x86/ 
>> domain_builder/fdt.c
>> index ff1ba58b6907..6bf1c4a297fe 100644
>> --- a/xen/arch/x86/domain_builder/fdt.c
>> +++ b/xen/arch/x86/domain_builder/fdt.c
> 
>> +static int __init process_domain_node(
>> +    struct boot_info *bi, void *fdt, int dom_node)
>> +{
>> +    int node;
>> +    struct boot_domain *bd = &bi->domains[bi->nr_domains];
>> +    const char *name = fdt_get_name(fdt, dom_node, NULL);
> 
> const char *name = fdt_get_name(fdt, dom_node, NULL) ?: "unknown";
> 
> to avoid...

Sure.

>> +    int address_size = fdt_address_cells(fdt, dom_node);
>> +    int size_size = fdt_size_cells(fdt, dom_node);
>> +
>> +    if ( address_size < 0 || size_size < 0 )
>> +    {
>> +        printk("  failed processing #address or #size for domain %s)\n",
>> +               name == NULL ? "unknown" : name);
> 
> ...all this duplication in the following patches.
> 
>> +        return -EINVAL;
>> +    }
>> +
>> +    fdt_for_each_subnode(node, fdt, dom_node)
>> +    {
>> +        if ( fdt_node_check_compatible(fdt, node, "multiboot,kernel") 
>> == 0 )
> 
> I thought you were going to use "module,kernel" and "module,index" as 
> u32s for multiboot2?

Per our discussion, I will update appropriately.

v/r,
dps




From xen-devel-bounces@lists.xenproject.org Wed Dec 11 15:10:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 15:10:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854855.1267942 (Exim 4.92)
	(envelope-from )
	id 1tLOM9-0001u7-Lu; Wed, 11 Dec 2024 15:10:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854855.1267942; Wed, 11 Dec 2024 15:10:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLOM9-0001u0-Iy; Wed, 11 Dec 2024 15:10:29 +0000
Received: by outflank-mailman (input) for mailman id 854855;
 Wed, 11 Dec 2024 15:10: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 1tLOM8-0001tl-0a
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 15:10:28 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0cabf43c-b7d2-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 16:10:26 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id B4916A424F8
 for ; Wed, 11 Dec 2024 15:08:33 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6165C4CEDE
 for ; Wed, 11 Dec 2024 15:10:24 +0000 (UTC)
Received: by mail-lj1-f176.google.com with SMTP id
 38308e7fff4ca-30167f4c1e3so37266521fa.3
 for ; Wed, 11 Dec 2024 07:10: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: 0cabf43c-b7d2-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1733929824;
	bh=vwMne/K0j8rrpH/mQjtZ5MhGf+oQP7w7hqp0euRGM1A=;
	h=References:In-Reply-To:From:Date:Subject:To:Cc:From;
	b=RQ4HLuF6JC1GgROlngq5G+okeXtK0tEW3apDaBThJ0QNyKpSbvmg7ub2QP3HqD7wn
	 LlM7G257UsutNwKOFhQykFg5iBD/lrON/1NsXELZ1W+pph51V93njc9iN9WDE+RPq9
	 OMALZbBMLbB3M13ejgVoR02QfY427EQCoJB2ewZW33S+nAgom30xR/YE3FSgIgmyHv
	 t2qM99EvZF05QtiVhTkMu0d51lSozNW6KjahLY9Ok/lr/N6h+zmQ4K7/KzezxShm6x
	 08FOnQXin2lYT72wDaPHbIXkfP8jamHnTNKfAgXg7yYf9KPEbqEw2ETTskgFyG5tqO
	 yImVDjRRS/rEw==
X-Forwarded-Encrypted: i=1; AJvYcCUqaQCgpCEqErJMClAwRnu6MhKwuhoP9H3v5y7cxJEO6I08iKfuX7moiJtK6rYUC4jtD9zJCka1vkg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw6f51on5AAjeWqJaIgTRVzC5Ry8reNcW/wGyGWfP5deZz+sH7N
	bDGVeRt4yrPyq0aiT2D4PUIVpqgFBVBaMQIboatQT+V1LYyInVgFRh8rJIiNe65LpyqUKcZ/VVG
	ENHERALtdsehnhT43jXtdpYY0AIQ=
X-Google-Smtp-Source: AGHT+IEH2haSPiKkqpS7Re3sKBMuXnJYr1qHANTQL7CO42YZMOsFAblQcWfjwoKqa/dgt/iFcSPfS+HSQCIAEOV6h6Q=
X-Received: by 2002:a2e:bcc4:0:b0:300:7f87:a6a with SMTP id
 38308e7fff4ca-30240ca0ad1mr13544001fa.7.1733929823030; Wed, 11 Dec 2024
 07:10:23 -0800 (PST)
MIME-Version: 1.0
References:  
 
  
  <2024121144-false-playtime-968e@gregkh>
In-Reply-To: <2024121144-false-playtime-968e@gregkh>
From: Ard Biesheuvel 
Date: Wed, 11 Dec 2024 16:10:11 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: [REGRESSION] Linux 6.6.64 crashes when booting as PVH domU
To: Greg Kroah-Hartman 
Cc: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , 
	=?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , 
	Jason Andryuk , Stefano Stabellini , 
	Oleksandr Tyshchenko , regressions@lists.linux.dev, 
	xen-devel 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 11 Dec 2024 at 14:46, Greg Kroah-Hartman
 wrote:
>
> On Wed, Dec 11, 2024 at 02:39:33PM +0100, Marek Marczykowski-G=C3=B3recki=
 wrote:
> > On Wed, Dec 11, 2024 at 01:37:52PM +0100, Ard Biesheuvel wrote:
> > > (cc Greg)
> > >
> > > On Wed, 11 Dec 2024 at 13:30, Marek Marczykowski-G=C3=B3recki
> > >  wrote:
> > > >
> > > > On Wed, Dec 11, 2024 at 01:24:08PM +0100, Ard Biesheuvel wrote:
> > > > > On Wed, 11 Dec 2024 at 12:53, J=C3=BCrgen Gro=C3=9F  wrote:
> > > > > >
> > > > > > Jason, Ard,
> > > > > >
> > > > > > I guess there are some prereq patches missing in stable 6.6.y b=
ranch?
> > > > > >
> > > > > >
> > > > > > Juergen
> > > > > >
> > > > > > On 11.12.24 12:41, Marek Marczykowski-G=C3=B3recki wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > With Linux 6.6.64 I get the following crash on domU boot:
> > > > > > >
> > > > > > > (XEN) d5v0 Triple fault - invoking HVM shutdown action 1
> > > > > > > (XEN) *** Dumping Dom5 vcpu#0 state: ***
> > > > > > > (XEN) ----[ Xen-4.19.0  x86_64  debug=3Dn  Tainted:  M     ]-=
---
> > > ...
> > > > > > >
> > > > > > > Linux 6.6.63 works fine.
> > > > > > >
> > > > > > > Looking at the changes, I suspect one of those:
> > > > > > >
> > > > > > >      83d123e27623 x86/pvh: Call C code via the kernel virtual=
 mapping
> > > > > > >      f662b4a69e1d x86/pvh: Set phys_base when calling xen_pre=
pare_pvh()
> > > > > > >
> > > > >
> > > > > The second patch shouldn't have been backported. It is unnecessar=
y,
> > > > > given that in the old situation, the kernel image needs to be loa=
ded
> > > > > at a fixed address. And it assumes  that %rbp is set to the physi=
cal
> > > > > load offset, but those patches were not backported.
> > > >
> > > > It has this tag:
> > > >
> > > >     Stable-dep-of: e8fbc0d9cab6 ("x86/pvh: Call C code via the kern=
el virtual mapping")
> > > >
> > >
> > > That was added by the stable maintainers - someone grabbed a patch
> > > from the middle of an unrelated series to make e8fbc0d9cab6 apply
> > > without lexical conflicts.
> > >
> > > > Does it mean neither of them should be backported?
> > > >
> > > > But then, the e8fbc0d9cab6 has "Fixes:" tag (pointing at very old
> > > > commit).
> > > >
> > >
> > > If someone thinks e8fbc0d9cab6 should be backported, they should
> > > rebase it onto v6.6.y, not backport random other patches until
> > > git-apply stops complaining. And ideally, someone would build and boo=
t
> > > the result to check whether it works.
> > >
> > > For now, it would be better to revert both.
> >
> > I can confirm that reverting both commits fixes the issue.
>
> Ok, thanks, let me go rip all of these out and do a new release now to
> fix the issue.  Sorry about that, and thanks so much for the testing and
> letting us know!
>

I guess 6.11 is beyond repair?


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 15:13:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 15:13:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854865.1267952 (Exim 4.92)
	(envelope-from )
	id 1tLOP7-0002xD-34; Wed, 11 Dec 2024 15:13:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854865.1267952; Wed, 11 Dec 2024 15:13: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 1tLOP6-0002x6-W4; Wed, 11 Dec 2024 15:13:32 +0000
Received: by outflank-mailman (input) for mailman id 854865;
 Wed, 11 Dec 2024 15:13: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 1tLOP5-0002wt-GH
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 15:13:31 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7acaa78d-b7d2-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 16:13:30 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-aa689a37dd4so672012066b.3
 for ; Wed, 11 Dec 2024 07:13:30 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa665119a06sm676932866b.121.2024.12.11.07.13.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 07:13: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: 7acaa78d-b7d2-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733930010; x=1734534810; 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=EtsoRGoluwCrd6QQv0luq5gTndqCcJ0mFLAtuWD2QBA=;
        b=Ghj5cVxMiBHiDllLmthYM+4ILXMfs20ThjSbcbzWjlU6OOOUz9RTl5AjeBl9NFul0U
         0WIHXi/2Fn4Pi/cnZWhp0kn9u6xjRHHb0zAOESrSMN7m+Sk4gD8SnJ7jCW8tDGx6tNBq
         6B3hZ5FsUFXGfCEq02zlWXEQ3Zup6eDPJcW5U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733930010; x=1734534810;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=EtsoRGoluwCrd6QQv0luq5gTndqCcJ0mFLAtuWD2QBA=;
        b=gQrb1UxQK0EU7y5ood1RnmPfionjcd7G+wa9jkOCJS4NivrkTQsoN1MQh1cynWugiZ
         4sJbP/OYO8THNJz6jXEqC+mKOghGuCG33oylpedHy9l8CYisbk5JpCz3HzcyTkOfvbvp
         8tgEpwp5QNKCtPVANsV/G5XTGSk8O/VQDDAYtRQdxFpNiIzd/bcRIt/eLfECgfn2dl74
         /Z6c21D9+x4bTNNSLO0gxbOygLeLXqS+zn/oBIhwzy8TZX10NOq+jjlAo4KY6/0bENPC
         qUTRezjfklboeGArVd7JGDbz8DWd9Y5EluH3NNAidFmlFzMngVncHdoYrhYhc4si8Qrx
         8T+w==
X-Gm-Message-State: AOJu0YxqdPFmg0srdAZ4ERUZI3bN08WaJ8OerTK+yxqiFKkFYtFB9MOY
	IphBmaBB709ymQi9X3xesPSXWJEURd2TkhXqZTKkTD3PoQjxZLhY0OFOX21DT5Y=
X-Gm-Gg: ASbGncvJzXf2Cep/z0NkyCIp3x9zhTUeVXUrJohkn1aXY16kZkU05F4yojBswYYJneO
	Ztc60f6Ql5LlSIHs64O9Ppt6wCOZF1jSJy3H0mlvz/2xGLM37C8pne71rxR+M1eEryh56Cuz8r7
	AiUTA5x8goNTRSywqxAjvtwTI9IJBTCHSqXnKDHgc9hcvXphItLE9yOjB4HclnfqXK2xQn8PX20
	vK4kiVvTn5ec1oq45U5yuImBjWkZVNWyHJT5v9eDXPS+hNQ6L1vO5uDW3H8ewc=
X-Google-Smtp-Source: AGHT+IHw3qgKcLGUuGabAwNcjvuX0WaiNQo5BUfZysGB9zKeK87cUOeVj4XZs7tMtjkySAPtZfDSEw==
X-Received: by 2002:a17:906:3287:b0:aa6:4494:e354 with SMTP id a640c23a62f3a-aa6b1373e90mr276536766b.42.1733930009832;
        Wed, 11 Dec 2024 07:13:29 -0800 (PST)
Date: Wed, 11 Dec 2024 16:13:28 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 08/35] x86/domain: introduce domain_has_vuart()
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-8-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-8-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:41:38PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Introduce domain_has_vuart() for x86 port to be used in the console driver.
> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/arch/x86/include/asm/domain.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
> index b79d6badd71c4d96279555df62fad75fe817a2b6..c1d0d1f47324e8cc678a4c76c43f86820a89e7b3 100644
> --- a/xen/arch/x86/include/asm/domain.h
> +++ b/xen/arch/x86/include/asm/domain.h
> @@ -506,6 +506,9 @@ struct arch_domain
>  #define has_pirq(d)        (!!((d)->arch.emulation_flags & X86_EMU_USE_PIRQ))
>  #define has_vpci(d)        (!!((d)->arch.emulation_flags & X86_EMU_VPCI))
>  
> +/* NB: same symbol as in Arm port */
> +#define domain_has_vuart(d) false

Don't you need to consume d in the macro, ie:

#define domain_has_vuart(d) ((void)(d), false)

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 15:19:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 15:19:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854880.1267962 (Exim 4.92)
	(envelope-from )
	id 1tLOV4-0003ZC-NY; Wed, 11 Dec 2024 15:19:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854880.1267962; Wed, 11 Dec 2024 15:19:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLOV4-0003Z5-Jv; Wed, 11 Dec 2024 15:19:42 +0000
Received: by outflank-mailman (input) for mailman id 854880;
 Wed, 11 Dec 2024 15:19: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 1tLOV3-0003Yz-SD
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 15:19:41 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 570f68dc-b7d3-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 16:19:40 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5d0ac27b412so9006802a12.1
 for ; Wed, 11 Dec 2024 07:19:40 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d14c7aaa09sm9158873a12.80.2024.12.11.07.19.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 07:19: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: 570f68dc-b7d3-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733930379; x=1734535179; 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=hamutSdrGzdlYLG1n/9z/tGor9ygoyk7yWzz82YAn8s=;
        b=mrHbQWohsgUWvu6LRJ0jif8o+4vy5Zd4kyu2VtuJSy1Wn6Ma3m+o7GrHCyN45tC1kv
         SceDQ9/fDfLtySgkjXQ1bkYffe/3PgYWz7JarpEjjeT1vIoBIvz3tO1pi7AMJ9maOZ+h
         ALF44/P2E2IsF5wJvh23zc/HY5vhdYbqebyRE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733930379; x=1734535179;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=hamutSdrGzdlYLG1n/9z/tGor9ygoyk7yWzz82YAn8s=;
        b=HG0MBMn9pja1L3pAl5jFgCx+q3VGPK8SGvvakC2jHpkq3nnhRIYjWmgDXGAFA5RvmJ
         Q5NOTwIk4cuTcGJnnuE39w/tx0SBDpC+qRNG8MmqcVqViK1HvCcj2L85AXA4hF3VlYCK
         NFZMzi5G/ltSoQ0FyVSUTjoEEQv05HpGK1UrTpJ/1pkDouPLXOOSQ1Xuoa0RZRnl5De/
         2XQEIVRsFSb5zZGDLTbYfuefW37WGRYl3rLLnkj4gsEz5SsdmeFEiZwvszJ62zcZKDRh
         4ctmpkbmgE5A7vfZua/buYyPD5PXCKPdH+bsqDlwqojKPlRa0fWanf5fAf0l/XHegsax
         vsYQ==
X-Gm-Message-State: AOJu0YwQFNTTc3QVJfN5maw52n5O1J+LMqNLDX0tEEHHUlvRzYmTju4d
	khKW4mkGhXfRMjlGyecc3hV1PGdUvJh38H+7XUFxMJrPpH6nBKFzC6/+4S58dEg=
X-Gm-Gg: ASbGncsLnf+Ux0J47pgPi97CS2fmwH+k1M9csas/g6iOfwoREB766bW9RbSflYXBpZW
	XLOm29n7f/1nZdxYG7XlfDlTy1Hk9a3aYW1kczcb8n6gK2qpd0Tpr2sL1HD+yYfNGJoFp/uHt9i
	yexJNwFE/3rw8ASlJ8dYHDAJrd7JqXn/zPFLniaNLitT67bd3mR0o0iFbk5X1gbE+jrjh01J2yY
	J3VCIUMSb0ZeY8LjrIKG5CUaXcNpppkBEHuVaJfS3fFyAWfdrOGl7V0WuGAuYg=
X-Google-Smtp-Source: AGHT+IFuVkn0bjck4KKkjhnwlCNjnet7n6TKglHuyY3sf6ErJuCQNrmksytcwwS/DQsdsB8zuGNPlg==
X-Received: by 2002:a05:6402:3484:b0:5d0:b040:4616 with SMTP id 4fb4d7f45d1cf-5d4331778cemr3168266a12.28.1733930379365;
        Wed, 11 Dec 2024 07:19:39 -0800 (PST)
Date: Wed, 11 Dec 2024 16:19:38 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 09/35] x86/domain: print emulation_flags
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-9-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-9-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:41:39PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Print d->arch.emulation_flags on the console for better traceability while
> debugging in-hypervisor hardware emulators.
> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/arch/x86/domain.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 78a13e6812c9120901d0a70fb3bc1bd6a8b6917d..c88d422a64544531c1e1058fa484364bb4277d1e 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -818,11 +818,15 @@ int arch_domain_create(struct domain *d,
>  
>      if ( !emulation_flags_ok(d, emflags) )
>      {
> -        printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation "
> +        printk(XENLOG_G_ERR "d%d: Xen does not allow %s %sdomain creation "

gprintk(XENLOG_ERR, "...

Might be more natural now that we have the macro (together with Jan's
suggestion to use %pd (same below).

>                 "with the current selection of emulators: %#x\n",
> -               d->domain_id, is_hvm_domain(d) ? "HVM" : "PV", emflags);
> +               d->domain_id,
> +               is_hvm_domain(d) ? "HVM" : "PV",
> +               is_hardware_domain(d) ? "(hardware) " : "",
> +               emflags);
>          return -EOPNOTSUPP;
>      }
> +    printk(XENLOG_G_INFO "d%d: emulation_flags %#x\n", d->domain_id, emflags);

This would need to be a dprintk at least, and the log level should be
XENLOG_DEBUG.

Maybe it would be better if you could print this information as part
of some debug key, for not having to print it for every guest
creation.  Maybe as part of the 'q' debug key?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 15:22:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 15:22:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854895.1267972 (Exim 4.92)
	(envelope-from )
	id 1tLOXa-0005jd-7w; Wed, 11 Dec 2024 15:22:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854895.1267972; Wed, 11 Dec 2024 15:22: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 1tLOXa-0005jW-3m; Wed, 11 Dec 2024 15:22:18 +0000
Received: by outflank-mailman (input) for mailman id 854895;
 Wed, 11 Dec 2024 15:22: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 1tLOXZ-0005jJ-1h
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 15:22:17 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b2e147fa-b7d3-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 16:22:14 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 09046A40328;
 Wed, 11 Dec 2024 15:20:22 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 92019C4CED2;
 Wed, 11 Dec 2024 15:22:12 +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: b2e147fa-b7d3-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1733930533;
	bh=BEajb66fv5ISU7KilfoMDfuQLWj5xAaw+py5oQe1/W4=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=fUbWkepLV+LvQ9ZJmV1jXtKTVaCWlN1PgyVS5eI08vUwVVAgUk947VGQX9z6mVkt8
	 slCkliHvlasyaWO3AUG2ngh47HTBaQLpx6ERAygN/4NI9iTFmdJAUB05XhYi/SO5rM
	 gUfy1epuGFgChomDRY0bRcYUVK2QIQzD7FsnJblk=
Date: Wed, 11 Dec 2024 16:22:10 +0100
From: Greg Kroah-Hartman 
To: Ard Biesheuvel 
Cc: Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= ,
	=?iso-8859-1?Q?J=FCrgen_Gro=DF?= ,
	Jason Andryuk ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	regressions@lists.linux.dev,
	xen-devel 
Subject: Re: [REGRESSION] Linux 6.6.64 crashes when booting as PVH domU
Message-ID: <2024121131-blip-container-01ce@gregkh>
References: 
 
 
 
 
 
 <2024121144-false-playtime-968e@gregkh>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Wed, Dec 11, 2024 at 04:10:11PM +0100, Ard Biesheuvel wrote:
> On Wed, 11 Dec 2024 at 14:46, Greg Kroah-Hartman
>  wrote:
> >
> > On Wed, Dec 11, 2024 at 02:39:33PM +0100, Marek Marczykowski-Górecki wrote:
> > > On Wed, Dec 11, 2024 at 01:37:52PM +0100, Ard Biesheuvel wrote:
> > > > (cc Greg)
> > > >
> > > > On Wed, 11 Dec 2024 at 13:30, Marek Marczykowski-Górecki
> > > >  wrote:
> > > > >
> > > > > On Wed, Dec 11, 2024 at 01:24:08PM +0100, Ard Biesheuvel wrote:
> > > > > > On Wed, 11 Dec 2024 at 12:53, Jürgen Groß  wrote:
> > > > > > >
> > > > > > > Jason, Ard,
> > > > > > >
> > > > > > > I guess there are some prereq patches missing in stable 6.6.y branch?
> > > > > > >
> > > > > > >
> > > > > > > Juergen
> > > > > > >
> > > > > > > On 11.12.24 12:41, Marek Marczykowski-Górecki wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > With Linux 6.6.64 I get the following crash on domU boot:
> > > > > > > >
> > > > > > > > (XEN) d5v0 Triple fault - invoking HVM shutdown action 1
> > > > > > > > (XEN) *** Dumping Dom5 vcpu#0 state: ***
> > > > > > > > (XEN) ----[ Xen-4.19.0  x86_64  debug=n  Tainted:  M     ]----
> > > > ...
> > > > > > > >
> > > > > > > > Linux 6.6.63 works fine.
> > > > > > > >
> > > > > > > > Looking at the changes, I suspect one of those:
> > > > > > > >
> > > > > > > >      83d123e27623 x86/pvh: Call C code via the kernel virtual mapping
> > > > > > > >      f662b4a69e1d x86/pvh: Set phys_base when calling xen_prepare_pvh()
> > > > > > > >
> > > > > >
> > > > > > The second patch shouldn't have been backported. It is unnecessary,
> > > > > > given that in the old situation, the kernel image needs to be loaded
> > > > > > at a fixed address. And it assumes  that %rbp is set to the physical
> > > > > > load offset, but those patches were not backported.
> > > > >
> > > > > It has this tag:
> > > > >
> > > > >     Stable-dep-of: e8fbc0d9cab6 ("x86/pvh: Call C code via the kernel virtual mapping")
> > > > >
> > > >
> > > > That was added by the stable maintainers - someone grabbed a patch
> > > > from the middle of an unrelated series to make e8fbc0d9cab6 apply
> > > > without lexical conflicts.
> > > >
> > > > > Does it mean neither of them should be backported?
> > > > >
> > > > > But then, the e8fbc0d9cab6 has "Fixes:" tag (pointing at very old
> > > > > commit).
> > > > >
> > > >
> > > > If someone thinks e8fbc0d9cab6 should be backported, they should
> > > > rebase it onto v6.6.y, not backport random other patches until
> > > > git-apply stops complaining. And ideally, someone would build and boot
> > > > the result to check whether it works.
> > > >
> > > > For now, it would be better to revert both.
> > >
> > > I can confirm that reverting both commits fixes the issue.
> >
> > Ok, thanks, let me go rip all of these out and do a new release now to
> > fix the issue.  Sorry about that, and thanks so much for the testing and
> > letting us know!
> >
> 
> I guess 6.11 is beyond repair?

6.11.y is end-of-life for a week or so now, sorry.  Hopefully no one is
still using it (I did hear that Fedora is using it, so I don't know...)

greg k-h


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 15:42:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 15:42:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854909.1267982 (Exim 4.92)
	(envelope-from )
	id 1tLOqa-0001Ea-Mv; Wed, 11 Dec 2024 15:41:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854909.1267982; Wed, 11 Dec 2024 15:41:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLOqa-0001ET-J4; Wed, 11 Dec 2024 15:41:56 +0000
Received: by outflank-mailman (input) for mailman id 854909;
 Wed, 11 Dec 2024 15:41: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 1tLOqZ-0001AJ-Nz
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 15:41:55 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 718b84c8-b7d6-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 16:41:54 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733931704905995.210486743355;
 Wed, 11 Dec 2024 07:41: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: 718b84c8-b7d6-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1733931707; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=PMizDMuZaK2Ohs+ThE9lT52OJsP3MxJJNbFdU4fBBZ9sRMP/9s/htmwgRU/sNMacUISrAiPwQB82xBSKf+4jm98FnJb5/CvcDRpYI7y9p9Vt9G3eZXOC0vU8nyxy7Mr9ie0WzM9p4aJLYpfHC9wMHbIsoxR8HmCGXoZXy390nA0=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733931707; 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=4liT0qrO/T3UlhWquLdcJPHwO80fJ6Dv48246bTbq6A=; 
	b=DWsGLMzBaujyePswk+ppZ6sF+cDXeM8MajUH1Ra0Xk3ZtmW2N1JxD80LHjZJUqC9OtlggpmKrUS3+Jr4kGXXSFveOmqfIRKjJDWsPDBOeTqZcTtNLCdoiSDxqSJtSfG3fGx7g4wjA0MWAel18uvc+YBuf6ygxcWK4bB5wCemZ1w=
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=1733931707;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=4liT0qrO/T3UlhWquLdcJPHwO80fJ6Dv48246bTbq6A=;
	b=Ry5R187/7mJcfbBefyZKCV+YVBquiXisMceqowOzFmg7qaGyDVadFIJo5+5oxqKL
	dK+rrVk4xtjUQLpfFUvyQHzryzoaMQAEwnklaUr8x/t/yJmum1jlfmi7IrFxYkPGeVc
	oY+N7Jau9p5vj/87s0uRWrRsbYnYozcxFwslf2wI=
Message-ID: 
Date: Wed, 11 Dec 2024 10:41:43 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 08/15] x86/hyperlaunch: locate dom0 kernel with
 hyperlaunch
To: Jan Beulich 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-9-dpsmith@apertussolutions.com>
 <91e6d4e7-b4ff-4e13-8814-95eaac891cf4@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <91e6d4e7-b4ff-4e13-8814-95eaac891cf4@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 12/2/24 06:53, Jan Beulich wrote:
> On 23.11.2024 19:20, Daniel P. Smith wrote:
>> Look for a subnode of type `multiboot,kernel` within a domain node. If found,
>> process the reg property for the MB1 module index. If the bootargs property is
>> present and there was not an MB1 string, then use the command line from the
>> device tree definition.
> 
> Why specifically MB1?

Because Xen converts MB2 into an MB1 chain very early in the entry 
points that take MB2. By the time HL code is executed, it will only ever 
see a list of MB1 modules.

>> --- a/xen/arch/x86/domain_builder/core.c
>> +++ b/xen/arch/x86/domain_builder/core.c
>> @@ -56,6 +56,18 @@ void __init builder_init(struct boot_info *bi)
>>   
>>           printk(XENLOG_INFO "  Number of domains: %d\n", bi->nr_domains);
>>       }
>> +    else
>> +    {
>> +        int i;
> 
> Plain int when ...
> 
>> +        /* Find first unknown boot module to use as Dom0 kernel */
>> +        printk("Falling back to using first boot module as dom0\n");
>> +        i = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
>> +        bi->mods[i].type = BOOTMOD_KERNEL;
>> +        bi->domains[0].kernel = &bi->mods[i];
>> +        bi->nr_domains = 1;
>> +    }
> 
> ... it's used as array index (and there's no check for the function return
> value being negative)?

Nope, that is an artifact from early version of boot module series in 
which first_boot_module_index() returned a plain int. Will fix.

>> --- a/xen/arch/x86/domain_builder/fdt.c
>> +++ b/xen/arch/x86/domain_builder/fdt.c
>> @@ -14,6 +14,122 @@
>>   
>>   #include "fdt.h"
>>   
>> +static inline int __init fdt_get_prop_as_reg(
> 
> What does "reg" stand for here?

Device Tree defines a two field "prop-encoded=array" property type 
called reg.

>> +    const void *fdt, int node, const char *name, unsigned int ssize,
>> +    unsigned int asize, uint64_t *size, uint64_t *addr)
>> +{
>> +    int ret;
>> +    const struct fdt_property *prop;
>> +    fdt32_t *cell;
>> +
>> +    /* FDT spec max size is 4 (128bit int), but largest arch int size is 64 */
>> +    if ( ssize > 2 || asize > 2 )
>> +        return -EINVAL;
>> +
>> +    prop = fdt_get_property(fdt, node, name, &ret);
>> +    if ( !prop || ret < sizeof(u32) )
>> +        return ret < 0 ? ret : -EINVAL;
>> +
>> +    /* read address field */
>> +    cell = (fdt32_t *)prop->data;
>> +
>> +    if ( asize == 1 )
>> +    {
>> +        uint32_t val;
>> +        fdt_cell_as_u32(cell, &val);
>> +        *addr = (uint64_t)val;
> 
> No need for a cast here nor ...
> 
>> +    }
>> +    else
>> +        fdt_cell_as_u64(cell, addr);
>> +
>> +    /* read size field */
>> +    cell += asize;
>> +
>> +    if ( ssize == 1 )
>> +    {
>> +        uint32_t val;
>> +        fdt_cell_as_u32(cell, &val);
>> +        *size = (uint64_t)val;
> 
> ... here?

No the compiler does not need the cast, placed to remind readers what 
was being done. Can/will drop.

>> +    }
>> +    else
>> +        fdt_cell_as_u64(cell, size);
>> +
>> +    return 0;
>> +}
> 
> This whole function reads very much like a library one. Does it really need
> adding here, rather than to the FDT library code we already have? In any
> event there's nothing x86-specific about it, afaics.

This is where it gets complicated. Most of the higher order functions 
exposed by xen/device_tree.h are written to work with FDT indexing 
structures, referred to as the unflattened tree. Deconflicting the mixed 
use of FDT and FDT index in device_tree.h is beyond the scope of this 
series.

>> +static int __init dom0less_module_node(
>> +    void *fdt, int node, int size_size, int address_size)
> 
> Three times plain int, when ...
> 
>> +{
>> +    uint64_t size, addr;
>> +    int ret = fdt_get_prop_as_reg(fdt, node, "reg", size_size, address_size,
> 
> ... two get converted to unsigned int in the course of the function call
> here?

The libfdt function returns signed int for size_size and address_size to 
allow returning an error code, which is checked for at the time of 
invocation. After that point, the value is guaranteed to be >= 0. They 
can be left as int in the function calls or a pair of temporary plain 
ints could be used for the libfdt call and if no error, store the value 
into unsigned.

>> +                                  &size, &addr);
>> +    /* An FDT error value may have been returned, translate to -EINVAL */
>> +    if ( ret < 0 )
>> +        return -EINVAL;
>> +
>> +    if ( size != 0 )
>> +        return -EOPNOTSUPP;
> 
> Not knowing much about DT: What does 0 represent here?

The libfdt code treats 0 as a valid value, whether zero is a valid value 
is driven by the contextual usage of the property.

>> +    if ( addr > MAX_NR_BOOTMODS )
>> +        return -ERANGE;
>> +
>> +    /*
>> +     * MAX_NR_BOOTMODS cannot exceed the max for MB1, represented by a u32,
>> +     * thus the cast down to a u32 will be safe due to the prior check.
>> +     */
>> +    return (int)addr;
> 
> Comment and cast contradict one another. DYM u32 (really: uint32_t), or plain
> int? If you mean to return a plain int (for the sake of the -errno values
> further up), MAX_NR_BOOTMODS needs to stay below 2**31.

Good point, we cannot artificially impose 2^31 limit when 2^32 is the 
legitimate upper bound supported by the MB1 protocol. Even if that value 
is impractical. At the same time, it is beneficial to be able to 
communicate failures along with some delineation of the failure. Let me 
think about this, and in the meantime suggestions are welcomed.

>> +static int __init process_domain_node(
>> +    struct boot_info *bi, void *fdt, int dom_node)
>> +{
>> +    int node;
>> +    struct boot_domain *bd = &bi->domains[bi->nr_domains];
>> +    const char *name = fdt_get_name(fdt, dom_node, NULL);
>> +    int address_size = fdt_address_cells(fdt, dom_node);
>> +    int size_size = fdt_size_cells(fdt, dom_node);
>> +
>> +    if ( address_size < 0 || size_size < 0 )
>> +    {
>> +        printk("  failed processing #address or #size for domain %s)\n",
>> +               name == NULL ? "unknown" : name);
>> +        return -EINVAL;
>> +    }
>> +
>> +    fdt_for_each_subnode(node, fdt, dom_node)
>> +    {
>> +        if ( fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
>> +        {
>> +            int idx = dom0less_module_node(fdt, node, size_size, address_size);
>> +            if ( idx < 0 )
>> +            {
>> +                printk("  failed processing kernel module for domain %s)\n",
>> +                       name == NULL ? "unknown" : name);
>> +                return idx;
>> +            }
>> +
>> +            if ( idx > bi->nr_modules )
>> +            {
>> +                printk("  invalid kernel module index for domain node (%d)\n",
>> +                       bi->nr_domains);
>> +                return -EINVAL;
>> +            }
>> +
>> +            printk("  kernel: boot module %d\n", idx);
>> +            bi->mods[idx].type = BOOTMOD_KERNEL;
>> +            bd->kernel = &bi->mods[idx];
>> +        }
>> +    }
> 
> What if you find two?

No different than if someone accidentally duplicated the module line for 
the kernel in grub.cfg. It's a violation of the boot convention with the 
resulting behavior being indeterminate, which may or may not result in 
failure/panic when the domain attempts to boot. It might be worth adding 
a warning if a duplicate kernel entry is detected. It is possible that 
such a configuration would boot if it was a duplicate paste situation. 
So I would not feel right panicking, when there is a possibility that 
the configuration could boot.

>> --- a/xen/arch/x86/domain_builder/fdt.h
>> +++ b/xen/arch/x86/domain_builder/fdt.h
>> @@ -3,6 +3,7 @@
>>   #define __XEN_X86_FDT_H__
>>   
>>   #include 
>> +#include 
>>   
>>   #include 
>>   
>> @@ -10,6 +11,22 @@
>>   #define HYPERLAUNCH_MODULE_IDX 0
>>   
>>   #ifdef CONFIG_DOMAIN_BUILDER
>> +
>> +static inline int __init fdt_cell_as_u32(const fdt32_t *cell, uint32_t *val)
>> +{
>> +    *val = fdt32_to_cpu(*cell);
>> +
>> +    return 0;
>> +}
>> +
>> +static inline int __init fdt_cell_as_u64(const fdt32_t *cell, uint64_t *val)
>> +{
>> +    *val = ((uint64_t)fdt32_to_cpu(cell[0]) << 32) |
>> +           (uint64_t)fdt32_to_cpu(cell[1]);
>> +
>> +    return 0;
>> +}
> 
> Basic library routines again?

Same as above.

v/r,
dps



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 15:46:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 15:46:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854921.1267992 (Exim 4.92)
	(envelope-from )
	id 1tLOur-0001z3-6S; Wed, 11 Dec 2024 15:46:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854921.1267992; Wed, 11 Dec 2024 15: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 1tLOur-0001yw-3O; Wed, 11 Dec 2024 15:46:21 +0000
Received: by outflank-mailman (input) for mailman id 854921;
 Wed, 11 Dec 2024 15:46: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 1tLOuq-0001yi-3q
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 15:46:20 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0f8c5fba-b7d7-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 16:46:19 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733931971433723.1442856793576;
 Wed, 11 Dec 2024 07:46: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: 0f8c5fba-b7d7-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1733931974; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=mpQs8stcLn/6BtVsQcrvcZN9JW09FG1GNJMJ/fIl5Sy4Ey8Y/aXU56XuUmrolnKKsyanB3977q+t+NFCY4poR1+DqYcrbpXF9YM0CcsvHA3FS6YJmBJX3UKUdX9qs1h0AXld4a+mNnHPxc0rAwmFWkn/+uH9zKwv8d3HfO3NXPw=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733931974; 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=jZZ4ULguLTW7jlwVwf7sQnKBcPkBv2PSOMsKjNnRy+M=; 
	b=LdsjtHwW2qTGo4Z4drEvt+FDYSG50Ki3OydITkRk+ultpsYWWBjwnvulHEomYCqgVQN3g+Ad6znzXejvBNjzihJwX8XWe9yZzpIzNvsp5WXehFxU2Ici1+r13NJ791jGwdpw5rJIUoMxpox3rinrfXfGVt/eKTN0j0iJhE8ODG8=
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=1733931974;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=jZZ4ULguLTW7jlwVwf7sQnKBcPkBv2PSOMsKjNnRy+M=;
	b=jYQHXuE1dGSc5z3tQThcZzz9nFwyhjpwj/2BwGXXeBRjQr7iJFHP+m4+EQRCDJaT
	hhBxerUTdTfHLCh3oU8SHXOgQtJGTxulP9jADj4D6hg/zaCVF2bfHYBBnZILmPUkJEe
	Smv39Q13YCcngsqc4Y5qGosZI+IdoWXncEIAM0ss=
Message-ID: 
Date: Wed, 11 Dec 2024 10:46:10 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 09/15] x86/hyperlaunch: obtain cmdline from device tree
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com,
 Jan Beulich , Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-10-dpsmith@apertussolutions.com>
 
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

On 11/25/24 18:12, Jason Andryuk wrote:
> On 2024-11-23 13:20, Daniel P. Smith wrote:
>> If a command line is not provided through the bootloader's mechanism, 
>> e.g.
>> muiltboot module string field, then use one from the device tree if 
>> present.
>> The device tree command line is located in the bootargs property of the
>> `multiboot,kernel` node.
>>
>> Signed-off-by: Daniel P. Smith 
>> ---
>>   xen/arch/x86/domain_builder/core.c       | 28 +++++++++++++++++++
>>   xen/arch/x86/domain_builder/fdt.c        | 34 ++++++++++++++++++++++++
>>   xen/arch/x86/domain_builder/fdt.h        | 24 +++++++++++++++++
>>   xen/arch/x86/include/asm/bootinfo.h      |  6 +++--
>>   xen/arch/x86/include/asm/domainbuilder.h |  4 +++
>>   xen/arch/x86/setup.c                     | 10 +++++--
>>   6 files changed, 102 insertions(+), 4 deletions(-)
>>
>> diff --git a/xen/arch/x86/domain_builder/core.c b/xen/arch/x86/ 
>> domain_builder/core.c
>> index 9335f3a9ebef..95cab06e6159 100644
>> --- a/xen/arch/x86/domain_builder/core.c
>> +++ b/xen/arch/x86/domain_builder/core.c
>> @@ -8,9 +8,37 @@
>>   #include 
>>   #include 
>> +#include 
>>   #include "fdt.h"
>> +size_t __init builder_get_cmdline_size(struct boot_info *bi, int offset)
>> +{
>> +#ifdef CONFIG_DOMAIN_BUILDER
> 
> I wasnted to suggest:
> 
> if ( !IS_ENABLED(CONFIG_DOMAIN_BUILDER) )
>      return 0;
> 
> but that fails to compile for a missing fdt_cmdline_prop_size().

Yes, I wanted to do the same as well.

>> +    const void *fdt = bootstrap_map_bm(&bi- 
>> >mods[HYPERLAUNCH_MODULE_IDX]);
>> +    int size = fdt_cmdline_prop_size(fdt, offset);
>> +
>> +    bootstrap_unmap();
>> +    return size < 0 ? 0 : (size_t) size;
>> +#else
>> +    return 0;
>> +#endif
>> +}
>> +
>> +int __init builder_get_cmdline(
>> +    struct boot_info *bi, int offset, char *cmdline, size_t size)
>> +{
>> +#ifdef CONFIG_DOMAIN_BUILDER
> 
> and here fdt_cmdline_prop_copy().  I'm not sure the addition of more 
> stubs offsets these ifdefs, so:
> 
> Reviewed-by: Jason Andryuk 

Thanks!

v/r,
dps



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 15:50:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 15:50:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854932.1268003 (Exim 4.92)
	(envelope-from )
	id 1tLOyX-0003Sn-MT; Wed, 11 Dec 2024 15:50:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854932.1268003; Wed, 11 Dec 2024 15:50: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 1tLOyX-0003Sg-I5; Wed, 11 Dec 2024 15:50:09 +0000
Received: by outflank-mailman (input) for mailman id 854932;
 Wed, 11 Dec 2024 15:50: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 1tLOyV-0003Sa-Lo
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 15:50:07 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 96eff7c2-b7d7-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 16:50:06 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733932198330521.808700040406;
 Wed, 11 Dec 2024 07:49: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: 96eff7c2-b7d7-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1733932201; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=hO5jdAoh7s6+2XYrGfHwetCAiwBcyJGNScpc1+cIiRQe1qYtZivX9te5Sn60oSib9uKICTOQuz913brDCc/UADCQqwl+oIsOPn72S6u5TmmYDQYvPA6OY6WaZyQzdB2MOgbj8mQ2Uf77Whvq9dvoPiKNAJgPngxaUUsbaienpd8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733932201; 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=4mNkgdDLw9V4heCgs6q03+jt8fQN8SUF8+4WfCQLRMs=; 
	b=Arg85pjk9G9nR6gwu8Y9D8I8NPE55+VrM8tSHK2LPScIiWph2P8T+VdP5YX/mfjUETqNdChNFSSP7oX0Yy7r4bqTec8kGvFEdDBy2DNW62YdmjYPcP5nUCV224bC+BhY1pJg80KNUFSJVT6GK5Wka2JCvaY+xoW/My2duIzRjt0=
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=1733932201;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=4mNkgdDLw9V4heCgs6q03+jt8fQN8SUF8+4WfCQLRMs=;
	b=Xe/4HAz8bKWe3oZbmXncwwVe/bxw6dZhUdDFwXxXqFMqnbvutdEIubsi4GPiJZiI
	8CmjX4yeYiU6oKq9WX9t5jIhlFwwu7xbySlidjIkZWz4ojjOFwz/aDvVN8s3MXNKf3J
	UQKzr41xOdaL2yaWjzRESmnJB/STMnp8KAEjvDT0=
Message-ID: 
Date: Wed, 11 Dec 2024 10:49:56 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 10/15] x86/hyperlaunch: locate dom0 initrd with
 hyperlaunch
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com,
 Jan Beulich , Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-11-dpsmith@apertussolutions.com>
 <4fe95739-1873-401b-b253-5d13c13abc9d@amd.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <4fe95739-1873-401b-b253-5d13c13abc9d@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

On 11/25/24 18:34, Jason Andryuk wrote:
> On 2024-11-23 13:20, Daniel P. Smith wrote:
>> Look for a subnode of type `multiboot,ramdisk` within a domain node. If
>> found, process the reg property for the MB1 module index.
>>
>> Signed-off-by: Daniel P. Smith 
>> ---
>>   xen/arch/x86/domain_builder/fdt.c | 25 ++++++++++++++++++++++
>>   xen/arch/x86/setup.c              | 35 +++++++++++++++++--------------
>>   2 files changed, 44 insertions(+), 16 deletions(-)
>>
>> diff --git a/xen/arch/x86/domain_builder/fdt.c b/xen/arch/x86/ 
>> domain_builder/fdt.c
>> index f8ddb11b339e..bc8054a80ec1 100644
>> --- a/xen/arch/x86/domain_builder/fdt.c
>> +++ b/xen/arch/x86/domain_builder/fdt.c
>> @@ -152,6 +152,31 @@ static int __init process_domain_node(
>>                   if ( ret > 0 )
>>                       bd->kernel->fdt_cmdline = true;
>>               }
>> +
>> +            continue;
>> +        }
>> +        if ( fdt_node_check_compatible(fdt, node, 
>> "multiboot,ramdisk") == 0 )
> 
> I think
>          continue;
>      }
>      if
> 
> should change to
> 
>      } else if
> 
> ?

Yah, I can make it a nested set of ifs.

> Also "module,ramdisk"/"module,index"?

Yes, will be updated to new format.

v/r,
dps



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 16:06:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 16:06:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854946.1268011 (Exim 4.92)
	(envelope-from )
	id 1tLPEM-0007fb-UH; Wed, 11 Dec 2024 16:06:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854946.1268011; Wed, 11 Dec 2024 16:06: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 1tLPEM-0007fU-Rg; Wed, 11 Dec 2024 16:06:30 +0000
Received: by outflank-mailman (input) for mailman id 854946;
 Wed, 11 Dec 2024 16:06: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 1tLPEM-0007fO-3W
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 16:06:30 +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 df121664-b7d9-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 17:06:26 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733933174271379.75298590475563;
 Wed, 11 Dec 2024 08:06: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: df121664-b7d9-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1733933180; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=kwgOH+8Gtei6ABFK2o6pwDYwaTkeWm4XFakyNcgYWHfvVlhO4ZTr7YUjsK1IcO0YaUMENj4gryMbVZpNAB37O4+ofvzo1oYI8exsAiqdwutz2tJnT32jDHQEQOycouc9NRzrGdbsKs4wL8GjVYJAgfBvDj8R106t7Na2SIoFNSM=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733933180; 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=UaUToRm0uKeJR+eRCN+VEks07UMpYz/py7jkWfWWj7I=; 
	b=B00TddP9HREk6B5r3ct+PKRLsQJBD9rN+xiLdybDpB3RoBEfy23nhAZjV2GEtuopFMbAxx5nnT5Mwpdf+x0skdYMav5VJYK78uJiGn7aMRGKdtd9ck1VOC7IEJl6m0SIFxapsZMC1mceZURH9O88lvVdWQsPQvNIFnhWOnWUfqc=
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=1733933180;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=UaUToRm0uKeJR+eRCN+VEks07UMpYz/py7jkWfWWj7I=;
	b=USP8cIfDruvZ5myUKsauI1hSzuZMfkqDYnNfcSDyjZM8Ne+PfIo3D2Z1Pmwxb+5N
	B50R1l3srj3NLj6lGrwmQOBzH+ys1waF2OPl9Y4d4unpk2XGTtTo+FticVI/zaHTesC
	d/TW0bjDQT/h7agphdtavsi/261f1gyv+HddDkqY=
Message-ID: 
Date: Wed, 11 Dec 2024 11:06:12 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 11/15] x86/hyperlaunch: add domain id parsing to domain
 config
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com,
 Jan Beulich , Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-12-dpsmith@apertussolutions.com>
 <99177823-38d9-4aca-af84-150ae6f37a25@amd.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <99177823-38d9-4aca-af84-150ae6f37a25@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

On 11/25/24 18:45, Jason Andryuk wrote:
> On 2024-11-23 13:20, Daniel P. Smith wrote:
>> Introduce the ability to specify the desired domain id for the domain
>> definition. The domain id will be populated in the domid property of 
>> the domain
>> node in the device tree configuration.
>>
>> Signed-off-by: Daniel P. Smith 
>> ---
>>   xen/arch/x86/domain_builder/fdt.c | 31 ++++++++++++++++++++++++++++++-
>>   xen/arch/x86/domain_builder/fdt.h | 18 ++++++++++++++++++
>>   xen/arch/x86/setup.c              |  3 ++-
>>   3 files changed, 50 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/x86/domain_builder/fdt.c b/xen/arch/x86/ 
>> domain_builder/fdt.c
>> index bc8054a80ec1..3a6b4fbc09a9 100644
>> --- a/xen/arch/x86/domain_builder/fdt.c
>> +++ b/xen/arch/x86/domain_builder/fdt.c
> 
>> @@ -120,6 +121,28 @@ static int __init process_domain_node(
>>           return -EINVAL;
>>       }
>> +    fdt_for_each_property_offset(property, fdt, dom_node)
>> +    {
>> +        const struct fdt_property *prop;
>> +
>> +        prop = fdt_get_property_by_offset(fdt, property, NULL);
>> +        if ( !prop )
>> +            continue; /* silently skip */
>> +
>> +        if ( match_fdt_property(fdt, prop, "domid" ) )
>> +        {
>> +            uint32_t val = DOMID_INVALID;
>> +            if ( fdt_prop_as_u32(prop, &val) != 0 )
>> +            {
>> +                printk("  failed processing domain id for domain %s\n",
>> +                       name == NULL ? "unknown" : name);
>> +                return -EINVAL;
>> +            }
> 
> Bounds check against DOMID_FIRST_RESERVED?

Yah, that would be good.

>> +            bd->domid = (domid_t)val;
>> +            printk("  domid: %d\n", bd->domid);
>> +        }
>> +    }
>> +
>>       fdt_for_each_subnode(node, fdt, dom_node)
>>       {
>>           if ( fdt_node_check_compatible(fdt, node, 
>> "multiboot,kernel") == 0 )
>> @@ -186,6 +209,12 @@ static int __init process_domain_node(
>>           return -EFAULT;
>>       }
>> +    if ( bd->domid == DOMID_INVALID )
>> +        bd->domid = get_initial_domain_id();
>> +    else
>> +        if ( bd->domid != get_initial_domain_id() )
> 
> single line "else if"?

Yep.

>> +            printk(XENLOG_WARNING "WARN: unsuported booting not using 
>> initial domid\n");
> 
> "unsupported"
> 
> Maybe "Booting without initial domid not supported"?

I am good with that phrasing.

>> +
>>       return 0;
>>   }
>> diff --git a/xen/arch/x86/domain_builder/fdt.h b/xen/arch/x86/ 
>> domain_builder/fdt.h
>> index ab2b43872e25..06ead05a2583 100644
>> --- a/xen/arch/x86/domain_builder/fdt.h
>> +++ b/xen/arch/x86/domain_builder/fdt.h
>> @@ -27,6 +27,24 @@ static inline int __init fdt_cell_as_u64(const 
>> fdt32_t *cell, uint64_t *val)
> 
>> +static inline bool __init match_fdt_property(
>> +    const void *fdt, const struct fdt_property *prop, const char *s)
>> +{
>> +    int slen, len = strlen(s);
>> +    const char *p = fdt_get_string(fdt, fdt32_to_cpu(prop->nameoff), 
>> &slen);
>> +
>> +    return p && (slen == len) && (memcmp(p, s, len) == 0);
> 
> match_fdt_property() gets called more in later patches.  I wonder if
> 
>      const char *p = fdt_get_string(fdt, fdt32_to_cpu(prop->nameoff), 
> &slen);
> 
> should move into process_domain_node, and then the string is just 
> compared?  Maybe it already gets optimized?

Your approach would explicitly force a single fdt_get_string() call, 
logic would remain readable, all while not hoping the optimizer can 
catch it.

> (Is there a way to disassemble .init.text with symbols?)
> 
>> +}
>> +
>>   static inline int __init fdt_cmdline_prop_size(const void *fdt, int 
>> offset)
>>   {
>>       int ret;
>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>> index eaac87b02f78..317349b80ac6 100644
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -1020,7 +1020,8 @@ static struct domain *__init create_dom0(struct 
>> boot_info *bi)
>>           dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
>>       /* Create initial domain.  Not d0 for pvshim. */
>> -    bd->domid = get_initial_domain_id();
>> +    if ( bd->domid == DOMID_INVALID )
>> +        bd->domid = get_initial_domain_id();
> 
> This seems redundant with the earlier DOMID_INVALID check & setting.  Or 
> does this handle the non-hyperlaunch case?  Maybe it should move to 
> builder_init() for other non-hyperlaunch configuration?

Even if the call to get_initial_domain_id() is moved to builder_init(), 
I would not feel comfortable with assuming bd->domid is valid when 
getting here. So I would still have the check, but with panic instead. 
I'm open to making the change if the x86 maintainers are comfortable 
with making the assumption.

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 16:07:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 16:07:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854958.1268021 (Exim 4.92)
	(envelope-from )
	id 1tLPFM-0008EC-9V; Wed, 11 Dec 2024 16:07:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854958.1268021; Wed, 11 Dec 2024 16:07:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLPFM-0008E3-6y; Wed, 11 Dec 2024 16:07:32 +0000
Received: by outflank-mailman (input) for mailman id 854958;
 Wed, 11 Dec 2024 16:07: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 1tLPFK-0008BF-OI
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 16:07:30 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 048f27f0-b7da-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 17:07:29 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733933240956195.13922843402474;
 Wed, 11 Dec 2024 08:07:20 -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: 048f27f0-b7da-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1733933244; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=OIdgTLlRBamAk5x8zqa5YxDgzhIzonsQLTB9tGDZSkEb3Qd8ML/+eUz95apsgeqPcufcuJ2at9spZTsjlRmP3GMaFFizq93tALo756GV1AN9I+MEJgFjWPecOgHcpqvz9ew7d+HgTPoRDsGSn6nfLOS52YBAAinN/usd0uL+X6w=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733933244; 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=9Lm5ZvZ63BzudbCXPyhXRSASFrTO/SYhQw6yp/5HMXc=; 
	b=O2iIBnvNl+NKCQ/KXMsLHOOvi4EUmpzwF52ZDPgBG5l6KurgEHkMYa/w8k2puMRnRjKNYgOfiPJ7k4W3BndaiIX3DLaoaA7jhIvEGW5d7LuwU+WG/jR31OXGxc0YX6PC0xjPsnXMegIAuYKWynto5IyM0xGUAyhl7CdeX6son/U=
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=1733933243;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=9Lm5ZvZ63BzudbCXPyhXRSASFrTO/SYhQw6yp/5HMXc=;
	b=btYYOnsSF9q3qZFP2i7pp0lRPX40uvbwB+UvOSkQ1hj+zPYhlJEu4lOSYGT9Da8O
	bDG6fbStwUai8WaDSvfozo3UQznOqvZw/hFiKeLddOsVFxnKlN8TXd8JoDDZjBUPy1H
	w+wBXr75MXu+WIUlRMZZT4hFxxjIPFopVWZPvsP4=
Message-ID: <70aeda86-687f-4733-98e9-583bae35a220@apertussolutions.com>
Date: Wed, 11 Dec 2024 11:07:19 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 11/15] x86/hyperlaunch: add domain id parsing to domain
 config
To: Jan Beulich , Jason Andryuk 
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-12-dpsmith@apertussolutions.com>
 <99177823-38d9-4aca-af84-150ae6f37a25@amd.com>
 <4dbd5882-0724-4023-9c0e-43c82eba2b80@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <4dbd5882-0724-4023-9c0e-43c82eba2b80@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 12/2/24 07:00, Jan Beulich wrote:
> On 26.11.2024 00:45, Jason Andryuk wrote:
>> On 2024-11-23 13:20, Daniel P. Smith wrote:
>>> @@ -186,6 +209,12 @@ static int __init process_domain_node(
>>>            return -EFAULT;
>>>        }
>>>    
>>> +    if ( bd->domid == DOMID_INVALID )
>>> +        bd->domid = get_initial_domain_id();
>>> +    else
>>> +        if ( bd->domid != get_initial_domain_id() )
>>
>> single line "else if"?
> 
> Yes.

Agreed.

>>> +            printk(XENLOG_WARNING "WARN: unsuported booting not using initial domid\n");
>>
>> "unsupported"
>>
>> Maybe "Booting without initial domid not supported"?
> 
> Plus the line then wants splitting after XENLOG_WARNING.

Okay.

v/r,
dps



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 16:21:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 16:21:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854975.1268032 (Exim 4.92)
	(envelope-from )
	id 1tLPTC-0003ti-Hb; Wed, 11 Dec 2024 16:21:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854975.1268032; Wed, 11 Dec 2024 16: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 1tLPTC-0003tb-EU; Wed, 11 Dec 2024 16:21:50 +0000
Received: by outflank-mailman (input) for mailman id 854975;
 Wed, 11 Dec 2024 16:21: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 1tLPTB-0003tV-CI
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 16:21:49 +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 0379611b-b7dc-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 17:21:46 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733934097104724.0671274423535;
 Wed, 11 Dec 2024 08:21: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: 0379611b-b7dc-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1733934099; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=YpQhe8RLm08Q/aT13SNKzLXP2vwFKx360kyGduZVhXxvHFHV8sUjSS2I9valcIBPcPSuj0Gpq7A6YBw2ItnFNBRYuzShDuiReJsXSCKT5eQTd5C0S1gcqAp0DT8YzOCyEyzX8WHG2e5olYckscEfvwKhH5yT5tbhwYaqRrfKWH4=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733934099; 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=kH4d+UX9lpjjueWcRRnkZOevrY0+M4h1bEj5p/ijAQk=; 
	b=ZsCNBle8aLkFEPM72jjlTByMRppLCG4o5KJoWbggtHHdfuQa+7vBYF04DWctj8rXf+niQ6Z929H2eFV7aMGvc4fB521UnkSBI3WAg+EiNVnTaG1aK3ttSZm4BFVAzhH1McXCoWloPivoHu0aro2oOQkXzS8sjWJ9f3tdgYqXwII=
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=1733934099;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=kH4d+UX9lpjjueWcRRnkZOevrY0+M4h1bEj5p/ijAQk=;
	b=O4nCcbo6SZsPfv8WlzRkCE7YecKL6SbJNX/ufTYOumwIvd1rEzuMSGHNcrBcXFLM
	mqriNZF9xAfGCITpCc+FUxWECi5ZqJCqyTA8AntuhqhNbewBUOjnXsbapIRB4T4GzwD
	mEVuTf0dODivG+P5yvrckA1yn2X4sI7rH08o+8CM=
Message-ID: 
Date: Wed, 11 Dec 2024 11:21:35 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 11/15] x86/hyperlaunch: add domain id parsing to domain
 config
To: Jan Beulich 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-12-dpsmith@apertussolutions.com>
 <8a492a4d-cc9c-4756-8fb9-721626c295a6@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <8a492a4d-cc9c-4756-8fb9-721626c295a6@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 12/2/24 07:02, Jan Beulich wrote:
> On 23.11.2024 19:20, Daniel P. Smith wrote:
>> --- a/xen/arch/x86/domain_builder/fdt.h
>> +++ b/xen/arch/x86/domain_builder/fdt.h
>> @@ -27,6 +27,24 @@ static inline int __init fdt_cell_as_u64(const fdt32_t *cell, uint64_t *val)
>>       return 0;
>>   }
>>   
>> +static inline int __init fdt_prop_as_u32(
>> +    const struct fdt_property *prop, uint32_t *val)
>> +{
>> +    if ( !prop || fdt32_to_cpu(prop->len) < sizeof(u32) )
>> +        return -EINVAL;
>> +
>> +    return fdt_cell_as_u32((fdt32_t *)prop->data, val);
>> +}
>> +
>> +static inline bool __init match_fdt_property(
>> +    const void *fdt, const struct fdt_property *prop, const char *s)
>> +{
>> +    int slen, len = strlen(s);
> 
> Plain int isn't quite appropriate for strlen()'s return. It doesn't strictly
> need to be size_t, but it should be at least unsigned int.

Ack.

>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -1020,7 +1020,8 @@ static struct domain *__init create_dom0(struct boot_info *bi)
>>           dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
>>   
>>       /* Create initial domain.  Not d0 for pvshim. */
>> -    bd->domid = get_initial_domain_id();
>> +    if ( bd->domid == DOMID_INVALID )
>> +        bd->domid = get_initial_domain_id();
> 
> Looks like the comment then wants to move, too.

Okay.

v/r,
dps



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 16:25:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 16:25:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854987.1268041 (Exim 4.92)
	(envelope-from )
	id 1tLPW6-000533-TT; Wed, 11 Dec 2024 16:24:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854987.1268041; Wed, 11 Dec 2024 16:24:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLPW6-00052w-Qu; Wed, 11 Dec 2024 16:24:50 +0000
Received: by outflank-mailman (input) for mailman id 854987;
 Wed, 11 Dec 2024 16:24: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 1tLPW5-00052q-Dx
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 16:24:49 +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 6f442f46-b7dc-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 17:24:47 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733934279475558.1676705814723;
 Wed, 11 Dec 2024 08:24: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: 6f442f46-b7dc-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1733934281; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=fMWfA2sfkldlFLZX+4QpMTJBKxXob/l+EggJVuoSWGgT4OuwCB5XGbMTa+R1enN9lN3iaa91V02uZKZkYRMyX3LFgaM5+lXbHbJYTfPmFmAMZHknCDH5zrOAIxXFsQfjcPJJcuLDfjUAE3TnuZ7IGkt7PGA2nxC+I69MuXzaa+U=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733934281; 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=KXHtkkYxwv+cpccP6f5l6OxNxOBBConw8tM135nSlWw=; 
	b=bIjO+hI/+DCoo/UclrkXXyl6Jw81CrFQIAr1tc8ocpzlnFIGHDvkThZUh7UUfhNOADzud2+FiRi9tCzJ1fiS+c8y0/loFAV9pJLSLnHm9Qizu1uZy8jK4S7B1+4ye6IlPfh2LbUgSCOYLBlgyRAhimtQsZZvlnNIoYpUPCo379I=
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=1733934281;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=KXHtkkYxwv+cpccP6f5l6OxNxOBBConw8tM135nSlWw=;
	b=JkvzHSdUEJPlRhE01ydMwGhgJWJUeZP7tPP4yvs9AKkOeSOMYLtuRtJE4NyRkNHx
	IDbiXys3zqPYP6U7RJox8GSvB0zAWNV5QY8Vzv+r5wpHIW9EWsz5+fR5aWIqThRquLA
	rl62ozyRxUSqraW3WuWcdtCn9e3uguS8jDU80bL0=
Message-ID: <688a2399-d0e9-4f1a-97af-037722dabc98@apertussolutions.com>
Date: Wed, 11 Dec 2024 11:24:37 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 12/15] x86/hyperlaunch: specify dom0 mode with device tree
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com,
 Jan Beulich , Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-13-dpsmith@apertussolutions.com>
 
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

On 11/25/24 18:52, Jason Andryuk wrote:
> On 2024-11-23 13:20, Daniel P. Smith wrote:
>> Enable selecting the mode in which the domain will be built and ran. This
>> includes:
>>
>> - whether it will be either a 32/64 bit domain
>> - if it will be run as a PV or HVM domain
>> - and if it will require a device model (not applicable for dom0)
>>
>> In the device tree, this will be represented as a bit map that will be 
>> carried
>> through into struct boot_domain.
>>
>> Signed-off-by: Daniel P. Smith 
> 
> Reviewed-by: Jason Andryuk 

Thanks!

> 32/64 is only applicable for PV.  It might be worth mentioning that.

Ack.

v/r,
dps



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 16:31:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 16:31:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.854999.1268052 (Exim 4.92)
	(envelope-from )
	id 1tLPcX-00072F-IP; Wed, 11 Dec 2024 16:31:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 854999.1268052; Wed, 11 Dec 2024 16:31: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 1tLPcX-000728-FW; Wed, 11 Dec 2024 16:31:29 +0000
Received: by outflank-mailman (input) for mailman id 854999;
 Wed, 11 Dec 2024 16:31: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 1tLPcV-000722-U4
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 16:31:27 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5cb2b010-b7dd-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 17:31:25 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733934674116550.6665648094927;
 Wed, 11 Dec 2024 08:31: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: 5cb2b010-b7dd-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1733934678; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=hI2lXc/6Fpg/yNSiQdrgDkyVg4tJ5U1PVq6wJnc4YfmJ7NiFtgQQ3rJvqFutJo3JTXfzDMV92QG2/nQ2uT7fP670cPI/fApqRRilVNopsvVExpw1/YM6dnKUj4mDVRaX4dv7a3HTqRQIn3J77kDYafF64bO+bzu2DPHU7kC+J5E=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733934678; 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=Olq2bonr4k+ZwG6WegzbYkZheckvZONs+NRQZPix5e8=; 
	b=FVcKkX9/qcp+dvLTP8jrFZFsgRLUlm4PYE/AsoY2NSFdXzvvSWwq/iTL4ZJB73GFSTaLL77sA1RGk/JzFkQxzP6VkrpDmKzKAm+T9G7Ak6rgMwHAOcRjZPYzpIPlxgrDNHsGNUG8svrotalKkiFDNPHZ2sXBkzSyWmkYJ8ZpXuI=
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=1733934678;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=Olq2bonr4k+ZwG6WegzbYkZheckvZONs+NRQZPix5e8=;
	b=mPZW5Wf+dmFcO+TxaThk4puXLf8ZF/IJ5pIMzfX/EpPizQ84RFRnWo12atklCOS0
	Q5cHVbd4Nvdn0en/r1NwVZPofkaCKt+oiJSmpQtiKEv5YAx5toq4zYnEfNW/jxcZotG
	FOGBlWIdV0nHwhNNIEKTdfbjysfSLtP/2kAK83oE=
Message-ID: <593d78d7-93fd-47a1-86f6-30ef8a9b23d1@apertussolutions.com>
Date: Wed, 11 Dec 2024 11:31:12 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 12/15] x86/hyperlaunch: specify dom0 mode with device tree
To: Jan Beulich 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-13-dpsmith@apertussolutions.com>
 <5dc478be-7b8a-4966-8889-d4d40bda8770@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <5dc478be-7b8a-4966-8889-d4d40bda8770@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 12/2/24 07:05, Jan Beulich wrote:
> On 23.11.2024 19:20, Daniel P. Smith wrote:
>> --- a/xen/arch/x86/domain_builder/fdt.c
>> +++ b/xen/arch/x86/domain_builder/fdt.c
>> @@ -141,6 +141,25 @@ static int __init process_domain_node(
>>               bd->domid = (domid_t)val;
>>               printk("  domid: %d\n", bd->domid);
>>           }
>> +        if ( match_fdt_property(fdt, prop, "mode" ) )
>> +        {
>> +            if ( fdt_prop_as_u32(prop, &bd->mode) != 0 )
>> +            {
>> +                printk("  failed processing mode for domain %s\n",
>> +                       name == NULL ? "unknown" : name);
>> +                return -EINVAL;
>> +            }
>> +
>> +            printk("  mode: ");
>> +            if ( !(bd->mode & BUILD_MODE_PARAVIRT) ) {
> 
> Nit: Brace placement.

Ack.

>> +                if ( bd->mode & BUILD_MODE_ENABLE_DM )
>> +                    printk("HVM\n");
>> +                else
>> +                    printk("PVH\n");
>> +            }
>> +            else
>> +                printk("PV\n");
>> +        }
>>       }
>>   
>>       fdt_for_each_subnode(node, fdt, dom_node)
>> --- a/xen/arch/x86/include/asm/bootdomain.h
>> +++ b/xen/arch/x86/include/asm/bootdomain.h
>> @@ -18,6 +18,12 @@ struct boot_domain {
>>   
>>       domid_t domid;
>>   
>> +                                          /* On     | Off    */
>> +#define BUILD_MODE_PARAVIRT      (1 << 0) /* PV     | PVH/HVM */
>> +#define BUILD_MODE_ENABLE_DM     (1 << 1) /* HVM    | PVH     */
>> +#define BUILD_MODE_LONG          (1 << 2) /* 64 BIT | 32 BIT  */
> 
> This last one isn't used anywhere, is it?

Hmm, I may have lost this when AMD asked for PVH to be done this cycle. 
It should still be used to allow for 32bit PV dom0, will get this added in.

>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -1006,7 +1006,8 @@ static struct domain *__init create_dom0(struct boot_info *bi)
>>       struct boot_domain *bd = &bi->domains[0];
>>       struct domain *d;
>>   
>> -    if ( opt_dom0_pvh )
>> +    if ( opt_dom0_pvh ||
>> +         (bi->hyperlaunch_enabled && !(bd->mode & BUILD_MODE_PARAVIRT)) )
>>       {
>>           dom0_cfg.flags |= (XEN_DOMCTL_CDF_hvm |
>>                              ((hvm_hap_supported() && !opt_dom0_shadow) ?
> 
> What about BUILD_MODE_ENABLE_DM?

Good point, a goal for HL was to enable building and booting with 
separate hwdom and ctldom.

v/r,
dps



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 16:50:26 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 16:50:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855015.1268068 (Exim 4.92)
	(envelope-from )
	id 1tLPuo-0003sx-3g; Wed, 11 Dec 2024 16:50:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855015.1268068; Wed, 11 Dec 2024 16:50: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 1tLPuo-0003sq-0e; Wed, 11 Dec 2024 16:50:22 +0000
Received: by outflank-mailman (input) for mailman id 855015;
 Wed, 11 Dec 2024 16:50: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 1tLPun-0003sk-99
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 16:50:21 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 017032c5-b7e0-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 17:50:19 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5ceb03aadb1so9282905a12.0
 for ; Wed, 11 Dec 2024 08:50:19 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa68dd43cefsm446467566b.50.2024.12.11.08.50.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 08:50:18 -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: 017032c5-b7e0-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733935819; x=1734540619; 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=pLMiFfwhC8a0yqC/bDgoQoZXUS/bRDEPn5cFlllzpKA=;
        b=D2mFh1lPiVg8YlTDK/itWfe4VOVuw+UMHXWMRNu7HEbbL+JSwv5cyIcyY7YVap+BtX
         Ibjlgh8pXLvdRISn52GJlZMS/0FsYgtouIuGpFUGexIITNMl731vhxFdab01sl0IpEqi
         DJgtf5g02kGvm1q2yD4E+4Hr8Su/wrjI5R21s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733935819; x=1734540619;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pLMiFfwhC8a0yqC/bDgoQoZXUS/bRDEPn5cFlllzpKA=;
        b=icmAhnBZYbOc3eTPCgk1cQvMvulinPwFAvw424o77pPq9S/nGUYHWTYF/Ql0L/D/H2
         rZ7NbZHDVpMtph195bAc+ajb5LD8T6hPM79crrb/MnFhqiSX3kDcLUAE5VLB63ctrEwA
         IsFi+v0/wYie1KGtdTcGGGBMLSAtqsyy6WPVRim3H+MUTzzfOvFdQBsx0uVkBOeL1Dl7
         TyzBgi1fxxy0UbgyrvzGRANQzC6cPQG/FYqwSCBs7YF47O95Mq7LCaNy/57cAfuRl37g
         9JkhA9YrOIieykCA8C9qsw65BqTdrkpf3xWakOg8hRhkqlRSBXDhMXDPsOh33ZBFEYF9
         PcOw==
X-Gm-Message-State: AOJu0Yzn1M4Ts97Lekxui3D86jCdzBgu9EzdKLANdIGOVBM0LGNfGOnp
	pHToUNMsISCBy05pR9vjlM63LEx1nVmhqi3IY2e6DsqigZ+iSkW/PKuOXvmZK0w=
X-Gm-Gg: ASbGncsn7tVVKT8hQJIO3cveEk6ChiC1IJTD7sptDT3TkzebKbySlWHkfNRI6ExRdK0
	zH44RlzxRvW1pOXvGXI5l0Gvk1uS9i1ByNZ++4iUAwKyGbosY2w1/nDXW7ieB2Jj4AZQ79L1LDm
	rf3+ngln4TTlbfMPa1F0Ks5DcYUFDmJ2aGGNuzXbvVOIQEsy8hVGQAHs1HjtCsvYYN7tVKNIgPy
	jnClTMLFJ31ezkHDcDGE/C4W35GmljsRuWhSNFzpnRX+AiyU2Ss0ppowlzMHUs=
X-Google-Smtp-Source: AGHT+IFypkB8NucOPuGWCLdC7YWk1nBW+hgxfxNpOufkx5PB3hr0aSkHS8jTvDwIYT+toSTZ31p0Dg==
X-Received: by 2002:a17:906:31cc:b0:aa6:93c4:c68c with SMTP id a640c23a62f3a-aa6b13964d1mr380231366b.41.1733935819147;
        Wed, 11 Dec 2024 08:50:19 -0800 (PST)
Date: Wed, 11 Dec 2024 17:50:17 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 10/35] xen/domain: add get_initial_domain_id()
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-10-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-10-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:41:40PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Move get_initial_domain_id() to a public API and enable for all architectures.
> That is pre-requisite change for console focus switch logic cleanup.
> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/arch/x86/include/asm/pv/shim.h |  4 ++--
>  xen/arch/x86/pv/shim.c             |  4 ++--
>  xen/common/domain.c                | 10 ++++++++++
>  xen/include/xen/domain.h           |  2 ++
>  4 files changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/x86/include/asm/pv/shim.h b/xen/arch/x86/include/asm/pv/shim.h
> index 6153e27005986881ad87e9db0b555b30edc59fc0..1515ad1b0680aa11ab91a152a1944fc1bb477a79 100644
> --- a/xen/arch/x86/include/asm/pv/shim.h
> +++ b/xen/arch/x86/include/asm/pv/shim.h
> @@ -31,7 +31,7 @@ long cf_check pv_shim_cpu_up(void *data);
>  long cf_check pv_shim_cpu_down(void *data);
>  void pv_shim_online_memory(unsigned int nr, unsigned int order);
>  void pv_shim_offline_memory(unsigned int nr, unsigned int order);
> -domid_t get_initial_domain_id(void);
> +domid_t pv_shim_initial_domain_id(void);
>  uint64_t pv_shim_mem(uint64_t avail);
>  void pv_shim_fixup_e820(void);
>  const struct platform_bad_page *pv_shim_reserved_pages(unsigned int *size);
> @@ -76,7 +76,7 @@ static inline void pv_shim_offline_memory(unsigned int nr, unsigned int order)
>  {
>      ASSERT_UNREACHABLE();
>  }
> -static inline domid_t get_initial_domain_id(void)
> +static inline domid_t pv_shim_initial_domain_id(void)
>  {
>      return 0;
>  }
> diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
> index 81e4a0516d18b359561f471f1d96e38977661ca7..17cb30620290c76cf42251f70cfa4199c0e165d1 100644
> --- a/xen/arch/x86/pv/shim.c
> +++ b/xen/arch/x86/pv/shim.c
> @@ -328,7 +328,7 @@ int pv_shim_shutdown(uint8_t reason)
>      }
>  
>      /* Update domain id. */
> -    d->domain_id = get_initial_domain_id();
> +    d->domain_id = pv_shim_initial_domain_id();

Can't you leave this instance using get_initial_domain_id(), it should
DTRT when running in pv-shim mode.

>  
>      /* Clean the iomem range. */
>      BUG_ON(iomem_deny_access(d, 0, ~0UL));
> @@ -1016,7 +1016,7 @@ void pv_shim_offline_memory(unsigned int nr, unsigned int order)
>      }
>  }
>  
> -domid_t get_initial_domain_id(void)
> +domid_t pv_shim_initial_domain_id(void)
>  {
>      uint32_t eax, ebx, ecx, edx;
>  
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 92263a4fbdc57159b4a32d9d4ee038f9f37804ed..2f67aa06ed50e69c27cedc8d7f6eb0b469fe81cd 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -45,6 +45,7 @@
>  
>  #ifdef CONFIG_X86
>  #include 
> +#include 
>  #endif
>  
>  /* Linux config option: propageted to domain0 */
> @@ -2229,6 +2230,15 @@ int continue_hypercall_on_cpu(
>      return 0;
>  }
>  
> +domid_t get_initial_domain_id(void)
> +{
> +#ifdef CONFIG_X86
> +    return pv_shim_initial_domain_id();
> +#else
> +    return 0;
> +#endif
> +}

Maybe there are further changes that make this a not suitable option,
but won't it be better to maybe do something like:

#ifndef HAS_ARCH_INITIAL_DOMID
static inline domid_t get_initial_domain_id(void) { return 0; }
#else
domid_t get_initial_domain_id(void);
#endif

In a generic header, and then in an x86 header you just

#define HAS_ARCH_INITIAL_DOMID

The ifdefary in get_initial_domain_id() if other arches need different
implementations seems undesirable.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 17:00:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 17:00:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855036.1268078 (Exim 4.92)
	(envelope-from )
	id 1tLQ4x-0007FU-3S; Wed, 11 Dec 2024 17:00:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855036.1268078; Wed, 11 Dec 2024 17:00: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 1tLQ4w-0007FN-W0; Wed, 11 Dec 2024 17:00:50 +0000
Received: by outflank-mailman (input) for mailman id 855036;
 Wed, 11 Dec 2024 17:00: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 1tLQ4w-00075X-4s
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 17:00:50 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 78cc85aa-b7e1-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 18:00:49 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-aa543c4db92so622967966b.0
 for ; Wed, 11 Dec 2024 09:00:49 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa65d870db9sm697689966b.203.2024.12.11.09.00.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 09:00: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: 78cc85aa-b7e1-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733936449; x=1734541249; 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=T3rrIoUY8eGTHYPZYuz6VI2qo5rwAkwDMw4Whb6+iVA=;
        b=sEFbgp4WAtm0v/J+z2wYRmPio33NpQEfO0ZSV82P/kXQzer85w/f2asL9OWN75BAGI
         aaBJnVE3hv4Qb2n3NSHrtIdZ/6Z8BdW98V0x7nfvvlFhLdkDeaNGVBYPf2LELOf5voPB
         H2q6fjLE4TkBnFMyMVHBem29ML0FCf69W2fcc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733936449; x=1734541249;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=T3rrIoUY8eGTHYPZYuz6VI2qo5rwAkwDMw4Whb6+iVA=;
        b=V0ugFJiEpIIsUeOp3czE595dgljSJtDfPK7LKFlCO5HbiGoklzG712e153uQsKyq0x
         tGhYoFobOnVWLaI2+vg+gC8gInNPfmVL3l0Pla1Fkxbz6X/kI9OtLj5ipS4G0RvcJfuQ
         54nS1L66N9cbD4erka1PnBwhPG5GeYmleiHQ97YRIqiSiAobvjVlM0mo14wxJfIi57Qr
         C4GQG0DFfENhtGHnPcEpiPrQYeHHv712sGMuozOKwI+j2VRFRNvIU1duGdlPmbRrO7ZF
         dIGGamB6UqFnpcHqUDOzy5+trOmOuha5jD3szLkojCTYNc2kQctwaMJln8E3NYWo14Jy
         gIgA==
X-Gm-Message-State: AOJu0YyPBtqg0NG/Qxc/XrUwyl/LGV9/aB2GDEBd+ly2j1cPyyfAsxpr
	Sc1aWDSKo8O/1DsJoFo9KII/Mx4wF2B1h4G/stOM0YE8iZ0UsKHSb1Oq5eZBK4k=
X-Gm-Gg: ASbGnctc1oywe5NZgp0bmmIGatksZ1Jj/lix367+KLgd7rviS+MSx8uIS6z4k0RR8Cl
	a1ukeCUWk1ddv1sfkJDzpZg7ibKv/B7nP6EwCWnyKL/+FyVTA25OKqYVW+0WhZ8CIUvCjn9S1ow
	X9DgbSYeMd/DQwDaxEwqkniClNeKDx+Djy1gNK+TUI8VSp+TY7fCYObzYFR8YETo7Q0tbb/lvb8
	ipGEu+ShimAUVInDki7ssgreQQErH+G+BoAPPf8ZcOKu+d5rl5egMTSIVLk+Fc=
X-Google-Smtp-Source: AGHT+IGaoYWTscHaKVMY4S7R1uZqi/YDwO64By5BA35vIjHDle1ciR93g35FnT7RnOnhZ053U8yJpA==
X-Received: by 2002:a17:907:9554:b0:aa6:ac4c:8dc with SMTP id a640c23a62f3a-aa6b117feb1mr309278966b.18.1733936448887;
        Wed, 11 Dec 2024 09:00:48 -0800 (PST)
Date: Wed, 11 Dec 2024 18:00:47 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 11/35] xen/domain: enable max_init_domid for all
 architectures
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-11-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-11-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:41:41PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Move max_init_domid to a public API and enable for all architectures.
> That is pre-requisite change for console focus switch logic cleanup.
> 
> max_init_domid is updated in domain_create().
> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/arch/arm/include/asm/setup.h   | 2 --
>  xen/arch/arm/setup.c               | 2 --
>  xen/arch/ppc/include/asm/setup.h   | 2 --
>  xen/arch/riscv/include/asm/setup.h | 2 --
>  xen/arch/x86/include/asm/setup.h   | 2 --
>  xen/common/domain.c                | 9 +++++++++
>  xen/include/xen/domain.h           | 2 ++
>  7 files changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
> index 64c227d171fc7b92e5b62d9fd42e5662871bd12b..d4e1670cd69cdd4475b2a5eb316d2c0601090ed7 100644
> --- a/xen/arch/arm/include/asm/setup.h
> +++ b/xen/arch/arm/include/asm/setup.h
> @@ -19,8 +19,6 @@ struct map_range_data
>      struct rangeset *irq_ranges;
>  };
>  
> -extern domid_t max_init_domid;
> -
>  void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
>  
>  size_t estimate_efi_size(unsigned int mem_nr_banks);
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 2e27af4560a504bf57daef572d4a768bd886145b..cb218fe3eb36f2cdda47cfa092fa99ee1ca4a14c 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -58,8 +58,6 @@ struct cpuinfo_arm __read_mostly system_cpuinfo;
>  bool __read_mostly acpi_disabled;
>  #endif
>  
> -domid_t __read_mostly max_init_domid;
> -
>  static __used void init_done(void)
>  {
>      int rc;
> diff --git a/xen/arch/ppc/include/asm/setup.h b/xen/arch/ppc/include/asm/setup.h
> index e4f64879b68ca5aac24bd9544255143e6ef693f3..956fa6985adb23375bd41d3e5d34d9d5f0712bd5 100644
> --- a/xen/arch/ppc/include/asm/setup.h
> +++ b/xen/arch/ppc/include/asm/setup.h
> @@ -1,6 +1,4 @@
>  #ifndef __ASM_PPC_SETUP_H__
>  #define __ASM_PPC_SETUP_H__
>  
> -#define max_init_domid (0)
> -
>  #endif /* __ASM_PPC_SETUP_H__ */
> diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/include/asm/setup.h
> index 844a2f0ef1d762b3a9bc90b61a336a23f1693cc9..978cad71d3df484e80ba19acc0e37b9278e941f0 100644
> --- a/xen/arch/riscv/include/asm/setup.h
> +++ b/xen/arch/riscv/include/asm/setup.h
> @@ -3,8 +3,6 @@
>  #ifndef ASM__RISCV__SETUP_H
>  #define ASM__RISCV__SETUP_H
>  
> -#define max_init_domid (0)
> -
>  void setup_mm(void);
>  
>  #endif /* ASM__RISCV__SETUP_H */
> diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
> index 5c2391a8684b66efdf4b092409ed33935db6b40c..296348655b9d146c73acc305cc9edd5fd46f7d47 100644
> --- a/xen/arch/x86/include/asm/setup.h
> +++ b/xen/arch/x86/include/asm/setup.h
> @@ -69,6 +69,4 @@ extern bool opt_dom0_verbose;
>  extern bool opt_dom0_cpuid_faulting;
>  extern bool opt_dom0_msr_relaxed;
>  
> -#define max_init_domid (0)
> -
>  #endif
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 2f67aa06ed50e69c27cedc8d7f6eb0b469fe81cd..9e57dd4122a726e2fb42efe9c029e775202be0e6 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -65,6 +65,9 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
>  static struct domain *domain_hash[DOMAIN_HASH_SIZE];
>  struct domain *domain_list;
>  
> +/* Last known non-system domain ID. */
> +domid_t __read_mostly max_init_domid;

The comment (and implementation below) seems to differ from what Arm
dom0less code currently uses the variable for.

> +
>  /*
>   * Insert a domain into the domlist/hash.  This allows the domain to be looked
>   * up by domid, and therefore to be the subject of hypercalls/etc.
> @@ -815,6 +818,12 @@ struct domain *domain_create(domid_t domid,
>  
>      memcpy(d->handle, config->handle, sizeof(d->handle));
>  
> +    /*
> +     * Housekeeping for physical console forwarding to the domain.
> +     */
> +    if ( !is_system_domain(d) && max_init_domid < domid )
> +        max_init_domid = domid;

Don't you need to adjust the ARM dom0-less logic that deal with
increasing max_init_domid in create_domUs().

Also max_init_domid likely only wants to be updated for domains
created before the control domain is started, and hence could be
__ro_after_init instead of __read_mostly?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 17:17:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 17:17:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855053.1268087 (Exim 4.92)
	(envelope-from )
	id 1tLQLL-0003Y3-Gl; Wed, 11 Dec 2024 17:17:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855053.1268087; Wed, 11 Dec 2024 17:17: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 1tLQLL-0003Xw-EE; Wed, 11 Dec 2024 17:17:47 +0000
Received: by outflank-mailman (input) for mailman id 855053;
 Wed, 11 Dec 2024 17:17: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 1tLQLK-0003Xq-3W
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 17:17:46 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d5b1f341-b7e3-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 18:17:44 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-a9e8522445dso1394451566b.1
 for ; Wed, 11 Dec 2024 09:17:44 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa6810027c6sm544289766b.104.2024.12.11.09.17.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 09:17: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: d5b1f341-b7e3-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733937464; x=1734542264; 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=+oA6uBMeNeBGYQGZMVyk7EeoK1zX0WhrNfAcgKqAqmE=;
        b=K6YG+Yu3iCGBoHmCm6DY9co5NefdXOFz824LHGBhAHAozEkRsD6eQjtY97j1Ah1SwM
         WrWo5k75CXFhX4Yv14cZSTNH8kx87cqCsEN/UUsSNX5WEnvWvmFn7vuIAL5qvQn1wvj2
         KvVKwS7tRFxvCQo0/r97nZhygwPagDDq4XhXY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733937464; x=1734542264;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+oA6uBMeNeBGYQGZMVyk7EeoK1zX0WhrNfAcgKqAqmE=;
        b=B38MiV+/u/9oguucpW/6fe3ODaAch2tFoF+Jx4crFt6AjsHnhaCtgSJSLYaIDYfVVZ
         PCWa+NXch5pvIzjK1YfdOUJxxX4+gY6Y62L896hYPvMTk0PyDQoRpEZsM6S8rgaeET37
         NHccMdTPCWsvPWt9QoCeYNxGNqA334H+C/2GSrBmDLPWERkzOKtY7CWchxjK5XqG5fFQ
         uLXDdpNmOUOKlb2IR6ZwpdLBJEbGbyZScvzwwJBFl/HQI1De3BanuesFcw4ruRQGelDT
         af5Yoi4mldrE0N/efp3TkrUfO8NzQUBUtoTxW+d8eFnpkz+477ZlyYaFHZHucvB4SU6Z
         p2Wg==
X-Gm-Message-State: AOJu0YzJp59z0DKdLt/TxCOrMsz6t2YAjhPbpilTyp6mljcFb09mMwjF
	NbCsgsDBvhqxeXRVcs3GMTqvcKZ0Ho/ppv64DU9sxGUgGBw+NF/yhSnNAod7aEM=
X-Gm-Gg: ASbGnctPs0DzieG7eXZsvOqzQ+s211wiqv4DSCz+cDDiLXJt7rIZOUxyPA+5rTpPYWv
	w0RIVReBj+P+LWH2NybRxDs2iyT+VFf0dY0/gVlwBW0CnXRQjDopjlb3iXSll1hOmuQ2z6bKmto
	L30vs9D+yJKj84Mh5c3KH2BAp7b0pij5dXNVRq71AFqBiqyYuHfK6WBrL/9MbeVbWfnDMqJ/sFW
	B9OfpQN+/fL6vyVD6djvdDfOZZronCSccWfe+pU6+DrT7Et0v4iBphe+aWsYak=
X-Google-Smtp-Source: AGHT+IHdzPanXR0vjr+2wSAdKn+jT972sOb9SSTC3pjHDGvkCpKT7IzX0bK711f5DKnKZ6MtapvtTQ==
X-Received: by 2002:a17:907:8690:b0:aa6:a844:8791 with SMTP id a640c23a62f3a-aa6b1395887mr457554566b.45.1733937463799;
        Wed, 11 Dec 2024 09:17:43 -0800 (PST)
Date: Wed, 11 Dec 2024 18:17:42 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 13/35] xen/console: rename console_input_domain
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-13-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-13-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:41:43PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> console_input_domain() takes an RCU lock to protect domain structure.
> That implies call to rcu_unlock_domain() after use.
> 
> Rename console_input_domain() to rcu_lock_domain_console_owner() to
> highlight the need of calling rcu_unlock_domain().
> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/arch/arm/vpl011.c      | 2 +-
>  xen/drivers/char/console.c | 2 +-
>  xen/include/xen/console.h  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> index fe36fe2bd1529a4114884580ded6d6fa55a22f0e..4d682e98553303b4a12f5cd7e5e67ab096cd7cc2 100644
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -78,7 +78,7 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t data)
>      unsigned long flags;
>      struct vpl011 *vpl011 = &d->arch.vpl011;
>      struct vpl011_xen_backend *intf = vpl011->backend.xen;
> -    struct domain *input = console_input_domain();
> +    struct domain *input = rcu_lock_domain_console_owner();

May I suggest console_get_domain() and then introducing a
console_put_domain() which is just a wrapper around
rcu_unlock_domain()?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 17:22:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 17:22:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855065.1268098 (Exim 4.92)
	(envelope-from )
	id 1tLQQ8-0005am-2j; Wed, 11 Dec 2024 17:22:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855065.1268098; Wed, 11 Dec 2024 17:22:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLQQ7-0005af-V4; Wed, 11 Dec 2024 17:22:43 +0000
Received: by outflank-mailman (input) for mailman id 855065;
 Wed, 11 Dec 2024 17:22: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 1tLQQ6-0005ZQ-An
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 17:22:42 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 86b0b3e3-b7e4-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 18:22:41 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-a9f1c590ecdso1356936266b.1
 for ; Wed, 11 Dec 2024 09:22:41 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa6552b29a3sm712459166b.86.2024.12.11.09.22.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 09:22: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: 86b0b3e3-b7e4-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733937761; x=1734542561; 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=K/ibFxfCI8ItX4HxT3HM8aX31ulpCqJOz4MjteRnl5E=;
        b=Te1i54JoRoCFbDi0XzORCUTRD4ABsEe+dLhp4LH3Kutqkqzu2G5QmFGA82bJBFlNVG
         j2p3/SvJ0YJnv4VTndS9B43ig+UGSr1MZSzbt2fE3GtSHmenIyyJI+6UoddPcHweS6Hk
         5vseD3CgUmVPOh8/16xV76jJzqSpUG30QhJpM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733937761; x=1734542561;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=K/ibFxfCI8ItX4HxT3HM8aX31ulpCqJOz4MjteRnl5E=;
        b=bGDtjj8HoTtCyfEW3CsaJM+PXlSAgj5kPISPUcomIBOuxLRSdG9Az8lRsZM46rS4Gq
         ACMdO1jqe9Vfk4lx7dAQgU6vVtjEh6yYwjTpXDf+jogrH49dbGkw8cXX92t3mzqt8l7g
         TixE+1rGkP5IGwwj7bXJFzL7iqeaLNZAGqn0weFjGWjMoJSmsI8iHGJNI9gWoeva1KsP
         tRQlCJ884M3v8lcokrt54tSyF0Vixg2E8D5uY1IyOa3/LCZX6Ehhvbh7J5bgdUabRlxh
         YYpNg1ZgKMKYm76W+ZenAZpLUDs8bKCuuadx1yVPlmZ9syLhklSFQtar48ZTzLdn1LcY
         AQjQ==
X-Forwarded-Encrypted: i=1; AJvYcCUQ2Va5nUNeCySoUVBGqYmKz/W9Val67L88PY5WqZwNHsDlHxbB12PeA6xD2+pdbqaqC46Ls/Hz+dE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwLVI8342OaXHLGX+pkNZArXIZpMZlXtbhsQXYpO6Y+CXsp/G4G
	I2WYO2G0sK9DHEI1gDIQlCg2/tIgutafIpSmZjOrtCnDJ+8KkWUh11KjRRA837mNCyj51m8pTAd
	G
X-Gm-Gg: ASbGncuqRlB1/HKfTS37pRyEiROuOJADzjzLqL8JanWkb+HerY7z2VzmUpALjY+FkEL
	UpVBslqvzwjl9LS3fsMKk1UUj0f3R3oKY+nS6qtTuD9pgXY9hUFqq4EsPSXauQlPUp+bORIQTP8
	0phkMvPn8Lp+3PIQQ4S9cjSWJQqOILAFZo6c3cPJXGOOnCCJ1UNcwgaEPJijs2SPOlKDAhEOWTm
	fgcHQXmgZmzd9XLBTursNTsA3zCg1k0ZB5w97OhoH59le9V16FkzezcP/5HCSc=
X-Google-Smtp-Source: AGHT+IHwvH7L4iy2TVu65RLplBi4Hr2pEAGDXexUlBnnRJ7XTmjGXXRIWHe01qhdpSmxDPQ8bMdQew==
X-Received: by 2002:a17:907:84d4:b0:aa6:7107:db00 with SMTP id a640c23a62f3a-aa6b13f8044mr290918666b.50.1733937760805;
        Wed, 11 Dec 2024 09:22:40 -0800 (PST)
Date: Wed, 11 Dec 2024 18:22:39 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: dmukhin@ford.com, Andrew Cooper ,
	Julien Grall ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 14/35] xen/console: rename switch_serial_input() to
 console_find_owner()
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-14-e9aa923127eb@ford.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 

On Tue, Dec 10, 2024 at 03:13:20PM +0100, Jan Beulich wrote:
> On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> > From: Denis Mukhin 
> > 
> > Updated the name to highlight the logic of selection the physical console
> > owner: existing code does not switch only serial console, it also switches
> > video console and debugging console (debug I/O port and console hypercall).
> 
> I'm especially surprised you mention "video console" here. Afaics all of
> this is only about console _input_, and no input comes from a video device.
> Arguably "serial" in the original name is too narrow now. Yet "input"
> continues to be quite appropriate.

switch_console_input() maybe? switch_console_input_target() even?

I think the switch is also relevant, as it shuffles the input around,
console_find_owner() doesn't seem to convey that meaning.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 17:28:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 17:28:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855082.1268168 (Exim 4.92)
	(envelope-from )
	id 1tLQVK-0000JD-Bb; Wed, 11 Dec 2024 17:28:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855082.1268168; Wed, 11 Dec 2024 17:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLQVK-0000Hk-6i; Wed, 11 Dec 2024 17:28:06 +0000
Received: by outflank-mailman (input) for mailman id 855082;
 Wed, 11 Dec 2024 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 1tLQVI-0007JC-IC
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 17:28:04 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 46ee7ddc-b7e5-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 18:28:03 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5d414b8af7bso5464559a12.0
 for ; Wed, 11 Dec 2024 09:28:03 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa6656f306csm687297466b.61.2024.12.11.09.28.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 09:28: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: 46ee7ddc-b7e5-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1733938082; x=1734542882; 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=GWSH1TKGIXYk6lQDxdJzHqmgxJre5HbeAcdBxlqmawo=;
        b=bIn+98zm0J/yFYjrIpqMMy46v6pFV9B4cHanHLY3VvosZYeIixM4PBYU1auRLjj2Tb
         2YomqT644EdOiyXGDoBOJFa4NlX5vm4NZBw+1lsoWHV61sc7SqydKTb3oR0STm++1JVd
         4R4UuDR7XlmkNQIFTsEjy+qc8c24lpgGCD9P0faPdyYdbtds8wJr1Wx012dVRGkTPKTi
         mTGmw0HFhPrWj8ARfLiPtZpwNGooR/7bxNAs20kw3NrBipmVRK8NWSQ2+eOhzPiSEo4y
         8DPj5EOh4enRc3eCLaWPDXSvV3Qxsv212Oaf3KQwlhVMsWZkzgMfXYCtIMVjKvLn70oI
         Opxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733938082; x=1734542882;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=GWSH1TKGIXYk6lQDxdJzHqmgxJre5HbeAcdBxlqmawo=;
        b=BUcL4Ru6uWFdd8s8UGNi+074uqChOD4Ag6+b/sqU4frpOjzPtH0dkd9yyXKOGyxs2j
         W35Q0LW7/Dd6WON37S9Q1j5AwJMkC7737B42WFbmV/OewYesIBGczO+Q4J7vLhZQVeVT
         7Nu5bQFHzSx4J3HVlGH0JTyfYA9RBITnUC83hIDvnyfqUaHXukThxfnBItkjFi/PjyuJ
         oeqQXgbrZq363m42e/hZJEAThyybM5hLUBRVaDo05D4exAaJaIYklMDpUQB11hHNKqF6
         MnrELNoSrQ/9H2feUpRNUiZKIpWkxksg0WylCYEdvRG2Bh5oOPeOrhDySVqC7hw47M+Z
         V1FA==
X-Gm-Message-State: AOJu0YySMl6+ZwY4l6vur2D3+rKUFX9T8fveKZsOPLfhB8D7rF+8tp29
	0dtY/Da9OyXLJ/IKLxRIZ+NnIV5FRfc8sLy+b1Ez/dreh8JaagcKhwY0LLSN
X-Gm-Gg: ASbGncsh3fjWREjcexLpcPzSLAMHLQY8UclW2CHGiuv/HBQMZPM3o1O9xEhd67j42Wz
	n8byqHrLoT2ptGU5m7Z1TW0Q/V51GDLq2qimWkPe5AnavegYlJ9/ndznba03P5uUZaruwLvwCBb
	lYAkN93mamThxSJXYzyorQDai25iJQWmplaCNjocuB/VXR+TS50kJiVn0OOyvp12Azo0PQHi9CB
	nGXIcFioJSxGidwDKiL4KO5xA/5AObAtwJYiLIgMAnGZfgVh2X3Dq4=
X-Google-Smtp-Source: AGHT+IHbe07tD/GOgdxTxM0a2FBOELv2ZPSnPlzQYVX0S7GWmyenULQ+sfEkyhmENBGKMEnz6YDsVg==
X-Received: by 2002:a17:906:3182:b0:aa6:ac9b:6824 with SMTP id a640c23a62f3a-aa6c1ae4bbemr65539266b.5.1733938081636;
        Wed, 11 Dec 2024 09:28:01 -0800 (PST)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2 6/7] xen/riscv: implement prereq for DTB relocation
Date: Wed, 11 Dec 2024 18:27:50 +0100
Message-ID: <2d2d6ca32aa7db490d47154530f01216651ba335.1733937787.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

DTB relocatin in Xen heap requires the following functions which are
introduced in current patch:
- xvmalloc_array()
- copy_from_paddr()

For internal use of xvmalloc, the functions flush_page_to_ram() and
virt_to_page() are introduced. virt_to_page() is also required for
free_xenheap_pages().

Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - Drop variable directmap_virt_end.
 - Update ASSERT in virt_to_page() to use DIRECTMAP_VIRT_END instead of
   variable directmap_virt_end.
 - Declare local varibale v as const inside flush_page_to_ram().
 - Declare copy_from_paddr() in riscv/setup.h as in the future it will be
   used for copying kernel in guest memory.
 - Code style updates for copy_from_paddr().
 - Make l and s variable in copy_from_paddr() as the virables' initializers.
 - Drop call of clean_dcache_va_range(dst, l) in copy_from_paddr() as the
   necessiry of it is Arm-specific:
     After memcpy'ing the kernel in guest memory Arm need to flush the dcache
     to make sure that the data actually reaches the memory before we start
     executing guest code with caches disabled.
   RISC-V has caches always enabled thereby there is no such issue for RISC-V.
 - Make local variable src in copy_from_paddr() as const.
 - Update the commit message and subject: drop information of relocate_fdt()
   introduction and rename it to "prereq for DTB relocation".
 - Add BUG_ON() inside flush_page_to_ram() to check the return value of
   clean_and_invalidate_dcache_va_range().
 - Move relocate_fdt() introduction to the next patch to make this patch
   compilable.
---
 xen/arch/riscv/include/asm/mm.h    |  8 ++++++--
 xen/arch/riscv/include/asm/page.h  | 11 +++++++++--
 xen/arch/riscv/include/asm/setup.h |  4 ++++
 xen/arch/riscv/setup.c             | 26 ++++++++++++++++++++++++++
 4 files changed, 45 insertions(+), 4 deletions(-)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 699ed23f0d..292aa48fc1 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -148,8 +149,11 @@ static inline void *page_to_virt(const struct page_info *pg)
 /* Convert between Xen-heap virtual addresses and page-info structures. */
 static inline struct page_info *virt_to_page(const void *v)
 {
-    BUG_ON("unimplemented");
-    return NULL;
+    unsigned long va = (unsigned long)v;
+
+    ASSERT((va >= DIRECTMAP_VIRT_START) && (va <= DIRECTMAP_VIRT_END));
+
+    return frametable_virt_start + PFN_DOWN(va - directmap_virt_start);
 }
 
 /*
diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index 54c6fe6515..fbb35a6673 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -175,10 +176,16 @@ static inline void invalidate_icache(void)
 #define clear_page(page) memset((void *)(page), 0, PAGE_SIZE)
 #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
 
-/* TODO: Flush the dcache for an entire page. */
 static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache)
 {
-    BUG_ON("unimplemented");
+    const void *v = map_domain_page(_mfn(mfn));
+
+    BUG_ON(clean_and_invalidate_dcache_va_range(v, PAGE_SIZE));
+
+    unmap_domain_page(v);
+
+    if ( sync_icache )
+        invalidate_icache();
 }
 
 /* Write a pagetable entry. */
diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/include/asm/setup.h
index 844a2f0ef1..c9d69cdf51 100644
--- a/xen/arch/riscv/include/asm/setup.h
+++ b/xen/arch/riscv/include/asm/setup.h
@@ -3,10 +3,14 @@
 #ifndef ASM__RISCV__SETUP_H
 #define ASM__RISCV__SETUP_H
 
+#include 
+
 #define max_init_domid (0)
 
 void setup_mm(void);
 
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
+
 #endif /* ASM__RISCV__SETUP_H */
 
 /*
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 9680332fee..bea3f27c4d 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -12,6 +12,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +27,31 @@ void arch_get_xen_caps(xen_capabilities_info_t *info)
 unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
     __aligned(STACK_SIZE);
 
+/**
+ * copy_from_paddr - copy data from a physical address
+ * @dst: destination virtual address
+ * @paddr: source physical address
+ * @len: length to copy
+ */
+void __init copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
+{
+    const void *src = (void *)FIXMAP_ADDR(FIX_MISC);
+
+    while ( len )
+    {
+        unsigned long s = paddr & (PAGE_SIZE - 1);
+        unsigned long l = min(PAGE_SIZE - s, len);
+
+        set_fixmap(FIX_MISC, maddr_to_mfn(paddr), PAGE_HYPERVISOR_RW);
+        memcpy(dst, src + s, l);
+        clear_fixmap(FIX_MISC);
+
+        paddr += l;
+        dst += l;
+        len -= l;
+    }
+}
+
 void __init noreturn start_xen(unsigned long bootcpu_id,
                                paddr_t dtb_addr)
 {
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 17:28:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 17:28:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855083.1268174 (Exim 4.92)
	(envelope-from )
	id 1tLQVK-0000PG-Ph; Wed, 11 Dec 2024 17:28:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855083.1268174; Wed, 11 Dec 2024 17:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLQVK-0000OE-IB; Wed, 11 Dec 2024 17:28:06 +0000
Received: by outflank-mailman (input) for mailman id 855083;
 Wed, 11 Dec 2024 17:28: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 1tLQVJ-0007J6-Gk
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 17:28:05 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4722f73b-b7e5-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 18:28:04 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-a9e8522445dso1396545366b.1
 for ; Wed, 11 Dec 2024 09:28:04 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa6656f306csm687297466b.61.2024.12.11.09.28.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 09:28: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: 4722f73b-b7e5-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1733938083; x=1734542883; 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=MVUeGYT1/F6OE3Cc8TjMGFB+HbFqEqO/qxv449JXpGc=;
        b=HCWkt8Ic8xaYwSk49tmcqrKvGfvT2dO4IUidbkqpU3s6I4vfcTAi1Bq67ITpfKa/4E
         BjIKQQUmXeEE86MJ+iWnkJxX+kfSl9LDWfvyrUgp89EPZHP2GpS3vg3UN7uqG9Lv+K3m
         ctVDK1KKpIC9eT63F0PsPLbfKzXKUKgjK3gJmFqMonf9kD7QLRWbcwQ71njFeQxYaDbO
         uDT4nN/qc7/zc2tfStBK5x2B4q/iwr7AZibT47U5QdGikBwH/2UpiglEipj5z+Re2phJ
         3yaYt3CXrxiDbmY+srWQaaKIhCOj5LZ+CEsAlpCfJd2EQfSvZrbzcDokpmriLkxOcrui
         k1aQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733938083; x=1734542883;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=MVUeGYT1/F6OE3Cc8TjMGFB+HbFqEqO/qxv449JXpGc=;
        b=LeoXpqqSd+zlLogdX8nLJS9WS4C1V1liX/KcYz6WMQLZBAWC/ZcZnTAYLlMoejl5s1
         hTr46quNkqGfwQ5wNppqXrMLBsvA2OG2HdvqJerCCZ9icN8C1TuVdBicPT0eVZbc3kEY
         UwdCz3EkgLJqVE2I8ONjKkA1xLi2jd1qgyfeTp3aU8kMEWUuQ0tMpdrvCiiPfE0dLZyd
         dLxMUR+Zzvtnj2E55oDITUx6vCtlKhO+jzrGkspnHubCr+E7SFi66637yWKBlsE+VKE9
         Wgrr1Ubty2WGJaaCxp//vjiBDeGhCR2yfwKljUn6gCOzGu88huY4lB8ncEC8ESIrkgnE
         t3Yw==
X-Gm-Message-State: AOJu0YwNbd2+5YQHJoH3OB27Fg5QZgqspm500t5ZQDFdFoBlqR7fs/WT
	2VqsVDhhcsgcUe3QTx4pU/LlIiUI4cKLYf9Fub3pF75T/LdgqG7aslDYPfJk
X-Gm-Gg: ASbGncscme+breO1q1yUtCmQok2Tsd8QVrDQu4WvfJ2fhoMC5a3rqOO/iPFp+IAw+EO
	w42vuRZGLQ2ofxRSCvjQ8KkhZwJzvu9//4sIk+VApOBpEGHuZRrxbz7wNJnCRebPzpUIb/yl3sF
	Rvrc4dwio3bn2/AOHInZ/8lCAsNwx00xDm0xi5vWgzBCB1hJ3XrmYU5uIyen3er2He+VBmboa6A
	lLLiw/nGbykaINFkljJ+q5qTMd4jqvpF2wChD5SDao2Z3/ihvvTlt8=
X-Google-Smtp-Source: AGHT+IHk81CkV2ksl1MLimg86CXEDzadwLfuTlvYafnNlthU8knKAYe1HaxlGYqoNPeORU4oJS52nA==
X-Received: by 2002:a17:906:3299:b0:aa6:6510:f27e with SMTP id a640c23a62f3a-aa6b115bc46mr379902766b.14.1733938082630;
        Wed, 11 Dec 2024 09:28:02 -0800 (PST)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2 7/7] xen/riscv: relocating and unflattening host device tree
Date: Wed, 11 Dec 2024 18:27:51 +0100
Message-ID: <8906108d2e29637a42d5e127e393337d6b259b30.1733937787.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce relocate_fdt() and call it to relocate FDT to Xen heap
instead of using early mapping as it is expected that discard_initial_modules()
( is supposed to call in the future ) discards the FDT boot module and
remove_early_mappings() destroys the early mapping.

Unflatten a device tree, creating the tree of struct device_node.
It also fills the "name" and "type" pointers of the nodes so the normal
device-tree walking functions can be used.

Set device_tree_flattened to NULL in the case when acpi_disabled is
equal to false.

Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - Move introduction of relocate_fdt() to the current patch with the following
   change:
    - use xvmalloc() instead of xmalloc_bytes() in relocate_fdt();
 - Drop the check of returned fdt_size from boot_fdt_info() to be in sync
   with Arm and boot_fdt_info() will panic anyway if something wrong with
   DTB.
 - Update the commit message.
---
 xen/arch/riscv/setup.c | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index bea3f27c4d..fb6bbba684 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -1,5 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
+#include 
 #include 
 #include 
 #include 
@@ -8,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -52,10 +54,24 @@ void __init copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
     }
 }
 
+/* Relocate the FDT in Xen heap */
+static void * __init relocate_fdt(paddr_t dtb_paddr, size_t dtb_size)
+{
+    void *fdt = xvmalloc_array(uint8_t, dtb_size);
+
+    if ( !fdt )
+        panic("Unable to allocate memory for relocating the Device-Tree.\n");
+
+    copy_from_paddr(fdt, dtb_paddr, dtb_size);
+
+    return fdt;
+}
+
 void __init noreturn start_xen(unsigned long bootcpu_id,
                                paddr_t dtb_addr)
 {
     const char *cmdline;
+    size_t fdt_size;
 
     remove_identity_mapping();
 
@@ -80,8 +96,7 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
                           _end - _start, false) )
         panic("Failed to add BOOTMOD_XEN\n");
 
-    if ( !boot_fdt_info(device_tree_flattened, dtb_addr) )
-        BUG();
+    fdt_size = boot_fdt_info(device_tree_flattened, dtb_addr);
 
     cmdline = boot_fdt_cmdline(device_tree_flattened);
     printk("Command line: %s\n", cmdline);
@@ -99,6 +114,18 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
      */
     system_state = SYS_STATE_boot;
 
+    if ( acpi_disabled )
+    {
+        printk("Booting using Device Tree\n");
+        device_tree_flattened = relocate_fdt(dtb_addr, fdt_size);
+        dt_unflatten_host_device_tree();
+    }
+    else
+    {
+        device_tree_flattened = NULL;
+        panic("Booting using ACPI isn't supported\n");
+    }
+
     printk("All set up\n");
 
     machine_halt();
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 17:28:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 17:28:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855077.1268112 (Exim 4.92)
	(envelope-from )
	id 1tLQVE-0007Lt-Sw; Wed, 11 Dec 2024 17:28:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855077.1268112; Wed, 11 Dec 2024 17:28:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLQVE-0007Kx-OL; Wed, 11 Dec 2024 17:28:00 +0000
Received: by outflank-mailman (input) for mailman id 855077;
 Wed, 11 Dec 2024 17:27:59 +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 1tLQVD-0007J6-AS
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 17:27:59 +0000
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [2a00:1450:4864:20::634])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 436c2f1d-b7e5-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 18:27:58 +0100 (CET)
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-aa696d3901bso596135366b.1
 for ; Wed, 11 Dec 2024 09:27:57 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa6656f306csm687297466b.61.2024.12.11.09.27.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 09:27:56 -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: 436c2f1d-b7e5-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1733938077; x=1734542877; 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=rWBao4XqsmB8/UXiyyZSgIeWD9mc9NwUxRoYjmq47fU=;
        b=Z3sUBgl5Y0NBzVknFqZBALu00u6ImGBTzQarU8aWwG+JzA6qCo289cWNhFExYce+rn
         gKJxal/yXrpOEfG1EW7D+FqrhVzBaGKSsSjpMbVPdhQV/W2Dh9fzd9ER5HhdMmaIP5uk
         sXpuqqwUuyd8AMo8ldDbQRvhGTw4PeRQo+qB2JRbAeCrfbLcZuGtntu7CwRb2kblubse
         NTxbZah0KQbLfEJLuJvhb3C8J7sH98gZ0h1BiPkAbKNiIhuYkSLCR1q6HwUOO15a2uqz
         YpJzy67wEzxLAqVmddJWO7gdTbqiQqWZqWwwy0g+e3CFXgobAXaPbhzD3xS44u2Y31Hd
         9UPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733938077; x=1734542877;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=rWBao4XqsmB8/UXiyyZSgIeWD9mc9NwUxRoYjmq47fU=;
        b=T+E+0EVE1h/w8WnF+/hq3rCUOv8GqJo1Z2x0w/cdhvmIKBdbQx/xrJplzxUkppXoft
         T7mzXUM4jJj+x9Y8BfXR2pIFr0Bujv8Qnm7GpuAROmMgRxXy8UOZtLFA/9MbMqCGUcTF
         Bsb8z5mcDbpN/bgm3RIyIdPKgs384Fz7MtDYjpboN9WidI4MeP7gETqqZYqMNPTpO1fR
         UU+V/5ML7LCdAsJNULOidu8GM+8VgGEy2yzsx9eUQHmcIuEDCnrqnUsBjgl90ypcrfkH
         hJBFk8C0eD+seQi2yxD5vRNPg0TzNcNQcsShqPkffnxgTHw7YUAtuml21kzD8XIOqQWL
         W4Lw==
X-Gm-Message-State: AOJu0YzgpLbIF+RiXQiK6km0vn4+S42oLYWMWLkeAd8uZqReQSGIjoYT
	dNBHDwPd+LZE8v0pd5R0PYf1octVpWW0KIniePGNtTrkM65+xUW95HWNiLOg
X-Gm-Gg: ASbGncv36Iu8a8HZnRD0GMX82atwoPsz8K7Crc9tj1BLMtOdiiLjPGMWrRO/6DO6TWE
	2iQKx4sgWhzK1PiAR7OsiHnZbBv41IZfWTRRf2FgPn+CgwCJ+JIZvnjirawIMZsVA27f7VfmiHn
	Vb0YDGwe726B9XP7tro+bxutI4f4mKsBBVAIE9O3hW+g7CsrrkYla1xZH6rctr/rvjHK+JJ5M3m
	/fPrei5DnkCuTISTLuxu5zz1GBp01bpdlqiuKxMYqZZ98T4vbSdkN4=
X-Google-Smtp-Source: AGHT+IEnjYQPlyyOFaaSm0cIXgB3hbmyPLyJZAeXB6K1RN5O+yRnA+Ihrj0qpAB/P8+c5QuvlfYlKA==
X-Received: by 2002:a17:907:9145:b0:aa6:966d:3f93 with SMTP id a640c23a62f3a-aa6c1b0a214mr57357066b.23.1733938076730;
        Wed, 11 Dec 2024 09:27:56 -0800 (PST)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2 2/7] xen/riscv: add destroy_xen_mappings() to remove mappings in Xen page tables
Date: Wed, 11 Dec 2024 18:27:46 +0100
Message-ID: 
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce the destroy_xen_mappings() function, which removes page
mappings in Xen's page tables between a start address s and an end
address e.
The function ensures that both s and e are page-aligned
and verifies that the start address is less than or equal to the end
address before calling pt_update() to invalidate the mappings.
The pt_update() function is called with INVALID_MFN and PTE_VALID=0
in the flags, which tell pt_update() to remove mapping. No additional
ASSERT() is required to check these arguments, as they are hardcoded in
the call to pt_update() within destroy_xen_mappings().

Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V2:
 - Drop ASSERT(s <= e).
 - Update implementation of destroy_xen_mappings() to avoid calling of
   pt_update() when start_addr >= end_addr and return -EINVAL.
 - Add Acked-by: Jan Beulich .
---
 xen/arch/riscv/mm.c | 6 ------
 xen/arch/riscv/pt.c | 8 ++++++++
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index 9359dc7f33..f2bf279bac 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -360,12 +360,6 @@ int xenmem_add_to_physmap_one(struct domain *d, unsigned int space,
     return 0;
 }
 
-int destroy_xen_mappings(unsigned long s, unsigned long e)
-{
-    BUG_ON("unimplemented");
-    return -1;
-}
-
 void share_xen_page_with_guest(struct page_info *page, struct domain *d,
                                enum XENSHARE_flags flags)
 {
diff --git a/xen/arch/riscv/pt.c b/xen/arch/riscv/pt.c
index d62aceb36c..86bd9ea613 100644
--- a/xen/arch/riscv/pt.c
+++ b/xen/arch/riscv/pt.c
@@ -421,6 +421,14 @@ int map_pages_to_xen(unsigned long virt,
     return pt_update(virt, mfn, nr_mfns, flags);
 }
 
+int destroy_xen_mappings(unsigned long s, unsigned long e)
+{
+    ASSERT(IS_ALIGNED(s, PAGE_SIZE));
+    ASSERT(IS_ALIGNED(e, PAGE_SIZE));
+
+    return ( s < e ) ? pt_update(s, INVALID_MFN, PFN_DOWN(e - s), 0) : -EINVAL;
+}
+
 int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns)
 {
     return pt_update(virt, INVALID_MFN, nr_mfns, PTE_POPULATE);
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 17:28:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 17:28:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855079.1268138 (Exim 4.92)
	(envelope-from )
	id 1tLQVH-00080r-FV; Wed, 11 Dec 2024 17:28:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855079.1268138; Wed, 11 Dec 2024 17:28: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 1tLQVH-00080g-C5; Wed, 11 Dec 2024 17:28:03 +0000
Received: by outflank-mailman (input) for mailman id 855079;
 Wed, 11 Dec 2024 17:28: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 1tLQVF-0007J6-NN
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 17:28:01 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 44dbaa17-b7e5-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 18:28:00 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5cfa1ec3b94so9628534a12.2
 for ; Wed, 11 Dec 2024 09:28:00 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa6656f306csm687297466b.61.2024.12.11.09.27.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 09:27: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: 44dbaa17-b7e5-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1733938079; x=1734542879; 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=yBf1T7q7Qfa9RGnc2Coijh+Oa0RzeIjYcm94VV4SlJc=;
        b=kxV5UOgUUq817NL6EleR1nKXRcQns110WbtsBreWDiXDJWinhIcbZ/d/mmqlYiSY8S
         XuPBe6zMnqsfqvMzkA91s9gwunS7BWnI5JPx5TTqgZGuSQAva6EqZMzHlSJG0ZQOtxUu
         iozGR3V5mqrvyY2u+XZKNT3EGVRWetoul5hO4me7lK/qf5GWC1lOQWNh6oMitoWc7JXf
         3wY7vLvh0umL4oMn5DMAloluUfBRpa6XTawZxCk7t9k73yGUcN9bQHMnasjBkVpUl5fH
         jCKR6671WNSD0+qDte/+YGJeeTW/+PjwlqqT+WsQbZnWCxGUK9jFIjoVFuspuUSrLp4y
         iqFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733938079; x=1734542879;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=yBf1T7q7Qfa9RGnc2Coijh+Oa0RzeIjYcm94VV4SlJc=;
        b=lkNEauXyoElMpxDtiCU5FdhOryf4c9XVZNxGfNopEOsq/E82E/73PuP88J+Nm9GTI4
         8yPYO9rWP8PXMoiluLiGV8S6pCq/wLSgMQ05z06Lql/pBhfhtxalXlpxGncKC5cpFcKB
         M1nblSGi7V4xv3qmiBKtPh4x4EQq8dngZnm9WviOD6dcfgxiYlvTNjkQDyLz8pWng0DF
         CHaj270tMS8cwvSMU/cQxbba/x/pHD6V1So2YT9wbe5q4Iawpc4zvyM79NSrX3hSh217
         5HEzUqarf3owGBMbbbZaxi5w48Pg28L+zdsKaxO9LXZo08aIGQeixnqKO+a4VnDp8eKi
         iQYw==
X-Gm-Message-State: AOJu0Ywik3SSnQzoMwQwk8w9vPH4lOI6lWazmfkBe05zLWIFwPN8HbQ3
	MBRgUjDI2aVoWTR4Z+2x5Ou9OZKX8HOFc6zQFmi/CX7JJSxYCCR2CH+KlRaf
X-Gm-Gg: ASbGncvzJcMtFVPu97VzLwHYdIGvg/MHeZwa+qSU48rkpoALrQLDbDsdg1LKvg5S+UJ
	yRcqsc0FPbDkHnRh4aiT7KVrZBMYThMWOMglNCnJtm0MvwMKaqCyjvEk5+WdAmz65Y4LZnLUxnt
	ADyGrK34GeicIDJB2B2z1ybs45R11NMOAkdYund9Vxlyj6wgaXSePpJJ7IiHRP5pHOTzI+zR6Sq
	+74z+crjsDYcNLAVmPMFIXz/qQentfxCLxVtILp79RlmT3F748u56Y=
X-Google-Smtp-Source: AGHT+IH7cOZleyu34bvpQMa3pFX/11My/M5C5X1FUrFKP5oF4geYyx8+10k/PUjt4AmSnvyzUmK5Hg==
X-Received: by 2002:a17:906:3154:b0:aa6:8fa5:f3e3 with SMTP id a640c23a62f3a-aa6c1ab62b1mr54492666b.8.1733938078530;
        Wed, 11 Dec 2024 09:27:58 -0800 (PST)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2 3/7] xen/riscv: reorder includes in asm/page.h alphabetically
Date: Wed, 11 Dec 2024 18:27:47 +0100
Message-ID: <2e2751c3ef25f3b1aa3a216045022e82d2ab2b30.1733937787.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V2:
 - Add Acked-by: Jan Beulich 
---
 xen/arch/riscv/include/asm/page.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index 91b1194b55..bf3f75e85d 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -5,8 +5,8 @@
 
 #ifndef __ASSEMBLY__
 
-#include 
 #include 
+#include 
 #include 
 
 #include 
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 17:28:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 17:28:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855076.1268107 (Exim 4.92)
	(envelope-from )
	id 1tLQVE-0007JZ-JU; Wed, 11 Dec 2024 17:28:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855076.1268107; Wed, 11 Dec 2024 17:28:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLQVE-0007JS-H0; Wed, 11 Dec 2024 17:28:00 +0000
Received: by outflank-mailman (input) for mailman id 855076;
 Wed, 11 Dec 2024 17:27: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 1tLQVC-0007JC-O3
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 17:27:58 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 432b0522-b7e5-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 18:27:57 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-aa684b6d9c7so666028366b.2
 for ; Wed, 11 Dec 2024 09:27:57 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa6656f306csm687297466b.61.2024.12.11.09.27.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 09:27: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: 432b0522-b7e5-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1733938077; x=1734542877; 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=VzX0EG8we7tfVPdrZl970dxIaE2lTCTt+eDvQIAPb6U=;
        b=gyy4oAQ4JzDOaQWwLKl+lgiA/U8Q8LXUUB3k+NOX2+AzGor4obsc880ws+/SZNZDAZ
         CjHk7JwwvYS7ZqXBH/AdeLPh9BQ84EVBOPs871YkKEkrjJGgQG0r6kJPqTOLajoxGHB4
         WMShlHL9zsyCRsz4f3fcx/yRwgk/mWzGW878n933DLvR/26DMVHai4eaMtA+gKtjaovn
         kqFSF4B/5sCdhvHTtFzYVpWJdKdaumd+vkj5FyDoOL28lK20NloDZVS+m1/r3EHy+EHM
         RDdyDq1NhesejWlPQSRz2Drib8YuqDyJOl8WPxSAvJLLgRU61M1yxp/eXv+sih9U/qHj
         ThdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733938077; x=1734542877;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=VzX0EG8we7tfVPdrZl970dxIaE2lTCTt+eDvQIAPb6U=;
        b=cj0CQu1FeVaWfnAYLQBBE6usbKWNTl4RpQUyM/2Y38u+BnTkc7wftlJaO+E4tQhc7r
         75axNEOpoexl8iQjczyjMEYrCnZOblZUdLtIJOtQ0eu9ZOssVpD/ArfHiFJoY2YMNpkY
         GIlvwex8FkSopsxgnYxM4A8wChDx4Ct0M/6KvlZxBwwIdqbQbTXHP17JXIh0K6aMprKl
         YifZDIdaBK4Um6k3imaLusEp6hbaxVejI/dHerTk45ad4QmpDYdfv3cJDpy4RdME+fLo
         +JKO4e5ghJXgnNQ2QsitFPLkvlLei0sgXHIEvx56BJc0pURemT2niyY9ZZr7z16TPxqP
         xK0Q==
X-Gm-Message-State: AOJu0YzIBOGRUFZobMsWxtsu4jU1c0LIJZhWaOoT6iVxTnYegdOnVu35
	dVsnBiSefaGQyxMTciGIe4sIi6bHCJEqHSkIdiDF4/9+28pZkCZiO1V9gYYc
X-Gm-Gg: ASbGncunwMxxa4fUK3lkz8+LK3zsinGQ94NN94ZCHhP/oJ8vc1K2VvPK6SMiWdGuJlL
	QRc+uRvB08qwrtotwKjUh/Hm4lFJOFstMyfgEZnnFjQMjnnwsVcrpCkPKmqMiMGbkvhMcDE2+Xr
	Es0m7ubFxq8Xo2BrMZN0uct8NjoyzOnmr6/dhDNPlWc/t5pYdjtJcNzhcNDiVgfTVXfcgqJarh1
	Qn2pI8zjQCxG7OTjxyBWJnlqb/2YrVYrKdew6gsoLvHGO1kq0IkHT8=
X-Google-Smtp-Source: AGHT+IHa49oG7xF72kcIsHSUqvy7xJ4GbRUC02XLty084JogjHEMWJU8D7j8yPmTBBEzTL036/kfmg==
X-Received: by 2002:a17:906:9a95:b0:aa6:6276:fe5a with SMTP id a640c23a62f3a-aa6c1ce75f7mr70820866b.43.1733938075671;
        Wed, 11 Dec 2024 09:27:55 -0800 (PST)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2 1/7] xen/riscv: update layout table in config.h
Date: Wed, 11 Dec 2024 18:27:45 +0100
Message-ID: 
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Make all upper bounds (end addresses) for areas inclusive to align
with the corresponding definitions.

Signed-off-by: Oleksii Kurochko 
---
Changes in v2:
 - new patch
---
 xen/arch/riscv/include/asm/config.h | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/riscv/include/asm/config.h b/xen/arch/riscv/include/asm/config.h
index 4954677aff..826e5c7172 100644
--- a/xen/arch/riscv/include/asm/config.h
+++ b/xen/arch/riscv/include/asm/config.h
@@ -41,17 +41,17 @@
  * Start addr          | End addr         | Slot       | area description
  * ============================================================================
  *                   .....                 L2 511          Unused
- *  0xffffffffc0a00000  0xffffffffc0c00000 L2 511          Fixmap
+ *  0xffffffffc0a00000  0xffffffffc0bfffff L2 511          Fixmap
  *                   ..... ( 2 MB gap )
- *  0xffffffffc0400000  0xffffffffc0800000 L2 511          FDT
+ *  0xffffffffc0400000  0xffffffffc07fffff L2 511          FDT
  *                   ..... ( 2 MB gap )
- *  0xffffffffc0000000  0xffffffffc0200000 L2 511          Xen
+ *  0xffffffffc0000000  0xffffffffc01fffff L2 511          Xen
  *                   .....                 L2 510          Unused
- *  0x3200000000        0x7f40000000       L2 200-509      Direct map
+ *  0x3200000000        0x7f7fffffff       L2 200-509      Direct map
  *                   .....                 L2 199          Unused
- *  0x30c0000000        0x31c0000000       L2 195-198      Frametable
+ *  0x30c0000000        0x31bfffffff       L2 195-198      Frametable
  *                   .....                 L2 194          Unused
- *  0x3040000000        0x3080000000       L2 193          VMAP
+ *  0x3040000000        0x307fffffff       L2 193          VMAP
  *                   .....                 L2 0-192        Unused
 #elif RV_STAGE1_MODE == SATP_MODE_SV48
  * Memory layout is the same as for SV39 in terms of slots, so only start and
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 17:28:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 17:28:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855081.1268152 (Exim 4.92)
	(envelope-from )
	id 1tLQVJ-0008KA-1X; Wed, 11 Dec 2024 17:28:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855081.1268152; Wed, 11 Dec 2024 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 1tLQVI-0008J7-SV; Wed, 11 Dec 2024 17:28:04 +0000
Received: by outflank-mailman (input) for mailman id 855081;
 Wed, 11 Dec 2024 17:28: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 1tLQVI-0007J6-1R
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 17:28:04 +0000
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [2a00:1450:4864:20::62d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4625b698-b7e5-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 18:28:02 +0100 (CET)
Received: by mail-ej1-x62d.google.com with SMTP id
 a640c23a62f3a-aa69077b93fso508305166b.0
 for ; Wed, 11 Dec 2024 09:28:02 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa6656f306csm687297466b.61.2024.12.11.09.27.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 09:28: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: 4625b698-b7e5-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1733938081; x=1734542881; 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=QkQK8nAgFr42ZPxstS2wi6BvRdU+OOSSDhzgllibs7Q=;
        b=CnBFBy8PDmu0f5KK4wK2HoVVxaPtrYH/R7Agj0XV7x43R/OCsGv1L+l6GJ8BalQswk
         1ZJ9CYWEpkDlKnU0syng7R/sUj7aOSYK+XjqBGxGE2iXzDeXURyN6CezvWrCEXTwMFir
         BdQfIIaH6/GpuMUcU2syTCGu4Vz3Vp/Nc4aFotZhEuGWTLBbM+zD0PYtD63klrk+DWJs
         EwvV6KWsMnJLRia/Tgrn4hk+i4pd1zqt8l69BYgxTce3+0kHlmcE6cD0a0HlK0eSQxB1
         Kcw88mzoyWWKLSA2kiqTvaq06tGtDyqx3iQcua+C1mBUEeFx/qN66iXExEBjNh/vsuJ6
         Fpsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733938081; x=1734542881;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=QkQK8nAgFr42ZPxstS2wi6BvRdU+OOSSDhzgllibs7Q=;
        b=GZOtDCmavkM3yvJeozXxvVkqIk8lKOPIMunUS/ynxAS9eSBKwijaoGwWjwAhCHn7ji
         3zkcoYtn7u48sTVpff1vMrxHJPYVY77JeX2bTQ+5J6KrR4e5Ye/4prQ49IGyuo04s5lX
         St6pCca2inPJxTMxlGCwbuY3UpYeBlruVHuXOBDKLulAqhOzB1YXNgm1fUdRoyqbYvCd
         2Q2uNw2KLb1J/2LDOooPESo1WSMsbuwpaPnXv5rs0QHHYNq4XGYNjtsgXOGGQFuBskOf
         bPcYzJqwN+CI2x2M8RIoIBEvgtuC7DIREnQOLl2qVgJ350dTqbFKaaxSaBUVnsNUaLhu
         QxgA==
X-Gm-Message-State: AOJu0YyL+IQcpoFpwp75roaGwF7xeLWJxdhJiMaPelmO7uh+pRtoDlMp
	9+/T00FGpyTGIWfwvUchix9z5hbVYYu4nKFHm9oq7yD0kRfeaJKC6OXGGw0z
X-Gm-Gg: ASbGncs4zYYAhF/QsOzkMjUBj4wXrW98LZgku10sH5VMHTPxTPR68tK+qTT+U33Pm6F
	oHeYZ7Uv3mhtpPDYiwztrPuPNwLyJTvqpqeFEAViAREiWFxibjLGqESWJW1hwg8k0kHG08jjdn2
	5XOSXLbJtnK06sH1KSKKSGS0mOHVmU8xNCb9zkdDQvJja0bNtOiM48b5+DhS/KvT+z1ifbnFJvw
	I8y9jyuwtBStQli327FNny7gyyvFKr+jpa+0RKcYKPfUs3TbHpfpKM=
X-Google-Smtp-Source: AGHT+IGfMe6zVWrtyyrEzVriIleXUcPcuX7PTitRVcZdUVKgvE14a22FQJgoZt9rNPki9KX736cIfw==
X-Received: by 2002:a17:906:8a42:b0:aa6:8bb4:503b with SMTP id a640c23a62f3a-aa6c1d13240mr76327066b.55.1733938080609;
        Wed, 11 Dec 2024 09:28:00 -0800 (PST)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2 5/7] xen/riscv: implement data and instruction cache operations
Date: Wed, 11 Dec 2024 18:27:49 +0100
Message-ID: 
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Implement following cache operations:
- clean_and_invalidate_dcache_va_range()
- clean_dcache_va_range()
- invalidate_icache()

The first two functions may require support for the CMO (Cache Management
Operations) extension and/or hardware-specific instructions.
Currently, only QEMU is supported, which does not model cache behavior.
Therefore, clean_and_invalidate_dcache_va_range() and clean_dcache_va_range()
are implemented to simply return 0. For other cases, -ENOTSUPP is returned.
If hardware supports CMO or hardware-specific instructions,
these functions should be updated accordingly. To support current
implementation of these function CONFIG_QEMU is introduced.

invalidate_icache() is implemented using fence.i instruction as
mentioned in the unpriv spec:
  The FENCE.I instruction was designed to support a wide variety of
  implementations. A simple implementation can flush the local instruction
  cache and the instruction pipeline when the FENCE.I is executed.
  A more complex implementation might snoop the instruction (data) cache
  on every data (instruction) cache miss, or use an inclusive unified
  private L2 cache to invalidate lines from the primary instruction cache
  when they are being written by a local store instruction.
  If instruction and data caches are kept coherent in this way, or if the
  memory system consists of only uncached RAMs, then just the fetch pipeline
  needs to be flushed at a FENCE.I.
The FENCE.I instruction requires the presence of the Zifencei extension,
which might not always be available. However, Xen uses the RV64G ISA, which
guarantees the presence of the Zifencei extension. According to the
unprivileged ISA specification (version 20240411):
  One goal of the RISC-V project is that it be used as a stable software
  development target. For this purpose, we define a combination of a base ISA
  (RV32I or RV64I) plus selected standard extensions (IMAFD, Zicsr, Zifencei)
  as a "general-purpose" ISA, and we use the abbreviation G for the
  IMAFDZicsr_Zifencei combination of instruction-set extensions.

Set CONFIG_QEMU=y in tiny64_defconfig to have proper implemtation of
clean_and_invalidate_dcache_va_range() and clean_dcache_va_range() for CI.

Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
 - Update the commit message and subject:
   - drop information about HAS_CMO;
   - add information about Zifencei extension;
 - Introdce platforms directory and CONFIG_QEMU; update implementation of
   data/instruction cache operations as returning 0 for CONFIG_QEMU and for
   others - return -ENOTSUPP.
 - Drop HAS_CMO config.
---
 xen/arch/riscv/Kconfig                  |  2 ++
 xen/arch/riscv/configs/tiny64_defconfig |  1 +
 xen/arch/riscv/include/asm/page.h       | 21 ++++++++++++++++++++-
 xen/arch/riscv/platforms/Kconfig        |  5 +++++
 4 files changed, 28 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/riscv/platforms/Kconfig

diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
index 1858004676..00f329054c 100644
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -52,6 +52,8 @@ config RISCV_ISA_C
 
 endmenu
 
+source "arch/riscv/platforms/Kconfig"
+
 source "common/Kconfig"
 
 source "drivers/Kconfig"
diff --git a/xen/arch/riscv/configs/tiny64_defconfig b/xen/arch/riscv/configs/tiny64_defconfig
index fc7a04872f..47076e357c 100644
--- a/xen/arch/riscv/configs/tiny64_defconfig
+++ b/xen/arch/riscv/configs/tiny64_defconfig
@@ -10,3 +10,4 @@ CONFIG_RISCV_64=y
 CONFIG_DEBUG=y
 CONFIG_DEBUG_INFO=y
 CONFIG_EXPERT=y
+CONFIG_QEMU=y
diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index bf3f75e85d..54c6fe6515 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -148,9 +149,27 @@ static inline bool pte_is_mapping(pte_t p)
     return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK);
 }
 
+static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
+{
+#ifdef CONFIG_QEMU
+    return 0;
+#else
+    return -EOPNOTSUPP;
+#endif
+}
+
+static inline int clean_dcache_va_range(const void *p, unsigned long size)
+{
+#ifdef CONFIG_QEMU
+    return 0;
+#else
+    return -EOPNOTSUPP;
+#endif
+}
+
 static inline void invalidate_icache(void)
 {
-    BUG_ON("unimplemented");
+    asm volatile ( "fence.i" ::: "memory" );
 }
 
 #define clear_page(page) memset((void *)(page), 0, PAGE_SIZE)
diff --git a/xen/arch/riscv/platforms/Kconfig b/xen/arch/riscv/platforms/Kconfig
new file mode 100644
index 0000000000..30ed938d52
--- /dev/null
+++ b/xen/arch/riscv/platforms/Kconfig
@@ -0,0 +1,5 @@
+config QEMU
+	bool "QEMU aarch virt machine support"
+	depends on RISCV_64
+	help
+	  Enable all the required drivers for QEMU riscv64 virt emulated machine.
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 17:28:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 17:28:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855080.1268148 (Exim 4.92)
	(envelope-from )
	id 1tLQVI-0008Gx-MS; Wed, 11 Dec 2024 17:28:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855080.1268148; Wed, 11 Dec 2024 17:28: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 1tLQVI-0008Gn-J1; Wed, 11 Dec 2024 17:28:04 +0000
Received: by outflank-mailman (input) for mailman id 855080;
 Wed, 11 Dec 2024 17:28: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 1tLQVG-0007J6-TG
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 17:28:02 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4589c99e-b7e5-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 18:28:01 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-a9f1d76dab1so1011026766b.0
 for ; Wed, 11 Dec 2024 09:28:01 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa6656f306csm687297466b.61.2024.12.11.09.27.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 09:27: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: 4589c99e-b7e5-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1733938080; x=1734542880; 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=kV5fnGT+IURuJB8/ySzjdk0FAfLfvbDV4kQWrHvyXVA=;
        b=dqXcSD42gGbIpSEY8fo7L/WBDY0yi3/qqbp0eAH7QW4fLn4TDCb0zxH/NQ51/aOPkY
         lYkBVAT1cHIz5z6beiFQyOqAujQb6lqb7aizduXHtmT6WaQ240U65gnNBjCl/S8rbaeN
         4G0k+NB2WNLqIP5MJ7/pWkeWDQ/NU7+mnhWxqbSEVH60guKjezPzgW0nG5gK2JRFcpxS
         N92kbD5UaTC6FCHACAIaYH0kxJ4oAcCylS2EydAm3zma19m1KV7PbG8JQ1HaKFc1975+
         qv9sULAUkty44r2mkNuu4UL0Wf1OG3KNmUEE2LB3Ajc21i+vgyTDBnewzK5GE0Y0NMmY
         yQhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733938080; x=1734542880;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=kV5fnGT+IURuJB8/ySzjdk0FAfLfvbDV4kQWrHvyXVA=;
        b=FDICHEwAsUK2bsbqCQc7VeZozNV8auFqA2Iy2XyRDEda0Hg8tkjLMYFyX0jwYnwDmZ
         XKNBXd2XSEI3JwmEkDPQpYpXBwFS3WooIWHbAKHkPLXC6Lo5ROM/7XnPfsqGB1B4OECr
         JBPR4s0W+nP+Rff9ubMLJumVjHpM2NjtF9bQvmrIM2FRTX4nakr+IAvWxSDkCUEqqq0o
         yrJsPJ4yKndZVYExzDoRwx7jhkuXUa+CTfDTUnHRWZFlPmJcvazMe68bJr6MoLnzx7cl
         JnDPDflm5hCXeKKkmDEkv38e8b90GFL1KK/atbjw2Ep440xs2pldaqCDUbJQcuYaEZ8V
         /drQ==
X-Gm-Message-State: AOJu0YwtJ95DRMKK6MgeK3s1jkbocK4cmFuUwlfdPCdXMXt8CtmVhFpO
	6ovkQXvb4JbiITQiJiFSKxz8mHQXlDjXiwS6kPgw/nf2ByeNdp3qAG0W7cbl
X-Gm-Gg: ASbGncuiHaQVzSe1DquEdfuUPw0vAn2Ryn4avEvKSN2XmS+TFIdgb21CoWeZy4pXrtJ
	4m2mFUENWSBzTRor4Up9k8zP/v5f1YQ8/45pO50wDWZN7IFGHGn+xlmFyYcqeqsGej12g7eqY7o
	JgrESNf5UOeyb/Z93nh7T7uX5ugQVQQLvI/X5NzsVae/aqeOE4BflEFWTRYw4prbL79yp+XufKz
	biVpvhmK5cz6bLzq+jRTjRaswegRfNoZSOAfjVyYgYxBXg2kUeMJqA=
X-Google-Smtp-Source: AGHT+IEPTLL+WUKby+ninBNWHjY1Dl2NtcLd1rZlicn1EDp6HPCuCO5wX72e+3d1olMJCiXIrwYWnA==
X-Received: by 2002:a17:907:61a7:b0:aa6:715a:75b5 with SMTP id a640c23a62f3a-aa6b139781emr309980866b.46.1733938079661;
        Wed, 11 Dec 2024 09:27:59 -0800 (PST)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2 4/7] xen/riscv: add {set,clear}_fixmap() functions for managing fixmap entries
Date: Wed, 11 Dec 2024 18:27:48 +0100
Message-ID: <3d34dbc7a8af373b799d1e0c1c99acfa3798f37d.1733937787.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce set_fixmap() and clear_fixmap() functions to manage mappings
in the fixmap region. The set_fixmap() function maps a 4k page ( as only L0
is expected to be updated; look at setup_fixmap_mappings() ) at a specified
fixmap entry using map_pages_to_xen(), while clear_fixmap() removes the
mapping from a fixmap entry by calling destroy_xen_mappings().

Both functions ensure that the operations succeed by asserting that their
respective calls (map_pages_to_xen() and destroy_xen_mappings()) return 0.
`BUG()` is added to trigger a failure if any issues occur during
the mapping or unmapping process.

Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V2:
 - Update the commit message.
 - drop local variables from {set, clear}_fixmap(); use if (... != 0) + BUG().
---
 xen/arch/riscv/include/asm/fixmap.h |  5 +++++
 xen/arch/riscv/pt.c                 | 17 +++++++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/xen/arch/riscv/include/asm/fixmap.h b/xen/arch/riscv/include/asm/fixmap.h
index 818c8ce07b..e399a15f53 100644
--- a/xen/arch/riscv/include/asm/fixmap.h
+++ b/xen/arch/riscv/include/asm/fixmap.h
@@ -32,6 +32,11 @@
  */
 extern pte_t xen_fixmap[];
 
+/* Map a page in a fixmap entry */
+void set_fixmap(unsigned int map, mfn_t mfn, unsigned int flags);
+/* Remove a mapping from a fixmap entry */
+void clear_fixmap(unsigned int map);
+
 #define fix_to_virt(slot) ((void *)FIXMAP_ADDR(slot))
 
 static inline unsigned int virt_to_fix(vaddr_t vaddr)
diff --git a/xen/arch/riscv/pt.c b/xen/arch/riscv/pt.c
index 86bd9ea613..3407fda937 100644
--- a/xen/arch/riscv/pt.c
+++ b/xen/arch/riscv/pt.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -433,3 +434,19 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns)
 {
     return pt_update(virt, INVALID_MFN, nr_mfns, PTE_POPULATE);
 }
+
+/* Map a 4k page in a fixmap entry */
+void set_fixmap(unsigned int map, mfn_t mfn, unsigned int flags)
+{
+    if ( map_pages_to_xen(FIXMAP_ADDR(map), mfn, 1, flags | PTE_SMALL) != 0 )
+        BUG();
+}
+
+/* Remove a mapping from a fixmap entry */
+void clear_fixmap(unsigned int map)
+{
+    if ( destroy_xen_mappings(
+            FIXMAP_ADDR(map),
+            FIXMAP_ADDR(map) + PAGE_SIZE) != 0 )
+        BUG();
+}
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 17:28:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 17:28:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855078.1268120 (Exim 4.92)
	(envelope-from )
	id 1tLQVF-0007TW-84; Wed, 11 Dec 2024 17:28:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855078.1268120; Wed, 11 Dec 2024 17:28:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLQVF-0007SF-1C; Wed, 11 Dec 2024 17:28:01 +0000
Received: by outflank-mailman (input) for mailman id 855078;
 Wed, 11 Dec 2024 17:28: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 1tLQVE-0007J6-Ab
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 17:28:00 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 43d25905-b7e5-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 18:27:58 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-aa6aad76beeso285149566b.2
 for ; Wed, 11 Dec 2024 09:27:58 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa6656f306csm687297466b.61.2024.12.11.09.27.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Dec 2024 09:27: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: 43d25905-b7e5-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1733938077; x=1734542877; 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=J7P8VV/ICo4pOSmR8O3bdkrRLWJ+hz7hoMbQD+Lhjrg=;
        b=lrcJnhX7+h9P4dIdX/ktKFB8hK38X8+lsVUDDb3+8kbuUuqW9OXcAVR0F86FNAj2Fr
         lJi9WWIDM8uwWpcLEw4pIAqyOQGPgeEIzX2fRTb8r4Lz76B41waRniDATBfLf/a63lwf
         bbLBZ7LaCKopKJQQwacJ0J0Az6pRVVBN1xYSIcMkZIH1e998gIwUXYbX6PcpDlGaF9Yb
         299NIDVyUCKoliDjmkrg30Y1kgUBH/6qm0SUlz1v/r2v2Y759RgdzXlXOiFjKMRsPeGK
         ZHLMY++Y/vaseVF3eBhcxGmVOYdHT/eISC7cAuLaSJnZdnyv2eRbJ2iBQhNbaLcQrJ6M
         iX7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733938077; x=1734542877;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=J7P8VV/ICo4pOSmR8O3bdkrRLWJ+hz7hoMbQD+Lhjrg=;
        b=WXh6iYSRo5k0dIGNce2tIe4Uv0xLVOJuPYPbque4cDHDy3ZnyzlaNyRYw1moHeczFA
         zbpTfQGvnVd+hoxXC1EtrWNmQ58hmbcb1zHAXrYVp3sgmxhY9INMW/K1jw+o/kbN0D6f
         6m6RmI28QaEYykkoz4hzxEVuf6dXaSjpTUqyWeTIxfw5OQW4sBQmAOdLQzeITnkNYLUl
         +2/QzyrXQzY5lCYgGzjp4mYuBsR8Wbkbf1IUOgWZ6UTvChTgEAZEFhUogtfTD8M2C3Xs
         g3mldUQxXFU7tGpWcffF6UOHtmeWGdlb14AsBxHqCIYujkgpn9T67cejHSXvIc5P9gPl
         hW6A==
X-Gm-Message-State: AOJu0YxD20s9Sc3EWqv+86YLoWBMa/h2/d8bjcMTcake+9VJuogtZrIT
	5KNsAir4WGV11yEQ0UB/45/rFbJbMmIjkCPvlNRkfeG3GLooMkvQSz+ZpuvI
X-Gm-Gg: ASbGncsZ6tgX/W9ED1dom7QHBwYlOBBg4+zktDjxoWctiNdhepN1XMozv45q8BfTDBa
	eKlwD3Qjuss/bshrgXVj2j/OzVu/YMDuqG1DmY23vMiXYl8op5paq4ChyLEqgiG6jgKR6L6/bVn
	lS/52CDCmeDYbz+jliO3bPwwmuo1SXqFga1xLmFmyIzCQc4E9s47lG/44J2uuNpS4HPIgKccjnX
	H8O3KtaLqRbpORHyaQyPYVwLfux6dZ0dIBmfCr4QxnQfhohfztSBEs=
X-Google-Smtp-Source: AGHT+IGh4LyOzhjdURZwplM/eh1WgTc0kQXLviziG8oET43C97XSN+E67K9zw2LBr1swdi0RI7eUNg==
X-Received: by 2002:a17:906:1db2:b0:aa6:8b4a:46a4 with SMTP id a640c23a62f3a-aa6b139782dmr385585866b.44.1733938074689;
        Wed, 11 Dec 2024 09:27:54 -0800 (PST)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2 0/7] Unflattening and relocation of host device tree
Date: Wed, 11 Dec 2024 18:27:44 +0100
Message-ID: 
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The current patch series introduces the relocation of the host device tree file
to free up low memory and also it is expected that discard_initial_modules()
will be called sooner or later, it will discard the FDT boot module,
and remove_early_mappings() will destroy the early mappings.

In addition to relocation, unflattening is introduced to create the tree of
struct device_node for the host device tree.

To implement this, several things have been introduced:
 - destroy_xen_mappings() function, which removes page mappings from Xen's
   page tables. This is necessary for clear_fixmap().
 - {set,clear}_fixmap() functions to manage mappings in the fixmap region,
   which are expected to be used in copy_from_paddr() to copy the FDT to Xen's
   heap.
 - Introduce new config CONFIG_QEMU which is going to be used to cover changes
   connected to QEMU virtual board. It will be used during introduction of stubs
   for clean_and_invalidate_dcache_va_range() and clean_dcache_va_range(),
   which are expected to be used in copy_from_paddr() and flush_page_to_ram(),
   which in turn are expected to be used during the call to xvmalloc_array() in
   relocate_fdt().
   In case of QEMU cached related functions are implemented as returning 0 as
   QEMU doesn't model cache ( and so CMO extensions ). For others cases, it is
   introduced as -ENOSUPP as h/w could support CMO extension ( or hardware
   specific insertions ) and it will need to update implementation of the
   mentioned functions.
 - The introduction of copy_from_paddr() to copy the FDT to an address
   allocated in Xen's heap.

---
Changes in v2:
 - Update the cover letter.
 - Introduce new patch with aligning of upper bounds in the layout table in
   config.h with the definitions below which are inclusive.
 - Other changes please look at the specific patch.
---

Oleksii Kurochko (7):
  xen/riscv: update layout table in config.h
  xen/riscv: add destroy_xen_mappings() to remove mappings in Xen page
    tables
  xen/riscv: reorder includes in asm/page.h alphabetically
  xen/riscv: add {set,clear}_fixmap() functions for managing fixmap
    entries
  xen/riscv: implement data and instruction cache operations
  xen/riscv: implement prereq for DTB relocation
  xen/riscv: relocating and unflattening host device tree

 xen/arch/riscv/Kconfig                  |  2 +
 xen/arch/riscv/configs/tiny64_defconfig |  1 +
 xen/arch/riscv/include/asm/config.h     | 12 +++---
 xen/arch/riscv/include/asm/fixmap.h     |  5 +++
 xen/arch/riscv/include/asm/mm.h         |  8 +++-
 xen/arch/riscv/include/asm/page.h       | 34 +++++++++++++--
 xen/arch/riscv/include/asm/setup.h      |  4 ++
 xen/arch/riscv/mm.c                     |  6 ---
 xen/arch/riscv/platforms/Kconfig        |  5 +++
 xen/arch/riscv/pt.c                     | 25 +++++++++++
 xen/arch/riscv/setup.c                  | 57 ++++++++++++++++++++++++-
 11 files changed, 139 insertions(+), 20 deletions(-)
 create mode 100644 xen/arch/riscv/platforms/Kconfig

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 17:40:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 17:40:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855181.1268187 (Exim 4.92)
	(envelope-from )
	id 1tLQgr-0006kB-US; Wed, 11 Dec 2024 17:40:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855181.1268187; Wed, 11 Dec 2024 17:40:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLQgr-0006k4-RL; Wed, 11 Dec 2024 17:40:01 +0000
Received: by outflank-mailman (input) for mailman id 855181;
 Wed, 11 Dec 2024 17:40:01 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1tLQgq-0006cD-W6
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 17:40:01 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1tLQgq-00FZd6-1P;
 Wed, 11 Dec 2024 17:40:00 +0000
Received: from [15.248.2.30] (helo=[10.24.66.86])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1tLQgq-00F3JH-1W;
 Wed, 11 Dec 2024 17:40: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" 
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=nhFuV5+IEdDAr0T0ihXpY3oY+VU2mzJUxzfxzT/CMiI=; b=qoIpejGKW2JPH5Ik2vjiA0ulOS
	vVqXdmblh4WV3BqM2xzHx+aEvpFXx8Q/qlxE6mXdbTRPTZv70MSQddJaF5YLAYg7KdsEOa2bm7s1V
	4jMoi6MwFlu3Y4rXqqkB0H6+jsX9xte/IM4COa/XAUhLxPTPDva3uHD+4BfFUmP1g15c=;
Message-ID: 
Date: Wed, 11 Dec 2024 17:39:58 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] arm/domain_build: Make find_unallocated_memory() more
 generic
Content-Language: en-GB
To: Michal Orzel , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20241210101001.91578-1-michal.orzel@amd.com>
From: Julien Grall 
In-Reply-To: <20241210101001.91578-1-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Michal,

On 10/12/2024 10:10, Michal Orzel wrote:
> At the moment, find_unallocated_memory() is only used to retrieve free
> memory ranges for direct mapped domains in order to find extended
> regions. It is not generic as it makes assumptions as for the place at
> which it's being called (domain memory already allocated, gnttab region
> already found) and hardcodes the memory banks to be excluded.
> 
> Make the function more generic, so that it can be used for other
> purposes whenever there is a need to find free host memory regions (e.g.
> upcoming LLC coloring series). Allow passing array with memory banks as a
> parameter together with a callback to populate free regions structure,
> as the logic may differ depending on the needs.
> 
> Add find_host_extended_regions() to be called from make_hypervisor_node()
> to contain the logic to find extended regions for domains using host
> memory layout that are not permitted to use IOMMU.
> 
> Signed-off-by: Michal Orzel 

With one remark below:

Acked-by: Julien Grall 

> ---
> This is a prerequisite patch for LLC coloring series patch 3.
> For dom0 LLC coloring, we just need to pass resmem and gnttab in mem_banks.
> ---
>   xen/arch/arm/domain_build.c | 97 +++++++++++++++++++++----------------
>   1 file changed, 55 insertions(+), 42 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 2c30792de88b..500005079b88 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -901,31 +901,26 @@ int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
>   }
>   
>   /*
> - * Find unused regions of Host address space which can be exposed to Dom0
> - * as extended regions for the special memory mappings. In order to calculate
> - * regions we exclude every region assigned to Dom0 from the Host RAM:
> - * - domain RAM
> - * - reserved-memory
> - * - static shared memory
> - * - grant table space
> + * Find unused regions of Host address space which can be exposed to domain
> + * using the host memory layout (i.e. direct mapped or hardware domain). In

NIT: I would use "e.g." rather than "i.e." because in the future we may 
want to expose the host layout to a guest without necessarily having IPA 
== PA. You could also drop the part in () because one could find the 
definition on top of domain_use_host_layout().

> + * order to calculate regions we exclude every region passed in mem_banks from
> + * the Host RAM.
>    */
>   static int __init find_unallocated_memory(const struct kernel_info *kinfo,
> -                                          struct membanks *ext_regions)
> +                                          const struct membanks *mem_banks[],
> +                                          unsigned int nr_mem_banks,
> +                                          struct membanks *free_regions,
> +                                          int (*cb)(unsigned long s_gfn,
> +                                                    unsigned long e_gfn,
> +                                                    void *data))
>   {
>       const struct membanks *mem = bootinfo_get_mem();
> -    const struct membanks *mem_banks[] = {
> -        kernel_info_get_mem_const(kinfo),
> -        bootinfo_get_reserved_mem(),
> -#ifdef CONFIG_STATIC_SHM
> -        bootinfo_get_shmem(),
> -#endif
> -    };
>       struct rangeset *unalloc_mem;
>       paddr_t start, end;
>       unsigned int i, j;
>       int res;
>   
> -    dt_dprintk("Find unallocated memory for extended regions\n");
> +    ASSERT(domain_use_host_layout(kinfo->d));
>   
>       unalloc_mem = rangeset_new(NULL, NULL, 0);
>       if ( !unalloc_mem )

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 17:48:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 17:48:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855195.1268197 (Exim 4.92)
	(envelope-from )
	id 1tLQoz-0001zM-OU; Wed, 11 Dec 2024 17:48:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855195.1268197; Wed, 11 Dec 2024 17:48: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 1tLQoz-0001zF-Lz; Wed, 11 Dec 2024 17:48:25 +0000
Received: by outflank-mailman (input) for mailman id 855195;
 Wed, 11 Dec 2024 17:48: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 1tLQoz-0001z9-28
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 17:48:25 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1cbbfb9e-b7e8-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 18:48:22 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733939293889905.8481153499937;
 Wed, 11 Dec 2024 09:48:13 -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: 1cbbfb9e-b7e8-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1733939297; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=EbaxsIhDZ0T8EveJeM9QHEFjURLIVN23qWPyYnklrTdW5hZX1KuwerHri4GRfr60U+KQmOezIikIPrLObgxG61wDmsswOewBq1C5nLOXdjEraJr3NZtYTMZYsSN0yKoN9tICvD6Z/EphN5ZI71eyBQoYYG3Irg4kXiwBYjuHUu8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733939297; 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=YGNri/AxMCHpfyBgHH9l/zMoenKe3yZTJZzLs9MsvJA=; 
	b=ds58Qr/u4bgXuCQxJrFpWMdHzjsEw52GWCjuwSDTd8hqnRV0fAulGofN7aGinAWhN2dV7TwQSYedSvsltBbCdv7DSdj+2mOZWpIHWhRPfv6Ndh1ZYtmrVBn4+eTlwydQ8mSd0q8+CBS9a8YdCJKI8Bt9pMnVtnorOqbD/iKpyyY=
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=1733939297;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=YGNri/AxMCHpfyBgHH9l/zMoenKe3yZTJZzLs9MsvJA=;
	b=PoQKqKRju/GsyPkOqwVUX9ducm2HEzG9VYSe1RJXcaI6Q5ZydvmaHouOJJgRoVsa
	LuaIuS+Fa4oX7zj/6Q+ZY3ewWXQRiCpNn1q4zmHRMCH+blv5UloS5fia5oA9xH7KF7N
	ADUkAI3lRSuFWZ6GTPFyUXV/BAyMHnL5oUHAN/Cc=
Message-ID: <029011a0-0b7c-48e2-a98a-845588bbc7bf@apertussolutions.com>
Date: Wed, 11 Dec 2024 12:48:12 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 12/15] x86/hyperlaunch: specify dom0 mode with device tree
To: Jan Beulich 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-13-dpsmith@apertussolutions.com>
 <294035fd-45c9-4c59-a5b7-bc1ebed90e47@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <294035fd-45c9-4c59-a5b7-bc1ebed90e47@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 12/2/24 07:06, Jan Beulich wrote:
> On 23.11.2024 19:20, Daniel P. Smith wrote:
>> --- a/xen/arch/x86/domain_builder/fdt.c
>> +++ b/xen/arch/x86/domain_builder/fdt.c
>> @@ -141,6 +141,25 @@ static int __init process_domain_node(
>>               bd->domid = (domid_t)val;
>>               printk("  domid: %d\n", bd->domid);
>>           }
>> +        if ( match_fdt_property(fdt, prop, "mode" ) )
>> +        {
>> +            if ( fdt_prop_as_u32(prop, &bd->mode) != 0 )
>> +            {
>> +                printk("  failed processing mode for domain %s\n",
>> +                       name == NULL ? "unknown" : name);
>> +                return -EINVAL;
>> +            }
>> +
>> +            printk("  mode: ");
>> +            if ( !(bd->mode & BUILD_MODE_PARAVIRT) ) {
>> +                if ( bd->mode & BUILD_MODE_ENABLE_DM )
>> +                    printk("HVM\n");
>> +                else
>> +                    printk("PVH\n");
>> +            }
>> +            else
>> +                printk("PV\n");
> 
> Oh, and: What about BUILD_MODE_ENABLE_DM also being set here?

Are you asking in the sense that the PV domain is being flag as a device 
model domain? Maybe I am missing something, but I am not aware of 
anything specific that must be set for a PV domain to operate as device 
model domain. If flask is in play, then there is a secure label 
requirement but that is separate of a mode that the domain must be 
running in. Please enlighten me if I am over looking something.

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 17:59:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 17:59:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855207.1268207 (Exim 4.92)
	(envelope-from )
	id 1tLQzY-0005sr-NJ; Wed, 11 Dec 2024 17:59:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855207.1268207; Wed, 11 Dec 2024 17:59: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 1tLQzY-0005sk-KJ; Wed, 11 Dec 2024 17:59:20 +0000
Received: by outflank-mailman (input) for mailman id 855207;
 Wed, 11 Dec 2024 17:59: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 1tLQzX-0005se-PE
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 17:59:19 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a31916fe-b7e9-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 18:59:17 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 173393994988872.60557394017133;
 Wed, 11 Dec 2024 09:59:09 -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: a31916fe-b7e9-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1733939953; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=hqxRH5RV7htdgT7GRVx8ZiV5cW3j0gf7biq49LzS4fsk68BwR6hGq86Thk3KT2aBgjLTwwoYLql1ZxCbbR23gGyxXeiVtO3qbr/IFZa+wAfYO+oj3btiFxPulzQ7yWOnwpQwcj8Ey2TJTBzCZYPbVw19CJyX4x0BuiFxOkVIc/g=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733939953; 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=aUUQXotjCoae9FguMP4BnsvFjSve1T6Oc0EOyn8t6SM=; 
	b=D80qysFUmnfdm8MeqtMktXF7bGuL5Qrj1Mc3ojiOpzg3ptUUGqyfmheiUYHFfXy1TVXyFNqkWfsbLxRaubiSl0kp25wKgP88zMoJYP4ukPdnGgDOsAAM0/IpucRisBlcTJWcvIzxe1an1HUY2ZqEm/ecdFrur8+7fV7mEcJhZ9k=
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=1733939953;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=aUUQXotjCoae9FguMP4BnsvFjSve1T6Oc0EOyn8t6SM=;
	b=ZF4SmA1DxFcDbjuJtm8k77NZu8o+rUN4ubukGQAA6CmuGmf0OWejs9wgsZUSHyiH
	XyvpRC0S0w546b7Rc9MvmK0VqhzbAQAMhMrrjwgekuohh66mgEMHww/z6TQT+M4JYZ7
	3xi7455gjW4/tyQ028J5Mfb1scwa0/ZEQRRy8rWg=
Message-ID: <8072fa09-1e3c-43a7-a36c-4c965314ac22@apertussolutions.com>
Date: Wed, 11 Dec 2024 12:59:08 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 13/15] x86/hyperlaunch: add memory parsing to domain
 config
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com,
 Jan Beulich , Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-14-dpsmith@apertussolutions.com>
 <4c4d8cf0-cc31-4042-8efb-892f56047d11@amd.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <4c4d8cf0-cc31-4042-8efb-892f56047d11@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

On 11/25/24 19:03, Jason Andryuk wrote:
> On 2024-11-23 13:20, Daniel P. Smith wrote:
>> Add three properties, memory, mem-min, and mem-max, to the domain node 
>> device
>> tree parsing to define the memory allocation for a domain. All three 
>> fields are
>> expressed in kb and written as a u64 in the device tree entries.
>>
>> Signed-off-by: Daniel P. Smith 
>> ---
> 
>> diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
>> index c231191faec7..1c3b7ff0e658 100644
>> --- a/xen/arch/x86/dom0_build.c
>> +++ b/xen/arch/x86/dom0_build.c
>> @@ -609,6 +609,14 @@ int __init construct_dom0(struct boot_domain *bd)
>>       process_pending_softirqs();
>> +    /* If param dom0_size was not set and HL config provided memory 
>> size */
>> +    if ( !get_memsize(&dom0_size, LONG_MAX) && bd->mem_pages )
>> +        dom0_size.nr_pages = bd->mem_pages;
>> +    if ( !get_memsize(&dom0_min_size, LONG_MAX) && bd->min_pages )
>> +        dom0_size.nr_pages = bd->min_pages;
>> +    if ( !get_memsize(&dom0_max_size, LONG_MAX) && bd->max_pages )
>> +        dom0_size.nr_pages = bd->max_pages;
>> +
> 
> This placement seems a little random.  Can this move into 
> dom0_compute_nr_pages()?

As I started to rebase the multi-domain code around all the changes that 
happened under the boot module review, dom0_compute_nr_pages() became a 
mess to work with again. The result does see this drop in favor of 
handling during dom_compute_nr_pages(). I will look to back port that 
refactoring to here.

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 18:02:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 18:02:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855217.1268218 (Exim 4.92)
	(envelope-from )
	id 1tLR2U-000817-3t; Wed, 11 Dec 2024 18:02:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855217.1268218; Wed, 11 Dec 2024 18:02: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 1tLR2U-000810-1E; Wed, 11 Dec 2024 18:02:22 +0000
Received: by outflank-mailman (input) for mailman id 855217;
 Wed, 11 Dec 2024 18:02: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 1tLR2S-0007v6-BS
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 18:02:20 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0f6589ec-b7ea-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 19:02:19 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733940131887442.562450053406;
 Wed, 11 Dec 2024 10:02: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: 0f6589ec-b7ea-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1733940134; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=cLb54D+K610+OOP8NztLm8oHUXh7WGG8bqJx80S7L6Yg/sLBRfiBcrx2Z9WBRfVChYE1QNqFuFairNPwR3REZ80I+JcIjcT0DsDxaKFMubcNeD1AX28em+M5ZQ35y2tB4Ngq1RwIQ48bp6wELNdKEJZrTe/yAVqjuMXd6Cc5DPo=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733940134; 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=6tzOCB89aUMmzBNvnrv96m1H59rEhkXoYmeGsgmxwq8=; 
	b=P3x++HkO5+FzxFFA9caBeyH0sKVyJ7ayxAEaZeQVQzcLSBMBisKMVbFrig229fEXIoGS19QPXM5SAirzVD+FuKpv8Rl42M/82OQPI2qa6FPJzkzSlsMRH9WuyiGLxdvwP2ocsMuyBeppMJG+k2jXGa6g08NexKWXVCiHE27jMmI=
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=1733940134;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=6tzOCB89aUMmzBNvnrv96m1H59rEhkXoYmeGsgmxwq8=;
	b=abftf6WMbpdBGczyjkTvu1Scpf3hhei3IFtp0kHwzSNHjsAKlFDXx7wwAuj/LB4A
	w4jvfshHcSJqbuUd7ynnke2Mx3frzhXDerK2LpOxn1dnf+RiBIDWyKE4ZKIe5s8nBmI
	fM9pm4NmHQJmqGyigA/sGp3pqVyyNUcU9fcmvKzw=
Message-ID: <0e68ddfe-6736-4abe-b139-acd80a4bdedc@apertussolutions.com>
Date: Wed, 11 Dec 2024 13:02:10 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 13/15] x86/hyperlaunch: add memory parsing to domain
 config
To: Jan Beulich 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-14-dpsmith@apertussolutions.com>
 
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 12/2/24 07:14, Jan Beulich wrote:
> On 23.11.2024 19:20, Daniel P. Smith wrote:
>> @@ -160,6 +161,42 @@ static int __init process_domain_node(
>>               else
>>                   printk("PV\n");
>>           }
>> +        if ( match_fdt_property(fdt, prop, "memory" ) )
>> +        {
>> +            uint64_t kb;
>> +            if ( fdt_prop_as_u64(prop, &kb) != 0 )
>> +            {
>> +                printk("  failed processing memory for domain %s\n",
>> +                       name == NULL ? "unknown" : name);
>> +                return -EINVAL;
>> +            }
>> +            bd->mem_pages = PFN_DOWN(kb * SZ_1K);
>> +            printk("  memory: %ld\n", bd->mem_pages << PAGE_SHIFT);
>> +        }
>> +        if ( match_fdt_property(fdt, prop, "mem-min" ) )
>> +        {
>> +            uint64_t kb;
>> +            if ( fdt_prop_as_u64(prop, &kb) != 0 )
>> +            {
>> +                printk("  failed processing memory for domain %s\n",
>> +                       name == NULL ? "unknown" : name);
>> +                return -EINVAL;
>> +            }
>> +            bd->min_pages = PFN_DOWN(kb * SZ_1K);
>> +            printk("  min memory: %ld\n", bd->min_pages << PAGE_SHIFT);
>> +        }
>> +        if ( match_fdt_property(fdt, prop, "mem-max" ) )
>> +        {
>> +            uint64_t kb;
>> +            if ( fdt_prop_as_u64(prop, &kb) != 0 )
>> +            {
>> +                printk("  failed processing memory for domain %s\n",
>> +                       name == NULL ? "unknown" : name);
>> +                return -EINVAL;
>> +            }
>> +            bd->max_pages = PFN_DOWN(kb * SZ_1K);
>> +            printk("  max memory: %ld\n", bd->max_pages << PAGE_SHIFT);
>> +        }
> 
> Since the values logged are all multiples of 1k, why make reading the logs
> more complicated by logging byte-granular values? I instead wonder whether
> converting to more coarse grained values (leaving, say, between 4 and 6
> significant digits while using kb, Mb, Gb, etc) wouldn't be yet better.

Sure we can make it report in a friendlier format. To support dynamic 
sizing, is there already an existing formatter, I would hate to 
re-invent the wheel on this, or I could just statically report in kb.

v/r,
dps



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 18:06:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 18:06:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855233.1268227 (Exim 4.92)
	(envelope-from )
	id 1tLR5z-00014C-Kz; Wed, 11 Dec 2024 18:05:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855233.1268227; Wed, 11 Dec 2024 18:05: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 1tLR5z-000145-IP; Wed, 11 Dec 2024 18:05:59 +0000
Received: by outflank-mailman (input) for mailman id 855233;
 Wed, 11 Dec 2024 18:05: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 1tLR5y-00013u-DX
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 18:05:58 +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 907abb16-b7ea-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 19:05:56 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733940349333613.1622616607953;
 Wed, 11 Dec 2024 10:05: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: 907abb16-b7ea-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1733940351; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=IRzFixlOPDEwGnV06tDo7D/IvhDjwyCUe0KNjVdQDv/js8VexEQzL3iHa6y7VQZndweIggV+hB2kgZVg91tyEAYc1jV1vfs+zn3Q6WgUwpZtpCnCSpxg513P2BJflxf7f5CksFUG0PM/b+zfs0a1lOzROL2hs3/ag6bP2z93BUk=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733940351; 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=12ImO80Zzt0+1Mm+hbsb8wgw1RlNEeGO9yRNMtB0DDg=; 
	b=NjkN3EsY2psVZIammRihAEFuFNhpPgN0lJkrA72OveXkvGNF0jVY3vv0sTcOWW2ZQIcvtXTU0UopdL2+Pt4IL0oWY3hjDegdeQuYvUBd7C9jTbhKkxVVnoNGLERxEJ1/0VB49uYa21fZidsV1feZr7QSUbv8oDujMZB1gpgNvLo=
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=1733940351;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=12ImO80Zzt0+1Mm+hbsb8wgw1RlNEeGO9yRNMtB0DDg=;
	b=LR5JYPMCHVWDUgS0T7JZuZUuvzaPHWOulbRdMqbVi9V0oQvbcbSyJJ9uEd91qBpE
	a6ZDA+Eajm6MIo2jHkCZDHx+tfIO0np5TI/0NVGzUsj4qgZ0sUFKXYcp9zi1eO2oGZ6
	Iws7E8c/bPLXjyzCx0jvFS7H/SQu/zbq17Wlllws=
Message-ID: 
Date: Wed, 11 Dec 2024 13:05:47 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 14/15] x86/hyperlaunch: add max vcpu parsing of
 hyperlaunch device tree
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com,
 Jan Beulich , Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-15-dpsmith@apertussolutions.com>
 <0dc5d92f-5405-4eaa-ae77-bfa6a347d9d8@amd.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <0dc5d92f-5405-4eaa-ae77-bfa6a347d9d8@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

On 11/25/24 19:05, Jason Andryuk wrote:
> On 2024-11-23 13:20, Daniel P. Smith wrote:
>> Introduce the `cpus` property, named as such for dom0less 
>> compatibility, that
>> represents the maximum number of vpcus to allocate for a domain. In 
>> the device
>> tree, it will be encoded as a u32 value.
>>
>> Signed-off-by: Daniel P. Smith 
>> ---
> 
>> diff --git a/xen/arch/x86/domain_builder/fdt.c b/xen/arch/x86/ 
>> domain_builder/fdt.c
>> index b8ace5c18c6a..d24e265f2378 100644
>> --- a/xen/arch/x86/domain_builder/fdt.c
>> +++ b/xen/arch/x86/domain_builder/fdt.c
>> @@ -197,6 +197,18 @@ static int __init process_domain_node(
>>               bd->max_pages = PFN_DOWN(kb * SZ_1K);
>>               printk("  max memory: %ld\n", bd->max_pages << PAGE_SHIFT);
>>           }
>> +        if ( match_fdt_property(fdt, prop, "cpus" ) )
> 
> I think I forgot to mention it on earlier ones, but I think all these 
> match_fdt_property() should be chained together with "else if".

Ack.

> With that
> 
> Reviewed-by: Jason Andryuk 

Thanks!

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 18:20:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 18:20:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855248.1268237 (Exim 4.92)
	(envelope-from )
	id 1tLRKH-0006ls-R2; Wed, 11 Dec 2024 18:20:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855248.1268237; Wed, 11 Dec 2024 18: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 1tLRKH-0006ll-OW; Wed, 11 Dec 2024 18:20:45 +0000
Received: by outflank-mailman (input) for mailman id 855248;
 Wed, 11 Dec 2024 18:20: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 1tLRKH-0006lf-7W
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 18:20:45 +0000
Received: from mail180-17.suw31.mandrillapp.com
 (mail180-17.suw31.mandrillapp.com [198.2.180.17])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a18c2258-b7ec-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 19:20:43 +0100 (CET)
Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail180-17.suw31.mandrillapp.com (Mailchimp) with ESMTP id
 4Y7kRs54MVzRKM3Cd
 for ; Wed, 11 Dec 2024 18:20:41 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 1d39b95fe262477686aa09aac7f8edb9; Wed, 11 Dec 2024 18:20: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: a18c2258-b7ec-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1733941241; x=1734201741;
	bh=MXx6097v6tjQI3SQM06xqM84N8iVt7qg7svrUgiSIKg=;
	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=K1X7LGFSxctL8TJYxtAhoObl+y+Nf9iiEQ6A2K0CmwdF+psbYjeXKz36Rby8jBmCk
	 H3N7as4BiMvHb31NucPIkKHtwD+AFH49+Xppo2v6i6mQGDkhb4ioNdNVVvXaQNGOuL
	 o9tqZEt3XCAkC6Rzk2WvcYz6YIAfuZRDDQ4TYRbwqAyB8WlgoK7aY8RbvjgDqBtMPj
	 GIuRhmoJLwAN72Zfls/ZS2wbKV/PWekN/llQOo4X6+J1RCUm5mJk3ix6nurLQr2Wtz
	 NTChwWnYgZm4A2GI4jZWm0gCiF9jgjBVUAUPkFARMCPIiDKvi1vZ0kIVS9LgEvBUxN
	 Os7sOKTHGlcpw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1733941241; x=1734201741; i=thierry.escande@vates.tech;
	bh=MXx6097v6tjQI3SQM06xqM84N8iVt7qg7svrUgiSIKg=;
	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=LPpb4JcBcJauyzgBGfmeUdKYyanuuyElQdCfJMRVo7J+QCVOhsnOrHL63PrfLuXc+
	 GYzQxP7rGVhAvXMkjGpJUZBks7g9r37ZyyYeKTugk+mmGQlnRlAumDFGdplyRF2CJ1
	 Se6An7n4CCCxH9XtdHO+y988YbGly+wze8gMIdteBncxHU6yXaL2kjUnjiIRIvN/1j
	 Pz+sirAyrQsSlc5OpUq9Y+4+d9HrkcMY6EIMBkaNz12YhclIjlwFbX77bklCyjtSjw
	 PmY6bCS87ARtTFWr33GOaTry6471jDw+rSjeLgbkQJ3jjw3PkRFJW86FvC7I71QXSd
	 /l++yof0QYc3g==
From: "Thierry Escande" 
Subject: =?utf-8?Q?Re:=20[PATCH]=20x86/xen/mmu:=20Increase=20MAX=5FCONTIG=5FORDER?=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1733941240628
Message-Id: 
To: "Jan Beulich" 
Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, xen-devel@lists.xenproject.org, "Juergen Gross" , linux-kernel@vger.kernel.org
References: <20241204171346.458105-1-thierry.escande@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.1d39b95fe262477686aa09aac7f8edb9?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20241211:md
Date: Wed, 11 Dec 2024 18:20:41 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hi Jan,

On 09/12/2024 11:04, Jan Beulich wrote:
> On 04.12.2024 18:14, Thierry Escande wrote:
>> With change 9f40ec84a797 (xen/swiotlb: add alignment check for dma
>> buffers), the driver mpt3sas fails to load because it cannot allocate
>> its DMA pool for an allocation size of ~2,3 MBytes. This is because the
>> alignement check added by 9f40ec84a797 fails and
>> xen_swiotlb_alloc_coherent() ends up calling
>> xen_create_contiguous_region() with a size order of 10 which is too high
>> for the current max value.
>>
>> This patch increases the MAX_CONTIG_ORDER from 9 to 10 (4MB) to allow
>> such allocations.
>>
>> Signed-off-by: Thierry Escande 
>> ---
>>  arch/x86/xen/mmu_pv.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
>> index 55a4996d0c04..7f110740e1a2 100644
>> --- a/arch/x86/xen/mmu_pv.c
>> +++ b/arch/x86/xen/mmu_pv.c
>> @@ -2200,7 +2200,7 @@ void __init xen_init_mmu_ops(void)
>>  }
>>  
>>  /* Protected by xen_reservation_lock. */
>> -#define MAX_CONTIG_ORDER 9 /* 2MB */
>> +#define MAX_CONTIG_ORDER 10 /* 4MB */
>>  static unsigned long discontig_frames[1< 
> While lacking respective commentary, bumping this value imo also needs to
> take into account Xen itself, at least commit-message-wise. The bumping is
> fine for Dom0 in any event. It is also fine for DomU-s with the defaults
> built into the hypervisor (orders 12 and 10 respectively for x86 and Arm),
> yet especially for Arm (and in the future PPC and RISC-V) any further
> bumping would be less straightforward.

Thanks for pointing this out. On the Xen side, CONFIG_CTLDOM_MAX_ORDER
and CONFIG_HWDOM_MAX_ORDER seem big enough on all architectures. But I
see CONFIG_DOMU_MAX_ORDER set to 9 (also all archs). Won't that be a
problem for drivers trying to allocate more than that from a domU ?

> However - does the driver really need this big a contiguous chunk? It
> would seem far more desirable to me to break that up some, if possible.

Since this works on bare metal I'm afraid the driver maintainer (mpt
fusion driver) will just tell me to fix Xen.

Regards,
Thierry

> 
> Jan


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 19:50:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 19:50:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855263.1268248 (Exim 4.92)
	(envelope-from )
	id 1tLSiX-0000uq-VU; Wed, 11 Dec 2024 19:49:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855263.1268248; Wed, 11 Dec 2024 19:49:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLSiX-0000uj-SB; Wed, 11 Dec 2024 19:49:53 +0000
Received: by outflank-mailman (input) for mailman id 855263;
 Wed, 11 Dec 2024 19:49: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 1tLSiW-0000uc-Ny
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 19:49:52 +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 1395a458-b7f9-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 20:49:49 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733946578178640.3325830817193;
 Wed, 11 Dec 2024 11:49:38 -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: 1395a458-b7f9-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1733946580; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=hOzneaWZo6iyJbmQNns9dpq38N5tkC44ULH9yr+oSlmaZrvFIuyNQqzV6SxCYFc3B+z2LdjZ671goBuVnDEdBL5FsPkwvyyJl8qUYsjyOV/SX+lfGmzp+I+jjoQylimaFioPqhnbgtSsGG9FcGVa/9X6IVt65Vo6stxL27V12M8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733946580; 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=QRMV5mz0I1LKwrGBAt8mQqfHcldiCxpHbNA/ilPHm7A=; 
	b=DeAANlDOKTpQW+ocVsHPFZSoBEpb7I3+j4MCJBEq62bCWCFQgmgUXnIId13VETxJjpwlD5Q/A2txYwVCLUzH+6t1n0q57uoIb+5GmqvppbYL3mGns5n2NoMLV9yjsEgposBj3YZX3e0h8Sgw5IvxLJCYzaAG+t0OYMS/AePtEC0=
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=1733946580;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=QRMV5mz0I1LKwrGBAt8mQqfHcldiCxpHbNA/ilPHm7A=;
	b=Rb+cGOFfymNCKPTgTBivGUP3IV7ABcoGwtJVDRo74i3lQg82ICx8snuPKnHsofxz
	WKdYFiYZ3o7hkoTdlC22GSF16EmhtYo5wGCwZKx37KWM2rCzkMAhL+R57RtUelP5UsK
	TnwvGtmG5e4wNb/eGYoadT2QkmuIfFspNHG+R24s=
Message-ID: <18da1057-9874-44b0-a25c-f1ce733611f8@apertussolutions.com>
Date: Wed, 11 Dec 2024 14:49:36 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 14/15] x86/hyperlaunch: add max vcpu parsing of
 hyperlaunch device tree
To: Jan Beulich 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-15-dpsmith@apertussolutions.com>
 <88126e8c-96f8-4cb2-a899-eec2b800cf66@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <88126e8c-96f8-4cb2-a899-eec2b800cf66@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 12/2/24 07:19, Jan Beulich wrote:
> On 23.11.2024 19:20, Daniel P. Smith wrote:
>> --- a/xen/arch/x86/dom0_build.c
>> +++ b/xen/arch/x86/dom0_build.c
>> @@ -617,6 +617,9 @@ int __init construct_dom0(struct boot_domain *bd)
>>       if ( !get_memsize(&dom0_max_size, LONG_MAX) && bd->max_pages )
>>           dom0_size.nr_pages = bd->max_pages;
>>   
>> +    if ( opt_dom0_max_vcpus_max == UINT_MAX && bd->max_vcpus )
>> +        opt_dom0_max_vcpus_max = bd->max_vcpus;
> 
> Isn't this kind of backwards? I.e. aren't you meaning to move us towards
> boot-domains?

Prior to domain builder, available construction parameters for dom0 were 
exposed as command line parameters. This allowed for boot-time 
adjustments to the parameters. With domain builder, there are now two 
sources for dom0 construction parameters. Those coming from the device 
tree and those coming from the command line. For most x86 platforms, the 
device tree parameters can only be constructed prior to booting Xen. 
Whereas the command line parameters allow boot-time adjustments, at 
least for dom0. That is the thinking at least. Now if there is interest 
in being able to retire the command line options, that would definitely 
simplify things.

> Also, what about the counterpart opt_dom0_max_vcpus_min? That wants to be
> controllable from DT too, I would think?

Yes, in theory we will eventually be able to do requested/min/max as 
well as cpu pinning/affinity. For now it was requested we focus on 
implementing only requested vcpus.

v/r,
dps



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 19:51:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 19:51:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855273.1268258 (Exim 4.92)
	(envelope-from )
	id 1tLSk3-00030V-9C; Wed, 11 Dec 2024 19:51:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855273.1268258; Wed, 11 Dec 2024 19:51:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLSk3-00030O-6C; Wed, 11 Dec 2024 19:51:27 +0000
Received: by outflank-mailman (input) for mailman id 855273;
 Wed, 11 Dec 2024 19:51: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 1tLSk1-000306-Ea
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 19:51:25 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4ba5debe-b7f9-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 20:51:23 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733946675786887.6962878926549;
 Wed, 11 Dec 2024 11:51: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: 4ba5debe-b7f9-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1733946678; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=Jh0XrYeuquUXX6DBpf2JWYuOW5S1J7Ef8oF2q3Ld9Xu0c1tkS3GkyZZ6r/RZEs9Cp41QBX2+NRbejhs6lvL10rBfHf6/KtN6JDtIeLodU94vE3dQGZQ1PkH1HC/WU34YUpxFikgimdhDYdaM33aFk+DrPvg3yvySYUSfdnPq27c=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733946678; 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=Pt25ELFfkt7OmxOKkJjl/OzhaL1ZMQn6CcuxTcaayLQ=; 
	b=CnWE52WvhT7OPEEX1YRZgIkECiNdtwWDIXMxPOI7qmN4wWvErLgp/E3FbjOfQVkYgWf9KrpY9EYCQyaNGl8fgkr4uyIC9Fd+BgzuF6FxM9y1BrlC28R2hnSjfPS1gX0oKP1ZCbR6Iz58SnSCMBEX/g0P5qIs5vTiPGdYi7a6J0w=
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=1733946678;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=Pt25ELFfkt7OmxOKkJjl/OzhaL1ZMQn6CcuxTcaayLQ=;
	b=sWgaK1XorCDo40IfxkcUZ3laPhSnpLwYhfW4KUXUSBFbYQR0HjxaWpcVx8qYGQ7O
	KSlaCjl5JbONKMY2lfkEcL57FDqCYqFImH8GNVNSlEgk/Tc4GUzUrQuSNemOHMwwoQg
	QjECRejZ1v5F5gOkeIebypkve193fcXI7dtzQEfI=
Message-ID: <34cb3914-eb85-41bd-8205-9d2aa1ffbc31@apertussolutions.com>
Date: Wed, 11 Dec 2024 14:51:14 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 15/15] x86/hyperlaunch: add capabilities to boot domain
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com,
 Jan Beulich , Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-16-dpsmith@apertussolutions.com>
 
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

On 11/25/24 19:09, Jason Andryuk wrote:
> On 2024-11-23 13:20, Daniel P. Smith wrote:
>> Introduce the ability to assign capabilities to a domain via its 
>> definition in
>> device tree. The first capability enabled to select is the control domain
>> capability. The capability property is a bitfield in both the device 
>> tree and
>> `struct boot_domain`.
>>
>> Signed-off-by: Daniel P. Smith 
>> ---
>>   xen/arch/x86/domain_builder/core.c    |  2 +-
>>   xen/arch/x86/domain_builder/fdt.c     | 13 +++++++++++++
>>   xen/arch/x86/include/asm/bootdomain.h |  4 ++++
>>   xen/arch/x86/setup.c                  |  6 +++++-
>>   4 files changed, 23 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/x86/domain_builder/core.c b/xen/arch/x86/ 
>> domain_builder/core.c
>> index 95cab06e6159..eaa019472724 100644
>> --- a/xen/arch/x86/domain_builder/core.c
>> +++ b/xen/arch/x86/domain_builder/core.c
>> @@ -93,9 +93,9 @@ void __init builder_init(struct boot_info *bi)
>>           i = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
>>           bi->mods[i].type = BOOTMOD_KERNEL;
>>           bi->domains[0].kernel = &bi->mods[i];
>> +        bi->domains[0].capabilities |= BUILD_CAPS_CONTROL;
>>           bi->nr_domains = 1;
>>       }
>> -
> 
> This will get cleaned up earlier.
> 
> With that:
> 
> Reviewed-by: Jason Andryuk 

Thanks!


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 19:56:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 19:56:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855288.1268268 (Exim 4.92)
	(envelope-from )
	id 1tLSoz-00054w-Q5; Wed, 11 Dec 2024 19:56:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855288.1268268; Wed, 11 Dec 2024 19:56:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLSoz-00054p-Mp; Wed, 11 Dec 2024 19:56:33 +0000
Received: by outflank-mailman (input) for mailman id 855288;
 Wed, 11 Dec 2024 19:56: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 1tLSoy-000541-MK
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 19:56:32 +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 02deb21a-b7fa-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 20:56:30 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1733946980799737.5198303639822;
 Wed, 11 Dec 2024 11:56:20 -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: 02deb21a-b7fa-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1733946983; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=CUuV3w9UlJAfvPEPk5RJUwPsuVrfWuw+sDEqQqAwPHXy5lrQMcvSOCq2GNk5COl4N77poakJ2WWpea6D49MFibsiEi6FI+4oPU7on2F8cH3jw7kRrL9UVykv3qBHrY9WjqhD3xtK40ZnyUNB2anPMpkYcDcEUw5NeRjgi+rIq6Y=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733946983; 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=yAsunI+vC/1qmV0Cgw5h2c+aVx89BeUOLRPKJtqyYDI=; 
	b=QCzSTdxPlEqCc4Hz8c2baIerkP4J9KySTmttAgInV93IHA2/Ke4aA1B5TcSdp7Hhq2NoV+oVvoskLDquo+MEzqRZ6AUB2MWup7WNrkgafk42tIrlN0BIWMeHbLOpsn8XYk/s6X/VQ3CKonEzGIFb9ZlwnHUrA7PkqIVPzOJgqXk=
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=1733946983;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=yAsunI+vC/1qmV0Cgw5h2c+aVx89BeUOLRPKJtqyYDI=;
	b=eYPKbAaceFspZXQz+//1nq8FogSU6s1rW9PIkOXmFuGAOb2tfA0oG3yq0tFBndJD
	F4Gliu39xZGMNec+j11R0U4JN9Poa5G77/OjXWLRxEbsmKWVvtN9vkN1yKlQnxrVFSN
	sYYUs6BZEwoe6EQf4Hx3f0sYrKxP3dk9sS6bANqo=
Message-ID: <16a6944d-4ac5-4016-bafe-1bd8b6a4fa4d@apertussolutions.com>
Date: Wed, 11 Dec 2024 14:56:19 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 15/15] x86/hyperlaunch: add capabilities to boot domain
To: Jan Beulich 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-16-dpsmith@apertussolutions.com>
 <84bc7854-7935-4f36-b574-d19dde775673@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <84bc7854-7935-4f36-b574-d19dde775673@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 12/2/24 07:23, Jan Beulich wrote:
> On 23.11.2024 19:20, Daniel P. Smith wrote:
>> --- a/xen/arch/x86/domain_builder/fdt.c
>> +++ b/xen/arch/x86/domain_builder/fdt.c
>> @@ -209,6 +209,19 @@ static int __init process_domain_node(
>>               bd->max_vcpus = val;
>>               printk("  max vcpus: %d\n", bd->max_vcpus);
>>           }
>> +        if ( match_fdt_property(fdt, prop, "capabilities" ) )
>> +        {
>> +            if ( fdt_prop_as_u32(prop, &bd->capabilities) != 0 )
>> +            {
>> +                printk("  failed processing domain id for domain %s\n",
>> +                       name == NULL ? "unknown" : name);
>> +                return -EINVAL;
>> +            }
>> +            printk("  caps: ");
>> +            if ( bd->capabilities & BUILD_CAPS_CONTROL )
>> +                printk("c");
>> +            printk("\n");
>> +        }
> 
> What if any of the other bits is set?

I'm not sure what you are getting at, but there is another cap added 
later for HARDWARE and it will print an 'h' next to the 'c' if set.

>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -992,6 +992,7 @@ static size_t __init domain_cmdline_size(
>>   static struct domain *__init create_dom0(struct boot_info *bi)
>>   {
>>       char *cmdline = NULL;
>> +    int create_flags = 0;
> 
> Once again unsigned int please.

ack.

>> @@ -1023,7 +1024,10 @@ static struct domain *__init create_dom0(struct boot_info *bi)
>>       /* Create initial domain.  Not d0 for pvshim. */
>>       if ( bd->domid == DOMID_INVALID )
>>           bd->domid = get_initial_domain_id();
>> -    d = domain_create(bd->domid, &dom0_cfg, pv_shim ? 0 : CDF_privileged);
>> +    if ( bd->capabilities & BUILD_CAPS_CONTROL )
>> +            create_flags |= CDF_privileged;
> 
> Nit: Indentation.

ack.

v/r,
dps



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 19:57:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 19:57:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855298.1268278 (Exim 4.92)
	(envelope-from )
	id 1tLSqK-0005bF-43; Wed, 11 Dec 2024 19:57:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855298.1268278; Wed, 11 Dec 2024 19: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 1tLSqK-0005b8-0M; Wed, 11 Dec 2024 19:57:56 +0000
Received: by outflank-mailman (input) for mailman id 855298;
 Wed, 11 Dec 2024 19:57: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 1tLSqI-0005b2-N8
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 19:57:54 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3405db9b-b7fa-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 20:57:52 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 173394706513489.6879956682427;
 Wed, 11 Dec 2024 11:57: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: 3405db9b-b7fa-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1733947067; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=ePy9CWlfLu5meR+GmYVtPGmH1wA2rX1YpPAqoFU5ssSW71SnencKFAhS2gGfzeJPnWZHxqfuDi3zZtK0x3ugNJyB7ZiN0BVDpDmZ4IST0UcHGwAMbAvD89JwrFYjS9zREek0Ft7q92LDV2qHzaGikT3KDWl9wpFOnmqQQbr1t8Y=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1733947067; 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=oOUBIxcz6spn5xEIpbInUoIhgQ+SLADcKx0oqmYW8yY=; 
	b=CoOzH0ubjodqmTz66ABEz0PsU4k27WtQbnRb34qxwN0liUiqsGppGXyrdSSdnrRlxUgKW5ENXXEQSdBEhqRi7zFP6OQdRgabqNG95z6pk0XN5rEfoPNwmVN/xMqYGLQRAxEsuyPJ8alJLbO1+HIT4sxPVmRBHRXDy/Y1KYJ2XDU=
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=1733947067;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=oOUBIxcz6spn5xEIpbInUoIhgQ+SLADcKx0oqmYW8yY=;
	b=nUFgdfRFOtOPx0nPfoxwUCM6YVS+RfAJ+1SEoWeAIlbtuKCR0UIK3XuzWvnRL1kd
	cQnTLX3F9ga4qX7N1I+NoF3uLJOC2dhOwLCKS5cd0Tbydtz8QaLKI9psmemKZYAV79V
	q4IOqTL9bb/bWpRPuo3JR0SLngezg+tY9Qgi65UY=
Message-ID: <71a9d5ec-f810-410c-81a8-92dc69ffabdd@apertussolutions.com>
Date: Wed, 11 Dec 2024 14:57:43 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 00/15] Hyperlaunch device tree for dom0
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <40db3a16-0f02-4b9a-ac1c-8e237b32b006@amd.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <40db3a16-0f02-4b9a-ac1c-8e237b32b006@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 11/25/24 19:11, Jason Andryuk wrote:
> On 2024-11-23 13:20, Daniel P. Smith wrote:
>> The Hyperlaunch device tree for dom0 series is the second split out 
>> for the
>> introduction of the Hyperlaunch domain builder logic. These changes 
>> focus on
>> introducing the ability to express a domain configuration that is then 
>> used to
>> populate the struct boot_domain structure for dom0. This ability to 
>> express a
>> domain configuration provides the next step towards a general domain 
>> builder.
>>
>> The splitting of Hyperlaunch into a set of series are twofold, to 
>> reduce the
>> effort in reviewing a much larger series, and to reduce the effort in 
>> handling
>> the knock-on effects to the construction logic from requested review 
>> changes.
> 
> Having gone through this, I think you want to ensure that docs/designs/ 
> launch/hyperlaunch-devicetree.rst is updated with each patch adding a 
> property to ensure they stay in sync.

Ack.

v/r,
dps



From xen-devel-bounces@lists.xenproject.org Wed Dec 11 20:55:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 20:55:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855341.1268287 (Exim 4.92)
	(envelope-from )
	id 1tLTjo-0001wJ-QV; Wed, 11 Dec 2024 20:55:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855341.1268287; Wed, 11 Dec 2024 20:55: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 1tLTjo-0001wC-Nv; Wed, 11 Dec 2024 20:55:16 +0000
Received: by outflank-mailman (input) for mailman id 855341;
 Wed, 11 Dec 2024 20:55: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 1tLTjn-0001w6-7e
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 20:55:15 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on2061f.outbound.protection.outlook.com
 [2a01:111:f403:2414::61f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 36de4e19-b802-11ef-a0d5-8be0dac302b0;
 Wed, 11 Dec 2024 21:55:13 +0100 (CET)
Received: from BL0PR02CA0136.namprd02.prod.outlook.com (2603:10b6:208:35::41)
 by PH8PR12MB6794.namprd12.prod.outlook.com (2603:10b6:510:1c5::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Wed, 11 Dec
 2024 20:55:07 +0000
Received: from BL02EPF0002992E.namprd02.prod.outlook.com
 (2603:10b6:208:35:cafe::64) by BL0PR02CA0136.outlook.office365.com
 (2603:10b6:208:35::41) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.15 via Frontend Transport; Wed,
 11 Dec 2024 20:55:06 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL02EPF0002992E.mail.protection.outlook.com (10.167.249.59) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Wed, 11 Dec 2024 20:55:06 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) 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; Wed, 11 Dec
 2024 14:55:06 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 11 Dec
 2024 14:55:06 -0600
Received: from [172.28.102.118] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 11 Dec 2024 14:55:05 -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: 36de4e19-b802-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Y/EepAqvEW71O5iWgLvLMpaTjsyYh0z6kK2odW35Rgy1MENRjduOCZfTLrzeRKN0XK1+nxyo5NzMYs4o72gA1V2K4NopSIEFZPzhpyx3HszVexJ2TmfizUTRHgDFfABpxF/TRBJ5BQbqCVaydlCecJdjR4M/zMjdd5EQAEoed4XGLfW7sXsfj5uMYD7rOQ2zutzn0Ps/81Ix4UCpR1QN46BLghjebL20GKZ0+kGTzVVOezz8YC9gcIHtA9KkCSvIzA1BHrv/YunWEZDmiYJN8S4quNk+uDky5kJ0mMKgIXHe+RNc2ChzH1Rd9HyhA2uhwn++Wj7h7Ec+steoC40tOg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ZAv7KRx89DhcXcVv6bLoGdu/cM2Loc4RW/Vc9i+/tv4=;
 b=GZ1gC+7CIT30IlszSYdJgeYj+HbKVGlZWjjD5PKDlC9hQeCUEIn9urTrRBPXvjBtWphBRswn8bPPymf8jmn8CQPs67T5DxaFMWXwPQJfqmWqMeDzxrNQuJRQcR9YY5wz9uQe2BzpiZIXmcq1KkUp9xqHX2zF/7lpxDkwn/YlfDgR0XDlZeRUCPgkXfBCxuc0TBpA3Q5qWUQGFzPAZwPd2Dqmfokc+pW7owGYzf10GCDSib43819bsfkFejnwlUnveSaObK3PyqPnsacHDJS7qxVOGiE7hHCAmxYaQx7kRs+a3BCqRRCZhLByv+Q7LJIQqLDDsVPXu5NKlmpDZO/gIA==
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=ZAv7KRx89DhcXcVv6bLoGdu/cM2Loc4RW/Vc9i+/tv4=;
 b=ei0HkYuJChAuiDS0hf8XCrtE49KlcFtl2S/eTjbt6rGwySYyBgQA3Uy3VwOeezB8fgyvJuZBMFlyEivZ9wc+fr/gqmRcibUPDjs6vasC6inxQJwhruQOm+2PPLu9veQUSxP2cA+ZIeEN+D1jFB8p/E7pwEHyUfLsar3O3MeRNUA=
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=SATLEXMB04.amd.com; pr=C
Message-ID: <27be3779-a192-4e64-a882-cf6e6c9bb549@amd.com>
Date: Wed, 11 Dec 2024 15:55:05 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/4] xen/cppc: introduce cppc data upload sub-hypercall
To: Penny Zheng , Juergen Gross ,
	Stefano Stabellini , Oleksandr Tyshchenko
	
CC: Ray Huang , Xenia Ragiadakou
	, ,
	
References: <20241205054252.471761-1-Penny.Zheng@amd.com>
 <20241205054252.471761-5-Penny.Zheng@amd.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20241205054252.471761-5-Penny.Zheng@amd.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL02EPF0002992E:EE_|PH8PR12MB6794:EE_
X-MS-Office365-Filtering-Correlation-Id: 62bd73dd-5c0c-4121-15a2-08dd1a2617ec
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|376014|1800799024|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?SndveURHc2JwOFYrdFVkUXBkakxiRm9NV1Rhc1EzeFBsZ2tzcjVjTWoyMEZP?=
 =?utf-8?B?b2xKQVRMNElRV3ZoenlGZmc2TXdSV2V2K04xUFovVzMvWTRUbGN4cEk2L3k1?=
 =?utf-8?B?OTBFRXNWNzY0Ui9RalJZOE5QYmd4THhpRHdBQ2ZtSkxZTVdYME1QNmtpTzNV?=
 =?utf-8?B?bVFkTHhiMEtibDBCcnNNY2o4cTMxWUxOdWZlQUN4YUZ5cm1Cb0FMOGtrOWlE?=
 =?utf-8?B?SUJYSWZoaUtyV1pTTkQ4ZzIrQW11VWI2WGJTMGg4ZDRzbVFPNUpOK3pRak5y?=
 =?utf-8?B?TlJqeXFZYzNMZk93QUdOb2FsOWhDb2pITWVkSW91WmlESEhMRTlIZlRpTitv?=
 =?utf-8?B?SzNKY2tPU09qd3hGWG4zalpkSHlkNWk3aUdybUlZUURrYXkydENCOXpjV2Vn?=
 =?utf-8?B?dTFnTjZUY1hVbW1YdFgzYllHcFkrYTB0M1oxb21MT3VVWTJNNElVTm1uSTZE?=
 =?utf-8?B?ZzUvSEdKd0Q2WWxvb2Q4N2wrM01oeU1WR2RiOFQ2UjI1MmdGSmlTTWJCT2JN?=
 =?utf-8?B?aEpEZk92N3FJQTRmb0QyRTlIZlVGWTA0bm1STS9Zb2hpZzhPam4reTZPV2c2?=
 =?utf-8?B?L3o1ZGxHOEVTcTgydlExRHd5dGJrRnFYWU1GNld6T3N3MzRTcGhialhXcTJx?=
 =?utf-8?B?MG1iYWorTWkvN1hkc3BNMTQrMWdub2RpZm9BVUhZRGV5TFhUZmpzRlU1UXRV?=
 =?utf-8?B?WHFEc0dLSzJSMTFiK0x3MmlwYXNObzZzWHhnOWJlWlc1am52cGlURXRHdUdj?=
 =?utf-8?B?REM2UkNZcjA2YkxuajgrOGo2aSswTVF1NmUwaUhhYWo1Wlp4Q1BSaE9ybTVQ?=
 =?utf-8?B?RGtGaFN3NUlNWlBuMnN4U1hWcjdHd055Mi91M3lUNVZwaUZxemppekNxVmZN?=
 =?utf-8?B?Y0ZLMGZNOTdNWG5BcXpYU09MVmo5bHpqQjVnd0NUN0REWVk4SUJmL2JVOGYy?=
 =?utf-8?B?Y21FNGh5MmhlWnd0d2JUMzBhc0VxM0UzMHgxbGNtclVyNHJBSTZjdFNNYnRX?=
 =?utf-8?B?VlB5djBDdXkyb0gybXJzcWdSV2RYNGVXMUY2UC9OYmlEdnY5N1dleUtaaXpx?=
 =?utf-8?B?bkdVblg4OFpVZTJEcWEyVEpDdS9ZSTRsLy91eUZ3aXc1ODBOa1MvZXpjTEw1?=
 =?utf-8?B?dFdqZ1FWWjJQQnIra1FlMDJPTU13M1l3dUR5RzhwSUxKTFRZZ0pDNktvVGhZ?=
 =?utf-8?B?VXJ3QkhJU0ZVMExkMlk3TXZXVTIrVUZFNW5JdmNJeTAybWRpYktXaDZWMEF2?=
 =?utf-8?B?M1VhcTkvUEczWTlCVDJsY2haM2M4ekY0WFR2dmw0eC8vWlJHZ3lMdUtEbXVm?=
 =?utf-8?B?djBBM0FNMXJyazJzc2JlVUpweW45TDdmZlpnN3BObXVyazhZc1AzOENEUmxO?=
 =?utf-8?B?TUhUM1orVkZJQzJrQVVQUlBZZlRQOFdERXM2aytlanZ2d1Eyem5NMVdMb2dO?=
 =?utf-8?B?R0M2VUEwVEFEK2lkcm5ERnRnckNheGozdEdITWM1cnJqRXEyOEtqRGIxUXlI?=
 =?utf-8?B?eHpOek8xWlJxcFhxZDdhM1pOTDlMV1o3N2FKQ3RQZmplcTZ2b0hndUJkUFht?=
 =?utf-8?B?ekd6L25yS1VPUVdYSzVLc21rbGJURjYxRVZmUEFVVDFKSnNFc0M1Z1dPeG96?=
 =?utf-8?B?T1Z6T1NmcXJiaTJwVGU0N2hyS0Z2OTBod0FVQ3lpOFBsbW9yRTFIdktIOE5o?=
 =?utf-8?B?V1VrU1lFREk4M3djZloyZmlNL1pLSzZ0M1pYbHc3cG5Ydy9Ock9aRjBQRmEw?=
 =?utf-8?B?Ym1SdTlBVlpmZEdLTW9wUmcvdWFGaXd0NGFQMk90SEJjZ1ZaeGR3cU1nL2or?=
 =?utf-8?B?MGNqNnhDb09kUE5xZjNRZVJGSlBQSWRpOWl6c2s3eDYyTEdBVzZMLzV6RWdW?=
 =?utf-8?B?R1NFSmt1UkdTS1ZsZjdwRlc3YlNwOUhuaWVFSmxZdzQ4TjUwTzdwbTlFWURp?=
 =?utf-8?Q?iOUzpS1LscNjIzw2xuUzXmV9SfoP+MTe?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Dec 2024 20:55:06.8280
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 62bd73dd-5c0c-4121-15a2-08dd1a2617ec
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL02EPF0002992E.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB6794



On 2024-12-05 00:42, Penny Zheng wrote:
> As Xen is uncapable of parsing the ACPI dynamic table, this commit
> introduces a new sub-hypercall XEN_PM_CPPC to deliver CPPC perf
> caps data.
> 
> Signed-off-by: Penny Zheng 

> @@ -208,6 +213,44 @@ static int xen_copy_pct_data(struct acpi_pct_register *pct,
>   	dst_pct->address = pct->address;
>   	return 0;
>   }
> +static int push_cppc_to_hypervisor(struct acpi_processor *_pr)
> +{
> +	int ret = 0;
> +	struct xen_platform_op op = {
> +		.cmd            = XENPF_set_processor_pminfo,
> +		.interface_version  = XENPF_INTERFACE_VERSION,
> +		.u.set_pminfo.id    = _pr->acpi_id,
> +		.u.set_pminfo.type  = XEN_PM_CPPC,
> +	};
> +	struct cppc_perf_caps *cppc_perf = acpi_cppc_data + _pr->acpi_id;
> +
> +	op.u.set_pminfo.cppc_data.highest_perf = cppc_perf->highest_perf;
> +	op.u.set_pminfo.cppc_data.lowest_perf = cppc_perf->lowest_perf;
> +	op.u.set_pminfo.cppc_data.nominal_perf = cppc_perf->nominal_perf;
> +	op.u.set_pminfo.cppc_data.lowest_nonlinear_perf = cppc_perf->lowest_nonlinear_perf;
> +	op.u.set_pminfo.cppc_data.lowest_freq = cppc_perf->lowest_freq;
> +	op.u.set_pminfo.cppc_data.nominal_freq = cppc_perf->nominal_freq;
> +
> +	if (!no_hypercall)
> +		ret = HYPERVISOR_platform_op(&op);
> +
> +	if (!ret) {
> +		pr_debug("ACPI CPU%u - CPPC uploaded.\n", _pr->acpi_id);
> +		pr_debug("     highest_perf: %d\n", cppc_perf->highest_perf);
> +		pr_debug("     lowest_perf: %d\n", cppc_perf->lowest_perf);
> +		pr_debug("     lowest_nonlinear_perf: %d\n", cppc_perf->lowest_nonlinear_perf);
> +		pr_debug("     nominal_perf: %d\n", cppc_perf->nominal_perf);
> +		pr_debug("     lowest_freq: %d Mhz\n", cppc_perf->lowest_freq);
> +		pr_debug("     nominal_freq: %d Mhz\n", cppc_perf->nominal_freq);
> +	} else if ((ret != -EINVAL) && (ret != -ENOSYS))
> +		/* EINVAL means the ACPI ID is incorrect - meaning the ACPI
> +		 * table is referencing a non-existing CPU - which can happen
> +		 * with broken ACPI tables. */
> +		pr_warn("(_CPC): Hypervisor error (%d) for ACPI CPU%u\n",
> +			ret, _pr->acpi_id);
> +
> +		return ret;

I just saw gcc warn about misleading indent here given the lack of { } 
on else if above.  I think you just want a single tab indent for return.

Regards,
Jason

> +}
>   static int push_pxx_to_hypervisor(struct acpi_processor *_pr)
>   {
>   	int ret = 0;


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 23:23:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 23:23:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855193.1268298 (Exim 4.92)
	(envelope-from )
	id 1tLW2h-0003Zx-66; Wed, 11 Dec 2024 23:22:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855193.1268298; Wed, 11 Dec 2024 23:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLW2h-0003Zq-2q; Wed, 11 Dec 2024 23:22:55 +0000
Received: by outflank-mailman (input) for mailman id 855193;
 Wed, 11 Dec 2024 17:46: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 1tLQnX-0001cu-FR
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 17:46:55 +0000
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com
 [2607:f8b0:4864:20::b2b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e73b7aa4-b7e7-11ef-99a3-01e77a169b0f;
 Wed, 11 Dec 2024 18:46:52 +0100 (CET)
Received: by mail-yb1-xb2b.google.com with SMTP id
 3f1490d57ef6-e3982e9278bso5948867276.2
 for ; Wed, 11 Dec 2024 09:46: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: e73b7aa4-b7e7-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=raspberrypi.com; s=google; t=1733939211; x=1734544011; 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=XX4yF9JMGXX3II/VI0ICz4h+LN+8Yz44eu6TfJ04Ugk=;
        b=aoftBBqYd/YdaPRjL91Sjad8U5qjxmH9vbfbY9gTQwyaK2EvFEi4MfHl5Hy4j1PdNA
         9i+EQQraiQwZRClYSsDw3r8JRupy+8DlpAUGDt9XgIDCpyLvU8voCF+uqg3ZcFxaB2vO
         AGMsnjjPvVFnqLT6j4cQZAisaOr6N1BLkN49l5VRboTZZypbXQ3a3ZRDg8DCKSTjZ33F
         Jp9B0OBCtGi4Xc7LqMiYLhFsTCp2P9cSBAfVqdLBaYIivhHbZWQ6/1m0kpwdmJEbYWkV
         PaEqm3TX9IHbbOYLT8vdymQN2Ixvj5ru3E61ke4R1IUSbllaDyV1zeX/ximYHX3g795T
         PnoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733939211; x=1734544011;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=XX4yF9JMGXX3II/VI0ICz4h+LN+8Yz44eu6TfJ04Ugk=;
        b=ncc3Oypp+y16oYMFIHS1RZAkK8nf7l8NMSTekIzGat1cSx/NEGSSxx7JSWw9VlQyjx
         CDozFhmJMhVgPjh7F4gf0fK06puuo6SjEEG8s0IRkF+3gMCFj99OdlmKv8gKkfcE+A+7
         eELGHHIfL3M3qvusFFk2i+P+BGv5aVW1mMexGy1PQyY5hSPR2RN6MLJC3D7jiazzDlm2
         oyZHt30phpHKt/ZctQP4vkaACkZSAojXM1VAu9zPwD7kNAtTB07tvEIULmcu/x/mE6gV
         vYIh9vFYOCzxN99L5TCbtjujylxRK1qCR2Wybtalo5RkcU78epeHHJOeqqAKx5Fecq1S
         r14w==
X-Forwarded-Encrypted: i=1; AJvYcCWdwSqBP55xBH6CNJi52DYols1MhCu7vt+oAJiZ2AIiBqox0QqbwIpxJuhRXgi2OhLzUthJACtDVPk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yws20nK4JPKYlwOjL07E9TVJ+nZPmL5kQOraYytsexh7wDRAtkT
	+HGG4G+SupQQrNT8ciZzmrdJ/0Xaic9sZmthF3U7W98ghivQUxoWqt0pJubT6tW05T+pfVhfZ/l
	oqJbkYwWZOzer+zDsqs6jjKUAwL6dn05j7xCyCQ==
X-Gm-Gg: ASbGnctE+A4rwGvncD1y0N7YqFAo0agS17bAYcENMO36jDdpjmWojmGaVuKxxVkZPLQ
	Cv/Qs2Juj94nNKSLDZxHQudznT6Gmu6jy5n4=
X-Google-Smtp-Source: AGHT+IG3lDp6pcc8WpN9DOxtNpymp29steFnShZFR78LeXrDU2v7lqz7zSz8oGrhbnT8m3jrCYcj2LxsZTVFVNmSQds=
X-Received: by 2002:a05:6902:230d:b0:e39:8a36:5771 with SMTP id
 3f1490d57ef6-e3da3158089mr228005276.34.1733939211006; Wed, 11 Dec 2024
 09:46:51 -0800 (PST)
MIME-Version: 1.0
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
 <20241210-converge-secs-to-jiffies-v3-16-ddfefd7e9f2a@linux.microsoft.com>
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-16-ddfefd7e9f2a@linux.microsoft.com>
From: Dave Stevenson 
Date: Wed, 11 Dec 2024 17:46:32 +0000
Message-ID: 
Subject: Re: [PATCH v3 16/19] staging: vc04_services: Convert timeouts to secs_to_jiffies()
To: Easwar Hariharan 
Cc: Pablo Neira Ayuso , Jozsef Kadlecsik , 
	"David S. Miller" , Eric Dumazet , 
	Jakub Kicinski , Paolo Abeni , Simon Horman , 
	Julia Lawall , Nicolas Palix , 
	Daniel Mack , Haojian Zhuang , 
	Robert Jarzmik , Russell King , 
	Heiko Carstens , Vasily Gorbik , 
	Alexander Gordeev , Christian Borntraeger , 
	Sven Schnelle , Ofir Bitton , 
	Oded Gabbay , Lucas De Marchi , 
	=?UTF-8?Q?Thomas_Hellstr=C3=B6m?= , 
	Rodrigo Vivi , 
	Maarten Lankhorst , Maxime Ripard , 
	Thomas Zimmermann , David Airlie , Simona Vetter , 
	Jeroen de Borst , Praveen Kaligineedi , 
	Shailend Chand , Andrew Lunn , 
	James Smart , Dick Kennedy , 
	"James E.J. Bottomley" , 
	"Martin K. Petersen" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Jens Axboe , Kalle Valo , Jeff Johnson , 
	Catalin Marinas , Andrew Morton , 
	Jack Wang , Marcel Holtmann , 
	Johan Hedberg , Luiz Augusto von Dentz , 
	Greg Kroah-Hartman , 
	Florian Fainelli , Ray Jui , 
	Scott Branden , 
	Broadcom internal kernel review list , Xiubo Li , 
	Ilya Dryomov , Josh Poimboeuf , Jiri Kosina , 
	Miroslav Benes , Petr Mladek , 
	Joe Lawrence , Jaroslav Kysela , Takashi Iwai , 
	Louis Peens , Michael Ellerman , 
	Nicholas Piggin , Christophe Leroy , 
	Naveen N Rao , Madhavan Srinivasan , netfilter-devel@vger.kernel.org, 
	coreteam@netfilter.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, 
	cocci@inria.fr, linux-arm-kernel@lists.infradead.org, 
	linux-s390@vger.kernel.org, dri-devel@lists.freedesktop.org, 
	intel-xe@lists.freedesktop.org, linux-scsi@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-block@vger.kernel.org, 
	linux-wireless@vger.kernel.org, ath11k@lists.infradead.org, 
	linux-mm@kvack.org, linux-bluetooth@vger.kernel.org, 
	linux-staging@lists.linux.dev, linux-rpi-kernel@lists.infradead.org, 
	ceph-devel@vger.kernel.org, live-patching@vger.kernel.org, 
	linux-sound@vger.kernel.org, oss-drivers@corigine.com, 
	linuxppc-dev@lists.ozlabs.org, Anna-Maria Behnsen 
Content-Type: text/plain; charset="UTF-8"

On Tue, 10 Dec 2024 at 22:02, Easwar Hariharan
 wrote:
>
> Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
> secs_to_jiffies(). As the value here is a multiple of 1000, use
> secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
>
> This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
> the following Coccinelle rules:
>
> @@ constant C; @@
>
> - msecs_to_jiffies(C * 1000)
> + secs_to_jiffies(C)
>
> @@ constant C; @@
>
> - msecs_to_jiffies(C * MSEC_PER_SEC)
> + secs_to_jiffies(C)
>
> Signed-off-by: Easwar Hariharan 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
> index dc0d715ed97078ad0f0a41db78428db4f4135a76..0dbe76ee557032d7861acfc002cc203ff2e6971d 100644
> --- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
> +++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
> @@ -59,7 +59,7 @@ static int bcm2835_audio_send_msg_locked(struct bcm2835_audio_instance *instance
>
>         if (wait) {
>                 if (!wait_for_completion_timeout(&instance->msg_avail_comp,
> -                                                msecs_to_jiffies(10 * 1000))) {
> +                                                secs_to_jiffies(10))) {
>                         dev_err(instance->dev,
>                                 "vchi message timeout, msg=%d\n", m->type);
>                         return -ETIMEDOUT;
>
> --
> 2.43.0
>


From xen-devel-bounces@lists.xenproject.org Wed Dec 11 23:23:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Dec 2024 23:23:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855365.1268302 (Exim 4.92)
	(envelope-from )
	id 1tLW2h-0003bh-Cf; Wed, 11 Dec 2024 23:22:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855365.1268302; Wed, 11 Dec 2024 23:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLW2h-0003bL-9E; Wed, 11 Dec 2024 23:22:55 +0000
Received: by outflank-mailman (input) for mailman id 855365;
 Wed, 11 Dec 2024 23:21: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 1tLW1Z-0003Db-1t
 for xen-devel@lists.xenproject.org; Wed, 11 Dec 2024 23:21:45 +0000
Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.73])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id acf6f758-b816-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 00:21:40 +0100 (CET)
Received: from localhost ([141.70.80.5]) by mrelayeu.kundenserver.de (mreue109
 [212.227.15.183]) with ESMTPSA (Nemesis) id 1Mo6zF-1twmb41wmx-00fwPC; Thu, 12
 Dec 2024 00:21:37 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: acf6f758-b816-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heusel.eu;
	s=s1-ionos; t=1733959297; x=1734564097; i=christian@heusel.eu;
	bh=X+C0SkHj3MaQtDSgienyW0MYtS9PYkivpmVdSFfEqAs=;
	h=X-UI-Sender-Class:Date:From:To:Cc:Subject:Message-ID:References:
	 MIME-Version:Content-Type:In-Reply-To:cc:
	 content-transfer-encoding:content-type:date:from:message-id:
	 mime-version:reply-to:subject:to;
	b=meZ7K8wpISnGb7HlNSceUMlXxcFdIy5ldwCI0nJ/h2znE5vOdfisEQGVxfnjcEPg
	 sNkfQvXTfmyR0wb207zB/BwnibGuBKyVBSEt2vB4yfTmlDUY999MVL5ZblFZo7vq6
	 PV3WYIAeNI5OBHBoSr5GBRomfE3kZcrbyzoewoTnqm3akHkIvqSYK7dqll6DJ8pjZ
	 uHTaWVrT8SYjdMDg7+OeiFFB+Zm7nkIkIKaf3m3LeymwvCNSzMRfcVA4r8TdC0LGw
	 fkel85g7Tud6xL3+UwFbjBDmsDfBkOS9kWiN3ID49PHMr7QnGeyIScIFwIQiZRPqP
	 urt8cv0MvRvO6sZZxQ==
X-UI-Sender-Class: 55c96926-9e95-11ee-ae09-1f7a4046a0f6
Date: Thu, 12 Dec 2024 00:21:36 +0100
From: Christian Heusel 
To: Ard Biesheuvel 
Cc: Greg Kroah-Hartman , 
	Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= , =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= , 
	Jason Andryuk , Stefano Stabellini , 
	Oleksandr Tyshchenko , regressions@lists.linux.dev, 
	xen-devel 
Subject: Re: [REGRESSION] Linux 6.6.64 crashes when booting as PVH domU
Message-ID: <222e15c2-ca70-421e-8034-9dace7087920@heusel.eu>
References: 
 
 
 
 
 
 <2024121144-false-playtime-968e@gregkh>
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="eiwstsylbaon5chu"
Content-Disposition: inline
In-Reply-To: 
X-Provags-ID: V03:K1:gYOQOD8hQSxhz/imGEOxyxSITQEnr51PQ7bwoMIEojzMxnDQlrr
 wRBmSyAVuIljmPHF8pmYIBqn07c59anH/TtteXadd2OZppBhArWssnkxI2gMjeDaYM1v32j
 FVs3R0xzbshxbk2AAVBFQAWSx+zyZ3xc+329hxy3Hva1UvQIxAb3RKxwU/J4CrMtvonuLAU
 chlnTa1IV25Tq4zwzaRog==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:dDW7J3i4cKs=;sEte6PkHw1QrIQQmlfc6bdJ0xQj
 3xvV+jsFn/MVN/uyiK+HOJM4WkUZCv3jJSn7qIuDXSaYNtnlytLYm49WlysiFGZ/jOPJXxLzn
 fu0o4mv2051dToibcTJgV2SJZ52pYKlRHcYxNPjLx0Pzl5w7zfDojUhLvqqiazPKPJSEgGQB6
 DntUmKj2WowVf1TCGWhuiqdGlJ22HGO4bxRUvEv43u6jxk0jC83Z0y1UwLCFblU1TUTHcJ9+a
 uNI47KVMcYIqpujCfPONaIrclmExxqb6LEtJMA0Pu1j5kzfjRJ8s6wTAI6qUyGm1Mp/dmvxKP
 kYvmYVIge0TcatPSl49NVjR2/BlyLkLGGaPZ64UEkX5ptaDyjZl/4OemDJdTMDrqC5yF2Y0ly
 js8JuetTUx21VqJ1U/vmRxAS5S3lX5+6EpmrCaI1+jLkEO56yYjcvfZhIRtAl+O1l31wA7A5f
 Q/vu1RcgfAXx7kdBd5//+K6R8aYQj+YnEt8RuWX/G1xmNgg3y3Qg0P8oALlK2AEeKmbHTJSFx
 QI+PjX/h9g421R1wTeNNnHcHgiB2TKAJJ1K88YYt83jyEcEA3gpAg3xXLl1AxzJn3bEISk4yR
 HOvt0h23d8KfdCIkaQNS+bqFdfNjN+5/zRSbo01xGVpahPZp9RYSHJ2tTT8UOWeHTIZwjar9D
 1tTGv/8hEKrlnWV/2oqdyaYef1t5tOQ5PWSvuPINxdLWxbJIAHPJkPxV4umpTXA21RF/aeSdO
 UNchJgEoT9LYUdzenHsgp5d6C1Y7T1nnnuslGk4t3NXkpMuhKkWJUwDUml+4NaMcegLFKrG5+
 a0vpOyNes2g8sQkuSVfwjUk0fjTPfPqtn7WmxmpbgCxsFbFOGJEycZWdUctfEEKvpPlA5MB8B
 vI2uqa8DIXoewE7fH/CuwiUxQ2oCOamnlpJLrGJt5XMpbkIf5HIsMY/Op2sl4A8u80aLOACH/
 JsNExE0uWd7EZhl4BR6gvkLDgy9aLmYyle/gM7BkgD2dJxJ54/PVM98WBR3w+iTgrJ9w310WU
 8QRERib5sQHfnwmM09nJxTLxi0BJbfHWiv/HNQi


--eiwstsylbaon5chu
Content-Type: text/plain; protected-headers=v1; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: [REGRESSION] Linux 6.6.64 crashes when booting as PVH domU
MIME-Version: 1.0

On 24/12/11 04:10PM, Ard Biesheuvel wrote:
> On Wed, 11 Dec 2024 at 14:46, Greg Kroah-Hartman
>  wrote:
> >
> > On Wed, Dec 11, 2024 at 02:39:33PM +0100, Marek Marczykowski-G=F3recki =
wrote:
> > > On Wed, Dec 11, 2024 at 01:37:52PM +0100, Ard Biesheuvel wrote:
> > > > (cc Greg)
> > > >
> > > > On Wed, 11 Dec 2024 at 13:30, Marek Marczykowski-G=F3recki
> > > >  wrote:
> > > > >
> > > > > On Wed, Dec 11, 2024 at 01:24:08PM +0100, Ard Biesheuvel wrote:
> > > > > > On Wed, 11 Dec 2024 at 12:53, J=FCrgen Gro=DF =
 wrote:
> > > > > > >
> > > > > > > Jason, Ard,
> > > > > > >
> > > > > > > I guess there are some prereq patches missing in stable 6.6.y=
 branch?
> > > > > > >
> > > > > > >
> > > > > > > Juergen
> > > > > > >
> > > > > > > On 11.12.24 12:41, Marek Marczykowski-G=F3recki wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > With Linux 6.6.64 I get the following crash on domU boot:
> > > > > > > >
> > > > > > > > (XEN) d5v0 Triple fault - invoking HVM shutdown action 1
> > > > > > > > (XEN) *** Dumping Dom5 vcpu#0 state: ***
> > > > > > > > (XEN) ----[ Xen-4.19.0  x86_64  debug=3Dn  Tainted:  M     =
]----
> > > > ...
> > > > > > > >
> > > > > > > > Linux 6.6.63 works fine.
> > > > > > > >
> > > > > > > > Looking at the changes, I suspect one of those:
> > > > > > > >
> > > > > > > >      83d123e27623 x86/pvh: Call C code via the kernel virtu=
al mapping
> > > > > > > >      f662b4a69e1d x86/pvh: Set phys_base when calling xen_p=
repare_pvh()
> > > > > > > >
> > > > > >
> > > > > > The second patch shouldn't have been backported. It is unnecess=
ary,
> > > > > > given that in the old situation, the kernel image needs to be l=
oaded
> > > > > > at a fixed address. And it assumes  that %rbp is set to the phy=
sical
> > > > > > load offset, but those patches were not backported.
> > > > >
> > > > > It has this tag:
> > > > >
> > > > >     Stable-dep-of: e8fbc0d9cab6 ("x86/pvh: Call C code via the ke=
rnel virtual mapping")
> > > > >
> > > >
> > > > That was added by the stable maintainers - someone grabbed a patch
> > > > from the middle of an unrelated series to make e8fbc0d9cab6 apply
> > > > without lexical conflicts.
> > > >
> > > > > Does it mean neither of them should be backported?
> > > > >
> > > > > But then, the e8fbc0d9cab6 has "Fixes:" tag (pointing at very old
> > > > > commit).
> > > > >
> > > >
> > > > If someone thinks e8fbc0d9cab6 should be backported, they should
> > > > rebase it onto v6.6.y, not backport random other patches until
> > > > git-apply stops complaining. And ideally, someone would build and b=
oot
> > > > the result to check whether it works.
> > > >
> > > > For now, it would be better to revert both.
> > >
> > > I can confirm that reverting both commits fixes the issue.
> >
> > Ok, thanks, let me go rip all of these out and do a new release now to
> > fix the issue.  Sorry about that, and thanks so much for the testing and
> > letting us know!
> >
>=20
> I guess 6.11 is beyond repair?
>=20

Yes 6.11 is not a supported stable series anymore.

    $ curl -s https://kernel.org/releases.json | \
        jq '.releases[] | select(.version=3D=3D"6.11.11") .iseol'
    -> true

Cheers,
Chris

--eiwstsylbaon5chu
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCAAdFiEEb3ea3iR6a4oPcswTwEfU8yi1JYUFAmdaHoAACgkQwEfU8yi1
JYUe1xAArNQyyXyedV1N5sISRckfRL/ugQDTAAVDy53kYTtPjn3nyQX0oX0qceAC
AB0OQewAksKLHbxOOteciFC0muwh3XOBSDR9HcpsMTGeyGuW0V33olkDB81+o2S2
5Hl7xPl3KRYg/ygKOUABKoaXOjtZ2KHOpHzBm3QNgsYo/uFqW1IUp/t7o0EqAGdd
F68aoYA7f+oYcPWuuppuvvZBjvmU9TSIcuIuLwgqjcQpzWzlxe5I3djc8dVHNZQY
SUVffEP2GGZ+QhUFXObqi6NeI195toUpsjUjUDagBS9Bt0ui3I5ETCw1opZ4J6Lt
imLxfKetO7Lqjpmtu8wxNNkG7gKyvcuEr3ks/ag9zWt/Wv0KHFjxnS+SueskXDgT
xGXGifcoCOmiZE2CUE+91eaBrj6hRLthX5JUW03vrO1EAVx5kOevGVv6Elirr/y0
4isn6P6Vjjb0oY3ypeTCnrNwE7TF25T0QoiAUEGUhGV9YTWAMuOceeeszKXlQPf4
JVTLq6W4e1FEQef8t6rkSA8RNRGGfOgCNoQ2b7SNFmqPeo70O05Zdwom3P3JJOzR
WZf0FUHUOwIw++pMKfRBQ6ZARrI5izfo1mvN5+qo977FdFKof3AqvbxtFbbzcjF/
R2BRG1WqXRbHfQQtras4pzPAWtLC01vq478WyoCsBGDToDRoUaY=
=afDJ
-----END PGP SIGNATURE-----

--eiwstsylbaon5chu--


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 00:13:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 00:13:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855395.1268318 (Exim 4.92)
	(envelope-from )
	id 1tLWpo-0005xx-U9; Thu, 12 Dec 2024 00:13:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855395.1268318; Thu, 12 Dec 2024 00:13: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 1tLWpo-0005xq-RP; Thu, 12 Dec 2024 00:13:40 +0000
Received: by outflank-mailman (input) for mailman id 855395;
 Thu, 12 Dec 2024 00:13: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 1tLWpo-0005xa-34
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 00:13:40 +0000
Received: from EUR02-AM0-obe.outbound.protection.outlook.com
 (mail-am0eur02on2062c.outbound.protection.outlook.com
 [2a01:111:f403:2606::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ef4ecfde-b81d-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 01:13:38 +0100 (CET)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by DB9PR03MB7625.eurprd03.prod.outlook.com
 (2603:10a6:10:2bc::17) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.15; Thu, 12 Dec
 2024 00:13:34 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%7]) with mapi id 15.20.8251.008; Thu, 12 Dec 2024
 00:13: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: ef4ecfde-b81d-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=os26MnnPP9Ybn7PkGV4f/jUb0oLy1U+s6rutc5rtBQHdrjZnYW59s41IzILAthYGumAynAdbbyoAe+fM0ZpIp1TdlvYg5C2AbpylTLP8m5jCDNvcoEN1dyhX54ge10eHuLgwTTv1KYIq9JQl6XWZZLRoTE4Aef56jLE2G2D5gNzdeR5VIbRCw7S6r4S7XNWwxaW1leACqyh24xoxIx8JxMItVu2kfOSy2q0eRxERnx6eBMpSycYngRykex2LhGbi2Cquap++HR+JaoA/2lb34NQMH3uXjdqL29w5UeZUczOo2FduGUl/wsdR3z5M6meK/Q6YPp7xQLRyIa8ccQRL6A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=axs4QJ77roqbYqfnnAkUbciJgFdMd1ErBhfaw24jMAg=;
 b=EC3iKvKoIVwbkAUGyqaena/jIcKwyrJKUsjk2tsr9YeanTTm08lWnky7+ZKSAXy4py74Y3dcGYD0RI/jls6HDM+0u4u5NKYTahs0CtmCB++IVLhhQWI3CSiyV0/OEVKKbjqtwsOsCOc17n9rzgKD4oyABlbN2pRC0sXCTBIJ0uoIkWTRZkX/qpV5Ni7AQ8rKQNTrX/AFqIQbZjm5K6w0MbLGixzWJAGWxjUAgxjcZ3Limwv1j8MapstsaR69j4ZsiJ4rSFvPlHh2ZVl6DqpyuQcnUeSWCpqGyGazYwjtP7uVMU0HY2EC6yswGlYqgfhjD4JUTEJ+crWbvxPf8OpPlw==
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=axs4QJ77roqbYqfnnAkUbciJgFdMd1ErBhfaw24jMAg=;
 b=l9nUpI78hqm1pnn0iD2ieFoCdlf/77OO7fTm3EnKQmzxzJsX8SPX0aYcKJBHNc11v9iLOR/GMHHzvAVtHHyXJhpAWWLuOKpt71g9nZMk+85i46m7wCCeZIYKja8GOvsL5x7lwbUfemxQ7C/5JTjUr9eXZzg7KmYoie1690OOuxPMgs3ev6swSSvS2m+jctiZkwhpbaO3iUeBISQAi6pJEtIdvJycW0MDnELVPi1z3yH98iZyaTy8W43/W8EXgFA7+uCK4sfsa8IRQWW5LoTd0DJGg6/A/4OxOEmS1lsKknEPrRahUosGa5O+VXrQsu1GGa2KVbHCDiqRhkMP+Uspmg==
From: Volodymyr Babchuk 
To: Jan Beulich 
CC: Andrew Cooper , Julien Grall ,
	Stefano Stabellini , Anthony PERARD
	, Samuel Thibault ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Bertrand Marquis
	, Michal Orzel ,
	"xen-devel@lists.xenproject.org" 
Subject: Re: [PATCH v3 0/3] Add stack protector
Thread-Topic: [PATCH v3 0/3] Add stack protector
Thread-Index: AQHbS3EDPfnUwIrgWUmXfq3bo38udA==
Date: Thu, 12 Dec 2024 00:13:33 +0000
Message-ID: <87pllx3gib.fsf@epam.com>
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
	
In-Reply-To:  (Jan Beulich's
	message of "Wed, 11 Dec 2024 08:46:37 +0100")
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: GV1PR03MB10456:EE_|DB9PR03MB7625:EE_
x-ms-office365-filtering-correlation-id: 9c18fc56-c30e-4c0a-4c14-08dd1a41d0e6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|7416014|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?IwQfvcVJV51fXXF9LLMNTCAXJ4rXUrfPONPFluUhYmolWPjDZZ/m93RIzX?=
 =?iso-8859-1?Q?s1ylnoRKE9kVLOzCQzm7RLc+NJnwfCnDSLqQ6K7NM5DbLjvJVTOh6SPPLV?=
 =?iso-8859-1?Q?Rsw55LF4LdC4JFh/oyM2pf6ZIP2G7xYAbSGciEmJ+Q2z8/Ebk2yDqm2ejW?=
 =?iso-8859-1?Q?7QrnAD9y4P4bzZvpRO3ONVoJVRgpwKc8qmbF5qUtAUjqfc4ETfNs3feAua?=
 =?iso-8859-1?Q?vt13mHL8S2ipJPUEZqlL6qdFUV+Y18Z9lL3VtLuBuVZ4xBeT7cLR9+yOpz?=
 =?iso-8859-1?Q?kFzp2XyVPNm3Keez6ZVDuEHFtzbNRSi9kWgKgO9SmvSDpITuqbaD8nScR8?=
 =?iso-8859-1?Q?3190MY2aMCoJf/1qW4dV25P/Y9Lwd5yitLOi6rYUoHC5gI/A0JfbkVycj2?=
 =?iso-8859-1?Q?BoWbojL6zKWAKJUoWtuNu/2Kmq9dCJcjR+oHUAA34sv/PQ9xQzleIt4aqS?=
 =?iso-8859-1?Q?CwsU1VJlaiJMxc06utuEyTqqX5HnGGKqYl3TbxiTE4qeC0OH5Bzi1d2bo/?=
 =?iso-8859-1?Q?hgH5H5ceWl0AcPYEfK+nOr3v0P41mT4vMG5nnsQMyvAGkqkBzCrdPAjVoe?=
 =?iso-8859-1?Q?X+vCsGW0Q7CU4S8aUMSsnPCW/PUBUFJtAK8ukSZahxgFXflpirJ2uf/Ege?=
 =?iso-8859-1?Q?ox5v9FwTFQiIP23oNYpqQXa9VR7PE1d6ld2Z5QFDOCXTXnQxyGl5Cwk5DR?=
 =?iso-8859-1?Q?qbJ0VvMH1m9xuYsPYsJLOxXr5fsjxmuUJ4BeeA83BBNRvrV4WlAiJjEKxc?=
 =?iso-8859-1?Q?I4ISAXT2Pgp1ZbIn4HiO6jWIOUAzYeLyj2psF+nJrr9zYGG8Bsn/ydKYq6?=
 =?iso-8859-1?Q?EEWVi0xRb6dSh7yl6BT6ctJL/qFGe/iH6HZf4huXU3VlrnFj1SGgeI2rsD?=
 =?iso-8859-1?Q?y5Rslw0ZkcvasvJZAEwB4K1wGSr1sgN4p3AqCuyWxTExx6RTLtXsd3PLNd?=
 =?iso-8859-1?Q?5P9DRW86LzndgvUosQUac3PJs2c19I/fSisJORZNhy/3bjfhTg2qtu+6Tu?=
 =?iso-8859-1?Q?Cb1yODYe/3QmWSmwMNZ1iDJn46AhQ07F6lOoyhQqC+2/X0AGEAnbmSMbus?=
 =?iso-8859-1?Q?CknK0SvWsqhi8JK3iA8Eh7REBjCJB1qZcQscoA1TJgNCaAFviabtmz1Nzq?=
 =?iso-8859-1?Q?4r/BX0D3h4a5nwUOiBqTY+fAUAgJEF3NpFX6FIHP19yRxzUOrQEeXMUFN0?=
 =?iso-8859-1?Q?rN2QLQWuV4Ltm+HkaLfYhe0yAOX5kxHk9FKh9kw1VO1HYgtC0IyRKzXyWW?=
 =?iso-8859-1?Q?MYqndykd9sw+I0VB+0S+LSKloxhE79XdFWV8/6K0A9VMAtub9jbHmEdzpj?=
 =?iso-8859-1?Q?ORrTmgIPdJicIQOLAVfNajnoU6SsD8MgMXjNCiAiswQDUIuyMe9/hZuwDw?=
 =?iso-8859-1?Q?iv30Daf545OZ8vMzSzHhtj5Crol+FCIIq5sY9u1e/iu8UTqJ6EM6+S8aZW?=
 =?iso-8859-1?Q?epMaEXi2g/QN3w7Hd9j6iyUczUi6bwE/ulCkiA=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?6e9iny/2nh6ZcI6xvrowIU5zPiiHBz3nsvfUqriRGFu7MjSI7DGqwRZO4l?=
 =?iso-8859-1?Q?JEBMYyMfx9Lk5NWZ8ULRCoVuhQ5Cb0wyOP2xc926RfF+3xzIcB7l3r0gxa?=
 =?iso-8859-1?Q?M4M8OKdv/5v9Qg0zyOWxyDcMiEjFeZOCxFRoB9In6gMhGljelQOtQGZhC4?=
 =?iso-8859-1?Q?Wz/L7Nkwz+IWma+4AH3vImMJDE97U8qRAhPlF32ECsoDsE0AEgkEgQ6gOA?=
 =?iso-8859-1?Q?sIEh7p6xw++PzktKjUTce8Q5oLNcx8+aucI9sij0oJxZT8Grk1/bpLmoaC?=
 =?iso-8859-1?Q?huBDo3eXmxYxI+RoUFMZiZerbt5BGADsFdmyscOAotVNrSG6DkYI/qFhan?=
 =?iso-8859-1?Q?B53IGdkOC9niS2kfrbszytGA6BMQsNAPLaMUL4a+OyvVWdT1sWKHdeA4eo?=
 =?iso-8859-1?Q?89a8PdoQV1WOqeUQOAIKr0JpxyegmFXsolp0W35OufWVNKYWbhqkYr3dya?=
 =?iso-8859-1?Q?avk/R8nlPRgOY7/Pn1SBuuYqnhnofPQiJiulu2L7Y2P7+nKdfT1jNXuljO?=
 =?iso-8859-1?Q?ANCCmDamtvLjyGQRdhV/zWd0AW5mE2kdZZDz/pGI5XvchYkFxT/1dT02TB?=
 =?iso-8859-1?Q?Bm3Y8sKt+YZD1eW5dYVVlzKpJjVi1eobZf+vFqwJYRZvrzrr5YBPz2nKG8?=
 =?iso-8859-1?Q?GWX27NvUKzSMJdmzx/9XY+JJkT8aacpAQVGBxbDQpf9Mh7YCJGOjs6Zq7f?=
 =?iso-8859-1?Q?KvhM2T9ZD758fyClJcRhi6CjqOXgG9uf/4Y1DGkC9iIH7HARA+r7Thm1Pu?=
 =?iso-8859-1?Q?vLQuMIDvR0yXt7k6KGv8lb3xAkcMfYOUoUAcpThVIR8d/G9d5MvX/966D3?=
 =?iso-8859-1?Q?XoM7+c4CvCpm1+yoMyqNPvo0swtoQieEOjzly2nzaq1YUSJje9d47RGw6c?=
 =?iso-8859-1?Q?hwDXfobKNeYOMH2z4pmijVRcUwhADLHOUgPzLei7C1mIPAlfA9U7V2Vos8?=
 =?iso-8859-1?Q?oEejVSEtTa70W59BhUOwDEw2JJ0LCNQb7OE9CLWrFa22bxfN2PURYPjLUk?=
 =?iso-8859-1?Q?H7BH7O6qwWDBtZ+3FZmCODvnt8chizbMN0pJIjUtDetOd0kCUvglmW7BoL?=
 =?iso-8859-1?Q?itGaqrzNLcaVS+LmddPkiPHEHMlzm/KaBYVbg0/UmCNhOtDalzdeSyF0qB?=
 =?iso-8859-1?Q?NHbn837XwhCfc+R34WGvIIYgPOPVCzHIMzB9VrkRLzw6eT/vg0E64LsAX4?=
 =?iso-8859-1?Q?3WJoDseTcOvPt5QqxkVRBrBwefmIpG4tBMoT9I2ssTtGfg9qcVSTymTQD5?=
 =?iso-8859-1?Q?xbNVVXzYR5oegF5uO57yqsgKzDKnn3UGkP5bdRgsk00thfUJH/rNzvbJ4x?=
 =?iso-8859-1?Q?SGPb8Ji+bdwEHYM7l8NkGDVToazriMoWzU2Jv8WrYbet1tzw9IHaywLSuu?=
 =?iso-8859-1?Q?dPdXU21rpkEwzjEMhKvNMTG+YEWF3ssMjWo72YbaSgyiefwLsHxLXJtrkF?=
 =?iso-8859-1?Q?fnC4M28AvLahOeHdc4ialF51Err7HVH51uuSwenV2WURpz3bUkO0cHSqB2?=
 =?iso-8859-1?Q?mTzixpHwih2c5VlHYJu5JmbY4hs3Mh4mGq9mQAdXwMezBETIvrWC6XLjTf?=
 =?iso-8859-1?Q?Ti3Yoer+tIluEq68GwiLoXo/vj8ZH5WdAYP7DLJEWrIxZhA3stDEs9pV1G?=
 =?iso-8859-1?Q?Ds1PmlZF2+f3H7CAI5ap8RLCrmBjNTNkqDoKfU1oy5Xbva+Am1x2Lv7A?=
 =?iso-8859-1?Q?=3D=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: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9c18fc56-c30e-4c0a-4c14-08dd1a41d0e6
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2024 00:13:33.6370
 (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: WbBoZfuw0e5U1ePHHdHtUEtHMhCouksTCRKe8bwcniGKVigH/83Np3wl5qmScsfOgEh+6LNEStBHrZaQsUZTbTDWWIi49zkMZYyhBA058ZM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR03MB7625


Hello Jan,

Jan Beulich  writes:

> On 11.12.2024 03:04, Volodymyr Babchuk wrote:
>> Both GCC and Clang support -fstack-protector feature, which add stack
>> canaries to functions where stack corruption is possible. This series
>> makes possible to use this feature in Xen. I tested this on ARM64 and
>> it is working as intended. Tested both with GCC and Clang.
>>=20
>> It is hard to enable this feature on x86, as GCC stores stack canary
>> in %fs:40 by default, but Xen can't use %fs for various reasons. It is
>> possibly to change stack canary location new newer GCC versions, but
>> this will change minimal GCC requirement, which is also hard due to
>> various reasons. So, this series focus mostly on ARM and RISCV.
>
> Why exactly would it not be possible to offer the feature when new enough
> gcc is in use?

It is possible to use this feature with a modern enough GCC, yes. Are
you suggesting to make HAS_STACK_PROTECTOR dependent on GCC_VERSION for
x86 platform?

--=20
WBR, Volodymyr=


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 00:47:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 00:47:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855408.1268327 (Exim 4.92)
	(envelope-from )
	id 1tLXMm-00006C-86; Thu, 12 Dec 2024 00:47:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855408.1268327; Thu, 12 Dec 2024 00:47: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 1tLXMm-000065-5Y; Thu, 12 Dec 2024 00:47:44 +0000
Received: by outflank-mailman (input) for mailman id 855408;
 Thu, 12 Dec 2024 00:47: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 1tLXMl-00005z-6Q
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 00:47:43 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 (mail-am6eur05on2061e.outbound.protection.outlook.com
 [2a01:111:f403:2612::61e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b0e02588-b822-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 01:47:41 +0100 (CET)
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 (2603:10a6:150:16a::21) by AS2PR03MB9124.eurprd03.prod.outlook.com
 (2603:10a6:20b:5fb::15) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.14; Thu, 12 Dec
 2024 00:47:38 +0000
Received: from GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com
 ([fe80::a41e:5aa8:e298:757e%7]) with mapi id 15.20.8251.008; Thu, 12 Dec 2024
 00:47: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: b0e02588-b822-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=EDLxj2907HmOQ68MNalQH52JU3Y0FKX/pXdWA1uY2QGeQ2DQUHjBs22HjhqmqhA5M8B3AbDLM6wzRsKddcHUlwo6MQl/r+5oa5nU5nCYWmirre1zOWs0dUIIEoCGeTEQgMGthifGOKwIkMtVp4Ioe8Hr/8mMdGLNe9yG+qdDZmp1tYQzJu4/VGkSnER5gnGQGsWobbXZdMg/neUkvYNcM6znW9qRFAYpc/Dsx7+kjcNTmcP9G1IU+59DE4CalLdyKbZpjws0jLz8Zi1SihKqN5pkDej8HHAdF/VRXOPW/a4nSexPvPC7QDSpC8kLkaY8VgFizzJ7XWySg95G4HMK7Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=CR7AGxsyUZtscQ6lFuY5AQqMJBIqZNkWAJ1amwqw3ag=;
 b=rPTxwG++KQhMwkL1b5cpMZ0p/kZYj79LazdF4UYwtdpYUb8LrNYLdfPeBB4UsP4aR6COM39KAGOv+lv+GR1dGeWub+X3tMNqJpFlXKxKHx1ndpE7swE5xrdVAdhRwy1Oc3DL4VNAoH6CXHZCNdWutmBpvWWwSFeh9azFtFR4d0SlOtUTAyYZkkDTEjK330fDuB/N3mzTDX8vmD1k6I2TIkfSJheaLvoc6fNXzupbadB3HVNLj7BNnLzgjNa5CN2mjxMvvAe0W+jZMB5R0ZLHXwlY36Opg4kxfM1IPUJPBpt2chRwyiHdRrVBxg5k3L9WMDIgqiaqSWvQj2e+3ys0hg==
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=CR7AGxsyUZtscQ6lFuY5AQqMJBIqZNkWAJ1amwqw3ag=;
 b=bdYKG2/AJMZV1zAhcOPCUoXQFADnsapd4Do7OhUO8htrUJHUdyqVjsNhLZkf+FUWAWPFspLbO/6kU8GeAY0LgBErfIGUlp83fgTr+1LEbSGohiH3dBpRvDa76G0tYxGVEssSzTP0JoEROlvUkqzPLjxdBJFJzllvjudzLSa2/g2IsM3t5mJrdSyCRqQiyzAtRQKSpTkTq+n+RAtVYUE3XyZnlppU7n0712Oqxo4UrmsZcWz5w/h9/d1Fe45Gosh6aVNEshwDrlgXb58KAnuLHdmYXLFoEPN3oRoCKC10qWTsrYMJmr4u/gYyDSw+cErAOJk144gRahFhTn1lBtFuSA==
From: Volodymyr Babchuk 
To: Jan Beulich 
CC: Andrew Cooper , Julien Grall ,
	Stefano Stabellini , "xen-devel@lists.xenproject.org"
	
Subject: Re: [PATCH v3 2/3] xen: common: add ability to enable stack protector
Thread-Topic: [PATCH v3 2/3] xen: common: add ability to enable stack
 protector
Thread-Index: AQHbS3ED5ZENsqu4Z0+AIfWfHmGdmQ==
Date: Thu, 12 Dec 2024 00:47:38 +0000
Message-ID: <87bjxh3exi.fsf@epam.com>
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
	<20241211020424.401614-3-volodymyr_babchuk@epam.com>
	<0d04abb1-dae1-47d1-93e3-23d88399fa64@suse.com>
In-Reply-To: <0d04abb1-dae1-47d1-93e3-23d88399fa64@suse.com> (Jan Beulich's
	message of "Wed, 11 Dec 2024 09:16:47 +0100")
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: GV1PR03MB10456:EE_|AS2PR03MB9124:EE_
x-ms-office365-filtering-correlation-id: 0447eeff-13d7-4b4e-4445-08dd1a4693a9
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?C3S1JExESxDxd0eCH7PKZIXB+tP2WKw6Jagv4So3GGXGhGUV6AWBIy8GrL?=
 =?iso-8859-1?Q?I6thaN3rWZRsHdjgiM3WCCrk5e4Lsx60fLewAcAZVCOrvSZad/E+5VaqH+?=
 =?iso-8859-1?Q?V3/HMv093n7Gde218ttsDk9+OUU52EeMVuXyUxIVm9ZtjgQeKFcIUKAlzu?=
 =?iso-8859-1?Q?68bJGCaPsVFYtKbX6yDKuADF5oCVspETmcfOuX/uE4agKAaW5l/gGhTUFZ?=
 =?iso-8859-1?Q?LY2NmTl56myIVeoH54d+fXtmOiTBIU07tzHgbAAYRpsnUJBkwa/FXTSQpG?=
 =?iso-8859-1?Q?eUua8vxfmfCUROBY269bW7vdCG+bKXpDkytPMFMWQ5/wFdSOxwVUQYu0IC?=
 =?iso-8859-1?Q?zvz/r+LuRrVb6SNFAB1laGKWCBAzUykJFxSlhvs0VYC18hWC3sNuJGTMZD?=
 =?iso-8859-1?Q?tQLVarevFMGaDlAnn8NsurU9U+YgpZao8CCeZP7upFFrbOGREnCQwAD14R?=
 =?iso-8859-1?Q?pEvlEO58fZ8NTqQZxC0YeFffE7Svv2xVYbd0dBjtOziHnyrnhNNZnMG/aq?=
 =?iso-8859-1?Q?QOSSbmz5xexYVODQetERKmlc+S090PHByBqOFnfupWfqmYrHFS3Jd7XOx4?=
 =?iso-8859-1?Q?vCWp2V50t4NQUO2EU42dxP2uvWq+pRq4xybsvTpmZp437CCf3K/ABsh6AF?=
 =?iso-8859-1?Q?cEtFXLko4QczOpMTDHDQZklDTTp98ViPlgRMjZGWx3tC2qa5c4aOXtmpT2?=
 =?iso-8859-1?Q?2ul3mhHbG4hbX2cNgQBEKyvwQQfkruXU/KN4v8HfbAIRvoiGPqMiL4yeVQ?=
 =?iso-8859-1?Q?Aour/vwvPyZzTesWTul7xGUliUlJzauSI/+bgN+Kjirfko+tZmsoeFj98b?=
 =?iso-8859-1?Q?u4ESL6jlARL+QHLp9qHLnRCtdse6fd7Ln+yOGhrhbi6zulhpcDaP/CJ3/+?=
 =?iso-8859-1?Q?JqYQV0YGFJaURgslWgIki1ftx/cXWSp518xpXbweeglYyRP1lGwWRUKPg5?=
 =?iso-8859-1?Q?f2Jqtf16GV8rpct118lXNVO2XHc4OdtOUwrcFrRkwBbVExhEbe9Et2Gk9N?=
 =?iso-8859-1?Q?belYWjuek8AkttSeSirNmbGF+3JjF479B+IJka168MPxAfIXy7ZRVnEbHx?=
 =?iso-8859-1?Q?jldmlu4/ZNq3CZor/FYHIe46jGRXoh26kn+XTAjID5s8w07G2LrmdIFNqf?=
 =?iso-8859-1?Q?Jb9LtcT5HWfwgoel6oMRBAGaM9BhqcFSlyQ2GqGK1nsPrOvgPgvTcpgpek?=
 =?iso-8859-1?Q?elTOwxBgRyJMjEKiNVH2ZVaxi2AR6X4GGID7hjYoPUe+e6ipT8KHeKJdOF?=
 =?iso-8859-1?Q?kizYllS91BUAhMlk3Q1VVSoueMT5A9qZ9eprwL5j0/cjCcr5bSFzbIUQvT?=
 =?iso-8859-1?Q?LMZy39YEwIlCVxPKC9a583KEeYpiO+dAVPBZ3sjQ4eK2v8CB5n6PvRGNvN?=
 =?iso-8859-1?Q?XGDRkR/kZeBqnbE+tXXJ8ZP8Fl0QFWrYPJPTrCuSHid30l498UNY/yaFLN?=
 =?iso-8859-1?Q?GTTKVBTfEHGuVxPt/HHhvmy5woqNbAkmtAQqng=3D=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?Fk4WDSyFMq2n67h5HQZc1vfgOj4aLRzxho1MGSH7IVJljvQu5DcXzcY2mM?=
 =?iso-8859-1?Q?V+YIphmCsi1+ZiiL0d3FNWLqOxaDlDgMcioZsi/Kip+PutcgNJuDunfLVh?=
 =?iso-8859-1?Q?agqBHAOiQzeZ6rLSX2KFPfyIUWoFqr/ilxZQWSJ62YDfkLUUp9pVpw28o9?=
 =?iso-8859-1?Q?wrheklnY2dCdnycSCia8hfB4B5jFAJvDMcv1DqE4Opu+ni4mEFpwl2s/mJ?=
 =?iso-8859-1?Q?3vNYD7ZiyEp0VVxahLdQ4RCXcyUFrqWW1kqnSg2FmYqxizMPrfLuNZ5WCE?=
 =?iso-8859-1?Q?3Ijjik7Gv8ef70k1szCkvETgwPhf/nmL/xKl8IPZHAXFgyCnfnMYwwDodl?=
 =?iso-8859-1?Q?tGT5n7VFxr+gWzYQSbFcBl34jroxVVy9ZZmHx4CkLQNTWn+82ZlLfaluaa?=
 =?iso-8859-1?Q?D9u6SOF99zFu17FvEPGVELqDCaLsefcYsXjOJhjBOKgMFQw/GnrwYYdXJN?=
 =?iso-8859-1?Q?nY8nee0auG74B3NK+fXVyia9qZ1Z5z5NCVi6rKFzsu8cLcHS6xIRw6XTFn?=
 =?iso-8859-1?Q?ABxCk8aUYaSaV3rQwRQMzMtkQ888K60J7DINrXX/qcArKBaj4kEDaR5iyH?=
 =?iso-8859-1?Q?Qdr89IH/Mfew4IsIwvxvkId6ReR0AHpK12PTkBQkimP1ZDH6acIzXuinH7?=
 =?iso-8859-1?Q?mLo/G7IQNpUlpFF768LNKBFEN3H0DjnYrQdxVIInuF5oYrwwP9rVVdihx+?=
 =?iso-8859-1?Q?oeUwH5sz+ZfygI1fztVgGp0ovkHVueW8Dk8DG9RFZv1R9Q1PO/52RyyEWY?=
 =?iso-8859-1?Q?P4DXW3NRijtSTVmKw/6gap1Fb4HOD/J8XtdOFGlTqVdTKYFM5xTQ27G9Es?=
 =?iso-8859-1?Q?A033bj9XVYhtgCXSquNdCPuxn6kBxFif6/ezwbV6Xcaj6N2rf2hf1+vQOE?=
 =?iso-8859-1?Q?0//PEL/K2rTnNcAmjjyf7TxaJltBQnAROfiHuREyUWnvcpZ7Gc2mNkb7+F?=
 =?iso-8859-1?Q?D7nNiJZQ9yZNozcCEctkRmtEYPwBfwwJShlTU9bnAtOYBkKVy9k3Q96y+y?=
 =?iso-8859-1?Q?KmFF4I3R06U5yLkPPfD6YqW1ZkqBLFZjajHMTkUjL8FDV1nq5obljCK/kg?=
 =?iso-8859-1?Q?04UhBH5PoB1iWUsBR2QomHuhlaZGOxPWHlJ3dWKFBXamh4OkSMLbTzm3GK?=
 =?iso-8859-1?Q?B9wu4gP/Gp7kqXFXWlAxuWqJFie8r44mJbstRtuREFwD0XhlCglrEExZJJ?=
 =?iso-8859-1?Q?6GAaQiPPsIigwx6h3uyiLGp9gpT9qZ6GouAqCMdhfJcjdV/ehvC6h06y41?=
 =?iso-8859-1?Q?9l7ESI+jU3WYkCDaculvM/BzHBeaL1XFOk2Dtod5FkB9NmVed+Fa8EtHE+?=
 =?iso-8859-1?Q?UGBLwC/eXlb9OnPzRdqwBldbtuBc7eEEyaDKaEoQRMKpXsPBlWkiyG+n/y?=
 =?iso-8859-1?Q?OGwujT3SrGF/72r1K7yYYzOz0RZe2sZrzZ+P4X57Mr36W6liEwO9GfdRuX?=
 =?iso-8859-1?Q?RfnoQvXLb+DQ7YDpPRA+bkc5RlC4HIQMwjdcQyCB99ZlkZcfSEg4DWN1j/?=
 =?iso-8859-1?Q?YYFIU1WExjERnqRRASwhdxvbjza0VzNOKwjo5zh/OdQb2FppMGkC/CvY1q?=
 =?iso-8859-1?Q?XrwoJhCMoJfVI7zq9auOR4GMZ+//EGQz8f7aHAsPbNEBcKXI0/HBtC4a0k?=
 =?iso-8859-1?Q?pOX68Od6FTnklrYD3IyISNndTFDGNl5gR140Kj5FsaNWbJgXEyAaZ9Yw?=
 =?iso-8859-1?Q?=3D=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: GV1PR03MB10456.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0447eeff-13d7-4b4e-4445-08dd1a4693a9
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2024 00:47:38.3408
 (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: rq07u/adudQdcCd5SrLCan5XWRS66WiLhe6bq+YcPlNHgVHmRW8RHXz9yymoCXyKHNpvR7H8TiGdMmXLUK3nzNpyzrnO94THwACr4VUFd5w=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9124


Hello Jan,

Jan Beulich  writes:

> On 11.12.2024 03:04, Volodymyr Babchuk wrote:

[...]

>
>> @@ -213,6 +216,18 @@ config SPECULATIVE_HARDEN_LOCK
>> =20
>>  endmenu
>> =20
>> +menu "Compiler options"
>> +
>> +config STACK_PROTECTOR
>> +	bool "Stack protector"
>> +	depends on HAS_STACK_PROTECTOR
>> +	help
>> +	  Enable the Stack Protector compiler hardening option. This inserts a
>> +	  canary value in the stack frame of functions, and performs an integr=
ity
>> +	  check on exit.
>> +
>> +endmenu
>
> "Compiler options" reads a little odd to me as a menu title. The precedin=
g one
> is "Speculative hardening"; how about making this one "Other hardening" o=
r some
> such?

It was on of the Andrew's suggestion. Other was "Hardening". So yes, I
can rename it to "Other hardening", hope Andrew will be okay with this.

[...]

>> +/* This function should be called from ASM only */
>
> And with no (stack-protector enabled) C functions up the call stack. This
> may be as easy to express in the comment as by simply adding "early".

Like "This function should be called from early ASM only" ?

> However, considering the so far hypothetical case of offering the feature
> also on x86: What about xen.efi, which from the very start uses C code?
>

It depends on what other services are available. If RNG can be used
already, we don't need to call this function at all and can use
boot_stack_chk_guard_setup() right away.

>> +void __init asmlinkage boot_stack_chk_guard_setup_early(void)
>> +{

[...]

>> +void asmlinkage __stack_chk_fail(void)
>> +{
>> +    panic("Stack Protector integrity violation identified in %ps\n",
>> +	  __builtin_return_address(0));
>
> Again.
>
> Is panic() really the right construct to use here, though?
> __builtin_return_address() will merely identify the immediate caller. A
> full stack trace (from BUG()) would likely be more useful in identifying
> the offender.

Okay, I'll put just plain BUG(); here.

>
>> --- a/xen/include/asm-generic/random.h
>> +++ b/xen/include/asm-generic/random.h
>> @@ -2,6 +2,11 @@
>>  #ifndef __ASM_GENERIC_RANDOM_H__
>>  #define __ASM_GENERIC_RANDOM_H__
>> =20
>> +/*
>> + * When implementing arch_get_random(), please make sure that
>> + * it can provide random data before stack protector is initialized
>> + * (i.e. before boot_stack_chk_guard_setup() is called).
>> + */
>>  static inline unsigned int arch_get_random(void)
>>  {
>>      return 0;
>
> What exactly will go (entirely) wrong if the comment isn't followed?

This will not cause immediate harm, but it will give false confidence to
anyone who enables stack protector.

I'd prefer more substantial protection, but we can't even check if
random generator is available in runtime. Taking into account that we
potential can get 0 as result of RNG, we can't even put
WARN_ON(!arch_get_random()) check.

> (I'm afraid anyway that the comment living here is easy to miss.)

I didn't found a better place for it. Maybe you can suggest one?


[...]

Thank you for the review. I'll address all your other comments.

--=20
WBR, Volodymyr=


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 00:52:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 00:52:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855420.1268338 (Exim 4.92)
	(envelope-from )
	id 1tLXRk-00043S-Rq; Thu, 12 Dec 2024 00:52:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855420.1268338; Thu, 12 Dec 2024 00:52: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 1tLXRk-00043L-OY; Thu, 12 Dec 2024 00:52:52 +0000
Received: by outflank-mailman (input) for mailman id 855420;
 Thu, 12 Dec 2024 00:52: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 1tLXRj-00043F-Pe
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 00:52:51 +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 694ec305-b823-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 01:52:50 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-4361815b96cso263335e9.1
 for ; Wed, 11 Dec 2024 16:52:50 -0800 (PST)
Received: from [192.168.189.19] ([81.6.40.111])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4362559f984sm384725e9.25.2024.12.11.16.52.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 16:52: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: 694ec305-b823-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733964770; x=1734569570; 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=vCoqLBeS9dpIWkInTTrdalCtTm92FScKnOSa7+WTxt4=;
        b=fLj4Wq0PmbB0iiLcjj80amak/QyD0zq69Fty94wXZ086ByO3dQACh0bUGODXynxBQl
         YqW+UecuhGmXm3zIEYds5YVj9TsiIAiNWgHu1oiVRnXqrWZ3pOt3xWTPkRglhKiydy2H
         4Vm/9Ke20xJX60OY3Ebqc7Syntm3I81q9o0cM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733964770; x=1734569570;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=vCoqLBeS9dpIWkInTTrdalCtTm92FScKnOSa7+WTxt4=;
        b=Pz8QaIHd4ZGqAV/HlLKQ5yMZhTiUjjpEKRzIJgS8hfTwrVCEGQJWnnKGRKEiEyn1Fa
         eAH3GmqnuartGJW7LwoWZXraGMTpkk+hebuCywO9iP3nd1kRy5JyuzHbIki+tmH4ORAh
         btBBWxVaQpjSAfKrSImr3Ec++EAgVkBNxQ5nUkHL4dIfzNmPXngwZn8lkWwZJNd9Bl/i
         4KT83KOO+sKtwEL33BVHKNrdmtNecBZsG8LajGubGy3YJhXkEmx/7NPpgD1hkPMlS8Y5
         KZ1wjb/KNur52Jz7mnBU9ExtYWtq8xTX/rCroQTu6nUTRCEaejnusr2tMWFDXWL/yID9
         EyMQ==
X-Forwarded-Encrypted: i=1; AJvYcCUvBJGPzXRTSmJygqe6f9mZKGE8sti1SjcFs4yAmtZgxfphu+KXoun0E2uj0j+n02rWSWjismClG0Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx9V1vFIpWMT6eEfk7u37YRon9rr6frIK05b3BPC/VieXbExdfh
	NDX9onyv4HrP/uMktbypjOYPvbNdAsTqn4BKd18lvi33x5mYEeG+/0VRZBXwaKRFiRNSiQFLlER
	ngKZCHg==
X-Gm-Gg: ASbGncs0VymXeXyxkUykfqdEUGV/M5kXPckQkYDwVwTatyJdrEeY/IOrU7wXWdPgNZM
	v9q3hBpCodz59G3NTW4ex03aVzS3UsDBpmn/jizlCmktVSgCQnTevNCon3LlZUEzuxyeYnSDIJz
	Ck+VTlSui4QgGPNKZ3ZqKMZ2FgC8/s2ClkapgFmZawC6LTCU7jgkaxX/0CKojTyP7nQW9JJBin1
	NwUbfW3Ck793ppkwe0GN8shm4aJRYRbPANWvpwg1Z8GCqpm1dry1CDUMEPfOd5v
X-Google-Smtp-Source: AGHT+IEXQBhYH8CuetOYMFxIYVgmnXM8cDT7pS3FM8ENTQW9M4RqjmmYIMcxpkozOVnjvy1S1LN2Qg==
X-Received: by 2002:a05:600c:b86:b0:436:1c04:aa8e with SMTP id 5b1f17b1804b1-4361c3746c2mr41311665e9.16.1733964769683;
        Wed, 11 Dec 2024 16:52:49 -0800 (PST)
Message-ID: <6b5326de-1ffb-4bac-b698-0e17435e89bc@citrix.com>
Date: Thu, 12 Dec 2024 00:52:48 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/3] xen: common: add ability to enable stack protector
To: Jan Beulich ,
 Volodymyr Babchuk 
Cc: Julien Grall , Stefano Stabellini
 ,
 "xen-devel@lists.xenproject.org" 
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
 <20241211020424.401614-3-volodymyr_babchuk@epam.com>
 <0d04abb1-dae1-47d1-93e3-23d88399fa64@suse.com>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <0d04abb1-dae1-47d1-93e3-23d88399fa64@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 11/12/2024 8:16 am, Jan Beulich wrote:
> On 11.12.2024 03:04, Volodymyr Babchuk wrote:
>> Both GCC and Clang support -fstack-protector feature, which add stack
>> canaries to functions where stack corruption is possible. This patch
>> makes general preparations to enable this feature on different
>> supported architectures:
>>
>>  - Added CONFIG_HAS_STACK_PROTECTOR option so each architecture
>>    can enable this feature individually
>>  - Added user-selectable CONFIG_STACK_PROTECTOR option
>>  - Implemented code that sets up random stack canary and a basic
>>    handler for stack protector failures
>>
>> Stack guard value is initialized in three phases:
>>
>> 1. Pre-defined randomly-selected value.
>>
>> 2. Early use of linear congruent random number generator. It relies on
>> get_cycles() being available very early. If get_cycles() returns zero,
>> it would leave pre-defined value from the previous step. Even when
>> get_cycles() is available, it's return value may be easily predicted,
>> especially on embedded systems, where boot time is quite consistent.
>>
>> 3. After hypervisor is sufficiently initialized, stack guard can be
>> set-up with get_random() function, which is expected to provide better
>> randomness.
>>
>> Also this patch adds comment to asm-generic/random.h about stack
>> protector dependency on it.
>>
>> Signed-off-by: Volodymyr Babchuk 
>>
>> ---
>>
>> Changes in v3:
>>  - Fixed coding style in stack-protector.h
>>  - Extended panic() message
>>  - Included missed random.h
>>  - Renamed Kconfig option
>>  - Used Andrew's suggestion for the Kconfig help text
>>  - Added "asmlinkage" attribute to __stack_chk_fail() to make Eclair
>>  happy
>>  - Initial stack guard value is random
>>  - Added LCG to generate stack guard value at early boot stages
>>  - Added comment to asm-generic/random.h about dependencies
>>  - Extended the commit message
>>
>> Changes in v2:
>>  - Moved changes to EMBEDDED_EXTRA_CFLAGS into separate patch
>>  - Renamed stack_protector.c to stack-protector.c
>>  - Renamed stack_protector.h to stack-protector.h
>>  - Removed #ifdef CONFIG_X86 in stack-protector.h
>>  - Updated comment in stack-protector.h
>>    (also, we can't call boot_stack_chk_guard_setup() from asm code in
>>    general case, because it calls get_random() and get_random() may
>>    depend in per_cpu infrastructure, which is initialized later)
>>  - Fixed coding style
>>  - Moved CONFIG_STACK_PROTECTOR into newly added "Compiler options"
>>  submenu
>>  - Marked __stack_chk_guard as __ro_after_init
>> ---
>>  xen/Makefile                      |  4 +++
>>  xen/common/Kconfig                | 15 ++++++++++
>>  xen/common/Makefile               |  1 +
>>  xen/common/stack-protector.c      | 47 +++++++++++++++++++++++++++++++
>>  xen/include/asm-generic/random.h  |  5 ++++
>>  xen/include/xen/stack-protector.h | 30 ++++++++++++++++++++
>>  6 files changed, 102 insertions(+)
>>  create mode 100644 xen/common/stack-protector.c
>>  create mode 100644 xen/include/xen/stack-protector.h
>>
>> diff --git a/xen/Makefile b/xen/Makefile
>> index 34ed8c0fc7..0de0101fd0 100644
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -432,7 +432,11 @@ else
>>  CFLAGS_UBSAN :=
>>  endif
>>  
>> +ifeq ($(CONFIG_STACK_PROTECTOR),y)
>> +CFLAGS += -fstack-protector
>> +else
>>  CFLAGS += -fno-stack-protector
>> +endif
> Personally I'd prefer if we consistently used the list approach we use
> in various places, whenever possible:
>
> CFLAGS-stack-protector-y := -fno-stack-protector
> CFLAGS-stack-protector-$(CONFIG_STACK_PROTECTOR) := -fstack-protector
> CFLAGS += $(CFLAGS-stack-protector-y)

No - please stop this antipattern.

It saves 2 lines of code and makes the logic complete unintelligible.

I have a very strong preference for this patch to happen as Volodymyr
presented, and without the double := replacing the more-legible ifeq.

>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -86,6 +86,9 @@ config HAS_UBSAN
>>  config HAS_VMAP
>>  	bool
>>  
>> +config HAS_STACK_PROTECTOR
>> +	bool
> Please obey to alphabetic sorting in this region of the file.
>
>> @@ -213,6 +216,18 @@ config SPECULATIVE_HARDEN_LOCK
>>  
>>  endmenu
>>  
>> +menu "Compiler options"
>> +
>> +config STACK_PROTECTOR
>> +	bool "Stack protector"
>> +	depends on HAS_STACK_PROTECTOR
>> +	help
>> +	  Enable the Stack Protector compiler hardening option. This inserts a
>> +	  canary value in the stack frame of functions, and performs an integrity
>> +	  check on exit.

I'd be tempted to say "on function exit" to be a little more specific.

>> +
>> +endmenu
> "Compiler options" reads a little odd to me as a menu title. The preceding one
> is "Speculative hardening"; how about making this one "Other hardening" or some
> such?

In an ideal world, we'd have "Code hardening", with speculative just
being one item in the list beside stack protector, trivial auto var
init, FineIBT, etc.

>
>> --- /dev/null
>> +++ b/xen/common/stack-protector.c
>> @@ -0,0 +1,47 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
> Nit: I don't think we permit C++ comments as per our style.
>
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/*
>> + * Initial value is chosen by a fair dice roll.
>> + * It will be updated during boot process.
>> + */
>> +#if BITS_PER_LONG == 32
>> +unsigned long __ro_after_init __stack_chk_guard = 0xdd2cc927UL;
>> +#else
>> +unsigned long __ro_after_init __stack_chk_guard = 0x2d853605a4d9a09cUL;
>> +#endif
>> +
>> +/* This function should be called from ASM only */
> And with no (stack-protector enabled) C functions up the call stack. This
> may be as easy to express in the comment as by simply adding "early".
> However, considering the so far hypothetical case of offering the feature
> also on x86: What about xen.efi, which from the very start uses C code?

The necessary property is "with no functions to unwind that have an
active canary".

This is why it ends up as "from early assembly, or a noreturn function",
where really the latter is even really "has an exit which escapes canary
tracking, such as Xen's reset_stack_and_jmp()".

>
>> +void __init asmlinkage boot_stack_chk_guard_setup_early(void)
>> +{
>> +    /*
>> +     * Linear congruent generator (X_n+1 = X_n * a + c).
>> +     *
>> +     * Constant is taken from "Tables Of Linear Congruential
>> +     * Generators Of Different Sizes And Good Lattice Structure" by
>> +     * Pierre L’Ecuyer.
>> +     */
>> +#if BITS_PER_LONG == 32
>> +    const unsigned long a = 2891336453UL;
>> +#else
>> +    const unsigned long a = 2862933555777941757UL;
>> +#endif
>> +    const unsigned long c = 1;
>> +
>> +    unsigned long cycles = get_cycles();
>> +
>> +    /* Use the initial value if we can't generate random one */
>> +    if ( !cycles )
>> +	    return;
> Nit: Indentation (no hard tabs please).
>
>> +    __stack_chk_guard = cycles * a + c;
>> +}

This is much much nicer.

That said, I don't think we two different setup phases.  I'd suggest
having only this get_cycles implementation and ignore the later
get_random() setup.

It's definitely good enough for a v1, (and frankly, get_random() wants
some separate improvements anyway.)


>> +
>> +void asmlinkage __stack_chk_fail(void)
>> +{
>> +    panic("Stack Protector integrity violation identified in %ps\n",
>> +	  __builtin_return_address(0));
> Again.
>
> Is panic() really the right construct to use here, though?
> __builtin_return_address() will merely identify the immediate caller. A
> full stack trace (from BUG()) would likely be more useful in identifying
> the offender.

Well - we have to be careful, because the backtrace from here is
specifically misleading in this case.

When this trips, it's either the caller itself that broke, or some
sibling call tree which is rubble under the active stack now.

BUG() also comes with 0 information.

So, maybe we want a dump_execution_state() (to get the backtrace), and
then this panic() which states it was a Stack Protection violation,
which hopefully is enough of a hint to people to look in the sibling
call tree.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 01:08:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 01:08:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855437.1268349 (Exim 4.92)
	(envelope-from )
	id 1tLXh6-0007Wg-Ar; Thu, 12 Dec 2024 01:08:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855437.1268349; Thu, 12 Dec 2024 01: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 1tLXh6-0007WY-5N; Thu, 12 Dec 2024 01:08:44 +0000
Received: by outflank-mailman (input) for mailman id 855437;
 Thu, 12 Dec 2024 01:08: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 1tLXh5-0007WS-6z
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 01:08:43 +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 9fcf93dc-b825-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 02:08:40 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-43618283d48so319065e9.1
 for ; Wed, 11 Dec 2024 17:08:40 -0800 (PST)
Received: from [192.168.189.19] ([81.6.40.111])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4362571776asm497505e9.40.2024.12.11.17.08.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 17:08: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: 9fcf93dc-b825-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733965720; x=1734570520; 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=TP9LdhWnkwuR4BVtDr1TfyZDD6u3r+pSiUAXCQnKV+Y=;
        b=LBpokgrqHePVgGVLnSc97af83XTLYPmDfhd9Jt1IbwZ7D9w+0QePY+KMma9oW2rl48
         CsMKPlFeaGDzvDX8L2m7L37G1+k37lmcuOVoEBcodCiG18Gxud+a7NATZYNH+Pm8b8eM
         dDu0mrKnYlRToaOzcYw/HBXLUfcXkMR/0xjVI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733965720; x=1734570520;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=TP9LdhWnkwuR4BVtDr1TfyZDD6u3r+pSiUAXCQnKV+Y=;
        b=pMlSnE+oEpI462ZZKWLhvwqI30t9W+Xh5/csUajROJFGn35atG+YduV+iCpBboyi+j
         vlsrkaS950UTDxXaD7cI8REY0ST/KkW5qX8ZJYAU/1tyg8yCAOMTKsuNgkFy1lo1Wxj+
         PYhIBFCY/C4G92N+LEcW0S3/iGzORTCoIs0au8xr85pdjP4d6NAy5p5fchjCreFyTLzD
         12UoRErbtRtbJ0K5jOivbcA4bXBZC4OJm/TV0PJHwfSyhcD+8yDzzREiHwLijcmKPd1T
         TP839M/7MGGkWQprUmtOhJwKkMXhgNQr76tNwIV5KKug7QnBVdnGO/PJKKejFJav1nSR
         RzAw==
X-Forwarded-Encrypted: i=1; AJvYcCUoargfCY+pmi5aq33ZLiAwGyeKUDDLGf/ocutEetAib7IKKE8GOSVsjvoGXZR6bodyvWpcMiwn9s4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzG54zBVuX8Ade/AZgqHdHTTAL+kpf7d3Zu11c0xj6eid8Fmcjl
	90VT3xpvCN/VGSUbbVzAtXSI1bcyMdNy/qzPeopBa4WJgm3HMeRKFTBCXtFZ4Q8xelZFVV1cFdH
	AJ97U5A==
X-Gm-Gg: ASbGncs7Urp5q/ojG+NJZYbt3Ctl5LC8esaXrv3YezyShZTaUlFFZk2C417IKfRTtSi
	STG61EXw7VpChZtidHVNR6GiKa+E/Ul2KYAHafNPFaInLs8PBEAtJ0X9BntWxYb8YpAFLUjFElR
	tY+AxVD4Nutnm56F8bmQKKOsX+3ZBDIBCPcUHjPwh5rDhhAZqxNzkIrrha56UKsjp8zfLbyOiRp
	+DDqtpXxkH3uVskb61KeR6jV7+bXAyL9INPkMF5f5SkvtUECY5mTN2He9B/P3lF
X-Google-Smtp-Source: AGHT+IFF6035NWPK1cRIr2atBUFPRX+LPderE7e4YKEWbhwrT4aDgMM15J/jXOxAEjRvvPs6mq6UCw==
X-Received: by 2002:a05:600c:5101:b0:435:136:75f6 with SMTP id 5b1f17b1804b1-4361c2bbc4amr41066375e9.0.1733965720192;
        Wed, 11 Dec 2024 17:08:40 -0800 (PST)
Message-ID: 
Date: Thu, 12 Dec 2024 01:08:38 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/3] common: remove -fno-stack-protector from
 EMBEDDED_EXTRA_CFLAGS
To: Volodymyr Babchuk ,
 "xen-devel@lists.xenproject.org" 
Cc: Jan Beulich , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Samuel Thibault ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
 <20241211020424.401614-2-volodymyr_babchuk@epam.com>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20241211020424.401614-2-volodymyr_babchuk@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 11/12/2024 2:04 am, Volodymyr Babchuk wrote:
> This patch is preparation for making stack protector
> configurable. First step is to remove -fno-stack-protector flag from
> EMBEDDED_EXTRA_CFLAGS so separate components (Hypervisor in this case)
> can enable/disable this feature by themselves.
>
> Signed-off-by: Volodymyr Babchuk 

This doesn't build on x86.

You need this hunk too,

diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index d45787665907..ff0d61d7ac39 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -17,6 +17,7 @@ obj32 := $(addprefix $(obj)/,$(obj32))
 CFLAGS_x86_32 := $(subst -m64,-m32 -march=i686,$(XEN_TREEWIDE_CFLAGS))
 $(call cc-options-add,CFLAGS_x86_32,CC,$(EMBEDDED_EXTRA_CFLAGS))
 CFLAGS_x86_32 += -Werror -fno-builtin -g0 -msoft-float -mregparm=3
+CFLAGS_x86_32 += -fno-stack-protector
 CFLAGS_x86_32 += -nostdinc -include $(filter
%/include/xen/config.h,$(XEN_CFLAGS))
 CFLAGS_x86_32 += $(filter -I% -O%,$(XEN_CFLAGS)) -D__XEN__
 
because CFLAGS_x86_32 really was using -fno-stack-protector to override
the compilers inbuilt choice.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 01:17:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 01:17:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855450.1268358 (Exim 4.92)
	(envelope-from )
	id 1tLXpc-0003AI-1x; Thu, 12 Dec 2024 01:17:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855450.1268358; Thu, 12 Dec 2024 01:17: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 1tLXpb-0003AB-UU; Thu, 12 Dec 2024 01:17:31 +0000
Received: by outflank-mailman (input) for mailman id 855450;
 Thu, 12 Dec 2024 01:17: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 1tLXpa-0003A5-8E
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 01:17:30 +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 da9acf96-b826-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 02:17:29 +0100 (CET)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-385e3621518so13998f8f.1
 for ; Wed, 11 Dec 2024 17:17:29 -0800 (PST)
Received: from [192.168.189.19] ([81.6.40.111])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3878251c4e1sm2564022f8f.89.2024.12.11.17.17.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 17:17: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: da9acf96-b826-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733966248; x=1734571048; 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=18uw1qSoAWfFGPpqjRt2lgQFGAo3CbWDaWK05fK9KmM=;
        b=SO0Y2L67D7hD0hby9Jqlfz9qYhbFGOTNkj2pEluat3+9z80sThKmQcW7e2Corh+iLQ
         iclBbc2t0YgyQX4Sx1HrLYJ8z4WhSl/pw5p3JIaDDjE3rVe7cJs58mAfD5TKv9C+8RhK
         zNd6OqbRkSIoiN8mtcjFQ5hOsfBRd6GkBlbTE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733966248; x=1734571048;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=18uw1qSoAWfFGPpqjRt2lgQFGAo3CbWDaWK05fK9KmM=;
        b=C+zT3bnpCR2gM8LLidCBZ9MkDWDvMVKiXfZUDt5zih6eyKkJJy3c3DgW6npvnD0Mh5
         V1oDZ0RQl0OPmfowRX6nUF35fx3jVH9HB1HrltzBRhjZGfXXgW5XjEOroVkmb84wVjIr
         1atqWYx5HPtMuPaeeLl4KV/5gEsnDVU/g/ri4r1kLjndGwhGlvGwuMSvbz7LnwR/iqk+
         sqW/tFUHTyWAUoXz/gjP/ztOfc6NNkKyO+9aFwyfd2zxXdrQ7g+80zTaeycVLNB1fo6h
         0rH8cD9ZIVk+xH1EVjwz2oaK5BQNhZ4EMFmbhYolrLAvKhlmpRhSl/QyZ/eS9CtgMTT1
         f4Qg==
X-Forwarded-Encrypted: i=1; AJvYcCWzpK8Y+grDz89N5tF7+1Goyyf4Gnls6rTnTfdchlP618i8x9kROydXaY69Kgx2Z8JAHvHM2pOzGFY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx5urovES4UqIa50BAPBMGfOCta7J9ETG41w/ljrK671JCgQISa
	mi7kOUeQiQ8q6ah9SzO8X8GubT2SzhTEso6Jg7Tp4DJtd2HFnqwJGb12UppJDkI=
X-Gm-Gg: ASbGncueQALRPxscHlvdDuPKiVoHO2rjcX9iwhtESB5wRI9+nRMoFv26/YHX6Dg6l06
	sgisQ2LlwcrhCzS7lgthNVpyxz58HfUunVAGpm7B6KWAcAVjW9g1QZG/grIJDaW8Mr0r9ex9IBS
	bgBLDDYIZ+pkj+jLvL1YWFEGeHBk1Qr6IhcTxdGD6WqezpRvxJmaqREhb6FNh9A61GmfVsnVFo2
	3glG0M7p0fVv9nLUo9PzHWjETmLCpKzDVgZSymnK8MnDQLKmfBpNO/rIpa8bqmI09Q=
X-Google-Smtp-Source: AGHT+IHrVSqxm+RQc72lUrg49gTNgalA7n18Z1JXGeInPdIpjqSF++ynetQrTMpQL65yRS+bedk2mg==
X-Received: by 2002:a5d:6487:0:b0:385:fc32:1ec6 with SMTP id ffacd0b85a97d-387876c37abmr1153850f8f.50.1733966248214;
        Wed, 11 Dec 2024 17:17:28 -0800 (PST)
Message-ID: 
Date: Thu, 12 Dec 2024 01:17:26 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/3] Add stack protector
To: Volodymyr Babchuk ,
 Jan Beulich 
Cc: Julien Grall , Stefano Stabellini
 , Anthony PERARD ,
 Samuel Thibault ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Bertrand Marquis ,
 Michal Orzel ,
 "xen-devel@lists.xenproject.org" 
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
  <87pllx3gib.fsf@epam.com>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <87pllx3gib.fsf@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12/12/2024 12:13 am, Volodymyr Babchuk wrote:
> Hello Jan,
>
> Jan Beulich  writes:
>
>> On 11.12.2024 03:04, Volodymyr Babchuk wrote:
>>> Both GCC and Clang support -fstack-protector feature, which add stack
>>> canaries to functions where stack corruption is possible. This series
>>> makes possible to use this feature in Xen. I tested this on ARM64 and
>>> it is working as intended. Tested both with GCC and Clang.
>>>
>>> It is hard to enable this feature on x86, as GCC stores stack canary
>>> in %fs:40 by default, but Xen can't use %fs for various reasons. It is
>>> possibly to change stack canary location new newer GCC versions, but
>>> this will change minimal GCC requirement, which is also hard due to
>>> various reasons. So, this series focus mostly on ARM and RISCV.
>> Why exactly would it not be possible to offer the feature when new enough
>> gcc is in use?
> It is possible to use this feature with a modern enough GCC, yes. Are
> you suggesting to make HAS_STACK_PROTECTOR dependent on GCC_VERSION for
> x86 platform?

(With the knowledge that this is a disputed Kconfig pattern, and will
need rebasing), the way I want this to work is simply:

diff --git a/xen/Makefile b/xen/Makefile
index 0de0101fd0bf..5d0a88fb3c3f 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -434,6 +434,9 @@ endif
 
 ifeq ($(CONFIG_STACK_PROTECTOR),y)
 CFLAGS += -fstack-protector
+ifeq ($(CONFIG_X86),y)
+CFLAGS += -mstack-protector-guard=global
+endif
 else
 CFLAGS += -fno-stack-protector
 endif
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 9cdd04721afa..7951ca908b36 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -28,6 +28,7 @@ config X86
        select HAS_PCI_MSI
        select HAS_PIRQ
        select HAS_SCHED_GRANULARITY
+       select HAS_STACK_PROTECTOR if
$(cc-option,-mstack-protector-guard=global)
        select HAS_UBSAN
        select HAS_VMAP
        select HAS_VPCI if HVM



Sadly, it doesn't build.  I get a handful of:

prelink.o: in function `cmdline_parse':
/home/andrew/xen.git/xen/common/kernel.c:216:(.init.text+0x20f2): failed
to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
--no-relax
/home/andrew/xen.git/xen/common/kernel.c:230:(.init.text+0x246f): failed
to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
--no-relax

which is more toolchain-whispering than I feel like doing tonight.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 01:19:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 01:19:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855460.1268367 (Exim 4.92)
	(envelope-from )
	id 1tLXr7-0003i3-B4; Thu, 12 Dec 2024 01:19:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855460.1268367; Thu, 12 Dec 2024 01:19: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 1tLXr7-0003hw-8X; Thu, 12 Dec 2024 01:19:05 +0000
Received: by outflank-mailman (input) for mailman id 855460;
 Thu, 12 Dec 2024 01:19: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 1tLXr6-0003hq-Ri
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 01:19:04 +0000
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com
 [2a00:1450:4864:20::42c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1342b688-b827-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 02:19:04 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-3862df95f92so13077f8f.2
 for ; Wed, 11 Dec 2024 17:19:03 -0800 (PST)
Received: from [192.168.189.19] ([81.6.40.111])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-387824bf19dsm2475539f8f.53.2024.12.11.17.19.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 11 Dec 2024 17:19: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: 1342b688-b827-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733966343; x=1734571143; 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=8bMWNK4gk5o2HwpQpcH+JiKGsPZRHmNcrB5vZ8Ao1og=;
        b=meB56vR20IqB7rJrSSrcz6oj6G0/S1R+M3BFyOT5FOjTNGid8Pv/PoUL9IK5SJhM1h
         dSGqhhvPqRY7QdQwOuN397uinljVCnzE1tOnwKXAwCdf74y3CiKp8rdDHrVkYjqw0Cmj
         6rf3GJ3qBWsEBD8hNcAPEuERZJph0bXu21DrA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733966343; x=1734571143;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=8bMWNK4gk5o2HwpQpcH+JiKGsPZRHmNcrB5vZ8Ao1og=;
        b=J5iZY+WxeRhS/67b68I3cmN1oBo+PIeM0KJq3JEOl83/pkOp5fm6GlCIFA1iW7O8gw
         ABwjOHtPcIikNDh1pgW3LYO9uQAPQwLmDfrXQEirWbDfJLQ+dgQK7JikjFUC4s4FpKnv
         R4QeqbqjZCCDTN+oBG4r48wNmy9sqr0krIFoMzOfM/RpMAney7qi9LACEkAQUfIc39Ve
         iSsZi+47gnhwZ2QyoWaBozuFvMmHl1YBB+s20xbbZNsKA8s4HQcZwMPQt7nNCjh7byOp
         UyxlwzAWCbcR7dkxlmP9Yw9GgIJX0tzqjtZtIuiWBm4jYci2hmhsrIxz89CWXYW+uA6Q
         moRQ==
X-Forwarded-Encrypted: i=1; AJvYcCWQ7fnMduxrluZcV1KhA5ueEdbpgWI/zB9ioC+eU2hnwXE2D+cuJfpPFUopYBRAjYKW8BpGDAVtCio=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxhy0XtWu8cx0ND6tKE4UGEps8B1x+tzq+nX2F3zewhqVQu+n/w
	HB64udqHMjkZfqLT74FVrKCRG3Vmvfg+TuobWD+4AIcMV0JWG3HpbLqDKSfsYtQ=
X-Gm-Gg: ASbGncs3jpClnzto3P6vBys9IOW1ucjbncEqDC5BMnZc2xQkRT7HvHLK2LjEupDXVEe
	okMnRuUXun/SvjEmXen5Wd20D/b976RlEJMiqxc3me5RgJsHc2PiFDR/okM79IKzx5nQeYtf3Lg
	H2261ZPZ0JHFpZZjAyBucy4+IrqTZMKbxlHEFviAz2cdP481WBYuHzLAcH3gRM3cgBmy8U1tWU0
	bNIDk8TGi01fwhOrguyRA66RsHA0tRj05T72Em6N4G9s8XwU3JMvRdjs2ERIluWfhE=
X-Google-Smtp-Source: AGHT+IFZa6YHfCObxFOYVv5kgwUF45zHoMeT9mAi3f5Yfj2yIwSp9zJCVEB9YSHQKv5XvN/0IEDNAQ==
X-Received: by 2002:a5d:6c63:0:b0:385:f9db:3c4c with SMTP id ffacd0b85a97d-38787685894mr1268136f8f.9.1733966343352;
        Wed, 11 Dec 2024 17:19:03 -0800 (PST)
Message-ID: <8243acee-5414-4a97-bf8c-b9667eaf2234@citrix.com>
Date: Thu, 12 Dec 2024 01:19:01 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/3] Add stack protector
From: Andrew Cooper 
To: Volodymyr Babchuk ,
 Jan Beulich 
Cc: Julien Grall , Stefano Stabellini
 , Anthony PERARD ,
 Samuel Thibault ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Bertrand Marquis ,
 Michal Orzel ,
 "xen-devel@lists.xenproject.org" 
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
  <87pllx3gib.fsf@epam.com>
 
Content-Language: en-GB
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12/12/2024 1:17 am, Andrew Cooper wrote:
> On 12/12/2024 12:13 am, Volodymyr Babchuk wrote:
>> Hello Jan,
>>
>> Jan Beulich  writes:
>>
>>> On 11.12.2024 03:04, Volodymyr Babchuk wrote:
>>>> Both GCC and Clang support -fstack-protector feature, which add stack
>>>> canaries to functions where stack corruption is possible. This series
>>>> makes possible to use this feature in Xen. I tested this on ARM64 and
>>>> it is working as intended. Tested both with GCC and Clang.
>>>>
>>>> It is hard to enable this feature on x86, as GCC stores stack canary
>>>> in %fs:40 by default, but Xen can't use %fs for various reasons. It is
>>>> possibly to change stack canary location new newer GCC versions, but
>>>> this will change minimal GCC requirement, which is also hard due to
>>>> various reasons. So, this series focus mostly on ARM and RISCV.
>>> Why exactly would it not be possible to offer the feature when new enough
>>> gcc is in use?
>> It is possible to use this feature with a modern enough GCC, yes. Are
>> you suggesting to make HAS_STACK_PROTECTOR dependent on GCC_VERSION for
>> x86 platform?
> (With the knowledge that this is a disputed Kconfig pattern, and will
> need rebasing), the way I want this to work is simply:
>
> diff --git a/xen/Makefile b/xen/Makefile
> index 0de0101fd0bf..5d0a88fb3c3f 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -434,6 +434,9 @@ endif
>  
>  ifeq ($(CONFIG_STACK_PROTECTOR),y)
>  CFLAGS += -fstack-protector
> +ifeq ($(CONFIG_X86),y)
> +CFLAGS += -mstack-protector-guard=global
> +endif
>  else
>  CFLAGS += -fno-stack-protector
>  endif
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 9cdd04721afa..7951ca908b36 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -28,6 +28,7 @@ config X86
>         select HAS_PCI_MSI
>         select HAS_PIRQ
>         select HAS_SCHED_GRANULARITY
> +       select HAS_STACK_PROTECTOR if
> $(cc-option,-mstack-protector-guard=global)
>         select HAS_UBSAN
>         select HAS_VMAP
>         select HAS_VPCI if HVM
>
>
>
> Sadly, it doesn't build.  I get a handful of:
>
> prelink.o: in function `cmdline_parse':
> /home/andrew/xen.git/xen/common/kernel.c:216:(.init.text+0x20f2): failed
> to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
> --no-relax
> /home/andrew/xen.git/xen/common/kernel.c:230:(.init.text+0x246f): failed
> to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
> --no-relax
>
> which is more toolchain-whispering than I feel like doing tonight.

P.S.  Irrespective of the x86 side of things, you need a final patch on
your series adjusting CHANGELOG.md.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 02:28:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 02:28:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855482.1268377 (Exim 4.92)
	(envelope-from )
	id 1tLYva-0008WP-4w; Thu, 12 Dec 2024 02:27:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855482.1268377; Thu, 12 Dec 2024 02:27:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLYva-0008WI-2R; Thu, 12 Dec 2024 02:27:46 +0000
Received: by outflank-mailman (input) for mailman id 855482;
 Thu, 12 Dec 2024 02:27: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 1tLYvY-0008WC-GT
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 02:27:44 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a9adfab4-b830-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 03:27:42 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 7A5F85C6874;
 Thu, 12 Dec 2024 02:26:58 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 56DFCC4CED2;
 Thu, 12 Dec 2024 02:27: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: a9adfab4-b830-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1733970460;
	bh=Sn2MqdtLFyzeJw8pL4qtS/NeuKLuVvVft1TCzYNDnmA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Ch6rebkayVJ8g7jfy0N/IWIY/GPHk9QlCzr/yYcmKs0joiKiyrXxWBsFDHUQTqKda
	 3mrUE+MLKt9B28okK5Vw4LO2ia6FQYhxOLhQjgcQUr4XhkgVqPQvdpQCtFh62GYQve
	 rSQexM0CU/4xKXJ4u8bjpXI6u3VDxO5UV7EbPquGH1KDH1XT9UMnMwgc037Ngr9BF5
	 yiXmG9kKfxb8EmfvFyfmnYaEJMNza5nuCinOyicn7S/ysyEvWRHjYx9YuY19ywKr3i
	 e3Q0Jl3o8HuWIuacHo+9EjVOoybHaW2n2yX+zcSyh/NVW1E+UGfSH47toCa2of4c3h
	 sIcpH1SuAFC1Q==
Date: Wed, 11 Dec 2024 18:27:37 -0800 (PST)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Alessandro Zucchelli , 
    consulting@bugseng.com, Stefano Stabellini , 
    Julien Grall , Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen: address violation of MISRA C Rule 11.1
In-Reply-To: 
Message-ID: 
References: <7debd63f3900bad62bcbcc03081e4c04e6099135.1733914487.git.alessandro.zucchelli@bugseng.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 11 Dec 2024, Jan Beulich wrote:
> On 11.12.2024 12:02, Alessandro Zucchelli wrote:
> > Rule 11.1 states as following: "Conversions shall not be performed
> > between a pointer to a function and any other type".
> > 
> > Functions "__machine_restart" and "__machine_halt" in "x86/shutdown.c"
> > and "halt_this_cpu" in "arm/shutdown.c" are defined as noreturn
> > functions and subsequently passed as parameters to function calls.
> > This violates the rule in Clang, where the "noreturn" attribute is
> > considered part of the function"s type.
> 
> I'm unaware of build issues with Clang, hence can you clarify how Clang's
> view comes into play here? In principle various attributes ought to be
> part of a function's type; iirc that's also the case for gcc. Yet how
> that matters to Eclair is still entirely unclear to me.
> 
> > By removing the "noreturn"
> > attribbute and replacing it with uses of the ASSERT_UNREACHABLE macro,
> > these violations are addressed.
> 
> Papered over, I'd say. What about release builds, for example?
> 
> Deleting the attribute also has a clear downside documentation-wise. If
> we really mean to remove them from what the compiler gets to see, I think
> we ought to still retain them in commented-out shape.

Another option would be to #define noreturn to nothing for ECLAIR builds ?


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 02:29:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 02:29:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855495.1268387 (Exim 4.92)
	(envelope-from )
	id 1tLYxD-0000h2-Jh; Thu, 12 Dec 2024 02:29:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855495.1268387; Thu, 12 Dec 2024 02:29:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLYxD-0000gv-Gm; Thu, 12 Dec 2024 02:29:27 +0000
Received: by outflank-mailman (input) for mailman id 855495;
 Thu, 12 Dec 2024 02:29: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 1tLYxB-0000gn-JR
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 02:29:25 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e5e921de-b830-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 03:29:23 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id E68695C6685;
 Thu, 12 Dec 2024 02:28:39 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2DD19C4CED2;
 Thu, 12 Dec 2024 02:29: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: e5e921de-b830-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1733970562;
	bh=lDhRmp9g2oCOJzyqjm6wcG7LDvG5iuQjKJtnqq5pl4g=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=ge5GJs4/jvk22PZeEBjisoiyXdiT6EsbnXgLI2rOpHXsyOwX6bVFs01dfhAcluIdD
	 I0mdUPYAz0ITWcHLrVT8pLT5q8xLkbFqM17p12lf++wIlkcmYftOTNtv6DczcA0rT+
	 49B3vAfnzFJDzkG8AufLxNL0c3c+CJeLTEfMguqECdEiNExqsMQicukKQZWpnRlB3I
	 PGZFmi4/XjmJzxu7TCituvi7COVSqTbTIeegsdUZ+1Be+6tQYuM7lQIlMvteAdFccE
	 t+xZFXJ0HlSDDN3L+n/2TEsUUFa21DKKTK564jfZVVOc31lq+sLF70fYO0/8k5OjQK
	 3MsQqU+yOirSw==
Date: Wed, 11 Dec 2024 18:29:19 -0800 (PST)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Alessandro Zucchelli , 
    consulting@bugseng.com, Andrew Cooper , 
    Julien Grall , Stefano Stabellini , 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH] misra: add deviation for MISRA C Rule R11.1.
In-Reply-To: 
Message-ID: 
References: <8db58416ce215a3c5fdba8074dc21f32116e8a41.1733915076.git.alessandro.zucchelli@bugseng.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Wed, 11 Dec 2024, Jan Beulich wrote:
> On 11.12.2024 12:05, Alessandro Zucchelli wrote:
> > Rule 11.1 states as following: "Conversions shall not be performed
> > between a pointer to a function and any other type".
> > 
> > In "xen/common/bug.c", in order to get additional debug information,
> > pointer "bug_fn_t *fn" in the data section is converted to a function
> > pointer, which is then used to get such information.
> 
> If the pointer converted pointed into the data section, it would fault
> upon being used to call what it points to, for the lack of execute
> permissions there.
> 
> The change itself looks okay to me, but the description imo needs
> updating, to be as precise as possible.


What about:

In "xen/common/bug.c", in order to get additional debug information,
pointer "bug_fn_t *fn" is converted to a function pointer, which is then
used to get such information.

?


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 07:43:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 07:43:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855524.1268399 (Exim 4.92)
	(envelope-from )
	id 1tLdrD-0007RT-Kk; Thu, 12 Dec 2024 07:43:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855524.1268399; Thu, 12 Dec 2024 07:43:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLdrD-0007RM-Fp; Thu, 12 Dec 2024 07:43:35 +0000
Received: by outflank-mailman (input) for mailman id 855524;
 Thu, 12 Dec 2024 07:43: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 1tLdrC-0007RG-AR
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 07:43:34 +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 c95fb51a-b85c-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 08:43:33 +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 EEC7A210F4;
 Thu, 12 Dec 2024 07:43:31 +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 4F9FD13508;
 Thu, 12 Dec 2024 07:43:31 +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 qxHuESOUWmfYbAAAD6G6ig
 (envelope-from ); Thu, 12 Dec 2024 07:43: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: c95fb51a-b85c-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1733989412; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=eQb9M3J4JrPlPfisqjk4yxpyO+3HjWmcIFpGgd4fxtc=;
	b=nFc5Pe8tA8WUdjVlGn3G567JI1jWpBZRpG52eWaH/OW93W9SG2BTQ6D2A5M8aD7H5ax+Nt
	ywVrehPlJlL7j/9jjCCsij9X3S+wS6mannZCgPBsOmvsfDmzwiVWDJpWWGQjezGVXv2qN0
	3Y77Wq1oFLHrUjeldr57bK6fgA0zgJE=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=K9GnkQpk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1733989411; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=eQb9M3J4JrPlPfisqjk4yxpyO+3HjWmcIFpGgd4fxtc=;
	b=K9GnkQpkWDlhA2aSJ9be+bTGb9Ch3e9dhWN0Pdcplg1yZoLkaYiQyhiUcOxPI0B756roxG
	JgMJYLqj0LZWnHyHhDkwbMEgDO0T/qcnOqXSUPI07oBCRvUQlkd9MEVK/2gm0rg3H6SbjQ
	jwjAimMs0DCA9+F6gxSqiyGqhDHdLyA=
Message-ID: <1b557096-6527-4aea-a8c2-d72ecf0a31e8@suse.com>
Date: Thu, 12 Dec 2024 08:43:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/3] virtgpu: check if P2P is possiable or not
To: Julia Zhang , David Airlie ,
 Gerd Hoffmann ,
 Gurchetan Singh , Chia-I Wu
 , dri-devel@lists.freedesktop.org,
 virtualization@lists.linux-foundation.org,
 Stefano Stabellini ,
 Oleksandr Tyshchenko ,
 xen-devel@lists.xenproject.org
Cc: Alex Deucher ,
 =?UTF-8?Q?Christian_K=C3=B6nig?= ,
 Daniel Vetter , Chen Jiqian ,
 Huang Rui , Penny Zheng ,
 Zhu Lingshan ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Jan Beulich , Paul Durrant 
References: <20241207105023.542399-1-julia.zhang@amd.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: <20241207105023.542399-1-julia.zhang@amd.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------FORJHIzhj36aBxYHJVPo4KVg"
X-Rspamd-Queue-Id: EEC7A210F4
X-Spam-Score: -5.41
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-5.41 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SIGNED_PGP(-2.00)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MIME_BASE64_TEXT(0.10)[];
	MX_GOOD(-0.01)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FREEMAIL_TO(0.00)[amd.com,redhat.com,chromium.org,gmail.com,lists.freedesktop.org,lists.linux-foundation.org,kernel.org,epam.com,lists.xenproject.org];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCPT_COUNT_TWELVE(0.00)[21];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	FREEMAIL_ENVRCPT(0.00)[gmail.com];
	RCVD_TLS_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:dkim,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo]
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spam-Level: 

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------FORJHIzhj36aBxYHJVPo4KVg
Content-Type: multipart/mixed; boundary="------------lJn20Kef0EmCQeBJ5lwj106a";
 protected-headers="v1"
From: Juergen Gross 
To: Julia Zhang , David Airlie ,
 Gerd Hoffmann ,
 Gurchetan Singh , Chia-I Wu
 , dri-devel@lists.freedesktop.org,
 virtualization@lists.linux-foundation.org,
 Stefano Stabellini ,
 Oleksandr Tyshchenko ,
 xen-devel@lists.xenproject.org
Cc: Alex Deucher ,
 =?UTF-8?Q?Christian_K=C3=B6nig?= ,
 Daniel Vetter , Chen Jiqian ,
 Huang Rui , Penny Zheng ,
 Zhu Lingshan ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Jan Beulich , Paul Durrant 
Message-ID: <1b557096-6527-4aea-a8c2-d72ecf0a31e8@suse.com>
Subject: Re: [PATCH 0/3] virtgpu: check if P2P is possiable or not
References: <20241207105023.542399-1-julia.zhang@amd.com>
In-Reply-To: <20241207105023.542399-1-julia.zhang@amd.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------lJn20Kef0EmCQeBJ5lwj106a
Content-Type: multipart/mixed; boundary="------------vDc3tXiv0Jc0gS4fx4LN4O6V"

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

T24gMDcuMTIuMjQgMTE6NTAsIEp1bGlhIFpoYW5nIHdyb3RlOg0KPiBUbyBpbXBsZW1lbnQg
ZEdQVSBwcmltZSBmZWF0dXJlLCB2aXJ0Z3B1IG5lZWRzIHRvIGltcG9ydC9leHBvcnQgYnVm
ZmVyDQo+IGJldHdlZW4gdmlydGlvIGlHUFUgYW5kIHBhc3N0aHJvdWdoIGRHUFUuIEJlZm9y
ZSB0aGF0LCB2aXJ0Z3B1IHNob3VsZA0KPiBjaGVjayBpZiBQMlAgaXMgcG9zc2libGUgb3Ig
bm90LiBCdXQgY2FsbGluZyBmdW5jdGlvbiBwY2lfcDJwZG1hX2Rpc3RhbmNlDQo+IGluIGd1
ZXN0IFZNIHdpbGwgb25seSBnZXQgdmlydHVhbCBwMnBkbWFfZGlzdGFuY2UgaW5zdGVhZCBv
ZiByZWFsIHBoeXNpY2FsDQo+IHAycGRtYV9kaXN0YW5jZS4NCj4gICANCj4gU28gdGhpcyBz
ZXJpZXMgaW50cm9kdWNlIGFuIGltcGxlbWVudGF0aW9uIG9mIHZpcnRncHUgZGV2aWNlX2F0
dGFjaA0KPiBjYWxsYmFjayB0byBnZXQgcDJwZG1hX2Rpc3RhbmNlLiBBbmQgYWxzbyBhZGRz
IGEgbmV3IHZpcnRncHUgY29tbWFuZCB0bw0KPiBwYXNzIFBDSSBub3RhdGlvbnMgZnJvbSBn
dWVzdCB0byBob3N0IGFuZCBhIG5ldyB4ZW4gcHJpdmNtZCB0byBnZXQgcGh5c2ljYWwNCj4g
cDJwZG1hX2Rpc3RhbmNlIGFjY29yZGluZyB0byB0aGUgUENJIG5vdGF0aW9ucyBpbiBob3N0
Lg0KDQpJdCBpcyBoYXJkIHRvIHJldmlldyB0aGlzIHNlcmllcyB3aXRob3V0IGhhdmluZyBh
IGNsZWFyIHBpY3R1cmUgaG93DQp0aGlzIGFsbCBpcyBjb21pbmcgdG9nZXRoZXIuDQoNCkkg
Z3Vlc3MgdGhlIHZpcnRncHUgZnJvbnRlbmQgd2lsbCBzZW5kIGEgcDJwZG1hX2Rpc3RhbmNl
IHJlcXVlc3QgdG8NCnRoZSBiYWNrZW5kLCB3aGljaCBpcyBydW5uaW5nIGluIHVzZXIgbW9k
ZSBvZiBkb20wLiBUaGlzIGJhY2tlbmQgd2lsbA0KdGhlbiBjYWxsIGludG8gdGhlIHByaXZj
bWQgZHJpdmVyIHRvIG9idGFpbiB0aGUgbmVlZGVkIGluZm9ybWF0aW9uIGFuZA0Kc2VuZHMg
aXQgYmFjayB0byB0aGUgZnJvbnRlbmQuDQoNCkNhbiB5b3UgcGxlYXNlIGNvbmZpcm0gbXkg
c3VzcGljaW9uIGlzIGNvcnJlY3Q/DQoNCg0KSnVlcmdlbg0K
--------------vDc3tXiv0Jc0gS4fx4LN4O6V
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-----

--------------vDc3tXiv0Jc0gS4fx4LN4O6V--

--------------lJn20Kef0EmCQeBJ5lwj106a--

--------------FORJHIzhj36aBxYHJVPo4KVg
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/Ey8FAmdalCIFAwAAAAAACgkQsN6d1ii/Ey8N
iQf/fpPw/+amQAbgmNByT3LMIV97FgTh8OXjfnM6WH2D9tHqHzDkjMsTsf3dGuJH2Y1ZGhk2+9lp
nRSA5DMwJ0ew94xJGNvcKrURfucWpj7jFQNOLV9S0yLfMtaIxAIh7Q6K/YkXsjf0feYe2msAPc6j
paLxDFuW8KatUcD8upTK3li0hJULnQecGWqCBXu/JN/yffernuIrJ7pjQJXVyz4cQg2Sx3Pqq1+R
St/4PNP6Zx1CRIhgre42HfcC5LtUaknuJ+JdRy5Nhqif5sPyYhpJC5uEAs2VSPCPZRorklNOYtpT
Hbq/jJD8wbu5O4ZO2puFpU7VjJgj2krW+vMawLIgzg==
=X6gv
-----END PGP SIGNATURE-----

--------------FORJHIzhj36aBxYHJVPo4KVg--


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 08:34:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 08:34:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855542.1268408 (Exim 4.92)
	(envelope-from )
	id 1tLee9-0001Mu-DW; Thu, 12 Dec 2024 08:34:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855542.1268408; Thu, 12 Dec 2024 08:34:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLee9-0001Mn-AR; Thu, 12 Dec 2024 08:34:09 +0000
Received: by outflank-mailman (input) for mailman id 855542;
 Thu, 12 Dec 2024 08:34: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 1tLee7-0001Mh-JA
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 08:34:07 +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 d8e66392-b863-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 09:34: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-out1.suse.de (Postfix) with ESMTPS id A450E21120;
 Thu, 12 Dec 2024 08:34: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 3EF2513508;
 Thu, 12 Dec 2024 08:34: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 UvNnDfyfWmfhewAAD6G6ig
 (envelope-from ); Thu, 12 Dec 2024 08:34: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: d8e66392-b863-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1733992444; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=tmKmAkW6sky1KrqIET/0hTlrU0aJrqhTHuOrrPeQhZY=;
	b=qG/7zovhFMnyzH9U9uaTBWObmvkOXJBWIfZ4xFizcoOSdv+K9VXsFGVFQVJID6OrNRtupx
	tPF1Z5Kg+MKxtOXgF3n/ydc/CZ9oQYbhLQ9fKsU7E/f1wkkO6NTkENqOnM9ZFHPCtcK1vQ
	UQTNj9TSYsWOzAlA4KMXiX0YDscZJ00=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b="qG/7zovh"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1733992444; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=tmKmAkW6sky1KrqIET/0hTlrU0aJrqhTHuOrrPeQhZY=;
	b=qG/7zovhFMnyzH9U9uaTBWObmvkOXJBWIfZ4xFizcoOSdv+K9VXsFGVFQVJID6OrNRtupx
	tPF1Z5Kg+MKxtOXgF3n/ydc/CZ9oQYbhLQ9fKsU7E/f1wkkO6NTkENqOnM9ZFHPCtcK1vQ
	UQTNj9TSYsWOzAlA4KMXiX0YDscZJ00=
Message-ID: <138422c8-36a8-4ed0-b8b8-c1085c9f22e6@suse.com>
Date: Thu, 12 Dec 2024 09:34:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] Grab mm lock before grabbing pt lock
To: Maksym Planeta ,
 Boris Ostrovsky ,
 Thomas Gleixner , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 x86@kernel.org, "H. Peter Anvin" 
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
References: <20241204103516.3309112-1-maksym@exostellar.io>
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: <20241204103516.3309112-1-maksym@exostellar.io>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------3TvqW7IvbKy70kZij6m81HGa"
X-Rspamd-Queue-Id: A450E21120
X-Spam-Level: 
X-Spamd-Result: default: False [-5.41 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SIGNED_PGP(-2.00)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_BASE64_TEXT(0.10)[];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MX_GOOD(-0.01)[];
	FROM_HAS_DN(0.00)[];
	RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	TO_DN_SOME(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[10];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	DKIM_TRACE(0.00)[suse.com:+];
	ASN(0.00)[asn:25478, ipnet:::/0, country:RU];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:dkim,suse.com:mid,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -5.41
X-Spam-Flag: NO

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------3TvqW7IvbKy70kZij6m81HGa
Content-Type: multipart/mixed; boundary="------------mdV24wtmxeUldecw03mORDd4";
 protected-headers="v1"
From: Juergen Gross 
To: Maksym Planeta ,
 Boris Ostrovsky ,
 Thomas Gleixner , Ingo Molnar ,
 Borislav Petkov , Dave Hansen ,
 x86@kernel.org, "H. Peter Anvin" 
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Message-ID: <138422c8-36a8-4ed0-b8b8-c1085c9f22e6@suse.com>
Subject: Re: [PATCH] Grab mm lock before grabbing pt lock
References: <20241204103516.3309112-1-maksym@exostellar.io>
In-Reply-To: <20241204103516.3309112-1-maksym@exostellar.io>

--------------mdV24wtmxeUldecw03mORDd4
Content-Type: multipart/mixed; boundary="------------hPf6TyNP2uLKBoEnbFa4w0x1"

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

T24gMDQuMTIuMjQgMTE6MzUsIE1ha3N5bSBQbGFuZXRhIHdyb3RlOg0KPiBGdW5jdGlvbiB4
ZW5fcGluX3BhZ2UgY2FsbHMgeGVuX3B0ZV9sb2NrLCB3aGljaCBpbiB0dXJuIGdyYWIgcGFn
ZQ0KPiB0YWJsZSBsb2NrIChwdGxvY2spLiBXaGVuIGxvY2tpbmcsIHhlbl9wdGVfbG9jayBl
eHBlY3QgbW0tPnBhZ2VfdGFibGVfbG9jaw0KPiB0byBiZSBoZWxkIGJlZm9yZSBncmFiYmlu
ZyBwdGxvY2ssIGJ1dCB0aGlzIGRvZXMgbm90IGhhcHBlbiB3aGVuIHBpbm5pbmcNCj4gaXMg
Y2F1c2VkIGJ5IHhlbl9tbV9waW5fYWxsLg0KPiANCj4gVGhpcyBjb21taXQgYWRkcmVzc2Vz
IGxvY2tkZXAgd2FybmluZyBiZWxvdywgd2hpY2ggc2hvd3MgdXAgd2hlbg0KPiBzdXNwZW5k
aW5nIGEgWGVuIFZNLg0KPiANCj4gWyAzNjgwLjY1ODQyMl0gRnJlZXppbmcgdXNlciBzcGFj
ZSBwcm9jZXNzZXMNCj4gWyAzNjgwLjY2MDE1Nl0gRnJlZXppbmcgdXNlciBzcGFjZSBwcm9j
ZXNzZXMgY29tcGxldGVkIChlbGFwc2VkIDAuMDAxIHNlY29uZHMpDQo+IFsgMzY4MC42NjAx
ODJdIE9PTSBraWxsZXIgZGlzYWJsZWQuDQo+IFsgMzY4MC42NjAxOTJdIEZyZWV6aW5nIHJl
bWFpbmluZyBmcmVlemFibGUgdGFza3MNCj4gWyAzNjgwLjY2MTQ4NV0gRnJlZXppbmcgcmVt
YWluaW5nIGZyZWV6YWJsZSB0YXNrcyBjb21wbGV0ZWQgKGVsYXBzZWQgMC4wMDEgc2Vjb25k
cykNCj4gWyAzNjgwLjY4NTI1NF0NCj4gWyAzNjgwLjY4NTI2NV0gPT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PQ0KPiBbIDM2ODAuNjg1MjY5XSBXQVJOSU5HOiBOZXN0ZWQg
bG9jayB3YXMgbm90IHRha2VuDQo+IFsgMzY4MC42ODUyNzRdIDYuMTIuMCsgIzE2IFRhaW50
ZWQ6IEcgICAgICAgIFcNCj4gWyAzNjgwLjY4NTI3OV0gLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQ0KPiBbIDM2ODAuNjg1MjgzXSBtaWdyYXRpb24vMC8xOSBpcyB0cnlp
bmcgdG8gbG9jazoNCj4gWyAzNjgwLjY4NTI4OF0gZmZmZjg4ODAwYmFjMzNjMCAocHRsb2Nr
X3B0cihwdGRlc2MpIzIpeysuKy59LXszOjN9LCBhdDogeGVuX3Bpbl9wYWdlKzB4MTc1LzB4
MWQwDQo+IFsgMzY4MC42ODUzMDNdDQo+IFsgMzY4MC42ODUzMDNdIGJ1dCB0aGlzIHRhc2sg
aXMgbm90IGhvbGRpbmc6DQo+IFsgMzY4MC42ODUzMDhdIGluaXRfbW0ucGFnZV90YWJsZV9s
b2NrDQo+IFsgMzY4MC42ODUzMTFdDQo+IFsgMzY4MC42ODUzMTFdIHN0YWNrIGJhY2t0cmFj
ZToNCj4gWyAzNjgwLjY4NTMxNl0gQ1BVOiAwIFVJRDogMCBQSUQ6IDE5IENvbW06IG1pZ3Jh
dGlvbi8wIFRhaW50ZWQ6IEcgICAgICAgIFcgICAgICAgICAgNi4xMi4wKyAjMTYNCj4gWyAz
NjgwLjY4NTMyNF0gVGFpbnRlZDogW1ddPVdBUk4NCj4gWyAzNjgwLjY4NTMyOF0gU3RvcHBl
cjogbXVsdGlfY3B1X3N0b3ArMHgwLzB4MTIwIDwtIF9fc3RvcF9jcHVzLmNvbnN0cHJvcC4w
KzB4OGMvMHhkMA0KPiBbIDM2ODAuNjg1MzM5XSBDYWxsIFRyYWNlOg0KPiBbIDM2ODAuNjg1
MzQ0XSAgPFRBU0s+DQo+IFsgMzY4MC42ODUzNDddICBkdW1wX3N0YWNrX2x2bCsweDc3LzB4
YjANCj4gWyAzNjgwLjY4NTM1Nl0gIF9fbG9ja19hY3F1aXJlKzB4OTE3LzB4MjMxMA0KPiBb
IDM2ODAuNjg1MzY0XSAgbG9ja19hY3F1aXJlKzB4Y2UvMHgyYzANCj4gWyAzNjgwLjY4NTM2
OV0gID8geGVuX3Bpbl9wYWdlKzB4MTc1LzB4MWQwDQo+IFsgMzY4MC42ODUzNzNdICBfcmF3
X3NwaW5fbG9ja19uZXN0X2xvY2srMHgyZi8weDcwDQo+IFsgMzY4MC42ODUzODFdICA/IHhl
bl9waW5fcGFnZSsweDE3NS8weDFkMA0KPiBbIDM2ODAuNjg1Mzg2XSAgeGVuX3Bpbl9wYWdl
KzB4MTc1LzB4MWQwDQo+IFsgMzY4MC42ODUzOTBdICA/IF9fcGZ4X3hlbl9waW5fcGFnZSsw
eDEwLzB4MTANCj4gWyAzNjgwLjY4NTM5NF0gIF9feGVuX3BnZF93YWxrKzB4MjMzLzB4MmMw
DQo+IFsgMzY4MC42ODU0MDFdICA/IHN0b3Bfb25lX2NwdSsweDkxLzB4MTAwDQo+IFsgMzY4
MC42ODU0MDVdICBfX3hlbl9wZ2RfcGluKzB4NWQvMHgyNTANCj4gWyAzNjgwLjY4NTQxMF0g
IHhlbl9tbV9waW5fYWxsKzB4NzAvMHhhMA0KPiBbIDM2ODAuNjg1NDE1XSAgeGVuX3B2X3By
ZV9zdXNwZW5kKzB4Zi8weDI4MA0KPiBbIDM2ODAuNjg1NDIwXSAgeGVuX3N1c3BlbmQrMHg1
Ny8weDFhMA0KPiBbIDM2ODAuNjg1NDI4XSAgbXVsdGlfY3B1X3N0b3ArMHg2Yi8weDEyMA0K
PiBbIDM2ODAuNjg1NDMyXSAgPyB1cGRhdGVfY3B1bWFza3NfaGllcisweDdjLzB4YTYwDQo+
IFsgMzY4MC42ODU0MzldICA/IF9fcGZ4X211bHRpX2NwdV9zdG9wKzB4MTAvMHgxMA0KPiBb
IDM2ODAuNjg1NDQzXSAgY3B1X3N0b3BwZXJfdGhyZWFkKzB4OGMvMHgxNDANCj4gWyAzNjgw
LjY4NTQ0OF0gID8gc21wYm9vdF90aHJlYWRfZm4rMHgyMC8weDFmMA0KPiBbIDM2ODAuNjg1
NDU0XSAgPyBfX3BmeF9zbXBib290X3RocmVhZF9mbisweDEwLzB4MTANCj4gWyAzNjgwLjY4
NTQ1OF0gIHNtcGJvb3RfdGhyZWFkX2ZuKzB4ZWQvMHgxZjANCj4gWyAzNjgwLjY4NTQ2Ml0g
IGt0aHJlYWQrMHhkZS8weDExMA0KPiBbIDM2ODAuNjg1NDY3XSAgPyBfX3BmeF9rdGhyZWFk
KzB4MTAvMHgxMA0KPiBbIDM2ODAuNjg1NDcxXSAgcmV0X2Zyb21fZm9yaysweDJmLzB4NTAN
Cj4gWyAzNjgwLjY4NTQ3OF0gID8gX19wZnhfa3RocmVhZCsweDEwLzB4MTANCj4gWyAzNjgw
LjY4NTQ4Ml0gIHJldF9mcm9tX2ZvcmtfYXNtKzB4MWEvMHgzMA0KPiBbIDM2ODAuNjg1NDg5
XSAgPC9UQVNLPg0KPiBbIDM2ODAuNjg1NDkxXQ0KPiBbIDM2ODAuNjg1NDkxXSBvdGhlciBp
bmZvIHRoYXQgbWlnaHQgaGVscCB1cyBkZWJ1ZyB0aGlzOg0KPiBbIDM2ODAuNjg1NDk3XSAx
IGxvY2sgaGVsZCBieSBtaWdyYXRpb24vMC8xOToNCj4gWyAzNjgwLjY4NTUwMF0gICMwOiBm
ZmZmZmZmZjgyODRkZjM4IChwZ2RfbG9jayl7Ky4rLn0tezM6M30sIGF0OiB4ZW5fbW1fcGlu
X2FsbCsweDE0LzB4YTANCj4gWyAzNjgwLjY4NTUxMl0NCj4gWyAzNjgwLjY4NTUxMl0gc3Rh
Y2sgYmFja3RyYWNlOg0KPiBbIDM2ODAuNjg1NTE4XSBDUFU6IDAgVUlEOiAwIFBJRDogMTkg
Q29tbTogbWlncmF0aW9uLzAgVGFpbnRlZDogRyAgICAgICAgVyAgICAgICAgICA2LjEyLjAr
ICMxNg0KPiBbIDM2ODAuNjg1NTI4XSBUYWludGVkOiBbV109V0FSTg0KPiBbIDM2ODAuNjg1
NTMxXSBTdG9wcGVyOiBtdWx0aV9jcHVfc3RvcCsweDAvMHgxMjAgPC0gX19zdG9wX2NwdXMu
Y29uc3Rwcm9wLjArMHg4Yy8weGQwDQo+IFsgMzY4MC42ODU1MzhdIENhbGwgVHJhY2U6DQo+
IFsgMzY4MC42ODU1NDFdICA8VEFTSz4NCj4gWyAzNjgwLjY4NTU0NF0gIGR1bXBfc3RhY2tf
bHZsKzB4NzcvMHhiMA0KPiBbIDM2ODAuNjg1NTQ5XSAgX19sb2NrX2FjcXVpcmUrMHg5M2Mv
MHgyMzEwDQo+IFsgMzY4MC42ODU1NTRdICBsb2NrX2FjcXVpcmUrMHhjZS8weDJjMA0KPiBb
IDM2ODAuNjg1NTU4XSAgPyB4ZW5fcGluX3BhZ2UrMHgxNzUvMHgxZDANCj4gWyAzNjgwLjY4
NTU2Ml0gIF9yYXdfc3Bpbl9sb2NrX25lc3RfbG9jaysweDJmLzB4NzANCj4gWyAzNjgwLjY4
NTU2OF0gID8geGVuX3Bpbl9wYWdlKzB4MTc1LzB4MWQwDQo+IFsgMzY4MC42ODU1NzJdICB4
ZW5fcGluX3BhZ2UrMHgxNzUvMHgxZDANCj4gWyAzNjgwLjY4NTU3OF0gID8gX19wZnhfeGVu
X3Bpbl9wYWdlKzB4MTAvMHgxMA0KPiBbIDM2ODAuNjg1NTgyXSAgX194ZW5fcGdkX3dhbGsr
MHgyMzMvMHgyYzANCj4gWyAzNjgwLjY4NTU4OF0gID8gc3RvcF9vbmVfY3B1KzB4OTEvMHgx
MDANCj4gWyAzNjgwLjY4NTU5Ml0gIF9feGVuX3BnZF9waW4rMHg1ZC8weDI1MA0KPiBbIDM2
ODAuNjg1NTk2XSAgeGVuX21tX3Bpbl9hbGwrMHg3MC8weGEwDQo+IFsgMzY4MC42ODU2MDBd
ICB4ZW5fcHZfcHJlX3N1c3BlbmQrMHhmLzB4MjgwDQo+IFsgMzY4MC42ODU2MDddICB4ZW5f
c3VzcGVuZCsweDU3LzB4MWEwDQo+IFsgMzY4MC42ODU2MTFdICBtdWx0aV9jcHVfc3RvcCsw
eDZiLzB4MTIwDQo+IFsgMzY4MC42ODU2MTVdICA/IHVwZGF0ZV9jcHVtYXNrc19oaWVyKzB4
N2MvMHhhNjANCj4gWyAzNjgwLjY4NTYyMF0gID8gX19wZnhfbXVsdGlfY3B1X3N0b3ArMHgx
MC8weDEwDQo+IFsgMzY4MC42ODU2MjVdICBjcHVfc3RvcHBlcl90aHJlYWQrMHg4Yy8weDE0
MA0KPiBbIDM2ODAuNjg1NjI5XSAgPyBzbXBib290X3RocmVhZF9mbisweDIwLzB4MWYwDQo+
IFsgMzY4MC42ODU2MzRdICA/IF9fcGZ4X3NtcGJvb3RfdGhyZWFkX2ZuKzB4MTAvMHgxMA0K
PiBbIDM2ODAuNjg1NjM4XSAgc21wYm9vdF90aHJlYWRfZm4rMHhlZC8weDFmMA0KPiBbIDM2
ODAuNjg1NjQyXSAga3RocmVhZCsweGRlLzB4MTEwDQo+IFsgMzY4MC42ODU2NDVdICA/IF9f
cGZ4X2t0aHJlYWQrMHgxMC8weDEwDQo+IFsgMzY4MC42ODU2NDldICByZXRfZnJvbV9mb3Jr
KzB4MmYvMHg1MA0KPiBbIDM2ODAuNjg1NjU0XSAgPyBfX3BmeF9rdGhyZWFkKzB4MTAvMHgx
MA0KPiBbIDM2ODAuNjg1NjU3XSAgcmV0X2Zyb21fZm9ya19hc20rMHgxYS8weDMwDQo+IFsg
MzY4MC42ODU2NjJdICA8L1RBU0s+DQo+IFsgMzY4MC42ODUyNjddIHhlbjpncmFudF90YWJs
ZTogR3JhbnQgdGFibGVzIHVzaW5nIHZlcnNpb24gMSBsYXlvdXQNCj4gWyAzNjgwLjY4NTky
MV0gT09NIGtpbGxlciBlbmFibGVkLg0KPiBbIDM2ODAuNjg1OTM0XSBSZXN0YXJ0aW5nIHRh
c2tzIC4uLiBkb25lLg0KPiANCj4gU2lnbmVkLW9mZi1ieTogTWFrc3ltIFBsYW5ldGEgPG1h
a3N5bUBleG9zdGVsbGFyLmlvPg0KDQpSZXZpZXdlZC1ieTogSnVlcmdlbiBHcm9zcyA8amdy
b3NzQHN1c2UuY29tPg0KDQoNCkp1ZXJnZW4NCg==
--------------hPf6TyNP2uLKBoEnbFa4w0x1
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-----

--------------hPf6TyNP2uLKBoEnbFa4w0x1--

--------------mdV24wtmxeUldecw03mORDd4--

--------------3TvqW7IvbKy70kZij6m81HGa
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/Ey8FAmdan/sFAwAAAAAACgkQsN6d1ii/Ey+8
EAgAkzb0QIFIiNL92O77yTHv48ee2qE6cR6q1/EWcIGOOPfaQ9Lcag46vdIBSBiIAHnfx7IoVb/4
Bqtx3KRPooPzOW2fWXaKDaJrc+mRFvduliIPcDQbQH+lDsnW0i+RVulzAjhd8Mti9+3L1elwxcdV
mYMd4Nzk7oiBOoFj2E2eZYZ9SlLtM4xOyMdBfQ3UM9BOr9vJfeH0ghO6MxxmCh4cwl32MMMj+PAv
0J63AfaSM0RN192rEFOs7kTouH+i04s+ejIVHo4EhSIcbRWcdDzd0IagA5q6fHkq/c1VkmG9zGBp
rp6ef4tXOCRUOmav5GxoCdQ3sXndBbsauv5lp0tZFg==
=W1Kj
-----END PGP SIGNATURE-----

--------------3TvqW7IvbKy70kZij6m81HGa--


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 08:47:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 08:47:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855560.1268418 (Exim 4.92)
	(envelope-from )
	id 1tLeqU-0003v6-Kl; Thu, 12 Dec 2024 08:46:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855560.1268418; Thu, 12 Dec 2024 08:46: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 1tLeqU-0003uz-Hh; Thu, 12 Dec 2024 08:46:54 +0000
Received: by outflank-mailman (input) for mailman id 855560;
 Thu, 12 Dec 2024 08:46: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 1tLeqT-0003ur-GJ
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 08:46:53 +0000
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam04on20608.outbound.protection.outlook.com
 [2a01:111:f403:2409::608])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a04db2c5-b865-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 09:46:50 +0100 (CET)
Received: from MN2PR15CA0059.namprd15.prod.outlook.com (2603:10b6:208:237::28)
 by MN0PR12MB6224.namprd12.prod.outlook.com (2603:10b6:208:3c0::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.16; Thu, 12 Dec
 2024 08:46:45 +0000
Received: from BL6PEPF00020E64.namprd04.prod.outlook.com
 (2603:10b6:208:237:cafe::b3) by MN2PR15CA0059.outlook.office365.com
 (2603:10b6:208:237::28) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.16 via Frontend Transport; Thu,
 12 Dec 2024 08:46:45 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BL6PEPF00020E64.mail.protection.outlook.com (10.167.249.25) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Thu, 12 Dec 2024 08:46:45 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 12 Dec
 2024 02:46:44 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 12 Dec
 2024 02:46:44 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 12 Dec 2024 02:46: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: a04db2c5-b865-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=j2MwmssHVDexNZRCtHqFDtcmPqwzNTOyFmPD51mdbpiNbaELk91aHktMzXZoNhNh1z/eSSH5nOJKAiFVvCyvlcdodw1IFF7U/LZDadS4fGR+d0I+e9n23t/e653MDzto3VM2Yf5F+lXqBOfCMM2rEj8jzUaInfiLD85P2bKCzIxl1qvtnF64K7koNE0bz0HR3IuwyzBQrsL7uJVqJPho3tu3V4LrVA6d722braLA38MsFNVM5xKcUidFa8XCkmKTkwTAa3C+wYccg5vxWZOSZN7Z9cZergXXTLJSIpmrPd0knwXWActoV+VlxXmcrXPJgEMxxSBprksgzqGraNNsRw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=O9yoGP7yvMHXuM4AIFczLTZmyq3Qzgx8EZRBPMLyyhU=;
 b=pik9t/A44OIVJA7d7irOLs/Cl7NDyTBuQQeN5HdsIh2zvjHU5dMj03l4Nlp0k4f1udXC0Nst8ho6ySo298Gw+Ipk5d/tyvn3YL9sru6nQZRq4TDy0+M/E1ywR+N25NiFSlIt3r/uJquLAGeGAqtVAC8AnTcnMeIQ4J4Rbo2FUNa5Cdow0lyYqi1AF9FJkdKa/R2wMOQcmGiewcxkx6LWqDI+qvto7098ZmhsXysjfyF1EyibuZjvwEYfzvvcXPVrHzf5EKrUuxRtT74hTDZjoH0S9ZYF2EaWzvvwLN6N3V4QtWNvJRn+k+wCEVsuC2L2USvf88ecmiUaeoJpTQZEQQ==
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=O9yoGP7yvMHXuM4AIFczLTZmyq3Qzgx8EZRBPMLyyhU=;
 b=VBs1u87URZ1MnPpS3TdIUjmN1+Wy4txeaHvo3iHUyDl2FS8rOT7n6V+3O/P9WlxaTRppst65KQwbhmLzobGjoytrByZJkwwrdllyUO8rulVKzdJiEOlCuvN0NYHnnArvd5D/asLqudQiZcYOUt50dmm+QYVvXF30DEe4cF2Dah0=
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=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Thu, 12 Dec 2024 09:46:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] arm/domain_build: Make find_unallocated_memory() more
 generic
To: Julien Grall , 
CC: Stefano Stabellini , Bertrand Marquis
	, Volodymyr Babchuk 
References: <20241210101001.91578-1-michal.orzel@amd.com>
 
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF00020E64:EE_|MN0PR12MB6224:EE_
X-MS-Office365-Filtering-Correlation-Id: 6113cb88-88e5-4ab5-1578-08dd1a898212
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?VW0zSEZySzhZQUtDVW5SVTBiUFFwM2RjMHpXQmNXT2UrVTNjMDYzaDlpWG9m?=
 =?utf-8?B?UUhxSTNJWWNZL3FpOVlaN3Z0QUM5Z2Z5NXlGS3MrSmZWYTZMcGdXM05DdTl3?=
 =?utf-8?B?T2VSSnNLdkJuWVlrSHF2QVN4SDNsMjlUVGUwbndUTXZyeHc5alJZdlczMEJN?=
 =?utf-8?B?SCtEU0cwLys3NjhCc0tGMGh2SjBZeDBad0NlU3l3MmMwNDROUVkwTXQvMm9q?=
 =?utf-8?B?ZkxqQTNXcm9EVFgzNGNrNHk2MUw0RzJSMEZNSSs5RFRoT2F2VWVOY0JPdy9Q?=
 =?utf-8?B?NVZyaENiWXl4K2ZEMGlMcVZDOFIwNHRNaG5vcWRPcy8zYXBlamttNWdVa0NQ?=
 =?utf-8?B?eUtVNXhNTTBtSmFkbHRSL240dkZVbktjOHg4Uzl1N3Rmb1Z0aDRiRnk4dnBU?=
 =?utf-8?B?cmIvMnFqV3lCc1dOKzNvSHFNT1JIcHp5eEFBeVRxdlVsNkZFV0hNd2Z5eE4v?=
 =?utf-8?B?T1UvWlZQcWdBcExBd0IvYW1jamdaSzdzdndxREozNGg4UEUydVZQNTlENFov?=
 =?utf-8?B?cCtNa0ZqR1RiNGdBMi81bndOcWNFQXJjN2VCZ2pwR0RHcm95QlovZ0ozL25S?=
 =?utf-8?B?aEd2YjlHczVHRDJGT3dHWlMzMlMzNHljZnRVTXZIdTdMK3VxbnRWZ1J0dHBZ?=
 =?utf-8?B?YnNHU1BEWXBJMmJCWFNCUys4MEhTdS9scU5xVTVRUG5MUHlSbEV0MDRDWnJH?=
 =?utf-8?B?Z0pyclZHNEE3ZnFtMnhaR3lrSW5KQ0Exb2FoODJUbWgrMEFOU0VGZU9IV3dL?=
 =?utf-8?B?SHVlV043MDFUT01Dbld1UmlTTXFjT3pxSmE1UUlBcmNFZ3pyVXZrOXNDTGNG?=
 =?utf-8?B?UU9XV05zWGtnblBib2ZCbjZnYTJ0SFFJZnNNNTcrdHQzMk11dFFoMWdyTWU2?=
 =?utf-8?B?dXMvYzJpajNDNmpzOUwzdUtLTmhmL1RQbmJVWFlxalBXZ05XQ0p0MStyZTJn?=
 =?utf-8?B?U1ZIYk80Q3kvMzgxMXBrOEpmdlE5L3JYTFJ5YlBGbXJIVk9vYlIvUHVwOUhR?=
 =?utf-8?B?Y2JVcGxqSStTbzFCTXE4bGRLRDZQVnc3SG9BUDRBbHloem9hVE1FRUlRU2Rt?=
 =?utf-8?B?ekVEV2ZYQlROeUQyZVFvUVZIaExBL0U2MVJhL2syQzRGZmE5QWNBbVVya1Jp?=
 =?utf-8?B?OFhkN2lhMVc0U1lyMEROakk2Nm9mWlQ5bzNnUmtIS0FweTU4NGh3MnZJb2RY?=
 =?utf-8?B?NDVrSkwvVHFXR0l0c0NtQWhudkZTL0pjc3RBR1Mzd0JVSGE4VjRsUG91SXBW?=
 =?utf-8?B?c21keDhDOG1UcFVFVzhHQ3hzNXkwNVBlS0xLY3dQWWJKd09xZE1iQ3pmQmU1?=
 =?utf-8?B?SzdkNFc2WS9YN1ZLdlkvNVJEMkRka01pMVhHYU82SnZBY2xkWVRTMFRheW1R?=
 =?utf-8?B?YXVtWE5TdHVoY1JJUVpBV1B6S2ZUM0tycHhJNElYUzc1TEYzNHRVN3ZNY1pN?=
 =?utf-8?B?SnlGUzRIVkdManlhNXpIS3R5WG82V1BxTitHR2Q0TEtleGJQUERySS9SdWcw?=
 =?utf-8?B?UmRKTUx4VzI2dUxsWXNqWnBsT05BN1lmQWRmYm5oaTltekhYdGI3ODJWRFNK?=
 =?utf-8?B?Qi9VVHRMUDJXbDVseDduRmQveFJqdm14VGZMSlJ0NXhscHRXdnBQVzFQdTc3?=
 =?utf-8?B?YWdkcXQwSWJ3NDgwL2U3RGU2ZjdlTWVJdko2Rk4wOWhDdVJrKzAxc3hYNDl5?=
 =?utf-8?B?WlA2TEsxS3U5RFZZUFdUbmRIT0JCaVJzKzIrRERNNTRUbE9adzM4SUtZWXMz?=
 =?utf-8?B?djh0TzVDRFpXenNjVjBsaW93Q0pQZXBNT1pRcVJtMGRaM0NHcklTSGJJSWRl?=
 =?utf-8?B?ZXpvM21WNHcwY3RNTmJyQnplWlhWWGdMY2JlWWVHZGYzZ1pmb2pMeDVOZGg0?=
 =?utf-8?B?dWRZNmZwRmU0Lzh4bVp3ZG00S2djM3A3K0dDbUFOVmo2OGROa01CVHlpREtC?=
 =?utf-8?Q?BaxuV39z3GISrvc6trIx5wfTW/fmmNB9?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Dec 2024 08:46:45.0918
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6113cb88-88e5-4ab5-1578-08dd1a898212
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL6PEPF00020E64.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6224

Hi Julien,

On 11/12/2024 18:39, Julien Grall wrote:
> 
> 
> Hi Michal,
> 
> On 10/12/2024 10:10, Michal Orzel wrote:
>> At the moment, find_unallocated_memory() is only used to retrieve free
>> memory ranges for direct mapped domains in order to find extended
>> regions. It is not generic as it makes assumptions as for the place at
>> which it's being called (domain memory already allocated, gnttab region
>> already found) and hardcodes the memory banks to be excluded.
>>
>> Make the function more generic, so that it can be used for other
>> purposes whenever there is a need to find free host memory regions (e.g.
>> upcoming LLC coloring series). Allow passing array with memory banks as a
>> parameter together with a callback to populate free regions structure,
>> as the logic may differ depending on the needs.
>>
>> Add find_host_extended_regions() to be called from make_hypervisor_node()
>> to contain the logic to find extended regions for domains using host
>> memory layout that are not permitted to use IOMMU.
>>
>> Signed-off-by: Michal Orzel 
> 
> With one remark below:
> 
> Acked-by: Julien Grall 
> 
>> ---
>> This is a prerequisite patch for LLC coloring series patch 3.
>> For dom0 LLC coloring, we just need to pass resmem and gnttab in mem_banks.
>> ---
>>   xen/arch/arm/domain_build.c | 97 +++++++++++++++++++++----------------
>>   1 file changed, 55 insertions(+), 42 deletions(-)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 2c30792de88b..500005079b88 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -901,31 +901,26 @@ int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
>>   }
>>
>>   /*
>> - * Find unused regions of Host address space which can be exposed to Dom0
>> - * as extended regions for the special memory mappings. In order to calculate
>> - * regions we exclude every region assigned to Dom0 from the Host RAM:
>> - * - domain RAM
>> - * - reserved-memory
>> - * - static shared memory
>> - * - grant table space
>> + * Find unused regions of Host address space which can be exposed to domain
>> + * using the host memory layout (i.e. direct mapped or hardware domain). In
> 
> NIT: I would use "e.g." rather than "i.e." because in the future we may
> want to expose the host layout to a guest without necessarily having IPA
> == PA. You could also drop the part in () because one could find the
> definition on top of domain_use_host_layout().
I removed () on commit. Thanks.

~Michal



From xen-devel-bounces@lists.xenproject.org Thu Dec 12 08:58:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 08:58:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855573.1268432 (Exim 4.92)
	(envelope-from )
	id 1tLf1o-0006Xp-JT; Thu, 12 Dec 2024 08:58:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855573.1268432; Thu, 12 Dec 2024 08:58: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 1tLf1o-0006Xi-FY; Thu, 12 Dec 2024 08:58:36 +0000
Received: by outflank-mailman (input) for mailman id 855573;
 Thu, 12 Dec 2024 08:58: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 1tLf1n-0006Xc-Sb
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 08:58:35 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4401a1ff-b867-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 09:58:33 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5d3dce16a3dso653302a12.1
 for ; Thu, 12 Dec 2024 00:58:33 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d3dbf898e7sm7483135a12.16.2024.12.12.00.58.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Dec 2024 00:58: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: 4401a1ff-b867-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733993913; x=1734598713; 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=S7Qp3j63K5B0ohX3jwMaAjsqeWmkAwPi4LarI1Jro5Q=;
        b=dq31ooNvDl7ksHJ1k1lOv8+5/MtrXEeglZuIh1bel0354XsHMHwbonMVY6Cj89TjWU
         i46nWIt5yr8LVKbS0lSHH0O6M85VsbcCjL/wj8rrKjK07STnUKYeUawGfEuhsKxL/J7Y
         aKzG5XwNaR9NhJGwQH7JEoozvAWkTnrkUsW5g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733993913; x=1734598713;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=S7Qp3j63K5B0ohX3jwMaAjsqeWmkAwPi4LarI1Jro5Q=;
        b=DzcfI8uN35Z5t5tQvnFT9wOwKz9APK8lagrR9SF7afNECHlEmuxbnTXY9fRvMTZ37l
         BHuBAyaQgyUfvV7X3Sj05YANeTUCH9Z3TutQAHNFII5XNyc5vpLz7GH2ztMOPdqgfjRO
         rW6l0ZwdjaKcgClPn618G3TzPbT3w6HvPl9y2369gEqGYEV2rT3sNmz3Nex6xnj10xnc
         0zAH+EXDBJOLy43GNcYudduNtjaijIswk3SN4TooAvZiUiZ+Fdc+ndTjbX2G4EGItiqz
         qf0lL6sLlU5smwjiKo0faBG86b/LhPoF4vyD2wzTHNR+6IO0HHoS92eVNjS6Svw8GbuH
         wm0A==
X-Gm-Message-State: AOJu0YwY/YCfiYQb9uP5154xbjH29sDqnnnqqmqkE2MYM9k9RtP7RsIP
	2lln+YqBcOxE1UytaSoAzZS2/lBEmwQzwhBqeqOVB3BDJdhuQbZuLtrAXKwiozxHEHG052mrGHW
	F
X-Gm-Gg: ASbGncto+OIXCtg6WEDfAd8ZG4zdvPp/Z2Nm4bo1EBmdtjE+lw+qq81hFKmpqcjrOpY
	J1+rIZ+McKs/IKdsK62LQavQ6tNr5Qb4hWfADHw91KF7lnFZD0EsheZq3k96UBzHm7O3j38oOcD
	6rGB7iRPVCq8wHcQTM0t+TWtwrkaDNp0RuXllBe+/HUYxqPybw2KXFcjqzuDw5TZ3nfsVCaOCaF
	ck4aPIGbVl7Z+JoEdV3ks0BS8uWP4NJrqKZtc7bQamyqLuL1MfLDgJs1XC7CPo0ww==
X-Google-Smtp-Source: AGHT+IHOGTiCd4EOWpyI981EJYs5SCLgQglJbMyA92C3O4PGBltiPosW4TDUDuY1VIW/QAXcTkjU/g==
X-Received: by 2002:a05:6402:2811:b0:5d0:e9a8:4c96 with SMTP id 4fb4d7f45d1cf-5d54763b71dmr24351a12.9.1733993912863;
        Thu, 12 Dec 2024 00:58:32 -0800 (PST)
Date: Thu, 12 Dec 2024 09:58:31 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 15/35] xen/console: rename console_rx to console_owner
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-15-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-15-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:41:45PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Preparation for the follow on change to switch console_owner to
> domid_t address space.

I'm a bit confused, is the plan to assign the console (so both RX and
TX) exclusively to a domain?

Otherwise this would better be named console_input_target or similar,
if you think console_rx is not clear enough (FWIW, I'm OK with the
name given the current usage).

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 09:15:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 09:15:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855584.1268442 (Exim 4.92)
	(envelope-from )
	id 1tLfHj-0002fY-SR; Thu, 12 Dec 2024 09:15:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855584.1268442; Thu, 12 Dec 2024 09:15: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 1tLfHj-0002fR-Pi; Thu, 12 Dec 2024 09:15:03 +0000
Received: by outflank-mailman (input) for mailman id 855584;
 Thu, 12 Dec 2024 09:15: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 1tLfHi-0002fJ-HT
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 09:15:02 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 90b4dd63-b869-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 10:15:01 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5d3ecae02beso440609a12.0
 for ; Thu, 12 Dec 2024 01:15:01 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d3c1f99b84sm8840402a12.11.2024.12.12.01.15.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Dec 2024 01:15: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: 90b4dd63-b869-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733994900; x=1734599700; 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=H7igillvt6e+KKJzLmDEmwnXw1c3sNqc3sgGDnKwaTM=;
        b=UHWfGOSQ4aTe78RG7qBWAsTvFCUAKUeoG9aa5JfSKgrlHMumyujP3xVqy6l9ntcEQj
         jBNKD0WJt8cl+cBk9y74XsQVUcfm1Hblbr0j7KkAM2UxFNkDtWrdWkKsG23MePV7Ymu4
         Y+chU4/x9IRD3tFcvDFEHL8lKLoAmsADpWLDs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733994900; x=1734599700;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=H7igillvt6e+KKJzLmDEmwnXw1c3sNqc3sgGDnKwaTM=;
        b=Jwzqg96IeCmfilhg1tn7UvJGTrcU/YAfmX8v0NfKmzlwZpsBA5vy46zQ88c8H7Al9r
         kMk60Elu/iEPDyr6K7lvnYjLHSO93YW1jZVV/EDdNCkE7hD1hNVNL2Smks7RhQoVbNqs
         P8Zt+6Iuwv2zG11yyvL1M/HgzHp8HmhXeMpkzXAj0QlD9iOAyyqJTTbWdHaRBjtYmIqm
         neqmpDHxmlKOda51n4/pdNZF6dNCKYfUYfh1kXljuA0WD3lOJB4ZKAL3Lq9y5yGNELTV
         aPsK/dLKPHpbqQxhsVsAiG8jVoARj35OnCLQnR0SIZefaig9TpZ6sWa2+AS3bZU6DGxl
         A+7w==
X-Gm-Message-State: AOJu0YyVrb7jDSKgibxORLqhPKnnbGVKmuxPlgBuVu7Bj92ntqVB1eOT
	zfsL9jWOvlx3wE73F83cIgT1HVeWYqNP4AmVTwMoRHUVbertZkDXE99DmX8IuLUBxVgw61BT0NH
	Z
X-Gm-Gg: ASbGnctEuvgWbeXlKINwK3RK0MTpc73aIY5k0VSYKp+56PrdGsCe1ijZijXGzgPlj9H
	n6ZTLmFBWS1Kd2cSIuYIka9/KQvZEeZgeE8CfXiJBKZRLbESHx3ADs+4PTOVQvyH2/D1NEmAbN5
	3vszcC8UROq0RgxL9Yl677nDFarw/M4SWERcbF4N2NCyRHSYCccuAPwgqPfvNfLfszMGR4h22dX
	mOZYQJIOXCi7eNGGmRyd1w769MoQKMc1fBSnU62VlzmdyVAn/+aPvkjmB/xwHuBCQ==
X-Google-Smtp-Source: AGHT+IHpxfmtLt3O2pXYipKFquDT2QjuDKum3ecVVWyZFkR7oDl4PitWBC+DHqWN2iaBQMUtul5F1g==
X-Received: by 2002:a05:6402:3227:b0:5d0:d492:970b with SMTP id 4fb4d7f45d1cf-5d4e6a6e7demr422195a12.0.1733994900562;
        Thu, 12 Dec 2024 01:15:00 -0800 (PST)
Date: Thu, 12 Dec 2024 10:14:59 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 16/35] xen/console: introduce printk_common()
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-16-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-16-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:41:46PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Introduce new printk() variant for convenient printouts which skip '(XEN)'
> prefix on xen console. This is needed for the case when physical console is
> owned by a domain w/ in-hypervisor UART emulation enabled.

IIRC the ns8250 can only send or receive one byte (character) at a
time, so you should likely put that on the console as soon as it's
received?

For the hardware domain we explicitly don't buffer writes to the
console (see guest_console_write() hardware domain special handling).

I wonder however how you deal with domains that don't have the console
focus (ie: != console_rx), as for those I think you still want to use
the (d) prefix?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 09:30:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 09:30:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855595.1268452 (Exim 4.92)
	(envelope-from )
	id 1tLfX2-0006MQ-4I; Thu, 12 Dec 2024 09:30:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855595.1268452; Thu, 12 Dec 2024 09:30:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLfX2-0006MJ-1X; Thu, 12 Dec 2024 09:30:52 +0000
Received: by outflank-mailman (input) for mailman id 855595;
 Thu, 12 Dec 2024 09:30: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 1tLfX0-0006Kx-PM
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 09:30:50 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id c5331821-b86b-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 10:30:48 +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 D7A0F169E;
 Thu, 12 Dec 2024 01:31:15 -0800 (PST)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9CB7C3F5A1;
 Thu, 12 Dec 2024 01:30: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: c5331821-b86b-11ef-a0d5-8be0dac302b0
From: Luca Fancellu 
To: xen-devel@lists.xenproject.org
Cc: Penny Zheng ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Penny Zheng ,
	Wei Chen 
Subject: [PATCH v6] xen/arm: Check for Static Heap feature when freeing resources
Date: Thu, 12 Dec 2024 09:30:37 +0000
Message-Id: <20241212093037.2916713-1-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Penny Zheng 

If the Xen heap is statically configured in Device Tree, its size is
definite, so only the defined memory shall be given to the boot
allocator. Have a check where init_domheap_pages() is called
which takes into account if static heap feature is used.

Extract static_heap flag from init data bootinfo, as it will be needed
after destroying the init data section, rename it to using_static_heap
and use it to tell whether the Xen static heap feature is enabled.

Signed-off-by: Penny Zheng 
Signed-off-by: Wei Chen 
Signed-off-by: Luca Fancellu 
---
Changes from v5:
 - Drop Jan R-by due to the code changes
 - Static heap is not dependent on static memory, so delete #ifdefs
   for CONFIG_STATIC_MEMORY
Changes from v4:
 - Add R-by Jan
 - Changed code to reduce nesting in discard_initial_modules (Julien)
Changes from v3:
 - Removed helper using_static_heap(), renamed static_heap variable
   to using_static_heap and simplified #ifdef-ary (Jan suggestion)
Changes from v2:
 - Change xen_is_using_staticheap() to using_static_heap()
 - Move declaration of static_heap to xen/mm.h and import that in
   bootfdt.h
 - Reprased first part of the commit message
Changes from v1:
 - moved static_heap to common/page_alloc.c
 - protect static_heap access with CONFIG_STATIC_MEMORY
 - update comment in arm/kernel.c kernel_decompress()
---
---
 xen/arch/arm/arm32/mmu/mm.c       | 4 ++--
 xen/arch/arm/kernel.c             | 7 ++++---
 xen/arch/arm/mmu/setup.c          | 8 ++++++--
 xen/arch/arm/setup.c              | 3 +++
 xen/common/device-tree/bootfdt.c  | 2 +-
 xen/common/device-tree/bootinfo.c | 2 +-
 xen/common/page_alloc.c           | 3 +++
 xen/include/xen/bootfdt.h         | 1 -
 xen/include/xen/mm.h              | 2 ++
 9 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/arm32/mmu/mm.c b/xen/arch/arm/arm32/mmu/mm.c
index 063611412be0..0824d61323b5 100644
--- a/xen/arch/arm/arm32/mmu/mm.c
+++ b/xen/arch/arm/arm32/mmu/mm.c
@@ -199,7 +199,7 @@ void __init setup_mm(void)
 
     total_pages = ram_size >> PAGE_SHIFT;
 
-    if ( bootinfo.static_heap )
+    if ( using_static_heap )
     {
         const struct membanks *reserved_mem = bootinfo_get_reserved_mem();
 
@@ -246,7 +246,7 @@ void __init setup_mm(void)
 
     do
     {
-        e = bootinfo.static_heap ?
+        e = using_static_heap ?
             fit_xenheap_in_static_heap(pfn_to_paddr(xenheap_pages), MB(32)) :
             consider_modules(ram_start, ram_end,
                              pfn_to_paddr(xenheap_pages),
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 293d7efaed9c..8270684246ea 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -244,10 +244,11 @@ static __init int kernel_decompress(struct bootmodule *mod, uint32_t offset)
     size += offset;
 
     /*
-     * Free the original kernel, update the pointers to the
-     * decompressed kernel
+     * In case Xen is not using the static heap feature, free the original
+     * kernel, update the pointers to the decompressed kernel
      */
-    fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
+    if ( !using_static_heap )
+        fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
 
     return 0;
 }
diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c
index 9664e85ee6c0..8c87649bc88e 100644
--- a/xen/arch/arm/mmu/setup.c
+++ b/xen/arch/arm/mmu/setup.c
@@ -341,8 +341,12 @@ void free_init_memory(void)
     if ( rc )
         panic("Unable to remove the init section (rc = %d)\n", rc);
 
-    init_domheap_pages(pa, pa + len);
-    printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10);
+    if ( !using_static_heap )
+    {
+        init_domheap_pages(pa, pa + len);
+        printk("Freed %ldkB init memory.\n",
+               (long)(__init_end-__init_begin) >> 10);
+    }
 }
 
 /**
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 2e27af4560a5..85f743a2c6ad 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -206,6 +206,9 @@ void __init discard_initial_modules(void)
     struct bootmodules *mi = &bootinfo.modules;
     int i;
 
+    if ( using_static_heap )
+        return;
+
     for ( i = 0; i < mi->nr_mods; i++ )
     {
         paddr_t s = mi->module[i].start;
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index fc93d86e8232..47386d4fffea 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -410,7 +410,7 @@ static int __init process_chosen_node(const void *fdt, int node,
         if ( rc )
             return rc;
 
-        bootinfo.static_heap = true;
+        using_static_heap = true;
     }
 
     printk("Checking for initrd in /chosen\n");
diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c
index 0daf5e941a51..76d652c0de0b 100644
--- a/xen/common/device-tree/bootinfo.c
+++ b/xen/common/device-tree/bootinfo.c
@@ -407,7 +407,7 @@ void __init populate_boot_allocator(void)
     const struct membanks *reserved_mem = bootinfo_get_reserved_mem();
     paddr_t s, e;
 
-    if ( bootinfo.static_heap )
+    if ( using_static_heap )
     {
         for ( i = 0 ; i < reserved_mem->nr_banks; i++ )
         {
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 92abed6514b4..1f424333db27 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -165,6 +165,9 @@
 #define PGT_TYPE_INFO_INITIALIZER 0
 #endif
 
+/* Flag saved when Xen is using the static heap feature */
+bool __ro_after_init using_static_heap;
+
 unsigned long __read_mostly max_page;
 unsigned long __read_mostly total_pages;
 paddr_t __ro_after_init mem_hotplug;
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 343c48b73d2c..c8bbfd8979b2 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -139,7 +139,6 @@ struct bootinfo {
 #ifdef CONFIG_STATIC_SHM
     struct shared_meminfo shmem;
 #endif
-    bool static_heap;
 };
 
 #ifdef CONFIG_ACPI
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index d7dcf0f06330..16f733281af3 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -72,6 +72,8 @@
 
 struct page_info;
 
+extern bool using_static_heap;
+
 void put_page(struct page_info *page);
 bool __must_check get_page(struct page_info *page,
                            const struct domain *domain);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 12 09:31:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 09:31:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855601.1268462 (Exim 4.92)
	(envelope-from )
	id 1tLfXR-00075m-Ft; Thu, 12 Dec 2024 09:31:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855601.1268462; Thu, 12 Dec 2024 09:31: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 1tLfXR-00075f-Cu; Thu, 12 Dec 2024 09:31:17 +0000
Received: by outflank-mailman (input) for mailman id 855601;
 Thu, 12 Dec 2024 09:31: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 1tLfXP-0006Kx-If
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 09:31:15 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d4f04391-b86b-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 10:31:14 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5cf6f804233so492301a12.2
 for ; Thu, 12 Dec 2024 01:31:14 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa6701b08c2sm712832266b.124.2024.12.12.01.31.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Dec 2024 01:31:13 -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: d4f04391-b86b-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733995874; x=1734600674; 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=qgudi9dn3mJ13z1xTj/cewsTNQ/AtX31LoBxoz18FyY=;
        b=vFZLOXDf+JxR3qqPkp5RGPZdBJKMJPy6xzQak5WHWUgtDhdFLl7Y1HfCRaNvqtQ7fv
         XCdY8dnms9zHs+c0DlTz6J9pzSWtYCU0cAJZr3yT1vvrVAeTQpH62PZDyDM0PxvIsuSi
         OMoAaKIrIA3ISPQnMVFxg2mr9y88hpi0YUhWs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733995874; x=1734600674;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=qgudi9dn3mJ13z1xTj/cewsTNQ/AtX31LoBxoz18FyY=;
        b=vgK0J96Ki8iceC8tZjRh7V20Gw5PqaGVIqhEm9ea21GNxaqzgmkhsQ6SDC1N5nJvcf
         vnz4BCwU7biKH3rBJAd0BVomWYo85qjgE421jyD9IZqs1lenNjl0OMRsCcPPuY0QgxY4
         HtTHqGrPCshorXiPEuD3VNYj8Hxa5q9DZHv+yhFefVXN/e8DR+7m5NCmnD3xY35TX6o+
         qqGSA5qbr3fSAgIbfA/LJs12t2rrboW+5+mQRtPr3YiK44EwX6Ebiofqc9yqOCH88c2q
         BTTkwTvUQbO42nr1PKbe0DaUGxDwpOx9jB/XbEhPzfJRUis/LIVfhf9uQq91H2EcQ9La
         20GA==
X-Gm-Message-State: AOJu0YxXZtataChIogyjB2xYwlx9thUotuILyG6ZG9o8mRD2yvstjcWY
	S3sA/awhO03dRE0qYgd5yfyfTV/JwS+VM12EjXrqzRZbmCFsqwUEfDmtN0skk0Q=
X-Gm-Gg: ASbGncs5wtRm2i8dTNPxg9Y2BCQSluv8U4oSuCqP3oXocOH57CNSsjlWbVtDZP0hxz4
	a7ntc4k2VxPKQ3BOMGrS736YzKvLoYtGK2z8b31oyJADsNG2qCQhdXu8tUiY78dGd3tnFzR7Sg+
	VXUAruJiU0n3yz21zQHhETfvboCF9psN8k4oV2GM0uoZApXuXqCUUR/8EtKmMYFaAAt/X2Yh1Lx
	qynu6r/aQ8E776PqVEkIxiN3ZBpyufbRh/8ilPjeRVHCluHPEBZUOC4keMYZel9mA==
X-Google-Smtp-Source: AGHT+IF6rP1hm1fVeWkQl6kVHqGGGmFa5/aiK6pMSYZ7K4HUk0zNVqnlIY8yYjyPF6ORoaOJ8S+PHA==
X-Received: by 2002:a17:906:311a:b0:aa5:2575:e75d with SMTP id a640c23a62f3a-aa6b1141c72mr600474266b.2.1733995874036;
        Thu, 12 Dec 2024 01:31:14 -0800 (PST)
Date: Thu, 12 Dec 2024 10:31:12 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 17/35] xen/console: introduce consoled_is_enabled()
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-17-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-17-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:41:47PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> There are few places which check pv_shim console under CONFIG_PV_SHIM in xen
> console driver. Instead of #ifdef-ing, use new consoled_is_enabled() to
> customize the logic.
> 
> Header file now can be included w/o CONFIG_X86.
> 
> Signature of consoled_guest_{rx,tx} has changed to account for follow-on
> console switch logic cleanup.
> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/drivers/char/console.c  | 10 +++-------
>  xen/drivers/char/consoled.c | 18 ++++++++++++++----
>  xen/include/xen/consoled.h  | 35 +++++++++++++++++++++++++++++++++--
>  3 files changed, 50 insertions(+), 13 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index f034ce5aab3f3bf59b0df9fa583ee9ce32dbf665..60c055396b697869b04b9132b0dcfa832fabe932 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -33,9 +33,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #ifdef CONFIG_X86
> -#include 
>  #include 
>  #endif
>  #ifdef CONFIG_SBSA_VUART_CONSOLE
> @@ -505,11 +505,9 @@ static void console_find_owner(void)
>              break;
>          }
>  
> -#ifdef CONFIG_PV_SHIM
> -        if ( next_rx == 1 )
> +        if ( consoled_is_enabled() && next_rx == 1 )
>              domid = get_initial_domain_id();
>          else
> -#endif
>              domid = next_rx - 1;
>          d = rcu_lock_domain_by_id(domid);
>          if ( d )
> @@ -573,10 +571,8 @@ static void __serial_rx(char c)
>  #endif
>      }
>  
> -#ifdef CONFIG_X86
> -    if ( pv_shim && pv_console )
> +    if ( consoled_is_enabled() )
>          consoled_guest_tx(c);
> -#endif
>  }
>  
>  static void cf_check serial_rx(char c)
> diff --git a/xen/drivers/char/consoled.c b/xen/drivers/char/consoled.c
> index b415b632cecc0a80e161b701d7b70ba4f3cc5fb8..d6624e7697f56e1a1959b0efa5dca104f34af002 100644
> --- a/xen/drivers/char/consoled.c
> +++ b/xen/drivers/char/consoled.c
> @@ -43,13 +43,13 @@ struct xencons_interface *consoled_get_ring_addr(void)
>  static char buf[BUF_SZ + 1];
>  
>  /* Receives characters from a domain's PV console */
> -void consoled_guest_rx(void)
> +int consoled_guest_rx(void)
>  {
>      size_t idx = 0;
>      XENCONS_RING_IDX cons, prod;
>  
>      if ( !cons_ring )
> -        return;
> +        return 0;
>  
>      spin_lock(&rx_lock);
>  
> @@ -91,15 +91,17 @@ void consoled_guest_rx(void)
>  
>   out:
>      spin_unlock(&rx_lock);
> +
> +    return 0;
>  }
>  
>  /* Sends a character into a domain's PV console */
> -void consoled_guest_tx(char c)
> +int consoled_guest_tx(char c)
>  {
>      XENCONS_RING_IDX cons, prod;
>  
>      if ( !cons_ring )
> -        return;
> +        return 0;
>  
>      cons = ACCESS_ONCE(cons_ring->in_cons);
>      prod = cons_ring->in_prod;
> @@ -118,6 +120,7 @@ void consoled_guest_tx(char c)
>  
>      cons_ring->in[MASK_XENCONS_IDX(prod++, cons_ring->in)] = c;
>  
> +
>      /* Write to the ring before updating the pointer */
>      smp_wmb();
>      ACCESS_ONCE(cons_ring->in_prod) = prod;
> @@ -125,6 +128,13 @@ void consoled_guest_tx(char c)
>   notify:
>      /* Always notify the guest: prevents receive path from getting stuck. */
>      pv_shim_inject_evtchn(pv_console_evtchn());
> +
> +    return 0;
> +}
> +
> +bool consoled_is_enabled(void)
> +{
> +    return pv_shim && pv_console;
>  }
>  
>  /*
> diff --git a/xen/include/xen/consoled.h b/xen/include/xen/consoled.h
> index bd7ab6329ee8a7c466484021247241ded8ed03c7..696677fa5a3be458a0ec93360e08376c3471f95b 100644
> --- a/xen/include/xen/consoled.h
> +++ b/xen/include/xen/consoled.h
> @@ -3,10 +3,41 @@
>  
>  #include 
>  
> +#if defined(CONFIG_PV_SHIM)
> +
>  void consoled_set_ring_addr(struct xencons_interface *ring);
>  struct xencons_interface *consoled_get_ring_addr(void);
> -void consoled_guest_rx(void);
> -void consoled_guest_tx(char c);
> +int consoled_guest_rx(void);
> +int consoled_guest_tx(char c);
> +bool consoled_is_enabled(void);
> +
> +#else
> +
> +static inline void consoled_set_ring_addr(struct xencons_interface *ring)
> +{
> +}
> +
> +static inline struct xencons_interface *consoled_get_ring_addr(void)
> +{
> +    return NULL;
> +}
> +
> +static inline int consoled_guest_rx(void)
> +{
> +    return 0;
> +}

You don't need to provide dummy implementations of
consoled_{set,get}_ring_addr() and consoled_guest_rx(), they are only
called from code that's build when CONFIG_PV_SHIM is selected.

> +static inline int consoled_guest_tx(char c)
> +{
> +    return 0;

For consoled_guest_tx() you want to add an ASSERT_UNREACHABLE(), as
it should never be called if !CONFIG_PV_SHIM?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 10:12:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 10:12:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855627.1268476 (Exim 4.92)
	(envelope-from )
	id 1tLgBJ-0007po-BO; Thu, 12 Dec 2024 10:12:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855627.1268476; Thu, 12 Dec 2024 10:12: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 1tLgBJ-0007ph-8t; Thu, 12 Dec 2024 10:12:29 +0000
Received: by outflank-mailman (input) for mailman id 855627;
 Thu, 12 Dec 2024 10:12:29 +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 1tLgBI-0007pb-UI
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 10:12:28 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9352db56-b871-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 11:12:21 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-aa67333f7d2so58285366b.0
 for ; Thu, 12 Dec 2024 02:12:26 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa687bbe83bsm574528166b.188.2024.12.12.02.12.25
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Dec 2024 02:12: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: 9352db56-b871-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733998346; x=1734603146; 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=+6IjAX4mVM3M7acEHQrD01ZAC0Q9A8vGkOVZ5x26frQ=;
        b=vR9OiGs0Qr7s9R2ED4kd+AQCRa4GYcn5QhtO0yjsqPdT7rxWfMvqNcbeStilwe7nzh
         gVRCF8yYsLUr+xN67+tDKCNUBwLGmEkbsPvfdM3YKCzMMRDIDpsXo4SWcQ94WFDuM5SL
         +Grauw0JjKnSj/FD4D64SvfnebL47Pxyi38jE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733998346; x=1734603146;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+6IjAX4mVM3M7acEHQrD01ZAC0Q9A8vGkOVZ5x26frQ=;
        b=woEUYwTtH4Iu4B2hkNCNeb7jwKV5ZzOgsYyinK61GP3o62K0nyEzLE3w7xBKQ6kgKw
         xZE99H1bdQdgCGNIgpuBeSjI4QhfhivMnaXfVMEOgCmXfiyUO7M2WoL5p57kD6/Z8Ihw
         iExmOFspIRVKFaoKXDX+s55i+ZZzotnACsJXzNTCwZ11+NOpp6nCWyBtxKs396aH/tA0
         FUve1znY5ynzQyq/SjxWR0rJNkeAI0ztb1IuBb1+PEIB0/bOEu8yuGLCe86p5qNi2Tea
         O/VKoxblcqjYD2cqA8BIOkxzxKKhyZnZc2iKyvBZytDeXtuQwR9WqkYn6eIMRPn/FSwn
         DYTw==
X-Gm-Message-State: AOJu0Yyc6sJ1NMy/PQUIsTqN1ZqgFJLYkoKf1xRS3hPVKYmPH74JKro7
	ndQZa4rvAqK/0U6snWIs6kOgVgH4/bXFbECkLpxSDp+m5pi6Kkfhy/rdNUdt27c=
X-Gm-Gg: ASbGncudWZAOp0Hd/ak1wSc917hjDt5MLpZrcGwuNWWZeS1wmOPATCLJWhLqnQCGpvK
	Z+1+Z1HQ2DjZCG40b+SPyvhNb7Wali/J24AoUS5+2098RL//dbkSe62uPRAJoLh9JeO+taSOW9e
	iZVsNTdCeCQJwvjqYqe4aCuxz8ru44oF3utzlo3sdKkGhgwDvSflr1J6KQfiYudU2N4jjCorsQE
	qt0G/99a29nJGGDVH9KJ3LDsRv77X0fcCgMj2pkRYC51n0Lwz1XSJzzr6orHQDT1Q==
X-Google-Smtp-Source: AGHT+IH1pIYcj0aTsC1/vmkvOZqV0BUtKm1CjpZnwAliOKqHhLU1HjQDukL0VQqGj7tpF2mf56/bCg==
X-Received: by 2002:a17:907:7856:b0:aa6:2b8b:20c6 with SMTP id a640c23a62f3a-aa6b11a0dd4mr547195966b.20.1733998345987;
        Thu, 12 Dec 2024 02:12:25 -0800 (PST)
Date: Thu, 12 Dec 2024 11:12:24 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 19/35] xen/console: introduce console_set_owner()
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-19-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-19-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:41:49PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> console_set_owner() is introduced for setting the new console owner.
> 
> Switches console owner to domain ID vs range of integer numbers mapped to
> domain IDs.
> 
> This a public API to console driver, will be used in the follow on code change.
> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/drivers/char/console.c | 122 ++++++++++++++++++++++++++-------------------
>  xen/include/xen/console.h  |   1 +
>  2 files changed, 71 insertions(+), 52 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 8cbac54c66044ae8581e486a782102b75c8bfaa9..52cf64dbf6fd18d599cb88835d03501a23b3e3c4 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -463,82 +463,100 @@ static void cf_check dump_console_ring_key(unsigned char key)
>  
>  /*
>   * CTRL- changes input direction, rotating among Xen, Dom0,
> - * and the DomUs started from Xen at boot.
> + * and the DomUs.
>   */
>  #define switch_code (opt_conswitch[0]-'a'+1)
> +
>  /*
> - * console_owner=0 => input to xen
> - * console_owner=1 => input to dom0 (or the sole shim domain)
> - * console_owner=N => input to dom(N-1)
> + * Current console owner domain ID: either Xen or domain w/ d->is_console ==
> + * true.
> + *
> + * Initialized in console_endboot().
>   */
> -static unsigned int __read_mostly console_owner = 0;
> +static domid_t __read_mostly console_owner;

Should this be initialized to DOMID_XEN?  I assume it doesn't make
much difference because the variable is not checked before
console_endboot() anyway, but it might be safer to initialize to a
value that assigns the console to Xen.

>  
> -#define max_console_rx (max_init_domid + 1)
> +static struct domain *rcu_lock_domain_console_by_id(domid_t domid)
> +{
> +    struct domain *d;
> +
> +    d = rcu_lock_domain_by_id(domid);
> +

Nit: I would remove this newline.

> +    if ( d == NULL )
> +        return NULL;
> +
> +    if ( d->is_console )
> +        return d;
> +
> +    rcu_unlock_domain(d);
> +
> +    return NULL;
> +}
>  
> -#ifdef CONFIG_SBSA_VUART_CONSOLE
>  /* Make sure to rcu_unlock_domain after use */
>  struct domain *rcu_lock_domain_console_owner(void)
>  {
> -    if ( console_owner == 0 )
> -            return NULL;
> -    return rcu_lock_domain_by_id(console_owner - 1);
> +    return rcu_lock_domain_console_by_id(console_owner);
>  }
> -#endif
>  
> -static void console_find_owner(void)
> +static bool console_owner_possible(domid_t domid)
>  {
> -    unsigned int next_rx = console_owner;
> -
> -    /*
> -     * Rotate among Xen, dom0 and boot-time created domUs while skipping
> -     * switching serial input to non existing domains.
> -     */
> -    for ( ; ; )
> -    {
> -        domid_t domid;
> -        struct domain *d;
> -
> -        if ( next_rx++ >= max_console_rx )
> -        {
> -            console_owner = 0;
> -            printk("*** Serial input to Xen");
> -            break;
> -        }
> -
> -        if ( consoled_is_enabled() && next_rx == 1 )
> -            domid = get_initial_domain_id();
> -        else
> -            domid = next_rx - 1;
> -
> -        d = rcu_lock_domain_by_id(domid);
> -        if ( d == NULL )
> -            continue;
> -
> -        if ( d->is_console )
> -        {
> -            rcu_unlock_domain(d);
> -            console_owner = next_rx;
> -            printk("*** Serial input to DOM%u", domid);
> -            break;
> -        }
> +    struct domain *d;
>  
> +    d = rcu_lock_domain_console_by_id(domid);
> +    if ( d != NULL )
>          rcu_unlock_domain(d);
> -    }
> +
> +    return d != NULL;
> +}
> +
> +int console_set_owner(domid_t domid)
> +{
> +    if ( domid == DOMID_XEN )
> +        printk("*** Serial input to Xen");
> +    else if ( console_owner_possible(domid) )
> +        printk("*** Serial input to DOM%u", domid);
> +    else
> +        return -ENOENT;
> +
> +    console_owner = domid;
>  
>      if ( switch_code )
>          printk(" (type 'CTRL-%c' three times to switch input)",
>                 opt_conswitch[0]);
>      printk("\n");
> +
> +    return 0;
> +}
> +
> +/*
> + * Switch console input focus.
> + * Rotates input focus among Xen, dom0 and boot-time created domUs while
> + * skipping switching serial input to non existing domains.
> + */
> +static void console_find_owner(void)
> +{
> +    domid_t i, n = max_init_domid + 1;

n can be made const, I would even rename to nr for clarity, but that's
personal taste.

> +
> +    if ( console_owner == DOMID_XEN )
> +        i = get_initial_domain_id();
> +    else
> +        i = console_owner + 1;
> +
> +    for ( ; i < n; i++ )
> +        if ( !console_set_owner(i) )
> +            break;

Hm, that could be a non-trivial amount of iteration if max_init_domid
is bumped for every domain created as you have it in patch 11/35
(albeit I'm not sure that was intended?)

> +    if ( i == n )
> +        console_set_owner(DOMID_XEN);
>  }
>  
>  static void __serial_rx(char c)
>  {
>      switch ( console_owner )
>      {
> -    case 0:
> +    case DOMID_XEN:
>          return handle_keypress(c, false);
>  
> -    case 1:
> +    case 0:

If console_owner now strictly contains a domid you cannot assume that
domid 0 is the hardware domain, you will need to handle this
differently and check whether the domain pointed by console_owner
passes the is_hardware_domain() check.

>          /*
>           * Deliver input to the hardware domain buffer, unless it is
>           * already full.
> @@ -556,7 +574,7 @@ static void __serial_rx(char c)
>  #ifdef CONFIG_SBSA_VUART_CONSOLE
>      default:
>      {
> -        struct domain *d = rcu_lock_domain_by_id(console_owner - 1);
> +        struct domain *d = rcu_lock_domain_by_id(console_owner);
>  
>          /*
>           * If we have a properly initialized vpl011 console for the
> @@ -567,7 +585,7 @@ static void __serial_rx(char c)
>              vpl011_rx_char_xen(d, c);
>          else
>              printk("Cannot send chars to Dom%d: no UART available\n",
> -                   console_owner - 1);
> +                   console_owner);
>  
>          if ( d != NULL )
>              rcu_unlock_domain(d);
> @@ -1126,7 +1144,7 @@ void __init console_endboot(void)
>       * a useful 'how to switch' message.
>       */
>      if ( opt_conswitch[1] == 'x' )
> -        console_owner = max_console_rx;
> +        console_owner = DOMID_XEN;

Hm, are you sure this still works as expected?  Setting console_owner
== DOMID_XEN will cause the call to switch_serial_input() below to
switch the console back to the first domain in the system.  Also
initializing console_owner to 0 by default would also cause the call
to switch_serial_input() to possibly switch it to the first domain
after domid 0 (or back to Xen).

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 10:18:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 10:18:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855639.1268486 (Exim 4.92)
	(envelope-from )
	id 1tLgHK-0008St-3C; Thu, 12 Dec 2024 10:18:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855639.1268486; Thu, 12 Dec 2024 10:18: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 1tLgHK-0008Sm-0P; Thu, 12 Dec 2024 10:18:42 +0000
Received: by outflank-mailman (input) for mailman id 855639;
 Thu, 12 Dec 2024 10:18: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 1tLgHJ-0008Sg-02
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 10:18:41 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 741d4906-b872-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 11:18:40 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5d3f65844deso655558a12.0
 for ; Thu, 12 Dec 2024 02:18:38 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d3eb109bc9sm6830953a12.42.2024.12.12.02.18.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Dec 2024 02:18: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: 741d4906-b872-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733998718; x=1734603518; 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=PAjh9EwANrCRydhu1/QCA56w6BsZUlaXVNGvSsLPj3w=;
        b=uOFPw9OxVvRPp5mapEv8dgcTQ3ATCeT1oXpiSOBhNyAhE5niTD7/ZZt9hssPv3z64Y
         luh2/a5386gFrg1ij7UWBQ4VnyMSoDjHMdBFoYavpY/6It972sbZpoKUXIp28WIz+nP7
         HxuoXVWPG5JrDy//f6GGX6DNE+mRMTWqNhwGo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733998718; x=1734603518;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=PAjh9EwANrCRydhu1/QCA56w6BsZUlaXVNGvSsLPj3w=;
        b=MLqMqukxSflvWYAY1PIXJpJ2Izs2IdPIWqhYylUEknYP4EGG56t/Zmf+CkFk31otgw
         OVhS8uX7PCoVHma4RhQQReSXuIAoD0sdZuJimB+gAtF3i+J9hSM6CAvovpxBeUkGoLWl
         VZZ5LtMYq3T/pf2rltH8F02qmN8kRusx93kBJUHddnIDrT5cquEABWm70KeYS6/ESRpc
         54lQHM9elcYJ/FfoolrQpZfTkog6rFIs54L+Log8TpOM1XjuN7884cKpxsrVoLfOWMQY
         gneCx6bKq6sPse1iFwwGvKrR0N1x3SdIqKnH27a5ePnPHrpKGXRgFg6g0NXZtMzSFKmb
         uIpw==
X-Gm-Message-State: AOJu0YyXOpV1vhQbnItqAZOX9XBiiPiZlOdOxoctZucSuqNgmj2bgYae
	wonye+gvCIIRzRxFJzpS/iiw+i/4/QBhAC1LOKAVcGY8nrfHkASfPtyjPyv8vCo=
X-Gm-Gg: ASbGncuZPmR+IZW5x+DZw0XEQigSYrthcAdf9etXiugyZTH5rQy1bUvam5KbOitcB9n
	LIa7RmG8cUmqZLBmtXUSTezkmrmwzcCzMBUq1yQAdcVrC/bnKRnGvcrAbDeMbiErlIWwItX3V+O
	ZnYbcD+hso9bfpM0eq3o72fAHVfnJB0WXSpYFVUKols0EcPEhwrhtFbJyZWBgUmnJDacJepEFFz
	Fd/kBW5Pmd0hyyLOdCO/FIQ+rr/m8byeXUW6yOLKjW98eByyDC5+vM6DjxeM3pTqQ==
X-Google-Smtp-Source: AGHT+IHRSJEAqOwCFT01xSX3OoG1DDL8YdjrQ8mQzgjpArHOTq4oRaDHvUdUSTGgHo1pplDVb0brTg==
X-Received: by 2002:a05:6402:34cb:b0:5d0:e826:f0da with SMTP id 4fb4d7f45d1cf-5d54765c5e4mr270935a12.16.1733998718089;
        Thu, 12 Dec 2024 02:18:38 -0800 (PST)
Date: Thu, 12 Dec 2024 11:18:36 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 20/35] xen/console: introduce console_owner_domid()
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-20-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:41:50PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> console_owner_domid() is introduced to obtain the "console owner" domain ID.
> 
> The call is used in NS8250 emulator to identify the case when physical xen
> console focus is owned by the domain w/ NS8250 emulator, in which case,
> messages from guest OS are formatted w/o '(XEN)' prefix.

Nit: it would be better to not use abbreviations such as w/ or w/o in
commit messages.

> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/drivers/char/console.c | 5 +++++
>  xen/include/xen/console.h  | 1 +
>  2 files changed, 6 insertions(+)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 52cf64dbf6fd18d599cb88835d03501a23b3e3c4..a8ab5c2bcb98e4cadf9ad2c9ad28d297977d0557 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -498,6 +498,11 @@ struct domain *rcu_lock_domain_console_owner(void)
>      return rcu_lock_domain_console_by_id(console_owner);
>  }
>  
> +domid_t console_owner_domid(void)
> +{
> +    return console_owner;
> +}
> +
>  static bool console_owner_possible(domid_t domid)
>  {
>      struct domain *d;
> diff --git a/xen/include/xen/console.h b/xen/include/xen/console.h
> index 57c482cfbf2da15b011e64841ea086e779f4588d..83be5794aff6630beaad46f910fcc0fc6d833808 100644
> --- a/xen/include/xen/console.h
> +++ b/xen/include/xen/console.h
> @@ -33,6 +33,7 @@ void console_end_log_everything(void);
>  
>  struct domain *rcu_lock_domain_console_owner(void);
>  int console_set_owner(domid_t);
> +domid_t console_owner_domid(void);

I would expect that either the caller already has a domain locked, or
uses rcu_lock_domain_console_owner() to obtain the domain and then get
the domid?  (d->domain_id?)

It's hard to tell why you need such way to get the console input
target domid in such a way without seeing a caller to the function.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 10:22:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 10:22:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855653.1268495 (Exim 4.92)
	(envelope-from )
	id 1tLgKf-0002Wf-Gk; Thu, 12 Dec 2024 10:22:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855653.1268495; Thu, 12 Dec 2024 10:22: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 1tLgKf-0002WY-Dp; Thu, 12 Dec 2024 10:22:09 +0000
Received: by outflank-mailman (input) for mailman id 855653;
 Thu, 12 Dec 2024 10:22: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 1tLgKd-0002WS-Mt
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 10:22:07 +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 f015a96a-b872-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 11:22:06 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-434ab938e37so2891665e9.0
 for ; Thu, 12 Dec 2024 02:22:06 -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-4362559eaf6sm12181355e9.20.2024.12.12.02.22.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 02:22:05 -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: f015a96a-b872-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733998926; x=1734603726; 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=c645PNElfeFM12UdgKMeAmcuHLZRg8JK7eBZ7/1+xnY=;
        b=eyUdZu1R3DNBlpuqXezjIl8BGqI4WGWmJREA9qpq2lRA4vzsxci9F/mwygsmZ2AVZy
         m++/2pYUAyjCa3PdY56ZJ5lzwT6HUX9vvcb6thsV5O8Ql48ae6tLoLythFJ/mPSnFHcI
         MlWaFjrr8qMQX+Q91N1YTE8KrmXMPPNKeXAMw6hYUJiLxVc1X15iKptHbZ8190MdhGI/
         Ax3Vur3yi4CWmMrB2oQO53BWPNX3qmO8VZtMQCnCRTJRZEdOj3ErNDtykKt5Uix0W4n0
         sI0urxnt1J0ePliiVlcEkG4mgtn/coxhM5/LxCdq9QlYWAkESZrEbMRrV3fwPOWBV2Wd
         gVuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733998926; x=1734603726;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=c645PNElfeFM12UdgKMeAmcuHLZRg8JK7eBZ7/1+xnY=;
        b=VJXqoyPeIzf3GN8IPAMsBKc0I8L7tuhagrn+jUYl74/d9J955VlxxHv7xDRgu1UJ5h
         2uFOOiJr6stq+DDjqlDG8bdAxFhf16YFWJbVvXa6UZSLFN2azC1iVNxzMWLzqg43r1vb
         PyrxVQxXhYMzF0TMECG59hfQ47AojqsphQ8CjzNpAP8v8ie3fHrVOExOBRAgw4AKADEy
         rel+pEuAVCIg7R5t8ruaLITnZjl6Kt5GfgzKhy0irnGxWwxecSYY9aIvNpHFtWcpagGj
         XfVsTAfNzSZHYdqe9IQjbDBkbOnE0FFxuOIInc6I68EtAfowLukEBdgEkI+gE7KTtMHL
         idUw==
X-Forwarded-Encrypted: i=1; AJvYcCVTUeSQLZ6noYGH0txsMeVj6tvi60RugEUeAiM7AYqwReLFmJi3JmXC3wkI6Z9x8NMgBtf2W2m0qWQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yygiq31Ee18R8o7kG0lKK9ze6QQ3LbZHpVrZT0CMKM8I90/79F8
	Ubc5vJK/egZw/L0LgnmIgmqNXUjmbNw9mqggkhlqakxbbdqbz4WVDs6MnoBbRg==
X-Gm-Gg: ASbGncurFvIA/ya0shLoZrq7W3+FgQ8cQnUZ1sjPb584UkwEXio9ZmJKws2guadwNwp
	RXrlVkfKEIVtRpMv2JN+L8yy51xen+bHWeB/A8WudiQC+yAjIYVa6gGgx4z9ILEqc8ffxePGvI9
	oR5mEHnI+j0m2wmAbmIB9ZUjqgXgbCzHS0I0IZQ04TXTcNzIuQEUppgdZAyOlu//Tot/YpLxqi7
	+7TQrbg9kBlcBgzq45tMZPgoVeE8ZTb9NpmLXdDxofXfaYUaUD+6SsDFSMPVXpgTPRIGnnI+JnJ
	BavSV1C21TiYgZZLNI4CJElQjxNP7HOc9fknW3b6TQ==
X-Google-Smtp-Source: AGHT+IEEpl5WnfVqD5Eyl1PeCZc5X0OZKvY51dNZlWpRgEl0ZIGnyTAoD5sXkKoKOCY9S9gRMv6sMg==
X-Received: by 2002:a05:600c:4450:b0:436:1aa6:b8ee with SMTP id 5b1f17b1804b1-4361c346a7emr52444405e9.2.1733998926105;
        Thu, 12 Dec 2024 02:22:06 -0800 (PST)
Message-ID: 
Date: Thu, 12 Dec 2024 11:22:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/xen/mmu: Increase MAX_CONTIG_ORDER
To: Thierry Escande 
Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com,
 xen-devel@lists.xenproject.org, Juergen Gross ,
 linux-kernel@vger.kernel.org
References: <20241204171346.458105-1-thierry.escande@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 11.12.2024 19:20, Thierry Escande wrote:
> Hi Jan,
> 
> On 09/12/2024 11:04, Jan Beulich wrote:
>> On 04.12.2024 18:14, Thierry Escande wrote:
>>> With change 9f40ec84a797 (xen/swiotlb: add alignment check for dma
>>> buffers), the driver mpt3sas fails to load because it cannot allocate
>>> its DMA pool for an allocation size of ~2,3 MBytes. This is because the
>>> alignement check added by 9f40ec84a797 fails and
>>> xen_swiotlb_alloc_coherent() ends up calling
>>> xen_create_contiguous_region() with a size order of 10 which is too high
>>> for the current max value.
>>>
>>> This patch increases the MAX_CONTIG_ORDER from 9 to 10 (4MB) to allow
>>> such allocations.
>>>
>>> Signed-off-by: Thierry Escande 
>>> ---
>>>  arch/x86/xen/mmu_pv.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
>>> index 55a4996d0c04..7f110740e1a2 100644
>>> --- a/arch/x86/xen/mmu_pv.c
>>> +++ b/arch/x86/xen/mmu_pv.c
>>> @@ -2200,7 +2200,7 @@ void __init xen_init_mmu_ops(void)
>>>  }
>>>  
>>>  /* Protected by xen_reservation_lock. */
>>> -#define MAX_CONTIG_ORDER 9 /* 2MB */
>>> +#define MAX_CONTIG_ORDER 10 /* 4MB */
>>>  static unsigned long discontig_frames[1<>
>> While lacking respective commentary, bumping this value imo also needs to
>> take into account Xen itself, at least commit-message-wise. The bumping is
>> fine for Dom0 in any event. It is also fine for DomU-s with the defaults
>> built into the hypervisor (orders 12 and 10 respectively for x86 and Arm),
>> yet especially for Arm (and in the future PPC and RISC-V) any further
>> bumping would be less straightforward.
> 
> Thanks for pointing this out. On the Xen side, CONFIG_CTLDOM_MAX_ORDER
> and CONFIG_HWDOM_MAX_ORDER seem big enough on all architectures. But I
> see CONFIG_DOMU_MAX_ORDER set to 9 (also all archs). Won't that be a
> problem for drivers trying to allocate more than that from a domU ?

A driver assumes a (physical) device to be in the DomU, at which point it
is CONFIG_PTDOM_MAX_ORDER which applies (PT standing for pass-through).

>> However - does the driver really need this big a contiguous chunk? It
>> would seem far more desirable to me to break that up some, if possible.
> 
> Since this works on bare metal I'm afraid the driver maintainer (mpt
> fusion driver) will just tell me to fix Xen.

Well. The bigger such allocations, the larger the risk that on systems
that have been up for a while such allocations can't be fulfilled anymore
even in the bare metal case.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 10:24:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 10:24:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855667.1268506 (Exim 4.92)
	(envelope-from )
	id 1tLgMW-00039K-Vk; Thu, 12 Dec 2024 10:24:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855667.1268506; Thu, 12 Dec 2024 10:24: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 1tLgMW-00039D-Sv; Thu, 12 Dec 2024 10:24:04 +0000
Received: by outflank-mailman (input) for mailman id 855667;
 Thu, 12 Dec 2024 10:24: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 1tLgMV-000397-4M
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 10:24:03 +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 31650407-b873-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 11:23:56 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-5d3d143376dso577544a12.3
 for ; Thu, 12 Dec 2024 02:24:01 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d3f4ecdd02sm6170212a12.81.2024.12.12.02.24.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Dec 2024 02:24: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: 31650407-b873-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1733999041; x=1734603841; 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=rhJXeRLyiJKXQgxd0Ls1ZxBZm8Jk6VnGD8JsOnPnRQk=;
        b=CGQn7DQIHnawLU5GooekUEhcbv40yL2yT6/ByvISMvYulBbeSx+1E7va4Cd/pwMOts
         mBINIhUPE6jCmlH074UrLdgBvPfXJZVzWN91OtP1V0UslHdEfL3+Ws4TfbbHpoj1XXUN
         R2DTqXz2eM+gbrtgt2nZ+ww3iqCJgUtWlLfz0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733999041; x=1734603841;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=rhJXeRLyiJKXQgxd0Ls1ZxBZm8Jk6VnGD8JsOnPnRQk=;
        b=tKgt50WzVATaxV5Upwq/bz+h3QSek//eJSuCUfNSMLfCw20XKQCG2BaADGiau3mmiT
         +WWd3XqbxKzMdsxm7TW2LlrFcFJPXRDfJGl3rzUQS/2zes8Qgdu9PFPDVU6mBSl097tM
         zPP0SOyP9zfLNkNilNtOoxmHPYwQOiBIGoJHBecAcyLezur4QZ+0X383LIjZWEfvpUY5
         K9BrYG+M8cGacdBGOwSaZCz559yShdKO+6Xoe6NDOJslSGzC5cvmUq2luxTEQg5Shhu2
         SOqh2Nw+dJMledKD6dv1dUC4X6JbZlwFMJCvOKCSXfJT9YT0LhCfnnSu61U7b1hR3Xnd
         CmwQ==
X-Gm-Message-State: AOJu0Yw7jBblwaMcf74IRAf5cvwlD9i9ff0zijkFby993ttTPmbB2XW5
	JRdRBDtChEst7ohQaIma/o0nldoGwf8DqCXDRxqktj6O99VovDU4sPW/2ASO688=
X-Gm-Gg: ASbGncuvH+A60tSFcUMSSXRCCFnheK7dXUXGb385XMgkWn0bDdlIpBC/GKZe0ge2Hv/
	shMZGLUPLXa4onCTBUpQH0s6wyhTjKfY6HT+6tTVhf0XKtR+oDsTqsgkPWoS7XLag5OMnWimEEv
	iZeBByy/RHNGvqlodP9d24skP22LM7otgf4nZOXRUI6o1EMX9EuTp3/yW/DRJFQxUn8ysFw/xNq
	WIHDmiVjIraYtNIumNMnyr4XjL8c/pCxdfKKDx7fOgg1tnKPr21yJNtPNyo11dtTA==
X-Google-Smtp-Source: AGHT+IGvstdDiL2qxZR52qksPJ92TafMAuwpIUv2yiVQauGoJmQ5tFbJ5kqDHSCapRZqWDaQmcFrtA==
X-Received: by 2002:a05:6402:26cc:b0:5d2:7199:ae5 with SMTP id 4fb4d7f45d1cf-5d4edcce2bemr436467a12.5.1733999040654;
        Thu, 12 Dec 2024 02:24:00 -0800 (PST)
Date: Thu, 12 Dec 2024 11:23:59 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 21/35] xen/console: introduce console_init_owner()
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-21-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-21-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:41:51PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> console_init_owner() is introduced for selecting the boot-time console owner.
> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/drivers/char/console.c | 27 +++++++++++++++++----------
>  1 file changed, 17 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index a8ab5c2bcb98e4cadf9ad2c9ad28d297977d0557..6261bdb5a2ac1075bc89fa408c0fd6cfef380ae6 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -554,6 +554,22 @@ static void console_find_owner(void)
>          console_set_owner(DOMID_XEN);
>  }
>  
> +static void console_init_owner(void)

__init attribute missing (given current call context), but see below.

> +{
> +    domid_t domid;
> +
> +    /*
> +     * If user specifies so, we fool the switch routine to redirect input
> +     * straight back to Xen.
> +     */
> +    if ( opt_conswitch[1] == 'x' )
> +        domid = DOMID_XEN;
> +    else
> +        domid = get_initial_domain_id();
> +
> +    console_set_owner(domid);
> +}
> +
>  static void __serial_rx(char c)
>  {
>      switch ( console_owner )
> @@ -1143,14 +1159,6 @@ void __init console_endboot(void)
>  
>      video_endboot();
>  
> -    /*
> -     * If user specifies so, we fool the switch routine to redirect input
> -     * straight back to Xen. I use this convoluted method so we still print
> -     * a useful 'how to switch' message.
> -     */
> -    if ( opt_conswitch[1] == 'x' )
> -        console_owner = DOMID_XEN;
> -
>      register_keyhandler('w', dump_console_ring_key,
>                          "synchronously dump console ring buffer (dmesg)", 0);
>      register_irq_keyhandler('+', &do_inc_thresh,
> @@ -1160,8 +1168,7 @@ void __init console_endboot(void)
>      register_irq_keyhandler('G', &do_toggle_guest,
>                              "toggle host/guest log level adjustment", 0);
>  
> -    /* Serial input is directed to DOM0 by default. */
> -    console_find_owner();
> +    console_init_owner();

Oh, so this is what fixes the regression introduced in patch 19/35.
THB I'm not sure it's worth introducing the console_init_owner()
helper if it's just for this usage.  You could do:

console_set_owner(opt_conswitch[1] == 'x' ? DOMID_XEN
                                          : get_initial_domain_id());

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 10:30:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 10:30:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855679.1268516 (Exim 4.92)
	(envelope-from )
	id 1tLgT0-00059V-Ky; Thu, 12 Dec 2024 10:30:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855679.1268516; Thu, 12 Dec 2024 10:30:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLgT0-00059O-IL; Thu, 12 Dec 2024 10:30:46 +0000
Received: by outflank-mailman (input) for mailman id 855679;
 Thu, 12 Dec 2024 10:30: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 1tLgSz-00059I-VI
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 10:30:45 +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 24ebc80d-b874-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 11:30:44 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-434a736518eso4685505e9.1
 for ; Thu, 12 Dec 2024 02:30: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
 a640c23a62f3a-aa69afa395csm449919266b.71.2024.12.12.02.30.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 02:30: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: 24ebc80d-b874-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733999444; x=1734604244; 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=TrJ/D3rbPGQe4yyzZZUi7eBLXXQ8mzVAZH0cIW0dtWw=;
        b=efVt+notNlQ9Cxrj4FvZ2DSkfzD2lfZvvpc3ooT8MXairh7c0lsCZAn/i1ydvssyqo
         UySwnsQzZTcx9tTHFbZHKmk9n/wKxJWzvDrMTvhLacByBO5NZxRx74mpeq5HSmrCV1T0
         IrXLMZ+kK2ypKFzR26xFNATz0ufOoKT4zZLnIfAuflWFneuqs5dGTyP1Dt0YpNsO3f0N
         IeQ4gdcqcQ3u5CADrxd4Yrs4SYfksZmSkrBVoMKatvYyWTjTnIA9zc1pcLYkFjr7iFAu
         D4j4pzp9EzBIMDY9sU5385SvL36f8T9tKB4FFElvWUbm9c3WS1113+7GxGin03X6XjO9
         mHbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733999444; x=1734604244;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=TrJ/D3rbPGQe4yyzZZUi7eBLXXQ8mzVAZH0cIW0dtWw=;
        b=KTnx2cVo6OMY3dVzKahqDHV4AiHevuyvqbTPDIc2sRnJqYT0vplvhbvjlIxeyEXxBt
         Yl9y5ypZVPkkXZbMTPYWg6aWqRW0WRT5wkZWMLIFlPF0xPn2/jYm5tDkpkz0jdptipLn
         vLbOBwADRpxHSDFvGLUC/PAj1lIex6x8Y3jrcBnBVKKHjEbRoypy3G4dgbpqwpVFnwjl
         VbYDLlnLrBLoHRwhb+sQV8vMEobYuO7xsGqRvdZCM0LPTX1AX4xgQx2ZBMsPTyfo+Nab
         9HP4gJr39JfP/g27VIpfQq6oUOoaJudd9cfHLB5PUMnG6r47anhgPrDFwkPKhW6VSPet
         ZEVQ==
X-Forwarded-Encrypted: i=1; AJvYcCULFevLrnKoiZGb6/ciDwYw+JN1FeU1AEhDvI4Rz8/riob4zv3AMMevopZtXiJuVKCvzNkyBsyRGqM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzTltd4MNO+IS6Y58sF5+bj6vhF79hwfdtMtaWS24RiQc3TnFFd
	Fslncdq2LlI6QryR4/ygMk6LD2Z963odrqBqFkYcjGSEgATVd5+mmijAH1Z3Jw==
X-Gm-Gg: ASbGncvJFPBSB6OrMuMZi8W3M+TQlVYvkYK2L2AlusXlJrZ7wsv3gh8eQoRq+Om/hro
	+KyeSE7PTQQw78nqzzpvvgXXK0HTDvePRsKEDYyKHvzqsPjg+jg0Fmti3u64fsGCJsXxSbNttxl
	uiG2t2simwNJwOODiusvsNtotjsuzejxJWzqcb1kNKbDfdjagOOR9jDLQDaDrOf1Pf7/ETJZ3bv
	aDbpIfWyatWAaHApqe52KeaW1rxJ7XHuTn7vzGc/BTTcJ16etq0JmqDiDgsLInrLRFAj1zSbDC+
	XsQS1KuVmI+8Qldw25sJhsr+lD3phIDBTSeW2JVkgg==
X-Google-Smtp-Source: AGHT+IFFxia2esVZkvufQzKTQuDr0Fvealab5JMGSd1y+R/I3V0BYmxzC95TtbVJ1vrMjqH/F2PsJQ==
X-Received: by 2002:a5d:6c6c:0:b0:385:df73:2f42 with SMTP id ffacd0b85a97d-3864cea3b4bmr3969864f8f.32.1733999444282;
        Thu, 12 Dec 2024 02:30:44 -0800 (PST)
Message-ID: <2bc2b412-b567-45ce-ae8b-4f22b6e212f1@suse.com>
Date: Thu, 12 Dec 2024 11:30:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/3] Add stack protector
To: Volodymyr Babchuk 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Samuel Thibault ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Bertrand Marquis ,
 Michal Orzel ,
 "xen-devel@lists.xenproject.org" 
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
  <87pllx3gib.fsf@epam.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: <87pllx3gib.fsf@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.12.2024 01:13, Volodymyr Babchuk wrote:
> Jan Beulich  writes:
>> On 11.12.2024 03:04, Volodymyr Babchuk wrote:
>>> Both GCC and Clang support -fstack-protector feature, which add stack
>>> canaries to functions where stack corruption is possible. This series
>>> makes possible to use this feature in Xen. I tested this on ARM64 and
>>> it is working as intended. Tested both with GCC and Clang.
>>>
>>> It is hard to enable this feature on x86, as GCC stores stack canary
>>> in %fs:40 by default, but Xen can't use %fs for various reasons. It is
>>> possibly to change stack canary location new newer GCC versions, but
>>> this will change minimal GCC requirement, which is also hard due to
>>> various reasons. So, this series focus mostly on ARM and RISCV.
>>
>> Why exactly would it not be possible to offer the feature when new enough
>> gcc is in use?
> 
> It is possible to use this feature with a modern enough GCC, yes. Are
> you suggesting to make HAS_STACK_PROTECTOR dependent on GCC_VERSION for
> x86 platform?

Only kind of. I remain yet to be convinced (or formally outvoted) on such
wanting to live in (only) Kconfig. I actually proposed a hybrid model [1].
But yes - some time of build time dependency.

Jan

[1] https://lists.xen.org/archives/html/xen-devel/2022-09/msg01793.html


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 10:32:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 10:32:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855689.1268526 (Exim 4.92)
	(envelope-from )
	id 1tLgUV-0006GZ-Ui; Thu, 12 Dec 2024 10:32:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855689.1268526; Thu, 12 Dec 2024 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 1tLgUV-0006GS-Rk; Thu, 12 Dec 2024 10:32:19 +0000
Received: by outflank-mailman (input) for mailman id 855689;
 Thu, 12 Dec 2024 10:32: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 1tLgUU-0006GK-IV
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 10:32:18 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 57a91ca0-b874-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 11:32:09 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5d3e9f60bf4so637803a12.3
 for ; Thu, 12 Dec 2024 02:32:14 -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
 a640c23a62f3a-aa6883f65c3sm570270766b.157.2024.12.12.02.32.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 02:32: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: 57a91ca0-b874-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733999534; x=1734604334; 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=iT4yOZy9bBBTLa23VcD8bCT6eHB0VIw2gFb58wLvNaY=;
        b=LP4Iqo0Yu7Kh7hEDhu5PLfuyuBgAU35cjnrYt4r72iATZuqSaGfHTaOqmylZ0vytXy
         +4PvEVVgZ3Sa1nMWVm7iH1SVGkUa01iqirSWftcRoUOd0/E2ft/1TGMJ0ojGHxGDWnEe
         qn9Zt9MolSU+2hOIzdz3CxOIOZnZGbiitK2pTIshdW3Ia8SNKATqfyusPQckqqcZKh5K
         cYs/MmnwAXQvmPKxP8zbGfjESsYNJiUDZnbu4ahocETlMsSk0anbNmTo9FVLfnAtSO3j
         yWR8GbObofOyFvr4e4TVQ6d7wxNv5Me8uctIYGEQl++RiRk51gx67tHgARner1ON85Ca
         ZvtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733999534; x=1734604334;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=iT4yOZy9bBBTLa23VcD8bCT6eHB0VIw2gFb58wLvNaY=;
        b=xH2cAWmtSHSetllW4T8GhRuljhM1M5Fe91DEql+KOF+dNdo7LUygKwCKmJ0hr8/Z2G
         FgOgTUzdBsxxZihMQUq/xeEMpQL74xgJlMgmNjz7tDzoJ0c7AQzyHdn1iK05IHAXC/vJ
         pcjMCYCqI+pAlrP2YnLYd3CkVSogBgP6iIu0qEv4TCvtEuKQHaF2D/Hb0OwVsZVf9uo3
         qUczq9AiprtBljNyClxLAWb+cxuQ3J/L+VBLow4SWqWkakoiHR+F+mWc0XUpZB/KOJ/4
         EGw9HheMgqBUkW9flRiAy86PKcv+4Eff8gu5H5HYCpAyXX/UY+UQCIzjxcZBy07IH4Q3
         Cf9g==
X-Forwarded-Encrypted: i=1; AJvYcCVyTpJY9ERgyF1mn9FUuRyJxO1aqgSTEHpvhCXap16poebvzn6apKLxY6RJcGAhH95S7AXyJiwxxJA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyhpMDkMJeudARu7kzZPlBpc6WpPMYK21ut1xXeWPOC9X2f/jXm
	+vbWhc8gnv8UKFRlB299//imv+if2+s3IAUuDoE4h13bJMPA5Ko3IqSsM9w4Xw==
X-Gm-Gg: ASbGncv2kOHTFtGzSLyXc3JWe/sIzgmp3XpS7W7Uhb6pFZwhOByCQndjeYnk4qMwsKv
	FNFtKp8m9dDRKHrmATU9/AOF3yAAm+8MCIVLTGv6EDSBTEMY5D2A+CYxCdhDvW6rlWERzytwFF4
	necRziIop4ceAqgucrCmgpGuRyVNyO0uAqbuLdv3BTQEUymCMtpZyCC23CfAxRt/LeOGZnJfEMx
	a8hgS0QEo4G3/W6DK0E4dLoMr1je8C/dTWq9dXaqh3jDDsPXPmXLhqm0XDoaKeIb5VsOiS6jFtE
	MhfpxWmNqs5iqeHatyDAMhgyMR/417bCGf2s5c7SXw==
X-Google-Smtp-Source: AGHT+IFUuk9sKqx0ukJ9vqsJVOugBcZnW02Jk+t/2I1mC1xX9cbjYFZlUUjKwgcvKyRiShlBQVJLSQ==
X-Received: by 2002:a17:906:31d2:b0:aa6:9461:a17e with SMTP id a640c23a62f3a-aa6c1cef49emr333485966b.40.1733999534454;
        Thu, 12 Dec 2024 02:32:14 -0800 (PST)
Message-ID: <26600bb0-93af-45b5-a341-5771bad844a1@suse.com>
Date: Thu, 12 Dec 2024 11:32:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: address violation of MISRA C Rule 11.1
To: Stefano Stabellini 
Cc: Alessandro Zucchelli ,
 consulting@bugseng.com, Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <7debd63f3900bad62bcbcc03081e4c04e6099135.1733914487.git.alessandro.zucchelli@bugseng.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 12.12.2024 03:27, Stefano Stabellini wrote:
> On Wed, 11 Dec 2024, Jan Beulich wrote:
>> On 11.12.2024 12:02, Alessandro Zucchelli wrote:
>>> Rule 11.1 states as following: "Conversions shall not be performed
>>> between a pointer to a function and any other type".
>>>
>>> Functions "__machine_restart" and "__machine_halt" in "x86/shutdown.c"
>>> and "halt_this_cpu" in "arm/shutdown.c" are defined as noreturn
>>> functions and subsequently passed as parameters to function calls.
>>> This violates the rule in Clang, where the "noreturn" attribute is
>>> considered part of the function"s type.
>>
>> I'm unaware of build issues with Clang, hence can you clarify how Clang's
>> view comes into play here? In principle various attributes ought to be
>> part of a function's type; iirc that's also the case for gcc. Yet how
>> that matters to Eclair is still entirely unclear to me.
>>
>>> By removing the "noreturn"
>>> attribbute and replacing it with uses of the ASSERT_UNREACHABLE macro,
>>> these violations are addressed.
>>
>> Papered over, I'd say. What about release builds, for example?
>>
>> Deleting the attribute also has a clear downside documentation-wise. If
>> we really mean to remove them from what the compiler gets to see, I think
>> we ought to still retain them in commented-out shape.
> 
> Another option would be to #define noreturn to nothing for ECLAIR builds ?

That again would feel like papering over things. Plus I don't know if that's
an option at all.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 10:35:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 10:35:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855703.1268535 (Exim 4.92)
	(envelope-from )
	id 1tLgXB-0006qy-B4; Thu, 12 Dec 2024 10:35:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855703.1268535; Thu, 12 Dec 2024 10: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 1tLgXB-0006qr-8U; Thu, 12 Dec 2024 10:35:05 +0000
Received: by outflank-mailman (input) for mailman id 855703;
 Thu, 12 Dec 2024 10:35: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 1tLgXA-0006ql-4A
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 10:35:04 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bee8d263-b874-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 11:35:03 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aa67333f7d2so61728166b.0
 for ; Thu, 12 Dec 2024 02: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
 a640c23a62f3a-aa68ef79bcdsm528053566b.205.2024.12.12.02.35.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 02: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: bee8d263-b874-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1733999703; x=1734604503; 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=DJumWVxw0xvXsyApHorOyLcvrgYJJTcjbrkIuT/FZyc=;
        b=d8Ae7zcJFc1FNhOR//axp8GUEhYOUUppLtdy21HVsX2xYiHTWsv83c+bE8VaaolppP
         lzDOI8QQ2gvpDXpyP9Nfmurcl+9+DxvOCN3ZxzAp3ybX+xTqwwKJZw6a/7W5i0X7/hki
         CNKEu7t9KR8RKIi2kx/X61VyH6b7jtUNEN9+D/z6kHhNxCYdP6TUCFQ1Ge4zgm8jLdcd
         cKlFr6IT42vkHFCd5FZHyrnOO8CDqck0G0ryMDInlWVidMRQs+DURikkCMGfFgfGA3i4
         zFTPYcH3ugYdOivMUHisUgZ63zeM3E1JrpRrtOuXLQcEzcR84ca8c8SC7NhyAwqWpNF+
         kuPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733999703; x=1734604503;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=DJumWVxw0xvXsyApHorOyLcvrgYJJTcjbrkIuT/FZyc=;
        b=QM6ir/Gc8a7oWQnUqJdyB3C8qchlSu+nqEZpHnpdmnFSq0P80WrRGolWnx6F+gJmck
         a6+J1jcx6ZqDi5iUG/cDDXSmGDh5shlaJpIivUaAFyfEaXv3ZbuXstb+Np/prMkG25Ft
         Y74m1DKIn81Bf3oZdESiPsKNhGo7kQAQdLDGr1FpZ8elQO1bTTPwJGqxUJ8IZj1XyfWr
         J5/DJsWwunu2yE3jlB2iY2kfVzG1CGNbNr4ZIIytUtQ0RgFYX7iHhwxJzCZOm97MJwhQ
         AIzegFXrLA1w3ewo1eQv25afWb2CBedcW0v1OTYTEWFSAhR4OounQ0fpKti3jbi8RLnb
         p/RA==
X-Forwarded-Encrypted: i=1; AJvYcCXfhs/Q+jHRB3+jeI5Vkgf3gyKeeZGX0opacD8n4b4lwx4Kt1EIaWUjanS9H5hjst+nC/YGh83t4lk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyu22Zb2xUXdEU4TxtwGgwQFEK/zFVxjKWVHg6c6tQpdo6rapcL
	gIGAdzC69lYz5PUjASq9MfIwlxVQ/ICjNfuBd9ngY3+diwdM5bBnatf/OYn03w==
X-Gm-Gg: ASbGncvcEFontafP7yV8VqxmTp10R+ucBTDyxjsPERtkDYBOjoSxm5rJm1m9pY1ahM1
	G/4pfWMZOhaGmSluPyANCnHo1EjPW5d32QMPdqbKU0bkJ+e/rdZBZwjumI1KyGPCirvA5JuZMOb
	4tbSdHq0Xs7+rUyucPM4/nwU2G7AOL66GktSyqlZrQF9ZOg0h3L9JQAgfNvXUEK3OV5ecTxKbuB
	NIfe7aGlQvzzCKsJnzAZndv7RVARZ2n2wADwCc/dG6YQqW4tG18sYUvhZ+oDrq8ZlZp3xZIzDoy
	lN8C+uOOKetOIXazuqy16pplL3nRB5KCaMQ8nIjsPw==
X-Google-Smtp-Source: AGHT+IHKB23+dBx0gLcsp6nP+GxrAFs42YNvfmKY0xoqrBaaSV4aizIXIpxCXUvB/m0j7LhPtCpc+g==
X-Received: by 2002:a17:906:318d:b0:aa6:8bb4:5035 with SMTP id a640c23a62f3a-aa6b11ed581mr596948766b.31.1733999702675;
        Thu, 12 Dec 2024 02:35:02 -0800 (PST)
Message-ID: <032d2e7b-7828-4a7f-a2d2-c2df46831507@suse.com>
Date: Thu, 12 Dec 2024 11:35:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] misra: add deviation for MISRA C Rule R11.1.
To: Stefano Stabellini 
Cc: Alessandro Zucchelli ,
 consulting@bugseng.com, Andrew Cooper ,
 Julien Grall , xen-devel@lists.xenproject.org
References: <8db58416ce215a3c5fdba8074dc21f32116e8a41.1733915076.git.alessandro.zucchelli@bugseng.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 12.12.2024 03:29, Stefano Stabellini wrote:
> On Wed, 11 Dec 2024, Jan Beulich wrote:
>> On 11.12.2024 12:05, Alessandro Zucchelli wrote:
>>> Rule 11.1 states as following: "Conversions shall not be performed
>>> between a pointer to a function and any other type".
>>>
>>> In "xen/common/bug.c", in order to get additional debug information,
>>> pointer "bug_fn_t *fn" in the data section is converted to a function
>>> pointer, which is then used to get such information.
>>
>> If the pointer converted pointed into the data section, it would fault
>> upon being used to call what it points to, for the lack of execute
>> permissions there.
>>
>> The change itself looks okay to me, but the description imo needs
>> updating, to be as precise as possible.
> 
> 
> What about:
> 
> In "xen/common/bug.c", in order to get additional debug information,
> pointer "bug_fn_t *fn" is converted to a function pointer, which is then
> used to get such information.
> 
> ?

This may do; I, however, was rather hoping for the description to be
extended rather than shrunk. E.g. '..., pointer "bug_fn_t *fn", obtained
by arithmetic on a pointer originating in the data section, is converted
to a function pointer, ...'

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 10:45:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 10:45:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855720.1268546 (Exim 4.92)
	(envelope-from )
	id 1tLghW-0001HF-BX; Thu, 12 Dec 2024 10:45:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855720.1268546; Thu, 12 Dec 2024 10:45: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 1tLghW-0001H8-8f; Thu, 12 Dec 2024 10:45:46 +0000
Received: by outflank-mailman (input) for mailman id 855720;
 Thu, 12 Dec 2024 10:45: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 1tLghU-0001H2-UR
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 10:45:44 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3cd56347-b876-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 11:45:43 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aa69251292dso83613266b.2
 for ; Thu, 12 Dec 2024 02:45:43 -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
 a640c23a62f3a-aa6975b1f27sm480935566b.113.2024.12.12.02.45.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 02:45: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: 3cd56347-b876-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734000343; x=1734605143; 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=aIQzt1yulu5i1a3ynxfDWvmaKZkJve7gh764YAZyV7s=;
        b=cphOBBfQIQ6Mq8JjBEsa4lAKcJvLp5LVbuQ+o7LwwbcdMFuN3AD5eGoA5ipVDObBdu
         vKzEA+q0C0Kaj1J6ishmHSXDJ++JZTLhBuDLJHbnDqiWgfMaHOGiv1i6HsbYO1Eq59uh
         sMj0c6a66doHktLQzAuXLifAUuIB1MIMru0a9sQabPvu/eDHCcN5qveFod9PYX/qqV3T
         3K5adM4ngIax1tc+trgDl6UrkhRn7UUUQ3BPKYTD0OXcOE2ICVIPAOCk/ikiMjALYsI1
         Y26+xepuuySfOz5Wm6CoaPaN7Fv0NoOBQYmsM5Dsop3mAvHUOHVTvZgUhBEuHTn5gRTB
         qqxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734000343; x=1734605143;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=aIQzt1yulu5i1a3ynxfDWvmaKZkJve7gh764YAZyV7s=;
        b=kT1Q4yRltsGccYAqyqxXzXANjanriZfs5SEr+UAQwVQaLHXikrIwYEdsbVJl8U6bV/
         nEwRACBkKGA2rIDGE9jl0X3ZM47SUOcrJ0doeM3GvKChjmuo2laXslREl6qzwgM+IDj9
         HbAixV9f33q5aVJInlK6gmUXgObKHVb3nWpSJXNYeztX9LANuaTu8YmzLXnkl0Z1k9In
         dIjfeDDEr1VObuCJQZEq4UwhEWQ3KPfvbFRp5dqnAGmdAYAhPbuTShe5hMHf/0mfd6Fb
         nLRzUzT/988+9LrPp/01a61xz/45tFuPmq2sYeWjDJa+uAmHvCsB5DBwEwZl9amd2ZDK
         pOjA==
X-Forwarded-Encrypted: i=1; AJvYcCU/jYMbNB2ItjbpO3RWE03FuOcH6+e41Y0g6n2i/UoVxk9V26vK4yvWky8EQYioTy8RtIGRE/3y3pw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxXtov1f/h0aYlrMm6Pyxb4Gt876WoOzpEsJygrA0JRDpAdnuBb
	+O1ZRvZRzKI+mILh8D7SC+QVOWDUstzWdlztaSFlZjV5nWx/RGazb/4U4X8jzNtDbKOEm045XdQ
	=
X-Gm-Gg: ASbGncsvowsrGdZcUPj2pTpbpz7fiYiTR7N/5sSRWoFHeazTVw0AiJn2Ooq9BPz3hfG
	71BwzijWAUiPn4KkqUyLDG8LT2h3+trTeWxyig5dMTWdBEwZwmmvOg1XLGmNOwGKxId4MATGmU9
	lwRFDkyHTtPUPnaeD+P4VkyH81a9C8VDhKxsIbLOFhIcrtxaLoz4R4t6N4vf9DGGzyBDAMrhxM/
	yM/zKMmL1th3Gk+WN1oJyxj1EZCga9diW6PSCkKsKZ6J1praJ79ue0gg8XxHQXEthjyhSnsMIOP
	xLlxCQUEjwsRGXC2lIg+/dOYnj+rvJ4Zl/4W894dzQ==
X-Google-Smtp-Source: AGHT+IH6qPGJrqZAXTDeBJOLiWxOQlMXaK11rD0YMqHBkMwQMjfAcbFIRHDNY2v3JI0QsXlJVRQHtg==
X-Received: by 2002:a17:907:7707:b0:aa6:5eae:7ed4 with SMTP id a640c23a62f3a-aa6b11912fbmr454748266b.13.1734000343404;
        Thu, 12 Dec 2024 02:45:43 -0800 (PST)
Message-ID: 
Date: Thu, 12 Dec 2024 11:45:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/3] xen: common: add ability to enable stack protector
To: Andrew Cooper 
Cc: Julien Grall , Stefano Stabellini
 ,
 "xen-devel@lists.xenproject.org" ,
 Volodymyr Babchuk 
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
 <20241211020424.401614-3-volodymyr_babchuk@epam.com>
 <0d04abb1-dae1-47d1-93e3-23d88399fa64@suse.com>
 <6b5326de-1ffb-4bac-b698-0e17435e89bc@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: <6b5326de-1ffb-4bac-b698-0e17435e89bc@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.12.2024 01:52, Andrew Cooper wrote:
> On 11/12/2024 8:16 am, Jan Beulich wrote:
>> On 11.12.2024 03:04, Volodymyr Babchuk wrote:
>>> --- a/xen/Makefile
>>> +++ b/xen/Makefile
>>> @@ -432,7 +432,11 @@ else
>>>  CFLAGS_UBSAN :=
>>>  endif
>>>  
>>> +ifeq ($(CONFIG_STACK_PROTECTOR),y)
>>> +CFLAGS += -fstack-protector
>>> +else
>>>  CFLAGS += -fno-stack-protector
>>> +endif
>> Personally I'd prefer if we consistently used the list approach we use
>> in various places, whenever possible:
>>
>> CFLAGS-stack-protector-y := -fno-stack-protector
>> CFLAGS-stack-protector-$(CONFIG_STACK_PROTECTOR) := -fstack-protector
>> CFLAGS += $(CFLAGS-stack-protector-y)
> 
> No - please stop this antipattern.
> 
> It saves 2 lines of code and makes the logic complete unintelligible.
> 
> I have a very strong preference for this patch to happen as Volodymyr
> presented, and without the double := replacing the more-legible ifeq.

Why "antipattern"? Surely there are cases where the list approach is
preferable. Surely there are cases where it ends up less legible, and
this may indeed be one such case. Yet then - where do you suggest to
draw the boundary?

>>> +void asmlinkage __stack_chk_fail(void)
>>> +{
>>> +    panic("Stack Protector integrity violation identified in %ps\n",
>>> +	  __builtin_return_address(0));
>> Again.
>>
>> Is panic() really the right construct to use here, though?
>> __builtin_return_address() will merely identify the immediate caller. A
>> full stack trace (from BUG()) would likely be more useful in identifying
>> the offender.
> 
> Well - we have to be careful, because the backtrace from here is
> specifically misleading in this case.
> 
> When this trips, it's either the caller itself that broke, or some
> sibling call tree which is rubble under the active stack now.
> 
> BUG() also comes with 0 information.

Not quite, the more that you suggest an alternative way to ...

> So, maybe we want a dump_execution_state() (to get the backtrace), and
> then this panic() which states it was a Stack Protection violation,
> which hopefully is enough of a hint to people to look in the sibling
> call tree.

... get register state and stack trace out. Which I'd be entirely fine
with.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 10:51:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 10:51:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855732.1268555 (Exim 4.92)
	(envelope-from )
	id 1tLgmx-0003pX-VC; Thu, 12 Dec 2024 10:51:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855732.1268555; Thu, 12 Dec 2024 10:51: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 1tLgmx-0003pQ-Rz; Thu, 12 Dec 2024 10:51:23 +0000
Received: by outflank-mailman (input) for mailman id 855732;
 Thu, 12 Dec 2024 10:51: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 1tLgmw-0003ig-0n
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 10:51:22 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 05c1d663-b877-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 11:51:21 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5d3d479b1e6so577722a12.2
 for ; Thu, 12 Dec 2024 02:51:21 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d3e7936581sm7176044a12.56.2024.12.12.02.51.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Dec 2024 02:51:20 -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: 05c1d663-b877-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734000680; x=1734605480; 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=ia5fGrLJCCZZbPn6F1drPOFD+LT9NslQOlZL2Wxfma0=;
        b=KEAtdNvtWfmQWzkiz51vJI560ySzBdCzGXztHnWePUaDlrWCGhrMTA39JpOJjMxDlU
         of1oI/TeImJBOYIoebpOdh9AiJMB77m8nraiOh8DzSTEd+u4cH/8T9wbctid9eLMbzxn
         sINf8hs7bEAbeKzXmY2bcZrUdLkYqSBr/0q90=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734000680; x=1734605480;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ia5fGrLJCCZZbPn6F1drPOFD+LT9NslQOlZL2Wxfma0=;
        b=Nrd2KyvRfmYEygkA+2FIlnSaQ0kz/3HaoE0WSw3pdtZwKPkGXk77FBtvVcQx8ldPj/
         CM4BTkyVnfiumEyAms+V0WBIypAK2bmdEF2YmSxwq8WhOj860d9B1Wzq0EmCnlj6e8M6
         4vYsvcVy7a/jzxqv1j+e9Ns96HxThfPdG0YrH1W/hiCQ2KXvCHsS7Ekan2dsYLkyUOna
         2EtVLF+kzL4YDdHtvfWQUC7es9CJoigOJsK6Setd/hrmbJTyGwBFJiptfWrqiCWsx36e
         yfNNk83UoeSWnAZKMdwqKyqqlK+8LdL9zXQkg4uQm1zMQxH6/T79Z4ImXCrOBkPdJLsG
         nh7g==
X-Gm-Message-State: AOJu0YyiO3oEkLjw1ZuYlTEns0NsG+XNujMcj0I/rMeSEKdSGRnjxrS1
	ui7r2DXh3mZ995IVoIgUY9jTqxJQLO1ZVub5+dz4/13fZ0GA2fCDL+GHYe0bYdY=
X-Gm-Gg: ASbGncse4yKDT22O+dpTwNy3XaV80gLy56gMXzXA0Y3r1nqLTVkYHzqma5AsHK4mKSF
	HWZqRhTKGFXyFukdTuU5qyqxFvwB9nkq5oNRfYhN25ZLhsESZcerpqW7r7gpUIje9ujdabvJykJ
	qKfNnpsmk1S7DgfPtts48Oqh9H4y5mX81M537zPIbuWEgCHIulcd1v7RuRY6/gtGC5BahbZXMB+
	JVYYyDifywA1+Ok4e9lS0AAEz/APDbU6IXSlaQu/fwonKuFN8DjCpTMGV+AVmGmlQ==
X-Google-Smtp-Source: AGHT+IFTRb2T6vw9Etj/GW7CZb6IcuT9AkFzoHjZ3J25ZUfnbKAA1rVsN1viT6swWWivdxgcUfH9Vg==
X-Received: by 2002:a05:6402:40c2:b0:5d0:cfad:f71 with SMTP id 4fb4d7f45d1cf-5d4fa1b2a38mr1309519a12.32.1734000680425;
        Thu, 12 Dec 2024 02:51:20 -0800 (PST)
Date: Thu, 12 Dec 2024 11:51:19 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 22/35] xen/console: introduce
 handle_keypress_in_domain()
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-22-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-22-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:41:52PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> With introduction of NS8250 emulator for x86, the logic of switching console
> focus gets more convoluted: HVM domain w/ NS8205 must be able to receive the
> physical console input for guest VM debugging.
> 
> Also, existing code does not honor `hardware_dom=` xen command line parameter
> (hardware domain ID does _not_ necessarily starts from 0).
> 
> Introduce handle_keypress_in_domain() to account for all scenarios of console
> input forwarding.
> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/drivers/char/console.c | 72 +++++++++++++++++++++++++++-------------------
>  1 file changed, 42 insertions(+), 30 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 6261bdb5a2ac1075bc89fa408c0fd6cfef380ae6..ce3639a4cdcda00ea63e3bf119bc3b242cbfdf6a 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -570,14 +570,16 @@ static void console_init_owner(void)
>      console_set_owner(domid);
>  }
>  
> -static void __serial_rx(char c)
> +static void handle_keypress_in_domain(struct domain *d, char c)
>  {
> -    switch ( console_owner )
> -    {
> -    case DOMID_XEN:
> -        return handle_keypress(c, false);
> +    int rc = 0;
>  
> -    case 0:
> +    /*
> +     * Deliver input to the hardware domain buffer.
> +     * NB: must be the first check: hardware domain may have emulated UART.
> +     */
> +    if ( d == hardware_domain )

is_hardware_domain(d)

> +    {
>          /*
>           * Deliver input to the hardware domain buffer, unless it is
>           * already full.
> @@ -590,34 +592,44 @@ static void __serial_rx(char c)
>           * getting stuck.
>           */
>          send_global_virq(VIRQ_CONSOLE);
> -        break;
> -
> -#ifdef CONFIG_SBSA_VUART_CONSOLE
> -    default:
> -    {
> -        struct domain *d = rcu_lock_domain_by_id(console_owner);
> -
> -        /*
> -         * If we have a properly initialized vpl011 console for the
> -         * domain, without a full PV ring to Dom0 (in that case input
> -         * comes from the PV ring), then send the character to it.
> -         */
> -        if ( d != NULL )
> -            vpl011_rx_char_xen(d, c);
> -        else
> -            printk("Cannot send chars to Dom%d: no UART available\n",
> -                   console_owner);
> -
> -        if ( d != NULL )
> -            rcu_unlock_domain(d);
> -
> -        break;
>      }
> +    /*
> +     * Deliver input to the emulated UART.
> +     */

For one-line comments you can use:
/* Deliver input to the emulated UART. */

I would however place the comment inside the `if` body.

> +    else if ( domain_has_vuart(d) )
> +    {
> +#if defined(CONFIG_SBSA_VUART_CONSOLE)
> +        rc = vpl011_rx_char_xen(d, c);
>  #endif

You can possibly make the preprocessor conditional also contain the
if condition itself?  As otherwise the if condition is dead code.

>      }
> -
> +    /*
> +     * Deliver input to the PV shim console.
> +     */
>      if ( consoled_is_enabled() )
> -        consoled_guest_tx(c);
> +        rc = consoled_guest_tx(c);
> +
> +    if ( rc && rc != -ENODEV )
> +        printk(KERN_WARNING "console input domain %d: not ready: %d\n",
> +               d->domain_id, rc);

XENLOG_ERR instead of KERN_WARNING, and use %pd to print domains, ie:

printk(XENLOG_ERR "%pd: delivery of console input failed: %d\n",
       d, rc);

And I wonder whether this should be printed just once per domain,
or whether the domain should be marked as not having a console
(is_console = false) after delivery of input keys failed.

Otherwise you could spam the console with such error messages on every
serial key press.

> +}
> +
> +static void __serial_rx(char c)
> +{
> +    struct domain *d;
> +
> +    if ( console_owner == DOMID_XEN )
> +    {
> +        handle_keypress(c, false);
> +        return;
> +    }
> +
> +    d = rcu_lock_domain_console_owner();
> +    if ( d == NULL )
> +        return;
> +
> +    handle_keypress_in_domain(d, c);

Is __serial_rx() the only caller of handle_keypress_in_domain() after
the series?  If so, I'm not sure it's worth placing this logic in a
separate function.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 10:58:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 10:58:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855743.1268565 (Exim 4.92)
	(envelope-from )
	id 1tLgtQ-0004YK-KH; Thu, 12 Dec 2024 10:58:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855743.1268565; Thu, 12 Dec 2024 10: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 1tLgtQ-0004YD-HV; Thu, 12 Dec 2024 10:58:04 +0000
Received: by outflank-mailman (input) for mailman id 855743;
 Thu, 12 Dec 2024 10:58: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 1tLgtO-0004Y7-Nl
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 10:58:02 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f49c2aea-b877-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 11:58:01 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aa6b4cc7270so60481166b.0
 for ; Thu, 12 Dec 2024 02:58: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
 a640c23a62f3a-aa6996487aesm467619066b.12.2024.12.12.02.58.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 02:58: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: f49c2aea-b877-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734001081; x=1734605881; 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=by+E7a3ewMGaFfF7TK+NdMjs7TBxHf743/QgL6QMkp8=;
        b=KS5NVZoN9a1m9Fhfa4WQKd8jXSzHsrSjgSrgPVumxzdIh+nh9CAKfJ/T/LSxM5kRax
         gyxb98rlvRZgzW6m9XXothYUzyQwHQbHhIcjA0+qkMOdWe0M5Q1VbbGzBUDguNNtUJSE
         CjyeSS6V0CyujtuFC80kMcjm/+WTsx1C6tBsljIsO0gndhZJsJJu89R0x7RkSsJuhrrc
         nFh747iscbwywEZ3IwxEsJ3P9FM0lgoBbosCdTbul5qZxDtxyDTHyFZnsHjKSNnZPzlm
         jeMIPrFvM7eAen66Z2g2NEvP2p89/cX4Cb1s6SbM5KujPNweITPdftT4ZBy6LdQXdXd/
         niHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734001081; x=1734605881;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=by+E7a3ewMGaFfF7TK+NdMjs7TBxHf743/QgL6QMkp8=;
        b=VrEkL1FyeFEcWt5b8QnUjYi3pi1uMqEqpIDTw+TJBQB/91xLLLlfMgHzWiBr73ojYp
         flUqmjfOoTK84Z7zMYDDragDtaWPIZ6+fnM2YFvh//swWv8tlUaFHXlFcEglpPI0lqAh
         BQZb90M0c3rCKEbI1RReqPJUaRYgSZ7vhhEFh5pgzHJhjsA+kgXOQadYAQh83JvPVhwV
         dD6nktSS4Gr2W8oS8FHTIgO70onWekZXjapDoBm6rlPc4CAcAWa/iWNqkn2hUhaCYKOy
         qVPPq5+aBDW27vzrQii/oWrqUDzWPPC7Wd/yVsCJ2JPAaAOMhN+RUiiafqiif7i5mfTC
         XegA==
X-Forwarded-Encrypted: i=1; AJvYcCUZ3vLfon9Cuee8NEed/J9DYJYEb8f5hz5GlUywUiI8J+mg6gvh5FTY6C73QzAbCbVg+S1q2WUu20s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwPzGHvlpx+cXYeBEUNZT5+l9Qh5TQLnV2RuxNTedOQ1EIojujX
	SStL0RSbQg0BGNF8rP1FqZihvtKCIIOIP/TnnPy0FQhCWhllbWBXlgZIjXCgTA==
X-Gm-Gg: ASbGnctSWilSI3Ef1+TDFJ1q35MC/0/cbOTxr+Pxmy3cIQnRKmTXc8zBGV4kQb+eO2L
	QvtDCuFpopYf4zyscXjU4SVxCASiNdkPQuoSX0rDmYZmtkWuri7Gwp0A+8D/kAAlRc3u8byGqKs
	qmPCXWvL9NHzC2OK0HdNX//LDxmKNuAfaA8r/tdTfHs7pp/7s6eGW1t27Xe6wL6WpZzMQRHfH8e
	X7KijywzJ1Uu4kZmX7SPuyr/+lPPZG1gh9sPrh91nzrZ2/cqh03DsmKNLt88DtTwlnbyg6YPpw2
	dGdN8rAsKgqKARAkMMPFJlc3OiiGupVedkwFhimJnA==
X-Google-Smtp-Source: AGHT+IGo+F7owOExUnkR0TgOEMLggooc9djHXbgdgKekbJsugQouE+Y1KBgBpJsRSOY4iZuTp4x+Dw==
X-Received: by 2002:a05:6402:34d6:b0:5d3:cf89:bd3e with SMTP id 4fb4d7f45d1cf-5d4fa1b2936mr1380060a12.30.1734001081186;
        Thu, 12 Dec 2024 02:58:01 -0800 (PST)
Message-ID: <55078aa2-7baf-40a4-80a2-1b083adff2f6@suse.com>
Date: Thu, 12 Dec 2024 11:58:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/3] xen: common: add ability to enable stack protector
To: Volodymyr Babchuk 
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 "xen-devel@lists.xenproject.org" 
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
 <20241211020424.401614-3-volodymyr_babchuk@epam.com>
 <0d04abb1-dae1-47d1-93e3-23d88399fa64@suse.com> <87bjxh3exi.fsf@epam.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: <87bjxh3exi.fsf@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12.12.2024 01:47, Volodymyr Babchuk wrote:
> Jan Beulich  writes:
>> On 11.12.2024 03:04, Volodymyr Babchuk wrote:
>>> --- a/xen/include/asm-generic/random.h
>>> +++ b/xen/include/asm-generic/random.h
>>> @@ -2,6 +2,11 @@
>>>  #ifndef __ASM_GENERIC_RANDOM_H__
>>>  #define __ASM_GENERIC_RANDOM_H__
>>>  
>>> +/*
>>> + * When implementing arch_get_random(), please make sure that
>>> + * it can provide random data before stack protector is initialized
>>> + * (i.e. before boot_stack_chk_guard_setup() is called).
>>> + */
>>>  static inline unsigned int arch_get_random(void)
>>>  {
>>>      return 0;
>>
>> What exactly will go (entirely) wrong if the comment isn't followed?
> 
> This will not cause immediate harm, but it will give false confidence to
> anyone who enables stack protector.
> 
> I'd prefer more substantial protection, but we can't even check if
> random generator is available in runtime. Taking into account that we
> potential can get 0 as result of RNG, we can't even put
> WARN_ON(!arch_get_random()) check.

Right, and hence 0 isn't strictly something that can be called "bad".
With at least some randomness one will of course observe a possible
problem at least across two or more runs. However, you don't call
arch_get_random() directly anyway, and get_random() has fallback code,
which is no more likely to return 0 than arch_get_random() is.

In fact this fallback code means get_random() will also use it when
arch_get_random() returns 0 as coming from an actual RNG. Which can
be considered bogus, as for a good random number source _every_
possible value ought to have equal probability of being returned.
Plus if we special-case 0, why not also special-case ~0? Or any other
number with only very few bits set/clear?

For the purpose of stack protector we may want to consider using a
mix of static pattern (not used elsewhere in the codebase) and random
number. The static pattern part would then want arranging such that
at least any value representing a valid address (within Xen alone)
won't match possible canary values.

>> (I'm afraid anyway that the comment living here is easy to miss.)
> 
> I didn't found a better place for it. Maybe you can suggest one?

I'm of two minds here really. Part of me wants this simply dropped. Yet
then some may deem this worthwhile information, except that then it
needs to live is a suitably exposed place. Just that I can't think of
any that would really fit.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 10:58:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 10:58:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855751.1268576 (Exim 4.92)
	(envelope-from )
	id 1tLgtq-000535-SU; Thu, 12 Dec 2024 10:58:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855751.1268576; Thu, 12 Dec 2024 10:58:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLgtq-00052y-Oy; Thu, 12 Dec 2024 10:58:30 +0000
Received: by outflank-mailman (input) for mailman id 855751;
 Thu, 12 Dec 2024 10:58: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 1tLgtq-0004Y7-9J
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 10:58:30 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20604.outbound.protection.outlook.com
 [2a01:111:f403:2412::604])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 04f48902-b878-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 11:58:29 +0100 (CET)
Received: from CH5P220CA0023.NAMP220.PROD.OUTLOOK.COM (2603:10b6:610:1ef::20)
 by BY1PR12MB8448.namprd12.prod.outlook.com (2603:10b6:a03:534::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.16; Thu, 12 Dec
 2024 10:58:23 +0000
Received: from CH1PEPF0000AD79.namprd04.prod.outlook.com
 (2603:10b6:610:1ef:cafe::6f) by CH5P220CA0023.outlook.office365.com
 (2603:10b6:610:1ef::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.14 via Frontend Transport; Thu,
 12 Dec 2024 10:58:22 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH1PEPF0000AD79.mail.protection.outlook.com (10.167.244.57) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Thu, 12 Dec 2024 10:58:22 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 12 Dec
 2024 04:58:21 -0600
Received: from [10.71.192.50] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 12 Dec 2024 04:58:19 -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: 04f48902-b878-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=KAUx+s/Mdfe29BcbSr0ywOAGhtszJNc1aQi4btqYAf0WFn0D5EYA1tC8UdELdva6lv2+gXAgdIdSDjiUpKo5edAMiHQRVOKQFVNCkk6N0PLBlvmd+g4izDoZlMVUDHaY73hQumhTrkAxTkKjLHr3UZEpXBUxhusxoO7G5tTitSuR821iiveymAP1nh1s/5GXh4VXa/85/zbrelz6TbsN6SZCPRixiy1+J7g9WPVcvF3kajS9tz0uAKD1JfUA1U2GZ/YvjJIDPO0wlKEHvy6n+v1x1chXqguaf7AIaVeMEo3TVWcmOrqwFXzpmpYawl/fNyK9Nes1j+CE+o/hdV/AhA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Gd2Ji8lDuZI4uC7Mx/ebEXSeEldyKS8kZ95rEBZDv4o=;
 b=pj6rXBwW0+bQsMa8bhz1uK5NjajnjZkhbEV0fuMh703ckjrtlNqRQr8yG0HfChdCC7iJv9WEojHPqsIwY804Qv6AUHiRV/5saONBwVKYwXY637QuX6Ush6srD7loW9ab8tz4lQZBcNdAGHOV4lDmTwMSM6EkaguUItWaOdHh5F2CxfffCIO0DthHMjcrnGGacSIED3epzh6MuhSz1N5zoCDW9T42qm7FSbGnFVUhsX/bguiejmPJpbpjX9YX5oE4qNmrFkNJmmmkSC1Xd1VQjIuoW4Xi0e5eYA7WvvrSMyRJJb/V2CHth4JByUby8sZCV4JbGUzSCiMFzNNMBKLW7Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Gd2Ji8lDuZI4uC7Mx/ebEXSeEldyKS8kZ95rEBZDv4o=;
 b=rdJbS2m7sUZUaoQoY+5q8Ot7hq0peDU9QoRzRsbdjhatZMJybNPy41Aguw4o75kJ/S8JnYXAHKgtvfCRpgcfpbhN6iwgCDdyblPBOaFcYc9LfWF4m8qMD407PP0gtXqyr/XVQfdyYEvo9qjyD576isdHpvkM6vru5FX3eBeTMsw=
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=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Thu, 12 Dec 2024 11:58:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6] xen/arm: Check for Static Heap feature when freeing
 resources
To: Luca Fancellu , 
CC: Penny Zheng , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Volodymyr Babchuk ,
	Andrew Cooper , Anthony PERARD
	, Jan Beulich ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Chen
	
References: <20241212093037.2916713-1-luca.fancellu@arm.com>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <20241212093037.2916713-1-luca.fancellu@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD79:EE_|BY1PR12MB8448:EE_
X-MS-Office365-Filtering-Correlation-Id: b76df4e4-eeec-4062-7582-08dd1a9be546
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|7416014|36860700013|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?WGFHa3pSa0VPVnhzNG9xYmlENjZxd1Vmc1QxM0FvaHd1WjhUamI4ZHBudjAv?=
 =?utf-8?B?SUUrdUZLdWx5OXY5dnJ0OXJUSkQ0QXZ0VzU2NngrKy9TL2NQN1QvODY2T2Ft?=
 =?utf-8?B?ckpPTGNKVnUxN2luemM2aXpsQkl4aFplWEpwNWpNRFQzcEZ5OEQyUm1FMkt1?=
 =?utf-8?B?V2FHK0x4blhiVmc5R3QrbVdwY2xOdkFWUC9VVnhlRzJwaDBNWFFEQ3lsdzEy?=
 =?utf-8?B?eFZoZUtqT1hpcFVBK2JyZkNwZ2NObEIycm5wdUp1K0NOOXR6MFczZmFzeFls?=
 =?utf-8?B?ZXR4aHo3RlN5RjMzbzJuSEg0c1ZvRG1kMFpLMXIxTHJLdFpVTTFnQzV5djVE?=
 =?utf-8?B?Uk9LUWwzYWhtbWZucC8vR2lFajRKUjRsdlJVdEd6VFhQMUpmcGlrOHdDL0Vn?=
 =?utf-8?B?U0s1eFlCWUZsVjZFcURJK1ZzeGhFUGpKU1FLUzBjSytIUWFNL0F2U1IrOHZZ?=
 =?utf-8?B?ZVJMRG9IMzBZREdnL1J6djBJWDFteVlMMDU2U3k4dzdMTUJ0VG50WnFIN0Rj?=
 =?utf-8?B?K1ZEa2w3czhobWVxbUhYYTdkTVcycXg3eFEzYWt6elUzenhETnIvT0s5aDVT?=
 =?utf-8?B?VXcwOGtwa0VDSG9jMWgxNmt0bTJ1S000QW5HcXFKWVFVb0NkSlF1VTc4S1Yr?=
 =?utf-8?B?TG9LaUNxV2VkdWZiZnRKQjJha2FzNGt6V1ZjUjBVeGQyeTZHWCtnbG1oYy95?=
 =?utf-8?B?R2R4Tyt3OStoemR0aEZXYUZQQXEvNUJ4S05ScGltNW10V3FXM0NHT1h3ZjZY?=
 =?utf-8?B?cU9xM2JTRktpemZ3aFRXTzRYSDlDbWRsMGFZTUdKeU5JeFdxREE5ZmhhbnhG?=
 =?utf-8?B?bkZBcUI0NVNTYjBvR09BQWtnYzJsekhKeG1HTStNOWNac1huTU9kQlhpQW9y?=
 =?utf-8?B?RENkMEYyTUVLaVhuMTloWDNYdjFoMlJxSmpUZTdINUFyMkdOVmc3UHhHb0pZ?=
 =?utf-8?B?dlFnOGVmVFhEU3RMcm01bW82K2JTUndIY1ZVTndwekY5WERMeWRQMXEweUVT?=
 =?utf-8?B?bmhPa096dGZtSUQ3S2dFT09IVWVpcktFWXVyRWFVOGk5VHRUNVRkd1J3K0xk?=
 =?utf-8?B?ZHBDdG5qekJWSW9wVzJFUUJpSVZTVi9uRjl6dzdpb3NFdmRLUmRPRjRxWG9t?=
 =?utf-8?B?ZTdrOUNDdHNWNSswUjZ0ZlloYUJ3aCtKMDFpRnhBZkpEQUpMYi9CMDNsYkoy?=
 =?utf-8?B?bVBldGlBNUk2bHQxRWtmU25tV0dWdUIraEpQN1RBV3NqTGZuazY3QjA3WGIv?=
 =?utf-8?B?YjAvTzdycVF6T0RYMHB6YmxuS1hJbmltdVhCTkFBYjhuZS82NkRoeTFoeVJx?=
 =?utf-8?B?d01ldDk5SjZ4c3k1aVN0Vk5KMFZnVGpmdU14NnNOL2RNd1VvdnBuN2M1d1pV?=
 =?utf-8?B?cXZxa25sR0Nibi9YbTNHS1c4VngvaUlKUWZDemdGZ3ZJbGRsTWhtU1dNRWhQ?=
 =?utf-8?B?UjZoQlN2UUxlUHphOU5wMlJCOEhGdGUvdjNaUnBXdFRRcVNlVTJjaUQyR3Fp?=
 =?utf-8?B?a3J0OFY2UDMrb1FKc0FSVldWNnVkREhCdnZuN0I2aUkvNmFheHRmQ2xORWpI?=
 =?utf-8?B?RnJYZFV1dzFhb1Y5Ry8rTTl6SHFsY0tvbzk0T29jbzVCemRHcEFhTHdNUVZO?=
 =?utf-8?B?aHRXUHJmcC9xbEpxalh4Yzg2WlhqL3JwcXhMc1FvYm1nUnkxVVROQ0o5dGpK?=
 =?utf-8?B?S1Z6QUtBREJIa28xZGVDbTQ2QkpXb2kyano4d3RKeG5jMno3N1JKUUtsN0hz?=
 =?utf-8?B?L0ZkTnhpMk9oTE9vMXVOYklkb2dkTk5pY0xpaGMxYSt2UUJuV252ZXVLdDln?=
 =?utf-8?B?bDZjRE9pYk5MT2x3Y01VZFRaVEhNVndENW8vUS9LS1lvblhmMmRrYW9vNWtZ?=
 =?utf-8?B?ZVFiWTUzZTVvMzQybDY5K01lVmc0UHhCNmVBWENIRW5mTnludEE1bUltYWZl?=
 =?utf-8?Q?YXFuN1QZy8aHYNiurShUaqLp76g/pnVW?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(36860700013)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Dec 2024 10:58:22.4550
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b76df4e4-eeec-4062-7582-08dd1a9be546
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000AD79.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR12MB8448



On 12/12/2024 10:30, Luca Fancellu wrote:
> 
> 
> From: Penny Zheng 
> 
> If the Xen heap is statically configured in Device Tree, its size is
> definite, so only the defined memory shall be given to the boot
> allocator. Have a check where init_domheap_pages() is called
> which takes into account if static heap feature is used.
> 
> Extract static_heap flag from init data bootinfo, as it will be needed
> after destroying the init data section, rename it to using_static_heap
> and use it to tell whether the Xen static heap feature is enabled.
> 
> Signed-off-by: Penny Zheng 
> Signed-off-by: Wei Chen 
> Signed-off-by: Luca Fancellu 
> ---
> Changes from v5:
>  - Drop Jan R-by due to the code changes
>  - Static heap is not dependent on static memory, so delete #ifdefs
>    for CONFIG_STATIC_MEMORY
> Changes from v4:
>  - Add R-by Jan
>  - Changed code to reduce nesting in discard_initial_modules (Julien)
> Changes from v3:
>  - Removed helper using_static_heap(), renamed static_heap variable
>    to using_static_heap and simplified #ifdef-ary (Jan suggestion)
> Changes from v2:
>  - Change xen_is_using_staticheap() to using_static_heap()
>  - Move declaration of static_heap to xen/mm.h and import that in
>    bootfdt.h
>  - Reprased first part of the commit message
> Changes from v1:
>  - moved static_heap to common/page_alloc.c
>  - protect static_heap access with CONFIG_STATIC_MEMORY
>  - update comment in arm/kernel.c kernel_decompress()
> ---
> ---
>  xen/arch/arm/arm32/mmu/mm.c       | 4 ++--
>  xen/arch/arm/kernel.c             | 7 ++++---
>  xen/arch/arm/mmu/setup.c          | 8 ++++++--
>  xen/arch/arm/setup.c              | 3 +++
>  xen/common/device-tree/bootfdt.c  | 2 +-
>  xen/common/device-tree/bootinfo.c | 2 +-
>  xen/common/page_alloc.c           | 3 +++
>  xen/include/xen/bootfdt.h         | 1 -
>  xen/include/xen/mm.h              | 2 ++
>  9 files changed, 22 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/arm32/mmu/mm.c b/xen/arch/arm/arm32/mmu/mm.c
> index 063611412be0..0824d61323b5 100644
> --- a/xen/arch/arm/arm32/mmu/mm.c
> +++ b/xen/arch/arm/arm32/mmu/mm.c
> @@ -199,7 +199,7 @@ void __init setup_mm(void)
> 
>      total_pages = ram_size >> PAGE_SHIFT;
> 
> -    if ( bootinfo.static_heap )
> +    if ( using_static_heap )
>      {
>          const struct membanks *reserved_mem = bootinfo_get_reserved_mem();
> 
> @@ -246,7 +246,7 @@ void __init setup_mm(void)
> 
>      do
>      {
> -        e = bootinfo.static_heap ?
> +        e = using_static_heap ?
>              fit_xenheap_in_static_heap(pfn_to_paddr(xenheap_pages), MB(32)) :
>              consider_modules(ram_start, ram_end,
>                               pfn_to_paddr(xenheap_pages),
> diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> index 293d7efaed9c..8270684246ea 100644
> --- a/xen/arch/arm/kernel.c
> +++ b/xen/arch/arm/kernel.c
> @@ -244,10 +244,11 @@ static __init int kernel_decompress(struct bootmodule *mod, uint32_t offset)
>      size += offset;
> 
>      /*
> -     * Free the original kernel, update the pointers to the
> -     * decompressed kernel
> +     * In case Xen is not using the static heap feature, free the original
> +     * kernel, update the pointers to the decompressed kernel
>       */
> -    fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
> +    if ( !using_static_heap )
You should get out of this function even earlier, before calculating addr and size that are only
used in fw_unreserved_regions.

> +        fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
> 
>      return 0;
>  }
> diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c
> index 9664e85ee6c0..8c87649bc88e 100644
> --- a/xen/arch/arm/mmu/setup.c
> +++ b/xen/arch/arm/mmu/setup.c
> @@ -341,8 +341,12 @@ void free_init_memory(void)
>      if ( rc )
>          panic("Unable to remove the init section (rc = %d)\n", rc);
> 
> -    init_domheap_pages(pa, pa + len);
> -    printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10);
> +    if ( !using_static_heap )
So here, you allow the init region mappings to be destroyed (above), yet ...

> +    {
> +        init_domheap_pages(pa, pa + len);
> +        printk("Freed %ldkB init memory.\n",
> +               (long)(__init_end-__init_begin) >> 10);
> +    }
>  }
> 
>  /**
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 2e27af4560a5..85f743a2c6ad 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -206,6 +206,9 @@ void __init discard_initial_modules(void)
>      struct bootmodules *mi = &bootinfo.modules;
>      int i;
> 
> +    if ( using_static_heap )
> +        return;
... here you would get out without calling remove_early_mappings() that today destroys early FDT
mappings. IMO you should allow to call remove_early_mappings().

With the remarks addressed:
Reviewed-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Thu Dec 12 11:06:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 11:06:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855771.1268586 (Exim 4.92)
	(envelope-from )
	id 1tLh1r-0007zZ-OH; Thu, 12 Dec 2024 11:06:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855771.1268586; Thu, 12 Dec 2024 11:06: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 1tLh1r-0007zS-LV; Thu, 12 Dec 2024 11:06:47 +0000
Received: by outflank-mailman (input) for mailman id 855771;
 Thu, 12 Dec 2024 11:06: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 1tLh1r-0007zI-0z
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 11:06:47 +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 28b3e416-b879-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 12:06:38 +0100 (CET)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-385eed29d17so246286f8f.0
 for ; Thu, 12 Dec 2024 03:06:43 -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-3878251dba9sm3669114f8f.98.2024.12.12.03.06.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 03:06: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: 28b3e416-b879-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734001603; x=1734606403; 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=9q1TIO9XEXl5wxz4pacBPWrkjhyyhVCZ/ilae7gYZHQ=;
        b=gRbnHhd7ulk+c2aBIUQt9GkbJDZoXgEL7WDR/8bXzQDsJtUx0xzsD2EflevQgeOg0i
         nHnnht3MGsR22Funty31+//Y6XU5LBCWlhXJyvDbivpGCW2Jom+KuBRVr+lV2/y0AMmx
         WENE8udLj8jriwmt+3552g3GhFXNbq1rnlPgGYO+Mff7wB/kKpCshXCMY7OfBtGvqH0Q
         e4Js/m8vjgMqz+RTaDLiorMF8uZem8p5iGR1JIBwBj5tVdnYsxAQDzu9Kmq2yFABhvmg
         K6yNg4JQCosd0QJqtlvlie1lTrtH4JOC0WHnhrmBQyt6aJlv0gWBTWDeNkrZxcaKABa6
         UtUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734001603; x=1734606403;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=9q1TIO9XEXl5wxz4pacBPWrkjhyyhVCZ/ilae7gYZHQ=;
        b=fh5DEEA7GtrHv/panjmtpd0k1uGVxFfcyVpAU5IMstM1qKo+sM79mnhwjAFvIpiZ4F
         x7ppYH0c8xR2CBaymxM/BDlupkblzzdg6jtJlhNJzwcD5efppUr6WXeV1RApYTJ2fIeC
         sNHQ4uuUAJqcSI0LFKSI0FJPQdnnlMPHjFPX6kWZajn2O5p0tlC/bjQGjPwwfm0gCjmY
         l9SYpCWsC1sfEZcKiBpWz8jyCOisL0hvTqwx19YZmKIxDnfIzEkSBuQn9wEkZE6fKpe3
         ziThyOdg9+2DlpgrONjlLp7N8MlIN1hqsx9VqngcA8K/0Y+EvcgD0Dm7+37xuV5kkSiL
         1okQ==
X-Forwarded-Encrypted: i=1; AJvYcCUUjlSk5eRqmn2sMBiipkym0ARVDpso3EsDJRs7M6xAq6tY226L7cUOQqm3vd3i0Ya9n5QeTct1+nM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwhA9a69bbXDEGtRaep94E6jQJMJfbokhFMW/A39oRP0UeCocxV
	B0Dhi+KhStm1eOP9+S6sKKgqjGTY5SCgRHYDq1Gp/ZFlfKaNGuHFWlpK/9JMJg==
X-Gm-Gg: ASbGncuOtop2v8y/n1ldnavJHV0yySLkND2paA9wxMDmW49GrCsLJ4DFeb4ETiNQzCk
	ZCaDgqL5dzYoxegR4t8wMwbRg1OXNPKM2CE8rkI52dlMgde9Ek1FpY4ppvAg1ORy8t0LCyH6Ct7
	JxPmtj+j3B4GCoxLchbA/k4sVt4ePiQFKci52IJ19L1NHdC6JRlLUGFTav3mZ+FVo1h3ojON1iC
	Xv+OGvxikX46XkwXql41TGdqehP2FCmf8xepIR+0ZTWuG/4oGHXmxp95e6DWvsgPFdOOTdiVq/a
	gCSFHHZJmH9C6NUiCvmWPN4xFB7FlH5iO3RZi/03Gw==
X-Google-Smtp-Source: AGHT+IHmkNR0XAQVTlDj3u/r6hlDW61dK4PKHL5CU1YpHRwdmprv/DKhapmAALyupWWdoLF3A8ROuw==
X-Received: by 2002:a05:6000:986:b0:386:3918:16a8 with SMTP id ffacd0b85a97d-3878768e1f5mr2547114f8f.13.1734001603084;
        Thu, 12 Dec 2024 03:06:43 -0800 (PST)
Message-ID: <3b0d3128-2501-4866-a2c5-36a1277956b1@suse.com>
Date: Thu, 12 Dec 2024 12:06:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 06/15] x86/hyperlaunch: introduce the domain builder
To: "Daniel P. Smith" 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-7-dpsmith@apertussolutions.com>
 
 <71d62f74-91d9-498f-80a7-d0dc01fb51da@apertussolutions.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: <71d62f74-91d9-498f-80a7-d0dc01fb51da@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.12.2024 13:36, Daniel P. Smith wrote:
> On 12/2/24 05:10, Jan Beulich wrote:
>> On 23.11.2024 19:20, Daniel P. Smith wrote:
>>> Introduce the domain builder which is capable of consuming a device tree as the
>>> first boot module. If it finds a device tree as the first boot module, it will
>>> set its type to BOOTMOD_FDT. This change only detects the boot module and
>>> continues to boot with slight change to the boot convention that the dom0
>>> kernel is no longer first boot module but is the second.
>>>
>>> No functional change intended.
>>>
>>> Signed-off-by: Daniel P. Smith 
>>> ---
>>>   xen/arch/x86/Makefile                    |  2 +
>>>   xen/arch/x86/domain_builder/Makefile     |  3 ++
>>>   xen/arch/x86/domain_builder/core.c       | 55 ++++++++++++++++++++++++
>>>   xen/arch/x86/domain_builder/fdt.c        | 38 ++++++++++++++++
>>>   xen/arch/x86/domain_builder/fdt.h        | 21 +++++++++
>>>   xen/arch/x86/include/asm/bootinfo.h      |  3 ++
>>>   xen/arch/x86/include/asm/domainbuilder.h |  8 ++++
>>>   xen/arch/x86/setup.c                     | 18 +++++---
>>>   8 files changed, 142 insertions(+), 6 deletions(-)
>>>   create mode 100644 xen/arch/x86/domain_builder/Makefile
>>>   create mode 100644 xen/arch/x86/domain_builder/core.c
>>>   create mode 100644 xen/arch/x86/domain_builder/fdt.c
>>>   create mode 100644 xen/arch/x86/domain_builder/fdt.h
>>
>> As I'm sure I indicated before: Dashes instead of underscores please in new
>> files' names.
>>
>>>   create mode 100644 xen/arch/x86/include/asm/domainbuilder.h
>>
>> Why is there no separator in this file's name?
> 
> Name was getting a bit long, but can add separator if desired.

Well, my desire is for the subdir and the header names to match up.
Personally I think that neater to achieve when both have a dash in the
middle.

>>> --- /dev/null
>>> +++ b/xen/arch/x86/domain_builder/core.c
>>> @@ -0,0 +1,55 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +/*
>>> + * Copyright (C) 2024, Apertus Solutions, LLC
>>> + */
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +
>>> +#include "fdt.h"
>>> +
>>> +void __init builder_init(struct boot_info *bi)
>>> +{
>>> +    if ( IS_ENABLED(CONFIG_DOMAIN_BUILDER) )
>>> +    {
>>> +        int ret;
>>> +
>>> +        switch ( ret = has_hyperlaunch_fdt(bi) )
>>> +        {
>>> +        case 0:
>>> +            printk("Hyperlaunch device tree detected\n");
>>> +            bi->hyperlaunch_enabled = true;
>>> +            bi->mods[0].type = BOOTMOD_FDT;
>>> +            break;
>>> +        case -EINVAL:
>>> +            printk("Hyperlaunch device tree was not detected\n");
>>> +            bi->hyperlaunch_enabled = false;
>>> +            break;
>>> +        case -ENOENT:
>>> +            fallthrough;
>>
>> No need for this.
> 
> I thought MISRA called for explicit fallthrough?

Only when there are statements between two case labels. Which ...

>>> +        case -ENODATA:

... isn't the case here.

>>> @@ -1277,9 +1278,12 @@ void asmlinkage __init noreturn __start_xen(void)
>>>                  bi->nr_modules);
>>>       }
>>>   
>>> -    /* Dom0 kernel is always first */
>>> -    bi->mods[0].type = BOOTMOD_KERNEL;
>>> -    bi->domains[0].kernel = &bi->mods[0];
>>> +    builder_init(bi);
>>> +
>>> +    /* Find first unknown boot module to use as Dom0 kernel */
>>> +    i = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
>>> +    bi->mods[i].type = BOOTMOD_KERNEL;
>>> +    bi->domains[0].kernel = &bi->mods[i];
>>
>> Better latch the result here into a separate local variable, for use ...
>>
>>> @@ -1466,8 +1470,9 @@ void asmlinkage __init noreturn __start_xen(void)
>>>           xen->size  = __2M_rwdata_end - _stext;
>>>       }
>>>   
>>> -    bi->mods[0].headroom =
>>> -        bzimage_headroom(bootstrap_map_bm(&bi->mods[0]), bi->mods[0].size);
>>> +    i = first_boot_module_index(bi, BOOTMOD_KERNEL);
>>> +    bi->mods[i].headroom =
>>> +        bzimage_headroom(bootstrap_map_bm(&bi->mods[i]), bi->mods[i].size);
>>>       bootstrap_unmap();
>>>   
>>>   #ifndef highmem_start
>>> @@ -1591,7 +1596,8 @@ void asmlinkage __init noreturn __start_xen(void)
>>>   #endif
>>>       }
>>>   
>>> -    if ( bi->mods[0].headroom && !bi->mods[0].relocated )
>>> +    i = first_boot_module_index(bi, BOOTMOD_KERNEL);
>>> +    if ( bi->mods[i].headroom && !bi->mods[0].relocated )
>>>           panic("Not enough memory to relocate the dom0 kernel image\n");
>>>       for ( i = 0; i < bi->nr_modules; ++i )
>>>       {
>>
>> ... in these two places?
> 
> I don't know if a local variable is need. I assume your suggestion is to 
> drop the first_boot_module_index() call,

The latter two of the three, yes.

> but thinking about it, not sure 
> why I kept the walk. A direct use of bi->domains[0].kernel could be used 
> without the intermediate variable while removing the call.

If that's possible, the even better.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 11:09:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 11:09:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855782.1268595 (Exim 4.92)
	(envelope-from )
	id 1tLh4m-00007a-5w; Thu, 12 Dec 2024 11:09:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855782.1268595; Thu, 12 Dec 2024 11:09: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 1tLh4m-00007T-2e; Thu, 12 Dec 2024 11:09:48 +0000
Received: by outflank-mailman (input) for mailman id 855782;
 Thu, 12 Dec 2024 11:09: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 1tLh4k-00007N-A6
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 11:09:46 +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 97b1611a-b879-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 12:09:45 +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 48C612111F;
 Thu, 12 Dec 2024 11:09:44 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 0A31D13508;
 Thu, 12 Dec 2024 11:09:44 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id UqyLAHjEWmfRLwAAD6G6ig
 (envelope-from ); Thu, 12 Dec 2024 11:09: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: 97b1611a-b879-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734001784; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=fNZopUEUX3FjPq3t2iAMdKTc1ZjqXNiFVd7H4qojjy8=;
	b=OQj3CuyfQJJpx09wy+3ULckJ4ZE7a5AzvuW7dFOCC0Ci7bfpXjSBMvpi0P+vUvVdl/rz6w
	v4IXwH4z6bSBGV0ai7paAkkhfB3cH6Vt654huuIv8ANMEHUhGV+NHC2oQSSyWeX1gv26MM
	dJkKSewNlko3slVFO+P9hRz1SLGPgSA=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734001784; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=fNZopUEUX3FjPq3t2iAMdKTc1ZjqXNiFVd7H4qojjy8=;
	b=OQj3CuyfQJJpx09wy+3ULckJ4ZE7a5AzvuW7dFOCC0Ci7bfpXjSBMvpi0P+vUvVdl/rz6w
	v4IXwH4z6bSBGV0ai7paAkkhfB3cH6Vt654huuIv8ANMEHUhGV+NHC2oQSSyWeX1gv26MM
	dJkKSewNlko3slVFO+P9hRz1SLGPgSA=
Message-ID: <8fb77778-b821-4e38-a835-54883ba14e4b@suse.com>
Date: Thu, 12 Dec 2024 12:09:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/xen/mmu: Increase MAX_CONTIG_ORDER
To: Jan Beulich ,
 Thierry Escande 
Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
References: <20241204171346.458105-1-thierry.escande@vates.tech>
 
 
 
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: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------FF0xBmAe6C9bSA00BHSlST3a"
X-Spam-Score: -5.19
X-Spamd-Result: default: False [-5.19 / 50.00];
	BAYES_HAM(-3.00)[100.00%];
	SIGNED_PGP(-2.00)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-0.99)[-0.990];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	NEURAL_HAM_SHORT(-0.20)[-0.996];
	MIME_BASE64_TEXT(0.10)[];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	RCVD_TLS_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	ARC_NA(0.00)[];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCPT_COUNT_FIVE(0.00)[6];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,imap1.dmz-prg2.suse.org:helo];
	HAS_ATTACHMENT(0.00)[]
X-Spam-Flag: NO
X-Spam-Level: 

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------FF0xBmAe6C9bSA00BHSlST3a
Content-Type: multipart/mixed; boundary="------------Po2XpOKQR0YFOAIlDgThNkfr";
 protected-headers="v1"
From: Juergen Gross 
To: Jan Beulich ,
 Thierry Escande 
Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Message-ID: <8fb77778-b821-4e38-a835-54883ba14e4b@suse.com>
Subject: Re: [PATCH] x86/xen/mmu: Increase MAX_CONTIG_ORDER
References: <20241204171346.458105-1-thierry.escande@vates.tech>
 
 
 
In-Reply-To: 
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------Po2XpOKQR0YFOAIlDgThNkfr
Content-Type: multipart/mixed; boundary="------------csyXRdVOfJV0c6HJdb4aU0L0"

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

T24gMTIuMTIuMjQgMTE6MjIsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxMS4xMi4yMDI0
IDE5OjIwLCBUaGllcnJ5IEVzY2FuZGUgd3JvdGU6DQo+PiBIaSBKYW4sDQo+Pg0KPj4gT24g
MDkvMTIvMjAyNCAxMTowNCwgSmFuIEJldWxpY2ggd3JvdGU6DQo+Pj4gT24gMDQuMTIuMjAy
NCAxODoxNCwgVGhpZXJyeSBFc2NhbmRlIHdyb3RlOg0KPj4+PiBXaXRoIGNoYW5nZSA5ZjQw
ZWM4NGE3OTcgKHhlbi9zd2lvdGxiOiBhZGQgYWxpZ25tZW50IGNoZWNrIGZvciBkbWENCj4+
Pj4gYnVmZmVycyksIHRoZSBkcml2ZXIgbXB0M3NhcyBmYWlscyB0byBsb2FkIGJlY2F1c2Ug
aXQgY2Fubm90IGFsbG9jYXRlDQo+Pj4+IGl0cyBETUEgcG9vbCBmb3IgYW4gYWxsb2NhdGlv
biBzaXplIG9mIH4yLDMgTUJ5dGVzLiBUaGlzIGlzIGJlY2F1c2UgdGhlDQo+Pj4+IGFsaWdu
ZW1lbnQgY2hlY2sgYWRkZWQgYnkgOWY0MGVjODRhNzk3IGZhaWxzIGFuZA0KPj4+PiB4ZW5f
c3dpb3RsYl9hbGxvY19jb2hlcmVudCgpIGVuZHMgdXAgY2FsbGluZw0KPj4+PiB4ZW5fY3Jl
YXRlX2NvbnRpZ3VvdXNfcmVnaW9uKCkgd2l0aCBhIHNpemUgb3JkZXIgb2YgMTAgd2hpY2gg
aXMgdG9vIGhpZ2gNCj4+Pj4gZm9yIHRoZSBjdXJyZW50IG1heCB2YWx1ZS4NCj4+Pj4NCj4+
Pj4gVGhpcyBwYXRjaCBpbmNyZWFzZXMgdGhlIE1BWF9DT05USUdfT1JERVIgZnJvbSA5IHRv
IDEwICg0TUIpIHRvIGFsbG93DQo+Pj4+IHN1Y2ggYWxsb2NhdGlvbnMuDQo+Pj4+DQo+Pj4+
IFNpZ25lZC1vZmYtYnk6IFRoaWVycnkgRXNjYW5kZSA8dGhpZXJyeS5lc2NhbmRlQHZhdGVz
LnRlY2g+DQo+Pj4+IC0tLQ0KPj4+PiAgIGFyY2gveDg2L3hlbi9tbXVfcHYuYyB8IDIgKy0N
Cj4+Pj4gICAxIGZpbGUgY2hhbmdlZCwgMSBpbnNlcnRpb24oKyksIDEgZGVsZXRpb24oLSkN
Cj4+Pj4NCj4+Pj4gZGlmZiAtLWdpdCBhL2FyY2gveDg2L3hlbi9tbXVfcHYuYyBiL2FyY2gv
eDg2L3hlbi9tbXVfcHYuYw0KPj4+PiBpbmRleCA1NWE0OTk2ZDBjMDQuLjdmMTEwNzQwZTFh
MiAxMDA2NDQNCj4+Pj4gLS0tIGEvYXJjaC94ODYveGVuL21tdV9wdi5jDQo+Pj4+ICsrKyBi
L2FyY2gveDg2L3hlbi9tbXVfcHYuYw0KPj4+PiBAQCAtMjIwMCw3ICsyMjAwLDcgQEAgdm9p
ZCBfX2luaXQgeGVuX2luaXRfbW11X29wcyh2b2lkKQ0KPj4+PiAgIH0NCj4+Pj4gICANCj4+
Pj4gICAvKiBQcm90ZWN0ZWQgYnkgeGVuX3Jlc2VydmF0aW9uX2xvY2suICovDQo+Pj4+IC0j
ZGVmaW5lIE1BWF9DT05USUdfT1JERVIgOSAvKiAyTUIgKi8NCj4+Pj4gKyNkZWZpbmUgTUFY
X0NPTlRJR19PUkRFUiAxMCAvKiA0TUIgKi8NCj4+Pj4gICBzdGF0aWMgdW5zaWduZWQgbG9u
ZyBkaXNjb250aWdfZnJhbWVzWzE8PE1BWF9DT05USUdfT1JERVJdOw0KPj4+DQo+Pj4gV2hp
bGUgbGFja2luZyByZXNwZWN0aXZlIGNvbW1lbnRhcnksIGJ1bXBpbmcgdGhpcyB2YWx1ZSBp
bW8gYWxzbyBuZWVkcyB0bw0KPj4+IHRha2UgaW50byBhY2NvdW50IFhlbiBpdHNlbGYsIGF0
IGxlYXN0IGNvbW1pdC1tZXNzYWdlLXdpc2UuIFRoZSBidW1waW5nIGlzDQo+Pj4gZmluZSBm
b3IgRG9tMCBpbiBhbnkgZXZlbnQuIEl0IGlzIGFsc28gZmluZSBmb3IgRG9tVS1zIHdpdGgg
dGhlIGRlZmF1bHRzDQo+Pj4gYnVpbHQgaW50byB0aGUgaHlwZXJ2aXNvciAob3JkZXJzIDEy
IGFuZCAxMCByZXNwZWN0aXZlbHkgZm9yIHg4NiBhbmQgQXJtKSwNCj4+PiB5ZXQgZXNwZWNp
YWxseSBmb3IgQXJtIChhbmQgaW4gdGhlIGZ1dHVyZSBQUEMgYW5kIFJJU0MtVikgYW55IGZ1
cnRoZXINCj4+PiBidW1waW5nIHdvdWxkIGJlIGxlc3Mgc3RyYWlnaHRmb3J3YXJkLg0KPj4N
Cj4+IFRoYW5rcyBmb3IgcG9pbnRpbmcgdGhpcyBvdXQuIE9uIHRoZSBYZW4gc2lkZSwgQ09O
RklHX0NUTERPTV9NQVhfT1JERVINCj4+IGFuZCBDT05GSUdfSFdET01fTUFYX09SREVSIHNl
ZW0gYmlnIGVub3VnaCBvbiBhbGwgYXJjaGl0ZWN0dXJlcy4gQnV0IEkNCj4+IHNlZSBDT05G
SUdfRE9NVV9NQVhfT1JERVIgc2V0IHRvIDkgKGFsc28gYWxsIGFyY2hzKS4gV29uJ3QgdGhh
dCBiZSBhDQo+PiBwcm9ibGVtIGZvciBkcml2ZXJzIHRyeWluZyB0byBhbGxvY2F0ZSBtb3Jl
IHRoYW4gdGhhdCBmcm9tIGEgZG9tVSA/DQo+IA0KPiBBIGRyaXZlciBhc3N1bWVzIGEgKHBo
eXNpY2FsKSBkZXZpY2UgdG8gYmUgaW4gdGhlIERvbVUsIGF0IHdoaWNoIHBvaW50IGl0DQo+
IGlzIENPTkZJR19QVERPTV9NQVhfT1JERVIgd2hpY2ggYXBwbGllcyAoUFQgc3RhbmRpbmcg
Zm9yIHBhc3MtdGhyb3VnaCkuDQo+IA0KPj4+IEhvd2V2ZXIgLSBkb2VzIHRoZSBkcml2ZXIg
cmVhbGx5IG5lZWQgdGhpcyBiaWcgYSBjb250aWd1b3VzIGNodW5rPyBJdA0KPj4+IHdvdWxk
IHNlZW0gZmFyIG1vcmUgZGVzaXJhYmxlIHRvIG1lIHRvIGJyZWFrIHRoYXQgdXAgc29tZSwg
aWYgcG9zc2libGUuDQo+Pg0KPj4gU2luY2UgdGhpcyB3b3JrcyBvbiBiYXJlIG1ldGFsIEkn
bSBhZnJhaWQgdGhlIGRyaXZlciBtYWludGFpbmVyIChtcHQNCj4+IGZ1c2lvbiBkcml2ZXIp
IHdpbGwganVzdCB0ZWxsIG1lIHRvIGZpeCBYZW4uDQo+IA0KPiBXZWxsLiBUaGUgYmlnZ2Vy
IHN1Y2ggYWxsb2NhdGlvbnMsIHRoZSBsYXJnZXIgdGhlIHJpc2sgdGhhdCBvbiBzeXN0ZW1z
DQo+IHRoYXQgaGF2ZSBiZWVuIHVwIGZvciBhIHdoaWxlIHN1Y2ggYWxsb2NhdGlvbnMgY2Fu
J3QgYmUgZnVsZmlsbGVkIGFueW1vcmUNCj4gZXZlbiBpbiB0aGUgYmFyZSBtZXRhbCBjYXNl
Lg0KDQpZZXMuIEkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIGp1c3Qgd29yayBhcm91bmQgdGhp
cyBpc3N1ZSB3aXRob3V0IGhhdmluZw0KZXZlbiB0cmllZCB0byBnZXQgdGhlIGRyaXZlciBm
aXhlZC4gSW4gY2FzZSB0aGV5IHJlZnVzZSB0byBjaGFuZ2UgaXQsIHdlDQpjYW4gc3RpbGwg
aW5jcmVhc2UgTUFYX0NPTlRJR19PUkRFUi4NCg0KDQpKdWVyZ2VuDQo=
--------------csyXRdVOfJV0c6HJdb4aU0L0
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-----

--------------csyXRdVOfJV0c6HJdb4aU0L0--

--------------Po2XpOKQR0YFOAIlDgThNkfr--

--------------FF0xBmAe6C9bSA00BHSlST3a
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/Ey8FAmdaxHcFAwAAAAAACgkQsN6d1ii/Ey/Q
ZggAh7DLKM49C60+ARA2YJ6AK6b0WPJPuL4Xq2TumiiCZjD6Sh3YaXwHNOv7qj/0u4LxGqBGPdn3
EoGm0rgy+XJvn6XJ3flx+EFC0wgY+O3KiCmLq0GaVq+RE+HIea6hL0A0fLDJG8OoLRUQPwzHDoO1
g7trRSuCBXclz9QiKUHfp8FIKca/juwwnSsymjhQD6ho9gdEp8MCT3N8P3vZAaB2wxae1l3EliL5
PdaAh0+j2VNJs+heMAQGKcz1Zt9yRYRLiu4elzUvquAYgB1RMiklVbeEFcpYGsjUxWjFFcgBpv1W
bSKw9EGQTO+G4DfPFoU/0h5M7G8TPGg3iIv9qYdOvA==
=wllM
-----END PGP SIGNATURE-----

--------------FF0xBmAe6C9bSA00BHSlST3a--


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 11:26:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 11:26:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855798.1268606 (Exim 4.92)
	(envelope-from )
	id 1tLhKO-00059h-Ge; Thu, 12 Dec 2024 11:25:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855798.1268606; Thu, 12 Dec 2024 11:25: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 1tLhKO-00059a-Cv; Thu, 12 Dec 2024 11:25:56 +0000
Received: by outflank-mailman (input) for mailman id 855798;
 Thu, 12 Dec 2024 11:25: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 1tLhKN-00059U-6p
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 11:25:55 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d5c715d3-b87b-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 12:25:48 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5d4e2aa7ea9so876425a12.2
 for ; Thu, 12 Dec 2024 03:25:52 -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
 a640c23a62f3a-aa657abb2fbsm804438366b.128.2024.12.12.03.25.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 03:25: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: d5c715d3-b87b-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734002752; x=1734607552; 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=qFPq8rKVGUuN+3GpuxpNkTnkf4SZpT0mkh7MtnBixjU=;
        b=O1WiEy46IBq5IkijiuOJ3yEQBYwBWCA94cf0jFWZ2MjDnO0iz2cq679Mu+0Xzjali5
         SXIjrXMn8RxSNXE56GMsGeknb870oicsixMCD0h97NuRYT52+KxFJ9Zm8WMrigTHOG7O
         RucsalXFqA5FGMq4/UZxCABOH56bo/5/n6W5wy1euR+1oP+ZAUPWv1Ifz5FoS6hq7UNT
         2ClJXOCn+e5PpVJJt04NAM36RLTritNZI0TALdyHCIbUlUxenp6lIxIfyL8JODAzu0+y
         ZH3MmLCOhK24V2ns1VYKJb+842Dmahbo+nbEoC/BUkkH85xwudsJkFxrsbx+eUGVGJ/R
         uYPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734002752; x=1734607552;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=qFPq8rKVGUuN+3GpuxpNkTnkf4SZpT0mkh7MtnBixjU=;
        b=vsy2O4gwMopDbQr56Ca4M6IQFwHcg/APWHJDSakOf0Aqw6PEpRH0oc4t27/wpuwbbb
         e045d7EwIkTTohaaH7VYDI4bitfvxOX0KszRj/f076Nyzy0+o6zaqC0Ed9DEWT6mXa6f
         KDoJ9fAo6YTiY2uI5DvO9En/pe4+P98AEom2zumZ4kbvj6fCw1JgD4f4QLd4xLj9a3Lo
         6BR4OTZx8KcxeYobqAT8HcUXqRvjV7KxU5iztdFedPBRibtDnIcwOjDqKqWluy4gy5Cm
         GuVSFGzJfq67GDZsJxux3JPQf3uoO8dYKZb4dQic5+bDBQls/sod1iwe2VaC/XQMOl3G
         36nA==
X-Forwarded-Encrypted: i=1; AJvYcCVR3V/b0/xvkPfAgtdCTjYIHWa8+i3YFe+82kSCZF2Tk792FiUQgOWMjyJUBbn400D/UFreypVSLbY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzXUzNJkWeEyDJx0eigqI/UgJASbCpMRFgExJQsn6J5IzvzODba
	4BQgqgybH432skiHX45wmni4Oz690FraCknlbIn1jpxi62hojYNrpAstOb2M+w==
X-Gm-Gg: ASbGncsck/4T101xX0W8YR5A6OZWwQVdlK82kLwSnSF2lVP8oKdSN8LscT6Z4BFvufD
	0Fh0Jgb2J3V7/QDM1z5QdBrZxylwMzNfs9E0oN/uPwLmyhVnSbAAIcQ1oCJj3o9eQdZwd3eExrJ
	LhWBpUHs8R5+Oid2pd5fHnY656PK3nHoQAPCvB1rLQuBPMkMIN9Rsxh87rCB9QSfGlYZA2FPLkZ
	mBAJ680WtFSuKRjcdGvuqLm09PsqteJv/M5BaR95QpXV14n4baHrL8gMfkNUMLR6c54qUkQojFP
	hAlqwFJvgnjoCGmZRGjIllU2DeuDSb+FKB2LRNxfFQ==
X-Google-Smtp-Source: AGHT+IFdA2i+dXeQCNHkpAvhiPTXjDW8HN1buKKiehnTX9lyBY4AzY/DLH/wxWwGXkITqTMR9QGjvQ==
X-Received: by 2002:a17:907:7628:b0:aa6:824c:4ae5 with SMTP id a640c23a62f3a-aa6c1d131d8mr331515966b.56.1734002752329;
        Thu, 12 Dec 2024 03:25:52 -0800 (PST)
Message-ID: <361c68de-eda8-49f7-a743-ddd4ad63a0ff@suse.com>
Date: Thu, 12 Dec 2024 12:25:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 08/15] x86/hyperlaunch: locate dom0 kernel with
 hyperlaunch
To: "Daniel P. Smith" 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-9-dpsmith@apertussolutions.com>
 <91e6d4e7-b4ff-4e13-8814-95eaac891cf4@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.12.2024 16:41, Daniel P. Smith wrote:
> On 12/2/24 06:53, Jan Beulich wrote:
>> On 23.11.2024 19:20, Daniel P. Smith wrote:
>>> Look for a subnode of type `multiboot,kernel` within a domain node. If found,
>>> process the reg property for the MB1 module index. If the bootargs property is
>>> present and there was not an MB1 string, then use the command line from the
>>> device tree definition.
>>
>> Why specifically MB1?
> 
> Because Xen converts MB2 into an MB1 chain very early in the entry 
> points that take MB2. By the time HL code is executed, it will only ever 
> see a list of MB1 modules.

Yet that's all Xen's internal representation, which merely is kind of
originating from MB1. That origin is, afaict, irrelevant here, and is
instead, imo, confusing.

>>> --- a/xen/arch/x86/domain_builder/fdt.c
>>> +++ b/xen/arch/x86/domain_builder/fdt.c
>>> @@ -14,6 +14,122 @@
>>>   
>>>   #include "fdt.h"
>>>   
>>> +static inline int __init fdt_get_prop_as_reg(
>>
>> What does "reg" stand for here?
> 
> Device Tree defines a two field "prop-encoded=array" property type 
> called reg.

Okay, this explains where you took it from, yet I remain curious what it
actually stands for. Just from the letters I would derive "register", yet
that seems unlikely here.

>>> +    const void *fdt, int node, const char *name, unsigned int ssize,
>>> +    unsigned int asize, uint64_t *size, uint64_t *addr)
>>> +{
>>> +    int ret;
>>> +    const struct fdt_property *prop;
>>> +    fdt32_t *cell;
>>> +
>>> +    /* FDT spec max size is 4 (128bit int), but largest arch int size is 64 */
>>> +    if ( ssize > 2 || asize > 2 )
>>> +        return -EINVAL;
>>> +
>>> +    prop = fdt_get_property(fdt, node, name, &ret);
>>> +    if ( !prop || ret < sizeof(u32) )
>>> +        return ret < 0 ? ret : -EINVAL;
>>> +
>>> +    /* read address field */
>>> +    cell = (fdt32_t *)prop->data;
>>> +
>>> +    if ( asize == 1 )
>>> +    {
>>> +        uint32_t val;
>>> +        fdt_cell_as_u32(cell, &val);
>>> +        *addr = (uint64_t)val;
>>
>> No need for a cast here nor ...
>>
>>> +    }
>>> +    else
>>> +        fdt_cell_as_u64(cell, addr);
>>> +
>>> +    /* read size field */
>>> +    cell += asize;
>>> +
>>> +    if ( ssize == 1 )
>>> +    {
>>> +        uint32_t val;
>>> +        fdt_cell_as_u32(cell, &val);
>>> +        *size = (uint64_t)val;
>>
>> ... here?
> 
> No the compiler does not need the cast, placed to remind readers what 
> was being done. Can/will drop.
> 
>>> +    }
>>> +    else
>>> +        fdt_cell_as_u64(cell, size);
>>> +
>>> +    return 0;
>>> +}
>>
>> This whole function reads very much like a library one. Does it really need
>> adding here, rather than to the FDT library code we already have? In any
>> event there's nothing x86-specific about it, afaics.
> 
> This is where it gets complicated. Most of the higher order functions 
> exposed by xen/device_tree.h are written to work with FDT indexing 
> structures, referred to as the unflattened tree. Deconflicting the mixed 
> use of FDT and FDT index in device_tree.h is beyond the scope of this 
> series.

Going that far also wasn't my request. Yet it's still library-like code,
which seems odd to introduce as x86-specific when later it may very well
want using by other architectures as well. If the FDT library code isn't
a good place, then put it somewhere under xen/lib/?

>>> +                                  &size, &addr);
>>> +    /* An FDT error value may have been returned, translate to -EINVAL */
>>> +    if ( ret < 0 )
>>> +        return -EINVAL;
>>> +
>>> +    if ( size != 0 )
>>> +        return -EOPNOTSUPP;
>>
>> Not knowing much about DT: What does 0 represent here?
> 
> The libfdt code treats 0 as a valid value, whether zero is a valid value 
> is driven by the contextual usage of the property.

And 0 is the _only_ valid value here? Another comment may be on order, to
at least briefly indicate why this is.

>>> +    if ( addr > MAX_NR_BOOTMODS )
>>> +        return -ERANGE;
>>> +
>>> +    /*
>>> +     * MAX_NR_BOOTMODS cannot exceed the max for MB1, represented by a u32,
>>> +     * thus the cast down to a u32 will be safe due to the prior check.
>>> +     */
>>> +    return (int)addr;
>>
>> Comment and cast contradict one another. DYM u32 (really: uint32_t), or plain
>> int? If you mean to return a plain int (for the sake of the -errno values
>> further up), MAX_NR_BOOTMODS needs to stay below 2**31.
> 
> Good point, we cannot artificially impose 2^31 limit when 2^32 is the 
> legitimate upper bound supported by the MB1 protocol. Even if that value 
> is impractical. At the same time, it is beneficial to be able to 
> communicate failures along with some delineation of the failure. Let me 
> think about this, and in the meantime suggestions are welcomed.

    BUILD_BUG_ON(MAX_NR_BOOTMODS > INT_MAX);

deferring the thinking about the "bigger than this" aspect until a (perhaps
much) later time?

>>> +static int __init process_domain_node(
>>> +    struct boot_info *bi, void *fdt, int dom_node)
>>> +{
>>> +    int node;
>>> +    struct boot_domain *bd = &bi->domains[bi->nr_domains];
>>> +    const char *name = fdt_get_name(fdt, dom_node, NULL);
>>> +    int address_size = fdt_address_cells(fdt, dom_node);
>>> +    int size_size = fdt_size_cells(fdt, dom_node);
>>> +
>>> +    if ( address_size < 0 || size_size < 0 )
>>> +    {
>>> +        printk("  failed processing #address or #size for domain %s)\n",
>>> +               name == NULL ? "unknown" : name);
>>> +        return -EINVAL;
>>> +    }
>>> +
>>> +    fdt_for_each_subnode(node, fdt, dom_node)
>>> +    {
>>> +        if ( fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
>>> +        {
>>> +            int idx = dom0less_module_node(fdt, node, size_size, address_size);
>>> +            if ( idx < 0 )
>>> +            {
>>> +                printk("  failed processing kernel module for domain %s)\n",
>>> +                       name == NULL ? "unknown" : name);
>>> +                return idx;
>>> +            }
>>> +
>>> +            if ( idx > bi->nr_modules )
>>> +            {
>>> +                printk("  invalid kernel module index for domain node (%d)\n",
>>> +                       bi->nr_domains);
>>> +                return -EINVAL;
>>> +            }
>>> +
>>> +            printk("  kernel: boot module %d\n", idx);
>>> +            bi->mods[idx].type = BOOTMOD_KERNEL;
>>> +            bd->kernel = &bi->mods[idx];
>>> +        }
>>> +    }
>>
>> What if you find two?
> 
> No different than if someone accidentally duplicated the module line for 
> the kernel in grub.cfg. It's a violation of the boot convention with the 
> resulting behavior being indeterminate, which may or may not result in 
> failure/panic when the domain attempts to boot. It might be worth adding 
> a warning if a duplicate kernel entry is detected. It is possible that 
> such a configuration would boot if it was a duplicate paste situation. 
> So I would not feel right panicking, when there is a possibility that 
> the configuration could boot.

I agree with not panic()ing, and I didn't mean to ask that you do so. A
warning ought to be enough indeed.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 11:31:26 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 11:31:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855814.1268616 (Exim 4.92)
	(envelope-from )
	id 1tLhPf-0007XF-6n; Thu, 12 Dec 2024 11:31:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855814.1268616; Thu, 12 Dec 2024 11:31: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 1tLhPf-0007X8-2i; Thu, 12 Dec 2024 11:31:23 +0000
Received: by outflank-mailman (input) for mailman id 855814;
 Thu, 12 Dec 2024 11:31: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 1tLhPe-0007X2-QW
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 11:31:22 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 994550c4-b87c-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 12:31:16 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5d414b8af7bso956892a12.0
 for ; Thu, 12 Dec 2024 03:31:20 -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
 a640c23a62f3a-aa653a95e90sm798695766b.173.2024.12.12.03.31.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 03:31:20 -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: 994550c4-b87c-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734003080; x=1734607880; 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=7amF25cdvQu/McBE34fVxW5BL8pahhXcLQJF3ts/xS4=;
        b=cEJZ5+X8gb3vudBqVa+90nw/UYPcSe6QsG/YG6hPEb7e5xhgeaEh6TE0MUo6RALSpV
         CY2a74vS9znEvCa0PllTNyVIH0iJKVTa7eAHZStJwNRzrQJSkbkxSkd2s9y4DvP6/P45
         2uTXeOsNczhG/acOqJqkrz35i+IpBRLrVqjSt9nYEht9cYIpBpsGVMUphRcywBeQizjR
         956b98wu13RV17e3qVyX2oxP6gt2vcE5H2jpoa5zB0KoScra7sjWKYW51OIrgK3i962N
         YzffrFRIXtp5+V3R0cPWmPmFj7Sv75O3vDIV73d0iV0Lvm6SYuRwq/XhNHs0MLnQ9YH/
         pheA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734003080; x=1734607880;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7amF25cdvQu/McBE34fVxW5BL8pahhXcLQJF3ts/xS4=;
        b=d9I0coalDqvqtvIZvbeJCGHna7m/8cSd7VzfojWzlfKu2iXBcUts9De4vXhozb3HQ8
         Gl6fae/CH7MD7Bhossjw6/cWFTDgW1dbFKaJBiNE0cH0wLvcvrenxJ9Ht0YG7Ve8nfbl
         jRpHbARf3FriY8Cl4gP5GRKkNeMO8T8ZGT+NTUraZ5adkTtm6GD9S8Kln+KPri+v+SAF
         Vr0UBH+sRLxAtm0pgrvdalTqc3g4ulq0yAsSjt8Mlm5SRLafoW9iAKp6AtHdTCUilnmr
         O0enuBvE27n27HCQ0h8vCMI3H7FJk5F2q7Y8s164Pi48ftVChzj9U2XZuDvqow24UYyY
         hc1g==
X-Forwarded-Encrypted: i=1; AJvYcCX+mHMgxLRQzkyb1iJpV6bnKE5mzbjoMtfbY/FkaRtXJQojVX5sxg8ITh6zWIP2auOMnkCgyleqIIg=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz4n9IWv0PRH2GQDEWa2BzQAEVBC+H0+G9EOz3CuXL6LY5o2k55
	2IyNEg3T0/+KHKsDXYw4LgvQ8R/a/9JwnLBLwS8vVcnHwuprxIwdppPSVBVQWg==
X-Gm-Gg: ASbGncvRI6moQTD+3xe4KZOwqKZ6vU0j+FXbFgEFpYeN+3yjuuuaQDXdznNfWftSuwE
	YjG/veGWYQK2ytgMxaJVDQWE8Vfro0JXBTdvVHwSlU1CI7SrxJY7goBN8EfpYVt9EmtvaagKptW
	IFuFZEsnAg8RHkimC7TGTiSVPoxIl7AS0IFKIye8iImNTpaxeEobWZPSfWDhNBFy2akHxvqEMFU
	LbNyLAl8P6v2o9m+qFbxNqfn04irJBsg/ST7KSZSboXGawTmU7RLIhHDtTu0ygpn++AgccxeePq
	EKdoVuKkXcwhXl295mjTtg5LDN99Ebr0/chDtbpWSQ==
X-Google-Smtp-Source: AGHT+IG97GlLKcTMGVsO557G17EWUlb8Gm7OrFZWZ8VS4UGIKYX3VjIFOAyWTMmeq7j1hLisqpRYtA==
X-Received: by 2002:a17:906:7307:b0:aa6:32f9:d1a7 with SMTP id a640c23a62f3a-aa6c1cf1b1fmr502292766b.38.1734003080415;
        Thu, 12 Dec 2024 03:31:20 -0800 (PST)
Message-ID: <9a1589bc-82d9-42b1-a200-7b6a61035eec@suse.com>
Date: Thu, 12 Dec 2024 12:31:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 12/15] x86/hyperlaunch: specify dom0 mode with device tree
To: "Daniel P. Smith" 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-13-dpsmith@apertussolutions.com>
 <294035fd-45c9-4c59-a5b7-bc1ebed90e47@suse.com>
 <029011a0-0b7c-48e2-a98a-845588bbc7bf@apertussolutions.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: <029011a0-0b7c-48e2-a98a-845588bbc7bf@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.12.2024 18:48, Daniel P. Smith wrote:
> On 12/2/24 07:06, Jan Beulich wrote:
>> On 23.11.2024 19:20, Daniel P. Smith wrote:
>>> --- a/xen/arch/x86/domain_builder/fdt.c
>>> +++ b/xen/arch/x86/domain_builder/fdt.c
>>> @@ -141,6 +141,25 @@ static int __init process_domain_node(
>>>               bd->domid = (domid_t)val;
>>>               printk("  domid: %d\n", bd->domid);
>>>           }
>>> +        if ( match_fdt_property(fdt, prop, "mode" ) )
>>> +        {
>>> +            if ( fdt_prop_as_u32(prop, &bd->mode) != 0 )
>>> +            {
>>> +                printk("  failed processing mode for domain %s\n",
>>> +                       name == NULL ? "unknown" : name);
>>> +                return -EINVAL;
>>> +            }
>>> +
>>> +            printk("  mode: ");
>>> +            if ( !(bd->mode & BUILD_MODE_PARAVIRT) ) {
>>> +                if ( bd->mode & BUILD_MODE_ENABLE_DM )
>>> +                    printk("HVM\n");
>>> +                else
>>> +                    printk("PVH\n");
>>> +            }
>>> +            else
>>> +                printk("PV\n");
>>
>> Oh, and: What about BUILD_MODE_ENABLE_DM also being set here?
> 
> Are you asking in the sense that the PV domain is being flag as a device 
> model domain? Maybe I am missing something, but I am not aware of 
> anything specific that must be set for a PV domain to operate as device 
> model domain. If flask is in play, then there is a secure label 
> requirement but that is separate of a mode that the domain must be 
> running in. Please enlighten me if I am over looking something.

Rephrasing my question: Is it legitimate for BUILD_MODE_PARAVIRT to be
accompanied with BUILD_MODE_ENABLE_DM. If it is, what is the difference
between BUILD_MODE_PARAVIRT|BUILD_MODE_ENABLE_DM and plain
BUILD_MODE_PARAVIRT? If there's none, perhaps better to reject the flag
(retaining possible use for some future purpose)?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 11:34:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 11:34:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855825.1268625 (Exim 4.92)
	(envelope-from )
	id 1tLhSQ-0000Bd-IS; Thu, 12 Dec 2024 11:34:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855825.1268625; Thu, 12 Dec 2024 11:34: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 1tLhSQ-0000BW-Fv; Thu, 12 Dec 2024 11:34:14 +0000
Received: by outflank-mailman (input) for mailman id 855825;
 Thu, 12 Dec 2024 11:34: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 1tLhSP-0000BQ-Al
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 11:34:13 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fdd17a70-b87c-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 12:34:04 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-aa1e6ecd353so67015566b.1
 for ; Thu, 12 Dec 2024 03:34: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
 a640c23a62f3a-aa674a112c7sm691758866b.147.2024.12.12.03.34.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 03:34: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: fdd17a70-b87c-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734003249; x=1734608049; 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=tgZ+WFUVZlvnULNLaYqU6aMaHAUoT5n16fVxjwQ2LIM=;
        b=KUoiLWUWS4aNQ44ZlHJ5+7Wb9r3bul77Pseo50lR9pfAxwSgOUb4r+bBD0UUYWocaR
         h91AbgyBT0HTrXmdOhty3lkw0GNILY5orxGVDCQclXGdaxkIN5R9UGgy7hAztJVoFaOK
         YoBHk+71yzwLDvzoYukZrq4SDV6xTCO6ioKgfjG2bMECNKWJNlscGIEU/cUWETgH6/yd
         zhvzoPpWR7s1zjY0CZPadQU5TSHXeZxSpQRl1o0jfIoG9opvdUfcHEb7nr+A8SesqcjN
         ZFymEUDyUNpW4xGkkRlasqvuAxxj3RMzZJc7tvb/jB9g9Kfsp+Vy13hu/htoyyHed7Y4
         u+mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734003249; x=1734608049;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=tgZ+WFUVZlvnULNLaYqU6aMaHAUoT5n16fVxjwQ2LIM=;
        b=XBRQsIDN+6+DYu/27fJC90NtGMIFMj/MBMIaL3s5uGHHfCdJD+gRgAq8rvrqDRxJ7Y
         FCARP2+wCDxTAj346lrsqfODrBWj3iGjg9QacBn2JHCjL/D9gzELbGMkozvmedptCtpr
         Lyr19/sk0DbAI9KQlgCLJZDk160GE4UMf7AvJSWRhH/R7B1eBWeh8uYkMeDPtQmo0bPy
         9MWygnDMjXFD9Z6QYysU3DZv7fewm3wXi3c6szwG3nyj9Yhugan8iuZnnLXYmuWp7w9S
         V5evAeIrnucDqp+ec9lnOSC9q0oBJN02VhCa4NL1ayfQakmxYpiGOz7I9VDKfkx+zQEq
         E2Dg==
X-Forwarded-Encrypted: i=1; AJvYcCULx68CMxur+KcMilBkU7i4ZB33k5eRM1JfFp0fyulewLZuDbO2kQCtsCQ1HwfNDlxbuYEHrqIfzNs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YypWyn8aHEtJE3C06iMaiRQSl6AzvToVAy+GOO8QtMZSP/8JqP5
	WkwWbBUt8qbgoxIbxUEWYi9tZzUrCl81KO66ajeOKoWMbdhNiU2Z0IPYil6JMg==
X-Gm-Gg: ASbGnct3HLs1notWss97WwfHshmdfbKrDzNfjlctLQcxdmKmHVk0Qh57QRt5b8iHiba
	fGQugtcWT7TMYZbkFWot4oIuRK7a395AH+GF7fTU7zzhq7RJGyYY9753peuhwgMlw0A3+9f66eE
	bzpeTlo4wtM5DskEPxSeYi3ad0mat9HSWFD9FCKkUts9YNlHK5zRlrdbmtJJF7nawRGgrnx1M5N
	r0RAxFvDThKA4MWgkHDaL+StuBplp+H+gg/T30h4WBBLy3YglbUGJZjqfykDWDKf4lhG18y6i9x
	54XjW0k9AGSMUE9Fzhsph3ZU4dSf4JbuhpOxMWduXw==
X-Google-Smtp-Source: AGHT+IEDHJFE18dKzfxJ9I1X5eFqw1+YMqGW5/slpwSAE/Pm44xDDJRaiONeVdYUmP/9Vd2wWNfFWQ==
X-Received: by 2002:a05:6402:2809:b0:5d3:da65:ff26 with SMTP id 4fb4d7f45d1cf-5d4fa1b29a2mr1585631a12.31.1734003249080;
        Thu, 12 Dec 2024 03:34:09 -0800 (PST)
Message-ID: <70463137-e91d-4a81-a946-e44425275922@suse.com>
Date: Thu, 12 Dec 2024 12:34:07 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 13/15] x86/hyperlaunch: add memory parsing to domain
 config
To: "Daniel P. Smith" 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-14-dpsmith@apertussolutions.com>
 
 <0e68ddfe-6736-4abe-b139-acd80a4bdedc@apertussolutions.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: <0e68ddfe-6736-4abe-b139-acd80a4bdedc@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.12.2024 19:02, Daniel P. Smith wrote:
> On 12/2/24 07:14, Jan Beulich wrote:
>> On 23.11.2024 19:20, Daniel P. Smith wrote:
>>> @@ -160,6 +161,42 @@ static int __init process_domain_node(
>>>               else
>>>                   printk("PV\n");
>>>           }
>>> +        if ( match_fdt_property(fdt, prop, "memory" ) )
>>> +        {
>>> +            uint64_t kb;
>>> +            if ( fdt_prop_as_u64(prop, &kb) != 0 )
>>> +            {
>>> +                printk("  failed processing memory for domain %s\n",
>>> +                       name == NULL ? "unknown" : name);
>>> +                return -EINVAL;
>>> +            }
>>> +            bd->mem_pages = PFN_DOWN(kb * SZ_1K);
>>> +            printk("  memory: %ld\n", bd->mem_pages << PAGE_SHIFT);
>>> +        }
>>> +        if ( match_fdt_property(fdt, prop, "mem-min" ) )
>>> +        {
>>> +            uint64_t kb;
>>> +            if ( fdt_prop_as_u64(prop, &kb) != 0 )
>>> +            {
>>> +                printk("  failed processing memory for domain %s\n",
>>> +                       name == NULL ? "unknown" : name);
>>> +                return -EINVAL;
>>> +            }
>>> +            bd->min_pages = PFN_DOWN(kb * SZ_1K);
>>> +            printk("  min memory: %ld\n", bd->min_pages << PAGE_SHIFT);
>>> +        }
>>> +        if ( match_fdt_property(fdt, prop, "mem-max" ) )
>>> +        {
>>> +            uint64_t kb;
>>> +            if ( fdt_prop_as_u64(prop, &kb) != 0 )
>>> +            {
>>> +                printk("  failed processing memory for domain %s\n",
>>> +                       name == NULL ? "unknown" : name);
>>> +                return -EINVAL;
>>> +            }
>>> +            bd->max_pages = PFN_DOWN(kb * SZ_1K);
>>> +            printk("  max memory: %ld\n", bd->max_pages << PAGE_SHIFT);
>>> +        }
>>
>> Since the values logged are all multiples of 1k, why make reading the logs
>> more complicated by logging byte-granular values? I instead wonder whether
>> converting to more coarse grained values (leaving, say, between 4 and 6
>> significant digits while using kb, Mb, Gb, etc) wouldn't be yet better.
> 
> Sure we can make it report in a friendlier format. To support dynamic 
> sizing, is there already an existing formatter, I would hate to 
> re-invent the wheel on this, or I could just statically report in kb.

I don't recall use having any formatter for this, so for now I'd just report
kb values.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 11:37:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 11:37:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855836.1268636 (Exim 4.92)
	(envelope-from )
	id 1tLhVw-0000qC-2D; Thu, 12 Dec 2024 11:37:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855836.1268636; Thu, 12 Dec 2024 11:37: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 1tLhVv-0000q5-Vo; Thu, 12 Dec 2024 11:37:51 +0000
Received: by outflank-mailman (input) for mailman id 855836;
 Thu, 12 Dec 2024 11:37: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 1tLhVu-0000px-Is
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 11:37:50 +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 804fb4f8-b87d-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 12:37:43 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-aa6a92f863cso90611166b.1
 for ; Thu, 12 Dec 2024 03:37:48 -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
 a640c23a62f3a-aa699487854sm470679466b.13.2024.12.12.03.37.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 03:37: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: 804fb4f8-b87d-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734003468; x=1734608268; 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=5wlTV87l7FP4yewa1JCyk6duJgpPz6St59BNw6WbqCg=;
        b=UB4fFUCfSAGlU10GhlhXlGOihBbVZvyCx58uXSJaj2iZHleGk+z0Wb13j19ToNSGeV
         PG6X/4qu7AA0W9LG5Ms5+i+/1DF8qypPafxgBK3lQs8e28wJg8iHmzhU0MAo6casbx9N
         UQ4doK4E9RQfRBb57fFCMHkW4pDTtdRED6ygCufEjGezFlVhWgz6NN98Ok/OryvbhEIR
         gkoZ5u2SMLagKCSiiwRMQjpSNIB2Gikm9mhQGgCA/dzcTFfKUo8sTon2n1JJe1OFLQf3
         gFEvBmVTVTYdGIQERR/VEBDsrtGUD1EF1fz0Qnw8B/EuOBNK27VauFJQZ2iQ38aAtRnx
         UztA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734003468; x=1734608268;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=5wlTV87l7FP4yewa1JCyk6duJgpPz6St59BNw6WbqCg=;
        b=GGh59z4CF6JyLoJ8Hj0cu3efLutrynEKJp5hy9+15Kf+Iwpcx6cejn8g2fPTKkGcds
         ajLlibKKbzKbWG4L1fXqbVrhSM/GHswem0kvXLhjBPBMTnBEylM9fCxYSNGt9Hyn5Mg0
         MTV/wcNeFSa6Ce0RBeXe1pO/vMyelvLbmDf9+nsfMsLU4RXEN5MxsuA0/Z2sS1dBpHzg
         /Ccs2t/Fdoz/u2gR9UnoUNwYXyDMqNcOcsJzOXhKJPyPHZtTs7sLGj049sYbiDZJ1ofQ
         +0+xsXtKd96t5/zdEbDEgVpsJSiW6+H2vERW+EKGToa6e7XNd3RT0WlDETWAB1NIOhib
         566A==
X-Forwarded-Encrypted: i=1; AJvYcCU4o6uKffseD4Vjsila1/1TtBSlrMt14h2tflxqmY/6kg6NIlq2fHZaJTAEkFvvELSKT91lmO89f/Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzbFH0ox1JYh95jxaLD5v1oogH+RWLj0SUqbhvas4ohTC2O67Kd
	BoUvT2/yGuxzKJsHB/lc4o7m9n+2AsWBAxf4WcZC05OkyGGwcKO0SrfmGM5wUw==
X-Gm-Gg: ASbGnctQHPPSUNEmp7mmgDWGy5bSrKwlMk0GoMFxdoQXNNC5jZcFzYdtrfmJgmAUI9n
	QVHTaHLPiMpvfp4kBO9MqjXbhe5P0mPZ5tq3NYX8pgFNDlgnRfQ1XUoKqFWeffeVlQwI5VN7N6D
	tE2nKUpkXiX8R7elBxmpjKMiYffEL1JhvYSk3M7+pCyrjksF9Us8A2PBv9OBRLb5sizmvGivib5
	8KH7+wfxTOis1Fdu4RgdT04rQenMeqR2LZnhXwiITf1sHC71tBZF1mdkNfaxjkdsYC+k95kPkf0
	AjwA3iHWHc/YTQUDWhPtGGMaKTZiysEadO2kVIrrqw==
X-Google-Smtp-Source: AGHT+IHd5YVgP2ONYGOFgmLHsKXVFTMeYgFuA4WKs4J4yQ/0Fu6OwKJZudKOOGn3H2DSSWo38Ns1Zw==
X-Received: by 2002:a17:907:1ca7:b0:aa6:77e6:ea3d with SMTP id a640c23a62f3a-aa6b1378bfamr742891966b.45.1734003467939;
        Thu, 12 Dec 2024 03:37:47 -0800 (PST)
Message-ID: <18fd3e13-2e36-4d64-b56f-1227049bfb30@suse.com>
Date: Thu, 12 Dec 2024 12:37:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 14/15] x86/hyperlaunch: add max vcpu parsing of
 hyperlaunch device tree
To: "Daniel P. Smith" 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-15-dpsmith@apertussolutions.com>
 <88126e8c-96f8-4cb2-a899-eec2b800cf66@suse.com>
 <18da1057-9874-44b0-a25c-f1ce733611f8@apertussolutions.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: <18da1057-9874-44b0-a25c-f1ce733611f8@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.12.2024 20:49, Daniel P. Smith wrote:
> On 12/2/24 07:19, Jan Beulich wrote:
>> On 23.11.2024 19:20, Daniel P. Smith wrote:
>>> --- a/xen/arch/x86/dom0_build.c
>>> +++ b/xen/arch/x86/dom0_build.c
>>> @@ -617,6 +617,9 @@ int __init construct_dom0(struct boot_domain *bd)
>>>       if ( !get_memsize(&dom0_max_size, LONG_MAX) && bd->max_pages )
>>>           dom0_size.nr_pages = bd->max_pages;
>>>   
>>> +    if ( opt_dom0_max_vcpus_max == UINT_MAX && bd->max_vcpus )
>>> +        opt_dom0_max_vcpus_max = bd->max_vcpus;
>>
>> Isn't this kind of backwards? I.e. aren't you meaning to move us towards
>> boot-domains?
> 
> Prior to domain builder, available construction parameters for dom0 were 
> exposed as command line parameters. This allowed for boot-time 
> adjustments to the parameters. With domain builder, there are now two 
> sources for dom0 construction parameters. Those coming from the device 
> tree and those coming from the command line. For most x86 platforms, the 
> device tree parameters can only be constructed prior to booting Xen. 
> Whereas the command line parameters allow boot-time adjustments, at 
> least for dom0. That is the thinking at least. Now if there is interest 
> in being able to retire the command line options, that would definitely 
> simplify things.

No, retiring command line options is out of question imo. Yet that also
wasn't my point. Instead I was wondering why we wouldn't make bd->* the
ultimate source of truth. However, ...

>> Also, what about the counterpart opt_dom0_max_vcpus_min? That wants to be
>> controllable from DT too, I would think?
> 
> Yes, in theory we will eventually be able to do requested/min/max as 
> well as cpu pinning/affinity. For now it was requested we focus on 
> implementing only requested vcpus.

... that's pretty much only a reasonable option if these were converted
at the same time, to avoid becoming inconsistent for perhaps an extended
period of time.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 11:41:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 11:41:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855847.1268646 (Exim 4.92)
	(envelope-from )
	id 1tLhYw-0002ut-Gb; Thu, 12 Dec 2024 11:40:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855847.1268646; Thu, 12 Dec 2024 11:40: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 1tLhYw-0002um-Ck; Thu, 12 Dec 2024 11:40:58 +0000
Received: by outflank-mailman (input) for mailman id 855847;
 Thu, 12 Dec 2024 11:40: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 1tLhYv-0002tM-9Y
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 11:40:57 +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 efa1cf38-b87d-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 12:40:50 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-aa66ead88b3so89245866b.0
 for ; Thu, 12 Dec 2024 03:40:55 -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
 a640c23a62f3a-aa69964872asm473170166b.103.2024.12.12.03.40.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 03:40: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: efa1cf38-b87d-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734003655; x=1734608455; 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=UyND7wvYxn+7wf2otM9OxBX7OxZgEQuOpc+HEbYcvPs=;
        b=beDnIb1r0H0HNGV3m4cPislSmhVM3hZJlNz1LuhyOm3vA+sLDFIMUvWKK6tarBAEZl
         AfQ5cs8xhq67jwqqQ5wSjjVEpD3M3+iw7jbaWZFcfItdHbdfe41KDcVpHRGIkye9XJa2
         VmQ+GRw+EMrjW6vUJtI3SG4IEPQzh3sSzxCvyXbGEd4oxQaiaA2jFp5AUo50pyNwmwiH
         S3ZnNas71sQVj1x3XZsJKO/7POVM1c9Xy28eBtCk/5qnbyE+gtqGZkoOzMZgYj5HfN0z
         CwVS4m0HvTVbvEh1bGqkXGg0JfjboZNpzIfUvAIedGvYQNcaN6CR+dDVNa6jV+W+C4Ou
         L3eA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734003655; x=1734608455;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=UyND7wvYxn+7wf2otM9OxBX7OxZgEQuOpc+HEbYcvPs=;
        b=t0RgRoXLxt5don69qYn8zVUChuBN5KH7MWePr5u4aljrcM97T+/zzezp/m/eEmITj4
         yGAyXPwb65jVBRGYfDEW43RNati5GXqfOQYHS8SWeA+1TOGYNu2WURscnQO2i4bIz2Un
         uE4uzbUU5fSOg+9B1SdvJY7h4gF3/ANl83WObM5MLyQaOVTTIxjw3CSjptPb7W+AJNyN
         Hw0LNmTp2HJ9MA8LaeflGdJDngZZKhwIPfTCbXCnxJ2lTGiLjpIVYeDjM7D5V1iihFrK
         k4CpnjCqVMKZZSOR7cNnn4TlodjUaTMuM8aVGU8n6WXt3GtuQ/VY0qABiXju4SdrDhqK
         bTsg==
X-Forwarded-Encrypted: i=1; AJvYcCV9tl6/8JmXM7KMesHa7kue0m9genfOGE8xKKvC0ZzvXLrTRzsUu67Mp0S3siArVG73LHzhV1AZt+0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxrZOOyO5hkLAFRjVcczfi6+SOWXxA63D6z+G19dDupDnh98e2E
	GHPZNiUeupg+j8tu9YVg7cJdvipT56/WQeqZgqxfIcfvI8cg3M8cwAjAkkIFYg==
X-Gm-Gg: ASbGncuNKuSE5MkzEi2arjBpCS3J6NldDq6KAS3O//yzc4ANn+FpSb6XCBmWKvIssIe
	9Dpb1t1ywL9D0PGIo1q/7goup+CEp0X+AhbVRuNw+WQh8ylJ/BOrLMGXFQ1NIxWKaU1bIsRcA+p
	6N53idsCpUWB8BquZvS7Hu729s0LY7FzoFMffJHzEg8/OdHXTJ4ngs8z6SCttlUD1fWzU6PmePb
	mLwM47axEaDPsoaopF4tPzv3EmrW3eegEQYEfAnTqd3xiRvSuF2VQcP0Ckb1v6OHV9Sc5bFwUxo
	IDX03eWG9eT1uMPdmUSJimoViPK8a+N6X4gz2BJF0Q==
X-Google-Smtp-Source: AGHT+IELcESixDvtRT2iNcd4G5oTHZX4KSLaSAfq45ihdOSRfEJqq/4kayEdvirDe6JSJExuzfHPOA==
X-Received: by 2002:a17:906:3109:b0:aa6:9eac:4b86 with SMTP id a640c23a62f3a-aa6b1182374mr640790566b.16.1734003654786;
        Thu, 12 Dec 2024 03:40:54 -0800 (PST)
Message-ID: <6605c052-da20-49e4-8d7f-f9e870ca6b92@suse.com>
Date: Thu, 12 Dec 2024 12:40:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 15/15] x86/hyperlaunch: add capabilities to boot domain
To: "Daniel P. Smith" 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-16-dpsmith@apertussolutions.com>
 <84bc7854-7935-4f36-b574-d19dde775673@suse.com>
 <16a6944d-4ac5-4016-bafe-1bd8b6a4fa4d@apertussolutions.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: <16a6944d-4ac5-4016-bafe-1bd8b6a4fa4d@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.12.2024 20:56, Daniel P. Smith wrote:
> On 12/2/24 07:23, Jan Beulich wrote:
>> On 23.11.2024 19:20, Daniel P. Smith wrote:
>>> --- a/xen/arch/x86/domain_builder/fdt.c
>>> +++ b/xen/arch/x86/domain_builder/fdt.c
>>> @@ -209,6 +209,19 @@ static int __init process_domain_node(
>>>               bd->max_vcpus = val;
>>>               printk("  max vcpus: %d\n", bd->max_vcpus);
>>>           }
>>> +        if ( match_fdt_property(fdt, prop, "capabilities" ) )
>>> +        {
>>> +            if ( fdt_prop_as_u32(prop, &bd->capabilities) != 0 )
>>> +            {
>>> +                printk("  failed processing domain id for domain %s\n",
>>> +                       name == NULL ? "unknown" : name);
>>> +                return -EINVAL;
>>> +            }
>>> +            printk("  caps: ");
>>> +            if ( bd->capabilities & BUILD_CAPS_CONTROL )
>>> +                printk("c");
>>> +            printk("\n");
>>> +        }
>>
>> What if any of the other bits is set?
> 
> I'm not sure what you are getting at, but there is another cap added 
> later for HARDWARE and it will print an 'h' next to the 'c' if set.

And that bit, when set, will likely have meaning beyond this mere printing?
If so, what's the effect on the domain when the bit is set, but the code
consuming the bit isn't there yet? Will the domain function correctly? IOW
shouldn't you reject any set bits that the code doesn't know how to handle?
And then perhaps report all unknown bits in a numeric value here?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 11:43:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 11:43:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855864.1268656 (Exim 4.92)
	(envelope-from )
	id 1tLhbZ-0004MW-UU; Thu, 12 Dec 2024 11:43:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855864.1268656; Thu, 12 Dec 2024 11:43: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 1tLhbZ-0004MP-RS; Thu, 12 Dec 2024 11:43:41 +0000
Received: by outflank-mailman (input) for mailman id 855864;
 Thu, 12 Dec 2024 11:43: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 1tLhbY-0004MJ-69
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 11:43:40 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5445cf4e-b87e-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 12:43:39 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5d3f65844deso791731a12.0
 for ; Thu, 12 Dec 2024 03:43: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
 a640c23a62f3a-aa671f1482asm709572466b.107.2024.12.12.03.43.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 03:43:38 -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: 5445cf4e-b87e-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734003819; x=1734608619; 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=ZLxheR2Ho1Fpke9iVPI8LqPgTq9RQohZDcOeJ7ONy6M=;
        b=JZvrUrqwabE6KzNa4CwK6v6UEZFT55xBMhUoOpDQS8sOZm8suom0pweqndrWH60Tuo
         1nV7xpE0PCHAH7nFcy6r0NW21RMKuQcPqCjMJ9g298yWdjtT7G+eMwHhriLY2wFaPhTX
         UG3PUm+sOjXqYLZ/mrpbPgstWGbFeA8XTY+H3+yU7466sAwe2bXQM7dZQVx7v6LO+QZa
         qbIHs8TuNAagwlBNbN/h1m32qemG6CEgGcsHP4ZLaIsVeMPhfnpagIe4csVoDzUno97u
         hw5o5vkYP3WYdQZYnqVu8qL5Kb5r5/GOW6MJHG26TYSYYJr9D5DXrCCvyVy4doNMSG/4
         QPsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734003819; x=1734608619;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZLxheR2Ho1Fpke9iVPI8LqPgTq9RQohZDcOeJ7ONy6M=;
        b=enJYltP0a9Fa+0WPuMIl1cS2mUakvlWJ8DmV/LavDgmxrFTv6Hk9CaCc4JRv06r/m2
         LrphhWX1AyA3QTgy+RLlJOn5XqKRULGuW7LuOlUZdinVo2+ipvd2KO1Nw1TsRSPb+PRY
         EXypeQVST3ZuklPBbRCwR7J+X07m5JsSh3AIfz+BH+/J4BGWHYnOHkofe6YAUjJNEPNd
         ZFKOCLUo+azSiRuLiaAelTh38Lfiw6nO8QST7XPLIJ6kk0U2BzxolOBIUf08GzySO8xU
         zCme0STpD4cI6sJ89cLiN8DmALJLkyaDLlAzd4Q8If1+tLhLNXv9rbMGAgS6M58m+tF2
         wuow==
X-Forwarded-Encrypted: i=1; AJvYcCWSJZB3YVJrMd0WDSVx5ieMnwaO3JUgA6Z71lVwbLSOhY7zgrLbplWJwYc2SBAxD+lGaDh4BYcRAEQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy8BSYNdOo7Pjzpwlqi6WaL0SNw7VBJXDX/KLfmcVk8h2c9KL86
	Lj2CGmMoLijzEhHyzqyuguZu9KJJFafs/lxvxivoEo2d7RRwAMDgkGiS9o8giA==
X-Gm-Gg: ASbGncs3syXP2fylEgqeFaf/qqogm89IcYKwcUgeiqPqK2u6sLGvrZYaK0NuWEO6sUS
	4YyUgX00Q4a5ueol0Q5SNnj7o/aVozYwKoMBhgN+9v03R/a6QdtvbCnyfx2LjxAaTVInWNXwrWs
	/ZsqVm2HaHD/3x0qyRI237ZX69877wUF+1wDnCTOuHrJEI/ONZu05QJ/TO1UzUB1AoVLxl749QU
	J/kdgn3s05DFYqYRmDMKRYqQeWO3pl6Qmkcz7YELlKwn09f3n127OCGokriJqnXuh3gHx0gUBFi
	SJD/UXJM2RjQUjQVp9b1Z4AilvmjjrlofblzMRD+AA==
X-Google-Smtp-Source: AGHT+IH0yL6bpgM1iYl7AsYlLzKLbffRJhYltBpymT7VWOBE9JbXxaHM1PxPh0GmudxtLMShuOehQA==
X-Received: by 2002:a17:906:9c9:b0:aa6:7f3d:4f9c with SMTP id a640c23a62f3a-aa6c1cefd42mr348810866b.38.1734003818642;
        Thu, 12 Dec 2024 03:43:38 -0800 (PST)
Message-ID: 
Date: Thu, 12 Dec 2024 12:43:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] xen/riscv: add destroy_xen_mappings() to remove
 mappings in Xen page tables
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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 11.12.2024 18:27, Oleksii Kurochko wrote:
> Introduce the destroy_xen_mappings() function, which removes page
> mappings in Xen's page tables between a start address s and an end
> address e.
> The function ensures that both s and e are page-aligned
> and verifies that the start address is less than or equal to the end
> address before calling pt_update() to invalidate the mappings.
> The pt_update() function is called with INVALID_MFN and PTE_VALID=0
> in the flags, which tell pt_update() to remove mapping. No additional
> ASSERT() is required to check these arguments, as they are hardcoded in
> the call to pt_update() within destroy_xen_mappings().
> 
> Signed-off-by: Oleksii Kurochko 
> Acked-by: Jan Beulich 

Apparently I just shouldn't provide advance acks, when ...

> --- a/xen/arch/riscv/pt.c
> +++ b/xen/arch/riscv/pt.c
> @@ -421,6 +421,14 @@ int map_pages_to_xen(unsigned long virt,
>      return pt_update(virt, mfn, nr_mfns, flags);
>  }
>  
> +int destroy_xen_mappings(unsigned long s, unsigned long e)
> +{
> +    ASSERT(IS_ALIGNED(s, PAGE_SIZE));
> +    ASSERT(IS_ALIGNED(e, PAGE_SIZE));
> +
> +    return ( s < e ) ? pt_update(s, INVALID_MFN, PFN_DOWN(e - s), 0) : -EINVAL;

... then you introduce basic style violations like the excess blanks here.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 11:48:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 11:48:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855875.1268666 (Exim 4.92)
	(envelope-from )
	id 1tLhgQ-0004xV-G9; Thu, 12 Dec 2024 11:48:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855875.1268666; Thu, 12 Dec 2024 11:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLhgQ-0004xO-D5; Thu, 12 Dec 2024 11:48:42 +0000
Received: by outflank-mailman (input) for mailman id 855875;
 Thu, 12 Dec 2024 11:48: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 1tLhgQ-0004xI-17
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 11:48:42 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 04a1ab5a-b87f-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 12:48:35 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-aa68b513abcso87730766b.0
 for ; Thu, 12 Dec 2024 03:48:40 -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
 a640c23a62f3a-aa6761d0ab3sm688876866b.201.2024.12.12.03.48.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 03:48: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: 04a1ab5a-b87f-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734004119; x=1734608919; 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=oF01OQTATxw5803525epeWR+MSrmPgptyH0ip19zs0I=;
        b=f6WkYEsPbMj52HTAFhRe7unAP8m2IRL7u/9EK/vNniB7AxaE1FlNF57EH2y8a5cHKg
         Zh93Uyu7N4YcT9vCW0cQLqfSc5p73oy9v2nZJX9CVSY5YxM1ZII02ClxkhoZ6Pan/AjR
         ilHzM0ZozgJK9rmyks9EjkIW4O+Cd/Fg3M7neoC/50BG9rh2YaCT1Y7LYYt+CvAv1bRl
         20bpPyAM45X13RFJomhHQ0bXjbtKB8WQqgusaZewpV0C9sDMbHTMQ8W6hTtTOscrE+OQ
         6ZE8XUF32Ky6DJ2TwxOhm6+O+yWQCJ4fwXPhixs8C2kl3lPQaiAB+IAy5fi75syahf2O
         6g0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734004119; x=1734608919;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=oF01OQTATxw5803525epeWR+MSrmPgptyH0ip19zs0I=;
        b=BIe34qjIo3z1C2C+hvjYrt3SVqGPjUZsZzTYUebTPBdjBPdRJRahi9yzUlhkAHGM6c
         Jt6a9UnPF9Q2m5R27QsNl67QqxMuqURvSeLGYYTpU7qhILYMVbklSyycgCdKaKHeha4g
         pmunY1IhXuuje0S68ybVkqzvtxyKjSGBJorFuJ/i8PFCOOeP2eau5FD0EtkByASnQWKc
         5XOufRWQWRG8QtVzRLqcSQco4FTRcV3fCZE/UxMrpEOLszwfZQHd2LkUs/LdaGlaLBda
         JkrIGrtcDPbLuNnauc7bxjTslQjKB9cJZcF0qL0zL7Dgrplw0pZq/eFG0duQTqOZXWKy
         DAuQ==
X-Forwarded-Encrypted: i=1; AJvYcCUr0i6sjuR6C0AUTdg+wP6TaC9QdEq/VzhzMX5GFY9z1/ljpBSp76uyvuW5KVQbgsdR8V1r/drxcGQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YweULevVseqQ33QPkSiZ7G8zfJPqMMSY0H4Oug5ZUc9vRqZN/dJ
	f9IIra8fx08rE4YM26Kfm1/XwMNxdbKUbQ8tQQgc+IMqp7eNo5wJs04qE3SCYw==
X-Gm-Gg: ASbGncvRPOdS8kIfS4dAe7MBS34bYRl08tPNTNyBCwgqGD/LkeFsiwg8qKoLYM+eazF
	Q3KpFBqXdieQdto7S3vA1Q7LkVHkS4TyvI/fHn+80e4K33TpwYfsaWsNowvwKXog8DQWOZCb3XV
	fpFWcYwM7YY2qnd80ltJgYQ4M3Bc/kjbB3ue55J5tLhHfJKnmDFZw0d5IykpYnpgQqpLkdxtaxF
	83VZjxydmoiY8zDKzQh2vZNy3P095fdWMC5oikWaZ/lI0pH9roijbOP9FAjL0GuI0TZ7oRU03/d
	FDbKhS99o3p8xKFTX8ER0CpfRlGTdCzUj46Tl+TkkQ==
X-Google-Smtp-Source: AGHT+IH8tH6n9pHHb1dIOmw71r7e46uqifKDgIAl6EIfnSXjMH3j4kS1z/wqkPViBTWgfzIWFKA9FQ==
X-Received: by 2002:a17:907:7746:b0:a9a:9df:5580 with SMTP id a640c23a62f3a-aa6c1b09ceamr355678766b.19.1734004119425;
        Thu, 12 Dec 2024 03:48:39 -0800 (PST)
Message-ID: <424be620-ae2e-4681-8c5a-42572194b256@suse.com>
Date: Thu, 12 Dec 2024 12:48:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/7] xen/riscv: add {set,clear}_fixmap() functions for
 managing fixmap entries
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <3d34dbc7a8af373b799d1e0c1c99acfa3798f37d.1733937787.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: <3d34dbc7a8af373b799d1e0c1c99acfa3798f37d.1733937787.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.12.2024 18:27, Oleksii Kurochko wrote:
> @@ -433,3 +434,19 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns)
>  {
>      return pt_update(virt, INVALID_MFN, nr_mfns, PTE_POPULATE);
>  }
> +
> +/* Map a 4k page in a fixmap entry */
> +void set_fixmap(unsigned int map, mfn_t mfn, unsigned int flags)
> +{
> +    if ( map_pages_to_xen(FIXMAP_ADDR(map), mfn, 1, flags | PTE_SMALL) != 0 )
> +        BUG();
> +}
> +
> +/* Remove a mapping from a fixmap entry */
> +void clear_fixmap(unsigned int map)
> +{
> +    if ( destroy_xen_mappings(
> +            FIXMAP_ADDR(map),
> +            FIXMAP_ADDR(map) + PAGE_SIZE) != 0 )

There are multiple options of how to indent such wrapped lines in function
invocations, but this isn't one of them.

    if ( destroy_xen_mappings(
             FIXMAP_ADDR(map),
             FIXMAP_ADDR(map) + PAGE_SIZE) != 0 )

(arguments offset by 4 from the function name, which may not be a multiple
of 4 from the start of the line) or

    if ( destroy_xen_mappings(FIXMAP_ADDR(map),
                              FIXMAP_ADDR(map) + PAGE_SIZE) != 0 )

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 11:53:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 11:53:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855888.1268676 (Exim 4.92)
	(envelope-from )
	id 1tLhlO-0007td-1Z; Thu, 12 Dec 2024 11:53:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855888.1268676; Thu, 12 Dec 2024 11:53: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 1tLhlN-0007tW-Uk; Thu, 12 Dec 2024 11:53:49 +0000
Received: by outflank-mailman (input) for mailman id 855888;
 Thu, 12 Dec 2024 11:53: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 1tLhlM-0007tP-IS
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 11:53:48 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id becd8111-b87f-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 12:53:47 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5d2726c0d45so896950a12.2
 for ; Thu, 12 Dec 2024 03:53: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
 4fb4d7f45d1cf-5d14c74c3casm10210465a12.53.2024.12.12.03.53.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 03:53: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: becd8111-b87f-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734004427; x=1734609227; 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=N4h+zAxTmc1Pv7dONz90Et+cu5Hsh4CG7PbQvWTjvto=;
        b=EtzLHINi/kTWMEEottt3I7nZASSYAeb3bS+tfE6vF/TiE2HCgjn8pEfjL3Eg6xPzJq
         7MjRIdYozmV2Ul6OmmXMc5UAP1rhN2SsfoRWpXn23VUyDED/UUSaO5AT3+/T/kVBTaHK
         V5boiXjbIW57DYqICANbWXrOOi5/mTHelosVMQvm29+9GbfrVmjZvUTdXgIsNcS9OpoA
         X+ZviSvKYSPRepLGTkFN3BtDkQ9ivGFVMwj1LUm5QtslL6pTnY0N0cJRT+Ya/63ZeYQ/
         CaMfy3za0woSlewP/01PXNlfHSHZQDEzb0GNr0dI/KUhnseHDaI1QS9kJXFLqMoHfdTz
         8GlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734004427; x=1734609227;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=N4h+zAxTmc1Pv7dONz90Et+cu5Hsh4CG7PbQvWTjvto=;
        b=VfuWoFQcjgxV4Q0ms/4cr+Y65QA31MCL3enpccpyD7q1b5+XYt7v88NZPHGxrxxxDh
         RJ3q+L5sf1pfF7E0TASRGrhaIImjPWeKxyyKHzr40RUoPsPrAn1sSGpEcHv7ZOKk30XL
         pvmNFiqAvCb49nLO2lFx+wUETJRskUWrqaftv0LQuUWFQ4KzL4679Kw0jm+Z9RA7PxTm
         yO+9mlKt1EWdA8jqN4g/JFUadIb3zOjLtf8LaP4JyklxJ6Fi2szQ1kkI226jRjC50Ru6
         CUiu3Z8K0Un8UE4qEnRGFQJZ7s8+14Uwgwnf6+Ei2EmeR93rW+47LEHdcHVZAEs58Ift
         BQag==
X-Gm-Message-State: AOJu0Yy3l2RPAkSjr45dNM0ojpSIRIXVgHFYCyP43JuE2KiZvT6cKakv
	uuB4R4N2Q96Y+fxw7s1wuMOtyJNAG5a6apQ31yl0O7OlSmzLeUB+cATHhhBodw==
X-Gm-Gg: ASbGncvdDpTKNy569ox0gJckX+wmYhZH8KsSWrEUkrIg+wiIjMAd5PWW1m7wVV8iNvI
	aqx8n6g28Hfhk2cssRkfQEMxtuN9b7WfjfeH2ysYBExBqd7M4yuwClZOaxy1Cqy+uNOOTqdZCB5
	UcgaEORkBagPFV/vnhf8MyB62zNLqJfkSs2DjG6yxV19mcItkxXfeJt0HE2rqBGl3jhYnCapRHc
	uNyCKt8ldegpcjoKhD1OAFDip5ZDKa9d28s0W5rUiimlDpyAP5X/3JyPCEdwlYt+Y8v6WC6c0Tj
	2SEKCdfi3sCJ1OYGgEA2UB3xNw33ot7uU+xklGpqsw==
X-Google-Smtp-Source: AGHT+IHkHBWDvIyE6Q3neJIOYD/1G8NSHvC2IvZuUhfZEjy2oV0PSQOXQd4a55v0SG8ZNzg2l2Vy5g==
X-Received: by 2002:a05:6402:35d4:b0:5d3:e4eb:8d1f with SMTP id 4fb4d7f45d1cf-5d4edcce306mr812180a12.12.1734004426923;
        Thu, 12 Dec 2024 03:53:46 -0800 (PST)
Message-ID: <8fa61060-3c00-453e-be47-3a60671dc7df@suse.com>
Date: Thu, 12 Dec 2024 12:53:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 09/35] x86/domain: print emulation_flags
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , Julien Grall ,
 Stefano Stabellini , dmukhin@ford.com
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-9-e9aa923127eb@ford.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.12.2024 16:19, Roger Pau Monné wrote:
> On Thu, Dec 05, 2024 at 08:41:39PM -0800, Denis Mukhin via B4 Relay wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -818,11 +818,15 @@ int arch_domain_create(struct domain *d,
>>  
>>      if ( !emulation_flags_ok(d, emflags) )
>>      {
>> -        printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation "
>> +        printk(XENLOG_G_ERR "d%d: Xen does not allow %s %sdomain creation "
> 
> gprintk(XENLOG_ERR, "...
> 
> Might be more natural now that we have the macro (together with Jan's
> suggestion to use %pd (same below).

Yet why would we want to log current here, as gprintk() does?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 11:57:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 11:57:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855899.1268685 (Exim 4.92)
	(envelope-from )
	id 1tLhov-000050-FG; Thu, 12 Dec 2024 11:57:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855899.1268685; Thu, 12 Dec 2024 11:57: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 1tLhov-00004r-Cg; Thu, 12 Dec 2024 11:57:29 +0000
Received: by outflank-mailman (input) for mailman id 855899;
 Thu, 12 Dec 2024 11:57: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 1tLhou-0008WP-Oo
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 11:57:28 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 42208f59-b880-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 12:57:27 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5d122cf8e52so841276a12.1
 for ; Thu, 12 Dec 2024 03: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
 4fb4d7f45d1cf-5d14c7aaeefsm10521397a12.87.2024.12.12.03.57.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 03: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: 42208f59-b880-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734004647; x=1734609447; 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=usKq8skEY+IpS3zo9O1EK2cETBYBqBsvKJLc30SBBAY=;
        b=NtlK0trjTujQYR9Sv7l1zLyjuiaMJCck3MsowEM4tdXQPQEX2Z6ibz+XpCUOFjEWrd
         zBIGq6EHCRuyDph/R6qPR8bCNYL5n6xLnf+2hk1vR3gZ/cqfc6n+Ol11agCVQA5bs9PU
         xgkEtasVZFqV9V5zoZZ8BZXTFaTjYI974LhhCJMo4+s5YkPvJGT2EviZfDhTGtxWplq9
         7Vza2OqNnHGrNWW5xcQI8p1zIIza0ZrmROvk0u1Zun9w8qbiw7MW7vbJYIovZxa7QB+e
         qfEuBtGCdTGIdO/92IiFnjKC2gpilBbte2VslTiMtoCP7vJXzGV6Zo8TkFH4gXoxruoe
         40Mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734004647; x=1734609447;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=usKq8skEY+IpS3zo9O1EK2cETBYBqBsvKJLc30SBBAY=;
        b=W1koE5nrbz+MAPZsyqu6xki6JhXfKlKHfKw/vM9wlhWYl3jMEsSNMm/0TokwrCQGTb
         NeI6s3KO8hXAUUWgZwX0XAk0AmfK31NFLG2T5hCrvRNutKMwnqGmkTnkY0ElvEVSGxWC
         WhLzIE3iQSldWnHBay5pzjozonbjXObpni6UOahQVF7NFvWerKexVzWhUbVh7lEdFNxA
         I55hjrVYU76kW5WISvnr0nqSsQx74k17eBAoblFhaDtQb4JwSOm7e96lzqh730UR6Xbl
         h4tghsanQk/isDVhJZZCM1Aj0J1jZCsNbsESYdt7lkBndIUPU72LpsFDSF7s5jDtGqPg
         vSUw==
X-Gm-Message-State: AOJu0YxGWDT11DeQTqIpoDkCUFQ45uTDvqZpctanhe0LrrJG1I2uj1Za
	3mcj37wRyLZKLtZVxENjjF1i1TI47DrrDyhlFNHC95Rkpt7a1DgX1ur1T7fNZQ==
X-Gm-Gg: ASbGncspaINLyzKL3uQaW4AK2ZhuxCYHDqrpzTxPzNJstxQyVd8kfqwYlz7pbSAnuGc
	skBY8ZUOxR0rFZUmJCYF7PCHZT/ZEgo8xO1QjbjIPS3FGE7ORtxQr1xBKjz6k2P9kvdLfzztz2L
	UKvuALsfTICqlwZz4KKPBdPZDXVqG4tQhzsmxVeejv6CFtMVSqNJiuMiOw9eZXUjvr6G/oGI8Ct
	sMtBtlvayC29T8ht7cdExJhLx3tivhPDTfXh+87Obo7qiVPOsAlXcn92fIDA2OiY7XjhZ4MwZGi
	LspsElxlzlQAATEUSwkILBJdUTeeaC4MC99y7w8esQ==
X-Google-Smtp-Source: AGHT+IGO+RPQ/h17MLOv7YZxSPfHIgyKH7prsAsiPvLcfX/WLyvBnGBiWEEdrHtDnW+KPPnjLs3n/g==
X-Received: by 2002:a05:6402:2106:b0:5d2:723c:a577 with SMTP id 4fb4d7f45d1cf-5d4edce03d7mr893975a12.14.1734004647289;
        Thu, 12 Dec 2024 03:57:27 -0800 (PST)
Message-ID: <8e5ce2dd-f888-42a3-937f-98ed1269c66c@suse.com>
Date: Thu, 12 Dec 2024 12:57:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 16/35] xen/console: introduce printk_common()
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , Julien Grall ,
 Stefano Stabellini 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-16-e9aa923127eb@ford.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 12.12.2024 10:14, Roger Pau Monné wrote:
> On Thu, Dec 05, 2024 at 08:41:46PM -0800, Denis Mukhin via B4 Relay wrote:
>> From: Denis Mukhin 
>>
>> Introduce new printk() variant for convenient printouts which skip '(XEN)'
>> prefix on xen console. This is needed for the case when physical console is
>> owned by a domain w/ in-hypervisor UART emulation enabled.
> 
> IIRC the ns8250 can only send or receive one byte (character) at a
> time, so you should likely put that on the console as soon as it's
> received?
> 
> For the hardware domain we explicitly don't buffer writes to the
> console (see guest_console_write() hardware domain special handling).
> 
> I wonder however how you deal with domains that don't have the console
> focus (ie: != console_rx), as for those I think you still want to use
> the (d) prefix?

Imo no matter what domain has the focus, the (d) prefix should
always be logged. Just to avoid possible confusion.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 11:59:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 11:59:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855912.1268696 (Exim 4.92)
	(envelope-from )
	id 1tLhqw-0000lz-Vg; Thu, 12 Dec 2024 11:59:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855912.1268696; Thu, 12 Dec 2024 11: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 1tLhqw-0000ls-S3; Thu, 12 Dec 2024 11:59:34 +0000
Received: by outflank-mailman (input) for mailman id 855912;
 Thu, 12 Dec 2024 11:59: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 1tLhqv-0000lY-38
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 11:59:33 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8c4b5f91-b880-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 12:59:32 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-aa66ead88b3so92482466b.0
 for ; Thu, 12 Dec 2024 03:59: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
 a640c23a62f3a-aa672d377fbsm695464166b.75.2024.12.12.03.59.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 03:59: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: 8c4b5f91-b880-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734004772; x=1734609572; 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=Ph6gCKBjK4UKK8Qia0/dHHZfNDmnP26M8zJMoR0ZQfw=;
        b=BI1R1C/OU77E0oxyl7p+qPnOEeoScovvLkAgdlnYFsbNb7IOweUo462dc+uLaNQPvM
         BZX1dUurS/ndKKNn0jJqsXpKCN7hiqkFQj6UYoweNRvi6Pl+KrpkSVsmDtmSDgptKjax
         PqR9JmeNZcYIxOXZgMyS62oUEeDB1IbllU3Jz96rQ0RGmpqdoZWLBAZEzUW7Nzva2AU4
         IchMlZZzkPQKd/K436UPqBlSkHLZSiEstoOGzYOLRZjSFsAgLQaz7XLLv+f/MsbtNOaq
         bvxuxN0aX46vNAN783YCsXjYi60UeQH1DjW7+mE8sceyabN/taXgfahS09+Dg1pW/Bnr
         /Icw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734004772; x=1734609572;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Ph6gCKBjK4UKK8Qia0/dHHZfNDmnP26M8zJMoR0ZQfw=;
        b=CwgI1lpnQmz6J6vpGE4KWmJuhNzVcXnLB7GrwAmbYAGBxQo1cESWclF6iIgjTJ1NCG
         GRTgb6vHqWwpCCcWdHkh7spzQOmrpmk2NozUxfc8iBw+DJiqenMJVSFNqaYZo+9Z2sFA
         llfgFLlp0ur79Tl7X4y4CPj2gFG5FdiGzi5i4pl5ojwxLtOyWqvjNcy6Qph0NohYjEh1
         G9TsrC9C67nDW5eUxa2xaQxC97x3oKa99VQ19cmkSKAYdtlzmykxq2b5iSQlpR3iQu4N
         r269ctwNdtIxfvujvzg+9eEle9fh+ellsqgsAefKckRYT1B6jOhmWcurx+3Cl4iIn6Gu
         b+MA==
X-Gm-Message-State: AOJu0YyBL286gDepfW2HJFDZf8Od8oqKSo65vax/SGLv4GaAq/hKfDBj
	2/92N2FV+bmRhZl0hhC6EkMPu6Z0Yt9cOgnyyhjrnBg8Oe1oQs5Dachxz3LjUQ==
X-Gm-Gg: ASbGnctrwKKovSxckwF/DkmAQV/PORFrQNiQWZhkfFPyjnGAQ53zjO/W7ZhUQ/RlQHS
	zEgnRWk5BY2NV+HU2VrAgS6RuzbUPS9q8yifCbO6s8FwDqKxi1885HbfAnpjxMTQsqaqwbhRq7t
	qXfMyG0VWjc0lE84D8VlPvxRUKATuKAGfFtUNiKtFCqXNb9TWM2oZ53okbacN0vAKnVGQWV6s80
	oAi8lzIPOuLSjmXOzgOiKLu7Ltmm+t1jvaPyP/4qITMZg8SpV0Oq0LEjD2hJK3B3VFNc+s6Xvgn
	3ucbPJk7Q5ctM4ohMQTOVbQiTAExp37oQmdIYxQWqA==
X-Google-Smtp-Source: AGHT+IGLKc3Ge4L/SsSvQXjBOTeuj6au4SxUtjAei07cNMuEv0QjXH864LYXjE84M6Gn0U8ISnapSA==
X-Received: by 2002:a17:906:3292:b0:aa6:b1b4:520b with SMTP id a640c23a62f3a-aa6b1b4536dmr575358266b.58.1734004771717;
        Thu, 12 Dec 2024 03:59:31 -0800 (PST)
Message-ID: <1e36f66b-a423-428c-9b22-8fd58450f119@suse.com>
Date: Thu, 12 Dec 2024 12:59:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 19/35] xen/console: introduce console_set_owner()
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , Julien Grall ,
 Stefano Stabellini 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-19-e9aa923127eb@ford.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 12.12.2024 11:12, Roger Pau Monné wrote:
> On Thu, Dec 05, 2024 at 08:41:49PM -0800, Denis Mukhin via B4 Relay wrote:
>> +static struct domain *rcu_lock_domain_console_by_id(domid_t domid)
>> +{
>> +    struct domain *d;
>> +
>> +    d = rcu_lock_domain_by_id(domid);
>> +
> 
> Nit: I would remove this newline.

Or even better make the function call the variable's initializer.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 12:04:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 12:04:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855932.1268705 (Exim 4.92)
	(envelope-from )
	id 1tLhvy-0003hA-Kh; Thu, 12 Dec 2024 12:04:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855932.1268705; Thu, 12 Dec 2024 12:04: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 1tLhvy-0003h3-I9; Thu, 12 Dec 2024 12:04:46 +0000
Received: by outflank-mailman (input) for mailman id 855932;
 Thu, 12 Dec 2024 12:04: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 1tLhvw-0003gx-Gs
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 12:04:44 +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 424b7de2-b881-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 13:04:37 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-aa66e4d1d5aso83932966b.2
 for ; Thu, 12 Dec 2024 04:04:42 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa67d6fcd3dsm656070466b.80.2024.12.12.04.04.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Dec 2024 04:04: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: 424b7de2-b881-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734005082; x=1734609882; 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=CosiXLC70EQ5Hq7B/A6HMe8QGiCjRXU4Dc3u9daacOk=;
        b=DMKCoquugWO3XCs9MegSWXxdWoRNh8apoFI3mYUwPMcXJAbpX8szNH9Fnlly7W/MhS
         IkAdUK1PKCwGs23Sg+vywDbrMfR4BgVPhewhJf/FNZbnb+KkconqPEixtTjxy/Lz+6Zp
         nKev7HcZhMXf3/LvbJHmJiCgoh2mR7GELenZA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734005082; x=1734609882;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=CosiXLC70EQ5Hq7B/A6HMe8QGiCjRXU4Dc3u9daacOk=;
        b=lAocux+V7AcLxj8xWpF4t9tDXmOE0X0WeMbdaeTwqTmw7wubUi+C6NglgzpIZU0/Fo
         NWVBCzfcA7lUqkkXqio6t/QMqOMWJpPwPWjuS7qsUlp6ENgghYZTmujG8KLdL5TbnWjX
         2WtlUlCpiFmH1kR/7rFohwI9JYeihjIUeeTNTreeo7qL0ym3mSyLaCtANpO3V7FTDE2P
         ck/yNvJJl2p382DFycHUFVgflrFQQeTP1OrY59ScdYb0HhphRvkpCgvEYkRQ5d1ZHXus
         tIJWdN+cE0KWa7SbK1f3jzB0w6xKQYVTODyJxv1BhGzZDTZRTsACzo3FfArnUNEdkGpO
         690Q==
X-Gm-Message-State: AOJu0Yyzz2QIDDKmFjt5m9s4RyQ73ArDfodFtPZPhLWiMWEfjiviY6m2
	DGn917tIvXGrjKaFWrmfyQX0O2683m8K5gtP97rEut8eZGXpgCZx9VKsk78vkZE=
X-Gm-Gg: ASbGncvvpzzo5ePenEwyhjSWC3uQnwaebgpD08ntSe8G6sa7Qn+rLV+ujwljZIfMynI
	hFg7lovqYJ/P2Jt6/gbEgasNt7/p4EiqCOM3zP0FEJJMGcp6PGdmsgyvxAJn35lQGZ5u2Ucb85v
	68Lr14gLK+l4OGg1fZwjhw5dwppejFQ0273JgfBlaMt5AIa0Ds9krhKhxltubqp0SVh/xEUaqWD
	tCGhWSbPfZJ6F/AQcW3mWOY6XisygPciFS2z8DDtvLc2oHg5hYplAP0dMJsOzGRVw==
X-Google-Smtp-Source: AGHT+IFld8r2qPMzH52o0LNdnFRgizWAcXOC5ouav3qbmso94KapH4ryfiOklM5qcTJk0ZsNAs/wVA==
X-Received: by 2002:a17:907:1de7:b0:aa6:653c:409a with SMTP id a640c23a62f3a-aa6b13f1b34mr610896466b.57.1734005081757;
        Thu, 12 Dec 2024 04:04:41 -0800 (PST)
Date: Thu, 12 Dec 2024 13:04:40 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 23/35] xen/console: introduce console_write()
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-23-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-23-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:41:53PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> PV Linux kernel uses HYPERVISOR_console_io hypercall for early console which
> ends up being handled by Xen's console driver's guest_console_write().
> 
> guest_console_write() duplicates the code from __putstr(), elimitate code
> duplication.

It might be better to split the code that unifies
guest_console_write() and __putstr() as a non-functional change.
While the introduction of use_conring is likely a functional change.

> Signed-off-by: Denis Mukhin 
> ---
>  xen/drivers/char/console.c | 97 +++++++++++++++++++++++++---------------------
>  1 file changed, 53 insertions(+), 44 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index ce3639a4cdcda00ea63e3bf119bc3b242cbfdf6a..115967d179998cba4a81578caba09db4e4aca7f7 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -63,6 +63,8 @@ static const char __initconst warning_sync_console[] =
>      "However it can introduce SIGNIFICANT latencies and affect\n"
>      "timekeeping. It is NOT recommended for production use!\n";
>  
> +/* Flag: use conring for early console; switches to opt_console_to_ring */
> +static bool __read_mostly use_conring = true;

__ro_after_init instead of __read_mostly.

>  /* console_to_ring: send guest (incl. dom 0) console data to console ring. */
>  static bool __read_mostly opt_console_to_ring;
>  boolean_param("console_to_ring", opt_console_to_ring);
> @@ -661,6 +663,16 @@ static void cf_check notify_dom0_con_ring(void *unused)
>  static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
>                                 notify_dom0_con_ring, NULL);
>  
> +static bool console_locks_busted;
> +
> +static void conring_write(const char *str, size_t len)
> +{
> +    conring_puts(str, len);
> +
> +    if ( !console_locks_busted )
> +        tasklet_schedule(¬ify_dom0_con_ring_tasklet);
> +}
> +
>  #ifdef CONFIG_X86
>  static inline void xen_console_write_debug_port(const char *buf, size_t len)
>  {
> @@ -669,8 +681,44 @@ static inline void xen_console_write_debug_port(const char *buf, size_t len)
>                     : "=&S" (tmp), "=&c" (tmp)
>                     : "0" (buf), "1" (len), "d" (XEN_HVM_DEBUGCONS_IOPORT) );
>  }
> +
> +static void xen_console_write(const char *str, size_t len)
> +{
> +    if ( xen_guest )
> +        xen_hypercall_console_write(str, len);
> +    else
> +        xen_console_write_debug_port(str, len);
> +}
> +#else
> +static inline void xen_console_write(const char *str, size_t len)
> +{

opt_console_xen would only be set on x86 with the current command line
parsing done in console_init_preirq(), so you could add an
ASSERT_UNREACHABLE() here.

> +}
>  #endif
>  
> +/*
> + * Write characters to console.
> + *
> + * That will handle all possible scenarios working w/ console
> + * - serial console;
> + * - video output;
> + * - __HYPERVISOR_console_io hypercall (x86 only);
> + * - debug I/O port (x86 only);
> + * - forward to Xen event channel.

"Xen event channel" is not the correct term.  I would use "PV
console".  The event channel is just used to send the notification.

> + */
> +static void console_write(const char *str, size_t len)
> +{
> +    ASSERT(rspin_is_locked(&console_lock));
> +
> +    console_serial_puts(str, len);
> +    video_puts(str, len);
> +
> +    if ( opt_console_xen )
> +        xen_console_write(str, len);

Are you sure this builds?  opt_console_xen is only defined on x86, and
AFAICT console_write() is generic.  AFAICT you need to keep the X86
preprocessor guards, or alternatively do something like:

#define opt_console_xen false

For non-x86 arches in xen/console.h

> +
> +    if ( use_conring )
> +        conring_write(str, len);
> +}
> +
>  static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
>                                  unsigned int count)
>  {
> @@ -691,28 +739,8 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer,
>  
>          if ( is_hardware_domain(cd) )
>          {
> -            /* Use direct console output as it could be interactive */
>              nrspin_lock_irq(&console_lock);
> -
> -            console_serial_puts(kbuf, kcount);
> -            video_puts(kbuf, kcount);
> -
> -#ifdef CONFIG_X86
> -            if ( opt_console_xen )
> -            {
> -                if ( xen_guest )
> -                    xen_hypercall_console_write(kbuf, kcount);
> -                else
> -                    xen_console_write_debug_port(kbuf, kcount);
> -            }
> -#endif
> -
> -            if ( opt_console_to_ring )
> -            {
> -                conring_puts(kbuf, kcount);
> -                tasklet_schedule(¬ify_dom0_con_ring_tasklet);
> -            }
> -
> +            console_write(kbuf, kcount);
>              nrspin_unlock_irq(&console_lock);
>          }
>          else
> @@ -813,31 +841,9 @@ long do_console_io(
>   * *****************************************************
>   */
>  
> -static bool console_locks_busted;
> -
>  static void __putstr(const char *str)
>  {
> -    size_t len = strlen(str);
> -
> -    ASSERT(rspin_is_locked(&console_lock));
> -
> -    console_serial_puts(str, len);
> -    video_puts(str, len);
> -
> -#ifdef CONFIG_X86
> -    if ( opt_console_xen )
> -    {
> -        if ( xen_guest )
> -            xen_hypercall_console_write(str, len);
> -        else
> -            xen_console_write_debug_port(str, len);
> -    }
> -#endif
> -
> -    conring_puts(str, len);
> -
> -    if ( !console_locks_busted )
> -        tasklet_schedule(¬ify_dom0_con_ring_tasklet);
> +    console_write(str, strlen(str));
>  }
>  
>  static int printk_prefix_check(char *p, char **pp)
> @@ -1171,6 +1177,9 @@ void __init console_endboot(void)
>  
>      video_endboot();
>  
> +    use_conring = opt_console_to_ring;
> +    smp_wmb();

Do you really need the barrier?  If so it would need a comment
describing exactly why it's needed.  I don't think it's possible for
the write to be reordered past the return of the function, which would
be enough to ensure correctness?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 12:07:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 12:07:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855942.1268716 (Exim 4.92)
	(envelope-from )
	id 1tLhyt-0004mp-2a; Thu, 12 Dec 2024 12:07:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855942.1268716; Thu, 12 Dec 2024 12: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 1tLhys-0004mi-W2; Thu, 12 Dec 2024 12:07:46 +0000
Received: by outflank-mailman (input) for mailman id 855942;
 Thu, 12 Dec 2024 12:07: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 1tLhys-0004mA-0Q
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 12:07:46 +0000
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [2a00:1450:4864:20::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b17d787e-b881-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 13:07:44 +0100 (CET)
Received: by mail-ej1-x62b.google.com with SMTP id
 a640c23a62f3a-a9a0ef5179dso78469566b.1
 for ; Thu, 12 Dec 2024 04:07:44 -0800 (PST)
Received: from localhost ([217.156.233.154]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa657abb2fbsm808291566b.128.2024.12.12.04.07.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 04:07: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: b17d787e-b881-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1734005263; x=1734610063; darn=lists.xenproject.org;
        h=in-reply-to:references:subject:cc:to:from:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=aEH3svm+ODWbKyLiOHf4AvTgW1h4RyA0BCxw3M+F/jI=;
        b=WF9cf7uRP/kEFdeS2U7lJzmyYI2/I8tR8XgP09vSN7HTSIt//+cVruVx/cwAGJ/WnJ
         G0iLkSsfGm7YpDm2VT7QmtTM/e4W7wSgm7Fgyy6i6eTQNm0tN+a7QP817xu4N2Fc2oY8
         uBUTF/BVCzeZucT7cZ5TjbfwQu5thzdHdljak=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734005263; x=1734610063;
        h=in-reply-to:references:subject:cc:to:from:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=aEH3svm+ODWbKyLiOHf4AvTgW1h4RyA0BCxw3M+F/jI=;
        b=CrcLNgpZjUivI0trCBz5eUtdc9sjDlbhlnPaM2jF2eZVL3bQeKyGX66v54RXPT/Xuy
         eIYUE/4h3OFO0Jxv1jRGZ8SuPcW4bcg5TmOdH6CpmUTUA0kvbR9zqJwdxaCLD8/ZN2Im
         DOWhlgm1+f1wxflJkIevVqDKO2uVmXvsQbhiZVxmYHRO7h/oCbIunepQTOJC+4mqNTMk
         PgJrKCaS4DXwPiN/d4QEJzLvk+j45oOoIi3hibK0jBsdbGWO5P6Zkqah5MIZ1l+OUjOj
         lBP5gYPFvY7kKVjOjTbgOBoVJ5rgGYBInp6Sn+WIxAP4yvkgDEBMDuo2ZKn6im4HiT7t
         L0VA==
X-Forwarded-Encrypted: i=1; AJvYcCWoCNFAbBJR721fYkC3zkE91dChibmSbhgv8rK1p2x4gWtXnPFtTv2lka1tk4OPzLVoU7Y6qfDGTLo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz/NnUDs5XoMfjUKScrQm1excOBI6Wzqy3neu/E2bkcSpWTSaL/
	omTa7gHIpFAfwAVBck2KGoO3mWuvJWksJWFY/CvYiCdVMMBiRpQ0DpAH3kRK6tI=
X-Gm-Gg: ASbGnctRq25RluGnDHjdaWqtT3nr6hPgYlNSNrYzTSGXlCWy9rt7XDnV7W1o/kizWaX
	XtqPFoCGU6HAN5YnGWQqNdc2yYp2+WGlWhJ1SZ6jE0+HQLlrMb96cFrNVSMNb6d2xu17XNsYOSD
	4QQhVVf6Rg0+s7FXnzqy6Wix0p8NA1ld2lPTcRF7lC4YLFKGzeL+oydNXWZF/1cBcW8lR+oEUBy
	WCBRngJCAEi9ZKxdwskfcwgTIhp8R4WZrcOzjLA5zyHDvL0BruAAmkOnFNnBV1uZQ==
X-Google-Smtp-Source: AGHT+IEzcs/KZs9ruRThh9nAbTayuQY11/6Aagz+I9L4zkKMIZvQLKQli236EywdsNn2d5ObrnuoXw==
X-Received: by 2002:a17:907:3faa:b0:aa6:824c:4ae6 with SMTP id a640c23a62f3a-aa6c1d02adamr470024366b.56.1734005263562;
        Thu, 12 Dec 2024 04:07:43 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Thu, 12 Dec 2024 12:07:42 +0000
Message-Id: 
From: "Alejandro Vallejo" 
To: "Jan Beulich" , "Bernhard Kaindl"
 
Cc: "Andrew Cooper" , "Julien Grall"
 , "Stefano Stabellini" ,
 
Subject: Re: [RFC PATCH] SYSCTL_numainfo.memsize: Switch spanned to present
 memory
X-Mailer: aerc 0.18.2
References: <10466e8c29b5f69774915bcf6562985c75e98bb7.1733224306.git.bernhard.kaindl@cloud.com> <0299582c-7261-4947-a2ac-bf3d62ccac14@suse.com> <3f527685-e1bf-4a87-8986-2b9620d14646@cloud.com> 
In-Reply-To: 

On Mon Dec 9, 2024 at 8:23 AM GMT, Jan Beulich wrote:
> On 05.12.2024 11:55, Bernhard Kaindl wrote:
> > On 03/12/2024 12:37, Jan Beulich wrote:
> >> On 03.12.2024 12:12, Bernhard Kaindl wrote:
> >>> This the 2nd part of my submission to fix the NUMA node memsize
> >>> retured in xen_sysctl_meminfo[].memsize by the XEN_SYSCTL_numainfo
> >>> hypercall to not count MMIO memory holes etc but only memory pages.
> >>>
> >>> For this, we introduced NODE_DATA->node_present_pages as a prereq.
> >>> With the prereq merged in master, I send this 2nd part for review:
> >>>
> >>> This RFC is for changing the value of xen_sysctl_meminfo[]->memsize
> >>> from NODE_DATA->node_spanned_pages << PAGE_SHIFT
> >>>    to NODE_DATA->node_present_pages << PAGE_SHIFT
> >>> for returing total present NUMA node memory instead of spanned range.
> >>>
> >>> Sample of struct xen_sysctl_meminfo[].* as presented by in xl info -n=
:
> >>>
> >>> xl info -n:
> >>> [...]
> >>> node:    memsize    memfree    distances
> >>>     0:  -> 67584 <-   60672      10,21
> >>>     1:     65536      60958      21,10
> >>>
> >>> The -> memsize <- marked here is the value that we'd like to fix:
> >>> The current value based node_spanned_pages is often 2TB too large.
> >>>
> >>> We're currently not using these often false memsize values in XenServ=
er
> >>> according to my code review and and Andrew seemed to confirm this as =
well.
> >>>
> >>> I think that the same is likely true for other Xen toolstacks, but of=
 course
> >>> to review this change or propose an alternaive is the purpose of this=
 RFC.
> >>>
> >>> Thanks,
> >>> Bernhard
> >>
> >> All of the above reads like a cover letter. What's missing is a patch
> >> description, part of which would be to clarify whether the field is
> >> indeed unused except for display purposes, or why respective users wou=
ld
> >> at least not regress from this change. What's also unclear is what
> >> comments you're actually after (i.e. what question(s) you want to have
> >> answered), seeing this is tagged RFC.
> > [...]
> >> Jan
> >=20
> > Hi Jan!
> >=20
> > The answer I'm looking for is which users to check, or to check with.
> >=20
> > For example, I know that Xapi can use xen_sysctl_meminfo[].memfree to
> > get a preference about the NUMA node use use when creating a domain
> > (when the new mode `numa_affinity_policy.best_effort` is enabled):
> > https://xapi-project.github.io/new-docs/toolstack/features/NUMA/
> >=20
> > A potential use of xen_sysctl_meminfo.memsize in Xen toolstacks is
> > less clear to me:
> >=20
> > The only potential use would be if some Xen toolstack would not like
> > to solely rely on [nid].memfree for NUMA placement.
> >=20
> > The question is if there are other NUMA aware toolstacks besides Xapi,
> > that would try to use it for e.g. planning the placement of domains.
> >=20
> > My in the Xapi and Xen repos only turned up a debug printf() in
> > xen-api's xen-api/xenopsd and in xen only the output of xl info -n.
> >=20
> > It seems questionable to me that any other toolstacks would rely on it,
> > especially as the value it returns currently is offset even 2GB on some
> > machines. I'd expect that this bug would have affected code using it.
> >=20
> > The answers I am looking for are acknowledgements of that or references=
=20
> > which users might use .memsize currently (that could be affected).
>
> IOW all questions to respective toolstack people.
>
> > Alternatively, I'd hope to get an idea what would be the method to=20
> > create a new revision of the numainfo hypercall:
> >=20
> > I guess it would be to add a new #define XEN_SYSCTL_numainfo_v2,
> > and if v2 is called, return [].memsize using [nid].node_present_pages=
=20
> > instead?
>
> That's a last resort, yes. Since sysctls aren't stable (yet), changing
> existing interfaces generally is an option. We merely want to figure
> how careful we need to be. It may be fine to do the change "silently",
> as you do now. A middle option might be to rename the field which has
> its meaning changed, such that anyone using the field will notice that
> they need to update their code, hopefully resulting in them checking
> what changed and hence what they may need to change.
>
> Jan

The biggest unknown is libvirt, I think. They use libxl and do use
libxl_get_numainfo(). I suspect they rely on this new semantic rather than =
the
old one, but didn't dig hard enough to find out. It may very well be just
informative, just as `xl info`.

  https://gitlab.com/libvirt/libvirt

If they don't rely on memsize meaning "node span" then this patch is best a=
s it
is now. Might be worth either checking their code or pinging them in their
mailing list or IRC to confirm.

If they do rely on the current semantics, adding a new field to
xen_sysctl_meminfo ought to be fine as long as you bump the interface versi=
on
on top of sysctl.h as well.

Cheers,
Alejandro

P.S: If going down the "new field" route, I'd also like to suggest replacin=
g
     uint64_t with uint64_aligned_t in xen_sysctl_meminfo while at it.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 12:11:26 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 12:11:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855956.1268726 (Exim 4.92)
	(envelope-from )
	id 1tLi2K-00073m-H8; Thu, 12 Dec 2024 12:11:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855956.1268726; Thu, 12 Dec 2024 12:11: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 1tLi2K-00073f-Dx; Thu, 12 Dec 2024 12:11:20 +0000
Received: by outflank-mailman (input) for mailman id 855956;
 Thu, 12 Dec 2024 12:11: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 1tLi2J-0006vx-HX
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 12:11:19 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 31271e37-b882-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 13:11:18 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5d0d32cd31aso653723a12.0
 for ; Thu, 12 Dec 2024 04:11:18 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d149a25ce7sm10149346a12.5.2024.12.12.04.11.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Dec 2024 04:11: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: 31271e37-b882-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734005478; x=1734610278; 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=3wtsy4PeGy3ryXQDKf3EoIlhjTLXPbh5i72ZTQs6twU=;
        b=St72Q73HKjxiOHyqOCHEi0/hTiDyuExGS8mIJm8TheQ3eZ4bavfaGTj4GvkTmpeDSq
         2Ws8H+OOi/L6eSbkHVbeNAm4yjp7Bn0lsWzfiB5xER0he9x2WKXXj/1UCnJ+NyX2Ierp
         muvwjS+xmcUR4BazFp84q6dNypG1Ah5Phedn8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734005478; x=1734610278;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=3wtsy4PeGy3ryXQDKf3EoIlhjTLXPbh5i72ZTQs6twU=;
        b=OVkbfMykGHo+2PNd4Xq6uixbXqoDqgdrUXUIMMgOuAZa4TWnorFH1rPNXZW/XlrfNP
         xedyozPMD5GdpkphZIz9jC8uh2RFV+lk/RSEyWpm54g5ai7JqCX6aRoCJtxUv9cKIvZJ
         VnRud33dX8FlvWZixabWrMaNak6F2WI9CA+vjPa17hkPNVIQAs7NAm2/HEyvWuCsD5gB
         IUesta5/0l9hauHPKPa365NAELrdeGTCO9295yO/Bsrzb83xahYa3Q367E2KDHaciXeH
         VW3NLELO99UgJ/40UGzvBlbwlDqpX92joUcV2lqljEaNeOu0ivw2DqR8KXLZe8oH3VQN
         yhjA==
X-Gm-Message-State: AOJu0Yx2OrIl2JjseceXorMU6eA1s0Buo4Eal2Ixu4h7s6Y63ugmjvsg
	BB1RR/Q7OEWc6CO+gJpyslwR/CbQc84YnhFWEy/JThe8+PiuNM0Ks40CgFok3po=
X-Gm-Gg: ASbGncv+z45WxvwH1W91tK/OmLpDyjsTNsre+Z2cCykwo25vcAlWRHkknOOJKHYPWxX
	WQtQMMedUtyZbIzyMbOhW7yXG2j7UCP7acOXueZO4NaktQerKMf2KeeyTM6jAnDqYftP+n5K9QD
	/B09IQOkhFF2ghwDKIvt9rhjUMJcdEfXdE4PzxJ6cwNa8+tXD10pujDm/oDvLzplpAJyCfMVz1f
	Cq0DuH40SyIX1chRCAKGprX3hq0KKEAkQTJ3LpmII8SrFhrIikF+Sa+U6O7+nAiSg==
X-Google-Smtp-Source: AGHT+IF0eXyKgv6a8A1ZKIdlnZljOZnyso8dB21we7zLuUXjdx3bIGBklSFl8WCu6qDoGaAytsatAQ==
X-Received: by 2002:a05:6402:2809:b0:5d3:da65:ff26 with SMTP id 4fb4d7f45d1cf-5d4fa1b29a2mr1840713a12.31.1734005477558;
        Thu, 12 Dec 2024 04:11:17 -0800 (PST)
Date: Thu, 12 Dec 2024 13:11:16 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Julien Grall ,
	Stefano Stabellini , dmukhin@ford.com
Subject: Re: [PATCH v2 09/35] x86/domain: print emulation_flags
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-9-e9aa923127eb@ford.com>
 
 <8fa61060-3c00-453e-be47-3a60671dc7df@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8fa61060-3c00-453e-be47-3a60671dc7df@suse.com>

On Thu, Dec 12, 2024 at 12:53:45PM +0100, Jan Beulich wrote:
> On 11.12.2024 16:19, Roger Pau Monné wrote:
> > On Thu, Dec 05, 2024 at 08:41:39PM -0800, Denis Mukhin via B4 Relay wrote:
> >> --- a/xen/arch/x86/domain.c
> >> +++ b/xen/arch/x86/domain.c
> >> @@ -818,11 +818,15 @@ int arch_domain_create(struct domain *d,
> >>  
> >>      if ( !emulation_flags_ok(d, emflags) )
> >>      {
> >> -        printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation "
> >> +        printk(XENLOG_G_ERR "d%d: Xen does not allow %s %sdomain creation "
> > 
> > gprintk(XENLOG_ERR, "...
> > 
> > Might be more natural now that we have the macro (together with Jan's
> > suggestion to use %pd (same below).
> 
> Yet why would we want to log current here, as gprintk() does?

Right - I've forgotten that gprintk already prepends %pd.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 12:15:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 12:15:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855966.1268736 (Exim 4.92)
	(envelope-from )
	id 1tLi6P-00009N-2n; Thu, 12 Dec 2024 12:15:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855966.1268736; Thu, 12 Dec 2024 12:15: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 1tLi6O-00009G-Ui; Thu, 12 Dec 2024 12:15:32 +0000
Received: by outflank-mailman (input) for mailman id 855966;
 Thu, 12 Dec 2024 12:15: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 1tLi6N-00009A-V6
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 12:15:31 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c618f9a6-b882-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 13:15:28 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-aa6c0d1833eso84585766b.1
 for ; Thu, 12 Dec 2024 04:15:28 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa678f0ff87sm674894566b.131.2024.12.12.04.15.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Dec 2024 04:15: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: c618f9a6-b882-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734005728; x=1734610528; 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=Zgp90Rnf5B5SQbyo5cDlBJU6psBYT5wWQKaHJSUi3VY=;
        b=s430O67fSa3zW1FkwriZqRqrDrjBRsKtn3OHCjIsD4bjdOr1ZW3dEnlLDeqjbhTI3j
         DQytgJuhGu452SwYcZShpMo1clHZHuBEBnUgqdbly0hYOByUjDOSArWE5bcPVzJThXoW
         czbhcU6KYkkpnQ1BHg6Vg6p0389Wk1+1P054A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734005728; x=1734610528;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=Zgp90Rnf5B5SQbyo5cDlBJU6psBYT5wWQKaHJSUi3VY=;
        b=QhjmxTZ45vNIR1Jo3PD5HJIFPdW8SSpkvCzeYd7tMEtWSWTasghBbZTuzBuPg3WJ5D
         lqQtzL/E/mGNftz1YJspE9YEvOQ6nyqx1mVrMm6/L4zwy3wbT+OTvz32HKHdB3MSi9Dx
         2PJ8CgzzNMCClBAXC47/t3hN6v8HViAxe4c9Cby7fiQxydCWQJpNwa5pjsC3KDjznve7
         MsBQFRhZKQhrEb+nlnLQ8HcXHT9oLGpX0RQgL55aflBqPsZqFPE9hbeBxp/bOcfJxaPc
         O01cWVo8d8ryhbsi/U9fTNvZ/AgqPCojBTMPZRKZRDnboQZ1I58y4bl6D3HeON4oWr9Z
         tW9g==
X-Forwarded-Encrypted: i=1; AJvYcCWtB147T+ZHsoJY1nD4/9qyaENLdtpiJPHD01byRzlbQxeyPi3isyvY8a2Ube4SuKMnFfzaNOM/ydw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzw+3A0wLGotNzSkX46xLLbwGy6GQgSm4SKtEEzH39iOW85Cfjh
	Q/zAVJ6Q1zVWqaI/6b2n2mKYFv0UT2lSPnz3eT52xI1evVWhjEIa4RpT35SJMtTxOTH68nPCNgA
	F
X-Gm-Gg: ASbGncvvacDBjFkXfs7+572+LGMbsnGS4VUXMOh59YEcTUbH3Q7ALxtkuAwFA0G+J6Q
	LJCwdgJrlkho1EmDXchYwa4vKLZR4Gi3dY5Cu/W7Kr4YXUhLnziBpVNk05Jge0vWZTKPWILhlYz
	iGWyv0bPGgqNmXjVKIL1XIrtGSdvX/OLh2mjgcqxQPQuZZraYHY74tBILqUouENPNdl1qP8Z9Nv
	leDElmtJbR7dWDGXhEbBW4nZyKPeNtRDuYPjSDVmdSU/71hC9o4Df3k5c3/2I0qPg==
X-Google-Smtp-Source: AGHT+IG82leLf/1H0HoDZxeRc0Zf/Q7vIpaTjnAAe6SRoJdveanQ9oasCS9bY1OI1PIJD4zonnSEEg==
X-Received: by 2002:a17:906:3287:b0:aa6:ac9b:681f with SMTP id a640c23a62f3a-aa6b1398119mr629487366b.43.1734005727568;
        Thu, 12 Dec 2024 04:15:27 -0800 (PST)
Date: Thu, 12 Dec 2024 13:15:26 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 16/35] xen/console: introduce printk_common()
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-16-e9aa923127eb@ford.com>
 
 <8e5ce2dd-f888-42a3-937f-98ed1269c66c@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8e5ce2dd-f888-42a3-937f-98ed1269c66c@suse.com>

On Thu, Dec 12, 2024 at 12:57:25PM +0100, Jan Beulich wrote:
> On 12.12.2024 10:14, Roger Pau Monné wrote:
> > On Thu, Dec 05, 2024 at 08:41:46PM -0800, Denis Mukhin via B4 Relay wrote:
> >> From: Denis Mukhin 
> >>
> >> Introduce new printk() variant for convenient printouts which skip '(XEN)'
> >> prefix on xen console. This is needed for the case when physical console is
> >> owned by a domain w/ in-hypervisor UART emulation enabled.
> > 
> > IIRC the ns8250 can only send or receive one byte (character) at a
> > time, so you should likely put that on the console as soon as it's
> > received?
> > 
> > For the hardware domain we explicitly don't buffer writes to the
> > console (see guest_console_write() hardware domain special handling).
> > 
> > I wonder however how you deal with domains that don't have the console
> > focus (ie: != console_rx), as for those I think you still want to use
> > the (d) prefix?
> 
> Imo no matter what domain has the focus, the (d) prefix should
> always be logged. Just to avoid possible confusion.

WE don't do that currently for the hardware domain, because we avoid
doing any kind of line processing, as characters from the hardware
domain are send straight to the console without waiting for the
newline terminator (like we do for other domains).

Are you suggesting that in case of the console input being shared
between multiple domains they should all be treated as plain domUs and
thus lines should be buffered?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 12:16:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 12:16:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855977.1268746 (Exim 4.92)
	(envelope-from )
	id 1tLi6y-0000ic-DO; Thu, 12 Dec 2024 12:16:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855977.1268746; Thu, 12 Dec 2024 12: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 1tLi6y-0000iV-Aa; Thu, 12 Dec 2024 12:16:08 +0000
Received: by outflank-mailman (input) for mailman id 855977;
 Thu, 12 Dec 2024 12:16: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 1tLi6w-0000RY-Kd
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 12:16:06 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d9390dfe-b882-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 13:16:00 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-aa692211331so109563666b.1
 for ; Thu, 12 Dec 2024 04:16:05 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa6845ab4absm601774666b.73.2024.12.12.04.16.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Dec 2024 04:16: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: d9390dfe-b882-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734005764; x=1734610564; 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=7V68edYQP2aEXF1VyCS3KEISttMbFwrmg4hxeGHKVek=;
        b=r4MeX4aQz/9VaMQlsR1rZGveFHcL6Eaz6+Oykh54F3bXgiwu0L29e7Bh0kjj4VNMVL
         mr0ZICqNb6NCSj9fyc95wsYkBJ1jmDfEYI5czE6uKLLMFume3pXO5HvBJVyb4qYtVbSy
         EbYo+IwsYDOmowoCKBJmb4C9UvaeO/TtqGnCA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734005764; x=1734610564;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=7V68edYQP2aEXF1VyCS3KEISttMbFwrmg4hxeGHKVek=;
        b=oKiXImlGQ9Q56dyttDtOM7K7bFFJl70VHwFPGCbmDwBkq3mKS22DEsIx7lw1q+LtnX
         bFh+0ij6MCIaRH62C7CysNAdMajO4UAh54dT8dHe5z6N0vb1RKLlTbmA1MxIHqEPepQr
         uf0sIDXRjDHfGV/u+75bpX9MTQBY3uBXkk+qkIbiTZ14APMzGleBXrU3OBUbC0vT4NEQ
         PdJu47gp5KGH2++r8qBFiezpWjknIkjdSh5ZuAXWLaP8xxH6ckpPJoCirz+aRhRexoah
         ADH/ns+djoXHrfOgIlHwTY9fzfFpa7bpHQZRDJtvMVPsXBd0MgsMXlIy7opqGbjH4CXl
         ukTg==
X-Forwarded-Encrypted: i=1; AJvYcCWdoKc+cvdNO+gKj6O1OvDMgsnn3fNVNn6wGdsESnmswJRqdZDHC520Hw6Qiw6Ka3Nyv8DE/crCXf8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwjJjl8hoP0JkrZDaI2OFWPB2Y1qqQOT0lttko9BZzBTnJL6H1s
	vJNtj+L7zFgYgc2d3p8/vhEgNzjG4p2jSbSxpoZFIr0hUkXgtMoCy9IhqnTBT0k=
X-Gm-Gg: ASbGncunJLkfMLiREk6yceuS+TdyYhfk/6t3Zp7P9gdsFMmkDNBpJIikHndU8OJLXpG
	b4ljJ5bk1103+PSNJrsGx6841OTP8QhzK34gvkOKnSScbj/lZQ6tyCysG/AWPtx8Ueiy5ZLAgEj
	RjeevA3dB2Gt7WRxFd8bUr5b+kk+UCPz64iQNiSgB6PZNARMqSE3ss9Y0JgMswcFUpx7tUxhk9I
	GeD/DUJ2jZMEso/d+h7xBgTgSUF3AxfPI9TFEdCSAkX+SvcBmFKjcPCe5iC5cF5/g==
X-Google-Smtp-Source: AGHT+IHq4E6eazJeWhzfcEpXvLT1g5EzvyONB8lNUWWrEIweNHOVdUQ7/GhlFWMCtZYP1WRB8Y5ktQ==
X-Received: by 2002:a17:907:7da0:b0:aa5:b1bb:10db with SMTP id a640c23a62f3a-aa6c40bd748mr263706166b.1.1734005764630;
        Thu, 12 Dec 2024 04:16:04 -0800 (PST)
Date: Thu, 12 Dec 2024 13:16:03 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 19/35] xen/console: introduce console_set_owner()
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-19-e9aa923127eb@ford.com>
 
 <1e36f66b-a423-428c-9b22-8fd58450f119@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1e36f66b-a423-428c-9b22-8fd58450f119@suse.com>

On Thu, Dec 12, 2024 at 12:59:30PM +0100, Jan Beulich wrote:
> On 12.12.2024 11:12, Roger Pau Monné wrote:
> > On Thu, Dec 05, 2024 at 08:41:49PM -0800, Denis Mukhin via B4 Relay wrote:
> >> +static struct domain *rcu_lock_domain_console_by_id(domid_t domid)
> >> +{
> >> +    struct domain *d;
> >> +
> >> +    d = rcu_lock_domain_by_id(domid);
> >> +
> > 
> > Nit: I would remove this newline.
> 
> Or even better make the function call the variable's initializer.

Indeed, didn't catch that one.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 12:29:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 12:29:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.855993.1268756 (Exim 4.92)
	(envelope-from )
	id 1tLiJa-00042L-Gw; Thu, 12 Dec 2024 12:29:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 855993.1268756; Thu, 12 Dec 2024 12:29: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 1tLiJa-00042E-Dk; Thu, 12 Dec 2024 12:29:10 +0000
Received: by outflank-mailman (input) for mailman id 855993;
 Thu, 12 Dec 2024 12:29: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 1tLiJZ-000428-TF
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 12:29:09 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id af0b09f7-b884-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 13:29:08 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5d3ecae02beso679411a12.0
 for ; Thu, 12 Dec 2024 04:29:08 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d3ec8ef816sm6784363a12.59.2024.12.12.04.29.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Dec 2024 04:29: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: af0b09f7-b884-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734006548; x=1734611348; 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=BdtAM5a0jtp+NJMY45ybX9EcbJQMLM5aL0o0xw5Fk0g=;
        b=fVL/afH9A1kDXhjNSti9lqlUZnOiQVw5pf7lx0ENd++J7uHzxUcuIRb05kVB4VT6tV
         f0K6cPloeKtdLRlNi94r5Kn5CykwM1PmJvGQzTo/11Gu6q5O98JRl2r/XEju5b/+K7kp
         cFPhRduzEJZaifNMrIaD6vaUmTA+vbzh657w8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734006548; x=1734611348;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=BdtAM5a0jtp+NJMY45ybX9EcbJQMLM5aL0o0xw5Fk0g=;
        b=ot+N1G5RcDzQUPhQtXDquPW9Kv0vkluKU7s/HkHnJt8zcpjE8q7hoQ9SK/42RFm0nz
         +cvlvlXk5+g+OHHnWsPZ7ikrB98OO67pEGvru6vYQm8AyQQMzQxX7tv/8Tz/6/oonKS8
         TF4jjW1FO0fJxL9W7gN2J4f/dfCQl4kLJbdozCtsNk8sMWjc4asPD6TmI4xVZjoRoraw
         5Y/WbdK4gkgvTU/rlXl+TBCt4Df0tQ2q0W2iweLJFjlSJlUyH3x4iB2PCkEzQ4m72EYO
         tPic8DpTCnbN3HawDKG3g3yN5qZimLD8nKcooku8qmM0r7dNmw3d22j8ulvxTG7DGoZa
         +aFw==
X-Gm-Message-State: AOJu0YxOAHDz3OYgv8TUq+iw7r5a4URZAsBh0jPZnMnDh1Q8/UwSiev0
	gDNR5yQkBG2jR2letex0VLns/2rt+qF21XDw19Tq3/ZLv9I6IgcP15RZqDLbZCarNDFhFl00pGO
	R
X-Gm-Gg: ASbGncu4tJ4SgWXuJXbCVuKsWP/4sHs3g15TiUX9Zx/KaQMTowL9xkxnM7Y0DmYOR3t
	41wPCs9S1FYUv3HM295zYmwyuAHjHlB/w9QttMfvFWmSFfJG6OCi7xFP0hOja3wl6YJc+3s8Y6X
	ej2w0Zbed+KpNy/6LfwsPwITdd0BF1TboE9axhuWa2epi46KrJPz7Ev0c9829N0TDW4hIR/+2Ah
	1cnYRlp44A2zmjUm9aD6tZZxzzFWvQCOhNvtTjJGEilO7sUaPW56WsIyF2uSJL9+g==
X-Google-Smtp-Source: AGHT+IHj2y0jWvbWEy51Hc3hZIJr+pfTdYN1K2U6JlgTdDfO77r4owG8ZVFsgIokvO7fDeUnJ46mRw==
X-Received: by 2002:a05:6402:2807:b0:5d4:4143:c082 with SMTP id 4fb4d7f45d1cf-5d6337dffb8mr51558a12.21.1734006547857;
        Thu, 12 Dec 2024 04:29:07 -0800 (PST)
Date: Thu, 12 Dec 2024 13:29:06 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 24/35] xen/console: introduce hwdom_crashconsole=
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-24-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-24-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:41:54PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> The new command line switch `hwdom_crashconsole=BOOL` allows to switch serial
> console input focus to xen for machine state inspection using keyhandler
> mechanism after the hardware domain crashes.
> 
> The new command line switch is aliased via `dom0=...,crashconsole` knob.
> 
> Such functionality can be useful while debugging dom0 bringup.
> 
> Signed-off-by: Denis Mukhin 
> ---
>  docs/misc/xen-command-line.pandoc |  5 +++++
>  xen/arch/x86/dom0_build.c         |  2 ++
>  xen/common/domain.c               | 14 +++++++++++++-
>  xen/include/xen/domain.h          |  1 +
>  4 files changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index 293dbc1a957ba6e668fd4d55d58e84f643822126..fb77d7dca1ea517f79d6713aa6909422f31e7724 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -806,6 +806,7 @@ Specify the bit width of the DMA heap.
>  
>  ### dom0
>      = List of [ pv | pvh, shadow=, verbose=,
> +                crashconsole=,
>                  cpuid-faulting=, msr-relaxed= ] (x86)
>  
>      = List of [ sve= ] (Arm64)
> @@ -839,6 +840,10 @@ Controls for how dom0 is constructed on x86 systems.
>      information during the dom0 build.  It defaults to the compile time choice
>      of `CONFIG_VERBOSE_DEBUG`.
>  
> +*   The `crashconsole` boolean instructs Xen to drop into emergency console
> +    in case of dom0 crash. May be useful for dom0 bringup on a custom

I think the 'a' is unneeded -> "on custom hardware."

I think however this would be clearer as:

"The `crashconsole` boolean instructs Xen to switch input console
focus to the hypervisor when dom0 shuts down and avoid performing
dom0 domain destruction.  Should only be used for debugging
purposes."

It's IMO not clear what "instructs Xen to drop into emergency console"
implies for Xen.

> +    hardware.
> +
>  *   The `cpuid-faulting` boolean is an interim option, is only applicable to
>      PV dom0, and defaults to true.
>  
> diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
> index e8f5bf5447bc47a6daa3d95787106a4c11e80d31..706aeec0ecbb565a415edbfb33ca2fd72967c560 100644
> --- a/xen/arch/x86/dom0_build.c
> +++ b/xen/arch/x86/dom0_build.c
> @@ -286,6 +286,8 @@ int __init parse_arch_dom0_param(const char *s, const char *e)
>          opt_dom0_cpuid_faulting = val;
>      else if ( (val = parse_boolean("msr-relaxed", s, e)) >= 0 )
>          opt_dom0_msr_relaxed = val;
> +    else if ( (val = parse_boolean("crashconsole", s, e)) >= 0 )
> +        opt_hwdom_crashconsole = !!val;
>      else
>          return -EINVAL;
>  
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index aab546c0a8535e4f007cbbc9c5c552bcf66b5807..4fe69f294158dda7b2e0b9d98d49c34e04131cb8 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -56,6 +56,13 @@ unsigned int xen_processor_pmbits = XEN_PROCESSOR_PM_PX;
>  bool opt_dom0_vcpus_pin;
>  boolean_param("dom0_vcpus_pin", opt_dom0_vcpus_pin);
>  
> +/*
> + * Hardware domain crash handler: if true, do not halt machine, but switch to
> + * Xen console for debugging.
> + */
> +bool opt_hwdom_crashconsole;

__ro_after_init.

> +boolean_param("hwdom_crashconsole", opt_hwdom_crashconsole);

This option doesn't seem to be documented at all in
xen-command-line.pandoc?

> +
>  /* Protect updates/reads (resp.) of domain_list and domain_hash. */
>  DEFINE_SPINLOCK(domlist_update_lock);
>  DEFINE_RCU_READ_LOCK(domlist_read_lock);
> @@ -1138,7 +1145,12 @@ int domain_shutdown(struct domain *d, u8 reason)
>      reason = d->shutdown_code;
>  
>      if ( is_hardware_domain(d) )
> -        hwdom_shutdown(reason);
> +    {
> +        if ( opt_hwdom_crashconsole )
> +            console_set_owner(DOMID_XEN);

Don't you need to pause all domain vCPUs and return early here to
avoid executing the rest of the function, that will likely destroy the
domain?

Maybe there's something I'm missing that prevents the hardware domain
destruction.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 12:47:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 12:47:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856006.1268765 (Exim 4.92)
	(envelope-from )
	id 1tLib8-0000tc-QY; Thu, 12 Dec 2024 12:47:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856006.1268765; Thu, 12 Dec 2024 12:47: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 1tLib8-0000tV-Nx; Thu, 12 Dec 2024 12:47:18 +0000
Received: by outflank-mailman (input) for mailman id 856006;
 Thu, 12 Dec 2024 12: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 1tLib7-0000tP-V8
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 12:47:17 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 36cf82ba-b887-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 13:47:15 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5d3e6274015so978455a12.0
 for ; Thu, 12 Dec 2024 04:47:15 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d3d00a0370sm8613889a12.6.2024.12.12.04.47.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Dec 2024 04:47: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: 36cf82ba-b887-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734007634; x=1734612434; 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=E+lwibPUPUtKfa/BiyW51T+1sphSyp6BBlkuj86kxWk=;
        b=p+CxU2qgLqufKXZD7o4KKI3pZx+UA942x+LWXJox0Kpz2UpQxBI06Ui2yrSGlPNq78
         IDb+1a4tTRJWv7cj9ENeBkBQlFxFL9t/rfN3fcBp6p5NxfwjoL0g6nWuLqeNFb0U1lf8
         8BXjbYDNSk2xfjxgn6nWp1fF/Lt7h/TeP0NM8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734007634; x=1734612434;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=E+lwibPUPUtKfa/BiyW51T+1sphSyp6BBlkuj86kxWk=;
        b=Hit3bx1dUr0rvcQ1CmLEGyFnRkc2xY4ozZw3VbLRm9T4dGgbT7zd/jR2fJY3Go2o2h
         MonU0QQti7ZnGJTnfgtYcn9BdzM4zrxkPmBZLCHCeAUhupqfrxYiKGikcpLfMLTj+Qt/
         lzIS9ogjNHD21uj99FPKxI5SlCxEEz3zsNz9aEftV5FoEQes5YBvLU/0gPTNhWt22ApN
         P8PLOc8jLPmlOH3M6Dfmgx4QZmVxhEurK57XvaJ9Vz3PPBj0EW1tr1DicJX4aE40C1vW
         eX7v3jh/EbZFQCJDwLyAmJZnBVl3gMLjMbhnkW886vblfBB5UbWJ1K/hsCjvO4OZ8Wdj
         lDdg==
X-Gm-Message-State: AOJu0YxbsaZfaZ9sbHskShk7H0x8RvbyUZS4ohk2etsQ3MJ6o+R9FJZ7
	S+0a2O10yFW+GWSdHSYCT4+wroeffVqEPTOoC60gKZmchw2IChh/kpqZy1VdXmU=
X-Gm-Gg: ASbGncssEwI4U9sfDbWZM9IMmfJHQoBQPDI3fmPyZMfCJ2d4bo4Ry70zXFolwTYDGBS
	QdPVA79fpcd8RswLvWVxLrZe2QCWMrMzAE9jdM+OpBIGTH+bqvIL82YAyq1fMLLt3YHLUmbmMnZ
	AMc4wKYfX7HIM0NRphFnbXDNHAoIBUSx0iqr7/KogcZM+NHTX+jVcJBh1myYMBTPTykx294C4us
	Kyj9oAaCVraN9P2CGXrCpAf881uMxHrMx16nVfN1DZLR5GW47AnxI0mzULlvN1uMQ==
X-Google-Smtp-Source: AGHT+IFwaZQTVzw8SudTv1zJfT8BNoBN+MMOuMT6DdIyv6TMMmIRiTHdVHkkaJZ0Ec9YRhGvGsxlCA==
X-Received: by 2002:a05:6402:4304:b0:5d0:e73c:b7f6 with SMTP id 4fb4d7f45d1cf-5d633ea9bb0mr110675a12.31.1734007634503;
        Thu, 12 Dec 2024 04:47:14 -0800 (PST)
Date: Thu, 12 Dec 2024 13:47:13 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 26/35] xen/console: make console buffer size
 configurable
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-26-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-26-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:41:56PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Add new CONRING_LOG_SHIFT Kconfig parameter to specify the boot console buffer
> size as a power of 2.
> 
> Bump default size to 32 KiB.
> 
> Link: https://gitlab.com/xen-project/xen/-/issues/185
> Signed-off-by: Denis Mukhin 

Thanks for taking care of this.

> ---
>  xen/drivers/char/Kconfig   | 23 +++++++++++++++++++++++
>  xen/drivers/char/console.c |  4 ++--
>  2 files changed, 25 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
> index e6e12bb4139717f9319031f51f5d20155d2caee2..3bc892fc38d8cdeb3c76ea44d747f712a8d0d372 100644
> --- a/xen/drivers/char/Kconfig
> +++ b/xen/drivers/char/Kconfig
> @@ -96,6 +96,29 @@ config SERIAL_TX_BUFSIZE
>  
>  	  Default value is 32768 (32KiB).
>  
> +config CONRING_LOG_SHIFT
> +	int "Console buffer size"
> +	range 14 25
> +	default 15
> +	help
> +	  Select the boot console buffer size as a power of 2.
> +	  Run-time console buffer size is the same as the boot console size,
> +	  unless enforced via 'conring_size=' boot parameter.
> +
> +	  Examples:
> +	    25 =>  32 MiB
> +	    24 =>  16 MiB
> +	    23 =>   8 MiB
> +	    22 =>   4 MiB
> +	    21 =>   2 MiB
> +	    20 =>   1 MiB
> +	    19 => 512 KiB
> +	    18 => 256 KiB
> +	    17 => 128 KiB
> +	    16 =>  64 KiB
> +	    15 =>  32 KiB
> +	    14 =>  16 KiB

It might be better to do something similar to what we do in
SERIAL_TX_BUFSIZE, that the user provides a value in KiB which is
rounded down to the nearest power of 2?

> +
>  config XHCI
>  	bool "XHCI DbC UART driver"
>  	depends on X86
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index d22fb4a253af26f9b51d91bd408e1dbf4bb5a7c1..581ee22b85302a54db5b9d5d28e8b2d689d31403 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -104,11 +104,11 @@ static int cf_check parse_console_timestamps(const char *s);
>  custom_runtime_param("console_timestamps", parse_console_timestamps,
>                       con_timestamp_mode_upd);
>  
> -/* conring_size: allows a large console ring than default (16kB). */
> +/* conring_size: allows a large console ring than default (32 KiB). */
>  static uint32_t __initdata opt_conring_size;
>  size_param("conring_size", opt_conring_size);

You also need to update xen-command-line.pandoc to mention the default
size is now set in Kconfig.  And here I would mention
CONFIG_CONRING_SIZE rather than explicit 32 KiB, because that's just
the default in Kconfig, but might not be the default in the build
itself.

FWIW, you could define:

#define _CONRING_SIZE        (CONFIG_CONRING_SIZE & (CONFIG_CONRING_SIZE - 1))

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 12:50:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 12:50:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856019.1268776 (Exim 4.92)
	(envelope-from )
	id 1tLieP-0002nE-8o; Thu, 12 Dec 2024 12:50:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856019.1268776; Thu, 12 Dec 2024 12:50: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 1tLieP-0002n7-5c; Thu, 12 Dec 2024 12:50:41 +0000
Received: by outflank-mailman (input) for mailman id 856019;
 Thu, 12 Dec 2024 12:50: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 1tLieN-0002OP-No
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 12:50:39 +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 b005e851-b887-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 13:50:38 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4361c705434so4001935e9.3
 for ; Thu, 12 Dec 2024 04:50: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-436255a0d5dsm15851425e9.27.2024.12.12.04.50.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 04:50:38 -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: b005e851-b887-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734007838; x=1734612638; 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=1IZaOfCpSXmNRz9T25v+4RtngXkGHxE0MxkPcywNabk=;
        b=NvR19gDk9tudhZ91bS6znXiydjQ7TkJdjX5PjL1m1Uu7tTvtcgtuhk96H74bCNGTy7
         w9q2VO0Ko3PzPmCBGkMjXYqQ7bxO+GZQIAMj6WFhqsLEpNfKA5wkfWqi3bO9Si6TtEPH
         BJXVk69Id2UYj6VNlg4jw07EUSu1vdDoM/rmCiZnGxhNU6+NmyRkgS/Eg8ukh4IrUUgj
         w+SIRgKzBxVyuF7HDGvxZmnbKpawmSnIUkPvlrFCkwxi+xWYrYaepYI/HO1QGTJcsWT7
         OKjzHrShSjptroaZOgzcUWzoGHmkjOtKYMP6F6Qr1DfqTgl6uN3o70ZMvcBOV2zfvSTq
         SQgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734007838; x=1734612638;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1IZaOfCpSXmNRz9T25v+4RtngXkGHxE0MxkPcywNabk=;
        b=eEZ9TJLc171tDLrTfDPBVTyV8bkA1pbQlHCfoH+StDmUrr8NLqxOgK1Tf3K0f5GVuK
         XtJvBvHHEGd09zslaba2E9LXJqQ3SleoHIb8cKpmIy1W40JwYYV2FPU5hkflJM2TOouj
         Rk1xChsLVJjZpt04+nFPQ96m/Zdep3Y8/shubUAhAC5UQwoNFTs5uvDVCyJwQ5FzHm5Y
         CtlsRvthin/lNDRvml51DN/UM+GZvcqJMfsfLhfsB/sThdWmawVNC4T0e7+Et1FCB+tz
         owz90DGclBAypbwxoA8jcc6+Iy6RLmz1aSxPhz/MK0NwQxb/FWx5p3NgIXsAdZYcyKaa
         foDQ==
X-Gm-Message-State: AOJu0YzvbXA5TmMwPrxkeb7Ga3SUrgLCblNpw7JjeUvvG/xWMvy02Q8T
	lncssM+A8FHu9GRAKms/LDXpaTCF5amjWJUwOjkHDnyjNcHFXZT/OR+S6fGa0Q==
X-Gm-Gg: ASbGncvtfmOX8/67ytqpuMIN70hPEcMrxX4PpUE4OJ40PE/13aIMeEqPgM+GANMV912
	cawoAPv1A8YQnR9KjihTcml9YlnUei5LPUzXgaG/zTrsqkNWQ8Lt+aQM3DBtMVXpH6yI/as+pxA
	G7cHFUxiJr1B35a0hgN7fmqAItYFpaILdqG8NT3wiBP+hxWGK4yOd/v9/YoAWZdxf7aCZGWEZRw
	EvF+flmcai4JOUMIMk8+yZifurKVHX4GJuWkSYM3cM1fWbg2/vXT4VKnHOPn5+DCibAQtxVeE3b
	puuqYJ0Rpao9JsbPipbkwZ6Q41TgubSo81HAB+I+iA==
X-Google-Smtp-Source: AGHT+IE5mgvC3wcWPfXRAByN8Ui8HW4lS3g0GfshOv21HDxwQ+AzMR+KkWeSy6hMwpicNkRuQcslzA==
X-Received: by 2002:a05:600c:4e4b:b0:434:f3a1:b214 with SMTP id 5b1f17b1804b1-4361c429603mr43454745e9.28.1734007838414;
        Thu, 12 Dec 2024 04:50:38 -0800 (PST)
Message-ID: <89735894-2f3f-4723-921c-2e1b4b455469@suse.com>
Date: Thu, 12 Dec 2024 13:50:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 09/35] x86/domain: print emulation_flags
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , Julien Grall ,
 Stefano Stabellini , dmukhin@ford.com
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-9-e9aa923127eb@ford.com>
 
 <8fa61060-3c00-453e-be47-3a60671dc7df@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 12.12.2024 13:11, Roger Pau Monné wrote:
> On Thu, Dec 12, 2024 at 12:53:45PM +0100, Jan Beulich wrote:
>> On 11.12.2024 16:19, Roger Pau Monné wrote:
>>> On Thu, Dec 05, 2024 at 08:41:39PM -0800, Denis Mukhin via B4 Relay wrote:
>>>> --- a/xen/arch/x86/domain.c
>>>> +++ b/xen/arch/x86/domain.c
>>>> @@ -818,11 +818,15 @@ int arch_domain_create(struct domain *d,
>>>>  
>>>>      if ( !emulation_flags_ok(d, emflags) )
>>>>      {
>>>> -        printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation "
>>>> +        printk(XENLOG_G_ERR "d%d: Xen does not allow %s %sdomain creation "
>>>
>>> gprintk(XENLOG_ERR, "...
>>>
>>> Might be more natural now that we have the macro (together with Jan's
>>> suggestion to use %pd (same below).
>>
>> Yet why would we want to log current here, as gprintk() does?
> 
> Right - I've forgotten that gprintk already prepends %pd.

FTAOD: It's %pv and logging current, which isn't what is being logged here
(an incoming struct domain *).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 12:53:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 12:53:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856031.1268786 (Exim 4.92)
	(envelope-from )
	id 1tLigY-0004Fu-K8; Thu, 12 Dec 2024 12:52:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856031.1268786; Thu, 12 Dec 2024 12: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 1tLigY-0004Fn-HT; Thu, 12 Dec 2024 12:52:54 +0000
Received: by outflank-mailman (input) for mailman id 856031;
 Thu, 12 Dec 2024 12:52: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 1tLigX-0004Fh-6x
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 12:52:53 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ff0ee83e-b887-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 13:52:51 +0100 (CET)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3862d161947so258750f8f.3
 for ; Thu, 12 Dec 2024 04:52: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
 5b1f17b1804b1-436256e05fcsm15657915e9.39.2024.12.12.04.52.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 04:52: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: ff0ee83e-b887-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734007970; x=1734612770; 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=uN3gUeNWduKGh7s7l7BMZRqec9xj6mow4csbPQ3FN7g=;
        b=ahhoG/9PJ6CZT1DP5LbOskJI6pVRVW1MJ9w8Gj/T5zGo5WVRrkTwOU+/XR0rpGR3eV
         c1G+eq0pR3pziXMt/Avsl/FDe9D19wAMtftFmaXc6xfJmKe9ec88RXBGOC9OBkmVpuTl
         7Q0cyG9XVQRDzjqdrYNzbSgv+NEi0H3mQC7VlT5mbRntdZrNWR6NVFiCkk71HpKAxeQL
         GuTYDZOcwuN9ta1kTlbphyZ44N2iSBX8Q8tA6lK21s8XmdTbnj0+obGBaeGjCKgJfqsX
         cO/JlbFujjIlXiusEHMicfm7cIuZsQcZSvNmFH4jrlOm/amR92jDXzVltAd0emTDbn8B
         DyJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734007970; x=1734612770;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=uN3gUeNWduKGh7s7l7BMZRqec9xj6mow4csbPQ3FN7g=;
        b=vrXLA3bkZCi1o3gR/CIF3W5ReMmGXzmxY4EzDjkXBCMSURWxkwkX5dWMMeX4nC7Fp6
         yRsOQNSvZGBKWdBKbCVNoyHB9nHpt85fUFeB5m2C0bOxuHjZ4Gpwa2kS3o1P7eUw2MqY
         zhi6bHHEHmyhC5r49OJoXVqCiBtQpTlxuV/PH8eZ/tvZZhkLyfE0hnaVi+BW2dnsJguH
         zDB4gzEVyTMp0gGt1Igcp1Ro0/I4r4mpSk99Zbsx9OIIdev8GQwrH0sq6JpRYjSRZK7T
         C5BOpRLKsw6JSh3hSh8mnBe57BkLh334H2eX+saLbRTod4VaeCHZe2O6v84OHGTARFEm
         7Pzw==
X-Forwarded-Encrypted: i=1; AJvYcCW/3kyTQ/FQwPUgfZBJy+VLkfT+wdN3D1Kjy/QYLJxVh8Nv/kUk4TXuRLbLxbd255Er3nB9798cOd4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz+nUolxnrvbLSygnP/96ReEFSgYj1FB8lzHue9/DYMMko237Xf
	Ro60Z2YYB2uZVvHHp2a8XPtrb95ssAb+Fk7kU3lF5Pb2Y0SI0m06E0FodOV6SAZuWSDJdjWR5Kk
	=
X-Gm-Gg: ASbGnctxgr3zP3sYlEwYhpm4T2wYq+tCxeu5Gbsscc8hzGLBdaQq0MGr2HwU/dEtuRf
	Z1L7Fqo1EjTf0mnqxZwNARvJreTva3B9K06It1qP3HvpGkc6sSp7qBjSoDuVedcayF+GEupFraf
	C+vFO6BMpS27p5A7ovHwqYqb3+TVHsxp3aoc4mf6VEqZ40dXkCIPCBkKAD47R8BWRx5b3lEjEX+
	nqewgol+xc+O5f0MkYT9TgT+3n4aHnsVH3vuro3HYo0xX7Vk/lahkkv5EBtZBAf+s17kY+T+/PO
	cqAoBbmxz111l3NPPDFABnxs/wY/6EeC3jeIuZDlSg==
X-Google-Smtp-Source: AGHT+IGIQ4Y215HfE1p1/3T2tW8yos0+320jQ8SzKctBmtEwcBE+Ik5j+2YDz56OPPP4GQcbm7YwdQ==
X-Received: by 2002:a5d:6c63:0:b0:385:f9db:3c4c with SMTP id ffacd0b85a97d-38787685894mr3003366f8f.9.1734007970662;
        Thu, 12 Dec 2024 04:52:50 -0800 (PST)
Message-ID: <9dad24ea-178f-48c8-a93b-5823c44b56ee@suse.com>
Date: Thu, 12 Dec 2024 13:52:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 16/35] xen/console: introduce printk_common()
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-16-e9aa923127eb@ford.com>
 
 <8e5ce2dd-f888-42a3-937f-98ed1269c66c@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 12.12.2024 13:15, Roger Pau Monné wrote:
> On Thu, Dec 12, 2024 at 12:57:25PM +0100, Jan Beulich wrote:
>> On 12.12.2024 10:14, Roger Pau Monné wrote:
>>> On Thu, Dec 05, 2024 at 08:41:46PM -0800, Denis Mukhin via B4 Relay wrote:
>>>> From: Denis Mukhin 
>>>>
>>>> Introduce new printk() variant for convenient printouts which skip '(XEN)'
>>>> prefix on xen console. This is needed for the case when physical console is
>>>> owned by a domain w/ in-hypervisor UART emulation enabled.
>>>
>>> IIRC the ns8250 can only send or receive one byte (character) at a
>>> time, so you should likely put that on the console as soon as it's
>>> received?
>>>
>>> For the hardware domain we explicitly don't buffer writes to the
>>> console (see guest_console_write() hardware domain special handling).
>>>
>>> I wonder however how you deal with domains that don't have the console
>>> focus (ie: != console_rx), as for those I think you still want to use
>>> the (d) prefix?
>>
>> Imo no matter what domain has the focus, the (d) prefix should
>> always be logged. Just to avoid possible confusion.
> 
> WE don't do that currently for the hardware domain, because we avoid
> doing any kind of line processing, as characters from the hardware
> domain are send straight to the console without waiting for the
> newline terminator (like we do for other domains).

Right, and that's kind of special, and aiui intentionally so. These are
the only un-prefixed lines logged.

> Are you suggesting that in case of the console input being shared
> between multiple domains they should all be treated as plain domUs and
> thus lines should be buffered?

No, I'm actually not suggesting anything here beyond perhaps reducing
the scope of this series to just what the equivalent of vpl011 would be
for the 8250 / 16550 case.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 14:21:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 14:21:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856058.1268796 (Exim 4.92)
	(envelope-from )
	id 1tLk46-0006AP-Ty; Thu, 12 Dec 2024 14:21:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856058.1268796; Thu, 12 Dec 2024 14:21: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 1tLk46-0006AI-QE; Thu, 12 Dec 2024 14:21:18 +0000
Received: by outflank-mailman (input) for mailman id 856058;
 Thu, 12 Dec 2024 14: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 1tLk45-0006A9-Iw
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 14:21:17 +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 57eb84b6-b894-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 15:21:14 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-5d3f249f3b2so817561a12.3
 for ; Thu, 12 Dec 2024 06:21:14 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d3cedbb8fesm8890319a12.22.2024.12.12.06.21.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Dec 2024 06:21:13 -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: 57eb84b6-b894-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734013273; x=1734618073; 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=gCBmeOoyE/4VgfiRB4jwDsmFs4HDFreoB7cO2NrDIhM=;
        b=H6rSrpgcwrKUOyhlzmu+QG6gCZ86XaLup37Ygtvt9ZpXuPsIGKj8zXsXXDEqOEftV0
         /wlQKaQcDm/2uyEH/cy7jgPvF5/yVCLXQJpJRXqAP3YrcmKtTJvl81omb/f6NyYwVwZd
         EdddDwUVmCNieg1Jno8hOdgbGKMTjnGPGX2ME=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734013273; x=1734618073;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=gCBmeOoyE/4VgfiRB4jwDsmFs4HDFreoB7cO2NrDIhM=;
        b=pLKOtBEuBvQTeL9ENuN3GsKEi8tlG7z5hZECNMkkije6dPtb4erVj4rN465V0QAJm+
         5IndKrZ0pPnYTYMMyW1E4qVC89O93SQASyCINuSeGEEBnvYfA2zdBG2tck3sI4marL7i
         IaGTtpKplTF5VadDFYdxkAxmEfD64WI7E+AYBJvtwNGHLExpwy6AS5ISOL6vdZ4e6ndm
         fsXQyGlUChfCFbkYid3yaLcY7iv/guXIobI+1wS+KiSXNtyoS9jJZtAS9jqcTcsq2q28
         dItvFgKbg2Y4XBbF0WIkcnVq4P6obLyzZ7jgOWwj3ibVNMmNn92p69JR7khEAwEou/eg
         QymA==
X-Gm-Message-State: AOJu0YwObIODtOGHao0qTfUDWv3jU9RCz/AQvfIv3C+sJaP2vwS5CBVl
	NLC8pBwPKZvLHCLqIrNM6HSW97b970fMDdmGRNy+Yv1RuyKm5JtQRVgcMvNdGvc=
X-Gm-Gg: ASbGncuphQJ2HRRUqK6hihI8cqwAe3t/9z8OJkRh+pSSECMpnPINq9QTJjL0CjnBQ4u
	1j2O3xuHN3tzPshcEfeLfAdOZtVN8oDbIutpa39J7Gxv64/NuAaXSlsspL/CK+0NL8bTEfsdeCk
	QjYTYKBJ4THxNIMujAmMWYh/70YKUPfjb5Valmt+Ni6catewkplHr6c3HLwIlFpi1ez/E+Vc+JL
	R5+dBCTr1m9p5ZEhGEyHswKcfyeUOIsKB8/WvawFkpfmci7pIBsBsZF1BWe1JpKGQ==
X-Google-Smtp-Source: AGHT+IEZw84v496fP9moR0cO66NB7YJYtJNUhODJpaiqxhZjHpsCP8GRx2l6Ljbu6RJCBrPyJR1KtA==
X-Received: by 2002:a05:6402:40c7:b0:5d3:ff93:f5f9 with SMTP id 4fb4d7f45d1cf-5d63238cf10mr905826a12.20.1734013273566;
        Thu, 12 Dec 2024 06:21:13 -0800 (PST)
Date: Thu, 12 Dec 2024 15:21:12 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 27/35] xen/console: flush console ring to physical
 console
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-27-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-27-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:41:57PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Messages printed before the serial and VGA consoles are initialized end up in
> the internal console buffer (conring). Flush contents of conring to all
> external consoles after external consoles are fully initialied.
> 
> Link: https://gitlab.com/xen-project/xen/-/issues/184
> Signed-off-by: Denis Mukhin 
> ---
>  xen/drivers/char/console.c | 54 +++++++++++++++++++++++++++++++++-------------
>  1 file changed, 39 insertions(+), 15 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 581ee22b85302a54db5b9d5d28e8b2d689d31403..a26daee9c4c4b1134d0ae3d105ffdb656340b6df 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -426,23 +426,35 @@ void console_serial_puts(const char *s, size_t nr)
>      pv_console_puts(s, nr);
>  }
>  
> -static void cf_check dump_console_ring_key(unsigned char key)
> +/*
> + * Write characters to physical console(s).
> + * That covers:
> + * - serial console;
> + * - video output.
> + */
> +static void console_puts(const char *str, size_t len)
> +{
> +    ASSERT(rspin_is_locked(&console_lock));
> +
> +    console_serial_puts(str, len);
> +    video_puts(str, len);
> +}
> +
> +/*
> + * Flush contents of the conring to the physical console devices.
> + */
> +static int console_flush(void)
>  {
>      uint32_t idx, len, sofar, c;
>      unsigned int order;
>      char *buf;
>  
> -    printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key);
> -
> -    /* create a buffer in which we'll copy the ring in the correct
> -       order and NUL terminate */
>      order = get_order_from_bytes(conring_size + 1);
>      buf = alloc_xenheap_pages(order, 0);
>      if ( buf == NULL )
> -    {
> -        printk("unable to allocate memory!\n");
> -        return;
> -    }
> +        return -ENOMEM;
> +
> +    nrspin_lock_irq(&console_lock);
>  
>      c = conringc;
>      sofar = 0;
> @@ -457,10 +469,23 @@ static void cf_check dump_console_ring_key(unsigned char key)
>          c += len;
>      }
>  
> -    console_serial_puts(buf, sofar);
> -    video_puts(buf, sofar);
> +    console_puts(buf, sofar);
> +
> +    nrspin_unlock_irq(&console_lock);
>  
>      free_xenheap_pages(buf, order);
> +
> +    return 0;
> +}
> +
> +static void cf_check dump_console_ring_key(unsigned char key)
> +{
> +    int rc;
> +
> +    printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key);
> +    rc = console_flush();
> +    if ( rc )
> +        printk("failed to dump console ring buffer: %d\n", rc);
>  }
>  
>  /*
> @@ -707,10 +732,7 @@ static inline void xen_console_write(const char *str, size_t len)
>   */
>  static void console_write(const char *str, size_t len)
>  {
> -    ASSERT(rspin_is_locked(&console_lock));
> -
> -    console_serial_puts(str, len);
> -    video_puts(str, len);
> +    console_puts(str, len);
>  
>      if ( opt_console_xen )
>          xen_console_write(str, len);
> @@ -1177,6 +1199,8 @@ void __init console_endboot(void)
>  
>      video_endboot();
>  
> +    /* NB: send conring contents to all enabled physical consoles, if any */
> +    console_flush();

This is way too late: at this point Xen has already finished booting,
and is about to handover execution to dom0.  Flushing here will result
in duplicating almost all Xen output already printed?

The flush needs to be done inside of console_init_preirq(), just
before printing xen_banner() I think.  This sequentially after the
console has been initialized.  Otherwise you are just duplicating
messages.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 14:30:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 14:30:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856071.1268806 (Exim 4.92)
	(envelope-from )
	id 1tLkCW-0006p7-Mj; Thu, 12 Dec 2024 14:30:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856071.1268806; Thu, 12 Dec 2024 14:30: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 1tLkCW-0006p0-Jp; Thu, 12 Dec 2024 14:30:00 +0000
Received: by outflank-mailman (input) for mailman id 856071;
 Thu, 12 Dec 2024 14:29: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 1tLkCV-0006ou-2a
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 14:29:59 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 90265fae-b895-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 15:29:58 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-aa69077b93fso93505566b.0
 for ; Thu, 12 Dec 2024 06:29:58 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa663334906sm787320766b.72.2024.12.12.06.29.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Dec 2024 06:29: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: 90265fae-b895-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734013797; x=1734618597; 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=/MFmPhYMWCD3uVwM5ZNOxirq5yWYQNSc8mUC050yNHo=;
        b=beoLKilw/B6ITPSVcm5IQcmFLKwFpC4imia4SKGO5z7e9gOKjdPBJRegZgAIQvk6lk
         3pvXgwsDiPRrf2l0LVf3VvWClEc7YHMzabwlqH0h14qxo0tsba8GE24xRmM8TVOrfW6/
         p90rArm7lzkDARpy1wgLPLwY/TR1ZocA4mzQs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734013797; x=1734618597;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/MFmPhYMWCD3uVwM5ZNOxirq5yWYQNSc8mUC050yNHo=;
        b=gjnl3XuxxTeDfNIJJpQm1owTzC44eq31bv2yF25dZmAqVVBF40N7JDk9ypZVWsMWMI
         pUf3S7IXU6F8w5eabJCSRqv82YtIVF08g/Et7GTouOq2OcLIj+LWxrNVSFEjXWVpn5Ro
         I1xxOI8KLfCtw6EtESoabO1x0JUDoPe+rF5rSMOBBin4drgp/6sQMoYL38cZe8ZaxxXN
         M23V++02gGa2w6Z88AZZRYoctRQMEOMg+C5+mLoiCfinQCNszSsEN5E1rnZeEiGrQXJp
         DAJe7X5wEUlj9HqHV6igBsouz3oa77pJyn5DkPO5CWqyS/ESFqbwhbUkp7j2oeSQFOIM
         hB7A==
X-Gm-Message-State: AOJu0YxhlKFi+S+osK8WituJh/qitw1FWFPYSPl0La4dLAMbKBElP2jn
	oPO9UZSxIDAPJxyyhBpQXs91BcUeL6MCoYcZjnmoUS6d8VHQ8sJsMJgAXDmWU40=
X-Gm-Gg: ASbGncvb6VJiUMDDsskfgEuo980702nIWAkMzX6uA28wfumJJpYC/gG1TBCd1IDnDuK
	iTMrmwILRhX9GuRJRfmKi16ueBXesY2Cwr3avjij3jbfTV3A5pGueB5mJe0SmVakzcuGaDzFNsp
	SeCC8IkXMKxut62X0qmP7bBrHHVcQ5KzD2x6sBN65wr4DRqbU6XRBNQT9lIussG9Sm2SBco8KjM
	9BMmiREmSg1zCD8hRjOBXWtes1OsM/iqFx0t/zU4miTm4/9VTR/hr3zMgBdEA6WSA==
X-Google-Smtp-Source: AGHT+IEEbO10q1B4Rvd1iwyZlTjjDIpOLsX6RxDwNalK7SqCsecOkRQ8nR2f6pgUcc0ligQwyriHjQ==
X-Received: by 2002:a17:906:328d:b0:aa6:ac19:b579 with SMTP id a640c23a62f3a-aa6c1b0a7d0mr409383966b.26.1734013797599;
        Thu, 12 Dec 2024 06:29:57 -0800 (PST)
Date: Thu, 12 Dec 2024 15:29:56 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 28/35] xen/8250-uart: add missing definitions
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-28-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-28-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:41:58PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Added missing definitions needed for NS8250 UART emulator.
> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/include/xen/8250-uart.h | 81 +++++++++++++++++++++++++++++++++------------
>  1 file changed, 60 insertions(+), 21 deletions(-)
> 
> diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
> index d13352940c13c50bac17d4cdf2f3bf584380776a..4a69b2b225140efda287bdf96fa0caa4aa70074f 100644
> --- a/xen/include/xen/8250-uart.h
> +++ b/xen/include/xen/8250-uart.h
> @@ -32,16 +32,22 @@
>  #define UART_MCR          0x04    /* Modem control        */
>  #define UART_LSR          0x05    /* line status          */
>  #define UART_MSR          0x06    /* Modem status         */
> +#define UART_SCR          0x07    /* Scratch pad          */
>  #define UART_USR          0x1f    /* Status register (DW) */
>  #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=1) */
>  #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=1) */
>  #define UART_XR_EFR       0x09    /* Enhanced function register (Exar) */
>  
> +/* ns8250 emulator: range of emulated registers [0..UART_MAX-1] */
> +#define UART_MAX          (UART_SCR + 1)
> +
>  /* Interrupt Enable Register */
>  #define UART_IER_ERDAI    0x01    /* rx data recv'd       */
>  #define UART_IER_ETHREI   0x02    /* tx reg. empty        */
>  #define UART_IER_ELSI     0x04    /* rx line status       */
>  #define UART_IER_EMSI     0x08    /* MODEM status         */
> +#define UART_IER_MASK \
> +    (UART_IER_ERDAI | UART_IER_ETHREI | UART_IER_ELSI | UART_IER_EMSI)
>  
>  /* Interrupt Identification Register */
>  #define UART_IIR_NOINT    0x01    /* no interrupt pending */
> @@ -51,12 +57,21 @@
>  #define UART_IIR_THR      0x02    /*  - tx reg. empty     */
>  #define UART_IIR_MSI      0x00    /*  - MODEM status      */
>  #define UART_IIR_BSY      0x07    /*  - busy detect (DW) */
> +#define UART_IIR_FE0      BIT(6, U) /* FIFO enable #0 */
> +#define UART_IIR_FE1      BIT(7, U) /* FIFO enable #1 */
> +#define UART_IIR_FE_MASK  (UART_IIR_FE0 | UART_IIR_FE1)
>  
>  /* FIFO Control Register */
> -#define UART_FCR_ENABLE   0x01    /* enable FIFO          */
> -#define UART_FCR_CLRX     0x02    /* clear Rx FIFO        */
> -#define UART_FCR_CLTX     0x04    /* clear Tx FIFO        */
> -#define UART_FCR_DMA      0x10    /* enter DMA mode       */
> +#define UART_FCR_ENABLE     BIT(0, U)   /* enable FIFO          */
> +#define UART_FCR_CLRX       BIT(1, U)   /* clear Rx FIFO        */
> +#define UART_FCR_CLTX       BIT(2, U)   /* clear Tx FIFO        */
> +#define UART_FCR_DMA        BIT(3, U)   /* enter DMA mode       */
> +#define UART_FCR_RESERVED0  BIT(4, U)   /* reserved; always 0   */
> +#define UART_FCR_RESERVED1  BIT(5, U)   /* reserved; always 0   */

We don't usually define reserved bits I think, as I assume those won't
be used by the code?

Maybe a reserved mask for the hole register, to ensure the access to
the register doesn't attempt to set reserved bits?  But even then the
best we can do when emulating is print a warning message.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 14:30:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 14:30:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856072.1268816 (Exim 4.92)
	(envelope-from )
	id 1tLkCh-00080T-TN; Thu, 12 Dec 2024 14:30:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856072.1268816; Thu, 12 Dec 2024 14:30:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLkCh-00080I-QR; Thu, 12 Dec 2024 14:30:11 +0000
Received: by outflank-mailman (input) for mailman id 856072;
 Thu, 12 Dec 2024 14:30: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 1tLkCg-0007zb-Ba
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 14:30:10 +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 964fd732-b895-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 15:30:08 +0100 (CET)
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-434a2033562so4855485e9.1
 for ; Thu, 12 Dec 2024 06:30: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
 ffacd0b85a97d-387824a3e38sm4137362f8f.23.2024.12.12.06.30.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 06:30: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: 964fd732-b895-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734013808; x=1734618608; 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=PxC+nt1AuYYNJgdbHbEjSDFpsMZk5KXvhCGek25nyj8=;
        b=R6ay6JCYXfpWNVpIrCIB/lWEx/vXkMpLPkHBBF3a9/nSY47AzPG6blZonbyeJGWv33
         m5v10/0bQ53J7p4RPRcpOEutdnorLOT/6YvcHKumTD4NnRDG3H3Buul7Gl/aWzyaiwrl
         gCQk0N7+tAzhDmGre3DUsAG3ejXH4FPjt4rs9Qb83sj/FViS4VezYK5tbMrgXzcaXlGK
         fiYW2cp3g9Gk1mYe0l1ejJGwX/bD+KCtJMZucR66QloeS5kvkyqKMD7IxsFOfy6JhiTB
         QIMYb1x7NJzwMKFmxZZdjYclWhi2mTGdEVK7O5dIQsAhbi8mne9R7SjKjKw+K5VjrO92
         Krvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734013808; x=1734618608;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=PxC+nt1AuYYNJgdbHbEjSDFpsMZk5KXvhCGek25nyj8=;
        b=RIEoqoejdsZnXgHm6GXOQ6XxNNuo4GWY+wUDDTXgv+N3BqI17NUCdW35inN7TPUZJl
         fnlTnDGNQfOk3KERhscqX160cuBy3wmNKgKE8UbbtB61fgxSRu+/DohEp1Atr+9p+8dw
         +CrU+NXoY4xYpimiS4pvF2w6jlGDMPlFr8YVDW8Qt9qWt/A7Kq2/ugg+YsPMSEvCjlIH
         c8jNGtePUKTudEhS/ATtw0fdMsp30xo4P4XAkKhAkGGO28iiR8X/xOamK4nYIAzEKh2B
         Vd83iTSBxnJdgEvhZr92T63ndBvkyharCGJk9OwiDawnpEbeCw1/nBjBh4gIfPRjfSyX
         6XXw==
X-Forwarded-Encrypted: i=1; AJvYcCXtMEcZXw9V3N8apD9HId9Hct2o8XJhg6QJaaDPUW6fAuY3jZvrxOsenxCDlX7bzTjRYyMWRK0CPeE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YysvM4EKwgYNtF+I9ZFEmLHPBt2YyAL6EdE19/dGaFv2Pkixwd+
	RFP4bDWxF2BYGr7NjbUrTvdn4SWO+Vdx6NoR0ypNtm4QmKZ5eEN+J25CaTzH4Q==
X-Gm-Gg: ASbGnctltxB4ovpQpPLaXHOG/TZF+Wr0w0kk537jaaDGi255dNv7Yg5nteCWFUR8TQ0
	8B6NvZrdApXErXDTyCR5zryFGU+uVb+uHTeMT83bHLybLJajc7vXqEX8sCqGAel4r3LE/ZtY56H
	X6ejGwDsRv4u6boIPhGIolz7k3pqd8fe9ku9m20DHdeamW0X/tEzVEpGaGpZYXkxlLzI1fIh36T
	n0mB53noK/4p+aYvtPUyiN/7ksrxT5NebMXyF0Lzu3YFdFqhZ/oVJUB/wxvQ9n5dh2lLIsjvvq4
	SpL3yGbqUVUiKUSljApv2Y8ceFe9swHeH95junZvOA==
X-Google-Smtp-Source: AGHT+IGgts9O2Nr/1A4I3lTNWlkzsPhHq8uT+HTgOFuMCl81bvYcinDvDev1NsF2Gca7awtl+pq3Mg==
X-Received: by 2002:adf:e18b:0:b0:385:e429:e591 with SMTP id ffacd0b85a97d-3878768f817mr2872328f8f.23.1734013807798;
        Thu, 12 Dec 2024 06:30:07 -0800 (PST)
Message-ID: <9056a92d-8e91-4f2d-a8f3-5cde378f6c6f@suse.com>
Date: Thu, 12 Dec 2024 15:30:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/3] Add stack protector
To: Andrew Cooper 
Cc: Julien Grall , Stefano Stabellini
 , Anthony PERARD ,
 Samuel Thibault ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Bertrand Marquis ,
 Michal Orzel ,
 "xen-devel@lists.xenproject.org" ,
 Volodymyr Babchuk 
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
  <87pllx3gib.fsf@epam.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 12.12.2024 02:17, Andrew Cooper wrote:
> (With the knowledge that this is a disputed Kconfig pattern, and will
> need rebasing), the way I want this to work is simply:
> 
> diff --git a/xen/Makefile b/xen/Makefile
> index 0de0101fd0bf..5d0a88fb3c3f 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -434,6 +434,9 @@ endif
>  
>  ifeq ($(CONFIG_STACK_PROTECTOR),y)
>  CFLAGS += -fstack-protector
> +ifeq ($(CONFIG_X86),y)
> +CFLAGS += -mstack-protector-guard=global
> +endif
>  else
>  CFLAGS += -fno-stack-protector
>  endif
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 9cdd04721afa..7951ca908b36 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -28,6 +28,7 @@ config X86
>         select HAS_PCI_MSI
>         select HAS_PIRQ
>         select HAS_SCHED_GRANULARITY
> +       select HAS_STACK_PROTECTOR if
> $(cc-option,-mstack-protector-guard=global)
>         select HAS_UBSAN
>         select HAS_VMAP
>         select HAS_VPCI if HVM
> 
> 
> 
> Sadly, it doesn't build.  I get a handful of:
> 
> prelink.o: in function `cmdline_parse':
> /home/andrew/xen.git/xen/common/kernel.c:216:(.init.text+0x20f2): failed
> to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
> --no-relax
> /home/andrew/xen.git/xen/common/kernel.c:230:(.init.text+0x246f): failed
> to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
> --no-relax
> 
> which is more toolchain-whispering than I feel like doing tonight.

Imo the root of the problem is that the compiler doesn't itself mark
__stack_chk_guard hidden (it does so for __stack_chk_fail, albeit only for
32-bit code), and hence finds it necessary to use @gotpcrel to access the
variable. Even if the linker managed to relax all of these, it would then
still be less efficient compared to direct RIP-relative accesses.

I also can't see how we might be able to override the compiler's internal
declaration to mark it hidden (the same appears to be true for other items
the declares internally, like the retpoline thunks or even strcmp() et al).
Passing -fvisibility=hidden doesn't make a difference (just as another
data point).

Playing with -fstack-protector* flavors, I observe:
- -fstack-protector causing several failures, like you observed, oddly
  enough exclusively from __init functions,
- -fstack-protector-all and -fstack-protector-strong each causing a single
  (but respectively different) failure, for apparently random non-__init
  functions.
Taking this together it very much smells like a linker issue. I'll see
about checking there further.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 14:56:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 14:56:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856101.1268832 (Exim 4.92)
	(envelope-from )
	id 1tLkcO-0005X9-2i; Thu, 12 Dec 2024 14:56:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856101.1268832; Thu, 12 Dec 2024 14:56:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLkcN-0005X2-UY; Thu, 12 Dec 2024 14:56:43 +0000
Received: by outflank-mailman (input) for mailman id 856101;
 Thu, 12 Dec 2024 14:56: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 1tLkcN-0005Ww-DY
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 14:56:43 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4b24f37f-b899-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 15:56:41 +0100 (CET)
Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com
 [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-588-TSb6-2JgOC-gug9412_iXQ-1; Thu, 12 Dec 2024 09:56:38 -0500
Received: by mail-wm1-f71.google.com with SMTP id
 5b1f17b1804b1-4359206e1e4so7171515e9.2
 for ; Thu, 12 Dec 2024 06:56:38 -0800 (PST)
Received: from [192.168.88.24] (146-241-48-67.dyn.eolo.it. [146.241.48.67])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4362557c457sm19247805e9.15.2024.12.12.06.56.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 06:56: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: 4b24f37f-b899-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1734015399;
	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=oL7oDzf/iu+owBEyFgADY3KtJbecvvlrXRMt6TBS380=;
	b=DeTuY93Gl+QN/i3NSufXohDh5kzQ5U46yxaBzDTGmmFpqioerQwohfCtNBrRf2YVQ/A/vf
	qHL0U/1TkrRuAVqYAU8oYfXmndUGM9+yJUKR7Kv1C++pqgQuajeQMr44mBK3YR/gHRwuZO
	ZEMNOE1WcmHFTmkM2nVLdSgErhzaYbk=
X-MC-Unique: TSb6-2JgOC-gug9412_iXQ-1
X-Mimecast-MFC-AGG-ID: TSb6-2JgOC-gug9412_iXQ
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734015397; x=1734620197;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=oL7oDzf/iu+owBEyFgADY3KtJbecvvlrXRMt6TBS380=;
        b=AXbltwZn+fWbNJqGxs/5OMBdP0altejP2yrfHVSfqctd1iEByg0es46hJk/QtVBdFE
         Yp3jbB8+zeUigo4+Mdy2H7oLLKYYAWYveVRDOM9spaFH351uQQen4YJZwGeVDV5JGDEq
         JNlCc88BPPelmBqT3Wkb4Gg6vVq8T0JlaWc1KWg4mC4UnkLpQoUnFS2QhdLof4aVaHHi
         7rgf1PKr7CUWct64BEhuc+o4Y1xQ5ttxfks846fVT49+vDz0HsPsqfb9ojM0+c7zfMNO
         Z4mj5a/TveVsAJkmaEonYs3KHDjvUNTMR7T37NNRX9TxCVCXELLGch8FfdbogkGn71vW
         vtqA==
X-Forwarded-Encrypted: i=1; AJvYcCUBcguf2PNgHmPFWL0DiVaK6eTXYolmVh6ZcbBWK16jVzUYpAlm4ENALoi9Cd3g4ZlJRm+qMRPtPMY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy53wtpPVdUGQJJvN2AHqlruyDNvXCaRkUIPlFC4P02AaCkMrS0
	VLlLBxtkSZ6rNZ2/Ai7xdGRP6PmPT8aMFSkRzAuO6eizbROatpCNMn7i1Q3StxJ+TxMMpc5doKC
	fYpAx73GNM/8GtW50ZLcOFYswoUFbrDd98G886alOUHrb41kIUIysP3EuzLD0DsRV
X-Gm-Gg: ASbGncvLYviR/CZRTjOl/8EHAAUGTTpRQTN20TzBM/zihSIHkTgW200pt1X+ZLUZCKM
	gnFRuu7O43ZeYeAFP2K+RWTC6khdCwJtKx9RxjeChFrDVT1+lMtLzc6H3b1Ac1ZfYmvNgBFBftK
	wry/Z5sQWrDXhTV8GriSIO/lR+B4k8VNIxXSTbG1T4c6yHb+OSnpxoRC36GdcGpD7+pDFvmiYOz
	7+SkaTCWTngXHFzuOncbznYq0lrMAZUCM3tT3JZ1dwqhqnqfgLTIw7k8wGFAZ9ZF75MG2n6OWmx
	gcN1cCU=
X-Received: by 2002:a05:600c:34cc:b0:434:fbe2:4f with SMTP id 5b1f17b1804b1-4361c430b5cmr63302745e9.23.1734015397016;
        Thu, 12 Dec 2024 06:56:37 -0800 (PST)
X-Google-Smtp-Source: AGHT+IH6jT4MvcNP0dxPJ6BKwDHdX4PrfqhYHXR4TAbgRNM6khL6oXpHiVnh7UfEpSYX/vLofOsSxA==
X-Received: by 2002:a05:600c:34cc:b0:434:fbe2:4f with SMTP id 5b1f17b1804b1-4361c430b5cmr63302405e9.23.1734015396688;
        Thu, 12 Dec 2024 06:56:36 -0800 (PST)
Message-ID: <8ee0cf91-c215-4015-90fc-32be6f22b7db@redhat.com>
Date: Thu, 12 Dec 2024 15:56:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 03/11] net/ethernet: Use never-managed version of
 pci_intx()
To: Philipp Stanner , amien Le Moal
 , Niklas Cassel ,
 Basavaraj Natikar , Jiri Kosina
 , Benjamin Tissoires ,
 Arnd Bergmann ,
 Greg Kroah-Hartman , Alex Dubov
 , Sudarsana Kalluru ,
 Manish Chopra , Andrew Lunn ,
 "David S. Miller" , Eric Dumazet ,
 Jakub Kicinski , Rasesh Mody ,
 GR-Linux-NIC-Dev@marvell.com, Igor Mitsyanko ,
 Sergey Matyukevich , Kalle Valo ,
 Sanjay R Mehta ,
 Shyam Sundar S K , Jon Mason ,
 Dave Jiang , Allen Hubbe ,
 Bjorn Helgaas ,
 Alex Williamson , Juergen Gross
 , Stefano Stabellini ,
 Oleksandr Tyshchenko ,
 Mario Limonciello , Chen Ni ,
 Ricky Wu , Al Viro ,
 Breno Leitao , Thomas Gleixner ,
 Kevin Tian ,
 Andy Shevchenko ,
 Mostafa Saleh , Jason Gunthorpe ,
 Yi Liu , Kunwu Chan ,
 Dan Carpenter ,
 "Dr. David Alan Gilbert" ,
 Ankit Agrawal ,
 Reinette Chatre ,
 Eric Auger , Ye Bin 
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
 linux-input@vger.kernel.org, netdev@vger.kernel.org,
 linux-wireless@vger.kernel.org, ntb@lists.linux.dev,
 linux-pci@vger.kernel.org, kvm@vger.kernel.org,
 xen-devel@lists.xenproject.org
References: <20241209130632.132074-2-pstanner@redhat.com>
 <20241209130632.132074-5-pstanner@redhat.com>
From: Paolo Abeni 
In-Reply-To: <20241209130632.132074-5-pstanner@redhat.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: VFg-QPmEhin6PmWLz6IcEXvTPCg1zMDoHJWWWo-lkIA_1734015397
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12/9/24 14:06, Philipp Stanner wrote:
> pci_intx() is a hybrid function which can sometimes be managed through
> devres. To remove this hybrid nature from pci_intx(), it is necessary to
> port users to either an always-managed or a never-managed version.
> 
> broadcom/bnx2x and brocade/bna enable their PCI-Device with
> pci_enable_device(). Thus, they need the never-managed version.
> 
> Replace pci_intx() with pci_intx_unmanaged().
> 
> Signed-off-by: Philipp Stanner 

Acked-by: Paolo Abeni 



From xen-devel-bounces@lists.xenproject.org Thu Dec 12 14:58:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 14:58:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856113.1268842 (Exim 4.92)
	(envelope-from )
	id 1tLkeI-00069X-G1; Thu, 12 Dec 2024 14:58:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856113.1268842; Thu, 12 Dec 2024 14: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 1tLkeI-00069Q-DL; Thu, 12 Dec 2024 14:58:42 +0000
Received: by outflank-mailman (input) for mailman id 856113;
 Thu, 12 Dec 2024 14:58: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 1tLkeH-00069I-9B
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 14:58:41 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 91bac255-b899-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 15:58:39 +0100 (CET)
Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com
 [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-148-w4Q-E6ceN7CWhDudgIcVDw-1; Thu, 12 Dec 2024 09:58:35 -0500
Received: by mail-wm1-f70.google.com with SMTP id
 5b1f17b1804b1-43627bb20b5so2996165e9.1
 for ; Thu, 12 Dec 2024 06:58:35 -0800 (PST)
Received: from [192.168.88.24] (146-241-48-67.dyn.eolo.it. [146.241.48.67])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4362559edc3sm19213025e9.22.2024.12.12.06.58.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 06:58: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: 91bac255-b899-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1734015518;
	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=mp7PByfrT26c6XlUU6lXZIxvrN1DU5qMvcLQpbxnk5A=;
	b=Q4ieOnsNtSrfUI+gNJ5dX/tEjo8dMVfuODtCVZfS6FOyjIt7UwqTlZwA+WjS2euJkvEA76
	6vOZLCCO0bldypzGkBwqRdSBgFbnuSyf2KQXfuEUfr0Q2xIodsWHV9wGw5yLybhHVKVOw1
	mrV+fa+GsdI0Mw0Mjd2g//eXko3EqNg=
X-MC-Unique: w4Q-E6ceN7CWhDudgIcVDw-1
X-Mimecast-MFC-AGG-ID: w4Q-E6ceN7CWhDudgIcVDw
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734015514; x=1734620314;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=mp7PByfrT26c6XlUU6lXZIxvrN1DU5qMvcLQpbxnk5A=;
        b=T3/lk2CdNFWJ/c0oORaqpNIJ8SQci14IT3XwPmSvnOVg3G6DxRgHAG7dzqalnu9ZYD
         O9Lix/tKDrpDrhyrDw/1yk51dbCX1o6ZJGPuZh+QMIr6cj/6YV8VSqKegUdhTTkZJ7Vi
         HXyd7WeSC8NukUKKYuDBf/SEGpou/BHCSl6DiQstX5NH25FAfFP8sYy4wC2uw1YE0/10
         r2PlFDL74nE4Fl/H7CM8VIJFGx6mbdTkMON2w4DlLmL4kLGAGPKNUMFOKOOMcpHsmPWH
         VDBWkcB6NrXD08P9M8ny9dPgRThf5Y0sVgOMXgjdgDLsvlIDNH1iOr6wHfLXueXrj3KE
         C3HQ==
X-Forwarded-Encrypted: i=1; AJvYcCXvkCSPoIXeudmmgLZA23Hl32LmLT/3hdsP0/A1SbPqrm82sPgl4H6GIJCkGUgMZxaYjdePZpF2ywU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwB1Z9EnWl7YshJ8zm78IRLu5BYHBDnw13X0olYsjs2ZXiGM8/c
	1wRgsuwAGtddNoun0huixqeCKuj1O9h8MPq764eOk/txvbF8yGgCR/VOcX53w4dgD57oA+fZc0G
	K/1xvNHkkNpn0YnSrYtN7EZC+InIlztmC8YL3MFBwoJ4VZuO25hoy59AdPCLyKmJh
X-Gm-Gg: ASbGnctKYdjDQgDXd42W6pN9l39CA+lrG3pIMSYZpge4kjDa2YEHD1o5CHyEIbtFuj8
	IdR9Tdi4PgfihWLFDz5PM1sBG4WggyoY7gBjqEodwMvmBj5hom/AmbXZb4fl4/hSgLN1M3GAhpy
	R2HH1QUImKJZgTeEXKgCKuwpwhOUozMLbthsY57tksxuZnCHqpi5SaX3liIanYR+aHeohFCKKid
	tOOO4pmAOH2YMJ9d1QR1SOyGHtU3h9kV+8lBTWh4rIDBuZbG2pp9ThKiT9e1XRo1fuUHpmqrnYD
	4gfQB9o=
X-Received: by 2002:a05:600c:1e89:b0:435:21a1:b109 with SMTP id 5b1f17b1804b1-436228239d4mr34776345e9.2.1734015514544;
        Thu, 12 Dec 2024 06:58:34 -0800 (PST)
X-Google-Smtp-Source: AGHT+IHoQPXURHNGvrny3f7vl2oVT9jWXY7D4FX6dkSlxmx2R9PGBk/+viTtA90lBPMFXjybTLaFQQ==
X-Received: by 2002:a05:600c:1e89:b0:435:21a1:b109 with SMTP id 5b1f17b1804b1-436228239d4mr34775655e9.2.1734015514130;
        Thu, 12 Dec 2024 06:58:34 -0800 (PST)
Message-ID: 
Date: Thu, 12 Dec 2024 15:58:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 11/11] Remove devres from pci_intx()
To: Philipp Stanner , amien Le Moal
 , Niklas Cassel ,
 Basavaraj Natikar , Jiri Kosina
 , Benjamin Tissoires ,
 Arnd Bergmann ,
 Greg Kroah-Hartman , Alex Dubov
 , Sudarsana Kalluru ,
 Manish Chopra , Andrew Lunn ,
 "David S. Miller" , Eric Dumazet ,
 Jakub Kicinski , Rasesh Mody ,
 GR-Linux-NIC-Dev@marvell.com, Igor Mitsyanko ,
 Sergey Matyukevich , Kalle Valo ,
 Sanjay R Mehta ,
 Shyam Sundar S K , Jon Mason ,
 Dave Jiang , Allen Hubbe ,
 Bjorn Helgaas ,
 Alex Williamson , Juergen Gross
 , Stefano Stabellini ,
 Oleksandr Tyshchenko ,
 Mario Limonciello , Chen Ni ,
 Ricky Wu , Al Viro ,
 Breno Leitao , Thomas Gleixner ,
 Kevin Tian ,
 Andy Shevchenko ,
 Mostafa Saleh , Jason Gunthorpe ,
 Yi Liu , Kunwu Chan ,
 Dan Carpenter ,
 "Dr. David Alan Gilbert" ,
 Ankit Agrawal ,
 Reinette Chatre ,
 Eric Auger , Ye Bin 
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
 linux-input@vger.kernel.org, netdev@vger.kernel.org,
 linux-wireless@vger.kernel.org, ntb@lists.linux.dev,
 linux-pci@vger.kernel.org, kvm@vger.kernel.org,
 xen-devel@lists.xenproject.org
References: <20241209130632.132074-2-pstanner@redhat.com>
 <20241209130632.132074-13-pstanner@redhat.com>
From: Paolo Abeni 
In-Reply-To: <20241209130632.132074-13-pstanner@redhat.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: EZHz_EX21hJITz_zMuEDfcwZJqnwOg8rTEdzfdk7i8w_1734015514
X-Mimecast-Originator: redhat.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12/9/24 14:06, Philipp Stanner wrote:
> pci_intx() is a hybrid function which can sometimes be managed through
> devres. This hybrid nature is undesirable.
> 
> Since all users of pci_intx() have by now been ported either to
> always-managed pcim_intx() or never-managed pci_intx_unmanaged(), the
> devres functionality can be removed from pci_intx().
> 
> Consequently, pci_intx_unmanaged() is now redundant, because pci_intx()
> itself is now unmanaged.
> 
> Remove the devres functionality from pci_intx(). Have all users of
> pci_intx_unmanaged() call pci_intx(). Remove pci_intx_unmanaged().
> 
> Signed-off-by: Philipp Stanner 
> ---
>  drivers/misc/cardreader/rtsx_pcr.c            |  2 +-
>  drivers/misc/tifm_7xx1.c                      |  6 +--
>  .../net/ethernet/broadcom/bnx2x/bnx2x_main.c  |  2 +-
>  drivers/net/ethernet/brocade/bna/bnad.c       |  2 +-
>  drivers/ntb/hw/amd/ntb_hw_amd.c               |  4 +-
>  drivers/ntb/hw/intel/ntb_hw_gen1.c            |  2 +-
>  drivers/pci/devres.c                          |  4 +-
>  drivers/pci/msi/api.c                         |  2 +-
>  drivers/pci/msi/msi.c                         |  2 +-
>  drivers/pci/pci.c                             | 43 +------------------
>  drivers/vfio/pci/vfio_pci_core.c              |  2 +-
>  drivers/vfio/pci/vfio_pci_intrs.c             | 10 ++---
>  drivers/xen/xen-pciback/conf_space_header.c   |  2 +-
>  include/linux/pci.h                           |  1 -
>  14 files changed, 22 insertions(+), 62 deletions(-)

For the net bits:

Acked-by: Paolo Abeni 



From xen-devel-bounces@lists.xenproject.org Thu Dec 12 15:07:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 15:07:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856130.1268852 (Exim 4.92)
	(envelope-from )
	id 1tLkmK-0000PQ-7u; Thu, 12 Dec 2024 15:07:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856130.1268852; Thu, 12 Dec 2024 15:07: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 1tLkmK-0000PJ-5O; Thu, 12 Dec 2024 15:07:00 +0000
Received: by outflank-mailman (input) for mailman id 856130;
 Thu, 12 Dec 2024 15:06: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 1tLkmI-0000PD-NU
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 15:06:58 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ba0a44b1-b89a-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 16:06:55 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5d3e829ff44so3527182a12.0
 for ; Thu, 12 Dec 2024 07:06:55 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d3f3cf8c6esm6481333a12.85.2024.12.12.07.06.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Dec 2024 07:06: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: ba0a44b1-b89a-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734016015; x=1734620815; 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=e0ufwB2b4FW4nolJ5aBbeFkKaQFRCaq1nBYehTHUsPQ=;
        b=ncVFZamjXhGS2hcRUr6CcPbRVZUnleaaukNcRo0DGYuccSauKomL0p3lubvZ2743xk
         Pe0F5DFDOEABJUyQKgF+Oswj5/DRrUReskBtov3qzt+zTGelfwFSH/BzrVvxWL5JwpLn
         1sYjkfo4elx3HGlJwjOsliLagRtHhyQU3BCvA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734016015; x=1734620815;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=e0ufwB2b4FW4nolJ5aBbeFkKaQFRCaq1nBYehTHUsPQ=;
        b=E/X0q/tcLUhX/aNTvd9fLGtxxuHSxgoUIQbpSWyUwz99e4LvjD6QrA1sRnbS2Nc0xL
         6GmowWEmEHxr9WebJJ6vVZbcuq4tJRnxl7NVTqAxlsE2EU4JjU9giSjvF+QDFJaW9Lck
         bakbmhXBG8UJsZK/2Xl4/3Rrhx4ELupOSokpbSQhfo5mKUU3Y+dAVh2tboycrT3XYRM3
         3KL3M4iLm6SpBO9DD4JNuRVawwG9ER2KlODpthWQapMSFPtviQwnsp7gubLM9EQE+Oan
         SNCvNX4sFxLged1jvVt+0898YmX2VR4uv+7xGkavcX2eZkobDocOtMSMn4RWk7H/14lY
         tvIQ==
X-Gm-Message-State: AOJu0YxWi3j9YCjgvAEtU+8EI1+BbC7dVDZqvairhepMVLXkzyNsOFTB
	0kQSQKxZh0gMs6Kae45m//ajL8kCLW2iDQQx/VQrlVL6Fg1U7KX/jY44Bg8PQ1s=
X-Gm-Gg: ASbGncsyLnHjkp/VAZvlHg2u7n0cfuCuGg4yi/+Gjg8x5CbD4JK/j44Ane90p6Dz0XC
	0iI0hn/9zPLB25GkfX6TRttQPghP4qSYqqs1AApTWipGzbRXBU4iStiYm/ME7/qXv+er78OP9Ur
	IJclWWOtqJjtt0SUYj6O05Hb0amYf1A17FM4h4yDDBOjMQikQAZf6cyBaHt5/czYH5E20Q28Ijd
	hloWmrRJOxx4WeReFIOROJGhirLMW/xioexUyIOwbyJBGhpz2HzhAGZQ1KSSnEUaA==
X-Google-Smtp-Source: AGHT+IGGyNLNR1RClM55xrjfdfWVD2LgIWLTKhIXrbKkA3UKKSknIdcAM6iFD4rA8RiO5kZp/JvnfQ==
X-Received: by 2002:a05:6402:5206:b0:5d0:b61a:89c9 with SMTP id 4fb4d7f45d1cf-5d63579198fmr631834a12.5.1734016014800;
        Thu, 12 Dec 2024 07:06:54 -0800 (PST)
Date: Thu, 12 Dec 2024 16:06:53 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 29/35] x86/hvm: add HVM-specific Kconfig
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-29-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-29-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:41:59PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Add separate menu for configuring HVM build-time settings.
> That will help organizing HVM-specific options under a separate menu.

Instead of being a separate menu, which feels a bit odd under default
settings because there's just an "HVM support" option inside, could
you make it look like the PV support menu, that indents PV specific
options:

[*] PV support
[ ]   Support for 32bit PV guests
[*]   Support for PV linear pagetables

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 15:07:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 15:07:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856138.1268861 (Exim 4.92)
	(envelope-from )
	id 1tLkn0-0000sH-HA; Thu, 12 Dec 2024 15:07:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856138.1268861; Thu, 12 Dec 2024 15:07: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 1tLkn0-0000sA-Ec; Thu, 12 Dec 2024 15:07:42 +0000
Received: by outflank-mailman (input) for mailman id 856138;
 Thu, 12 Dec 2024 15:07: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 1tLkmz-0000rw-9X
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 15:07:41 +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 d46e0c81-b89a-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 16:07:40 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-436281c8a38so2386435e9.3
 for ; Thu, 12 Dec 2024 07:07:40 -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-4362559ef5bsm19028805e9.24.2024.12.12.07.07.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 07:07: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: d46e0c81-b89a-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734016060; x=1734620860; 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=ym8/EVixyFMihplOZa+TuRa9VkEPjJ16liKFp/tRpDo=;
        b=BD7d5O7dcRkRg77FYab30TsKSjtDRszJZ8xOLGShKN2O5c2YZ2NEq0Erk4aXvRqwal
         z5Zs0JzxKWmLGK91AOuWUsCbHQkNiICeyHRZo35JBU2B23m1VC/ElnnX6PMWeCuNWYTr
         MP39dj+LFE0cyrXq05D66nHZW/NrxrE93AxarEcHlBgANU3q7chuUYEv0b9lWzpEjFAK
         ES0H+A+wcmA0QYC+St1Z0f7sEP6m+78VErnniatOtiaBLHCW3+RoKFRg80JWNn0VKu2D
         A1eQO8BaSgyv9+eeHARYmH3GBBPiE7YjwGeWvQuK9IIyNRODlha/Z72UhAuff0VN+Hu0
         9bOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734016060; x=1734620860;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ym8/EVixyFMihplOZa+TuRa9VkEPjJ16liKFp/tRpDo=;
        b=UVtAOqLUeiwhenglujqi0mOMBUWT+RLlN1gzYGK9Lsb6HHSuaJKHCkwSUHlLlJztkU
         xaIgqhhwrO+YM/yAWdDdkgU9+uDEj3Qv1zpD1SDs8D3sELhOibDYN/RJ5eiMOxYzxLq4
         lEdNJv778VbbnJWxnU3yY8gHMItmUHc4L7affGkiXtokEtL04MCCVdmafBlIrxuZTXdP
         AcZ+N3kOwxawvUM+NPKHAkRI4gEJt1NTl/d1Ruyh58FBM5ly1NIrlf2CSU1MaGRGkRIx
         BAjST3xf2Y2Um7kFPefgAqWi0B94m/S5oDUaebY0N0evbSTPfMOAeoqzRh4yLdq/xkEw
         fqCg==
X-Forwarded-Encrypted: i=1; AJvYcCVOp8OTip+SPnH0oTNTHXQnEDYmv8kUE49p7BM5N5OnBYRX+GUFviy6CvAncBSmOrxWDFBk/2ItQ3I=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx9ju8aL+/douhbtpjBmZA6rckhy2uhHQALO3cueik5EACKsvHx
	8V7cM5z3nqCrTg7/Y47gJHz84AYwXXUosfWxq8Yb49SdHjsXHpuapkEizA7azVGZwIy3E3zDpy4
	=
X-Gm-Gg: ASbGncv3Yj5DiToMb6j50LbXMu+ICme3LAbAi7PnLCwz9IzZY9CDVHh6e2Kw/kO/EzB
	iavf5HzcxqtbbTrOFtt9SHbM5i6RV9oSVZhyWcXTQoSCFJcL825g5KIFmhN/VWYKqzylBnRJIQm
	CT7f5qWpwGZaAupaef82fq89ExrLKqVqTQDLkIWVmfColTAzpvI2ErKmEtD+3z3scXtaMVdEtAw
	4EZ2/8qgd//TI9hHJuQ9ZT4zKoNGHizFu20ls6/Ed7iBVxqLbdN005RF7yKT3n1KnjXsgb3RMkY
	GRY8Mk6e2qtaHcu0LKLMgc5q37TvHMuuecLizP0ZnQ==
X-Google-Smtp-Source: AGHT+IEvrLNnvMAGkxcEuXSO77UYxwNXfTUXhG84+AXug8LYRee3sinsr7vZ2FQwTZVC+r+3CP9y0g==
X-Received: by 2002:a05:600c:1c10:b0:434:a91e:c709 with SMTP id 5b1f17b1804b1-43622864830mr26897575e9.28.1734016058070;
        Thu, 12 Dec 2024 07:07:38 -0800 (PST)
Message-ID: 
Date: Thu, 12 Dec 2024 16:07:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 28/35] xen/8250-uart: add missing definitions
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-28-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-28-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:41, Denis Mukhin via B4 Relay wrote:
> --- a/xen/include/xen/8250-uart.h
> +++ b/xen/include/xen/8250-uart.h
> @@ -32,16 +32,22 @@
>  #define UART_MCR          0x04    /* Modem control        */
>  #define UART_LSR          0x05    /* line status          */
>  #define UART_MSR          0x06    /* Modem status         */
> +#define UART_SCR          0x07    /* Scratch pad          */
>  #define UART_USR          0x1f    /* Status register (DW) */
>  #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=1) */
>  #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=1) */
>  #define UART_XR_EFR       0x09    /* Enhanced function register (Exar) */
>  
> +/* ns8250 emulator: range of emulated registers [0..UART_MAX-1] */
> +#define UART_MAX          (UART_SCR + 1)

There are two issues here: "max" means "highest within range", yet
you define it as "first invalid", i.e. something we'd normally call
"_NR" or "_NUM". And then, as the comment says, this is a limit the
emulation is going to expose, not something generally applicable to
UARTs of this kind. Hence the UART_ prefix alone isn't quite correct
either.

> @@ -51,12 +57,21 @@
>  #define UART_IIR_THR      0x02    /*  - tx reg. empty     */
>  #define UART_IIR_MSI      0x00    /*  - MODEM status      */
>  #define UART_IIR_BSY      0x07    /*  - busy detect (DW) */
> +#define UART_IIR_FE0      BIT(6, U) /* FIFO enable #0 */
> +#define UART_IIR_FE1      BIT(7, U) /* FIFO enable #1 */
> +#define UART_IIR_FE_MASK  (UART_IIR_FE0 | UART_IIR_FE1)

Much like BSY is a 3-bit field, aiui this is a 2-bit one.

>  /* FIFO Control Register */
> -#define UART_FCR_ENABLE   0x01    /* enable FIFO          */
> -#define UART_FCR_CLRX     0x02    /* clear Rx FIFO        */
> -#define UART_FCR_CLTX     0x04    /* clear Tx FIFO        */
> -#define UART_FCR_DMA      0x10    /* enter DMA mode       */
> +#define UART_FCR_ENABLE     BIT(0, U)   /* enable FIFO          */
> +#define UART_FCR_CLRX       BIT(1, U)   /* clear Rx FIFO        */
> +#define UART_FCR_CLTX       BIT(2, U)   /* clear Tx FIFO        */
> +#define UART_FCR_DMA        BIT(3, U)   /* enter DMA mode       */
> +#define UART_FCR_RESERVED0  BIT(4, U)   /* reserved; always 0   */
> +#define UART_FCR_RESERVED1  BIT(5, U)   /* reserved; always 0   */
> +#define UART_FCR_RTB0       BIT(6, U)   /* receiver trigger bit #0 */
> +#define UART_FCR_RTB1       BIT(7, U)   /* receiver trigger bit #1 */
> +#define UART_FCR_TRG_MASK   (UART_FCR_RTB0 | UART_FCR_RTB1)

Much like the top two bits here are, and - as Roger has said - the
reserved bits probably also should be.

> @@ -64,17 +79,17 @@
>  
>  /*
>   * Note: The FIFO trigger levels are chip specific:
> - *	RX:76 = 00  01  10  11	TX:54 = 00  01  10  11
> - * PC16550D:	 1   4   8  14		xx  xx  xx  xx
> - * TI16C550A:	 1   4   8  14          xx  xx  xx  xx
> - * TI16C550C:	 1   4   8  14          xx  xx  xx  xx
> - * ST16C550:	 1   4   8  14		xx  xx  xx  xx
> - * ST16C650:	 8  16  24  28		16   8  24  30	PORT_16650V2
> - * NS16C552:	 1   4   8  14		xx  xx  xx  xx
> - * ST16C654:	 8  16  56  60		 8  16  32  56	PORT_16654
> - * TI16C750:	 1  16  32  56		xx  xx  xx  xx	PORT_16750
> - * TI16C752:	 8  16  56  60		 8  16  32  56
> - * Tegra:	 1   4   8  14		16   8   4   1	PORT_TEGRA
> + *  RX:76 = 00  01  10  11  TX:54 = 00  01  10  11
> + * PC16550D:     1   4   8  14      xx  xx  xx  xx
> + * TI16C550A:    1   4   8  14      xx  xx  xx  xx
> + * TI16C550C:    1   4   8  14      xx  xx  xx  xx
> + * ST16C550:     1   4   8  14      xx  xx  xx  xx
> + * ST16C650:     8  16  24  28      16   8  24  30  PORT_16650V2
> + * NS16C552:     1   4   8  14      xx  xx  xx  xx
> + * ST16C654:     8  16  56  60       8  16  32  56  PORT_16654
> + * TI16C750:     1  16  32  56      xx  xx  xx  xx  PORT_16750
> + * TI16C752:     8  16  56  60       8  16  32  56
> + * Tegra:        1   4   8  14      16   8   4   1  PORT_TEGRA
>   */

While perhaps okay, the adjustment of this table still looks unrelated.
It wants at least mentioning in the description, to clarify it's an
intentional change (as opposed to e.g. being an effect of how your
editor is configured).

> @@ -96,11 +111,31 @@
>  #define UART_LCR_CONF_MODE_B	0xBF		/* Configuration mode B */
>  
>  /* Modem Control Register */
> -#define UART_MCR_DTR      0x01    /* Data Terminal Ready  */
> -#define UART_MCR_RTS      0x02    /* Request to Send      */
> -#define UART_MCR_OUT2     0x08    /* OUT2: interrupt mask */
> -#define UART_MCR_LOOP     0x10    /* Enable loopback test mode */
> -#define UART_MCR_TCRTLR   0x40    /* Access TCR/TLR (TI16C752, EFR[4]=1) */
> +#define UART_MCR_DTR            BIT(0, U)   /* Data Terminal Ready  */
> +#define UART_MCR_RTS            BIT(1, U)   /* Request to Send      */
> +#define UART_MCR_OUT1           BIT(2, U)   /* OUT1: interrupt mask */
> +#define UART_MCR_OUT2           BIT(3, U)   /* OUT2: interrupt mask */
> +#define UART_MCR_LOOP           BIT(4, U)   /* Enable loopback test mode */
> +#define UART_MCR_RESERVED0      BIT(5, U)   /* Reserved #0 */
> +#define UART_MCR_RESERVED1      BIT(6, U)   /* Reserved #1 */
> +#define UART_MCR_TCRTLR         BIT(6, U)   /* Access TCR/TLR (TI16C752, EFR[4]=1) */
> +#define UART_MCR_RESERVED2      BIT(7, U)   /* Reserved #2 */
> +#define UART_MCR_MASK \
> +    (UART_MCR_DTR | UART_MCR_RTS | \
> +     UART_MCR_OUT1 | UART_MCR_OUT2 | \
> +     UART_MCR_LOOP)
> +
> +/* Modem Status Register */
> +#define UART_MSR_DCTS           BIT(0, U)   /* Change in CTS */
> +#define UART_MSR_DDSR           BIT(1, U)   /* Change in DSR */
> +#define UART_MSR_TERI           BIT(2, U)   /* Change in RI */
> +#define UART_MSR_DDCD           BIT(3, U)   /* Change in CTS */
> +#define UART_MSR_CTS            BIT(4, U)
> +#define UART_MSR_DSR            BIT(5, U)
> +#define UART_MSR_RI             BIT(6, U)
> +#define UART_MSR_DCD            BIT(7, U)

As you introduce these constants, I think you also want to switch the sole
MSR read we have to actually use them.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 15:25:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 15:25:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856156.1268871 (Exim 4.92)
	(envelope-from )
	id 1tLl3q-0005qV-Tk; Thu, 12 Dec 2024 15:25:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856156.1268871; Thu, 12 Dec 2024 15:25:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLl3q-0005qO-RI; Thu, 12 Dec 2024 15:25:06 +0000
Received: by outflank-mailman (input) for mailman id 856156;
 Thu, 12 Dec 2024 15:25: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 1tLl3p-0005qI-O8
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 15:25:05 +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 413e4baa-b89d-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 16:25:03 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1734017092551658.7603516810639;
 Thu, 12 Dec 2024 07:24: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: 413e4baa-b89d-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1734017095; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=aVtsHmmoEPRBVqafU+X+SyutgeOiZednb86pOZ2qen/R+1G8bsHyl0NAPMq7HgbgA8AJOVvoeRIIG6ivKse0aXsSmcE8BajtmDWMHr2H3uSb19cGf9XnW/VFyGmBUoU8wzb/OJohnfbbER2H/AZhZpt4nq2FJD7dSOqrO3KQ0fU=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1734017095; 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=F1Ma1hJwRLZUMkZ2303OZR8O0S2s2eu3hXgcPBG/cjs=; 
	b=HPma9QzpItga95COO84F5RNI9eLWRF4KPTfqQ3IRxteIuL//z9Ctpw5SvLi0h1wA9csto9MR23Orahvrnppon7dV67I6hGoC5+ObzaKiDBMJwY3iecuGWdvQvUaGzJ/ZtWCEuD1zA/00Q8AXjfdhWTbUvEAxI/0Hu5VSWRtg+ms=
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=1734017095;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=F1Ma1hJwRLZUMkZ2303OZR8O0S2s2eu3hXgcPBG/cjs=;
	b=jT9FWvBHJcgaF4Xhp/MHkDU6c0KhVvGzWitZQAZ2dqoVxt80YavPuENU68Rxlcg/
	stwILGU9nVXBzp8jDetEP6OkzLB2F6fqeFZ362KyJBQHOFDIqj5pvrufdcJpGatOQsY
	gdUwHaiU31WVegeT1l2eJubYjzQB1JrFjdMqvdUg=
Message-ID: <6ea84558-4042-468b-9607-1a2e5a281a89@apertussolutions.com>
Date: Thu, 12 Dec 2024 10:24:49 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 06/15] x86/hyperlaunch: introduce the domain builder
To: Jan Beulich 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-7-dpsmith@apertussolutions.com>
 
 <71d62f74-91d9-498f-80a7-d0dc01fb51da@apertussolutions.com>
 <3b0d3128-2501-4866-a2c5-36a1277956b1@suse.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <3b0d3128-2501-4866-a2c5-36a1277956b1@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 12/12/24 06:06, Jan Beulich wrote:
> On 11.12.2024 13:36, Daniel P. Smith wrote:
>> On 12/2/24 05:10, Jan Beulich wrote:
>>> On 23.11.2024 19:20, Daniel P. Smith wrote:
>>>> Introduce the domain builder which is capable of consuming a device tree as the
>>>> first boot module. If it finds a device tree as the first boot module, it will
>>>> set its type to BOOTMOD_FDT. This change only detects the boot module and
>>>> continues to boot with slight change to the boot convention that the dom0
>>>> kernel is no longer first boot module but is the second.
>>>>
>>>> No functional change intended.
>>>>
>>>> Signed-off-by: Daniel P. Smith 
>>>> ---
>>>>    xen/arch/x86/Makefile                    |  2 +
>>>>    xen/arch/x86/domain_builder/Makefile     |  3 ++
>>>>    xen/arch/x86/domain_builder/core.c       | 55 ++++++++++++++++++++++++
>>>>    xen/arch/x86/domain_builder/fdt.c        | 38 ++++++++++++++++
>>>>    xen/arch/x86/domain_builder/fdt.h        | 21 +++++++++
>>>>    xen/arch/x86/include/asm/bootinfo.h      |  3 ++
>>>>    xen/arch/x86/include/asm/domainbuilder.h |  8 ++++
>>>>    xen/arch/x86/setup.c                     | 18 +++++---
>>>>    8 files changed, 142 insertions(+), 6 deletions(-)
>>>>    create mode 100644 xen/arch/x86/domain_builder/Makefile
>>>>    create mode 100644 xen/arch/x86/domain_builder/core.c
>>>>    create mode 100644 xen/arch/x86/domain_builder/fdt.c
>>>>    create mode 100644 xen/arch/x86/domain_builder/fdt.h
>>>
>>> As I'm sure I indicated before: Dashes instead of underscores please in new
>>> files' names.
>>>
>>>>    create mode 100644 xen/arch/x86/include/asm/domainbuilder.h
>>>
>>> Why is there no separator in this file's name?
>>
>> Name was getting a bit long, but can add separator if desired.
> 
> Well, my desire is for the subdir and the header names to match up.
> Personally I think that neater to achieve when both have a dash in the
> middle.

Sure.

>>>> --- /dev/null
>>>> +++ b/xen/arch/x86/domain_builder/core.c
>>>> @@ -0,0 +1,55 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>>> +/*
>>>> + * Copyright (C) 2024, Apertus Solutions, LLC
>>>> + */
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +
>>>> +#include 
>>>> +
>>>> +#include "fdt.h"
>>>> +
>>>> +void __init builder_init(struct boot_info *bi)
>>>> +{
>>>> +    if ( IS_ENABLED(CONFIG_DOMAIN_BUILDER) )
>>>> +    {
>>>> +        int ret;
>>>> +
>>>> +        switch ( ret = has_hyperlaunch_fdt(bi) )
>>>> +        {
>>>> +        case 0:
>>>> +            printk("Hyperlaunch device tree detected\n");
>>>> +            bi->hyperlaunch_enabled = true;
>>>> +            bi->mods[0].type = BOOTMOD_FDT;
>>>> +            break;
>>>> +        case -EINVAL:
>>>> +            printk("Hyperlaunch device tree was not detected\n");
>>>> +            bi->hyperlaunch_enabled = false;
>>>> +            break;
>>>> +        case -ENOENT:
>>>> +            fallthrough;
>>>
>>> No need for this.
>>
>> I thought MISRA called for explicit fallthrough?
> 
> Only when there are statements between two case labels. Which ...
> 
>>>> +        case -ENODATA:
> 
> ... isn't the case here.

Rgr, have already dropped it.

>>>> @@ -1277,9 +1278,12 @@ void asmlinkage __init noreturn __start_xen(void)
>>>>                   bi->nr_modules);
>>>>        }
>>>>    
>>>> -    /* Dom0 kernel is always first */
>>>> -    bi->mods[0].type = BOOTMOD_KERNEL;
>>>> -    bi->domains[0].kernel = &bi->mods[0];
>>>> +    builder_init(bi);
>>>> +
>>>> +    /* Find first unknown boot module to use as Dom0 kernel */
>>>> +    i = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
>>>> +    bi->mods[i].type = BOOTMOD_KERNEL;
>>>> +    bi->domains[0].kernel = &bi->mods[i];
>>>
>>> Better latch the result here into a separate local variable, for use ...
>>>
>>>> @@ -1466,8 +1470,9 @@ void asmlinkage __init noreturn __start_xen(void)
>>>>            xen->size  = __2M_rwdata_end - _stext;
>>>>        }
>>>>    
>>>> -    bi->mods[0].headroom =
>>>> -        bzimage_headroom(bootstrap_map_bm(&bi->mods[0]), bi->mods[0].size);
>>>> +    i = first_boot_module_index(bi, BOOTMOD_KERNEL);
>>>> +    bi->mods[i].headroom =
>>>> +        bzimage_headroom(bootstrap_map_bm(&bi->mods[i]), bi->mods[i].size);
>>>>        bootstrap_unmap();
>>>>    
>>>>    #ifndef highmem_start
>>>> @@ -1591,7 +1596,8 @@ void asmlinkage __init noreturn __start_xen(void)
>>>>    #endif
>>>>        }
>>>>    
>>>> -    if ( bi->mods[0].headroom && !bi->mods[0].relocated )
>>>> +    i = first_boot_module_index(bi, BOOTMOD_KERNEL);
>>>> +    if ( bi->mods[i].headroom && !bi->mods[0].relocated )
>>>>            panic("Not enough memory to relocate the dom0 kernel image\n");
>>>>        for ( i = 0; i < bi->nr_modules; ++i )
>>>>        {
>>>
>>> ... in these two places?
>>
>> I don't know if a local variable is need. I assume your suggestion is to
>> drop the first_boot_module_index() call,
> 
> The latter two of the three, yes.
> 
>> but thinking about it, not sure
>> why I kept the walk. A direct use of bi->domains[0].kernel could be used
>> without the intermediate variable while removing the call.
> 
> If that's possible, the even better.

Yep, while it did make the lines a little longer, I was able to use the 
boot_domain reference.

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 15:25:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 15:25:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856164.1268882 (Exim 4.92)
	(envelope-from )
	id 1tLl4L-0006JM-A3; Thu, 12 Dec 2024 15:25:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856164.1268882; Thu, 12 Dec 2024 15:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLl4L-0006JF-61; Thu, 12 Dec 2024 15:25:37 +0000
Received: by outflank-mailman (input) for mailman id 856164;
 Thu, 12 Dec 2024 15:25: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 1tLl4K-0005qI-16
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 15:25:36 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 54dab4c8-b89d-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 16:25:34 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-aa6a618981eso113043466b.3
 for ; Thu, 12 Dec 2024 07:25:34 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa6801060e4sm648619266b.158.2024.12.12.07.25.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Dec 2024 07:25: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: 54dab4c8-b89d-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734017134; x=1734621934; 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=yI7P/J1NvDahaqdb81p62ViU/ufpXHsb/RMe1IM+oSw=;
        b=ePO9Kyjv2ayZ2TdVBns75G5JQCqL5Mg2UOaq4gU2TUcpyca8L/wRRJamOyUEmsd6E4
         4MCzOp/ZHwl62lv8hvVQwDCV3OtMvBvE0662BOXDHjEXnhbaqnB4wFuhmU6unbXaHWgF
         EuyQvFmjyr/NVfYKYu8+6rReOoia3Q1xT266A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734017134; x=1734621934;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=yI7P/J1NvDahaqdb81p62ViU/ufpXHsb/RMe1IM+oSw=;
        b=hJCwXgwyOkB4BXowxuONaEvJRAbItSmWWTgZ+D3srLeeiwSmXUYmeG3GRVAHOQAlRo
         VhXlc0LpD2GbOoUw3X/rT5LKNCxop3NGRlVwfnrCWw789Ecjx6A0HWtCIFt7Bc26Cwkv
         fA2AbKNXZr4NsEXLARrH48wp+hQd8sQ877qEmwp9VUUXZBKHCq/na3zOKXHV1arOA105
         lVzE8c3GWkAzNjnvdLvFQNRo9NzUfDEZFJC1ZRJGr7qiWr5KzLwPS6r/SN4J14NSXD5d
         51gt/LCIkLTrDb0/GD5gmll1QuA8YBGPerfKJ8XtRTefZVMHlEVs4WuOSYB6sEbH4pqc
         ganQ==
X-Forwarded-Encrypted: i=1; AJvYcCVrKKESVEioAuWobkbReSmOXSH0rLL9tc4YqWYP2q2mTdSYtTckJl7Wl1hqHgKmU3rz212IuM4lr2I=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyGsxK6250s6M6O4LWfM7B5wQRLS+3+cHwJM9FABQJMQJly4Ufb
	4StsYTg7E+vIihjhQWV0j11k+EanmWJfC9NdwdBhEIMZWDqkeanvNhoy3kvGTrs=
X-Gm-Gg: ASbGncs4/Qf2WkGTaeCaODcxR3S4fLeZrJu8/WrfnkDsKbxaRBEkKiVwzO7h7NnnMNt
	oi8MwA7gjMQCQdrCH8kurMBVkty05LSnj3cuL3fhYPerf5LP9ZBbCpjekrAFVvlIpOYjphqxsfs
	RnpQz89LDfKfBlam6AWYZEzk+PuLmSwnaXrAkeYE2upRahDgglpQa19mVJCMjgxLkyKB9i+Urcf
	TFsMAtKnNdSJ9/SupjDH553msJRo1U2/4niAUeSmhxfW1j9u/upl6qWZIiC/jtbQw==
X-Google-Smtp-Source: AGHT+IEBWaF8RzjhT02eBsfbqPPWHnzrjPfhQ85d+0PxTJga/5CkNMBEf+TCZBdVTS2USMJ3/KYfWg==
X-Received: by 2002:a17:907:7747:b0:aa6:8935:ae71 with SMTP id a640c23a62f3a-aa6b10f5d3amr778536466b.12.1734017133916;
        Thu, 12 Dec 2024 07:25:33 -0800 (PST)
Date: Thu, 12 Dec 2024 16:25:32 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 16/35] xen/console: introduce printk_common()
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-16-e9aa923127eb@ford.com>
 
 <8e5ce2dd-f888-42a3-937f-98ed1269c66c@suse.com>
 
 <9dad24ea-178f-48c8-a93b-5823c44b56ee@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9dad24ea-178f-48c8-a93b-5823c44b56ee@suse.com>

On Thu, Dec 12, 2024 at 01:52:49PM +0100, Jan Beulich wrote:
> On 12.12.2024 13:15, Roger Pau Monné wrote:
> > On Thu, Dec 12, 2024 at 12:57:25PM +0100, Jan Beulich wrote:
> >> On 12.12.2024 10:14, Roger Pau Monné wrote:
> >>> On Thu, Dec 05, 2024 at 08:41:46PM -0800, Denis Mukhin via B4 Relay wrote:
> >>>> From: Denis Mukhin 
> >>>>
> >>>> Introduce new printk() variant for convenient printouts which skip '(XEN)'
> >>>> prefix on xen console. This is needed for the case when physical console is
> >>>> owned by a domain w/ in-hypervisor UART emulation enabled.
> >>>
> >>> IIRC the ns8250 can only send or receive one byte (character) at a
> >>> time, so you should likely put that on the console as soon as it's
> >>> received?
> >>>
> >>> For the hardware domain we explicitly don't buffer writes to the
> >>> console (see guest_console_write() hardware domain special handling).
> >>>
> >>> I wonder however how you deal with domains that don't have the console
> >>> focus (ie: != console_rx), as for those I think you still want to use
> >>> the (d) prefix?
> >>
> >> Imo no matter what domain has the focus, the (d) prefix should
> >> always be logged. Just to avoid possible confusion.
> > 
> > WE don't do that currently for the hardware domain, because we avoid
> > doing any kind of line processing, as characters from the hardware
> > domain are send straight to the console without waiting for the
> > newline terminator (like we do for other domains).
> 
> Right, and that's kind of special, and aiui intentionally so. These are
> the only un-prefixed lines logged.
> 
> > Are you suggesting that in case of the console input being shared
> > between multiple domains they should all be treated as plain domUs and
> > thus lines should be buffered?
> 
> No, I'm actually not suggesting anything here beyond perhaps reducing
> the scope of this series to just what the equivalent of vpl011 would be
> for the 8250 / 16550 case.

Indeed, reducing the scope would make it easier to get the actual
feature reviewed.  There's a huge amount of pre-patching that will
possibly take some time to get agreement on (if suitable).

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 15:38:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 15:38:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856184.1268891 (Exim 4.92)
	(envelope-from )
	id 1tLlGX-0000qU-A9; Thu, 12 Dec 2024 15:38:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856184.1268891; Thu, 12 Dec 2024 15:38: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 1tLlGX-0000qN-7b; Thu, 12 Dec 2024 15:38:13 +0000
Received: by outflank-mailman (input) for mailman id 856184;
 Thu, 12 Dec 2024 15:38:11 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1tLlGV-0000qH-Ns
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 15:38:11 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1tLlGS-00HDGM-0o;
 Thu, 12 Dec 2024 15:38:08 +0000
Received: from lfbn-gre-1-248-145.w90-112.abo.wanadoo.fr ([90.112.205.145]
 helo=l14) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96)
 (envelope-from ) id 1tLlGS-00HDu8-0f;
 Thu, 12 Dec 2024 15:38: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" 
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date;
	bh=d7loXoRdZ1igJ2wSUNEYwLh4PTsFsCd6B3/p+qYULSc=; b=bkByxIa/CoW+nko918KJQjFIPz
	DpLSy+OCroVMzwDEVBu3hhE3XRRmlqksMueSpOAONgq9QCP1dN/R5BayQr7DgqzvTKC83fBkPa1L8
	xkw9e5lqCPwHGPI/tCJ0q/YebUPfnkr/B+wUaal4L2XSq9JM47YCUEbwa4gAuC+m+Ogo=;
Date: Thu, 12 Dec 2024 16:38:05 +0100
From: Anthony PERARD 
To: "Chen, Jiqian" 
Cc: "Hildebrand, Stewart" ,
	Stefano Stabellini ,
	Paul Durrant ,
	"Edgar E . Iglesias" ,
	"Michael S. Tsirkin" ,
	Marcel Apfelbaum ,
	"qemu-devel@nongnu.org" ,
	"xen-devel@lists.xenproject.org" ,
	"Huang, Ray" 
Subject: Re: [QEMU PATCH v10] xen/passthrough: use gsi to map pirq when dom0
 is PVH
Message-ID: 
References: <20241106061418.3655304-1-Jiqian.Chen@amd.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

On Tue, Dec 10, 2024 at 07:17:30AM +0000, Chen, Jiqian wrote:
> On 2024/11/19 00:05, Anthony PERARD wrote:
> > On Wed, Nov 06, 2024 at 02:14:18PM +0800, Jiqian Chen wrote:
> >> In PVH dom0, when passthrough a device to domU, QEMU code
> >> xen_pt_realize->xc_physdev_map_pirq wants to use gsi, but in current codes
> >> the gsi number is got from file /sys/bus/pci/devices//irq, that is
> >> wrong, because irq is not equal with gsi, they are in different spaces, so
> >> pirq mapping fails.
> >>
> >> To solve above problem, use new interface of Xen, xc_pcidev_get_gsi to get
> >> gsi and use xc_physdev_map_pirq_gsi to map pirq when dom0 is PVH.
> >>
> >> Signed-off-by: Jiqian Chen 
> >> Signed-off-by: Huang Rui 
> >> Signed-off-by: Jiqian Chen 
> > 
> > Acked-by: Anthony PERARD 
> > 
> > But, this following change probably needs an ack from PCI maintaners,
> > CCed.
> As PCI maintainers didn't response for weeks,
> can I just move the definition of the macro back to xen_pt.c file ?

No, that's fine. I should be able to send a pull-request with this
change without too much trouble.

Cheers,

> >> diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> >> index eb26cac81098..07805aa8a5f3 100644
> >> --- a/include/hw/pci/pci.h
> >> +++ b/include/hw/pci/pci.h
> >> @@ -23,6 +23,10 @@ extern bool pci_available;
> >>  #define PCI_SLOT_MAX            32
> >>  #define PCI_FUNC_MAX            8
> >>  
> >> +#define PCI_SBDF(seg, bus, dev, func) \
> >> +            ((((uint32_t)(seg)) << 16) | \
> >> +            (PCI_BUILD_BDF(bus, PCI_DEVFN(dev, func))))
> >> +
> >>  /* Class, Vendor and Device IDs from Linux's pci_ids.h */
> >>  #include "hw/pci/pci_ids.h"

-- 
Anthony PERARD


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 16:18:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 16:18:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856203.1268902 (Exim 4.92)
	(envelope-from )
	id 1tLltn-0001ug-98; Thu, 12 Dec 2024 16:18:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856203.1268902; Thu, 12 Dec 2024 16:18: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 1tLltn-0001uZ-6D; Thu, 12 Dec 2024 16:18:47 +0000
Received: by outflank-mailman (input) for mailman id 856203;
 Thu, 12 Dec 2024 16:18: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 1tLltm-0001uT-OK
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 16:18:46 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c249cf22-b8a4-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 17:18:44 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-a9a0ec0a94fso128473966b.1
 for ; Thu, 12 Dec 2024 08:18:44 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa66f671da0sm743250966b.17.2024.12.12.08.18.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Dec 2024 08:18: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: c249cf22-b8a4-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734020324; x=1734625124; 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=EmoOxdJWcpYNHrfRxKU9VYSkBeucXZYJGur1RrRhPZE=;
        b=IpB4ezz55+eFcX/hUEUOZDhhRYGhQbQf4UpgeoUd+AmtS4yhOOYyOq36yK6C4Njdws
         LEdoL5oPyf3T8jGP5m78DawmNkA9rtIe0HImCa8hyQI2aLxl12muJuw8cLb5R3gL0qzH
         i7yYEVYdJsgXs7/TtIl8ldf2NHn4jqafinC7k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734020324; x=1734625124;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=EmoOxdJWcpYNHrfRxKU9VYSkBeucXZYJGur1RrRhPZE=;
        b=KkvCjBS7o4uruPydFkFU2ImlJM2I5nPfa05a60/iMXtZkCwGliLxzJJFsXgrBWKPsx
         qKiQgHk6kUXeEkWx/uhMOLB7mxCEX3dXdWCZDrj6JyCye/dy4N5wRoEtKaCq6LbFMQQO
         dd7koutokdkNYpKgsT2OTpx6jHi09gyRjjo6XXwwDWTTJtblcJrGiyqsLfekTKQN5Taz
         jAIDhULzaw381AcHw3MXGG3sXfKvepirGrrAsqOBaGsoaAjL9MV7KDdYlCeuq3OpENHy
         oz6qLcKnFnZnjyRIJQlxRF2iDufKsuTMe4/t/z+4+3DGjBQK4Ivf9lttLJGK52VqvPFR
         IqsQ==
X-Gm-Message-State: AOJu0YxWhqN1HM+zZ64ihvmtIJOzIQXo+zaFBOsqBP/UWr6f3bIYCiOf
	HOjxlbvOwKL5zMW30PzrmXXi0abe/paXTUqmW+OA48ipyHfO3bM4U5CwAZMfH64=
X-Gm-Gg: ASbGncvZPFoHKgzuSTcsx66ZFAfQvoMOVMUrbvFNzVP3yJw6/WCtalQtJDZ85IAT6JF
	FtnixCtBrz3ti4yCJR1QJKrYkBupR3vQoP5GobstPkES93evwURvhGOiPz94Kj0ChLpbQILGFoW
	8d2BQ88CWULWhvWZ/5UxST3+Ak3FuOziQgbafDyfciCvlzKsEXAEunYMr1kxlweH4rJYdQfBUVz
	kbteheg9DqHG/oWhHuaXd/03mzMZslIBrCc2LeTI6wH9nKVyIwkvzWji2/KQpUMSQ==
X-Google-Smtp-Source: AGHT+IGvX6XpphB37MBimPyiDifCJfoY2C6CAZ7Cs4ZYmw9ziTWSspRMbPobCVjjaNpC0LbqbxjoLw==
X-Received: by 2002:a17:907:7717:b0:aa6:7cae:db98 with SMTP id a640c23a62f3a-aa6c1ab6285mr465110066b.10.1734020324054;
        Thu, 12 Dec 2024 08:18:44 -0800 (PST)
Date: Thu, 12 Dec 2024 17:18:42 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 30/35] x86/hvm: add helpers for raising guest IRQs
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-30-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-30-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:42:00PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Added convenience wrappers for asserting/de-asserting interrupts in the
> hardware emulation code.
> 
> That will be used for PCI-based NS8250 emulator.

Strictly speaking the ns8250 uart should only generate ISA interrupts
as I understand it, as it only uses IRQs 3 and 4?  IOW from that code
you should only need to use hvm_isa_irq_assert().

> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/arch/x86/hvm/irq.c             | 24 ++++++++++++++++++++++++
>  xen/arch/x86/include/asm/hvm/irq.h |  3 +++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
> index 1eab44defca4c82ec35769617c66c380cc07d1b6..9e3a50d21dcf281c1015116094e47795c51ed5d0 100644
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -242,6 +242,30 @@ void hvm_isa_irq_deassert(
>      spin_unlock(&d->arch.hvm.irq_lock);
>  }
>  
> +void hvm_irq_raise(struct domain *d, unsigned int irq)
> +{
> +    if ( irq < NR_ISAIRQS )
> +    {
> +        hvm_isa_irq_assert(d, irq, NULL);
> +    }
> +    else
> +    {
> +        hvm_gsi_assert(d, irq);
> +    }
> +}
> +
> +void hvm_irq_lower(struct domain *d, unsigned int irq)

It would be better to use the assert/deassert nomenclature, like it's
used for the functions that are called.

> +{
> +    if ( irq < NR_ISAIRQS )
> +    {
> +        hvm_isa_irq_deassert(d, irq);
> +    }
> +    else
> +    {
> +        hvm_gsi_deassert(d, irq);
> +    }
> +}

The parameter to thins function is kind of fuzzy, as I understand it,
if the parameter is < NR_ISAIRQS it's an ISA IRQ, while if it's >=
NR_ISAIRQS it's a GSI?

It would also be helpul to mention that hvm_isa_irq_deassert() will
already do the ISA IRQ -> GSI conversion in case there are any source
overrides.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 16:52:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 16:52:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856220.1268911 (Exim 4.92)
	(envelope-from )
	id 1tLmQV-0001VY-Ph; Thu, 12 Dec 2024 16:52:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856220.1268911; Thu, 12 Dec 2024 16: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 1tLmQV-0001VR-ND; Thu, 12 Dec 2024 16:52:35 +0000
Received: by outflank-mailman (input) for mailman id 856220;
 Thu, 12 Dec 2024 16: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 1tLmQU-0001VL-Tb
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 16:52:34 +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 7ae6fcd4-b8a9-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 17:52:32 +0100 (CET)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-385e2880606so848988f8f.3
 for ; Thu, 12 Dec 2024 08:52: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-38782521dfesm4390674f8f.107.2024.12.12.08.52.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 08:52: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: 7ae6fcd4-b8a9-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734022352; x=1734627152; 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=ABRjboFcPXzmp8ZEB8fDUTBnLeQ+jIzjHW5crLMy4/Q=;
        b=Qf0c53rO33Ku5XEdUcnE4ZmEqJoyeNHDMYrEIELhZa6MmN9/syWC+MDqKGkGSvW8MB
         gA75qv5lZXUu+avWnrv6+herVuOaKO8mGJsXhycbdyZQfjwDDTkLufJQRS/5kSMebBTw
         KXiTEDxL+BI932ywcMnClNWpxJIts9GvP2+yqlQE51+hZuvbqUazK7OjgfwbTuzacXPc
         dAcFIjQPt6qU0Xb42vnq7AtuH0BW3XnYNQ/KfTmKXiaeCgh0VzGnd4XoNyAzuN6JGt6p
         Gg8ODnEPli5FCWO/uCuvD5s/AdefxnXnHeLlxmfa0bE7mDZcu1JqousQ6J/tbHMSw/AF
         vLcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734022352; x=1734627152;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=ABRjboFcPXzmp8ZEB8fDUTBnLeQ+jIzjHW5crLMy4/Q=;
        b=ezlhJwSJnGWHPDu0MCtABupvgf53qOgDzo1wIlREumLKFv6SRIpSTNsHH7v1Tab7aU
         lEupCU6hw+VSs3Mg3GkM9dCyMft/XJEGoyzAq3/dfmWzBfEeXFxeKL4zwlk6bxZT0AsM
         7L3yNPxEXIqaLgqqYl5DTl9EjBD84YeX4UR0iFF2k7geVZbcLR9B7Tiq6d3JSbNS9m7t
         hPZSpLQpa+kzuPjfEKKzuNjwCPlvwKOkuWF1xU70rtYd9LwdeEMut2Wr1i9lONHP4lrV
         cECURTdVDZxIHz/EY6AYqJxZNVqVUNkVAUlqAWt7w6FtADZC8ydPLVnml9H8Xc9Ko5C/
         EYyQ==
X-Forwarded-Encrypted: i=1; AJvYcCVxkyg/zMBZyXfIAlr1fQ/F1MHi5B9ySggnfMS0pP8ySJcqqit33kuUuDNfjQNibYaA1qcu21aqw0c=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy4PD5buIAPo8u2fMphpbTAaOT39EgEkYPIoc2TEPT/w1AkfwJA
	+AneU6PLQGCdYk2IAWK1AeNfDMniuGAdEUW38qUsZHfCjkx2IdI/tmWG2TQnbw==
X-Gm-Gg: ASbGncuoL7yMxk7DkxnIQQSLYd5dhtioIppYFkcOeo/bmq7Dd+TkVPQyY2xlUNLm0oJ
	RDhse7bePY6+3zax0jYUOzeXmGsMLW2+MlFKwtsoJPNGKtDu/AUs8MVZw/Vf0thoEg8HFxZIvab
	QG9ivbx5Uvoda2+25oa5dAAAhd7MsqBkhWs0d+HQrQ1f2VWBrw6yokLtRpHgIS/6txJbyl51ulw
	btcGEnwMDBWG0ZpnQ3V7jN9xeh0MMQutkZpXwP1t8w4Pnz2Kibl/abVNrkoc7KFerECycq0uI+t
	laEIYfhCe0oLuya0K6x825Qu9qRMRZQU26ynxsx9UQ==
X-Google-Smtp-Source: AGHT+IE8tZAZf6JMun47dVUijQMchEn0AO/AC7YNyhCuCMOFMzbNmogvF5FY0knQFnWEvgM82/tiDw==
X-Received: by 2002:a5d:6da6:0:b0:386:33e3:853c with SMTP id ffacd0b85a97d-3864ce8645amr6765397f8f.12.1734022351880;
        Thu, 12 Dec 2024 08:52:31 -0800 (PST)
Message-ID: <7aea0e1d-f60c-4e82-8b63-c4e18cbcce85@suse.com>
Date: Thu, 12 Dec 2024 17:52:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/3] Add stack protector
From: Jan Beulich 
To: Andrew Cooper 
Cc: Julien Grall , Stefano Stabellini
 , Anthony PERARD ,
 Samuel Thibault ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Bertrand Marquis ,
 Michal Orzel ,
 "xen-devel@lists.xenproject.org" ,
 Volodymyr Babchuk 
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
  <87pllx3gib.fsf@epam.com>
 
 <9056a92d-8e91-4f2d-a8f3-5cde378f6c6f@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: <9056a92d-8e91-4f2d-a8f3-5cde378f6c6f@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12.12.2024 15:30, Jan Beulich wrote:
> On 12.12.2024 02:17, Andrew Cooper wrote:
>> (With the knowledge that this is a disputed Kconfig pattern, and will
>> need rebasing), the way I want this to work is simply:
>>
>> diff --git a/xen/Makefile b/xen/Makefile
>> index 0de0101fd0bf..5d0a88fb3c3f 100644
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -434,6 +434,9 @@ endif
>>  
>>  ifeq ($(CONFIG_STACK_PROTECTOR),y)
>>  CFLAGS += -fstack-protector
>> +ifeq ($(CONFIG_X86),y)
>> +CFLAGS += -mstack-protector-guard=global
>> +endif
>>  else
>>  CFLAGS += -fno-stack-protector
>>  endif
>> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
>> index 9cdd04721afa..7951ca908b36 100644
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -28,6 +28,7 @@ config X86
>>         select HAS_PCI_MSI
>>         select HAS_PIRQ
>>         select HAS_SCHED_GRANULARITY
>> +       select HAS_STACK_PROTECTOR if
>> $(cc-option,-mstack-protector-guard=global)
>>         select HAS_UBSAN
>>         select HAS_VMAP
>>         select HAS_VPCI if HVM
>>
>>
>>
>> Sadly, it doesn't build.  I get a handful of:
>>
>> prelink.o: in function `cmdline_parse':
>> /home/andrew/xen.git/xen/common/kernel.c:216:(.init.text+0x20f2): failed
>> to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
>> --no-relax
>> /home/andrew/xen.git/xen/common/kernel.c:230:(.init.text+0x246f): failed
>> to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
>> --no-relax
>>
>> which is more toolchain-whispering than I feel like doing tonight.
> 
> Imo the root of the problem is that the compiler doesn't itself mark
> __stack_chk_guard hidden (it does so for __stack_chk_fail, albeit only for
> 32-bit code), and hence finds it necessary to use @gotpcrel to access the
> variable. Even if the linker managed to relax all of these, it would then
> still be less efficient compared to direct RIP-relative accesses.
> 
> I also can't see how we might be able to override the compiler's internal
> declaration to mark it hidden (the same appears to be true for other items
> the declares internally, like the retpoline thunks or even strcmp() et al).
> Passing -fvisibility=hidden doesn't make a difference (just as another
> data point).
> 
> Playing with -fstack-protector* flavors, I observe:
> - -fstack-protector causing several failures, like you observed, oddly
>   enough exclusively from __init functions,
> - -fstack-protector-all and -fstack-protector-strong each causing a single
>   (but respectively different) failure, for apparently random non-__init
>   functions.
> Taking this together it very much smells like a linker issue. I'll see
> about checking there further.

The oddity with how many diags show up is down to internals of the linker.
It processes a single input section in full (continuing over this specific
type of error), but will stop processing afterwards if any such error was
encountered.

The issue itself is a wrong assumption in the linker: It believes that it
would only ever build small-model code when encountering this kind of
relocation, and when not linking a shared library or PIE. With this
assumption it converts the relocation resulting from @gotpcrel to
R_X86_64_32S (converting the MOV from GOT to MOV $imm), which of course
overflows when later trying to actually resolve it. What I'm yet to
understand is why it doesn't use R_X86_64_PC32 (also) in such a situation
(it does e.g. when building a shared library).

While so far I didn't try it, using --no-relax is presumably not an option,
as I expect that it'll leave us with a non-empty .got. Plus I didn't even
start looking into how the xen.efi linking would deal with the ELF-specific
gotpcrel relocs; the concept of GOT doesn't exist in PE/COFF, after all.

While the linker certainly wants fixing, I continue to think that getting
the compiler side right would yield the better overall result.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 17:48:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 17:48:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856240.1268922 (Exim 4.92)
	(envelope-from )
	id 1tLnIU-0003G5-Si; Thu, 12 Dec 2024 17:48:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856240.1268922; Thu, 12 Dec 2024 17:48: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 1tLnIU-0003Fy-PP; Thu, 12 Dec 2024 17:48:22 +0000
Received: by outflank-mailman (input) for mailman id 856240;
 Thu, 12 Dec 2024 17:48: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 1tLnIT-0003Fs-8s
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 17:48:21 +0000
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com
 [2607:f8b0:4864:20::d2f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4527a4ca-b8b1-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 18:48:19 +0100 (CET)
Received: by mail-io1-xd2f.google.com with SMTP id
 ca18e2360f4ac-844ce213af6so27319739f.1
 for ; Thu, 12 Dec 2024 09:48:18 -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: 4527a4ca-b8b1-11ef-a0d5-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734025697; x=1734630497; 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=lJmOoCTfegMJa1Yr0/R8zMtSjGdO8E/PmSuCtIKtiKM=;
        b=l7Y1tjCduv8gTsuZvWKwzFqJM7du5ivCqlrZTf0aNtoIynTGcZ0WFPtlbYinZmSRAk
         bPLifCXI+M8lfnbSF8/43mprV9hk8Y/mXvmWQB+44j9+1+JXGTR02beP/0qI15GwrN3p
         IjZ3dYmjdeTwAqb78cIAiw/6h0FsbAA1AvW0KZ8wXayaLpgYiBi6K+pHjGC/zgNRzu2g
         ITW2SkpcxadaempSsQJCpFD+lrXr7RF5seqK5oxO7DCsq3Y2ao1lL3K49fYC+7ygcTnB
         89jM54xG3AsmzFfPvsrRIrPpB2CmQh793PUbpQmwQm3K4QnOM1QOvBmI+8lN8/tw9Sdk
         FEgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734025697; x=1734630497;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=lJmOoCTfegMJa1Yr0/R8zMtSjGdO8E/PmSuCtIKtiKM=;
        b=d7vJXGl917Mukh3BUDvly9U2Hu1BcTVOZUODTgFDhuNoryk/jZUQHCCRFOaGdqe8ld
         n+4L/l1fmdHq4m4mY9kdeiYWQx2S2Ohwk+6PnnyW3+Oka4e8avdw7YHRdihhL3QmeISB
         Hwg8TytD03XRjZbzC+7m0HmUVB2oRPEY0VrdODBb6wRdtNQ6ReWrqty+RcTt+MDPZJOk
         CeJJmyCj05zKSYK53JcRqzeV8FIXnGh/6f7SmyCpoNao7BizIDuo8+BVvb8YbQMUKPGV
         qihUfrommYtLu0jl5GZvvX912JjGItJE6ikpY6/Tqx4MR54K2ibS8sxQtjNKlFpuOUPl
         ykUQ==
X-Forwarded-Encrypted: i=1; AJvYcCV3vATy2QXbUwAhERO3jAXxX5ycn+HdGCcI807wpulB+ocrHqIOObL/UiaLmT7Dm6mI9q3C1pCQ+Lc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YycZuph0fZfxb8uX3i0pdhSy+LuWighYzT0gwwnz6F67djgzpJM
	CaiPX8mdP6SMy/TuFmeavm6SUKLgXjwhhaIH72V7YxU+6G4MXuEdB/jnsFPcfyLSwV56M3LTUbS
	R2ZN3/Mr8Mds7kMAL8s9JJZ0Y6myIaDtsOMp45Q==
X-Gm-Gg: ASbGncuDsa/MPAnsuRoWs2Rn4Apa78oe/4w3JXulymXJ6HkIirRwu9+jVC/3uYnviAt
	sVotEzdkZehYxFDWR4gkzgWfEkLLaD4noT2UFo8w=
X-Google-Smtp-Source: AGHT+IGhRw4OjLOc+qBlOfuTB11qT8uwOJMXjtWxCy6RHajtcNdB/SHDcFD+aBS5toPWNZjWhJxOSlTw2djqsmla7rU=
X-Received: by 2002:a92:ca49:0:b0:3a7:e539:c272 with SMTP id
 e9e14a558f8ab-3ae5934c765mr14068265ab.23.1734025697419; Thu, 12 Dec 2024
 09:48:17 -0800 (PST)
MIME-Version: 1.0
References: <20241202165921.249585-1-carlo.nonato@minervasys.tech>
 <20241202165921.249585-4-carlo.nonato@minervasys.tech> 
 <7ecc99c5-0cb5-4351-bede-cb03c9a4ac7e@xen.org> <293004fa-c87e-4a45-aa4c-b02456aaecea@amd.com>
 <0bacfdb6-d4ad-4dea-85d4-2851873dca4e@xen.org>
In-Reply-To: <0bacfdb6-d4ad-4dea-85d4-2851873dca4e@xen.org>
From: Carlo Nonato 
Date: Thu, 12 Dec 2024 18:48:06 +0100
Message-ID: 
Subject: Re: [PATCH v11 03/12] xen/arm: permit non direct-mapped Dom0 construction
To: Julien Grall 
Cc: Michal Orzel , xen-devel@lists.xenproject.org, 
	andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, 
	Stefano Stabellini , Bertrand Marquis , 
	Volodymyr Babchuk 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Dec 9, 2024 at 8:17=E2=80=AFPM Julien Grall  wrote:
>
> Hi Michal,
>
> On 07/12/2024 15:04, Michal Orzel wrote:
> >
> >
> > On 06/12/2024 19:37, Julien Grall wrote:
> >>
> >>
> >> Hi,
> >>
> >> Sorry for the late answer.
> >>
> >> On 05/12/2024 09:40, Michal Orzel wrote:
> >>>
> >>>
> >>> On 02/12/2024 17:59, Carlo Nonato wrote:
> >>>>
> >>>>
> >>>> Cache coloring requires Dom0 not to be direct-mapped because of its =
non
> >>>> contiguous mapping nature, so allocate_memory() is needed in this ca=
se.
> >>>> 8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a separate=
 module")
> >>>> moved allocate_memory() in dom0less_build.c. In order to use it
> >>>> in Dom0 construction bring it back to domain_build.c and declare it =
in
> >>>> domain_build.h.
> >>>>
> >>>> Take the opportunity to adapt the implementation of allocate_memory(=
) so
> >>>> that it uses the host layout when called on the hwdom, via
> >>>> find_unallocated_memory().
> >>>>
> >>>> Signed-off-by: Carlo Nonato 
> >>>> ---
> >>>> v11:
> >>>> - GUEST_RAM_BANKS instead of hardcoding the number of banks in alloc=
ate_memory()
> >>>> - hwdom_ext_regions -> hwdom_free_mem in allocate_memory()
> >>>> - added a comment in allocate_memory() when skipping small banks
> >>>> v10:
> >>>> - fixed a compilation bug that happened when dom0less support was di=
sabled
> >>>> v9:
> >>>> - no changes
> >>>> v8:
> >>>> - patch adapted to new changes to allocate_memory()
> >>>> v7:
> >>>> - allocate_memory() now uses the host layout when called on the hwdo=
m
> >>>> v6:
> >>>> - new patch
> >>>> ---
> >>>>    xen/arch/arm/dom0less-build.c           | 44 -----------
> >>>>    xen/arch/arm/domain_build.c             | 97 ++++++++++++++++++++=
++++-
> >>>>    xen/arch/arm/include/asm/domain_build.h |  1 +
> >>>>    3 files changed, 94 insertions(+), 48 deletions(-)
> >>>>
> >>>> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-b=
uild.c
> >>>> index d93a85434e..67b1503647 100644
> >>>> --- a/xen/arch/arm/dom0less-build.c
> >>>> +++ b/xen/arch/arm/dom0less-build.c
> >>>> @@ -49,50 +49,6 @@ bool __init is_dom0less_mode(void)
> >>>>        return ( !dom0found && domUfound );
> >>>>    }
> >>>>
> >>>> -static void __init allocate_memory(struct domain *d, struct kernel_=
info *kinfo)
> >>>> -{
> >>>> -    struct membanks *mem =3D kernel_info_get_mem(kinfo);
> >>>> -    unsigned int i;
> >>>> -    paddr_t bank_size;
> >>>> -
> >>>> -    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd=
:\n",
> >>>> -           /* Don't want format this as PRIpaddr (16 digit hex) */
> >>>> -           (unsigned long)(kinfo->unassigned_mem >> 20), d);
> >>>> -
> >>>> -    mem->nr_banks =3D 0;
> >>>> -    bank_size =3D MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem);
> >>>> -    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM0_BASE)=
,
> >>>> -                               bank_size) )
> >>>> -        goto fail;
> >>>> -
> >>>> -    bank_size =3D MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem);
> >>>> -    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM1_BASE)=
,
> >>>> -                               bank_size) )
> >>>> -        goto fail;
> >>>> -
> >>>> -    if ( kinfo->unassigned_mem )
> >>>> -        goto fail;
> >>>> -
> >>>> -    for( i =3D 0; i < mem->nr_banks; i++ )
> >>>> -    {
> >>>> -        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" =
(%ldMB)\n",
> >>>> -               d,
> >>>> -               i,
> >>>> -               mem->bank[i].start,
> >>>> -               mem->bank[i].start + mem->bank[i].size,
> >>>> -               /* Don't want format this as PRIpaddr (16 digit hex)=
 */
> >>>> -               (unsigned long)(mem->bank[i].size >> 20));
> >>>> -    }
> >>>> -
> >>>> -    return;
> >>>> -
> >>>> -fail:
> >>>> -    panic("Failed to allocate requested domain memory."
> >>>> -          /* Don't want format this as PRIpaddr (16 digit hex) */
> >>>> -          " %ldKB unallocated. Fix the VMs configurations.\n",
> >>>> -          (unsigned long)kinfo->unassigned_mem >> 10);
> >>>> -}
> >>>> -
> >>>>    #ifdef CONFIG_VGICV2
> >>>>    static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
> >>>>    {
> >>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build=
.c
> >>>> index 2c30792de8..2b8cba9b2f 100644
> >>>> --- a/xen/arch/arm/domain_build.c
> >>>> +++ b/xen/arch/arm/domain_build.c
> >>>> @@ -416,7 +416,6 @@ static void __init allocate_memory_11(struct dom=
ain *d,
> >>>>        }
> >>>>    }
> >>>>
> >>>> -#ifdef CONFIG_DOM0LESS_BOOT
> >>>>    bool __init allocate_domheap_memory(struct domain *d, paddr_t tot=
_size,
> >>>>                                        alloc_domheap_mem_cb cb, void=
 *extra)
> >>>>    {
> >>>> @@ -508,7 +507,6 @@ bool __init allocate_bank_memory(struct kernel_i=
nfo *kinfo, gfn_t sgfn,
> >>>>
> >>>>        return true;
> >>>>    }
> >>>> -#endif
> >>>>
> >>>>    /*
> >>>>     * When PCI passthrough is available we want to keep the
> >>>> @@ -1003,6 +1001,94 @@ out:
> >>>>        return res;
> >>>>    }
> >>>>
> >>>> +void __init allocate_memory(struct domain *d, struct kernel_info *k=
info)
> >>>> +{
> >>>> +    struct membanks *mem =3D kernel_info_get_mem(kinfo);
> >>>> +    unsigned int i, nr_banks =3D GUEST_RAM_BANKS;
> >>>> +    paddr_t bank_start, bank_size;
> >>> Limit the scope
> >>>
> >>>> +    struct membanks *hwdom_free_mem =3D NULL;
> >>>> +    const uint64_t bankbase[] =3D GUEST_RAM_BANK_BASES;
> >>>> +    const uint64_t banksize[] =3D GUEST_RAM_BANK_SIZES;
> >>> Limit the scope
> >>>
> >>>> +
> >>>> +    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd=
:\n",
> >>>> +           /* Don't want format this as PRIpaddr (16 digit hex) */
> >>>> +           (unsigned long)(kinfo->unassigned_mem >> 20), d);
> >>>> +
> >>>> +    mem->nr_banks =3D 0;
> >>>> +    /*
> >>>> +     * Use host memory layout for hwdom. Only case for this is when=
 LLC coloring
> >>>> +     * is enabled.
> >>>> +     */
> >>>> +    if ( is_hardware_domain(d) )
> >>>> +    {
> >>>> +        ASSERT(llc_coloring_enabled);
> >>> This patch does not build because of declaration not being visible. Y=
ou must include .
> >>
> >> Piggying back on this comment. AFAICT, the code below would work also =
in
> >> the non cache coloring case. So what's the assert is for?
> >>
> >>>
> >>>> +
> >>>> +        hwdom_free_mem =3D xzalloc_flex_struct(struct membanks, ban=
k,
> >>>> +                                             NR_MEM_BANKS);
> >>>> +        if ( !hwdom_free_mem )
> >>>> +            goto fail;
> >>>> +
> >>>> +        hwdom_free_mem->max_banks =3D NR_MEM_BANKS;
> >>>> +
> >>>> +        if ( find_unallocated_memory(kinfo, hwdom_free_mem) )
> >>> My remarks for the use of find_unallocated_memory() 1:1 have not been=
 addressed. You did not even
> >>> change the comments inside the function. The problem is that the func=
tion is specifically designed
> >>> for finding extended regions and assumes being called at certain poin=
t i.e. dom0 RAM allocated, gnttab
> >>> region allocated, etc.
> >>
> >> So I agree that the function should be updated if we plan to use it fo=
r
> >> other purpose.
> >>
> >> My opinion is that we should attempt to make the function generic so
> >> that in your
> >>> case you can choose which regions to exclude, define even your own fu=
nction to grab free regions (at the moment
> >>> add_ext_regions grabs banks >=3D 64M but you still discards banks >=
=3D 128M, so it's a bit wasteful.
> >>>
> >>> My very short attempt to make the function as generic as possible in =
the first iteration:
> >>> https://paste.debian.net/1338334/
> >>
> >> This looks better, but I wonder why we need still need to exclude the
> >> static regions? Wouldn't it be sufficient to exclude just reserved reg=
ions?
> > Static shared memory banks are not part of reserved memory (i.e. bootin=
fo.reserved_mem) if that's what you're asking.
> > They are stored in bootinfo.shmem, hence we need to take them into acco=
unt when searching for unused address space.
>
> Oh I missed the fact you now pass "mem_banks" as a parameter. I thought
> they would still get excluded for cache coloring case.
>
> >
> > If you and Carlo are ok with my proposed solution for making the functi=
on generic, I can send a patch as a prerequisite
> > patch for Carlo series.
>
> I am fine with the approach.
>
> Cheers,
>
> --
> Julien Grall
>

> @@ -2152,7 +2238,10 @@ static int __init construct_dom0(struct domain *d)
>      /* type must be set before allocate_memory */
>      d->arch.type =3D kinfo.type;
>  #endif
> -    allocate_memory_11(d, &kinfo);
> +    if ( is_domain_direct_mapped(d) )
> +        allocate_memory_11(d, &kinfo);
> +    else
> +        allocate_memory(d, &kinfo);
>      find_gnttab_region(d, &kinfo);

Since find_gnttab_region() is called after allocate_memory(), kinfo->gnttab=
_*
fields aren't initialized and the call to find_unallocated_memory() with
gnttab as the region to exclude, fails ending in a crash since memory for
dom0 can't be allocated.

Can the solution be to call find_gnttab_region() before the above if?
Or should I just call it before allocate_memory() in one case, but still af=
ter
allocate_memory_11() in the other?

Thanks.


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 18:23:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 18:23:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856260.1268932 (Exim 4.92)
	(envelope-from )
	id 1tLnqN-00037K-IL; Thu, 12 Dec 2024 18:23:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856260.1268932; Thu, 12 Dec 2024 18:23: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 1tLnqN-00037D-F6; Thu, 12 Dec 2024 18:23:23 +0000
Received: by outflank-mailman (input) for mailman id 856260;
 Thu, 12 Dec 2024 18:23: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 1tLnqL-000377-D0
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 18:23:21 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 29600a5c-b8b6-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 19:23:19 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-aa66ead88b3so168153766b.0
 for ; Thu, 12 Dec 2024 10:23:19 -0800 (PST)
Received: from ?IPV6:2001:4ca0:0:f293:dc1b:7733:c3ba:a819?
 ([2001:4ca0:0:f293:dc1b:7733:c3ba:a819])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa68f70cc47sm571518866b.123.2024.12.12.10.23.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 12 Dec 2024 10:23:18 -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: 29600a5c-b8b6-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734027798; x=1734632598; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=4XUi4a7hE2rmXI8Ng6fxTd+T/FbjYkCmbPSpum5eWW4=;
        b=pMv9lrhHMTC9EkWuzh2Gwe3DywnZ/nrH79/i+A4JMjMqnJZZH9aRzcZLGQfMbHiMrv
         +N+cmcqEEyjN1bwBHx8R5HYxVD+1xVAIffYACzUIenSmOJrZJA9hcVxRnpjEWbqK1CPb
         LbFnFsWLPGzM+oAxQlTKQXR6kLCZv+Mhmvke9fLWyk+hsVG4Nxv9WrkHsm0PcI0y74cM
         Rh35qsw1a3T/Xw5v0yWwGLuyWhJpejGj4zfmKzoOgkGU0C6O2KT782CuK/bujBcIZ7Ly
         IfJpWukrp2MgWXpkCvulI7SPDzOp6MIrE7VM/Jg3fl6axNZCsiMUTXMct0k7vw5Gs2bh
         pJSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734027798; x=1734632598;
        h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc
         :to:content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=4XUi4a7hE2rmXI8Ng6fxTd+T/FbjYkCmbPSpum5eWW4=;
        b=HVw8G9smUll8R7qCd4pV+LHvJaQpi30/EkjFTm8DUW/yXTUCEdf346tCYAafHrvFvn
         n1ds1fB1z6/S5JKQd8ftsno/jmRKg0lf6D9Afb1lH+kmrH8G/gvFUme1XSxkZKeyBbM1
         V9eUhLncPQblbW7Rb7jyWKu9MA7WL5zv/gseiZicKy9zSNQdqGEvtFPE3Acdg2BI5HbT
         LkqRoSXJzjwJjZq5mB5yRyVc+AnxxqU4yt/KR3caIXhAeBYDBMErzBdVhl7VT5sHhS/J
         CvaGueWVgnrCB9rBP/EJnEmDR4OChs/ejXlX6HL4xyVyp3CUKGpDAlA4zf+CmJMF+QFy
         AKsA==
X-Forwarded-Encrypted: i=1; AJvYcCWrtzxtkoe9qvmhfWlWeVB7LMa5hyZsMfpoW7DlPkMRgKiYSVJ31EyBunFW8wQRHhGLV/XLaFgJ3q0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzoUf+cw35+3nXMGzbHs/lodyC0Z+tIHzRDtjKYKbD1DV3mvrO3
	7Uq1jXIhIu6NVEoIXwbsN1WVoDkcmG85KhP7vlf1cRsr8uTyHzNUYWxDlNtq36I=
X-Gm-Gg: ASbGncspj/eHLK8XjGG5Yr7/VBavVbhRVe+92EHOEyA9D/o8l8UFdQ8LCmRAMP5/Mvh
	4EZmPXahAbnm2j/KPgh4VcelUiKIv9Hizw+VNsEFx+/Jre6n/OCDrkau2YRNjeADIftubKINJuH
	da6zO+t3MjiS48TmV0UgX0m2pYeWFG79ZSE5fz1qrFQ+hfSAaNuOenHds2TTWZWhZd7H3wioU9/
	lWv8nXg40GliK9P6iQ7y0t43hOdqB0F7sOaBrElrgcWIXH/jtEHzWfRUF0HqXA1v1xDXVXqO6Zk
	D5LVCa91QuNQY2lU9wtVAOtN2KL1lKnMwWJPbw==
X-Google-Smtp-Source: AGHT+IHnvxfPvEAhz++HPBKL7nc9OF5D2iH8j6tW64b2Tsi49u5SaB8EgOWUVsOG/LOJrJJ/B8pjew==
X-Received: by 2002:a17:906:314e:b0:aa6:b5d8:d5c4 with SMTP id a640c23a62f3a-aa6b5d8d617mr807141066b.17.1734027798457;
        Thu, 12 Dec 2024 10:23:18 -0800 (PST)
Message-ID: 
Date: Thu, 12 Dec 2024 19:22:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v11 03/12] xen/arm: permit non direct-mapped Dom0
 construction
Content-Language: en-US
To: Carlo Nonato , Julien Grall 
Cc: Michal Orzel , xen-devel@lists.xenproject.org,
 marco.solieri@minervasys.tech, Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20241202165921.249585-1-carlo.nonato@minervasys.tech>
 <20241202165921.249585-4-carlo.nonato@minervasys.tech>
 
 <7ecc99c5-0cb5-4351-bede-cb03c9a4ac7e@xen.org>
 <293004fa-c87e-4a45-aa4c-b02456aaecea@amd.com>
 <0bacfdb6-d4ad-4dea-85d4-2851873dca4e@xen.org>
 
From: Andrea Bastoni 
Autocrypt: addr=andrea.bastoni@minervasys.tech; keydata=
 xsFNBF5Nh4sBEAC7UM3QJtjrFO3pjcMCCh04JFyCCDzLFMIqMTB1UWCLamZ9dUwIau7ScgWv
 49aqbM++edVvEBmG8JHDC83DFWymvFVXBgqgcR7tHHBbg33XJKFMHvuW/kFm/67XPTFcec4L
 JsH5MWms9TLJbgCnaWQQMH3kztTRQaf5QcULIoHnTySKlt3WzzzHosaMO+/GNYX7vzfc4ypJ
 mD5SQWYDhfRefASkyxdrN6/QkPwS2vGTyVK58o2U9I27KPYvs+77JrjrNBfpnebapaYVA55C
 7BvTnno5Kr6QHwA6LcnIZqefz7KxQ1n+1C5QQbmhi9S68aloGCeUo9R06UMJG79TXC2Mc68t
 AtSCN/HpgcvN1CSL45f/4WCDPG572ebo5M6MPcTb4ptV1SC/i+4U/3cG0LNSUap+sGRCf0Iy
 C5xy0KOtgoq8jesdleSy8j/3DNIMGekSYbQYMO39DfZds2XFh9lVDjG7tQcChwW+lQDPo113
 ENBRftDyqJthrvmJXGyrOmn0su56qh2Zqvi5pSHWsH88vAZUJsOU+9lpohmcb3o/cQ18UXNK
 H/9wjo2zKHFdSylQFERHIzj6WlBp01wkTcCqtUGpxsjJHmVSyakWs3TrGXooKR9SPMxqVrD/
 oCCEo9IUD9jd+TxLsp/4TzUp4ScTO/43uPgdkMekU5mRs6B6WwARAQABzS9BbmRyZWEgQmFz
 dG9uaSA8YW5kcmVhLmJhc3RvbmlAbWluZXJ2YXN5cy50ZWNoPsLBlAQTAQgAPgIbAwULCQgH
 AgYVCgkICwIEFgIDAQIeAQIXgBYhBImpnm1L3x9XIoXhD3VSShFTR9xSBQJitcUIBQkKC9f2
 AAoJEHVSShFTR9xSmSoP/0W/VboJmWmLh89eIl1QRoiL1nGcti1fTN835Q2TPiSdg+nFVqy1
 8oLrJaHNe5THVaSr4S2du56SASYSG6f+Y5aiQccbalUJIV7KwXr741kovTnUPUKjPoi61Bx4
 DUzis0Xo0NmMnz7M1YudbQZmjoakE/wZJRB+b79+kJwrfZFcNg4DSuSvNOUeI17uapLKRQ1a
 ukuRgXwUpMOudKngJ8HB+16aHIQX+yfpcsanNr1nGwHSLhEPEM20DVzKiCp2cKjv9Y7zZ+6y
 akbJHdbRuJliyZmXaSVO8sQ1tO/W6Y/4zAjejw2c1qDKISeIlGi+o6UEVYZlKCThzrV9vYok
 AcJF4DlYcAuBMVYCTomovXb/9/Y48pRGlfDGrmnt+FvGVA0jYrG02oufItY2JAGzFcX1KMTG
 AGf1S7pOj3AvBTGJjW8d8+sXuedH51HNixJtMnzcmi+qJfPJujBW3BEZ1p0ZoDyTH/WCZF+7
 B5lFvTi0DRKY6AI0TSzBdjtaOMt64fn6KXtLtaTZKDKkFUBwAShJyYcWQSp/7EO+ZJW7dWIw
 1vM5AcnugonJby+q+JGgBVC2rjscu5Okl3lnviF9WLAzmRH/pDkAa3jifiUm8eS+dP+4cN6g
 WXL9vTF6FtFyI8sgzRlY/IX8mao5bV/P1HCwNvkBhO8C3XMaul4FwQsjzsFNBF5Nh4sBEADN
 J99l+vOp8LB8jDjWOhINlpgp+EcrmWOuler5QnoJUywc2zkLelQIwVGP2lFliMdLHM6DbMEX
 ySIzHbhw7oPRP0QRPK/6I4bXYkSQCrLyqYd0CYSbkar8YV6Xa6nGxRmP1bBv1lPFHN66D0yE
 /z1ScGMXyX+ZOIvH0ekIkqFvi7Ec/7a/ntfU43o2t05dmbnEKoECZgeS8SraojfKnQRpz7+P
 N0q45O5fMETZpIiQh1/mB12HOcklDNELcKohqVfevbknJw04Yjbcv79aGpBRqoVWWBS4TxcD
 CRPQZ+H0tMUVEL/MqO7tNLA1VuGpOccyFtZnC/+J/twa7iKpPIxS9Ec/LDYTddebWH+8gOmr
 /PkBerBXghlZpxmQUlJeQ8kyecOOc4C7ec3aUGj+x28j0+zlXFLUbjiKIEM5VowIMgDDRwA/
 MDr9IJhFzHaY2VCfBnX8sgJSn62IxqREq4X3KkR/Jtxt+HYXQYLl0yva2MBplkRcwQO799o6
 woAMW0uyct4+BUcKo1sBFP2x2n4NFiPEjeoH3y9baruD9iiMQsmbJ3IKqtT13crCa+bcY3ZS
 Oz+CymgzNdH+RabJMC3mGfKIhUQGwEHz+wyMnv16nqO49bmoCk3q5Oneo4I3XwI3QbIJr0rd
 QkX6oh6R0taC3naal1ZYGxs0vZK567bT5wARAQABwsF2BBgBCAAgFiEEiamebUvfH1ciheEP
 dVJKEVNH3FIFAl5Nh4sCGwwACgkQdVJKEVNH3FLafxAAl7pW0v6Jju19I6wtB+XNzzi5Wota
 3AyWzCxO/hUHNGRV/ZufhMkNFCMNzAxbdmO56eCk9ZYf/JMLu8H1GwhV1NgQ7HL4FNXXxLZ0
 ixZDik86iiSjVLtEjLuwkS4Fj9wjqevycL/t16kJduFNyxT0/XiB5UPh5NClOMonHSC+V2If
 Kf6l2Ic34CrA3ovkfVvBXJTzia0VgyQCikeazgPRELH8bq2WTBWfjR3/l86Y0twiYyXqBNQ8
 Q2Z83mu+yt38gTanz4YuDYz7YFjvL6IU2MZ5+ByothK6Cfx4W595q81dsGcJOlcd6j3QE+ps
 b3SHuToWZCHZRHyKrgGDqCL5RbsK3wXgDmc48SfN+5TxenT8A1lkoOHFcQ0SV8xleiwURXHc
 Ao+SzyDcTfltBNjzQmntQjAfq1Lq5Ux9nfpPMgnVHu5ANWeLtwLJyh+4aPVE5hGjeCa+Ab5U
 MyocCYdTuAmDHB9RQdf9c+qlVYuZCg7yYlWsvId5DGZnab2MzvExayaFCJVEoCccpfrqFFiF
 kJ19BogE4A6VTU0ShoHYJhLg7PuEZS1oWzULZnM8sNNI72MecvfZn5Oi0ZEJhFh+HETlJnIT
 7gh7CGFBxPacT8vHxmeMPod7qrvYgKW+QKhU+tAI8gkI6hHXLBg/dxn7wAwTjlX1bo+jRJyp
 Id5SuAU=
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12/12/2024 18:48, Carlo Nonato wrote:
> Hi,
> 
> On Mon, Dec 9, 2024 at 8:17 PM Julien Grall  wrote:
>>
>> Hi Michal,
>>
>> On 07/12/2024 15:04, Michal Orzel wrote:
>>>
>>>
>>> On 06/12/2024 19:37, Julien Grall wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> Sorry for the late answer.
>>>>
>>>> On 05/12/2024 09:40, Michal Orzel wrote:
>>>>>
>>>>>
>>>>> On 02/12/2024 17:59, Carlo Nonato wrote:
>>>>>>
>>>>>>
>>>>>> Cache coloring requires Dom0 not to be direct-mapped because of its non
>>>>>> contiguous mapping nature, so allocate_memory() is needed in this case.
>>>>>> 8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a separate module")
>>>>>> moved allocate_memory() in dom0less_build.c. In order to use it
>>>>>> in Dom0 construction bring it back to domain_build.c and declare it in
>>>>>> domain_build.h.
>>>>>>
>>>>>> Take the opportunity to adapt the implementation of allocate_memory() so
>>>>>> that it uses the host layout when called on the hwdom, via
>>>>>> find_unallocated_memory().
>>>>>>
>>>>>> Signed-off-by: Carlo Nonato 
>>>>>> ---
>>>>>> v11:
>>>>>> - GUEST_RAM_BANKS instead of hardcoding the number of banks in allocate_memory()
>>>>>> - hwdom_ext_regions -> hwdom_free_mem in allocate_memory()
>>>>>> - added a comment in allocate_memory() when skipping small banks
>>>>>> v10:
>>>>>> - fixed a compilation bug that happened when dom0less support was disabled
>>>>>> v9:
>>>>>> - no changes
>>>>>> v8:
>>>>>> - patch adapted to new changes to allocate_memory()
>>>>>> v7:
>>>>>> - allocate_memory() now uses the host layout when called on the hwdom
>>>>>> v6:
>>>>>> - new patch
>>>>>> ---
>>>>>>    xen/arch/arm/dom0less-build.c           | 44 -----------
>>>>>>    xen/arch/arm/domain_build.c             | 97 ++++++++++++++++++++++++-
>>>>>>    xen/arch/arm/include/asm/domain_build.h |  1 +
>>>>>>    3 files changed, 94 insertions(+), 48 deletions(-)
>>>>>>
>>>>>> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
>>>>>> index d93a85434e..67b1503647 100644
>>>>>> --- a/xen/arch/arm/dom0less-build.c
>>>>>> +++ b/xen/arch/arm/dom0less-build.c
>>>>>> @@ -49,50 +49,6 @@ bool __init is_dom0less_mode(void)
>>>>>>        return ( !dom0found && domUfound );
>>>>>>    }
>>>>>>
>>>>>> -static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
>>>>>> -{
>>>>>> -    struct membanks *mem = kernel_info_get_mem(kinfo);
>>>>>> -    unsigned int i;
>>>>>> -    paddr_t bank_size;
>>>>>> -
>>>>>> -    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
>>>>>> -           /* Don't want format this as PRIpaddr (16 digit hex) */
>>>>>> -           (unsigned long)(kinfo->unassigned_mem >> 20), d);
>>>>>> -
>>>>>> -    mem->nr_banks = 0;
>>>>>> -    bank_size = MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem);
>>>>>> -    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM0_BASE),
>>>>>> -                               bank_size) )
>>>>>> -        goto fail;
>>>>>> -
>>>>>> -    bank_size = MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem);
>>>>>> -    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM1_BASE),
>>>>>> -                               bank_size) )
>>>>>> -        goto fail;
>>>>>> -
>>>>>> -    if ( kinfo->unassigned_mem )
>>>>>> -        goto fail;
>>>>>> -
>>>>>> -    for( i = 0; i < mem->nr_banks; i++ )
>>>>>> -    {
>>>>>> -        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
>>>>>> -               d,
>>>>>> -               i,
>>>>>> -               mem->bank[i].start,
>>>>>> -               mem->bank[i].start + mem->bank[i].size,
>>>>>> -               /* Don't want format this as PRIpaddr (16 digit hex) */
>>>>>> -               (unsigned long)(mem->bank[i].size >> 20));
>>>>>> -    }
>>>>>> -
>>>>>> -    return;
>>>>>> -
>>>>>> -fail:
>>>>>> -    panic("Failed to allocate requested domain memory."
>>>>>> -          /* Don't want format this as PRIpaddr (16 digit hex) */
>>>>>> -          " %ldKB unallocated. Fix the VMs configurations.\n",
>>>>>> -          (unsigned long)kinfo->unassigned_mem >> 10);
>>>>>> -}
>>>>>> -
>>>>>>    #ifdef CONFIG_VGICV2
>>>>>>    static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
>>>>>>    {
>>>>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>>>>> index 2c30792de8..2b8cba9b2f 100644
>>>>>> --- a/xen/arch/arm/domain_build.c
>>>>>> +++ b/xen/arch/arm/domain_build.c
>>>>>> @@ -416,7 +416,6 @@ static void __init allocate_memory_11(struct domain *d,
>>>>>>        }
>>>>>>    }
>>>>>>
>>>>>> -#ifdef CONFIG_DOM0LESS_BOOT
>>>>>>    bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size,
>>>>>>                                        alloc_domheap_mem_cb cb, void *extra)
>>>>>>    {
>>>>>> @@ -508,7 +507,6 @@ bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
>>>>>>
>>>>>>        return true;
>>>>>>    }
>>>>>> -#endif
>>>>>>
>>>>>>    /*
>>>>>>     * When PCI passthrough is available we want to keep the
>>>>>> @@ -1003,6 +1001,94 @@ out:
>>>>>>        return res;
>>>>>>    }
>>>>>>
>>>>>> +void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
>>>>>> +{
>>>>>> +    struct membanks *mem = kernel_info_get_mem(kinfo);
>>>>>> +    unsigned int i, nr_banks = GUEST_RAM_BANKS;
>>>>>> +    paddr_t bank_start, bank_size;
>>>>> Limit the scope
>>>>>
>>>>>> +    struct membanks *hwdom_free_mem = NULL;
>>>>>> +    const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
>>>>>> +    const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
>>>>> Limit the scope
>>>>>
>>>>>> +
>>>>>> +    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
>>>>>> +           /* Don't want format this as PRIpaddr (16 digit hex) */
>>>>>> +           (unsigned long)(kinfo->unassigned_mem >> 20), d);
>>>>>> +
>>>>>> +    mem->nr_banks = 0;
>>>>>> +    /*
>>>>>> +     * Use host memory layout for hwdom. Only case for this is when LLC coloring
>>>>>> +     * is enabled.
>>>>>> +     */
>>>>>> +    if ( is_hardware_domain(d) )
>>>>>> +    {
>>>>>> +        ASSERT(llc_coloring_enabled);
>>>>> This patch does not build because of declaration not being visible. You must include .
>>>>
>>>> Piggying back on this comment. AFAICT, the code below would work also in
>>>> the non cache coloring case. So what's the assert is for?
>>>>
>>>>>
>>>>>> +
>>>>>> +        hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank,
>>>>>> +                                             NR_MEM_BANKS);
>>>>>> +        if ( !hwdom_free_mem )
>>>>>> +            goto fail;
>>>>>> +
>>>>>> +        hwdom_free_mem->max_banks = NR_MEM_BANKS;
>>>>>> +
>>>>>> +        if ( find_unallocated_memory(kinfo, hwdom_free_mem) )
>>>>> My remarks for the use of find_unallocated_memory() 1:1 have not been addressed. You did not even
>>>>> change the comments inside the function. The problem is that the function is specifically designed
>>>>> for finding extended regions and assumes being called at certain point i.e. dom0 RAM allocated, gnttab
>>>>> region allocated, etc.
>>>>
>>>> So I agree that the function should be updated if we plan to use it for
>>>> other purpose.
>>>>
>>>> My opinion is that we should attempt to make the function generic so
>>>> that in your
>>>>> case you can choose which regions to exclude, define even your own function to grab free regions (at the moment
>>>>> add_ext_regions grabs banks >= 64M but you still discards banks >= 128M, so it's a bit wasteful.
>>>>>
>>>>> My very short attempt to make the function as generic as possible in the first iteration:
>>>>> https://paste.debian.net/1338334/
>>>>
>>>> This looks better, but I wonder why we need still need to exclude the
>>>> static regions? Wouldn't it be sufficient to exclude just reserved regions?
>>> Static shared memory banks are not part of reserved memory (i.e. bootinfo.reserved_mem) if that's what you're asking.
>>> They are stored in bootinfo.shmem, hence we need to take them into account when searching for unused address space.
>>
>> Oh I missed the fact you now pass "mem_banks" as a parameter. I thought
>> they would still get excluded for cache coloring case.
>>
>>>
>>> If you and Carlo are ok with my proposed solution for making the function generic, I can send a patch as a prerequisite
>>> patch for Carlo series.
>>
>> I am fine with the approach.
>>
>> Cheers,
>>
>> --
>> Julien Grall
>>
> 
>> @@ -2152,7 +2238,10 @@ static int __init construct_dom0(struct domain *d)
>>      /* type must be set before allocate_memory */
>>      d->arch.type = kinfo.type;
>>  #endif
>> -    allocate_memory_11(d, &kinfo);
>> +    if ( is_domain_direct_mapped(d) )
>> +        allocate_memory_11(d, &kinfo);
>> +    else
>> +        allocate_memory(d, &kinfo);
>>      find_gnttab_region(d, &kinfo);
> 
> Since find_gnttab_region() is called after allocate_memory(), kinfo->gnttab_*
> fields aren't initialized and the call to find_unallocated_memory() with
> gnttab as the region to exclude, fails ending in a crash since memory for
> dom0 can't be allocated.
> 
> Can the solution be to call find_gnttab_region() before the above if?

The function is called find, but currently it only initializes kinfo->gnttab_start
and kinfo->gnttab_size and we tested that moving it before allocate_memory* doesn't
cause fallouts.

If moving before allocate_memory*, would it be better to rename it e.g., init_gnttab_region()?

Thanks,
Andrea

> Or should I just call it before allocate_memory() in one case, but still after
> allocate_memory_11() in the other?
> 
> Thanks.



From xen-devel-bounces@lists.xenproject.org Thu Dec 12 19:03:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 19:03:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856272.1268941 (Exim 4.92)
	(envelope-from )
	id 1tLoTQ-0002pA-GK; Thu, 12 Dec 2024 19:03:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856272.1268941; Thu, 12 Dec 2024 19:03: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 1tLoTQ-0002p3-DI; Thu, 12 Dec 2024 19:03:44 +0000
Received: by outflank-mailman (input) for mailman id 856272;
 Thu, 12 Dec 2024 19:03: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 1tLoTP-0002ox-Hr
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 19:03:43 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20622.outbound.protection.outlook.com
 [2a01:111:f403:2415::622])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cc7359ee-b8bb-11ef-a0d5-8be0dac302b0;
 Thu, 12 Dec 2024 20:03:41 +0100 (CET)
Received: from CH0PR13CA0034.namprd13.prod.outlook.com (2603:10b6:610:b2::9)
 by PH8PR12MB7136.namprd12.prod.outlook.com (2603:10b6:510:22b::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.15; Thu, 12 Dec
 2024 19:03:33 +0000
Received: from DS3PEPF000099DE.namprd04.prod.outlook.com
 (2603:10b6:610:b2:cafe::fc) by CH0PR13CA0034.outlook.office365.com
 (2603:10b6:610:b2::9) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.16 via Frontend Transport; Thu,
 12 Dec 2024 19:03:30 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 DS3PEPF000099DE.mail.protection.outlook.com (10.167.17.200) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Thu, 12 Dec 2024 19:03:29 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 12 Dec
 2024 13:03:29 -0600
Received: from xcbayankuma40.xilinx.com (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via
 Frontend Transport; Thu, 12 Dec 2024 13:03:28 -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: cc7359ee-b8bb-11ef-a0d5-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ooa2XCg1/xu+r0tTHWN3IIkdLlfQW634HnWby1ZThshoaHNdqD0x8qY5zkjfrKh2LP2MQq77um0GqZCAli8aT9Ja1L6FBpU5A5hYZFnuPB/0i3Uy4tc4SDBkIvXOiZH/M8PsGMhg+JfP0aD8zQ1m+Mc2GSJDhBLWGLtdry6VCFc9NNvUpJOvNCn+Rh8/aTlNS+gNlQ4x+1LoB7wEJ5Zi+5m8xGJ1qjKxAJxOBCw/LpffsPPE3IJ1j2FyFLBVliD+vxWYtlz6oFTfhPE0E83H3EcHuihXOqhH3ZICaimKPMRttjvkn2xrN34cN5eY1elv2/MI5DcwTHY7c5bC+Bv2BA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hE5i8yz04k/YaqHxjYahPmbZibPdXdt4siNvS6ou3qM=;
 b=wSGkHLKd4RENTJzfKKAieC4BCtVMvFwJtRqGwzFTCfqLFXRcp5taFAUk0IFe6msuYUsGrP53/WPkTErQOQxDUotvEwxxKKGQyiDWh9Q4tqJ7OxZTVhYoZDA+2Kaw6QBlSkDkdWk/QTTaD/mnnsKUYjeTAUj6S395grwmcMgNXnA2i0d6KmMuEMnQ/M/t5XfKJycXnZrTqrf5ngWiLaIOlXeAxIfJdh6HkH5tA4pGsizlCuZJ7ZrnftM5+1tHk5tPZrlbpJuwONxhqkR6QHvkT+J4qGjkVnllpi2/dpuwtwYn1Wz/nOYEJDxNwdmRvN5QL9Z13/0n9IN66Op09QEttw==
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=hE5i8yz04k/YaqHxjYahPmbZibPdXdt4siNvS6ou3qM=;
 b=OCf0NjLnSiS8xI+6q/zC+y7YNKCDhyEYSffMNdLkWn59qA4bkAj1/Tw3Iuk/Kh2mxWjDRh8Wnz8vxJZiqIvgp/oJ+MBwi0gGpx0d/firJkB3aoI4IzRVtwOI8H6rOww5TOoFxfGavqfcwrl15ur8/dBb+h0AJcTMutGLOmgxHa4=
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=SATLEXMB03.amd.com; pr=C
From: Ayan Kumar Halder 
To: 
CC: Michal Orzel , Stefano Stabellini
	, Bertrand Marquis , "Ayan
 Kumar Halder" , Artem Mygaiev
	
Subject: [PATCH v2] docs: fusa: Add dom0less domain configuration requirements
Date: Thu, 12 Dec 2024 19:03:25 +0000
Message-ID: <20241212190325.2130129-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
Received-SPF: None (SATLEXMB03.amd.com: ayan.kumar.halder@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS3PEPF000099DE:EE_|PH8PR12MB7136:EE_
X-MS-Office365-Filtering-Correlation-Id: 9bd9b888-7cb7-417f-81b7-08dd1adfaa7d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?sftnQDGku6FnWNN+8hfY75AZ0FEyWJ7iqzsbGs64FIOWfs5rMonLSvRR/gl5?=
 =?us-ascii?Q?Wac2spSqIbz+De2lQv+FrPyurGrH+BURErCRWQyEOTF9Jxu2fQEhl8bWi0qE?=
 =?us-ascii?Q?RvUEYQLudcTXMyT+WUnsOJ6eGKjFDUFDdKxtxVNrV0HOaLRdXAjkA1kiFCZX?=
 =?us-ascii?Q?BrCvhpfaFicc3J6UbJC3yGVY7B/01cEtDSIlRXpKBesxLOzu5B2ZihXOpU7f?=
 =?us-ascii?Q?WHrbk5sci93Ce6Uikz2kTSHdLyaG/hncJjiGveAZeRFe+3fKUdWIISwSSD8F?=
 =?us-ascii?Q?hkPwt1TNbJredmJgbvAJIm6n7nUwFbErk8SiCfRzLpNQI76vNisYBUZqVa7q?=
 =?us-ascii?Q?2WV0tab281Y+ygbhQCU82JRjPuVovsVBvTj4zOF2VYRqpec6jqGyX78dhRm9?=
 =?us-ascii?Q?Hdgp4jCrvAMe742u2puXLZsCZrHr8Eq361W6b0UrgaC9bSN1tKmIf1tAt9xx?=
 =?us-ascii?Q?c/T7xBXPN1CFDO7Q1Bpu3nxlkHQQ5BLFxYD1PUwyplTDRGkib6THprUik2fA?=
 =?us-ascii?Q?QmyczFSSYzSieMb24eYKrolveL8RyL3At1BDd5wq4vi+xcsNh+qubzcS4Sts?=
 =?us-ascii?Q?s1f2Yl8uc4J29k+QPozjOWpe6bnjffSi1XOzcf+Zu84PEWjhF/se1GuuFMpj?=
 =?us-ascii?Q?gMTxWXLS317l0rOCMOIvs6/MxKdLEtqYMfYpmj3su1iNXIYhGXSbrF6hH25b?=
 =?us-ascii?Q?gNpeBDAoKe9UNkfoU4JrSU36VT1wdVTgCW1UfFRnBBX2GGGCPmDq4K6wl/Bb?=
 =?us-ascii?Q?C6H8xSBWXChYpErLZR7FgmrWLwcOtfy2+/uE3ExIrhJ80gBSCBOaCRk5mGSL?=
 =?us-ascii?Q?yaz1JMb40X5AoTHuFXnYmXUr0eik76HuXptO+q+RiJa3cVSjiHC3/QPQSctN?=
 =?us-ascii?Q?oa1vJo6ge75W3RNKKYIe03GWhtPseS2Tn29LsuiTJiw/6ulfSCgFkuC+WBSt?=
 =?us-ascii?Q?cqPtTWZNWTfNJtR/OfIt/xHQyLl/es21bQYmRwmXfE2699pfR/STxI/g3l7+?=
 =?us-ascii?Q?t0PgFi3SifZv0dG3Jmkvz2zDwsVlI0mRO1zVQg7VPNMcvtlrCRESoY1y8sFl?=
 =?us-ascii?Q?g2y1vYCTQWGIwtzwN/+qqzrdQpxc72ZxMJKcWJS/wcvCUw8pNAR8zB3ZLy2U?=
 =?us-ascii?Q?Ut4/PuEX7AboQsQXYHGKk0H+Z8blqyMzfCAfcPSVmait5IxE7HykDR3T6XjM?=
 =?us-ascii?Q?9lmLU1iO8czgL1u+Pdj/lh1HbgA7shzjxC/MvKHeA8lHp+qEIl2amB6jzkuR?=
 =?us-ascii?Q?qpCGuD9XNQ71hvcb792SRzBIf+scSCx805KbpZ46gLqgunmPSZauu3ydfe4+?=
 =?us-ascii?Q?k01m1ZVTB5QPc5kjIHBH3X88634RkzcKBErAaOexVoPYcbRdDt3UK79pQ7Ek?=
 =?us-ascii?Q?QpN4E3SdtybQ2hpSkuGDhETa4S2NR067YPPQqHuxLfG8X1xXRw=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Dec 2024 19:03:29.5922
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9bd9b888-7cb7-417f-81b7-08dd1adfaa7d
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS3PEPF000099DE.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7136

From: Michal Orzel 

Add requirements for dom0less domain creation.

Signed-off-by: Michal Orzel 
Signed-off-by: Ayan Kumar Halder 
---
Changes from v1 :-

1. As the dom0less domain creation requirements specifies the dt properties
for creating domains, it has been moved to product requirements. Product
requirements define the interface Xen exposes to other domains.

2. For the requirements which introduces new terms (like grant table, etc), I
have provided the definition as part of the comments.

3. Introduced new market requirements to specify that Xen can assign iomem and
irqs to domains.

4. The design requirements will be added later.

 docs/fusa/reqs/market-reqs/reqs.rst        |  16 ++
 docs/fusa/reqs/product-reqs/arm64/reqs.rst | 306 +++++++++++++++++++++
 2 files changed, 322 insertions(+)

diff --git a/docs/fusa/reqs/market-reqs/reqs.rst b/docs/fusa/reqs/market-reqs/reqs.rst
index f456788d96..47e1b6ad61 100644
--- a/docs/fusa/reqs/market-reqs/reqs.rst
+++ b/docs/fusa/reqs/market-reqs/reqs.rst
@@ -47,3 +47,19 @@ Comments:
 
 Needs:
  - XenProd
+
+Static VM definition
+--------------------
+
+`XenMkt~static_vm_definition~1`
+
+Description:
+Xen shall support assigning peripherals to various domains.
+
+Rationale:
+
+Comments:
+Peripheral implies an iomem (input output memory) and/or interrupts.
+
+Needs:
+ - XenProd
diff --git a/docs/fusa/reqs/product-reqs/arm64/reqs.rst b/docs/fusa/reqs/product-reqs/arm64/reqs.rst
index db91c47a02..66f2978733 100644
--- a/docs/fusa/reqs/product-reqs/arm64/reqs.rst
+++ b/docs/fusa/reqs/product-reqs/arm64/reqs.rst
@@ -40,3 +40,309 @@ Covers:
 
 Needs:
  - XenSwdgn
+
+Linux kernel image
+------------------
+
+`XenProd~linux_kernel_image~1`
+
+Description:
+Xen shall create a domain with a Arm64 Linux kernel image [1].
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Gzip Linux kernel image
+-----------------------
+
+`XenProd~linux_kernel_gzip_image~1`
+
+Description:
+Xen shall create a domain with a Arm64 Gzip compressed Linux kernel image.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Kernel with uImage header
+-------------------------
+
+`XenProd~kernel_uimage~1`
+
+Description:
+Xen shall create a domain with a kernel containing uImage header [2].
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Gzip kernel with uImage header
+------------------------------
+
+`XenSwdgn~arm64_gzip_kernel_uimage~1`
+
+Description:
+Xen shall create a domain with a Gzip compressed kernel containing uImage
+header [2].
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Kernel command line arguments
+-----------------------------
+
+`XenSwdgn~kernel_cmd_line_args~1`
+
+Description:
+Xen shall pass kernel command line arguments to a domain.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Ramdisk
+-------
+
+`XenSwdgn~ramdisk~1`
+
+Description:
+Xen shall provide initial ramdisk to a domain.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Memory
+------
+
+`XenSwdgn~memory~1`
+
+Description:
+Xen shall create a domain with specified amount of memory.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+vCPUs
+-----
+
+`XenSwdgn~vcpus~1`
+
+Description:
+Xen shall create a domain with a number of virtual CPUs.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Credit2 CPU pool scheduler
+--------------------------
+
+`XenSwdgn~credit2_cpu_pool_scheduler~1`
+
+Description:
+Xen shall assign a Credit2 CPU pool scheduler [3] to a domain.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+NUL CPU pool scheduler
+----------------------
+
+`XenSwdgn~nul_cpu_pool_scheduler~1`
+
+Description:
+Xen shall assign a NUL CPU pool scheduler to a domain.
+
+Rationale:
+
+Comments:
+A NUL CPU pool scheduler maps a virtual cpu to a unique physical cpu.
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+SPIs
+----
+
+`XenSwdgn~spis~1`
+
+Description:
+Xen shall allocate a specified number of shared peripheral interrupts for a
+domain.
+
+Rationale:
+
+Comments:
+A shared peripheral interrupt is an interrupt generated by a peripheral that is
+accessible across all the cpu cores.
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+ - `XenMkt~static_vm_definition~1`
+
+Needs:
+ - XenSwdgn
+
+Grant table frames
+------------------
+
+`XenSwdgn~grant_table_frames~1`
+
+Description:
+Xen shall create a domain with a specified number of grant table frames.
+
+Rationale:
+
+Comments:
+Grant tables are a mechanism for sharing and transferring frames (memory buffers)
+between domains.
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Grant maptrack frames
+---------------------
+
+`XenSwdgn~grant_maptrack_frames~1`
+
+Description:
+Xen shall create a domain with a specified number of grant maptrack frames.
+
+Rationale:
+
+Comments:
+Maptrack frame is the metadata for tracking the memory mapped into a domain.
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Virtual PL011
+-------------
+
+`XenProd~virtual_pl011~1`
+
+Description:
+Xen shall provide an "Arm PL011 UART" compliant device to the domains.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+ - `XenMkt~provide_console_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Assign iomem
+------------
+
+`XenProd~assign_iomem~1`
+
+Description:
+Xen shall support assigning iomem to a domain.
+
+Rationale:
+
+Comments:
+
+Rationale:
+
+Covers:
+ - `XenMkt~static_vm_definition~1`
+
+Needs:
+ - XenSwdgn
+
+Forward interrupts
+------------------
+
+`XenProd~forward_irqs~1`
+
+Description:
+Xen shall support forwarding interrupts to a domain.
+
+Rationale:
+
+Comments:
+
+Rationale:
+
+Covers:
+ - `XenMkt~static_vm_definition~1`
+
+Needs:
+ - XenSwdgn
+
+| [1] https://github.com/torvalds/linux/blob/master/Documentation/arch/arm64/booting.rst
+| [2] https://source.denx.de/u-boot/u-boot/-/blob/master/include/image.h#L315
+| [3] https://xenbits.xenproject.org/gitweb/?p=xen.git;a=blob;f=docs/features/sched_credit2.pandoc
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 12 19:21:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 19:21:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856288.1268952 (Exim 4.92)
	(envelope-from )
	id 1tLokZ-0006RS-1X; Thu, 12 Dec 2024 19:21:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856288.1268952; Thu, 12 Dec 2024 19:21: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 1tLokY-0006RL-Ua; Thu, 12 Dec 2024 19:21:26 +0000
Received: by outflank-mailman (input) for mailman id 856288;
 Thu, 12 Dec 2024 19:21: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 1tLokX-0006R7-VY
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 19:21:25 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 456b4b15-b8be-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 20:21:22 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 70AFA5C69F5;
 Thu, 12 Dec 2024 19:20:38 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43DA5C4CECE;
 Thu, 12 Dec 2024 19:21:20 +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: 456b4b15-b8be-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1734031280;
	bh=7jTnse7IuWHCGd/Dl0nDYQ1TbdJrSYaJ37r4en1LiKY=;
	h=Date:From:To:Cc:Subject:In-Reply-To:From;
	b=Jsm8J74CeCOSQX2TAidV+m7FZS6ULNXQzhXeWkuv5iEzrUHcg8znyVLdxbxRPru+9
	 VTNtp1UpRC4YYL3KINlGq6Rm3mDmwWUjLlcvFtcaDdm/sMMc8jL3Lt6IP5xBBVa4uN
	 g6rp1AYKrZau2/lQVHaCgwMigVCU6RnvH5h7xgx9CXno8P90z+4zZDJzkW2VTv9vLB
	 2v8zIQ6uOpGnT4DsGys0y1UkWGeCS95G+7B8sB3FnS30uNrBNXakIEsYRc31wuk1wU
	 pMewcBUam+M54kZf6oMYeSKDOO0eQTk9gVUDIBiga7Z+z4SFYtDLeKSArBCBnotXnd
	 YNml6TBS6OcqA==
Date: Thu, 12 Dec 2024 13:21:18 -0600
From: Bjorn Helgaas 
To: Philipp Stanner 
Cc: amien Le Moal , Niklas Cassel ,
	Basavaraj Natikar ,
	Jiri Kosina ,
	Benjamin Tissoires ,
	Arnd Bergmann ,
	Greg Kroah-Hartman ,
	Alex Dubov ,
	Sudarsana Kalluru ,
	Manish Chopra ,
	Andrew Lunn ,
	"David S. Miller" ,
	Eric Dumazet ,
	Jakub Kicinski , Paolo Abeni ,
	Rasesh Mody , GR-Linux-NIC-Dev@marvell.com,
	Igor Mitsyanko ,
	Sergey Matyukevich ,
	Kalle Valo , Sanjay R Mehta ,
	Shyam Sundar S K ,
	Jon Mason , Dave Jiang ,
	Allen Hubbe ,
	Bjorn Helgaas ,
	Alex Williamson ,
	Juergen Gross ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Mario Limonciello ,
	Chen Ni , Ricky Wu ,
	Al Viro , Breno Leitao ,
	Thomas Gleixner ,
	Kevin Tian ,
	Andy Shevchenko ,
	Mostafa Saleh , Jason Gunthorpe ,
	Yi Liu , Kunwu Chan ,
	Dan Carpenter ,
	"Dr. David Alan Gilbert" ,
	Ankit Agrawal ,
	Reinette Chatre ,
	Eric Auger , Ye Bin ,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-input@vger.kernel.org, netdev@vger.kernel.org,
	linux-wireless@vger.kernel.org, ntb@lists.linux.dev,
	linux-pci@vger.kernel.org, kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 00/11] Remove implicit devres from pci_intx()
Message-ID: <20241212192118.GA3359591@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20241209130632.132074-2-pstanner@redhat.com>

On Mon, Dec 09, 2024 at 02:06:22PM +0100, Philipp Stanner wrote:
> @Driver-Maintainers: Your driver might be touched by patch "Remove
> devres from pci_intx()". You might want to take a look.
> 
> Changes in v3:
>   - Add Thomas' RB.
> 
> Changes in v2:
>   - Drop pci_intx() deprecation patch.
>   - ata: Add RB from Sergey and Niklas.
>   - wifi: Add AB by Kalle.
>   - Drop INTx deprecation patch
>   - Drop ALSA / hda_intel patch because pci_intx() was removed from
>     there in the meantime.
> 
> Changes since the RFC [1]:
>   - Add a patch deprecating pci{m}_intx(). (Heiner, Andy, Me)
>   - Add Acked-by's already given.
>   - Export pcim_intx() as a GPL function. (Alex)
>   - Drop patch for rts5280, since this driver will be removed quite
>     soon. (Philipp Hortmann, Greg)
>   - Use early-return in pci_intx_unmanaged() and pci_intx(). (Andy)
> 
> Hi all,
> 
> this series removes a problematic feature from pci_intx(). That function
> sometimes implicitly uses devres for automatic cleanup. We should get
> rid of this implicit behavior.
> 
> To do so, a pci_intx() version that is always-managed, and one that is
> never-managed are provided. Then, all pci_intx() users are ported to the
> version they need. Afterwards, pci_intx() can be cleaned up and the
> users of the never-managed version be ported back to pci_intx().
> 
> This way we'd get this PCI API consistent again.
> 
> Patch "Remove devres from pci_intx()" obviously reverts the previous
> patches that made drivers use pci_intx_unmanaged(). But this way it's
> easier to review and approve. It also makes sure that each checked out
> commit should provide correct behavior, not just the entire series as a
> whole.
> 
> Merge plan for this is to enter through the PCI tree.
> 
> [1] https://lore.kernel.org/all/20241009083519.10088-1-pstanner@redhat.com/

Applied the ones with maintainer acks to pci/devres for v6.14, thanks!

I'll poke the ones that haven't been acked yet.

> Philipp Stanner (11):
>   PCI: Prepare removing devres from pci_intx()
>   drivers/xen: Use never-managed version of pci_intx()
>   net/ethernet: Use never-managed version of pci_intx()
>   net/ntb: Use never-managed version of pci_intx()
>   misc: Use never-managed version of pci_intx()
>   vfio/pci: Use never-managed version of pci_intx()
>   PCI: MSI: Use never-managed version of pci_intx()
>   ata: Use always-managed version of pci_intx()
>   wifi: qtnfmac: use always-managed version of pcim_intx()
>   HID: amd_sfh: Use always-managed version of pcim_intx()
>   Remove devres from pci_intx()
> 
>  drivers/ata/ahci.c                            |  2 +-
>  drivers/ata/ata_piix.c                        |  2 +-
>  drivers/ata/pata_rdc.c                        |  2 +-
>  drivers/ata/sata_sil24.c                      |  2 +-
>  drivers/ata/sata_sis.c                        |  2 +-
>  drivers/ata/sata_uli.c                        |  2 +-
>  drivers/ata/sata_vsc.c                        |  2 +-
>  drivers/hid/amd-sfh-hid/amd_sfh_pcie.c        |  4 ++--
>  drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c |  2 +-
>  .../wireless/quantenna/qtnfmac/pcie/pcie.c    |  2 +-
>  drivers/pci/devres.c                          | 24 +++----------------
>  drivers/pci/pci.c                             | 16 +++----------
>  include/linux/pci.h                           |  1 +
>  13 files changed, 18 insertions(+), 45 deletions(-)
> 
> -- 
> 2.47.1
> 


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 19:21:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 19:21:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856289.1268961 (Exim 4.92)
	(envelope-from )
	id 1tLokj-0006mx-7t; Thu, 12 Dec 2024 19:21:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856289.1268961; Thu, 12 Dec 2024 19:21:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLokj-0006mq-5Q; Thu, 12 Dec 2024 19:21:37 +0000
Received: by outflank-mailman (input) for mailman id 856289;
 Thu, 12 Dec 2024 19:21: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 1tLokh-0006R7-Jy
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 19:21:35 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4c1b8854-b8be-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 20:21:33 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 13684A42A1B;
 Thu, 12 Dec 2024 19:19:41 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id BF63AC4CECE;
 Thu, 12 Dec 2024 19:21: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: 4c1b8854-b8be-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1734031292;
	bh=IbIwv1jGi3ADBtK60JNsHHHrXo2ysodiR7fOfGgUVZU=;
	h=Date:From:To:Cc:Subject:In-Reply-To:From;
	b=X7Ww+fY+bDJtf3JxD/fNdF9zPIqj7pIGW/Dr+8Hy8zeOUa7vem/i36jiSgi47zLR3
	 YpC9QVHuv7/PiiXwbFbJuD7PWiQvUm4tLZL89I7y6drN/IISf9C/h2IC7qJcgPOCYO
	 TnykuuOqWi0PRGE6pVEOPgNxJnBWWG52IOH275lcGsYtS8MPZd1Ks1XKaW1+ryZtpO
	 IXw35zDUnBs6v/FBtZoqMaTrIZOPnPE0vABs8PZYyW8Z8fcrhs9GihaNd+TgvR5kYJ
	 gFO04DIRnzP1eI07UKaDS8MVDbssUZ/lDF97BIT7ZiYJkn87B953qsx+t4Wp9qf70X
	 d8haM3Qwmd07Q==
Date: Thu, 12 Dec 2024 13:21:30 -0600
From: Bjorn Helgaas 
To: Philipp Stanner ,
	Alex Williamson 
Cc: amien Le Moal , Niklas Cassel ,
	Basavaraj Natikar ,
	Jiri Kosina ,
	Benjamin Tissoires ,
	Arnd Bergmann ,
	Greg Kroah-Hartman ,
	Alex Dubov ,
	Sudarsana Kalluru ,
	Manish Chopra ,
	Andrew Lunn ,
	"David S. Miller" ,
	Eric Dumazet ,
	Jakub Kicinski , Paolo Abeni ,
	Rasesh Mody , GR-Linux-NIC-Dev@marvell.com,
	Igor Mitsyanko ,
	Sergey Matyukevich ,
	Kalle Valo , Sanjay R Mehta ,
	Shyam Sundar S K ,
	Jon Mason , Dave Jiang ,
	Allen Hubbe ,
	Bjorn Helgaas ,
	Juergen Gross ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Mario Limonciello ,
	Chen Ni , Ricky Wu ,
	Al Viro , Breno Leitao ,
	Thomas Gleixner ,
	Kevin Tian ,
	Andy Shevchenko ,
	Mostafa Saleh , Jason Gunthorpe ,
	Yi Liu , Kunwu Chan ,
	Dan Carpenter ,
	"Dr. David Alan Gilbert" ,
	Ankit Agrawal ,
	Reinette Chatre ,
	Eric Auger , Ye Bin ,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-input@vger.kernel.org, netdev@vger.kernel.org,
	linux-wireless@vger.kernel.org, ntb@lists.linux.dev,
	linux-pci@vger.kernel.org, kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 06/11] vfio/pci: Use never-managed version of
 pci_intx()
Message-ID: <20241212192130.GA3359535@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20241209130632.132074-8-pstanner@redhat.com>

[cc->to: Alex W]

On Mon, Dec 09, 2024 at 02:06:28PM +0100, Philipp Stanner wrote:
> pci_intx() is a hybrid function which can sometimes be managed through
> devres. To remove this hybrid nature from pci_intx(), it is necessary to
> port users to either an always-managed or a never-managed version.
> 
> vfio enables its PCI-Device with pci_enable_device(). Thus, it
> needs the never-managed version.
> 
> Replace pci_intx() with pci_intx_unmanaged().
> 
> Signed-off-by: Philipp Stanner 

Not applied yet, pending ack from Alex.

> ---
>  drivers/vfio/pci/vfio_pci_core.c  |  2 +-
>  drivers/vfio/pci/vfio_pci_intrs.c | 10 +++++-----
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
> index 1ab58da9f38a..90240c8d51aa 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -498,7 +498,7 @@ int vfio_pci_core_enable(struct vfio_pci_core_device *vdev)
>  		if (vfio_pci_nointx(pdev)) {
>  			pci_info(pdev, "Masking broken INTx support\n");
>  			vdev->nointx = true;
> -			pci_intx(pdev, 0);
> +			pci_intx_unmanaged(pdev, 0);
>  		} else
>  			vdev->pci_2_3 = pci_intx_mask_supported(pdev);
>  	}
> diff --git a/drivers/vfio/pci/vfio_pci_intrs.c b/drivers/vfio/pci/vfio_pci_intrs.c
> index 8382c5834335..40abb0b937a2 100644
> --- a/drivers/vfio/pci/vfio_pci_intrs.c
> +++ b/drivers/vfio/pci/vfio_pci_intrs.c
> @@ -118,7 +118,7 @@ static bool __vfio_pci_intx_mask(struct vfio_pci_core_device *vdev)
>  	 */
>  	if (unlikely(!is_intx(vdev))) {
>  		if (vdev->pci_2_3)
> -			pci_intx(pdev, 0);
> +			pci_intx_unmanaged(pdev, 0);
>  		goto out_unlock;
>  	}
>  
> @@ -132,7 +132,7 @@ static bool __vfio_pci_intx_mask(struct vfio_pci_core_device *vdev)
>  		 * mask, not just when something is pending.
>  		 */
>  		if (vdev->pci_2_3)
> -			pci_intx(pdev, 0);
> +			pci_intx_unmanaged(pdev, 0);
>  		else
>  			disable_irq_nosync(pdev->irq);
>  
> @@ -178,7 +178,7 @@ static int vfio_pci_intx_unmask_handler(void *opaque, void *data)
>  	 */
>  	if (unlikely(!is_intx(vdev))) {
>  		if (vdev->pci_2_3)
> -			pci_intx(pdev, 1);
> +			pci_intx_unmanaged(pdev, 1);
>  		goto out_unlock;
>  	}
>  
> @@ -296,7 +296,7 @@ static int vfio_intx_enable(struct vfio_pci_core_device *vdev,
>  	 */
>  	ctx->masked = vdev->virq_disabled;
>  	if (vdev->pci_2_3) {
> -		pci_intx(pdev, !ctx->masked);
> +		pci_intx_unmanaged(pdev, !ctx->masked);
>  		irqflags = IRQF_SHARED;
>  	} else {
>  		irqflags = ctx->masked ? IRQF_NO_AUTOEN : 0;
> @@ -569,7 +569,7 @@ static void vfio_msi_disable(struct vfio_pci_core_device *vdev, bool msix)
>  	 * via their shutdown paths.  Restore for NoINTx devices.
>  	 */
>  	if (vdev->nointx)
> -		pci_intx(pdev, 0);
> +		pci_intx_unmanaged(pdev, 0);
>  
>  	vdev->irq_type = VFIO_PCI_NUM_IRQS;
>  }
> -- 
> 2.47.1
> 


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 19:24:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 19:24:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856308.1268972 (Exim 4.92)
	(envelope-from )
	id 1tLonJ-0008Dr-Kc; Thu, 12 Dec 2024 19:24:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856308.1268972; Thu, 12 Dec 2024 19:24: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 1tLonJ-0008Dk-Hw; Thu, 12 Dec 2024 19:24:17 +0000
Received: by outflank-mailman (input) for mailman id 856308;
 Thu, 12 Dec 2024 19:24: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 1tLonI-0008De-0A
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 19:24:16 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ab1b9912-b8be-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 20:24:13 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 787995C6A11;
 Thu, 12 Dec 2024 19:23:29 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58F31C4CECE;
 Thu, 12 Dec 2024 19:24:11 +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: ab1b9912-b8be-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1734031451;
	bh=1drleKSVmSZecvjLL637vpj9Uwu8sP8KERGudhXDLZw=;
	h=Date:From:To:Cc:Subject:In-Reply-To:From;
	b=AhBebKxOvxeSefMCQemAWxdtkP4lVSLp5/JlRJC4BX23eiI2Dl5bBHYOzHkMhk3wt
	 OAKQyIj5oWEFDKCXqKn3KUvYZcII+c+3REDcqSqR6azZ1GnrIpXKBVzFidMWXQ3pKZ
	 R5A3dM3mkD/Z183rT7dmOaL89lpe1hKYJP8js22v6fuP/RNOss2jpGL+dIcGyXDW4B
	 fJUEwnK84ONbYJE1CE/5Ci++Vj2VlTYdpRGnc77CNZ7XTaG22cuCJ+XeVcOimFy80u
	 psMKUA60y/77EjFe3Zp7qZwmaKzvSPciD45Yc0j4otDxKpHaTxdtEPPVrPUhumAZOb
	 JI/VpaGWfDtow==
Date: Thu, 12 Dec 2024 13:24:10 -0600
From: Bjorn Helgaas 
To: Philipp Stanner ,
	Sudarsana Kalluru ,
	Manish Chopra ,
	Rasesh Mody 
Cc: Damien Le Moal , Niklas Cassel ,
	Basavaraj Natikar ,
	Jiri Kosina ,
	Benjamin Tissoires ,
	Arnd Bergmann ,
	Greg Kroah-Hartman ,
	Alex Dubov , Andrew Lunn ,
	"David S. Miller" ,
	Eric Dumazet ,
	Jakub Kicinski , Paolo Abeni ,
	GR-Linux-NIC-Dev@marvell.com,
	Igor Mitsyanko ,
	Sergey Matyukevich ,
	Kalle Valo , Sanjay R Mehta ,
	Shyam Sundar S K ,
	Jon Mason , Dave Jiang ,
	Allen Hubbe ,
	Bjorn Helgaas ,
	Alex Williamson ,
	Juergen Gross ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Mario Limonciello ,
	Chen Ni , Ricky Wu ,
	Al Viro , Breno Leitao ,
	Thomas Gleixner ,
	Kevin Tian ,
	Andy Shevchenko ,
	Mostafa Saleh , Jason Gunthorpe ,
	Yi Liu , Kunwu Chan ,
	Dan Carpenter ,
	"Dr. David Alan Gilbert" ,
	Ankit Agrawal ,
	Reinette Chatre ,
	Eric Auger , Ye Bin ,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-input@vger.kernel.org, netdev@vger.kernel.org,
	linux-wireless@vger.kernel.org, ntb@lists.linux.dev,
	linux-pci@vger.kernel.org, kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 03/11] net/ethernet: Use never-managed version of
 pci_intx()
Message-ID: <20241212192410.GA3359655@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20241209130632.132074-5-pstanner@redhat.com>

[cc->to: Sudarsana, Manish, Rasesh]

On Mon, Dec 09, 2024 at 02:06:25PM +0100, Philipp Stanner wrote:
> pci_intx() is a hybrid function which can sometimes be managed through
> devres. To remove this hybrid nature from pci_intx(), it is necessary to
> port users to either an always-managed or a never-managed version.
> 
> broadcom/bnx2x and brocade/bna enable their PCI-Device with
> pci_enable_device(). Thus, they need the never-managed version.
> 
> Replace pci_intx() with pci_intx_unmanaged().
> 
> Signed-off-by: Philipp Stanner 

Hoping for an ack from Sudarsana, Manish, Rasesh.

> ---
>  drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
>  drivers/net/ethernet/brocade/bna/bnad.c          | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> index 678829646cec..2ae63d6e6792 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
> @@ -1669,7 +1669,7 @@ static void bnx2x_igu_int_enable(struct bnx2x *bp)
>  	REG_WR(bp, IGU_REG_PF_CONFIGURATION, val);
>  
>  	if (val & IGU_PF_CONF_INT_LINE_EN)
> -		pci_intx(bp->pdev, true);
> +		pci_intx_unmanaged(bp->pdev, true);
>  
>  	barrier();
>  
> diff --git a/drivers/net/ethernet/brocade/bna/bnad.c b/drivers/net/ethernet/brocade/bna/bnad.c
> index ece6f3b48327..2b37462d406e 100644
> --- a/drivers/net/ethernet/brocade/bna/bnad.c
> +++ b/drivers/net/ethernet/brocade/bna/bnad.c
> @@ -2669,7 +2669,7 @@ bnad_enable_msix(struct bnad *bnad)
>  		}
>  	}
>  
> -	pci_intx(bnad->pcidev, 0);
> +	pci_intx_unmanaged(bnad->pcidev, 0);
>  
>  	return;
>  
> -- 
> 2.47.1
> 


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 19:26:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 19:26:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856320.1268981 (Exim 4.92)
	(envelope-from )
	id 1tLopf-0000LG-W9; Thu, 12 Dec 2024 19:26:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856320.1268981; Thu, 12 Dec 2024 19:26:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLopf-0000L9-TT; Thu, 12 Dec 2024 19:26:43 +0000
Received: by outflank-mailman (input) for mailman id 856320;
 Thu, 12 Dec 2024 19:26: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 1tLope-0000Kv-AN
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 19:26:42 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 031ed518-b8bf-11ef-a0d6-8be0dac302b0;
 Thu, 12 Dec 2024 20:26:40 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 61C5BA42A34;
 Thu, 12 Dec 2024 19:24:48 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2FE3DC4CECE;
 Thu, 12 Dec 2024 19:26: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: 031ed518-b8bf-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1734031599;
	bh=GY8df68Vpq13zRfn9lQiZuhcp6ZPERGYWUjygEgKyfo=;
	h=Date:From:To:Cc:Subject:In-Reply-To:From;
	b=Nq8DebfnKz6oRj40JuP2b63VJxYs2cK7koMQE4wqMV6qD2csMUAgK5AzSgqwbBYEL
	 u9euMyyzqa7e7GkjVAp6yQfo1AZ2Co8EJsXQ4Tm39YjgSAGT4PgrOZSOipNdus0wWP
	 5jEOuPBPs1+JKN2ABFGyBe3bAHjHJXDBdMubHDqVFWJ7Vy1RPqX8Fa+BwvWlMEiPRP
	 qSJu+l8/ulTi3y9AwZpqtrLG6q55HekV8WDMGP0u1YdCkLSXeeoiRpw137PWbZFSeR
	 0v5Q/aRW85aEzTfeInJqQ6lZPduXCDaQWJCKCHPvbJoZteMnM1UyL4vc31qeB26R6X
	 PJXIBsPc6+D8Q==
Date: Thu, 12 Dec 2024 13:26:37 -0600
From: Bjorn Helgaas 
To: Philipp Stanner , Arnd Bergmann ,
	Greg Kroah-Hartman ,
	Alex Dubov 
Cc: amien Le Moal , Niklas Cassel ,
	Basavaraj Natikar ,
	Jiri Kosina ,
	Benjamin Tissoires ,
	Sudarsana Kalluru ,
	Manish Chopra ,
	Andrew Lunn ,
	"David S. Miller" ,
	Eric Dumazet ,
	Jakub Kicinski , Paolo Abeni ,
	Rasesh Mody , GR-Linux-NIC-Dev@marvell.com,
	Igor Mitsyanko ,
	Sergey Matyukevich ,
	Kalle Valo , Sanjay R Mehta ,
	Shyam Sundar S K ,
	Jon Mason , Dave Jiang ,
	Allen Hubbe ,
	Bjorn Helgaas ,
	Alex Williamson ,
	Juergen Gross ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Mario Limonciello ,
	Chen Ni , Ricky Wu ,
	Al Viro , Breno Leitao ,
	Thomas Gleixner ,
	Kevin Tian ,
	Andy Shevchenko ,
	Mostafa Saleh , Jason Gunthorpe ,
	Yi Liu , Kunwu Chan ,
	Dan Carpenter ,
	"Dr. David Alan Gilbert" ,
	Ankit Agrawal ,
	Reinette Chatre ,
	Eric Auger , Ye Bin ,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-input@vger.kernel.org, netdev@vger.kernel.org,
	linux-wireless@vger.kernel.org, ntb@lists.linux.dev,
	linux-pci@vger.kernel.org, kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 05/11] misc: Use never-managed version of pci_intx()
Message-ID: <20241212192637.GA3359920@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20241209130632.132074-7-pstanner@redhat.com>

[cc->to: Arnd, Greg, Alex]

On Mon, Dec 09, 2024 at 02:06:27PM +0100, Philipp Stanner wrote:
> pci_intx() is a hybrid function which can sometimes be managed through
> devres. To remove this hybrid nature from pci_intx(), it is necessary to
> port users to either an always-managed or a never-managed version.
> 
> cardreader/rtsx_pcr.c and tifm_7xx1.c enable their PCI-Device with
> pci_enable_device(). Thus, they need the never-managed version.
> 
> Replace pci_intx() with pci_intx_unmanaged().
> 
> Signed-off-by: Philipp Stanner 

Looking for ack from Arnd, Greg, Alex.

> ---
>  drivers/misc/cardreader/rtsx_pcr.c | 2 +-
>  drivers/misc/tifm_7xx1.c           | 6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/misc/cardreader/rtsx_pcr.c b/drivers/misc/cardreader/rtsx_pcr.c
> index be3d4e0e50cc..e25e6d560dd7 100644
> --- a/drivers/misc/cardreader/rtsx_pcr.c
> +++ b/drivers/misc/cardreader/rtsx_pcr.c
> @@ -1057,7 +1057,7 @@ static int rtsx_pci_acquire_irq(struct rtsx_pcr *pcr)
>  	}
>  
>  	pcr->irq = pcr->pci->irq;
> -	pci_intx(pcr->pci, !pcr->msi_en);
> +	pci_intx_unmanaged(pcr->pci, !pcr->msi_en);
>  
>  	return 0;
>  }
> diff --git a/drivers/misc/tifm_7xx1.c b/drivers/misc/tifm_7xx1.c
> index 1d54680d6ed2..5f9c7ccae8d2 100644
> --- a/drivers/misc/tifm_7xx1.c
> +++ b/drivers/misc/tifm_7xx1.c
> @@ -327,7 +327,7 @@ static int tifm_7xx1_probe(struct pci_dev *dev,
>  		goto err_out;
>  	}
>  
> -	pci_intx(dev, 1);
> +	pci_intx_unmanaged(dev, 1);
>  
>  	fm = tifm_alloc_adapter(dev->device == PCI_DEVICE_ID_TI_XX21_XX11_FM
>  				? 4 : 2, &dev->dev);
> @@ -368,7 +368,7 @@ static int tifm_7xx1_probe(struct pci_dev *dev,
>  err_out_free:
>  	tifm_free_adapter(fm);
>  err_out_int:
> -	pci_intx(dev, 0);
> +	pci_intx_unmanaged(dev, 0);
>  	pci_release_regions(dev);
>  err_out:
>  	if (!pci_dev_busy)
> @@ -392,7 +392,7 @@ static void tifm_7xx1_remove(struct pci_dev *dev)
>  		tifm_7xx1_sock_power_off(tifm_7xx1_sock_addr(fm->addr, cnt));
>  
>  	iounmap(fm->addr);
> -	pci_intx(dev, 0);
> +	pci_intx_unmanaged(dev, 0);
>  	pci_release_regions(dev);
>  
>  	pci_disable_device(dev);
> -- 
> 2.47.1
> 


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 19:29:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 19:29:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856335.1268991 (Exim 4.92)
	(envelope-from )
	id 1tLosX-0000w6-Dg; Thu, 12 Dec 2024 19:29:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856335.1268991; Thu, 12 Dec 2024 19:29: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 1tLosX-0000vz-Al; Thu, 12 Dec 2024 19:29:41 +0000
Received: by outflank-mailman (input) for mailman id 856335;
 Thu, 12 Dec 2024 19:29: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 1tLosW-0000vt-D6
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 19:29:40 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6cb09838-b8bf-11ef-99a3-01e77a169b0f;
 Thu, 12 Dec 2024 20:29:37 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id A56B1A42A18;
 Thu, 12 Dec 2024 19:27:45 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5CF19C4CECE;
 Thu, 12 Dec 2024 19:29:36 +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: 6cb09838-b8bf-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1734031776;
	bh=WYoQMRv5P87I4hjtnXW8jZn4JiuWP9wJLhfOJzWWED8=;
	h=Date:From:To:Cc:Subject:In-Reply-To:From;
	b=d8Cw2aVsk35SPPPau+WmwKHftXtxOtBGxzABqjUp3VewkjoIOKo8B2KXqKje+JVSP
	 djTBvJiul67mWCuDNPW4/7UmW1JpZA0Oe5fd7eFxyNc9E3jTYVs++scwAbEKvN2iio
	 ASWerK5IzlxQVYyY4PM1IgFrHu0PGaU7uXur0la91TTLygMlSjhi0SElqDcrayVRMc
	 0tYs1Hf43YjllDIP7BU4vZCfLJYJF9u51IjbOaLqSBjARf2gjtT5Lvj9TK90DQ5pmV
	 rzwfJOkKAeZX8PAqSxmH3Y12S6t6PJiSyxTumghytGk8wMXEJrBvzc6gMccg5kHs/2
	 saRXMHh0KSqZQ==
Date: Thu, 12 Dec 2024 13:29:35 -0600
From: Bjorn Helgaas 
To: Philipp Stanner ,
	Igor Mitsyanko 
Cc: amien Le Moal , Niklas Cassel ,
	Basavaraj Natikar ,
	Jiri Kosina ,
	Benjamin Tissoires ,
	Arnd Bergmann ,
	Sergey Matyukevich ,
	Greg Kroah-Hartman ,
	Alex Dubov ,
	Sudarsana Kalluru ,
	Manish Chopra ,
	Andrew Lunn ,
	"David S. Miller" ,
	Eric Dumazet ,
	Jakub Kicinski , Paolo Abeni ,
	Rasesh Mody , GR-Linux-NIC-Dev@marvell.com,
	Kalle Valo , Sanjay R Mehta ,
	Shyam Sundar S K ,
	Jon Mason , Dave Jiang ,
	Allen Hubbe ,
	Bjorn Helgaas ,
	Alex Williamson ,
	Juergen Gross ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Mario Limonciello ,
	Chen Ni , Ricky Wu ,
	Al Viro , Breno Leitao ,
	Thomas Gleixner ,
	Kevin Tian ,
	Andy Shevchenko ,
	Mostafa Saleh , Jason Gunthorpe ,
	Yi Liu , Kunwu Chan ,
	Dan Carpenter ,
	"Dr. David Alan Gilbert" ,
	Ankit Agrawal ,
	Reinette Chatre ,
	Eric Auger , Ye Bin ,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-input@vger.kernel.org, netdev@vger.kernel.org,
	linux-wireless@vger.kernel.org, ntb@lists.linux.dev,
	linux-pci@vger.kernel.org, kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 09/11] wifi: qtnfmac: use always-managed version of
 pcim_intx()
Message-ID: <20241212192935.GA3360239@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20241209130632.132074-11-pstanner@redhat.com>

[cc->to: Igor]

On Mon, Dec 09, 2024 at 02:06:31PM +0100, Philipp Stanner wrote:
> pci_intx() is a hybrid function which can sometimes be managed through
> devres. To remove this hybrid nature from pci_intx(), it is necessary to
> port users to either an always-managed or a never-managed version.
> 
> qtnfmac enables its PCI-Device with pcim_enable_device(). Thus, it needs
> the always-managed version.
> 
> Replace pci_intx() with pcim_intx().
> 
> Signed-off-by: Philipp Stanner 
> Acked-by: Kalle Valo 

Hoping for an ack from Igor, too.

> ---
>  drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c b/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c
> index f66eb43094d4..3adcfac2886f 100644
> --- a/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c
> +++ b/drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c
> @@ -204,7 +204,7 @@ static void qtnf_pcie_init_irq(struct qtnf_pcie_bus_priv *priv, bool use_msi)
>  
>  	if (!priv->msi_enabled) {
>  		pr_warn("legacy PCIE interrupts enabled\n");
> -		pci_intx(pdev, 1);
> +		pcim_intx(pdev, 1);
>  	}
>  }
>  
> -- 
> 2.47.1
> 


From xen-devel-bounces@lists.xenproject.org Thu Dec 12 19:49:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Dec 2024 19:49:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856352.1269001 (Exim 4.92)
	(envelope-from )
	id 1tLpBh-0005To-2T; Thu, 12 Dec 2024 19:49:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856352.1269001; Thu, 12 Dec 2024 19:49:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLpBg-0005Th-WE; Thu, 12 Dec 2024 19:49:29 +0000
Received: by outflank-mailman (input) for mailman id 856352;
 Thu, 12 Dec 2024 19:49: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 1tLpBf-0005Tb-V9
 for xen-devel@lists.xenproject.org; Thu, 12 Dec 2024 19:49:28 +0000
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2fc87687-b8c2-11ef-a0d6-8be0dac302b0;
 Thu, 12 Dec 2024 20:49:25 +0100 (CET)
Received: from mail-io1-f72.google.com (mail-io1-f72.google.com
 [209.85.166.72]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-495-Z7_gqxJQMa2Dj4jdHdOe_g-1; Thu, 12 Dec 2024 14:49:22 -0500
Received: by mail-io1-f72.google.com with SMTP id
 ca18e2360f4ac-844ca9b7233so12323939f.3
 for ; Thu, 12 Dec 2024 11:49:22 -0800 (PST)
Received: from redhat.com ([38.15.36.11]) by smtp.gmail.com with ESMTPSA id
 ca18e2360f4ac-844737bc5e7sm434751139f.7.2024.12.12.11.49.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Dec 2024 11:49:20 -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: 2fc87687-b8c2-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1734032963;
	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=sBiPw5OuI7dlO4Z4t4oS+jtz5kPmxd4ZnxuDxig2hUM=;
	b=gjOL4fMqzHZ/IO3tgHl8lojM40em91HWsjhswwEkjgbgXAikWI9wt319d7d6BhryRyrxqm
	U8bs5vPMtxGGa+G4RZvgeBjb8Q04zJU94syrREkfOpe37B4YCEaOQq1abGQ8RldEtWu4ew
	69ZGaFqQRIWJB2FvH5E8/xoT5Y/JYto=
X-MC-Unique: Z7_gqxJQMa2Dj4jdHdOe_g-1
X-Mimecast-MFC-AGG-ID: Z7_gqxJQMa2Dj4jdHdOe_g
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734032961; x=1734637761;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=sBiPw5OuI7dlO4Z4t4oS+jtz5kPmxd4ZnxuDxig2hUM=;
        b=TCB/LlH2bpnJHvcrogffBoTdmKIQhRGLoA3teDPfYzcHbs9sEERo0+fi5NPCzBO0n/
         6GuQTX6q8xXZCdf4yZw3uFFrD2Zu9tylkH40ptlS4XIHgCKJEtsKotlfUdXQO48FWXO9
         r4O/bkJaQIO/TTn6CUZzigoFUdJ+flk/YGVecrdyHyV++lJvCeu/UHLK9hnCL4Q35eNL
         O5/NcFc8YwBV8X30PpLDKgSLm3OFe1H5vVYDlH7aSBOBUrfjra/Z1cym5wgRTloLvYWg
         zq2Bl2fz923KnbsVOtPBwd3Vi1NKzHT4+vHDckQbkOYk7+paun8D630RtP2+RB0eB2wM
         woPg==
X-Forwarded-Encrypted: i=1; AJvYcCXJmBAmQSvs8emN6ebGpN1quCbRcLPxk/PYe5F5KoGJiGjAKg5qorG5IqOztsYTQ+DT5X2mmUjc7Ek=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwWQxJXPtXauBd7NqFo0A3aqNRNTOeaYXbTZ+YKuGPbDA3F+HBT
	yyt4vhdPOMNlqLC8Hbf2lwSzral4LNjNGzfYTYM2oyHrj8HolPJlIMXQ4Qa7N6LCyeNWUV/Kb5W
	+yzqxc+uUH+byKt2EJCqLVLIuSE+GpffEdI98pv9jb3i1kiPO1ZPZ+F4LoWd5rH0o
X-Gm-Gg: ASbGncsw7FGqj7Qao+/kYw22tlZqi0mbytaK2YaCDRyuFA6f4Y+lFRcpYa3Iixygwzd
	AAf5/w5NPVbSeiLQS4jc7e4ndym+daOzRmG/sPBW5yrysIfgD5Fhk+mFgG940GWdx47Edc6ZK8e
	ebXL7Yilf8Q2FhbrhNEkXALUhb969+kzQhbEMHsSalLxGO1TqfRYzOGsTgKMwP+haR1/bNGSVNS
	IBksU1y15Z8l+y70mR906bUp1s1XST+Q3KlFHh5Lvn7NCSzGMITitnA3Yl6
X-Received: by 2002:a05:6602:1593:b0:83a:acc8:5faf with SMTP id ca18e2360f4ac-844e8a3f0b7mr2639739f.5.1734032961291;
        Thu, 12 Dec 2024 11:49:21 -0800 (PST)
X-Google-Smtp-Source: AGHT+IERcvaNomxn8th3z3SWMQIAn0f18rUBb5b4dBUVRvcRJcJEoHv6gpei7+xXPBScGwtQKEbPgQ==
X-Received: by 2002:a05:6602:1593:b0:83a:acc8:5faf with SMTP id ca18e2360f4ac-844e8a3f0b7mr2638439f.5.1734032960861;
        Thu, 12 Dec 2024 11:49:20 -0800 (PST)
Date: Thu, 12 Dec 2024 12:49:18 -0700
From: Alex Williamson 
To: Bjorn Helgaas 
Cc: Philipp Stanner , amien Le Moal
 , Niklas Cassel , Basavaraj Natikar
 , Jiri Kosina , Benjamin
 Tissoires , Arnd Bergmann , Greg
 Kroah-Hartman , Alex Dubov ,
 Sudarsana Kalluru , Manish Chopra
 , Andrew Lunn , "David S.
 Miller" , Eric Dumazet , Jakub
 Kicinski , Paolo Abeni , Rasesh Mody
 , GR-Linux-NIC-Dev@marvell.com, Igor Mitsyanko
 , Sergey Matyukevich , Kalle
 Valo , Sanjay R Mehta , Shyam Sundar
 S K , Jon Mason , Dave Jiang
 , Allen Hubbe , Bjorn Helgaas
 , Juergen Gross , Stefano Stabellini
 , Oleksandr Tyshchenko
 , Mario Limonciello
 , Chen Ni , Ricky Wu
 , Al Viro , Breno Leitao
 , Thomas Gleixner , Kevin Tian
 , Andy Shevchenko
 , Mostafa Saleh ,
 Jason Gunthorpe , Yi Liu , Kunwu Chan
 , Dan Carpenter , "Dr. David
 Alan Gilbert" , Ankit Agrawal ,
 Reinette Chatre , Eric Auger
 , Ye Bin ,
 linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
 linux-input@vger.kernel.org, netdev@vger.kernel.org,
 linux-wireless@vger.kernel.org, ntb@lists.linux.dev,
 linux-pci@vger.kernel.org, kvm@vger.kernel.org,
 xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 06/11] vfio/pci: Use never-managed version of
 pci_intx()
Message-ID: <20241212124918.0dd284fe.alex.williamson@redhat.com>
In-Reply-To: <20241212192130.GA3359535@bhelgaas>
References: <20241209130632.132074-8-pstanner@redhat.com>
	<20241212192130.GA3359535@bhelgaas>
X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: xIqkPECxcMXjk7foFdmh8PgcK_77g-S7Ac8RixG-TXY_1734032961
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 12 Dec 2024 13:21:30 -0600
Bjorn Helgaas  wrote:

> [cc->to: Alex W]
> 
> On Mon, Dec 09, 2024 at 02:06:28PM +0100, Philipp Stanner wrote:
> > pci_intx() is a hybrid function which can sometimes be managed through
> > devres. To remove this hybrid nature from pci_intx(), it is necessary to
> > port users to either an always-managed or a never-managed version.
> > 
> > vfio enables its PCI-Device with pci_enable_device(). Thus, it
> > needs the never-managed version.
> > 
> > Replace pci_intx() with pci_intx_unmanaged().
> > 
> > Signed-off-by: Philipp Stanner   
> 
> Not applied yet, pending ack from Alex.

Acked-by: Alex Williamson 

> 
> > ---
> >  drivers/vfio/pci/vfio_pci_core.c  |  2 +-
> >  drivers/vfio/pci/vfio_pci_intrs.c | 10 +++++-----
> >  2 files changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
> > index 1ab58da9f38a..90240c8d51aa 100644
> > --- a/drivers/vfio/pci/vfio_pci_core.c
> > +++ b/drivers/vfio/pci/vfio_pci_core.c
> > @@ -498,7 +498,7 @@ int vfio_pci_core_enable(struct vfio_pci_core_device *vdev)
> >  		if (vfio_pci_nointx(pdev)) {
> >  			pci_info(pdev, "Masking broken INTx support\n");
> >  			vdev->nointx = true;
> > -			pci_intx(pdev, 0);
> > +			pci_intx_unmanaged(pdev, 0);
> >  		} else
> >  			vdev->pci_2_3 = pci_intx_mask_supported(pdev);
> >  	}
> > diff --git a/drivers/vfio/pci/vfio_pci_intrs.c b/drivers/vfio/pci/vfio_pci_intrs.c
> > index 8382c5834335..40abb0b937a2 100644
> > --- a/drivers/vfio/pci/vfio_pci_intrs.c
> > +++ b/drivers/vfio/pci/vfio_pci_intrs.c
> > @@ -118,7 +118,7 @@ static bool __vfio_pci_intx_mask(struct vfio_pci_core_device *vdev)
> >  	 */
> >  	if (unlikely(!is_intx(vdev))) {
> >  		if (vdev->pci_2_3)
> > -			pci_intx(pdev, 0);
> > +			pci_intx_unmanaged(pdev, 0);
> >  		goto out_unlock;
> >  	}
> >  
> > @@ -132,7 +132,7 @@ static bool __vfio_pci_intx_mask(struct vfio_pci_core_device *vdev)
> >  		 * mask, not just when something is pending.
> >  		 */
> >  		if (vdev->pci_2_3)
> > -			pci_intx(pdev, 0);
> > +			pci_intx_unmanaged(pdev, 0);
> >  		else
> >  			disable_irq_nosync(pdev->irq);
> >  
> > @@ -178,7 +178,7 @@ static int vfio_pci_intx_unmask_handler(void *opaque, void *data)
> >  	 */
> >  	if (unlikely(!is_intx(vdev))) {
> >  		if (vdev->pci_2_3)
> > -			pci_intx(pdev, 1);
> > +			pci_intx_unmanaged(pdev, 1);
> >  		goto out_unlock;
> >  	}
> >  
> > @@ -296,7 +296,7 @@ static int vfio_intx_enable(struct vfio_pci_core_device *vdev,
> >  	 */
> >  	ctx->masked = vdev->virq_disabled;
> >  	if (vdev->pci_2_3) {
> > -		pci_intx(pdev, !ctx->masked);
> > +		pci_intx_unmanaged(pdev, !ctx->masked);
> >  		irqflags = IRQF_SHARED;
> >  	} else {
> >  		irqflags = ctx->masked ? IRQF_NO_AUTOEN : 0;
> > @@ -569,7 +569,7 @@ static void vfio_msi_disable(struct vfio_pci_core_device *vdev, bool msix)
> >  	 * via their shutdown paths.  Restore for NoINTx devices.
> >  	 */
> >  	if (vdev->nointx)
> > -		pci_intx(pdev, 0);
> > +		pci_intx_unmanaged(pdev, 0);
> >  
> >  	vdev->irq_type = VFIO_PCI_NUM_IRQS;
> >  }
> > -- 
> > 2.47.1
> >   
> 



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 00:54:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 00:54:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856387.1269014 (Exim 4.92)
	(envelope-from )
	id 1tLtwJ-0001td-UG; Fri, 13 Dec 2024 00:53:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856387.1269014; Fri, 13 Dec 2024 00:53:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLtwJ-0001tW-Rq; Fri, 13 Dec 2024 00:53:55 +0000
Received: by outflank-mailman (input) for mailman id 856387;
 Fri, 13 Dec 2024 00:53: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 1tLtwI-0001tQ-5x
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 00:53:54 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org
 [2604:1380:45d1:ec00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b838b41c-b8ec-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 01:53:52 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id CA471A407E7;
 Fri, 13 Dec 2024 00:51:59 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 53B64C4CECE;
 Fri, 13 Dec 2024 00:53:49 +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: b838b41c-b8ec-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1734051230;
	bh=NyuJI6XNqmKZXrETVVV29wBB2MR8InJJ+U3680Zl94k=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=otasr8A1QoZKSZp4BcqBL704QnCoDzrHWoaEEMh/DK0YQU56D16/3qXPgsda4Fuhv
	 3oqnjViJrygUoLxqbLZwYplzqqS2gKjHvbamd4X3u58/O8tTX2WJSrZ83N9JCNPMpm
	 Av1z4PYd2JlnKV4ICsKT+hmte2TZ4KgMkxNaMcLtb1LOGhk6bzbpvPDdGVeMrLT+CK
	 WU8VO0P4R4FnyAEm5mLxNVS3P/GwVuMIS/QyTvQagdnjA7lAWkxgjFy28N9M3puizC
	 kwFvTqM+9FB1hunWijbK+Dleb1gL69kS/cbBGkkqF3Acdbm5ne0QQdK5okjtULa58t
	 BaabOnfBSonsw==
Date: Thu, 12 Dec 2024 16:53:48 -0800 (PST)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , 
    Alessandro Zucchelli , 
    consulting@bugseng.com, Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen: address violation of MISRA C Rule 11.1
In-Reply-To: <26600bb0-93af-45b5-a341-5771bad844a1@suse.com>
Message-ID: 
References: <7debd63f3900bad62bcbcc03081e4c04e6099135.1733914487.git.alessandro.zucchelli@bugseng.com>  
 <26600bb0-93af-45b5-a341-5771bad844a1@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 12 Dec 2024, Jan Beulich wrote:
> On 12.12.2024 03:27, Stefano Stabellini wrote:
> > On Wed, 11 Dec 2024, Jan Beulich wrote:
> >> On 11.12.2024 12:02, Alessandro Zucchelli wrote:
> >>> Rule 11.1 states as following: "Conversions shall not be performed
> >>> between a pointer to a function and any other type".
> >>>
> >>> Functions "__machine_restart" and "__machine_halt" in "x86/shutdown.c"
> >>> and "halt_this_cpu" in "arm/shutdown.c" are defined as noreturn
> >>> functions and subsequently passed as parameters to function calls.
> >>> This violates the rule in Clang, where the "noreturn" attribute is
> >>> considered part of the function"s type.
> >>
> >> I'm unaware of build issues with Clang, hence can you clarify how Clang's
> >> view comes into play here? In principle various attributes ought to be
> >> part of a function's type; iirc that's also the case for gcc. Yet how
> >> that matters to Eclair is still entirely unclear to me.
> >>
> >>> By removing the "noreturn"
> >>> attribbute and replacing it with uses of the ASSERT_UNREACHABLE macro,
> >>> these violations are addressed.
> >>
> >> Papered over, I'd say. What about release builds, for example?
> >>
> >> Deleting the attribute also has a clear downside documentation-wise. If
> >> we really mean to remove them from what the compiler gets to see, I think
> >> we ought to still retain them in commented-out shape.
> > 
> > Another option would be to #define noreturn to nothing for ECLAIR builds ?
> 
> That again would feel like papering over things. Plus I don't know if that's
> an option at all.

What is "papering over" and what is a "nice solution" is often up to the
personal opinions.

>From my point of view, Alessandro's patch doesn't make the code worse.
The ASSERT_UNREACHABLE solution is OK. I do agree with you that it
should not be required for us to remove "noreturn", but I don't think we
have used it consistently anyway across the Xen codebase.
ASSERT_UNREACHABLE is also a form of documentation that the function
does not return.

In conclusion, I think all three options are acceptable:
1) this patch as is
2) this patch plus /* noreturn */ as a comment
3) #define noreturn to nothing just for ECLAIR builds

I don't mind either way, maybe option 2) is the best compromise.


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 00:55:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 00:55:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856397.1269025 (Exim 4.92)
	(envelope-from )
	id 1tLtxe-0002OO-7t; Fri, 13 Dec 2024 00:55:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856397.1269025; Fri, 13 Dec 2024 00:55: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 1tLtxe-0002OH-5D; Fri, 13 Dec 2024 00:55:18 +0000
Received: by outflank-mailman (input) for mailman id 856397;
 Fri, 13 Dec 2024 00: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 1tLtxc-0002K4-R3
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 00:55:16 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e9fd6d5c-b8ec-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 01:55:16 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id E138B5C0391;
 Fri, 13 Dec 2024 00:54:31 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 16514C4CED4;
 Fri, 13 Dec 2024 00:55:12 +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: e9fd6d5c-b8ec-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1734051314;
	bh=OTFg+UYe06c8WEhbKmCTFULMPgpPXAcShiclVdaTYC0=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=N068kFzMuvlk7/NaECFZMm9jydr548ID+mUkybnuTDXILSXQ0EstiowfTl/96FHhy
	 7/joQ1dlNkPB9BoEUvyJ5/uKfCnHddqoX7sxYsBAtAKPzOydOjZ7LXVGorZ8ejHPYG
	 XMtuOHKiQVH+B3LsqsZOAgsKtEmXW+xFe5Ay5uqO9fmflXTNbP2Jgjg6/2aU10DUKh
	 FNODVBwYZsI6kR5fjoeyFEEpxIJLmY+xAB70Ps2FlrsvT8vGZK6ZlEc/C7Mfje0PMU
	 cbEpaRwBthF7UC0XerRzeO7ZomQa5rM8eS8D+nYz9HCfSestRNZJmEQVb+O2tTpBOW
	 BBj07SzXM8OFQ==
Date: Thu, 12 Dec 2024 16:55:11 -0800 (PST)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: Stefano Stabellini , 
    Alessandro Zucchelli , 
    consulting@bugseng.com, Andrew Cooper , 
    Julien Grall , xen-devel@lists.xenproject.org
Subject: Re: [PATCH] misra: add deviation for MISRA C Rule R11.1.
In-Reply-To: <032d2e7b-7828-4a7f-a2d2-c2df46831507@suse.com>
Message-ID: 
References: <8db58416ce215a3c5fdba8074dc21f32116e8a41.1733915076.git.alessandro.zucchelli@bugseng.com>  
 <032d2e7b-7828-4a7f-a2d2-c2df46831507@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 12 Dec 2024, Jan Beulich wrote:
> On 12.12.2024 03:29, Stefano Stabellini wrote:
> > On Wed, 11 Dec 2024, Jan Beulich wrote:
> >> On 11.12.2024 12:05, Alessandro Zucchelli wrote:
> >>> Rule 11.1 states as following: "Conversions shall not be performed
> >>> between a pointer to a function and any other type".
> >>>
> >>> In "xen/common/bug.c", in order to get additional debug information,
> >>> pointer "bug_fn_t *fn" in the data section is converted to a function
> >>> pointer, which is then used to get such information.
> >>
> >> If the pointer converted pointed into the data section, it would fault
> >> upon being used to call what it points to, for the lack of execute
> >> permissions there.
> >>
> >> The change itself looks okay to me, but the description imo needs
> >> updating, to be as precise as possible.
> > 
> > 
> > What about:
> > 
> > In "xen/common/bug.c", in order to get additional debug information,
> > pointer "bug_fn_t *fn" is converted to a function pointer, which is then
> > used to get such information.
> > 
> > ?
> 
> This may do; I, however, was rather hoping for the description to be
> extended rather than shrunk. E.g. '..., pointer "bug_fn_t *fn", obtained
> by arithmetic on a pointer originating in the data section, is converted
> to a function pointer, ...'

That's fine. 

Reviewed-by: Stefano Stabellini 

If you feel like fixing it on commit, please go ahead.


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 01:03:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 01:03:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856410.1269035 (Exim 4.92)
	(envelope-from )
	id 1tLu5b-00040p-WB; Fri, 13 Dec 2024 01:03:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856410.1269035; Fri, 13 Dec 2024 01:03:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLu5b-00040i-TC; Fri, 13 Dec 2024 01:03:31 +0000
Received: by outflank-mailman (input) for mailman id 856410;
 Fri, 13 Dec 2024 01:03: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 1tLu5b-0003yQ-3o
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 01:03:31 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0fcdfc7f-b8ee-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 02:03:28 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 04BA05C6837;
 Fri, 13 Dec 2024 01:02:45 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 329D6C4CECE;
 Fri, 13 Dec 2024 01:03:26 +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: 0fcdfc7f-b8ee-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1734051807;
	bh=3xPTfmKW4cdEXh1DvWzkX62caVcxgnWWlm2oAQ6TZLg=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=Ak9DOEZhU6epsRWlcW9d2T9yahtHl0rUhpXk3kTIrfhKFT5ccuRiKHbOW5sPSeHMY
	 Hc9d1Ql1FlW9RetF0EJAdQXNfSMOyjERAXbbN99eCoHqaYNOrkvsfj3q5BXY4j7kHr
	 WiZj7nAmu9MBgqV3DPyQARSKJl61n+7tKi6W7gr7O0FTbrrsLoTprelT4oZNkJEo8A
	 3dTC8V44oFznZX7o2sM0mV74wmyU4W93RCXZWZfwSpuZGX+D+Pn/ABxp5jla1wOkRa
	 ZSt+AKV8zNeQeXSmiUg4+bs/MhAa2H8JtPod7HVO4+boc7Bl08Mync19hiGeVX2AFn
	 nXFk4KFfL4a2g==
Date: Thu, 12 Dec 2024 17:03:24 -0800 (PST)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , dmukhin@ford.com, 
    xen-devel@lists.xenproject.org, Andrew Cooper , 
    Julien Grall , Stefano Stabellini 
Subject: Re: [PATCH v2 16/35] xen/console: introduce printk_common()
In-Reply-To: <9dad24ea-178f-48c8-a93b-5823c44b56ee@suse.com>
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-16-e9aa923127eb@ford.com>  <8e5ce2dd-f888-42a3-937f-98ed1269c66c@suse.com> 
 <9dad24ea-178f-48c8-a93b-5823c44b56ee@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1813960475-1734051411=:463523"
Content-ID: 

  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-1813960475-1734051411=:463523
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Thu, 12 Dec 2024, Jan Beulich wrote:
> On 12.12.2024 13:15, Roger Pau Monné wrote:
> > On Thu, Dec 12, 2024 at 12:57:25PM +0100, Jan Beulich wrote:
> >> On 12.12.2024 10:14, Roger Pau Monné wrote:
> >>> On Thu, Dec 05, 2024 at 08:41:46PM -0800, Denis Mukhin via B4 Relay wrote:
> >>>> From: Denis Mukhin 
> >>>>
> >>>> Introduce new printk() variant for convenient printouts which skip '(XEN)'
> >>>> prefix on xen console. This is needed for the case when physical console is
> >>>> owned by a domain w/ in-hypervisor UART emulation enabled.
> >>>
> >>> IIRC the ns8250 can only send or receive one byte (character) at a
> >>> time, so you should likely put that on the console as soon as it's
> >>> received?
> >>>
> >>> For the hardware domain we explicitly don't buffer writes to the
> >>> console (see guest_console_write() hardware domain special handling).
> >>>
> >>> I wonder however how you deal with domains that don't have the console
> >>> focus (ie: != console_rx), as for those I think you still want to use
> >>> the (d) prefix?
> >>
> >> Imo no matter what domain has the focus, the (d) prefix should
> >> always be logged. Just to avoid possible confusion.
> > 
> > WE don't do that currently for the hardware domain, because we avoid
> > doing any kind of line processing, as characters from the hardware
> > domain are send straight to the console without waiting for the
> > newline terminator (like we do for other domains).
> 
> Right, and that's kind of special, and aiui intentionally so. These are
> the only un-prefixed lines logged.

I think we should provide a consistent behavior across architectures.
The current behavior with vpl011 and dom0less on ARM is the following:

- no prefix for Dom0 output
- DOM$NUM for DomUs when not in focus, otherwise no prefix

It is OK to change this behavior, but in that case I would ask that we
change it consistently also for ARM.


> > Are you suggesting that in case of the console input being shared
> > between multiple domains they should all be treated as plain domUs and
> > thus lines should be buffered?
> 
> No, I'm actually not suggesting anything here beyond perhaps reducing
> the scope of this series to just what the equivalent of vpl011 would be
> for the 8250 / 16550 case.

I agree with this
--8323329-1813960475-1734051411=:463523--


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 02:57:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 02:57:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856424.1269045 (Exim 4.92)
	(envelope-from )
	id 1tLvrN-0006hD-Lv; Fri, 13 Dec 2024 02:56:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856424.1269045; Fri, 13 Dec 2024 02:56: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 1tLvrN-0006h6-J9; Fri, 13 Dec 2024 02:56:57 +0000
Received: by outflank-mailman (input) for mailman id 856424;
 Fri, 13 Dec 2024 02:56: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 1tLvrM-0006gy-Ht
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 02:56:56 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20616.outbound.protection.outlook.com
 [2a01:111:f403:2407::616])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e7ef1f3b-b8fd-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 03:56:53 +0100 (CET)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by MW4PR12MB5625.namprd12.prod.outlook.com (2603:10b6:303:168::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.16; Fri, 13 Dec
 2024 02:56:49 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%3]) with mapi id 15.20.8230.010; Fri, 13 Dec 2024
 02:56: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: e7ef1f3b-b8fd-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PBdT/h7kcYcZeE+Z4oU2sWXMjEBbGtOmLypa0/3jNe46gw3SwF/9jwJOIwzLXdpGarKersPbXttzw/TXpNP27uIX3t585kZrZwnI3wULNd5SJKbmBlAHWjqf9fqqAQRXDnIrLNdjVzVLL+AWexPG6Su5pZhVpUsI5LYmIHVXvbkkDsHRtTbbZHU+O0d7V48w/9HmUJ9ZPBND/s3MSmcPKOuKQN7FSghU7LLfB32FqMR6xyYIkXX18y3GfABtL25ozi8pzMAr+SPc2qu6gkxFY2S89ply171tAw6ae/42cJ8vR0t2HTMooKBoXkQ6gy6Oh9KPuPPQHNxLD83NQZdzBA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=CKOUlPpI6dtus3JgEj5ocRUYgdhISRnrB6EbG4Md3r8=;
 b=VxIAUsjMNWFdhKm3khnnG2DZHZOXhhNh/09/yrhoQ4KAS23vjrTArq8fB7GSjX6hL9FtYRG0IEQwkti39rRubre9ebo6eeyBKurzM3x8tXHV3+zV+GsubLfTmrj2vlXBuYoYjuaGz4mX7suAv9T3NxyZjOK/Vf59xY0my8SXnl63mEUBQ40bpQXyJ6+GQSQp0fOlsZlVFVzZq2ngVHTduMw6sfrBeDLxWzRXlrYL82kgrtstWh8WWVJ+S06Hrkg5CgtgRv7rEn36pQwcGUn94OLhmGwiux9WZxCKAjZGbGEGzQ27wN7mocfTqAtcv0hDaKUEUz6PmndeuPSPZt2HRQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=CKOUlPpI6dtus3JgEj5ocRUYgdhISRnrB6EbG4Md3r8=;
 b=3gcPtbfae7vXVPP+CnNvjE7CuEYWqIR611BXdtamUUJEAYvLyqdyef1Eh5vyEv/Kr7vZKh/4LLL3p5HlP0AHCxJ5ivqbPqdEVFzzCM2IMhLWL+3OAaPqoEJ7iLXmm1+s7j5fmVPIZfAwf0HyW7gzLRmcdsnnSXlHGMu+1nE8Y9o=
From: "Chen, Jiqian" 
To: Anthony PERARD 
CC: "Hildebrand, Stewart" , Stefano Stabellini
	, Paul Durrant , "Edgar E . Iglesias"
	, "Michael S. Tsirkin" , Marcel
 Apfelbaum , "qemu-devel@nongnu.org"
	, "xen-devel@lists.xenproject.org"
	, "Huang, Ray" , "Chen,
 Jiqian" 
Subject: Re: [QEMU PATCH v10] xen/passthrough: use gsi to map pirq when dom0
 is PVH
Thread-Topic: [QEMU PATCH v10] xen/passthrough: use gsi to map pirq when dom0
 is PVH
Thread-Index: AQHbMBN9zgKXu6QHp0mudGAMtCr+w7K9RysAgCKFMICAAyspgIABQ32A
Date: Fri, 13 Dec 2024 02:56:49 +0000
Message-ID:
 
References: <20241106061418.3655304-1-Jiqian.Chen@amd.com>
 
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8230.010)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|MW4PR12MB5625:EE_
x-ms-office365-filtering-correlation-id: d170640f-e606-4135-805d-08dd1b21c9f5
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?dFpRYThrUmZyajJYOUdLQmhqMW9wcUZqZEpmZE5mVjRkMGpyOTNtZjkvQUVY?=
 =?utf-8?B?aHR0Y1BvQmpUeVZnUmRzUngwbjN1TVc5cG9DWWJFSGJjVDliZURGV0hHc1JT?=
 =?utf-8?B?RWVRdzB5Syt0dmFtRTFpelRWQjRvbHBVWnB1bjIycEhOZU01cm9UaUl1Rk12?=
 =?utf-8?B?M1d1c1dkWlMwZGoyRUpSckkxMFU2aW13NHpOR0Q2WU9mQzBkYTRBNTRiSDV1?=
 =?utf-8?B?aHFOWVM0aTVVSGNyemZtVUJUaGVjcEU0YTJ0cjlZTVVYOFBNT0FmY0pMOGZZ?=
 =?utf-8?B?UWFZWklMeW1RbmJDU0YwVEJSMDhBUWdzZ0xUN21pRnpCWUZnaDAwM1RYTDA1?=
 =?utf-8?B?Q1ptdmhoWmE3T01zejFFb014TGxlT3BzTEw2Tm9qMTMzbVpVb3BnMXBJYlFE?=
 =?utf-8?B?T2JrbElqLzhUL0ZyeXlrVit1ZFk1SmRUODJQTW5kK1R3MmNHKzd5aE9xaXE3?=
 =?utf-8?B?YmwrdStwN3JiN1dQSHgwY0ZzVlUyWmlOVnoxQWpnS2hDVjhENE9oTXFiaWVH?=
 =?utf-8?B?QkUwNUE1L05TMnpleTl5MlVjWldjVEhudG14Zk5PaGtuTDN6MzY1NmozSEly?=
 =?utf-8?B?REM4clR3RlJmNlBNaFB5cDQyMWw5bWF5blczb05rUzlYWTVHS0p6TnpJUFUr?=
 =?utf-8?B?ei9xdHZVcDBSdHdwQ2lsVFJoMUxJdjlGZXFSeUYwdk5FbExGNTdUMDZUeVUv?=
 =?utf-8?B?OHhsZmtBNk1BbGlIVC9WcDZwRkZFTzdrbklGOFVSRXM5YjVSZzRINUFHbzZG?=
 =?utf-8?B?eUVaaVI2R3VKdVVFbHRaaWtrejcwbUYveXFuN2lWMDdHSnhoWTJqK3dGWi9p?=
 =?utf-8?B?ajYvMm8rbytTODN4MVF6RjZmZWE0cUdFL3NOcmozNVlBUGNCYjVTTmV0QU1m?=
 =?utf-8?B?SzEzWnBVMDVxOWQwNE92eW5aM3U4MkdyR04zbmI1MG9HOHlSNTFWUFIvSzNl?=
 =?utf-8?B?U2dOSTZIOXREOG5kem1hblpSYXpEU0pnazFoLzV3MlY5NlBLaUNOd3BzSk1m?=
 =?utf-8?B?L2dkYmErRzBWaU9QQkZuV0RpdXQxWTA1UGtLcURMK3NQdXlobzVQQ1Uxd0cx?=
 =?utf-8?B?QTh1OHVXOFhWd0NhMndMbTduVTlZWkJ2L0VLdGlzYnhKRzF2cUEwbGRQSmNn?=
 =?utf-8?B?ZldJSVgxTllpRDJib3F0Skx4VndqZFFkend2MzBjRUxZa1FEYnhYQ0hiOFA0?=
 =?utf-8?B?ZW96OUpPRWZVWW5HUnlmRnJ0OW5rVko5U3Z4eXhiWWh2ZGRFSFFyTGlmZDM0?=
 =?utf-8?B?TmNoM3B3eVBGVy9EdjVkclR1WmhHbTBQVjZjRStiYkxoOTBXWWJFWHI5RkN2?=
 =?utf-8?B?cGMrQ0NiSmgzbW5GbnZzVzNLeHVqK1VpY0hENTJoaVNMMGlQc2NCNXExYnhh?=
 =?utf-8?B?ZGU3VjRSem5QWjltcmpNTDI4c2FuUmFJK0hFbFdXNTdFZ0RwOENqZHVPVkt2?=
 =?utf-8?B?MjAwc2lnQjhSOGZrQmZCNDFIaU1Odkw2YkZPMk9qMXdPMnRlOUgyQloyV2NU?=
 =?utf-8?B?dlNJbkdsKzNFOGxWRk44cG01dVNNRTdSa2x3dkdKZzFCdWFYNTlBTklQVWhV?=
 =?utf-8?B?SmhFWG1uU0NNTm1GektPYnFVT0lEQXovVktQMEZ4WmdHeFpJTnhHYjNWKzJh?=
 =?utf-8?B?WDNGVE94RllWUUQwZVlGQ3huZFl4K3grMFVaVnlUY0FwRFFNNERHcTZ0bkht?=
 =?utf-8?B?WlVvWU5zUEY3cWZDSnlRQU9MalVBYnptcVlpMFFtUG5KS04rT09IV0ZQRGtQ?=
 =?utf-8?B?Vk9ja3JEbVJGRWJCTVlWSkVUb0ZFYUxzakN3NHBZUHltbFJYMm5OKzVNRVhR?=
 =?utf-8?B?TC9Lc25uQTdzSCtMQzVIQVFvNHhYVCtNUk8xRmhrUCtUTzcrdzh4enVqRTc1?=
 =?utf-8?B?MjhCMkN0SEJMK3J2OE1PNGM2eUxqaTJiYkVRaVVMNFYyaFE9PQ==?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?UUJYOGdIQmRNRFBhTGJTYUd2cHZKMVl1QVRmcm9BRG5tLzEvTXQvSVNIcXUv?=
 =?utf-8?B?bkhJdStheElaWk9uWWYycUpsTGhzTFVyTld0dU5CZm45aFV4MlVtQW03djF1?=
 =?utf-8?B?azJIa2ltNGtZbkVKZW5rcTNEYmlLSDA4N0hwWVgyZ0QrZWNtVFpMU2s2RVRm?=
 =?utf-8?B?Y3pGZjM1d1pYR2JLb2lEZ3ErK082MTVlNFJwUzYzMjY4aFlLWlVFUzJIOEZm?=
 =?utf-8?B?Zmg2OEtzdnJOL0FkZTRSVnF4RGJTcFRGTEdZVlpvZmRtVVZFc1J1b2pMTHhP?=
 =?utf-8?B?ZW1OY2NsQ0c5dEpjMnpPNDQ3UURoYzNsYWpyY2Erd1R2eGQ2SW8zcVZNUXg5?=
 =?utf-8?B?ZmNZWjl0bXgySkFXa1dSMWlRaU13Q3RiMkJsNXJ1YnFmTEZpb1N1RjZoZWRo?=
 =?utf-8?B?QTZNUVU2NUF6VkoyZkpYZENqZmk3a0gzM25teVJFKzRDbFdjNmtMTU9qS0dx?=
 =?utf-8?B?eUpmK2s4Mlc5TVpWSktpanZZdkxjZW5vcGc3aXl1cHIzV3BEbnNrRU5pd1I3?=
 =?utf-8?B?YWNROFdUM3UvcHo5OHN0NlU5L2ZzakswZWJnTTZIZ3A2NWJxTDhLR3hocUF3?=
 =?utf-8?B?YytNV084MjNhY3djaUNISzVmbWNKMGV0YkYyRkpaUm9oMlZuY00xQTMyZVFL?=
 =?utf-8?B?MEdHMnlkTzBmRG1wOHNVRUw4MVp5R0d3WnIvakxNNzVTNjNjVHNPVFlpV3Nv?=
 =?utf-8?B?UDVPMm00bXNYS0M5bTcwa1lIc3RpRU1LaVlBeUp1Z20rSnJmcExnNTlwbmtG?=
 =?utf-8?B?NWh6SzRtbStPS3o5NWs1TzZzOW9WOFRUNnBqTG9XTng4MW5oY0t5RWlERkxB?=
 =?utf-8?B?N0MyWGN1bkdJdkYzdkpmMFlYUmNYNTJtOUovdkRvK3dvK2lUamxnZE5KUGti?=
 =?utf-8?B?bU92OFpJKythNWUzb2NDQ1NqQXJyREcrRjF6THVDV2NQM3BJczBnN2FMTXpi?=
 =?utf-8?B?VzZhakxiVEYyaEorcGFObEJOL0k4eXhsRUcvOVFsNGNWWDhIN0NGOFNRZXNN?=
 =?utf-8?B?UFV4STZ4RzArU1FSeWEzaTIyU2x5QmlLUzZ4cmRCclpudGhhNTR6V084aVQ3?=
 =?utf-8?B?MEFtNlVkbHhWK3VXN09FZWE0VjY0UmFKekdSMEpGQXErZ21oYXFYbDZNZ2lt?=
 =?utf-8?B?eTkva0ZWaDc3LzZsd3FIcUVsdldtazVRQi8wSVhCdWpLMWhXSnNuRHlzcFFO?=
 =?utf-8?B?cHhuYm1ad3h4NHgwdTFRb1dqaUJDSWZ3TUZUSVBYcXhXSm5XaFhmUmlJZlhh?=
 =?utf-8?B?NjFEYkdGdFFURG91UEtyRVlBRWhCbVg3Wjc4dUk4OVBScGNUV3FhWkdDeVlB?=
 =?utf-8?B?d1pKcDMzTlVEY0xmaWR5cXZGbGFFVDR6cVBhMkpXcW91Z2VLaVdwMUk3ZGl6?=
 =?utf-8?B?VlVPK3Z3K3JzMDNVU2ZBUHBWYldYY2syWStjU0JGYUllQ1lWRkhVbjE5WFI2?=
 =?utf-8?B?OC9ZMDYrRXVhN2RncmF6MmdyMVlUUEk1dTVFVUdFenV4SFpvL3lTWFJtc0Y3?=
 =?utf-8?B?bVB6ODRZTDJPUzhXUzZkenJYeGY2Qk0wOTVhdW8yWEIvWWZjb0M4aHpuUkdY?=
 =?utf-8?B?Wm80VE5xUnRqT0sxSFBQK3N1djVHM3Q5WGxrMVJ1enZNUEVDRm5VLyszV3lU?=
 =?utf-8?B?cHkwcHc0SnJncEhKQ1pZMHR6bGxEUmlFSU1tclpYY0UzeVNSL2RtVzVxTlBY?=
 =?utf-8?B?S2huZEFJd1RVT25TNzdPSHVYSFQwSE9rN1ZZWSt0WU9mY0ZmLzN0SUcvcGhv?=
 =?utf-8?B?NHFZMlJFS1FxOGtxU3E5czdFazB6b291UThBSC96WnlVM2xYamcrek1KczJ1?=
 =?utf-8?B?TzZLeEdlWkVpUkF2T3dDVzlrRTBpeS8vQ1dZNVFsdzJnblJmVXBVMk5RcmZ6?=
 =?utf-8?B?YXc0Z3JsVXdlUklBdFpYcm9pOTRJeUhzNjlJU0ZkNHFpYm5jbms3YmUwSXRU?=
 =?utf-8?B?SnpvQm5rNXJIamF2YjZYM3pKZGxtQ2JzMUZCejREdExHTGk0MktmV3hyOHF0?=
 =?utf-8?B?QUZISTZuTU83eENUVUtIKys1bU93V0pFRCsvSVhpYTNTdVdTZVh1UDYrMDJ6?=
 =?utf-8?B?WG9PRTdVdmw0aDMreFVoeWJSS1h2ZnF4b3lkM0tJTnpHNGdPWjI5VGpud1p1?=
 =?utf-8?Q?kcOQ=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <80F959B7836FD84FB49A3574C1FED9B6@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d170640f-e606-4135-805d-08dd1b21c9f5
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2024 02:56:49.2126
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Cu93TefQWovaLMoVT5TC3UN1aN1GIV4Nv+yCWpb8xin/ji25psBoZE1FaxZUozOrCJXT9nAgCyU/TqmdIzw/Fg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB5625

T24gMjAyNC8xMi8xMiAyMzozOCwgQW50aG9ueSBQRVJBUkQgd3JvdGU6DQo+IE9uIFR1ZSwgRGVj
IDEwLCAyMDI0IGF0IDA3OjE3OjMwQU0gKzAwMDAsIENoZW4sIEppcWlhbiB3cm90ZToNCj4+IE9u
IDIwMjQvMTEvMTkgMDA6MDUsIEFudGhvbnkgUEVSQVJEIHdyb3RlOg0KPj4+IE9uIFdlZCwgTm92
IDA2LCAyMDI0IGF0IDAyOjE0OjE4UE0gKzA4MDAsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4+PiBJ
biBQVkggZG9tMCwgd2hlbiBwYXNzdGhyb3VnaCBhIGRldmljZSB0byBkb21VLCBRRU1VIGNvZGUN
Cj4+Pj4geGVuX3B0X3JlYWxpemUtPnhjX3BoeXNkZXZfbWFwX3BpcnEgd2FudHMgdG8gdXNlIGdz
aSwgYnV0IGluIGN1cnJlbnQgY29kZXMNCj4+Pj4gdGhlIGdzaSBudW1iZXIgaXMgZ290IGZyb20g
ZmlsZSAvc3lzL2J1cy9wY2kvZGV2aWNlcy88c2JkZj4vaXJxLCB0aGF0IGlzDQo+Pj4+IHdyb25n
LCBiZWNhdXNlIGlycSBpcyBub3QgZXF1YWwgd2l0aCBnc2ksIHRoZXkgYXJlIGluIGRpZmZlcmVu
dCBzcGFjZXMsIHNvDQo+Pj4+IHBpcnEgbWFwcGluZyBmYWlscy4NCj4+Pj4NCj4+Pj4gVG8gc29s
dmUgYWJvdmUgcHJvYmxlbSwgdXNlIG5ldyBpbnRlcmZhY2Ugb2YgWGVuLCB4Y19wY2lkZXZfZ2V0
X2dzaSB0byBnZXQNCj4+Pj4gZ3NpIGFuZCB1c2UgeGNfcGh5c2Rldl9tYXBfcGlycV9nc2kgdG8g
bWFwIHBpcnEgd2hlbiBkb20wIGlzIFBWSC4NCj4+Pj4NCj4+Pj4gU2lnbmVkLW9mZi1ieTogSmlx
aWFuIENoZW4gPEppcWlhbi5DaGVuQGFtZC5jb20+DQo+Pj4+IFNpZ25lZC1vZmYtYnk6IEh1YW5n
IFJ1aSA8cmF5Lmh1YW5nQGFtZC5jb20+DQo+Pj4+IFNpZ25lZC1vZmYtYnk6IEppcWlhbiBDaGVu
IDxKaXFpYW4uQ2hlbkBhbWQuY29tPg0KPj4+DQo+Pj4gQWNrZWQtYnk6IEFudGhvbnkgUEVSQVJE
IDxhbnRob255QHhlbnByb2plY3Qub3JnPg0KPj4+DQo+Pj4gQnV0LCB0aGlzIGZvbGxvd2luZyBj
aGFuZ2UgcHJvYmFibHkgbmVlZHMgYW4gYWNrIGZyb20gUENJIG1haW50YW5lcnMsDQo+Pj4gQ0Nl
ZC4NCj4+IEFzIFBDSSBtYWludGFpbmVycyBkaWRuJ3QgcmVzcG9uc2UgZm9yIHdlZWtzLA0KPj4g
Y2FuIEkganVzdCBtb3ZlIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBtYWNybyBiYWNrIHRvIHhlbl9w
dC5jIGZpbGUgPw0KPiANCj4gTm8sIHRoYXQncyBmaW5lLiBJIHNob3VsZCBiZSBhYmxlIHRvIHNl
bmQgYSBwdWxsLXJlcXVlc3Qgd2l0aCB0aGlzDQo+IGNoYW5nZSB3aXRob3V0IHRvbyBtdWNoIHRy
b3VibGUuDQo+IA0KVGhhbmsgeW91IHZlcnkgbXVjaCENCg0KPiBDaGVlcnMsDQo+IA0KDQotLSAN
CkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0K


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 05:26:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 05:26:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856447.1269055 (Exim 4.92)
	(envelope-from )
	id 1tLyBn-0005KS-63; Fri, 13 Dec 2024 05:26:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856447.1269055; Fri, 13 Dec 2024 05:26: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 1tLyBn-0005KL-2G; Fri, 13 Dec 2024 05:26:11 +0000
Received: by outflank-mailman (input) for mailman id 856447;
 Fri, 13 Dec 2024 05:26: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 1tLyBl-0005KF-Mb
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 05:26:09 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bf0ebc94-b912-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 06:26:04 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 6B4C1A42515;
 Fri, 13 Dec 2024 05:24:11 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D513C4CED1;
 Fri, 13 Dec 2024 05:25:49 +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: bf0ebc94-b912-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1734067562;
	bh=M2xdmdLNhUnONPFOKg4DD+NknFYDEaK+x9KyPHrv24s=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=bw4/mjm10HI4gIYEq6PcUyF1AyHtdTx8xY1u9mQ/MqJN77zbADAxHBaxyRlLd3fvm
	 K+xp87WmOhOZL0i+Bq0ipg5X8v20dbpQflvkGqWjrmRLY/0GuREkoyHJNVYE+cNf5x
	 z8LCuZGHvDXUpEOFv59Bb7IqvPJLfr+Ey53P+W4LJrWqp6nhL8os12GgjvLuqPfWM7
	 tQzQgeo6YclbvdVoVzle3X83Llu3G9oxPWspWAnjZkdc3+GZOJaUxSQ04u5mGgaPm3
	 thWesm1LM0XsGyHp4VpoNWDNgdZGRIRa8iRReDoOdNpvWyxV8vC93Zm54QQh6yd+QZ
	 BUiwJG/w6t0xg==
Date: Fri, 13 Dec 2024 06:25:47 +0100
From: Niklas Cassel 
To: Bjorn Helgaas 
Cc: Philipp Stanner ,
	amien Le Moal ,
	Basavaraj Natikar ,
	Jiri Kosina ,
	Benjamin Tissoires ,
	Arnd Bergmann ,
	Greg Kroah-Hartman ,
	Alex Dubov ,
	Sudarsana Kalluru ,
	Manish Chopra ,
	Andrew Lunn ,
	"David S. Miller" ,
	Eric Dumazet ,
	Jakub Kicinski , Paolo Abeni ,
	Rasesh Mody , GR-Linux-NIC-Dev@marvell.com,
	Igor Mitsyanko ,
	Sergey Matyukevich ,
	Kalle Valo , Sanjay R Mehta ,
	Shyam Sundar S K ,
	Jon Mason , Dave Jiang ,
	Allen Hubbe ,
	Bjorn Helgaas ,
	Alex Williamson ,
	Juergen Gross ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Mario Limonciello ,
	Chen Ni , Ricky Wu ,
	Al Viro , Breno Leitao ,
	Thomas Gleixner ,
	Kevin Tian ,
	Andy Shevchenko ,
	Mostafa Saleh , Jason Gunthorpe ,
	Yi Liu , Kunwu Chan ,
	Dan Carpenter ,
	"Dr. David Alan Gilbert" ,
	Ankit Agrawal ,
	Reinette Chatre ,
	Eric Auger , Ye Bin ,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-input@vger.kernel.org, netdev@vger.kernel.org,
	linux-wireless@vger.kernel.org, ntb@lists.linux.dev,
	linux-pci@vger.kernel.org, kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 00/11] Remove implicit devres from pci_intx()
Message-ID: 
References: <20241209130632.132074-2-pstanner@redhat.com>
 <20241212192118.GA3359591@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20241212192118.GA3359591@bhelgaas>

On Thu, Dec 12, 2024 at 01:21:18PM -0600, Bjorn Helgaas wrote:
> On Mon, Dec 09, 2024 at 02:06:22PM +0100, Philipp Stanner wrote:
> 
> Applied the ones with maintainer acks to pci/devres for v6.14, thanks!

I don't see this on:
https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/

Did you perhaps forget to push?


Kind regards,
Niklas


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 05:43:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 05:43:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856457.1269065 (Exim 4.92)
	(envelope-from )
	id 1tLySI-0008Sr-Id; Fri, 13 Dec 2024 05:43:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856457.1269065; Fri, 13 Dec 2024 05:43:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tLySI-0008Sk-Ed; Fri, 13 Dec 2024 05:43:14 +0000
Received: by outflank-mailman (input) for mailman id 856457;
 Fri, 13 Dec 2024 05:43: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 1tLySH-0008Se-8f
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 05:43:13 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on2061e.outbound.protection.outlook.com
 [2a01:111:f403:2407::61e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 239f3959-b915-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 06:43:11 +0100 (CET)
Received: from PH8PR05CA0016.namprd05.prod.outlook.com (2603:10b6:510:2cc::17)
 by CYYPR12MB8990.namprd12.prod.outlook.com (2603:10b6:930:ba::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.17; Fri, 13 Dec
 2024 05:43:04 +0000
Received: from CY4PEPF0000E9D0.namprd03.prod.outlook.com
 (2603:10b6:510:2cc:cafe::80) by PH8PR05CA0016.outlook.office365.com
 (2603:10b6:510:2cc::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.13 via Frontend Transport; Fri,
 13 Dec 2024 05:43:04 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000E9D0.mail.protection.outlook.com (10.167.241.135) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Fri, 13 Dec 2024 05:43:03 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) 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; Thu, 12 Dec
 2024 23:43:00 -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: 239f3959-b915-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=RT0zBlpkv/Ja4EEh1fgD73Sem8iaUE6C+2HhxEASr6oJsyk9D4qKgwcbvmONigy9wHDBs4NEbA4PDit2lAec4AQ+nEULYSw3/kJZWR6yikcT8vCIHBbm0cFQRpHaHyrM8/b+68t7IphxenxQKXIcAV8d0j26e95db02ykYem3zT4lF387H5SgVphXAxt8X7EiJ1knAAPVa73EpSvd8Ye1Wxkzogw0ZXZRriqWI9smtTi5ctidxuIlH9DimxjqId6/U6l7wNYhgl2NN5uXEt+cwkitR1t5A17FrHzO24Wq+B3Jddw7VSZQt+/UK/y33c332cj9z+Kpl99Z64rX82B8A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ojxF/E4gKWp1SAYZJFlXQKW+DKzK4dAdOy+EuuUsY/k=;
 b=RlKCX89zQZXjoazPuTCpNRMjqGYpCvKleyMHiqLXI1WRkelevcvqekjoCyZy1iUsOgUD2LNx38UlCa0GTZBKhRmGvUjkixjZh/ucew9+LnGd64qKT299PDvYFFhuueM1wVBWX09mmNydAv+dO5ZZgiCZS71npiAEKcy1CLpKVWjvQnxNjxyDg2tRj29GYLOlq/uTOJqMkdowWnQVP97SfDrXiZ9n9jQlm9QHL30DZ62xIw8BmL6ZPkL4uDpwxQX04bILRiDVBR1RtdIgydGJ4YYl9k3odkSvmn2lF4fwSy+wslcuoasYxCXOU1gzYWePOe2dYreXrDPQzD3GiTx85g==
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=ojxF/E4gKWp1SAYZJFlXQKW+DKzK4dAdOy+EuuUsY/k=;
 b=J/ehN3fX9YcEphIbUc2VSVJ/NdUyGxfq2nXGuU5EsePqqwgGC3iejZ5G2Me5nRtZjrZRG+CsphEGXBB4W5CnAqzFgY9OB6mfrtBC11YYPmm58TYhKCC4pjvjSJSUnU47y7wXesPQ0FxPCCTAKTHvtoSbwiPXp664MoHUviLiksg=
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=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Andrew Cooper
	, Jan Beulich , Julien Grall
	, Stefano Stabellini , Huang Rui
	, Jiqian Chen 
Subject: [PATCH v3] vpci: Add resizable bar support
Date: Fri, 13 Dec 2024 13:42:32 +0800
Message-ID: <20241213054232.2638640-1-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D0:EE_|CYYPR12MB8990:EE_
X-MS-Office365-Filtering-Correlation-Id: 012e6529-875a-4713-165a-08dd1b390323
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?b5sXt7a0CMJM1305g94E/4pO6/utwWeHoxLTjkjxfVCUtdOsBxfjhJl208P5?=
 =?us-ascii?Q?v644KjC2eFHteEcZQBcWgxKocyF/rEMo6mw4m55IkW1pXyY2wmzVI1aOGQR/?=
 =?us-ascii?Q?X+5nSwfs8hYMU+NYgHpBXwCYLz3K8U0oBt0dCafWjhLzu+fLIo380/jgwFrV?=
 =?us-ascii?Q?YULPfvMax58uTV70Y+UdEXxqeaHPX5HtHS41PTx7ADTszTNoe0qOhnU7Va4D?=
 =?us-ascii?Q?ILfil2UtsP/eMrLq7ivZSUlzzb0LwudEx/SfGGpF3OsVlu/vr2L5b5cMSFgC?=
 =?us-ascii?Q?W74Fml4AM4/cV8cjWMo3pMzNzohYjhlDMVrnq8GxVeWICf+LPHSVnIvhxbfc?=
 =?us-ascii?Q?E//oge3VzyQWdqrU3a305nWuYcQO+wshbK7X6tw2G3fuW+zsNgbtHIBLdRIf?=
 =?us-ascii?Q?9uOfl5oR8UvmbBMYoPNnGHLb9Kf8FyCaR3lWJ/pHsJxXbjvXDNRvASCnx7zJ?=
 =?us-ascii?Q?qIjT0lUtinDsTVtH4lKFU9qES/ZR4T27msvPdgWQISsqzVKVeci+bq3FkCLA?=
 =?us-ascii?Q?7bwluDSo3s+H6CruGsIWBZDi4gQvcbtWTaNjWMcGbXEOa7IDLtGU6YBZmZAx?=
 =?us-ascii?Q?VQojM8du03sVO/Dhn4+VC+nfel1/Knk4T9v+AIP4KgvNlH/kAgu4gw+KUrTe?=
 =?us-ascii?Q?i7BnU25oobfy3RHXvLJOjWyKkUj07arIe4vA172/XnQy/V9kjkxkC02UMGzG?=
 =?us-ascii?Q?eJpWqrt/aTwHu5fQhb3uMOriZsMWNbq+40uZryTOqDhdMYB/2UGOrKQfOSQC?=
 =?us-ascii?Q?BPDCslP7FeVWtLqZC+JyP/qD2RfaZ4J+ri4VmtiAk0v3VUt+gTz2guwr+qRA?=
 =?us-ascii?Q?ZnaLGsG0gUfOVw004lPJJ2LAyUi1bwt6KOlN6T7+krfXB/83hLx2aFGQNl02?=
 =?us-ascii?Q?MUo0DQo3eVsT0XWRId6NtRzQZmyu9j71EYdwsyLk1XFI98btP/gb5UGnJLHV?=
 =?us-ascii?Q?Lq1VQOv3rePfI7f6BGncIG/jnsuNh/VqS3N0UZH5T0oqlp0zAD0Th4k320wT?=
 =?us-ascii?Q?yHVSOMwApIZ06zUr2DWsoIPvZAoUVA868sQtqLTUD7dBcIWJ8e7mDOEcO5Ny?=
 =?us-ascii?Q?wm16pAAFIE0PtO6zY9aNRjXZhNbn7jAh9MzqFn4kt0RGKqJlAc55dl81NN+o?=
 =?us-ascii?Q?+xA7YcpiSZgitldwEsofbZggHJzkTgpnHibc9qZJ0Ys0hQweIZ1CPvTqlJsW?=
 =?us-ascii?Q?jXr70WG+WRR2fj6LAZ4eGKt6/PVyCG4/5iQnjxoLTPa2jFIC3xOB/KvZQI/Y?=
 =?us-ascii?Q?TvdQCkxLzGgLcW8oZnMzdL2HBtuKEAWvLmRJveuH9iWMg96LMfOviHEmKEb3?=
 =?us-ascii?Q?SfCIBXLMYtTR4rc7yOxVNmIAogWUvk7hs6FZLi6Q+U4ZRvFr4cGleZ8bGggq?=
 =?us-ascii?Q?KZOTZ/q0l0EsInebxa0qiXMi63auh2kpFVBF1HIMak8tI9MrlJdGtm+KgYFY?=
 =?us-ascii?Q?GkHmISMe9Rh4A2+9uLYckwYmaedCmFv9?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2024 05:43:03.4476
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 012e6529-875a-4713-165a-08dd1b390323
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000E9D0.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8990

Some devices, like discrete GPU of amd, support resizable bar
capability, but vpci of Xen doesn't support this feature, so
they fail to resize bars and then cause probing failure.

According to PCIe spec, each bar that supports resizing has
two registers, PCI_REBAR_CAP and PCI_REBAR_CTRL. So, add
handlers for them to support resizing the size of BARs.

Signed-off-by: Jiqian Chen 
---
Hi all,
v2->v3 changes:
* Used "bar->enabled" to replace "pci_conf_read16(pdev->sbdf, PCI_COMMAND) & PCI_COMMAND_MEMORY",
  and added comments why it needs this check.
* Added "!is_hardware_domain(pdev->domain)" check in init_rebar() to return EOPNOTSUPP for domUs.
* Moved BAR type and index check into init_rebar(), then only need to check once.
* Added 'U' suffix for macro PCI_REBAR_CAP_SIZES.
* Added macro PCI_REBAR_SIZE_BIAS to represent 20.

TODO: need to hide ReBar capability from hardware domain when init_rebar() fails.

Best regards,
Jiqian Chen.

v1->v2 changes:
* In rebar_ctrl_write, to check if memory decoding is enabled, and added
  some checks for the type of Bar.
* Added vpci_hw_write32 to handle PCI_REBAR_CAP's write, since there is
  no write limitation of dom0.
* And has many other minor modifications as well.
---
 xen/drivers/vpci/Makefile  |   2 +-
 xen/drivers/vpci/rebar.c   | 130 +++++++++++++++++++++++++++++++++++++
 xen/drivers/vpci/vpci.c    |   6 ++
 xen/include/xen/pci_regs.h |  13 ++++
 xen/include/xen/vpci.h     |   2 +
 5 files changed, 152 insertions(+), 1 deletion(-)
 create mode 100644 xen/drivers/vpci/rebar.c

diff --git a/xen/drivers/vpci/Makefile b/xen/drivers/vpci/Makefile
index 1a1413b93e76..a7c8a30a8956 100644
--- a/xen/drivers/vpci/Makefile
+++ b/xen/drivers/vpci/Makefile
@@ -1,2 +1,2 @@
-obj-y += vpci.o header.o
+obj-y += vpci.o header.o rebar.o
 obj-$(CONFIG_HAS_PCI_MSI) += msi.o msix.o
diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
new file mode 100644
index 000000000000..39432c3271a4
--- /dev/null
+++ b/xen/drivers/vpci/rebar.c
@@ -0,0 +1,130 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2024 Advanced Micro Devices, Inc. All Rights Reserved.
+ *
+ * Author: Jiqian Chen 
+ */
+
+#include 
+#include 
+
+static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
+                                      unsigned int reg,
+                                      uint32_t val,
+                                      void *data)
+{
+    uint64_t size;
+    struct vpci_bar *bar = data;
+
+    size = PCI_REBAR_CTRL_SIZE(val);
+    if ( bar->enabled )
+    {
+        if ( size == bar->size )
+            return;
+
+        /*
+        * Refuse to resize a BAR while memory decoding is enabled, as
+        * otherwise the size of the mapped region in the p2m would become
+        * stale with the newly set BAR size, and the position of the BAR
+        * would be reset to undefined.  Note the PCIe specification also
+        * forbids resizing a BAR with memory decoding enabled.
+        */
+        gprintk(XENLOG_ERR,
+                "%pp: refuse to resize BAR with memory decoding enabled\n",
+                &pdev->sbdf);
+        return;
+    }
+
+    if ( !((size >> PCI_REBAR_SIZE_BIAS) &
+           MASK_EXTR(pci_conf_read32(pdev->sbdf,
+                                     reg - PCI_REBAR_CTRL + PCI_REBAR_CAP),
+                                     PCI_REBAR_CAP_SIZES)) )
+        gprintk(XENLOG_WARNING,
+                "%pp: new size %#lx is not supported by hardware\n",
+                &pdev->sbdf, size);
+
+    bar->size = size;
+    bar->addr = 0;
+    bar->guest_addr = 0;
+    pci_conf_write32(pdev->sbdf, reg, val);
+}
+
+static int cf_check init_rebar(struct pci_dev *pdev)
+{
+    uint32_t ctrl;
+    unsigned int rebar_offset, nbars;
+
+    rebar_offset = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_REBAR);
+
+    if ( !rebar_offset )
+        return 0;
+
+    if ( !is_hardware_domain(pdev->domain) )
+    {
+        printk("ReBar is not supported for domUs\n");
+        return -EOPNOTSUPP;
+    }
+
+    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL);
+    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
+
+    for ( unsigned int i = 0; i < nbars; i++, rebar_offset += PCI_REBAR_CTRL )
+    {
+        int rc;
+        unsigned int index;
+        struct vpci_bar *bars = pdev->vpci->header.bars;
+
+        index = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL) &
+                PCI_REBAR_CTRL_BAR_IDX;
+
+        if ( index >= PCI_HEADER_NORMAL_NR_BARS )
+        {
+            /*
+             * TODO: for failed pathes, need to hide ReBar capability
+             * from hardware domain instead of returning an error.
+             */
+            printk("%pp: BAR number %u in REBAR_CTRL register is too big\n",
+                   &pdev->sbdf, index);
+            return -EINVAL;
+        }
+
+        if ( bars[index].type != VPCI_BAR_MEM64_LO &&
+             bars[index].type != VPCI_BAR_MEM32 )
+        {
+            printk("%pp: BAR%u is not in memory space\n", &pdev->sbdf, index);
+            return -EINVAL;
+        }
+
+        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32,
+                               rebar_offset + PCI_REBAR_CAP, 4, NULL);
+        if ( rc )
+        {
+            printk("%pp: add register for PCI_REBAR_CAP failed (rc=%d)\n",
+                   &pdev->sbdf, rc);
+            return rc;
+        }
+
+        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
+                               rebar_offset + PCI_REBAR_CTRL, 4,
+                               &bars[index]);
+        if ( rc )
+        {
+            printk("%pp: add register for PCI_REBAR_CTRL failed %d\n",
+                   &pdev->sbdf, rc);
+            return rc;
+        }
+    }
+
+    return 0;
+}
+REGISTER_VPCI_INIT(init_rebar, VPCI_PRIORITY_LOW);
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 1e6aa5d799b9..3349b98389b8 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -232,6 +232,12 @@ void cf_check vpci_hw_write16(
     pci_conf_write16(pdev->sbdf, reg, val);
 }
 
+void cf_check vpci_hw_write32(
+    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
+{
+    pci_conf_write32(pdev->sbdf, reg, val);
+}
+
 int vpci_add_register_mask(struct vpci *vpci, vpci_read_t *read_handler,
                            vpci_write_t *write_handler, unsigned int offset,
                            unsigned int size, void *data, uint32_t ro_mask,
diff --git a/xen/include/xen/pci_regs.h b/xen/include/xen/pci_regs.h
index 250ba106dbd3..c6bd3545d7a5 100644
--- a/xen/include/xen/pci_regs.h
+++ b/xen/include/xen/pci_regs.h
@@ -459,6 +459,7 @@
 #define PCI_EXT_CAP_ID_ARI	14
 #define PCI_EXT_CAP_ID_ATS	15
 #define PCI_EXT_CAP_ID_SRIOV	16
+#define PCI_EXT_CAP_ID_REBAR	21	/* Resizable BAR */
 
 /* Advanced Error Reporting */
 #define PCI_ERR_UNCOR_STATUS	4	/* Uncorrectable Error Status */
@@ -541,6 +542,18 @@
 #define  PCI_VNDR_HEADER_REV(x)	(((x) >> 16) & 0xf)
 #define  PCI_VNDR_HEADER_LEN(x)	(((x) >> 20) & 0xfff)
 
+/* Resizable BARs */
+#define PCI_REBAR_SIZE_BIAS	20
+#define PCI_REBAR_CAP		4	/* capability register */
+#define  PCI_REBAR_CAP_SIZES		0xFFFFFFF0U  /* supported BAR sizes */
+#define PCI_REBAR_CTRL		8	/* control register */
+#define  PCI_REBAR_CTRL_BAR_IDX	0x00000007  /* BAR index */
+#define  PCI_REBAR_CTRL_NBAR_MASK	0x000000E0  /* # of resizable BARs */
+#define  PCI_REBAR_CTRL_BAR_SIZE	0x00001F00  /* BAR size */
+#define  PCI_REBAR_CTRL_SIZE(v) \
+            (1UL << (MASK_EXTR(v, PCI_REBAR_CTRL_BAR_SIZE) \
+                     + PCI_REBAR_SIZE_BIAS))
+
 /*
  * Hypertransport sub capability types
  *
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index 41e7c3bc2791..72992e93cece 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -78,6 +78,8 @@ uint32_t cf_check vpci_hw_read32(
     const struct pci_dev *pdev, unsigned int reg, void *data);
 void cf_check vpci_hw_write16(
     const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data);
+void cf_check vpci_hw_write32(
+    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data);
 
 /*
  * Check for pending vPCI operations on this vcpu. Returns true if the vcpu
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 07:32:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 07:32:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856468.1269074 (Exim 4.92)
	(envelope-from )
	id 1tM0A3-0006Pf-4e; Fri, 13 Dec 2024 07:32:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856468.1269074; Fri, 13 Dec 2024 07:32:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tM0A3-0006PY-27; Fri, 13 Dec 2024 07:32:31 +0000
Received: by outflank-mailman (input) for mailman id 856468;
 Fri, 13 Dec 2024 07:32: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 1tM0A1-0006PS-K4
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 07:32:29 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 667473e2-b924-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 08:32:26 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id D9A54A41BB3;
 Fri, 13 Dec 2024 07:30:33 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74C47C4CED0;
 Fri, 13 Dec 2024 07:32:23 +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: 667473e2-b924-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1734075144;
	bh=KF2u61fFy2MhhhXHsq56NzRxS4bNBSmPrcwIzbiCk28=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=YXws51p4OlwPq738uGlipsQN5HV9ZVc0qBQtIDFJ/RVNPLGvtjmm8j7Lruy9AroPG
	 fwsqluHpE8hKxixfh9G9UkxLnr46YSpthgtDfA9vQaZk5drkqBVz90PEiil9zPChQB
	 04xHlVOMH3ZIXzCGOFptOxKKf9WCynUw3GeIuYZg=
Date: Fri, 13 Dec 2024 08:31:45 +0100
From: Greg Kroah-Hartman 
To: Bjorn Helgaas 
Cc: Philipp Stanner , Arnd Bergmann ,
	Alex Dubov , amien Le Moal ,
	Niklas Cassel ,
	Basavaraj Natikar ,
	Jiri Kosina ,
	Benjamin Tissoires ,
	Sudarsana Kalluru ,
	Manish Chopra ,
	Andrew Lunn ,
	"David S. Miller" ,
	Eric Dumazet ,
	Jakub Kicinski , Paolo Abeni ,
	Rasesh Mody , GR-Linux-NIC-Dev@marvell.com,
	Igor Mitsyanko ,
	Sergey Matyukevich ,
	Kalle Valo , Sanjay R Mehta ,
	Shyam Sundar S K ,
	Jon Mason , Dave Jiang ,
	Allen Hubbe ,
	Bjorn Helgaas ,
	Alex Williamson ,
	Juergen Gross ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Mario Limonciello ,
	Chen Ni , Ricky Wu ,
	Al Viro , Breno Leitao ,
	Thomas Gleixner ,
	Kevin Tian ,
	Andy Shevchenko ,
	Mostafa Saleh , Jason Gunthorpe ,
	Yi Liu , Kunwu Chan ,
	Dan Carpenter ,
	"Dr. David Alan Gilbert" ,
	Ankit Agrawal ,
	Reinette Chatre ,
	Eric Auger , Ye Bin ,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-input@vger.kernel.org, netdev@vger.kernel.org,
	linux-wireless@vger.kernel.org, ntb@lists.linux.dev,
	linux-pci@vger.kernel.org, kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 05/11] misc: Use never-managed version of pci_intx()
Message-ID: <2024121335-blooper-cognitive-04ec@gregkh>
References: <20241209130632.132074-7-pstanner@redhat.com>
 <20241212192637.GA3359920@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20241212192637.GA3359920@bhelgaas>

On Thu, Dec 12, 2024 at 01:26:37PM -0600, Bjorn Helgaas wrote:
> [cc->to: Arnd, Greg, Alex]
> 
> On Mon, Dec 09, 2024 at 02:06:27PM +0100, Philipp Stanner wrote:
> > pci_intx() is a hybrid function which can sometimes be managed through
> > devres. To remove this hybrid nature from pci_intx(), it is necessary to
> > port users to either an always-managed or a never-managed version.
> > 
> > cardreader/rtsx_pcr.c and tifm_7xx1.c enable their PCI-Device with
> > pci_enable_device(). Thus, they need the never-managed version.
> > 
> > Replace pci_intx() with pci_intx_unmanaged().
> > 
> > Signed-off-by: Philipp Stanner 
> 
> Looking for ack from Arnd, Greg, Alex.

Acked-by: Greg Kroah-Hartman 


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 09:46:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 09:46:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856486.1269085 (Exim 4.92)
	(envelope-from )
	id 1tM2Fb-0006FF-1m; Fri, 13 Dec 2024 09:46:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856486.1269085; Fri, 13 Dec 2024 09:46: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 1tM2Fa-0006F8-VH; Fri, 13 Dec 2024 09:46:22 +0000
Received: by outflank-mailman (input) for mailman id 856486;
 Fri, 13 Dec 2024 09:46: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 1tM2FZ-0006F2-CC
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 09:46:21 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20612.outbound.protection.outlook.com
 [2a01:111:f403:2416::612])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 198d3556-b937-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 10:46:19 +0100 (CET)
Received: from MW4PR04CA0209.namprd04.prod.outlook.com (2603:10b6:303:86::34)
 by MN2PR12MB4047.namprd12.prod.outlook.com (2603:10b6:208:1de::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.18; Fri, 13 Dec
 2024 09:46:10 +0000
Received: from MWH0EPF000971E3.namprd02.prod.outlook.com
 (2603:10b6:303:86:cafe::b8) by MW4PR04CA0209.outlook.office365.com
 (2603:10b6:303:86::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.15 via Frontend Transport; Fri,
 13 Dec 2024 09:46:09 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 MWH0EPF000971E3.mail.protection.outlook.com (10.167.243.70) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Fri, 13 Dec 2024 09:46:09 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) 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, 13 Dec
 2024 03:46:08 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 13 Dec 2024 03:46: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: 198d3556-b937-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CMhuoftOMIGukJGWoMU8TfIj0+8l9FWrGaqnGQ5GRzEfJtFLWTz8X2kU6dIA31hc9tUMYnRukwlESbchIwuR5qguTQTUSeqIMBuvp3krUs5glWI0lfyV9S+5qncgmodTOtGFAvmV7qbsdMu10aJ7vSBWgFqHpUn+t4LSKULbiTJB5KWACbCkfXCSyComQe6z+7XHI60zEv6b453tvQxh8MtecgbsvSll6pxXH6xZiSONYCdXcng6B19vtomgLHrBjwHwfFF/APvoPyvs/No++MGclRfQRLz5JBvoUWASYyj8Ve6+Pj23rEdNp3u3ot1EhvGN3GW+/y0pC1ZoMD+YsA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=8D9BD01jgMhk+GCEvIWAN/G0tU0XeYCD+AiRCx8+xck=;
 b=gpOnU7xH+iwGkhHHTjVy6ETzzhtyK6gA+mOUO71WRRXZGMB+gbTv1txtPpsOIIjbaxj59OHcKjT4llAlI0bmhRkicP73Acrg+cd9WTrdsywMnHb0brcOOpoMClvJwFdRAYK+5K5/2SX3g8J3Ps+eNSSVfRAkxAymHVu0hIVmwGS3WTp+/eXDjWeuMW8ZZeYNwQeaek/If56coPzX92u8zwST4StL1n0j6SySwUW1glrQS+RMnWs7da0+T9ayHrG6DjEKd0kbNAntqMpmeqvdSybcjpJEGWlB48cdwqOukrcqLtEtB4IpJ2it/4jq0gO7nW33VTbNWipkH/rn+lIGZg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=minervasys.tech smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=8D9BD01jgMhk+GCEvIWAN/G0tU0XeYCD+AiRCx8+xck=;
 b=EMEHMHoCsdZIJT6eZRwQCDZT4dr99+rNstJIOmwpvVIIt09ZpssvsgxIQ17hFqfNIwRehjZFDR/U10YltoEEuU8Z6JRqFDlQ1i1PojasGPYZqg6ioPEknzAbt4dtW0hIqZDDFXqbv6c8WQvkHYSZRJVkovLjxyyrcjZhBaqRazw=
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=SATLEXMB04.amd.com; pr=C
Message-ID: <2f834c6b-c9fa-4b95-abff-b9bcb8c70246@amd.com>
Date: Fri, 13 Dec 2024 10:45:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v11 03/12] xen/arm: permit non direct-mapped Dom0
 construction
To: Andrea Bastoni , Carlo Nonato
	, Julien Grall 
CC: , , Stefano
 Stabellini , Bertrand Marquis
	, Volodymyr Babchuk 
References: <20241202165921.249585-1-carlo.nonato@minervasys.tech>
 <20241202165921.249585-4-carlo.nonato@minervasys.tech>
 
 <7ecc99c5-0cb5-4351-bede-cb03c9a4ac7e@xen.org>
 <293004fa-c87e-4a45-aa4c-b02456aaecea@amd.com>
 <0bacfdb6-d4ad-4dea-85d4-2851873dca4e@xen.org>
 
 
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000971E3:EE_|MN2PR12MB4047:EE_
X-MS-Office365-Filtering-Correlation-Id: f10ee6df-953b-48f7-9c63-08dd1b5af8db
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?eDAxMkx3VS9DWXdqeS9naDdnTVpwc1lmMkF2Y2hLQ2txSXpiN09OZVUxZXEz?=
 =?utf-8?B?NzY2a3JlU1R3N0xXb2ZBUE1aanpnOHJVeFF0ZU1wT3lrTi9OODhJWVZNdWkw?=
 =?utf-8?B?SFh0ZWl1aW5hQ1JZZHJWN2ZZcDYyZ3MyMHIyeElldHdNcitZcG1CYzVmZ1Ns?=
 =?utf-8?B?RW9icDh2YkJkSmhVc1JvOUNPOEgzNi90bnZTdjc5SVBOK3dlcWFaeWNpdWRs?=
 =?utf-8?B?VnZYSVVMUDRPd3ZYS01jTWlXaWI4YlVNRmVkUDZoaWl3Z0J5aDFWMStvWDFX?=
 =?utf-8?B?RStHa3MwM3dyQWp6L0RsdDE2V2JObjdHaThhZ0xUcVVGYVBCc2RxV1JUVkFt?=
 =?utf-8?B?SjZVL3BHck5rTlVwZDh2ckJVKzRBWVhKOXFiYTIxZjlLWW5la0hFUXlSR0RT?=
 =?utf-8?B?enNxSU5WM1QwMWhOZ010WitXbTZKdUNlQVczSG56K0ZlVXNBV01TTjVnQXRD?=
 =?utf-8?B?NitDYzFJT0FsTXluK1RyeGlTZXphWHJGTDFQWThzU1JWZ2x6bkk1T3BDb3NH?=
 =?utf-8?B?TU1sLzFUZWpIcHRQZU1VU09uQ3VhTGN3NHNsTDNFUXhBcjhjd01QblQwVEds?=
 =?utf-8?B?dWtUai9IVU5mLzRFSW82ZmVjRlZic0ZPTnh5bi9PWUxhSXZmOWxxc3JOaHlO?=
 =?utf-8?B?cFE3d0Q0TzVCK3lWVjIvWlJSZWJ2cEFITGFIaFFCNXJneVA4THZRTExpT3Zt?=
 =?utf-8?B?aVorU0d6R1BGcVdlejRxdmx0VXd0VnF3Z05Gb2pTdW5RNmx0MHlUdEdXbUls?=
 =?utf-8?B?S1dteTUyVjhyUUovbytBMjVpdktWaHZlbE90Qlk2dGhrTXZjZklIazhsbVA1?=
 =?utf-8?B?VDFEWjdidjFvU2V2Ni83WGhwdW96RGgwVFl2ZmtHNVVENWdNRHpOclpUeXBJ?=
 =?utf-8?B?RTAwS2J4eCs1OVV1QnBUSUFKN0NiVVVRWlFMVVVPNFNCTFdsR3V3bUdYbmZv?=
 =?utf-8?B?TlV1aGl3STRxNGR1WDBXM1dxTUtCejE3VHYweVBZOXQ3cG4xNUFuck1qR3BN?=
 =?utf-8?B?OGJ1cCsvVHRsWTZ1RTZPajcyL3VBbDRpTEs2SWJRb2c2UFVORHJucWJGdUk4?=
 =?utf-8?B?Mk43eTRNdnJZdlZDemx5aGxLUzBmaTFhVFpuTzRPLzI4bFQzcXVHcFRLUHdt?=
 =?utf-8?B?bjg2cWJvdklGaXFwNXY3Z2VvTWdYMW9yVjduay82TnhZdWUvWno3TXpiQnNq?=
 =?utf-8?B?aFV6VkZnRzRDK0lMYlNCRk1MamF4bXNoMEUwQ016NTJvQmI4ZEFJdUhqZTFM?=
 =?utf-8?B?d3ltcXY2aENsTnMvMmw0NHhqTTdxTUVGbTl1UnQ1bXArN1piK0s4MFRTbWtr?=
 =?utf-8?B?U1Fqa3JKSmJUbHFCKzVSbHFZL256cnl3Y3VEanFia1MvQU03cloyL3Eybzdi?=
 =?utf-8?B?dHE3NDRrUnF3bVNXU0lwZEVXSE9PS3BxOUxGMFFVY2JLRTFPZDBoQnZnZXlo?=
 =?utf-8?B?a3JuZjUyUlJGd3VybDc2UGtCdkVoZFpsd0NUNCtvZzFCK2VmVnp6UXphN01G?=
 =?utf-8?B?bVhMNVBCYlNJZUdSaVY3U3hCM1ZMVFE2ZWJSUmRsZU5hcmh6TGhqUktVZklT?=
 =?utf-8?B?SlVLcGxNNEVaS0hGeHdLdHhHRjJqNmdEak1ONEpwVlFBNVBnTlNXSk5zK1l5?=
 =?utf-8?B?cW52YUVyeHRvSHgvNXRkZ2xVVFFwWTVGNUpoUjVUQVNuVjg2RUE3Z2R3ejVO?=
 =?utf-8?B?VkVPVTYrbm9IaHY5cWEybzFLSm5wbFBFSnVWdnhZNnRiazhic2dYZ0I5OUQy?=
 =?utf-8?B?NXFXUlRGTTE1Yzk4dVp0THY0WVlueVNSU2w5T3kwVDJ0L0xpRlJqN1VCRjEr?=
 =?utf-8?B?c1lseFdqcWJTenQzSUdxOTViUW16Y0o4bVdRZ1UxdUNFVTJsVmRtZy9vWUYy?=
 =?utf-8?B?cHg2T3FxbENNMDRzV2o0S2ZQcFlHajc3WWtYQ1NBdmVTeEE9PQ==?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2024 09:46:09.1064
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f10ee6df-953b-48f7-9c63-08dd1b5af8db
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000971E3.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4047

Hi Carlo, Andrea,

On 12/12/2024 19:22, Andrea Bastoni wrote:
> 
> 
> On 12/12/2024 18:48, Carlo Nonato wrote:
>> Hi,
>>
>> On Mon, Dec 9, 2024 at 8:17 PM Julien Grall  wrote:
>>>
>>> Hi Michal,
>>>
>>> On 07/12/2024 15:04, Michal Orzel wrote:
>>>>
>>>>
>>>> On 06/12/2024 19:37, Julien Grall wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Sorry for the late answer.
>>>>>
>>>>> On 05/12/2024 09:40, Michal Orzel wrote:
>>>>>>
>>>>>>
>>>>>> On 02/12/2024 17:59, Carlo Nonato wrote:
>>>>>>>
>>>>>>>
>>>>>>> Cache coloring requires Dom0 not to be direct-mapped because of its non
>>>>>>> contiguous mapping nature, so allocate_memory() is needed in this case.
>>>>>>> 8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a separate module")
>>>>>>> moved allocate_memory() in dom0less_build.c. In order to use it
>>>>>>> in Dom0 construction bring it back to domain_build.c and declare it in
>>>>>>> domain_build.h.
>>>>>>>
>>>>>>> Take the opportunity to adapt the implementation of allocate_memory() so
>>>>>>> that it uses the host layout when called on the hwdom, via
>>>>>>> find_unallocated_memory().
>>>>>>>
>>>>>>> Signed-off-by: Carlo Nonato 
>>>>>>> ---
>>>>>>> v11:
>>>>>>> - GUEST_RAM_BANKS instead of hardcoding the number of banks in allocate_memory()
>>>>>>> - hwdom_ext_regions -> hwdom_free_mem in allocate_memory()
>>>>>>> - added a comment in allocate_memory() when skipping small banks
>>>>>>> v10:
>>>>>>> - fixed a compilation bug that happened when dom0less support was disabled
>>>>>>> v9:
>>>>>>> - no changes
>>>>>>> v8:
>>>>>>> - patch adapted to new changes to allocate_memory()
>>>>>>> v7:
>>>>>>> - allocate_memory() now uses the host layout when called on the hwdom
>>>>>>> v6:
>>>>>>> - new patch
>>>>>>> ---
>>>>>>>    xen/arch/arm/dom0less-build.c           | 44 -----------
>>>>>>>    xen/arch/arm/domain_build.c             | 97 ++++++++++++++++++++++++-
>>>>>>>    xen/arch/arm/include/asm/domain_build.h |  1 +
>>>>>>>    3 files changed, 94 insertions(+), 48 deletions(-)
>>>>>>>
>>>>>>> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
>>>>>>> index d93a85434e..67b1503647 100644
>>>>>>> --- a/xen/arch/arm/dom0less-build.c
>>>>>>> +++ b/xen/arch/arm/dom0less-build.c
>>>>>>> @@ -49,50 +49,6 @@ bool __init is_dom0less_mode(void)
>>>>>>>        return ( !dom0found && domUfound );
>>>>>>>    }
>>>>>>>
>>>>>>> -static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
>>>>>>> -{
>>>>>>> -    struct membanks *mem = kernel_info_get_mem(kinfo);
>>>>>>> -    unsigned int i;
>>>>>>> -    paddr_t bank_size;
>>>>>>> -
>>>>>>> -    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
>>>>>>> -           /* Don't want format this as PRIpaddr (16 digit hex) */
>>>>>>> -           (unsigned long)(kinfo->unassigned_mem >> 20), d);
>>>>>>> -
>>>>>>> -    mem->nr_banks = 0;
>>>>>>> -    bank_size = MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem);
>>>>>>> -    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM0_BASE),
>>>>>>> -                               bank_size) )
>>>>>>> -        goto fail;
>>>>>>> -
>>>>>>> -    bank_size = MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem);
>>>>>>> -    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM1_BASE),
>>>>>>> -                               bank_size) )
>>>>>>> -        goto fail;
>>>>>>> -
>>>>>>> -    if ( kinfo->unassigned_mem )
>>>>>>> -        goto fail;
>>>>>>> -
>>>>>>> -    for( i = 0; i < mem->nr_banks; i++ )
>>>>>>> -    {
>>>>>>> -        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
>>>>>>> -               d,
>>>>>>> -               i,
>>>>>>> -               mem->bank[i].start,
>>>>>>> -               mem->bank[i].start + mem->bank[i].size,
>>>>>>> -               /* Don't want format this as PRIpaddr (16 digit hex) */
>>>>>>> -               (unsigned long)(mem->bank[i].size >> 20));
>>>>>>> -    }
>>>>>>> -
>>>>>>> -    return;
>>>>>>> -
>>>>>>> -fail:
>>>>>>> -    panic("Failed to allocate requested domain memory."
>>>>>>> -          /* Don't want format this as PRIpaddr (16 digit hex) */
>>>>>>> -          " %ldKB unallocated. Fix the VMs configurations.\n",
>>>>>>> -          (unsigned long)kinfo->unassigned_mem >> 10);
>>>>>>> -}
>>>>>>> -
>>>>>>>    #ifdef CONFIG_VGICV2
>>>>>>>    static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
>>>>>>>    {
>>>>>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>>>>>> index 2c30792de8..2b8cba9b2f 100644
>>>>>>> --- a/xen/arch/arm/domain_build.c
>>>>>>> +++ b/xen/arch/arm/domain_build.c
>>>>>>> @@ -416,7 +416,6 @@ static void __init allocate_memory_11(struct domain *d,
>>>>>>>        }
>>>>>>>    }
>>>>>>>
>>>>>>> -#ifdef CONFIG_DOM0LESS_BOOT
>>>>>>>    bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size,
>>>>>>>                                        alloc_domheap_mem_cb cb, void *extra)
>>>>>>>    {
>>>>>>> @@ -508,7 +507,6 @@ bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
>>>>>>>
>>>>>>>        return true;
>>>>>>>    }
>>>>>>> -#endif
>>>>>>>
>>>>>>>    /*
>>>>>>>     * When PCI passthrough is available we want to keep the
>>>>>>> @@ -1003,6 +1001,94 @@ out:
>>>>>>>        return res;
>>>>>>>    }
>>>>>>>
>>>>>>> +void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
>>>>>>> +{
>>>>>>> +    struct membanks *mem = kernel_info_get_mem(kinfo);
>>>>>>> +    unsigned int i, nr_banks = GUEST_RAM_BANKS;
>>>>>>> +    paddr_t bank_start, bank_size;
>>>>>> Limit the scope
>>>>>>
>>>>>>> +    struct membanks *hwdom_free_mem = NULL;
>>>>>>> +    const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
>>>>>>> +    const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
>>>>>> Limit the scope
>>>>>>
>>>>>>> +
>>>>>>> +    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
>>>>>>> +           /* Don't want format this as PRIpaddr (16 digit hex) */
>>>>>>> +           (unsigned long)(kinfo->unassigned_mem >> 20), d);
>>>>>>> +
>>>>>>> +    mem->nr_banks = 0;
>>>>>>> +    /*
>>>>>>> +     * Use host memory layout for hwdom. Only case for this is when LLC coloring
>>>>>>> +     * is enabled.
>>>>>>> +     */
>>>>>>> +    if ( is_hardware_domain(d) )
>>>>>>> +    {
>>>>>>> +        ASSERT(llc_coloring_enabled);
>>>>>> This patch does not build because of declaration not being visible. You must include .
>>>>>
>>>>> Piggying back on this comment. AFAICT, the code below would work also in
>>>>> the non cache coloring case. So what's the assert is for?
>>>>>
>>>>>>
>>>>>>> +
>>>>>>> +        hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank,
>>>>>>> +                                             NR_MEM_BANKS);
>>>>>>> +        if ( !hwdom_free_mem )
>>>>>>> +            goto fail;
>>>>>>> +
>>>>>>> +        hwdom_free_mem->max_banks = NR_MEM_BANKS;
>>>>>>> +
>>>>>>> +        if ( find_unallocated_memory(kinfo, hwdom_free_mem) )
>>>>>> My remarks for the use of find_unallocated_memory() 1:1 have not been addressed. You did not even
>>>>>> change the comments inside the function. The problem is that the function is specifically designed
>>>>>> for finding extended regions and assumes being called at certain point i.e. dom0 RAM allocated, gnttab
>>>>>> region allocated, etc.
>>>>>
>>>>> So I agree that the function should be updated if we plan to use it for
>>>>> other purpose.
>>>>>
>>>>> My opinion is that we should attempt to make the function generic so
>>>>> that in your
>>>>>> case you can choose which regions to exclude, define even your own function to grab free regions (at the moment
>>>>>> add_ext_regions grabs banks >= 64M but you still discards banks >= 128M, so it's a bit wasteful.
>>>>>>
>>>>>> My very short attempt to make the function as generic as possible in the first iteration:
>>>>>> https://paste.debian.net/1338334/
>>>>>
>>>>> This looks better, but I wonder why we need still need to exclude the
>>>>> static regions? Wouldn't it be sufficient to exclude just reserved regions?
>>>> Static shared memory banks are not part of reserved memory (i.e. bootinfo.reserved_mem) if that's what you're asking.
>>>> They are stored in bootinfo.shmem, hence we need to take them into account when searching for unused address space.
>>>
>>> Oh I missed the fact you now pass "mem_banks" as a parameter. I thought
>>> they would still get excluded for cache coloring case.
>>>
>>>>
>>>> If you and Carlo are ok with my proposed solution for making the function generic, I can send a patch as a prerequisite
>>>> patch for Carlo series.
>>>
>>> I am fine with the approach.
>>>
>>> Cheers,
>>>
>>> --
>>> Julien Grall
>>>
>>
>>> @@ -2152,7 +2238,10 @@ static int __init construct_dom0(struct domain *d)
>>>      /* type must be set before allocate_memory */
>>>      d->arch.type = kinfo.type;
>>>  #endif
>>> -    allocate_memory_11(d, &kinfo);
>>> +    if ( is_domain_direct_mapped(d) )
>>> +        allocate_memory_11(d, &kinfo);
>>> +    else
>>> +        allocate_memory(d, &kinfo);
>>>      find_gnttab_region(d, &kinfo);
>>
>> Since find_gnttab_region() is called after allocate_memory(), kinfo->gnttab_*
>> fields aren't initialized and the call to find_unallocated_memory() with
>> gnttab as the region to exclude, fails ending in a crash since memory for
>> dom0 can't be allocated.
>>
>> Can the solution be to call find_gnttab_region() before the above if?
> 
> The function is called find, but currently it only initializes kinfo->gnttab_start
> and kinfo->gnttab_size and we tested that moving it before allocate_memory* doesn't
> cause fallouts.
> 
> If moving before allocate_memory*, would it be better to rename it e.g., init_gnttab_region()?
> 
> Thanks,
> Andrea
> 
>> Or should I just call it before allocate_memory() in one case, but still after
>> allocate_memory_11() in the other?
>>
>> Thanks.
> 

AFAICT there is nothing stopping us from moving find_gnttab_region() before allocate_*. This function initializes
gnttab region with PA of Xen. In normal case, because Xen is added as bootmodule, it will never be mapped in dom0 memory map
and the placement does not matter. In LLC case, it will point to relocated address of Xen and it needs to be known before
calling find_unallocated_memory. Don't rename it, leave as is, just move before allocate_*.

@Carlo:
My prerequisite patch has been merged, so you're good to respin a series (unless you wait for some feedback in which case do let me know).
To prevent too many respins, you're going to call find_unallocated_memory for LLC passing resmem and gnttab to be excluded. If you're going
to reuse add_ext_regions, you need to rename it and fix comments to make it more generic. As for the size, the decision is yours. One solution
would be to modify add_ext_regions to take min bank size as parameter (64MB for extended regions, X for LLC dom0). In your code, you write that
the first bank must contain dom0, dtb, ramdisk and you chose 128MB. However, looking at the code, you seem to discard banks < 128 for all the banks,
not only for the first one. This is the part that I don't have a ready solution. Maybe you could define your own add_free_region function and sort
the banks, so that you take the largest possible bank first for dom0. This could simplify things.

You can also ask others for opinion.

We are approaching Dec 20th deadline, and I want this series to be in as it's been on the list for too many years. I'm willing to accept a sub-optimal solution
(so far will be used only for LLC, and LLC as experimental feature will be the only victim of not optimal algorithm) for now, and we can think of a better one
after the release. But still, even the sub-optimal solution must make sense.

~Michal



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 09:59:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 09:59:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856502.1269095 (Exim 4.92)
	(envelope-from )
	id 1tM2Rl-00086Y-8B; Fri, 13 Dec 2024 09:58:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856502.1269095; Fri, 13 Dec 2024 09:58: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 1tM2Rl-00086R-5J; Fri, 13 Dec 2024 09:58:57 +0000
Received: by outflank-mailman (input) for mailman id 856502;
 Fri, 13 Dec 2024 09:58: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 1tM2Rj-00086I-PY
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 09:58:55 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20606.outbound.protection.outlook.com
 [2a01:111:f403:2408::606])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dbe1877c-b938-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 10:58:54 +0100 (CET)
Received: from IA1PR12MB6532.namprd12.prod.outlook.com (2603:10b6:208:3a3::12)
 by DM4PR12MB6589.namprd12.prod.outlook.com (2603:10b6:8:b4::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.16; Fri, 13 Dec
 2024 09:58:51 +0000
Received: from IA1PR12MB6532.namprd12.prod.outlook.com
 ([fe80::dc05:a63a:39fa:ff0b]) by IA1PR12MB6532.namprd12.prod.outlook.com
 ([fe80::dc05:a63a:39fa:ff0b%7]) with mapi id 15.20.8251.015; Fri, 13 Dec 2024
 09:58:51 +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: dbe1877c-b938-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=HlDb4f4NPGoxR1EebYlyo/omQQ79ctYYmbjLTwk54rdajr7Ay6kjJfN0Jk2UmBsf02dtjbArWTTFGcLsAfWhGnz7CgIxitpe5o9Q/lJs4mJ0VsjD1Cf8IccSwzSEc7XYhSrp92uSk9ZiXCajbvVfzjwAyAh0dVhZgnctcKg+SIqkTGRlkAVkC7GoPeyOppTJ8NlchiHBTC2Dos/kl6LfVAsHnlNFmLn31IbX07X9gRXrXmKPKs4PWfeqZNf9M2IWBkUagkuJxoytOzacpliGMe6idhxdoZ7eF7ueY2Dwt56Kw6HIBRCNy16gUqUXS8ncjnPx7q6IYfVyC1Pmp8PlfA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=3/hKrtp2mKw2lsKmfdebUk5ttyADH6RTL/Ux9ghBR8I=;
 b=lYTdv2Ls1dyXEmMB5ruB/9DWGQbFwo96Un64GQil5EM8jPsfXDHWGmawx1pO0uN7JUw/PVW+kQf2KAFoaMIXPzZvcFvnUaoyXzM/10HIaX5N+hMPD7t7vshIhElTfg2PhQuIoY4R74qset1JpJFqcLFI4u4KQwumjFX/N+4Mg7qXebYTAUEhT0qVeNaCBUap6GkMAZL7DuFi5QPutz/n8YIDh02rtiBrvZneojuVcP7TcABBFqKHf7JIP83glmbnWkLw81F7NHLCwfk1s/gSTpPnmz8WgZm1GQtrtVVa0WnhY974mgfczgZeXNq60OZMfbL6sdvQt1+dynLPXQ9/5A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=3/hKrtp2mKw2lsKmfdebUk5ttyADH6RTL/Ux9ghBR8I=;
 b=b/FIHr9mRhLPbEwN+/QLAXj8Bss1ij5KMSf44JEys8cHuv2s199Vy1qLzj0f8zO03iTfURVrwYSKLuhzgrE+cVuQIUzzOOsoJVsLZrNh07Nq5BLTFtIt5xLmacYwaBpuFq1WKNfFB+s4li1nMmQaN/wMb+IehfKAprAZQOgxH8g=
From: "Zhang, Julia" 
To: Juergen Gross , "Zhang, Julia" ,
	David Airlie , Gerd Hoffmann ,
	Gurchetan Singh , Chia-I Wu ,
	"dri-devel@lists.freedesktop.org" ,
	"virtualization@lists.linux-foundation.org"
	, Stefano Stabellini
	, Oleksandr Tyshchenko
	, "xen-devel@lists.xenproject.org"
	
CC: "Deucher, Alexander" , "Koenig, Christian"
	, Daniel Vetter , "Chen, Jiqian"
	, "Huang, Ray" , "Penny, Zheng"
	, "Zhu, Lingshan" , Anthony PERARD
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, Jan Beulich , Paul Durrant
	
Subject: Re: [PATCH 0/3] virtgpu: check if P2P is possiable or not
Thread-Topic: [PATCH 0/3] virtgpu: check if P2P is possiable or not
Thread-Index: AQHbSJXzDQ7EITP6Dk67xFd0UcUl5LLiQecAgAI9SQA=
Date: Fri, 13 Dec 2024 09:58:50 +0000
Message-ID:
 
References: <20241207105023.542399-1-julia.zhang@amd.com>
 <1b557096-6527-4aea-a8c2-d72ecf0a31e8@suse.com>
In-Reply-To: <1b557096-6527-4aea-a8c2-d72ecf0a31e8@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: IA1PR12MB6532.namprd12.prod.outlook.com
 (15.20.8251.004)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: IA1PR12MB6532:EE_|DM4PR12MB6589:EE_
x-ms-office365-filtering-correlation-id: adcb2431-bef3-44c6-3d36-08dd1b5cbee6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|376014|7416014|366016|1800799024|921020|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?aHpqYTlBd2ZGNzU4WU9DNjZuNXpuUGJ1cWlka0dwVm8vMURxdk1TRDJ0ZlUz?=
 =?utf-8?B?anpBcGwvWXVhZnMyZEN6L0FsUXRPSjBoWGhITDFQZVEvRUl0VnNuQVNOaTRt?=
 =?utf-8?B?dWs4M1V4eXRJNXA4RmZPQklxcGZieU5MNUp1R29nMjM1MHNndzNtVFdidVRl?=
 =?utf-8?B?ZUQ4VFN3TmFTUDFYazFUb0UvLzNGb0d5U0xxR1J1MVZBclNWU1NTc0FSL2pR?=
 =?utf-8?B?clZNRWNSeGRiVkZvRHkxaytOYWFJR2R2RGxJSm1RK1ZEUDluR3lzOEY2QWtk?=
 =?utf-8?B?Z3RjZmJyVmc4Wk8yWVBUMlNJZTI2OTJnZzhDQmV1SElKRE1mMlhlaHE1eFRw?=
 =?utf-8?B?V3RkUmllUm5ES3Flb2pKOVpGN2tnSW04cU92RjhqZEtDNmRlc2NqUU9aTW5K?=
 =?utf-8?B?UlI1MCtDOFRIVDlQZUZmaDlJdGYyZmV3WG1LdTdrVE16dFFKUlFhb2FEeTBn?=
 =?utf-8?B?aU9sQ0QwRmtETi9qWHR6Mk93REQ4Yi82aVdNY2o2Y05lZFZxWXMybTgvUHVN?=
 =?utf-8?B?cHdudjlhT21QUVU5RjIvZ0k3ZDNwcFhyNVhEN29nbVdmampwNVFBd2JFNXNz?=
 =?utf-8?B?NG5GM2JzWGluRmFCUS9jeC9WdmxERURMejJUWWNpRVRoMUh4S0RLbngxYVoz?=
 =?utf-8?B?UVg0dG5yMDFYVUN0YU1Kb3VpVnk0YkRWMkhMMlVXZkNicEY4b3ZMbnRGYXJ5?=
 =?utf-8?B?SkRFNEw3dTVzWFFrMXNBVDR2SkNOYWlaemVUdW5UWjNIa1lKcG5QRkdRMkwr?=
 =?utf-8?B?ZHkyYTluRnJOYU5RNnR6dVdXdVcydzdjRXhmN2c2dEFGeWJTb2dhUGRVWEJM?=
 =?utf-8?B?VFJyRFh4SXdxTjF0blRmWFVmOTJRQmdpV0cxczBLcDVKbVRoTlMwZTcyb2dO?=
 =?utf-8?B?ODE2NEx3dUttUkVUSUpqRlNLRDZ1VTg0S3dkUDdjVXk3S2g3TzdzMWFZc2Yx?=
 =?utf-8?B?WWxQSDZmcmp3aEY3Z1Y0cDFUUTRydXJqT1FqNmtOcXJ2eXlja1R0ZkNMZ1pl?=
 =?utf-8?B?OUM3M0crclBiaE9OU0RrYkU3WU95RzdsZ09qdTh4TmxWVVFLMjlMMmM2YUdq?=
 =?utf-8?B?M2JlamtURDFOeXdmc2ZGc2YxQWlWY0dDZWdURCtiOWl2SWg0Q2xyUjdGTjRm?=
 =?utf-8?B?TjY1amZsT1pHWUF0SGZBZDZRUFl3eHRTdGRybGFaU2gxWk5nU3FlNS81U1NT?=
 =?utf-8?B?R3VDL1E3di9xOTlNb3ZwTTE3Y05QWXJ1SE1hcnNqR2EvWlI3QndMemxRZ1Jl?=
 =?utf-8?B?RmRhQnQ5TkNwaGY0MERGUi9xeHZZam1TRE9YN3RYOG5NeTIrc2ZiakY3K2NS?=
 =?utf-8?B?Y1BuNmFnVHNRamdGSUZ6eWlGbXB3SkdGdWYzZkkybHBXblpnOWpDQVRFZmJa?=
 =?utf-8?B?RzFSeHBhUEZibkttRm03NzVRMERCc3l1N0ZRdWNPN29VYjFGK2VqQ0pxYXVa?=
 =?utf-8?B?NkF3Ujd4N3ZtdkJOdWxENFYzd3BoR0dTRmNFVWFiQ2Y1czc4VVU4amRkeUNh?=
 =?utf-8?B?b2EwVXQwOHFjaEx2b3VyaHFuTTV5MVl0b3ErZjdvQWEwdXQ3ZGZkckRLQ0N2?=
 =?utf-8?B?cjZ2dWZGdVI1cWZySDJPbDN3aGFYdHJudkwxMmpJL1lJK0JmVEwzNVNTVGgw?=
 =?utf-8?B?VzI0Z1hxa1AzQ2tmbFViZnRGL1BpWkVmaCt6aFN3ekN2VnJUUXNJUXAvRk9a?=
 =?utf-8?B?dm05QmpJSStnZlhTc1Z2dWVHVG56VzVwckpDd2ZRRnVpbmRkTzA2NkFpUnlK?=
 =?utf-8?B?VVZJS2ZOd3VITWs5UStsT3M1TXRxWlhGMVhURVM4a0lEcDNkNnZhbE5KL3Q1?=
 =?utf-8?B?MmZIaENoRGRTbmd2T2F4TGFyRWhWQUNkM2JsMHpwTFNyQUx5T0hlY0xlaEpr?=
 =?utf-8?B?MXVmb1pvMU52bXF3YndZOHZuVTlpVVBPalVDcjcwTWZaWW10eEltUnVGK0VG?=
 =?utf-8?Q?cAGUfq5lgOw=3D?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA1PR12MB6532.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(1800799024)(921020)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?dnhETDc2S0kzOC9RRXgyVjZyTlQ0ZS9TbHhLVnFRQjBJNEZiNElBczN1U0F5?=
 =?utf-8?B?Z1pHQk1saG5HaTF2UzNJQlJKbnY1b3lFYWU1ZGI3TEp2S3NUTWlwdjkxU1RM?=
 =?utf-8?B?WThNVVR6d0pwSG5ERnJ3Wjk4OGZtbUUyUG9jcXhtNnA5WnpQNW5pOVlFVnBn?=
 =?utf-8?B?b1YxUVpjR3l6cys3VWw5V1N4anIzTm1GV0dVNzQvNHdQVTYxUVl4UjExTFI0?=
 =?utf-8?B?VlBTcmQybklSYkFTa2Yra0w0Wk9JdTVWcXl0M1pwWENvRU51RnZtUkhlZThr?=
 =?utf-8?B?S1JyVm1rS3R2UkhOWkNkd1Nud001TW5aRjljL0pkeTEzR1RSd25PQW9UQmxO?=
 =?utf-8?B?eStDdHlheWFydHhMV3oySWdmV0ZXekNEa1A3cUtBekdpbkdLVmJaT1ZJcmV3?=
 =?utf-8?B?em56RTV4ejZabitvNEdTNFFJT0Y0eHVQMC9ROElyS3BZSlFFanZpODJZQ210?=
 =?utf-8?B?MDUrZXBSZTZlYzYxTVF2b0c4QzhDdnVZU1FhajlUTjNxb2JWY2tVaWxzNm05?=
 =?utf-8?B?YlF4VXVTdU9tWmxvWmV5KzZra2hrZkJWTGI0MW9ZZUpPVjNjbThRaTVYVGR0?=
 =?utf-8?B?dXQ4dVJQTFBoV2N1Mm5aRFN2UmpUQTdWZUtBMkc1aVZIcGhEM2YvZnFYdE5Q?=
 =?utf-8?B?T2lFR045cVdTV0daYlY0akZCK3pYTUQwTWh2L0FCN1c1R3plT2dFS3M3Yno1?=
 =?utf-8?B?NGpIb3B6OXFsblNBK2tOdlcydlBaVy9ha2owUUZtelRjamNBdjJhdHRlSnhR?=
 =?utf-8?B?bnIyTGtFV0RsOFgzdnR0SGJKbDlNUXhhalkxUHA2aEtnc1FhSjBRa05JZk5i?=
 =?utf-8?B?Nzd4dE0xQTN1TW5BK3ZLbGFHYzcrdnYzY0ZBbUhGbnZQaFZCRThwYUFtWWda?=
 =?utf-8?B?cy9mSm54T2NxWVJjRm5McDI0MTZGVGJDekZIaEsxUjcycU1ZbUtGREdJWkpJ?=
 =?utf-8?B?MlJrbzdKQmU4ZXAyc092TjhWSUF0Qjc0ZTlVZlNLUHVjQ01nenViT0QzYmY2?=
 =?utf-8?B?WFI2aU9ONHBHUi9UaitzdDVFSnlKbEs4N3gwK0NGcTM5ckgrU3Mrckd4SWVi?=
 =?utf-8?B?NTFpTlkvdEFSV2NmQTRJV0dvRkszWlR0ZWhxM2ZPZjhMSUxuWnpvSTlGNW4v?=
 =?utf-8?B?QUZ5bTA4WXdvTWFWd0J5RXFMRm4rUUhrUmhCUlFHTnJaeVNNWDE5bE0zTkxn?=
 =?utf-8?B?L1FremZZVFdnOXlld3BMOVhpeDFzTHJScXNDTDZLVkdwb3JLQnhlcklBWVIv?=
 =?utf-8?B?bC9EWGk0WFljbFErbW5mVjFJOXVrZS91Qm1UK0RualVkM1pYQjVpbjB0OHhl?=
 =?utf-8?B?UVlUQmt5OXp0bUNxZ0ppWDFCN3dncGZIRW11RUZvbHlGMVRYOEVydmg5SkYx?=
 =?utf-8?B?T0RzdEg0NEh4T0pFSG5ucXo5M05JckNzTmxubC9LZnZoSmRma1RYT1FtajBY?=
 =?utf-8?B?M2Zwa1VCL3o0N3hrN2YxNG1Eby9Bd00yTCs1V0wwd2JxT1BrbUlYNGNLV0pH?=
 =?utf-8?B?cG1RYlcxZzBBL1pvU2tWY3o5NlJVNzcyVWJRTWdpUXFPWW00NmY4UGNJcHhx?=
 =?utf-8?B?TVpydllTT3FvakV3WkdHS25OWTArNTl3ZHZwY0VPYlBxY0tqZ3BZckpha2Nl?=
 =?utf-8?B?NThFaGR4QWgzcFgxeVFoUmZDWklXWFcyZTEyUmt6cEFiMWZOaXdPNVB3dDlG?=
 =?utf-8?B?ZEdSRFpQZjJza3R0T1dTRlpwSU9RRmVjRWFTaHJpY0xiL1gzZy9IaFdOUy92?=
 =?utf-8?B?ZHhsMDFNb3lOVmpYeWxJMG1uNXlXNURrQ2FEbXFscGlEbkxDL1lKeXJac2tC?=
 =?utf-8?B?SjhLdUlTOUN2OFlmc2ExWE5BNW9YcHVOTHpaVEFMRFhJV3RaTHBINFdvbGtO?=
 =?utf-8?B?Y3I5WWhvRCtJbDV3RzhRNEplWWNNK0w4YTR0Z1pNVmJtUFlKVGRSUmhwQWdk?=
 =?utf-8?B?YjdJS0R1elBPTkt6RTl4T3BkdWg0bXpQbTNKMmRmbWVuYlBadTlRZ0lBaFZ6?=
 =?utf-8?B?SkJZa1QvUndZbkpuSVJYYXFJdEk1aCtyWk95WU9kanZWM2pkZWpBalRNNTFI?=
 =?utf-8?B?ejRpblNoZkdHRE9aWXliQ3dJOWVVU0ZkeU13OEhrU2I0UTZJalQ1TGROV2pt?=
 =?utf-8?Q?5hoM=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <695641150F59DC4EADB28691B1F5A034@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: IA1PR12MB6532.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: adcb2431-bef3-44c6-3d36-08dd1b5cbee6
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2024 09:58:50.9847
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: g3w95i5b/9UHIhVooztrCL6Yl5i3dhkc7r76mDUhMu/WvQphc0YPTCz/whHGFBOngfnqFgRzeJpZSjF1GlSNjA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6589

DQpPbiAyMDI0LzEyLzEyIDE1OjQzLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPiBPbiAwNy4xMi4y
NCAxMTo1MCwgSnVsaWEgWmhhbmcgd3JvdGU6DQo+PiBUbyBpbXBsZW1lbnQgZEdQVSBwcmltZSBm
ZWF0dXJlLCB2aXJ0Z3B1IG5lZWRzIHRvIGltcG9ydC9leHBvcnQgYnVmZmVyDQo+PiBiZXR3ZWVu
IHZpcnRpbyBpR1BVIGFuZCBwYXNzdGhyb3VnaCBkR1BVLiBCZWZvcmUgdGhhdCwgdmlydGdwdSBz
aG91bGQNCj4+IGNoZWNrIGlmIFAyUCBpcyBwb3NzaWJsZSBvciBub3QuIEJ1dCBjYWxsaW5nIGZ1
bmN0aW9uIA0KPj4gcGNpX3AycGRtYV9kaXN0YW5jZQ0KPj4gaW4gZ3Vlc3QgVk0gd2lsbCBvbmx5
IGdldCB2aXJ0dWFsIHAycGRtYV9kaXN0YW5jZSBpbnN0ZWFkIG9mIHJlYWwgDQo+PiBwaHlzaWNh
bA0KPj4gcDJwZG1hX2Rpc3RhbmNlLg0KPj4gwqAgU28gdGhpcyBzZXJpZXMgaW50cm9kdWNlIGFu
IGltcGxlbWVudGF0aW9uIG9mIHZpcnRncHUgZGV2aWNlX2F0dGFjaA0KPj4gY2FsbGJhY2sgdG8g
Z2V0IHAycGRtYV9kaXN0YW5jZS4gQW5kIGFsc28gYWRkcyBhIG5ldyB2aXJ0Z3B1IGNvbW1hbmQg
dG8NCj4+IHBhc3MgUENJIG5vdGF0aW9ucyBmcm9tIGd1ZXN0IHRvIGhvc3QgYW5kIGEgbmV3IHhl
biBwcml2Y21kIHRvIGdldCANCj4+IHBoeXNpY2FsDQo+PiBwMnBkbWFfZGlzdGFuY2UgYWNjb3Jk
aW5nIHRvIHRoZSBQQ0kgbm90YXRpb25zIGluIGhvc3QuDQo+DQo+IEl0IGlzIGhhcmQgdG8gcmV2
aWV3IHRoaXMgc2VyaWVzIHdpdGhvdXQgaGF2aW5nIGEgY2xlYXIgcGljdHVyZSBob3cNCj4gdGhp
cyBhbGwgaXMgY29taW5nIHRvZ2V0aGVyLg0KPg0KPiBJIGd1ZXNzIHRoZSB2aXJ0Z3B1IGZyb250
ZW5kIHdpbGwgc2VuZCBhIHAycGRtYV9kaXN0YW5jZSByZXF1ZXN0IHRvDQo+IHRoZSBiYWNrZW5k
LCB3aGljaCBpcyBydW5uaW5nIGluIHVzZXIgbW9kZSBvZiBkb20wLiBUaGlzIGJhY2tlbmQgd2ls
bA0KPiB0aGVuIGNhbGwgaW50byB0aGUgcHJpdmNtZCBkcml2ZXIgdG8gb2J0YWluIHRoZSBuZWVk
ZWQgaW5mb3JtYXRpb24gYW5kDQo+IHNlbmRzIGl0IGJhY2sgdG8gdGhlIGZyb250ZW5kLg0KPg0K
PiBDYW4geW91IHBsZWFzZSBjb25maXJtIG15IHN1c3BpY2lvbiBpcyBjb3JyZWN0Pw0KDQpZZXMs
IHlvdSBhcmUgcmlnaHQuDQoNCkp1bGlhDQoNCj4NCj4NCj4gSnVlcmdlbg0K


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 10:08:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 10:08:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856512.1269104 (Exim 4.92)
	(envelope-from )
	id 1tM2b5-0001ZO-3V; Fri, 13 Dec 2024 10:08:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856512.1269104; Fri, 13 Dec 2024 10:08:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tM2b5-0001ZH-12; Fri, 13 Dec 2024 10:08:35 +0000
Received: by outflank-mailman (input) for mailman id 856512;
 Fri, 13 Dec 2024 10:08: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 1tM2b3-0001Z9-M4
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 10:08:33 +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 34c295fd-b93a-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 11:08:31 +0100 (CET)
Received: by mail-ed1-x531.google.com with SMTP id
 4fb4d7f45d1cf-5d0d32cd31aso1882633a12.0
 for ; Fri, 13 Dec 2024 02:08: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
 a640c23a62f3a-aa67a4f8dc2sm773572466b.179.2024.12.13.02.08.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 13 Dec 2024 02:08: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: 34c295fd-b93a-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734084511; x=1734689311; 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=LRSpUNKBeXZVxNb/VM3hMwYQFc91eslLe3UGCA9xs9k=;
        b=J24wgW5TWtxnWkbapn+TaTGjPnLMU32uormcESPdcVIXT3H/WS/d6GeGHoFfqAhgEE
         DC7IucOFJ5zNG6T4PpQzfU3uIAFQDCvdjx6l2ace50ng8GTucQ6Rz2+z0guJj5tOdNtH
         zFSUSurcWTifsKB8CqT0WCUgInW4g/uh/aZ+7ANqmQP5RCiGUqqV7t0q7kNpGeSl1EM+
         xu2YKcWs7NKMMWRmVNPWB2m31OSaS9p/+rXBqQ0YWHwnIOKKnFX0YTIx8SZknbvUbEP/
         FZckRf0s1fukyJ9/htUAhLs1e3jxoxVipqe7NTJozqME1vb0FUCS52e2vgTbKJdsUm41
         a0Hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734084511; x=1734689311;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=LRSpUNKBeXZVxNb/VM3hMwYQFc91eslLe3UGCA9xs9k=;
        b=QOONBQ3dmCyJCcPiYRwS4hZNyXoUs25gX+IHCLZ59c3rRWPngXhB66h9ppwBNLlM3i
         EV52gJHbqTB7gwn5GiIYJ+CNIdJQa49jG3axQiK7ivSb5pvTRv3fzd5IocRHxspIjPGA
         IuNrbKKnjdVqPE7twVrs0rYvQOLy6mIAbk+qv8y+wOXJ7qzDcZK2ceS07wdIFd7DQcqI
         m+o0kW2MsG4s+rLO5h9Cqtrt2q9Pw2Js05CGwojhkgwdLamrBuz1B3DWz+wv6je78UIG
         Uys1JhB6xXwl2EjXAi7lor8BfDFQ9KNE380u5lFOfE/phZTIBSoJYMp+D9iMBgWOnvi3
         9ddw==
X-Forwarded-Encrypted: i=1; AJvYcCUx+7sT9m28bKVdb+6BY/ILi5VvVYwbvhtp7oh/0OG3Ds97A860ofgozQRHO+3wxEku2Luu3kfRP9k=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxlFJWhxBTMaPjzOq2Ts0Y/Q65Q+3vVZ3rGAvrtFkEFJbLX0cVc
	lVVDC4rKDZRrPgAxdLhr9bgXcEVUKt/MyfiMXrdX5H2PQrbvqJgijVJBw7uiIA==
X-Gm-Gg: ASbGncsBl1+yhlt5FQBS779CejvAwdClzuzkt4b0K7j5EdT6fy+C/nuQqVajsSRllN0
	wsxfomNtwF87SyGJAFiIB4KYpEFyDSpns9F34FhLULAWn3P7YGk/GzNmXK3o7vIb9y3MV29aUfI
	6HD4i9CCnPjKSdp1rSlLaPwb/LTUaKyU2H3HnyP9m71SSt2qgSnaLzZJ/hR8CJlpEtDw5Om9Qrg
	UQNV3y8XeF11PHc813j76aOQoGBuWuyT0UQ6vz9VYLabnwUqdTI2UMfT8SgKQWfMd1n7UAnLQKh
	Ib0/ifhcn5RbeOiywKc3pBtI2uehtkSdBVz65Zx5aw==
X-Google-Smtp-Source: AGHT+IFzFWfWlqgH46qYmeUkjwgn8S0sfvbujyPMwoPMydDyLxsGed0L8FiLFHptOqzr15vTs8QubQ==
X-Received: by 2002:a05:6402:35c2:b0:5d0:d3eb:a78f with SMTP id 4fb4d7f45d1cf-5d63c157955mr4467272a12.0.1734084511143;
        Fri, 13 Dec 2024 02:08:31 -0800 (PST)
Message-ID: 
Date: Fri, 13 Dec 2024 11:08:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: address violation of MISRA C Rule 11.1
To: Stefano Stabellini 
Cc: Alessandro Zucchelli ,
 consulting@bugseng.com, Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <7debd63f3900bad62bcbcc03081e4c04e6099135.1733914487.git.alessandro.zucchelli@bugseng.com>
 
 
 <26600bb0-93af-45b5-a341-5771bad844a1@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 13.12.2024 01:53, Stefano Stabellini wrote:
> On Thu, 12 Dec 2024, Jan Beulich wrote:
>> On 12.12.2024 03:27, Stefano Stabellini wrote:
>>> On Wed, 11 Dec 2024, Jan Beulich wrote:
>>>> On 11.12.2024 12:02, Alessandro Zucchelli wrote:
>>>>> Rule 11.1 states as following: "Conversions shall not be performed
>>>>> between a pointer to a function and any other type".
>>>>>
>>>>> Functions "__machine_restart" and "__machine_halt" in "x86/shutdown.c"
>>>>> and "halt_this_cpu" in "arm/shutdown.c" are defined as noreturn
>>>>> functions and subsequently passed as parameters to function calls.
>>>>> This violates the rule in Clang, where the "noreturn" attribute is
>>>>> considered part of the function"s type.
>>>>
>>>> I'm unaware of build issues with Clang, hence can you clarify how Clang's
>>>> view comes into play here? In principle various attributes ought to be
>>>> part of a function's type; iirc that's also the case for gcc. Yet how
>>>> that matters to Eclair is still entirely unclear to me.
>>>>
>>>>> By removing the "noreturn"
>>>>> attribbute and replacing it with uses of the ASSERT_UNREACHABLE macro,
>>>>> these violations are addressed.
>>>>
>>>> Papered over, I'd say. What about release builds, for example?
>>>>
>>>> Deleting the attribute also has a clear downside documentation-wise. If
>>>> we really mean to remove them from what the compiler gets to see, I think
>>>> we ought to still retain them in commented-out shape.
>>>
>>> Another option would be to #define noreturn to nothing for ECLAIR builds ?
>>
>> That again would feel like papering over things. Plus I don't know if that's
>> an option at all.
> 
> What is "papering over" and what is a "nice solution" is often up to the
> personal opinions.
> 
> From my point of view, Alessandro's patch doesn't make the code worse.
> The ASSERT_UNREACHABLE solution is OK. I do agree with you that it
> should not be required for us to remove "noreturn", but I don't think we
> have used it consistently anyway across the Xen codebase.
> ASSERT_UNREACHABLE is also a form of documentation that the function
> does not return.
> 
> In conclusion, I think all three options are acceptable:
> 1) this patch as is
> 2) this patch plus /* noreturn */ as a comment
> 3) #define noreturn to nothing just for ECLAIR builds
> 
> I don't mind either way, maybe option 2) is the best compromise.

The variant with least impact on what we currently have (generated code
wise) is 3), though, which hence would be my preference (well, not exactly
a preference, but the least bad one).

Jan


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 10:26:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 10:26:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856526.1269115 (Exim 4.92)
	(envelope-from )
	id 1tM2sV-0004ks-DW; Fri, 13 Dec 2024 10:26:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856526.1269115; Fri, 13 Dec 2024 10:26: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 1tM2sV-0004kl-As; Fri, 13 Dec 2024 10:26:35 +0000
Received: by outflank-mailman (input) for mailman id 856526;
 Fri, 13 Dec 2024 10:26: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 1tM2sT-0004kf-M2
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 10:26:33 +0000
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com
 [2607:f8b0:4864:20::d32])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b7e5b6ad-b93c-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 11:26:31 +0100 (CET)
Received: by mail-io1-xd32.google.com with SMTP id
 ca18e2360f4ac-844dae6a0caso48270539f.1
 for ; Fri, 13 Dec 2024 02:26: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: b7e5b6ad-b93c-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734085590; x=1734690390; 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=R8Eo/2gPJP+l6AJHessDc20pqM3OY/WBTn7AI4vDpj8=;
        b=us6vVBn40Nsd6PIuh9D+uO76uMHF4v6KfgAGIep0Xf1BGQ/elJbtYpEcNDky+02F0X
         weypT3bq91dqH3WtkoLMy9HpsiTSF75lVN5VHrZIwvnWqhDK/gZCGh9C+Fz51pULxbUb
         TBQvaj1rcpKTHK8sdlWBd3T2CdS7ZMwgvSxai/8yA388dh/t1FbSWLY0GtAUdZ/49kW6
         S4xHHKxOSRmtz8aGUqDumQh2gWvxzhJ/Wq236mmhyBQSAd3Jz4Wc0PrfL0O+pX9pvz21
         /xLD0ATC3abnkZwK6M4alGiXuBvFhoEGLcrnz41MfisCf+DM/OYUkcDaeHr0hutwhceY
         AQ0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734085590; x=1734690390;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=R8Eo/2gPJP+l6AJHessDc20pqM3OY/WBTn7AI4vDpj8=;
        b=tjfsSQhdbEV+Vr2jd5w3FjzSk3ZJGZfaKv+w2WW6Pmg2Sq0fW1C4zl60NYibzYcTBm
         rmo7up+UYcoKbHW8Hyv+my4p5cIxDun0V4ceCaTurfToUvG1ygZn2xbCslphLSL9CToT
         Gsiwp5e4pXvvvnMf54LgO+8uoXJiZAaRBN1LK1wRErYJ6Cokj8KbA1Nw8fuz1XdqNAWQ
         CDjPTfklRjUtTKAtX/CWvJsg4OSZixUUVKvKX+i9MtL72UvPklnNAyGUISpjO1hgmJdY
         5T6lzqZ9QBhpq1MWm9M5qYSN5vfjSx9KMZ37qg9kCZQIIpONJsYC1Lh0w4dUjGVgJqV0
         Is8Q==
X-Forwarded-Encrypted: i=1; AJvYcCU0iY/TX6YXsf6ve2hQCpmLUZT9ZO0WdQ5kXF9FakgqCM2aWQ6xYv6bCA2o3H45ZDNPSrMyVH6uCew=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy6no+NWzzkpo+HABtdGHAmEKwZAaCQ81VTuVl84KE8ULFfRRls
	o5lALrHtMh8pT8Pz7awfX4t2jTPzXftjiioWCHdmeikx4TRAwkfnRon8AoxQDlJPyu+ZcxkDbpW
	BeIGTq4VqYdK9IatQgQLJQe6GFzdLd4TWRi9/Zw==
X-Gm-Gg: ASbGnctueOX3xDFtZBnKAnvkeWKVjaLyqo0DBkK4DFnBWSM+vQ4mqKuoPA2pd5SrN/o
	5JvuId9vhdzcR6rCELDsrLkqkW4rdOxWcDMwx6Q==
X-Google-Smtp-Source: AGHT+IEFuq9kOTmslWolPGMKz/2LwQw4wp9Xsk3qe8bK1FzV/ygBZH3lqUF7P36KttGF8D/oPKDTjMLRvzVnAJWVgxg=
X-Received: by 2002:a05:6e02:1c4d:b0:3a7:7a68:44e2 with SMTP id
 e9e14a558f8ab-3aff243f5acmr22965785ab.15.1734085589979; Fri, 13 Dec 2024
 02:26:29 -0800 (PST)
MIME-Version: 1.0
References: <20241202165921.249585-1-carlo.nonato@minervasys.tech>
 <20241202165921.249585-4-carlo.nonato@minervasys.tech> 
 <7ecc99c5-0cb5-4351-bede-cb03c9a4ac7e@xen.org> <293004fa-c87e-4a45-aa4c-b02456aaecea@amd.com>
 <0bacfdb6-d4ad-4dea-85d4-2851873dca4e@xen.org> 
  <2f834c6b-c9fa-4b95-abff-b9bcb8c70246@amd.com>
In-Reply-To: <2f834c6b-c9fa-4b95-abff-b9bcb8c70246@amd.com>
From: Carlo Nonato 
Date: Fri, 13 Dec 2024 11:26:19 +0100
Message-ID: 
Subject: Re: [PATCH v11 03/12] xen/arm: permit non direct-mapped Dom0 construction
To: Michal Orzel 
Cc: Andrea Bastoni , Julien Grall , 
	xen-devel@lists.xenproject.org, marco.solieri@minervasys.tech, 
	Stefano Stabellini , Bertrand Marquis , 
	Volodymyr Babchuk 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Michal,

On Fri, Dec 13, 2024 at 10:46=E2=80=AFAM Michal Orzel  wrote:
>
> Hi Carlo, Andrea,
>
> On 12/12/2024 19:22, Andrea Bastoni wrote:
> >
> >
> > On 12/12/2024 18:48, Carlo Nonato wrote:
> >> Hi,
> >>
> >> On Mon, Dec 9, 2024 at 8:17=E2=80=AFPM Julien Grall  w=
rote:
> >>>
> >>> Hi Michal,
> >>>
> >>> On 07/12/2024 15:04, Michal Orzel wrote:
> >>>>
> >>>>
> >>>> On 06/12/2024 19:37, Julien Grall wrote:
> >>>>>
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> Sorry for the late answer.
> >>>>>
> >>>>> On 05/12/2024 09:40, Michal Orzel wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 02/12/2024 17:59, Carlo Nonato wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> Cache coloring requires Dom0 not to be direct-mapped because of i=
ts non
> >>>>>>> contiguous mapping nature, so allocate_memory() is needed in this=
 case.
> >>>>>>> 8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a separ=
ate module")
> >>>>>>> moved allocate_memory() in dom0less_build.c. In order to use it
> >>>>>>> in Dom0 construction bring it back to domain_build.c and declare =
it in
> >>>>>>> domain_build.h.
> >>>>>>>
> >>>>>>> Take the opportunity to adapt the implementation of allocate_memo=
ry() so
> >>>>>>> that it uses the host layout when called on the hwdom, via
> >>>>>>> find_unallocated_memory().
> >>>>>>>
> >>>>>>> Signed-off-by: Carlo Nonato 
> >>>>>>> ---
> >>>>>>> v11:
> >>>>>>> - GUEST_RAM_BANKS instead of hardcoding the number of banks in al=
locate_memory()
> >>>>>>> - hwdom_ext_regions -> hwdom_free_mem in allocate_memory()
> >>>>>>> - added a comment in allocate_memory() when skipping small banks
> >>>>>>> v10:
> >>>>>>> - fixed a compilation bug that happened when dom0less support was=
 disabled
> >>>>>>> v9:
> >>>>>>> - no changes
> >>>>>>> v8:
> >>>>>>> - patch adapted to new changes to allocate_memory()
> >>>>>>> v7:
> >>>>>>> - allocate_memory() now uses the host layout when called on the h=
wdom
> >>>>>>> v6:
> >>>>>>> - new patch
> >>>>>>> ---
> >>>>>>>    xen/arch/arm/dom0less-build.c           | 44 -----------
> >>>>>>>    xen/arch/arm/domain_build.c             | 97 +++++++++++++++++=
+++++++-
> >>>>>>>    xen/arch/arm/include/asm/domain_build.h |  1 +
> >>>>>>>    3 files changed, 94 insertions(+), 48 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0les=
s-build.c
> >>>>>>> index d93a85434e..67b1503647 100644
> >>>>>>> --- a/xen/arch/arm/dom0less-build.c
> >>>>>>> +++ b/xen/arch/arm/dom0less-build.c
> >>>>>>> @@ -49,50 +49,6 @@ bool __init is_dom0less_mode(void)
> >>>>>>>        return ( !dom0found && domUfound );
> >>>>>>>    }
> >>>>>>>
> >>>>>>> -static void __init allocate_memory(struct domain *d, struct kern=
el_info *kinfo)
> >>>>>>> -{
> >>>>>>> -    struct membanks *mem =3D kernel_info_get_mem(kinfo);
> >>>>>>> -    unsigned int i;
> >>>>>>> -    paddr_t bank_size;
> >>>>>>> -
> >>>>>>> -    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for =
%pd:\n",
> >>>>>>> -           /* Don't want format this as PRIpaddr (16 digit hex) =
*/
> >>>>>>> -           (unsigned long)(kinfo->unassigned_mem >> 20), d);
> >>>>>>> -
> >>>>>>> -    mem->nr_banks =3D 0;
> >>>>>>> -    bank_size =3D MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem);
> >>>>>>> -    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM0_BA=
SE),
> >>>>>>> -                               bank_size) )
> >>>>>>> -        goto fail;
> >>>>>>> -
> >>>>>>> -    bank_size =3D MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem);
> >>>>>>> -    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM1_BA=
SE),
> >>>>>>> -                               bank_size) )
> >>>>>>> -        goto fail;
> >>>>>>> -
> >>>>>>> -    if ( kinfo->unassigned_mem )
> >>>>>>> -        goto fail;
> >>>>>>> -
> >>>>>>> -    for( i =3D 0; i < mem->nr_banks; i++ )
> >>>>>>> -    {
> >>>>>>> -        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpadd=
r" (%ldMB)\n",
> >>>>>>> -               d,
> >>>>>>> -               i,
> >>>>>>> -               mem->bank[i].start,
> >>>>>>> -               mem->bank[i].start + mem->bank[i].size,
> >>>>>>> -               /* Don't want format this as PRIpaddr (16 digit h=
ex) */
> >>>>>>> -               (unsigned long)(mem->bank[i].size >> 20));
> >>>>>>> -    }
> >>>>>>> -
> >>>>>>> -    return;
> >>>>>>> -
> >>>>>>> -fail:
> >>>>>>> -    panic("Failed to allocate requested domain memory."
> >>>>>>> -          /* Don't want format this as PRIpaddr (16 digit hex) *=
/
> >>>>>>> -          " %ldKB unallocated. Fix the VMs configurations.\n",
> >>>>>>> -          (unsigned long)kinfo->unassigned_mem >> 10);
> >>>>>>> -}
> >>>>>>> -
> >>>>>>>    #ifdef CONFIG_VGICV2
> >>>>>>>    static int __init make_gicv2_domU_node(struct kernel_info *kin=
fo)
> >>>>>>>    {
> >>>>>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_bu=
ild.c
> >>>>>>> index 2c30792de8..2b8cba9b2f 100644
> >>>>>>> --- a/xen/arch/arm/domain_build.c
> >>>>>>> +++ b/xen/arch/arm/domain_build.c
> >>>>>>> @@ -416,7 +416,6 @@ static void __init allocate_memory_11(struct =
domain *d,
> >>>>>>>        }
> >>>>>>>    }
> >>>>>>>
> >>>>>>> -#ifdef CONFIG_DOM0LESS_BOOT
> >>>>>>>    bool __init allocate_domheap_memory(struct domain *d, paddr_t =
tot_size,
> >>>>>>>                                        alloc_domheap_mem_cb cb, v=
oid *extra)
> >>>>>>>    {
> >>>>>>> @@ -508,7 +507,6 @@ bool __init allocate_bank_memory(struct kerne=
l_info *kinfo, gfn_t sgfn,
> >>>>>>>
> >>>>>>>        return true;
> >>>>>>>    }
> >>>>>>> -#endif
> >>>>>>>
> >>>>>>>    /*
> >>>>>>>     * When PCI passthrough is available we want to keep the
> >>>>>>> @@ -1003,6 +1001,94 @@ out:
> >>>>>>>        return res;
> >>>>>>>    }
> >>>>>>>
> >>>>>>> +void __init allocate_memory(struct domain *d, struct kernel_info=
 *kinfo)
> >>>>>>> +{
> >>>>>>> +    struct membanks *mem =3D kernel_info_get_mem(kinfo);
> >>>>>>> +    unsigned int i, nr_banks =3D GUEST_RAM_BANKS;
> >>>>>>> +    paddr_t bank_start, bank_size;
> >>>>>> Limit the scope
> >>>>>>
> >>>>>>> +    struct membanks *hwdom_free_mem =3D NULL;
> >>>>>>> +    const uint64_t bankbase[] =3D GUEST_RAM_BANK_BASES;
> >>>>>>> +    const uint64_t banksize[] =3D GUEST_RAM_BANK_SIZES;
> >>>>>> Limit the scope
> >>>>>>
> >>>>>>> +
> >>>>>>> +    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for =
%pd:\n",
> >>>>>>> +           /* Don't want format this as PRIpaddr (16 digit hex) =
*/
> >>>>>>> +           (unsigned long)(kinfo->unassigned_mem >> 20), d);
> >>>>>>> +
> >>>>>>> +    mem->nr_banks =3D 0;
> >>>>>>> +    /*
> >>>>>>> +     * Use host memory layout for hwdom. Only case for this is w=
hen LLC coloring
> >>>>>>> +     * is enabled.
> >>>>>>> +     */
> >>>>>>> +    if ( is_hardware_domain(d) )
> >>>>>>> +    {
> >>>>>>> +        ASSERT(llc_coloring_enabled);
> >>>>>> This patch does not build because of declaration not being visible=
. You must include .
> >>>>>
> >>>>> Piggying back on this comment. AFAICT, the code below would work al=
so in
> >>>>> the non cache coloring case. So what's the assert is for?
> >>>>>
> >>>>>>
> >>>>>>> +
> >>>>>>> +        hwdom_free_mem =3D xzalloc_flex_struct(struct membanks, =
bank,
> >>>>>>> +                                             NR_MEM_BANKS);
> >>>>>>> +        if ( !hwdom_free_mem )
> >>>>>>> +            goto fail;
> >>>>>>> +
> >>>>>>> +        hwdom_free_mem->max_banks =3D NR_MEM_BANKS;
> >>>>>>> +
> >>>>>>> +        if ( find_unallocated_memory(kinfo, hwdom_free_mem) )
> >>>>>> My remarks for the use of find_unallocated_memory() 1:1 have not b=
een addressed. You did not even
> >>>>>> change the comments inside the function. The problem is that the f=
unction is specifically designed
> >>>>>> for finding extended regions and assumes being called at certain p=
oint i.e. dom0 RAM allocated, gnttab
> >>>>>> region allocated, etc.
> >>>>>
> >>>>> So I agree that the function should be updated if we plan to use it=
 for
> >>>>> other purpose.
> >>>>>
> >>>>> My opinion is that we should attempt to make the function generic s=
o
> >>>>> that in your
> >>>>>> case you can choose which regions to exclude, define even your own=
 function to grab free regions (at the moment
> >>>>>> add_ext_regions grabs banks >=3D 64M but you still discards banks =
>=3D 128M, so it's a bit wasteful.
> >>>>>>
> >>>>>> My very short attempt to make the function as generic as possible =
in the first iteration:
> >>>>>> https://paste.debian.net/1338334/
> >>>>>
> >>>>> This looks better, but I wonder why we need still need to exclude t=
he
> >>>>> static regions? Wouldn't it be sufficient to exclude just reserved =
regions?
> >>>> Static shared memory banks are not part of reserved memory (i.e. boo=
tinfo.reserved_mem) if that's what you're asking.
> >>>> They are stored in bootinfo.shmem, hence we need to take them into a=
ccount when searching for unused address space.
> >>>
> >>> Oh I missed the fact you now pass "mem_banks" as a parameter. I thoug=
ht
> >>> they would still get excluded for cache coloring case.
> >>>
> >>>>
> >>>> If you and Carlo are ok with my proposed solution for making the fun=
ction generic, I can send a patch as a prerequisite
> >>>> patch for Carlo series.
> >>>
> >>> I am fine with the approach.
> >>>
> >>> Cheers,
> >>>
> >>> --
> >>> Julien Grall
> >>>
> >>
> >>> @@ -2152,7 +2238,10 @@ static int __init construct_dom0(struct domain=
 *d)
> >>>      /* type must be set before allocate_memory */
> >>>      d->arch.type =3D kinfo.type;
> >>>  #endif
> >>> -    allocate_memory_11(d, &kinfo);
> >>> +    if ( is_domain_direct_mapped(d) )
> >>> +        allocate_memory_11(d, &kinfo);
> >>> +    else
> >>> +        allocate_memory(d, &kinfo);
> >>>      find_gnttab_region(d, &kinfo);
> >>
> >> Since find_gnttab_region() is called after allocate_memory(), kinfo->g=
nttab_*
> >> fields aren't initialized and the call to find_unallocated_memory() wi=
th
> >> gnttab as the region to exclude, fails ending in a crash since memory =
for
> >> dom0 can't be allocated.
> >>
> >> Can the solution be to call find_gnttab_region() before the above if?
> >
> > The function is called find, but currently it only initializes kinfo->g=
nttab_start
> > and kinfo->gnttab_size and we tested that moving it before allocate_mem=
ory* doesn't
> > cause fallouts.
> >
> > If moving before allocate_memory*, would it be better to rename it e.g.=
, init_gnttab_region()?
> >
> > Thanks,
> > Andrea
> >
> >> Or should I just call it before allocate_memory() in one case, but sti=
ll after
> >> allocate_memory_11() in the other?
> >>
> >> Thanks.
> >
>
> AFAICT there is nothing stopping us from moving find_gnttab_region() befo=
re allocate_*. This function initializes
> gnttab region with PA of Xen. In normal case, because Xen is added as boo=
tmodule, it will never be mapped in dom0 memory map
> and the placement does not matter. In LLC case, it will point to relocate=
d address of Xen and it needs to be known before
> calling find_unallocated_memory. Don't rename it, leave as is, just move =
before allocate_*.
>
> @Carlo:
> My prerequisite patch has been merged, so you're good to respin a series =
(unless you wait for some feedback in which case do let me know).
> To prevent too many respins, you're going to call find_unallocated_memory=
 for LLC passing resmem and gnttab to be excluded. If you're going
> to reuse add_ext_regions, you need to rename it and fix comments to make =
it more generic. As for the size, the decision is yours. One solution
> would be to modify add_ext_regions to take min bank size as parameter (64=
MB for extended regions, X for LLC dom0). In your code, you write that
> the first bank must contain dom0, dtb, ramdisk and you chose 128MB. Howev=
er, looking at the code, you seem to discard banks < 128 for all the banks,
> not only for the first one. This is the part that I don't have a ready so=
lution. Maybe you could define your own add_free_region function and sort
> the banks, so that you take the largest possible bank first for dom0. Thi=
s could simplify things.

For the moment I added a __add_ext_regions() helper that also takes a skip_=
size
parameter. This is called by add_ext_regions() and by a new
add_hwdom_free_regions() callback used in allocate_memory().
I still use 128MB for all the banks. Do you think this is acceptable, maybe
with a FIXME comment cause we should skip only the first bank, or not?

> You can also ask others for opinion.
>
> We are approaching Dec 20th deadline, and I want this series to be in as =
it's been on the list for too many years. I'm willing to accept a sub-optim=
al solution
> (so far will be used only for LLC, and LLC as experimental feature will b=
e the only victim of not optimal algorithm) for now, and we can think of a =
better one
> after the release. But still, even the sub-optimal solution must make sen=
se.
>
> ~Michal
>

Thanks.


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 10:31:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 10:31:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856540.1269125 (Exim 4.92)
	(envelope-from )
	id 1tM2wp-0006X2-1M; Fri, 13 Dec 2024 10:31:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856540.1269125; Fri, 13 Dec 2024 10:31: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 1tM2wo-0006Wv-Tq; Fri, 13 Dec 2024 10:31:02 +0000
Received: by outflank-mailman (input) for mailman id 856540;
 Fri, 13 Dec 2024 10:31: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 1tM2wm-0006Wp-Ub
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 10:31:01 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 57004528-b93d-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 11:30:59 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id EEA0D5C6B59;
 Fri, 13 Dec 2024 10:30:13 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 65922C4CED0;
 Fri, 13 Dec 2024 10:30:44 +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: 57004528-b93d-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1734085855;
	bh=BTQhG+pcPpVWdFU7M6WGNSEHiOAWlPk9OMovbRGe8jk=;
	h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
	b=KwAmFDLewAK8qtG2JcgTDln5oAPvX7T6s21n+sVrQK/zovEQltlKTZMfOOydVCYBZ
	 wexQmXSVYI3h7TBHmpxxuKJCAtIKDA3xJNa8/Im/UBR7LXeWQh180GN2AD0v8T0VFC
	 xau4jIIld3rUWglJe0O5Ly1c3n+LVRPKkn4Ap2bFPikm9rfX1t0FvFxCEdhmOO7GmQ
	 T1Kv1o7hm5xTuEGg8jC3v4laVOub2r/1lqEAAYkD9VqHdQWO6/vYMu4tQswLjScRFC
	 qcBNgWj6+WXQRdmWrvKriaNXsmUfp6QHYu1lvvdq1sD36YHJ/Kyex37L0CjkCkv8o5
	 SYIrwECkF64TQ==
From: Kalle Valo 
To: Bjorn Helgaas 
Cc: Philipp Stanner ,  Igor Mitsyanko
 ,  amien Le Moal ,  Niklas
 Cassel ,  Basavaraj Natikar
 ,  Jiri Kosina ,  Benjamin
 Tissoires ,  Arnd Bergmann ,  Sergey
 Matyukevich ,  Greg Kroah-Hartman
 ,  Alex Dubov ,  Sudarsana
 Kalluru ,  Manish Chopra ,
  Andrew Lunn ,  "David S. Miller"
 ,  Eric Dumazet ,  Jakub
 Kicinski ,  Paolo Abeni ,  Rasesh Mody
 ,  GR-Linux-NIC-Dev@marvell.com,  Sanjay R Mehta
 ,  Shyam Sundar S K ,  Jon
 Mason ,  Dave Jiang ,  Allen Hubbe
 ,  Bjorn Helgaas ,  Alex
 Williamson ,  Juergen Gross ,
  Stefano Stabellini ,  Oleksandr Tyshchenko
 ,  Mario Limonciello
 ,  Chen Ni ,  Ricky Wu
 ,  Al Viro ,  Breno Leitao
 ,  Thomas Gleixner ,  Kevin Tian
 ,  Andy Shevchenko
 ,  Mostafa Saleh ,
  Jason Gunthorpe ,  Yi Liu ,  Kunwu Chan
 ,  Dan Carpenter ,  "Dr.
 David Alan Gilbert" ,  Ankit Agrawal
 ,  Reinette Chatre ,  Eric
 Auger ,  Ye Bin ,
  linux-ide@vger.kernel.org,  linux-kernel@vger.kernel.org,
  linux-input@vger.kernel.org,  netdev@vger.kernel.org,
  linux-wireless@vger.kernel.org,  ntb@lists.linux.dev,
  linux-pci@vger.kernel.org,  kvm@vger.kernel.org,
  xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 09/11] wifi: qtnfmac: use always-managed version of
 pcim_intx()
References: <20241212192935.GA3360239@bhelgaas>
Date: Fri, 13 Dec 2024 12:30:42 +0200
In-Reply-To: <20241212192935.GA3360239@bhelgaas> (Bjorn Helgaas's message of
	"Thu, 12 Dec 2024 13:29:35 -0600")
Message-ID: <87cyhvoox9.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain

Bjorn Helgaas  writes:

> [cc->to: Igor]
>
> On Mon, Dec 09, 2024 at 02:06:31PM +0100, Philipp Stanner wrote:
>> pci_intx() is a hybrid function which can sometimes be managed through
>> devres. To remove this hybrid nature from pci_intx(), it is necessary to
>> port users to either an always-managed or a never-managed version.
>> 
>> qtnfmac enables its PCI-Device with pcim_enable_device(). Thus, it needs
>> the always-managed version.
>> 
>> Replace pci_intx() with pcim_intx().
>> 
>> Signed-off-by: Philipp Stanner 
>> Acked-by: Kalle Valo 
>
> Hoping for an ack from Igor, too.

Igor hasn't been around for a while so I'm not expecting see an ack from
him, I think the whole qtnfmac driver should be removed in the future.
Feel free to take the patch as is.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 10:51:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 10:51:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856555.1269135 (Exim 4.92)
	(envelope-from )
	id 1tM3GL-0001Mg-KD; Fri, 13 Dec 2024 10:51:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856555.1269135; Fri, 13 Dec 2024 10:51: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 1tM3GL-0001MZ-HC; Fri, 13 Dec 2024 10:51:13 +0000
Received: by outflank-mailman (input) for mailman id 856555;
 Fri, 13 Dec 2024 10:51: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 1tM3GK-0001MS-80
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 10:51:12 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id 26ed9ab1-b940-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 11:51:05 +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 1CDB711FB;
 Fri, 13 Dec 2024 02:51:33 -0800 (PST)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 281263F720;
 Fri, 13 Dec 2024 02:51: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: 26ed9ab1-b940-11ef-a0d6-8be0dac302b0
From: Luca Fancellu 
To: xen-devel@lists.xenproject.org
Cc: Penny Zheng ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Penny Zheng ,
	Wei Chen 
Subject: [PATCH v7] xen/arm: Check for Static Heap feature when freeing resources
Date: Fri, 13 Dec 2024 10:50:47 +0000
Message-Id: <20241213105047.3043403-1-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Penny Zheng 

If the Xen heap is statically configured in Device Tree, its size is
definite, so only the defined memory shall be given to the boot
allocator. Have a check where init_domheap_pages() is called
which takes into account if static heap feature is used.

Extract static_heap flag from init data bootinfo, as it will be needed
after destroying the init data section, rename it to using_static_heap
and use it to tell whether the Xen static heap feature is enabled.

Signed-off-by: Penny Zheng 
Signed-off-by: Wei Chen 
Signed-off-by: Luca Fancellu 
Reviewed-by: Michal Orzel 
---
Changes from v6:
 - fix issue in discard_initial_modules that prevented remove_early_mappings
   to be called (Michal)
 - Modify code in kernel_decompress to exit early (Michal)
 - Add R-by Michal
Changes from v5:
 - Drop Jan R-by due to the code changes
 - Static heap is not dependent on static memory, so delete #ifdefs
   for CONFIG_STATIC_MEMORY
Changes from v4:
 - Add R-by Jan
 - Changed code to reduce nesting in discard_initial_modules (Julien)
Changes from v3:
 - Removed helper using_static_heap(), renamed static_heap variable
   to using_static_heap and simplified #ifdef-ary (Jan suggestion)
Changes from v2:
 - Change xen_is_using_staticheap() to using_static_heap()
 - Move declaration of static_heap to xen/mm.h and import that in
   bootfdt.h
 - Reprased first part of the commit message
Changes from v1:
 - moved static_heap to common/page_alloc.c
 - protect static_heap access with CONFIG_STATIC_MEMORY
 - update comment in arm/kernel.c kernel_decompress()
---
---
 xen/arch/arm/arm32/mmu/mm.c       | 4 ++--
 xen/arch/arm/kernel.c             | 7 +++++++
 xen/arch/arm/mmu/setup.c          | 8 ++++++--
 xen/arch/arm/setup.c              | 8 ++++++++
 xen/common/device-tree/bootfdt.c  | 2 +-
 xen/common/device-tree/bootinfo.c | 2 +-
 xen/common/page_alloc.c           | 3 +++
 xen/include/xen/bootfdt.h         | 1 -
 xen/include/xen/mm.h              | 2 ++
 9 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/arm32/mmu/mm.c b/xen/arch/arm/arm32/mmu/mm.c
index 063611412be0..0824d61323b5 100644
--- a/xen/arch/arm/arm32/mmu/mm.c
+++ b/xen/arch/arm/arm32/mmu/mm.c
@@ -199,7 +199,7 @@ void __init setup_mm(void)
 
     total_pages = ram_size >> PAGE_SHIFT;
 
-    if ( bootinfo.static_heap )
+    if ( using_static_heap )
     {
         const struct membanks *reserved_mem = bootinfo_get_reserved_mem();
 
@@ -246,7 +246,7 @@ void __init setup_mm(void)
 
     do
     {
-        e = bootinfo.static_heap ?
+        e = using_static_heap ?
             fit_xenheap_in_static_heap(pfn_to_paddr(xenheap_pages), MB(32)) :
             consider_modules(ram_start, ram_end,
                              pfn_to_paddr(xenheap_pages),
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 293d7efaed9c..80fad8b3362c 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -235,6 +235,13 @@ static __init int kernel_decompress(struct bootmodule *mod, uint32_t offset)
     for ( ; i < (1 << kernel_order_out); i++ )
         free_domheap_page(pages + i);
 
+    /*
+     * When using static heap feature, don't give bootmodules memory back to
+     * the heap allocator
+     */
+    if ( using_static_heap )
+        return 0;
+
     /*
      * When freeing the kernel, we need to pass the module start address and
      * size as they were before taking an offset to gzip header into account,
diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c
index 9664e85ee6c0..8c87649bc88e 100644
--- a/xen/arch/arm/mmu/setup.c
+++ b/xen/arch/arm/mmu/setup.c
@@ -341,8 +341,12 @@ void free_init_memory(void)
     if ( rc )
         panic("Unable to remove the init section (rc = %d)\n", rc);
 
-    init_domheap_pages(pa, pa + len);
-    printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10);
+    if ( !using_static_heap )
+    {
+        init_domheap_pages(pa, pa + len);
+        printk("Freed %ldkB init memory.\n",
+               (long)(__init_end-__init_begin) >> 10);
+    }
 }
 
 /**
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 2e27af4560a5..545702d8a32d 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -206,6 +206,13 @@ void __init discard_initial_modules(void)
     struct bootmodules *mi = &bootinfo.modules;
     int i;
 
+    /*
+     * When using static heap feature, don't give bootmodules memory back to
+     * the heap allocator
+     */
+    if ( using_static_heap )
+        goto out;
+
     for ( i = 0; i < mi->nr_mods; i++ )
     {
         paddr_t s = mi->module[i].start;
@@ -223,6 +230,7 @@ void __init discard_initial_modules(void)
 
     mi->nr_mods = 0;
 
+ out:
     remove_early_mappings();
 }
 
diff --git a/xen/common/device-tree/bootfdt.c b/xen/common/device-tree/bootfdt.c
index fc93d86e8232..47386d4fffea 100644
--- a/xen/common/device-tree/bootfdt.c
+++ b/xen/common/device-tree/bootfdt.c
@@ -410,7 +410,7 @@ static int __init process_chosen_node(const void *fdt, int node,
         if ( rc )
             return rc;
 
-        bootinfo.static_heap = true;
+        using_static_heap = true;
     }
 
     printk("Checking for initrd in /chosen\n");
diff --git a/xen/common/device-tree/bootinfo.c b/xen/common/device-tree/bootinfo.c
index 0daf5e941a51..76d652c0de0b 100644
--- a/xen/common/device-tree/bootinfo.c
+++ b/xen/common/device-tree/bootinfo.c
@@ -407,7 +407,7 @@ void __init populate_boot_allocator(void)
     const struct membanks *reserved_mem = bootinfo_get_reserved_mem();
     paddr_t s, e;
 
-    if ( bootinfo.static_heap )
+    if ( using_static_heap )
     {
         for ( i = 0 ; i < reserved_mem->nr_banks; i++ )
         {
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 92abed6514b4..1f424333db27 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -165,6 +165,9 @@
 #define PGT_TYPE_INFO_INITIALIZER 0
 #endif
 
+/* Flag saved when Xen is using the static heap feature */
+bool __ro_after_init using_static_heap;
+
 unsigned long __read_mostly max_page;
 unsigned long __read_mostly total_pages;
 paddr_t __ro_after_init mem_hotplug;
diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
index 343c48b73d2c..c8bbfd8979b2 100644
--- a/xen/include/xen/bootfdt.h
+++ b/xen/include/xen/bootfdt.h
@@ -139,7 +139,6 @@ struct bootinfo {
 #ifdef CONFIG_STATIC_SHM
     struct shared_meminfo shmem;
 #endif
-    bool static_heap;
 };
 
 #ifdef CONFIG_ACPI
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index d7dcf0f06330..16f733281af3 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -72,6 +72,8 @@
 
 struct page_info;
 
+extern bool using_static_heap;
+
 void put_page(struct page_info *page);
 bool __must_check get_page(struct page_info *page,
                            const struct domain *domain);
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 10:56:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 10:56:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856565.1269145 (Exim 4.92)
	(envelope-from )
	id 1tM3LJ-0001xW-5S; Fri, 13 Dec 2024 10:56:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856565.1269145; Fri, 13 Dec 2024 10:56: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 1tM3LJ-0001xP-20; Fri, 13 Dec 2024 10:56:21 +0000
Received: by outflank-mailman (input) for mailman id 856565;
 Fri, 13 Dec 2024 10:56: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 1tM3LH-0001xJ-GE
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 10:56:19 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20609.outbound.protection.outlook.com
 [2a01:111:f403:2009::609])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e07a925f-b940-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 11:56:16 +0100 (CET)
Received: from MN2PR19CA0065.namprd19.prod.outlook.com (2603:10b6:208:19b::42)
 by SA1PR12MB6996.namprd12.prod.outlook.com (2603:10b6:806:24f::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.15; Fri, 13 Dec
 2024 10:56:11 +0000
Received: from BL6PEPF0001AB53.namprd02.prod.outlook.com
 (2603:10b6:208:19b:cafe::91) by MN2PR19CA0065.outlook.office365.com
 (2603:10b6:208:19b::42) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.16 via Frontend Transport; Fri,
 13 Dec 2024 10:56:11 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL6PEPF0001AB53.mail.protection.outlook.com (10.167.241.5) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Fri, 13 Dec 2024 10:56:11 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) 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, 13 Dec
 2024 04:56:10 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) 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; Fri, 13 Dec
 2024 04:56:10 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 13 Dec 2024 04:56:08 -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: e07a925f-b940-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=tqcb36BAdcEKwrOZNM+mslTtACGwSAB6gDvMVVef0aqeXQzdAXxvkmKDMpZDB8Ve2Pp33aTt38lm52+uXnEHry1TIgoKUr+fSyNVT4gNuwjQYEoHgwl8DC8kxbjp5bn7H7X6uStEoKeMrmvWC9ec2xy+l7hcGMdLgdkc5nh0d5MwdNhNNPtIS07AXsLh+qjyDfeH5XvohqHbr99cGM3HUs6cwpaLVGYJP9i3fbblMAt9/s0x8iLmT1gmhSZmyVk2r4a2APyznrYV5kmkoyXsGeAwxAVmPX3Wuc48qyrgn07WYkJ/CWk1GaiR4QnEf16VkcXRC46l8i/vTpeEVPb3+w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=nFTcJje/qsnKaootPSjYtmkLjoDjXis11H3T1nTyEhs=;
 b=H2+H8Rf+UIrYW8TDv4VhW5FfAwyJjHpqz0n9Pedu1jt9qHNxe5bqNZY3VEoTnHsPZNhvhA/TpE6w3VzUlExzzPufgKbqTnLQWfHSmM6UYzDHk8PdQmKpNprT6uXucOLd7dADWFOkueaYPr4KhooYyPL1VW/xluEpHo09CzwI4+u35+kpG4b9EibioqrQ1+9Jb3ljTw11RaPb2l4FCICiNVWOAxPrXeryuzUqwlVFdHYc3CaRWQ2eby52BqK8NKDHtamuntJtWnnq3WqLmGRwH44topw6wHWJZP85f0dDog/53FdgE4Vh9K1+q5E/vGhjmXD7ymTAn7LJOKkYPvrhrQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=minervasys.tech smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=nFTcJje/qsnKaootPSjYtmkLjoDjXis11H3T1nTyEhs=;
 b=Nxw7l5p6pF5mK0IKfpPXgzWT2WCMryEvaOUdEIyJ1H8xTXuxQC3B41lxm5eEpio4NrOdyJ57EM9vROISTdLGBzl6DJSwilyivbA2yD72DfdCQwm9FQ6OZ4BnTat+eDQu9HGMisg3c7iVG42XiHj1V5bpdmgtXHvLKpLzzlS4nPc=
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=SATLEXMB04.amd.com; pr=C
Message-ID: <6cb8c273-8e1d-4f34-adcc-620d4a71340c@amd.com>
Date: Fri, 13 Dec 2024 11:56:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v11 03/12] xen/arm: permit non direct-mapped Dom0
 construction
To: Carlo Nonato 
CC: Andrea Bastoni , Julien Grall
	, ,
	, Stefano Stabellini ,
	Bertrand Marquis , Volodymyr Babchuk
	
References: <20241202165921.249585-1-carlo.nonato@minervasys.tech>
 <20241202165921.249585-4-carlo.nonato@minervasys.tech>
 
 <7ecc99c5-0cb5-4351-bede-cb03c9a4ac7e@xen.org>
 <293004fa-c87e-4a45-aa4c-b02456aaecea@amd.com>
 <0bacfdb6-d4ad-4dea-85d4-2851873dca4e@xen.org>
 
 
 <2f834c6b-c9fa-4b95-abff-b9bcb8c70246@amd.com>
 
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB53:EE_|SA1PR12MB6996:EE_
X-MS-Office365-Filtering-Correlation-Id: e4a8e4ef-a8c0-4fce-4394-08dd1b64c167
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?WkVnS01XUGFSY2VPdG9GNVd6Q2JHazcvRUFHNlFVQjQzR0Ryb2NJZ0tRY1ps?=
 =?utf-8?B?RjFzTjZabEhLdW9VTjdBdHoxcUhISkNaVnk0eGVLOFA0QXRHY2x3SWtaZWhk?=
 =?utf-8?B?M3RjY0NqOStVNDVreWg5a2k0U1dsaSt1WTNLZVF2eEJhMVkydXJrMFlFVnFV?=
 =?utf-8?B?bkpsMmEwcmZhTFpQeGpRSUZmMng1RkczRWlSWnNsVzJRc2hIcEk0S0ozRXZl?=
 =?utf-8?B?cnorTHF6S21sSFppaFV4T2RXbzZoMmQwbFA0RjE1Q3JscjZ5b1VSZzBldFN6?=
 =?utf-8?B?bm91c0NjejFoRUVqdEo2NE1QWmVZQWRCOXJrRldvL3R2dE1GeDNELzIzcS9t?=
 =?utf-8?B?aFVET2tyQTN6MHdMejFQeURURFl0dVZITWdKd25FSzBoWktIdnlISTRCYnpI?=
 =?utf-8?B?TU55RFdMdXUzNFBDMGZ0MUJtNjNVY1RVUU5KejFDNDFiVzdBRW5qalJ5UmJF?=
 =?utf-8?B?eEdkRWUvaUwzYW95ODY3azNBWEZwSmFDSDhkc3UwUmdHTkFYa2VNNGpWM09G?=
 =?utf-8?B?bzhaYmlmNnVWVGgxenkzbW9Sdzd6WmhpczFjTTVucGsvRmlocWJLL0NrSkor?=
 =?utf-8?B?OElMT1RNZmMzOHZwQUJaVmJiaEtwb2pRODh3dlU3S2NqTGZYWmhrKzBKYU1V?=
 =?utf-8?B?clZkM2pyWUo4TU1CNmZWZ280eGEzRElFQ1FQRDJnNDhaNExhbE50bzlhYzIx?=
 =?utf-8?B?bVNZcWFkOUdVTnZkUTQxRG85dTNiOXppNUt4MnU2WStvZ3NNZXFqTEJETmU1?=
 =?utf-8?B?Ulk5REY4Rjh5ZlhBam0vTGhNZVNBdWNSWmhONXdpS3VoRzdwRUhRYUUvR3Rj?=
 =?utf-8?B?RWpyZFcwMWcvMWN1NXowUGJnUDAzc0dQYzhYa2gvc2dyc1I0SklzWWFmVGFN?=
 =?utf-8?B?NU5mY3p6cjlySnluZ2xlb0M2SGg5d0Q1bkpoQm16SmE0emlLcEZzUlNnQnZP?=
 =?utf-8?B?M2M1eElEREhsZzBPbTBRdnJsZk1YZUxtb0lGNU15T1RQUFcwZU9PMDVSd0Zv?=
 =?utf-8?B?OFN6VTVKVlNXWWd2QjdnWmVDYXFTM01jakhDMUlFMGtCR2pyL3VaVm43WExO?=
 =?utf-8?B?aDI4aGtXbnVuaXRLMGhqL21vZTE3NTF6c3VsaEs1cEFHR2JoNVUxTmNjeitS?=
 =?utf-8?B?Qm5BZ1EwdEJiSGtjekh3aWczU0lycmpCSFljT1V2RTRkc3NHN0NxdnZ1VlpJ?=
 =?utf-8?B?OUZHVU5XUWtNQjdUTmhMZTd0ZVpSS01rbEQvTWpsVk5MckM5c0pTOUZVYk1I?=
 =?utf-8?B?RDdnazArQjZCcjZHNmM2M2NuWEFjRmc0YmxCTllVTFNsaXhOT2tPcHluSW1s?=
 =?utf-8?B?MG5PbC9QdGwvMU5YcFZnYVRPRytPT0xQRkZ1Yk1PYlZSSkpjaEtkck5jdlZ1?=
 =?utf-8?B?MllMWG5ZOG1KQzNGQWNKaXdHeUVQLzZaenNSR25qK253NFNFVi9HTDY5b3BV?=
 =?utf-8?B?OHFZT3k5eW1UM1JqbUdMVnFNS2U1M0ZhWSt6MUY2UWhwblorbXU2SUVoeVV3?=
 =?utf-8?B?b2lFNEduaWsxVVcwNHN1ZkIxWmFqSHJxT3FDcnBWTS9yTjFscGNUL3J4S3dV?=
 =?utf-8?B?aHdIa0VhVlNjNzJXWmJrKy9Ma1JtQVA1dlRleDJEZ1FITTlCL0tCT1RvZG5p?=
 =?utf-8?B?M3JIeTg2RWVPenFDaUR1RHdZSndzT3FDNldmcFBkSjhNUElVMXgyQ3A5NWxk?=
 =?utf-8?B?Nk1WRzJUTHhPUEVta3BMNEE0cVQrVENFMFFGT2l6R0k1aXJYYXh6dFJCZSsv?=
 =?utf-8?B?bGNRcWprNm5TQVQ5R25vMWUyMHBjcGVMNHByaGdrZE5CVFpyS1ZySHpwaFdl?=
 =?utf-8?B?QWgvVFo4ZmQrVFFsUmowM0liOHpnZ2p4MTQ0ZU50d3NKMUJVREpCSU0xbWw4?=
 =?utf-8?B?YWROQkgxTkxMekFVbURTa1ZYbjNCNktoSkpmQldnSmVTWXc9PQ==?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2024 10:56:11.1146
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e4a8e4ef-a8c0-4fce-4394-08dd1b64c167
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL6PEPF0001AB53.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB6996



On 13/12/2024 11:26, Carlo Nonato wrote:
> 
> 
> Hi Michal,
> 
> On Fri, Dec 13, 2024 at 10:46 AM Michal Orzel  wrote:
>>
>> Hi Carlo, Andrea,
>>
>> On 12/12/2024 19:22, Andrea Bastoni wrote:
>>>
>>>
>>> On 12/12/2024 18:48, Carlo Nonato wrote:
>>>> Hi,
>>>>
>>>> On Mon, Dec 9, 2024 at 8:17 PM Julien Grall  wrote:
>>>>>
>>>>> Hi Michal,
>>>>>
>>>>> On 07/12/2024 15:04, Michal Orzel wrote:
>>>>>>
>>>>>>
>>>>>> On 06/12/2024 19:37, Julien Grall wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Sorry for the late answer.
>>>>>>>
>>>>>>> On 05/12/2024 09:40, Michal Orzel wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 02/12/2024 17:59, Carlo Nonato wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cache coloring requires Dom0 not to be direct-mapped because of its non
>>>>>>>>> contiguous mapping nature, so allocate_memory() is needed in this case.
>>>>>>>>> 8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a separate module")
>>>>>>>>> moved allocate_memory() in dom0less_build.c. In order to use it
>>>>>>>>> in Dom0 construction bring it back to domain_build.c and declare it in
>>>>>>>>> domain_build.h.
>>>>>>>>>
>>>>>>>>> Take the opportunity to adapt the implementation of allocate_memory() so
>>>>>>>>> that it uses the host layout when called on the hwdom, via
>>>>>>>>> find_unallocated_memory().
>>>>>>>>>
>>>>>>>>> Signed-off-by: Carlo Nonato 
>>>>>>>>> ---
>>>>>>>>> v11:
>>>>>>>>> - GUEST_RAM_BANKS instead of hardcoding the number of banks in allocate_memory()
>>>>>>>>> - hwdom_ext_regions -> hwdom_free_mem in allocate_memory()
>>>>>>>>> - added a comment in allocate_memory() when skipping small banks
>>>>>>>>> v10:
>>>>>>>>> - fixed a compilation bug that happened when dom0less support was disabled
>>>>>>>>> v9:
>>>>>>>>> - no changes
>>>>>>>>> v8:
>>>>>>>>> - patch adapted to new changes to allocate_memory()
>>>>>>>>> v7:
>>>>>>>>> - allocate_memory() now uses the host layout when called on the hwdom
>>>>>>>>> v6:
>>>>>>>>> - new patch
>>>>>>>>> ---
>>>>>>>>>    xen/arch/arm/dom0less-build.c           | 44 -----------
>>>>>>>>>    xen/arch/arm/domain_build.c             | 97 ++++++++++++++++++++++++-
>>>>>>>>>    xen/arch/arm/include/asm/domain_build.h |  1 +
>>>>>>>>>    3 files changed, 94 insertions(+), 48 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
>>>>>>>>> index d93a85434e..67b1503647 100644
>>>>>>>>> --- a/xen/arch/arm/dom0less-build.c
>>>>>>>>> +++ b/xen/arch/arm/dom0less-build.c
>>>>>>>>> @@ -49,50 +49,6 @@ bool __init is_dom0less_mode(void)
>>>>>>>>>        return ( !dom0found && domUfound );
>>>>>>>>>    }
>>>>>>>>>
>>>>>>>>> -static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
>>>>>>>>> -{
>>>>>>>>> -    struct membanks *mem = kernel_info_get_mem(kinfo);
>>>>>>>>> -    unsigned int i;
>>>>>>>>> -    paddr_t bank_size;
>>>>>>>>> -
>>>>>>>>> -    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
>>>>>>>>> -           /* Don't want format this as PRIpaddr (16 digit hex) */
>>>>>>>>> -           (unsigned long)(kinfo->unassigned_mem >> 20), d);
>>>>>>>>> -
>>>>>>>>> -    mem->nr_banks = 0;
>>>>>>>>> -    bank_size = MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem);
>>>>>>>>> -    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM0_BASE),
>>>>>>>>> -                               bank_size) )
>>>>>>>>> -        goto fail;
>>>>>>>>> -
>>>>>>>>> -    bank_size = MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem);
>>>>>>>>> -    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM1_BASE),
>>>>>>>>> -                               bank_size) )
>>>>>>>>> -        goto fail;
>>>>>>>>> -
>>>>>>>>> -    if ( kinfo->unassigned_mem )
>>>>>>>>> -        goto fail;
>>>>>>>>> -
>>>>>>>>> -    for( i = 0; i < mem->nr_banks; i++ )
>>>>>>>>> -    {
>>>>>>>>> -        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
>>>>>>>>> -               d,
>>>>>>>>> -               i,
>>>>>>>>> -               mem->bank[i].start,
>>>>>>>>> -               mem->bank[i].start + mem->bank[i].size,
>>>>>>>>> -               /* Don't want format this as PRIpaddr (16 digit hex) */
>>>>>>>>> -               (unsigned long)(mem->bank[i].size >> 20));
>>>>>>>>> -    }
>>>>>>>>> -
>>>>>>>>> -    return;
>>>>>>>>> -
>>>>>>>>> -fail:
>>>>>>>>> -    panic("Failed to allocate requested domain memory."
>>>>>>>>> -          /* Don't want format this as PRIpaddr (16 digit hex) */
>>>>>>>>> -          " %ldKB unallocated. Fix the VMs configurations.\n",
>>>>>>>>> -          (unsigned long)kinfo->unassigned_mem >> 10);
>>>>>>>>> -}
>>>>>>>>> -
>>>>>>>>>    #ifdef CONFIG_VGICV2
>>>>>>>>>    static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
>>>>>>>>>    {
>>>>>>>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>>>>>>>> index 2c30792de8..2b8cba9b2f 100644
>>>>>>>>> --- a/xen/arch/arm/domain_build.c
>>>>>>>>> +++ b/xen/arch/arm/domain_build.c
>>>>>>>>> @@ -416,7 +416,6 @@ static void __init allocate_memory_11(struct domain *d,
>>>>>>>>>        }
>>>>>>>>>    }
>>>>>>>>>
>>>>>>>>> -#ifdef CONFIG_DOM0LESS_BOOT
>>>>>>>>>    bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size,
>>>>>>>>>                                        alloc_domheap_mem_cb cb, void *extra)
>>>>>>>>>    {
>>>>>>>>> @@ -508,7 +507,6 @@ bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
>>>>>>>>>
>>>>>>>>>        return true;
>>>>>>>>>    }
>>>>>>>>> -#endif
>>>>>>>>>
>>>>>>>>>    /*
>>>>>>>>>     * When PCI passthrough is available we want to keep the
>>>>>>>>> @@ -1003,6 +1001,94 @@ out:
>>>>>>>>>        return res;
>>>>>>>>>    }
>>>>>>>>>
>>>>>>>>> +void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
>>>>>>>>> +{
>>>>>>>>> +    struct membanks *mem = kernel_info_get_mem(kinfo);
>>>>>>>>> +    unsigned int i, nr_banks = GUEST_RAM_BANKS;
>>>>>>>>> +    paddr_t bank_start, bank_size;
>>>>>>>> Limit the scope
>>>>>>>>
>>>>>>>>> +    struct membanks *hwdom_free_mem = NULL;
>>>>>>>>> +    const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
>>>>>>>>> +    const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
>>>>>>>> Limit the scope
>>>>>>>>
>>>>>>>>> +
>>>>>>>>> +    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
>>>>>>>>> +           /* Don't want format this as PRIpaddr (16 digit hex) */
>>>>>>>>> +           (unsigned long)(kinfo->unassigned_mem >> 20), d);
>>>>>>>>> +
>>>>>>>>> +    mem->nr_banks = 0;
>>>>>>>>> +    /*
>>>>>>>>> +     * Use host memory layout for hwdom. Only case for this is when LLC coloring
>>>>>>>>> +     * is enabled.
>>>>>>>>> +     */
>>>>>>>>> +    if ( is_hardware_domain(d) )
>>>>>>>>> +    {
>>>>>>>>> +        ASSERT(llc_coloring_enabled);
>>>>>>>> This patch does not build because of declaration not being visible. You must include .
>>>>>>>
>>>>>>> Piggying back on this comment. AFAICT, the code below would work also in
>>>>>>> the non cache coloring case. So what's the assert is for?
>>>>>>>
>>>>>>>>
>>>>>>>>> +
>>>>>>>>> +        hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank,
>>>>>>>>> +                                             NR_MEM_BANKS);
>>>>>>>>> +        if ( !hwdom_free_mem )
>>>>>>>>> +            goto fail;
>>>>>>>>> +
>>>>>>>>> +        hwdom_free_mem->max_banks = NR_MEM_BANKS;
>>>>>>>>> +
>>>>>>>>> +        if ( find_unallocated_memory(kinfo, hwdom_free_mem) )
>>>>>>>> My remarks for the use of find_unallocated_memory() 1:1 have not been addressed. You did not even
>>>>>>>> change the comments inside the function. The problem is that the function is specifically designed
>>>>>>>> for finding extended regions and assumes being called at certain point i.e. dom0 RAM allocated, gnttab
>>>>>>>> region allocated, etc.
>>>>>>>
>>>>>>> So I agree that the function should be updated if we plan to use it for
>>>>>>> other purpose.
>>>>>>>
>>>>>>> My opinion is that we should attempt to make the function generic so
>>>>>>> that in your
>>>>>>>> case you can choose which regions to exclude, define even your own function to grab free regions (at the moment
>>>>>>>> add_ext_regions grabs banks >= 64M but you still discards banks >= 128M, so it's a bit wasteful.
>>>>>>>>
>>>>>>>> My very short attempt to make the function as generic as possible in the first iteration:
>>>>>>>> https://paste.debian.net/1338334/
>>>>>>>
>>>>>>> This looks better, but I wonder why we need still need to exclude the
>>>>>>> static regions? Wouldn't it be sufficient to exclude just reserved regions?
>>>>>> Static shared memory banks are not part of reserved memory (i.e. bootinfo.reserved_mem) if that's what you're asking.
>>>>>> They are stored in bootinfo.shmem, hence we need to take them into account when searching for unused address space.
>>>>>
>>>>> Oh I missed the fact you now pass "mem_banks" as a parameter. I thought
>>>>> they would still get excluded for cache coloring case.
>>>>>
>>>>>>
>>>>>> If you and Carlo are ok with my proposed solution for making the function generic, I can send a patch as a prerequisite
>>>>>> patch for Carlo series.
>>>>>
>>>>> I am fine with the approach.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> --
>>>>> Julien Grall
>>>>>
>>>>
>>>>> @@ -2152,7 +2238,10 @@ static int __init construct_dom0(struct domain *d)
>>>>>      /* type must be set before allocate_memory */
>>>>>      d->arch.type = kinfo.type;
>>>>>  #endif
>>>>> -    allocate_memory_11(d, &kinfo);
>>>>> +    if ( is_domain_direct_mapped(d) )
>>>>> +        allocate_memory_11(d, &kinfo);
>>>>> +    else
>>>>> +        allocate_memory(d, &kinfo);
>>>>>      find_gnttab_region(d, &kinfo);
>>>>
>>>> Since find_gnttab_region() is called after allocate_memory(), kinfo->gnttab_*
>>>> fields aren't initialized and the call to find_unallocated_memory() with
>>>> gnttab as the region to exclude, fails ending in a crash since memory for
>>>> dom0 can't be allocated.
>>>>
>>>> Can the solution be to call find_gnttab_region() before the above if?
>>>
>>> The function is called find, but currently it only initializes kinfo->gnttab_start
>>> and kinfo->gnttab_size and we tested that moving it before allocate_memory* doesn't
>>> cause fallouts.
>>>
>>> If moving before allocate_memory*, would it be better to rename it e.g., init_gnttab_region()?
>>>
>>> Thanks,
>>> Andrea
>>>
>>>> Or should I just call it before allocate_memory() in one case, but still after
>>>> allocate_memory_11() in the other?
>>>>
>>>> Thanks.
>>>
>>
>> AFAICT there is nothing stopping us from moving find_gnttab_region() before allocate_*. This function initializes
>> gnttab region with PA of Xen. In normal case, because Xen is added as bootmodule, it will never be mapped in dom0 memory map
>> and the placement does not matter. In LLC case, it will point to relocated address of Xen and it needs to be known before
>> calling find_unallocated_memory. Don't rename it, leave as is, just move before allocate_*.
>>
>> @Carlo:
>> My prerequisite patch has been merged, so you're good to respin a series (unless you wait for some feedback in which case do let me know).
>> To prevent too many respins, you're going to call find_unallocated_memory for LLC passing resmem and gnttab to be excluded. If you're going
>> to reuse add_ext_regions, you need to rename it and fix comments to make it more generic. As for the size, the decision is yours. One solution
>> would be to modify add_ext_regions to take min bank size as parameter (64MB for extended regions, X for LLC dom0). In your code, you write that
>> the first bank must contain dom0, dtb, ramdisk and you chose 128MB. However, looking at the code, you seem to discard banks < 128 for all the banks,
>> not only for the first one. This is the part that I don't have a ready solution. Maybe you could define your own add_free_region function and sort
>> the banks, so that you take the largest possible bank first for dom0. This could simplify things.
> 
> For the moment I added a __add_ext_regions() helper that also takes a skip_size
I'm not sure if MISRA and our guidelines are happy with prefixing with function with __.
I don't understand the skip_size parameter. In which scenario do you want to use it? Not for
extended regions and for LLC, even with your current solution, you also want to find banks bigger than
some size.

> parameter. This is called by add_ext_regions() and by a new
> add_hwdom_free_regions() callback used in allocate_memory().
> I still use 128MB for all the banks. Do you think this is acceptable, maybe
> with a FIXME comment cause we should skip only the first bank, or not?
First of all, I'm not convinced with 128MB. This is definitely not a requirement for arm64.
allocate_memory_11 uses it but the algorithm of finding banks is completely different.

AFAICT, with my suggested solution i.e. sorting banks in a helper like add_ext_regions used only
for LLC case, you no longer need to worry about size. You simply start with the biggest possible bank
as the first bank.

~Michal



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 11:30:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 11:30:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856584.1269154 (Exim 4.92)
	(envelope-from )
	id 1tM3sD-0007Er-EH; Fri, 13 Dec 2024 11:30:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856584.1269154; Fri, 13 Dec 2024 11:30: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 1tM3sD-0007Ek-Bd; Fri, 13 Dec 2024 11:30:21 +0000
Received: by outflank-mailman (input) for mailman id 856584;
 Fri, 13 Dec 2024 11:30: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 1tM3sB-0007Ee-VL
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 11:30:20 +0000
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com
 [2607:f8b0:4864:20::135])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a06608ad-b945-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 12:30:17 +0100 (CET)
Received: by mail-il1-x135.google.com with SMTP id
 e9e14a558f8ab-3ab2f414695so5255595ab.0
 for ; Fri, 13 Dec 2024 03:30: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: a06608ad-b945-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734089416; x=1734694216; 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=Skor99wtpWhnoGqVEyK458RiUEUsEy2xJ2n4H4KBoX4=;
        b=M5EsNAzR4LmUUSThLkWF9GAWp2hWvtmqH6Fqpd8T881xId29grmOL6K/VMUsRRJpX9
         FWlzQPkt1NPXfvbQvVEWmMwVoNrwCP0CrT675bdroQEU0QQnTQSEG83vCkuRuYFGMzfw
         EVwUXrUL7p8thXyWXXlLz7IeswYbHh9Uxagpxz9ESQo0Kwy7I5Evcd2aqcTKKCw0tyET
         z+0fD6SaA6PzJzXfRWmxa3AlC3eb7SSH31+W/dzBeBKeEj0h5mq/FLZi4jFjUxitJJnn
         Hhumhm+16QZcFn1vzhkHv9lR5ZCZ6jXoyC7cfhjLcILf9EDk9hscHZrEDmA+O2Z9H8UV
         4yjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734089416; x=1734694216;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Skor99wtpWhnoGqVEyK458RiUEUsEy2xJ2n4H4KBoX4=;
        b=iCvFy/kh7FJG2/zwygodVK9FXDEs5y1g0c5eCyyeZho7oJgI8qE3CtEXk0vsUCrQ5T
         pLjOa9iOcoN+7ftGGfT8UZRYo8WGaChnb0Fs9ieqd2TPV2OyXEBuBk06psH06UhKBo2J
         /1NU7gli52GbwktguNMASwcmke3AN8JSYG+/tgU+iBT32A/EAIP48mn6x6t9cMmBKf7m
         4/EoQhVD6cVgn1zKVg+SBgfkF+9xsxlIRT4FPFbXeosbHeV4/ofiK2ZpFHCjVGhXjqRM
         PujgBhobBIH/zCXeWMxLmT4dmC3plnWhKyBgdjH0Kr/hn/jVai1z5HRJ2kw214uFi2sw
         2tmA==
X-Forwarded-Encrypted: i=1; AJvYcCVwMe17KiAjGgiLsRbPeIXSKKiOlFpPlvjX7bMFMPOo5728YE4xFaxOFz3qge/8uNeQhDh5np/oUtE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxeV+zfncSDy+pvuV/5k1GxcNZpPPLDYvYWbiamMYNor8djzrov
	oXLZ3YhvhdHAjUvft/eOqFdTGcQUJ9r5+82qJzcLgZIFh6NPQL75sqYdbZTfHA3zyD9H0krNtE2
	wWW53kXVdrJgSWgdY4pT3lxPCngiicEznL4vzpU355suLBpkmhR7b5w==
X-Gm-Gg: ASbGncuCcAV6qosHSlkiwDLNuxitxmBCZ50iVC7Lr0HIEOXw/gc6M1atOY1BUPqdmAZ
	7TJFakcDmpjlT26TsN0jj2+XE78lqahWT5TiwfA==
X-Google-Smtp-Source: AGHT+IHmxHc6JXxNa+sbAFMjZ0da3wx+5KaBWKvazVK8XYBTB0UyLcMCrhIakEmL3lH4IZVE0z5uXynsT7O0kiZWAT8=
X-Received: by 2002:a05:6e02:1489:b0:3a3:b45b:fb92 with SMTP id
 e9e14a558f8ab-3aff2fbeacdmr25258775ab.23.1734089415898; Fri, 13 Dec 2024
 03:30:15 -0800 (PST)
MIME-Version: 1.0
References: <20241202165921.249585-1-carlo.nonato@minervasys.tech>
 <20241202165921.249585-4-carlo.nonato@minervasys.tech> 
 <7ecc99c5-0cb5-4351-bede-cb03c9a4ac7e@xen.org> <293004fa-c87e-4a45-aa4c-b02456aaecea@amd.com>
 <0bacfdb6-d4ad-4dea-85d4-2851873dca4e@xen.org> 
  <2f834c6b-c9fa-4b95-abff-b9bcb8c70246@amd.com>
  <6cb8c273-8e1d-4f34-adcc-620d4a71340c@amd.com>
In-Reply-To: <6cb8c273-8e1d-4f34-adcc-620d4a71340c@amd.com>
From: Carlo Nonato 
Date: Fri, 13 Dec 2024 12:30:05 +0100
Message-ID: 
Subject: Re: [PATCH v11 03/12] xen/arm: permit non direct-mapped Dom0 construction
To: Michal Orzel 
Cc: Andrea Bastoni , Julien Grall , 
	xen-devel@lists.xenproject.org, marco.solieri@minervasys.tech, 
	Stefano Stabellini , Bertrand Marquis , 
	Volodymyr Babchuk 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 13, 2024 at 11:56=E2=80=AFAM Michal Orzel  wrote:
>
>
>
> On 13/12/2024 11:26, Carlo Nonato wrote:
> >
> >
> > Hi Michal,
> >
> > On Fri, Dec 13, 2024 at 10:46=E2=80=AFAM Michal Orzel  wrote:
> >>
> >> Hi Carlo, Andrea,
> >>
> >> On 12/12/2024 19:22, Andrea Bastoni wrote:
> >>>
> >>>
> >>> On 12/12/2024 18:48, Carlo Nonato wrote:
> >>>> Hi,
> >>>>
> >>>> On Mon, Dec 9, 2024 at 8:17=E2=80=AFPM Julien Grall =
 wrote:
> >>>>>
> >>>>> Hi Michal,
> >>>>>
> >>>>> On 07/12/2024 15:04, Michal Orzel wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 06/12/2024 19:37, Julien Grall wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Sorry for the late answer.
> >>>>>>>
> >>>>>>> On 05/12/2024 09:40, Michal Orzel wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 02/12/2024 17:59, Carlo Nonato wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Cache coloring requires Dom0 not to be direct-mapped because of=
 its non
> >>>>>>>>> contiguous mapping nature, so allocate_memory() is needed in th=
is case.
> >>>>>>>>> 8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a sep=
arate module")
> >>>>>>>>> moved allocate_memory() in dom0less_build.c. In order to use it
> >>>>>>>>> in Dom0 construction bring it back to domain_build.c and declar=
e it in
> >>>>>>>>> domain_build.h.
> >>>>>>>>>
> >>>>>>>>> Take the opportunity to adapt the implementation of allocate_me=
mory() so
> >>>>>>>>> that it uses the host layout when called on the hwdom, via
> >>>>>>>>> find_unallocated_memory().
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Carlo Nonato 
> >>>>>>>>> ---
> >>>>>>>>> v11:
> >>>>>>>>> - GUEST_RAM_BANKS instead of hardcoding the number of banks in =
allocate_memory()
> >>>>>>>>> - hwdom_ext_regions -> hwdom_free_mem in allocate_memory()
> >>>>>>>>> - added a comment in allocate_memory() when skipping small bank=
s
> >>>>>>>>> v10:
> >>>>>>>>> - fixed a compilation bug that happened when dom0less support w=
as disabled
> >>>>>>>>> v9:
> >>>>>>>>> - no changes
> >>>>>>>>> v8:
> >>>>>>>>> - patch adapted to new changes to allocate_memory()
> >>>>>>>>> v7:
> >>>>>>>>> - allocate_memory() now uses the host layout when called on the=
 hwdom
> >>>>>>>>> v6:
> >>>>>>>>> - new patch
> >>>>>>>>> ---
> >>>>>>>>>    xen/arch/arm/dom0less-build.c           | 44 -----------
> >>>>>>>>>    xen/arch/arm/domain_build.c             | 97 +++++++++++++++=
+++++++++-
> >>>>>>>>>    xen/arch/arm/include/asm/domain_build.h |  1 +
> >>>>>>>>>    3 files changed, 94 insertions(+), 48 deletions(-)
> >>>>>>>>>
> >>>>>>>>> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0l=
ess-build.c
> >>>>>>>>> index d93a85434e..67b1503647 100644
> >>>>>>>>> --- a/xen/arch/arm/dom0less-build.c
> >>>>>>>>> +++ b/xen/arch/arm/dom0less-build.c
> >>>>>>>>> @@ -49,50 +49,6 @@ bool __init is_dom0less_mode(void)
> >>>>>>>>>        return ( !dom0found && domUfound );
> >>>>>>>>>    }
> >>>>>>>>>
> >>>>>>>>> -static void __init allocate_memory(struct domain *d, struct ke=
rnel_info *kinfo)
> >>>>>>>>> -{
> >>>>>>>>> -    struct membanks *mem =3D kernel_info_get_mem(kinfo);
> >>>>>>>>> -    unsigned int i;
> >>>>>>>>> -    paddr_t bank_size;
> >>>>>>>>> -
> >>>>>>>>> -    printk(XENLOG_INFO "Allocating mappings totalling %ldMB fo=
r %pd:\n",
> >>>>>>>>> -           /* Don't want format this as PRIpaddr (16 digit hex=
) */
> >>>>>>>>> -           (unsigned long)(kinfo->unassigned_mem >> 20), d);
> >>>>>>>>> -
> >>>>>>>>> -    mem->nr_banks =3D 0;
> >>>>>>>>> -    bank_size =3D MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem);
> >>>>>>>>> -    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM0_=
BASE),
> >>>>>>>>> -                               bank_size) )
> >>>>>>>>> -        goto fail;
> >>>>>>>>> -
> >>>>>>>>> -    bank_size =3D MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem);
> >>>>>>>>> -    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM1_=
BASE),
> >>>>>>>>> -                               bank_size) )
> >>>>>>>>> -        goto fail;
> >>>>>>>>> -
> >>>>>>>>> -    if ( kinfo->unassigned_mem )
> >>>>>>>>> -        goto fail;
> >>>>>>>>> -
> >>>>>>>>> -    for( i =3D 0; i < mem->nr_banks; i++ )
> >>>>>>>>> -    {
> >>>>>>>>> -        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpa=
ddr" (%ldMB)\n",
> >>>>>>>>> -               d,
> >>>>>>>>> -               i,
> >>>>>>>>> -               mem->bank[i].start,
> >>>>>>>>> -               mem->bank[i].start + mem->bank[i].size,
> >>>>>>>>> -               /* Don't want format this as PRIpaddr (16 digit=
 hex) */
> >>>>>>>>> -               (unsigned long)(mem->bank[i].size >> 20));
> >>>>>>>>> -    }
> >>>>>>>>> -
> >>>>>>>>> -    return;
> >>>>>>>>> -
> >>>>>>>>> -fail:
> >>>>>>>>> -    panic("Failed to allocate requested domain memory."
> >>>>>>>>> -          /* Don't want format this as PRIpaddr (16 digit hex)=
 */
> >>>>>>>>> -          " %ldKB unallocated. Fix the VMs configurations.\n",
> >>>>>>>>> -          (unsigned long)kinfo->unassigned_mem >> 10);
> >>>>>>>>> -}
> >>>>>>>>> -
> >>>>>>>>>    #ifdef CONFIG_VGICV2
> >>>>>>>>>    static int __init make_gicv2_domU_node(struct kernel_info *k=
info)
> >>>>>>>>>    {
> >>>>>>>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_=
build.c
> >>>>>>>>> index 2c30792de8..2b8cba9b2f 100644
> >>>>>>>>> --- a/xen/arch/arm/domain_build.c
> >>>>>>>>> +++ b/xen/arch/arm/domain_build.c
> >>>>>>>>> @@ -416,7 +416,6 @@ static void __init allocate_memory_11(struc=
t domain *d,
> >>>>>>>>>        }
> >>>>>>>>>    }
> >>>>>>>>>
> >>>>>>>>> -#ifdef CONFIG_DOM0LESS_BOOT
> >>>>>>>>>    bool __init allocate_domheap_memory(struct domain *d, paddr_=
t tot_size,
> >>>>>>>>>                                        alloc_domheap_mem_cb cb,=
 void *extra)
> >>>>>>>>>    {
> >>>>>>>>> @@ -508,7 +507,6 @@ bool __init allocate_bank_memory(struct ker=
nel_info *kinfo, gfn_t sgfn,
> >>>>>>>>>
> >>>>>>>>>        return true;
> >>>>>>>>>    }
> >>>>>>>>> -#endif
> >>>>>>>>>
> >>>>>>>>>    /*
> >>>>>>>>>     * When PCI passthrough is available we want to keep the
> >>>>>>>>> @@ -1003,6 +1001,94 @@ out:
> >>>>>>>>>        return res;
> >>>>>>>>>    }
> >>>>>>>>>
> >>>>>>>>> +void __init allocate_memory(struct domain *d, struct kernel_in=
fo *kinfo)
> >>>>>>>>> +{
> >>>>>>>>> +    struct membanks *mem =3D kernel_info_get_mem(kinfo);
> >>>>>>>>> +    unsigned int i, nr_banks =3D GUEST_RAM_BANKS;
> >>>>>>>>> +    paddr_t bank_start, bank_size;
> >>>>>>>> Limit the scope
> >>>>>>>>
> >>>>>>>>> +    struct membanks *hwdom_free_mem =3D NULL;
> >>>>>>>>> +    const uint64_t bankbase[] =3D GUEST_RAM_BANK_BASES;
> >>>>>>>>> +    const uint64_t banksize[] =3D GUEST_RAM_BANK_SIZES;
> >>>>>>>> Limit the scope
> >>>>>>>>
> >>>>>>>>> +
> >>>>>>>>> +    printk(XENLOG_INFO "Allocating mappings totalling %ldMB fo=
r %pd:\n",
> >>>>>>>>> +           /* Don't want format this as PRIpaddr (16 digit hex=
) */
> >>>>>>>>> +           (unsigned long)(kinfo->unassigned_mem >> 20), d);
> >>>>>>>>> +
> >>>>>>>>> +    mem->nr_banks =3D 0;
> >>>>>>>>> +    /*
> >>>>>>>>> +     * Use host memory layout for hwdom. Only case for this is=
 when LLC coloring
> >>>>>>>>> +     * is enabled.
> >>>>>>>>> +     */
> >>>>>>>>> +    if ( is_hardware_domain(d) )
> >>>>>>>>> +    {
> >>>>>>>>> +        ASSERT(llc_coloring_enabled);
> >>>>>>>> This patch does not build because of declaration not being visib=
le. You must include .
> >>>>>>>
> >>>>>>> Piggying back on this comment. AFAICT, the code below would work =
also in
> >>>>>>> the non cache coloring case. So what's the assert is for?
> >>>>>>>
> >>>>>>>>
> >>>>>>>>> +
> >>>>>>>>> +        hwdom_free_mem =3D xzalloc_flex_struct(struct membanks=
, bank,
> >>>>>>>>> +                                             NR_MEM_BANKS);
> >>>>>>>>> +        if ( !hwdom_free_mem )
> >>>>>>>>> +            goto fail;
> >>>>>>>>> +
> >>>>>>>>> +        hwdom_free_mem->max_banks =3D NR_MEM_BANKS;
> >>>>>>>>> +
> >>>>>>>>> +        if ( find_unallocated_memory(kinfo, hwdom_free_mem) )
> >>>>>>>> My remarks for the use of find_unallocated_memory() 1:1 have not=
 been addressed. You did not even
> >>>>>>>> change the comments inside the function. The problem is that the=
 function is specifically designed
> >>>>>>>> for finding extended regions and assumes being called at certain=
 point i.e. dom0 RAM allocated, gnttab
> >>>>>>>> region allocated, etc.
> >>>>>>>
> >>>>>>> So I agree that the function should be updated if we plan to use =
it for
> >>>>>>> other purpose.
> >>>>>>>
> >>>>>>> My opinion is that we should attempt to make the function generic=
 so
> >>>>>>> that in your
> >>>>>>>> case you can choose which regions to exclude, define even your o=
wn function to grab free regions (at the moment
> >>>>>>>> add_ext_regions grabs banks >=3D 64M but you still discards bank=
s >=3D 128M, so it's a bit wasteful.
> >>>>>>>>
> >>>>>>>> My very short attempt to make the function as generic as possibl=
e in the first iteration:
> >>>>>>>> https://paste.debian.net/1338334/
> >>>>>>>
> >>>>>>> This looks better, but I wonder why we need still need to exclude=
 the
> >>>>>>> static regions? Wouldn't it be sufficient to exclude just reserve=
d regions?
> >>>>>> Static shared memory banks are not part of reserved memory (i.e. b=
ootinfo.reserved_mem) if that's what you're asking.
> >>>>>> They are stored in bootinfo.shmem, hence we need to take them into=
 account when searching for unused address space.
> >>>>>
> >>>>> Oh I missed the fact you now pass "mem_banks" as a parameter. I tho=
ught
> >>>>> they would still get excluded for cache coloring case.
> >>>>>
> >>>>>>
> >>>>>> If you and Carlo are ok with my proposed solution for making the f=
unction generic, I can send a patch as a prerequisite
> >>>>>> patch for Carlo series.
> >>>>>
> >>>>> I am fine with the approach.
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> --
> >>>>> Julien Grall
> >>>>>
> >>>>
> >>>>> @@ -2152,7 +2238,10 @@ static int __init construct_dom0(struct doma=
in *d)
> >>>>>      /* type must be set before allocate_memory */
> >>>>>      d->arch.type =3D kinfo.type;
> >>>>>  #endif
> >>>>> -    allocate_memory_11(d, &kinfo);
> >>>>> +    if ( is_domain_direct_mapped(d) )
> >>>>> +        allocate_memory_11(d, &kinfo);
> >>>>> +    else
> >>>>> +        allocate_memory(d, &kinfo);
> >>>>>      find_gnttab_region(d, &kinfo);
> >>>>
> >>>> Since find_gnttab_region() is called after allocate_memory(), kinfo-=
>gnttab_*
> >>>> fields aren't initialized and the call to find_unallocated_memory() =
with
> >>>> gnttab as the region to exclude, fails ending in a crash since memor=
y for
> >>>> dom0 can't be allocated.
> >>>>
> >>>> Can the solution be to call find_gnttab_region() before the above if=
?
> >>>
> >>> The function is called find, but currently it only initializes kinfo-=
>gnttab_start
> >>> and kinfo->gnttab_size and we tested that moving it before allocate_m=
emory* doesn't
> >>> cause fallouts.
> >>>
> >>> If moving before allocate_memory*, would it be better to rename it e.=
g., init_gnttab_region()?
> >>>
> >>> Thanks,
> >>> Andrea
> >>>
> >>>> Or should I just call it before allocate_memory() in one case, but s=
till after
> >>>> allocate_memory_11() in the other?
> >>>>
> >>>> Thanks.
> >>>
> >>
> >> AFAICT there is nothing stopping us from moving find_gnttab_region() b=
efore allocate_*. This function initializes
> >> gnttab region with PA of Xen. In normal case, because Xen is added as =
bootmodule, it will never be mapped in dom0 memory map
> >> and the placement does not matter. In LLC case, it will point to reloc=
ated address of Xen and it needs to be known before
> >> calling find_unallocated_memory. Don't rename it, leave as is, just mo=
ve before allocate_*.
> >>
> >> @Carlo:
> >> My prerequisite patch has been merged, so you're good to respin a seri=
es (unless you wait for some feedback in which case do let me know).
> >> To prevent too many respins, you're going to call find_unallocated_mem=
ory for LLC passing resmem and gnttab to be excluded. If you're going
> >> to reuse add_ext_regions, you need to rename it and fix comments to ma=
ke it more generic. As for the size, the decision is yours. One solution
> >> would be to modify add_ext_regions to take min bank size as parameter =
(64MB for extended regions, X for LLC dom0). In your code, you write that
> >> the first bank must contain dom0, dtb, ramdisk and you chose 128MB. Ho=
wever, looking at the code, you seem to discard banks < 128 for all the ban=
ks,
> >> not only for the first one. This is the part that I don't have a ready=
 solution. Maybe you could define your own add_free_region function and sor=
t
> >> the banks, so that you take the largest possible bank first for dom0. =
This could simplify things.
> >
> > For the moment I added a __add_ext_regions() helper that also takes a s=
kip_size
> I'm not sure if MISRA and our guidelines are happy with prefixing with fu=
nction with __.
> I don't understand the skip_size parameter. In which scenario do you want=
 to use it? Not for
> extended regions and for LLC, even with your current solution, you also w=
ant to find banks bigger than
> some size.
>
> > parameter. This is called by add_ext_regions() and by a new
> > add_hwdom_free_regions() callback used in allocate_memory().
> > I still use 128MB for all the banks. Do you think this is acceptable, m=
aybe
> > with a FIXME comment cause we should skip only the first bank, or not?
> First of all, I'm not convinced with 128MB. This is definitely not a requ=
irement for arm64.
> allocate_memory_11 uses it but the algorithm of finding banks is complete=
ly different.
>
> AFAICT, with my suggested solution i.e. sorting banks in a helper like ad=
d_ext_regions used only
> for LLC case, you no longer need to worry about size. You simply start wi=
th the biggest possible bank
> as the first bank.
>
> ~Michal
>

Here's my current patch:

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index d93a85434e..67b1503647 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -49,50 +49,6 @@ bool __init is_dom0less_mode(void)
     return ( !dom0found && domUfound );
 }

-static void __init allocate_memory(struct domain *d, struct kernel_info *k=
info)
-{
-    struct membanks *mem =3D kernel_info_get_mem(kinfo);
-    unsigned int i;
-    paddr_t bank_size;
-
-    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
-           /* Don't want format this as PRIpaddr (16 digit hex) */
-           (unsigned long)(kinfo->unassigned_mem >> 20), d);
-
-    mem->nr_banks =3D 0;
-    bank_size =3D MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem);
-    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM0_BASE),
-                               bank_size) )
-        goto fail;
-
-    bank_size =3D MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem);
-    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM1_BASE),
-                               bank_size) )
-        goto fail;
-
-    if ( kinfo->unassigned_mem )
-        goto fail;
-
-    for( i =3D 0; i < mem->nr_banks; i++ )
-    {
-        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)=
\n",
-               d,
-               i,
-               mem->bank[i].start,
-               mem->bank[i].start + mem->bank[i].size,
-               /* Don't want format this as PRIpaddr (16 digit hex) */
-               (unsigned long)(mem->bank[i].size >> 20));
-    }
-
-    return;
-
-fail:
-    panic("Failed to allocate requested domain memory."
-          /* Don't want format this as PRIpaddr (16 digit hex) */
-          " %ldKB unallocated. Fix the VMs configurations.\n",
-          (unsigned long)kinfo->unassigned_mem >> 10);
-}
-
 #ifdef CONFIG_VGICV2
 static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
 {
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index adf26f2778..59ac45c4e0 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -416,7 +417,6 @@ static void __init allocate_memory_11(struct domain *d,
     }
 }

-#ifdef CONFIG_DOM0LESS_BOOT
 bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size,
                                     alloc_domheap_mem_cb cb, void *extra)
 {
@@ -508,7 +508,6 @@ bool __init allocate_bank_memory(struct
kernel_info *kinfo, gfn_t sgfn,

     return true;
 }
-#endif

 /*
  * When PCI passthrough is available we want to keep the
@@ -859,8 +858,8 @@ int __init make_memory_node(const struct
kernel_info *kinfo, int addrcells,
     return res;
 }

-int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
-                           void *data)
+static int __init __add_ext_regions(unsigned long s_gfn, unsigned long e_g=
fn,
+                                    void *data, paddr_t skip_size)
 {
     struct membanks *ext_regions =3D data;
     paddr_t start, size;
@@ -885,12 +884,7 @@ int __init add_ext_regions(unsigned long s_gfn,
unsigned long e_gfn,
     e +=3D 1;
     size =3D (e - start) & ~(SZ_2M - 1);

-    /*
-     * Reasonable size. Not too little to pick up small ranges which are
-     * not quite useful but increase bookkeeping and not too large
-     * to skip a large proportion of unused address space.
-     */
-    if ( size < MB(64) )
+    if ( size < skip_size )
         return 0;

     ext_regions->bank[ext_regions->nr_banks].start =3D start;
@@ -900,6 +894,28 @@ int __init add_ext_regions(unsigned long s_gfn,
unsigned long e_gfn,
     return 0;
 }

+static int __init add_hwdom_free_regions(unsigned long s_gfn,
+                                         unsigned long e_gfn, void *data)
+{
+    /*
+     * Skip banks that are too small. The first bank must contain dom0 ker=
nel +
+     * ramdisk + dtb and 128 MB is the same limit used in allocate_memory_=
11().
+     */
+    return __add_ext_regions(s_gfn, e_gfn, data, MB(128));
+}
+
+
+int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
+                           void *data)
+{
+    /*
+     * Reasonable size. Not too little to pick up small ranges which are
+     * not quite useful but increase bookkeeping and not too large
+     * to skip a large proportion of unused address space.
+     */
+    return __add_ext_regions(s_gfn, e_gfn, data, MB(64));
+}
+
 /*
  * Find unused regions of Host address space which can be exposed to domai=
n
  * using the host memory layout. In order to calculate regions we exclude =
every
@@ -977,6 +993,109 @@ out:
     return res;
 }

+void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
+{
+    struct membanks *mem =3D kernel_info_get_mem(kinfo);
+    unsigned int i, nr_banks =3D GUEST_RAM_BANKS;
+    struct membanks *hwdom_free_mem =3D NULL;
+
+    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
+           /* Don't want format this as PRIpaddr (16 digit hex) */
+           (unsigned long)(kinfo->unassigned_mem >> 20), d);
+
+    mem->nr_banks =3D 0;
+    /*
+     * Use host memory layout for hwdom. Only case for this is when
LLC coloring
+     * is enabled.
+     */
+    if ( is_hardware_domain(d) )
+    {
+        struct membanks *gnttab =3D xzalloc_flex_struct(struct
membanks, bank, 1);
+        /*
+         * Exclude the following regions:
+         * 1) Remove reserved memory
+         * 2) Grant table assigned to Dom0
+         */
+        const struct membanks *mem_banks[] =3D {
+            bootinfo_get_reserved_mem(),
+            gnttab,
+        };
+
+        ASSERT(llc_coloring_enabled);
+
+        if ( !gnttab )
+            goto fail;
+
+        gnttab->nr_banks =3D 1;
+        gnttab->bank[0].start =3D kinfo->gnttab_start;
+        gnttab->bank[0].size =3D kinfo->gnttab_start + kinfo->gnttab_size;
+
+        hwdom_free_mem =3D xzalloc_flex_struct(struct membanks, bank,
+                                             NR_MEM_BANKS);
+        if ( !hwdom_free_mem )
+            goto fail;
+
+        hwdom_free_mem->max_banks =3D NR_MEM_BANKS;
+
+        if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_bank=
s),
+                                     hwdom_free_mem, add_hwdom_free_region=
s) )
+            goto fail;
+
+        nr_banks =3D hwdom_free_mem->nr_banks;
+        xfree(gnttab);
+    }
+
+    for ( i =3D 0; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_bank=
s-- )
+    {
+        paddr_t bank_start, bank_size;
+
+        if ( is_hardware_domain(d) )
+        {
+            bank_start =3D hwdom_free_mem->bank[i].start;
+            bank_size =3D hwdom_free_mem->bank[i].size;
+            ASSERT(bank_size >=3D MB(128));
+        }
+        else
+        {
+            const uint64_t bankbase[] =3D GUEST_RAM_BANK_BASES;
+            const uint64_t banksize[] =3D GUEST_RAM_BANK_SIZES;
+
+            if ( i >=3D GUEST_RAM_BANKS )
+                goto fail;
+
+            bank_start =3D bankbase[i];
+            bank_size =3D banksize[i];
+        }
+
+        bank_size =3D MIN(bank_size, kinfo->unassigned_mem);
+        if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(bank_start),
bank_size) )
+            goto fail;
+    }
+
+    if ( kinfo->unassigned_mem )
+        goto fail;
+
+    for( i =3D 0; i < mem->nr_banks; i++ )
+    {
+        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)=
\n",
+               d,
+               i,
+               mem->bank[i].start,
+               mem->bank[i].start + mem->bank[i].size,
+               /* Don't want format this as PRIpaddr (16 digit hex) */
+               (unsigned long)(mem->bank[i].size >> 20));
+    }
+
+    xfree(hwdom_free_mem);
+    return;
+
+fail:
+    panic("Failed to allocate requested domain memory."
+          /* Don't want format this as PRIpaddr (16 digit hex) */
+          " %ldKB unallocated. Fix the VMs configurations.\n",
+          (unsigned long)kinfo->unassigned_mem >> 10);
+}
+
 static int __init handle_pci_range(const struct dt_device_node *dev,
                                    uint64_t addr, uint64_t len, void *data=
)
 {
@@ -1235,7 +1354,7 @@ int __init make_hypervisor_node(struct domain *d,

         ext_regions->max_banks =3D NR_MEM_BANKS;

-        if ( is_domain_direct_mapped(d) )
+        if ( domain_use_host_layout(d) )
         {
             if ( !is_iommu_enabled(d) )
                 res =3D find_host_extended_regions(kinfo, ext_regions);
@@ -2164,8 +2283,11 @@ static int __init construct_dom0(struct domain *d)
     /* type must be set before allocate_memory */
     d->arch.type =3D kinfo.type;
 #endif
-    allocate_memory_11(d, &kinfo);
     find_gnttab_region(d, &kinfo);
+    if ( is_domain_direct_mapped(d) )
+        allocate_memory_11(d, &kinfo);
+    else
+        allocate_memory(d, &kinfo);

     rc =3D process_shm_chosen(d, &kinfo);
     if ( rc < 0 )
diff --git a/xen/arch/arm/include/asm/domain_build.h
b/xen/arch/arm/include/asm/domain_build.h
index e712afbc7f..b0d646e173 100644
--- a/xen/arch/arm/include/asm/domain_build.h
+++ b/xen/arch/arm/include/asm/domain_build.h
@@ -11,6 +11,7 @@ bool allocate_domheap_memory(struct domain *d,
paddr_t tot_size,
                              alloc_domheap_mem_cb cb, void *extra);
 bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
                           paddr_t tot_size);
+void allocate_memory(struct domain *d, struct kernel_info *kinfo);
 int construct_domain(struct domain *d, struct kernel_info *kinfo);
 int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
 int make_chosen_node(const struct kernel_info *kinfo);
@@ -54,6 +55,9 @@ static inline int prepare_acpi(struct domain *d,
struct kernel_info *kinfo)
 int prepare_acpi(struct domain *d, struct kernel_info *kinfo);
 #endif

+typedef int (*add_free_regions_fn)(unsigned long s_gfn, unsigned long e_gf=
n,
+                                   void *data);
+
 int add_ext_regions(unsigned long s_gfn, unsigned long e_gfn, void *data);

 #endif

skip_size can be renamed to threshold_size to make it more clear.

Anyway I'm not following you on the suggested solution: when should I sort =
the
banks, how can I do it in the callback of find_unallocated_memory() and
what if the first biggest bank is lower than 128MB, I should not care for t=
hat?

Thanks.

- Carlo


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 11:34:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 11:34:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856595.1269165 (Exim 4.92)
	(envelope-from )
	id 1tM3vk-0007zy-Tt; Fri, 13 Dec 2024 11:34:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856595.1269165; Fri, 13 Dec 2024 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 1tM3vk-0007zr-Pz; Fri, 13 Dec 2024 11:34:00 +0000
Received: by outflank-mailman (input) for mailman id 856595;
 Fri, 13 Dec 2024 11:33: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 1tM3vj-0007zl-DZ
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 11:33:59 +0000
Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com
 [2607:f8b0:4864:20::12f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2443fa97-b946-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 12:33:58 +0100 (CET)
Received: by mail-il1-x12f.google.com with SMTP id
 e9e14a558f8ab-3a815ed5acfso5650755ab.0
 for ; Fri, 13 Dec 2024 03:33: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: 2443fa97-b946-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734089637; x=1734694437; 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=CnpqPdvmC0fd8qrUabT3ZvDcK97udtTf3U/+QZUvbkI=;
        b=D0agULTL4J6cnNV+nuXXSuoS4wRTUzA9rza4Nb/wFGTrTs9nRoQhOAJ+tFsbfVZMKE
         xCUpDOJWPlWCuzXrpLUYaHuTjJgZkn8wQlla3f2t4F9FJ0ph0VITvBaBiPmbJhCP2TgZ
         QpVUURIaoeoLkgs7ZfcG8671iNk31vmb53scF2iwvcxqiCWSGQu9mL9B3Jj+z/9vOy2g
         aiKuYzlpQyrBlv4ILfp6p/STskkiMEHo61KEPbb24Z89FmFC6wxCQkMy0JzCEsh+5V+m
         t4tsHii8MSxDrokIkKM2yEcuF6xBA2r+bK8C33OOlbzTGv7+DYoXmpJBaJpPJlXoW+LD
         STbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734089637; x=1734694437;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=CnpqPdvmC0fd8qrUabT3ZvDcK97udtTf3U/+QZUvbkI=;
        b=TRNUmPKfHN+XBH9ct3la4Ed69+vbOX0x+bOxVv/PZSrgrHVOUbMY7ln5QVgS9iVL2p
         zGUsVKjtMw7dDG8CFwiRObdPKMNNRZXzYvlW9Fc2XP4+Ti8h4kqRofBL0WeZ3c23r32e
         PjlGSREhrLVEWlLPV6tYQIjJskB9WL7GzuKamgYkLaVf5WZ9RyR9+smKMvBTH8NLBVsw
         KXs1tNJgsIwFF0nhvAnSm6yAwhDiisebG980ve6Lx/poelG2gMVHX6sfQGZ9hyGgfcm5
         +LAUACPdceW2wtUmGA8a4fQ09gm+vL205ukT5mcEeE9MON886x1OVs4EQv8Jhs8PUC55
         V0UA==
X-Forwarded-Encrypted: i=1; AJvYcCXoI/3Sdq6jWoz2zM+TZPzLUThgwc7Fxphi+S8vQybNiYBDkZOijUXJ4RC+q9kj7f+N1JLWfMs9TqM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw44d569NcRAv3Qs8g3JVkgteEkxjfttC41CQMHfvOhXJVV5MCL
	P14Lwa+RuwlSMFOvkxqexXIPwrQZe2YhfN6ZLgetTAhh5D3N0agX7j7gtzD+Nx3jKAQpZ7tFoZG
	F7S+YPFTEpXbSZVRfHK6Q0fi+frORLzrsaITakZUOJHbD/4oLzHUHog==
X-Gm-Gg: ASbGnctI4BeEtj0KW76CJ25+hwu4HY+NLEWCA1WexTdwSfPEkV4BDJ8vlQrK5eafaLx
	MN5EEN/lrdkTcO97Z5t1VHkl9DYloUq7mTbbNug==
X-Google-Smtp-Source: AGHT+IE9TXACnS+Yl7gW0I1j4FiDRHAqiOknphe4zM0QA6aMeq3Zj1GctXhGqM4b+xS/44Sc5x+dROMd3LDJ5hzyCyU=
X-Received: by 2002:a92:c569:0:b0:3a7:172f:1299 with SMTP id
 e9e14a558f8ab-3aff794e4a0mr28272915ab.12.1734089637368; Fri, 13 Dec 2024
 03:33:57 -0800 (PST)
MIME-Version: 1.0
References: <20241202165921.249585-1-carlo.nonato@minervasys.tech>
 <20241202165921.249585-4-carlo.nonato@minervasys.tech> 
 <7ecc99c5-0cb5-4351-bede-cb03c9a4ac7e@xen.org> <293004fa-c87e-4a45-aa4c-b02456aaecea@amd.com>
 <0bacfdb6-d4ad-4dea-85d4-2851873dca4e@xen.org> 
  <2f834c6b-c9fa-4b95-abff-b9bcb8c70246@amd.com>
 
 <6cb8c273-8e1d-4f34-adcc-620d4a71340c@amd.com> 
In-Reply-To: 
From: Carlo Nonato 
Date: Fri, 13 Dec 2024 12:33:46 +0100
Message-ID: 
Subject: Re: [PATCH v11 03/12] xen/arm: permit non direct-mapped Dom0 construction
To: Michal Orzel 
Cc: Andrea Bastoni , Julien Grall , 
	xen-devel@lists.xenproject.org, marco.solieri@minervasys.tech, 
	Stefano Stabellini , Bertrand Marquis , 
	Volodymyr Babchuk 
Content-Type: text/plain; charset="UTF-8"

Using paste.debian:

https://paste.debian.net/1339647/

Thanks.

- Carlo


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 11:43:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 11:43:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856610.1269174 (Exim 4.92)
	(envelope-from )
	id 1tM452-0001Vw-Qf; Fri, 13 Dec 2024 11:43:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856610.1269174; Fri, 13 Dec 2024 11:43: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 1tM452-0001Vp-Nk; Fri, 13 Dec 2024 11:43:36 +0000
Received: by outflank-mailman (input) for mailman id 856610;
 Fri, 13 Dec 2024 11:43: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 1tM451-0001Vh-40
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 11:43:35 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7ab5a55a-b947-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 12:43:32 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-a9a977d6cc7so209981566b.3
 for ; Fri, 13 Dec 2024 03:43:32 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa657abb2fbsm923694366b.128.2024.12.13.03.43.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 03:43: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: 7ab5a55a-b947-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734090212; x=1734695012; 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=FOWIjBrUSmtWfAUEiXqLdAYPmIjAV9uIRyweQXpirq4=;
        b=TlIK5k5Yk8Ds/ZPalHgxIU1VPptQUUDJy+qs36/difPHlq1gq8jSbdxPPBLfAPQ1dY
         FFjo5g0XjiCJskTD+5JZOhMAbzqthfjA/VvIEWEyz8sfKjYNWEivqapdNu2a+XAyrTLG
         uTUpyy++vE7qmGa+D8rwSgfg+KsqB82Tf9h2k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734090212; x=1734695012;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=FOWIjBrUSmtWfAUEiXqLdAYPmIjAV9uIRyweQXpirq4=;
        b=F61METOA8l4w4cSercCakCi2L943WfSjs2BWpbTgCVwYIskvUDRs5pLcDM7bw54UI8
         Ezwqbl5JS5UU+7Nzt/05lW3Vucu4FjRfXZH3Zh5Tp8bfcqK52M05/1C5Gp2louG1th7c
         yDm3Vi2LTUi67BjSl0evBKG2BQgYEr/SQEj1g3o3yN0uZgzfs3zBtt1nAUAMQCobodQw
         Xzc2arKAZUVsuju6A+G+Q69+ZV2sHQ7Tv6DQBiyr4VSL0APHPFlOE1ZTAgjm+ts0J+fo
         vDKBrqwLbaq8bc4XcSf3HBnSTPhItVtfTqeNPWWG3pnZl2ptumLXXanbYlYKEM9T2hmJ
         TxqQ==
X-Gm-Message-State: AOJu0Ywjg03i2s6zVeB6zkFO8sDXXnKV5CmxlKmNE49lyOv/X5UukGPF
	pnl74yD0aBP2IGyYgm2ui/u85BYzyEXmhPVsEXWKxs3hvuQJKxR8mkt6L+larA4=
X-Gm-Gg: ASbGncvTVDQKhi7AfEVuo/cC0k2MZaOdJ88HoTX8SnPgS4fQuKZTSh/TZ5OydeVarAX
	PxmpkL22UOmZy+sxnGLrJ9+HHSxzT9GUq7hU7LECfFOoIJ/JUoJQJ+38tEiRKL4nzYwC8VeNKfX
	Es278X8dXRX9juH2uSujczJUy7vtrqBnrlB4ZZkPptBMRQSqKzs0JPXqbDUcVc1w1s78vPxoVSi
	cew6JG2i/0ieihFSeVbYnrw1SMjjg6ny638ct/JT0VP68vw/HIqYsetciDz0aKlpA==
X-Google-Smtp-Source: AGHT+IH59v9d25D+Hpdx44vY5oqphbmne2u/4bMGWMaFkloX3VYJk2aFTeDnVg+/HyeMGCdWOjmtsA==
X-Received: by 2002:a05:6402:40cf:b0:5d3:ba42:e9fa with SMTP id 4fb4d7f45d1cf-5d63c3405a8mr4777134a12.16.1734090211500;
        Fri, 13 Dec 2024 03:43:31 -0800 (PST)
Date: Fri, 13 Dec 2024 12:43:30 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 31/35] x86/hvm: introduce NS8250 UART emulator
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-31-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-31-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:42:01PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Add initial in-hypervisor emulator for NS8250/NS16x50-compatible UARTs under
> CONFIG_HAS_VUART_NS8250.
> 
> In parallel domain creation scenario (hyperlaunch), NS8520 emulator helps
> early guest OS bringup debugging, because it eliminates dependency on the
> external emulator being operational by the time domains are created. Also,
> there's no early console facility similar to vpl011 to support x86 guest OS
> bring up.
> 
> By default, CONFIG_HAS_VUART_NS8250 enables emulatio of NS8250 at I/O port

emulatio -> emulation

> 0x3f8, IRQ#4 in guest OS.
> 
> Limitations:
> - Only x86;
> - Only Linux guest tested so far;
> - Only legacy COM{1,2,3,4} resources, no customization;
> - Only Xen console as a backend, no inter-domain communication (similar to
>   vpl011 on Arm);
> - Only 8-bit characters;
> - Baud rate is not emulated;
> - FIFO-less mode is not emulated properly;
> - RX FIFO interrupt moderation (FCR) is not emulated properly, TL16C750
>   has special FCR handling;
> - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and
>   friends);
> - Assumes no ISA-device IRQ sharing;
> - MMIO-based UART is not supported.

Do you have a reference to the specification you have used to
implement the driver?

Most of the comments below are quite generic, I haven't really looked
into the implementation details of the ns8520 emulated registers.

> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/arch/x86/hvm/Kconfig                    |  14 +
>  xen/arch/x86/hvm/Makefile                   |   1 +
>  xen/arch/x86/hvm/hvm.c                      |  13 +
>  xen/arch/x86/hvm/vuart_ns8250.c             | 886 ++++++++++++++++++++++++++++
>  xen/arch/x86/include/asm/hvm/domain.h       |   5 +
>  xen/arch/x86/include/asm/hvm/vuart_ns8250.h |  75 +++
>  6 files changed, 994 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig
> index 361bb6572e633f3cf0fc972a3b391e8341c33361..af6e698b8be0d82af94b00c0cfdaf9a2bc24b154 100644
> --- a/xen/arch/x86/hvm/Kconfig
> +++ b/xen/arch/x86/hvm/Kconfig
> @@ -61,3 +61,17 @@ config HVM_FEP
>  	  for use in production.
>  
>  	  If unsure, say N.
> +
> +config HAS_VUART_NS8250
> +	bool "NS8250-compatible UART Emulation"
> +	depends on HVM && HAS_IOPORTS
> +	default n
> +	help
> +	  In-hypervisor NS8250/NS16x50 UART emulation.
> +
> +	  Only legacy PC I/O ports are emulated.
> +
> +	  This is strictly for testing purposes (early HVM guest console), and not
> +	  appropriate for use in production.

If it's strictly speaking for debug purposes, then it might be helpful
to tie it to CONFIG_DEBUG, or if maybe that's too broad, make it tied
to CONFIG_EXPERT, so that it's clear builds wit the option enabled
won't be security supported.

> +
> +	  If unsure, say N.
> diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
> index 4c1fa5c6c2bf75d336b39f343241bfced5b91b09..14761435e0694109f815da63289666c0f1cbf0ce 100644
> --- a/xen/arch/x86/hvm/Makefile
> +++ b/xen/arch/x86/hvm/Makefile
> @@ -29,3 +29,4 @@ obj-y += vm_event.o
>  obj-y += vmsi.o
>  obj-y += vpic.o
>  obj-y += vpt.o
> +obj-$(CONFIG_HAS_VUART_NS8250) += vuart_ns8250.o
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 493b699c708949b2109c26573a107565543f5d45..db61af7defc5f5da795b7a613fe4d32fbff7d93e 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -55,6 +55,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -679,6 +680,15 @@ int hvm_domain_initialise(struct domain *d,
>      if ( rc != 0 )
>          goto fail1;
>  
> +    if ( domain_has_vuart(d) )
> +    {
> +        rc = domain_vuart_init(d);
> +        if ( rc == 0 )
> +            d->is_console = true;
> +        else if ( rc != -ENODEV )
> +            goto out_vioapic_deinit;

Why do you shallow the ENODEV error?  If a user has asked for a vUART,
and there's no support in Xen it should error hard IMO, rather than
ignoring it and continue building the domain.

IMO emulation_flags_ok() should prevent hvm_domain_initialise() from
being called with vUART when there's no support built-in.

> +    }
> +
>      stdvga_init(d);
>  
>      rtc_init(d);
> @@ -699,6 +709,9 @@ int hvm_domain_initialise(struct domain *d,
>      return 0;
>  
>   fail2:
> +    if ( domain_has_vuart(d) )
> +        domain_vuart_free(d);
> + out_vioapic_deinit:
>      vioapic_deinit(d);
>   fail1:
>      if ( is_hardware_domain(d) )
> diff --git a/xen/arch/x86/hvm/vuart_ns8250.c b/xen/arch/x86/hvm/vuart_ns8250.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..779dbd80d7be4e070ea9df3ae736ecdc662a527a
> --- /dev/null
> +++ b/xen/arch/x86/hvm/vuart_ns8250.c
> @@ -0,0 +1,886 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * NS8250-compatible UART Emulator.
> + *
> + * Limitations:
> + * - Only x86;
> + * - Only Linux guest tested so far;
> + * - Only legacy COM{1,2,3,4} resources, no customization;
> + * - Only Xen console as a backend, no inter-domain communication (similar to
> + *   vpl011 on Arm);
> + * - Only 8-bit characters;
> + * - Baud rate is not emulated;
> + * - FIFO-less mode is not emulated properly;
> + * - RX FIFO interrupt moderation (FCR) is not emulated properly, TL16C750
> + *   has special FCR handling;
> + * - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and
> + *   friends);
> + * - Assumes no ISA-device IRQ sharing;
> + * - MMIO-based UART is not supported;
> + * - PCI UART is not supported.

IMO putting the limitations here is likely to make them go out of
sync, noting in the commit message should be enough.

> + */
> +
> +#define pr_fmt(fmt)         "ns8250: " fmt
> +#define pr_log_level        hvm_ns8250_log_level
> +
> +/* Development debugging */
> +#define NS8250_LOG_LEVEL    0
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include  /* console_input_domid() */

Includes would be better sorted alphabetically if possible.

> +#include    /* max_init_domid */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#if !defined(pr_fmt)
> +#define pr_fmt(fmt) fmt
> +#endif
> +
> +#if !defined(pr_log_level)
> +#define pr_log_level 0
> +#endif
> +
> +#define pr_err(fmt, args...) \
> +    gprintk(KERN_ERR, pr_fmt(fmt), ## args)
> +#define pr_warn(fmt, args...) \
> +    if (pr_log_level) gprintk(KERN_WARNING, pr_fmt(fmt), ## args)
> +#define pr_info(fmt, args...) \
> +    if (pr_log_level) gprintk(KERN_INFO, pr_fmt(fmt), ## args)
> +#define pr_debug(fmt, args...) \
> +    if (pr_log_level) gprintk(KERN_DEBUG, pr_fmt(fmt), ## args)

Is there any reason you cannot directly use gprintk() and need those
wrappers?

If the code has been imported from another project it would be good to
have a reference, so that we can pickup updates in the future.

> +
> +/*
> + * NS8250 emulator state machine logging (development only)
> + * FIXME: use similar to parse_guest_loglvl()
> + */
> +static unsigned int __read_mostly hvm_ns8250_log_level = NS8250_LOG_LEVEL;
> +integer_param("hvm.ns8250.log_level", hvm_ns8250_log_level);

WE don't have any existing instances of command line options with
dots, and also the documentation addition to xen-command-line.pandoc
seems to be missing from this patch.

My recommendation would be that the code here just uses normal logs
levels, users can adjust the minimum log level of pritned messages.
Adding ad-hoc log level settings for each subsystem just causes
confusion.

> +
> +/*
> + * Default emulated NS8250 resources.
> + * If not specified, COM1 (I/O port 0x3f8, IRQ#4) is emulated.
> + * FIXME: follow Linux'es console= syntax or re-use
> + * ns16550_parse_port_config().
> + */
> +static char __read_mostly hvm_ns8250_console[64];
> +string_param("hvm.ns8250.console", hvm_ns8250_console);

Same here, there seems to be no documentation about this option.  And
you likely want this to be a custom_param so you can do the parsing
directly instead of storing into a buffer for later parsing.

> +
> +/* I/O access mask */
> +static const uint32_t io_access_mask[] = {
> +    [0] = 0X00000000U,
> +    [1] = 0X000000FFU,
> +    [2] = 0X0000FFFFU,
> +    [4] = 0XFFFFFFFFU,

lowercase x please.

> +};
> +
> +/*
> + * Legacy IBM PC NS8250 resources.
> + * There are only 4 I/O port ranges, hardcoding all of them here.
> + */
> +static const struct {
> +    const char *name;
> +    const struct resource *res;
> +} ns8250_x86_legacy_uarts[4] = {
> +    [0] = {
> +        .name = "com1",
> +        .res = (const struct resource[]){
> +            { .type = IORESOURCE_IO,  .addr = 0x3F8, .size = UART_MAX },
> +            { .type = IORESOURCE_IRQ, .addr = 4,     .size = 1 },
> +            { .type = IORESOURCE_UNKNOWN },
> +        },
> +    },
> +    [1] = {
> +        .name = "com2",
> +        .res = (const struct resource[]){
> +            { .type = IORESOURCE_IO,  .addr = 0x2F8, .size = UART_MAX },
> +            { .type = IORESOURCE_IRQ, .addr = 3,     .size = 1 },
> +            { .type = IORESOURCE_UNKNOWN },
> +        },
> +    },
> +    [2] = {
> +        .name = "com3",
> +        .res = (const struct resource[]){
> +            { .type = IORESOURCE_IO,  .addr = 0x3E8, .size = UART_MAX },
> +            { .type = IORESOURCE_IRQ, .addr = 4,     .size = 1 },
> +            { .type = IORESOURCE_UNKNOWN },
> +        },
> +    },
> +    [3] = {
> +        .name = "com4",
> +        .res = (const struct resource[]){
> +            { .type = IORESOURCE_IO,  .addr = 0x2E8, .size = UART_MAX },
> +            { .type = IORESOURCE_IRQ, .addr = 3,     .size = 1 },
> +            { .type = IORESOURCE_UNKNOWN },
> +        },
> +    },
> +};
> +
> +static bool ns8250_fifo_rx_empty(struct vuart_ns8250 *vdev)
> +{
> +    struct xencons_interface *cons = vdev->cons;

const here and in the function parameter.

> +
> +    return cons->in_prod == cons->in_cons;
> +}
> +
> +static bool ns8250_fifo_rx_full(struct vuart_ns8250 *vdev)
> +{
> +    struct xencons_interface *cons = vdev->cons;

const here and in the function parameter.

> +
> +    return cons->in_prod - cons->in_cons == sizeof(cons->in);
> +}
> +
> +static void ns8250_fifo_rx_reset(struct vuart_ns8250 *vdev)
> +{
> +    struct xencons_interface *cons = vdev->cons;
> +
> +    cons->in_cons = cons->in_prod;
> +}
> +
> +static int ns8250_fifo_rx_getchar(struct vuart_ns8250 *vdev)
> +{
> +    struct xencons_interface *cons = vdev->cons;
> +    int rc = -1;

-ENOENT maybe instead of -1?

> +
> +    if ( !ns8250_fifo_rx_empty(vdev) )
> +    {
> +        rc = cons->in[MASK_XENCONS_IDX(cons->in_cons, cons->in)];
> +        cons->in_cons++;
> +    }
> +
> +    return rc;
> +}
> +
> +static int ns8250_fifo_rx_putchar(struct vuart_ns8250 *vdev, char c)
> +{
> +    struct xencons_interface *cons = vdev->cons;
> +    int rc = 0;
> +
> +    /*
> +     * FIFO-less 8250/16450 UARTs: newly arrived word overwrites the contents
> +     * of the THR.
> +     */
> +    if ( ns8250_fifo_rx_full(vdev) )
> +    {
> +        ns8250_fifo_rx_reset(vdev);
> +        rc = -ENOSPC;
> +    }
> +
> +    cons->in[MASK_XENCONS_IDX(cons->in_prod, cons->in)] = c;
> +    cons->in_prod++;
> +
> +    return rc;
> +}
> +
> +/*
> + * Flush cached output to Xen console.
> + * Can be called from ns8250_exit().
> + */
> +static void ns8250_fifo_tx_reset(struct vuart_ns8250 *vdev)
> +{
> +    struct xencons_interface *cons = vdev->cons;
> +
> +    if ( cons->out_prod == 0 )

Don't you need to check that cons->out_prod == cons->out_cons instead?

> +        return;
> +
> +    cons->out[cons->out_prod++] = '\0';

You need to use MASK_XENCONS_IDX() otherwise this could result in a
buffer overflow?

If you expect (because of checks in other places) out_prod to always
be < ring size - 1, please add an assert to that extent here.  But see
below about the usage of the ring indexes.

Also, no need for the trailing increment, you will unconditionally
reset out_prod to 0 just below.

> +
> +    /*
> +     * NB: do not show domain ID if the domain owning the virtual UART also
> +     * owns Xen input console.
> +     */
> +    if ( vdev->owner->domain_id == console_owner_domid() )
> +        printk_common("%s", cons->out);
> +    else
> +        guest_printk(vdev->owner, "%s", cons->out);
> +
> +    cons->out_prod = 0;

You should rather do cons->out_cons = cons->out_prod?

Wait, you seem to use the out buffer differently than the input one,
and only advance out_prod but not out_cons?

It seems weird to drive the 'in' ring using both indexes, while the
'out' ring is just using one index.

> +}
> +
> +/*
> + * Send a character to Xen console.
> + */
> +static void ns8250_fifo_tx_putchar(struct vuart_ns8250 *vdev, char ch)
> +{
> +    struct xencons_interface *cons = vdev->cons;
> +
> +    if ( !isconsole(ch) )
> +        return;
> +
> +    cons->out[cons->out_prod] = ch;
> +    cons->out_prod++;
> +
> +    if ( cons->out_prod == ARRAY_SIZE(cons->out) - 1
> +            || ch == '\n' || ch == '\0' )

Bad indentation, should be:

    if ( cons->out_prod == ARRAY_SIZE(cons->out) - 1 ||
         ch == '\n' || ch == '\0' )

Albeit I'm not sure you need the '\0' check, as isconsole('\0') will
already return false?

> +        ns8250_fifo_tx_reset(vdev);
> +}
> +
> +static bool cf_check ns8250_iir_check_lsi(struct vuart_ns8250 *vdev)

vdev should be const.

> +{
> +    return  !!( vdev->regs[UART_LSR] & UART_LSR_MASK );

Extra spaces around the parentheses.

> +}
> +
> +static bool cf_check ns8250_iir_check_rda(struct vuart_ns8250 *vdev)
> +{
> +    return !ns8250_fifo_rx_empty(vdev);
> +}
> +
> +static bool cf_check ns8250_iir_check_thr(struct vuart_ns8250 *vdev)
> +{
> +    return !!( vdev->flags & NS8250_IRQ_THRE_PENDING );
> +}
> +
> +static bool cf_check ns8250_iir_check_msi(struct vuart_ns8250 *vdev)

const for all the 3 vdev parameters above.

> +{
> +    return !!( vdev->regs[UART_MSR] & UART_MSR_DELTA );

Extra spaces around the parentheses.

> +}
> +
> +/*
> + * Interrupt identity reasons by priority.
> + * NB: highest priority are at lower indexes.
> + */
> +static const struct {
> +    uint8_t ier_mask;
> +    uint8_t iir_mask;
> +    bool (*iir_check)(struct vuart_ns8250 *vdev);
> +} iir_by_prio[] = {
> +    [0] = { UART_IER_ELSI,   UART_IIR_LSI, ns8250_iir_check_lsi },
> +    [1] = { UART_IER_ERDAI,  UART_IIR_RDA, ns8250_iir_check_rda },
> +    [2] = { UART_IER_ETHREI, UART_IIR_THR, ns8250_iir_check_thr },
> +    [3] = { UART_IER_EMSI,   UART_IIR_MSI, ns8250_iir_check_msi },

You don't need the explicit array indexes (at least with the ones you
are specifying here).

I think those interrupt reasons are not likely to change, and the
checker for each reason is a one line function.  It would be better to
open-code the checking in ns8250_irq_reason(), as that will avoid the
indirect function call.

Otherwise iir_by_prio array should be declared in the scope of
ns8250_irq_reason(), as that's the only function where it's used.

> +};
> +
> +/*
> + * Define the interrupt identity reason.
> + * NB: NS8250 always reports high priority events first.
> + */
> +static uint8_t ns8250_irq_reason(struct vuart_ns8250 *vdev)
> +{
> +    int i;

unsigned int.

> +
> +    ASSERT( spin_is_locked(&vdev->lock) );

Extra spaces around the parentheses.

> +    for ( i = 0; i < ARRAY_SIZE(iir_by_prio); i++ )
> +    {
> +        if ( (vdev->regs[UART_IER] & iir_by_prio[i].ier_mask)
> +                && iir_by_prio[i].iir_check(vdev) )

Wrong placement of the &&, plus indentation.

> +            return iir_by_prio[i].iir_mask;
> +    }
> +
> +    return UART_IIR_NOINT;
> +}
> +
> +/*
> + * Assert virtual NS8250 interrupt line.
> + */
> +static void ns8250_irq_assert(struct vuart_ns8250 *vdev)
> +{
> +    uint8_t iir;
> +
> +    iir = ns8250_irq_reason(vdev);
> +    if (iir & UART_IIR_NOINT)

Missing spaces around the parentheses.

> +        hvm_irq_lower(vdev->owner, vdev->irq);
> +    else
> +        hvm_irq_raise(vdev->owner, vdev->irq);

I think you should use hvm_isa_irq_{,de}assert(), as the interrupt
will unconditionally be < 16?

> +
> +    pr_debug("IRQ#%d %x %s\n", vdev->irq, iir,
> +            !!(iir & UART_IIR_NOINT) ? "lower" : "raise");

hm, this will get very verbose.  While it might have been helpful
during development, I don't think it would be appropriate to print at
any debug level.

> +}
> +
> +/*
> + * Emulate 8-bit write access to NS8250 register.
> + */
> +static int ns8250_io_write8(
> +    struct vuart_ns8250 *vdev, uint32_t reg, uint8_t *data)
> +{
> +    uint8_t val;
> +    int rc = 0;
> +
> +    val = *data;

You can init val at declaration.

> +
> +    switch ( reg )
> +    {
> +    /* DLAB=0 */
> +    case UART_THR:
> +        if ( vdev->regs[UART_MCR] & UART_MCR_LOOP )
> +        {
> +            ns8250_fifo_rx_putchar(vdev, val);
> +            vdev->regs[UART_LSR] |= UART_LSR_OE;
> +        }
> +        else
> +            ns8250_fifo_tx_putchar(vdev, val);
> +
> +        vdev->flags |= NS8250_IRQ_THRE_PENDING;
> +
> +        break;
> +
> +    case UART_IER:
> +        if ( val & vdev->regs[UART_IER] & UART_IER_ETHREI )
> +            vdev->flags |= NS8250_IRQ_THRE_PENDING;
> +
> +        vdev->regs[UART_IER] = val & UART_IER_MASK;
> +
> +        break;
> +
> +    case UART_FCR: /* WO */
> +        if ( val & UART_FCR_CLRX )
> +            ns8250_fifo_rx_reset(vdev);
> +
> +        if ( val & UART_FCR_CLTX )
> +            ns8250_fifo_tx_reset(vdev);
> +
> +        if ( !(val & UART_FCR_ENABLE) )
> +            val = 0;
> +
> +        vdev->regs[UART_FCR] = val & (UART_FCR_ENABLE |
> +                                      UART_FCR_DMA |
> +                                      UART_FCR_TRG_MASK);
> +
> +        break;
> +
> +    case UART_LCR:
> +        vdev->regs[UART_LCR] = val;
> +        break;
> +
> +    case UART_MCR: {
> +        uint8_t msr_curr, msr_next, msr_delta;
> +
> +        msr_curr = vdev->regs[UART_MSR];
> +        msr_next = 0;
> +        msr_delta = 0;
> +
> +        /* Set modem status */
> +        if ( val & UART_MCR_LOOP )
> +        {
> +            if ( val & UART_MCR_DTR )
> +                msr_next |= UART_MSR_DSR;
> +            if ( val & UART_MCR_RTS )
> +                msr_next |= UART_MSR_CTS;
> +            if ( val & UART_MCR_OUT1 )
> +                msr_next |= UART_MSR_RI;
> +            if ( val & UART_MCR_OUT2 )
> +                msr_next |= UART_MSR_DCD;
> +        }
> +        else
> +            msr_next |= UART_MSR_DCD | UART_MSR_DSR | UART_MSR_CTS;
> +
> +        /* Calculate changes in modem status */
> +        if ( (msr_curr & UART_MSR_CTS) ^ (msr_next & UART_MSR_CTS) )
> +            msr_delta |= UART_MSR_DCTS;
> +        if ( (msr_curr & UART_MCR_RTS) ^ (msr_next & UART_MCR_RTS) )
> +            msr_delta |= UART_MSR_DDSR;
> +        if ( (msr_curr & UART_MSR_RI)  & (msr_next & UART_MSR_RI) )
> +            msr_delta |= UART_MSR_TERI;
> +        if ( (msr_curr & UART_MSR_DCD) ^ (msr_next & UART_MSR_DCD) )
> +            msr_delta |= UART_MSR_DDCD;
> +
> +        vdev->regs[UART_MCR] = val & UART_MCR_MASK;
> +        vdev->regs[UART_MSR] = msr_next | msr_delta;
> +
> +        break;
> +    }
> +
> +    case UART_LSR: /* RO */
> +    case UART_MSR: /* RO */
> +        rc = -EINVAL;
> +        break;

Why are those not handled by the default case below?  Is there any
reason to explicitly mention those cases?

> +
> +    /*
> +     * NB: Firmware like OVMF rely on SCR presence to initialize the ns8250
> +     * driver.
> +     */
> +    case UART_SCR:
> +        vdev->regs[UART_SCR] = val;
> +        break;
> +
> +    /* DLAB=1 */
> +    case UART_MAX + UART_DLL:
> +        vdev->dl = (vdev->dl & 0xFF00U) | val;
> +        break;
> +
> +    case UART_MAX + UART_DLM:
> +        vdev->dl = (val << 8) | (vdev->dl & 0x00FFU);
> +        break;
> +
> +    default:
> +        rc = -EINVAL;
> +        break;

Returning -EINVAL here is not correct I think, as the error gets
propagated into the return of the IO handler.  Those handlers expect
to return a code in the range of X86EMUL_OKAY (see x86_emulate.h).

But most importantly, what do you expect the caller to do with such
error code?  The access must be handled by the console driver, as it
belongs to it's range of IO ports.  What would hardware do in this
case, ignore the write and continue operation?

If so, there's no point in returning any error from
ns8250_io_write8(), the best would be to log a debug message in case
of ignored accesses.  This likely applies to all the handlers
implemented below.

> +    }
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate 16-bit write access to NS8250 register.
> + * NB: some guest OSes use outw() to access UART_DLL.
> + */
> +static int ns8250_io_write16(
> +    struct vuart_ns8250 *vdev, uint32_t reg, uint16_t *data)
> +{
> +    int rc;
> +
> +    switch ( reg )
> +    {
> +    case UART_MAX + UART_DLL:
> +        vdev->dl = *data;
> +        rc = 0;
> +        break;
> +
> +    default:
> +        rc = -EINVAL;
> +        break;
> +    }
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate write access to NS8250 register.
> + */
> +static int ns8250_io_write(
> +    struct vuart_ns8250 *vdev, uint8_t reg, uint32_t size, uint32_t *data)
> +{
> +    int rc = -EINVAL;
> +
> +    switch ( size )
> +    {
> +    case 1:
> +        rc = ns8250_io_write8(vdev, reg, (uint8_t *)data);
> +        break;
> +
> +    case 2:
> +        rc = ns8250_io_write16(vdev, reg, (uint16_t *)data);
> +        break;
> +
> +    default:
> +        break;
> +    }
> +
> +    ns8250_irq_assert(vdev);
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate 8-bit read access to NS8250 register.
> + */
> +static int ns8250_io_read8(
> +    struct vuart_ns8250 *vdev, uint32_t reg, uint8_t *data)
> +{
> +    int rc = 0;
> +    uint8_t val;

In order to avoid unintentionally leaking stack contents, it would be
best to initialize val at declaration:

uint8_t val = ~0;

> +
> +    switch ( reg )
> +    {
> +    /* DLAB=0 */
> +    case UART_RBR:
> +        val = (uint8_t)ns8250_fifo_rx_getchar(vdev);

You seem to ignore that ns8250_fifo_rx_getchar() can return an error,
is it intended to just propagate the error to the caller then?

> +        /* NB: do not forget to clear overrun condition */
> +        vdev->regs[UART_LSR] &= ~UART_LSR_OE;
> +        break;
> +
> +    case UART_IER: /* RO */
> +        val = vdev->regs[UART_IER];
> +        break;
> +
> +    case UART_IIR:
> +        val = ns8250_irq_reason(vdev);
> +        if ( val & UART_IIR_THR )
> +            vdev->flags &= ~NS8250_IRQ_THRE_PENDING;
> +
> +        if ( vdev->regs[UART_FCR] & UART_FCR_ENABLE )
> +            val |= UART_IIR_FE_MASK;
> +
> +        break;
> +
> +    case UART_LCR:
> +        val = vdev->regs[UART_LCR];
> +        break;
> +
> +    case UART_MCR:
> +        val = vdev->regs[UART_MCR];
> +        break;
> +
> +    case UART_LSR:
> +        val = vdev->regs[UART_LSR] | UART_LSR_THRE | UART_LSR_TEMT;
> +        if ( ns8250_fifo_rx_empty(vdev) )
> +            val &= ~UART_LSR_DR;
> +        else
> +            val |= UART_LSR_DR;
> +
> +        vdev->regs[UART_LSR] = val & ~UART_LSR_MASK;
> +
> +        break;
> +
> +    case UART_MSR:
> +        val = vdev->regs[UART_MSR];
> +        vdev->regs[UART_MSR] &= ~UART_MSR_DELTA;
> +        break;
> +
> +    case UART_SCR:
> +        val = vdev->regs[UART_SCR];
> +        break;
> +
> +    /* DLAB=1 */
> +    case UART_MAX + UART_DLL:
> +        val = vdev->dl & 0xFFU;
> +        break;
> +
> +    case UART_MAX + UART_DLM:
> +        val = vdev->dl >> 8;
> +        break;
> +
> +    default:
> +        val = (uint8_t)io_access_mask[1];

Hm, not sure why you need this mask, isn't it OK to just do val = ~0;?

However see comment above about initializing at definition.

> +        rc = -EINVAL;
> +        break;
> +    }
> +
> +    *data = val;
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate 16-bit read access to NS8250 register.
> + */
> +static int ns8250_io_read16(
> +    struct vuart_ns8250 *vdev, uint32_t reg, uint16_t *data)
> +{
> +    uint16_t val;

Same comment as ns8250_io_read8() about initializing val at definition
and not using io_access_mask.

> +    int rc;
> +
> +    switch ( reg )
> +    {
> +    case UART_MAX + UART_DLL:
> +        val = vdev->dl;
> +        rc = 0;
> +        break;
> +
> +    default:
> +        val = (uint16_t)io_access_mask[2];
> +        rc = -EINVAL;
> +        break;
> +    }
> +
> +    *data = val;
> +
> +    return rc;
> +}
> +
> +/*
> + * Emulate read access to NS8250 register.
> + */
> +static int ns8250_io_read(
> +    struct vuart_ns8250 *vdev, uint8_t reg, uint32_t size, uint32_t *data)
> +{
> +    int rc;
> +
> +    switch ( size )
> +    {
> +    case 1:
> +        rc = ns8250_io_read8(vdev, reg, (uint8_t *)data);
> +        break;
> +
> +    case 2:
> +        rc = ns8250_io_read16(vdev, reg, (uint16_t *)data);

I get the feeling you could handle both 1 and 2 byte accesses in the
same function, as there's just a single register that allows 2 byte
accesses.

Is the split done because further (to be implemented) features will
require addition 2 byte accesses?

> +        break;
> +
> +    default:
> +        *data = io_access_mask[size];
> +        rc = -EINVAL;
> +        break;
> +    }
> +
> +    ns8250_irq_assert(vdev);
> +
> +    return rc;
> +}
> +
> +static const char *ns8250_regname(
> +    const struct vuart_ns8250 *vdev, uint32_t reg, int dir)
> +{
> +    static const char *reg_names[UART_MAX + 2][2] = {
> +        /* register                 W      R   */
> +        [UART_RBR] =            { "THR", "RBR" },
> +        [UART_IER] =            { "IER", "IER" },
> +        [UART_IIR] =            { "FCR", "IIR" },
> +        [UART_LCR] =            { "LCR", "LCR" },
> +        [UART_MCR] =            { "MCR", "MCR" },
> +        [UART_LSR] =            { "LSR", "LSR" },
> +        [UART_MSR] =            { "MSR", "MSR" },
> +        [UART_SCR] =            { "SCR", "SCR" },
> +        [UART_MAX + UART_DLL] = { "DLL", "DLL" },
> +        [UART_MAX + UART_DLM] = { "DLM", "DLM" },
> +    };
> +

To be in the safe saide I would assert that 'reg' and 'dir' are
between the array bounds.

> +    return reg_names[reg][dir];
> +}
> +
> +/*
> + * Emulate I/O access to NS8250 register.
> + */
> +static int cf_check ns8250_io_handle(
> +    int dir, unsigned int addr, unsigned int size, uint32_t *data)
> +{
> +#define op(dir)     (((dir) == IOREQ_WRITE) ? 'W' : 'R')
> +    struct domain *d = rcu_lock_current_domain();
> +    struct vuart_ns8250 *vdev = &d->arch.hvm.vuart;
> +    uint32_t offset, reg;
> +    int rc;
> +
> +    spin_lock(&vdev->lock);
> +
> +    BUG_ON( vdev->owner != d );

Extra spaces around the parentheses.

However I would rather use:

if ( vdev->owner != d )
{
    gprintk(XENLOG_ERR, "vUART owner %pd doesn't match current domain\n",
            vdev->owner);
    ASSERT_UNREACHABLE();
    rcu_unlock_domain(d);
    return X86EMU_OKAY;
}

And place it before the spin_lock() call.

> +
> +    if ( !(vdev->flags & NS8250_READY) )
> +    {
> +        pr_err("%c io 0x%04x %d 0x%08"PRIx32": propagate to external I/O emulator\n",
> +                op(dir), addr, size, *data);
> +        rc = X86EMUL_UNHANDLEABLE;

I think you need to unconditionally return X86EMU_OKAY and just ignore
the access.  I assume there's no point in attempting to forward this
access to any other handler, as it must be handled by the vuart
driver.

> +        goto out;
> +    }
> +
> +    reg = addr - vdev->io_addr;
> +    BUG_ON( reg >= UART_MAX );

If possible, might be best to use a construct similar to the one
proposed above with ASSERT_UNREACHABLE().

> +    if ( reg % size != 0 )

IS_ALIGNED(reg, size)  might be clearer.

> +    {
> +        pr_err("%c 0x%04x %d 0x%08"PRIx32": unaligned access\n",
> +                op(dir), addr, size, *data & io_access_mask[size]);
> +        rc = X86EMUL_OKAY;
> +        goto out;
> +    }
> +
> +    /* Redirect access to divisor latch registers */
> +    if ( !!(vdev->regs[UART_LCR] & UART_LCR_DLAB)
> +            && (reg == UART_DLL || reg == UART_DLM) )

Indentation plus placement of the &&.

> +        offset = UART_MAX + reg;
> +    else
> +        offset = reg;
> +
> +    if ( dir == IOREQ_WRITE )
> +    {
> +        pr_debug("%c 0x%04x %d 0x%08"PRIx32" %s[0x%02"PRIx32"]\n",
> +                op(dir), addr, size,
> +                *data & io_access_mask[size],
> +                ns8250_regname(vdev, offset, dir), reg);
> +        rc = ns8250_io_write(vdev, offset, size, data);
> +    }
> +    else
> +    {
> +        rc = ns8250_io_read(vdev, offset, size, data);
> +        pr_debug("%c 0x%04x %d 0x%08"PRIx32" %s[0x%02"PRIx32"]\n",
> +                op(dir), addr, size,
> +                *data & io_access_mask[size],
> +                ns8250_regname(vdev, offset, dir), reg);

The pr_debug() are likely too verbose.

> +    }
> +    if ( rc )
> +        pr_err("%c 0x%04x %d 0x%08"PRIx32": unsupported access\n",
> +                op(dir), addr, size, *data & io_access_mask[size]);
> +    rc = X86EMUL_OKAY;
> +
> +out:
> +    spin_unlock(&vdev->lock);

You seem to have forgotten a rcu_unlock_domain() call here?  (even if
it's a no-op).

> +
> +    return rc;
> +#undef op
> +}
> +
> +/*
> + * Parse virtual NS8250 configuration.
> + *   hvm.ns8250.console=[com1|com2|com3|com4]
> + */
> +static const struct resource *ns8250_parse(void)
> +{
> +    int i;
> +
> +    for ( i = 0; i < ARRAY_SIZE(ns8250_x86_legacy_uarts); i++ )
> +        if ( !strcasecmp(hvm_ns8250_console, ns8250_x86_legacy_uarts[i].name) )
> +            return ns8250_x86_legacy_uarts[i].res;
> +
> +    return ns8250_x86_legacy_uarts[0].res;
> +}
> +
> +/*
> + * Claim virtual NS8250 resources to domain.
> + */
> +static int ns8250_claim(
> +    struct vuart_ns8250 *vdev, const struct resource *r, struct domain *d)
> +{
> +    unsigned long size;
> +    unsigned long start;
> +    unsigned long end;
> +
> +    vdev->irq = NO_IRQ;
> +    vdev->io_addr = IORESOURCE_UNKNOWN;
> +    vdev->io_size = IORESOURCE_UNKNOWN;
> +
> +    foreach_resource(r)
> +    {
> +        if ( r->type & IORESOURCE_IO )
> +        {
> +            size = r->size;
> +            start = r->addr;
> +            end = r->addr + r->size - 1;
> +
> +            if ( !ioports_access_permitted(d, start, end) )
> +                ioports_permit_access(d, start, end);

Are you sure this is intended?  By using ioports_permit_access() you
are giving the domain access to the hardware (host) IO ports, and thus
possibly avoiding the trapping into the IO handlers.

However this is not very well-wired in HVM, because there's still an
extra guest IO port -> host IO port translation that you are not
adding.

You shouldn't need the ioports_permit_access() for using the emulated
vUART.

> +
> +            register_portio_handler(d, start, size, ns8250_io_handle);
> +
> +            /* Used to assert I/O port handler */
> +            vdev->io_addr = start;
> +            vdev->io_size = size;
> +        }
> +        else if ( r->type & IORESOURCE_IRQ )
> +            /* "Claim" virtual IRQ; assumes no ISA-device IRQ sharing */
> +            vdev->irq = r->addr;
> +        else
> +            return -EINVAL;
> +    }
> +
> +    if ( vdev->irq == NO_IRQ
> +            || vdev->io_addr == IORESOURCE_UNKNOWN
> +            || vdev->io_size == IORESOURCE_UNKNOWN )
> +        return -ENODEV;
> +
> +    return 0;
> +}
> +
> +/*
> + * Unclaim virtual NS8250 resources.
> + */
> +static void ns8250_unclaim(struct vuart_ns8250 *vdev, struct domain *d)
> +{
> +    unsigned long size = vdev->io_size;
> +    unsigned long start = vdev->io_addr;
> +    unsigned long end = start + size - 1;
> +
> +    if ( ioports_access_permitted(d, start, end) )
> +        ioports_deny_access(d, start, size);
> +}
> +
> +static int ns8250_init(struct domain *d, const struct resource *r)
> +{
> +    struct vuart_ns8250 *vdev = &d->arch.hvm.vuart;
> +    struct xencons_interface *cons;
> +    int rc;
> +
> +    cons = _xzalloc(sizeof(*vdev->cons), sizeof(void *));

xvzalloc(typeof(*vdev->cons));

> +    if ( cons == NULL )
> +        return -ENOMEM;
> +
> +    rc = ns8250_claim(vdev, r, d);
> +    if ( rc )
> +    {
> +        xfree(cons);
> +        return rc;
> +    }
> +
> +    spin_lock_init(&vdev->lock);
> +    hvm_irq_lower(d, vdev->irq);
> +
> +    vdev->dl = (UART_CLOCK_HZ / 115200) >> 4; /* Report 115200 baud rate */
> +    vdev->cons = cons;
> +    vdev->owner = d;
> +    vdev->flags = NS8250_READY | NS8250_IRQ_THRE_PENDING;
> +
> +    return 0;
> +}
> +
> +static void ns8250_exit(struct domain *d)
> +{
> +    struct vuart_ns8250 *vdev = &d->arch.hvm.vuart;
> +
> +    spin_lock(&vdev->lock);
> +
> +    if ( !(vdev->flags & NS8250_READY) )
> +        goto out;
> +
> +    ns8250_unclaim(vdev, d);
> +    ns8250_fifo_tx_reset(vdev);
> +    xfree(vdev->cons);
> +
> +    vdev->cons = NULL;
> +    vdev->owner = NULL;
> +    vdev->flags = 0;
> +
> +out:
> +    spin_unlock(&vdev->lock);
> +}
> +
> +int vuart_putchar(struct vuart_ns8250 *vdev, char ch)
> +{
> +    int rc;
> +
> +    spin_lock(&vdev->lock);
> +
> +    if ( !(vdev->flags & NS8250_READY) )
> +    {
> +        rc = -ENODEV;
> +        goto out;
> +    }
> +
> +    /* Echo the user input on the console */
> +    printk("%c", ch);

FWIW, I would move the printk() after the error checks, so that the
character is only echoed if handled.

> +
> +    /*
> +     * Device is in loopback mode; do nothing.
> +     */
> +    if ( vdev->regs[UART_MCR] & UART_MCR_LOOP )
> +    {
> +        rc = -EBUSY;
> +        goto out;
> +    }
> +
> +    rc = ns8250_fifo_rx_putchar(vdev, ch);
> +    if ( rc == -ENOSPC )
> +        vdev->regs[UART_LSR] |= UART_LSR_OE | UART_LSR_DR;
> +    else
> +        /* NB: UART_LSR_DR is also set when UART_LSR is accessed. */
> +        vdev->regs[UART_LSR] |= UART_LSR_DR;
> +
> +    /* FIXME: check FCR when to fire an interrupt */
> +    ns8250_irq_assert(vdev);
> +
> +out:
> +    spin_unlock(&vdev->lock);
> +
> +    return rc;
> +}
> +
> +int domain_vuart_init(struct domain *d)
> +{
> +    struct vuart_ns8250 *vdev = &d->arch.hvm.vuart;
> +    const struct resource *r;
> +
> +    memset(vdev, 0, sizeof(*vdev));
> +
> +    r = ns8250_parse();
> +    if ( r != NULL )
> +        return ns8250_init(d, r);
> +
> +    return -ENODEV;
> +}
> +
> +void domain_vuart_free(struct domain *d)
> +{
> +    ns8250_exit(d);
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/arch/x86/include/asm/hvm/domain.h b/xen/arch/x86/include/asm/hvm/domain.h
> index 333501d5f2ac01676646b9b277b551f06d43c3a5..d4ce25896259fc9763477e88d56bacbe4f78af5b 100644
> --- a/xen/arch/x86/include/asm/hvm/domain.h
> +++ b/xen/arch/x86/include/asm/hvm/domain.h
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #ifdef CONFIG_MEM_SHARING
>  struct mem_sharing_domain
> @@ -73,6 +74,10 @@ struct hvm_domain {
>      struct hvm_vioapic    **vioapic;
>      unsigned int           nr_vioapics;
>  
> +#if defined(CONFIG_HAS_VUART_NS8250)
> +    struct vuart_ns8250    vuart;

Since this is supposed to possibly be used by just a small amount of
domain on the system, I would rather make this a pointer:

struct vuart_ns8250    *vuart;

And embed the xencons_ring inside of it directly, so that you just
have to allocate vuart_ns8250.

> +#endif
> +
>      /*
>       * hvm_hw_pmtimer is a publicly-visible name. We will defer renaming
>       * it to the more appropriate hvm_hw_acpi until the expected
> diff --git a/xen/arch/x86/include/asm/hvm/vuart_ns8250.h b/xen/arch/x86/include/asm/hvm/vuart_ns8250.h
> new file mode 100644
> index 0000000000000000000000000000000000000000..e1013751f955441a9089ea38c96c4605a7f4cb75
> --- /dev/null
> +++ b/xen/arch/x86/include/asm/hvm/vuart_ns8250.h
> @@ -0,0 +1,75 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * NS8250-compatible UART Emulator.
> + */
> +#if !defined(HVM__VUART_NS8250_H)

As commented by Jan, better use #ifndef.

> +#define HVM__VUART_NS8250_H
> +
> +#include 
> +#include 
> +#include  /* xencons_interface */
> +
> +/*
> + * NS8250 emulator operational flags.
> + */
> +enum {
> +    /* Emulator is ready */
> +    NS8250_READY                = BIT(0, U),
> +    /* Trigger re-delivery of THRE interrupt */
> +    NS8250_IRQ_THRE_PENDING     = BIT(1, U),

I'm unsure the unnamed enum buys you much here if you end up assigning
values anyway.  You might as well do:

#define NS8250_READY            BIT(0, U)
#define NS8250_IRQ_THRE_PENDING BIT(1, U)

It would be good if you could integrate this with the flags field
being declared using DECLARE_BITMAP().  Otherwise you might need some
build-time check to ensure max defined flag fits in the struct flags
field.

> +};
> +
> +/*
> + * Virtual NS8250 device state.
> + */
> +struct vuart_ns8250 {
> +    uint16_t dl;                    /* Divisor Latch */
> +    uint8_t regs[UART_MAX];         /* Registers */

Doesn't regs already account for the divisor latch register?

> +    uint32_t flags;                 /* Virtual device flags */

See comment above about using DECLARE_BITMAP().

> +    uint64_t io_addr;               /* Guest I/O region base address */

IO space is limited to 16bits, hence there's no need to use a uint64_t
to store the address. Either uint16_t, or just a plain unsigned int
will suffice.  Same for size below.

> +    uint64_t io_size;               /* Guest I/O region size */
> +    int irq;                        /* Guest IRQ# */
> +    struct xencons_interface *cons; /* Emulated RX/TX FIFOs */

Any reason you re-use the xencons interface?  And any reason it's a
pointer instead of being part of vuart_ns8250 itself?

> +    struct domain *owner;           /* Owner domain */
> +    spinlock_t lock;                /* Protection */
> +};
> +
> +#if defined(CONFIG_HAS_VUART_NS8250)
> +
> +int vuart_putchar(struct vuart_ns8250 *vdev, char ch);
> +
> +/*
> + * Match the names w/ arch/arm/vuart.h
> + * FIXME: move to common vuart.h
> + */
> +int domain_vuart_init(struct domain *d);
> +void domain_vuart_free(struct domain *d);
> +
> +#else
> +
> +static inline int vuart_putchar(struct vuart_ns8250 *vdev, char ch)
> +{

Hard to tell as there are no users of vuart_putchar() in this patch,
but it seems you might want an ASSERT_UNREACHABLE() here.

> +    return -1;
> +}
> +
> +static inline int domain_vuart_init(struct domain *d)
> +{
> +    return -ENODEV;
> +}
> +
> +static inline void domain_vuart_free(struct domain *d)
> +{

Both init and free calls are gated with domain_has_vuart(), so you
might want to also add ASSERT_UNREACHABLE() here.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 11:47:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 11:47:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856625.1269185 (Exim 4.92)
	(envelope-from )
	id 1tM48s-00028v-HG; Fri, 13 Dec 2024 11:47:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856625.1269185; Fri, 13 Dec 2024 11:47: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 1tM48s-00028o-Cb; Fri, 13 Dec 2024 11:47:34 +0000
Received: by outflank-mailman (input) for mailman id 856625;
 Fri, 13 Dec 2024 11:47: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 1tM48r-00028i-Hq
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 11:47:33 +0000
Received: from NAM10-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam10on20624.outbound.protection.outlook.com
 [2a01:111:f403:2412::624])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 085d713f-b948-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 12:47:31 +0100 (CET)
Received: from DS7P220CA0008.NAMP220.PROD.OUTLOOK.COM (2603:10b6:8:1ca::15) by
 DM6PR12MB4268.namprd12.prod.outlook.com (2603:10b6:5:223::15) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8251.16; Fri, 13 Dec 2024 11:47:24 +0000
Received: from DS1PEPF00017093.namprd03.prod.outlook.com
 (2603:10b6:8:1ca:cafe::d9) by DS7P220CA0008.outlook.office365.com
 (2603:10b6:8:1ca::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.18 via Frontend Transport; Fri,
 13 Dec 2024 11:47:24 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 DS1PEPF00017093.mail.protection.outlook.com (10.167.17.136) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Fri, 13 Dec 2024 11:47:24 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 13 Dec
 2024 05:47:24 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 13 Dec 2024 05:47:21 -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: 085d713f-b948-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=aiGocDun8H1dOntdG6WgeUR2/XzSGUPHiEF4Jw//R7rp1Y9xvzuPRdHK/7dULqPuIUmISpsVI84xEQR0Z45scjI/5PBgHqy9fwiDfOW0YAsxcK7LDPFBoUgrD0NNxGtXqZySNrwCPtLzRvw0v8irfPwUsoO1Rr/sF/+kfjrp8+mdRpFwHEtpwSuOeSET1dR4jtTZ2C0Q1MfpH8FBJD610jcGxVVGwXz5MRIwddIzpj3CagR8KmrFgRHzvXTFgw7f2RfVpZnGXdjI+oRJzTbKDAYgp9d9ZL4bvcDx1LjZzwsJ6DyBGiwnXSPclnjsj7Sl1ySD77tT3eY+QjB9M7yObw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=E4gkhHjeOW+EXymXd/7PefBvELrnzXP5XWlm4IfBqo0=;
 b=m3ZeAZkDI22ncWeXm51ADJ612UhWIDWLt5W/RMzMnKg3mkf1r2Uym5o+rfZZeW+mfs7XlSQOrykYEg4Je7lRLrkaUT2gYGMv5h+YFATz4K5yVlovrnHnDGUNQqxZphoz/JEADG7whPhb0cZjm50zsBzj0lvIS18VkazXjOxiE55iW42BYeOiIhL4eMeX+uM5F5LpUbITi7a2cSde5epNO+hvs6idBfaF5MNNKZSQZhUbxRrpv8gLPYVH7JeklziegIsKS8e29i2AXgY69hTLyIinaww2CRAsw2yJ/JIbn2kPXi5lX+/6qlRpJErfI0g93r6SBmFedyLHG/cv/fiK3A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=minervasys.tech smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=E4gkhHjeOW+EXymXd/7PefBvELrnzXP5XWlm4IfBqo0=;
 b=kJe2UYuveE+G2R5YMpRnJ+Or1/9NOPbchMBglFHWaA17uGfF3N+H7iraPx7/Pj47oOV6WQAsHCVfvvlQU6Stvx6Hgd6gvZ/Ir2xPpHIILRDAeyN7LfUDl9wwobiTe1NO8fAx5GZlQGXVDlV5OyItkHu7FPL+L7ENH2eH3eFwr/g=
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=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Fri, 13 Dec 2024 12:47:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v11 03/12] xen/arm: permit non direct-mapped Dom0
 construction
To: Carlo Nonato 
CC: Andrea Bastoni , Julien Grall
	, ,
	, Stefano Stabellini ,
	Bertrand Marquis , Volodymyr Babchuk
	
References: <20241202165921.249585-1-carlo.nonato@minervasys.tech>
 <20241202165921.249585-4-carlo.nonato@minervasys.tech>
 
 <7ecc99c5-0cb5-4351-bede-cb03c9a4ac7e@xen.org>
 <293004fa-c87e-4a45-aa4c-b02456aaecea@amd.com>
 <0bacfdb6-d4ad-4dea-85d4-2851873dca4e@xen.org>
 
 
 <2f834c6b-c9fa-4b95-abff-b9bcb8c70246@amd.com>
 
 <6cb8c273-8e1d-4f34-adcc-620d4a71340c@amd.com>
 
 
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS1PEPF00017093:EE_|DM6PR12MB4268:EE_
X-MS-Office365-Filtering-Correlation-Id: db396f19-5947-46ed-77e9-08dd1b6be95d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cnlUT3d5UXFHWnB4VVRmTllKNXoxZXBWK0FNZ3NVTUxyMmdMTkNYODRjY2N1?=
 =?utf-8?B?U2ZwSDh1NHE3NjVkdXZhU05xSkxTM2Urem5NVEZxOUJNaFZBVk9tbW0zS1Nr?=
 =?utf-8?B?L1NTZmY0d24zaTA3eWk2MlVCczd4NEZVTGlMLzNaUUVpbk1kMzlHN0Z4Qnds?=
 =?utf-8?B?SS9Kbks3UDB0RjJaRzA2ekszbWd2MFJMa2NxNUVaRCtaZTlVMTVTMzNna1NX?=
 =?utf-8?B?RzVyUTNwNVZDQnIyUmZZVkRhdVlzVi9UTENhMWE3SEVmZkR6Sy9zT3U3ZENs?=
 =?utf-8?B?SUdHY2RYSXNINUo2dDJ0cktpL0FJbVZQQmdDOHB2ZThBWVE3S1ZpQ2JnV2xX?=
 =?utf-8?B?UnlRS0FSeXR6OU82a2s2R0szSDNrempxcUJ0d1VZUTVwaTZUTmFQOWQrNTYy?=
 =?utf-8?B?d0REaUhYYW9LZHVQV1hnUmZIY2VZTk9ZMGdyWnZiYmlMVXF4emtPWGhrUnJs?=
 =?utf-8?B?bWtKRWRJMEI4WjlkTDY4SDBRcm9xYmRrdW9obExrMkcyTmNTN0Y4K1FUcFlW?=
 =?utf-8?B?Q0NrZHNaWEx4RDljM1VmNkF4WW9EWVZZTzAxSDdPby9hVWpscW9ZTGNkenhF?=
 =?utf-8?B?MW1UUERqa0JGUkJVZGkxSGFMdFRrZStqYUhrb01BTDRIQ096VXFwcnFiVWlP?=
 =?utf-8?B?bHBNSUtON2tGbWZkanc0S0s1SlEzcXM0d2VtVGRtb1gzaUVNV2pWVEJFdlpN?=
 =?utf-8?B?cmFEa0VtTXVJV1NJSlMzQWxSQjNobE1TcjlNbURmdllQeFdGazBVWHZRT1p4?=
 =?utf-8?B?bDRBUXlNaXo3RnJqenAzcm1QdDhuVGc4b0xxdFAvOXhMQ0tDVlF0dVN2L0pn?=
 =?utf-8?B?V3pHNms2aGZOV3NxRmZsQkI0K055bUhYUUlpNUk4SHVPSERIbS9GeDNoRTl3?=
 =?utf-8?B?dXBwc2l3SXN3WTNBRlRHTS9MYkY0L09lMmlWT2U3bW14OHVWbFc3OXgrRjFm?=
 =?utf-8?B?aUVRaHYzNUxtS0hXbVdYTjFhejhHOFFxRUNJZjYvdXdBOWd0RHRMcmVOajk5?=
 =?utf-8?B?WXZwWUkrVC90T3Y3eVFsdXVvcDhhcVBXV0hzTGRVWjdIT2lCTHUvYlZrNXF1?=
 =?utf-8?B?MFpvdENiQjBqVTNncGFkQjhLQkhVUXd0UXE0ZXZBU1NVVHppUkU3K2VzMEVX?=
 =?utf-8?B?UUdxVjZRaVpEVTJHbEY3K0QrRVZiaGNtdWNBUjVhNGRVZlB0WVdMOEg5cms0?=
 =?utf-8?B?QlVEVUFobUUrMFZXaHdTV3JTTTZ4MURJeEpzbUplUjdkZjMzOHJKSkdOWG05?=
 =?utf-8?B?MjJGZVZLUW1jd1M2di9vT0RDNDQ3SmxSWGs3a281UExxcUkxVkh4ZGVmamQx?=
 =?utf-8?B?aE9FRmhDYnNvOU02QlNOTzFSY25ZV0QwQUhOZ0FUSW0rTmlzVCsxY2dpYll1?=
 =?utf-8?B?c2NkMUxyNTdXZFNBcjkrZ2RUMXhldDZDY2RMcEFtcFk2dm9kZjZTWmoxZEo2?=
 =?utf-8?B?YVUycEJOSklrZVZXTUpIbjFqalNvTVpxMjZFVDVlSWVPL2QxNmFmelVNc0Nv?=
 =?utf-8?B?ZlFISFdyUkxWME9rdzNYTDJaYnVycHliTDZzWWVJRTI1NTVhNWRMZEI0VFNC?=
 =?utf-8?B?S3BTR2ZvZmZRT1Ezc21ka1NZYU9iVmR1Qmk3cVp2WnE3VStPRnIvdjFZQzJN?=
 =?utf-8?B?NDlSd0YzUzhHS1NDU21IRytyYlRYWmZpMG1QTUhhNW1TMm85c3pxUXNDQnMz?=
 =?utf-8?B?MTBaUzRpa1U0RWttMlV2MGpQNlNCY0Y1ekNhdE4wTCtHWGhFOWxMVGRTZnBk?=
 =?utf-8?B?MlViT2NjTXN0d0FJQUE2ZTczcGIxall4dHpqTTRsZzFnSWxCSmdxK1dDSzk5?=
 =?utf-8?B?Umx2dk44b09WOVJjVnNvdy9KaTFFWllaRko2Nm9HVllTdWhQZk9XZzNBOENY?=
 =?utf-8?Q?t/7iHVQAJ1IxX?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2024 11:47:24.6052
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: db396f19-5947-46ed-77e9-08dd1b6be95d
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS1PEPF00017093.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4268



On 13/12/2024 12:33, Carlo Nonato wrote:
> 
> 
> Using paste.debian:
> 
> https://paste.debian.net/1339647/

1. Issue I mentioned with prefixing with double underscore
2. Generic helper should not be named ext_regions
3. s/skip_size/min_bank_size/

And still you need to convince others about 128MB limit because I'm not sure.

Imagine, that our kernel+dtb+ramdisk is > 128MB and your first bank is 128MB. With your
solution this would fail. Now, imagine that you sort your banks and start with the biggest
one. You don't care about its size. It's the biggest one so if it does not fit, then that's not
your problem.

~Michal



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 12:08:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 12:08:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856643.1269196 (Exim 4.92)
	(envelope-from )
	id 1tM4T6-0005SP-8I; Fri, 13 Dec 2024 12:08:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856643.1269196; Fri, 13 Dec 2024 12:08: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 1tM4T6-0005SI-4I; Fri, 13 Dec 2024 12:08:28 +0000
Received: by outflank-mailman (input) for mailman id 856643;
 Fri, 13 Dec 2024 12:08: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 1tM4T4-0005Qf-Rp
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 12:08:26 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f4cd3256-b94a-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 13:08:26 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5d0d32cd31aso2015931a12.0
 for ; Fri, 13 Dec 2024 04:08:25 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa68770c481sm692330766b.110.2024.12.13.04.08.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 04:08: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: f4cd3256-b94a-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734091705; x=1734696505; 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=3uiSySdXOdAjSyfpFkZEBuFnMElPBj8h17XrCKrLRdo=;
        b=WyPzwd4FD77GO/mVHs7HAz6pDw6txrilU4eDRLyESyVygeMchIAMjM8kQhweCiipsE
         2uF5pB/ENTylIEMI5gli4cUK2bBhgRBTZ3xKHIPtOe9OKL8nr10W07cFHIYi3+nv8UG1
         BI6drpDiwjoxa8paoA1ZvLR86PIAU34rKK9o0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734091705; x=1734696505;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=3uiSySdXOdAjSyfpFkZEBuFnMElPBj8h17XrCKrLRdo=;
        b=edos7G7rPE08NnA4DXfQ0YOvyYXmktUqpu3EfKtq2XFvb01Xs0wLJrJAGVs3l19XH2
         HD4bgL3aE9mBbBRnlfalfQJOII2tN2WFobNewVn9wemeukXOhqSXqilde7mxokJfTeuI
         kIE3tgDKm/QVTbTD/eUj2+HArwEbyJCJKVBm0ZdfTZZcu/9LXv9AVEjajXE9IpavEd3P
         OSszisE2scc/CtKeXm9VvbWX8wQdwW3PCmAuMjC4S6uHarBnI6ZqlQO+mSiBrGJtDiG5
         5d49O0ntA3x9ElupdbtQcY3o+4Q7ksmhy/TXAXzAD4uT2Z4bALj8DnhB9DISdq0MqrQ0
         /Rtg==
X-Gm-Message-State: AOJu0YwggQ7zmu8IuHlciB/FhgWkUf58YQifzCXJWhqGd9/f3YOi6m5L
	r5WVktA0VS9rMjojs/N7LTvzt+mR1Mk4/SYemU5QJ2o18zQcycaAn2qZhNON5wY8vKMNFZNUoyP
	L
X-Gm-Gg: ASbGnctRIEJykUn0+Q7xu+vToIEfEsbEviKx2JwgFNcH6opYD4/qHTbs1oDnoBUVdPp
	TaKAZZx8aekUkaSrIo5T4tTlc2wjgwRnB+dM/zsITT92hzZiIINcviV+AKeGuFBwEBeFloFH89k
	aTUmxSJFTkB7TJVLJEcHNUoc3KRSxn0e0kRk4UtCJtUd2AOo2VMTsvEvAMMdG/z/K06PAmLT6on
	C2Fkb+m0ISLW8q349E4g3ItHjXrzV3m9yWtv9Ib3sGmSovI2LrVi5e+fTsCM+GAhA==
X-Google-Smtp-Source: AGHT+IEN3k0DWZjpDNTuZ/Fs8fa1Vs6JmtyOmIeE3RZv5q9XAyOogPj/+3iuh9cYMAweQSCi4oYogg==
X-Received: by 2002:a05:6402:5109:b0:5d0:abb8:7a3 with SMTP id 4fb4d7f45d1cf-5d63c30097cmr4772116a12.6.1734091705164;
        Fri, 13 Dec 2024 04:08:25 -0800 (PST)
Date: Fri, 13 Dec 2024 13:08:24 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 32/35] x86/hvm: add debugging facility to NS8250 UART
 emulator
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-32-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-32-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:42:02PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Enable keyhandler mechanism for dumping state of emulated NS8250 on the
> console.
> 
> Signed-off-by: Denis Mukhin 
> ---
>  xen/arch/x86/hvm/vuart_ns8250.c | 122 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 122 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/vuart_ns8250.c b/xen/arch/x86/hvm/vuart_ns8250.c
> index 779dbd80d7be4e070ea9df3ae736ecdc662a527a..c8c75afaf2b2419d1dae999da1d1e400fd367791 100644
> --- a/xen/arch/x86/hvm/vuart_ns8250.c
> +++ b/xen/arch/x86/hvm/vuart_ns8250.c
> @@ -25,6 +25,7 @@
>  
>  /* Development debugging */
>  #define NS8250_LOG_LEVEL    0
> +#undef NS8250_DEBUG
>  
>  #include 
>  #include 
> @@ -35,6 +36,9 @@
>  #include 
>  #include 
>  #include 
> +#if defined(NS8250_DEBUG)
> +#include 
> +#endif
>  #include  /* console_input_domid() */
>  #include    /* max_init_domid */
>  #include 
> @@ -625,6 +629,121 @@ static const char *ns8250_regname(
>      return reg_names[reg][dir];
>  }
>  
> +#if defined(NS8250_DEBUG)

I don't think the keyhandler should be gated on NS8250_DEBUG, it
should always be present if Xen is built with vUART support.

> +static void ns8250_dump(struct vuart_ns8250 *vdev)
> +{
> +    struct xencons_interface *cons = vdev->cons;

const for both.

> +    uint8_t val;
> +
> +    printk("I/O port %02"PRIx64" IRQ %d flags %"PRIx32" owner %d\n",

I think you want 04 for the io_addr field width?  So that the width is
always fixed, and %pd for owner.

> +            vdev->io_addr, vdev->irq,
> +            vdev->flags, vdev->owner->domain_id);
> +
> +    printk("RX size %ld in_prod %d in_cons %d used %d\n",
> +            sizeof(cons->in),
> +            cons->in_prod, cons->in_cons,
> +            cons->in_prod - cons->in_cons);
> +
> +    printk("TX size %ld out_prod %d out_cons %d used %d\n",
> +            sizeof(cons->out),
> +            cons->out_prod, cons->out_cons,
> +            cons->out_prod - cons->out_cons);
> +
> +    printk("%02x RBR [ %c ] THR [ %c ] DLL %02x DLM %02x\n",
> +            UART_RBR,
> +            cons->in[MASK_XENCONS_IDX(cons->in_prod, cons)],
> +            cons->out[MASK_XENCONS_IDX(cons->out_prod, cons)],
> +            vdev->dl & 0xFFU, vdev->dl >> 8);
> +
> +    printk("%02"PRIx8" IER %02"PRIx8"\n", UART_IER, vdev->regs[UART_IER]);
> +
> +    val = (vdev->regs[UART_FCR] & UART_FCR_ENABLE) ? UART_IIR_FE_MASK : 0;
> +    val |= ns8250_irq_reason(vdev);
> +    printk("%02"PRIx8" FCR %02"PRIx8" IIR %02"PRIx8"\n",
> +            UART_FCR, vdev->regs[UART_FCR], val);
> +
> +    printk("%02"PRIx8" LCR %02"PRIx8"\n", UART_LCR, vdev->regs[UART_LCR]);
> +    printk("%02"PRIx8" MCR %02"PRIx8"\n", UART_MCR, vdev->regs[UART_MCR]);
> +    printk("%02"PRIx8" LSR %02"PRIx8"\n", UART_LSR, vdev->regs[UART_LSR]);
> +    printk("%02"PRIx8" MSR %02"PRIx8"\n", UART_MSR, vdev->regs[UART_MSR]);
> +}
> +
> +static struct domain *rcu_find_first_domain_with_vuart(void)
> +{
> +    struct domain *d = NULL;
> +    domid_t i;
> +
> +    for ( i = 0; i < max_init_domid + 1; i++ )
> +    {
> +        d = rcu_lock_domain_by_id(i);
> +        if ( d == NULL )
> +            continue;
> +
> +        if ( domain_has_vuart(d) )
> +            break;
> +
> +        rcu_unlock_domain(d);
> +    }
> +
> +    return d;
> +}
> +
> +static void cf_check ns8250_keyhandler_show(unsigned char key)
> +{
> +    struct vuart_ns8250 *vdev;
> +    struct domain *d;
> +
> +    d = rcu_find_first_domain_with_vuart();
> +    if ( d == NULL )
> +        return;

I wonder whether you should dump the state of all domains with a
vUART, rather than just a single domain?

> +
> +    printk("'%c' pressed -> dumping virtual NS8250 state (d%d)\n",
> +            key, d->domain_id);
> +
> +    vdev = &d->arch.hvm.vuart;
> +    spin_lock(&vdev->lock);

This should likely be a trylock, so that you can still print the
console state in case of a deadlock.

> +    ns8250_dump(vdev);
> +    spin_unlock(&vdev->lock);
> +
> +    rcu_unlock_domain(d);
> +}
> +
> +static void cf_check ns8250_keyhandler_irq(unsigned char key)
> +{
> +    struct vuart_ns8250 *vdev;
> +    struct domain *d;
> +
> +    d = rcu_find_first_domain_with_vuart();
> +    if ( d == NULL )
> +        return;
> +
> +    printk("'%c' pressed -> triggering IRQ on virtual NS8250 (d%d)\n",
> +            key, d->domain_id);
> +
> +    vdev = &d->arch.hvm.vuart;
> +    spin_lock(&vdev->lock);
> +    ns8250_irq_assert(vdev);
> +    spin_unlock(&vdev->lock);
> +
> +    rcu_unlock_domain(d);
> +}
> +
> +static void ns8250_keyhandler_init(void)
> +{
> +    register_keyhandler('1', ns8250_keyhandler_show,
> +                        "dump virtual NS8250 state", 0);
> +    register_keyhandler('2', ns8250_keyhandler_irq,
> +                        "trigger IRQ from virtual NS8250", 0);
> +}
> +#else
> +static inline void ns8250_keyhandler_init(void)
> +{
> +}
> +static inline void ns8250_dump(struct vuart_ns8250 *vdev)
> +{
> +}
> +#endif /* #if defined(NS8250_DEBUG) */
> +
>  /*
>   * Emulate I/O access to NS8250 register.
>   */
> @@ -688,6 +807,7 @@ static int cf_check ns8250_io_handle(
>      rc = X86EMUL_OKAY;
>  
>  out:
> +    ns8250_dump(vdev);

Likely a remaining of some debugging?  Printing the state for every
access is too verbose.

>      spin_unlock(&vdev->lock);
>  
>      return rc;
> @@ -786,6 +906,7 @@ static int ns8250_init(struct domain *d, const struct resource *r)
>      }
>  
>      spin_lock_init(&vdev->lock);
> +    ns8250_keyhandler_init();

The keyhandler init should be in a __initcall(), otherwise you are
calling it for each domain creation that has a vUART.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 12:23:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 12:23:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856655.1269204 (Exim 4.92)
	(envelope-from )
	id 1tM4hz-0008QB-Fx; Fri, 13 Dec 2024 12:23:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856655.1269204; Fri, 13 Dec 2024 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 1tM4hz-0008Q4-Cw; Fri, 13 Dec 2024 12:23:51 +0000
Received: by outflank-mailman (input) for mailman id 856655;
 Fri, 13 Dec 2024 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 1tM4hy-0008Py-Cu
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 12:23:50 +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 1b058c91-b94d-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 13:23:49 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-a9a977d6cc7so214673066b.3
 for ; Fri, 13 Dec 2024 04:23:48 -0800 (PST)
Received: from localhost ([213.195.123.63]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa666cf5743sm897822866b.65.2024.12.13.04.23.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 04:23: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: 1b058c91-b94d-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734092628; x=1734697428; 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=ZRjd9VIIJ7/vP5y7gch1pC+dY9ZIqfQZ1Z3Z/fG94xg=;
        b=PzABCKXKmYiny+2kUwg8mk6e/BP1HApbimTb136cLgrTpXk/WsJUvwjHSouddfDgKi
         7pnStwYMFjMvnBmUxNHlNC1kzkzQRiDG4BrIrE63pg/oP4ZFn2BAkZcPJjP1Ufhg7QvN
         lC93suPjw5Rd6jmXmRJvINVh1Bto/mypQ53dI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734092628; x=1734697428;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZRjd9VIIJ7/vP5y7gch1pC+dY9ZIqfQZ1Z3Z/fG94xg=;
        b=GMPJhTCtaaoBWBW6mWFLyD3VURypAWpC4O8DIa30NxDLJerW1tkPQi9dBzPj6ClReQ
         Vssfgn7/1QheckFJ3W5Y4avX8CGQAzYormC8V7u7pBVzY1MAEnBUtbvX1ek9ZKAr2UYn
         vWfzOet05cAIiuIxwTwquSOIEGvnjXEQpOnA61vugdqJ/q7HPLdb5zl1yGFkY8bZX0TI
         tf27rCN3HTEQtPZpB52QSs0weMTX3E4jg7H4ojuUWPFIPNpwao3LQcYUMLYWg0pBWCZH
         hf4/7PcC6uUaOD1Fi8kGA+4KvNUFOIEqNLxlTieAZesJN35PgILOIzexRA2f+ReMwI7X
         wTpQ==
X-Gm-Message-State: AOJu0YwiS7RUfDgASPN+wIUeWXtVRmDh/Drf9wm5hikj+UnfS1pvZAiQ
	oA1UJLuqzbzdYcpZzFeKd8LGFonILHrMNV7epdC0ZBXiGrOSWbKBg7wh0oxTHUX5ZXFgSAN3PtU
	d
X-Gm-Gg: ASbGnct3bb6pZ81vnFX40XTVw9Z4l44qOsyvJq+4ZNqrBLItmG2SWBMgtGzVCnOugYL
	1s8YfeeL5QBlkgBKjRKRA6Q2G/BB2r3VPDMt//54SMjRM1Lm+wRTXQrsAujxW1n7VrACcaNHsgG
	qH11mOACbYX3ea8RSdXAPw7q475QOw9WVHbgjVNEM42W0loluvfpg3T7h75jqz30G/dnJwZpQQR
	ur3U3ugdBg/QZ5sWaNHF34cSoDMoaFC6a0JmfkJB7bCdDJvozQhQIFsAJe3/Y9ilw==
X-Google-Smtp-Source: AGHT+IHwO9zooK0KVHOxa5Tr5V4hFoFYnV1fK5q6/tobMDEdl9g8Fe7dL1XHd2Yz3nw0+W/NZ7dtVQ==
X-Received: by 2002:a05:6402:2392:b0:5d6:48ef:c19f with SMTP id 4fb4d7f45d1cf-5d648efc1b9mr337889a12.29.1734092628239;
        Fri, 13 Dec 2024 04:23:48 -0800 (PST)
Date: Fri, 13 Dec 2024 13:23:47 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini 
Subject: Re: [PATCH v2 33/35] x86/domain: implement domain_has_vuart()
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-33-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-33-e9aa923127eb@ford.com>

On Thu, Dec 05, 2024 at 08:42:03PM -0800, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Add new emulation flag for virtual UART on x86 and plumb it through the stack.
> 
> This change enables NS8250 emulator initialization.
> 
> Signed-off-by: Denis Mukhin 
> ---
>  tools/libs/light/libxl_x86.c      |  6 +++++-
>  tools/ocaml/libs/xc/xenctrl.ml    |  1 +
>  tools/ocaml/libs/xc/xenctrl.mli   |  1 +
>  tools/python/xen/lowlevel/xc/xc.c |  4 +---
>  xen/arch/x86/domain.c             |  8 +++++---
>  xen/arch/x86/include/asm/domain.h |  7 ++++---
>  xen/include/public/arch-x86/xen.h | 14 +++++++++++++-
>  7 files changed, 30 insertions(+), 11 deletions(-)
> 
> diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c
> index a3164a3077fec7e1b81a34074894dc646954a49a..de5f05e18cb0671bb031b101b9a7159eb0fe0178 100644
> --- a/tools/libs/light/libxl_x86.c
> +++ b/tools/libs/light/libxl_x86.c
> @@ -8,7 +8,11 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>  {
>      switch(d_config->c_info.type) {
>      case LIBXL_DOMAIN_TYPE_HVM:
> -        config->arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
> +        config->arch.emulation_flags = XEN_X86_EMU_ALL;
> +        config->arch.emulation_flags &= ~XEN_X86_EMU_VPCI;
> +        /* Virtual UART is selected at Xen build time */
> +        config->arch.emulation_flags &= ~XEN_X86_EMU_VUART;
> +
>          if (!libxl_defbool_val(d_config->b_info.u.hvm.pirq))
>              config->arch.emulation_flags &= ~XEN_X86_EMU_USE_PIRQ;
>          break;
> diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
> index 2690f9a92316b812ad3d3ff0e1c36823070adb4a..647239b3e55e88b00eb8e9773a5267894cbbae54 100644
> --- a/tools/ocaml/libs/xc/xenctrl.ml
> +++ b/tools/ocaml/libs/xc/xenctrl.ml
> @@ -47,6 +47,7 @@ type x86_arch_emulation_flags =
>    | X86_EMU_PIT
>    | X86_EMU_USE_PIRQ
>    | X86_EMU_VPCI
> +  | X86_EMU_VUART
>  
>  type x86_arch_misc_flags =
>    | X86_MSR_RELAXED
> diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
> index febbe1f6ae3f10c5abe45eaa3c06a8a67d9ba268..4f5f64c786e83e8a0c3dd3cdb0460f7095de4a62 100644
> --- a/tools/ocaml/libs/xc/xenctrl.mli
> +++ b/tools/ocaml/libs/xc/xenctrl.mli
> @@ -41,6 +41,7 @@ type x86_arch_emulation_flags =
>    | X86_EMU_PIT
>    | X86_EMU_USE_PIRQ
>    | X86_EMU_VPCI
> +  | X86_EMU_VUART
>  
>  type x86_arch_misc_flags =
>    | X86_MSR_RELAXED
> diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
> index 9feb12ae2b16e48cb5d0c3c45044ae226f152f2d..e54308956efc7061d58d2166ec9a95bc1dcd1781 100644
> --- a/tools/python/xen/lowlevel/xc/xc.c
> +++ b/tools/python/xen/lowlevel/xc/xc.c
> @@ -159,9 +159,7 @@ static PyObject *pyxc_domain_create(XcObject *self,
>  
>  #if defined (__i386) || defined(__x86_64__)
>      if ( config.flags & XEN_DOMCTL_CDF_hvm )
> -        config.arch.emulation_flags = XEN_X86_EMU_ALL &
> -                                      ~(XEN_X86_EMU_VPCI |
> -                                        XEN_X86_EMU_USE_PIRQ);
> +        config.arch.emulation_flags = XEN_X86_EMU_HVM_ALLOWABLE;
>  #elif defined (__arm__) || defined(__aarch64__)
>      config.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
>  #else
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index c88d422a64544531c1e1058fa484364bb4277d1e..439da7adc92a3a8eb481075bf834da5f9670dd54 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -752,10 +752,10 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
>          if ( is_hardware_domain(d) &&
>               emflags != (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) )
>              return false;
> +
> +        emflags &= ~X86_EMU_VUART;

I think you want to allow X86_EMU_VUART only for domains created by
Xen itself, so X86_EMU_VUART can only be valid if system_state <
SYS_STATE_active.

>          if ( !is_hardware_domain(d) &&
> -             /* HVM PIRQ feature is user-selectable. */
> -             (emflags & ~X86_EMU_USE_PIRQ) !=
> -             (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
> +             xen_emflags_allowable(emflags) != XEN_X86_EMU_HVM_ALLOWABLE &&
>               emflags != X86_EMU_LAPIC )
>              return false;
>      }
> @@ -806,6 +806,8 @@ int arch_domain_create(struct domain *d,
>  
>      emflags = config->arch.emulation_flags;
>  
> +    if ( IS_ENABLED(CONFIG_HAS_VUART_NS8250) && is_hvm_domain(d) )
> +        emflags |= XEN_X86_EMU_VUART;

Doesn't this need to be limited to domains created by Xen itself, as
otherwise it's the toolstack that should specify the XEN_X86_EMU_VUART
flag, and even then the recommendation would be to use the vUART from
QEMU?

>      if ( is_hardware_domain(d) && is_pv_domain(d) )
>          emflags |= XEN_X86_EMU_PIT;
>  
> diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h
> index c1d0d1f47324e8cc678a4c76c43f86820a89e7b3..dacea6e1aad46e9f8710b2202bb81203c5e92807 100644
> --- a/xen/arch/x86/include/asm/domain.h
> +++ b/xen/arch/x86/include/asm/domain.h
> @@ -484,7 +484,8 @@ struct arch_domain
>  #define X86_EMU_VPCI     0
>  #endif
>  
> -#define X86_EMU_PIT     XEN_X86_EMU_PIT
> +#define X86_EMU_PIT      XEN_X86_EMU_PIT

Unintended indentation change?

> +#define X86_EMU_VUART    XEN_X86_EMU_VUART
>  
>  /* This must match XEN_X86_EMU_ALL in xen.h */
>  #define X86_EMU_ALL             (X86_EMU_LAPIC | X86_EMU_HPET |         \
> @@ -492,7 +493,7 @@ struct arch_domain
>                                   X86_EMU_IOAPIC | X86_EMU_PIC |         \
>                                   X86_EMU_VGA | X86_EMU_IOMMU |          \
>                                   X86_EMU_PIT | X86_EMU_USE_PIRQ |       \
> -                                 X86_EMU_VPCI)
> +                                 X86_EMU_VPCI | X86_EMU_VUART)
>  
>  #define has_vlapic(d)      (!!((d)->arch.emulation_flags & X86_EMU_LAPIC))
>  #define has_vhpet(d)       (!!((d)->arch.emulation_flags & X86_EMU_HPET))
> @@ -507,7 +508,7 @@ struct arch_domain
>  #define has_vpci(d)        (!!((d)->arch.emulation_flags & X86_EMU_VPCI))
>  
>  /* NB: same symbol as in Arm port */
> -#define domain_has_vuart(d) false
> +#define domain_has_vuart(d) (!!((d)->arch.emulation_flags & X86_EMU_VUART))
>  
>  #define gdt_ldt_pt_idx(v) \
>        ((v)->vcpu_id >> (PAGETABLE_ORDER - GDT_LDT_VCPU_SHIFT))
> diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
> index fc2487986642a7694578ab9d2f5f16d09761bff8..e7922e3f9ddc1742a464d228807279839df31e52 100644
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -283,13 +283,25 @@ struct xen_arch_domainconfig {
>  #define XEN_X86_EMU_USE_PIRQ        (1U<<_XEN_X86_EMU_USE_PIRQ)
>  #define _XEN_X86_EMU_VPCI           10
>  #define XEN_X86_EMU_VPCI            (1U<<_XEN_X86_EMU_VPCI)
> +#define _XEN_X86_EMU_VUART          11
> +#define XEN_X86_EMU_VUART           (1U<<_XEN_X86_EMU_VUART)
>  
>  #define XEN_X86_EMU_ALL             (XEN_X86_EMU_LAPIC | XEN_X86_EMU_HPET |  \
>                                       XEN_X86_EMU_PM | XEN_X86_EMU_RTC |      \
>                                       XEN_X86_EMU_IOAPIC | XEN_X86_EMU_PIC |  \
>                                       XEN_X86_EMU_VGA | XEN_X86_EMU_IOMMU |   \
>                                       XEN_X86_EMU_PIT | XEN_X86_EMU_USE_PIRQ |\
> -                                     XEN_X86_EMU_VPCI)
> +                                     XEN_X86_EMU_VPCI | XEN_X86_EMU_VUART)
> +
> +/* HVM PIRQ feature is user-selectable (libxl). */
> +#define XEN_X86_EMU_HVM_SELECTABLE  (XEN_X86_EMU_VPCI | \
> +                                     XEN_X86_EMU_USE_PIRQ | \
> +                                     XEN_X86_EMU_VUART)

XEN_X86_EMU_HVM_OPTIONAL is maybe clearer?

Albeit PVH is kind of HVM.

> +
> +#define xen_emflags_allowable(x)    ((x) & ~XEN_X86_EMU_HVM_SELECTABLE)
> +
> +#define XEN_X86_EMU_HVM_ALLOWABLE   xen_emflags_allowable(XEN_X86_EMU_ALL)

XEN_X86_EMU_HVM_BASELINE I think would also be better?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 12:46:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 12:46:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856668.1269215 (Exim 4.92)
	(envelope-from )
	id 1tM53Q-0002x6-79; Fri, 13 Dec 2024 12:46:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856668.1269215; Fri, 13 Dec 2024 12:46:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tM53Q-0002wz-3T; Fri, 13 Dec 2024 12:46:00 +0000
Received: by outflank-mailman (input) for mailman id 856668;
 Fri, 13 Dec 2024 12:45: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 1tM53O-0002wp-5o
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 12:45:58 +0000
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com
 [2607:f8b0:4864:20::d2f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 319baee2-b950-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 13:45:56 +0100 (CET)
Received: by mail-io1-xd2f.google.com with SMTP id
 ca18e2360f4ac-844e9b8b0b9so51235039f.0
 for ; Fri, 13 Dec 2024 04:45: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: 319baee2-b950-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734093954; x=1734698754; 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=fP/HHVlymalsIk/eJX6eEgaI5TLf71EpIA7DRChZFT8=;
        b=2fz2rfyCJsja711HL65rXRAgyrcnTM+Dxptzv7z5Xm3qLNsEJnn0S5kvAaNSwxGZg7
         7pVLxXVLNVznvgDrky4B0U2HQs/KrF8L13DR9dVs+9ez6pslOWnSqxVbMiZ1MUojhJYc
         aRKsxR0g03Cq9X+lrNRb5+zTJTAmsq8bLgIHwVY/QZORb19frPUL2ahuT8RLsGQbJmpG
         quHwbP0xkqmyXe7Vluw0YDzWFvsZGC37yvi0k/jhPOEamSdWME/+OxD0UWITAgpf9053
         cD+75n0qREC9453VEpfozCSqLWLSAXlT8KI/978UX3Xlx5Q2QDyHqHPn68TZ9iU2QGyj
         YItw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734093954; x=1734698754;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=fP/HHVlymalsIk/eJX6eEgaI5TLf71EpIA7DRChZFT8=;
        b=b70ZJM8t2zgRMZ5olBrL3OvgtoSqV1IvPP9t9SNQGKbg7ZeNcir3IBoVguML9ZfGTh
         t5NfDS7WXFaPpxvbBd5fvP/ZwWGwyohXViYA7BFbQbkZ5IyVzcIInkOHmFUqe0p8zrbV
         BHMQBX+zZKCeuALUdTbGenHESS4E/2/jxAL+QfFS0JVFOmcD4Io/NPZtMRAFgzMOpL4k
         6OWXB6yrc/LDEwOlOUrfGhsqsuUe6666bbR1ICFeSFSfT1NTVZ6Hd2iQosrPNmggflNE
         T/akoKDg1Eh+o4pzvpGrXS9J0k/l/g/V5KdYX6Yot/YVThw8ByhsONTaxO4WQQAZst2q
         8stQ==
X-Forwarded-Encrypted: i=1; AJvYcCVgKWlEdMpIt16Q1dkCjjnnwqYQRqbBTQQrA+4MsrU54zf+tRdIVgqPPqFEDtj+g4jkmHAvD9C7eIA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyrO6ytyyAQLlGhTHuZu/n3Ujzp5mx4bBKyxzhaEKuORKcRkI8P
	Lnae1Qp2X2f5cZelrgztx0gAvTBF7lRFiWGUNh5VFxH0XHXrsx666kDM72q5wfIiTvkejVE+riv
	BUZ0Zm8A9bJK6SU2/hgFcZooB0pDdSk4t7HkWmw==
X-Gm-Gg: ASbGncvn2s2cafrr9u+3cfc/8bRNbYDaec+xkp/AzjngVyvlhavMijvetg6gtAT4oFE
	Ohmqw6GWLR9YPLvxZStagSGEwhvAwsoTqhc0tlw==
X-Google-Smtp-Source: AGHT+IFr1FQ+KA5kfbjgDjYU+yAHc4eAh+dDYiy6PssJg9uGtT1+01F76pmmrXO0DILILKndStTahE2J1/f1YYnb/7o=
X-Received: by 2002:a05:6e02:18ca:b0:3a7:d7dd:e70f with SMTP id
 e9e14a558f8ab-3afeee787ecmr34140155ab.12.1734093954733; Fri, 13 Dec 2024
 04:45:54 -0800 (PST)
MIME-Version: 1.0
References: <20241202165921.249585-1-carlo.nonato@minervasys.tech>
 <20241202165921.249585-4-carlo.nonato@minervasys.tech> 
 <7ecc99c5-0cb5-4351-bede-cb03c9a4ac7e@xen.org> <293004fa-c87e-4a45-aa4c-b02456aaecea@amd.com>
 <0bacfdb6-d4ad-4dea-85d4-2851873dca4e@xen.org> 
  <2f834c6b-c9fa-4b95-abff-b9bcb8c70246@amd.com>
 
 <6cb8c273-8e1d-4f34-adcc-620d4a71340c@amd.com> 
  
In-Reply-To: 
From: Carlo Nonato 
Date: Fri, 13 Dec 2024 13:45:43 +0100
Message-ID: 
Subject: Re: [PATCH v11 03/12] xen/arm: permit non direct-mapped Dom0 construction
To: Michal Orzel 
Cc: Andrea Bastoni , Julien Grall , 
	xen-devel@lists.xenproject.org, marco.solieri@minervasys.tech, 
	Stefano Stabellini , Bertrand Marquis , 
	Volodymyr Babchuk 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 13, 2024 at 12:47=E2=80=AFPM Michal Orzel  wrote:
>
>
>
> On 13/12/2024 12:33, Carlo Nonato wrote:
> >
> >
> > Using paste.debian:
> >
> > https://paste.debian.net/1339647/
>
> 1. Issue I mentioned with prefixing with double underscore
> 2. Generic helper should not be named ext_regions
> 3. s/skip_size/min_bank_size/
>
> And still you need to convince others about 128MB limit because I'm not s=
ure.
>
> Imagine, that our kernel+dtb+ramdisk is > 128MB and your first bank is 12=
8MB. With your
> solution this would fail. Now, imagine that you sort your banks and start=
 with the biggest
> one. You don't care about its size. It's the biggest one so if it does no=
t fit, then that's not
> your problem.
>
> ~Michal
>

Something like that in add_hwdom_free_regions()?

>     /* Find the insert position (descending order). */
>     for ( i =3D 0; i < free_regions->nr_banks ; i++)
>         if ( size > free_regions->bank[i].size )
>             break;
>
>     /* Move the other banks to make space. */
>     for ( j =3D free_regions->nr_banks; j > i ; j-- )
>     {
>         free_regions->bank[j].start =3D free_regions->bank[j - 1].start;
>         free_regions->bank[j].size =3D free_regions->bank[j - 1].size;
>     }
>
>     free_regions->bank[i].start =3D start;
>     free_regions->bank[i].size =3D size;
>     free_regions->nr_banks++;

With that (if I didn't make any mistake) I'm inserting banks in descending =
size
order. Is it ok?

Thanks.

- Carlo


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 12:54:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 12:54:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856678.1269224 (Exim 4.92)
	(envelope-from )
	id 1tM5BV-0004hC-Ul; Fri, 13 Dec 2024 12:54:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856678.1269224; Fri, 13 Dec 2024 12:54: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 1tM5BV-0004h5-Rz; Fri, 13 Dec 2024 12:54:21 +0000
Received: by outflank-mailman (input) for mailman id 856678;
 Fri, 13 Dec 2024 12:54: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 1tM5BU-0004gz-Kn
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 12:54:20 +0000
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com
 [2a00:1450:4864:20::136])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5e4aa94e-b951-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 13:54:19 +0100 (CET)
Received: by mail-lf1-x136.google.com with SMTP id
 2adb3069b0e04-5401bd6ccadso1684194e87.2
 for ; Fri, 13 Dec 2024 04:54:19 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-53e333dda47sm2287349e87.250.2024.12.13.04.54.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 13 Dec 2024 04:54: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: 5e4aa94e-b951-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734094459; x=1734699259; darn=lists.xenproject.org;
        h=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=kT37nskFBPLL/v2ifjenAGgemMKHda0UrLaFaQbzhXk=;
        b=WVEj7dRTUom3VvcyhoQxW1NKszLgt3qPmD5iiHKWYVl5P+/6f1HUu1QqZ1ffihMHm5
         I+6jME6YubstokEuUbmb0BWf5Nkbf4fCxHreiYWkIW5MZ3xpeRfyLVZU+ErF+ntAHVTH
         aLWLALmIhgcJkFjuBY6qhlf3fJGME57EctiMpSm+3+8R4hrgtxum39ImO1gUeUC1YT4Q
         9vIJslokJx/da6sRy/1+3+rwrQ3Y+xfB5Xt4MzehL0f/73+LgUqtDC/NOgSATMl+L4da
         cD4qHzF5W+lu4knqI82sCwP7mXr/WXtCE9HgAU3u6jOxnW2SPGDc5AJreBoK0WlFaaZw
         vqwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734094459; x=1734699259;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=kT37nskFBPLL/v2ifjenAGgemMKHda0UrLaFaQbzhXk=;
        b=HOPGcNY82E7Wp3j8aZonh+LN87v7xN3ogo9J+cfo4DHt3fq41fU5H4CgIl6mBXc0Cx
         U2ylFuhDckVNoInZuXfutvotDh+xFpt5jslLkyuN+3XHFj676y587TYriXTAsS3Rc+3R
         Z46o7E8GR8zwXy8oIOkEjrhNt68kZG8aODv+I5rDyz4oukeOfwE8jaLUTIK7rW30LDzl
         mV89ilbMcfpCa/1ZGoDKFH6No/pMUxEi+N1VZfNIsAYrTXPd5pWFy2sYk4DNy3oAVNU/
         j9bvvKNcnTGKJ3P57GEfrlNem7qj2T/Tqy+snaDxaqQi6pAg9r1IEi9687XXMxs4+v0a
         jvsA==
X-Forwarded-Encrypted: i=1; AJvYcCXapXzyNMDC19k0+I7BmpYJFLIKxvJ0Gd/HLPqj1Kv6Cd9myJwSNKrxbpPASpWb+7yigrJydLlygew=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxEvwNuDOe0+8BYN7RRY7qc5Rt9fvxygtLn/2v0qzNHCvBQGApQ
	f+ecdeI/wwFfUHvsIVjs492CUqimtamuMnJIKMRpF59wDeD3/6ba
X-Gm-Gg: ASbGnctP0vzeCFTGAJWtEFuvTkT+x3ublIJRKmUW5VedmQIUs4GngkklZ9ZVU40SBCM
	OSeUr98g2rWaPq1aHYJTIeWuA/ppyfMB+uoEoyP27mCTLQqkh1yLgJ/ARWHA7HLbf7K/QxSelNc
	ca9qRVRiuZM2Kyp+1hwT7zcvMAANNWVta372EfRUwnCXhf9Wk/VDq9GIWln1iIjUMUg9yx9RHCZ
	cf67X6mpxXU/6F1SoDIMMP5EKL1U1Pa1sOyKeLBhko+7uQoWkV0AsuX+j+L/S+L86e5Vg==
X-Google-Smtp-Source: AGHT+IEmYt1152AXd5KxqaVYPVTgs3UuOybnOoKk88cbhwKWvCSE5D8Vk6Ejfv1Ts44t7lSVZS2Xyw==
X-Received: by 2002:a05:6512:acb:b0:540:3561:969e with SMTP id 2adb3069b0e04-54090553eccmr762661e87.14.1734094457409;
        Fri, 13 Dec 2024 04:54:17 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------ixIz48BZz3EFV8FUvJ4cDO7l"
Message-ID: <3a23d17a-358d-45df-9c9b-65d95a1393f4@gmail.com>
Date: Fri, 13 Dec 2024 13:54:16 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/7] xen/riscv: add destroy_xen_mappings() to remove
 mappings in Xen page tables
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , 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: Oleksii Kurochko 
In-Reply-To: 

This is a multi-part message in MIME format.
--------------ixIz48BZz3EFV8FUvJ4cDO7l
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 12/12/24 12:43 PM, Jan Beulich wrote:
> On 11.12.2024 18:27, Oleksii Kurochko wrote:
>> Introduce the destroy_xen_mappings() function, which removes page
>> mappings in Xen's page tables between a start address s and an end
>> address e.
>> The function ensures that both s and e are page-aligned
>> and verifies that the start address is less than or equal to the end
>> address before calling pt_update() to invalidate the mappings.
>> The pt_update() function is called with INVALID_MFN and PTE_VALID=0
>> in the flags, which tell pt_update() to remove mapping. No additional
>> ASSERT() is required to check these arguments, as they are hardcoded in
>> the call to pt_update() within destroy_xen_mappings().
>>
>> Signed-off-by: Oleksii Kurochko
>> Acked-by: Jan Beulich
> Apparently I just shouldn't provide advance acks, when ...
>
>> --- a/xen/arch/riscv/pt.c
>> +++ b/xen/arch/riscv/pt.c
>> @@ -421,6 +421,14 @@ int map_pages_to_xen(unsigned long virt,
>>       return pt_update(virt, mfn, nr_mfns, flags);
>>   }
>>   
>> +int destroy_xen_mappings(unsigned long s, unsigned long e)
>> +{
>> +    ASSERT(IS_ALIGNED(s, PAGE_SIZE));
>> +    ASSERT(IS_ALIGNED(e, PAGE_SIZE));
>> +
>> +    return ( s < e ) ? pt_update(s, INVALID_MFN, PFN_DOWN(e - s), 0) : -EINVAL;
> ... then you introduce basic style violations like the excess blanks here.

I thought that I could consider ternary operator as `if` which requires spaces around condition.

~ Oleksii

--------------ixIz48BZz3EFV8FUvJ4cDO7l
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    


    

    
On 12/12/24 12:43 PM, Jan Beulich
      wrote:

    

    

      
On 11.12.2024 18:27, Oleksii Kurochko wrote:


      

        
Introduce the destroy_xen_mappings() function, which removes page
mappings in Xen's page tables between a start address s and an end
address e.
The function ensures that both s and e are page-aligned
and verifies that the start address is less than or equal to the end
address before calling pt_update() to invalidate the mappings.
The pt_update() function is called with INVALID_MFN and PTE_VALID=0
in the flags, which tell pt_update() to remove mapping. No additional
ASSERT() is required to check these arguments, as they are hardcoded in
the call to pt_update() within destroy_xen_mappings().

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>


      

      
Apparently I just shouldn't provide advance acks, when ...



      

        
--- a/xen/arch/riscv/pt.c
+++ b/xen/arch/riscv/pt.c
@@ -421,6 +421,14 @@ int map_pages_to_xen(unsigned long virt,
     return pt_update(virt, mfn, nr_mfns, flags);
 }
 
+int destroy_xen_mappings(unsigned long s, unsigned long e)
+{
+    ASSERT(IS_ALIGNED(s, PAGE_SIZE));
+    ASSERT(IS_ALIGNED(e, PAGE_SIZE));
+
+    return ( s < e ) ? pt_update(s, INVALID_MFN, PFN_DOWN(e - s), 0) : -EINVAL;


      

      
... then you introduce basic style violations like the excess blanks here.

    

    
I thought that I could consider ternary operator as `if` which requires spaces around condition.

    
~ Oleksii


  


--------------ixIz48BZz3EFV8FUvJ4cDO7l--


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 13:43:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 13:43:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856700.1269256 (Exim 4.92)
	(envelope-from )
	id 1tM5xL-00039y-5X; Fri, 13 Dec 2024 13:43:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856700.1269256; Fri, 13 Dec 2024 13:43: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 1tM5xL-00039p-0T; Fri, 13 Dec 2024 13:43:47 +0000
Received: by outflank-mailman (input) for mailman id 856700;
 Fri, 13 Dec 2024 13:43: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 1tM5xJ-0002en-Lf
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 13:43:45 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 (mail-db8eur05on2061b.outbound.protection.outlook.com
 [2a01:111:f403:2614::61b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 45ad5464-b958-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 14:43:45 +0100 (CET)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by AS8PR03MB9747.eurprd03.prod.outlook.com
 (2603:10a6:20b:61c::20) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Fri, 13 Dec
 2024 13:43:40 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%5]) with mapi id 15.20.8251.015; Fri, 13 Dec 2024
 13:43: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: 45ad5464-b958-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=q14Iy0RKutKgdkIQa65J1BRKTRprmzCchaXKGpLy+jWmK6ms7p1ZMtsGf9HXIUUKz06OJrAFpfI6M4G+WTJW7CtBs7UFdbnUQBMN4pOxAAyhel0I+xoXGPr3/oP9jRId0FLC7f9HMs9ZeTCQtFC64qENDGtyX2kFU7M7BH2FIyiypfuU96vADeloyYtNh489T+SXWFpga/kjcWvCElrRvXL0nwtRLPMbXpFLUNejnO6rqKUQF+2ANx1zcWiwROfj//mGGFGRusDG/mZj9+xcjuv1fP8u7GH8S29POcsas73Tvfo7qNiVDQLQ6QN5yNiTP/yesph0hRD6UKX9XXEQ6A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=slzVGFgFXwONJ/Cto3DTVKvONW79x4yZWlB6rJXTyPU=;
 b=Zk/lBJEI253W+ru2bjgZo77fogewxuQ6qHxUYRsRghtMwyvMmTB7WoYJk8PhHhgQIHde84bKeMbPGuhs/Wm7TeTvX/oisYoUsEw3WOdArw9ahgkomz8JhAA9EBOmYBDfHRknSIPC4fg7K2JF21v5yJw0eoUWZrFmjeITjr4vIS/g5EjFYnE5Y39nReEm50A8v6qH3k54t/ghCU7iMGhs7pED+1ZoVxk0112/RbO11AWs5tRc+Q5frjdMOb8qb109mGP1UZTkQxTti6c5xB9V8KZ9Xqly5sKLpdzrU+ckB/MF6C3GrZ5atrYxq1rH3Q550wWo9KplpoYBZh+HV50M8g==
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=slzVGFgFXwONJ/Cto3DTVKvONW79x4yZWlB6rJXTyPU=;
 b=rOV7PGTg3NTc9ZHonOjN2pKWD7IRcdn/ow9gdcwycoX032IfYenI1AhJrPyYUDyc+88HBu9tsjGQwpZEakLWoSJMaPiRE+vEoiB0npL2dEOYfFD6J4tu/HWgnDZymDi9lNqnTQqjD9N0zoCywgMYEigjKp/ygkA/8tGxlDHDbXYIeAM4qOSTzQrbm6PMAyl0r7KCs6zci4hdLv2A+8xGhhYG1OxCxHH1jnE4Sh7Ws1dTffbQQrNbgSEVGM6kdcHfOxtsKB7eYJ+8+fY01Z4FikOE70cYmgDob4KqAjZIdAkA9voHh+LO/aVLPfGcwy0ry9JAxmJSWpMpKvJYsWmZaA==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Oleksandr Andrushchenko , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Michal Orzel ,
	Volodymyr Babchuk , Volodymyr Babchuk
	, Mykyta Poturai 
Subject: [PATCH 2/2] xen/arm: platform: Add support for R-Car Gen4
Thread-Topic: [PATCH 2/2] xen/arm: platform: Add support for R-Car Gen4
Thread-Index: AQHbTWUELiJDWTQqiU2CiE+YljSlcQ==
Date: Fri, 13 Dec 2024 13:43:40 +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_|AS8PR03MB9747:EE_
x-ms-office365-filtering-correlation-id: 929085ee-6142-4c3a-b681-08dd1b7c2711
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?9nTwOLQ/Qemia5IgOUAjKNJs6zxl5VhLNEA8bBzCVww/4PAcAnoSrVc6H9?=
 =?iso-8859-1?Q?A8a8tGOOdh133FYucRh4qUMnzOj68ABZBh3BNRuhfYmHtd6l6prE8TjQZI?=
 =?iso-8859-1?Q?PvWuVx2+kOmJ+8kEQVY1fhzI8/oroIyIzEF9LbCi5vZDbOJqfxWwvddQuV?=
 =?iso-8859-1?Q?qCXs0myBecmMq7FTx//isapjsrVm1Y6jFFWJfHC+y0xZFaxOlFboerdF1l?=
 =?iso-8859-1?Q?EuEcFbvu2T70auW3MfLUNiORrLQV+gOByJHMLwUryacoWqqifsM256uyLh?=
 =?iso-8859-1?Q?kjedxpEaYeuOVaACM96gtrBcV27CKPxHiWHWO5dahrMwqibEz5ajMAToSQ?=
 =?iso-8859-1?Q?84u2pj9dW4bsu2WbkIihvrOklMC0QZFPQFphtTqrPn7JGfVwV7LkdwtnBt?=
 =?iso-8859-1?Q?gFHSaEtdXxv00MsIqDwWZEj+DHoyR+Ij29+CnCfJ+FKzmlTsxSHPQef/G3?=
 =?iso-8859-1?Q?N02sEQQF4OlarnqSN9GcITqn11e0dVzxdayPcQVbsa7B/6qb7XiHD47KEr?=
 =?iso-8859-1?Q?j+tIRp6jOMWW3gjWSTn8j03W4wGCZzI2Cclddfo8nzCbKxqyHyLbovRMkX?=
 =?iso-8859-1?Q?58yWwiogy8SG8KABvrio9orKFIaJjsrHCYWBRrRTjNIkmtWim1eQgdfmf2?=
 =?iso-8859-1?Q?8q8LRavBK2LbnqhZwkEmS25rkgwd/og169IbBVdnW9kfWvjxahapn8Bqd8?=
 =?iso-8859-1?Q?F6vCOBfKCJPDetmde+IWCF7ONXFscFVHOJh6TNb0BPTH9fBmTkAPWkjJLV?=
 =?iso-8859-1?Q?W3nErMGnZWOOk2PKPQC7HtCqJBhCofRaO6csmucARI8CeSxY5hzvgLaUhY?=
 =?iso-8859-1?Q?CpwUSR7D/vT1SOfZFmkIreLHL7Nbw6Jws+OsxSGsN+N4iSUic6ZrUUNpss?=
 =?iso-8859-1?Q?ZSpOFSD0VrXDSIQhIOAkcPr7PgLLhsYqGKDlBfAmW59czLQt2Wr6sJdivy?=
 =?iso-8859-1?Q?C7toFYJ3cprh7DtBr4Ln9uiZrikMP8MZMkVS93RB/uwrwnWxVZdn0IYWne?=
 =?iso-8859-1?Q?35+a3jZN1YsfM6IBNPQqeGAneQZ8Gzi6LkFy3KM/1CIlED9LnfBjI62KoE?=
 =?iso-8859-1?Q?gsvo4hvUaUOw58MC64x/SlK0PNQEl4TRtRLI2FrTF3Md6pPl216KIOFtRN?=
 =?iso-8859-1?Q?i6gUsdRiyceGZTuo6UKycdii8NC8TaLUBh+t/Fj8P3OcZxAdsCb56FwThr?=
 =?iso-8859-1?Q?9mUBz8rk9/pP3i3+H4EnL0fEdoZOb/HQb1bT/iy86INetcimD5O3D9peby?=
 =?iso-8859-1?Q?Y+Nm6MF9PcYJme0xRahdR2eTBaL/+SZuY9RueTd9h8tgTRvLVEHQhT/zMf?=
 =?iso-8859-1?Q?Q0E/1p1JalefIA/MoNFWCQBZ5U4YNB6otITwZz+qHXQULtMiH837kA28aY?=
 =?iso-8859-1?Q?7QuFstIVuG1QeDih5lDUoAtMU3uKpEDKoNNEkAYjVYbL76dpESBMPB5CLt?=
 =?iso-8859-1?Q?W0VZB7IZ9Hw4P7PuuDflJW2fyinFEdquTk/qIg=3D=3D?=
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)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?XXLUfYhPzD5V/jrrM6NBmeQB1vYBhgf2TS6k4R6Gxe4ai3w2hcHz4+pHax?=
 =?iso-8859-1?Q?A1j3OX6AGnc5O/CnQrtYOEjb87FUjOs9/Gm7kL+CZ+2bROZfsgqn6JKFq0?=
 =?iso-8859-1?Q?yqEAr9F8rK1dyKNqKetpaBVZARi8Xq5r02NkDZEjyb6QAUttuCGvXnRyjl?=
 =?iso-8859-1?Q?Nx7ryXxaO8yJ2NvAf7Kv6iHuX6jhVEiUL8qXDlXtqcF9WiF5Bt15nITpII?=
 =?iso-8859-1?Q?pL1dX0Kbr1tr9fxitzTl7yBja27Ycdf4Nchfq0RM7UK67OeFfceL0sgG68?=
 =?iso-8859-1?Q?MghZ8EPekvSN+ULBsbCp1trWYM3RxpGfBWU2wE5kDWl6bergwnLu443ruq?=
 =?iso-8859-1?Q?TfyHvcLVnSjob95/yjIqk3OZ7/1pGAJaGPG0ksS2/ts55TZPdROBV5+APw?=
 =?iso-8859-1?Q?LbBENVo4/Mjfjhzgukg/bkizNOU880V35uGkyB6zxz5xKWvNo8Duyi1aEq?=
 =?iso-8859-1?Q?YvWWeOcjC9nN2teHybZ8o+O0S3AdqPyWPu+pdBbqETePUoQrGkn6tUaZ23?=
 =?iso-8859-1?Q?jcaQGWoCFRhYWOhhjLCCGAfKU6fgiAZ3KUslBCGcrx1qzOsKGH4hCKkFD6?=
 =?iso-8859-1?Q?/TnLVTAVO6wwnbowq/q/JPSSU4ZDNNwYM4V23dzeLGedVOXKYbj9y0qrqC?=
 =?iso-8859-1?Q?12kaEWnPaKzG5SnNNkIvEOSlFvfUkm2BAn0hiVElzk5V+hnA6h0NKlt6HF?=
 =?iso-8859-1?Q?2e0lkh8+KOkG4RWHtbN3tCSIJ1CTWrL1r/Vw9ZR/FvePRn6MYzlPUdvghg?=
 =?iso-8859-1?Q?DwkBlVI82imFKXzmKiZ9YEqwI8G5RpW/8dsQ+GReKswF/gAIAie0yfcHx3?=
 =?iso-8859-1?Q?OcN0HOy+X9MN7EcAUXTW+8gDjieCdpy/hqsbw8aFJgL5+hCdDJuHBKrwbB?=
 =?iso-8859-1?Q?jsSi0en/zRbwYx1lW1ZSUfM/NdoJWYkUDzQ2jM8f7TPhEptHjXWoP4E93Y?=
 =?iso-8859-1?Q?EpoCpmqn92QxO08vf+Hg9GZgPFvi6Zl8HUq1NHwswWSTN67WLnQMkIGVgx?=
 =?iso-8859-1?Q?QPE1JLQ/xLN6t9wF9zSJiyFLbHjjEo4JWYa0+bhrJUeRTfNqgJ1JIH82/K?=
 =?iso-8859-1?Q?1H2j+6c88moGcfrY1mvbmsMhGnRK53yQeJlhjPhMv4pCtm5jSrgOaXMYib?=
 =?iso-8859-1?Q?jLVLW0vCSMS7TEZ5svoL+p6Z0LBwTySbmThZQj6aoRCEPvOhvtQmfy7ZDl?=
 =?iso-8859-1?Q?miwbicBs5rfonOyKNftgm5XYKnwSAKlQkvT2sjCEToEevp+obtBjtWybgy?=
 =?iso-8859-1?Q?ZNN+ygdW/1fAoH0wnuPC0hn9l0XR1AhQxAq2G4jJSVYdTNTop1gBDogE75?=
 =?iso-8859-1?Q?JlBAAIRJdVBMLqIZIheOMB+xUJWGemp7rFnwvOD8S3kgzV/QWwXvncVLby?=
 =?iso-8859-1?Q?Q7tPniZZQfM2xaNJ9ZFnvetIGzuAtgXZGmiQn6bQL0WXWfJEarAsPh0e32?=
 =?iso-8859-1?Q?GJFENN+Mwy9nTBa3FwZrFMFFL3jowbH9jDf/yy/su6JOipy5wUs1Mbganq?=
 =?iso-8859-1?Q?O05g/D0o1nG+eTQCSUBknDCdK30dxxRmaBaW/wJi0zmL9Rcocl3tMmw7n+?=
 =?iso-8859-1?Q?jV7KhI5Gd8tOOBQeVTaYHrQtek9qgvO1+qzhLX2VRD/Qn0vd6UFvNCm5Xh?=
 =?iso-8859-1?Q?PPPW5zrQu8UnGpLI1qCKiFf5F2hPabn1PqPzVR+Ne6mZ7Hu2CQe/y/uQ?=
 =?iso-8859-1?Q?=3D=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: 929085ee-6142-4c3a-b681-08dd1b7c2711
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2024 13:43:40.1576
 (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: K74TK6xKp2ZkRF9dVuiLgoS4pDdyM5FAmTDBzAgsQt5URQXSmjRUKVpPQG5B++mMm8yY/SFCogeNVCncxahs1w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9747

From: Oleksandr Andrushchenko 

Add Rcar Gen4 platform choice to Kconfig to select all required
drivers automatically.

Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Volodymyr Babchuk 
Signed-off-by: Mykyta Poturai 
---
 xen/arch/arm/platforms/Kconfig | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfi=
g
index 02322c259c..8785c168bd 100644
--- a/xen/arch/arm/platforms/Kconfig
+++ b/xen/arch/arm/platforms/Kconfig
@@ -29,6 +29,15 @@ config RCAR3
 	help
 	Enable all the required drivers for Renesas RCar3
=20
+config RCAR4
+	bool "Renesas RCar4 support"
+	depends on ARM_64
+	select HAS_SCIF
+	select HAS_ITS
+	select IPMMU_VMSA
+	help
+	Enable all the required drivers for Renesas RCar4
+
 config MPSOC
 	bool "Xilinx Ultrascale+ MPSoC support"
 	depends on ARM_64
@@ -55,4 +64,3 @@ config ALL32_PLAT
 config MPSOC_PLATFORM
 	bool
 	default (ALL64_PLAT || MPSOC)
-
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 13:43:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 13:43:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856698.1269235 (Exim 4.92)
	(envelope-from )
	id 1tM5xE-0002f0-Id; Fri, 13 Dec 2024 13:43:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856698.1269235; Fri, 13 Dec 2024 13:43: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 1tM5xE-0002et-F3; Fri, 13 Dec 2024 13:43:40 +0000
Received: by outflank-mailman (input) for mailman id 856698;
 Fri, 13 Dec 2024 13:43: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 1tM5xD-0002en-2l
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 13:43:39 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 (mail-am6eur05on20619.outbound.protection.outlook.com
 [2a01:111:f403:2612::619])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 41585e4a-b958-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 14:43:37 +0100 (CET)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by AS8PR03MB9747.eurprd03.prod.outlook.com
 (2603:10a6:20b:61c::20) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Fri, 13 Dec
 2024 13:43:35 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%5]) with mapi id 15.20.8251.015; Fri, 13 Dec 2024
 13:43: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: 41585e4a-b958-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=pLquUP1+EEHc1Vmi30zUiOWgqDxxtcZ+hmAfXxJtGfXu8AjWpB/70dBrUD9rhnIf7Rzr8DXsTPr4/3fzWdWdwDtJ+UlduYWTZS/T9LyZFBpvAlFVXqT28HxK4aOZi9V9DA1z/H3p4V6SyTr0yoUPiHgi50IV2HjFsWj4+XuZHwtXN1tTucHabBz4usf08UqbznxbO3JXolir7TaTKkstUG3bPF5LOxv98G6363T6QhO8P7GSphy5djGPqT2dQLVM8d3zvO2W4YoVgmyzSluSElhe76hqDabR62LUbAh6S2xikwioO/vkWZmEPse7OTQBAhlISxikAuxQeLsV2IZzTA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=SXs4W9HXe/l7b8kPVdKdc9mxJ4MftveKskpVLf5RVcU=;
 b=w7eqlnwi227zoGxaGbi7Bwix9atGbCAXw9l5vhtG0e801fwU95vC3XVUSh8zNtPtZ6qLE4VmbQykdK8bsyPnhRkYqahEkgw4146+PqXrDY8z25Tgoh0AM1NycirUw3Iar3plCZTX4YqKqbexjKs7p2b74UbyxYNtHPief7LZ5eZXnTDTPgM26NkCDmfNYPhB0WYtuwBA3fUe+9XdB2tG0G1JUwGwYA3xpJmClIXsfAuUzEPMaZuNw9wB0kbWYqQRjtzmySaqbFKoy3c8OqjO5sqjQ6nkmlZhRCN92/j0DigWTVq3gFOsnSnV88Exv3hRd5Ps0g09w1sgH96SXanpXQ==
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=SXs4W9HXe/l7b8kPVdKdc9mxJ4MftveKskpVLf5RVcU=;
 b=eWc0uuAF+pquLGIb3yVfkcu3Fk/RNASpYFr5O5yTcnj0bQuiylO3C0PwD970hhMEQ0Dg3VWhqxyDK/vnEYmQzQtyoIMaP/JdZ9Fc5WIbbmEH4eRyxivEiC8ry0BQkutTNlD0tDwi94E27lABR9TGS8QHzvhVWRATLnymbMyp4L+9YPjBFB0C3+XoJInLgNuKhiwl+C2Cl5gFjvOY0UTnTY49v7wdF8qsLDB0p7LCJMFTlyfG/HnCjtbdAbvciiNdKoWkFJKyiVBHR+zlu/OJgTt2eosuYFMuj9Hh8yG+04mO9wsn6RmepxCR7J/bhpR34WSp+XyGxVZrorLYovYQFw==
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?=
	
Subject: [PATCH 0/2] Add support for Renesas R-Car Gen4
Thread-Topic: [PATCH 0/2] Add support for Renesas R-Car Gen4
Thread-Index: AQHbTWUB27lB14oHWUaGss6v6V2bnw==
Date: Fri, 13 Dec 2024 13:43:35 +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_|AS8PR03MB9747:EE_
x-ms-office365-filtering-correlation-id: 6f6fbd61-b1b8-465e-ebee-08dd1b7c2429
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?59dfAtJNTcsx8/1phTsOXPJZbXqlRFG+Bb+56VlLC91rgr/hnHuTtgHvJ0?=
 =?iso-8859-1?Q?b8Urd001a5hWMFQ/LCGTK2j2AijOP73/Nlu/mMaFu+A0RzLj3ePK5JLoHM?=
 =?iso-8859-1?Q?IcdcrkgXh0JmLtEbOJBNXPQ7cOMHaVusTgaSlIpRNM6Et8f2gBpHtDr+lR?=
 =?iso-8859-1?Q?e2oHGtpT/9WC0SKL2a2VOIRSVBI9nyw67ublOPqbwpLnM7YyVhxt1CtryJ?=
 =?iso-8859-1?Q?aUDx0MMfC+oH2pBmw5pYbnuZp9kmUAg8QKNuS0+pUYEVCtZMDhvvxFDa2R?=
 =?iso-8859-1?Q?1av5efhIFekIzjq+xUXCkJvVsxy2KdKQpI1fn7SHqZN34uYQh9CBMxAm+M?=
 =?iso-8859-1?Q?2AjIVZAkR/LS5rtCzF4+lf6hXuxQpZCnN0pvYRyAfGXBgmtNT2WcPx1FuE?=
 =?iso-8859-1?Q?1kckz5g4FJOnVf31JDMftfwiFppGhPO3JU2NqwKhEdmh1YTqBMDYMVG46H?=
 =?iso-8859-1?Q?R3SEt5moBsxPjtFqGZdnbRASyDf6wnrScXsBiKLoezce8mdQdk+bZnXGAN?=
 =?iso-8859-1?Q?rwUYK80lUQdZZoLXGJczX+KetYfMKs6QDPecZJgSzoQrEzj3qVfcsWrmJz?=
 =?iso-8859-1?Q?PuWEX/djPmd3zMJKTcJR6h9ZgjGX6nAXywEhEuhFbZYYX0Zl4O8W/DmNzg?=
 =?iso-8859-1?Q?BvloAk9tDzlP5rv9+QTJLLOycLEfbs7hBLTrYpujqO3ymY6RMvWT0CXv3l?=
 =?iso-8859-1?Q?4Z/MlxCTmG/kyACHdwxdWJ7EcsiSxFkTM8J4upJNy16UenSgartm6V0pO4?=
 =?iso-8859-1?Q?skV0qKdEBp6Ujn/rTE/byqN3omtRNhwWsRl27zKoO6iiuccjx63ZNGFsCc?=
 =?iso-8859-1?Q?CbA8KdFFN3dCuHCHjdmjWLDiHPRT3jt+EAcGjIySO7Je3F96FfVwP04AjC?=
 =?iso-8859-1?Q?ciPO9QJVBRklV/+0d69j01uKaB0FO4wNIz7oaaxAqr2s+SgcgYE5R1sZ7N?=
 =?iso-8859-1?Q?7NHJbWFhT3keQ+VCAQedZGIxgPj61pl8KtyridKlRg5+rklrGBZTKb9oUx?=
 =?iso-8859-1?Q?+tzI19ntLLeuUHheIzm6NmWp3/2Ue+e0+JDhNQRwvJlUOLx+MCQN9JkDBr?=
 =?iso-8859-1?Q?Dgnavm73tblbO3cjbSaD+fjQ+sLYMSHcbdsz8HKxKaQGs3GPKMZtHwtDH4?=
 =?iso-8859-1?Q?HFMPzi6aGVVdvC9dTwjTufIbo0PRq6ZpFuc9+2G/eNUzYnsUW8o7yw5X9k?=
 =?iso-8859-1?Q?R0FAs/yaCIsdMYtXPyxPE+C3tKleONydozOsN4bto4xrNOL3HonQoWjhO3?=
 =?iso-8859-1?Q?pYVbjH84A0sFn9Yewbanol8XnXgbCbIOW2d1XSFtLWKJXOa7jY/Nq12McP?=
 =?iso-8859-1?Q?zuwkxPSJpZbPv8yWWREFrAj8gbCHBYxyLxZuTHj6J0kIUZhcVnNwhwWlj7?=
 =?iso-8859-1?Q?pLf67X2O6hChlqffJ13Q0eZJnyvOQjli/3E+Ms0MF46EPcZtndqlmHeu1U?=
 =?iso-8859-1?Q?eQGovK44DuajrOra29VqHMNVinQAhbGy3Nkxcg=3D=3D?=
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)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?yLD2nKhS9kI42WvCyeWMPxdJ+0BiWBnaBk1CI4iUdd/DHtARCOrk2M6QYA?=
 =?iso-8859-1?Q?auK9GVdRRkp8rpdh2C7h4+VCxz6zgg4nhLiu5tX0I8bUlMT17mnxvryT13?=
 =?iso-8859-1?Q?a4YvP8DnSQBOYKv/7lrJ/E1myF/jdAbnYNyujJJ464kLiUJ9ONXX/7xrij?=
 =?iso-8859-1?Q?XLlpuPMmFYzI7UDprOlA/8Mhx2biA8udHJ+PI3cL+ecrOd3kyLdxAYW9C9?=
 =?iso-8859-1?Q?+Pvda2bmOwohs1+kOc4Y3y5G6bK00VudWlaJofxkKGn0+xewg2jUy+5R94?=
 =?iso-8859-1?Q?3+oFIRFq0O1A41pxxK2fUl0x7qLeCDLI4u4Q7+6p+A1SjpuDQd6StGw88T?=
 =?iso-8859-1?Q?dZ7mjn4IpSK3O6VADErAdcE9k7s4MQBEjWR8ddNEZUfR2w7qOulJnSN15P?=
 =?iso-8859-1?Q?CuIspLwTKx0e6B8QvAYwDHRGX/Ylrn03zjqblyWXqXDij3AhKWMA87+7Ih?=
 =?iso-8859-1?Q?4mT1PEhlBVmIaMdnxBawKgDTZxi/AruqOC7XGF0V8/Th2wEJSySBVCNo3q?=
 =?iso-8859-1?Q?1t2oo4bj+rZFypx5IU/q6dW3f7IN5UDdKOqvu+9NNU5G7hcGPdK7nz/aSq?=
 =?iso-8859-1?Q?FcDGc2pnMdAAKCalYP8OcgPSLZCOaUra4G67SPVyPYzVkL4hHYlDkVwg8U?=
 =?iso-8859-1?Q?wP7a2tEsmcXjtggQuE2qwX+fKbkSaKnkW9Eku4rK1BclOZPaiY7Wqo6E5l?=
 =?iso-8859-1?Q?HDGp9ORrU2puQ6zl7a3wAF1+2xHG0N4nC4kkR6nPdhTUbLWJjgaqenH09e?=
 =?iso-8859-1?Q?PuFxLcirgQKO4cc8QZdujA061FHEDnlY4i6kkzMDnNq9+xpqhPBNR1yMas?=
 =?iso-8859-1?Q?EUKvfkNn7uF294S3GFDLRTWDHgg8iS0RxP9OmDWLAfVFhEfz6yU52fx1X+?=
 =?iso-8859-1?Q?aRLb6c5DkYS74S1R8pznVor24snF9tWxTRQXRrca7dw5Da9Px0bT54DyEP?=
 =?iso-8859-1?Q?XgCLHmxpc+wgeKUR7PV98GBV/c+3EZ3De+02n60MG8KYsYM6lqX4u3/kZY?=
 =?iso-8859-1?Q?DrAH8gqI3xeP/vaXo2JhhXtGUEr6DcHDBRaKoosfP1dTmO8FC4TGU9+L4O?=
 =?iso-8859-1?Q?dY3lZaOkftjkQYiDB/Cej2Sj2VGGPQMfn3TzRH4k0Z8LF6qeFezxPNpE1I?=
 =?iso-8859-1?Q?hOczBdftmpAkYSe1cwqzS0KVU06UmTfO7Evnb08hQC7AuDEZ4FPq4R+qZw?=
 =?iso-8859-1?Q?nRtJ6bff9ZjaJONCnSHUm+Hbyvq4hchx3/85/gKcc6/KWxPCw/mSs5/eKw?=
 =?iso-8859-1?Q?+2HtMrXf/gbFPrfXbv14uZPEZURZ2PSGhKuL/r6a6AouZNna2P6OmZC7+V?=
 =?iso-8859-1?Q?YeyrqDVHFNAJ/WjDlfJR9CZov9Np9fJfEM7b3KTvP+OkysMFpwo1p8wiVR?=
 =?iso-8859-1?Q?RzgkuZDQ+OOvM4M929K5ADvz+l69yB9wVIVhfGJaipuv78MD1Teq7i96DF?=
 =?iso-8859-1?Q?Tq72vCw8/a3BRI+c3wB4rGNa9+tHW6+Fwu8sGTzn/ZI0rZzu+lTQ1+6u+w?=
 =?iso-8859-1?Q?9q1JaOcfEZ1B9JWKGCpUhm02ClaT3jnM6D2aOkdHBJLtTusZi/aq+pH3dz?=
 =?iso-8859-1?Q?LYQ5iMghR3uW6mkK1PfMS9vSnbsqXgVtj/TlyST/8EVXzndiE+1h6dYsqo?=
 =?iso-8859-1?Q?+xTNY84zWoUV3xqZjF462Ko/3RH66ulQD4l6tZPn2YgNriKvM5295cww?=
 =?iso-8859-1?Q?=3D=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: 6f6fbd61-b1b8-465e-ebee-08dd1b7c2429
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2024 13:43:35.2565
 (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: aKOhXExHF2oFIIMvvZjmSZAQwVfVW2XTG0KxeedYGZF/uqyNlE52DB6tFE0c1vYGRp72VZemLdKnTN4+XMZ08A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9747

Add support for Renesas Gen4 boards such as S4[1] and V4H[2] by adding the
appropriate confing option, and support for the Gen4 ITS.
Tested on Renesas R-Car V4H board.

[1]: https://www.renesas.com/en/products/automotive-products/automotive-sys=
tem-chips-socs/r-car-s4-automotive-system-chip-soc-car-servercommunication-=
gateway
[2]: https://www.renesas.com/en/products/automotive-products/automotive-sys=
tem-chips-socs/r-car-v4h-best-class-deep-learning-very-low-power-system-chi=
p-automated-driving-level-2level-3

Oleksandr Andrushchenko (2):
  ARM: ITS: implement quirks and add support for Renesas Gen4 ITS
  xen/arm: platform: Add support for R-Car Gen4

 xen/arch/arm/gic-v3-its.c             | 90 ++++++++++++++++++++++++---
 xen/arch/arm/gic-v3-lpi.c             | 14 +++--
 xen/arch/arm/include/asm/gic_v3_its.h |  8 +++
 xen/arch/arm/platforms/Kconfig        | 10 ++-
 xen/arch/arm/vgic-v3-its.c            |  8 +--
 xen/common/xmalloc_tlsf.c             | 18 +++++-
 xen/include/xen/xmalloc.h             |  4 ++
 7 files changed, 131 insertions(+), 21 deletions(-)

--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 13:43:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 13:43:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856699.1269245 (Exim 4.92)
	(envelope-from )
	id 1tM5xH-0002tH-Pf; Fri, 13 Dec 2024 13:43:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856699.1269245; Fri, 13 Dec 2024 13:43:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tM5xH-0002tA-Ml; Fri, 13 Dec 2024 13:43:43 +0000
Received: by outflank-mailman (input) for mailman id 856699;
 Fri, 13 Dec 2024 13:43: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 1tM5xG-0002su-5D
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 13:43:42 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 (mail-am6eur05on20613.outbound.protection.outlook.com
 [2a01:111:f403:2612::613])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 42ac9a5c-b958-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 14:43:40 +0100 (CET)
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 (2603:10a6:102:30d::12) by AS8PR03MB9747.eurprd03.prod.outlook.com
 (2603:10a6:20b:61c::20) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Fri, 13 Dec
 2024 13:43:38 +0000
Received: from PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971]) by PAVPR03MB10102.eurprd03.prod.outlook.com
 ([fe80::35ac:8893:c31c:b971%5]) with mapi id 15.20.8251.015; Fri, 13 Dec 2024
 13:43: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: 42ac9a5c-b958-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kAzDxXP+PGPfqPvkLRzNqzMgOwwNTp4qSumEsWBBMxd8BbL2I5cDM2ZjZGMKSNccjgXuT7/e9Yuboj4vfcssm7TRAHhRUcHpIeGH089cebA2s15NTBAcqrCtH6vd3A/vVEJ6o36KrVY1kliukUPFknwX+OgLNHsBx+aITJJVptVbOaC+t1UAuBdIsclVGA+0jbmRTQXZvPF1BV+cV20OW8fyZKECcrK183PxDVeoBJlAzPIicwr14ioTDaJFjJWyJt06YeP6/d6i7vPn1hedXBIvQC3QqU5Gk7/w7wyVcnJNCpGUqNFvpsYC3xYa/5W0LVrY2erZ2yLYDpTjwZ3PPw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=8m82pZphfIXwF4z/QxJwwNRwFlrHF7j9oOsgHJHvG7M=;
 b=gvvTxVr4fNTFohG8qpFEf9YF+q0NznZAx6RCxPpBs7WkRaF5rvA+9RoQAVqssqg6LJYnZubWop/aEYaq1BG8jBvI6hNgdzELO0z0yBF3EIltH9l8193WQe+9XCPA73UtoHRRNSA7vDdzOXmmPlsUOCbEY/yoncw29stytIb4dvOU4RF3WbKRMa8IzHO4NC2AleHf+RZj4zs2Ld1WG6qy1Uq9bzxWFHUNUoTYf2fKeD62vZH1xNetqqy4LWmZrEQeeNN3yNlYi6NGDlwr86fjkbZbObyCxaluqjrQXRYbelJICuazEa40sf6VqkWtrMcro6JcKo/dZq7gxxZ2Z8Mw3g==
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=8m82pZphfIXwF4z/QxJwwNRwFlrHF7j9oOsgHJHvG7M=;
 b=Cc7ukpAIpV7dc9jztd2CIl3FoNx1upwPD2nwwFdPa8KlnmA5A667Ya+fIPerl+C3CtaQCD61qle6Q95c/inG41ErpRq1xrLF+vn8JR+A8C9/okgldoHKHr6p7rNAodcBC4WpcIfV2/zDknTWVeTyAm7zCI6IkKhW1RJYkBmLoOgBhmHICrSxLjb3VN91tofa8oWcx2ZtNuT2n6GFlFXODxYlNi+GYK6UT06zmj1MWtPHnDDR3lc21AsLydDfUFoA7mIsZ1S3TiGZAo9tiewDFt9SS2l3E5/6APqezflQbPAawp7f9P8Guy2X38OTpl6vOq+w+qaXFnHPDci9fEUL9Q==
From: Mykyta Poturai 
To: "xen-devel@lists.xenproject.org" 
CC: Oleksandr Andrushchenko , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Michal Orzel ,
	Volodymyr Babchuk , Andrew Cooper
	, Anthony PERARD , Jan
 Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?=
	, Mykyta Poturai 
Subject: [PATCH 1/2] ARM: ITS: implement quirks and add support for Renesas
 Gen4 ITS
Thread-Topic: [PATCH 1/2] ARM: ITS: implement quirks and add support for
 Renesas Gen4 ITS
Thread-Index: AQHbTWUDkPvtOs/CJU+9P/F/tFzopw==
Date: Fri, 13 Dec 2024 13:43:38 +0000
Message-ID:
 <2ea26be2689585ea254a9c0177816722bcb2db8d.1734096752.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_|AS8PR03MB9747:EE_
x-ms-office365-filtering-correlation-id: 2b1849ca-faf7-400c-261a-08dd1b7c25ea
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info:
 =?iso-8859-1?Q?xnUBcbig9o+7RZWWGjo1yf7UpO7YiNXapL4DN4EJjSv+bKmupyrVdzymvf?=
 =?iso-8859-1?Q?i2do+1DuRKWFNIYFgpKpPzIGffEnoNwHVquY4a9r8IhNUbLJkK8nwqsFau?=
 =?iso-8859-1?Q?kmERftUA9Zb9Fw0pLPcu0ll/q8c/fBTc+/r3tA48MPeQmXpaeFEJGPydag?=
 =?iso-8859-1?Q?/yMF/8TL+2If2x3euyOwo2ctdx6Ud3QRzJmxrzcqE9Li+Q44RF/aG6NxWv?=
 =?iso-8859-1?Q?wfRr/gID2+7nZxI7AB+LfphIBz0GQPk1xgcGQe3zDawONNJz31q70cAX6F?=
 =?iso-8859-1?Q?wYJSAnnBqgC6LZ4sdcr0ExU1jPL1eZWhahN3gYW/dSt2qa5Cj8Xfymi4SQ?=
 =?iso-8859-1?Q?W74T651eDLHfaW7B9KtjX6F1ShuoU0w2PovIbb6rmywDu4BcLnoZ1JdZth?=
 =?iso-8859-1?Q?BbbMBf9mSD3UqWwGzFdV4nToph2QpHStR1zfjXtN8FQ6rUmfhvareGPL6m?=
 =?iso-8859-1?Q?jOO+DAUAO/HTvqyZ1JOO84haO/By3steYgU2Zq4WNBwCGcHecmJ/Yn2muo?=
 =?iso-8859-1?Q?5a3NCblkIIZaOsfr0IZO6wmlhFf+zjLBxtzUgUkbr6gN7W+vEx1V8ZANom?=
 =?iso-8859-1?Q?A8puoT5k4BLdTd/bTq03S+Ec2veyPr3LTxXcidkx8SnMI9EGKt8c+s1Mcs?=
 =?iso-8859-1?Q?C62v0tBkrTuTH5Kz/h+oyb/7G9ryfxR0QSaxf+izD0VkeEj27qjKy7ZZ4q?=
 =?iso-8859-1?Q?gbkXXWhnc8+JI+7bYtYXoLuS6GAWVbglv4gizkZ7bitc3vats282QHDUVF?=
 =?iso-8859-1?Q?U2XdVMfSdN7iTjXWZZGrlu0XxCwlf5Utq8+sLboSAFfMVXEkSV0rf0U+oH?=
 =?iso-8859-1?Q?0JZ+gIT3qwnDd1RsTxyyiF+b/yHuqiY65ql7f+4XjeUs5Q3FKF9O6YX44D?=
 =?iso-8859-1?Q?Vtifp+E2DFq8OTDOL6F2/wcaJHYcxVdXlh1Ay1yODCimBboKP8xV793DtD?=
 =?iso-8859-1?Q?y8A/eOh5JrB8vQaimYASQvbjFTApIU/F0jyHyRr3uaVIbQbPYDRU3qSRyZ?=
 =?iso-8859-1?Q?uUXcYomP6FINNak6sg/2o4B3sUXtRGKVRBOL+xhvopqatrn3/A6urkIuZ1?=
 =?iso-8859-1?Q?QnFq8q+bJM+/nYm8++2iVmLDMd0YDUZl8Pw38ApWuAByxdkjvzqHLP8v4a?=
 =?iso-8859-1?Q?eWY2xsern5vKzCkumSWQH2V+g9nQusXnmFcMoctELLE/xiLVkE40EUsYx2?=
 =?iso-8859-1?Q?SSixuPzOk4ZCDrwbzL3jqLSOgL6fxrAStoCjBHeX/8/hUOP7Hnfnby177P?=
 =?iso-8859-1?Q?ZkuIC4nnXOGOobXKsR9X1dU17HeLCDVpn1t3MPrVYyldJULLaNMvJe9c3I?=
 =?iso-8859-1?Q?upoUI62K/i7SFMxBW8v2RUmybPJmO9MwrRh1p0tsmr8Y20XlHYYQzl6Rqn?=
 =?iso-8859-1?Q?zYEmuKYVwknVxiJ8N+tD02sdgxKDahFsbIInF1vviWXZfq06xsKSM=3D?=
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)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?3a3Yc+ZkJ8u6mJY1A+e25bLjGEpjPINyNqr/GG92le9LoAQ/q8Kwm/LDJ3?=
 =?iso-8859-1?Q?hpob7abZKMLxukDVCapx0DiBMxgl6bFs2SSHR5ygZQiPk5yO2C07qbmHoY?=
 =?iso-8859-1?Q?dH59QIDtSw00eNtGpoSWSBPpz4dmos7tx5jfGT6EfgyR9Y19tDKR/v7x05?=
 =?iso-8859-1?Q?3IQ/ZH6go5c2pobpp3+OL/QcnAdXgr9NOEyqBS2NWeBJrIan+nbyimYH8b?=
 =?iso-8859-1?Q?osMEnNv10nj1xdkAkLjRQ6dJhG0nZ6L2qjX56vkK3jtUXO1H6Qwwjf9jW2?=
 =?iso-8859-1?Q?J7i7RcQiieAQJwTen+NwpQCsPhyiYZ5DshH/VTZD4C+ZgqfJDIPhRcHWEl?=
 =?iso-8859-1?Q?9ljurxvMpjgoH7pkQmJJH4u3HbtQ8A5dUzd+1Y92DfdWRXbGmKyMqthRnJ?=
 =?iso-8859-1?Q?7R7bEYEMGBJtqu/hmtPdWxolOJtWcZ+aFSxbZ68/+LqL9QL3S4l0jNUUvd?=
 =?iso-8859-1?Q?3iORsUYum9QsypolvErFioQSlJy1r0qN2IxhkN52I5e3CgiveEZq9UKH3v?=
 =?iso-8859-1?Q?IFQrJdkokFoPZAuoazxdgYgvdobBFYT2yJMduoWgRZGsCzg7NgGjyWDGMZ?=
 =?iso-8859-1?Q?sbZsHAx3KEzz/XnCWlrC9sV9A6Xd2TL2iCd7vkt2q+zTk/QWIGEf3Ednl0?=
 =?iso-8859-1?Q?gVZAdWTyVg/egXvPyw7p3hIUjiUqP1ZIdO8WCKfi6ukq+7hgvYm9cFQg2m?=
 =?iso-8859-1?Q?UoPLfUNadToPBhMmVwEXaMbrT8hXXf4nF102mJpCagM6/IWRnhfeh6SPi1?=
 =?iso-8859-1?Q?RO73BQ0wF5avmvq62WmP1R5CeymrxDNY07DQq/syYUJ+Xv/dDhoRlW0fBa?=
 =?iso-8859-1?Q?sEWqJsTFeL1z1v5b3MGnWrEvfF2CPVdzGuGG4ugx5NN27VNml/D+P6gmyr?=
 =?iso-8859-1?Q?e00tnFEjq+qb1mkuW6x1ac6PF4NspB91hUYt6JjZ9En85Vkc6Snly4I3hj?=
 =?iso-8859-1?Q?FBhaJW50kA8RlEf2SZud/hri9qfinE6PHs1Q9CAJQrenivGBI+IS9d60LZ?=
 =?iso-8859-1?Q?C7ilw66gMNeTdsXUdprf7m+wB9rpFkXvRQgdLhwtmF+ENpv49/gKso0kMV?=
 =?iso-8859-1?Q?gGu6m5mLjy5Q/d4YPfSmTXCPir4FI9EpnQRut1kfDhznIYYaSwJ5oJpW1m?=
 =?iso-8859-1?Q?+1v0zynsAFZJUmNk1+n78FSxCfhAnm3uE79bQBYD8QVW1MHLb9/NSzsS+v?=
 =?iso-8859-1?Q?Tib/T1bo9QPU+glR+cK7huPIVzQYQPCdav3GNgxeUYTOmGlRO59/shJBCd?=
 =?iso-8859-1?Q?nVuXB57wN/f5KGd3j+TbIk3Zd5xrOWrdJ2pGFa3FAO2fBiOsCxTFspS7Ya?=
 =?iso-8859-1?Q?rVeyFgh7eZNA/IXiP+m1qaS6brOxdMVBQKSc06XzzB0TwLLCGqad7braE4?=
 =?iso-8859-1?Q?8j9zOa+f76Jogqywoq+/HSaHAy54/eKwTNt+RuKWKqcrFF5F0AqcHUvjun?=
 =?iso-8859-1?Q?vg9FsFOwnzqg6VhAwN8T1GHcS5ou+JiFmwAtflh7iCDpnr0ANw7U0FElFU?=
 =?iso-8859-1?Q?zNLlrY5gbafJFO7RWXEkyd5gZUvZXQ3pxGSnwJsPA8HKjrVu1jV45igd/1?=
 =?iso-8859-1?Q?pxTSfQrpacpdQfdx4fHcx13frRjhzpBPSmNoklNvza9NzuPfxHSe62ZqLH?=
 =?iso-8859-1?Q?upkGPmASFXuCJTSaL9j+wHE3KNK7vMU0Sd++gdHfVcR5Yk3oF1BJ/ijA?=
 =?iso-8859-1?Q?=3D=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: 2b1849ca-faf7-400c-261a-08dd1b7c25ea
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2024 13:43:38.2425
 (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: aePkeOQXJ/fgWAb5vj4hpg5Y0AkWpuqYYZIZpjmkWms6DtvZbfCzULoX+CaecbEWXbvPaCEm8xdSD2DLdHykdQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB9747

From: Oleksandr Andrushchenko 

There are number of ITS implementations exist which are different from
the base one which have number of functionalities defined as is
"IMPLEMENTATION DEFINED", e.g. there may exist differences in cacheability,
shareability and memory requirements and others. This requires
appropriate handling of such HW requirements which are implemented as
ITS quirks: GITS_IIDR (ITS Implementer Identification Register) is used to
differentiate the ITS implementations and select appropriate set of
quirks if any.

As an example of such ITSes add quirk implementation for Renesas Gen4 ITS:
- add possibility to override default cacheability and shareability
settings used for ITS memory allocations;
- add possibility to allocate memory used by ITS with specific memory
requirements: introduce _x{z|m}alloc_whole_pages functions and free the
memory with xfree as usual.

The idea of the quirk implementation is inspired by the Linux kernel ITS
quirk implementation [1].

Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Mykyta Poturai 

[1] https://elixir.bootlin.com/linux/v5.16.1/source/drivers/irqchip/irq-gic=
-v3-its.c
---
 xen/arch/arm/gic-v3-its.c             | 90 ++++++++++++++++++++++++---
 xen/arch/arm/gic-v3-lpi.c             | 14 +++--
 xen/arch/arm/include/asm/gic_v3_its.h |  8 +++
 xen/arch/arm/vgic-v3-its.c            |  8 +--
 xen/common/xmalloc_tlsf.c             | 18 +++++-
 xen/include/xen/xmalloc.h             |  4 ++
 6 files changed, 122 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 5fd83af25a..b1a2cdccc5 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -50,6 +50,77 @@ struct its_device {
     struct pending_irq *pend_irqs;      /* One struct per event */
 };
=20
+/*
+ * It is unlikely that a platform implements ITSes with different quirks,
+ * so assume they all share the same.
+ */
+struct its_quirk {
+    const char *desc;
+    bool (*init)(struct host_its *hw_its);
+    uint32_t iidr;
+    uint32_t mask;
+};
+
+uint32_t its_quirk_flags;
+
+static bool gicv3_its_enable_quirk_gen4(struct host_its *hw_its)
+{
+    its_quirk_flags |=3D HOST_ITS_WORKAROUND_NC_NS |
+        HOST_ITS_WORKAROUND_32BIT_ADDR;
+
+    return true;
+}
+
+static const struct its_quirk its_quirks[] =3D {
+    {
+        .desc	=3D "R-Car Gen4",
+        .iidr	=3D 0x0201743b,
+        .mask	=3D 0xffffffff,
+        .init	=3D gicv3_its_enable_quirk_gen4,
+    },
+    {
+        /* Sentinel. */
+    }
+};
+
+static void gicv3_its_enable_quirks(struct host_its *hw_its)
+{
+    const struct its_quirk *quirks =3D its_quirks;
+    uint32_t iidr =3D readl_relaxed(hw_its->its_base + GITS_IIDR);
+
+    for ( ; quirks->desc; quirks++ )
+    {
+        if ( quirks->iidr !=3D (quirks->mask & iidr) )
+            continue;
+        if ( quirks->init(hw_its) )
+            printk("GICv3: enabling workaround for ITS: %s\n", quirks->des=
c);
+    }
+}
+
+uint64_t gicv3_its_get_cacheability(void)
+{
+    if ( its_quirk_flags & HOST_ITS_WORKAROUND_NC_NS )
+        return GIC_BASER_CACHE_nC;
+
+    return GIC_BASER_CACHE_RaWaWb;
+}
+
+uint64_t gicv3_its_get_shareability(void)
+{
+    if ( its_quirk_flags & HOST_ITS_WORKAROUND_NC_NS )
+        return GIC_BASER_NonShareable;
+
+    return GIC_BASER_InnerShareable;
+}
+
+unsigned int gicv3_its_get_memflags(void)
+{
+    if ( its_quirk_flags & HOST_ITS_WORKAROUND_32BIT_ADDR )
+        return MEMF_bits(32);
+
+    return 0;
+}
+
 bool gicv3_its_host_has_its(void)
 {
     return !list_empty(&host_its_list);
@@ -291,11 +362,12 @@ static void *its_map_cbaser(struct host_its *its)
     uint64_t reg;
     void *buffer;
=20
-    reg  =3D GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
+    reg  =3D gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHIFT=
;
     reg |=3D GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY_=
SHIFT;
-    reg |=3D GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT=
;
+    reg |=3D gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILITY=
_SHIFT;
=20
-    buffer =3D _xzalloc(ITS_CMD_QUEUE_SZ, SZ_64K);
+    buffer =3D _xzalloc_whole_pages(ITS_CMD_QUEUE_SZ, SZ_64K,
+                                  gicv3_its_get_memflags());
     if ( !buffer )
         return NULL;
=20
@@ -342,9 +414,9 @@ static int its_map_baser(void __iomem *basereg, uint64_=
t regc,
     unsigned int table_size;
     void *buffer;
=20
-    attr  =3D GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
+    attr  =3D gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHIF=
T;
     attr |=3D GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY=
_SHIFT;
-    attr |=3D GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIF=
T;
+    attr |=3D gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILIT=
Y_SHIFT;
=20
     /*
      * Setup the BASE register with the attributes that we like. Then read
@@ -357,7 +429,8 @@ retry:
     /* The BASE registers support at most 256 pages. */
     table_size =3D min(table_size, 256U << BASER_PAGE_BITS(pagesz));
=20
-    buffer =3D _xzalloc(table_size, BIT(BASER_PAGE_BITS(pagesz), UL));
+    buffer =3D _xzalloc_whole_pages(table_size, BIT(BASER_PAGE_BITS(pagesz=
), UL),
+                                  gicv3_its_get_memflags());
     if ( !buffer )
         return -ENOMEM;
=20
@@ -453,6 +526,8 @@ static int gicv3_its_init_single_its(struct host_its *h=
w_its)
     if ( ret )
         return ret;
=20
+    gicv3_its_enable_quirks(hw_its);
+
     reg =3D readq_relaxed(hw_its->its_base + GITS_TYPER);
     hw_its->devid_bits =3D GITS_TYPER_DEVICE_ID_BITS(reg);
     hw_its->evid_bits =3D GITS_TYPER_EVENT_ID_BITS(reg);
@@ -681,7 +756,8 @@ int gicv3_its_map_guest_device(struct domain *d,
     ret =3D -ENOMEM;
=20
     /* An Interrupt Translation Table needs to be 256-byte aligned. */
-    itt_addr =3D _xzalloc(nr_events * hw_its->itte_size, 256);
+    itt_addr =3D _xzalloc_whole_pages(nr_events * hw_its->itte_size, 256,
+                                    gicv3_its_get_memflags());
     if ( !itt_addr )
         goto out_unlock;
=20
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index de4b0eb4a4..72b725a624 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -237,7 +237,8 @@ static int gicv3_lpi_allocate_pendtable(unsigned int cp=
u)
      * The GICv3 imposes a 64KB alignment requirement, also requires
      * physically contiguous memory.
      */
-    pendtable =3D _xzalloc(lpi_data.max_host_lpi_ids / 8, SZ_64K);
+    pendtable =3D _xmalloc_whole_pages(lpi_data.max_host_lpi_ids / 8, SZ_6=
4K,
+                                     gicv3_its_get_memflags());
     if ( !pendtable )
         return -ENOMEM;
=20
@@ -272,9 +273,9 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdist_=
base)
=20
     ASSERT(!(virt_to_maddr(pendtable) & ~GENMASK(51, 16)));
=20
-    val  =3D GIC_BASER_CACHE_RaWaWb << GICR_PENDBASER_INNER_CACHEABILITY_S=
HIFT;
+    val  =3D gicv3_its_get_cacheability() << GICR_PENDBASER_INNER_CACHEABI=
LITY_SHIFT;
     val |=3D GIC_BASER_CACHE_SameAsInner << GICR_PENDBASER_OUTER_CACHEABIL=
ITY_SHIFT;
-    val |=3D GIC_BASER_InnerShareable << GICR_PENDBASER_SHAREABILITY_SHIFT=
;
+    val |=3D gicv3_its_get_shareability() << GICR_PENDBASER_SHAREABILITY_S=
HIFT;
     val |=3D GICR_PENDBASER_PTZ;
     val |=3D virt_to_maddr(pendtable);
=20
@@ -301,9 +302,9 @@ static int gicv3_lpi_set_proptable(void __iomem * rdist=
_base)
 {
     uint64_t reg;
=20
-    reg  =3D GIC_BASER_CACHE_RaWaWb << GICR_PROPBASER_INNER_CACHEABILITY_S=
HIFT;
+    reg  =3D gicv3_its_get_cacheability() << GICR_PROPBASER_INNER_CACHEABI=
LITY_SHIFT;
     reg |=3D GIC_BASER_CACHE_SameAsInner << GICR_PROPBASER_OUTER_CACHEABIL=
ITY_SHIFT;
-    reg |=3D GIC_BASER_InnerShareable << GICR_PROPBASER_SHAREABILITY_SHIFT=
;
+    reg |=3D gicv3_its_get_shareability() << GICR_PROPBASER_SHAREABILITY_S=
HIFT;
=20
     /*
      * The property table is shared across all redistributors, so allocate
@@ -312,7 +313,8 @@ static int gicv3_lpi_set_proptable(void __iomem * rdist=
_base)
     if ( !lpi_data.lpi_property )
     {
         /* The property table holds one byte per LPI. */
-        void *table =3D _xmalloc(lpi_data.max_host_lpi_ids, SZ_4K);
+        void *table =3D _xmalloc_whole_pages(lpi_data.max_host_lpi_ids, SZ=
_4K,
+                                           gicv3_its_get_memflags());
=20
         if ( !table )
             return -ENOMEM;
diff --git a/xen/arch/arm/include/asm/gic_v3_its.h b/xen/arch/arm/include/a=
sm/gic_v3_its.h
index c24d4752d0..0737e67aa6 100644
--- a/xen/arch/arm/include/asm/gic_v3_its.h
+++ b/xen/arch/arm/include/asm/gic_v3_its.h
@@ -110,6 +110,9 @@
 #define HOST_ITS_FLUSH_CMD_QUEUE        (1U << 0)
 #define HOST_ITS_USES_PTA               (1U << 1)
=20
+#define HOST_ITS_WORKAROUND_NC_NS       (1U << 0)
+#define HOST_ITS_WORKAROUND_32BIT_ADDR  (1U << 1)
+
 /* We allocate LPIs on the hosts in chunks of 32 to reduce handling overhe=
ad. */
 #define LPI_BLOCK                       32U
=20
@@ -197,6 +200,11 @@ struct pending_irq *gicv3_assign_guest_event(struct do=
main *d,
 void gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id,
                                  uint32_t virt_lpi);
=20
+/* ITS quirks handling. */
+uint64_t gicv3_its_get_cacheability(void);
+uint64_t gicv3_its_get_shareability(void);
+unsigned int gicv3_its_get_memflags(void);
+
 #else
=20
 #ifdef CONFIG_ACPI
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index c65c1dbf52..f5deb18497 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -1191,7 +1191,7 @@ static void sanitize_its_base_reg(uint64_t *reg)
     {
     case GIC_BASER_OuterShareable:
         r &=3D ~GITS_BASER_SHAREABILITY_MASK;
-        r |=3D GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
+        r |=3D gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHI=
FT;
         break;
     default:
         break;
@@ -1203,7 +1203,7 @@ static void sanitize_its_base_reg(uint64_t *reg)
     case GIC_BASER_CACHE_nCnB:
     case GIC_BASER_CACHE_nC:
         r &=3D ~GITS_BASER_INNER_CACHEABILITY_MASK;
-        r |=3D GIC_BASER_CACHE_RaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT=
;
+        r |=3D gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILI=
TY_SHIFT;
         break;
     default:
         break;
@@ -1455,9 +1455,9 @@ static int vgic_v3_its_init_virtual(struct domain *d,=
 paddr_t guest_addr,
     if ( !its )
         return -ENOMEM;
=20
-    base_attr  =3D GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHI=
FT;
+    base_attr  =3D gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY=
_SHIFT;
     base_attr |=3D GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEAB=
ILITY_SHIFT;
-    base_attr |=3D GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY=
_SHIFT;
+    base_attr |=3D gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEA=
BILITY_SHIFT;
=20
     its->cbaser  =3D base_attr;
     base_attr |=3D 0ULL << GITS_BASER_PAGE_SIZE_SHIFT;    /* 4K pages */
diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
index 5e55fc463e..f7f00db044 100644
--- a/xen/common/xmalloc_tlsf.c
+++ b/xen/common/xmalloc_tlsf.c
@@ -537,14 +537,15 @@ static void cf_check xmalloc_pool_put(void *p)
     free_xenheap_page(p);
 }
=20
-static void *xmalloc_whole_pages(unsigned long size, unsigned long align)
+void *_xmalloc_whole_pages(unsigned long size, unsigned long align,
+                           unsigned int memflags)
 {
     unsigned int i, order;
     void *res, *p;
=20
     order =3D get_order_from_bytes(max(align, size));
=20
-    res =3D alloc_xenheap_pages(order, 0);
+    res =3D alloc_xenheap_pages(order, memflags);
     if ( res =3D=3D NULL )
         return NULL;
=20
@@ -562,6 +563,17 @@ static void *xmalloc_whole_pages(unsigned long size, u=
nsigned long align)
     return res;
 }
=20
+void *_xzalloc_whole_pages(unsigned long size, unsigned long align,
+                           unsigned int memflags)
+{
+    void *p =3D _xmalloc_whole_pages(size, align, memflags);
+
+    if ( p )
+        memset(p, 0, size);
+
+    return p;
+}
+
 static void tlsf_init(void)
 {
     xenpool =3D xmem_pool_create("xmalloc", xmalloc_pool_get,
@@ -628,7 +640,7 @@ void *_xmalloc(unsigned long size, unsigned long align)
     if ( size < PAGE_SIZE )
         p =3D xmem_pool_alloc(size, xenpool);
     if ( p =3D=3D NULL )
-        return xmalloc_whole_pages(size - align + MEM_ALIGN, align);
+        return _xmalloc_whole_pages(size - align + MEM_ALIGN, align, 0);
=20
     /* Add alignment padding. */
     p =3D add_padding(p, align);
diff --git a/xen/include/xen/xmalloc.h b/xen/include/xen/xmalloc.h
index b903fa2e26..3b05e992ef 100644
--- a/xen/include/xen/xmalloc.h
+++ b/xen/include/xen/xmalloc.h
@@ -79,6 +79,10 @@ extern void xfree(void *p);
 extern void *_xmalloc(unsigned long size, unsigned long align);
 extern void *_xzalloc(unsigned long size, unsigned long align);
 extern void *_xrealloc(void *ptr, unsigned long size, unsigned long align)=
;
+extern void *_xmalloc_whole_pages(unsigned long size, unsigned long align,
+                                  unsigned int memflags);
+extern void *_xzalloc_whole_pages(unsigned long size, unsigned long align,
+                                  unsigned int memflags);
=20
 static inline void *_xmalloc_array(
     unsigned long size, unsigned long align, unsigned long num)
--=20
2.34.1


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 13:46:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 13:46:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856725.1269265 (Exim 4.92)
	(envelope-from )
	id 1tM5zf-0004Fj-Hu; Fri, 13 Dec 2024 13:46:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856725.1269265; Fri, 13 Dec 2024 13:46: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 1tM5zf-0004Fc-E9; Fri, 13 Dec 2024 13:46:11 +0000
Received: by outflank-mailman (input) for mailman id 856725;
 Fri, 13 Dec 2024 13:46: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 1tM5ze-0004FW-1w
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 13:46:10 +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 9af8bebc-b958-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 14:46:08 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-5d3f28a4fccso2722437a12.2
 for ; Fri, 13 Dec 2024 05:46:08 -0800 (PST)
Received: from localhost ([217.156.233.154]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d3d0f93d54sm10009063a12.68.2024.12.13.05.46.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 13 Dec 2024 05:46: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: 9af8bebc-b958-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1734097567; x=1734702367; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=aZaGjiDFdfKCuOOiiuffu/nMjDxG6MPP4FdpAqr9SNc=;
        b=QS0zXcLh2KYnAvoRSxpAYL/D53mIKNgfP7gWTwTLJllG6h9xSmK6jgbNVkGfLa9bWR
         LhSbe3/6OkThwdfOYjHaMnAF1UXJhhv5kV2JWj06LUsmNl/kdl9k2054Lb8gphmJCxpk
         MNUQaxZnNe+1AVi8YAp1/Yt4jQrV5oz5xouPg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734097567; x=1734702367;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=aZaGjiDFdfKCuOOiiuffu/nMjDxG6MPP4FdpAqr9SNc=;
        b=MTW8hJvQFG9fZPPEX5r3I8JHVpTk+C61dlSvei2nc0pTHJ9o2hyUb6k4f8TFiHCAuI
         XrjfEitwyhDcAjCf9unUF+TsjunHa9HWb1AXRauVoA0s2P+1qMFysGE662q13NFE6bh1
         qn1DQJ+SgjDp3TckVOyKAAMsU+CUEb4vL/Q8gCsZzNvgJakH6TUfyO04ZW9h14kbwEQr
         FDjV9VIVDjU9IPB8w1TNSVZXVWrK5cbqKxa+E7wQLz0213SrXAlHAe95OwdADGk9IxnT
         NE555oG/0+9IfgCAy70rIYlIHA+VP5PMOCZe1N0Yt/CHEGBVikYgyDclHOJEpVaLIA58
         Sp2g==
X-Forwarded-Encrypted: i=1; AJvYcCVVhbDsooMAOXi2+Gafxv6XLKaprOYPVpV3t7wdaYge3aAjze6do6IHARf8hEPkyygaLt3OIdVhIxA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwHzxG6LSb0njAo50thH7KwRE3crExaWaxyeWU+XsVjE6TQGxsk
	QraO4dHZMpONVTmtsBL5ZOuW0pQXL3jHiVwQ3ypo6oNqgr1NDahfEpiEcx5Sou8=
X-Gm-Gg: ASbGnctxW5aJrDssibhk9WbolPbXvJb4NOprCQCKl88AKv5JirjE2RwIfuAeGN7Ih6/
	Qd0i8+XJNB+T96+waw+UdEd83tAef3+eHTANWudB9S9MXOVwqnIK+2Lbaz4AjUeqL0AGJQQT8bC
	3WfSmjBhWk1J78eEtboIM3Pv9btyM8CPMb0H+JJ7OaO/Xsib02mp0mU8tTj0uW7EgFTkpQufzKi
	JQwZMb63OooeFTFtDxKvCtKgRbG/6o6MhIsv8edyTKEIxWJR03TIldu1t90F3mPxg==
X-Google-Smtp-Source: AGHT+IGlAD7Sru8l3ygJa8G6VFVdhaXx5a2J2czGBUSSUSw9IT66WR2V/W6KZp9d//yhJ+3yTK4JpA==
X-Received: by 2002:a17:907:7fa5:b0:aa6:8a1b:8b78 with SMTP id a640c23a62f3a-aab778c1e9dmr322961266b.6.1734097567534;
        Fri, 13 Dec 2024 05:46:07 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Fri, 13 Dec 2024 13:46:05 +0000
Message-Id: 
Cc: , , , "Hongyan
 Xia" , "Julien Grall" 
Subject: Re: [PATCH V4 10/15] xen/page_alloc: vmap heap nodes when they are
 outside the direct map
From: "Alejandro Vallejo" 
To: "Elias El Yandouzi" ,
 
X-Mailer: aerc 0.18.2
References: <20241111131148.52568-1-eliasely@amazon.com>
 <20241111131148.52568-11-eliasely@amazon.com>
In-Reply-To: <20241111131148.52568-11-eliasely@amazon.com>

Hi,

I'm seeing crashes on NUMA machines, which can be attributed to a bug below=
:

On Mon Nov 11, 2024 at 1:11 PM GMT, Elias El Yandouzi wrote:
> From: Hongyan Xia 
>
> When we do not have a direct map, archs_mfn_in_direct_map() will always
> return false, thus init_node_heap() will allocate xenheap pages from an
> existing node for the metadata of a new node. This means that the
> metadata of a new node is in a different node, slowing down heap
> allocation.
>
> Since we now have early vmap, vmap the metadata locally in the new node.
>
> Signed-off-by: Hongyan Xia 
> Signed-off-by: Julien Grall 
> Signed-off-by: Elias El Yandouzi 
>
> ----
>
>     Changes in v4:
>         * Change type of the parameters to paddr_t
>         * Use clear_domain_page() instead of open-coding it
>
>     Changes in v2:
>         * vmap_contig_pages() was renamed to vmap_contig()
>         * Fix indentation and coding style
>
>     Changes from Hongyan's version:
>         * arch_mfn_in_direct_map() was renamed to
>           arch_mfns_in_direct_map()
>         * Use vmap_contig_pages() rather than __vmap(...).
>         * Add missing include (xen/vmap.h) so it compiles on Arm
>
> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> index 2cef521ad85a..62cdeb5013a3 100644
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -137,6 +137,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> =20
>  #include 
>  #include 
> @@ -606,22 +607,32 @@ static unsigned long init_node_heap(int node, unsig=
ned long mfn,
>          needed =3D 0;
>      }
>      else if ( *use_tail && nr >=3D needed &&
> -              arch_mfns_in_directmap(mfn + nr - needed, needed) &&
>                (!xenheap_bits ||
>                 !((mfn + nr - 1) >> (xenheap_bits - PAGE_SHIFT))) )
>      {
> -        _heap[node] =3D mfn_to_virt(mfn + nr - needed);
> -        avail[node] =3D mfn_to_virt(mfn + nr - 1) +
> -                      PAGE_SIZE - sizeof(**avail) * NR_ZONES;
> +        if ( arch_mfns_in_directmap(mfn + nr - needed, needed) )
> +            _heap[node] =3D mfn_to_virt(mfn + nr - needed);
> +        else
> +            _heap[node] =3D vmap_contig(_mfn(mfn + nr - needed), needed)=
;
> +
> +        BUG_ON(!_heap[node]);
> +        avail[node] =3D (void *)(_heap[node]) + (needed << PAGE_SHIFT) -
> +                        sizeof(**avail) * NR_ZONES;
> +
>      }
>      else if ( nr >=3D needed &&
> -              arch_mfns_in_directmap(mfn, needed) &&
>                (!xenheap_bits ||
> -               !((mfn + needed - 1) >> (xenheap_bits - PAGE_SHIFT))) )
> +              !((mfn + needed - 1) >> (xenheap_bits - PAGE_SHIFT))) )
>      {
> -        _heap[node] =3D mfn_to_virt(mfn);
> -        avail[node] =3D mfn_to_virt(mfn + needed - 1) +
> -                      PAGE_SIZE - sizeof(**avail) * NR_ZONES;
> +        if ( arch_mfns_in_directmap(mfn + nr - needed, needed) )
> +            _heap[node] =3D mfn_to_virt(mfn + nr - needed);
> +        else
> +            _heap[node] =3D vmap_contig(_mfn(mfn + nr - needed), needed)=
;

This isn't quite the same thing, I think it regressed in v4 when acting on
Roger's feedback. It should be:

   if ( arch_mfns_in_directmap(mfn, needed) )
       _heap[node] =3D mfn_to_virt(mfn);
   else
       _heap[node] =3D vmap_contig(_mfn(mfn), needed);

Otherwise `use_tail` serves is unconditionally considered as set. With this
change in place, I can boot on NUMA machines.

> +
> +        BUG_ON(!_heap[node]);
> +        avail[node] =3D (void *)(_heap[node]) + (needed << PAGE_SHIFT) -
> +                        sizeof(**avail) * NR_ZONES;
> +
>          *use_tail =3D false;
>      }
>      else if ( get_order_from_bytes(sizeof(**_heap)) =3D=3D

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 14:02:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 14:02:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856748.1269274 (Exim 4.92)
	(envelope-from )
	id 1tM6F4-0007X3-Lp; Fri, 13 Dec 2024 14:02:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856748.1269274; Fri, 13 Dec 2024 14:02: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 1tM6F4-0007Ww-JG; Fri, 13 Dec 2024 14:02:06 +0000
Received: by outflank-mailman (input) for mailman id 856748;
 Fri, 13 Dec 2024 14:02: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 1tM6F3-0007Wo-Bp
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 14:02:05 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d3915868-b95a-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 15:02:02 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 3CB674EE073D;
 Fri, 13 Dec 2024 15:02:01 +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: d3915868-b95a-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1734098521; bh=klRPZOqneBz5gfO7b441OlTKJoRMkxdw9PnJWpSOFvw=;
	h=Date:From:To:Cc:Subject:Reply-To:In-Reply-To:References:From;
	b=pwflzZJu6TyuBDRpkvpqxveBlgPqWUniEycepnJ/W4rq6jv8FMhoOoWT1tv1Eg44V
	 JpB/9cMU/jZnUrpgX9P0LbMSEwMcp39ha5mEtbcvwQDIXgbvz52tDyrMC9Ioc6em/H
	 k9FB3qEYCkWJ3cHk3QoPjM5WFyV//i+koqQE0crDbrg5q9BqhWVszBzN4nE+Ec8D7d
	 pDBEQUFjTywLvbMyls5ol1sMPYFJcpoxsx1/DlLFtGWZmBOX6HYCxHD0iWuPBRwEo2
	 4rkGCQKa2ecVby9QhbgTQreSL9ZVsx7/XswWPZuvGYMNWj9nIX9Z8ymX+5yGuc668Z
	 VYRm5SlHRAIWA==
MIME-Version: 1.0
Date: Fri, 13 Dec 2024 15:02:01 +0100
From: Alessandro Zucchelli 
To: Jan Beulich 
Cc: Stefano Stabellini , consulting@bugseng.com,
 Julien Grall , Bertrand Marquis ,
 Michal Orzel , Volodymyr Babchuk
 , Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen: address violation of MISRA C Rule 11.1
Reply-To: alessandro.zucchelli@bugseng.com
Mail-Reply-To: alessandro.zucchelli@bugseng.com
In-Reply-To: 
References: <7debd63f3900bad62bcbcc03081e4c04e6099135.1733914487.git.alessandro.zucchelli@bugseng.com>
 
 
 <26600bb0-93af-45b5-a341-5771bad844a1@suse.com>
 
 
Message-ID: <1ddb5bd7e8889da0e978bb1391072925@bugseng.com>
X-Sender: alessandro.zucchelli@bugseng.com
Organization: BUGSENG Srl
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-12-13 11:08, Jan Beulich wrote:
> On 13.12.2024 01:53, Stefano Stabellini wrote:
>> On Thu, 12 Dec 2024, Jan Beulich wrote:
>>> On 12.12.2024 03:27, Stefano Stabellini wrote:
>>>> On Wed, 11 Dec 2024, Jan Beulich wrote:
>>>>> On 11.12.2024 12:02, Alessandro Zucchelli wrote:
>>>>>> Rule 11.1 states as following: "Conversions shall not be performed
>>>>>> between a pointer to a function and any other type".
>>>>>> 
>>>>>> Functions "__machine_restart" and "__machine_halt" in 
>>>>>> "x86/shutdown.c"
>>>>>> and "halt_this_cpu" in "arm/shutdown.c" are defined as noreturn
>>>>>> functions and subsequently passed as parameters to function calls.
>>>>>> This violates the rule in Clang, where the "noreturn" attribute is
>>>>>> considered part of the function"s type.
>>>>> 
>>>>> I'm unaware of build issues with Clang, hence can you clarify how 
>>>>> Clang's
>>>>> view comes into play here? In principle various attributes ought to 
>>>>> be
>>>>> part of a function's type; iirc that's also the case for gcc. Yet 
>>>>> how
>>>>> that matters to Eclair is still entirely unclear to me.
>>>>> 
>>>>>> By removing the "noreturn"
>>>>>> attribbute and replacing it with uses of the ASSERT_UNREACHABLE 
>>>>>> macro,
>>>>>> these violations are addressed.
>>>>> 
>>>>> Papered over, I'd say. What about release builds, for example?
>>>>> 
>>>>> Deleting the attribute also has a clear downside 
>>>>> documentation-wise. If
>>>>> we really mean to remove them from what the compiler gets to see, I 
>>>>> think
>>>>> we ought to still retain them in commented-out shape.
>>>> 
>>>> Another option would be to #define noreturn to nothing for ECLAIR 
>>>> builds ?
>>> 
>>> That again would feel like papering over things. Plus I don't know if 
>>> that's
>>> an option at all.
>> 
>> What is "papering over" and what is a "nice solution" is often up to 
>> the
>> personal opinions.
>> 
>> From my point of view, Alessandro's patch doesn't make the code worse.
>> The ASSERT_UNREACHABLE solution is OK. I do agree with you that it
>> should not be required for us to remove "noreturn", but I don't think 
>> we
>> have used it consistently anyway across the Xen codebase.
>> ASSERT_UNREACHABLE is also a form of documentation that the function
>> does not return.
>> 
>> In conclusion, I think all three options are acceptable:
>> 1) this patch as is
>> 2) this patch plus /* noreturn */ as a comment
>> 3) #define noreturn to nothing just for ECLAIR builds
>> 
>> I don't mind either way, maybe option 2) is the best compromise.
> 
> The variant with least impact on what we currently have (generated code
> wise) is 3), though, which hence would be my preference (well, not 
> exactly
> a preference, but the least bad one).

Another option could be to encapsulate these function pointer casts as 
follows:
#define REMOVE_NORETURN(x) (void(*)(void*))(x)
This approach allows us to retain the noreturn attribute and the 
associated optimizations;
note that the encapsulating macro will need to be deviated then.

-- 
Alessandro Zucchelli, B.Sc.

Software Engineer, BUGSENG (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 14:59:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 14:59:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856765.1269284 (Exim 4.92)
	(envelope-from )
	id 1tM78h-0005nN-Ca; Fri, 13 Dec 2024 14:59:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856765.1269284; Fri, 13 Dec 2024 14:59: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 1tM78h-0005nG-A2; Fri, 13 Dec 2024 14:59:35 +0000
Received: by outflank-mailman (input) for mailman id 856765;
 Fri, 13 Dec 2024 14:59: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 1tM78f-0005nA-Lu
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 14:59:33 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dbaf3b52-b962-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 15:59:31 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-aa69077b93fso272280366b.0
 for ; Fri, 13 Dec 2024 06:59:31 -0800 (PST)
Received: from localhost ([217.156.233.154]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa68f70cc47sm671340666b.123.2024.12.13.06.59.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 13 Dec 2024 06:59: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: dbaf3b52-b962-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1734101971; x=1734706771; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+8FDKQbpBGmim4bWvmV4I2XHERC7FpRhL8bJGk/mvcM=;
        b=KizIyDC9hZycwYoPTC3l0v8JZfJ/0VNjvQprgyEp+nhpn+vsmfx4vcchYKFviznvoY
         pWjfXmRxDz4BgGAtPCOnUsmeY/2RQZYjwtkll2vJhTeBjzbAlYOSp6QCmsL+8CY0hDAq
         fRourpYfUwtJADpyG7VKqZuQwuse9JuytHTDI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734101971; x=1734706771;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=+8FDKQbpBGmim4bWvmV4I2XHERC7FpRhL8bJGk/mvcM=;
        b=SXm1gbc3tLoPHBeuZvp+FB7Pzz1VtwAcYlAtcmkLC5DImbjEXvBkSJemTMaM8NPOnb
         2mxSwxBbSWPlBfBAMfr7AJU0VbfxS7J/sCAJZjAyy82j0R/IurvAjK9TYzW+/acyyJ+t
         ++4yP+Yj1vuULE/g1zgb+xUSPaYYVv/ZH9qm1biRFUkz+eD9B0qTqyq6ibQwa76bWFGN
         nPiH9XxWxod9+WkWzOLwZJNMt3Xq4ZWnjfkRL689CV3u4jC4YLMYOZLauSmBSiZLzQXI
         spCme4FgN4ZWmaxtpxw8VOPhCrh3bW0iC3niItfj1gQTLUQFwfepWMqRR2/f6MLQAcLo
         IpIQ==
X-Forwarded-Encrypted: i=1; AJvYcCWHdXhtNg4vwfH/MpATlI/P8mpL1RIphNtv7PiYNE9JhtKsepBTOB+5Zw1XAfjs7PuJvw6CtN3giis=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwQN2MC2qPKXUhRp8GVM0I4hDqHTtYKeKJUMz+WzMg1nOnpQMnt
	kV9DG3DTbe1h0McuMwP/0/S7QWiRunqtGO1nWKvxLoZAQs0hbEfLINwpzS6LSos=
X-Gm-Gg: ASbGncsSui96jRsp7XYTz0RFCwkKaCR/k3IM3Cv+zljh/wq83+BFD97brhbnUGCQqkr
	h1kVulaL3GNCxxOsVl2wwPtenlvQbcfFt1fSp2d1hFHvK3i2ZO6jXWqK9v9vXlmk+Zn+QX4+UBK
	SCy+VVbMcM9o/714SgvxLQC1hgnxZTv6Xo9afPvTMA99EcRIEBx+c9bGSV1rTnEtEBhguGO6k8M
	t1/7Lz47zUvISwrfa7HOxcseEK8BMvjah0+1AZ/BAVPolJugU2aSTLtNxIYqEvstw==
X-Google-Smtp-Source: AGHT+IGjgOBtANzrdNgxVHbVz25HZtoWoznhpClsOWoBVge6zWGTY3JLSO3N09rNXlS8FBnA1h4+cQ==
X-Received: by 2002:a17:907:2d8f:b0:aa6:b4b3:5923 with SMTP id a640c23a62f3a-aab779c72e4mr345786766b.33.1734101971045;
        Fri, 13 Dec 2024 06:59:31 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Fri, 13 Dec 2024 14:59:28 +0000
Message-Id: 
Cc: , , , "Hongyan
 Xia" , "Julien Grall" 
Subject: Re: [PATCH V4 10/15] xen/page_alloc: vmap heap nodes when they are
 outside the direct map
From: "Alejandro Vallejo" 
To: "Elias El Yandouzi" ,
 
X-Mailer: aerc 0.18.2
References: <20241111131148.52568-1-eliasely@amazon.com>
 <20241111131148.52568-11-eliasely@amazon.com>
In-Reply-To: <20241111131148.52568-11-eliasely@amazon.com>

On Mon Nov 11, 2024 at 1:11 PM GMT, Elias El Yandouzi wrote:
> From: Hongyan Xia 
>
> When we do not have a direct map, archs_mfn_in_direct_map() will always
> return false, thus init_node_heap() will allocate xenheap pages from an
> existing node for the metadata of a new node. This means that the
> metadata of a new node is in a different node, slowing down heap
> allocation.
>
> Since we now have early vmap, vmap the metadata locally in the new node.
>
> Signed-off-by: Hongyan Xia 
> Signed-off-by: Julien Grall 
> Signed-off-by: Elias El Yandouzi 
>
> ----
>
>     Changes in v4:
>         * Change type of the parameters to paddr_t
>         * Use clear_domain_page() instead of open-coding it
>
>     Changes in v2:
>         * vmap_contig_pages() was renamed to vmap_contig()
>         * Fix indentation and coding style
>
>     Changes from Hongyan's version:
>         * arch_mfn_in_direct_map() was renamed to
>           arch_mfns_in_direct_map()
>         * Use vmap_contig_pages() rather than __vmap(...).
>         * Add missing include (xen/vmap.h) so it compiles on Arm
>
> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> index 2cef521ad85a..62cdeb5013a3 100644
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -137,6 +137,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> =20
>  #include 
>  #include 
> @@ -606,22 +607,32 @@ static unsigned long init_node_heap(int node, unsig=
ned long mfn,
>          needed =3D 0;
>      }
>      else if ( *use_tail && nr >=3D needed &&
> -              arch_mfns_in_directmap(mfn + nr - needed, needed) &&
>                (!xenheap_bits ||
>                 !((mfn + nr - 1) >> (xenheap_bits - PAGE_SHIFT))) )
>      {
> -        _heap[node] =3D mfn_to_virt(mfn + nr - needed);
> -        avail[node] =3D mfn_to_virt(mfn + nr - 1) +
> -                      PAGE_SIZE - sizeof(**avail) * NR_ZONES;
> +        if ( arch_mfns_in_directmap(mfn + nr - needed, needed) )
> +            _heap[node] =3D mfn_to_virt(mfn + nr - needed);
> +        else
> +            _heap[node] =3D vmap_contig(_mfn(mfn + nr - needed), needed)=
;

... and looking more carefully, couldn't we simply map_pages_to_xen() on th=
e
directmap using mfn_to_virt() as the target? It's not like the NUMA informa=
tion
is a secret, and even if it was the vmap is no less exposed.

I _GUESS_ this was done with the intent of eventually removing the directma=
p
altogether, but it's probably a lot better to keep it around for things lik=
e
the p2m structures and other global data (like these per-node structures).

> +
> +        BUG_ON(!_heap[node]);
> +        avail[node] =3D (void *)(_heap[node]) + (needed << PAGE_SHIFT) -
> +                        sizeof(**avail) * NR_ZONES;
> +
>      }
>      else if ( nr >=3D needed &&
> -              arch_mfns_in_directmap(mfn, needed) &&
>                (!xenheap_bits ||
> -               !((mfn + needed - 1) >> (xenheap_bits - PAGE_SHIFT))) )
> +              !((mfn + needed - 1) >> (xenheap_bits - PAGE_SHIFT))) )
>      {
> -        _heap[node] =3D mfn_to_virt(mfn);
> -        avail[node] =3D mfn_to_virt(mfn + needed - 1) +
> -                      PAGE_SIZE - sizeof(**avail) * NR_ZONES;
> +        if ( arch_mfns_in_directmap(mfn + nr - needed, needed) )
> +            _heap[node] =3D mfn_to_virt(mfn + nr - needed);
> +        else
> +            _heap[node] =3D vmap_contig(_mfn(mfn + nr - needed), needed)=
;
> +
> +        BUG_ON(!_heap[node]);
> +        avail[node] =3D (void *)(_heap[node]) + (needed << PAGE_SHIFT) -
> +                        sizeof(**avail) * NR_ZONES;
> +
>          *use_tail =3D false;
>      }
>      else if ( get_order_from_bytes(sizeof(**_heap)) =3D=3D

I'm compiling all these fixes/enhancements into a separate branch while tes=
ting
the whole thing.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:24:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:24:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856788.1269295 (Exim 4.92)
	(envelope-from )
	id 1tM8Sp-00006E-FZ; Fri, 13 Dec 2024 16:24:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856788.1269295; Fri, 13 Dec 2024 16:24: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 1tM8Sp-000067-D1; Fri, 13 Dec 2024 16:24:27 +0000
Received: by outflank-mailman (input) for mailman id 856788;
 Fri, 13 Dec 2024 16:24: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 1tM8So-000061-1e
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:24:26 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b76eacb1-b96e-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 17:24:24 +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 4CF631F442;
 Fri, 13 Dec 2024 16:24:24 +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 EDECA137CF;
 Fri, 13 Dec 2024 16:24:23 +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 0ZCqOLdfXGe+SgAAD6G6ig
 (envelope-from ); Fri, 13 Dec 2024 16:24: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: b76eacb1-b96e-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734107064; 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=f/mtRsCqwfRHhr0LElon5TNA7kJIIspcSuOoJQxSx/Y=;
	b=vFnnvd8Fh6DOgUMj5m1ceTkeKQz4SdpTyql7jVYN+wP/m4XUNPkR8B3PbDZVrbIFvUSTxJ
	D0N0heSVLyo/0XN6B1e2Te2rT07RhFQagov92TyiBn0rRNpEWJCylr1tuGmMtNKKBEnVG3
	+x8y9RFlCBpJZyakT1Vwxhoyok5h1Yo=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=vFnnvd8F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734107064; 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=f/mtRsCqwfRHhr0LElon5TNA7kJIIspcSuOoJQxSx/Y=;
	b=vFnnvd8Fh6DOgUMj5m1ceTkeKQz4SdpTyql7jVYN+wP/m4XUNPkR8B3PbDZVrbIFvUSTxJ
	D0N0heSVLyo/0XN6B1e2Te2rT07RhFQagov92TyiBn0rRNpEWJCylr1tuGmMtNKKBEnVG3
	+x8y9RFlCBpJZyakT1Vwxhoyok5h1Yo=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	"Daniel P. Smith" ,
	Samuel Thibault 
Subject: [PATCH v3 0/7] remove libxenctrl usage from xenstored
Date: Fri, 13 Dec 2024 17:24:14 +0100
Message-ID: <20241213162421.16782-1-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4CF631F442
X-Spam-Level: 
X-Spamd-Result: default: False [-3.01 / 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)[];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:mid];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCPT_COUNT_SEVEN(0.00)[11];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	TO_DN_SOME(0.00)[];
	DKIM_TRACE(0.00)[suse.com:+]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -3.01
X-Spam-Flag: NO

Xenstored is using libxenctrl for only one purpose: to get information
about state of domains.

This patch series is removing that dependency by introducing a new
stable interface which can be used by xenstored instead.

There was a RFC series sent out 3 years ago, which I have taken as a
base and by addressing all comments from back then.

The main differences since that RFC series are:

- Instead of introducing an new main hypercall for a stable management
  interface I have just added a new domctl sub-op, as requested in 2021.

- I have added a new library libxenmanage for easy use of the new
  stable hypervisor interface. Main motivation for adding the library
  was the recent attempt to decouple oxenstored from the Xen git tree.
  By using the new library, oxenstored could benefit in the same way as
  xenstored from the new interface: it would be possible to rely on
  stable libraries only.

- Mini-OS has gained some more config options recently, so it was rather
  easy to make xenstore[pvh]-stubdom independent from libxenctrl, too.

- By moving the CPU barrier definitions out of xenctrl.h into a new
  dedicated header xenstored code no longer needs to #include xenctrl.h,
  thus removing any xenctrl reference from xenstored code.

Please note that the last patch can be committed only after the related
Mini-OS patch "config: add support for libxenmanage" has gone in AND
the Mini-OS commit-id has been updated in Config.mk accordingly! The
Mini-OS patch has been Acked already, so it can go in as soon as patch
6 of this series (the one introducing libxenmanage) has been committed.

Changes in V2:
- new patch 1
- former patch 5 mover earlier, now patch 2 (can go in without the rest
  of the series)
- addressed comments

Changes in V3:
- addressed comments

Juergen Gross (7):
  xen/xsm: make getdomaininfo xsm dummy checks more stringent
  tools: add a dedicated header file for barrier definitions
  xen: add a domain unique id to each domain
  xen: add bitmap to indicate per-domain state changes
  xen: add new domctl get_changed_domain
  tools/libs: add a new libxenmanage library
  tools/xenstored: use new stable interface instead of libxenctrl

 stubdom/Makefile                       |   8 +-
 stubdom/mini-os.mk                     |   1 +
 tools/9pfsd/io.c                       |   5 +-
 tools/flask/policy/modules/dom0.te     |   2 +-
 tools/flask/policy/modules/xen.if      |   4 +-
 tools/flask/policy/modules/xenstore.te |   1 +
 tools/include/xen-barrier.h            |  39 ++++++
 tools/include/xenctrl.h                |  28 +----
 tools/include/xenmanage.h              |  92 ++++++++++++++
 tools/libs/Makefile                    |   1 +
 tools/libs/ctrl/Makefile               |   2 +-
 tools/libs/manage/Makefile             |  10 ++
 tools/libs/manage/Makefile.common      |   3 +
 tools/libs/manage/core.c               | 168 +++++++++++++++++++++++++
 tools/libs/manage/libxenmanage.map     |   8 ++
 tools/libs/uselibs.mk                  |   2 +
 tools/xenstored/Makefile               |   2 +-
 tools/xenstored/Makefile.common        |   2 +-
 tools/xenstored/core.h                 |   1 -
 tools/xenstored/domain.c               |  52 +++-----
 tools/xenstored/lu.c                   |   1 +
 tools/xenstored/lu_daemon.c            |   1 +
 xen/common/domain.c                    | 138 ++++++++++++++++++++
 xen/common/domctl.c                    |  20 ++-
 xen/common/event_channel.c             |  14 +++
 xen/common/sysctl.c                    |   2 +-
 xen/include/public/domctl.h            |  26 ++++
 xen/include/xen/sched.h                |   8 ++
 xen/include/xsm/dummy.h                |  10 +-
 xen/include/xsm/xsm.h                  |   6 +
 xen/xsm/dummy.c                        |   1 +
 xen/xsm/flask/hooks.c                  |   7 ++
 xen/xsm/flask/policy/access_vectors    |   2 +
 33 files changed, 591 insertions(+), 76 deletions(-)
 create mode 100644 tools/include/xen-barrier.h
 create mode 100644 tools/include/xenmanage.h
 create mode 100644 tools/libs/manage/Makefile
 create mode 100644 tools/libs/manage/Makefile.common
 create mode 100644 tools/libs/manage/core.c
 create mode 100644 tools/libs/manage/libxenmanage.map

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:24:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:24:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856790.1269315 (Exim 4.92)
	(envelope-from )
	id 1tM8Sz-0000dJ-UN; Fri, 13 Dec 2024 16:24:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856790.1269315; Fri, 13 Dec 2024 16:24:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tM8Sz-0000dC-Qi; Fri, 13 Dec 2024 16:24:37 +0000
Received: by outflank-mailman (input) for mailman id 856790;
 Fri, 13 Dec 2024 16:24: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 1tM8Sy-000061-Hl
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:24:36 +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 be031707-b96e-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 17:24:35 +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 A384B210F3;
 Fri, 13 Dec 2024 16:24:35 +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 72972137CF;
 Fri, 13 Dec 2024 16:24:35 +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 GKBsGsNfXGfXSgAAD6G6ig
 (envelope-from ); Fri, 13 Dec 2024 16:24: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: be031707-b96e-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734107075; 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=M6JXLGZ2C/uRkGXgqKjA/JAonnCDowTlDjW+0Nr5vSE=;
	b=sBBOnfSbOX/5fJ7YZQCDY/xzoSEa+03QAK60gQH6tayTzdSPzkOppBPNjBWMm3ZDl8GbrJ
	fxwjgKdN6p81kDRUPisDnwN8LEueB1wP11FeeuxUCx1nJn2RlFzIvWVUmGSyzZarqizWeh
	dXMoLW4jYtiuW3DBhzGJeifDlUCmWII=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734107075; 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=M6JXLGZ2C/uRkGXgqKjA/JAonnCDowTlDjW+0Nr5vSE=;
	b=sBBOnfSbOX/5fJ7YZQCDY/xzoSEa+03QAK60gQH6tayTzdSPzkOppBPNjBWMm3ZDl8GbrJ
	fxwjgKdN6p81kDRUPisDnwN8LEueB1wP11FeeuxUCx1nJn2RlFzIvWVUmGSyzZarqizWeh
	dXMoLW4jYtiuW3DBhzGJeifDlUCmWII=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Anthony PERARD 
Subject: [PATCH v3 2/7] tools: add a dedicated header file for barrier definitions
Date: Fri, 13 Dec 2024 17:24:16 +0100
Message-ID: <20241213162421.16782-3-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213162421.16782-1-jgross@suse.com>
References: <20241213162421.16782-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.80
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)[-0.998];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Level: 

Instead of having to include xenctrl.h for getting definitions of cpu
barriers, add a dedicated header for that purpose.

Switch the xen-9pfsd daemon to use the new header instead of xenctrl.h.

This is in preparation of making Xenstore independent from libxenctrl.

Signed-off-by: Juergen Gross 
---
V1:
- new patch
V2:
- use SPDX
- modify guard define (Anthony PERARD)
- moved earlier in the series
---
 tools/9pfsd/io.c            |  5 ++++-
 tools/include/xen-barrier.h | 39 +++++++++++++++++++++++++++++++++++++
 tools/include/xenctrl.h     | 28 +-------------------------
 tools/libs/ctrl/Makefile    |  2 +-
 4 files changed, 45 insertions(+), 29 deletions(-)
 create mode 100644 tools/include/xen-barrier.h

diff --git a/tools/9pfsd/io.c b/tools/9pfsd/io.c
index 468e0241f5..14cfcaf568 100644
--- a/tools/9pfsd/io.c
+++ b/tools/9pfsd/io.c
@@ -13,15 +13,18 @@
 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
-#include            /* For cpu barriers. */
+#include 
 #include 
 
 #include "xen-9pfsd.h"
diff --git a/tools/include/xen-barrier.h b/tools/include/xen-barrier.h
new file mode 100644
index 0000000000..a716fb93cc
--- /dev/null
+++ b/tools/include/xen-barrier.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: LGPL-2.1 */
+/******************************************************************************
+ * xen-barrier.h
+ *
+ * Definition of CPU barriers, part of libxenctrl.
+ *
+ * Copyright (c) 2003-2004, K A Fraser.
+ */
+
+#ifndef XEN_BARRIER_H
+#define XEN_BARRIER_H
+
+/*
+ *  DEFINITIONS FOR CPU BARRIERS
+ */
+
+#define xen_barrier() asm volatile ( "" : : : "memory")
+
+#if defined(__i386__)
+#define xen_mb()  asm volatile ( "lock addl $0, -4(%%esp)" ::: "memory" )
+#define xen_rmb() xen_barrier()
+#define xen_wmb() xen_barrier()
+#elif defined(__x86_64__)
+#define xen_mb()  asm volatile ( "lock addl $0, -32(%%rsp)" ::: "memory" )
+#define xen_rmb() xen_barrier()
+#define xen_wmb() xen_barrier()
+#elif defined(__arm__)
+#define xen_mb()   asm volatile ("dmb" : : : "memory")
+#define xen_rmb()  asm volatile ("dmb" : : : "memory")
+#define xen_wmb()  asm volatile ("dmb" : : : "memory")
+#elif defined(__aarch64__)
+#define xen_mb()   asm volatile ("dmb sy" : : : "memory")
+#define xen_rmb()  asm volatile ("dmb sy" : : : "memory")
+#define xen_wmb()  asm volatile ("dmb sy" : : : "memory")
+#else
+#error "Define barriers"
+#endif
+
+#endif /* XEN_BARRIER_H */
diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 29617585c5..ea57e9dbb9 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -48,6 +48,7 @@
 #include 
 
 #include "xentoollog.h"
+#include "xen-barrier.h"
 
 #if defined(__i386__) || defined(__x86_64__)
 #include 
@@ -61,33 +62,6 @@
 
 #define INVALID_MFN  (~0UL)
 
-/*
- *  DEFINITIONS FOR CPU BARRIERS
- */
-
-#define xen_barrier() asm volatile ( "" : : : "memory")
-
-#if defined(__i386__)
-#define xen_mb()  asm volatile ( "lock addl $0, -4(%%esp)" ::: "memory" )
-#define xen_rmb() xen_barrier()
-#define xen_wmb() xen_barrier()
-#elif defined(__x86_64__)
-#define xen_mb()  asm volatile ( "lock addl $0, -32(%%rsp)" ::: "memory" )
-#define xen_rmb() xen_barrier()
-#define xen_wmb() xen_barrier()
-#elif defined(__arm__)
-#define xen_mb()   asm volatile ("dmb" : : : "memory")
-#define xen_rmb()  asm volatile ("dmb" : : : "memory")
-#define xen_wmb()  asm volatile ("dmb" : : : "memory")
-#elif defined(__aarch64__)
-#define xen_mb()   asm volatile ("dmb sy" : : : "memory")
-#define xen_rmb()  asm volatile ("dmb sy" : : : "memory")
-#define xen_wmb()  asm volatile ("dmb sy" : : : "memory")
-#else
-#error "Define barriers"
-#endif
-
-
 #define XENCTRL_HAS_XC_INTERFACE 1
 /* In Xen 4.0 and earlier, xc_interface_open and xc_evtchn_open would
  * both return ints being the file descriptor.  In 4.1 and later, they
diff --git a/tools/libs/ctrl/Makefile b/tools/libs/ctrl/Makefile
index 5fe0bfad0c..acce8639d3 100644
--- a/tools/libs/ctrl/Makefile
+++ b/tools/libs/ctrl/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 include Makefile.common
 
-LIBHEADER := xenctrl.h xenctrl_compat.h
+LIBHEADER := xenctrl.h xenctrl_compat.h xen-barrier.h
 PKG_CONFIG_FILE := xencontrol.pc
 PKG_CONFIG_NAME := Xencontrol
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:24:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:24:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856789.1269305 (Exim 4.92)
	(envelope-from )
	id 1tM8Su-0000M4-Lr; Fri, 13 Dec 2024 16:24:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856789.1269305; Fri, 13 Dec 2024 16:24: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 1tM8Su-0000Lx-Io; Fri, 13 Dec 2024 16:24:32 +0000
Received: by outflank-mailman (input) for mailman id 856789;
 Fri, 13 Dec 2024 16:24: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 1tM8St-000061-0l
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:24:31 +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 bac62228-b96e-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 17:24:30 +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 0E33B1F394;
 Fri, 13 Dec 2024 16:24:30 +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 B0EF2137CF;
 Fri, 13 Dec 2024 16:24:29 +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 ZJy9Kb1fXGfFSgAAD6G6ig
 (envelope-from ); Fri, 13 Dec 2024 16:24: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: bac62228-b96e-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734107070; 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=L2xTCNjOjUSFogDUtL9Ml6AtqorKdQYe/34xDCxxxEg=;
	b=N0WIH8RnI/1mOHjyKiQTlZnM47OIhDo/MKwqVLwsLqpr4sZ8G9Hou564PpjpqRtfxE0z5q
	4tmuGh5OE3F7KKvgetQZoiV8QJWRO8sWyMmgZUj/DJJ3hZ4ps+eMbr/tS59jvaKocRiL52
	6wAMs0KUo7kKAgA3D9bsjw8AQ6H5Vik=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734107070; 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=L2xTCNjOjUSFogDUtL9Ml6AtqorKdQYe/34xDCxxxEg=;
	b=N0WIH8RnI/1mOHjyKiQTlZnM47OIhDo/MKwqVLwsLqpr4sZ8G9Hou564PpjpqRtfxE0z5q
	4tmuGh5OE3F7KKvgetQZoiV8QJWRO8sWyMmgZUj/DJJ3hZ4ps+eMbr/tS59jvaKocRiL52
	6wAMs0KUo7kKAgA3D9bsjw8AQ6H5Vik=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	"Daniel P. Smith" 
Subject: [PATCH v3 1/7] xen/xsm: make getdomaininfo xsm dummy checks more stringent
Date: Fri, 13 Dec 2024 17:24:15 +0100
Message-ID: <20241213162421.16782-2-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213162421.16782-1-jgross@suse.com>
References: <20241213162421.16782-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.80
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-0.998];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCVD_TLS_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[10];
	RCVD_COUNT_TWO(0.00)[2];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email]
X-Spam-Flag: NO
X-Spam-Level: 

Today the dummy XSM privilege checks for getdomaininfo are less
stringent than possible: they basically rely on the general
sysctl/domctl entry check to do all tests and then do the test with
the XSM_HOOK privilege, which is an "allow all" default.

Instead of XSM_HOOK use XSM_XS_PRIV, which is the privilege really
wanted. Note that this test is still wider than the sysctl entry test,
but there is no easy way to make both domctl and sysctl happy at the
same time.

Signed-off-by: Juergen Gross 
Acked-by: Daniel P. Smith 
---
V2:
- new patch
---
 xen/common/domctl.c     | 2 +-
 xen/common/sysctl.c     | 2 +-
 xen/include/xsm/dummy.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index ea16b75910..444e072fdc 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -539,7 +539,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         break;
 
     case XEN_DOMCTL_getdomaininfo:
-        ret = xsm_getdomaininfo(XSM_HOOK, d);
+        ret = xsm_getdomaininfo(XSM_XS_PRIV, d);
         if ( ret )
             break;
 
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index d02f44fe3a..c2d99ae12e 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -89,7 +89,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
             if ( num_domains == op->u.getdomaininfolist.max_domains )
                 break;
 
-            if ( xsm_getdomaininfo(XSM_HOOK, d) )
+            if ( xsm_getdomaininfo(XSM_XS_PRIV, d) )
                 continue;
 
             getdomaininfo(d, &info);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 7956f27a29..f8a3c4b81e 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -137,7 +137,7 @@ static XSM_INLINE int cf_check xsm_domain_create(
 static XSM_INLINE int cf_check xsm_getdomaininfo(
     XSM_DEFAULT_ARG struct domain *d)
 {
-    XSM_ASSERT_ACTION(XSM_HOOK);
+    XSM_ASSERT_ACTION(XSM_XS_PRIV);
     return xsm_default_action(action, current->domain, d);
 }
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:24:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:24:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856794.1269324 (Exim 4.92)
	(envelope-from )
	id 1tM8T7-0000z8-40; Fri, 13 Dec 2024 16:24:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856794.1269324; Fri, 13 Dec 2024 16:24: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 1tM8T7-0000z1-12; Fri, 13 Dec 2024 16:24:45 +0000
Received: by outflank-mailman (input) for mailman id 856794;
 Fri, 13 Dec 2024 16:24: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 1tM8T5-0000xX-NZ
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:24:43 +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 c187d92a-b96e-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 17:24:41 +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 579D7210F3;
 Fri, 13 Dec 2024 16:24:41 +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 076D5137CF;
 Fri, 13 Dec 2024 16:24:41 +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 7JlcAMlfXGfeSgAAD6G6ig
 (envelope-from ); Fri, 13 Dec 2024 16:24: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: c187d92a-b96e-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734107081; 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=FGgbqx71ndv5sBTrCP7+ufVgCN8ZAPJccnfCSLfUpqw=;
	b=eM6rf3u27YOalVv5txi5KAH1V1xP8mlB20hvM1oxCyDIN0kYx5pTxBrAule9uaED4jc39z
	aTRosPlMWFhLaZmZAfFrQRQhHu2OqEwPulNW345n2s4TTurBYyt1KzWU7B63IzoS316Aw4
	6orjGc+vx5dhO9pKzK9j6rKvmKw0Xtc=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734107081; 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=FGgbqx71ndv5sBTrCP7+ufVgCN8ZAPJccnfCSLfUpqw=;
	b=eM6rf3u27YOalVv5txi5KAH1V1xP8mlB20hvM1oxCyDIN0kYx5pTxBrAule9uaED4jc39z
	aTRosPlMWFhLaZmZAfFrQRQhHu2OqEwPulNW345n2s4TTurBYyt1KzWU7B63IzoS316Aw4
	6orjGc+vx5dhO9pKzK9j6rKvmKw0Xtc=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Alejandro Vallejo 
Subject: [PATCH v3 3/7] xen: add a domain unique id to each domain
Date: Fri, 13 Dec 2024 17:24:17 +0100
Message-ID: <20241213162421.16782-4-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213162421.16782-1-jgross@suse.com>
References: <20241213162421.16782-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.80
X-Spamd-Result: default: False [-2.80 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_SEVEN(0.00)[10];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Level: 

Xenstore is referencing domains by their domid, but reuse of a domid
can lead to the situation that Xenstore can't tell whether a domain
with that domid has been deleted and created again without Xenstore
noticing the domain is a new one now.

Add a global domain creation unique id which is updated when creating
a new domain, and store that value in struct domain of the new domain.
The global unique id is initialized with the system time and updates
are done via the xorshift algorithm which is used for pseudo random
number generation, too (see https://en.wikipedia.org/wiki/Xorshift).

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
Reviewed-by: Alejandro Vallejo 
---
V1:
- make unique_id local to function (Jan Beulich)
- add lock (Julien Grall)
- add comment (Julien Grall)
V2:
- move reading unique_id into locked section (Julien Grall)
- add comment (Alejandro Vallejo)
---
 xen/common/domain.c     | 27 +++++++++++++++++++++++++++
 xen/include/xen/sched.h |  3 +++
 2 files changed, 30 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 92263a4fbd..e33a0a5a21 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -562,6 +562,32 @@ static void _domain_destroy(struct domain *d)
     free_domain_struct(d);
 }
 
+static uint64_t get_unique_id(void)
+{
+    static uint64_t unique_id;
+    static DEFINE_SPINLOCK(lock);
+    uint64_t x;
+
+    spin_lock(&lock);
+
+    x = unique_id ? : NOW();
+
+    /*
+     * Pseudo-randomize id in order to avoid consumers relying on sequence.
+     * Randomization algorithm has a period of 2^64 - 1.
+     * Unique id is not repeatable between resets and each id has the same
+     * lifetime as the domain it is associated with.
+     */
+    x ^= x << 13;
+    x ^= x >> 7;
+    x ^= x << 17;
+    unique_id = x;
+
+    spin_unlock(&lock);
+
+    return x;
+}
+
 static int sanitise_domain_config(struct xen_domctl_createdomain *config)
 {
     bool hvm = config->flags & XEN_DOMCTL_CDF_hvm;
@@ -654,6 +680,7 @@ struct domain *domain_create(domid_t domid,
 
     /* Sort out our idea of is_system_domain(). */
     d->domain_id = domid;
+    d->unique_id = get_unique_id();
 
     /* Holding CDF_* internal flags. */
     d->cdf = flags;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 76e39378b3..711668e028 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -370,6 +370,9 @@ struct domain
     domid_t          domain_id;
 
     unsigned int     max_vcpus;
+
+    uint64_t         unique_id;       /* Unique domain identifier */
+
     struct vcpu    **vcpu;
 
     shared_info_t   *shared_info;     /* shared data area */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:24:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:24:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856798.1269335 (Exim 4.92)
	(envelope-from )
	id 1tM8TC-0001PR-I0; Fri, 13 Dec 2024 16:24:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856798.1269335; Fri, 13 Dec 2024 16:24:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tM8TC-0001PG-DX; Fri, 13 Dec 2024 16:24:50 +0000
Received: by outflank-mailman (input) for mailman id 856798;
 Fri, 13 Dec 2024 16:24: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 1tM8TA-0000xX-VS
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:24:48 +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 c4d6d722-b96e-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 17:24:47 +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 03CF2210F4;
 Fri, 13 Dec 2024 16:24: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 B1FCE137CF;
 Fri, 13 Dec 2024 16:24:46 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id Qof+Kc5fXGfmSgAAD6G6ig
 (envelope-from ); Fri, 13 Dec 2024 16:24: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: c4d6d722-b96e-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734107087; 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=/m9NTpFMMv/H9wqTamSGbL2GCo3Y1K03xNFyvwN3i/A=;
	b=dny9APKxnCJLhV8Z01uTH0qLdJejWLl5wBCcBDxNT7e5R+zDssG2ZwMYI30Elh9ijHIZjQ
	NaZUoZcJQeAURUntCgEpxkpDOb0+u5+Yp/BHpy8dnewjy0c22ztWAWgJ2Bvm5trir5oq8v
	I5xDGbk2XhwmxsuYFBzqPWFsyWq/OOk=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734107087; 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=/m9NTpFMMv/H9wqTamSGbL2GCo3Y1K03xNFyvwN3i/A=;
	b=dny9APKxnCJLhV8Z01uTH0qLdJejWLl5wBCcBDxNT7e5R+zDssG2ZwMYI30Elh9ijHIZjQ
	NaZUoZcJQeAURUntCgEpxkpDOb0+u5+Yp/BHpy8dnewjy0c22ztWAWgJ2Bvm5trir5oq8v
	I5xDGbk2XhwmxsuYFBzqPWFsyWq/OOk=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 4/7] xen: add bitmap to indicate per-domain state changes
Date: Fri, 13 Dec 2024 17:24:18 +0100
Message-ID: <20241213162421.16782-5-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213162421.16782-1-jgross@suse.com>
References: <20241213162421.16782-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
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)[-0.998];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_SEVEN(0.00)[9];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Score: -2.80
X-Spam-Flag: NO

Add a bitmap with one bit per possible domid indicating the respective
domain has changed its state (created, deleted, dying, crashed,
shutdown).

Registering the VIRQ_DOM_EXC event will result in setting the bits for
all existing domains and resetting all other bits.

As the usage of this bitmap is tightly coupled with the VIRQ_DOM_EXC
event, it is meant to be used only by a single consumer in the system,
just like the VIRQ_DOM_EXC event.

Resetting a bit will be done in a future patch.

This information is needed for Xenstore to keep track of all domains.

Signed-off-by: Juergen Gross 
---
V2:
- use DOMID_FIRST_RESERVED instead of DOMID_MASK + 1 (Jan Beulich)
- use const (Jan Beulich)
- move call of domain_reset_states() into evtchn_bind_virq() (Jan Beulich)
- dynamically allocate dom_state_changed bitmap (Jan Beulich)
V3:
- use xvzalloc_array() (Jan Beulich)
- don't rename existing label (Jan Beulich)
---
 xen/common/domain.c        | 60 ++++++++++++++++++++++++++++++++++++++
 xen/common/event_channel.c | 14 +++++++++
 xen/include/xen/sched.h    |  3 ++
 3 files changed, 77 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index e33a0a5a21..dab2344ef6 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -138,6 +139,60 @@ bool __read_mostly vmtrace_available;
 
 bool __read_mostly vpmu_is_available;
 
+static DEFINE_SPINLOCK(dom_state_changed_lock);
+static unsigned long *dom_state_changed;
+
+int domain_init_states(void)
+{
+    const struct domain *d;
+    int rc = -ENOMEM;
+
+    spin_lock(&dom_state_changed_lock);
+
+    if ( dom_state_changed )
+        bitmap_zero(dom_state_changed, DOMID_FIRST_RESERVED);
+    else
+    {
+        dom_state_changed = xvzalloc_array(unsigned long,
+                                           BITS_TO_LONGS(DOMID_FIRST_RESERVED));
+        if ( !dom_state_changed )
+            goto unlock;
+    }
+
+    rcu_read_lock(&domlist_read_lock);
+
+    for_each_domain ( d )
+        set_bit(d->domain_id, dom_state_changed);
+
+    rcu_read_unlock(&domlist_read_lock);
+
+    rc = 0;
+
+ unlock:
+    spin_unlock(&dom_state_changed_lock);
+
+    return rc;
+}
+
+void domain_deinit_states(void)
+{
+    spin_lock(&dom_state_changed_lock);
+
+    XVFREE(dom_state_changed);
+
+    spin_unlock(&dom_state_changed_lock);
+}
+
+static void domain_changed_state(const struct domain *d)
+{
+    spin_lock(&dom_state_changed_lock);
+
+    if ( dom_state_changed )
+        set_bit(d->domain_id, dom_state_changed);
+
+    spin_unlock(&dom_state_changed_lock);
+}
+
 static void __domain_finalise_shutdown(struct domain *d)
 {
     struct vcpu *v;
@@ -152,6 +207,7 @@ static void __domain_finalise_shutdown(struct domain *d)
             return;
 
     d->is_shut_down = 1;
+    domain_changed_state(d);
     if ( (d->shutdown_code == SHUTDOWN_suspend) && d->suspend_evtchn )
         evtchn_send(d, d->suspend_evtchn);
     else
@@ -839,6 +895,7 @@ struct domain *domain_create(domid_t domid,
      */
     domlist_insert(d);
 
+    domain_changed_state(d);
     memcpy(d->handle, config->handle, sizeof(d->handle));
 
     return d;
@@ -1104,6 +1161,7 @@ int domain_kill(struct domain *d)
         /* Mem event cleanup has to go here because the rings 
          * have to be put before we call put_domain. */
         vm_event_cleanup(d);
+        domain_changed_state(d);
         put_domain(d);
         send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
@@ -1293,6 +1351,8 @@ static void cf_check complete_domain_destroy(struct rcu_head *head)
 
     xfree(d->vcpu);
 
+    domain_changed_state(d);
+
     _domain_destroy(d);
 
     send_global_virq(VIRQ_DOM_EXC);
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 8db2ca4ba2..d18a756217 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -485,6 +485,13 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
     if ( (v = domain_vcpu(d, vcpu)) == NULL )
         return -ENOENT;
 
+    if ( virq == VIRQ_DOM_EXC )
+    {
+        rc = domain_init_states();
+        if ( rc )
+            goto deinit;
+    }
+
     write_lock(&d->event_lock);
 
     if ( read_atomic(&v->virq_to_evtchn[virq]) )
@@ -527,6 +534,10 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
  out:
     write_unlock(&d->event_lock);
 
+ deinit:
+    if ( rc )
+        domain_deinit_states();
+
     return rc;
 }
 
@@ -730,6 +741,9 @@ int evtchn_close(struct domain *d1, int port1, bool guest)
         struct vcpu *v;
         unsigned long flags;
 
+        if ( chn1->u.virq == VIRQ_DOM_EXC )
+            domain_deinit_states();
+
         v = d1->vcpu[virq_is_global(chn1->u.virq) ? 0 : chn1->notify_vcpu_id];
 
         write_lock_irqsave(&v->virq_lock, flags);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 711668e028..16684bbaf9 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -800,6 +800,9 @@ void domain_resume(struct domain *d);
 
 int domain_soft_reset(struct domain *d, bool resuming);
 
+int domain_init_states(void);
+void domain_deinit_states(void);
+
 int vcpu_start_shutdown_deferral(struct vcpu *v);
 void vcpu_end_shutdown_deferral(struct vcpu *v);
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:24:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:24:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856806.1269345 (Exim 4.92)
	(envelope-from )
	id 1tM8TG-0001qQ-O8; Fri, 13 Dec 2024 16:24:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856806.1269345; Fri, 13 Dec 2024 16:24: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 1tM8TG-0001qJ-Jn; Fri, 13 Dec 2024 16:24:54 +0000
Received: by outflank-mailman (input) for mailman id 856806;
 Fri, 13 Dec 2024 16:24: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 1tM8TF-000061-Ok
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:24:53 +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 c831d7d6-b96e-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 17:24:53 +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 B0F6A210F3;
 Fri, 13 Dec 2024 16:24:52 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 602CB137CF;
 Fri, 13 Dec 2024 16:24:52 +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 vpfzFdRfXGfuSgAAD6G6ig
 (envelope-from ); Fri, 13 Dec 2024 16:24: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: c831d7d6-b96e-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734107092; 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=TzV+3QWUfmO/vSj/Xvj3rTStuZE3waoFjw1OBy9Z1yc=;
	b=PdXQmvXU8a9xFYcCw5lomarMcK4kOXnCokscv6BAVIIMAzIATJ1VOqP65kZVAoOYJTASfe
	I/J/zheQFN2XTLtHGZQiqzUFY2Z/79NwRvtqGLmDmSRyASkdDYvdH9L0PoCrY8DHeMollT
	E1qw8OZFP6zMnNT42AanfMdW3S4gVpk=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734107092; 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=TzV+3QWUfmO/vSj/Xvj3rTStuZE3waoFjw1OBy9Z1yc=;
	b=PdXQmvXU8a9xFYcCw5lomarMcK4kOXnCokscv6BAVIIMAzIATJ1VOqP65kZVAoOYJTASfe
	I/J/zheQFN2XTLtHGZQiqzUFY2Z/79NwRvtqGLmDmSRyASkdDYvdH9L0PoCrY8DHeMollT
	E1qw8OZFP6zMnNT42AanfMdW3S4gVpk=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	"Daniel P. Smith" ,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 5/7] xen: add new domctl get_changed_domain
Date: Fri, 13 Dec 2024 17:24:19 +0100
Message-ID: <20241213162421.16782-6-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213162421.16782-1-jgross@suse.com>
References: <20241213162421.16782-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
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)[-0.998];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[10];
	TO_DN_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	R_RATELIMIT(0.00)[to_ip_from(RLme6mccyyenyxxgt1bwti8hnf)];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Score: -2.80
X-Spam-Flag: NO

Add a new domctl sub-function to get data of a domain having changed
state (this is needed by Xenstore).

The returned state just contains the domid, the domain unique id,
and some flags (existing, shutdown, dying).

In order to enable Xenstore stubdom being built for multiple Xen
versions, make this domctl stable.  For stable domctls the
interface_version is always 0.

Signed-off-by: Juergen Gross 
---
V1:
- use a domctl subop for the new interface (Jan Beulich)
V2:
- fix XSM hooks (Daniel P. Smith)
- remove versioning of stable sub-ops (Jan Beulich)
- use domctl.domain for retuning domid of a changed domain (Jan Beulich)
- simplify locking in get_domain_state() (Jan Beulich)
- undo stray change in event_channel.c (Jan Beulich)
V3:
- have disjunct states "dying" and "dead" (Jan Beulich)
- check padding fields to be 0 (Jan Beulich)
- drop memset() (Jan Beulich)
---
 tools/flask/policy/modules/dom0.te     |  2 +-
 tools/flask/policy/modules/xen.if      |  4 +-
 tools/flask/policy/modules/xenstore.te |  1 +
 xen/common/domain.c                    | 51 ++++++++++++++++++++++++++
 xen/common/domctl.c                    | 18 ++++++++-
 xen/include/public/domctl.h            | 26 +++++++++++++
 xen/include/xen/sched.h                |  2 +
 xen/include/xsm/dummy.h                |  8 ++++
 xen/include/xsm/xsm.h                  |  6 +++
 xen/xsm/dummy.c                        |  1 +
 xen/xsm/flask/hooks.c                  |  7 ++++
 xen/xsm/flask/policy/access_vectors    |  2 +
 12 files changed, 124 insertions(+), 4 deletions(-)

diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
index 16b8c9646d..6043c01b12 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -40,7 +40,7 @@ allow dom0_t dom0_t:domain {
 };
 allow dom0_t dom0_t:domain2 {
 	set_cpu_policy gettsc settsc setscheduler set_vnumainfo
-	get_vnumainfo psr_cmt_op psr_alloc get_cpu_policy
+	get_vnumainfo psr_cmt_op psr_alloc get_cpu_policy get_domain_state
 };
 allow dom0_t dom0_t:resource { add remove };
 
diff --git a/tools/flask/policy/modules/xen.if b/tools/flask/policy/modules/xen.if
index 11c1562aa5..2e06f3ed94 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -54,7 +54,7 @@ define(`create_domain_common', `
 	allow $1 $2:domain2 { set_cpu_policy settsc setscheduler setclaim
 			set_vnumainfo get_vnumainfo cacheflush
 			psr_cmt_op psr_alloc soft_reset
-			resource_map get_cpu_policy };
+			resource_map get_cpu_policy get_domain_state };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
@@ -94,7 +94,7 @@ define(`manage_domain', `
 			getaddrsize pause unpause trigger shutdown destroy
 			setaffinity setdomainmaxmem getscheduler resume
 			setpodtarget getpodtarget getpagingmempool setpagingmempool };
-    allow $1 $2:domain2 set_vnumainfo;
+    allow $1 $2:domain2 { set_vnumainfo get_domain_state };
 ')
 
 # migrate_domain_out(priv, target)
diff --git a/tools/flask/policy/modules/xenstore.te b/tools/flask/policy/modules/xenstore.te
index 519566ab81..49de53ebe2 100644
--- a/tools/flask/policy/modules/xenstore.te
+++ b/tools/flask/policy/modules/xenstore.te
@@ -13,6 +13,7 @@ allow dom0_t xenstore_t:domain set_virq_handler;
 allow xenstore_t xen_t:xen writeconsole;
 # Xenstore queries domaininfo on all domains
 allow xenstore_t domain_type:domain getdomaininfo;
+allow xenstore_t domain_type:domain2 get_domain_state;
 
 # As a shortcut, the following 3 rules are used instead of adding a domain_comms
 # rule between xenstore_t and every domain type that talks to xenstore
diff --git a/xen/common/domain.c b/xen/common/domain.c
index dab2344ef6..0073a1f445 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -193,6 +193,57 @@ static void domain_changed_state(const struct domain *d)
     spin_unlock(&dom_state_changed_lock);
 }
 
+static void set_domain_state_info(struct xen_domctl_get_domain_state *info,
+                                  const struct domain *d)
+{
+    info->state = XEN_DOMCTL_GETDOMSTATE_STATE_EXIST;
+    if ( d->is_shut_down )
+        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN;
+    if ( d->is_dying == DOMDYING_dying )
+        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DYING;
+    if ( d->is_dying == DOMDYING_dead )
+        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DEAD;
+    info->unique_id = d->unique_id;
+}
+
+int get_domain_state(struct xen_domctl_get_domain_state *info, struct domain *d,
+                     domid_t *domid)
+{
+    unsigned int dom;
+
+    if ( info->pad0 || info->pad1 )
+        return -EINVAL;
+
+    if ( d )
+    {
+        set_domain_state_info(info, d);
+
+        return 0;
+    }
+
+    while ( (dom = find_first_bit(dom_state_changed, DOMID_MASK + 1)) <
+            DOMID_FIRST_RESERVED )
+    {
+        if ( test_and_clear_bit(dom, dom_state_changed) )
+        {
+            *domid = dom;
+
+            d = rcu_lock_domain_by_id(dom);
+
+            if ( d )
+            {
+                set_domain_state_info(info, d);
+
+                rcu_unlock_domain(d);
+            }
+
+            return 0;
+        }
+    }
+
+    return -ENOENT;
+}
+
 static void __domain_finalise_shutdown(struct domain *d)
 {
     struct vcpu *v;
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 444e072fdc..802bd7596e 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -278,6 +278,11 @@ static struct vnuma_info *vnuma_init(const struct xen_domctl_vnuma *uinfo,
     return ERR_PTR(ret);
 }
 
+static bool is_stable_domctl(uint32_t cmd)
+{
+    return cmd == XEN_DOMCTL_get_domain_state;
+}
+
 long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 {
     long ret = 0;
@@ -288,7 +293,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     if ( copy_from_guest(op, u_domctl, 1) )
         return -EFAULT;
 
-    if ( op->interface_version != XEN_DOMCTL_INTERFACE_VERSION )
+    if ( op->interface_version !=
+         (is_stable_domctl(op->cmd) ? 0 : XEN_DOMCTL_INTERFACE_VERSION) )
         return -EACCES;
 
     switch ( op->cmd )
@@ -309,6 +315,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         fallthrough;
     case XEN_DOMCTL_test_assign_device:
     case XEN_DOMCTL_vm_event_op:
+    case XEN_DOMCTL_get_domain_state:
         if ( op->domain == DOMID_INVALID )
         {
             d = NULL;
@@ -866,6 +873,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
                 __HYPERVISOR_domctl, "h", u_domctl);
         break;
 
+    case XEN_DOMCTL_get_domain_state:
+        ret = xsm_get_domain_state(XSM_XS_PRIV, d);
+        if ( ret )
+            break;
+
+        copyback = 1;
+        ret = get_domain_state(&op->u.get_domain_state, d, &op->domain);
+        break;
+
     default:
         ret = arch_do_domctl(op, d, u_domctl);
         break;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 353f831e40..13fe17ab0a 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -28,6 +28,7 @@
  * Pure additions (e.g. new sub-commands) or compatible interface changes
  * (e.g. adding semantics to 0-checked input fields or data to zeroed output
  * fields) don't require a change of the version.
+ * Stable ops are NOT covered by XEN_DOMCTL_INTERFACE_VERSION!
  *
  * Last version bump: Xen 4.19
  */
@@ -1236,7 +1237,30 @@ struct xen_domctl_dt_overlay {
 };
 #endif
 
+/*
+ * XEN_DOMCTL_get_domain_state (stable interface)
+ *
+ * Get state information of a domain.
+ *
+ * In case domain is DOMID_INVALID, return information about a domain having
+ * changed state and reset the state change indicator for that domain. This
+ * function is usable only by a domain having registered the VIRQ_DOM_EXC
+ * event (normally Xenstore).
+ * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
+ */
+struct xen_domctl_get_domain_state {
+    uint16_t state;
+#define XEN_DOMCTL_GETDOMSTATE_STATE_EXIST     0x0001  /* Domain is existing. */
+#define XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN  0x0002  /* Shutdown finished. */
+#define XEN_DOMCTL_GETDOMSTATE_STATE_DYING     0x0004  /* Domain dying. */
+#define XEN_DOMCTL_GETDOMSTATE_STATE_DEAD      0x0008  /* Domain dead. */
+    uint16_t pad0;           /* Must be 0 on input, returned as 0. */
+    uint32_t pad1;           /* Must be 0 on input, returned as 0. */
+    uint64_t unique_id;      /* Unique domain identifier. */
+};
+
 struct xen_domctl {
+/* Stable domctl ops: interface_version is required to be 0.  */
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
 #define XEN_DOMCTL_destroydomain                  2
@@ -1325,6 +1349,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_set_paging_mempool_size       86
 #define XEN_DOMCTL_dt_overlay                    87
 #define XEN_DOMCTL_gsi_permission                88
+#define XEN_DOMCTL_get_domain_state              89 /* stable interface */
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1391,6 +1416,7 @@ struct xen_domctl {
 #if defined(__arm__) || defined(__aarch64__)
         struct xen_domctl_dt_overlay        dt_overlay;
 #endif
+        struct xen_domctl_get_domain_state  get_domain_state;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 16684bbaf9..5e9858c3ba 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -802,6 +802,8 @@ int domain_soft_reset(struct domain *d, bool resuming);
 
 int domain_init_states(void);
 void domain_deinit_states(void);
+int get_domain_state(struct xen_domctl_get_domain_state *info,
+                     struct domain *d, domid_t *domid);
 
 int vcpu_start_shutdown_deferral(struct vcpu *v);
 void vcpu_end_shutdown_deferral(struct vcpu *v);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index f8a3c4b81e..a1a5bb60e9 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -173,6 +173,7 @@ static XSM_INLINE int cf_check xsm_domctl(
     case XEN_DOMCTL_unbind_pt_irq:
         return xsm_default_action(XSM_DM_PRIV, current->domain, d);
     case XEN_DOMCTL_getdomaininfo:
+    case XEN_DOMCTL_get_domain_state:
         return xsm_default_action(XSM_XS_PRIV, current->domain, d);
     default:
         return xsm_default_action(XSM_PRIV, current->domain, d);
@@ -815,6 +816,13 @@ static XSM_INLINE int cf_check xsm_argo_send(
 
 #endif /* CONFIG_ARGO */
 
+static XSM_INLINE int cf_check xsm_get_domain_state(
+    XSM_DEFAULT_ARG struct domain *d)
+{
+    XSM_ASSERT_ACTION(XSM_XS_PRIV);
+    return xsm_default_action(action, current->domain, d);
+}
+
 #include 
 static XSM_INLINE int cf_check xsm_xen_version(XSM_DEFAULT_ARG uint32_t op)
 {
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 4dbff9d866..0689bf5c9f 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -200,6 +200,7 @@ struct xsm_ops {
     int (*argo_register_any_source)(const struct domain *d);
     int (*argo_send)(const struct domain *d, const struct domain *t);
 #endif
+    int (*get_domain_state)(struct domain *d);
 };
 
 #ifdef CONFIG_XSM
@@ -774,6 +775,11 @@ static inline int xsm_argo_send(const struct domain *d, const struct domain *t)
 
 #endif /* CONFIG_ARGO */
 
+static inline int xsm_get_domain_state(struct domain *d)
+{
+    return alternative_call(xsm_ops.get_domain_state, d);
+}
+
 #endif /* XSM_NO_WRAPPERS */
 
 #ifdef CONFIG_MULTIBOOT
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index e6ffa948f7..ce6fbdc6c5 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -148,6 +148,7 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .argo_register_any_source      = xsm_argo_register_any_source,
     .argo_send                     = xsm_argo_send,
 #endif
+    .get_domain_state              = xsm_get_domain_state,
 };
 
 void __init xsm_fixup_ops(struct xsm_ops *ops)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a79474ffe4..e110846ad9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -688,6 +688,7 @@ static int cf_check flask_domctl(struct domain *d, unsigned int cmd,
     case XEN_DOMCTL_memory_mapping:
     case XEN_DOMCTL_set_target:
     case XEN_DOMCTL_vm_event_op:
+    case XEN_DOMCTL_get_domain_state:
 
     /* These have individual XSM hooks (arch/../domctl.c) */
     case XEN_DOMCTL_bind_pt_irq:
@@ -1856,6 +1857,11 @@ static int cf_check flask_argo_send(
 
 #endif
 
+static int cf_check flask_get_domain_state(struct domain *d)
+{
+    return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GET_DOMAIN_STATE);
+}
+
 static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .set_system_active = flask_set_system_active,
     .security_domaininfo = flask_security_domaininfo,
@@ -1992,6 +1998,7 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .argo_register_any_source = flask_argo_register_any_source,
     .argo_send = flask_argo_send,
 #endif
+    .get_domain_state = flask_get_domain_state,
 };
 
 const struct xsm_ops *__init flask_init(
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index a35e3d4c51..c9a8eeda4e 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -251,6 +251,8 @@ class domain2
     resource_map
 # XEN_DOMCTL_get_cpu_policy
     get_cpu_policy
+# XEN_DOMCTL_get_domain_state
+    get_domain_state
 }
 
 # Similar to class domain, but primarily contains domctls related to HVM domains
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:25:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:25:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856818.1269355 (Exim 4.92)
	(envelope-from )
	id 1tM8TO-0002Uf-Vu; Fri, 13 Dec 2024 16:25:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856818.1269355; Fri, 13 Dec 2024 16:25: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 1tM8TO-0002UY-Sk; Fri, 13 Dec 2024 16:25:02 +0000
Received: by outflank-mailman (input) for mailman id 856818;
 Fri, 13 Dec 2024 16:25: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 1tM8TN-0000xX-84
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:25:01 +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 cba91b08-b96e-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 17:24:58 +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 41C54210F3;
 Fri, 13 Dec 2024 16:24:58 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 1C95A137CF;
 Fri, 13 Dec 2024 16:24:58 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id IQ2LBdpfXGf1SgAAD6G6ig
 (envelope-from ); Fri, 13 Dec 2024 16:24: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: cba91b08-b96e-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734107098; 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=rbVDjEcqqAdiVmzEYfAl6rmQ+S/MNPFNQOY9L1rY84I=;
	b=r37vAnbDx5G+zPbik8fdOiHLNVd6P907+OhciNvXjOxeTl6dl5CtC43mX+SKjN+q/1EBb1
	pL0SIRj3QDa8T4nfeeHF3XYrX7+GLET2RG+azAKGvTLLDX0c7HCGwaNpuzvc5lvk606WK4
	ueFKCUEtDradcJ2OHXWBmKE0YsTk9c4=
Authentication-Results: smtp-out1.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=r37vAnbD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734107098; 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=rbVDjEcqqAdiVmzEYfAl6rmQ+S/MNPFNQOY9L1rY84I=;
	b=r37vAnbDx5G+zPbik8fdOiHLNVd6P907+OhciNvXjOxeTl6dl5CtC43mX+SKjN+q/1EBb1
	pL0SIRj3QDa8T4nfeeHF3XYrX7+GLET2RG+azAKGvTLLDX0c7HCGwaNpuzvc5lvk606WK4
	ueFKCUEtDradcJ2OHXWBmKE0YsTk9c4=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Anthony PERARD 
Subject: [PATCH v3 6/7] tools/libs: add a new libxenmanage library
Date: Fri, 13 Dec 2024 17:24:20 +0100
Message-ID: <20241213162421.16782-7-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213162421.16782-1-jgross@suse.com>
References: <20241213162421.16782-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 41C54210F3
X-Spam-Level: 
X-Spamd-Result: default: False [-3.01 / 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)[];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[gnu.org:url,suse.com:email,suse.com:dkim,suse.com:mid];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCVD_TLS_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCPT_COUNT_THREE(0.00)[3];
	DKIM_TRACE(0.00)[suse.com:+]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -3.01
X-Spam-Flag: NO

In order to have a stable interface in user land for using stable
domctl and possibly later sysctl interfaces, add a new library
libxenmanage.

Signed-off-by: Juergen Gross 
---
V1:
- new patch
V2:
- define __XEN_TOOLS__ via Makefile (Anthony PERARD)
- use SPDX in header file (Anthony PERARD)
- change function name to xenmanage_poll_changed_domain() (Anthony PERARD)
- add short library description (Anthony PERARD)
- narrow scope of xen_domctl_get_domain_state pointer (Anthony PERARD)
---
 tools/include/xenmanage.h          |  92 ++++++++++++++++
 tools/libs/Makefile                |   1 +
 tools/libs/manage/Makefile         |  10 ++
 tools/libs/manage/Makefile.common  |   3 +
 tools/libs/manage/core.c           | 168 +++++++++++++++++++++++++++++
 tools/libs/manage/libxenmanage.map |   8 ++
 tools/libs/uselibs.mk              |   2 +
 7 files changed, 284 insertions(+)
 create mode 100644 tools/include/xenmanage.h
 create mode 100644 tools/libs/manage/Makefile
 create mode 100644 tools/libs/manage/Makefile.common
 create mode 100644 tools/libs/manage/core.c
 create mode 100644 tools/libs/manage/libxenmanage.map

diff --git a/tools/include/xenmanage.h b/tools/include/xenmanage.h
new file mode 100644
index 0000000000..5d169693b0
--- /dev/null
+++ b/tools/include/xenmanage.h
@@ -0,0 +1,92 @@
+/* SPDX-License-Identifier: LGPL-2.1 */
+/*
+ * Copyright (c) 2024 SUSE Software Solutions Germany GmbH
+ *
+ * Interfaces of libxenmanage.
+ *
+ * libxenmanage provides management functions for the host using stable
+ * hypercall interfaces.
+ */
+#ifndef XENMANAGE_H
+#define XENMANAGE_H
+
+#include 
+
+/* Avoid the need to #include  */
+struct xentoollog_logger;
+
+typedef struct xenmanage_handle xenmanage_handle;
+
+/*
+ * Open libxenmanage.
+ *
+ * Get a handle of the xenmanage library. The handle is required for all
+ * further operations of the library.
+ * Parameters:
+ *   logger:     Logging function to use. If NULL logging is done to stderr.
+ *   open_flags: Only 0 supported.
+ * Return value: Handle or NULL if error.
+ */
+xenmanage_handle *xenmanage_open(struct xentoollog_logger *logger,
+                                 unsigned int open_flags);
+
+/*
+ * Close libxenmanage.
+ *
+ * Return a handle of the xenmanage library.
+ * Parameters:
+ *    hdl: Handle obtained by xenmanage_open().
+ * Return value: always 0.
+ */
+int xenmanage_close(xenmanage_handle *hdl);
+
+#define XENMANAGE_GETDOMSTATE_STATE_EXIST     0x0001  /* Domain is existing. */
+#define XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN  0x0002  /* Shutdown finished. */
+#define XENMANAGE_GETDOMSTATE_STATE_DYING     0x0004  /* Domain dying. */
+#define XENMANAGE_GETDOMSTATE_STATE_DEAD      0x0008  /* Domain dead. */
+
+/*
+ * Return state information of an existing domain.
+ *
+ * Returns the domain state and unique id of the given domain.
+ * Parameters:
+ *   hdl:       handle returned by xenmanage_open()
+ *   domid:     domain id of the domain to get the information for
+ *   state:     where to store the state (XENMANAGE_GETDOMSTATE_STATE_ flags,
+ *              nothing stored if NULL)
+ *   unique_id: where to store the unique id of the domain (nothing stored if
+ *              NULL)
+ * Return value: 0 if information was stored, -1 else (errno is set)
+ */
+int xenmanage_get_domain_info(xenmanage_handle *hdl, unsigned int domid,
+                              unsigned int *state, uint64_t *unique_id);
+
+/*
+ * Return information of a domain having changed state recently.
+ *
+ * Returns the domain id, state and unique id of a domain having changed
+ * state (any of the state bits was modified) since the last time information
+ * for that domain was returned by this function. Only usable by callers who
+ * have registered the VIRQ_DOM_EXC event (normally Xenstore).
+ * Parameters:
+ *   hdl:       handle returned by xenmanage_open()
+ *   domid:     where to store the domid of the domain (not NULL)
+ *   state:     where to store the state (XENMANAGE_GETDOMSTATE_STATE_ flags,
+ *              nothing stored if NULL)
+ *   unique_id: where to store the unique id of the domain (nothing stored if
+ *              NULL)
+ * Return value: 0 if information was stored, -1 else (errno is set)
+ */
+int xenmanage_poll_changed_domain(xenmanage_handle *hdl, unsigned int *domid,
+                                  unsigned int *state, uint64_t *unique_id);
+#endif /* XENMANAGE_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libs/Makefile b/tools/libs/Makefile
index 1afcd12e2b..d39516c1b3 100644
--- a/tools/libs/Makefile
+++ b/tools/libs/Makefile
@@ -12,6 +12,7 @@ SUBDIRS-y += devicemodel
 SUBDIRS-y += ctrl
 SUBDIRS-y += guest
 SUBDIRS-y += hypfs
+SUBDIRS-y += manage
 SUBDIRS-y += store
 SUBDIRS-y += stat
 SUBDIRS-$(CONFIG_Linux) += vchan
diff --git a/tools/libs/manage/Makefile b/tools/libs/manage/Makefile
new file mode 100644
index 0000000000..dbfe70d259
--- /dev/null
+++ b/tools/libs/manage/Makefile
@@ -0,0 +1,10 @@
+XEN_ROOT = $(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+MAJOR    = 1
+MINOR    = 0
+version-script := libxenmanage.map
+
+include Makefile.common
+
+include $(XEN_ROOT)/tools/libs/libs.mk
diff --git a/tools/libs/manage/Makefile.common b/tools/libs/manage/Makefile.common
new file mode 100644
index 0000000000..533ba30fba
--- /dev/null
+++ b/tools/libs/manage/Makefile.common
@@ -0,0 +1,3 @@
+CFLAGS += -D__XEN_TOOLS__
+
+OBJS-y  += core.o
diff --git a/tools/libs/manage/core.c b/tools/libs/manage/core.c
new file mode 100644
index 0000000000..b5fa67b036
--- /dev/null
+++ b/tools/libs/manage/core.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright (c) 2024 SUSE Software Solutions Germany GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see .
+ */
+
+#define _GNU_SOURCE
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct xenmanage_handle {
+    xentoollog_logger *logger, *logger_tofree;
+    unsigned int flags;
+    xencall_handle *xcall;
+};
+
+xenmanage_handle *xenmanage_open(xentoollog_logger *logger,
+                                 unsigned open_flags)
+{
+    xenmanage_handle *hdl = calloc(1, sizeof(*hdl));
+    int saved_errno;
+
+    if ( !hdl )
+        return NULL;
+
+    if ( open_flags )
+    {
+        errno = EINVAL;
+        goto err;
+    }
+
+    hdl->flags = open_flags;
+    hdl->logger = logger;
+    hdl->logger_tofree = NULL;
+
+    if ( !hdl->logger )
+    {
+        hdl->logger = hdl->logger_tofree =
+            (xentoollog_logger *)
+            xtl_createlogger_stdiostream(stderr, XTL_PROGRESS, 0);
+        if ( !hdl->logger )
+            goto err;
+    }
+
+    hdl->xcall = xencall_open(hdl->logger, 0);
+    if ( !hdl->xcall )
+        goto err;
+
+    return hdl;
+
+err:
+    saved_errno = errno;
+    xenmanage_close(hdl);
+    errno = saved_errno;
+
+    return NULL;
+}
+
+int xenmanage_close(xenmanage_handle *hdl)
+{
+    if ( !hdl )
+        return 0;
+
+    xencall_close(hdl->xcall);
+    xtl_logger_destroy(hdl->logger_tofree);
+    free(hdl);
+    return 0;
+}
+
+static int xenmanage_do_domctl_get_domain_state(xenmanage_handle *hdl,
+                                                unsigned int domid_in,
+                                                unsigned int *domid_out,
+                                                unsigned int *state,
+                                                uint64_t *unique_id)
+{
+    struct xen_domctl *buf;
+    int saved_errno;
+    int ret;
+
+    buf = xencall_alloc_buffer(hdl->xcall, sizeof(*buf));
+    if ( !buf )
+    {
+        errno = ENOMEM;
+        return -1;
+    }
+
+    memset(buf, 0, sizeof(*buf));
+
+    buf->cmd = XEN_DOMCTL_get_domain_state;
+    buf->domain = domid_in;
+
+    ret = xencall1(hdl->xcall, __HYPERVISOR_domctl, (unsigned long)buf);
+    saved_errno = errno;
+    if ( !ret )
+    {
+        struct xen_domctl_get_domain_state *st = &buf->u.get_domain_state;
+
+        if ( domid_out )
+            *domid_out = buf->domain;
+        if ( state )
+        {
+            *state = 0;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_EXIST )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_EXIST;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_DYING )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_DYING;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_DEAD )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_DEAD;
+        }
+        if ( unique_id )
+            *unique_id = st->unique_id;
+    }
+
+    xencall_free_buffer(hdl->xcall, buf);
+
+    errno = saved_errno;
+
+    return ret;
+}
+
+int xenmanage_get_domain_info(xenmanage_handle *hdl, unsigned int domid,
+                              unsigned int *state, uint64_t *unique_id)
+{
+    if ( !hdl || domid >= DOMID_FIRST_RESERVED )
+    {
+        errno = EINVAL;
+        return -1;
+    }
+
+    return xenmanage_do_domctl_get_domain_state(hdl, domid, NULL, state,
+                                                unique_id);
+}
+
+int xenmanage_poll_changed_domain(xenmanage_handle *hdl, unsigned int *domid,
+                                  unsigned int *state, uint64_t *unique_id)
+{
+    if ( !hdl || !domid )
+    {
+        errno = EINVAL;
+        return -1;
+    }
+
+    return xenmanage_do_domctl_get_domain_state(hdl, DOMID_INVALID, domid,
+                                                state, unique_id);
+}
diff --git a/tools/libs/manage/libxenmanage.map b/tools/libs/manage/libxenmanage.map
new file mode 100644
index 0000000000..64c793e603
--- /dev/null
+++ b/tools/libs/manage/libxenmanage.map
@@ -0,0 +1,8 @@
+VERS_1.0 {
+	global:
+		xenmanage_open;
+		xenmanage_close;
+		xenmanage_get_domain_info;
+		xenmanage_poll_changed_domain;
+	local: *; /* Do not expose anything by default */
+};
diff --git a/tools/libs/uselibs.mk b/tools/libs/uselibs.mk
index 7aa8d83e06..c0a234cfec 100644
--- a/tools/libs/uselibs.mk
+++ b/tools/libs/uselibs.mk
@@ -16,6 +16,8 @@ LIBS_LIBS += devicemodel
 USELIBS_devicemodel := toollog toolcore call
 LIBS_LIBS += hypfs
 USELIBS_hypfs := toollog toolcore call
+LIBS_LIBS += manage
+USELIBS_manage := toollog toolcore call
 LIBS_LIBS += ctrl
 USELIBS_ctrl := toollog call evtchn gnttab foreignmemory devicemodel
 LIBS_LIBS += guest
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:28:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:28:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856847.1269372 (Exim 4.92)
	(envelope-from )
	id 1tM8Wh-00040D-0N; Fri, 13 Dec 2024 16:28:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856847.1269372; Fri, 13 Dec 2024 16:28:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tM8Wg-0003zS-Pz; Fri, 13 Dec 2024 16:28:26 +0000
Received: by outflank-mailman (input) for mailman id 856847;
 Fri, 13 Dec 2024 16:28: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 1tM8Wg-0003wR-0M
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:28:26 +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 467cc13f-b96f-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 17:28:24 +0100 (CET)
Received: by mail-ej1-x62a.google.com with SMTP id
 a640c23a62f3a-aa69077b93fso287611766b.0
 for ; Fri, 13 Dec 2024 08:28:24 -0800 (PST)
Received: from carlo-ubuntu.minervasys.tech ([193.207.202.156])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa673474d96sm841759266b.96.2024.12.13.08.28.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 08:28: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: 467cc13f-b96f-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734107304; x=1734712104; 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=8xN4Aad0/N1nJ9Tga4wRWIzgobDhCTST0LCZu2HLDn0=;
        b=ZaqCzRa86ZFYFQR3oGv4CSgk0Cc2de4yl0MFlA6c1wW4RrBE9XjpJ41B1QqaPpUnbm
         Ej2Mp5MHEDMud5cGVblYqT54LMKDrecIYBvmymJ9l3Rpsk+GWEq/0GUyO/up/gy3x5ue
         yAEtHVazzF/InCZwcwxDqjinl0Dsk61NrYDtbMrIIN+8Znym8GE7vypFlZd8ZeIjt4WC
         OvJyGadsjZn5jp4c31YB/BDpokeFMAO31eJSt1ek7X77O5Vy4QGGyYfSBzENIrPjKNWp
         VCFKAiDyV2FT+jmeO+pzLEQ+OzBFcIPPyw1oCaVFlvLEDp/p4JNZ12UNaTzM2tCw7s/a
         gAEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734107304; x=1734712104;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=8xN4Aad0/N1nJ9Tga4wRWIzgobDhCTST0LCZu2HLDn0=;
        b=oxRjgJd22KNhVX0EMW8VYN/KLLX9m8++ponFocMeePE4wda68q+T1S8APjkrhR455+
         P937d/sCwHRPVHDuyd942Xo9OkMOvzx3a8UJmgiXH8wwyv8HrvRQirPKe410QNZLYNf4
         c4w1Bxh8BYfj8+IuRy2unvxR/Fd1x9c9gm7fLH0F5c4LVaaBWms9OICMeg3CSvFZkFYs
         9lDJAlTi9kBGwdObDVkaZkoX79LYFifQIqKXQVRI2RQEvtBx1CA5moNmdO0d3FEcGlST
         hjcu6DmlMT6xC4rNn5L4XyDaA0zi2TU9qheTidIoxf5JAnM71IZrNrelZ2Bd4r7JFvUI
         DG8w==
X-Gm-Message-State: AOJu0Yycjp0dwnEqvGzYdhAtUvhxjroJptNrtEEr04fO8PjvjGhSwtsH
	aeshjUG0c8H0k7law2hpsW3vLFJrO6QwttBkSmtJoRWmNrhYaGbh9w80ybPRvEI2hi326E5vK94
	5LfU=
X-Gm-Gg: ASbGncsPlSz77NC6zLgT3cFQ4zrqzeG6Djkbh/Aqjv5FMREREh4HDvIf7O8DuRdc2Mc
	3a8Vqj88bJrSi6XFpeox3vXDV/ab5k8wFGkyAqC/wmqU/Uj+SpDbLJmXYWofkLiAfZZedqVksFf
	P3uKomJFaUokdVwiIYsMqB9ffx1Yf/icTzo5Vd0DXKxrzZA6cYLTUPf3ngsnNjEZiS3WzGvmfWx
	fCOEoWI6zVP6ZtfBE30gAaRGUiIBu1yqfBpK8uDXF2azrxaBMvFR5v7lVEz6E2oExVsiV9/b5B/
	IHJfRXVCmV6/9E9q
X-Google-Smtp-Source: AGHT+IHqGWEcyP0h9uma1N7BRtF5EwlfEgnSQP1GSbk05iZA42D2fIB2f80WRWhc5Q15HZHwaA199w==
X-Received: by 2002:a17:907:6eab:b0:aa6:8d51:8fe2 with SMTP id a640c23a62f3a-aab77e9f793mr343278366b.42.1734107303821;
        Fri, 13 Dec 2024 08:28:23 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v12 01/12] xen/common: add cache coloring common code
Date: Fri, 13 Dec 2024 17:28:04 +0100
Message-ID: <20241213162815.9196-2-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Last Level Cache (LLC) coloring allows to partition the cache in smaller
chunks called cache colors.

Since not all architectures can actually implement it, add a HAS_LLC_COLORING
Kconfig option.
LLC_COLORS_ORDER Kconfig option has a range maximum of 10 (2^10 = 1024)
because that's the number of colors that fit in a 4 KiB page when integers
are 4 bytes long.

LLC colors are a property of the domain, so struct domain has to be extended.

Based on original work from: Luca Miccio 

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
Acked-by: Michal Orzel 
---
v12:
- fixed build errors
- added opt_llc_coloring to improve readibility
- reverted llc_coloring_enabled type to bool
v11:
- __COLORING_H__ -> __XEN_LLC_COLORING_H__ in llc-coloring.h
- added SPDX tag to cache-coloring.rst
- llc-coloring=off now takes precedence over other cmdline options
- removed useless #includes
v10:
- fixed commit message to use LLC_COLORS_ORDER
- added documentation to index.rst
- moved check on CONFIG_NUMA in arch/arm/Kconfig (next patch)
- fixed copyright line
- fixed array type for colors parameter in print_colors()
- added check on (way_size & ~PAGE_MASK)
v9:
- dropped _MAX_ from CONFIG_MAX_LLC_COLORS_ORDER
v8:
- minor documentation fixes
- "llc-coloring=on" is inferred from "llc-nr-ways" and "llc-size" usage
- turned CONFIG_NR_LLC_COLORS to CONFIG_MAX_LLC_COLORS_ORDER, base-2 exponent
- moved Kconfig options to common/Kconfig
- don't crash if computed max_nr_colors is too large
v7:
- SUPPORT.md changes added to this patch
- extended documentation to better address applicability of cache coloring
- "llc-nr-ways" and "llc-size" params introduced in favor of "llc-way-size"
- moved dump_llc_coloring_info() call in 'm' keyhandler (pagealloc_info())
v6:
- moved almost all code in common
- moved documentation in this patch
- reintroduced range for CONFIG_NR_LLC_COLORS
- reintroduced some stub functions to reduce the number of checks on
  llc_coloring_enabled
- moved domain_llc_coloring_free() in same patch where allocation happens
- turned "d->llc_colors" to pointer-to-const
- llc_coloring_init() now returns void and panics if errors are found
v5:
- used - instead of _ for filenames
- removed domain_create_llc_colored()
- removed stub functions
- coloring domain fields are now #ifdef protected
v4:
- Kconfig options moved to xen/arch
- removed range for CONFIG_NR_LLC_COLORS
- added "llc_coloring_enabled" global to later implement the boot-time
  switch
- added domain_create_llc_colored() to be able to pass colors
- added is_domain_llc_colored() macro
---
 SUPPORT.md                        |   7 ++
 docs/index.rst                    |   1 +
 docs/misc/cache-coloring.rst      | 118 ++++++++++++++++++++++++++++
 docs/misc/xen-command-line.pandoc |  37 +++++++++
 xen/common/Kconfig                |  21 +++++
 xen/common/Makefile               |   1 +
 xen/common/keyhandler.c           |   3 +
 xen/common/llc-coloring.c         | 124 ++++++++++++++++++++++++++++++
 xen/common/page_alloc.c           |   3 +
 xen/include/xen/llc-coloring.h    |  36 +++++++++
 xen/include/xen/sched.h           |   5 ++
 11 files changed, 356 insertions(+)
 create mode 100644 docs/misc/cache-coloring.rst
 create mode 100644 xen/common/llc-coloring.c
 create mode 100644 xen/include/xen/llc-coloring.h

diff --git a/SUPPORT.md b/SUPPORT.md
index 82239d0294..998faf5635 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -401,6 +401,13 @@ by maintaining multiple physical to machine (p2m) memory mappings.
     Status, x86 HVM: Tech Preview
     Status, ARM: Tech Preview
 
+### Cache coloring
+
+Allows to reserve Last Level Cache (LLC) partitions for Dom0, DomUs and Xen
+itself.
+
+    Status, Arm64: Experimental
+
 ## Resource Management
 
 ### CPU Pools
diff --git a/docs/index.rst b/docs/index.rst
index 1d44796d72..1bb8d02ea3 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -66,6 +66,7 @@ Documents in need of some rearranging.
    misc/xen-makefiles/makefiles
    misra/index
    fusa/index
+   misc/cache-coloring
 
 
 Miscellanea
diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
new file mode 100644
index 0000000000..371f21a0e7
--- /dev/null
+++ b/docs/misc/cache-coloring.rst
@@ -0,0 +1,118 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Xen cache coloring user guide
+=============================
+
+The cache coloring support in Xen allows to reserve Last Level Cache (LLC)
+partitions for Dom0, DomUs and Xen itself. Currently only ARM64 is supported.
+Cache coloring realizes per-set cache partitioning in software and is applicable
+to shared LLCs as implemented in Cortex-A53, Cortex-A72 and similar CPUs.
+
+To compile LLC coloring support set ``CONFIG_LLC_COLORING=y``.
+
+If needed, change the maximum number of colors with
+``CONFIG_LLC_COLORS_ORDER=``.
+
+Runtime configuration is done via `Command line parameters`_.
+
+Background
+**********
+
+Cache hierarchy of a modern multi-core CPU typically has first levels dedicated
+to each core (hence using multiple cache units), while the last level is shared
+among all of them. Such configuration implies that memory operations on one
+core (e.g. running a DomU) are able to generate interference on another core
+(e.g. hosting another DomU). Cache coloring realizes per-set cache-partitioning
+in software and mitigates this, guaranteeing more predictable performances for
+memory accesses.
+Software-based cache coloring is particularly useful in those situations where
+no hardware mechanisms (e.g., DSU-based way partitioning) are available to
+partition caches. This is the case for e.g., Cortex-A53, A57 and A72 CPUs that
+feature a L2 LLC cache shared among all cores.
+
+The key concept underlying cache coloring is a fragmentation of the memory
+space into a set of sub-spaces called colors that are mapped to disjoint cache
+partitions. Technically, the whole memory space is first divided into a number
+of subsequent regions. Then each region is in turn divided into a number of
+subsequent sub-colors. The generic i-th color is then obtained by all the
+i-th sub-colors in each region.
+
+::
+
+                            Region j            Region j+1
+                .....................   ............
+                .                     . .
+                .                       .
+            _ _ _______________ _ _____________________ _ _
+                |     |     |     |     |     |     |
+                | c_0 | c_1 |     | c_n | c_0 | c_1 |
+           _ _ _|_____|_____|_ _ _|_____|_____|_____|_ _ _
+                    :                       :
+                    :                       :...         ... .
+                    :                            color 0
+                    :...........................         ... .
+                                                :
+          . . ..................................:
+
+How colors are actually defined depends on the function that maps memory to
+cache lines. In case of physically-indexed, physically-tagged caches with linear
+mapping, the set index is found by extracting some contiguous bits from the
+physical address. This allows colors to be defined as shown in figure: they
+appear in memory as subsequent blocks of equal size and repeats themselves after
+``n`` different colors, where ``n`` is the total number of colors.
+
+If some kind of bit shuffling appears in the mapping function, then colors
+assume a different layout in memory. Those kind of caches aren't supported by
+the current implementation.
+
+**Note**: Finding the exact cache mapping function can be a really difficult
+task since it's not always documented in the CPU manual. As said Cortex-A53, A57
+and A72 are known to work with the current implementation.
+
+How to compute the number of colors
+###################################
+
+Given the linear mapping from physical memory to cache lines for granted, the
+number of available colors for a specific platform is computed using three
+parameters:
+
+- the size of the LLC.
+- the number of the LLC ways.
+- the page size used by Xen.
+
+The first two parameters can be found in the processor manual, while the third
+one is the minimum mapping granularity. Dividing the cache size by the number of
+its ways we obtain the size of a way. Dividing this number by the page size,
+the number of total cache colors is found. So for example an Arm Cortex-A53
+with a 16-ways associative 1 MiB LLC can isolate up to 16 colors when pages are
+4 KiB in size.
+
+Effective colors assignment
+###########################
+
+When assigning colors, if one wants to avoid cache interference between two
+domains, different colors needs to be used for their memory.
+
+Command line parameters
+***********************
+
+Specific documentation is available at `docs/misc/xen-command-line.pandoc`.
+
++----------------------+-------------------------------+
+| **Parameter**        | **Description**               |
++----------------------+-------------------------------+
+| ``llc-coloring``     | Enable coloring at runtime    |
++----------------------+-------------------------------+
+| ``llc-size``         | Set the LLC size              |
++----------------------+-------------------------------+
+| ``llc-nr-ways``      | Set the LLC number of ways    |
++----------------------+-------------------------------+
+
+Auto-probing of LLC specs
+#########################
+
+LLC size and number of ways are probed automatically by default.
+
+LLC specs can be manually set via the above command line parameters. This
+bypasses any auto-probing and it's used to overcome failing situations, such as
+flawed probing logic, or for debugging/testing purposes.
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 293dbc1a95..abd8dae96f 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1708,6 +1708,43 @@ This option is intended for debugging purposes only.  Enable MSR_DEBUGCTL.LBR
 in hypervisor context to be able to dump the Last Interrupt/Exception To/From
 record with other registers.
 
+### llc-coloring (arm64)
+> `= `
+
+> Default: `false`
+
+Flag to enable or disable LLC coloring support at runtime. This option is
+available only when `CONFIG_LLC_COLORING` is enabled. See the general
+cache coloring documentation for more info.
+
+### llc-nr-ways (arm64)
+> `= `
+
+> Default: `Obtained from hardware`
+
+Specify the number of ways of the Last Level Cache. This option is available
+only when `CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are used
+to find the number of supported cache colors. By default the value is
+automatically computed by probing the hardware, but in case of specific needs,
+it can be manually set. Those include failing probing and debugging/testing
+purposes so that it's possible to emulate platforms with different number of
+supported colors. If set, also "llc-size" must be set, otherwise the default
+will be used. Note that using both options implies "llc-coloring=on".
+
+### llc-size (arm64)
+> `= `
+
+> Default: `Obtained from hardware`
+
+Specify the size of the Last Level Cache. This option is available only when
+`CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are used to find
+the number of supported cache colors. By default the value is automatically
+computed by probing the hardware, but in case of specific needs, it can be
+manually set. Those include failing probing and debugging/testing purposes so
+that it's possible to emulate platforms with different number of supported
+colors. If set, also "llc-nr-ways" must be set, otherwise the default will be
+used. Note that using both options implies "llc-coloring=on".
+
 ### lock-depth-size
 > `= `
 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 90268d9249..b4ec6893be 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -71,6 +71,9 @@ config HAS_IOPORTS
 config HAS_KEXEC
 	bool
 
+config HAS_LLC_COLORING
+	bool
+
 config HAS_PIRQ
 	bool
 
@@ -516,4 +519,22 @@ config TRACEBUFFER
 	  to be collected at run time for debugging or performance analysis.
 	  Memory and execution overhead when not active is minimal.
 
+config LLC_COLORING
+	bool "Last Level Cache (LLC) coloring" if EXPERT
+	depends on HAS_LLC_COLORING
+
+config LLC_COLORS_ORDER
+	int "Maximum number of LLC colors (base-2 exponent)"
+	range 1 10
+	default 7
+	depends on LLC_COLORING
+	help
+	  Controls the build-time size of various arrays associated with LLC
+	  coloring. The value is a base-2 exponent. Refer to cache coloring
+	  documentation for how to compute the number of colors supported by the
+	  platform. This is only an upper bound. The runtime value is autocomputed
+	  or manually set via cmdline parameters.
+	  The default value corresponds to an 8 MiB 16-ways LLC, which should be
+	  more than what's needed in the general case.
+
 endmenu
diff --git a/xen/common/Makefile b/xen/common/Makefile
index b279b09bfb..cba3b32733 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -25,6 +25,7 @@ obj-y += keyhandler.o
 obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_KEXEC) += kimage.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
+obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
 obj-$(CONFIG_MEM_ACCESS) += mem_access.o
 obj-y += memory.o
 obj-y += multicall.o
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 6da291b34e..6ea54838d4 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -304,6 +305,8 @@ static void cf_check dump_domains(unsigned char key)
 
         arch_dump_domain_info(d);
 
+        domain_dump_llc_colors(d);
+
         rangeset_domain_printk(d);
 
         dump_pageframe_info(d);
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
new file mode 100644
index 0000000000..b0fc162b05
--- /dev/null
+++ b/xen/common/llc-coloring.c
@@ -0,0 +1,124 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Last Level Cache (LLC) coloring common code
+ *
+ * Copyright (C) 2024, Advanced Micro Devices, Inc.
+ * Copyright (C) 2024, Minerva Systems SRL
+ */
+#include 
+#include 
+#include 
+
+#define NR_LLC_COLORS          (1U << CONFIG_LLC_COLORS_ORDER)
+
+/*
+ * -1: not specified (disabled unless llc-size and llc-nr-ways present)
+ *  0: explicitly disabled through cmdline
+ *  1: explicitly enabled through cmdline
+ */
+static int8_t __initdata opt_llc_coloring = -1;
+boolean_param("llc-coloring", opt_llc_coloring);
+
+static bool __ro_after_init llc_coloring_enabled;
+
+static unsigned int __initdata llc_size;
+size_param("llc-size", llc_size);
+static unsigned int __initdata llc_nr_ways;
+integer_param("llc-nr-ways", llc_nr_ways);
+/* Number of colors available in the LLC */
+static unsigned int __ro_after_init max_nr_colors;
+
+static void print_colors(const unsigned int colors[], unsigned int num_colors)
+{
+    unsigned int i;
+
+    printk("{ ");
+    for ( i = 0; i < num_colors; i++ )
+    {
+        unsigned int start = colors[i], end = start;
+
+        printk("%u", start);
+
+        for ( ; i < num_colors - 1 && end + 1 == colors[i + 1]; i++, end++ )
+            ;
+
+        if ( start != end )
+            printk("-%u", end);
+
+        if ( i < num_colors - 1 )
+            printk(", ");
+    }
+    printk(" }\n");
+}
+
+void __init llc_coloring_init(void)
+{
+    unsigned int way_size;
+
+    llc_coloring_enabled = (opt_llc_coloring == 1);
+    if ( (opt_llc_coloring != 0) && llc_size && llc_nr_ways )
+    {
+        llc_coloring_enabled = true;
+        way_size = llc_size / llc_nr_ways;
+    }
+    else if ( !llc_coloring_enabled )
+        return;
+    else
+    {
+        way_size = get_llc_way_size();
+        if ( !way_size )
+            panic("LLC probing failed and 'llc-size' or 'llc-nr-ways' missing\n");
+    }
+
+    if ( way_size & ~PAGE_MASK )
+        panic("LLC way size must be a multiple of PAGE_SIZE\n");
+
+    /*
+     * The maximum number of colors must be a power of 2 in order to correctly
+     * map them to bits of an address.
+     */
+    max_nr_colors = way_size >> PAGE_SHIFT;
+
+    if ( max_nr_colors & (max_nr_colors - 1) )
+        panic("Number of LLC colors (%u) isn't a power of 2\n", max_nr_colors);
+
+    if ( max_nr_colors > NR_LLC_COLORS )
+    {
+        printk(XENLOG_WARNING
+               "Number of LLC colors (%u) too big. Using configured max %u\n",
+               max_nr_colors, NR_LLC_COLORS);
+        max_nr_colors = NR_LLC_COLORS;
+    }
+    else if ( max_nr_colors < 2 )
+        panic("Number of LLC colors %u < 2\n", max_nr_colors);
+
+    arch_llc_coloring_init();
+}
+
+void dump_llc_coloring_info(void)
+{
+    if ( !llc_coloring_enabled )
+        return;
+
+    printk("LLC coloring info:\n");
+    printk("    Number of LLC colors supported: %u\n", max_nr_colors);
+}
+
+void domain_dump_llc_colors(const struct domain *d)
+{
+    if ( !llc_coloring_enabled )
+        return;
+
+    printk("%u LLC colors: ", d->num_llc_colors);
+    print_colors(d->llc_colors, d->num_llc_colors);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 92abed6514..55d561e93c 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -126,6 +126,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2644,6 +2645,8 @@ static void cf_check pagealloc_info(unsigned char key)
     }
 
     printk("    Dom heap: %lukB free\n", total << (PAGE_SHIFT-10));
+
+    dump_llc_coloring_info();
 }
 
 static __init int cf_check pagealloc_keyhandler_init(void)
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
new file mode 100644
index 0000000000..0acd8d0ad6
--- /dev/null
+++ b/xen/include/xen/llc-coloring.h
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Last Level Cache (LLC) coloring common header
+ *
+ * Copyright (C) 2024, Advanced Micro Devices, Inc.
+ * Copyright (C) 2024, Minerva Systems SRL
+ */
+#ifndef __XEN_LLC_COLORING_H__
+#define __XEN_LLC_COLORING_H__
+
+struct domain;
+
+#ifdef CONFIG_LLC_COLORING
+void llc_coloring_init(void);
+void dump_llc_coloring_info(void);
+void domain_dump_llc_colors(const struct domain *d);
+#else
+static inline void llc_coloring_init(void) {}
+static inline void dump_llc_coloring_info(void) {}
+static inline void domain_dump_llc_colors(const struct domain *d) {}
+#endif
+
+unsigned int get_llc_way_size(void);
+void arch_llc_coloring_init(void);
+
+#endif /* __XEN_LLC_COLORING_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 76e39378b3..bc798a2f61 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -637,6 +637,11 @@ struct domain
 
     /* Holding CDF_* constant. Internal flags for domain creation. */
     unsigned int cdf;
+
+#ifdef CONFIG_LLC_COLORING
+    unsigned int num_llc_colors;
+    const unsigned int *llc_colors;
+#endif
 };
 
 static inline struct page_list_head *page_to_list(
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:28:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:28:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856846.1269365 (Exim 4.92)
	(envelope-from )
	id 1tM8Wg-0003we-M6; Fri, 13 Dec 2024 16:28:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856846.1269365; Fri, 13 Dec 2024 16:28:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tM8Wg-0003wX-II; Fri, 13 Dec 2024 16:28:26 +0000
Received: by outflank-mailman (input) for mailman id 856846;
 Fri, 13 Dec 2024 16:28: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 1tM8We-0003wJ-QD
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:28:25 +0000
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [2a00:1450:4864:20::534])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4540136b-b96f-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 17:28:22 +0100 (CET)
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-5d3f249f3b2so2466322a12.3
 for ; Fri, 13 Dec 2024 08:28:22 -0800 (PST)
Received: from carlo-ubuntu.minervasys.tech ([193.207.202.156])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa673474d96sm841759266b.96.2024.12.13.08.28.19
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 08:28: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: 4540136b-b96f-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734107302; x=1734712102; 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=uFJsugpqRu+wkYb+hKtB3kv+BczMORwJDo3dzgPHCwI=;
        b=XQb4yEVCZsbKb1usGLDmZ8Qv7QDz8OfnGnNw+30YAb6ligMvWncBuyb0wAbWEGP8oD
         DM58WV98nA1Q7OjTgwjOvE1L64ei0UEvc7cPWNAS91C5cEfu7+BWNegUk2eZo8iMnAqM
         7f0GJFT3Ec1h2C7VXowm9kn0MPi/PFDD5W4x7EenBpEH2ao+A86yYxykeKiOpgGvnH6X
         +4UMfHxx096wv7weFktPvgPsEaq3kFtRtX5rIK1VlDXL2SzpbQItW8ChIflw+87n6IKk
         ADSZ1A8DJeWbxZSePNb4QIaYBiI1X8/5d82ePODsmmfx4FlKkTzlzm0/GYhGaHw2zLid
         onOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734107302; x=1734712102;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=uFJsugpqRu+wkYb+hKtB3kv+BczMORwJDo3dzgPHCwI=;
        b=U2K0RbJnEr340MTZ9eeASIgspZWfNIRSMgwwLJLjVSu+MVaWn7dxZg3CNNEumzdWzL
         rrdRUgDfVnATsF9neWluFYV4usjAnuLo+dvSY+ZC/GRFFq5BvxwRQt3QWShyAZ2xfjVq
         c0E+yf7pvxx5Dpp+JYjwC26Ucg6/nTPoSdiTAfOke3wIozqIpzX8ydzyWVx3shTXWe2y
         MQIJYfPaw29CH4QnVJLQXJoINJVdgq71gNZq/XZiizU6A0qQNMlLy9PBDSOdb9N73Zgy
         HT8aN31pLW6cONaps4mOy4rSE+eC15thjSrr4rGGakVmUz3eLDJ4Rxw/nsawD9rzQBsU
         2HkA==
X-Gm-Message-State: AOJu0YwueJvXFBlW+Oz/XsIDzBZ/N58TOWjSqzEFhQy7Sb17TSnkxqfk
	xU+glZjRixl2Bfw0OKa9K1ZxBYQ9qZ94fktPZOpVoJ+YLMRzs8IKGKx6agLQ2y8r2Hr0wEDZXUw
	TJhY=
X-Gm-Gg: ASbGncuohgjUWxU0OCVKpJn+Kjl+zJzlLj37EstBkfmhBHGlIyUuZdQFvDAxNfp9OOO
	/FwrFRE8bKQ0h7JjkJWWjqbWfGI0bW2S2u+40f8CGTLrGpXORu2LbWPCXcalmjHVd/luTtQOg6r
	b13CRDd7bKsvrTf9doUi7cP2p6eaqkDPWGXy9Fi5hVT7SbgC5uqcTuxlD0CsjQwRNwOlrLxPnso
	Gy4f+zo+wBXEb7trUpHzo3gKcPz+fNuNLn5xwv2eSL2cyLf5uS2Prf/9bfs9x2e+OswZoeGAnKx
	/YMHLcBpHVxwOVxw
X-Google-Smtp-Source: AGHT+IFNLnZwB7igfihHtVdilMmPwYv0HKls6IekFrpik0Gl7X0sLu5xTzw1mWzCOaX8/tq9uUqx5Q==
X-Received: by 2002:a05:6402:354b:b0:5d0:c7a7:ac13 with SMTP id 4fb4d7f45d1cf-5d63c409146mr7688886a12.34.1734107301860;
        Fri, 13 Dec 2024 08:28:21 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Volodymyr Babchuk ,
	Nick Rosbrook ,
	George Dunlap ,
	Juergen Gross 
Subject: [PATCH v12 00/12] Arm cache coloring
Date: Fri, 13 Dec 2024 17:28:03 +0100
Message-ID: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Shared caches in multi-core CPU architectures represent a problem for
predictability of memory access latency. This jeopardizes applicability
of many Arm platform in real-time critical and mixed-criticality
scenarios. We introduce support for cache partitioning with page
coloring, a transparent software technique that enables isolation
between domains and Xen, and thus avoids cache interference.

When creating a domain, a simple syntax (e.g. `0-3` or `4-11`) allows
the user to define assignments of cache partitions ids, called colors,
where assigning different colors guarantees no mutual eviction on cache
will ever happen. This instructs the Xen memory allocator to provide
the i-th color assignee only with pages that maps to color i, i.e. that
are indexed in the i-th cache partition.

The proposed implementation supports the dom0less feature.
The proposed implementation doesn't support the static-mem feature.
The solution has been tested in several scenarios, including Xilinx Zynq
MPSoCs.

Carlo Nonato (11):
  xen/common: add cache coloring common code
  xen/arm: add initial support for LLC coloring on arm64
  xen/arm: permit non direct-mapped Dom0 construction
  xen/arm: add Dom0 cache coloring support
  xen: extend domctl interface for cache coloring
  tools: add support for cache coloring configuration
  xen/arm: add support for cache coloring configuration via device-tree
  xen/page_alloc: introduce preserved page flags macro
  xen: add cache coloring allocator for domains
  xen/arm: make consider_modules() available for xen relocation
  xen/arm: add cache coloring support for Xen image

Luca Miccio (1):
  xen/arm: add Xen cache colors command line parameter

 SUPPORT.md                              |   7 +
 docs/index.rst                          |   1 +
 docs/man/xl.cfg.5.pod.in                |   6 +
 docs/misc/arm/device-tree/booting.txt   |   5 +
 docs/misc/cache-coloring.rst            | 248 +++++++++++++++
 docs/misc/xen-command-line.pandoc       |  70 +++++
 tools/golang/xenlight/helpers.gen.go    |  16 +
 tools/golang/xenlight/types.gen.go      |   1 +
 tools/include/libxl.h                   |   5 +
 tools/include/xenctrl.h                 |   9 +
 tools/libs/ctrl/xc_domain.c             |  34 ++
 tools/libs/light/libxl_create.c         |  18 ++
 tools/libs/light/libxl_types.idl        |   1 +
 tools/xl/xl_parse.c                     |  38 ++-
 xen/arch/arm/Kconfig                    |   1 +
 xen/arch/arm/Makefile                   |   1 +
 xen/arch/arm/alternative.c              |  26 +-
 xen/arch/arm/arm32/mmu/mm.c             |  95 +-----
 xen/arch/arm/arm64/mmu/head.S           |  58 +++-
 xen/arch/arm/arm64/mmu/mm.c             |  29 ++
 xen/arch/arm/dom0less-build.c           |  60 +---
 xen/arch/arm/domain_build.c             | 173 ++++++++++-
 xen/arch/arm/include/asm/domain_build.h |   4 +
 xen/arch/arm/include/asm/mm.h           |   5 +
 xen/arch/arm/include/asm/mmu/layout.h   |   3 +
 xen/arch/arm/include/asm/mmu/mm.h       |   1 +
 xen/arch/arm/include/asm/processor.h    |  15 +
 xen/arch/arm/include/asm/setup.h        |   3 +
 xen/arch/arm/llc-coloring.c             | 142 +++++++++
 xen/arch/arm/mmu/setup.c                | 197 +++++++++++-
 xen/arch/arm/setup.c                    |  13 +-
 xen/common/Kconfig                      |  29 ++
 xen/common/Makefile                     |   1 +
 xen/common/domain.c                     |   3 +
 xen/common/domctl.c                     |  10 +
 xen/common/keyhandler.c                 |   3 +
 xen/common/llc-coloring.c               | 393 ++++++++++++++++++++++++
 xen/common/page_alloc.c                 | 200 +++++++++++-
 xen/include/public/domctl.h             |   9 +
 xen/include/xen/llc-coloring.h          |  65 ++++
 xen/include/xen/sched.h                 |   5 +
 xen/include/xen/xmalloc.h               |  12 +
 42 files changed, 1843 insertions(+), 172 deletions(-)
 create mode 100644 docs/misc/cache-coloring.rst
 create mode 100644 xen/arch/arm/llc-coloring.c
 create mode 100644 xen/common/llc-coloring.c
 create mode 100644 xen/include/xen/llc-coloring.h

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:28:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:28:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856848.1269385 (Exim 4.92)
	(envelope-from )
	id 1tM8Wi-0004R6-Am; Fri, 13 Dec 2024 16:28:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856848.1269385; Fri, 13 Dec 2024 16:28:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tM8Wi-0004Qd-64; Fri, 13 Dec 2024 16:28:28 +0000
Received: by outflank-mailman (input) for mailman id 856848;
 Fri, 13 Dec 2024 16:28: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 1tM8Wh-0003wR-42
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:28:27 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 47771352-b96f-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 17:28:26 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-a9a0ef5179dso303330166b.1
 for ; Fri, 13 Dec 2024 08:28:26 -0800 (PST)
Received: from carlo-ubuntu.minervasys.tech ([193.207.202.156])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa673474d96sm841759266b.96.2024.12.13.08.28.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 08:28: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: 47771352-b96f-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734107306; x=1734712106; 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=q6nZdsDBVSk0DEXukpRwfqMedc+oXoqSMGtI7VFZIVI=;
        b=SwVRCJxwFp6rNu8+sO+XQb4dmvF6PGxqKmDbK+J/zliAdnrTFd0Fgf7lTynRlqNgDC
         ww+zcOdb6I/UH0Q2ZQJ91aZM1HUN4TyVLlp1seuZdFpXLwcpVVtM44ShJSUM79YKGdYD
         Vm1FZRV7/9xblOZUlHlXJ7JHRWmta8vy35sXIw3oOS722gihRtORSvzU/mrP6gvk3dvi
         z3AAHiEolisLmiT4zAtSWYSjd4szIFu0Nmrheu/me0RmMvk5TD55V8ACh1CsK8LRvAnu
         joXuNWPmKirXHD0COox9bKLFQijPOg5Qlon1nEbRobob1Hp6wXDsUbGy0/J8mapAnXJ5
         xHvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734107306; x=1734712106;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=q6nZdsDBVSk0DEXukpRwfqMedc+oXoqSMGtI7VFZIVI=;
        b=lgS9RishlryUoXV7BKgLIpKTXR3c2R+dsDAAcBZSiesTE0RitiB0E9q8joo2hVqphr
         soLw35fcwVqnf7PftCMWBVRAGGm6MVN+bC+Smp78BCfN8ukV6U15i0zGHr51l0TWE4RP
         s+MT/Gs2GwLrjovMH6viXse7rMrrGVpF+LLByYQCIduISJmlz1wQgX2F3kem/4ViP0ON
         7PyfXgNSediJums4pE0Dy3jMYR/BN4qFCDhf808mBmLmrOJ8NYXa3SsdmyOtdRauSiVp
         4I2X50t1PoM22YNPaQP8YAXZjyWUttGwW8GDWW0LXCny4j+FrNDCXU7qUqC0i9BqpyWU
         Hf3g==
X-Gm-Message-State: AOJu0YwuuwlwyRnJtsOylZxIAEyzMDysAr1dueq3BOfB1TiNEOeVvuNP
	tRyuvfjEuBtBGzbo8/pBSF3vVnMVwdGpFQY3a4rm36RbnAJZV9zIrLPVy6dA1dMCIldDK2VVqbl
	P0UA=
X-Gm-Gg: ASbGncs+bgVr9D6ixybZnNR49r4DSFjKy+hQvhYLlHq/ZFRYn3s+jHJLkaufzoHzSwb
	6VpaMxDGb2XbBhqdUSDY4XngeEa5ae6itx83eRsdbFen5FDQzXskvcqPEGlk4WMh/F7Lf2Vdeiu
	r8LKIx0FSRa7EjalM8JDXr/IIlj8hbuE42D9/iQRuXPUhDIKJAPqCDSt3sDf7+G0fmKSxoR65D6
	wbDgcIRpTLd0OchCBeGZ/NDapLhoCRYBaCPRiO4+uY/6f+am+zS4Z3whH1890+/Va+RxKP/4UUv
	yqrrEflS49inXVW+
X-Google-Smtp-Source: AGHT+IETMrofSYLEPqm+RP/18QcDQKxPgPf0K9S0s2exoyNcisanu/oqQzvZN34Puy/4JUsjIT01eg==
X-Received: by 2002:a17:907:96a6:b0:aa6:88ae:22a with SMTP id a640c23a62f3a-aab77ea5c29mr287671166b.37.1734107305699;
        Fri, 13 Dec 2024 08:28:25 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: [PATCH v12 02/12] xen/arm: add initial support for LLC coloring on arm64
Date: Fri, 13 Dec 2024 17:28:05 +0100
Message-ID: <20241213162815.9196-3-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

LLC coloring needs to know the last level cache layout in order to make the
best use of it. This can be probed by inspecting the CLIDR_EL1 register,
so the Last Level is defined as the last level visible by this register.
Note that this excludes system caches in some platforms.

Static memory allocation and cache coloring are incompatible because static
memory can't be guaranteed to use only colors assigned to the domain.
Panic during DomUs creation when both are enabled.

Based on original work from: Luca Miccio 

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
Reviewed-by: Michal Orzel 
Acked-by: Jan Beulich 
---
v12:
- fixed build errors
v11:
- removed useless #define from processor.h
v10:
- moved CONFIG_NUMA check in arch/arm/Kconfig
v9:
- no changes
v8:
- no changes
v7:
- only minor changes
v6:
- get_llc_way_size() now checks for at least separate I/D caches
v5:
- used - instead of _ for filenames
- moved static-mem check in this patch
- moved dom0 colors parsing in next patch
- moved color allocation and configuration in next patch
- moved check_colors() in next patch
- colors are now printed in short form
v4:
- added "llc-coloring" cmdline option for the boot-time switch
- dom0 colors are now checked during domain init as for any other domain
- fixed processor.h masks bit width
- check for overflow in parse_color_config()
- check_colors() now checks also that colors are sorted and unique
---
 docs/misc/cache-coloring.rst         | 14 +++++
 xen/arch/arm/Kconfig                 |  1 +
 xen/arch/arm/Makefile                |  1 +
 xen/arch/arm/dom0less-build.c        |  6 +++
 xen/arch/arm/include/asm/processor.h | 15 ++++++
 xen/arch/arm/llc-coloring.c          | 79 ++++++++++++++++++++++++++++
 xen/arch/arm/setup.c                 |  3 ++
 xen/common/llc-coloring.c            |  4 +-
 xen/include/xen/llc-coloring.h       |  6 +++
 9 files changed, 128 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/arm/llc-coloring.c

diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
index 371f21a0e7..12972dbb2c 100644
--- a/docs/misc/cache-coloring.rst
+++ b/docs/misc/cache-coloring.rst
@@ -113,6 +113,20 @@ Auto-probing of LLC specs
 
 LLC size and number of ways are probed automatically by default.
 
+In the Arm implementation, this is done by inspecting the CLIDR_EL1 register.
+This means that other system caches that aren't visible there are ignored.
+
 LLC specs can be manually set via the above command line parameters. This
 bypasses any auto-probing and it's used to overcome failing situations, such as
 flawed probing logic, or for debugging/testing purposes.
+
+Known issues and limitations
+****************************
+
+"xen,static-mem" isn't supported when coloring is enabled
+#########################################################
+
+In the domain configuration, "xen,static-mem" allows memory to be statically
+allocated to the domain. This isn't possible when LLC coloring is enabled,
+because that memory can't be guaranteed to use only colors assigned to the
+domain.
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 604aba4996..c5e7b74733 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -8,6 +8,7 @@ config ARM_64
 	depends on !ARM_32
 	select 64BIT
 	select HAS_FAST_MULTIPLY
+	select HAS_LLC_COLORING if !NUMA
 
 config ARM
 	def_bool y
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index e4ad1ce851..ccbfc61f88 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_IOREQ_SERVER) += ioreq.o
 obj-y += irq.o
 obj-y += kernel.init.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o
+obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
 obj-$(CONFIG_MEM_ACCESS) += mem_access.o
 obj-y += mm.o
 obj-y += monitor.o
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index f328a044e9..d93a85434e 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -890,7 +891,12 @@ void __init create_domUs(void)
             panic("No more domain IDs available\n");
 
         if ( dt_find_property(node, "xen,static-mem", NULL) )
+        {
+            if ( llc_coloring_enabled )
+                panic("LLC coloring and static memory are incompatible\n");
+
             flags |= CDF_staticmem;
+        }
 
         if ( dt_property_read_bool(node, "direct-map") )
         {
diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h
index 8e02410465..60b587db69 100644
--- a/xen/arch/arm/include/asm/processor.h
+++ b/xen/arch/arm/include/asm/processor.h
@@ -18,6 +18,21 @@
 #define CTR_IDC_SHIFT       28
 #define CTR_DIC_SHIFT       29
 
+/* CCSIDR Current Cache Size ID Register */
+#define CCSIDR_LINESIZE_MASK            _AC(0x7, UL)
+#define CCSIDR_NUMSETS_SHIFT            13
+#define CCSIDR_NUMSETS_MASK             _AC(0x3fff, UL)
+#define CCSIDR_NUMSETS_SHIFT_FEAT_CCIDX 32
+#define CCSIDR_NUMSETS_MASK_FEAT_CCIDX  _AC(0xffffff, UL)
+
+/* CSSELR Cache Size Selection Register */
+#define CSSELR_LEVEL_SHIFT 1
+
+/* CLIDR Cache Level ID Register */
+#define CLIDR_CTYPEn_SHIFT(n) (3 * ((n) - 1))
+#define CLIDR_CTYPEn_MASK     _AC(0x7, UL)
+#define CLIDR_CTYPEn_LEVELS   7
+
 #define ICACHE_POLICY_VPIPT  0
 #define ICACHE_POLICY_AIVIVT 1
 #define ICACHE_POLICY_VIPT   2
diff --git a/xen/arch/arm/llc-coloring.c b/xen/arch/arm/llc-coloring.c
new file mode 100644
index 0000000000..1c7b92bc45
--- /dev/null
+++ b/xen/arch/arm/llc-coloring.c
@@ -0,0 +1,79 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Last Level Cache (LLC) coloring support for ARM
+ *
+ * Copyright (C) 2024, Advanced Micro Devices, Inc.
+ * Copyright (C) 2024, Minerva Systems SRL
+ */
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* Return the LLC way size by probing the hardware */
+unsigned int __init get_llc_way_size(void)
+{
+    register_t ccsidr_el1;
+    register_t clidr_el1 = READ_SYSREG(CLIDR_EL1);
+    register_t csselr_el1 = READ_SYSREG(CSSELR_EL1);
+    register_t id_aa64mmfr2_el1 = READ_SYSREG(ID_AA64MMFR2_EL1);
+    uint32_t ccsidr_numsets_shift = CCSIDR_NUMSETS_SHIFT;
+    uint32_t ccsidr_numsets_mask = CCSIDR_NUMSETS_MASK;
+    unsigned int n, line_size, num_sets;
+
+    for ( n = CLIDR_CTYPEn_LEVELS; n != 0; n-- )
+    {
+        uint8_t ctype_n = (clidr_el1 >> CLIDR_CTYPEn_SHIFT(n)) &
+                           CLIDR_CTYPEn_MASK;
+
+        /* Unified cache (see Arm ARM DDI 0487J.a D19.2.27) */
+        if ( ctype_n == 0b100 )
+            break;
+    }
+
+    if ( n == 0 )
+        return 0;
+
+    WRITE_SYSREG((n - 1) << CSSELR_LEVEL_SHIFT, CSSELR_EL1);
+    isb();
+
+    ccsidr_el1 = READ_SYSREG(CCSIDR_EL1);
+
+    /* Arm ARM: (Log2(Number of bytes in cache line)) - 4 */
+    line_size = 1U << ((ccsidr_el1 & CCSIDR_LINESIZE_MASK) + 4);
+
+    /* If FEAT_CCIDX is enabled, CCSIDR_EL1 has a different bit layout */
+    if ( (id_aa64mmfr2_el1 >> ID_AA64MMFR2_CCIDX_SHIFT) & 0x7 )
+    {
+        ccsidr_numsets_shift = CCSIDR_NUMSETS_SHIFT_FEAT_CCIDX;
+        ccsidr_numsets_mask = CCSIDR_NUMSETS_MASK_FEAT_CCIDX;
+    }
+
+    /* Arm ARM: (Number of sets in cache) - 1 */
+    num_sets = ((ccsidr_el1 >> ccsidr_numsets_shift) & ccsidr_numsets_mask) + 1;
+
+    printk(XENLOG_INFO "LLC found: L%u (line size: %u bytes, sets num: %u)\n",
+           n, line_size, num_sets);
+
+    /* Restore value in CSSELR_EL1 */
+    WRITE_SYSREG(csselr_el1, CSSELR_EL1);
+    isb();
+
+    return line_size * num_sets;
+}
+
+void __init arch_llc_coloring_init(void)
+{
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 2e27af4560..568a49b274 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -326,6 +327,8 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr)
     printk("Command line: %s\n", cmdline);
     cmdline_parse(cmdline);
 
+    llc_coloring_init();
+
     setup_mm();
 
     vm_init();
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index b0fc162b05..78a50c15a7 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -8,6 +8,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define NR_LLC_COLORS          (1U << CONFIG_LLC_COLORS_ORDER)
 
@@ -19,7 +21,7 @@
 static int8_t __initdata opt_llc_coloring = -1;
 boolean_param("llc-coloring", opt_llc_coloring);
 
-static bool __ro_after_init llc_coloring_enabled;
+bool __ro_after_init llc_coloring_enabled;
 
 static unsigned int __initdata llc_size;
 size_param("llc-size", llc_size);
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
index 0acd8d0ad6..a3ebb17186 100644
--- a/xen/include/xen/llc-coloring.h
+++ b/xen/include/xen/llc-coloring.h
@@ -8,13 +8,19 @@
 #ifndef __XEN_LLC_COLORING_H__
 #define __XEN_LLC_COLORING_H__
 
+#include 
+
 struct domain;
 
 #ifdef CONFIG_LLC_COLORING
+extern bool llc_coloring_enabled;
+
 void llc_coloring_init(void);
 void dump_llc_coloring_info(void);
 void domain_dump_llc_colors(const struct domain *d);
 #else
+#define llc_coloring_enabled false
+
 static inline void llc_coloring_init(void) {}
 static inline void dump_llc_coloring_info(void) {}
 static inline void domain_dump_llc_colors(const struct domain *d) {}
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:28:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:28:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856849.1269395 (Exim 4.92)
	(envelope-from )
	id 1tM8Wk-0004jM-J1; Fri, 13 Dec 2024 16:28:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856849.1269395; Fri, 13 Dec 2024 16:28: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 1tM8Wk-0004jB-Dg; Fri, 13 Dec 2024 16:28:30 +0000
Received: by outflank-mailman (input) for mailman id 856849;
 Fri, 13 Dec 2024 16:28: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 1tM8Wi-0003wR-PW
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:28:28 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 486a3e7c-b96f-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 17:28:28 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-a9e8522445dso386860866b.1
 for ; Fri, 13 Dec 2024 08:28:28 -0800 (PST)
Received: from carlo-ubuntu.minervasys.tech ([193.207.202.156])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa673474d96sm841759266b.96.2024.12.13.08.28.25
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 08:28: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: 486a3e7c-b96f-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734107307; x=1734712107; 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=OETE9xbD98S4584ewKKfCkxeqyNzsOb/5grRyUywQEk=;
        b=DVmwM9QxMz2hwnnC5TlNNIHOacwDOpQ2ynqiwqaxu+/e47B75smnNHy6KEsQoBl/Lb
         Mn5sA9U7fhVCnYgwD9q9uKjQKbbKiNC9AuJUhAUmZaqAjkMTCt4HY+6+3Lu8ttav7R/6
         6F7wFySzqBSbE7sQfoACri/Qg1unFy5BCPre6hXOvJefKeKZ51W6QbqhiLq4dNCpBgLk
         QO/K1DSvPsVIANDtxl9B/uRqOE/w1b6tS/HdCA9ztRAgfdOtYiNJDQalvdsdElxhbL2m
         Qfgsd/HuY1rsfG8LR8SIFGbH02z+fBU4fuVh5UfsMJ3lhJgcRod4YH4G6yc0kJkf8zpw
         ApYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734107307; x=1734712107;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=OETE9xbD98S4584ewKKfCkxeqyNzsOb/5grRyUywQEk=;
        b=fg+H0PXBThY7cCg/1pzwtHgXtexgwbH3NUbYykj/6H4gYJDETT1kEiXcUxkfbckUOO
         5TXbIPN5lNLOxVGbMA+gxI98JF3CS9H+37X3CDAeOIwESJXTucwPKNmEaJVCUVURL0hX
         NP13N7xR1w3ZYcAgUf34F8XivfyCYuW7FLBZZGZTRXg3kpbCQd5erqpUKH1YOH8VH5MQ
         GxwOJAa6BIz3Xx7xfDXRmX38mwXFcEyOxOqMJPiKzrDAmSpHCd+1sy88bvbgtu4kZtOU
         W/9WkwjuD6tfDskf2U6gw46zMQUbpHzkp0rZh0O8Au2zf1eU8xP4XKIWI4sQz7ziA2z3
         ZFtQ==
X-Gm-Message-State: AOJu0Yw37dPCN/7jhfmbLw+cTaPzWh2yRBox/V6naPGbRTje+Vq4G/ax
	l5o7ZQMeXWHg3aNqJAILK94jqBaaf1C9+gYzlzhleCLlBtQYs8yU2mN/9ZlH4ELqbt46Kvz+VSf
	tNy8=
X-Gm-Gg: ASbGncsy22Xt2z89em1h/rdfw0n89Nhb0t5oyT/syiNYdBqxNZ/Lr92X55JaNfVVOd7
	eySH/F08olm+uQ2s/RnrgdqRrrtoNGkFtI6Qxt2PTsxtN9EIx/7r//Tn6rkj157zynGGyZPYOCq
	M2A20Jv1mF9s4kRuHLmdfi5FgQcaallgeGNxQGVoCJfOYlcDIs54D661575w3fjVWnxPJtvNeDc
	zchY5MRMz8ppgc81iiWqeig6oYbZsxex8BrjNPnQKDFe7IjZjMrlGjMX38JGTl5LAqOW2UNMvgs
	WeaGFFunFgIV9lxr
X-Google-Smtp-Source: AGHT+IEcx2gZe58o1gLiYKKiwDXlXjo9jbU9N+hkp7pJ6yTyKRURflePtFEgjWjcbIG7Ja4cNVJLFg==
X-Received: by 2002:a17:906:7952:b0:aa6:7438:2a30 with SMTP id a640c23a62f3a-aab779c7204mr448090766b.29.1734107307367;
        Fri, 13 Dec 2024 08:28:27 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v12 03/12] xen/arm: permit non direct-mapped Dom0 construction
Date: Fri, 13 Dec 2024 17:28:06 +0100
Message-ID: <20241213162815.9196-4-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Cache coloring requires Dom0 not to be direct-mapped because of its non
contiguous mapping nature, so allocate_memory() is needed in this case.
8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a separate module")
moved allocate_memory() in dom0less_build.c. In order to use it
in Dom0 construction bring it back to domain_build.c and declare it in
domain_build.h.

Adapt the implementation of allocate_memory() so that it uses the host
layout when called on the hwdom, via find_unallocated_memory(). Take the
opportunity to keep the parameter order consistent with
rangeset_report_ranges() and move the membanks struct after the callback
function in find_unallocated_memory().

Introduce add_hwdom_free_regions() callback to add hwdom banks in descending
order.

Signed-off-by: Carlo Nonato 
---
v12:
- used the new generic find_unallocated_memory()
- added add_hwdom_free_regions() callback
v11:
- GUEST_RAM_BANKS instead of hardcoding the number of banks in allocate_memory()
- hwdom_ext_regions -> hwdom_free_mem in allocate_memory()
- added a comment in allocate_memory() when skipping small banks
v10:
- fixed a compilation bug that happened when dom0less support was disabled
v9:
- no changes
v8:
- patch adapted to new changes to allocate_memory()
v7:
- allocate_memory() now uses the host layout when called on the hwdom
v6:
- new patch
---
 xen/arch/arm/dom0less-build.c           |  44 -------
 xen/arch/arm/domain_build.c             | 164 +++++++++++++++++++++++-
 xen/arch/arm/include/asm/domain_build.h |   4 +
 3 files changed, 161 insertions(+), 51 deletions(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index d93a85434e..67b1503647 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -49,50 +49,6 @@ bool __init is_dom0less_mode(void)
     return ( !dom0found && domUfound );
 }
 
-static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
-{
-    struct membanks *mem = kernel_info_get_mem(kinfo);
-    unsigned int i;
-    paddr_t bank_size;
-
-    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
-           /* Don't want format this as PRIpaddr (16 digit hex) */
-           (unsigned long)(kinfo->unassigned_mem >> 20), d);
-
-    mem->nr_banks = 0;
-    bank_size = MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem);
-    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM0_BASE),
-                               bank_size) )
-        goto fail;
-
-    bank_size = MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem);
-    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM1_BASE),
-                               bank_size) )
-        goto fail;
-
-    if ( kinfo->unassigned_mem )
-        goto fail;
-
-    for( i = 0; i < mem->nr_banks; i++ )
-    {
-        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
-               d,
-               i,
-               mem->bank[i].start,
-               mem->bank[i].start + mem->bank[i].size,
-               /* Don't want format this as PRIpaddr (16 digit hex) */
-               (unsigned long)(mem->bank[i].size >> 20));
-    }
-
-    return;
-
-fail:
-    panic("Failed to allocate requested domain memory."
-          /* Don't want format this as PRIpaddr (16 digit hex) */
-          " %ldKB unallocated. Fix the VMs configurations.\n",
-          (unsigned long)kinfo->unassigned_mem >> 10);
-}
-
 #ifdef CONFIG_VGICV2
 static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
 {
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index adf26f2778..bfcff99194 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -416,7 +417,6 @@ static void __init allocate_memory_11(struct domain *d,
     }
 }
 
-#ifdef CONFIG_DOM0LESS_BOOT
 bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size,
                                     alloc_domheap_mem_cb cb, void *extra)
 {
@@ -508,7 +508,6 @@ bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
 
     return true;
 }
-#endif
 
 /*
  * When PCI passthrough is available we want to keep the
@@ -900,6 +899,52 @@ int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
     return 0;
 }
 
+static int __init add_hwdom_free_regions(unsigned long s_gfn,
+                                         unsigned long e_gfn, void *data)
+{
+    struct membanks *free_regions = data;
+    paddr_t start, size;
+    paddr_t s = pfn_to_paddr(s_gfn);
+    paddr_t e = pfn_to_paddr(e_gfn);
+    unsigned int i, j;
+
+    if ( free_regions->nr_banks >= free_regions->max_banks )
+        return 0;
+
+    /*
+     * Both start and size of the free region should be 2MB aligned to
+     * potentially allow superpage mapping.
+     */
+    start = (s + SZ_2M - 1) & ~(SZ_2M - 1);
+    if ( start > e )
+        return 0;
+
+    /*
+     * e is actually "end-1" because it is called by rangeset functions
+     * which are inclusive of the last address.
+     */
+    e += 1;
+    size = (e - start) & ~(SZ_2M - 1);
+
+    /* Find the insert position (descending order). */
+    for ( i = 0; i < free_regions->nr_banks ; i++)
+        if ( size > free_regions->bank[i].size )
+            break;
+
+    /* Move the other banks to make space. */
+    for ( j = free_regions->nr_banks; j > i ; j-- )
+    {
+        free_regions->bank[j].start = free_regions->bank[j - 1].start;
+        free_regions->bank[j].size = free_regions->bank[j - 1].size;
+    }
+
+    free_regions->bank[i].start = start;
+    free_regions->bank[i].size = size;
+    free_regions->nr_banks++;
+
+    return 0;
+}
+
 /*
  * Find unused regions of Host address space which can be exposed to domain
  * using the host memory layout. In order to calculate regions we exclude every
@@ -908,10 +953,10 @@ int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
 static int __init find_unallocated_memory(const struct kernel_info *kinfo,
                                           const struct membanks *mem_banks[],
                                           unsigned int nr_mem_banks,
-                                          struct membanks *free_regions,
                                           int (*cb)(unsigned long s_gfn,
                                                     unsigned long e_gfn,
-                                                    void *data))
+                                                    void *data),
+                                          struct membanks *free_regions)
 {
     const struct membanks *mem = bootinfo_get_mem();
     struct rangeset *unalloc_mem;
@@ -977,6 +1022,108 @@ out:
     return res;
 }
 
+void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
+{
+    struct membanks *mem = kernel_info_get_mem(kinfo);
+    unsigned int i, nr_banks = GUEST_RAM_BANKS;
+    struct membanks *hwdom_free_mem = NULL;
+
+    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
+           /* Don't want format this as PRIpaddr (16 digit hex) */
+           (unsigned long)(kinfo->unassigned_mem >> 20), d);
+
+    mem->nr_banks = 0;
+    /*
+     * Use host memory layout for hwdom. Only case for this is when LLC coloring
+     * is enabled.
+     */
+    if ( is_hardware_domain(d) )
+    {
+        struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1);
+        /*
+         * Exclude the following regions:
+         * 1) Remove reserved memory
+         * 2) Grant table assigned to Dom0
+         */
+        const struct membanks *mem_banks[] = {
+            bootinfo_get_reserved_mem(),
+            gnttab,
+        };
+
+        ASSERT(llc_coloring_enabled);
+
+        if ( !gnttab )
+            goto fail;
+
+        gnttab->nr_banks = 1;
+        gnttab->bank[0].start = kinfo->gnttab_start;
+        gnttab->bank[0].size = kinfo->gnttab_start + kinfo->gnttab_size;
+
+        hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank,
+                                             NR_MEM_BANKS);
+        if ( !hwdom_free_mem )
+            goto fail;
+
+        hwdom_free_mem->max_banks = NR_MEM_BANKS;
+
+        if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
+                                     add_hwdom_free_regions, hwdom_free_mem) )
+            goto fail;
+
+        nr_banks = hwdom_free_mem->nr_banks;
+        xfree(gnttab);
+    }
+
+    for ( i = 0; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_banks-- )
+    {
+        paddr_t bank_start, bank_size;
+
+        if ( is_hardware_domain(d) )
+        {
+            bank_start = hwdom_free_mem->bank[i].start;
+            bank_size = hwdom_free_mem->bank[i].size;
+        }
+        else
+        {
+            const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
+            const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
+
+            if ( i >= GUEST_RAM_BANKS )
+                goto fail;
+
+            bank_start = bankbase[i];
+            bank_size = banksize[i];
+        }
+
+        bank_size = MIN(bank_size, kinfo->unassigned_mem);
+        if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(bank_start), bank_size) )
+            goto fail;
+    }
+
+    if ( kinfo->unassigned_mem )
+        goto fail;
+
+    for( i = 0; i < mem->nr_banks; i++ )
+    {
+        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
+               d,
+               i,
+               mem->bank[i].start,
+               mem->bank[i].start + mem->bank[i].size,
+               /* Don't want format this as PRIpaddr (16 digit hex) */
+               (unsigned long)(mem->bank[i].size >> 20));
+    }
+
+    xfree(hwdom_free_mem);
+    return;
+
+fail:
+    panic("Failed to allocate requested domain memory."
+          /* Don't want format this as PRIpaddr (16 digit hex) */
+          " %ldKB unallocated. Fix the VMs configurations.\n",
+          (unsigned long)kinfo->unassigned_mem >> 10);
+}
+
 static int __init handle_pci_range(const struct dt_device_node *dev,
                                    uint64_t addr, uint64_t len, void *data)
 {
@@ -1176,7 +1323,7 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
     gnttab->bank[0].size = kinfo->gnttab_size;
 
     res = find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
-                                  ext_regions, add_ext_regions);
+                                  add_ext_regions, ext_regions);
     xfree(gnttab);
 
     return res;
@@ -1235,7 +1382,7 @@ int __init make_hypervisor_node(struct domain *d,
 
         ext_regions->max_banks = NR_MEM_BANKS;
 
-        if ( is_domain_direct_mapped(d) )
+        if ( domain_use_host_layout(d) )
         {
             if ( !is_iommu_enabled(d) )
                 res = find_host_extended_regions(kinfo, ext_regions);
@@ -2164,8 +2311,11 @@ static int __init construct_dom0(struct domain *d)
     /* type must be set before allocate_memory */
     d->arch.type = kinfo.type;
 #endif
-    allocate_memory_11(d, &kinfo);
     find_gnttab_region(d, &kinfo);
+    if ( is_domain_direct_mapped(d) )
+        allocate_memory_11(d, &kinfo);
+    else
+        allocate_memory(d, &kinfo);
 
     rc = process_shm_chosen(d, &kinfo);
     if ( rc < 0 )
diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h
index e712afbc7f..b0d646e173 100644
--- a/xen/arch/arm/include/asm/domain_build.h
+++ b/xen/arch/arm/include/asm/domain_build.h
@@ -11,6 +11,7 @@ bool allocate_domheap_memory(struct domain *d, paddr_t tot_size,
                              alloc_domheap_mem_cb cb, void *extra);
 bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
                           paddr_t tot_size);
+void allocate_memory(struct domain *d, struct kernel_info *kinfo);
 int construct_domain(struct domain *d, struct kernel_info *kinfo);
 int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
 int make_chosen_node(const struct kernel_info *kinfo);
@@ -54,6 +55,9 @@ static inline int prepare_acpi(struct domain *d, struct kernel_info *kinfo)
 int prepare_acpi(struct domain *d, struct kernel_info *kinfo);
 #endif
 
+typedef int (*add_free_regions_fn)(unsigned long s_gfn, unsigned long e_gfn,
+                                   void *data);
+
 int add_ext_regions(unsigned long s_gfn, unsigned long e_gfn, void *data);
 
 #endif
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:28:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:28:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856850.1269404 (Exim 4.92)
	(envelope-from )
	id 1tM8Wl-00050e-V6; Fri, 13 Dec 2024 16:28:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856850.1269404; Fri, 13 Dec 2024 16:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tM8Wl-00050P-SB; Fri, 13 Dec 2024 16:28:31 +0000
Received: by outflank-mailman (input) for mailman id 856850;
 Fri, 13 Dec 2024 16:28: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 1tM8Wk-0003wR-Mg
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:28:30 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 49909045-b96f-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 17:28:30 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-aa6aee68a57so291062666b.3
 for ; Fri, 13 Dec 2024 08:28:30 -0800 (PST)
Received: from carlo-ubuntu.minervasys.tech ([193.207.202.156])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa673474d96sm841759266b.96.2024.12.13.08.28.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 08:28: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: 49909045-b96f-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734107309; x=1734712109; 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=sFD4/otmPlpgzMGg8v7puJ0h1cJQAWQfjG2jho9su4o=;
        b=OvLlQeYoMIj8E8MmaHjm82ncBrWUntu/ATAwuwGKQexr15kBAhERAXoRM5mNexQaeP
         vzo9iDJqclQBttIBnMYnwTItF3GTlafrb57+uh6qNccb/r9XY8AAXRcclaRwMF34GFr5
         bGu0iwENHN448LUhd7520PoFFYNIhudvWuE7zL92ULs3f1HMawmjyopZsLX+WGyJ/5BT
         ujgVXNLiaSzDBAIfaBJT0Rlbt4VO5m+mRvYOoG2Z5rR+XG58pNGKns1QXUzxzyPPxNjZ
         dzEdjZqynAlU+C0sb6VHhCmyv2omHzu0mOGiSHWnpAWqWKjIiftPUCniw0SwJ15tDlno
         ex1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734107309; x=1734712109;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=sFD4/otmPlpgzMGg8v7puJ0h1cJQAWQfjG2jho9su4o=;
        b=f2Q1+n8yYtv5RsG3RTZw7vFAqfOlt2W/o4B6BaryftJlfbpuCVIDdxzKqjyjBk8HGs
         BXIuBuIKUGLg5f5xMMaYtWlbove2paN0MsLsaRuHv+BbhcF1NE2/CM73ZAlY/KJG3EmU
         mp0ohxmD7gP5ak3GvuE/xTUaEgmMeBozjUyv6rrTtP8wtD+pwZpo3RQ4Wc/iiVncLkZY
         RD5uhDQzDUHyvMFpQLT0bpIMf+SB7etEmBoHqzifutY8V2xvU+cvp1RXxsbulROB5ZuO
         bBsz9XSM/CRfGzNDjYHYpoTMhqzvm4aXso+BxSU4X/q9vp+IPOjIReEEwqJUxzPw1zQp
         67lQ==
X-Gm-Message-State: AOJu0YzPoEEcnCwBSvZ0nrOf0yeTETLcuQpj8DhjuWfiQ0vOGcRqsOtg
	TDBvVyGLi0Sts3SZO/XMR4C57ihfoh3zYDu2SXZhE78rqxo3dgQ6F7x0Mt+6cjT5q3iL4NFa4bE
	o/rw=
X-Gm-Gg: ASbGncsLHuNGuwjGy8qvhJZNAmrEtNhWVgvYj2JqCNz5UoZGaIDmDnGtnSWDT3nN+iR
	VicMbQ+FN7hRGBZfMpLXjdZ+fLNbexevLntjrmLroFfB2BVfMSubIFTId88B6PSQHxViZSupuhg
	MqKhv+5dmnx3a0+q/n/OS5tXeBa0hg1urIBZp5DI73mHIa6FVon9wIDTYZ4Ig8lsc6TZk18wFX+
	aETu8tJV0pu+Nwab9FqczJHDILa2bzscy7lyEd1beHHXHFF6MJpJA5/IEzaaiZ5nIQBslRONRcm
	01Wojjq1g5LjZs/z
X-Google-Smtp-Source: AGHT+IGNIJkZzVMpAqUGf1C+5+Vp3SD/XGAGPAJTPJOU7edrzGVEySLsPzi7s6m5CcvyMvSd5TRKkQ==
X-Received: by 2002:a17:907:3f1b:b0:aa6:7165:504b with SMTP id a640c23a62f3a-aab779b3ff3mr408116366b.31.1734107309284;
        Fri, 13 Dec 2024 08:28:29 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: [PATCH v12 04/12] xen/arm: add Dom0 cache coloring support
Date: Fri, 13 Dec 2024 17:28:07 +0100
Message-ID: <20241213162815.9196-5-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add a command line parameter to allow the user to set the coloring
configuration for Dom0.
A common configuration syntax for cache colors is introduced and
documented.
Take the opportunity to also add:
 - default configuration notion.
 - function to check well-formed configurations.

Direct mapping Dom0 isn't possible when coloring is enabled, so
CDF_directmap flag is removed when creating it.

Based on original work from: Luca Miccio 

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
Reviewed-by: Jan Beulich 
Reviewed-by: Michal Orzel 
---
v12:
- no changes
v11:
- minor changes
v10:
- fixed array type for colors parameter in check_colors()
v9:
- moved domain_llc_coloring_free() in next patch cause it's never used for dom0
v8:
- added bound check on dom0_num_colors
- default colors array set just once
v7:
- parse_color_config() doesn't accept leading/trailing commas anymore
- removed alloc_colors() helper
v6:
- moved domain_llc_coloring_free() in this patch
- removed domain_alloc_colors() in favor of a more explicit allocation
- parse_color_config() now accepts the size of the array to be filled
- allocate_memory() moved in another patch
v5:
- Carlo Nonato as the new author
- moved dom0 colors parsing (parse_colors()) in this patch
- added dom0_set_llc_colors() to set dom0 colors after creation
- moved color allocation and checking in this patch
- error handling when allocating color arrays
- FIXME: copy pasted allocate_memory() cause it got moved
v4:
- dom0 colors are dynamically allocated as for any other domain
  (colors are duplicated in dom0_colors and in the new array, but logic
  is simpler)
---
 docs/misc/cache-coloring.rst      |  29 ++++++++
 docs/misc/xen-command-line.pandoc |   9 +++
 xen/arch/arm/domain_build.c       |   9 ++-
 xen/common/llc-coloring.c         | 120 +++++++++++++++++++++++++++++-
 xen/include/xen/llc-coloring.h    |   1 +
 5 files changed, 166 insertions(+), 2 deletions(-)

diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
index 12972dbb2c..7b47d0ed92 100644
--- a/docs/misc/cache-coloring.rst
+++ b/docs/misc/cache-coloring.rst
@@ -107,6 +107,35 @@ Specific documentation is available at `docs/misc/xen-command-line.pandoc`.
 +----------------------+-------------------------------+
 | ``llc-nr-ways``      | Set the LLC number of ways    |
 +----------------------+-------------------------------+
+| ``dom0-llc-colors``  | Dom0 color configuration      |
++----------------------+-------------------------------+
+
+Colors selection format
+***********************
+
+Regardless of the memory pool that has to be colored (Xen, Dom0/DomUs),
+the color selection can be expressed using the same syntax. In particular a
+comma-separated list of colors or ranges of colors is used.
+Ranges are hyphen-separated intervals (such as `0-4`) and are inclusive on both
+sides.
+
+Note that:
+
+- no spaces are allowed between values.
+- no overlapping ranges or duplicated colors are allowed.
+- values must be written in ascending order.
+
+Examples:
+
++-------------------+-----------------------------+
+| **Configuration** | **Actual selection**        |
++-------------------+-----------------------------+
+| 1-2,5-8           | [1, 2, 5, 6, 7, 8]          |
++-------------------+-----------------------------+
+| 4-8,10,11,12      | [4, 5, 6, 7, 8, 10, 11, 12] |
++-------------------+-----------------------------+
+| 0                 | [0]                         |
++-------------------+-----------------------------+
 
 Auto-probing of LLC specs
 #########################
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index abd8dae96f..bfdc8b0002 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -963,6 +963,15 @@ Controls for the dom0 IOMMU setup.
 
 Specify a list of IO ports to be excluded from dom0 access.
 
+### dom0-llc-colors (arm64)
+> `= List of [  | - ]`
+
+> Default: `All available LLC colors`
+
+Specify dom0 LLC color configuration. This option is available only when
+`CONFIG_LLC_COLORING` is enabled. If the parameter is not set, all available
+colors are used.
+
 ### dom0_max_vcpus
 
 Either:
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index bfcff99194..d7c9be4c4b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2358,6 +2358,7 @@ void __init create_dom0(void)
         .max_maptrack_frames = -1,
         .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
     };
+    unsigned int flags = CDF_privileged;
     int rc;
 
     /* The vGIC for DOM0 is exactly emulating the hardware GIC */
@@ -2385,10 +2386,16 @@ void __init create_dom0(void)
             panic("SVE vector length error\n");
     }
 
-    dom0 = domain_create(0, &dom0_cfg, CDF_privileged | CDF_directmap);
+    if ( !llc_coloring_enabled )
+        flags |= CDF_directmap;
+
+    dom0 = domain_create(0, &dom0_cfg, flags);
     if ( IS_ERR(dom0) )
         panic("Error creating domain 0 (rc = %ld)\n", PTR_ERR(dom0));
 
+    if ( llc_coloring_enabled && (rc = dom0_set_llc_colors(dom0)) )
+        panic("Error initializing LLC coloring for domain 0 (rc = %d)\n", rc);
+
     if ( alloc_dom0_vcpu0(dom0) == NULL )
         panic("Error creating domain 0 vcpu0\n");
 
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index 78a50c15a7..1eb733285e 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -29,6 +29,66 @@ static unsigned int __initdata llc_nr_ways;
 integer_param("llc-nr-ways", llc_nr_ways);
 /* Number of colors available in the LLC */
 static unsigned int __ro_after_init max_nr_colors;
+/* Default coloring configuration */
+static unsigned int __ro_after_init default_colors[NR_LLC_COLORS];
+
+static unsigned int __initdata dom0_colors[NR_LLC_COLORS];
+static unsigned int __initdata dom0_num_colors;
+
+/*
+ * Parse the coloring configuration given in the buf string, following the
+ * syntax below.
+ *
+ * COLOR_CONFIGURATION ::= COLOR | RANGE,...,COLOR | RANGE
+ * RANGE               ::= COLOR-COLOR
+ *
+ * Example: "0,2-6,15-16" represents the set of colors: 0,2,3,4,5,6,15,16.
+ */
+static int __init parse_color_config(const char *buf, unsigned int colors[],
+                                     unsigned int max_num_colors,
+                                     unsigned int *num_colors)
+{
+    const char *s = buf;
+
+    *num_colors = 0;
+
+    while ( *s != '\0' )
+    {
+        unsigned int color, start, end;
+
+        start = simple_strtoul(s, &s, 0);
+
+        if ( *s == '-' )    /* Range */
+        {
+            s++;
+            end = simple_strtoul(s, &s, 0);
+        }
+        else                /* Single value */
+            end = start;
+
+        if ( start > end || (end - start) > (UINT_MAX - *num_colors) ||
+             (*num_colors + (end - start)) >= max_num_colors )
+            return -EINVAL;
+
+        /* Colors are range checked in check_colors() */
+        for ( color = start; color <= end; color++ )
+            colors[(*num_colors)++] = color;
+
+        if ( *s == ',' )
+            s++;
+        else if ( *s != '\0' )
+            break;
+    }
+
+    return *s ? -EINVAL : 0;
+}
+
+static int __init parse_dom0_colors(const char *s)
+{
+    return parse_color_config(s, dom0_colors, ARRAY_SIZE(dom0_colors),
+                              &dom0_num_colors);
+}
+custom_param("dom0-llc-colors", parse_dom0_colors);
 
 static void print_colors(const unsigned int colors[], unsigned int num_colors)
 {
@@ -53,9 +113,27 @@ static void print_colors(const unsigned int colors[], unsigned int num_colors)
     printk(" }\n");
 }
 
+static bool __init check_colors(const unsigned int colors[],
+                                unsigned int num_colors)
+{
+    unsigned int i;
+
+    for ( i = 0; i < num_colors; i++ )
+    {
+        if ( colors[i] >= max_nr_colors )
+        {
+            printk(XENLOG_ERR "LLC color %u >= %u (max allowed)\n", colors[i],
+                   max_nr_colors);
+            return false;
+        }
+    }
+
+    return true;
+}
+
 void __init llc_coloring_init(void)
 {
-    unsigned int way_size;
+    unsigned int way_size, i;
 
     llc_coloring_enabled = (opt_llc_coloring == 1);
     if ( (opt_llc_coloring != 0) && llc_size && llc_nr_ways )
@@ -94,6 +172,9 @@ void __init llc_coloring_init(void)
     else if ( max_nr_colors < 2 )
         panic("Number of LLC colors %u < 2\n", max_nr_colors);
 
+    for ( i = 0; i < max_nr_colors; i++ )
+        default_colors[i] = i;
+
     arch_llc_coloring_init();
 }
 
@@ -115,6 +196,43 @@ void domain_dump_llc_colors(const struct domain *d)
     print_colors(d->llc_colors, d->num_llc_colors);
 }
 
+static void __init domain_set_default_colors(struct domain *d)
+{
+    printk(XENLOG_WARNING
+           "LLC color config not found for %pd, using all colors\n", d);
+
+    d->llc_colors = default_colors;
+    d->num_llc_colors = max_nr_colors;
+}
+
+int __init dom0_set_llc_colors(struct domain *d)
+{
+    typeof(*dom0_colors) *colors;
+
+    if ( !dom0_num_colors )
+    {
+        domain_set_default_colors(d);
+        return 0;
+    }
+
+    if ( (dom0_num_colors > max_nr_colors) ||
+         !check_colors(dom0_colors, dom0_num_colors) )
+    {
+        printk(XENLOG_ERR "%pd:  bad LLC color config\n", d);
+        return -EINVAL;
+    }
+
+    colors = xmalloc_array(typeof(*dom0_colors), dom0_num_colors);
+    if ( !colors )
+        return -ENOMEM;
+
+    memcpy(colors, dom0_colors, sizeof(*colors) * dom0_num_colors);
+    d->llc_colors = colors;
+    d->num_llc_colors = dom0_num_colors;
+
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
index a3ebb17186..d29ebeb4c5 100644
--- a/xen/include/xen/llc-coloring.h
+++ b/xen/include/xen/llc-coloring.h
@@ -28,6 +28,7 @@ static inline void domain_dump_llc_colors(const struct domain *d) {}
 
 unsigned int get_llc_way_size(void);
 void arch_llc_coloring_init(void);
+int dom0_set_llc_colors(struct domain *d);
 
 #endif /* __XEN_LLC_COLORING_H__ */
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:28:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:28:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856854.1269415 (Exim 4.92)
	(envelope-from )
	id 1tM8Wp-0005Lq-7h; Fri, 13 Dec 2024 16:28:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856854.1269415; Fri, 13 Dec 2024 16:28: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 1tM8Wp-0005Lj-41; Fri, 13 Dec 2024 16:28:35 +0000
Received: by outflank-mailman (input) for mailman id 856854;
 Fri, 13 Dec 2024 16:28: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 1tM8Wn-0003wJ-My
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:28:33 +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 4adafeec-b96f-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 17:28:32 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-5d0ac27b412so2739946a12.1
 for ; Fri, 13 Dec 2024 08:28:32 -0800 (PST)
Received: from carlo-ubuntu.minervasys.tech ([193.207.202.156])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa673474d96sm841759266b.96.2024.12.13.08.28.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 08:28: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: 4adafeec-b96f-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734107311; x=1734712111; 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=9mv5REGWn6ITbuAUP9LZySGEqnq/G3R/fSnXpuq2iqc=;
        b=c8U+9A1nPCz4dWS6bZz94mUkfJMCCiSZ+vUT8t2KrE4SJ53VLX2JuhSDbHhq6zUU85
         sjLExwKQoV3X+6smW9cfT1hVqwXi4OL7c8T7lF0UyDDAd74vI2hBkN1mWYVWNAKbYKAg
         75YjAdSfgNPeZsUZqCsO0rfWSH0SgpUlsQAI/kD5ImG4P1PEOJvz9v0n20XWVqiCQCQh
         jkBh1U5E0a8dHmx/GDpgNKNP4PGhkUXuCBwuIANkEuB84ueFaSS8ohuUN3bJmTAE7iDN
         a7P2MpaYF8LrHjXMh37rB3Wcg4Kq569Tra9RDn3/ukzOOSAIVxO3zmzvGBB1Ib5Ttozj
         6jSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734107311; x=1734712111;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=9mv5REGWn6ITbuAUP9LZySGEqnq/G3R/fSnXpuq2iqc=;
        b=btsd31E0N7Cb0Vg+HUUDRd9bQ+y9lcTenIENWi4RAiuPV4gV7jWwotqtkBLi+L9PLg
         qacayBX2Eyv8yIz+EOxXBKkji+JBduYvaOkVro22m2rkeyHVXC4h8WfAmrWfaKsRnM4M
         KEQ5Ee/VXSBVeqGLUFRhuxGQTrySXY2QodKvcqCaZmnoFRFqHZPzomUwmD3ppoTRGyRW
         bktYcHRPu5Hx4Ji1Y0MWzqCB4a0DoS/+6gYO2KbjHdCvmiycRhwFuZyJ/wm8CWPTYsx2
         c3whQP6PVMY9JSwQb/jgffnpLz6xOHgxPejZjie75l1Xt371fC2UkVI04diPnWj0QYZR
         NJRQ==
X-Gm-Message-State: AOJu0YwkIj4KaHbgYmONDobcHUdShApU0FfaBRZNJVNXArKjZNWGWgXV
	Wa5jYdcEVhP/RWWBbFBVmA1+NFvz86AYjXoOU15vKDYDj70B+GXZ+0k4oWpPNV3CfFrR1zkyt+a
	Io/8=
X-Gm-Gg: ASbGncsbByrhTbopTCKajmsmO7oWxHIkIC8KemDAooyMwyQzKtEJHfaWpKp4qgWyc8Z
	wOFcunoD8Fobv7v2y6W1RIHsZvhATSlRyyfDAaWDkcwCD9cciPOkQ7+Qh5/bjTugtzqiF3u8/Nr
	H1fKaELNxxVmsgcAjV/2Ct5F8jZGkMT2A7Bf7k5yn1eECmf8geiakKkQjusjqzbD+ttTbkTIkB7
	jN69dD7Ok9dpUZNMF9zLYzVYCJQ37p4qY4MNCeQfGGqIdo175b/PJ+rsA6J2srEpJN/ANTbLDK5
	b4CmMRHpmfoYNZuR
X-Google-Smtp-Source: AGHT+IHLvy+xSQ6XzQpoGWPxGKXwZQaj6T50KXQYfEs2Ftvx/fAc8we8jDrgCSlT5a1VjeryysAZgw==
X-Received: by 2002:a17:906:6bd4:b0:aab:9268:2626 with SMTP id a640c23a62f3a-aab92682666mr54602166b.25.1734107311184;
        Fri, 13 Dec 2024 08:28:31 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v12 05/12] xen: extend domctl interface for cache coloring
Date: Fri, 13 Dec 2024 17:28:08 +0100
Message-ID: <20241213162815.9196-6-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add a new domctl hypercall to allow the user to set LLC coloring
configurations. Colors can be set only once, just after domain creation,
since recoloring isn't supported.

Based on original work from: Luca Miccio 

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
Reviewed-by: Jan Beulich 
---
v12:
- no changes
v11:
- minor changes
v10:
- fixed array type for colors parameter in check_colors()
v9:
- moved domain_llc_coloring_free() in next patch cause it's never used for dom0
v8:
- added bound check on dom0_num_colors
- default colors array set just once
v7:
- parse_color_config() doesn't accept leading/trailing commas anymore
- removed alloc_colors() helper
v6:
- moved domain_llc_coloring_free() in this patch
- removed domain_alloc_colors() in favor of a more explicit allocation
- parse_color_config() now accepts the size of the array to be filled
- allocate_memory() moved in another patch
v5:
- Carlo Nonato as the new author
- moved dom0 colors parsing (parse_colors()) in this patch
- added dom0_set_llc_colors() to set dom0 colors after creation
- moved color allocation and checking in this patch
- error handling when allocating color arrays
- FIXME: copy pasted allocate_memory() cause it got moved
v4:
- dom0 colors are dynamically allocated as for any other domain
  (colors are duplicated in dom0_colors and in the new array, but logic
  is simpler)
---
 xen/common/domain.c            |  3 ++
 xen/common/domctl.c            | 10 +++++++
 xen/common/llc-coloring.c      | 55 ++++++++++++++++++++++++++++++++--
 xen/include/public/domctl.h    |  9 ++++++
 xen/include/xen/llc-coloring.h |  5 ++++
 5 files changed, 79 insertions(+), 3 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 92263a4fbd..842a23751a 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1276,6 +1277,8 @@ void domain_destroy(struct domain *d)
 {
     BUG_ON(!d->is_dying);
 
+    domain_llc_coloring_free(d);
+
     /* May be already destroyed, or get_domain() can race us. */
     if ( atomic_cmpxchg(&d->refcnt, 0, DOMAIN_DESTROYED) != 0 )
         return;
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index ea16b75910..6387dddbcd 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -866,6 +867,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
                 __HYPERVISOR_domctl, "h", u_domctl);
         break;
 
+    case XEN_DOMCTL_set_llc_colors:
+        if ( op->u.set_llc_colors.pad )
+            ret = -EINVAL;
+        else if ( llc_coloring_enabled )
+            ret = domain_set_llc_colors(d, &op->u.set_llc_colors);
+        else
+            ret = -EOPNOTSUPP;
+        break;
+
     default:
         ret = arch_do_domctl(op, d, u_domctl);
         break;
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index 1eb733285e..d7d797e4d2 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -5,6 +5,7 @@
  * Copyright (C) 2024, Advanced Micro Devices, Inc.
  * Copyright (C) 2024, Minerva Systems SRL
  */
+#include 
 #include 
 #include 
 #include 
@@ -113,8 +114,7 @@ static void print_colors(const unsigned int colors[], unsigned int num_colors)
     printk(" }\n");
 }
 
-static bool __init check_colors(const unsigned int colors[],
-                                unsigned int num_colors)
+static bool check_colors(const unsigned int colors[], unsigned int num_colors)
 {
     unsigned int i;
 
@@ -196,7 +196,7 @@ void domain_dump_llc_colors(const struct domain *d)
     print_colors(d->llc_colors, d->num_llc_colors);
 }
 
-static void __init domain_set_default_colors(struct domain *d)
+static void domain_set_default_colors(struct domain *d)
 {
     printk(XENLOG_WARNING
            "LLC color config not found for %pd, using all colors\n", d);
@@ -233,6 +233,55 @@ int __init dom0_set_llc_colors(struct domain *d)
     return 0;
 }
 
+int domain_set_llc_colors(struct domain *d,
+                          const struct xen_domctl_set_llc_colors *config)
+{
+    unsigned int *colors;
+
+    if ( d->num_llc_colors )
+        return -EEXIST;
+
+    if ( !config->num_llc_colors )
+    {
+        domain_set_default_colors(d);
+        return 0;
+    }
+
+    if ( config->num_llc_colors > max_nr_colors )
+        return -EINVAL;
+
+    colors = xmalloc_array(unsigned int, config->num_llc_colors);
+    if ( !colors )
+        return -ENOMEM;
+
+    if ( copy_from_guest(colors, config->llc_colors, config->num_llc_colors) )
+    {
+        xfree(colors);
+        return -EFAULT;
+    }
+
+    if ( !check_colors(colors, config->num_llc_colors) )
+    {
+        printk(XENLOG_ERR "%pd: bad LLC color config\n", d);
+        xfree(colors);
+        return -EINVAL;
+    }
+
+    d->llc_colors = colors;
+    d->num_llc_colors = config->num_llc_colors;
+
+    return 0;
+}
+
+void domain_llc_coloring_free(struct domain *d)
+{
+    if ( !llc_coloring_enabled || d->llc_colors == default_colors )
+        return;
+
+    /* free pointer-to-const using __va(__pa()) */
+    xfree(__va(__pa(d->llc_colors)));
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 353f831e40..e2d392d1e5 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1236,6 +1236,13 @@ struct xen_domctl_dt_overlay {
 };
 #endif
 
+struct xen_domctl_set_llc_colors {
+    /* IN LLC coloring parameters */
+    uint32_t num_llc_colors;
+    uint32_t pad;
+    XEN_GUEST_HANDLE_64(uint32) llc_colors;
+};
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -1325,6 +1332,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_set_paging_mempool_size       86
 #define XEN_DOMCTL_dt_overlay                    87
 #define XEN_DOMCTL_gsi_permission                88
+#define XEN_DOMCTL_set_llc_colors                89
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1391,6 +1399,7 @@ struct xen_domctl {
 #if defined(__arm__) || defined(__aarch64__)
         struct xen_domctl_dt_overlay        dt_overlay;
 #endif
+        struct xen_domctl_set_llc_colors    set_llc_colors;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
index d29ebeb4c5..26353c808a 100644
--- a/xen/include/xen/llc-coloring.h
+++ b/xen/include/xen/llc-coloring.h
@@ -11,6 +11,7 @@
 #include 
 
 struct domain;
+struct xen_domctl_set_llc_colors;
 
 #ifdef CONFIG_LLC_COLORING
 extern bool llc_coloring_enabled;
@@ -18,17 +19,21 @@ extern bool llc_coloring_enabled;
 void llc_coloring_init(void);
 void dump_llc_coloring_info(void);
 void domain_dump_llc_colors(const struct domain *d);
+void domain_llc_coloring_free(struct domain *d);
 #else
 #define llc_coloring_enabled false
 
 static inline void llc_coloring_init(void) {}
 static inline void dump_llc_coloring_info(void) {}
 static inline void domain_dump_llc_colors(const struct domain *d) {}
+static inline void domain_llc_coloring_free(struct domain *d) {}
 #endif
 
 unsigned int get_llc_way_size(void);
 void arch_llc_coloring_init(void);
 int dom0_set_llc_colors(struct domain *d);
+int domain_set_llc_colors(struct domain *d,
+                          const struct xen_domctl_set_llc_colors *config);
 
 #endif /* __XEN_LLC_COLORING_H__ */
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:28:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:28:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856858.1269425 (Exim 4.92)
	(envelope-from )
	id 1tM8Wq-0005cQ-K1; Fri, 13 Dec 2024 16:28:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856858.1269425; Fri, 13 Dec 2024 16:28:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tM8Wq-0005c2-Dz; Fri, 13 Dec 2024 16:28:36 +0000
Received: by outflank-mailman (input) for mailman id 856858;
 Fri, 13 Dec 2024 16:28: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 1tM8Wp-0003wJ-Ai
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:28:35 +0000
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com
 [2a00:1450:4864:20::635])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4bbe9ac1-b96f-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 17:28:33 +0100 (CET)
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-aa6aee68a57so291070566b.3
 for ; Fri, 13 Dec 2024 08:28:33 -0800 (PST)
Received: from carlo-ubuntu.minervasys.tech ([193.207.202.156])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa673474d96sm841759266b.96.2024.12.13.08.28.31
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 08:28: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: 4bbe9ac1-b96f-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734107313; x=1734712113; 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=Rq3vT01mcQ7WuIW7p4+7qshmPLMHXN2VmCfYDaVBCp8=;
        b=cHXJpkaiW456Ot11dSHKaWjeanWcbkVpxo+nbJEtbiftjfG+hn4WCxe4/w3cnqfsvP
         cQTLTJ/aEPGdVy6xOenVsqv2O+tMl0nKu72umXcEMlO2TtGbJFrJGPZzZrVO1N8EblFi
         HZWXX0+kXHFws6Xdu10gFX9kNy+0OzEWe117vs4K3C2N8of2yBUUdcXEflOUqhevypkT
         PLlUxcv5x4QZHCmQgDEqp7YV3C+RJ4IIP8KKIKAC7W2vG/tL98evXXvECfMu1aYqwLC0
         Qe9vtjMn/ZjFRLbc9CaHjCOhB7QqMq2lFVSUBdj63GfSJ/5wAK34cuo4AcsgddIrgGso
         LHtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734107313; x=1734712113;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Rq3vT01mcQ7WuIW7p4+7qshmPLMHXN2VmCfYDaVBCp8=;
        b=QW6xOboXPJEeCPS58aGREuiFJbjUAiUXDOOpA2rLIHNAwiXTMto3gajg/rcTP2d8+n
         UFi52hekA0mRuYU/lHIsOcjTasu+Mh11wm/EogVBc9c/NqA4LERo8227fPUtgk0j0FU3
         XUMKKbSBhqOE0Q9wThV0T4oLmr1iSDr4XFeEvOInbAbSD2pPxbtMeP/PguW7sDFjyRfn
         G/eQxvGewl27U0CiAE+noxHQqTFtDind2KGNFY4P1rg76Z+VyN7AIshz1CKHehKzMlyM
         7DQ0cI0NITgloFNR+11wDFOvTEKdm4X+GTrvrox5VOH0BeMqqvLDXP4DefgNqnaKo/kt
         2Uig==
X-Gm-Message-State: AOJu0YxZUhnEJBxwEEGEnGi4VdbB56P8BdgI1iWJEUAl3fiCbvI2LghE
	GRPuX610Ocai2NJLqeChTUnQJT7I+y3HANMSh4PL1rubRG12mDtJtsS/1uQOhvtEi8aocCzpppQ
	GnNQ=
X-Gm-Gg: ASbGncuSIRYxg8YW3A30WJV1TUpscF5I5iJIWPuvEq6nI4gnWtNxEwbPIx+3Rlc83Uw
	QiPiX7QWidDkHHDNstvlv+eWMTdr1EIzRO/0w1I3AIdol+kXuvx1wU0zB+UUyzR45anCMwsp82j
	dX80xTlTii30BpNJe2HUY/BYct6YcyBjB5ph06bpiOrh5dwNlGFvr8wLsT/Lb6UrsQHNFnBqogB
	MVtvyL6zyMzZREQZBgOsGk5PDzBGy6FTcQZ6yAGnuhyuqQV6KrzdTfwZLqsHv+wSYWFjhu+2jTC
	/AXywoSInlYKMcCw
X-Google-Smtp-Source: AGHT+IEbpM9K/p+EQHTML6WSJ2IOFaqH8DApwywpbd/OgOLC4ZM4wqdHLB7eFvz5xm4uwu11utVpLw==
X-Received: by 2002:a17:906:4fce:b0:aa6:950c:ae18 with SMTP id a640c23a62f3a-aab7790a0fdmr361817366b.22.1734107312847;
        Fri, 13 Dec 2024 08:28:32 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Anthony PERARD ,
	Nick Rosbrook ,
	George Dunlap ,
	Juergen Gross 
Subject: [PATCH v12 06/12] tools: add support for cache coloring configuration
Date: Fri, 13 Dec 2024 17:28:09 +0100
Message-ID: <20241213162815.9196-7-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add a new "llc_colors" parameter that defines the LLC color assignment for
a domain. The user can specify one or more color ranges using the same
syntax used everywhere else for color config described in the
documentation.
The parameter is defined as a list of strings that represent the color
ranges.

Documentation is also added.
Golang bindings are regenerated.

Based on original work from: Luca Miccio 

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
Reviewed-by: Anthony PERARD 
---
v12:
- no changes
v11:
- turned unsigned int to uint32_t in xc_domain_set_llc_colors()
- return -1 in case of error instead of ENOMEM in xc_domain_set_llc_colors()
- added regenerated go bindings
v10:
- no changes
v9:
- turned warning into error in case of coloring not enabled
v8:
- warn the user in case of coloring not supported at hypervisor level
v7:
- removed unneeded NULL check before xc_hypercall_buffer_free() in
  xc_domain_set_llc_colors()
v6:
- no edits
v5:
- added LIBXL_HAVE_BUILDINFO_LLC_COLORS
- moved color configuration in xc_domain_set_llc_colors() cause of the new
  hypercall
v4:
- removed overlapping color ranges checks during parsing
- moved hypercall buffer initialization in libxenctrl
---
 docs/man/xl.cfg.5.pod.in             |  6 +++++
 tools/golang/xenlight/helpers.gen.go | 16 ++++++++++++
 tools/golang/xenlight/types.gen.go   |  1 +
 tools/include/libxl.h                |  5 ++++
 tools/include/xenctrl.h              |  9 +++++++
 tools/libs/ctrl/xc_domain.c          | 34 +++++++++++++++++++++++++
 tools/libs/light/libxl_create.c      | 18 +++++++++++++
 tools/libs/light/libxl_types.idl     |  1 +
 tools/xl/xl_parse.c                  | 38 +++++++++++++++++++++++++++-
 9 files changed, 127 insertions(+), 1 deletion(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index ac3f88fd57..8e1422104e 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -3074,6 +3074,12 @@ raised.
 
 =over 4
 
+=item B
+
+Specify the Last Level Cache (LLC) color configuration for the guest.
+B can be either a single color value or a hypen-separated closed
+interval of colors (such as "0-4").
+
 =item B
 
 An optional integer parameter specifying the number of SPIs (Shared
diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go
index fe5110474d..90846ea8e8 100644
--- a/tools/golang/xenlight/helpers.gen.go
+++ b/tools/golang/xenlight/helpers.gen.go
@@ -1097,6 +1097,14 @@ if err := x.Iomem[i].fromC(&v); err != nil {
 return fmt.Errorf("converting field Iomem: %v", err) }
 }
 }
+x.LlcColors = nil
+if n := int(xc.num_llc_colors); n > 0 {
+cLlcColors := (*[1<<28]C.uint32_t)(unsafe.Pointer(xc.llc_colors))[:n:n]
+x.LlcColors = make([]uint32, n)
+for i, v := range cLlcColors {
+x.LlcColors[i] = uint32(v)
+}
+}
 if err := x.ClaimMode.fromC(&xc.claim_mode);err != nil {
 return fmt.Errorf("converting field ClaimMode: %v", err)
 }
@@ -1453,6 +1461,14 @@ return fmt.Errorf("converting field Iomem: %v", err)
 }
 }
 }
+if numLlcColors := len(x.LlcColors); numLlcColors > 0 {
+xc.llc_colors = (*C.uint32_t)(C.malloc(C.size_t(numLlcColors*numLlcColors)))
+xc.num_llc_colors = C.int(numLlcColors)
+cLlcColors := (*[1<<28]C.uint32_t)(unsafe.Pointer(xc.llc_colors))[:numLlcColors:numLlcColors]
+for i,v := range x.LlcColors {
+cLlcColors[i] = C.uint32_t(v)
+}
+}
 if err := x.ClaimMode.toC(&xc.claim_mode); err != nil {
 return fmt.Errorf("converting field ClaimMode: %v", err)
 }
diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go
index c9e45b306f..e7667f1ce3 100644
--- a/tools/golang/xenlight/types.gen.go
+++ b/tools/golang/xenlight/types.gen.go
@@ -575,6 +575,7 @@ SchedParams DomainSchedParams
 Ioports []IoportRange
 Irqs []uint32
 Iomem []IomemRange
+LlcColors []uint32
 ClaimMode Defbool
 EventChannels uint32
 Kernel string
diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index 8d32428ea9..f8fe4afd7d 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -1379,6 +1379,11 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, const libxl_mac *src);
  */
 #define LIBXL_HAVE_BUILDINFO_HVM_SYSTEM_FIRMWARE
 
+/*
+ * The libxl_domain_build_info has the llc_colors array.
+ */
+#define LIBXL_HAVE_BUILDINFO_LLC_COLORS 1
+
 /*
  * ERROR_REMUS_XXX error code only exists from Xen 4.5, Xen 4.6 and it
  * is changed to ERROR_CHECKPOINT_XXX in Xen 4.7
diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 29617585c5..d6d93a2e8f 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -2667,6 +2667,15 @@ int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t timeout, uint32
 int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
                          xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
 
+/*
+ * Set LLC colors for a domain.
+ * It can only be used directly after domain creation. An attempt to use it
+ * afterwards will result in an error.
+ */
+int xc_domain_set_llc_colors(xc_interface *xch, uint32_t domid,
+                             const uint32_t *llc_colors,
+                             uint32_t num_llc_colors);
+
 #if defined(__arm__) || defined(__aarch64__)
 int xc_dt_overlay(xc_interface *xch, void *overlay_fdt,
                   uint32_t overlay_fdt_size, uint8_t overlay_op);
diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c
index e3538ec0ba..2ddc3f4f42 100644
--- a/tools/libs/ctrl/xc_domain.c
+++ b/tools/libs/ctrl/xc_domain.c
@@ -2195,6 +2195,40 @@ int xc_domain_soft_reset(xc_interface *xch,
     domctl.domain = domid;
     return do_domctl(xch, &domctl);
 }
+
+int xc_domain_set_llc_colors(xc_interface *xch, uint32_t domid,
+                             const uint32_t *llc_colors,
+                             uint32_t num_llc_colors)
+{
+    struct xen_domctl domctl = {};
+    DECLARE_HYPERCALL_BUFFER(uint32_t, local);
+    int ret = -1;
+
+    if ( num_llc_colors )
+    {
+        size_t bytes = sizeof(uint32_t) * num_llc_colors;
+
+        local = xc_hypercall_buffer_alloc(xch, local, bytes);
+        if ( local == NULL )
+        {
+            PERROR("Could not allocate LLC colors for set_llc_colors");
+            goto out;
+        }
+        memcpy(local, llc_colors, bytes);
+        set_xen_guest_handle(domctl.u.set_llc_colors.llc_colors, local);
+    }
+
+    domctl.cmd = XEN_DOMCTL_set_llc_colors;
+    domctl.domain = domid;
+    domctl.u.set_llc_colors.num_llc_colors = num_llc_colors;
+
+    ret = do_domctl(xch, &domctl);
+
+out:
+    xc_hypercall_buffer_free(xch, local);
+
+    return ret;
+}
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
index edeadd57ef..e03599ea99 100644
--- a/tools/libs/light/libxl_create.c
+++ b/tools/libs/light/libxl_create.c
@@ -747,6 +747,24 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
             /* A new domain now exists */
             *domid = local_domid;
 
+            ret = xc_domain_set_llc_colors(ctx->xch, local_domid,
+                                           b_info->llc_colors,
+                                           b_info->num_llc_colors);
+            if (ret < 0) {
+                if (errno == EOPNOTSUPP) {
+                    if (b_info->num_llc_colors > 0) {
+                        LOGED(ERROR, local_domid,
+                            "LLC coloring not enabled in the hypervisor");
+                        rc = ERROR_FAIL;
+                        goto out;
+                    }
+                } else {
+                    LOGED(ERROR, local_domid, "LLC colors allocation failed");
+                    rc = ERROR_FAIL;
+                    goto out;
+                }
+            }
+
             rc = libxl__is_domid_recent(gc, local_domid, &recent);
             if (rc)
                 goto out;
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index 4e65e6fda5..bd4b8721ff 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -616,6 +616,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("ioports",          Array(libxl_ioport_range, "num_ioports")),
     ("irqs",             Array(uint32, "num_irqs")),
     ("iomem",            Array(libxl_iomem_range, "num_iomem")),
+    ("llc_colors",       Array(uint32, "num_llc_colors")),
     ("claim_mode",	     libxl_defbool),
     ("event_channels",   uint32),
     ("kernel",           string),
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index e3a4800f6e..3d85be7dd4 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -1296,7 +1296,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;
+                   *mca_caps, *smbios, *llc_colors;
     int num_ioports, num_irqs, num_iomem, num_cpus, num_viridian, num_mca_caps;
     int num_smbios;
     int pci_power_mgmt = 0;
@@ -1304,6 +1304,7 @@ void parse_config_data(const char *config_source,
     int pci_permissive = 0;
     int pci_seize = 0;
     int i, e;
+    int num_llc_colors;
     char *kernel_basename;
 
     libxl_domain_create_info *c_info = &d_config->c_info;
@@ -1447,6 +1448,41 @@ void parse_config_data(const char *config_source,
     if (!xlu_cfg_get_long (config, "maxmem", &l, 0))
         b_info->max_memkb = l * 1024;
 
+    if (!xlu_cfg_get_list(config, "llc_colors", &llc_colors, &num_llc_colors, 0)) {
+        int cur_index = 0;
+
+        b_info->num_llc_colors = 0;
+        for (i = 0; i < num_llc_colors; i++) {
+            uint32_t start = 0, end = 0, k;
+
+            buf = xlu_cfg_get_listitem(llc_colors, i);
+            if (!buf) {
+                fprintf(stderr,
+                        "xl: Can't get element %d in LLC color list\n", i);
+                exit(1);
+            }
+
+            if (sscanf(buf, "%" SCNu32 "-%" SCNu32, &start, &end) != 2) {
+                if (sscanf(buf, "%" SCNu32, &start) != 1) {
+                    fprintf(stderr, "xl: Invalid LLC color range: %s\n", buf);
+                    exit(1);
+                }
+                end = start;
+            } else if (start > end) {
+                fprintf(stderr,
+                        "xl: Start LLC color is greater than end: %s\n", buf);
+                exit(1);
+            }
+
+            b_info->num_llc_colors += (end - start) + 1;
+            b_info->llc_colors = (uint32_t *)realloc(b_info->llc_colors,
+                        sizeof(*b_info->llc_colors) * b_info->num_llc_colors);
+
+            for (k = start; k <= end; k++)
+                b_info->llc_colors[cur_index++] = k;
+        }
+    }
+
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         vcpus = l;
         if (libxl_cpu_bitmap_alloc(ctx, &b_info->avail_vcpus, l)) {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:28:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:28:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856861.1269434 (Exim 4.92)
	(envelope-from )
	id 1tM8Ws-0005vq-6A; Fri, 13 Dec 2024 16:28:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856861.1269434; Fri, 13 Dec 2024 16:28:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tM8Ws-0005vC-1E; Fri, 13 Dec 2024 16:28:38 +0000
Received: by outflank-mailman (input) for mailman id 856861;
 Fri, 13 Dec 2024 16:28: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 1tM8Wr-0003wJ-CU
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:28:37 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4d06218e-b96f-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 17:28:35 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-a9a977d6cc7so244931666b.3
 for ; Fri, 13 Dec 2024 08:28:35 -0800 (PST)
Received: from carlo-ubuntu.minervasys.tech ([193.207.202.156])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa673474d96sm841759266b.96.2024.12.13.08.28.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 08:28: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: 4d06218e-b96f-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734107315; x=1734712115; 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=oFP3lN2u/aPjbY0TPsAh1rRXnFfL4x53loEQEUCcn44=;
        b=erXJPmim0KqLyg6def0UtsQBNp+ujx6JhrYPtot1NH/enVMLz0TrZ/F7XZ/N6jvT12
         QzUDTvjMbTFvxIhSJpeqVPSZqI6wP43tcZErAMj2kGV0s/ZzPz3T71txBuRkCl/fyQBB
         JkObvrc6OWdpwd153NoDalc2mkEUwOv3nadfP5/zLlZm/fYSMmVeaQxXqZff1wMtF2O7
         DSKooLdsKVEB/WXNoRaIKwiYLD/o5U97od8DDR12h/L79Bjse74JyHhgSAtp3y4uMP5+
         LGmTCJgH99404sNIu/1OX5DEALyFUFDA1Vbz/soV5Kwamth2VKciKHBwaCK+vH7+i5Og
         Soog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734107315; x=1734712115;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=oFP3lN2u/aPjbY0TPsAh1rRXnFfL4x53loEQEUCcn44=;
        b=kuzNvToEYJ5rwAG9T7kK4mymwZv7cZT9Y32tH1mjiQJu0xB1sXA4liRr8zPHYvYsuB
         YoBF24jDu86jXG06x2pS6MeUq2kF5iaRKbs7iuBtgOjJu7J28h1q8QKuwcp400vE5C/1
         TqqkNF/32GEjff4hEdiq7nnUbwy7/xcPDy1wFKwSJcC9c2x9CdQiGstbFFKltG3AP8KA
         onSb2dA1DVl0KZW8CaRnRvt9799Kw+Tf1YEkSqN6QOZP5Gz9EAREUmdsX5l2TGLKYGYs
         SRiCw47a9kUppxasBYIUzovr6F4QexvJjDRt5TVDuihJA3uivMS9c8yeNwplRfIqVbC0
         t5sg==
X-Gm-Message-State: AOJu0YzvdxpfJ6oydpR0haeLQpXA424Vpm2OixIG9qAUJ0XSZZoGYdFt
	Zboa07COc0Kx2VSZaHMTIXNmmBWi+eaW6AKgO3tiIm0Be9SxBqr7yHWYn5o8X5ZEiT2XYep6ZOu
	G8dk=
X-Gm-Gg: ASbGncvWkChpEjZI1F784LTC6C1T6ZUYEHUzppGk2D69ckW54BnsnSVXmR11kGHBf+E
	4ljSmd1/Uxieov7ytvjJfkmd/tEcoUVNcnoRlDuWK8HI2sK51HmSn0VYc1DYudHLXmIShKLxOpT
	a3vderjoUxVNa0O7H75fZC6uhnN+ht+J/+SydDb2bEyLkOwhyJvLZnE9l9JiZ1coQPnKYe+7pGv
	F1wSKXS4clFVT+LubZfhtWVGA1SKIOZvMuTjy44Xx50E8AZnvnRBGsOTxUEtFbspj6GtjpOHj6t
	5nidNB8pmGVLS9Bw
X-Google-Smtp-Source: AGHT+IEbA6dke+2U6A9aM1+Ezqd72LDaJoNfLha9Msq7ItRiGcv/T9srLySBjaHSM/f6EDE+2W9YCQ==
X-Received: by 2002:a05:6402:2786:b0:5d3:ff93:f5f9 with SMTP id 4fb4d7f45d1cf-5d63c3432f6mr6594350a12.20.1734107314996;
        Fri, 13 Dec 2024 08:28:34 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v12 07/12] xen/arm: add support for cache coloring configuration via device-tree
Date: Fri, 13 Dec 2024 17:28:10 +0100
Message-ID: <20241213162815.9196-8-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add the "llc-colors" Device Tree property to express DomUs and Dom0less
color configurations.

Based on original work from: Luca Miccio 

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
Reviewed-by: Jan Beulich  # non-Arm
Reviewed-by: Michal Orzel 
---
v12:
- no changes
v11:
- made clear that llc-colors device-tree property is Arm64-only in booting.txt
v10:
- no changes
v9:
- use best-effort allocation in domain_set_llc_colors_from_str()
v8:
- fixed memory leak on error path of domain_set_llc_colors_from_str()
- realloc colors array after parsing from string to reduce memory usage
v7:
- removed alloc_colors() helper usage from domain_set_llc_colors_from_str()
v6:
- rewrote domain_set_llc_colors_from_str() to be more explicit
v5:
- static-mem check has been moved in a previous patch
- added domain_set_llc_colors_from_str() to set colors after domain creation
---
 docs/misc/arm/device-tree/booting.txt |  5 +++
 docs/misc/cache-coloring.rst          | 48 +++++++++++++++++++++++++++
 xen/arch/arm/dom0less-build.c         | 10 ++++++
 xen/common/llc-coloring.c             | 40 ++++++++++++++++++++++
 xen/include/xen/llc-coloring.h        |  1 +
 xen/include/xen/xmalloc.h             | 12 +++++++
 6 files changed, 116 insertions(+)

diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
index 3a04f5c57f..9c881baccc 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -162,6 +162,11 @@ with the following properties:
 
     An integer specifying the number of vcpus to allocate to the guest.
 
+- llc-colors
+    A string specifying the LLC color configuration for the guest.
+    Refer to docs/misc/cache_coloring.rst for syntax. This option is applicable
+    only to Arm64 guests.
+
 - vpl011
 
     An empty property to enable/disable a virtual pl011 for the guest to
diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
index 7b47d0ed92..e097e74032 100644
--- a/docs/misc/cache-coloring.rst
+++ b/docs/misc/cache-coloring.rst
@@ -14,6 +14,7 @@ If needed, change the maximum number of colors with
 ``CONFIG_LLC_COLORS_ORDER=``.
 
 Runtime configuration is done via `Command line parameters`_.
+For DomUs follow `DomUs configuration`_.
 
 Background
 **********
@@ -149,6 +150,53 @@ LLC specs can be manually set via the above command line parameters. This
 bypasses any auto-probing and it's used to overcome failing situations, such as
 flawed probing logic, or for debugging/testing purposes.
 
+DomUs configuration
+*******************
+
+DomUs colors can be set either in the ``xl`` configuration file (documentation
+at `docs/man/xl.cfg.pod.5.in`) or via Device Tree (documentation at
+`docs/misc/arm/device-tree/booting.txt`) using the ``llc-colors`` option.
+For example:
+
+::
+
+    xen,xen-bootargs = "console=dtuart dtuart=serial0 dom0_mem=1G dom0_max_vcpus=1 sched=null llc-coloring=on dom0-llc-colors=2-6";
+    xen,dom0-bootargs "console=hvc0 earlycon=xen earlyprintk=xen root=/dev/ram0"
+
+    dom0 {
+        compatible = "xen,linux-zimage" "xen,multiboot-module";
+        reg = <0x0 0x1000000 0x0 15858176>;
+    };
+
+    dom0-ramdisk {
+        compatible = "xen,linux-initrd" "xen,multiboot-module";
+        reg = <0x0 0x2000000 0x0 20638062>;
+    };
+
+    domU0 {
+        #address-cells = <0x1>;
+        #size-cells = <0x1>;
+        compatible = "xen,domain";
+        memory = <0x0 0x40000>;
+        llc-colors = "4-8,10,11,12";
+        cpus = <0x1>;
+        vpl011 = <0x1>;
+
+        module@2000000 {
+            compatible = "multiboot,kernel", "multiboot,module";
+            reg = <0x2000000 0xffffff>;
+            bootargs = "console=ttyAMA0";
+        };
+
+        module@30000000 {
+            compatible = "multiboot,ramdisk", "multiboot,module";
+            reg = <0x3000000 0xffffff>;
+        };
+    };
+
+**Note:** If no color configuration is provided for a domain, the default one,
+which corresponds to all available colors is used instead.
+
 Known issues and limitations
 ****************************
 
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 67b1503647..49d1f14d65 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -817,6 +817,7 @@ void __init create_domUs(void)
     bool iommu = false;
     const struct dt_device_node *cpupool_node,
                                 *chosen = dt_find_node_by_path("/chosen");
+    const char *llc_colors_str = NULL;
 
     BUG_ON(chosen == NULL);
     dt_for_each_child_node(chosen, node)
@@ -965,6 +966,10 @@ void __init create_domUs(void)
 #endif
         }
 
+        dt_property_read_string(node, "llc-colors", &llc_colors_str);
+        if ( !llc_coloring_enabled && llc_colors_str )
+            panic("'llc-colors' found, but LLC coloring is disabled\n");
+
         /*
          * The variable max_init_domid is initialized with zero, so here it's
          * very important to use the pre-increment operator to call
@@ -975,6 +980,11 @@ void __init create_domUs(void)
             panic("Error creating domain %s (rc = %ld)\n",
                   dt_node_name(node), PTR_ERR(d));
 
+        if ( llc_coloring_enabled &&
+             (rc = domain_set_llc_colors_from_str(d, llc_colors_str)) )
+            panic("Error initializing LLC coloring for domain %s (rc = %d)\n",
+                  dt_node_name(node), rc);
+
         d->is_console = true;
         dt_device_set_used_by(node, d->domain_id);
 
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index d7d797e4d2..1a0e02ddb0 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -282,6 +282,46 @@ void domain_llc_coloring_free(struct domain *d)
     xfree(__va(__pa(d->llc_colors)));
 }
 
+int __init domain_set_llc_colors_from_str(struct domain *d, const char *str)
+{
+    int err;
+    unsigned int *colors, num_colors;
+
+    if ( !str )
+    {
+        domain_set_default_colors(d);
+        return 0;
+    }
+
+    colors = xmalloc_array(unsigned int, max_nr_colors);
+    if ( !colors )
+        return -ENOMEM;
+
+    err = parse_color_config(str, colors, max_nr_colors, &num_colors);
+    if ( err )
+    {
+        printk(XENLOG_ERR "Error parsing LLC color configuration");
+        xfree(colors);
+        return err;
+    }
+
+    if ( !check_colors(colors, num_colors) )
+    {
+        printk(XENLOG_ERR "%pd: bad LLC color config\n", d);
+        xfree(colors);
+        return -EINVAL;
+    }
+
+    /* Adjust the size cause it was initially set to max_nr_colors */
+    d->llc_colors = xrealloc_array(colors, num_colors);
+    if ( !d->llc_colors )
+        d->llc_colors = colors;
+
+    d->num_llc_colors = num_colors;
+
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
index 26353c808a..5d1355b3c9 100644
--- a/xen/include/xen/llc-coloring.h
+++ b/xen/include/xen/llc-coloring.h
@@ -34,6 +34,7 @@ void arch_llc_coloring_init(void);
 int dom0_set_llc_colors(struct domain *d);
 int domain_set_llc_colors(struct domain *d,
                           const struct xen_domctl_set_llc_colors *config);
+int domain_set_llc_colors_from_str(struct domain *d, const char *str);
 
 #endif /* __XEN_LLC_COLORING_H__ */
 
diff --git a/xen/include/xen/xmalloc.h b/xen/include/xen/xmalloc.h
index b903fa2e26..f0412fb4e0 100644
--- a/xen/include/xen/xmalloc.h
+++ b/xen/include/xen/xmalloc.h
@@ -37,6 +37,9 @@
     ((_type *)_xmalloc_array(sizeof(_type), __alignof__(_type), _num))
 #define xzalloc_array(_type, _num) \
     ((_type *)_xzalloc_array(sizeof(_type), __alignof__(_type), _num))
+#define xrealloc_array(_ptr, _num)                                  \
+    ((typeof(_ptr))_xrealloc_array(_ptr, sizeof(typeof(*(_ptr))),   \
+                                   __alignof__(typeof(*(_ptr))), _num))
 
 /* Allocate space for a structure with a flexible array of typed objects. */
 #define xzalloc_flex_struct(type, field, nr) \
@@ -98,6 +101,15 @@ static inline void *_xzalloc_array(
     return _xzalloc(size * num, align);
 }
 
+static inline void *_xrealloc_array(
+    void *ptr, unsigned long size, unsigned long align, unsigned long num)
+{
+    /* Check for overflow. */
+    if ( size && num > UINT_MAX / size )
+        return NULL;
+    return _xrealloc(ptr, size * num, align);
+}
+
 /*
  * Pooled allocator interface.
  */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:28:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:28:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856868.1269445 (Exim 4.92)
	(envelope-from )
	id 1tM8Wx-0006cs-HG; Fri, 13 Dec 2024 16:28:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856868.1269445; Fri, 13 Dec 2024 16:28: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 1tM8Wx-0006cG-AV; Fri, 13 Dec 2024 16:28:43 +0000
Received: by outflank-mailman (input) for mailman id 856868;
 Fri, 13 Dec 2024 16:28: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 1tM8Wv-0003wJ-L6
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:28:41 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4f78cc49-b96f-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 17:28:39 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-a9a68480164so316769666b.3
 for ; Fri, 13 Dec 2024 08:28:39 -0800 (PST)
Received: from carlo-ubuntu.minervasys.tech ([193.207.202.156])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa673474d96sm841759266b.96.2024.12.13.08.28.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 08:28:38 -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: 4f78cc49-b96f-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734107319; x=1734712119; 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=IpihGP/rsJKpIJF0EavB+fmzC08YQ4HgsyuMaFmmYQE=;
        b=PtRkVrkpoG5IunSCFR3EBU1K1KcgLRTu2rHCk+OyiiwINYO23VdBxiHG+Z0Y76PdDe
         tJ7THnWawQxhYYw8FI4C7dcOEIO5Mhx+JAYYXsmh2lcvUq46kLyELDZ5IT/N17tApspd
         WeAvyAsskzi5nDKfUdGyDh73RFkpQ7S3p2RcvPE2EkpUPRU/VdxoEaPFLkG9IcAZGRK1
         zkjN4vHDH2glrCQ/LEOlTX/UofsrU0k9xI2Wu5MpR0H7kVS+lwF5r8nedebMbWeAneey
         edr6CA1VXNvgVx1PI9EVlFRn0ktnRSAbGgUllfyntB658/sz0q77KPd6HD6QwZ2zpV18
         M+9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734107319; x=1734712119;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=IpihGP/rsJKpIJF0EavB+fmzC08YQ4HgsyuMaFmmYQE=;
        b=kaAqWRktkJktC3UNSgbSFot6blwkPqoOvnzhpv8K6gJ0A1JdN4r4fB0QVEHoTR40Np
         dJIHpOLrT1fnmqf2jjiPF9NURtLB8CYVD2zZakK/3wf8EtAmV1DfM0vS9XpMI2TszkCy
         D3/N1wMUF6taBsTFQz344hPMBMlE+RQhmTfkDTZIiDZC12ZbzN3f1Q8wb031BlMeRufb
         5wg0ktGvDVfGvuU8j6qHnPd/ZsMldjNiyIoqc1IbhP9w5nCxxbq1QPjeJUuxdOJ8DvEL
         lgjsolWHqTNI7KPvkoO9NuQeTCevgmwWVe78hCMJFIIvyEzCnEAnCpDCc6rxIvRZcKS3
         tynA==
X-Gm-Message-State: AOJu0YwFFQB9JiUMYHUB2jnGtws8ankuRqSbWDC6Y5m23abHRds+GMkA
	90W+rGgsbiXZyFTsbs0VR70dlbAZltnLGI9iPIZXXgRKIrmcZ16f2XtKpBBeqTzH4qL4EBkW+Dl
	V8HY=
X-Gm-Gg: ASbGncuBG5kioaABZF75IpF133ioSF3tMUQfusKrsMCu5xZnGwPrt0fC5I6XZ7ppob2
	pSeMflnyC5wXWAJPpFrw50g5gyR/8Geh7Apx9Zmhhhrf0cjVSBcDmHsfpwArCTFY6LFFuglUvJt
	Y/WBEtIp/1Ml17bZ0403MsnGC0LTslLO+BAfMc3JZiKym1FMIaOMascR5mvdDGW4Apd5n9IdbOo
	JdYzpDEOnsdWEeG15DR4BbQPKqwWlAnaAhhSFlb4E93I8QKNWNmWgokcmpkkBt2uIVkwUZVBaCX
	4HntoBZvgjLLNYIc
X-Google-Smtp-Source: AGHT+IH5GwuYk2PFo+99JYWWqoLHhLwj47JCWpYXawOIBeUmE/SQ/Sn5uz1XXQ66vrpnS8GX2tvoIw==
X-Received: by 2002:a17:906:7953:b0:aa6:a53a:f6c7 with SMTP id a640c23a62f3a-aab779ba4ebmr442697566b.31.1734107318927;
        Fri, 13 Dec 2024 08:28:38 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: [PATCH v12 09/12] xen: add cache coloring allocator for domains
Date: Fri, 13 Dec 2024 17:28:12 +0100
Message-ID: <20241213162815.9196-10-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add a new memory page allocator that implements the cache coloring mechanism.
The allocation algorithm enforces equal frequency distribution of cache
partitions, following the coloring configuration of a domain. This allows
for an even utilization of cache sets for every domain.

Pages are stored in a color-indexed array of lists. Those lists are filled
by a simple init function which computes the color of each page.
When a domain requests a page, the allocator extracts the page from the list
with the maximum number of free pages among those that the domain can access,
given its coloring configuration.

The allocator can only handle requests of order-0 pages. This allows for
easier implementation and since cache coloring targets only embedded systems,
it's assumed not to be a major problem.

The buddy allocator must coexist with the colored one because the Xen heap
isn't colored. For this reason a new Kconfig option and a command line
parameter are added to let the user set the amount of memory reserved for
the buddy allocator. Even when cache coloring is enabled, this memory
isn't managed by the colored allocator.

Colored heap information is dumped in the dump_heap() debug-key function.

Based on original work from: Luca Miccio 

Signed-off-by: Marco Solieri 
Signed-off-by: Carlo Nonato 
Reviewed-by: Jan Beulich 
---
v12:
- fixed #ifdef CONFIG_LLC_COLORING in init_color_heap_pages()
v11:
- CONFIG_BUDDY_ALLOCATOR_SIZE depends on CONFIG_LLC_COLORING
- buddy_alloc_size is defined only if CONFIG_LLC_COLORING
- buddy-alloc-size param is parsed only if CONFIG_LLC_COLORING
v10:
- stated explicit dependency on CONFIG_LLC_COLORING for buddy-alloc-size
- fix for MISRA rule 20.7 parenthesis
v9:
- added ASSERT(order == 0) when freeing a colored page
- moved buddy_alloc_size initialization logic in Kconfig
v8:
- requests that uses MEMF_* flags that can't be served are now going to fail
- free_color_heap_page() is called directly from free_heap_pages()
v7:
- requests to alloc_color_heap_page() now fail if MEMF_bits is used
v6:
- colored allocator functions are now static
v5:
- Carlo Nonato as the new author
- the colored allocator balances color usage for each domain and it searches
  linearly only in the number of colors (FIXME removed)
- addedd scrub functionality
- removed stub functions (still requires some macro definition)
- addr_to_color turned to mfn_to_color for easier operations
- removed BUG_ON in init_color_heap_pages() in favor of panic()
- only non empty page lists are logged in dump_color_heap()
v4:
- moved colored allocator code after buddy allocator because it now has
  some dependencies on buddy functions
- buddy_alloc_size is now used only by the colored allocator
- fixed a bug that allowed the buddy to merge pages when they were colored
- free_color_heap_page() now calls mark_page_free()
- free_color_heap_page() uses of the frametable array for faster searches
- added FIXME comment for the linear search in free_color_heap_page()
- removed alloc_color_domheap_page() to let the colored allocator exploit
  some more buddy allocator code
- alloc_color_heap_page() now allocs min address pages first
- reduced the mess in end_boot_allocator(): use the first loop for
  init_color_heap_pages()
- fixed page_list_add_prev() (list.h) since it was doing the opposite of
  what it was supposed to do
- fixed page_list_add_prev() (non list.h) to check also for next existence
- removed unused page_list_add_next()
- moved p2m code in another patch
---
 docs/misc/cache-coloring.rst      |  37 ++++++
 docs/misc/xen-command-line.pandoc |  14 +++
 xen/arch/arm/include/asm/mm.h     |   5 +
 xen/common/Kconfig                |   8 ++
 xen/common/llc-coloring.c         |  13 ++
 xen/common/page_alloc.c           | 191 +++++++++++++++++++++++++++++-
 xen/include/xen/llc-coloring.h    |   3 +
 7 files changed, 267 insertions(+), 4 deletions(-)

diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
index e097e74032..5224b27afe 100644
--- a/docs/misc/cache-coloring.rst
+++ b/docs/misc/cache-coloring.rst
@@ -13,6 +13,9 @@ To compile LLC coloring support set ``CONFIG_LLC_COLORING=y``.
 If needed, change the maximum number of colors with
 ``CONFIG_LLC_COLORS_ORDER=``.
 
+If needed, change the buddy allocator reserved size with
+``CONFIG_BUDDY_ALLOCATOR_SIZE=``.
+
 Runtime configuration is done via `Command line parameters`_.
 For DomUs follow `DomUs configuration`_.
 
@@ -110,6 +113,8 @@ Specific documentation is available at `docs/misc/xen-command-line.pandoc`.
 +----------------------+-------------------------------+
 | ``dom0-llc-colors``  | Dom0 color configuration      |
 +----------------------+-------------------------------+
+| ``buddy-alloc-size`` | Buddy allocator reserved size |
++----------------------+-------------------------------+
 
 Colors selection format
 ***********************
@@ -197,6 +202,17 @@ For example:
 **Note:** If no color configuration is provided for a domain, the default one,
 which corresponds to all available colors is used instead.
 
+Colored allocator and buddy allocator
+*************************************
+
+The colored allocator distributes pages based on color configurations of
+domains so that each domains only gets pages of its own colors.
+The colored allocator is meant as an alternative to the buddy allocator because
+its allocation policy is by definition incompatible with the generic one. Since
+the Xen heap is not colored yet, we need to support the coexistence of the two
+allocators and some memory must be left for the buddy one. Buddy memory
+reservation is configured via Kconfig or via command-line.
+
 Known issues and limitations
 ****************************
 
@@ -207,3 +223,24 @@ In the domain configuration, "xen,static-mem" allows memory to be statically
 allocated to the domain. This isn't possible when LLC coloring is enabled,
 because that memory can't be guaranteed to use only colors assigned to the
 domain.
+
+Cache coloring is intended only for embedded systems
+####################################################
+
+The current implementation aims to satisfy the need of predictability in
+embedded systems with small amount of memory to be managed in a colored way.
+Given that, some shortcuts are taken in the development. Expect worse
+performances on larger systems.
+
+Colored allocator can only make use of order-0 pages
+####################################################
+
+The cache coloring technique relies on memory mappings and on the smallest
+mapping granularity to achieve the maximum number of colors (cache partitions)
+possible. This granularity is what is normally called a page and, in Xen
+terminology, the order-0 page is the smallest one. The fairly simple
+colored allocator currently implemented, makes use only of such pages.
+It must be said that a more complex one could, in theory, adopt higher order
+pages if the colors selection contained adjacent colors. Two subsequent colors,
+for example, can be represented by an order-1 page, four colors correspond to
+an order-2 page, etc.
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index bfdc8b0002..3a70c49c05 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -270,6 +270,20 @@ and not running softirqs. Reduce this if softirqs are not being run frequently
 enough. Setting this to a high value may cause boot failure, particularly if
 the NMI watchdog is also enabled.
 
+### buddy-alloc-size (arm64)
+> `= `
+
+> Default: `64M`
+
+Amount of memory reserved for the buddy allocator when colored allocator is
+active. This option is available only when `CONFIG_LLC_COLORING` is enabled.
+The colored allocator is meant as an alternative to the buddy allocator,
+because its allocation policy is by definition incompatible with the generic
+one. Since the Xen heap systems is not colored yet, we need to support the
+coexistence of the two allocators for now. This parameter, which is optional
+and for expert only, it's used to set the amount of memory reserved to the
+buddy allocator.
+
 ### cet
     = List of [ shstk=, ibt= ]
 
diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
index 59b774b7b8..f91ff088f6 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -145,6 +145,11 @@ struct page_info
 #else
 #define PGC_static     0
 #endif
+#ifdef CONFIG_LLC_COLORING
+/* Page is cache colored */
+#define _PGC_colored      PG_shift(4)
+#define PGC_colored       PG_mask(1, 4)
+#endif
 /* ... */
 /* Page is broken? */
 #define _PGC_broken       PG_shift(7)
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index b4ec6893be..6166327f4d 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -537,4 +537,12 @@ config LLC_COLORS_ORDER
 	  The default value corresponds to an 8 MiB 16-ways LLC, which should be
 	  more than what's needed in the general case.
 
+config BUDDY_ALLOCATOR_SIZE
+	int "Buddy allocator reserved memory size (MiB)"
+	default "64"
+	depends on LLC_COLORING
+	help
+	  Amount of memory reserved for the buddy allocator to serve Xen heap,
+	  working alongside the colored one.
+
 endmenu
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index 1a0e02ddb0..ec6b0d3bff 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -36,6 +36,9 @@ static unsigned int __ro_after_init default_colors[NR_LLC_COLORS];
 static unsigned int __initdata dom0_colors[NR_LLC_COLORS];
 static unsigned int __initdata dom0_num_colors;
 
+#define mfn_color_mask              (max_nr_colors - 1)
+#define mfn_to_color(mfn)           (mfn_x(mfn) & mfn_color_mask)
+
 /*
  * Parse the coloring configuration given in the buf string, following the
  * syntax below.
@@ -322,6 +325,16 @@ int __init domain_set_llc_colors_from_str(struct domain *d, const char *str)
     return 0;
 }
 
+unsigned int page_to_llc_color(const struct page_info *pg)
+{
+    return mfn_to_color(page_to_mfn(pg));
+}
+
+unsigned int get_max_nr_llc_colors(void)
+{
+    return max_nr_colors;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 7735c8b436..e8cfb427d9 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -139,6 +139,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -160,11 +161,15 @@
 #define PGC_static 0
 #endif
 
-#define PGC_no_buddy_merge PGC_static
+#ifndef PGC_colored
+#define PGC_colored 0
+#endif
+
+#define PGC_no_buddy_merge (PGC_static | PGC_colored)
 /*
  * Flags that are preserved in assign_pages() (and only there)
  */
-#define PGC_preserved (PGC_extra | PGC_static)
+#define PGC_preserved (PGC_extra | PGC_static | PGC_colored)
 
 #ifndef PGT_TYPE_INFO_INITIALIZER
 #define PGT_TYPE_INFO_INITIALIZER 0
@@ -1477,6 +1482,8 @@ static bool mark_page_free(struct page_info *pg, mfn_t mfn)
     return pg_offlined;
 }
 
+static void free_color_heap_page(struct page_info *pg, bool need_scrub);
+
 /* Free 2^@order set of pages. */
 static void free_heap_pages(
     struct page_info *pg, unsigned int order, bool need_scrub)
@@ -1501,6 +1508,15 @@ static void free_heap_pages(
             pg[i].count_info |= PGC_need_scrub;
             poison_one_page(&pg[i]);
         }
+
+        if ( pg->count_info & PGC_colored )
+        {
+            ASSERT(order == 0);
+
+            free_color_heap_page(pg, need_scrub);
+            spin_unlock(&heap_lock);
+            return;
+        }
     }
 
     avail[node][zone] += 1 << order;
@@ -1965,6 +1981,157 @@ static unsigned long avail_heap_pages(
     return free_pages;
 }
 
+/*************************
+ * COLORED SIDE-ALLOCATOR
+ *
+ * Pages are grouped by LLC color in lists which are globally referred to as the
+ * color heap. Lists are populated in end_boot_allocator().
+ * After initialization there will be N lists where N is the number of
+ * available colors on the platform.
+ */
+static struct page_list_head *__ro_after_init _color_heap;
+#define color_heap(color) (&_color_heap[color])
+
+static unsigned long *__ro_after_init free_colored_pages;
+
+#ifdef CONFIG_LLC_COLORING
+#define domain_num_llc_colors(d) ((d)->num_llc_colors)
+#define domain_llc_color(d, i)   ((d)->llc_colors[i])
+
+/* Memory required for buddy allocator to work with colored one */
+static unsigned long __initdata buddy_alloc_size =
+    MB(CONFIG_BUDDY_ALLOCATOR_SIZE);
+size_param("buddy-alloc-size", buddy_alloc_size);
+#else
+#define domain_num_llc_colors(d) 0
+#define domain_llc_color(d, i)   0
+#endif
+
+static void free_color_heap_page(struct page_info *pg, bool need_scrub)
+{
+    unsigned int color;
+
+    color = page_to_llc_color(pg);
+    free_colored_pages[color]++;
+    /*
+     * Head insertion allows re-using cache-hot pages in configurations without
+     * sharing of colors.
+     */
+    page_list_add(pg, color_heap(color));
+}
+
+static struct page_info *alloc_color_heap_page(unsigned int memflags,
+                                               const struct domain *d)
+{
+    struct page_info *pg = NULL;
+    unsigned int i, color = 0;
+    unsigned long max = 0;
+    bool need_tlbflush = false;
+    uint32_t tlbflush_timestamp = 0;
+    bool need_scrub;
+
+    if ( memflags & ~(MEMF_no_refcount | MEMF_no_owner | MEMF_no_tlbflush |
+                      MEMF_no_icache_flush | MEMF_no_scrub) )
+        return NULL;
+
+    spin_lock(&heap_lock);
+
+    for ( i = 0; i < domain_num_llc_colors(d); i++ )
+    {
+        unsigned long free = free_colored_pages[domain_llc_color(d, i)];
+
+        if ( free > max )
+        {
+            color = domain_llc_color(d, i);
+            pg = page_list_first(color_heap(color));
+            max = free;
+        }
+    }
+
+    if ( !pg )
+    {
+        spin_unlock(&heap_lock);
+        return NULL;
+    }
+
+    need_scrub = pg->count_info & PGC_need_scrub;
+    pg->count_info = PGC_state_inuse | (pg->count_info & PGC_colored);
+    free_colored_pages[color]--;
+    page_list_del(pg, color_heap(color));
+
+    if ( !(memflags & MEMF_no_tlbflush) )
+        accumulate_tlbflush(&need_tlbflush, pg, &tlbflush_timestamp);
+
+    init_free_page_fields(pg);
+
+    spin_unlock(&heap_lock);
+
+    if ( !(memflags & MEMF_no_scrub) )
+    {
+        if ( need_scrub )
+            scrub_one_page(pg);
+        else
+            check_one_page(pg);
+    }
+
+    if ( need_tlbflush )
+        filtered_flush_tlb_mask(tlbflush_timestamp);
+
+    flush_page_to_ram(mfn_x(page_to_mfn(pg)),
+                      !(memflags & MEMF_no_icache_flush));
+
+    return pg;
+}
+
+static void __init init_color_heap_pages(struct page_info *pg,
+                                         unsigned long nr_pages)
+{
+    unsigned long i;
+    bool need_scrub = opt_bootscrub == BOOTSCRUB_IDLE;
+
+#ifdef CONFIG_LLC_COLORING
+    if ( buddy_alloc_size >= PAGE_SIZE )
+    {
+        unsigned long buddy_pages = min(PFN_DOWN(buddy_alloc_size), nr_pages);
+
+        init_heap_pages(pg, buddy_pages);
+        nr_pages -= buddy_pages;
+        buddy_alloc_size -= buddy_pages << PAGE_SHIFT;
+        pg += buddy_pages;
+    }
+#endif
+
+    if ( !_color_heap )
+    {
+        unsigned int max_nr_colors = get_max_nr_llc_colors();
+
+        _color_heap = xvmalloc_array(struct page_list_head, max_nr_colors);
+        free_colored_pages = xvzalloc_array(unsigned long, max_nr_colors);
+        if ( !_color_heap || !free_colored_pages )
+            panic("Can't allocate colored heap. Buddy reserved size is too low");
+
+        for ( i = 0; i < max_nr_colors; i++ )
+            INIT_PAGE_LIST_HEAD(color_heap(i));
+    }
+
+    for ( i = 0; i < nr_pages; i++ )
+    {
+        pg[i].count_info = PGC_colored;
+        free_color_heap_page(&pg[i], need_scrub);
+    }
+}
+
+static void dump_color_heap(void)
+{
+    unsigned int color;
+
+    printk("Dumping color heap info\n");
+    for ( color = 0; color < get_max_nr_llc_colors(); color++ )
+        if ( free_colored_pages[color] > 0 )
+            printk("Color heap[%u]: %lu pages\n",
+                   color, free_colored_pages[color]);
+}
+
 void __init end_boot_allocator(void)
 {
     unsigned int i;
@@ -1984,7 +2151,13 @@ void __init end_boot_allocator(void)
     for ( i = nr_bootmem_regions; i-- > 0; )
     {
         struct bootmem_region *r = &bootmem_region_list[i];
-        if ( r->s < r->e )
+
+        if ( r->s >= r->e )
+            continue;
+
+        if ( llc_coloring_enabled )
+            init_color_heap_pages(mfn_to_page(_mfn(r->s)), r->e - r->s);
+        else
             init_heap_pages(mfn_to_page(_mfn(r->s)), r->e - r->s);
     }
     nr_bootmem_regions = 0;
@@ -2480,7 +2653,14 @@ struct page_info *alloc_domheap_pages(
     if ( memflags & MEMF_no_owner )
         memflags |= MEMF_no_refcount;
 
-    if ( !dma_bitsize )
+    /* Only domains are supported for coloring */
+    if ( d && llc_coloring_enabled )
+    {
+        /* Colored allocation must be done on 0 order */
+        if ( order || (pg = alloc_color_heap_page(memflags, d)) == NULL )
+            return NULL;
+    }
+    else if ( !dma_bitsize )
         memflags &= ~MEMF_no_dma;
     else if ( (dma_zone = bits_to_zone(dma_bitsize)) < zone_hi )
         pg = alloc_heap_pages(dma_zone + 1, zone_hi, order, memflags, d);
@@ -2683,6 +2863,9 @@ static void cf_check dump_heap(unsigned char key)
             continue;
         printk("Node %d has %lu unscrubbed pages\n", i, node_need_scrub[i]);
     }
+
+    if ( llc_coloring_enabled )
+        dump_color_heap();
 }
 
 static __init int cf_check register_heap_trigger(void)
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
index 5d1355b3c9..1216d1fbd4 100644
--- a/xen/include/xen/llc-coloring.h
+++ b/xen/include/xen/llc-coloring.h
@@ -11,6 +11,7 @@
 #include 
 
 struct domain;
+struct page_info;
 struct xen_domctl_set_llc_colors;
 
 #ifdef CONFIG_LLC_COLORING
@@ -35,6 +36,8 @@ int dom0_set_llc_colors(struct domain *d);
 int domain_set_llc_colors(struct domain *d,
                           const struct xen_domctl_set_llc_colors *config);
 int domain_set_llc_colors_from_str(struct domain *d, const char *str);
+unsigned int page_to_llc_color(const struct page_info *pg);
+unsigned int get_max_nr_llc_colors(void);
 
 #endif /* __XEN_LLC_COLORING_H__ */
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:28:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:28:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856875.1269455 (Exim 4.92)
	(envelope-from )
	id 1tM8X0-0007He-V8; Fri, 13 Dec 2024 16:28:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856875.1269455; Fri, 13 Dec 2024 16:28: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 1tM8X0-0007HQ-Qv; Fri, 13 Dec 2024 16:28:46 +0000
Received: by outflank-mailman (input) for mailman id 856875;
 Fri, 13 Dec 2024 16:28: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 1tM8Wy-0003wJ-Vf
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:28:44 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 51898afc-b96f-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 17:28:43 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-aab925654d9so39315266b.2
 for ; Fri, 13 Dec 2024 08:28:43 -0800 (PST)
Received: from carlo-ubuntu.minervasys.tech ([193.207.202.156])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa673474d96sm841759266b.96.2024.12.13.08.28.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 08:28: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: 51898afc-b96f-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734107322; x=1734712122; 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=tgbePI0AttbYCT39ufoypfo88obicULa6RDxOdvlbAE=;
        b=OIYJgvHDH1xmriJ1GQbKmbeJHGFK1QulEMEJIV96OKUX3rSDAbgq3KLCjX53dalI1n
         xAb1qc++MnXMkkcBMdL+Ltq8+Tf1CxajQ4YByAs2zGDOL1MddfX+E//Ycs64psltlvbu
         RLiDj10/PhxEOpxk5gbwfbdkdL5JEWmVW/tI41x4w28msSB5eDDJYYMVE1glrqxtJB7j
         lCxceRrK3afiIMVbFMT5ROAIj+Y//e86NhagCL3s7NxiAGdfzoIX/S7cxTBk7KVpxIS+
         dIQw4dXszQGb54/zIOtJ+/RgbPgZKucvBfaGcyH3WGJqYZZmGeJ4QRtMyoQgD5gn0iK5
         mceA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734107322; x=1734712122;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=tgbePI0AttbYCT39ufoypfo88obicULa6RDxOdvlbAE=;
        b=nRbSj1AoKlObsaJyz4mvx34vtTwh4CdnCUaFfrvu9OkIi3s0bldL+vBhvokk+FMbPE
         biuqi9CipXdVCzJ4iV2ymwsiQ8FkOYkAPI7ptflxaOh8K4jM8vmbLGkn5LH/ZUeANT18
         Zg7yK89Hbps9kZGJeZQLRiOVahOIsXrouH9GxURSRK5vkLeJZfCdSbCotjnp/dJXvTOg
         saWUF3uI53rAc6jO7mXhzCC1ankqgDem9Z73LBotX+Q7ynKXvUdV0AkUwB+SPx8e2RQA
         A4s6XPixbW115YDIXcYe/JXqbBzRCXnKlZBjd3pFrwWrEqkjndflHdCvv1FKdR8vwfMv
         0GTg==
X-Gm-Message-State: AOJu0YxBZFxKgCqegR5qvInAf9nYYkeSyT9IWYXClm709d04XR7VkOuG
	YgPA4rUZDS/Vdl3RQTIoPG4yFeWmlQUqZ/87katMDfOYsHkBb8Ly8K65EWaseYRlCvXUmkR1ku0
	fsWw=
X-Gm-Gg: ASbGnct0aLMBddkNd5yB/v8Y/03fYkpoO29cE2zcEgIAthSqWDvoEYj1x2rDaaKcOGr
	8QbDB1+ZUDYIAwyTQ318e4k+tLDphLviHv1EVdCPJhpHMOzMved/obINetnQD0CDBvOK0PTfz6M
	WcAZbBg0eCRiBiI/Q2qOE8EG/pR7J0JekljN56RaoclGC1PUupRO7ViXLe2nTZgV9YLB3D62Mjg
	7GmzHhT63V9moEJUoofQAhJQl9p3sWoUr9matPAtCkIcdydQ9LG+YGYqns7sv0kR1cbi0YRgCL6
	6zegQQe/MDAQ7RCg
X-Google-Smtp-Source: AGHT+IHIXXIN+KmQgkKmBq54I0q9oKub3ahwQfBOGNdnL9of2AipdboITRWoaFpRmuiWBoDNe1F7Pg==
X-Received: by 2002:a17:907:3e1c:b0:aa6:8160:849a with SMTP id a640c23a62f3a-aab7793eb15mr329641066b.22.1734107322492;
        Fri, 13 Dec 2024 08:28:42 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v12 11/12] xen/arm: make consider_modules() available for xen relocation
Date: Fri, 13 Dec 2024 17:28:14 +0100
Message-ID: <20241213162815.9196-12-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Cache coloring must physically relocate Xen in order to color the hypervisor
and consider_modules() is a key function that is needed to find a new
available physical address.

672d67f339c0 ("xen/arm: Split MMU-specific setup_mm() and related code out")
moved consider_modules() under arm32. Move it to mmu/setup.c and make it
non-static so that it can be used outside.

Signed-off-by: Carlo Nonato 
Reviewed-by: Michal Orzel 
---
v12:
- no changes
v11:
- removed useless #include
v10:
- no changes
v9:
- no changes
v8:
- patch adapted to new changes to consider_modules()
v7:
- moved consider_modules() to arm/mmu/setup.c
v6:
- new patch
---
 xen/arch/arm/arm32/mmu/mm.c      | 95 +-------------------------------
 xen/arch/arm/include/asm/setup.h |  3 +
 xen/arch/arm/mmu/setup.c         | 94 +++++++++++++++++++++++++++++++
 3 files changed, 98 insertions(+), 94 deletions(-)

diff --git a/xen/arch/arm/arm32/mmu/mm.c b/xen/arch/arm/arm32/mmu/mm.c
index 063611412b..903d946f07 100644
--- a/xen/arch/arm/arm32/mmu/mm.c
+++ b/xen/arch/arm/arm32/mmu/mm.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -31,100 +32,6 @@ static void __init setup_directmap_mappings(unsigned long base_mfn,
     directmap_virt_end = XENHEAP_VIRT_START + nr_mfns * PAGE_SIZE;
 }
 
-/*
- * Returns the end address of the highest region in the range s..e
- * with required size and alignment that does not conflict with the
- * modules from first_mod to nr_modules.
- *
- * For non-recursive callers first_mod should normally be 0 (all
- * modules and Xen itself) or 1 (all modules but not Xen).
- */
-static paddr_t __init consider_modules(paddr_t s, paddr_t e,
-                                       uint32_t size, paddr_t align,
-                                       int first_mod)
-{
-    const struct membanks *reserved_mem = bootinfo_get_reserved_mem();
-#ifdef CONFIG_STATIC_SHM
-    const struct membanks *shmem = bootinfo_get_shmem();
-#endif
-    const struct bootmodules *mi = &bootinfo.modules;
-    int i;
-    int nr;
-
-    s = (s+align-1) & ~(align-1);
-    e = e & ~(align-1);
-
-    if ( s > e ||  e - s < size )
-        return 0;
-
-    /* First check the boot modules */
-    for ( i = first_mod; i < mi->nr_mods; i++ )
-    {
-        paddr_t mod_s = mi->module[i].start;
-        paddr_t mod_e = mod_s + mi->module[i].size;
-
-        if ( s < mod_e && mod_s < e )
-        {
-            mod_e = consider_modules(mod_e, e, size, align, i+1);
-            if ( mod_e )
-                return mod_e;
-
-            return consider_modules(s, mod_s, size, align, i+1);
-        }
-    }
-
-    /*
-     * i is the current bootmodule we are evaluating, across all
-     * possible kinds of bootmodules.
-     *
-     * When retrieving the corresponding reserved-memory addresses, we
-     * need to index the reserved_mem bank starting from 0, and only counting
-     * the reserved-memory modules. Hence, we need to use i - nr.
-     */
-    nr = mi->nr_mods;
-    for ( ; i - nr < reserved_mem->nr_banks; i++ )
-    {
-        paddr_t r_s = reserved_mem->bank[i - nr].start;
-        paddr_t r_e = r_s + reserved_mem->bank[i - nr].size;
-
-        if ( s < r_e && r_s < e )
-        {
-            r_e = consider_modules(r_e, e, size, align, i + 1);
-            if ( r_e )
-                return r_e;
-
-            return consider_modules(s, r_s, size, align, i + 1);
-        }
-    }
-
-#ifdef CONFIG_STATIC_SHM
-    nr += reserved_mem->nr_banks;
-    for ( ; i - nr < shmem->nr_banks; i++ )
-    {
-        paddr_t r_s, r_e;
-
-        r_s = shmem->bank[i - nr].start;
-
-        /* Shared memory banks can contain INVALID_PADDR as start */
-        if ( INVALID_PADDR == r_s )
-            continue;
-
-        r_e = r_s + shmem->bank[i - nr].size;
-
-        if ( s < r_e && r_s < e )
-        {
-            r_e = consider_modules(r_e, e, size, align, i + 1);
-            if ( r_e )
-                return r_e;
-
-            return consider_modules(s, r_s, size, align, i + 1);
-        }
-    }
-#endif
-
-    return e;
-}
-
 /*
  * Find a contiguous region that fits in the static heap region with
  * required size and alignment, and return the end address of the region
diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index a5a80d9b47..6cf272c160 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -81,6 +81,9 @@ struct init_info
     unsigned int cpuid;
 };
 
+paddr_t consider_modules(paddr_t s, paddr_t e, uint32_t size, paddr_t align,
+                         int first_mod);
+
 #endif
 /*
  * Local variables:
diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c
index 9664e85ee6..196974f3e2 100644
--- a/xen/arch/arm/mmu/setup.c
+++ b/xen/arch/arm/mmu/setup.c
@@ -222,6 +222,100 @@ static void xen_pt_enforce_wnx(void)
     flush_xen_tlb_local();
 }
 
+/*
+ * Returns the end address of the highest region in the range s..e
+ * with required size and alignment that does not conflict with the
+ * modules from first_mod to nr_modules.
+ *
+ * For non-recursive callers first_mod should normally be 0 (all
+ * modules and Xen itself) or 1 (all modules but not Xen).
+ */
+paddr_t __init consider_modules(paddr_t s, paddr_t e,
+                                uint32_t size, paddr_t align,
+                                int first_mod)
+{
+    const struct membanks *reserved_mem = bootinfo_get_reserved_mem();
+#ifdef CONFIG_STATIC_SHM
+    const struct membanks *shmem = bootinfo_get_shmem();
+#endif
+    const struct bootmodules *mi = &bootinfo.modules;
+    int i;
+    int nr;
+
+    s = (s+align-1) & ~(align-1);
+    e = e & ~(align-1);
+
+    if ( s > e ||  e - s < size )
+        return 0;
+
+    /* First check the boot modules */
+    for ( i = first_mod; i < mi->nr_mods; i++ )
+    {
+        paddr_t mod_s = mi->module[i].start;
+        paddr_t mod_e = mod_s + mi->module[i].size;
+
+        if ( s < mod_e && mod_s < e )
+        {
+            mod_e = consider_modules(mod_e, e, size, align, i+1);
+            if ( mod_e )
+                return mod_e;
+
+            return consider_modules(s, mod_s, size, align, i+1);
+        }
+    }
+
+    /*
+     * i is the current bootmodule we are evaluating, across all
+     * possible kinds of bootmodules.
+     *
+     * When retrieving the corresponding reserved-memory addresses, we
+     * need to index the reserved_mem bank starting from 0, and only counting
+     * the reserved-memory modules. Hence, we need to use i - nr.
+     */
+    nr = mi->nr_mods;
+    for ( ; i - nr < reserved_mem->nr_banks; i++ )
+    {
+        paddr_t r_s = reserved_mem->bank[i - nr].start;
+        paddr_t r_e = r_s + reserved_mem->bank[i - nr].size;
+
+        if ( s < r_e && r_s < e )
+        {
+            r_e = consider_modules(r_e, e, size, align, i + 1);
+            if ( r_e )
+                return r_e;
+
+            return consider_modules(s, r_s, size, align, i + 1);
+        }
+    }
+
+#ifdef CONFIG_STATIC_SHM
+    nr += reserved_mem->nr_banks;
+    for ( ; i - nr < shmem->nr_banks; i++ )
+    {
+        paddr_t r_s, r_e;
+
+        r_s = shmem->bank[i - nr].start;
+
+        /* Shared memory banks can contain INVALID_PADDR as start */
+        if ( INVALID_PADDR == r_s )
+            continue;
+
+        r_e = r_s + shmem->bank[i - nr].size;
+
+        if ( s < r_e && r_s < e )
+        {
+            r_e = consider_modules(r_e, e, size, align, i + 1);
+            if ( r_e )
+                return r_e;
+
+            return consider_modules(s, r_s, size, align, i + 1);
+        }
+    }
+#endif
+
+    return e;
+}
+
 /*
  * Boot-time pagetable setup.
  * Changes here may need matching changes in head.S
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:30:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:30:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856904.1269465 (Exim 4.92)
	(envelope-from )
	id 1tM8Ye-0001tZ-99; Fri, 13 Dec 2024 16:30:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856904.1269465; Fri, 13 Dec 2024 16:30: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 1tM8Ye-0001tQ-6V; Fri, 13 Dec 2024 16:30:28 +0000
Received: by outflank-mailman (input) for mailman id 856904;
 Fri, 13 Dec 2024 16:30: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 1tM8TQ-000061-U1
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:25:04 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cee4c468-b96e-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 17:25:04 +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 D46FC1F394;
 Fri, 13 Dec 2024 16:25:03 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id A3B03137CF;
 Fri, 13 Dec 2024 16:25:03 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id mPZ0Jt9fXGf7SgAAD6G6ig
 (envelope-from ); Fri, 13 Dec 2024 16: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: cee4c468-b96e-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734107104; 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=U4Ln9oY8teJqj0oQ6om9doDIAfM1X4V+dyEL2CQtrKA=;
	b=L1ZIHnIyoOdvizrUkZEUJ6ZpF7AD43wTTSSFRxR7g6yCHAFANNQw6Da3JiVWlPUUcpVoZp
	iq5nzZfUF5oMCs2/rkx7A158z/cND+qs9tQCI9KZ6C+kb5JqQgWWpHtXInUrAVU3LDtGJw
	HqJ2shDcLoIPLS1S7D2CSm7uMRjgbAo=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734107103; 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=U4Ln9oY8teJqj0oQ6om9doDIAfM1X4V+dyEL2CQtrKA=;
	b=l7ix/qwFk+VZZ1cBNERb62DfmAzN4SuKkL+jMGRZMwzwttPax1wPIoEBj8Ujcz9pIVNjCc
	Ag0lN9CkRVvGlzBZr+J0DVkSxI3RwOnJkqK79eIARV8OytA1sipaYgfEex/hPZ2DR8P7UD
	oWsj5lp2o0jVifmaQ1P353I6P03QqP4=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Anthony PERARD ,
	Samuel Thibault ,
	Julien Grall 
Subject: [PATCH v3 7/7] tools/xenstored: use new stable interface instead of libxenctrl
Date: Fri, 13 Dec 2024 17:24:21 +0100
Message-ID: <20241213162421.16782-8-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213162421.16782-1-jgross@suse.com>
References: <20241213162421.16782-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.80
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)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_FIVE(0.00)[5];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Level: 

Replace the current use of the unstable xc_domain_getinfo_single()
interface with the stable domctl XEN_DOMCTL_get_domain_state call
via the new libxenmanage library.

This will remove the last usage of libxenctrl by Xenstore, so update
the library dependencies accordingly.

For now only do a direct replacement without using the functionality
of obtaining information about domains having changed the state.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
V1:
- use library instead of direct hypercall, only replace current
  libxenctrl use case

Please note that this patch can be committed only after the related
Mini-OS patch "config: add support for libxenmanage" has gone in AND
the Mini-OS commit-id has been updated in Config.mk accordingly!

Signed-off-by: Juergen Gross 
---
 stubdom/Makefile                |  8 ++---
 stubdom/mini-os.mk              |  1 +
 tools/xenstored/Makefile        |  2 +-
 tools/xenstored/Makefile.common |  2 +-
 tools/xenstored/core.h          |  1 -
 tools/xenstored/domain.c        | 52 ++++++++++++---------------------
 tools/xenstored/lu.c            |  1 +
 tools/xenstored/lu_daemon.c     |  1 +
 8 files changed, 28 insertions(+), 40 deletions(-)

diff --git a/stubdom/Makefile b/stubdom/Makefile
index 2a81af28a1..ca800b243c 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -307,7 +307,7 @@ endif
 # libraries under tools/libs
 #######
 
-STUB_LIBS := toolcore toollog evtchn gnttab call foreignmemory devicemodel ctrl guest
+STUB_LIBS := toolcore toollog evtchn gnttab call foreignmemory devicemodel ctrl guest manage
 
 LIBDEP_guest := cross-zlib
 
@@ -465,7 +465,7 @@ grub: cross-polarssl grub-upstream $(CROSS_ROOT) grub-$(XEN_TARGET_ARCH)-minios-
 # xenstore
 ##########
 
-xenstore-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog ctrl
+xenstore-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog manage
 xenstore-minios.gen.cfg: xenstore-minios.cfg Makefile
 	$(GEN_config) >$@
 
@@ -480,7 +480,7 @@ xenstore: $(CROSS_ROOT) xenstore-minios-config.mk
 # xenstorepvh
 #############
 
-xenstorepvh-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog ctrl
+xenstorepvh-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog manage
 xenstorepvh-minios.gen.cfg: xenstorepvh-minios.cfg Makefile
 	$(GEN_config) >$@
 
@@ -523,7 +523,7 @@ else
 pv-grub-if-enabled:
 endif
 
-XENSTORE_DEPS := libxenevtchn libxengnttab libxenctrl
+XENSTORE_DEPS := libxenevtchn libxengnttab libxenmanage
 
 .PHONY: xenstore-stubdom
 xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore $(XENSTORE_DEPS) xenstore
diff --git a/stubdom/mini-os.mk b/stubdom/mini-os.mk
index 7e4968e026..be32302f9e 100644
--- a/stubdom/mini-os.mk
+++ b/stubdom/mini-os.mk
@@ -13,5 +13,6 @@ GNTTAB_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/gnttab
 CALL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/call
 FOREIGNMEMORY_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/foreignmemory
 DEVICEMODEL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/devicemodel
+MANAGE_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/manage
 CTRL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/ctrl
 GUEST_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/guest
diff --git a/tools/xenstored/Makefile b/tools/xenstored/Makefile
index 09adfe1d50..81c42838e0 100644
--- a/tools/xenstored/Makefile
+++ b/tools/xenstored/Makefile
@@ -5,7 +5,7 @@ include Makefile.common
 
 xenstored: LDLIBS += $(LDLIBS_libxenevtchn)
 xenstored: LDLIBS += $(LDLIBS_libxengnttab)
-xenstored: LDLIBS += $(LDLIBS_libxenctrl)
+xenstored: LDLIBS += $(LDLIBS_libxenmanage)
 xenstored: LDLIBS += -lrt
 xenstored: LDLIBS += $(SOCKET_LIBS)
 
diff --git a/tools/xenstored/Makefile.common b/tools/xenstored/Makefile.common
index 27fdb3b49e..271134fcc1 100644
--- a/tools/xenstored/Makefile.common
+++ b/tools/xenstored/Makefile.common
@@ -12,7 +12,7 @@ XENSTORED_OBJS-$(CONFIG_MiniOS) += minios.o lu_minios.o
 # Include configure output (config.h)
 CFLAGS += -include $(XEN_ROOT)/tools/config.h
 CFLAGS += $(CFLAGS_libxenevtchn)
-CFLAGS += $(CFLAGS_libxenctrl)
+CFLAGS += $(CFLAGS_libxenmanage)
 CFLAGS += $(CFLAGS_libxentoolcore)
 
 $(XENSTORED_OBJS-y): CFLAGS += $(CFLAGS_libxengnttab)
diff --git a/tools/xenstored/core.h b/tools/xenstored/core.h
index e58779e88c..632886cecf 100644
--- a/tools/xenstored/core.h
+++ b/tools/xenstored/core.h
@@ -19,7 +19,6 @@
 #ifndef _XENSTORED_CORE_H
 #define _XENSTORED_CORE_H
 
-#include 
 #include 
 
 #include 
diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c
index 64c8fd0cc3..a6506a5bb2 100644
--- a/tools/xenstored/domain.c
+++ b/tools/xenstored/domain.c
@@ -34,14 +34,15 @@
 #include "control.h"
 
 #include 
-#include 
+#include 
+#include 
 #include 
 
 #ifdef __MINIOS__
 #include 
 #endif
 
-static xc_interface **xc_handle;
+static xenmanage_handle *xm_handle;
 xengnttab_handle **xgt_handle;
 static evtchn_port_t virq_port;
 
@@ -619,32 +620,28 @@ static int destroy_domain(void *_domain)
 	return 0;
 }
 
-static bool get_domain_info(unsigned int domid, xc_domaininfo_t *dominfo)
-{
-	return xc_domain_getinfo_single(*xc_handle, domid, dominfo) == 0;
-}
-
 static int check_domain(const void *k, void *v, void *arg)
 {
-	xc_domaininfo_t dominfo;
+	unsigned int state;
 	struct connection *conn;
-	bool dom_valid;
+	int dom_invalid;
 	struct domain *domain = v;
 	bool *notify = arg;
 
-	dom_valid = get_domain_info(domain->domid, &dominfo);
+	dom_invalid = xenmanage_get_domain_info(xm_handle, domain->domid,
+						&state, NULL);
 	if (!domain->introduced) {
-		if (!dom_valid)
+		if (dom_invalid)
 			talloc_free(domain);
 		return 0;
 	}
-	if (dom_valid) {
-		if ((dominfo.flags & XEN_DOMINF_shutdown)
+	if (!dom_invalid) {
+		if ((state & XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN)
 		    && !domain->shutdown) {
 			domain->shutdown = true;
 			*notify = true;
 		}
-		if (!(dominfo.flags & XEN_DOMINF_dying))
+		if (!(state & XENMANAGE_GETDOMSTATE_STATE_DEAD))
 			return 0;
 	}
 	if (domain->conn) {
@@ -786,10 +783,9 @@ static struct domain *find_or_alloc_domain(const void *ctx, unsigned int domid)
 static struct domain *find_or_alloc_existing_domain(unsigned int domid)
 {
 	struct domain *domain;
-	xc_domaininfo_t dominfo;
 
 	domain = find_domain_struct(domid);
-	if (!domain && get_domain_info(domid, &dominfo))
+	if (!domain && !xenmanage_get_domain_info(xm_handle, domid, NULL, NULL))
 		domain = alloc_domain(NULL, domid);
 
 	return domain;
@@ -1187,12 +1183,6 @@ int do_reset_watches(const void *ctx, struct connection *conn,
 	return 0;
 }
 
-static int close_xc_handle(void *_handle)
-{
-	xc_interface_close(*(xc_interface**)_handle);
-	return 0;
-}
-
 static int close_xgt_handle(void *_handle)
 {
 	xengnttab_close(*(xengnttab_handle **)_handle);
@@ -1258,15 +1248,9 @@ void domain_early_init(void)
 	if (!domhash)
 		barf_perror("Failed to allocate domain hashtable");
 
-	xc_handle = talloc(talloc_autofree_context(), xc_interface*);
-	if (!xc_handle)
-		barf_perror("Failed to allocate domain handle");
-
-	*xc_handle = xc_interface_open(0,0,0);
-	if (!*xc_handle)
-		barf_perror("Failed to open connection to hypervisor");
-
-	talloc_set_destructor(xc_handle, close_xc_handle);
+	xm_handle = xenmanage_open(NULL, 0);
+	if (!xm_handle)
+		barf_perror("Failed to open connection to libxenmanage");
 
 	xgt_handle = talloc(talloc_autofree_context(), xengnttab_handle*);
 	if (!xgt_handle)
@@ -1306,6 +1290,8 @@ void domain_deinit(void)
 {
 	if (virq_port)
 		xenevtchn_unbind(xce_handle, virq_port);
+
+	xenmanage_close(xm_handle);
 }
 
 /*
@@ -1335,13 +1321,13 @@ int domain_alloc_permrefs(struct node_perms *perms)
 {
 	unsigned int i, domid;
 	struct domain *d;
-	xc_domaininfo_t dominfo;
 
 	for (i = 0; i < perms->num; i++) {
 		domid = perms->p[i].id;
 		d = find_domain_struct(domid);
 		if (!d) {
-			if (!get_domain_info(domid, &dominfo))
+			if (xenmanage_get_domain_info(xm_handle, domid,
+						      NULL, NULL))
 				perms->p[i].perms |= XS_PERM_IGNORE;
 			else if (!alloc_domain(NULL, domid))
 				return ENOMEM;
diff --git a/tools/xenstored/lu.c b/tools/xenstored/lu.c
index bec2a84e10..4fccbbc195 100644
--- a/tools/xenstored/lu.c
+++ b/tools/xenstored/lu.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/tools/xenstored/lu_daemon.c b/tools/xenstored/lu_daemon.c
index 6df6c80a2a..88d8d9e1b3 100644
--- a/tools/xenstored/lu_daemon.c
+++ b/tools/xenstored/lu_daemon.c
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 #include 
 
 #include "talloc.h"
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:31:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:31:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856927.1269475 (Exim 4.92)
	(envelope-from )
	id 1tM8ZC-0002eR-H9; Fri, 13 Dec 2024 16:31:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856927.1269475; Fri, 13 Dec 2024 16:31: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 1tM8ZC-0002eK-E2; Fri, 13 Dec 2024 16:31:02 +0000
Received: by outflank-mailman (input) for mailman id 856927;
 Fri, 13 Dec 2024 16:31: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 1tM8X2-0003wJ-0U
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:28:48 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 52d6ee14-b96f-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 17:28:45 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5d3e9f60bf4so3102557a12.3
 for ; Fri, 13 Dec 2024 08:28:45 -0800 (PST)
Received: from carlo-ubuntu.minervasys.tech ([193.207.202.156])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa673474d96sm841759266b.96.2024.12.13.08.28.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 08:28: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: 52d6ee14-b96f-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734107325; x=1734712125; 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=9Q+kUbuWvfsq5GAUn2XdzEBq7xjusccOT8RsDI7ZLrc=;
        b=ydHb4eKtl5GTBw66vJP/5ijH84fD7Irkevy2C4ufhU7EeNYhEd7UBzzVEW+JS31gKP
         /fw527CrQhV2PSBdF7xYFe5R5+nXHhq1it2Ze6q+qwzkMsG5m28UjTAps6ScDuJkvh2r
         nyfa/6Jduxt3wNdSexCpzoMQKIOH354eWH1e6EJNalXdFRcsCGEbFnLwOYLgNi0frGju
         1UzPqU96/7N655HW4PK17qFXbjtNU//cCr7fYERmk3IRqNX8VVAP2+HaRv+yRb0HTzOj
         ux+ZTjkKd7pAaLbNuztuKscAhJ3OfI/Nj52oy27hpbQs+9tTCVAlmBQOTD+Zg7F1JWjh
         ZB8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734107325; x=1734712125;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=9Q+kUbuWvfsq5GAUn2XdzEBq7xjusccOT8RsDI7ZLrc=;
        b=n45YOJ/w9qc8IYkcr5WWUcQ6nnlHNEyFeSYsydFnjOyTXuA2E+m+9+/ahCA/iD8pyz
         EgYF5sCCl8EWxEycVOYLTBvEHt7NMZbXHFDMb75JaPtgWb19yLYucUu31gC0oOWoK0FF
         Oxou+8sbfioqTbeOgAWEjKADH55+Y7rwBD+k/zh14VpGPARwTXZfBJ3D9O/nId81iAjy
         oebYda5YBMnVwA+V5gzift6DVqt2WQtpDZ318+FXOuQK96FkMjBIL072f2y4d0dYcfv2
         FvYOWUYBS5+MOD4FLTljknpiQ3AXUXrcF35H1GTQdVu21Q7R812SFAHOOm9YSVIbAITQ
         ilKQ==
X-Gm-Message-State: AOJu0Yx623k8lNXEZWuoDBpr9oAtu4ntnuoh++8xMvC8srKlBxUmYytz
	kcYLtRGfqIfDG4MJmPHdV6toOLVG9Wv8iEZAGIaV8qevp1Ef1Zytt9PIQZU4Wbih6U0hECJRyv7
	BxV8=
X-Gm-Gg: ASbGncvAE2Mx9v30LlQ2X0GwP6inDctAmpd4x/0UBwTK0XOe3GeFtUbgpzrB6bttHm4
	k7P88D3u4NP6y2fXGQpO2FwiytLL1HCmnWn8ppQdknyu57uu2e0d2rme5M8yt4QburssdAQVjD0
	Bi/2waVBf02nB8D2ZhdaCNZ2VIdSfaSSvPTBIuJoB2t9O037fWaSD5f+7Q1zzfOKBmrrLIJpGK2
	JBC1dYbuzelyqvnX9OWPMd8gdTs5nAjYaWhA66afvia6oc3tV5Egm5QpuRipGFM0Sea5iWM0xpA
	lI9We7p6rPO9XrcH
X-Google-Smtp-Source: AGHT+IFM0tJWCl6LcCDR4DhR2PBYBdW1jgcaoSKtUxaX17DXIlCa2d0TLtlhZff3UoUbU3NCbBPfJw==
X-Received: by 2002:a17:907:1c0b:b0:aa6:7c36:3423 with SMTP id a640c23a62f3a-aab778bf059mr297768166b.1.1734107324628;
        Fri, 13 Dec 2024 08:28:44 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v12 12/12] xen/arm: add cache coloring support for Xen image
Date: Fri, 13 Dec 2024 17:28:15 +0100
Message-ID: <20241213162815.9196-13-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Xen image is relocated to a new colored physical space. Some relocation
functionalities must be brought back:
- the virtual address of the new space is taken from 0c18fb76323b
  ("xen/arm: Remove unused BOOT_RELOC_VIRT_START").
- relocate_xen() and get_xen_paddr() are taken from f60658c6ae47
  ("xen/arm: Stop relocating Xen").

setup_pagetables() must be adapted for coloring and for relocation. Runtime
page tables are used to map the colored space, but they are also linked in
boot tables so that the new space is temporarily available for relocation.
This implies that Xen protection must happen after the copy.

Finally, since the alternative framework needs to remap the Xen text and
inittext sections, this operation must be done in a coloring-aware way.
The function xen_remap_colored() is introduced for that.

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
Reviewed-by: Jan Beulich  # common
---
v12:
- FUNC instead of ENTRY in head.S for relocate_xen
- dc cvau instead of dc cvav in relocate_xen()
- added relocate_and_switch_ttbr() to make setup_pagetables() code more clear
v11:
- else if -> if in xen_colored_mfn()
v10:
- no changes
v9:
- patch adapted to changes to setup_pagetables()
v8:
- moved xen_colored_map_size() to arm/llc-coloring.c
v7:
- added BUG_ON() checks to arch_llc_coloring_init() and
  create_llc_coloring_mappings()
v6:
- squashed with BOOT_RELOC_VIRT_START patch
- consider_modules() moved in another patch
- removed psci and smpboot code because of new idmap work already handles that
- moved xen_remap_colored() in alternative.c since it's only used there
- removed xen_colored_temp[] in favor of xen_xenmap[] usage for mapping
- use of boot_module_find_by_kind() to remove the need of extra parameter in
  setup_pagetables()
- moved get_xen_paddr() in arm/llc-coloring.c since it's only used there
v5:
- FIXME: consider_modules copy pasted since it got moved
v4:
- removed set_value_for_secondary() because it was wrongly cleaning cache
- relocate_xen() now calls switch_ttbr_id()
---
 xen/arch/arm/alternative.c            |  26 ++++++-
 xen/arch/arm/arm64/mmu/head.S         |  58 ++++++++++++++-
 xen/arch/arm/arm64/mmu/mm.c           |  29 ++++++++
 xen/arch/arm/include/asm/mmu/layout.h |   3 +
 xen/arch/arm/include/asm/mmu/mm.h     |   1 +
 xen/arch/arm/llc-coloring.c           |  63 ++++++++++++++++
 xen/arch/arm/mmu/setup.c              | 103 ++++++++++++++++++++++----
 xen/arch/arm/setup.c                  |  10 ++-
 xen/common/llc-coloring.c             |  18 +++++
 xen/include/xen/llc-coloring.h        |  13 ++++
 10 files changed, 304 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index fec7dbd2cd..2c1af6e7e4 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -191,6 +192,25 @@ static int __apply_alternatives_multi_stop(void *xenmap)
     return 0;
 }
 
+static void __init *xen_remap_colored(mfn_t xen_mfn, paddr_t xen_size)
+{
+    unsigned int i;
+    void *xenmap;
+    mfn_t *xen_colored_mfns, mfn;
+
+    xen_colored_mfns = xmalloc_array(mfn_t, xen_size >> PAGE_SHIFT);
+    if ( !xen_colored_mfns )
+        panic("Can't allocate LLC colored MFNs\n");
+
+    for_each_xen_colored_mfn ( xen_mfn, mfn, i )
+        xen_colored_mfns[i] = mfn;
+
+    xenmap = vmap(xen_colored_mfns, xen_size >> PAGE_SHIFT);
+    xfree(xen_colored_mfns);
+
+    return xenmap;
+}
+
 /*
  * This function should only be called during boot and before CPU0 jump
  * into the idle_loop.
@@ -209,7 +229,11 @@ void __init apply_alternatives_all(void)
      * The text and inittext section are read-only. So re-map Xen to
      * be able to patch the code.
      */
-    xenmap = vmap_contig(xen_mfn, 1U << xen_order);
+    if ( llc_coloring_enabled )
+        xenmap = xen_remap_colored(xen_mfn, xen_size);
+    else
+        xenmap = vmap_contig(xen_mfn, 1U << xen_order);
+
     /* Re-mapping Xen is not expected to fail during boot. */
     BUG_ON(!xenmap);
 
diff --git a/xen/arch/arm/arm64/mmu/head.S b/xen/arch/arm/arm64/mmu/head.S
index 665a51a337..634156f83d 100644
--- a/xen/arch/arm/arm64/mmu/head.S
+++ b/xen/arch/arm/arm64/mmu/head.S
@@ -428,6 +428,61 @@ FUNC_LOCAL(fail)
         b     1b
 END(fail)
 
+/*
+ * Copy Xen to new location and switch TTBR
+ * x0    ttbr
+ * x1    source address
+ * x2    destination address
+ * x3    length
+ *
+ * Source and destination must be word aligned, length is rounded up
+ * to a 16 byte boundary.
+ *
+ * MUST BE VERY CAREFUL when saving things to RAM over the copy
+ */
+FUNC(relocate_xen)
+        /*
+         * Copy 16 bytes at a time using:
+         *   x9: counter
+         *   x10: data
+         *   x11: data
+         *   x12: source
+         *   x13: destination
+         */
+        mov     x9, x3
+        mov     x12, x1
+        mov     x13, x2
+
+1:      ldp     x10, x11, [x12], #16
+        stp     x10, x11, [x13], #16
+
+        subs    x9, x9, #16
+        bgt     1b
+
+        /*
+         * Flush destination from dcache using:
+         *   x9: counter
+         *   x10: step
+         *   x11: vaddr
+         *
+         * This is to ensure data is visible to the instruction cache
+         */
+        dsb   sy
+
+        mov   x9, x3
+        ldr   x10, =dcache_line_bytes /* x10 := step */
+        ldr   x10, [x10]
+        mov   x11, x2
+
+1:      dc    cvau, x11
+
+        add   x11, x11, x10
+        subs  x9, x9, x10
+        bgt   1b
+
+        /* No need for dsb/isb because they are alredy done in switch_ttbr_id */
+        b switch_ttbr_id
+
 /*
  * Switch TTBR
  *
@@ -453,7 +508,8 @@ FUNC(switch_ttbr_id)
 
         /*
          * 5) Flush I-cache
-         * This should not be necessary but it is kept for safety.
+         * This should not be necessary in the general case, but it's needed
+         * for cache coloring because code is relocated in that case.
          */
         ic     iallu
         isb
diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c
index 671eaadbc1..f1f2543902 100644
--- a/xen/arch/arm/arm64/mmu/mm.c
+++ b/xen/arch/arm/arm64/mmu/mm.c
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
 #include 
+#include 
 #include 
 #include 
 
@@ -138,8 +139,36 @@ void update_boot_mapping(bool enable)
 }
 
 extern void switch_ttbr_id(uint64_t ttbr);
+extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len);
 
 typedef void (switch_ttbr_fn)(uint64_t ttbr);
+typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t len);
+
+void __init relocate_and_switch_ttbr(uint64_t ttbr) {
+    vaddr_t id_addr = virt_to_maddr(relocate_xen);
+    relocate_xen_fn *fn = (relocate_xen_fn *)id_addr;
+    lpae_t pte;
+
+    /* Enable the identity mapping in the boot page tables */
+    update_identity_mapping(true);
+
+    /* Enable the identity mapping in the runtime page tables */
+    pte = pte_of_xenaddr((vaddr_t)relocate_xen);
+    pte.pt.table = 1;
+    pte.pt.xn = 0;
+    pte.pt.ro = 1;
+    write_pte(&xen_third_id[third_table_offset(id_addr)], pte);
+
+    /* Relocate Xen and switch TTBR */
+    fn(ttbr, _start, (void *)BOOT_RELOC_VIRT_START, _end - _start);
+
+    /*
+     * Disable the identity mapping in the runtime page tables.
+     * Note it is not necessary to disable it in the boot page tables
+     * because they are not going to be used by this CPU anymore.
+     */
+    update_identity_mapping(false);
+}
 
 void __init switch_ttbr(uint64_t ttbr)
 {
diff --git a/xen/arch/arm/include/asm/mmu/layout.h b/xen/arch/arm/include/asm/mmu/layout.h
index a3b546465b..19c0ec63a5 100644
--- a/xen/arch/arm/include/asm/mmu/layout.h
+++ b/xen/arch/arm/include/asm/mmu/layout.h
@@ -30,6 +30,7 @@
  *  10M -  12M   Fixmap: special-purpose 4K mapping slots
  *  12M -  16M   Early boot mapping of FDT
  *  16M -  18M   Livepatch vmap (if compiled in)
+ *  16M -  24M   Cache-colored Xen text, data, bss (temporary, if compiled in)
  *
  *   1G -   2G   VMAP: ioremap and early_ioremap
  *
@@ -74,6 +75,8 @@
 #define BOOT_FDT_VIRT_START     (FIXMAP_VIRT_START + FIXMAP_VIRT_SIZE)
 #define BOOT_FDT_VIRT_SIZE      _AT(vaddr_t, MB(4))
 
+#define BOOT_RELOC_VIRT_START   (BOOT_FDT_VIRT_START + BOOT_FDT_VIRT_SIZE)
+
 #ifdef CONFIG_LIVEPATCH
 #define LIVEPATCH_VMAP_START    (BOOT_FDT_VIRT_START + BOOT_FDT_VIRT_SIZE)
 #define LIVEPATCH_VMAP_SIZE    _AT(vaddr_t, MB(2))
diff --git a/xen/arch/arm/include/asm/mmu/mm.h b/xen/arch/arm/include/asm/mmu/mm.h
index c5e03a66bf..f5a00558c4 100644
--- a/xen/arch/arm/include/asm/mmu/mm.h
+++ b/xen/arch/arm/include/asm/mmu/mm.h
@@ -31,6 +31,7 @@ void dump_pt_walk(paddr_t ttbr, paddr_t addr,
 
 /* Switch to a new root page-tables */
 extern void switch_ttbr(uint64_t ttbr);
+extern void relocate_and_switch_ttbr(uint64_t ttbr);
 
 #endif /* __ARM_MMU_MM_H__ */
 
diff --git a/xen/arch/arm/llc-coloring.c b/xen/arch/arm/llc-coloring.c
index 1c7b92bc45..7cb4ecb50e 100644
--- a/xen/arch/arm/llc-coloring.c
+++ b/xen/arch/arm/llc-coloring.c
@@ -9,6 +9,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -64,8 +65,70 @@ unsigned int __init get_llc_way_size(void)
     return line_size * num_sets;
 }
 
+/**
+ * get_xen_paddr - get physical address to relocate Xen to
+ *
+ * Xen is relocated to as near to the top of RAM as possible and
+ * aligned to a XEN_PADDR_ALIGN boundary.
+ */
+static paddr_t __init get_xen_paddr(paddr_t xen_size)
+{
+    const struct membanks *mem = bootinfo_get_mem();
+    paddr_t min_size, paddr = 0;
+    unsigned int i;
+
+    min_size = ROUNDUP(xen_size, XEN_PADDR_ALIGN);
+
+    /* Find the highest bank with enough space. */
+    for ( i = 0; i < mem->nr_banks; i++ )
+    {
+        const struct membank *bank = &mem->bank[i];
+        paddr_t s, e;
+
+        if ( bank->size >= min_size )
+        {
+            e = consider_modules(bank->start, bank->start + bank->size,
+                                 min_size, XEN_PADDR_ALIGN, 0);
+            if ( !e )
+                continue;
+
+#ifdef CONFIG_ARM_32
+            /* Xen must be under 4GB */
+            if ( e > GB(4) )
+                e = GB(4);
+            if ( e < bank->start )
+                continue;
+#endif
+
+            s = e - min_size;
+
+            if ( s > paddr )
+                paddr = s;
+        }
+    }
+
+    if ( !paddr )
+        panic("Not enough memory to relocate Xen\n");
+
+    printk("Placing Xen at 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
+           paddr, paddr + min_size);
+
+    return paddr;
+}
+
+static paddr_t __init xen_colored_map_size(void)
+{
+    return ROUNDUP((_end - _start) * get_max_nr_llc_colors(), XEN_PADDR_ALIGN);
+}
+
 void __init arch_llc_coloring_init(void)
 {
+    struct bootmodule *xen_bootmodule = boot_module_find_by_kind(BOOTMOD_XEN);
+
+    BUG_ON(!xen_bootmodule);
+
+    xen_bootmodule->size = xen_colored_map_size();
+    xen_bootmodule->start = get_xen_paddr(xen_bootmodule->size);
 }
 
 /*
diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c
index 196974f3e2..073f762a32 100644
--- a/xen/arch/arm/mmu/setup.c
+++ b/xen/arch/arm/mmu/setup.c
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -20,6 +21,9 @@
 #undef virt_to_mfn
 #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
 
+#define virt_to_reloc_virt(virt) \
+    (((vaddr_t)virt) - XEN_VIRT_START + BOOT_RELOC_VIRT_START)
+
 /* Main runtime page tables */
 
 /*
@@ -69,6 +73,7 @@ static void __init __maybe_unused build_assertions(void)
     /* 2MB aligned regions */
     BUILD_BUG_ON(XEN_VIRT_START & ~SECOND_MASK);
     BUILD_BUG_ON(FIXMAP_ADDR(0) & ~SECOND_MASK);
+    BUILD_BUG_ON(BOOT_RELOC_VIRT_START & ~SECOND_MASK);
     /* 1GB aligned regions */
 #ifdef CONFIG_ARM_32
     BUILD_BUG_ON(XENHEAP_VIRT_START & ~FIRST_MASK);
@@ -138,6 +143,9 @@ static void __init __maybe_unused build_assertions(void)
 
 lpae_t __init pte_of_xenaddr(vaddr_t va)
 {
+    if ( llc_coloring_enabled )
+        va = virt_to_reloc_virt(va);
+
     return mfn_to_xen_entry(virt_to_mfn(va), MT_NORMAL);
 }
 
@@ -316,6 +324,32 @@ paddr_t __init consider_modules(paddr_t s, paddr_t e,
     return e;
 }
 
+static void __init create_llc_coloring_mappings(void)
+{
+    lpae_t pte;
+    unsigned int i;
+    struct bootmodule *xen_bootmodule = boot_module_find_by_kind(BOOTMOD_XEN);
+    mfn_t start_mfn = maddr_to_mfn(xen_bootmodule->start), mfn;
+
+    for_each_xen_colored_mfn ( start_mfn, mfn, i )
+    {
+        pte = mfn_to_xen_entry(mfn, MT_NORMAL);
+        pte.pt.table = 1; /* level 3 mappings always have this bit set */
+        xen_xenmap[i] = pte;
+    }
+
+    for ( i = 0; i < XEN_NR_ENTRIES(2); i++ )
+    {
+        vaddr_t va = BOOT_RELOC_VIRT_START + (i << XEN_PT_LEVEL_SHIFT(2));
+
+        pte = mfn_to_xen_entry(virt_to_mfn(xen_xenmap +
+                                           i * XEN_PT_LPAE_ENTRIES),
+                               MT_NORMAL);
+        pte.pt.table = 1;
+        write_pte(&boot_second[second_table_offset(va)], pte);
+    }
+}
+
 /*
  * Boot-time pagetable setup.
  * Changes here may need matching changes in head.S
@@ -326,6 +360,14 @@ void __init setup_pagetables(void)
     lpae_t pte, *p;
     int i;
 
+    /*
+     * In case of cache coloring, map the new physical space in the boot page
+     * tables. From now on, pte_of_xenaddr() will translate addresses to this
+     * new space.
+     */
+    if ( llc_coloring_enabled )
+        create_llc_coloring_mappings();
+
     arch_setup_page_tables();
 
 #ifdef CONFIG_ARM_64
@@ -353,13 +395,7 @@ void __init setup_pagetables(void)
             break;
         pte = pte_of_xenaddr(va);
         pte.pt.table = 1; /* third level mappings always have this bit set */
-        if ( is_kernel_text(va) || is_kernel_inittext(va) )
-        {
-            pte.pt.xn = 0;
-            pte.pt.ro = 1;
-        }
-        if ( is_kernel_rodata(va) )
-            pte.pt.ro = 1;
+        pte.pt.xn = 0; /* Permissions will be enforced later. Allow execution */
         xen_xenmap[i] = pte;
     }
 
@@ -379,19 +415,54 @@ void __init setup_pagetables(void)
     pte.pt.table = 1;
     xen_second[second_table_offset(FIXMAP_ADDR(0))] = pte;
 
-#ifdef CONFIG_ARM_64
-    ttbr = virt_to_maddr(xen_pgtable);
-#else
-    ttbr = virt_to_maddr(cpu0_pgtable);
+#ifdef CONFIG_ARM_32
+    per_cpu(xen_pgtable, 0) = cpu0_pgtable;
 #endif
 
-    switch_ttbr(ttbr);
+    if ( llc_coloring_enabled ) {
+        ttbr = virt_to_maddr(virt_to_reloc_virt(THIS_CPU_PGTABLE));
+        relocate_and_switch_ttbr(ttbr);
+    }
+    else {
+        ttbr = virt_to_maddr(THIS_CPU_PGTABLE);
+        switch_ttbr(ttbr);
+    }
 
-    xen_pt_enforce_wnx();
+    /* Protect Xen */
+    for ( i = 0; i < XEN_NR_ENTRIES(3); i++ )
+    {
+        vaddr_t va = XEN_VIRT_START + (i << PAGE_SHIFT);
+        lpae_t *entry = xen_xenmap + i;
 
-#ifdef CONFIG_ARM_32
-    per_cpu(xen_pgtable, 0) = cpu0_pgtable;
-#endif
+        if ( !is_kernel(va) )
+            break;
+
+        pte = read_atomic(entry);
+
+        if ( is_kernel_text(va) || is_kernel_inittext(va) )
+        {
+            pte.pt.xn = 0;
+            pte.pt.ro = 1;
+        }
+        else if ( is_kernel_rodata(va) ) {
+            pte.pt.ro = 1;
+            pte.pt.xn = 1;
+        }
+        else {
+            pte.pt.xn = 1;
+            pte.pt.ro = 0;
+        }
+
+        write_pte(entry, pte);
+    }
+
+    /*
+     * We modified live page-tables. Ensure the TLBs are invalidated
+     * before setting enforcing the WnX permissions.
+     */
+    flush_xen_tlb_local();
+
+    xen_pt_enforce_wnx();
 }
 
 void *__init arch_vmap_virt_end(void)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 568a49b274..5e2c519ce8 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -304,8 +304,6 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr)
     /* Initialize traps early allow us to get backtrace when an error occurred */
     init_traps();
 
-    setup_pagetables();
-
     smp_clear_cpu_maps();
 
     device_tree_flattened = early_fdt_map(fdt_paddr);
@@ -329,6 +327,14 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr)
 
     llc_coloring_init();
 
+    /*
+     * Page tables must be setup after LLC coloring initialization because
+     * coloring info are required in order to create colored mappings
+     */
+    setup_pagetables();
+    /* Device-tree was mapped in boot page tables, remap it in the new tables */
+    device_tree_flattened = early_fdt_map(fdt_paddr);
+
     setup_mm();
 
     vm_init();
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index ff4837fcc6..545d8b49e8 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -42,6 +42,8 @@ static unsigned int __ro_after_init xen_num_colors;
 
 #define mfn_color_mask              (max_nr_colors - 1)
 #define mfn_to_color(mfn)           (mfn_x(mfn) & mfn_color_mask)
+#define get_mfn_with_color(mfn, color) \
+    (_mfn((mfn_x(mfn) & ~mfn_color_mask) | (color)))
 
 /*
  * Parse the coloring configuration given in the buf string, following the
@@ -364,6 +366,22 @@ unsigned int get_max_nr_llc_colors(void)
     return max_nr_colors;
 }
 
+mfn_t __init xen_colored_mfn(mfn_t mfn)
+{
+    unsigned int i, color = mfn_to_color(mfn);
+
+    for ( i = 0; i < xen_num_colors; i++ )
+    {
+        if ( color == xen_colors[i] )
+            return mfn;
+        if ( color < xen_colors[i] )
+            return get_mfn_with_color(mfn, xen_colors[i]);
+    }
+
+    /* Jump to next color space (max_nr_colors mfns) and use the first color */
+    return get_mfn_with_color(mfn_add(mfn, max_nr_colors), xen_colors[0]);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
index 1216d1fbd4..30c8a1d9a6 100644
--- a/xen/include/xen/llc-coloring.h
+++ b/xen/include/xen/llc-coloring.h
@@ -8,6 +8,7 @@
 #ifndef __XEN_LLC_COLORING_H__
 #define __XEN_LLC_COLORING_H__
 
+#include 
 #include 
 
 struct domain;
@@ -30,6 +31,17 @@ static inline void domain_dump_llc_colors(const struct domain *d) {}
 static inline void domain_llc_coloring_free(struct domain *d) {}
 #endif
 
+/**
+ * Iterate over each Xen mfn in the colored space.
+ * @start_mfn:  the first mfn that needs to be colored.
+ * @mfn:        the current mfn.
+ * @i:          loop index.
+ */
+#define for_each_xen_colored_mfn(start_mfn, mfn, i) \
+    for ( i = 0, mfn = xen_colored_mfn(start_mfn);  \
+          i < (_end - _start) >> PAGE_SHIFT;        \
+          i++, mfn = xen_colored_mfn(mfn_add(mfn, 1)) )
+
 unsigned int get_llc_way_size(void);
 void arch_llc_coloring_init(void);
 int dom0_set_llc_colors(struct domain *d);
@@ -38,6 +50,7 @@ int domain_set_llc_colors(struct domain *d,
 int domain_set_llc_colors_from_str(struct domain *d, const char *str);
 unsigned int page_to_llc_color(const struct page_info *pg);
 unsigned int get_max_nr_llc_colors(void);
+mfn_t xen_colored_mfn(mfn_t mfn);
 
 #endif /* __XEN_LLC_COLORING_H__ */
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:31:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:31:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856973.1269485 (Exim 4.92)
	(envelope-from )
	id 1tM8Ze-0003RA-SF; Fri, 13 Dec 2024 16:31:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856973.1269485; Fri, 13 Dec 2024 16:31: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 1tM8Ze-0003Qz-PJ; Fri, 13 Dec 2024 16:31:30 +0000
Received: by outflank-mailman (input) for mailman id 856973;
 Fri, 13 Dec 2024 16:31: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 1tM8Wt-0003wR-3Y
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:28:39 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4df80701-b96f-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 17:28:37 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5d3d143376dso2885613a12.3
 for ; Fri, 13 Dec 2024 08:28:37 -0800 (PST)
Received: from carlo-ubuntu.minervasys.tech ([193.207.202.156])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa673474d96sm841759266b.96.2024.12.13.08.28.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 08:28: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: 4df80701-b96f-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734107317; x=1734712117; 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=xlEGxO2IBuQZ7rn+a3lLB8EIrI2UkwRqyEO2+oge/xI=;
        b=rJ/pXLhGDaJHXCtQsZ5yjpakKGHhxj3UhRDxTK4SyMB4UPmYCjMW35/OPxKghVyNOI
         ev9R/O8zPMeZQZt+iv4c3IoikWzEEJ6XK6v/7iFhzAC1OwhVPbDqI25zJf3hmTGYZ/Ph
         kl/qrf81jaryASN84VA6zUvsCN+tX1aRurzRVKH/fd2NkergStbEhJKNRUz9FuMCG9Kf
         yVcqua+aTcDJJzW4/Ru5d8iHo1NowEVgXsBwBsAy8qdvPr9KCHEekV3vMJCP7mYZ9krO
         uRluuOS1WDTZp4C3cpyQSv0LBfvcGbESIkDdPOLyJVIoJaFThfyQ+PX1nROp3/cTRrFJ
         odJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734107317; x=1734712117;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=xlEGxO2IBuQZ7rn+a3lLB8EIrI2UkwRqyEO2+oge/xI=;
        b=nH/mFzKmdf//3GmAOzRnDK2eBmkJd30+JUsK63EeoevzYzu0ufGe+sKVr3/1vzX3Do
         gz56Op+vTw/Mepa3CVEbGCTMhWRiLBCbeKlOWIvt7QcuR9fejAzIFzKa03IG5KQVW8DE
         HsbD/hu8gCIHelmjwhmoP4yZO2DoQvDWdTn8MpLwmiIeiXbGf3gUhVcMMsPEPmo/9p9X
         bVMEpfIsFSIhkGUfwWd7l1wQrjVjDGRdZY5diGml+eaHusUIBERVaox6IOo6Y/fX+uHH
         PN2dta7jHJOIrJcPgrdIvqRZdXkdbFcTGuh22SnOKLXEnhf5SJFAxJ4xeYMBgvMbnU43
         cwDQ==
X-Gm-Message-State: AOJu0YxqRH5R3fxwOtA/hEy0aLNVQQjEk0os8siiJL9OaACMnAwQ6Vys
	LRhLb8Cm7XkJs9sI2kracIOMHEarXR13Y2MMWV3ACLly0Rh4GS9TVU+RLlRdNeevy6Y2J6WEBLD
	7gow=
X-Gm-Gg: ASbGnctBngmEFl0f091m1DCL8yIBtrnaYVXj+8L7o2W9QcsO62RE4Z5AbE2PchaCaJr
	1a1g+df7w4fA0YuKLUglwe1QBjCwvPjqQEl970Orx7bpJoyePfIqsDhfq/da9XtcM1EFT3vUz6U
	4RVEE7pcsGnyD+sdI8TlPCpMqUJKwemdFAnENPnBXv+CoZmZi2ZRO+FwGRfVtHlHzzwiZF47j87
	jnZVKRsMT/CZ8pEsRC+h9maplf3tHHj1dJjjXqHYteCAfpAn/cmhyw0wAvPxE6pZKKkmrA809CS
	ZXnwlf1qBLr3mYUc
X-Google-Smtp-Source: AGHT+IGeFQ1uM4ac/bBTdwHITw+kKTkRvy28KpZgFPJ6kT5gLWNwHkwhQik5Tc6gYalTgR4jI4NvLA==
X-Received: by 2002:a17:907:6e91:b0:aa6:af4b:7c91 with SMTP id a640c23a62f3a-aab77ed4383mr382603466b.58.1734107316736;
        Fri, 13 Dec 2024 08:28:36 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v12 08/12] xen/page_alloc: introduce preserved page flags macro
Date: Fri, 13 Dec 2024 17:28:11 +0100
Message-ID: <20241213162815.9196-9-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

PGC_static and PGC_extra need to be preserved when assigning a page.
Define a new macro that groups those flags and use it instead of or'ing
every time.

Signed-off-by: Carlo Nonato 
---
v12:
- fixed wrong patch sent in v11
- added comment on PGC_preserved
v11:
- removed PGC_broken from PGC_preserved
- removed PGC preservation from mark_page_free()
v10:
- fixed commit message
v9:
- add PGC_broken to PGC_preserved
- clear PGC_extra in alloc_domheap_pages() only if MEMF_no_refcount is set
v8:
- fixed PGC_extra ASSERT fail in alloc_domheap_pages() by removing PGC_extra
  before freeing
v7:
- PGC_preserved used also in mark_page_free()
v6:
- preserved_flags renamed to PGC_preserved
- PGC_preserved is used only in assign_pages()
v5:
- new patch
---
 xen/common/page_alloc.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 55d561e93c..7735c8b436 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -161,6 +161,10 @@
 #endif
 
 #define PGC_no_buddy_merge PGC_static
+/*
+ * Flags that are preserved in assign_pages() (and only there)
+ */
+#define PGC_preserved (PGC_extra | PGC_static)
 
 #ifndef PGT_TYPE_INFO_INITIALIZER
 #define PGT_TYPE_INFO_INITIALIZER 0
@@ -2382,7 +2386,7 @@ int assign_pages(
 
         for ( i = 0; i < nr; i++ )
         {
-            ASSERT(!(pg[i].count_info & ~(PGC_extra | PGC_static)));
+            ASSERT(!(pg[i].count_info & ~PGC_preserved));
             if ( pg[i].count_info & PGC_extra )
                 extra_pages++;
         }
@@ -2442,7 +2446,7 @@ int assign_pages(
         page_set_owner(&pg[i], d);
         smp_wmb(); /* Domain pointer must be visible before updating refcnt. */
         pg[i].count_info =
-            (pg[i].count_info & (PGC_extra | PGC_static)) | PGC_allocated | 1;
+            (pg[i].count_info & PGC_preserved) | PGC_allocated | 1;
 
         page_list_add_tail(&pg[i], page_to_list(d, &pg[i]));
     }
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 16:31:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 16:31:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.856979.1269494 (Exim 4.92)
	(envelope-from )
	id 1tM8Zn-0003sV-2Y; Fri, 13 Dec 2024 16:31:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 856979.1269494; Fri, 13 Dec 2024 16:31: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 1tM8Zm-0003sO-VY; Fri, 13 Dec 2024 16:31:38 +0000
Received: by outflank-mailman (input) for mailman id 856979;
 Fri, 13 Dec 2024 16:31: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 1tM8Wx-0003wR-4i
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 16:28:43 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 505d4768-b96f-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 17:28:41 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5d0f6fa6f8bso2959123a12.0
 for ; Fri, 13 Dec 2024 08:28:41 -0800 (PST)
Received: from carlo-ubuntu.minervasys.tech ([193.207.202.156])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aa673474d96sm841759266b.96.2024.12.13.08.28.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 08:28: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: 505d4768-b96f-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734107321; x=1734712121; 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=v2Fqewzc4NSZqd78RnQVSVrm5ltUTfiMxSBWlBJDggY=;
        b=EHFdkXKTEw1TeJrN+BsMuKpktu1qTB606QygXx3YIYkbDWEDp6+RtqWYziQJ8eSL60
         fzwT8ft2c4JcPF7e6Dg3qBmR+o8Gd1p+5YBKPxNoGDQZfE0FKEu1zvDGESuXeyjHomsv
         FJMZeQs6oeVbpH0Rp/P8OGDpbVAhmaql7prL7AraodyJOnTWiK+JQXjngVjj0hkGEVeJ
         SVYB9ilzKTEePprDwnHRgwjAFVWCO90h4MLZmzy308JSt/NIyHjF/yuAz00x4BuLKflf
         PW2pzOb/rCnsDBj6mNE6Fw5A2ZbrNah6dOc3HvwFCOWAuUdkbAT6YocCPPhWnKfFFNuw
         b5Rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734107321; x=1734712121;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=v2Fqewzc4NSZqd78RnQVSVrm5ltUTfiMxSBWlBJDggY=;
        b=JCODZws/jptT6MY9afuv4zhfe+3au4IhKBbt/vlferTDYFiuT7SUUEaXqRZEeHU2dL
         J6reGjqEaQQD1UItliR3Myi2C7xmckbqHdWOphJNGz2PczMVpBoTOQSCMXJrUDPywChV
         3+9ql5wdjnQmJpNvnceNq8ll3VTdtbCs5CGN9GjZmd0Ez8zvvSseVw7HTvcV1/vh4RYX
         3Nnl09aNH8b+c3Sl+FOQstDWKi+xGxi6x+aY2Qm8M+6H/+V+WBG+akEx0NN15YcqP6sx
         xPhnckcSslfEd1ptyTi7mmGAtr8jaL/iJJAsMbHNdREK806irAAkgwIDaTHtkZahaKLc
         CwbA==
X-Gm-Message-State: AOJu0YxZkVR/sXmmG4JIFoC/0poCNLJfJyWsMKxgghZW/Q0JWRXA5/3W
	9oum3MNeuFtq2+v4yxXPlkZUvAfVqz0L/eKVeOAltRY1saGuGVQTo57J9SK/nRCvOwDsC9UrrH7
	V1pM=
X-Gm-Gg: ASbGnctaMu5a1ZOg5DUnQEVvnpvVG7qdlqfXAjPr0mYN2+sa/0x5rffkxRRYGGwyJCL
	oFoJHOXw0JqZfuglG8c4P21bo3TZuCUaNmc9MHw6O1e0ycCxgSPgRWpQW/fhCOdp4q1WxrtISqf
	7aFegRVdBjSmHzcbniYCwRAvnoP0YnS6fT8t2h4gCtctNa2A7kEPTcENjy6vx8cjWLu9rls6e2m
	nanhYTUUkBbggYf1WAhzDlGK9wGIrrpDjKYedIFQwhczKkcNWZJTW0hORlm15arxQwj/LHY6oZH
	10rL4R2HQmGxE+Ff
X-Google-Smtp-Source: AGHT+IHGkm6ZpHTtlOX8qen1IdvyvNBfDHKUBnmNDwp2fqelZbnS9mSI2VsNF3FnqMeTMzhDYb9+sw==
X-Received: by 2002:a17:907:9705:b0:aab:75f1:e520 with SMTP id a640c23a62f3a-aab779b3b5fmr328981166b.34.1734107320717;
        Fri, 13 Dec 2024 08:28:40 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Luca Miccio ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Carlo Nonato 
Subject: [PATCH v12 10/12] xen/arm: add Xen cache colors command line parameter
Date: Fri, 13 Dec 2024 17:28:13 +0100
Message-ID: <20241213162815.9196-11-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Luca Miccio 

Add a new command line parameter to configure Xen cache colors.
These colors are dumped together with other coloring info.

Benchmarking the VM interrupt response time provides an estimation of
LLC usage by Xen's most latency-critical runtime task. Results on Arm
Cortex-A53 on Xilinx Zynq UltraScale+ XCZU9EG show that one color, which
reserves 64 KiB of L2, is enough to attain best responsiveness:
- Xen 1 color latency:  3.1 us
- Xen 2 color latency:  3.1 us

Since this is the most common target for Arm cache coloring, the default
amount of Xen colors is set to one.

More colors are instead very likely to be needed on processors whose L1
cache is physically-indexed and physically-tagged, such as Cortex-A57.
In such cases, coloring applies to L1 also, and there typically are two
distinct L1-colors. Therefore, reserving only one color for Xen would
senselessly partitions a cache memory that is already private, i.e.
underutilize it.

Signed-off-by: Luca Miccio 
Signed-off-by: Marco Solieri 
Signed-off-by: Carlo Nonato 
Reviewed-by: Jan Beulich 
---
v12:
- no changes
v11:
- no changes
v10:
- no changes
v9:
- no changes
v8:
- added bound check on xen_colors in llc_coloring_init()
v7:
- removed XEN_DEFAULT_COLOR
- XEN_DEFAULT_NUM_COLORS is now used in a for loop to set xen default colors
---
 docs/misc/cache-coloring.rst      |  2 ++
 docs/misc/xen-command-line.pandoc | 10 ++++++++++
 xen/common/llc-coloring.c         | 29 +++++++++++++++++++++++++++++
 3 files changed, 41 insertions(+)

diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
index 5224b27afe..e156062aa2 100644
--- a/docs/misc/cache-coloring.rst
+++ b/docs/misc/cache-coloring.rst
@@ -115,6 +115,8 @@ Specific documentation is available at `docs/misc/xen-command-line.pandoc`.
 +----------------------+-------------------------------+
 | ``buddy-alloc-size`` | Buddy allocator reserved size |
 +----------------------+-------------------------------+
+| ``xen-llc-colors``   | Xen color configuration       |
++----------------------+-------------------------------+
 
 Colors selection format
 ***********************
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 3a70c49c05..992e1f993e 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2923,6 +2923,16 @@ mode.
 **WARNING: `x2apic_phys` is deprecated and superseded by `x2apic-mode`.
 The latter takes precedence if both are set.**
 
+### xen-llc-colors (arm64)
+> `= List of [  | - ]`
+
+> Default: `0: the lowermost color`
+
+Specify Xen LLC color configuration. This options is available only when
+`CONFIG_LLC_COLORING` is enabled.
+Two colors are most likely needed on platforms where private caches are
+physically indexed, e.g. the L1 instruction cache of the Arm Cortex-A57.
+
 ### xenheap_megabytes (arm32)
 > `= `
 
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index ec6b0d3bff..ff4837fcc6 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -13,6 +13,7 @@
 #include 
 
 #define NR_LLC_COLORS          (1U << CONFIG_LLC_COLORS_ORDER)
+#define XEN_DEFAULT_NUM_COLORS 1
 
 /*
  * -1: not specified (disabled unless llc-size and llc-nr-ways present)
@@ -36,6 +37,9 @@ static unsigned int __ro_after_init default_colors[NR_LLC_COLORS];
 static unsigned int __initdata dom0_colors[NR_LLC_COLORS];
 static unsigned int __initdata dom0_num_colors;
 
+static unsigned int __ro_after_init xen_colors[NR_LLC_COLORS];
+static unsigned int __ro_after_init xen_num_colors;
+
 #define mfn_color_mask              (max_nr_colors - 1)
 #define mfn_to_color(mfn)           (mfn_x(mfn) & mfn_color_mask)
 
@@ -94,6 +98,13 @@ static int __init parse_dom0_colors(const char *s)
 }
 custom_param("dom0-llc-colors", parse_dom0_colors);
 
+static int __init parse_xen_colors(const char *s)
+{
+    return parse_color_config(s, xen_colors, ARRAY_SIZE(xen_colors),
+                              &xen_num_colors);
+}
+custom_param("xen-llc-colors", parse_xen_colors);
+
 static void print_colors(const unsigned int colors[], unsigned int num_colors)
 {
     unsigned int i;
@@ -178,6 +189,22 @@ void __init llc_coloring_init(void)
     for ( i = 0; i < max_nr_colors; i++ )
         default_colors[i] = i;
 
+    if ( !xen_num_colors )
+    {
+        unsigned int i;
+
+        xen_num_colors = MIN(XEN_DEFAULT_NUM_COLORS, max_nr_colors);
+
+        printk(XENLOG_WARNING
+               "Xen LLC color config not found. Using first %u colors\n",
+               xen_num_colors);
+        for ( i = 0; i < xen_num_colors; i++ )
+            xen_colors[i] = i;
+    }
+    else if ( xen_num_colors > max_nr_colors ||
+              !check_colors(xen_colors, xen_num_colors) )
+        panic("Bad LLC color config for Xen\n");
+
     arch_llc_coloring_init();
 }
 
@@ -188,6 +215,8 @@ void dump_llc_coloring_info(void)
 
     printk("LLC coloring info:\n");
     printk("    Number of LLC colors supported: %u\n", max_nr_colors);
+    printk("    Xen LLC colors (%u): ", xen_num_colors);
+    print_colors(xen_colors, xen_num_colors);
 }
 
 void domain_dump_llc_colors(const struct domain *d)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 17:54:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 17:54:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857072.1269504 (Exim 4.92)
	(envelope-from )
	id 1tM9rP-0003fc-Ir; Fri, 13 Dec 2024 17:53:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857072.1269504; Fri, 13 Dec 2024 17:53:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tM9rP-0003fV-Fu; Fri, 13 Dec 2024 17:53:55 +0000
Received: by outflank-mailman (input) for mailman id 857072;
 Fri, 13 Dec 2024 17:53: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 1tM9rN-0003fP-Nd
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 17:53:53 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 367abd8c-b97b-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 18:53:52 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id BFDE8A41425;
 Fri, 13 Dec 2024 17:51:59 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6830CC4CED0;
 Fri, 13 Dec 2024 17:53: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: 367abd8c-b97b-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1734112430;
	bh=giLsrBe+eXIr2Z5RCc4V156ArPFV4LhVw7wYhIzIoXE=;
	h=Date:From:To:Cc:Subject:In-Reply-To:From;
	b=dsGwzCpsHyKSEp5dYNZqIU7VIPCf1+1BvfLnsNExHvF+KgHEKWxdDya2OH4Yb1KdO
	 xjyNZsn9LGsL+5ubm9YwLy6PfO1o9HHK4GH9HnfKOzJfFxn/wgTn1u4o1aUgnAXEWn
	 GkW8WT5ub+1C8izqxGJm68p92qbUmH0Zz6j12LSWYDuKvCO0PKAmAIFG8J70k4DM58
	 BkmbpSUnFf6MODuN2bFpAw11s14p/2yDMhpzWn6yJuuKNDwnCnEugjbstu3jKrQ4hZ
	 YZx0beo5hpke+CycdWaTs127pteqlLsHIM7BixvuD11GKP+6nU5Tvb5YUerVZXNZPP
	 DkNTiHRBWPZvw==
Date: Fri, 13 Dec 2024 11:53:49 -0600
From: Bjorn Helgaas 
To: Kalle Valo 
Cc: Philipp Stanner ,
	Igor Mitsyanko ,
	amien Le Moal ,
	Niklas Cassel ,
	Basavaraj Natikar ,
	Jiri Kosina ,
	Benjamin Tissoires ,
	Arnd Bergmann ,
	Sergey Matyukevich ,
	Greg Kroah-Hartman ,
	Alex Dubov ,
	Sudarsana Kalluru ,
	Manish Chopra ,
	Andrew Lunn ,
	"David S. Miller" ,
	Eric Dumazet ,
	Jakub Kicinski , Paolo Abeni ,
	Rasesh Mody , GR-Linux-NIC-Dev@marvell.com,
	Sanjay R Mehta ,
	Shyam Sundar S K ,
	Jon Mason , Dave Jiang ,
	Allen Hubbe ,
	Bjorn Helgaas ,
	Alex Williamson ,
	Juergen Gross ,
	Stefano Stabellini ,
	Oleksandr Tyshchenko ,
	Mario Limonciello ,
	Chen Ni , Ricky Wu ,
	Al Viro , Breno Leitao ,
	Thomas Gleixner ,
	Kevin Tian ,
	Andy Shevchenko ,
	Mostafa Saleh , Jason Gunthorpe ,
	Yi Liu , Kunwu Chan ,
	Dan Carpenter ,
	"Dr. David Alan Gilbert" ,
	Ankit Agrawal ,
	Reinette Chatre ,
	Eric Auger , Ye Bin ,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-input@vger.kernel.org, netdev@vger.kernel.org,
	linux-wireless@vger.kernel.org, ntb@lists.linux.dev,
	linux-pci@vger.kernel.org, kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	Igor Mitsyanko 
Subject: Re: [PATCH v3 09/11] wifi: qtnfmac: use always-managed version of
 pcim_intx()
Message-ID: <20241213175349.GA3421319@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87cyhvoox9.fsf@kernel.org>

[+cc personal address for Igor]

On Fri, Dec 13, 2024 at 12:30:42PM +0200, Kalle Valo wrote:
> Bjorn Helgaas  writes:
> 
> > [cc->to: Igor]
> >
> > On Mon, Dec 09, 2024 at 02:06:31PM +0100, Philipp Stanner wrote:
> >> pci_intx() is a hybrid function which can sometimes be managed through
> >> devres. To remove this hybrid nature from pci_intx(), it is necessary to
> >> port users to either an always-managed or a never-managed version.
> >> 
> >> qtnfmac enables its PCI-Device with pcim_enable_device(). Thus, it needs
> >> the always-managed version.
> >> 
> >> Replace pci_intx() with pcim_intx().
> >> 
> >> Signed-off-by: Philipp Stanner 
> >> Acked-by: Kalle Valo 
> >
> > Hoping for an ack from Igor, too.
> 
> Igor hasn't been around for a while so I'm not expecting see an ack from
> him, I think the whole qtnfmac driver should be removed in the future.
> Feel free to take the patch as is.

Thanks, Kalle, will do.


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 19:09:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 19:09:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857087.1269515 (Exim 4.92)
	(envelope-from )
	id 1tMB29-0004Tj-0J; Fri, 13 Dec 2024 19:09:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857087.1269515; Fri, 13 Dec 2024 19:09: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 1tMB28-0004Tc-Tk; Fri, 13 Dec 2024 19:09:04 +0000
Received: by outflank-mailman (input) for mailman id 857087;
 Fri, 13 Dec 2024 19:09: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 1tMB27-0004TW-IU
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 19:09:03 +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 b5eb0664-b985-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 20:09:01 +0100 (CET)
Received: by mail-ot1-x32a.google.com with SMTP id
 46e09a7af769-71e1158fe3eso974845a34.1
 for ; Fri, 13 Dec 2024 11:09:01 -0800 (PST)
Received: from stoup.. ([187.217.227.247]) by smtp.gmail.com with ESMTPSA id
 46e09a7af769-71e4834da91sm29697a34.18.2024.12.13.11.08.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 11:08: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: b5eb0664-b985-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1734116940; x=1734721740; 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=VBuAnCPgZLHdX0sVpQB+fbM15dWtrtdAGUwOdHBBqsc=;
        b=lmkMzcGiWAmwSkFj8FYR/5sT4TP38QIHngNyyOJNNh1dIE2fvUngs/bSTaYy1HLqxk
         ikVnyMS9TNdpoyyFqLKTOmLLuvMGDrNJm1GHpQ9EWTXNnkC3ui/dAOmq/DzekD+yh4qo
         ZN+MLOPWZhaHNcxcQ9KRsLbpVmr42WyB+uKyxx+EbJ93XdJc3hH/aZ9IIMExbg2WIqKn
         aFuFRdvGbbwIblilmmvmPQqBwGGebbvngD8K7thQibbhcXY/8p1ecpXbakQS8UKmvtag
         SenTcdQSIka0994kw+/RFy4ZXyrnmvHkE4Ao76jby9uKQGhjFO7owWa6rIXE5fdhMJpO
         DF9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734116940; x=1734721740;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=VBuAnCPgZLHdX0sVpQB+fbM15dWtrtdAGUwOdHBBqsc=;
        b=WmZG44ELWgTmrXISVE2gVVODlQm+efzVJl0+6lGg6y5toRRfUkGGrrp7MvTKW1c+QO
         qOPQw8WTJJyNXSJ+amXjSdczyjcE5wPsfmOVe4GROTUhivupu7aluxCWaxuIsYgFcWtN
         rxi6/OfozNZzPTipSd86WyOHs8LAde3Zeo3XNe9GlEg532+YSrr0NsdJpIJ+81IpJvqm
         XG37zJARq1aG7Q/wvtH+yUbQTEHJqa78w83lJ2mQKxG+M2Z3fNO4PbygSGInTLAFhhRN
         4L0qwjXEinf2cCjv3m5TN6vD3wLxCrwxiqSWOcfNA+dPSc6oV55u3Rme9CmF4MjofG7L
         Zvtw==
X-Forwarded-Encrypted: i=1; AJvYcCX+rP10ikkcLbXuws3g9TTAO0D+RamE1tcMUTp/amgQbr8E0vr1tCaLYaLtvF+09Tb6pMZ2pbir3eo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzrb0CK78TJsU+TMaCBBSrlMYNer5b1VVDWk9U56aG26ZIamwcj
	TyxbKcOV1ykTijSZgT/LhuyfWjLVaygmEz4rYKpR1dbUbgGqM+rDwJVGacnTGZo=
X-Gm-Gg: ASbGncvBUzXirFMVEa3jl7rdy2SVYlKnPDATwtz7FXGnr538tFjorMp5DMWZHZrih/0
	cFlTZ/IvgvgHvOXeawHqInTItdvMz+oWIt7H4YVjdrOSPgitlJWKKkqb3OCzUlZJqquMPtH/s6N
	PfhFCya4CAwjojwqi0Dsh3MnlsIrYJ++SDkm0B963ZzJvZunx3OBxp2xoS7IUdxC+lqs3nZ9X3P
	oWpRsXVgSsx3shqyalgIatHkNc1v/se1dJgtdVL1s7FPbYacjOWwEUNCpne9U9o
X-Google-Smtp-Source: AGHT+IG4Oaa1CFMaif+EnKB8kf2kg/gBi+Er63DHsr2guVeeoIb4v5eKEHl55hIr030QigRhTnJLHA==
X-Received: by 2002:a05:6830:2a92:b0:71d:f6d3:9fd2 with SMTP id 46e09a7af769-71e3ba3f147mr1411664a34.24.1734116940056;
        Fri, 13 Dec 2024 11:09:00 -0800 (PST)
From: Richard Henderson 
To: qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	Kevin Wolf ,
	Hanna Reitz ,
	xen-devel@lists.xenproject.org (open list:X86 Xen CPUs),
	qemu-block@nongnu.org (open list:Block layer core)
Subject: [PATCH 18/71] hw/block/xen-block: Unexport PropertyInfo
Date: Fri, 13 Dec 2024 13:06:52 -0600
Message-ID: <20241213190750.2513964-23-richard.henderson@linaro.org>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213190750.2513964-1-richard.henderson@linaro.org>
References: <20241213190750.2513964-1-richard.henderson@linaro.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

xen_block_prop_vdev is not used outside the file.

Signed-off-by: Richard Henderson 
---
 hw/block/xen-block.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index aed1d5c330..72cfd6893a 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -659,7 +659,7 @@ invalid:
  *
  * https://xenbits.xen.org/docs/unstable/man/xen-vbd-interface.7.html
  */
-const PropertyInfo xen_block_prop_vdev = {
+static const PropertyInfo xen_block_prop_vdev = {
     .name  = "str",
     .description = "Virtual Disk specifier: d*p*/xvd*/hd*/sd*",
     .get = xen_block_get_vdev,
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 19:09:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 19:09:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857089.1269535 (Exim 4.92)
	(envelope-from )
	id 1tMB2I-000500-H3; Fri, 13 Dec 2024 19:09:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857089.1269535; Fri, 13 Dec 2024 19:09: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 1tMB2I-0004zp-DT; Fri, 13 Dec 2024 19:09:14 +0000
Received: by outflank-mailman (input) for mailman id 857089;
 Fri, 13 Dec 2024 19:09: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 1tMB2H-0004TW-7T
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 19:09:13 +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 bbe44eac-b985-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 20:09:11 +0100 (CET)
Received: by mail-ot1-x32a.google.com with SMTP id
 46e09a7af769-71e2bc5b90fso1009869a34.0
 for ; Fri, 13 Dec 2024 11:09:11 -0800 (PST)
Received: from stoup.. ([187.217.227.247]) by smtp.gmail.com with ESMTPSA id
 46e09a7af769-71e4834da91sm29697a34.18.2024.12.13.11.09.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 11:09:09 -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: bbe44eac-b985-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1734116950; x=1734721750; 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=b/X3IVDeDd+noUKxYZR0n+Vdo2pFngQ4Wz2l9zT17Cg=;
        b=Ch5XorqkKzZK++r7uaJ7Ingrf3KtC1Zzonea15h1sPeVhp9gQWDBz3Tt45CU00JuS+
         a7YxmBfFPEbhNIUcMg0CHIYz9D38B5lzAt4w1iaEbVQLGlHWXQU1XDOygRIhUCP11AA+
         NByLvcRIvMhV/MUJ4UJTk5Qq8qufYBN3Hp/I/bR5A7JSUb7cl0zUY5Hlk0SKeCSa1yEB
         +/3Un/GEPnJos05G9iTQFHNKK5FTlaOf/fp1vlHAkJdIwD6e3+XwgV/2DtZ/AT/Aq+Hy
         71mxAYfLRnBhw9a9VSE2L38kbozQRAB1rK+dN26IfDwJVgnEjpIJYKnMuv7pDAgF7s0M
         l6qQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734116950; x=1734721750;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=b/X3IVDeDd+noUKxYZR0n+Vdo2pFngQ4Wz2l9zT17Cg=;
        b=kUrdm38uwmR6RptAhKPN/xPSgmisN54kjLmDMCDVX2y5wB66ij67X1/A78J/DQ7mMS
         HjdrrRQmid5gtFvC/abYmYZlZBN2BgskgdXqu2NiYhlVrwucbBp1p4goAWd/NxOjz7/X
         +eRksEgusy9vuII0Ja4vmezVH/3T2yNwFtbmyaZp4xYb7/kMM3SFBbRNlVGYrly1CfAf
         9azQjzychXDuQYnWVwjihGSdyypN1N9hdaEmtR/iYhvoPE9pFL5CIdkwbUYQBQIWXVMj
         +gJkdE39VQd+VNJ/UT/k1PKkn0B8ieCakfUBULMhpUg68FoGmaxs3FWZfbc02sQFpZKu
         k9bA==
X-Forwarded-Encrypted: i=1; AJvYcCXD1VPksAseqmGS2Cv+ybkoxByTX7w/fVYPD/4sZpILZWG6TlEbscbpU6BwS8PT0iHfPDHo39RhezU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzL+ZyOLNR6BeX7XcKncppYvK3bPXq+uXNytn/04tXjeUAsyh+S
	J+FEzB1zEhOEfycQ9XDWBjV0wVLmqgPKZHQ7+7WMTaBoVEzh2WEWhg2BfrmNQik=
X-Gm-Gg: ASbGncujkSab3OmsM93RxdvFvxDDUAJbaBqqhvgOV6HlgAx3//cCjhUR0aauyDXmQH4
	6DGQYz2AM0S9cne+GV+QaFPqSiBn+u1bRmg3v9q6VC0iLQ0KtPepoM+tZqm+s94VXYPj/45XqR6
	BwzChGTMJ0yeFpleywokbdB8LOHoimKgf50pr8+miot+VoT9ib10bqU3IXekXyqBpDOtCQ3bf8U
	u6eMdxcVf4rB7JkOXavfZvZGxZBYUL6T69MQvDpOHBYLmcXJjS73waIZ79b5f4t
X-Google-Smtp-Source: AGHT+IHyiahaPH7IR7tMGor3tb4r8tyoeL5l6bj/iA+pUDvvwPfsGQ4o6c5cVxqEWXW+NK7FcqsU5A==
X-Received: by 2002:a05:6830:4486:b0:71e:212e:9115 with SMTP id 46e09a7af769-71e3ba50013mr2201200a34.30.1734116949898;
        Fri, 13 Dec 2024 11:09:09 -0800 (PST)
From: Richard Henderson 
To: qemu-devel@nongnu.org
Cc: Michael Rolnik ,
	=?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= ,
	Paolo Bonzini ,
	Peter Maydell ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	"Edgar E. Iglesias" ,
	Alistair Francis ,
	"Michael S. Tsirkin" ,
	Antony Pavlov ,
	Igor Mitsyanko ,
	Laurent Vivier ,
	=?UTF-8?q?Cl=C3=A9ment=20Chigot?= ,
	Frederic Konrad ,
	Alberto Garcia ,
	Thomas Huth ,
	Joel Stanley ,
	Yoshinori Sato ,
	Magnus Damm ,
	Halil Pasic ,
	Christian Borntraeger ,
	Vijai Kumar K ,
	Bin Meng ,
	Palmer Dabbelt ,
	Nicholas Piggin ,
	Daniel Henrique Barboza ,
	Harsh Prateek Bora ,
	Samuel Tardieu ,
	Amit Shah ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	qemu-arm@nongnu.org (open list:Raspberry Pi),
	qemu-riscv@nongnu.org (open list:OpenTitan),
	qemu-s390x@nongnu.org (open list:S390 general arch...),
	qemu-ppc@nongnu.org (open list:sPAPR (pseries)),
	xen-devel@lists.xenproject.org (open list:X86 Xen CPUs)
Subject: [PATCH 20/71] hw/char: Constify all Property
Date: Fri, 13 Dec 2024 13:06:54 -0600
Message-ID: <20241213190750.2513964-25-richard.henderson@linaro.org>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213190750.2513964-1-richard.henderson@linaro.org>
References: <20241213190750.2513964-1-richard.henderson@linaro.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Richard Henderson 
---
 hw/char/avr_usart.c         | 2 +-
 hw/char/bcm2835_aux.c       | 2 +-
 hw/char/cadence_uart.c      | 2 +-
 hw/char/cmsdk-apb-uart.c    | 2 +-
 hw/char/debugcon.c          | 2 +-
 hw/char/digic-uart.c        | 2 +-
 hw/char/escc.c              | 2 +-
 hw/char/exynos4210_uart.c   | 2 +-
 hw/char/goldfish_tty.c      | 2 +-
 hw/char/grlib_apbuart.c     | 2 +-
 hw/char/ibex_uart.c         | 2 +-
 hw/char/imx_serial.c        | 2 +-
 hw/char/ipoctal232.c        | 2 +-
 hw/char/mcf_uart.c          | 2 +-
 hw/char/nrf51_uart.c        | 2 +-
 hw/char/parallel.c          | 2 +-
 hw/char/pl011.c             | 2 +-
 hw/char/renesas_sci.c       | 2 +-
 hw/char/sclpconsole-lm.c    | 2 +-
 hw/char/sclpconsole.c       | 2 +-
 hw/char/serial-isa.c        | 2 +-
 hw/char/serial-mm.c         | 2 +-
 hw/char/serial-pci-multi.c  | 4 ++--
 hw/char/serial-pci.c        | 2 +-
 hw/char/serial.c            | 2 +-
 hw/char/sh_serial.c         | 2 +-
 hw/char/shakti_uart.c       | 2 +-
 hw/char/sifive_uart.c       | 2 +-
 hw/char/spapr_vty.c         | 2 +-
 hw/char/stm32f2xx_usart.c   | 2 +-
 hw/char/stm32l4x5_usart.c   | 2 +-
 hw/char/terminal3270.c      | 2 +-
 hw/char/virtio-console.c    | 2 +-
 hw/char/virtio-serial-bus.c | 4 ++--
 hw/char/xen_console.c       | 2 +-
 hw/char/xilinx_uartlite.c   | 2 +-
 36 files changed, 38 insertions(+), 38 deletions(-)

diff --git a/hw/char/avr_usart.c b/hw/char/avr_usart.c
index 3aff01cd54..3421576e45 100644
--- a/hw/char/avr_usart.c
+++ b/hw/char/avr_usart.c
@@ -259,7 +259,7 @@ static const MemoryRegionOps avr_usart_ops = {
     .impl = {.min_access_size = 1, .max_access_size = 1}
 };
 
-static Property avr_usart_properties[] = {
+static const Property avr_usart_properties[] = {
     DEFINE_PROP_CHR("chardev", AVRUsartState, chr),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/char/bcm2835_aux.c b/hw/char/bcm2835_aux.c
index fca2f27a55..30285c97b0 100644
--- a/hw/char/bcm2835_aux.c
+++ b/hw/char/bcm2835_aux.c
@@ -290,7 +290,7 @@ static void bcm2835_aux_realize(DeviceState *dev, Error **errp)
                              bcm2835_aux_receive, NULL, NULL, s, NULL, true);
 }
 
-static Property bcm2835_aux_props[] = {
+static const Property bcm2835_aux_props[] = {
     DEFINE_PROP_CHR("chardev", BCM2835AuxState, chr),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/char/cadence_uart.c b/hw/char/cadence_uart.c
index 77d9a2a221..2e778f7a9c 100644
--- a/hw/char/cadence_uart.c
+++ b/hw/char/cadence_uart.c
@@ -617,7 +617,7 @@ static const VMStateDescription vmstate_cadence_uart = {
     },
 };
 
-static Property cadence_uart_properties[] = {
+static const Property cadence_uart_properties[] = {
     DEFINE_PROP_CHR("chardev", CadenceUARTState, chr),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/char/cmsdk-apb-uart.c b/hw/char/cmsdk-apb-uart.c
index 467e40b715..e37e14e0f2 100644
--- a/hw/char/cmsdk-apb-uart.c
+++ b/hw/char/cmsdk-apb-uart.c
@@ -377,7 +377,7 @@ static const VMStateDescription cmsdk_apb_uart_vmstate = {
     }
 };
 
-static Property cmsdk_apb_uart_properties[] = {
+static const Property cmsdk_apb_uart_properties[] = {
     DEFINE_PROP_CHR("chardev", CMSDKAPBUART, chr),
     DEFINE_PROP_UINT32("pclk-frq", CMSDKAPBUART, pclk_frq, 0),
     DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/char/debugcon.c b/hw/char/debugcon.c
index fdb04fee09..c0f16e9bd6 100644
--- a/hw/char/debugcon.c
+++ b/hw/char/debugcon.c
@@ -114,7 +114,7 @@ static void debugcon_isa_realizefn(DeviceState *dev, Error **errp)
                                 isa->iobase, &s->io);
 }
 
-static Property debugcon_isa_properties[] = {
+static const Property debugcon_isa_properties[] = {
     DEFINE_PROP_UINT32("iobase", ISADebugconState, iobase, 0xe9),
     DEFINE_PROP_CHR("chardev",  ISADebugconState, state.chr),
     DEFINE_PROP_UINT32("readback", ISADebugconState, state.readback, 0xe9),
diff --git a/hw/char/digic-uart.c b/hw/char/digic-uart.c
index 5b04abec1d..03beba11ad 100644
--- a/hw/char/digic-uart.c
+++ b/hw/char/digic-uart.c
@@ -172,7 +172,7 @@ static const VMStateDescription vmstate_digic_uart = {
     }
 };
 
-static Property digic_uart_properties[] = {
+static const Property digic_uart_properties[] = {
     DEFINE_PROP_CHR("chardev", DigicUartState, chr),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/char/escc.c b/hw/char/escc.c
index b1b1bbed15..08bc65ef2c 100644
--- a/hw/char/escc.c
+++ b/hw/char/escc.c
@@ -1089,7 +1089,7 @@ static void escc_realize(DeviceState *dev, Error **errp)
     }
 }
 
-static Property escc_properties[] = {
+static const Property escc_properties[] = {
     DEFINE_PROP_UINT32("frequency", ESCCState, frequency,   0),
     DEFINE_PROP_UINT32("it_shift",  ESCCState, it_shift,    0),
     DEFINE_PROP_BOOL("bit_swap",    ESCCState, bit_swap,    false),
diff --git a/hw/char/exynos4210_uart.c b/hw/char/exynos4210_uart.c
index d9e732f98b..c2836ff8fd 100644
--- a/hw/char/exynos4210_uart.c
+++ b/hw/char/exynos4210_uart.c
@@ -704,7 +704,7 @@ static void exynos4210_uart_realize(DeviceState *dev, Error **errp)
                              NULL, s, NULL, true);
 }
 
-static Property exynos4210_uart_properties[] = {
+static const Property exynos4210_uart_properties[] = {
     DEFINE_PROP_CHR("chardev", Exynos4210UartState, chr),
     DEFINE_PROP_UINT32("channel", Exynos4210UartState, channel, 0),
     DEFINE_PROP_UINT32("rx-size", Exynos4210UartState, rx.size, 16),
diff --git a/hw/char/goldfish_tty.c b/hw/char/goldfish_tty.c
index d1917b83d8..68e261236e 100644
--- a/hw/char/goldfish_tty.c
+++ b/hw/char/goldfish_tty.c
@@ -241,7 +241,7 @@ static const VMStateDescription vmstate_goldfish_tty = {
     }
 };
 
-static Property goldfish_tty_properties[] = {
+static const Property goldfish_tty_properties[] = {
     DEFINE_PROP_CHR("chardev", GoldfishTTYState, chr),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/char/grlib_apbuart.c b/hw/char/grlib_apbuart.c
index d0032b4d2a..caae88d77d 100644
--- a/hw/char/grlib_apbuart.c
+++ b/hw/char/grlib_apbuart.c
@@ -277,7 +277,7 @@ static void grlib_apbuart_reset(DeviceState *d)
     uart->current = 0;
 }
 
-static Property grlib_apbuart_properties[] = {
+static const Property grlib_apbuart_properties[] = {
     DEFINE_PROP_CHR("chrdev", UART, chr),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/char/ibex_uart.c b/hw/char/ibex_uart.c
index 589177f85b..b1bdb2ad15 100644
--- a/hw/char/ibex_uart.c
+++ b/hw/char/ibex_uart.c
@@ -508,7 +508,7 @@ static const VMStateDescription vmstate_ibex_uart = {
     }
 };
 
-static Property ibex_uart_properties[] = {
+static const Property ibex_uart_properties[] = {
     DEFINE_PROP_CHR("chardev", IbexUartState, chr),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/char/imx_serial.c b/hw/char/imx_serial.c
index 22c9080b1c..6376f2cadc 100644
--- a/hw/char/imx_serial.c
+++ b/hw/char/imx_serial.c
@@ -438,7 +438,7 @@ static void imx_serial_init(Object *obj)
     sysbus_init_irq(sbd, &s->irq);
 }
 
-static Property imx_serial_properties[] = {
+static const Property imx_serial_properties[] = {
     DEFINE_PROP_CHR("chardev", IMXSerialState, chr),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/char/ipoctal232.c b/hw/char/ipoctal232.c
index 64be5226d4..fb8cb6c2b7 100644
--- a/hw/char/ipoctal232.c
+++ b/hw/char/ipoctal232.c
@@ -558,7 +558,7 @@ static void ipoctal_realize(DeviceState *dev, Error **errp)
     }
 }
 
-static Property ipoctal_properties[] = {
+static const Property ipoctal_properties[] = {
     DEFINE_PROP_CHR("chardev0", IPOctalState, ch[0].dev),
     DEFINE_PROP_CHR("chardev1", IPOctalState, ch[1].dev),
     DEFINE_PROP_CHR("chardev2", IPOctalState, ch[2].dev),
diff --git a/hw/char/mcf_uart.c b/hw/char/mcf_uart.c
index ad15e28944..c044536d5d 100644
--- a/hw/char/mcf_uart.c
+++ b/hw/char/mcf_uart.c
@@ -312,7 +312,7 @@ static void mcf_uart_realize(DeviceState *dev, Error **errp)
                              mcf_uart_event, NULL, s, NULL, true);
 }
 
-static Property mcf_uart_properties[] = {
+static const Property mcf_uart_properties[] = {
     DEFINE_PROP_CHR("chardev", mcf_uart_state, chr),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/char/nrf51_uart.c b/hw/char/nrf51_uart.c
index 04da3f8d97..b164c70f52 100644
--- a/hw/char/nrf51_uart.c
+++ b/hw/char/nrf51_uart.c
@@ -304,7 +304,7 @@ static const VMStateDescription nrf51_uart_vmstate = {
     }
 };
 
-static Property nrf51_uart_properties[] = {
+static const Property nrf51_uart_properties[] = {
     DEFINE_PROP_CHR("chardev", NRF51UARTState, chr),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/char/parallel.c b/hw/char/parallel.c
index c394635ada..15191698f5 100644
--- a/hw/char/parallel.c
+++ b/hw/char/parallel.c
@@ -603,7 +603,7 @@ bool parallel_mm_init(MemoryRegion *address_space,
     return true;
 }
 
-static Property parallel_isa_properties[] = {
+static const Property parallel_isa_properties[] = {
     DEFINE_PROP_UINT32("index", ISAParallelState, index,   -1),
     DEFINE_PROP_UINT32("iobase", ISAParallelState, iobase,  -1),
     DEFINE_PROP_UINT32("irq",   ISAParallelState, isairq,  7),
diff --git a/hw/char/pl011.c b/hw/char/pl011.c
index 0fd1334fab..5fbee5e6c5 100644
--- a/hw/char/pl011.c
+++ b/hw/char/pl011.c
@@ -603,7 +603,7 @@ static const VMStateDescription vmstate_pl011 = {
     }
 };
 
-static Property pl011_properties[] = {
+static const Property pl011_properties[] = {
     DEFINE_PROP_CHR("chardev", PL011State, chr),
     DEFINE_PROP_BOOL("migrate-clk", PL011State, migrate_clk, true),
     DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/char/renesas_sci.c b/hw/char/renesas_sci.c
index 7ce0408b0c..516b48648b 100644
--- a/hw/char/renesas_sci.c
+++ b/hw/char/renesas_sci.c
@@ -319,7 +319,7 @@ static const VMStateDescription vmstate_rsci = {
     }
 };
 
-static Property rsci_properties[] = {
+static const Property rsci_properties[] = {
     DEFINE_PROP_UINT64("input-freq", RSCIState, input_freq, 0),
     DEFINE_PROP_CHR("chardev", RSCIState, chr),
     DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/char/sclpconsole-lm.c b/hw/char/sclpconsole-lm.c
index 4fe1c4d289..536b283471 100644
--- a/hw/char/sclpconsole-lm.c
+++ b/hw/char/sclpconsole-lm.c
@@ -333,7 +333,7 @@ static void console_reset(DeviceState *dev)
    scon->write_errors = 0;
 }
 
-static Property console_properties[] = {
+static const Property console_properties[] = {
     DEFINE_PROP_CHR("chardev", SCLPConsoleLM, chr),
     DEFINE_PROP_UINT32("write_errors", SCLPConsoleLM, write_errors, 0),
     DEFINE_PROP_BOOL("echo", SCLPConsoleLM, echo, true),
diff --git a/hw/char/sclpconsole.c b/hw/char/sclpconsole.c
index e6d49e819e..a90b892d1d 100644
--- a/hw/char/sclpconsole.c
+++ b/hw/char/sclpconsole.c
@@ -251,7 +251,7 @@ static void console_reset(DeviceState *dev)
    scon->notify = false;
 }
 
-static Property console_properties[] = {
+static const Property console_properties[] = {
     DEFINE_PROP_CHR("chardev", SCLPConsole, chr),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/char/serial-isa.c b/hw/char/serial-isa.c
index b562ec9d37..2cf50eb0bb 100644
--- a/hw/char/serial-isa.c
+++ b/hw/char/serial-isa.c
@@ -113,7 +113,7 @@ static const VMStateDescription vmstate_isa_serial = {
     }
 };
 
-static Property serial_isa_properties[] = {
+static const Property serial_isa_properties[] = {
     DEFINE_PROP_UINT32("index",  ISASerialState, index,   -1),
     DEFINE_PROP_UINT32("iobase",  ISASerialState, iobase,  -1),
     DEFINE_PROP_UINT32("irq",    ISASerialState, isairq,  -1),
diff --git a/hw/char/serial-mm.c b/hw/char/serial-mm.c
index 2f67776b19..8f51f1d3b8 100644
--- a/hw/char/serial-mm.c
+++ b/hw/char/serial-mm.c
@@ -125,7 +125,7 @@ static void serial_mm_instance_init(Object *o)
     qdev_alias_all_properties(DEVICE(&smm->serial), o);
 }
 
-static Property serial_mm_properties[] = {
+static const Property serial_mm_properties[] = {
     /*
      * Set the spacing between adjacent memory-mapped UART registers.
      * Each register will be at (1 << regshift) bytes after the previous one.
diff --git a/hw/char/serial-pci-multi.c b/hw/char/serial-pci-multi.c
index 28b275709a..c2f20d8e74 100644
--- a/hw/char/serial-pci-multi.c
+++ b/hw/char/serial-pci-multi.c
@@ -132,14 +132,14 @@ static const VMStateDescription vmstate_pci_multi_serial = {
     }
 };
 
-static Property multi_2x_serial_pci_properties[] = {
+static const Property multi_2x_serial_pci_properties[] = {
     DEFINE_PROP_CHR("chardev1",  PCIMultiSerialState, state[0].chr),
     DEFINE_PROP_CHR("chardev2",  PCIMultiSerialState, state[1].chr),
     DEFINE_PROP_UINT8("prog_if",  PCIMultiSerialState, prog_if, 0x02),
     DEFINE_PROP_END_OF_LIST(),
 };
 
-static Property multi_4x_serial_pci_properties[] = {
+static const Property multi_4x_serial_pci_properties[] = {
     DEFINE_PROP_CHR("chardev1",  PCIMultiSerialState, state[0].chr),
     DEFINE_PROP_CHR("chardev2",  PCIMultiSerialState, state[1].chr),
     DEFINE_PROP_CHR("chardev3",  PCIMultiSerialState, state[2].chr),
diff --git a/hw/char/serial-pci.c b/hw/char/serial-pci.c
index f8a1a94d0c..2f487a3a79 100644
--- a/hw/char/serial-pci.c
+++ b/hw/char/serial-pci.c
@@ -81,7 +81,7 @@ static const VMStateDescription vmstate_pci_serial = {
     }
 };
 
-static Property serial_pci_properties[] = {
+static const Property serial_pci_properties[] = {
     DEFINE_PROP_UINT8("prog_if",  PCISerialState, prog_if, 0x02),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/char/serial.c b/hw/char/serial.c
index b50a8a1313..85dba02ace 100644
--- a/hw/char/serial.c
+++ b/hw/char/serial.c
@@ -964,7 +964,7 @@ const MemoryRegionOps serial_io_ops = {
     .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
-static Property serial_properties[] = {
+static const Property serial_properties[] = {
     DEFINE_PROP_CHR("chardev", SerialState, chr),
     DEFINE_PROP_UINT32("baudbase", SerialState, baudbase, 115200),
     DEFINE_PROP_BOOL("wakeup", SerialState, wakeup, false),
diff --git a/hw/char/sh_serial.c b/hw/char/sh_serial.c
index 429b2562aa..2ab7197aee 100644
--- a/hw/char/sh_serial.c
+++ b/hw/char/sh_serial.c
@@ -447,7 +447,7 @@ static void sh_serial_init(Object *obj)
 {
 }
 
-static Property sh_serial_properties[] = {
+static const Property sh_serial_properties[] = {
     DEFINE_PROP_CHR("chardev", SHSerialState, chr),
     DEFINE_PROP_UINT8("features", SHSerialState, feat, 0),
     DEFINE_PROP_END_OF_LIST()
diff --git a/hw/char/shakti_uart.c b/hw/char/shakti_uart.c
index 4a71953c9a..6e56754ca6 100644
--- a/hw/char/shakti_uart.c
+++ b/hw/char/shakti_uart.c
@@ -157,7 +157,7 @@ static void shakti_uart_instance_init(Object *obj)
     sysbus_init_mmio(SYS_BUS_DEVICE(obj), &sus->mmio);
 }
 
-static Property shakti_uart_properties[] = {
+static const Property shakti_uart_properties[] = {
     DEFINE_PROP_CHR("chardev", ShaktiUartState, chr),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/char/sifive_uart.c b/hw/char/sifive_uart.c
index 5ae2a29ed6..97e4be37c0 100644
--- a/hw/char/sifive_uart.c
+++ b/hw/char/sifive_uart.c
@@ -251,7 +251,7 @@ static int sifive_uart_be_change(void *opaque)
     return 0;
 }
 
-static Property sifive_uart_properties[] = {
+static const Property sifive_uart_properties[] = {
     DEFINE_PROP_CHR("chardev", SiFiveUARTState, chr),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/char/spapr_vty.c b/hw/char/spapr_vty.c
index 3e23d9cbab..cd91dad709 100644
--- a/hw/char/spapr_vty.c
+++ b/hw/char/spapr_vty.c
@@ -163,7 +163,7 @@ void spapr_vty_create(SpaprVioBus *bus, Chardev *chardev)
     qdev_realize_and_unref(dev, &bus->bus, &error_fatal);
 }
 
-static Property spapr_vty_properties[] = {
+static const Property spapr_vty_properties[] = {
     DEFINE_SPAPR_PROPERTIES(SpaprVioVty, sdev),
     DEFINE_PROP_CHR("chardev", SpaprVioVty, chardev),
     DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/char/stm32f2xx_usart.c b/hw/char/stm32f2xx_usart.c
index 17b5b1f15f..4a3c30eddb 100644
--- a/hw/char/stm32f2xx_usart.c
+++ b/hw/char/stm32f2xx_usart.c
@@ -199,7 +199,7 @@ static const MemoryRegionOps stm32f2xx_usart_ops = {
     .endianness = DEVICE_NATIVE_ENDIAN,
 };
 
-static Property stm32f2xx_usart_properties[] = {
+static const Property stm32f2xx_usart_properties[] = {
     DEFINE_PROP_CHR("chardev", STM32F2XXUsartState, chr),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/char/stm32l4x5_usart.c b/hw/char/stm32l4x5_usart.c
index 3cf200c080..360e79cc3f 100644
--- a/hw/char/stm32l4x5_usart.c
+++ b/hw/char/stm32l4x5_usart.c
@@ -534,7 +534,7 @@ static const MemoryRegionOps stm32l4x5_usart_base_ops = {
     },
 };
 
-static Property stm32l4x5_usart_base_properties[] = {
+static const Property stm32l4x5_usart_base_properties[] = {
     DEFINE_PROP_CHR("chardev", Stm32l4x5UsartBaseState, chr),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/char/terminal3270.c b/hw/char/terminal3270.c
index 82e85fac2e..c2aafda0ce 100644
--- a/hw/char/terminal3270.c
+++ b/hw/char/terminal3270.c
@@ -283,7 +283,7 @@ static int write_payload_3270(EmulatedCcw3270Device *dev, uint8_t cmd)
     return (retval <= 0) ? 0 : get_cds(t)->count;
 }
 
-static Property terminal_properties[] = {
+static const Property terminal_properties[] = {
     DEFINE_PROP_CHR("chardev", Terminal3270, chr),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/char/virtio-console.c b/hw/char/virtio-console.c
index dbe0b28e60..f58292e2bb 100644
--- a/hw/char/virtio-console.c
+++ b/hw/char/virtio-console.c
@@ -274,7 +274,7 @@ static const TypeInfo virtconsole_info = {
     .class_init    = virtconsole_class_init,
 };
 
-static Property virtserialport_properties[] = {
+static const Property virtserialport_properties[] = {
     DEFINE_PROP_CHR("chardev", VirtConsole, chr),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 2094d213cd..1e631bcb2b 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -835,7 +835,7 @@ static int virtio_serial_load_device(VirtIODevice *vdev, QEMUFile *f,
 
 static void virtser_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent);
 
-static Property virtser_props[] = {
+static const Property virtser_props[] = {
     DEFINE_PROP_UINT32("nr", VirtIOSerialPort, id, VIRTIO_CONSOLE_BAD_ID),
     DEFINE_PROP_STRING("name", VirtIOSerialPort, name),
     DEFINE_PROP_END_OF_LIST()
@@ -1153,7 +1153,7 @@ static const VMStateDescription vmstate_virtio_console = {
     },
 };
 
-static Property virtio_serial_properties[] = {
+static const Property virtio_serial_properties[] = {
     DEFINE_PROP_UINT32("max_ports", VirtIOSerial, serial.max_virtserial_ports,
                                                   31),
     DEFINE_PROP_BIT64("emergency-write", VirtIOSerial, host_features,
diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index 683c92aca1..c20c1b4b84 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -487,7 +487,7 @@ static char *xen_console_get_frontend_path(XenDevice *xendev, Error **errp)
 }
 
 
-static Property xen_console_properties[] = {
+static const Property xen_console_properties[] = {
     DEFINE_PROP_CHR("chardev", XenConsole, chr),
     DEFINE_PROP_INT32("idx", XenConsole, dev, -1),
     DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/char/xilinx_uartlite.c b/hw/char/xilinx_uartlite.c
index f325084f8b..ad77226217 100644
--- a/hw/char/xilinx_uartlite.c
+++ b/hw/char/xilinx_uartlite.c
@@ -176,7 +176,7 @@ static const MemoryRegionOps uart_ops = {
     }
 };
 
-static Property xilinx_uartlite_properties[] = {
+static const Property xilinx_uartlite_properties[] = {
     DEFINE_PROP_CHR("chardev", XilinxUARTLite, chr),
     DEFINE_PROP_END_OF_LIST(),
 };
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 19:09:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 19:09:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857088.1269525 (Exim 4.92)
	(envelope-from )
	id 1tMB2C-0004hs-6m; Fri, 13 Dec 2024 19:09:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857088.1269525; Fri, 13 Dec 2024 19:09: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 1tMB2C-0004hl-3v; Fri, 13 Dec 2024 19:09:08 +0000
Received: by outflank-mailman (input) for mailman id 857088;
 Fri, 13 Dec 2024 19:09: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 1tMB2A-0004TW-Uu
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 19:09:06 +0000
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com
 [2607:f8b0:4864:20::32d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b852f025-b985-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 20:09:05 +0100 (CET)
Received: by mail-ot1-x32d.google.com with SMTP id
 46e09a7af769-71e2aa8d5e3so1086778a34.2
 for ; Fri, 13 Dec 2024 11:09:05 -0800 (PST)
Received: from stoup.. ([187.217.227.247]) by smtp.gmail.com with ESMTPSA id
 46e09a7af769-71e4834da91sm29697a34.18.2024.12.13.11.09.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 11:09: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: b852f025-b985-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1734116944; x=1734721744; 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=dvKuTabJuM44RrR9LqcDtNRzVnC+ouLNjCo5mA0gZDg=;
        b=gC/gomOO+FDbnqz7bFspjcJXROTR4HEevGRfrf/56eLxkMGJ8C9flybddKA6fpbUHT
         Kl3xICcCmrhkwuPG1aHqLTfhIL/3/CO2/as2Ey3Ha0MjB87QHnHGoZPIurtCU9Wz1LGh
         YtLZF525p0paJJFSdrw2wH+ib06fvlOM0iWUfNkM5edPfcl4eBgV7SR64YMWh9MD7h4t
         /glKpzjjx5bHJ/LrhHW0dylkUae9hrEo7j6ox2NvUOBEzYV8BsABE1ab+ENcs3ySvrFn
         549MAXQxeN0w1jky8RBROSVr9703k1NcTDrFzghMibeNjSRNULk4gbJeBUPjkKpAJ561
         /uOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734116944; x=1734721744;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=dvKuTabJuM44RrR9LqcDtNRzVnC+ouLNjCo5mA0gZDg=;
        b=cs/Utu+mJhmcQyGEo2Ar6fKLcNIjuBglqFlfFp8TdCq8nWatWgra28/Kj1lDIy4Vew
         Sycn+zDA+ajUbInnc6be6YWD5zYlW2ZO3zwEY8S2Z4Cp7bNZcUYvL7KE3qTVC5ozqNAY
         ljdPRAcFcQFIBgnn7v5Ht2zvXdsHq0zxvKN1aNfLsNehJGLPFSRW00pxPI0YX9I4Vd8/
         PjXxwSWizrPxhwVxhackBHlVi+pi4aG+I/WUCyfGSO2lDumNtiMvz1HQS3HdSXYovsIu
         dSAPjeatulnyqCRNxpHrDPJ62jciGBzKZIJEpzS6plpN68FnGmJH9oZLzUUHM9OU9ucE
         /UJw==
X-Forwarded-Encrypted: i=1; AJvYcCXVeBpTk9emX1ETCTnJUKw5qw8O1RzH8ejPqFP2qzCeXQJFVym6n+5sJLa8ZykOz81bXjksHTDCRwk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx9hwNRjmbpjPNZIOaGimYpqnGEfN/7ImV6jejsWH3pZXc7b7MK
	lF/R34UnnuNxc6NS4lbNyYXG+pLgZNeBwnYEacA4JJRngKb8CE1oTuXZKWUEpoo=
X-Gm-Gg: ASbGnctT2E20UgjQE7NnrZj+0z+BQA8KOXVZuu/OEi6TxmRnUUFjqRIzDDlN94jO9kh
	m1JCOab0ZDke02GZJMtvIsWu4d0hpWogKYQ9gcklL+R7vB26+yE9mKF0nw+FMOnRiNPgSPZlDgO
	bEChoiXjDP80inQT5S3/BIp4ExuGlhXELL0xjGNncyRm9fd3goNr6Ut9f+ZqIKMgFaqRh+2atL3
	MMR1zisbf8SsoCnONfyy4Gpq0yasNiXok5W18OM1HRUrtaTbLeOHahs/Z1kbuPH
X-Google-Smtp-Source: AGHT+IH4rJcdXbtBNLnupXAb1IE3M6qGGNYml9H8C6S7DGbxJKBCaGKoGLFrcPQYq1LiK/0DBH3rEw==
X-Received: by 2002:a05:6830:6e18:b0:71d:f239:c0a8 with SMTP id 46e09a7af769-71e3b827be9mr2189273a34.6.1734116944096;
        Fri, 13 Dec 2024 11:09:04 -0800 (PST)
From: Richard Henderson 
To: qemu-devel@nongnu.org
Cc: John Snow ,
	Kevin Wolf ,
	Hanna Reitz ,
	Alistair Francis ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Laurent Vivier ,
	Raphael Norwitz ,
	"Michael S. Tsirkin" ,
	Stefano Garzarella ,
	Stefan Hajnoczi ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	qemu-block@nongnu.org (open list:Floppy),
	xen-devel@lists.xenproject.org (open list:X86 Xen CPUs)
Subject: [PATCH 19/71] hw/block: Constify all Property
Date: Fri, 13 Dec 2024 13:06:53 -0600
Message-ID: <20241213190750.2513964-24-richard.henderson@linaro.org>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213190750.2513964-1-richard.henderson@linaro.org>
References: <20241213190750.2513964-1-richard.henderson@linaro.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Richard Henderson 
---
 hw/block/fdc-isa.c        | 2 +-
 hw/block/fdc-sysbus.c     | 4 ++--
 hw/block/fdc.c            | 2 +-
 hw/block/m25p80.c         | 2 +-
 hw/block/nand.c           | 2 +-
 hw/block/pflash_cfi01.c   | 2 +-
 hw/block/pflash_cfi02.c   | 2 +-
 hw/block/swim.c           | 2 +-
 hw/block/vhost-user-blk.c | 2 +-
 hw/block/virtio-blk.c     | 2 +-
 hw/block/xen-block.c      | 2 +-
 11 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/hw/block/fdc-isa.c b/hw/block/fdc-isa.c
index 5ed3c18c28..2b9f667fe4 100644
--- a/hw/block/fdc-isa.c
+++ b/hw/block/fdc-isa.c
@@ -283,7 +283,7 @@ static const VMStateDescription vmstate_isa_fdc = {
     }
 };
 
-static Property isa_fdc_properties[] = {
+static const Property isa_fdc_properties[] = {
     DEFINE_PROP_UINT32("iobase", FDCtrlISABus, iobase, 0x3f0),
     DEFINE_PROP_UINT32("irq", FDCtrlISABus, irq, 6),
     DEFINE_PROP_UINT32("dma", FDCtrlISABus, dma, 2),
diff --git a/hw/block/fdc-sysbus.c b/hw/block/fdc-sysbus.c
index e1ddbf3d1a..f17e04b138 100644
--- a/hw/block/fdc-sysbus.c
+++ b/hw/block/fdc-sysbus.c
@@ -196,7 +196,7 @@ static const TypeInfo sysbus_fdc_common_typeinfo = {
     .class_size    = sizeof(FDCtrlSysBusClass),
 };
 
-static Property sysbus_fdc_properties[] = {
+static const Property sysbus_fdc_properties[] = {
     DEFINE_PROP_SIGNED("fdtypeA", FDCtrlSysBus, state.qdev_for_drives[0].type,
                         FLOPPY_DRIVE_TYPE_AUTO, qdev_prop_fdc_drive_type,
                         FloppyDriveType),
@@ -223,7 +223,7 @@ static const TypeInfo sysbus_fdc_typeinfo = {
     .class_init    = sysbus_fdc_class_init,
 };
 
-static Property sun4m_fdc_properties[] = {
+static const Property sun4m_fdc_properties[] = {
     DEFINE_PROP_SIGNED("fdtype", FDCtrlSysBus, state.qdev_for_drives[0].type,
                         FLOPPY_DRIVE_TYPE_AUTO, qdev_prop_fdc_drive_type,
                         FloppyDriveType),
diff --git a/hw/block/fdc.c b/hw/block/fdc.c
index 6dd94e98bc..57d6844806 100644
--- a/hw/block/fdc.c
+++ b/hw/block/fdc.c
@@ -454,7 +454,7 @@ struct FloppyDrive {
     FloppyDriveType type;
 };
 
-static Property floppy_drive_properties[] = {
+static const Property floppy_drive_properties[] = {
     DEFINE_PROP_UINT32("unit", FloppyDrive, unit, -1),
     DEFINE_BLOCK_PROPERTIES(FloppyDrive, conf),
     DEFINE_PROP_SIGNED("drive-type", FloppyDrive, type,
diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
index 748594524e..ca97365926 100644
--- a/hw/block/m25p80.c
+++ b/hw/block/m25p80.c
@@ -1720,7 +1720,7 @@ static int m25p80_pre_save(void *opaque)
     return 0;
 }
 
-static Property m25p80_properties[] = {
+static const Property m25p80_properties[] = {
     /* This is default value for Micron flash */
     DEFINE_PROP_BOOL("write-enable", Flash, write_enable, false),
     DEFINE_PROP_UINT32("nonvolatile-cfg", Flash, nonvolatile_cfg, 0x8FFF),
diff --git a/hw/block/nand.c b/hw/block/nand.c
index ac0a5d2b42..b6e6bfac23 100644
--- a/hw/block/nand.c
+++ b/hw/block/nand.c
@@ -445,7 +445,7 @@ static void nand_realize(DeviceState *dev, Error **errp)
     s->ioaddr = s->io;
 }
 
-static Property nand_properties[] = {
+static const Property nand_properties[] = {
     DEFINE_PROP_UINT8("manufacturer_id", NANDFlashState, manf_id, 0),
     DEFINE_PROP_UINT8("chip_id", NANDFlashState, chip_id, 0),
     DEFINE_PROP_DRIVE("drive", NANDFlashState, blk),
diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
index 21a81b44f0..20f4fc67a0 100644
--- a/hw/block/pflash_cfi01.c
+++ b/hw/block/pflash_cfi01.c
@@ -895,7 +895,7 @@ static void pflash_cfi01_system_reset(DeviceState *dev)
     pfl->blk_offset = -1;
 }
 
-static Property pflash_cfi01_properties[] = {
+static const Property pflash_cfi01_properties[] = {
     DEFINE_PROP_DRIVE("drive", PFlashCFI01, blk),
     /* num-blocks is the number of blocks actually visible to the guest,
      * ie the total size of the device divided by the sector length.
diff --git a/hw/block/pflash_cfi02.c b/hw/block/pflash_cfi02.c
index 8393f261b8..c82002d665 100644
--- a/hw/block/pflash_cfi02.c
+++ b/hw/block/pflash_cfi02.c
@@ -937,7 +937,7 @@ static void pflash_cfi02_reset(DeviceState *dev)
     pflash_reset_state_machine(pfl);
 }
 
-static Property pflash_cfi02_properties[] = {
+static const Property pflash_cfi02_properties[] = {
     DEFINE_PROP_DRIVE("drive", PFlashCFI02, blk),
     DEFINE_PROP_UINT32("num-blocks", PFlashCFI02, uniform_nb_blocs, 0),
     DEFINE_PROP_UINT32("sector-length", PFlashCFI02, uniform_sector_len, 0),
diff --git a/hw/block/swim.c b/hw/block/swim.c
index 64992eb72e..c336d83bdc 100644
--- a/hw/block/swim.c
+++ b/hw/block/swim.c
@@ -166,7 +166,7 @@ static const BlockDevOps swim_block_ops = {
     .change_media_cb = swim_change_cb,
 };
 
-static Property swim_drive_properties[] = {
+static const Property swim_drive_properties[] = {
     DEFINE_PROP_INT32("unit", SWIMDrive, unit, -1),
     DEFINE_BLOCK_PROPERTIES(SWIMDrive, conf),
     DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
index 7996e49821..f3ac007108 100644
--- a/hw/block/vhost-user-blk.c
+++ b/hw/block/vhost-user-blk.c
@@ -570,7 +570,7 @@ static const VMStateDescription vmstate_vhost_user_blk = {
     },
 };
 
-static Property vhost_user_blk_properties[] = {
+static const Property vhost_user_blk_properties[] = {
     DEFINE_PROP_CHR("chardev", VHostUserBlk, chardev),
     DEFINE_PROP_UINT16("num-queues", VHostUserBlk, num_queues,
                        VHOST_USER_BLK_AUTO_NUM_QUEUES),
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 9166d7974d..9ca60fbc07 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -1985,7 +1985,7 @@ static const VMStateDescription vmstate_virtio_blk = {
     },
 };
 
-static Property virtio_blk_properties[] = {
+static const Property virtio_blk_properties[] = {
     DEFINE_BLOCK_PROPERTIES(VirtIOBlock, conf.conf),
     DEFINE_BLOCK_ERROR_PROPERTIES(VirtIOBlock, conf.conf),
     DEFINE_BLOCK_CHS_PROPERTIES(VirtIOBlock, conf.conf),
diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index 72cfd6893a..0c0817f498 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -666,7 +666,7 @@ static const PropertyInfo xen_block_prop_vdev = {
     .set = xen_block_set_vdev,
 };
 
-static Property xen_block_props[] = {
+static const Property xen_block_props[] = {
     DEFINE_PROP("vdev", XenBlockDevice, props.vdev,
                 xen_block_prop_vdev, XenBlockVdev),
     DEFINE_BLOCK_PROPERTIES(XenBlockDevice, props.conf),
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 19:10:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 19:10:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857116.1269545 (Exim 4.92)
	(envelope-from )
	id 1tMB3U-00073B-RK; Fri, 13 Dec 2024 19:10:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857116.1269545; Fri, 13 Dec 2024 19:10:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tMB3U-000734-Np; Fri, 13 Dec 2024 19:10:28 +0000
Received: by outflank-mailman (input) for mailman id 857116;
 Fri, 13 Dec 2024 19:10: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 1tMB3S-0005GA-Tr
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 19:10:26 +0000
Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com
 [2607:f8b0:4864:20::32c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e89ac4e4-b985-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 20:10:26 +0100 (CET)
Received: by mail-ot1-x32c.google.com with SMTP id
 46e09a7af769-71e1158fe3eso975036a34.1
 for ; Fri, 13 Dec 2024 11:10:26 -0800 (PST)
Received: from stoup.. ([187.217.227.247]) by smtp.gmail.com with ESMTPSA id
 46e09a7af769-71e4834da91sm29697a34.18.2024.12.13.11.10.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 11:10: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: e89ac4e4-b985-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1734117025; x=1734721825; 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=t1hIg4oc5GY14Zd4SHmDtJmfPLkCBWu0upl9dxEz8/g=;
        b=oGGZ+6mTqbfoTTn/dhGDIh0fDtYPuuGgbzI0MpEyq9S6aMsJX5/sZ6EEeXgnrgZD85
         tHwXlP/1D/tnC8KK+vh7ioghvHmN4Q/mK/Nn0VI2gfhWzxX5jjdN0YlznwkfM2nl9qdN
         abNJkUWtV4rODq1OdFTH9K3vU9Az+fo8RyV7nV9v7rtcZBC2B/G7HyIEhTyvVHTPgKlJ
         vb3J0ryq0B15zU3c7gVtjq7donV91jBhln0tubHSmVzC4MWp7oJziKgoQAd62wuu69Ez
         eXYyMD6oaIW2z/1LRmNfeUzdna+ihpm2qBI943wfGPDFP/I/yRgXFeSbmTajPSUt1CTy
         hExA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734117025; x=1734721825;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=t1hIg4oc5GY14Zd4SHmDtJmfPLkCBWu0upl9dxEz8/g=;
        b=xNZBgTulc94x2PBX/DqC3ksZrVU7fo0FND4vX6p+lnxVEtWmQhKzuD3TbV4tNrLBfn
         d+MWcBFA1j8/6kbHpYdz/RckCqI1JBewc7oSoVPK9Ipf/mfWu5+ZFMnMrAMcgbQQJ/UJ
         cyluw9TW/m8pHzx1afrvHjV5hX8CGpB6cEZmkq8i5R00CnBYaFmz1OaWJaUZn9ZfRtEo
         SwUMPa4rbRf7UrQZhGZv/9qiydOXcPN6BO0F7+XzczFCk9oKGRXi6Ul0lOffhPFqgC35
         p1JBXLlqZwTdD552WffmWOWhodg3VL1Uvzct84eGWFLGr6KU6QMFEmiwzrjvglOsMZOI
         yDUg==
X-Forwarded-Encrypted: i=1; AJvYcCWGPHSUF0zYDT/Rq+1JSoKB8W9v6x5D+2CFLRjczG6D8TGNZICgRX5uRxjORSt0puYRfLQGW+ovl+A=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwvMV6vRnMh0aZeHCq7WX97nlw8Blwh5RMy7bVK53tz2S/xuCnz
	ncZ3HLghbr0rZ8IlrfzMAYSIBijX4tYrZo+bUTFUn8kR4RolBleIq8mkvrUOMC8=
X-Gm-Gg: ASbGnct2w8/566jzGdUNEs0ZMJxexXF2uPcg0/8iXnhr14PGTrFTsrHFYS/FGky2WOe
	EWROICWBZeYgy1jrwXVoLy4+ay5nw92cWD19ypOxICID9bSoEntZnL0XjETPpmT4e+JCNClygqX
	Sl9V5hd2X5N/2y/d3WRe2T47SfAzWTInMs6tfMN2BFU8KOy3z4RlKjEO5eY+gv6xpAR63glQjwM
	hbcRKA7NJhAjd86bZy+Hgedr2m9we+KQ3db8u05DFOYCuDxRVS+zj+nYkRo+lK4
X-Google-Smtp-Source: AGHT+IHwfk+yWhygf0MTMKyExMm9RZrHBdGyaRiigL/H+X/LC3MhVRZSqRde0AcS403E+WEtKhsmHQ==
X-Received: by 2002:a05:6830:700f:b0:71d:ffa2:d34d with SMTP id 46e09a7af769-71e3b879bbbmr2283286a34.16.1734117025113;
        Fri, 13 Dec 2024 11:10:25 -0800 (PST)
From: Richard Henderson 
To: qemu-devel@nongnu.org
Cc: "Michael S. Tsirkin" ,
	Marcel Apfelbaum ,
	Paolo Bonzini ,
	Eduardo Habkost ,
	Jason Wang ,
	Yi Liu ,
	=?UTF-8?q?Cl=C3=A9ment=20Mathieu--Drif?= ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org (open list:X86 Xen CPUs)
Subject: [PATCH 29/71] hw/i386: Constify all Property
Date: Fri, 13 Dec 2024 13:07:03 -0600
Message-ID: <20241213190750.2513964-34-richard.henderson@linaro.org>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213190750.2513964-1-richard.henderson@linaro.org>
References: <20241213190750.2513964-1-richard.henderson@linaro.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Richard Henderson 
---
 hw/i386/amd_iommu.c        | 2 +-
 hw/i386/intel_iommu.c      | 2 +-
 hw/i386/kvm/clock.c        | 2 +-
 hw/i386/kvm/i8254.c        | 2 +-
 hw/i386/kvm/ioapic.c       | 2 +-
 hw/i386/sgx-epc.c          | 2 +-
 hw/i386/vmmouse.c          | 2 +-
 hw/i386/vmport.c           | 2 +-
 hw/i386/x86-iommu.c        | 2 +-
 hw/i386/xen/xen_pvdevice.c | 2 +-
 10 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
index af0f4da1f6..ca3e62a244 100644
--- a/hw/i386/amd_iommu.c
+++ b/hw/i386/amd_iommu.c
@@ -1668,7 +1668,7 @@ static void amdvi_sysbus_realize(DeviceState *dev, Error **errp)
     amdvi_init(s);
 }
 
-static Property amdvi_properties[] = {
+static const Property amdvi_properties[] = {
     DEFINE_PROP_BOOL("xtsup", AMDVIState, xtsup, false),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 4c0d1d7d47..a5b268342f 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -3404,7 +3404,7 @@ static const MemoryRegionOps vtd_mem_ops = {
     },
 };
 
-static Property vtd_properties[] = {
+static const Property vtd_properties[] = {
     DEFINE_PROP_UINT32("version", IntelIOMMUState, version, 0),
     DEFINE_PROP_ON_OFF_AUTO("eim", IntelIOMMUState, intr_eim,
                             ON_OFF_AUTO_AUTO),
diff --git a/hw/i386/kvm/clock.c b/hw/i386/kvm/clock.c
index 40aa9a32c3..71150ed2e0 100644
--- a/hw/i386/kvm/clock.c
+++ b/hw/i386/kvm/clock.c
@@ -305,7 +305,7 @@ static const VMStateDescription kvmclock_vmsd = {
     }
 };
 
-static Property kvmclock_properties[] = {
+static const Property kvmclock_properties[] = {
     DEFINE_PROP_BOOL("x-mach-use-reliable-get-clock", KVMClockState,
                       mach_use_reliable_get_clock, true),
     DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/i386/kvm/i8254.c b/hw/i386/kvm/i8254.c
index baa4b39582..2933d3f458 100644
--- a/hw/i386/kvm/i8254.c
+++ b/hw/i386/kvm/i8254.c
@@ -287,7 +287,7 @@ static void kvm_pit_realizefn(DeviceState *dev, Error **errp)
     kpc->parent_realize(dev, errp);
 }
 
-static Property kvm_pit_properties[] = {
+static const Property kvm_pit_properties[] = {
     DEFINE_PROP_LOSTTICKPOLICY("lost_tick_policy", KVMPITState,
                                lost_tick_policy, LOST_TICK_POLICY_DELAY),
     DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/i386/kvm/ioapic.c b/hw/i386/kvm/ioapic.c
index 2907b08164..217ff43b98 100644
--- a/hw/i386/kvm/ioapic.c
+++ b/hw/i386/kvm/ioapic.c
@@ -133,7 +133,7 @@ static void kvm_ioapic_realize(DeviceState *dev, Error **errp)
     qdev_init_gpio_in(dev, kvm_ioapic_set_irq, IOAPIC_NUM_PINS);
 }
 
-static Property kvm_ioapic_properties[] = {
+static const Property kvm_ioapic_properties[] = {
     DEFINE_PROP_UINT32("gsi_base", KVMIOAPICState, kvm_gsi_base, 0),
     DEFINE_PROP_END_OF_LIST()
 };
diff --git a/hw/i386/sgx-epc.c b/hw/i386/sgx-epc.c
index d664829d35..c232e825e0 100644
--- a/hw/i386/sgx-epc.c
+++ b/hw/i386/sgx-epc.c
@@ -19,7 +19,7 @@
 #include "target/i386/cpu.h"
 #include "exec/address-spaces.h"
 
-static Property sgx_epc_properties[] = {
+static const Property sgx_epc_properties[] = {
     DEFINE_PROP_UINT64(SGX_EPC_ADDR_PROP, SGXEPCDevice, addr, 0),
     DEFINE_PROP_UINT32(SGX_EPC_NUMA_NODE_PROP, SGXEPCDevice, node, 0),
     DEFINE_PROP_LINK(SGX_EPC_MEMDEV_PROP, SGXEPCDevice, hostmem,
diff --git a/hw/i386/vmmouse.c b/hw/i386/vmmouse.c
index 76130cd46d..da9c35c1ec 100644
--- a/hw/i386/vmmouse.c
+++ b/hw/i386/vmmouse.c
@@ -317,7 +317,7 @@ static void vmmouse_realizefn(DeviceState *dev, Error **errp)
     vmport_register(VMPORT_CMD_VMMOUSE_DATA, vmmouse_ioport_read, s);
 }
 
-static Property vmmouse_properties[] = {
+static const Property vmmouse_properties[] = {
     DEFINE_PROP_LINK("i8042", VMMouseState, i8042, TYPE_I8042, ISAKBDState *),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
index 7cc75dbc6d..cab6e72089 100644
--- a/hw/i386/vmport.c
+++ b/hw/i386/vmport.c
@@ -252,7 +252,7 @@ static void vmport_realizefn(DeviceState *dev, Error **errp)
     }
 }
 
-static Property vmport_properties[] = {
+static const Property vmport_properties[] = {
     /* Used to enforce compatibility for migration */
     DEFINE_PROP_BIT("x-read-set-eax", VMPortState, compat_flags,
                     VMPORT_COMPAT_READ_SET_EAX_BIT, true),
diff --git a/hw/i386/x86-iommu.c b/hw/i386/x86-iommu.c
index 60af896225..155f6262ea 100644
--- a/hw/i386/x86-iommu.c
+++ b/hw/i386/x86-iommu.c
@@ -125,7 +125,7 @@ static void x86_iommu_realize(DeviceState *dev, Error **errp)
     }
 }
 
-static Property x86_iommu_properties[] = {
+static const Property x86_iommu_properties[] = {
     DEFINE_PROP_ON_OFF_AUTO("intremap", X86IOMMUState,
                             intr_supported, ON_OFF_AUTO_AUTO),
     DEFINE_PROP_BOOL("device-iotlb", X86IOMMUState, dt_supported, false),
diff --git a/hw/i386/xen/xen_pvdevice.c b/hw/i386/xen/xen_pvdevice.c
index ed621531d8..e71483e6e3 100644
--- a/hw/i386/xen/xen_pvdevice.c
+++ b/hw/i386/xen/xen_pvdevice.c
@@ -115,7 +115,7 @@ static void xen_pv_realize(PCIDevice *pci_dev, Error **errp)
                      &d->mmio);
 }
 
-static Property xen_pv_props[] = {
+static const Property xen_pv_props[] = {
     DEFINE_PROP_UINT16("vendor-id", XenPVDevice, vendor_id, PCI_VENDOR_ID_XEN),
     DEFINE_PROP_UINT16("device-id", XenPVDevice, device_id, 0xffff),
     DEFINE_PROP_UINT8("revision", XenPVDevice, revision, 0x01),
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 19:14:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 19:14:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857135.1269554 (Exim 4.92)
	(envelope-from )
	id 1tMB6v-0007xI-Cx; Fri, 13 Dec 2024 19:14:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857135.1269554; Fri, 13 Dec 2024 19:14: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 1tMB6v-0007xB-AC; Fri, 13 Dec 2024 19:14:01 +0000
Received: by outflank-mailman (input) for mailman id 857135;
 Fri, 13 Dec 2024 19:13:59 +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 1tMB6t-0007x5-Ep
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 19:13:59 +0000
Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com
 [2607:f8b0:4864:20::235])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 657b258d-b986-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 20:13:55 +0100 (CET)
Received: by mail-oi1-x235.google.com with SMTP id
 5614622812f47-3eb7edfa42dso1063947b6e.2
 for ; Fri, 13 Dec 2024 11:13:55 -0800 (PST)
Received: from stoup.. ([187.217.227.247]) by smtp.gmail.com with ESMTPSA id
 5614622812f47-3ebb478a497sm3545b6e.10.2024.12.13.11.13.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 11:13: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: 657b258d-b986-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1734117234; x=1734722034; 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=wFKwAi47wfnLcU3Qx3I/C9LQF6ejU8QSvlDRphKjPrc=;
        b=Bb19MNJNvFE8uzJDmajeQzS+kqmA0Bjcg5bIp+tzlHSjiJxV7ZYHVz+WOjoUCqlJle
         XV1qhrZ7h40Po++dmWfvWmZW1+lAKeFnaHNxFbpypOkazou+pb/LuTD7gCN/AVBjLoUR
         PBhvAQdnkPydgZ/9XDHyUZ933w4bZOxyStbBXtBEPozYyB7ldbJm7iakSR5hVtZUs8Tt
         LJtSZ7IDsHKvJ9SY5p0tqEG05PNVXoNNTbM79bcaMYcKSAqYUkA0npDrMIBB2Jx6YXA6
         CabBHhVjf4u5AXZD401RYRy33UIEbH1XOHUIUFHuagrsel2wDDP6T4vaFOGtBO6VJP4Q
         LyKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734117234; x=1734722034;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=wFKwAi47wfnLcU3Qx3I/C9LQF6ejU8QSvlDRphKjPrc=;
        b=U83vaCAbjYUQirqyTwYeHAwtGDTl08rpqNR+FWVBKeLY36DomXHn8FCkfxR1TjPikg
         VWByb0HFv1P/yeWHJ0tON4gSQRMEaH5ph4lkLJo6ghoeiLMjdaSQzT00hs45YFY2IuBq
         6ZaLOl3SATvzHNsjTS9jksQvwSvr2WBFshjgj88Cz0DbY2u6u/WRPDl3KBWA8dyahv1I
         tZtctH+qR+q1AXd8oOnTNXAP/WHWrq87wGaUUyG5LLPZKMrv2GPvxj9y5DAhpUeeXaeh
         mQwMg+41IuzZA262SYNNHUYRxcDbK+BzRyBiF6qR0YM3jLPIEAWkq6AtG7++ePmunlYO
         +/xw==
X-Forwarded-Encrypted: i=1; AJvYcCUfi3T6Suvz5T/X6Pj0aeDByPHmgqmsadO0eq7MUEpC5s+qfU2cU3O8jpBCaMcSWNdF/j71VLWD5ro=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzqsTEcgyAQvtuvT8X/kLPi5P0zqcjKsPTI7uYQEZyh5KalU3Pp
	a/gtR8/JTiJcw1QyzFHc0TGDWYbbLsg0nyzHoQgWGuHFKNDj3d9eEx38iFyMPqo=
X-Gm-Gg: ASbGncthCNMwPs3vDF+aKJCNB9tQXDFV24rNqPYcRid/T3MBuURjVNMKO3OyLRLVNtr
	X59+IAR2PNA/8Da1t48f3LWkTtbzj9FIFR8W+/zyAb/I/SQZDkBfRjIv+MtWbEAmN4y8+IYJhdq
	5EzlxVyO+fjWo4jBeXz7Dxn4Hg16gCQO2o4sjX6iZUiEAKK7PmQHxj18fdmD3CnLw0lPNXgo+Eh
	FMtXXN9Qo9LEcZ/tQs/GuHWqZ/gTUMLkUH0RsNTtul4w/8JU6D76UzcpcIdumuE
X-Google-Smtp-Source: AGHT+IFJrsAEbAzw8PHedKF8jNEE5A/ycBi7wNVu+WwdSwNIkAPFcMw1QPeZeNQ/IDou/sUxxHjwmA==
X-Received: by 2002:a05:6808:d4e:b0:3ea:519e:cc92 with SMTP id 5614622812f47-3eba699ea30mr2505794b6e.37.1734117234416;
        Fri, 13 Dec 2024 11:13:54 -0800 (PST)
From: Richard Henderson 
To: qemu-devel@nongnu.org
Cc: Beniamino Galvani ,
	Peter Maydell ,
	Strahinja Jankovic ,
	Jason Wang ,
	"Edgar E. Iglesias" ,
	Alistair Francis ,
	Pavel Pisa ,
	Francisco Iglesias ,
	Vikram Garhwal ,
	Dmitry Fleytman ,
	Akihiko Odaki ,
	Stefan Weil ,
	Bernhard Beschow ,
	=?UTF-8?q?C=C3=A9dric=20Le=20Goater?= ,
	Steven Lee ,
	Troy Lee ,
	Jamin Lin ,
	Andrew Jeffery ,
	Joel Stanley ,
	Sriram Yagnaraman ,
	Helge Deller ,
	Thomas Huth ,
	Aleksandar Rikalo ,
	Subbaraya Sundeep ,
	Jan Kiszka ,
	Tyrone Ting ,
	Hao Wu ,
	Max Filippov ,
	Jiri Pirko ,
	Nicholas Piggin ,
	Daniel Henrique Barboza ,
	Harsh Prateek Bora ,
	Sven Schnelle ,
	"Michael S. Tsirkin" ,
	Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	Rob Herring ,
	qemu-arm@nongnu.org (open list:Allwinner-a10),
	qemu-ppc@nongnu.org (open list:e500),
	xen-devel@lists.xenproject.org (open list:X86 Xen CPUs)
Subject: [PATCH 41/71] hw/net: Constify all Property
Date: Fri, 13 Dec 2024 13:07:15 -0600
Message-ID: <20241213190750.2513964-46-richard.henderson@linaro.org>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213190750.2513964-1-richard.henderson@linaro.org>
References: <20241213190750.2513964-1-richard.henderson@linaro.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Richard Henderson 
---
 hw/net/allwinner-sun8i-emac.c  | 2 +-
 hw/net/allwinner_emac.c        | 2 +-
 hw/net/cadence_gem.c           | 2 +-
 hw/net/can/xlnx-versal-canfd.c | 2 +-
 hw/net/can/xlnx-zynqmp-can.c   | 2 +-
 hw/net/dp8393x.c               | 2 +-
 hw/net/e1000.c                 | 2 +-
 hw/net/e1000e.c                | 2 +-
 hw/net/eepro100.c              | 2 +-
 hw/net/fsl_etsec/etsec.c       | 2 +-
 hw/net/ftgmac100.c             | 4 ++--
 hw/net/igb.c                   | 2 +-
 hw/net/imx_fec.c               | 2 +-
 hw/net/lan9118.c               | 2 +-
 hw/net/lance.c                 | 2 +-
 hw/net/lasi_i82596.c           | 2 +-
 hw/net/mcf_fec.c               | 2 +-
 hw/net/mipsnet.c               | 2 +-
 hw/net/msf2-emac.c             | 2 +-
 hw/net/mv88w8618_eth.c         | 2 +-
 hw/net/ne2000-isa.c            | 2 +-
 hw/net/ne2000-pci.c            | 2 +-
 hw/net/npcm7xx_emc.c           | 2 +-
 hw/net/npcm_gmac.c             | 2 +-
 hw/net/opencores_eth.c         | 2 +-
 hw/net/pcnet-pci.c             | 2 +-
 hw/net/rocker/rocker.c         | 2 +-
 hw/net/rtl8139.c               | 2 +-
 hw/net/smc91c111.c             | 2 +-
 hw/net/spapr_llan.c            | 2 +-
 hw/net/stellaris_enet.c        | 2 +-
 hw/net/sungem.c                | 2 +-
 hw/net/sunhme.c                | 2 +-
 hw/net/tulip.c                 | 2 +-
 hw/net/virtio-net.c            | 2 +-
 hw/net/vmxnet3.c               | 2 +-
 hw/net/xen_nic.c               | 2 +-
 hw/net/xgmac.c                 | 2 +-
 hw/net/xilinx_axienet.c        | 2 +-
 hw/net/xilinx_ethlite.c        | 2 +-
 40 files changed, 41 insertions(+), 41 deletions(-)

diff --git a/hw/net/allwinner-sun8i-emac.c b/hw/net/allwinner-sun8i-emac.c
index cdae74f503..3f03060bf5 100644
--- a/hw/net/allwinner-sun8i-emac.c
+++ b/hw/net/allwinner-sun8i-emac.c
@@ -829,7 +829,7 @@ static void allwinner_sun8i_emac_realize(DeviceState *dev, Error **errp)
     qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
 }
 
-static Property allwinner_sun8i_emac_properties[] = {
+static const Property allwinner_sun8i_emac_properties[] = {
     DEFINE_NIC_PROPERTIES(AwSun8iEmacState, conf),
     DEFINE_PROP_UINT8("phy-addr", AwSun8iEmacState, mii_phy_addr, 0),
     DEFINE_PROP_LINK("dma-memory", AwSun8iEmacState, dma_mr,
diff --git a/hw/net/allwinner_emac.c b/hw/net/allwinner_emac.c
index c104c2588e..39c10426cf 100644
--- a/hw/net/allwinner_emac.c
+++ b/hw/net/allwinner_emac.c
@@ -462,7 +462,7 @@ static void aw_emac_realize(DeviceState *dev, Error **errp)
     fifo8_create(&s->tx_fifo[1], TX_FIFO_SIZE);
 }
 
-static Property aw_emac_properties[] = {
+static const Property aw_emac_properties[] = {
     DEFINE_NIC_PROPERTIES(AwEmacState, conf),
     DEFINE_PROP_UINT8("phy-addr", AwEmacState, phy_addr, 0),
     DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
index 526739887c..3fce01315f 100644
--- a/hw/net/cadence_gem.c
+++ b/hw/net/cadence_gem.c
@@ -1784,7 +1784,7 @@ static const VMStateDescription vmstate_cadence_gem = {
     }
 };
 
-static Property gem_properties[] = {
+static const Property gem_properties[] = {
     DEFINE_NIC_PROPERTIES(CadenceGEMState, conf),
     DEFINE_PROP_UINT32("revision", CadenceGEMState, revision,
                        GEM_MODID_VALUE),
diff --git a/hw/net/can/xlnx-versal-canfd.c b/hw/net/can/xlnx-versal-canfd.c
index e148bd7b46..97fa46c4b3 100644
--- a/hw/net/can/xlnx-versal-canfd.c
+++ b/hw/net/can/xlnx-versal-canfd.c
@@ -2042,7 +2042,7 @@ static const VMStateDescription vmstate_canfd = {
     }
 };
 
-static Property canfd_core_properties[] = {
+static const Property canfd_core_properties[] = {
     DEFINE_PROP_UINT8("rx-fifo0", XlnxVersalCANFDState, cfg.rx0_fifo, 0x40),
     DEFINE_PROP_UINT8("rx-fifo1", XlnxVersalCANFDState, cfg.rx1_fifo, 0x40),
     DEFINE_PROP_UINT8("tx-fifo", XlnxVersalCANFDState, cfg.tx_fifo, 0x20),
diff --git a/hw/net/can/xlnx-zynqmp-can.c b/hw/net/can/xlnx-zynqmp-can.c
index 58f1432bb3..61c104c18b 100644
--- a/hw/net/can/xlnx-zynqmp-can.c
+++ b/hw/net/can/xlnx-zynqmp-can.c
@@ -1169,7 +1169,7 @@ static const VMStateDescription vmstate_can = {
     }
 };
 
-static Property xlnx_zynqmp_can_properties[] = {
+static const Property xlnx_zynqmp_can_properties[] = {
     DEFINE_PROP_UINT32("ext_clk_freq", XlnxZynqMPCANState, cfg.ext_clk_freq,
                        CAN_DEFAULT_CLOCK),
     DEFINE_PROP_LINK("canbus", XlnxZynqMPCANState, canbus, TYPE_CAN_BUS,
diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
index c0977308ba..e3ca11991b 100644
--- a/hw/net/dp8393x.c
+++ b/hw/net/dp8393x.c
@@ -931,7 +931,7 @@ static const VMStateDescription vmstate_dp8393x = {
     }
 };
 
-static Property dp8393x_properties[] = {
+static const Property dp8393x_properties[] = {
     DEFINE_NIC_PROPERTIES(dp8393xState, conf),
     DEFINE_PROP_LINK("dma_mr", dp8393xState, dma_mr,
                      TYPE_MEMORY_REGION, MemoryRegion *),
diff --git a/hw/net/e1000.c b/hw/net/e1000.c
index ab72236d18..ef0af31751 100644
--- a/hw/net/e1000.c
+++ b/hw/net/e1000.c
@@ -1677,7 +1677,7 @@ static void pci_e1000_realize(PCIDevice *pci_dev, Error **errp)
                                         e1000_flush_queue_timer, d);
 }
 
-static Property e1000_properties[] = {
+static const Property e1000_properties[] = {
     DEFINE_NIC_PROPERTIES(E1000State, conf),
     DEFINE_PROP_BIT("extra_mac_registers", E1000State,
                     compat_flags, E1000_FLAG_MAC_BIT, true),
diff --git a/hw/net/e1000e.c b/hw/net/e1000e.c
index 843892ce09..e2b7576f67 100644
--- a/hw/net/e1000e.c
+++ b/hw/net/e1000e.c
@@ -661,7 +661,7 @@ static PropertyInfo e1000e_prop_disable_vnet,
                     e1000e_prop_subsys_ven,
                     e1000e_prop_subsys;
 
-static Property e1000e_properties[] = {
+static const Property e1000e_properties[] = {
     DEFINE_NIC_PROPERTIES(E1000EState, conf),
     DEFINE_PROP_SIGNED("disable_vnet_hdr", E1000EState, disable_vnet, false,
                         e1000e_prop_disable_vnet, bool),
diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
index 20b22d8e49..b8cb8d5cf1 100644
--- a/hw/net/eepro100.c
+++ b/hw/net/eepro100.c
@@ -2058,7 +2058,7 @@ static E100PCIDeviceInfo *eepro100_get_class(EEPRO100State *s)
     return eepro100_get_class_by_name(object_get_typename(OBJECT(s)));
 }
 
-static Property e100_properties[] = {
+static const Property e100_properties[] = {
     DEFINE_NIC_PROPERTIES(EEPRO100State, conf),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/net/fsl_etsec/etsec.c b/hw/net/fsl_etsec/etsec.c
index d8076e7be4..764be2c6a2 100644
--- a/hw/net/fsl_etsec/etsec.c
+++ b/hw/net/fsl_etsec/etsec.c
@@ -414,7 +414,7 @@ static void etsec_instance_init(Object *obj)
     sysbus_init_irq(sbd, &etsec->err_irq);
 }
 
-static Property etsec_properties[] = {
+static const Property etsec_properties[] = {
     DEFINE_NIC_PROPERTIES(eTSEC, conf),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/net/ftgmac100.c b/hw/net/ftgmac100.c
index 478356ee3e..4adc7fb10c 100644
--- a/hw/net/ftgmac100.c
+++ b/hw/net/ftgmac100.c
@@ -1254,7 +1254,7 @@ static const VMStateDescription vmstate_ftgmac100 = {
     }
 };
 
-static Property ftgmac100_properties[] = {
+static const Property ftgmac100_properties[] = {
     DEFINE_PROP_BOOL("aspeed", FTGMAC100State, aspeed, false),
     DEFINE_NIC_PROPERTIES(FTGMAC100State, conf),
     DEFINE_PROP_BOOL("dma64", FTGMAC100State, dma64, false),
@@ -1415,7 +1415,7 @@ static const VMStateDescription vmstate_aspeed_mii = {
     }
 };
 
-static Property aspeed_mii_properties[] = {
+static const Property aspeed_mii_properties[] = {
     DEFINE_PROP_LINK("nic", AspeedMiiState, nic, TYPE_FTGMAC100,
                      FTGMAC100State *),
     DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/net/igb.c b/hw/net/igb.c
index b92bba402e..ad0f748d82 100644
--- a/hw/net/igb.c
+++ b/hw/net/igb.c
@@ -591,7 +591,7 @@ static const VMStateDescription igb_vmstate = {
     }
 };
 
-static Property igb_properties[] = {
+static const Property igb_properties[] = {
     DEFINE_NIC_PROPERTIES(IGBState, conf),
     DEFINE_PROP_BOOL("x-pcie-flr-init", IGBState, has_flr, true),
     DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/net/imx_fec.c b/hw/net/imx_fec.c
index 4ee6f74206..9b64968477 100644
--- a/hw/net/imx_fec.c
+++ b/hw/net/imx_fec.c
@@ -1222,7 +1222,7 @@ static void imx_eth_realize(DeviceState *dev, Error **errp)
     qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
 }
 
-static Property imx_eth_properties[] = {
+static const Property imx_eth_properties[] = {
     DEFINE_NIC_PROPERTIES(IMXFECState, conf),
     DEFINE_PROP_UINT32("tx-ring-num", IMXFECState, tx_ring_num, 1),
     DEFINE_PROP_UINT32("phy-num", IMXFECState, phy_num, 0),
diff --git a/hw/net/lan9118.c b/hw/net/lan9118.c
index 99e87b7178..237e9b97d5 100644
--- a/hw/net/lan9118.c
+++ b/hw/net/lan9118.c
@@ -1304,7 +1304,7 @@ static void lan9118_realize(DeviceState *dev, Error **errp)
     ptimer_transaction_commit(s->timer);
 }
 
-static Property lan9118_properties[] = {
+static const Property lan9118_properties[] = {
     DEFINE_NIC_PROPERTIES(lan9118_state, conf),
     DEFINE_PROP_UINT32("mode_16bit", lan9118_state, mode_16bit, 0),
     DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/net/lance.c b/hw/net/lance.c
index 269615b452..9ed9c94cff 100644
--- a/hw/net/lance.c
+++ b/hw/net/lance.c
@@ -137,7 +137,7 @@ static void lance_instance_init(Object *obj)
                                   DEVICE(obj));
 }
 
-static Property lance_properties[] = {
+static const Property lance_properties[] = {
     DEFINE_PROP_LINK("dma", SysBusPCNetState, state.dma_opaque,
                      TYPE_DEVICE, DeviceState *),
     DEFINE_NIC_PROPERTIES(SysBusPCNetState, state.conf),
diff --git a/hw/net/lasi_i82596.c b/hw/net/lasi_i82596.c
index 183fab8712..248e3841db 100644
--- a/hw/net/lasi_i82596.c
+++ b/hw/net/lasi_i82596.c
@@ -158,7 +158,7 @@ static void lasi_82596_instance_init(Object *obj)
                                   DEVICE(obj));
 }
 
-static Property lasi_82596_properties[] = {
+static const Property lasi_82596_properties[] = {
     DEFINE_NIC_PROPERTIES(SysBusI82596State, state.conf),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/net/mcf_fec.c b/hw/net/mcf_fec.c
index 037cd2028e..55bad4c069 100644
--- a/hw/net/mcf_fec.c
+++ b/hw/net/mcf_fec.c
@@ -660,7 +660,7 @@ static void mcf_fec_instance_init(Object *obj)
     }
 }
 
-static Property mcf_fec_properties[] = {
+static const Property mcf_fec_properties[] = {
     DEFINE_NIC_PROPERTIES(mcf_fec_state, conf),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/net/mipsnet.c b/hw/net/mipsnet.c
index 31bbd6fb89..c9ef1beb7b 100644
--- a/hw/net/mipsnet.c
+++ b/hw/net/mipsnet.c
@@ -266,7 +266,7 @@ static void mipsnet_sysbus_reset(DeviceState *dev)
     mipsnet_reset(s);
 }
 
-static Property mipsnet_properties[] = {
+static const Property mipsnet_properties[] = {
     DEFINE_NIC_PROPERTIES(MIPSnetState, conf),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/net/msf2-emac.c b/hw/net/msf2-emac.c
index d28fc6c570..8d9015f962 100644
--- a/hw/net/msf2-emac.c
+++ b/hw/net/msf2-emac.c
@@ -546,7 +546,7 @@ static void msf2_emac_init(Object *obj)
     sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->mmio);
 }
 
-static Property msf2_emac_properties[] = {
+static const Property msf2_emac_properties[] = {
     DEFINE_PROP_LINK("ahb-bus", MSF2EmacState, dma_mr,
                      TYPE_MEMORY_REGION, MemoryRegion *),
     DEFINE_NIC_PROPERTIES(MSF2EmacState, conf),
diff --git a/hw/net/mv88w8618_eth.c b/hw/net/mv88w8618_eth.c
index 96c65f4d46..ccb11512db 100644
--- a/hw/net/mv88w8618_eth.c
+++ b/hw/net/mv88w8618_eth.c
@@ -371,7 +371,7 @@ static const VMStateDescription mv88w8618_eth_vmsd = {
     }
 };
 
-static Property mv88w8618_eth_properties[] = {
+static const Property mv88w8618_eth_properties[] = {
     DEFINE_NIC_PROPERTIES(mv88w8618_eth_state, conf),
     DEFINE_PROP_LINK("dma-memory", mv88w8618_eth_state, dma_mr,
                      TYPE_MEMORY_REGION, MemoryRegion *),
diff --git a/hw/net/ne2000-isa.c b/hw/net/ne2000-isa.c
index 26980e087e..1cd070d419 100644
--- a/hw/net/ne2000-isa.c
+++ b/hw/net/ne2000-isa.c
@@ -79,7 +79,7 @@ static void isa_ne2000_realizefn(DeviceState *dev, Error **errp)
     qemu_format_nic_info_str(qemu_get_queue(s->nic), s->c.macaddr.a);
 }
 
-static Property ne2000_isa_properties[] = {
+static const Property ne2000_isa_properties[] = {
     DEFINE_PROP_UINT32("iobase", ISANE2000State, iobase, 0x300),
     DEFINE_PROP_UINT32("irq",   ISANE2000State, isairq, 9),
     DEFINE_NIC_PROPERTIES(ISANE2000State, ne2000.c),
diff --git a/hw/net/ne2000-pci.c b/hw/net/ne2000-pci.c
index 74773069c6..12fa579d22 100644
--- a/hw/net/ne2000-pci.c
+++ b/hw/net/ne2000-pci.c
@@ -96,7 +96,7 @@ static void ne2000_instance_init(Object *obj)
                                   &pci_dev->qdev);
 }
 
-static Property ne2000_properties[] = {
+static const Property ne2000_properties[] = {
     DEFINE_NIC_PROPERTIES(PCINE2000State, ne2000.c),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/net/npcm7xx_emc.c b/hw/net/npcm7xx_emc.c
index 7307a13400..f06e908d04 100644
--- a/hw/net/npcm7xx_emc.c
+++ b/hw/net/npcm7xx_emc.c
@@ -845,7 +845,7 @@ static const VMStateDescription vmstate_npcm7xx_emc = {
     },
 };
 
-static Property npcm7xx_emc_properties[] = {
+static const Property npcm7xx_emc_properties[] = {
     DEFINE_NIC_PROPERTIES(NPCM7xxEMCState, conf),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/net/npcm_gmac.c b/hw/net/npcm_gmac.c
index 685905f9e2..1db29307d7 100644
--- a/hw/net/npcm_gmac.c
+++ b/hw/net/npcm_gmac.c
@@ -912,7 +912,7 @@ static const VMStateDescription vmstate_npcm_gmac = {
     },
 };
 
-static Property npcm_gmac_properties[] = {
+static const Property npcm_gmac_properties[] = {
     DEFINE_NIC_PROPERTIES(NPCMGMACState, conf),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/net/opencores_eth.c b/hw/net/opencores_eth.c
index 2c0ebda100..003b452bc9 100644
--- a/hw/net/opencores_eth.c
+++ b/hw/net/opencores_eth.c
@@ -743,7 +743,7 @@ static void qdev_open_eth_reset(DeviceState *dev)
     open_eth_reset(d);
 }
 
-static Property open_eth_properties[] = {
+static const Property open_eth_properties[] = {
     DEFINE_NIC_PROPERTIES(OpenEthState, conf),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/net/pcnet-pci.c b/hw/net/pcnet-pci.c
index 6190b76916..83ba8cd949 100644
--- a/hw/net/pcnet-pci.c
+++ b/hw/net/pcnet-pci.c
@@ -252,7 +252,7 @@ static void pcnet_instance_init(Object *obj)
                                   DEVICE(obj));
 }
 
-static Property pcnet_properties[] = {
+static const Property pcnet_properties[] = {
     DEFINE_NIC_PROPERTIES(PCIPCNetState, state.conf),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/net/rocker/rocker.c b/hw/net/rocker/rocker.c
index 5e74acc969..efc20396aa 100644
--- a/hw/net/rocker/rocker.c
+++ b/hw/net/rocker/rocker.c
@@ -1459,7 +1459,7 @@ static void rocker_reset(DeviceState *dev)
     DPRINTF("Reset done\n");
 }
 
-static Property rocker_properties[] = {
+static const Property rocker_properties[] = {
     DEFINE_PROP_STRING("name", Rocker, name),
     DEFINE_PROP_STRING("world", Rocker, world_name),
     DEFINE_PROP_MACADDR("fp_start_macaddr", Rocker,
diff --git a/hw/net/rtl8139.c b/hw/net/rtl8139.c
index bc56075c0d..064a73b6b4 100644
--- a/hw/net/rtl8139.c
+++ b/hw/net/rtl8139.c
@@ -3410,7 +3410,7 @@ static void rtl8139_instance_init(Object *obj)
                                   DEVICE(obj));
 }
 
-static Property rtl8139_properties[] = {
+static const Property rtl8139_properties[] = {
     DEFINE_NIC_PROPERTIES(RTL8139State, conf),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/net/smc91c111.c b/hw/net/smc91c111.c
index 180ba5c791..a853c30fa2 100644
--- a/hw/net/smc91c111.c
+++ b/hw/net/smc91c111.c
@@ -788,7 +788,7 @@ static void smc91c111_realize(DeviceState *dev, Error **errp)
     /* ??? Save/restore.  */
 }
 
-static Property smc91c111_properties[] = {
+static const Property smc91c111_properties[] = {
     DEFINE_NIC_PROPERTIES(smc91c111_state, conf),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/net/spapr_llan.c b/hw/net/spapr_llan.c
index 8af33d91b6..d381c041db 100644
--- a/hw/net/spapr_llan.c
+++ b/hw/net/spapr_llan.c
@@ -786,7 +786,7 @@ static target_ulong h_change_logical_lan_mac(PowerPCCPU *cpu,
     return H_SUCCESS;
 }
 
-static Property spapr_vlan_properties[] = {
+static const Property spapr_vlan_properties[] = {
     DEFINE_SPAPR_PROPERTIES(SpaprVioVlan, sdev),
     DEFINE_NIC_PROPERTIES(SpaprVioVlan, nicconf),
     DEFINE_PROP_BIT("use-rx-buffer-pools", SpaprVioVlan,
diff --git a/hw/net/stellaris_enet.c b/hw/net/stellaris_enet.c
index 9ebff296c4..4af1afa733 100644
--- a/hw/net/stellaris_enet.c
+++ b/hw/net/stellaris_enet.c
@@ -497,7 +497,7 @@ static void stellaris_enet_realize(DeviceState *dev, Error **errp)
     qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
 }
 
-static Property stellaris_enet_properties[] = {
+static const Property stellaris_enet_properties[] = {
     DEFINE_NIC_PROPERTIES(stellaris_enet_state, conf),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/net/sungem.c b/hw/net/sungem.c
index 67087e9842..bcc7a18382 100644
--- a/hw/net/sungem.c
+++ b/hw/net/sungem.c
@@ -1420,7 +1420,7 @@ static void sungem_instance_init(Object *obj)
                                   DEVICE(obj));
 }
 
-static Property sungem_properties[] = {
+static const Property sungem_properties[] = {
     DEFINE_NIC_PROPERTIES(SunGEMState, conf),
     /* Phy address should be 0 for most Apple machines except
      * for K2 in which case it's 1. Will be set by a machine
diff --git a/hw/net/sunhme.c b/hw/net/sunhme.c
index 0e6c655a5b..86f472fcbe 100644
--- a/hw/net/sunhme.c
+++ b/hw/net/sunhme.c
@@ -177,7 +177,7 @@ struct SunHMEState {
     uint16_t miiregs[HME_MII_REGS_SIZE];
 };
 
-static Property sunhme_properties[] = {
+static const Property sunhme_properties[] = {
     DEFINE_NIC_PROPERTIES(SunHMEState, conf),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/net/tulip.c b/hw/net/tulip.c
index 9df3e17162..f35b58a88c 100644
--- a/hw/net/tulip.c
+++ b/hw/net/tulip.c
@@ -1007,7 +1007,7 @@ static void tulip_instance_init(Object *obj)
                                   &pci_dev->qdev);
 }
 
-static Property tulip_properties[] = {
+static const Property tulip_properties[] = {
     DEFINE_NIC_PROPERTIES(TULIPState, c),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 6e8c51a2db..4fd1f9acca 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -3985,7 +3985,7 @@ static const VMStateDescription vmstate_virtio_net = {
     .dev_unplug_pending = dev_unplug_pending,
 };
 
-static Property virtio_net_properties[] = {
+static const Property virtio_net_properties[] = {
     DEFINE_PROP_BIT64("csum", VirtIONet, host_features,
                     VIRTIO_NET_F_CSUM, true),
     DEFINE_PROP_BIT64("guest_csum", VirtIONet, host_features,
diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
index 8aa8c46228..f69547cad5 100644
--- a/hw/net/vmxnet3.c
+++ b/hw/net/vmxnet3.c
@@ -2471,7 +2471,7 @@ static const VMStateDescription vmstate_vmxnet3 = {
     }
 };
 
-static Property vmxnet3_properties[] = {
+static const Property vmxnet3_properties[] = {
     DEFINE_NIC_PROPERTIES(VMXNET3State, conf),
     DEFINE_PROP_BIT("x-old-msi-offsets", VMXNET3State, compat_flags,
                     VMXNET3_COMPAT_FLAG_OLD_MSI_OFFSETS_BIT, false),
diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c
index 89487b49ba..5a5259150a 100644
--- a/hw/net/xen_nic.c
+++ b/hw/net/xen_nic.c
@@ -555,7 +555,7 @@ static void xen_netdev_unrealize(XenDevice *xendev)
 
 /* ------------------------------------------------------------- */
 
-static Property xen_netdev_properties[] = {
+static const Property xen_netdev_properties[] = {
     DEFINE_NIC_PROPERTIES(XenNetDev, conf),
     DEFINE_PROP_INT32("idx", XenNetDev, dev, -1),
     DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/net/xgmac.c b/hw/net/xgmac.c
index ffe3fc8dbe..6e0f96f485 100644
--- a/hw/net/xgmac.c
+++ b/hw/net/xgmac.c
@@ -414,7 +414,7 @@ static void xgmac_enet_realize(DeviceState *dev, Error **errp)
                                   s->conf.macaddr.a[0];
 }
 
-static Property xgmac_properties[] = {
+static const Property xgmac_properties[] = {
     DEFINE_NIC_PROPERTIES(XgmacState, conf),
     DEFINE_PROP_END_OF_LIST(),
 };
diff --git a/hw/net/xilinx_axienet.c b/hw/net/xilinx_axienet.c
index faf27947b0..9d0c618e2f 100644
--- a/hw/net/xilinx_axienet.c
+++ b/hw/net/xilinx_axienet.c
@@ -996,7 +996,7 @@ static void xilinx_enet_init(Object *obj)
     sysbus_init_mmio(sbd, &s->iomem);
 }
 
-static Property xilinx_enet_properties[] = {
+static const Property xilinx_enet_properties[] = {
     DEFINE_PROP_UINT32("phyaddr", XilinxAXIEnet, c_phyaddr, 7),
     DEFINE_PROP_UINT32("rxmem", XilinxAXIEnet, c_rxmem, 0x1000),
     DEFINE_PROP_UINT32("txmem", XilinxAXIEnet, c_txmem, 0x1000),
diff --git a/hw/net/xilinx_ethlite.c b/hw/net/xilinx_ethlite.c
index bd81290808..9413731d20 100644
--- a/hw/net/xilinx_ethlite.c
+++ b/hw/net/xilinx_ethlite.c
@@ -251,7 +251,7 @@ static void xilinx_ethlite_init(Object *obj)
     sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->mmio);
 }
 
-static Property xilinx_ethlite_properties[] = {
+static const Property xilinx_ethlite_properties[] = {
     DEFINE_PROP_UINT32("tx-ping-pong", struct xlx_ethlite, c_tx_pingpong, 1),
     DEFINE_PROP_UINT32("rx-ping-pong", struct xlx_ethlite, c_rx_pingpong, 1),
     DEFINE_NIC_PROPERTIES(struct xlx_ethlite, conf),
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 19:30:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 19:30:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857149.1269576 (Exim 4.92)
	(envelope-from )
	id 1tMBNE-0002v6-4t; Fri, 13 Dec 2024 19:30:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857149.1269576; Fri, 13 Dec 2024 19:30:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tMBND-0002uz-Vn; Fri, 13 Dec 2024 19:30:51 +0000
Received: by outflank-mailman (input) for mailman id 857149;
 Fri, 13 Dec 2024 19:30: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 1tMBNC-0002uA-HY
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 19:30:50 +0000
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com
 [2a00:1450:4864:20::12f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c1e559a7-b988-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 20:30:49 +0100 (CET)
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-5401be44b58so2133033e87.0
 for ; Fri, 13 Dec 2024 11:30:49 -0800 (PST)
Received: from stoup.. ([91.209.212.67]) by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-54120c01051sm6972e87.156.2024.12.13.11.30.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 11:30: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: c1e559a7-b988-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1734118249; x=1734723049; 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=G5t5Kfg88Idn9A8sdeK/3C+aA4Q4/f69T01+9FYpo+k=;
        b=dV0MQvqM07waF9qRZdtPAk2OkKBlQl6sfLWkrLfmYsMtdUHriL5r+bPTWDAnEqESAc
         vvPPMyEmJ8I2imbb6bFkovdiEhq2uc9GGjo/TW7HdCpmFWo7FdaXyrNbiX661c9BgF0Z
         P0MnMrhQu3z6I+WaIgpbPvB/9g3mNmB5VyzOCmA+pSLCGcVgzz63oRvhtxYrBFugYF/0
         uEyv/owZvMmze8UC1b4Uj68uI4X0CrIivLp9oaBoBOOmv/IP/blBUl7ZUtHl/gixA7ss
         y/ekH5+jef74IJu4GVt5DJumeXpfq0v0F9BufnvTrMqbvY/0QyJoSYGTbMW47rPDeiw+
         cmiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734118249; x=1734723049;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=G5t5Kfg88Idn9A8sdeK/3C+aA4Q4/f69T01+9FYpo+k=;
        b=OD+o1ahs1Boucl6jUsV+lFPhBtbDlpL6oD9OkoVBtZ7HVp+rOWqxKTyZDRLrQmWy30
         0wCYlnvXggP/toFCWuuwQ9OFr77WEoIyzHf0a0W3OKIg4m6fGbDQOSqep0dKzpYVf+mU
         oEpJRaxsOlex+koc+B23Ny9YAOIzX5xS2E3n93VqNtQa2HUMe7oAo9XKF/qMgT9ACMEY
         BJEqSpMa4BD3GzfHqvjvzy/MC9u3RWC/KF5+4rqpjr9g/7vzRWtZWYQfd4rhOFBAbc50
         OdkLdevASleDLY0KViJka9dsm8O4b/YeUphfdYpebLhkt4DQYGiwXysXc9TAkGgWoYBy
         OT4A==
X-Forwarded-Encrypted: i=1; AJvYcCWGh7ni0Z3MMevRZ+h/BiU2/0MNRBRa+fFOQu42sMAezL0EYhJ8p2W1RTokyuuYhq3vthRKqLLcGdE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzCUNEuNoeolrYFZrkQj54VXkWkNtoWG8SLBOwuz9JuJINHb3IM
	2hgUbWI969tKXnX+Usvk435WHtR8D7FLEoDUV5Fu37zyOHXKAXmf1kSDKeETj+K74j7khnRsBIt
	Wk0A/iIpT
X-Gm-Gg: ASbGncvBNxCqaXCVbGG6is/mVjMr2Hedf1ikBCefgWbAV+fn/8kNCjiqWqILMuzttgU
	OpI63Y3Ir77QeEwuBvEIkeRzYPSUhSxePWCd6YTkIUb3Sfc06UNJlwjNRevtTtYFANpJ2WnQuS2
	szyHxuJWqqDG22LwamjxrPQkVCtY5yjiofotfKY4VMaeMd0eNfVe5k23RT/f2nY2Y+QVHv6AygB
	rINv5GvK8EonMs1GYSCDxbJUHElLZXi7KrCGUCFFjHs+xfNRo9ess2a1JgUJg==
X-Google-Smtp-Source: AGHT+IEVWn8s5zP1MGFumvUQTEQ3ffwofWS3mvrYSU47wD3xL4Ll8IZLZ5/xOoizBV+DtpEb6Tf3yA==
X-Received: by 2002:a05:6512:104d:b0:540:206b:c358 with SMTP id 2adb3069b0e04-5409055826bmr965522e87.20.1734118248733;
        Fri, 13 Dec 2024 11:30:48 -0800 (PST)
From: Richard Henderson 
To: qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org (open list:X86 Xen CPUs)
Subject: [PATCH 69/71] hw/xen: Use DEFINE_PROP_END_OF_LIST in xen_sysdev_properties
Date: Fri, 13 Dec 2024 13:30:03 -0600
Message-ID: <20241213193004.2515684-7-richard.henderson@linaro.org>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213193004.2515684-1-richard.henderson@linaro.org>
References: <20241213190750.2513964-1-richard.henderson@linaro.org>
 <20241213193004.2515684-1-richard.henderson@linaro.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Richard Henderson 
---
 hw/xen/xen-legacy-backend.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c
index b15393e934..f6ad58fe13 100644
--- a/hw/xen/xen-legacy-backend.c
+++ b/hw/xen/xen-legacy-backend.c
@@ -675,7 +675,7 @@ static const TypeInfo xensysbus_info = {
 };
 
 static const Property xen_sysdev_properties[] = {
-    {/* end of property list */},
+    DEFINE_PROP_END_OF_LIST(),
 };
 
 static void xen_sysdev_class_init(ObjectClass *klass, void *data)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 19:30:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 19:30:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857148.1269565 (Exim 4.92)
	(envelope-from )
	id 1tMBN9-0002eL-PL; Fri, 13 Dec 2024 19:30:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857148.1269565; Fri, 13 Dec 2024 19:30:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tMBN9-0002eE-LG; Fri, 13 Dec 2024 19:30:47 +0000
Received: by outflank-mailman (input) for mailman id 857148;
 Fri, 13 Dec 2024 19:30: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 1tMBN8-0002e8-Gr
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 19:30:46 +0000
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com
 [2a00:1450:4864:20::12f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bee7d81c-b988-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 20:30:44 +0100 (CET)
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-53df6322ea7so2982485e87.0
 for ; Fri, 13 Dec 2024 11:30:44 -0800 (PST)
Received: from stoup.. ([91.209.212.67]) by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-54120c01051sm6972e87.156.2024.12.13.11.30.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Dec 2024 11:30: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: bee7d81c-b988-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1734118244; x=1734723044; 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=Ks6G+A84FfZ3IMwYe7rtmCGNogRG46Y1v4JaJo0a9Is=;
        b=S+PZ3DHfsJ0S9wjWF0R8cacakxTf31oZVROvgLOyb2MHSO5N0+OHgBalb/5/Hfq+SS
         VIRFd8lwme4lMOX1E6SDa639d0aFK6jGCgMtvxKnoFlDAXAMz4l7KiYV23SQr+eDh7BG
         BAX90NAiVsltKhOP47SQ10OHIeIyhGnqYS1/5R7T36RPERwkOCIhZ6/TrcyEVVsgBiaD
         AvRPy51pzOocKVhMRGgg0hkX4XbDmIXt704Se+LWYWMhrhSgyuG8PDHnWhiMxTvVd/E+
         85VN4zmQatP8A3Pcz1msQluaalA7WxMq5EfVHPTwA8YuhzdldmSc1rG5EuGfHx2t4cqG
         LoEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734118244; x=1734723044;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Ks6G+A84FfZ3IMwYe7rtmCGNogRG46Y1v4JaJo0a9Is=;
        b=FdCUFeiCki8FIAW6XiDsXKDI4g5b3mvaMUaBDmPZQ5R6Rki41tEhWbrU8un5u1hmj/
         7Ht0sJe1CzLWJJ9fS/nNNXvAbLqXT86S5GWRD8c33Sgh2EfTpFFVrXE8blu/LWB18BX2
         wwk05GOlrO7VTeQghkSZSDKlSFNx6F+0cdyhjP+f+LAKQ4W7u0PAmivi8ozmHHIj7SFk
         zWgJgvpoc8nxFqqqW3JDNGgjrAqjHYJx4FJymIL+/aWaIIpLepPYwyhwC5uBiczSukH1
         3/Zok734e6p0ZJDMTpKG6XwEJxfxKpqvGz1h50ui+uPmhHgo1f4yLGscC6Ra3u2OL+LJ
         OyQA==
X-Forwarded-Encrypted: i=1; AJvYcCXlKqZF0K4zRvDyw6rf+d0XBnmd0KnV19cfI1KmM1lvIpiweg6XzhsZqcNT7CYFU62kwRcVlvzYm3Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzdYwSUKgSwS8ncVeenWICLm0PiEIQyMhWerRZ8z3LzghJp3arv
	DhOv5LKtDso86UcKvAxIhEP65Dq8L3TbfffJFWvtCUTkCtBJOTU9GC+zWsw5/sw=
X-Gm-Gg: ASbGncuRYIZ/gSdPmnZYPOMR2YS0zYDoTjisBgCesjispW05yrwjiKhkpu9CJbL+IVA
	9pokZbsP8jIGIWx8j115iNOiyA4x/NwK33VemfQbtqBzcQUsIHuScAS46FBqkjRzMPSJPstFg6X
	0C1/DiBnBaQAvlfGwN29CAx9u7hQpD0SO1k0P9/G3i5BV1iPvQEH/c7E/yVwWvowoLSMfSePb84
	tK7LYM0KxK44CpIwtMzX0k7lUbDOOFmGe9Ig1aVGSOb5RTRnQu8cor6Zbwd6A==
X-Google-Smtp-Source: AGHT+IFGZJIZIUb5LjrLjVc0WvQwaJBK5eY0K7njVad3ONjLROwm4SnNIJX99T953BtT5rEvxmgCfA==
X-Received: by 2002:a05:6512:3e07:b0:53e:2fdb:4de3 with SMTP id 2adb3069b0e04-540905955ccmr1343488e87.44.1734118243635;
        Fri, 13 Dec 2024 11:30:43 -0800 (PST)
From: Richard Henderson 
To: qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Anthony PERARD ,
	Paul Durrant ,
	"Edgar E. Iglesias" ,
	xen-devel@lists.xenproject.org (open list:X86 Xen CPUs)
Subject: [PATCH 68/71] hw/xen: Constify all Property
Date: Fri, 13 Dec 2024 13:30:02 -0600
Message-ID: <20241213193004.2515684-6-richard.henderson@linaro.org>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241213193004.2515684-1-richard.henderson@linaro.org>
References: <20241213190750.2513964-1-richard.henderson@linaro.org>
 <20241213193004.2515684-1-richard.henderson@linaro.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Richard Henderson 
---
 hw/xen/xen-bus.c            | 2 +-
 hw/xen/xen-legacy-backend.c | 4 ++--
 hw/xen/xen_pt.c             | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index 95b207ac8b..0d7defb8cd 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -1092,7 +1092,7 @@ unrealize:
     xen_device_unrealize(dev);
 }
 
-static Property xen_device_props[] = {
+static const Property xen_device_props[] = {
     DEFINE_PROP_UINT16("frontend-id", XenDevice, frontend_id,
                        DOMID_INVALID),
     DEFINE_PROP_END_OF_LIST()
diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c
index e8e1ee4f7d..b15393e934 100644
--- a/hw/xen/xen-legacy-backend.c
+++ b/hw/xen/xen-legacy-backend.c
@@ -635,7 +635,7 @@ int xen_be_bind_evtchn(struct XenLegacyDevice *xendev)
 }
 
 
-static Property xendev_properties[] = {
+static const Property xendev_properties[] = {
     DEFINE_PROP_END_OF_LIST(),
 };
 
@@ -674,7 +674,7 @@ static const TypeInfo xensysbus_info = {
     }
 };
 
-static Property xen_sysdev_properties[] = {
+static const Property xen_sysdev_properties[] = {
     {/* end of property list */},
 };
 
diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index 3635d1b39f..557aa98be4 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -931,7 +931,7 @@ static void xen_pt_unregister_device(PCIDevice *d)
     xen_pt_destroy(d);
 }
 
-static Property xen_pci_passthrough_properties[] = {
+static const Property xen_pci_passthrough_properties[] = {
     DEFINE_PROP_PCI_HOST_DEVADDR("hostaddr", XenPCIPassthroughState, hostaddr),
     DEFINE_PROP_BOOL("permissive", XenPCIPassthroughState, permissive, false),
     DEFINE_PROP_END_OF_LIST(),
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 20:45:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 20:45:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857182.1269588 (Exim 4.92)
	(envelope-from )
	id 1tMCXe-0005GY-98; Fri, 13 Dec 2024 20:45:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857182.1269588; Fri, 13 Dec 2024 20:45: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 1tMCXe-0005GR-5y; Fri, 13 Dec 2024 20:45:42 +0000
Received: by outflank-mailman (input) for mailman id 857182;
 Fri, 13 Dec 2024 20:45: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 1tMCXc-0005GL-Ro
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 20:45:40 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 34e6012a-b993-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 21:45:38 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 0382C5C5FE0;
 Fri, 13 Dec 2024 20:44:54 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0DDA2C4CED6;
 Fri, 13 Dec 2024 20:45:34 +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: 34e6012a-b993-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1734122735;
	bh=dByUPsNZ25l6EpZmsuACLXZwiypAYy/TalLHbnBsEN4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=s15HAtgSJE2fkZtO+bXT6grgvWDG8an93nICmDwIj6Qanl2FD8tUmXnYimHYQM9J5
	 JRszlxpCeJXFyDPKYaXHdaD5e4JdO/8AHD6WoMabrUFpEWs2Lke5vtR7r49cCQuE4m
	 xTGoTw8BixTf7XxuqimXiipvW5bcRs+EOWGcGB9gDUUDWCSRlSwvZkZ9J7zVqXEt6Y
	 yNqSAb98ZetGAnZ6pSOwrvuiFkcmBBMPJ4wtbr7rEigcUvZbqZM8iE9KA0ZudR/KJn
	 Ss0nN6p1F3tcbY8P9RQexEkbpWZ6cN5q+bAyWbBwpwj3KpPJZtGtpxuZwhILuVH/lx
	 YkSoNgm2sFRMw==
Date: Fri, 13 Dec 2024 12:45:34 -0800 (PST)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, 
    Andrew Cooper , Jan Beulich , 
    Julien Grall , Stefano Stabellini 
Subject: Re: [PATCH v2 33/35] x86/domain: implement domain_has_vuart()
In-Reply-To: 
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com> <20241205-vuart-ns8250-v1-33-e9aa923127eb@ford.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-108919309-1734122502=:463523"
Content-ID: 

  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-108919309-1734122502=:463523
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: 8BIT
Content-ID: 

On Fri, 13 Dec 2024, Roger Pau Monné wrote:
> On Thu, Dec 05, 2024 at 08:42:03PM -0800, Denis Mukhin via B4 Relay wrote:
> > From: Denis Mukhin 
> > 
> > Add new emulation flag for virtual UART on x86 and plumb it through the stack.
> > 
> > This change enables NS8250 emulator initialization.
> > 
> > Signed-off-by: Denis Mukhin 
> > ---
> >  tools/libs/light/libxl_x86.c      |  6 +++++-
> >  tools/ocaml/libs/xc/xenctrl.ml    |  1 +
> >  tools/ocaml/libs/xc/xenctrl.mli   |  1 +
> >  tools/python/xen/lowlevel/xc/xc.c |  4 +---
> >  xen/arch/x86/domain.c             |  8 +++++---
> >  xen/arch/x86/include/asm/domain.h |  7 ++++---
> >  xen/include/public/arch-x86/xen.h | 14 +++++++++++++-
> >  7 files changed, 30 insertions(+), 11 deletions(-)
> > 
> > diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c
> > index a3164a3077fec7e1b81a34074894dc646954a49a..de5f05e18cb0671bb031b101b9a7159eb0fe0178 100644
> > --- a/tools/libs/light/libxl_x86.c
> > +++ b/tools/libs/light/libxl_x86.c
> > @@ -8,7 +8,11 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
> >  {
> >      switch(d_config->c_info.type) {
> >      case LIBXL_DOMAIN_TYPE_HVM:
> > -        config->arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
> > +        config->arch.emulation_flags = XEN_X86_EMU_ALL;
> > +        config->arch.emulation_flags &= ~XEN_X86_EMU_VPCI;
> > +        /* Virtual UART is selected at Xen build time */
> > +        config->arch.emulation_flags &= ~XEN_X86_EMU_VUART;
> > +
> >          if (!libxl_defbool_val(d_config->b_info.u.hvm.pirq))
> >              config->arch.emulation_flags &= ~XEN_X86_EMU_USE_PIRQ;
> >          break;
> > diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
> > index 2690f9a92316b812ad3d3ff0e1c36823070adb4a..647239b3e55e88b00eb8e9773a5267894cbbae54 100644
> > --- a/tools/ocaml/libs/xc/xenctrl.ml
> > +++ b/tools/ocaml/libs/xc/xenctrl.ml
> > @@ -47,6 +47,7 @@ type x86_arch_emulation_flags =
> >    | X86_EMU_PIT
> >    | X86_EMU_USE_PIRQ
> >    | X86_EMU_VPCI
> > +  | X86_EMU_VUART
> >  
> >  type x86_arch_misc_flags =
> >    | X86_MSR_RELAXED
> > diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
> > index febbe1f6ae3f10c5abe45eaa3c06a8a67d9ba268..4f5f64c786e83e8a0c3dd3cdb0460f7095de4a62 100644
> > --- a/tools/ocaml/libs/xc/xenctrl.mli
> > +++ b/tools/ocaml/libs/xc/xenctrl.mli
> > @@ -41,6 +41,7 @@ type x86_arch_emulation_flags =
> >    | X86_EMU_PIT
> >    | X86_EMU_USE_PIRQ
> >    | X86_EMU_VPCI
> > +  | X86_EMU_VUART
> >  
> >  type x86_arch_misc_flags =
> >    | X86_MSR_RELAXED
> > diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
> > index 9feb12ae2b16e48cb5d0c3c45044ae226f152f2d..e54308956efc7061d58d2166ec9a95bc1dcd1781 100644
> > --- a/tools/python/xen/lowlevel/xc/xc.c
> > +++ b/tools/python/xen/lowlevel/xc/xc.c
> > @@ -159,9 +159,7 @@ static PyObject *pyxc_domain_create(XcObject *self,
> >  
> >  #if defined (__i386) || defined(__x86_64__)
> >      if ( config.flags & XEN_DOMCTL_CDF_hvm )
> > -        config.arch.emulation_flags = XEN_X86_EMU_ALL &
> > -                                      ~(XEN_X86_EMU_VPCI |
> > -                                        XEN_X86_EMU_USE_PIRQ);
> > +        config.arch.emulation_flags = XEN_X86_EMU_HVM_ALLOWABLE;
> >  #elif defined (__arm__) || defined(__aarch64__)
> >      config.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
> >  #else
> > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > index c88d422a64544531c1e1058fa484364bb4277d1e..439da7adc92a3a8eb481075bf834da5f9670dd54 100644
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -752,10 +752,10 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
> >          if ( is_hardware_domain(d) &&
> >               emflags != (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) )
> >              return false;
> > +
> > +        emflags &= ~X86_EMU_VUART;
> 
> I think you want to allow X86_EMU_VUART only for domains created by
> Xen itself, so X86_EMU_VUART can only be valid if system_state <
> SYS_STATE_active.
> 
> >          if ( !is_hardware_domain(d) &&
> > -             /* HVM PIRQ feature is user-selectable. */
> > -             (emflags & ~X86_EMU_USE_PIRQ) !=
> > -             (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
> > +             xen_emflags_allowable(emflags) != XEN_X86_EMU_HVM_ALLOWABLE &&
> >               emflags != X86_EMU_LAPIC )
> >              return false;
> >      }
> > @@ -806,6 +806,8 @@ int arch_domain_create(struct domain *d,
> >  
> >      emflags = config->arch.emulation_flags;
> >  
> > +    if ( IS_ENABLED(CONFIG_HAS_VUART_NS8250) && is_hvm_domain(d) )
> > +        emflags |= XEN_X86_EMU_VUART;
> 
> Doesn't this need to be limited to domains created by Xen itself, as
> otherwise it's the toolstack that should specify the XEN_X86_EMU_VUART
> flag, and even then the recommendation would be to use the vUART from
> QEMU?

While I agree with you that this feature is really useful mostly for the
domains created by Xen, as for those there is no other way to get early
output, I think Denis has been also testing successfully this feature
with PVH or HVM domains created by the toolstack.

I'll let you decide whether you want to expose the feature to xl created
domains, but yes my understanding is that they already work with this
series. One benefit would be that for PVH domains you could get early
output without having to start QEMU, but I'll leave this to you.
--8323329-108919309-1734122502=:463523--


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 21:35:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 21:35:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857193.1269597 (Exim 4.92)
	(envelope-from )
	id 1tMDJI-0003en-JD; Fri, 13 Dec 2024 21:34:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857193.1269597; Fri, 13 Dec 2024 21:34: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 1tMDJI-0003eg-GM; Fri, 13 Dec 2024 21:34:56 +0000
Received: by outflank-mailman (input) for mailman id 857193;
 Fri, 13 Dec 2024 21:34: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 1tMDJG-0003ea-VT
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 21:34:54 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 169ccd71-b99a-11ef-a0d6-8be0dac302b0;
 Fri, 13 Dec 2024 22:34:53 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 1E3CDA42BC4;
 Fri, 13 Dec 2024 21:33:01 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7AE70C4CED0;
 Fri, 13 Dec 2024 21:34: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: 169ccd71-b99a-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1734125691;
	bh=bzH9Xlq+uoBZJSvZGQeh0yCm/oAUi02hbLgUI/NrzBA=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=olYnqEKURYkgoPE2XKK3YzR9CC2/fOcCXnW2ZwFh6B5bmXhXCgMArWsqNG/sSnKUE
	 ldOEj6++asxdCtYZctdecmjtvZT/W/MQUFkFhHag0SNq05Ik3UnXbC//OVOKWhtQTa
	 0PlCyTMmkvbJ5C/QBkstzA/XxR6FLiehU1Xgp2vToQ786V47HkB3lzq9z/xFPMQBRv
	 bwJQKoL/ec11KaHQRbf2CJid1mHQen11OIIWdgo6dUQkWHhqIxW1TdvymaYTWqpmzV
	 wNo16DOBumjU2akHOieWl51K+1i258Gwsi0oMW2Fqn6cU8sqHmpit/T1rWs99f1zmT
	 KTB/DRY9Dp26w==
Date: Fri, 13 Dec 2024 13:34:49 -0800 (PST)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Alessandro Zucchelli 
cc: Jan Beulich , 
    Stefano Stabellini , consulting@bugseng.com, 
    Julien Grall , Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen: address violation of MISRA C Rule 11.1
In-Reply-To: <1ddb5bd7e8889da0e978bb1391072925@bugseng.com>
Message-ID: 
References: <7debd63f3900bad62bcbcc03081e4c04e6099135.1733914487.git.alessandro.zucchelli@bugseng.com>   <26600bb0-93af-45b5-a341-5771bad844a1@suse.com>
   <1ddb5bd7e8889da0e978bb1391072925@bugseng.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 13 Dec 2024, Alessandro Zucchelli wrote:
> On 2024-12-13 11:08, Jan Beulich wrote:
> > On 13.12.2024 01:53, Stefano Stabellini wrote:
> > > On Thu, 12 Dec 2024, Jan Beulich wrote:
> > > > On 12.12.2024 03:27, Stefano Stabellini wrote:
> > > > > On Wed, 11 Dec 2024, Jan Beulich wrote:
> > > > > > On 11.12.2024 12:02, Alessandro Zucchelli wrote:
> > > > > > > Rule 11.1 states as following: "Conversions shall not be performed
> > > > > > > between a pointer to a function and any other type".
> > > > > > > 
> > > > > > > Functions "__machine_restart" and "__machine_halt" in
> > > > > > > "x86/shutdown.c"
> > > > > > > and "halt_this_cpu" in "arm/shutdown.c" are defined as noreturn
> > > > > > > functions and subsequently passed as parameters to function calls.
> > > > > > > This violates the rule in Clang, where the "noreturn" attribute is
> > > > > > > considered part of the function"s type.
> > > > > > 
> > > > > > I'm unaware of build issues with Clang, hence can you clarify how
> > > > > > Clang's
> > > > > > view comes into play here? In principle various attributes ought to
> > > > > > be
> > > > > > part of a function's type; iirc that's also the case for gcc. Yet
> > > > > > how
> > > > > > that matters to Eclair is still entirely unclear to me.
> > > > > > 
> > > > > > > By removing the "noreturn"
> > > > > > > attribbute and replacing it with uses of the ASSERT_UNREACHABLE
> > > > > > > macro,
> > > > > > > these violations are addressed.
> > > > > > 
> > > > > > Papered over, I'd say. What about release builds, for example?
> > > > > > 
> > > > > > Deleting the attribute also has a clear downside documentation-wise.
> > > > > > If
> > > > > > we really mean to remove them from what the compiler gets to see, I
> > > > > > think
> > > > > > we ought to still retain them in commented-out shape.
> > > > > 
> > > > > Another option would be to #define noreturn to nothing for ECLAIR
> > > > > builds ?
> > > > 
> > > > That again would feel like papering over things. Plus I don't know if
> > > > that's
> > > > an option at all.
> > > 
> > > What is "papering over" and what is a "nice solution" is often up to the
> > > personal opinions.
> > > 
> > > From my point of view, Alessandro's patch doesn't make the code worse.
> > > The ASSERT_UNREACHABLE solution is OK. I do agree with you that it
> > > should not be required for us to remove "noreturn", but I don't think we
> > > have used it consistently anyway across the Xen codebase.
> > > ASSERT_UNREACHABLE is also a form of documentation that the function
> > > does not return.
> > > 
> > > In conclusion, I think all three options are acceptable:
> > > 1) this patch as is
> > > 2) this patch plus /* noreturn */ as a comment
> > > 3) #define noreturn to nothing just for ECLAIR builds
> > > 
> > > I don't mind either way, maybe option 2) is the best compromise.
> > 
> > The variant with least impact on what we currently have (generated code
> > wise) is 3), though, which hence would be my preference (well, not exactly
> > a preference, but the least bad one).
> 
> Another option could be to encapsulate these function pointer casts as
> follows:
> #define REMOVE_NORETURN(x) (void(*)(void*))(x)
> This approach allows us to retain the noreturn attribute and the associated
> optimizations;
> note that the encapsulating macro will need to be deviated then.

I think that's OK.


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 22:06:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 22:06:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857209.1269608 (Exim 4.92)
	(envelope-from )
	id 1tMDnr-0007eG-SO; Fri, 13 Dec 2024 22:06:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857209.1269608; Fri, 13 Dec 2024 22:06:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tMDnr-0007e9-PX; Fri, 13 Dec 2024 22:06:31 +0000
Received: by outflank-mailman (input) for mailman id 857209;
 Fri, 13 Dec 2024 22:06: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 1tMDnq-0007e3-O5
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 22:06:30 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8041914e-b99e-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 23:06:28 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 4122BA42B9E;
 Fri, 13 Dec 2024 22:04:36 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 85D0CC4CED0;
 Fri, 13 Dec 2024 22:06:25 +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: 8041914e-b99e-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1734127587;
	bh=hb1EkTP7mixqMTEK5Esj+vsGJHqJpdVrO6M2ZUpL/ZY=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=tAqAPp79TdO8eKtRRoVU1eqPAqY4HFhtyfu+Rid4hAEMStaRB6ZuNyK14nsyyxQJ7
	 YItdXnpD+BehTBCTQQ/O12femuX9erPZ2PgIOBff5ZdisVKZlLdapasKG158bJmXcV
	 99ya29bPVt8qOPgfc1TmanTkknvBRR+d6lDWbGW5LEzqJrsZBhRAMdhbZHrv2oDhI0
	 B5oyR95VWxGS6t2IgVeywWJKNkeSbs4kKcCun/vdEsQO9nQI/DolMLF1959A0kO3p5
	 Bmp2WQga5JqbrB0h5pmDMQ2xXaoWhu32Ke5qmKa7Ko2u2UCwsLNTTr9ZgajmUOVnVZ
	 m7gShsMs1tfJw==
Date: Fri, 13 Dec 2024 14:06:24 -0800 (PST)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Mykyta Poturai 
cc: "xen-devel@lists.xenproject.org" , 
    Oleksandr Andrushchenko , 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    Anthony PERARD , 
    Jan Beulich , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH 1/2] ARM: ITS: implement quirks and add support for
 Renesas Gen4 ITS
In-Reply-To: <2ea26be2689585ea254a9c0177816722bcb2db8d.1734096752.git.mykyta_poturai@epam.com>
Message-ID: 
References:  <2ea26be2689585ea254a9c0177816722bcb2db8d.1734096752.git.mykyta_poturai@epam.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 13 Dec 2024, Mykyta Poturai wrote:
> From: Oleksandr Andrushchenko 
> 
> There are number of ITS implementations exist which are different from
> the base one which have number of functionalities defined as is
> "IMPLEMENTATION DEFINED", e.g. there may exist differences in cacheability,
> shareability and memory requirements and others. This requires
> appropriate handling of such HW requirements which are implemented as
> ITS quirks: GITS_IIDR (ITS Implementer Identification Register) is used to
> differentiate the ITS implementations and select appropriate set of
> quirks if any.
> 
> As an example of such ITSes add quirk implementation for Renesas Gen4 ITS:
> - add possibility to override default cacheability and shareability
> settings used for ITS memory allocations;
> - add possibility to allocate memory used by ITS with specific memory
> requirements: introduce _x{z|m}alloc_whole_pages functions and free the
> memory with xfree as usual.
> 
> The idea of the quirk implementation is inspired by the Linux kernel ITS
> quirk implementation [1].
> 
> Signed-off-by: Oleksandr Andrushchenko 
> Signed-off-by: Mykyta Poturai 
> 
> [1] https://elixir.bootlin.com/linux/v5.16.1/source/drivers/irqchip/irq-gic-v3-its.c
> ---
>  xen/arch/arm/gic-v3-its.c             | 90 ++++++++++++++++++++++++---
>  xen/arch/arm/gic-v3-lpi.c             | 14 +++--
>  xen/arch/arm/include/asm/gic_v3_its.h |  8 +++
>  xen/arch/arm/vgic-v3-its.c            |  8 +--
>  xen/common/xmalloc_tlsf.c             | 18 +++++-
>  xen/include/xen/xmalloc.h             |  4 ++
>  6 files changed, 122 insertions(+), 20 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index 5fd83af25a..b1a2cdccc5 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -50,6 +50,77 @@ struct its_device {
>      struct pending_irq *pend_irqs;      /* One struct per event */
>  };
>  
> +/*
> + * It is unlikely that a platform implements ITSes with different quirks,
> + * so assume they all share the same.
> + */
> +struct its_quirk {
> +    const char *desc;
> +    bool (*init)(struct host_its *hw_its);
> +    uint32_t iidr;
> +    uint32_t mask;
> +};
> +
> +uint32_t its_quirk_flags;

static


> +static bool gicv3_its_enable_quirk_gen4(struct host_its *hw_its)
> +{
> +    its_quirk_flags |= HOST_ITS_WORKAROUND_NC_NS |
> +        HOST_ITS_WORKAROUND_32BIT_ADDR;
> +
> +    return true;
> +}
> +
> +static const struct its_quirk its_quirks[] = {
> +    {
> +        .desc	= "R-Car Gen4",
> +        .iidr	= 0x0201743b,
> +        .mask	= 0xffffffff,
> +        .init	= gicv3_its_enable_quirk_gen4,
> +    },
> +    {
> +        /* Sentinel. */
> +    }
> +};
> +
> +static void gicv3_its_enable_quirks(struct host_its *hw_its)
> +{
> +    const struct its_quirk *quirks = its_quirks;
> +    uint32_t iidr = readl_relaxed(hw_its->its_base + GITS_IIDR);
> +
> +    for ( ; quirks->desc; quirks++ )
> +    {
> +        if ( quirks->iidr != (quirks->mask & iidr) )
> +            continue;
> +        if ( quirks->init(hw_its) )
> +            printk("GICv3: enabling workaround for ITS: %s\n", quirks->desc);
> +    }
> +}
> +
> +uint64_t gicv3_its_get_cacheability(void)
> +{
> +    if ( its_quirk_flags & HOST_ITS_WORKAROUND_NC_NS )
> +        return GIC_BASER_CACHE_nC;
> +
> +    return GIC_BASER_CACHE_RaWaWb;
> +}
> +
> +uint64_t gicv3_its_get_shareability(void)
> +{
> +    if ( its_quirk_flags & HOST_ITS_WORKAROUND_NC_NS )
> +        return GIC_BASER_NonShareable;
> +
> +    return GIC_BASER_InnerShareable;
> +}
> +
> +unsigned int gicv3_its_get_memflags(void)
> +{
> +    if ( its_quirk_flags & HOST_ITS_WORKAROUND_32BIT_ADDR )
> +        return MEMF_bits(32);
> +
> +    return 0;
> +}
> +
>  bool gicv3_its_host_has_its(void)
>  {
>      return !list_empty(&host_its_list);
> @@ -291,11 +362,12 @@ static void *its_map_cbaser(struct host_its *its)
>      uint64_t reg;
>      void *buffer;
>  
> -    reg  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
> +    reg  = gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHIFT;
>      reg |= GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY_SHIFT;
> -    reg |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
> +    reg |= gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILITY_SHIFT;
>  
> -    buffer = _xzalloc(ITS_CMD_QUEUE_SZ, SZ_64K);
> +    buffer = _xzalloc_whole_pages(ITS_CMD_QUEUE_SZ, SZ_64K,
> +                                  gicv3_its_get_memflags());
>      if ( !buffer )
>          return NULL;
>  
> @@ -342,9 +414,9 @@ static int its_map_baser(void __iomem *basereg, uint64_t regc,
>      unsigned int table_size;
>      void *buffer;
>  
> -    attr  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
> +    attr  = gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHIFT;
>      attr |= GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY_SHIFT;
> -    attr |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
> +    attr |= gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILITY_SHIFT;
>  
>      /*
>       * Setup the BASE register with the attributes that we like. Then read
> @@ -357,7 +429,8 @@ retry:
>      /* The BASE registers support at most 256 pages. */
>      table_size = min(table_size, 256U << BASER_PAGE_BITS(pagesz));
>  
> -    buffer = _xzalloc(table_size, BIT(BASER_PAGE_BITS(pagesz), UL));
> +    buffer = _xzalloc_whole_pages(table_size, BIT(BASER_PAGE_BITS(pagesz), UL),
> +                                  gicv3_its_get_memflags());
>      if ( !buffer )
>          return -ENOMEM;
>  
> @@ -453,6 +526,8 @@ static int gicv3_its_init_single_its(struct host_its *hw_its)
>      if ( ret )
>          return ret;
>  
> +    gicv3_its_enable_quirks(hw_its);

We have an issue here because gicv3_its_enable_quirks is called for
every ITS in the system, setting its_quirk_flags as appropriate, but
there is only one its_quirk_flags.

In the unlikely case of multiple ITSes, this wouldn't work.

One option is to call gicv3_its_enable_quirks only for the first ITS and
assume the others are the same (ideally we would check and BUG_ON if it
is not the case). Another option is to have one its_quirk_flags per ITS.


>      reg = readq_relaxed(hw_its->its_base + GITS_TYPER);
>      hw_its->devid_bits = GITS_TYPER_DEVICE_ID_BITS(reg);
>      hw_its->evid_bits = GITS_TYPER_EVENT_ID_BITS(reg);
> @@ -681,7 +756,8 @@ int gicv3_its_map_guest_device(struct domain *d,
>      ret = -ENOMEM;
>  
>      /* An Interrupt Translation Table needs to be 256-byte aligned. */
> -    itt_addr = _xzalloc(nr_events * hw_its->itte_size, 256);
> +    itt_addr = _xzalloc_whole_pages(nr_events * hw_its->itte_size, 256,
> +                                    gicv3_its_get_memflags());
>      if ( !itt_addr )
>          goto out_unlock;
>  
> diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
> index de4b0eb4a4..72b725a624 100644
> --- a/xen/arch/arm/gic-v3-lpi.c
> +++ b/xen/arch/arm/gic-v3-lpi.c
> @@ -237,7 +237,8 @@ static int gicv3_lpi_allocate_pendtable(unsigned int cpu)
>       * The GICv3 imposes a 64KB alignment requirement, also requires
>       * physically contiguous memory.
>       */
> -    pendtable = _xzalloc(lpi_data.max_host_lpi_ids / 8, SZ_64K);
> +    pendtable = _xmalloc_whole_pages(lpi_data.max_host_lpi_ids / 8, SZ_64K,
> +                                     gicv3_its_get_memflags());
>      if ( !pendtable )
>          return -ENOMEM;
>  
> @@ -272,9 +273,9 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdist_base)
>  
>      ASSERT(!(virt_to_maddr(pendtable) & ~GENMASK(51, 16)));
>  
> -    val  = GIC_BASER_CACHE_RaWaWb << GICR_PENDBASER_INNER_CACHEABILITY_SHIFT;
> +    val  = gicv3_its_get_cacheability() << GICR_PENDBASER_INNER_CACHEABILITY_SHIFT;
>      val |= GIC_BASER_CACHE_SameAsInner << GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT;
> -    val |= GIC_BASER_InnerShareable << GICR_PENDBASER_SHAREABILITY_SHIFT;
> +    val |= gicv3_its_get_shareability() << GICR_PENDBASER_SHAREABILITY_SHIFT;
>      val |= GICR_PENDBASER_PTZ;
>      val |= virt_to_maddr(pendtable);
>  
> @@ -301,9 +302,9 @@ static int gicv3_lpi_set_proptable(void __iomem * rdist_base)
>  {
>      uint64_t reg;
>  
> -    reg  = GIC_BASER_CACHE_RaWaWb << GICR_PROPBASER_INNER_CACHEABILITY_SHIFT;
> +    reg  = gicv3_its_get_cacheability() << GICR_PROPBASER_INNER_CACHEABILITY_SHIFT;
>      reg |= GIC_BASER_CACHE_SameAsInner << GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT;
> -    reg |= GIC_BASER_InnerShareable << GICR_PROPBASER_SHAREABILITY_SHIFT;
> +    reg |= gicv3_its_get_shareability() << GICR_PROPBASER_SHAREABILITY_SHIFT;
>  
>      /*
>       * The property table is shared across all redistributors, so allocate
> @@ -312,7 +313,8 @@ static int gicv3_lpi_set_proptable(void __iomem * rdist_base)
>      if ( !lpi_data.lpi_property )
>      {
>          /* The property table holds one byte per LPI. */
> -        void *table = _xmalloc(lpi_data.max_host_lpi_ids, SZ_4K);
> +        void *table = _xmalloc_whole_pages(lpi_data.max_host_lpi_ids, SZ_4K,
> +                                           gicv3_its_get_memflags());
>  
>          if ( !table )
>              return -ENOMEM;
> diff --git a/xen/arch/arm/include/asm/gic_v3_its.h b/xen/arch/arm/include/asm/gic_v3_its.h
> index c24d4752d0..0737e67aa6 100644
> --- a/xen/arch/arm/include/asm/gic_v3_its.h
> +++ b/xen/arch/arm/include/asm/gic_v3_its.h
> @@ -110,6 +110,9 @@
>  #define HOST_ITS_FLUSH_CMD_QUEUE        (1U << 0)
>  #define HOST_ITS_USES_PTA               (1U << 1)
>  
> +#define HOST_ITS_WORKAROUND_NC_NS       (1U << 0)
> +#define HOST_ITS_WORKAROUND_32BIT_ADDR  (1U << 1)
> +
>  /* We allocate LPIs on the hosts in chunks of 32 to reduce handling overhead. */
>  #define LPI_BLOCK                       32U
>  
> @@ -197,6 +200,11 @@ struct pending_irq *gicv3_assign_guest_event(struct domain *d,
>  void gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id,
>                                   uint32_t virt_lpi);
>  
> +/* ITS quirks handling. */
> +uint64_t gicv3_its_get_cacheability(void);
> +uint64_t gicv3_its_get_shareability(void);
> +unsigned int gicv3_its_get_memflags(void);
> +
>  #else
>  
>  #ifdef CONFIG_ACPI
> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
> index c65c1dbf52..f5deb18497 100644
> --- a/xen/arch/arm/vgic-v3-its.c
> +++ b/xen/arch/arm/vgic-v3-its.c
> @@ -1191,7 +1191,7 @@ static void sanitize_its_base_reg(uint64_t *reg)
>      {
>      case GIC_BASER_OuterShareable:
>          r &= ~GITS_BASER_SHAREABILITY_MASK;
> -        r |= GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
> +        r |= gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHIFT;
>          break;
>      default:
>          break;
> @@ -1203,7 +1203,7 @@ static void sanitize_its_base_reg(uint64_t *reg)
>      case GIC_BASER_CACHE_nCnB:
>      case GIC_BASER_CACHE_nC:
>          r &= ~GITS_BASER_INNER_CACHEABILITY_MASK;
> -        r |= GIC_BASER_CACHE_RaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
> +        r |= gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILITY_SHIFT;

gicv3_its_get_cacheability returns GIC_BASER_CACHE_RaWaWb, because that
is the value that was previously present in all the other cases. In this
case, however, we end up replacing GIC_BASER_CACHE_RaWb with
GIC_BASER_CACHE_RaWaWb. Is that OK? 


>          break;
>      default:
>          break;
> @@ -1455,9 +1455,9 @@ static int vgic_v3_its_init_virtual(struct domain *d, paddr_t guest_addr,
>      if ( !its )
>          return -ENOMEM;
>  
> -    base_attr  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
> +    base_attr  = gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHIFT;
>      base_attr |= GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY_SHIFT;
> -    base_attr |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
> +    base_attr |= gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILITY_SHIFT;
>  
>      its->cbaser  = base_attr;
>      base_attr |= 0ULL << GITS_BASER_PAGE_SIZE_SHIFT;    /* 4K pages */
> diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
> index 5e55fc463e..f7f00db044 100644
> --- a/xen/common/xmalloc_tlsf.c
> +++ b/xen/common/xmalloc_tlsf.c
> @@ -537,14 +537,15 @@ static void cf_check xmalloc_pool_put(void *p)
>      free_xenheap_page(p);
>  }
>  
> -static void *xmalloc_whole_pages(unsigned long size, unsigned long align)
> +void *_xmalloc_whole_pages(unsigned long size, unsigned long align,
> +                           unsigned int memflags)
>  {
>      unsigned int i, order;
>      void *res, *p;
>  
>      order = get_order_from_bytes(max(align, size));
>  
> -    res = alloc_xenheap_pages(order, 0);
> +    res = alloc_xenheap_pages(order, memflags);
>      if ( res == NULL )
>          return NULL;
>  
> @@ -562,6 +563,17 @@ static void *xmalloc_whole_pages(unsigned long size, unsigned long align)
>      return res;
>  }
>  
> +void *_xzalloc_whole_pages(unsigned long size, unsigned long align,
> +                           unsigned int memflags)
> +{
> +    void *p = _xmalloc_whole_pages(size, align, memflags);
> +
> +    if ( p )
> +        memset(p, 0, size);
> +
> +    return p;
> +}
> +
>  static void tlsf_init(void)
>  {
>      xenpool = xmem_pool_create("xmalloc", xmalloc_pool_get,
> @@ -628,7 +640,7 @@ void *_xmalloc(unsigned long size, unsigned long align)
>      if ( size < PAGE_SIZE )
>          p = xmem_pool_alloc(size, xenpool);
>      if ( p == NULL )
> -        return xmalloc_whole_pages(size - align + MEM_ALIGN, align);
> +        return _xmalloc_whole_pages(size - align + MEM_ALIGN, align, 0);
>  
>      /* Add alignment padding. */
>      p = add_padding(p, align);
> diff --git a/xen/include/xen/xmalloc.h b/xen/include/xen/xmalloc.h
> index b903fa2e26..3b05e992ef 100644
> --- a/xen/include/xen/xmalloc.h
> +++ b/xen/include/xen/xmalloc.h
> @@ -79,6 +79,10 @@ extern void xfree(void *p);
>  extern void *_xmalloc(unsigned long size, unsigned long align);
>  extern void *_xzalloc(unsigned long size, unsigned long align);
>  extern void *_xrealloc(void *ptr, unsigned long size, unsigned long align);
> +extern void *_xmalloc_whole_pages(unsigned long size, unsigned long align,
> +                                  unsigned int memflags);
> +extern void *_xzalloc_whole_pages(unsigned long size, unsigned long align,
> +                                  unsigned int memflags);
>  
>  static inline void *_xmalloc_array(
>      unsigned long size, unsigned long align, unsigned long num)
> -- 
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 22:07:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 22:07:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857222.1269618 (Exim 4.92)
	(envelope-from )
	id 1tMDof-0008Bv-7Y; Fri, 13 Dec 2024 22:07:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857222.1269618; Fri, 13 Dec 2024 22:07: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 1tMDof-0008Bo-4u; Fri, 13 Dec 2024 22:07:21 +0000
Received: by outflank-mailman (input) for mailman id 857222;
 Fri, 13 Dec 2024 22:07: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 1tMDod-0007e3-Hi
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 22:07:19 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9dc2396a-b99e-11ef-99a3-01e77a169b0f;
 Fri, 13 Dec 2024 23:07:18 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 11313A42E09;
 Fri, 13 Dec 2024 22:05:26 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6C66C4CED0;
 Fri, 13 Dec 2024 22:07:15 +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: 9dc2396a-b99e-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1734127636;
	bh=vdpib4y+gL1a3865p0IRl3l7ICW/lrQh+lZjgFg2pS4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=IZn4pKD1e00zkZZ7QoWlmC9dSGAvnWxTCKDhOCFEpYuHCM2P9rUNRdPPkDIxDjhno
	 kLHfPlEWJFq1V8kf2mnCjVedBSTN73CFLbrjtDvAz3T+7LZqISotOLDorvwm74ZarE
	 iA7OfEHp8fsj8dvxauQpYy/Y5ZinjpGAGevN7ZNj4JSi/V6NJuqfemp1MB3aOexcne
	 MWA4/nUni2O3IEHlX819lNsc7X63gsAsa+F+jhjJuIiD5KPby42bG1mAP8RJffUXCF
	 a4eeeLppNTFj5K2ZVbb92RAs6FFFZS7dPQ5pD+rnS8COOF0ga6sfhc6LhqsZSf/o4O
	 fh0z1FVVptQwg==
Date: Fri, 13 Dec 2024 14:07:14 -0800 (PST)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Mykyta Poturai 
cc: "xen-devel@lists.xenproject.org" , 
    Oleksandr Andrushchenko , 
    Stefano Stabellini , Julien Grall , 
    Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Volodymyr Babchuk 
Subject: Re: [PATCH 2/2] xen/arm: platform: Add support for R-Car Gen4
In-Reply-To: 
Message-ID: 
References:  
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Fri, 13 Dec 2024, Mykyta Poturai wrote:
> From: Oleksandr Andrushchenko 
> 
> Add Rcar Gen4 platform choice to Kconfig to select all required
> drivers automatically.
> 
> Signed-off-by: Oleksandr Andrushchenko 
> Signed-off-by: Volodymyr Babchuk 
> Signed-off-by: Mykyta Poturai 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/platforms/Kconfig | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
> index 02322c259c..8785c168bd 100644
> --- a/xen/arch/arm/platforms/Kconfig
> +++ b/xen/arch/arm/platforms/Kconfig
> @@ -29,6 +29,15 @@ config RCAR3
>  	help
>  	Enable all the required drivers for Renesas RCar3
>  
> +config RCAR4
> +	bool "Renesas RCar4 support"
> +	depends on ARM_64
> +	select HAS_SCIF
> +	select HAS_ITS
> +	select IPMMU_VMSA
> +	help
> +	Enable all the required drivers for Renesas RCar4
> +
>  config MPSOC
>  	bool "Xilinx Ultrascale+ MPSoC support"
>  	depends on ARM_64
> @@ -55,4 +64,3 @@ config ALL32_PLAT
>  config MPSOC_PLATFORM
>  	bool
>  	default (ALL64_PLAT || MPSOC)
> -
> -- 
> 2.34.1
> 


From xen-devel-bounces@lists.xenproject.org Fri Dec 13 22:49:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 22:49:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857235.1269628 (Exim 4.92)
	(envelope-from )
	id 1tMETY-00051V-9h; Fri, 13 Dec 2024 22:49:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857235.1269628; Fri, 13 Dec 2024 22:49: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 1tMETY-00051O-5o; Fri, 13 Dec 2024 22:49:36 +0000
Received: by outflank-mailman (input) for mailman id 857235;
 Fri, 13 Dec 2024 22:49:35 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1tMETX-00051I-SY
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 22:49:35 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1tMETW-001SJU-2g;
 Fri, 13 Dec 2024 22:49:35 +0000
Received: from [2a02:8012:3a1:0:544c:e3b3:a616:8824]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1tMETW-0032bt-2m;
 Fri, 13 Dec 2024 22:49: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" 
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=J5b/8kbUcBUlf1uNLsu1i4+8JQ0VNiRoMT0NGuW5SzI=; b=o/3RBEenMF7LT20qa9M/SpwROM
	1xBH4Bn/mQaVkmtInMO91nLYYoDe+9S++bry2ocdYeNuuGDZ/mPztpj+ycMsBf6B0AAHrApYodFXn
	uAGZkrnXCZ5YeCWonVxiv9BAXWjOQG8a68BnPYhLToW8r7arOj7lCyxm1fKCxSKdxgHw=;
Message-ID: 
Date: Fri, 13 Dec 2024 22:49:32 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] ARM: ITS: implement quirks and add support for
 Renesas Gen4 ITS
Content-Language: en-GB
To: Stefano Stabellini ,
 Mykyta Poturai 
Cc: "xen-devel@lists.xenproject.org" ,
 Oleksandr Andrushchenko ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: 
 <2ea26be2689585ea254a9c0177816722bcb2db8d.1734096752.git.mykyta_poturai@epam.com>
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 13/12/2024 22:06, Stefano Stabellini wrote:
> On Fri, 13 Dec 2024, Mykyta Poturai wrote:
>> From: Oleksandr Andrushchenko 
>>
>> There are number of ITS implementations exist which are different from
>> the base one which have number of functionalities defined as is
>> "IMPLEMENTATION DEFINED", e.g. there may exist differences in cacheability,
>> shareability and memory requirements and others. This requires
>> appropriate handling of such HW requirements which are implemented as
>> ITS quirks: GITS_IIDR (ITS Implementer Identification Register) is used to
>> differentiate the ITS implementations and select appropriate set of
>> quirks if any.
>>
>> As an example of such ITSes add quirk implementation for Renesas Gen4 ITS:
>> - add possibility to override default cacheability and shareability
>> settings used for ITS memory allocations;
>> - add possibility to allocate memory used by ITS with specific memory
>> requirements: introduce _x{z|m}alloc_whole_pages functions and free the
>> memory with xfree as usual.

Do you have any link to any errata documentation?

>>
>> The idea of the quirk implementation is inspired by the Linux kernel ITS
>> quirk implementation [1].
>>
>> Signed-off-by: Oleksandr Andrushchenko 
>> Signed-off-by: Mykyta Poturai 
>>
>> [1] https://elixir.bootlin.com/linux/v5.16.1/source/drivers/irqchip/irq-gic-v3-its.c
>> ---
>>   xen/arch/arm/gic-v3-its.c             | 90 ++++++++++++++++++++++++---
>>   xen/arch/arm/gic-v3-lpi.c             | 14 +++--
>>   xen/arch/arm/include/asm/gic_v3_its.h |  8 +++
>>   xen/arch/arm/vgic-v3-its.c            |  8 +--
>>   xen/common/xmalloc_tlsf.c             | 18 +++++-
>>   xen/include/xen/xmalloc.h             |  4 ++
>>   6 files changed, 122 insertions(+), 20 deletions(-)
>>
>> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
>> index 5fd83af25a..b1a2cdccc5 100644
>> --- a/xen/arch/arm/gic-v3-its.c
>> +++ b/xen/arch/arm/gic-v3-its.c
>> @@ -50,6 +50,77 @@ struct its_device {
>>       struct pending_irq *pend_irqs;      /* One struct per event */
>>   };
>>   
>> +/*
>> + * It is unlikely that a platform implements ITSes with different quirks,
>> + * so assume they all share the same.
>> + */
>> +struct its_quirk {
>> +    const char *desc;
>> +    bool (*init)(struct host_its *hw_its);
>> +    uint32_t iidr;
>> +    uint32_t mask;
>> +};
>> +
>> +uint32_t its_quirk_flags;

Is this mean to be modified after boot? If not, then can we use 
__ro_after_init?

>> diff --git a/xen/arch/arm/include/asm/gic_v3_its.h b/xen/arch/arm/include/asm/gic_v3_its.h
>> index c24d4752d0..0737e67aa6 100644
>> --- a/xen/arch/arm/include/asm/gic_v3_its.h
>> +++ b/xen/arch/arm/include/asm/gic_v3_its.h
>> @@ -110,6 +110,9 @@
>>   #define HOST_ITS_FLUSH_CMD_QUEUE        (1U << 0)
>>   #define HOST_ITS_USES_PTA               (1U << 1)
>>   
>> +#define HOST_ITS_WORKAROUND_NC_NS       (1U << 0)
>> +#define HOST_ITS_WORKAROUND_32BIT_ADDR  (1U << 1)
>> +
>>   /* We allocate LPIs on the hosts in chunks of 32 to reduce handling overhead. */
>>   #define LPI_BLOCK                       32U
>>   
>> @@ -197,6 +200,11 @@ struct pending_irq *gicv3_assign_guest_event(struct domain *d,
>>   void gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id,
>>                                    uint32_t virt_lpi);
>>   
>> +/* ITS quirks handling. */
>> +uint64_t gicv3_its_get_cacheability(void);
>> +uint64_t gicv3_its_get_shareability(void);
>> +unsigned int gicv3_its_get_memflags(void);
>> +
>>   #else
>>   
>>   #ifdef CONFIG_ACPI
>> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
>> index c65c1dbf52..f5deb18497 100644
>> --- a/xen/arch/arm/vgic-v3-its.c
>> +++ b/xen/arch/arm/vgic-v3-its.c
>> @@ -1191,7 +1191,7 @@ static void sanitize_its_base_reg(uint64_t *reg)
>>       {
>>       case GIC_BASER_OuterShareable:
>>           r &= ~GITS_BASER_SHAREABILITY_MASK;
>> -        r |= GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
>> +        r |= gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHIFT;
>>           break;
>>       default:
>>           break;
>> @@ -1203,7 +1203,7 @@ static void sanitize_its_base_reg(uint64_t *reg)
>>       case GIC_BASER_CACHE_nCnB:
>>       case GIC_BASER_CACHE_nC:
>>           r &= ~GITS_BASER_INNER_CACHEABILITY_MASK;
>> -        r |= GIC_BASER_CACHE_RaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
>> +        r |= gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILITY_SHIFT;
> 
> gicv3_its_get_cacheability returns GIC_BASER_CACHE_RaWaWb, because that
> is the value that was previously present in all the other cases. In this
> case, however, we end up replacing GIC_BASER_CACHE_RaWb with
> GIC_BASER_CACHE_RaWaWb. Is that OK?

Actually I don't understand why we need to modify the vGIC code. We 
never pass memory from the domain to the physical ITS, so the erratum 
should not apply.
> 
>>           break;
>>       default:
>>           break;
>> @@ -1455,9 +1455,9 @@ static int vgic_v3_its_init_virtual(struct domain *d, paddr_t guest_addr,
>>       if ( !its )
>>           return -ENOMEM;
>>   
>> -    base_attr  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
>> +    base_attr  = gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHIFT;
>>       base_attr |= GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY_SHIFT;
>> -    base_attr |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
>> +    base_attr |= gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILITY_SHIFT;
>>   
>>       its->cbaser  = base_attr;
>>       base_attr |= 0ULL << GITS_BASER_PAGE_SIZE_SHIFT;    /* 4K pages */

[...]

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Fri Dec 13 22:57:26 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Dec 2024 22:57:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857246.1269638 (Exim 4.92)
	(envelope-from )
	id 1tMEb4-0006hq-0z; Fri, 13 Dec 2024 22:57:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857246.1269638; Fri, 13 Dec 2024 22:57: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 1tMEb3-0006hj-Tg; Fri, 13 Dec 2024 22:57:21 +0000
Received: by outflank-mailman (input) for mailman id 857246;
 Fri, 13 Dec 2024 22:57:21 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1tMEb3-0006hd-4J
 for xen-devel@lists.xenproject.org; Fri, 13 Dec 2024 22:57:21 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1tMEb2-001SRY-0s;
 Fri, 13 Dec 2024 22:57:20 +0000
Received: from [2a02:8012:3a1:0:544c:e3b3:a616:8824]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1tMEb2-0033aW-1H;
 Fri, 13 Dec 2024 22:57:20 +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=oRnpSM+/TcK7gpc3shES86e+UYwEi0FaIXIFQkqcmss=; b=CkqBAS6UuDPd2oyhLCFQq2cojI
	tlcxNqNABgwPR1rfJC+VU4POz9nz0PlEHjcA2Th1KffigtFmeXk5o5NUDtvK9CEz+QIpaoT+ZcP7v
	A5ub8c20yhEiI8DwrhATG1Vx1pCl0S6c83PVuZrrUQ0VqE4DgXUP+9Ae9Kl4MmAbaZ34=;
Message-ID: <8d8ef7f9-d73f-4ff8-8af9-4e73cda97624@xen.org>
Date: Fri, 13 Dec 2024 22:57:17 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 04/10] xen/arm: ffa: Fine granular call support
Content-Language: en-GB
To: Bertrand Marquis ,
 xen-devel@lists.xenproject.org
Cc: jens.wiklander@linaro.org, Volodymyr Babchuk
 , Stefano Stabellini ,
 Michal Orzel 
References: 
 <1b02c9c1df9ff2230e076f25398a5de876f98a51.1732702210.git.bertrand.marquis@arm.com>
From: Julien Grall 
In-Reply-To: <1b02c9c1df9ff2230e076f25398a5de876f98a51.1732702210.git.bertrand.marquis@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Bertrand,

On 27/11/2024 16:07, Bertrand Marquis wrote:
> Create a bitmap to store which feature is supported or not by the
> firmware and use it to filter which calls are done to the firmware.
> 
> While there reoder ABI definition by numbers to easily find the min and

Typo (I can fix it while committing): s/reoder/reorder

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Sat Dec 14 00:06:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Dec 2024 00:06:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857257.1269647 (Exim 4.92)
	(envelope-from )
	id 1tMFfk-0007fy-GK; Sat, 14 Dec 2024 00:06:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857257.1269647; Sat, 14 Dec 2024 00:06: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 1tMFfk-0007fr-Do; Sat, 14 Dec 2024 00:06:16 +0000
Received: by outflank-mailman (input) for mailman id 857257;
 Sat, 14 Dec 2024 00:06: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 1tMFfi-0007fl-5R
 for xen-devel@lists.xenproject.org; Sat, 14 Dec 2024 00:06:14 +0000
Received: from fanzine2.igalia.com (fanzine.igalia.com [178.60.130.6])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 353d8d15-b9af-11ef-99a3-01e77a169b0f;
 Sat, 14 Dec 2024 01:06:04 +0100 (CET)
Received: from maestria.local.igalia.com ([192.168.10.14] helo=mail.igalia.com)
 by fanzine2.igalia.com with esmtps 
 (Cipher TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim)
 id 1tMFes-002sgk-73; Sat, 14 Dec 2024 01:05:22 +0100
Received: from gate.service.igalia.com ([192.168.21.52])
 by mail.igalia.com with esmtp (Exim)
 id 1tMFeq-007HeJ-9B; Sat, 14 Dec 2024 01:05:22 +0100
Received: from berto by gate.service.igalia.com with local (Exim 4.96)
 (envelope-from ) id 1tMFeq-007aKe-0O;
 Sat, 14 Dec 2024 00:05:20 +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: 353d8d15-b9af-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com;
	s=20170329; h=Content-Type:MIME-Version:Message-ID:Date:References:
	In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
	Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
	Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
	List-Subscribe:List-Post:List-Owner:List-Archive;
	bh=s3baxnvsv0QDjdbqpZIjo+pfDf0zddAKGBM4vYP+R4s=; b=AJ1SV70n7ay56Wph5Xdsr6p6Fi
	ypQHjAi5++9f6K3K8cMFXVCH2s7dvz+JMkaIlBo/lK9PaeDMNi/Q38Sf5hfM4hllCFstq43GI3JIs
	calJyadqr4UGXbq8Y2sW2/hu/MZNMWw46Zc9M5goyZaQtwdZCeR99GZjBBAinedWfQeEgm/T4miw9
	ZTt+YioIM0tfkuWx3koJEJp+NbnzFzNJO4bQjV05qs8YzDJ09d3TCdIMIcpYb3egXDwr+f4ofM95g
	GhRivEcAA2t/BPOBkuZNquIHG/zCQrdwQ3XsDHwrjeYdqxmhmeJPdToREXKyQKnj+itqMXjmg7WH8
	yJISu/bg==;
From: Alberto Garcia 
To: Richard Henderson , qemu-devel@nongnu.org
Cc: Michael Rolnik , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau
 , Paolo Bonzini , Peter
 Maydell , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?=
 , "Edgar E. Iglesias" ,
 Alistair Francis , "Michael S. Tsirkin"
 , Antony Pavlov , Igor Mitsyanko
 , Laurent Vivier , =?utf-8?Q?Cl?=
 =?utf-8?Q?=C3=A9ment?=
 Chigot , Frederic Konrad ,
 Thomas Huth , Joel Stanley , Yoshinori
 Sato , Magnus Damm ,
 Halil Pasic , Christian Borntraeger
 , Vijai Kumar K , Bin
 Meng , Palmer Dabbelt , Nicholas
 Piggin , Daniel Henrique Barboza
 , Harsh Prateek Bora ,
 Samuel Tardieu , Amit Shah , Stefano
 Stabellini , Anthony PERARD
 , Paul Durrant , "open
 list:Raspberry Pi" , "open list:OpenTitan"
 , "open list:S390 general arch..."
 , "open list:sPAPR (pseries)"
 , "open list:X86 Xen CPUs"
 
Subject: Re: [PATCH 20/71] hw/char: Constify all Property
In-Reply-To: <20241213190750.2513964-25-richard.henderson@linaro.org>
References: <20241213190750.2513964-1-richard.henderson@linaro.org>
 <20241213190750.2513964-25-richard.henderson@linaro.org>
Date: Sat, 14 Dec 2024 01:05:20 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: NO, Score=0.6, Tests=ALL_TRUSTED=-1,AWL=0.775,BAYES_50=0.8,URIBL_BLOCKED=0.001
X-Spam-Score: 6
X-Spam-Bar: /

On Fri 13 Dec 2024 01:06:54 PM -06, Richard Henderson wrote:
> Signed-off-by: Richard Henderson 

Acked-by: Alberto Garcia 

Berto


From xen-devel-bounces@lists.xenproject.org Sat Dec 14 10:05:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Dec 2024 10:05:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857332.1269677 (Exim 4.92)
	(envelope-from )
	id 1tMP1V-0006gS-8R; Sat, 14 Dec 2024 10:05:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857332.1269677; Sat, 14 Dec 2024 10:05: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 1tMP1V-0006gK-49; Sat, 14 Dec 2024 10:05:21 +0000
Received: by outflank-mailman (input) for mailman id 857332;
 Sat, 14 Dec 2024 10:05: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 1tMP1T-0006gE-Tw
 for xen-devel@lists.xenproject.org; Sat, 14 Dec 2024 10:05:20 +0000
Received: from mail.ozlabs.org (mail.ozlabs.org [2404:9400:2221:ea00::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e90c478c-ba02-11ef-a0d6-8be0dac302b0;
 Sat, 14 Dec 2024 11:05:18 +0100 (CET)
Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3])
 by gandalf.ozlabs.org (Postfix) with ESMTP id 4Y9MJf5d2dz4wj2;
 Sat, 14 Dec 2024 21:05:06 +1100 (AEDT)
Received: from authenticated.ozlabs.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)
 (Client did not present a certificate)
 by mail.ozlabs.org (Postfix) with ESMTPSA id 4Y9MJ53k8qz4w2R;
 Sat, 14 Dec 2024 21:04:37 +1100 (AEDT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: e90c478c-ba02-11ef-a0d6-8be0dac302b0
Message-ID: <3bdef0a1-df2e-400e-91ea-76c3196aead4@kaod.org>
Date: Sat, 14 Dec 2024 11:04:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 41/71] hw/net: Constify all Property
To: Richard Henderson , qemu-devel@nongnu.org
Cc: Beniamino Galvani ,
 Peter Maydell ,
 Strahinja Jankovic ,
 Jason Wang ,
 "Edgar E. Iglesias" ,
 Alistair Francis , Pavel Pisa
 , Francisco Iglesias ,
 Vikram Garhwal ,
 Dmitry Fleytman ,
 Akihiko Odaki , Stefan Weil ,
 Bernhard Beschow , Steven Lee
 , Troy Lee ,
 Jamin Lin ,
 Andrew Jeffery , Joel Stanley ,
 Sriram Yagnaraman ,
 Helge Deller , Thomas Huth ,
 Aleksandar Rikalo ,
 Subbaraya Sundeep , Jan Kiszka ,
 Tyrone Ting , Hao Wu ,
 Max Filippov , Jiri Pirko ,
 Nicholas Piggin ,
 Daniel Henrique Barboza ,
 Harsh Prateek Bora ,
 Sven Schnelle , "Michael S. Tsirkin" ,
 Stefano Stabellini ,
 Anthony PERARD , Paul Durrant ,
 Rob Herring , "open list:Allwinner-a10"
 , "open list:e500" ,
 "open list:X86 Xen CPUs" 
References: <20241213190750.2513964-1-richard.henderson@linaro.org>
 <20241213190750.2513964-46-richard.henderson@linaro.org>
Content-Language: en-US, fr
From: =?UTF-8?Q?C=C3=A9dric_Le_Goater?= 
Autocrypt: addr=clg@kaod.org; keydata=
 xsFNBFu8o3UBEADP+oJVJaWm5vzZa/iLgpBAuzxSmNYhURZH+guITvSySk30YWfLYGBWQgeo
 8NzNXBY3cH7JX3/a0jzmhDc0U61qFxVgrPqs1PQOjp7yRSFuDAnjtRqNvWkvlnRWLFq4+U5t
 yzYe4SFMjFb6Oc0xkQmaK2flmiJNnnxPttYwKBPd98WfXMmjwAv7QfwW+OL3VlTPADgzkcqj
 53bfZ4VblAQrq6Ctbtu7JuUGAxSIL3XqeQlAwwLTfFGrmpY7MroE7n9Rl+hy/kuIrb/TO8n0
 ZxYXvvhT7OmRKvbYuc5Jze6o7op/bJHlufY+AquYQ4dPxjPPVUT/DLiUYJ3oVBWFYNbzfOrV
 RxEwNuRbycttMiZWxgflsQoHF06q/2l4ttS3zsV4TDZudMq0TbCH/uJFPFsbHUN91qwwaN/+
 gy1j7o6aWMz+Ib3O9dK2M/j/O/Ube95mdCqN4N/uSnDlca3YDEWrV9jO1mUS/ndOkjxa34ia
 70FjwiSQAsyIwqbRO3CGmiOJqDa9qNvd2TJgAaS2WCw/TlBALjVQ7AyoPEoBPj31K74Wc4GS
 Rm+FSch32ei61yFu6ACdZ12i5Edt+To+hkElzjt6db/UgRUeKfzlMB7PodK7o8NBD8outJGS
 tsL2GRX24QvvBuusJdMiLGpNz3uqyqwzC5w0Fd34E6G94806fwARAQABzSBDw6lkcmljIExl
 IEdvYXRlciA8Y2xnQGthb2Qub3JnPsLBeAQTAQIAIgUCW7yjdQIbAwYLCQgHAwIGFQgCCQoL
 BBYCAwECHgECF4AACgkQUaNDx8/77KGRSxAAuMJJMhJdj7acTcFtwof7CDSfoVX0owE2FJdd
 M43hNeTwPWlV5oLCj1BOQo0MVilIpSd9Qu5wqRD8KnN2Bv/rllKPqK2+i8CXymi9hsuzF56m
 76wiPwbsX54jhv/VYY9Al7NBknh6iLYJiC/pgacRCHtSj/wofemSCM48s61s1OleSPSSvJE/
 jYRa0jMXP98N5IEn8rEbkPua/yrm9ynHqi4dKEBCq/F7WDQ+FfUaFQb4ey47A/aSHstzpgsl
 TSDTJDD+Ms8y9x2X5EPKXnI3GRLaCKXVNNtrvbUd9LsKymK3WSbADaX7i0gvMFq7j51P/8yj
 neaUSKSkktHauJAtBNXHMghWm/xJXIVAW8xX5aEiSK7DNp5AM478rDXn9NZFUdLTAScVf7LZ
 VzMFKR0jAVG786b/O5vbxklsww+YXJGvCUvHuysEsz5EEzThTJ6AC5JM2iBn9/63PKiS3ptJ
 QAqzasT6KkZ9fKLdK3qtc6yPaSm22C5ROM3GS+yLy6iWBkJ/nEYh/L/du+TLw7YNbKejBr/J
 ml+V3qZLfuhDjW0GbeJVPzsENuxiNiBbyzlSnAvKlzda/sBDvxmvWhC+nMRQCf47mFr8Xx3w
 WtDSQavnz3zTa0XuEucpwfBuVdk4RlPzNPri6p2KTBhPEvRBdC9wNOdRBtsP9rAPjd52d73O
 wU0EW7yjdQEQALyDNNMw/08/fsyWEWjfqVhWpOOrX2h+z4q0lOHkjxi/FRIRLfXeZjFfNQNL
 SoL8j1y2rQOs1j1g+NV3K5hrZYYcMs0xhmrZKXAHjjDx7FW3sG3jcGjFW5Xk4olTrZwFsZVU
 cP8XZlArLmkAX3UyrrXEWPSBJCXxDIW1hzwpbV/nVbo/K9XBptT/wPd+RPiOTIIRptjypGY+
 S23HYBDND3mtfTz/uY0Jytaio9GETj+fFis6TxFjjbZNUxKpwftu/4RimZ7qL+uM1rG1lLWc
 9SPtFxRQ8uLvLOUFB1AqHixBcx7LIXSKZEFUCSLB2AE4wXQkJbApye48qnZ09zc929df5gU6
 hjgqV9Gk1rIfHxvTsYltA1jWalySEScmr0iSYBZjw8Nbd7SxeomAxzBv2l1Fk8fPzR7M616d
 tb3Z3HLjyvwAwxtfGD7VnvINPbzyibbe9c6gLxYCr23c2Ry0UfFXh6UKD83d5ybqnXrEJ5n/
 t1+TLGCYGzF2erVYGkQrReJe8Mld3iGVldB7JhuAU1+d88NS3aBpNF6TbGXqlXGF6Yua6n1c
 OY2Yb4lO/mDKgjXd3aviqlwVlodC8AwI0SdujWryzL5/AGEU2sIDQCHuv1QgzmKwhE58d475
 KdVX/3Vt5I9kTXpvEpfW18TjlFkdHGESM/JxIqVsqvhAJkalABEBAAHCwV8EGAECAAkFAlu8
 o3UCGwwACgkQUaNDx8/77KEhwg//WqVopd5k8hQb9VVdk6RQOCTfo6wHhEqgjbXQGlaxKHoX
 ywEQBi8eULbeMQf5l4+tHJWBxswQ93IHBQjKyKyNr4FXseUI5O20XVNYDJZUrhA4yn0e/Af0
 IX25d94HXQ5sMTWr1qlSK6Zu79lbH3R57w9jhQm9emQEp785ui3A5U2Lqp6nWYWXz0eUZ0Ta
 d2zC71Gg9VazU9MXyWn749s0nXbVLcLS0yops302Gf3ZmtgfXTX/W+M25hiVRRKCH88yr6it
 +OMJBUndQVAA/fE9hYom6t/zqA248j0QAV/pLHH3hSirE1mv+7jpQnhMvatrwUpeXrOiEw1n
 HzWCqOJUZ4SY+HmGFW0YirWV2mYKoaGO2YBUwYF7O9TI3GEEgRMBIRT98fHa0NPwtlTktVIS
 l73LpgVscdW8yg9Gc82oe8FzU1uHjU8b10lUXOMHpqDDEV9//r4ZhkKZ9C4O+YZcTFu+mvAY
 3GlqivBNkmYsHYSlFsbxc37E1HpTEaSWsGfAHQoPn9qrDJgsgcbBVc1gkUT6hnxShKPp4Pls
 ZVMNjvPAnr5TEBgHkk54HQRhhwcYv1T2QumQizDiU6iOrUzBThaMhZO3i927SG2DwWDVzZlt
 KrCMD1aMPvb3NU8FOYRhNmIFR3fcalYr+9gDuVKe8BVz4atMOoktmt0GWTOC8P4=
In-Reply-To: <20241213190750.2513964-46-richard.henderson@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 12/13/24 20:07, Richard Henderson wrote:
> Signed-off-by: Richard Henderson 
> ---
>   hw/net/allwinner-sun8i-emac.c  | 2 +-
>   hw/net/allwinner_emac.c        | 2 +-
>   hw/net/cadence_gem.c           | 2 +-
>   hw/net/can/xlnx-versal-canfd.c | 2 +-
>   hw/net/can/xlnx-zynqmp-can.c   | 2 +-
>   hw/net/dp8393x.c               | 2 +-
>   hw/net/e1000.c                 | 2 +-
>   hw/net/e1000e.c                | 2 +-
>   hw/net/eepro100.c              | 2 +-
>   hw/net/fsl_etsec/etsec.c       | 2 +-
>   hw/net/ftgmac100.c             | 4 ++--
>   hw/net/igb.c                   | 2 +-
>   hw/net/imx_fec.c               | 2 +-
>   hw/net/lan9118.c               | 2 +-
>   hw/net/lance.c                 | 2 +-
>   hw/net/lasi_i82596.c           | 2 +-
>   hw/net/mcf_fec.c               | 2 +-
>   hw/net/mipsnet.c               | 2 +-
>   hw/net/msf2-emac.c             | 2 +-
>   hw/net/mv88w8618_eth.c         | 2 +-
>   hw/net/ne2000-isa.c            | 2 +-
>   hw/net/ne2000-pci.c            | 2 +-
>   hw/net/npcm7xx_emc.c           | 2 +-
>   hw/net/npcm_gmac.c             | 2 +-
>   hw/net/opencores_eth.c         | 2 +-
>   hw/net/pcnet-pci.c             | 2 +-
>   hw/net/rocker/rocker.c         | 2 +-
>   hw/net/rtl8139.c               | 2 +-
>   hw/net/smc91c111.c             | 2 +-
>   hw/net/spapr_llan.c            | 2 +-
>   hw/net/stellaris_enet.c        | 2 +-
>   hw/net/sungem.c                | 2 +-
>   hw/net/sunhme.c                | 2 +-
>   hw/net/tulip.c                 | 2 +-
>   hw/net/virtio-net.c            | 2 +-
>   hw/net/vmxnet3.c               | 2 +-
>   hw/net/xen_nic.c               | 2 +-
>   hw/net/xgmac.c                 | 2 +-
>   hw/net/xilinx_axienet.c        | 2 +-
>   hw/net/xilinx_ethlite.c        | 2 +-
>   40 files changed, 41 insertions(+), 41 deletions(-)


For the ftgmac100,

Reviewed-by: Cédric Le Goater 

Thanks,

C.

> 
> diff --git a/hw/net/allwinner-sun8i-emac.c b/hw/net/allwinner-sun8i-emac.c
> index cdae74f503..3f03060bf5 100644
> --- a/hw/net/allwinner-sun8i-emac.c
> +++ b/hw/net/allwinner-sun8i-emac.c
> @@ -829,7 +829,7 @@ static void allwinner_sun8i_emac_realize(DeviceState *dev, Error **errp)
>       qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
>   }
>   
> -static Property allwinner_sun8i_emac_properties[] = {
> +static const Property allwinner_sun8i_emac_properties[] = {
>       DEFINE_NIC_PROPERTIES(AwSun8iEmacState, conf),
>       DEFINE_PROP_UINT8("phy-addr", AwSun8iEmacState, mii_phy_addr, 0),
>       DEFINE_PROP_LINK("dma-memory", AwSun8iEmacState, dma_mr,
> diff --git a/hw/net/allwinner_emac.c b/hw/net/allwinner_emac.c
> index c104c2588e..39c10426cf 100644
> --- a/hw/net/allwinner_emac.c
> +++ b/hw/net/allwinner_emac.c
> @@ -462,7 +462,7 @@ static void aw_emac_realize(DeviceState *dev, Error **errp)
>       fifo8_create(&s->tx_fifo[1], TX_FIFO_SIZE);
>   }
>   
> -static Property aw_emac_properties[] = {
> +static const Property aw_emac_properties[] = {
>       DEFINE_NIC_PROPERTIES(AwEmacState, conf),
>       DEFINE_PROP_UINT8("phy-addr", AwEmacState, phy_addr, 0),
>       DEFINE_PROP_END_OF_LIST(),
> diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
> index 526739887c..3fce01315f 100644
> --- a/hw/net/cadence_gem.c
> +++ b/hw/net/cadence_gem.c
> @@ -1784,7 +1784,7 @@ static const VMStateDescription vmstate_cadence_gem = {
>       }
>   };
>   
> -static Property gem_properties[] = {
> +static const Property gem_properties[] = {
>       DEFINE_NIC_PROPERTIES(CadenceGEMState, conf),
>       DEFINE_PROP_UINT32("revision", CadenceGEMState, revision,
>                          GEM_MODID_VALUE),
> diff --git a/hw/net/can/xlnx-versal-canfd.c b/hw/net/can/xlnx-versal-canfd.c
> index e148bd7b46..97fa46c4b3 100644
> --- a/hw/net/can/xlnx-versal-canfd.c
> +++ b/hw/net/can/xlnx-versal-canfd.c
> @@ -2042,7 +2042,7 @@ static const VMStateDescription vmstate_canfd = {
>       }
>   };
>   
> -static Property canfd_core_properties[] = {
> +static const Property canfd_core_properties[] = {
>       DEFINE_PROP_UINT8("rx-fifo0", XlnxVersalCANFDState, cfg.rx0_fifo, 0x40),
>       DEFINE_PROP_UINT8("rx-fifo1", XlnxVersalCANFDState, cfg.rx1_fifo, 0x40),
>       DEFINE_PROP_UINT8("tx-fifo", XlnxVersalCANFDState, cfg.tx_fifo, 0x20),
> diff --git a/hw/net/can/xlnx-zynqmp-can.c b/hw/net/can/xlnx-zynqmp-can.c
> index 58f1432bb3..61c104c18b 100644
> --- a/hw/net/can/xlnx-zynqmp-can.c
> +++ b/hw/net/can/xlnx-zynqmp-can.c
> @@ -1169,7 +1169,7 @@ static const VMStateDescription vmstate_can = {
>       }
>   };
>   
> -static Property xlnx_zynqmp_can_properties[] = {
> +static const Property xlnx_zynqmp_can_properties[] = {
>       DEFINE_PROP_UINT32("ext_clk_freq", XlnxZynqMPCANState, cfg.ext_clk_freq,
>                          CAN_DEFAULT_CLOCK),
>       DEFINE_PROP_LINK("canbus", XlnxZynqMPCANState, canbus, TYPE_CAN_BUS,
> diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
> index c0977308ba..e3ca11991b 100644
> --- a/hw/net/dp8393x.c
> +++ b/hw/net/dp8393x.c
> @@ -931,7 +931,7 @@ static const VMStateDescription vmstate_dp8393x = {
>       }
>   };
>   
> -static Property dp8393x_properties[] = {
> +static const Property dp8393x_properties[] = {
>       DEFINE_NIC_PROPERTIES(dp8393xState, conf),
>       DEFINE_PROP_LINK("dma_mr", dp8393xState, dma_mr,
>                        TYPE_MEMORY_REGION, MemoryRegion *),
> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> index ab72236d18..ef0af31751 100644
> --- a/hw/net/e1000.c
> +++ b/hw/net/e1000.c
> @@ -1677,7 +1677,7 @@ static void pci_e1000_realize(PCIDevice *pci_dev, Error **errp)
>                                           e1000_flush_queue_timer, d);
>   }
>   
> -static Property e1000_properties[] = {
> +static const Property e1000_properties[] = {
>       DEFINE_NIC_PROPERTIES(E1000State, conf),
>       DEFINE_PROP_BIT("extra_mac_registers", E1000State,
>                       compat_flags, E1000_FLAG_MAC_BIT, true),
> diff --git a/hw/net/e1000e.c b/hw/net/e1000e.c
> index 843892ce09..e2b7576f67 100644
> --- a/hw/net/e1000e.c
> +++ b/hw/net/e1000e.c
> @@ -661,7 +661,7 @@ static PropertyInfo e1000e_prop_disable_vnet,
>                       e1000e_prop_subsys_ven,
>                       e1000e_prop_subsys;
>   
> -static Property e1000e_properties[] = {
> +static const Property e1000e_properties[] = {
>       DEFINE_NIC_PROPERTIES(E1000EState, conf),
>       DEFINE_PROP_SIGNED("disable_vnet_hdr", E1000EState, disable_vnet, false,
>                           e1000e_prop_disable_vnet, bool),
> diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
> index 20b22d8e49..b8cb8d5cf1 100644
> --- a/hw/net/eepro100.c
> +++ b/hw/net/eepro100.c
> @@ -2058,7 +2058,7 @@ static E100PCIDeviceInfo *eepro100_get_class(EEPRO100State *s)
>       return eepro100_get_class_by_name(object_get_typename(OBJECT(s)));
>   }
>   
> -static Property e100_properties[] = {
> +static const Property e100_properties[] = {
>       DEFINE_NIC_PROPERTIES(EEPRO100State, conf),
>       DEFINE_PROP_END_OF_LIST(),
>   };
> diff --git a/hw/net/fsl_etsec/etsec.c b/hw/net/fsl_etsec/etsec.c
> index d8076e7be4..764be2c6a2 100644
> --- a/hw/net/fsl_etsec/etsec.c
> +++ b/hw/net/fsl_etsec/etsec.c
> @@ -414,7 +414,7 @@ static void etsec_instance_init(Object *obj)
>       sysbus_init_irq(sbd, &etsec->err_irq);
>   }
>   
> -static Property etsec_properties[] = {
> +static const Property etsec_properties[] = {
>       DEFINE_NIC_PROPERTIES(eTSEC, conf),
>       DEFINE_PROP_END_OF_LIST(),
>   };
> diff --git a/hw/net/ftgmac100.c b/hw/net/ftgmac100.c
> index 478356ee3e..4adc7fb10c 100644
> --- a/hw/net/ftgmac100.c
> +++ b/hw/net/ftgmac100.c
> @@ -1254,7 +1254,7 @@ static const VMStateDescription vmstate_ftgmac100 = {
>       }
>   };
>   
> -static Property ftgmac100_properties[] = {
> +static const Property ftgmac100_properties[] = {
>       DEFINE_PROP_BOOL("aspeed", FTGMAC100State, aspeed, false),
>       DEFINE_NIC_PROPERTIES(FTGMAC100State, conf),
>       DEFINE_PROP_BOOL("dma64", FTGMAC100State, dma64, false),
> @@ -1415,7 +1415,7 @@ static const VMStateDescription vmstate_aspeed_mii = {
>       }
>   };
>   
> -static Property aspeed_mii_properties[] = {
> +static const Property aspeed_mii_properties[] = {
>       DEFINE_PROP_LINK("nic", AspeedMiiState, nic, TYPE_FTGMAC100,
>                        FTGMAC100State *),
>       DEFINE_PROP_END_OF_LIST(),
> diff --git a/hw/net/igb.c b/hw/net/igb.c
> index b92bba402e..ad0f748d82 100644
> --- a/hw/net/igb.c
> +++ b/hw/net/igb.c
> @@ -591,7 +591,7 @@ static const VMStateDescription igb_vmstate = {
>       }
>   };
>   
> -static Property igb_properties[] = {
> +static const Property igb_properties[] = {
>       DEFINE_NIC_PROPERTIES(IGBState, conf),
>       DEFINE_PROP_BOOL("x-pcie-flr-init", IGBState, has_flr, true),
>       DEFINE_PROP_END_OF_LIST(),
> diff --git a/hw/net/imx_fec.c b/hw/net/imx_fec.c
> index 4ee6f74206..9b64968477 100644
> --- a/hw/net/imx_fec.c
> +++ b/hw/net/imx_fec.c
> @@ -1222,7 +1222,7 @@ static void imx_eth_realize(DeviceState *dev, Error **errp)
>       qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
>   }
>   
> -static Property imx_eth_properties[] = {
> +static const Property imx_eth_properties[] = {
>       DEFINE_NIC_PROPERTIES(IMXFECState, conf),
>       DEFINE_PROP_UINT32("tx-ring-num", IMXFECState, tx_ring_num, 1),
>       DEFINE_PROP_UINT32("phy-num", IMXFECState, phy_num, 0),
> diff --git a/hw/net/lan9118.c b/hw/net/lan9118.c
> index 99e87b7178..237e9b97d5 100644
> --- a/hw/net/lan9118.c
> +++ b/hw/net/lan9118.c
> @@ -1304,7 +1304,7 @@ static void lan9118_realize(DeviceState *dev, Error **errp)
>       ptimer_transaction_commit(s->timer);
>   }
>   
> -static Property lan9118_properties[] = {
> +static const Property lan9118_properties[] = {
>       DEFINE_NIC_PROPERTIES(lan9118_state, conf),
>       DEFINE_PROP_UINT32("mode_16bit", lan9118_state, mode_16bit, 0),
>       DEFINE_PROP_END_OF_LIST(),
> diff --git a/hw/net/lance.c b/hw/net/lance.c
> index 269615b452..9ed9c94cff 100644
> --- a/hw/net/lance.c
> +++ b/hw/net/lance.c
> @@ -137,7 +137,7 @@ static void lance_instance_init(Object *obj)
>                                     DEVICE(obj));
>   }
>   
> -static Property lance_properties[] = {
> +static const Property lance_properties[] = {
>       DEFINE_PROP_LINK("dma", SysBusPCNetState, state.dma_opaque,
>                        TYPE_DEVICE, DeviceState *),
>       DEFINE_NIC_PROPERTIES(SysBusPCNetState, state.conf),
> diff --git a/hw/net/lasi_i82596.c b/hw/net/lasi_i82596.c
> index 183fab8712..248e3841db 100644
> --- a/hw/net/lasi_i82596.c
> +++ b/hw/net/lasi_i82596.c
> @@ -158,7 +158,7 @@ static void lasi_82596_instance_init(Object *obj)
>                                     DEVICE(obj));
>   }
>   
> -static Property lasi_82596_properties[] = {
> +static const Property lasi_82596_properties[] = {
>       DEFINE_NIC_PROPERTIES(SysBusI82596State, state.conf),
>       DEFINE_PROP_END_OF_LIST(),
>   };
> diff --git a/hw/net/mcf_fec.c b/hw/net/mcf_fec.c
> index 037cd2028e..55bad4c069 100644
> --- a/hw/net/mcf_fec.c
> +++ b/hw/net/mcf_fec.c
> @@ -660,7 +660,7 @@ static void mcf_fec_instance_init(Object *obj)
>       }
>   }
>   
> -static Property mcf_fec_properties[] = {
> +static const Property mcf_fec_properties[] = {
>       DEFINE_NIC_PROPERTIES(mcf_fec_state, conf),
>       DEFINE_PROP_END_OF_LIST(),
>   };
> diff --git a/hw/net/mipsnet.c b/hw/net/mipsnet.c
> index 31bbd6fb89..c9ef1beb7b 100644
> --- a/hw/net/mipsnet.c
> +++ b/hw/net/mipsnet.c
> @@ -266,7 +266,7 @@ static void mipsnet_sysbus_reset(DeviceState *dev)
>       mipsnet_reset(s);
>   }
>   
> -static Property mipsnet_properties[] = {
> +static const Property mipsnet_properties[] = {
>       DEFINE_NIC_PROPERTIES(MIPSnetState, conf),
>       DEFINE_PROP_END_OF_LIST(),
>   };
> diff --git a/hw/net/msf2-emac.c b/hw/net/msf2-emac.c
> index d28fc6c570..8d9015f962 100644
> --- a/hw/net/msf2-emac.c
> +++ b/hw/net/msf2-emac.c
> @@ -546,7 +546,7 @@ static void msf2_emac_init(Object *obj)
>       sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->mmio);
>   }
>   
> -static Property msf2_emac_properties[] = {
> +static const Property msf2_emac_properties[] = {
>       DEFINE_PROP_LINK("ahb-bus", MSF2EmacState, dma_mr,
>                        TYPE_MEMORY_REGION, MemoryRegion *),
>       DEFINE_NIC_PROPERTIES(MSF2EmacState, conf),
> diff --git a/hw/net/mv88w8618_eth.c b/hw/net/mv88w8618_eth.c
> index 96c65f4d46..ccb11512db 100644
> --- a/hw/net/mv88w8618_eth.c
> +++ b/hw/net/mv88w8618_eth.c
> @@ -371,7 +371,7 @@ static const VMStateDescription mv88w8618_eth_vmsd = {
>       }
>   };
>   
> -static Property mv88w8618_eth_properties[] = {
> +static const Property mv88w8618_eth_properties[] = {
>       DEFINE_NIC_PROPERTIES(mv88w8618_eth_state, conf),
>       DEFINE_PROP_LINK("dma-memory", mv88w8618_eth_state, dma_mr,
>                        TYPE_MEMORY_REGION, MemoryRegion *),
> diff --git a/hw/net/ne2000-isa.c b/hw/net/ne2000-isa.c
> index 26980e087e..1cd070d419 100644
> --- a/hw/net/ne2000-isa.c
> +++ b/hw/net/ne2000-isa.c
> @@ -79,7 +79,7 @@ static void isa_ne2000_realizefn(DeviceState *dev, Error **errp)
>       qemu_format_nic_info_str(qemu_get_queue(s->nic), s->c.macaddr.a);
>   }
>   
> -static Property ne2000_isa_properties[] = {
> +static const Property ne2000_isa_properties[] = {
>       DEFINE_PROP_UINT32("iobase", ISANE2000State, iobase, 0x300),
>       DEFINE_PROP_UINT32("irq",   ISANE2000State, isairq, 9),
>       DEFINE_NIC_PROPERTIES(ISANE2000State, ne2000.c),
> diff --git a/hw/net/ne2000-pci.c b/hw/net/ne2000-pci.c
> index 74773069c6..12fa579d22 100644
> --- a/hw/net/ne2000-pci.c
> +++ b/hw/net/ne2000-pci.c
> @@ -96,7 +96,7 @@ static void ne2000_instance_init(Object *obj)
>                                     &pci_dev->qdev);
>   }
>   
> -static Property ne2000_properties[] = {
> +static const Property ne2000_properties[] = {
>       DEFINE_NIC_PROPERTIES(PCINE2000State, ne2000.c),
>       DEFINE_PROP_END_OF_LIST(),
>   };
> diff --git a/hw/net/npcm7xx_emc.c b/hw/net/npcm7xx_emc.c
> index 7307a13400..f06e908d04 100644
> --- a/hw/net/npcm7xx_emc.c
> +++ b/hw/net/npcm7xx_emc.c
> @@ -845,7 +845,7 @@ static const VMStateDescription vmstate_npcm7xx_emc = {
>       },
>   };
>   
> -static Property npcm7xx_emc_properties[] = {
> +static const Property npcm7xx_emc_properties[] = {
>       DEFINE_NIC_PROPERTIES(NPCM7xxEMCState, conf),
>       DEFINE_PROP_END_OF_LIST(),
>   };
> diff --git a/hw/net/npcm_gmac.c b/hw/net/npcm_gmac.c
> index 685905f9e2..1db29307d7 100644
> --- a/hw/net/npcm_gmac.c
> +++ b/hw/net/npcm_gmac.c
> @@ -912,7 +912,7 @@ static const VMStateDescription vmstate_npcm_gmac = {
>       },
>   };
>   
> -static Property npcm_gmac_properties[] = {
> +static const Property npcm_gmac_properties[] = {
>       DEFINE_NIC_PROPERTIES(NPCMGMACState, conf),
>       DEFINE_PROP_END_OF_LIST(),
>   };
> diff --git a/hw/net/opencores_eth.c b/hw/net/opencores_eth.c
> index 2c0ebda100..003b452bc9 100644
> --- a/hw/net/opencores_eth.c
> +++ b/hw/net/opencores_eth.c
> @@ -743,7 +743,7 @@ static void qdev_open_eth_reset(DeviceState *dev)
>       open_eth_reset(d);
>   }
>   
> -static Property open_eth_properties[] = {
> +static const Property open_eth_properties[] = {
>       DEFINE_NIC_PROPERTIES(OpenEthState, conf),
>       DEFINE_PROP_END_OF_LIST(),
>   };
> diff --git a/hw/net/pcnet-pci.c b/hw/net/pcnet-pci.c
> index 6190b76916..83ba8cd949 100644
> --- a/hw/net/pcnet-pci.c
> +++ b/hw/net/pcnet-pci.c
> @@ -252,7 +252,7 @@ static void pcnet_instance_init(Object *obj)
>                                     DEVICE(obj));
>   }
>   
> -static Property pcnet_properties[] = {
> +static const Property pcnet_properties[] = {
>       DEFINE_NIC_PROPERTIES(PCIPCNetState, state.conf),
>       DEFINE_PROP_END_OF_LIST(),
>   };
> diff --git a/hw/net/rocker/rocker.c b/hw/net/rocker/rocker.c
> index 5e74acc969..efc20396aa 100644
> --- a/hw/net/rocker/rocker.c
> +++ b/hw/net/rocker/rocker.c
> @@ -1459,7 +1459,7 @@ static void rocker_reset(DeviceState *dev)
>       DPRINTF("Reset done\n");
>   }
>   
> -static Property rocker_properties[] = {
> +static const Property rocker_properties[] = {
>       DEFINE_PROP_STRING("name", Rocker, name),
>       DEFINE_PROP_STRING("world", Rocker, world_name),
>       DEFINE_PROP_MACADDR("fp_start_macaddr", Rocker,
> diff --git a/hw/net/rtl8139.c b/hw/net/rtl8139.c
> index bc56075c0d..064a73b6b4 100644
> --- a/hw/net/rtl8139.c
> +++ b/hw/net/rtl8139.c
> @@ -3410,7 +3410,7 @@ static void rtl8139_instance_init(Object *obj)
>                                     DEVICE(obj));
>   }
>   
> -static Property rtl8139_properties[] = {
> +static const Property rtl8139_properties[] = {
>       DEFINE_NIC_PROPERTIES(RTL8139State, conf),
>       DEFINE_PROP_END_OF_LIST(),
>   };
> diff --git a/hw/net/smc91c111.c b/hw/net/smc91c111.c
> index 180ba5c791..a853c30fa2 100644
> --- a/hw/net/smc91c111.c
> +++ b/hw/net/smc91c111.c
> @@ -788,7 +788,7 @@ static void smc91c111_realize(DeviceState *dev, Error **errp)
>       /* ??? Save/restore.  */
>   }
>   
> -static Property smc91c111_properties[] = {
> +static const Property smc91c111_properties[] = {
>       DEFINE_NIC_PROPERTIES(smc91c111_state, conf),
>       DEFINE_PROP_END_OF_LIST(),
>   };
> diff --git a/hw/net/spapr_llan.c b/hw/net/spapr_llan.c
> index 8af33d91b6..d381c041db 100644
> --- a/hw/net/spapr_llan.c
> +++ b/hw/net/spapr_llan.c
> @@ -786,7 +786,7 @@ static target_ulong h_change_logical_lan_mac(PowerPCCPU *cpu,
>       return H_SUCCESS;
>   }
>   
> -static Property spapr_vlan_properties[] = {
> +static const Property spapr_vlan_properties[] = {
>       DEFINE_SPAPR_PROPERTIES(SpaprVioVlan, sdev),
>       DEFINE_NIC_PROPERTIES(SpaprVioVlan, nicconf),
>       DEFINE_PROP_BIT("use-rx-buffer-pools", SpaprVioVlan,
> diff --git a/hw/net/stellaris_enet.c b/hw/net/stellaris_enet.c
> index 9ebff296c4..4af1afa733 100644
> --- a/hw/net/stellaris_enet.c
> +++ b/hw/net/stellaris_enet.c
> @@ -497,7 +497,7 @@ static void stellaris_enet_realize(DeviceState *dev, Error **errp)
>       qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
>   }
>   
> -static Property stellaris_enet_properties[] = {
> +static const Property stellaris_enet_properties[] = {
>       DEFINE_NIC_PROPERTIES(stellaris_enet_state, conf),
>       DEFINE_PROP_END_OF_LIST(),
>   };
> diff --git a/hw/net/sungem.c b/hw/net/sungem.c
> index 67087e9842..bcc7a18382 100644
> --- a/hw/net/sungem.c
> +++ b/hw/net/sungem.c
> @@ -1420,7 +1420,7 @@ static void sungem_instance_init(Object *obj)
>                                     DEVICE(obj));
>   }
>   
> -static Property sungem_properties[] = {
> +static const Property sungem_properties[] = {
>       DEFINE_NIC_PROPERTIES(SunGEMState, conf),
>       /* Phy address should be 0 for most Apple machines except
>        * for K2 in which case it's 1. Will be set by a machine
> diff --git a/hw/net/sunhme.c b/hw/net/sunhme.c
> index 0e6c655a5b..86f472fcbe 100644
> --- a/hw/net/sunhme.c
> +++ b/hw/net/sunhme.c
> @@ -177,7 +177,7 @@ struct SunHMEState {
>       uint16_t miiregs[HME_MII_REGS_SIZE];
>   };
>   
> -static Property sunhme_properties[] = {
> +static const Property sunhme_properties[] = {
>       DEFINE_NIC_PROPERTIES(SunHMEState, conf),
>       DEFINE_PROP_END_OF_LIST(),
>   };
> diff --git a/hw/net/tulip.c b/hw/net/tulip.c
> index 9df3e17162..f35b58a88c 100644
> --- a/hw/net/tulip.c
> +++ b/hw/net/tulip.c
> @@ -1007,7 +1007,7 @@ static void tulip_instance_init(Object *obj)
>                                     &pci_dev->qdev);
>   }
>   
> -static Property tulip_properties[] = {
> +static const Property tulip_properties[] = {
>       DEFINE_NIC_PROPERTIES(TULIPState, c),
>       DEFINE_PROP_END_OF_LIST(),
>   };
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 6e8c51a2db..4fd1f9acca 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -3985,7 +3985,7 @@ static const VMStateDescription vmstate_virtio_net = {
>       .dev_unplug_pending = dev_unplug_pending,
>   };
>   
> -static Property virtio_net_properties[] = {
> +static const Property virtio_net_properties[] = {
>       DEFINE_PROP_BIT64("csum", VirtIONet, host_features,
>                       VIRTIO_NET_F_CSUM, true),
>       DEFINE_PROP_BIT64("guest_csum", VirtIONet, host_features,
> diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
> index 8aa8c46228..f69547cad5 100644
> --- a/hw/net/vmxnet3.c
> +++ b/hw/net/vmxnet3.c
> @@ -2471,7 +2471,7 @@ static const VMStateDescription vmstate_vmxnet3 = {
>       }
>   };
>   
> -static Property vmxnet3_properties[] = {
> +static const Property vmxnet3_properties[] = {
>       DEFINE_NIC_PROPERTIES(VMXNET3State, conf),
>       DEFINE_PROP_BIT("x-old-msi-offsets", VMXNET3State, compat_flags,
>                       VMXNET3_COMPAT_FLAG_OLD_MSI_OFFSETS_BIT, false),
> diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c
> index 89487b49ba..5a5259150a 100644
> --- a/hw/net/xen_nic.c
> +++ b/hw/net/xen_nic.c
> @@ -555,7 +555,7 @@ static void xen_netdev_unrealize(XenDevice *xendev)
>   
>   /* ------------------------------------------------------------- */
>   
> -static Property xen_netdev_properties[] = {
> +static const Property xen_netdev_properties[] = {
>       DEFINE_NIC_PROPERTIES(XenNetDev, conf),
>       DEFINE_PROP_INT32("idx", XenNetDev, dev, -1),
>       DEFINE_PROP_END_OF_LIST(),
> diff --git a/hw/net/xgmac.c b/hw/net/xgmac.c
> index ffe3fc8dbe..6e0f96f485 100644
> --- a/hw/net/xgmac.c
> +++ b/hw/net/xgmac.c
> @@ -414,7 +414,7 @@ static void xgmac_enet_realize(DeviceState *dev, Error **errp)
>                                     s->conf.macaddr.a[0];
>   }
>   
> -static Property xgmac_properties[] = {
> +static const Property xgmac_properties[] = {
>       DEFINE_NIC_PROPERTIES(XgmacState, conf),
>       DEFINE_PROP_END_OF_LIST(),
>   };
> diff --git a/hw/net/xilinx_axienet.c b/hw/net/xilinx_axienet.c
> index faf27947b0..9d0c618e2f 100644
> --- a/hw/net/xilinx_axienet.c
> +++ b/hw/net/xilinx_axienet.c
> @@ -996,7 +996,7 @@ static void xilinx_enet_init(Object *obj)
>       sysbus_init_mmio(sbd, &s->iomem);
>   }
>   
> -static Property xilinx_enet_properties[] = {
> +static const Property xilinx_enet_properties[] = {
>       DEFINE_PROP_UINT32("phyaddr", XilinxAXIEnet, c_phyaddr, 7),
>       DEFINE_PROP_UINT32("rxmem", XilinxAXIEnet, c_rxmem, 0x1000),
>       DEFINE_PROP_UINT32("txmem", XilinxAXIEnet, c_txmem, 0x1000),
> diff --git a/hw/net/xilinx_ethlite.c b/hw/net/xilinx_ethlite.c
> index bd81290808..9413731d20 100644
> --- a/hw/net/xilinx_ethlite.c
> +++ b/hw/net/xilinx_ethlite.c
> @@ -251,7 +251,7 @@ static void xilinx_ethlite_init(Object *obj)
>       sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->mmio);
>   }
>   
> -static Property xilinx_ethlite_properties[] = {
> +static const Property xilinx_ethlite_properties[] = {
>       DEFINE_PROP_UINT32("tx-ping-pong", struct xlx_ethlite, c_tx_pingpong, 1),
>       DEFINE_PROP_UINT32("rx-ping-pong", struct xlx_ethlite, c_rx_pingpong, 1),
>       DEFINE_NIC_PROPERTIES(struct xlx_ethlite, conf),



From xen-devel-bounces@lists.xenproject.org Sat Dec 14 16:14:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Dec 2024 16:14:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857383.1269687 (Exim 4.92)
	(envelope-from )
	id 1tMUmS-0005lb-9s; Sat, 14 Dec 2024 16:14:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857383.1269687; Sat, 14 Dec 2024 16:14:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tMUmS-0005lU-77; Sat, 14 Dec 2024 16:14:12 +0000
Received: by outflank-mailman (input) for mailman id 857383;
 Sat, 14 Dec 2024 16:14: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 1tMUmR-0005lO-3G
 for xen-devel@lists.xenproject.org; Sat, 14 Dec 2024 16:14:11 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7198eda4-ba36-11ef-99a3-01e77a169b0f;
 Sat, 14 Dec 2024 17:14:07 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 14 Dec 2024 17:14:06 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id 22ACF2C54;
 Sat, 14 Dec 2024 17:14:06 +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: 7198eda4-ba36-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734192847; x=1765728847;
  h=from:to:cc:subject:date:message-id:mime-version:
   content-transfer-encoding;
  bh=VEFsgEhevt+XM4a4qkfzKieZUKI+SayLjdE6l3zq1I0=;
  b=FutX55YtolMQXW+mOtAPJ3n3tSmT70xMjBSTcoevJ5TnjBRUOHdQiKJg
   XLsolFp8eL8h8rQDRoz5+zSt3s61hCziiUVXRThUBJkA+06jQxPeYcDrE
   t5IIQGC7QJOAUZvI49Vqa5VDsjlrj36VBc2oduVUwd6J9h/kw0DnZSk1u
   g=;
X-CSE-ConnectionGUID: 8Zi7OD5dRgeYulB2prfubQ==
X-CSE-MsgGUID: aeY/njpRTF+fBAB6yyJnzQ==
X-IronPort-AV: E=Sophos;i="6.12,234,1728943200"; 
   d="scan'208";a="28182305"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	nthony PERARD ,
	Ariel Otilibili 
Subject: [PATCH 0/1] tools, xen/scripts: clear out Python syntax warnings
Date: Sat, 14 Dec 2024 17:09:49 +0100
Message-ID: <20241214161350.70515-1-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hello,

The series clears out Python syntax warnings. In all occurrences of the re methods,

```
$ git grep -Pn '[^\w_]re\.[a-z]+' | wc -l 
69
```

Where it was needed, the strings have been quoted as raw.

Thank you,

Ariel Otilibili (1):
  tools, xen/scripts: clear out Python syntax warnings

 tools/misc/xensymoops                         | 4 ++--
 tools/pygrub/src/GrubConf.py                  | 4 ++--
 tools/pygrub/src/pygrub                       | 6 +++---
 xen/scripts/xen_analysis/cppcheck_analysis.py | 4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Sat Dec 14 16:14:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Dec 2024 16:14:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857387.1269697 (Exim 4.92)
	(envelope-from )
	id 1tMUn0-0006Aa-Iv; Sat, 14 Dec 2024 16:14:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857387.1269697; Sat, 14 Dec 2024 16:14: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 1tMUn0-0006AT-F6; Sat, 14 Dec 2024 16:14:46 +0000
Received: by outflank-mailman (input) for mailman id 857387;
 Sat, 14 Dec 2024 16:14: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 1tMUmz-0006AH-RT
 for xen-devel@lists.xenproject.org; Sat, 14 Dec 2024 16:14:45 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 876dfd29-ba36-11ef-99a3-01e77a169b0f;
 Sat, 14 Dec 2024 17:14:43 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 14 Dec 2024 17:14:43 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id 272AA2C55;
 Sat, 14 Dec 2024 17:14:43 +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: 876dfd29-ba36-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734192884; x=1765728884;
  h=from:to:cc:subject:date:message-id:in-reply-to:
   references:mime-version:content-transfer-encoding;
  bh=OPZcqoYnos1qDgrzyTEHlZczqYru4m8U1RTFC0EoMks=;
  b=CTcYYxe43Yq4CkNFgi5O+AAzyTFLZdjvZ1jZkElaChMU4fGIwLxkrJq1
   Xr0n7UWjTqjoT1aw4gG6bK2hEBDXewO309V6m+8Z5zyqVh+cIwiZrFOxp
   ne0uql/n1HN5KinjUbhoXgT4jdOakAFbUFsbJPkTvn4sgADtMLTNabLMi
   A=;
X-CSE-ConnectionGUID: K0GWcpOhRWaD/5qqjLPwjg==
X-CSE-MsgGUID: mR7jXJG6TGuWOnWQFTyL9g==
X-IronPort-AV: E=Sophos;i="6.12,234,1728943200"; 
   d="scan'208";a="28182307"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	nthony PERARD ,
	Ariel Otilibili ,
	Luca Fancellu 
Subject: [PATCH 1/1] tools, xen/scripts: clear out Python syntax warnings
Date: Sat, 14 Dec 2024 17:09:51 +0100
Message-ID: <20241214161350.70515-3-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20241214161350.70515-1-Ariel.Otilibili-Anieli@eurecom.fr>
References: <20241214161350.70515-1-Ariel.Otilibili-Anieli@eurecom.fr>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

* since 3.12 invalid escape sequences generate SyntaxWarning
* in the future, these invalid sequences will generate SyntaxError
* therefore changed syntax to raw string notation.

Link: https://docs.python.org/3/whatsnew/3.12.html#other-language-changes
Fixes: e45e8f69047 ("bitkeeper revision 1.803 (4056f51d2UjBnn9uwzC9Vu3LspnUCg)")
Fixes: d8f3a67bf98 ("pygrub: further improve grub2 support")
Fixes: dd03048708a ("xen/pygrub: grub2/grub.cfg from RHEL 7 has new commands in menuentry")
Fixes: d1b93ea2615 ("tools/pygrub: Make pygrub understand default entry in string format")
Fixes: 622e368758b ("Add ZFS libfsimage support patch")
Fixes: 02b26c02c7c ("xen/scripts: add cppcheck tool to the xen-analysis.py script")
Fixes: 56c0063f4e7 ("xen/misra: xen-analysis.py: Improve the cppcheck version check")

Cc: Anthony PERARD 
Cc: Luca Fancellu 
Signed-off-by: Ariel Otilibili 
---
 tools/misc/xensymoops                         | 4 ++--
 tools/pygrub/src/GrubConf.py                  | 4 ++--
 tools/pygrub/src/pygrub                       | 6 +++---
 xen/scripts/xen_analysis/cppcheck_analysis.py | 4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/tools/misc/xensymoops b/tools/misc/xensymoops
index 835d187e90..bec75cae93 100755
--- a/tools/misc/xensymoops
+++ b/tools/misc/xensymoops
@@ -17,7 +17,7 @@ def read_oops():
     stack_addrs is a dictionary mapping potential code addresses in the stack
       to their order in the stack trace.
     """
-    stackaddr_ptn = "\[([a-z,0-9]*)\]"
+    stackaddr_ptn = r"\[([a-z,0-9]*)\]"
     stackaddr_re  = re.compile(stackaddr_ptn)
 
     eip_ptn = ".*EIP:.*<([a-z,0-9]*)>.*"
@@ -67,7 +67,7 @@ addr_ptn = "([a-z,0-9]*):"
 addr_re  = re.compile(addr_ptn)
 
 # regexp to match the start of functions in the objdump
-func_ptn = "(.*<[\S]*>):"
+func_ptn = r"(.*<[\S]*>):"
 func_re  = re.compile(func_ptn)
 
 func = "" # holds the name of the current function being scanned
diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/GrubConf.py
index 580c9628ca..7cd2bc9aeb 100644
--- a/tools/pygrub/src/GrubConf.py
+++ b/tools/pygrub/src/GrubConf.py
@@ -320,7 +320,7 @@ class GrubConfigFile(_GrubConfigFile):
 def grub2_handle_set(arg):
     (com,arg) = grub_split(arg,2)
     com="set:" + com
-    m = re.match("([\"\'])(.*)\\1", arg)
+    m = re.match(r"([\"\'])(.*)\\1", arg)
     if m is not None:
         arg=m.group(2)
     return (com,arg)
@@ -402,7 +402,7 @@ class Grub2ConfigFile(_GrubConfigFile):
                 continue
 
             # new image
-            title_match = re.match('^menuentry ["\'](.*?)["\'] (.*){', l)
+            title_match = re.match(r'^menuentry ["\'](.*?)["\'] (.*){', l)
             if title_match:
                 if img is not None:
                     raise RuntimeError("syntax error: cannot nest menuentry (%d %s)" % (len(img),img))
diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
index 9d51f96070..58b088d285 100755
--- a/tools/pygrub/src/pygrub
+++ b/tools/pygrub/src/pygrub
@@ -614,7 +614,7 @@ class Grub:
             title = self.cf.default
             while 1:
                 try:
-                    title = re.search('(\S)>(\S.+$)',title).group(2)
+                    title = re.search(r'(\S)>(\S.+$)',title).group(2)
                 except AttributeError:
                     break
 
@@ -1039,7 +1039,7 @@ if __name__ == "__main__":
 
     # if boot filesystem is set then pass to fsimage.open
     bootfsargs = '"%s"' % incfg["args"]
-    bootfsgroup = re.findall('zfs-bootfs=(.*?)[\s\,\"]', bootfsargs)
+    bootfsgroup = re.findall(r'zfs-bootfs=(.*?)[\s\,\"]', bootfsargs)
     if bootfsgroup:
         bootfsoptions = bootfsgroup[0]
     else:
@@ -1104,7 +1104,7 @@ if __name__ == "__main__":
     if chosencfg["args"]:
         zfsinfo = xenfsimage.getbootstring(fs)
         if zfsinfo is not None:
-            e = re.compile("zfs-bootfs=[\w\-\.\:@/]+" )
+            e = re.compile(r"zfs-bootfs=[\w\-\.\:@/]+" )
             (chosencfg["args"],count) = e.subn(zfsinfo, chosencfg["args"])
             if count == 0:
                chosencfg["args"] += " -B %s" % zfsinfo
diff --git a/xen/scripts/xen_analysis/cppcheck_analysis.py b/xen/scripts/xen_analysis/cppcheck_analysis.py
index 850335c998..ce7bda91b6 100644
--- a/xen/scripts/xen_analysis/cppcheck_analysis.py
+++ b/xen/scripts/xen_analysis/cppcheck_analysis.py
@@ -93,7 +93,7 @@ def __generate_suppression_list(out_file):
                         # start of a comment '/*'
                         comment_line_starts = re.match('^[ \t]*/\*.*$', line)
                         # Matches a line with text and the end of a comment '*/'
-                        comment_line_stops = re.match('^.*\*/$', line)
+                        comment_line_stops = re.match(r'^.*\*/$', line)
                         if (not comment_section) and comment_line_starts:
                             comment_section = True
                         if (len(line.strip()) != 0) and (not comment_section):
@@ -157,7 +157,7 @@ def generate_cppcheck_deps():
             "Error occured retrieving cppcheck version:\n{}\n\n{}"
         )
 
-    version_regex = re.search('^Cppcheck (\d+)\.(\d+)(?:\.\d+)?$',
+    version_regex = re.search(r'^Cppcheck (\d+)\.(\d+)(?:\.\d+)?$',
                               invoke_cppcheck, flags=re.M)
     # Currently, only cppcheck version >= 2.7 is supported, but version 2.8 is
     # known to be broken, please refer to docs/misra/cppcheck.txt
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Sat Dec 14 17:53:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Dec 2024 17:53:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857415.1269707 (Exim 4.92)
	(envelope-from )
	id 1tMWK6-00013Q-FY; Sat, 14 Dec 2024 17:53:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857415.1269707; Sat, 14 Dec 2024 17:53:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tMWK6-00013J-CH; Sat, 14 Dec 2024 17:53:02 +0000
Received: by outflank-mailman (input) for mailman id 857415;
 Sat, 14 Dec 2024 17:53: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 1tMWK4-00013D-Dz
 for xen-devel@lists.xenproject.org; Sat, 14 Dec 2024 17:53:00 +0000
Received: from NAM04-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam04on20623.outbound.protection.outlook.com
 [2a01:111:f403:240a::623])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 401a9a1d-ba44-11ef-a0d6-8be0dac302b0;
 Sat, 14 Dec 2024 18:52:58 +0100 (CET)
Received: from DS7PR03CA0190.namprd03.prod.outlook.com (2603:10b6:5:3b6::15)
 by DM6PR12MB4369.namprd12.prod.outlook.com (2603:10b6:5:2a1::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.20; Sat, 14 Dec
 2024 17:52:53 +0000
Received: from DS3PEPF0000C37C.namprd04.prod.outlook.com
 (2603:10b6:5:3b6:cafe::88) by DS7PR03CA0190.outlook.office365.com
 (2603:10b6:5:3b6::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.17 via Frontend Transport; Sat,
 14 Dec 2024 17:52:53 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS3PEPF0000C37C.mail.protection.outlook.com (10.167.23.6) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Sat, 14 Dec 2024 17:52:53 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) 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; Sat, 14 Dec
 2024 11:52:53 -0600
Received: from [172.28.102.118] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Sat, 14 Dec 2024 11:52: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: 401a9a1d-ba44-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NBGAog0ymk1ioMUUWeffVZr/aIe6ItSRtlAi+si4M8mBatp42UGNVYHvlOUIRER+HNR54mYPoMxDHHXKip1InKPbYs/J76av3Y9bAu2e+7AqpJMENGDe5eEe2FGibkRZupPSz0Vz1rBW/BGBhwRuy2kYvrXTyhoLjl4x1495EFg3Sfu9e27+z9k2ViDC4+0dN5Lm8KvSNiL52RfL1wbvd4QIC4yHra5oLcx/fr62qQ5QzJMVaXSf52g1qsk5OVxpcvICNdq7h6u+73j4/zBgmBh13I2xJco3ibFVpNoaaj9lJIyHARsu94R+9Xg7Nh0avrmqdVeJ5rWNQWTbaVSQtg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=M2Tw8JOIgOMGYEnHFbaXyteUataF//cgg6h4wb7QKPk=;
 b=P7QF5nnrFRRfFxpr7UfiAMSPqNYg0JzS5jfbL1MopVhxUR1eNCD6MvjSFXCfMu2tOJxHRXQRBApdT8W4B+8f83tt4okDqGSM6yva2z+sv3Js/6QoSAhDT+zyUgsoXfSAEDvj3ajDHEtY92hVDp42JaujnYMirQ1QS2VItYX9XoCjJjVbOLdgGY5xdn3OCQrMIwlBy6Nw4yfpFGis+4wDqmGrodFBTDqEe1FBC8YXm5R9f+I45+vMg9Yiba10jCfCQoa9ZLAPVD4UuB8pAi3IBPM7jVU5efSAGJ0RwD+7Engwbf5Wk9NmEeN4tugqr/1I3Yx6lg0ySfcCkHYqTK2AOg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=linaro.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=M2Tw8JOIgOMGYEnHFbaXyteUataF//cgg6h4wb7QKPk=;
 b=EoqwrK+aoq6u80MSUeqGYPET1Wk4reAT8UYyB0lruAGdJApx6N+f3CFcxf90/kqfhIoP5VBmWrGEqsG1iOAXKqqrb5naDAF1lhm0N60AERVuLhDoMldtt/z7lLIC+wsIiKWWheTFYh5jSQMs+pTcvMjT1upD4T3CLPuwIV3Ehbw=
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=SATLEXMB04.amd.com; pr=C
Message-ID: <0eab7b25-87a0-4e08-bf59-aea64136052f@amd.com>
Date: Sat, 14 Dec 2024 12:52:50 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 18/71] hw/block/xen-block: Unexport PropertyInfo
To: Richard Henderson , 
CC: Stefano Stabellini , Anthony PERARD
	, Paul Durrant , "Edgar E. Iglesias"
	, Kevin Wolf , Hanna Reitz
	, "open list:X86 Xen CPUs"
	, "open list:Block layer core"
	
References: <20241213190750.2513964-1-richard.henderson@linaro.org>
 <20241213190750.2513964-23-richard.henderson@linaro.org>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20241213190750.2513964-23-richard.henderson@linaro.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS3PEPF0000C37C:EE_|DM6PR12MB4369:EE_
X-MS-Office365-Filtering-Correlation-Id: af7e0e21-2609-475d-84b2-08dd1c682287
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|1800799024|36860700013|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?dWVOSXlYT1Z2QkEvZHVJN29XOU1YVVNyRVBUdGhlWnByRFpFTHJPM3laM2FC?=
 =?utf-8?B?T2x3bE5KdVk5bW1IN0p4QmtkRUoyNXNRL3o0Q3NzYjBhQks5RkErbWxOS0lI?=
 =?utf-8?B?am01OGVtOXFPTnZERVhvbWdjT1VERE00ZDJwUFRoYkxYa2pYcDBkZFZ2cDlT?=
 =?utf-8?B?ZGJRSmhPc0xDZkNNemU2YVFmQ0tTTnBvOTFlTWh6VHVYWndoTFJxOERJTCtz?=
 =?utf-8?B?b1ZzLzNGTHNXYVdCbmR1NG01V2gxRG1aMllnVG5VWDRFd2xLZFpUQzVvUjN5?=
 =?utf-8?B?blV2d3JpeWFDTk1HVFlnTUZRaXBOaXJqR2N1SHdLOER3amZNYVlIaWE4YkRo?=
 =?utf-8?B?WHJKdnQ4UFg2SHhZWTVwZkNVeUU2R3BxQytuSE9vY2VlSTdGU3grVjVLZmw0?=
 =?utf-8?B?aFAxMmxSa2ptQ1IyeHcxQkJyL2dxT2R3aFlxZDlVRS8rL3ZRUWtKMUtwR2hH?=
 =?utf-8?B?c1dCcVRURWc2RllvQVhUSDRsRC9Tc2NvektuQzR6ZXVCcHc4NXZBWFV0cGtS?=
 =?utf-8?B?VENjTUs2ZkE4Z2c2T1A4elFUSnpOa2trQVJtQU1LWnJjSGNESDR1R3ZuV2NQ?=
 =?utf-8?B?TERNQldLbE01YU1QdkRjVERlYWJFdzRwdng4bFgvS3FvTTVVWmFBaTl2MVRn?=
 =?utf-8?B?ZFpaQU4zS3JLMzJIcTVCVE51a205MEIycTBkellKdmhDRXZsNk5Ic3Nna0I3?=
 =?utf-8?B?cU9OcDZsZWM2UGRCVHJ4dkUvSUdWWHVjRm5ndEg0SlVEQ1BtSEFQYURrbUkv?=
 =?utf-8?B?WDlGSE5tRE9aYXlKdk1uVzE2bXNpUEIrakkzZDhlMVhjZ2VDMFBYeCtkS0RS?=
 =?utf-8?B?ZGdxWjY5NDN5VVN5c25LNjBmYjc0MnUwOUM4dDlLdXIxbzQzeUtEbkgxL1ov?=
 =?utf-8?B?Mlp6M0sra3NvdGExbTcyU3dnYU9rOE1EWXh6aXE1Ujl4Mkl5QWlJUWZQaFVN?=
 =?utf-8?B?SXRsMkliTmxIWXpsVENPc3BBOFBxcVdmZlQwSE9TMkovWGdJbUdLdEdCelFm?=
 =?utf-8?B?ZUsxN3dBRjkxUzIyVEpWZXo1NmNEdUQ4K0VtdE5CVWpET0xEK1RaMW84SGc3?=
 =?utf-8?B?QjgrZkVScjAwV2EyUGZtcW1rU203bmorVVhza0gvaFora1lhYjYzZm5sL2Nk?=
 =?utf-8?B?WUV5WFNNV2grVjFrdG42aUJYNDYrSGZQbEtwaVhhampleEZweHhWYmZadldz?=
 =?utf-8?B?ejhXRkFuSUo1SmtFdXZyZTJGNU9aTnJUTmxjcWoweFVPbDgrMHV5T0tpNTlO?=
 =?utf-8?B?c1o1dUxBRFFnUC9YU2puVEZhckJaUVYzRXJpYlZCdVQxbkdqU0FKckxhbElo?=
 =?utf-8?B?UzIyZVdza2xPajhrREU4ZHJaWTM2NEFZSHlxMTdqODJBb3F4cHpCdEp0YUk3?=
 =?utf-8?B?QmpIVjE3ZnVMWDN2STltR3htYWVhcGt0VGtNLzhMbmpVUW9SYmEyM01sZFRH?=
 =?utf-8?B?S3RDeTczTGx1c1lybmN6SjVtbm9CbHFjMWhVOW5xSFlEbm9MakM1R3FuMnlR?=
 =?utf-8?B?c2pXenIyMi94QWJFNDNiSjBMejNVcGVLL21CUDBOajAvVkhWelNEUVIwTWVy?=
 =?utf-8?B?WFlwU1IxOUlGMjlzMXlwSXNodW9kdjluN0drVGNlVlpabGlRTGVBSzlkQWV0?=
 =?utf-8?B?OFJmRGJiaXZXSFV2eDNadjhHQnhuZVJMdC9PQ1pDc0Q5WHROWHNWZkVRd3h4?=
 =?utf-8?B?QUJoSVpoNzFzU3YveGp6bDlVS1RUZk01T29sRGhJZVJRK3hGVTI4WTVHUThq?=
 =?utf-8?B?a0hkZnFXWUFma2N6NlZXSlBuVkhHbi8zM0VXaGVHUEVwWjhOWHpObjlWbjI0?=
 =?utf-8?B?RVQwQlVsNjRaWlJNempZYkM2NUtiNEt6UHorWmFkN0hmZGMxZGh1SUswd1Ey?=
 =?utf-8?B?SzdlU25PRGpYSlJCNU5mMGd4K2ltd1I3RG9UdXFRUG5oWVZwT0RqVGs1eTVC?=
 =?utf-8?B?KytJczBlWUpmckJ6TEI5NllJcm5Yb2RnTGsyTGFIb0loeGtyWXhSWFpVYkt1?=
 =?utf-8?Q?pac5Gsk3JmanAv4G/DZ3jjxBOpUKrU=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(36860700013)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Dec 2024 17:52:53.7024
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: af7e0e21-2609-475d-84b2-08dd1c682287
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS3PEPF0000C37C.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4369

On 2024-12-13 14:06, Richard Henderson wrote:
> xen_block_prop_vdev is not used outside the file.
> 
> Signed-off-by: Richard Henderson 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Sat Dec 14 17:54:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Dec 2024 17:54:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857422.1269717 (Exim 4.92)
	(envelope-from )
	id 1tMWL6-0001Yw-Oz; Sat, 14 Dec 2024 17:54:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857422.1269717; Sat, 14 Dec 2024 17:54: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 1tMWL6-0001Yp-Ln; Sat, 14 Dec 2024 17:54:04 +0000
Received: by outflank-mailman (input) for mailman id 857422;
 Sat, 14 Dec 2024 17:54: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 1tMWL5-0001Yj-LB
 for xen-devel@lists.xenproject.org; Sat, 14 Dec 2024 17:54:03 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on20606.outbound.protection.outlook.com
 [2a01:111:f403:2009::606])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 66269740-ba44-11ef-99a3-01e77a169b0f;
 Sat, 14 Dec 2024 18:54:01 +0100 (CET)
Received: from CH0PR08CA0008.namprd08.prod.outlook.com (2603:10b6:610:33::13)
 by CY8PR12MB8067.namprd12.prod.outlook.com (2603:10b6:930:74::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.19; Sat, 14 Dec
 2024 17:53:57 +0000
Received: from DS3PEPF0000C37E.namprd04.prod.outlook.com
 (2603:10b6:610:33:cafe::95) by CH0PR08CA0008.outlook.office365.com
 (2603:10b6:610:33::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.20 via Frontend Transport; Sat,
 14 Dec 2024 17:53:57 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS3PEPF0000C37E.mail.protection.outlook.com (10.167.23.8) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Sat, 14 Dec 2024 17:53:57 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) 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; Sat, 14 Dec
 2024 11:53:56 -0600
Received: from [172.28.102.118] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Sat, 14 Dec 2024 11:53:55 -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: 66269740-ba44-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ukekAscJmRLHJCKnwmsXpMTpcrB5qGmjXxuzgl1yBKhxYlPZ1sdYxAFiff9fbxAs0QRy/08W44gieukreyqstD7mDGyMNODm9Xk1OAATL3FDQAQp0abY8yv8mwgi7VyhErYCBDdNi63g9oVR86Kpj0SAc926Q/4mkNdo1pMFi1lLjteoVWFUcu/NBxQQNRkKnffI8E9MADInLKFg6Wbfj4c/9fH7jvb8/rwoX0jVhBzd5uDxPKJZvm1DDly7BrKCfwb/FNXjbCnHLXqiwqS5dF5oBtyB6HpPSMh3prkuI6qhFA9NI3KT1hjbxyDMGbuxgbaPODGY5gX6++7tiad1FA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=0GnafECtgxI2eDydWJ5XeykP2Zok967VY/jGtFS4mds=;
 b=dqCip/OqZpHBx54euI/FYHbVJ6udR2PO1CJqYNjf2kxgGeVxWCWLRHHwE/s0gfy22o4BO7S4WHLWnQ56ibsx3rp3vR2VuZt3Lz1mlHUOhyYX90Szd1d0qVBDJqtSjVogQmULqzc0KYl9OCrArPxxdj8pYBOBO9NPo6FBuCTtnW3zJCLCvgk5avzptgHhIx6JCOwYxt8TMDqG99in9dZCcDoWZCVzkyi26DoTlhoWP2mDG16JUlBbhAKKhM3OCv1J/CSVi2nS9RZCSPx1he1OlkwF4KIywLfU4wM93jNGiIchOOVcOlNKimCjrT/VFPftG9Nuz3rKevotu6kXjfHU1A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=linaro.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=0GnafECtgxI2eDydWJ5XeykP2Zok967VY/jGtFS4mds=;
 b=bBQpmvyG+ZrRGnA8AmSdpu+GYP0Txu4G+jAzs0lO/J5Pdq2sk79lVqGhONLaExiajcYpfN3Q5QP/lE+IOT5O6MSK9Gma2iTfxtKjV+3Xk/Akvjsn2aPl13ZxG56HFnK/WrPHwW1ennM4sHVuzLyWBeLFmQr+c9xjF0JxmHldRdo=
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=SATLEXMB04.amd.com; pr=C
Message-ID: <981a2c50-c82a-40e0-a45c-783696a7bdef@amd.com>
Date: Sat, 14 Dec 2024 12:53:55 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 68/71] hw/xen: Constify all Property
To: Richard Henderson , 
CC: Stefano Stabellini , Anthony PERARD
	, Paul Durrant , "Edgar E. Iglesias"
	, "open list:X86 Xen CPUs"
	
References: <20241213190750.2513964-1-richard.henderson@linaro.org>
 <20241213193004.2515684-1-richard.henderson@linaro.org>
 <20241213193004.2515684-6-richard.henderson@linaro.org>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20241213193004.2515684-6-richard.henderson@linaro.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS3PEPF0000C37E:EE_|CY8PR12MB8067:EE_
X-MS-Office365-Filtering-Correlation-Id: 6769f826-ff98-4d25-849a-08dd1c68487f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cFZNKzZjWFJDNlByS0lXU2cwUGtrK1E1emVKWHE4RWlXbk1qNjRuSW1DOFFJ?=
 =?utf-8?B?SVliVk1BRkJ4MStaeHRnWjZVdk1KdTFabG1GR2RCUmh6NzJpQmVOS0M2SkxI?=
 =?utf-8?B?cUdocGxCbks2Nk00T1dMRFd2K1FFcGFXWlRUYnkrYTQxbnNFMU1LYlh4eVhk?=
 =?utf-8?B?ZDR4RkJITkhzZDVsbXBDMHhDdnBGcXU1c0hyYm83SS9QWGd5QXYxTWEwNVE5?=
 =?utf-8?B?VnhGT3BVczZGZm1IRHdlZzdJMGthNnhHcjFabXlCMHUvQVp4WVYzbHFDRmV5?=
 =?utf-8?B?SnpBNVNjWFdndlFVTXRMRStLUzhCcXp2Z1pXVzhZeUNwMHJaT2Vhek5kNjdI?=
 =?utf-8?B?TmJ1c05iVzkrVXBJUEQ4Q3Bsamt2SERnbEZYU3BlZ1Q0ZjIvaUVFcG1XaWQ3?=
 =?utf-8?B?OGxac3UzYjBNM2lsUFpTeDdXRi9xUUE2cFlzUVZrNDgwOXRpTW9GVUphSVRS?=
 =?utf-8?B?RWc4YUJsTmV4ak5LSzJ2VFBxcFBSTFlIRGE2OGdlWWZXc0Q4NkJzV2Vaem1N?=
 =?utf-8?B?TS9qcEdRVDYxb3ZrL3gvTmRLNDY5eEg4UGRDREp6aTJDRHg3TTVnR3FRY1Nr?=
 =?utf-8?B?d1pGR0VGTVN4M3VKYko1YitoSjFSb1ZNa3hzOXcwZDVLY3ZqZVdHRWJMeGZ2?=
 =?utf-8?B?ZlQrTU1XbWw0TE9ORmwrNUxYbyt5UVN3WDI0VXF4LzBPcC9kWml2WXJjb3NK?=
 =?utf-8?B?bjd5b2Jib2ZSemhHS1JHWGxhSXlWdUNzSWZCTlRFMmNXUVpjRlE4ZTNJVWg0?=
 =?utf-8?B?ek43eVcweHgwTTNSUHYyWDVGQlorc0FKeEEzcHF4L2lPR0Z2a1pRenQvMkFT?=
 =?utf-8?B?WEU2dzJHV2t5VTRkWVJGazFWazh2UFhhNU5xaldQa3MwamRPenFDRmtEZVE4?=
 =?utf-8?B?VWF5T1dSQWMvazZRL0RvNHNMdVdKbnphV0FDRFdFUW15SzExcDhuUTNoalU1?=
 =?utf-8?B?SFRTd1gyT3dYckdWS2xMQzR2L05UUk15Y1I4T2RHY2cxbStiOTF6QVRkSnht?=
 =?utf-8?B?N3FMTVc1UVJlQWpsRHpVRG9uVEs0akN4bmx3TytXTkZ6L3RuREZhdjlnRzdQ?=
 =?utf-8?B?cXZObW0yUE45V2E0cHdEQ3lJNU5xQk1YNTk5UlBjRldHbTFaR2dQQngwRUE3?=
 =?utf-8?B?bkpKdEloR0Q3WkN5VjdSUU5yZWxRNkRpc2gzRmp1NXpQYkVzVjEyTkVPdFk0?=
 =?utf-8?B?dldTaS95ZzVDUDBTV245MDhTTGUrUnlpak9xYTJJWUJjMkluQ0Vla3pncHlF?=
 =?utf-8?B?bnBQeGNmekZHVkw1WTM5aUU2UmkxQnlhTWZDQkgvOTlwekNaQTg0S3hWbDNY?=
 =?utf-8?B?UDdwNHhJZXBiNklTL1FmSzNkejFTMnNxSkxiR0JIdUxlOEJtczFqSFg0dFBH?=
 =?utf-8?B?bXRZeW05L05PWDBJdnZnRitTdDBHalZhYXU4ODBuSDR5dXZIUVlvSUJ2OU5v?=
 =?utf-8?B?ZG80QktaSnNETDBHU1J4UitjaE96VzQzYUNsS25NUEFGU0dYVTdpV3VtOTA3?=
 =?utf-8?B?VmpmQzVQM3RjcEY2UXgrZkdOQnhIeHp2cThYZXp0V1dEMnBkZEp4OHU1enZP?=
 =?utf-8?B?Tnk3aDQ4TE1jY1dTczRvTzU0a09tN3RYKzExeGQzaTF2bHFjcUtXZXpmeWhI?=
 =?utf-8?B?bXFlR3VzQkd5bHRCd1dVSVE1QlFtcGM0MDBGNGEvRzdkcklvZms2bE5JMWY1?=
 =?utf-8?B?QitGZGx1S3ViSm1zSmF1dmo1OVB1a1paS0ZsTDAvZ2lVcWp5WDlWRnU5RjdX?=
 =?utf-8?B?WGxIZVFFOGd2YVJXQzFSQVpxSmx2Q2tpR3RkQXBCSk1wVTczM1JpSzY2cGh1?=
 =?utf-8?B?RUowY3EzclZ3NkpPVjBDczNuTWxFVkdsWGF2Q2VES2JzbXdvOVlnY1dlTm9Y?=
 =?utf-8?B?ek5LSkpIMmlZbXMzcW9TQm0vN1N6UGVsZ25NK3YyVFIyQ0tlY29hNlpiWTJs?=
 =?utf-8?B?TVRxempSbUpXVG5WOTBsRGhZanJ3aytlOEJVcVh3TTkxRDBBREJ4VU9CVkFX?=
 =?utf-8?Q?nvUebqZbVdL3GL/+Kwo0wicEm5OqLQ=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Dec 2024 17:53:57.4034
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6769f826-ff98-4d25-849a-08dd1c68487f
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS3PEPF0000C37E.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8067

On 2024-12-13 14:30, Richard Henderson wrote:
> Signed-off-by: Richard Henderson 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Sat Dec 14 17:54:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Dec 2024 17:54:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857431.1269727 (Exim 4.92)
	(envelope-from )
	id 1tMWLj-00027r-54; Sat, 14 Dec 2024 17:54:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857431.1269727; Sat, 14 Dec 2024 17:54: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 1tMWLj-00027k-2J; Sat, 14 Dec 2024 17:54:43 +0000
Received: by outflank-mailman (input) for mailman id 857431;
 Sat, 14 Dec 2024 17:54: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 1tMWLi-0001Xu-5s
 for xen-devel@lists.xenproject.org; Sat, 14 Dec 2024 17:54:42 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2062f.outbound.protection.outlook.com
 [2a01:111:f403:2413::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7ddc30e4-ba44-11ef-a0d6-8be0dac302b0;
 Sat, 14 Dec 2024 18:54:41 +0100 (CET)
Received: from BN9P220CA0018.NAMP220.PROD.OUTLOOK.COM (2603:10b6:408:13e::23)
 by IA1PR12MB6459.namprd12.prod.outlook.com (2603:10b6:208:3a9::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.15; Sat, 14 Dec
 2024 17:54:37 +0000
Received: from BN2PEPF000055DF.namprd21.prod.outlook.com
 (2603:10b6:408:13e:cafe::4f) by BN9P220CA0018.outlook.office365.com
 (2603:10b6:408:13e::23) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.17 via Frontend Transport; Sat,
 14 Dec 2024 17:54:37 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN2PEPF000055DF.mail.protection.outlook.com (10.167.245.9) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8272.0 via Frontend Transport; Sat, 14 Dec 2024 17:54:37 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sat, 14 Dec
 2024 11:54:37 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Sat, 14 Dec
 2024 11:54:37 -0600
Received: from [172.28.102.118] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Sat, 14 Dec 2024 11:54:36 -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: 7ddc30e4-ba44-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rY3ew6M64TBE0L3g4xq8PczDQyR3+AAdI2R4RkNQRQ5dHC/P67XJv2i5jWab8sWv2GsYRnRysE8LzgcoczGLmUNvpjbTz3qTOwlNaSRQS2QAroorOoHjjWwwXQdnHdrNVHcm1sH6jWRQ6IlkHhaKjJyuEAir/M2WVWR/trfiRVCdUasXDnrKEIgJhTdGD5KEU6+woKsLa3bFZ/BJC6+EsuG5UayAsJ0QN7kB68oQ9AmraF+G7BMVI1T6yelLf7Nystk4l7bP9j8Opx5esUrLO00rEMvAlHVscDhrXznPE8NDbaLp3qfvhND5IbeycTdUeo8ef7MS6TCF7q1OkIC1iA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=0GnafECtgxI2eDydWJ5XeykP2Zok967VY/jGtFS4mds=;
 b=WTh6sNikz7H2Yt8j1j2plFqQ19J7e9dzbgd4Ovi2pM8Pg6M1BPPfHSz2iZaq3p11n+N6Lgp/XvowH3Jn69a0Qtn16YlgRjk1EL5rbwHQQuKnw9y1M8+UbOYQ9d89fx3LCo+zTeGujLZo0VCXBVUZ1BsFWTy42ctDxb8VDw7GKtJtU0xX24MA2z/FY39agAvcNTFeIn9KTR83BkiPNe131wBLFFSiv57giNMzrW2lHLjkLXiLDYNk0vPztjs184Im6TIefX80dYlrYIgmSWANuNwweWktVHz066W4BlHff1bfiPjCC6x6eUJkS/QuCaoA/EhXGpeiglBvP7m1+3q54A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=linaro.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=0GnafECtgxI2eDydWJ5XeykP2Zok967VY/jGtFS4mds=;
 b=HEeuj9e7v6W5qv15kO5QmQ0TYt6Q1feE3AQNTmXhlv4b/FYEJVyjGnTeHLU+ZRiwzCCXJEXW4N+WF+NslHBU3K+eTPQDmQexEuYajo9z32JccNH03V02pRXv7wm6ePgh0bQUjk89x7PTpFeNz4c8tbksAM5okKKJtyxgDh6G1nM=
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=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Sat, 14 Dec 2024 12:54:35 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 69/71] hw/xen: Use DEFINE_PROP_END_OF_LIST in
 xen_sysdev_properties
To: Richard Henderson , 
CC: Stefano Stabellini , Anthony PERARD
	, Paul Durrant , "Edgar E. Iglesias"
	, "open list:X86 Xen CPUs"
	
References: <20241213190750.2513964-1-richard.henderson@linaro.org>
 <20241213193004.2515684-1-richard.henderson@linaro.org>
 <20241213193004.2515684-7-richard.henderson@linaro.org>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20241213193004.2515684-7-richard.henderson@linaro.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000055DF:EE_|IA1PR12MB6459:EE_
X-MS-Office365-Filtering-Correlation-Id: 1a0cc2cb-cfae-4cdf-4bb0-08dd1c68608a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?eEpta0lCZE1YTGlseTBwZGdjM1BmVlBJRXNzUTQ1Rlo0c1JLZnpYQUFDV0xp?=
 =?utf-8?B?TWdWclFDVW5RMEc2MUcwWk5rbU5MbmRKanlNU3UvSWlqVTZ0aEljZjA2V3lD?=
 =?utf-8?B?dlFkUlhtQldTeE1KQTJEdFdBZEc2VHAxaVBaYkNRbkhacElPcEpPNlJxQXZV?=
 =?utf-8?B?WnNTbUpQTVl3QmZ6TDRMZG9wWExqYnFoOW5xYkRrY1BNbDJMNGJMSWpwbHk5?=
 =?utf-8?B?YWdkU0wzSjJTLzJOVnoxd3lkN252ZVpoVWk0VXZhaUxIL0kxVTZoUXVaS3ht?=
 =?utf-8?B?ZTdJdWl5UWpmZ0t3emJreEZXWTlndTVielhUTTVObVpzbmVQN1duL3pBZmdy?=
 =?utf-8?B?VC92N21weXFWQzlWNkdLSENMWlZGb2VBc2pINGp1RkVsMFdsRlZDbzdROTVq?=
 =?utf-8?B?L2xXS2Rad0FDYWtweDQraExtemx0R2FiTzBWbFEzRkJQWkJBNXJ1ZVNEekhW?=
 =?utf-8?B?ZE5SZUN4RWFqak5SbklTS1BXZHFpVTZQVWlXaUw5dk84UVJJUE1BbFpRMTF0?=
 =?utf-8?B?dEtEYzBtbCsrTyswVWUwOXljbitPOTBESktEL015Z3MvQ1hLenQrYm01aHZl?=
 =?utf-8?B?Y1VHaWJqd0NpczV4VzhrN0FJcjA2WWgvRkFSOEtKNUpzaHBxUWZTV3BBWFVM?=
 =?utf-8?B?SVpsdWw3emFMWnUwWFh4dndBbVFIU09WSG11eE50VXNnU2FTd2dFMkcxSTZL?=
 =?utf-8?B?aDdWU0o0a3oxOUc0U0VsRFpYKzVNNVNUSEcvclZPUXgrN0c1NjFyZW5rOWIw?=
 =?utf-8?B?L1QyTVV1KzloV0NyZnBydW16RmVuRklvcVVibElpTllWVHpDVDFSQmZkTGho?=
 =?utf-8?B?RFhLQWptaEd4RE9uSDNBNHVlSkhla1lCYzdybTZPa2Q3Q28rNER6TUJoNFJn?=
 =?utf-8?B?cFpiejVsQUY0S0Fkc1VEWUZTeVNJTm1rTGdONlhOVWthZzBsUkFQNG10SFpQ?=
 =?utf-8?B?Q1FxdllUck9xZVArOXpHeXNNc29JbGtpclc5eVFRdjlrSURMSWUvMlNtZ0Rk?=
 =?utf-8?B?TXBqdW5oKzN3TkZCalRkR1pBUnU0Q05VRWc3WGZ3QzBEWXNLcWh2akUwbmM5?=
 =?utf-8?B?N0FTeFlSeWwwbEwzSXNDN0llZXJXdk1PWUZoOWxZL0pUSkxkTUlTSndGV1Fo?=
 =?utf-8?B?ckkxTHMycTZ3SVZhRHFmdDBCcUVwZCtOaWRDZ1B6Nm5zS05Fb0hrN1ZmeUFr?=
 =?utf-8?B?UkRjeDZ6R3hFRWxkVTlOSWJMcnZLYlpwZFV5eEpmbC9GVDlTTWRZUUcwZDQ2?=
 =?utf-8?B?VDMwRVkybkZ5UU8yTWlvMVBOeE9CZWplKzFTVExVZTFmTXNheEpaMWZGVUh0?=
 =?utf-8?B?dWlrd1BZTW5CTjF3MlNqU056WXN4WEFQSnhxelYwbHJuWnlZbXN3TVpjRXA5?=
 =?utf-8?B?QWJnaHhaQkYzYnVYaVhtWFdGV250UjY4R2JWQzkwdzM3dkJzdlZncUxIeUFG?=
 =?utf-8?B?WkF1TTZ3blJ6Y1Y3bmFxSjh4MG0veVFFWkxYMVNsZllac2tDclB4K0lnbFZU?=
 =?utf-8?B?WDhzWXJzN0g3eFU0bFhqdzlpcWxGejF0UldTUi85cGJJdmpVTVBiYU9vNjV1?=
 =?utf-8?B?NkZmYjBRbE5DcmRsYnZlWnV3aWp0SGYyaWJNY0x3Q1RoVFk5MHRYcExIanRz?=
 =?utf-8?B?ei92UzhCaHpvemk4UFl1QTBaR09YYlRJRzJwV0R5N0NBRzZyVlhNNUg0S3oz?=
 =?utf-8?B?QWpGQ2RrZWNtek5zenRBZFEvWndGTklaR014d20yU2lxMmN6d0dJOXFaY0JL?=
 =?utf-8?B?T01OSXIwRTluQ3JsQ1p3ZzJKSXJWOHNRZGFNVkRpK0YrUm5JYmxWNVZVWkg3?=
 =?utf-8?B?eWpBVm9FcFRHTnRrSTJrTTBDQkhYK0pRU2tyNmNlcG9keDR4OEZTajk2bXdF?=
 =?utf-8?B?YW1xbmgxTXZ5KzBqZjYram1hVGpEQjl2QlJYd2JtdTBQTVI1dHhKNnVDUTVz?=
 =?utf-8?B?eDBKOUZSbXV0TmdySmw0NDRjN2M5cXpzNmRuem93VzNBMmNySmhldVh4WHUy?=
 =?utf-8?Q?8Mw47UrbQdOKlS8snLWTjXWSZVGmE8=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Dec 2024 17:54:37.7549
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1a0cc2cb-cfae-4cdf-4bb0-08dd1c68608a
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000055DF.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6459

On 2024-12-13 14:30, Richard Henderson wrote:
> Signed-off-by: Richard Henderson 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Sat Dec 14 18:05:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Dec 2024 18:05:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857447.1269736 (Exim 4.92)
	(envelope-from )
	id 1tMWW6-0004B1-2P; Sat, 14 Dec 2024 18:05:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857447.1269736; Sat, 14 Dec 2024 18:05:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tMWW5-0004Au-WB; Sat, 14 Dec 2024 18:05:25 +0000
Received: by outflank-mailman (input) for mailman id 857447;
 Sat, 14 Dec 2024 18:05: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 1tMWW4-0004Am-LS
 for xen-devel@lists.xenproject.org; Sat, 14 Dec 2024 18:05:24 +0000
Received: from fout-b1-smtp.messagingengine.com
 (fout-b1-smtp.messagingengine.com [202.12.124.144])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fb692edd-ba45-11ef-99a3-01e77a169b0f;
 Sat, 14 Dec 2024 19:05:21 +0100 (CET)
Received: from phl-compute-05.internal (phl-compute-05.phl.internal
 [10.202.2.45])
 by mailfout.stl.internal (Postfix) with ESMTP id DCE1F114007F;
 Sat, 14 Dec 2024 13:05:19 -0500 (EST)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-05.internal (MEProxy); Sat, 14 Dec 2024 13:05:20 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat,
 14 Dec 2024 13:05:18 -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: fb692edd-ba45-11ef-99a3-01e77a169b0f
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=1734199519;
	 x=1734285919; bh=CGfjQ4mtSogkwDRwGFBcKvlSU+aE7jlwAxUbDSYEheI=; b=
	sU3x8/0Tg0UEcJqvlyq15K4oIIu7sEPwN0O5Mm8xTy1a19v5F4GTYvZUpucpJfpM
	jQQXagVba27EflURtcDh7s+GQJ+pWTpDcs3RdTDi7MbYYpJ2cA4ZGGWRgwzHuPLB
	qWk+TyoHK/sb/fL6ZDv68rbBTeU+oy+hH3FR0d/yyWqknuFy0r+PhE31v8ZLjPIc
	wD9V3xNXevgXaTfyitu7V5rnWJmdXuLteWaFJvuFQoO3elm+qnjvCycaNVj8v1eG
	xgR1GiTf1dgI5zHlLtMh1KQlSNBCRzrOyLI3FUEmxxUTvljAdddMX6IGNkvrQxn1
	1wJJ52ojHwI8PLlXaZGp/A==
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=
	1734199519; x=1734285919; bh=CGfjQ4mtSogkwDRwGFBcKvlSU+aE7jlwAxU
	bDSYEheI=; b=LCW/nM+Z8cDMXFhFYwnxGW8jqIu2eW16JBbYlUCMjb75etBHPsC
	fyqB6G+8HCLIB34m0ufFD1NvuQ9kHcmP4huZZNiJdM8sCv3pJudKfLGYjZLHOX7E
	XfNolzNN7ult1cLLcFV/6H/a0gHiYEUUkxf5pVzGSpoMrjrWUBLi17SUs2sKGbzF
	Q2JKVoyhMUEmI6hxMI0tMmElz2hzKSFP+EILml4w0nwbt9tYf7Y7g6WIySsyoS+I
	tuCvKqH4PtE1w2Bj2vVzCpCtxUDyyVhakFeiKMfu9GnBlX+QgSm6HcazVBp/DfRc
	RjF1qu77/zd591uTx02iT0BYSAGrlp2D1Ng==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrkeelgddutdeiucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeen
    ucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomh
    grrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggft
    rfgrthhtvghrnhepgfduleetfeevhfefheeiteeliefhjefhleduveetteekveettddvge
    euteefjedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho
    mhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnh
    gspghrtghpthhtohepjedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepughmuhhk
    hhhinhesfhhorhgurdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtsh
    drgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtoheprghnughrvgifrdgtohhophgv
    rhefsegtihhtrhhigidrtghomhdprhgtphhtthhopehjsggvuhhlihgthhesshhushgvrd
    gtohhmpdhrtghpthhtohepjhhulhhivghnseigvghnrdhorhhgpdhrtghpthhtohepshhs
    thgrsggvlhhlihhniheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepohhlvghkshhiih
    drkhhurhhotghhkhhosehgmhgrihhlrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Sat, 14 Dec 2024 19:05:15 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	Oleksii Kurochko 
Subject: Re: [PATCH v2 00/35] Introduce NS8250 UART emulator
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="pF/P2cMhT/UHyHIG"
Content-Disposition: inline
In-Reply-To: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>


--pF/P2cMhT/UHyHIG
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Sat, 14 Dec 2024 19:05:15 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: dmukhin@ford.com
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	Oleksii Kurochko 
Subject: Re: [PATCH v2 00/35] Introduce NS8250 UART emulator

On Thu, Dec 05, 2024 at 08:41:30PM -0800, Denis Mukhin via B4 Relay wrote:
> The patch series introduces initial in-hypervisor emulator for
> NS8250/NS16x50-compatible UARTs under CONFIG_HAS_VUART_NS8250.
>=20
> In parallel domain creation scenario (hyperlaunch), NS8520 emulator helps
> early guest OS bringup debugging, because it eliminates dependency on the
> external emulator being operational by the time domains are created. Also,
> there's no early console facility similar to vpl011 to support x86 guest =
OS
> bring up.
>=20
> The NS8250 emulator is disabled by default.

On a high level, why the mechanism used by earlyprintk=3Dxen (IIUC i/o
port 0xe9) isn't enough?
Hyperlaunch can't start full (Xen-unaware) HVM domains anyway, so
a requirement to use a Xen-specific interface for the console shouldn't be
an issue, no?

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

--pF/P2cMhT/UHyHIG
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmddyNsACgkQ24/THMrX
1yyiBQf/RLMejP9/MPjMcQylP4wOkr9Ltzz5VBvwcCuJfIb3RrdRF20KikVz1YFD
Ki3z97Jx3GpRpzDeVBORZvP29DpOlek1GTZuBCoHDBCqRrg3cbbboN0LrAuAGreI
disM2GLNckxIv7uLs6FYw3TciOufO/yT1+qN30XQgmrlYzrgRiksDmDVUQztnesi
zbAqEn6g4HbhJZNKtus5i49EZXpK7k42AuehxORi33E47anCmmCC3flYUnnSvYYy
5RKATImO/lFeTsXBhJq0P9bO2wdc4Y6I+9czgRMpLXREpBvMq+Pv1V+y5qNZrnxy
JN2YbKqqDMvfnlg01rm4bCY+YQrQ7w==
=aMUr
-----END PGP SIGNATURE-----

--pF/P2cMhT/UHyHIG--


From xen-devel-bounces@lists.xenproject.org Sun Dec 15 15:47:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Dec 2024 15:47:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857506.1269756 (Exim 4.92)
	(envelope-from )
	id 1tMqqC-0000ys-3a; Sun, 15 Dec 2024 15:47:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857506.1269756; Sun, 15 Dec 2024 15:47: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 1tMqqC-0000yl-19; Sun, 15 Dec 2024 15:47:32 +0000
Received: by outflank-mailman (input) for mailman id 857506;
 Sun, 15 Dec 2024 15:47: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 1tMqqA-0000y8-UT
 for xen-devel@lists.xenproject.org; Sun, 15 Dec 2024 15:47:30 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e281f55c-bafb-11ef-99a3-01e77a169b0f;
 Sun, 15 Dec 2024 16:47:27 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 15 Dec 2024 16:47:27 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id CE3A72CA4;
 Sun, 15 Dec 2024 16:47:26 +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: e281f55c-bafb-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734277647; x=1765813647;
  h=from:to:cc:subject:date:message-id:in-reply-to:
   references:mime-version:content-transfer-encoding;
  bh=d35/fRKhEk4BnT9kSZymUoojDTsx78u+z8fW+WtGOzg=;
  b=buTT47n23Xi19Zjy8g99leLtOC79B9TxM2bFp0+CYVHkEO8OOggiQ8SN
   /Qm+EWEd4lf5ziPrja0cieVbObxResNkN0SUykTEk3Gfec6R9o+Y8FnNM
   LE2pja78ojNzwmnuFQxVJ/g2miWFFNaC74g4PyKVsy0wvLklfUX+HObkB
   g=;
X-CSE-ConnectionGUID: qWOV7EptQi6CYNeNSCexxA==
X-CSE-MsgGUID: VNwSvHuWRBy8A7K5FqVrJQ==
X-IronPort-AV: E=Sophos;i="6.12,236,1728943200"; 
   d="scan'208";a="28185495"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	nthony PERARD ,
	Ariel Otilibili 
Subject: [PATCH 1/1] tools/libacpi: clear ASL warning about PCI0
Date: Sun, 15 Dec 2024 16:40:46 +0100
Message-ID: <20241215154659.151158-2-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20241215154659.151158-1-Ariel.Otilibili-Anieli@eurecom.fr>
References: <20241215154659.151158-1-Ariel.Otilibili-Anieli@eurecom.fr>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

* iasl complains _HID and _ADR cannot be used at the same time

```
/usr/bin/iasl -vs -p tools/firmware/hvmloader/dsdt_anycpu.tmp -tc tools/firmware/hvmloader/dsdt_anycpu.asl 2>&1 | grep -B10 HID
tools/firmware/hvmloader/dsdt_anycpu.asl     40:        Device (PCI0)
Warning  3073 -                                    Multiple types ^  (Device object requires either a _HID or _ADR, but not both)
```

* generally _HID devices are enumerated and have their drivers loaded by ACPI
* this is from "ASL 2.0 Introduction and Overview" (page 4).
* removing _ADR, the warning is cleared out.

Link: https://www.intel.com/content/www/us/en/developer/topic-technology/open/acpica/documentation.html
Fixes: a5da231f56268702ba9d9e0c4f1ad7156446e77b
Cc: Jan Beulich 
Cc: Anthony PERARD 
Signed-off-by: Ariel Otilibili 
---
 tools/libacpi/dsdt.asl | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/libacpi/dsdt.asl b/tools/libacpi/dsdt.asl
index 32b42f85ae..9d50578e98 100644
--- a/tools/libacpi/dsdt.asl
+++ b/tools/libacpi/dsdt.asl
@@ -41,7 +41,6 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
        {
            Name (_HID, EisaId ("PNP0A03"))
            Name (_UID, 0x00)
-           Name (_ADR, 0x00)
            Name (_BBN, 0x00)
 
            /* Make cirrues VGA S3 suspend/resume work in Windows XP/2003 */
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Sun Dec 15 15:47:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Dec 2024 15:47:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857505.1269747 (Exim 4.92)
	(envelope-from )
	id 1tMqq2-0000iK-TJ; Sun, 15 Dec 2024 15:47:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857505.1269747; Sun, 15 Dec 2024 15:47: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 1tMqq2-0000iD-Q2; Sun, 15 Dec 2024 15:47:22 +0000
Received: by outflank-mailman (input) for mailman id 857505;
 Sun, 15 Dec 2024 15:47: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 1tMqq0-0000i5-UQ
 for xen-devel@lists.xenproject.org; Sun, 15 Dec 2024 15:47:21 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id dcea87e6-bafb-11ef-a0d6-8be0dac302b0;
 Sun, 15 Dec 2024 16:47:18 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 15 Dec 2024 16:47:17 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id 2470C2CA3;
 Sun, 15 Dec 2024 16:47:17 +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: dcea87e6-bafb-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734277638; x=1765813638;
  h=from:to:cc:subject:date:message-id:mime-version:
   content-transfer-encoding;
  bh=EUsqSo7NMo0gypGU76MTejtXRREjqCKXHtiu3gsUQvo=;
  b=AjETNaowgIVAIkNGix+tZ5BM6hE2nMWppOCUvJaOAH8P5HANdY7kHdV8
   kA9h1yOJ1Jx5vSb5BTLYtnPI87WxNGZTWJ8yqEds/0VXteLxhhKH3GWhL
   AtQhTF2TykpuIzyiQPvlk0ZGmKOTI17axT8hv8ieEzH9WCMk6sR7xx/ls
   0=;
X-CSE-ConnectionGUID: fXvuy6ILRCqxexGB9tkB9Q==
X-CSE-MsgGUID: feKxiDcHS4STuY3e5z1PoQ==
X-IronPort-AV: E=Sophos;i="6.12,236,1728943200"; 
   d="scan'208";a="28185493"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	nthony PERARD ,
	Ariel Otilibili 
Subject: [PATCH 0/1] tools/libacpi: clear ASL warning about PCI0
Date: Sun, 15 Dec 2024 16:40:45 +0100
Message-ID: <20241215154659.151158-1-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hello,

This patch clears out an ASL warning; below is listed my configuration.

Your feedback is much appreciated.

Thank you,

```
$ iasl -v

Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20240927
Copyright (c) 2000 - 2023 Intel Corporation

$ gcc --version 
gcc (GCC) 14.2.1 20240910
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ uname -a
Linux arc 6.12.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Mon, 09 Dec 2024 14:31:57 +0000 x86_64 GNU/Linux
```

Ariel Otilibili (1):
  tools/libacpi: clear ASL warning about PCI0

 tools/libacpi/dsdt.asl | 1 -
 1 file changed, 1 deletion(-)

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 07:03:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 07:03:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857536.1269767 (Exim 4.92)
	(envelope-from )
	id 1tN58D-0007c2-SH; Mon, 16 Dec 2024 07:03:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857536.1269767; Mon, 16 Dec 2024 07:03: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 1tN58D-0007bv-P5; Mon, 16 Dec 2024 07:03:05 +0000
Received: by outflank-mailman (input) for mailman id 857536;
 Mon, 16 Dec 2024 06:14: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 1tN4NR-0002OY-Ns
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 06:14:46 +0000
Received: from smarthost1.eviden.com (smarthost1.eviden.com [80.78.11.82])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0949d2fe-bb75-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 07:14:41 +0100 (CET)
Received: from mail-db5eur02lp2108.outbound.protection.outlook.com (HELO
 EUR02-DB5-obe.outbound.protection.outlook.com) ([104.47.11.108])
 by smarthost1.eviden.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 16 Dec 2024 07:14:22 +0100
Received: from AM8PR07MB7602.eurprd07.prod.outlook.com (2603:10a6:20b:24b::7)
 by AS8PR07MB9068.eurprd07.prod.outlook.com (2603:10a6:20b:569::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.20; Mon, 16 Dec
 2024 06:14:17 +0000
Received: from AM8PR07MB7602.eurprd07.prod.outlook.com
 ([fe80::fbd7:ca71:b636:6f9d]) by AM8PR07MB7602.eurprd07.prod.outlook.com
 ([fe80::fbd7:ca71:b636:6f9d%5]) with mapi id 15.20.8251.015; Mon, 16 Dec 2024
 06:14: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: 0949d2fe-bb75-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=eviden.com; i=@eviden.com; q=dns/txt; s=mail;
  t=1734329681; x=1765865681;
  h=from:to:cc:subject:date:message-id:references:
   in-reply-to:content-id:content-transfer-encoding:
   mime-version;
  bh=KcM3qu6wrUbpXxioCKYw1IyCE3cff/1SziVQFXEGa5M=;
  b=CsxyfBJg7B7JNZgDe2KvjWl/v8QCTCFiJ4aEzkDuorqPY8S6TYK6mr0R
   UaZGdfG2UMdqM8quGJv3KzAZDoMJpxF/w0dmpLvQywyJfPdq4yuSrwWyq
   gOLVpFgXYnc+RFX4yEYjNGPK+OmsEjSUSbkxLMYFiwBl3VnQIuTJZZNm1
   OjHu/etRvI7mPYvBKCBhFt71e9yD+ZW2pxfZSOLuieZVZervBYAAvUqEA
   TjMYmo1Z0VLkl/QAV3GLdrlJX6/5VScxf3YVCe88v8t0rQ3Hj9pTdU0Mw
   diDkmB96xdiIN7p0npirh7haEG4eZiKYuHl7F613meTYPVMWHIKJCsGjy
   w==;
X-IronPort-AV: E=Sophos;i="6.12,237,1728943200"; 
   d="scan'208";a="26812121"
X-MGA-submission: =?us-ascii?q?MDF17JqH3VGSMNv5KrwJYdcOJp3fyfa92bmcjC?=
 =?us-ascii?q?32xrvjtveokzliE2SgKgYZ8fJm0W8jc+95IRvOiIgyMqHTRf1aSDa1FP?=
 =?us-ascii?q?VpPIJgePTmgGQBWqj51NGeMhDUTOCKlXmrZiSTnLtqcZ3iwYzq+a7VT6?=
 =?us-ascii?q?Azv03manBU1bfDfRvBzOaNBg=3D=3D?=
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fINMuMroT7fBB7t16IQxx6w9fRrZbNSKpidTDbyVcKcBBIHloKhbuB1NWVuKGOCpoe0L3LqhYzw6Zmeyy9SR5JncHFqTR/3ZLzKUK/MLaSbi5SYD9cmNoR73pbdoJQT3e0rh6PhEWV1MEfT+6+b0EM6XF2sNrt3Q2YzEMZCcSM5qeXfNv7GNRLuHkuFMom55A4qOoYUjFd+haoymg4yBS7AMxBAVnsJqNnpRlBctfLEXFTtZzcvYxx05sLm/RyIvc+3V6DqUkyPz0xbCm/uf8Vg94IemfaS7Z/bTIHPOzB6YvQmAJm/tCD+UrRJ0/tl+f26nwMmQ2ilmKiXcGz3AFQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=KcM3qu6wrUbpXxioCKYw1IyCE3cff/1SziVQFXEGa5M=;
 b=JIELYCoVVU36JaYfN+bH/c5rytv79Z7/gUya8yDYf9gC0bNuW2GwUNf9xP4utpDXRgzO6uHQeE0/uT8rky6ikan+289xdVJpsqdUdF/yyLc7wwMXgNvrAb9TaN3QRusUlGnTXSKKU4YSYI4XoGdQ/6qhtQpTs+4pTjdSu0mObsApQZ2IJ7dghAwEcBX2nkQUcSvGiWSZT6wbEUqwpmcNrmpYMdCHdYJ3fTz9HqU3bSWOPV32a24Dzl2zwH3WKScA3sIuS2BdPMDZex32BrD46eVMRrYn5OLe1hUCi1XXhuK+lkHPcK2E3gwUTJODZoADHa455zlOz4OiS97zPzj/kg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=eviden.com; dmarc=pass action=none header.from=eviden.com;
 dkim=pass header.d=eviden.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Eviden.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=KcM3qu6wrUbpXxioCKYw1IyCE3cff/1SziVQFXEGa5M=;
 b=D2DIKbJ/9aYDJklH1H+XOalP06XslkXr4ZUW+Yql98OOEOJr/VMz51VMbxjspQO605GZ4uBsYKV8fDZRh5/ezFfzgJRMfuzkZb16DaNZq2tSOLcoExdk1WC7PrEDUQRTOTOGlsocUQe0VJxY/p8+ZDPL9sx0d/zAUnU3Y5KqLzm54JLblBn29m2SnZFro9By86RdVaN50Ywvh7f4QkMtiyL3/Oyk2Memn13Z+2tNdG3a0jPEpzfI4XFFbSx052KNgyReeLFfHCYimZRZf0Cj2Dno5Byfy5BkXNEWsMPQXZMKsKUKzgaNW4IM3V361jwTZsRQrhd/Nt1mty+gjuhJoQ==
From: CLEMENT MATHIEU--DRIF 
To: Richard Henderson , "qemu-devel@nongnu.org"
	
CC: "Michael S. Tsirkin" , Marcel Apfelbaum
	, Paolo Bonzini , Eduardo
 Habkost , Jason Wang , Yi Liu
	, Stefano Stabellini , Anthony
 PERARD , Paul Durrant , "Edgar E.
 Iglesias" , "open list:X86 Xen CPUs"
	
Subject: Re: [PATCH 29/71] hw/i386: Constify all Property
Thread-Topic: [PATCH 29/71] hw/i386: Constify all Property
Thread-Index: AQHbTZKuMX5TQ4/Qd0KDE8iIYBLMC7LoaEWA
Date: Mon, 16 Dec 2024 06:14:16 +0000
Message-ID: <774bd939-8015-47c2-910d-f36c44bc0379@eviden.com>
References: <20241213190750.2513964-1-richard.henderson@linaro.org>
 <20241213190750.2513964-34-richard.henderson@linaro.org>
In-Reply-To: <20241213190750.2513964-34-richard.henderson@linaro.org>
Accept-Language: en-GB, fr-FR, 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=eviden.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AM8PR07MB7602:EE_|AS8PR07MB9068:EE_
x-ms-office365-filtering-correlation-id: 5f7a7b0e-23d3-4fec-0f47-08dd1d98ded9
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|376014|1800799024|7416014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?Y3U4WkRuUVByYjJ6TWZ5MGM5dnF3a2cvRXgzVi9jNndLZC9QSmZ2YnBnMWNo?=
 =?utf-8?B?TFJDWkl1aVQyTzNYTnAzTEpVLzlKVFhtOTIyYzNGVXIyWDRKUXJaSmlvWWQw?=
 =?utf-8?B?bWQ4bUtNVnVRU0NxMVR1NzNSVG9FSU5YZ1hDZU1QcFlYN09HYkRsVGExbTVW?=
 =?utf-8?B?RzhWaER2MjUyYTdLWEZSRFVHVm8wMnorZEg3NEVMQmpJMVlZTGJQZW5yS3Rm?=
 =?utf-8?B?eTRQOTlZdWtEWlhCZ25FR1dzalhqUVZZZUEveElGdWVvaG9qYWkwTXBieWFh?=
 =?utf-8?B?NUlGRW44QXhlRUFYSlVIUTdVMWtWRCt1Zm05MXhSeWthYSsramxxQitJUHJt?=
 =?utf-8?B?WG9kS21aeU1Uem9EZGtLWEw4RFhZOFlDQStWTEJjMkg2Q1IvOUNoZU1XdlJr?=
 =?utf-8?B?TlkvbHFsN0NrWDRnaGkvUDZMQTNDNGQ0ZkNVQjdtendhaXhGM2xnZ29pa2M0?=
 =?utf-8?B?bWxRcEFpQjZvWVFXWVNNNkh0RXVTK3NzMFZva0FzUThaSStEOERZME1uR1kz?=
 =?utf-8?B?Y3ZhTmlOeDRsb2FQNmpTVVJ2R0diVm5GZ01NNWFXT3VnUzcyalhEb21tTlBn?=
 =?utf-8?B?azRVZi9jeFN0Q2x2WlZoR0NTRklML1hNakF4aEw0c1F4SGZhSlYyVDJlVE8w?=
 =?utf-8?B?TSsxNU9lNlNEUHFVVS9XdG9Id1liRUhnOVQ0Z2krSEIwbjRGL25BL2JCdGZN?=
 =?utf-8?B?QlNteEhuaC94QTRjLzVFNWlOYmh6QnlOZTZ4Nm1SZ3VRekk0VldSbG50dHEz?=
 =?utf-8?B?T0pTR1hmMFhLcTJKdDg0SEJuUnQyUDB3Y1c4RFVQUHk3UVVtT3BJVEtyR2ln?=
 =?utf-8?B?MGxvZWl4K1grdTl3ejhURTJ5VGlqL3ltTUh5RldTWXBnUmJXUmV0eTNHVm44?=
 =?utf-8?B?ODVXYnFnWXRRM0cvajAveXRVWG4vMGRTQjlDTGo5SkVxcXFYekN3NmJzSWlw?=
 =?utf-8?B?bzdhTE9jM2RsYlpiem5QWkRKSzdjSXh1ZmdvT0dMZ3lhajBGanBqYk00QWpl?=
 =?utf-8?B?VUl3ejdKRW9XaUVSMG8zd2ZuSjJSR0NjMExWWmtIQmZ0ajJDMHRjMUcrTzV0?=
 =?utf-8?B?enZqRWJ1ZmxkY2pCRFdoQm9SaWpNMlZHbkRFK0NTQWh6bitEUURrRm1ndTlR?=
 =?utf-8?B?ZXZsNEQ0dWN6QURtQmErNlAxT0dEWWtHMG85bVdhY2pTVTh6Q2g3OWltMi9k?=
 =?utf-8?B?QTYxUnNtWHRGNVZEemlyckVnLzdkYmZVcGVUQmZ1TmZRUy94L3dIZVdDVllU?=
 =?utf-8?B?TE1LL3lqNnM0bmU5Wm9VSWducldxekFXaFhZeldjeGIvZmtwQ1JHZ2tDdDVT?=
 =?utf-8?B?UjFtcFdaOWg5T1pKUjB0RnF4ZXNjZ3d4Z3FXelp6aXhBZmxmRDh0RSt4bkpl?=
 =?utf-8?B?U1lyYUhkTlZLWFVySFM4c1pNbzFWcDJzN3BUc0lIbE0waFV0VU13ZkMzeURW?=
 =?utf-8?B?VmhvbUhTQ2FiSkZNU3psT3oybzZaTTVvRzZPYU1aNUlkQ1owZUVwZXZpZFZM?=
 =?utf-8?B?UWZBS0VDMWU3cm5iM2gvVEk3WnRWYlk5Nm5lZ21WT3ZyLzFoZTdqTlE5V2tk?=
 =?utf-8?B?V3pDR2xrNmNqMkk2TDNsVEJoZzIwVmRiZ2FPNG5CVU5HckZpcW1rVHFGMlFV?=
 =?utf-8?B?TVBwWUFIL1JscUV6RkFGTlJ2SEFWQzczcytsUGd4RWwyTVpHT21JZ0o1NXZW?=
 =?utf-8?B?S3ZaL1JSWURWSGVvQmw3bkN3elRKMmtWZkNwMXZYZGNlRUhSclhYYmdLTWtE?=
 =?utf-8?B?a01kLzY1L2JXTEJVNFprcnl6OE16REwvWE9yOGIyZk1FTHJZSVJyVVdOMFAx?=
 =?utf-8?B?L3lsRXN2eEd3UjBDZ1ZEKzNkR0FKcGNvWG5uT1lmRVpzSE1qZFhNbDVpZGhz?=
 =?utf-8?B?VUFOdzZ3RFVkNmpnc1F5VFNQT2NTV25oUWphaCtZKzRtL1lCNE51VDZqQmJB?=
 =?utf-8?Q?gRZiCUUSHwDy5DumCkz36or0GrQ3Tt6G?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM8PR07MB7602.eurprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(7416014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?UDZGUkFnVkprK3hsRnBJRktOV2J5bEF4ekJaU2R4QTEvTStyMm9HaWNwc1Ux?=
 =?utf-8?B?M0RNb3hmMnRiSzNKendTcG5acXRad25TYlJ4dHN5Y0FaZXpobmo2SUFvMFZu?=
 =?utf-8?B?ZjZrdHdoY2RjVG56WXZuNTUrbE5pa2NVcit6ZWN0Vnp3bE1pN3Z3b2Uwc1hP?=
 =?utf-8?B?Q0tXd1Y0M0NwR01vWGFTZkFNRmRNb2g4U1piUnZmR25GcWVOWFg1TEptM2ZB?=
 =?utf-8?B?RkY1U1lUcVhMei9NZDE5VVV0dUhYaFZScmpKSGd0dHlrTlZYNy94bm94dys4?=
 =?utf-8?B?eXV2RGNRWUdoR2RXS2pkTXpyNW92QXRWekt4N0J6SElGejFzN011alhKK0dv?=
 =?utf-8?B?Y3ZYaUdTWHI2bFV3NmF2QkM1dzR4cEZuWTQvTXdrUkp1U1daZERJUGpFbjNo?=
 =?utf-8?B?YTB4ZHp1ZHZVM3JEWnZOYjN0VXduaFNMVWVaQmE5Sm5IMk1DVGV0ZzAydkpD?=
 =?utf-8?B?WE5iTVUzSlRreDU5ekRHN0ZaV2FESjBLTklUZ1BYazV3a1FCWGVodWFmYXhS?=
 =?utf-8?B?Qmp3MzkvN1RwZVRiYVVhblF5R1RHVXdWcCtzZDhTc3c4eUtKRnBPREgyOGh2?=
 =?utf-8?B?TE5NTDQyMDN5NGwwMlBRRktWSnN1c3J6SlpnSk5jWWpTN3pqdFdQL1pNSWtm?=
 =?utf-8?B?SndlVGVQWGZ0bFpQU2JveU9LVldPbjBBbU1scjlVZGlvbTdYNXRRY0pFQ2RC?=
 =?utf-8?B?b1YyUXZOekZGamkzenc2RWs4MXhneUxqelY1cU1wZi9Wb1d3MEl0SmlYSWt2?=
 =?utf-8?B?NHBuZ25GeVlBbm9yQkJuTE1MeU5Ea1FwYWxJUWNMRXhaejRFaXZYTVdrYWtI?=
 =?utf-8?B?VVZHQ1NlZmpyNzkrMFR3NitQd29JM3VFNjVtQitycnhvOFVQZ1VCL1pYeXc3?=
 =?utf-8?B?b3ZZUTFZd01KdWd4elZ4WGc5UjBzeWxGRlVqZXBEeG0zaW9yTHBpcm83aXZR?=
 =?utf-8?B?OWFBVEFUdVFkTFMxdVV5ZURkNW9SVlcyNTlZMUN4ZDlPVkREL2N3SUxrMTFF?=
 =?utf-8?B?UW0wNFNnUHh0N1hTbUw0T0U1N1FJaHdoM0tFZE4rU1VoN1JrWWg0Q1FTcUNl?=
 =?utf-8?B?U2xYSEkzM0gwSmNVKzdOZVZlbWhINFoybTdNeWp2WHJlUjZMczBXQ0JNaVlL?=
 =?utf-8?B?WjBiSFZvdTQ4OVNNUnJzZ3ppLy9pendHNFk3SEc4dHRpdjUvQW12S1BuTzZE?=
 =?utf-8?B?K0tCZEtXVFRmWkQ3WXU1QVQzelJkOWxGWFpPSnVqeGxJNjZYZ0NMK1Uva3g1?=
 =?utf-8?B?ZnNSODF1Rmh2OWN2WTl6Uyt5eksyRmFXWmlrVkdBNzhjV1dvbFo3dWxZdFp4?=
 =?utf-8?B?YkNlN1VZYVRvMVAyaElGd1JBbldhSTB5MlpCVkhucU1HQk9WZ0E4VTV0bGpU?=
 =?utf-8?B?Y0ZydHhGL0lXNytNZUVvRnBzbXpGZldKZ2xwNGRvZ04ybWFLcWROWkk2SVgw?=
 =?utf-8?B?Q0lHNzNkT0JuT3ZTbEhFUUtYaFhZWVU4TkVsNkZLa0lyc2dHSSsrM2JjZklr?=
 =?utf-8?B?RWtaRnlBNGJlR0ptS2tKYXFFelFlR083UTZqd1NSMlNjQ3pVVlEvYmNsd0Jj?=
 =?utf-8?B?UytEUUlveW5RNnQvTWJ4bzJlZllWWGFGR0JRWkxYRWFMdTZhTklpTnpPUm90?=
 =?utf-8?B?OWNZT1pzbzl2NDNkTk5vdldkVGoyYTBDd1F3YThGTkhRSTJZRFdRS3VHOE53?=
 =?utf-8?B?eHlEay95NFZPUUhJWVMrekdFRU10RHZBblc4NzFEVTNROWZGSTUyZ3pkcXFE?=
 =?utf-8?B?N2p0WVBLM0JUZEJtOWRFM0ZqMXFwVDJEYWpRQzhSa0RlN01leTNrSmtCNE9t?=
 =?utf-8?B?Q3BjOWpSQ0djMFVyQXpWa0ljRjQ3OW1Yd0xhbHRjSDNpUXN3OXFDNTcxZVNF?=
 =?utf-8?B?aERFdmdOSzF1QlBPQjRFRnFLY1pGWi9KOGRUaGlseXlOcGpBSE9NQVFqRlNN?=
 =?utf-8?B?bE5ua3pXWWpobnkrdWc4VFZZR2FycVgvZlNTcjZNWkgxQmJoQjh3YXBuQWJ6?=
 =?utf-8?B?bTFFQ2w2eWgwZDJGWGdQRzkvQi9wMFdsa3N1ZlVXWms1dDg0OVJ6NW5Ta2NW?=
 =?utf-8?B?cDlyN3l6aGNZNE5adEVyT2prTEgwNUs4VUZwZTdUd1V3T3JkZE5rbFlCd3Ji?=
 =?utf-8?B?amtCSzhLZHE0STBmRTNkOG9KbGthSkg5UWJzTVlVdFFLdmVxQzhvT3o2UW9M?=
 =?utf-8?Q?t0u293gx+oyaxMi2M7YONWg=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <65718DAC884D734985E2BC933C356A9B@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: eviden.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB7602.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5f7a7b0e-23d3-4fec-0f47-08dd1d98ded9
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2024 06:14:16.7239
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 7d1c7785-2d8a-437d-b842-1ed5d8fbe00a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: AQtkFe7vRLLiYHGuG51H9j0F0cp5xdINTPFTYEle+2wlNa8+CRzlaGj1RZpSQan0I0z2aJmSC1tSroD6LJcWm8TQqhpjvzeSZKEMM9EOSYjtZu/WlSXn1NGWe+m4nbzr
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR07MB9068

SGkgUmloYXJkLg0KDQpHb29kIGlkZWEsIExHVE0uDQoNCkp1c3Qgb3V0IG9mIGN1cmlvc2l0eSwg
d2hhdCB3YXMgdGhlIG1vdGl2YXRpb24gZm9yIHN1Y2ggYSBwYXRjaD8NCkl0IGl0IHNpbXBseSBh
Ym91dCBjbGVhbmluZyB0aGUgY29kZSBvciBpcyBpdCBpbnRlbmRlZCB0byBzb2x2ZSBhIGRlZXBl
ciANCnByb2JsZW0uDQoNClRoYW5rcywNCmNtZA0KDQoNCk9uIDEzLzEyLzIwMjQgMjA6MDcsIFJp
Y2hhcmQgSGVuZGVyc29uIHdyb3RlOg0KPiBDYXV0aW9uOiBFeHRlcm5hbCBlbWFpbC4gRG8gbm90
IG9wZW4gYXR0YWNobWVudHMgb3IgY2xpY2sgbGlua3MsIHVubGVzcyB0aGlzIGVtYWlsIGNvbWVz
IGZyb20gYSBrbm93biBzZW5kZXIgYW5kIHlvdSBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+
DQo+DQo+IFNpZ25lZC1vZmYtYnk6IFJpY2hhcmQgSGVuZGVyc29uIDxyaWNoYXJkLmhlbmRlcnNv
bkBsaW5hcm8ub3JnPg0KPiAtLS0NCj4gICBody9pMzg2L2FtZF9pb21tdS5jICAgICAgICB8IDIg
Ky0NCj4gICBody9pMzg2L2ludGVsX2lvbW11LmMgICAgICB8IDIgKy0NCj4gICBody9pMzg2L2t2
bS9jbG9jay5jICAgICAgICB8IDIgKy0NCj4gICBody9pMzg2L2t2bS9pODI1NC5jICAgICAgICB8
IDIgKy0NCj4gICBody9pMzg2L2t2bS9pb2FwaWMuYyAgICAgICB8IDIgKy0NCj4gICBody9pMzg2
L3NneC1lcGMuYyAgICAgICAgICB8IDIgKy0NCj4gICBody9pMzg2L3ZtbW91c2UuYyAgICAgICAg
ICB8IDIgKy0NCj4gICBody9pMzg2L3ZtcG9ydC5jICAgICAgICAgICB8IDIgKy0NCj4gICBody9p
Mzg2L3g4Ni1pb21tdS5jICAgICAgICB8IDIgKy0NCj4gICBody9pMzg2L3hlbi94ZW5fcHZkZXZp
Y2UuYyB8IDIgKy0NCj4gICAxMCBmaWxlcyBjaGFuZ2VkLCAxMCBpbnNlcnRpb25zKCspLCAxMCBk
ZWxldGlvbnMoLSkNCj4NCj4gZGlmZiAtLWdpdCBhL2h3L2kzODYvYW1kX2lvbW11LmMgYi9ody9p
Mzg2L2FtZF9pb21tdS5jDQo+IGluZGV4IGFmMGY0ZGExZjYuLmNhM2U2MmEyNDQgMTAwNjQ0DQo+
IC0tLSBhL2h3L2kzODYvYW1kX2lvbW11LmMNCj4gKysrIGIvaHcvaTM4Ni9hbWRfaW9tbXUuYw0K
PiBAQCAtMTY2OCw3ICsxNjY4LDcgQEAgc3RhdGljIHZvaWQgYW1kdmlfc3lzYnVzX3JlYWxpemUo
RGV2aWNlU3RhdGUgKmRldiwgRXJyb3IgKiplcnJwKQ0KPiAgICAgICBhbWR2aV9pbml0KHMpOw0K
PiAgIH0NCj4NCj4gLXN0YXRpYyBQcm9wZXJ0eSBhbWR2aV9wcm9wZXJ0aWVzW10gPSB7DQo+ICtz
dGF0aWMgY29uc3QgUHJvcGVydHkgYW1kdmlfcHJvcGVydGllc1tdID0gew0KPiAgICAgICBERUZJ
TkVfUFJPUF9CT09MKCJ4dHN1cCIsIEFNRFZJU3RhdGUsIHh0c3VwLCBmYWxzZSksDQo+ICAgICAg
IERFRklORV9QUk9QX0VORF9PRl9MSVNUKCksDQo+ICAgfTsNCj4gZGlmZiAtLWdpdCBhL2h3L2kz
ODYvaW50ZWxfaW9tbXUuYyBiL2h3L2kzODYvaW50ZWxfaW9tbXUuYw0KPiBpbmRleCA0YzBkMWQ3
ZDQ3Li5hNWIyNjgzNDJmIDEwMDY0NA0KPiAtLS0gYS9ody9pMzg2L2ludGVsX2lvbW11LmMNCj4g
KysrIGIvaHcvaTM4Ni9pbnRlbF9pb21tdS5jDQo+IEBAIC0zNDA0LDcgKzM0MDQsNyBAQCBzdGF0
aWMgY29uc3QgTWVtb3J5UmVnaW9uT3BzIHZ0ZF9tZW1fb3BzID0gew0KPiAgICAgICB9LA0KPiAg
IH07DQo+DQo+IC1zdGF0aWMgUHJvcGVydHkgdnRkX3Byb3BlcnRpZXNbXSA9IHsNCj4gK3N0YXRp
YyBjb25zdCBQcm9wZXJ0eSB2dGRfcHJvcGVydGllc1tdID0gew0KPiAgICAgICBERUZJTkVfUFJP
UF9VSU5UMzIoInZlcnNpb24iLCBJbnRlbElPTU1VU3RhdGUsIHZlcnNpb24sIDApLA0KPiAgICAg
ICBERUZJTkVfUFJPUF9PTl9PRkZfQVVUTygiZWltIiwgSW50ZWxJT01NVVN0YXRlLCBpbnRyX2Vp
bSwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT05fT0ZGX0FVVE9fQVVUTyksDQo+
IGRpZmYgLS1naXQgYS9ody9pMzg2L2t2bS9jbG9jay5jIGIvaHcvaTM4Ni9rdm0vY2xvY2suYw0K
PiBpbmRleCA0MGFhOWEzMmMzLi43MTE1MGVkMmUwIDEwMDY0NA0KPiAtLS0gYS9ody9pMzg2L2t2
bS9jbG9jay5jDQo+ICsrKyBiL2h3L2kzODYva3ZtL2Nsb2NrLmMNCj4gQEAgLTMwNSw3ICszMDUs
NyBAQCBzdGF0aWMgY29uc3QgVk1TdGF0ZURlc2NyaXB0aW9uIGt2bWNsb2NrX3Ztc2QgPSB7DQo+
ICAgICAgIH0NCj4gICB9Ow0KPg0KPiAtc3RhdGljIFByb3BlcnR5IGt2bWNsb2NrX3Byb3BlcnRp
ZXNbXSA9IHsNCj4gK3N0YXRpYyBjb25zdCBQcm9wZXJ0eSBrdm1jbG9ja19wcm9wZXJ0aWVzW10g
PSB7DQo+ICAgICAgIERFRklORV9QUk9QX0JPT0woIngtbWFjaC11c2UtcmVsaWFibGUtZ2V0LWNs
b2NrIiwgS1ZNQ2xvY2tTdGF0ZSwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgbWFjaF91c2Vf
cmVsaWFibGVfZ2V0X2Nsb2NrLCB0cnVlKSwNCj4gICAgICAgREVGSU5FX1BST1BfRU5EX09GX0xJ
U1QoKSwNCj4gZGlmZiAtLWdpdCBhL2h3L2kzODYva3ZtL2k4MjU0LmMgYi9ody9pMzg2L2t2bS9p
ODI1NC5jDQo+IGluZGV4IGJhYTRiMzk1ODIuLjI5MzNkM2Y0NTggMTAwNjQ0DQo+IC0tLSBhL2h3
L2kzODYva3ZtL2k4MjU0LmMNCj4gKysrIGIvaHcvaTM4Ni9rdm0vaTgyNTQuYw0KPiBAQCAtMjg3
LDcgKzI4Nyw3IEBAIHN0YXRpYyB2b2lkIGt2bV9waXRfcmVhbGl6ZWZuKERldmljZVN0YXRlICpk
ZXYsIEVycm9yICoqZXJycCkNCj4gICAgICAga3BjLT5wYXJlbnRfcmVhbGl6ZShkZXYsIGVycnAp
Ow0KPiAgIH0NCj4NCj4gLXN0YXRpYyBQcm9wZXJ0eSBrdm1fcGl0X3Byb3BlcnRpZXNbXSA9IHsN
Cj4gK3N0YXRpYyBjb25zdCBQcm9wZXJ0eSBrdm1fcGl0X3Byb3BlcnRpZXNbXSA9IHsNCj4gICAg
ICAgREVGSU5FX1BST1BfTE9TVFRJQ0tQT0xJQ1koImxvc3RfdGlja19wb2xpY3kiLCBLVk1QSVRT
dGF0ZSwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbG9zdF90aWNrX3BvbGlj
eSwgTE9TVF9USUNLX1BPTElDWV9ERUxBWSksDQo+ICAgICAgIERFRklORV9QUk9QX0VORF9PRl9M
SVNUKCksDQo+IGRpZmYgLS1naXQgYS9ody9pMzg2L2t2bS9pb2FwaWMuYyBiL2h3L2kzODYva3Zt
L2lvYXBpYy5jDQo+IGluZGV4IDI5MDdiMDgxNjQuLjIxN2ZmNDNiOTggMTAwNjQ0DQo+IC0tLSBh
L2h3L2kzODYva3ZtL2lvYXBpYy5jDQo+ICsrKyBiL2h3L2kzODYva3ZtL2lvYXBpYy5jDQo+IEBA
IC0xMzMsNyArMTMzLDcgQEAgc3RhdGljIHZvaWQga3ZtX2lvYXBpY19yZWFsaXplKERldmljZVN0
YXRlICpkZXYsIEVycm9yICoqZXJycCkNCj4gICAgICAgcWRldl9pbml0X2dwaW9faW4oZGV2LCBr
dm1faW9hcGljX3NldF9pcnEsIElPQVBJQ19OVU1fUElOUyk7DQo+ICAgfQ0KPg0KPiAtc3RhdGlj
IFByb3BlcnR5IGt2bV9pb2FwaWNfcHJvcGVydGllc1tdID0gew0KPiArc3RhdGljIGNvbnN0IFBy
b3BlcnR5IGt2bV9pb2FwaWNfcHJvcGVydGllc1tdID0gew0KPiAgICAgICBERUZJTkVfUFJPUF9V
SU5UMzIoImdzaV9iYXNlIiwgS1ZNSU9BUElDU3RhdGUsIGt2bV9nc2lfYmFzZSwgMCksDQo+ICAg
ICAgIERFRklORV9QUk9QX0VORF9PRl9MSVNUKCkNCj4gICB9Ow0KPiBkaWZmIC0tZ2l0IGEvaHcv
aTM4Ni9zZ3gtZXBjLmMgYi9ody9pMzg2L3NneC1lcGMuYw0KPiBpbmRleCBkNjY0ODI5ZDM1Li5j
MjMyZTgyNWUwIDEwMDY0NA0KPiAtLS0gYS9ody9pMzg2L3NneC1lcGMuYw0KPiArKysgYi9ody9p
Mzg2L3NneC1lcGMuYw0KPiBAQCAtMTksNyArMTksNyBAQA0KPiAgICNpbmNsdWRlICJ0YXJnZXQv
aTM4Ni9jcHUuaCINCj4gICAjaW5jbHVkZSAiZXhlYy9hZGRyZXNzLXNwYWNlcy5oIg0KPg0KPiAt
c3RhdGljIFByb3BlcnR5IHNneF9lcGNfcHJvcGVydGllc1tdID0gew0KPiArc3RhdGljIGNvbnN0
IFByb3BlcnR5IHNneF9lcGNfcHJvcGVydGllc1tdID0gew0KPiAgICAgICBERUZJTkVfUFJPUF9V
SU5UNjQoU0dYX0VQQ19BRERSX1BST1AsIFNHWEVQQ0RldmljZSwgYWRkciwgMCksDQo+ICAgICAg
IERFRklORV9QUk9QX1VJTlQzMihTR1hfRVBDX05VTUFfTk9ERV9QUk9QLCBTR1hFUENEZXZpY2Us
IG5vZGUsIDApLA0KPiAgICAgICBERUZJTkVfUFJPUF9MSU5LKFNHWF9FUENfTUVNREVWX1BST1As
IFNHWEVQQ0RldmljZSwgaG9zdG1lbSwNCj4gZGlmZiAtLWdpdCBhL2h3L2kzODYvdm1tb3VzZS5j
IGIvaHcvaTM4Ni92bW1vdXNlLmMNCj4gaW5kZXggNzYxMzBjZDQ2ZC4uZGE5YzM1YzFlYyAxMDA2
NDQNCj4gLS0tIGEvaHcvaTM4Ni92bW1vdXNlLmMNCj4gKysrIGIvaHcvaTM4Ni92bW1vdXNlLmMN
Cj4gQEAgLTMxNyw3ICszMTcsNyBAQCBzdGF0aWMgdm9pZCB2bW1vdXNlX3JlYWxpemVmbihEZXZp
Y2VTdGF0ZSAqZGV2LCBFcnJvciAqKmVycnApDQo+ICAgICAgIHZtcG9ydF9yZWdpc3RlcihWTVBP
UlRfQ01EX1ZNTU9VU0VfREFUQSwgdm1tb3VzZV9pb3BvcnRfcmVhZCwgcyk7DQo+ICAgfQ0KPg0K
PiAtc3RhdGljIFByb3BlcnR5IHZtbW91c2VfcHJvcGVydGllc1tdID0gew0KPiArc3RhdGljIGNv
bnN0IFByb3BlcnR5IHZtbW91c2VfcHJvcGVydGllc1tdID0gew0KPiAgICAgICBERUZJTkVfUFJP
UF9MSU5LKCJpODA0MiIsIFZNTW91c2VTdGF0ZSwgaTgwNDIsIFRZUEVfSTgwNDIsIElTQUtCRFN0
YXRlICopLA0KPiAgICAgICBERUZJTkVfUFJPUF9FTkRfT0ZfTElTVCgpLA0KPiAgIH07DQo+IGRp
ZmYgLS1naXQgYS9ody9pMzg2L3ZtcG9ydC5jIGIvaHcvaTM4Ni92bXBvcnQuYw0KPiBpbmRleCA3
Y2M3NWRiYzZkLi5jYWI2ZTcyMDg5IDEwMDY0NA0KPiAtLS0gYS9ody9pMzg2L3ZtcG9ydC5jDQo+
ICsrKyBiL2h3L2kzODYvdm1wb3J0LmMNCj4gQEAgLTI1Miw3ICsyNTIsNyBAQCBzdGF0aWMgdm9p
ZCB2bXBvcnRfcmVhbGl6ZWZuKERldmljZVN0YXRlICpkZXYsIEVycm9yICoqZXJycCkNCj4gICAg
ICAgfQ0KPiAgIH0NCj4NCj4gLXN0YXRpYyBQcm9wZXJ0eSB2bXBvcnRfcHJvcGVydGllc1tdID0g
ew0KPiArc3RhdGljIGNvbnN0IFByb3BlcnR5IHZtcG9ydF9wcm9wZXJ0aWVzW10gPSB7DQo+ICAg
ICAgIC8qIFVzZWQgdG8gZW5mb3JjZSBjb21wYXRpYmlsaXR5IGZvciBtaWdyYXRpb24gKi8NCj4g
ICAgICAgREVGSU5FX1BST1BfQklUKCJ4LXJlYWQtc2V0LWVheCIsIFZNUG9ydFN0YXRlLCBjb21w
YXRfZmxhZ3MsDQo+ICAgICAgICAgICAgICAgICAgICAgICBWTVBPUlRfQ09NUEFUX1JFQURfU0VU
X0VBWF9CSVQsIHRydWUpLA0KPiBkaWZmIC0tZ2l0IGEvaHcvaTM4Ni94ODYtaW9tbXUuYyBiL2h3
L2kzODYveDg2LWlvbW11LmMNCj4gaW5kZXggNjBhZjg5NjIyNS4uMTU1ZjYyNjJlYSAxMDA2NDQN
Cj4gLS0tIGEvaHcvaTM4Ni94ODYtaW9tbXUuYw0KPiArKysgYi9ody9pMzg2L3g4Ni1pb21tdS5j
DQo+IEBAIC0xMjUsNyArMTI1LDcgQEAgc3RhdGljIHZvaWQgeDg2X2lvbW11X3JlYWxpemUoRGV2
aWNlU3RhdGUgKmRldiwgRXJyb3IgKiplcnJwKQ0KPiAgICAgICB9DQo+ICAgfQ0KPg0KPiAtc3Rh
dGljIFByb3BlcnR5IHg4Nl9pb21tdV9wcm9wZXJ0aWVzW10gPSB7DQo+ICtzdGF0aWMgY29uc3Qg
UHJvcGVydHkgeDg2X2lvbW11X3Byb3BlcnRpZXNbXSA9IHsNCj4gICAgICAgREVGSU5FX1BST1Bf
T05fT0ZGX0FVVE8oImludHJlbWFwIiwgWDg2SU9NTVVTdGF0ZSwNCj4gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgaW50cl9zdXBwb3J0ZWQsIE9OX09GRl9BVVRPX0FVVE8pLA0KPiAgICAg
ICBERUZJTkVfUFJPUF9CT09MKCJkZXZpY2UtaW90bGIiLCBYODZJT01NVVN0YXRlLCBkdF9zdXBw
b3J0ZWQsIGZhbHNlKSwNCj4gZGlmZiAtLWdpdCBhL2h3L2kzODYveGVuL3hlbl9wdmRldmljZS5j
IGIvaHcvaTM4Ni94ZW4veGVuX3B2ZGV2aWNlLmMNCj4gaW5kZXggZWQ2MjE1MzFkOC4uZTcxNDgz
ZTZlMyAxMDA2NDQNCj4gLS0tIGEvaHcvaTM4Ni94ZW4veGVuX3B2ZGV2aWNlLmMNCj4gKysrIGIv
aHcvaTM4Ni94ZW4veGVuX3B2ZGV2aWNlLmMNCj4gQEAgLTExNSw3ICsxMTUsNyBAQCBzdGF0aWMg
dm9pZCB4ZW5fcHZfcmVhbGl6ZShQQ0lEZXZpY2UgKnBjaV9kZXYsIEVycm9yICoqZXJycCkNCj4g
ICAgICAgICAgICAgICAgICAgICAgICAmZC0+bW1pbyk7DQo+ICAgfQ0KPg0KPiAtc3RhdGljIFBy
b3BlcnR5IHhlbl9wdl9wcm9wc1tdID0gew0KPiArc3RhdGljIGNvbnN0IFByb3BlcnR5IHhlbl9w
dl9wcm9wc1tdID0gew0KPiAgICAgICBERUZJTkVfUFJPUF9VSU5UMTYoInZlbmRvci1pZCIsIFhl
blBWRGV2aWNlLCB2ZW5kb3JfaWQsIFBDSV9WRU5ET1JfSURfWEVOKSwNCj4gICAgICAgREVGSU5F
X1BST1BfVUlOVDE2KCJkZXZpY2UtaWQiLCBYZW5QVkRldmljZSwgZGV2aWNlX2lkLCAweGZmZmYp
LA0KPiAgICAgICBERUZJTkVfUFJPUF9VSU5UOCgicmV2aXNpb24iLCBYZW5QVkRldmljZSwgcmV2
aXNpb24sIDB4MDEpLA0KPiAtLQ0KPiAyLjQzLjANCj4NCg==


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 07:26:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 07:26:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857548.1269777 (Exim 4.92)
	(envelope-from )
	id 1tN5Us-0001uz-Np; Mon, 16 Dec 2024 07:26:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857548.1269777; Mon, 16 Dec 2024 07:26: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 1tN5Us-0001us-Kt; Mon, 16 Dec 2024 07:26:30 +0000
Received: by outflank-mailman (input) for mailman id 857548;
 Mon, 16 Dec 2024 07:26: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 1tN5Ur-0001um-U1
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 07:26:30 +0000
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
 [2a00:1450:4864:20::42f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0f6e0c21-bb7f-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 08:26:26 +0100 (CET)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-385e87b25f0so3066208f8f.0
 for ; Sun, 15 Dec 2024 23:26: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
 ffacd0b85a97d-388c801b9ebsm7289392f8f.63.2024.12.15.23.26.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 15 Dec 2024 23:26: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: 0f6e0c21-bb7f-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734333986; x=1734938786; 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=nDClr30Lcr0vDyPEXxZa27XEpMaP8Hx/VJ+zjk+2fCw=;
        b=Sypy/C/Goujj6VMQymSnJO4VyGD8mipQ5VF24QHzaBaOv+ufmqlgWhsh69oxezbg0Q
         jR82ugkkLFpcAvRGLxA+WbbwL2PuAdbKjq5wjzn1XAzIVHT2w8OhDIQv8mKB17E/Br0f
         scvUPOq374O9/IjDsFoEepq2mKpRdQAOnYkZ61p1ExQe/x5k3HiKiNGVfydLpZgwaReg
         8E1HZiTf8AlBuMeRHsKC/5oGfY7RP7/AEMHoZJ6xUywWuGEi3mZfBrKGsJAz98LFWS18
         cSFhhDsjcjwvkg8MjlUO8uObqknnuVySnGtBlR3v5UEz/4QxsV97d3B2rngcyfXXvJif
         MkpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734333986; x=1734938786;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nDClr30Lcr0vDyPEXxZa27XEpMaP8Hx/VJ+zjk+2fCw=;
        b=dXL1F8YByY9VdbBwqeE7mv3s7RcwXEF9XYxrN2AR6rBtpoF8AZILsxLPBW3dL7ZvJX
         /2oVFbRDVulUw4BDmBGH+Pola5dLUVd17fqvO5oY84GzV5ZgyqFOW7Pr4D8LqR3WJ47d
         vZhSjh0ElUDVlSRbyr5GFpQE7FO5LXYcg9pInbb2xd0HLWLA1ZUzZnM00CzvIUO2IhMG
         ilwfFXK3A4r/YKNIU0VBsAET/75ffSob8IHK5QPc7/rZ8tZBYtrBCfswesdjOMZW2v/U
         tKCb/a3HcXh5XvqSgCkt4Cr5hgjifl63dmpN73DkyhQVQKB0l7n0D6oGuzc5Cg44Jqra
         fXgw==
X-Forwarded-Encrypted: i=1; AJvYcCVo2H1WueF3Ckib0lWWKkJqlibZTmg6bhhmWjCKuPaGTb2lxC/+FVp9pmW1cH7X0eJMI/aKkD6PLFs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwccEpYFmY/eEG2VE3tRYiqxgp9NpuUkpxRzmr7VkHjN3zCf1Uz
	MGJCU6ADwRsjh6SNMss3Z0Cy195SQ7CT3yYF4tS0doVVFa6KeFIExXKUGENFsA==
X-Gm-Gg: ASbGncv7UznBgOLKe9DtiSikkVRMExHlYQOshlOAmyWSpKc6R2JEL4seEMdwnwCEw/I
	LfnApsnIDYVRMH6EizwRLeXmw2G8oXOMbjASzGYvNolW95xGTtFFB0HWSmiUL6FxCusiYv3tEcx
	kd3+jJTvB0TF4qyWQuhax/UkWm0W9X2WcVN0b3LUoa1lcK9qM8r0zjR2Iw35wT59p/4/eJPOGXB
	D/Ggwr0Lcrqg+Vu08ppqoODAdjBnN3sZUQpDefpn5hdR0Vo2oAk+YtbXjWf/C+N5WVYyD/80IVf
	/naCNNN6WBI9KQqwuqbjEhqbQBNUQX2mCG2QuyedMA==
X-Google-Smtp-Source: AGHT+IE2ETw++RADhNZRp1rzYmqhN1PA3RVwPOsuldbu+tsijSK4uQka6P8cP3y6tUQAQxMCixwGgQ==
X-Received: by 2002:a5d:584b:0:b0:386:3afc:14a7 with SMTP id ffacd0b85a97d-387887e24c5mr12553425f8f.7.1734333986113;
        Sun, 15 Dec 2024 23:26:26 -0800 (PST)
Message-ID: <3beb2c10-0cde-48e4-841c-5addd324626d@suse.com>
Date: Mon, 16 Dec 2024 08:26:28 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: address violation of MISRA C Rule 11.1
To: alessandro.zucchelli@bugseng.com
Cc: Stefano Stabellini , consulting@bugseng.com,
 Julien Grall , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <7debd63f3900bad62bcbcc03081e4c04e6099135.1733914487.git.alessandro.zucchelli@bugseng.com>
 
 
 <26600bb0-93af-45b5-a341-5771bad844a1@suse.com>
 
 
 <1ddb5bd7e8889da0e978bb1391072925@bugseng.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: <1ddb5bd7e8889da0e978bb1391072925@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.12.2024 15:02, Alessandro Zucchelli wrote:
> On 2024-12-13 11:08, Jan Beulich wrote:
>> On 13.12.2024 01:53, Stefano Stabellini wrote:
>>> On Thu, 12 Dec 2024, Jan Beulich wrote:
>>>> On 12.12.2024 03:27, Stefano Stabellini wrote:
>>>>> On Wed, 11 Dec 2024, Jan Beulich wrote:
>>>>>> On 11.12.2024 12:02, Alessandro Zucchelli wrote:
>>>>>>> Rule 11.1 states as following: "Conversions shall not be performed
>>>>>>> between a pointer to a function and any other type".
>>>>>>>
>>>>>>> Functions "__machine_restart" and "__machine_halt" in 
>>>>>>> "x86/shutdown.c"
>>>>>>> and "halt_this_cpu" in "arm/shutdown.c" are defined as noreturn
>>>>>>> functions and subsequently passed as parameters to function calls.
>>>>>>> This violates the rule in Clang, where the "noreturn" attribute is
>>>>>>> considered part of the function"s type.
>>>>>>
>>>>>> I'm unaware of build issues with Clang, hence can you clarify how 
>>>>>> Clang's
>>>>>> view comes into play here? In principle various attributes ought to 
>>>>>> be
>>>>>> part of a function's type; iirc that's also the case for gcc. Yet 
>>>>>> how
>>>>>> that matters to Eclair is still entirely unclear to me.
>>>>>>
>>>>>>> By removing the "noreturn"
>>>>>>> attribbute and replacing it with uses of the ASSERT_UNREACHABLE 
>>>>>>> macro,
>>>>>>> these violations are addressed.
>>>>>>
>>>>>> Papered over, I'd say. What about release builds, for example?
>>>>>>
>>>>>> Deleting the attribute also has a clear downside 
>>>>>> documentation-wise. If
>>>>>> we really mean to remove them from what the compiler gets to see, I 
>>>>>> think
>>>>>> we ought to still retain them in commented-out shape.
>>>>>
>>>>> Another option would be to #define noreturn to nothing for ECLAIR 
>>>>> builds ?
>>>>
>>>> That again would feel like papering over things. Plus I don't know if 
>>>> that's
>>>> an option at all.
>>>
>>> What is "papering over" and what is a "nice solution" is often up to 
>>> the
>>> personal opinions.
>>>
>>> From my point of view, Alessandro's patch doesn't make the code worse.
>>> The ASSERT_UNREACHABLE solution is OK. I do agree with you that it
>>> should not be required for us to remove "noreturn", but I don't think 
>>> we
>>> have used it consistently anyway across the Xen codebase.
>>> ASSERT_UNREACHABLE is also a form of documentation that the function
>>> does not return.
>>>
>>> In conclusion, I think all three options are acceptable:
>>> 1) this patch as is
>>> 2) this patch plus /* noreturn */ as a comment
>>> 3) #define noreturn to nothing just for ECLAIR builds
>>>
>>> I don't mind either way, maybe option 2) is the best compromise.
>>
>> The variant with least impact on what we currently have (generated code
>> wise) is 3), though, which hence would be my preference (well, not 
>> exactly
>> a preference, but the least bad one).
> 
> Another option could be to encapsulate these function pointer casts as 
> follows:
> #define REMOVE_NORETURN(x) (void(*)(void*))(x)
> This approach allows us to retain the noreturn attribute and the 
> associated optimizations;
> note that the encapsulating macro will need to be deviated then.

And then have one such macro for every attribute that may need zapping?
What if there are multiple? Any macro may do, yet which one to use would
be unclear. What if only some attributes need zapping, and some need
retaining?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 08:07:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 08:07:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857564.1269787 (Exim 4.92)
	(envelope-from )
	id 1tN68K-0007YD-Sz; Mon, 16 Dec 2024 08:07:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857564.1269787; Mon, 16 Dec 2024 08:07: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 1tN68K-0007Y6-QH; Mon, 16 Dec 2024 08:07:16 +0000
Received: by outflank-mailman (input) for mailman id 857564;
 Mon, 16 Dec 2024 08:07: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 1tN68J-0007Y0-9n
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 08:07:15 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 (mail-db8eur05on20605.outbound.protection.outlook.com
 [2a01:111:f403:2614::605])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c1fc722a-bb84-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 09:07:13 +0100 (CET)
Received: from AM0PR02CA0207.eurprd02.prod.outlook.com (2603:10a6:20b:28f::14)
 by AS2PR08MB8832.eurprd08.prod.outlook.com (2603:10a6:20b:5e6::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Mon, 16 Dec
 2024 08:07:08 +0000
Received: from AMS1EPF0000003F.eurprd04.prod.outlook.com
 (2603:10a6:20b:28f:cafe::3a) by AM0PR02CA0207.outlook.office365.com
 (2603:10a6:20b:28f::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.21 via Frontend Transport; Mon,
 16 Dec 2024 08:07:08 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 AMS1EPF0000003F.mail.protection.outlook.com (10.167.16.36) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.15
 via Frontend Transport; Mon, 16 Dec 2024 08:07:06 +0000
Received: ("Tessian outbound b4c479532664:v524");
 Mon, 16 Dec 2024 08:07:06 +0000
Received: from Le616b5eb4440.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 1F791742-4497-4487-BBCA-1F58B2EE7E53.1; 
 Mon, 16 Dec 2024 08:06:59 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 Le616b5eb4440.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 16 Dec 2024 08:06:59 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by AS8PR08MB7693.eurprd08.prod.outlook.com (2603:10a6:20b:50b::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.19; Mon, 16 Dec
 2024 08:06:55 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8251.015; Mon, 16 Dec 2024
 08:06: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: c1fc722a-bb84-11ef-a0d6-8be0dac302b0
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=hRb3mpU9DUiQrdCIdvSEo7fmJKt700Ocbvjok5JKAuZtRUIX3nEDA9l+FVcw1qBLmW8dRVTKvLCh+c5Yhx3HzAZc2G7ZLspWYkOl6Dtzvkk8j5uwbUpZSycBjMb56CGod7vWh0jy+/l1wBMzAPWEQ/qi2Z9S5vpVJdE2utO0AjcA3V5PukN5SMaaEMVXAkM0szLdw4Tj8f2rfnhA3OJI5rwkOKJkyFreQnZR4OnZ+4U/86kdjgL2BFhCO8808qZKAgEmCbzArhIciuhNdNlgc6YhTE55Z73yIzyHaRd1FFwD1GUWjIXHv+IUxb9EA3u9E3b+LscmGqX5nReRR1SyaA==
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=ykHkM1i8na4wGJSlOKQ1GvbGFnUZhRjYH11j9HgkP0A=;
 b=w1HabQ1TM2XBYrZ0aYpWKjhSicZFFd+cwE8O48lukYT9hRKVRwM4dM02NBTeqgM5jkFI6nCIQl3Lb92XzyDSnN8G/cYr9h81B/SRJRe6iQ3T675x+Xqb2dDw9nJ3DyvUHR3M1Smx8oEwcFOfeNX/LsVHdE2QCJG7LysrmML9rA2F+Uz2u1FUM0/OlwSIiac2y6BW7pU4aQljEfjdu5uuqW88S6Bg7D+Ke/VQOYhg4By/sX92cXKREb8oxhhilJ7YatZTRjwcll41iZW0wzpglQU4mymC+z9ha3zHTbC3+7ijekSPttdmDC1liw//BVP/7ov22Cv2Yr208AWiNBoe3A==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=ykHkM1i8na4wGJSlOKQ1GvbGFnUZhRjYH11j9HgkP0A=;
 b=K//NkHN6ZPPF/LHSGbIOhOQaGUCmElqjMQQMuRlgJ5DMQ9RSJeJgjVctYc9xn2TrS4jEmp2vyhCbB6LBKEqx9EgyCy/rhK2jtTYSKsahK8NHpQr44yJgXDTEZij9MyVacn1lwIindjlAkdjnydGejyZmjJpz7KUwDVELI1PST7g=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 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
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: b5bd94bc582082ed
X-TessianGatewayMetadata: nScMtncYObil3Ebf3wZNv8TAOP+WP47Jz9zvK2jTMQUv+H3wJdxyzQWlnaD2hReqUE9s5xQ8Vh8uemfpP0lt9d3KnQ5ApqWCItn8U7OehSmUYK1+O1EkcOWABP4FeouEGQ9355TCvxRSd23RGcCxp6xYegXaITmLho2JIhdbGSg=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Ez0IIkR8o+a4dbJpBIDpo65srq+aCSvdyoS44H6BGYaTzFsTUaILxJ8/8CYosoJGEjqUw3gBeaF8m4GqsxN5Un+35O/0U8uqhSAyuRfUP8/je4yKNoPH4acAyM4cSM95/qKgX1bbyGJ8uTEaT8tAI+fJrHXBu/aym6m84ZD5xPLzuPpARbUo+4w4aI5p+uFvhuwwDRxn/Ftw+ERc2Yq/xpO6vP1/8GkaAW+laaGDr9x8Ghr+xmVPBrZNncu5mpYVBSbaRfO5P2AuaTJCu+Q3WP92MV3hNeoikRDWPV44n72j7WXgpK7nXvskXdsxdIxINW+zajCax3765T9suj6ghQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ykHkM1i8na4wGJSlOKQ1GvbGFnUZhRjYH11j9HgkP0A=;
 b=i8Ot+I4mbYq3plUIvDSWz8BuHwXE1S8l09dzaHU9fbFKITlpnDJmQw4ZiQLgsGtvZPlcwd6lkaSgcSOHTcMaUjSw3GDG7GhaaugINrs0RqCKeehNMsxJpCBbaDoJWi02C0/ij318GZPzJVgSR04VLgEYWijgnhInpHVxwvvvDR0qMtc5mpPVd27M/9RZf1rlRXQ46EOtHtm5io1dBZzi1ULLbA9EIVugdKWXlKyq6RhAEw6Ys4uXl0ygXDIF3GEeDPGTg2cZCPQN6iFt47XyTSmwrsDIoSypX+o7M4QLIHZn8zv4YKVSgsT+TFAnknvjQx2o4N96ZTmWcd2hKTwyww==
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=ykHkM1i8na4wGJSlOKQ1GvbGFnUZhRjYH11j9HgkP0A=;
 b=K//NkHN6ZPPF/LHSGbIOhOQaGUCmElqjMQQMuRlgJ5DMQ9RSJeJgjVctYc9xn2TrS4jEmp2vyhCbB6LBKEqx9EgyCy/rhK2jtTYSKsahK8NHpQr44yJgXDTEZij9MyVacn1lwIindjlAkdjnydGejyZmjJpz7KUwDVELI1PST7g=
From: Bertrand Marquis 
To: Julien Grall 
CC: "xen-devel@lists.xenproject.org" ,
	"jens.wiklander@linaro.org" , Volodymyr Babchuk
	, Stefano Stabellini ,
	Michal Orzel 
Subject: Re: [PATCH v3 04/10] xen/arm: ffa: Fine granular call support
Thread-Topic: [PATCH v3 04/10] xen/arm: ffa: Fine granular call support
Thread-Index: AQHbQOahZBVDYXOcj0uVqGja5nIgjbLk4umAgAO+LIA=
Date: Mon, 16 Dec 2024 08:06:54 +0000
Message-ID: <03D53BB9-1751-42DF-9AAD-41B25E915027@arm.com>
References: 
 <1b02c9c1df9ff2230e076f25398a5de876f98a51.1732702210.git.bertrand.marquis@arm.com>
 <8d8ef7f9-d73f-4ff8-8af9-4e73cda97624@xen.org>
In-Reply-To: <8d8ef7f9-d73f-4ff8-8af9-4e73cda97624@xen.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|AS8PR08MB7693:EE_|AMS1EPF0000003F:EE_|AS2PR08MB8832:EE_
X-MS-Office365-Filtering-Correlation-Id: 66a9ee84-4872-48df-2442-08dd1da8a1fc
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|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?DNC9UuNFGxF2JFkqRiI91WqeDSFdnLa6Dz9xAjZeanvPfy9a5VjhTUQxij5z?=
 =?us-ascii?Q?CJsCgrPh69bb4elq2TUN+oBQA5ZT54fPu9o0iqlnEZG2adOOuQzXctIu/iNq?=
 =?us-ascii?Q?2VYcym4gkjuQ1CDv3xMsP2+CfUzyDdZcA3vLIhCa2hD1tO7ILIyWjGkoTZsp?=
 =?us-ascii?Q?medK5hI9KHjWvq9DFKmnJltrYIQmUGKT3bwdExG9i0zT7GmLOt1bc7R+KJEF?=
 =?us-ascii?Q?VPvLH2nAADks8Gg5+YwsHoEUPqLSulUW/FI7jM5lB38DGOYZFFZfYgn8k0oT?=
 =?us-ascii?Q?cYQT3smfO5j5EaPVDIMDPIxsNsejf72M3JeRm8gzKoy8MPSGA2u3o+rh+StP?=
 =?us-ascii?Q?z4b5Yb53T7Ceu+PrS7yNJdhxlH9Kcm1A1IL8QmtbhTJewKGstSDAbSmEhMNI?=
 =?us-ascii?Q?ThUmLEN+BY1aL+wpWWHeE9Fr3N6R/R7TShn5CoVjOkJ+v2WIuxx51ojw4p8C?=
 =?us-ascii?Q?qOyRnr7sFhbr+RITH11J0lSnhs1gCZYuuYPW5Tz2bkmDIP5Ehc7Wnn/fxarn?=
 =?us-ascii?Q?9R6QxofWBacVyRJw4Ltro2ywPviJKcZcEoJtZddkokfJLYSn4Ui6HrK9NEY3?=
 =?us-ascii?Q?CZYX00IxuYA1JcaMOAQdQR/Ul/LiY+uMS2pB8h+IyITqPYOwNAXhv+Imc3tZ?=
 =?us-ascii?Q?ckumigbxBjjgXdhe1mStnCU/ssSkaeh4Evm7KYLWSPLzKgxJLLlGwzgE3+Kz?=
 =?us-ascii?Q?tEPKhTGqsubFI0roVtHTXfiTtmr/GC5597tl6LTlZxBkSIVJ76qgKOs7VyHJ?=
 =?us-ascii?Q?OCRsgzzvoj0vNjjQxf6sPDHdvssBys1ZE2ebp6sSdWGCgSpyeEkGy9gAMb14?=
 =?us-ascii?Q?b5RS6/lJGtf93c8GbH8CLeP7tSL6zW0Vx+0gNJBqGgKG2mnidi/t899fmXCA?=
 =?us-ascii?Q?NX/uKHmtSgqpc1we+Py4KfpwXMH6Hg8+RY2weE3+eyBPtpRIonJFVKE/Bhhu?=
 =?us-ascii?Q?moyUvA/OcyIxrzyy7Vt/DNgnNqiYFig3wC6ggN0pELxzCAqdrEG+5eP1sQc3?=
 =?us-ascii?Q?wb/KSixDe9x2u47UnBV9tEdXYO8IgAQ0bSx0ozoniQASXKlLD5izqV1O/Df0?=
 =?us-ascii?Q?fdg+I6qlKJayjPE6QSo5k/G7rGqOPdYmzL+oKmJeis3/ljF0Zh/Adab3P7N1?=
 =?us-ascii?Q?5sdBy7tVlz/2WIaZcNAqrNTtQktatmHiiXlFm+qPYZHAIXkel/sfi0lSrfCV?=
 =?us-ascii?Q?qEI6CngUx/G4BaoUQg2t2X/RWeU6jNIKeRSxv19WPvN7LgLyPEypySv7OzQs?=
 =?us-ascii?Q?dhy+fQKACBHnx97Zbrq1ChntPqb/yYK9zcoTAWQWW8CsZx9nQyHfzEIKT3s4?=
 =?us-ascii?Q?7j4fvDDzdE92ntHNNJZVaaIP6BSF1l5q/b9Ste4wxBVVfoB+VvQnvPJUiXdq?=
 =?us-ascii?Q?xGRcQlnFNrNnVqXY/8rkDTzPN0kwuO1WfHsWJlysY3+Bo8AP2GF6qJCVmR6B?=
 =?us-ascii?Q?PdPzFv6KXOJ2CvbdDiq4GkYVlKmFZmBD?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(10070799003)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6F77F50B2F93514DB4EE21D3F070BAE0@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB7693
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender:
 ip=[2603:10a6:10:25a::24];domain=DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS1EPF0000003F.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	c0c25af6-dcb0-4de8-512d-08dd1da89b09
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|35042699022|14060799003|36860700013|1800799024|82310400026|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?NmNiTokIQyYO5CFNUYYWTmOT5zLmPr5/OTGSK2C86dOSE4NWCF2JVToV5f+Q?=
 =?us-ascii?Q?gRTbT92ippsneMB6XBnleXVn6RUm0xoBcSWN/9pX7ls3AsoZeNgQ7GjtbhMk?=
 =?us-ascii?Q?zEUM7Ig4zxFITSuY/PKLqcS41K7BBDaehDwLHukeNO2HypiUlk0OL4Nqlekw?=
 =?us-ascii?Q?+Fs2Rrvx2aX/f5p8PzlHOkXBxYkj2afwkC4/iNscbq/jCesmWdNRJnADOCx3?=
 =?us-ascii?Q?1paaU8Z+8tVGAs6mreHJGSuTNPB2e3QXgwhEpgxpEYqUVOh05/4KZ4cvLh3Q?=
 =?us-ascii?Q?I78FRsZk5OnKKggMbmQcK3sGpbW2IV4yHQ3JNK3GarqVe13zoBRtDtDZJCD1?=
 =?us-ascii?Q?cI8nhCIDMcBfLzvnoUC5zqX9y5JEbjV5pj2rZZ4N0GL+A4LpEysCQsNJ6dev?=
 =?us-ascii?Q?VuTBhN0kKw2fiaY+ClncpG/tKihLkoqigk6b5f2abUmacer8jdJyl3JBkSKX?=
 =?us-ascii?Q?9YQtoA2Dj8Mbe3G+tPOhh7alpDRQARq6yDEi4upeBh31Vs2VFod1RWYiGam+?=
 =?us-ascii?Q?+b/NlMpVE3TbW3VerScp8SQ8gCTBDrHUA9wvYe/ajLWfyYc8ehmZm0SujVxX?=
 =?us-ascii?Q?iXONlkLLTKfqNFcRLBXxMRfR2ek8wIJqXIHo2aqsHt8lhtMW6BzFR03Gs3m0?=
 =?us-ascii?Q?n3p7Q17feOLKMgn3KzIcJdPWclXHZhphBa4525E01i8HsgLiJohzAXlYCtz4?=
 =?us-ascii?Q?xUzElk46VU7OLl7WuZ59PU6mtoJKo2OGqrswvVA1Ve1f7Z4Xkgo9vD1FykqF?=
 =?us-ascii?Q?EVOguZku34l1aQMx2qRXEBX6yZ38tzhL0cYN+8fL3RBqiva9Hytj8kIJ1ysA?=
 =?us-ascii?Q?YCmLwShlir8wKtHdHVhKRnsKL6fOmervLhk26//ujleOVr5SrydLwVWLAokH?=
 =?us-ascii?Q?Ax0PN7K4mI3sToAgN571gbodHZeZPEia4PSZrI78I6FMJZ7fxlfZrE4KqH4L?=
 =?us-ascii?Q?dwciy04xtf/Bo4PXhSJDNMgQcFZ4/Zgj93o21Qnh/JtjzrrfKXiBGIOjafl3?=
 =?us-ascii?Q?aAHviTv0vB3MUBpfiZfHaSkSF2qDSQORVMjvR8jvDcUrjtpcVlcWqepgCK2p?=
 =?us-ascii?Q?UxNhGMK0dueURWu8oVUa05TvIH+9eUTCm56J+00C0vLqnv5uTdOwN43QOp37?=
 =?us-ascii?Q?cCjqHGHC7tKqs5FaugZV5oz41e2Hj+qa0ezGmyhX891EOYmNj1n5tQmvEG/I?=
 =?us-ascii?Q?whxRu44Sa/YHWIj1F5MYo8AVoRRAD2IkVuYvwSDxcTmwp+kC7czF21vKrB0J?=
 =?us-ascii?Q?bHW0paH/6KzPO3YeAOr2Ce7pzQWiz82q8EeYdYM6VQNCr/Ic2xpV8XDAOY53?=
 =?us-ascii?Q?QE3fZiVvBI2FE5QRcZizvKVd0WAbeA8nZhy6b2Au39DCHGsKBCYYOKYVKtdC?=
 =?us-ascii?Q?px00HRcXL2IOMazWO5Fq9J3TsyKEhgX1+l/iWnNQXPim7E3zLj5cuWOYQI8R?=
 =?us-ascii?Q?w3NQ6rx3mH4niExcKXrRqCZiV07cLIyyonia1MwdQVPlJCpCUS3CQUBvV6k7?=
 =?us-ascii?Q?VCXFZMCr4iFdZak=3D?=
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(35042699022)(14060799003)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Dec 2024 08:07:06.4595
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 66a9ee84-4872-48df-2442-08dd1da8a1fc
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AMS1EPF0000003F.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB8832

Hi Julien,

> On 13 Dec 2024, at 23:57, Julien Grall  wrote:
>=20
> Hi Bertrand,
>=20
> On 27/11/2024 16:07, Bertrand Marquis wrote:
>> Create a bitmap to store which feature is supported or not by the
>> firmware and use it to filter which calls are done to the firmware.
>> While there reoder ABI definition by numbers to easily find the min and
>=20
> Typo (I can fix it while committing): s/reoder/reorder

Thanks for the finding.
Please fix on commit if that is ok for you.

There are also 2 minor findings on the patch 7 that could be fixed on commi=
t.

Cheers
Bertrand

>=20
> Cheers,
>=20
> --=20
> Julien Grall
>=20



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 08:18:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 08:18:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857573.1269797 (Exim 4.92)
	(envelope-from )
	id 1tN6JJ-0000tc-T9; Mon, 16 Dec 2024 08:18:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857573.1269797; Mon, 16 Dec 2024 08: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 1tN6JJ-0000tV-P1; Mon, 16 Dec 2024 08:18:37 +0000
Received: by outflank-mailman (input) for mailman id 857573;
 Mon, 16 Dec 2024 08: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 1tN6JI-0000tP-5i
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 08:18:36 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20608.outbound.protection.outlook.com
 [2a01:111:f403:2418::608])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 56bdece6-bb86-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 09:18:33 +0100 (CET)
Received: from IA1PR12MB6532.namprd12.prod.outlook.com (2603:10b6:208:3a3::12)
 by MW3PR12MB4442.namprd12.prod.outlook.com (2603:10b6:303:55::14)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Mon, 16 Dec
 2024 08:18:30 +0000
Received: from IA1PR12MB6532.namprd12.prod.outlook.com
 ([fe80::dc05:a63a:39fa:ff0b]) by IA1PR12MB6532.namprd12.prod.outlook.com
 ([fe80::dc05:a63a:39fa:ff0b%7]) with mapi id 15.20.8251.015; Mon, 16 Dec 2024
 08:18: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: 56bdece6-bb86-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QF/CwT3OS/uzWTNW0e2AiZaHGDRKBAb6SoOU3SPZ5usa3Ajnw3o2kD/MzCPQ33g0eQd1WrjgJohlPMC4rN1LBr6revDrvSzswZ92zs18GqtUoUtDUrBhCZdnZGiZpN/slZ/yZqN8HbV5LtpR4yFYSnGM59fmxszEa7pL1gPRw9wFNsE/DbeSrRfpbR4D1AXyVPRhcnfW6hg8vA0305L5gZMv8bWi/+RXJunCTKV95dLsfVfOWf89zJff/hylhiaoDekYdHqbZzdiR0QXyVlEH2go8fBK9YZtQNTdMnKXWe7AIQ9qnoHZSq8J/uJC+u5RfG3GLhLUwHKmLrTITYMIWA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=645zXlLl0I1RyA5pElv0FV4s04T3SIqtsw3PIadqNrs=;
 b=p0WAzr8ysK2hIVNRuCVgX8MlOz7N3Z7h3VJVz1ftFEvkMPLvJSQtPtjs7VO2uJUgoRwHlDPoOWtc8Pyd6XvmnXXlgGf4/3Bkm8jBdUJ4IERXQG79lJ4eBpy+4mCNZXLIvIDS+jIk7fABrllzg8EZc6iqx83vSFhUsNz2DwA8oQQ+k1TneKiNdnSeOJJOqbTFzD6SEKOaR8t5jUbwzWpgROIALIQXSJo4Z9c1BKnwLRzoJS5f8t8EttJikRsYicCP1ML8vSN8uNNvkrWVnJg/jL+jcr+pEAcFb7QgYmKya10Z3k10VmQejeoHuauL3xnE9Eh0V/BBn8cM5FVy4ApdCw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=645zXlLl0I1RyA5pElv0FV4s04T3SIqtsw3PIadqNrs=;
 b=Iz38x7Cj0M45+Fa+Md2cGJ59kpcqE1t0zeccBMTDFfpxDTSJEMLe32O0EGmZ3eMtViaNaY7ULmDNPL5DdKrXZxm/WtSMq1cHtWll8C/6nSFZ4ugInVv93aZOA457K+sKw2JDHhscPwR5NDyBvk8XOCDiF8ffFkvAtIoONfQ2jGs=
From: "Zhang, Julia" 
To: Jan Beulich , Stefano Stabellini
	
CC: "Deucher, Alexander" , "Koenig, Christian"
	, Xenia Ragiadakou , "Chen,
 Jiqian" , "Huang, Ray" , "Penny,
 Zheng" , "Zhu, Lingshan" , Paul
 Durrant , "Edgar E . Iglesias" ,
	"Michael S . Tsirkin" , Marcel Apfelbaum
	, Juergen Gross , Oleksandr
 Tyshchenko , Anthony PERARD
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "xen-devel@lists.xenproject.org"
	
Subject: Re: [PATCH] xen: add privcmd ioctl to get p2pdma_distance
Thread-Topic: [PATCH] xen: add privcmd ioctl to get p2pdma_distance
Thread-Index: AQHbSJdDNMdfRsD4vkSvz8Ngpfn4L7LdjBaAgAuOxQA=
Date: Mon, 16 Dec 2024 08:18:29 +0000
Message-ID:
 
References: <20241207105946.542491-1-julia.zhang@amd.com>
 <03504a1e-c801-47fc-ac66-ab7e10ab6695@suse.com>
In-Reply-To: <03504a1e-c801-47fc-ac66-ab7e10ab6695@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: IA1PR12MB6532.namprd12.prod.outlook.com
 (15.20.8251.004)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: IA1PR12MB6532:EE_|MW3PR12MB4442:EE_
x-ms-office365-filtering-correlation-id: 43ad07c4-f19d-4b13-ee8f-08dd1daa395d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|366016|1800799024|7416014|376014|8096899003|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?empwdzVEc1Nubm5FclBBZ2dRL29uaDk4WUVPVFVjWW4yRmtJa2FUS0xXT2dv?=
 =?utf-8?B?TVlORFduNC9VTVF4bUxiMXBnemZpNUx2V2JMRU1vMjBNSGlqOFdjK2tVaXdO?=
 =?utf-8?B?SXVXZWhxMnlsaGMyV2t4SkZmbUViVlVYa3VCY1N1UW04UkdhbGRScTFnUFVl?=
 =?utf-8?B?bXA3bm9RaUs3R2syVGVUcCt2WWRUbFJ5M2wvSlE5YW5pSEpOR2w3MzRYc3FL?=
 =?utf-8?B?TUVnaFZiL0tEcDZtdHFCSlg0eEpyN3lhaEIwNTZlU1FaaUN5b2FiVTlhbUpn?=
 =?utf-8?B?QVNEUnZKU2xJSThqcnZKcGoybU91SjJ4QlhkakhJYTJTeXU4WmZrRlk4R2cz?=
 =?utf-8?B?RXFnL0ZLRStqZnFsd3hxZ3cwdm9POFIwYS9yYzlrckdhMzBIUk5ibW5TbXFm?=
 =?utf-8?B?TThVUExMdldWTzVHYzVTRHZvZjBBenpsd2Roa0FGaTJHcXpqYTNHbEJPcUZv?=
 =?utf-8?B?VUp2VkY3SEdHaDFUUk4rN3lwdmJBa2ZOK3lyL1FmUzhLd3J1dEVxRDZ1NHNu?=
 =?utf-8?B?SitJVmNLRzc4U2g4RFViR0RxSVBFUXgrSCtnMXgrVUJLRnp3eDl5aDNnRWcr?=
 =?utf-8?B?TE9VMGZ3YVdmbTFZQmNIaTkwRzl1TDU4d0NJNUQwZGVaNWNQOFg3OTlxdjM4?=
 =?utf-8?B?ZytPNm4xRFRrVWFsaVl1S3NSeno4ZTNtMkZOT3I2eDhoTGp0OVB0R1FlcGdD?=
 =?utf-8?B?Y2xPdFZDUldiVzZiT2JvV3o1QWNtb2YwTW5NRG1CNStPK3pONHl3azdCNTBF?=
 =?utf-8?B?YVgxQXpZZ0JOUmorRjhIUFBjU3cvTnhHcnVxQ1o3cHpob0dpZzlqZXk0T0VB?=
 =?utf-8?B?THdUTlM2YUM5bGh3KzlYaFlqN1k2cEdNOE1QOG9QSDNMNTJwV3kvVFZ2OTNk?=
 =?utf-8?B?K0NJdGNoU1VVeEpNUEtFRFJFUUQ5WkRUb1FJWnVxNHpmQ0JkenZxWkVGR05w?=
 =?utf-8?B?MFkyMnA1MTF6aWFZa2MrMFRhMEhyWHRaZjV2ekdCc3gxb2RQWkNLSTRBNUFI?=
 =?utf-8?B?MjJ0djZqQmg1eUxPUFU3ajR1ODJnWEI3ckpBMVRaQ1J0cVVSZEE2YmxsU2E3?=
 =?utf-8?B?UTE5dXRveGpqeHh4c2hFblJpUElZa1R4UUhJdFZXekR2N1dnUGtwRVBNTGda?=
 =?utf-8?B?TTlQSk11NE1sN1U5N0Jmd2kzOVEraUlDdEZTR1J0R2pZU3kxUFM5eVh2SGdH?=
 =?utf-8?B?dTFsaGFCSjR3WStqNzVGUk9GejZBcmhvN0pFWXdXVnRnUnptS01CY1h1bDdr?=
 =?utf-8?B?UnpMUEM1QmUrNjYxSml3RGZITDI2aFFZMk0rcXBabFVXSnpjQ2lQNTNOQkpI?=
 =?utf-8?B?VWpiOGtBOFNsODRnbytadERIS1R5eWV0aGI4NVJES2NTL2JLajlxRDl6ZnU0?=
 =?utf-8?B?NllwVnB1ajVGQTJlTlZDaURRUmFydjZNN1hJUFVwbjRkd0x6dko2bTVJaTZH?=
 =?utf-8?B?M2JHNWJqcGRXZVY5eHh0eWNlWUlIa3ZEcWJ1a3BFVThUanFwUEJKSVZ5dC8z?=
 =?utf-8?B?MU1rUGg4ZnVHWHNFemNDbUgvTDMydGVIalM4RTRXZzc1YU5kdVNrUHh6NUti?=
 =?utf-8?B?NEZuMFlmZTFWb0h5SkU5MWNCSFoza2tRZWxvT2l5VGY5RVVRaC9wL3o2ZXA4?=
 =?utf-8?B?dGM5b29qUVBHUGxNV0ZuU1UzSU13UUpGOEVMS1dsck5wZWhGZ1Q1YXV3eUo4?=
 =?utf-8?B?RkxBbWQ5VjVHM2tZOGg5bExYcFl3MHJQMXlYNE8yM1lpNVhZbysxNlBJdXZV?=
 =?utf-8?B?VTZTUmtNQnBhM3JTaTJRWng4cUh6TnZiZnZDSVlqbVhVRktyS1R1UEx1MVA4?=
 =?utf-8?B?UHJZQkZsVlRaNXA5aTREbzM5cFFHYUc1eENNcXYwSnllZVNUWW1ya1hsTzZH?=
 =?utf-8?B?Z3pzTUwrcW43L3hpcUF5Mk5MWFRyUTBvMlJ2dVR3NFlTMG01MFI4SzNPWlJu?=
 =?utf-8?Q?IOg0chgQo/DKrXmQBEhLt6/3cDdk+ldj?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA1PR12MB6532.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014)(8096899003)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?SHdLaVJZQ2ExK09kM0dSaGlJK1VCMzhxcW5wN2NoQlV5ZGVQczdjRk1rbkJK?=
 =?utf-8?B?VXB5N1orOEdJZ3p4eGM3NGlzZG1MTU5oRHFBZ2JHYnRvcjRnc3Y1anpmNWdi?=
 =?utf-8?B?L3FnUFB6eHJQcDVMRjM1QXFndW5XUENLSzZDZnZpeGljOFZLUngzRHRDSFdq?=
 =?utf-8?B?N3NtWVhnK3ovMVo2Zkw4bkd2bXV2U1F5aTRlSUQ4eVMxMFpGMnB3MjZ2SjFa?=
 =?utf-8?B?eXJWZXprZm5hbFY3K21oQjhUMzVybVJiWlYyelNHVlFQRlBWK3RGM0F1cElJ?=
 =?utf-8?B?SHQ3Vi9wNCtlNnNmcEppaVdhTVQweHZ2aC9xTmNWRDVDUmg2L29NNHZJZDln?=
 =?utf-8?B?UEZYbGMyUjQvVmZVZkdJbEYxakNmd3NNeElQVDhYMjNEWG9DTjBrb0V6U1JV?=
 =?utf-8?B?QzhlYjV4TlR5ejE1cHZPWUp4YU1aSW53dytBMCtNTkEvN0xLV09QVlBMSWJm?=
 =?utf-8?B?czc5WXNzZ0VBcllyRmNzRTZHK2NJSkhMM01aUTdpaVZLdkloN0lCM0xZeDAy?=
 =?utf-8?B?S2RZSXg4SzVEN2V5aU1PYnI2dW9mUlJPV2pOazRDK3hwbWJwZHVTY08ySWJo?=
 =?utf-8?B?ZXllYndxbCtHVjVEUkFXanBxWjhiNGhJVDhzZHlFUGxSKzNBaDhJY2RGeFdH?=
 =?utf-8?B?blFrcnpKMThxSFZVUkxWNXpneVVhK3FPdVovbDNGMXlna00rbnF5NURuVURH?=
 =?utf-8?B?NG52VGNOTGQ4OWJrQXR6RnZpcDliVFVlbjAwdHhtTHRaK04vdUxTcjY5eDJl?=
 =?utf-8?B?WDdobnVPalUySXY4STl0NFo3UmxRRzFBWkZXdURRNXZzZkphVmxmYUk0aDhi?=
 =?utf-8?B?ZjRhN0FraDZYSVczbFdWUWZTOU5pMmJCTjNTYWNWWUdFV2tjSTNOQU9XZjBi?=
 =?utf-8?B?WWNndHVmQUFlTVkwMno4bGxNOXM1REk5UjNHWndBSnhoM0tRZTN3dFNFZllG?=
 =?utf-8?B?UkV4U2gvSWhoZ2F0Sm1Pa1phRnNxWFYrSDZSWUozWlJ0MGRmRjl0TzVNVDAx?=
 =?utf-8?B?YUpDWk5UcUYvWUdGTWlPUFlTazNUMjdSemVtU09zdDNWeVBtN2Z4OTJrSkVS?=
 =?utf-8?B?eE8rbDVzd3BMY0kwait1cWtKRUFDM3B4ZGloMCtXM0dGV2R1czFEemE1dHAw?=
 =?utf-8?B?WFd2WFhYTUYyYUppU2ZzYlAwaCtwckoxYW1YdmsvVjNwcXNySmNpYlVaTTJw?=
 =?utf-8?B?YWdFVjM3VkxheXB6L1pPcUduVXpLeStvRjJoVVZyNE9PMWVHWW14THBTVTBM?=
 =?utf-8?B?M244dEpnZnRtVlpVYkJ3bzV3OVRWNUc5YzhZUFNwazZ2R2FjcWtkV1FiRkZm?=
 =?utf-8?B?WSsvT3RkNlFHMG0rajcwYjNDOGFBM3pmd0h4bTQyTHBGUTRFRU5yaEtqdkZK?=
 =?utf-8?B?SlpWUHJwbWVINFJobmlsYi83azE3Q2kwbnVVTjk5clY3YzdjT0JuWWJ2OXlW?=
 =?utf-8?B?STBobkNReXlmL0gzeEc2dUx2Njk5UCtrblNPQ1VZVnRqclRPUWpLVk5hMllG?=
 =?utf-8?B?WkU2aVczeGs4elRkNVVpZldsOW5lR2FIWTE1UHo4ZWRyZzYwNStPVGNpMVZi?=
 =?utf-8?B?N3pqeUp2UVQyVGtOak9LWlkvVjBIZkRuaThvb3NQOHVlbGkyTXJEekNGMWcy?=
 =?utf-8?B?MWNkRnhoWnV3NXd4NmRjUkVYdVdPMWtDNW5GeHFUaE1rNG91MGJqa3V2L0JP?=
 =?utf-8?B?SWNzS0VMQ2FRMmllbVZEVi8rODRJTFBwMldIaWlVeXdoam9kZGJWUktuTWVQ?=
 =?utf-8?B?RFUvNXV1SWtOTlg1dWNuZUMwMitiZ3NURXk5Tm1YblhhaVZWWk9qYk9KeFhO?=
 =?utf-8?B?TllSc2d5alBhak9VSmdCTndjQlViRlFjdTlieE85WHJwQ0dTZ1ZObmlhbHYx?=
 =?utf-8?B?emloZW1hYkxxWTFQQ056K0FLMkRuZ0Yvb1pDeGI0aUtBR1huZzBxVnB2V3h2?=
 =?utf-8?B?Z0wzWGdlclpCSDNGRGRzNjhaM3lOTHMxSngwNmZvZjlZdFZkcjZmTkJybXdp?=
 =?utf-8?B?Z3E1SStUa0hSMEVqVUJZU1RSTnV0aFJDdGhLVnVTZUNPdSswbG1PK2dEdUcx?=
 =?utf-8?B?bDFDemZvOVZLTXc5amVjdXRYWFlwTGNpNTBuaVYwT2tJR1pYazV3ZU9LajA1?=
 =?utf-8?Q?GOpk=3D?=
Content-Type: multipart/alternative;
	boundary="_000_IA1PR12MB6532F32D012A63000F34823AF23B2IA1PR12MB6532namp_"
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: IA1PR12MB6532.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 43ad07c4-f19d-4b13-ee8f-08dd1daa395d
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2024 08:18:30.0171
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Np0xqysFHYuXg3Aq1bxLg4YJOMla97kOCE2iGA7/esyzdMwDYd8RYYg9fWYW5ek/bodjX2BAz+7Vv6LdtcQC1w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR12MB4442

--_000_IA1PR12MB6532F32D012A63000F34823AF23B2IA1PR12MB6532namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpPbiAyMDI0LzEyLzkgMTU6NDcsIEphbiBCZXVsaWNoIHdyb3RlOg0KDQpPbiAwNy4xMi4yMDI0
IDExOjU5LCBKdWxpYSBaaGFuZyB3cm90ZToNCg0KVG8gaW1wbGVtZW50IGRHUFUgcHJpbWUgZmVh
dHVyZSwgdmlydGdwdSBkcml2ZXIgbmVlZCB0byBnZXQNCg0KcDJwZG1hX2Rpc3RhbmNlIG9mIHR3
byBHUFUgZnJvbSBob3N0IHNpZGUuDQoNCg0KDQpUaGlzIGFkZHMgYSBuZXcgcHJpdmNtZCBpb2N0
bCB0byBnZXQgdGhlIHJlYWwgcDJwZG1hX2Rpc3RhbmNlIG9mIHR3byBwY2kNCg0KZGV2aWNlcyBp
biB0aGUgaG9zdCB3aXRoIHBjaSBub3RhdGlvbnMgc2VudCBmcm9tIGd1ZXN0IHNpZGUuDQoNCg0K
DQpTaWduZWQtb2ZmLWJ5OiBKdWxpYSBaaGFuZyA8anVsaWEuemhhbmdAYW1kLmNvbT48bWFpbHRv
Omp1bGlhLnpoYW5nQGFtZC5jb20+DQoNCg0KDQpGaXJzdCAtIGNvcnJlY3RpbmcgQW50aG9ueSdz
IGVtYWlsIGFkZHJlc3MuIEhlJ3Mgbm8gbG9uZ2VyIGF0IENpdHJpeC9DbG91ZC4NClRoYW5rIHlv
dSBmb3IgcmVtaW5kaW5nIG1lIGFuZCBjb3JyZWN0aW5nIGl0Lg0KDQoNCg0KDQoNClNlY29uZCwg
cGxlYXNlIHNlbmQgcGF0Y2hlcyBUbzogdGhlIGxpc3QsIHdpdGggbWFpbnRhaW5lcnMgb24gQ2M6
LiAoU3RlZmFubywNCg0KYXMgdGhpcyBpc24ndCB0aGUgZmlyc3Qgc3VjaCBpc3N1ZSwgY2FuIHlv
dSBwbGVhc2UgdHJ5IHRvIHNwcmVhZCB0aGUNCg0Ka25vd2xlZGdlIG9mIHRoaXMgYWNyb3NzIHBl
b3BsZSBzdGFydGluZyB0byBjb250cmlidXRlPykgUGVyc29uYWxseSBJJ2QNCg0KcXVlc3Rpb24g
dGhlIGxlbmd0aCBvZiB0aGUgQ2M6IGxpc3Qgb2YgdGhpcyBzdWJtaXNzaW9uLCB0aG91Z2guIFBs
dXMgLSBhbG9uZw0KDQp3aXRoIFJvZ2VyIEkgd2FzIG9uIHRoZSBUbzogbGlzdCBoZXJlIGRlc3Bp
dGUgbm90IGV2ZW4gYmVpbmcgbWFpbnRhaW5lciBvZg0KDQphbnkgb2YgdGhlIGZpbGVzIHRvdWNo
ZWQuDQpTb3JyeSBmb3IgYm90aGVyaW5nIHlvdSBhbmQgSSB3aWxsIG1vZGlmeSB0aGUgbGlzdHMg
bmV4dCB0aW1lLiBUaGFua3MgZm9yIHJldmlld2luZyB0aGlzIHBhdGNoLg0KDQoNCg0KDQoNCi0t
LSBhL3Rvb2xzL2luY2x1ZGUveGVuLXN5cy9MaW51eC9wcml2Y21kLmgNCg0KKysrIGIvdG9vbHMv
aW5jbHVkZS94ZW4tc3lzL0xpbnV4L3ByaXZjbWQuaA0KDQpAQCAtMTEwLDYgKzExMCwxNiBAQCB0
eXBlZGVmIHN0cnVjdCBwcml2Y21kX21hcF9odmFfdG9fZ3BmbnMgew0KDQogICBpbnQgYWRkX21h
cHBpbmc7DQoNCiB9IHByaXZjbWRfbWFwX2h2YV90b19ncGZuc190Ow0KDQoNCg0KK3R5cGVkZWYg
c3RydWN0IHByaXZjbWRfcDJwZG1hX2Rpc3RhbmNlIHsNCg0KKyAgX191MzIgcHJvdmlkZXJfYnVz
Ow0KDQorICBfX3UzMiBwcm92aWRlcl9zbG90Ow0KDQorICBfX3UzMiBwcm92aWRlcl9mdW5jOw0K
DQorICBfX3UzMiBjbGllbnRfYnVzOw0KDQorICBfX3UzMiBjbGllbnRfc2xvdDsNCg0KKyAgX191
MzIgY2xpZW50X2Z1bmM7DQoNCisgIF9fdTMyIGRpc3RhbmNlOw0KDQorfSBwcml2Y21kX3AycGRt
YV9kaXN0YW5jZV90Ow0KDQoNCg0KIkRpc3RhbmNlIiB0eXBpY2FsbHkgaXMgYSBzeW1tZXRyaWMg
dGhpbmcuIFdoeSB0aGUgYXN5bW1ldHJ5IGhlcmU/IEFuZA0KDQp3aHkgX191MzIgd2hlbiBfX3U4
IHdpbGwgYmUgZmluZSBmb3IgbW9zdCBmaWVsZHM/IEFuZCB3aGVyZSdzIHRoZSBzZWdtZW50DQoN
CnBhcnQgb2YgdGhlIGRldmljZSBjb29yZGluYXRlcz8gRmluYWxseSwgd2l0aCBpdCBiZWluZyBt
ZXJlbHkgc3R1Yg0KDQppbXBsZW1lbnRhdGlvbnMgdGhhdCB5b3UgYWRkIGhlcmUsIGFsbCBkZXRh
aWxzIG9uIHdoZXJlIHRoZSBuZWVkZWQgaW5mbw0KDQppcyB0byBjb21lIGZyb20gYXJlIG1pc3Np
bmcuDQoNCiJEaXN0YW5jZSIgaXMgcDJwZG1hLWRpc3RhbmNlIGJldHdlZW4gdHdvIFBDSSBkZXZp
Y2VzLCBpdCdzIGNhbGN1bGF0ZWQgaW4ga2VybmVsIGRyaXZlci5JIGRvbid0IGdldCB3aHkgaXQn
cyBzeW1tZXRyaWM/DQoNCkkgd2lsbCB1c2UgY2hhbmdlIF9fdTMyIHRvIF9fdTguDQoNCkJ5IHRo
ZSBzZWdtZW50IHBhcnQgb2YgdGhlIGRldmljZSBjb29yZGluYXRlcywgZG8geW91IG1lYW4gdGhl
IGRvbWFpbiBudW1iZXIgb2YgdGhlIGRldmljZT8NCg0KQWxsIHRoZSBuZWVkZWQgaW5mbyh2aXJ0
dWFsIGJ1cy9zbG90L2Z1bmN0aW9uIG51bWJlcnMpIGFyZSBmcm9tIGd1ZXN0IFZNLCBRRU1VIGNv
bnZlcnQgdGhlbSB0byByZWFsIHBoeXNpY2FsIGluZm8gb2YgdHdvIGRldmljZXMuDQoNCkRvIHlv
dSBtZWFuIHRoYXQgSSBzaG91bGQgYWRkIG1vcmUgZGV0YWlscyBpbiBjb21taXQgbWVzc2FnZSBv
ciBjb21tZW50Pw0KDQpKdWxpYQ0KDQoNCg0KDQoNCkphbg0K

--_000_IA1PR12MB6532F32D012A63000F34823AF23B2IA1PR12MB6532namp_
Content-Type: text/html; charset="utf-8"
Content-ID: <3AE6C7A518E1DF40ABE6766D7E9D73B3@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx
IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpBcHRvczt9DQpAZm9udC1mYWNlDQoJe2Zv
bnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBm
b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAg
MyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N
c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTIuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJBcHRvcyIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlw
ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t
c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglmb250
LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJl
Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7
DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h
dHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5zcGVsbGUNCgl7bXNvLXN0eWxl
LW5hbWU6c3BlbGxlO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNv
bmFsLWNvbXBvc2U7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u
bHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCgltc28tbGlnYXR1cmVzOm5vbmU7fQ0KQHBhZ2UgV29y
ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp
biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv
c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl
ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv
IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i
ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv
aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHls
ZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIw
MjQvMTIvOSAxNTo0NywgSmFuIEJldWxpY2ggd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPHByZT5PbiAwNy4xMi4yMDI0IDExOjU5LCBKdWxpYSBaaGFuZyB3cm90ZTo8bzpwPjwvbzpw
PjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8cHJlPlRvIGltcGxlbWVudCBkR1BVIHByaW1lIGZlYXR1cmUsIHZpcnRncHUg
ZHJpdmVyIG5lZWQgdG8gZ2V0PG86cD48L286cD48L3ByZT4NCjxwcmU+cDJwZG1hX2Rpc3RhbmNl
IG9mIHR3byBHUFUgZnJvbSBob3N0IHNpZGUuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhpcyBhZGRzIGEgbmV3IHByaXZjbWQgaW9jdGwgdG8g
Z2V0IHRoZSByZWFsIHAycGRtYV9kaXN0YW5jZSBvZiB0d28gcGNpPG86cD48L286cD48L3ByZT4N
CjxwcmU+ZGV2aWNlcyBpbiB0aGUgaG9zdCB3aXRoIHBjaSBub3RhdGlvbnMgc2VudCBmcm9tIGd1
ZXN0IHNpZGUuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmU+U2lnbmVkLW9mZi1ieTogSnVsaWEgWmhhbmcgPGEgaHJlZj0ibWFpbHRvOmp1bGlhLnpo
YW5nQGFtZC5jb20iPiZsdDtqdWxpYS56aGFuZ0BhbWQuY29tJmd0OzwvYT48bzpwPjwvbzpwPjwv
cHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5G
aXJzdCAtIGNvcnJlY3RpbmcgQW50aG9ueSdzIGVtYWlsIGFkZHJlc3MuIEhlJ3Mgbm8gbG9uZ2Vy
IGF0IENpdHJpeC9DbG91ZC48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5UaGFuayB5b3UgZm9yIHJlbWluZGluZyBtZSBhbmQgY29ycmVjdGlu
ZyBpdC48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5TZWNvbmQsIHBsZWFzZSBzZW5kIHBhdGNo
ZXMgVG86IHRoZSBsaXN0LCB3aXRoIG1haW50YWluZXJzIG9uIENjOi4gKFN0ZWZhbm8sPG86cD48
L286cD48L3ByZT4NCjxwcmU+YXMgdGhpcyBpc24ndCB0aGUgZmlyc3Qgc3VjaCBpc3N1ZSwgY2Fu
IHlvdSBwbGVhc2UgdHJ5IHRvIHNwcmVhZCB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5rbm93
bGVkZ2Ugb2YgdGhpcyBhY3Jvc3MgcGVvcGxlIHN0YXJ0aW5nIHRvIGNvbnRyaWJ1dGU/KSBQZXJz
b25hbGx5IEknZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnF1ZXN0aW9uIHRoZSBsZW5ndGggb2Yg
dGhlIENjOiBsaXN0IG9mIHRoaXMgc3VibWlzc2lvbiwgdGhvdWdoLiBQbHVzIC0gYWxvbmc8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT53aXRoIFJvZ2VyIEkgd2FzIG9uIHRoZSBUbzogbGlzdCBoZXJl
IGRlc3BpdGUgbm90IGV2ZW4gYmVpbmcgbWFpbnRhaW5lciBvZjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPmFueSBvZiB0aGUgZmlsZXMgdG91Y2hlZC48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1
b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Tb3JyeSBmb3IgYm90aGVyaW5nIHlvdSBhbmQg
SSB3aWxsIG1vZGlmeSB0aGUgbGlzdHMgbmV4dCB0aW1lLiBUaGFua3MgZm9yIHJldmlld2luZyB0
aGlzIHBhdGNoLjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+LS0tIGEvdG9vbHMvaW5jbHVk
ZS94ZW4tc3lzL0xpbnV4L3ByaXZjbWQuaDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPisrKyBiL3Rv
b2xzL2luY2x1ZGUveGVuLXN5cy9MaW51eC9wcml2Y21kLmg8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5AQCAtMTEwLDYgKzExMCwxNiBAQCB0eXBlZGVmIHN0cnVjdCBwcml2Y21kX21hcF9odmFfdG9f
Z3BmbnMgezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiAmbmJzcDsgaW50IGFkZF9tYXBwaW5nOzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiB9IHByaXZjbWRfbWFwX2h2YV90b19ncGZuc190OzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4rdHlwZWRlZiBzdHJ1
Y3QgcHJpdmNtZF9wMnBkbWFfZGlzdGFuY2UgezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPismbmJz
cDsgX191MzIgcHJvdmlkZXJfYnVzOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPismbmJzcDsgX191
MzIgcHJvdmlkZXJfc2xvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4rJm5ic3A7IF9fdTMyIHBy
b3ZpZGVyX2Z1bmM7PG86cD48L286cD48L3ByZT4NCjxwcmU+KyZuYnNwOyBfX3UzMiBjbGllbnRf
YnVzOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPismbmJzcDsgX191MzIgY2xpZW50X3Nsb3Q7PG86
cD48L286cD48L3ByZT4NCjxwcmU+KyZuYnNwOyBfX3UzMiBjbGllbnRfZnVuYzs8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4rJm5ic3A7IF9fdTMyIGRpc3RhbmNlOzxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPit9IHByaXZjbWRfcDJwZG1hX2Rpc3RhbmNlX3Q7PG86cD48L286cD48L3ByZT4NCjwvYmxv
Y2txdW90ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+JnF1b3Q7RGlzdGFu
Y2UmcXVvdDsgdHlwaWNhbGx5IGlzIGEgc3ltbWV0cmljIHRoaW5nLiBXaHkgdGhlIGFzeW1tZXRy
eSBoZXJlPyBBbmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT53aHkgX191MzIgd2hlbiBfX3U4IHdp
bGwgYmUgZmluZSBmb3IgbW9zdCBmaWVsZHM/IEFuZCB3aGVyZSdzIHRoZSBzZWdtZW50PG86cD48
L286cD48L3ByZT4NCjxwcmU+cGFydCBvZiB0aGUgZGV2aWNlIGNvb3JkaW5hdGVzPyBGaW5hbGx5
LCB3aXRoIGl0IGJlaW5nIG1lcmVseSBzdHViPG86cD48L286cD48L3ByZT4NCjxwcmU+aW1wbGVt
ZW50YXRpb25zIHRoYXQgeW91IGFkZCBoZXJlLCBhbGwgZGV0YWlscyBvbiB3aGVyZSB0aGUgbmVl
ZGVkIGluZm88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pcyB0byBjb21lIGZyb20gYXJlIG1pc3Np
bmcuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwPiZxdW90O0Rpc3RhbmNlJnF1
b3Q7IGlzIHAycGRtYS1kaXN0YW5jZSBiZXR3ZWVuIHR3byBQQ0kgZGV2aWNlcywgaXQncyBjYWxj
dWxhdGVkIGluIGtlcm5lbA0KPHNwYW4gY2xhc3M9InNwZWxsZSI+ZHJpdmVyLkk8L3NwYW4+IGRv
bid0IGdldCB3aHkgaXQncyBzeW1tZXRyaWM/PG86cD48L286cD48L3A+DQo8cD5JIHdpbGwgdXNl
IGNoYW5nZSBfX3UzMiB0byBfX3U4LjxvOnA+PC9vOnA+PC9wPg0KPHA+QnkgdGhlIHNlZ21lbnQg
cGFydCBvZiB0aGUgZGV2aWNlIGNvb3JkaW5hdGVzLCBkbyB5b3UgbWVhbiB0aGUgZG9tYWluIG51
bWJlciBvZiB0aGUgZGV2aWNlPzxvOnA+PC9vOnA+PC9wPg0KPHA+QWxsIHRoZSBuZWVkZWQgaW5m
byh2aXJ0dWFsIGJ1cy9zbG90L2Z1bmN0aW9uIG51bWJlcnMpIGFyZSBmcm9tIGd1ZXN0IFZNLCBR
RU1VIGNvbnZlcnQgdGhlbSB0byByZWFsIHBoeXNpY2FsIGluZm8gb2YgdHdvIGRldmljZXMuPG86
cD48L286cD48L3A+DQo8cD5EbyB5b3UgbWVhbiB0aGF0IEkgc2hvdWxkIGFkZCBtb3JlIGRldGFp
bHMgaW4gY29tbWl0IG1lc3NhZ2Ugb3IgY29tbWVudD88bzpwPjwvbzpwPjwvcD4NCjxwPkp1bGlh
PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SmFuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2tx
dW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_IA1PR12MB6532F32D012A63000F34823AF23B2IA1PR12MB6532namp_--


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 08:35:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 08:35:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857587.1269806 (Exim 4.92)
	(envelope-from )
	id 1tN6Zq-0003tF-BK; Mon, 16 Dec 2024 08:35:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857587.1269806; Mon, 16 Dec 2024 08:35: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 1tN6Zq-0003t8-8t; Mon, 16 Dec 2024 08:35:42 +0000
Received: by outflank-mailman (input) for mailman id 857587;
 Mon, 16 Dec 2024 08:35: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 1tN6Zp-0003t2-Gy
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 08:35:41 +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 badda2c8-bb88-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 09:35:39 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-4361b6f9faeso22816625e9.1
 for ; Mon, 16 Dec 2024 00:35:39 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436362c7d64sm77467795e9.36.2024.12.16.00.35.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 16 Dec 2024 00:35:38 -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: badda2c8-bb88-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734338139; x=1734942939; 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=b+kCnh5k/m/swwkPB23/AzEj4XU0ioEDBXZoejXDJJk=;
        b=EZyBChE20gqYJLHScX0Hln7FL1g9yK7YZpAk6oDyW3H5LLDKvIO2O40Jehu46JVDCy
         mRuuqggubkIWea+z+N32oYDnKooea+NK1gkPzz6+fs/mtZ5bqURvj0jfOLVkYMPuYvrf
         KEuloKKAYWnY1LBOiBWyi37QTi5GbBmI4HtPI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734338139; x=1734942939;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=b+kCnh5k/m/swwkPB23/AzEj4XU0ioEDBXZoejXDJJk=;
        b=AQJRg2PIY+lDrcLvGer4Hl9ASCW49guk1yhrTwqhiWKX4NBPSbMZqTRclMjYfBHXdw
         7DoIFap6IdPKeVrMzm3R+7se/09PYiB8Vadwij4mHK2Fm4PsYRPT5CM6fOq/Y09gSbkg
         wDfavaDUyxeP7I2MJU8hHrlv5gkocw9RzBvPgOVaZUe0pqYp/dvtyGPkSqInXvKoELb4
         7T2nQ/te58Ye3rGDckw/p5qr+3cvqjFbrClXpA9f48UwYjrjlK8O8XlHF/YX5l23+1N+
         UfCghcQHZWuI0hdb/ktr+Ltjh5COL/Vy5/8elPiCqI9LbYkt1MeTCi7IDQLQ4uXyd3Q7
         0JlQ==
X-Forwarded-Encrypted: i=1; AJvYcCU8RwLyd6YmElj4rbZqREmvb0t8lh4/2mmAeYXrMfbEamA2nCQX2+UUWaRaX6BWp1F7qLOcR7jv+3s=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx6NEqUQLZ2FA7jNs1AZVhttrzeq5A6oFp7pK/gu8ZlhCsjotjm
	o4zUVCvzJI29aXlClNcKF1NEws69V016RcPBvV5c41JELxYBrvetlF+xCrDwPus=
X-Gm-Gg: ASbGncvl5OFqrBHAKdc65FPO3VCFf3yHGW9SUipTktRWTz8ERGagGayD1JPgoqAO62h
	4qr1RklqfenxZHygpBrLjq+nNcIL5MtPm6ZMJn1m4g2idyUZqmUQ6M60qM/6zwBe7BSq8t8QQj4
	OZTBIvdY7X/R9osx07PpHNG3dC68mVUqb9KNam12r9L4LFuX8nJZfckU75dBZvbwAYDfvu/W6/W
	HQJXG+StKd4gur7iv1f4yTkFfZdK9Xez3K5rzhIgegiWzsOJyI9O+aUTyPHPQ==
X-Google-Smtp-Source: AGHT+IF2AkHOESqAxDd6U9/vIdN3J+EE9lZif0AH9SjNfR2HCQXmTb9lLjLhQjkyBzWFxRyme53vFg==
X-Received: by 2002:a05:600c:2306:b0:434:e892:1033 with SMTP id 5b1f17b1804b1-4362309dd0emr123846055e9.2.1734338139319;
        Mon, 16 Dec 2024 00:35:39 -0800 (PST)
Date: Mon, 16 Dec 2024 09:35:37 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= ,
	Oleksii Kurochko 
Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] tools/xg: increase LZMA_BLOCK_SIZE for uncompressing the
 kernel
Message-ID: 
References: <20241008213225.728922-1-marmarek@invisiblethingslab.com>
 <226bc9b3-6741-4cb6-917b-1164e340a19d@suse.com>
 
 <00ac0665-e4ff-4a56-8537-e81573710c3c@suse.com>
 
 
 <99089b03-e9f0-4fe8-94b2-11e75f9e5243@suse.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

Adding Oleksii, as this IMO wants to be a blocker for 4.20.

On Wed, Oct 09, 2024 at 03:03:28PM +0200, Marek Marczykowski-Górecki wrote:
> On Wed, Oct 09, 2024 at 01:38:32PM +0200, Jürgen Groß wrote:
> > On 09.10.24 13:15, Jan Beulich wrote:
> > > On 09.10.2024 13:08, Andrew Cooper wrote:
> > > > On 09/10/2024 11:26 am, Juergen Gross wrote:
> > > > > On 09.10.24 12:19, Jan Beulich wrote:
> > > > > > On 09.10.2024 11:52, Marek Marczykowski-Górecki wrote:
> > > > > > > On Wed, Oct 09, 2024 at 09:19:57AM +0200, Jan Beulich wrote:
> > > > > > > > On 08.10.2024 23:32, Marek Marczykowski-Górecki wrote:
> > > > > > > > > --- a/tools/libs/guest/xg_dom_bzimageloader.c
> > > > > > > > > +++ b/tools/libs/guest/xg_dom_bzimageloader.c
> > > > > > > > > @@ -272,8 +272,7 @@ static int _xc_try_lzma_decode(
> > > > > > > > >        return retval;
> > > > > > > > >    }
> > > > > > > > >    -/* 128 Mb is the minimum size (half-way) documented to work for
> > > > > > > > > all inputs. */
> > > > > > > > > -#define LZMA_BLOCK_SIZE (128*1024*1024)
> > > > > > > > > +#define LZMA_BLOCK_SIZE (256*1024*1024)
> > > > > > > > 
> > > > > > > > That's as arbitrary as before, now just not even with a comment at
> > > > > > > > least
> > > > > > > > hinting at it being arbitrary. Quoting from one of the LZMA API
> > > > > > > > headers:
> > > > > > > > 
> > > > > > > >       * Decoder already supports dictionaries up to 4 GiB - 1 B (i.e.
> > > > > > > >       * UINT32_MAX), so increasing the maximum dictionary size of the
> > > > > > > >       * encoder won't cause problems for old decoders.
> > > > > > > > 
> > > > > > > > IOW - what if the Linux folks decided to increase the dictionary size
> > > > > > > > further? I therefore wonder whether we don't need to make this more
> > > > > > > > dynamic, perhaps by peeking into the header to obtain the dictionary
> > > > > > > > size used. The one thing I'm not sure about is whether there can't be
> > > > > > > > multiple such headers throughout the file, and hence (in principle)
> > > > > > > > differing dictionary sizes.
> > > > > > > 
> > > > > > > What is the purpose of this block size limit? From the error
> > > > > > > message, it
> > > > > > > seems to be avoiding excessive memory usage during decompression (which
> > > > > > > could be DoS via OOM). If that's the case, then taking the limit from
> > > > > > > the kernel binary itself will miss this point (especially in case of
> > > > > > > pygrub or similar, but there may be other cases of not-fully-trusted
> > > > > > > kernel binaries).
> > > > > > 
> > > > > > Indeed. The question then simply is: Where do we want to draw the line
> > > > > > between what we permit and what we reject?
> > > > > 
> > > > > IMHO the most natural solution would be to use guest memory for this
> > > > > purpose.
> > > > > OTOH this probably would require a significant rework of libxenguest.
> > > > 
> > > > That was XSA-25.  There are toolstack-provided limits on kernel&initrd
> > > > sizes.
> > > 
> > > Which probably can't be directly applied to dictionary size used during
> > > (de)compression.
> > 
> > My point still stands: using GUEST memory for all the decompression work
> > would avoid all these problems. If the guest memory isn't sufficient, a
> > decompression by e.g. grub wouldn't work either.
> 
> Doing that would probably require mapping guest memory to dom0 for this
> purpose. And probably quite severe changes to the decompressing code
> (liblzma?) to actually use that memory instead of standard heap. I don't
> think it's a feasible short term fix.
> Theoretically this could be made configurable (if nothing else, then via
> an env variable or even build-time setting...), but honestly it feels
> like an overkill.

As a compromise that could likely be done in time for the release,
would it be feasible to fetch the dictionary size from the header and
cap it at certain boundary using max(
, )?

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 08:40:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 08:40:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857596.1269817 (Exim 4.92)
	(envelope-from )
	id 1tN6eY-0005Pl-Th; Mon, 16 Dec 2024 08:40:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857596.1269817; Mon, 16 Dec 2024 08:40:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tN6eY-0005Pe-Px; Mon, 16 Dec 2024 08:40:34 +0000
Received: by outflank-mailman (input) for mailman id 857596;
 Mon, 16 Dec 2024 08:40: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 1tN6eX-0005PY-Au
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 08:40:33 +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 68915820-bb89-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 09:40:31 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-432d86a3085so24182275e9.2
 for ; Mon, 16 Dec 2024 00:40:31 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c80601desm7464309f8f.90.2024.12.16.00.40.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 16 Dec 2024 00:40: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: 68915820-bb89-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734338431; x=1734943231; 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=n7hnVuA6Ir1t7mYwsyCzuoPRED4PVNmOejMrQoICa5A=;
        b=bNUeklhbfWn+2DPBS/b5t5SPLI55lh4L4P/YCscxaXgyengSMfCfySpnRVw7BY/HnJ
         /6JU6WXsSob3EIRWJV+yU00u3/qcjNECaIkdjYAjWf1nW+LhZiW2iye4zMOLbSIpuS2O
         gNl5e+XOlj0iP5Jtyf2y9jVhuA9WjjbJR6B3Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734338431; x=1734943231;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=n7hnVuA6Ir1t7mYwsyCzuoPRED4PVNmOejMrQoICa5A=;
        b=TNkUVMpbPS79Sq+Zu6CBS6xwbQqOyoiAkCCJb90B0Z4m9OyCN8IIetwtIr5bxvlVJ2
         bXlvEPXWCavWEnYj8LqS/ogOdtP7Zv4P6kP5zt/W5exk47EcmRFe0KF3vz9CGaF61sE6
         CfzTYOcoR3lpI2LJmhGMjEkmfXFRB8o1SyvFBQ03IXDaxtM6BAYZaByet7bZ+io+6hJk
         nb/JevGOfBnnzhgN8XPmQ+jxE45PimDmHcm9971ZKVdin8Y8o82G4JrqdLMCZy83zCQ5
         OSkkEnB7K0dqhxp9KjkkApSDzVRJ+fq/QkR/MVyTEPPhgpvvCNiJtULprS2dhAP35wKg
         s0/w==
X-Forwarded-Encrypted: i=1; AJvYcCX6SmrKUI2BEjhy0Dzh7DNZDaY3cOrr4qjiKFdGisY0KQ3wcectbVoexVz0S9u3zHuFh7Ihxx8ANJ4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywj8zQbUvaya0rOBe5ojkpawnTZwp+xnja8BTtllO8TTJv8NUzP
	Wa3e7AgfUAqcCmoaVk3AlQWOW7XCj/kPZDNIe2VLKDuCqSm8Vhp4t0PcchUSvhI=
X-Gm-Gg: ASbGncuQ5ZSFBvWwFwBZUiBGwKtVSgtSNtlKIXFpqe/jTY3dDDHSp6BkP9d3K9GTHky
	EeIWT9OoYCzEv7u+lVcGI53EiaEA+IGk7XH5LRQImKe8VAO7IWLxcSJ54WYH3jjmYqFgAqH/1jM
	REkiVFUzwBJW8QMxlBl6KKuWSCEtt03AI10mOC/RNjWa29M1/laStYKpDuXcgCDuNKBUPH6xYvW
	OIiT6LQ5wqX2RzXJkLeMYx2mzzeIZhBO1TujCBLZ0dExoojnPFxHsGqAqVv3w==
X-Google-Smtp-Source: AGHT+IHh5wcCZRXGFa0CjTwy/DajjsMEflZRQX0DXrJw7XjGvDIDQqPFRapZoN5QVoAI1NFzpxduuA==
X-Received: by 2002:a05:600c:1d29:b0:436:1ac2:1ad2 with SMTP id 5b1f17b1804b1-4362aa40835mr89440485e9.19.1734338430619;
        Mon, 16 Dec 2024 00:40:30 -0800 (PST)
Date: Mon, 16 Dec 2024 09:40:29 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Stefano Stabellini 
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall 
Subject: Re: [PATCH v2 33/35] x86/domain: implement domain_has_vuart()
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-33-e9aa923127eb@ford.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Fri, Dec 13, 2024 at 12:45:34PM -0800, Stefano Stabellini wrote:
> On Fri, 13 Dec 2024, Roger Pau Monné wrote:
> > On Thu, Dec 05, 2024 at 08:42:03PM -0800, Denis Mukhin via B4 Relay wrote:
> > > From: Denis Mukhin 
> > > 
> > > Add new emulation flag for virtual UART on x86 and plumb it through the stack.
> > > 
> > > This change enables NS8250 emulator initialization.
> > > 
> > > Signed-off-by: Denis Mukhin 
> > > ---
> > >  tools/libs/light/libxl_x86.c      |  6 +++++-
> > >  tools/ocaml/libs/xc/xenctrl.ml    |  1 +
> > >  tools/ocaml/libs/xc/xenctrl.mli   |  1 +
> > >  tools/python/xen/lowlevel/xc/xc.c |  4 +---
> > >  xen/arch/x86/domain.c             |  8 +++++---
> > >  xen/arch/x86/include/asm/domain.h |  7 ++++---
> > >  xen/include/public/arch-x86/xen.h | 14 +++++++++++++-
> > >  7 files changed, 30 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c
> > > index a3164a3077fec7e1b81a34074894dc646954a49a..de5f05e18cb0671bb031b101b9a7159eb0fe0178 100644
> > > --- a/tools/libs/light/libxl_x86.c
> > > +++ b/tools/libs/light/libxl_x86.c
> > > @@ -8,7 +8,11 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
> > >  {
> > >      switch(d_config->c_info.type) {
> > >      case LIBXL_DOMAIN_TYPE_HVM:
> > > -        config->arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
> > > +        config->arch.emulation_flags = XEN_X86_EMU_ALL;
> > > +        config->arch.emulation_flags &= ~XEN_X86_EMU_VPCI;
> > > +        /* Virtual UART is selected at Xen build time */
> > > +        config->arch.emulation_flags &= ~XEN_X86_EMU_VUART;
> > > +
> > >          if (!libxl_defbool_val(d_config->b_info.u.hvm.pirq))
> > >              config->arch.emulation_flags &= ~XEN_X86_EMU_USE_PIRQ;
> > >          break;
> > > diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
> > > index 2690f9a92316b812ad3d3ff0e1c36823070adb4a..647239b3e55e88b00eb8e9773a5267894cbbae54 100644
> > > --- a/tools/ocaml/libs/xc/xenctrl.ml
> > > +++ b/tools/ocaml/libs/xc/xenctrl.ml
> > > @@ -47,6 +47,7 @@ type x86_arch_emulation_flags =
> > >    | X86_EMU_PIT
> > >    | X86_EMU_USE_PIRQ
> > >    | X86_EMU_VPCI
> > > +  | X86_EMU_VUART
> > >  
> > >  type x86_arch_misc_flags =
> > >    | X86_MSR_RELAXED
> > > diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
> > > index febbe1f6ae3f10c5abe45eaa3c06a8a67d9ba268..4f5f64c786e83e8a0c3dd3cdb0460f7095de4a62 100644
> > > --- a/tools/ocaml/libs/xc/xenctrl.mli
> > > +++ b/tools/ocaml/libs/xc/xenctrl.mli
> > > @@ -41,6 +41,7 @@ type x86_arch_emulation_flags =
> > >    | X86_EMU_PIT
> > >    | X86_EMU_USE_PIRQ
> > >    | X86_EMU_VPCI
> > > +  | X86_EMU_VUART
> > >  
> > >  type x86_arch_misc_flags =
> > >    | X86_MSR_RELAXED
> > > diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
> > > index 9feb12ae2b16e48cb5d0c3c45044ae226f152f2d..e54308956efc7061d58d2166ec9a95bc1dcd1781 100644
> > > --- a/tools/python/xen/lowlevel/xc/xc.c
> > > +++ b/tools/python/xen/lowlevel/xc/xc.c
> > > @@ -159,9 +159,7 @@ static PyObject *pyxc_domain_create(XcObject *self,
> > >  
> > >  #if defined (__i386) || defined(__x86_64__)
> > >      if ( config.flags & XEN_DOMCTL_CDF_hvm )
> > > -        config.arch.emulation_flags = XEN_X86_EMU_ALL &
> > > -                                      ~(XEN_X86_EMU_VPCI |
> > > -                                        XEN_X86_EMU_USE_PIRQ);
> > > +        config.arch.emulation_flags = XEN_X86_EMU_HVM_ALLOWABLE;
> > >  #elif defined (__arm__) || defined(__aarch64__)
> > >      config.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
> > >  #else
> > > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > > index c88d422a64544531c1e1058fa484364bb4277d1e..439da7adc92a3a8eb481075bf834da5f9670dd54 100644
> > > --- a/xen/arch/x86/domain.c
> > > +++ b/xen/arch/x86/domain.c
> > > @@ -752,10 +752,10 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
> > >          if ( is_hardware_domain(d) &&
> > >               emflags != (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) )
> > >              return false;
> > > +
> > > +        emflags &= ~X86_EMU_VUART;
> > 
> > I think you want to allow X86_EMU_VUART only for domains created by
> > Xen itself, so X86_EMU_VUART can only be valid if system_state <
> > SYS_STATE_active.
> > 
> > >          if ( !is_hardware_domain(d) &&
> > > -             /* HVM PIRQ feature is user-selectable. */
> > > -             (emflags & ~X86_EMU_USE_PIRQ) !=
> > > -             (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
> > > +             xen_emflags_allowable(emflags) != XEN_X86_EMU_HVM_ALLOWABLE &&
> > >               emflags != X86_EMU_LAPIC )
> > >              return false;
> > >      }
> > > @@ -806,6 +806,8 @@ int arch_domain_create(struct domain *d,
> > >  
> > >      emflags = config->arch.emulation_flags;
> > >  
> > > +    if ( IS_ENABLED(CONFIG_HAS_VUART_NS8250) && is_hvm_domain(d) )
> > > +        emflags |= XEN_X86_EMU_VUART;
> > 
> > Doesn't this need to be limited to domains created by Xen itself, as
> > otherwise it's the toolstack that should specify the XEN_X86_EMU_VUART
> > flag, and even then the recommendation would be to use the vUART from
> > QEMU?
> 
> While I agree with you that this feature is really useful mostly for the
> domains created by Xen, as for those there is no other way to get early
> output, I think Denis has been also testing successfully this feature
> with PVH or HVM domains created by the toolstack.
> 
> I'll let you decide whether you want to expose the feature to xl created
> domains, but yes my understanding is that they already work with this
> series. One benefit would be that for PVH domains you could get early
> output without having to start QEMU, but I'll leave this to you.

I'm not opposed to allowing usage of the Xen emulated uart for
toolstack created domains, but then the option needs to be integrated
with xl/libxl IMO, so that it can be specified in the xl.cfg file, and
propagated from the toolstack into Xen using the emulation_flags
field.  Just like all other emulated devices that are controlled by
emulation_flags.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 09:05:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 09:05:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857607.1269828 (Exim 4.92)
	(envelope-from )
	id 1tN729-0000MH-Qu; Mon, 16 Dec 2024 09:04:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857607.1269828; Mon, 16 Dec 2024 09:04: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 1tN729-0000MA-MX; Mon, 16 Dec 2024 09:04:57 +0000
Received: by outflank-mailman (input) for mailman id 857607;
 Mon, 16 Dec 2024 09:04: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 1tN728-0000M4-6G
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 09:04:56 +0000
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [2a00:1450:4864:20::436])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d0838499-bb8c-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 10:04:54 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-382610c7116so1847153f8f.0
 for ; Mon, 16 Dec 2024 01:04:54 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c8015f77sm7491465f8f.26.2024.12.16.01.04.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 16 Dec 2024 01:04: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: d0838499-bb8c-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734339893; x=1734944693; 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=1U0GFgEt/Un031CzGR3NNK8KlCEMGfo2Slq73A6rzmo=;
        b=qhprj//OXAFGphxrbzhEzwyc2o724cO/Y9QnDniYWd5ZcMHAhOdVjyG//+Bms5rLfi
         +U6jjVyMgQk1y96w8XFHdYjnhi1zlv570O5L3azLRHDqIyWckz9uE5RorbsYZNJU/qrD
         3Zpg50ellvZ4EI5sf9IwCYuy4f1Po5tVZ00j4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734339893; x=1734944693;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=1U0GFgEt/Un031CzGR3NNK8KlCEMGfo2Slq73A6rzmo=;
        b=i7jrli4wK2/nPdLkEUud1tBRdola78vEsP8Emqhx6sQw+sI192x+OCFEkM+QfwRrNV
         CJDLam7yHi+BONDvOFEFTRKI7Pv3cnBoiL+YfbuvV84VNf3VDNbF5kiv1u4LiroTukAs
         OQG4MyM+z1lE7TZ7TqXLYj+La9U4jBFZxbf49TcHYtsmo6h0NX4l7I2n+XC6xxaj3T3+
         P3r5XQcZa77Uppf1+Artp9EqVINEyMt9ZrLbzTLojoG/cqwbqBVaxC2HmfqCQ7+IjN8o
         eT9KZTF4hek41wovy8WEIDElsVoaVuI9QrSkb6FieAn6mFAAjXHvtWEgojyRinxxYOqZ
         jeGw==
X-Forwarded-Encrypted: i=1; AJvYcCVPl9nI4r4o7NDXE/WN0cOLKxXJLrayUop2jeSCXBM4gfU5w1vSVBQ2P8jBvSJV/KnSKbrq9lA4Bo8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxtrhIw9911UNP816x70np8PSFacKGs1U+dZa8e1TAutvfuFvjq
	IaLKTxS8Vi9vG1nyYKfA1RHOexVRd4J4+feJHQVSyEYCrODDQYOKZm6o2dle0Qk=
X-Gm-Gg: ASbGncv1PfjQCMz6ku+HsaNqEiATfqns866GNWQf1Xowycj0x/xztUz0U8zMMnFi/ka
	sbM8yMuyvIo5embW+x7nCHEcpS8AVIR/cnSdGbmXNw5cLs1rVtnexwQ9thfpMeggn2zm6P3P1/w
	lgLas6BhdDIM8Eq78F0DTfacFd0iYEwil8zTWEOwqAVv/6JG1QNlz4waL7cUg/mOTAMLrNSpbF5
	ZtisRU+O3VmD15aXgYnp2Da8CAXHI3bso6fO+J87WE0q9ZtGOwH5x1ZmI1zQA==
X-Google-Smtp-Source: AGHT+IG9ekZHp9Ot7ZpiIoFYsY1mxbEc8sCPIk6PIkvMnwcQFjmoEaXT5NwNQmpGkMq0mTT6gYrMoA==
X-Received: by 2002:a5d:6d8f:0:b0:385:e3d3:be1b with SMTP id ffacd0b85a97d-38880ae1392mr10247668f8f.28.1734339893517;
        Mon, 16 Dec 2024 01:04:53 -0800 (PST)
Date: Mon, 16 Dec 2024 10:04:52 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	Oleksii Kurochko 
Subject: Re: [PATCH v2 00/35] Introduce NS8250 UART emulator
Message-ID: 
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Sat, Dec 14, 2024 at 07:05:15PM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Dec 05, 2024 at 08:41:30PM -0800, Denis Mukhin via B4 Relay wrote:
> > The patch series introduces initial in-hypervisor emulator for
> > NS8250/NS16x50-compatible UARTs under CONFIG_HAS_VUART_NS8250.
> > 
> > In parallel domain creation scenario (hyperlaunch), NS8520 emulator helps
> > early guest OS bringup debugging, because it eliminates dependency on the
> > external emulator being operational by the time domains are created. Also,
> > there's no early console facility similar to vpl011 to support x86 guest OS
> > bring up.
> > 
> > The NS8250 emulator is disabled by default.
> 
> On a high level, why the mechanism used by earlyprintk=xen (IIUC i/o
> port 0xe9) isn't enough?
> Hyperlaunch can't start full (Xen-unaware) HVM domains anyway, so
> a requirement to use a Xen-specific interface for the console shouldn't be
> an issue, no?

I assume the point is to provide a minimal set of non-Xen specific
interfaces so that a guest *could* work if made to use only those
interfaces.  The 0xE9 hack is quite common for emergency printing, but
it doesn't allow for input, which the ns8250 does.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 09:19:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 09:19:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857616.1269838 (Exim 4.92)
	(envelope-from )
	id 1tN7GH-0002Af-27; Mon, 16 Dec 2024 09:19:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857616.1269838; Mon, 16 Dec 2024 09:19:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tN7GG-0002AY-Tk; Mon, 16 Dec 2024 09:19:32 +0000
Received: by outflank-mailman (input) for mailman id 857616;
 Mon, 16 Dec 2024 09:19: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 1tN7GF-0002AS-FF
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 09:19:31 +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 dab83dbb-bb8e-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 10:19:30 +0100 (CET)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-43628e97467so34172555e9.3
 for ; Mon, 16 Dec 2024 01:19: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
 ffacd0b85a97d-388c8046da0sm7770523f8f.74.2024.12.16.01.19.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 01:19: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: dab83dbb-bb8e-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734340770; x=1734945570; 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=OxHl9dtxX5fxuawa353QgOBshFc+eKtA/Hav1Jgel+c=;
        b=dKt8V9oDr/dNv/AEWMhY8B85e2BXx6IACrxrePgOsJeFX1Gz0ff5eXoQBAbk4UHCje
         N7AFxcONRkfNovunwbLDPhtJR7qE+jwZaD5lidXvkgOqr7nQ8c/vh/mglaHpnd1kikJ6
         ALjUM0TYwrqYFaTHzSGLxOOHva6jX21ci+KpTN02iiTUlV8DLZFJZ5t2JmqQh0YInelj
         Tqz79XDOq5tMkEVi3ejh679S5wvbdPOv8+hJVtLbzKPlnACSWkPmjQf2hA0DQugFMM/j
         zVhUYtkCKgqbe4BbMrfKVFNxzCAXrvRIDBYfrmZL4gqtlaE8ihwX9gTHmW8P7eIV4ITX
         9eIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734340770; x=1734945570;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=OxHl9dtxX5fxuawa353QgOBshFc+eKtA/Hav1Jgel+c=;
        b=ncdE4NWy4W6XoIJnO708ren2fjrwIxeyzwL9onX/Vaqxnan07TM50RN1nT9jr0E7JA
         xYYj7V5XISttQFeMjN1/XAX9I4E7B0Ge+4UiaSrwOGwWvPOCjgXZm1VWeySBMWPua0Bz
         JF1Z5heOJp28I7GOR8tFNYxA/gLsCsOX5VsmlkaE6FcZchczoeCIYO+wszV/XVRKBamU
         MWnjNzW8GqlBkpPjw2kA5Z1p8Q5AOKgXxP/wIETw5pAzJ1Enkz4gmNETi8+H8sjXUSpa
         a3NeFIrZVOLBw4wp4bnKwHLlC5ljoKgrLq+EZixlYMWxrswf5JXgdnOMX7+CvmNIfZaZ
         S0bw==
X-Forwarded-Encrypted: i=1; AJvYcCXzkGjLI87rX/72d4xqTmC+ne7fPuD2UisgPYG7B8JlqxPJmDLzw3O9FvHOUnWqqzFrnigI0jTaUNE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwiQ4nJPs2dKzntSMgWVADS+usJ2phvKAHzzB5LC2DCgGN8s9Xj
	pVp1Cb29YoWfgGSnYs3gR7RD42gGThs18H2aGhLwXHVWpf5Ou9DoeHE+xbJ5vg==
X-Gm-Gg: ASbGncv5QQcCUP6CWHwZdQtFDIV/OrSg1Ym442S0bt+iUpE7nsMGNmaswSP0pyLv5ak
	Kg0Z/nhvp7wLOyRnpcUp+YrQi1GR6YsN5ZdOkasT3a51Kez6NEzkvVXU7Z7JjR32oE/f5K2bd0B
	k87KsgCgEoCvNeBTGWLfA+afoKde/Bz3JuayuQpMlC+3Bw95a+dsIpWmH+GT++bf5ZR/KeruHrJ
	/vbJY/G+T5Why8eqp96yNYzfAGsqv7FnXIeEGIu+GaMenIXYul3VjjuUQMn80Q2rlV37WqC0Fre
	e/nD/+dw8azrmZHDVlUnxZYwGwlINh+WNEvVYCOJtA==
X-Google-Smtp-Source: AGHT+IGUzulWCwIOeLEykd2kHecnhZmkQfhwjBHryCgvLvYGC5trB2ocAktXRMtBUqznyIGq0VBuwQ==
X-Received: by 2002:a05:600c:4e4e:b0:434:a30b:5455 with SMTP id 5b1f17b1804b1-4362aaa4372mr100847785e9.27.1734340769649;
        Mon, 16 Dec 2024 01:19:29 -0800 (PST)
Message-ID: <0284d807-ae85-4d43-93b5-91fb29528d62@suse.com>
Date: Mon, 16 Dec 2024 10:19:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: add privcmd ioctl to get p2pdma_distance
To: "Zhang, Julia" 
Cc: "Deucher, Alexander" ,
 "Koenig, Christian" ,
 Xenia Ragiadakou , "Chen, Jiqian"
 , "Huang, Ray" ,
 "Penny, Zheng" , "Zhu, Lingshan"
 , Paul Durrant ,
 "Edgar E . Iglesias" ,
 "Michael S . Tsirkin" ,
 Marcel Apfelbaum ,
 Juergen Gross ,
 Oleksandr Tyshchenko ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini 
References: <20241207105946.542491-1-julia.zhang@amd.com>
 <03504a1e-c801-47fc-ac66-ab7e10ab6695@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 16.12.2024 09:18, Zhang, Julia wrote:
> On 2024/12/9 15:47, Jan Beulich wrote:
> On 07.12.2024 11:59, Julia Zhang wrote:

Yet another formality, sorry: Please send plain text emails. You'll note that what
I said and why you said is indistinguishably intermixed below.

> --- a/tools/include/xen-sys/Linux/privcmd.h
> 
> +++ b/tools/include/xen-sys/Linux/privcmd.h
> 
> @@ -110,6 +110,16 @@ typedef struct privcmd_map_hva_to_gpfns {
> 
>    int add_mapping;
> 
>  } privcmd_map_hva_to_gpfns_t;
> 
> 
> 
> +typedef struct privcmd_p2pdma_distance {
> 
> +  __u32 provider_bus;
> 
> +  __u32 provider_slot;
> 
> +  __u32 provider_func;
> 
> +  __u32 client_bus;
> 
> +  __u32 client_slot;
> 
> +  __u32 client_func;
> 
> +  __u32 distance;
> 
> +} privcmd_p2pdma_distance_t;
> 
> 
> 
> "Distance" typically is a symmetric thing. Why the asymmetry here? And
> 
> why __u32 when __u8 will be fine for most fields? And where's the segment
> 
> part of the device coordinates? Finally, with it being merely stub
> 
> implementations that you add here, all details on where the needed info
> 
> is to come from are missing.
> 
> "Distance" is p2pdma-distance between two PCI devices, it's calculated in kernel driver.I don't get why it's symmetric?

Distance from A to B is usually the same as that from B to A. But yes,
not necessarily always (thinking of e.g. rings). Yet still I'm unclear
about the distinction between provide and client.

> I will use change __u32 to __u8.
> 
> By the segment part of the device coordinates, do you mean the domain number of the device?

Some call it domain, yes. Since domain has an important-ish different
meaning in Xen, we prefer segment though.

> All the needed info(virtual bus/slot/function numbers) are from guest VM, QEMU convert them to real physical info of two devices.
> 
> Do you mean that I should add more details in commit message or comment?

Perhaps. Or have the patch be more complete, in the sense of not only
putting in place stubs, thus actually making visible how the data is
produced / used.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 09:53:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 09:53:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857631.1269846 (Exim 4.92)
	(envelope-from )
	id 1tN7n3-0007Vl-Kk; Mon, 16 Dec 2024 09:53:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857631.1269846; Mon, 16 Dec 2024 09:53: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 1tN7n3-0007Ve-Hh; Mon, 16 Dec 2024 09:53:25 +0000
Received: by outflank-mailman (input) for mailman id 857631;
 Mon, 16 Dec 2024 09:53: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 1tN7n1-0007VY-F6
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 09:53: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 9559663f-bb93-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 10:53:21 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-43622354a3eso26220865e9.1
 for ; Mon, 16 Dec 2024 01:53:21 -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-388c80163b8sm7546568f8f.35.2024.12.16.01.53.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 01:53:20 -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: 9559663f-bb93-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734342801; x=1734947601; 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=CpKEyRqWsCjQ57UZGAkTg3oqG67L2eugsefWzGZeJlg=;
        b=frgIN9gxwYyKrdLn8EgDOSji7X1U+UmuIP/6555iR6PxVOCr0tgMzVnSHLwYf9d8nM
         ITJLbqjzLexbW1ahVX+jjrj/JaU0tYVPDMimSenDo1iE8eGZWP4GcT6oa1jiNGfnPvno
         fEvPELiL+bUAr2T3CwBoeCk7pvFEv2bNPh7FkmdPSu8rL2M7xSNP29rCxanWn7OyJ0f1
         yieJRi3A6baOMGh31f7LTIdQrChENeSHTeS2gjtkl9c37cxU2X3y+kjR61YjQGntv+69
         fj0QU/8x8S9jTTGDpiCHlUC44Rx06d4+dTjsLbOxoHIH16ekvH4j2arYKpbNR5R3gGTJ
         Rf2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734342801; x=1734947601;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=CpKEyRqWsCjQ57UZGAkTg3oqG67L2eugsefWzGZeJlg=;
        b=WOI86PMfHhmJ6fAWE6psXZULyg8W4CqVxR4OTeYT9CGvs4QvsOI9lUu1h9IAsoNhXa
         yStl7LZHcAjDI38OTjmNaGW9QQJqRNEehk3iVgURZsUVzgRY4cS3YhX20nxARHpINrsu
         zKpTcl6plu3gr+UCIJOz1hivFYRh37TZPdPnF6RDoeVHF2AjbC9dJQiHOATbWSNVZkqm
         gCFlP5x+eoR3q4IW4Wa57SFOrxUJOtSWLNJSI/RrnWX76mwGIniJyN5pJPJln+KPaNQR
         c6KHLze4EeFbSMnz2tVLHiyv36VEfnQLhfrBo1oFjXF5RRukW/3AVLHOB8nVSEaUE9Mm
         a3og==
X-Forwarded-Encrypted: i=1; AJvYcCXatVP62GHqZWSxCo6EaRFvJZPIhXk83sj3mggGji6fQlQQzYrpXobOJb9jDbdFiskoxvXq6sFIhH0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YybociOOroC/PPIMCnTDqw1AXp9w4CdHx9ckTS4eqRr5YGTn9vw
	cZVKUrzhWBlJ+3N3EdSxceLDBIvAP1/JbS9GZ/z8IoHjsIq/5JjUwa/GKPfdtw==
X-Gm-Gg: ASbGncsuAGO35zBLe4vwTb+xOkaaIAnuWpxmtT5sLUAORUDDSxmdb0i+Gr9eeciQ79+
	DUA+jeNkEoAg7Dg1OPxxyrfZNhnJinfth2Bw53BizouArpxGvlsRjds+8KCa/owfrBwt8dbB/4x
	FVbnuw8K6U2HB8gDEIUP/2taFYL9ET3HZe+lGfqKYiV8dogBwY+JR4oYYJw2bTjzPHcpueosWsS
	6CibvcAu1zBwozaEQxzZXNI9pgcvP1CMkgL07aaAadDesbwqEJ+1khTOV2gziJIpOgFFohDi7ei
	jQ7F6xfQ4WTHiqpWwVMqCk+Qu7E4mcaSD6+RBRGMUw==
X-Google-Smtp-Source: AGHT+IH7wEymKwew7c4nnDnYCEm+AtoiDO/pPOfTL690bU2YLb0My3m/S9un2HzL+SYSg1tiBYbgVg==
X-Received: by 2002:a5d:5849:0:b0:385:f69a:7e5f with SMTP id ffacd0b85a97d-3888e0b8e63mr10021175f8f.38.1734342800702;
        Mon, 16 Dec 2024 01:53:20 -0800 (PST)
Message-ID: <5599dc89-0fa4-4255-b4a1-5b81e151d8c7@suse.com>
Date: Mon, 16 Dec 2024 10:53:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/1] tools/libacpi: clear ASL warning about PCI0
To: Ariel Otilibili 
Cc: nthony PERARD , xen-devel@lists.xenproject.org
References: <20241215154659.151158-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241215154659.151158-2-Ariel.Otilibili-Anieli@eurecom.fr>
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: <20241215154659.151158-2-Ariel.Otilibili-Anieli@eurecom.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 15.12.2024 16:40, Ariel Otilibili wrote:
> * iasl complains _HID and _ADR cannot be used at the same time
> 
> ```
> /usr/bin/iasl -vs -p tools/firmware/hvmloader/dsdt_anycpu.tmp -tc tools/firmware/hvmloader/dsdt_anycpu.asl 2>&1 | grep -B10 HID
> tools/firmware/hvmloader/dsdt_anycpu.asl     40:        Device (PCI0)
> Warning  3073 -                                    Multiple types ^  (Device object requires either a _HID or _ADR, but not both)
> ```
> 
> * generally _HID devices are enumerated and have their drivers loaded by ACPI
> * this is from "ASL 2.0 Introduction and Overview" (page 4).
> * removing _ADR, the warning is cleared out.

Okay, that's the positive aspect. Yet what about the potential fallout thereof?
Can you confirm that there's no risk of regressions with older guest OSes, for
example?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 09:58:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 09:58:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857639.1269857 (Exim 4.92)
	(envelope-from )
	id 1tN7sK-00088G-6t; Mon, 16 Dec 2024 09:58:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857639.1269857; Mon, 16 Dec 2024 09:58: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 1tN7sK-000889-3t; Mon, 16 Dec 2024 09:58:52 +0000
Received: by outflank-mailman (input) for mailman id 857639;
 Mon, 16 Dec 2024 09:58: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 1tN7sI-000880-Um
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 09:58:50 +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 58a5d0f3-bb94-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 10:58:49 +0100 (CET)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-385ddcfc97bso3288808f8f.1
 for ; Mon, 16 Dec 2024 01:58: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-388c801643fsm7693112f8f.41.2024.12.16.01.58.47
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 01:58: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: 58a5d0f3-bb94-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734343128; x=1734947928; 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=XOLxbcZZTjzhG5nt8yc/Ddg/CYtaUwO8sT4eRfCtkUk=;
        b=FrP1L/DOxJA16G56y0Suj8dDpL+LX1TvsE4GAijRWjeNyA6vS4snx7aDuf7aElkjHK
         7dtFlO3HNDVtelGtRdnsGPuXr2ugsQYlVsyUaxhtuQxbK1SNeYBCtes4bmiDNfOWz2+l
         Tp0XWaHU0tih4s8fuVrDQ7WEL03WlwgKjYW65vp7Wja0kDaWZ8LQK40jWUm/A17rhkZi
         Ruqdw3s/5Dc2s3yeetzazCemsRRtdWvyNoR1r6dWZXvx/30onkxvh/vL/JiXruhpHZek
         4C3dsEcKTV5JtUKItRGU7JaxWOnXLADrXaS+6et1jKOI+8rpjcuIOIYO/Sefd3kMh5e0
         wGLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734343128; x=1734947928;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=XOLxbcZZTjzhG5nt8yc/Ddg/CYtaUwO8sT4eRfCtkUk=;
        b=p4W5y0OyEiIRR1p5FzOyDfISmsBgQEBwiO1Wpu2/BVcHCyoQCY5f3pfGWs0cy9mVOn
         HdwOLL/xEuxgWXCDcpcU9OYHzvsiSrKPy5IIXMU4AggcCiP6gNEe9yi17YfBZ0jLvMvm
         T6/59U6OsKPiU/Hbid3c+7HAHgVd740Dm0/DHap0/W08AdZXpanNxLI8jaHR+RkTUZHz
         uY+aUMtX35tVcJKZ3FtFcLPL0dA/Es3V2IlyAxtuUU6gC8R3ChgcYHYivUUE8f4DaFz5
         Jt5QSH5mAhWT74+tBbr9XdWTXO6Hs1QJ8xwHGvCwAQOTNTy/eh5HYsS1PtjPAUYxh5a4
         VGxQ==
X-Forwarded-Encrypted: i=1; AJvYcCWfcQCBb9iw38/eQaTzolcxJ2mAX3pcdt4ZK+xGSwJTtYaYzRzPfHaG/ffUzkIc6TCaIFxol/X0peM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz4KCCS6VEwB9uASSA+0xegeKEXCX0kCTLTUWtsnZIcXQd0NuE7
	MSx7dPGcKC9I2gnlHN2h/lwblNY/koB8eXqhmiR+WNAblXgfJE9ov29Ueaa0Vg==
X-Gm-Gg: ASbGnctq3NR3FsoWBmR6RfwUHiJRpHpDCZz41aCCUfO67ppZiWKX66nu5DkwMwOTcOf
	Y5bU5keSisE1A8Xc2X5F0/KYK9LEcsKBAXcUnger00KZYZgaAWw0RK0qnhrkQW1fDcR+7YNTk+r
	+qtAR2Uhfx3bQ64IW/rNNfaqP59qdBHWdVi2bnjGNLX0R17HphWp7TDH7vhl8aGQWygkuD2CIPq
	4t/crGnqBP+4eJ++uDnrrEOlm3jS0G0t2h0aGhIvnpXDFwqMDTAvEPG2mGsGs9lTqnjz233ZhIp
	x+tAWR1PVq9LmZwGTmutuaeiTMeljqXNFDrfyBqbhA==
X-Google-Smtp-Source: AGHT+IH1H9EW0O/v3WAoUuqp6lsDCb04nNT/Xp7A6OtsjAi0UgjUdh8dkCD8xo3mdP2GdrHHivShYQ==
X-Received: by 2002:a5d:64ef:0:b0:385:f4db:e336 with SMTP id ffacd0b85a97d-38880af1626mr8180467f8f.2.1734343128363;
        Mon, 16 Dec 2024 01:58:48 -0800 (PST)
Message-ID: <153381d0-3da1-47b2-b9b1-ac6783bdc9b1@suse.com>
Date: Mon, 16 Dec 2024 10:58:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] ARM: ITS: implement quirks and add support for
 Renesas Gen4 ITS
To: Mykyta Poturai 
Cc: Oleksandr Andrushchenko ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" 
References: 
 <2ea26be2689585ea254a9c0177816722bcb2db8d.1734096752.git.mykyta_poturai@epam.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: <2ea26be2689585ea254a9c0177816722bcb2db8d.1734096752.git.mykyta_poturai@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.12.2024 14:43, Mykyta Poturai wrote:
> From: Oleksandr Andrushchenko 
> 
> There are number of ITS implementations exist which are different from
> the base one which have number of functionalities defined as is
> "IMPLEMENTATION DEFINED", e.g. there may exist differences in cacheability,
> shareability and memory requirements and others. This requires
> appropriate handling of such HW requirements which are implemented as
> ITS quirks: GITS_IIDR (ITS Implementer Identification Register) is used to
> differentiate the ITS implementations and select appropriate set of
> quirks if any.
> 
> As an example of such ITSes add quirk implementation for Renesas Gen4 ITS:
> - add possibility to override default cacheability and shareability
> settings used for ITS memory allocations;
> - add possibility to allocate memory used by ITS with specific memory
> requirements: introduce _x{z|m}alloc_whole_pages functions and free the
> memory with xfree as usual.

I disagree with this part. If you need whole pages, you want to use
alloc_{dom,xen}heap_pages(). They also provide control over "specific
requirements", which xmalloc() et al (deliberately don't offer, while
you end up making that inconsistent by adding memflags to two of the
interfaces there). And btw, if anything you'd need to alter the
xvmalloc() set of interfaces, as new code is supposed to use them in
favor of the xmalloc() family.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 10:21:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 10:21:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857650.1269866 (Exim 4.92)
	(envelope-from )
	id 1tN8Du-0003cs-U1; Mon, 16 Dec 2024 10:21:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857650.1269866; Mon, 16 Dec 2024 10:21: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 1tN8Du-0003cl-RJ; Mon, 16 Dec 2024 10:21:10 +0000
Received: by outflank-mailman (input) for mailman id 857650;
 Mon, 16 Dec 2024 10:21: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 1tN8Dt-0003cc-IQ
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 10:21:09 +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 7565b830-bb97-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 11:21:05 +0100 (CET)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-436202dd730so27462795e9.2
 for ; Mon, 16 Dec 2024 02:21: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-4362559ec08sm136229865e9.22.2024.12.16.02.21.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 02:21: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: 7565b830-bb97-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734344465; x=1734949265; 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=SPUpQ3AANBoIUV/uT+3rcfFFLjpUmp27Gb7Kq7AbkTU=;
        b=Szln7NFyFC1Sa19+CWdPwDLVY0Y5DH2UKUI8sy6mm+UbFeIRtC4vjZ1Dks5dTHHrZM
         qMtcATVoNRE+aunfq/3GBF/tM5eYSPu4NfKgc4CJLwaiUQBpHOEsREQqtc9+tniI4sX8
         lC9CZw1YaDxEfAQwGX+2r+nOZPABPtdyLoFB7k0+2PUV2kcIw54+V+63r96NyL3ta9mj
         o1fiInqtGoswJ7IosHzCcuiU0TXl6t6KtYxCxmthGsesBMldP6rrtTdrJdm4KOia8aOl
         7PezaJIkooJ4X3aH+iBjYQma0OpBJzo0LDeoCEhxF6HkR4RYIQpin6imQts1d1q8logn
         zkkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734344465; x=1734949265;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=SPUpQ3AANBoIUV/uT+3rcfFFLjpUmp27Gb7Kq7AbkTU=;
        b=fdW8bqZr1yIcZroesB4F7yOIlL/iqWj9t84iitpYu021WN5pbgCfz80d/gB4V5ykmd
         yhgcc/mFby6TfMW305ngc7KYVTPrEBqTT97hHWgfKODUIM29/XpIdTC+twvgqCMU2EuY
         0qqFgAs792JY1hvsAPXmafcOhZuQ1BLoIoFEUNcJUfvYtpgxloQYkC2Ksw54K2TClrko
         oAOSmx5lE6US/oaBvDepOcaqgp65r6VbEZPrIQCnvFtEw6rOZnq4R38Gbi0FFx8qVJ2/
         LH+d2nIcRa0aVpiH+lyVlNTtQTuohlinjDnrduGzcLEURCuhbLqBCgFKZBceYStcopnu
         l+zw==
X-Forwarded-Encrypted: i=1; AJvYcCVp4a1LoWeXoETu52+UaqzVpcYyYaL6Z7OFO9HAjAeD7x78NR4Wh2nzchVh1bdxYIv95Aa9E6h6MJM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxW9q+Y/N9FARsLKFwxEBc1aR5vaT/xDWaK9gpcGMY3KfJeb5av
	6ejQFaJacdSqG0KOygrJjOtuE98knNSrtqFLMAzaNOh4SIKYingO7LYCs6av1A==
X-Gm-Gg: ASbGncueY6aV6t2j32uWkeGRUKcWTUxmq1HzlSHHP3awzu0K16+0CI+2S8yNvcND9Vc
	vfONFfrMkrB/s6+OFOcZa7ydXc8RQRuhQxkGS+pZiqhV03kQ1PV7LEjj3vmdBhdWH3a8j9DMO2o
	k9ioTGMmW/sQVyvGulLCMCYsraZEtMpSGALoPtSLR2OAQyISqt6i4VZvx7THpjmqZWcR+6gVZin
	YVUuiK5+3zH5PHQaxOSD5q1lv509TIzMm5AoqtCFYd7xLD5bhazCxHzG95dGw+BMLXsbHBZz/Fq
	hZ4bHIssRO68lBFLIPWsQJdPGPZP9HfB49R8lrgA5w==
X-Google-Smtp-Source: AGHT+IHw87OegXSV2JNn4ULvXYDfEO2vjSDEdpDk2ZGL6Sqbw5zBbzA1JBTVjdtxClv5Q4GS2lh04w==
X-Received: by 2002:a05:600c:5248:b0:434:f3d8:62d0 with SMTP id 5b1f17b1804b1-4362aa34e58mr120872315e9.3.1734344465029;
        Mon, 16 Dec 2024 02:21:05 -0800 (PST)
Message-ID: <50258f9a-89e6-4a62-8ed5-63a3bfa668c8@suse.com>
Date: Mon, 16 Dec 2024 11:21:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 4/7] xen: add bitmap to indicate per-domain state
 changes
To: Juergen Gross 
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: <20241213162421.16782-1-jgross@suse.com>
 <20241213162421.16782-5-jgross@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: <20241213162421.16782-5-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.12.2024 17:24, Juergen Gross wrote:
> @@ -138,6 +139,60 @@ bool __read_mostly vmtrace_available;
>  
>  bool __read_mostly vpmu_is_available;
>  
> +static DEFINE_SPINLOCK(dom_state_changed_lock);
> +static unsigned long *dom_state_changed;

__read_mostly?

> +int domain_init_states(void)
> +{
> +    const struct domain *d;
> +    int rc = -ENOMEM;
> +
> +    spin_lock(&dom_state_changed_lock);
> +
> +    if ( dom_state_changed )
> +        bitmap_zero(dom_state_changed, DOMID_FIRST_RESERVED);
> +    else
> +    {
> +        dom_state_changed = xvzalloc_array(unsigned long,
> +                                           BITS_TO_LONGS(DOMID_FIRST_RESERVED));
> +        if ( !dom_state_changed )
> +            goto unlock;
> +    }
> +
> +    rcu_read_lock(&domlist_read_lock);
> +
> +    for_each_domain ( d )
> +        set_bit(d->domain_id, dom_state_changed);

Use the cheaper __set_bit() here?

> +static void domain_changed_state(const struct domain *d)
> +{
> +    spin_lock(&dom_state_changed_lock);
> +
> +    if ( dom_state_changed )
> +        set_bit(d->domain_id, dom_state_changed);

And perhaps even here, considering everything's under lock now?

> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -485,6 +485,13 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
>      if ( (v = domain_vcpu(d, vcpu)) == NULL )
>          return -ENOENT;
>  
> +    if ( virq == VIRQ_DOM_EXC )
> +    {
> +        rc = domain_init_states();
> +        if ( rc )
> +            goto deinit;
> +    }

This is tied to VIRQ_DOM_EXC. How come ...

> @@ -527,6 +534,10 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
>   out:
>      write_unlock(&d->event_lock);
>  
> + deinit:
> +    if ( rc )
> +        domain_deinit_states();
> +
>      return rc;
>  }

... de-init happens upon any error, regardless of vIRQ? Even checking
the virq isn't sufficient, as we also need to gracefully deal with the
-EEXIST path.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 10:25:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 10:25:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857659.1269876 (Exim 4.92)
	(envelope-from )
	id 1tN8Hg-0004EM-Bd; Mon, 16 Dec 2024 10:25:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857659.1269876; Mon, 16 Dec 2024 10:25: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 1tN8Hg-0004EF-92; Mon, 16 Dec 2024 10:25:04 +0000
Received: by outflank-mailman (input) for mailman id 857659;
 Mon, 16 Dec 2024 10:25: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 1tN8Hf-0004E9-0l
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 10:25:03 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 01f5dd16-bb98-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 11:25:01 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-aa679ad4265so937438766b.0
 for ; Mon, 16 Dec 2024 02:25:01 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab96359511sm319784166b.122.2024.12.16.02.25.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 16 Dec 2024 02:25: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: 01f5dd16-bb98-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734344701; x=1734949501; 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=fhE706MTljb2DcXw01XpFkphNKUAEqeYg0XT/RdYUsI=;
        b=d8gybSyPF9OvkLEzUlYj8N/30g7mQ95e3qc1nwRJCJEVgMFJV/iJWDHoyoXv34Fw6G
         e50lnS0lyhMrjDTQ0DlCDV+DAqOVASu/kJZEazOmttjgak/r5gaAa0AOknZj2tMwVMsr
         mbh+SaVq2U8dkwWo5vpUQLYN+18m1+wYQhL8Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734344701; x=1734949501;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=fhE706MTljb2DcXw01XpFkphNKUAEqeYg0XT/RdYUsI=;
        b=PUfp2UxsAHMroIGq9wlWfD8lPsH2zlYBPfxl2kTPQcT1RW3TsPUYDqmxDbSdZsztEw
         gynGKhK/zPY5kjckk+9VD43MGCJ8x5zhRIX7qnwcIghce2p0jfRR38P4E3CryX8U9G7U
         Tgwvldv7p/HMVVrJjUqQuqpzbWUOaX73mo11GdiGiRBqQHwdSe5H36/CbNVU9KRusaj6
         zukmlb8GRO3INt+AXoCFKBK45b81A3pjWTF+FBMyOmASmgmWZ/goUglp8VORE2NX3yeq
         jqiOrbcZ8W19zVR+WuKGue2fd/Rb9U71spGBozUK2HDY+MBaliVeMFxmewpMmYvV4Gk6
         OqJQ==
X-Gm-Message-State: AOJu0YwoSxdipkY03PMkSmn4l/LhxDCE2tpaN2maGKBlxo3rFFnoVB7L
	p6uTts8biN7u4eNiLxh3XlxoLQ1YRbXBDyF7lOj1KxHjeX21Qz3YL1oSPj43Gp0=
X-Gm-Gg: ASbGnctooq9dq+/lLLpzo6RZDiJR1jo6M8rEfISi1GFoDWeWZPu+i9wwCim7l37bwyH
	b51dP4FHMo6fhypnaxy2CeV7+J69cHZZHu8mNQvWuZos1oGxtkPgvS89j/Fnto+a6K3fHKmscqs
	0q2pDcgnQQBBIsvp/ZFEf0+OpliubZRpNbyyNk6aNW3f5zBDhMdtG4OUrmH+CyW6Xu64gW8cl1x
	ljXz4YciysbAnmzk3GMy6i/4Tz64XVbzeI5bvHEiEeUZSecPpbmsWdC10iGNw==
X-Google-Smtp-Source: AGHT+IFi3bK5aCk1yxtXnD0AsNpSdOVrIMvobhoFCwp4megDO7TgEkWhwmbV+hAKzrSVhwmNlFLQKA==
X-Received: by 2002:a17:907:971c:b0:aab:9341:e1bd with SMTP id a640c23a62f3a-aab9341e235mr646021766b.11.1734344700946;
        Mon, 16 Dec 2024 02:25:00 -0800 (PST)
Date: Mon, 16 Dec 2024 11:24:59 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jiqian Chen 
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	Huang Rui 
Subject: Re: [PATCH v3] vpci: Add resizable bar support
Message-ID: 
References: <20241213054232.2638640-1-Jiqian.Chen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20241213054232.2638640-1-Jiqian.Chen@amd.com>

On Fri, Dec 13, 2024 at 01:42:32PM +0800, Jiqian Chen wrote:
> Some devices, like discrete GPU of amd, support resizable bar
> capability, but vpci of Xen doesn't support this feature, so
> they fail to resize bars and then cause probing failure.
> 
> According to PCIe spec, each bar that supports resizing has
> two registers, PCI_REBAR_CAP and PCI_REBAR_CTRL. So, add
> handlers for them to support resizing the size of BARs.
> 
> Signed-off-by: Jiqian Chen 
> ---
> Hi all,
> v2->v3 changes:
> * Used "bar->enabled" to replace "pci_conf_read16(pdev->sbdf, PCI_COMMAND) & PCI_COMMAND_MEMORY",
>   and added comments why it needs this check.
> * Added "!is_hardware_domain(pdev->domain)" check in init_rebar() to return EOPNOTSUPP for domUs.
> * Moved BAR type and index check into init_rebar(), then only need to check once.
> * Added 'U' suffix for macro PCI_REBAR_CAP_SIZES.
> * Added macro PCI_REBAR_SIZE_BIAS to represent 20.
> 
> TODO: need to hide ReBar capability from hardware domain when init_rebar() fails.
> 
> Best regards,
> Jiqian Chen.
> 
> v1->v2 changes:
> * In rebar_ctrl_write, to check if memory decoding is enabled, and added
>   some checks for the type of Bar.
> * Added vpci_hw_write32 to handle PCI_REBAR_CAP's write, since there is
>   no write limitation of dom0.
> * And has many other minor modifications as well.
> ---
>  xen/drivers/vpci/Makefile  |   2 +-
>  xen/drivers/vpci/rebar.c   | 130 +++++++++++++++++++++++++++++++++++++
>  xen/drivers/vpci/vpci.c    |   6 ++
>  xen/include/xen/pci_regs.h |  13 ++++
>  xen/include/xen/vpci.h     |   2 +
>  5 files changed, 152 insertions(+), 1 deletion(-)
>  create mode 100644 xen/drivers/vpci/rebar.c
> 
> diff --git a/xen/drivers/vpci/Makefile b/xen/drivers/vpci/Makefile
> index 1a1413b93e76..a7c8a30a8956 100644
> --- a/xen/drivers/vpci/Makefile
> +++ b/xen/drivers/vpci/Makefile
> @@ -1,2 +1,2 @@
> -obj-y += vpci.o header.o
> +obj-y += vpci.o header.o rebar.o
>  obj-$(CONFIG_HAS_PCI_MSI) += msi.o msix.o
> diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
> new file mode 100644
> index 000000000000..39432c3271a4
> --- /dev/null
> +++ b/xen/drivers/vpci/rebar.c
> @@ -0,0 +1,130 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2024 Advanced Micro Devices, Inc. All Rights Reserved.
> + *
> + * Author: Jiqian Chen 
> + */
> +
> +#include 

Do you really need the hypercall header?

> +#include 
> +
> +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
> +                                      unsigned int reg,
> +                                      uint32_t val,
> +                                      void *data)
> +{
> +    uint64_t size;
> +    struct vpci_bar *bar = data;
> +
> +    size = PCI_REBAR_CTRL_SIZE(val);
> +    if ( bar->enabled )
> +    {
> +        if ( size == bar->size )
> +            return;
> +
> +        /*

Indentation

> +        * Refuse to resize a BAR while memory decoding is enabled, as
> +        * otherwise the size of the mapped region in the p2m would become
> +        * stale with the newly set BAR size, and the position of the BAR
> +        * would be reset to undefined.  Note the PCIe specification also
> +        * forbids resizing a BAR with memory decoding enabled.
> +        */
> +        gprintk(XENLOG_ERR,
> +                "%pp: refuse to resize BAR with memory decoding enabled\n",
> +                &pdev->sbdf);
> +        return;
> +    }

Nit: just realized this could be made shorter:

if ( bar->enabled )
{
   /*
    * Refuse to resize a BAR while memory decoding is enabled, as
    * otherwise the size of the mapped region in the p2m would become
    * stale with the newly set BAR size, and the position of the BAR
    * would be reset to undefined.  Note the PCIe specification also
    * forbids resizing a BAR with memory decoding enabled.
    */
    if ( size != bar->size )
        gprintk(XENLOG_ERR,
                "%pp: refuse to resize BAR with memory decoding enabled\n",
                &pdev->sbdf);

    return;
}

> +
> +    if ( !((size >> PCI_REBAR_SIZE_BIAS) &
> +           MASK_EXTR(pci_conf_read32(pdev->sbdf,
> +                                     reg - PCI_REBAR_CTRL + PCI_REBAR_CAP),
> +                                     PCI_REBAR_CAP_SIZES)) )

Would it be possible to cache this information.  It's my understand
the supported sizes won't change, and hence Xen could read and cache
them in init_rebar() to avoid repeated reads to the register on every
access?

> +        gprintk(XENLOG_WARNING,
> +                "%pp: new size %#lx is not supported by hardware\n",
> +                &pdev->sbdf, size);
> +
> +    bar->size = size;
> +    bar->addr = 0;
> +    bar->guest_addr = 0;
> +    pci_conf_write32(pdev->sbdf, reg, val);
> +}
> +
> +static int cf_check init_rebar(struct pci_dev *pdev)
> +{
> +    uint32_t ctrl;
> +    unsigned int rebar_offset, nbars;
> +
> +    rebar_offset = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_REBAR);

You can do the init at definition:

    uint32_t ctrl;
    unsigned int nbars;
    unsigned int rebar_offset = pci_find_ext_capability(pdev->sbdf,
                                                        PCI_EXT_CAP_ID_REBAR);


> +
> +    if ( !rebar_offset )
> +        return 0;
> +
> +    if ( !is_hardware_domain(pdev->domain) )
> +    {
> +        printk("ReBar is not supported for domUs\n");

This needs a bit more information IMO:

printk(XENLOG_ERR
       "%pd %pp: resizable BAR capability not supported for unprivileged domains\n",
       pdev->domain, &pdev->sbdf);

I wonder if this should instead be an XSM check, but that would
require a new XSM hook to process permissions for PCI capabilities.

> +        return -EOPNOTSUPP;
> +    }
> +
> +    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL);
> +    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
> +
> +    for ( unsigned int i = 0; i < nbars; i++, rebar_offset += PCI_REBAR_CTRL )
> +    {
> +        int rc;
> +        unsigned int index;
> +        struct vpci_bar *bars = pdev->vpci->header.bars;
> +
> +        index = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL) &
> +                PCI_REBAR_CTRL_BAR_IDX;

You could initialize index at definition.

> +
> +        if ( index >= PCI_HEADER_NORMAL_NR_BARS )
> +        {
> +            /*
> +             * TODO: for failed pathes, need to hide ReBar capability
> +             * from hardware domain instead of returning an error.
> +             */
> +            printk("%pp: BAR number %u in REBAR_CTRL register is too big\n",
> +                   &pdev->sdf, index);

XENLOG_ERR, plus we could print the domain the device was assigned to
(pdev->domain).

> +            return -EINVAL;
> +        }
> +
> +        if ( bars[index].type != VPCI_BAR_MEM64_LO &&
> +             bars[index].type != VPCI_BAR_MEM32 )
> +        {
> +            printk("%pp: BAR%u is not in memory space\n", &pdev->sbdf, index);
> +            return -EINVAL;
> +        }
> +
> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32,
> +                               rebar_offset + PCI_REBAR_CAP, 4, NULL);
> +        if ( rc )
> +        {
> +            printk("%pp: add register for PCI_REBAR_CAP failed (rc=%d)\n",
> +                   &pdev->sbdf, rc);
> +            return rc;
> +        }
> +
> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
> +                               rebar_offset + PCI_REBAR_CTRL, 4,
> +                               &bars[index]);
> +        if ( rc )
> +        {
> +            printk("%pp: add register for PCI_REBAR_CTRL failed %d\n",
> +                   &pdev->sbdf, rc);
> +            return rc;
> +        }

All the log messages above need the XENLOG_ERR prefix, plus possibly
printing the assigned domain.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 10:30:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 10:30:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857673.1269886 (Exim 4.92)
	(envelope-from )
	id 1tN8Mq-0005oH-1L; Mon, 16 Dec 2024 10:30:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857673.1269886; Mon, 16 Dec 2024 10:30: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 1tN8Mp-0005oA-Up; Mon, 16 Dec 2024 10:30:23 +0000
Received: by outflank-mailman (input) for mailman id 857673;
 Mon, 16 Dec 2024 10:30: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 1tN8Mo-0005o4-1U
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 10:30:22 +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 c06f1c55-bb98-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 11:30:21 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-38632b8ae71so2946888f8f.0
 for ; Mon, 16 Dec 2024 02:30:21 -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-388c801bb00sm7656051f8f.62.2024.12.16.02.30.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 02:30:20 -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: c06f1c55-bb98-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734345020; x=1734949820; 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=Xe3FOJmPSksOXmyBucYR8GgKOnpN39f2Q3+pJbrENks=;
        b=dM0zciDPWNgRXRbU4AifTjst/sVhpBeohYrwwt25Ff8uXQt9XNg6/ZG0Y4uggspkwk
         QHhMToErsZOsGsbMn4WROzCNF3M+Cw8izBN3KMDAxBNIPPikjb0smJFslXm96kmWl9/7
         gueJLAWkxjUq9VcXOTnghCltWfJHtw7q1fr4kdJVdolwxliEmh5R0j0dRh0YiNhv6M/O
         52fqGhIQ2HPFqdCcwj+XPG3jXZ04uWd+RkQPu7oQuaCVAQWToYLozGchMB9exjGjNzlN
         K2zvp/dL8oplbI6/7iY2SLnEyKnkbEZ9uy5xhK9IAPfYRd1c8Nos8QzRpqVVSaAank+s
         im2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734345020; x=1734949820;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Xe3FOJmPSksOXmyBucYR8GgKOnpN39f2Q3+pJbrENks=;
        b=de/5W0LCxfuU15w5QfYwlFjck8cy1QbPIxO5T25H30gBFHEeAKkomu4BSQuuQ94aE5
         9FAfE/xbITo6EpfR+nkZJNwl4RimXrZqEBjiFgny31CljtjuTiOLbl9efb7YA1X9siRt
         dIZwiXAyB7gduen/ZBmZVpDFreJZhWbw6qi2v538y+pAyz2UVTJ3WKwYXVCcQp24oKs9
         J1h9vlPv9H9EbvEwqexC6ebLNMoC/LSNwlHzvpRD4yFSFt5QfSfl7lsh1Vqb5t8LF8XA
         J0vmOQiGCOuPobt3T8YodZGZ544xVLOHvI87txMF1GXCE/9z2A3+DzF8L7wO7DEHspQr
         /BFQ==
X-Gm-Message-State: AOJu0YwQZ3jrbA/WQHRqjVCYeH+QES4YMBDe9A2YrF8GVC6CLOIShE8q
	N8FIZgFt3394IT+JJzmsoyPwIKNNzAOCjL2okA3WHmHrq+k6Sx30e+rJV8NIuQ==
X-Gm-Gg: ASbGncspk9n2LJUWx7yuCHfdiUItkzXCTN+dXVOPRVR7qTS3T8//5MtpVtj7gV/DaW5
	Dz6Vf8GgjKsOfLFVU2Hj6krLx8H3KD9ovsZh+WPpbQBMqZW7tXX6DMOtTydlIpZDEl0yIqVy68O
	WhzCPLGf4nbFcMlX2RShQKC2uaDeqMjYTcZvIqjMvhFz+8GvfOvGYIFXrfBza0I9YC57wc96+6h
	57gQ35Ztb4AUpNLOUzHYQx8rjeGDcLUHf0q6XpCeTL7B9OR2dR5aiNRL5lpy0yXQP+e9beCVpJQ
	ieQK6N4EEMVxtyh9efchudjDpVM6m/NWAfebgkDoTg==
X-Google-Smtp-Source: AGHT+IGhfMj/Fwz6l4IANvZ4VACgxfhv+8KRu1kxz2qNjfFnzorfImoGQdNIJA7WB9alz6otwp0h/A==
X-Received: by 2002:a05:6000:18a5:b0:385:e43a:4ded with SMTP id ffacd0b85a97d-3888e0c17f8mr9283915f8f.57.1734345020584;
        Mon, 16 Dec 2024 02:30:20 -0800 (PST)
Message-ID: <0773afe1-e892-4df5-a19e-25c55458e5cc@suse.com>
Date: Mon, 16 Dec 2024 11:30:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] vpci: Add resizable bar support
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Cc: xen-devel@lists.xenproject.org, Andrew Cooper
 , Julien Grall ,
 Stefano Stabellini , Huang Rui ,
 Jiqian Chen 
References: <20241213054232.2638640-1-Jiqian.Chen@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 16.12.2024 11:24, Roger Pau Monné wrote:
> On Fri, Dec 13, 2024 at 01:42:32PM +0800, Jiqian Chen wrote:
>> +static int cf_check init_rebar(struct pci_dev *pdev)
>> +{
>> +    uint32_t ctrl;
>> +    unsigned int rebar_offset, nbars;
>> +
>> +    rebar_offset = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_REBAR);
> 
> You can do the init at definition:
> 
>     uint32_t ctrl;
>     unsigned int nbars;
>     unsigned int rebar_offset = pci_find_ext_capability(pdev->sbdf,
>                                                         PCI_EXT_CAP_ID_REBAR);
> 
> 
>> +
>> +    if ( !rebar_offset )
>> +        return 0;
>> +
>> +    if ( !is_hardware_domain(pdev->domain) )
>> +    {
>> +        printk("ReBar is not supported for domUs\n");
> 
> This needs a bit more information IMO:
> 
> printk(XENLOG_ERR
>        "%pd %pp: resizable BAR capability not supported for unprivileged domains\n",
>        pdev->domain, &pdev->sbdf);
> 
> I wonder if this should instead be an XSM check, but that would
> require a new XSM hook to process permissions for PCI capabilities.

Ultimately perhaps, but right now we need to bail here irrespective of
XSM policy, as the DomU side simply is unimplemented.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 10:36:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 10:36:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857684.1269897 (Exim 4.92)
	(envelope-from )
	id 1tN8SW-0006jj-IP; Mon, 16 Dec 2024 10:36:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857684.1269897; Mon, 16 Dec 2024 10:36:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tN8SW-0006jc-Fo; Mon, 16 Dec 2024 10:36:16 +0000
Received: by outflank-mailman (input) for mailman id 857684;
 Mon, 16 Dec 2024 10:36:15 +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 1tN8SU-0006jW-L2
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 10:36:15 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 91ac66f0-bb99-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 11:36:12 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 16 Dec 2024 11:36:11 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 91ac66f0-bb99-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734345372; x=1765881372;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=6BkxDGBDhRIHdzbtNISrCpFxTwW7OpUIXdcwz/X+9OM=;
  b=UihHuV2VwYb59vjnzVPGnBU9jMmGkH4TFJhm5WUFqXU01cI6jqmuhuZs
   vddoTK2pbHX/72I4FBxhvX5WOPww+dVKmVXphOvBza1D1KbboPh4HMZTU
   CKVs/u579YQYePWRwHQCHl5Sun77dMa1fwye5RlKvtce2ADua7Zg32kqy
   g=;
X-CSE-ConnectionGUID: NKqfWz8PQ36utQdF98QfKQ==
X-CSE-MsgGUID: veJrgUAIRk20q0EmLljYNw==
X-IronPort-AV: E=Sophos;i="6.12,238,1728943200"; 
   d="scan'208";a="28194969"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: <5599dc89-0fa4-4255-b4a1-5b81e151d8c7@suse.com>
Content-Type: text/plain; charset="utf-8"
X-Forward: 149.5.228.1
References: <20241215154659.151158-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241215154659.151158-2-Ariel.Otilibili-Anieli@eurecom.fr> <5599dc89-0fa4-4255-b4a1-5b81e151d8c7@suse.com>
Date: Mon, 16 Dec 2024 11:36:11 +0100
Cc: xen-devel@lists.xenproject.org, "Anthony PERARD" 
To: "Jan Beulich" 
MIME-Version: 1.0
Message-ID: <2f7a85-67600280-e411-38ee5c40@258420856>
Subject: =?utf-8?q?Re=3A?= [PATCH 1/1] =?utf-8?q?tools/libacpi=3A?= clear ASL 
 warning about PCI0
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 1439

On Monday, December 16, 2024 10:53 CET, Jan Beulich =
 wrote:

> On 15.12.2024 16:40, Ariel Otilibili wrote:
> > * iasl complains =5FHID and =5FADR cannot be used at the same time
> >=20
> > ```
> > /usr/bin/iasl -vs -p tools/firmware/hvmloader/dsdt=5Fanycpu.tmp -tc=
 tools/firmware/hvmloader/dsdt=5Fanycpu.asl 2>&1 | grep -B10 HID
> > tools/firmware/hvmloader/dsdt=5Fanycpu.asl     40:        Device (P=
CI0)
> > Warning  3073 -                                    Multiple types ^=
  (Device object requires either a =5FHID or =5FADR, but not both)
> > ```
> >=20
> > * generally =5FHID devices are enumerated and have their drivers lo=
aded by ACPI
> > * this is from "ASL 2.0 Introduction and Overview" (page 4).
> > * removing =5FADR, the warning is cleared out.
>=20
> Okay, that's the positive aspect. Yet what about the potential fallou=
t thereof?
> Can you confirm that there's no risk of regressions with older guest =
OSes, for
> example?

Hi Jan,

OSes that were released after ACPI 2.0 should work [1]; including WinXP=
:=20
The 2.0 specs says either =5FHID or =5FADR should be included [2], not =
both (Section 6.1, page 146).

I chose WinXP because, on another patch, it came up in the discussion [=
3].

Ariel

[1] https://uefi.org/acpi/specs
[2] https://uefi.org/sites/default/files/resources/ACPI=5F2.pdf
[3] https://lore.kernel.org/all/ed248424-00a2-44ab-a7cf-3f2197d589a1@ci=
trix.com/
>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 10:38:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 10:38:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857691.1269906 (Exim 4.92)
	(envelope-from )
	id 1tN8UL-0007GL-Tt; Mon, 16 Dec 2024 10:38:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857691.1269906; Mon, 16 Dec 2024 10:38:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tN8UL-0007GE-Qt; Mon, 16 Dec 2024 10:38:09 +0000
Received: by outflank-mailman (input) for mailman id 857691;
 Mon, 16 Dec 2024 10:38: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 1tN8UL-0007G8-Dk
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 10:38:09 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d6787e12-bb99-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 11:38:07 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5d647d5df90so3833533a12.2
 for ; Mon, 16 Dec 2024 02:38:07 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d652ab5695sm3021655a12.13.2024.12.16.02.38.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 16 Dec 2024 02:38: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: d6787e12-bb99-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734345487; x=1734950287; 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=xDjQ3yeJk6FyymKuNTEpWNfKrXU4gPmReKx7i7Ge4nY=;
        b=GMDIT01Q34GwO4C13LP9Dm8P5uPZWjC97SmkBYcpJvedPHFhRSBHhIYhD8O/qYcKBt
         ni/fAvCNWhbdsXnEq0MsWwRLY2zK3l2mq4rxbHmBjxVMZdgOt0gFMie3vsTiRBJyurQo
         vZL2ZfPX+z7bmlwJAK0QjlFEHY/x67gkP/aV8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734345487; x=1734950287;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=xDjQ3yeJk6FyymKuNTEpWNfKrXU4gPmReKx7i7Ge4nY=;
        b=gn18ZsbHP8LqLL8M0fceBsEql09LhkcbdQ8z+CkUSkIGnlOCqYhV5+hiET70jfc93U
         kE2gSGqDiFyqebclpl0t7yv8O1rPmRGrYhTaLJ5TrKJdtSXJeMIOafiPmoPtvzk4Rn93
         q4iWp9pzj7MYKGn1DwyOq88OY2J0fHn4bA4tqMcEu8Lyw4xqztKQw2wjfW2EE+tMO6G+
         JTKVLRnWgPjRlg0zK4E705j8pGzAy940oaupFSJ4aS38kxNamPNJ2f0WkXVpVxkPFBgZ
         +q47JOJv4mu8gNpzawifKCKJ+JDb+CvfkP2wGkYCOdY7oslA1TagRxiP/lHJgFM9vgTd
         WKzw==
X-Gm-Message-State: AOJu0YwyKX8QlXdfEICDc5GwkaRscxNRbjiBFu+v90TN4DsqEa0eaU8S
	+hfA4zEwf6rfc49QuS9tVT+y2Al5dGxyb9USjDH4QyfptoXoSxEjal5riSCp4UE=
X-Gm-Gg: ASbGncu98x/6V7T6q4JFrm9MEZsU5tH/7t4bQC13YU9EcYBpV19kM7mOeMsprbbuXyL
	IKApjESs+e5TCqnqlM8QqEcL8aE2qNQBkCr+pXqf51I1hgDBHScyqG8F6hT7WA2LgN2wS1CKky+
	8300kpX+gnDqjMT+dFz0PGMhUl2fiC9VwIKBN4NiVDpX2IDlaMHYZiGYni/kTSkj6R6tjiiJXZ4
	E8iYNyIm+NM10KTDJ9mnR8YjYIcbXUl6LsVaIeKCubvMsrJwIed4HLrNqj4Jg==
X-Google-Smtp-Source: AGHT+IEcS/DTGGk0yWNg6DrZEvSrxXyYCbvVUts0r1Uex6pabuyYvdUq2Jfpa2jlRJm889lg6pcMBg==
X-Received: by 2002:a05:6402:2394:b0:5d0:e877:764e with SMTP id 4fb4d7f45d1cf-5d63c3b1c46mr7913752a12.24.1734345486998;
        Mon, 16 Dec 2024 02:38:06 -0800 (PST)
Date: Mon, 16 Dec 2024 11:38:05 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org,
	Andrew Cooper ,
	Julien Grall ,
	Stefano Stabellini ,
	Huang Rui , Jiqian Chen 
Subject: Re: [PATCH v3] vpci: Add resizable bar support
Message-ID: 
References: <20241213054232.2638640-1-Jiqian.Chen@amd.com>
 
 <0773afe1-e892-4df5-a19e-25c55458e5cc@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0773afe1-e892-4df5-a19e-25c55458e5cc@suse.com>

On Mon, Dec 16, 2024 at 11:30:22AM +0100, Jan Beulich wrote:
> On 16.12.2024 11:24, Roger Pau Monné wrote:
> > On Fri, Dec 13, 2024 at 01:42:32PM +0800, Jiqian Chen wrote:
> >> +static int cf_check init_rebar(struct pci_dev *pdev)
> >> +{
> >> +    uint32_t ctrl;
> >> +    unsigned int rebar_offset, nbars;
> >> +
> >> +    rebar_offset = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_REBAR);
> > 
> > You can do the init at definition:
> > 
> >     uint32_t ctrl;
> >     unsigned int nbars;
> >     unsigned int rebar_offset = pci_find_ext_capability(pdev->sbdf,
> >                                                         PCI_EXT_CAP_ID_REBAR);
> > 
> > 
> >> +
> >> +    if ( !rebar_offset )
> >> +        return 0;
> >> +
> >> +    if ( !is_hardware_domain(pdev->domain) )
> >> +    {
> >> +        printk("ReBar is not supported for domUs\n");
> > 
> > This needs a bit more information IMO:
> > 
> > printk(XENLOG_ERR
> >        "%pd %pp: resizable BAR capability not supported for unprivileged domains\n",
> >        pdev->domain, &pdev->sbdf);
> > 
> > I wonder if this should instead be an XSM check, but that would
> > require a new XSM hook to process permissions for PCI capabilities.
> 
> Ultimately perhaps, but right now we need to bail here irrespective of
> XSM policy, as the DomU side simply is unimplemented.

Yes, I should have said additionally rather than instead of the
is_hardware_domain() check.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 10:41:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 10:41:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857703.1269917 (Exim 4.92)
	(envelope-from )
	id 1tN8XV-0000gq-Cc; Mon, 16 Dec 2024 10:41:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857703.1269917; Mon, 16 Dec 2024 10:41: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 1tN8XV-0000gj-9a; Mon, 16 Dec 2024 10:41:25 +0000
Received: by outflank-mailman (input) for mailman id 857703;
 Mon, 16 Dec 2024 10:41: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 1tN8XU-0000gN-PO
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 10:41:24 +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 4b8969a1-bb9a-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 11:41:24 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-435f8f29f8aso27679565e9.2
 for ; Mon, 16 Dec 2024 02:41: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-436360154c7sm80505735e9.1.2024.12.16.02.41.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 02:41: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: 4b8969a1-bb9a-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734345683; x=1734950483; 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=U472/Npzn+Rc8KBcwENfcdFf4Nfo53RnxwaAKI9LbU8=;
        b=WCWj9amvLdMA47cjPR95ozmLg16WcUDCtnmPuZGPhGwUUtew6zGBOwfDh17CmrC2s9
         AYnI1LFUko6DhfUzL5EbGLlEYz9gk1AdumF9CyDMlJ3eCnuNlq2EFNsRYN7KgxYWz9NM
         KkXOyA7UrTftaxGJ7b81ifx2bvidsjGQBsOIKpdcOCB4aRkpOXceo0M/D/7+Plyqs7a7
         rBx2wzW/Hbsp7ac7JJhY6ZgBLJIDgKldw78K9vX+R4Ibs3KdwZnOHXFHGEQGJLCWiQMH
         pWhGbGcmVTYmpiIyEqhMCbfnGPP8sZSCvI/o/rS9htJxEbApj1/BYZ1DPRgD6rli9cCS
         M6dA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734345683; x=1734950483;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=U472/Npzn+Rc8KBcwENfcdFf4Nfo53RnxwaAKI9LbU8=;
        b=kfMda5pA7B5w3hBjPU3WZE+EJ3ocTk5+ni5nw7whMQRFyipzTKUqf+Q5IsdkQ8HCBv
         qQoKpbEHdY5hIk4IaVhi4RhB0oG2+HEZTAY5XjUWL0Y+fP86y4HAvC7VwBcs2XsiWuWi
         DA4C6ZgTAZ70RoLazNOtuY9mWhlqRMeCXM5Nm1iZdNk9xB9ObceJPjQssoMOYOBQpgnj
         FQJPgYon6B/eynvWEdeoctwDTlRSALexAi/7AcUR1jKmEgUrYjkEaIM8/atUGG4pPXdB
         ojs3CXOJ3csNN8RNFBKmJfOv2dzezv9WTfx355IojwFjvpzmBc0USCSZpQ2ydKvBFINr
         lQ3A==
X-Forwarded-Encrypted: i=1; AJvYcCVgVfPz7lN+0xpei4bVuOwfP8tFfDjW8AnfjpG3daKgktCOkhHxIzjk5OvheVnz77KYqrqL8AetRn4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxmARIVHv0prmlqpz4sY6Cn/ZxInNaivRnPgp8nJEy+RF++w/YE
	0hzxWSwOFAg5qsrrP+2W1o2IOqVe9XaeBrZ4rR3kuiEkvxBhewtjrF0v0DJjBg==
X-Gm-Gg: ASbGncsFKgL6M2V4YfLvmtzSXdYrBj2eSOI79UoVltvtcXKTH7LogsScdLTHBsp/7We
	9jc2phjL1sMHTCB+eVZ2OF7Uepdxnta53/KiyPlHiPmE7jvMi/91ZUZYcH3LNBjLUY6x/i+hegY
	qNUByOLWA5WXyFuGmcDkhVQv4taPbci9fZy4vM2mSP9Ql4zlYZkfjrSmZ4JuNjdntE2c77N1Sbd
	UaEDC851hEwLj51rpZwzal7KLIa6/UtYswxaV12FBXqjWM+mp/tCwQEtUL/xI/i4eEdLhgw4zeZ
	QylpOsyr8hGCA8AD/005I2FcL9ejiJKDlXsNF2gqLQ==
X-Google-Smtp-Source: AGHT+IH8GlOnrPLZYbXM5JU1fntsaCPcyTL3jUF4/R+hjyeUPoWTONv/YYBXb9eX95sks1ySRhfN9g==
X-Received: by 2002:a05:600c:468b:b0:434:f871:1b96 with SMTP id 5b1f17b1804b1-4362aab4cb4mr101242055e9.29.1734345683429;
        Mon, 16 Dec 2024 02:41:23 -0800 (PST)
Message-ID: 
Date: Mon, 16 Dec 2024 11:41:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 5/7] xen: add new domctl get_changed_domain
To: Juergen Gross 
Cc: "Daniel P. Smith" ,
 Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241213162421.16782-1-jgross@suse.com>
 <20241213162421.16782-6-jgross@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: <20241213162421.16782-6-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.12.2024 17:24, Juergen Gross wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -193,6 +193,57 @@ static void domain_changed_state(const struct domain *d)
>      spin_unlock(&dom_state_changed_lock);
>  }
>  
> +static void set_domain_state_info(struct xen_domctl_get_domain_state *info,
> +                                  const struct domain *d)
> +{
> +    info->state = XEN_DOMCTL_GETDOMSTATE_STATE_EXIST;
> +    if ( d->is_shut_down )
> +        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN;
> +    if ( d->is_dying == DOMDYING_dying )
> +        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DYING;
> +    if ( d->is_dying == DOMDYING_dead )
> +        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DEAD;
> +    info->unique_id = d->unique_id;
> +}
> +
> +int get_domain_state(struct xen_domctl_get_domain_state *info, struct domain *d,
> +                     domid_t *domid)
> +{
> +    unsigned int dom;
> +
> +    if ( info->pad0 || info->pad1 )
> +        return -EINVAL;
> +
> +    if ( d )
> +    {
> +        set_domain_state_info(info, d);
> +
> +        return 0;
> +    }
> +
> +    while ( (dom = find_first_bit(dom_state_changed, DOMID_MASK + 1)) <
> +            DOMID_FIRST_RESERVED )
> +    {
> +        if ( test_and_clear_bit(dom, dom_state_changed) )

For these two accesses to dom_state_changed don't you need to hold the
lock patch 4 introduces? Also didn't you say you'd constrain the new
sub-op to the sole domain having VIRQ_DOM_EXEC bound (which, ftaod,
isn't enough to eliminate the race)?

> +        {
> +            *domid = dom;
> +
> +            d = rcu_lock_domain_by_id(dom);
> +
> +            if ( d )
> +            {
> +                set_domain_state_info(info, d);
> +
> +                rcu_unlock_domain(d);
> +            }

Oh, on the implicit "else" is where the original memset() would come into
play: You want to make sure at least ->state, but perhaps also ->unique_id
are cleared (rather than demanding the caller to clear them ahead of making
the call).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 10:51:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 10:51:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857718.1269932 (Exim 4.92)
	(envelope-from )
	id 1tN8hC-0002ne-By; Mon, 16 Dec 2024 10:51:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857718.1269932; Mon, 16 Dec 2024 10:51: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 1tN8hC-0002nX-8g; Mon, 16 Dec 2024 10:51:26 +0000
Received: by outflank-mailman (input) for mailman id 857718;
 Mon, 16 Dec 2024 10:51: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 1tN8hA-0002kq-OF
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 10:51: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 af67b0ee-bb9b-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 11:51:21 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-43623f0c574so26785205e9.2
 for ; Mon, 16 Dec 2024 02:51:21 -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-436362c8fbasm80586165e9.44.2024.12.16.02.51.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 02:51: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: af67b0ee-bb9b-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734346280; x=1734951080; 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=+0ZI0HEEOzwUl1IvW7tceorT+M4QEr+GcDshLLfHT50=;
        b=UyxV1Wh7nk4ywFbiuOG6BRR8Jdy9X1OeDaFm08uT1gJxS+Col7Hj3PnSc01wYlpmpx
         sMlP+N6YQRgYxE+Dyz95QO8EpIg5zZP635gLA7I+6hXpJU/M+KY5tYGNonDF9ZsHtIom
         DNXBngmv5nxMPs2aRbp23diY6Cqckc9TXWs1Ory9lLjcB8SWI8CN5MXJKzn4pg6K77//
         3Y2Lr6Xvw+e8ogbcyhVt4udpNUi6nNmK1twUQFMkwVcEZ5TPrIm8u5JLjOmpsFfjiGYA
         t1m5RtwGTBRks4dtvTN+TTKWApRBIfTMN0kS8WmGLp0NFFiLn2QgX4IDCI4vWMbwYxDj
         6IIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734346280; x=1734951080;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+0ZI0HEEOzwUl1IvW7tceorT+M4QEr+GcDshLLfHT50=;
        b=iJgJyMg28gOL6ovMAU2nqg1uhuSe8NuD1fsw/cYgmv6vp4aIte4ztW2agHD2Fkkn3O
         m6b6j31sfROXGM5AKkZ+kGr/3lKXGERBWzawQSxhPWkmdh44/NS3CWak264YiA2OLNSa
         boF0+Pl4AjRCUVjSg7naj9yJbrDKVVXcbmhddOqGtJrJdZJtN1Em4eNxUudWoIa9Sf1B
         LSEvgwoRtjEVnUHcdTGdAaKMYunI3coEan9ypNF7wG0c+k4Gww48BewtQ5tQAAV4BNU6
         r2C+P+BqyhP6NfLHgzf7CbfMIqUErjz4aoxBjeKJ4YXY9sPFEzQdB1mdpNpmOm219eqk
         xLJg==
X-Forwarded-Encrypted: i=1; AJvYcCXlL0hVZtGnLGEfa7uu4vfzVRyTWAzo2t76+bt3DCE1DpfmOstLM5RT0x1bz2z8Bf0UU/FUwiyXlVc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzWzNyvJrgPkr91OSWx94cuZ3CwynHkZcNp2bSlLa3TymZrySUc
	RCbRZWkuKGfTswiEWgxr4j0zmxwOj9SQQMKKzX0MP30DtcHAKbZ46UEestKiLA==
X-Gm-Gg: ASbGncuuUndR8Q5xzqXmvxZ6mHrXalEvVvsmBNhKjFv+DWB8s8OrERMbkXeN3XvnrnY
	LHNvWbB8dDylZoavrvKgbSIAXfzMoXimIIdXesWlEqa/dgi+z3lhMKwR0zIKNBWJ8zKzyBI9RdQ
	hFdaodLP9Ep4lsYh/Oh9ySeGd0hbnnVX09kzvIl4JqhlMIZApgasj11XUYmIusksgv2L2uvNhGf
	jNHzb5pb7O3glaJN6EoAehxAzp0+ywtrtlMK9yGNfiJOEVdmjiHbhC9DYsojgoCuAVUVmJhap/n
	au1uE6VRRehTy7JLGiadAWnaaU++AMOdA3/ia1n9zw==
X-Google-Smtp-Source: AGHT+IGTIWGR9C8KMv5jmcovA1i/4F1juPg9gXNuS+70r7bq6JRpLdoUOmlTRrb2TPWdFFpvfJ5OLg==
X-Received: by 2002:a05:600c:1c82:b0:431:5863:4240 with SMTP id 5b1f17b1804b1-4362aa944bbmr92086365e9.24.1734346280207;
        Mon, 16 Dec 2024 02:51:20 -0800 (PST)
Message-ID: 
Date: Mon, 16 Dec 2024 11:51:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v12 01/12] xen/common: add cache coloring common code
To: Carlo Nonato 
Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-2-carlo.nonato@minervasys.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: <20241213162815.9196-2-carlo.nonato@minervasys.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.12.2024 17:28, Carlo Nonato wrote:
> Last Level Cache (LLC) coloring allows to partition the cache in smaller
> chunks called cache colors.
> 
> Since not all architectures can actually implement it, add a HAS_LLC_COLORING
> Kconfig option.
> LLC_COLORS_ORDER Kconfig option has a range maximum of 10 (2^10 = 1024)
> because that's the number of colors that fit in a 4 KiB page when integers
> are 4 bytes long.
> 
> LLC colors are a property of the domain, so struct domain has to be extended.
> 
> Based on original work from: Luca Miccio 
> 
> Signed-off-by: Carlo Nonato 
> Signed-off-by: Marco Solieri 
> Acked-by: Michal Orzel 
> ---
> v12:
> - fixed build errors
> - added opt_llc_coloring to improve readibility
> - reverted llc_coloring_enabled type to bool
> v11:
> - __COLORING_H__ -> __XEN_LLC_COLORING_H__ in llc-coloring.h
> - added SPDX tag to cache-coloring.rst
> - llc-coloring=off now takes precedence over other cmdline options
> - removed useless #includes
> v10:
> - fixed commit message to use LLC_COLORS_ORDER
> - added documentation to index.rst
> - moved check on CONFIG_NUMA in arch/arm/Kconfig (next patch)
> - fixed copyright line
> - fixed array type for colors parameter in print_colors()
> - added check on (way_size & ~PAGE_MASK)
> v9:
> - dropped _MAX_ from CONFIG_MAX_LLC_COLORS_ORDER
> v8:
> - minor documentation fixes
> - "llc-coloring=on" is inferred from "llc-nr-ways" and "llc-size" usage
> - turned CONFIG_NR_LLC_COLORS to CONFIG_MAX_LLC_COLORS_ORDER, base-2 exponent
> - moved Kconfig options to common/Kconfig
> - don't crash if computed max_nr_colors is too large
> v7:
> - SUPPORT.md changes added to this patch
> - extended documentation to better address applicability of cache coloring
> - "llc-nr-ways" and "llc-size" params introduced in favor of "llc-way-size"
> - moved dump_llc_coloring_info() call in 'm' keyhandler (pagealloc_info())
> v6:
> - moved almost all code in common
> - moved documentation in this patch
> - reintroduced range for CONFIG_NR_LLC_COLORS
> - reintroduced some stub functions to reduce the number of checks on
>   llc_coloring_enabled
> - moved domain_llc_coloring_free() in same patch where allocation happens
> - turned "d->llc_colors" to pointer-to-const
> - llc_coloring_init() now returns void and panics if errors are found
> v5:
> - used - instead of _ for filenames
> - removed domain_create_llc_colored()
> - removed stub functions
> - coloring domain fields are now #ifdef protected
> v4:
> - Kconfig options moved to xen/arch
> - removed range for CONFIG_NR_LLC_COLORS
> - added "llc_coloring_enabled" global to later implement the boot-time
>   switch
> - added domain_create_llc_colored() to be able to pass colors
> - added is_domain_llc_colored() macro
> ---
>  SUPPORT.md                        |   7 ++
>  docs/index.rst                    |   1 +
>  docs/misc/cache-coloring.rst      | 118 ++++++++++++++++++++++++++++
>  docs/misc/xen-command-line.pandoc |  37 +++++++++
>  xen/common/Kconfig                |  21 +++++
>  xen/common/Makefile               |   1 +
>  xen/common/keyhandler.c           |   3 +
>  xen/common/llc-coloring.c         | 124 ++++++++++++++++++++++++++++++
>  xen/common/page_alloc.c           |   3 +
>  xen/include/xen/llc-coloring.h    |  36 +++++++++
>  xen/include/xen/sched.h           |   5 ++
>  11 files changed, 356 insertions(+)
>  create mode 100644 docs/misc/cache-coloring.rst
>  create mode 100644 xen/common/llc-coloring.c
>  create mode 100644 xen/include/xen/llc-coloring.h
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 82239d0294..998faf5635 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -401,6 +401,13 @@ by maintaining multiple physical to machine (p2m) memory mappings.
>      Status, x86 HVM: Tech Preview
>      Status, ARM: Tech Preview
>  
> +### Cache coloring
> +
> +Allows to reserve Last Level Cache (LLC) partitions for Dom0, DomUs and Xen
> +itself.
> +
> +    Status, Arm64: Experimental
> +
>  ## Resource Management
>  
>  ### CPU Pools
> diff --git a/docs/index.rst b/docs/index.rst
> index 1d44796d72..1bb8d02ea3 100644
> --- a/docs/index.rst
> +++ b/docs/index.rst
> @@ -66,6 +66,7 @@ Documents in need of some rearranging.
>     misc/xen-makefiles/makefiles
>     misra/index
>     fusa/index
> +   misc/cache-coloring
>  
>  
>  Miscellanea
> diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
> new file mode 100644
> index 0000000000..371f21a0e7
> --- /dev/null
> +++ b/docs/misc/cache-coloring.rst
> @@ -0,0 +1,118 @@
> +.. SPDX-License-Identifier: CC-BY-4.0
> +
> +Xen cache coloring user guide
> +=============================
> +
> +The cache coloring support in Xen allows to reserve Last Level Cache (LLC)
> +partitions for Dom0, DomUs and Xen itself. Currently only ARM64 is supported.
> +Cache coloring realizes per-set cache partitioning in software and is applicable
> +to shared LLCs as implemented in Cortex-A53, Cortex-A72 and similar CPUs.
> +
> +To compile LLC coloring support set ``CONFIG_LLC_COLORING=y``.
> +
> +If needed, change the maximum number of colors with
> +``CONFIG_LLC_COLORS_ORDER=``.
> +
> +Runtime configuration is done via `Command line parameters`_.
> +
> +Background
> +**********
> +
> +Cache hierarchy of a modern multi-core CPU typically has first levels dedicated
> +to each core (hence using multiple cache units), while the last level is shared
> +among all of them. Such configuration implies that memory operations on one
> +core (e.g. running a DomU) are able to generate interference on another core
> +(e.g. hosting another DomU). Cache coloring realizes per-set cache-partitioning
> +in software and mitigates this, guaranteeing more predictable performances for
> +memory accesses.
> +Software-based cache coloring is particularly useful in those situations where
> +no hardware mechanisms (e.g., DSU-based way partitioning) are available to
> +partition caches. This is the case for e.g., Cortex-A53, A57 and A72 CPUs that
> +feature a L2 LLC cache shared among all cores.
> +
> +The key concept underlying cache coloring is a fragmentation of the memory
> +space into a set of sub-spaces called colors that are mapped to disjoint cache
> +partitions. Technically, the whole memory space is first divided into a number
> +of subsequent regions. Then each region is in turn divided into a number of
> +subsequent sub-colors. The generic i-th color is then obtained by all the
> +i-th sub-colors in each region.
> +
> +::
> +
> +                            Region j            Region j+1
> +                .....................   ............
> +                .                     . .
> +                .                       .
> +            _ _ _______________ _ _____________________ _ _
> +                |     |     |     |     |     |     |
> +                | c_0 | c_1 |     | c_n | c_0 | c_1 |
> +           _ _ _|_____|_____|_ _ _|_____|_____|_____|_ _ _
> +                    :                       :
> +                    :                       :...         ... .
> +                    :                            color 0
> +                    :...........................         ... .
> +                                                :
> +          . . ..................................:
> +
> +How colors are actually defined depends on the function that maps memory to
> +cache lines. In case of physically-indexed, physically-tagged caches with linear
> +mapping, the set index is found by extracting some contiguous bits from the
> +physical address. This allows colors to be defined as shown in figure: they
> +appear in memory as subsequent blocks of equal size and repeats themselves after
> +``n`` different colors, where ``n`` is the total number of colors.
> +
> +If some kind of bit shuffling appears in the mapping function, then colors
> +assume a different layout in memory. Those kind of caches aren't supported by
> +the current implementation.
> +
> +**Note**: Finding the exact cache mapping function can be a really difficult
> +task since it's not always documented in the CPU manual. As said Cortex-A53, A57
> +and A72 are known to work with the current implementation.
> +
> +How to compute the number of colors
> +###################################
> +
> +Given the linear mapping from physical memory to cache lines for granted, the
> +number of available colors for a specific platform is computed using three
> +parameters:
> +
> +- the size of the LLC.
> +- the number of the LLC ways.
> +- the page size used by Xen.
> +
> +The first two parameters can be found in the processor manual, while the third
> +one is the minimum mapping granularity. Dividing the cache size by the number of
> +its ways we obtain the size of a way. Dividing this number by the page size,
> +the number of total cache colors is found. So for example an Arm Cortex-A53
> +with a 16-ways associative 1 MiB LLC can isolate up to 16 colors when pages are
> +4 KiB in size.
> +
> +Effective colors assignment
> +###########################
> +
> +When assigning colors, if one wants to avoid cache interference between two
> +domains, different colors needs to be used for their memory.
> +
> +Command line parameters
> +***********************
> +
> +Specific documentation is available at `docs/misc/xen-command-line.pandoc`.
> +
> ++----------------------+-------------------------------+
> +| **Parameter**        | **Description**               |
> ++----------------------+-------------------------------+
> +| ``llc-coloring``     | Enable coloring at runtime    |
> ++----------------------+-------------------------------+
> +| ``llc-size``         | Set the LLC size              |
> ++----------------------+-------------------------------+
> +| ``llc-nr-ways``      | Set the LLC number of ways    |
> ++----------------------+-------------------------------+
> +
> +Auto-probing of LLC specs
> +#########################
> +
> +LLC size and number of ways are probed automatically by default.
> +
> +LLC specs can be manually set via the above command line parameters. This
> +bypasses any auto-probing and it's used to overcome failing situations, such as
> +flawed probing logic, or for debugging/testing purposes.
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index 293dbc1a95..abd8dae96f 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1708,6 +1708,43 @@ This option is intended for debugging purposes only.  Enable MSR_DEBUGCTL.LBR
>  in hypervisor context to be able to dump the Last Interrupt/Exception To/From
>  record with other registers.
>  
> +### llc-coloring (arm64)
> +> `= `
> +
> +> Default: `false`
> +
> +Flag to enable or disable LLC coloring support at runtime. This option is
> +available only when `CONFIG_LLC_COLORING` is enabled. See the general
> +cache coloring documentation for more info.
> +
> +### llc-nr-ways (arm64)
> +> `= `
> +
> +> Default: `Obtained from hardware`
> +
> +Specify the number of ways of the Last Level Cache. This option is available
> +only when `CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are used
> +to find the number of supported cache colors. By default the value is
> +automatically computed by probing the hardware, but in case of specific needs,
> +it can be manually set. Those include failing probing and debugging/testing
> +purposes so that it's possible to emulate platforms with different number of
> +supported colors. If set, also "llc-size" must be set, otherwise the default
> +will be used. Note that using both options implies "llc-coloring=on".
> +
> +### llc-size (arm64)
> +> `= `
> +
> +> Default: `Obtained from hardware`
> +
> +Specify the size of the Last Level Cache. This option is available only when
> +`CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are used to find
> +the number of supported cache colors. By default the value is automatically
> +computed by probing the hardware, but in case of specific needs, it can be
> +manually set. Those include failing probing and debugging/testing purposes so
> +that it's possible to emulate platforms with different number of supported
> +colors. If set, also "llc-nr-ways" must be set, otherwise the default will be
> +used. Note that using both options implies "llc-coloring=on".
> +
>  ### lock-depth-size
>  > `= `
>  
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 90268d9249..b4ec6893be 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -71,6 +71,9 @@ config HAS_IOPORTS
>  config HAS_KEXEC
>  	bool
>  
> +config HAS_LLC_COLORING
> +	bool
> +
>  config HAS_PIRQ
>  	bool
>  
> @@ -516,4 +519,22 @@ config TRACEBUFFER
>  	  to be collected at run time for debugging or performance analysis.
>  	  Memory and execution overhead when not active is minimal.
>  
> +config LLC_COLORING
> +	bool "Last Level Cache (LLC) coloring" if EXPERT
> +	depends on HAS_LLC_COLORING
> +
> +config LLC_COLORS_ORDER
> +	int "Maximum number of LLC colors (base-2 exponent)"
> +	range 1 10
> +	default 7
> +	depends on LLC_COLORING
> +	help
> +	  Controls the build-time size of various arrays associated with LLC
> +	  coloring. The value is a base-2 exponent. Refer to cache coloring
> +	  documentation for how to compute the number of colors supported by the
> +	  platform. This is only an upper bound. The runtime value is autocomputed
> +	  or manually set via cmdline parameters.
> +	  The default value corresponds to an 8 MiB 16-ways LLC, which should be
> +	  more than what's needed in the general case.
> +
>  endmenu
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index b279b09bfb..cba3b32733 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -25,6 +25,7 @@ obj-y += keyhandler.o
>  obj-$(CONFIG_KEXEC) += kexec.o
>  obj-$(CONFIG_KEXEC) += kimage.o
>  obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
> +obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
>  obj-$(CONFIG_MEM_ACCESS) += mem_access.o
>  obj-y += memory.o
>  obj-y += multicall.o
> diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
> index 6da291b34e..6ea54838d4 100644
> --- a/xen/common/keyhandler.c
> +++ b/xen/common/keyhandler.c
> @@ -5,6 +5,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -304,6 +305,8 @@ static void cf_check dump_domains(unsigned char key)
>  
>          arch_dump_domain_info(d);
>  
> +        domain_dump_llc_colors(d);
> +
>          rangeset_domain_printk(d);
>  
>          dump_pageframe_info(d);
> diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
> new file mode 100644
> index 0000000000..b0fc162b05
> --- /dev/null
> +++ b/xen/common/llc-coloring.c
> @@ -0,0 +1,124 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Last Level Cache (LLC) coloring common code
> + *
> + * Copyright (C) 2024, Advanced Micro Devices, Inc.
> + * Copyright (C) 2024, Minerva Systems SRL
> + */
> +#include 
> +#include 
> +#include 
> +
> +#define NR_LLC_COLORS          (1U << CONFIG_LLC_COLORS_ORDER)
> +
> +/*
> + * -1: not specified (disabled unless llc-size and llc-nr-ways present)
> + *  0: explicitly disabled through cmdline
> + *  1: explicitly enabled through cmdline
> + */
> +static int8_t __initdata opt_llc_coloring = -1;
> +boolean_param("llc-coloring", opt_llc_coloring);
> +
> +static bool __ro_after_init llc_coloring_enabled;
> +
> +static unsigned int __initdata llc_size;
> +size_param("llc-size", llc_size);
> +static unsigned int __initdata llc_nr_ways;
> +integer_param("llc-nr-ways", llc_nr_ways);
> +/* Number of colors available in the LLC */
> +static unsigned int __ro_after_init max_nr_colors;
> +
> +static void print_colors(const unsigned int colors[], unsigned int num_colors)
> +{
> +    unsigned int i;
> +
> +    printk("{ ");
> +    for ( i = 0; i < num_colors; i++ )
> +    {
> +        unsigned int start = colors[i], end = start;
> +
> +        printk("%u", start);
> +
> +        for ( ; i < num_colors - 1 && end + 1 == colors[i + 1]; i++, end++ )
> +            ;
> +
> +        if ( start != end )
> +            printk("-%u", end);
> +
> +        if ( i < num_colors - 1 )
> +            printk(", ");
> +    }
> +    printk(" }\n");
> +}
> +
> +void __init llc_coloring_init(void)
> +{
> +    unsigned int way_size;
> +
> +    llc_coloring_enabled = (opt_llc_coloring == 1);

Generally I'd suggest to only use > 0, >= 0, < 0, and <= 0 on such
variables.

> +    if ( (opt_llc_coloring != 0) && llc_size && llc_nr_ways )
> +    {
> +        llc_coloring_enabled = true;
> +        way_size = llc_size / llc_nr_ways;
> +    }

Hmm, I actually see a difference in someone saying

"llc-coloring=0 llc-size=... llc-nr-ways=..."

vs

"llc-size=... llc-nr-ways=... llc-coloring=0"

I'm not sure about Arm, but on x86 this can be relevant as there may be
pre-set parts of a command line with appended (human) overrides. Therefore
it always wants to be "last wins". Yet yes, you may weant to take the
position that in such a case the former example would require "llc-coloring=1"
to also be added. Kind of against the shorthand llc-size+llc-nr-ways only,
though.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 11:00:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 11:00:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857732.1269942 (Exim 4.92)
	(envelope-from )
	id 1tN8q9-0004c4-9H; Mon, 16 Dec 2024 11:00:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857732.1269942; Mon, 16 Dec 2024 11:00: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 1tN8q9-0004bx-6S; Mon, 16 Dec 2024 11:00:41 +0000
Received: by outflank-mailman (input) for mailman id 857732;
 Mon, 16 Dec 2024 11:00: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 1tN8q7-0004aC-Gp
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 11:00:39 +0000
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [2a00:1450:4864:20::533])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fb0eea6c-bb9c-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 12:00:37 +0100 (CET)
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5d4e2aa7ea9so7484922a12.2
 for ; Mon, 16 Dec 2024 03:00:37 -0800 (PST)
Received: from localhost ([85.152.134.39]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d652ab5198sm3025746a12.8.2024.12.16.03.00.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 03:00: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: fb0eea6c-bb9c-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1734346837; x=1734951637; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=A/bn0R9iQWFXBtLuN73CSNYk9yOwOpbIqDziJTUJp+U=;
        b=IXU4aEal9quum0ettsL+xubdUIAm+ZWQpMhBVbPOSP0Zbbk8OezDw/D1Vx5kIEY405
         0ccq2zw5pNgWFloHNPfaI7oXQQkOajkmcAYbobXRuGJnr+6Dt7+joaYb1bmbMqMP6z0x
         eFSraceq5Mgn/nhpOSfasO4YlnMlMy1P+snIk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734346837; x=1734951637;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=A/bn0R9iQWFXBtLuN73CSNYk9yOwOpbIqDziJTUJp+U=;
        b=UeyyTidPpFTT7M01WQL3z5a9iKveuCDEKaSZyzZ1YIuR+WzxF7U+mVQOhp857piUcq
         WLKlb8yalKgm8+IygCWPDmUtsjxl5xfGACJJ6QnWokKerKG8r+pACOaIKEMyXZ8SbFZ2
         IJUrk9Mkjbg+8oZ4zV266CRZGLn0qWIbsk59f0TACcvUzJDv75FkY/MtbzmBFAqQfiXR
         veOZHqA66zwPgffBDhhIA5e+27fDQ00HI0JevfEkWb0LyuSiFjGesXTM/bCKqML+9lPQ
         JfEpSwZuVftno68VxACP1R23Z3iVQHffcMMvOeaCMEXmOubsLRACAsT/0ycxB4t2mXKo
         sgmg==
X-Forwarded-Encrypted: i=1; AJvYcCU+qo5SSanXmkgQTSJNHT/8PCTW80QjoKe1n53/TjXHa6gKjyExp/bwJn3TSQC6WVgG3Ubq9CykYP4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yze8MIKHh9GjN7/NhY2PN1aP9GcX2rzc4XE65FKrD5YYcUPGX3t
	9WBjn8zzScGHQcG9IYVajjM3o/1e0rKlalMnhQLtJWTgFwa+X2upN9yInLj0JcXfqsmGK6K22s4
	Pcw+YqKok
X-Gm-Gg: ASbGncstI+MZreyaCG9L7wZjG4JIuU0PYG2ouqdWL9Psf94R+8SuY01DU02kXHMisLn
	KMcpaxISDE3bGHVza2Q7TkMuU2T+Nxkaw4HnA0pPfveQDssvxjSI5NVLK+FHnwN3SVonhEzVhFX
	dufcYP5V30SFOPPDEPHv4aE3LMlZI1s3WdADGpcUu0PclkUgQeIcp+O++cjBklLQa8+DruiC1F/
	HDa7QQPbXVlA8xprwXrHb889axrA4LU+SWmh5W6UgQcfvqZkLZURRNT7X1pBzc=
X-Google-Smtp-Source: AGHT+IEk9uTWPFQ5ArPRN+4/vyNaOYATQc2paUoLBRhzAxSPfvXkCqkHsRqTrmW9JJguC1KcO8GGUg==
X-Received: by 2002:a05:6402:5288:b0:5d3:e8d1:a46 with SMTP id 4fb4d7f45d1cf-5d63c3bf48dmr12572098a12.30.1734346836868;
        Mon, 16 Dec 2024 03:00:36 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Mon, 16 Dec 2024 11:00:33 +0000
Message-Id: 
Cc: "Andrew Cooper" ,
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= ,
 
Subject: Re: [PATCH v2 02/13] x86/xstate: Create map/unmap primitives for
 xsave areas
From: "Alejandro Vallejo" 
To: "Jan Beulich" 
X-Mailer: aerc 0.18.2
References: <20241105143310.28301-1-alejandro.vallejo@cloud.com>
 <20241105143310.28301-3-alejandro.vallejo@cloud.com>
 <2948b6c9-eb8b-400f-be0a-274cbf7ffde6@suse.com>
In-Reply-To: <2948b6c9-eb8b-400f-be0a-274cbf7ffde6@suse.com>

On Mon Dec 9, 2024 at 4:11 PM GMT, Jan Beulich wrote:
> On 05.11.2024 15:32, Alejandro Vallejo wrote:
> > --- a/xen/arch/x86/include/asm/xstate.h
> > +++ b/xen/arch/x86/include/asm/xstate.h
> > @@ -143,4 +143,46 @@ static inline bool xstate_all(const struct vcpu *v=
)
> >             (v->arch.xcr0_accum & XSTATE_LAZY & ~XSTATE_FP_SSE);
> >  }
> > =20
> > +/*
> > + * Fetch a pointer to a vCPU's XSAVE area
> > + *
> > + * TL;DR: If v =3D=3D current, the mapping is guaranteed to already ex=
ist.
> > + *
> > + * Despite the name, this macro might not actually map anything. The o=
nly case
> > + * in which a mutation of page tables is strictly required is when ASI=
=3D=3Don &&
> > + * v!=3Dcurrent. For everything else the mapping already exists and ne=
eds not
> > + * be created nor destroyed.
> > + *
> > + *                         +-----------------+--------------+
> > + *                         |   v =3D=3D current  | v !=3D current |
> > + *          +--------------+-----------------+--------------+
> > + *          | ASI  enabled | per-vCPU fixmap |  actual map  |
> > + *          +--------------+-----------------+--------------+
> > + *          | ASI disabled |             directmap          |
> > + *          +--------------+--------------------------------+
> > + *
> > + * There MUST NOT be outstanding maps of XSAVE areas of the non-curren=
t vCPU
> > + * at the point of context switch. Otherwise, the unmap operation will
> > + * misbehave.
> > + *
> > + * TODO: Expand the macro to the ASI cases after infra to do so is in =
place.
> > + *
> > + * @param v Owner of the XSAVE area
> > + */
> > +#define VCPU_MAP_XSAVE_AREA(v) ((v)->arch.xsave_area)
>
> When this is fleshed out, I expect (hope) type safety (type of "return
> value") will remain to be there. I think it would be nice ...

The return type will always be a pointer to `struct xsave_struct`, so that'=
s
definitely type-safe.

>
> > +/*
> > + * Drops the mapping of a vCPU's XSAVE area and nullifies its pointer =
on exit
> > + *
> > + * See VCPU_MAP_XSAVE_AREA() for additional information on the persist=
ence of
> > + * these mappings. This macro only tears down the mappings in the ASI=
=3Don &&
> > + * v!=3Dcurrent case.
> > + *
> > + * TODO: Expand the macro to the ASI cases after infra to do so is in =
place.
> > + *
> > + * @param v Owner of the XSAVE area
> > + * @param x XSAVE blob of v
> > + */
> > +#define VCPU_UNMAP_XSAVE_AREA(v, x) ({ (x) =3D NULL; })
>
> ... if this was typesafe (at least on x) from the very beginning as
> well. Thoughts?

I tentatively intend for both macros to involve a call to static inline
functions when the real infrastructure is in place. By the time everything =
is
fleshed out both will be definitely type-safe. Const-ness might suffer thou=
gh,
as there's a tension between clarity of static inlines and flexible qualifi=
ers
(i.e: having const outputs iff inputs are const).

>
> Jan

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 11:01:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 11:01:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857740.1269952 (Exim 4.92)
	(envelope-from )
	id 1tN8qr-0005HL-Is; Mon, 16 Dec 2024 11:01:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857740.1269952; Mon, 16 Dec 2024 11:01:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tN8qr-0005HE-FM; Mon, 16 Dec 2024 11:01:25 +0000
Received: by outflank-mailman (input) for mailman id 857740;
 Mon, 16 Dec 2024 11:01: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 1tN8qq-0004aC-Qe
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 11:01:24 +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 16549c61-bb9d-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 12:01:23 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-434b3e32e9dso43447875e9.2
 for ; Mon, 16 Dec 2024 03:01: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
 ffacd0b85a97d-388c801643fsm7838793f8f.41.2024.12.16.03.01.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 03:01: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: 16549c61-bb9d-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734346882; x=1734951682; 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=wmMnM5aGjix9vBrOfafxI9AVJbKWvJGHNFYyDLBTHqM=;
        b=XUt33e2SWw0oLBklDU2AoRr33SoqUGACC/7snEI/fdL7uYfwtNLK7cyDDBB3S/VpKo
         41HbQ5VX0KlXOP5ylVt5Y24ImLh6Dzaa+kyf/3glWi5WeiRR/3p1V4vN/uqZ0BOFV2GH
         Bu3CCm5GFNqn06VVnLR+3jBsV16/UiC6cs40SI9B2E8T93J4NM1wkzcnka9Q5fVXLS8Y
         Le7NzEvZR2H153LFuvn8GNi+CYlTMpXxGGOhDA2HwX8nS0pqWzIu/wvY8yTNvKExT+lZ
         /d4DIHaQF7U5Xnkv7VBxR30t42AH8/87wqBqrB2dXuelVHAzgRp6Czji+bkC3G/ccYDQ
         xaLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734346882; x=1734951682;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=wmMnM5aGjix9vBrOfafxI9AVJbKWvJGHNFYyDLBTHqM=;
        b=tSDqvXkVzxRredtqHe0dCcpsmoVNLl2ef0b6T3osF8BLX7Z/Q6BfYcXyV1TOFXB9zy
         tfb860talELPoLvbittOmlXV+Yn58yhNGLLYBd+6TTtBLkZrW8owNWWo+FJedXsv2vwQ
         giagCdX2j2xC60KYfe7Hs3grrYJtI4VLTPd7fL/rp6lUk7GFwhLOKam/qARIHHDWc57A
         z4MIFLxBjtDv6s5sXK78PQCD2ictOYYwb8B8Ex0hzYFgJsxSInbOIaYbi20yOg86Gblt
         PmH4MvXduMzUE7M/N6buA9B5n+C4uJNNw3ra2X/ZXRZHBcmq7jg4dJEXWI8h1chAqXkv
         p4ag==
X-Gm-Message-State: AOJu0YyILkKhjjZErqPd5FNWgb076xfdIHoTBMfnQBg1KEJjMqhAO7zY
	LvRA3khbz7XvRmcaIGhLP+UdO5k2TIduZSkBmy41SB949CZyDZasd7tFKNAeCA==
X-Gm-Gg: ASbGncu9BLIvu1SMB7QWR080WZxaDZlrdeeP0N2ieGq2zHiw8/yIWEvK8AKQFlp24AI
	tSOdxUxULQ5Rsspu6PJslS4ZsDboInvwCoCNZ2p29q8XvokZ+6MDfUIqZxwr3zhldgk3GU4pbdh
	8bqSsOUq41jTMpm73CpdmdRl0M8dIwBtL+fKO3cIivKDpHfTgUVA+KEZQXyJdCaeeQDpVa/WdoI
	sfDuIOc0rUFmyaN7LJXkMkd/IM/qOiy32gK6Rd96WL1wleN6YpInsvFUE+EqvhZ/6fZh7TqNXKs
	RV4Auy34Bij7qI6DXFnwUxwiPBSAkDbuvNh8juHJnQ==
X-Google-Smtp-Source: AGHT+IFH2cwFZQdo7uDTy5YcWGEB198X3OXW5Yityferi3NMqsjpmwrwEPKrtfo8idQBskWGTneVXg==
X-Received: by 2002:a5d:6c68:0:b0:386:1cd3:8a00 with SMTP id ffacd0b85a97d-3888e0ac341mr10164650f8f.40.1734346882662;
        Mon, 16 Dec 2024 03:01:22 -0800 (PST)
Message-ID: 
Date: Mon, 16 Dec 2024 12:01:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/1] tools/libacpi: clear ASL warning about PCI0
To: Ariel Otilibili-Anieli 
Cc: xen-devel@lists.xenproject.org, Anthony PERARD 
References: <20241215154659.151158-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241215154659.151158-2-Ariel.Otilibili-Anieli@eurecom.fr>
 <5599dc89-0fa4-4255-b4a1-5b81e151d8c7@suse.com>
 <2f7a85-67600280-e411-38ee5c40@258420856>
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: <2f7a85-67600280-e411-38ee5c40@258420856>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.12.2024 11:36, Ariel Otilibili-Anieli wrote:
> On Monday, December 16, 2024 10:53 CET, Jan Beulich  wrote:
> 
>> On 15.12.2024 16:40, Ariel Otilibili wrote:
>>> * iasl complains _HID and _ADR cannot be used at the same time
>>>
>>> ```
>>> /usr/bin/iasl -vs -p tools/firmware/hvmloader/dsdt_anycpu.tmp -tc tools/firmware/hvmloader/dsdt_anycpu.asl 2>&1 | grep -B10 HID
>>> tools/firmware/hvmloader/dsdt_anycpu.asl     40:        Device (PCI0)
>>> Warning  3073 -                                    Multiple types ^  (Device object requires either a _HID or _ADR, but not both)
>>> ```
>>>
>>> * generally _HID devices are enumerated and have their drivers loaded by ACPI
>>> * this is from "ASL 2.0 Introduction and Overview" (page 4).
>>> * removing _ADR, the warning is cleared out.
>>
>> Okay, that's the positive aspect. Yet what about the potential fallout thereof?
>> Can you confirm that there's no risk of regressions with older guest OSes, for
>> example?
> 
> OSes that were released after ACPI 2.0 should work [1]; including WinXP: 
> The 2.0 specs says either _HID or _ADR should be included [2], not both (Section 6.1, page 146).

We must be looking at two different variants of the spec then. My copy says
"device object must contain either an _HID object or an _ADR object, but can
contain both." Also still in 2.0c. I agree that in e.g. 6.5 the wording has
changed. I also agree that the use of "either" doesn't help clarity.

> I chose WinXP because, on another patch, it came up in the discussion [3].

And indeed appropriately so.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 11:02:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 11:02:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857750.1269961 (Exim 4.92)
	(envelope-from )
	id 1tN8rw-000605-Qr; Mon, 16 Dec 2024 11:02:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857750.1269961; Mon, 16 Dec 2024 11:02:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tN8rw-0005zy-OP; Mon, 16 Dec 2024 11:02:32 +0000
Received: by outflank-mailman (input) for mailman id 857750;
 Mon, 16 Dec 2024 11: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 1tN8rw-0005zs-84
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 11:02:32 +0000
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [2a00:1450:4864:20::633])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3e6b7980-bb9d-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 12:02:30 +0100 (CET)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-aa679ad4265so943603766b.0
 for ; Mon, 16 Dec 2024 03:02:30 -0800 (PST)
Received: from localhost ([85.152.134.39]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab96068988sm321921866b.62.2024.12.16.03.02.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 03:02: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: 3e6b7980-bb9d-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1734346950; x=1734951750; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NqTk6LaWx/Mf1jhvP5yaED2ql1cMoofpvb2Ww4U+a4w=;
        b=BChQck5tcfBYzi/vXrIZjQIOCXlHHqzV4aHd3/9z2yTckUr0bS/N8I6Vw1ayu+ruqr
         sN8/GvMV2LYLZDW0fEMfxD6CyYS90qr9BXV4bwepHhvPxhpiOj4c6S4YDLUpWvvxeZkR
         9S0hEWepqY0589ELfGM0ZSr9Pi8sAysi4RESk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734346950; x=1734951750;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=NqTk6LaWx/Mf1jhvP5yaED2ql1cMoofpvb2Ww4U+a4w=;
        b=LYWsCT2r5BntJpKuE2CQST90Fo8R7IjBeQSfMGDtBgOPRDvFDavlB8yhdb+a76z6th
         Ec1RvTCLJnq7Q3fmx8F4WOivbbmd6Y9KRPlC8j9xsHrXWz9mhA1E66jEWfJh1WnNPMaf
         pKdJpVu2oGVtVkZJO524XLUptx5L3BJ6esIOM7rneGs1f/caeKp6RKy5kkQJPJ4TgWcg
         BHL/kLKmz7EC3ntcSRy3TZNaGbanmPZ7kOuag4rkXWDA79a7BxJN2dTW+0xnDhHcz/9S
         5ifeZyC+94TXwuLvTJFME8hZ++osfUdZoicU4Edm1JPpX4hRqPyljudshbCrLXwFMaPV
         9Ikg==
X-Forwarded-Encrypted: i=1; AJvYcCVg3FV2RuPUGlYVqvbxbYwquPH/tbhBgGoVZKED7kO7CE4R6E4qSybPQPGJQSH0MimNSahXbbUV0kw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxc/0Fjjnxrt5VP3vU5TAYb2XZI44ebhQqvox4IkZ4J+fiCjDg4
	Y91kFDWkp/uLVBH/4bs6MluiPd/B/TTrnYZ3XIhPiiHsS3KDTveQAq24vcHJBb0=
X-Gm-Gg: ASbGncse4TtB3TUrrFlhuYyTBMrc3N5kmnXcX/ar7vDkxBbYBy9C31QzchKksMg4pJh
	DWnKCA2KzIpXU33gqxt5stqBAXPSrZakcrw6wpBdbtxacG1iGmbVsN5BxONNjPxvDSBTZP5ByNW
	wN0vG+yNXAw1R2bUuDPEwz7voQKUPv+GhN3J7b7h63OwwIurdm3P8CzADDXCO6g7nlKieO3t2ur
	Hlafkqdh0661q8A2aq/TCExEjGnzwgU2mKoOjD3yH1u+ihXNxZWMGOhRuWUK30=
X-Google-Smtp-Source: AGHT+IGzqRnaOunX1RA6exqOJ43/N2AbM1vjDxzv46YjWFfuwuH8aI6ImKpr8kk8c5xFOx1/30/3vg==
X-Received: by 2002:a17:907:9687:b0:aa6:1afe:b0a5 with SMTP id a640c23a62f3a-aa6c40bca07mr1772407266b.2.1734346949829;
        Mon, 16 Dec 2024 03:02:29 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Mon, 16 Dec 2024 11:02:26 +0000
Message-Id: 
Cc: "Andrew Cooper" ,
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= ,
 
Subject: Re: [PATCH v2 05/13] x86/xstate: Map/unmap xsave area in
 xstate_set_init() and handle_setbv()
From: "Alejandro Vallejo" 
To: "Jan Beulich" 
X-Mailer: aerc 0.18.2
References: <20241105143310.28301-1-alejandro.vallejo@cloud.com>
 <20241105143310.28301-6-alejandro.vallejo@cloud.com>
 
In-Reply-To: 

On Mon Dec 9, 2024 at 4:16 PM GMT, Jan Beulich wrote:
> On 05.11.2024 15:33, Alejandro Vallejo wrote:
> > No functional change.
> >=20
> > Signed-off-by: Alejandro Vallejo 
>
> Acked-by: Jan Beulich 

Thanks (for this one and the others).

> with ...
>
> > --- a/xen/arch/x86/xstate.c
> > +++ b/xen/arch/x86/xstate.c
> > @@ -993,7 +993,13 @@ int handle_xsetbv(u32 index, u64 new_bv)
> > =20
> >          clts();
> >          if ( curr->fpu_dirtied )
> > -            asm ( "stmxcsr %0" : "=3Dm" (curr->arch.xsave_area->fpu_ss=
e.mxcsr) );
> > +        {
> > +            /* has a fastpath for `current`, so there's no actual map =
*/
> > +            struct xsave_struct *xsave_area =3D VCPU_MAP_XSAVE_AREA(cu=
rr);
>
> ... comment style adhered to (capital 'H').
>
> Jan

Ah, yes. All those ought to be capitalized. My bad.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 11:09:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 11:09:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857761.1269972 (Exim 4.92)
	(envelope-from )
	id 1tN8z0-0006eR-IG; Mon, 16 Dec 2024 11:09:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857761.1269972; Mon, 16 Dec 2024 11:09:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tN8z0-0006eK-Fc; Mon, 16 Dec 2024 11:09:50 +0000
Received: by outflank-mailman (input) for mailman id 857761;
 Mon, 16 Dec 2024 11:09: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 1tN8yz-0006eE-9V
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 11:09:49 +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 42def42a-bb9e-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 12:09:47 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-4362bae4d7dso19520095e9.1
 for ; Mon, 16 Dec 2024 03:09: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
 5b1f17b1804b1-4363602cd11sm81395475e9.14.2024.12.16.03.09.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 03:09: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: 42def42a-bb9e-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734347387; x=1734952187; 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=iu+Yz6AeBKGdmKyzFjaCAIEYrTKlB4phgetCKsAvp/U=;
        b=N93RRYgZpk8SAZh/3e1q8ue0ehSqQFqvz1GrChc+5EIoaoCWRiH658m1NFWpYUs0Ji
         z2B3waE9ZeASJtkKk6mVeEQCgzopwWEFc7EtGH8cUrnuyiJq2jBUg/lEkjSwyOzJ8mrf
         hwDOnrRh/5fOUEM6476+TlgWGKFVtLvnrrYFQn+9tHBZ3dpmiEteaBjRZ1JQ/0ydJW33
         i+FdrrQpje3N1WZS0kmBTyv2x29zmwKkVlNY6UEFX9w/yAxxaA7VrPLMMwyFBwon86Tz
         evzxS0xjPlO4gvSdwVSnncAA2ItFpWj5rPq1CkRqVCBZdQrYfv4owPhjeLqyhgIMQDKb
         DrnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734347387; x=1734952187;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=iu+Yz6AeBKGdmKyzFjaCAIEYrTKlB4phgetCKsAvp/U=;
        b=JQzeq3rhmUGDNkf6sxkuurelJP7yvbnjOpUq380X9BPgGlp3DxSgtfpk1cy4JIsxz2
         hqFe3ZoiA0vD9EbJX34YD9yZdvDVTIXZVYoIjlLApMnZKBtL43VbIgSG+EBtqk4qGNLd
         25ZJxEuLA4jQg8dJXGA+sTjsuF6mIrxowRdXTqSh0HLMK4u1xanNhL1WhXaXffqJugqn
         Oi0RaluD/pDj2KuliRF903QFwi1oJvxHITIz6/QZPdi0IzHVdR4925trWD9FuCi2gCuk
         lo/CdBUWXFcBgapC0srWqZ0VPN5NdpmrBcQIQsWaz/a0nY06CpxBRbN3IXxWSIs/IPGS
         4iEg==
X-Forwarded-Encrypted: i=1; AJvYcCXs7DkTpAfsDoY9uRaxPK7KBQOPwphpL2GvhCI3ZLB3EChtWckQzrVqE0+6729y0sf/NaS+7eHI4OA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwGyy0ZzuTIgesdkiN9q8np09J9wFKNiizatoJbIj1DN8ozFssH
	4+da/Tj7v68llXIzGZ95eYlHVM2tM90zvHTAioXyEuLgE5J2GmJirILNAR1zhQ==
X-Gm-Gg: ASbGncskvxAGlB+SfXhjBAz1uULc9ZbznkcthylPJn3veb3buzI2O9bmVqlRjDseAa/
	vU+MPvb4NwVs5AEtITOFxENmcI0BtsvbU3hggR+kP5/JTVU4jL7bRba6P1Z3+b3IhVqWCnCuCoY
	18mp45kHSrYp4Ibv4FCjb77h0ipXh0zaX25TjGYEuciowxlbZYddWMS5jcJ8q8f7oud6mgWe+QP
	MF9uhj76jUzS6G806jJy1n+Hg0CpUbYDmsTtP/zYtcha6Ltgm/Zor9lT7MDKMm4G7fNHbxCqhQ1
	rfkfcWHGef3bCDXfCPKvMRRQwqSWQKN47nUJAjZlKw==
X-Google-Smtp-Source: AGHT+IG2HE+WPCzsN35+35T7xKqfqTosReJP49eIYdEhlTjBMlUabIlrkv5sKcbfoaU+Osi+LcBQGQ==
X-Received: by 2002:a05:600c:5025:b0:436:1c0c:bfb6 with SMTP id 5b1f17b1804b1-4362aab0763mr107185205e9.27.1734347386823;
        Mon, 16 Dec 2024 03:09:46 -0800 (PST)
Message-ID: <943d356f-e1cc-4e42-94c5-fa6d7fc157a3@suse.com>
Date: Mon, 16 Dec 2024 12:09:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/7] xen/riscv: update layout table in config.h
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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 11.12.2024 18:27, Oleksii Kurochko wrote:
> Make all upper bounds (end addresses) for areas inclusive to align
> with the corresponding definitions.
> 
> Signed-off-by: Oleksii Kurochko 

I expected this would be straightforward to ack, but ...

> --- a/xen/arch/riscv/include/asm/config.h
> +++ b/xen/arch/riscv/include/asm/config.h
> @@ -41,17 +41,17 @@
>   * Start addr          | End addr         | Slot       | area description
>   * ============================================================================
>   *                   .....                 L2 511          Unused
> - *  0xffffffffc0a00000  0xffffffffc0c00000 L2 511          Fixmap
> + *  0xffffffffc0a00000  0xffffffffc0bfffff L2 511          Fixmap
>   *                   ..... ( 2 MB gap )
> - *  0xffffffffc0400000  0xffffffffc0800000 L2 511          FDT
> + *  0xffffffffc0400000  0xffffffffc07fffff L2 511          FDT
>   *                   ..... ( 2 MB gap )
> - *  0xffffffffc0000000  0xffffffffc0200000 L2 511          Xen
> + *  0xffffffffc0000000  0xffffffffc01fffff L2 511          Xen
>   *                   .....                 L2 510          Unused
> - *  0x3200000000        0x7f40000000       L2 200-509      Direct map
> + *  0x3200000000        0x7f7fffffff       L2 200-509      Direct map

... this isn't just an adjustment by -1. If the old table entry was wrong,
the description wants to say so. Else an adjustment to the number is needed
here.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 11:24:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 11:24:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857773.1269982 (Exim 4.92)
	(envelope-from )
	id 1tN9Cl-0001Yh-ON; Mon, 16 Dec 2024 11:24:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857773.1269982; Mon, 16 Dec 2024 11:24:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tN9Cl-0001Ya-LT; Mon, 16 Dec 2024 11:24:03 +0000
Received: by outflank-mailman (input) for mailman id 857773;
 Mon, 16 Dec 2024 11:24: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 1tN9Cj-0001YU-U1
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 11:24:01 +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 3f523e6b-bba0-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 12:24:00 +0100 (CET)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-4361fe642ddso42223575e9.2
 for ; Mon, 16 Dec 2024 03:24: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-4362557c57dsm136387485e9.12.2024.12.16.03.23.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 03:23: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: 3f523e6b-bba0-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734348240; x=1734953040; 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=yxfdzce9dBvZit3hIoPW5hX1l7Tj1gSZWKooZXG8eMM=;
        b=bl3lBhZMSQGhAyCnSNWF2SJM8icE0tpEudeumI19O4GLQvtiEasDg5bZOolsBNxBtm
         kIgamhqRBqe2+ExKLYHa/xAMq46KjewNNUvE9PvNamTDIENavVuyUtWDw8DbJRrVF8Sw
         5LAge/FzDiimCS4MHiKpkEG3j3T6Nn0HB7L2FS1JUd94kzyYzViVPehYzzzxwA1EXP7v
         wsEY50eDCfvN+qPCmPvtHIWCx9f/brVqUqOdA2l+5ArV2gYJ8skJJ7Go812uqYFS8kG/
         yq83kj4DgpKiue0lGJ28HS901yMKpbNPn1W/wI36PHTDSxSrpTnzDNuwTjY4OP1QsLsH
         4UXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734348240; x=1734953040;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=yxfdzce9dBvZit3hIoPW5hX1l7Tj1gSZWKooZXG8eMM=;
        b=l2+FbX3W0r8J7Aqg/4nJEA+5p7JRMnM15SPlqHJqzxM1vS1t0G8xlz36D9/0qowGKT
         rYkPncm02ELQwdo4OyMWaJuHnZtDRJQK9HS+tF/k/ec41O0S6gHqhdSQAdlSDLPc6G6L
         r1O+Wh/QL0o7G6eev3u1BOTl4eEB8P1oejK06vrrO1/Qgjipz+5Z64YlOOH02FJnJZTW
         OGBdfTXacUVgDfYbpXGsbCLzMKwJccD7oE862Xu265aoEbDc2STmKhVaeZqsoFHu0wVi
         azxE9uZi6+EaYq+nbRtDhbluI2rN/Ma500I3AaA8hrbnk6eApmRWDS2sSY6n+8OZU3Z9
         RBJQ==
X-Forwarded-Encrypted: i=1; AJvYcCXyJgTcJhkmh5Ro8qu9L+sQnDerzSwX2pKlqDOxoMcn7x0KIHV/Dbhhq9BPpXkF0589B16PlSFaxaY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywc0lmsHUy2WDBnGky7Vb7I1ZyGGk8aDISwR+l+JwPi9dYUbwBb
	U6BaW4I0AV5eEahGnqu4CClOEKkrrTfv5IuA31lg46h6NHAYSk2ciiXpd/ntOQ==
X-Gm-Gg: ASbGncv7tAWcFZBoo00AOwhVgqWMxYF8nVzRK86F8K2gwemHw8vHZVN28LpfToyb5XL
	xNCePp0dTICQk2iutmA+rI5XBQAdjrp4pvv24uRbT8kaNEwFIsddVMfo90iVMfJc6Dsl5Sp9Fj2
	qN/4Jv4EKKw5brCCXGsnYUHc22wOfLNbjAJ/sRwggfHHoF3BTe4UvZNq1Qs6zln0Q+fiepi81kz
	ogKQdiMc1NMh5/k9GOzyPq96D0yuDz0fLzxOl/F0ge0xrxUJZkS/fAyhlT5K/Mdz1D9xniIbf2A
	6iY8iYrUy20+DdDQCgu5TwRnzRnGUzDDSv5WcoW+cw==
X-Google-Smtp-Source: AGHT+IEaadTZpVH/9bJh6C7XOcdqNoUr0UWYFKJGSz+NdL8CiRtWmTOStyyaJtqc1kmAkVd/v7kl+A==
X-Received: by 2002:a05:600c:1f0b:b0:434:a94f:f8a9 with SMTP id 5b1f17b1804b1-4362aaa495emr90710175e9.28.1734348239901;
        Mon, 16 Dec 2024 03:23:59 -0800 (PST)
Message-ID: <0f75fcd2-6c5d-4be6-9fc9-3c7b6c10ae51@suse.com>
Date: Mon, 16 Dec 2024 12:24:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] vpci: Add resizable bar support
To: Jiqian Chen 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini , Huang Rui ,
 xen-devel@lists.xenproject.org
References: <20241213054232.2638640-1-Jiqian.Chen@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: <20241213054232.2638640-1-Jiqian.Chen@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.12.2024 06:42, Jiqian Chen wrote:
> --- /dev/null
> +++ b/xen/drivers/vpci/rebar.c
> @@ -0,0 +1,130 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2024 Advanced Micro Devices, Inc. All Rights Reserved.
> + *
> + * Author: Jiqian Chen 
> + */
> +
> +#include 
> +#include 
> +
> +static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
> +                                      unsigned int reg,
> +                                      uint32_t val,
> +                                      void *data)
> +{
> +    uint64_t size;
> +    struct vpci_bar *bar = data;
> +
> +    size = PCI_REBAR_CTRL_SIZE(val);
> +    if ( bar->enabled )
> +    {
> +        if ( size == bar->size )
> +            return;
> +
> +        /*
> +        * Refuse to resize a BAR while memory decoding is enabled, as
> +        * otherwise the size of the mapped region in the p2m would become
> +        * stale with the newly set BAR size, and the position of the BAR
> +        * would be reset to undefined.  Note the PCIe specification also
> +        * forbids resizing a BAR with memory decoding enabled.
> +        */
> +        gprintk(XENLOG_ERR,
> +                "%pp: refuse to resize BAR with memory decoding enabled\n",
> +                &pdev->sbdf);
> +        return;
> +    }
> +
> +    if ( !((size >> PCI_REBAR_SIZE_BIAS) &
> +           MASK_EXTR(pci_conf_read32(pdev->sbdf,
> +                                     reg - PCI_REBAR_CTRL + PCI_REBAR_CAP),
> +                                     PCI_REBAR_CAP_SIZES)) )
> +        gprintk(XENLOG_WARNING,
> +                "%pp: new size %#lx is not supported by hardware\n",
> +                &pdev->sbdf, size);

This only covers the 1Mb ... 128Tb range. What about the 256Tb ... 8Eb one?

> +static int cf_check init_rebar(struct pci_dev *pdev)
> +{
> +    uint32_t ctrl;
> +    unsigned int rebar_offset, nbars;
> +
> +    rebar_offset = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_REBAR);
> +
> +    if ( !rebar_offset )
> +        return 0;
> +
> +    if ( !is_hardware_domain(pdev->domain) )
> +    {
> +        printk("ReBar is not supported for domUs\n");
> +        return -EOPNOTSUPP;
> +    }
> +
> +    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL);
> +    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
> +
> +    for ( unsigned int i = 0; i < nbars; i++, rebar_offset += PCI_REBAR_CTRL )

PCI_REBAR_CTRL is an offset; it can't be used to bump rebar_offset here.
That'll need a separate constant, even if both evaluate to 8.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 11:31:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 11:31:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857787.1269991 (Exim 4.92)
	(envelope-from )
	id 1tN9K0-0003Kc-IM; Mon, 16 Dec 2024 11:31:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857787.1269991; Mon, 16 Dec 2024 11:31:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tN9K0-0003KV-Ft; Mon, 16 Dec 2024 11:31:32 +0000
Received: by outflank-mailman (input) for mailman id 857787;
 Mon, 16 Dec 2024 11:31: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 1tN9Jy-0003Ib-UO
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 11:31:30 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4adc3f82-bba1-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 12:31:29 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 16 Dec 2024 12:31:28 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4adc3f82-bba1-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734348689; x=1765884689;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=jpjwLZOUhm3SnCDbRSSKNMJd+vdvvzdaNgDO2bNHUQ8=;
  b=pecQKPOE01dFqO3ZjelFXlCaTo69c5smV0r+5HngVhzBENcupyzZGbA9
   bPaMOliNZpWCX+MCp7NW05v2AsndolK9fmSLn9opH4aiorTVtGPvq9yOC
   daxpwWCfgNSl0Yf8dJjt0DJGI3/IjI1Ukc/19Ei51vwpZLRFBSCXlVimn
   g=;
X-CSE-ConnectionGUID: MeeKheEbToiZWXZSm/sv1g==
X-CSE-MsgGUID: ejIzTYT5QxuK3p/3K59WuQ==
X-IronPort-AV: E=Sophos;i="6.12,238,1728943200"; 
   d="scan'208";a="28195530"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"
X-Forward: 149.5.228.1
References: <20241215154659.151158-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241215154659.151158-2-Ariel.Otilibili-Anieli@eurecom.fr>
 <5599dc89-0fa4-4255-b4a1-5b81e151d8c7@suse.com>
 <2f7a85-67600280-e411-38ee5c40@258420856> 
Date: Mon, 16 Dec 2024 12:31:28 +0100
Cc: xen-devel@lists.xenproject.org, "Anthony PERARD" 
To: "Jan Beulich" 
MIME-Version: 1.0
Message-ID: <2f7a86-67600f80-8b81-26131fc0@216081513>
Subject: =?utf-8?q?Re=3A?= [PATCH 1/1] =?utf-8?q?tools/libacpi=3A?= clear ASL 
 warning about PCI0
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 2770

On Monday, December 16, 2024 12:01 CET, Jan Beulich =
 wrote:

> On 16.12.2024 11:36, Ariel Otilibili-Anieli wrote:
> > On Monday, December 16, 2024 10:53 CET, Jan Beulich  wrote:
> >=20
> >> On 15.12.2024 16:40, Ariel Otilibili wrote:
> >>> * iasl complains =5FHID and =5FADR cannot be used at the same tim=
e
> >>>
> >>> ```
> >>> /usr/bin/iasl -vs -p tools/firmware/hvmloader/dsdt=5Fanycpu.tmp -=
tc tools/firmware/hvmloader/dsdt=5Fanycpu.asl 2>&1 | grep -B10 HID
> >>> tools/firmware/hvmloader/dsdt=5Fanycpu.asl     40:        Device =
(PCI0)
> >>> Warning  3073 -                                    Multiple types=
 ^  (Device object requires either a =5FHID or =5FADR, but not both)
> >>> ```
> >>>
> >>> * generally =5FHID devices are enumerated and have their drivers =
loaded by ACPI
> >>> * this is from "ASL 2.0 Introduction and Overview" (page 4).
> >>> * removing =5FADR, the warning is cleared out.
> >>
> >> Okay, that's the positive aspect. Yet what about the potential fal=
lout thereof?
> >> Can you confirm that there's no risk of regressions with older gue=
st OSes, for
> >> example?
> >=20
> > OSes that were released after ACPI 2.0 should work [1]; including W=
inXP:=20
> > The 2.0 specs says either =5FHID or =5FADR should be included [2], =
not both (Section 6.1, page 146).
>=20
> We must be looking at two different variants of the spec then. My cop=
y says
> "device object must contain either an =5FHID object or an =5FADR obje=
ct, but can
> contain both." Also still in 2.0c. I agree that in e.g. 6.5 the wordi=
ng has
> changed. I also agree that the use of "either" doesn't help clarity.

I looked up 2.0 (July 2000); indeed, it said "can contain both". My bad=
.
>=20
> > I chose WinXP because, on another patch, it came up in the discussi=
on [3].

The change should work down to WinXP: the name =5FHID is kept.

```
$ git grep -B2 -A2 -n PNP0A03
tools/libacpi/dsdt.asl-40-       Device (PCI0)
tools/libacpi/dsdt.asl-41-       {
tools/libacpi/dsdt.asl:42:           Name (=5FHID, EisaId ("PNP0A03"))
tools/libacpi/dsdt.asl-43-           Name (=5FUID, 0x00)
tools/libacpi/dsdt.asl-44-           Name (=5FADR, 0x00)
```

Its EISA ID is "PNP0A03"; the namespace is reserved for Microsoft. Micr=
osoft identifies "PNP0A03" as PCI devices [1].

```
$ curl -k -s https://download.microsoft.com/download/1/6/1/161ba512-40e=
2-4cc9-843a-923143f3456c/devids.txt | grep PNP0A03
PNP0A03         PCI Bus
```
Linux displays PCI devices with =5FHID and no =5FHID [2].

[1] https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-84=
3a-923143f3456c/devids.txt
[2] https://www.infradead.org/~mchehab/kernel=5Fdocs/firmware-guide/acp=
i/namespace.html
>=20
> And indeed appropriately so.
>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 11:34:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 11:34:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857797.1270002 (Exim 4.92)
	(envelope-from )
	id 1tN9Mm-00047U-W8; Mon, 16 Dec 2024 11:34:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857797.1270002; Mon, 16 Dec 2024 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 1tN9Mm-00047N-Sy; Mon, 16 Dec 2024 11:34:24 +0000
Received: by outflank-mailman (input) for mailman id 857797;
 Mon, 16 Dec 2024 11:34: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 1tN9Mm-00047H-7z
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 11:34:24 +0000
Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com
 [2a00:1450:4864:20::344])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b1a785f9-bba1-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 12:34:22 +0100 (CET)
Received: by mail-wm1-x344.google.com with SMTP id
 5b1f17b1804b1-436202dd730so28104365e9.2
 for ; Mon, 16 Dec 2024 03:34:22 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c801a8a5sm7905787f8f.48.2024.12.16.03.34.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 03:34:20 -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: b1a785f9-bba1-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734348861; x=1734953661; 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=UqayyQBfpUPr/Pj7P6Vd6jPsK74AdpD5wXNC7i5RUjE=;
        b=UIl+Hteck/cVwx4HLiEqA2WlvggXvUoVezQZOEr0AVO+m+0VnLROG142lknZ8avLTD
         N0faOBcAbs4EE8ZfNu9yDoNuLSAhz2caTFxrXV2tH8ZyXqC49Pf91xzkfiPy6UpKe2OJ
         QxTNkIUZ/G4SZl50oytDi6Sioaooa4rWtZ84Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734348861; x=1734953661;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=UqayyQBfpUPr/Pj7P6Vd6jPsK74AdpD5wXNC7i5RUjE=;
        b=COTuorajyMkCY7c4DhHgXx6TcJ8gZ3wcHtNp1EcZrG2D7cHpCjs2FHaLkuWU0d+3La
         CpD+f+g92XLtz8MD5gJgQOh32Zaiaxgc18o364BKHfgrDMQXvNolMuJmCR0fbySkAKuD
         YsEoAcghAeK1SsvtFLOO8dy6r8sh0YMyHdw8dEDZqn9uWe1uGEUozEETkOgPTz4iEziJ
         6gmGXl4W7SpmR6mOPwC4OCu5cTdmSHwe2kYYnk2AQN9wMwXj149ugUQRB2Y1WyY7B6qe
         UP2xrU4MqQNwntrjAucoNmzSCiJDqI2igrwhuKDMru7bLnGwtSaQWyswGWpaj3FTdd1e
         shjg==
X-Forwarded-Encrypted: i=1; AJvYcCXaz98x6HrGu1HSscaGdyIOYSoXuUK4nqVW2JzIWS9H7sqN6PyPXJdU6KgkjfIj7QYRGcv4vbc7oj0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwR01yCyn5VUoVSfuEwRCELedHQxnLCcuSaOoLY2jJK/Dte1aJG
	pSRxLGXRfsHuHTvNE4RC+jwuVG0j3NgvR2RxFL3DcaSN8/uVpg3O4bJdYxehjYk=
X-Gm-Gg: ASbGncvu9IYnRYspHMpRjA+xfBxILGN6jg/c8RO+ZOzsVb/8DHYuo0adrFc0AOqfihN
	0F+ZTsm0OmTerfOH6OZCr1o4lceBwpYCMCUyW1XMQGrkA9sOs9L/8S6fvcJCWuRJQ92+Ak1SIwE
	/6uXjGQqXgPAJWv2PO8vVZwhAE0mqe4WC8dUuCtcoW8bYNOOS1GGxslgcTXPiDg3m7rTIFYPdtV
	vek3t/cJq1eWXSiAtO2PR1VWOQPVKU4NGSEDCS3gUj/EsVGnJdR0ElY2celFS3iWa6sGFmctbGx
	3QVgQHH5X5ieUkULVTp0
X-Google-Smtp-Source: AGHT+IHfBysp6ty+ixBfM3lu7atblP7Wy3Ma/a4GMiza1zKVjeIsFTWmc6RsNIE7jUQWvjKHLQ9wYw==
X-Received: by 2002:a05:600c:5248:b0:434:f3d8:62d0 with SMTP id 5b1f17b1804b1-4362aa34e58mr123821265e9.3.1734348861106;
        Mon, 16 Dec 2024 03:34:21 -0800 (PST)
Message-ID: <49497f8c-a2e4-49a1-aac0-96d704834f0f@citrix.com>
Date: Mon, 16 Dec 2024 11:34:20 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/1] tools, xen/scripts: clear out Python syntax warnings
To: Ariel Otilibili ,
 xen-devel@lists.xenproject.org
Cc: Jan Beulich , nthony PERARD
 , Luca Fancellu 
References: <20241214161350.70515-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241214161350.70515-3-Ariel.Otilibili-Anieli@eurecom.fr>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20241214161350.70515-3-Ariel.Otilibili-Anieli@eurecom.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 14/12/2024 4:09 pm, Ariel Otilibili wrote:
> * since 3.12 invalid escape sequences generate SyntaxWarning
> * in the future, these invalid sequences will generate SyntaxError
> * therefore changed syntax to raw string notation.
>
> Link: https://docs.python.org/3/whatsnew/3.12.html#other-language-changes
> Fixes: e45e8f69047 ("bitkeeper revision 1.803 (4056f51d2UjBnn9uwzC9Vu3LspnUCg)")
> Fixes: d8f3a67bf98 ("pygrub: further improve grub2 support")
> Fixes: dd03048708a ("xen/pygrub: grub2/grub.cfg from RHEL 7 has new commands in menuentry")
> Fixes: d1b93ea2615 ("tools/pygrub: Make pygrub understand default entry in string format")
> Fixes: 622e368758b ("Add ZFS libfsimage support patch")
> Fixes: 02b26c02c7c ("xen/scripts: add cppcheck tool to the xen-analysis.py script")
> Fixes: 56c0063f4e7 ("xen/misra: xen-analysis.py: Improve the cppcheck version check")
>
> Cc: Anthony PERARD 
> Cc: Luca Fancellu 
> Signed-off-by: Ariel Otilibili 
> ---
>  tools/misc/xensymoops                         | 4 ++--
>  tools/pygrub/src/GrubConf.py                  | 4 ++--
>  tools/pygrub/src/pygrub                       | 6 +++---
>  xen/scripts/xen_analysis/cppcheck_analysis.py | 4 ++--
>  4 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/tools/misc/xensymoops b/tools/misc/xensymoops
> index 835d187e90..bec75cae93 100755
> --- a/tools/misc/xensymoops
> +++ b/tools/misc/xensymoops
> @@ -17,7 +17,7 @@ def read_oops():
>      stack_addrs is a dictionary mapping potential code addresses in the stack
>        to their order in the stack trace.
>      """
> -    stackaddr_ptn = "\[([a-z,0-9]*)\]"
> +    stackaddr_ptn = r"\[([a-z,0-9]*)\]"
>      stackaddr_re  = re.compile(stackaddr_ptn)
>  
>      eip_ptn = ".*EIP:.*<([a-z,0-9]*)>.*"

Oh wow.  I've not come across this script before, and it's not
referenced in the build system.

Also, it's hard-coded to 32bit Xen which was deleted in Xen 4.13 more
than a decade ago, and there are other errors in the regexes such as
including a comma in stackaddr_ptn

Worse however, it escaped the Py2->3 conversion and is still using raw
print statements.

I'll submit a patch deleting it entirely.

> diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/GrubConf.py
> index 580c9628ca..7cd2bc9aeb 100644
> --- a/tools/pygrub/src/GrubConf.py
> +++ b/tools/pygrub/src/GrubConf.py
> @@ -320,7 +320,7 @@ class GrubConfigFile(_GrubConfigFile):
>  def grub2_handle_set(arg):
>      (com,arg) = grub_split(arg,2)
>      com="set:" + com
> -    m = re.match("([\"\'])(.*)\\1", arg)
> +    m = re.match(r"([\"\'])(.*)\\1", arg)

Doesn't this \\1 want to turn into just \1 now it's a raw string?

> diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
> index 9d51f96070..58b088d285 100755
> --- a/tools/pygrub/src/pygrub
> +++ b/tools/pygrub/src/pygrub
> @@ -1104,7 +1104,7 @@ if __name__ == "__main__":
>      if chosencfg["args"]:
>          zfsinfo = xenfsimage.getbootstring(fs)
>          if zfsinfo is not None:
> -            e = re.compile("zfs-bootfs=[\w\-\.\:@/]+" )
> +            e = re.compile(r"zfs-bootfs=[\w\-\.\:@/]+" )

Related, this string looks dodgy.  The \- is correct (I think, to not
have it interpreted as a range), but I'm pretty sure a literal . and :
don't need escaping inside a [], and the result here would be for a
literal \ to be included.

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 11:35:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 11:35:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857805.1270011 (Exim 4.92)
	(envelope-from )
	id 1tN9NW-0004cO-6z; Mon, 16 Dec 2024 11:35:10 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857805.1270011; Mon, 16 Dec 2024 11:35:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tN9NW-0004cH-4P; Mon, 16 Dec 2024 11:35:10 +0000
Received: by outflank-mailman (input) for mailman id 857805;
 Mon, 16 Dec 2024 11:35: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 1tN9NV-0004Oq-Cn
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 11:35:09 +0000
Received: from fout-a7-smtp.messagingengine.com
 (fout-a7-smtp.messagingengine.com [103.168.172.150])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cc614700-bba1-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 12:35:07 +0100 (CET)
Received: from phl-compute-11.internal (phl-compute-11.phl.internal
 [10.202.2.51])
 by mailfout.phl.internal (Postfix) with ESMTP id D19A61383E9E;
 Mon, 16 Dec 2024 06:35:05 -0500 (EST)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-11.internal (MEProxy); Mon, 16 Dec 2024 06:35:05 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 16 Dec 2024 06:35: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: cc614700-bba1-11ef-a0d6-8be0dac302b0
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=1734348905;
	 x=1734435305; bh=DKeD6oR0WFoQA/n3ucu51GQJu3RG4ED6fJOAjXzrlKY=; b=
	MAy3QnFrdOopvIKLpL1jtBC0hMBHPd3wToHcBT9v92VcQB/di8kAg0v8d+XsR3TO
	1FEHaaCJYSeMf2rLPxlI6dhAU5ylxYMVvf/+h/4LoSdMuo9FfzlJUIVgvSfVJeiR
	e+k9iEcLYBMlCMAdClz1IRiM43dp0rA/VPg3pm9yTV5vAUgN8ZzklNvUW5KUTXpD
	/Q+7D8/md6MC4weDSrxOid/+0alFzuaGTAMtdV/1ubLeNmVsCBKizjTZZbqa7PLQ
	OPfxsoP78dTjvCEthCWYbUQKiBSksEwvEHpKqRNSlStUpbojMv8bLRens1rTfYbH
	wAInis2NfBM5SicbyakYFw==
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=
	1734348905; x=1734435305; bh=DKeD6oR0WFoQA/n3ucu51GQJu3RG4ED6fJO
	AjXzrlKY=; b=PmxH1gtsXGCovOlrK9WA0jRBb+JMK6vzAIuOYUaIp9opXJ4k1lZ
	OQHDh71sClW75PnwXnpwO+OXvUGvBqewhhuU3mf4NlnC4UYu0hM7bbGqmvhLLbgn
	FS7V2fSrO/RKe0dn0KL8DX0yvqLSWlHm4Oky8LAWIibJl/ogbBJLZy3J2zasMbXg
	qU2huHmsv1CSVZBmc7XZfaxRrdfVqiRGwS0qufQSDExc4Ld3A0QlR5zr4k16uSX1
	oPHTSbEznHmif7PTZjrKKKZTNBYreAD2Wx97uCITzLnhyJfPpgCdQT7Nxvi5ikiN
	o3JMVxfTOjUAIMY9e6Sq8l9j0IReaZAleLg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrleefgddvlecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr
    tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth
    hsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecu
    hfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrg
    hrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffr
    rghtthgvrhhnpefgudelteefvefhfeehieetleeihfejhfeludevteetkeevtedtvdegue
    etfeejudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm
    pehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsg
    gprhgtphhtthhopeejpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehrohhgvghr
    rdhprghusegtihhtrhhigidrtghomhdprhgtphhtthhopeholhgvkhhsihhirdhkuhhroh
    gthhhkohesghhmrghilhdrtghomhdprhgtphhtthhopehjghhrohhsshesshhushgvrdgt
    ohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdprhgtphhtthhope
    grnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthhtoheprghn
    thhhohhnhidrphgvrhgrrhgusehvrghtvghsrdhtvggthhdprhgtphhtthhopeigvghnqd
    guvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Mon, 16 Dec 2024 12:35:01 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau =?utf-8?B?TW9ubsOp?= 
Cc: Oleksii Kurochko ,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] tools/xg: increase LZMA_BLOCK_SIZE for uncompressing the
 kernel
Message-ID: 
References: <20241008213225.728922-1-marmarek@invisiblethingslab.com>
 <226bc9b3-6741-4cb6-917b-1164e340a19d@suse.com>
 
 <00ac0665-e4ff-4a56-8537-e81573710c3c@suse.com>
 
 
 <99089b03-e9f0-4fe8-94b2-11e75f9e5243@suse.com>
 
 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="FyyhMwKxTCf/oLKa"
Content-Disposition: inline
In-Reply-To: 


--FyyhMwKxTCf/oLKa
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Mon, 16 Dec 2024 12:35:01 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Roger Pau =?utf-8?B?TW9ubsOp?= 
Cc: Oleksii Kurochko ,
	=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= ,
	Jan Beulich ,
	Andrew Cooper ,
	Anthony PERARD ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] tools/xg: increase LZMA_BLOCK_SIZE for uncompressing the
 kernel

On Mon, Dec 16, 2024 at 09:35:37AM +0100, Roger Pau Monn=C3=A9 wrote:
> Adding Oleksii, as this IMO wants to be a blocker for 4.20.
>=20
> On Wed, Oct 09, 2024 at 03:03:28PM +0200, Marek Marczykowski-G=C3=B3recki=
 wrote:
> > On Wed, Oct 09, 2024 at 01:38:32PM +0200, J=C3=BCrgen Gro=C3=9F wrote:
> > > On 09.10.24 13:15, Jan Beulich wrote:
> > > > On 09.10.2024 13:08, Andrew Cooper wrote:
> > > > > On 09/10/2024 11:26 am, Juergen Gross wrote:
> > > > > > On 09.10.24 12:19, Jan Beulich wrote:
> > > > > > > On 09.10.2024 11:52, Marek Marczykowski-G=C3=B3recki wrote:
> > > > > > > > On Wed, Oct 09, 2024 at 09:19:57AM +0200, Jan Beulich wrote:
> > > > > > > > > On 08.10.2024 23:32, Marek Marczykowski-G=C3=B3recki wrot=
e:
> > > > > > > > > > --- a/tools/libs/guest/xg_dom_bzimageloader.c
> > > > > > > > > > +++ b/tools/libs/guest/xg_dom_bzimageloader.c
> > > > > > > > > > @@ -272,8 +272,7 @@ static int _xc_try_lzma_decode(
> > > > > > > > > >  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return retval;
> > > > > > > > > >  =C2=A0 }
> > > > > > > > > >  =C2=A0 -/* 128 Mb is the minimum size (half-way) docum=
ented to work for
> > > > > > > > > > all inputs. */
> > > > > > > > > > -#define LZMA_BLOCK_SIZE (128*1024*1024)
> > > > > > > > > > +#define LZMA_BLOCK_SIZE (256*1024*1024)
> > > > > > > > >=20
> > > > > > > > > That's as arbitrary as before, now just not even with a c=
omment at
> > > > > > > > > least
> > > > > > > > > hinting at it being arbitrary. Quoting from one of the LZ=
MA API
> > > > > > > > > headers:
> > > > > > > > >=20
> > > > > > > > >  =C2=A0=C2=A0=C2=A0=C2=A0 * Decoder already supports dict=
ionaries up to 4 GiB - 1 B (i.e.
> > > > > > > > >  =C2=A0=C2=A0=C2=A0=C2=A0 * UINT32_MAX), so increasing th=
e maximum dictionary size of the
> > > > > > > > >  =C2=A0=C2=A0=C2=A0=C2=A0 * encoder won't cause problems =
for old decoders.
> > > > > > > > >=20
> > > > > > > > > IOW - what if the Linux folks decided to increase the dic=
tionary size
> > > > > > > > > further? I therefore wonder whether we don't need to make=
 this more
> > > > > > > > > dynamic, perhaps by peeking into the header to obtain the=
 dictionary
> > > > > > > > > size used. The one thing I'm not sure about is whether th=
ere can't be
> > > > > > > > > multiple such headers throughout the file, and hence (in =
principle)
> > > > > > > > > differing dictionary sizes.
> > > > > > > >=20
> > > > > > > > What is the purpose of this block size limit? From the error
> > > > > > > > message, it
> > > > > > > > seems to be avoiding excessive memory usage during decompre=
ssion (which
> > > > > > > > could be DoS via OOM). If that's the case, then taking the =
limit from
> > > > > > > > the kernel binary itself will miss this point (especially i=
n case of
> > > > > > > > pygrub or similar, but there may be other cases of not-full=
y-trusted
> > > > > > > > kernel binaries).
> > > > > > >=20
> > > > > > > Indeed. The question then simply is: Where do we want to draw=
 the line
> > > > > > > between what we permit and what we reject?
> > > > > >=20
> > > > > > IMHO the most natural solution would be to use guest memory for=
 this
> > > > > > purpose.
> > > > > > OTOH this probably would require a significant rework of libxen=
guest.
> > > > >=20
> > > > > That was XSA-25.=C2=A0 There are toolstack-provided limits on ker=
nel&initrd
> > > > > sizes.
> > > >=20
> > > > Which probably can't be directly applied to dictionary size used du=
ring
> > > > (de)compression.
> > >=20
> > > My point still stands: using GUEST memory for all the decompression w=
ork
> > > would avoid all these problems. If the guest memory isn't sufficient,=
 a
> > > decompression by e.g. grub wouldn't work either.
> >=20
> > Doing that would probably require mapping guest memory to dom0 for this
> > purpose. And probably quite severe changes to the decompressing code
> > (liblzma?) to actually use that memory instead of standard heap. I don't
> > think it's a feasible short term fix.
> > Theoretically this could be made configurable (if nothing else, then via
> > an env variable or even build-time setting...), but honestly it feels
> > like an overkill.
>=20
> As a compromise that could likely be done in time for the release,
> would it be feasible to fetch the dictionary size from the header and
> cap it at certain boundary using max(
, )?

Isn't the current constant more or less that already? It's named
LZMA_BLOCK_SIZE, but the lzma_stream_decoder() argument it's used for is
"memlimit", described as "Memory usage limit as bytes".

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

--FyyhMwKxTCf/oLKa
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmdgEGYACgkQ24/THMrX
1ywUEAf8DnKhBMfk3WH01oo2e1rftTx1GdeB0Wo47vrVDpebEai9c1ZgND+qX5Kp
LEuM7wfZpYldv5ERezhprsP4mkHOJ/PLv5u5TuZl62j3mhEbJFXHIld9rIRckLrA
WED4YqwuSLygEE3jvMxNMyb+nra/FNEoudY3FCbi1wl4vOQpBei+Rmf15rbwC48N
tzufxFEC1idIdabUnSroBHuVDfTTpnLAzBqj4if2cD5Zu0HdHvh3PXqz9Bma2elw
efJZ9daR1zZuxulRAP8OSRaNVeo+H1Kpskgw59UUFnVDx6rdYr8XIhY0E03Ytd6u
WEMKWVlLfw+wVa3RPUNoi2mDpgevOg==
=xzL6
-----END PGP SIGNATURE-----

--FyyhMwKxTCf/oLKa--


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 11:36:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 11:36:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857813.1270022 (Exim 4.92)
	(envelope-from )
	id 1tN9Ow-0005C3-Hw; Mon, 16 Dec 2024 11:36:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857813.1270022; Mon, 16 Dec 2024 11:36:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tN9Ow-0005Bw-E0; Mon, 16 Dec 2024 11:36:38 +0000
Received: by outflank-mailman (input) for mailman id 857813;
 Mon, 16 Dec 2024 11:36: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 1tN9Ov-0005Bo-5j
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 11:36:37 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 013e9df9-bba2-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 12:36:35 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-aa6a92f863cso801722666b.1
 for ; Mon, 16 Dec 2024 03:36:35 -0800 (PST)
Received: from localhost ([85.152.134.39]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab9635996asm325356666b.102.2024.12.16.03.36.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 03:36: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: 013e9df9-bba2-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1734348995; x=1734953795; darn=lists.xenproject.org;
        h=in-reply-to:references:from:subject:cc:to:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1pSNdM0wXEGoI3xI6ufGMlDOE27JrPVoHDz11IhOcnI=;
        b=EFFhoqMPff7Qb3zHmJxpdVqYeGzwO1kn7WIwoTi0mEp05eUItdUgB4LDTpibf9woSk
         VUSaM4/eVnbb/AVCUFgIjoaWb+wVphnqPvsF97sJddvwpWK42F0JUokYyW/H3Qq7jMho
         kui4Ad49G2m6zwDrB0KxACwjOZvGdo1TsmrWw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734348995; x=1734953795;
        h=in-reply-to:references:from:subject:cc:to:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=1pSNdM0wXEGoI3xI6ufGMlDOE27JrPVoHDz11IhOcnI=;
        b=S7jfFifQLT4wmu1U8ti3qtpnoaHqgXg0F0iWRNktC5o8FwPQSu6oK3mLFxu+YvQm3v
         hIjTlxNbbTB78eu2EpCYQcefTXDPn++wCiGF7+1kEer/0GnrZrd91963a+PJgpL7VtT8
         3xX7IxfIi/mbIJ7oY0ILdNasve7dpGarjshfI9xsJSjNJUkMU+iT0vAaGPHgXYFnI62x
         PejzbSNi6Cq94kYKevvx0V9JzoOckEYRRxl9YipEfPvPTvD7n8aN+OxdmpwrEb9bCafr
         rBx411ud4i0IXBDd2h/BGfO0pH4MlXSA5KQFu0iRlIRaBYKTaJsj9v/LnXGtOJGOoiAj
         4lGg==
X-Forwarded-Encrypted: i=1; AJvYcCXRuAd0Hpw7O/vo/qGl7Wrcn/5Gebk2yD+yoIpV0imrhyO8wmD7/LL0MuzdAk1ZmkvE67FxgAvuAE8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzdSG6ds7o4UK5KoPRvlSzZ7FLuGkgIIf57HTehgvAOr9QZ4/wd
	XhhkP2Mukn9J/l1PfPZ/ohWNBaMsJojLEU0bS62+KGkb9Oatj8SUlAQj0h2UQ98=
X-Gm-Gg: ASbGncs7PPn6RkMFsMQJ8XrFcNeQPBmstNkJJLBSeyHcgwWi93SblYCoT2K5CN0jsZ2
	CBkrtV+gIhPaRTztgay+5CdkKbOtlSGVMOPtWyGkkagfv29ZijTE72Kskd5Q19bJhGf67wg+4th
	MxHB5ZCNV2H6+EDqYfQ2/Mtab5oTQPFhlFyfU4u0fb+JypXuXTZ+EiQ2DQfkYDcQV5kscyL2qTF
	bL1ErXPMT4GzmjdUAPxm28koYmuv8rzvSF9AfKjbCqBpHyXw+TPF2Si2q0wfP4=
X-Google-Smtp-Source: AGHT+IG6CQwRSN0Eon/cIgo9Xa+ZZlHMcccWAy+S0UbzMr4qR7TkvsfPiepU2JAHFrUUc/dfKRMGDA==
X-Received: by 2002:a17:906:3289:b0:aa6:6f92:74b1 with SMTP id a640c23a62f3a-aab778f6f48mr940605266b.13.1734348994774;
        Mon, 16 Dec 2024 03:36:34 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Mon, 16 Dec 2024 11:36:31 +0000
Message-Id: 
To: "Jan Beulich" 
Cc: "Andrew Cooper" ,
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= ,
 
Subject: Re: [PATCH v2 08/13] x86/xstate: Map/unmap xsave area in
 {compress,expand}_xsave_states()
From: "Alejandro Vallejo" 
X-Mailer: aerc 0.18.2
References: <20241105143310.28301-1-alejandro.vallejo@cloud.com>
 <20241105143310.28301-9-alejandro.vallejo@cloud.com>
 <0edad037-f6df-4a9a-ba3f-73ea2405604d@suse.com>
In-Reply-To: <0edad037-f6df-4a9a-ba3f-73ea2405604d@suse.com>

On Mon Dec 9, 2024 at 4:20 PM GMT, Jan Beulich wrote:
> On 05.11.2024 15:33, Alejandro Vallejo wrote:
> > No functional change.
> >=20
> > Signed-off-by: Alejandro Vallejo 
> > ---
> > v2:
> >   * No change
> > ---
> >  xen/arch/x86/xstate.c | 8 ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >=20
> > diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
> > index 401bdad2eb0d..6db7ec2ea6a9 100644
> > --- a/xen/arch/x86/xstate.c
> > +++ b/xen/arch/x86/xstate.c
> > @@ -177,7 +177,7 @@ static void setup_xstate_comp(uint16_t *comp_offset=
s,
> >   */
> >  void expand_xsave_states(const struct vcpu *v, void *dest, unsigned in=
t size)
> >  {
> > -    const struct xsave_struct *xstate =3D v->arch.xsave_area;
> > +    const struct xsave_struct *xstate =3D VCPU_MAP_XSAVE_AREA(v);
> >      const void *src;
> >      uint16_t comp_offsets[sizeof(xfeature_mask)*8];
> >      u64 xstate_bv =3D xstate->xsave_hdr.xstate_bv;
> > @@ -228,6 +228,8 @@ void expand_xsave_states(const struct vcpu *v, void=
 *dest, unsigned int size)
> > =20
> >          valid &=3D ~feature;
> >      }
> > +
> > +    VCPU_UNMAP_XSAVE_AREA(v, xstate);
> >  }
>
> In the middle of these two hunks there's an early return.
>
> > @@ -242,7 +244,7 @@ void expand_xsave_states(const struct vcpu *v, void=
 *dest, unsigned int size)
> >   */
> >  void compress_xsave_states(struct vcpu *v, const void *src, unsigned i=
nt size)
> >  {
> > -    struct xsave_struct *xstate =3D v->arch.xsave_area;
> > +    struct xsave_struct *xstate =3D VCPU_MAP_XSAVE_AREA(v);
> >      void *dest;
> >      uint16_t comp_offsets[sizeof(xfeature_mask)*8];
> >      u64 xstate_bv, valid;
> > @@ -294,6 +296,8 @@ void compress_xsave_states(struct vcpu *v, const vo=
id *src, unsigned int size)
> > =20
> >          valid &=3D ~feature;
> >      }
> > +
> > +    VCPU_UNMAP_XSAVE_AREA(v, xstate);
> >  }
>
> Same here.
>
> Jan

Doh! Yes, good catch. I'll "goto out" on both rather than the early exit to
ensure the unmap is invoked in the "already (de)compressed" cases.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 11:38:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 11:38:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857828.1270032 (Exim 4.92)
	(envelope-from )
	id 1tN9Qh-0005oM-2g; Mon, 16 Dec 2024 11:38:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857828.1270032; Mon, 16 Dec 2024 11:38:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tN9Qg-0005oF-Sv; Mon, 16 Dec 2024 11:38:26 +0000
Received: by outflank-mailman (input) for mailman id 857828;
 Mon, 16 Dec 2024 11:38: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 1tN9Qf-0005mm-7V
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 11:38: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 425a2174-bba2-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 12:38:24 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-43622354a3eso27122585e9.1
 for ; Mon, 16 Dec 2024 03:38: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-436360147desm82200205e9.9.2024.12.16.03.38.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 03:38: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: 425a2174-bba2-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734349104; x=1734953904; 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=I3+dyRajkcNzGgdPoCJrlBLi/zuPpVioGU77W2JhwdQ=;
        b=d2sTaS/ngBPlbifigiJwFJUnOYh8S+Q1iurawaoFXOJU2KTXBKWX6HLLd1AoJkraiK
         EuOPZNhe2gBn90cDHpr3+PdvTzy/JNru/L0ZhramiqfA5OZ7QvEYQHmgX5NGOCtqhnLk
         bDrSLxFAONNEIxQPxLdW521LAk7gUq6AZcjkCvSbiVMTxV4Bc6awKXqrfKYZlPLk2vH/
         4z+wnW378mmJ+POfYAS1PbcFUAi6Tkl7PBiD7HenaJfM9hK9B1i9ZV0D97fuDVAFRwW8
         bcBl7RPgyE5L01NHEzCbWHXg/ba3yT49PNWGJICR8tTY3vqaFa+ZUQKOoJg29vMjizWH
         wf7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734349104; x=1734953904;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=I3+dyRajkcNzGgdPoCJrlBLi/zuPpVioGU77W2JhwdQ=;
        b=fzFEbV8j6t7d3fkDUXJM4ZFbP0y86rFxbuH90iA2soSIc4gZD70Md05W0HoUpo6H8N
         75gS4YXazanu/WfsU1X5moyrEv6hIyDJSE6tnXWq0th2s3WWBi+LpjfWC8/v9Q8Tv6Yu
         6rMIITd/FeiAhmUDOQmoRzOlMWqZCOIGah797xpQ7HMLykeCB52B6L0yuLptvBr138hs
         Tgho5nh2+1wWclVob70NpFCiFFiKqIQ1MPzO25dwoo/W5Qg0FmW9Bts7zq0+ZGD/7ooG
         yIY82A/3GIZfVAg7dPG1kc7WH5P+6FlEsFtbFpdzKykUFZuvHqJ9EYczi27r8EBVlC6T
         oOsQ==
X-Gm-Message-State: AOJu0YzOB5qVHHU72A7gVBTgrljdnO6uK6PvLQnDZSPn1kcvgW2fSC9z
	oSnFydWTX0Op/4qciysSPCOYi3/dImNEANYgaI6g2VWWpf7UK8OMgBTvZ6oicQ==
X-Gm-Gg: ASbGncuOrfJEHkga0URUC354p3uQ18AdGFDDqW586D9MaZnn/S90Z2fkbyPWsAEOGb2
	a5kPjLcXjdIF/8exaqAQRq3LZbl4yujuIQh+LYR9AxypVesGTz5CXHeIfNl5PfnMFU/rwSyGULk
	DXXg9bTxha+QxsEmovJBO5HzznJWMwR4d12aF2oT3R9Ca735aYch3p/5juwYJJnlVmiCk7Z/S57
	hHziFubtGqYwTH5/6uh69LC+vc/ozGszP0vzihbL0w+yvVEvPvzy2bSycBddV7QIxCq+8hxCGqo
	PBWhNl73Bo4Pl04zHlSaWBfCP1I33GAbCaRxg/yA0A==
X-Google-Smtp-Source: AGHT+IFQXxH1Rdpo/0yV5jGJ/DRA801yzUFaKj6qUiKBw8BHoSD/qgpMdYNsLROlpedYBEByWcDavw==
X-Received: by 2002:a05:600c:3b9c:b0:42c:c401:6d8b with SMTP id 5b1f17b1804b1-4362aa2deaemr100624655e9.7.1734349103952;
        Mon, 16 Dec 2024 03:38:23 -0800 (PST)
Message-ID: <3f3e9a77-5695-4c91-9fc2-11a3c21605c5@suse.com>
Date: Mon, 16 Dec 2024 12:38:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/1] tools/libacpi: clear ASL warning about PCI0
To: Ariel Otilibili-Anieli 
Cc: xen-devel@lists.xenproject.org, Anthony PERARD 
References: <20241215154659.151158-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241215154659.151158-2-Ariel.Otilibili-Anieli@eurecom.fr>
 <5599dc89-0fa4-4255-b4a1-5b81e151d8c7@suse.com>
 <2f7a85-67600280-e411-38ee5c40@258420856>
 
 <2f7a86-67600f80-8b81-26131fc0@216081513>
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: <2f7a86-67600f80-8b81-26131fc0@216081513>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.12.2024 12:31, Ariel Otilibili-Anieli wrote:
> On Monday, December 16, 2024 12:01 CET, Jan Beulich  wrote:
> 
>> On 16.12.2024 11:36, Ariel Otilibili-Anieli wrote:
>>> On Monday, December 16, 2024 10:53 CET, Jan Beulich  wrote:
>>>
>>>> On 15.12.2024 16:40, Ariel Otilibili wrote:
>>>>> * iasl complains _HID and _ADR cannot be used at the same time
>>>>>
>>>>> ```
>>>>> /usr/bin/iasl -vs -p tools/firmware/hvmloader/dsdt_anycpu.tmp -tc tools/firmware/hvmloader/dsdt_anycpu.asl 2>&1 | grep -B10 HID
>>>>> tools/firmware/hvmloader/dsdt_anycpu.asl     40:        Device (PCI0)
>>>>> Warning  3073 -                                    Multiple types ^  (Device object requires either a _HID or _ADR, but not both)
>>>>> ```
>>>>>
>>>>> * generally _HID devices are enumerated and have their drivers loaded by ACPI
>>>>> * this is from "ASL 2.0 Introduction and Overview" (page 4).
>>>>> * removing _ADR, the warning is cleared out.
>>>>
>>>> Okay, that's the positive aspect. Yet what about the potential fallout thereof?
>>>> Can you confirm that there's no risk of regressions with older guest OSes, for
>>>> example?
>>>
>>> OSes that were released after ACPI 2.0 should work [1]; including WinXP: 
>>> The 2.0 specs says either _HID or _ADR should be included [2], not both (Section 6.1, page 146).
>>
>> We must be looking at two different variants of the spec then. My copy says
>> "device object must contain either an _HID object or an _ADR object, but can
>> contain both." Also still in 2.0c. I agree that in e.g. 6.5 the wording has
>> changed. I also agree that the use of "either" doesn't help clarity.
> 
> I looked up 2.0 (July 2000); indeed, it said "can contain both". My bad.
>>
>>> I chose WinXP because, on another patch, it came up in the discussion [3].
> 
> The change should work down to WinXP: the name _HID is kept.
> 
> ```
> $ git grep -B2 -A2 -n PNP0A03
> tools/libacpi/dsdt.asl-40-       Device (PCI0)
> tools/libacpi/dsdt.asl-41-       {
> tools/libacpi/dsdt.asl:42:           Name (_HID, EisaId ("PNP0A03"))
> tools/libacpi/dsdt.asl-43-           Name (_UID, 0x00)
> tools/libacpi/dsdt.asl-44-           Name (_ADR, 0x00)
> ```
> 
> Its EISA ID is "PNP0A03"; the namespace is reserved for Microsoft. Microsoft identifies "PNP0A03" as PCI devices [1].

You again say "should" without explaining what you derive this from. Is it
written down somewhere that no OS we (remotely) care about ever evaluated
_ADR when _HID was there? As before, along side mentioning the benefits of
the change, I'd like to also see a discussion of risks.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 11:44:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 11:44:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857843.1270042 (Exim 4.92)
	(envelope-from )
	id 1tN9WB-0007sa-K0; Mon, 16 Dec 2024 11:44:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857843.1270042; Mon, 16 Dec 2024 11:44:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tN9WB-0007sT-GA; Mon, 16 Dec 2024 11:44:07 +0000
Received: by outflank-mailman (input) for mailman id 857843;
 Mon, 16 Dec 2024 11:44: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 1tN9WA-0007sN-9I
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 11:44:06 +0000
Received: from fforwardh-a4-smtp.messagingengine.com
 (fforwardh-a4-smtp.messagingengine.com [103.168.172.199])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0cabd406-bba3-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 12:44:04 +0100 (CET)
Received: from phl-compute-11.internal (phl-compute-11.phl.internal
 [10.202.2.51])
 by mailfforwardh.phl.internal (Postfix) with ESMTP id 5A4E92920AF9;
 Mon, 16 Dec 2024 06:44:03 -0500 (EST)
Received: from phl-frontend-01 ([10.202.2.160])
 by phl-compute-11.internal (MEProxy); Mon, 16 Dec 2024 06:44:03 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 16 Dec 2024 06:44:01 -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: 0cabd406-bba3-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	: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=
	1734349443; x=1734435843; bh=WLk/bUl8QTjpdm5SL23a7o3i/Q+j5mOh+lA
	vvvlQblE=; b=4SxQpDs6t686cCmXjLEHnhrTs0FCp9wdrUqNRLnCXKYiQVODBL4
	YnXxHAv15enSN41iLNxRqW1fQa/TmSWyj5X2C0QPOFyImD6tjim+XVI9Ri3rz3lL
	tYrGR7+fOuKCnGEosfMjZfu3EbeUbMe2666u1JejAySseGSrLquD+jjsAAKH5q2w
	lE6njDD7AZWy4lrHk3tESfUjOZsyV4vGPHOkVIJxzDHAQ/NmcrdpDDKh3cQpLogB
	gOYdVJWZauoYZirZ2d11ezNVoEr3qupDJrqRQvDa3kVFNEghVg0UbZEkmuGtw21Y
	fDlTM7tdJx06cT0+TuaLBItmK3mPtgmIxbA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrleefgdefudcutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr
    tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth
    hsucdlqddutddtmdenucfjughrpefhvfevufffkffoggfgsedtkeertdertddtnecuhfhr
    ohhmpefuvghrghhihicumfhisghrihhkuceoufgvrhhgihihpgfmihgsrhhikhesvghprg
    hmrdgtohhmqeenucggtffrrghtthgvrhhnpeegvdeffefhuddvteekgeelgefgleehkeev
    ieduudefhedtheellefhkeeivdevvdenucffohhmrghinhepkhgvrhhnvghlrdhorhhgne
    cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshgrkhhi
    sgesuggrrhhkshhtrghrrdhsihhtvgdpnhgspghrtghpthhtohepuddvpdhmohguvgepsh
    hmthhpohhuthdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhr
    ohhjvggtthdrohhrghdprhgtphhtthhopehsthgvfhgrnhhordhsthgrsggvlhhlihhnih
    esrghmugdrtghomhdprhgtphhtthhopehjuhhlihgvnhesgigvnhdrohhrghdprhgtphht
    thhopegsvghrthhrrghnugdrmhgrrhhquhhishesrghrmhdrtghomhdprhgtphhtthhope
    hmihgthhgrlhdrohhriigvlhesrghmugdrtghomhdprhgtphhtthhopehvohhlohguhihm
    hihrpggsrggstghhuhhksegvphgrmhdrtghomhdprhgtphhtthhopegrnhgurhgvfidrtg
    hoohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthhtoheprghnthhhohhnhidrphgv
    rhgrrhgusehvrghtvghsrdhtvggthhdprhgtphhtthhopehjsggvuhhlihgthhesshhush
    gvrdgtohhm
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i5753c467:Fastmail
From: Sergiy Kibrik 
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Sergiy Kibrik 
Subject: [XEN PATCH v1] arm: introduce kconfig options to disable hypercalls
Date: Mon, 16 Dec 2024 13:43:58 +0200
Message-Id: <20241216114358.2845447-1-Sergiy_Kibrik@epam.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Stefano Stabellini 

It can be beneficial for some dom0less systems to further reduce Xen footprint
and disable some hypercalls handling code, which may not to be used & required
in such systems. Each hypercall has a separate option to keep configuration
flexible.

Options to disable hypercalls:
- domctl, sysctl
- hvm
- physdev
- platform

Some of these options are forced to be configurable only when DOM0LESS is
enabled, so that system won't become accidentally un-bootable when any hypercall
is disabled.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Sergiy Kibrik 
CC: Andrew Cooper 
CC: Jan Beulich 
---
changes in v1:
 - incorporated PV_SHIM_EXCLUSIVE check in Kconfig
 - drop excessive ifeq from Makefile & #ifdef from code
 - drop checks for CONFIG_HVM_OP & CONFIG_PLATFORM_HYP being off when !DOM0LESS
 - description updated

RFC patch here: https://lore.kernel.org/xen-devel/20240926095806.67149-1-Sergiy_Kibrik@epam.com/
---
 xen/arch/arm/Makefile        | 10 +++++-----
 xen/common/Kconfig           | 27 +++++++++++++++++++++++++++
 xen/common/Makefile          |  4 ++--
 xen/common/domain.c          |  2 ++
 xen/include/hypercall-defs.c | 14 ++++++++++++--
 xen/include/xen/hypercall.h  | 12 ++++++++++++
 6 files changed, 60 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index e4ad1ce851..b910ce3726 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_IOREQ_SERVER) += dm.o
 obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
 obj-y += domain.o
 obj-y += domain_build.init.o
-obj-y += domctl.o
+obj-$(CONFIG_DOMCTL) += domctl.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 obj-y += efi/
 obj-y += gic.o
@@ -29,7 +29,7 @@ obj-$(CONFIG_HAS_ITS) += gic-v3-lpi.o
 obj-y += guestcopy.o
 obj-y += guest_atomics.o
 obj-y += guest_walk.o
-obj-y += hvm.o
+obj-$(CONFIG_HVM_OP) += hvm.o
 obj-y += io.o
 obj-$(CONFIG_IOREQ_SERVER) += ioreq.o
 obj-y += irq.o
@@ -40,8 +40,8 @@ obj-y += mm.o
 obj-y += monitor.o
 obj-y += p2m.o
 obj-y += platform.o
-obj-y += platform_hypercall.o
-obj-y += physdev.o
+obj-$(CONFIG_PLATFORM_HYP) += platform_hypercall.o
+obj-$(CONFIG_PHYSDEVOP) += physdev.o
 obj-y += processor.o
 obj-y += psci.o
 obj-y += setup.o
@@ -51,7 +51,7 @@ obj-y += smpboot.o
 obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
 obj-$(CONFIG_STATIC_MEMORY) += static-memory.init.o
 obj-$(CONFIG_STATIC_SHM) += static-shmem.init.o
-obj-y += sysctl.o
+obj-$(CONFIG_SYSCTL) += sysctl.o
 obj-y += time.o
 obj-y += traps.o
 obj-y += vcpreg.o
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 90268d9249..22b1b10700 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -516,4 +516,31 @@ config TRACEBUFFER
 	  to be collected at run time for debugging or performance analysis.
 	  Memory and execution overhead when not active is minimal.
 
+menu "Supported hypercall interfaces"
+	visible if DOM0LESS_BOOT && EXPERT
+
+config SYSCTL
+	bool "Enable sysctl hypercall"
+	default y
+
+config DOMCTL
+	bool "Enable domctl hypercalls"
+	default y
+
+config HVM_OP
+	bool "Enable HVM hypercalls"
+	depends on HVM
+	default y
+
+config PLATFORM_HYP
+	bool "Enable platform hypercalls"
+	depends on !PV_SHIM_EXCLUSIVE
+	default y
+
+config PHYSDEVOP
+	bool "Enable physdev hypercall"
+	default y
+
+endmenu
+
 endmenu
diff --git a/xen/common/Makefile b/xen/common/Makefile
index b279b09bfb..26de84d122 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -66,9 +66,9 @@ obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo un
 obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o)
 
 ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
-obj-y += domctl.o
+obj-$(CONFIG_DOMCTL) += domctl.o
 obj-y += monitor.o
-obj-y += sysctl.o
+obj-$(CONFIG_SYSCTL) += sysctl.o
 endif
 
 extra-y := symbols-dummy.o
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 92263a4fbd..77d15a317f 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1053,7 +1053,9 @@ int domain_kill(struct domain *d)
         d->is_dying = DOMDYING_dying;
         rspin_barrier(&d->domain_lock);
         argo_destroy(d);
+#ifdef CONFIG_DOMCTL
         vnuma_destroy(d->vnuma);
+#endif
         domain_set_outstanding_pages(d, 0);
         /* fallthrough */
     case DOMDYING_dying:
diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c
index 7720a29ade..16b4c795e4 100644
--- a/xen/include/hypercall-defs.c
+++ b/xen/include/hypercall-defs.c
@@ -234,7 +234,7 @@ stack_switch                       do:2     do:2     -        -        -
 set_callbacks                      compat   do       -        -        -
 fpu_taskswitch                     do       do       -        -        -
 sched_op_compat                    do       do       -        -        dep
-#ifndef CONFIG_PV_SHIM_EXCLUSIVE
+#if defined(CONFIG_PLATFORM_HYP)
 platform_op                        compat   do       compat   do       do
 #endif
 set_debugreg                       do       do       -        -        -
@@ -247,7 +247,9 @@ set_timer_op                       compat   do       compat   do       -
 event_channel_op_compat            do       do       -        -        dep
 xen_version                        do       do       do       do       do
 console_io                         do       do       do       do       do
+#ifdef CONFIG_PHYSDEV
 physdev_op_compat                  compat   do       -        -        dep
+#endif
 #if defined(CONFIG_GRANT_TABLE)
 grant_table_op                     compat   do       hvm      hvm      do
 #elif defined(CONFIG_PV_SHIM)
@@ -269,14 +271,20 @@ callback_op                        compat   do       -        -        -
 xenoprof_op                        compat   do       -        -        -
 #endif
 event_channel_op                   do       do       do:1     do:1     do:1
+#ifdef CONFIG_PHYSDEVOP
 physdev_op                         compat   do       hvm      hvm      do_arm
-#ifdef CONFIG_HVM
+#endif
+#ifdef CONFIG_HVM_OP
 hvm_op                             do       do       do       do       do
 #endif
 #ifndef CONFIG_PV_SHIM_EXCLUSIVE
+#ifdef CONFIG_SYSCTL
 sysctl                             do       do       do       do       do
+#endif
+#ifdef CONFIG_DOMCTL
 domctl                             do       do       do       do       do
 #endif
+#endif
 #ifdef CONFIG_KEXEC
 kexec_op                           compat   do       -        -        -
 #endif
@@ -293,7 +301,9 @@ hypfs_op                           do       do       do       do       do
 #endif
 mca                                do       do       -        -        -
 #ifndef CONFIG_PV_SHIM_EXCLUSIVE
+#ifdef CONFIG_DOMCTL
 paging_domctl_cont                 do       do       do       do       -
 #endif
+#endif
 
 #endif /* !CPPCHECK */
diff --git a/xen/include/xen/hypercall.h b/xen/include/xen/hypercall.h
index f307dfb597..e47c6ddfd2 100644
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -24,6 +24,18 @@
 /* Needs to be after asm/hypercall.h. */
 #include 
 
+#if !defined(CONFIG_DOMCTL) && !defined(CONFIG_DOM0LESS_BOOT)
+#error "domctl and dom0less can't be disabled simultaneously"
+#endif
+
+#if !defined(CONFIG_PHYSDEVOP) && !defined(CONFIG_DOM0LESS_BOOT)
+#error "physdevop and dom0less can't be disabled simultaneously"
+#endif
+
+#if !defined(CONFIG_SYSCTL) && !defined(CONFIG_DOM0LESS_BOOT)
+#error "sysctl and dom0less can't be disabled simultaneously"
+#endif
+
 extern long
 arch_do_domctl(
     struct xen_domctl *domctl, struct domain *d,
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 11:58:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 11:58:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857852.1270052 (Exim 4.92)
	(envelope-from )
	id 1tN9k1-0001cG-Ou; Mon, 16 Dec 2024 11:58:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857852.1270052; Mon, 16 Dec 2024 11:58:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tN9k1-0001c9-Lp; Mon, 16 Dec 2024 11:58:25 +0000
Received: by outflank-mailman (input) for mailman id 857852;
 Mon, 16 Dec 2024 11:58: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 1tN9k0-0001c3-G5
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 11:58:24 +0000
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [2a00:1450:4864:20::529])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0b4c57a4-bba5-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 12:58:20 +0100 (CET)
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5cecbddb574so6831576a12.1
 for ; Mon, 16 Dec 2024 03:58:20 -0800 (PST)
Received: from localhost ([85.152.134.39]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d652f352b9sm3194597a12.81.2024.12.16.03.58.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 03:58: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: 0b4c57a4-bba5-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1734350300; x=1734955100; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+OnOxTjScTaeAqk9bWH4KWMLUkfMOrD1DbxYHYwpUYY=;
        b=JKGE29KAg0vXpfScf+lyngp5+uQthje+Qm+puifE0ufPmUc1cOVjEphksO+wknqQr0
         57CpEvrFQWVKSREDH/xJLAEZp0LSSkkxVEWjCrkf+rbjBvvDsNHI/ZAEr0atTlxUHIoc
         bM40SA3g/HLv8D+iMQMewgNKnd1JkeHqQPhtc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734350300; x=1734955100;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=+OnOxTjScTaeAqk9bWH4KWMLUkfMOrD1DbxYHYwpUYY=;
        b=OwmapWdxcYJHR8RSYjxVuJvU84vTHNviiUMYviD7mL3vOazNR+dXZnBPxNquTcNp5c
         70sn9uTAu398dss9++hyXjhlsjhNz+ct8yT6WFi/MkqyA2RMJWjKbBhRXcmjrC3DhEAB
         eu2VPvA3rIqralzNyK6UTIbSW6rD+RY9kqoxun4kdM5Jjq6Bax2BBD1/a4kyQY3SeR3n
         jIt//1zL5Tr6342YOTA7InWIR7q9p4dQ9T9ZJ/GHyHaaYrSfC5rujvvtjvzmd7LLtNsd
         BYaD87Ray9XqM4pFJf/3RyFgDttSYvScAo7eK/pbCqMf/Krs5M9ifoYKdMcwQYO8XVeP
         tyBg==
X-Forwarded-Encrypted: i=1; AJvYcCWgzWI3fkKPOHemeGMtbicqz4So42zjgFrdhk1IBxdwhiGd2tIBV/nXjgCjdfAbL2IDwQ6mcGWMFlQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyoBQxyN+OUf9tz7NxWDjf5OzdGLxHX/IsdaJrVQGSOE53eZQ8f
	jJAuf3xbOfAc0nDbAg11AEUYMiBdKEfitoAwfERYUqwiXaiUjrB+TMz9EdZy7+Q=
X-Gm-Gg: ASbGncuKoyQjdkLjzDgBakdww0Wo25fa1ubFXgYyIscAgW6nfMlF4DWMH3pIaPQdFV7
	MxTeeaiIRbaXITz9Yily9L05uxBsRnxs+6IAWVD3ybhtsz8Sn2QaymdZ2FXrMC34Z42Bi4xSEUz
	6jdQpGbizuuyycAvM4JBEcFWetS1Cy6btduXJ7fgXJvAdKusT5UgO5mQ/IgyraY5cBe1pJIPY4X
	c0ehKXzfOVW7+tdbnnycZny6sVpm21wItuDG0wcIwSCxNKQmHOj+93RnxyWCVc=
X-Google-Smtp-Source: AGHT+IH0YCezW2KEWLwpCMSIKQXnAWe611CAkvX5KczC12Vrp3XHOZp64i873gRWb5etHMVudi8pwA==
X-Received: by 2002:a05:6402:3593:b0:5d3:ba42:e9f4 with SMTP id 4fb4d7f45d1cf-5d63c3ed1e1mr10134748a12.23.1734350298634;
        Mon, 16 Dec 2024 03:58:18 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Mon, 16 Dec 2024 11:58:14 +0000
Message-Id: 
Cc: "Andrew Cooper" ,
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= ,
 
Subject: Re: [PATCH v2 09/13] x86/emulator: Refactor FXSAVE_AREA to use
 wrappers
From: "Alejandro Vallejo" 
To: "Jan Beulich" 
X-Mailer: aerc 0.18.2
References: <20241105143310.28301-1-alejandro.vallejo@cloud.com>
 <20241105143310.28301-10-alejandro.vallejo@cloud.com>
 
In-Reply-To: 

On Mon Dec 9, 2024 at 4:26 PM GMT, Jan Beulich wrote:
> On 05.11.2024 15:33, Alejandro Vallejo wrote:
> > --- a/xen/arch/x86/x86_emulate/blk.c
> > +++ b/xen/arch/x86/x86_emulate/blk.c
> > @@ -11,9 +11,12 @@
> >      !defined(X86EMUL_NO_SIMD)
> >  # ifdef __XEN__
> >  #  include 
> > -#  define FXSAVE_AREA ((void *)¤t->arch.xsave_area->fpu_sse)
> > +/* has a fastpath for `current`, so there's no actual map */
> > +#  define FXSAVE_AREA ((void *)VCPU_MAP_XSAVE_AREA(current))
> > +#  define UNMAP_FXSAVE_AREA(x) VCPU_UNMAP_XSAVE_AREA(currt ent, x)
>
> The typo of the first argument strongly suggests that the macro should
> already now evaluate its parameters, also pleasing Misra.

Not an unreasonable takeaway. I can expand as follows instead:

#define VCPU_UNMAP_XSAVE_AREA(v, x) ({ (void)(v); x; })

Thoughts?

>
> >  # else
> >  #  define FXSAVE_AREA get_fpu_save_area()
> > +#  define UNMAP_FXSAVE_AREA(x) ((void)x)
>
> If only for consistency and to avoid setting bad precedents - parentheses
> please around x.

Ack.

>
> > @@ -292,6 +295,9 @@ int x86_emul_blk(
> >          }
> >          else
> >              asm volatile ( "fxrstor %0" :: "m" (*fxsr) );
> > +
> > +        UNMAP_FXSAVE_AREA(fxsr);
> > +
> >          break;
> >      }
> > =20
> > @@ -320,6 +326,9 @@ int x86_emul_blk(
> > =20
> >          if ( fxsr !=3D ptr ) /* i.e. s->op_bytes < sizeof(*fxsr) */
> >              memcpy(ptr, fxsr, s->op_bytes);
> > +
> > +        UNMAP_FXSAVE_AREA(fxsr);
> > +
> >          break;
> >      }
>
> So for now the emulator only supports FXSAVE / FXRSTOR. That'll need to c=
hange
> sooner or later. Is it really appropriate in that light to name the new m=
acro
> after FXSAVE, when the underlying machinery uses all XSAVE?
>
> Jan

I have no strong feeling one way or the other, except that it should mirror=
 the
other macro's name. I'd say it makes more sense to rename _both_ after the
emulator is XSAVE-aware. That the internal machinery is actually XSAVE-base=
d is
an implementation detail largely irrelevant at the call sites.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 12:00:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 12:00:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857864.1270061 (Exim 4.92)
	(envelope-from )
	id 1tN9m0-00039o-6Q; Mon, 16 Dec 2024 12:00:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857864.1270061; Mon, 16 Dec 2024 12:00: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 1tN9m0-00039h-3s; Mon, 16 Dec 2024 12:00:28 +0000
Received: by outflank-mailman (input) for mailman id 857864;
 Mon, 16 Dec 2024 12:00: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 1tN9lz-000398-2g
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 12:00:27 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5640c488-bba5-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 13:00:26 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-aa69107179cso754092866b.0
 for ; Mon, 16 Dec 2024 04:00:26 -0800 (PST)
Received: from localhost ([85.152.134.39]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab963b282csm322813866b.180.2024.12.16.04.00.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 04:00: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: 5640c488-bba5-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1734350426; x=1734955226; darn=lists.xenproject.org;
        h=in-reply-to:references:subject:cc:to:from:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=5hjPTMon1EDWQtLsBgRz5nZlvtMWdXZkey3ExrywPas=;
        b=X9H+RpeXMrrZPvKRjN7/JKTQskwWh29IFTRLbvvsavIIYHi4PxJ3xr2fQd/VQO5zji
         msQ0uxeWUo9WJyHnDryj/KmV2Dr+blyIxIKIwFiVq4h6J7le9A5sDokyE3QbrcXEVGxW
         PHojKDu87xEZCg9xuiGLC9fnJO3ty5qBsNfqU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734350426; x=1734955226;
        h=in-reply-to:references:subject:cc:to:from:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=5hjPTMon1EDWQtLsBgRz5nZlvtMWdXZkey3ExrywPas=;
        b=WpsnVI4a6Xc+j5juOKuc+8yGdzBRYitZevIiOYcO/VU4kQEVnfmaPGBoaspsC2vOtk
         Z2C4tDyV6eF0eihqkBDxRSBCZa28UxgOEtubqO1YZPAJCMcicZmRBaV7T2eMaLIwaySF
         chh7jvjB4KDsllj/ZGopS7KV8Mqmdvxn1RJcOC26xO71HesGKjgE9aRao3DJ/NosPVL0
         s5qHKCD63wi1UDsL8lfM9tfWQu0aefL9iBbelNZRAI0IZLEV+H599CzPeg+qF1sbi4Dl
         K8gVHXt+LHRqdpIczHfgUM0IBgr6dkHH3pk2TFNPaT91Y9cnYE2kHxxy9XhIS4Pj/KQx
         uppA==
X-Forwarded-Encrypted: i=1; AJvYcCVjAHekpQAQPKmoAFH+oKW3m2f9XoGAfpff/aQ+u6hFfgV4hnoP8Sksj6viS2FDuzLGw9zrYCvsYcQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzsTriOYXSc1wRiVc2VDCEVirZzsg7CYOPpkV0YnI2Lg+ubuYTq
	+mAjNTqOEyT/8iDWICj3kqFkIEPkByHFEBh11cCZXQIVrOurGOMoJHHK/d25qB4=
X-Gm-Gg: ASbGnctldFtuFlUMT9jhVyboPywr92ho3xJhDV1zQkuQuqCalljMnrxflFh/1XoP5s/
	+gYiJN9EIcyJdZuyCQPvR0iBTFKCbychiVShfKoDInYjF+803nvAnqxelmDcMEc7Wu4Pc0i5qWr
	xBoRGq0nOwIZVeakBMogCHkdQc9IDSk8EPyp+RlwugPaBZrfP7Lpg9WNQ8fboDJtRSX/3Svy2uk
	7lcc+ctY0U9zOWPps+v+sfm7QE9CwWfhqEV0ubNITgbRc3APinO/lxWqFg3geY=
X-Google-Smtp-Source: AGHT+IGnU5VysDyUFo6bLcfUIY9VhTZro3gr/Q1V4xRALoMV2UEDcD16XCKNUlCX1KPXfmUD8vFN6w==
X-Received: by 2002:a17:906:32c3:b0:aa6:7feb:193f with SMTP id a640c23a62f3a-aab7795851bmr1194025466b.20.1734350425898;
        Mon, 16 Dec 2024 04:00:25 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Mon, 16 Dec 2024 12:00:22 +0000
Message-Id: 
From: "Alejandro Vallejo" 
To: "Jan Beulich" 
Cc: "Andrew Cooper" ,
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= ,
 
Subject: Re: [PATCH v2 10/13] x86/mpx: Map/unmap xsave area in in
 read_bndcfgu()
X-Mailer: aerc 0.18.2
References: <20241105143310.28301-1-alejandro.vallejo@cloud.com>
 <20241105143310.28301-11-alejandro.vallejo@cloud.com>
 <7e36137b-ce1f-4e78-9a41-fbfdbe9c0d87@suse.com>
In-Reply-To: <7e36137b-ce1f-4e78-9a41-fbfdbe9c0d87@suse.com>

On Mon Dec 9, 2024 at 4:30 PM GMT, Jan Beulich wrote:
> On 05.11.2024 15:33, Alejandro Vallejo wrote:
> > --- a/xen/arch/x86/xstate.c
> > +++ b/xen/arch/x86/xstate.c
> > @@ -1022,9 +1022,10 @@ int handle_xsetbv(u32 index, u64 new_bv)
> > =20
> >  uint64_t read_bndcfgu(void)
> >  {
> > +    uint64_t bndcfgu =3D 0;
> >      unsigned long cr0 =3D read_cr0();
> > -    struct xsave_struct *xstate
> > -        =3D idle_vcpu[smp_processor_id()]->arch.xsave_area;
> > +    struct vcpu *v =3D idle_vcpu[smp_processor_id()];
>
> Can this be pointer-to-const? Certainly right now, so the question is rat=
her
> meant to be forward looking.
>
> > +    struct xsave_struct *xstate =3D VCPU_MAP_XSAVE_AREA(v);
>
> This certainly can be pointer-to-const, just like ...
>
> >      const struct xstate_bndcsr *bndcsr;
>
> ... this is.
>
> Jan

Yes, those retained non-const because of the now missing patch to zero-out
bndcfgu.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 12:01:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 12:01:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857876.1270071 (Exim 4.92)
	(envelope-from )
	id 1tN9n6-00046w-FO; Mon, 16 Dec 2024 12:01:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857876.1270071; Mon, 16 Dec 2024 12: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 1tN9n6-00046p-Cn; Mon, 16 Dec 2024 12:01:36 +0000
Received: by outflank-mailman (input) for mailman id 857876;
 Mon, 16 Dec 2024 12:01: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 1tN9n5-00046j-73
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 12:01:35 +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 7e06b1a4-bba5-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 13:01:33 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-436281c8a38so25472535e9.3
 for ; Mon, 16 Dec 2024 04:01: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-4363602d76fsm82147465e9.18.2024.12.16.04.01.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 04:01: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: 7e06b1a4-bba5-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734350492; x=1734955292; 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=Eru0yi5UTg7G8gcdUMXhgut/0ygz8qe/9NCcR7BjtcE=;
        b=Ben+ya9snnLNwnkAuC3O+iGgtd38xqYFp5FvlugxgJHtgizxV0UWkma5B4IpF2x5dX
         0JnCjpB4bmwUVASjApKNODVFMyjKW3ESzOm0M+8P78gGs6r8TCW1k+DaxSRRcyKzcVZJ
         fvkbQIyWUH2A40aD9LnbjSQjlYmApd9rFXMZ8PBt9EWgnzpW5ut5YbMGjEkLnx1GY/iV
         ocZ63eWHkjeGQOzyyTJLbiyZ7+KgVI+/aNeSXBvzS2F0bA5ADUQgbWL21Klb5KhyCjBi
         RubRaAnj20+txm5k6PzhdIL/fKwfli283MPMZEe95u6DaAAFcgNXnCf86Sl+jE9SgeA8
         LE2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734350492; x=1734955292;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Eru0yi5UTg7G8gcdUMXhgut/0ygz8qe/9NCcR7BjtcE=;
        b=Jkq2LbRKnY2e28L20ZlMBnb+dJyI6ZFzJYBvNNZ1pTDBiWSseMZWXK0W1yOolMSM5d
         3iIWOSNAK/ElRDXKxcqpJG0o345ozibchq2z6+NED36swQDU3PRyQi3x1hmYMswgt8Lr
         Sm290WXiTlZDKKhiVLEyyZ+LqLUqTeDIvIb/eLtqIg5vM3mvh7DzssL2krUquV2+ZbQm
         br8AmykfWRDASaeqK/19yRnc0g8gSkZZM4t3vXW8L9tIGWkjHz0MTjOa7zdrGNQ28ZFC
         +IDig8SGbVx8Rue4vqET1GvdfIVVyO9eeZu88MM3SEOlYTbdBaPmf2LxgBk9PnJNaIuw
         KSxQ==
X-Forwarded-Encrypted: i=1; AJvYcCWGAJUIzfwp2Ig06LwBJTfZWF2LIMD/J38jerE7nIArli0YxZ7b0PaP0Gkm7BmqAw3dtE1VjI1WWFQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yymd4CKEchEmtPRSL1yddzHEnt1bcJtiy8Xl/Tcckb6nIDoQpbA
	o7B4FP+u5qqGIWfKueyv/vndzpTpwbHiUmN90G5pTAQAcX9wRAWBhFQVJFuSDA==
X-Gm-Gg: ASbGnctpazCwd20sY8FaL8uxFR1mhjPfw6P6Y2UkxxsY8dkU3/Z/Ha/Jjml2s/Gd90V
	V2vqA5augivIK8jl2dE755srqxkE/K6eSq3Xd/yLzPnHpF+brfL6EvxUAFmz1dVdtWhr7w4vlPm
	6qc+i4770n7c33k/AWLY3NHOrVK/QXHtZh4yVZD6PJ3etd0YQjMpVe3RX2Bg3pwvlCRiPssuwpP
	J5l8nEH5ruFvomWOkISqC9VUNm8t4TELuFDGY1MpapSlm4fEXHbl9bfIus7RhG6x/W+gjzKRu+0
	Sh6oqE649bx9RRJgXCX5wtGq7nsGMq82wLimIzPI0g==
X-Google-Smtp-Source: AGHT+IEa62phwZgzIwE3N2wcURHjJ+2Vm5Hfgs0EXv4ZqwyxSBP21VnklcyYazM1uPegKOhSZfiYvg==
X-Received: by 2002:a05:600c:5397:b0:433:c76d:d57e with SMTP id 5b1f17b1804b1-4362aa34e4cmr89337155e9.5.1734350492552;
        Mon, 16 Dec 2024 04:01:32 -0800 (PST)
Message-ID: <96c6dbc9-05f3-4e55-acee-5e9f9e2c93e5@suse.com>
Date: Mon, 16 Dec 2024 13:01:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 09/13] x86/emulator: Refactor FXSAVE_AREA to use
 wrappers
To: Alejandro Vallejo 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241105143310.28301-1-alejandro.vallejo@cloud.com>
 <20241105143310.28301-10-alejandro.vallejo@cloud.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 16.12.2024 12:58, Alejandro Vallejo wrote:
> On Mon Dec 9, 2024 at 4:26 PM GMT, Jan Beulich wrote:
>> On 05.11.2024 15:33, Alejandro Vallejo wrote:
>>> --- a/xen/arch/x86/x86_emulate/blk.c
>>> +++ b/xen/arch/x86/x86_emulate/blk.c
>>> @@ -11,9 +11,12 @@
>>>      !defined(X86EMUL_NO_SIMD)
>>>  # ifdef __XEN__
>>>  #  include 
>>> -#  define FXSAVE_AREA ((void *)¤t->arch.xsave_area->fpu_sse)
>>> +/* has a fastpath for `current`, so there's no actual map */
>>> +#  define FXSAVE_AREA ((void *)VCPU_MAP_XSAVE_AREA(current))
>>> +#  define UNMAP_FXSAVE_AREA(x) VCPU_UNMAP_XSAVE_AREA(currt ent, x)
>>
>> The typo of the first argument strongly suggests that the macro should
>> already now evaluate its parameters, also pleasing Misra.
> 
> Not an unreasonable takeaway. I can expand as follows instead:
> 
> #define VCPU_UNMAP_XSAVE_AREA(v, x) ({ (void)(v); x; })
> 
> Thoughts?

Why would x not also be cast to void?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 12:03:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 12:03:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857885.1270081 (Exim 4.92)
	(envelope-from )
	id 1tN9ox-0004rN-Pp; Mon, 16 Dec 2024 12:03:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857885.1270081; Mon, 16 Dec 2024 12:03:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tN9ox-0004rG-N4; Mon, 16 Dec 2024 12:03:31 +0000
Received: by outflank-mailman (input) for mailman id 857885;
 Mon, 16 Dec 2024 12:03: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 1tN9ow-0004qr-QJ
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 12:03:30 +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 c313f973-bba5-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 13:03:29 +0100 (CET)
Received: by mail-wm1-x32b.google.com with SMTP id
 5b1f17b1804b1-4361f664af5so44165425e9.1
 for ; Mon, 16 Dec 2024 04:03: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
 ffacd0b85a97d-388c801223dsm8091587f8f.3.2024.12.16.04.03.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 04:03: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: c313f973-bba5-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734350608; x=1734955408; 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=HZoK8R8Q++Fvlt6Io3P422EOkwXp1d7Y7SElsgKxRUE=;
        b=T4fXldJw+l4w6wr4PNbkYbald16O0HrMoHK5t0n4Yg9A1Qq9H6XV0EYPxMG9Xm1kgv
         Y20cPFL+r9VRm0MZ3vyP+LtD9rPA1PmX6NRtW4vUsew4Kl5kkbZYol5su7EfIRG8ReIL
         BqkSxy3vMDTFaYgh6jAT9SqN+KTcB7tB9LUN2Taa2C2SUWvbg1AaShnFWEd2OkS0Tf2F
         wFOveSWRhE3htjUZzdf6GiUVVnuHiDrXWBAo+wdiqvWP3MkwfFjVesLycWGw0lLr8H/m
         IdUtiPliCCVGK7nY8HveZwHICKhWCPSeF5voDESSmPL6ulXr+9Zgz2EcjRXyInGpF04o
         x4pA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734350608; x=1734955408;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=HZoK8R8Q++Fvlt6Io3P422EOkwXp1d7Y7SElsgKxRUE=;
        b=QsVdo2/I/wlGOrw5/eN9UPinFBujAaH01gz/0xojyVZ9+uzp8Kjd+YT69Ys5BcJexy
         xeoDdsUilMTH5AFh1rwncFO0QO1QFPvGTLC9ImbmSvqxjsxBLTWBCkJo8i6ZJkE0s5IW
         OJpJPFNI3r32a+P1KM7qU+8Q4FTFuQgPuaqxgfGzz2WF1x+8SGMfixmRdCr6sVB763fk
         TiM4o9TuWVFy0XECTz56LSiElCIPNMbvB+MB7m3lYlXO/5IAiA2Hyxw66PCJ8rdH+oqq
         DnCrfSOTxhISvONzLtGbYWMxOjbKgX9M1Br5dufQlzYryBVOkjeWDs5eOJz2ViHlpTGp
         ihmQ==
X-Forwarded-Encrypted: i=1; AJvYcCUcUMYxgihqUk7xu9MV7tU7jNY3hMffQ8+asJ1yDGImZED80OEE+PDUkqwk09zdeTQKqRn6o9qxE+o=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx08NNSQcSdAgiTWmk9lZ+6sYdrLXKYnyV/c2PLcE7WSnStt+3f
	IGSHYcstysOVCWSnLDg7XMBApkYlEI/Jc1ezX4f7xMErezHhAq2feWpg4CNZjg==
X-Gm-Gg: ASbGncv6fQvXtow44NHLpFEba10oxFhUfVQ4P9qoGOdNAmsS26cHvMqRyzZCQ/5VFC0
	tBsb5Jn9smnhv8z3vq2Xjx0/p27hvq9dnOoHnh0YuS7mrYXuM64cDWphE/R42GkAHNlbfFHNbj4
	pTVjctwAd705gPAtEKbNcs/+Iq271/R8xyoCF2mbfqoBZd1NyPPrMx49wIzzPBgLMkE0dYnlm7a
	FQDn4IXUQtSKgr2yZUKyZ7SMeHTfnEsiK8YqEkoVNWXecuYoa9H1zgyycFlxrXbD6kNKXMtfbZx
	sQjayuqno4x6z1Tcgz3+8uu5+krHaZpsm6QN0kuCTQ==
X-Google-Smtp-Source: AGHT+IEgbJevSNlD0/1GQ7fIY0t3EIdvK24kKi+4d7QLm4u2ubEdlB1vsMT5fxQg9hQ1dmQ8Q7+p4Q==
X-Received: by 2002:a05:600c:1e87:b0:432:cbe5:4f09 with SMTP id 5b1f17b1804b1-4362aa113f1mr101915375e9.4.1734350608401;
        Mon, 16 Dec 2024 04:03:28 -0800 (PST)
Message-ID: 
Date: Mon, 16 Dec 2024 13:03:27 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 10/13] x86/mpx: Map/unmap xsave area in in
 read_bndcfgu()
To: Alejandro Vallejo 
Cc: Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241105143310.28301-1-alejandro.vallejo@cloud.com>
 <20241105143310.28301-11-alejandro.vallejo@cloud.com>
 <7e36137b-ce1f-4e78-9a41-fbfdbe9c0d87@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 16.12.2024 13:00, Alejandro Vallejo wrote:
> On Mon Dec 9, 2024 at 4:30 PM GMT, Jan Beulich wrote:
>> On 05.11.2024 15:33, Alejandro Vallejo wrote:
>>> --- a/xen/arch/x86/xstate.c
>>> +++ b/xen/arch/x86/xstate.c
>>> @@ -1022,9 +1022,10 @@ int handle_xsetbv(u32 index, u64 new_bv)
>>>  
>>>  uint64_t read_bndcfgu(void)
>>>  {
>>> +    uint64_t bndcfgu = 0;
>>>      unsigned long cr0 = read_cr0();
>>> -    struct xsave_struct *xstate
>>> -        = idle_vcpu[smp_processor_id()]->arch.xsave_area;
>>> +    struct vcpu *v = idle_vcpu[smp_processor_id()];
>>
>> Can this be pointer-to-const? Certainly right now, so the question is rather
>> meant to be forward looking.
>>
>>> +    struct xsave_struct *xstate = VCPU_MAP_XSAVE_AREA(v);
>>
>> This certainly can be pointer-to-const, just like ...
>>
>>>      const struct xstate_bndcsr *bndcsr;
>>
>> ... this is.
> 
> Yes, those retained non-const because of the now missing patch to zero-out
> bndcfgu.

I'm afraid this reply is ambiguous as to what's going to happen in the next
version. I can read both "will change" and "needs to stay" into it.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 12:04:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 12:04:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857891.1270091 (Exim 4.92)
	(envelope-from )
	id 1tN9pW-0005K8-0u; Mon, 16 Dec 2024 12:04:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857891.1270091; Mon, 16 Dec 2024 12:04:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tN9pV-0005K1-UZ; Mon, 16 Dec 2024 12:04:05 +0000
Received: by outflank-mailman (input) for mailman id 857891;
 Mon, 16 Dec 2024 12:04: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 1tN9pU-0004qr-2N
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 12:04:04 +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 d7193a0d-bba5-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 13:04:02 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-436326dcb1cso16868615e9.0
 for ; Mon, 16 Dec 2024 04:04:02 -0800 (PST)
Received: from andrewcoop.eng.citrite.net (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c801ace1sm7980759f8f.60.2024.12.16.04.04.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 16 Dec 2024 04:04: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: d7193a0d-bba5-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734350641; x=1734955441; 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=E/yoIKLroltRXpYfT9Moon8gt+naa50PDu8Vp+WUJzU=;
        b=lYyh8OgP82E5co/bqfleEz8ZPno5moWopavJxWLXJ4YlqS2fPgMUiO8/ejYr0nOelC
         AlZmbzXHMmN9QfFj7t9FDeVi3LbxdudpWNWquzrLQwpRgt+BbWBxcAnIKYSaoof6viFA
         hMZSPZO1nRWLwQ8RAwFNm4FV9Xti1fDMRzUQE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734350641; x=1734955441;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=E/yoIKLroltRXpYfT9Moon8gt+naa50PDu8Vp+WUJzU=;
        b=HtwSPB2VEQXy/LPNukIvWCsBHU1kEcuegph1uSTcE6gus2NtubVeWCUsv6UudQGYYT
         ReaYqi7EHpkK7spj4pYgmQ8w8U2nB2ZPgZidZACE8MjRzg8YO+Tin3uwh2AwStodTjP1
         dAWXyQ6I7J8USp0KO5K/ZjgAmUhntBagXv7zX5JlkDtFLmgqLEkdxRVM6qCcwZH+t9F6
         DLOP9tRy9PGjrHS1tBf+P2Ugk6qK9fbU5yKhdxaePlfKnLwoh/Dd4BDuPQh5q7M8XPe2
         LA3OfEOGO/5RGAypbjYZfwDct5FeziDrnGp2AqXEqLEVa7/znskici2IpGK/wb5KTXc+
         weuA==
X-Gm-Message-State: AOJu0YxmsHeEbMnAzUs0jSAz+QDRH8RB1JNbvVyiDZAKwjS6vkxuQuiK
	2BT8TIpwhA57OJMo2wNnJyyjRsqIuzJxTCpHsfyMTA2FmxEx81dTjo5pnQPj7H+S3c+L9WIU6FK
	iDbM=
X-Gm-Gg: ASbGncsh+qA96XX/5gbGjFcQLAONfT1MwuCu9whmdhRnvXFEcc65OZ9mQJWqKcNTw06
	WqmUU6A/P+uxCX8hNN4flJ+8e+sARc6TqByucgxjzDXJBWCHykSRIcC+jqFjOwzCEeSxy8oW+mh
	Rc9+OGSPefk3TgGxgwklUA9nEvEkxcba8uSWIeDObWzpyCt3zgWLRepqjbA+m2ETzOjxfi69NE9
	I7Xx6/yFv7BesEmV1yc6PuNjLZJ9Ss4ObyA/PzxTjQGGj86tU7GFaSToUe44if3VLi2SIKkxudT
	S+KCu3vbpLrRuO0D00Q0Dsy2jbUfNHxf6AOG
X-Google-Smtp-Source: AGHT+IHfVHgP0OxPHXj1A3Ezf3u0VYmlcdRErHTOLjEvqMT0QjTOtv4zAbUkhBXLiOihKtSb07Cmbg==
X-Received: by 2002:a05:6000:1a86:b0:386:1cf9:b993 with SMTP id ffacd0b85a97d-38880ad9782mr10295762f8f.26.1734350641146;
        Mon, 16 Dec 2024 04:04:01 -0800 (PST)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Ariel Otilibili 
Subject: [PATCH] tools/misc: Drop xensymoops
Date: Mon, 16 Dec 2024 12:03:59 +0000
Message-Id: <20241216120359.10469-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

This script is not referenced by the build system, and has escaped all Python
compatibility work; it's still using print statements.

Also, the regex it uses ties it to a 32bit build of Xen, which was dropped in
Xen 4.3, 11 years ago.

Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Jan Beulich 
CC: Julien Grall 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Ariel Otilibili 
---
 tools/misc/xensymoops | 118 ------------------------------------------
 1 file changed, 118 deletions(-)
 delete mode 100755 tools/misc/xensymoops

diff --git a/tools/misc/xensymoops b/tools/misc/xensymoops
deleted file mode 100755
index 835d187e9013..000000000000
--- a/tools/misc/xensymoops
+++ /dev/null
@@ -1,118 +0,0 @@
-#!/usr/bin/env python
-
-# An oops analyser for Xen
-# Usage: xensymoops path-to-xen.s < oops-message
-
-# There's probably some more features that could go in here but this
-# is sufficient to analyse most errors in my code ;-)
-
-# by Mark Williamson (C) 2004 Intel Research Cambridge
-
-import re, sys
-
-def read_oops():
-    """Process an oops message on stdin and return (eip_addr, stack_addrs)
-
-    eip_addr is the location of EIP at the point of the crash.
-    stack_addrs is a dictionary mapping potential code addresses in the stack
-      to their order in the stack trace.
-    """
-    stackaddr_ptn = "\[([a-z,0-9]*)\]"
-    stackaddr_re  = re.compile(stackaddr_ptn)
-
-    eip_ptn = ".*EIP:.*<([a-z,0-9]*)>.*"
-    eip_re  = re.compile(eip_ptn)
-
-    matches = 0
-    stack_addresses = {}
-    eip_addr = "Not known"
-
-    while True:
-        line = sys.stdin.readline()
-        if not line: break
-
-        m = eip_re.match(line)
-        if m: eip_addr = m.group(1)
-        
-        m = stackaddr_re.findall(line)
-    
-        for i in m:
-            stack_addresses[i] = matches
-            matches += 1
-
-    return (eip_addr, stack_addresses)
-
-def usage():
-    print >> sys.stderr, """Usage: %s path-to-asm < oops-msg
-    The oops message should be fed to the standard input.  The
-    command-line argument specifies the path to the Xen assembly dump
-    produced by \"make debug\".  The location of EIP and the backtrace
-    will be output to standard output.
-    """ % sys.argv[0]
-    sys.exit()
-
-##### main
-
-if len(sys.argv) != 2:
-    usage()
-
-# get address of EIP and the potential code addresses from the stack
-(eip_addr, stk_addrs) = read_oops()
-
-# open Xen disassembly
-asm_file = open(sys.argv[1])
-
-# regexp to match addresses of code lines in the objdump
-addr_ptn = "([a-z,0-9]*):"
-addr_re  = re.compile(addr_ptn)
-
-# regexp to match the start of functions in the objdump
-func_ptn = "(.*<[\S]*>):"
-func_re  = re.compile(func_ptn)
-
-func = "" # holds the name of the current function being scanned
-
-eip_func = "" # name of the function EIP was in
-
-# list of (position in original backtrace, code address, function) tuples
-# describing all the potential code addresses we identified in the backtrace
-# whose addresses we also located in the objdump output
-backtrace = []
-
-while True:
-    line = asm_file.readline()
-    if not line: break
-
-    # if we've read the start of the function, record the name and address
-    fm = func_re.match(line)
-    if fm:
-        func = fm.group(1)
-        continue
-
-    # try match the address at the start of the line
-    m = addr_re.match(line)
-    if not m: continue
-
-    # we're on a code line...
-
-    address = m.group(1)
-
-    # if this address was seen as a potential code address in the backtrace then
-    # record it in the backtrace list
-    if stk_addrs.has_key(address):
-        backtrace.append((stk_addrs[address], address, func))
-
-    # if this was the address that EIP...
-    if address == eip_addr:
-        eip_func = func
-
-
-print "EIP %s in function %s" % (eip_addr, eip_func)
-print "Backtrace:"
-
-# sorting will order primarily by the first element of each tuple,
-# i.e. the order in the original oops
-backtrace.sort()
-
-for (i, a, f) in backtrace:
-    print "%s in function %s" % ( a, f )

base-commit: 89dca886ac6be886f7a375612426f7661c80420b
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 12:08:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 12:08:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857905.1270102 (Exim 4.92)
	(envelope-from )
	id 1tN9ty-000602-JL; Mon, 16 Dec 2024 12:08:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857905.1270102; Mon, 16 Dec 2024 12: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 1tN9ty-0005zv-F9; Mon, 16 Dec 2024 12:08:42 +0000
Received: by outflank-mailman (input) for mailman id 857905;
 Mon, 16 Dec 2024 12:08: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 1tN9tw-0005zp-74
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 12:08:40 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2062b.outbound.protection.outlook.com
 [2a01:111:f403:2413::62b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7a563cd8-bba6-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 13:08:37 +0100 (CET)
Received: from CY5PR22CA0026.namprd22.prod.outlook.com (2603:10b6:930:16::16)
 by CH2PR12MB9493.namprd12.prod.outlook.com (2603:10b6:610:27c::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Mon, 16 Dec
 2024 12:08:31 +0000
Received: from CY4PEPF0000E9D7.namprd05.prod.outlook.com
 (2603:10b6:930:16:cafe::30) by CY5PR22CA0026.outlook.office365.com
 (2603:10b6:930:16::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.21 via Frontend Transport; Mon,
 16 Dec 2024 12:08:31 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CY4PEPF0000E9D7.mail.protection.outlook.com (10.167.241.70) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Mon, 16 Dec 2024 12:08:31 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 16 Dec
 2024 06:08:31 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 16 Dec
 2024 06:08:30 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 16 Dec 2024 06:08:29 -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: 7a563cd8-bba6-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=i2p22iqhFYpCS2fMcC0mjBUxBYSKt/9rL7FVGubKmtTtq7QCZV3UsAGrnkPMM/wh4WWPQ06Vus9dQKg8qw8Ro7Fna1IVxleWNzXJ/YkcNJt5BLmHHsocFwdEf8hixY+C0xPrySbTyoN/ZoHlX3HYgh3J1H+mayGzMJLP8a+ZFDDzBJsomy8b7DvAStRSAs0i3DD/s+Y/0RDaeP++2y+xG8eEJLkF0vhpuRLHCGaLY6MT1bWPGxROiGSDu877y2H/9tIaByvBUqqau0tk2CM26LhOUig/maB50s+WFD1fnXRHQMj3XQiMh6L5HNd7qfntAgvleZ+xDHVsRpN3agKXKw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fBeJCbgxaAyLeBYJ1WxdC5gReHzTab06dZAagJ453To=;
 b=cSbCJ0aJ3+XOGoOOvAVNDaVDLGB8WjFnQsDHzRVdB3Co2Ld4KLNlLIpjfk3OfMOk2v4O4auGQHFuq+7AoWyX9DPyetb/GQDYh22Gj/MDgfvGByl0VPsGNIvGSs9Agj2KnBy4PSP/OuYIdXjv11VuSE4XmrVyz5/3LdszJQvdy4SAI+MFXYJkb75he6gFtr9sxa3mylNhPLCl1HpGEb50fMVhFV3WFIAmxZ/uIZ+Y/yIAzLjrdDlXWaKmOT9l0Ph3t9yg2N+LgGOOxoMdxv4EInWIFIrS4MAgP4x7aQ17XyzYQQgKk/lGCMWlj3zI6rYp+8a/TXKZjYFLZA4juUXFjQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=minervasys.tech smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=fBeJCbgxaAyLeBYJ1WxdC5gReHzTab06dZAagJ453To=;
 b=c3p1nqZF+GzMPNPR5kDitdXDdj9JyBsH91Cpq3OQWSDP//xzXO+yFImqyqetSPVpdPk2ffw6mcE4PKFCI1LaZSisPxnvReyHaK/ZVlX+ontL/PuZL4TPdfjg7bgHKSSUcVvEwapESv/6cJOFXHkVhEWmRHASkXSxyFQtMzGRQwA=
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=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Mon, 16 Dec 2024 13:08:28 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v12 03/12] xen/arm: permit non direct-mapped Dom0
 construction
To: Carlo Nonato ,
	
CC: , ,
	"Stefano Stabellini" , Julien Grall ,
	"Bertrand Marquis" , Volodymyr Babchuk
	
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-4-carlo.nonato@minervasys.tech>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <20241213162815.9196-4-carlo.nonato@minervasys.tech>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D7:EE_|CH2PR12MB9493:EE_
X-MS-Office365-Filtering-Correlation-Id: 2f7fde1e-b15c-48a6-bc48-08dd1dca5baa
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?RUUvc3pUMUxJUEphZGlSa1FBZVd3V2pTWDByY29vL2htMzJjWkJPT1RPUVJL?=
 =?utf-8?B?Vk5zQzNOYUtwV091dDFtcThhZ3JFamRBSlcrNy9ZZXgxNnhRNE02Uno5eVJ0?=
 =?utf-8?B?cEY1cHg0UmlsUnVLb2wzMzNLMFYrMEdaUEs3Y2d0a0JGNUhsN1FvTmVDSXRY?=
 =?utf-8?B?VHM5em1RWjRKUnNCbDFnTnVnVUZyT1NhbXFGMVgyUmd5NHlXUnBqT3M3dlhi?=
 =?utf-8?B?bzlHK2orbS8wUTRSRk1uYzM3K2d3UWNMV2VMbmtZSUlQUTJYSUtDNDVWTVdZ?=
 =?utf-8?B?OHF2YmxVd2ovZTR5RDVqT3NxcjNDZ2l0emZOZEU0OExHclY3MnBjU2hGUjNr?=
 =?utf-8?B?RnNkRkl3Yk5vY3lDQ1l3OEE2aStsc3dDcmt1dWQvb0FHN0laQ295ZDI5NEw4?=
 =?utf-8?B?Y2JrWXRlUlZzWHNCR1RHcDNYNVczRFI5NnFuRnljRUZzQUNpdTlrSWRTdEY0?=
 =?utf-8?B?VGlad3ZZcFZ5ek5XMFZkRmhqNkVzT0kxQXh1OUFrZDJ3SkJNdGFUT0VYOFBN?=
 =?utf-8?B?VVdrTWRBeDJwRStMWmc0L2pTVjg5N3lQYnArd094YUplVjMwVnhiVmpRVTZO?=
 =?utf-8?B?RS9nY0tINkwxdElWQVhCcEdkdEJReE5LU3dRdHYwajI2WjBrbFMyREtTb3Fr?=
 =?utf-8?B?dzVyUmlXVUcvU3J1emUzSkxva09Gc0FmNm96WXp1Y1ZOT0VXNUtWQU9ReXdq?=
 =?utf-8?B?NU81L3NiTG5uNGpDSkNYUWNFYVJWZENOQ3pQdlpWSytrM3Bnd1Joa2VjUjZw?=
 =?utf-8?B?WFgzYTFDNWRkdXVXZTZiSE1XN3VpcVErWnJ5U003V09iNm9aaUxZM0pEcmRU?=
 =?utf-8?B?bzRjazlmamVydXQ3bWYvYjV0UC9vK2haNm1vclF1a0RmVG1nUGd2MUV3RXNi?=
 =?utf-8?B?ak96U2UyVVNWRVNBSEs5eFB0WmtIS1NOdC90YXUrSlk2akpodDU4QkxkdjZI?=
 =?utf-8?B?TEJlM2F0OHZJdTdNcExNV0tYTG0xWW00RDA2Ykk0Q215R2x5bzlrb3Z5dTB3?=
 =?utf-8?B?YkIrbkxOdEF6eVRuVmhuZTRLVzR4eTBJSzJ6R2xMN3h2K0JGeVJmbFA1SnVG?=
 =?utf-8?B?UlRvcnVHVkY0Q281bktzRk5KWHMrMmRyUWhZb3Q0Ynd3c282QkNDMU1xUDFj?=
 =?utf-8?B?cUhHb3RhY0lqTFA1NWU5UUdJTjNjNEtQdHlkR3E3YXdJSEFQL3l6ekJ1NjVp?=
 =?utf-8?B?QWR0eDNkay90YnY5RnhLSTBqQ0IvRWFOLzY1MUhYank3YU5WZWJGang4WHA0?=
 =?utf-8?B?NnV2T0oxUmVoYWkwclluTG9KNW9zYnNhK250ZnQwVS8zN3ZhbzlvTjM4Nzhs?=
 =?utf-8?B?bVphNXdsVUp2SVFEYWdDbXBqcUszZEtaYXhGR3Vrc2NORnNockNLOVF0a2pE?=
 =?utf-8?B?cVpUMXVrQ2xHZmxVK2pVQVRmdkptMEJDUUVCS0FwWEwvSU9vc09LdEhUbGlJ?=
 =?utf-8?B?R3RzUG1SS1NPSlJldzJFbk00akgrZk52M1RpVXRaT2tZT3ExL29DaWZtQVJv?=
 =?utf-8?B?bWs5ampML2pQUFN5L21ZTE56WDNRR0VxNWVsT3ZjU3d3bmRIVEpROUJvaXBs?=
 =?utf-8?B?VmFIRzhJbVlFV0xNM0pSb3lCTDhOaDB1N0dqaHZLOThLTHhXdHhYcFpZVitM?=
 =?utf-8?B?YzhybFRMbEFXc3grem9mZmQxbEtnM1RQVTk5T3VyazNkMjhkZnZHMjFnazJ5?=
 =?utf-8?B?NnVGZkQ2d29hM2Yva0VxeENuVjNRZ29VcUJ2L3pOcW9CWUt6L25ha0VtSHRh?=
 =?utf-8?B?bXVSRk1qV09qMDM4enAzN0txN2g5YWRIbnR3MW12WUxYQ2ptNklRd3lySDFo?=
 =?utf-8?B?dWxIMGFZdk5tMTBjSzdUUGIxZW9kTk9wcjlhR1lNd3JpRHN3WWlkYUNubGZ4?=
 =?utf-8?B?cVJudVJYaFEyNytJSW52dGxvTnl2UUtPYXhZMWh3ZWVtTVRENlR0Q1lTOEw1?=
 =?utf-8?B?dWN3aXh5bUtCaitIVmE3MEpPTVQ5OXd0OHF4QnVHTTh1WkRYNkhORHNQeW1m?=
 =?utf-8?Q?3gHFrSSo1NNh20b2tG1A14oR4Rgr3E=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Dec 2024 12:08:31.3275
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2f7fde1e-b15c-48a6-bc48-08dd1dca5baa
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000E9D7.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB9493



On 13/12/2024 17:28, Carlo Nonato wrote:
> 
> 
> Cache coloring requires Dom0 not to be direct-mapped because of its non
> contiguous mapping nature, so allocate_memory() is needed in this case.
> 8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a separate module")
> moved allocate_memory() in dom0less_build.c. In order to use it
> in Dom0 construction bring it back to domain_build.c and declare it in
> domain_build.h.
> 
> Adapt the implementation of allocate_memory() so that it uses the host
> layout when called on the hwdom, via find_unallocated_memory(). Take the
> opportunity to keep the parameter order consistent with
> rangeset_report_ranges() and move the membanks struct after the callback
> function in find_unallocated_memory().
Why? What benefit does this change (that is irrelevant to the goal of this patch) provide?

> 
> Introduce add_hwdom_free_regions() callback to add hwdom banks in descending
> order.
> 
> Signed-off-by: Carlo Nonato 
> ---
> v12:
> - used the new generic find_unallocated_memory()
> - added add_hwdom_free_regions() callback
> v11:
> - GUEST_RAM_BANKS instead of hardcoding the number of banks in allocate_memory()
> - hwdom_ext_regions -> hwdom_free_mem in allocate_memory()
> - added a comment in allocate_memory() when skipping small banks
> v10:
> - fixed a compilation bug that happened when dom0less support was disabled
> v9:
> - no changes
> v8:
> - patch adapted to new changes to allocate_memory()
> v7:
> - allocate_memory() now uses the host layout when called on the hwdom
> v6:
> - new patch
> ---
>  xen/arch/arm/dom0less-build.c           |  44 -------
>  xen/arch/arm/domain_build.c             | 164 +++++++++++++++++++++++-
>  xen/arch/arm/include/asm/domain_build.h |   4 +
>  3 files changed, 161 insertions(+), 51 deletions(-)
> 
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index d93a85434e..67b1503647 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -49,50 +49,6 @@ bool __init is_dom0less_mode(void)
>      return ( !dom0found && domUfound );
>  }
> 
> -static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
> -{
> -    struct membanks *mem = kernel_info_get_mem(kinfo);
> -    unsigned int i;
> -    paddr_t bank_size;
> -
> -    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
> -           /* Don't want format this as PRIpaddr (16 digit hex) */
> -           (unsigned long)(kinfo->unassigned_mem >> 20), d);
> -
> -    mem->nr_banks = 0;
> -    bank_size = MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem);
> -    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM0_BASE),
> -                               bank_size) )
> -        goto fail;
> -
> -    bank_size = MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem);
> -    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM1_BASE),
> -                               bank_size) )
> -        goto fail;
> -
> -    if ( kinfo->unassigned_mem )
> -        goto fail;
> -
> -    for( i = 0; i < mem->nr_banks; i++ )
> -    {
> -        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
> -               d,
> -               i,
> -               mem->bank[i].start,
> -               mem->bank[i].start + mem->bank[i].size,
> -               /* Don't want format this as PRIpaddr (16 digit hex) */
> -               (unsigned long)(mem->bank[i].size >> 20));
> -    }
> -
> -    return;
> -
> -fail:
> -    panic("Failed to allocate requested domain memory."
> -          /* Don't want format this as PRIpaddr (16 digit hex) */
> -          " %ldKB unallocated. Fix the VMs configurations.\n",
> -          (unsigned long)kinfo->unassigned_mem >> 10);
> -}
> -
>  #ifdef CONFIG_VGICV2
>  static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
>  {
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index adf26f2778..bfcff99194 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2,6 +2,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -416,7 +417,6 @@ static void __init allocate_memory_11(struct domain *d,
>      }
>  }
> 
> -#ifdef CONFIG_DOM0LESS_BOOT
>  bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size,
>                                      alloc_domheap_mem_cb cb, void *extra)
>  {
> @@ -508,7 +508,6 @@ bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
> 
>      return true;
>  }
> -#endif
> 
>  /*
>   * When PCI passthrough is available we want to keep the
> @@ -900,6 +899,52 @@ int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
>      return 0;
>  }
> 
> +static int __init add_hwdom_free_regions(unsigned long s_gfn,
> +                                         unsigned long e_gfn, void *data)
> +{
> +    struct membanks *free_regions = data;
> +    paddr_t start, size;
> +    paddr_t s = pfn_to_paddr(s_gfn);
> +    paddr_t e = pfn_to_paddr(e_gfn);
> +    unsigned int i, j;
> +
> +    if ( free_regions->nr_banks >= free_regions->max_banks )
> +        return 0;
> +
> +    /*
> +     * Both start and size of the free region should be 2MB aligned to
> +     * potentially allow superpage mapping.
> +     */
> +    start = (s + SZ_2M - 1) & ~(SZ_2M - 1);
> +    if ( start > e )
> +        return 0;
> +
> +    /*
> +     * e is actually "end-1" because it is called by rangeset functions
> +     * which are inclusive of the last address.
> +     */
> +    e += 1;
> +    size = (e - start) & ~(SZ_2M - 1);
> +
> +    /* Find the insert position (descending order). */
> +    for ( i = 0; i < free_regions->nr_banks ; i++)
CODING_STYLE:
for ( i = 0; i < free_regions->nr_banks; i++ )

> +        if ( size > free_regions->bank[i].size )
> +            break;
> +
> +    /* Move the other banks to make space. */
> +    for ( j = free_regions->nr_banks; j > i ; j-- )
> +    {
> +        free_regions->bank[j].start = free_regions->bank[j - 1].start;
> +        free_regions->bank[j].size = free_regions->bank[j - 1].size;
> +    }
> +
> +    free_regions->bank[i].start = start;
> +    free_regions->bank[i].size = size;
> +    free_regions->nr_banks++;
The algorithm looks good. In my head I thought you will use sort() after adding all the banks, but
I'm not sure which solution is more efficient. Probably yours and it avoids implementing cmp and swap functions.

> +
> +    return 0;
> +}
> +
>  /*
>   * Find unused regions of Host address space which can be exposed to domain
>   * using the host memory layout. In order to calculate regions we exclude every
> @@ -908,10 +953,10 @@ int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
>  static int __init find_unallocated_memory(const struct kernel_info *kinfo,
>                                            const struct membanks *mem_banks[],
>                                            unsigned int nr_mem_banks,
> -                                          struct membanks *free_regions,
>                                            int (*cb)(unsigned long s_gfn,
>                                                      unsigned long e_gfn,
> -                                                    void *data))
> +                                                    void *data),
> +                                          struct membanks *free_regions)
>  {
>      const struct membanks *mem = bootinfo_get_mem();
>      struct rangeset *unalloc_mem;
> @@ -977,6 +1022,108 @@ out:
>      return res;
>  }
> 
> +void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
> +{
> +    struct membanks *mem = kernel_info_get_mem(kinfo);
> +    unsigned int i, nr_banks = GUEST_RAM_BANKS;
> +    struct membanks *hwdom_free_mem = NULL;
> +
> +    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
> +           /* Don't want format this as PRIpaddr (16 digit hex) */
> +           (unsigned long)(kinfo->unassigned_mem >> 20), d);
> +
> +    mem->nr_banks = 0;
> +    /*
> +     * Use host memory layout for hwdom. Only case for this is when LLC coloring
> +     * is enabled.
> +     */
> +    if ( is_hardware_domain(d) )
> +    {
> +        struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1);
> +        /*
> +         * Exclude the following regions:
> +         * 1) Remove reserved memory
> +         * 2) Grant table assigned to Dom0
Can we not mention 'Dom0'? In the future hwdom may not necessarily be dom0. Especially that
in other places you mention hwdom.

> +         */
> +        const struct membanks *mem_banks[] = {
> +            bootinfo_get_reserved_mem(),
> +            gnttab,
> +        };
> +
> +        ASSERT(llc_coloring_enabled);
Remove this assert. There's nothing LLC special here and this could be re-used in the future
to provide non 1:1 hwdom.

> +
> +        if ( !gnttab )
> +            goto fail;
> +
> +        gnttab->nr_banks = 1;
> +        gnttab->bank[0].start = kinfo->gnttab_start;
> +        gnttab->bank[0].size = kinfo->gnttab_start + kinfo->gnttab_size;
Incorrect. You assign to 'end' to'size'. It should simply be:
gnttab->bank[0].size = kinfo->gnttab_size.

> +
> +        hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank,
> +                                             NR_MEM_BANKS);
> +        if ( !hwdom_free_mem )
> +            goto fail;
> +
> +        hwdom_free_mem->max_banks = NR_MEM_BANKS;
> +
> +        if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
> +                                     add_hwdom_free_regions, hwdom_free_mem) )
> +            goto fail;
> +
> +        nr_banks = hwdom_free_mem->nr_banks;
> +        xfree(gnttab);
> +    }
> +
> +    for ( i = 0; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_banks-- )
> +    {
> +        paddr_t bank_start, bank_size;
> +
> +        if ( is_hardware_domain(d) )
> +        {
> +            bank_start = hwdom_free_mem->bank[i].start;
> +            bank_size = hwdom_free_mem->bank[i].size;
> +        }
> +        else
> +        {
> +            const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
> +            const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
> +
> +            if ( i >= GUEST_RAM_BANKS )
> +                goto fail;
> +
> +            bank_start = bankbase[i];
> +            bank_size = banksize[i];
> +        }
> +
> +        bank_size = MIN(bank_size, kinfo->unassigned_mem);
> +        if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(bank_start), bank_size) )
> +            goto fail;
> +    }
> +
> +    if ( kinfo->unassigned_mem )
> +        goto fail;
> +
> +    for( i = 0; i < mem->nr_banks; i++ )
> +    {
> +        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
> +               d,
> +               i,
> +               mem->bank[i].start,
> +               mem->bank[i].start + mem->bank[i].size,
> +               /* Don't want format this as PRIpaddr (16 digit hex) */
> +               (unsigned long)(mem->bank[i].size >> 20));
> +    }
> +
> +    xfree(hwdom_free_mem);
> +    return;
> +
> +fail:
> +    panic("Failed to allocate requested domain memory."
> +          /* Don't want format this as PRIpaddr (16 digit hex) */
> +          " %ldKB unallocated. Fix the VMs configurations.\n",
> +          (unsigned long)kinfo->unassigned_mem >> 10);
> +}
> +
>  static int __init handle_pci_range(const struct dt_device_node *dev,
>                                     uint64_t addr, uint64_t len, void *data)
>  {
> @@ -1176,7 +1323,7 @@ static int __init find_host_extended_regions(const struct kernel_info *kinfo,
>      gnttab->bank[0].size = kinfo->gnttab_size;
> 
>      res = find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
> -                                  ext_regions, add_ext_regions);
> +                                  add_ext_regions, ext_regions);
>      xfree(gnttab);
> 
>      return res;
> @@ -1235,7 +1382,7 @@ int __init make_hypervisor_node(struct domain *d,
> 
>          ext_regions->max_banks = NR_MEM_BANKS;
> 
> -        if ( is_domain_direct_mapped(d) )
> +        if ( domain_use_host_layout(d) )
>          {
>              if ( !is_iommu_enabled(d) )
>                  res = find_host_extended_regions(kinfo, ext_regions);
> @@ -2164,8 +2311,11 @@ static int __init construct_dom0(struct domain *d)
>      /* type must be set before allocate_memory */
>      d->arch.type = kinfo.type;
>  #endif
> -    allocate_memory_11(d, &kinfo);
>      find_gnttab_region(d, &kinfo);
This re-ordering should be mentioned in commit msg.

> +    if ( is_domain_direct_mapped(d) )
> +        allocate_memory_11(d, &kinfo);
> +    else
> +        allocate_memory(d, &kinfo);
> 
>      rc = process_shm_chosen(d, &kinfo);
>      if ( rc < 0 )
> diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h
> index e712afbc7f..b0d646e173 100644
> --- a/xen/arch/arm/include/asm/domain_build.h
> +++ b/xen/arch/arm/include/asm/domain_build.h
> @@ -11,6 +11,7 @@ bool allocate_domheap_memory(struct domain *d, paddr_t tot_size,
>                               alloc_domheap_mem_cb cb, void *extra);
>  bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
>                            paddr_t tot_size);
> +void allocate_memory(struct domain *d, struct kernel_info *kinfo);
>  int construct_domain(struct domain *d, struct kernel_info *kinfo);
>  int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
>  int make_chosen_node(const struct kernel_info *kinfo);
> @@ -54,6 +55,9 @@ static inline int prepare_acpi(struct domain *d, struct kernel_info *kinfo)
>  int prepare_acpi(struct domain *d, struct kernel_info *kinfo);
>  #endif
> 
> +typedef int (*add_free_regions_fn)(unsigned long s_gfn, unsigned long e_gfn,
> +                                   void *data);
Random code? Remove.

With the remarks addressed:
Reviewed-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 12:09:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 12:09:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857916.1270112 (Exim 4.92)
	(envelope-from )
	id 1tN9ux-0006YI-VE; Mon, 16 Dec 2024 12:09:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857916.1270112; Mon, 16 Dec 2024 12:09: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 1tN9ux-0006YB-Sb; Mon, 16 Dec 2024 12:09:43 +0000
Received: by outflank-mailman (input) for mailman id 857916;
 Mon, 16 Dec 2024 12:09: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 1tN9uw-0006Xz-FG
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 12:09:42 +0000
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
 [2a00:1450:4864:20::42f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a07c8d90-bba6-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 13:09:40 +0100 (CET)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3862d16b4f5so2587576f8f.0
 for ; Mon, 16 Dec 2024 04:09:40 -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-388c8046c66sm7901431f8f.69.2024.12.16.04.09.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 04:09: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: a07c8d90-bba6-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734350980; x=1734955780; 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=NQnigSnboxqD5iDFE6IApJJq+eundlOUjIfEVV3vn5Y=;
        b=KVZ3MVLqnssDr/iSRR871noFE4fxwCc60KehVqXJDanIaN5YI1ztviNWdBri2z/tlS
         2tyoLReOTGJfkSKCx5AA8zBH/9FMioFwZJyod8rKrLfsqY7gAIssbMu6anOa29R4od1b
         xfaPd+XuodA4/sJU6qafoN6SXuCAh9BJGW+Wip3BsESGYSloM9ZUBAhrMaIGBeraNzrk
         avEixJDaFig+LCeAkZFviyERZGPa2X95GcS2w9RtKw5lD8phQFS6oBTy2cgJH1qb9M27
         tEL8TIpb9G8UdgDTmURw2BFIzJWCmnwOU/tFPVe/41iILVePD1LFBEPwIaOP/YSDDTS8
         CKbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734350980; x=1734955780;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NQnigSnboxqD5iDFE6IApJJq+eundlOUjIfEVV3vn5Y=;
        b=mfCnV0tPpOkavv34uv5SneWzGad16mYUc4fmaa1UqyAAXy2WwA059Pw5KOzq0nwcyJ
         27fcFbWMYcydDA2g5xv0Y73Oa4zwLxM5Ir3t2bOZ3/hpoY6vTWapm+jp/aHKy9CCeuFM
         SRWqjYmAEuBQXSzXeVScvTvnveUzf16L70HweotEFtLPgfxvoqqdW6UDaiACZBAWNE9D
         yKPa44q8sUmemB3zjUKng4psvMMix9J93h1nnaQwyO3mThU3M5zVfNi08ua+EQNpFuhx
         0DDGl9DrSk5ixm5ywhY6pLkfkBDsqszh1RZ6uBOrosiCrUcFbCrrWKHto0bejPLTHqLU
         hw2g==
X-Forwarded-Encrypted: i=1; AJvYcCWxcvcp/BLgRKPiASZwYIPjPjaMPEL/RjlUjkzy5kPX2gsPRKgBZoXMQ1X9rhiP5vcqxuPDkoLQhU4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwRQi6qyrUJ03DroRL+GMXx8jagXzV8Mvsn+vs+Ot73Dk5svxza
	3XdWxb8qs/c23FqYqj5l+lh3UcbKPwDUvR/iIKkVVKcO1WING9pQHJSxQYHRxg==
X-Gm-Gg: ASbGnctecfSAA92h2UaOsfJPdtWczvZm1NN2q+I8r2WqiYeN9MpQApBRxG5dsUn0drD
	HapSodfJ8jUVQ4fCqpqGzw5f9tGBOrHUlvwdnZtKPDu6KYCGpEfemM1gWO0Mq1jJVbb2u1qVgGo
	BvezlChnsXeyjnCvoHPgdjfHxYs1zU2zTTH2xELx/X85mKwKviKUf9lGiGktyLJV+aodr/ACRmH
	si9vGrCO8Kh3pDC4KLu8VGEa1VlUjDuKcbEqbSJs/1MaDxvZzIgV1K/KawC8hyIqACC5inWUPV/
	fFgYw+6Ez0EdGc+nUnJhsdCtRHRpwbW3L0ebdXQScw==
X-Google-Smtp-Source: AGHT+IGDfP0Muq9PSPjw8m3623M/pAP5vBF5akTRg4GLlPJ06gWKbMgsXbsFD9SxOSN77KGktMwIbg==
X-Received: by 2002:a5d:5f50:0:b0:385:e95b:bb46 with SMTP id ffacd0b85a97d-388c3a7dd8bmr8604839f8f.22.1734350979971;
        Mon, 16 Dec 2024 04:09:39 -0800 (PST)
Message-ID: <92fdf726-504b-4d3b-8043-d736b275d8d0@suse.com>
Date: Mon, 16 Dec 2024 13:09:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tools/misc: Drop xensymoops
To: Andrew Cooper 
Cc: Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Ariel Otilibili ,
 Xen-devel 
References: <20241216120359.10469-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: <20241216120359.10469-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.12.2024 13:03, Andrew Cooper wrote:
> This script is not referenced by the build system, and has escaped all Python
> compatibility work; it's still using print statements.
> 
> Also, the regex it uses ties it to a 32bit build of Xen, which was dropped in
> Xen 4.3, 11 years ago.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Mon Dec 16 12:12:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 12:12:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857935.1270141 (Exim 4.92)
	(envelope-from )
	id 1tN9x9-0000FK-G5; Mon, 16 Dec 2024 12:11:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857935.1270141; Mon, 16 Dec 2024 12:11: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 1tN9x9-0000FD-DR; Mon, 16 Dec 2024 12:11:59 +0000
Received: by outflank-mailman (input) for mailman id 857935;
 Mon, 16 Dec 2024 12:11: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 1tN9x8-0000Dw-Ik
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 12:11:58 +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 f162d51f-bba6-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 13:11:56 +0100 (CET)
Received: by mail-wr1-x429.google.com with SMTP id
 ffacd0b85a97d-385e27c75f4so3150169f8f.2
 for ; Mon, 16 Dec 2024 04:11: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
 ffacd0b85a97d-388c8012029sm7942524f8f.12.2024.12.16.04.11.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 04:11: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: f162d51f-bba6-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734351115; x=1734955915; 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=Xk1JxjITef4yyd7NZvmgldkO/CBQtbZWwymd3Qndhlc=;
        b=X2QNHOoL4bT9rXfaXtSXCFDu0FR5VU+jwKkb1kNTeEbc86sJ1JuteAup96umFf9zxh
         wjGQk+EfdbezGjexhxWiFutYA1fc5d8pYhwE1nbfSVU8ogkCwzIJEztdd++ivALgcmVe
         zsVtnLKok8XT0T4xvM2e01GvOh6MGWz+57qGHYN8uxWQ94LAJ/vpbYNnT5IF1o64BflW
         pvFj2t/ipqlsnnApcq/YH20JTR0OkQy+Lxb5aSvHjYafQAAvYSrTGxM0rHkUZ/c3FCE8
         Mz2XxJYfwK/St3yV/q5dDClCLQXwNZg1Mv3zgZLNeZ5nSDAjVewTprJQ11YMN1nab3Cg
         2mvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734351116; x=1734955916;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Xk1JxjITef4yyd7NZvmgldkO/CBQtbZWwymd3Qndhlc=;
        b=fxQvHcncThCUR3ELfSbXvnlrWwu3QoU4Mk1QzrQxjGdXy5QBzcFio23lHVmAhSyGjY
         1eLFoi8l7KHkopmNVYKtsXbXSLlphR5L3p3dfpJ8DkHuL0wFVjd7E2YhtcSve+F0NPi5
         eRGtAJnsGv7GQFx68rExd7zXm2ABw4NFWnqt/1tuwDokB2oKYa3+3a1ZxyX8o2EHD5cg
         lzJmtcLnYpBWFhb5rY+SWkExpRjb7mzqVDogp+WNHA52y8wh+5y1e9q6+Kjsp9gBxV7F
         7q+Pxf1vfsI03Bx+On7bHamSqKkMJHMVsO0kmt28PnP/WgVvSijfVUM1coSxmNaMYxPB
         qKJQ==
X-Forwarded-Encrypted: i=1; AJvYcCUKviMn+3cAKbeCKbpNAhAYoodtCYZf204rjB+nJoxmsEdN4mA+8z3ypKhjIrFDlJxyiSGNabqO8Kk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwIuIDx3wYJwXqbZKkzq3Z3VXG+PBpZxayG57k+BC4KsTNhv2JX
	mTAtyFdWk0scXpzleRpny3kLT+hl/frxsm3eYYJvSGVpvgQTKM1fJeEVU5lnJvxYH4GuxKsLCv0
	=
X-Gm-Gg: ASbGnctuhZHhVRhl9WhT65BNrmbqbGl9HSEnKXfeOgJUpHOo1RysuL51rGAQoBrjWAJ
	hrUs9ObjNWoONCKJTpTxLseznG0M9t1lb9FDD/fJjyLiCkBkOB8HCI0mwSFLh4FIfbe/eZGaw4n
	Aub0JHRkQpNfV80kQT650ytXQxslw6OwhqMMdPGuRU0esXY4s91zxPukKbNnKOXgB9aP7bdnOtP
	+vqqZahlt8OR4NSSAxGHmNBuE5Nnq31VD5cQKTrvv20EA0EowmFRQW+CU7JY9sQ0qdz0kHmoWcA
	gklADJfJVhBE8wVzlxUjOsF8loDhC6l/LYfy3E6bYw==
X-Google-Smtp-Source: AGHT+IHdmYiEr5wNj/uhmm2ZeWD3ydlCKITwq2Na+NlaXalUh61C04XRUhyguZP/3TUy/BYGIu9NQQ==
X-Received: by 2002:a05:6000:2a5:b0:385:f840:e630 with SMTP id ffacd0b85a97d-3888e0b9bc0mr7748078f8f.37.1734351115653;
        Mon, 16 Dec 2024 04:11:55 -0800 (PST)
Message-ID: <4360dd9d-049d-462f-9c15-16a73a4027a1@suse.com>
Date: Mon, 16 Dec 2024 13:11:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v12 03/12] xen/arm: permit non direct-mapped Dom0
 construction
To: Michal Orzel ,
 Carlo Nonato 
Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 xen-devel@lists.xenproject.org
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-4-carlo.nonato@minervasys.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 16.12.2024 13:08, Michal Orzel wrote:
> On 13/12/2024 17:28, Carlo Nonato wrote:
>> @@ -977,6 +1022,108 @@ out:
>>      return res;
>>  }
>>
>> +void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
>> +{
>> +    struct membanks *mem = kernel_info_get_mem(kinfo);
>> +    unsigned int i, nr_banks = GUEST_RAM_BANKS;
>> +    struct membanks *hwdom_free_mem = NULL;
>> +
>> +    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
>> +           /* Don't want format this as PRIpaddr (16 digit hex) */
>> +           (unsigned long)(kinfo->unassigned_mem >> 20), d);
>> +
>> +    mem->nr_banks = 0;
>> +    /*
>> +     * Use host memory layout for hwdom. Only case for this is when LLC coloring
>> +     * is enabled.
>> +     */
>> +    if ( is_hardware_domain(d) )
>> +    {
>> +        struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1);
>> +        /*
>> +         * Exclude the following regions:
>> +         * 1) Remove reserved memory
>> +         * 2) Grant table assigned to Dom0
> Can we not mention 'Dom0'? In the future hwdom may not necessarily be dom0. Especially that
> in other places you mention hwdom.
> 
>> +         */
>> +        const struct membanks *mem_banks[] = {
>> +            bootinfo_get_reserved_mem(),
>> +            gnttab,
>> +        };
>> +
>> +        ASSERT(llc_coloring_enabled);
> Remove this assert. There's nothing LLC special here and this could be re-used in the future
> to provide non 1:1 hwdom.
> 
>> +
>> +        if ( !gnttab )
>> +            goto fail;
>> +
>> +        gnttab->nr_banks = 1;
>> +        gnttab->bank[0].start = kinfo->gnttab_start;
>> +        gnttab->bank[0].size = kinfo->gnttab_start + kinfo->gnttab_size;
> Incorrect. You assign to 'end' to'size'. It should simply be:
> gnttab->bank[0].size = kinfo->gnttab_size.
> 
>> +
>> +        hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank,
>> +                                             NR_MEM_BANKS);
>> +        if ( !hwdom_free_mem )
>> +            goto fail;
>> +
>> +        hwdom_free_mem->max_banks = NR_MEM_BANKS;
>> +
>> +        if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
>> +                                     add_hwdom_free_regions, hwdom_free_mem) )
>> +            goto fail;
>> +
>> +        nr_banks = hwdom_free_mem->nr_banks;
>> +        xfree(gnttab);
>> +    }
>> +
>> +    for ( i = 0; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_banks-- )
>> +    {
>> +        paddr_t bank_start, bank_size;
>> +
>> +        if ( is_hardware_domain(d) )
>> +        {
>> +            bank_start = hwdom_free_mem->bank[i].start;
>> +            bank_size = hwdom_free_mem->bank[i].size;
>> +        }
>> +        else
>> +        {
>> +            const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
>> +            const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
>> +
>> +            if ( i >= GUEST_RAM_BANKS )
>> +                goto fail;
>> +
>> +            bank_start = bankbase[i];
>> +            bank_size = banksize[i];
>> +        }
>> +
>> +        bank_size = MIN(bank_size, kinfo->unassigned_mem);
>> +        if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(bank_start), bank_size) )
>> +            goto fail;
>> +    }
>> +
>> +    if ( kinfo->unassigned_mem )
>> +        goto fail;
>> +
>> +    for( i = 0; i < mem->nr_banks; i++ )
>> +    {
>> +        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
>> +               d,
>> +               i,
>> +               mem->bank[i].start,
>> +               mem->bank[i].start + mem->bank[i].size,
>> +               /* Don't want format this as PRIpaddr (16 digit hex) */
>> +               (unsigned long)(mem->bank[i].size >> 20));
>> +    }
>> +
>> +    xfree(hwdom_free_mem);
>> +    return;
>> +
>> +fail:

Nit: Style (missing indentation).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 12:19:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 12:19:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857945.1270152 (Exim 4.92)
	(envelope-from )
	id 1tNA4R-0001A8-7X; Mon, 16 Dec 2024 12:19:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857945.1270152; Mon, 16 Dec 2024 12:19:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNA4R-0001A1-4k; Mon, 16 Dec 2024 12:19:31 +0000
Received: by outflank-mailman (input) for mailman id 857945;
 Mon, 16 Dec 2024 12:19:29 +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 1tNA4P-00019c-Ms
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 12:19:29 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fdfa2978-bba7-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 13:19:27 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 16 Dec 2024 13:19:26 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fdfa2978-bba7-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734351567; x=1765887567;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=Ph989u006BDdQWYK2SGOsfoX14BuAnh6WrlmLplCcGM=;
  b=STCm6dSU6TkyupcdKpAcaIhKvNb4z2D6hQGLmHppcTna9BYobU1kZ5ja
   OKKRHq28V6Fm0wRkBeTQYCtFqM7JagsCak3zeVeWif4KRbY62xIbB/m+z
   63SW7f0Ak21nUbB9JJ6MPxAdJSt8fv0b+nXu+pDW7YCeNPUBbafOg0FnR
   o=;
X-CSE-ConnectionGUID: GPYmMVXFRJqJqD7wRLk8Gg==
X-CSE-MsgGUID: A+l9iTLMTwiswfry1jlgEw==
X-IronPort-AV: E=Sophos;i="6.12,238,1728943200"; 
   d="scan'208";a="28195922"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: <3f3e9a77-5695-4c91-9fc2-11a3c21605c5@suse.com>
Content-Type: text/plain; charset="utf-8"
X-Forward: 149.5.228.1
References: <20241215154659.151158-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241215154659.151158-2-Ariel.Otilibili-Anieli@eurecom.fr>
 <5599dc89-0fa4-4255-b4a1-5b81e151d8c7@suse.com>
 <2f7a85-67600280-e411-38ee5c40@258420856>
 
 <2f7a86-67600f80-8b81-26131fc0@216081513> <3f3e9a77-5695-4c91-9fc2-11a3c21605c5@suse.com>
Date: Mon, 16 Dec 2024 13:19:26 +0100
Cc: xen-devel@lists.xenproject.org, "Anthony PERARD" 
To: "Jan Beulich" 
MIME-Version: 1.0
Message-ID: <2f7a86-67601b00-8b99-26131fc0@216117285>
Subject: =?utf-8?q?Re=3A?= [PATCH 1/1] =?utf-8?q?tools/libacpi=3A?= clear ASL 
 warning about PCI0
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 3664

On Monday, December 16, 2024 12:38 CET, Jan Beulich =
 wrote:

> On 16.12.2024 12:31, Ariel Otilibili-Anieli wrote:
> > On Monday, December 16, 2024 12:01 CET, Jan Beulich  wrote:
> >=20
> >> On 16.12.2024 11:36, Ariel Otilibili-Anieli wrote:
> >>> On Monday, December 16, 2024 10:53 CET, Jan Beulich  wrote:
> >>>
> >>>> On 15.12.2024 16:40, Ariel Otilibili wrote:
> >>>>> * iasl complains =5FHID and =5FADR cannot be used at the same t=
ime
> >>>>>
> >>>>> ```
> >>>>> /usr/bin/iasl -vs -p tools/firmware/hvmloader/dsdt=5Fanycpu.tmp=
 -tc tools/firmware/hvmloader/dsdt=5Fanycpu.asl 2>&1 | grep -B10 HID
> >>>>> tools/firmware/hvmloader/dsdt=5Fanycpu.asl     40:        Devic=
e (PCI0)
> >>>>> Warning  3073 -                                    Multiple typ=
es ^  (Device object requires either a =5FHID or =5FADR, but not both)
> >>>>> ```
> >>>>>
> >>>>> * generally =5FHID devices are enumerated and have their driver=
s loaded by ACPI
> >>>>> * this is from "ASL 2.0 Introduction and Overview" (page 4).
> >>>>> * removing =5FADR, the warning is cleared out.
> >>>>
> >>>> Okay, that's the positive aspect. Yet what about the potential f=
allout thereof?
> >>>> Can you confirm that there's no risk of regressions with older g=
uest OSes, for
> >>>> example?
> >>>
> >>> OSes that were released after ACPI 2.0 should work [1]; including=
 WinXP:=20
> >>> The 2.0 specs says either =5FHID or =5FADR should be included [2]=
, not both (Section 6.1, page 146).
> >>
> >> We must be looking at two different variants of the spec then. My =
copy says
> >> "device object must contain either an =5FHID object or an =5FADR o=
bject, but can
> >> contain both." Also still in 2.0c. I agree that in e.g. 6.5 the wo=
rding has
> >> changed. I also agree that the use of "either" doesn't help clarit=
y.
> >=20
> > I looked up 2.0 (July 2000); indeed, it said "can contain both". My=
 bad.
> >>
> >>> I chose WinXP because, on another patch, it came up in the discus=
sion [3].
> >=20
> > The change should work down to WinXP: the name =5FHID is kept.
> >=20
> > ```
> > $ git grep -B2 -A2 -n PNP0A03
> > tools/libacpi/dsdt.asl-40-       Device (PCI0)
> > tools/libacpi/dsdt.asl-41-       {
> > tools/libacpi/dsdt.asl:42:           Name (=5FHID, EisaId ("PNP0A03=
"))
> > tools/libacpi/dsdt.asl-43-           Name (=5FUID, 0x00)
> > tools/libacpi/dsdt.asl-44-           Name (=5FADR, 0x00)
> > ```
> >=20
> > Its EISA ID is "PNP0A03"; the namespace is reserved for Microsoft. =
Microsoft identifies "PNP0A03" as PCI devices [1].
>=20
> You again say "should" without explaining what you derive this from. =
Is it
> written down somewhere that no OS we (remotely) care about ever evalu=
ated
> =5FADR when =5FHID was there? As before, along side mentioning the be=
nefits of
> the change, I'd like to also see a discussion of risks.
>=20

I derive this knowledge only from the APCI specs. Indeed, I've not rese=
arched how every OS interprets =5FHID and =5FADR.

From your answer, I see you would like to be sure the change will intro=
duce no regression. I do understand you point of view; keeping the back=
ward compatibility.=20

The benefit is that the warning will be cleared. We agree on that.

The risk is that, if ever any OS relies on =5FADR, and cannot read =5FH=
ID; it would break.

After thinking about it, the other way is less risky: this =5FHID name =
is only recognized by Windows. Every OS should (I did say it again, sho=
uld) understand =5FADR.

If you think the change makes sense, I can remove =5FHID instead of =5F=
ADR.

Otherwise, I think we should end the discussion.

Ariel
> Jan



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 12:24:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 12:24:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857956.1270162 (Exim 4.92)
	(envelope-from )
	id 1tNA8m-0003Jl-Os; Mon, 16 Dec 2024 12:24:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857956.1270162; Mon, 16 Dec 2024 12:24: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 1tNA8m-0003Je-LA; Mon, 16 Dec 2024 12:24:00 +0000
Received: by outflank-mailman (input) for mailman id 857956;
 Mon, 16 Dec 2024 12:24: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 1tNA8m-0003JY-Az
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 12:24:00 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9fcd946b-bba8-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 13:23:58 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 16 Dec 2024 13:23:58 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9fcd946b-bba8-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734351838; x=1765887838;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=YmkfCn6dKxIG8ZjVDvxpedYpcnK0kYr3+Ph2sFjyHm8=;
  b=s/1rl30ZhKfuWyxT2vB6x4Lb9qeRUMPMVid7l2feVKCz/7sjTm/gWeR/
   mffAPuTOzNsjfZlZ1uh4zDkW3f8PUP3bhwBfhmPG2c+4odEhXK2Xaq+sC
   8yUv2YeQjzbT3ShhRT3Ha7VnF0zJNgh232kqS1Ko4GTxDSQXOrwwVqwzq
   M=;
X-CSE-ConnectionGUID: Q8Zog9VKRnySGLxjIycwzw==
X-CSE-MsgGUID: XWAlPsmtR8ibmcv8ZRuunQ==
X-IronPort-AV: E=Sophos;i="6.12,238,1728943200"; 
   d="scan'208";a="28195949"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: <92fdf726-504b-4d3b-8043-d736b275d8d0@suse.com>
Content-Type: text/plain; charset="utf-8"
X-Forward: 149.5.228.1
References: <20241216120359.10469-1-andrew.cooper3@citrix.com> <92fdf726-504b-4d3b-8043-d736b275d8d0@suse.com>
Date: Mon, 16 Dec 2024 13:23:58 +0100
Cc: "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Stefano Stabellini" , "Xen-devel" 
To: "Jan Beulich" 
MIME-Version: 1.0
Message-ID: <2f7a88-67601c00-f147-208cdcc@54224017>
Subject: =?utf-8?q?Re=3A?= [PATCH] =?utf-8?q?tools/misc=3A?= Drop xensymoops
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 586

On Monday, December 16, 2024 13:09 CET, Jan Beulich =
 wrote:

> On 16.12.2024 13:03, Andrew Cooper wrote:
> > This script is not referenced by the build system, and has escaped =
all Python
> > compatibility work; it's still using print statements.
> >=20
> > Also, the regex it uses ties it to a 32bit build of Xen, which was =
dropped in
> > Xen 4.3, 11 years ago.
> >=20
> > Signed-off-by: Andrew Cooper 
>=20
> Acked-by: Jan Beulich 
>=20
>=20

Acked-by: Ariel Otilibili-Anieli 



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 12:39:26 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 12:39:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857965.1270172 (Exim 4.92)
	(envelope-from )
	id 1tNANV-0005PA-0Z; Mon, 16 Dec 2024 12:39:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857965.1270172; Mon, 16 Dec 2024 12:39:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNANU-0005P3-Tw; Mon, 16 Dec 2024 12:39:12 +0000
Received: by outflank-mailman (input) for mailman id 857965;
 Mon, 16 Dec 2024 12:39: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 1tNANT-0005Ox-Ne
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 12:39:11 +0000
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com
 [2a00:1450:4864:20::42c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bf8fbc96-bbaa-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 13:39:10 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-385de9f789cso3249484f8f.2
 for ; Mon, 16 Dec 2024 04:39:10 -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-388c8015f77sm7989395f8f.26.2024.12.16.04.39.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 04:39:09 -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: bf8fbc96-bbaa-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734352750; x=1734957550; 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=JDGBV3lZJKS4peaTPAzvFzuXtWgbTOpf0v8IZbM4KqU=;
        b=YnqEl0xvIvkB+i3R+GoHbCy+neUhL8h/p9oTeryBq0uINkD0d/yQvTAv07quLrBis5
         cRw8hEQOJLdw9W196O8oAjOqArP9vSOnFOBsKv28ZjaSJfB4LhP7DqIJ4RR6Ns7zMghv
         z47YbcZickSiMJFA57j+SliyBOFxrCADScHxS9NOGrorrwvxeGc54M9RwGUrtcbG8Lc7
         qLGslXZGG5ljCrAdTc9bt0E6cVxFaoDe6V2B1aejUcZEnTBgzRipWgPk/AAAn/NLGxGU
         BpuwOjWN1uw0nYyW3CWk175F3EIAy7yu6GSWK4IDbD3e3l30UTFK6XdwPOMnuasXSgUO
         TwAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734352750; x=1734957550;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=JDGBV3lZJKS4peaTPAzvFzuXtWgbTOpf0v8IZbM4KqU=;
        b=MJILuU1f0e21TUzv+VStl7F4Ye3M9nBKI2jPb/W5ep+CZ+Rl2rmF7bkKM253rElXrg
         WFzeIN/MWV57fZ/VQC80c85WaMi+16iF8BnGncUdHpuloooTLOsv806F3zsUpL4FUdxf
         YS52VwKSl7gOMpgtlAtZ7CDO8AybTA+iRdspG3IliHDBOCT9eAlVxv0du6TRRAyYizG7
         PimFkPo8xV4gcfFejUirJst2l1Krz1oo55UJrdMB8ATYVQ6xEuMmya9Q3pt5kvTIuql8
         jRG5Ccn+g314Z/ryhdDwYy/VJ2pHLLYbtKml3xxAfNcPC77yTI7f7R+UCEKjCqKyvzpy
         CKhA==
X-Gm-Message-State: AOJu0Yysa5PVAYmGtsD7BkQ8kN71T+Hhox28La7oiGjhrYShH3YEv5KJ
	1l6tSp7Q6CCbxkF8jGFUCQ70dJLzPXcBC4Q8mcLVxjPWDSviYAa+OZ8Qj7GILg==
X-Gm-Gg: ASbGncsHn1gH0eIq+zU/ggyi94yYvOugSVgkooQ7pTsC/kPHLqxybr2wNq0JvkhHe15
	NcLBBMDIzYo142Vs8pTknIl7vyrrZgcew0nRsOfwuozNg0qaWJtZacJ7xpFNPtvEjZEEOHA4Beu
	4Wlfa1zxOAElJ2Hj9qZaNaZw0Nou+O3goxWO5+M1tUXQF/ksiZBysC/lDFIkhkn4qC2uKIfqMF1
	/Ss5pErjPyststXvBmZHTZbOEcrkdRjyh+xZp5kMDL/aR8vupClQ/fdFMdwhv1YyVnOV/tgujyh
	IiCXwxBtoTp8LLH5sdhrAZgbz+km7iPBzkxVfnQXEw==
X-Google-Smtp-Source: AGHT+IFsm9nrCxgZc6AyglyQ54EjDaSfFEOxLfdnFGRcdffKP+Ekhk4uN9k2k7YIUsbAWP0SvqYPYw==
X-Received: by 2002:a5d:5f8b:0:b0:386:3e3c:efd with SMTP id ffacd0b85a97d-3888e0f470bmr9546532f8f.44.1734352749930;
        Mon, 16 Dec 2024 04:39:09 -0800 (PST)
Message-ID: <7f30f105-e13e-4e41-b432-82f9c12760d9@suse.com>
Date: Mon, 16 Dec 2024 13:39:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/1] tools/libacpi: clear ASL warning about PCI0
To: Ariel Otilibili-Anieli 
Cc: xen-devel@lists.xenproject.org, Anthony PERARD 
References: <20241215154659.151158-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241215154659.151158-2-Ariel.Otilibili-Anieli@eurecom.fr>
 <5599dc89-0fa4-4255-b4a1-5b81e151d8c7@suse.com>
 <2f7a85-67600280-e411-38ee5c40@258420856>
 
 <2f7a86-67600f80-8b81-26131fc0@216081513>
 <3f3e9a77-5695-4c91-9fc2-11a3c21605c5@suse.com>
 <2f7a86-67601b00-8b99-26131fc0@216117285>
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: <2f7a86-67601b00-8b99-26131fc0@216117285>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.12.2024 13:19, Ariel Otilibili-Anieli wrote:
> On Monday, December 16, 2024 12:38 CET, Jan Beulich  wrote:
> 
>> On 16.12.2024 12:31, Ariel Otilibili-Anieli wrote:
>>> On Monday, December 16, 2024 12:01 CET, Jan Beulich  wrote:
>>>
>>>> On 16.12.2024 11:36, Ariel Otilibili-Anieli wrote:
>>>>> On Monday, December 16, 2024 10:53 CET, Jan Beulich  wrote:
>>>>>
>>>>>> On 15.12.2024 16:40, Ariel Otilibili wrote:
>>>>>>> * iasl complains _HID and _ADR cannot be used at the same time
>>>>>>>
>>>>>>> ```
>>>>>>> /usr/bin/iasl -vs -p tools/firmware/hvmloader/dsdt_anycpu.tmp -tc tools/firmware/hvmloader/dsdt_anycpu.asl 2>&1 | grep -B10 HID
>>>>>>> tools/firmware/hvmloader/dsdt_anycpu.asl     40:        Device (PCI0)
>>>>>>> Warning  3073 -                                    Multiple types ^  (Device object requires either a _HID or _ADR, but not both)
>>>>>>> ```
>>>>>>>
>>>>>>> * generally _HID devices are enumerated and have their drivers loaded by ACPI
>>>>>>> * this is from "ASL 2.0 Introduction and Overview" (page 4).
>>>>>>> * removing _ADR, the warning is cleared out.
>>>>>>
>>>>>> Okay, that's the positive aspect. Yet what about the potential fallout thereof?
>>>>>> Can you confirm that there's no risk of regressions with older guest OSes, for
>>>>>> example?
>>>>>
>>>>> OSes that were released after ACPI 2.0 should work [1]; including WinXP: 
>>>>> The 2.0 specs says either _HID or _ADR should be included [2], not both (Section 6.1, page 146).
>>>>
>>>> We must be looking at two different variants of the spec then. My copy says
>>>> "device object must contain either an _HID object or an _ADR object, but can
>>>> contain both." Also still in 2.0c. I agree that in e.g. 6.5 the wording has
>>>> changed. I also agree that the use of "either" doesn't help clarity.
>>>
>>> I looked up 2.0 (July 2000); indeed, it said "can contain both". My bad.
>>>>
>>>>> I chose WinXP because, on another patch, it came up in the discussion [3].
>>>
>>> The change should work down to WinXP: the name _HID is kept.
>>>
>>> ```
>>> $ git grep -B2 -A2 -n PNP0A03
>>> tools/libacpi/dsdt.asl-40-       Device (PCI0)
>>> tools/libacpi/dsdt.asl-41-       {
>>> tools/libacpi/dsdt.asl:42:           Name (_HID, EisaId ("PNP0A03"))
>>> tools/libacpi/dsdt.asl-43-           Name (_UID, 0x00)
>>> tools/libacpi/dsdt.asl-44-           Name (_ADR, 0x00)
>>> ```
>>>
>>> Its EISA ID is "PNP0A03"; the namespace is reserved for Microsoft. Microsoft identifies "PNP0A03" as PCI devices [1].
>>
>> You again say "should" without explaining what you derive this from. Is it
>> written down somewhere that no OS we (remotely) care about ever evaluated
>> _ADR when _HID was there? As before, along side mentioning the benefits of
>> the change, I'd like to also see a discussion of risks.
>>
> 
> I derive this knowledge only from the APCI specs. Indeed, I've not researched how every OS interprets _HID and _ADR.
> 
> From your answer, I see you would like to be sure the change will introduce no regression. I do understand you point of view; keeping the backward compatibility. 
> 
> The benefit is that the warning will be cleared. We agree on that.
> 
> The risk is that, if ever any OS relies on _ADR, and cannot read _HID; it would break.
> 
> After thinking about it, the other way is less risky: this _HID name is only recognized by Windows. Every OS should (I did say it again, should) understand _ADR.
> 
> If you think the change makes sense, I can remove _HID instead of _ADR.

But that would remove relevant information, the the PNP ID serves a purpose.

> Otherwise, I think we should end the discussion.

Well, you may decide to withdraw / abandon the patch, or you may decide to
re-submit with an extended description, clarifying why the removal is
expected to be safe. Even if - obviously - you can't inspect e.g. Windows
sources.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 12:42:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 12:42:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.857978.1270182 (Exim 4.92)
	(envelope-from )
	id 1tNAQV-0007Nm-H8; Mon, 16 Dec 2024 12:42:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 857978.1270182; Mon, 16 Dec 2024 12:42: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 1tNAQV-0007Nf-Dq; Mon, 16 Dec 2024 12:42:19 +0000
Received: by outflank-mailman (input) for mailman id 857978;
 Mon, 16 Dec 2024 12:42: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 1tNAQU-0007NZ-Gm
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 12:42:18 +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 2e5e740e-bbab-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 13:42:16 +0100 (CET)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3862a921123so3106133f8f.3
 for ; Mon, 16 Dec 2024 04:42: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
 ffacd0b85a97d-388c801a8a5sm8068473f8f.48.2024.12.16.04.42.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 04:42: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: 2e5e740e-bbab-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734352936; x=1734957736; 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=4Ge9+7Zj3HbDDcjUkuO+cmUsX/JU+tFta7a3FCl7OTU=;
        b=VvHqZyoBCYomcDOC3IZOoVs3mn/hYtaQHzTEwYEzIw+qfN+Il1uPW3RJyruf/TKT44
         qJxGFh087B/wNT+8tpwXEca2uYUisWLD0B3NpSjUH5OCmM2+aZOx1wH5QLvLK28BPjd9
         SEysaUBzQtxT/ajxKfkRDLvc5YGGeYby8JX3H+l8M4yvxFCRSNU5MZfd9EAMdoarzwV1
         CrVx7B6yvUS8OgOL5634uuFN7dPq/cJIQetKRLrICG59ljVaN+5y7kC4Pz2SddFfpAWU
         02ZYydTVKPwopynzATdJyKGb+QWFV7TVQ1hbHfn3jiaksA6/j3C4U/qoffHApbS7Fehg
         J4fQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734352936; x=1734957736;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4Ge9+7Zj3HbDDcjUkuO+cmUsX/JU+tFta7a3FCl7OTU=;
        b=qqVahPDN89MH/B7M/D2xuDH6PTK+bD2wdcT6VuVEwaQP9IHatGZB5YluSfbgwWbbtK
         /cbtklYbEoNAfbHgw8MV3bTARBPOkuJ1MWVQyHO9luFi6oanTz1cCOb4it7K1nboamJn
         BxsID7CqIyXci01cofw4N6REB5oLRvs/8ZL/SCnE75aXzmFvwkUFPTGRWQpWMiSG06zn
         tvd1Jc4vEnz3g+wQVK+jrAVbLk9KF/eeMM4NaWQNmjBxvShdMwjNFzsSvCeVJpK28yb4
         4Edmp7dkcFPSg+6HyjRcqo1pFR8fWJH9ngd3v5nLCzAqjyX/wU3K91lJ+mVFfnhxBVCh
         E2sw==
X-Forwarded-Encrypted: i=1; AJvYcCU9h8avXQd3sl1FmcLc0NxnZXE6Q7glV9VAiA3daqxHrVVEa1o2C7chALvczxebi/rxynfimFL3iOU=@lists.xenproject.org
X-Gm-Message-State: AOJu0YycC9Bjbm3/rmQoWGVm7qi4TXDoyN4aF5aVCOUeSkV+2UQvKd67
	DFxuZLgI0r2yWqI4goN8Ut0NUe5vnIu4PzrvBwhiG9IMx7l5iut/tZ/mHyWkMQ==
X-Gm-Gg: ASbGncsA6+BXXM1qPMssx8qXJq8QyqiQP5r7+vz29D/dhi9s/T9bhk0aqY6kUwvSTv1
	ThAIv3z4YYbhVRYaaI3LiTvkpAzxF0p1gkXpBZJHHV6UquO37+OSxD3MCYnHGmseh87HvvPanat
	FD5DCxPufrsTHjZx6L3EE6NhYRnUrVU84ZNfw1QfkeSGwi9ZJiqXO/YlVL1YGpPwI8tnodKuMJC
	3eAYvvLUJzXNREMqeBl5pw+1SzeAIw5UGxLQLiSeOjysdxEuBI1R3vPCuBoJHrCqmPTJEuXt8a6
	j3PZfOOgifAKN5j6SF8Vqt+xj4UebtvstDIrappCmg==
X-Google-Smtp-Source: AGHT+IHC3M93YKbX/zJekxQ2S6I60xA9HXMTt0MQkmdKkmC7QLRQCuK9iL0qARvZ5KOhQ65Qxqq1fQ==
X-Received: by 2002:a5d:64a7:0:b0:385:e9ca:4e18 with SMTP id ffacd0b85a97d-38880ac23d0mr10470331f8f.1.1734352935976;
        Mon, 16 Dec 2024 04:42:15 -0800 (PST)
Message-ID: <9a8089db-cddb-4f86-bc14-9dd71b0bc7ba@suse.com>
Date: Mon, 16 Dec 2024 13:42:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v12 08/12] xen/page_alloc: introduce preserved page flags
 macro
To: Carlo Nonato 
Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-9-carlo.nonato@minervasys.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: <20241213162815.9196-9-carlo.nonato@minervasys.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 13.12.2024 17:28, Carlo Nonato wrote:
> PGC_static and PGC_extra need to be preserved when assigning a page.
> Define a new macro that groups those flags and use it instead of or'ing
> every time.
> 
> Signed-off-by: Carlo Nonato 

Reviewed-by: Jan Beulich 

Aiui this is independent of 1-7 and hence could go in ahead of time?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 13:08:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 13:08:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858013.1270257 (Exim 4.92)
	(envelope-from )
	id 1tNApo-0003KM-52; Mon, 16 Dec 2024 13:08:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858013.1270257; Mon, 16 Dec 2024 13:08: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 1tNApo-0003KF-1T; Mon, 16 Dec 2024 13:08:28 +0000
Received: by outflank-mailman (input) for mailman id 858013;
 Mon, 16 Dec 2024 13:08: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 1tNApm-0003IY-PD
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 13:08:26 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20606.outbound.protection.outlook.com
 [2a01:111:f403:2417::606])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d297eccf-bbae-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 14:08:21 +0100 (CET)
Received: from BN0PR08CA0005.namprd08.prod.outlook.com (2603:10b6:408:142::20)
 by DM6PR12MB4044.namprd12.prod.outlook.com (2603:10b6:5:21d::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.20; Mon, 16 Dec
 2024 13:08:17 +0000
Received: from BN1PEPF00004681.namprd03.prod.outlook.com
 (2603:10b6:408:142:cafe::17) by BN0PR08CA0005.outlook.office365.com
 (2603:10b6:408:142::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.21 via Frontend Transport; Mon,
 16 Dec 2024 13:08:16 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BN1PEPF00004681.mail.protection.outlook.com (10.167.243.87) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Mon, 16 Dec 2024 13:08:16 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) 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; Mon, 16 Dec
 2024 07:08:15 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 16 Dec 2024 07:08:13 -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: d297eccf-bbae-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TshjHTNKH17CwxpCWl0hdMZrxz22K247PKv1akTw6sSr35NRCMWDFtp3csogENDnbaVsmedD/38F8f5OKnTEWoSTqT/lzZ2YSCjpbma87AcpKkqun2Fd27FIsmsd57g0m2qhLuhMJ2hA2Cj2vYksnmDkqudT0hwnMbWulINhZtlZcM9w19uDLAKKHj+zjx9rtpHHDFogFPRTSegf8kse0Tba/IfQi4yvV3Uy0dLAF5EUytvw6/FdLyUjS3rlfemNE5JF+lpePfdztwXwL9dP8jz6D4Jb/5ZHBsY9W3Rq/9kvxamBI1JBqQqeV44EVvpWVn/5LNbroRfebh15WLrXkg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=wW9Eczi97SpgvR7eCDs1FQ0fLj0o4WlujxzIJR3BSck=;
 b=ypSK1MvqXZ7u9lGPZ9a6RcotholWoC/MDNhjJIM7C4KsqlI99Y5KCx63hM8RqXXiqx3d3qzSt/eBGvU3ZlMDkisfxl1Td1U2Uz1Q0SjixpqxW8YpzY7eccA6FWk5Z2unvvvV/4paETVoBJbGZWN4JBPMfDtv+YlqrAt6ieYYCoGg+dognByPZkLH744z2ql6+lH8y7LxpOa2OqQ2Hv+I9bNLO7buAirwq7wwBIzX+ZalAvDNYg6QQsi3vGqs6Pcf0PajXWdpyXkh9OUwhqbSHZgoHosWwwBABYUB1GX6PZCBg3YfPZFe1SYPjb+ZwKKSHob3uT54NUlMNZEBkvB0JA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=minervasys.tech smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=wW9Eczi97SpgvR7eCDs1FQ0fLj0o4WlujxzIJR3BSck=;
 b=QHMfYFVjkybIJyXRZ6Da11jyRoyuepq9jPiYVAH/LSKj5AA5Etj3gq1DhTPOu+Lbxg39+oYQCfCkAP8wl4F3w+j9+D0SkFDTO2lePBeROqVRqR6HeqoaKDvAox15MyCEhRROIHQKT5P/TiOg21Rrh2fCk8dVTaxj3uMyRGBDqg0=
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=SATLEXMB04.amd.com; pr=C
Message-ID: <1ca9b698-4fb3-4756-a0af-f08582ad3023@amd.com>
Date: Mon, 16 Dec 2024 14:08:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v12 09/12] xen: add cache coloring allocator for domains
To: Carlo Nonato ,
	
CC: , , Andrew
 Cooper , Anthony PERARD
	, Jan Beulich , Julien Grall
	, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
	Stefano Stabellini , Bertrand Marquis
	, Volodymyr Babchuk 
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-10-carlo.nonato@minervasys.tech>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <20241213162815.9196-10-carlo.nonato@minervasys.tech>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN1PEPF00004681:EE_|DM6PR12MB4044:EE_
X-MS-Office365-Filtering-Correlation-Id: baa11116-755b-45c4-2378-08dd1dd2b496
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|36860700013|7416014|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?dDJrYnBUamsxWUJXak1TalNabVpZOHVhWmtYVzJyNHFKc0hJNkM1YTlsMm94?=
 =?utf-8?B?WXFyYlhmMmtDMVB5QTBWTHdIRnpSM1dSR0N5ck9IYnhRdUJDZGpGbTZLejR0?=
 =?utf-8?B?N2YzVmpUR2dSM1JDYWxpQVZuNU9BcnBBTHFnRVRSd251Sm9PeXhJU1VJU3Zn?=
 =?utf-8?B?WDdkZ0RST2FISVQ0SzNTQkNjdXFES3ovbC91MDRXZXZtUkVGVkt6UzJ4VWNu?=
 =?utf-8?B?Sk9rZDRKeEk2b24wZnpoTGpiMGlkNWlqcXJYVjl1Y3g4Sjlhb1Y3ak9RMFVI?=
 =?utf-8?B?eGpJYmF1VXF6WjJGUUxmTklHVUFhN3dYYkJRYXNKNXhCdDM5czViejAxeVdj?=
 =?utf-8?B?WWxWRTlXa1RRQllwRllLQ2hUQ1pHM0s1NnAxL2NIZXVnSU1ZM05HeHhOYUdp?=
 =?utf-8?B?aXpqQXd3WHpMNWxMdytXc3FCcHpHYUdlbXh4dVBiL0NxMEt6YnVIaE9TOHFT?=
 =?utf-8?B?Uzd4SUJac1dZaWYwbnpTR1RsN0JsVGRIVUxNOXc1dHFHVTgxSDJ6VWNKTmhk?=
 =?utf-8?B?NTMrUTVTNDUvM0JhdUdTeVcwdmMzT0phOCttWk9oOUtYbUZWeFMxL0dlMnZW?=
 =?utf-8?B?UzZ4Y0lzbm1HWWFHUmFpUXd0ZVJLTjFVNHllbHJIQ0VBNStjcTlKak9tby9y?=
 =?utf-8?B?WGpJdUtYMWxxd1V4djQ5RzdTb2hVRWRRK1FLZk9WWDhWcmxNRnVBeU9iTDBO?=
 =?utf-8?B?dHpNb2t4MCtWMmNoUmxEeThTdkJ4SVZORkhKZmFJZGFoMjZUN0IyNlA5L2hs?=
 =?utf-8?B?V211OW1jQU9adGlSN3J1QWl1Y0xveVpVQmJRR2tsRnYrQTFpWXh4L0N2RUxs?=
 =?utf-8?B?dG83YjlQcW80U1Y3TzJDVVFMYjRzcHM2M3NwU0JFM290UzhHKzByRkx4Snda?=
 =?utf-8?B?UkVCN00rYU8xTXJ4aTJEM0ZjajdTaUJNN3FJWWhEeWxVVFV0VWNzSCsvSlNE?=
 =?utf-8?B?UXlZZk5TeCtDWThBcjZaVThBR1c4UzVVM3pFcTJQcmNqeVNLeGlQb0IvQUtr?=
 =?utf-8?B?RnVmMm9Ea1JnNkVCS0Z2MklPNVZrN0h5cVhZRVpjamRVRVlYbExnNHpKYU5F?=
 =?utf-8?B?WjJIMSsvT1JhSmdteUhyaUsvZTU1VXEzeXdjVUc3Z1lDaXZnU0dnSlJaMjBL?=
 =?utf-8?B?NFhkTUpnUS9SaUdaRFFmMHBpRXJZcmJ6dCtRV1hEczY1YnNISUx3NWZBYXk3?=
 =?utf-8?B?em5FZDBabUE4VGNlZEpwUGdIU21JOEZOdXk0WE1zbjZTTnBGdVJaMkhVNHJN?=
 =?utf-8?B?Vk04RFg1ZE52bWgwZ3gzY2xEdFljemUrMmtwY2kvcklXWEV0SmtvMXU1WS94?=
 =?utf-8?B?VVJINHRnNEFPTHJFTG5IUHdXYzJKSkhoSmpYYkJNS052b0JLeXpkeUZrS2dF?=
 =?utf-8?B?bVpGbmhGV3NBT2dhK2ltZXppQ3NkYVNOVXZzd01NeDBXK0h4eUY1OUlna1Rh?=
 =?utf-8?B?ZU5JR2t0WWhRUGNvQ2ttUTR0WXhqMXptNnFVOXFLZWFuUGQ4MUxjVEtqQWxJ?=
 =?utf-8?B?QnFQRFhRc2VRWGhyUFJoQmpHSFhrWTJWTExncWFQYnN3N3ZDMnZ2YXBxYVpy?=
 =?utf-8?B?ZUJNRXJhYjNSV0RhSkFFWnBOTDV1KzZkQ0VFSVJCWkxGM1hLWnMwZW8rVC8r?=
 =?utf-8?B?SkpuekdYSENqNmc2MytmNkVPYmFhb3kwL3pQaUxCcWxQc1U3TEhyN0g5cURM?=
 =?utf-8?B?SWRCeGY5MExRTE9wZmtiVEpyWDVJaDVIR3JadnFSVmwxRW1ESEhjMG9XVisw?=
 =?utf-8?B?WnZEVzRQN2w3UFJJMUFGZlRtVDdqUjFxcDdUczZsajBIeDFUVlo4QjRzeWhj?=
 =?utf-8?B?MFBCdituN3BsSXdqTkh3REFTeGRjWFMzWVUyYXdDeDZlTDZ5aUVWeUxMNjg4?=
 =?utf-8?B?dThMTTlpYzNBTFJ0Y1p0NTVRd2pQbDFTbTdiejQ3U2YzbmtwYkU3OUpzNWhO?=
 =?utf-8?B?MlNQVTE1dUhZOVRrNEp0QjZiVTZYVzlEZ3EzMXVBMEd2T0lLdXlCMlZINVFE?=
 =?utf-8?Q?cwRgUy1BNEg6QWOLdVe3sZ7rKLXQrE=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(36860700013)(7416014)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Dec 2024 13:08:16.5773
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: baa11116-755b-45c4-2378-08dd1dd2b496
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN1PEPF00004681.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4044



On 13/12/2024 17:28, Carlo Nonato wrote:
> 
> 
> Add a new memory page allocator that implements the cache coloring mechanism.
> The allocation algorithm enforces equal frequency distribution of cache
> partitions, following the coloring configuration of a domain. This allows
> for an even utilization of cache sets for every domain.
> 
> Pages are stored in a color-indexed array of lists. Those lists are filled
> by a simple init function which computes the color of each page.
> When a domain requests a page, the allocator extracts the page from the list
> with the maximum number of free pages among those that the domain can access,
> given its coloring configuration.
> 
> The allocator can only handle requests of order-0 pages. This allows for
> easier implementation and since cache coloring targets only embedded systems,
> it's assumed not to be a major problem.
> 
> The buddy allocator must coexist with the colored one because the Xen heap
> isn't colored. For this reason a new Kconfig option and a command line
> parameter are added to let the user set the amount of memory reserved for
> the buddy allocator. Even when cache coloring is enabled, this memory
> isn't managed by the colored allocator.
> 
> Colored heap information is dumped in the dump_heap() debug-key function.
> 
> Based on original work from: Luca Miccio 
> 
> Signed-off-by: Marco Solieri 
> Signed-off-by: Carlo Nonato 
> Reviewed-by: Jan Beulich 
> ---
> v12:
> - fixed #ifdef CONFIG_LLC_COLORING in init_color_heap_pages()
> v11:
> - CONFIG_BUDDY_ALLOCATOR_SIZE depends on CONFIG_LLC_COLORING
> - buddy_alloc_size is defined only if CONFIG_LLC_COLORING
> - buddy-alloc-size param is parsed only if CONFIG_LLC_COLORING
> v10:
> - stated explicit dependency on CONFIG_LLC_COLORING for buddy-alloc-size
> - fix for MISRA rule 20.7 parenthesis
> v9:
> - added ASSERT(order == 0) when freeing a colored page
> - moved buddy_alloc_size initialization logic in Kconfig
> v8:
> - requests that uses MEMF_* flags that can't be served are now going to fail
> - free_color_heap_page() is called directly from free_heap_pages()
> v7:
> - requests to alloc_color_heap_page() now fail if MEMF_bits is used
> v6:
> - colored allocator functions are now static
> v5:
> - Carlo Nonato as the new author
> - the colored allocator balances color usage for each domain and it searches
>   linearly only in the number of colors (FIXME removed)
> - addedd scrub functionality
> - removed stub functions (still requires some macro definition)
> - addr_to_color turned to mfn_to_color for easier operations
> - removed BUG_ON in init_color_heap_pages() in favor of panic()
> - only non empty page lists are logged in dump_color_heap()
> v4:
> - moved colored allocator code after buddy allocator because it now has
>   some dependencies on buddy functions
> - buddy_alloc_size is now used only by the colored allocator
> - fixed a bug that allowed the buddy to merge pages when they were colored
> - free_color_heap_page() now calls mark_page_free()
> - free_color_heap_page() uses of the frametable array for faster searches
> - added FIXME comment for the linear search in free_color_heap_page()
> - removed alloc_color_domheap_page() to let the colored allocator exploit
>   some more buddy allocator code
> - alloc_color_heap_page() now allocs min address pages first
> - reduced the mess in end_boot_allocator(): use the first loop for
>   init_color_heap_pages()
> - fixed page_list_add_prev() (list.h) since it was doing the opposite of
>   what it was supposed to do
> - fixed page_list_add_prev() (non list.h) to check also for next existence
> - removed unused page_list_add_next()
> - moved p2m code in another patch
> ---
>  docs/misc/cache-coloring.rst      |  37 ++++++
>  docs/misc/xen-command-line.pandoc |  14 +++
>  xen/arch/arm/include/asm/mm.h     |   5 +
[...]

> +#ifdef CONFIG_LLC_COLORING
> +/* Page is cache colored */
> +#define _PGC_colored      PG_shift(4)
NIT: do we really need to define it if it's not used? I don't like this concept but
I quickly checked new arches and they also copied some flags that are not used, so
maybe it's the proper way to go.

Acked-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 13:27:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 13:27:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858025.1270266 (Exim 4.92)
	(envelope-from )
	id 1tNB7m-0006cB-Jc; Mon, 16 Dec 2024 13:27:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858025.1270266; Mon, 16 Dec 2024 13:27: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 1tNB7m-0006c4-Gf; Mon, 16 Dec 2024 13:27:02 +0000
Received: by outflank-mailman (input) for mailman id 858025;
 Mon, 16 Dec 2024 13:27: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 1tNB7l-0006by-66
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 13:27:01 +0000
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com
 [2607:f8b0:4864:20::135])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6cbf5e51-bbb1-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 14:26:58 +0100 (CET)
Received: by mail-il1-x135.google.com with SMTP id
 e9e14a558f8ab-3a815ed5acfso14007885ab.0
 for ; Mon, 16 Dec 2024 05:26: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: 6cbf5e51-bbb1-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734355617; x=1734960417; 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=k78SYHRlfjmw6gItq29cq+NFFn6CZCuog15ExU7ukHQ=;
        b=SWcXhsBMh8nQwmGSY/NTDhMZsYuV4rbe5Jbu2Kku2nhT2lj7uv7qYbnt6Gx5Gncibe
         Y4GJ4XsFN7RLnfIATGgPdxZNDmx+WumGeK37kunriyXJ3jQxkvBwvbMtd9OCH3WFQe58
         rO00UGbPGN/kNMrUVN3ywFYXtBuqlopegNFEQQHY6UYCqpYT7ZlHkTgZeMc/wCJGeDRp
         bMIvOiDfMiZIrFH19unWrKxrDJ/KyjKKZMYvh6LbNC/F7DQUnqyoyEUNHRR0/sIsWsrH
         Mltoh/LVc7DoXwEcAhbRMtjGbMA5MV6lz74W9hx3VTRuhxvE7QP/gFdH3P9saDNg0Bvu
         E+uA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734355617; x=1734960417;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=k78SYHRlfjmw6gItq29cq+NFFn6CZCuog15ExU7ukHQ=;
        b=hBnPUx+XITPPV1Hc74OZzDA3gJLG4HzbcGwX+L2aHuZXugzPf3dqkXIIcTCCdsM9d0
         QKp4nBTAd+e7dQVQYhs5/MrGUFC5TfFndPWBXuhqe+DAujRGhfCpcKDRRDMK7W8g3fl8
         IC9ns5vela9K5OcwHEd7r3HTS7PE4qK1DuO5It15f/9aXfg0cNbY4P4Qb0EQ7Wb2AqGJ
         Ajk4rPi61UKeC9UWzftvm78v2KoAu2xRZzKsrj4hP5aCuBgnoGyNWyPyZ+ajC+XRBXtC
         wSI+UfvxUpIDOUTzwaU1iOyoceXrcLCGHaeUt+lATDE2HCw/89Q8sHnbXQn+S8lrbz31
         Cj4A==
X-Forwarded-Encrypted: i=1; AJvYcCVVpEhdzp3P48WTgs0b4f5dof7Yv/UQjf69irr3BXQyaIV0+TTleaqgagbZBqoXyCG9O9UDF90Reic=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw4wkQAez+JrJIs9/YRuYTmdKU85dyKNLshgH0PBPirwYMGmTva
	jefOCWPa5CR9NrDVTtUDNVQYvyaVAA+D5GrReyZGqHs4nN9ZtAXw82Ojji/EtEeyt599V7uICY4
	MeOdYTribu+GHo32uPSDQfr5L2CPyk6e/Yvb32A==
X-Gm-Gg: ASbGnctnYbxIQpP9P+F0CHzhv6cuEz3bSLPG8qmXNYMyj+UK7fc8wB8I/8MGAiQXsRx
	uZQk2Glyf/np/UtGZDlKgicYEfpE6X6QfRJtgLi0=
X-Google-Smtp-Source: AGHT+IEXCKhK6+eoE3hkWNmwiXOJQG2KLZp3TY8AISzfZ++eJFe1T7aYTE1IgBjn/InNrTNid/JVOqag5ZYryUzOSjY=
X-Received: by 2002:a05:6e02:218e:b0:3a7:e732:4713 with SMTP id
 e9e14a558f8ab-3affab6228amr103488355ab.15.1734355617498; Mon, 16 Dec 2024
 05:26:57 -0800 (PST)
MIME-Version: 1.0
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-9-carlo.nonato@minervasys.tech> <9a8089db-cddb-4f86-bc14-9dd71b0bc7ba@suse.com>
In-Reply-To: <9a8089db-cddb-4f86-bc14-9dd71b0bc7ba@suse.com>
From: Carlo Nonato 
Date: Mon, 16 Dec 2024 14:26:45 +0100
Message-ID: 
Subject: Re: [PATCH v12 08/12] xen/page_alloc: introduce preserved page flags macro
To: Jan Beulich 
Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, 
	Andrew Cooper , Anthony PERARD , 
	Michal Orzel , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jan,

On Mon, Dec 16, 2024 at 1:42=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 13.12.2024 17:28, Carlo Nonato wrote:
> > PGC_static and PGC_extra need to be preserved when assigning a page.
> > Define a new macro that groups those flags and use it instead of or'ing
> > every time.
> >
> > Signed-off-by: Carlo Nonato 
>
> Reviewed-by: Jan Beulich 
>
> Aiui this is independent of 1-7 and hence could go in ahead of time?

Yes.

> Jan

Thanks.

- Carlo


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 13:30:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 13:30:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858033.1270276 (Exim 4.92)
	(envelope-from )
	id 1tNBB3-000850-1W; Mon, 16 Dec 2024 13:30:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858033.1270276; Mon, 16 Dec 2024 13:30:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNBB2-00084t-Ux; Mon, 16 Dec 2024 13:30:24 +0000
Received: by outflank-mailman (input) for mailman id 858033;
 Mon, 16 Dec 2024 13:30: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 1tNBB1-00084n-KQ
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 13:30:23 +0000
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [2a00:1450:4864:20::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e6aa2fe5-bbb1-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 14:30:22 +0100 (CET)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-aab925654d9so491903966b.2
 for ; Mon, 16 Dec 2024 05:30:22 -0800 (PST)
Received: from ?IPV6:2003:e5:8725:5e00:fa69:c5cb:46d:3e5b?
 (p200300e587255e00fa69c5cb046d3e5b.dip0.t-ipconnect.de.
 [2003:e5:8725:5e00:fa69:c5cb:46d:3e5b])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab96390cbesm330169366b.158.2024.12.16.05.30.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 05:30: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: e6aa2fe5-bbb1-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734355822; x=1734960622; 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=N9kyEzeL62UYAfA9Mb+PrEZVN4x1XgjhNEltXJTS2Hg=;
        b=dF9/Pikv14UCIIErMC2WI7pS0qW10TSVFVWp9C+a5jhXcEIb4v/s62obDoyI05MiIO
         eZJ9YWYTO/udwUgwo7ZoHP/Y4WhT07UJccmfQG4YR90Ey2cacLTs3T/bs4/xwvtYtz4L
         sC66R1g5oBrQeGUXUaSNNPU82GXA6Wh3FJF6a3MClKE6l/Radz24jcpeVkhTuuPhPVJ8
         eYgCjNqzxvAeUKdLit0QpuAiZgY2V8NdbH3rmHG068ODPElQBNhsCMfOo/oz75oRM6SI
         J6PHvK0c+YCRTtT15rR26s+B3aS6mjdzAtw9LMTHZja4G0T7kM+iPFZHypOhKxeSJzCU
         9c8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734355822; x=1734960622;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=N9kyEzeL62UYAfA9Mb+PrEZVN4x1XgjhNEltXJTS2Hg=;
        b=EJBEDVdbnapG5qcJ+B35eIATrzBxhnfe97GfcM1BlDSTFnmIw+ivCLYfNSmWNk95h2
         ETI6FnSoameHocUhf65fa6p63jjotDsYsrmqEqqsGYH3oqhuNlS70cKmNXhW/CZG8o9g
         +gNZBPoSTAynqgzhjeaaLWpyjTcw1guPwRTmN2H1FRc1ocWxbQQlz9uKEpPpkpFoPMZD
         RhYZOfCRs/okxBIl4Ju8i1Ao/vSkYHwBSvthMp8IdCsJ2y3c4j6Kox3zPZAwCkRgB8V8
         0VuRA8FrOTPodB70d02j7XcXC9dAt2iOksBZtN6u3TOQL1vu5khcm6qDoD4J+Mdj9OCe
         KWfA==
X-Forwarded-Encrypted: i=1; AJvYcCUebr7wAQz4QHtaTj6a5B1Tlk9w9+VjA683p2mO543ixN2Lha07m7SaidQO3/Q9crspgEc3OUo5xCc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxo1BFiH6R1b8eUB/Uk3W1Kq75MZKLriqmEwIG4dGRbF2hpha3C
	ky5t/ANtT9BCiJr/3HGlYbnpj7w66iEGIPNw+fk9oM+iDK+GFT28JPJSepjfCE4=
X-Gm-Gg: ASbGnct2gFclrg2ZbxUoIK9r0nHNzAooAlpSVAOxxikw0YY3WzpdxsbeIsivzlAUfVF
	ISdqd0C+lzbPIRGkhSsu1B8jAqrxlEj801L/fCZHeG5cT1DueWlavXHiIz44i/tkzrhGSrMbn+U
	6pHTIOfVcZNPxQGH2XSaZwScpyZiKkgbzMFcoPOpa+uOgfJ2mM+yarTSn5uZDjT7hu75W0KXy+V
	xucgjYaN4DM01va7P2HxJEr9+4H/LNJEBTKi6M2ZYGSDHvgFmVc8zpB6emCfFb9+TsWSnea26SM
	RQJZxDJNP/0AUyPbwF0pB3r5G/fwwgdTtS/YhP+o9WQDB9Ts6IGVs1ZXTOGWQsuoXgmzziUSLQv
	eDtY=
X-Google-Smtp-Source: AGHT+IHYDolQP0P7oVtgxbOhEE3I6v6SDbNrjfVMS4Z/L15JeyZSnUFyKjkJLzFgkBv0tW8sB7odOA==
X-Received: by 2002:a17:906:f59f:b0:aa6:40a4:b13 with SMTP id a640c23a62f3a-aab77ec4a49mr1432004366b.59.1734355822025;
        Mon, 16 Dec 2024 05:30:22 -0800 (PST)
Message-ID: <0008f33a-74d8-48d7-bd3d-23318eda2fa5@suse.com>
Date: Mon, 16 Dec 2024 14:30:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 4/7] xen: add bitmap to indicate per-domain state
 changes
To: Jan Beulich 
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: <20241213162421.16782-1-jgross@suse.com>
 <20241213162421.16782-5-jgross@suse.com>
 <50258f9a-89e6-4a62-8ed5-63a3bfa668c8@suse.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: <50258f9a-89e6-4a62-8ed5-63a3bfa668c8@suse.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------yRXwyV3ZG0mpYB0ioo7L0UWO"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------yRXwyV3ZG0mpYB0ioo7L0UWO
Content-Type: multipart/mixed; boundary="------------RVcEsyhOeNHohCRT2m1jquI5";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
Message-ID: <0008f33a-74d8-48d7-bd3d-23318eda2fa5@suse.com>
Subject: Re: [PATCH v3 4/7] xen: add bitmap to indicate per-domain state
 changes
References: <20241213162421.16782-1-jgross@suse.com>
 <20241213162421.16782-5-jgross@suse.com>
 <50258f9a-89e6-4a62-8ed5-63a3bfa668c8@suse.com>
In-Reply-To: <50258f9a-89e6-4a62-8ed5-63a3bfa668c8@suse.com>
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------RVcEsyhOeNHohCRT2m1jquI5
Content-Type: multipart/mixed; boundary="------------qCXI1sXhPO0ix8VBjgc14Jod"

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

T24gMTYuMTIuMjQgMTE6MjEsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxMy4xMi4yMDI0
IDE3OjI0LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gQEAgLTEzOCw2ICsxMzksNjAgQEAg
Ym9vbCBfX3JlYWRfbW9zdGx5IHZtdHJhY2VfYXZhaWxhYmxlOw0KPj4gICANCj4+ICAgYm9v
bCBfX3JlYWRfbW9zdGx5IHZwbXVfaXNfYXZhaWxhYmxlOw0KPj4gICANCj4+ICtzdGF0aWMg
REVGSU5FX1NQSU5MT0NLKGRvbV9zdGF0ZV9jaGFuZ2VkX2xvY2spOw0KPj4gK3N0YXRpYyB1
bnNpZ25lZCBsb25nICpkb21fc3RhdGVfY2hhbmdlZDsNCj4gDQo+IF9fcmVhZF9tb3N0bHk/
DQoNClllcy4NCg0KPiANCj4+ICtpbnQgZG9tYWluX2luaXRfc3RhdGVzKHZvaWQpDQo+PiAr
ew0KPj4gKyAgICBjb25zdCBzdHJ1Y3QgZG9tYWluICpkOw0KPj4gKyAgICBpbnQgcmMgPSAt
RU5PTUVNOw0KPj4gKw0KPj4gKyAgICBzcGluX2xvY2soJmRvbV9zdGF0ZV9jaGFuZ2VkX2xv
Y2spOw0KPj4gKw0KPj4gKyAgICBpZiAoIGRvbV9zdGF0ZV9jaGFuZ2VkICkNCj4+ICsgICAg
ICAgIGJpdG1hcF96ZXJvKGRvbV9zdGF0ZV9jaGFuZ2VkLCBET01JRF9GSVJTVF9SRVNFUlZF
RCk7DQo+PiArICAgIGVsc2UNCj4+ICsgICAgew0KPj4gKyAgICAgICAgZG9tX3N0YXRlX2No
YW5nZWQgPSB4dnphbGxvY19hcnJheSh1bnNpZ25lZCBsb25nLA0KPj4gKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCSVRTX1RPX0xPTkdTKERPTUlEX0ZJ
UlNUX1JFU0VSVkVEKSk7DQo+PiArICAgICAgICBpZiAoICFkb21fc3RhdGVfY2hhbmdlZCAp
DQo+PiArICAgICAgICAgICAgZ290byB1bmxvY2s7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsg
ICAgcmN1X3JlYWRfbG9jaygmZG9tbGlzdF9yZWFkX2xvY2spOw0KPj4gKw0KPj4gKyAgICBm
b3JfZWFjaF9kb21haW4gKCBkICkNCj4+ICsgICAgICAgIHNldF9iaXQoZC0+ZG9tYWluX2lk
LCBkb21fc3RhdGVfY2hhbmdlZCk7DQo+IA0KPiBVc2UgdGhlIGNoZWFwZXIgX19zZXRfYml0
KCkgaGVyZT8NCg0KT2theS4NCg0KPiANCj4+ICtzdGF0aWMgdm9pZCBkb21haW5fY2hhbmdl
ZF9zdGF0ZShjb25zdCBzdHJ1Y3QgZG9tYWluICpkKQ0KPj4gK3sNCj4+ICsgICAgc3Bpbl9s
b2NrKCZkb21fc3RhdGVfY2hhbmdlZF9sb2NrKTsNCj4+ICsNCj4+ICsgICAgaWYgKCBkb21f
c3RhdGVfY2hhbmdlZCApDQo+PiArICAgICAgICBzZXRfYml0KGQtPmRvbWFpbl9pZCwgZG9t
X3N0YXRlX2NoYW5nZWQpOw0KPiANCj4gQW5kIHBlcmhhcHMgZXZlbiBoZXJlLCBjb25zaWRl
cmluZyBldmVyeXRoaW5nJ3MgdW5kZXIgbG9jayBub3c/DQoNClRydWUuDQoNCj4gDQo+PiAt
LS0gYS94ZW4vY29tbW9uL2V2ZW50X2NoYW5uZWwuYw0KPj4gKysrIGIveGVuL2NvbW1vbi9l
dmVudF9jaGFubmVsLmMNCj4+IEBAIC00ODUsNiArNDg1LDEzIEBAIGludCBldnRjaG5fYmlu
ZF92aXJxKGV2dGNobl9iaW5kX3ZpcnFfdCAqYmluZCwgZXZ0Y2huX3BvcnRfdCBwb3J0KQ0K
Pj4gICAgICAgaWYgKCAodiA9IGRvbWFpbl92Y3B1KGQsIHZjcHUpKSA9PSBOVUxMICkNCj4+
ICAgICAgICAgICByZXR1cm4gLUVOT0VOVDsNCj4+ICAgDQo+PiArICAgIGlmICggdmlycSA9
PSBWSVJRX0RPTV9FWEMgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICByYyA9IGRvbWFpbl9p
bml0X3N0YXRlcygpOw0KPj4gKyAgICAgICAgaWYgKCByYyApDQo+PiArICAgICAgICAgICAg
Z290byBkZWluaXQ7DQo+PiArICAgIH0NCj4gDQo+IFRoaXMgaXMgdGllZCB0byBWSVJRX0RP
TV9FWEMuIEhvdyBjb21lIC4uLg0KPiANCj4+IEBAIC01MjcsNiArNTM0LDEwIEBAIGludCBl
dnRjaG5fYmluZF92aXJxKGV2dGNobl9iaW5kX3ZpcnFfdCAqYmluZCwgZXZ0Y2huX3BvcnRf
dCBwb3J0KQ0KPj4gICAgb3V0Og0KPj4gICAgICAgd3JpdGVfdW5sb2NrKCZkLT5ldmVudF9s
b2NrKTsNCj4+ICAgDQo+PiArIGRlaW5pdDoNCj4+ICsgICAgaWYgKCByYyApDQo+PiArICAg
ICAgICBkb21haW5fZGVpbml0X3N0YXRlcygpOw0KPj4gKw0KPj4gICAgICAgcmV0dXJuIHJj
Ow0KPj4gICB9DQo+IA0KPiAuLi4gZGUtaW5pdCBoYXBwZW5zIHVwb24gYW55IGVycm9yLCBy
ZWdhcmRsZXNzIG9mIHZJUlE/IEV2ZW4gY2hlY2tpbmcNCj4gdGhlIHZpcnEgaXNuJ3Qgc3Vm
ZmljaWVudCwgYXMgd2UgYWxzbyBuZWVkIHRvIGdyYWNlZnVsbHkgZGVhbCB3aXRoIHRoZQ0K
PiAtRUVYSVNUIHBhdGguDQoNCkdvb2QgY2F0Y2guIFdpbGwgY2hhbmdlIHRoYXQuDQoNCg0K
SnVlcmdlbg0K
--------------qCXI1sXhPO0ix8VBjgc14Jod
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-----

--------------qCXI1sXhPO0ix8VBjgc14Jod--

--------------RVcEsyhOeNHohCRT2m1jquI5--

--------------yRXwyV3ZG0mpYB0ioo7L0UWO
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/Ey8FAmdgK20FAwAAAAAACgkQsN6d1ii/Ey/B
yAf/SrP/ntF+i+q1RzMF83F+WMkU1bqThjYeGmsO9RzDU5qFwxMj5iZ2jEnmwfnLF9lfRYp1v+iE
c2XHt96h2YCL2Q/83PhA6nrtLfyJPqJz/WW4RJ/96bcPlO/IQ550wyuGcg8nS01QsF6wj2WBwdEI
mEqrENXCdluDQht5t8ZLKnYx/I4CWdUp4XuTN6S1m51zfpHUm+kxhxG/1VzHlMfm+dohGvIc2sKz
YzgIaamN2XH8f6Z+fTcfhA/wsP2VHrlAFJs88bSKWjBNtj+y5MyeITLQCi2jxJEOwx7EtCVA2rUX
D0lcPI+k35nMxPV+8RWuveapVzbCo0EWwqBGKQ0ykw==
=+nqX
-----END PGP SIGNATURE-----

--------------yRXwyV3ZG0mpYB0ioo7L0UWO--


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 13:56:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 13:56:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858061.1270307 (Exim 4.92)
	(envelope-from )
	id 1tNBaC-0003Mk-D1; Mon, 16 Dec 2024 13:56:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858061.1270307; Mon, 16 Dec 2024 13:56:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNBaC-0003Md-AI; Mon, 16 Dec 2024 13:56:24 +0000
Received: by outflank-mailman (input) for mailman id 858061;
 Mon, 16 Dec 2024 13:56: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 1tNBaB-0003MV-02
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 13:56:23 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20604.outbound.protection.outlook.com
 [2a01:111:f403:2416::604])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 85bc13ab-bbb5-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 14:56:20 +0100 (CET)
Received: from CH2PR08CA0008.namprd08.prod.outlook.com (2603:10b6:610:5a::18)
 by DS0PR12MB7582.namprd12.prod.outlook.com (2603:10b6:8:13c::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.20; Mon, 16 Dec
 2024 13:56:11 +0000
Received: from CH1PEPF0000AD81.namprd04.prod.outlook.com
 (2603:10b6:610:5a:cafe::b2) by CH2PR08CA0008.outlook.office365.com
 (2603:10b6:610:5a::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.21 via Frontend Transport; Mon,
 16 Dec 2024 13:56:11 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH1PEPF0000AD81.mail.protection.outlook.com (10.167.244.89) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Mon, 16 Dec 2024 13:56:11 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 16 Dec
 2024 07:56:10 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) 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; Mon, 16 Dec
 2024 07:56:10 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 16 Dec 2024 07:56:08 -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: 85bc13ab-bbb5-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=H6BjuSMyB0+dTmpcIYE3uv88+r+r620jgPkY504tIaFXmrPtwC0gOWqastr68l2w72NxQFZqrYnzlmqWtR2v7xtdiZE0+/Spk0pUV7WCT0p8mJDqeAA4sqxBt6OPC9uK9YypKkaLUgSpSjpBhzNo1vc1qrKBfQHBMPgBIFv/c8yMY+1iFY+4fO0g5WKxlxhoqc8CWvofiNWHzuOc+/90At2RO87nqk2uRfepQc8sHM9jXc/r1aVC6jhFAfUM4pLiJmsIWVVuy0WJp5n/hEwbA3GZYbkgi9o+r5FWUvPveaX0WP4BEHKhQ7KohgrUfyaQLguAh+nV6eo78+juV8YDsA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=8AsawoGcIXA1bkqmsFbGyMtCG2SunipahcRRRtswVgs=;
 b=FvyECNq6n3nammz0wotm6oPuGQ7pDH2z+Tkpxk8dVhhaZ1l7Tjm3XjTAoodYj0y+WMLqpN0zHeXQgr04W3kjToXIJO1uqejJpaz4wjSglcMtz8cu+jRAkKnSPwoPfeowEkivAjikd8r13aTORleQZqIQq8NlpjFi9QDhW+OhMR9eIui+JGpHofx98okU5ezT1+/DatH83nuldm+aQDw3cDK5KojyEXRCGXAtX8m9hyKiWiz9aYdcSfEWzymCn907ybQoqXxzWa7mAcCw0+KLNfoPNtSPhgqcOcyNmVLMieKc3czXijeNj0UM8Dzx/CPHtN4lRjLHDGeCFmYvJQeGsQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=minervasys.tech smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=8AsawoGcIXA1bkqmsFbGyMtCG2SunipahcRRRtswVgs=;
 b=DIfsOFs5pitjfQ8zOyGFP3gF65QoW+NeX2NV/UKAB33tHLzkXhbztFarEpWEOqOvGkb+cvHGR8B/c0n2NN8wRDasunQnlcHTZ6SYyoIvzvhAYdPb8fd56GpGkZQnEzw/fXUBByKW0IkoRbVgGG3eVUlU/x9GD2nO/33icaiQ7YU=
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=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Mon, 16 Dec 2024 14:56:07 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v12 12/12] xen/arm: add cache coloring support for Xen
 image
To: Carlo Nonato ,
	
CC: , ,
	"Stefano Stabellini" , Julien Grall ,
	"Bertrand Marquis" , Volodymyr Babchuk
	, Andrew Cooper ,
	Anthony PERARD , Jan Beulich ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-13-carlo.nonato@minervasys.tech>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <20241213162815.9196-13-carlo.nonato@minervasys.tech>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD81:EE_|DS0PR12MB7582:EE_
X-MS-Office365-Filtering-Correlation-Id: 0f1e3bd2-f9be-42a9-bf02-08dd1dd96623
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|376014|7416014|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?VitNR0NVZG1CRG9rVWI5TEdGUkJ0Qm5US0xyRWxTcmp2TG1CR3lGa3ZMbFRo?=
 =?utf-8?B?cTJ1NExGTmF6NGlUdUN1N2tHQ3U0SWZyMzM1M3d0N0JGNTVIL0FucXFFNlM0?=
 =?utf-8?B?c2t4TDVFQ21mdjA5WHl0cERiV242alJ4eG1iY3E1L045cnM3dzZCT0daRTV6?=
 =?utf-8?B?OWFwb21DTlh3ZEltSitnSjZLSGZ0WS9WcWcrRDBOYkgvL3c0dUVLdEFPQUVp?=
 =?utf-8?B?Wk1sRmdFKzdHVC82anFkcTl1YXh0Q3hVUGtlcmV3YW1pWS94WE1UaTNUYk9J?=
 =?utf-8?B?VGU3Tk5idW9BT2VwbTIwenZ4TzQ4VWhWTGlWandGTER1MkV2dTdWRXJnOXhh?=
 =?utf-8?B?TDJFWkp2QlZmRFZYL2p4eWRGcnlaWjg1Vk43SVo1NUU3Ykh4bW5QQTlkaXFH?=
 =?utf-8?B?VmJjL2NZMEhSQUF4VmJyNzY3SGc1NEd1cDFIbVhIS1RDSHlXTkdSOHZBSjU2?=
 =?utf-8?B?WTRab2d2RnJraXFKNEtsV0ZlNW85aXNkdGkyd0JUU0NyZGJ4eVJMWHdSc2Q4?=
 =?utf-8?B?Y05NY1pPaEczWXVleStEVU5KWGl5UXhIMGQ1c3prcUtZOWZZeWI4WHhmcW11?=
 =?utf-8?B?RWs3TEQ3RHhWb21Md0dmRWJqSFBlNFpwdTRDTGhHR1QrbE41bmp0bTVjQ1Ft?=
 =?utf-8?B?L09iWGFIWFVsVHJXUTk2WkRIRlM3OFp3eHkvdkNBeFNiTTNPMy9XMmR6TytF?=
 =?utf-8?B?bXdjWGoyeGxNVHZzQ0hPWEVlZFIxODhLc0VheHhkMEN5RlJpMVVNQjBUaThC?=
 =?utf-8?B?WE92cCtPWENTenRRYzduZVpDemNydnlDeGRrTDMvQjlINzM2STl4Tm1mTUo4?=
 =?utf-8?B?b1FpdnpQYzMvQ0ZCYVFaWHplN09qb2U0cERIbGI4bWxwQW9PNnpIOFJDNTZJ?=
 =?utf-8?B?NmtDbEJIYlFTWWV5MCtSbUR4NzBVdmZwQmc5ekJiaWZYalB5SVMra3BYZDdz?=
 =?utf-8?B?YS9Zd1RxWExkOENsZWo2Tlp2UnRFQTNLZTJPT05TcEF3V3pnTnowamZCcGdK?=
 =?utf-8?B?QnB0ZGhoRGV2bk10WFh4NmRaeDg1NSt5ZVJ4K21JTkkwZzZweEV3UzdQQTVm?=
 =?utf-8?B?bjlxQlNKYTZaSG11VVY5WFdSclVTdGt5eWpQd0drU2h3WDVhM2lLSHZOanFN?=
 =?utf-8?B?UUVid0xmdysvWFo5WllnVWNyQ3JJb1lWM0p3akxObUkyck1IaENtTUdud055?=
 =?utf-8?B?am8wUWhockhCdm5RVDBIeEd0WUtJWFJ6NjRBQkFQTTBObG1pV1A1ZXVEZ29Z?=
 =?utf-8?B?T3FZcysvMUhBT1RoQnJxUWQzdDZySjQ2eExRa09udlVhR2RYVi9qTWE1RVVo?=
 =?utf-8?B?dGl6Z25IVjJ2TVEzT2pxYXE5NmI0QWFSbHBURElzR3ZaQlUzdENQbEJNVVpx?=
 =?utf-8?B?Z3lYR0V3NDAwMjBTNzYyTzkyaHlobCs3Nlh3LzZOUWxkVFltdVE3YTlFdFlo?=
 =?utf-8?B?Zm9pODdmV2dRU0FPaXhURmtzbzhXeEJxQXFOSmFJYVhtREcxYzQ4eDRmTWVL?=
 =?utf-8?B?d25IUUpTTlphbm04MkdZejhGWVpXaGhUL0FyWnd2LzYwRDRhQkFQdWxyVWJ2?=
 =?utf-8?B?QVRWODJjYk1oRUdzblhHMkVhNHRtakdqNEdST0Z1TnhjS1hqNm5FTnRWTmJW?=
 =?utf-8?B?OC9KWVJRSmh5YUpFSXJQVVB4V0ZQSUEySjZMeWIyS3hZblFZc3JHV1E2U1Ja?=
 =?utf-8?B?RjREYzhwM2xrUThxR0xZckoxNkVRenQ5ak90bW1BS05YblpiMU43eHpzNkxP?=
 =?utf-8?B?dkp1ODJKMHp5WGVjb1FPZXZQSWN3NExGYVBQMHUxZmZhSUJnR0ZjU2NvcVZu?=
 =?utf-8?B?Mlh4Z0xMbGlUanRkOXF3ekdqZTRBZHNmUzQ3a09UdWpVU0JlVnJNMENlZXd0?=
 =?utf-8?B?U0hwTE0wOUVpamtnTTNQNS9sRVkybFdzR0RXOFR3dWViV1g4bG1BQVdnaFlV?=
 =?utf-8?B?SFlBVkR6SVUzZWVPVTlqT0V6WjhWcGVwTGp3V3pPV0tiVHl1WmVTNkJLVXhm?=
 =?utf-8?Q?+8RcNPhcXOGgN7qVDIH93dcSGwWTTc=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(376014)(7416014)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Dec 2024 13:56:11.4268
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0f1e3bd2-f9be-42a9-bf02-08dd1dd96623
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH1PEPF0000AD81.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7582



On 13/12/2024 17:28, Carlo Nonato wrote:
> 
> 
> Xen image is relocated to a new colored physical space. Some relocation
> functionalities must be brought back:
> - the virtual address of the new space is taken from 0c18fb76323b
>   ("xen/arm: Remove unused BOOT_RELOC_VIRT_START").
> - relocate_xen() and get_xen_paddr() are taken from f60658c6ae47
>   ("xen/arm: Stop relocating Xen").
> 
> setup_pagetables() must be adapted for coloring and for relocation. Runtime
> page tables are used to map the colored space, but they are also linked in
> boot tables so that the new space is temporarily available for relocation.
> This implies that Xen protection must happen after the copy.
> 
> Finally, since the alternative framework needs to remap the Xen text and
> inittext sections, this operation must be done in a coloring-aware way.
> The function xen_remap_colored() is introduced for that.
> 
> Signed-off-by: Carlo Nonato 
> Signed-off-by: Marco Solieri 
> Reviewed-by: Jan Beulich  # common
> ---
> v12:
> - FUNC instead of ENTRY in head.S for relocate_xen
> - dc cvau instead of dc cvav in relocate_xen()
> - added relocate_and_switch_ttbr() to make setup_pagetables() code more clear
> v11:
> - else if -> if in xen_colored_mfn()
> v10:
> - no changes
> v9:
> - patch adapted to changes to setup_pagetables()
> v8:
> - moved xen_colored_map_size() to arm/llc-coloring.c
> v7:
> - added BUG_ON() checks to arch_llc_coloring_init() and
>   create_llc_coloring_mappings()
> v6:
> - squashed with BOOT_RELOC_VIRT_START patch
> - consider_modules() moved in another patch
> - removed psci and smpboot code because of new idmap work already handles that
> - moved xen_remap_colored() in alternative.c since it's only used there
> - removed xen_colored_temp[] in favor of xen_xenmap[] usage for mapping
> - use of boot_module_find_by_kind() to remove the need of extra parameter in
>   setup_pagetables()
> - moved get_xen_paddr() in arm/llc-coloring.c since it's only used there
> v5:
> - FIXME: consider_modules copy pasted since it got moved
> v4:
> - removed set_value_for_secondary() because it was wrongly cleaning cache
> - relocate_xen() now calls switch_ttbr_id()
> ---
>  xen/arch/arm/alternative.c            |  26 ++++++-
>  xen/arch/arm/arm64/mmu/head.S         |  58 ++++++++++++++-
>  xen/arch/arm/arm64/mmu/mm.c           |  29 ++++++++
>  xen/arch/arm/include/asm/mmu/layout.h |   3 +
>  xen/arch/arm/include/asm/mmu/mm.h     |   1 +
>  xen/arch/arm/llc-coloring.c           |  63 ++++++++++++++++
>  xen/arch/arm/mmu/setup.c              | 103 ++++++++++++++++++++++----
>  xen/arch/arm/setup.c                  |  10 ++-
>  xen/common/llc-coloring.c             |  18 +++++
>  xen/include/xen/llc-coloring.h        |  13 ++++
>  10 files changed, 304 insertions(+), 20 deletions(-)
> 
> diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
> index fec7dbd2cd..2c1af6e7e4 100644
> --- a/xen/arch/arm/alternative.c
> +++ b/xen/arch/arm/alternative.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -191,6 +192,25 @@ static int __apply_alternatives_multi_stop(void *xenmap)
>      return 0;
>  }
> 
> +static void __init *xen_remap_colored(mfn_t xen_mfn, paddr_t xen_size)
> +{
> +    unsigned int i;
> +    void *xenmap;
> +    mfn_t *xen_colored_mfns, mfn;
> +
> +    xen_colored_mfns = xmalloc_array(mfn_t, xen_size >> PAGE_SHIFT);
> +    if ( !xen_colored_mfns )
> +        panic("Can't allocate LLC colored MFNs\n");
> +
> +    for_each_xen_colored_mfn ( xen_mfn, mfn, i )
> +        xen_colored_mfns[i] = mfn;
> +
> +    xenmap = vmap(xen_colored_mfns, xen_size >> PAGE_SHIFT);
> +    xfree(xen_colored_mfns);
> +
> +    return xenmap;
> +}
> +
>  /*
>   * This function should only be called during boot and before CPU0 jump
>   * into the idle_loop.
> @@ -209,7 +229,11 @@ void __init apply_alternatives_all(void)
>       * The text and inittext section are read-only. So re-map Xen to
>       * be able to patch the code.
>       */
> -    xenmap = vmap_contig(xen_mfn, 1U << xen_order);
> +    if ( llc_coloring_enabled )
> +        xenmap = xen_remap_colored(xen_mfn, xen_size);
> +    else
> +        xenmap = vmap_contig(xen_mfn, 1U << xen_order);
> +
>      /* Re-mapping Xen is not expected to fail during boot. */
>      BUG_ON(!xenmap);
> 
> diff --git a/xen/arch/arm/arm64/mmu/head.S b/xen/arch/arm/arm64/mmu/head.S
> index 665a51a337..634156f83d 100644
> --- a/xen/arch/arm/arm64/mmu/head.S
> +++ b/xen/arch/arm/arm64/mmu/head.S
> @@ -428,6 +428,61 @@ FUNC_LOCAL(fail)
>          b     1b
>  END(fail)
> 
> +/*
> + * Copy Xen to new location and switch TTBR
> + * x0    ttbr
> + * x1    source address
> + * x2    destination address
> + * x3    length
> + *
> + * Source and destination must be word aligned, length is rounded up
> + * to a 16 byte boundary.
> + *
> + * MUST BE VERY CAREFUL when saving things to RAM over the copy
> + */
> +FUNC(relocate_xen)
> +        /*
> +         * Copy 16 bytes at a time using:
> +         *   x9: counter
> +         *   x10: data
> +         *   x11: data
> +         *   x12: source
> +         *   x13: destination
> +         */
> +        mov     x9, x3
> +        mov     x12, x1
> +        mov     x13, x2
> +
> +1:      ldp     x10, x11, [x12], #16
> +        stp     x10, x11, [x13], #16
> +
> +        subs    x9, x9, #16
> +        bgt     1b
> +
> +        /*
> +         * Flush destination from dcache using:
> +         *   x9: counter
> +         *   x10: step
> +         *   x11: vaddr
> +         *
> +         * This is to ensure data is visible to the instruction cache
> +         */
> +        dsb   sy
> +
> +        mov   x9, x3
> +        ldr   x10, =dcache_line_bytes /* x10 := step */
> +        ldr   x10, [x10]
> +        mov   x11, x2
> +
> +1:      dc    cvau, x11
> +
> +        add   x11, x11, x10
> +        subs  x9, x9, x10
> +        bgt   1b
> +
> +        /* No need for dsb/isb because they are alredy done in switch_ttbr_id */
> +        b switch_ttbr_id
> +
>  /*
>   * Switch TTBR
>   *
> @@ -453,7 +508,8 @@ FUNC(switch_ttbr_id)
> 
>          /*
>           * 5) Flush I-cache
> -         * This should not be necessary but it is kept for safety.
> +         * This should not be necessary in the general case, but it's needed
> +         * for cache coloring because code is relocated in that case.
>           */
>          ic     iallu
>          isb
> diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c
> index 671eaadbc1..f1f2543902 100644
> --- a/xen/arch/arm/arm64/mmu/mm.c
> +++ b/xen/arch/arm/arm64/mmu/mm.c
> @@ -1,6 +1,7 @@
>  /* SPDX-License-Identifier: GPL-2.0-only */
> 
>  #include 
> +#include 
>  #include 
>  #include 
> 
> @@ -138,8 +139,36 @@ void update_boot_mapping(bool enable)
>  }
> 
>  extern void switch_ttbr_id(uint64_t ttbr);
> +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len);
> 
>  typedef void (switch_ttbr_fn)(uint64_t ttbr);
> +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t len);
> +
> +void __init relocate_and_switch_ttbr(uint64_t ttbr) {
CODING_STYLE: { needs to be on its own line

Also, this function is only executed in case of LLC coloring, so shouldn't it
be #ifdef protected.

> +    vaddr_t id_addr = virt_to_maddr(relocate_xen);
> +    relocate_xen_fn *fn = (relocate_xen_fn *)id_addr;
> +    lpae_t pte;
> +
> +    /* Enable the identity mapping in the boot page tables */
> +    update_identity_mapping(true);
> +
> +    /* Enable the identity mapping in the runtime page tables */
> +    pte = pte_of_xenaddr((vaddr_t)relocate_xen);
> +    pte.pt.table = 1;
> +    pte.pt.xn = 0;
> +    pte.pt.ro = 1;
> +    write_pte(&xen_third_id[third_table_offset(id_addr)], pte);
> +
> +    /* Relocate Xen and switch TTBR */
> +    fn(ttbr, _start, (void *)BOOT_RELOC_VIRT_START, _end - _start);
> +
> +    /*
> +     * Disable the identity mapping in the runtime page tables.
> +     * Note it is not necessary to disable it in the boot page tables
> +     * because they are not going to be used by this CPU anymore.
> +     */
> +    update_identity_mapping(false);
> +}
> 
>  void __init switch_ttbr(uint64_t ttbr)
>  {
> diff --git a/xen/arch/arm/include/asm/mmu/layout.h b/xen/arch/arm/include/asm/mmu/layout.h
> index a3b546465b..19c0ec63a5 100644
> --- a/xen/arch/arm/include/asm/mmu/layout.h
> +++ b/xen/arch/arm/include/asm/mmu/layout.h
> @@ -30,6 +30,7 @@
>   *  10M -  12M   Fixmap: special-purpose 4K mapping slots
>   *  12M -  16M   Early boot mapping of FDT
>   *  16M -  18M   Livepatch vmap (if compiled in)
> + *  16M -  24M   Cache-colored Xen text, data, bss (temporary, if compiled in)
>   *
>   *   1G -   2G   VMAP: ioremap and early_ioremap
>   *
> @@ -74,6 +75,8 @@
>  #define BOOT_FDT_VIRT_START     (FIXMAP_VIRT_START + FIXMAP_VIRT_SIZE)
>  #define BOOT_FDT_VIRT_SIZE      _AT(vaddr_t, MB(4))
> 
> +#define BOOT_RELOC_VIRT_START   (BOOT_FDT_VIRT_START + BOOT_FDT_VIRT_SIZE)
> +
>  #ifdef CONFIG_LIVEPATCH
>  #define LIVEPATCH_VMAP_START    (BOOT_FDT_VIRT_START + BOOT_FDT_VIRT_SIZE)
>  #define LIVEPATCH_VMAP_SIZE    _AT(vaddr_t, MB(2))
> diff --git a/xen/arch/arm/include/asm/mmu/mm.h b/xen/arch/arm/include/asm/mmu/mm.h
> index c5e03a66bf..f5a00558c4 100644
> --- a/xen/arch/arm/include/asm/mmu/mm.h
> +++ b/xen/arch/arm/include/asm/mmu/mm.h
> @@ -31,6 +31,7 @@ void dump_pt_walk(paddr_t ttbr, paddr_t addr,
> 
>  /* Switch to a new root page-tables */
>  extern void switch_ttbr(uint64_t ttbr);
> +extern void relocate_and_switch_ttbr(uint64_t ttbr);
> 
>  #endif /* __ARM_MMU_MM_H__ */
> 
> diff --git a/xen/arch/arm/llc-coloring.c b/xen/arch/arm/llc-coloring.c
> index 1c7b92bc45..7cb4ecb50e 100644
> --- a/xen/arch/arm/llc-coloring.c
> +++ b/xen/arch/arm/llc-coloring.c
> @@ -9,6 +9,7 @@
>  #include 
> 
>  #include 
> +#include 
>  #include 
>  #include 
> 
> @@ -64,8 +65,70 @@ unsigned int __init get_llc_way_size(void)
>      return line_size * num_sets;
>  }
> 
> +/**
Incorrect comment style. Should be /*

> + * get_xen_paddr - get physical address to relocate Xen to
> + *
> + * Xen is relocated to as near to the top of RAM as possible and
> + * aligned to a XEN_PADDR_ALIGN boundary.
> + */
> +static paddr_t __init get_xen_paddr(paddr_t xen_size)
> +{
> +    const struct membanks *mem = bootinfo_get_mem();
> +    paddr_t min_size, paddr = 0;
> +    unsigned int i;
> +
> +    min_size = ROUNDUP(xen_size, XEN_PADDR_ALIGN);
> +
> +    /* Find the highest bank with enough space. */
> +    for ( i = 0; i < mem->nr_banks; i++ )
> +    {
> +        const struct membank *bank = &mem->bank[i];
> +        paddr_t s, e;
> +
> +        if ( bank->size >= min_size )
> +        {
> +            e = consider_modules(bank->start, bank->start + bank->size,
> +                                 min_size, XEN_PADDR_ALIGN, 0);
> +            if ( !e )
> +                continue;
> +
> +#ifdef CONFIG_ARM_32
> +            /* Xen must be under 4GB */
> +            if ( e > GB(4) )
> +                e = GB(4);
> +            if ( e < bank->start )
> +                continue;
> +#endif
> +
> +            s = e - min_size;
> +
> +            if ( s > paddr )
> +                paddr = s;
> +        }
> +    }
> +
> +    if ( !paddr )
> +        panic("Not enough memory to relocate Xen\n");
> +
> +    printk("Placing Xen at 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
> +           paddr, paddr + min_size);
> +
> +    return paddr;
> +}
> +
> +static paddr_t __init xen_colored_map_size(void)
> +{
> +    return ROUNDUP((_end - _start) * get_max_nr_llc_colors(), XEN_PADDR_ALIGN);
> +}
> +
>  void __init arch_llc_coloring_init(void)
>  {
> +    struct bootmodule *xen_bootmodule = boot_module_find_by_kind(BOOTMOD_XEN);
> +
> +    BUG_ON(!xen_bootmodule);
> +
> +    xen_bootmodule->size = xen_colored_map_size();
> +    xen_bootmodule->start = get_xen_paddr(xen_bootmodule->size);
>  }
> 
>  /*
> diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c
> index 196974f3e2..073f762a32 100644
> --- a/xen/arch/arm/mmu/setup.c
> +++ b/xen/arch/arm/mmu/setup.c
> @@ -7,6 +7,7 @@
> 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -20,6 +21,9 @@
>  #undef virt_to_mfn
>  #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
> 
> +#define virt_to_reloc_virt(virt) \
> +    (((vaddr_t)virt) - XEN_VIRT_START + BOOT_RELOC_VIRT_START)
You need to enclose 'virt' in paranthesis.

> +
>  /* Main runtime page tables */
> 
>  /*
> @@ -69,6 +73,7 @@ static void __init __maybe_unused build_assertions(void)
>      /* 2MB aligned regions */
>      BUILD_BUG_ON(XEN_VIRT_START & ~SECOND_MASK);
>      BUILD_BUG_ON(FIXMAP_ADDR(0) & ~SECOND_MASK);
> +    BUILD_BUG_ON(BOOT_RELOC_VIRT_START & ~SECOND_MASK);
>      /* 1GB aligned regions */
>  #ifdef CONFIG_ARM_32
>      BUILD_BUG_ON(XENHEAP_VIRT_START & ~FIRST_MASK);
> @@ -138,6 +143,9 @@ static void __init __maybe_unused build_assertions(void)
> 
>  lpae_t __init pte_of_xenaddr(vaddr_t va)
>  {
> +    if ( llc_coloring_enabled )
> +        va = virt_to_reloc_virt(va);
> +
>      return mfn_to_xen_entry(virt_to_mfn(va), MT_NORMAL);
>  }
> 
> @@ -316,6 +324,32 @@ paddr_t __init consider_modules(paddr_t s, paddr_t e,
>      return e;
>  }
> 
> +static void __init create_llc_coloring_mappings(void)
Shouldn't this be #ifdef protected and stub provided if config disabled?.

> +{
> +    lpae_t pte;
> +    unsigned int i;
> +    struct bootmodule *xen_bootmodule = boot_module_find_by_kind(BOOTMOD_XEN);
> +    mfn_t start_mfn = maddr_to_mfn(xen_bootmodule->start), mfn;
> +
> +    for_each_xen_colored_mfn ( start_mfn, mfn, i )
> +    {
> +        pte = mfn_to_xen_entry(mfn, MT_NORMAL);
> +        pte.pt.table = 1; /* level 3 mappings always have this bit set */
> +        xen_xenmap[i] = pte;
> +    }
> +
> +    for ( i = 0; i < XEN_NR_ENTRIES(2); i++ )
> +    {
> +        vaddr_t va = BOOT_RELOC_VIRT_START + (i << XEN_PT_LEVEL_SHIFT(2));
> +
> +        pte = mfn_to_xen_entry(virt_to_mfn(xen_xenmap +
> +                                           i * XEN_PT_LPAE_ENTRIES),
> +                               MT_NORMAL);
> +        pte.pt.table = 1;
> +        write_pte(&boot_second[second_table_offset(va)], pte);
> +    }
> +}
> +
>  /*
>   * Boot-time pagetable setup.
>   * Changes here may need matching changes in head.S
> @@ -326,6 +360,14 @@ void __init setup_pagetables(void)
>      lpae_t pte, *p;
>      int i;
> 
> +    /*
> +     * In case of cache coloring, map the new physical space in the boot page
> +     * tables. From now on, pte_of_xenaddr() will translate addresses to this
> +     * new space.
> +     */
> +    if ( llc_coloring_enabled )
> +        create_llc_coloring_mappings();
> +
>      arch_setup_page_tables();
> 
>  #ifdef CONFIG_ARM_64
> @@ -353,13 +395,7 @@ void __init setup_pagetables(void)
>              break;
>          pte = pte_of_xenaddr(va);
>          pte.pt.table = 1; /* third level mappings always have this bit set */
> -        if ( is_kernel_text(va) || is_kernel_inittext(va) )
> -        {
> -            pte.pt.xn = 0;
> -            pte.pt.ro = 1;
> -        }
> -        if ( is_kernel_rodata(va) )
> -            pte.pt.ro = 1;
> +        pte.pt.xn = 0; /* Permissions will be enforced later. Allow execution */
>          xen_xenmap[i] = pte;
>      }
> 
> @@ -379,19 +415,54 @@ void __init setup_pagetables(void)
>      pte.pt.table = 1;
>      xen_second[second_table_offset(FIXMAP_ADDR(0))] = pte;
> 
> -#ifdef CONFIG_ARM_64
> -    ttbr = virt_to_maddr(xen_pgtable);
> -#else
> -    ttbr = virt_to_maddr(cpu0_pgtable);
> +#ifdef CONFIG_ARM_32
> +    per_cpu(xen_pgtable, 0) = cpu0_pgtable;
>  #endif
> 
> -    switch_ttbr(ttbr);
> +    if ( llc_coloring_enabled ) {
CODING_STYLE: { needs to be on its own line

> +        ttbr = virt_to_maddr(virt_to_reloc_virt(THIS_CPU_PGTABLE));
> +        relocate_and_switch_ttbr(ttbr);
> +    }
> +    else {
CODING_STYLE: { needs to be on its own line

> +        ttbr = virt_to_maddr(THIS_CPU_PGTABLE);
> +        switch_ttbr(ttbr);
> +    }
> 
> -    xen_pt_enforce_wnx();
> +    /* Protect Xen */
> +    for ( i = 0; i < XEN_NR_ENTRIES(3); i++ )
> +    {
> +        vaddr_t va = XEN_VIRT_START + (i << PAGE_SHIFT);
> +        lpae_t *entry = xen_xenmap + i;
> 
> -#ifdef CONFIG_ARM_32
> -    per_cpu(xen_pgtable, 0) = cpu0_pgtable;
> -#endif
> +        if ( !is_kernel(va) )
> +            break;
> +
> +        pte = read_atomic(entry);
> +
> +        if ( is_kernel_text(va) || is_kernel_inittext(va) )
> +        {
> +            pte.pt.xn = 0;
> +            pte.pt.ro = 1;
> +        }
> +        else if ( is_kernel_rodata(va) ) {
CODING_STYLE: { needs to be on its own line

> +            pte.pt.ro = 1;
> +            pte.pt.xn = 1;
> +        }
> +        else {
CODING_STYLE: { needs to be on its own line

> +            pte.pt.xn = 1;
> +            pte.pt.ro = 0;
> +        }
> +
> +        write_pte(entry, pte);
> +    }
> +
> +    /*
> +     * We modified live page-tables. Ensure the TLBs are invalidated
> +     * before setting enforcing the WnX permissions.
> +     */
> +    flush_xen_tlb_local();
> +
> +    xen_pt_enforce_wnx();
>  }
> 
>  void *__init arch_vmap_virt_end(void)
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 568a49b274..5e2c519ce8 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -304,8 +304,6 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr)
>      /* Initialize traps early allow us to get backtrace when an error occurred */
>      init_traps();
> 
> -    setup_pagetables();
> -
>      smp_clear_cpu_maps();
> 
>      device_tree_flattened = early_fdt_map(fdt_paddr);
> @@ -329,6 +327,14 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr)
> 
>      llc_coloring_init();
> 
> +    /*
> +     * Page tables must be setup after LLC coloring initialization because
> +     * coloring info are required in order to create colored mappings
> +     */
> +    setup_pagetables();
> +    /* Device-tree was mapped in boot page tables, remap it in the new tables */
> +    device_tree_flattened = early_fdt_map(fdt_paddr);
> +
>      setup_mm();
> 
>      vm_init();
> diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
> index ff4837fcc6..545d8b49e8 100644
> --- a/xen/common/llc-coloring.c
> +++ b/xen/common/llc-coloring.c
> @@ -42,6 +42,8 @@ static unsigned int __ro_after_init xen_num_colors;
> 
>  #define mfn_color_mask              (max_nr_colors - 1)
>  #define mfn_to_color(mfn)           (mfn_x(mfn) & mfn_color_mask)
> +#define get_mfn_with_color(mfn, color) \
> +    (_mfn((mfn_x(mfn) & ~mfn_color_mask) | (color)))
> 
>  /*
>   * Parse the coloring configuration given in the buf string, following the
> @@ -364,6 +366,22 @@ unsigned int get_max_nr_llc_colors(void)
>      return max_nr_colors;
>  }
> 
> +mfn_t __init xen_colored_mfn(mfn_t mfn)
> +{
> +    unsigned int i, color = mfn_to_color(mfn);
> +
> +    for ( i = 0; i < xen_num_colors; i++ )
> +    {
> +        if ( color == xen_colors[i] )
> +            return mfn;
> +        if ( color < xen_colors[i] )
> +            return get_mfn_with_color(mfn, xen_colors[i]);
> +    }
> +
> +    /* Jump to next color space (max_nr_colors mfns) and use the first color */
> +    return get_mfn_with_color(mfn_add(mfn, max_nr_colors), xen_colors[0]);
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
> index 1216d1fbd4..30c8a1d9a6 100644
> --- a/xen/include/xen/llc-coloring.h
> +++ b/xen/include/xen/llc-coloring.h
> @@ -8,6 +8,7 @@
>  #ifndef __XEN_LLC_COLORING_H__
>  #define __XEN_LLC_COLORING_H__
> 
> +#include 
>  #include 
> 
>  struct domain;
> @@ -30,6 +31,17 @@ static inline void domain_dump_llc_colors(const struct domain *d) {}
>  static inline void domain_llc_coloring_free(struct domain *d) {}
>  #endif
> 
> +/**
> + * Iterate over each Xen mfn in the colored space.
> + * @start_mfn:  the first mfn that needs to be colored.
> + * @mfn:        the current mfn.
> + * @i:          loop index.
> + */
> +#define for_each_xen_colored_mfn(start_mfn, mfn, i) \
> +    for ( i = 0, mfn = xen_colored_mfn(start_mfn);  \
Here and elsewhere you need to enclose 'i' in paranthesis. Otherwise ECLAIR will report 20.7 violation.

> +          i < (_end - _start) >> PAGE_SHIFT;        \
> +          i++, mfn = xen_colored_mfn(mfn_add(mfn, 1)) )
> +
>  unsigned int get_llc_way_size(void);
>  void arch_llc_coloring_init(void);
>  int dom0_set_llc_colors(struct domain *d);
> @@ -38,6 +50,7 @@ int domain_set_llc_colors(struct domain *d,
>  int domain_set_llc_colors_from_str(struct domain *d, const char *str);
>  unsigned int page_to_llc_color(const struct page_info *pg);
>  unsigned int get_max_nr_llc_colors(void);
> +mfn_t xen_colored_mfn(mfn_t mfn);
> 
>  #endif /* __XEN_LLC_COLORING_H__ */
> 
> --
> 2.43.0
> 

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 13:57:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 13:57:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858073.1270318 (Exim 4.92)
	(envelope-from )
	id 1tNBbR-0003wf-Qn; Mon, 16 Dec 2024 13:57:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858073.1270318; Mon, 16 Dec 2024 13:57: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 1tNBbR-0003wY-OI; Mon, 16 Dec 2024 13:57:41 +0000
Received: by outflank-mailman (input) for mailman id 858073;
 Mon, 16 Dec 2024 13:57: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 1tNBbQ-0003wJ-V3
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 13:57:40 +0000
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [2a00:1450:4864:20::530])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b5a55e1d-bbb5-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 14:57:38 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5d3e6274015so7217725a12.0
 for ; Mon, 16 Dec 2024 05:57:38 -0800 (PST)
Received: from ?IPV6:2003:e5:8725:5e00:fa69:c5cb:46d:3e5b?
 (p200300e587255e00fa69c5cb046d3e5b.dip0.t-ipconnect.de.
 [2003:e5:8725:5e00:fa69:c5cb:46d:3e5b])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d652ae1205sm3210615a12.44.2024.12.16.05.57.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 05:57: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: b5a55e1d-bbb5-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734357458; x=1734962258; 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=I6mLb53qXQ+6q8Wws9RLDGZ6bIRw/j/samqfJuSBVMo=;
        b=F7caVi6FgrkatBViEGhnFtVoIhktglKKtEYlEyqXsp5XhlChVXGgMgKo1WGtrycvnr
         0LRzdCjeivMcmmASgMGTR6CrnxAB590y21u9NBz98r123m4HN/TG4nsLx5PJPnkj3sSe
         y2FeObuQzJc5ItKczlG6su8JuNF7FdTPqqjFMaSoYWZOdIeshXjHSdc7wB0tSMXSvjpR
         RCKbw6uYd1zDLe810bZTcLiYOmJfEr78rwq7Q9GmO56HY3rqL+I2GBTqb5wPHtGm8XjQ
         urwSHHMBiJB5UhnAyeKk3Mdc7ff0Vymp/Bhc8xuzAfu1V8T18zAaNFibBza5VjV4jt0w
         Nycg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734357458; x=1734962258;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=I6mLb53qXQ+6q8Wws9RLDGZ6bIRw/j/samqfJuSBVMo=;
        b=uxdLsDx+sz0eSYC6wwURwN91icRDGpuo3bexorsyK0Fh9y3qHzMQ0p7QJ1tLLnFmdB
         tK/9xSh2UmO9bfwToCj/ZzqjNR37Uhk5N9znifPyA3s55f2hi/RBwns4S1mjEVPExpdW
         7v4Y9iGDNUKB/TpcGPR98WeB2zCmTC397LbNdvnpjGVYfbM406mhEVXorJAaBh2nEzZ8
         nVvsNE9Nrr1NgmEnQAlHKnT2As9T9so0I8lhXsYKUGVFi9RogNiWNaTObClOFWroPJ69
         zvMsNWPs8NrkxQAtzadvxj7fPDP9jhmBU1nqEKd3Jhho9OpE3f0mBe25Z4Uie7vcSl56
         jGxA==
X-Forwarded-Encrypted: i=1; AJvYcCUCMdk0t4cQchIsbRFm8ndjCDpcHlOCVJ8gPpbauxYo1TTEiUjj/yUwXjGeKREbHueXXwmff2Ya9dc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxhRnDvoJXDHY3TIQum8h8+E/ID93z+fayILc3jANTHk6benlxC
	Ca6zOA1SJK2p/32GgWIDxaKAfRK63fVlX4fYayMuCW50MmuUInM7ak3I276wNy4=
X-Gm-Gg: ASbGncs+v5kV9UOawCF+6wxjw2iHTW/tmKqWTX58eHnVtlB+sbTjkaRusp6b34KZDwj
	W75JegDmBamptGCNtJlzq2ujBDTXDgvyTGSwuIznKgSL+otKkcj8kPKHl6SnB83EG2gVU3/ZLQF
	DgDpUcnHD5u/3lo24g0cRzOdeMtGaeqtmY0+yJd6LFEFbUSuvctn3VDeoVz5LteMT4CLpKiAsIH
	KupVDIDrFZGg4S6U8JG5IblHT3S4JxkrC/oAiQIfzsXXQUWY76r/22rQai6PkYrMY8ftoqJe/e7
	v0edwd1i1FoIzQ+OhJAhPIrE+leLAxip6QD+XWU8EHm0pN4qWh/H0U/Av+xQDXi3BsteyAfhV6S
	/rvM=
X-Google-Smtp-Source: AGHT+IH7Wb1odvwKa50nm+iSwmMGFmyrwdhsYw89QnviTrN0/Zp7bEUFgUKzw+NgRcxBMUwyQ5TttA==
X-Received: by 2002:a05:6402:354d:b0:5cf:ab23:1f07 with SMTP id 4fb4d7f45d1cf-5d63c320f8fmr10455703a12.15.1734357457816;
        Mon, 16 Dec 2024 05:57:37 -0800 (PST)
Message-ID: 
Date: Mon, 16 Dec 2024 14:57:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 5/7] xen: add new domctl get_changed_domain
To: Jan Beulich 
Cc: "Daniel P. Smith" ,
 Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241213162421.16782-1-jgross@suse.com>
 <20241213162421.16782-6-jgross@suse.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: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------WGwiqnZwB75dvyYz0jf1cBnY"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------WGwiqnZwB75dvyYz0jf1cBnY
Content-Type: multipart/mixed; boundary="------------v67u5DqhRdNvFXAGOgeLhb9N";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jan Beulich 
Cc: "Daniel P. Smith" ,
 Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
Message-ID: 
Subject: Re: [PATCH v3 5/7] xen: add new domctl get_changed_domain
References: <20241213162421.16782-1-jgross@suse.com>
 <20241213162421.16782-6-jgross@suse.com>
 
In-Reply-To: 
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------v67u5DqhRdNvFXAGOgeLhb9N
Content-Type: multipart/mixed; boundary="------------y6WUQ276IJkKlliwTc0kZT0u"

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

T24gMTYuMTIuMjQgMTE6NDEsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxMy4xMi4yMDI0
IDE3OjI0LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gLS0tIGEveGVuL2NvbW1vbi9kb21h
aW4uYw0KPj4gKysrIGIveGVuL2NvbW1vbi9kb21haW4uYw0KPj4gQEAgLTE5Myw2ICsxOTMs
NTcgQEAgc3RhdGljIHZvaWQgZG9tYWluX2NoYW5nZWRfc3RhdGUoY29uc3Qgc3RydWN0IGRv
bWFpbiAqZCkNCj4+ICAgICAgIHNwaW5fdW5sb2NrKCZkb21fc3RhdGVfY2hhbmdlZF9sb2Nr
KTsNCj4+ICAgfQ0KPj4gICANCj4+ICtzdGF0aWMgdm9pZCBzZXRfZG9tYWluX3N0YXRlX2lu
Zm8oc3RydWN0IHhlbl9kb21jdGxfZ2V0X2RvbWFpbl9zdGF0ZSAqaW5mbywNCj4+ICsgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qgc3RydWN0IGRvbWFpbiAqZCkN
Cj4+ICt7DQo+PiArICAgIGluZm8tPnN0YXRlID0gWEVOX0RPTUNUTF9HRVRET01TVEFURV9T
VEFURV9FWElTVDsNCj4+ICsgICAgaWYgKCBkLT5pc19zaHV0X2Rvd24gKQ0KPj4gKyAgICAg
ICAgaW5mby0+c3RhdGUgfD0gWEVOX0RPTUNUTF9HRVRET01TVEFURV9TVEFURV9TSFVURE9X
TjsNCj4+ICsgICAgaWYgKCBkLT5pc19keWluZyA9PSBET01EWUlOR19keWluZyApDQo+PiAr
ICAgICAgICBpbmZvLT5zdGF0ZSB8PSBYRU5fRE9NQ1RMX0dFVERPTVNUQVRFX1NUQVRFX0RZ
SU5HOw0KPj4gKyAgICBpZiAoIGQtPmlzX2R5aW5nID09IERPTURZSU5HX2RlYWQgKQ0KPj4g
KyAgICAgICAgaW5mby0+c3RhdGUgfD0gWEVOX0RPTUNUTF9HRVRET01TVEFURV9TVEFURV9E
RUFEOw0KPj4gKyAgICBpbmZvLT51bmlxdWVfaWQgPSBkLT51bmlxdWVfaWQ7DQo+PiArfQ0K
Pj4gKw0KPj4gK2ludCBnZXRfZG9tYWluX3N0YXRlKHN0cnVjdCB4ZW5fZG9tY3RsX2dldF9k
b21haW5fc3RhdGUgKmluZm8sIHN0cnVjdCBkb21haW4gKmQsDQo+PiArICAgICAgICAgICAg
ICAgICAgICAgZG9taWRfdCAqZG9taWQpDQo+PiArew0KPj4gKyAgICB1bnNpZ25lZCBpbnQg
ZG9tOw0KPj4gKw0KPj4gKyAgICBpZiAoIGluZm8tPnBhZDAgfHwgaW5mby0+cGFkMSApDQo+
PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsNCj4+ICsgICAgaWYgKCBkICkNCj4+
ICsgICAgew0KPj4gKyAgICAgICAgc2V0X2RvbWFpbl9zdGF0ZV9pbmZvKGluZm8sIGQpOw0K
Pj4gKw0KPj4gKyAgICAgICAgcmV0dXJuIDA7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAg
d2hpbGUgKCAoZG9tID0gZmluZF9maXJzdF9iaXQoZG9tX3N0YXRlX2NoYW5nZWQsIERPTUlE
X01BU0sgKyAxKSkgPA0KPj4gKyAgICAgICAgICAgIERPTUlEX0ZJUlNUX1JFU0VSVkVEICkN
Cj4+ICsgICAgew0KPj4gKyAgICAgICAgaWYgKCB0ZXN0X2FuZF9jbGVhcl9iaXQoZG9tLCBk
b21fc3RhdGVfY2hhbmdlZCkgKQ0KPiANCj4gRm9yIHRoZXNlIHR3byBhY2Nlc3NlcyB0byBk
b21fc3RhdGVfY2hhbmdlZCBkb24ndCB5b3UgbmVlZCB0byBob2xkIHRoZQ0KPiBsb2NrIHBh
dGNoIDQgaW50cm9kdWNlcz8gQWxzbyBkaWRuJ3QgeW91IHNheSB5b3UnZCBjb25zdHJhaW4g
dGhlIG5ldw0KPiBzdWItb3AgdG8gdGhlIHNvbGUgZG9tYWluIGhhdmluZyBWSVJRX0RPTV9F
WEVDIGJvdW5kICh3aGljaCwgZnRhb2QsDQo+IGlzbid0IGVub3VnaCB0byBlbGltaW5hdGUg
dGhlIHJhY2UpPw0KDQpPaCwgaW5kZWVkLiBTb3JyeSBmb3IgaGF2aW5nIG1pc3NlZCBib3Ro
IGFzcGVjdHMuDQoNCj4gDQo+PiArICAgICAgICB7DQo+PiArICAgICAgICAgICAgKmRvbWlk
ID0gZG9tOw0KPj4gKw0KPj4gKyAgICAgICAgICAgIGQgPSByY3VfbG9ja19kb21haW5fYnlf
aWQoZG9tKTsNCj4+ICsNCj4+ICsgICAgICAgICAgICBpZiAoIGQgKQ0KPj4gKyAgICAgICAg
ICAgIHsNCj4+ICsgICAgICAgICAgICAgICAgc2V0X2RvbWFpbl9zdGF0ZV9pbmZvKGluZm8s
IGQpOw0KPj4gKw0KPj4gKyAgICAgICAgICAgICAgICByY3VfdW5sb2NrX2RvbWFpbihkKTsN
Cj4+ICsgICAgICAgICAgICB9DQo+IA0KPiBPaCwgb24gdGhlIGltcGxpY2l0ICJlbHNlIiBp
cyB3aGVyZSB0aGUgb3JpZ2luYWwgbWVtc2V0KCkgd291bGQgY29tZSBpbnRvDQo+IHBsYXk6
IFlvdSB3YW50IHRvIG1ha2Ugc3VyZSBhdCBsZWFzdCAtPnN0YXRlLCBidXQgcGVyaGFwcyBh
bHNvIC0+dW5pcXVlX2lkDQo+IGFyZSBjbGVhcmVkIChyYXRoZXIgdGhhbiBkZW1hbmRpbmcg
dGhlIGNhbGxlciB0byBjbGVhciB0aGVtIGFoZWFkIG9mIG1ha2luZw0KPiB0aGUgY2FsbCku
DQoNClJpZ2h0Lg0KDQoNCkp1ZXJnZW4NCg==
--------------y6WUQ276IJkKlliwTc0kZT0u
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-----

--------------y6WUQ276IJkKlliwTc0kZT0u--

--------------v67u5DqhRdNvFXAGOgeLhb9N--

--------------WGwiqnZwB75dvyYz0jf1cBnY
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/Ey8FAmdgMdAFAwAAAAAACgkQsN6d1ii/Ey9l
dAgAlBvgJwJUYV7DmtBW5murzbEyWslTYhHn3OJTqSSb6gfDjohVvldZ1h7x1U76rSdoIr8BB85M
rL7fpXbvE13VSgz5pvPIQt2ge6sV7gHKfDQneD+87VUS6Mzqx7wtqz/Uozb7XJ+8FXTJNncsSbQZ
kienNgUKI6vdIoSb/yQLTpPzCTgWbANApaLSz1n0/Gsx2uiNfLx1o6/+4YbvtGcm4GG0Je6+RYTE
d+O0hQ/ZAQJi5QYtttPP/Eb3NUhvOLI/GqZV5JNAtS8ZDHMJhAtUoebQktkJCDMlPuDw2+FXSVIy
qRVM2qKPBhbqqJFhjX0OeBOp3HXr57kjkC40VVQBzw==
=FZsU
-----END PGP SIGNATURE-----

--------------WGwiqnZwB75dvyYz0jf1cBnY--


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 14:02:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 14:02:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858085.1270328 (Exim 4.92)
	(envelope-from )
	id 1tNBg5-0005rx-CC; Mon, 16 Dec 2024 14:02:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858085.1270328; Mon, 16 Dec 2024 14: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 1tNBg5-0005rq-8u; Mon, 16 Dec 2024 14:02:29 +0000
Received: by outflank-mailman (input) for mailman id 858085;
 Mon, 16 Dec 2024 14:02: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 1tNBg3-0005rk-IZ
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 14:02:27 +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 60c38d10-bbb6-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 15:02:25 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4361c705434so29576855e9.3
 for ; Mon, 16 Dec 2024 06:02:25 -0800 (PST)
Received: from localhost ([85.152.134.39]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c8060582sm8096186f8f.93.2024.12.16.06.02.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 06:02: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: 60c38d10-bbb6-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1734357745; x=1734962545; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4yOYCFVZVcQRBuxGwcaYwMLPHbIXfU+0oS9iNm76wMI=;
        b=g78HUdkWqNyGFiEifAIrOeZcsYDxkRQRa5hIBlu+I9E6HGVxKuuyOxei7/K7ILRCmp
         Jv606bMgqJcTx2Yx7WQtQJH4JooMGp+43alaaVZ2HtM39SXFyW2gxiltoXdXLYURsN5R
         nTR3qCH8oKJGBv9fVtAld9p8nmg7Hz5pkb+PM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734357745; x=1734962545;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=4yOYCFVZVcQRBuxGwcaYwMLPHbIXfU+0oS9iNm76wMI=;
        b=E8LbRBFUI24CvCW8WnAdsd8OszIQ4FjxURYcY5NWlAXqWjCkdKh+DymFfbxizQpn6X
         yf7GlOwGkX7otRAMPV9wGxRoJV7Phf/AmYEHz1x8Um8Z0Nft0QK/Q0ApdvblcAm5lgAi
         5jCqCSWurT5BmevoLZ0rgIqvcdtlUwskp9iyjceSMPmsxxbH0GlDiw3tPoYFUcyyLsjR
         9AHvJBdVPnmp88hcDqfzNfmwg/bOcc3f+oPNwrQAeaXd5WKP0hjRKCnxYjYL+v5uW+88
         zCkvunhh0AiBWPj46wpIZFPpinkGvBDqhpy5KImXavLChne7GJ2eqRcTeEQtNDERW0sW
         3wYg==
X-Forwarded-Encrypted: i=1; AJvYcCVxHHG+QSVIxTbJkIqsAAtwk2mRdIR33ccGnyMkgz7wvLOyIa9o8oPIN3zqGUJ91q+5LZBLjZ1LHj8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwQtEFNuNpnvs/GCixdN1ctm5R1RkBa2gJunGRYHdYS4B6HSoZj
	FZ4qn3eDspZ8fx4wEZu0iJPrE51MNGQTzwmwXe7V58ne6aLCH/JSp3Xt8eEjvPE=
X-Gm-Gg: ASbGnctztWM5vBI92A75UUKKq6iqDGU6MhYzgp2DV0H3qS0Hwq8nqjFqDl4ln7hgKnw
	g2jzpInwcbp5j02GemJ7y3Z02UMHapWLl5XUbpkrBQKr59Z7GRpbihnou/dFj9y23knBlYH1JL1
	N+JiQ+oByy1tSpotyRVDrQv/pAFo8YZ+5JrK+AEtbpHkdFzW11XQ6CYqYGdUGDw5SKX7b27ERWw
	AaVfEy4/gRcjkNKs54CCTts3Gg2K2+ug5EkSZrdZLu4JwoI8nq+6qkS9Zhu5Co=
X-Google-Smtp-Source: AGHT+IHnzcvLwha3WwzYqyiaJol2bpa26aSbx5TFC/pK85SaeIDiV/BBycX6DcunxTbXSZGNypWyHQ==
X-Received: by 2002:a05:6000:1f82:b0:385:f349:ffe7 with SMTP id ffacd0b85a97d-38880ac4e71mr9377609f8f.2.1734357744464;
        Mon, 16 Dec 2024 06:02:24 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Mon, 16 Dec 2024 14:02:21 +0000
Message-Id: 
Cc: "Andrew Cooper" ,
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= ,
 
Subject: Re: [PATCH v2 10/13] x86/mpx: Map/unmap xsave area in in
 read_bndcfgu()
From: "Alejandro Vallejo" 
To: "Jan Beulich" 
X-Mailer: aerc 0.18.2
References: <20241105143310.28301-1-alejandro.vallejo@cloud.com>
 <20241105143310.28301-11-alejandro.vallejo@cloud.com>
 <7e36137b-ce1f-4e78-9a41-fbfdbe9c0d87@suse.com>
 
 
In-Reply-To: 

On Mon Dec 16, 2024 at 12:03 PM GMT, Jan Beulich wrote:
> On 16.12.2024 13:00, Alejandro Vallejo wrote:
> > On Mon Dec 9, 2024 at 4:30 PM GMT, Jan Beulich wrote:
> >> On 05.11.2024 15:33, Alejandro Vallejo wrote:
> >>> --- a/xen/arch/x86/xstate.c
> >>> +++ b/xen/arch/x86/xstate.c
> >>> @@ -1022,9 +1022,10 @@ int handle_xsetbv(u32 index, u64 new_bv)
> >>> =20
> >>>  uint64_t read_bndcfgu(void)
> >>>  {
> >>> +    uint64_t bndcfgu =3D 0;
> >>>      unsigned long cr0 =3D read_cr0();
> >>> -    struct xsave_struct *xstate
> >>> -        =3D idle_vcpu[smp_processor_id()]->arch.xsave_area;
> >>> +    struct vcpu *v =3D idle_vcpu[smp_processor_id()];
> >>
> >> Can this be pointer-to-const? Certainly right now, so the question is =
rather
> >> meant to be forward looking.
> >>
> >>> +    struct xsave_struct *xstate =3D VCPU_MAP_XSAVE_AREA(v);
> >>
> >> This certainly can be pointer-to-const, just like ...
> >>
> >>>      const struct xstate_bndcsr *bndcsr;
> >>
> >> ... this is.
> >=20
> > Yes, those retained non-const because of the now missing patch to zero-=
out
> > bndcfgu.
>
> I'm afraid this reply is ambiguous as to what's going to happen in the ne=
xt
> version. I can read both "will change" and "needs to stay" into it.
>
> Jan

It was an answer to "Can this be pointer to const?". Yes, I'll put the cons=
t
back.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 14:06:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 14:06:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858095.1270339 (Exim 4.92)
	(envelope-from )
	id 1tNBjX-0006U2-Rw; Mon, 16 Dec 2024 14:06:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858095.1270339; Mon, 16 Dec 2024 14:06: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 1tNBjX-0006Tv-Nn; Mon, 16 Dec 2024 14:06:03 +0000
Received: by outflank-mailman (input) for mailman id 858095;
 Mon, 16 Dec 2024 14:06: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 1tNBjW-0006Tp-FY
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 14:06:02 +0000
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com
 [2607:f8b0:4864:20::22d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e12aae42-bbb6-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 15:06:01 +0100 (CET)
Received: by mail-oi1-x22d.google.com with SMTP id
 5614622812f47-3eb7ecc3c54so2314184b6e.0
 for ; Mon, 16 Dec 2024 06:06:01 -0800 (PST)
Received: from [192.168.4.112] (fixed-187-189-51-143.totalplay.net.
 [187.189.51.143]) by smtp.gmail.com with ESMTPSA id
 5614622812f47-3ebb492a328sm1552586b6e.44.2024.12.16.06.05.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 06:05: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: e12aae42-bbb6-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1734357960; x=1734962760; 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=kSWekSVktEYmf12kc9swILeOvBfo99CjqVpCRN5BqHM=;
        b=jfz7+je/qzzzpB2zT1BMkVzMIcN02ZqycYRy05F+O2ErT/p8QIO+WDJDsd1xfTiX3C
         jkoAPrSZ4C8M2vU0opAXnyqoVeQ0xuvLWZQx75AL9+Edzey3LGKwAGwvM+n3OJ/yG216
         StdWBOcgCgRC1pvKhqtw0YndMC3g8R2XG2CJMtWpL9MtmQQr+CCUXbSO6bLIK2sJ/qVq
         IPcHZTM5N3N748UahL2iGdOYXiOWvp5rG/d44xvHijGLaGScLxVwHO0gBR8onnLQEelQ
         ZyoySZy2UPkk4vMdo6Dk91bINAJau5YBSKqQhNvxeu5JV0OrRkrq8oznY5sGvLTQ/tsC
         QIQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734357960; x=1734962760;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=kSWekSVktEYmf12kc9swILeOvBfo99CjqVpCRN5BqHM=;
        b=OWfCNa6q4GiPznD215zBFk1Y+54PVytA32GuwL/zaZV8ZZp6TjnJfMFNvPEdYwwKqs
         Qg0Clc6rNadmJMoPJCika0B25+eamrwGEWoZQZNH3wNnl1J93PIW/zmk+YnJY0801qr+
         ntO056/84LHp4zIyn2hyEFefCegT86VtvmUbWIiSkd7iuyZnugfkYecbad2wgSE2wSZZ
         ScFc05BZD0JKDl4qdgN1C77SaMNKrHMKQl6Pm4tOeot1qKoBZHs/4hPrHkKb28G3R/qB
         UrDjxEIWCUhALsPziU4J+32JZVUKORPpUZ1YMIYZd/F6EYPmKm0PI0TKA/RJPYGuFRfh
         uCoQ==
X-Forwarded-Encrypted: i=1; AJvYcCUWmnWeVAorcG/v4rNKgsA/DOauOCc8G1DvZugUnj/DejjjUu53KBnAZ51DEZDop8ug0nw0KktOfuo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwlZJg3IszDy9tSCdm9IgcxLd6I3hA8Z83jkWkB6yYYDM0QjDZk
	9OTMSrb2xNf7iqHPMafrmrt9C4el4jyXxOnPqqgQhFFZvsxFTepSxdTGfYQ6KkA=
X-Gm-Gg: ASbGnctwz1yGxIY9+J5XL4p2eFjvrb+NIfLrMIfcMbZ+FWEccQCiaRcQNdUk37MG26W
	SWGKOpFuPRbB4aMV2NIc+Mk8eV+/QTMDLhBxbQyqwzQMhz4UDPh4GvAtB2s6He5f0UJ8blCqk0N
	FkQvJMNntokHA0L/ulCDIFOKr5Nq5TM2LodLtYX1lZTFaLOAjH9tSaI9WNohJlfanxwvHnd84KB
	o5Sa8Nc7k8IslHrKjSMG4G09VDJxfF6zUjMxA9SpqZ8wUmt9mPDtKCzyPhcNrhITJYZdeWnlvFD
	tucMem9qA5ntyoqlCNJ7+dpkq62fqHNMKZc=
X-Google-Smtp-Source: AGHT+IEYZltRF3Xk2M2/eYQrbngda+UogA4Snbi+1SqsSAHFMIXRUkYBThrOo1fnHuEkK/CNGlSqJA==
X-Received: by 2002:a05:6808:bca:b0:3eb:428b:fa5f with SMTP id 5614622812f47-3eba691e695mr5189702b6e.33.1734357960125;
        Mon, 16 Dec 2024 06:06:00 -0800 (PST)
Message-ID: <10d4be0d-1d50-415d-aed8-f71e81098604@linaro.org>
Date: Mon, 16 Dec 2024 08:05:56 -0600
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 29/71] hw/i386: Constify all Property
To: CLEMENT MATHIEU--DRIF ,
 "qemu-devel@nongnu.org" 
Cc: "Michael S. Tsirkin" ,
 Marcel Apfelbaum ,
 Paolo Bonzini , Eduardo Habkost ,
 Jason Wang , Yi Liu ,
 Stefano Stabellini ,
 Anthony PERARD , Paul Durrant ,
 "Edgar E. Iglesias" ,
 "open list:X86 Xen CPUs" 
References: <20241213190750.2513964-1-richard.henderson@linaro.org>
 <20241213190750.2513964-34-richard.henderson@linaro.org>
 <774bd939-8015-47c2-910d-f36c44bc0379@eviden.com>
Content-Language: en-US
From: Richard Henderson 
In-Reply-To: <774bd939-8015-47c2-910d-f36c44bc0379@eviden.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 12/16/24 00:14, CLEMENT MATHIEU--DRIF wrote:
> Hi Rihard.
> 
> Good idea, LGTM.
> 
> Just out of curiosity, what was the motivation for such a patch?
> It it simply about cleaning the code or is it intended to solve a deeper
> problem.

Simply cleaning the code, prompted by a change to core QAPI code for Rust enablement.


r~


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 14:13:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 14:13:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858117.1270377 (Exim 4.92)
	(envelope-from )
	id 1tNBqe-0000PT-Sy; Mon, 16 Dec 2024 14:13:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858117.1270377; Mon, 16 Dec 2024 14:13:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNBqe-0000PM-Od; Mon, 16 Dec 2024 14:13:24 +0000
Received: by outflank-mailman (input) for mailman id 858117;
 Mon, 16 Dec 2024 14:13: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 1tNBqe-0000PG-70
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 14:13:24 +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 e78f902f-bbb7-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 15:13:21 +0100 (CET)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-385e3621518so2010005f8f.1
 for ; Mon, 16 Dec 2024 06:13:21 -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-388c801637esm8224677f8f.28.2024.12.16.06.13.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 06:13:20 -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: e78f902f-bbb7-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734358400; x=1734963200; 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=RyzKkAHr9EwB1+Rh2shP5R1qGP6Fb9dodDMOguzSmxQ=;
        b=gK1urfAgVjWvMFas+BK1tIYMHUrohoR82H4i4qtcTRmSBCCo4gP1CpI8ntN5m7hvR+
         erLz8PR6HfXUTa+g9RXmhpST7gHkmwdbQFH65eQE6rT0ix7j8UA+w7XoWbqdMvYVa6qN
         FFdvz+3lVjLZNzEJIr6YMoUtfH7MZx4yDqnlgM+p6Y6PS1Ospw+gC6ANjm9hpa09se1R
         dJz2N+wr76l/J0Ruw8Oy7r5EBf1hhmxaCl6rDU/dIuqUeDqV0G4AgCsQOQ/WywngtWxH
         B4SLeffhMWIG9s9EoUvxMazPhuuvqkfSDwyD7in3nk2sm/M/ijbb4qBGiQ4cqXSnB0RG
         GJcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734358400; x=1734963200;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=RyzKkAHr9EwB1+Rh2shP5R1qGP6Fb9dodDMOguzSmxQ=;
        b=TOW1HA62ABcpsCtqoGoeUuugK7+THTxLMSTYwr11rfhXnb4Fl3+L9T0MAN74NGi0Pn
         dX/cb7oS8pjMBVgbAm9a0WUmNWPWXrNwTAtYimY8wlRdcOsD79MLf9TZdWEUOC2Bd0bL
         81vNwl7GLLo62C3Un9MzcTHDZmlRRNPSIRtcpNn9QbgdWB1TEISIgvBIfUQ55TFqaxu8
         N4kXhU/YRrMEGRl02Uu4qF/wmzyCgauOqgXqHISllLX63xcqcKefHUVLL2J/UL2V6ALZ
         b4JM5HUOhFESzZNEFK9flsQ5LgsnooF1tyVaOr66mhpiE8EdBEW/e9oQD7rVLCm+DSle
         VQtg==
X-Forwarded-Encrypted: i=1; AJvYcCXwWr9RlX/jL2gFdrgicSi3y07DGWPxMXsyQZdruHFDWSGQ0KKz8pexKmFm4lvd143jk/o40FcBtj4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwHK6dFdp/Yi/1YJ9UtDHE2qod0fi5KsJ9FT7ZJTAKDwed1VDps
	3pqbZ6SzXj9vW8IjX0gYdHqv6kGDbWXli5gSmu72U/+HNefnL8dykLxByuEPSg==
X-Gm-Gg: ASbGnctTo8jTug3LM/lPVIWNbjFEw2qDMN2Vn030R1QTtD7hISB4KNo9in+gS73DLQC
	EjxLlCR4pLv1zxeCM1ur96eGVzHnM+cD4vrsuUiuFzPqZAbeY8S+9uGcu+vFJvpzl2ANNKwve1i
	qGxlcDyiDOfeQSHt1Klv5zjnHlH+g5VGtJutV0nX3zf57sR8vpcQxIxrwzwdoVG5SoEhzrapYQr
	uKij4X0XHZKb6bVHGS2rxNKRVhIBOwauGpnW1e+0iE44T0H+p/gKW/gPlnb7rp94iO3gqzIlhIs
	RNm6N9VYFYi1ZJcQnKqsc9AtY7CJ6MBs04LeS+upKA==
X-Google-Smtp-Source: AGHT+IH9AHwJV1QCq5N3eHDHxaesoMSPdConcUgGRgVcL2BFD6T3a9Ro0s+hljWk7SWF/g91YUHf/A==
X-Received: by 2002:a05:6000:144a:b0:385:f417:ee3d with SMTP id ffacd0b85a97d-38880adb3c3mr9043624f8f.35.1734358400589;
        Mon, 16 Dec 2024 06:13:20 -0800 (PST)
Message-ID: 
Date: Mon, 16 Dec 2024 15:13:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v12 12/12] xen/arm: add cache coloring support for Xen
 image
To: Michal Orzel ,
 Carlo Nonato 
Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-13-carlo.nonato@minervasys.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 16.12.2024 14:56, Michal Orzel wrote:
> On 13/12/2024 17:28, Carlo Nonato wrote:
>> @@ -30,6 +31,17 @@ static inline void domain_dump_llc_colors(const struct domain *d) {}
>>  static inline void domain_llc_coloring_free(struct domain *d) {}
>>  #endif
>>
>> +/**
>> + * Iterate over each Xen mfn in the colored space.
>> + * @start_mfn:  the first mfn that needs to be colored.
>> + * @mfn:        the current mfn.
>> + * @i:          loop index.
>> + */
>> +#define for_each_xen_colored_mfn(start_mfn, mfn, i) \
>> +    for ( i = 0, mfn = xen_colored_mfn(start_mfn);  \
> Here and elsewhere you need to enclose 'i' in paranthesis. Otherwise ECLAIR will report 20.7 violation.

And then also mfn, ftaod.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 14:14:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 14:14:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858128.1270387 (Exim 4.92)
	(envelope-from )
	id 1tNBs9-00011B-A0; Mon, 16 Dec 2024 14:14:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858128.1270387; Mon, 16 Dec 2024 14:14: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 1tNBs9-000114-6T; Mon, 16 Dec 2024 14:14:57 +0000
Received: by outflank-mailman (input) for mailman id 858128;
 Mon, 16 Dec 2024 14:14: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 1tNBs7-00010w-Dl
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 14:14:55 +0000
Received: from mail179-16.suw41.mandrillapp.com
 (mail179-16.suw41.mandrillapp.com [198.2.179.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1eb46353-bbb8-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 15:14:54 +0100 (CET)
Received: from pmta12.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail179-16.suw41.mandrillapp.com (Mailchimp) with ESMTP id
 4YBhlw6JRWzB5pB8n
 for ; Mon, 16 Dec 2024 14:14:52 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 88620f5623e9448d8e01c29ceb9969e8; Mon, 16 Dec 2024 14:14: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: 1eb46353-bbb8-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1734358492; x=1734618992;
	bh=Eg1AR4hb4BDWRnauHnhGJuys1Ck7P04mXrpjVWQykhY=;
	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=iadVfP41f/vAqcXRngcyNYLe40KTjjF9dDI8HMUVlmKNAPZjW8bJypIC9gGmbU1t8
	 7A5l2r6Ugfur90suiJY3jo/TGyPEt7N1hfTsxIbUTzVC2qld7KIK9taCp1nzmB7kKF
	 vCS1RdJXplBy425lt4VOXX108wd12LlDuoXubFetG9zFrp/UOMeHq5GnrOxEdRPK0N
	 BZ0PNY7iOJhnEZzDiLoSsjxGg+/y/OlXnpGwT4/s1n0WPSMRINGdyJWuB9mZHdrDlC
	 Anj1fbEMgpMTgh57Bk2mxfiSKUKsnU+S+XwYTBceHHrdtNF2qzFR8EnUs6Ka8J2jEI
	 9ID6ZwrWUGutA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1734358492; x=1734618992; i=anthony.perard@vates.tech;
	bh=Eg1AR4hb4BDWRnauHnhGJuys1Ck7P04mXrpjVWQykhY=;
	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=Hi4hSVxAc8deq8t4rVQjm/CR5HkNDYeVKviujrm5qrYWQ2lh4UkAjbTDj84PVpIvb
	 ph2VsgOPgnB24MNCuqSEKDa6zRx8YF3vbbJem2ojZq8GU3zH62DO3oaTkGGxS8/XIY
	 Kncvfgx2EFRgrfa3zT39gAdVrxf2JwZV6ihmh0E9juHW+fJdHqgGDwigOGEk3QKUiA
	 jrMQGGjacAMOfNCs4/UpnXmJH24WJT0/WGk7xDD7wG/oj2n6xQKE4ubCahFtKsSvIb
	 +/bZxfq8crlZnryLxmJj3wuh27TE/gr9pDmJ6pvC/ilY3ALiEB1yoYj2EwKK6vzvrf
	 yzP8WBdQSDLCg==
From: "Anthony PERARD" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v3=202/7]=20tools:=20add=20a=20dedicated=20header=20file=20for=20barrier=20definitions?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1734358492393
To: "Juergen Gross" 
Cc: xen-devel@lists.xenproject.org
Message-Id: 
References: <20241213162421.16782-1-jgross@suse.com> <20241213162421.16782-3-jgross@suse.com>
In-Reply-To: <20241213162421.16782-3-jgross@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.88620f5623e9448d8e01c29ceb9969e8?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20241216:md
Date: Mon, 16 Dec 2024 14:14:52 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On Fri, Dec 13, 2024 at 05:24:16PM +0100, Juergen Gross wrote:
> diff --git a/tools/include/xen-barrier.h b/tools/include/xen-barrier.h
> new file mode 100644
> index 0000000000..a716fb93cc
> --- /dev/null
> +++ b/tools/include/xen-barrier.h
> @@ -0,0 +1,39 @@
> +/* SPDX-License-Identifier: LGPL-2.1 */

That's a deprecated SPDX identifier, it should be written
"LGPL-2.1-only" instead.

With that fixed: Reviewed-by: Anthony PERARD 

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 Dec 16 14:23:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 14:23:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858139.1270396 (Exim 4.92)
	(envelope-from )
	id 1tNC0l-00032K-2c; Mon, 16 Dec 2024 14:23:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858139.1270396; Mon, 16 Dec 2024 14: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 1tNC0l-00032D-03; Mon, 16 Dec 2024 14:23:51 +0000
Received: by outflank-mailman (input) for mailman id 858139;
 Mon, 16 Dec 2024 14:23: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 1tNC0j-000327-IR
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 14:23:49 +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 5cfe19df-bbb9-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 15:23:47 +0100 (CET)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-38637614567so1847626f8f.3
 for ; Mon, 16 Dec 2024 06:23: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-388c8016120sm8179812f8f.23.2024.12.16.06.23.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 06:23: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: 5cfe19df-bbb9-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734359027; x=1734963827; 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=jwaRtNXHGtnfWOWK+zlhQ+m7hPHIQFVIRx06ln/6DSU=;
        b=gupY2DhCUenMeJMFOaujEzQYoUKIgwSAxw4KI5Z6FiFEJdsRSLR76ROPPyOuCiNtmU
         2uU5biSj94/Lr3k79KmMaITtXtew9QEyubqaoEtchf3C5m2NYrQOoK71DTvy5HEcNZyS
         1XpiEoGz3ypwuYS8bfdugqUg7bBrQfmefd2nZEYkxROtwHcpe9QhG/0vb+BO51QZe2rd
         a9oW9i8NWSHVm8aa1EviaAekLhMYmgupa96Z1TdBI0Vf3+aGb1kux704laawCIk8bdJ0
         ez0h5HNQOSP9nwfJvVeJTSE2BQt4k5j0+SLJ95GvuJ6NTiOTGtt90Qp/nwIJdmsNtKSz
         2OXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734359027; x=1734963827;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jwaRtNXHGtnfWOWK+zlhQ+m7hPHIQFVIRx06ln/6DSU=;
        b=lhfCfHj50bbSdbyGJ4yHujwfEWz8RGIRc4SUD9bKZ1XwdFozCtOlWNdx0p3uIDjzrr
         gf+hht6Xo2gmF6qEGgzAw2Fk8di6DUgi0uHfs5jZOHlZYzDI//4ygkpt7QFO4h412Gox
         +8Pp01DpHUGmeScQa723Xl51J9NwyI+ZcWjcyrEa1kObdMszXCorddM/EYOx586uHuv+
         Avcp9IDL1bhuAlTQIezpQfg0gtvGNyu3SzdvfAK/sbQVghC4fDT0VpwNRfLIo5LeL8j6
         S0MhjLEOSezc7VPRD350hsUQ0K6SHFYbAm7uib1LvFRvjRyYDYg9Ej/ZX/+DpXmwMBrN
         PtjA==
X-Forwarded-Encrypted: i=1; AJvYcCVrEOv7r/Am9ks+l19iTx0zg73SvcIMFO0oPVlo+7a3pqEoIrH47KvlJSLR3bpag7/SQ1oYvQJa5fc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx8mpGyktdXNmWpL5gEKpCvHm2Bwl2YwwmKCDali06/i13LaD1G
	Tm6Qpb+oYhVejXeObXaTXCIQeS6b0Azyr1gVEurJv2b5haifNqEdU9VUfdRiNA==
X-Gm-Gg: ASbGncuRhr07E8Mpd3MW4eejZluiT0asyfh/axg9xTbKaguWWBqWngidcFxkZLkBVAH
	7PaMzCMxezudPORT+sityXuv4iL2RGf6mGaUVi8gaZLmjlSkRDBgHKHGZRCu4xHH3M1pS3stWE+
	+rtzlaOjAgkPxmh+3/4v3q3YcBKG21n+wWsz8YZi9jTmgRAz624FV/Pc+6Nnrz7DUCINGshdaI6
	JKfNh8/Or5fQ6WJu+FT5M+RYAvwOEgdHsDn4qildlfYPOypB6y6zA5hKB9je/q3SdhJfYFktSnJ
	SjDhKYnZszhSj77he27rzNGXszMRhXG9znv+W9ALhw==
X-Google-Smtp-Source: AGHT+IHZR8Sk54lblWHkVSoC8FNLgq7w35pkD3KnKRy5Ffewb/0yBx/S1iZ9PbF0CRu58LQAp1aAPg==
X-Received: by 2002:a05:6000:4613:b0:385:ed16:c8b with SMTP id ffacd0b85a97d-38880ad1d9emr9897752f8f.23.1734359027100;
        Mon, 16 Dec 2024 06:23:47 -0800 (PST)
Message-ID: <19c9ef65-a5bd-4d81-89dc-c780d3ead8b8@suse.com>
Date: Mon, 16 Dec 2024 15:23:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/7] xen/riscv: implement data and instruction cache
 operations
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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 11.12.2024 18:27, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/page.h
> +++ b/xen/arch/riscv/include/asm/page.h
> @@ -7,6 +7,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -148,9 +149,27 @@ static inline bool pte_is_mapping(pte_t p)
>      return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK);
>  }
>  
> +static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
> +{
> +#ifdef CONFIG_QEMU
> +    return 0;
> +#else
> +    return -EOPNOTSUPP;
> +#endif
> +}
> +
> +static inline int clean_dcache_va_range(const void *p, unsigned long size)
> +{
> +#ifdef CONFIG_QEMU
> +    return 0;
> +#else
> +    return -EOPNOTSUPP;
> +#endif
> +}

So testing on real hardware will then effectively become impossible, until
someone goes and implements these?

> --- /dev/null
> +++ b/xen/arch/riscv/platforms/Kconfig
> @@ -0,0 +1,5 @@
> +config QEMU
> +	bool "QEMU aarch virt machine support"
> +	depends on RISCV_64

I understand Arm has it like this, but: Is QEMU really a sufficiently non-
ambiguous name to use? Is the RISCV_64 dependency really needed?

> +	help
> +	  Enable all the required drivers for QEMU riscv64 virt emulated machine.

This line looks to be slightly too long now (after you apparently unwrapped
what Arm has).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 14:28:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 14:28:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858148.1270406 (Exim 4.92)
	(envelope-from )
	id 1tNC5b-0003cU-KS; Mon, 16 Dec 2024 14:28:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858148.1270406; Mon, 16 Dec 2024 14: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 1tNC5b-0003cN-Hn; Mon, 16 Dec 2024 14:28:51 +0000
Received: by outflank-mailman (input) for mailman id 858148;
 Mon, 16 Dec 2024 14:28: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 1tNC5Z-0003cH-O1
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 14:28:50 +0000
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com
 [2607:f8b0:4864:20::d30])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0ed3600d-bbba-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 15:28:46 +0100 (CET)
Received: by mail-io1-xd30.google.com with SMTP id
 ca18e2360f4ac-844df397754so130774139f.2
 for ; Mon, 16 Dec 2024 06:28: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: 0ed3600d-bbba-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734359325; x=1734964125; 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=ZbXODO7ddqYeCaGkYUo4xqtbseVEAlqu5pXe3uCjUyM=;
        b=BdIdXob50uuHpehgXRfPl5weVPKLCW3OVZS8RL6hZqvWeQS9IrLPKyUFCkGGJHfrLA
         Y9gOGY4bBiuqiRtmecrGSI1tKn/6NPgiX0GX0PkTCe4YJv++OL7VRJD+0ck6oqDER7i7
         y7cpWmiDNL7rY9GB/iVrOpdp9shdl1F2qOBHos3SB8w+V+NqrEdberhITQ4hP9cLMVml
         jtWXqyrnmpxKiGbsk9lpGYB0LAeSkCWNOYYpP1y5gWoLze+Z4d2enjIIs3V3sqEkMSn9
         SCUoic3Gfwe98j4oXldjiHPKiIpJCP7xkLXN5oR6DhoHbbyh/BGgcztr/iwoyCj5xVvs
         25dQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734359325; x=1734964125;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=ZbXODO7ddqYeCaGkYUo4xqtbseVEAlqu5pXe3uCjUyM=;
        b=FuYTmhRIx+0UL96mrazDDK4cybOspkdXi0Twq50stDanFqG3gPKVrMR6wHVAi+iDyg
         V7VfH5CfmjahFpRmor1goDDQlWdalpypAvCzJo8n3W7ZNF02eu1rM16b9Zs2ktqjeFdp
         TdORx2ORpAXmD31K7HCZnXsWz/wFL/MeJVtxS3T41z8aijhEu/cg+Uz4n+MV2mGVtNAu
         LBAw1jHGoD8rZo8DF4dh5olTpFej1T8iE+QItvSfMA2SmwLTMozSyBZw6cBWblJjfhuu
         OGb8iAdNnpnmjNcOYa0bRJA3EhVZO0RRoVboAX4GzF0BECMyi53XtAvCIAwdWp/MZzD1
         BhFw==
X-Gm-Message-State: AOJu0YxdUimEviKy93xELaBTG5lSmbJ21g1E+qq6cG5SetUMX16s31SC
	9yfIaCBBIb/n41OMYTrfwTLZ1MEOYLQDaNytkXTvCUd6IaUeynOat/OCWuR79DWojybLA7WqL7Q
	riueNX2WkpDXK5DX29d2qUm19MjT6Oen43vl37w==
X-Gm-Gg: ASbGncsdS/G7LqzAGwbkFF5Ehcv8JCJyjLLsUi+o/NHnb+EzSiHkndRRWCTjRVNSvg+
	iUA87+1ROusv74d2DjaqTnCiNFbL6dCAr8n92Cyo=
X-Google-Smtp-Source: AGHT+IHSDYMyESLu/A8IPVsPXUpNhhjZePjUG9RIx/DxTWy/XHkKpuGDeOyfds4FoNX7e2fDr/8wrCGvYO+QBxRSYgk=
X-Received: by 2002:a05:6e02:20c2:b0:3a7:d84c:f2a0 with SMTP id
 e9e14a558f8ab-3aff69e2d54mr102508375ab.7.1734359325103; Mon, 16 Dec 2024
 06:28:45 -0800 (PST)
MIME-Version: 1.0
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-13-carlo.nonato@minervasys.tech> 
In-Reply-To: 
From: Carlo Nonato 
Date: Mon, 16 Dec 2024 15:28:34 +0100
Message-ID: 
Subject: Re: [PATCH v12 12/12] xen/arm: add cache coloring support for Xen image
To: Michal Orzel 
Cc: xen-devel@lists.xenproject.org, andrea.bastoni@minervasys.tech, 
	marco.solieri@minervasys.tech, Stefano Stabellini , 
	Julien Grall , Bertrand Marquis , 
	Volodymyr Babchuk , Andrew Cooper , 
	Anthony PERARD , Jan Beulich , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Michal,

On Mon, Dec 16, 2024 at 2:56=E2=80=AFPM Michal Orzel =
 wrote:
>
> On 13/12/2024 17:28, Carlo Nonato wrote:
> >
> > Xen image is relocated to a new colored physical space. Some relocation
> > functionalities must be brought back:
> > - the virtual address of the new space is taken from 0c18fb76323b
> >   ("xen/arm: Remove unused BOOT_RELOC_VIRT_START").
> > - relocate_xen() and get_xen_paddr() are taken from f60658c6ae47
> >   ("xen/arm: Stop relocating Xen").
> >
> > setup_pagetables() must be adapted for coloring and for relocation. Run=
time
> > page tables are used to map the colored space, but they are also linked=
 in
> > boot tables so that the new space is temporarily available for relocati=
on.
> > This implies that Xen protection must happen after the copy.
> >
> > Finally, since the alternative framework needs to remap the Xen text an=
d
> > inittext sections, this operation must be done in a coloring-aware way.
> > The function xen_remap_colored() is introduced for that.
> >
> > Signed-off-by: Carlo Nonato 
> > Signed-off-by: Marco Solieri 
> > Reviewed-by: Jan Beulich  # common
> > ---
> > v12:
> > - FUNC instead of ENTRY in head.S for relocate_xen
> > - dc cvau instead of dc cvav in relocate_xen()
> > - added relocate_and_switch_ttbr() to make setup_pagetables() code more=
 clear
> > v11:
> > - else if -> if in xen_colored_mfn()
> > v10:
> > - no changes
> > v9:
> > - patch adapted to changes to setup_pagetables()
> > v8:
> > - moved xen_colored_map_size() to arm/llc-coloring.c
> > v7:
> > - added BUG_ON() checks to arch_llc_coloring_init() and
> >   create_llc_coloring_mappings()
> > v6:
> > - squashed with BOOT_RELOC_VIRT_START patch
> > - consider_modules() moved in another patch
> > - removed psci and smpboot code because of new idmap work already handl=
es that
> > - moved xen_remap_colored() in alternative.c since it's only used there
> > - removed xen_colored_temp[] in favor of xen_xenmap[] usage for mapping
> > - use of boot_module_find_by_kind() to remove the need of extra paramet=
er in
> >   setup_pagetables()
> > - moved get_xen_paddr() in arm/llc-coloring.c since it's only used ther=
e
> > v5:
> > - FIXME: consider_modules copy pasted since it got moved
> > v4:
> > - removed set_value_for_secondary() because it was wrongly cleaning cac=
he
> > - relocate_xen() now calls switch_ttbr_id()
> > ---
> >  xen/arch/arm/alternative.c            |  26 ++++++-
> >  xen/arch/arm/arm64/mmu/head.S         |  58 ++++++++++++++-
> >  xen/arch/arm/arm64/mmu/mm.c           |  29 ++++++++
> >  xen/arch/arm/include/asm/mmu/layout.h |   3 +
> >  xen/arch/arm/include/asm/mmu/mm.h     |   1 +
> >  xen/arch/arm/llc-coloring.c           |  63 ++++++++++++++++
> >  xen/arch/arm/mmu/setup.c              | 103 ++++++++++++++++++++++----
> >  xen/arch/arm/setup.c                  |  10 ++-
> >  xen/common/llc-coloring.c             |  18 +++++
> >  xen/include/xen/llc-coloring.h        |  13 ++++
> >  10 files changed, 304 insertions(+), 20 deletions(-)
> >
> > diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
> > index fec7dbd2cd..2c1af6e7e4 100644
> > --- a/xen/arch/arm/alternative.c
> > +++ b/xen/arch/arm/alternative.c
> > @@ -9,6 +9,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -191,6 +192,25 @@ static int __apply_alternatives_multi_stop(void *x=
enmap)
> >      return 0;
> >  }
> >
> > +static void __init *xen_remap_colored(mfn_t xen_mfn, paddr_t xen_size)
> > +{
> > +    unsigned int i;
> > +    void *xenmap;
> > +    mfn_t *xen_colored_mfns, mfn;
> > +
> > +    xen_colored_mfns =3D xmalloc_array(mfn_t, xen_size >> PAGE_SHIFT);
> > +    if ( !xen_colored_mfns )
> > +        panic("Can't allocate LLC colored MFNs\n");
> > +
> > +    for_each_xen_colored_mfn ( xen_mfn, mfn, i )
> > +        xen_colored_mfns[i] =3D mfn;
> > +
> > +    xenmap =3D vmap(xen_colored_mfns, xen_size >> PAGE_SHIFT);
> > +    xfree(xen_colored_mfns);
> > +
> > +    return xenmap;
> > +}
> > +
> >  /*
> >   * This function should only be called during boot and before CPU0 jum=
p
> >   * into the idle_loop.
> > @@ -209,7 +229,11 @@ void __init apply_alternatives_all(void)
> >       * The text and inittext section are read-only. So re-map Xen to
> >       * be able to patch the code.
> >       */
> > -    xenmap =3D vmap_contig(xen_mfn, 1U << xen_order);
> > +    if ( llc_coloring_enabled )
> > +        xenmap =3D xen_remap_colored(xen_mfn, xen_size);
> > +    else
> > +        xenmap =3D vmap_contig(xen_mfn, 1U << xen_order);
> > +
> >      /* Re-mapping Xen is not expected to fail during boot. */
> >      BUG_ON(!xenmap);
> >
> > diff --git a/xen/arch/arm/arm64/mmu/head.S b/xen/arch/arm/arm64/mmu/hea=
d.S
> > index 665a51a337..634156f83d 100644
> > --- a/xen/arch/arm/arm64/mmu/head.S
> > +++ b/xen/arch/arm/arm64/mmu/head.S
> > @@ -428,6 +428,61 @@ FUNC_LOCAL(fail)
> >          b     1b
> >  END(fail)
> >
> > +/*
> > + * Copy Xen to new location and switch TTBR
> > + * x0    ttbr
> > + * x1    source address
> > + * x2    destination address
> > + * x3    length
> > + *
> > + * Source and destination must be word aligned, length is rounded up
> > + * to a 16 byte boundary.
> > + *
> > + * MUST BE VERY CAREFUL when saving things to RAM over the copy
> > + */
> > +FUNC(relocate_xen)
> > +        /*
> > +         * Copy 16 bytes at a time using:
> > +         *   x9: counter
> > +         *   x10: data
> > +         *   x11: data
> > +         *   x12: source
> > +         *   x13: destination
> > +         */
> > +        mov     x9, x3
> > +        mov     x12, x1
> > +        mov     x13, x2
> > +
> > +1:      ldp     x10, x11, [x12], #16
> > +        stp     x10, x11, [x13], #16
> > +
> > +        subs    x9, x9, #16
> > +        bgt     1b
> > +
> > +        /*
> > +         * Flush destination from dcache using:
> > +         *   x9: counter
> > +         *   x10: step
> > +         *   x11: vaddr
> > +         *
> > +         * This is to ensure data is visible to the instruction cache
> > +         */
> > +        dsb   sy
> > +
> > +        mov   x9, x3
> > +        ldr   x10, =3Ddcache_line_bytes /* x10 :=3D step */
> > +        ldr   x10, [x10]
> > +        mov   x11, x2
> > +
> > +1:      dc    cvau, x11
> > +
> > +        add   x11, x11, x10
> > +        subs  x9, x9, x10
> > +        bgt   1b
> > +
> > +        /* No need for dsb/isb because they are alredy done in switch_=
ttbr_id */
> > +        b switch_ttbr_id
> > +
> >  /*
> >   * Switch TTBR
> >   *
> > @@ -453,7 +508,8 @@ FUNC(switch_ttbr_id)
> >
> >          /*
> >           * 5) Flush I-cache
> > -         * This should not be necessary but it is kept for safety.
> > +         * This should not be necessary in the general case, but it's =
needed
> > +         * for cache coloring because code is relocated in that case.
> >           */
> >          ic     iallu
> >          isb
> > diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c
> > index 671eaadbc1..f1f2543902 100644
> > --- a/xen/arch/arm/arm64/mmu/mm.c
> > +++ b/xen/arch/arm/arm64/mmu/mm.c
> > @@ -1,6 +1,7 @@
> >  /* SPDX-License-Identifier: GPL-2.0-only */
> >
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >
> > @@ -138,8 +139,36 @@ void update_boot_mapping(bool enable)
> >  }
> >
> >  extern void switch_ttbr_id(uint64_t ttbr);
> > +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t l=
en);
> >
> >  typedef void (switch_ttbr_fn)(uint64_t ttbr);
> > +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, si=
ze_t len);
> > +
> > +void __init relocate_and_switch_ttbr(uint64_t ttbr) {
> CODING_STYLE: { needs to be on its own line
>
> Also, this function is only executed in case of LLC coloring, so shouldn'=
t it
> be #ifdef protected.

Here and in other places (patch #8) I'm relying on DCE to remove functions
that are not called. This was a suggestion from Jan in that patch. Can we
adopt the same here?

> > +    vaddr_t id_addr =3D virt_to_maddr(relocate_xen);
> > +    relocate_xen_fn *fn =3D (relocate_xen_fn *)id_addr;
> > +    lpae_t pte;
> > +
> > +    /* Enable the identity mapping in the boot page tables */
> > +    update_identity_mapping(true);
> > +
> > +    /* Enable the identity mapping in the runtime page tables */
> > +    pte =3D pte_of_xenaddr((vaddr_t)relocate_xen);
> > +    pte.pt.table =3D 1;
> > +    pte.pt.xn =3D 0;
> > +    pte.pt.ro =3D 1;
> > +    write_pte(&xen_third_id[third_table_offset(id_addr)], pte);
> > +
> > +    /* Relocate Xen and switch TTBR */
> > +    fn(ttbr, _start, (void *)BOOT_RELOC_VIRT_START, _end - _start);
> > +
> > +    /*
> > +     * Disable the identity mapping in the runtime page tables.
> > +     * Note it is not necessary to disable it in the boot page tables
> > +     * because they are not going to be used by this CPU anymore.
> > +     */
> > +    update_identity_mapping(false);
> > +}
> >
> >  void __init switch_ttbr(uint64_t ttbr)
> >  {
> > diff --git a/xen/arch/arm/include/asm/mmu/layout.h b/xen/arch/arm/inclu=
de/asm/mmu/layout.h
> > index a3b546465b..19c0ec63a5 100644
> > --- a/xen/arch/arm/include/asm/mmu/layout.h
> > +++ b/xen/arch/arm/include/asm/mmu/layout.h
> > @@ -30,6 +30,7 @@
> >   *  10M -  12M   Fixmap: special-purpose 4K mapping slots
> >   *  12M -  16M   Early boot mapping of FDT
> >   *  16M -  18M   Livepatch vmap (if compiled in)
> > + *  16M -  24M   Cache-colored Xen text, data, bss (temporary, if comp=
iled in)
> >   *
> >   *   1G -   2G   VMAP: ioremap and early_ioremap
> >   *
> > @@ -74,6 +75,8 @@
> >  #define BOOT_FDT_VIRT_START     (FIXMAP_VIRT_START + FIXMAP_VIRT_SIZE)
> >  #define BOOT_FDT_VIRT_SIZE      _AT(vaddr_t, MB(4))
> >
> > +#define BOOT_RELOC_VIRT_START   (BOOT_FDT_VIRT_START + BOOT_FDT_VIRT_S=
IZE)
> > +
> >  #ifdef CONFIG_LIVEPATCH
> >  #define LIVEPATCH_VMAP_START    (BOOT_FDT_VIRT_START + BOOT_FDT_VIRT_S=
IZE)
> >  #define LIVEPATCH_VMAP_SIZE    _AT(vaddr_t, MB(2))
> > diff --git a/xen/arch/arm/include/asm/mmu/mm.h b/xen/arch/arm/include/a=
sm/mmu/mm.h
> > index c5e03a66bf..f5a00558c4 100644
> > --- a/xen/arch/arm/include/asm/mmu/mm.h
> > +++ b/xen/arch/arm/include/asm/mmu/mm.h
> > @@ -31,6 +31,7 @@ void dump_pt_walk(paddr_t ttbr, paddr_t addr,
> >
> >  /* Switch to a new root page-tables */
> >  extern void switch_ttbr(uint64_t ttbr);
> > +extern void relocate_and_switch_ttbr(uint64_t ttbr);
> >
> >  #endif /* __ARM_MMU_MM_H__ */
> >
> > diff --git a/xen/arch/arm/llc-coloring.c b/xen/arch/arm/llc-coloring.c
> > index 1c7b92bc45..7cb4ecb50e 100644
> > --- a/xen/arch/arm/llc-coloring.c
> > +++ b/xen/arch/arm/llc-coloring.c
> > @@ -9,6 +9,7 @@
> >  #include 
> >
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >
> > @@ -64,8 +65,70 @@ unsigned int __init get_llc_way_size(void)
> >      return line_size * num_sets;
> >  }
> >
> > +/**
> Incorrect comment style. Should be /*
>
> > + * get_xen_paddr - get physical address to relocate Xen to
> > + *
> > + * Xen is relocated to as near to the top of RAM as possible and
> > + * aligned to a XEN_PADDR_ALIGN boundary.
> > + */
> > +static paddr_t __init get_xen_paddr(paddr_t xen_size)
> > +{
> > +    const struct membanks *mem =3D bootinfo_get_mem();
> > +    paddr_t min_size, paddr =3D 0;
> > +    unsigned int i;
> > +
> > +    min_size =3D ROUNDUP(xen_size, XEN_PADDR_ALIGN);
> > +
> > +    /* Find the highest bank with enough space. */
> > +    for ( i =3D 0; i < mem->nr_banks; i++ )
> > +    {
> > +        const struct membank *bank =3D &mem->bank[i];
> > +        paddr_t s, e;
> > +
> > +        if ( bank->size >=3D min_size )
> > +        {
> > +            e =3D consider_modules(bank->start, bank->start + bank->si=
ze,
> > +                                 min_size, XEN_PADDR_ALIGN, 0);
> > +            if ( !e )
> > +                continue;
> > +
> > +#ifdef CONFIG_ARM_32
> > +            /* Xen must be under 4GB */
> > +            if ( e > GB(4) )
> > +                e =3D GB(4);
> > +            if ( e < bank->start )
> > +                continue;
> > +#endif
> > +
> > +            s =3D e - min_size;
> > +
> > +            if ( s > paddr )
> > +                paddr =3D s;
> > +        }
> > +    }
> > +
> > +    if ( !paddr )
> > +        panic("Not enough memory to relocate Xen\n");
> > +
> > +    printk("Placing Xen at 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
> > +           paddr, paddr + min_size);
> > +
> > +    return paddr;
> > +}
> > +
> > +static paddr_t __init xen_colored_map_size(void)
> > +{
> > +    return ROUNDUP((_end - _start) * get_max_nr_llc_colors(), XEN_PADD=
R_ALIGN);
> > +}
> > +
> >  void __init arch_llc_coloring_init(void)
> >  {
> > +    struct bootmodule *xen_bootmodule =3D boot_module_find_by_kind(BOO=
TMOD_XEN);
> > +
> > +    BUG_ON(!xen_bootmodule);
> > +
> > +    xen_bootmodule->size =3D xen_colored_map_size();
> > +    xen_bootmodule->start =3D get_xen_paddr(xen_bootmodule->size);
> >  }
> >
> >  /*
> > diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c
> > index 196974f3e2..073f762a32 100644
> > --- a/xen/arch/arm/mmu/setup.c
> > +++ b/xen/arch/arm/mmu/setup.c
> > @@ -7,6 +7,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -20,6 +21,9 @@
> >  #undef virt_to_mfn
> >  #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
> >
> > +#define virt_to_reloc_virt(virt) \
> > +    (((vaddr_t)virt) - XEN_VIRT_START + BOOT_RELOC_VIRT_START)
> You need to enclose 'virt' in paranthesis.
>
> > +
> >  /* Main runtime page tables */
> >
> >  /*
> > @@ -69,6 +73,7 @@ static void __init __maybe_unused build_assertions(vo=
id)
> >      /* 2MB aligned regions */
> >      BUILD_BUG_ON(XEN_VIRT_START & ~SECOND_MASK);
> >      BUILD_BUG_ON(FIXMAP_ADDR(0) & ~SECOND_MASK);
> > +    BUILD_BUG_ON(BOOT_RELOC_VIRT_START & ~SECOND_MASK);
> >      /* 1GB aligned regions */
> >  #ifdef CONFIG_ARM_32
> >      BUILD_BUG_ON(XENHEAP_VIRT_START & ~FIRST_MASK);
> > @@ -138,6 +143,9 @@ static void __init __maybe_unused build_assertions(=
void)
> >
> >  lpae_t __init pte_of_xenaddr(vaddr_t va)
> >  {
> > +    if ( llc_coloring_enabled )
> > +        va =3D virt_to_reloc_virt(va);
> > +
> >      return mfn_to_xen_entry(virt_to_mfn(va), MT_NORMAL);
> >  }
> >
> > @@ -316,6 +324,32 @@ paddr_t __init consider_modules(paddr_t s, paddr_t=
 e,
> >      return e;
> >  }
> >
> > +static void __init create_llc_coloring_mappings(void)
> Shouldn't this be #ifdef protected and stub provided if config disabled?.

Same as above.

> > +{
> > +    lpae_t pte;
> > +    unsigned int i;
> > +    struct bootmodule *xen_bootmodule =3D boot_module_find_by_kind(BOO=
TMOD_XEN);
> > +    mfn_t start_mfn =3D maddr_to_mfn(xen_bootmodule->start), mfn;
> > +
> > +    for_each_xen_colored_mfn ( start_mfn, mfn, i )
> > +    {
> > +        pte =3D mfn_to_xen_entry(mfn, MT_NORMAL);
> > +        pte.pt.table =3D 1; /* level 3 mappings always have this bit s=
et */
> > +        xen_xenmap[i] =3D pte;
> > +    }
> > +
> > +    for ( i =3D 0; i < XEN_NR_ENTRIES(2); i++ )
> > +    {
> > +        vaddr_t va =3D BOOT_RELOC_VIRT_START + (i << XEN_PT_LEVEL_SHIF=
T(2));
> > +
> > +        pte =3D mfn_to_xen_entry(virt_to_mfn(xen_xenmap +
> > +                                           i * XEN_PT_LPAE_ENTRIES),
> > +                               MT_NORMAL);
> > +        pte.pt.table =3D 1;
> > +        write_pte(&boot_second[second_table_offset(va)], pte);
> > +    }
> > +}
> > +
> >  /*
> >   * Boot-time pagetable setup.
> >   * Changes here may need matching changes in head.S
> > @@ -326,6 +360,14 @@ void __init setup_pagetables(void)
> >      lpae_t pte, *p;
> >      int i;
> >
> > +    /*
> > +     * In case of cache coloring, map the new physical space in the bo=
ot page
> > +     * tables. From now on, pte_of_xenaddr() will translate addresses =
to this
> > +     * new space.
> > +     */
> > +    if ( llc_coloring_enabled )
> > +        create_llc_coloring_mappings();
> > +
> >      arch_setup_page_tables();
> >
> >  #ifdef CONFIG_ARM_64
> > @@ -353,13 +395,7 @@ void __init setup_pagetables(void)
> >              break;
> >          pte =3D pte_of_xenaddr(va);
> >          pte.pt.table =3D 1; /* third level mappings always have this b=
it set */
> > -        if ( is_kernel_text(va) || is_kernel_inittext(va) )
> > -        {
> > -            pte.pt.xn =3D 0;
> > -            pte.pt.ro =3D 1;
> > -        }
> > -        if ( is_kernel_rodata(va) )
> > -            pte.pt.ro =3D 1;
> > +        pte.pt.xn =3D 0; /* Permissions will be enforced later. Allow =
execution */
> >          xen_xenmap[i] =3D pte;
> >      }
> >
> > @@ -379,19 +415,54 @@ void __init setup_pagetables(void)
> >      pte.pt.table =3D 1;
> >      xen_second[second_table_offset(FIXMAP_ADDR(0))] =3D pte;
> >
> > -#ifdef CONFIG_ARM_64
> > -    ttbr =3D virt_to_maddr(xen_pgtable);
> > -#else
> > -    ttbr =3D virt_to_maddr(cpu0_pgtable);
> > +#ifdef CONFIG_ARM_32
> > +    per_cpu(xen_pgtable, 0) =3D cpu0_pgtable;
> >  #endif
> >
> > -    switch_ttbr(ttbr);
> > +    if ( llc_coloring_enabled ) {
> CODING_STYLE: { needs to be on its own line
>
> > +        ttbr =3D virt_to_maddr(virt_to_reloc_virt(THIS_CPU_PGTABLE));
> > +        relocate_and_switch_ttbr(ttbr);
> > +    }
> > +    else {
> CODING_STYLE: { needs to be on its own line
>
> > +        ttbr =3D virt_to_maddr(THIS_CPU_PGTABLE);
> > +        switch_ttbr(ttbr);
> > +    }
> >
> > -    xen_pt_enforce_wnx();
> > +    /* Protect Xen */
> > +    for ( i =3D 0; i < XEN_NR_ENTRIES(3); i++ )
> > +    {
> > +        vaddr_t va =3D XEN_VIRT_START + (i << PAGE_SHIFT);
> > +        lpae_t *entry =3D xen_xenmap + i;
> >
> > -#ifdef CONFIG_ARM_32
> > -    per_cpu(xen_pgtable, 0) =3D cpu0_pgtable;
> > -#endif
> > +        if ( !is_kernel(va) )
> > +            break;
> > +
> > +        pte =3D read_atomic(entry);
> > +
> > +        if ( is_kernel_text(va) || is_kernel_inittext(va) )
> > +        {
> > +            pte.pt.xn =3D 0;
> > +            pte.pt.ro =3D 1;
> > +        }
> > +        else if ( is_kernel_rodata(va) ) {
> CODING_STYLE: { needs to be on its own line
>
> > +            pte.pt.ro =3D 1;
> > +            pte.pt.xn =3D 1;
> > +        }
> > +        else {
> CODING_STYLE: { needs to be on its own line
>
> > +            pte.pt.xn =3D 1;
> > +            pte.pt.ro =3D 0;
> > +        }
> > +
> > +        write_pte(entry, pte);
> > +    }
> > +
> > +    /*
> > +     * We modified live page-tables. Ensure the TLBs are invalidated
> > +     * before setting enforcing the WnX permissions.
> > +     */
> > +    flush_xen_tlb_local();
> > +
> > +    xen_pt_enforce_wnx();
> >  }
> >
> >  void *__init arch_vmap_virt_end(void)
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index 568a49b274..5e2c519ce8 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -304,8 +304,6 @@ void asmlinkage __init start_xen(unsigned long fdt_=
paddr)
> >      /* Initialize traps early allow us to get backtrace when an error =
occurred */
> >      init_traps();
> >
> > -    setup_pagetables();
> > -
> >      smp_clear_cpu_maps();
> >
> >      device_tree_flattened =3D early_fdt_map(fdt_paddr);
> > @@ -329,6 +327,14 @@ void asmlinkage __init start_xen(unsigned long fdt=
_paddr)
> >
> >      llc_coloring_init();
> >
> > +    /*
> > +     * Page tables must be setup after LLC coloring initialization bec=
ause
> > +     * coloring info are required in order to create colored mappings
> > +     */
> > +    setup_pagetables();
> > +    /* Device-tree was mapped in boot page tables, remap it in the new=
 tables */
> > +    device_tree_flattened =3D early_fdt_map(fdt_paddr);
> > +
> >      setup_mm();
> >
> >      vm_init();
> > diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
> > index ff4837fcc6..545d8b49e8 100644
> > --- a/xen/common/llc-coloring.c
> > +++ b/xen/common/llc-coloring.c
> > @@ -42,6 +42,8 @@ static unsigned int __ro_after_init xen_num_colors;
> >
> >  #define mfn_color_mask              (max_nr_colors - 1)
> >  #define mfn_to_color(mfn)           (mfn_x(mfn) & mfn_color_mask)
> > +#define get_mfn_with_color(mfn, color) \
> > +    (_mfn((mfn_x(mfn) & ~mfn_color_mask) | (color)))
> >
> >  /*
> >   * Parse the coloring configuration given in the buf string, following=
 the
> > @@ -364,6 +366,22 @@ unsigned int get_max_nr_llc_colors(void)
> >      return max_nr_colors;
> >  }
> >
> > +mfn_t __init xen_colored_mfn(mfn_t mfn)
> > +{
> > +    unsigned int i, color =3D mfn_to_color(mfn);
> > +
> > +    for ( i =3D 0; i < xen_num_colors; i++ )
> > +    {
> > +        if ( color =3D=3D xen_colors[i] )
> > +            return mfn;
> > +        if ( color < xen_colors[i] )
> > +            return get_mfn_with_color(mfn, xen_colors[i]);
> > +    }
> > +
> > +    /* Jump to next color space (max_nr_colors mfns) and use the first=
 color */
> > +    return get_mfn_with_color(mfn_add(mfn, max_nr_colors), xen_colors[=
0]);
> > +}
> > +
> >  /*
> >   * Local variables:
> >   * mode: C
> > diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-color=
ing.h
> > index 1216d1fbd4..30c8a1d9a6 100644
> > --- a/xen/include/xen/llc-coloring.h
> > +++ b/xen/include/xen/llc-coloring.h
> > @@ -8,6 +8,7 @@
> >  #ifndef __XEN_LLC_COLORING_H__
> >  #define __XEN_LLC_COLORING_H__
> >
> > +#include 
> >  #include 
> >
> >  struct domain;
> > @@ -30,6 +31,17 @@ static inline void domain_dump_llc_colors(const stru=
ct domain *d) {}
> >  static inline void domain_llc_coloring_free(struct domain *d) {}
> >  #endif
> >
> > +/**
> > + * Iterate over each Xen mfn in the colored space.
> > + * @start_mfn:  the first mfn that needs to be colored.
> > + * @mfn:        the current mfn.
> > + * @i:          loop index.
> > + */
> > +#define for_each_xen_colored_mfn(start_mfn, mfn, i) \
> > +    for ( i =3D 0, mfn =3D xen_colored_mfn(start_mfn);  \
> Here and elsewhere you need to enclose 'i' in paranthesis. Otherwise ECLA=
IR will report 20.7 violation.
>
> > +          i < (_end - _start) >> PAGE_SHIFT;        \
> > +          i++, mfn =3D xen_colored_mfn(mfn_add(mfn, 1)) )
> > +
> >  unsigned int get_llc_way_size(void);
> >  void arch_llc_coloring_init(void);
> >  int dom0_set_llc_colors(struct domain *d);
> > @@ -38,6 +50,7 @@ int domain_set_llc_colors(struct domain *d,
> >  int domain_set_llc_colors_from_str(struct domain *d, const char *str);
> >  unsigned int page_to_llc_color(const struct page_info *pg);
> >  unsigned int get_max_nr_llc_colors(void);
> > +mfn_t xen_colored_mfn(mfn_t mfn);
> >
> >  #endif /* __XEN_LLC_COLORING_H__ */
> >
> > --
> > 2.43.0
> >
>
> ~Michal
>

Thanks.

- Carlo


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 14:30:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 14:30:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858160.1270417 (Exim 4.92)
	(envelope-from )
	id 1tNC7H-0005BU-2b; Mon, 16 Dec 2024 14:30:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858160.1270417; Mon, 16 Dec 2024 14: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 1tNC7G-0005BN-W9; Mon, 16 Dec 2024 14:30:34 +0000
Received: by outflank-mailman (input) for mailman id 858160;
 Mon, 16 Dec 2024 14: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 1tNC7F-00058e-Py
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 14:30:33 +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 4de7ac73-bbba-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 15:30:31 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4363ae65100so17101075e9.0
 for ; Mon, 16 Dec 2024 06:30: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-388c80120e8sm8448853f8f.6.2024.12.16.06.30.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 06:30: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: 4de7ac73-bbba-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734359431; x=1734964231; 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=kYZKkBzEG+u1J0E0fhjpe0G6dOD4egf6xz8FN1afcA8=;
        b=CjgF+9Ke6tDEEPTyTYvZMPHk7JrNev5FFQL4gIxLQJptMODkD+TnMxDYh83Ir12uk3
         b8K4vhBGSeymy+PG0tq1a+PO5smc1/cU9723qu5xJ5pPJ6tI6vw6qCOM7iOCSMo9gXQH
         OAFZEDJfbbCmGg/CGRAYXPaFkd/Qv5GX/Ox4dq4ar/syixe0XxsBklrfll0E0uvgAYaC
         HcveRFaGnPfoXEPOZZoSd1BoxR8oa7O9J733rRjq0DnwKPo6fqDXLwgOYUgpRTHOs/n4
         hd8VobE8tlzogWAKwOuGcmJ60cHkaRmMiVXBrQwb8AIJwnxHO047cvnGiU8fe8QWYgFg
         3AVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734359431; x=1734964231;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=kYZKkBzEG+u1J0E0fhjpe0G6dOD4egf6xz8FN1afcA8=;
        b=bibn2mVni4BW4dJMECpfcpeL8wZ/Nc2fJnhgO10EWkgYJwgoRBaZnMv9CzkWZSCxbJ
         6VZommXQHbY03qsBWvTUaK9m/iJZ1dko2JZmPdVdGZWiX9npdibdxz59WZhuSO59uCWB
         sd9OYECcuonDVtnHYnNw43+iVVay9iWwG2UFH66qlLPfO62q+Ap11gtE8C7xyE3cMnSC
         45IjQiMW3BDZ2vcZ8DOlmkAgwHTmmEjPP3cJ9+OgSgEd+vzAc5mQEpxVR0S7Mo/DRlD/
         KS8sS/PJiV4DNU7DwA7n65XzOEeBCuES+UyPrcS1sOGsn7ZNQfn6+eTS1g9iHelxVsJL
         fvDw==
X-Forwarded-Encrypted: i=1; AJvYcCVpGynn4tUqVS916Vs1LHaK/BRJtVvllVYmWWIF4AaB2+Fv/SzR0PQwXYYzD2J2pZj/7IS4EzCN5aA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzkQRgwGKj0+mNjFCDEGG1kMWSNgoI8QOaR2dYGzC4qU48/ORrK
	CzLdToAMeZrd1mCqCUINc1F1JUB42UUWEtAt2N8+klBwZZQDKF7IqidUGBEfVA==
X-Gm-Gg: ASbGncsZPKILgPSKPVOv025vo7n/KlErzJRK7EEpE3qJdsp9TGyNpo2qrEVITTIb60R
	JE/4WMPWxbdccQU50f66NwEc6AeAtEZeomj2qF7wZg//ZnSgaZgwIbIZBqliNPtH+9lP/km6qRG
	ijYSghkzvrNA9XXuxu/g1Eff6qD9QXmwwvZz0ZqrkUe9IsMoL4+SBxYizynutN6mGz7MH3jTSX8
	cR9wDWIgheZeckRSFosA+vhGiDViF65YSYvX/JS0OwjZkqS+YB4pzg/a5sBpKPpZ7Oj1uwzGhqi
	JPHLTR2USJKdVGN5Mbq177MiHxNvhrbiwxH4vE3ENA==
X-Google-Smtp-Source: AGHT+IFXG0tASyJ02bOKLmQz2kd3j56YyHnAJrriI3PymZvSigN2UBSkfM90U3mpskKQlpvo5aUFRw==
X-Received: by 2002:a05:600c:1c16:b0:434:fddf:5c0c with SMTP id 5b1f17b1804b1-4362aa1ac74mr117033905e9.4.1734359431258;
        Mon, 16 Dec 2024 06:30:31 -0800 (PST)
Message-ID: 
Date: Mon, 16 Dec 2024 15:30:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 6/7] xen/riscv: implement prereq for DTB relocation
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <2d2d6ca32aa7db490d47154530f01216651ba335.1733937787.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: <2d2d6ca32aa7db490d47154530f01216651ba335.1733937787.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.12.2024 18:27, Oleksii Kurochko wrote:
> @@ -175,10 +176,16 @@ static inline void invalidate_icache(void)
>  #define clear_page(page) memset((void *)(page), 0, PAGE_SIZE)
>  #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
>  
> -/* TODO: Flush the dcache for an entire page. */
>  static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache)
>  {
> -    BUG_ON("unimplemented");
> +    const void *v = map_domain_page(_mfn(mfn));
> +
> +    BUG_ON(clean_and_invalidate_dcache_va_range(v, PAGE_SIZE));

Please avoid expressions with side effects in BUG_ON(). This wants to be

    if ( clean_and_invalidate_dcache_va_range(v, PAGE_SIZE) )
        BUG();

Then
Acked-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 14:31:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 14:31:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858172.1270427 (Exim 4.92)
	(envelope-from )
	id 1tNC8Z-00066t-DI; Mon, 16 Dec 2024 14:31:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858172.1270427; Mon, 16 Dec 2024 14:31: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 1tNC8Z-00066m-AE; Mon, 16 Dec 2024 14:31:55 +0000
Received: by outflank-mailman (input) for mailman id 858172;
 Mon, 16 Dec 2024 14:31: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 1tNC8Y-00066g-4w
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 14:31:54 +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 7e65c5c1-bbba-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 15:31:53 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-43622267b2eso44557595e9.0
 for ; Mon, 16 Dec 2024 06:31: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-4363606ece8sm86481905e9.25.2024.12.16.06.31.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 06:31: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: 7e65c5c1-bbba-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734359513; x=1734964313; 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=0i4WgwIpdOCqNVhvmx9kuKMmSbzAESTfDxPATpP+aW0=;
        b=WZSawMcfKEw9Uye6iJLijuZoBduS4wLtKmw6B6XapbZS7H7+WxULCnTpAsvSIro9q4
         7xkgX0CtRkAoEtctUt1ixrmY453TwaOeFuoII9njUGHui/IACislONQTY1+AMViEuKZe
         ts4MCiy7AYmfoS6K4/YL6vfWNw33mLpYEhkpIhRqkGC0+zObSSb7JDdODqg8X9vgKuk1
         /ABu+x+3zRtST0+WKeT7UgMwdgvb2EAaszuLpG2wnKVDZ6fMjTWu5m5tFi/ZQOnbQVKb
         a+ESpqllUukko3qz7LPlIgRiyOIO/4KdYIDwmRfD9tf7HW5Ge8Yp2QMqKL1557M7P8Er
         IkpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734359513; x=1734964313;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=0i4WgwIpdOCqNVhvmx9kuKMmSbzAESTfDxPATpP+aW0=;
        b=T5kL4UpbSiFzPzDQvPnnj4QIGfISlNynm6Cm0IiVqGzrcrsfFA5x0QfBTfPIYK1sF9
         FysYCIFW0828kpBrAkwniRzGf7Uo4B7uH5LDcAdrOd2MF4K1lmO/sUXPHgN8k6d3fVRV
         EEAnN1KLQSw4YMKdr/dt+FcBlK1YILdUTL81PxLxKh9AlsDYVzk9wCAHvykjT86mq9OG
         GnlgvYYN1GA1Q1N7VOYLSJBGHjrRQGqJEWndWpLh6bR+C6JOM2XccOND+fuYzQIoiqDZ
         zFOLa5gFmictAHwsrjLFxEqSK59lmVBLj4HmhrB6lndjv8L86AyWIqtfWkkArXDNlX+b
         hoAg==
X-Forwarded-Encrypted: i=1; AJvYcCWDegf5N7frGa9eM9QIgFV6Lj6dqBLEzdFzY9jrsfj3C8CADKJZeygIrqdF1MNZqSdvzM26zwvwVOs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxO1kY3pzu3U6a9En8oF3Ow/DSLVv3SQRIA6vklfpYCNb3plDUc
	BGaT5Dr+7d5Se2v55FJJR/GRm3z+sl/qcDPRxY+DVBYF7h4Yh66XprlgHmXupQ==
X-Gm-Gg: ASbGncsmLZ0D8/G4uLauwlelmCVgk8tRcRSijHQLJiYy/xKL2uiZO55AFOxrPv7K9Np
	3CMFKjdSRKGwpzj47mKuWVeM0fszclk36OkMcno0/0h9TiZyKBu4NfmNQAxMQIqOOVqB1n3Io4l
	7MsHl4bIhytar3cniilqTUmNacvmDpSzkLssjYxnvgG0eeshqOcjjc1o8HKmeithLYS+FeAlsV8
	l9wzHLSgd4XYT2Hl68OLE2pc6eRljmYA62labQ19NqjELBC1vB4jOvJKmH1miHguejxJWg5CcJw
	Oc5OyRaHoUGCLp/NHmT6Cr4PFcvXsQLhlRS+MOe9Ew==
X-Google-Smtp-Source: AGHT+IGeLUKSC0f8xOSf58rSUzPrDanl6uGH22LWlQxBJ6wcIcVupu2VwLT1e0ndI5FRVw73hqqBpw==
X-Received: by 2002:a05:600c:510c:b0:434:a19a:5965 with SMTP id 5b1f17b1804b1-4362aa157afmr113929655e9.6.1734359511596;
        Mon, 16 Dec 2024 06:31:51 -0800 (PST)
Message-ID: <2d5c234a-2a2a-4739-9ff5-828788286dcc@suse.com>
Date: Mon, 16 Dec 2024 15:31:49 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 7/7] xen/riscv: relocating and unflattening host device
 tree
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <8906108d2e29637a42d5e127e393337d6b259b30.1733937787.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: <8906108d2e29637a42d5e127e393337d6b259b30.1733937787.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11.12.2024 18:27, Oleksii Kurochko wrote:
> Introduce relocate_fdt() and call it to relocate FDT to Xen heap
> instead of using early mapping as it is expected that discard_initial_modules()
> ( is supposed to call in the future ) discards the FDT boot module and
> remove_early_mappings() destroys the early mapping.
> 
> Unflatten a device tree, creating the tree of struct device_node.
> It also fills the "name" and "type" pointers of the nodes so the normal
> device-tree walking functions can be used.
> 
> Set device_tree_flattened to NULL in the case when acpi_disabled is
> equal to false.
> 
> Signed-off-by: Oleksii Kurochko 

Acked-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Mon Dec 16 14:36:26 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 14:36:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858181.1270436 (Exim 4.92)
	(envelope-from )
	id 1tNCCr-0006ne-So; Mon, 16 Dec 2024 14:36:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858181.1270436; Mon, 16 Dec 2024 14:36: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 1tNCCr-0006nX-QD; Mon, 16 Dec 2024 14:36:21 +0000
Received: by outflank-mailman (input) for mailman id 858181;
 Mon, 16 Dec 2024 14:36: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 1tNCCq-0006nR-FW
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 14:36:20 +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 1c817799-bbbb-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 15:36:18 +0100 (CET)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-385de59c1a0so2760710f8f.2
 for ; Mon, 16 Dec 2024 06:36: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-388c8046c66sm8241418f8f.69.2024.12.16.06.36.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 06:36: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: 1c817799-bbbb-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734359778; x=1734964578; 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=aQWmUEXPSsL0/T9L3Z0agw2awoqDGq7jOqPA1hXYkiU=;
        b=X3ufXmF85u4aeCzoVgvy4NMYpX0KkeOge7pNfHIfWEYbtNtueu+CKeeiqHjp1e7ufo
         VRKzOsppWNN3esWI2y8h/JuPWGYHuE2b+V2lGnzh41Z3GMNSXZlOAxjBX51N5uCxh9WD
         fBLf15JoNP/LjR+BdiysM1JMCViWpwk35s7MQ9x/QDOvrDuxTMlYLVa/XqgfK46VaUW6
         U5OSUVhGr+fKAeIpyEzwsRjOx17ZwheZ53Y4SBxz+C0wXhLKRvd9aS7H9BXTMHs9HqcK
         pdCxUErvHGu4tO4cIVyGgcQm0FWNVTuH/kcmJ1PejKdm0mfrdl2J2hZPbWru+evZukhV
         1ENg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734359778; x=1734964578;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=aQWmUEXPSsL0/T9L3Z0agw2awoqDGq7jOqPA1hXYkiU=;
        b=LtxuSViwgKe57kJ/3qT+BU8MHCMa3sn+EuSRh7hkR21ACS7jKUIAaniN9h/4ShzCyO
         6SrgrKvmYTxN43ZLPGNLobhuQh9GI85QClev7YioY+fOTIxfOTP6GH8IludnRqpsEKG1
         Nw710kX+lGfGf602zA5n40QbF+JUhwpb3UijuAy0n2YGHrv1ef7zjUiIXkVKk/FMKFgB
         KXx/SWkZkUWCN2sxP8vYYrMAKEiVcMwVr1IuVoJ1KNMf3iGlfoENDWiiFX5Nwi0DaJup
         kKSosiU7G7y0xEtgJxhzdEal5E83g0F2sp1PeXEcW5xhw/IGUGGT6jfReRJL2f5KW9pE
         4dWw==
X-Gm-Message-State: AOJu0Ywe5FpV7uqO7RfSo+yMDzWK44iGRfNy/xMdnFMxXXiDbzRtqHoC
	lu2fKWDeJX42Z28jExQMyjj1NXo0JVWoyHEPQ8/UAH6o2idamIDjmK1qM60Qqg==
X-Gm-Gg: ASbGncvLj2yDYQMXmhi2BOtfcRADIbdXk5SwD67X+SCUY8Lhy5r5ToflL8nIns9H3Df
	7/GLO25Qx1NMq99xYw6ZuLerZtWqBCk5PIlES0j2UWpo4YozoR7O6KDtQ56+nhO8oZC6jtnzn7p
	m+OkkARujj6hxFjcpCRTgFnoJWzWq/htJp1LArAOUWetS/BxOm+JgPxO7j5AyfQJ6cRPW/4F4Qb
	endFeK0C0nA2Y8/J1Q2Xc6I44L6Kw5nbK15ZT0fPg8CsEgxKKEdQi26xOEUxVbM2LFYSAYKh7wQ
	7FBFk73Un8SbWv6D2K6NTK8VDaxNAB4oMJWte5bxxQ==
X-Google-Smtp-Source: AGHT+IEY0VpDZvXduAjOfQtooLMYPcjzaMEzYuCqznyLAEYH8w1sOuwe9NkKzGHg3oP/gjmB8H8YlA==
X-Received: by 2002:a5d:6c68:0:b0:386:1cd3:8a00 with SMTP id ffacd0b85a97d-3888e0ac341mr11028617f8f.40.1734359777850;
        Mon, 16 Dec 2024 06:36:17 -0800 (PST)
Message-ID: 
Date: Mon, 16 Dec 2024 15:36:16 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v12 12/12] xen/arm: add cache coloring support for Xen
 image
To: Carlo Nonato 
Cc: xen-devel@lists.xenproject.org, andrea.bastoni@minervasys.tech,
 marco.solieri@minervasys.tech, Stefano Stabellini ,
 Julien Grall , Bertrand Marquis ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Michal Orzel 
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-13-carlo.nonato@minervasys.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: 8bit

On 16.12.2024 15:28, Carlo Nonato wrote:
> On Mon, Dec 16, 2024 at 2:56 PM Michal Orzel  wrote:
>> On 13/12/2024 17:28, Carlo Nonato wrote:
>>> --- a/xen/arch/arm/arm64/mmu/mm.c
>>> +++ b/xen/arch/arm/arm64/mmu/mm.c
>>> @@ -1,6 +1,7 @@
>>>  /* SPDX-License-Identifier: GPL-2.0-only */
>>>
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>
>>> @@ -138,8 +139,36 @@ void update_boot_mapping(bool enable)
>>>  }
>>>
>>>  extern void switch_ttbr_id(uint64_t ttbr);
>>> +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len);
>>>
>>>  typedef void (switch_ttbr_fn)(uint64_t ttbr);
>>> +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t len);
>>> +
>>> +void __init relocate_and_switch_ttbr(uint64_t ttbr) {
>> CODING_STYLE: { needs to be on its own line
>>
>> Also, this function is only executed in case of LLC coloring, so shouldn't it
>> be #ifdef protected.
> 
> Here and in other places (patch #8) I'm relying on DCE to remove functions
> that are not called. This was a suggestion from Jan in that patch. Can we
> adopt the same here?

Yet how would the compiler spot that the function is unused? That would only
work with LTO / WPO. DCE (as I did suggest elsewhere) requires the functions
in question to be static (allowing the compiler to see enough of the whole
picture).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 14:37:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 14:37:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858188.1270447 (Exim 4.92)
	(envelope-from )
	id 1tNCEA-0007Jn-5Y; Mon, 16 Dec 2024 14:37:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858188.1270447; Mon, 16 Dec 2024 14:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNCEA-0007Jg-2p; Mon, 16 Dec 2024 14:37:42 +0000
Received: by outflank-mailman (input) for mailman id 858188;
 Mon, 16 Dec 2024 14:37: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 1tNCE8-0007JW-6h
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 14:37:40 +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 4c8ee97d-bbbb-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 15:37:39 +0100 (CET)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-385f06d0c8eso1998259f8f.0
 for ; Mon, 16 Dec 2024 06:37:39 -0800 (PST)
Received: from localhost ([85.152.134.39]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c8012081sm8286251f8f.19.2024.12.16.06.37.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 06:37:38 -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: 4c8ee97d-bbbb-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1734359858; x=1734964658; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=qmixK1R7uIJ58XLLGHalch+xpsQmxBAYBg2y8shx5Vc=;
        b=PExY6CiB01tgK3v7pfwulHNCsYLfxeXAcpBWVApD7+R8bmeT2gHn1XtKBFdDLtw4p1
         jcCGdFD8hpiAqF+VqB1h6J/Qw6WijZQd4Y0BJuQMjB4tGGePGTraGMqO7PWnbv/VuBBx
         7iBZvsZGsBaaTK9SOSm3aeDVNzx/30G0qAyUQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734359858; x=1734964658;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=qmixK1R7uIJ58XLLGHalch+xpsQmxBAYBg2y8shx5Vc=;
        b=h9q1/6bTRdXrgrlJLng/7rwKDkwpRAqR+WTp8/fiKjL53ak2IOi9X4zrV45qqpzHWm
         7Yk19JgZbKxaivBOEvHGn+fsBBiBna4kyihk+FptF47J9ZD+qUn2PQ9HJJ8HrvenMsn4
         lkBa9E+juls06evwszV6gRK9SF1R5+t1pXZzwiRKmVNF8IM9nyOqBhQDwvEvY3rEldpp
         KtZVoWrOcNtB2dZplker2HmTI0bCiCIwknDNzq04u7pUc1FQ5Bu9H3Ykcu/kaVf8NBVv
         Yh518z7iyRiB45YbT79yii42S+LBUAC9jHvLDNgrSg1kaeuxPMWUsfulGF0My49QYmLy
         dfmQ==
X-Forwarded-Encrypted: i=1; AJvYcCXAvkpBpFWAodzxJIGaz/8tdYyIjZylAP+BoIC+y08SyimENWbiXBqfRkfz2oSJB2bFD9KoJJ8bSVc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzoDgAsPYC8r9Cj+Z5QeST5Kqo8T0M0UXPX9CD/UcEGSGYlU2UP
	HxffxQ/P0SSLAGWhfnLD1hTJS5Tg8NJBrWH5w6q6mw5/pu0SdX3RPn0iVlDO81U=
X-Gm-Gg: ASbGnctOrTadnRXey4PqS0666cMvdR/bm+o0g7gSL9++pQSaFHqUtbWlZxRQpVeaTWA
	g0fJ+LJbYTsLyLlgvLxCh+MpHQOt3N3qUQJp3iQkNsM2jC9KUgsp/E1ARnQJC+luPEwAvvJ3v6G
	ix1fjWbhzY/4ctodS/DX75y8vclDJRXDihFD+EaN3Xm7AuILn7pH2ffExIY/6OrT24NUhihIRYj
	QLdjvjNy/ruG0VeoYKlcnd7MLUttm0NKrzp67gW54oKJq3HMKoFRhC1+Efosk4=
X-Google-Smtp-Source: AGHT+IHKOQ1T5zlzLZ1O7ljZch543RGQEbbglxnGxBnY+tQAj+mQO79eo+CHbl0Fa4jGd/yyvzENlA==
X-Received: by 2002:a05:6000:1fa9:b0:385:de67:2269 with SMTP id ffacd0b85a97d-3888e0b86f2mr11888788f8f.36.1734359858573;
        Mon, 16 Dec 2024 06:37:38 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Mon, 16 Dec 2024 14:37:35 +0000
Message-Id: 
Cc: "Andrew Cooper" ,
 =?utf-8?q?Roger_Pau_Monn=C3=A9?= ,
 
Subject: Re: [PATCH v2 09/13] x86/emulator: Refactor FXSAVE_AREA to use
 wrappers
From: "Alejandro Vallejo" 
To: "Jan Beulich" 
X-Mailer: aerc 0.18.2
References: <20241105143310.28301-1-alejandro.vallejo@cloud.com>
 <20241105143310.28301-10-alejandro.vallejo@cloud.com>
 
 
 <96c6dbc9-05f3-4e55-acee-5e9f9e2c93e5@suse.com>
In-Reply-To: <96c6dbc9-05f3-4e55-acee-5e9f9e2c93e5@suse.com>

On Mon Dec 16, 2024 at 12:01 PM GMT, Jan Beulich wrote:
> On 16.12.2024 12:58, Alejandro Vallejo wrote:
> > On Mon Dec 9, 2024 at 4:26 PM GMT, Jan Beulich wrote:
> >> On 05.11.2024 15:33, Alejandro Vallejo wrote:
> >>> --- a/xen/arch/x86/x86_emulate/blk.c
> >>> +++ b/xen/arch/x86/x86_emulate/blk.c
> >>> @@ -11,9 +11,12 @@
> >>>      !defined(X86EMUL_NO_SIMD)
> >>>  # ifdef __XEN__
> >>>  #  include 
> >>> -#  define FXSAVE_AREA ((void *)¤t->arch.xsave_area->fpu_sse)
> >>> +/* has a fastpath for `current`, so there's no actual map */
> >>> +#  define FXSAVE_AREA ((void *)VCPU_MAP_XSAVE_AREA(current))
> >>> +#  define UNMAP_FXSAVE_AREA(x) VCPU_UNMAP_XSAVE_AREA(currt ent, x)
> >>
> >> The typo of the first argument strongly suggests that the macro should
> >> already now evaluate its parameters, also pleasing Misra.
> >=20
> > Not an unreasonable takeaway. I can expand as follows instead:
> >=20
> > #define VCPU_UNMAP_XSAVE_AREA(v, x) ({ (void)(v); x; })
> >=20
> > Thoughts?
>
> Why would x not also be cast to void?
>
> Jan

it should have the "x =3D NULL", in fact.

  #define VCPU_UNMAP_XSAVE_AREA(v, x) do { (void)(v); (x) =3D NULL; } while=
(0)

Regardless, the important bit was adding a separate statement for (v) caste=
d to
void. Leaving the rest as-is.

Cheers,
Alejandro


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 14:45:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 14:45:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858203.1270457 (Exim 4.92)
	(envelope-from )
	id 1tNCLQ-0001C5-U9; Mon, 16 Dec 2024 14:45:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858203.1270457; Mon, 16 Dec 2024 14:45: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 1tNCLQ-0001By-Qs; Mon, 16 Dec 2024 14:45:12 +0000
Received: by outflank-mailman (input) for mailman id 858203;
 Mon, 16 Dec 2024 14:45: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 1tNCLP-0001Bs-EV
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 14:45:11 +0000
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com
 [2607:f8b0:4864:20::132])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 58939b11-bbbc-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 15:45:09 +0100 (CET)
Received: by mail-il1-x132.google.com with SMTP id
 e9e14a558f8ab-3a813899384so13878315ab.1
 for ; Mon, 16 Dec 2024 06:45:09 -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: 58939b11-bbbc-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734360308; x=1734965108; 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=3jBIzL4o4vATaS2qlDmBK4XzP69JlBsw4cmvwtoNe6k=;
        b=XAZgJpRjVVMV7mUkwQqNcgXbvYQ5QtHNlTe1H8fwMajTDEV6AxmcXCaqsr2QBfvMkB
         TxgSB6SunzB7gQD/AyUilem9JurraCFkVJ2zXLUpdkyM/iEw0tVeMdMzqeY882byvQKb
         /b2s16uon29YQbS9dnGiRD57uGGu8iRPOUsNANiQTVmu1nkHxrq99Ytrh+943zg4ez1m
         skGkDkY700BLZZSBP6tSE0KnREGSvZH9mVP7hyNYOQK7ercSBDdQOAC7lRdmn4Cb6OUz
         p5rYmFFdc9BFXrij+MJY2sGN9npYJVlRR8H5yWZxiXicnBuvA0dvD2YCdqef9m3kvlNT
         6wwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734360308; x=1734965108;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=3jBIzL4o4vATaS2qlDmBK4XzP69JlBsw4cmvwtoNe6k=;
        b=jYpUiKDtrAegvbblZUFzGkNnI6czqfx7snlXXnzeJNWUn7DjiXDb4w5axxrDxORV8w
         fUgju1/1v9BvTVYdXncZf+8fR+ps3fTOS5ZuXRKMPGnlKwCuIcMZ0HLp8hhngoh0Zzok
         nR2C0b6VnWBeq8hILxiQOnlLomjshOnUQPWEzFlNnGFhxlt3T1pwtb9sQGPFxNwSNCsq
         59vlVnJnVf9H2I1lq72QslVa2+WACIttdkFi2fV5TelIeINcstjZu4XeuOLiDr0aRRCu
         YesSS25SHVi5SpWp6Kppt8xNNvXUCKw1Ybtlc8yLUrY1L3M1qhMPmFsqKalzsIDoZB5p
         GrHA==
X-Gm-Message-State: AOJu0YxVF56fLOtQIjEGsO/Rg8H/WhqrpdfZpIPHaSo5tLUUM+txiyHt
	QTSxV+n3nt2t7d0rnK1ph2r5akrH7tI9b0HR+lKw7LQtBZFMdyqQtUMy7z8SXOjeMOd5J6+7MyK
	5gPYE4vVEaJJkGvYRdBSbXMl07ljglCAuKL/88A==
X-Gm-Gg: ASbGncsoyss5fWlLe+fp14KfI6O9CvcZFVVldiUe6Lle7lePcfoQfDIPTJsB2GqycAA
	hdcMYmSAZiKXa2wcuzMv/FAlkd4NKhocrEKRyltk=
X-Google-Smtp-Source: AGHT+IFcpwvAsb6pnsOmZLiVt9eTtDgs0GogGZX7Iht2+vkX0pkRvtK831x35uvDvC8kS37b0bhm0q6Wbx2dJzQrgpw=
X-Received: by 2002:a05:6e02:1a49:b0:3a7:8d8e:e760 with SMTP id
 e9e14a558f8ab-3aff6212e59mr111056125ab.4.1734360308073; Mon, 16 Dec 2024
 06:45:08 -0800 (PST)
MIME-Version: 1.0
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-13-carlo.nonato@minervasys.tech> 
  
In-Reply-To: 
From: Carlo Nonato 
Date: Mon, 16 Dec 2024 15:44:57 +0100
Message-ID: 
Subject: Re: [PATCH v12 12/12] xen/arm: add cache coloring support for Xen image
To: Jan Beulich 
Cc: xen-devel@lists.xenproject.org, andrea.bastoni@minervasys.tech, 
	marco.solieri@minervasys.tech, Stefano Stabellini , 
	Julien Grall , Bertrand Marquis , 
	Volodymyr Babchuk , Andrew Cooper , 
	Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Michal Orzel 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jan,

On Mon, Dec 16, 2024 at 3:36=E2=80=AFPM Jan Beulich  wro=
te:
>
> On 16.12.2024 15:28, Carlo Nonato wrote:
> > On Mon, Dec 16, 2024 at 2:56=E2=80=AFPM Michal Orzel  wrote:
> >> On 13/12/2024 17:28, Carlo Nonato wrote:
> >>> --- a/xen/arch/arm/arm64/mmu/mm.c
> >>> +++ b/xen/arch/arm/arm64/mmu/mm.c
> >>> @@ -1,6 +1,7 @@
> >>>  /* SPDX-License-Identifier: GPL-2.0-only */
> >>>
> >>>  #include 
> >>> +#include 
> >>>  #include 
> >>>  #include 
> >>>
> >>> @@ -138,8 +139,36 @@ void update_boot_mapping(bool enable)
> >>>  }
> >>>
> >>>  extern void switch_ttbr_id(uint64_t ttbr);
> >>> +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t=
 len);
> >>>
> >>>  typedef void (switch_ttbr_fn)(uint64_t ttbr);
> >>> +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, =
size_t len);
> >>> +
> >>> +void __init relocate_and_switch_ttbr(uint64_t ttbr) {
> >> CODING_STYLE: { needs to be on its own line
> >>
> >> Also, this function is only executed in case of LLC coloring, so shoul=
dn't it
> >> be #ifdef protected.
> >
> > Here and in other places (patch #8) I'm relying on DCE to remove functi=
ons
> > that are not called. This was a suggestion from Jan in that patch. Can =
we
> > adopt the same here?
>
> Yet how would the compiler spot that the function is unused? That would o=
nly
> work with LTO / WPO. DCE (as I did suggest elsewhere) requires the functi=
ons
> in question to be static (allowing the compiler to see enough of the whol=
e
> picture).

Sorry, didn't know that. So I will protect with an #ifdef
relocate_and_switch_ttbr() only.

> Jan

Thanks.

- Carlo


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 14:49:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 14:49:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858216.1270466 (Exim 4.92)
	(envelope-from )
	id 1tNCPa-0001py-HE; Mon, 16 Dec 2024 14:49:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858216.1270466; Mon, 16 Dec 2024 14:49: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 1tNCPa-0001pr-Ed; Mon, 16 Dec 2024 14:49:30 +0000
Received: by outflank-mailman (input) for mailman id 858216;
 Mon, 16 Dec 2024 14:49: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 1tNCPZ-0001pl-RH
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 14:49:30 +0000
Received: from mail133-23.atl131.mandrillapp.com
 (mail133-23.atl131.mandrillapp.com [198.2.133.23])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f27ca8cb-bbbc-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 15:49:27 +0100 (CET)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-23.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4YBjWn5L7Pz35hVQF
 for ; Mon, 16 Dec 2024 14:49:25 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 82e0938de9bb411e81eaa74549021c58; Mon, 16 Dec 2024 14:49: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: f27ca8cb-bbbc-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1734360565; x=1734621065;
	bh=yVc8L/HByx5QGMmakcTUzjf5vsWSBENwyb/0Ge0cI/k=;
	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=PP7z54uoWWFBVy8YiLz5PGxIenQd4kjGgA1Y+vMI2lhtec6MhQ4WeqGFPSwtAEWjR
	 j5Gk/TB+pI5KjTB88TVvRnbujHIPQtKNZhb4loJ+yu1g1f/vS1e7Kog4zRQk2NZ0ml
	 20HNm2tOCEbsANkJZdm/v6GtutIx1SncPcTE7fNTfRaXMvLoyfZAWNLlIQ8HHvTccH
	 8av9znpdS2tLocLxNVn663A1wA/v/5prHXQrldOWQG3SlXQxSIaDe/qCKKHy1re+OC
	 VssvLmvg+Zcl27qOGyYKsk1J7qIuWTM3CvThbI8PTDBIuiecQ2CCIJC5uqzlITJRCh
	 gTHn0k87B9mYQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1734360565; x=1734621065; i=anthony.perard@vates.tech;
	bh=yVc8L/HByx5QGMmakcTUzjf5vsWSBENwyb/0Ge0cI/k=;
	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=xD2pEPM0zS6QGBx0SA3YWyb5FG8k95zQIPBd+ttlmhoiNgGPFRHlYiJWmpuiliQML
	 Lo7aqs8gkLWBIQiPwlniqaxo84fdqPh5zW127FG47iZEqYwFkv6dijaSWrjyj0oNvn
	 oOqA3GBn8+yi0ltJvnfPvVWC53p03oi22lEGpDceszpoH+yG5dvKl/gyYCprM7empm
	 ys9iCcUbXCqGT1X152wcN2/ARtRPayxcl2ZuycKvOo1T23tKm21vSJigIEDAoSZ3AZ
	 8YlYPkT2tPh1QzuP/55I0wxFZYRZ7M6NpKzDD1FTMtPeDtIRRbpzetDi3k0sCL18LE
	 9Kv6MoJp9rieA==
From: "Anthony PERARD" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v3=206/7]=20tools/libs:=20add=20a=20new=20libxenmanage=20library?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1734360565175
To: "Juergen Gross" 
Cc: xen-devel@lists.xenproject.org
Message-Id: 
References: <20241213162421.16782-1-jgross@suse.com> <20241213162421.16782-7-jgross@suse.com>
In-Reply-To: <20241213162421.16782-7-jgross@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.82e0938de9bb411e81eaa74549021c58?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20241216:md
Date: Mon, 16 Dec 2024 14:49:25 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On Fri, Dec 13, 2024 at 05:24:20PM +0100, Juergen Gross wrote:
> diff --git a/tools/include/xenmanage.h b/tools/include/xenmanage.h
> new file mode 100644
> index 0000000000..5d169693b0
> --- /dev/null
> +++ b/tools/include/xenmanage.h
> @@ -0,0 +1,92 @@
> +/* SPDX-License-Identifier: LGPL-2.1 */

This should read "LGPL-2.1-only".

> diff --git a/tools/libs/manage/core.c b/tools/libs/manage/core.c
> new file mode 100644
> index 0000000000..b5fa67b036
> --- /dev/null
> +++ b/tools/libs/manage/core.c
> @@ -0,0 +1,168 @@

> +static int xenmanage_do_domctl_get_domain_state(xenmanage_handle *hdl,
> +                                                unsigned int domid_in,
> +                                                unsigned int *domid_out,
> +                                                unsigned int *state,
> +                                                uint64_t *unique_id)
> +{
> +    struct xen_domctl *buf;
> +    int saved_errno;
> +    int ret;
> +
> +    buf = xencall_alloc_buffer(hdl->xcall, sizeof(*buf));
> +    if ( !buf )
> +    {
> +        errno = ENOMEM;

Is this necessary? Isn't xencall_alloc_buffer() going to set `errno`? Or
is it to overwrite `errno` set by system calls which could be other than
ENOMEM?

> +        return -1;
> +    }

Otherwise, patch looks fine to me: Reviewed-by: Anthony PERARD 

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 Dec 16 14:54:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 14:54:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858228.1270477 (Exim 4.92)
	(envelope-from )
	id 1tNCUf-0003zg-4C; Mon, 16 Dec 2024 14:54:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858228.1270477; Mon, 16 Dec 2024 14:54: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 1tNCUf-0003zZ-15; Mon, 16 Dec 2024 14:54:45 +0000
Received: by outflank-mailman (input) for mailman id 858228;
 Mon, 16 Dec 2024 14:54: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 1tNCUd-0003zT-Ng
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 14:54:43 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20629.outbound.protection.outlook.com
 [2a01:111:f403:2418::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id addc9f98-bbbd-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 15:54:42 +0100 (CET)
Received: from BN9PR03CA0225.namprd03.prod.outlook.com (2603:10b6:408:f8::20)
 by SA0PR12MB4413.namprd12.prod.outlook.com (2603:10b6:806:9e::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.22; Mon, 16 Dec
 2024 14:54:38 +0000
Received: from BN3PEPF0000B372.namprd21.prod.outlook.com
 (2603:10b6:408:f8:cafe::94) by BN9PR03CA0225.outlook.office365.com
 (2603:10b6:408:f8::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8230.18 via Frontend Transport; Mon,
 16 Dec 2024 14:54:38 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN3PEPF0000B372.mail.protection.outlook.com (10.167.243.169) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8272.0 via Frontend Transport; Mon, 16 Dec 2024 14:54:37 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 16 Dec
 2024 08:54:37 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 16 Dec 2024 08:54:35 -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: addc9f98-bbbd-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TLwaWLyg4ubZ9GzuxPoGl02ZQ89wF1SYQ3weEAonkyKboamlFnGaG2bJFIuSf36/gvgvQcq+3xnX9d3+/JrF5hy7pQLGKyLEzj9wjzQOuY/rKxNLGdIkx7ZfRkGBnDsKOQj7f8VGrq08/wP2fhHACSnnrEifrbmXseDYz7nnckNc5pr4GUMgLB3iplSgpsYGI0D3LcVrqHAh5AFJBVx+plBFGIeFv6PfqOOevoF0Qn0ZBcFgX8iU1uZfbVLJjljiyV9YpyHPaWBvG/H6z5CjtrNaKr5WhRnM2+PJrnfkiX4jS8SgcOxrxd4Q8X74g0EiAzWZgt1r5ehWtzz9vhwXLg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=8jx4YTWH4aXYEjjuOnHuBsDma2MLcE157dQwiArtFHQ=;
 b=ePc+of7i31GAG9mHKKtnW1HkW6r5xJvgCvCgacX9SiHVHK7YsaLV8Vl/gRH5GEhvAZM4WEj06Fo+eyiNA9+WqFqBP+eoH5AP/YVMzTHnX/x+dFoMLrd7EUklVcnKGuTcp+dnisWPm7mvfvMUhJnsoCro/S2TfJglBr8x89AydUj0pxd/qmfToLj32+B6dRp7GmR+KQ5GCQFm3vW6jVK92b7r0V76c/MY/9VhMLa/0TnTHA2TMwwD5yPQl01cLoLGCKRVdhBUXa/YhTK0QUwRiI9Qvrs596Udr0V7JuGICkUpG5xBlwEA1oLItiKv4lA4Wol9V17k4tGC5un18ZjFwg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=minervasys.tech smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=8jx4YTWH4aXYEjjuOnHuBsDma2MLcE157dQwiArtFHQ=;
 b=PLmZq+SaeSi4YwLK6mvif9LeWrflgVJtPPWlrTYkpZ0kDFirwVPGItADcDt910yde9PcydFG3cSEKgSbmZfgn9Yy6gyyh5FLZusCOY4MKOHrDGmdXDrRHuk+ynoigIko3CvC9kWAvD+EuxiDEk6D7IKvfy1Amdfp0H4/j9UznWU=
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=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Mon, 16 Dec 2024 15:54:34 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v12 12/12] xen/arm: add cache coloring support for Xen
 image
To: Carlo Nonato 
CC: , ,
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Volodymyr Babchuk , Andrew Cooper
	, Anthony PERARD , Jan
 Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-13-carlo.nonato@minervasys.tech>
 
 
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN3PEPF0000B372:EE_|SA0PR12MB4413:EE_
X-MS-Office365-Filtering-Correlation-Id: f39c6a76-1ecd-4ca8-114a-08dd1de19026
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|7416014|376014|36860700013|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?OGdVemV6VGt5NWFFUmszNTVKY1IyY1J4MHZENmdkbXFMSUZHdUVsOXl1eVRD?=
 =?utf-8?B?Tk41cjZtQWxCTDRTclFDOWFzL29CblNKZE9TYWNZTGpScE9Tak9nek1mQ3dy?=
 =?utf-8?B?eW5haHVqVnF6eXNqb1l0dEt5c2VUVG9WQlJVb1A1cmZodU1heXJmeGRkeHZL?=
 =?utf-8?B?VW1ZL2dla0hJTm53VUhPdndWLzdGaldBdSsvTVZBTFFrWnVkbjVzUWFxL2RJ?=
 =?utf-8?B?RldmcnU2UHdzaldQa1NyUnNKemg0N1FDQU85UVIxKzdwZWZRbVFWWHd1Y0Zx?=
 =?utf-8?B?NjJkdzIxMkFxbHV1dVBHdDFqS1lTOXdZd0d3NUxxZ2FyTWE0cEJ0dkg5ZCtE?=
 =?utf-8?B?VWxKbnpCTlphLzVmYjRIb2xzMUNQSlVJbGR3ZC9LYlNzK01JMVJUc29HcWFw?=
 =?utf-8?B?OTFtaXkvdzNCd3YxUE4yUytycGtUVEtmTURlVU5GeUVhV1dUTFpUOVplSkdv?=
 =?utf-8?B?cEpITWhyK0lmeWcyR1FXR2ZDcmFDSXhhbFZoQUNJb0M1WjB6clA5b3NlZWJE?=
 =?utf-8?B?UkxHZ3c1SWNVb2xNcStKSU9kRGRWc0FSYmFPSjY0Nld4bXBPTSsxYTlSNGU5?=
 =?utf-8?B?SEhaNGpCVElWcmRndWF6OGQ5Ykg2Z2lrb1BDQ2phazRHTEg5QUV6dWErMjBZ?=
 =?utf-8?B?QVRCNUhiMnY3QmdwbmFKSmtFVWVzbHNHK3NYL3NkQ3djRXlVSFNTNFpvcEV1?=
 =?utf-8?B?Vkt4NDI1NFR0b3dxUEg4SnBFa09OY2ZHUWVQdk9RSnRNR1cxZk5lWDhwaUN1?=
 =?utf-8?B?bStoUnlzbHpaRW54UzU5RWJQYzM4c0VHcTl2RmV0RlBkZndEV0MzYzR6b3Nw?=
 =?utf-8?B?bk1KZjYyZTlPMTVjVGJkNUVQblBQYnJGdjlVam1nYWJqNTg1R2dib1F4WERM?=
 =?utf-8?B?RzVORklpdDg2eFcxVEZURGNvc1c3YmRJcE1CUitqeDVDUzk1aXZjZzlNTGRJ?=
 =?utf-8?B?d1M2akxaT00ybXVqcmUrLzYrTHJJZmo0QlNiVTNBcTJsOWZyOWZZSldjNzVZ?=
 =?utf-8?B?MXRIcytyRkt5eG40RTR0V3M5S2NaM1NXT3ovMlRzSjlKaUQrbjhpb1czK2g4?=
 =?utf-8?B?bkhGN2QrbjY5R1BwNWNVb09uYXlUWm1jVEdrR2RTQ3VFMFdodGU4OUtydXlp?=
 =?utf-8?B?M0xUeFFxSFF4ZGU5cHBKRnhLY1V5RWZwYmhkQkVBY21WVktGbTRtVDREOGxG?=
 =?utf-8?B?VSswNEpGQjcvbWJ1NUFzTkRpcUVXREJBb28zT3p4dXB3cEYxa0ZYMDNid29P?=
 =?utf-8?B?RnhDQkpOUHFMVW82NTl0cmg5cENHUDlWVC8zeUMyZSs5LzZxK2ZMOGJtbWJE?=
 =?utf-8?B?VWxRbUhOQU4yN2t0NmQwK2lJS1VTU0llZUxJL3d3QUFVSkErbndQQnhONlVY?=
 =?utf-8?B?UmhqL0ZOREltOTQwbnUzeFlmU1VTUzBsT010K28vWklOdHFoSEFLMFlvT1A2?=
 =?utf-8?B?QmlXb1FEdm5tcVY1eWVrdWE3aFdQNmoxYkwxTWFFejc4bW96cHExWGNJNDJJ?=
 =?utf-8?B?UmR1RVFQZzY0V2VxVW81aGNTVTZkNVpOR3NLLys3VDczaHM0N04xRTNNMEc1?=
 =?utf-8?B?N01yTmk5M094VUhMcmd3aEhURHJlTjJiVUdmelkrTi9GdERQcWxVVVp3NVAv?=
 =?utf-8?B?T0NqUDVhMHFreFBhNHRzdGRWK1RVVldKbExBUlU3R0J1blliQ1A3ZTJsOXR6?=
 =?utf-8?B?SDVBdVQ1YXdUUkgyNmZpcnhqOWp5Myt3aVdvMUpOQ28rNW9RUEhjOXM0L1BI?=
 =?utf-8?B?R1J3bTJlVFovSXh2VEs1RHRzSU4zNFNrWXhaODlCM1pJU1hlV3hoc2lCWlB0?=
 =?utf-8?B?dDV1cDFXMkFXWEhYejFIbkNCeXE1Zkt2T1d0clo4S2tMZjkrZlpDcTkrZTBh?=
 =?utf-8?B?QWxFeE5HSTl0MGZWZ3F6TXNiMXF3UnVsQmR2eWJjWHhsMlF6T08wcVhBZDNH?=
 =?utf-8?B?eWtMeWdjT2czdnlGMTRGcVNzdWdqcVZjWmpGa0g3c1lSVm5kbnZKRjdXYUYw?=
 =?utf-8?Q?TK6RrW8Eb08+4wE0yijPu4LvuftuF4=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(36860700013)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Dec 2024 14:54:37.8956
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f39c6a76-1ecd-4ca8-114a-08dd1de19026
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B372.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4413



On 16/12/2024 15:28, Carlo Nonato wrote:
> 
> 
> Hi Michal,
> 
> On Mon, Dec 16, 2024 at 2:56 PM Michal Orzel  wrote:
>>
>> On 13/12/2024 17:28, Carlo Nonato wrote:
>>>
>>> Xen image is relocated to a new colored physical space. Some relocation
>>> functionalities must be brought back:
>>> - the virtual address of the new space is taken from 0c18fb76323b
>>>   ("xen/arm: Remove unused BOOT_RELOC_VIRT_START").
>>> - relocate_xen() and get_xen_paddr() are taken from f60658c6ae47
>>>   ("xen/arm: Stop relocating Xen").
>>>
>>> setup_pagetables() must be adapted for coloring and for relocation. Runtime
>>> page tables are used to map the colored space, but they are also linked in
>>> boot tables so that the new space is temporarily available for relocation.
>>> This implies that Xen protection must happen after the copy.
>>>
>>> Finally, since the alternative framework needs to remap the Xen text and
>>> inittext sections, this operation must be done in a coloring-aware way.
>>> The function xen_remap_colored() is introduced for that.
>>>
>>> Signed-off-by: Carlo Nonato 
>>> Signed-off-by: Marco Solieri 
>>> Reviewed-by: Jan Beulich  # common

[...]

>> Also, this function is only executed in case of LLC coloring, so shouldn't it
>> be #ifdef protected.
> 
> Here and in other places (patch #8) I'm relying on DCE to remove functions
> that are not called. This was a suggestion from Jan in that patch. Can we
> adopt the same here?
Yes, we can.

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 15:03:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 15:03:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858239.1270487 (Exim 4.92)
	(envelope-from )
	id 1tNCd2-0005ua-TW; Mon, 16 Dec 2024 15:03:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858239.1270487; Mon, 16 Dec 2024 15:03: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 1tNCd2-0005uT-Qm; Mon, 16 Dec 2024 15:03:24 +0000
Received: by outflank-mailman (input) for mailman id 858239;
 Mon, 16 Dec 2024 15:03: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 1tNCd1-0005uN-QX
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 15:03:23 +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 e4a8ad4d-bbbe-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 16:03:22 +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 ABD64210F7;
 Mon, 16 Dec 2024 15:03: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 50C49137CF;
 Mon, 16 Dec 2024 15:03: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 L7IAEjlBYGeXeAAAD6G6ig
 (envelope-from ); Mon, 16 Dec 2024 15:03: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: e4a8ad4d-bbbe-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734361401; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=6oxPavJAQ2tOHwMF0+YPPD3qM221eRPoTsGqGkyo+DQ=;
	b=tf7ZGa4K53uAghLrhwDCd7poPH3IgV5D541L/pbK+yeJ+W6N9B83mMQ4zuwhVMfRpwt9aL
	yj6pdklhEm9wFBA5iXUVFPt6UhYuKm1/883eP0+9jQmMUeK6V/ejOZ2RltrpnywcsgvL7i
	qAyeIzv7olmQWrDTT95UkzSp+nXbL0M=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734361401; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=6oxPavJAQ2tOHwMF0+YPPD3qM221eRPoTsGqGkyo+DQ=;
	b=tf7ZGa4K53uAghLrhwDCd7poPH3IgV5D541L/pbK+yeJ+W6N9B83mMQ4zuwhVMfRpwt9aL
	yj6pdklhEm9wFBA5iXUVFPt6UhYuKm1/883eP0+9jQmMUeK6V/ejOZ2RltrpnywcsgvL7i
	qAyeIzv7olmQWrDTT95UkzSp+nXbL0M=
Message-ID: <7061e31b-2d61-40fd-b2e9-528c4faf41f9@suse.com>
Date: Mon, 16 Dec 2024 16:03:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 5/7] xen: add new domctl get_changed_domain
To: Jan Beulich 
Cc: "Daniel P. Smith" ,
 Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241213162421.16782-1-jgross@suse.com>
 <20241213162421.16782-6-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: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------eBShTiMpm0if4XJTCQ1HQXLR"
X-Spam-Level: 
X-Spamd-Result: default: False [-5.19 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SIGNED_PGP(-2.00)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-0.99)[-0.992];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_BASE64_TEXT(0.10)[];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_HAS_DN(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[9];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid]
X-Spam-Score: -5.19
X-Spam-Flag: NO

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------eBShTiMpm0if4XJTCQ1HQXLR
Content-Type: multipart/mixed; boundary="------------oHtuBs9JURHoG0uU4UYM0QMP";
 protected-headers="v1"
From: Juergen Gross 
To: Jan Beulich 
Cc: "Daniel P. Smith" ,
 Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
Message-ID: <7061e31b-2d61-40fd-b2e9-528c4faf41f9@suse.com>
Subject: Re: [PATCH v3 5/7] xen: add new domctl get_changed_domain
References: <20241213162421.16782-1-jgross@suse.com>
 <20241213162421.16782-6-jgross@suse.com>
 
In-Reply-To: 
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------oHtuBs9JURHoG0uU4UYM0QMP
Content-Type: multipart/mixed; boundary="------------ckbKbWWbl3D9OqxBh3HkQAdz"

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

T24gMTYuMTIuMjQgMTE6NDEsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxMy4xMi4yMDI0
IDE3OjI0LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gLS0tIGEveGVuL2NvbW1vbi9kb21h
aW4uYw0KPj4gKysrIGIveGVuL2NvbW1vbi9kb21haW4uYw0KPj4gQEAgLTE5Myw2ICsxOTMs
NTcgQEAgc3RhdGljIHZvaWQgZG9tYWluX2NoYW5nZWRfc3RhdGUoY29uc3Qgc3RydWN0IGRv
bWFpbiAqZCkNCj4+ICAgICAgIHNwaW5fdW5sb2NrKCZkb21fc3RhdGVfY2hhbmdlZF9sb2Nr
KTsNCj4+ICAgfQ0KPj4gICANCj4+ICtzdGF0aWMgdm9pZCBzZXRfZG9tYWluX3N0YXRlX2lu
Zm8oc3RydWN0IHhlbl9kb21jdGxfZ2V0X2RvbWFpbl9zdGF0ZSAqaW5mbywNCj4+ICsgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qgc3RydWN0IGRvbWFpbiAqZCkN
Cj4+ICt7DQo+PiArICAgIGluZm8tPnN0YXRlID0gWEVOX0RPTUNUTF9HRVRET01TVEFURV9T
VEFURV9FWElTVDsNCj4+ICsgICAgaWYgKCBkLT5pc19zaHV0X2Rvd24gKQ0KPj4gKyAgICAg
ICAgaW5mby0+c3RhdGUgfD0gWEVOX0RPTUNUTF9HRVRET01TVEFURV9TVEFURV9TSFVURE9X
TjsNCj4+ICsgICAgaWYgKCBkLT5pc19keWluZyA9PSBET01EWUlOR19keWluZyApDQo+PiAr
ICAgICAgICBpbmZvLT5zdGF0ZSB8PSBYRU5fRE9NQ1RMX0dFVERPTVNUQVRFX1NUQVRFX0RZ
SU5HOw0KPj4gKyAgICBpZiAoIGQtPmlzX2R5aW5nID09IERPTURZSU5HX2RlYWQgKQ0KPj4g
KyAgICAgICAgaW5mby0+c3RhdGUgfD0gWEVOX0RPTUNUTF9HRVRET01TVEFURV9TVEFURV9E
RUFEOw0KPj4gKyAgICBpbmZvLT51bmlxdWVfaWQgPSBkLT51bmlxdWVfaWQ7DQo+PiArfQ0K
Pj4gKw0KPj4gK2ludCBnZXRfZG9tYWluX3N0YXRlKHN0cnVjdCB4ZW5fZG9tY3RsX2dldF9k
b21haW5fc3RhdGUgKmluZm8sIHN0cnVjdCBkb21haW4gKmQsDQo+PiArICAgICAgICAgICAg
ICAgICAgICAgZG9taWRfdCAqZG9taWQpDQo+PiArew0KPj4gKyAgICB1bnNpZ25lZCBpbnQg
ZG9tOw0KPj4gKw0KPj4gKyAgICBpZiAoIGluZm8tPnBhZDAgfHwgaW5mby0+cGFkMSApDQo+
PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsNCj4+ICsgICAgaWYgKCBkICkNCj4+
ICsgICAgew0KPj4gKyAgICAgICAgc2V0X2RvbWFpbl9zdGF0ZV9pbmZvKGluZm8sIGQpOw0K
Pj4gKw0KPj4gKyAgICAgICAgcmV0dXJuIDA7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAg
d2hpbGUgKCAoZG9tID0gZmluZF9maXJzdF9iaXQoZG9tX3N0YXRlX2NoYW5nZWQsIERPTUlE
X01BU0sgKyAxKSkgPA0KPj4gKyAgICAgICAgICAgIERPTUlEX0ZJUlNUX1JFU0VSVkVEICkN
Cj4+ICsgICAgew0KPj4gKyAgICAgICAgaWYgKCB0ZXN0X2FuZF9jbGVhcl9iaXQoZG9tLCBk
b21fc3RhdGVfY2hhbmdlZCkgKQ0KPiANCj4gRm9yIHRoZXNlIHR3byBhY2Nlc3NlcyB0byBk
b21fc3RhdGVfY2hhbmdlZCBkb24ndCB5b3UgbmVlZCB0byBob2xkIHRoZQ0KPiBsb2NrIHBh
dGNoIDQgaW50cm9kdWNlcz8gQWxzbyBkaWRuJ3QgeW91IHNheSB5b3UnZCBjb25zdHJhaW4g
dGhlIG5ldw0KPiBzdWItb3AgdG8gdGhlIHNvbGUgZG9tYWluIGhhdmluZyBWSVJRX0RPTV9F
WEVDIGJvdW5kICh3aGljaCwgZnRhb2QsDQo+IGlzbid0IGVub3VnaCB0byBlbGltaW5hdGUg
dGhlIHJhY2UpPw0KDQpKdXN0IHRvIGJlIG1vcmUgc3BlY2lmaWMgcmVnYXJkaW5nIHRoZSBy
YWNlOiBJIGd1ZXNzIHlvdSBtZWFuIHRoYXQgYSBkb21haW4NCmhhdmluZyByZWdpc3RlcmVk
IGZvciB0aGUgVklSUSBkb2Vzbid0IG1lYW4gdGhlIGNhbGxpbmcgY29tcG9uZW50IGJlaW5n
IGluDQp0aGF0IGRvbWFpbiByZWFsbHkgaXMgdGhlIG9uZSBhc3NvY2lhdGVkIHdpdGggdGhl
IFZJUlEuDQoNCldoaWxlIGJlaW5nIHRydWUsIGV2ZW4gdG9kYXkgaXQgaXMgcG9zc2libGUg
Zm9yIG9uZSBkb20wIHVzZXIgcHJvY2VzcyB0bw0KInN0ZWFsIiBhIFZJUlEgZnJvbSBhbm90
aGVyIHByb2Nlc3MgYnkgdXNpbmcgZGlydHkgdHJpY2tzIHZpYSB0aGUgcHJpdmNtZA0KZHJp
dmVyLg0KDQpJbiB0aGUgZW5kIGEgcHJvY2VzcyBoYXZpbmcgdGhlIGFjY2VzcyByaWdodHMg
dG8gdXNlIHRoZSBwcml2Y21kIGRyaXZlciBtdXN0DQpiZSB0cnVzdGVkIHRvIG5vdCBkaXN0
dXJiIG90aGVyIHByb2Nlc3NlcyB3aXRoIHRoZSBzYW1lIHJpZ2h0cy4NCg0KDQpKdWVyZ2Vu
DQo=
--------------ckbKbWWbl3D9OqxBh3HkQAdz
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-----

--------------ckbKbWWbl3D9OqxBh3HkQAdz--

--------------oHtuBs9JURHoG0uU4UYM0QMP--

--------------eBShTiMpm0if4XJTCQ1HQXLR
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/Ey8FAmdgQTgFAwAAAAAACgkQsN6d1ii/Ey+r
sQf9GoDE6HTtYgYnabiANB2JQUNm0E24cxa8BoTA8+Spq/HkRrWsJpOLOifCPUjf1hjBCxqcJ99o
mXgEakRbCmxSWNLgDk0ajIiPp7j93W0lSmrtWzmca8QtNtloqfsRk+FQomht3A0XmS99BkebJTtN
X1eiaLDREzgxVnviAYct95Q5FPA+t4qteWL4PH+EDdN1s26UmBwM4BbSzqJJyMcQbGNsk5T79NNn
OffePFQwFFp+ok2ZZn6ylwx2LPsh5O0HPqAjdXgEtJhZfefyjQebRuYLaYu9pejpjYk2XNXGp+wB
v5P0nPBh2cZoA2njDKWT3rEe2wDNbNbIV7zefZad/A==
=jOon
-----END PGP SIGNATURE-----

--------------eBShTiMpm0if4XJTCQ1HQXLR--


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 15:04:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 15:04:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858248.1270496 (Exim 4.92)
	(envelope-from )
	id 1tNCdn-0006Ys-9g; Mon, 16 Dec 2024 15:04:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858248.1270496; Mon, 16 Dec 2024 15:04:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNCdn-0006Yl-74; Mon, 16 Dec 2024 15:04:11 +0000
Received: by outflank-mailman (input) for mailman id 858248;
 Mon, 16 Dec 2024 15:04: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 1tNCdl-0005uN-Ld
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 15:04:09 +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 000dd43d-bbbf-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 16:04:08 +0100 (CET)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-4361d5dcf5bso46353205e9.3
 for ; Mon, 16 Dec 2024 07:04: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-43625706595sm144543735e9.33.2024.12.16.07.04.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 07:04: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: 000dd43d-bbbf-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734361448; x=1734966248; 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=nvnjmLw43p1KWuoTBVdL9LiP00PV4rKQ/YSw55O7Xpo=;
        b=C2KCOpX/HrPrRXCp0HaJkC/ASvzKjwm5ie2N2wfKww9yOanNo10X8zTtnA8aEKJROX
         NqQTjYf4MEP1TdmoEok2L36n1bTJFJ8nLTtIt/efvp8X63DpqXGn8Ty5iHs4n+C5Ip9K
         fUwpCQ81eBqxCj5HQa545137YV/bypspfDCHLIY0vi5tH8y7IURDUPVU48s0SuNwy+xq
         rY+LKhKbHJ65vMkDbC5eTZHdOHPD7DIfNphCKnN9FX5D0LyiO9DsFtskto5wQQBFIjyk
         /+zt5I6hn4SDvXTAqXWRhZTKdw2vQXytSq4aIlPi7osX/ZWk6fo4dyU5JWKTL5e74mLV
         7yYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734361448; x=1734966248;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nvnjmLw43p1KWuoTBVdL9LiP00PV4rKQ/YSw55O7Xpo=;
        b=dnr9MzFe5Q0CdFiF4AolkHGNgyXbN5dwV8OaphePU+j7mY8tKi+NH6hLwWKq/vfQIz
         +aFOYRmK/kOK0TDtn6wbf6wp4QuCyqGddfBPxbPIk3BsM6yBtuC7HvFntaSF75BYJMCA
         WVZSa0Ni94rY21mMr9p5WRpROSpCt1BF8CuIiDGHQmaRb/g7iHwYWh7tFjZ7sDDbsJdR
         3xXVBHjCUfMLMokb/wnigq107nuEW6e18jArZ1Uzd2A3q526ucr7n3PM4QsRuUb6MBwJ
         v+P+AH/eLEr0h2LDCYAD0ihOqlqlPS5ybiqI8qqm+bXOT7wVmdQSkH1idkLzluwMw+ZC
         G4aw==
X-Forwarded-Encrypted: i=1; AJvYcCWxtCjTca58UNqcA34euCk6H70wUQARn2daDf/MuIU5QoohtnTur/dsVaVLdOMzNshIlwfK/9Jf+mk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywd3mFK4RJH2A22+g2Vuhh59VER20079St521g/g+5C6iPY8/28
	s1hrtST9w9JAcUIqo6IpnwTzIL6QTrnmEb+EEjABSB45N5Ums/MQL0iPM6znOn72r/PzstMzSkM
	=
X-Gm-Gg: ASbGncs6m4uUPjld/daTaCJyHfsuHsFmr7VV4Nyp3gCK2h0+Nud0B3W0ZKNwfxhQU0J
	tDL6v1XlGWO5ygNtew0G2okzZKgl+03hMxDa4SbqmzKREqEMvvK3CUghOQGWCQW4li1JzvXVhIb
	G4oXbLAnV2+ltvShRXbStOHezNauhc9m+PiUGcvLenQwT9ytRi3CNfX+f7I67Ak5YTeNxT98hrp
	vcl8GI/B2ekNZCZW25W2X1hPPpIWzci1PNhOkW1n6Qhir7ZaDzZxJIM0ilnvK+CPIR84OzIqAId
	XLWxI8eGj2a3+tNdSTrNQDujWhyBisESNdqUJoCyNw==
X-Google-Smtp-Source: AGHT+IF+8wEq6qscHxROqvtqQilfBJBpY3muvrid1HP/mlz7JGhw7wHKBJbEW5g1JWo5dMlj5rcP2g==
X-Received: by 2002:a05:600c:524c:b0:434:f396:525e with SMTP id 5b1f17b1804b1-4362aa28541mr123138535e9.9.1734361447475;
        Mon, 16 Dec 2024 07:04:07 -0800 (PST)
Message-ID: <3be247cc-900b-48f3-98f3-0d97532ede76@suse.com>
Date: Mon, 16 Dec 2024 16:04:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 31/35] x86/hvm: introduce NS8250 UART emulator
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-31-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-31-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:42, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin 
> 
> Add initial in-hypervisor emulator for NS8250/NS16x50-compatible UARTs under
> CONFIG_HAS_VUART_NS8250.
> 
> In parallel domain creation scenario (hyperlaunch), NS8520 emulator helps
> early guest OS bringup debugging, because it eliminates dependency on the
> external emulator being operational by the time domains are created. Also,
> there's no early console facility similar to vpl011 to support x86 guest OS
> bring up.
> 
> By default, CONFIG_HAS_VUART_NS8250 enables emulatio of NS8250 at I/O port
> 0x3f8, IRQ#4 in guest OS.
> 
> Limitations:
> - Only x86;
> - Only Linux guest tested so far;
> - Only legacy COM{1,2,3,4} resources, no customization;
> - Only Xen console as a backend, no inter-domain communication (similar to
>   vpl011 on Arm);
> - Only 8-bit characters;
> - Baud rate is not emulated;
> - FIFO-less mode is not emulated properly;

With in particular this, why would it be called 8250 emulation in the first
place? The driver Xen uses for itself is in ns16550.c; I'd suggest to call
the child here ns16550 emulation right away, using vns16550.c as the file
name.

> --- a/xen/arch/x86/hvm/Kconfig
> +++ b/xen/arch/x86/hvm/Kconfig
> @@ -61,3 +61,17 @@ config HVM_FEP
>  	  for use in production.
>  
>  	  If unsure, say N.
> +
> +config HAS_VUART_NS8250
> +	bool "NS8250-compatible UART Emulation"

HAS_* options may not have prompts; they merely declare something to the
rest of the build system.

> +	depends on HVM && HAS_IOPORTS

Why HAS_IOPORTS?

> +	default n

No need for this.

> --- a/xen/arch/x86/hvm/Makefile
> +++ b/xen/arch/x86/hvm/Makefile
> @@ -29,3 +29,4 @@ obj-y += vm_event.o
>  obj-y += vmsi.o
>  obj-y += vpic.o
>  obj-y += vpt.o
> +obj-$(CONFIG_HAS_VUART_NS8250) += vuart_ns8250.o

If the vuart name pretix is to remain, then please avoid underscores in
the names of new files, in favor of dashes.

> --- /dev/null
> +++ b/xen/arch/x86/hvm/vuart_ns8250.c
> @@ -0,0 +1,886 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * NS8250-compatible UART Emulator.
> + *
> + * Limitations:
> + * - Only x86;
> + * - Only Linux guest tested so far;
> + * - Only legacy COM{1,2,3,4} resources, no customization;
> + * - Only Xen console as a backend, no inter-domain communication (similar to
> + *   vpl011 on Arm);
> + * - Only 8-bit characters;
> + * - Baud rate is not emulated;
> + * - FIFO-less mode is not emulated properly;
> + * - RX FIFO interrupt moderation (FCR) is not emulated properly, TL16C750
> + *   has special FCR handling;
> + * - No integration w/ VM snapshotting (HVM_REGISTER_SAVE_RESTORE() and
> + *   friends);
> + * - Assumes no ISA-device IRQ sharing;
> + * - MMIO-based UART is not supported;
> + * - PCI UART is not supported.
> + */
> +
> +#define pr_fmt(fmt)         "ns8250: " fmt
> +#define pr_log_level        hvm_ns8250_log_level
> +
> +/* Development debugging */
> +#define NS8250_LOG_LEVEL    0
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include  /* console_input_domid() */
> +#include    /* max_init_domid */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#if !defined(pr_fmt)
> +#define pr_fmt(fmt) fmt
> +#endif
> +
> +#if !defined(pr_log_level)
> +#define pr_log_level 0
> +#endif
> +
> +#define pr_err(fmt, args...) \
> +    gprintk(KERN_ERR, pr_fmt(fmt), ## args)
> +#define pr_warn(fmt, args...) \
> +    if (pr_log_level) gprintk(KERN_WARNING, pr_fmt(fmt), ## args)
> +#define pr_info(fmt, args...) \
> +    if (pr_log_level) gprintk(KERN_INFO, pr_fmt(fmt), ## args)
> +#define pr_debug(fmt, args...) \
> +    if (pr_log_level) gprintk(KERN_DEBUG, pr_fmt(fmt), ## args)

On top of Roger's remark here: _If_ you use such wrapper macros, then
please arrange for them to be usable in arbitrary context. Think of

    if ( condition )
        pr_info(...);
    else
        ...

> +/*
> + * NS8250 emulator state machine logging (development only)
> + * FIXME: use similar to parse_guest_loglvl()
> + */
> +static unsigned int __read_mostly hvm_ns8250_log_level = NS8250_LOG_LEVEL;
> +integer_param("hvm.ns8250.log_level", hvm_ns8250_log_level);

How can this be a command line option, when there may be many domains
making use of the in-Xen driver? This and ...

> +/*
> + * Default emulated NS8250 resources.
> + * If not specified, COM1 (I/O port 0x3f8, IRQ#4) is emulated.
> + * FIXME: follow Linux'es console= syntax or re-use
> + * ns16550_parse_port_config().
> + */
> +static char __read_mostly hvm_ns8250_console[64];
> +string_param("hvm.ns8250.console", hvm_ns8250_console);

... this need to be per-domain settings; a command line option may be
applicable to Dom0 alone.

> +/* I/O access mask */
> +static const uint32_t io_access_mask[] = {
> +    [0] = 0X00000000U,
> +    [1] = 0X000000FFU,
> +    [2] = 0X0000FFFFU,
> +    [4] = 0XFFFFFFFFU,
> +};

I don't think this is needed; we're doing similar port I/O emulation in
various other places, without resorting to such arrays.

> +/*
> + * Legacy IBM PC NS8250 resources.
> + * There are only 4 I/O port ranges, hardcoding all of them here.
> + */
> +static const struct {
> +    const char *name;
> +    const struct resource *res;
> +} ns8250_x86_legacy_uarts[4] = {
> +    [0] = {
> +        .name = "com1",
> +        .res = (const struct resource[]){
> +            { .type = IORESOURCE_IO,  .addr = 0x3F8, .size = UART_MAX },

Considering this, ...

> +static int ns8250_io_write8(
> +    struct vuart_ns8250 *vdev, uint32_t reg, uint8_t *data)
> +{
> +    uint8_t val;
> +    int rc = 0;
> +
> +    val = *data;
> +
> +    switch ( reg )
> +    {
> +    /* DLAB=0 */
> +    case UART_THR:
> +        if ( vdev->regs[UART_MCR] & UART_MCR_LOOP )
> +        {
> +            ns8250_fifo_rx_putchar(vdev, val);
> +            vdev->regs[UART_LSR] |= UART_LSR_OE;
> +        }
> +        else
> +            ns8250_fifo_tx_putchar(vdev, val);
> +
> +        vdev->flags |= NS8250_IRQ_THRE_PENDING;
> +
> +        break;
> +
> +    case UART_IER:
> +        if ( val & vdev->regs[UART_IER] & UART_IER_ETHREI )
> +            vdev->flags |= NS8250_IRQ_THRE_PENDING;
> +
> +        vdev->regs[UART_IER] = val & UART_IER_MASK;
> +
> +        break;
> +
> +    case UART_FCR: /* WO */
> +        if ( val & UART_FCR_CLRX )
> +            ns8250_fifo_rx_reset(vdev);
> +
> +        if ( val & UART_FCR_CLTX )
> +            ns8250_fifo_tx_reset(vdev);
> +
> +        if ( !(val & UART_FCR_ENABLE) )
> +            val = 0;
> +
> +        vdev->regs[UART_FCR] = val & (UART_FCR_ENABLE |
> +                                      UART_FCR_DMA |
> +                                      UART_FCR_TRG_MASK);
> +
> +        break;
> +
> +    case UART_LCR:
> +        vdev->regs[UART_LCR] = val;
> +        break;
> +
> +    case UART_MCR: {
> +        uint8_t msr_curr, msr_next, msr_delta;
> +
> +        msr_curr = vdev->regs[UART_MSR];
> +        msr_next = 0;
> +        msr_delta = 0;
> +
> +        /* Set modem status */
> +        if ( val & UART_MCR_LOOP )
> +        {
> +            if ( val & UART_MCR_DTR )
> +                msr_next |= UART_MSR_DSR;
> +            if ( val & UART_MCR_RTS )
> +                msr_next |= UART_MSR_CTS;
> +            if ( val & UART_MCR_OUT1 )
> +                msr_next |= UART_MSR_RI;
> +            if ( val & UART_MCR_OUT2 )
> +                msr_next |= UART_MSR_DCD;
> +        }
> +        else
> +            msr_next |= UART_MSR_DCD | UART_MSR_DSR | UART_MSR_CTS;
> +
> +        /* Calculate changes in modem status */
> +        if ( (msr_curr & UART_MSR_CTS) ^ (msr_next & UART_MSR_CTS) )
> +            msr_delta |= UART_MSR_DCTS;
> +        if ( (msr_curr & UART_MCR_RTS) ^ (msr_next & UART_MCR_RTS) )
> +            msr_delta |= UART_MSR_DDSR;
> +        if ( (msr_curr & UART_MSR_RI)  & (msr_next & UART_MSR_RI) )
> +            msr_delta |= UART_MSR_TERI;
> +        if ( (msr_curr & UART_MSR_DCD) ^ (msr_next & UART_MSR_DCD) )
> +            msr_delta |= UART_MSR_DDCD;
> +
> +        vdev->regs[UART_MCR] = val & UART_MCR_MASK;
> +        vdev->regs[UART_MSR] = msr_next | msr_delta;
> +
> +        break;
> +    }
> +
> +    case UART_LSR: /* RO */
> +    case UART_MSR: /* RO */
> +        rc = -EINVAL;
> +        break;
> +
> +    /*
> +     * NB: Firmware like OVMF rely on SCR presence to initialize the ns8250
> +     * driver.
> +     */
> +    case UART_SCR:
> +        vdev->regs[UART_SCR] = val;
> +        break;
> +
> +    /* DLAB=1 */
> +    case UART_MAX + UART_DLL:

... how can you go at or past UART_MAX here and ...

> +        vdev->dl = (vdev->dl & 0xFF00U) | val;
> +        break;
> +
> +    case UART_MAX + UART_DLM:

... here? I notice a caller up the tree sets things up like this, but this
feels pretty fragile. How would one easily spot all producers and consumers
without also hitting all other uses of UART_MAX?

> +static int cf_check ns8250_io_handle(
> +    int dir, unsigned int addr, unsigned int size, uint32_t *data)
> +{
> +#define op(dir)     (((dir) == IOREQ_WRITE) ? 'W' : 'R')
> +    struct domain *d = rcu_lock_current_domain();
> +    struct vuart_ns8250 *vdev = &d->arch.hvm.vuart;
> +    uint32_t offset, reg;
> +    int rc;
> +
> +    spin_lock(&vdev->lock);
> +
> +    BUG_ON( vdev->owner != d );
> +
> +    if ( !(vdev->flags & NS8250_READY) )
> +    {
> +        pr_err("%c io 0x%04x %d 0x%08"PRIx32": propagate to external I/O emulator\n",
> +                op(dir), addr, size, *data);
> +        rc = X86EMUL_UNHANDLEABLE;
> +        goto out;
> +    }
> +
> +    reg = addr - vdev->io_addr;
> +    BUG_ON( reg >= UART_MAX );
> +    if ( reg % size != 0 )
> +    {
> +        pr_err("%c 0x%04x %d 0x%08"PRIx32": unaligned access\n",
> +                op(dir), addr, size, *data & io_access_mask[size]);
> +        rc = X86EMUL_OKAY;
> +        goto out;
> +    }
> +
> +    /* Redirect access to divisor latch registers */
> +    if ( !!(vdev->regs[UART_LCR] & UART_LCR_DLAB)
> +            && (reg == UART_DLL || reg == UART_DLM) )
> +        offset = UART_MAX + reg;
> +    else
> +        offset = reg;
> +
> +    if ( dir == IOREQ_WRITE )
> +    {
> +        pr_debug("%c 0x%04x %d 0x%08"PRIx32" %s[0x%02"PRIx32"]\n",
> +                op(dir), addr, size,
> +                *data & io_access_mask[size],
> +                ns8250_regname(vdev, offset, dir), reg);
> +        rc = ns8250_io_write(vdev, offset, size, data);
> +    }
> +    else
> +    {
> +        rc = ns8250_io_read(vdev, offset, size, data);
> +        pr_debug("%c 0x%04x %d 0x%08"PRIx32" %s[0x%02"PRIx32"]\n",
> +                op(dir), addr, size,
> +                *data & io_access_mask[size],
> +                ns8250_regname(vdev, offset, dir), reg);
> +    }
> +    if ( rc )
> +        pr_err("%c 0x%04x %d 0x%08"PRIx32": unsupported access\n",
> +                op(dir), addr, size, *data & io_access_mask[size]);
> +    rc = X86EMUL_OKAY;
> +
> +out:

Nit: Missing indentation (see ./CODING_STYLE). Also elsewhere.

> --- /dev/null
> +++ b/xen/arch/x86/include/asm/hvm/vuart_ns8250.h
> @@ -0,0 +1,75 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * NS8250-compatible UART Emulator.
> + */
> +#if !defined(HVM__VUART_NS8250_H)
> +#define HVM__VUART_NS8250_H
> +
> +#include 
> +#include 
> +#include  /* xencons_interface */

I assume you mean ...

> +/*
> + * NS8250 emulator operational flags.
> + */
> +enum {
> +    /* Emulator is ready */
> +    NS8250_READY                = BIT(0, U),
> +    /* Trigger re-delivery of THRE interrupt */
> +    NS8250_IRQ_THRE_PENDING     = BIT(1, U),
> +};
> +
> +/*
> + * Virtual NS8250 device state.
> + */
> +struct vuart_ns8250 {
> +    uint16_t dl;                    /* Divisor Latch */
> +    uint8_t regs[UART_MAX];         /* Registers */
> +    uint32_t flags;                 /* Virtual device flags */
> +    uint64_t io_addr;               /* Guest I/O region base address */
> +    uint64_t io_size;               /* Guest I/O region size */
> +    int irq;                        /* Guest IRQ# */
> +    struct xencons_interface *cons; /* Emulated RX/TX FIFOs */

... this use, but that doesn't even require a forward decl of the struct
in C (in C++ such a forward decl would be all that's needed).

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 15:09:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 15:09:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858260.1270506 (Exim 4.92)
	(envelope-from )
	id 1tNCiM-0007Ng-Qe; Mon, 16 Dec 2024 15:08:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858260.1270506; Mon, 16 Dec 2024 15:08: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 1tNCiM-0007NZ-O9; Mon, 16 Dec 2024 15:08:54 +0000
Received: by outflank-mailman (input) for mailman id 858260;
 Mon, 16 Dec 2024 15: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 1tNCiM-0007NT-9r
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 15:08:54 +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 a91ef824-bbbf-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 16:08:52 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-4361a50e337so29282375e9.0
 for ; Mon, 16 Dec 2024 07:08:52 -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-388c801ad9asm8300655f8f.58.2024.12.16.07.08.49
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 07:08: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: a91ef824-bbbf-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734361732; x=1734966532; 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=oqMLKF6H5hfqx3MHJ7JN/4O+uWS/OoCWqsxL5O+4iHw=;
        b=bqw0jJ4IjyBrXtZe9tg8iQvtkn9DjHPkVI4i1Ux4boRFLsTGk0rV/ZKwGDRhZlmlHQ
         OgqB9DqWCqPh0Qv+8AJuFhYKXWJ64mQfS6FrYvnCTZstlnNQ7D41aoDDk4P0hhYzvxIY
         OfURjT7Ldh6qgFLYU6ZNSv9Ksu33AN63fjTxdN0+99zf57G/wi9ZFLnBau68xdbJuLK8
         ck/LN758/FoPcj+bf3Cy3ZlJJy5sAJXoCt8DupPvrrCXFwQojsGnCSAi4DFofz0aGpp3
         RveEx2v3tAg67N7tKuDmYPHkNtvvWSu3axewBPjKDZ27yJ2U1PiBDD2w8kfrMb13b6Vp
         CAJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734361732; x=1734966532;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=oqMLKF6H5hfqx3MHJ7JN/4O+uWS/OoCWqsxL5O+4iHw=;
        b=UNqkbLjatBq2/TtxM3htYcq3TTckL9pHKqyUxbmTWfZNPNB3jdyvfaq6vv311Y5pan
         FW+wbyop91iwi0XsKsH3QjPAKwAhdqyXxo1W3xn9VQvEclwYcOBwsm2jLoCAIPkGvEgs
         y7wFvimhEXbnA+nMYKxJ8yXALNEF4JufuojuSODQap08Ltvjg1yotkYQh0fdNuqMOks5
         QwEZVgxnDoZMx82xvXMDxGVIfCZZl60oi1Sj0zurzpCTNyP0PakN4cJKcOZS65R7bQ9X
         k4vEYsU7wC38lMarBYpiSqBJv5mEPTNaRaJUExgyut1BtOep/atWRFLPYIt9b2Fwefj6
         JCFA==
X-Forwarded-Encrypted: i=1; AJvYcCVdhmbm2Eehwvw9HCcWoJgv8HpLnNEoZIFWtMfW/8ZJK4v7EVemF7AjC+cX1bzjOgp5a7r21XPqnvw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzCq2tzjEgG+qG4CmPdLgTJwS0rvN8VhXJrBqPpbVxrYjcXlo2i
	4BVtm4xvDZreVOA6IcM0E6lW+ojCodCHmWAuSGSiCzilci1z9J1VCbpz7Ji7pQ==
X-Gm-Gg: ASbGncvVo4la0hRZ7P/RJQ97Ihgom5SaTZw4KACqx7/XLCk0DbPCbBQMJ10Z4sEiijN
	Xgk7bYr9KRsC3kXGUxvgnesuAwWTc+0vtpJzZAyc2OcDVfe+pRxUroJtq9gYkA5l5id6Fx9Azw8
	IL34ymPI6ufGp2DDH3qTwUzpsNANyFB8Oz7w69dqm/vk1Us4aUV4t+I7I6vkiQB0GwRtVSgri8S
	uGrpPMPHlmjUpOCHZZnB99b7nDiGg1VRpG9HJ5a3NFBYf0AiKxKFiyFUFYFGm5XPdXt4ihuj7f0
	j3mmj4tMtcSl5XOBN0PUAhCwQm3q1x3wa8xPCj08DA==
X-Google-Smtp-Source: AGHT+IHahP/FOSc9ewyKNmQFjGhManZ9NK/p5YRzgZ4YgLWUoPDh8VvyuThq/fSOg1f3LIV04fHlvQ==
X-Received: by 2002:a05:600c:83c9:b0:434:f219:6b28 with SMTP id 5b1f17b1804b1-4362aaa9625mr99934555e9.24.1734361730368;
        Mon, 16 Dec 2024 07:08:50 -0800 (PST)
Message-ID: 
Date: Mon, 16 Dec 2024 16:08:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 32/35] x86/hvm: add debugging facility to NS8250 UART
 emulator
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-32-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-32-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:42, Denis Mukhin via B4 Relay wrote:
> +static void ns8250_keyhandler_init(void)
> +{
> +    register_keyhandler('1', ns8250_keyhandler_show,
> +                        "dump virtual NS8250 state", 0);
> +    register_keyhandler('2', ns8250_keyhandler_irq,
> +                        "trigger IRQ from virtual NS8250", 0);

Characters for key handlers are a pretty scarce resource. I'm afraid I
wouldn't want to see this committed, even if it may be helpful during
(initial) debugging. Even more so when both handlers only ever act on
a single domain. Imo both want to be domctl-s instead.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 15:11:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 15:11:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858267.1270517 (Exim 4.92)
	(envelope-from )
	id 1tNCkl-0000fi-7K; Mon, 16 Dec 2024 15:11:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858267.1270517; Mon, 16 Dec 2024 15:11: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 1tNCkl-0000fX-3U; Mon, 16 Dec 2024 15:11:23 +0000
Received: by outflank-mailman (input) for mailman id 858267;
 Mon, 16 Dec 2024 15:11: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 1tNCkk-0000fP-IG
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 15:11:22 +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 018a2bdc-bbc0-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 16:11:20 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-43622354a3eso29272345e9.1
 for ; Mon, 16 Dec 2024 07:11:20 -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-4361e33ffb1sm137663445e9.0.2024.12.16.07.11.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 07:11: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: 018a2bdc-bbc0-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734361880; x=1734966680; 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=i9CWzlJ9qZYcDH5GaUG+z8oZvJxLFdOdvvlTmb/5Knk=;
        b=Xy0GogeTHkVjHW7Y/hbWgzUEPGHhxYvFffB127/JCbrF7cqfkkePC2YAUYpzAalET1
         sAuzwrJgH+RCZ1gHfUERrU4fbrexVSqN1/cJ/QvWGZFXnt/4HXUwMflIzoQyzKc0kREw
         ZITqa1EY9x9mvac9uYlH0DP/B5XOPvuNetY4n8WSBgbs6xlL8lK/7SrTF0Db+kGqePlk
         AMnlfN7M6SvNlXLnwYaawHkCk30AN6xe286eEfdqqmt8LBwuJNBzfe5QNmdbn8BkSlP0
         2crea01HUprIGmOHsn8tM+SvlY5OWxugSxITHPkMvx9Iod1eYy5At9dgMBy1xA/N30sE
         pgOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734361880; x=1734966680;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=i9CWzlJ9qZYcDH5GaUG+z8oZvJxLFdOdvvlTmb/5Knk=;
        b=kj2JDygfa2l39pSs84L/Ejt+pDZbZP0vckhevINsLYtfCh0tEoToFQ8gTIKsARTjQ0
         f05nwSP17BJ9E4iqJmGuFqAH6NkmI/sgvhfnVGsWmYqGh2nLHNJUYT/CANCX23DBRgZp
         k1D6Ir60AhxCRI89zRC+fp6zWvkY5HfzktKMW/wSCHb7aS3OvqIOwZ6ZnASEHt/OJQs3
         pb8n8wilB6v4PUwAagrLWkjiKpAZh0iPq089Su4E4di3F7P7gVpRUICo9cNzfWZ9gLiw
         AepSa4XkFJARuJuQ2rlqtuqjlQ9NB7iD0iW87OdcgYX3MFm45YlHcpVNtkdZNb7o9Chf
         XoTg==
X-Forwarded-Encrypted: i=1; AJvYcCUE88OyGjsHJ3tZRpMs2J0BKo48KDIpJ204SmwITGHgdFxLjzaojptKT+ztTxwUIXyg8/0+pr+V7SE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwoKvk5UJq4gP8BnD35PffQuLxjwA/QOa7vPfYoCO7S/mYWrFhY
	qejExOwnXMLnULMhr/LE6Zysr6oznuoBikf1ZR8CJcJsH5l06OHydr3pe3KbbQ==
X-Gm-Gg: ASbGnctZ3wzSoPMD3BRaSVe/l84APnqmytmeEYwaWgwjpP1MFFta1SRFPVckLcOVN+A
	PweTtRuJBEVshJzAb5qtbFoyqehuSlXFMqiyMnK70C1sVPim+N+IDWgsH8PmrSIrlwXTSM6Es+2
	W1bLKsrjzENwPeDma0ZL6upkjjOjM6Zf4cDxGBuxinsdG+QbuvYm900AdYGOczHeKZxJHwipID7
	xFXa0K+D+gP9kYyzPTuRoe8gZbYhLDU/hwKykTDkfHH88ThqjffwI7+xHYKpcj2RMkIgA8tZukt
	EzOA5h8jHaIhWwf3XhuiJ6E1bOYvqfZqrdHZVV4Olg==
X-Google-Smtp-Source: AGHT+IGwBocIKtpzFzSh6D7wvrUBm4tjNNLeZp8UdG/ztYhbY4o277U48k1Pzg5W48Th0iLGNSQaIw==
X-Received: by 2002:a05:600c:3496:b0:434:a07d:b709 with SMTP id 5b1f17b1804b1-4362aab4896mr111154315e9.29.1734361880158;
        Mon, 16 Dec 2024 07:11:20 -0800 (PST)
Message-ID: 
Date: Mon, 16 Dec 2024 16:11:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 33/35] x86/domain: implement domain_has_vuart()
To: dmukhin@ford.com
Cc: Andrew Cooper , Julien Grall ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241205-vuart-ns8250-v1-0-e9aa923127eb@ford.com>
 <20241205-vuart-ns8250-v1-33-e9aa923127eb@ford.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: <20241205-vuart-ns8250-v1-33-e9aa923127eb@ford.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 06.12.2024 05:42, Denis Mukhin via B4 Relay wrote:
> --- a/tools/libs/light/libxl_x86.c
> +++ b/tools/libs/light/libxl_x86.c
> @@ -8,7 +8,11 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>  {
>      switch(d_config->c_info.type) {
>      case LIBXL_DOMAIN_TYPE_HVM:
> -        config->arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
> +        config->arch.emulation_flags = XEN_X86_EMU_ALL;
> +        config->arch.emulation_flags &= ~XEN_X86_EMU_VPCI;
> +        /* Virtual UART is selected at Xen build time */
> +        config->arch.emulation_flags &= ~XEN_X86_EMU_VUART;

That is all domains, even post-boot created ones, only ever get the same
setting?

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 15:16:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 15:16:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858283.1270527 (Exim 4.92)
	(envelope-from )
	id 1tNCpC-0001lq-Rl; Mon, 16 Dec 2024 15:15:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858283.1270527; Mon, 16 Dec 2024 15:15:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNCpC-0001lj-Ox; Mon, 16 Dec 2024 15:15:58 +0000
Received: by outflank-mailman (input) for mailman id 858283;
 Mon, 16 Dec 2024 15:15: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 1tNCpB-0001l8-VF
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 15:15:57 +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 a603873d-bbc0-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 16:15:56 +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 1348D1F381;
 Mon, 16 Dec 2024 15:15:56 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id EC35013418;
 Mon, 16 Dec 2024 15:15:55 +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 tecBOCtEYGdlEgAAD6G6ig
 (envelope-from ); Mon, 16 Dec 2024 15:15: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: a603873d-bbc0-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734362156; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=C3LzBX8cw815wTpsH0sLm/iyjNL8GriAUh4sQOgqve4=;
	b=mXkKPw781sZTbzdnHh59lDgouoIvqYYDppGCI5N5opaUzhh3D7OZ+SbsrxCdDsOYG0mEAQ
	u415VAFqE7iJ5xUEG0yFtBpLx6kYFWmFzc9BVsEuFx9sCQ3p+WV44Ppfi6fSm6hp0bMDzZ
	SJqY69CZLPSi05yBxOFdqd5MKI5Ofss=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=mXkKPw78
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734362156; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
	bh=C3LzBX8cw815wTpsH0sLm/iyjNL8GriAUh4sQOgqve4=;
	b=mXkKPw781sZTbzdnHh59lDgouoIvqYYDppGCI5N5opaUzhh3D7OZ+SbsrxCdDsOYG0mEAQ
	u415VAFqE7iJ5xUEG0yFtBpLx6kYFWmFzc9BVsEuFx9sCQ3p+WV44Ppfi6fSm6hp0bMDzZ
	SJqY69CZLPSi05yBxOFdqd5MKI5Ofss=
Message-ID: <8a59d299-2477-48c4-80bf-d9bb32fd6441@suse.com>
Date: Mon, 16 Dec 2024 16:15:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 6/7] tools/libs: add a new libxenmanage library
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org
References: <20241213162421.16782-1-jgross@suse.com>
 <20241213162421.16782-7-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: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------w86dglXg6Amw348OgoaBHmKa"
X-Rspamd-Queue-Id: 1348D1F381
X-Spam-Score: -5.41
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-5.41 / 50.00];
	BAYES_HAM(-3.00)[99.99%];
	SIGNED_PGP(-2.00)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MIME_BASE64_TEXT(0.10)[];
	MX_GOOD(-0.01)[];
	ARC_NA(0.00)[];
	TO_DN_SOME(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	RCPT_COUNT_TWO(0.00)[2];
	RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	FROM_HAS_DN(0.00)[];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	DKIM_TRACE(0.00)[suse.com:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.com:mid,suse.com:dkim]
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spam-Level: 

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------w86dglXg6Amw348OgoaBHmKa
Content-Type: multipart/mixed; boundary="------------JUWyO6I7tFnalotG9JPMTvcI";
 protected-headers="v1"
From: Juergen Gross 
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org
Message-ID: <8a59d299-2477-48c4-80bf-d9bb32fd6441@suse.com>
Subject: Re: [PATCH v3 6/7] tools/libs: add a new libxenmanage library
References: <20241213162421.16782-1-jgross@suse.com>
 <20241213162421.16782-7-jgross@suse.com> 
In-Reply-To: 

--------------JUWyO6I7tFnalotG9JPMTvcI
Content-Type: multipart/mixed; boundary="------------nS0FOLkxccY3GbYa5xGnwZer"

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

T24gMTYuMTIuMjQgMTU6NDksIEFudGhvbnkgUEVSQVJEIHdyb3RlOg0KPiBPbiBGcmksIERl
YyAxMywgMjAyNCBhdCAwNToyNDoyMFBNICswMTAwLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0K
Pj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2luY2x1ZGUveGVubWFuYWdlLmggYi90b29scy9pbmNs
dWRlL3hlbm1hbmFnZS5oDQo+PiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0KPj4gaW5kZXggMDAw
MDAwMDAwMC4uNWQxNjk2OTNiMA0KPj4gLS0tIC9kZXYvbnVsbA0KPj4gKysrIGIvdG9vbHMv
aW5jbHVkZS94ZW5tYW5hZ2UuaA0KPj4gQEAgLTAsMCArMSw5MiBAQA0KPj4gKy8qIFNQRFgt
TGljZW5zZS1JZGVudGlmaWVyOiBMR1BMLTIuMSAqLw0KPiANCj4gVGhpcyBzaG91bGQgcmVh
ZCAiTEdQTC0yLjEtb25seSIuDQoNCk9rYXkuDQoNCj4gDQo+PiBkaWZmIC0tZ2l0IGEvdG9v
bHMvbGlicy9tYW5hZ2UvY29yZS5jIGIvdG9vbHMvbGlicy9tYW5hZ2UvY29yZS5jDQo+PiBu
ZXcgZmlsZSBtb2RlIDEwMDY0NA0KPj4gaW5kZXggMDAwMDAwMDAwMC4uYjVmYTY3YjAzNg0K
Pj4gLS0tIC9kZXYvbnVsbA0KPj4gKysrIGIvdG9vbHMvbGlicy9tYW5hZ2UvY29yZS5jDQo+
PiBAQCAtMCwwICsxLDE2OCBAQA0KPiANCj4+ICtzdGF0aWMgaW50IHhlbm1hbmFnZV9kb19k
b21jdGxfZ2V0X2RvbWFpbl9zdGF0ZSh4ZW5tYW5hZ2VfaGFuZGxlICpoZGwsDQo+PiArICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQg
aW50IGRvbWlkX2luLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHVuc2lnbmVkIGludCAqZG9taWRfb3V0LA0KPj4gKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGludCAqc3Rh
dGUsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgdWludDY0X3QgKnVuaXF1ZV9pZCkNCj4+ICt7DQo+PiArICAgIHN0cnVjdCB4ZW5fZG9t
Y3RsICpidWY7DQo+PiArICAgIGludCBzYXZlZF9lcnJubzsNCj4+ICsgICAgaW50IHJldDsN
Cj4+ICsNCj4+ICsgICAgYnVmID0geGVuY2FsbF9hbGxvY19idWZmZXIoaGRsLT54Y2FsbCwg
c2l6ZW9mKCpidWYpKTsNCj4+ICsgICAgaWYgKCAhYnVmICkNCj4+ICsgICAgew0KPj4gKyAg
ICAgICAgZXJybm8gPSBFTk9NRU07DQo+IA0KPiBJcyB0aGlzIG5lY2Vzc2FyeT8gSXNuJ3Qg
eGVuY2FsbF9hbGxvY19idWZmZXIoKSBnb2luZyB0byBzZXQgYGVycm5vYD8gT3INCj4gaXMg
aXQgdG8gb3ZlcndyaXRlIGBlcnJub2Agc2V0IGJ5IHN5c3RlbSBjYWxscyB3aGljaCBjb3Vs
ZCBiZSBvdGhlciB0aGFuDQo+IEVOT01FTT8NCg0KVGhlcmUgYXJlIG1hbnkgZGlmZmVyZW50
IGVycm5vIHZhbHVlcyB0aGlua2FibGUuIEkgd2FudCB0byBtYWtlIHN1cmUNCnRvIGhhdmUg
YSB2YWx1ZSBtYWtpbmcgY2xlYXIgdGhhdCB0aGUgYWxsb2NhdGlvbiBmYWlsZWQgZm9yIHNv
bWUgcmVhc29uLg0KDQo+IA0KPj4gKyAgICAgICAgcmV0dXJuIC0xOw0KPj4gKyAgICB9DQo+
IA0KPiBPdGhlcndpc2UsIHBhdGNoIGxvb2tzIGZpbmUgdG8gbWU6IFJldmlld2VkLWJ5OiBB
bnRob255IFBFUkFSRCA8YW50aG9ueS5wZXJhcmRAdmF0ZXMudGVjaD4NCg0KVGhhbmtzLA0K
DQoNCkp1ZXJnZW4NCg==
--------------nS0FOLkxccY3GbYa5xGnwZer
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-----

--------------nS0FOLkxccY3GbYa5xGnwZer--

--------------JUWyO6I7tFnalotG9JPMTvcI--

--------------w86dglXg6Amw348OgoaBHmKa
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/Ey8FAmdgRCsFAwAAAAAACgkQsN6d1ii/Ey/R
NAf/ewXB6LeR+sDdNIhJhyO2QKdei7F0/SqHaeQOAkQm/5lSRWWKmfU94wSOfYmPUj11CPxe8MkN
qggcJz8nSTGE2nZqMDGW/EvIF7HMIZHcQFVMiy21N2I9BadhbmRhYPT/2Inm48WRZTEYANbKu94R
kfrVHH/7F0y+hoOvR1Gj/sQTqhJieA/vBgRyFMcd33EKyLIOqSCndkrJi3zpxfF+6RnGVJbYhJZZ
aIns0kdhQi+Sn7jU41Ye1DMODWE8oLLCTYAdKf/J6N5/9XN+D2pHOrzvHOj2EXmbV8bYYIzeT+Vj
cRgMaFqdjdWDYjVOAlO5npzngWoTIrrNToLxRgqkGw==
=SobE
-----END PGP SIGNATURE-----

--------------w86dglXg6Amw348OgoaBHmKa--


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 15:17:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 15:17:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858291.1270536 (Exim 4.92)
	(envelope-from )
	id 1tNCqV-0002IS-5K; Mon, 16 Dec 2024 15:17:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858291.1270536; Mon, 16 Dec 2024 15:17:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNCqV-0002IL-2b; Mon, 16 Dec 2024 15:17:19 +0000
Received: by outflank-mailman (input) for mailman id 858291;
 Mon, 16 Dec 2024 15:17: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 1tNCqT-0002IF-7b
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 15:17:17 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d4eb097c-bbc0-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 16:17:15 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 16 Dec 2024 16:17:15 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d4eb097c-bbc0-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734362236; x=1765898236;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=vjwrwN1TSV0GR+T4z0725EGrHDxuHqB8DXkEpEdQfLU=;
  b=QNAh8UDhcg7w2X24E2fGMFIzPSW+JRoCiPJ6ahCryKBDdJ7wTKjRsKyA
   o/dq+caZu1X8phR5zwllMg7XSekr/1bfvBZu07sLTH//pbb/C8WEGxCyF
   uaev/U7TeQ8PgvkN2Bds/YVNDVQxkKNYGMqpOpVNL+48ZZD1dcs9fTWwF
   U=;
X-CSE-ConnectionGUID: LmttF90qTg+ntKxtF+lw+g==
X-CSE-MsgGUID: Pym3MY4DSkemchtvzdOiyw==
X-IronPort-AV: E=Sophos;i="6.12,238,1728943200"; 
   d="scan'208";a="28199345"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: <7f30f105-e13e-4e41-b432-82f9c12760d9@suse.com>
Content-Type: text/plain; charset="utf-8"
X-Forward: 149.5.228.1
References: <20241215154659.151158-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241215154659.151158-2-Ariel.Otilibili-Anieli@eurecom.fr>
 <5599dc89-0fa4-4255-b4a1-5b81e151d8c7@suse.com>
 <2f7a85-67600280-e411-38ee5c40@258420856>
 
 <2f7a86-67600f80-8b81-26131fc0@216081513>
 <3f3e9a77-5695-4c91-9fc2-11a3c21605c5@suse.com>
 <2f7a86-67601b00-8b99-26131fc0@216117285> <7f30f105-e13e-4e41-b432-82f9c12760d9@suse.com>
Date: Mon, 16 Dec 2024 16:17:15 +0100
Cc: xen-devel@lists.xenproject.org, "Anthony PERARD" 
To: "Jan Beulich" 
MIME-Version: 1.0
Message-ID: <2f7a84-67604480-4bc5-4ac1e700@168713693>
Subject: =?utf-8?q?Re=3A?= [PATCH 1/1] =?utf-8?q?tools/libacpi=3A?= clear ASL 
 warning about PCI0
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 4851

On Monday, December 16, 2024 13:39 CET, Jan Beulich =
 wrote:

> On 16.12.2024 13:19, Ariel Otilibili-Anieli wrote:
> > On Monday, December 16, 2024 12:38 CET, Jan Beulich  wrote:
> >=20
> >> On 16.12.2024 12:31, Ariel Otilibili-Anieli wrote:
> >>> On Monday, December 16, 2024 12:01 CET, Jan Beulich  wrote:
> >>>
> >>>> On 16.12.2024 11:36, Ariel Otilibili-Anieli wrote:
> >>>>> On Monday, December 16, 2024 10:53 CET, Jan Beulich  wrote:
> >>>>>
> >>>>>> On 15.12.2024 16:40, Ariel Otilibili wrote:
> >>>>>>> * iasl complains =5FHID and =5FADR cannot be used at the same=
 time
> >>>>>>>
> >>>>>>> ```
> >>>>>>> /usr/bin/iasl -vs -p tools/firmware/hvmloader/dsdt=5Fanycpu.t=
mp -tc tools/firmware/hvmloader/dsdt=5Fanycpu.asl 2>&1 | grep -B10 HID
> >>>>>>> tools/firmware/hvmloader/dsdt=5Fanycpu.asl     40:        Dev=
ice (PCI0)
> >>>>>>> Warning  3073 -                                    Multiple t=
ypes ^  (Device object requires either a =5FHID or =5FADR, but not both=
)
> >>>>>>> ```
> >>>>>>>
> >>>>>>> * generally =5FHID devices are enumerated and have their driv=
ers loaded by ACPI
> >>>>>>> * this is from "ASL 2.0 Introduction and Overview" (page 4).
> >>>>>>> * removing =5FADR, the warning is cleared out.
> >>>>>>
> >>>>>> Okay, that's the positive aspect. Yet what about the potential=
 fallout thereof?
> >>>>>> Can you confirm that there's no risk of regressions with older=
 guest OSes, for
> >>>>>> example?
> >>>>>
> >>>>> OSes that were released after ACPI 2.0 should work [1]; includi=
ng WinXP:=20
> >>>>> The 2.0 specs says either =5FHID or =5FADR should be included [=
2], not both (Section 6.1, page 146).
> >>>>
> >>>> We must be looking at two different variants of the spec then. M=
y copy says
> >>>> "device object must contain either an =5FHID object or an =5FADR=
 object, but can
> >>>> contain both." Also still in 2.0c. I agree that in e.g. 6.5 the =
wording has
> >>>> changed. I also agree that the use of "either" doesn't help clar=
ity.
> >>>
> >>> I looked up 2.0 (July 2000); indeed, it said "can contain both". =
My bad.
> >>>>
> >>>>> I chose WinXP because, on another patch, it came up in the disc=
ussion [3].
> >>>
> >>> The change should work down to WinXP: the name =5FHID is kept.
> >>>
> >>> ```
> >>> $ git grep -B2 -A2 -n PNP0A03
> >>> tools/libacpi/dsdt.asl-40-       Device (PCI0)
> >>> tools/libacpi/dsdt.asl-41-       {
> >>> tools/libacpi/dsdt.asl:42:           Name (=5FHID, EisaId ("PNP0A=
03"))
> >>> tools/libacpi/dsdt.asl-43-           Name (=5FUID, 0x00)
> >>> tools/libacpi/dsdt.asl-44-           Name (=5FADR, 0x00)
> >>> ```
> >>>
> >>> Its EISA ID is "PNP0A03"; the namespace is reserved for Microsoft=
. Microsoft identifies "PNP0A03" as PCI devices [1].
> >>
> >> You again say "should" without explaining what you derive this fro=
m. Is it
> >> written down somewhere that no OS we (remotely) care about ever ev=
aluated
> >> =5FADR when =5FHID was there? As before, along side mentioning the=
 benefits of
> >> the change, I'd like to also see a discussion of risks.
> >>
> >=20
> > I derive this knowledge only from the APCI specs. Indeed, I've not =
researched how every OS interprets =5FHID and =5FADR.
> >=20
> > From your answer, I see you would like to be sure the change will i=
ntroduce no regression. I do understand you point of view; keeping the =
backward compatibility.=20
> >=20
> > The benefit is that the warning will be cleared. We agree on that.
> >=20
> > The risk is that, if ever any OS relies on =5FADR, and cannot read =
=5FHID; it would break.
> >=20
> > After thinking about it, the other way is less risky: this =5FHID n=
ame is only recognized by Windows. Every OS should (I did say it again,=
 should) understand =5FADR.
> >=20
> > If you think the change makes sense, I can remove =5FHID instead of=
 =5FADR.
>=20
> But that would remove relevant information, the the PNP ID serves a p=
urpose.

You are right, I dumped the DSDT tables of my Linux, and the PCI object=
 does use it:

```
# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat=20
# iasl -e dsdt.dat -d dsdt.dsl
# grep PNP0A03 -B3 dsdt.dsl=20
        Device (PC00)
        {
            Name (=5FHID, EisaId ("PNP0A08") /* PCI Express Bus */)  //=
 =5FHID: Hardware ID
            Name (=5FCID, EisaId ("PNP0A03") /* PCI Bus */)  // =5FCID:=
 Compatible ID
```
>=20
> > Otherwise, I think we should end the discussion.
>=20
> Well, you may decide to withdraw / abandon the patch, or you may deci=
de to
> re-submit with an extended description, clarifying why the removal is
> expected to be safe. Even if - obviously - you can't inspect e.g. Win=
dows
> sources.

Thanks for the feedback, Jan; I am pushing another patch series. Docume=
nting all the findings.

I'll keep you posted,
Ariel
>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 15:18:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 15:18:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858299.1270547 (Exim 4.92)
	(envelope-from )
	id 1tNCrN-0002o2-Ds; Mon, 16 Dec 2024 15:18:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858299.1270547; Mon, 16 Dec 2024 15:18: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 1tNCrN-0002nv-B7; Mon, 16 Dec 2024 15:18:13 +0000
Received: by outflank-mailman (input) for mailman id 858299;
 Mon, 16 Dec 2024 15:18: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 1tNCrL-0002IF-TN
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 15:18:11 +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 f64428fe-bbc0-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 16:18:11 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4361f664af5so46583195e9.1
 for ; Mon, 16 Dec 2024 07:18: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
 5b1f17b1804b1-43625706c77sm141985545e9.34.2024.12.16.07.18.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 07:18: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: f64428fe-bbc0-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734362291; x=1734967091; 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=B4eBm+afKNIm9Ap0aIPPLtGyRI0QxsKpBcatLyVpIsI=;
        b=PR2Gv/fzpXl7KN58ihUjcfn3GE/PJziT8MfriCPRP/hTRIS66OMJYQHz1hAmBn6Kh9
         1H82sqZty90RsjPfEfPDvawdLd6RkaLpFRCyXezoxDnmp2OHgHQk+dhftPBYjdOxIs90
         MFxUDudvwYILIL5o9hJINoBf6FILkbSNRB8OQfD6hnx5vUOlIFaK2LIV+XHWzdCq0KJE
         5CpV85RYXOcS6ivRFvGasmfUsK7CucSjM1dRoDucfUXZfWclrnH3E12r4YZMtZUqRVBV
         NJ0C1GB8zbw9wrD3BdaSg6B9EazE/hLbR9QAVFIn/GjZQO1SAkTDBYp1yLt8OJARrZJ2
         5SaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734362291; x=1734967091;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=B4eBm+afKNIm9Ap0aIPPLtGyRI0QxsKpBcatLyVpIsI=;
        b=fTJlUWYga63W70y0yl1gJEhfYqVg3mKUct12FXlais94TktgTEQiy5DkbNKRRBpbZI
         KSapojQdZipC3zJq8f62y0XbLyH/rJLLCTPcLwyb8dQZLFLnF6o4hxeTrJdRNI41CswS
         alKlx9DsQ/laIAdopXDjBaucu5m0dL5cCof2wJfdsjRzKJ637TzT30eQcH/M/UYmvKw+
         wSlyIcNTxAbNPSgjSIkEjp+tFRsLBF9wkMUzwh2oDnxx/h/aInund72sakpOw7nZqzsm
         EwWg+PayVVbBZoqAMC8jmr4u/FYNuHk4MPnDY4Ym+zhCHyYLHD0Akp9C0XgUsf19zAxL
         Ld1Q==
X-Forwarded-Encrypted: i=1; AJvYcCWgXY41ElUyasdWNZRV6l7LZ460ec+7IPNUuRM5wtosxpR7bJFomLd2ZkfJc/d9QrsJiK8iRJlxhiU=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz5Mhh7T3vhAoM8DsAQr+PcOZmsdngonBaPWA40gwPVT/IR6qkC
	WF6s+nR04ym7GEro45Wf3O+gQQ+odooC1xepb/Ex52Fkv1AMOgEGi2Bqsg8IiA==
X-Gm-Gg: ASbGncu8FpvRUKXEZVXsihSUzhgl0+W8QVkk569oRPOuwkqJF8POO6UA6yw2uH33je2
	I9jeCPE1SnbNZsbmXMvJyM0y7t4yGuzvXAIpqq5Mm2ygNlUmRBcqSXQwgFxVXuM2EbqjNzv3Vxp
	8+7f9mviQ8wkqE9CWJUARNUdwiPtc1++OYfXFzlacXg2OcneF5Q3PRJ9GHDzZeOpwGwPzBBdvUg
	n7K4SfCoe12i/5QO7Xfnd/cZ8GWX1vAfJbW70QsAAYLZ3mw7i3nPQWluRAdRKT3SKKq1T1rHZeR
	OHi6tPhcFaH+91qZHJrMM0B3gX2njXpZ9YQQhaOtww==
X-Google-Smtp-Source: AGHT+IHFhOpf/POdPv6LZefHmstcbfninow334Gt3B8+Cre8SEpxkverSxld0YeA/75tz3ptFQ3eMA==
X-Received: by 2002:a05:600c:a014:b0:436:1971:2a4 with SMTP id 5b1f17b1804b1-4362aa3d7e5mr117152375e9.17.1734362290738;
        Mon, 16 Dec 2024 07:18:10 -0800 (PST)
Message-ID: 
Date: Mon, 16 Dec 2024 16:18:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 5/7] xen: add new domctl get_changed_domain
To: Juergen Gross 
Cc: "Daniel P. Smith" ,
 Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241213162421.16782-1-jgross@suse.com>
 <20241213162421.16782-6-jgross@suse.com>
 
 <7061e31b-2d61-40fd-b2e9-528c4faf41f9@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: <7061e31b-2d61-40fd-b2e9-528c4faf41f9@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.12.2024 16:03, Juergen Gross wrote:
> On 16.12.24 11:41, Jan Beulich wrote:
>> On 13.12.2024 17:24, Juergen Gross wrote:
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -193,6 +193,57 @@ static void domain_changed_state(const struct domain *d)
>>>       spin_unlock(&dom_state_changed_lock);
>>>   }
>>>   
>>> +static void set_domain_state_info(struct xen_domctl_get_domain_state *info,
>>> +                                  const struct domain *d)
>>> +{
>>> +    info->state = XEN_DOMCTL_GETDOMSTATE_STATE_EXIST;
>>> +    if ( d->is_shut_down )
>>> +        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN;
>>> +    if ( d->is_dying == DOMDYING_dying )
>>> +        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DYING;
>>> +    if ( d->is_dying == DOMDYING_dead )
>>> +        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DEAD;
>>> +    info->unique_id = d->unique_id;
>>> +}
>>> +
>>> +int get_domain_state(struct xen_domctl_get_domain_state *info, struct domain *d,
>>> +                     domid_t *domid)
>>> +{
>>> +    unsigned int dom;
>>> +
>>> +    if ( info->pad0 || info->pad1 )
>>> +        return -EINVAL;
>>> +
>>> +    if ( d )
>>> +    {
>>> +        set_domain_state_info(info, d);
>>> +
>>> +        return 0;
>>> +    }
>>> +
>>> +    while ( (dom = find_first_bit(dom_state_changed, DOMID_MASK + 1)) <
>>> +            DOMID_FIRST_RESERVED )
>>> +    {
>>> +        if ( test_and_clear_bit(dom, dom_state_changed) )
>>
>> For these two accesses to dom_state_changed don't you need to hold the
>> lock patch 4 introduces? Also didn't you say you'd constrain the new
>> sub-op to the sole domain having VIRQ_DOM_EXEC bound (which, ftaod,
>> isn't enough to eliminate the race)?
> 
> Just to be more specific regarding the race: I guess you mean that a domain
> having registered for the VIRQ doesn't mean the calling component being in
> that domain really is the one associated with the VIRQ.
> 
> While being true, even today it is possible for one dom0 user process to
> "steal" a VIRQ from another process by using dirty tricks via the privcmd
> driver.
> 
> In the end a process having the access rights to use the privcmd driver must
> be trusted to not disturb other processes with the same rights.

Of course, but that's not exactly what I was getting at. I was trying to
point out that the vIRQ check alone is still insufficient to avoid potential
crashes here, by one vCPU calling here while another unbinds the vIRQ. Taking
the lock is required for Xen's safety; checking the vIRQ is bound is an extra
policy enforcement.

Jan


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 15:20:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 15:20:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858314.1270556 (Exim 4.92)
	(envelope-from )
	id 1tNCtr-0004UN-T2; Mon, 16 Dec 2024 15:20:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858314.1270556; Mon, 16 Dec 2024 15:20:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNCtr-0004UG-QU; Mon, 16 Dec 2024 15:20:47 +0000
Received: by outflank-mailman (input) for mailman id 858314;
 Mon, 16 Dec 2024 15:20: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 1tNCtr-0004UA-7G
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 15:20:47 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 52a6fb27-bbc1-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 16:20:46 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5d3ecae02beso5523900a12.0
 for ; Mon, 16 Dec 2024 07:20:46 -0800 (PST)
Received: from ?IPV6:2003:e5:8725:5e00:fa69:c5cb:46d:3e5b?
 (p200300e587255e00fa69c5cb046d3e5b.dip0.t-ipconnect.de.
 [2003:e5:8725:5e00:fa69:c5cb:46d:3e5b])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab96359b94sm345492666b.106.2024.12.16.07.20.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 07:20: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: 52a6fb27-bbc1-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734362446; x=1734967246; 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=CvD0uv/RptUvQVZMuSMRfyuoTAQPIMuShTyPw62aLT0=;
        b=R8/QsLBJOEZlus3Eji9j0ENmQ88hI6PDSx9kdzBLqXfxRoTfTsT77HYH9sVpTiCncx
         s3Xc2lKvymAki+QK5uqyIaTGjEeVuhMEzjYRYDoSmXOv7iqh3n4t6KRnnAi5CFnmznJy
         9v18CmER9+N82xESoEGoz5+mVGmmJuyr7DZKQIdWtwQkcEwRWhSFHXhESQabjHlraX5/
         cJRj0dxGbGu+1+PzBoLXpn8VRItMLmp4pag8jRKEeHpwnA+xig9WDzYjcHc6PDjBvyGS
         8GZu47uxLX7HK/f+D6d67ZXZT43wiwuuy4Orh+xX+DZ1o5BBi7py9JYfQFeQqQBzx5oa
         xxXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734362446; x=1734967246;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=CvD0uv/RptUvQVZMuSMRfyuoTAQPIMuShTyPw62aLT0=;
        b=Vr88/RaaOOl9gCIpeueosuNHVrbSq4Ve97yAKcPpo3Kz1O+POgCiZDCt4USRFWge5n
         Kl+EFy72plm7IhmBs58d9y9mgt25rGqsxNv6jSKKYmiNy0T9hgLRm3hyq7+tg2aa+cWW
         xzodZ9RdpMrySJJs2XRf0nztA6DTlM+/lpBgLB1lBURRANyvQG23u982j20vXt/eFF/2
         dAfOkb8oGsb//utZp+HaJ2+BlRpSQ4yvJ8DxnQ+WvyazerXf5qVbCooAJLdGuJE+PpfF
         yfMn8A1ynllbxIbJe/B7gKuGareOrQAgO/08PBuCLQBrVvTr2OaluLBbRjokKhINKa0Y
         Vw+A==
X-Forwarded-Encrypted: i=1; AJvYcCW3E6UtzaZWYB+dzUdITYFVfIZX9YKsxVwmbAxW99DZ5QQpcvFkapPqSO7yET9IgikxwMTLs5KD77o=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyTzA0YcB/GJqsVbWD5BV2rsp/xQ+WK51kJH9puoV9oqWMKo4C4
	k79fhI1+yCqVRlJ8dJBsgf8pLtedbnSOBm4OMZgx8SmZN1BSJhpsnBGEVbxHvjA=
X-Gm-Gg: ASbGncs27/6VBzY0IaFNbsfOeRYmUeK/JGz+E03XzHUtI0BkNhyFLGzHFcxSiJANW14
	lfbWW63ftKDVh9QuCHlnXAwJ7zVl9OuUyl/tYkyTzfm2oVCxXCiYtRWkWcErejfqz8vQs6avjBn
	D5cQuUK/fUvT4SpiUY0ITV7MSoYcq/VFsyuvWv9WcG1B7MkbXMY6jooMi1YYm/Z9y9fBNdKz/3e
	wY8bYMlJfMfvN8QhYt/TR2ijS2+rXy4S7do+xAiUzedvY+a0pAQNF0EVX34TTeLtd/mt2/wzdXS
	xqbBRAIk4wpNFj9rGFu7CoBSFDWl0OCD1duWVnuMJnu7aPUYa1vs0gOsr74vhGgLvDMrvxtM66p
	9ajM=
X-Google-Smtp-Source: AGHT+IHrbiM7WTW5EWpbfrrNgj5d+SHO/jLZdxcJGBENWqc9LOaqVGdha5Wym+/UBDGBDfZMdj96Yg==
X-Received: by 2002:a17:906:f585:b0:aa6:5201:7ae3 with SMTP id a640c23a62f3a-aab77ea5c47mr1441072366b.40.1734362445642;
        Mon, 16 Dec 2024 07:20:45 -0800 (PST)
Message-ID: <3974c88f-ba87-4b09-bdc4-5bb77b06139b@suse.com>
Date: Mon, 16 Dec 2024 16:20:44 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 5/7] xen: add new domctl get_changed_domain
To: Jan Beulich 
Cc: "Daniel P. Smith" ,
 Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241213162421.16782-1-jgross@suse.com>
 <20241213162421.16782-6-jgross@suse.com>
 
 <7061e31b-2d61-40fd-b2e9-528c4faf41f9@suse.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: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------HxXmnoYRQDEK5Lg1aMq0WJvZ"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------HxXmnoYRQDEK5Lg1aMq0WJvZ
Content-Type: multipart/mixed; boundary="------------AYlcXS5r7fAZ1iMeVxifbgh2";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jan Beulich 
Cc: "Daniel P. Smith" ,
 Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
Message-ID: <3974c88f-ba87-4b09-bdc4-5bb77b06139b@suse.com>
Subject: Re: [PATCH v3 5/7] xen: add new domctl get_changed_domain
References: <20241213162421.16782-1-jgross@suse.com>
 <20241213162421.16782-6-jgross@suse.com>
 
 <7061e31b-2d61-40fd-b2e9-528c4faf41f9@suse.com>
 
In-Reply-To: 
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------AYlcXS5r7fAZ1iMeVxifbgh2
Content-Type: multipart/mixed; boundary="------------0sjivpxVRBWyl62DlMCvLb0V"

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

T24gMTYuMTIuMjQgMTY6MTgsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxNi4xMi4yMDI0
IDE2OjAzLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gT24gMTYuMTIuMjQgMTE6NDEsIEph
biBCZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDEzLjEyLjIwMjQgMTc6MjQsIEp1ZXJnZW4gR3Jv
c3Mgd3JvdGU6DQo+Pj4+IC0tLSBhL3hlbi9jb21tb24vZG9tYWluLmMNCj4+Pj4gKysrIGIv
eGVuL2NvbW1vbi9kb21haW4uYw0KPj4+PiBAQCAtMTkzLDYgKzE5Myw1NyBAQCBzdGF0aWMg
dm9pZCBkb21haW5fY2hhbmdlZF9zdGF0ZShjb25zdCBzdHJ1Y3QgZG9tYWluICpkKQ0KPj4+
PiAgICAgICAgc3Bpbl91bmxvY2soJmRvbV9zdGF0ZV9jaGFuZ2VkX2xvY2spOw0KPj4+PiAg
ICB9DQo+Pj4+ICAgIA0KPj4+PiArc3RhdGljIHZvaWQgc2V0X2RvbWFpbl9zdGF0ZV9pbmZv
KHN0cnVjdCB4ZW5fZG9tY3RsX2dldF9kb21haW5fc3RhdGUgKmluZm8sDQo+Pj4+ICsgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3Qgc3RydWN0IGRvbWFpbiAqZCkN
Cj4+Pj4gK3sNCj4+Pj4gKyAgICBpbmZvLT5zdGF0ZSA9IFhFTl9ET01DVExfR0VURE9NU1RB
VEVfU1RBVEVfRVhJU1Q7DQo+Pj4+ICsgICAgaWYgKCBkLT5pc19zaHV0X2Rvd24gKQ0KPj4+
PiArICAgICAgICBpbmZvLT5zdGF0ZSB8PSBYRU5fRE9NQ1RMX0dFVERPTVNUQVRFX1NUQVRF
X1NIVVRET1dOOw0KPj4+PiArICAgIGlmICggZC0+aXNfZHlpbmcgPT0gRE9NRFlJTkdfZHlp
bmcgKQ0KPj4+PiArICAgICAgICBpbmZvLT5zdGF0ZSB8PSBYRU5fRE9NQ1RMX0dFVERPTVNU
QVRFX1NUQVRFX0RZSU5HOw0KPj4+PiArICAgIGlmICggZC0+aXNfZHlpbmcgPT0gRE9NRFlJ
TkdfZGVhZCApDQo+Pj4+ICsgICAgICAgIGluZm8tPnN0YXRlIHw9IFhFTl9ET01DVExfR0VU
RE9NU1RBVEVfU1RBVEVfREVBRDsNCj4+Pj4gKyAgICBpbmZvLT51bmlxdWVfaWQgPSBkLT51
bmlxdWVfaWQ7DQo+Pj4+ICt9DQo+Pj4+ICsNCj4+Pj4gK2ludCBnZXRfZG9tYWluX3N0YXRl
KHN0cnVjdCB4ZW5fZG9tY3RsX2dldF9kb21haW5fc3RhdGUgKmluZm8sIHN0cnVjdCBkb21h
aW4gKmQsDQo+Pj4+ICsgICAgICAgICAgICAgICAgICAgICBkb21pZF90ICpkb21pZCkNCj4+
Pj4gK3sNCj4+Pj4gKyAgICB1bnNpZ25lZCBpbnQgZG9tOw0KPj4+PiArDQo+Pj4+ICsgICAg
aWYgKCBpbmZvLT5wYWQwIHx8IGluZm8tPnBhZDEgKQ0KPj4+PiArICAgICAgICByZXR1cm4g
LUVJTlZBTDsNCj4+Pj4gKw0KPj4+PiArICAgIGlmICggZCApDQo+Pj4+ICsgICAgew0KPj4+
PiArICAgICAgICBzZXRfZG9tYWluX3N0YXRlX2luZm8oaW5mbywgZCk7DQo+Pj4+ICsNCj4+
Pj4gKyAgICAgICAgcmV0dXJuIDA7DQo+Pj4+ICsgICAgfQ0KPj4+PiArDQo+Pj4+ICsgICAg
d2hpbGUgKCAoZG9tID0gZmluZF9maXJzdF9iaXQoZG9tX3N0YXRlX2NoYW5nZWQsIERPTUlE
X01BU0sgKyAxKSkgPA0KPj4+PiArICAgICAgICAgICAgRE9NSURfRklSU1RfUkVTRVJWRUQg
KQ0KPj4+PiArICAgIHsNCj4+Pj4gKyAgICAgICAgaWYgKCB0ZXN0X2FuZF9jbGVhcl9iaXQo
ZG9tLCBkb21fc3RhdGVfY2hhbmdlZCkgKQ0KPj4+DQo+Pj4gRm9yIHRoZXNlIHR3byBhY2Nl
c3NlcyB0byBkb21fc3RhdGVfY2hhbmdlZCBkb24ndCB5b3UgbmVlZCB0byBob2xkIHRoZQ0K
Pj4+IGxvY2sgcGF0Y2ggNCBpbnRyb2R1Y2VzPyBBbHNvIGRpZG4ndCB5b3Ugc2F5IHlvdSdk
IGNvbnN0cmFpbiB0aGUgbmV3DQo+Pj4gc3ViLW9wIHRvIHRoZSBzb2xlIGRvbWFpbiBoYXZp
bmcgVklSUV9ET01fRVhFQyBib3VuZCAod2hpY2gsIGZ0YW9kLA0KPj4+IGlzbid0IGVub3Vn
aCB0byBlbGltaW5hdGUgdGhlIHJhY2UpPw0KPj4NCj4+IEp1c3QgdG8gYmUgbW9yZSBzcGVj
aWZpYyByZWdhcmRpbmcgdGhlIHJhY2U6IEkgZ3Vlc3MgeW91IG1lYW4gdGhhdCBhIGRvbWFp
bg0KPj4gaGF2aW5nIHJlZ2lzdGVyZWQgZm9yIHRoZSBWSVJRIGRvZXNuJ3QgbWVhbiB0aGUg
Y2FsbGluZyBjb21wb25lbnQgYmVpbmcgaW4NCj4+IHRoYXQgZG9tYWluIHJlYWxseSBpcyB0
aGUgb25lIGFzc29jaWF0ZWQgd2l0aCB0aGUgVklSUS4NCj4+DQo+PiBXaGlsZSBiZWluZyB0
cnVlLCBldmVuIHRvZGF5IGl0IGlzIHBvc3NpYmxlIGZvciBvbmUgZG9tMCB1c2VyIHByb2Nl
c3MgdG8NCj4+ICJzdGVhbCIgYSBWSVJRIGZyb20gYW5vdGhlciBwcm9jZXNzIGJ5IHVzaW5n
IGRpcnR5IHRyaWNrcyB2aWEgdGhlIHByaXZjbWQNCj4+IGRyaXZlci4NCj4+DQo+PiBJbiB0
aGUgZW5kIGEgcHJvY2VzcyBoYXZpbmcgdGhlIGFjY2VzcyByaWdodHMgdG8gdXNlIHRoZSBw
cml2Y21kIGRyaXZlciBtdXN0DQo+PiBiZSB0cnVzdGVkIHRvIG5vdCBkaXN0dXJiIG90aGVy
IHByb2Nlc3NlcyB3aXRoIHRoZSBzYW1lIHJpZ2h0cy4NCj4gDQo+IE9mIGNvdXJzZSwgYnV0
IHRoYXQncyBub3QgZXhhY3RseSB3aGF0IEkgd2FzIGdldHRpbmcgYXQuIEkgd2FzIHRyeWlu
ZyB0bw0KPiBwb2ludCBvdXQgdGhhdCB0aGUgdklSUSBjaGVjayBhbG9uZSBpcyBzdGlsbCBp
bnN1ZmZpY2llbnQgdG8gYXZvaWQgcG90ZW50aWFsDQo+IGNyYXNoZXMgaGVyZSwgYnkgb25l
IHZDUFUgY2FsbGluZyBoZXJlIHdoaWxlIGFub3RoZXIgdW5iaW5kcyB0aGUgdklSUS4gVGFr
aW5nDQo+IHRoZSBsb2NrIGlzIHJlcXVpcmVkIGZvciBYZW4ncyBzYWZldHk7IGNoZWNraW5n
IHRoZSB2SVJRIGlzIGJvdW5kIGlzIGFuIGV4dHJhDQo+IHBvbGljeSBlbmZvcmNlbWVudC4N
Cg0KQWgsIG9rYXkuIEkgdGhpbmsgVjQgd2lsbCBjb3ZlciB5b3VyIHNjZW5hcmlvLg0KDQoN
Ckp1ZXJnZW4NCg==
--------------0sjivpxVRBWyl62DlMCvLb0V
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-----

--------------0sjivpxVRBWyl62DlMCvLb0V--

--------------AYlcXS5r7fAZ1iMeVxifbgh2--

--------------HxXmnoYRQDEK5Lg1aMq0WJvZ
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/Ey8FAmdgRUwFAwAAAAAACgkQsN6d1ii/Ey/t
Rgf/Zp1xT0MnwiLLEbBBCHtTX5wIRhFwU9k8T5G0u4lp0EZ99btuSPmP8+5t42nKwmp1nyuBzH5g
Yv55D8NC2wrfkshYv7suxig4IIEOA2Sj+5vDidqZ1xoFYPytopV8RKoHuqxYpFPFLlITGApYeGk4
DyeSAPIKFOp1TGDzVEsPx/tn6k6kpFYCY2WF4zj+1gc36tV1txkqGEy83X6lBnjEgQxpWS4IHeon
9HX5W8Xp0IG0AMzuJbaiPC9Ro0V/r9vVmqHIKsKUugLenZy82eRPkixcujqa6P4W2fjKM6Dw608d
2+V5tNpMIggoh5bRdM9Clov3E9dmhOqPsRWWbKvH5w==
=AKJw
-----END PGP SIGNATURE-----

--------------HxXmnoYRQDEK5Lg1aMq0WJvZ--


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 15:51:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 15:51:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858337.1270572 (Exim 4.92)
	(envelope-from )
	id 1tNDNg-000213-CK; Mon, 16 Dec 2024 15:51:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858337.1270572; Mon, 16 Dec 2024 15:51: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 1tNDNg-00020w-9A; Mon, 16 Dec 2024 15:51:36 +0000
Received: by outflank-mailman (input) for mailman id 858337;
 Mon, 16 Dec 2024 15:51: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 1tNDNf-0001zq-5D
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 15:51:35 +0000
Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com
 [2607:f8b0:4864:20::12e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9ec085fc-bbc5-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 16:51:32 +0100 (CET)
Received: by mail-il1-x12e.google.com with SMTP id
 e9e14a558f8ab-3a761a622dcso33692585ab.0
 for ; Mon, 16 Dec 2024 07:51: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: 9ec085fc-bbc5-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734364291; x=1734969091; 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=J2W90Vrf3TRBuSnhmRzMXdqApGTAPFHO/d7jXo8Fzms=;
        b=ZWLkv9V4/VDI8cqFg749oC+YKkSgbzAf1yx3ludWlZPfkSlB18f+ezbFGnWnlxedOi
         XM1c26bBK+H3jfBNbE6xhYxcZkrltkl4s6ZCQ1ZHDhCYHQxQZysa8+8Jf+TG4Mj7HZhF
         e/++a0DUHWREXewkGjIgIkPH8sBPmFDxUxW2+e5X24RKYSIi/iIXM8d59sBsvLh7oz0Y
         B6Q6tBUE5haBexrWHOTb897aIGIJV/f7Xzj1fh1lXZKKUMRwGT20us3wspnV1Rh9aFST
         RFXPl7T88vIQTWL1vxY2Lv/gQB689Q65onNmIebvlKpEHvMfejsd4Znwz9TZCFHtXTnZ
         Hywg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734364291; x=1734969091;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=J2W90Vrf3TRBuSnhmRzMXdqApGTAPFHO/d7jXo8Fzms=;
        b=SBhdf5jPEhsrMJvk/CPLVKUADpJTFB3EYfUFoszatVIomHhGnKe4x/GE8K/NpyvKrH
         V74i1YSyGj88XphvEHpi1obdY91usD5Qd7b0XDndbHt0ulazHu/CAs4nwvmLNleKLYh0
         aQtJXsDxXhot6Z7tl+zPFBdn/IPql/P3RimwaNi7utj61PP9WOxgWdPdX1wFOLB8Fwo6
         yQs8TW3kKSVO6HsOqRO88bBK39uV7ZIGKP0L3tuRrdsJmZ9T+k/TSp4UsnNtW+ftojHO
         +7R+PqCWGGgBjvUf4qXsyaH09BTpVBy6mHIEco/5k2qooUA3WVCeEecaLEwaEvSqyGbm
         G5Ig==
X-Gm-Message-State: AOJu0YzjdLVSnHngKzZcN0F+gYvG7wUpdXfzJE+RSpTcphHJQtebZmNN
	agXWbry+bCANFEPEOM/vs2dau7VCPRH5mSUewi/Gjrt+Zt4wBdTQ8DB4rpt8Ony3nCMSmQzwAP9
	rqaqUTz9/nBQDbgDXWAwpRWqNtijX5JI/ncreXw==
X-Gm-Gg: ASbGncuJsY7bBAW8FX4+AXfGY9EITwTL55qj6LfwcACUCt7rkRkliNix+SVBygKFXVz
	+0Ir+Z9rxjaQW6W34RIirvXvvOPXFKrPd/LNKo4I=
X-Google-Smtp-Source: AGHT+IF/4SaBnpvxVIMuSpfjYbb3OksmYIHm2L9KrwNcYnJsn/2iUx/n7K6vwmpnHTYTLiWw4Y0BQ7rydcytziip/Fw=
X-Received: by 2002:a05:6e02:12c4:b0:3a7:e528:6f1e with SMTP id
 e9e14a558f8ab-3aff6218adamr118489435ab.11.1734364291284; Mon, 16 Dec 2024
 07:51:31 -0800 (PST)
MIME-Version: 1.0
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-4-carlo.nonato@minervasys.tech> 
In-Reply-To: 
From: Carlo Nonato 
Date: Mon, 16 Dec 2024 16:51:20 +0100
Message-ID: 
Subject: Re: [PATCH v12 03/12] xen/arm: permit non direct-mapped Dom0 construction
To: Michal Orzel 
Cc: xen-devel@lists.xenproject.org, andrea.bastoni@minervasys.tech, 
	marco.solieri@minervasys.tech, Stefano Stabellini , 
	Julien Grall , Bertrand Marquis , 
	Volodymyr Babchuk 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Michal,

On Mon, Dec 16, 2024 at 1:08=E2=80=AFPM Michal Orzel =
 wrote:
>
> On 13/12/2024 17:28, Carlo Nonato wrote:
> >
> > Cache coloring requires Dom0 not to be direct-mapped because of its non
> > contiguous mapping nature, so allocate_memory() is needed in this case.
> > 8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a separate mo=
dule")
> > moved allocate_memory() in dom0less_build.c. In order to use it
> > in Dom0 construction bring it back to domain_build.c and declare it in
> > domain_build.h.
> >
> > Adapt the implementation of allocate_memory() so that it uses the host
> > layout when called on the hwdom, via find_unallocated_memory(). Take th=
e
> > opportunity to keep the parameter order consistent with
> > rangeset_report_ranges() and move the membanks struct after the callbac=
k
> > function in find_unallocated_memory().
> Why? What benefit does this change (that is irrelevant to the goal of thi=
s patch) provide?

You're right, it's irrelevant to this patch. Do you think it can be done in=
 a
separate patch? If nothing else, find_unallocated_memory() appears to be
called 2 times while rangeset_report_ranges() 11 times.

> > Introduce add_hwdom_free_regions() callback to add hwdom banks in desce=
nding
> > order.
> >
> > Signed-off-by: Carlo Nonato 
> > ---
> > v12:
> > - used the new generic find_unallocated_memory()
> > - added add_hwdom_free_regions() callback
> > v11:
> > - GUEST_RAM_BANKS instead of hardcoding the number of banks in allocate=
_memory()
> > - hwdom_ext_regions -> hwdom_free_mem in allocate_memory()
> > - added a comment in allocate_memory() when skipping small banks
> > v10:
> > - fixed a compilation bug that happened when dom0less support was disab=
led
> > v9:
> > - no changes
> > v8:
> > - patch adapted to new changes to allocate_memory()
> > v7:
> > - allocate_memory() now uses the host layout when called on the hwdom
> > v6:
> > - new patch
> > ---
> >  xen/arch/arm/dom0less-build.c           |  44 -------
> >  xen/arch/arm/domain_build.c             | 164 +++++++++++++++++++++++-
> >  xen/arch/arm/include/asm/domain_build.h |   4 +
> >  3 files changed, 161 insertions(+), 51 deletions(-)
> >
> > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-buil=
d.c
> > index d93a85434e..67b1503647 100644
> > --- a/xen/arch/arm/dom0less-build.c
> > +++ b/xen/arch/arm/dom0less-build.c
> > @@ -49,50 +49,6 @@ bool __init is_dom0less_mode(void)
> >      return ( !dom0found && domUfound );
> >  }
> >
> > -static void __init allocate_memory(struct domain *d, struct kernel_inf=
o *kinfo)
> > -{
> > -    struct membanks *mem =3D kernel_info_get_mem(kinfo);
> > -    unsigned int i;
> > -    paddr_t bank_size;
> > -
> > -    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n=
",
> > -           /* Don't want format this as PRIpaddr (16 digit hex) */
> > -           (unsigned long)(kinfo->unassigned_mem >> 20), d);
> > -
> > -    mem->nr_banks =3D 0;
> > -    bank_size =3D MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem);
> > -    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM0_BASE),
> > -                               bank_size) )
> > -        goto fail;
> > -
> > -    bank_size =3D MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem);
> > -    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM1_BASE),
> > -                               bank_size) )
> > -        goto fail;
> > -
> > -    if ( kinfo->unassigned_mem )
> > -        goto fail;
> > -
> > -    for( i =3D 0; i < mem->nr_banks; i++ )
> > -    {
> > -        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%l=
dMB)\n",
> > -               d,
> > -               i,
> > -               mem->bank[i].start,
> > -               mem->bank[i].start + mem->bank[i].size,
> > -               /* Don't want format this as PRIpaddr (16 digit hex) */
> > -               (unsigned long)(mem->bank[i].size >> 20));
> > -    }
> > -
> > -    return;
> > -
> > -fail:
> > -    panic("Failed to allocate requested domain memory."
> > -          /* Don't want format this as PRIpaddr (16 digit hex) */
> > -          " %ldKB unallocated. Fix the VMs configurations.\n",
> > -          (unsigned long)kinfo->unassigned_mem >> 10);
> > -}
> > -
> >  #ifdef CONFIG_VGICV2
> >  static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
> >  {
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index adf26f2778..bfcff99194 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2,6 +2,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -416,7 +417,6 @@ static void __init allocate_memory_11(struct domain=
 *d,
> >      }
> >  }
> >
> > -#ifdef CONFIG_DOM0LESS_BOOT
> >  bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size=
,
> >                                      alloc_domheap_mem_cb cb, void *ext=
ra)
> >  {
> > @@ -508,7 +508,6 @@ bool __init allocate_bank_memory(struct kernel_info=
 *kinfo, gfn_t sgfn,
> >
> >      return true;
> >  }
> > -#endif
> >
> >  /*
> >   * When PCI passthrough is available we want to keep the
> > @@ -900,6 +899,52 @@ int __init add_ext_regions(unsigned long s_gfn, un=
signed long e_gfn,
> >      return 0;
> >  }
> >
> > +static int __init add_hwdom_free_regions(unsigned long s_gfn,
> > +                                         unsigned long e_gfn, void *da=
ta)
> > +{
> > +    struct membanks *free_regions =3D data;
> > +    paddr_t start, size;
> > +    paddr_t s =3D pfn_to_paddr(s_gfn);
> > +    paddr_t e =3D pfn_to_paddr(e_gfn);
> > +    unsigned int i, j;
> > +
> > +    if ( free_regions->nr_banks >=3D free_regions->max_banks )
> > +        return 0;
> > +
> > +    /*
> > +     * Both start and size of the free region should be 2MB aligned to
> > +     * potentially allow superpage mapping.
> > +     */
> > +    start =3D (s + SZ_2M - 1) & ~(SZ_2M - 1);
> > +    if ( start > e )
> > +        return 0;
> > +
> > +    /*
> > +     * e is actually "end-1" because it is called by rangeset function=
s
> > +     * which are inclusive of the last address.
> > +     */
> > +    e +=3D 1;
> > +    size =3D (e - start) & ~(SZ_2M - 1);
> > +
> > +    /* Find the insert position (descending order). */
> > +    for ( i =3D 0; i < free_regions->nr_banks ; i++)
> CODING_STYLE:
> for ( i =3D 0; i < free_regions->nr_banks; i++ )
>
> > +        if ( size > free_regions->bank[i].size )
> > +            break;
> > +
> > +    /* Move the other banks to make space. */
> > +    for ( j =3D free_regions->nr_banks; j > i ; j-- )
> > +    {
> > +        free_regions->bank[j].start =3D free_regions->bank[j - 1].star=
t;
> > +        free_regions->bank[j].size =3D free_regions->bank[j - 1].size;
> > +    }
> > +
> > +    free_regions->bank[i].start =3D start;
> > +    free_regions->bank[i].size =3D size;
> > +    free_regions->nr_banks++;
> The algorithm looks good. In my head I thought you will use sort() after =
adding all the banks, but
> I'm not sure which solution is more efficient. Probably yours and it avoi=
ds implementing cmp and swap functions.
>
> > +
> > +    return 0;
> > +}
> > +
> >  /*
> >   * Find unused regions of Host address space which can be exposed to d=
omain
> >   * using the host memory layout. In order to calculate regions we excl=
ude every
> > @@ -908,10 +953,10 @@ int __init add_ext_regions(unsigned long s_gfn, u=
nsigned long e_gfn,
> >  static int __init find_unallocated_memory(const struct kernel_info *ki=
nfo,
> >                                            const struct membanks *mem_b=
anks[],
> >                                            unsigned int nr_mem_banks,
> > -                                          struct membanks *free_region=
s,
> >                                            int (*cb)(unsigned long s_gf=
n,
> >                                                      unsigned long e_gf=
n,
> > -                                                    void *data))
> > +                                                    void *data),
> > +                                          struct membanks *free_region=
s)
> >  {
> >      const struct membanks *mem =3D bootinfo_get_mem();
> >      struct rangeset *unalloc_mem;
> > @@ -977,6 +1022,108 @@ out:
> >      return res;
> >  }
> >
> > +void __init allocate_memory(struct domain *d, struct kernel_info *kinf=
o)
> > +{
> > +    struct membanks *mem =3D kernel_info_get_mem(kinfo);
> > +    unsigned int i, nr_banks =3D GUEST_RAM_BANKS;
> > +    struct membanks *hwdom_free_mem =3D NULL;
> > +
> > +    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n=
",
> > +           /* Don't want format this as PRIpaddr (16 digit hex) */
> > +           (unsigned long)(kinfo->unassigned_mem >> 20), d);
> > +
> > +    mem->nr_banks =3D 0;
> > +    /*
> > +     * Use host memory layout for hwdom. Only case for this is when LL=
C coloring
> > +     * is enabled.
> > +     */
> > +    if ( is_hardware_domain(d) )
> > +    {
> > +        struct membanks *gnttab =3D xzalloc_flex_struct(struct membank=
s, bank, 1);
> > +        /*
> > +         * Exclude the following regions:
> > +         * 1) Remove reserved memory
> > +         * 2) Grant table assigned to Dom0
> Can we not mention 'Dom0'? In the future hwdom may not necessarily be dom=
0. Especially that
> in other places you mention hwdom.
>
> > +         */
> > +        const struct membanks *mem_banks[] =3D {
> > +            bootinfo_get_reserved_mem(),
> > +            gnttab,
> > +        };
> > +
> > +        ASSERT(llc_coloring_enabled);
> Remove this assert. There's nothing LLC special here and this could be re=
-used in the future
> to provide non 1:1 hwdom.
>
> > +
> > +        if ( !gnttab )
> > +            goto fail;
> > +
> > +        gnttab->nr_banks =3D 1;
> > +        gnttab->bank[0].start =3D kinfo->gnttab_start;
> > +        gnttab->bank[0].size =3D kinfo->gnttab_start + kinfo->gnttab_s=
ize;
> Incorrect. You assign to 'end' to'size'. It should simply be:
> gnttab->bank[0].size =3D kinfo->gnttab_size.
>
> > +
> > +        hwdom_free_mem =3D xzalloc_flex_struct(struct membanks, bank,
> > +                                             NR_MEM_BANKS);
> > +        if ( !hwdom_free_mem )
> > +            goto fail;
> > +
> > +        hwdom_free_mem->max_banks =3D NR_MEM_BANKS;
> > +
> > +        if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_=
banks),
> > +                                     add_hwdom_free_regions, hwdom_fre=
e_mem) )
> > +            goto fail;
> > +
> > +        nr_banks =3D hwdom_free_mem->nr_banks;
> > +        xfree(gnttab);
> > +    }
> > +
> > +    for ( i =3D 0; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_=
banks-- )
> > +    {
> > +        paddr_t bank_start, bank_size;
> > +
> > +        if ( is_hardware_domain(d) )
> > +        {
> > +            bank_start =3D hwdom_free_mem->bank[i].start;
> > +            bank_size =3D hwdom_free_mem->bank[i].size;
> > +        }
> > +        else
> > +        {
> > +            const uint64_t bankbase[] =3D GUEST_RAM_BANK_BASES;
> > +            const uint64_t banksize[] =3D GUEST_RAM_BANK_SIZES;
> > +
> > +            if ( i >=3D GUEST_RAM_BANKS )
> > +                goto fail;
> > +
> > +            bank_start =3D bankbase[i];
> > +            bank_size =3D banksize[i];
> > +        }
> > +
> > +        bank_size =3D MIN(bank_size, kinfo->unassigned_mem);
> > +        if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(bank_start), ba=
nk_size) )
> > +            goto fail;
> > +    }
> > +
> > +    if ( kinfo->unassigned_mem )
> > +        goto fail;
> > +
> > +    for( i =3D 0; i < mem->nr_banks; i++ )
> > +    {
> > +        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%l=
dMB)\n",
> > +               d,
> > +               i,
> > +               mem->bank[i].start,
> > +               mem->bank[i].start + mem->bank[i].size,
> > +               /* Don't want format this as PRIpaddr (16 digit hex) */
> > +               (unsigned long)(mem->bank[i].size >> 20));
> > +    }
> > +
> > +    xfree(hwdom_free_mem);
> > +    return;
> > +
> > +fail:
> > +    panic("Failed to allocate requested domain memory."
> > +          /* Don't want format this as PRIpaddr (16 digit hex) */
> > +          " %ldKB unallocated. Fix the VMs configurations.\n",
> > +          (unsigned long)kinfo->unassigned_mem >> 10);
> > +}
> > +
> >  static int __init handle_pci_range(const struct dt_device_node *dev,
> >                                     uint64_t addr, uint64_t len, void *=
data)
> >  {
> > @@ -1176,7 +1323,7 @@ static int __init find_host_extended_regions(cons=
t struct kernel_info *kinfo,
> >      gnttab->bank[0].size =3D kinfo->gnttab_size;
> >
> >      res =3D find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_b=
anks),
> > -                                  ext_regions, add_ext_regions);
> > +                                  add_ext_regions, ext_regions);
> >      xfree(gnttab);
> >
> >      return res;
> > @@ -1235,7 +1382,7 @@ int __init make_hypervisor_node(struct domain *d,
> >
> >          ext_regions->max_banks =3D NR_MEM_BANKS;
> >
> > -        if ( is_domain_direct_mapped(d) )
> > +        if ( domain_use_host_layout(d) )
> >          {
> >              if ( !is_iommu_enabled(d) )
> >                  res =3D find_host_extended_regions(kinfo, ext_regions)=
;
> > @@ -2164,8 +2311,11 @@ static int __init construct_dom0(struct domain *=
d)
> >      /* type must be set before allocate_memory */
> >      d->arch.type =3D kinfo.type;
> >  #endif
> > -    allocate_memory_11(d, &kinfo);
> >      find_gnttab_region(d, &kinfo);
> This re-ordering should be mentioned in commit msg.
>
> > +    if ( is_domain_direct_mapped(d) )
> > +        allocate_memory_11(d, &kinfo);
> > +    else
> > +        allocate_memory(d, &kinfo);
> >
> >      rc =3D process_shm_chosen(d, &kinfo);
> >      if ( rc < 0 )
> > diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/inc=
lude/asm/domain_build.h
> > index e712afbc7f..b0d646e173 100644
> > --- a/xen/arch/arm/include/asm/domain_build.h
> > +++ b/xen/arch/arm/include/asm/domain_build.h
> > @@ -11,6 +11,7 @@ bool allocate_domheap_memory(struct domain *d, paddr_=
t tot_size,
> >                               alloc_domheap_mem_cb cb, void *extra);
> >  bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
> >                            paddr_t tot_size);
> > +void allocate_memory(struct domain *d, struct kernel_info *kinfo);
> >  int construct_domain(struct domain *d, struct kernel_info *kinfo);
> >  int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
> >  int make_chosen_node(const struct kernel_info *kinfo);
> > @@ -54,6 +55,9 @@ static inline int prepare_acpi(struct domain *d, stru=
ct kernel_info *kinfo)
> >  int prepare_acpi(struct domain *d, struct kernel_info *kinfo);
> >  #endif
> >
> > +typedef int (*add_free_regions_fn)(unsigned long s_gfn, unsigned long =
e_gfn,
> > +                                   void *data);
> Random code? Remove.
>
> With the remarks addressed:
> Reviewed-by: Michal Orzel 
>
> ~Michal

Thanks.

- Carlo


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 16:01:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 16:01:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858352.1270581 (Exim 4.92)
	(envelope-from )
	id 1tNDXG-0004QD-CJ; Mon, 16 Dec 2024 16:01:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858352.1270581; Mon, 16 Dec 2024 16:01:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNDXG-0004Q6-9f; Mon, 16 Dec 2024 16:01:30 +0000
Received: by outflank-mailman (input) for mailman id 858352;
 Mon, 16 Dec 2024 16: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 1tNDXE-0004OV-UW
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 16:01:28 +0000
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com
 [2a00:1450:4864:20::52f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 01ee2447-bbc7-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 17:01:27 +0100 (CET)
Received: by mail-ed1-x52f.google.com with SMTP id
 4fb4d7f45d1cf-5d3d2a30afcso7448834a12.3
 for ; Mon, 16 Dec 2024 08:01:28 -0800 (PST)
Received: from localhost ([85.152.134.39]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d652f25c8bsm3441229a12.66.2024.12.16.08.01.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 08:01: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: 01ee2447-bbc7-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1734364887; x=1734969687; darn=lists.xenproject.org;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6B3ybaM8PtQQdNLowhjYwJpjTluXmPdaIuEDjx5QwP8=;
        b=LxC4tYPqKlcg0c7mKhkgyq2PWrnjaTsCY6m2P1Fs+pe4IAq8iEu07edHY/bShzXfJ4
         IaemccKGmOFdDvfLwjg0ZKsGWOhW4G5DkeKS074ThOvBrSb3nRjPBxZkHiLe57UwBoe0
         vJ3juLXO4ZbCJv3MlructHRyh2Hi/+Ykzyjpg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734364887; x=1734969687;
        h=in-reply-to:references:to:from:subject:cc:message-id:date
         :content-transfer-encoding:mime-version:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=6B3ybaM8PtQQdNLowhjYwJpjTluXmPdaIuEDjx5QwP8=;
        b=S2wQv4kDGFBEPXuEAtvya4B2yrpqAok0PpHqRqBD4736JddWI8gjPJoOuKmzyA9iyq
         u0pkZHZYQAZgh+lsv9EGsrmx2fbvRSo/FmSRJtEb5lJ3Li1rXUnxDYTOHv6Pi6Ce2mVZ
         UZ9x2b5PDCvU4eCcGGAePJImPUh82RRbQs2Ka1vF7ERlcBXVu9uRyNuvypgS967ZTBcB
         SVet+9WrnQzIYu0lbOoJprnMpquski1F8QoXGUOFjRia4lo5BPWvqDCsrqcZA6I0C87d
         uZGoNCvI6SWHFETT+dS+DrYpFJ3ByiCnvhofeyroHLxhUlDHW1rmT2WSVMLrJL1TqKy4
         ed7g==
X-Forwarded-Encrypted: i=1; AJvYcCWTsWKXIF66u+QVpwAlBEyix65ZR4wBYZo9EoUtmpIU3tBYT/gi0+o72mSQpmaN8z/V92G1s/nGiBo=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy+V30JwbXoXMC5LNm6nzOstbJ8uS7WvBG38BtWQjBYii/AnPAq
	tScG+nZ+rTvEYuzUuLfh/gb5ltMyJhhqYHWFTRRYxi5erjNsSkC6Gxn4n7jjGyM=
X-Gm-Gg: ASbGncsHr3utNWhFgC9KPivHrF2+k+nI9yu3xx9B9++YPQCY7Nvq8fzh441pgdfzwjb
	+PkSaXvnkHmmiYgWTSBSQETlmrQCJSXhlkg9qUAGT0U/IazbsY9gmr/6I69N4NEn/lU9T140FGA
	wr5Xvqgz9C/hDDe8cVpPzbK90uRV92DpggjmpzpTeXUs8IBJcwz0QA/xXezj2EIt8L8vLstaKQ9
	IylAU64LUYyD9qjgwcz9voUNSYoIOm5EfMdIZSmdA0R1RnMhbVR+ipO3WI6PGU=
X-Google-Smtp-Source: AGHT+IHtTZ8Sh7K7tBJDqoURioC4EckaGMN17svBeMu2iXG1rFWp6ZGZensMIZkZYPCV4glsTTzekw==
X-Received: by 2002:a17:906:3157:b0:aa6:aa8e:c89c with SMTP id a640c23a62f3a-aabdb88744amr14922566b.39.1734364886965;
        Mon, 16 Dec 2024 08:01:26 -0800 (PST)
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Mon, 16 Dec 2024 16:01:23 +0000
Message-Id: 
Cc: , , , "Hongyan
 Xia" , "Julien Grall" 
Subject: Re: [PATCH V4 01/15] x86: Create per-domain mapping for
 guest_root_pt
From: "Alejandro Vallejo" 
To: "Elias El Yandouzi" ,
 
X-Mailer: aerc 0.18.2
References: <20241111131148.52568-1-eliasely@amazon.com>
 <20241111131148.52568-2-eliasely@amazon.com>
In-Reply-To: <20241111131148.52568-2-eliasely@amazon.com>

On Mon Nov 11, 2024 at 1:11 PM GMT, Elias El Yandouzi wrote:
> From: Hongyan Xia 
>
> This patch introduces a per-domain mapping for the `guest_root_pt` in PV
> guests as part of the effort to remove the direct map in Xen.
>
> For the time being, the `root_pgt` is not mapped or unmapped, as it remai=
ns
> a Xenheap page. This will be addressed in subsequent patches.
>
> Signed-off-by: Hongyan Xia 
> Signed-off-by: Julien Grall 
> Signed-off-by: Elias El Yandouzi 
>
> ----
>     Changes in V4:
>         * Fix over-allocation issue
>         * Update the mappings when switching from kernel to user-mode
>
>     Changes in V3:
>         * Rename SHADOW_ROOT
>         * Haven't addressed the potentially over-allocation issue as I do=
n't get it
>
>     Changes in V2:
>         * Rework the shadow perdomain mapping solution in the follow-up p=
atches
>
>     Changes since Hongyan's version:
>         * Remove the final dot in the commit title
>
> diff --git a/xen/arch/x86/include/asm/config.h b/xen/arch/x86/include/asm=
/config.h
> index f8a5a4913b07..bd360ec4141e 100644
> --- a/xen/arch/x86/include/asm/config.h
> +++ b/xen/arch/x86/include/asm/config.h
> @@ -174,7 +174,7 @@
>  /* Slot 260: per-domain mappings (including map cache). */
>  #define PERDOMAIN_VIRT_START    (PML4_ADDR(260))
>  #define PERDOMAIN_SLOT_MBYTES   (PML4_ENTRY_BYTES >> (20 + PAGETABLE_ORD=
ER))
> -#define PERDOMAIN_SLOTS         3
> +#define PERDOMAIN_SLOTS         4
>  #define PERDOMAIN_VIRT_SLOT(s)  (PERDOMAIN_VIRT_START + (s) * \
>                                   (PERDOMAIN_SLOT_MBYTES << 20))
>  /* Slot 4: mirror of per-domain mappings (for compat xlat area accesses)=
. */
> @@ -288,6 +288,14 @@ extern unsigned long xen_phys_start;
>  #define ARG_XLAT_START(v)        \
>      (ARG_XLAT_VIRT_START + ((v)->vcpu_id << ARG_XLAT_VA_SHIFT))
> =20
> +/* pv_root_pt mapping area. The fourth per-domain-mapping sub-area */
> +#define PV_ROOT_PT_MAPPING_VIRT_START   PERDOMAIN_VIRT_SLOT(3)
> +#define PV_ROOT_PT_MAPPING_ENTRIES      MAX_VIRT_CPUS
> +
> +/* The address of a particular VCPU's PV_ROOT_PT */
> +#define PV_ROOT_PT_MAPPING_VCPU_VIRT_START(v) \
> +    (PV_ROOT_PT_MAPPING_VIRT_START + ((v)->vcpu_id * PAGE_SIZE))
> +
>  #define ELFSIZE 64
> =20
>  #define ARCH_CRASH_SAVE_VMCOREINFO
> diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm=
/domain.h
> index b79d6badd71c..478ce41ad8ca 100644
> --- a/xen/arch/x86/include/asm/domain.h
> +++ b/xen/arch/x86/include/asm/domain.h
> @@ -272,6 +272,7 @@ struct time_scale {
>  struct pv_domain
>  {
>      l1_pgentry_t **gdt_ldt_l1tab;
> +    l1_pgentry_t **root_pt_l1tab;
> =20
>      atomic_t nr_l4_pages;
> =20
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index d537a799bced..a152e21bb086 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -516,6 +516,13 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
>          v->arch.cr3 |=3D get_pcid_bits(v, false);
>  }
> =20
> +#define pv_root_pt_idx(v) \
> +    ((v)->vcpu_id >> PAGETABLE_ORDER)
> +
> +#define pv_root_pt_pte(v) \
> +    ((v)->domain->arch.pv.root_pt_l1tab[pv_root_pt_idx(v)] + \
> +     ((v)->vcpu_id & (L1_PAGETABLE_ENTRIES - 1)))
> +
>  void write_ptbase(struct vcpu *v)
>  {
>      const struct domain *d =3D v->domain;
> @@ -527,11 +534,16 @@ void write_ptbase(struct vcpu *v)
> =20
>      if ( is_pv_domain(d) && d->arch.pv.xpti )
>      {
> +        mfn_t guest_root_pt =3D _mfn(MASK_EXTR(v->arch.cr3, X86_CR3_ADDR=
_MASK));
> +        l1_pgentry_t *pte =3D pv_root_pt_pte(v);
> +
>          cpu_info->root_pgt_changed =3D true;
>          cpu_info->pv_cr3 =3D __pa(this_cpu(root_pgt));
>          if ( new_cr4 & X86_CR4_PCIDE )
>              cpu_info->pv_cr3 |=3D get_pcid_bits(v, true);
>          switch_cr3_cr4(v->arch.cr3, new_cr4);
> +
> +        l1e_write(pte, l1e_from_mfn(guest_root_pt, __PAGE_HYPERVISOR_RO)=
);
>      }
>      else
>      {
> diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
> index d5a8564c1cbe..1a1c999743ac 100644
> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -289,6 +289,21 @@ static void pv_destroy_gdt_ldt_l1tab(struct vcpu *v)
>                                1U << GDT_LDT_VCPU_SHIFT);
>  }
> =20
> +static int pv_create_root_pt_l1tab(const struct vcpu *v)
> +{
> +    return create_perdomain_mapping(v->domain,
> +                                    PV_ROOT_PT_MAPPING_VCPU_VIRT_START(v=
),
> +                                    1, v->domain->arch.pv.root_pt_l1tab,
> +                                    NULL);
> +}
> +
> +static void pv_destroy_root_pt_l1tab(const struct vcpu *v)
> +
> +{
> +    destroy_perdomain_mapping(v->domain,
> +                              PV_ROOT_PT_MAPPING_VCPU_VIRT_START(v), 1);
> +}
> +
>  void pv_vcpu_destroy(struct vcpu *v)
>  {
>      if ( is_pv_32bit_vcpu(v) )
> @@ -298,6 +313,7 @@ void pv_vcpu_destroy(struct vcpu *v)
>      }
> =20
>      pv_destroy_gdt_ldt_l1tab(v);
> +    pv_destroy_root_pt_l1tab(v);
>      XFREE(v->arch.pv.trap_ctxt);
>  }
> =20
> @@ -312,6 +328,13 @@ int pv_vcpu_initialise(struct vcpu *v)
>      if ( rc )
>          return rc;
> =20
> +    if ( v->domain->arch.pv.xpti )
> +    {
> +        rc =3D pv_create_root_pt_l1tab(v);
> +        if ( rc )
> +            goto done;
> +    }
> +
>      BUILD_BUG_ON(X86_NR_VECTORS * sizeof(*v->arch.pv.trap_ctxt) >
>                   PAGE_SIZE);
>      v->arch.pv.trap_ctxt =3D xzalloc_array(struct trap_info, X86_NR_VECT=
ORS);
> @@ -347,10 +370,12 @@ void pv_domain_destroy(struct domain *d)
> =20
>      destroy_perdomain_mapping(d, GDT_LDT_VIRT_START,
>                                GDT_LDT_MBYTES << (20 - PAGE_SHIFT));
> +    destroy_perdomain_mapping(d, PV_ROOT_PT_MAPPING_VIRT_START, d->max_v=
cpus);
> =20
>      XFREE(d->arch.pv.cpuidmasks);
> =20
>      FREE_XENHEAP_PAGE(d->arch.pv.gdt_ldt_l1tab);
> +    FREE_XENHEAP_PAGE(d->arch.pv.root_pt_l1tab);

With root_pt_l1tab coming from xzalloc_array(), this must use XFREE() inste=
ad.

  XFREE(v->arch.pv.root_pt_l1tab);

>  }
> =20
>  void noreturn cf_check continue_pv_domain(void);
> @@ -382,8 +407,22 @@ int pv_domain_initialise(struct domain *d)
>      if ( rc )
>          goto fail;
> =20
> +    rc =3D create_perdomain_mapping(d, PV_ROOT_PT_MAPPING_VIRT_START,
> +                                  d->max_vcpus, NULL, NULL);
> +    if ( rc )
> +        goto fail;
> +
>      d->arch.ctxt_switch =3D &pv_csw;
> =20
> +    if ( d->arch.pv.xpti )
> +    {
> +        d->arch.pv.root_pt_l1tab =3D
> +            xzalloc_array(l1_pgentry_t *,
> +                          DIV_ROUND_UP(d->max_vcpus, L1_PAGETABLE_ENTRIE=
S));
> +        if ( !d->arch.pv.root_pt_l1tab )
> +            goto fail;
> +    }
> +
>      if ( !is_pv_32bit_domain(d) && use_invpcid && cpu_has_pcid )
>          switch ( ACCESS_ONCE(opt_pcid) )
>          {
> @@ -457,7 +496,8 @@ static void _toggle_guest_pt(struct vcpu *v)
>              guest_update =3D false;
>          }
>      }
> -    write_cr3(cr3);
> +
> +    write_ptbase(v);
> =20
>      if ( !pagetable_is_null(old_shadow) )
>          shadow_put_top_level(v->domain, old_shadow);
> @@ -497,9 +537,6 @@ void toggle_guest_mode(struct vcpu *v)
>      {
>          struct cpu_info *cpu_info =3D get_cpu_info();
> =20
> -        cpu_info->root_pgt_changed =3D true;
> -        cpu_info->pv_cr3 =3D __pa(this_cpu(root_pgt)) |
> -                           (d->arch.pv.pcid ? get_pcid_bits(v, true) : 0=
);
>          /*
>           * As in _toggle_guest_pt() the XPTI CR3 write needs to be a TLB=
-
>           * flushing one too for shadow mode guests.
> diff --git a/xen/arch/x86/x86_64/asm-offsets.c b/xen/arch/x86/x86_64/asm-=
offsets.c
> index 630bdc39451d..c1ae5013af96 100644
> --- a/xen/arch/x86/x86_64/asm-offsets.c
> +++ b/xen/arch/x86/x86_64/asm-offsets.c
> @@ -80,6 +80,7 @@ void __dummy__(void)
> =20
>  #undef OFFSET_EF
> =20
> +    OFFSET(VCPU_id, struct vcpu, vcpu_id);
>      OFFSET(VCPU_processor, struct vcpu, processor);
>      OFFSET(VCPU_domain, struct vcpu, domain);
>      OFFSET(VCPU_vcpu_info, struct vcpu, vcpu_info_area.map);
> diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
> index c5c723b5f4d4..91413b905768 100644
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -170,9 +170,16 @@ FUNC_LOCAL(restore_all_guest)
>          movabs $PADDR_MASK & PAGE_MASK, %rsi
>          movabs $DIRECTMAP_VIRT_START, %rcx
>          and   %rsi, %rdi
> -        and   %r9, %rsi
>          add   %rcx, %rdi
> +
> +        /*
> +         * The address in the vCPU cr3 is always mapped in the per-domai=
n
> +         * pv_root_pt virt area.
> +         */
> +        imul  $PAGE_SIZE, VCPU_id(%rbx), %esi
> +        movabs $PV_ROOT_PT_MAPPING_VIRT_START, %rcx
>          add   %rcx, %rsi
> +
>          mov   $ROOT_PAGETABLE_FIRST_XEN_SLOT, %ecx
>          mov   root_table_offset(SH_LINEAR_PT_VIRT_START)*8(%rsi), %r8
>          mov   %r8, root_table_offset(SH_LINEAR_PT_VIRT_START)*8(%rdi)



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 16:33:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 16:33:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858369.1270592 (Exim 4.92)
	(envelope-from )
	id 1tNE23-0000Cl-NC; Mon, 16 Dec 2024 16:33:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858369.1270592; Mon, 16 Dec 2024 16:33:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNE23-0000Ce-JG; Mon, 16 Dec 2024 16:33:19 +0000
Received: by outflank-mailman (input) for mailman id 858369;
 Mon, 16 Dec 2024 16:33: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 1tNE21-0000CX-WF
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 16:33:18 +0000
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com
 [2607:f8b0:4864:20::d30])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7283e7f0-bbcb-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 17:33:15 +0100 (CET)
Received: by mail-io1-xd30.google.com with SMTP id
 ca18e2360f4ac-844e1eb50e2so139951739f.0
 for ; Mon, 16 Dec 2024 08:33: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: 7283e7f0-bbcb-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734366794; x=1734971594; 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=vpOMfa/mF/n3ZZ8ESoBLLNBu8MYcUunfzbkXkXEi5/w=;
        b=jUgYVoUMc+1Ff47ZeJ4NsLCmEnn8nIOUiHwum9kHONnqdXUHGrp+p6CoLb8LgI/5cI
         7FxiGwVeZzeKNnXcnKVG59jPT54cc6swQuG1Hq8uKe2SnSMpBInRKmnGD/dnb5tHsynV
         jas43I4x/d5zqQJ2AD6uomtVyryuJyG19qxxwyqg+K3UmWBjF+KqVUzKhHPjo6+0Ru5b
         FQcZ79nUA0WiboCQWtEgv4pY8ub4vHMEC25o33vojf1WqWgPS09TgOhw6U0f1cRKMrrm
         fqDf28/1vIZK3C7xYtvjtAZqyYnmEbyzH1AyCAiZq8VIfqWQek8rtVTaPZoq7EkQPazX
         SQ6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734366794; x=1734971594;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=vpOMfa/mF/n3ZZ8ESoBLLNBu8MYcUunfzbkXkXEi5/w=;
        b=eM2BRtx00+y5R+hCBIdwNDKpGXQH6X6Dm9/11+Lo9lt53eHmTDRPdNTtoAUPeE3jCN
         iESDxeTLZYWMJRCibsz+UvspdSH6SZZejS1Wz7kRNtZbtd8X/8TZJxhVKJKbr/UcxhML
         JoyY5XmnYnSAtlRSGiMuplaqUmrVj9HzsdftsrCsbGw0V61HOEhGbWcdYRMQNIjfKawl
         GhZqwxFzo0JXipb2Aja0XGrvOT0rZuWjPwW8nxaKFbz1Vx5pvJE20gaaLUbTzsyumwWL
         ClaqTODFy7gvSA2691fm6Wal0gobJmlBbO/QbbdjXv8QBcm9I3WEfgn6W8pZeBnemmtT
         u61Q==
X-Forwarded-Encrypted: i=1; AJvYcCWdMNlK4ZYzYcsM3syKa6Aq/vy2gj+iYREjfaq535HV8g0oeMqDjJGNDDBaKIYETiprUuERC3v7FSg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxsRIV2z24A4P62mPdQgUxiSy7RpXAcsCMe3n+WpmSbTpb4420L
	ZQ2O6QEvO55cOWHnF0Alv8yXIabzT6eM38GtvZ46w5xqcMu00hx93Qg5lYc1rOqUyjT7dWCFcVa
	bSaPhENK7w2wV2Tovoli+LkAtwtXRQlcPADZyXQ==
X-Gm-Gg: ASbGncvY18vdNYRjY06RD2BOhgIvxguke4KtjIEl3PSXQOcFPKLozASxHF+C16CH6L0
	AxFEk5yXFA1VvHOi5LR+DWwtWTrQFoOy3QiuySKE=
X-Google-Smtp-Source: AGHT+IFLfvEmDKAg5ADJBv/H012KEJ+UQ83zyBDwoxceECUItTv0JqSmvYOpfRwqxW2u01Nnw8bGBqgyniV7B4ZGaAk=
X-Received: by 2002:a05:6e02:198c:b0:3a7:c5ff:e60b with SMTP id
 e9e14a558f8ab-3afef630628mr147150505ab.6.1734366794064; Mon, 16 Dec 2024
 08:33:14 -0800 (PST)
MIME-Version: 1.0
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-2-carlo.nonato@minervasys.tech> 
In-Reply-To: 
From: Carlo Nonato 
Date: Mon, 16 Dec 2024 17:33:03 +0100
Message-ID: 
Subject: Re: [PATCH v12 01/12] xen/common: add cache coloring common code
To: Jan Beulich 
Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, 
	Andrew Cooper , Anthony PERARD , 
	Michal Orzel , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jan,

On Mon, Dec 16, 2024 at 11:51=E2=80=AFAM Jan Beulich  wr=
ote:
>
> On 13.12.2024 17:28, Carlo Nonato wrote:
> > Last Level Cache (LLC) coloring allows to partition the cache in smalle=
r
> > chunks called cache colors.
> >
> > Since not all architectures can actually implement it, add a HAS_LLC_CO=
LORING
> > Kconfig option.
> > LLC_COLORS_ORDER Kconfig option has a range maximum of 10 (2^10 =3D 102=
4)
> > because that's the number of colors that fit in a 4 KiB page when integ=
ers
> > are 4 bytes long.
> >
> > LLC colors are a property of the domain, so struct domain has to be ext=
ended.
> >
> > Based on original work from: Luca Miccio 
> >
> > Signed-off-by: Carlo Nonato 
> > Signed-off-by: Marco Solieri 
> > Acked-by: Michal Orzel 
> > ---
> > v12:
> > - fixed build errors
> > - added opt_llc_coloring to improve readibility
> > - reverted llc_coloring_enabled type to bool
> > v11:
> > - __COLORING_H__ -> __XEN_LLC_COLORING_H__ in llc-coloring.h
> > - added SPDX tag to cache-coloring.rst
> > - llc-coloring=3Doff now takes precedence over other cmdline options
> > - removed useless #includes
> > v10:
> > - fixed commit message to use LLC_COLORS_ORDER
> > - added documentation to index.rst
> > - moved check on CONFIG_NUMA in arch/arm/Kconfig (next patch)
> > - fixed copyright line
> > - fixed array type for colors parameter in print_colors()
> > - added check on (way_size & ~PAGE_MASK)
> > v9:
> > - dropped _MAX_ from CONFIG_MAX_LLC_COLORS_ORDER
> > v8:
> > - minor documentation fixes
> > - "llc-coloring=3Don" is inferred from "llc-nr-ways" and "llc-size" usa=
ge
> > - turned CONFIG_NR_LLC_COLORS to CONFIG_MAX_LLC_COLORS_ORDER, base-2 ex=
ponent
> > - moved Kconfig options to common/Kconfig
> > - don't crash if computed max_nr_colors is too large
> > v7:
> > - SUPPORT.md changes added to this patch
> > - extended documentation to better address applicability of cache color=
ing
> > - "llc-nr-ways" and "llc-size" params introduced in favor of "llc-way-s=
ize"
> > - moved dump_llc_coloring_info() call in 'm' keyhandler (pagealloc_info=
())
> > v6:
> > - moved almost all code in common
> > - moved documentation in this patch
> > - reintroduced range for CONFIG_NR_LLC_COLORS
> > - reintroduced some stub functions to reduce the number of checks on
> >   llc_coloring_enabled
> > - moved domain_llc_coloring_free() in same patch where allocation happe=
ns
> > - turned "d->llc_colors" to pointer-to-const
> > - llc_coloring_init() now returns void and panics if errors are found
> > v5:
> > - used - instead of _ for filenames
> > - removed domain_create_llc_colored()
> > - removed stub functions
> > - coloring domain fields are now #ifdef protected
> > v4:
> > - Kconfig options moved to xen/arch
> > - removed range for CONFIG_NR_LLC_COLORS
> > - added "llc_coloring_enabled" global to later implement the boot-time
> >   switch
> > - added domain_create_llc_colored() to be able to pass colors
> > - added is_domain_llc_colored() macro
> > ---
> >  SUPPORT.md                        |   7 ++
> >  docs/index.rst                    |   1 +
> >  docs/misc/cache-coloring.rst      | 118 ++++++++++++++++++++++++++++
> >  docs/misc/xen-command-line.pandoc |  37 +++++++++
> >  xen/common/Kconfig                |  21 +++++
> >  xen/common/Makefile               |   1 +
> >  xen/common/keyhandler.c           |   3 +
> >  xen/common/llc-coloring.c         | 124 ++++++++++++++++++++++++++++++
> >  xen/common/page_alloc.c           |   3 +
> >  xen/include/xen/llc-coloring.h    |  36 +++++++++
> >  xen/include/xen/sched.h           |   5 ++
> >  11 files changed, 356 insertions(+)
> >  create mode 100644 docs/misc/cache-coloring.rst
> >  create mode 100644 xen/common/llc-coloring.c
> >  create mode 100644 xen/include/xen/llc-coloring.h
> >
> > diff --git a/SUPPORT.md b/SUPPORT.md
> > index 82239d0294..998faf5635 100644
> > --- a/SUPPORT.md
> > +++ b/SUPPORT.md
> > @@ -401,6 +401,13 @@ by maintaining multiple physical to machine (p2m) =
memory mappings.
> >      Status, x86 HVM: Tech Preview
> >      Status, ARM: Tech Preview
> >
> > +### Cache coloring
> > +
> > +Allows to reserve Last Level Cache (LLC) partitions for Dom0, DomUs an=
d Xen
> > +itself.
> > +
> > +    Status, Arm64: Experimental
> > +
> >  ## Resource Management
> >
> >  ### CPU Pools
> > diff --git a/docs/index.rst b/docs/index.rst
> > index 1d44796d72..1bb8d02ea3 100644
> > --- a/docs/index.rst
> > +++ b/docs/index.rst
> > @@ -66,6 +66,7 @@ Documents in need of some rearranging.
> >     misc/xen-makefiles/makefiles
> >     misra/index
> >     fusa/index
> > +   misc/cache-coloring
> >
> >
> >  Miscellanea
> > diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rs=
t
> > new file mode 100644
> > index 0000000000..371f21a0e7
> > --- /dev/null
> > +++ b/docs/misc/cache-coloring.rst
> > @@ -0,0 +1,118 @@
> > +.. SPDX-License-Identifier: CC-BY-4.0
> > +
> > +Xen cache coloring user guide
> > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
> > +
> > +The cache coloring support in Xen allows to reserve Last Level Cache (=
LLC)
> > +partitions for Dom0, DomUs and Xen itself. Currently only ARM64 is sup=
ported.
> > +Cache coloring realizes per-set cache partitioning in software and is =
applicable
> > +to shared LLCs as implemented in Cortex-A53, Cortex-A72 and similar CP=
Us.
> > +
> > +To compile LLC coloring support set ``CONFIG_LLC_COLORING=3Dy``.
> > +
> > +If needed, change the maximum number of colors with
> > +``CONFIG_LLC_COLORS_ORDER=3D``.
> > +
> > +Runtime configuration is done via `Command line parameters`_.
> > +
> > +Background
> > +**********
> > +
> > +Cache hierarchy of a modern multi-core CPU typically has first levels =
dedicated
> > +to each core (hence using multiple cache units), while the last level =
is shared
> > +among all of them. Such configuration implies that memory operations o=
n one
> > +core (e.g. running a DomU) are able to generate interference on anothe=
r core
> > +(e.g. hosting another DomU). Cache coloring realizes per-set cache-par=
titioning
> > +in software and mitigates this, guaranteeing more predictable performa=
nces for
> > +memory accesses.
> > +Software-based cache coloring is particularly useful in those situatio=
ns where
> > +no hardware mechanisms (e.g., DSU-based way partitioning) are availabl=
e to
> > +partition caches. This is the case for e.g., Cortex-A53, A57 and A72 C=
PUs that
> > +feature a L2 LLC cache shared among all cores.
> > +
> > +The key concept underlying cache coloring is a fragmentation of the me=
mory
> > +space into a set of sub-spaces called colors that are mapped to disjoi=
nt cache
> > +partitions. Technically, the whole memory space is first divided into =
a number
> > +of subsequent regions. Then each region is in turn divided into a numb=
er of
> > +subsequent sub-colors. The generic i-th color is then obtained by all =
the
> > +i-th sub-colors in each region.
> > +
> > +::
> > +
> > +                            Region j            Region j+1
> > +                .....................   ............
> > +                .                     . .
> > +                .                       .
> > +            _ _ _______________ _ _____________________ _ _
> > +                |     |     |     |     |     |     |
> > +                | c_0 | c_1 |     | c_n | c_0 | c_1 |
> > +           _ _ _|_____|_____|_ _ _|_____|_____|_____|_ _ _
> > +                    :                       :
> > +                    :                       :...         ... .
> > +                    :                            color 0
> > +                    :...........................         ... .
> > +                                                :
> > +          . . ..................................:
> > +
> > +How colors are actually defined depends on the function that maps memo=
ry to
> > +cache lines. In case of physically-indexed, physically-tagged caches w=
ith linear
> > +mapping, the set index is found by extracting some contiguous bits fro=
m the
> > +physical address. This allows colors to be defined as shown in figure:=
 they
> > +appear in memory as subsequent blocks of equal size and repeats themse=
lves after
> > +``n`` different colors, where ``n`` is the total number of colors.
> > +
> > +If some kind of bit shuffling appears in the mapping function, then co=
lors
> > +assume a different layout in memory. Those kind of caches aren't suppo=
rted by
> > +the current implementation.
> > +
> > +**Note**: Finding the exact cache mapping function can be a really dif=
ficult
> > +task since it's not always documented in the CPU manual. As said Corte=
x-A53, A57
> > +and A72 are known to work with the current implementation.
> > +
> > +How to compute the number of colors
> > +###################################
> > +
> > +Given the linear mapping from physical memory to cache lines for grant=
ed, the
> > +number of available colors for a specific platform is computed using t=
hree
> > +parameters:
> > +
> > +- the size of the LLC.
> > +- the number of the LLC ways.
> > +- the page size used by Xen.
> > +
> > +The first two parameters can be found in the processor manual, while t=
he third
> > +one is the minimum mapping granularity. Dividing the cache size by the=
 number of
> > +its ways we obtain the size of a way. Dividing this number by the page=
 size,
> > +the number of total cache colors is found. So for example an Arm Corte=
x-A53
> > +with a 16-ways associative 1 MiB LLC can isolate up to 16 colors when =
pages are
> > +4 KiB in size.
> > +
> > +Effective colors assignment
> > +###########################
> > +
> > +When assigning colors, if one wants to avoid cache interference betwee=
n two
> > +domains, different colors needs to be used for their memory.
> > +
> > +Command line parameters
> > +***********************
> > +
> > +Specific documentation is available at `docs/misc/xen-command-line.pan=
doc`.
> > +
> > ++----------------------+-------------------------------+
> > +| **Parameter**        | **Description**               |
> > ++----------------------+-------------------------------+
> > +| ``llc-coloring``     | Enable coloring at runtime    |
> > ++----------------------+-------------------------------+
> > +| ``llc-size``         | Set the LLC size              |
> > ++----------------------+-------------------------------+
> > +| ``llc-nr-ways``      | Set the LLC number of ways    |
> > ++----------------------+-------------------------------+
> > +
> > +Auto-probing of LLC specs
> > +#########################
> > +
> > +LLC size and number of ways are probed automatically by default.
> > +
> > +LLC specs can be manually set via the above command line parameters. T=
his
> > +bypasses any auto-probing and it's used to overcome failing situations=
, such as
> > +flawed probing logic, or for debugging/testing purposes.
> > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-=
line.pandoc
> > index 293dbc1a95..abd8dae96f 100644
> > --- a/docs/misc/xen-command-line.pandoc
> > +++ b/docs/misc/xen-command-line.pandoc
> > @@ -1708,6 +1708,43 @@ This option is intended for debugging purposes o=
nly.  Enable MSR_DEBUGCTL.LBR
> >  in hypervisor context to be able to dump the Last Interrupt/Exception =
To/From
> >  record with other registers.
> >
> > +### llc-coloring (arm64)
> > +> `=3D `
> > +
> > +> Default: `false`
> > +
> > +Flag to enable or disable LLC coloring support at runtime. This option=
 is
> > +available only when `CONFIG_LLC_COLORING` is enabled. See the general
> > +cache coloring documentation for more info.
> > +
> > +### llc-nr-ways (arm64)
> > +> `=3D `
> > +
> > +> Default: `Obtained from hardware`
> > +
> > +Specify the number of ways of the Last Level Cache. This option is ava=
ilable
> > +only when `CONFIG_LLC_COLORING` is enabled. LLC size and number of way=
s are used
> > +to find the number of supported cache colors. By default the value is
> > +automatically computed by probing the hardware, but in case of specifi=
c needs,
> > +it can be manually set. Those include failing probing and debugging/te=
sting
> > +purposes so that it's possible to emulate platforms with different num=
ber of
> > +supported colors. If set, also "llc-size" must be set, otherwise the d=
efault
> > +will be used. Note that using both options implies "llc-coloring=3Don"=
.
> > +
> > +### llc-size (arm64)
> > +> `=3D `
> > +
> > +> Default: `Obtained from hardware`
> > +
> > +Specify the size of the Last Level Cache. This option is available onl=
y when
> > +`CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are used=
 to find
> > +the number of supported cache colors. By default the value is automati=
cally
> > +computed by probing the hardware, but in case of specific needs, it ca=
n be
> > +manually set. Those include failing probing and debugging/testing purp=
oses so
> > +that it's possible to emulate platforms with different number of suppo=
rted
> > +colors. If set, also "llc-nr-ways" must be set, otherwise the default =
will be
> > +used. Note that using both options implies "llc-coloring=3Don".
> > +
> >  ### lock-depth-size
> >  > `=3D `
> >
> > diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> > index 90268d9249..b4ec6893be 100644
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -71,6 +71,9 @@ config HAS_IOPORTS
> >  config HAS_KEXEC
> >       bool
> >
> > +config HAS_LLC_COLORING
> > +     bool
> > +
> >  config HAS_PIRQ
> >       bool
> >
> > @@ -516,4 +519,22 @@ config TRACEBUFFER
> >         to be collected at run time for debugging or performance analys=
is.
> >         Memory and execution overhead when not active is minimal.
> >
> > +config LLC_COLORING
> > +     bool "Last Level Cache (LLC) coloring" if EXPERT
> > +     depends on HAS_LLC_COLORING
> > +
> > +config LLC_COLORS_ORDER
> > +     int "Maximum number of LLC colors (base-2 exponent)"
> > +     range 1 10
> > +     default 7
> > +     depends on LLC_COLORING
> > +     help
> > +       Controls the build-time size of various arrays associated with =
LLC
> > +       coloring. The value is a base-2 exponent. Refer to cache colori=
ng
> > +       documentation for how to compute the number of colors supported=
 by the
> > +       platform. This is only an upper bound. The runtime value is aut=
ocomputed
> > +       or manually set via cmdline parameters.
> > +       The default value corresponds to an 8 MiB 16-ways LLC, which sh=
ould be
> > +       more than what's needed in the general case.
> > +
> >  endmenu
> > diff --git a/xen/common/Makefile b/xen/common/Makefile
> > index b279b09bfb..cba3b32733 100644
> > --- a/xen/common/Makefile
> > +++ b/xen/common/Makefile
> > @@ -25,6 +25,7 @@ obj-y +=3D keyhandler.o
> >  obj-$(CONFIG_KEXEC) +=3D kexec.o
> >  obj-$(CONFIG_KEXEC) +=3D kimage.o
> >  obj-$(CONFIG_LIVEPATCH) +=3D livepatch.o livepatch_elf.o
> > +obj-$(CONFIG_LLC_COLORING) +=3D llc-coloring.o
> >  obj-$(CONFIG_MEM_ACCESS) +=3D mem_access.o
> >  obj-y +=3D memory.o
> >  obj-y +=3D multicall.o
> > diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
> > index 6da291b34e..6ea54838d4 100644
> > --- a/xen/common/keyhandler.c
> > +++ b/xen/common/keyhandler.c
> > @@ -5,6 +5,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -304,6 +305,8 @@ static void cf_check dump_domains(unsigned char key=
)
> >
> >          arch_dump_domain_info(d);
> >
> > +        domain_dump_llc_colors(d);
> > +
> >          rangeset_domain_printk(d);
> >
> >          dump_pageframe_info(d);
> > diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
> > new file mode 100644
> > index 0000000000..b0fc162b05
> > --- /dev/null
> > +++ b/xen/common/llc-coloring.c
> > @@ -0,0 +1,124 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Last Level Cache (LLC) coloring common code
> > + *
> > + * Copyright (C) 2024, Advanced Micro Devices, Inc.
> > + * Copyright (C) 2024, Minerva Systems SRL
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define NR_LLC_COLORS          (1U << CONFIG_LLC_COLORS_ORDER)
> > +
> > +/*
> > + * -1: not specified (disabled unless llc-size and llc-nr-ways present=
)
> > + *  0: explicitly disabled through cmdline
> > + *  1: explicitly enabled through cmdline
> > + */
> > +static int8_t __initdata opt_llc_coloring =3D -1;
> > +boolean_param("llc-coloring", opt_llc_coloring);
> > +
> > +static bool __ro_after_init llc_coloring_enabled;
> > +
> > +static unsigned int __initdata llc_size;
> > +size_param("llc-size", llc_size);
> > +static unsigned int __initdata llc_nr_ways;
> > +integer_param("llc-nr-ways", llc_nr_ways);
> > +/* Number of colors available in the LLC */
> > +static unsigned int __ro_after_init max_nr_colors;
> > +
> > +static void print_colors(const unsigned int colors[], unsigned int num=
_colors)
> > +{
> > +    unsigned int i;
> > +
> > +    printk("{ ");
> > +    for ( i =3D 0; i < num_colors; i++ )
> > +    {
> > +        unsigned int start =3D colors[i], end =3D start;
> > +
> > +        printk("%u", start);
> > +
> > +        for ( ; i < num_colors - 1 && end + 1 =3D=3D colors[i + 1]; i+=
+, end++ )
> > +            ;
> > +
> > +        if ( start !=3D end )
> > +            printk("-%u", end);
> > +
> > +        if ( i < num_colors - 1 )
> > +            printk(", ");
> > +    }
> > +    printk(" }\n");
> > +}
> > +
> > +void __init llc_coloring_init(void)
> > +{
> > +    unsigned int way_size;
> > +
> > +    llc_coloring_enabled =3D (opt_llc_coloring =3D=3D 1);
>
> Generally I'd suggest to only use > 0, >=3D 0, < 0, and <=3D 0 on such
> variables.
>
> > +    if ( (opt_llc_coloring !=3D 0) && llc_size && llc_nr_ways )
> > +    {
> > +        llc_coloring_enabled =3D true;
> > +        way_size =3D llc_size / llc_nr_ways;
> > +    }
>
> Hmm, I actually see a difference in someone saying
>
> "llc-coloring=3D0 llc-size=3D... llc-nr-ways=3D..."
>
> vs
>
> "llc-size=3D... llc-nr-ways=3D... llc-coloring=3D0"
>
> I'm not sure about Arm, but on x86 this can be relevant as there may be
> pre-set parts of a command line with appended (human) overrides. Therefor=
e
> it always wants to be "last wins". Yet yes, you may weant to take the
> position that in such a case the former example would require "llc-colori=
ng=3D1"
> to also be added.

Yes, I think this should be the way to go.

> Kind of against the shorthand llc-size+llc-nr-ways only,
> though.

The shorthand was proposed by you here:
https://patchew.org/Xen/20240315105902.160047-1-carlo.nonato@minervasys.tec=
h/20240315105902.160047-2-carlo.nonato@minervasys.tech/#05e4d3da-4130-4c57-=
9855-43b685ce5005@suse.com

> Wouldn't it make sense to infer "llc-coloring" when both of the latter op=
tions
> were supplied?

We both agreed that it was something good to have.

> Jan

Thanks.

- Carlo


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 16:51:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 16:51:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858385.1270606 (Exim 4.92)
	(envelope-from )
	id 1tNEJr-0003BC-Aa; Mon, 16 Dec 2024 16:51:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858385.1270606; Mon, 16 Dec 2024 16:51: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 1tNEJr-0003B5-7V; Mon, 16 Dec 2024 16:51:43 +0000
Received: by outflank-mailman (input) for mailman id 858385;
 Mon, 16 Dec 2024 16:51: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 1tNEJq-0003Az-1J
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 16:51:42 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0509e3ab-bbce-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 17:51:39 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 16 Dec 2024 17:51:39 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 0509e3ab-bbce-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734367900; x=1765903900;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=QHWfcLnJ/NkdFiBCvjorln0ohBppte9uNiADP/3iEvM=;
  b=QspoDnimKgUMoVzMhO3tvgUYonljjyJbmyP5kP9bCrJ5CkrY6ulIqPAn
   HBS4eD4VIokzPtlXi3upp4EVILlkzOxZB8cZhsEI4mmMtU6LOo2Bpmkw9
   8tNIoHFrDhn9uKf9a0x5HXcyHWc46bnAtMoXYPXdeFdFr+2QqKyoLYL3y
   w=;
X-CSE-ConnectionGUID: XxQNsC37StuOJhaBwO9iYQ==
X-CSE-MsgGUID: tPScodwQTESouMyNiePfRQ==
X-IronPort-AV: E=Sophos;i="6.12,239,1728943200"; 
   d="scan'208";a="28202852"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: <49497f8c-a2e4-49a1-aac0-96d704834f0f@citrix.com>
Content-Type: text/plain; charset="utf-8"
X-Forward: 149.5.228.1
References: <20241214161350.70515-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241214161350.70515-3-Ariel.Otilibili-Anieli@eurecom.fr> <49497f8c-a2e4-49a1-aac0-96d704834f0f@citrix.com>
Date: Mon, 16 Dec 2024 17:51:39 +0100
Cc: xen-devel@lists.xenproject.org, "Jan Beulich" , "Luca Fancellu" , "Anthony PERARD" 
To: "Andrew Cooper" 
MIME-Version: 1.0
Message-ID: <2f7a87-67605a80-ce37-141f3260@214819454>
Subject: =?utf-8?q?Re=3A?= [PATCH 1/1] =?utf-8?q?tools=2C?=
 =?utf-8?q?_xen/scripts=3A?= clear out Python syntax warnings
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 4040

On Monday, December 16, 2024 12:34 CET, Andrew Cooper  wrote:

> On 14/12/2024 4:09 pm, Ariel Otilibili wrote:
> > * since 3.12 invalid escape sequences generate SyntaxWarning
> > * in the future, these invalid sequences will generate SyntaxError
> > * therefore changed syntax to raw string notation.
> >
> > Link: https://docs.python.org/3/whatsnew/3.12.html#other-language-c=
hanges
> > Fixes: e45e8f69047 ("bitkeeper revision 1.803 (4056f51d2UjBnn9uwzC9=
Vu3LspnUCg)")
> > Fixes: d8f3a67bf98 ("pygrub: further improve grub2 support")
> > Fixes: dd03048708a ("xen/pygrub: grub2/grub.cfg from RHEL 7 has new=
 commands in menuentry")
> > Fixes: d1b93ea2615 ("tools/pygrub: Make pygrub understand default e=
ntry in string format")
> > Fixes: 622e368758b ("Add ZFS libfsimage support patch")
> > Fixes: 02b26c02c7c ("xen/scripts: add cppcheck tool to the xen-anal=
ysis.py script")
> > Fixes: 56c0063f4e7 ("xen/misra: xen-analysis.py: Improve the cppche=
ck version check")
> >
> > Cc: Anthony PERARD 
> > Cc: Luca Fancellu 
> > Signed-off-by: Ariel Otilibili 
> > ---
> >  tools/misc/xensymoops                         | 4 ++--
> >  tools/pygrub/src/GrubConf.py                  | 4 ++--
> >  tools/pygrub/src/pygrub                       | 6 +++---
> >  xen/scripts/xen=5Fanalysis/cppcheck=5Fanalysis.py | 4 ++--
> >  4 files changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/tools/misc/xensymoops b/tools/misc/xensymoops
> > index 835d187e90..bec75cae93 100755
> > --- a/tools/misc/xensymoops
> > +++ b/tools/misc/xensymoops
> > @@ -17,7 +17,7 @@ def read=5Foops():
> >      stack=5Faddrs is a dictionary mapping potential code addresses=
 in the stack
> >        to their order in the stack trace.
> >      """
> > -    stackaddr=5Fptn =3D "\[([a-z,0-9]*)\]"
> > +    stackaddr=5Fptn =3D r"\[([a-z,0-9]*)\]"
> >      stackaddr=5Fre  =3D re.compile(stackaddr=5Fptn)
> > =20
> >      eip=5Fptn =3D ".*EIP:.*<([a-z,0-9]*)>.*"
>=20
> Oh wow.=C2=A0 I've not come across this script before, and it's not
> referenced in the build system.
>=20
> Also, it's hard-coded to 32bit Xen which was deleted in Xen 4.13 more
> than a decade ago, and there are other errors in the regexes such as
> including a comma in stackaddr=5Fptn
>=20
> Worse however, it escaped the Py2->3 conversion and is still using ra=
w
> print statements.
>=20
> I'll submit a patch deleting it entirely.

Acked-by: Ariel Otilibili-Anieli 

I'll send a new series, only on the subsequent feedback.=20
>=20
> > diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/GrubCo=
nf.py
> > index 580c9628ca..7cd2bc9aeb 100644
> > --- a/tools/pygrub/src/GrubConf.py
> > +++ b/tools/pygrub/src/GrubConf.py
> > @@ -320,7 +320,7 @@ class GrubConfigFile(=5FGrubConfigFile):
> >  def grub2=5Fhandle=5Fset(arg):
> >      (com,arg) =3D grub=5Fsplit(arg,2)
> >      com=3D"set:" + com
> > -    m =3D re.match("([\"\'])(.*)\\1", arg)
> > +    m =3D re.match(r"([\"\'])(.*)\\1", arg)
>=20
> Doesn't this \\1 want to turn into just \1 now it's a raw string?

Indeed; I'll do that.
>=20
> > diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
> > index 9d51f96070..58b088d285 100755
> > --- a/tools/pygrub/src/pygrub
> > +++ b/tools/pygrub/src/pygrub
> > @@ -1104,7 +1104,7 @@ if =5F=5Fname=5F=5F =3D=3D "=5F=5Fmain=5F=5F"=
:
> >      if chosencfg["args"]:
> >          zfsinfo =3D xenfsimage.getbootstring(fs)
> >          if zfsinfo is not None:
> > -            e =3D re.compile("zfs-bootfs=3D[\w\-\.\:@/]+" )
> > +            e =3D re.compile(r"zfs-bootfs=3D[\w\-\.\:@/]+" )
>=20
> Related, this string looks dodgy.=C2=A0 The \- is correct (I think, t=
o not
> have it interpreted as a range), but I'm pretty sure a literal . and =
:
> don't need escaping inside a [], and the result here would be for a
> literal \ to be included.
>=20

To replace: \w\-\.\:@/
By: \w\-.:@/

Is this what you mean?
> ~Andrew



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 16:58:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 16:58:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858395.1270616 (Exim 4.92)
	(envelope-from )
	id 1tNEPw-0003m0-UM; Mon, 16 Dec 2024 16:58:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858395.1270616; Mon, 16 Dec 2024 16:58: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 1tNEPw-0003lt-RO; Mon, 16 Dec 2024 16:58:00 +0000
Received: by outflank-mailman (input) for mailman id 858395;
 Mon, 16 Dec 2024 16:58: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 1tNEPv-0003ln-LL
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 16:58:00 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e618e851-bbce-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 17:57:57 +0100 (CET)
Received: from delta.homenet.telecomitalia.it
 (host-82-59-161-229.retail.telecomitalia.it [82.59.161.229])
 by support.bugseng.com (Postfix) with ESMTPSA id 21AA54EE0738;
 Mon, 16 Dec 2024 17:57:54 +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: e618e851-bbce-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1734368276; bh=IIRKdy9oT95fHBS88XII/+1T1/LoTgdJ1XtpdTtepJw=;
	h=From:To:Cc:Subject:Date:From;
	b=NmAU25MzrNRkTZSTpmnnNtanN2wOg6iIUelp5dMx4GQfg9OyI/GM4E01I39dKQ6Y3
	 IYx0WFY+fFxaoTiD3auR0sBB9KgSMGSjguC7J88OrN4wmMes43u9WHlr4dwbzjEnm9
	 uBzfXsp6ombbpBGyYZgzh32XqIkE6ArAgDy4HLtGHXfdTqNb0SC2gxpodYaIpwHu0F
	 NThSWoHbc2KSV3Ua5vrIYuQdKNjhLJkB9rC0RGgfiAV97h6b51WPnjp4un0HB2+3VB
	 idwyN2WsX+cn297PY7ePpB87vCdhRQ1l98ZjhTmt+LeYA+wXUeaFO0/qbdcNm3fMh+
	 V1nnLIf4OhDxA==
From: Alessandro Zucchelli 
To: xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com,
	Alessandro Zucchelli ,
	Simone Ballarin ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: [PATCH] misra: add deviation for MISRA C Rule R11.8.
Date: Mon, 16 Dec 2024 17:57:45 +0100
Message-ID: <202c8efa4f846018e463f6242d25eb10c015d835.1734367711.git.alessandro.zucchelli@bugseng.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Rule 11.8 states as following: "A cast shall not remove any `const' or
`volatile' qualification from the type pointed to by a pointer".

Function `__hvm_copy' in `xen/arch/x86/hvm/hvm.c' is a double-use
function, where the parameter needs to not be const because it can be
set for write or not. As it was decided a new const-only function will
lead to more developer confusion than it is worth, this violation is
addressed by deviating the function.

No functional change.

Signed-off-by: Alessandro Zucchelli 
---
As this patch introduces a deviation for service MC3A2.R11.1, it
depends on the following patch and shall not be applied prior to its
application.
https://lore.kernel.org/xen-devel/cf13be4779f15620e94b99b3b91f9cb040319989.1733826952.git.alessandro.zucchelli@bugseng.com/T/#u
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 2f58f29203..5056669f16 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -393,6 +393,12 @@ Fixing this violation would require to increase code complexity and lower readab
 -config=MC3R1.R11.8,reports+={safe,"any_area(any_loc(any_exp(macro(^container_of$))))"}
 -doc_end
 
+-doc_begin="Function __hvm_copy in xen/arch/x86/hvm/hvm.c is a double-use
+function, where the parameter needs to not be const because it can be set for
+writeor not"
+-config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(text(^.*__hvm_copy.*$)))"}
+-doc_end
+
 -doc_begin="This construct is used to check if the type is scalar, and for this purpose the use of 0 as a null pointer constant is deliberate."
 -config=MC3R1.R11.9,reports+={deliberate, "any_area(any_loc(any_exp(macro(^__ACCESS_ONCE$))))"
 }
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 17:01:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 17:01:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858404.1270625 (Exim 4.92)
	(envelope-from )
	id 1tNETJ-0005Us-AI; Mon, 16 Dec 2024 17:01:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858404.1270625; Mon, 16 Dec 2024 17:01:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNETJ-0005Ul-7k; Mon, 16 Dec 2024 17:01:29 +0000
Received: by outflank-mailman (input) for mailman id 858404;
 Mon, 16 Dec 2024 17:01: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 1tNETH-0005Ue-Cc
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 17:01:27 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20614.outbound.protection.outlook.com
 [2a01:111:f403:2418::614])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 622ad7aa-bbcf-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 18:01:26 +0100 (CET)
Received: from CH0PR13CA0011.namprd13.prod.outlook.com (2603:10b6:610:b1::16)
 by DM4PR12MB5916.namprd12.prod.outlook.com (2603:10b6:8:69::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.22; Mon, 16 Dec
 2024 17:01:22 +0000
Received: from CH2PEPF0000009B.namprd02.prod.outlook.com
 (2603:10b6:610:b1:cafe::b7) by CH0PR13CA0011.outlook.office365.com
 (2603:10b6:610:b1::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.11 via Frontend Transport; Mon,
 16 Dec 2024 17:01:21 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH2PEPF0000009B.mail.protection.outlook.com (10.167.244.23) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Mon, 16 Dec 2024 17:01:21 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) 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; Mon, 16 Dec
 2024 11:01:21 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 16 Dec
 2024 11:01:20 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 16 Dec 2024 11:01:19 -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: 622ad7aa-bbcf-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=MIdEGTsZ/MjCWE6LLtVlTCbgFyfYvrQ00guAWAKzjgaQh/xpTmzMTNBCItdpML1qUgCyLIILUYn0L65P0R8UHS89YLg2Ush53tE5RaRnIQpvPCvPEACXTGR8dhcNvCydgJDCKgsFVx/SaVhBce5UGUvcB4aLECxpOsvDa0tm/OEs2597fy0zPErXgDdZLlvrkWFi0wqDuVO3w94ZGZHAjBCWo6hFeWV7W79DFICvmptsR54UyV/kQE2cs2GqFQGna+x7BCNWvvuMEag3jtwOuyCPWZVP7pygxNU1gBWaGOZuYNOYQBJ4yaGfL6ZAyU9H5F7CczAZKjACOuhO0msmPA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=v/opseh/KZDIsGsMACfVtPaEUrDMyjerWeUE+G3JzKw=;
 b=UEYK3aliDOJxdYgVAWjsf8vbfxVOt4OwtunR8VkEgl1N0GgndyCZ7FP1e3TU9WZwrTcZy4rp7Vqfy8uo6FKfq9z6wOjt1Mnf8hISlb2rSzk6nERrYyKg3VnlU1Aqjdrb8qjKPpOCHB7miMZdY9ofXenSdhXASbYqWeXZtisLPYg2sLAo9PJ6ZDgMGVe/ubQ+Sm671IF1SAmfVUYJJ/BboK2N5tA9ogV5Be1/Jn+FjEMcLeGOCqcrJzjsyJJjwHu3hI5xTzA+TWM5jDqQO0Q7tykLBZC2DAbRV35DUwUs32uUFjESk9ZmIhlcUxKewLAR0N8kmqtIsVExkCmZpOOkbw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=minervasys.tech smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=v/opseh/KZDIsGsMACfVtPaEUrDMyjerWeUE+G3JzKw=;
 b=nMucCd97GqHqBW0jQ5SDDrLEKN7GMhXzYP4TdHdcrM1VC60x7lVEhLefXolMAYuwScww2SGqljhDcE/mQoJ0G1l4L9l1ygoSbyRsWL8BV4I+ABbf6i61yW7OCGnKwna8tlsbywa5MTlfqrIVZDQbOJA0K9qn0QGwbPEoUKZM45c=
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=SATLEXMB04.amd.com; pr=C
Message-ID: <7d3b2ea9-1018-4d47-8c2c-51102a61202f@amd.com>
Date: Mon, 16 Dec 2024 18:01:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v12 03/12] xen/arm: permit non direct-mapped Dom0
 construction
To: Carlo Nonato 
CC: , ,
	, Stefano Stabellini ,
	Julien Grall , Bertrand Marquis ,
	Volodymyr Babchuk 
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-4-carlo.nonato@minervasys.tech>
 
 
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB05.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF0000009B:EE_|DM4PR12MB5916:EE_
X-MS-Office365-Filtering-Correlation-Id: bc468a88-d2c1-4e4c-6b61-08dd1df3444f
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:
	=?utf-8?B?ZWZFeWN1MjRLdEMvaHh3RUhISFZxZEdvQXFFREtDcmx6WDFBNDZmQTExVE5w?=
 =?utf-8?B?aC9kL2N5WG9VNXE5bXowc3Z6NUQyT09KUlg0UCtDWTNWdXVEZksrczNyaHY3?=
 =?utf-8?B?VEx4Sy91aFZ5M3BKZmFpeHR4SWJ2VGgyMmx0NUF6RGVNK0tzODYwVU4vcnlZ?=
 =?utf-8?B?RmZBNUxqQXNDSlZHR3crcDBXRWljUFlwcWd1Ylo5T2U2dklzb2hLUFgrN3J3?=
 =?utf-8?B?NmI3OTV3ekNSM3hvbTNCNEdwM2pTeEtaaGFkYXArSStLNzVCQzdWeDFidE9U?=
 =?utf-8?B?MUhvbDhlVm44VHRsMG5kRHdsajBwRldWMStTYldQZjB2NXNWSkNjNGFhcmkx?=
 =?utf-8?B?NTk4Zi9zbDZzWUlGbVAyWGtDWjJ6cFl3RmZwMWxvRk1TN2xUYVVjSzVTcWJy?=
 =?utf-8?B?Rm9FVFlqeVUvUU9hWkwwdVpLL2Q5SjNBb2NCTGFDREowMk1tQ1N0c0Q1UUdF?=
 =?utf-8?B?SnJtM0lOT2RBc2NUYnNCODg1cis1czlaOXpiZjJTZnJwZmlPL2UrN3Jpd2Nn?=
 =?utf-8?B?RlhMZWlLdklCVUNCSHB0M09GZGJhU1MxcG9pWlViczlwVjREblE2d0RlZUEr?=
 =?utf-8?B?V0xiUUxuSGM3SXNXT21wUGRDaDJ5anZHU21WVjg2NG1IWEd5UmxEbVhENDJY?=
 =?utf-8?B?MDRxem5HVEE4U0FwZjdCSTBsZGIvMmNGV05UZTgreit4NG00Q0s3MW5RR3Zm?=
 =?utf-8?B?aCtYUUw4Z2xmT3Y1dnNXb3Q0dUdiNkZ6aUsxeU1iNlRzek10RjQ3OVFJc3BT?=
 =?utf-8?B?b2d4SXFvRVZCNUl2VkE4TCswUWlxSWFqczVMdGFhYkxGTkNuQlBDeG5NOWw3?=
 =?utf-8?B?SWthNXZidTU3N3Nnbk5wZ25RQ1BwcG03NmtTYmQwenhVOHVDVzdQd2VuNFZN?=
 =?utf-8?B?R2R6WHl2TU5ubjlFWDBNelpkRVF4YjRNRnU2SEMwSFJxUjBFQldrRUwzK1Y3?=
 =?utf-8?B?RjMxLzhmbkpWazlJaHVlMVpEb1BzK0g1KzUxcnFkZzFLUTdEQVp4b1Bicm5L?=
 =?utf-8?B?M2xWWDErK0M1czAvck9qWjlFY2Jmd1RmRUNuMUNzd2w1Mi8vdFAzcEpWZ3VW?=
 =?utf-8?B?Y2hOSU80cm9RZUVra3ZVZ3htOTRaNVNBeTFCQ2dOMjBrM1JqRW5sNkdDU1Iz?=
 =?utf-8?B?azZmRytLZS9DYUMxb0NJZnJ0ZmJIVEVkNXMzTDhtRjBGd3pFeUliMHFpMVZk?=
 =?utf-8?B?dEozRHZ1MS9BOHNaMUNFemU4ZUNyWmpOWmlGQXZpZEVHaEJnY2NuZW9aVk1R?=
 =?utf-8?B?M08wdFV1N1ozR3AvNzh2cy9oc0Z5QXM4SldkYUdIenJ5ZkNSU3plZFBOTndp?=
 =?utf-8?B?QS9QQ1VZdDA2a2hub2I4ZFJWbW5CMHpuZEltaFhPaU1pMG5DZHAvazJoZDBt?=
 =?utf-8?B?VG9JeEFOR1REU0pEYktJN1hhTVo2NTN0dE1PTEpwK2NkeG1XaXpHdGliem9p?=
 =?utf-8?B?ZGFUeVgybzdYcnF3NldTZWg5akFyOG4xQmw1eEFZSStTM3dFSnA5QjNKK1l5?=
 =?utf-8?B?ZEFSMkZqRTBBU05jZDFqVHU0b3FJWDJSNFpEbStXWlJzZ0NhUHA0RlNheUJi?=
 =?utf-8?B?ZWNMeWgyZmhmcHN4WncrcjFzTGtDVkd5UUVWMnFUSDhCQWtoSWRzMjhMeFBZ?=
 =?utf-8?B?b28zd3JrcnkxbUozdG16R2J0U3M5dEMzWGVtcVowRjIvTm9xenNPQU4yUm1S?=
 =?utf-8?B?OFRhNlViRkFtaTByZVYvZWlKSzFqeGFpbTlBTmw5eElla2dXSUI1bEIwMXI3?=
 =?utf-8?B?SDBiVE8vSVZWZE1UNWtpQVNJY05Kdk5LNGJpT0ZVekVSRVVLaGo0OG5NZlor?=
 =?utf-8?B?aGFHaFlUcUxjWi9DNEhtdWhWajFjbUthL2xuckEvSGkwT3U0b2txS0ZOQnhH?=
 =?utf-8?B?NEJFK2pGbFJqQUVibDdqeFYvWmhYanBOc08wMzNod0hvQzZZaWFCS2N1ZmxP?=
 =?utf-8?B?ZzhaRzhWdmlodXdLSnB5YldpUlB5WUNNYWtZUmZpYlRxaDJnTXBNUXFMYmNw?=
 =?utf-8?Q?PvfX5xq4AI6IZHQqEuMhS6oj9L4pc4=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(36860700013)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Dec 2024 17:01:21.5698
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: bc468a88-d2c1-4e4c-6b61-08dd1df3444f
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF0000009B.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5916



On 16/12/2024 16:51, Carlo Nonato wrote:
> 
> 
> Hi Michal,
> 
> On Mon, Dec 16, 2024 at 1:08 PM Michal Orzel  wrote:
>>
>> On 13/12/2024 17:28, Carlo Nonato wrote:
>>>
>>> Cache coloring requires Dom0 not to be direct-mapped because of its non
>>> contiguous mapping nature, so allocate_memory() is needed in this case.
>>> 8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a separate module")
>>> moved allocate_memory() in dom0less_build.c. In order to use it
>>> in Dom0 construction bring it back to domain_build.c and declare it in
>>> domain_build.h.
>>>
>>> Adapt the implementation of allocate_memory() so that it uses the host
>>> layout when called on the hwdom, via find_unallocated_memory(). Take the
>>> opportunity to keep the parameter order consistent with
>>> rangeset_report_ranges() and move the membanks struct after the callback
>>> function in find_unallocated_memory().
>> Why? What benefit does this change (that is irrelevant to the goal of this patch) provide?
> 
> You're right, it's irrelevant to this patch. Do you think it can be done in a
> separate patch? If nothing else, find_unallocated_memory() appears to be
> called 2 times while rangeset_report_ranges() 11 times.
Leave it as is. I don't understand why you think find_unallocated_memory is supposed to follow some
special format like rangeset_report_ranges. Don't focus on things that are not relevant for now. Merging this series for
4.20 is more important.

Also, please trim down your replies.

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 17:40:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 17:40:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858417.1270635 (Exim 4.92)
	(envelope-from )
	id 1tNF59-0002Lz-1P; Mon, 16 Dec 2024 17:40:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858417.1270635; Mon, 16 Dec 2024 17: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 1tNF58-0002Ls-V5; Mon, 16 Dec 2024 17:40:34 +0000
Received: by outflank-mailman (input) for mailman id 858417;
 Mon, 16 Dec 2024 17: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 1tNF57-0002KF-Bj
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 17:40:33 +0000
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com
 [2a00:1450:4864:20::236])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d87efa06-bbd4-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 18:40:31 +0100 (CET)
Received: by mail-lj1-x236.google.com with SMTP id
 38308e7fff4ca-2ffa49f623cso54187771fa.1
 for ; Mon, 16 Dec 2024 09:40:31 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3034401ced1sm9949301fa.16.2024.12.16.09.40.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 16 Dec 2024 09:40: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: d87efa06-bbd4-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734370831; x=1734975631; darn=lists.xenproject.org;
        h=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=ADDGTTGFzOjt4E+s2bUznvpFAh6/ow/AK9pkcLFiubI=;
        b=iGmXJPO87HwKtLZ8J7DJVDJoKajXwJNpm7vMfuYLadb3Y4fgih1C/gaqZL/SXOIF6v
         t9O9IIgZJ7Nr1NPTtZK+qNLYwOsI8xU1axJf5RJbvn1q2jIt/c6+t1W2EyfXczl8/Cd+
         Hpu8Ro34MbVilVEk6gyuY/plIxDPZNtmOYl2JHu8h5sHuefxl8X0F89gGx9Mx1jRulWY
         F4w+xA8p8uCdVLq8FFiIgY74tKGkZ7XAW3gCPMT/5C3A04mly7eYxF8fc7ezP1Y0JM3Q
         dzKUGEDvsaCI4zfITdoICthUu6/D2r03GqJQpjXT7kJguvcpv9vzUjU7PVcgYDINbnZt
         UsNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734370831; x=1734975631;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=ADDGTTGFzOjt4E+s2bUznvpFAh6/ow/AK9pkcLFiubI=;
        b=wsFIe7GW/lmqoghJ9Q7n6RIr5GrAJnjpJdh2iDP6pBX3U+DEgVW2ywJTtgWPkSAa4A
         4/CFe3BeO66aOYhwTY+AoigSnme9NpEJnmCAeIQi7twm0lj3dRu4jpoNw4v6PakJnKL0
         O6E4t3bDRAMiqSAVNjJ6Hs9nrHEDUfxEANl947sI5od8rOOHq6lrBTIvqZ4AGMaWTSzr
         WMMFzMhT/1cMHbBoCkATOVomowth7rLmkAit6cNxAaZ1XmBHZbzDJEo9STbB2xJ71S3S
         9Tu2JjK+nFRfLCMFF1kNqrvtLguIUVWH2paHzAp0rc70vuQOg1fzrNgNc0wIyuwfpwt3
         Smpg==
X-Forwarded-Encrypted: i=1; AJvYcCWPa3Gs5I0qTuyi/eeegu57W/ZDbf1zd3IkDQwYnaz0IFktenX0z42lKQjPWxKZM7SoKkS16pcvkiE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwbwX9Ct9esfeqD5bYA7HWw/ORxsyQZPeK8ZmIUHlWneTWa/5+X
	4FTbEUadcSmcFSKtvNEGQh1Oug3Zkc6Yybn7bdBCmVE9KWnh+Q2P
X-Gm-Gg: ASbGnctMae0DyEZT9Aq2mwIfTQYTvinG2/jFxYelCzsn8Tr9wcNvnGRhBbWwUaujgBr
	pohUlXoHNa+E9WR7RM0qxE6iHchreaJetmnfOulr5JWxGOnZs3pt9ai+1vVrrjhQeaUokm6YFO8
	JeR4gCUIMyq5nS24k8K7pQgfgNxhz3a3n/3u28OAHH1Kb/HR6l17b+LfKMjd3sn3KQ18zFo8z+D
	f5QWRFechs9qGNVMzjnIUWDpqvZlMQJ9y0w5iTK83Ajv2Vj91JUd8+I+rk3AWC6/JKd4Q==
X-Google-Smtp-Source: AGHT+IFCBHBlQUh2TIVX4DemYik9xq+iV295GA273OyK0a/ppX/9hBR45NQISyN23QQ1KpAXOhI5xw==
X-Received: by 2002:a2e:a548:0:b0:2ff:bb68:4233 with SMTP id 38308e7fff4ca-302544cbb48mr59121311fa.33.1734370830533;
        Mon, 16 Dec 2024 09:40:30 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------dRqzdVVl9IHcSM567XfHN7ux"
Message-ID: <1c8c888e-bf59-4b4d-a3a5-cd2c0c7b6565@gmail.com>
Date: Mon, 16 Dec 2024 18:40:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/7] xen/riscv: implement data and instruction cache
 operations
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 
 <19c9ef65-a5bd-4d81-89dc-c780d3ead8b8@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <19c9ef65-a5bd-4d81-89dc-c780d3ead8b8@suse.com>

This is a multi-part message in MIME format.
--------------dRqzdVVl9IHcSM567XfHN7ux
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 12/16/24 3:23 PM, Jan Beulich wrote:
> On 11.12.2024 18:27, Oleksii Kurochko wrote:
>> --- a/xen/arch/riscv/include/asm/page.h
>> +++ b/xen/arch/riscv/include/asm/page.h
>> @@ -7,6 +7,7 @@
>>   
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   
>>   #include 
>> @@ -148,9 +149,27 @@ static inline bool pte_is_mapping(pte_t p)
>>       return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK);
>>   }
>>   
>> +static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
>> +{
>> +#ifdef CONFIG_QEMU
>> +    return 0;
>> +#else
>> +    return -EOPNOTSUPP;
>> +#endif
>> +}
>> +
>> +static inline int clean_dcache_va_range(const void *p, unsigned long size)
>> +{
>> +#ifdef CONFIG_QEMU
>> +    return 0;
>> +#else
>> +    return -EOPNOTSUPP;
>> +#endif
>> +}
> So testing on real hardware will then effectively become impossible, until
> someone goes and implements these?

Yes...

I am not sure what better we can do. It seems like it will be the best one to check if CMO
extensions is supported and use instructions for this extensions to implement these functions as they
are in the specification and not expected to be changed.

But I want to back a little bit later to this implemntation as this not issue for QEMU as it doesn't model cache and
h/w on which I can ask to run Xen has IO cache coherency so for it will be needed just to add a new config
and implementation will still be 'return 0'. ( I thought to introduce instead of CONFIG_QEMU something like
CONFIG_HAS_CACHE_COHERENCY )

And also in the spec it is mentioned:
```
This suggests that RISC-V platforms prefer to support full 
cache-coherent I/O, but it isn't actually mandatory.
As a result, the PMBT and CMO extensions aren't mandatory either, 
meaning that some platforms might not
have instructions to properly flush, clean, or invalidate the cache.
``` Based on that I also think to implement that in the following way:
```
     #ifdef CONFIG_QEMU
     static inline int plat_clean_and_invalidate_dcache_va_range() { return 0; }
   static inline int plat_clean_dcache_va_range() { return 0; }
   #else /* !CONFIG_QEMU */
     static inline void plat_clean_and_invalidate_dcache_va_range()
   {
     printk_once("%s: should it be implemented for your platform?\n", __func__);
     return 0;
   }

   static inline void plat_clean_dcache_va_range()
   {
     printk_once("%s: should it be implemented for your platform?\n", __func__);
     return 0;
   }
   #endif

   static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
   {
       return plat_clean_and_invalidate_dcache_va_range();
   }
....
```
So we will have a notification for others none-QEMU platforms notification that probably some
changes are required.

>
>> --- /dev/null
>> +++ b/xen/arch/riscv/platforms/Kconfig
>> @@ -0,0 +1,5 @@
>> +config QEMU
>> +	bool "QEMU aarch virt machine support"
>> +	depends on RISCV_64
> I understand Arm has it like this, but: Is QEMU really a sufficiently non-
> ambiguous name to use?

Yes, it sounds good to me to have such naming for the platform which are running on top of QEMU.

The other option I thought about it is to use CONFIG_VIRT_PLATFORM.

>   Is the RISCV_64 dependency really needed?

At the moment , we are testing only RISCV_64 so not to have none-verified config I added RISCV_64 but

probably it is too much and `depends on` should be dropped at all.

Thanks.

~ Oleksii

>
>> +	help
>> +	  Enable all the required drivers for QEMU riscv64 virt emulated machine.
> This line looks to be slightly too long now (after you apparently unwrapped
> what Arm has).
>
> Jan
--------------dRqzdVVl9IHcSM567XfHN7ux
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    
On 12/16/24 3:23 PM, Jan Beulich wrote:

    

    

      
On 11.12.2024 18:27, Oleksii Kurochko wrote:


      

        
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -7,6 +7,7 @@
 
 #include <xen/bug.h>
 #include <xen/const.h>
+#include <xen/errno.h>
 #include <xen/types.h>
 
 #include <asm/atomic.h>
@@ -148,9 +149,27 @@ static inline bool pte_is_mapping(pte_t p)
     return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK);
 }
 
+static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
+{
+#ifdef CONFIG_QEMU
+    return 0;
+#else
+    return -EOPNOTSUPP;
+#endif
+}
+
+static inline int clean_dcache_va_range(const void *p, unsigned long size)
+{
+#ifdef CONFIG_QEMU
+    return 0;
+#else
+    return -EOPNOTSUPP;
+#endif
+}


      

      
So testing on real hardware will then effectively become impossible, until
someone goes and implements these?

    

    
Yes...

I am not sure what better we can do. It seems like it will be the best one to check if CMO
extensions is supported and use instructions for this extensions to implement these functions as they
are in the specification and not expected to be changed. 

But I want to back a little bit later to this implemntation as this not issue for QEMU as it doesn't model cache and
h/w on which I can ask to run Xen has IO cache coherency so for it will be needed just to add a new config
and implementation will still be 'return 0'. ( I thought to introduce instead of CONFIG_QEMU something like
CONFIG_HAS_CACHE_COHERENCY )

And also in the spec it is mentioned:
```
This suggests that RISC-V platforms prefer to support full cache-coherent I/O, but it isn't actually mandatory.
As a result, the PMBT and CMO extensions aren't mandatory either, meaning that some platforms might not
have instructions to properly flush, clean, or invalidate the cache.
```

Based on that I also think to implement that in the following way:
```
    #ifdef CONFIG_QEMU
    static inline int plat_clean_and_invalidate_dcache_va_range() { return 0; }
  static inline int plat_clean_dcache_va_range() { return 0; }
  #else /* !CONFIG_QEMU */
    static inline void plat_clean_and_invalidate_dcache_va_range()
  {
    printk_once("%s: should it be implemented for your platform?\n", __func__);
    return 0;
  }

  static inline void plat_clean_dcache_va_range()
  {
    printk_once("%s: should it be implemented for your platform?\n", __func__);
    return 0;
  }
  #endif

  static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
  {
      return plat_clean_and_invalidate_dcache_va_range();
  }
....
```
So we will have a notification for others none-QEMU platforms notification that probably some
changes are required.


    

      



      

        
--- /dev/null
+++ b/xen/arch/riscv/platforms/Kconfig
@@ -0,0 +1,5 @@
+config QEMU
+	bool "QEMU aarch virt machine support"
+	depends on RISCV_64


      

      
I understand Arm has it like this, but: Is QEMU really a sufficiently non-
ambiguous name to use?

    

    
Yes, it sounds good to me to have such naming for the platform which are running on top of QEMU.

    
The other option I thought about it is to use CONFIG_VIRT_PLATFORM.



    

      
 Is the RISCV_64 dependency really needed?

    

    
At the moment , we are testing only RISCV_64 so not to have none-verified config I added RISCV_64 but

    
probably it is too much and `depends on` should be dropped at all.

Thanks.

~ Oleksii


    

      



      

        
+	help
+	  Enable all the required drivers for QEMU riscv64 virt emulated machine.


      

      
This line looks to be slightly too long now (after you apparently unwrapped
what Arm has).

Jan


    

  


--------------dRqzdVVl9IHcSM567XfHN7ux--


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 18:11:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 18:11:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858435.1270645 (Exim 4.92)
	(envelope-from )
	id 1tNFYa-0006jf-As; Mon, 16 Dec 2024 18:11:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858435.1270645; Mon, 16 Dec 2024 18:11:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNFYa-0006jY-8B; Mon, 16 Dec 2024 18:11:00 +0000
Received: by outflank-mailman (input) for mailman id 858435;
 Mon, 16 Dec 2024 18:10:59 +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 1tNFYY-0006jR-Va
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 18:10:59 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1763e6b3-bbd9-11ef-99a3-01e77a169b0f;
 Mon, 16 Dec 2024 19:10:56 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id DDDF38285957;
 Mon, 16 Dec 2024 12:10:53 -0600 (CST)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id P0J_JgFj_ghK; Mon, 16 Dec 2024 12:10:51 -0600 (CST)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 950F28286E56;
 Mon, 16 Dec 2024 12:10:51 -0600 (CST)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id 6W7QW7VkX1SO; Mon, 16 Dec 2024 12:10:51 -0600 (CST)
Received: from [10.11.0.2] (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id 1FD668285957;
 Mon, 16 Dec 2024 12:10:51 -0600 (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: 1763e6b3-bbd9-11ef-99a3-01e77a169b0f
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 950F28286E56
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1734372651; bh=lPPk6R6rdL6JixBNW3JHNMX+w5zgsjUn60i4BqLYnpk=;
	h=Message-ID:Date:MIME-Version:To:From;
	b=Dz5TzI4/ZCgb9jyFXiFpWMHkpG3wOhlYmtA+sAc5lCZpQ+cs8HZssw/2hTa1uJZxP
	 UE/7Xvz3f9EriT/H7+5l139XP/1d+7Esa92Aeow/2BTeqVnsYYs9l2AkakUdhzM/Ye
	 vrRF9F/xx9CmDEdYmfrYHERFjfbhCkc9QKoMykE8=
X-Virus-Scanned: amavisd-new at rptsys.com
Message-ID: 
Date: Mon, 16 Dec 2024 12:10:49 -0600
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] xen/device-tree: Allow region overlapping with
 /memreserve/ ranges
To: Luca Fancellu , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini , Julien Grall
 , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Grygorii Strashko 
References: <20241114102802.54512-1-luca.fancellu@arm.com>
Content-Language: en-US
From: Shawn Anastasio 
In-Reply-To: <20241114102802.54512-1-luca.fancellu@arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi Luca,

On 11/14/24 4:28 AM, Luca Fancellu wrote:
> There are some cases where the device tree exposes a memory range
> in both /memreserve/ and reserved-memory node, in this case the
> current code will stop Xen to boot since it will find that the
> latter range is clashing with the already recorded /memreserve/
> ranges.
> 
> Furthermore, u-boot lists boot modules ranges, such as ramdisk,
> in the /memreserve/ part and even in this case this will prevent
> Xen to boot since it will see that the module memory range that
> it is going to add in 'add_boot_module' clashes with a /memreserve/
> range.
> 
> When Xen populate the data structure that tracks the memory ranges,
> it also adds a memory type described in 'enum membank_type', so
> in order to fix this behavior, allow overlapping with the /memreserve/
> ranges in the 'check_reserved_regions_overlap' function when a flag
> is set.
> 
> In order to implement this solution, there is a distinction between
> the 'struct membanks *' handled by meminfo_overlap_check(...) that
> needs to be done, because the static shared memory banks doesn't have
> a usable bank[].type field and so it can't be accessed, hence now
> the 'struct membanks_hdr' have a 'enum region_type type' field in order
> to be able to identify static shared memory banks in meminfo_overlap_check(...).
> 
> While there, set a type for the memory recorded using meminfo_add_bank()
> from efi-boot.h.
> 
> Fixes: 53dc37829c31 ("xen/arm: Add DT reserve map regions to bootinfo.reserved_mem")
> Reported-by: Shawn Anastasio 
> Reported-by: Grygorii Strashko 
> Signed-off-by: Luca Fancellu 

Sorry for the late response on this and I know it has already gone in,
but I just wanted to confirm that this fixes the original issue I
observed with overlapping regions in skiboot's generated DT.

Thanks!


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 18:18:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 18:18:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858448.1270662 (Exim 4.92)
	(envelope-from )
	id 1tNFfw-0007S1-3c; Mon, 16 Dec 2024 18:18:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858448.1270662; Mon, 16 Dec 2024 18: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 1tNFfw-0007Ru-13; Mon, 16 Dec 2024 18:18:36 +0000
Received: by outflank-mailman (input) for mailman id 858448;
 Mon, 16 Dec 2024 18:18: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 1tNFfv-0007Ro-9D
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 18:18:35 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 28f15d56-bbda-11ef-a0d6-8be0dac302b0;
 Mon, 16 Dec 2024 19:18:34 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 30A498287C30;
 Mon, 16 Dec 2024 12:18:33 -0600 (CST)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id SWYXOXURHFcH; Mon, 16 Dec 2024 12:18:32 -0600 (CST)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 92B6A828563F;
 Mon, 16 Dec 2024 12:18:32 -0600 (CST)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id bMVIlAUYrnsQ; Mon, 16 Dec 2024 12:18:32 -0600 (CST)
Received: from [10.11.0.2] (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id 0D8278287CC1;
 Mon, 16 Dec 2024 12:18:31 -0600 (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: 28f15d56-bbda-11ef-a0d6-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 92B6A828563F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1734373112; bh=ZUBA9xVH4Gb4+YZ4FUbwwstEbbkfAHB0EOf5IYdZhzY=;
	h=Message-ID:Date:MIME-Version:To:From;
	b=fMNsfceqWTUS5IBIeuBSFX2YYHdtjn+ToeGlAtAMmRF4MnbIR2jxSXQRIckDIlfpa
	 F7qSkxusIu1arkwPiSITYLHesy2NJma0garog9unRfpfzBZSYqE3voBnivn5UQ3j1B
	 1qjnUQToFrV9MzSyV7Z2zlTDQW2Zd7Onz+Z/+6yw=
X-Virus-Scanned: amavisd-new at rptsys.com
Message-ID: <1283bff8-b890-45a4-a817-198c15649fd7@raptorengineering.com>
Date: Mon, 16 Dec 2024 12:18:29 -0600
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 3/3] xen/ppc: mm-radix: Allocate all paging structures
 at runtime
To: Jan Beulich 
Cc: tpearson@raptorengineering.com, xen-devel@lists.xenproject.org
References: 
 
 <801c913a-d915-4dd0-9ed2-f89c6717b1cb@suse.com>
Content-Language: en-US
From: Shawn Anastasio 
In-Reply-To: <801c913a-d915-4dd0-9ed2-f89c6717b1cb@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi Jan,

On 9/30/24 10:20 AM, Jan Beulich wrote:
> On 27.09.2024 00:24, Shawn Anastasio wrote:
>> In the initial mm-radix implementation, the in-memory partition and
>> process tables required to configure the MMU, as well as the page tables
>> themselves were all allocated statically since the boot allocator was
>> not yet available.
>>
>> Now that it is, allocate these structures at runtime and bump the size
>> of the Process Table to its maximum supported value (on POWER9).
>>
>> Signed-off-by: Shawn Anastasio 
> 
> On the assumption that the (theoretical only?) case of there being gaps
> in [min_alloc_mfn,max_alloc_mfn] if deemed okay, with it being just more
> memory being mapped in such a case:
> Acked-by: Jan Beulich 

Sorry for the late response on this. Your assumption is correct -- in
the case that there are gaps in the allocated region, it will just
result in more memory than is strictly necessary being mapped, and given
the constraints here I'm fine with that tradeoff.

> Jan

Thanks,
Shawn


From xen-devel-bounces@lists.xenproject.org Mon Dec 16 20:06:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 20:06:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858463.1270673 (Exim 4.92)
	(envelope-from )
	id 1tNHLg-0003Sw-Gg; Mon, 16 Dec 2024 20:05:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858463.1270673; Mon, 16 Dec 2024 20: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 1tNHLg-0003Sp-Do; Mon, 16 Dec 2024 20:05:48 +0000
Received: by outflank-mailman (input) for mailman id 858463;
 Mon, 16 Dec 2024 20:05:47 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1tNHLf-0003Sj-HA
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 20:05:47 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1tNHLe-006UKT-2U;
 Mon, 16 Dec 2024 20:05:47 +0000
Received: from [82.144.38.251] (helo=[172.20.15.232])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1tNHLe-00Beu4-2e;
 Mon, 16 Dec 2024 20:05: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=J6I8O2KdoJORnaTNtLWh3Ofd6xfbZLrD6Vu54ZZ1BnQ=; b=ryzy3l+7WPM7n7PP5QWdCZrBqS
	TrKokkrEwWmOLntE8QVYILKX5bQSiJ0KYHGXg1WWkgzgveZGFcqOGSiG5FGDl/ElijXBiYeWPWpwG
	21dDkYTfUw6UmIciW4RjlN1TZj4yns3+GHm4Ytt8baxxeRQj4MqbKOjAfeeOXEVFiWT8=;
Message-ID: <38870638-6d87-4a0d-843d-37cc55bb54a9@xen.org>
Date: Mon, 16 Dec 2024 21:05:44 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 04/10] xen/arm: ffa: Fine granular call support
Content-Language: en-GB
To: Bertrand Marquis 
Cc: "xen-devel@lists.xenproject.org" ,
 "jens.wiklander@linaro.org" ,
 Volodymyr Babchuk ,
 Stefano Stabellini ,
 Michal Orzel 
References: 
 <1b02c9c1df9ff2230e076f25398a5de876f98a51.1732702210.git.bertrand.marquis@arm.com>
 <8d8ef7f9-d73f-4ff8-8af9-4e73cda97624@xen.org>
 <03D53BB9-1751-42DF-9AAD-41B25E915027@arm.com>
From: Julien Grall 
In-Reply-To: <03D53BB9-1751-42DF-9AAD-41B25E915027@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 16/12/2024 08:06, Bertrand Marquis wrote:
> Hi Julien,

Hi Bertrand,

>> On 13 Dec 2024, at 23:57, Julien Grall  wrote:
>>
>> Hi Bertrand,
>>
>> On 27/11/2024 16:07, Bertrand Marquis wrote:
>>> Create a bitmap to store which feature is supported or not by the
>>> firmware and use it to filter which calls are done to the firmware.
>>> While there reoder ABI definition by numbers to easily find the min and
>>
>> Typo (I can fix it while committing): s/reoder/reorder
> 
> Thanks for the finding.
> Please fix on commit if that is ok for you.
> 
> There are also 2 minor findings on the patch 7 that could be fixed on commit.

I think I fixed all the minor findings and it is now committed.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 23:12:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 23:12:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858487.1270733 (Exim 4.92)
	(envelope-from )
	id 1tNKFk-0007xl-0A; Mon, 16 Dec 2024 23:11:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858487.1270733; Mon, 16 Dec 2024 23:11: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 1tNKFj-0007xe-Sw; Mon, 16 Dec 2024 23:11:51 +0000
Received: by outflank-mailman (input) for mailman id 858487;
 Mon, 16 Dec 2024 23:11: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 1tNKFj-0007ir-1L
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 23:11:51 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 216e6bec-bc03-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 00:11:50 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 17 Dec 2024 00:11:50 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id 097E82EAD;
 Tue, 17 Dec 2024 00:11:50 +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: 216e6bec-bc03-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734390710; x=1765926710;
  h=from:to:cc:subject:date:message-id:in-reply-to:
   references:mime-version:content-transfer-encoding;
  bh=EAV3EgAj1GYsZmin1Xq2+9I5AZcWLnfwtgtwG2gVjYg=;
  b=IrZPj1cCGpaJot7reh5OjbrUGmMMLt+TisnAzE4O3r8eXTbXqNvYQS9X
   iYsK4MuHs8sjZxfoyEGnKdNQReYsaG3TxzVuOsyZ7kdTlO4H+8FcM4AIm
   f1cB8AaapBNylbRxxjg2HrlqtsB7q02/1UWmbDExRtkYB1zIRm7fQyrNs
   w=;
X-CSE-ConnectionGUID: 0BvNt6iFQOyKj1wBH835hw==
X-CSE-MsgGUID: VLier6ySR0GDCknW79bYLA==
X-IronPort-AV: E=Sophos;i="6.12,240,1728943200"; 
   d="scan'208";a="28208512"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Anthony PERARD ,
	Andrew Cooper ,
	Ariel Otilibili ,
	Luca Fancellu 
Subject: [PATCH v2 1/1] tools, xen/scripts: clear out Python syntax warnings
Date: Tue, 17 Dec 2024 00:07:20 +0100
Message-ID: <20241216231128.211648-2-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20241216231128.211648-1-Ariel.Otilibili-Anieli@eurecom.fr>
References: <20241214161350.70515-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216231128.211648-1-Ariel.Otilibili-Anieli@eurecom.fr>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

* since 3.12 invalid escape sequences generate SyntaxWarning
* in the future, these invalid sequences will generate SyntaxError
* therefore changed syntax to raw string notation.

Link: https://docs.python.org/3/whatsnew/3.12.html#other-language-changes
Fixes: d8f3a67bf98 ("pygrub: further improve grub2 support")
Fixes: dd03048708a ("xen/pygrub: grub2/grub.cfg from RHEL 7 has new commands in menuentry")
Fixes: d1b93ea2615 ("tools/pygrub: Make pygrub understand default entry in string format")
Fixes: 622e368758b ("Add ZFS libfsimage support patch")
Fixes: 02b26c02c7c ("xen/scripts: add cppcheck tool to the xen-analysis.py script")
Fixes: 56c0063f4e7 ("xen/misra: xen-analysis.py: Improve the cppcheck version check")

Cc: Anthony PERARD 
Cc: Luca Fancellu 
Cc: Andrew Cooper 
Signed-off-by: Ariel Otilibili 
---
 tools/pygrub/src/GrubConf.py                  | 4 ++--
 tools/pygrub/src/pygrub                       | 6 +++---
 xen/scripts/xen_analysis/cppcheck_analysis.py | 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/GrubConf.py
index 580c9628ca..904e7d5567 100644
--- a/tools/pygrub/src/GrubConf.py
+++ b/tools/pygrub/src/GrubConf.py
@@ -320,7 +320,7 @@ class GrubConfigFile(_GrubConfigFile):
 def grub2_handle_set(arg):
     (com,arg) = grub_split(arg,2)
     com="set:" + com
-    m = re.match("([\"\'])(.*)\\1", arg)
+    m = re.match(r"([\"\'])(.*)\1", arg)
     if m is not None:
         arg=m.group(2)
     return (com,arg)
@@ -402,7 +402,7 @@ class Grub2ConfigFile(_GrubConfigFile):
                 continue
 
             # new image
-            title_match = re.match('^menuentry ["\'](.*?)["\'] (.*){', l)
+            title_match = re.match(r'^menuentry ["\'](.*?)["\'] (.*){', l)
             if title_match:
                 if img is not None:
                     raise RuntimeError("syntax error: cannot nest menuentry (%d %s)" % (len(img),img))
diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub
index 9d51f96070..e1657c494b 100755
--- a/tools/pygrub/src/pygrub
+++ b/tools/pygrub/src/pygrub
@@ -614,7 +614,7 @@ class Grub:
             title = self.cf.default
             while 1:
                 try:
-                    title = re.search('(\S)>(\S.+$)',title).group(2)
+                    title = re.search(r'(\S)>(\S.+$)',title).group(2)
                 except AttributeError:
                     break
 
@@ -1039,7 +1039,7 @@ if __name__ == "__main__":
 
     # if boot filesystem is set then pass to fsimage.open
     bootfsargs = '"%s"' % incfg["args"]
-    bootfsgroup = re.findall('zfs-bootfs=(.*?)[\s\,\"]', bootfsargs)
+    bootfsgroup = re.findall(r'zfs-bootfs=(.*?)[\s\,\"]', bootfsargs)
     if bootfsgroup:
         bootfsoptions = bootfsgroup[0]
     else:
@@ -1104,7 +1104,7 @@ if __name__ == "__main__":
     if chosencfg["args"]:
         zfsinfo = xenfsimage.getbootstring(fs)
         if zfsinfo is not None:
-            e = re.compile("zfs-bootfs=[\w\-\.\:@/]+" )
+            e = re.compile(r"zfs-bootfs=[\w\-.:@/]+" )
             (chosencfg["args"],count) = e.subn(zfsinfo, chosencfg["args"])
             if count == 0:
                chosencfg["args"] += " -B %s" % zfsinfo
diff --git a/xen/scripts/xen_analysis/cppcheck_analysis.py b/xen/scripts/xen_analysis/cppcheck_analysis.py
index 850335c998..ce7bda91b6 100644
--- a/xen/scripts/xen_analysis/cppcheck_analysis.py
+++ b/xen/scripts/xen_analysis/cppcheck_analysis.py
@@ -93,7 +93,7 @@ def __generate_suppression_list(out_file):
                         # start of a comment '/*'
                         comment_line_starts = re.match('^[ \t]*/\*.*$', line)
                         # Matches a line with text and the end of a comment '*/'
-                        comment_line_stops = re.match('^.*\*/$', line)
+                        comment_line_stops = re.match(r'^.*\*/$', line)
                         if (not comment_section) and comment_line_starts:
                             comment_section = True
                         if (len(line.strip()) != 0) and (not comment_section):
@@ -157,7 +157,7 @@ def generate_cppcheck_deps():
             "Error occured retrieving cppcheck version:\n{}\n\n{}"
         )
 
-    version_regex = re.search('^Cppcheck (\d+)\.(\d+)(?:\.\d+)?$',
+    version_regex = re.search(r'^Cppcheck (\d+)\.(\d+)(?:\.\d+)?$',
                               invoke_cppcheck, flags=re.M)
     # Currently, only cppcheck version >= 2.7 is supported, but version 2.8 is
     # known to be broken, please refer to docs/misra/cppcheck.txt
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 23:12:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 23:12:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858486.1270723 (Exim 4.92)
	(envelope-from )
	id 1tNKFg-0007jW-Oq; Mon, 16 Dec 2024 23:11:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858486.1270723; Mon, 16 Dec 2024 23:11: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 1tNKFg-0007jP-Lg; Mon, 16 Dec 2024 23:11:48 +0000
Received: by outflank-mailman (input) for mailman id 858486;
 Mon, 16 Dec 2024 23:11: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 1tNKFf-0007ir-PE
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 23:11:48 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1ec92c59-bc03-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 00:11:46 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 17 Dec 2024 00:11:45 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id 6034A2EAC;
 Tue, 17 Dec 2024 00:11:45 +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: 1ec92c59-bc03-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734390706; x=1765926706;
  h=from:to:cc:subject:date:message-id:in-reply-to:
   references:mime-version:content-transfer-encoding;
  bh=V5URqsWiKz9IlhLRYMp2ttrU4Ct57oJxcjdineMJgC0=;
  b=yGuygpw6vTINiwOHuEFElbtQrOIYrLRo7+wHTO0aG1z1crWEfkBlzJbK
   4dkprCirfh9u6phjtUAbJ2IKwTKz9Y7UcT4lsXmHxOiNqJXvkMCAkO8Rw
   V+VYpkad//fln+yaHM38tuNoXH9eq7t9Ew0vefrfmxLtPnNvWek6yVgu8
   o=;
X-CSE-ConnectionGUID: QJNWtmNsTWO5grxRlsaEHg==
X-CSE-MsgGUID: RvAxfPP2RGuiFAJfolEKlw==
X-IronPort-AV: E=Sophos;i="6.12,240,1728943200"; 
   d="scan'208";a="28208510"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Anthony PERARD ,
	Andrew Cooper ,
	Ariel Otilibili 
Subject: [PATCH v2 0/1] tools, xen/scripts: clear out Python syntax warnings
Date: Tue, 17 Dec 2024 00:07:19 +0100
Message-ID: <20241216231128.211648-1-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20241214161350.70515-1-Ariel.Otilibili-Anieli@eurecom.fr>
References: <20241214161350.70515-1-Ariel.Otilibili-Anieli@eurecom.fr>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hello,

The series clears out Python syntax warnings. In all occurrences of the re methods,

```
$ git grep -Pn '[^\w_]re\.[a-z]+' | wc -l 
69
```

Where it was needed, the strings have been quoted as raw.

Thank you,
--
v2:
* tools/misc/xensymoops got removed (2e955d2554, "tools/misc: Drop xensymoops")
* refined regexes (https://lore.kernel.org/all/49497f8c-a2e4-49a1-aac0-96d704834f0f@citrix.com/)

Ariel Otilibili (1):
  tools, xen/scripts: clear out Python syntax warnings

 tools/pygrub/src/GrubConf.py                  | 4 ++--
 tools/pygrub/src/pygrub                       | 6 +++---
 xen/scripts/xen_analysis/cppcheck_analysis.py | 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 23:53:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 23:53:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858506.1270743 (Exim 4.92)
	(envelope-from )
	id 1tNKtY-0004wj-M8; Mon, 16 Dec 2024 23:53:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858506.1270743; Mon, 16 Dec 2024 23:53: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 1tNKtY-0004wc-J9; Mon, 16 Dec 2024 23:53:00 +0000
Received: by outflank-mailman (input) for mailman id 858506;
 Mon, 16 Dec 2024 23:52:59 +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 1tNKtX-0004wR-8p
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 23:52:59 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id df5cc433-bc08-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 00:52:56 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 17 Dec 2024 00:52:56 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id 0D04E2EB6;
 Tue, 17 Dec 2024 00:52:55 +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: df5cc433-bc08-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734393177; x=1765929177;
  h=from:to:cc:subject:date:message-id:in-reply-to:
   references:mime-version:content-transfer-encoding;
  bh=0osHsDjGzamRjT1vneg1SKdE21qpRB7e2KIKWndfjbU=;
  b=HA/4oJClPnJl9dyjJFLj/NiYQ5wC40VAsTmC+wC3X7Qf4V/l/X9OwC0Y
   1YetgVb7RUnc71hUbn6484e8R+NoLstx4cMSnNdakiKWnfql/A+VopnCM
   hc5KNKUOADZd8Z8aqSCpAPJqtcZJRWDaX/pozH5YqGfWVG+GNbv99Mozg
   M=;
X-CSE-ConnectionGUID: exDUVaK+SmiDGWiOPU2plw==
X-CSE-MsgGUID: gtqPjUFOSJypxX1LeVfDlg==
X-IronPort-AV: E=Sophos;i="6.12,240,1728943200"; 
   d="scan'208";a="28208688"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Anthony PERARD ,
	Ariel Otilibili 
Subject: [PATCH v2 0/1] tools/libacpi: clear ASL warning about PCI0
Date: Tue, 17 Dec 2024 00:50:24 +0100
Message-ID: <20241216235241.217642-1-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20241215154659.151158-1-Ariel.Otilibili-Anieli@eurecom.fr>
References: <20241215154659.151158-1-Ariel.Otilibili-Anieli@eurecom.fr>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hello,

This patch clears out an ASL warning; below is listed my configuration.

Your feedback is much appreciated.

Thank you,

```
$ iasl -v

Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20240927
Copyright (c) 2000 - 2023 Intel Corporation

$ gcc --version 
gcc (GCC) 14.2.1 20240910
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ uname -a
Linux arc 6.12.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Mon, 09 Dec 2024 14:31:57 +0000 x86_64 GNU/Linux
```
--
v2:
* stated reasons why the changes should be backward compatible
* see, https://lore.kernel.org/all/7f30f105-e13e-4e41-b432-82f9c12760d9@suse.com/

Ariel Otilibili (1):
  tools/libacpi: clear ASL warning about PCI0

 tools/libacpi/dsdt.asl | 1 -
 1 file changed, 1 deletion(-)

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Mon Dec 16 23:53:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Dec 2024 23:53:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858507.1270752 (Exim 4.92)
	(envelope-from )
	id 1tNKtZ-0005Ah-SW; Mon, 16 Dec 2024 23:53:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858507.1270752; Mon, 16 Dec 2024 23:53:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNKtZ-0005Aa-PZ; Mon, 16 Dec 2024 23:53:01 +0000
Received: by outflank-mailman (input) for mailman id 858507;
 Mon, 16 Dec 2024 23:53: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 1tNKtY-0004wR-DN
 for xen-devel@lists.xenproject.org; Mon, 16 Dec 2024 23:53:00 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e0be2027-bc08-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 00:52:58 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 17 Dec 2024 00:52:59 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id 57B8E2EB7;
 Tue, 17 Dec 2024 00:52:58 +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: e0be2027-bc08-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734393179; x=1765929179;
  h=from:to:cc:subject:date:message-id:in-reply-to:
   references:mime-version:content-transfer-encoding;
  bh=wsuAFQksUReamPBle/EzWnEkgLkOUKoKn+XJSAZOxeU=;
  b=C3EgGv/HW/wkUNWmb0R8XG5x4Ir/kgIgtKHQDHA52LAr30KiQBYro4kT
   gYACim/YvuNgFTbV/2CsaAWizTaEwtDmhvZ9Fl/UmzPK0i8tKjK67eV31
   c+pel1QMBLN1/pc54RrW85uMLi86e9tA1nHgWe9sy0qH6KuB4MC8OPSIz
   U=;
X-CSE-ConnectionGUID: v7LBfRqdRH25XXAOgTDV4Q==
X-CSE-MsgGUID: qAkoC3LxQDuHZzA0HBScIQ==
X-IronPort-AV: E=Sophos;i="6.12,240,1728943200"; 
   d="scan'208";a="28208689"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Anthony PERARD ,
	Ariel Otilibili 
Subject: [PATCH v2 1/1] tools/libacpi: clear ASL warning about PCI0
Date: Tue, 17 Dec 2024 00:50:25 +0100
Message-ID: <20241216235241.217642-2-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20241216235241.217642-1-Ariel.Otilibili-Anieli@eurecom.fr>
References: <20241215154659.151158-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216235241.217642-1-Ariel.Otilibili-Anieli@eurecom.fr>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

iasl complains _HID and _ADR cannot be used at the same time:

```
/usr/bin/iasl -vs -p tools/firmware/hvmloader/dsdt_anycpu.tmp -tc tools/firmware/hvmloader/dsdt_anycpu.asl 2>&1 | grep -B10 HID

tools/firmware/hvmloader/dsdt_anycpu.asl     40:        Device (PCI0)
Warning  3073 -                                    Multiple types ^  (Device object requires either a _HID or _ADR, but not both)
```

Per ACPI 2.0 (Jul. 27, 2000; Section 6.1, page 146), the configuration was legit:

"A device object must contain either an _HID object or an _ADR object,
but can contain both." [1]

But, per ACPI 6.5 (Aug. 2022), this is no more legit:

"A device object must contain either an _HID object or an _ADR object,
but must not contain both." [2]

Generally _HID devices are enumerated and have their drivers loaded
by ACPI ("ASL 2.0 Introduction and Overview", page 4).

Removing _ADR, the warning is cleared out.

The change should be compatible down to OSes released after ACPI 2.0,
including Windows XP:

1. The _HID kept in the DSDT files is the EISA ID "PNP0A03",
Microsoft recognizes it as PCI bus:

```
$ curl -k -s https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/devids.txt | grep PNP0A

PNP0A00         ISA Bus
PNP0A01         EISA Bus
PNP0A02         MCA Bus
PNP0A03         PCI Bus
PNP0A04         VESA/VL Bus
PNP0A05         Generic ACPI Bus
PNP0A06         Generic ACPI Extended-IO Bus (EIO bus)
```

2. Linux 6.12 uses also _HID for identifying PCI devices [3]:

```
$ cat /sys/firmware/acpi/tables/DSDT > dsdt.dat
$ iasl -v

Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20240927
Copyright (c) 2000 - 2023 Intel Corporation

$ iasl -d dsdt.dat 2>/dev/null

Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20240927
Copyright (c) 2000 - 2023 Intel Corporation

$ grep PNP0A03 -B3 dsdt.dsl
        Device (PCI0)
        {
            Name (_HID, EisaId ("PNP0A08") /* PCI Express Bus */)  // _HID: Hardware ID
            Name (_CID, EisaId ("PNP0A03") /* PCI Bus */)  // _CID: Compatible ID
```

[1] https://uefi.org/sites/default/files/resources/ACPI_2.pdf
[2] https://uefi.org/specs/ACPI/6.5/06_Device_Configuration.html?highlight=_hid#device-identification-objects
[3] https://www.infradead.org/~mchehab/kernel_docs/firmware-guide/acpi/namespace.html

Link: https://www.intel.com/content/www/us/en/developer/topic-technology/open/acpica/documentation.html
Fixes: a5da231f56268702ba9d9e0c4f1ad7156446e77b
Cc: Jan Beulich 
Cc: Anthony PERARD 
Signed-off-by: Ariel Otilibili 
---
 tools/libacpi/dsdt.asl | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/libacpi/dsdt.asl b/tools/libacpi/dsdt.asl
index 32b42f85ae..9d50578e98 100644
--- a/tools/libacpi/dsdt.asl
+++ b/tools/libacpi/dsdt.asl
@@ -41,7 +41,6 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
        {
            Name (_HID, EisaId ("PNP0A03"))
            Name (_UID, 0x00)
-           Name (_ADR, 0x00)
            Name (_BBN, 0x00)
 
            /* Make cirrues VGA S3 suspend/resume work in Windows XP/2003 */
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 05:53:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 05:53:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858531.1270763 (Exim 4.92)
	(envelope-from )
	id 1tNQWL-000350-6Q; Tue, 17 Dec 2024 05:53:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858531.1270763; Tue, 17 Dec 2024 05:53: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 1tNQWL-00034t-2p; Tue, 17 Dec 2024 05:53:25 +0000
Received: by outflank-mailman (input) for mailman id 858531;
 Tue, 17 Dec 2024 05:53: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 1tNQWJ-00034l-S0
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 05:53:24 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on20612.outbound.protection.outlook.com
 [2a01:111:f403:2405::612])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 384ed372-bc3b-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 06:53:21 +0100 (CET)
Received: from IA1PR12MB6532.namprd12.prod.outlook.com (2603:10b6:208:3a3::12)
 by CH3PR12MB9022.namprd12.prod.outlook.com (2603:10b6:610:171::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.22; Tue, 17 Dec
 2024 05:53:16 +0000
Received: from IA1PR12MB6532.namprd12.prod.outlook.com
 ([fe80::dc05:a63a:39fa:ff0b]) by IA1PR12MB6532.namprd12.prod.outlook.com
 ([fe80::dc05:a63a:39fa:ff0b%7]) with mapi id 15.20.8251.015; Tue, 17 Dec 2024
 05:53: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: 384ed372-bc3b-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=g6n+44GswTyA57dJlTcX/rn8/lKqzQ0SEOEdkJ12GVdwb/PFFgUKXbuQZjJ0yiggG5nqXOryrZo6ZOoP+gUHqXF5WgbQPSww3Q/lZJS73xoA2/JF43yolg9kcKWHK6PCEIYjSiTKiO0vJTg2dP9MjaNlXHauGtRkyNUetU8X7WWUUiGI8xEjVAFc2pF9MGPFImC9Zaxs50vHu6uZYhkTbT8OI218wwucQbhpeFx38JeG6Jks1weZHD/5FDnOgdxAcSwrMa5wvX/dQpyLlBaCHA+AmkwjIfr2wtqCh6zyrQluvIYDp0kSqhJ0zTOQF1LNjqTzrqXvxnjpJBHyxWupWw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kQjo+foXW4GrxqAlNn9I1avTjrdIPXkP5vixCW4C/ro=;
 b=IcHUGO/vJHOUVJYpUvyRJ4zmzXwjbxhEy/QXpvi/SWpTZtX8b1NsTow0YjA2d8DyoFqsD2Y2sewbz78pk/Dt1AZ+tglSTgOjmxZH/HHvOCYVHPKZRdP+ofWX3+m93pA8rX9ZY6muclmjWRaSOoQEdJ8HqCyN5IE8AaklY0BXx7mlesHROk1+o6J1Ha0vEhKXmuVSDHizdlMYHb36Zlr4vHrDw4/If/NmyaAj95AXhn5WpoqBG4EVisOQPIeEYcDvrN3Vcq/uk4fEfo6a+b3ILSmFDsYjAsV4Fy6xDhzGBuiY6BOzZvFnQA+8bqOnzTiELHl9pKzVij+M6ftw70SGwA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=kQjo+foXW4GrxqAlNn9I1avTjrdIPXkP5vixCW4C/ro=;
 b=iXdHf57FPSsu54/vUIFN99o8c+VjDDbUbYzBaAvB9TZlYP3Q9w0O9CElQdwFBNjVdF/TNEhCKj/guOGcTrKd8sx47A6AqwYJLaYX2no4oLAPBicoinkeTFO9IXnmgoClKVrDxPvI5kLyTvYIqsFY0FoUYfCwZqrjiP6J0+o6/Tw=
From: "Zhang, Julia" 
To: Jan Beulich 
CC: "Deucher, Alexander" , "Koenig, Christian"
	, Xenia Ragiadakou , "Chen,
 Jiqian" , "Huang, Ray" , "Penny,
 Zheng" , "Zhu, Lingshan" , Paul
 Durrant , "Edgar E . Iglesias" ,
	"Michael S . Tsirkin" , Marcel Apfelbaum
	, Juergen Gross , Oleksandr
 Tyshchenko , Anthony PERARD
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "xen-devel@lists.xenproject.org"
	, Stefano Stabellini 
Subject: Re: [PATCH] xen: add privcmd ioctl to get p2pdma_distance
Thread-Topic: [PATCH] xen: add privcmd ioctl to get p2pdma_distance
Thread-Index: AQHbSJdDNMdfRsD4vkSvz8Ngpfn4L7LdjBaAgAuOxQD//4svAIAB3fOA
Date: Tue, 17 Dec 2024 05:53:16 +0000
Message-ID:
 
References: <20241207105946.542491-1-julia.zhang@amd.com>
 <03504a1e-c801-47fc-ac66-ab7e10ab6695@suse.com>
 
 <0284d807-ae85-4d43-93b5-91fb29528d62@suse.com>
In-Reply-To: <0284d807-ae85-4d43-93b5-91fb29528d62@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: IA1PR12MB6532.namprd12.prod.outlook.com
 (15.20.8251.004)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: IA1PR12MB6532:EE_|CH3PR12MB9022:EE_
x-ms-office365-filtering-correlation-id: 71e947d3-6300-4dc0-5f86-08dd1e5f1a0f
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|1800799024|376014|7416014|366016|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?ZEgxTTNvUHJSM040ci9DSk9YVVgrZkNCV3d5bmRMdzhkTlExZzBrb2c5ZURz?=
 =?utf-8?B?U25CRW0xVVdlQ210d3Vnb09GS2FZZHg1aG91cGRCT2dYRTVYU1RwQVpTSmNq?=
 =?utf-8?B?bkx2aitHeElsMFZvaUpCSVg0YkE4Z3F5Z1dQSkJ2bVZYdW9vRytEa0hCeTNH?=
 =?utf-8?B?bGNrR1RhQnV1QURFZlZRNTZBeEVNcFJFcnBrZ01TdHhpek1zYzNNZTVKWHNT?=
 =?utf-8?B?NGxpWHRKemlGM05wbjdBbUpkVCtrMDVhRm9iSjBpaFphUUN0Q0Zta21TTXZ1?=
 =?utf-8?B?aCtVeWZaSVpHNlNsdStTdEdSVDJQUjByZUY2ZDl1Rk9RelFBU1NQaUtnakIv?=
 =?utf-8?B?OHplVG5Fa2ltbVB5QUhQTUg0UVJnRHoyNmNKV0lnZ3VaaWFXM1A2V3hLU2Fz?=
 =?utf-8?B?cDJIcVNmWUdVRHRrdWZwYTkvTHl1WHNQTFJBMDhwZmtqR3Y2TTNBT1I4Um5r?=
 =?utf-8?B?SXM0bUNNVFdYbFJSYi9Id0RNeHF3Q3BlZmxGUzdadTByY3dQVEFXSjM1UGNR?=
 =?utf-8?B?YWFzaDR4cVBDcDIyUFcyaVAxZm1mdVZYMG9EY3A1RWNOTVZBdlkySE1FZHBP?=
 =?utf-8?B?WlhLMWlBSXZBRjQvZzdRM2QzaEpJTkpjN2l1TXlHT2w4ZjJqb1NjeEFEOGR5?=
 =?utf-8?B?cmJVTXQ1Y2wxTjZRbVVLaEtyZ3JzTHpvNUNSZ24wZ1FIUHcrOVoxVmxFV3l0?=
 =?utf-8?B?b1JuR3VYUzZwZS9rVnpUNzRsVHhyRUN1cDl4amFxQzl5UnVSTWltZFhnZU5E?=
 =?utf-8?B?OGJVRDFGS241NFk0QmUvbkVwQzNCb3g4R2wzRFNQZDVMSXJFV1lHYkVYYUpE?=
 =?utf-8?B?bk1xRkZOejFmSGdjWHp5NTNIbGl2L2V5M01zVGVJVVN6OHVmZkwrYWgxSy9M?=
 =?utf-8?B?ZXNHWElaeXFQR1lWRGQ4T0FtUDA5YStlWEVlR1RqSnl1L1pBbDg1Q0hGTjNy?=
 =?utf-8?B?VTZYcEV1bGJwTEEyTGQ2OEIrd1FDNmpnQ0F1aE91N243eWpkUFRZeDAwbWh4?=
 =?utf-8?B?ZFFQVHBKWGJZRGxsU3c3Q20yczEvL3pZS3g0VndGM08weTBMK0lJcUZuUUtY?=
 =?utf-8?B?cmpMOGN3dU5SZ20yV1lFdEI0K2cwNlhMYWdRVXRXYjBSa090K1k2cHFIc3Y4?=
 =?utf-8?B?dDRCMWxYZFZGYkpxdEdpMDdjVlRVNUM3RUhCN0h0OUJ2RmV4WVhkY1BIOGNu?=
 =?utf-8?B?UEtMN0RxcXhLbUZGU2Y2Q1VIQnNPd0d6SjJscWV3Z2YrTHg4KzVKM1lqZUdh?=
 =?utf-8?B?K1BQQSt6azZKMU5HZmNhL0tHQm80NDJpQjBvbzM0R2hHTEhGR3JDSElSK0g0?=
 =?utf-8?B?OE5sN0JjaXI2V2FsK3VQRFVDOGZwNlNWKzBWUmR2RVZMdEJBUHljaHFsTkps?=
 =?utf-8?B?NWI5SzlWTnFJWDVtRTgrL2FHZ056a2thQnpxS1ZKakc1V3dEaFh4Sld3WVBz?=
 =?utf-8?B?a2xvd1FmUkh5b3liTlFzbWdzMThyZWQvQ21Tam1PY0I2NDhWRTZKM2owekdo?=
 =?utf-8?B?bU0yenBWUnB4d2JRa2E4RDltT3I4WXFmT1FlSWM3eWc2V1htTnA5OUw4NUVZ?=
 =?utf-8?B?bFMxZVh4cHdmcFF3UnBIL3lJWTNLZ29yNEVoUk82ckxPREpqQ1JuRGRPU0tk?=
 =?utf-8?B?N2RyQnBzbDJNSnYwSkxJN1ROUmlLMnhQaThkMmljb21XeVMwRDQ2bVhlZ1NV?=
 =?utf-8?B?eFFyMmhaVnI1VXhEK3p4UFhBTXBxVkxBU1Z3ZlNxRlNxNjQ4c09NRlJ1MDl0?=
 =?utf-8?B?OCsyTmFyelJqK3pWTXpjU0RwNFg2dmtobmw4cCtRQ0FDQml1RjA3ZmkreEp6?=
 =?utf-8?B?bU5RbjdTUkE5ckZRK2tydVI5bUdxL1ltZ1U5dHdqc0pYOXBVendGRDlyN0Vw?=
 =?utf-8?B?U0Qxd295MXJuOUtRZTRXRkN4aGNsZ2QycXprVEJEb1I0UXQyZHhuSHpNaGRx?=
 =?utf-8?Q?L54UvnLi7Zhqsjw2smPlcU3IZ+VEoJYW?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA1PR12MB6532.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?NVBYU2dzeDJYRlJzS3dycVNGSEg0OEdneC9hYUdYYmxjczdGR2JQd2NpWnFI?=
 =?utf-8?B?b2ovQjcrcTYvR1lCSTZ6eU1nZWRKaFVMUFdhWWRXZ0pSaUIybkpsaDI5WVYx?=
 =?utf-8?B?b2t5WmJuejErUWU0eDdpbGtpR3JqVWZoajRSeHg3V1dRa1JpL1Zjd2pEK09H?=
 =?utf-8?B?M1lWODRaRFFyS0lLZ2d1d2JvUUxmS21HQTVQVFVwdFprUURYdldQVWNxTGpQ?=
 =?utf-8?B?cjMxSi9OR1ZxeFcrWC8rSmtUYzBkaGhOSmlnMXRiNjZua2l1V0NWQUl0Z2tQ?=
 =?utf-8?B?MVd4M1hvUlZVcXFVWnduemszRUJsMktQVG92MzhZWkYyQWtSdXpnV3kwVHZv?=
 =?utf-8?B?Q0VHWm9RcklvSWVrR0JtalBDdERRZUlObHJsVURPM1dIOUdacHJVMnJ5R0lI?=
 =?utf-8?B?Vktub3VodVB4dlBKbkVsN3hSWVVSVWNsbDJyRWFsSE12WUV5OXdJS0JESk01?=
 =?utf-8?B?ajF4M3ByVGZRVjZqcFp2SGJ1NEdKczE4ZGZ6dXBvNWF5czUxZGVxaURTVFJB?=
 =?utf-8?B?N0RvSDh1NXZ1TGRhd3Q0SEFpZk1MdittZ0Y3MTljVjR1b3pab0pVZ0NtVG9E?=
 =?utf-8?B?eDN2VXJJRjlWT0dtaEVuWTlocEVBOTdvTE51Z1krTWI4OURCQjNLYUNkUERi?=
 =?utf-8?B?eVZXVm9XOEVtRDU1Zkh6VXBFZlZJY0JTYkYvS0I4bnlnaFNvdzBxS1JXT3J2?=
 =?utf-8?B?bGtPZ3kyTDR6K1Y5QmVlM0xKTHVYc2FyYmNNTlBONGdsb2NYbmY1WjRkcVVp?=
 =?utf-8?B?aGlvV1JpWDg0NmdINXNvQlNZd2hEbjROUnltQ0s4UkFCbEZLNnIrQ0pxRXFQ?=
 =?utf-8?B?NUxPTzY4bEY0RVNaN2ZDQm1oMzREQ1M5SStadGJQdktuSmZZWkdoZGdCQ1Fu?=
 =?utf-8?B?NTZkMWpNSmxJcXFrNlNWdEdHRk1ISkRXdW4vSWxTUUErcUZTRGZ3bEUvNnJa?=
 =?utf-8?B?WFdnSWxEa3hJdjNxR2dLREgzcEo2dU5OSlF1UVc0TXl5VDdVQllHYkJkZHM5?=
 =?utf-8?B?eXlWcTh5MEorV3FCWU5adUd1MllaUTV4TkwyWHZRaTlwajhrRlVaRWY2WmQ2?=
 =?utf-8?B?dDJrT2JrY3prRUtJNG1KcGZNYXhFUW8zNlA2bHpNVjg0S0VlUXJVci9uYU9X?=
 =?utf-8?B?VDBJWE1DK0ZKZ1J5bTJ0T1dPSE5ETnpjZFdYVG1SVlJESXFHZXdtYkJFMi9L?=
 =?utf-8?B?QkJiMngvRWh3OUkwQWtFaGdOL1NFRUdmM0NBU0IvVDh3M093eGovTFFzRFRP?=
 =?utf-8?B?VHJRZlhEKzFkd1ZKbk5GeWFvVEVCUm15cjB2a2hma1hHS2I5RWtnbExCYTFi?=
 =?utf-8?B?MzZrUWpXNmd4cDlmUGZucnJQUHZQbFVhWFk1RFdWU1ZaZDBKSjRBU0ozSlAz?=
 =?utf-8?B?dnVOcnkyWGlNZU5MRlNmVHgrdFM2ck1YMjc0aCtCY243YmttUVpjME5SMnZX?=
 =?utf-8?B?Sm16ZndzOEdSUGc2QWNqL2FmOXBCMElFU3NRSTJOcHU4YWlKalh0aFArYjhF?=
 =?utf-8?B?NjFab2dvUWJ6bFViTTR1UzY2d1JKS3dmYUZJZUpmTXA1SUxwOGxIRnBzUlNS?=
 =?utf-8?B?c2VMTGtJbkkwTlp4REYyNzhjc0hqZFFsS3lWZ3U1V2RYenJYQ0NYWEphTmNm?=
 =?utf-8?B?V0dlRkNVNWl3UmJHVGZCNWlmVzdObnRiWjRVa1BKN1pwTFAzNTZKRUpzUkN0?=
 =?utf-8?B?aTh6cjVnZkZJMFliYytFajk3ZzFXNm9rUmZzM2d5bnltNi9tTVl0blQvQjI2?=
 =?utf-8?B?TVdUUExTelRvcTJSdzBSVGRVQUQyN3JWUU1BS0J3N1d5SUY3cjFSRVRUUnor?=
 =?utf-8?B?WUFtRmluamxnSURQVmc4L3NxSXdUVjNvSXZGMGM3bWxjMWZ4eGlSdzRJWFZ0?=
 =?utf-8?B?N3hGajlTYk13TWN1V09kSE9WenFyeHMzdUp2V1gvS1p3U1Joemp0VmFIN1ZY?=
 =?utf-8?B?K3M0dGcyNFFOSFJLd3IzaEo3UmlQSGhCbUo3NXdyWklobkpWNTd1R08wOXNk?=
 =?utf-8?B?VS9BR1ZuS09Tcnpud1IzOXlIMXZxSk5ETHgvREpOOGdNTEY5QXhzTDliQkNv?=
 =?utf-8?B?NDBUZU4ySTZlejd3eHRUNjJ2YXNqM2ZSd1ZkODFYcTdjcVBwaFdDcTRjSERZ?=
 =?utf-8?Q?9iAI=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: IA1PR12MB6532.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 71e947d3-6300-4dc0-5f86-08dd1e5f1a0f
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2024 05:53:16.4198
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: JwvIljXVEZqrb65iCVbdE0/Oj1Zgi5lxIHBnA8cN9y+hrQE0L+1TdTQQm4gb6AEubYnmSrXYAv0Edgpk49pc2A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9022

DQoNCk9uIDIwMjQvMTIvMTYgMTc6MTksIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxNi4xMi4y
MDI0IDA5OjE4LCBaaGFuZywgSnVsaWEgd3JvdGU6DQo+PiBPbiAyMDI0LzEyLzkgMTU6NDcsIEph
biBCZXVsaWNoIHdyb3RlOg0KPj4gT24gMDcuMTIuMjAyNCAxMTo1OSwgSnVsaWEgWmhhbmcgd3Jv
dGU6DQo+IA0KPiBZZXQgYW5vdGhlciBmb3JtYWxpdHksIHNvcnJ5OiBQbGVhc2Ugc2VuZCBwbGFp
biB0ZXh0IGVtYWlscy4gWW91J2xsIG5vdGUgdGhhdCB3aGF0DQo+IEkgc2FpZCBhbmQgd2h5IHlv
dSBzYWlkIGlzIGluZGlzdGluZ3Vpc2hhYmx5IGludGVybWl4ZWQgYmVsb3cuDQoNClRoYW5rcyBm
b3IgcmVtaW5kaW5nLg0KDQo+IA0KPj4gLS0tIGEvdG9vbHMvaW5jbHVkZS94ZW4tc3lzL0xpbnV4
L3ByaXZjbWQuaA0KPj4NCj4+ICsrKyBiL3Rvb2xzL2luY2x1ZGUveGVuLXN5cy9MaW51eC9wcml2
Y21kLmgNCj4+DQo+PiBAQCAtMTEwLDYgKzExMCwxNiBAQCB0eXBlZGVmIHN0cnVjdCBwcml2Y21k
X21hcF9odmFfdG9fZ3BmbnMgew0KPj4NCj4+ICAgICBpbnQgYWRkX21hcHBpbmc7DQo+Pg0KPj4g
ICB9IHByaXZjbWRfbWFwX2h2YV90b19ncGZuc190Ow0KPj4NCj4+DQo+Pg0KPj4gK3R5cGVkZWYg
c3RydWN0IHByaXZjbWRfcDJwZG1hX2Rpc3RhbmNlIHsNCj4+DQo+PiArICBfX3UzMiBwcm92aWRl
cl9idXM7DQo+Pg0KPj4gKyAgX191MzIgcHJvdmlkZXJfc2xvdDsNCj4+DQo+PiArICBfX3UzMiBw
cm92aWRlcl9mdW5jOw0KPj4NCj4+ICsgIF9fdTMyIGNsaWVudF9idXM7DQo+Pg0KPj4gKyAgX191
MzIgY2xpZW50X3Nsb3Q7DQo+Pg0KPj4gKyAgX191MzIgY2xpZW50X2Z1bmM7DQo+Pg0KPj4gKyAg
X191MzIgZGlzdGFuY2U7DQo+Pg0KPj4gK30gcHJpdmNtZF9wMnBkbWFfZGlzdGFuY2VfdDsNCj4+
DQo+Pg0KPj4NCj4+ICJEaXN0YW5jZSIgdHlwaWNhbGx5IGlzIGEgc3ltbWV0cmljIHRoaW5nLiBX
aHkgdGhlIGFzeW1tZXRyeSBoZXJlPyBBbmQNCj4+DQo+PiB3aHkgX191MzIgd2hlbiBfX3U4IHdp
bGwgYmUgZmluZSBmb3IgbW9zdCBmaWVsZHM/IEFuZCB3aGVyZSdzIHRoZSBzZWdtZW50DQo+Pg0K
Pj4gcGFydCBvZiB0aGUgZGV2aWNlIGNvb3JkaW5hdGVzPyBGaW5hbGx5LCB3aXRoIGl0IGJlaW5n
IG1lcmVseSBzdHViDQo+Pg0KPj4gaW1wbGVtZW50YXRpb25zIHRoYXQgeW91IGFkZCBoZXJlLCBh
bGwgZGV0YWlscyBvbiB3aGVyZSB0aGUgbmVlZGVkIGluZm8NCj4+DQo+PiBpcyB0byBjb21lIGZy
b20gYXJlIG1pc3NpbmcuDQo+Pg0KPj4gIkRpc3RhbmNlIiBpcyBwMnBkbWEtZGlzdGFuY2UgYmV0
d2VlbiB0d28gUENJIGRldmljZXMsIGl0J3MgY2FsY3VsYXRlZCBpbiBrZXJuZWwgZHJpdmVyLkkg
ZG9uJ3QgZ2V0IHdoeSBpdCdzIHN5bW1ldHJpYz8NCj4gDQo+IERpc3RhbmNlIGZyb20gQSB0byBC
IGlzIHVzdWFsbHkgdGhlIHNhbWUgYXMgdGhhdCBmcm9tIEIgdG8gQS4gQnV0IHllcywNCj4gbm90
IG5lY2Vzc2FyaWx5IGFsd2F5cyAodGhpbmtpbmcgb2YgZS5nLiByaW5ncykuIFlldCBzdGlsbCBJ
J20gdW5jbGVhcg0KPiBhYm91dCB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBwcm92aWRlIGFuZCBj
bGllbnQuDQoNClByb3ZpZGVyIC0gQSBkcml2ZXIgd2hpY2ggcHJvdmlkZXMgb3IgcHVibGlzaGVz
IFAyUCByZXNvdXJjZXMuDQpDbGllbnQgLSBBIGRyaXZlciB3aGljaCBtYWtlcyB1c2Ugb2YgYSBy
ZXNvdXJjZS4NCg0KSW4gb3VyIGNhc2UsIHdlIHdhbnQgdG8gdXNlIHBhc3N0aHJvdWdoIGRHUFUg
cmVuZGVyIGRhdGEsIGFuZCB2aXJ0aW8gDQppR1BVIGRpc3BsYXkgZGF0YS4gU28gZEdQVSBuZWVk
IHRvIGltcG9ydCBkaXNwbGF5IGJ1ZmZlciBvZiBpR1BVLiBpR1BVIA0KaXMgcHJvdmlkZXIgYW5k
IGRHUFUgaXMgY2xpZW50Lg0KDQo+IA0KPj4gSSB3aWxsIHVzZSBjaGFuZ2UgX191MzIgdG8gX191
OC4NCj4+DQo+PiBCeSB0aGUgc2VnbWVudCBwYXJ0IG9mIHRoZSBkZXZpY2UgY29vcmRpbmF0ZXMs
IGRvIHlvdSBtZWFuIHRoZSBkb21haW4gbnVtYmVyIG9mIHRoZSBkZXZpY2U/DQo+IA0KPiBTb21l
IGNhbGwgaXQgZG9tYWluLCB5ZXMuIFNpbmNlIGRvbWFpbiBoYXMgYW4gaW1wb3J0YW50LWlzaCBk
aWZmZXJlbnQNCj4gbWVhbmluZyBpbiBYZW4sIHdlIHByZWZlciBzZWdtZW50IHRob3VnaC4NCj4g
DQoNCkkgc2VlLCBJIHdpbGwgYWRkIHRoaXMgaW5mbyBpbiB0aGUgc3RydWN0Lg0KDQo+PiBBbGwg
dGhlIG5lZWRlZCBpbmZvKHZpcnR1YWwgYnVzL3Nsb3QvZnVuY3Rpb24gbnVtYmVycykgYXJlIGZy
b20gZ3Vlc3QgVk0sIFFFTVUgY29udmVydCB0aGVtIHRvIHJlYWwgcGh5c2ljYWwgaW5mbyBvZiB0
d28gZGV2aWNlcy4NCj4+DQo+PiBEbyB5b3UgbWVhbiB0aGF0IEkgc2hvdWxkIGFkZCBtb3JlIGRl
dGFpbHMgaW4gY29tbWl0IG1lc3NhZ2Ugb3IgY29tbWVudD8NCj4gDQo+IFBlcmhhcHMuIE9yIGhh
dmUgdGhlIHBhdGNoIGJlIG1vcmUgY29tcGxldGUsIGluIHRoZSBzZW5zZSBvZiBub3Qgb25seQ0K
PiBwdXR0aW5nIGluIHBsYWNlIHN0dWJzLCB0aHVzIGFjdHVhbGx5IG1ha2luZyB2aXNpYmxlIGhv
dyB0aGUgZGF0YSBpcw0KPiBwcm9kdWNlZCAvIHVzZWQuDQo+IA0KDQpTdXJlLCBJIHdpbGwgdHJ5
IHRvIGFkZCBtb3JlIGRldGFpbHMuDQoNCkp1bGlhDQoNCj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 08:20:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 08:20:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858556.1270813 (Exim 4.92)
	(envelope-from )
	id 1tNSoi-0003rF-Fu; Tue, 17 Dec 2024 08:20:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858556.1270813; Tue, 17 Dec 2024 08: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 1tNSoi-0003r8-Bj; Tue, 17 Dec 2024 08:20:32 +0000
Received: by outflank-mailman (input) for mailman id 858556;
 Tue, 17 Dec 2024 08: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 1tNSoh-0003r2-HY
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 08:20:31 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20603.outbound.protection.outlook.com
 [2a01:111:f403:2416::603])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c37e740a-bc4f-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 09:20:26 +0100 (CET)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by DS0PR12MB9447.namprd12.prod.outlook.com (2603:10b6:8:1b4::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Tue, 17 Dec
 2024 08:20:21 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8251.015; Tue, 17 Dec 2024
 08:20: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: c37e740a-bc4f-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Ml2U7Ql8V06RJLAlRB3KQchl/aFzGXqGavzjOApLAhHio9bqEeTo9/YCGkKvi86p/rGlhtGIIsSVwGhnq2Ds4H9c0gA6YcW28Np281U+peOr/1LWJxYK+vDh0YNKZkgeTWSJ7AF2M/0WbWs3qMM8kVtXRwf32ge0UaG6TMT1oQgWkbHeFu+drzoJwCe3q8svsCyrSxT8Vdaw9xh+dsHY5fkitPl7KMeyIyV0nU+JKBB9xWf/8gGLthnO9/rfhb2gFnbZu5p9zptAMM28rBkM7CRnnL2FMdLzLM6OKd28olEI/saao11yuVRq5rtzudqkbXmIuF0P81ItajXtN8tfBw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=qJx8eTxv7F/NiWwUFXPBLNcFqpJE/1gAiI4qYypjeW4=;
 b=ZJgs+uGrI+ZtLQxsYIp4EjkBXlxpxWqfuUsSv7aR8Di+BzxdId6lnAFyntrp8LDw9rIjWyHYprFb8dGGQKqkcM/Xera+j2GsPgOpKDgLVQLXO8QYXWRRYHVeR1N6JPpXR/34y8m14ZdD7pPcXR5H7F57toX46MBszOhz0bf84zgkfFnQou1U2QOuLbL2qtIBIQJFy/BIKvQZo4Km9VkXUuADXSIqLwNkHoXC6QAFL+Scp8T+jXONg7bFbB95ohA7ISjSOql1MwAlupKMvsOHtuLloJ2gKPQ81VVL1cmUQfOpBiZw6fjEqURhdb4xJ9k7WQ2BbvefFl9A1tPLEyiGdA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=qJx8eTxv7F/NiWwUFXPBLNcFqpJE/1gAiI4qYypjeW4=;
 b=TcAf6epXf0EtZNCctPavwVqEqLQzb5C3bgwedZCHj/tyyJHBRP65wfSrtdNOKO6oxC65ls9Z2kV0/Vu5yOyShRvcAv9VO9oUHDUlB3XQnohxqchKvyeAx22kQhS3Rew6eCjzQsWA+p/LBya1EBKKxy5C3+vI90g9aJ4J68PsZuU=
From: "Chen, Jiqian" 
To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Jan Beulich , Julien
 Grall , Stefano Stabellini , "Huang,
 Ray" , "Chen, Jiqian" 
Subject: Re: [PATCH v3] vpci: Add resizable bar support
Thread-Topic: [PATCH v3] vpci: Add resizable bar support
Thread-Index: AQHbTSHk/+a4JH45i0iSPkOFUem08bLor0CAgAHzfgA=
Date: Tue, 17 Dec 2024 08:20:21 +0000
Message-ID:
 
References: <20241213054232.2638640-1-Jiqian.Chen@amd.com>
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8251.004)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|DS0PR12MB9447:EE_
x-ms-office365-filtering-correlation-id: 15fb0230-48e3-43e7-7575-08dd1e73a621
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?cFRKK2JQelZISllUVHQzYzN3aGo4RHd6bEVxaXFkTkFHeFFQVTZYOUs3WVpQ?=
 =?utf-8?B?SFdRRjgwMU9aeENXQXRSaWxyaU5MNmJiY0tVNU94ZzlLRXN5eHRlSFRwRXRn?=
 =?utf-8?B?bTJtN0Jzc2hvQVpvNU1tK2JvYUI4S2ZYb0FSUnkvVFZOa01ZeTU5VmU1VTVt?=
 =?utf-8?B?aDZnd3poZ1VPUlNuTUlHQkluR3QrWElKUlU1V3J5MHJyZVEwWkF5ZkdhdEJy?=
 =?utf-8?B?cXRtU0lUMENrd1pUUkNBOG9xdG9vZitjaUsrTXFKdFRTMzdKeUVhb2hCTlpj?=
 =?utf-8?B?YVZ0VlpSZXdjbEQ4VUN3V0FVVzZ0aWtDSG5ZZGFHZTVVbHI5Y1JIUXRmN0Nk?=
 =?utf-8?B?QVZDN0JVbGpEM0JmeEZNeEplS0tiTmZWSnUraDNuVVZkSW0ybUtYTGdZN3Fy?=
 =?utf-8?B?OTZxV1ErVlhJTnFPTTA5cXlKVUtsMjZEVFFJaDhUVlFScVl0bUZCMDdZOWFC?=
 =?utf-8?B?czVLWndvZTQvaHIwNHpSaG9INXc3V1hXa0NqVlRiMG9UNE9KU3c1dGRBaGZo?=
 =?utf-8?B?dys4c244Y1ZkeWZHUUdjL3hhZnVoQTRvN0h5RVg1WGg1U0FTdThtVnBzL2Ru?=
 =?utf-8?B?M1FTL3RiUENSMjhSNjE4MlhTSjI0RmVFenRuZ01ZZjNNcTFZR3ZSdFRqYndW?=
 =?utf-8?B?TlFQWjIzTGRQNE5TOVBVaHptLzBBZTB2SkZ4b0dOMzdlR0NMYnpod0VhMkdX?=
 =?utf-8?B?SkFPMDhnWjJjcnBVY3N4cWhidmN5K1NrN1JvdGZwUXY4WlRSZDZsSElhV1U4?=
 =?utf-8?B?SmU5VXFISFlWbWQxdGxCdklDVFdiTlc0cDBaKzhsUHAzUmRXVjBRV2dmK0JJ?=
 =?utf-8?B?T3pkODBFbzBzaEdqb2h4cVQ4eUhtSFpkYkd0U0FKNUlFcUljd1NsL0ZZeTlu?=
 =?utf-8?B?czBuY1FJWUloTVJsdVRvM1BJeFFqa0NTYllLdjBNdjFDbGhiMndoV0VxaWxa?=
 =?utf-8?B?Ulh5YXhvMEI1ekl2MjBJazVsUjA5M3dWVkpEZE5yN2h2djE5TUMvRURxelNY?=
 =?utf-8?B?Wjd5Q2dRRWpRT0pSaFJFV2l5YnJLS2h5KzhRT3ZGb2c4cks5cnB6M2R1MFFS?=
 =?utf-8?B?RnJBS3RSUFNvdUsxOEdydTg5ckpMcUdobEJTbWNETTR0cXRXMVRqbCt5UXFX?=
 =?utf-8?B?QllDVFhyMk5jUkM2WnM2QVd2R05jUmRVbGpYWUgxTjArWk9SQ2RSS3hpNmlh?=
 =?utf-8?B?TU1zQlVDbXNoOTdEdUU5akxKMHRoeUYyTk1BWkM4Vnd2bkZtVjRKVG1vdkl4?=
 =?utf-8?B?aHJ4RTcxZFRyanREUU5Db1F5R2JqVnNNTmxlQTVvemFEUlZHTjhQY2ZJR2NQ?=
 =?utf-8?B?SEx5aFFpc256c3liL2EyM3RBVy94MCtQdjIvelIrZ3pvL1E3MFkwWTZzbVl1?=
 =?utf-8?B?QlBXdVRmUVlhRHUzWFlaWG12N2JVbGsxZGVSejFBUTVhMXYwS0xJdUdtTXJE?=
 =?utf-8?B?YmlxaHgySHhFaWt0YWpGd0FaNjJFWXhENmV0QXZPRHlLeVF6dWVlK3RxcHVH?=
 =?utf-8?B?WjlIQ3pCWDl6QkZWQzB6NitSL3BxaW04UG15VTMvUmFPTmJ2bC9Jbnd2ckxx?=
 =?utf-8?B?djU5eTZSV0E5M1k2UXFmUkZVNXcvQXZqK1kzRUMzVjZVWlhYL0RHQ1RjeWJ1?=
 =?utf-8?B?d1pZSzBqZzN6QjZtTEN2T0hGM01vN1A0WUtqaFFqbU1GdVI3cDVyUk5yOUdO?=
 =?utf-8?B?MjZ4TEVSRVNmMVFrV3ZaQXN5ZVJTT2xDTVRMLy9PWmxVQ3F3ZUJkWVkrblhT?=
 =?utf-8?B?NCtXNndpSUM1VENCRHZOK3dkcXQ5K01hM2lwT2NBb3JWTWFWSks3OWNrRDF6?=
 =?utf-8?B?alh2WTkyM3QxNWkrVVVIc1YvZXlLamdOV3ZTSDBTZXRKT1BYbXRiQnJPbGpL?=
 =?utf-8?B?ZGZoV3FxeW5IQ1ArclBPekR2aVNaUGNTT3R2Nkh6WHBZK1RjcVJJNkpUM0k1?=
 =?utf-8?Q?/Bd/IqgV9rh75Xu3KGGBVQ1tMuwhYhq1?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?WWVxV1JWZTRVN2FWS1A4ZHRnb0s4TUNxdkxkaUwzNUIrS3huZDlsS3RXN29O?=
 =?utf-8?B?MGgwMWpWcnF0bWV4aE1hcnZmZ1hrVFhuRFBtdjhZS3JaWitoclhQcmhkRERW?=
 =?utf-8?B?alUrNWtvZERyUllzTDd5UytWUWZtNVg4VlRBSUlNVklEdEhKQ2xRNmpsejRD?=
 =?utf-8?B?UldCVGVGOHhPN1FKSkp4anNDVWRaRzIwYmdLOFFsaVpucGJqd3dmRlMzeDdJ?=
 =?utf-8?B?Z3FRcWFTU0F6RndCK3JXSjUrdXBxRFNqdUw2S3E1anhVYmVQRjNjRzIwYmhD?=
 =?utf-8?B?Y3NETFdDUnpDaHFGOXZFOHlBZlIrNFBHcTRjeHQ1ZGVqZ3E5TjkreVpQbG9W?=
 =?utf-8?B?VlpVRnBXYTRQUUVXUXJJUjlYNlRYZEY4bHIyNlVtKzFvdHZHK3hMNlVCMGtn?=
 =?utf-8?B?WnFiWVNRR0pSZVU5bUNJSk9wUkRBSlQrd1I5NTBFcjhGdkd1Yk9mdzdCSEpu?=
 =?utf-8?B?SlBkTWNndlBraXE1aURvMHpkNHZKYThtVlNhR29acjc2VzFUMytzM294SWE4?=
 =?utf-8?B?SDZKUUtJWmtwOWp2dTgyL202T3R2c3VabHh3cTFEMUlDYXJlYnpzanJhMjlk?=
 =?utf-8?B?NVRidjNDSGIvRXM4bW5qcUhOKzV3bDBhY2YwRXp5c3VuYk56aTFkWkhXK0Zr?=
 =?utf-8?B?dzZrTDBoQWp3cEVERy9nMmpPaW51blBmWkdjdE9JOEFGaXVSVUtRcnhEZ0tz?=
 =?utf-8?B?NHNuNTUrVjdBWXdMeDVFYXRRWGMwN3REekhMdGtSUE15L2hPd21rZy9tcm1U?=
 =?utf-8?B?MU9FWWhuN3hCMXNhTUhMS0hIdWdjSEtTTm1Fa3pEZVowTStycVFWVkM1Y0dY?=
 =?utf-8?B?SmVuN1FMdXlsM1E2a284UGRLU1dkK1NGam45WEVRTlE3RllKVWh2NHhHZnAx?=
 =?utf-8?B?T3NNbSttZW5UdkdKZTQ3aFhySmI2YVZuZlh3ME1rdU4vaHBaZXFWUkc1ZGV2?=
 =?utf-8?B?aFVWQWJCaDUxRHNTdkRqdHpwdFZ1d1FkQmN6NnJ0MmE5WTlMdTBwSzl5V2hN?=
 =?utf-8?B?MjA2MExTSER2WjhoOVJBM1RteFRMOEV5VFhLbGJaNEd6Tkl4dUsyS1NnSkhG?=
 =?utf-8?B?MXVlbXU0dUNqYzkwY2ZqZmJ0dzc4WWVvOHMybDVHSE5mbXYyUjNMMllnMkx2?=
 =?utf-8?B?VjBWbTdMVWk4ZXVvUlJoTkpNOTlobGg3cXhFczdLTXQrK1FHdXlzQ3BWZ1lj?=
 =?utf-8?B?b25ESUFyR1hlN2FRMy9GRDFkTTFOS1hneS8wZHJ6ajVEUXZZZUYySEs2SG9z?=
 =?utf-8?B?NUdNZTErU21Vb3BRRVI3Ukd6RGpNVkkxL1gyalZLK25aS2JLN0gyVWFiZVY3?=
 =?utf-8?B?MkNDdE55WUdVd2VtZU14TDIzOHd0aEQwUlBrYzhrRFh6K1Q4Z0dueHhxdDZO?=
 =?utf-8?B?VUlqVVlMalQvWTF3VFgzZ3FHR2FIeDNXWVB6emFURHc0L0lXYWExNCsyb0hh?=
 =?utf-8?B?c3pTQWJjMDVycytuL2czNDd0NFhOTUViYmsxN2lQV1B0OFR4Yi9qQWR6ZWRT?=
 =?utf-8?B?RXcvTVhDZzNkWlVtWXd0OGRDQUNTOTVNaU40Mmx6QlBVTDVSSVlBZEVWd1JX?=
 =?utf-8?B?MWVVUElJQlBTTFJxZTFWZDR4Q2JQNGdSSi9GYjB1UnB0V0N6RkdIbG8zcThT?=
 =?utf-8?B?TCtBZEgyKzhMb3ZKMU9JSU1hNnlubTlEUm9idVUxdmhOVWxGZ3RzZjM1K1RM?=
 =?utf-8?B?SmZwMFUySmxiV21BM2tIWHlvUTQ3czRXTFRuUU9YUTRjams5WFBsdUNLVW8y?=
 =?utf-8?B?ZDU1YlBnbEpNZ3I3UGlKM055c3FxWjhhUDNqZ0JhbFVVRDBpZ21KQjlwNnJQ?=
 =?utf-8?B?VFU1SlZrTHY3VDN3WmtueGtNS2Y1SHBFbVpZdWNjUmMzU2JMeDRaRGswWXVj?=
 =?utf-8?B?bmw3amY4RFAxNktZK1kvYThMTEgzRTRKS2llNit4R01oenZFbUhXYVFIOWhF?=
 =?utf-8?B?cmdnOStyYkFlZVlFTzlucDQ4QTl6Q0U0R3o0RTdUUkUzaGw0QnJJdzNTWXJT?=
 =?utf-8?B?ZytHcklpclJ1SDd1Y29PNjcvcDkrSkhyTUM4SHpHa1h5L0E5K0RHbEFWdDBt?=
 =?utf-8?B?Z0l2Nk0xZXhwL283dDBBVnUrRWc3M3V4dC94ZGVUNWJjUmJlZC9acFkvamZM?=
 =?utf-8?Q?fFBg=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 15fb0230-48e3-43e7-7575-08dd1e73a621
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2024 08:20:21.3715
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: f4/faOfKUWrE/IDblQ5GCS+wFp1ab1jVJNNoKN7/kt+1cloJE1b3vRDV4OZNW3oYkmN0jL6iGB9f5O22HP0jdA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB9447

T24gMjAyNC8xMi8xNiAxODoyNCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToNCj4gT24gRnJpLCBE
ZWMgMTMsIDIwMjQgYXQgMDE6NDI6MzJQTSArMDgwMCwgSmlxaWFuIENoZW4gd3JvdGU6DQo+PiBT
b21lIGRldmljZXMsIGxpa2UgZGlzY3JldGUgR1BVIG9mIGFtZCwgc3VwcG9ydCByZXNpemFibGUg
YmFyDQo+PiBjYXBhYmlsaXR5LCBidXQgdnBjaSBvZiBYZW4gZG9lc24ndCBzdXBwb3J0IHRoaXMg
ZmVhdHVyZSwgc28NCj4+IHRoZXkgZmFpbCB0byByZXNpemUgYmFycyBhbmQgdGhlbiBjYXVzZSBw
cm9iaW5nIGZhaWx1cmUuDQo+Pg0KPj4gQWNjb3JkaW5nIHRvIFBDSWUgc3BlYywgZWFjaCBiYXIg
dGhhdCBzdXBwb3J0cyByZXNpemluZyBoYXMNCj4+IHR3byByZWdpc3RlcnMsIFBDSV9SRUJBUl9D
QVAgYW5kIFBDSV9SRUJBUl9DVFJMLiBTbywgYWRkDQo+PiBoYW5kbGVycyBmb3IgdGhlbSB0byBz
dXBwb3J0IHJlc2l6aW5nIHRoZSBzaXplIG9mIEJBUnMuDQo+Pg0KPj4gU2lnbmVkLW9mZi1ieTog
SmlxaWFuIENoZW4gPEppcWlhbi5DaGVuQGFtZC5jb20+DQo+PiAtLS0NCj4+IEhpIGFsbCwNCj4+
IHYyLT52MyBjaGFuZ2VzOg0KPj4gKiBVc2VkICJiYXItPmVuYWJsZWQiIHRvIHJlcGxhY2UgInBj
aV9jb25mX3JlYWQxNihwZGV2LT5zYmRmLCBQQ0lfQ09NTUFORCkgJiBQQ0lfQ09NTUFORF9NRU1P
UlkiLA0KPj4gICBhbmQgYWRkZWQgY29tbWVudHMgd2h5IGl0IG5lZWRzIHRoaXMgY2hlY2suDQo+
PiAqIEFkZGVkICIhaXNfaGFyZHdhcmVfZG9tYWluKHBkZXYtPmRvbWFpbikiIGNoZWNrIGluIGlu
aXRfcmViYXIoKSB0byByZXR1cm4gRU9QTk9UU1VQUCBmb3IgZG9tVXMuDQo+PiAqIE1vdmVkIEJB
UiB0eXBlIGFuZCBpbmRleCBjaGVjayBpbnRvIGluaXRfcmViYXIoKSwgdGhlbiBvbmx5IG5lZWQg
dG8gY2hlY2sgb25jZS4NCj4+ICogQWRkZWQgJ1UnIHN1ZmZpeCBmb3IgbWFjcm8gUENJX1JFQkFS
X0NBUF9TSVpFUy4NCj4+ICogQWRkZWQgbWFjcm8gUENJX1JFQkFSX1NJWkVfQklBUyB0byByZXBy
ZXNlbnQgMjAuDQo+Pg0KPj4gVE9ETzogbmVlZCB0byBoaWRlIFJlQmFyIGNhcGFiaWxpdHkgZnJv
bSBoYXJkd2FyZSBkb21haW4gd2hlbiBpbml0X3JlYmFyKCkgZmFpbHMuDQo+Pg0KPj4gQmVzdCBy
ZWdhcmRzLA0KPj4gSmlxaWFuIENoZW4uDQo+Pg0KPj4gdjEtPnYyIGNoYW5nZXM6DQo+PiAqIElu
IHJlYmFyX2N0cmxfd3JpdGUsIHRvIGNoZWNrIGlmIG1lbW9yeSBkZWNvZGluZyBpcyBlbmFibGVk
LCBhbmQgYWRkZWQNCj4+ICAgc29tZSBjaGVja3MgZm9yIHRoZSB0eXBlIG9mIEJhci4NCj4+ICog
QWRkZWQgdnBjaV9od193cml0ZTMyIHRvIGhhbmRsZSBQQ0lfUkVCQVJfQ0FQJ3Mgd3JpdGUsIHNp
bmNlIHRoZXJlIGlzDQo+PiAgIG5vIHdyaXRlIGxpbWl0YXRpb24gb2YgZG9tMC4NCj4+ICogQW5k
IGhhcyBtYW55IG90aGVyIG1pbm9yIG1vZGlmaWNhdGlvbnMgYXMgd2VsbC4NCj4+IC0tLQ0KPj4g
IHhlbi9kcml2ZXJzL3ZwY2kvTWFrZWZpbGUgIHwgICAyICstDQo+PiAgeGVuL2RyaXZlcnMvdnBj
aS9yZWJhci5jICAgfCAxMzAgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0K
Pj4gIHhlbi9kcml2ZXJzL3ZwY2kvdnBjaS5jICAgIHwgICA2ICsrDQo+PiAgeGVuL2luY2x1ZGUv
eGVuL3BjaV9yZWdzLmggfCAgMTMgKysrKw0KPj4gIHhlbi9pbmNsdWRlL3hlbi92cGNpLmggICAg
IHwgICAyICsNCj4+ICA1IGZpbGVzIGNoYW5nZWQsIDE1MiBpbnNlcnRpb25zKCspLCAxIGRlbGV0
aW9uKC0pDQo+PiAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9kcml2ZXJzL3ZwY2kvcmViYXIuYw0K
Pj4NCj4+IGRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy92cGNpL01ha2VmaWxlIGIveGVuL2RyaXZl
cnMvdnBjaS9NYWtlZmlsZQ0KPj4gaW5kZXggMWExNDEzYjkzZTc2Li5hN2M4YTMwYTg5NTYgMTAw
NjQ0DQo+PiAtLS0gYS94ZW4vZHJpdmVycy92cGNpL01ha2VmaWxlDQo+PiArKysgYi94ZW4vZHJp
dmVycy92cGNpL01ha2VmaWxlDQo+PiBAQCAtMSwyICsxLDIgQEANCj4+IC1vYmoteSArPSB2cGNp
Lm8gaGVhZGVyLm8NCj4+ICtvYmoteSArPSB2cGNpLm8gaGVhZGVyLm8gcmViYXIubw0KPj4gIG9i
ai0kKENPTkZJR19IQVNfUENJX01TSSkgKz0gbXNpLm8gbXNpeC5vDQo+PiBkaWZmIC0tZ2l0IGEv
eGVuL2RyaXZlcnMvdnBjaS9yZWJhci5jIGIveGVuL2RyaXZlcnMvdnBjaS9yZWJhci5jDQo+PiBu
ZXcgZmlsZSBtb2RlIDEwMDY0NA0KPj4gaW5kZXggMDAwMDAwMDAwMDAwLi4zOTQzMmMzMjcxYTQN
Cj4+IC0tLSAvZGV2L251bGwNCj4+ICsrKyBiL3hlbi9kcml2ZXJzL3ZwY2kvcmViYXIuYw0KPj4g
QEAgLTAsMCArMSwxMzAgQEANCj4+ICsvKiBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogR1BMLTIu
MC1vbmx5ICovDQo+PiArLyoNCj4+ICsgKiBDb3B5cmlnaHQgKEMpIDIwMjQgQWR2YW5jZWQgTWlj
cm8gRGV2aWNlcywgSW5jLiBBbGwgUmlnaHRzIFJlc2VydmVkLg0KPj4gKyAqDQo+PiArICogQXV0
aG9yOiBKaXFpYW4gQ2hlbiA8SmlxaWFuLkNoZW5AYW1kLmNvbT4NCj4+ICsgKi8NCj4+ICsNCj4+
ICsjaW5jbHVkZSA8eGVuL2h5cGVyY2FsbC5oPg0KPiANCj4gRG8geW91IHJlYWxseSBuZWVkIHRo
ZSBoeXBlcmNhbGwgaGVhZGVyPw0KSSB3aWxsIGNoYW5nZSB0byA8eGVuL3NjaGVkLmg+IHNpbmNl
IGlzX2hhcmR3YXJlX2RvbWFpbigpIG5lZWRzLg0KDQo+IA0KPj4gKyNpbmNsdWRlIDx4ZW4vdnBj
aS5oPg0KPj4gKw0KPj4gK3N0YXRpYyB2b2lkIGNmX2NoZWNrIHJlYmFyX2N0cmxfd3JpdGUoY29u
c3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB1bnNpZ25lZCBpbnQgcmVnLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgdWludDMyX3QgdmFsLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgdm9pZCAqZGF0YSkNCj4+ICt7DQo+PiArICAgIHVpbnQ2NF90IHNpemU7
DQo+PiArICAgIHN0cnVjdCB2cGNpX2JhciAqYmFyID0gZGF0YTsNCj4+ICsNCj4+ICsgICAgc2l6
ZSA9IFBDSV9SRUJBUl9DVFJMX1NJWkUodmFsKTsNCj4+ICsgICAgaWYgKCBiYXItPmVuYWJsZWQg
KQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBpZiAoIHNpemUgPT0gYmFyLT5zaXplICkNCj4+ICsg
ICAgICAgICAgICByZXR1cm47DQo+PiArDQo+PiArICAgICAgICAvKg0KPiANCj4gSW5kZW50YXRp
b24NCj4gDQo+PiArICAgICAgICAqIFJlZnVzZSB0byByZXNpemUgYSBCQVIgd2hpbGUgbWVtb3J5
IGRlY29kaW5nIGlzIGVuYWJsZWQsIGFzDQo+PiArICAgICAgICAqIG90aGVyd2lzZSB0aGUgc2l6
ZSBvZiB0aGUgbWFwcGVkIHJlZ2lvbiBpbiB0aGUgcDJtIHdvdWxkIGJlY29tZQ0KPj4gKyAgICAg
ICAgKiBzdGFsZSB3aXRoIHRoZSBuZXdseSBzZXQgQkFSIHNpemUsIGFuZCB0aGUgcG9zaXRpb24g
b2YgdGhlIEJBUg0KPj4gKyAgICAgICAgKiB3b3VsZCBiZSByZXNldCB0byB1bmRlZmluZWQuICBO
b3RlIHRoZSBQQ0llIHNwZWNpZmljYXRpb24gYWxzbw0KPj4gKyAgICAgICAgKiBmb3JiaWRzIHJl
c2l6aW5nIGEgQkFSIHdpdGggbWVtb3J5IGRlY29kaW5nIGVuYWJsZWQuDQo+PiArICAgICAgICAq
Lw0KPj4gKyAgICAgICAgZ3ByaW50ayhYRU5MT0dfRVJSLA0KPj4gKyAgICAgICAgICAgICAgICAi
JXBwOiByZWZ1c2UgdG8gcmVzaXplIEJBUiB3aXRoIG1lbW9yeSBkZWNvZGluZyBlbmFibGVkXG4i
LA0KPj4gKyAgICAgICAgICAgICAgICAmcGRldi0+c2JkZik7DQo+PiArICAgICAgICByZXR1cm47
DQo+PiArICAgIH0NCj4gDQo+IE5pdDoganVzdCByZWFsaXplZCB0aGlzIGNvdWxkIGJlIG1hZGUg
c2hvcnRlcjoNCj4gDQo+IGlmICggYmFyLT5lbmFibGVkICkNCj4gew0KPiAgICAvKg0KPiAgICAg
KiBSZWZ1c2UgdG8gcmVzaXplIGEgQkFSIHdoaWxlIG1lbW9yeSBkZWNvZGluZyBpcyBlbmFibGVk
LCBhcw0KPiAgICAgKiBvdGhlcndpc2UgdGhlIHNpemUgb2YgdGhlIG1hcHBlZCByZWdpb24gaW4g
dGhlIHAybSB3b3VsZCBiZWNvbWUNCj4gICAgICogc3RhbGUgd2l0aCB0aGUgbmV3bHkgc2V0IEJB
UiBzaXplLCBhbmQgdGhlIHBvc2l0aW9uIG9mIHRoZSBCQVINCj4gICAgICogd291bGQgYmUgcmVz
ZXQgdG8gdW5kZWZpbmVkLiAgTm90ZSB0aGUgUENJZSBzcGVjaWZpY2F0aW9uIGFsc28NCj4gICAg
ICogZm9yYmlkcyByZXNpemluZyBhIEJBUiB3aXRoIG1lbW9yeSBkZWNvZGluZyBlbmFibGVkLg0K
PiAgICAgKi8NCj4gICAgIGlmICggc2l6ZSAhPSBiYXItPnNpemUgKQ0KPiAgICAgICAgIGdwcmlu
dGsoWEVOTE9HX0VSUiwNCj4gICAgICAgICAgICAgICAgICIlcHA6IHJlZnVzZSB0byByZXNpemUg
QkFSIHdpdGggbWVtb3J5IGRlY29kaW5nIGVuYWJsZWRcbiIsDQo+ICAgICAgICAgICAgICAgICAm
cGRldi0+c2JkZik7DQo+IA0KPiAgICAgcmV0dXJuOw0KPiB9DQo+IA0KPj4gKw0KPj4gKyAgICBp
ZiAoICEoKHNpemUgPj4gUENJX1JFQkFSX1NJWkVfQklBUykgJg0KPj4gKyAgICAgICAgICAgTUFT
S19FWFRSKHBjaV9jb25mX3JlYWQzMihwZGV2LT5zYmRmLA0KPj4gKyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICByZWcgLSBQQ0lfUkVCQVJfQ1RSTCArIFBDSV9SRUJBUl9DQVAp
LA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQQ0lfUkVCQVJfQ0FQ
X1NJWkVTKSkgKQ0KPiANCj4gV291bGQgaXQgYmUgcG9zc2libGUgdG8gY2FjaGUgdGhpcyBpbmZv
cm1hdGlvbi4gIEl0J3MgbXkgdW5kZXJzdGFuZA0KPiB0aGUgc3VwcG9ydGVkIHNpemVzIHdvbid0
IGNoYW5nZSwgYW5kIGhlbmNlIFhlbiBjb3VsZCByZWFkIGFuZCBjYWNoZQ0KPiB0aGVtIGluIGlu
aXRfcmViYXIoKSB0byBhdm9pZCByZXBlYXRlZCByZWFkcyB0byB0aGUgcmVnaXN0ZXIgb24gZXZl
cnkNCj4gYWNjZXNzPw0KVGhhbmtzLCBJIHdpbGwgY2hhbmdlIGluIG5leHQgdmVyc2lvbi4NClRo
ZW4gSSB0aGluayBJIG5lZWQgdG8gYWRkIGEgcGFyYW1ldGVyIHRvIHN0cnVjdCB2cGNpX2Jhci4N
Ck1heWJlIEkgY2FuIG5hbWUgaXQgInJlc2l6YWJsZV9zaXplcyIgPw0KDQo+IA0KPj4gKyAgICAg
ICAgZ3ByaW50ayhYRU5MT0dfV0FSTklORywNCj4+ICsgICAgICAgICAgICAgICAgIiVwcDogbmV3
IHNpemUgJSNseCBpcyBub3Qgc3VwcG9ydGVkIGJ5IGhhcmR3YXJlXG4iLA0KPj4gKyAgICAgICAg
ICAgICAgICAmcGRldi0+c2JkZiwgc2l6ZSk7DQo+PiArDQo+PiArICAgIGJhci0+c2l6ZSA9IHNp
emU7DQo+PiArICAgIGJhci0+YWRkciA9IDA7DQo+PiArICAgIGJhci0+Z3Vlc3RfYWRkciA9IDA7
DQo+PiArICAgIHBjaV9jb25mX3dyaXRlMzIocGRldi0+c2JkZiwgcmVnLCB2YWwpOw0KPj4gK30N
Cj4+ICsNCj4+ICtzdGF0aWMgaW50IGNmX2NoZWNrIGluaXRfcmViYXIoc3RydWN0IHBjaV9kZXYg
KnBkZXYpDQo+PiArew0KPj4gKyAgICB1aW50MzJfdCBjdHJsOw0KPj4gKyAgICB1bnNpZ25lZCBp
bnQgcmViYXJfb2Zmc2V0LCBuYmFyczsNCj4+ICsNCj4+ICsgICAgcmViYXJfb2Zmc2V0ID0gcGNp
X2ZpbmRfZXh0X2NhcGFiaWxpdHkocGRldi0+c2JkZiwgUENJX0VYVF9DQVBfSURfUkVCQVIpOw0K
PiANCj4gWW91IGNhbiBkbyB0aGUgaW5pdCBhdCBkZWZpbml0aW9uOg0KPiANCj4gICAgIHVpbnQz
Ml90IGN0cmw7DQo+ICAgICB1bnNpZ25lZCBpbnQgbmJhcnM7DQo+ICAgICB1bnNpZ25lZCBpbnQg
cmViYXJfb2Zmc2V0ID0gcGNpX2ZpbmRfZXh0X2NhcGFiaWxpdHkocGRldi0+c2JkZiwNCj4gICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQQ0lf
RVhUX0NBUF9JRF9SRUJBUik7DQo+IA0KPiANCj4+ICsNCj4+ICsgICAgaWYgKCAhcmViYXJfb2Zm
c2V0ICkNCj4+ICsgICAgICAgIHJldHVybiAwOw0KPj4gKw0KPj4gKyAgICBpZiAoICFpc19oYXJk
d2FyZV9kb21haW4ocGRldi0+ZG9tYWluKSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHByaW50
aygiUmVCYXIgaXMgbm90IHN1cHBvcnRlZCBmb3IgZG9tVXNcbiIpOw0KPiANCj4gVGhpcyBuZWVk
cyBhIGJpdCBtb3JlIGluZm9ybWF0aW9uIElNTzoNCj4gDQo+IHByaW50ayhYRU5MT0dfRVJSDQo+
ICAgICAgICAiJXBkICVwcDogcmVzaXphYmxlIEJBUiBjYXBhYmlsaXR5IG5vdCBzdXBwb3J0ZWQg
Zm9yIHVucHJpdmlsZWdlZCBkb21haW5zXG4iLA0KPiAgICAgICAgcGRldi0+ZG9tYWluLCAmcGRl
di0+c2JkZik7DQpPSywgd2lsbCBjaGFuZ2UuDQpJZiB0aGUgbGVuZ3RoIG9mIGNvZGUgb2YgcHJp
bnRpbmcgbW9yZSB0aGFuIDgwIGNoYXJhY3RlcnMgaW4gb25lIGxpbmUsIGlzIGl0IGZpbmU/DQoN
Cj4gDQo+IEkgd29uZGVyIGlmIHRoaXMgc2hvdWxkIGluc3RlYWQgYmUgYW4gWFNNIGNoZWNrLCBi
dXQgdGhhdCB3b3VsZA0KPiByZXF1aXJlIGEgbmV3IFhTTSBob29rIHRvIHByb2Nlc3MgcGVybWlz
c2lvbnMgZm9yIFBDSSBjYXBhYmlsaXRpZXMuDQo+IA0KPj4gKyAgICAgICAgcmV0dXJuIC1FT1BO
T1RTVVBQOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIGN0cmwgPSBwY2lfY29uZl9yZWFkMzIo
cGRldi0+c2JkZiwgcmViYXJfb2Zmc2V0ICsgUENJX1JFQkFSX0NUUkwpOw0KPj4gKyAgICBuYmFy
cyA9IE1BU0tfRVhUUihjdHJsLCBQQ0lfUkVCQVJfQ1RSTF9OQkFSX01BU0spOw0KPj4gKw0KPj4g
KyAgICBmb3IgKCB1bnNpZ25lZCBpbnQgaSA9IDA7IGkgPCBuYmFyczsgaSsrLCByZWJhcl9vZmZz
ZXQgKz0gUENJX1JFQkFSX0NUUkwgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBpbnQgcmM7DQo+
PiArICAgICAgICB1bnNpZ25lZCBpbnQgaW5kZXg7DQo+PiArICAgICAgICBzdHJ1Y3QgdnBjaV9i
YXIgKmJhcnMgPSBwZGV2LT52cGNpLT5oZWFkZXIuYmFyczsNCj4+ICsNCj4+ICsgICAgICAgIGlu
ZGV4ID0gcGNpX2NvbmZfcmVhZDMyKHBkZXYtPnNiZGYsIHJlYmFyX29mZnNldCArIFBDSV9SRUJB
Ul9DVFJMKSAmDQo+PiArICAgICAgICAgICAgICAgIFBDSV9SRUJBUl9DVFJMX0JBUl9JRFg7DQo+
IA0KPiBZb3UgY291bGQgaW5pdGlhbGl6ZSBpbmRleCBhdCBkZWZpbml0aW9uLg0KPiANCj4+ICsN
Cj4+ICsgICAgICAgIGlmICggaW5kZXggPj0gUENJX0hFQURFUl9OT1JNQUxfTlJfQkFSUyApDQo+
PiArICAgICAgICB7DQo+PiArICAgICAgICAgICAgLyoNCj4+ICsgICAgICAgICAgICAgKiBUT0RP
OiBmb3IgZmFpbGVkIHBhdGhlcywgbmVlZCB0byBoaWRlIFJlQmFyIGNhcGFiaWxpdHkNCj4+ICsg
ICAgICAgICAgICAgKiBmcm9tIGhhcmR3YXJlIGRvbWFpbiBpbnN0ZWFkIG9mIHJldHVybmluZyBh
biBlcnJvci4NCj4+ICsgICAgICAgICAgICAgKi8NCj4+ICsgICAgICAgICAgICBwcmludGsoIiVw
cDogQkFSIG51bWJlciAldSBpbiBSRUJBUl9DVFJMIHJlZ2lzdGVyIGlzIHRvbyBiaWdcbiIsDQo+
PiArICAgICAgICAgICAgICAgICAgICZwZGV2LT5zZGYsIGluZGV4KTsNCj4gDQo+IFhFTkxPR19F
UlIsIHBsdXMgd2UgY291bGQgcHJpbnQgdGhlIGRvbWFpbiB0aGUgZGV2aWNlIHdhcyBhc3NpZ25l
ZCB0bw0KPiAocGRldi0+ZG9tYWluKS4NCj4gDQo+PiArICAgICAgICAgICAgcmV0dXJuIC1FSU5W
QUw7DQo+PiArICAgICAgICB9DQo+PiArDQo+PiArICAgICAgICBpZiAoIGJhcnNbaW5kZXhdLnR5
cGUgIT0gVlBDSV9CQVJfTUVNNjRfTE8gJiYNCj4+ICsgICAgICAgICAgICAgYmFyc1tpbmRleF0u
dHlwZSAhPSBWUENJX0JBUl9NRU0zMiApDQo+PiArICAgICAgICB7DQo+PiArICAgICAgICAgICAg
cHJpbnRrKCIlcHA6IEJBUiV1IGlzIG5vdCBpbiBtZW1vcnkgc3BhY2VcbiIsICZwZGV2LT5zYmRm
LCBpbmRleCk7DQo+PiArICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgICAgICB9
DQo+PiArDQo+PiArICAgICAgICByYyA9IHZwY2lfYWRkX3JlZ2lzdGVyKHBkZXYtPnZwY2ksIHZw
Y2lfaHdfcmVhZDMyLCB2cGNpX2h3X3dyaXRlMzIsDQo+PiArICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHJlYmFyX29mZnNldCArIFBDSV9SRUJBUl9DQVAsIDQsIE5VTEwpOw0KPj4gKyAg
ICAgICAgaWYgKCByYyApDQo+PiArICAgICAgICB7DQo+PiArICAgICAgICAgICAgcHJpbnRrKCIl
cHA6IGFkZCByZWdpc3RlciBmb3IgUENJX1JFQkFSX0NBUCBmYWlsZWQgKHJjPSVkKVxuIiwNCj4+
ICsgICAgICAgICAgICAgICAgICAgJnBkZXYtPnNiZGYsIHJjKTsNCj4+ICsgICAgICAgICAgICBy
ZXR1cm4gcmM7DQo+PiArICAgICAgICB9DQo+PiArDQo+PiArICAgICAgICByYyA9IHZwY2lfYWRk
X3JlZ2lzdGVyKHBkZXYtPnZwY2ksIHZwY2lfaHdfcmVhZDMyLCByZWJhcl9jdHJsX3dyaXRlLA0K
Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWJhcl9vZmZzZXQgKyBQQ0lfUkVC
QVJfQ1RSTCwgNCwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmJhcnNbaW5k
ZXhdKTsNCj4+ICsgICAgICAgIGlmICggcmMgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAg
ICAgIHByaW50aygiJXBwOiBhZGQgcmVnaXN0ZXIgZm9yIFBDSV9SRUJBUl9DVFJMIGZhaWxlZCAl
ZFxuIiwNCj4+ICsgICAgICAgICAgICAgICAgICAgJnBkZXYtPnNiZGYsIHJjKTsNCj4+ICsgICAg
ICAgICAgICByZXR1cm4gcmM7DQo+PiArICAgICAgICB9DQo+IA0KPiBBbGwgdGhlIGxvZyBtZXNz
YWdlcyBhYm92ZSBuZWVkIHRoZSBYRU5MT0dfRVJSIHByZWZpeCwgcGx1cyBwb3NzaWJseQ0KPiBw
cmludGluZyB0aGUgYXNzaWduZWQgZG9tYWluLg0KV2lsbCBjaGFuZ2UgYWNjb3JkaW5nIHRvIHlv
dXIgYWxsIGNvbW1lbnRzLCB0aGFuayB5b3UhDQoNCj4gDQo+IFRoYW5rcywgUm9nZXIuDQoNCi0t
IA0KQmVzdCByZWdhcmRzLA0KSmlxaWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 08:22:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 08:22:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858569.1270823 (Exim 4.92)
	(envelope-from )
	id 1tNSqg-0004T6-S8; Tue, 17 Dec 2024 08:22:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858569.1270823; Tue, 17 Dec 2024 08:22:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNSqg-0004Sz-PY; Tue, 17 Dec 2024 08:22:34 +0000
Received: by outflank-mailman (input) for mailman id 858569;
 Tue, 17 Dec 2024 08:22: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 1tNSqf-0004St-Ao
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 08:22:33 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2061b.outbound.protection.outlook.com
 [2a01:111:f403:2418::61b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0f63ddd0-bc50-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 09:22:32 +0100 (CET)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by DS0PR12MB9447.namprd12.prod.outlook.com (2603:10b6:8:1b4::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Tue, 17 Dec
 2024 08:22:29 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8251.015; Tue, 17 Dec 2024
 08:22: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: 0f63ddd0-bc50-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=OEB6SryH+RncRkUaEnKjLLukZy/D/iOWnbCxmuIV0+eIRtw9hltf9sKX/FkEiPb5W82H+cLwTVQoq4asFFbLI/S/kzgEiBuuOlnzi2nEMnFdn08jlEaPJmOr/K6J2t1DBBCGp5oMUqvyQN1SrbW2mXN4RJ5Mg6iSpXIyXUwQWEdlM1xCzKnb90GpkGA7YSkCeNtBlSdUHeif259gdkLMs84Xv1A/Uea1Wmpw/6L0qcZ/8aAq2W+DH/1y0eOuSCW9K68Gmy9+nA8phBw+L4VF2Zl7Q+Rv13ZU5X+M6L+wW0lSv9qhONHYAWVceFvfVAF3I35/wkoLOWgnNPKLg5iVhg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=gwVHidIimuTaiqlUBVJb3ndRK3bVXYzMoj55zuU/1UM=;
 b=FYVFbqsdPDZ2SBLb25d2+KWdua3ZjrBrGApdKB/OusHVvIME/t1or/bj5MfQaw8pG+8NUOc8p68E787zj4SDKrA853X+L/DisBjti06iThIPcjrefBDbSXtQIQat5yFIdjMbMY/BfXnEwGDxgJ95QU655HxJC8HccO0lBXB/zUt+2M10DsWHCHsQSZDh9LzlUINLBqaPwtIDJF0jHThAsy9Qdfd6C1JJ2VRg9sWr7/vFa4EGfCEjbqU4QI/LoBHR9Yyx2lg7vmwnvkMzcE+oqzJKA6KreXmW6QXh3VzLRK6IG1em+nUPnl+V+T4ysrxs7tCXs6GEadkmgRmVvOp74A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=gwVHidIimuTaiqlUBVJb3ndRK3bVXYzMoj55zuU/1UM=;
 b=ZciHpY5Gk+zDdhTKKC4qD/QXEzXYyfg4uz+Ac8GL2QRJ4KG/2QLZ33x/iXEy7d5Emp4VW8g0qJ21rMVgztJ/UbvFvlafcNHTx+krYj6MvK4h36/cSuSa6I0JrqvxByk/ONergAA7XI3IplRsX/W2wiyVOuyqsYwAXtMPWv2HlgU=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Andrew Cooper
	, Julien Grall , Stefano
 Stabellini , "Huang, Ray" ,
	"xen-devel@lists.xenproject.org" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v3] vpci: Add resizable bar support
Thread-Topic: [PATCH v3] vpci: Add resizable bar support
Thread-Index: AQHbTSHk/+a4JH45i0iSPkOFUem08bLov7+AgAHlKwA=
Date: Tue, 17 Dec 2024 08:22:28 +0000
Message-ID:
 
References: <20241213054232.2638640-1-Jiqian.Chen@amd.com>
 <0f75fcd2-6c5d-4be6-9fc9-3c7b6c10ae51@suse.com>
In-Reply-To: <0f75fcd2-6c5d-4be6-9fc9-3c7b6c10ae51@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8251.004)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|DS0PR12MB9447:EE_
x-ms-office365-filtering-correlation-id: 03b6f623-6947-4896-9e80-08dd1e73f22c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?T3pNSzBNNnQxM0tvNzRzenJoTUFzdjVWaFNobzdTRzRRei8xc2F5MnYzcDNW?=
 =?utf-8?B?YXMzemp2bHJZOEYwcFlnZXpBQjNEdnV4enZZejFEOXBaTGROazA0eHI0ZWlj?=
 =?utf-8?B?V1prbEVlQU5ZbXNLTkVsV0lKejVWeG1yWHJkQW5UMDFwYXJOOHBsOGl3ZnRn?=
 =?utf-8?B?eDRabnh2OEV6QmV5bWd5eUVNaEdkQzBSdXBGVnYxemJHbVV5bUJ0TzI1SjVw?=
 =?utf-8?B?N1NKcHZIRklOWlpnNGlLUkJYMy93S1Q1WUFxSUdaaGxnblNZSDRxQTk5c0x3?=
 =?utf-8?B?NGJ5c2g5RjdnWmtwOFNkTy9LRmRoaytySlJnWXA5Y3pIbjlHMTE1Wk5lNlJx?=
 =?utf-8?B?Z2RhaENPbHQyMjJDQnNkSFUyN3RsMHBLUGU0bUNwZWhud2RscklLZW9yL0hC?=
 =?utf-8?B?SDNsSmx1Lzlnd3RIa1BpV3BaQXFUTVFaL1d4c3Ayc1l3NDlSSWJGNDczWEM3?=
 =?utf-8?B?KytreEl4TW5vNzllWVY2djlyNmpQNHBNdUdpeWdrVGZIdWpSYUs1K3RvOG5j?=
 =?utf-8?B?ank0dlhRWnR0UVZqLzF5bW03S1NhbW9Rb2JJZDFXZjlYZFFyWGxhU09paFYv?=
 =?utf-8?B?eDJ3OERrMnBXVGFTU3hWN0RXVGVRSXVSSUpyZThud05SVVc4eEF6SlYwRXBP?=
 =?utf-8?B?UGg0YzluWTlncWs5bTNoZDNRV01Wd3o4SDF6SWM3T3kyMGJXaExUUjkxbWt3?=
 =?utf-8?B?MWZKVmF0T3J2WnBNWmdham0wZmZvZ2dFRlpmbTJ1ckxTUGNqSmlqanlDQmp5?=
 =?utf-8?B?SHhTcDRsZm9ST1VDdno3dzJuaXlaT0E2VDBnZmhNRkdNZVYrWXJSS3pOa1RT?=
 =?utf-8?B?elFhZW5aWW16bTZiaEJGelZ5cTdSUmlKTTBlalVvUVR0cFhYaHcyQmlrU1Fi?=
 =?utf-8?B?ZnpIcnZYclRvamRVeWRjRnJLM2wxTE00MDhVOUpoN0t1Y014Sk1VRmNJcGtk?=
 =?utf-8?B?MzhSQVl3aCtNa21RMDFrZkpOUVQ0cWJLRmoyVkVrL1NpU2JweUdLVXFlVkh0?=
 =?utf-8?B?VE9CMUxIdUlKcEFja21ZSEJ3ek9NNFFJK0NjRHFnY08xQXgxNmI5V1ovTXNn?=
 =?utf-8?B?NEFSTERwN09uL3Z1OUp4enZYb0I4RkxyNDcxVGd3VXlBbDFCN0svcXhDU3ZG?=
 =?utf-8?B?QkpaMWh0NHlUbG9MODc4c25ONkdiV1l0WlV5eE42V0IyV044ejdTOWphMTQ2?=
 =?utf-8?B?S0I1SlNpeTdDd3V5OGRUUDBtbVg1YU1kQVBKUmhOaXBrUWdKbzFGVTlleldp?=
 =?utf-8?B?R3lBcGUzVnB3SGMrR0E3RlJ3VDkyQlRMUnp6SElIbXROYWw4WGE2eTNZUExk?=
 =?utf-8?B?QTk2ZXBZWTRWQU5nUkpyMGtWbk5VWHJiWFVNTEF3cnZ0TkVMK2xLeDNSVzdX?=
 =?utf-8?B?d2MrRCtlQ0hiMjdDRWFkZDFYaDFYdkVRSnJjS21SUnE1d0xPaVQ0T1RNN0lN?=
 =?utf-8?B?T2psRUxLZUVmekE1OGZlN2FKTWEzM00vaXE0NDJXZ0FzOFJKazNTb1drOHU1?=
 =?utf-8?B?dG5NOXcxbmVVMHBUVWowQURJM2d1YkU2citwZG9NUlJwZVBodkdoYXNHYWZZ?=
 =?utf-8?B?bUhRQzVqR0g4a2dxdGp5cGt0Wm9HTVcxeDlmaUpiekRYMFY0T1Y5TkYvM0Jn?=
 =?utf-8?B?WUNZM25DVFBONThiYTJpbGJzZWhIS3daL3YyS1ZYaFpDNVd5Z00zRDBqQnhj?=
 =?utf-8?B?NnNSRVFWZEg0RVdlaTVEemFrbFROSlcvY2lCWXBxRWZrcE4vSnd5SzRuSkhi?=
 =?utf-8?B?TVRES0VQL0djSUxMdVVSbW00aWg2QTNvcThFQkxRNUFvcHFrMWpOd3FpM3hY?=
 =?utf-8?B?Mk02S0NJZjBkdHJpdE5obHVKNHpBU0VTeldaQWR5eXpQVG5hdDBCMVlTMXkr?=
 =?utf-8?B?c05ZM1ZkRW4wb0NPdURNSHRBUnZTZUdFMkl3ZVF4WGwzRUVYY21KUTUrRVI0?=
 =?utf-8?Q?H/M4OH6No2Hy5yVCETWbCkByZjiLFWHQ?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?N3dsenhLNmh4N2lsR29hRGpHN2xuTnRmQjBJQk1QN3VMMHI0VUsxSGpjR2RV?=
 =?utf-8?B?WFpvRForU0ZVL2xwNDBZU2t2dUZLYVRFMm4rbFcwWlVuYm1lMitaOWRiYThv?=
 =?utf-8?B?YnV4cUNYcnhrdzVnUXVEZ2hFa2ZXS3JYN1duSnoxQ2IxVW9aZlZ6UzBoNU1I?=
 =?utf-8?B?TWRRQ3FVems1NERQSmo5QllyY3ZWdFhHai9abGRkcXAyOXRHYm9GeDFPbC9m?=
 =?utf-8?B?S01JdlZFL3doZDFQM3pPUWZyR0Y5eEc1b0xvVDFvdDhrUDJ5bjl4TVhHSVEr?=
 =?utf-8?B?WHMxdFMxRUJublhzQ3JvQ0hlRktxWU5lQjJHSWZxODNRUTNEcXA0UVNnU3hz?=
 =?utf-8?B?M2lEdnlycjBiT292ZWkxWHJJblAzL29UeG0yYVkrbmtpOE1YSFd0TFFCSGZ2?=
 =?utf-8?B?c3paQ3pxR3BzRERjL0ZVcU9xUU1tZFE5U0RmdERCeDBTMllIQUdXVjVHSWI0?=
 =?utf-8?B?ZEdIV0Q4bHVIU1VkWnIyV0FOdXlkckJCSUZNZDFnbDFyMytIMVFoV1NuSXYx?=
 =?utf-8?B?MG5vS2l2Z0swYlpRQTI2Y041ZXhiYlFpV2RSS2lDSVVMYnphQ09jQnZIaytY?=
 =?utf-8?B?T3RrR2ovWVUyQkcyRkhiUGpGSFpSN093NERQLzJieDVqdzZaQW1TOEluTnFY?=
 =?utf-8?B?QVI2NlFoR1B5RVZMekRrZlk5djVmb0ZHWVcyY1F6dU4xMVRvVzZOZUd4Vkc1?=
 =?utf-8?B?KzJBTjRoaTN1UEV2S0xZR1d3VTN3SExwazlzaThXbWhya3RsWlhCek4vbWFQ?=
 =?utf-8?B?ck0yR2lwLzNHT2xkUU1Fdkc3MWMzZ3ZXcmJkTFJpTWU2ZFJYRTF3d21ROHVB?=
 =?utf-8?B?dGRuem9xdWJCQXpsdlgzRksvNE1QZVg1TGtQaHJTNzczcU1ZUC9KKzdDcmdN?=
 =?utf-8?B?ZEJiNDVHSHpYaEpkR28zRzdPQXl6a3VlazM5dy84Szk5TnkxQzdYanBNZGpn?=
 =?utf-8?B?UnBaOXRBU0d0Z2NyREVCaWIrY3Jmdjk4Zm9tbk13RVRtRzJrT1NSQ3dWSDhS?=
 =?utf-8?B?MEFoOHFKNjBXbHFsWEJteFJQNGgrOHNjU3Z4NTVUdHhnNnZUMnlzTWFJQTdr?=
 =?utf-8?B?bC90SU1XWWNGVURDajF1TEs4WWM4R2VXU1FvUXhuZ2VhOUkxcFpUSXozT1Zz?=
 =?utf-8?B?ZkJ1S29XWmU5MG5iZ1ZhWnRLRDNaaXB2UnF6WlY2cUc2NTlGenV1NmJYcGsv?=
 =?utf-8?B?endjTkpwbjJEZk5GZWRPaTE3cDUvMGtmaTVEL2tJdVZwT0VYRnViUXQrWE1J?=
 =?utf-8?B?VGk4cTI4RFN4ZksrcmFGeDZUL0RybENkRXRhd0lud3V6c1NhN2NITUpscUtR?=
 =?utf-8?B?Vm5OVHo4ZllBWFNZVWlpakR3Q3dlMFlINzd1QytIYVc2bkJBMllkVnRYcS9t?=
 =?utf-8?B?NXFUeUgzRHJkOVFvZnZSczRNZEVlQmxUQjBLTGdDdTJtWFhJa3p1V3U0eXJR?=
 =?utf-8?B?UnhoL3FEdnphSGFZSWprWmo4REpYbDZMWEI2N1lrVnI3c0JTb2R4NllTWU81?=
 =?utf-8?B?MEQzcS9LdnpaVVhDbFV1Q2RmUDBKaVk2MEhpNnpmT2dycm03ajZOaGtteDVp?=
 =?utf-8?B?S1ZveEdId0M2bk0rS3F6N2h2OFNDZjlNTWhDTHNZWjJQUUxycjBPbXpGMGhC?=
 =?utf-8?B?S2ZzY0IrdEJpa05kN1VKWEF5eTFFQTAvVWRlcjhrdTgvY1lYYkdxbjBrMW5C?=
 =?utf-8?B?WEFxRDZnK202eFlZZVNyRXBaVDllTE9sWXV1QjRtaVh4Y2lLbm4yYVNpLzVR?=
 =?utf-8?B?MHVaK1YvSjA2NG1wZjdPaDVxVExMNUU5dThmaEt6QjhyaWplMFcwMXVMMjU3?=
 =?utf-8?B?cEFLdll0V1l5RlVQTUpEZWliR1MyVXR2ZzVqc2tGcWZSNWlwK3BpRmx3SEhy?=
 =?utf-8?B?NEFOUjVnQjUxY2dCbGlibEt3N1ppejBGcGwzdlVWSXcwUlU3b1RMUUk1ZVdU?=
 =?utf-8?B?dFY3RVo4c0xXVkU5Nitxd05KK3NMZTV3K2JjVmx6NHp6WThzaGFDZzlQaGov?=
 =?utf-8?B?N29TNVJnNVplTVQ3NWlpMXQrMVhveEpaWXFhWFY0NW4yS0hHaUJuSFVqYXdN?=
 =?utf-8?B?bkN6dHJQY3pmejh3TmJvM21oc0l1TSs2Rnd1T1ZMcGc4QXg2bzkvdS93S0My?=
 =?utf-8?Q?XdXI=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <332D272B3600394CA777C39787847E52@amdcloud.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 03b6f623-6947-4896-9e80-08dd1e73f22c
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2024 08:22:28.8973
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: dSKaRQpB9/9UHp8eJz1XXbx8Ni3VOp7yh8kk5VkUtCGXUF3bfyWhTK4swCKaTURixfeaHgcO4Mqbt+bCQd33yg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB9447

T24gMjAyNC8xMi8xNiAxOToyNCwgSmFuIEJldWxpY2ggd3JvdGU6DQo+IE9uIDEzLjEyLjIwMjQg
MDY6NDIsIEppcWlhbiBDaGVuIHdyb3RlOg0KPj4gLS0tIC9kZXYvbnVsbA0KPj4gKysrIGIveGVu
L2RyaXZlcnMvdnBjaS9yZWJhci5jDQo+PiBAQCAtMCwwICsxLDEzMCBAQA0KPj4gKy8qIFNQRFgt
TGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9ubHkgKi8NCj4+ICsvKg0KPj4gKyAqIENvcHly
aWdodCAoQykgMjAyNCBBZHZhbmNlZCBNaWNybyBEZXZpY2VzLCBJbmMuIEFsbCBSaWdodHMgUmVz
ZXJ2ZWQuDQo+PiArICoNCj4+ICsgKiBBdXRob3I6IEppcWlhbiBDaGVuIDxKaXFpYW4uQ2hlbkBh
bWQuY29tPg0KPj4gKyAqLw0KPj4gKw0KPj4gKyNpbmNsdWRlIDx4ZW4vaHlwZXJjYWxsLmg+DQo+
PiArI2luY2x1ZGUgPHhlbi92cGNpLmg+DQo+PiArDQo+PiArc3RhdGljIHZvaWQgY2ZfY2hlY2sg
cmViYXJfY3RybF93cml0ZShjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwNCj4+ICsgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGludCByZWcsDQo+PiArICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCB2YWwsDQo+PiArICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2b2lkICpkYXRhKQ0KPj4gK3sNCj4+
ICsgICAgdWludDY0X3Qgc2l6ZTsNCj4+ICsgICAgc3RydWN0IHZwY2lfYmFyICpiYXIgPSBkYXRh
Ow0KPj4gKw0KPj4gKyAgICBzaXplID0gUENJX1JFQkFSX0NUUkxfU0laRSh2YWwpOw0KPj4gKyAg
ICBpZiAoIGJhci0+ZW5hYmxlZCApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIGlmICggc2l6ZSA9
PSBiYXItPnNpemUgKQ0KPj4gKyAgICAgICAgICAgIHJldHVybjsNCj4+ICsNCj4+ICsgICAgICAg
IC8qDQo+PiArICAgICAgICAqIFJlZnVzZSB0byByZXNpemUgYSBCQVIgd2hpbGUgbWVtb3J5IGRl
Y29kaW5nIGlzIGVuYWJsZWQsIGFzDQo+PiArICAgICAgICAqIG90aGVyd2lzZSB0aGUgc2l6ZSBv
ZiB0aGUgbWFwcGVkIHJlZ2lvbiBpbiB0aGUgcDJtIHdvdWxkIGJlY29tZQ0KPj4gKyAgICAgICAg
KiBzdGFsZSB3aXRoIHRoZSBuZXdseSBzZXQgQkFSIHNpemUsIGFuZCB0aGUgcG9zaXRpb24gb2Yg
dGhlIEJBUg0KPj4gKyAgICAgICAgKiB3b3VsZCBiZSByZXNldCB0byB1bmRlZmluZWQuICBOb3Rl
IHRoZSBQQ0llIHNwZWNpZmljYXRpb24gYWxzbw0KPj4gKyAgICAgICAgKiBmb3JiaWRzIHJlc2l6
aW5nIGEgQkFSIHdpdGggbWVtb3J5IGRlY29kaW5nIGVuYWJsZWQuDQo+PiArICAgICAgICAqLw0K
Pj4gKyAgICAgICAgZ3ByaW50ayhYRU5MT0dfRVJSLA0KPj4gKyAgICAgICAgICAgICAgICAiJXBw
OiByZWZ1c2UgdG8gcmVzaXplIEJBUiB3aXRoIG1lbW9yeSBkZWNvZGluZyBlbmFibGVkXG4iLA0K
Pj4gKyAgICAgICAgICAgICAgICAmcGRldi0+c2JkZik7DQo+PiArICAgICAgICByZXR1cm47DQo+
PiArICAgIH0NCj4+ICsNCj4+ICsgICAgaWYgKCAhKChzaXplID4+IFBDSV9SRUJBUl9TSVpFX0JJ
QVMpICYNCj4+ICsgICAgICAgICAgIE1BU0tfRVhUUihwY2lfY29uZl9yZWFkMzIocGRldi0+c2Jk
ZiwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVnIC0gUENJX1JF
QkFSX0NUUkwgKyBQQ0lfUkVCQVJfQ0FQKSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgUENJX1JFQkFSX0NBUF9TSVpFUykpICkNCj4+ICsgICAgICAgIGdwcmludGso
WEVOTE9HX1dBUk5JTkcsDQo+PiArICAgICAgICAgICAgICAgICIlcHA6IG5ldyBzaXplICUjbHgg
aXMgbm90IHN1cHBvcnRlZCBieSBoYXJkd2FyZVxuIiwNCj4+ICsgICAgICAgICAgICAgICAgJnBk
ZXYtPnNiZGYsIHNpemUpOw0KPiANCj4gVGhpcyBvbmx5IGNvdmVycyB0aGUgMU1iIC4uLiAxMjhU
YiByYW5nZS4gV2hhdCBhYm91dCB0aGUgMjU2VGIgLi4uIDhFYiBvbmU/DQpUaGFuayB5b3UgZm9y
IHJlbWluZGluZyBtZSENCkkgd2lsbCBjb25zaWRlciB0aGF0IGluIG5leHQgdmVyc2lvbi4NCg0K
PiANCj4+ICtzdGF0aWMgaW50IGNmX2NoZWNrIGluaXRfcmViYXIoc3RydWN0IHBjaV9kZXYgKnBk
ZXYpDQo+PiArew0KPj4gKyAgICB1aW50MzJfdCBjdHJsOw0KPj4gKyAgICB1bnNpZ25lZCBpbnQg
cmViYXJfb2Zmc2V0LCBuYmFyczsNCj4+ICsNCj4+ICsgICAgcmViYXJfb2Zmc2V0ID0gcGNpX2Zp
bmRfZXh0X2NhcGFiaWxpdHkocGRldi0+c2JkZiwgUENJX0VYVF9DQVBfSURfUkVCQVIpOw0KPj4g
Kw0KPj4gKyAgICBpZiAoICFyZWJhcl9vZmZzZXQgKQ0KPj4gKyAgICAgICAgcmV0dXJuIDA7DQo+
PiArDQo+PiArICAgIGlmICggIWlzX2hhcmR3YXJlX2RvbWFpbihwZGV2LT5kb21haW4pICkNCj4+
ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRrKCJSZUJhciBpcyBub3Qgc3VwcG9ydGVkIGZvciBk
b21Vc1xuIik7DQo+PiArICAgICAgICByZXR1cm4gLUVPUE5PVFNVUFA7DQo+PiArICAgIH0NCj4+
ICsNCj4+ICsgICAgY3RybCA9IHBjaV9jb25mX3JlYWQzMihwZGV2LT5zYmRmLCByZWJhcl9vZmZz
ZXQgKyBQQ0lfUkVCQVJfQ1RSTCk7DQo+PiArICAgIG5iYXJzID0gTUFTS19FWFRSKGN0cmwsIFBD
SV9SRUJBUl9DVFJMX05CQVJfTUFTSyk7DQo+PiArDQo+PiArICAgIGZvciAoIHVuc2lnbmVkIGlu
dCBpID0gMDsgaSA8IG5iYXJzOyBpKyssIHJlYmFyX29mZnNldCArPSBQQ0lfUkVCQVJfQ1RSTCAp
DQo+IA0KPiBQQ0lfUkVCQVJfQ1RSTCBpcyBhbiBvZmZzZXQ7IGl0IGNhbid0IGJlIHVzZWQgdG8g
YnVtcCByZWJhcl9vZmZzZXQgaGVyZS4NCj4gVGhhdCdsbCBuZWVkIGEgc2VwYXJhdGUgY29uc3Rh
bnQsIGV2ZW4gaWYgYm90aCBldmFsdWF0ZSB0byA4Lg0KSSB3aWxsIGFkZCBhIG5ldyBtYWNybyB0
byByZXByZXNlbnQgdGhlICc4JyBpbiByZWJhci5jDQpNYXliZSBJIGNhbiBuYW1lIGl0ICJQQ0lf
UkVCQVJfU0lOR0xFX0JBUl9MRU4iID8NCg0KPiANCj4gSmFuDQoNCi0tIA0KQmVzdCByZWdhcmRz
LA0KSmlxaWFuIENoZW4uDQo=


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 08:31:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 08:31:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858583.1270833 (Exim 4.92)
	(envelope-from )
	id 1tNSzM-00069j-Ms; Tue, 17 Dec 2024 08:31:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858583.1270833; Tue, 17 Dec 2024 08:31:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNSzM-00069c-Jd; Tue, 17 Dec 2024 08:31:32 +0000
Received: by outflank-mailman (input) for mailman id 858583;
 Tue, 17 Dec 2024 08:31: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 1tNSzL-00069W-0D
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 08:31:31 +0000
Received: from OSPPR02CU001.outbound.protection.outlook.com
 (mail-norwayeastazlp170130007.outbound.protection.outlook.com
 [2a01:111:f403:c20f::7])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4f90110a-bc51-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 09:31:28 +0100 (CET)
Received: from DU2PR04CA0342.eurprd04.prod.outlook.com (2603:10a6:10:2b4::21)
 by DU5PR08MB10493.eurprd08.prod.outlook.com (2603:10a6:10:518::7)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Tue, 17 Dec
 2024 08:31:25 +0000
Received: from DU6PEPF00009528.eurprd02.prod.outlook.com
 (2603:10a6:10:2b4:cafe::1b) by DU2PR04CA0342.outlook.office365.com
 (2603:10a6:10:2b4::21) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.21 via Frontend Transport; Tue,
 17 Dec 2024 08:31:25 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DU6PEPF00009528.mail.protection.outlook.com (10.167.8.9) with
 Microsoft SMTP
 Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.15 via
 Frontend Transport; Tue, 17 Dec 2024 08:31:24 +0000
Received: ("Tessian outbound 6a902d9511f9:v526");
 Tue, 17 Dec 2024 08:31:24 +0000
Received: from Le780b60c7bd3.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 8D777679-1714-41F6-BD90-A605D6E8133B.1; 
 Tue, 17 Dec 2024 08:31:18 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 Le780b60c7bd3.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Tue, 17 Dec 2024 08:31:18 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21)
 by AS8PR08MB6008.eurprd08.prod.outlook.com (2603:10a6:20b:29d::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.22; Tue, 17 Dec
 2024 08:31:16 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632%5]) with mapi id 15.20.8251.015; Tue, 17 Dec 2024
 08:31: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: 4f90110a-bc51-11ef-99a3-01e77a169b0f
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=oSQscCiZt97LJ5QTEhTHFiz4HhVzHFdKxZG7EBcuamh1t3YQKk4aCZTaiC/gPxpqqDtpWz4mxxMaMv9ZJGAW6UDPxWX/x7QIryjZGA43babRxjbuM5uQ1Ri0olR6RBDyc/mNxjiWiL6wBsAj7NbZiDy1yk8RUM5dGrR3h9CFfF6dkZY5V7kZCxo9megp6SyaOoM78hwmLXVczCakwMhUVaaeXVHRFT4StGlRnPpElTv/LSVA+PIMvOPSN4jB0DvPZdTqew4iAYIZhtBMt/EZGp0Weltvdli90evPvhHURlj8ZLyy0DeLAcxIwira8J8INY7hn7ozrMk+Atb4HK9hXw==
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=SEC0tfqc/UUMUkKLI5fX0XqY+czKS6Zq2mVkenu/40o=;
 b=b7tyWBo5+cxASzeRkgoJK+aRC2QqAkKQoldSIwE+OUFR8ItUcdxSLY0nEhmiR2CzCSUeJlCll4U70tRT6HCNjoSQ6iJIStyWqHbw+PvRGsiubzQIVhoeLw4LflBsyARbOJ69E9P+dBgUWZkXzw5Z+8FNtI7TExb3O2fIw9mxAybuhPfit5ecFw66y+nzzDp6DrI5gcXCpPkg803NajfPkiRw0goloJ4OLogqxGNSB1Lx7XmtvxazImtNffuhOSxaJm/AZ9kJRZi4Eed7kHsRYTu/4G/M4LEDve4LmeeDSFG2D4wflGRDASs1VqqG81SSKQDAcb0L19M1z4PmpEJr/w==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=SEC0tfqc/UUMUkKLI5fX0XqY+czKS6Zq2mVkenu/40o=;
 b=oLRC802PQIzrtXeGX5eOn47uPjQdi0JI4n04tdjwFChHxD7con/x7WCjVRTHBFcaxjgBPcDyDBl2HJncsc4LjkbFTDZkHAoK8spYVkXg3iIEgrqg9KUWvOGIKOsQWfyBxbMIMZaLSRhJOc40VxXYtGaf2lMpLHMrnV/Z7swMDNA=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 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
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 356d39b222f130eb
X-TessianGatewayMetadata: Mn/2yvhyeb16slkJ8/p4Pe1Vq2aJRM/PdhUPBnecEL42LWQb8NSSaOVHh/QhVWcTD5I0bqKF91O3nwfHxW3jB8PTVyDVHWFqrXpdRbsoY/eAgpkquarWM8YjgTdANETOykCi65jlpjrQ537oG7sjSmKPp2feuVO820ZXc5pyRXE=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=O0Y1z8pu7heE2Clx2RSKefBGTQQBt2SjABMv1k+t79pYDIfZJg7mlvgazW0w6fdfvf0Afpz3J0sYg+2Ue9f8OEeFfS/K/WXfd05Hix65UVR8FDtzP71da+7ZOWIYEq2sd5HT0/jggZ9G1opg8hmSocul4doL5a/pyPrP3LnVlxPId1Ae/R0XGckRkHYFCO5O6rt3l0lOfcMGZFkwVxZp+VbuhaW7jpbXGxcnr8+mbiK3NGvzUUZCI4iAe/Uo4tdNzfiMd/9BBySUV3TqcXYjZYj39/rfTAs+NLwA6npehndew3u1AeztjaR5rym+/KZ07GE9xUGAHatPn5JIG1y93A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=SEC0tfqc/UUMUkKLI5fX0XqY+czKS6Zq2mVkenu/40o=;
 b=MigWO1uDIAXElKxec+9ZyDBx2iNoTW7SQXPP4z73W18VR5zvC7cguhLM5zwZ9iVmWbTaD8EiBjt3neU2o5DDQ1ka+K02j7wQdv4M3pMDx2EJmfmzdGWWc18mrFRcYx91rRXNy6OcWNgiMi6tPTAyuvcpZwB5HPfm8XAQ2Ato2oRyMH0h13len2d7HZfVxRbF48iVW7h+YgSMFZagMsz5Z4ISdBDh2RagXvQUiGFs2KVB6kJwmrTb8IkZQ2ncnT0FruRK5He0K0WmEGhXPXdywCNgk43dBsRUiOeaJdrrAu7n8bhWBjD5jjP/xSUADd2UPX2tD1CyhcK2aIiBooVL8Q==
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=SEC0tfqc/UUMUkKLI5fX0XqY+czKS6Zq2mVkenu/40o=;
 b=oLRC802PQIzrtXeGX5eOn47uPjQdi0JI4n04tdjwFChHxD7con/x7WCjVRTHBFcaxjgBPcDyDBl2HJncsc4LjkbFTDZkHAoK8spYVkXg3iIEgrqg9KUWvOGIKOsQWfyBxbMIMZaLSRhJOc40VxXYtGaf2lMpLHMrnV/Z7swMDNA=
From: Luca Fancellu 
To: Ariel Otilibili 
CC: "xen-devel@lists.xenproject.org" , Jan
 Beulich , Anthony PERARD ,
	Andrew Cooper 
Subject: Re: [PATCH v2 1/1] tools, xen/scripts: clear out Python syntax
 warnings
Thread-Topic: [PATCH v2 1/1] tools, xen/scripts: clear out Python syntax
 warnings
Thread-Index: AQHbUA/lHa/DXS8C6UW0n1kPYHB8v7LqG9AA
Date: Tue, 17 Dec 2024 08:31:16 +0000
Message-ID: 
References: <20241214161350.70515-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216231128.211648-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216231128.211648-2-Ariel.Otilibili-Anieli@eurecom.fr>
In-Reply-To: <20241216231128.211648-2-Ariel.Otilibili-Anieli@eurecom.fr>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DBAPR08MB5798:EE_|AS8PR08MB6008:EE_|DU6PEPF00009528:EE_|DU5PR08MB10493:EE_
X-MS-Office365-Filtering-Correlation-Id: ee571954-6e95-454f-fed3-08dd1e75318f
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|376014|366016|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?SwDNINr3IQorvCVPSCW8SqaFkxEani5no1OnJ46SBFUH8w+7IQOiqMyauM4s?=
 =?us-ascii?Q?QAxmYBY63zWo8b0oUkxy7gSjgxin5RX5d4amgYzHKU4DOREjWBBE5fO7du4Y?=
 =?us-ascii?Q?6109LCLZe6nJdzsKrijJkws1wKiodgX3+2fYeyapLrbz2PRhgSdrOfDzIXEA?=
 =?us-ascii?Q?3JeCO3ocAQf87jFY3Vd9lTIwCtAy2KtilKn49c5zK/77vn7tOAOQ0cmIUDoN?=
 =?us-ascii?Q?TaPcAZ17p73Vs1xq4iYjilKO0EmnyTFrZk8nNKrREE4o3m5bYzXEbm+pR3Bm?=
 =?us-ascii?Q?sLkA5s/sn/X+wdqVdEnaSUIw/+FfvnoCWam64SBbSpxAUAvrsF7FpbntPsuO?=
 =?us-ascii?Q?gZkyQUqDJ9JDq7mFhfZEH9adrK5hmWym9cOwZ6oHqW70Vw1QKOCM9IyCuOBS?=
 =?us-ascii?Q?FQkJm+3DJYYf02XlFCAY0mAjVWbu86NMflgKHJF/gC3GnAu6gzcRTVzMZl6J?=
 =?us-ascii?Q?U62qTFTFI0nmD2o2sSA3yLJgF0+0bSHlI+Yv9ACC/ePJxFXJhknZEaa2H34B?=
 =?us-ascii?Q?f5rbRFZaerziV0zESgLJQ9ON49dnEwhr7nEFFv+AN1mtPlOhf8m8DoGZ7hQB?=
 =?us-ascii?Q?m1xd7vjNQDQGXQWYOgddIXaI808clT6AQKN0DrcK6iO4rGzIuI7rm64OEtAN?=
 =?us-ascii?Q?UnWZ4+uHFaxermAMgb9m1YwEN6zcvtw2YCVrc4v2xIo+nSMb8+TApdAGUSsZ?=
 =?us-ascii?Q?KOtxEKBJPTrGZPj0JApAX0o2zFggOjtcZTmBQKpnZawImyiaioimUJhHqHIg?=
 =?us-ascii?Q?euYqlZPtQUXiDEcMQ+mAQ93fdRtogrkRGPlDKZd5B7oHm9bj/MygPIixot5P?=
 =?us-ascii?Q?02Q6WjXKR26fHTWs6ZGCfT5IQpNFpZvj9xMfla8fOHM2biE1GFEXFvJCGKBs?=
 =?us-ascii?Q?+80tk11vqwLyzJ0ckfTP7uPmSSkYVn++cv9FyouS47kJWUoZG+54DMs9Qmml?=
 =?us-ascii?Q?27IhWxVCivEI7gWizP5LXQ4maZTfA2Z0cwehxT6NsVBC7sZs2rOb/P+FUk3J?=
 =?us-ascii?Q?JjhyJ3PMI0+m1wms8Sis3CP0Eu7gGeaRhxW62rOws6kGuJNacVShk5yJrxNn?=
 =?us-ascii?Q?ZChT0b+AEvatFCYgI8dJXyBvKwuv/tWJxja4wGvU5cA5vB4aXY6j1Hn+hgmZ?=
 =?us-ascii?Q?Hr9euhUfeieyOqfIKR4AtQck1V7kcOZbKCAvd3NivJHy6AwT4JyEeH8Z2Vuk?=
 =?us-ascii?Q?XXQjFBSjkxnAjtPxbhLEb6eeWJBk5uBULljbaEAF6/uFVmhKkkLhq1TStisq?=
 =?us-ascii?Q?8BZHIf4sfuYRei8YvF/zRC4dL/8p0gDAZKI7XQdV0O9DAiflr7uB0A51xAOf?=
 =?us-ascii?Q?UWiBVVe2bUBCzJ7tVOmbZk0uLGybQ5OK8/4RXZrp9tr4xnTpwKVICZkTYAhn?=
 =?us-ascii?Q?SS2iCg96yB5fZ2HBGMDCqvTkg45IHEJD70FvLMsvDGCeJwFeGldKbIKQQ4x/?=
 =?us-ascii?Q?G1X8z+dI4hwOEZS2IvtQMxTrGuzVyrQC?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6008
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender:
 ip=[2603:10a6:10:1a6::21];domain=DBAPR08MB5798.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU6PEPF00009528.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	1dd52016-3354-4551-c96d-08dd1e752ccb
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|14060799003|36860700013|376014|82310400026|35042699022;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?H/ovAJj4V6z4tzhDA7BmWDm0wR+lquf+xll28j3y2vi8+JSxdvQA/evslcYB?=
 =?us-ascii?Q?2BtznohloSiyppjg2inLKYxOjL80J8kP4yVXxFJ3pxnfgi0oTTSCDckw9Kdx?=
 =?us-ascii?Q?5QrDE0wVXHdpvGJyZLyMiFlzlBhKRcRCm6Eq/8oZ/YSmUFLs5HLTIzKlZIEF?=
 =?us-ascii?Q?QSJ1AjZL+f68nYohF8l2huZRGgDdRXsyR9ZRITE0KhKaBeT/rysv4ybBVhZH?=
 =?us-ascii?Q?Bag+FmrmKzeWXxL5v6LdjhnpsTpbCoqJAVSVauB8N36lBXg7CGe7/65hD5oh?=
 =?us-ascii?Q?6YIcxJlOu1ToefOP59/p1nhxNhyMEN5VyyaaaCSzWiubAWPLEeBDfr7OGkJQ?=
 =?us-ascii?Q?TN6+xZ/Y16LAjhTqk/GwaRQ1TUtEnvErPxOdcL1YZJ7JB9nkfr4lkdR0IyMG?=
 =?us-ascii?Q?R29XJzyT3JxJhFqj3P6vCBxBkysVyRwAqkzKqu/Sl0IBDnQcaxSoUzYnKPw/?=
 =?us-ascii?Q?NPLYtqt6DvVKAYHWEh4q4FSfJwi8Yij30+OazkzGUmd+hPMqPMKGcErCLIxE?=
 =?us-ascii?Q?Y4nJvSomt6fznYP5y/QTp5z6pYqxnfOQUcIMxqm22io3URnRdYcsB8/gVUz4?=
 =?us-ascii?Q?eCw/vFjE1CIdoRgnwXY4lcSqwy03ncqqIZaIiCvivT5zMpCRIbW6pWj4U5DU?=
 =?us-ascii?Q?E13vxMIRJ3x2UjbD+iatMDTY4lcTM3yUHkv1xpEWxN0WpfXBOQdbTcNmS5PP?=
 =?us-ascii?Q?lhXIKhGrARNYM5eUexF19NjDyv/q5UH06ntipDRgH1gnpy0qaXZIscJgCr0n?=
 =?us-ascii?Q?uIqEwC3yj3nnyh5jjisTdENvb9XhxYDdoixUiKw1Xeruu5Y14v39UpEXztbD?=
 =?us-ascii?Q?x0ICWFv6DSqV0muyQy4BaI2qPJLX9fbB3t2CNGaTyP/MV+dZ9E8TGRFbV6qZ?=
 =?us-ascii?Q?tDdW6PlLkYWCtqzzpsweSJ4lj0wyL/I93Ah44Qixw1MCJNrlul+wrAarV9mt?=
 =?us-ascii?Q?Bd5rcevma8seVA2TDNzHXUJmvFEBA+vlnbjVQxYaJk0BLksHJSn9q3PlcyFQ?=
 =?us-ascii?Q?/oz1HgzvR4F3klu3UWxxpc1HF92ku1icgH3SZvw79l/uER0lbIA9KmWdM1uF?=
 =?us-ascii?Q?MFyzGSJMHDORrwWP2LSqyZ4SNevvSaX7a81ToeqfghuiGD1CqjDCIsWJIEf7?=
 =?us-ascii?Q?LOWerO06S228vWDPjaS/sE90ZCOF2mMiYcUthbdWFsqgv/FqG6750aQjegoS?=
 =?us-ascii?Q?f6+1jtZ0Qg1Q59UzJiNShS+gJpDKyURxGZwTiPR8oM7GFrUtWhKBUVZIox+E?=
 =?us-ascii?Q?vbOFblc1EwJHvyoaHr3MfUeNlJ1fTpp+WECl+p93Pj4mJDzdVjElCzsRNHEy?=
 =?us-ascii?Q?0o6aniqdgfgj/HdkKnjdZtdPwkfVyihN/XnJ8fluNY47f4bfwH6DyWp0HTcH?=
 =?us-ascii?Q?UysTbCQe7Reegvyfs32LimVb3Xh1jYK56pAXP2blltVx4eCgyz35wL6/o87z?=
 =?us-ascii?Q?neuYE+U2oEsQ/+y+y5iy/hhD2Pbe//5wzSnCdBMHfFvVtC8MHoi/zvSIVENi?=
 =?us-ascii?Q?xHjmcCnqhvFQ7wY=3D?=
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(1800799024)(14060799003)(36860700013)(376014)(82310400026)(35042699022);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2024 08:31:24.7849
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ee571954-6e95-454f-fed3-08dd1e75318f
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DU6PEPF00009528.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU5PR08MB10493

Hi Ariel,

> On 16 Dec 2024, at 23:07, Ariel Otilibili  wrote:
>=20
> * since 3.12 invalid escape sequences generate SyntaxWarning
> * in the future, these invalid sequences will generate SyntaxError
> * therefore changed syntax to raw string notation.
>=20
> Link: https://docs.python.org/3/whatsnew/3.12.html#other-language-changes
> Fixes: d8f3a67bf98 ("pygrub: further improve grub2 support")
> Fixes: dd03048708a ("xen/pygrub: grub2/grub.cfg from RHEL 7 has new comma=
nds in menuentry")
> Fixes: d1b93ea2615 ("tools/pygrub: Make pygrub understand default entry i=
n string format")
> Fixes: 622e368758b ("Add ZFS libfsimage support patch")
> Fixes: 02b26c02c7c ("xen/scripts: add cppcheck tool to the xen-analysis.p=
y script")
> Fixes: 56c0063f4e7 ("xen/misra: xen-analysis.py: Improve the cppcheck ver=
sion check")
>=20
> Cc: Anthony PERARD 
> Cc: Luca Fancellu 
> Cc: Andrew Cooper 
> Signed-off-by: Ariel Otilibili 

For the xen_analysis tool:

Reviewed-by: Luca Fancellu 




From xen-devel-bounces@lists.xenproject.org Tue Dec 17 08:32:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 08:32:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858595.1270842 (Exim 4.92)
	(envelope-from )
	id 1tNT0h-0006jl-5n; Tue, 17 Dec 2024 08:32:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858595.1270842; Tue, 17 Dec 2024 08:32: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 1tNT0h-0006je-3B; Tue, 17 Dec 2024 08:32:55 +0000
Received: by outflank-mailman (input) for mailman id 858595;
 Tue, 17 Dec 2024 08:32: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 1tNT0g-0006j7-JM
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 08:32:54 +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 8193da50-bc51-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 09:32:52 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-436249df846so34662655e9.3
 for ; Tue, 17 Dec 2024 00:32:52 -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-4362559ec08sm165685205e9.22.2024.12.17.00.32.50
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 00:32: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: 8193da50-bc51-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734424372; x=1735029172; 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=jgjrEz0GJGTtRorLSyVu4NgoYGiJYSxNCbuun1M4fwg=;
        b=T7l/rP8iAmubzeLgA+N7d2VnDudcZXaIsAPs2VyXie2b8E0TG/MSvhomiU/jliXoZT
         Cpunhln3ZKosLvP2sAEJPsJeWUiDYsaWcKG2NPLnKg6St68p+uHmXzoHKVUnuU9F0BGM
         bsvR0Ub0xcDjfen2kANktN0U6ezzEgGPSB5Ev3mg7PCIp+CzBPq9HnBGeGUSzlE00E7/
         OM4/LRaArDxwHePr7XWodGeMGpDRlqz2Z7HtramKaH3hBEFxoEsbOV2dAJ3vIzURTI1d
         tGT9t9tzU4vhNKiacZe2BZ8VnJJZPU6h3kfZTATBcyUpzFS351AJy0M7hOlOJENl7C85
         lkOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734424372; x=1735029172;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=jgjrEz0GJGTtRorLSyVu4NgoYGiJYSxNCbuun1M4fwg=;
        b=L3wZULlpZ7px8/vNfrH2KddGGo/cIcNH3Dz9gusGzhPDtItM8jAWLfuQ2NUSGeytgC
         KTYkTx5EDSwWet6Bs4APNEmRB6C2shtUV9kONB/yBczsZuZFgFNV4LshRZSjDrS/zNPG
         icUfHxkV3J+2lq1BW8Mf1qCdhkTDQhFFFszwwjk5OwBab6BEwWnns1kVnw+/GgkwK6q+
         CUS2kGQ1prSCI4X40elGjvedlMsc9o8ucM7orUBJG9zkGpZVU4BMp5POnixADT1DLF/o
         uy0gw9foXwSn9mXRAKObrKpLtarhOU4qcaNSAeXJEyo4QciutciFNNFuP6AViSNh3gdr
         oqaw==
X-Forwarded-Encrypted: i=1; AJvYcCUpQ6pdRGyE1/+leqDQ+MK9OenN0VppJvD8aQ8zobzCXdACxVYk8WMAk3RTEoEaUwxTYsLY76/V32U=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxfhLFA/v3+hQbEqaUBlZN+V0Xl6x9KSQzL7GhbgKPJ5L6Dcv+u
	z6/STSjQbi/t0hfFa3hFpBvua28H0aFy/XnVAOUjh1NpWtW2bhMHo5gxy9jW0g==
X-Gm-Gg: ASbGnctyAxx9ijJJ3NMlFltVI2dWN34u1W18bnEJAzFVUG+LihfHkML5SVQ90Fhgy70
	CfoeKG5tYF8WSOAlklV59IT5CWvh5Fajeti7GCIXU2Oyr5UGebPtncUFS9RyuTdM9/8mv9EONQZ
	42A4eqnx4B7vUBrXYWrNmFU4Fv8eGqFGz9iZvjy+Gn5SuCcOYiRY7RFbWUVIIeg3eOky4P5tjdE
	GzwdwqTh+RkPTIE+vezAKzP22jm7Aq51iNs9+5OYmx4x0NCfgBqld8uJfk9hbvcocw8BDuC5d65
	ntET4U6XqTUE+2VuZFHo6k4UqX3ncxKruYZ0EIP+CA==
X-Google-Smtp-Source: AGHT+IH+eJHD7vVJvh0gGMfIhSRRAjRRzj7Txc7159wZttQD6+LSV6nkxJcRI48ZPtxLk+FOQpPEIw==
X-Received: by 2002:a05:600c:c89:b0:431:44fe:fd9a with SMTP id 5b1f17b1804b1-4362aa6fd6bmr124111605e9.19.1734424371981;
        Tue, 17 Dec 2024 00:32:51 -0800 (PST)
Message-ID: <3579b3ca-3634-4537-8981-fd68c60d5c6a@suse.com>
Date: Tue, 17 Dec 2024 09:32:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/7] xen/riscv: implement data and instruction cache
 operations
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 
 <19c9ef65-a5bd-4d81-89dc-c780d3ead8b8@suse.com>
 <1c8c888e-bf59-4b4d-a3a5-cd2c0c7b6565@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: <1c8c888e-bf59-4b4d-a3a5-cd2c0c7b6565@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 16.12.2024 18:40, Oleksii Kurochko wrote:
> On 12/16/24 3:23 PM, Jan Beulich wrote:
>> On 11.12.2024 18:27, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/include/asm/page.h
>>> +++ b/xen/arch/riscv/include/asm/page.h
>>> @@ -7,6 +7,7 @@
>>>   
>>>   #include 
>>>   #include 
>>> +#include 
>>>   #include 
>>>   
>>>   #include 
>>> @@ -148,9 +149,27 @@ static inline bool pte_is_mapping(pte_t p)
>>>       return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK);
>>>   }
>>>   
>>> +static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
>>> +{
>>> +#ifdef CONFIG_QEMU
>>> +    return 0;
>>> +#else
>>> +    return -EOPNOTSUPP;
>>> +#endif
>>> +}
>>> +
>>> +static inline int clean_dcache_va_range(const void *p, unsigned long size)
>>> +{
>>> +#ifdef CONFIG_QEMU
>>> +    return 0;
>>> +#else
>>> +    return -EOPNOTSUPP;
>>> +#endif
>>> +}
>> So testing on real hardware will then effectively become impossible, until
>> someone goes and implements these?
> 
> Yes...
> 
> I am not sure what better we can do. It seems like it will be the best one to check if CMO
> extensions is supported and use instructions for this extensions to implement these functions as they
> are in the specification and not expected to be changed.

Yes, using CMO when available is certainly the route to go. The main
question there is what the behavior ought to be when CMO is unavailable.

> But I want to back a little bit later to this implemntation as this not issue for QEMU as it doesn't model cache and
> h/w on which I can ask to run Xen has IO cache coherency so for it will be needed just to add a new config
> and implementation will still be 'return 0'. ( I thought to introduce instead of CONFIG_QEMU something like
> CONFIG_HAS_CACHE_COHERENCY )
> 
> And also in the spec it is mentioned:
> ```
> This suggests that RISC-V platforms prefer to support full 
> cache-coherent I/O, but it isn't actually mandatory.
> As a result, the PMBT and CMO extensions aren't mandatory either, 
> meaning that some platforms might not
> have instructions to properly flush, clean, or invalidate the cache.
> ``` Based on that I also think to implement that in the following way:
> ```
>      #ifdef CONFIG_QEMU
>      static inline int plat_clean_and_invalidate_dcache_va_range() { return 0; }
>    static inline int plat_clean_dcache_va_range() { return 0; }
>    #else /* !CONFIG_QEMU */
>      static inline void plat_clean_and_invalidate_dcache_va_range()
>    {
>      printk_once("%s: should it be implemented for your platform?\n", __func__);
>      return 0;
>    }
> 
>    static inline void plat_clean_dcache_va_range()
>    {
>      printk_once("%s: should it be implemented for your platform?\n", __func__);
>      return 0;
>    }
>    #endif
> 
>    static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
>    {
>        return plat_clean_and_invalidate_dcache_va_range();
>    }
> ....
> ```
> So we will have a notification for others none-QEMU platforms notification that probably some
> changes are required.

Yet failing to get cache management right can easily result in data corruption.
I don't think a on-time printk() is appropriate to handle the lack of respective
implementation. At least not anymore once RISC-V leaves "experimental" status.

>>> --- /dev/null
>>> +++ b/xen/arch/riscv/platforms/Kconfig
>>> @@ -0,0 +1,5 @@
>>> +config QEMU
>>> +	bool "QEMU aarch virt machine support"
>>> +	depends on RISCV_64
>> I understand Arm has it like this, but: Is QEMU really a sufficiently non-
>> ambiguous name to use?
> 
> Yes, it sounds good to me to have such naming for the platform which are running on top of QEMU.
> 
> The other option I thought about it is to use CONFIG_VIRT_PLATFORM.

I don't think QEMU should be fully omitted from the name. Nor do I think that
you can generally infer from "virtual platform" that caches aren't modeled.
What I was rather getting at is to perhaps add some qualifier to QEMU, e.g.
QEMU_PLATFORM.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 08:44:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 08:44:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858607.1270853 (Exim 4.92)
	(envelope-from )
	id 1tNTBb-0000Ba-45; Tue, 17 Dec 2024 08:44:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858607.1270853; Tue, 17 Dec 2024 08:44:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNTBb-0000BT-0y; Tue, 17 Dec 2024 08:44:11 +0000
Received: by outflank-mailman (input) for mailman id 858607;
 Tue, 17 Dec 2024 08:44: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 1tNTBa-0000BN-DW
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 08:44: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 145bfb94-bc53-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 09:44:08 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-4361c705434so35919565e9.3
 for ; Tue, 17 Dec 2024 00:44: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-4362557c54bsm164506605e9.13.2024.12.17.00.44.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 00:44: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: 145bfb94-bc53-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734425048; x=1735029848; 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=7aODO7TfAm6URX8K9VqRySZAR5rrCTpdiCRy8Wea1vw=;
        b=fj7WIOmrPguWJT7//XcitMbk+4RRavfbOzihbCLsO3k/PWku6dOWicSDPT3uNxEnWk
         AgnPK9ke2x+zpoLBipb6sL7hntAzNZOtjqPar4CPyFgIax2H32fkgHOagcoQubFVGMkz
         jz2uzkWWfjYhvJYTriU8h9pXMX/i5XMg94T8NqgXBvar9aDBNURbusmCs0Bifpy/ZvyC
         SLq77D3VYd1y305U31s/LTjv9a/GApJyB2BudFaZXlAujdFu2cA+xAdthX003bLmSTQs
         lh/SuMR4QqXgeKdjMGJpEqrgeOMKRVW0uy5LLxsjqa9I0O4RQJzKaI1pYWNF/3WKsw1k
         ougw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734425048; x=1735029848;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7aODO7TfAm6URX8K9VqRySZAR5rrCTpdiCRy8Wea1vw=;
        b=daB/550b74fNeM1ZVp2M0istunD+aU0hsDGOzLp/PgCGkTNNy+iTPjXjx5Jih/RK18
         MNW7Kt6p8FnW2u0YV9RTUrVAx6UWSz3Yv1ngAzvlTTNzsdctatg5ap/bOuca4WBPaCbt
         VWfdjhPZc4XCRVCRgd3XrD63TJUorjrFWWk1LmQ/FqZ02v6CWXlFlyNmkEfXbFekBak1
         e9MnbMuq/yc8LxkaNJnlJNSj3GCYkQypf0WZ3OK1/QgjmVvOTn5ThGt7OPDBvpIptnRy
         4UQANqpVfoNOvl1iW65R2Q6n4TqX/Swxx4uRLhvTy9+fNFlSikHyOv19U1Qd9BSQhEdF
         y5Vg==
X-Forwarded-Encrypted: i=1; AJvYcCXM4n/jcmKUEjcdHJH8AWayKsBzUVOG8+XxqvBVwgR0klJ++GQcZHxH9OC8EnUBG07Qu4b1rA5M3bs=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywxn2Mwn/72r4bLyM77KD3Zx4biZcBJdLc8MndPRoNiVLz34m89
	kNGdvua7mvFDogQ4Xm/t6yKyIHaKlbx4T0FSjzt7e4hl3p/vTMGXzQzctyn80A==
X-Gm-Gg: ASbGnct1uDFWTHb3yyY9AruWsc9zv+0j2J7AXdhD+XyCJUsJKjTO2s8hHoU62VjPN2G
	gVyJwTPZ2rnUO3tEGrLvq2yXOZEXJ6Igigo+82yEqYHd/WGn3SWJZaTF02kwm+5w+dOnDFWH92M
	K9602U1ywc3VCCbdlGahQwzlvuezIIZgaf4GWZuHWO3Q/pGBJyIhgCO3USkRF/uNqTecXu/pTkY
	QiogNDqsBs5jRO7aOPOi3DFXYcOC/vTsTRJ+uhQVF5lVbzk2iwt+hLohGXbFWk+5igHeEQjtAn0
	J1Mo8f0FN46I7mQtvdgLGyPS/hlBrZva6EE9/1MpfQ==
X-Google-Smtp-Source: AGHT+IFtE+MeaA6zhHiBnukcjj17r6kenbPE+1nMocvznF6Dfd01PeJo0aMTc5hosRR7sEUvrmV5UA==
X-Received: by 2002:a05:600c:4f84:b0:434:a711:ace4 with SMTP id 5b1f17b1804b1-4364769b30dmr24617995e9.17.1734425047727;
        Tue, 17 Dec 2024 00:44:07 -0800 (PST)
Message-ID: 
Date: Tue, 17 Dec 2024 09:44:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] vpci: Add resizable bar support
To: "Chen, Jiqian" 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini , "Huang, Ray"
 ,
 "xen-devel@lists.xenproject.org" 
References: <20241213054232.2638640-1-Jiqian.Chen@amd.com>
 <0f75fcd2-6c5d-4be6-9fc9-3c7b6c10ae51@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 17.12.2024 09:22, Chen, Jiqian wrote:
> On 2024/12/16 19:24, Jan Beulich wrote:
>> On 13.12.2024 06:42, Jiqian Chen wrote:
>>> +static int cf_check init_rebar(struct pci_dev *pdev)
>>> +{
>>> +    uint32_t ctrl;
>>> +    unsigned int rebar_offset, nbars;
>>> +
>>> +    rebar_offset = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_REBAR);
>>> +
>>> +    if ( !rebar_offset )
>>> +        return 0;
>>> +
>>> +    if ( !is_hardware_domain(pdev->domain) )
>>> +    {
>>> +        printk("ReBar is not supported for domUs\n");
>>> +        return -EOPNOTSUPP;
>>> +    }
>>> +
>>> +    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL);
>>> +    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
>>> +
>>> +    for ( unsigned int i = 0; i < nbars; i++, rebar_offset += PCI_REBAR_CTRL )
>>
>> PCI_REBAR_CTRL is an offset; it can't be used to bump rebar_offset here.
>> That'll need a separate constant, even if both evaluate to 8.
> I will add a new macro to represent the '8' in rebar.c
> Maybe I can name it "PCI_REBAR_SINGLE_BAR_LEN" ?

Naming is a 2nd step only, I think (and no really suitable name comes to mind).
Before thinking of names, I think the approach of doing the accesses here wants
reconsidering. It isn't quite right to bump rebar_offset. When using #define-s,
I'd instead expect to first move _just_ past the capability header, and then
use constants to get at capability and control registers. Alternatively, if we
want to express everything relative to rebar_offset, I think we'd want

#define PCI_REBAR_CAP(n) (4 + 8 *(n))
#define PCI_REBAR_CTRL(n) (8 + 8 *(n))

eliminating the need to alter rebar_offset (and hence disconnecting variable
name from its purpose).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 08:49:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 08:49:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858617.1270862 (Exim 4.92)
	(envelope-from )
	id 1tNTGs-0000mk-M4; Tue, 17 Dec 2024 08:49:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858617.1270862; Tue, 17 Dec 2024 08:49:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNTGs-0000md-JK; Tue, 17 Dec 2024 08:49:38 +0000
Received: by outflank-mailman (input) for mailman id 858617;
 Tue, 17 Dec 2024 08:49: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 1tNTGr-0000mX-9v
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 08:49:37 +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 d7dff08b-bc53-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 09:49:36 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-43618283d48so35997405e9.1
 for ; Tue, 17 Dec 2024 00:49:36 -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-4362571765dsm165698345e9.39.2024.12.17.00.49.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 00:49: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: d7dff08b-bc53-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734425376; x=1735030176; 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=+2QLLRvdvTDu2HlRouo/qbzquQEfVc4q7ZBXW19BzHs=;
        b=YPCNFjb2EhIAre281hi2VWEOOoNaACfyjTyH8xYDKmgyrdtVVolmpD2QbeQMSAznv7
         rQ03PG3J8UClfVqp7vEKS7PLrSK8fG8OYUiLTaxKGeSy/sJJWZKJmGA1nGVWoPhHFkJO
         R7M9GAkxIMEo62cWV3g1WXsZXYKaWBu3I5e4MTDlhGYKorv/7NCdpq5q7jxKAkY1KJMV
         7SCXyd9yBTbjTAGLfEtsUpW/zrQm4oKvlhjp+Y0opEI1O6vw9UJnJAFTCxLO309mCcn3
         p22mEblEHg+On3WwAJ1uv+NsALg7qiUuqLnOdcugrrl2GcWY38U0yXMHZ0+gWxil7c02
         Ux/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734425376; x=1735030176;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+2QLLRvdvTDu2HlRouo/qbzquQEfVc4q7ZBXW19BzHs=;
        b=bBFGvOSF2JV7ck8HS7aVMkgJjCsOqe43p4ImMWlzHyYNg1+5lD6XXyZfntnVGdm1jA
         k5fEDGI81L6C7bqpQW0qsjM3OM6MtC+SFqMHeAOInmYnt9nqS6eEOJCLkhMc+HGUgClS
         MSylEPBEFYw9FzDj9TiMxtymVQW3X1Gri70SxXsOAzOBp3sWohdG6G3lfGmAP0DZn3Gk
         Y3LJ2OpHTQ8dlYkGRd22mZYTG9/CMlVaNEEBzDhR1IZUMbUw/R9RzyKR8xdrq2I6zVRP
         1PVCQ/Lb5PVcezvyUIjeqmCRnawGwXBODrQ9ctYjhvAaIEIBRmh1TgtdBS5J01hs8URI
         uC7g==
X-Gm-Message-State: AOJu0YyowMxtaVnbeLJNMKtOabaZfSCf3LV+xUYym+WA4q5THx8oPhPZ
	NEi3CGwZQLp1Z5oEA0D5XH0SeW/e5OIBspFqwMKyhXf9VYlw5VZJbJ4XOz9nzA==
X-Gm-Gg: ASbGnctJ+oU1RPl7wJdS9B6VNTHrnSvt+K+VxR02AAU0EU1rtDvbJKTUAwC+GKOI3YZ
	G3XnfFwuPUC3/QIoCWLmsPh4xoZsQ2l9NBfv6ONJJiSWCp9nhOOb24jRu8HzK935eGAM6NivBOw
	cu4Y4yFHLBwGrSehDtHevkuSWXY4ZSu60BcDqenrOxu2imWzuFIrkRiay2mZKRy4DnnnHuVI2lj
	qB0xbV5ijte+0nzPUgTHVEkMERScVhSDnHR1wRZadcvW75W8ob4jgl/KHUFdNa0vi2E1mlBut9M
	xDCPwB2H6CNdEnfLSRO2qkFAVtmKtUCBweArCOGHkw==
X-Google-Smtp-Source: AGHT+IELd0nPHGd6ezO6i7ju9yCMVnsSyQMbZdjEhiGYPMt532z+AiR4zjt1iBPtwa1vTm7ZYMEn5Q==
X-Received: by 2002:a05:600c:358c:b0:435:194:3cdf with SMTP id 5b1f17b1804b1-4364769b2c6mr21910705e9.19.1734425375738;
        Tue, 17 Dec 2024 00:49:35 -0800 (PST)
Message-ID: <562c808f-106e-4505-87c2-71456d564916@suse.com>
Date: Tue, 17 Dec 2024 09:49:34 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] vpci: Add resizable bar support
To: "Chen, Jiqian" 
Cc: "xen-devel@lists.xenproject.org" ,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini , "Huang, Ray"
 , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20241213054232.2638640-1-Jiqian.Chen@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 17.12.2024 09:20, Chen, Jiqian wrote:
> On 2024/12/16 18:24, Roger Pau Monné wrote:
>> On Fri, Dec 13, 2024 at 01:42:32PM +0800, Jiqian Chen wrote:
>>> +    if ( !is_hardware_domain(pdev->domain) )
>>> +    {
>>> +        printk("ReBar is not supported for domUs\n");
>>
>> This needs a bit more information IMO:
>>
>> printk(XENLOG_ERR
>>        "%pd %pp: resizable BAR capability not supported for unprivileged domains\n",
>>        pdev->domain, &pdev->sbdf);
> OK, will change.
> If the length of code of printing more than 80 characters in one line, is it fine?

Technically: Yes. Imo in such cases one ought to strive though to shorten
wording as much as possible, without losing information. E.g. in this case
possibly:

    printk(XENLOG_ERR
           "%pp: resizable BARs unsupported for unpriv %pd\n",
           &pdev->sbdf, pdev->domain);

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 08:53:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 08:53:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858625.1270873 (Exim 4.92)
	(envelope-from )
	id 1tNTKp-0002dY-75; Tue, 17 Dec 2024 08:53:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858625.1270873; Tue, 17 Dec 2024 08: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 1tNTKp-0002dR-44; Tue, 17 Dec 2024 08:53:43 +0000
Received: by outflank-mailman (input) for mailman id 858625;
 Tue, 17 Dec 2024 08:53: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 1tNTKn-0002dL-On
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 08:53:41 +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 699370ae-bc54-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 09:53:40 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-434a766b475so53186125e9.1
 for ; Tue, 17 Dec 2024 00:53:40 -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-436255531b1sm169178895e9.2.2024.12.17.00.53.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 00:53: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: 699370ae-bc54-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734425620; x=1735030420; 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=7n2XuaKfUiUjrn3rk1+CMisvlSQprVNO8APALE7RQnY=;
        b=BUNDF8Agh52ZnuzUoE/mp8pp4G4tC4DSrQuHIzWhntgzP5jv8VzT4vvSxZHBER9IlU
         n4Q+rncftMf7kuDTUs+zIjEQYFj2OXifc7SXxxJhuu7SUCYWYQVc8h5THRSGc9OGRYui
         MIvyJcQhGIC3Tf2bc3JqHrmteo2dXaznok1+IQRLpSt+d5VU/YvKZSjIVCL/swyfbgtb
         rVMgcwqolYI8qUw+vSNF+lmHPaf/R/pNJG9fP33/0CZGOuHbbaho1QN6NTwcTu5Z1IOB
         uVxEG52eAZ+zUCR9BeFMy+N+RMFj8hhNMIf9dEskscfWJLTAKbF5ELEgKJuTqVnEcM4f
         uXnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734425620; x=1735030420;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7n2XuaKfUiUjrn3rk1+CMisvlSQprVNO8APALE7RQnY=;
        b=Ipvqs2Ol3BoDzQ9Kz/PyzbYVXtdkcF0VZGtwmBdXj0gFNLW4RwPjJjEIvIJN3rC4Pq
         schMbP+oqGk/wnbfNGjlv2LNHtF5GbKZH3JBMNYws3m68JVweRLgOEl4WvCx+cT0Ne/8
         jm0lApx9+YHri4DDpSfd/FxShNiIaEMdZpmDlnQTWGVjlKhJ9LZzQh2U+mqfKo2oWHab
         +zcsfTV430C/FziXeA0Ifp5BJzPlDtypAVu/VGyHvDj7CAyqVstMYM5/lCQg9wEFebQU
         bv2r5+Wdk1a2aoJ7wUv2+l5b3KzlbwtgoHUZD8SmoFG4ZaVCVPZJBPbZj0M4yfY2ae0F
         5xXA==
X-Forwarded-Encrypted: i=1; AJvYcCX54RBhddO98fo3iNQGfvWkYhtYSJecR94IVorbXNp/eVtign2NYJaCSJj8pNMsGW3/eMeJC/SbUws=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx2WTCrGjO+fwvq/urzTq42Gd9S29cZStDOlYQWVjiboMnP5PLQ
	BRxYh2GFS1PoxxbDBxlW8HWqmBSY6MDW4trhwM03pMnNJ+EK1UpDjaDbrBv0Ww==
X-Gm-Gg: ASbGncvMVNHmtuKmqd3TvQWzEfSwjONeYzSnAb+MT95SlAfCXP3lgGfFGyIdBEFJdeu
	P8k5I6SIyLtw6IlWvlulsZqb5uX7NjjtytA4RdqTL9fiGjSloo8JOppVfXrNj/TcJSit347TFjz
	mFm5QM2i7K6kgP0oFdHmluh2F0SSLO2ZssrTEDPtma9HzEHB74h3LTX3q2yef43vkr/TO09/aWx
	669ci1WXqFzXtUPLkO6mQtzDCneW3wzmCwMDhmnJ0sjgmYsFYlL5Sc2v6A1Mp8AP0XjJ1znJP6R
	+zhOKd/OIZNXRGKOpDccJ/MI9yXFbUrEvzT02sxQqg==
X-Google-Smtp-Source: AGHT+IG71G/tuI/8acYpYstoc0lqpsSUf3Pvj723OT4bt9re9zKGw4Q41BHmOYbqdxwL9JzSeEUsDQ==
X-Received: by 2002:a05:600c:1c07:b0:434:f739:7ce2 with SMTP id 5b1f17b1804b1-4362aa2e65emr124651755e9.8.1734425620176;
        Tue, 17 Dec 2024 00:53:40 -0800 (PST)
Message-ID: <837391e6-5ffd-4f4a-9bc4-c4431b5b25a2@suse.com>
Date: Tue, 17 Dec 2024 09:53:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen: add privcmd ioctl to get p2pdma_distance
To: "Zhang, Julia" 
Cc: "Deucher, Alexander" ,
 "Koenig, Christian" ,
 Xenia Ragiadakou , "Chen, Jiqian"
 , "Huang, Ray" ,
 "Penny, Zheng" , "Zhu, Lingshan"
 , Paul Durrant ,
 "Edgar E . Iglesias" ,
 "Michael S . Tsirkin" ,
 Marcel Apfelbaum ,
 Juergen Gross ,
 Oleksandr Tyshchenko ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini 
References: <20241207105946.542491-1-julia.zhang@amd.com>
 <03504a1e-c801-47fc-ac66-ab7e10ab6695@suse.com>
 
 <0284d807-ae85-4d43-93b5-91fb29528d62@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 17.12.2024 06:53, Zhang, Julia wrote:
> 
> 
> On 2024/12/16 17:19, Jan Beulich wrote:
>> On 16.12.2024 09:18, Zhang, Julia wrote:
>>> On 2024/12/9 15:47, Jan Beulich wrote:
>>> On 07.12.2024 11:59, Julia Zhang wrote:
>>
>> Yet another formality, sorry: Please send plain text emails. You'll note that what
>> I said and why you said is indistinguishably intermixed below.
> 
> Thanks for reminding.
> 
>>
>>> --- a/tools/include/xen-sys/Linux/privcmd.h
>>>
>>> +++ b/tools/include/xen-sys/Linux/privcmd.h
>>>
>>> @@ -110,6 +110,16 @@ typedef struct privcmd_map_hva_to_gpfns {
>>>
>>>     int add_mapping;
>>>
>>>   } privcmd_map_hva_to_gpfns_t;
>>>
>>>
>>>
>>> +typedef struct privcmd_p2pdma_distance {
>>>
>>> +  __u32 provider_bus;
>>>
>>> +  __u32 provider_slot;
>>>
>>> +  __u32 provider_func;
>>>
>>> +  __u32 client_bus;
>>>
>>> +  __u32 client_slot;
>>>
>>> +  __u32 client_func;
>>>
>>> +  __u32 distance;
>>>
>>> +} privcmd_p2pdma_distance_t;
>>>
>>>
>>>
>>> "Distance" typically is a symmetric thing. Why the asymmetry here? And
>>>
>>> why __u32 when __u8 will be fine for most fields? And where's the segment
>>>
>>> part of the device coordinates? Finally, with it being merely stub
>>>
>>> implementations that you add here, all details on where the needed info
>>>
>>> is to come from are missing.
>>>
>>> "Distance" is p2pdma-distance between two PCI devices, it's calculated in kernel driver.I don't get why it's symmetric?
>>
>> Distance from A to B is usually the same as that from B to A. But yes,
>> not necessarily always (thinking of e.g. rings). Yet still I'm unclear
>> about the distinction between provide and client.
> 
> Provider - A driver which provides or publishes P2P resources.
> Client - A driver which makes use of a resource.
> 
> In our case, we want to use passthrough dGPU render data, and virtio 
> iGPU display data. So dGPU need to import display buffer of iGPU. iGPU 
> is provider and dGPU is client.

Right, but: Is this arrangement relevant for the new ioctl? Aren't
you simply after the distance between two devices, of which your
provider/client model is merely a special case?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 08:57:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 08:57:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858638.1270884 (Exim 4.92)
	(envelope-from )
	id 1tNTOC-0003FP-Pt; Tue, 17 Dec 2024 08:57:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858638.1270884; Tue, 17 Dec 2024 08: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 1tNTOC-0003FI-LL; Tue, 17 Dec 2024 08:57:12 +0000
Received: by outflank-mailman (input) for mailman id 858638;
 Tue, 17 Dec 2024 08: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 1tNTOA-0003FA-Mn
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 08:57:10 +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 e6232415-bc54-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 09:57:09 +0100 (CET)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-43621d27adeso34844585e9.2
 for ; Tue, 17 Dec 2024 00: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-388c801ad9asm10404591f8f.58.2024.12.17.00.57.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 00:57: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: e6232415-bc54-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734425829; x=1735030629; 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=9ZqANH81DfpWvQHFgH/lhQ8OEBOOTblLuZ2Pzfhl1zc=;
        b=CJovTNjJh4WcYiML8J4XEUcv0Br1/j+MFLogOvz9aM/0XbV7IC9vXHrHiQslouseJD
         C6d8rwEOIc+DAxhv/3FlmFPECyrG8dRjws0hga3WecDMSOsV5nH76hsYvyU5onKg+7L9
         qVJefFapnQEMikocSgwbEvkSje9vmTPgOL6GGZZLWX6Asn35iXogM6bbo19T4OhyfW8M
         IZaGcczQzg1dX66vyBaA5MfcmJXQlEzTdOMoMfMNdVejEb6qnoiTHsXoH/UPcYi3ubJ+
         XAUWeSbIz/8QJTFOfqARo6LYmlVd/wGpG4xA+YOvvTsvikhancxjsn8Pn5uoYnDAYG55
         6TTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734425829; x=1735030629;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=9ZqANH81DfpWvQHFgH/lhQ8OEBOOTblLuZ2Pzfhl1zc=;
        b=h20K9zuGkm8ntT/9u6eQY/I5fxREpfgU7Olfr/zFQvkstOxkrEiSWsUnl3ZuSqjwbp
         8KnhPO4fR53N4xEAyeSnCriDghSKoTNKfEF9KD2T0jWr1xJBDdWl7s6qGuF2mM/amMYu
         NgJs6QuvDa19fw2+eCAQr09lkrUeFm/Yk2n8XULHgONwXv6MoR5+FK0chhkLFgJRLZJs
         ELy4H9VjFepmDoLHOcxaqJxRgxRV5dHVtR05MaTaFAQ3yZsYmbgTQo5F9bqilLj3h2n6
         FMhHfqZMyTZ7nFQaC1HiwCmPBtqHc5BwVRu4bLdUJNqo4rWbuWWi/Fk4H7LsIIylp840
         SOVg==
X-Forwarded-Encrypted: i=1; AJvYcCX4vi58mFx7XCDEtJ7WqMJi5Xll5QfXqXRPxQDFqBXKG0gTE5l00b3my7ITJjj4Wiu8XPNOuGtgnuE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw/YzaUUl9ZzUv0X3lRruiP4zHxQwxlB6Hf2Jpdl80pOfFl3SsD
	kPuE1oVTDz4WomugNaSGoKGj4Ip5vaBi/n+F7Vsmd57DzD4psxzlkGOF7gK26w==
X-Gm-Gg: ASbGncv+b0V4+Vqf24SjbUZVeVZdi+Q1KxkUDDhBi+cEVaxkxPJXjEwBa8D+G62Z2dT
	5BuRmMTE98sh737wiK+t8S/o9XoQHzBpHJXId5mFoNUlnz984pD4/Sdqz7dustM7gjJiicx2QNZ
	gUgynrdwlEs2bsku2ijRQrCyJORscuKL8Ky5Sc4tGlRmSXm75rmiX71KFU5lb2d4awN9+YOSC07
	5b9zAru3RWgHpHRGKPw+6qwfBhYHedByPkn+sKG7S1jxumfaRyIF605tt6C2RG09t1wdqgJz7Al
	YBFM6tXDxWXxLPXREc7G7BFsX8k42EexgGA+8gPZ1Q==
X-Google-Smtp-Source: AGHT+IHYMig3P9rX/ddawG9T5zluX386lW4Dq7D29209MQD8Fw/uHo1iCWQ38cFxNVevAZ8jCBpPqw==
X-Received: by 2002:a05:6000:18a5:b0:386:2fc8:ef86 with SMTP id ffacd0b85a97d-38880ad775amr12023236f8f.14.1734425827676;
        Tue, 17 Dec 2024 00:57:07 -0800 (PST)
Message-ID: <00e38f79-6185-4dcb-be69-4b08fb4a81f4@suse.com>
Date: Tue, 17 Dec 2024 09:57:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v12 01/12] xen/common: add cache coloring common code
To: Carlo Nonato 
Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-2-carlo.nonato@minervasys.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: 8bit

On 16.12.2024 17:33, Carlo Nonato wrote:
> On Mon, Dec 16, 2024 at 11:51 AM Jan Beulich  wrote:
>> On 13.12.2024 17:28, Carlo Nonato wrote:
>>> --- /dev/null
>>> +++ b/xen/common/llc-coloring.c
>>> @@ -0,0 +1,124 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +/*
>>> + * Last Level Cache (LLC) coloring common code
>>> + *
>>> + * Copyright (C) 2024, Advanced Micro Devices, Inc.
>>> + * Copyright (C) 2024, Minerva Systems SRL
>>> + */
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define NR_LLC_COLORS          (1U << CONFIG_LLC_COLORS_ORDER)
>>> +
>>> +/*
>>> + * -1: not specified (disabled unless llc-size and llc-nr-ways present)
>>> + *  0: explicitly disabled through cmdline
>>> + *  1: explicitly enabled through cmdline
>>> + */
>>> +static int8_t __initdata opt_llc_coloring = -1;
>>> +boolean_param("llc-coloring", opt_llc_coloring);
>>> +
>>> +static bool __ro_after_init llc_coloring_enabled;
>>> +
>>> +static unsigned int __initdata llc_size;
>>> +size_param("llc-size", llc_size);
>>> +static unsigned int __initdata llc_nr_ways;
>>> +integer_param("llc-nr-ways", llc_nr_ways);
>>> +/* Number of colors available in the LLC */
>>> +static unsigned int __ro_after_init max_nr_colors;
>>> +
>>> +static void print_colors(const unsigned int colors[], unsigned int num_colors)
>>> +{
>>> +    unsigned int i;
>>> +
>>> +    printk("{ ");
>>> +    for ( i = 0; i < num_colors; i++ )
>>> +    {
>>> +        unsigned int start = colors[i], end = start;
>>> +
>>> +        printk("%u", start);
>>> +
>>> +        for ( ; i < num_colors - 1 && end + 1 == colors[i + 1]; i++, end++ )
>>> +            ;
>>> +
>>> +        if ( start != end )
>>> +            printk("-%u", end);
>>> +
>>> +        if ( i < num_colors - 1 )
>>> +            printk(", ");
>>> +    }
>>> +    printk(" }\n");
>>> +}
>>> +
>>> +void __init llc_coloring_init(void)
>>> +{
>>> +    unsigned int way_size;
>>> +
>>> +    llc_coloring_enabled = (opt_llc_coloring == 1);
>>
>> Generally I'd suggest to only use > 0, >= 0, < 0, and <= 0 on such
>> variables.
>>
>>> +    if ( (opt_llc_coloring != 0) && llc_size && llc_nr_ways )
>>> +    {
>>> +        llc_coloring_enabled = true;
>>> +        way_size = llc_size / llc_nr_ways;
>>> +    }
>>
>> Hmm, I actually see a difference in someone saying
>>
>> "llc-coloring=0 llc-size=... llc-nr-ways=..."
>>
>> vs
>>
>> "llc-size=... llc-nr-ways=... llc-coloring=0"
>>
>> I'm not sure about Arm, but on x86 this can be relevant as there may be
>> pre-set parts of a command line with appended (human) overrides. Therefore
>> it always wants to be "last wins". Yet yes, you may weant to take the
>> position that in such a case the former example would require "llc-coloring=1"
>> to also be added.
> 
> Yes, I think this should be the way to go.
> 
>> Kind of against the shorthand llc-size+llc-nr-ways only,
>> though.
> 
> The shorthand was proposed by you here:
> https://patchew.org/Xen/20240315105902.160047-1-carlo.nonato@minervasys.tech/20240315105902.160047-2-carlo.nonato@minervasys.tech/#05e4d3da-4130-4c57-9855-43b685ce5005@suse.com
> 
>> Wouldn't it make sense to infer "llc-coloring" when both of the latter options
>> were supplied?
> 
> We both agreed that it was something good to have.

Right, and I'm not putting that under question. With that, however, I find
your reply ambiguous. If the shorthand is useful to have, is the requirement
to put a 2nd "llc-coloring=1" on a command line (as per above) really a good
idea?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 09:02:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 09:02:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858649.1270893 (Exim 4.92)
	(envelope-from )
	id 1tNTTY-0005BS-BW; Tue, 17 Dec 2024 09:02:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858649.1270893; Tue, 17 Dec 2024 09:02: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 1tNTTY-0005BL-7G; Tue, 17 Dec 2024 09:02:44 +0000
Received: by outflank-mailman (input) for mailman id 858649;
 Tue, 17 Dec 2024 09:02: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 1tNTTW-0005BD-Tf
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 09:02:42 +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 ac28406f-bc55-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 10:02:42 +0100 (CET)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-385e27c75f4so3866652f8f.2
 for ; Tue, 17 Dec 2024 01:02: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
 ffacd0b85a97d-388c801ace1sm10557669f8f.60.2024.12.17.01.02.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 01:02: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: ac28406f-bc55-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734426161; x=1735030961; 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=xjAZZXIZu4thRZG/EQtx9Gvia9nq9b5bV4ABjR28CUQ=;
        b=VEYZUDj5Di5jlyUDia67INEuPStoi9M8r+o7cEbtejIBcUjS3RK/iPhOVXAOlz2Mbz
         aKwtjAJPwozQUrW2uWmJzpkhSP71wjBlTGXoA1dTkNTBTzbcbbNUib4EHsWbD9Siugcc
         NJ8r7KEtibw2iKPbrbBso534wSBjjSxTlIyToFImdLZ6dxsDKN1LG0EpB/WMDtr2cjoN
         9OOyweT+sUveP1e+58JVjnSjGjOMYxMroF8B1KHC5xW1aWL7jvA3qsxwNQGKwAuFHfyT
         HTb+rIXXnv8TNmBeiy3DpnCkdXzAfOHxXN0qi63X9UVm6Bvvg0qr4OeURZEGQ2vTuU6B
         B9Xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734426161; x=1735030961;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=xjAZZXIZu4thRZG/EQtx9Gvia9nq9b5bV4ABjR28CUQ=;
        b=PTr3rzS+93CmuB3xNPcIlcYmAy5asLmtHGhm2AvsLCn4kmtdSog4rINh6p3ydpa6bv
         TPTelqxOGWvurwywM8dTHfDWaonkAMLoFEtbTvKyesYXzLy4R2GbSz5aLw5gL+e3Dn/w
         G7QwI+EfSbshAcUWIt7gdu79x0DZ+8uNAgxl8exh688UNCjRku3dZaa9FCfS2SXsFxJ9
         GfqaC5n3yRq5IJvl7q35iy4ldLrAiH3tOM1Ankqc2Ah7QYfxeePqGsFzqp2c8COUSk4c
         qmPbs/M1EGk5OZznS18yvlBD2ZvBKKMgBKd1NhwUyzbsrELGaeutTq+XfomKm6lRaXEe
         CE2Q==
X-Forwarded-Encrypted: i=1; AJvYcCWXg/69eMN/nQTPFW36rW+Sr1QdTHhGaF5cB8UiIJ8LAZtJ16+E3ak8Ug1pd3t+ReejrOZkFNtsqTw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy+SrQpgRosiRg+oORa9GrtXuXQbSXXlQ1M3he4WE7rhYlU/0ME
	ZRCxfg/nV86BSyXq7eKOjq5J5k1RfZpuf/wMYiqmDoqVt0K0FiC/9Sf6TWbC2Q==
X-Gm-Gg: ASbGnctfG5Fuo/AK7PA2ZNPYHNOeGh3V1viROGGPuAeOghCxFbY85+VEXFQmb5Jjj6d
	T/7JRtizyZrNgYS7hmG8ZVHGRHi2U+EU/zV3GxXBTNoKB47+Y0WVKoNHIr8r5s5nmoMGZ0zE6EI
	VRlSItDB9evx/56w24MSa4iY0WCfkiWsEiL3CTW6KsWM6GNS1T+efXIuN5YFluPhb4QJQF27FSD
	Q8WradBuQRuhyzAdnYMsWPIql0kpEZr4Rj35jEy5D+NCQKN4BnERZferRLnj39qZM2yYqtDAOzU
	p+AGsTvi/cQ2nqRpEoX8bcAN7glj3WMQ9VjZx1qmnA==
X-Google-Smtp-Source: AGHT+IHAwkomFfJdPR4XAeJVfEWLG80Mq1QrbUImadenqFOabRzZ0S4ZI/Y6UKUPOe4dLs8sQgDA9w==
X-Received: by 2002:a05:6000:2a8:b0:386:3262:28c6 with SMTP id ffacd0b85a97d-38880ac2d54mr12501831f8f.5.1734426160740;
        Tue, 17 Dec 2024 01:02:40 -0800 (PST)
Message-ID: <61a277f3-5650-4976-9ea2-4cb7137653da@suse.com>
Date: Tue, 17 Dec 2024 10:02:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] misra: add deviation for MISRA C Rule R11.8.
To: Alessandro Zucchelli 
Cc: consulting@bugseng.com, Simone Ballarin ,
 Doug Goldstein ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <202c8efa4f846018e463f6242d25eb10c015d835.1734367711.git.alessandro.zucchelli@bugseng.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: <202c8efa4f846018e463f6242d25eb10c015d835.1734367711.git.alessandro.zucchelli@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.12.2024 17:57, Alessandro Zucchelli wrote:
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -393,6 +393,12 @@ Fixing this violation would require to increase code complexity and lower readab
>  -config=MC3R1.R11.8,reports+={safe,"any_area(any_loc(any_exp(macro(^container_of$))))"}
>  -doc_end
>  
> +-doc_begin="Function __hvm_copy in xen/arch/x86/hvm/hvm.c is a double-use
> +function, where the parameter needs to not be const because it can be set for
> +writeor not"
> +-config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(text(^.*__hvm_copy.*$)))"}
> +-doc_end

Documentation text is quite a bit more specific than the config line.
Any function anywhere in the code (even non-x86) with a __hvm_copy infix
would be deviated this way, aiui.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 09:04:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 09:04:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858657.1270902 (Exim 4.92)
	(envelope-from )
	id 1tNTVY-0005jO-LS; Tue, 17 Dec 2024 09:04:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858657.1270902; Tue, 17 Dec 2024 09: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 1tNTVY-0005jH-It; Tue, 17 Dec 2024 09:04:48 +0000
Received: by outflank-mailman (input) for mailman id 858657;
 Tue, 17 Dec 2024 09:04: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 1tNTVX-0005jA-SA
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 09:04:47 +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 f67a58a1-bc55-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 10:04:46 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-434a766b475so53314325e9.1
 for ; Tue, 17 Dec 2024 01:04:46 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43625553234sm168873715e9.3.2024.12.17.01.04.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 01:04: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: f67a58a1-bc55-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734426286; x=1735031086; 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=QhUhfSD222VxNlcXsjSJ/iPbolQEMip+ixbS76EcuCM=;
        b=OYee+/cuz/OIqMgqgQAg8nzzDrs4Q7meE5yYHeRgXilXdGcPm9mYyjuXAMioCbjik4
         weFsYp/hyK/lp5pkEgCwAMeMkT+2wWDZSbMYjj57VUcA/pVaEL9Cc4GbPKmRNXK9X7cs
         4WKwXqceH3Rb19J3SVIlRppgm4CqXb0G2MIQQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734426286; x=1735031086;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=QhUhfSD222VxNlcXsjSJ/iPbolQEMip+ixbS76EcuCM=;
        b=JBfISDrwUsEe07A2Gn4toBSahLsojNxJgCKvjnfTs1MTJM9JoL7/Ru24XwwLOFACpB
         OVD6M6aolq4HiIKl0g5+YaO3NlLvhAbOyqHr2kegEA6Bf2h29yKDlwJ3nz8N3QrLEspy
         IdrxMTLix5pFs7BfHS66HbZaMI+nnMQitPv+guUzgX+gdD//cKWXRlj9yJK3l3W+yMuD
         7MG1YqO3vZo/63wSQTDcKxB+P/w8Rhz2YoAb93z1r8YIEFLVzejnyAXPSrvCa4x1DtiF
         Obh9H+nBkq7ijkBIyaeMT85HlqLMC+CPcYkVtBMqMluVrnNfR+jD7weZFX8M+fP2Caeh
         gZwg==
X-Gm-Message-State: AOJu0YzLpS1xoUJ5h9WAtpenQlgXrfsDWYeqjwzxPoNdfy5+H/cMRlJ0
	DKv+a4eK8Mwm/8qUVsSyNBnxUOlPiNwH+9+D9v95BHPf+duBdSxEzfj+Ao/Hgwce8CsRJWg7Ora
	/
X-Gm-Gg: ASbGncthtCudtjAIWJj87eK/z0SGVWVRhzxhAkOnKr8f71pjEi4bWlT3na11p0Au2YH
	BCIE56uOa3aitI3XPGsyZXPjQO45eEODz9apnAdaAMTgAoNHN3uDBZVu4m1UDoBUr2mu8K1vEqS
	nABv59HPC+dLw9JqmGTq5nz5AIw6L750uL+8BTYk5Fhvu/jue3PTuY5K4cy6eiY1a/38A525M1d
	XCVXCwv0O3i3NhTHOzK3GmOs9JVFddrjRI2bK2Eq2y4dHAjt1VIKTfoKS92nzuGzlc=
X-Google-Smtp-Source: AGHT+IEBO710LCTFWwUAihOCugEA3hGN50uCDGeneSo28meI4yCjdM/bnv32SmYDN5YJfiPuKXeYeA==
X-Received: by 2002:a05:600c:b99:b0:435:9ed3:5698 with SMTP id 5b1f17b1804b1-4362aa9784cmr126683715e9.24.1734426285738;
        Tue, 17 Dec 2024 01:04:45 -0800 (PST)
From: Roger Pau Monne 
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ,
	Jan Beulich ,
	Andrew Cooper ,
	Sergii Dmytruk 
Subject: [PATCH] x86/io-apic: prevent early exit from i8259 loop detection
Date: Tue, 17 Dec 2024 10:00:45 +0100
Message-ID: <20241217090045.6251-1-roger.pau@citrix.com>
X-Mailer: git-send-email 2.46.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Avoid exiting early from the loop when a pin that could be connected to the
i8259 is found, as such early exit would leave the EOI handler translation
array only partially allocated and/or initialized.

Otherwise on systems with multiple IO-APICs and an unmasked ExtINT pin on
any IO-APIC that's no the last one the following NULL pointer dereference
triggers:

(XEN) Enabling APIC mode.  Using 2 I/O APICs
(XEN) ----[ Xen-4.20-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[] __ioapic_write_entry+0x83/0x95
[...]
(XEN) Xen call trace:
(XEN)    [] R __ioapic_write_entry+0x83/0x95
(XEN)    [] F amd_iommu_ioapic_update_ire+0x1ea/0x273
(XEN)    [] F iommu_update_ire_from_apic+0xa/0xc
(XEN)    [] F __ioapic_write_entry+0x93/0x95
(XEN)    [] F arch/x86/io_apic.c#clear_IO_APIC_pin+0x7c/0x10e
(XEN)    [] F arch/x86/io_apic.c#clear_IO_APIC+0x2d/0x61
(XEN)    [] F enable_IO_APIC+0x2e3/0x34f
(XEN)    [] F smp_prepare_cpus+0x254/0x27a
(XEN)    [] F __start_xen+0x1ce1/0x23ae
(XEN)    [] F __high_start+0x8e/0x90
(XEN)
(XEN) Pagetable walk from 0000000000000000:
(XEN)  L4[0x000] = 000000007dbfd063 ffffffffffffffff
(XEN)  L3[0x000] = 000000007dbfa063 ffffffffffffffff
(XEN)  L2[0x000] = 000000007dbcc063 ffffffffffffffff
(XEN)  L1[0x000] = 0000000000000000 ffffffffffffffff
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0002]
(XEN) Faulting linear address: 0000000000000000
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...

Reported-by: Sergii Dmytruk 
Fixes: 86001b3970fe ('x86/io-apic: fix directed EOI when using AMD-Vi interrupt remapping')
Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/io_apic.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
index d9db2efc4f58..e4a88a2527d7 100644
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -1389,14 +1389,15 @@ void __init enable_IO_APIC(void)
             /* If the interrupt line is enabled and in ExtInt mode
              * I have found the pin where the i8259 is connected.
              */
-            if ((entry.mask == 0) && (entry.delivery_mode == dest_ExtINT)) {
+            if ( ioapic_i8259.apic == -1 && entry.mask == 0 &&
+                 entry.delivery_mode == dest_ExtINT )
+            {
+                ASSERT(ioapic_i8259.pin == -1);
                 ioapic_i8259.apic = apic;
                 ioapic_i8259.pin  = pin;
-                goto found_i8259;
             }
         }
     }
- found_i8259:
     /* Look to see what if the MP table has reported the ExtINT */
     /* If we could not find the appropriate pin by looking at the ioapic
      * the i8259 probably is not connected the ioapic but give the
-- 
2.46.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 09:30:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 09:30:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858670.1270912 (Exim 4.92)
	(envelope-from )
	id 1tNTtv-0000qi-FT; Tue, 17 Dec 2024 09:29:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858670.1270912; Tue, 17 Dec 2024 09: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 1tNTtv-0000qb-Ca; Tue, 17 Dec 2024 09:29:59 +0000
Received: by outflank-mailman (input) for mailman id 858670;
 Tue, 17 Dec 2024 09:29: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 1tNTtu-0000qV-4X
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 09:29:58 +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 792d1282-bc59-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 10:29:54 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-43622354a3eso35146505e9.1
 for ; Tue, 17 Dec 2024 01:29: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-4363602c9d7sm111021545e9.16.2024.12.17.01.29.53
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 01:29: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: 792d1282-bc59-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734427794; x=1735032594; 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=3A9RlaLr39wUofKB4B3KHUPUw1GkTQLzaTY0Xa0Iy4A=;
        b=I08UMmPctIHnFaYefJfZwgtZX73tyS8Ka27fyjGnKymknQFI0Y9Ee9bSrSENkZvQqj
         N97bnhLw8pNWl88egrBoRGp8WqYL4VPVz+JkZMwHA/tUKKblsVIvfuQcDzsX6Vi0jkCp
         LoWlY6udJoSrvP6jN5H9EGDeAC3kvBNz8N9/G/wOl5bTWLCftrwIwP/eivM7M8sN/Oqs
         qOw5ZMZ7OQyYuoTwEzkCJ6jNgwsIhACFudhIJ9ka5nak88XGY9x/flnDdXXHFkQi1yNo
         gL+lR1KnfKk7s/GS44A6QSIzEhZzlP7h2eb8LbCPy/w7Gp+fPdIRX9vn+D8sGhI3bYbJ
         HSoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734427794; x=1735032594;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=3A9RlaLr39wUofKB4B3KHUPUw1GkTQLzaTY0Xa0Iy4A=;
        b=GzAckfzC7gEFTdCzykroU08LFOTIqUhnLYF+FVFqnGm17ooTf5Ht2JdPQnXQOuCkeY
         LKvXFkTNCc6Vh5wWFNgVm+mGy+kcYCSbSS3BK3UPW6Cz9VafuDnp2XIw7oPL/KPVof0T
         chhXMb9jhWsqWYQ0xfx6l4WPqCxL9aPNso3e261EbkcvIKQdJ1hqPwmPkR1SbkS80k7t
         Z98IwILO06pHFBvic2uhgIQsNsH+CHGsTgj+0/n5w3t2p5c78IA2UW3SIo17lOSZkgML
         PbuY9qiopLSiJ9+wJIM3VAK59mzhwpUTuM/g97Wm+WHAVxnRdOVTG9qwmBDly5f2mFEN
         X93A==
X-Forwarded-Encrypted: i=1; AJvYcCVNVuc2Z8oGpnsO9vSBzqwuX0YQ1ow1hgnSqzQoVBxpRrrtC9IH3nUgpfUf1oGi/j/t1EcUq/HvhgY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxq+2lvUukG3slDcf1Zzo3aNpmUH8dpZxqW+DGeNZ9dOz3kDSHm
	M8KnsgICwFO6THxV0yvJ7zhRSmki80NpZJ0Vga7TJnCEmhNZlh6fnCB6RCczbg==
X-Gm-Gg: ASbGncsplHTUtbht2/UJ7LPoZYmxBBpRm1jAg7QDjhGTxjxqDbY7a7iBQuuwGZPn5SR
	6VSnWShjJehwl6HHv18zNiYlRQtSpniw29FLautK25hZDZUcfK7Ko2BtiC0ls6TqSlr7Sz8TDA6
	WoAZwcpr/6jHoo1SB4lMgU19P1GpPeprmnEy+w+SSNYhuLydNpkavZq7yjW2dsgglnLRgY+e9ow
	cIUZWVjvjMHgwivT/e3mbY3Lqy9BpeF+e0Qf73O/tGUMJo5Euhy26N0kYRHVj2NHbRgBEGOPWgc
	Jouk6jBJkCwWlYAeEgpnxI/qGQjpy2MT60NA/BY8Cg==
X-Google-Smtp-Source: AGHT+IFfXowhNC600y8aw0doIJF2sVTY+PN+VHV2XtfOM1eL1l9f8xPrTlLYGBrHh/YGIhEfL6Fpow==
X-Received: by 2002:a05:600c:524a:b0:436:488f:4f3 with SMTP id 5b1f17b1804b1-436488f0687mr20986365e9.17.1734427793816;
        Tue, 17 Dec 2024 01:29:53 -0800 (PST)
Message-ID: 
Date: Tue, 17 Dec 2024 10:29:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/1] tools/libacpi: clear ASL warning about PCI0
To: Ariel Otilibili 
Cc: Anthony PERARD , xen-devel@lists.xenproject.org
References: <20241215154659.151158-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216235241.217642-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216235241.217642-2-Ariel.Otilibili-Anieli@eurecom.fr>
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: <20241216235241.217642-2-Ariel.Otilibili-Anieli@eurecom.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.12.2024 00:50, Ariel Otilibili wrote:
> iasl complains _HID and _ADR cannot be used at the same time:
> 
> ```
> /usr/bin/iasl -vs -p tools/firmware/hvmloader/dsdt_anycpu.tmp -tc tools/firmware/hvmloader/dsdt_anycpu.asl 2>&1 | grep -B10 HID
> 
> tools/firmware/hvmloader/dsdt_anycpu.asl     40:        Device (PCI0)
> Warning  3073 -                                    Multiple types ^  (Device object requires either a _HID or _ADR, but not both)
> ```
> 
> Per ACPI 2.0 (Jul. 27, 2000; Section 6.1, page 146), the configuration was legit:
> 
> "A device object must contain either an _HID object or an _ADR object,
> but can contain both." [1]
> 
> But, per ACPI 6.5 (Aug. 2022), this is no more legit:
> 
> "A device object must contain either an _HID object or an _ADR object,
> but must not contain both." [2]
> 
> Generally _HID devices are enumerated and have their drivers loaded
> by ACPI ("ASL 2.0 Introduction and Overview", page 4).
> 
> Removing _ADR, the warning is cleared out.
> 
> The change should be compatible down to OSes released after ACPI 2.0,
> including Windows XP:

So my earlier hint apparently wasn't clear enough. I really would have
expected you to determine in what version the wording changed. Even 5.1
still has the old wording, and that's more than 10 years newer than 2.0.
And then in 6.0 the wording first changed to "but should not contain
both."

With this I'm afraid considering just WinXP is insufficient. May I also
point you at a Win2K related comment in acpi_build_tables(), seemingly
suggesting that that still was a "ACPI 1.0 operating system"? Further
in that function you'll find that apparently, besides the 1.0 special
case, we only support ACPI revisions 4 and 5. Therefore the spec change
in v6 would become relevant only once we actually supported (and
surfaced to guests) v6. At that point I'd further be of the opinion that
unless it can be proven that _ADR is unused by any OS we (ever) care(d)
about, we'd need to further split the set of DSDTs we may make use of.
One (pair) for up to 5.x with _ADR present, and another (pair) for 6.0
and newer with _ADR absent.

I'm further afraid that ...

> 1. The _HID kept in the DSDT files is the EISA ID "PNP0A03",
> Microsoft recognizes it as PCI bus:
> 
> ```
> $ curl -k -s https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/devids.txt | grep PNP0A
> 
> PNP0A00         ISA Bus
> PNP0A01         EISA Bus
> PNP0A02         MCA Bus
> PNP0A03         PCI Bus
> PNP0A04         VESA/VL Bus
> PNP0A05         Generic ACPI Bus
> PNP0A06         Generic ACPI Extended-IO Bus (EIO bus)
> ```
> 
> 2. Linux 6.12 uses also _HID for identifying PCI devices [3]:

... this fact alone means very little here. The more important question is
whether there are / were OSes which use(d) _ADR for any purpose even when
_HID is there. With just looking at the surface of just Linux, I find e.g.
a library-like function acpi_get_local_u64_address(), all users of which
would need auditing. Plus, once done, we'd then still only know the state
of things in one specific Linux version.

Bottom line: I wonder whether iasl has an option to suppress that warning.
Sadly I can't find a new enough iasl anywhere on the systems I have easy
access to, so I can't check myself. If there was no way to suppress this
warning, I'd wonder whether this wasn't a shortcoming of the tool, as the
warning is clearly inappropriate when dealing with tables for pre-v6
configurations.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 09:31:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 09:31:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858682.1270923 (Exim 4.92)
	(envelope-from )
	id 1tNTvQ-0002j6-TJ; Tue, 17 Dec 2024 09:31:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858682.1270923; Tue, 17 Dec 2024 09:31:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNTvQ-0002iz-Pu; Tue, 17 Dec 2024 09:31:32 +0000
Received: by outflank-mailman (input) for mailman id 858682;
 Tue, 17 Dec 2024 09:31: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 1tNTvP-0002ir-Bv
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 09:31:31 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20617.outbound.protection.outlook.com
 [2a01:111:f403:2414::617])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b1353277-bc59-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 10:31:29 +0100 (CET)
Received: from BL0PR0102CA0043.prod.exchangelabs.com (2603:10b6:208:25::20) by
 PH7PR12MB8121.namprd12.prod.outlook.com (2603:10b6:510:2b5::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.20; Tue, 17 Dec
 2024 09:31:24 +0000
Received: from BN1PEPF0000468A.namprd05.prod.outlook.com
 (2603:10b6:208:25:cafe::30) by BL0PR0102CA0043.outlook.office365.com
 (2603:10b6:208:25::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.22 via Frontend Transport; Tue,
 17 Dec 2024 09:31:27 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN1PEPF0000468A.mail.protection.outlook.com (10.167.243.135) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Tue, 17 Dec 2024 09:31:24 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 17 Dec
 2024 03:31:23 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 17 Dec 2024 03:31:21 -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: b1353277-bc59-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=QSldh6xWqpev9MOsFX18W5vG3cnjo3Uidzse+lsZjdK1W4MqCqBtu/BlqCj9GODmZbuep5YCgYuY4J/cKtlfucLYuR2rnD4lRxSplBrmH7giDUZD/+ahLamUAhC3WNRvdjqLRTZ8IoWcRs6P/d6NOk5bw3TUfizuEE+CAWdGA1vmz4vqQXatwVmam61Yca0Rij6T7FH+UeUe+j/Y0LJlqnNP7m0w6NI9TlXVz2guAvcbmb4uz05E1RxRmlBv7Zat0+Cp/9bVK9L9hbJsB/8uC+vLnQhtIoVxXovmUcvkfWwhj4rbtsYxMWVrNpkTLwtqIYv3fBrcuUHlqGlQT8edGw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=BJRfT8BvLOk2erNy0m/3q3H1UEdmEsNq2KmBaYzdSTs=;
 b=Rsz5r3WKQcIPTAglrdiBZIzlfVNMT9pP4XvuLcmCVAw3hC+OExDZ3NB02qSIxEtBy/yxMGk4vKdj4QLKeXTAYcIxzFfv1kfBdS9KmvK/bR1vgt1ZNDYEJtHRKI71yWBtf19wRlNjdNeDCKCoQKzwYejcZdfqzrdCpfhDdIAPfUoJmuHyMOo77P0M7RztscbvycAo9We7OxhSLqmfWH5AkE4BDNre2Od2N+az1zBnH4Ot6w7AF3t3JV45izzb/k2KawP/DmRHpT+pX97VQUiGP3iICgrwjfNO1f23ZmhpF1Y1fYoGdAdbHjXiBnVa8YEUCFLX2A/ewyy0qQZauhk3Gg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=BJRfT8BvLOk2erNy0m/3q3H1UEdmEsNq2KmBaYzdSTs=;
 b=qIlu0+haGVlHloI06ymZHmA0glQKOUNlvQOC3mJucORvRI+Tpm+yuLE9hbCCoQktWK8dfZNGx4oxTFyqwviUfjc26HbWdi87Q+RmLFQWoKuDxAlQj9t7KNjHCLNM7N1NEx/t+W81VbGRLYvYzQStbQBmyQnlLoH9B1wbDwcDr0U=
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=SATLEXMB03.amd.com; pr=C
Message-ID: <869511b5-c61b-412e-80a9-bc5b66989530@amd.com>
Date: Tue, 17 Dec 2024 10:31:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v7] xen/arm: Check for Static Heap feature when freeing
 resources
To: Luca Fancellu , 
CC: Penny Zheng , Stefano Stabellini
	, Julien Grall , Bertrand Marquis
	, Volodymyr Babchuk ,
	Andrew Cooper , Anthony PERARD
	, Jan Beulich ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Wei Chen
	
References: <20241213105047.3043403-1-luca.fancellu@arm.com>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <20241213105047.3043403-1-luca.fancellu@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN1PEPF0000468A:EE_|PH7PR12MB8121:EE_
X-MS-Office365-Filtering-Correlation-Id: 7e0ddffa-ebe4-4ef2-b8e9-08dd1e7d9306
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|376014|7416014|1800799024|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Wjd1UUdQVU1va2ViQ29ITG1lN1JjV2U4NVZ3MUIyRlRKOWc2NlpsT1FCOXRW?=
 =?utf-8?B?NW9OQ0dYdmhMaTluYlBnYnRMTlZwSTc1TTNKR3lkYks1TjlwMHFIa240dG8v?=
 =?utf-8?B?aG9DcTZIc24zRVRBeFBIVjdpU1lMd1BPWktnUFJ0a3dnZjU0N2pyQUgybDBt?=
 =?utf-8?B?T082VHdJMXZ0Rm16b2lsVFpiU0ErUHR1UTg4eWxTUXBLS0dIMU14OC95MVBR?=
 =?utf-8?B?Qzd1UCswSXg0UUVHZW5PUGw5cHNhL056S1JLaEdDNS9hTEtwUDkxUHV2Njhi?=
 =?utf-8?B?MTExYkgwdDVOR1V0ZXVWRWU3ejJmU3lKclVBb0FXRHBNaWRXS0tKL0grSG5w?=
 =?utf-8?B?bmoxTVZYSzFFbDhYS25WL1p0TXV1bjRBLzg1eVNPYzJERGhPZ0Z4RUQyR3dY?=
 =?utf-8?B?bzk0SStzS1pOc2ttSGw5a3EvVDQzcXc4ZlBZQ3ZNOEtzUVdGS24zd29SaWll?=
 =?utf-8?B?REp6ZlBxZnNERjRuODAydTFuaitnR2R6cDFRMXpoUFR4Q0NMUGthSVhqZzZv?=
 =?utf-8?B?SE1rRXRuWGIxQ1NzajRucklIbngyZW5OMmM3S3Y3TmdkemFYV3pFWWZybkVq?=
 =?utf-8?B?UlhPOGl3NjFwUEJZaDhPMU1YR3pKeW9tSWIvRjZKeXJkOVpzbHdtWEtKcU1V?=
 =?utf-8?B?ekdMVmtKamR3ajc0NTM4SE84ckZYRWQ5QVFVUzlLNkJZOElKcjA0UENZOVVl?=
 =?utf-8?B?bnNpYUhZcko2NXV5aHhiZTBsWktnQ3F6RmxFNlJJYTBCazYrTTlEZHZuSFdD?=
 =?utf-8?B?OXJWWVQweWxOS00yQlAwTG5wM2RHcWJOSVkrdUFBMVFUaG5GeEhzOThsWUh6?=
 =?utf-8?B?ZDRITVZBNE9JN09CY0Q0SitHaCt2eWxzb3NpaXhXVmo4a2RJVGhIMGxCMDkr?=
 =?utf-8?B?eHk5THF2K2l0aVVkbTJXUHVJZSt6M1AvQmt3Qkpxd2lPTW5Hc0VudjQwYkRh?=
 =?utf-8?B?TkJVRjc4NWZjUW9WYmZoL2xGK2FUTnFHZE55QzNZakZVS1l0aW1QNHp2ek9a?=
 =?utf-8?B?TnFmTFRlMU9oWElsT0VkL0tQRHVRK0gxOEtGWVdqMW84TFdaclhyKy9JUEV6?=
 =?utf-8?B?ai9WaUwvbGtURnJZdzIrOE9SUDc2SDZlM2ZaUXZTNVdzZm5sVU0wc1dzaU5U?=
 =?utf-8?B?K1BVRGZ3MnovNGNzRGZZTTdINFJxQUFKeGR2ZHZSaGgzUGtTbGRkTGRkZktZ?=
 =?utf-8?B?SkhjSkRURnpVZWVmZi9BYVMraEQ1Y3RJSVRJdE5CenY0MGp6L0xoRTNNTGJ6?=
 =?utf-8?B?Z1lWTlYzZnFmOHZSbmJqRVJDRnBONWh0WTdpRENnOWhwMkhWSlBFbWxwRWpS?=
 =?utf-8?B?WVIvTXUxOWkyKytEZTdhbm50MlAzbnNrQ0Zpc1lUcm1iVmhzMXA4QkM0L2th?=
 =?utf-8?B?eXhtZzVRaWhIOE92a0RWM09JVWJVRE9obTR2S3ExTlhiclRSQ1FIVDBvNGgv?=
 =?utf-8?B?aWlDRVM5Ti9pVEduSFhVVWd1NlRXc3llcXN1S2gzalBVVkx2WnN5dzE2Vk8x?=
 =?utf-8?B?Vk94aWZCaXJrc0ZUZ0h2Q1RUOXRyb2d0QnhBVEZrQVcwTS9yK20rdUVOZWJa?=
 =?utf-8?B?R3NUQWtLdDVtVDVOWkg2ZERjdW02amVXVithTTNLZjdTTXpnUkpPK3BhSkxM?=
 =?utf-8?B?SUlpTnR1MndSVVJ5K0xMaG02U3B2K005UEhFemJHQTdTTnFIME1XbC9kUHJE?=
 =?utf-8?B?N1VpaldaeXdmcWU3WTF3ZzBwRXlnVzZ1MmZKVDFsMXppYW1qNHBnTVJQOSsw?=
 =?utf-8?B?M0tTblYrN2I2UmxEaUhoMkVlTDJjbVh0ZGZBRysxVnUxc3F5VVR3WjF6SVNZ?=
 =?utf-8?B?b3lRTHYxUWt6QVcvNHlEdng1T0FWSHc1VTZnNzFJajdHQ25Fc0xOaGN4STY0?=
 =?utf-8?B?OUgyemx5aGdKa0J0MXkrNlY0eHVkaFVGSjN0NG8wQldIbjZpbVI1ZlREZmMx?=
 =?utf-8?B?VXNOdFFBOFB2QkZudnZiVDFNWnVjSXZXRy9oVHUyT2xpc3U1SWxWQzFVRVo0?=
 =?utf-8?Q?ApqofNwDCIPr06sPQQLs2OAG5p9uxk=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(7416014)(1800799024)(36860700013)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2024 09:31:24.2133
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7e0ddffa-ebe4-4ef2-b8e9-08dd1e7d9306
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN1PEPF0000468A.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB8121



On 13/12/2024 11:50, Luca Fancellu wrote:
> 
> 
> From: Penny Zheng 
> 
> If the Xen heap is statically configured in Device Tree, its size is
> definite, so only the defined memory shall be given to the boot
> allocator. Have a check where init_domheap_pages() is called
> which takes into account if static heap feature is used.
> 
> Extract static_heap flag from init data bootinfo, as it will be needed
> after destroying the init data section, rename it to using_static_heap
> and use it to tell whether the Xen static heap feature is enabled.
> 
> Signed-off-by: Penny Zheng 
> Signed-off-by: Wei Chen 
> Signed-off-by: Luca Fancellu 
> Reviewed-by: Michal Orzel 
I committed the patch. Thanks.

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 09:35:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 09:35:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858690.1270936 (Exim 4.92)
	(envelope-from )
	id 1tNTzS-0003LL-Ca; Tue, 17 Dec 2024 09:35:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858690.1270936; Tue, 17 Dec 2024 09:35: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 1tNTzS-0003LE-9r; Tue, 17 Dec 2024 09:35:42 +0000
Received: by outflank-mailman (input) for mailman id 858690;
 Tue, 17 Dec 2024 09:35: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 1tNTzQ-0003L4-PN
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 09:35:40 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2061d.outbound.protection.outlook.com
 [2a01:111:f403:2415::61d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 45cb2059-bc5a-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 10:35:38 +0100 (CET)
Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18)
 by SA1PR12MB7409.namprd12.prod.outlook.com (2603:10b6:806:29c::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Tue, 17 Dec
 2024 09:35:35 +0000
Received: from BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285]) by BL1PR12MB5849.namprd12.prod.outlook.com
 ([fe80::b77f:9333:3a5a:d285%4]) with mapi id 15.20.8251.015; Tue, 17 Dec 2024
 09:35: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: 45cb2059-bc5a-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=yANEByN02JMuuEiOgt+x7j8tzVlfmeeaI2Cl2HENnt71hwQa+p5QMeCNFNGo9DWADp5Qc8wCob6ebnWNflEbskIe0/Fdh4zvg8JlD0WTyAGbQIQ6KewS/EGPGuFl/+FIl9NlHhg+rgc6sHEJh9y7zlTeZpdeW0FBHcUcc5yetzyiNAQPZ8BY0sk6uYE1Q4ufTqg6oZC16Ejeifz5st6arkOSjhPFhPknwbOEbvjOyCyP+dkvW2I3LddQNTHkQnEA1ho6l+xWUD7dsGxFNR6DlPLqbeMoGsnlnyp5ME1/sofCdFGTKpnRn8lsfKUL3DSKbYxrezrGmWtr4BY9E5g+Aw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WYu04RuHbmyfowJoJn4dLaNNZdmuTAGtDJ7f8WmEpRY=;
 b=yuoMOTDV8whUGfBawijOsw5mJZm6QrpxttV9QsIg5CPr+FEuRn/FGa6zInAPAt8W6ueUSDL2iAFg5Brf8zwExSezhFCKvsX6In3fzTs4U9RId4Cu6YtGPfULB08yUf3CIBs5H++XXsYHjFKC6DDk4YNE9PJyO0OkA3SHJBLE2mG/eZYCdo1pDl+SStEIxsUhed9AyndXefh4E/E26wmqu0YQ3LlDLZv9CAtqrovn+zFCgYF9kz0a5xppRph7hPrZyjvEtKMNcRo2aNx3D0UedsMKdrXzpgtjA+/HcCEFvCJo3xMaN5w26Y+8VYC/pPaxoKkkq06NMAx82mJ9Kv9GDA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=WYu04RuHbmyfowJoJn4dLaNNZdmuTAGtDJ7f8WmEpRY=;
 b=eSxg5RnbcFQPszuXf9Uhudlr+lIpjb4j4DQ6JW2k8rFVf4jKnsfzwRtxTQY9kbIh8F1AWFX+sQSapz1kanqFmXny/QXwf/tS+Gz0kTWMcHhvSnRFuzOF2vzDBCN56LPqb6IoKuiUsTIz7eayaqwU0EXROpNTmpkro8JM8QmzLw4=
From: "Chen, Jiqian" 
To: Jan Beulich 
CC: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Andrew Cooper
	, Julien Grall , Stefano
 Stabellini , "Huang, Ray" ,
	"xen-devel@lists.xenproject.org" , "Chen,
 Jiqian" 
Subject: Re: [PATCH v3] vpci: Add resizable bar support
Thread-Topic: [PATCH v3] vpci: Add resizable bar support
Thread-Index: AQHbTSHk/+a4JH45i0iSPkOFUem08bLov7+AgAHlKwD//4B7AIAAlB2A
Date: Tue, 17 Dec 2024 09:35:35 +0000
Message-ID:
 
References: <20241213054232.2638640-1-Jiqian.Chen@amd.com>
 <0f75fcd2-6c5d-4be6-9fc9-3c7b6c10ae51@suse.com>
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: BL1PR12MB5849.namprd12.prod.outlook.com
 (15.20.8251.004)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL1PR12MB5849:EE_|SA1PR12MB7409:EE_
x-ms-office365-filtering-correlation-id: 20dac6f3-6266-42c7-57fc-08dd1e7e28d4
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?Ukc3QWtDNzNqQTBCYVZBOEE1ek15WnlyblNOU2V3ek9sNGdrcnd3d2VycmE0?=
 =?utf-8?B?V1kxaGdmTW9JWUUwQ0VkMkpxU2Qzb015dVd4VG5xQU9YZDRpQWNQVGxsZkRT?=
 =?utf-8?B?VFNtTkhxQWtMV01RcGhPMHdJME90dk9JVVJaa0RSL09UaGxXT2ZUbDkzSVlY?=
 =?utf-8?B?K1k2eUl0NEliZzRISklzWWZmaGpHSmpMYUhiNE5nZXZQbHRpNEZCNlVQVDNi?=
 =?utf-8?B?T2dFNWE5MU10dVlpK256VEpGZmFwSEhFL0QwMVRtcVJaelV6MHIvanFRRzVh?=
 =?utf-8?B?S1cyREl1NXJXanppNmVxcjFtUlJYZU5QbmwyZGRmcTUvdnNpV1NYdEZQNU45?=
 =?utf-8?B?ZUdQN2tJRFp3ZnJidEcyNHJSZlpOYUJLSWJWVlpZNGRMNHRESjlvZUc2RHcx?=
 =?utf-8?B?NG5ZWW1JRG1pbDg1TjZLTHU1dUVaZXRiY3ZkTU1la1RwKzVmRmIxODdSR0ZF?=
 =?utf-8?B?UVZXVkUzWDhnaGR6d3FNb2M4dE5WdUw3UVNuZmgwbXZ0T1dnOXVQWHlqQ0RF?=
 =?utf-8?B?b2VDZFlIVkJERmNleWRNK25PUkpzZjgwNWtaNjJNR1QxNGZ4WEEwVmY3ZTh2?=
 =?utf-8?B?UG5hQXBjL0tXMVZVaUt3WlFnbUtTdm5OVVpMSlJYL05hcmNrZlkxdHZudXJP?=
 =?utf-8?B?OTU2bnI3YkM5QU5vc25KWjFLbmxIbHlMSGE4OUFaWnpyYVJBVi9weEdBSzJZ?=
 =?utf-8?B?clMvbEo1R0xoZGlXK1VuWWdTcGlvc3VPQWRDUWFBMkxqOFYxancyNDZlTUkz?=
 =?utf-8?B?KzhVcEtHRUNzOUdoV01LQk10dWp0WWM4VTliQ1dzd0xwNW1OK1EyV0hZTnkx?=
 =?utf-8?B?RlZhdWhCbXdGb2d4czdXRDk0dWd4T3ZET0Q4RGFKcUYxWEFpRVJpZURaaG9F?=
 =?utf-8?B?MmdZT3R5Y2N6S29acDNmRThCWi94NVNaNTJwZFhxckhFcGgzazY5VXdCSUFr?=
 =?utf-8?B?dVQ5alBkYmMyZlkvWEhrT3hNVDBSY1IvUUJuZ3JqeG5xUk5ya0hIKytETUdz?=
 =?utf-8?B?UytFdGIxa3BidTd5cDBuaTdRYWRtRXJxMDRKeEVKT1RKeDFLTzB1ZFpoOTNx?=
 =?utf-8?B?WHU4RVVEVjNFaGxib3VrQkhBa3dsOUFZbGQzN2w4MFlWSkN6cTk3Wlk0ak8w?=
 =?utf-8?B?aFBoTmFTNGIyanlaemwvc0c1V296U3JDbE9aWWUxMVFYTEdkUXZZQW5nVlo2?=
 =?utf-8?B?V0I1dURkZ1ZueHltc2NkMXV0V1JiQVlxUjdvcTl5ci9FWEZ0eE93K3R3bkpG?=
 =?utf-8?B?cEttcnhNT2RnQVd4Y2Ircm1uditxc0YxY3REN0VoclUyZy8vbVlPVGRUbGlC?=
 =?utf-8?B?bWJHRmdURSt5OUNaU3EydmxRZDZiRmdhYmtia3QwaEo0UmxHZ3loRk5lb3Fs?=
 =?utf-8?B?cmhqRGlKRzFLUDJ4eFdmeDNTc3E2T3A0VWtlZDBkcXV1Z3VDYUMxSEZBdU8x?=
 =?utf-8?B?M0VUUnhib2VJK1NkZStTRzRrUG9uSlNuemlQZDJBa3lqOEpuQ3hvTFRKNE5z?=
 =?utf-8?B?ZjYwbVFEbW0zUXZJVmdjNmg4dk9mNGR5OGxxQmNXSVVqbzdmT2FQTEdiRDBV?=
 =?utf-8?B?Z1pmUmJIZDE0MHB3dXgvSndtTUR2TkZxUlBhSjdWYi9YUlNISkJTYU1qeFlO?=
 =?utf-8?B?cW5MdkpqS3Qvb2lVb2luN3NudVdkRGZLZ1Nmazl1WlljUUJYcUtQQmw5am5E?=
 =?utf-8?B?Vlc3UkVGbkRpTURQaGMwSzlaUXlNWFhpMW1FVkEvTXFKcEZXQ2YzNEFlckVs?=
 =?utf-8?B?cUttRWFYeERVSHFscHlNSHRQcU1NRHl2TThrZERnOHdVVFlyQTUxTlB5UGhK?=
 =?utf-8?B?dDc1Znk4M21kTTY4Wmw1NHlOdWZMVjM2ZXVXOHpWUEhUUmhvL3lUMTZOWGhO?=
 =?utf-8?B?Ulpva3BmandlK2c1V3dCcTFTbldwQU8xZkt5emJtTkNsbVZabUNLbFd3LzBx?=
 =?utf-8?Q?fTU1pCfUgvMIHfGadEInou5fs3um9mNa?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5849.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?RkMrNWxhbE5BMlFrclFxQ1dPalJxam80RjkrUG5nZ3RscnhBRWNCTDBDWmhB?=
 =?utf-8?B?SW8yVUszZDMrU3BHMCsrK1ZObkZCajhHdG5DZjJoL1JMekFIL2RGa0pTUzc3?=
 =?utf-8?B?UkorclYwWVFZSjBZcVNqVWJyMFd5ZXYrTW9uTlNGdzJ3U0pQaHZWR0U0MlFZ?=
 =?utf-8?B?ZGdpY0ZsdDlLMFY2RWJZZlAwZlFlRUg0TW14ZFhVRGxVNElKbmlia1VTVHlx?=
 =?utf-8?B?WHF4cDgvczJDU3NZTnd3SXZaS3NxNmFyY0pPcUFBTStpRFR6T0FoSEJlNmVW?=
 =?utf-8?B?c0FULzVxcEV4NEtMcDZ2OWViZURqREJXK09PQTFWekFCWC9VclJHZkd6VldP?=
 =?utf-8?B?UklsaEVkMW9USC9EVHVzMUw5WlRSbnYraVc4MVF1WFdIMXZVeHpib0QvT1RY?=
 =?utf-8?B?TGpIY21zaVdKWjRHamk0cjQ5ZFdiN05yUUcwQTlDZjJOSmxLVW9NU1JZRm1O?=
 =?utf-8?B?VXFkd21yRm5Pd09iYzVEM0FTWXErUGRxcFk0N2oyelpxWG8zNitZKy8zdVhY?=
 =?utf-8?B?TlNuSDl5elZCNlpzZ29hWGc5c2hQNXlZV0ZUWGNOWHNDNlNzaFV3RXU4aE5I?=
 =?utf-8?B?OFFXN0lmd2w1K2c0cEorVnE4WE1BR0l3WXBtZ2k4Tm5uamNSSkJrWk5qTTlS?=
 =?utf-8?B?Ynlzazczb3JtWHExMDQxM0NoMVhUNU9rdXM2MVl6R1RLRkRsUW9TaUJZS1dx?=
 =?utf-8?B?c2RzbzhGdXhyV201MW9DME5IcFR3K2s0N01KTWRCRlJvS1A4WHhwWHRoTHlo?=
 =?utf-8?B?MFVkTHVGUjZ1VjJHZGpwYllwMHlJLzkzRHBsSXFLMU1UVUpKV2k4Z1BsRkNF?=
 =?utf-8?B?ZW12TFpsZ1o4dkVNMFpRTzZON1VaWlRmeGFRQnV6dVorVlVaS3JHa0pHQXR1?=
 =?utf-8?B?aWlBSW5BUkdEN0NWZVVFUTJoazdDejA4QkdpekFEYnprSjZKbVFaMmdMNjBN?=
 =?utf-8?B?MFJsQmpTdXRqZzcvN21PK25mOCs2RnpiU3FLZDBpb004UitoUk5LODFEMTlq?=
 =?utf-8?B?QlFCQWxmRzA3T0k5NjVIamNTdnpYSVFWM1o1WUpUQTVTU005cU5sbUphVDlK?=
 =?utf-8?B?VVI2Z1JuVUtLMjRtemlKeXpWQ2hKSmcvVVVNaXJFOHNSWWNKL3p1R2ZtbDB4?=
 =?utf-8?B?Qmw4TTBVK0ZGVzFjaVlLSWt1cktYbUxrczh6QkZTQy9SU1htQUNYWmYxeUF0?=
 =?utf-8?B?WlA1Wk8vWVJnUkhsRHlKQUttdHZvNFI1eGlRdEwzeVk3WlpOMEQ3aWZZNlhJ?=
 =?utf-8?B?SUFTMng5K3FSRzc1V1BFSkhsWC9JbFVxR2l0NG9mK0FHaXAxSnBSSU1GMjZQ?=
 =?utf-8?B?Ynh6RGZYcTUzcU1Lc1pOVTR0T0JmUlBRL3UwNVVDWnczWVpZNjQ0dDYraGdD?=
 =?utf-8?B?V3V5TkRrNVNDdjZRTUxjSmJDeGE5U2Y3a0p1QXUvQ3FNWEgyQk94QVhXaUdS?=
 =?utf-8?B?Q00vQlRGQnRDYXRCdHJrMlNGcWNRdE9XNFVEMFRqRi8reXRQQ0ZtRjkyZVpm?=
 =?utf-8?B?T21tMlNRMWVHN0lKZ0FENWdRcUdHSm44bU5DVGJqTDIxVEx6SlJMcnJWSkNG?=
 =?utf-8?B?VHplaTZZQzc1SmYyQXNjNzdQdzhoRjRWbUpaRnFiTjRKM2J0S2lhZGNORGI2?=
 =?utf-8?B?UkZFcG5vSTJvQlozL0kvZTk2a2tVb3phdGlCNGcvV3ZVRHNxTnlndXZLWktt?=
 =?utf-8?B?ZkE1MG95WVZoZzhqWDd0c1ZvQTBsNFhJV01sSWw3MGtWelBuMVNGams3UTVG?=
 =?utf-8?B?cXhYT3BWSThEVjJia21FanB0V3pCbkllazBkRVhSVnBZNWN2Y3RJR3J3Y3Aw?=
 =?utf-8?B?akRIS2ZOMmdvaG9EdEpINWQvM3hXNUZpckdYWUdUVDYvdUEwKzFLR3o5ZHFU?=
 =?utf-8?B?RXZFUWZuY1BmMUk1UWYxRjZQZ1R4N3V1MDR0dkhtYzVvanRKdDJMMlVQTzN2?=
 =?utf-8?B?SnRPeEFnWmd2amFZVEg2SWUwckY1ZDNYc050c0xwMEZWeFdzKzg5MjRCTzFE?=
 =?utf-8?B?VlNQcytNeGx3S0o4aFhaVEV4T2FUb090eTZjYkZwMWdlZUE3cStRRCtjdE9u?=
 =?utf-8?B?eVlVM3dmaVJpaVJqaTQyNDF1a3ZsaWVXUlpTYXVWZlY1RWppdytQT1FvT1ds?=
 =?utf-8?Q?RMhU=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 20dac6f3-6266-42c7-57fc-08dd1e7e28d4
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2024 09:35:35.5833
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: i70YJM7ZeiUTstg7AyRbCIVVqQK46FD7x8vLUA3qu7gxen+RIfG01viALhNGy6MXlNFMAGYwUQSLTQ5siBjAuQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB7409

T24gMjAyNC8xMi8xNyAxNjo0NCwgSmFuIEJldWxpY2ggd3JvdGU6DQo+IE9uIDE3LjEyLjIwMjQg
MDk6MjIsIENoZW4sIEppcWlhbiB3cm90ZToNCj4+IE9uIDIwMjQvMTIvMTYgMTk6MjQsIEphbiBC
ZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDEzLjEyLjIwMjQgMDY6NDIsIEppcWlhbiBDaGVuIHdyb3Rl
Og0KPj4+PiArc3RhdGljIGludCBjZl9jaGVjayBpbml0X3JlYmFyKHN0cnVjdCBwY2lfZGV2ICpw
ZGV2KQ0KPj4+PiArew0KPj4+PiArICAgIHVpbnQzMl90IGN0cmw7DQo+Pj4+ICsgICAgdW5zaWdu
ZWQgaW50IHJlYmFyX29mZnNldCwgbmJhcnM7DQo+Pj4+ICsNCj4+Pj4gKyAgICByZWJhcl9vZmZz
ZXQgPSBwY2lfZmluZF9leHRfY2FwYWJpbGl0eShwZGV2LT5zYmRmLCBQQ0lfRVhUX0NBUF9JRF9S
RUJBUik7DQo+Pj4+ICsNCj4+Pj4gKyAgICBpZiAoICFyZWJhcl9vZmZzZXQgKQ0KPj4+PiArICAg
ICAgICByZXR1cm4gMDsNCj4+Pj4gKw0KPj4+PiArICAgIGlmICggIWlzX2hhcmR3YXJlX2RvbWFp
bihwZGV2LT5kb21haW4pICkNCj4+Pj4gKyAgICB7DQo+Pj4+ICsgICAgICAgIHByaW50aygiUmVC
YXIgaXMgbm90IHN1cHBvcnRlZCBmb3IgZG9tVXNcbiIpOw0KPj4+PiArICAgICAgICByZXR1cm4g
LUVPUE5PVFNVUFA7DQo+Pj4+ICsgICAgfQ0KPj4+PiArDQo+Pj4+ICsgICAgY3RybCA9IHBjaV9j
b25mX3JlYWQzMihwZGV2LT5zYmRmLCByZWJhcl9vZmZzZXQgKyBQQ0lfUkVCQVJfQ1RSTCk7DQo+
Pj4+ICsgICAgbmJhcnMgPSBNQVNLX0VYVFIoY3RybCwgUENJX1JFQkFSX0NUUkxfTkJBUl9NQVNL
KTsNCj4+Pj4gKw0KPj4+PiArICAgIGZvciAoIHVuc2lnbmVkIGludCBpID0gMDsgaSA8IG5iYXJz
OyBpKyssIHJlYmFyX29mZnNldCArPSBQQ0lfUkVCQVJfQ1RSTCApDQo+Pj4NCj4+PiBQQ0lfUkVC
QVJfQ1RSTCBpcyBhbiBvZmZzZXQ7IGl0IGNhbid0IGJlIHVzZWQgdG8gYnVtcCByZWJhcl9vZmZz
ZXQgaGVyZS4NCj4+PiBUaGF0J2xsIG5lZWQgYSBzZXBhcmF0ZSBjb25zdGFudCwgZXZlbiBpZiBi
b3RoIGV2YWx1YXRlIHRvIDguDQo+PiBJIHdpbGwgYWRkIGEgbmV3IG1hY3JvIHRvIHJlcHJlc2Vu
dCB0aGUgJzgnIGluIHJlYmFyLmMNCj4+IE1heWJlIEkgY2FuIG5hbWUgaXQgIlBDSV9SRUJBUl9T
SU5HTEVfQkFSX0xFTiIgPw0KPiANCj4gTmFtaW5nIGlzIGEgMm5kIHN0ZXAgb25seSwgSSB0aGlu
ayAoYW5kIG5vIHJlYWxseSBzdWl0YWJsZSBuYW1lIGNvbWVzIHRvIG1pbmQpLg0KPiBCZWZvcmUg
dGhpbmtpbmcgb2YgbmFtZXMsIEkgdGhpbmsgdGhlIGFwcHJvYWNoIG9mIGRvaW5nIHRoZSBhY2Nl
c3NlcyBoZXJlIHdhbnRzDQo+IHJlY29uc2lkZXJpbmcuIEl0IGlzbid0IHF1aXRlIHJpZ2h0IHRv
IGJ1bXAgcmViYXJfb2Zmc2V0LiBXaGVuIHVzaW5nICNkZWZpbmUtcywNCj4gSSdkIGluc3RlYWQg
ZXhwZWN0IHRvIGZpcnN0IG1vdmUgX2p1c3RfIHBhc3QgdGhlIGNhcGFiaWxpdHkgaGVhZGVyLCBh
bmQgdGhlbg0KPiB1c2UgY29uc3RhbnRzIHRvIGdldCBhdCBjYXBhYmlsaXR5IGFuZCBjb250cm9s
IHJlZ2lzdGVycy4gQWx0ZXJuYXRpdmVseSwgaWYgd2UNCj4gd2FudCB0byBleHByZXNzIGV2ZXJ5
dGhpbmcgcmVsYXRpdmUgdG8gcmViYXJfb2Zmc2V0LCBJIHRoaW5rIHdlJ2Qgd2FudA0KPiANCj4g
I2RlZmluZSBQQ0lfUkVCQVJfQ0FQKG4pICg0ICsgOCAqKG4pKQ0KPiAjZGVmaW5lIFBDSV9SRUJB
Ul9DVFJMKG4pICg4ICsgOCAqKG4pKQ0KPiANCj4gZWxpbWluYXRpbmcgdGhlIG5lZWQgdG8gYWx0
ZXIgcmViYXJfb2Zmc2V0IChhbmQgaGVuY2UgZGlzY29ubmVjdGluZyB2YXJpYWJsZQ0KPiBuYW1l
IGZyb20gaXRzIHB1cnBvc2UpLg0KSXQgc291bmRzIG11Y2ggYmV0dGVyLCB0aGFuayB5b3UgdmVy
eSBtdWNoIQ0KDQo+IA0KPiBKYW4NCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpKaXFpYW4gQ2hlbi4N
Cg==


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 09:40:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 09:40:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858703.1270948 (Exim 4.92)
	(envelope-from )
	id 1tNU4C-0004vP-WB; Tue, 17 Dec 2024 09:40:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858703.1270948; Tue, 17 Dec 2024 09:40: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 1tNU4C-0004vI-SA; Tue, 17 Dec 2024 09:40:36 +0000
Received: by outflank-mailman (input) for mailman id 858703;
 Tue, 17 Dec 2024 09:40: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 1tNU4B-0004vB-CA
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 09:40:35 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f6078dd1-bc5a-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 10:40:33 +0100 (CET)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-385e87b25f0so3988906f8f.0
 for ; Tue, 17 Dec 2024 01:40: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
 ffacd0b85a97d-388c801a8b0sm10508398f8f.53.2024.12.17.01.40.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 01:40: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: f6078dd1-bc5a-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734428433; x=1735033233; 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=nH81FfSCIIZDa7C6JLgxhb0Mejj/xRdGi8nDarQcVnc=;
        b=Vy8s8qx4c4E6q/oYWOv9YuyZF1xdXhPZwq6GjuxL7h+C1ammfvpDfb1AwIo5SnRYeD
         r0xZpDNXzd2GiMfTcnw8kutqqO2r+eJ9wU0LML/NiC/rzRiKVwwEQyyJOxvvKvCfjxCT
         0Cy+DukaW3mjgS1LhFnJR49v6xRsQ7W9BBplA99/8Pm/COg1bW/P47ammnzYK2zlNphW
         d7sakCLURj/Q/leuy7S7TTzkxkyRUekNi0V33Cp8K/BOfLm2UgVyyeAozFpx35cJoCPM
         pBbdazTjuVR2HtnklzyIl0MAL/ncvxnlz4euxRYEOIQz4msvzFeviUGUSmvHqbnoXz6K
         z4MQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734428433; x=1735033233;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nH81FfSCIIZDa7C6JLgxhb0Mejj/xRdGi8nDarQcVnc=;
        b=suOSPRH1FLXnXLfi5wRhHSCcXGkHQd1wY0XjMobzgSctki/yJg+PLX3EjlSUuXBW1O
         v2aRwyhIVEN2w9YBkTLVXVnZBo9A6hYvicr+MwCu8npq7XH+K/OIxLPB3Sll94G0TFH1
         W490X6V1R52GrJHFFP8cxbe+X4Yn7yKvc68whXYTTPP0k0EctkDmVsxvFD1FT19CtBMK
         iFko3IqTWqL1A8SiBQ3YfTXExriaqn5sOtBccnXfYYB+0XuaZYlv7YvznQHVkwBTzfVB
         ykRtfCMplBaw4KsdzpwKTbbGLEHlAqKzloEKZ0UBI5JNeHpYHAkCWhrl4zUFo0oiOMVb
         Ct9Q==
X-Forwarded-Encrypted: i=1; AJvYcCUlxTyryDVCFCMcOXCRsadOoddwc8jmKM6+UtyUazXmvDXk9Z4H8CisSqT0K3dNf+nrqv1l/rqVYcM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxGxX2gLf88BRY6suUeexNYu+tFVp7uYUZuO07WlgHnDjmluKi1
	JeHcoyxmgtZANi6ZEYl8RAeGw1fm/X1C4JWrIubBstHm9oT1YQawbKSTIL8n8g==
X-Gm-Gg: ASbGncs8vtHcorUrd2xnG7Up72cj318ILm91niQAePe9Iq5CEoOxxRf6ECZD7GNcEwf
	I3oUPfl1WC2E3BtHMW0sOFP6SUtesLqmkcdZoVMfaz/kM9gfH6s4vpXCvDK7jV5PxuYhbhUQCtq
	aUu5xLrJPaPHvEww3ItTTs9Hkg9MAzTcEPMGDtSOKqzEzBSoZRiQk1JVrZQiKUJTSzvn+/YD0Fo
	hRcsHAwrZ7HcQOY28oI36jEQUqkF4yyup2ocLRB2GsXo+3bzIkrCh8aBNrcVK3zOB7ua1es4EqD
	HSqWsZL1ByFN15WXPDr9Sp3fn25Htqi8HS+pyCciNQ==
X-Google-Smtp-Source: AGHT+IH7MhAPvUgRAQdACxoSOYiQVzioVfYuev4xjfpnEMLAVCU5jDVd9Dr7aolnKAuy3MWUYMnA9w==
X-Received: by 2002:a05:6000:1f89:b0:385:e8e7:d09a with SMTP id ffacd0b85a97d-388db22663cmr2243342f8f.2.1734428432828;
        Tue, 17 Dec 2024 01:40:32 -0800 (PST)
Message-ID: 
Date: Tue, 17 Dec 2024 10:40:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/io-apic: prevent early exit from i8259 loop detection
To: Roger Pau Monne 
Cc: Andrew Cooper ,
 Sergii Dmytruk , xen-devel@lists.xenproject.org
References: <20241217090045.6251-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: <20241217090045.6251-1-roger.pau@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 17.12.2024 10:00, Roger Pau Monne wrote:
> Avoid exiting early from the loop when a pin that could be connected to the
> i8259 is found, as such early exit would leave the EOI handler translation
> array only partially allocated and/or initialized.
> 
> Otherwise on systems with multiple IO-APICs and an unmasked ExtINT pin on
> any IO-APIC that's no the last one the following NULL pointer dereference
> triggers:
> 
> (XEN) Enabling APIC mode.  Using 2 I/O APICs
> (XEN) ----[ Xen-4.20-unstable  x86_64  debug=y  Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    e008:[] __ioapic_write_entry+0x83/0x95
> [...]
> (XEN) Xen call trace:
> (XEN)    [] R __ioapic_write_entry+0x83/0x95
> (XEN)    [] F amd_iommu_ioapic_update_ire+0x1ea/0x273
> (XEN)    [] F iommu_update_ire_from_apic+0xa/0xc
> (XEN)    [] F __ioapic_write_entry+0x93/0x95
> (XEN)    [] F arch/x86/io_apic.c#clear_IO_APIC_pin+0x7c/0x10e
> (XEN)    [] F arch/x86/io_apic.c#clear_IO_APIC+0x2d/0x61
> (XEN)    [] F enable_IO_APIC+0x2e3/0x34f
> (XEN)    [] F smp_prepare_cpus+0x254/0x27a
> (XEN)    [] F __start_xen+0x1ce1/0x23ae
> (XEN)    [] F __high_start+0x8e/0x90
> (XEN)
> (XEN) Pagetable walk from 0000000000000000:
> (XEN)  L4[0x000] = 000000007dbfd063 ffffffffffffffff
> (XEN)  L3[0x000] = 000000007dbfa063 ffffffffffffffff
> (XEN)  L2[0x000] = 000000007dbcc063 ffffffffffffffff
> (XEN)  L1[0x000] = 0000000000000000 ffffffffffffffff
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=0002]
> (XEN) Faulting linear address: 0000000000000000
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
> 
> Reported-by: Sergii Dmytruk 
> Fixes: 86001b3970fe ('x86/io-apic: fix directed EOI when using AMD-Vi interrupt remapping')
> Signed-off-by: Roger Pau Monné 

Hmm, considering the earlier change was backported, I'm even inclined to
delay 4.18.4 a little, for taking this one there as well.

> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -1389,14 +1389,15 @@ void __init enable_IO_APIC(void)
>              /* If the interrupt line is enabled and in ExtInt mode
>               * I have found the pin where the i8259 is connected.
>               */
> -            if ((entry.mask == 0) && (entry.delivery_mode == dest_ExtINT)) {
> +            if ( ioapic_i8259.apic == -1 && entry.mask == 0 &&
> +                 entry.delivery_mode == dest_ExtINT )
> +            {
> +                ASSERT(ioapic_i8259.pin == -1);

I'm not sure of the value of this assertion. It is provable that ...

>                  ioapic_i8259.apic = apic;
>                  ioapic_i8259.pin  = pin;

... both fields are updated together (and not earlier on), and hence once
we've been here neither field will still be -1.

Looking around I further notice that it's generally ioapic_i8259.pin that
we check against -1, so I wonder whether - just for consistency - the if()
condition wouldn't better too use that one.

Preferably with these adjustments:
Reviewed-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 10:14:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 10:14:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858720.1270957 (Exim 4.92)
	(envelope-from )
	id 1tNUaX-0001ew-Hw; Tue, 17 Dec 2024 10:14:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858720.1270957; Tue, 17 Dec 2024 10:14: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 1tNUaX-0001ep-Dg; Tue, 17 Dec 2024 10:14:01 +0000
Received: by outflank-mailman (input) for mailman id 858720;
 Tue, 17 Dec 2024 10:14: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 1tNUaW-0001ej-SK
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 10:14:00 +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 a1484a17-bc5f-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 11:13:58 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-385d7f19f20so2554426f8f.1
 for ; Tue, 17 Dec 2024 02:13:58 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c7fac5bbsm11066562f8f.0.2024.12.17.02.13.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 02:13: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: a1484a17-bc5f-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734430438; x=1735035238; 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=u8arajGDs6ktkoavY4rzlsf1c1cP5MJcU3EzxUXBa+U=;
        b=PUSuRzTq6G3vsPEVBOfsYLRKgH74gG90TUVYm/t7TI9TUt/UUW7MPlsTFuRh1oRLxQ
         x4d8eHBVNRhkuyK4wvg1Ss7dFTXJ4a9Q3bttErsfJc4OpQGH+uLEy4Xa15WEgzZN7Bsx
         3gc/jCbfrvZsG8gloTZNK3SavIZCSv/uFpnl8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734430438; x=1735035238;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=u8arajGDs6ktkoavY4rzlsf1c1cP5MJcU3EzxUXBa+U=;
        b=miiswObtsaA8/U8vx7MYVQEALWPfFGysbla0WcojrjY+XZLgVu12gsbyISKtJMKI+9
         xOKTFOVOA6cIynp/TDwKT78XS1jREI7KvXxMGZk81PDd7pbldt1YVGF0JhuKb38n12bP
         4UNK5v4C3nq5q/OFg7rLnoUB2Wl8wjeQsVL21dxVlUomU6exLe1EOVDA8bk9y2Yzwu3O
         JHsvb40RoqE1zpuwhdewxmaVhCHDKckibEHtSO8u2jenvrlKhbO58JFQO2sfE2DGyhl+
         MBBTLWHF69zk+LIAcPB9RgmHs887Vsj2+8byMya8Jl/O3WoJiK0k7rfs6uFSXMcpDsLd
         IV2Q==
X-Forwarded-Encrypted: i=1; AJvYcCUHpYdJ13qgsjjDiZxEZX6EfxkzCgSJcFysP88kBAwIt4qohUYjlR8o00nl3wV4Y8Rbg+2+acYYldY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyY6dlIQN8aCY7Ap0vjLmDpxEfU6blG17rLMipcF3R77NHwdZnR
	Bcv8EkfvB7vWRB6mTjpYzVp7z2lF1B8Bi+gTrB+rUBrX5H5QDtNRNd3JSXZOUSo=
X-Gm-Gg: ASbGnctVBhduiykTkXPvq5OIXLgAPufzvflfx3dhZEj0dU18v39PODvt8Z8f/icLtRh
	5s0C8tt+Iy7H5gTlVVbvvMIP5PzVDPn0HnuNN99Z+fsiqQkdU7eDHvjn4434yzyj3uoMwz4Ja8i
	9v3Ux73lqsPM55M11e2XW0j2dHQIzlC7JfVwDAtEaaj+/22LRhhBisq/EfucFv5gaoFUxAHRPTw
	SIElMT+bFgV59fzOodZB/QayYryBSA8t76iVnLBmv5E4mDeIhsZFes28994Aw==
X-Google-Smtp-Source: AGHT+IFZOYiH3Lp+d7c3IwqfVvrJzv9LfhQkadnYh+yiXsg63+Fi3WdnIKMzN5v9yy0Mix+L9bzXEw==
X-Received: by 2002:a05:6000:4026:b0:385:e879:45cc with SMTP id ffacd0b85a97d-388da3941d2mr2416167f8f.19.1734430438094;
        Tue, 17 Dec 2024 02:13:58 -0800 (PST)
Date: Tue, 17 Dec 2024 11:13:56 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
	Sergii Dmytruk ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] x86/io-apic: prevent early exit from i8259 loop detection
Message-ID: 
References: <20241217090045.6251-1-roger.pau@citrix.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 

On Tue, Dec 17, 2024 at 10:40:31AM +0100, Jan Beulich wrote:
> On 17.12.2024 10:00, Roger Pau Monne wrote:
> > Avoid exiting early from the loop when a pin that could be connected to the
> > i8259 is found, as such early exit would leave the EOI handler translation
> > array only partially allocated and/or initialized.
> > 
> > Otherwise on systems with multiple IO-APICs and an unmasked ExtINT pin on
> > any IO-APIC that's no the last one the following NULL pointer dereference
> > triggers:
> > 
> > (XEN) Enabling APIC mode.  Using 2 I/O APICs
> > (XEN) ----[ Xen-4.20-unstable  x86_64  debug=y  Not tainted ]----
> > (XEN) CPU:    0
> > (XEN) RIP:    e008:[] __ioapic_write_entry+0x83/0x95
> > [...]
> > (XEN) Xen call trace:
> > (XEN)    [] R __ioapic_write_entry+0x83/0x95
> > (XEN)    [] F amd_iommu_ioapic_update_ire+0x1ea/0x273
> > (XEN)    [] F iommu_update_ire_from_apic+0xa/0xc
> > (XEN)    [] F __ioapic_write_entry+0x93/0x95
> > (XEN)    [] F arch/x86/io_apic.c#clear_IO_APIC_pin+0x7c/0x10e
> > (XEN)    [] F arch/x86/io_apic.c#clear_IO_APIC+0x2d/0x61
> > (XEN)    [] F enable_IO_APIC+0x2e3/0x34f
> > (XEN)    [] F smp_prepare_cpus+0x254/0x27a
> > (XEN)    [] F __start_xen+0x1ce1/0x23ae
> > (XEN)    [] F __high_start+0x8e/0x90
> > (XEN)
> > (XEN) Pagetable walk from 0000000000000000:
> > (XEN)  L4[0x000] = 000000007dbfd063 ffffffffffffffff
> > (XEN)  L3[0x000] = 000000007dbfa063 ffffffffffffffff
> > (XEN)  L2[0x000] = 000000007dbcc063 ffffffffffffffff
> > (XEN)  L1[0x000] = 0000000000000000 ffffffffffffffff
> > (XEN)
> > (XEN) ****************************************
> > (XEN) Panic on CPU 0:
> > (XEN) FATAL PAGE FAULT
> > (XEN) [error_code=0002]
> > (XEN) Faulting linear address: 0000000000000000
> > (XEN) ****************************************
> > (XEN)
> > (XEN) Reboot in five seconds...
> > 
> > Reported-by: Sergii Dmytruk 
> > Fixes: 86001b3970fe ('x86/io-apic: fix directed EOI when using AMD-Vi interrupt remapping')
> > Signed-off-by: Roger Pau Monné 
> 
> Hmm, considering the earlier change was backported, I'm even inclined to
> delay 4.18.4 a little, for taking this one there as well.
> 
> > --- a/xen/arch/x86/io_apic.c
> > +++ b/xen/arch/x86/io_apic.c
> > @@ -1389,14 +1389,15 @@ void __init enable_IO_APIC(void)
> >              /* If the interrupt line is enabled and in ExtInt mode
> >               * I have found the pin where the i8259 is connected.
> >               */
> > -            if ((entry.mask == 0) && (entry.delivery_mode == dest_ExtINT)) {
> > +            if ( ioapic_i8259.apic == -1 && entry.mask == 0 &&
> > +                 entry.delivery_mode == dest_ExtINT )
> > +            {
> > +                ASSERT(ioapic_i8259.pin == -1);
> 
> I'm not sure of the value of this assertion. It is provable that ...
> 
> >                  ioapic_i8259.apic = apic;
> >                  ioapic_i8259.pin  = pin;
> 
> ... both fields are updated together (and not earlier on), and hence once
> we've been here neither field will still be -1.

No strong opinion, as all asserts I've placed it here in case the
logic to set apic or pin would change.

> Looking around I further notice that it's generally ioapic_i8259.pin that
> we check against -1, so I wonder whether - just for consistency - the if()
> condition wouldn't better too use that one.

As with the above, no strong opinion really, it's true that most
checks tend to use ioapic_i8259.pin != -1 instead of the apic field,
so I can adjust to that.

> Preferably with these adjustments:
> Reviewed-by: Jan Beulich 

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 10:25:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 10:25:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858730.1270966 (Exim 4.92)
	(envelope-from )
	id 1tNUlw-0003St-Gb; Tue, 17 Dec 2024 10:25:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858730.1270966; Tue, 17 Dec 2024 10:25: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 1tNUlw-0003Sm-Dn; Tue, 17 Dec 2024 10:25:48 +0000
Received: by outflank-mailman (input) for mailman id 858730;
 Tue, 17 Dec 2024 10:25: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 1tNUlv-0003Se-1K
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 10:25:47 +0000
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com
 [2607:f8b0:4864:20::d34])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 45d96c17-bc61-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 11:25:44 +0100 (CET)
Received: by mail-io1-xd34.google.com with SMTP id
 ca18e2360f4ac-844d67eb693so364365939f.3
 for ; Tue, 17 Dec 2024 02:25: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: 45d96c17-bc61-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734431143; x=1735035943; 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=Zdq547quTPr4F+j8gB5Fv7DWvFlx+ayEZm+4Oa/Abao=;
        b=BiMuOU4psl2UhpLSBd4lkVrvRY3Sq5HxRRL0vtrJEKBStxuA4k2SzEvdSuYkQKpArl
         yd0NPme0QTltbRRre4HGOWKJGegZJWHFl7wD9aEgBa08d82WjtkyBwHfC7FMFU/OCcsj
         3on8wF6WPAAwptH/jDcz9tzyfUTBls96r8PFmMS1ILVag1djy+LNK8AxyGYu+jLbVAkd
         24fK+DSU2H/hrFhC/c+JFhG7MvlLqyviA+nnR5NaW3HDFe/LnfhOLf9r83LX0W7YU01U
         zjycabfhYz3Pjo1qihJ+33rSh7HaNUqjfkU8lIfcA51iAdvWRIPpFrXRA0E0IZNHPB/Q
         c6Bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734431143; x=1735035943;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Zdq547quTPr4F+j8gB5Fv7DWvFlx+ayEZm+4Oa/Abao=;
        b=MNqydjZW0Ll5tlGwyolg8R3qfUnhEIwQ9O8/DS4//6v19lxTaVWlAb9+q5+d9oacP7
         /DDOiaa07Sx+WcollkgjmCkHdOR+uspj+z5veD/N7jcckFKQYwGvZHHjbTWvceIMhJRv
         ViJSC28a+pb3lQ50PcLaYzLbUDf34fKec3FrfYl890IiU0pPc7NB0l9K17+CUJ7pxg3i
         KUCQpTaf1D1Ri/uR305ZeIzr7Dlz61p2Id1OOvS1j+p23fv7IWd0/66WU9m0LJcTUCt5
         KiCXN8R7tM6aN50CCAaeZieffVD4qHPJCZ1Zbfbu2E+W/PE0o06m4Y1bngSFOuIO7THM
         PZcw==
X-Forwarded-Encrypted: i=1; AJvYcCXdl/Bi0rmOsUzGXpEWjIYdS4O662phMylBJR0Op7v9iBtMZj5KUW/VHt1SaODCv3YSnpNXz7mxPmM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxvitJbC9pXTzwvs00nlEtY2d7hR2fU+Bb7cat7H9jKQL9yaMB6
	COtKMU4pGDyxBFkOzrSFshAeZLS+mvWMHQpddjik0xCqjMV5QeQzj9V9YDr0Na+AWL31AUdWj5s
	3J0Z3/WA9xGN87wz675yU8RSKnNLjrG4+UYkPMA==
X-Gm-Gg: ASbGncu0aLAi5n892dYyZ44z46uZbwKcxppB3IlhHQ8Q+Jr4UD0KgrknPsFPyFRbqZU
	3e/2rsPvAPX2s8fppTHAidg/g//BaaAdtJXCY/ec=
X-Google-Smtp-Source: AGHT+IECGM/3Xs5L+2OH6MPD4XKNk3kUJjnydo5Y/uMMMTZLidRKnYuDqyfqbSFVzuLMMYRWNiZ1VWR0i7Fa9cfsqqI=
X-Received: by 2002:a05:6e02:3288:b0:3a7:159d:2dd8 with SMTP id
 e9e14a558f8ab-3afedc1a255mr162643755ab.7.1734431143638; Tue, 17 Dec 2024
 02:25:43 -0800 (PST)
MIME-Version: 1.0
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-2-carlo.nonato@minervasys.tech> 
  <00e38f79-6185-4dcb-be69-4b08fb4a81f4@suse.com>
In-Reply-To: <00e38f79-6185-4dcb-be69-4b08fb4a81f4@suse.com>
From: Carlo Nonato 
Date: Tue, 17 Dec 2024 11:25:33 +0100
Message-ID: 
Subject: Re: [PATCH v12 01/12] xen/common: add cache coloring common code
To: Jan Beulich 
Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, 
	Andrew Cooper , Anthony PERARD , 
	Michal Orzel , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 17, 2024 at 9:57=E2=80=AFAM Jan Beulich  wro=
te:
>
> On 16.12.2024 17:33, Carlo Nonato wrote:
> > On Mon, Dec 16, 2024 at 11:51=E2=80=AFAM Jan Beulich  wrote:
> >> On 13.12.2024 17:28, Carlo Nonato wrote:
> >>> --- /dev/null
> >>> +++ b/xen/common/llc-coloring.c
> >>> @@ -0,0 +1,124 @@
> >>> +/* SPDX-License-Identifier: GPL-2.0-only */
> >>> +/*
> >>> + * Last Level Cache (LLC) coloring common code
> >>> + *
> >>> + * Copyright (C) 2024, Advanced Micro Devices, Inc.
> >>> + * Copyright (C) 2024, Minerva Systems SRL
> >>> + */
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +
> >>> +#define NR_LLC_COLORS          (1U << CONFIG_LLC_COLORS_ORDER)
> >>> +
> >>> +/*
> >>> + * -1: not specified (disabled unless llc-size and llc-nr-ways prese=
nt)
> >>> + *  0: explicitly disabled through cmdline
> >>> + *  1: explicitly enabled through cmdline
> >>> + */
> >>> +static int8_t __initdata opt_llc_coloring =3D -1;
> >>> +boolean_param("llc-coloring", opt_llc_coloring);
> >>> +
> >>> +static bool __ro_after_init llc_coloring_enabled;
> >>> +
> >>> +static unsigned int __initdata llc_size;
> >>> +size_param("llc-size", llc_size);
> >>> +static unsigned int __initdata llc_nr_ways;
> >>> +integer_param("llc-nr-ways", llc_nr_ways);
> >>> +/* Number of colors available in the LLC */
> >>> +static unsigned int __ro_after_init max_nr_colors;
> >>> +
> >>> +static void print_colors(const unsigned int colors[], unsigned int n=
um_colors)
> >>> +{
> >>> +    unsigned int i;
> >>> +
> >>> +    printk("{ ");
> >>> +    for ( i =3D 0; i < num_colors; i++ )
> >>> +    {
> >>> +        unsigned int start =3D colors[i], end =3D start;
> >>> +
> >>> +        printk("%u", start);
> >>> +
> >>> +        for ( ; i < num_colors - 1 && end + 1 =3D=3D colors[i + 1]; =
i++, end++ )
> >>> +            ;
> >>> +
> >>> +        if ( start !=3D end )
> >>> +            printk("-%u", end);
> >>> +
> >>> +        if ( i < num_colors - 1 )
> >>> +            printk(", ");
> >>> +    }
> >>> +    printk(" }\n");
> >>> +}
> >>> +
> >>> +void __init llc_coloring_init(void)
> >>> +{
> >>> +    unsigned int way_size;
> >>> +
> >>> +    llc_coloring_enabled =3D (opt_llc_coloring =3D=3D 1);
> >>
> >> Generally I'd suggest to only use > 0, >=3D 0, < 0, and <=3D 0 on such
> >> variables.
> >>
> >>> +    if ( (opt_llc_coloring !=3D 0) && llc_size && llc_nr_ways )
> >>> +    {
> >>> +        llc_coloring_enabled =3D true;
> >>> +        way_size =3D llc_size / llc_nr_ways;
> >>> +    }
> >>
> >> Hmm, I actually see a difference in someone saying
> >>
> >> "llc-coloring=3D0 llc-size=3D... llc-nr-ways=3D..."
> >>
> >> vs
> >>
> >> "llc-size=3D... llc-nr-ways=3D... llc-coloring=3D0"
> >>
> >> I'm not sure about Arm, but on x86 this can be relevant as there may b=
e
> >> pre-set parts of a command line with appended (human) overrides. There=
fore
> >> it always wants to be "last wins". Yet yes, you may weant to take the
> >> position that in such a case the former example would require "llc-col=
oring=3D1"
> >> to also be added.
> >
> > Yes, I think this should be the way to go.
> >
> >> Kind of against the shorthand llc-size+llc-nr-ways only,
> >> though.
> >
> > The shorthand was proposed by you here:
> > https://patchew.org/Xen/20240315105902.160047-1-carlo.nonato@minervasys=
.tech/20240315105902.160047-2-carlo.nonato@minervasys.tech/#05e4d3da-4130-4=
c57-9855-43b685ce5005@suse.com
> >
> >> Wouldn't it make sense to infer "llc-coloring" when both of the latter=
 options
> >> were supplied?
> >
> > We both agreed that it was something good to have.
>
> Right, and I'm not putting that under question. With that, however, I fin=
d
> your reply ambiguous. If the shorthand is useful to have, is the requirem=
ent
> to put a 2nd "llc-coloring=3D1" on a command line (as per above) really a=
 good
> idea?

I don't know an easy way to check for parameters order. We're close to feat=
ure
freeze. Isn't this solution good enough for now?

> Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 10:38:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 10:38:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858741.1270976 (Exim 4.92)
	(envelope-from )
	id 1tNUxT-0005JN-Ee; Tue, 17 Dec 2024 10:37:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858741.1270976; Tue, 17 Dec 2024 10:37: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 1tNUxT-0005JG-Bn; Tue, 17 Dec 2024 10:37:43 +0000
Received: by outflank-mailman (input) for mailman id 858741;
 Tue, 17 Dec 2024 10:37: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 1tNUxR-0005JA-PY
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 10:37:41 +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 f066ed85-bc62-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 11:37:39 +0100 (CET)
Received: by mail-lj1-x235.google.com with SMTP id
 38308e7fff4ca-30229d5b21cso45666921fa.1
 for ; Tue, 17 Dec 2024 02:37:39 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-30344043eb3sm12286361fa.27.2024.12.17.02.37.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 02:37:38 -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: f066ed85-bc62-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734431859; x=1735036659; darn=lists.xenproject.org;
        h=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=nBYYuypc/ElymR8HjBxJKWEs4+PQ6vYMe7CYNB06BIM=;
        b=b9LP73rzsb93qD5OfTDSdAckww7Hh3hT3VxeSwSTtHmgvOs27PoUBxHMwlyQrUeKDy
         c31Mms/NAPvpii9pATBIEFH6UWBpAME8eFlkMu0hQwiwkhHp4ZvRz8L/hIogDgHwATMw
         yIfdOFYIGHbZO6a3Utlcc8UfeF8nJYUDSHvrft7JGyniLnpb/EZkjdBC5rsZ0vONEQE7
         /TLHPMVmD517s6pmn9mjuJdbM4fUIpwhibKrB/Nfb/i5BjDeAfLEpbo4GeKDiUo9BCNG
         RjQv3ow6dITvAmSoZKVDZNzTj/ValomID+DQ03yoyag++3xFBFeEWxjcD5YvxUsOS4e8
         L8ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734431859; x=1735036659;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=nBYYuypc/ElymR8HjBxJKWEs4+PQ6vYMe7CYNB06BIM=;
        b=fgCNoXZGJdbK2/4HymftY0dCURYnxNvjcVjZtnm+3gaFZz28ZLPJLagaS5qyXyjuNx
         kLj7cYSfzu6MiFEgJwAKjXQsbXRrb4Ly/vMnCmK8mC/y/SrG8/Quelf5JePd+odrijoW
         B3qUjQTaTUVWOoAhbduyjo1dQA9Oku8IOR0NHvZ/PLkKuNAVF4jYCCiiwBvuBLUt9S2i
         enb+y/Xj8/XihwK2TdCfABQ1cPiuCntfBQg3nyzWaDKG1WbqESHuegMQ/CRBhkOBUho4
         jkvYPJh4LtMUCZGg+xSG9cBDfDH+j7Lmdyjlcn44+qsyh4u51ZlrE/IoLxZ9pEOCnHQ2
         kd8Q==
X-Forwarded-Encrypted: i=1; AJvYcCWPLOFk4s8leNUODzYeE+XXalgQ3NF//Bh8F5p53pE+poPdAnJlBcL5dVzxcRbsXwpl33M2CE2BV/c=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzOzCJKJFktEp+MoCobVCh30Rf5kjvm68342FoiTPxnpAnL7mSp
	nHEQlftZqa2ShJycPIjtrRG0rOB0JyB6qYZciv7eWSiJt5JJfO4K
X-Gm-Gg: ASbGncuCeA4qY2rp2pCY8PQi7JRjoYe6yFORT9ZY0N8L31825Nlm4qlioU+nGIatWhH
	UAtm+ca3QQMeBZTQGTDvo7L7rhPNYEvH5D+6oc5lqKbHkqRIXci0NqbCYTsOCJQeOmA0IgZaiPU
	QJ+9WMBM2+pKDYdy2kFFcITbBeuitG38V/DXrxQeXS6SehvYl69VmLWlt9PPXPd8RWDjHK+hQtO
	lhxHs/gkZ+Gv/QvtGb40rFw0tCf8HJRE3/jxo0QmC2U9d+nU63ThmWDqvIkfyZZY3t+EQ==
X-Google-Smtp-Source: AGHT+IE0Ea4sSWF+lBfmwsxiXyQysgNk4NDBma26OK8fD0k9si483BXdkSlGV4m9xekyJ7aPvLgnMw==
X-Received: by 2002:a05:651c:1023:b0:300:f5bc:95b3 with SMTP id 38308e7fff4ca-302544e2ebamr33263091fa.41.1734431858840;
        Tue, 17 Dec 2024 02:37:38 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------00kLxmFgqjVCpE4HujugYm15"
Message-ID: 
Date: Tue, 17 Dec 2024 11:37:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/7] xen/riscv: implement data and instruction cache
 operations
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 
 <19c9ef65-a5bd-4d81-89dc-c780d3ead8b8@suse.com>
 <1c8c888e-bf59-4b4d-a3a5-cd2c0c7b6565@gmail.com>
 <3579b3ca-3634-4537-8981-fd68c60d5c6a@suse.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <3579b3ca-3634-4537-8981-fd68c60d5c6a@suse.com>

This is a multi-part message in MIME format.
--------------00kLxmFgqjVCpE4HujugYm15
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 12/17/24 9:32 AM, Jan Beulich wrote:
> On 16.12.2024 18:40, Oleksii Kurochko wrote:
>> On 12/16/24 3:23 PM, Jan Beulich wrote:
>>> On 11.12.2024 18:27, Oleksii Kurochko wrote:
>>>> --- a/xen/arch/riscv/include/asm/page.h
>>>> +++ b/xen/arch/riscv/include/asm/page.h
>>>> @@ -7,6 +7,7 @@
>>>>    
>>>>    #include 
>>>>    #include 
>>>> +#include 
>>>>    #include 
>>>>    
>>>>    #include 
>>>> @@ -148,9 +149,27 @@ static inline bool pte_is_mapping(pte_t p)
>>>>        return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK);
>>>>    }
>>>>    
>>>> +static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
>>>> +{
>>>> +#ifdef CONFIG_QEMU
>>>> +    return 0;
>>>> +#else
>>>> +    return -EOPNOTSUPP;
>>>> +#endif
>>>> +}
>>>> +
>>>> +static inline int clean_dcache_va_range(const void *p, unsigned long size)
>>>> +{
>>>> +#ifdef CONFIG_QEMU
>>>> +    return 0;
>>>> +#else
>>>> +    return -EOPNOTSUPP;
>>>> +#endif
>>>> +}
>>> So testing on real hardware will then effectively become impossible, until
>>> someone goes and implements these?
>> Yes...
>>
>> I am not sure what better we can do. It seems like it will be the best one to check if CMO
>> extensions is supported and use instructions for this extensions to implement these functions as they
>> are in the specification and not expected to be changed.
> Yes, using CMO when available is certainly the route to go. The main
> question there is what the behavior ought to be when CMO is unavailable.

If CMO ( or SoC specific extension for cache operation ) isn't available then IMO it means that memory is
coherent and nothing specific should be done in the mentioned above functions what means returning 0 should
be fine. Then implementation of these functions could look like:
```

static inline int <.....>(....)
{
#if !defined(CONFIG_QEMU)

    #warning should implementation of <....>  be updated? 

#endif

    return 0; 

}
```

Or just to be sure that user see the message change #warning -> #error.

~ Oleksii

>
>> But I want to back a little bit later to this implemntation as this not issue for QEMU as it doesn't model cache and
>> h/w on which I can ask to run Xen has IO cache coherency so for it will be needed just to add a new config
>> and implementation will still be 'return 0'. ( I thought to introduce instead of CONFIG_QEMU something like
>> CONFIG_HAS_CACHE_COHERENCY )
>>
>> And also in the spec it is mentioned:
>> ```
>> This suggests that RISC-V platforms prefer to support full
>> cache-coherent I/O, but it isn't actually mandatory.
>> As a result, the PMBT and CMO extensions aren't mandatory either,
>> meaning that some platforms might not
>> have instructions to properly flush, clean, or invalidate the cache.
>> ``` Based on that I also think to implement that in the following way:
>> ```
>>       #ifdef CONFIG_QEMU
>>       static inline int plat_clean_and_invalidate_dcache_va_range() { return 0; }
>>     static inline int plat_clean_dcache_va_range() { return 0; }
>>     #else /* !CONFIG_QEMU */
>>       static inline void plat_clean_and_invalidate_dcache_va_range()
>>     {
>>       printk_once("%s: should it be implemented for your platform?\n", __func__);
>>       return 0;
>>     }
>>
>>     static inline void plat_clean_dcache_va_range()
>>     {
>>       printk_once("%s: should it be implemented for your platform?\n", __func__);
>>       return 0;
>>     }
>>     #endif
>>
>>     static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
>>     {
>>         return plat_clean_and_invalidate_dcache_va_range();
>>     }
>> ....
>> ```
>> So we will have a notification for others none-QEMU platforms notification that probably some
>> changes are required.
> Yet failing to get cache management right can easily result in data corruption.
> I don't think a on-time printk() is appropriate to handle the lack of respective
> implementation. At least not anymore once RISC-V leaves "experimental" status.
>
>>>> --- /dev/null
>>>> +++ b/xen/arch/riscv/platforms/Kconfig
>>>> @@ -0,0 +1,5 @@
>>>> +config QEMU
>>>> +	bool "QEMU aarch virt machine support"
>>>> +	depends on RISCV_64
>>> I understand Arm has it like this, but: Is QEMU really a sufficiently non-
>>> ambiguous name to use?
>> Yes, it sounds good to me to have such naming for the platform which are running on top of QEMU.
>>
>> The other option I thought about it is to use CONFIG_VIRT_PLATFORM.
> I don't think QEMU should be fully omitted from the name. Nor do I think that
> you can generally infer from "virtual platform" that caches aren't modeled.
> What I was rather getting at is to perhaps add some qualifier to QEMU, e.g.
> QEMU_PLATFORM.
>
> Jan
--------------00kLxmFgqjVCpE4HujugYm15
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    


    

    
On 12/17/24 9:32 AM, Jan Beulich wrote:

    

    

      
On 16.12.2024 18:40, Oleksii Kurochko wrote:


      

        
On 12/16/24 3:23 PM, Jan Beulich wrote:


        

          
On 11.12.2024 18:27, Oleksii Kurochko wrote:


          

            
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -7,6 +7,7 @@
  
  #include <xen/bug.h>
  #include <xen/const.h>
+#include <xen/errno.h>
  #include <xen/types.h>
  
  #include <asm/atomic.h>
@@ -148,9 +149,27 @@ static inline bool pte_is_mapping(pte_t p)
      return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK);
  }
  
+static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
+{
+#ifdef CONFIG_QEMU
+    return 0;
+#else
+    return -EOPNOTSUPP;
+#endif
+}
+
+static inline int clean_dcache_va_range(const void *p, unsigned long size)
+{
+#ifdef CONFIG_QEMU
+    return 0;
+#else
+    return -EOPNOTSUPP;
+#endif
+}


          

          
So testing on real hardware will then effectively become impossible, until
someone goes and implements these?


        

        
Yes...

I am not sure what better we can do. It seems like it will be the best one to check if CMO
extensions is supported and use instructions for this extensions to implement these functions as they
are in the specification and not expected to be changed.


      

      
Yes, using CMO when available is certainly the route to go. The main
question there is what the behavior ought to be when CMO is unavailable.

    

    
If CMO ( or SoC specific extension for cache operation ) isn't available then IMO it means that memory is
coherent and nothing specific should be done in the mentioned above functions what means returning 0 should
be fine. Then implementation of these functions could look like:
```


    
static inline int <.....>(....)
{
#if !defined(CONFIG_QEMU)
#warning should implementation of <....>  be updated?

#endif


return 0;

}
```


    
Or just to be sure that user see the message change #warning -> #error.



    
~ Oleksii


    

      



      

        
But I want to back a little bit later to this implemntation as this not issue for QEMU as it doesn't model cache and
h/w on which I can ask to run Xen has IO cache coherency so for it will be needed just to add a new config
and implementation will still be 'return 0'. ( I thought to introduce instead of CONFIG_QEMU something like
CONFIG_HAS_CACHE_COHERENCY )

And also in the spec it is mentioned:
```
This suggests that RISC-V platforms prefer to support full 
cache-coherent I/O, but it isn't actually mandatory.
As a result, the PMBT and CMO extensions aren't mandatory either, 
meaning that some platforms might not
have instructions to properly flush, clean, or invalidate the cache.
``` Based on that I also think to implement that in the following way:
```
     #ifdef CONFIG_QEMU
     static inline int plat_clean_and_invalidate_dcache_va_range() { return 0; }
   static inline int plat_clean_dcache_va_range() { return 0; }
   #else /* !CONFIG_QEMU */
     static inline void plat_clean_and_invalidate_dcache_va_range()
   {
     printk_once("%s: should it be implemented for your platform?\n", __func__);
     return 0;
   }

   static inline void plat_clean_dcache_va_range()
   {
     printk_once("%s: should it be implemented for your platform?\n", __func__);
     return 0;
   }
   #endif

   static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
   {
       return plat_clean_and_invalidate_dcache_va_range();
   }
....
```
So we will have a notification for others none-QEMU platforms notification that probably some
changes are required.


      

      
Yet failing to get cache management right can easily result in data corruption.
I don't think a on-time printk() is appropriate to handle the lack of respective
implementation. At least not anymore once RISC-V leaves "experimental" status.



      

        

          

            
--- /dev/null
+++ b/xen/arch/riscv/platforms/Kconfig
@@ -0,0 +1,5 @@
+config QEMU
+	bool "QEMU aarch virt machine support"
+	depends on RISCV_64


          

          
I understand Arm has it like this, but: Is QEMU really a sufficiently non-
ambiguous name to use?


        

        
Yes, it sounds good to me to have such naming for the platform which are running on top of QEMU.

The other option I thought about it is to use CONFIG_VIRT_PLATFORM.


      

      
I don't think QEMU should be fully omitted from the name. Nor do I think that
you can generally infer from "virtual platform" that caches aren't modeled.
What I was rather getting at is to perhaps add some qualifier to QEMU, e.g.
QEMU_PLATFORM.

Jan


    

  


--------------00kLxmFgqjVCpE4HujugYm15--


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 11:08:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 11:08:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858760.1270994 (Exim 4.92)
	(envelope-from )
	id 1tNVQr-0001Jn-Q7; Tue, 17 Dec 2024 11:08:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858760.1270994; Tue, 17 Dec 2024 11:08: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 1tNVQr-0001Jg-Nd; Tue, 17 Dec 2024 11:08:05 +0000
Received: by outflank-mailman (input) for mailman id 858760;
 Tue, 17 Dec 2024 11:08: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 1tNVQq-0001Ja-Qq
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 11:08:04 +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 2f911a67-bc67-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 12:08:03 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-43635796b48so19994085e9.0
 for ; Tue, 17 Dec 2024 03:08: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-4364a3766dcsm13976725e9.0.2024.12.17.03.08.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 03:08: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: 2f911a67-bc67-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734433683; x=1735038483; 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=aT837i9CTDsu4vXWGQ+YP+stEq6MU1gGGCS+6o36ZJY=;
        b=IXFqC3/ZG6fqAPqwgu86WB34KvhgQQhKSyHQIkKLzSsqGtofEY6yCAhTkxhGXCqVin
         jhvosEISD/N7YprUGk14Xwjw1oLdBTsquddQmIpXaAiKjssKZ6XairsBVIYC6jH5qX7/
         hf9YJd7NITY18TXpzY5SYgZlufi1nuxkFfqMd2uRMFTwCIXD0qMEWZ6IRy9RAoUbe98T
         DrUQs4C7QeAwlqD6mqa5yCRzZhhUZVY3GF87y6ciPSiZQPZ6T7Iyvz+ydVCmOvOONVnh
         CjG+F7or9aelZRz4+DSQhanIdESoVrAk3G8ehv2doWlUbWmw1hjZ3nObEmz9x48BOjsx
         B9xA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734433683; x=1735038483;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=aT837i9CTDsu4vXWGQ+YP+stEq6MU1gGGCS+6o36ZJY=;
        b=BNhiU57BmF7+eeTPEGsNC7VnewrVwZPsCboo46sYTuPlPDtBzQJnD6o63dbcoVz6cG
         n9Y/YPLVcGe7HbOYj3uR6J7Tz6h9XIs/M+1jbgZRh7fk32tljf10mXm40xB1CXjgW5Sz
         2TFuc7YKsprYW/+Haflp3Dt2pGJU0hIwwnQb26z7PCQy0enNp5z0a5cnomYGN7+qu6pp
         xeqtT2Md7Iy7t6k+FoCRdZb4gL3Q5zHFjiFECMWSv1rodkyDUbkK64gW1gjWuGcbtJ34
         34eoTxFyEyP8Ovy3t7SuPqp6cQTnBf9LNH+T6WsPByU9i9m/9VXcE3WvT6Zz5x0VqyGf
         ifKQ==
X-Forwarded-Encrypted: i=1; AJvYcCVRHRDwB2lQYDr+ljcGqXeejOyJYENUSza4mfeyxUHClD0wFoDgBSoL7dCNRgo6vYCN5Jw4C/TIr6Q=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwmjpUgDOXfSPhQ5shaoOXZzCp9mv7rD39B+9ZVv2OBKV+zLS1x
	ILSZ182Tv9JRMPUtR6DZ1d886x9JS8zp3YxUB2bmkWZ3Z6E7Nf3NjfBBBuN/Pg==
X-Gm-Gg: ASbGncuKKSSOETY/bFviT+XLXGsdoi68KTpQxVDaWqxsrYBej3POegtoAz/mXisqA6b
	v97jmUE8x4x/XUt53q2BhgnQF61EhCQ11OD0IcVY2fowESGvpTgY5p5/CUvSKqLTJC8mPe7sEeU
	vFDOxW19p5BlU/FDVykBBFxcce3NTomHF69cotDDXcQQuvtqm9sAh4fXvaREEQmtVvmiDikzlbD
	8Ojpabf5cTNhSan2wEaxlimKHlRI67f4OlJZSBWNoDV2g979GPLfW1/l4vFOkY6iQc+Og+dNu6f
	ASId5gKGgO6hVsmVgX8pxmsAhEqzpHXoBLms8eKI1g==
X-Google-Smtp-Source: AGHT+IE7jmbJSsP9W2pZUzn8o5fWJjEBViOWYKn1w2CJfy9QBTBLEdfuB8jWrAMfncHwF5Px/0NaBQ==
X-Received: by 2002:a05:600c:4709:b0:435:1a2:262a with SMTP id 5b1f17b1804b1-43648131464mr25587625e9.3.1734433683199;
        Tue, 17 Dec 2024 03:08:03 -0800 (PST)
Message-ID: <542d963e-3fb6-45de-904c-4c1e17cc0f3d@suse.com>
Date: Tue, 17 Dec 2024 12:08:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/7] xen/riscv: implement data and instruction cache
 operations
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 
 <19c9ef65-a5bd-4d81-89dc-c780d3ead8b8@suse.com>
 <1c8c888e-bf59-4b4d-a3a5-cd2c0c7b6565@gmail.com>
 <3579b3ca-3634-4537-8981-fd68c60d5c6a@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 17.12.2024 11:37, Oleksii Kurochko wrote:
> 
> On 12/17/24 9:32 AM, Jan Beulich wrote:
>> On 16.12.2024 18:40, Oleksii Kurochko wrote:
>>> On 12/16/24 3:23 PM, Jan Beulich wrote:
>>>> On 11.12.2024 18:27, Oleksii Kurochko wrote:
>>>>> --- a/xen/arch/riscv/include/asm/page.h
>>>>> +++ b/xen/arch/riscv/include/asm/page.h
>>>>> @@ -7,6 +7,7 @@
>>>>>    
>>>>>    #include 
>>>>>    #include 
>>>>> +#include 
>>>>>    #include 
>>>>>    
>>>>>    #include 
>>>>> @@ -148,9 +149,27 @@ static inline bool pte_is_mapping(pte_t p)
>>>>>        return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK);
>>>>>    }
>>>>>    
>>>>> +static inline int clean_and_invalidate_dcache_va_range(const void *p, unsigned long size)
>>>>> +{
>>>>> +#ifdef CONFIG_QEMU
>>>>> +    return 0;
>>>>> +#else
>>>>> +    return -EOPNOTSUPP;
>>>>> +#endif
>>>>> +}
>>>>> +
>>>>> +static inline int clean_dcache_va_range(const void *p, unsigned long size)
>>>>> +{
>>>>> +#ifdef CONFIG_QEMU
>>>>> +    return 0;
>>>>> +#else
>>>>> +    return -EOPNOTSUPP;
>>>>> +#endif
>>>>> +}
>>>> So testing on real hardware will then effectively become impossible, until
>>>> someone goes and implements these?
>>> Yes...
>>>
>>> I am not sure what better we can do. It seems like it will be the best one to check if CMO
>>> extensions is supported and use instructions for this extensions to implement these functions as they
>>> are in the specification and not expected to be changed.
>> Yes, using CMO when available is certainly the route to go. The main
>> question there is what the behavior ought to be when CMO is unavailable.
> 
> If CMO ( or SoC specific extension for cache operation ) isn't available then IMO it means that memory is
> coherent and nothing specific should be done in the mentioned above functions what means returning 0 should
> be fine.

Hmm, imo that would be a pretty bold assumption.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 11:12:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 11:12:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858769.1271004 (Exim 4.92)
	(envelope-from )
	id 1tNVV5-0002x0-A5; Tue, 17 Dec 2024 11:12:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858769.1271004; Tue, 17 Dec 2024 11:12: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 1tNVV5-0002wt-7J; Tue, 17 Dec 2024 11:12:27 +0000
Received: by outflank-mailman (input) for mailman id 858769;
 Tue, 17 Dec 2024 11:12: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 1tNVV4-0002wn-Oa
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 11:12:26 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id cafbb95a-bc67-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 12:12:24 +0100 (CET)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-385f06d0c8eso2513107f8f.0
 for ; Tue, 17 Dec 2024 03:12: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
 ffacd0b85a97d-388c801a7c8sm11070220f8f.49.2024.12.17.03.12.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 03:12: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: cafbb95a-bc67-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734433944; x=1735038744; 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=ht0RZ4NK1kl3bi/eY/EWuXlbYq/ZtzNOq443JJbuVhY=;
        b=BShBVIOSIJNKHbvjAOOUGdox9SP5Os/MEWz8O2JJJd1a8O90YOLE3dFzV9UNeAx+fg
         vyW8t80FIBkEOb6+m8Kk7nf9YTrO4ZcFmKhxaY+j5f8CEyUuv0zqdErWxem4Ayyaapen
         cYuqOCUNCrtnK1wnFidvult2oNhnKMM1qQWKblklaF/OrClnFKitHyblqUKC50LZSiNr
         hKlJgNs1ZJz9rpGjtmNIdxGCIDIlWvSP+4hXtkaZvPtxF7SahExVeRLOBcTSLwbf4DuO
         GOyZmijl3M0bMN+HnLc2TprnJsf3e1pltoH5NGjUuJ/N9ZKp0wMIVwUiflIOMeIGZ3Sc
         XCJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734433944; x=1735038744;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ht0RZ4NK1kl3bi/eY/EWuXlbYq/ZtzNOq443JJbuVhY=;
        b=iabeO8YWjsR80O/l/drsZ9uzKomsiSti/sA2sOoeUrdpyiiW3zR4+k89+RPtzxDhur
         /Wpl9fLRD1XKlXiBzgKqMP/HrGVwE/cWaoniLQ/PM1wpg7hPLQcTWd5KytD36bVO+O9J
         UnsLwH9Zj87uMDLeSG+N0I73gccIhqDRjnvx9tYE8lRXtLH0cqQ9L5Dx3bj83BzPBtEw
         TWC9IeVoqQQk4L7uco3SfW5UG0yn9kBuqUQ+PFVzQ7JAKhM1B45FA+IVMY+plDmfzuh6
         LmdYz/kGk/RmvnMdv1x7ciVQKikQNRPM9y87IreOabxkjF52WtPMCXBsjam46CvS0D4G
         c3/w==
X-Forwarded-Encrypted: i=1; AJvYcCWU4XZc4XqRy6fvKq/7Nn9Sja3GRzySEOfxAmgWqCQD9ZFxfQAHw2meIva7xNcIb75BfemBq7J0qvA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwJ16h2uupWUDDR1MiRjwEMJW7obeRAT1IQvgi/htWTLj3tKvGE
	DE140K4wn5Y2Gczmp7ZxWkLwLm3r5ng6d6DOF+reGY89EJZjAzXAsChs2RWo/g==
X-Gm-Gg: ASbGnctlFvAgMo+/n/R1SyB6d4DGU9x1nG6lRWBPcZcMCLoYUP3RV2ghtACal1qVYfj
	Ys9OL81Mwn4hWQiVeWDqJ1sdB3G0CSkgXc6zpd4QHVaafytlFfNU33H+4t3+PFg6E1o5L5MMn+w
	S3dvTBynb+D4Of4ZLN5j8zvS5XtIGsKNYxhKzqPKr+65QfFZICKmVGiJlh6z5mCni/+Pf5/C3Lv
	91N6pW1RUaWr5HojXZN/XTYj6GiDRDcL9ULSzOvv/LnR+aqkag8BznZy/BMDNz/u0rdEMinfKhh
	5Mr6pSwRIp799X3Sd6M+JEqZVUKcVky0cF16b8Y3GA==
X-Google-Smtp-Source: AGHT+IHhLJ6a9kqTDYwQ1sKAUX7qSsk+gfhMpq3XMs73EhSPLlgOBcMfBSOl+3vxP5QHDGNT7tkOcw==
X-Received: by 2002:adf:a1c1:0:b0:388:da2a:e48 with SMTP id ffacd0b85a97d-388da2a0e58mr1867676f8f.23.1734433944047;
        Tue, 17 Dec 2024 03:12:24 -0800 (PST)
Message-ID: <49a1b364-595e-4971-9819-f7e4beb35b05@suse.com>
Date: Tue, 17 Dec 2024 12:12:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v12 01/12] xen/common: add cache coloring common code
To: Carlo Nonato 
Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech,
 Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-2-carlo.nonato@minervasys.tech>
 
 
 <00e38f79-6185-4dcb-be69-4b08fb4a81f4@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 17.12.2024 11:25, Carlo Nonato wrote:
> On Tue, Dec 17, 2024 at 9:57 AM Jan Beulich  wrote:
>>
>> On 16.12.2024 17:33, Carlo Nonato wrote:
>>> On Mon, Dec 16, 2024 at 11:51 AM Jan Beulich  wrote:
>>>> On 13.12.2024 17:28, Carlo Nonato wrote:
>>>>> --- /dev/null
>>>>> +++ b/xen/common/llc-coloring.c
>>>>> @@ -0,0 +1,124 @@
>>>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>>>> +/*
>>>>> + * Last Level Cache (LLC) coloring common code
>>>>> + *
>>>>> + * Copyright (C) 2024, Advanced Micro Devices, Inc.
>>>>> + * Copyright (C) 2024, Minerva Systems SRL
>>>>> + */
>>>>> +#include 
>>>>> +#include 
>>>>> +#include 
>>>>> +
>>>>> +#define NR_LLC_COLORS          (1U << CONFIG_LLC_COLORS_ORDER)
>>>>> +
>>>>> +/*
>>>>> + * -1: not specified (disabled unless llc-size and llc-nr-ways present)
>>>>> + *  0: explicitly disabled through cmdline
>>>>> + *  1: explicitly enabled through cmdline
>>>>> + */
>>>>> +static int8_t __initdata opt_llc_coloring = -1;
>>>>> +boolean_param("llc-coloring", opt_llc_coloring);
>>>>> +
>>>>> +static bool __ro_after_init llc_coloring_enabled;
>>>>> +
>>>>> +static unsigned int __initdata llc_size;
>>>>> +size_param("llc-size", llc_size);
>>>>> +static unsigned int __initdata llc_nr_ways;
>>>>> +integer_param("llc-nr-ways", llc_nr_ways);
>>>>> +/* Number of colors available in the LLC */
>>>>> +static unsigned int __ro_after_init max_nr_colors;
>>>>> +
>>>>> +static void print_colors(const unsigned int colors[], unsigned int num_colors)
>>>>> +{
>>>>> +    unsigned int i;
>>>>> +
>>>>> +    printk("{ ");
>>>>> +    for ( i = 0; i < num_colors; i++ )
>>>>> +    {
>>>>> +        unsigned int start = colors[i], end = start;
>>>>> +
>>>>> +        printk("%u", start);
>>>>> +
>>>>> +        for ( ; i < num_colors - 1 && end + 1 == colors[i + 1]; i++, end++ )
>>>>> +            ;
>>>>> +
>>>>> +        if ( start != end )
>>>>> +            printk("-%u", end);
>>>>> +
>>>>> +        if ( i < num_colors - 1 )
>>>>> +            printk(", ");
>>>>> +    }
>>>>> +    printk(" }\n");
>>>>> +}
>>>>> +
>>>>> +void __init llc_coloring_init(void)
>>>>> +{
>>>>> +    unsigned int way_size;
>>>>> +
>>>>> +    llc_coloring_enabled = (opt_llc_coloring == 1);
>>>>
>>>> Generally I'd suggest to only use > 0, >= 0, < 0, and <= 0 on such
>>>> variables.
>>>>
>>>>> +    if ( (opt_llc_coloring != 0) && llc_size && llc_nr_ways )
>>>>> +    {
>>>>> +        llc_coloring_enabled = true;
>>>>> +        way_size = llc_size / llc_nr_ways;
>>>>> +    }
>>>>
>>>> Hmm, I actually see a difference in someone saying
>>>>
>>>> "llc-coloring=0 llc-size=... llc-nr-ways=..."
>>>>
>>>> vs
>>>>
>>>> "llc-size=... llc-nr-ways=... llc-coloring=0"
>>>>
>>>> I'm not sure about Arm, but on x86 this can be relevant as there may be
>>>> pre-set parts of a command line with appended (human) overrides. Therefore
>>>> it always wants to be "last wins". Yet yes, you may weant to take the
>>>> position that in such a case the former example would require "llc-coloring=1"
>>>> to also be added.
>>>
>>> Yes, I think this should be the way to go.
>>>
>>>> Kind of against the shorthand llc-size+llc-nr-ways only,
>>>> though.
>>>
>>> The shorthand was proposed by you here:
>>> https://patchew.org/Xen/20240315105902.160047-1-carlo.nonato@minervasys.tech/20240315105902.160047-2-carlo.nonato@minervasys.tech/#05e4d3da-4130-4c57-9855-43b685ce5005@suse.com
>>>
>>>> Wouldn't it make sense to infer "llc-coloring" when both of the latter options
>>>> were supplied?
>>>
>>> We both agreed that it was something good to have.
>>
>> Right, and I'm not putting that under question. With that, however, I find
>> your reply ambiguous. If the shorthand is useful to have, is the requirement
>> to put a 2nd "llc-coloring=1" on a command line (as per above) really a good
>> idea?
> 
> I don't know an easy way to check for parameters order. We're close to feature
> freeze. Isn't this solution good enough for now?

Maybe it is, but then imo only when also calling out the apparent anomaly in
the command line doc. I.e. amend 'Note that using both options implies
"llc-coloring=on"' by e.g. 'unless an earlier "llc-coloring=off" is there' (in
both places).

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 11:12:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 11:12:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858773.1271014 (Exim 4.92)
	(envelope-from )
	id 1tNVVV-0003Ny-Gs; Tue, 17 Dec 2024 11:12:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858773.1271014; Tue, 17 Dec 2024 11: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 1tNVVV-0003Nr-EA; Tue, 17 Dec 2024 11:12:53 +0000
Received: by outflank-mailman (input) for mailman id 858773;
 Tue, 17 Dec 2024 11:12: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 1tNVVU-0002wn-4y
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 11:12:52 +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 da6e2e16-bc67-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 12:12:50 +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 DB61C1F385;
 Tue, 17 Dec 2024 11:12:49 +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 84476132EA;
 Tue, 17 Dec 2024 11:12:49 +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 +XbCHrFcYWfxUAAAD6G6ig
 (envelope-from ); Tue, 17 Dec 2024 11:12: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: da6e2e16-bc67-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734433970; 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=Y2BwafB5l2UJcF5zJtaItYQyp8yHOBEocvm//FyVYBs=;
	b=J+ynfYUZ6yNs8pTdWUPCPEvBTdY73iTSA7H7kozkJg6WGowjjPfFQw4CMZtLk9cE+COgmi
	HTRm7fKeI1O3sBI2zTygwb5TBncN5hx0P5eDapd75XYy7aI1oV27FGyGFApbGdhG1RqVIJ
	4NnB6YXMEBTVRnv5pToqmO02bbzTLu4=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=AGT30IwU
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734433969; 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=Y2BwafB5l2UJcF5zJtaItYQyp8yHOBEocvm//FyVYBs=;
	b=AGT30IwUj+XpdkiBk5iNm1Fcl+cGsl+ETnlZh9qDWj9fGAHIYMBXfzQcRubd951PeWX+Rt
	KPPhTkVPrkgQ7oY7fkSkjgCHPGxZhkgT267K1mLrEejVWLTiwGj2RPs1Y3DfPTCxLXG6cd
	zB3CWvhARs3cRbpB3vcRZtwFzlm6sT0=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	"Daniel P. Smith" ,
	Samuel Thibault 
Subject: [PATCH v4 0/5] remove libxenctrl usage from xenstored
Date: Tue, 17 Dec 2024 12:12:42 +0100
Message-ID: <20241217111247.2204-1-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: DB61C1F385
X-Spam-Score: -3.01
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-3.01 / 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.20)[-1.000];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	RCVD_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCPT_COUNT_SEVEN(0.00)[11];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.com:mid,suse.com:dkim];
	RCVD_TLS_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	DKIM_TRACE(0.00)[suse.com:+]
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spam-Level: 

Xenstored is using libxenctrl for only one purpose: to get information
about state of domains.

This patch series is removing that dependency by introducing a new
stable interface which can be used by xenstored instead.

There was a RFC series sent out 3 years ago, which I have taken as a
base and by addressing all comments from back then.

The main differences since that RFC series are:

- Instead of introducing an new main hypercall for a stable management
  interface I have just added a new domctl sub-op, as requested in 2021.

- I have added a new library libxenmanage for easy use of the new
  stable hypervisor interface. Main motivation for adding the library
  was the recent attempt to decouple oxenstored from the Xen git tree.
  By using the new library, oxenstored could benefit in the same way as
  xenstored from the new interface: it would be possible to rely on
  stable libraries only.

- Mini-OS has gained some more config options recently, so it was rather
  easy to make xenstore[pvh]-stubdom independent from libxenctrl, too.

- By moving the CPU barrier definitions out of xenctrl.h into a new
  dedicated header xenstored code no longer needs to #include xenctrl.h,
  thus removing any xenctrl reference from xenstored code.

Please note that the last patch can be committed only after the related
Mini-OS patch "config: add support for libxenmanage" has gone in AND
the Mini-OS commit-id has been updated in Config.mk accordingly! The
Mini-OS patch has been Acked already, so it can go in as soon as patch
4 of this series (the one introducing libxenmanage) has been committed.

Changes in V2:
- new patch 1
- former patch 5 mover earlier, now patch 2 (can go in without the rest
  of the series)
- addressed comments

Changes in V3:
- addressed comments

Changes in V4:
- patches 1 and 3 of V3 dropped, as already committed
- addressed comments

Juergen Gross (5):
  tools: add a dedicated header file for barrier definitions
  xen: add bitmap to indicate per-domain state changes
  xen: add new domctl get_changed_domain
  tools/libs: add a new libxenmanage library
  tools/xenstored: use new stable interface instead of libxenctrl

 stubdom/Makefile                       |   8 +-
 stubdom/mini-os.mk                     |   1 +
 tools/9pfsd/io.c                       |   5 +-
 tools/flask/policy/modules/dom0.te     |   2 +-
 tools/flask/policy/modules/xen.if      |   4 +-
 tools/flask/policy/modules/xenstore.te |   1 +
 tools/include/xen-barrier.h            |  39 ++++++
 tools/include/xenctrl.h                |  28 +----
 tools/include/xenmanage.h              |  92 ++++++++++++++
 tools/libs/Makefile                    |   1 +
 tools/libs/ctrl/Makefile               |   2 +-
 tools/libs/manage/Makefile             |  10 ++
 tools/libs/manage/Makefile.common      |   3 +
 tools/libs/manage/core.c               | 168 +++++++++++++++++++++++++
 tools/libs/manage/libxenmanage.map     |   8 ++
 tools/libs/uselibs.mk                  |   2 +
 tools/xenstored/Makefile               |   2 +-
 tools/xenstored/Makefile.common        |   2 +-
 tools/xenstored/core.h                 |   1 -
 tools/xenstored/domain.c               |  52 +++-----
 tools/xenstored/lu.c                   |   1 +
 tools/xenstored/lu_daemon.c            |   1 +
 xen/common/domain.c                    | 130 +++++++++++++++++++
 xen/common/domctl.c                    |  18 ++-
 xen/common/event_channel.c             |  26 +++-
 xen/include/public/domctl.h            |  26 ++++
 xen/include/xen/event.h                |   7 ++
 xen/include/xen/sched.h                |   5 +
 xen/include/xsm/dummy.h                |   8 ++
 xen/include/xsm/xsm.h                  |   6 +
 xen/xsm/dummy.c                        |   1 +
 xen/xsm/flask/hooks.c                  |   7 ++
 xen/xsm/flask/policy/access_vectors    |   2 +
 33 files changed, 595 insertions(+), 74 deletions(-)
 create mode 100644 tools/include/xen-barrier.h
 create mode 100644 tools/include/xenmanage.h
 create mode 100644 tools/libs/manage/Makefile
 create mode 100644 tools/libs/manage/Makefile.common
 create mode 100644 tools/libs/manage/core.c
 create mode 100644 tools/libs/manage/libxenmanage.map

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 11:12:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 11:12:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858775.1271025 (Exim 4.92)
	(envelope-from )
	id 1tNVVa-0003fq-OQ; Tue, 17 Dec 2024 11:12:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858775.1271025; Tue, 17 Dec 2024 11: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 1tNVVa-0003fh-Lh; Tue, 17 Dec 2024 11:12:58 +0000
Received: by outflank-mailman (input) for mailman id 858775;
 Tue, 17 Dec 2024 11:12: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 1tNVVZ-0002wn-FO
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 11:12:57 +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 dd98a982-bc67-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 12:12:55 +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 70CD21F38E;
 Tue, 17 Dec 2024 11:12:55 +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 4CA3C132EA;
 Tue, 17 Dec 2024 11:12:55 +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 FYhIEbdcYWf6UAAAD6G6ig
 (envelope-from ); Tue, 17 Dec 2024 11:12: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: dd98a982-bc67-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734433975; 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=G1G3ZUn7qm6OF894GcskQ6ITQ9bas9F9HnN7efD8s/8=;
	b=T8FzVfmOxsRrbFaC5K1eQ6JpnWoCZ2YmbL4vUZoaWTE7/9XRn+YH6szT4Q19DXzvGWBRG/
	wgD8kIOOh48dNyVm2nfGaDZDe28itSxhKJ1NZC1L5rw49wDBepV17lOFwV4M9D4tEreI3C
	21ZsaFmg9D+qxcAIupvQ+qmTuGbntlM=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734433975; 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=G1G3ZUn7qm6OF894GcskQ6ITQ9bas9F9HnN7efD8s/8=;
	b=T8FzVfmOxsRrbFaC5K1eQ6JpnWoCZ2YmbL4vUZoaWTE7/9XRn+YH6szT4Q19DXzvGWBRG/
	wgD8kIOOh48dNyVm2nfGaDZDe28itSxhKJ1NZC1L5rw49wDBepV17lOFwV4M9D4tEreI3C
	21ZsaFmg9D+qxcAIupvQ+qmTuGbntlM=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Anthony PERARD 
Subject: [PATCH v4 1/5] tools: add a dedicated header file for barrier definitions
Date: Tue, 17 Dec 2024 12:12:43 +0100
Message-ID: <20241217111247.2204-2-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217111247.2204-1-jgross@suse.com>
References: <20241217111247.2204-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.80
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];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	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-Level: 

Instead of having to include xenctrl.h for getting definitions of cpu
barriers, add a dedicated header for that purpose.

Switch the xen-9pfsd daemon to use the new header instead of xenctrl.h.

This is in preparation of making Xenstore independent from libxenctrl.

Signed-off-by: Juergen Gross 
Reviewed-by: Anthony PERARD 
---
V1:
- new patch
V2:
- use SPDX
- modify guard define (Anthony PERARD)
- moved earlier in the series
V4:
- use LGPL-2.1-only SPDX identifier (Anthony PERARD)
---
 tools/9pfsd/io.c            |  5 ++++-
 tools/include/xen-barrier.h | 39 +++++++++++++++++++++++++++++++++++++
 tools/include/xenctrl.h     | 28 +-------------------------
 tools/libs/ctrl/Makefile    |  2 +-
 4 files changed, 45 insertions(+), 29 deletions(-)
 create mode 100644 tools/include/xen-barrier.h

diff --git a/tools/9pfsd/io.c b/tools/9pfsd/io.c
index 468e0241f5..14cfcaf568 100644
--- a/tools/9pfsd/io.c
+++ b/tools/9pfsd/io.c
@@ -13,15 +13,18 @@
 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
-#include            /* For cpu barriers. */
+#include 
 #include 
 
 #include "xen-9pfsd.h"
diff --git a/tools/include/xen-barrier.h b/tools/include/xen-barrier.h
new file mode 100644
index 0000000000..5c22ee112c
--- /dev/null
+++ b/tools/include/xen-barrier.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: LGPL-2.1-only */
+/******************************************************************************
+ * xen-barrier.h
+ *
+ * Definition of CPU barriers, part of libxenctrl.
+ *
+ * Copyright (c) 2003-2004, K A Fraser.
+ */
+
+#ifndef XEN_BARRIER_H
+#define XEN_BARRIER_H
+
+/*
+ *  DEFINITIONS FOR CPU BARRIERS
+ */
+
+#define xen_barrier() asm volatile ( "" : : : "memory")
+
+#if defined(__i386__)
+#define xen_mb()  asm volatile ( "lock addl $0, -4(%%esp)" ::: "memory" )
+#define xen_rmb() xen_barrier()
+#define xen_wmb() xen_barrier()
+#elif defined(__x86_64__)
+#define xen_mb()  asm volatile ( "lock addl $0, -32(%%rsp)" ::: "memory" )
+#define xen_rmb() xen_barrier()
+#define xen_wmb() xen_barrier()
+#elif defined(__arm__)
+#define xen_mb()   asm volatile ("dmb" : : : "memory")
+#define xen_rmb()  asm volatile ("dmb" : : : "memory")
+#define xen_wmb()  asm volatile ("dmb" : : : "memory")
+#elif defined(__aarch64__)
+#define xen_mb()   asm volatile ("dmb sy" : : : "memory")
+#define xen_rmb()  asm volatile ("dmb sy" : : : "memory")
+#define xen_wmb()  asm volatile ("dmb sy" : : : "memory")
+#else
+#error "Define barriers"
+#endif
+
+#endif /* XEN_BARRIER_H */
diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 29617585c5..ea57e9dbb9 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -48,6 +48,7 @@
 #include 
 
 #include "xentoollog.h"
+#include "xen-barrier.h"
 
 #if defined(__i386__) || defined(__x86_64__)
 #include 
@@ -61,33 +62,6 @@
 
 #define INVALID_MFN  (~0UL)
 
-/*
- *  DEFINITIONS FOR CPU BARRIERS
- */
-
-#define xen_barrier() asm volatile ( "" : : : "memory")
-
-#if defined(__i386__)
-#define xen_mb()  asm volatile ( "lock addl $0, -4(%%esp)" ::: "memory" )
-#define xen_rmb() xen_barrier()
-#define xen_wmb() xen_barrier()
-#elif defined(__x86_64__)
-#define xen_mb()  asm volatile ( "lock addl $0, -32(%%rsp)" ::: "memory" )
-#define xen_rmb() xen_barrier()
-#define xen_wmb() xen_barrier()
-#elif defined(__arm__)
-#define xen_mb()   asm volatile ("dmb" : : : "memory")
-#define xen_rmb()  asm volatile ("dmb" : : : "memory")
-#define xen_wmb()  asm volatile ("dmb" : : : "memory")
-#elif defined(__aarch64__)
-#define xen_mb()   asm volatile ("dmb sy" : : : "memory")
-#define xen_rmb()  asm volatile ("dmb sy" : : : "memory")
-#define xen_wmb()  asm volatile ("dmb sy" : : : "memory")
-#else
-#error "Define barriers"
-#endif
-
-
 #define XENCTRL_HAS_XC_INTERFACE 1
 /* In Xen 4.0 and earlier, xc_interface_open and xc_evtchn_open would
  * both return ints being the file descriptor.  In 4.1 and later, they
diff --git a/tools/libs/ctrl/Makefile b/tools/libs/ctrl/Makefile
index 5fe0bfad0c..acce8639d3 100644
--- a/tools/libs/ctrl/Makefile
+++ b/tools/libs/ctrl/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 include Makefile.common
 
-LIBHEADER := xenctrl.h xenctrl_compat.h
+LIBHEADER := xenctrl.h xenctrl_compat.h xen-barrier.h
 PKG_CONFIG_FILE := xencontrol.pc
 PKG_CONFIG_NAME := Xencontrol
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 11:13:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 11:13:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858777.1271035 (Exim 4.92)
	(envelope-from )
	id 1tNVVg-00040H-4K; Tue, 17 Dec 2024 11:13:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858777.1271035; Tue, 17 Dec 2024 11:13: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 1tNVVg-00040A-19; Tue, 17 Dec 2024 11:13:04 +0000
Received: by outflank-mailman (input) for mailman id 858777;
 Tue, 17 Dec 2024 11:13: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 1tNVVe-0003La-AY
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 11:13:02 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e0f5676d-bc67-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 12:13:01 +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 25C271F385;
 Tue, 17 Dec 2024 11:13:01 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id D2877132EA;
 Tue, 17 Dec 2024 11:13:00 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id ZdLkMbxcYWcAUQAAD6G6ig
 (envelope-from ); Tue, 17 Dec 2024 11:13: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: e0f5676d-bc67-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734433981; 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=FgMqRSi3pmRan/PzXb3nIxh+nsRC9DNPVxN/BXmqq7Y=;
	b=d2hiq/mfhW809bZLOMo4YjOY97ahjfWSTjT3wxJk2PyhgktqSwcnHXYI+cuEeCYT5SAKmw
	CZ5p6O2X4Qj2ykRPOGDkME8YI5sUXpH7tRGyXiVwA6pMAcziRKBe2TzGzIOirxNtIiUEt5
	kjQQqLjnBRtyx7BrM4mEggWB5sKjHXw=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b="d2hiq/mf"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734433981; 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=FgMqRSi3pmRan/PzXb3nIxh+nsRC9DNPVxN/BXmqq7Y=;
	b=d2hiq/mfhW809bZLOMo4YjOY97ahjfWSTjT3wxJk2PyhgktqSwcnHXYI+cuEeCYT5SAKmw
	CZ5p6O2X4Qj2ykRPOGDkME8YI5sUXpH7tRGyXiVwA6pMAcziRKBe2TzGzIOirxNtIiUEt5
	kjQQqLjnBRtyx7BrM4mEggWB5sKjHXw=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v4 2/5] xen: add bitmap to indicate per-domain state changes
Date: Tue, 17 Dec 2024 12:12:44 +0100
Message-ID: <20241217111247.2204-3-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217111247.2204-1-jgross@suse.com>
References: <20241217111247.2204-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 25C271F385
X-Spam-Score: -3.01
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-3.01 / 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)[];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	RCVD_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCPT_COUNT_SEVEN(0.00)[9];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.com:dkim,suse.com:mid,suse.com:email];
	RCVD_TLS_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	DKIM_TRACE(0.00)[suse.com:+]
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spam-Level: 

Add a bitmap with one bit per possible domid indicating the respective
domain has changed its state (created, deleted, dying, crashed,
shutdown).

Registering the VIRQ_DOM_EXC event will result in setting the bits for
all existing domains and resetting all other bits.

As the usage of this bitmap is tightly coupled with the VIRQ_DOM_EXC
event, it is meant to be used only by a single consumer in the system,
just like the VIRQ_DOM_EXC event.

Resetting a bit will be done in a future patch.

This information is needed for Xenstore to keep track of all domains.

Signed-off-by: Juergen Gross 
---
V2:
- use DOMID_FIRST_RESERVED instead of DOMID_MASK + 1 (Jan Beulich)
- use const (Jan Beulich)
- move call of domain_reset_states() into evtchn_bind_virq() (Jan Beulich)
- dynamically allocate dom_state_changed bitmap (Jan Beulich)
V3:
- use xvzalloc_array() (Jan Beulich)
- don't rename existing label (Jan Beulich)
V4:
- add __read_mostly (Jan Beulich)
- use __set_biz() (Jan Beulich)
- fix error handling in evtchn_bind_virq() (Jan Beulich)
---
 xen/common/domain.c        | 60 ++++++++++++++++++++++++++++++++++++++
 xen/common/event_channel.c | 17 +++++++++++
 xen/include/xen/sched.h    |  3 ++
 3 files changed, 80 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index e33a0a5a21..87633b1f7b 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -138,6 +139,60 @@ bool __read_mostly vmtrace_available;
 
 bool __read_mostly vpmu_is_available;
 
+static DEFINE_SPINLOCK(dom_state_changed_lock);
+static unsigned long *__read_mostly dom_state_changed;
+
+int domain_init_states(void)
+{
+    const struct domain *d;
+    int rc = -ENOMEM;
+
+    spin_lock(&dom_state_changed_lock);
+
+    if ( dom_state_changed )
+        bitmap_zero(dom_state_changed, DOMID_FIRST_RESERVED);
+    else
+    {
+        dom_state_changed = xvzalloc_array(unsigned long,
+                                           BITS_TO_LONGS(DOMID_FIRST_RESERVED));
+        if ( !dom_state_changed )
+            goto unlock;
+    }
+
+    rcu_read_lock(&domlist_read_lock);
+
+    for_each_domain ( d )
+        __set_bit(d->domain_id, dom_state_changed);
+
+    rcu_read_unlock(&domlist_read_lock);
+
+    rc = 0;
+
+ unlock:
+    spin_unlock(&dom_state_changed_lock);
+
+    return rc;
+}
+
+void domain_deinit_states(void)
+{
+    spin_lock(&dom_state_changed_lock);
+
+    XVFREE(dom_state_changed);
+
+    spin_unlock(&dom_state_changed_lock);
+}
+
+static void domain_changed_state(const struct domain *d)
+{
+    spin_lock(&dom_state_changed_lock);
+
+    if ( dom_state_changed )
+        __set_bit(d->domain_id, dom_state_changed);
+
+    spin_unlock(&dom_state_changed_lock);
+}
+
 static void __domain_finalise_shutdown(struct domain *d)
 {
     struct vcpu *v;
@@ -152,6 +207,7 @@ static void __domain_finalise_shutdown(struct domain *d)
             return;
 
     d->is_shut_down = 1;
+    domain_changed_state(d);
     if ( (d->shutdown_code == SHUTDOWN_suspend) && d->suspend_evtchn )
         evtchn_send(d, d->suspend_evtchn);
     else
@@ -839,6 +895,7 @@ struct domain *domain_create(domid_t domid,
      */
     domlist_insert(d);
 
+    domain_changed_state(d);
     memcpy(d->handle, config->handle, sizeof(d->handle));
 
     return d;
@@ -1104,6 +1161,7 @@ int domain_kill(struct domain *d)
         /* Mem event cleanup has to go here because the rings 
          * have to be put before we call put_domain. */
         vm_event_cleanup(d);
+        domain_changed_state(d);
         put_domain(d);
         send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
@@ -1293,6 +1351,8 @@ static void cf_check complete_domain_destroy(struct rcu_head *head)
 
     xfree(d->vcpu);
 
+    domain_changed_state(d);
+
     _domain_destroy(d);
 
     send_global_virq(VIRQ_DOM_EXC);
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 8db2ca4ba2..041aacad02 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -469,6 +469,7 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
     struct domain *d = current->domain;
     int            virq = bind->virq, vcpu = bind->vcpu;
     int            rc = 0;
+    bool           deinit_if_err = false;
 
     if ( (virq < 0) || (virq >= ARRAY_SIZE(v->virq_to_evtchn)) )
         return -EINVAL;
@@ -485,11 +486,21 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
     if ( (v = domain_vcpu(d, vcpu)) == NULL )
         return -ENOENT;
 
+    if ( virq == VIRQ_DOM_EXC )
+    {
+        rc = domain_init_states();
+        if ( rc )
+            return rc;
+
+        deinit_if_err = true;
+    }
+
     write_lock(&d->event_lock);
 
     if ( read_atomic(&v->virq_to_evtchn[virq]) )
     {
         rc = -EEXIST;
+        deinit_if_err = false;
         gdprintk(XENLOG_WARNING, "EVTCHNOP failure: error %d\n", rc);
         goto out;
     }
@@ -527,6 +538,9 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
  out:
     write_unlock(&d->event_lock);
 
+    if ( rc && deinit_if_err )
+        domain_deinit_states();
+
     return rc;
 }
 
@@ -730,6 +744,9 @@ int evtchn_close(struct domain *d1, int port1, bool guest)
         struct vcpu *v;
         unsigned long flags;
 
+        if ( chn1->u.virq == VIRQ_DOM_EXC )
+            domain_deinit_states();
+
         v = d1->vcpu[virq_is_global(chn1->u.virq) ? 0 : chn1->notify_vcpu_id];
 
         write_lock_irqsave(&v->virq_lock, flags);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 711668e028..16684bbaf9 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -800,6 +800,9 @@ void domain_resume(struct domain *d);
 
 int domain_soft_reset(struct domain *d, bool resuming);
 
+int domain_init_states(void);
+void domain_deinit_states(void);
+
 int vcpu_start_shutdown_deferral(struct vcpu *v);
 void vcpu_end_shutdown_deferral(struct vcpu *v);
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 11:13:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 11:13:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858782.1271046 (Exim 4.92)
	(envelope-from )
	id 1tNVVn-0004Rw-Ck; Tue, 17 Dec 2024 11:13:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858782.1271046; Tue, 17 Dec 2024 11:13: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 1tNVVn-0004Rn-7o; Tue, 17 Dec 2024 11:13:11 +0000
Received: by outflank-mailman (input) for mailman id 858782;
 Tue, 17 Dec 2024 11:13: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 1tNVVl-0002wn-0Y
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 11:13:09 +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 e460714a-bc67-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 12:13:07 +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 DA9351F385;
 Tue, 17 Dec 2024 11:13:06 +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 8A0F5132EA;
 Tue, 17 Dec 2024 11:13:06 +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 aglPIMJcYWcLUQAAD6G6ig
 (envelope-from ); Tue, 17 Dec 2024 11:13: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: e460714a-bc67-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734433986; 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=lvYibJo92jiscLd1OpjPvmRaZg5ZdQ/HaYSiQ9WteiQ=;
	b=W0P0EB/G1k8uFy/TDgXDpdInFUaWQUJR4Lisgg3xva+22V+2dxRv5l+0jawmWrxTW8sHtr
	hxN3jkgRKu7jgDHvdMThXkONCUo/lWuKRZZPKlEBVhSWT28rrzR4MhSmc88sMRqs+usfg5
	8wLy3P8Xy1FkSeRocQxf5OOJ8WArsAk=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b="W0P0EB/G"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734433986; 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=lvYibJo92jiscLd1OpjPvmRaZg5ZdQ/HaYSiQ9WteiQ=;
	b=W0P0EB/G1k8uFy/TDgXDpdInFUaWQUJR4Lisgg3xva+22V+2dxRv5l+0jawmWrxTW8sHtr
	hxN3jkgRKu7jgDHvdMThXkONCUo/lWuKRZZPKlEBVhSWT28rrzR4MhSmc88sMRqs+usfg5
	8wLy3P8Xy1FkSeRocQxf5OOJ8WArsAk=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	"Daniel P. Smith" ,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v4 3/5] xen: add new domctl get_changed_domain
Date: Tue, 17 Dec 2024 12:12:45 +0100
Message-ID: <20241217111247.2204-4-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217111247.2204-1-jgross@suse.com>
References: <20241217111247.2204-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: DA9351F385
X-Spam-Level: 
X-Spamd-Result: default: False [-3.01 / 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)[];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	RCVD_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RCPT_COUNT_SEVEN(0.00)[10];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:email,suse.com:dkim,suse.com:mid];
	RCVD_TLS_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	DKIM_TRACE(0.00)[suse.com:+]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -3.01
X-Spam-Flag: NO

Add a new domctl sub-function to get data of a domain having changed
state (this is needed by Xenstore).

The returned state just contains the domid, the domain unique id,
and some flags (existing, shutdown, dying).

In order to enable Xenstore stubdom being built for multiple Xen
versions, make this domctl stable.  For stable domctls the
interface_version is always 0.

Signed-off-by: Juergen Gross 
---
V1:
- use a domctl subop for the new interface (Jan Beulich)
V2:
- fix XSM hooks (Daniel P. Smith)
- remove versioning of stable sub-ops (Jan Beulich)
- use domctl.domain for retuning domid of a changed domain (Jan Beulich)
- simplify locking in get_domain_state() (Jan Beulich)
- undo stray change in event_channel.c (Jan Beulich)
V3:
- have disjunct states "dying" and "dead" (Jan Beulich)
- check padding fields to be 0 (Jan Beulich)
- drop memset() (Jan Beulich)
V4:
- add locking in get_domain_state() (Jan Beulich)
- only allow querying domain having changed state by domain receiving
  VIRQ_DOM_EXC events (Jan Beulich)
---
 tools/flask/policy/modules/dom0.te     |  2 +-
 tools/flask/policy/modules/xen.if      |  4 +-
 tools/flask/policy/modules/xenstore.te |  1 +
 xen/common/domain.c                    | 70 ++++++++++++++++++++++++++
 xen/common/domctl.c                    | 18 ++++++-
 xen/common/event_channel.c             |  9 +++-
 xen/include/public/domctl.h            | 26 ++++++++++
 xen/include/xen/event.h                |  7 +++
 xen/include/xen/sched.h                |  2 +
 xen/include/xsm/dummy.h                |  8 +++
 xen/include/xsm/xsm.h                  |  6 +++
 xen/xsm/dummy.c                        |  1 +
 xen/xsm/flask/hooks.c                  |  7 +++
 xen/xsm/flask/policy/access_vectors    |  2 +
 14 files changed, 158 insertions(+), 5 deletions(-)

diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
index 16b8c9646d..6043c01b12 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -40,7 +40,7 @@ allow dom0_t dom0_t:domain {
 };
 allow dom0_t dom0_t:domain2 {
 	set_cpu_policy gettsc settsc setscheduler set_vnumainfo
-	get_vnumainfo psr_cmt_op psr_alloc get_cpu_policy
+	get_vnumainfo psr_cmt_op psr_alloc get_cpu_policy get_domain_state
 };
 allow dom0_t dom0_t:resource { add remove };
 
diff --git a/tools/flask/policy/modules/xen.if b/tools/flask/policy/modules/xen.if
index 11c1562aa5..2e06f3ed94 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -54,7 +54,7 @@ define(`create_domain_common', `
 	allow $1 $2:domain2 { set_cpu_policy settsc setscheduler setclaim
 			set_vnumainfo get_vnumainfo cacheflush
 			psr_cmt_op psr_alloc soft_reset
-			resource_map get_cpu_policy };
+			resource_map get_cpu_policy get_domain_state };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
@@ -94,7 +94,7 @@ define(`manage_domain', `
 			getaddrsize pause unpause trigger shutdown destroy
 			setaffinity setdomainmaxmem getscheduler resume
 			setpodtarget getpodtarget getpagingmempool setpagingmempool };
-    allow $1 $2:domain2 set_vnumainfo;
+    allow $1 $2:domain2 { set_vnumainfo get_domain_state };
 ')
 
 # migrate_domain_out(priv, target)
diff --git a/tools/flask/policy/modules/xenstore.te b/tools/flask/policy/modules/xenstore.te
index 519566ab81..49de53ebe2 100644
--- a/tools/flask/policy/modules/xenstore.te
+++ b/tools/flask/policy/modules/xenstore.te
@@ -13,6 +13,7 @@ allow dom0_t xenstore_t:domain set_virq_handler;
 allow xenstore_t xen_t:xen writeconsole;
 # Xenstore queries domaininfo on all domains
 allow xenstore_t domain_type:domain getdomaininfo;
+allow xenstore_t domain_type:domain2 get_domain_state;
 
 # As a shortcut, the following 3 rules are used instead of adding a domain_comms
 # rule between xenstore_t and every domain type that talks to xenstore
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 87633b1f7b..e7248cfc9b 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -193,6 +193,76 @@ static void domain_changed_state(const struct domain *d)
     spin_unlock(&dom_state_changed_lock);
 }
 
+static void set_domain_state_info(struct xen_domctl_get_domain_state *info,
+                                  const struct domain *d)
+{
+    info->state = XEN_DOMCTL_GETDOMSTATE_STATE_EXIST;
+    if ( d->is_shut_down )
+        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN;
+    if ( d->is_dying == DOMDYING_dying )
+        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DYING;
+    if ( d->is_dying == DOMDYING_dead )
+        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DEAD;
+    info->unique_id = d->unique_id;
+}
+
+int get_domain_state(struct xen_domctl_get_domain_state *info, struct domain *d,
+                     domid_t *domid)
+{
+    unsigned int dom;
+    int rc = -ENOENT;
+
+    if ( info->pad0 || info->pad1 )
+        return -EINVAL;
+
+    if ( d )
+    {
+        set_domain_state_info(info, d);
+
+        return 0;
+    }
+
+    /*
+     * Only domain registered for VIRQ_DOM_EXC event is allowed to query
+     * domains having changed state.
+     */
+    if ( !domain_handles_global_virq(current->domain, VIRQ_DOM_EXC) )
+        return -EACCES;
+
+    spin_lock(&dom_state_changed_lock);
+
+    if ( dom_state_changed )
+    {
+        dom = find_first_bit(dom_state_changed, DOMID_MASK + 1);
+        if ( dom < DOMID_FIRST_RESERVED )
+        {
+            __clear_bit(dom, dom_state_changed);
+
+            *domid = dom;
+
+            d = rcu_lock_domain_by_id(dom);
+
+            if ( d )
+            {
+                set_domain_state_info(info, d);
+
+                rcu_unlock_domain(d);
+            }
+            else
+            {
+                info->state = 0;
+                info->unique_id = 0;
+            }
+
+            rc = 0;
+        }
+    }
+
+    spin_unlock(&dom_state_changed_lock);
+
+    return rc;
+}
+
 static void __domain_finalise_shutdown(struct domain *d)
 {
     struct vcpu *v;
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 444e072fdc..802bd7596e 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -278,6 +278,11 @@ static struct vnuma_info *vnuma_init(const struct xen_domctl_vnuma *uinfo,
     return ERR_PTR(ret);
 }
 
+static bool is_stable_domctl(uint32_t cmd)
+{
+    return cmd == XEN_DOMCTL_get_domain_state;
+}
+
 long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 {
     long ret = 0;
@@ -288,7 +293,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     if ( copy_from_guest(op, u_domctl, 1) )
         return -EFAULT;
 
-    if ( op->interface_version != XEN_DOMCTL_INTERFACE_VERSION )
+    if ( op->interface_version !=
+         (is_stable_domctl(op->cmd) ? 0 : XEN_DOMCTL_INTERFACE_VERSION) )
         return -EACCES;
 
     switch ( op->cmd )
@@ -309,6 +315,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         fallthrough;
     case XEN_DOMCTL_test_assign_device:
     case XEN_DOMCTL_vm_event_op:
+    case XEN_DOMCTL_get_domain_state:
         if ( op->domain == DOMID_INVALID )
         {
             d = NULL;
@@ -866,6 +873,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
                 __HYPERVISOR_domctl, "h", u_domctl);
         break;
 
+    case XEN_DOMCTL_get_domain_state:
+        ret = xsm_get_domain_state(XSM_XS_PRIV, d);
+        if ( ret )
+            break;
+
+        copyback = 1;
+        ret = get_domain_state(&op->u.get_domain_state, d, &op->domain);
+        break;
+
     default:
         ret = arch_do_domctl(op, d, u_domctl);
         break;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 041aacad02..358eff0b81 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -993,6 +993,13 @@ void send_global_virq(uint32_t virq)
     send_guest_global_virq(global_virq_handlers[virq] ?: hardware_domain, virq);
 }
 
+bool domain_handles_global_virq(struct domain *d, uint32_t virq)
+{
+    ASSERT(virq_is_global(virq));
+
+    return global_virq_handlers[virq] == d;
+}
+
 int set_global_virq_handler(struct domain *d, uint32_t virq)
 {
     struct domain *old;
@@ -1002,7 +1009,7 @@ int set_global_virq_handler(struct domain *d, uint32_t virq)
     if (!virq_is_global(virq))
         return -EINVAL;
 
-    if (global_virq_handlers[virq] == d)
+    if ( domain_handles_global_virq(d, virq) )
         return 0;
 
     if (unlikely(!get_domain(d)))
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 353f831e40..13fe17ab0a 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -28,6 +28,7 @@
  * Pure additions (e.g. new sub-commands) or compatible interface changes
  * (e.g. adding semantics to 0-checked input fields or data to zeroed output
  * fields) don't require a change of the version.
+ * Stable ops are NOT covered by XEN_DOMCTL_INTERFACE_VERSION!
  *
  * Last version bump: Xen 4.19
  */
@@ -1236,7 +1237,30 @@ struct xen_domctl_dt_overlay {
 };
 #endif
 
+/*
+ * XEN_DOMCTL_get_domain_state (stable interface)
+ *
+ * Get state information of a domain.
+ *
+ * In case domain is DOMID_INVALID, return information about a domain having
+ * changed state and reset the state change indicator for that domain. This
+ * function is usable only by a domain having registered the VIRQ_DOM_EXC
+ * event (normally Xenstore).
+ * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
+ */
+struct xen_domctl_get_domain_state {
+    uint16_t state;
+#define XEN_DOMCTL_GETDOMSTATE_STATE_EXIST     0x0001  /* Domain is existing. */
+#define XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN  0x0002  /* Shutdown finished. */
+#define XEN_DOMCTL_GETDOMSTATE_STATE_DYING     0x0004  /* Domain dying. */
+#define XEN_DOMCTL_GETDOMSTATE_STATE_DEAD      0x0008  /* Domain dead. */
+    uint16_t pad0;           /* Must be 0 on input, returned as 0. */
+    uint32_t pad1;           /* Must be 0 on input, returned as 0. */
+    uint64_t unique_id;      /* Unique domain identifier. */
+};
+
 struct xen_domctl {
+/* Stable domctl ops: interface_version is required to be 0.  */
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
 #define XEN_DOMCTL_destroydomain                  2
@@ -1325,6 +1349,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_set_paging_mempool_size       86
 #define XEN_DOMCTL_dt_overlay                    87
 #define XEN_DOMCTL_gsi_permission                88
+#define XEN_DOMCTL_get_domain_state              89 /* stable interface */
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1391,6 +1416,7 @@ struct xen_domctl {
 #if defined(__arm__) || defined(__aarch64__)
         struct xen_domctl_dt_overlay        dt_overlay;
 #endif
+        struct xen_domctl_get_domain_state  get_domain_state;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 48b79f3d62..3a119505c6 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -36,6 +36,13 @@ void send_global_virq(uint32_t virq);
  */
 void send_guest_global_virq(struct domain *d, uint32_t virq);
 
+/*
+ * domain_handles_global_virq:
+ *  @d:        Suspected target domain for this VIRQ
+ *  @virq:     Virtual IRQ number (VIRQ_*), must be global
+ */
+bool domain_handles_global_virq(struct domain *d, uint32_t virq);
+
 /*
  * sent_global_virq_handler: Set a global VIRQ handler.
  *  @d:        New target domain for this VIRQ
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 16684bbaf9..5e9858c3ba 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -802,6 +802,8 @@ int domain_soft_reset(struct domain *d, bool resuming);
 
 int domain_init_states(void);
 void domain_deinit_states(void);
+int get_domain_state(struct xen_domctl_get_domain_state *info,
+                     struct domain *d, domid_t *domid);
 
 int vcpu_start_shutdown_deferral(struct vcpu *v);
 void vcpu_end_shutdown_deferral(struct vcpu *v);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index f8a3c4b81e..a1a5bb60e9 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -173,6 +173,7 @@ static XSM_INLINE int cf_check xsm_domctl(
     case XEN_DOMCTL_unbind_pt_irq:
         return xsm_default_action(XSM_DM_PRIV, current->domain, d);
     case XEN_DOMCTL_getdomaininfo:
+    case XEN_DOMCTL_get_domain_state:
         return xsm_default_action(XSM_XS_PRIV, current->domain, d);
     default:
         return xsm_default_action(XSM_PRIV, current->domain, d);
@@ -815,6 +816,13 @@ static XSM_INLINE int cf_check xsm_argo_send(
 
 #endif /* CONFIG_ARGO */
 
+static XSM_INLINE int cf_check xsm_get_domain_state(
+    XSM_DEFAULT_ARG struct domain *d)
+{
+    XSM_ASSERT_ACTION(XSM_XS_PRIV);
+    return xsm_default_action(action, current->domain, d);
+}
+
 #include 
 static XSM_INLINE int cf_check xsm_xen_version(XSM_DEFAULT_ARG uint32_t op)
 {
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 4dbff9d866..0689bf5c9f 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -200,6 +200,7 @@ struct xsm_ops {
     int (*argo_register_any_source)(const struct domain *d);
     int (*argo_send)(const struct domain *d, const struct domain *t);
 #endif
+    int (*get_domain_state)(struct domain *d);
 };
 
 #ifdef CONFIG_XSM
@@ -774,6 +775,11 @@ static inline int xsm_argo_send(const struct domain *d, const struct domain *t)
 
 #endif /* CONFIG_ARGO */
 
+static inline int xsm_get_domain_state(struct domain *d)
+{
+    return alternative_call(xsm_ops.get_domain_state, d);
+}
+
 #endif /* XSM_NO_WRAPPERS */
 
 #ifdef CONFIG_MULTIBOOT
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index e6ffa948f7..ce6fbdc6c5 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -148,6 +148,7 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .argo_register_any_source      = xsm_argo_register_any_source,
     .argo_send                     = xsm_argo_send,
 #endif
+    .get_domain_state              = xsm_get_domain_state,
 };
 
 void __init xsm_fixup_ops(struct xsm_ops *ops)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a79474ffe4..e110846ad9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -688,6 +688,7 @@ static int cf_check flask_domctl(struct domain *d, unsigned int cmd,
     case XEN_DOMCTL_memory_mapping:
     case XEN_DOMCTL_set_target:
     case XEN_DOMCTL_vm_event_op:
+    case XEN_DOMCTL_get_domain_state:
 
     /* These have individual XSM hooks (arch/../domctl.c) */
     case XEN_DOMCTL_bind_pt_irq:
@@ -1856,6 +1857,11 @@ static int cf_check flask_argo_send(
 
 #endif
 
+static int cf_check flask_get_domain_state(struct domain *d)
+{
+    return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GET_DOMAIN_STATE);
+}
+
 static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .set_system_active = flask_set_system_active,
     .security_domaininfo = flask_security_domaininfo,
@@ -1992,6 +1998,7 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .argo_register_any_source = flask_argo_register_any_source,
     .argo_send = flask_argo_send,
 #endif
+    .get_domain_state = flask_get_domain_state,
 };
 
 const struct xsm_ops *__init flask_init(
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index a35e3d4c51..c9a8eeda4e 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -251,6 +251,8 @@ class domain2
     resource_map
 # XEN_DOMCTL_get_cpu_policy
     get_cpu_policy
+# XEN_DOMCTL_get_domain_state
+    get_domain_state
 }
 
 # Similar to class domain, but primarily contains domctls related to HVM domains
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 11:13:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 11:13:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858786.1271055 (Exim 4.92)
	(envelope-from )
	id 1tNVVq-0004nP-No; Tue, 17 Dec 2024 11:13:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858786.1271055; Tue, 17 Dec 2024 11:13: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 1tNVVq-0004nI-KG; Tue, 17 Dec 2024 11:13:14 +0000
Received: by outflank-mailman (input) for mailman id 858786;
 Tue, 17 Dec 2024 11:13: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 1tNVVp-0003La-Oc
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 11:13:13 +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 e7c04fb4-bc67-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 12:13:12 +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 707641F385;
 Tue, 17 Dec 2024 11:13:12 +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 4C3FB132EA;
 Tue, 17 Dec 2024 11:13:12 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id jS4gEchcYWcQUQAAD6G6ig
 (envelope-from ); Tue, 17 Dec 2024 11:13: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: e7c04fb4-bc67-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734433992; 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=nEj0rU7fUJdxnb+34yZOLrAkY9HqJgVtVSezjvYU+Qo=;
	b=npMvvAFc4tFnxrINtslZd7DFRbWoN6qVfFar/a6g20mk/xi7zWA+Dq9VS7LCDctiiMWxSt
	kbMU3+yntXqFjmX9FQUG6nx16ii5VeCn1hwa37e5ijc3vFzOXhwGPf9TwP42gFPqw/bhMF
	rV9LiXCWi+cX2fNqoG6bTVUk+WFxVWI=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=npMvvAFc
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734433992; 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=nEj0rU7fUJdxnb+34yZOLrAkY9HqJgVtVSezjvYU+Qo=;
	b=npMvvAFc4tFnxrINtslZd7DFRbWoN6qVfFar/a6g20mk/xi7zWA+Dq9VS7LCDctiiMWxSt
	kbMU3+yntXqFjmX9FQUG6nx16ii5VeCn1hwa37e5ijc3vFzOXhwGPf9TwP42gFPqw/bhMF
	rV9LiXCWi+cX2fNqoG6bTVUk+WFxVWI=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Anthony PERARD 
Subject: [PATCH v4 4/5] tools/libs: add a new libxenmanage library
Date: Tue, 17 Dec 2024 12:12:46 +0100
Message-ID: <20241217111247.2204-5-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217111247.2204-1-jgross@suse.com>
References: <20241217111247.2204-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 707641F385
X-Spam-Score: -3.01
X-Rspamd-Action: no action
X-Spamd-Result: default: False [-3.01 / 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)[];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	TO_DN_SOME(0.00)[];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[gnu.org:url,suse.com:dkim,suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo];
	RCVD_TLS_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	DKIM_TRACE(0.00)[suse.com:+]
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Flag: NO
X-Spam-Level: 

In order to have a stable interface in user land for using stable
domctl and possibly later sysctl interfaces, add a new library
libxenmanage.

Signed-off-by: Juergen Gross 
Reviewed-by: Anthony PERARD 
---
V1:
- new patch
V2:
- define __XEN_TOOLS__ via Makefile (Anthony PERARD)
- use SPDX in header file (Anthony PERARD)
- change function name to xenmanage_poll_changed_domain() (Anthony PERARD)
- add short library description (Anthony PERARD)
- narrow scope of xen_domctl_get_domain_state pointer (Anthony PERARD)
V4:
- use LGPL-2.1-only SPDX identifier (Anthony PERARD)
---
 tools/include/xenmanage.h          |  92 ++++++++++++++++
 tools/libs/Makefile                |   1 +
 tools/libs/manage/Makefile         |  10 ++
 tools/libs/manage/Makefile.common  |   3 +
 tools/libs/manage/core.c           | 168 +++++++++++++++++++++++++++++
 tools/libs/manage/libxenmanage.map |   8 ++
 tools/libs/uselibs.mk              |   2 +
 7 files changed, 284 insertions(+)
 create mode 100644 tools/include/xenmanage.h
 create mode 100644 tools/libs/manage/Makefile
 create mode 100644 tools/libs/manage/Makefile.common
 create mode 100644 tools/libs/manage/core.c
 create mode 100644 tools/libs/manage/libxenmanage.map

diff --git a/tools/include/xenmanage.h b/tools/include/xenmanage.h
new file mode 100644
index 0000000000..956b7a0a44
--- /dev/null
+++ b/tools/include/xenmanage.h
@@ -0,0 +1,92 @@
+/* SPDX-License-Identifier: LGPL-2.1-only */
+/*
+ * Copyright (c) 2024 SUSE Software Solutions Germany GmbH
+ *
+ * Interfaces of libxenmanage.
+ *
+ * libxenmanage provides management functions for the host using stable
+ * hypercall interfaces.
+ */
+#ifndef XENMANAGE_H
+#define XENMANAGE_H
+
+#include 
+
+/* Avoid the need to #include  */
+struct xentoollog_logger;
+
+typedef struct xenmanage_handle xenmanage_handle;
+
+/*
+ * Open libxenmanage.
+ *
+ * Get a handle of the xenmanage library. The handle is required for all
+ * further operations of the library.
+ * Parameters:
+ *   logger:     Logging function to use. If NULL logging is done to stderr.
+ *   open_flags: Only 0 supported.
+ * Return value: Handle or NULL if error.
+ */
+xenmanage_handle *xenmanage_open(struct xentoollog_logger *logger,
+                                 unsigned int open_flags);
+
+/*
+ * Close libxenmanage.
+ *
+ * Return a handle of the xenmanage library.
+ * Parameters:
+ *    hdl: Handle obtained by xenmanage_open().
+ * Return value: always 0.
+ */
+int xenmanage_close(xenmanage_handle *hdl);
+
+#define XENMANAGE_GETDOMSTATE_STATE_EXIST     0x0001  /* Domain is existing. */
+#define XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN  0x0002  /* Shutdown finished. */
+#define XENMANAGE_GETDOMSTATE_STATE_DYING     0x0004  /* Domain dying. */
+#define XENMANAGE_GETDOMSTATE_STATE_DEAD      0x0008  /* Domain dead. */
+
+/*
+ * Return state information of an existing domain.
+ *
+ * Returns the domain state and unique id of the given domain.
+ * Parameters:
+ *   hdl:       handle returned by xenmanage_open()
+ *   domid:     domain id of the domain to get the information for
+ *   state:     where to store the state (XENMANAGE_GETDOMSTATE_STATE_ flags,
+ *              nothing stored if NULL)
+ *   unique_id: where to store the unique id of the domain (nothing stored if
+ *              NULL)
+ * Return value: 0 if information was stored, -1 else (errno is set)
+ */
+int xenmanage_get_domain_info(xenmanage_handle *hdl, unsigned int domid,
+                              unsigned int *state, uint64_t *unique_id);
+
+/*
+ * Return information of a domain having changed state recently.
+ *
+ * Returns the domain id, state and unique id of a domain having changed
+ * state (any of the state bits was modified) since the last time information
+ * for that domain was returned by this function. Only usable by callers who
+ * have registered the VIRQ_DOM_EXC event (normally Xenstore).
+ * Parameters:
+ *   hdl:       handle returned by xenmanage_open()
+ *   domid:     where to store the domid of the domain (not NULL)
+ *   state:     where to store the state (XENMANAGE_GETDOMSTATE_STATE_ flags,
+ *              nothing stored if NULL)
+ *   unique_id: where to store the unique id of the domain (nothing stored if
+ *              NULL)
+ * Return value: 0 if information was stored, -1 else (errno is set)
+ */
+int xenmanage_poll_changed_domain(xenmanage_handle *hdl, unsigned int *domid,
+                                  unsigned int *state, uint64_t *unique_id);
+#endif /* XENMANAGE_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libs/Makefile b/tools/libs/Makefile
index 1afcd12e2b..d39516c1b3 100644
--- a/tools/libs/Makefile
+++ b/tools/libs/Makefile
@@ -12,6 +12,7 @@ SUBDIRS-y += devicemodel
 SUBDIRS-y += ctrl
 SUBDIRS-y += guest
 SUBDIRS-y += hypfs
+SUBDIRS-y += manage
 SUBDIRS-y += store
 SUBDIRS-y += stat
 SUBDIRS-$(CONFIG_Linux) += vchan
diff --git a/tools/libs/manage/Makefile b/tools/libs/manage/Makefile
new file mode 100644
index 0000000000..dbfe70d259
--- /dev/null
+++ b/tools/libs/manage/Makefile
@@ -0,0 +1,10 @@
+XEN_ROOT = $(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+MAJOR    = 1
+MINOR    = 0
+version-script := libxenmanage.map
+
+include Makefile.common
+
+include $(XEN_ROOT)/tools/libs/libs.mk
diff --git a/tools/libs/manage/Makefile.common b/tools/libs/manage/Makefile.common
new file mode 100644
index 0000000000..533ba30fba
--- /dev/null
+++ b/tools/libs/manage/Makefile.common
@@ -0,0 +1,3 @@
+CFLAGS += -D__XEN_TOOLS__
+
+OBJS-y  += core.o
diff --git a/tools/libs/manage/core.c b/tools/libs/manage/core.c
new file mode 100644
index 0000000000..b5fa67b036
--- /dev/null
+++ b/tools/libs/manage/core.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright (c) 2024 SUSE Software Solutions Germany GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see .
+ */
+
+#define _GNU_SOURCE
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct xenmanage_handle {
+    xentoollog_logger *logger, *logger_tofree;
+    unsigned int flags;
+    xencall_handle *xcall;
+};
+
+xenmanage_handle *xenmanage_open(xentoollog_logger *logger,
+                                 unsigned open_flags)
+{
+    xenmanage_handle *hdl = calloc(1, sizeof(*hdl));
+    int saved_errno;
+
+    if ( !hdl )
+        return NULL;
+
+    if ( open_flags )
+    {
+        errno = EINVAL;
+        goto err;
+    }
+
+    hdl->flags = open_flags;
+    hdl->logger = logger;
+    hdl->logger_tofree = NULL;
+
+    if ( !hdl->logger )
+    {
+        hdl->logger = hdl->logger_tofree =
+            (xentoollog_logger *)
+            xtl_createlogger_stdiostream(stderr, XTL_PROGRESS, 0);
+        if ( !hdl->logger )
+            goto err;
+    }
+
+    hdl->xcall = xencall_open(hdl->logger, 0);
+    if ( !hdl->xcall )
+        goto err;
+
+    return hdl;
+
+err:
+    saved_errno = errno;
+    xenmanage_close(hdl);
+    errno = saved_errno;
+
+    return NULL;
+}
+
+int xenmanage_close(xenmanage_handle *hdl)
+{
+    if ( !hdl )
+        return 0;
+
+    xencall_close(hdl->xcall);
+    xtl_logger_destroy(hdl->logger_tofree);
+    free(hdl);
+    return 0;
+}
+
+static int xenmanage_do_domctl_get_domain_state(xenmanage_handle *hdl,
+                                                unsigned int domid_in,
+                                                unsigned int *domid_out,
+                                                unsigned int *state,
+                                                uint64_t *unique_id)
+{
+    struct xen_domctl *buf;
+    int saved_errno;
+    int ret;
+
+    buf = xencall_alloc_buffer(hdl->xcall, sizeof(*buf));
+    if ( !buf )
+    {
+        errno = ENOMEM;
+        return -1;
+    }
+
+    memset(buf, 0, sizeof(*buf));
+
+    buf->cmd = XEN_DOMCTL_get_domain_state;
+    buf->domain = domid_in;
+
+    ret = xencall1(hdl->xcall, __HYPERVISOR_domctl, (unsigned long)buf);
+    saved_errno = errno;
+    if ( !ret )
+    {
+        struct xen_domctl_get_domain_state *st = &buf->u.get_domain_state;
+
+        if ( domid_out )
+            *domid_out = buf->domain;
+        if ( state )
+        {
+            *state = 0;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_EXIST )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_EXIST;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_DYING )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_DYING;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_DEAD )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_DEAD;
+        }
+        if ( unique_id )
+            *unique_id = st->unique_id;
+    }
+
+    xencall_free_buffer(hdl->xcall, buf);
+
+    errno = saved_errno;
+
+    return ret;
+}
+
+int xenmanage_get_domain_info(xenmanage_handle *hdl, unsigned int domid,
+                              unsigned int *state, uint64_t *unique_id)
+{
+    if ( !hdl || domid >= DOMID_FIRST_RESERVED )
+    {
+        errno = EINVAL;
+        return -1;
+    }
+
+    return xenmanage_do_domctl_get_domain_state(hdl, domid, NULL, state,
+                                                unique_id);
+}
+
+int xenmanage_poll_changed_domain(xenmanage_handle *hdl, unsigned int *domid,
+                                  unsigned int *state, uint64_t *unique_id)
+{
+    if ( !hdl || !domid )
+    {
+        errno = EINVAL;
+        return -1;
+    }
+
+    return xenmanage_do_domctl_get_domain_state(hdl, DOMID_INVALID, domid,
+                                                state, unique_id);
+}
diff --git a/tools/libs/manage/libxenmanage.map b/tools/libs/manage/libxenmanage.map
new file mode 100644
index 0000000000..64c793e603
--- /dev/null
+++ b/tools/libs/manage/libxenmanage.map
@@ -0,0 +1,8 @@
+VERS_1.0 {
+	global:
+		xenmanage_open;
+		xenmanage_close;
+		xenmanage_get_domain_info;
+		xenmanage_poll_changed_domain;
+	local: *; /* Do not expose anything by default */
+};
diff --git a/tools/libs/uselibs.mk b/tools/libs/uselibs.mk
index 7aa8d83e06..c0a234cfec 100644
--- a/tools/libs/uselibs.mk
+++ b/tools/libs/uselibs.mk
@@ -16,6 +16,8 @@ LIBS_LIBS += devicemodel
 USELIBS_devicemodel := toollog toolcore call
 LIBS_LIBS += hypfs
 USELIBS_hypfs := toollog toolcore call
+LIBS_LIBS += manage
+USELIBS_manage := toollog toolcore call
 LIBS_LIBS += ctrl
 USELIBS_ctrl := toollog call evtchn gnttab foreignmemory devicemodel
 LIBS_LIBS += guest
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 11:13:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 11:13:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858795.1271065 (Exim 4.92)
	(envelope-from )
	id 1tNVVy-0005N2-Vt; Tue, 17 Dec 2024 11:13:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858795.1271065; Tue, 17 Dec 2024 11:13: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 1tNVVy-0005MP-So; Tue, 17 Dec 2024 11:13:22 +0000
Received: by outflank-mailman (input) for mailman id 858795;
 Tue, 17 Dec 2024 11:13: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 1tNVVx-0003La-6d
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 11:13:21 +0000
Received: from smtp-out2.suse.de (smtp-out2.suse.de
 [2a07:de40:b251:101:10:150:64:2])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id eb1a8487-bc67-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 12:13:18 +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 0F7A81F385;
 Tue, 17 Dec 2024 11:13:18 +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 D3628132EA;
 Tue, 17 Dec 2024 11:13:17 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id bzkTMs1cYWcWUQAAD6G6ig
 (envelope-from ); Tue, 17 Dec 2024 11:13: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: eb1a8487-bc67-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734433998; 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=U4Ln9oY8teJqj0oQ6om9doDIAfM1X4V+dyEL2CQtrKA=;
	b=tc7P+7aBdeQaxGbcvnmQT7Fi2HVl4Lqv+R3Di5l2eob4q1pZNF3Z1R31Arthoa3+yMLqKO
	0EOpeGlNRF9SeOcaO54sqSccJ46F2Rdc33lZS6z6fkWxn6dIS6rCVliTgQeMHE4fhv2NpE
	OdCFTKwnn5wvqtIU7jzYgWArU2dwab8=
Authentication-Results: smtp-out2.suse.de;
	dkim=pass header.d=suse.com header.s=susede1 header.b=tc7P+7aB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734433998; 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=U4Ln9oY8teJqj0oQ6om9doDIAfM1X4V+dyEL2CQtrKA=;
	b=tc7P+7aBdeQaxGbcvnmQT7Fi2HVl4Lqv+R3Di5l2eob4q1pZNF3Z1R31Arthoa3+yMLqKO
	0EOpeGlNRF9SeOcaO54sqSccJ46F2Rdc33lZS6z6fkWxn6dIS6rCVliTgQeMHE4fhv2NpE
	OdCFTKwnn5wvqtIU7jzYgWArU2dwab8=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Anthony PERARD ,
	Samuel Thibault ,
	Julien Grall 
Subject: [PATCH v4 5/5] tools/xenstored: use new stable interface instead of libxenctrl
Date: Tue, 17 Dec 2024 12:12:47 +0100
Message-ID: <20241217111247.2204-6-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217111247.2204-1-jgross@suse.com>
References: <20241217111247.2204-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 0F7A81F385
X-Spam-Level: 
X-Spamd-Result: default: False [-3.01 / 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)[];
	R_DKIM_ALLOW(-0.20)[suse.com:s=susede1];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MX_GOOD(-0.01)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
	TO_DN_SOME(0.00)[];
	RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:email,suse.com:dkim,suse.com:mid];
	RCVD_TLS_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_FIVE(0.00)[5];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	DKIM_TRACE(0.00)[suse.com:+]
X-Rspamd-Server: rspamd2.dmz-prg2.suse.org
X-Rspamd-Action: no action
X-Spam-Score: -3.01
X-Spam-Flag: NO

Replace the current use of the unstable xc_domain_getinfo_single()
interface with the stable domctl XEN_DOMCTL_get_domain_state call
via the new libxenmanage library.

This will remove the last usage of libxenctrl by Xenstore, so update
the library dependencies accordingly.

For now only do a direct replacement without using the functionality
of obtaining information about domains having changed the state.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
V1:
- use library instead of direct hypercall, only replace current
  libxenctrl use case

Please note that this patch can be committed only after the related
Mini-OS patch "config: add support for libxenmanage" has gone in AND
the Mini-OS commit-id has been updated in Config.mk accordingly!

Signed-off-by: Juergen Gross 
---
 stubdom/Makefile                |  8 ++---
 stubdom/mini-os.mk              |  1 +
 tools/xenstored/Makefile        |  2 +-
 tools/xenstored/Makefile.common |  2 +-
 tools/xenstored/core.h          |  1 -
 tools/xenstored/domain.c        | 52 ++++++++++++---------------------
 tools/xenstored/lu.c            |  1 +
 tools/xenstored/lu_daemon.c     |  1 +
 8 files changed, 28 insertions(+), 40 deletions(-)

diff --git a/stubdom/Makefile b/stubdom/Makefile
index 2a81af28a1..ca800b243c 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -307,7 +307,7 @@ endif
 # libraries under tools/libs
 #######
 
-STUB_LIBS := toolcore toollog evtchn gnttab call foreignmemory devicemodel ctrl guest
+STUB_LIBS := toolcore toollog evtchn gnttab call foreignmemory devicemodel ctrl guest manage
 
 LIBDEP_guest := cross-zlib
 
@@ -465,7 +465,7 @@ grub: cross-polarssl grub-upstream $(CROSS_ROOT) grub-$(XEN_TARGET_ARCH)-minios-
 # xenstore
 ##########
 
-xenstore-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog ctrl
+xenstore-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog manage
 xenstore-minios.gen.cfg: xenstore-minios.cfg Makefile
 	$(GEN_config) >$@
 
@@ -480,7 +480,7 @@ xenstore: $(CROSS_ROOT) xenstore-minios-config.mk
 # xenstorepvh
 #############
 
-xenstorepvh-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog ctrl
+xenstorepvh-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog manage
 xenstorepvh-minios.gen.cfg: xenstorepvh-minios.cfg Makefile
 	$(GEN_config) >$@
 
@@ -523,7 +523,7 @@ else
 pv-grub-if-enabled:
 endif
 
-XENSTORE_DEPS := libxenevtchn libxengnttab libxenctrl
+XENSTORE_DEPS := libxenevtchn libxengnttab libxenmanage
 
 .PHONY: xenstore-stubdom
 xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore $(XENSTORE_DEPS) xenstore
diff --git a/stubdom/mini-os.mk b/stubdom/mini-os.mk
index 7e4968e026..be32302f9e 100644
--- a/stubdom/mini-os.mk
+++ b/stubdom/mini-os.mk
@@ -13,5 +13,6 @@ GNTTAB_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/gnttab
 CALL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/call
 FOREIGNMEMORY_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/foreignmemory
 DEVICEMODEL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/devicemodel
+MANAGE_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/manage
 CTRL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/ctrl
 GUEST_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/guest
diff --git a/tools/xenstored/Makefile b/tools/xenstored/Makefile
index 09adfe1d50..81c42838e0 100644
--- a/tools/xenstored/Makefile
+++ b/tools/xenstored/Makefile
@@ -5,7 +5,7 @@ include Makefile.common
 
 xenstored: LDLIBS += $(LDLIBS_libxenevtchn)
 xenstored: LDLIBS += $(LDLIBS_libxengnttab)
-xenstored: LDLIBS += $(LDLIBS_libxenctrl)
+xenstored: LDLIBS += $(LDLIBS_libxenmanage)
 xenstored: LDLIBS += -lrt
 xenstored: LDLIBS += $(SOCKET_LIBS)
 
diff --git a/tools/xenstored/Makefile.common b/tools/xenstored/Makefile.common
index 27fdb3b49e..271134fcc1 100644
--- a/tools/xenstored/Makefile.common
+++ b/tools/xenstored/Makefile.common
@@ -12,7 +12,7 @@ XENSTORED_OBJS-$(CONFIG_MiniOS) += minios.o lu_minios.o
 # Include configure output (config.h)
 CFLAGS += -include $(XEN_ROOT)/tools/config.h
 CFLAGS += $(CFLAGS_libxenevtchn)
-CFLAGS += $(CFLAGS_libxenctrl)
+CFLAGS += $(CFLAGS_libxenmanage)
 CFLAGS += $(CFLAGS_libxentoolcore)
 
 $(XENSTORED_OBJS-y): CFLAGS += $(CFLAGS_libxengnttab)
diff --git a/tools/xenstored/core.h b/tools/xenstored/core.h
index e58779e88c..632886cecf 100644
--- a/tools/xenstored/core.h
+++ b/tools/xenstored/core.h
@@ -19,7 +19,6 @@
 #ifndef _XENSTORED_CORE_H
 #define _XENSTORED_CORE_H
 
-#include 
 #include 
 
 #include 
diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c
index 64c8fd0cc3..a6506a5bb2 100644
--- a/tools/xenstored/domain.c
+++ b/tools/xenstored/domain.c
@@ -34,14 +34,15 @@
 #include "control.h"
 
 #include 
-#include 
+#include 
+#include 
 #include 
 
 #ifdef __MINIOS__
 #include 
 #endif
 
-static xc_interface **xc_handle;
+static xenmanage_handle *xm_handle;
 xengnttab_handle **xgt_handle;
 static evtchn_port_t virq_port;
 
@@ -619,32 +620,28 @@ static int destroy_domain(void *_domain)
 	return 0;
 }
 
-static bool get_domain_info(unsigned int domid, xc_domaininfo_t *dominfo)
-{
-	return xc_domain_getinfo_single(*xc_handle, domid, dominfo) == 0;
-}
-
 static int check_domain(const void *k, void *v, void *arg)
 {
-	xc_domaininfo_t dominfo;
+	unsigned int state;
 	struct connection *conn;
-	bool dom_valid;
+	int dom_invalid;
 	struct domain *domain = v;
 	bool *notify = arg;
 
-	dom_valid = get_domain_info(domain->domid, &dominfo);
+	dom_invalid = xenmanage_get_domain_info(xm_handle, domain->domid,
+						&state, NULL);
 	if (!domain->introduced) {
-		if (!dom_valid)
+		if (dom_invalid)
 			talloc_free(domain);
 		return 0;
 	}
-	if (dom_valid) {
-		if ((dominfo.flags & XEN_DOMINF_shutdown)
+	if (!dom_invalid) {
+		if ((state & XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN)
 		    && !domain->shutdown) {
 			domain->shutdown = true;
 			*notify = true;
 		}
-		if (!(dominfo.flags & XEN_DOMINF_dying))
+		if (!(state & XENMANAGE_GETDOMSTATE_STATE_DEAD))
 			return 0;
 	}
 	if (domain->conn) {
@@ -786,10 +783,9 @@ static struct domain *find_or_alloc_domain(const void *ctx, unsigned int domid)
 static struct domain *find_or_alloc_existing_domain(unsigned int domid)
 {
 	struct domain *domain;
-	xc_domaininfo_t dominfo;
 
 	domain = find_domain_struct(domid);
-	if (!domain && get_domain_info(domid, &dominfo))
+	if (!domain && !xenmanage_get_domain_info(xm_handle, domid, NULL, NULL))
 		domain = alloc_domain(NULL, domid);
 
 	return domain;
@@ -1187,12 +1183,6 @@ int do_reset_watches(const void *ctx, struct connection *conn,
 	return 0;
 }
 
-static int close_xc_handle(void *_handle)
-{
-	xc_interface_close(*(xc_interface**)_handle);
-	return 0;
-}
-
 static int close_xgt_handle(void *_handle)
 {
 	xengnttab_close(*(xengnttab_handle **)_handle);
@@ -1258,15 +1248,9 @@ void domain_early_init(void)
 	if (!domhash)
 		barf_perror("Failed to allocate domain hashtable");
 
-	xc_handle = talloc(talloc_autofree_context(), xc_interface*);
-	if (!xc_handle)
-		barf_perror("Failed to allocate domain handle");
-
-	*xc_handle = xc_interface_open(0,0,0);
-	if (!*xc_handle)
-		barf_perror("Failed to open connection to hypervisor");
-
-	talloc_set_destructor(xc_handle, close_xc_handle);
+	xm_handle = xenmanage_open(NULL, 0);
+	if (!xm_handle)
+		barf_perror("Failed to open connection to libxenmanage");
 
 	xgt_handle = talloc(talloc_autofree_context(), xengnttab_handle*);
 	if (!xgt_handle)
@@ -1306,6 +1290,8 @@ void domain_deinit(void)
 {
 	if (virq_port)
 		xenevtchn_unbind(xce_handle, virq_port);
+
+	xenmanage_close(xm_handle);
 }
 
 /*
@@ -1335,13 +1321,13 @@ int domain_alloc_permrefs(struct node_perms *perms)
 {
 	unsigned int i, domid;
 	struct domain *d;
-	xc_domaininfo_t dominfo;
 
 	for (i = 0; i < perms->num; i++) {
 		domid = perms->p[i].id;
 		d = find_domain_struct(domid);
 		if (!d) {
-			if (!get_domain_info(domid, &dominfo))
+			if (xenmanage_get_domain_info(xm_handle, domid,
+						      NULL, NULL))
 				perms->p[i].perms |= XS_PERM_IGNORE;
 			else if (!alloc_domain(NULL, domid))
 				return ENOMEM;
diff --git a/tools/xenstored/lu.c b/tools/xenstored/lu.c
index bec2a84e10..4fccbbc195 100644
--- a/tools/xenstored/lu.c
+++ b/tools/xenstored/lu.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/tools/xenstored/lu_daemon.c b/tools/xenstored/lu_daemon.c
index 6df6c80a2a..88d8d9e1b3 100644
--- a/tools/xenstored/lu_daemon.c
+++ b/tools/xenstored/lu_daemon.c
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 #include 
 
 #include "talloc.h"
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 11:31:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 11:31:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858849.1271076 (Exim 4.92)
	(envelope-from )
	id 1tNVmx-000147-Dm; Tue, 17 Dec 2024 11:30:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858849.1271076; Tue, 17 Dec 2024 11:30: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 1tNVmx-000140-9t; Tue, 17 Dec 2024 11:30:55 +0000
Received: by outflank-mailman (input) for mailman id 858849;
 Tue, 17 Dec 2024 11:30: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 1tNVmv-00013u-Lr
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 11:30:53 +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 5f53d63b-bc6a-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 12:30:52 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-4361a50e337so36154895e9.0
 for ; Tue, 17 Dec 2024 03:30:52 -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-4362557c462sm170346595e9.14.2024.12.17.03.30.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 03:30: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: 5f53d63b-bc6a-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734435052; x=1735039852; 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=d/mfsXunNSQNnIFYCopWatrMCH0ZKlN89edcoZT2Zvk=;
        b=Ng7CXuuB2rzn7/Zvv9rSEAKTftsH1vmwTMmmnFxmGPk0nCkUTmyolc20Cbew/Gh4yZ
         sBAStHigotFwGCZpDUqqAMpvutZBHu+ZF0dNbrFBewa0qoKLHtbvtdTKRTCaVh4l+89z
         cyEnmy+bkmcoQCvOlsg6ohIJd6g8Jfy3aH0l4IK4smTXTYcCI0DTZEpLDJV3P49B5cWh
         U/rs22Jy+RBsCdJBOLj1MPrKMWYwnewDYIFa6Ov+YZx8fRRr/9PwqRGQ9DTANVJ5hes7
         0JxfgYyf8wp4vpY6gNQ0wNBi48pJszGawfFDsnrzwGQPLWQ4ASPqmF/dB9kC1cFTIHGd
         ecvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734435052; x=1735039852;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=d/mfsXunNSQNnIFYCopWatrMCH0ZKlN89edcoZT2Zvk=;
        b=kyiGYKr8pm/x43ATK53g2WI41XaMLy1e6AO63/LhtjKCSDnZSPcWN8ONBkEbjHsnek
         nlfiCdeS62v1yeRvlgab/vG6gUiXygxylwEa/NzOZmJee4AG+/pfQeIpDJ7tdDT9cmqS
         QU7K3Ov2UAAOPWmoq92C/lGEy6VtEYcJUTXaXW2BXCcLunKXoylV+3Oi3q99wiiADIXR
         wzaebUhgj8ip1z6av6cdtZcjckfmm+fjMZQI6Ebtf05kxsIwWVgORDgvvcsnz7CRYPcn
         +RdHRzSRpkMxJ2XVGfdtVmUkAbk8tLRGgUCJzbPa95ihGTAGAI4vWHSJdNSXDRFJKnxX
         wEJQ==
X-Forwarded-Encrypted: i=1; AJvYcCU3kfqNktkoOiOvAE3VjsQHTIrldm5VYXNmAtiCuj5e2cmU7zYOzT/skHjl6mvzoHV58IswQCkS4u4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxvGnCkyjc++1tFZWVSLQpzwumjJnQQE/Ng913cLy+ZbicmjWS/
	/1bWvz9imRvwtnXSOke6OP/JE5dqCUvxdw7AepnGlcktRQYwB9sFPfPcULMzYQ==
X-Gm-Gg: ASbGncudXpzX0K2pXgnd/a0Do00G5hM/+hTRrqvBceQJM/uqIOR7YuM/JCWHVgOn+AR
	aOgaRots0W5xom9D31Gvb5NxQc8LpO/qbVqixy6EhGAtW0gWu2RcQDmFlYkFJL8k9Kor+zVnr6c
	vQp5WNX+zipLmR7LtMRUA+bf8JaCGuBjG+QaJ5LlUWkPXpHa+AmsB9WlcWE9fGMgjLBTLdPO9+/
	DgtZaN8/vZcIEvjLjuaK9qYaR6U9OPa59nx+a6HgGgwkj0nhIqk2D23l5DJcA84NPOPB4GEpDrQ
	8NTIgWMg7TNY/4Vd3mBSbtazxFdF+7N0W9A5Aqlg9Q==
X-Google-Smtp-Source: AGHT+IGFDi+qd2TrOWa1FyvulV6K+W6cOkNysDTgD+eF3tJ9xGun1j1fdddt4SddzCRowGGjsgaYqg==
X-Received: by 2002:a05:6000:1acf:b0:386:33e8:20f4 with SMTP id ffacd0b85a97d-3888e0c189dmr14466882f8f.59.1734435051819;
        Tue, 17 Dec 2024 03:30:51 -0800 (PST)
Message-ID: 
Date: Tue, 17 Dec 2024 12:30:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 2/5] xen: add bitmap to indicate per-domain state
 changes
To: Juergen Gross 
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: <20241217111247.2204-1-jgross@suse.com>
 <20241217111247.2204-3-jgross@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: <20241217111247.2204-3-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.12.2024 12:12, Juergen Gross wrote:
> V4:
> - add __read_mostly (Jan Beulich)
> - use __set_biz() (Jan Beulich)
> - fix error handling in evtchn_bind_virq() (Jan Beulich)

I'm sorry, I should have spotted a 2nd issue already when reviewing v3 (or
even an earlier version).

> @@ -138,6 +139,60 @@ bool __read_mostly vmtrace_available;
>  
>  bool __read_mostly vpmu_is_available;
>  
> +static DEFINE_SPINLOCK(dom_state_changed_lock);
> +static unsigned long *__read_mostly dom_state_changed;
> +
> +int domain_init_states(void)
> +{
> +    const struct domain *d;
> +    int rc = -ENOMEM;
> +
> +    spin_lock(&dom_state_changed_lock);
> +
> +    if ( dom_state_changed )
> +        bitmap_zero(dom_state_changed, DOMID_FIRST_RESERVED);

This needs to not happen when ...

> @@ -485,11 +486,21 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
>      if ( (v = domain_vcpu(d, vcpu)) == NULL )
>          return -ENOENT;
>  
> +    if ( virq == VIRQ_DOM_EXC )
> +    {
> +        rc = domain_init_states();
> +        if ( rc )
> +            return rc;
> +
> +        deinit_if_err = true;
> +    }
> +
>      write_lock(&d->event_lock);
>  
>      if ( read_atomic(&v->virq_to_evtchn[virq]) )
>      {
>          rc = -EEXIST;
> +        deinit_if_err = false;
>          gdprintk(XENLOG_WARNING, "EVTCHNOP failure: error %d\n", rc);
>          goto out;
>      }

... we take this error path. Which I think calls for moving the
domain_init_states() invocation ...

> @@ -527,6 +538,9 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
>   out:
>      write_unlock(&d->event_lock);
>  
> +    if ( rc && deinit_if_err )
> +        domain_deinit_states();
> +
>      return rc;
>  }

... somewhere here. It really doesn't need doing early, as the caller
may assume the bitmap was set up only when this hypercall returns
successfully.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 11:34:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 11:34:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858864.1271090 (Exim 4.92)
	(envelope-from )
	id 1tNVqg-00026O-2E; Tue, 17 Dec 2024 11:34:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858864.1271090; Tue, 17 Dec 2024 11: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 1tNVqf-00026H-Tg; Tue, 17 Dec 2024 11:34:45 +0000
Received: by outflank-mailman (input) for mailman id 858864;
 Tue, 17 Dec 2024 11:34: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 1tNVqe-00026A-KE
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 11:34:44 +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 e918cba6-bc6a-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 12:34:43 +0100 (CET)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-385e3621518so2627436f8f.1
 for ; Tue, 17 Dec 2024 03:34:43 -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-4362559ed8dsm174314595e9.23.2024.12.17.03.34.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 03:34: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: e918cba6-bc6a-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734435283; x=1735040083; 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=FGcCn7MS4hx/mI5jQMgSZdmLZ7w8ly50SQXxSiWuojM=;
        b=Eh5jJ+YLIP7pqeYK0mvciUJ+Z65FA13EHu8xFVAszg/P/mNoLyXtgg/JF35ekGfxpH
         6z6rKeiP/nfHi+7xSOKXHVq3hNgcDTCYvvAhCK7rblu3oUnYm/lTyi2Nw9oEFXSVdUTg
         Z3zBUVUM2A5pFmHxqN28e+K06WHQjhASRyinkB/0jSuVlzc23fqgALMT7tTbnN7WYxgd
         dLEJTsZnOkPUmRSwzAF/JSVXpHKaLjLfVnaUTIFkzJmNEOdsNRWUaoqtusJ6bGb69TFn
         DVINuBxFfbgNajtlRNVwXTksTvZBctePB9NgLhV0YIhFGOxpfD8SX0HQ1AGDBChXjbb9
         ESTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734435283; x=1735040083;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=FGcCn7MS4hx/mI5jQMgSZdmLZ7w8ly50SQXxSiWuojM=;
        b=JrObzVYYt1od3x8eVJ/z7IpLBjUgR3awN+BskEnWYubxgszqqv2+TNvr3qnEhfdV5y
         L+g8bWu/L5ntabpwR7cIh68jJRElHxE5j9iBlyvKD7C7kcyqBXAbLtYLcJzE9BQ4IuvR
         hopnFtoT5OAfeu2/Q1MT3JPjlax4O8tHFG/zrCKwe31K8Hq7wE8Pdte1wDaNWxtNSMzG
         kNlOq9Ob75F4vVuBQjkZ8ElMEDKC3+VRb9R07v8TCodK01JvMvkiDVnkYC5PsjKyVea2
         vf3sj7JgAq+NnCSIaHVRP86YG49MhzSlOy+/tQNzE9mWK91Vm6u1Xg3zgdLsTHHEZNr6
         MpWw==
X-Forwarded-Encrypted: i=1; AJvYcCXUzJJJmkTn2kAubu/OazC1v2ByAwikmBUWZF8esQcZjmm4otFVrf+3lgkVvRXl6jtRP/SSpV5B8yw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwwTz6lTrqsu/7Ct6W2ZHhsBBc3L75X3TBu8z8FgJB4v/6c+/n2
	7Gjr5MkSHAVN8A4vgRiU97MqtZ8RgNYmdq0lojynkpt5l+J7XJ71WtesLKcRag==
X-Gm-Gg: ASbGncuOT67Ooy8xU13pwLIqDQYHcPL1YWgSvYynduk/7ExIaay70uyLOsN0pd3FjYT
	7qfGvxVA0yV5dAdfX2Z5k2NQY+uOhpudlr6At3xOML3EfH2I7wnGMAcJ1mR8M8d/WTHwNDUKChk
	vMSIshJzd13Mgg/lkB8TNZPOKOCKvaOOYK/774ffaGFbMI18SB1HhCdZOSuZp3/er+mHk2CEj+8
	8PQDjisj2SSHyG6LWRGCOWOLVRjCV0ubtT7IP67g7RdypoqzhP9lJ7wQheFiryv+YgKortFm2IU
	VDICx+kdIMJyVCicvAuvULvyRUIeybsDTLxSVqjXdQ==
X-Google-Smtp-Source: AGHT+IE3cVCZYJw5RP+SUQZl1V6FJus3GXx3LC7njx+bKToBK8dFlvJ0YsX6BXBg5D4OaoaZwP5SeA==
X-Received: by 2002:a05:6000:400b:b0:386:4a24:1914 with SMTP id ffacd0b85a97d-3888e0b8acemr13099063f8f.37.1734435283067;
        Tue, 17 Dec 2024 03:34:43 -0800 (PST)
Message-ID: <11d51fc8-d286-44cf-bbbf-f7a592785430@suse.com>
Date: Tue, 17 Dec 2024 12:34:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 3/5] xen: add new domctl get_changed_domain
To: Juergen Gross 
Cc: "Daniel P. Smith" ,
 Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241217111247.2204-1-jgross@suse.com>
 <20241217111247.2204-4-jgross@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: <20241217111247.2204-4-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.12.2024 12:12, Juergen Gross wrote:
> Add a new domctl sub-function to get data of a domain having changed
> state (this is needed by Xenstore).
> 
> The returned state just contains the domid, the domain unique id,
> and some flags (existing, shutdown, dying).
> 
> In order to enable Xenstore stubdom being built for multiple Xen
> versions, make this domctl stable.  For stable domctls the
> interface_version is always 0.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Jan Beulich  # non-XSM/Flask
albeit ...

> +int get_domain_state(struct xen_domctl_get_domain_state *info, struct domain *d,
> +                     domid_t *domid)
> +{
> +    unsigned int dom;
> +    int rc = -ENOENT;
> +
> +    if ( info->pad0 || info->pad1 )
> +        return -EINVAL;
> +
> +    if ( d )
> +    {
> +        set_domain_state_info(info, d);
> +
> +        return 0;
> +    }
> +
> +    /*
> +     * Only domain registered for VIRQ_DOM_EXC event is allowed to query
> +     * domains having changed state.
> +     */
> +    if ( !domain_handles_global_virq(current->domain, VIRQ_DOM_EXC) )
> +        return -EACCES;
> +
> +    spin_lock(&dom_state_changed_lock);
> +
> +    if ( dom_state_changed )
> +    {
> +        dom = find_first_bit(dom_state_changed, DOMID_MASK + 1);
> +        if ( dom < DOMID_FIRST_RESERVED )
> +        {
> +            __clear_bit(dom, dom_state_changed);
> +
> +            *domid = dom;
> +
> +            d = rcu_lock_domain_by_id(dom);
> +
> +            if ( d )
> +            {
> +                set_domain_state_info(info, d);
> +
> +                rcu_unlock_domain(d);
> +            }
> +            else
> +            {
> +                info->state = 0;
> +                info->unique_id = 0;
> +            }

... memset() may be prudent to use on the "else" path, to avoid this becoming
a pitfall if/when one of the padding fields have some meaning assigned.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 11:47:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 11:47:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858875.1271098 (Exim 4.92)
	(envelope-from )
	id 1tNW30-0004Bu-2S; Tue, 17 Dec 2024 11:47:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858875.1271098; Tue, 17 Dec 2024 11:47: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 1tNW2z-0004Bn-W4; Tue, 17 Dec 2024 11:47:29 +0000
Received: by outflank-mailman (input) for mailman id 858875;
 Tue, 17 Dec 2024 11:47: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 1tNW2y-0004Bh-Lh
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 11:47:28 +0000
Received: from fforwardh-a1-smtp.messagingengine.com
 (fforwardh-a1-smtp.messagingengine.com [103.168.172.196])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id aede9349-bc6c-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 12:47:25 +0100 (CET)
Received: from phl-compute-04.internal (phl-compute-04.phl.internal
 [10.202.2.44])
 by mailfforwardh.phl.internal (Postfix) with ESMTP id 42621292030F;
 Tue, 17 Dec 2024 06:47:24 -0500 (EST)
Received: from phl-frontend-02 ([10.202.2.161])
 by phl-compute-04.internal (MEProxy); Tue, 17 Dec 2024 06:47:24 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 17 Dec 2024 06:47:22 -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: aede9349-bc6c-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	: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=
	1734436044; x=1734522444; bh=PYMG5GFNcXN7JJ/1QU0o6xfmGVmIMv5xTQd
	rMgfmzB0=; b=emYUW2IZ8kwvUpjmejwPbcpeoq7a8APJMm5BEMnxQcMBC02dVni
	wbn0nHTwngrjs5ftQW3vabRfRHG5x1hhdQ4KMsRPt7AXKhvUJqJGu6cqpMbH+Sb4
	FIQLkcYOJYbZGZbXr+ErscjuEDhQC33v09PueIwjLvy/zOCTDVMmrV8l+twDT3cj
	gxSSimgaf2k/Q8jJxSlXoxbk2s5oWuvIn9EnWjeVQ5af8s0qhOw4N9y1PsgXSyCe
	xjBypIx8Y91kaBH+WXxUO0foQU3BqFgzW8HEJxRWTBAVpBnQhbKA0S/Wkgx+T4aH
	nMv/PYTF2CpeI/J2m0DWvcffnS0umaoXWEA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrleehgdeffecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr
    tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth
    hsucdlqddutddtmdenucfjughrpefhvfevufffkffoggfgsedtkeertdertddtnecuhfhr
    ohhmpefuvghrghhihicumfhisghrihhkuceoufgvrhhgihihpgfmihgsrhhikhesvghprg
    hmrdgtohhmqeenucggtffrrghtthgvrhhnpeffffdvieefieejhfehfeeuvdevtdehffej
    ieevhefgteetvdegudejgfdujeegvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrh
    grmhepmhgrihhlfhhrohhmpehsrghkihgssegurghrkhhsthgrrhdrshhithgvpdhnsggp
    rhgtphhtthhopedutddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepgigvnhdqug
    gvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohepshgv
    rhhgihihpghkihgsrhhikhesvghprghmrdgtohhmpdhrtghpthhtoheprghnughrvgifrd
    gtohhophgvrhefsegtihhtrhhigidrtghomhdprhgtphhtthhopegrnhhthhhonhihrdhp
    vghrrghrugesvhgrthgvshdrthgvtghhpdhrtghpthhtohepmhhitghhrghlrdhorhiivg
    hlsegrmhgurdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdp
    rhgtphhtthhopehjuhhlihgvnhesgigvnhdrohhrghdprhgtphhtthhopehrohhgvghrrd
    hprghusegtihhtrhhigidrtghomhdprhgtphhtthhopehsshhtrggsvghllhhinhhisehk
    vghrnhgvlhdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i57af8f6a:Fastmail
From: Sergiy Kibrik 
To: xen-devel@lists.xenproject.org
Cc: Sergiy Kibrik ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	"Daniel P. Smith" 
Subject: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
Date: Tue, 17 Dec 2024 13:47:19 +0200
Message-Id: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Allow to build ARM configuration with support for initializing hardware domain.
On ARM it is only possible to start hardware domain in multiboot mode, so
dom0less support is required. This is reflected by dependency on DOM0LESS_BOOT
instead of directly depending on ARM config option.

Signed-off-by: Sergiy Kibrik 
---
 xen/common/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 90268d9249..7368ca8208 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -374,7 +374,7 @@ endchoice
 config LATE_HWDOM
 	bool "Dedicated hardware domain"
 	default n
-	depends on XSM && X86
+	depends on XSM && (X86 || DOM0LESS_BOOT)
 	help
 	  Allows the creation of a dedicated hardware domain distinct from
 	  domain 0 that manages devices without needing access to other
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 11:47:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 11:47:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858879.1271110 (Exim 4.92)
	(envelope-from )
	id 1tNW3P-0004bK-BM; Tue, 17 Dec 2024 11:47:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858879.1271110; Tue, 17 Dec 2024 11: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 1tNW3P-0004bD-6y; Tue, 17 Dec 2024 11:47:55 +0000
Received: by outflank-mailman (input) for mailman id 858879;
 Tue, 17 Dec 2024 11: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 1tNW3O-0004Ze-3J
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 11:47:54 +0000
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com
 [2607:f8b0:4864:20::135])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bd9b5c1f-bc6c-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 12:47:50 +0100 (CET)
Received: by mail-il1-x135.google.com with SMTP id
 e9e14a558f8ab-3a817ee9936so17929135ab.2
 for ; Tue, 17 Dec 2024 03:47: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: bd9b5c1f-bc6c-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734436069; x=1735040869; 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=jxkqG6+sbk5sKBrS2+qvdvRHFQfIeGSH0RGpGDa8dZY=;
        b=kDjPNjXrLf4YsOIgZ/YyHmlzkJiQ27vdAnEtMbBJL4rZLOdVynOSlN/G7fSc73I5BI
         gn+rGOZSmab7x3pyt3gmKnJFPqSHzee75LNSGk1mOtONylD/r2f3qJCdooSjQFWohmWa
         qXTrSK0BAnNyktY0gs3NE1kHJFQFFL2KTfp4tM0EYN5u3wMalxa1IWm4gGUkrmJRrhjN
         zJS6MzpWXOeQD+ab9K+6bJVodYuXjIc5vB6x63gpZ7JEwx+34i1TzGd0YSKRuLI2cbXx
         cU+kKOS+gPF4FKewg01/3JEKKYVarix/jQbNAySnpvDoYI/jODFbUy8Xyh2H4KSTX1mz
         0Ffg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734436069; x=1735040869;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=jxkqG6+sbk5sKBrS2+qvdvRHFQfIeGSH0RGpGDa8dZY=;
        b=fA1HkyiM6RVjEArqD/zfPqZ2C0xd3yuyhXhfgKFd/qERYySkJE7dIYThRyaMuKjsfL
         Qz48D+NPEqgs37Ga+DxkdkRpTfvCB4oFNQGd71MiznjJM6UslVb1FDnCuGzSrM1AAnEW
         pPBIlNL7KkcTguavQE7cw2/WfOpGR0DfTsITrBDXjx/2b+mCfHtOnuxVYXrWx4zlzLzv
         niYQUVk6zXGoNzR6QnjtUIrW5j39pkuOoBfvtq1IP79s1bxC6EKpkJnT5fgtDaEMTbcZ
         j84buTXSmxVj05jskn1/oWRhBSuFmkZfBpc9ld2HFY0hPq8RaBzrhDcR6U632No2z7lC
         mjEg==
X-Forwarded-Encrypted: i=1; AJvYcCVEBzwDwmpNqzDWn88/R5PSg8arihsHF9Ze8JEz2ZS4PWew5l5Pe07MgO5b8m//v5J+EGO2Eam7OZA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwgiwFfPspRAMpRLFN5xOIOOwLstPV54OFgzH4HO6cjX4Vzio/T
	KBTbc3IB/PwB9T5B+S+WiAWQaO7e6JKjx2JWQtvFfGB1ZnN4GcaHYBesQf8JDXR5oB95ixemsWA
	ddGhIFikVDN/3oLgLWJA0EPnqu0IIobnA7uwVYg==
X-Gm-Gg: ASbGnctnqvv0HNlpgphAnNwP3tx9/I0Wjr1NzyslU9YAgUNED3LmlbpJeYHZT0+IKlZ
	O4/3wP/UEMQuYkzFPWX3nSfddGCvSthOCbuvHy7g=
X-Google-Smtp-Source: AGHT+IE4YEOQO8YPq3Y5Nu3QJ58o1w1Ezq9+apYD15YDpwwCYXmRXgVIykIPW/l++4pPj0zUDeRK/w9+e08XLvO+P4g=
X-Received: by 2002:a05:6e02:1a8b:b0:3a7:7124:bd2c with SMTP id
 e9e14a558f8ab-3affab62206mr169815225ab.19.1734436068997; Tue, 17 Dec 2024
 03:47:48 -0800 (PST)
MIME-Version: 1.0
References: <20241213162815.9196-1-carlo.nonato@minervasys.tech>
 <20241213162815.9196-2-carlo.nonato@minervasys.tech> 
 
 <00e38f79-6185-4dcb-be69-4b08fb4a81f4@suse.com> 
 <49a1b364-595e-4971-9819-f7e4beb35b05@suse.com>
In-Reply-To: <49a1b364-595e-4971-9819-f7e4beb35b05@suse.com>
From: Carlo Nonato 
Date: Tue, 17 Dec 2024 12:47:38 +0100
Message-ID: 
Subject: Re: [PATCH v12 01/12] xen/common: add cache coloring common code
To: Jan Beulich 
Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, 
	Andrew Cooper , Anthony PERARD , 
	Michal Orzel , Julien Grall , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 17, 2024 at 12:12=E2=80=AFPM Jan Beulich  wr=
ote:
>
> On 17.12.2024 11:25, Carlo Nonato wrote:
> > On Tue, Dec 17, 2024 at 9:57=E2=80=AFAM Jan Beulich =
 wrote:
> >>
> >> On 16.12.2024 17:33, Carlo Nonato wrote:
> >>> On Mon, Dec 16, 2024 at 11:51=E2=80=AFAM Jan Beulich  wrote:
> >>>> On 13.12.2024 17:28, Carlo Nonato wrote:
> >>>>> --- /dev/null
> >>>>> +++ b/xen/common/llc-coloring.c
> >>>>> @@ -0,0 +1,124 @@
> >>>>> +/* SPDX-License-Identifier: GPL-2.0-only */
> >>>>> +/*
> >>>>> + * Last Level Cache (LLC) coloring common code
> >>>>> + *
> >>>>> + * Copyright (C) 2024, Advanced Micro Devices, Inc.
> >>>>> + * Copyright (C) 2024, Minerva Systems SRL
> >>>>> + */
> >>>>> +#include 
> >>>>> +#include 
> >>>>> +#include 
> >>>>> +
> >>>>> +#define NR_LLC_COLORS          (1U << CONFIG_LLC_COLORS_ORDER)
> >>>>> +
> >>>>> +/*
> >>>>> + * -1: not specified (disabled unless llc-size and llc-nr-ways pre=
sent)
> >>>>> + *  0: explicitly disabled through cmdline
> >>>>> + *  1: explicitly enabled through cmdline
> >>>>> + */
> >>>>> +static int8_t __initdata opt_llc_coloring =3D -1;
> >>>>> +boolean_param("llc-coloring", opt_llc_coloring);
> >>>>> +
> >>>>> +static bool __ro_after_init llc_coloring_enabled;
> >>>>> +
> >>>>> +static unsigned int __initdata llc_size;
> >>>>> +size_param("llc-size", llc_size);
> >>>>> +static unsigned int __initdata llc_nr_ways;
> >>>>> +integer_param("llc-nr-ways", llc_nr_ways);
> >>>>> +/* Number of colors available in the LLC */
> >>>>> +static unsigned int __ro_after_init max_nr_colors;
> >>>>> +
> >>>>> +static void print_colors(const unsigned int colors[], unsigned int=
 num_colors)
> >>>>> +{
> >>>>> +    unsigned int i;
> >>>>> +
> >>>>> +    printk("{ ");
> >>>>> +    for ( i =3D 0; i < num_colors; i++ )
> >>>>> +    {
> >>>>> +        unsigned int start =3D colors[i], end =3D start;
> >>>>> +
> >>>>> +        printk("%u", start);
> >>>>> +
> >>>>> +        for ( ; i < num_colors - 1 && end + 1 =3D=3D colors[i + 1]=
; i++, end++ )
> >>>>> +            ;
> >>>>> +
> >>>>> +        if ( start !=3D end )
> >>>>> +            printk("-%u", end);
> >>>>> +
> >>>>> +        if ( i < num_colors - 1 )
> >>>>> +            printk(", ");
> >>>>> +    }
> >>>>> +    printk(" }\n");
> >>>>> +}
> >>>>> +
> >>>>> +void __init llc_coloring_init(void)
> >>>>> +{
> >>>>> +    unsigned int way_size;
> >>>>> +
> >>>>> +    llc_coloring_enabled =3D (opt_llc_coloring =3D=3D 1);
> >>>>
> >>>> Generally I'd suggest to only use > 0, >=3D 0, < 0, and <=3D 0 on su=
ch
> >>>> variables.
> >>>>
> >>>>> +    if ( (opt_llc_coloring !=3D 0) && llc_size && llc_nr_ways )
> >>>>> +    {
> >>>>> +        llc_coloring_enabled =3D true;
> >>>>> +        way_size =3D llc_size / llc_nr_ways;
> >>>>> +    }
> >>>>
> >>>> Hmm, I actually see a difference in someone saying
> >>>>
> >>>> "llc-coloring=3D0 llc-size=3D... llc-nr-ways=3D..."
> >>>>
> >>>> vs
> >>>>
> >>>> "llc-size=3D... llc-nr-ways=3D... llc-coloring=3D0"
> >>>>
> >>>> I'm not sure about Arm, but on x86 this can be relevant as there may=
 be
> >>>> pre-set parts of a command line with appended (human) overrides. The=
refore
> >>>> it always wants to be "last wins". Yet yes, you may weant to take th=
e
> >>>> position that in such a case the former example would require "llc-c=
oloring=3D1"
> >>>> to also be added.
> >>>
> >>> Yes, I think this should be the way to go.
> >>>
> >>>> Kind of against the shorthand llc-size+llc-nr-ways only,
> >>>> though.
> >>>
> >>> The shorthand was proposed by you here:
> >>> https://patchew.org/Xen/20240315105902.160047-1-carlo.nonato@minervas=
ys.tech/20240315105902.160047-2-carlo.nonato@minervasys.tech/#05e4d3da-4130=
-4c57-9855-43b685ce5005@suse.com
> >>>
> >>>> Wouldn't it make sense to infer "llc-coloring" when both of the latt=
er options
> >>>> were supplied?
> >>>
> >>> We both agreed that it was something good to have.
> >>
> >> Right, and I'm not putting that under question. With that, however, I =
find
> >> your reply ambiguous. If the shorthand is useful to have, is the requi=
rement
> >> to put a 2nd "llc-coloring=3D1" on a command line (as per above) reall=
y a good
> >> idea?
> >
> > I don't know an easy way to check for parameters order. We're close to =
feature
> > freeze. Isn't this solution good enough for now?
>
> Maybe it is, but then imo only when also calling out the apparent anomaly=
 in
> the command line doc. I.e. amend 'Note that using both options implies
> "llc-coloring=3Don"' by e.g. 'unless an earlier "llc-coloring=3Doff" is t=
here' (in
> both places).
>

Ok.

> Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 11:59:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 11:59:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858895.1271127 (Exim 4.92)
	(envelope-from )
	id 1tNWEf-0006wh-BZ; Tue, 17 Dec 2024 11:59:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858895.1271127; Tue, 17 Dec 2024 11:59:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNWEf-0006wa-8h; Tue, 17 Dec 2024 11:59:33 +0000
Received: by outflank-mailman (input) for mailman id 858895;
 Tue, 17 Dec 2024 11: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 1tNWEe-0006wU-4x
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 11:59:32 +0000
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com
 [2a00:1450:4864:20::52a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5f1070bc-bc6e-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 12:59:30 +0100 (CET)
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-5d3bdccba49so9061922a12.1
 for ; Tue, 17 Dec 2024 03:59:30 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d65346456fsm4182149a12.71.2024.12.17.03.59.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 03:59: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: 5f1070bc-bc6e-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734436769; x=1735041569; 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=4TK4xsKrBg7l7IKfhFhTEA2zGyreDJOlWm4cabCk6BQ=;
        b=DqpK1mhuY6xUjf/8L63mFJ/cZFMhfr3aiflv/5XHAaStJ5CP0hB6NABLnZrDCQwVqx
         gKmTJBwa91hkdKEvLkAUqd+FQoLESIkuAaHXSV71xlxcJ5OIRaabvQCjyC/RLAYn1/Of
         42DhtxgT0TRhHrxdCGY4kisiWFppJSh5WOdkvCDK6v4kKRITWb6WBVzJbUMEEiTDn8NT
         YqgVlNfl+L9y+OnLiHtR0GOERPshmEwW5p8Wy05YZwi20iiqLAT2q5fr/4ybnUp++iAt
         g6rTymZIGzmozAeej+xA7ODTyMZrTumxqr8KR0nkfQ/Jad/lu6VtYPMZCIqs2UqEUV0M
         x2Pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734436769; x=1735041569;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=4TK4xsKrBg7l7IKfhFhTEA2zGyreDJOlWm4cabCk6BQ=;
        b=f/YmWKGvdoTfqpEZCCGNfgHPFoHxGdt9GKyw3UhzAFPkm5DldpTMmCXxhu4IDMTjPw
         Om8M2wOWCr7xlJgWa3sYnOKgjR//jPhlWMsXvDPtj41MY74M+W1vRbgFjn1/stKL734b
         RHQbgkWI5VfMx9Zh0EBBFpqV01D9o9Uey58QCm5VUP3CJwvB6KsDdYYwsuwqzaWj3/jK
         yEIe72hHqHuKqNiII8sm8c+ADS3TM+4wB1RIAHB1u7kEIqSJUGPXhiJIUr/DJcX4h+uU
         x2M2KMt382CvZyBdfM8uhFznITkW/xIe0mPzrMHHKlmmK7zWNh9kSWCID2h2X1DD0QSo
         YAnQ==
X-Forwarded-Encrypted: i=1; AJvYcCX4+udVChMoMpeQ33iGoVCB37vdXjnR//h2vQtK+pBYyJM5hObGpkULLNx8Q398YaPXUXD/1Wo7xI8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzxwSApDpQm+v1FzzPBW4sRHBmYywn71CnrtAXLce2r+XcHLsCl
	6TDwxDZLLzvx+2bg/4Wbr4rVuo0Dfe7wxfHfUWdh3LOFpuT8+PyPJDxu69zZ76UYStThxa5rObX
	uKT0=
X-Gm-Gg: ASbGnctcv0NvPerVECYSClLY71jgyOjuOrysUfN5IIPWk2uh3Jg/FkrtIBmLafiQYFy
	v0WCPQl7pzduh+OtwlCsqhqZFPAt+20ubOvx4AK0EaMGcAdeP/e5hsoV0ughjj+5DtTXTA5CK3F
	2XJ1nGtH+nHpWecSInKDD/6HjR3go4+YeU6jCICPjS/wlw2PxlVcwTtUPWnV6NT6iSM9Psys303
	m1ggmUeu2TJGx4m/01acLPpDZqu6w46jE7kUy0wpKbpVRJSOzK4DdFbT0VmcSK188kiyA1NjgnS
	rEeMhlONBsZfw0loRwLO8A6TziUABeUXId4Nki5AvQfzp5JwkfcMSPOc8DlnP2KJibSldtBr73h
	9OHjQbQ==
X-Google-Smtp-Source: AGHT+IGWR78OD3BAYl6jvbazy60DXDZ0u61C7S0+bTIFvVxoz4MNRXo2ntKpHFaUXz7HhefyMNeCQQ==
X-Received: by 2002:a05:6402:3805:b0:5cf:b079:68ef with SMTP id 4fb4d7f45d1cf-5d7d40dbdf3mr2954190a12.26.1734436769354;
        Tue, 17 Dec 2024 03:59:29 -0800 (PST)
Message-ID: 
Date: Tue, 17 Dec 2024 12:59:27 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 2/5] xen: add bitmap to indicate per-domain state
 changes
To: Jan Beulich 
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: <20241217111247.2204-1-jgross@suse.com>
 <20241217111247.2204-3-jgross@suse.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: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------a3tcmIthmmlNBa0m1S4JBYwb"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------a3tcmIthmmlNBa0m1S4JBYwb
Content-Type: multipart/mixed; boundary="------------VvILjMkBX5lM01rk369AgU7j";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
Message-ID: 
Subject: Re: [PATCH v4 2/5] xen: add bitmap to indicate per-domain state
 changes
References: <20241217111247.2204-1-jgross@suse.com>
 <20241217111247.2204-3-jgross@suse.com>
 
In-Reply-To: 
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------VvILjMkBX5lM01rk369AgU7j
Content-Type: multipart/mixed; boundary="------------oh10exoWoyLLAwwSKsINQC6l"

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

T24gMTcuMTIuMjQgMTI6MzAsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxNy4xMi4yMDI0
IDEyOjEyLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gVjQ6DQo+PiAtIGFkZCBfX3JlYWRf
bW9zdGx5IChKYW4gQmV1bGljaCkNCj4+IC0gdXNlIF9fc2V0X2JpeigpIChKYW4gQmV1bGlj
aCkNCj4+IC0gZml4IGVycm9yIGhhbmRsaW5nIGluIGV2dGNobl9iaW5kX3ZpcnEoKSAoSmFu
IEJldWxpY2gpDQo+IA0KPiBJJ20gc29ycnksIEkgc2hvdWxkIGhhdmUgc3BvdHRlZCBhIDJu
ZCBpc3N1ZSBhbHJlYWR5IHdoZW4gcmV2aWV3aW5nIHYzIChvcg0KPiBldmVuIGFuIGVhcmxp
ZXIgdmVyc2lvbikuDQo+IA0KPj4gQEAgLTEzOCw2ICsxMzksNjAgQEAgYm9vbCBfX3JlYWRf
bW9zdGx5IHZtdHJhY2VfYXZhaWxhYmxlOw0KPj4gICANCj4+ICAgYm9vbCBfX3JlYWRfbW9z
dGx5IHZwbXVfaXNfYXZhaWxhYmxlOw0KPj4gICANCj4+ICtzdGF0aWMgREVGSU5FX1NQSU5M
T0NLKGRvbV9zdGF0ZV9jaGFuZ2VkX2xvY2spOw0KPj4gK3N0YXRpYyB1bnNpZ25lZCBsb25n
ICpfX3JlYWRfbW9zdGx5IGRvbV9zdGF0ZV9jaGFuZ2VkOw0KPj4gKw0KPj4gK2ludCBkb21h
aW5faW5pdF9zdGF0ZXModm9pZCkNCj4+ICt7DQo+PiArICAgIGNvbnN0IHN0cnVjdCBkb21h
aW4gKmQ7DQo+PiArICAgIGludCByYyA9IC1FTk9NRU07DQo+PiArDQo+PiArICAgIHNwaW5f
bG9jaygmZG9tX3N0YXRlX2NoYW5nZWRfbG9jayk7DQo+PiArDQo+PiArICAgIGlmICggZG9t
X3N0YXRlX2NoYW5nZWQgKQ0KPj4gKyAgICAgICAgYml0bWFwX3plcm8oZG9tX3N0YXRlX2No
YW5nZWQsIERPTUlEX0ZJUlNUX1JFU0VSVkVEKTsNCj4gDQo+IFRoaXMgbmVlZHMgdG8gbm90
IGhhcHBlbiB3aGVuIC4uLg0KPiANCj4+IEBAIC00ODUsMTEgKzQ4NiwyMSBAQCBpbnQgZXZ0
Y2huX2JpbmRfdmlycShldnRjaG5fYmluZF92aXJxX3QgKmJpbmQsIGV2dGNobl9wb3J0X3Qg
cG9ydCkNCj4+ICAgICAgIGlmICggKHYgPSBkb21haW5fdmNwdShkLCB2Y3B1KSkgPT0gTlVM
TCApDQo+PiAgICAgICAgICAgcmV0dXJuIC1FTk9FTlQ7DQo+PiAgIA0KPj4gKyAgICBpZiAo
IHZpcnEgPT0gVklSUV9ET01fRVhDICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcmMgPSBk
b21haW5faW5pdF9zdGF0ZXMoKTsNCj4+ICsgICAgICAgIGlmICggcmMgKQ0KPj4gKyAgICAg
ICAgICAgIHJldHVybiByYzsNCj4+ICsNCj4+ICsgICAgICAgIGRlaW5pdF9pZl9lcnIgPSB0
cnVlOw0KPj4gKyAgICB9DQo+PiArDQo+PiAgICAgICB3cml0ZV9sb2NrKCZkLT5ldmVudF9s
b2NrKTsNCj4+ICAgDQo+PiAgICAgICBpZiAoIHJlYWRfYXRvbWljKCZ2LT52aXJxX3RvX2V2
dGNoblt2aXJxXSkgKQ0KPj4gICAgICAgew0KPj4gICAgICAgICAgIHJjID0gLUVFWElTVDsN
Cj4+ICsgICAgICAgIGRlaW5pdF9pZl9lcnIgPSBmYWxzZTsNCj4+ICAgICAgICAgICBnZHBy
aW50ayhYRU5MT0dfV0FSTklORywgIkVWVENITk9QIGZhaWx1cmU6IGVycm9yICVkXG4iLCBy
Yyk7DQo+PiAgICAgICAgICAgZ290byBvdXQ7DQo+PiAgICAgICB9DQo+IA0KPiAuLi4gd2Ug
dGFrZSB0aGlzIGVycm9yIHBhdGguIFdoaWNoIEkgdGhpbmsgY2FsbHMgZm9yIG1vdmluZyB0
aGUNCj4gZG9tYWluX2luaXRfc3RhdGVzKCkgaW52b2NhdGlvbiAuLi4NCj4gDQo+PiBAQCAt
NTI3LDYgKzUzOCw5IEBAIGludCBldnRjaG5fYmluZF92aXJxKGV2dGNobl9iaW5kX3ZpcnFf
dCAqYmluZCwgZXZ0Y2huX3BvcnRfdCBwb3J0KQ0KPj4gICAgb3V0Og0KPj4gICAgICAgd3Jp
dGVfdW5sb2NrKCZkLT5ldmVudF9sb2NrKTsNCj4+ICAgDQo+PiArICAgIGlmICggcmMgJiYg
ZGVpbml0X2lmX2VyciApDQo+PiArICAgICAgICBkb21haW5fZGVpbml0X3N0YXRlcygpOw0K
Pj4gKw0KPj4gICAgICAgcmV0dXJuIHJjOw0KPj4gICB9DQo+IA0KPiAuLi4gc29tZXdoZXJl
IGhlcmUuIEl0IHJlYWxseSBkb2Vzbid0IG5lZWQgZG9pbmcgZWFybHksIGFzIHRoZSBjYWxs
ZXINCj4gbWF5IGFzc3VtZSB0aGUgYml0bWFwIHdhcyBzZXQgdXAgb25seSB3aGVuIHRoaXMg
aHlwZXJjYWxsIHJldHVybnMNCj4gc3VjY2Vzc2Z1bGx5Lg0KDQpPVE9IIHRoaXMgd2lsbCBy
ZXF1aXJlIHVuZG9pbmcgdGhlIGJpbmRpbmcgb2YgdGhlIHZpcnEgaW4gY2FzZSBvZiBhbg0K
ZXJyb3IgcmV0dXJuZWQgYnkgZG9tYWluX2luaXRfc3RhdGVzKCkuDQoNCkl0IHdvdWxkIHBy
b2JhYmx5IGJlIGJlc3QgdG8gcGxhY2UgdGhlIGNhbGwgb2YgZG9tYWluX2luaXRfc3RhdGVz
KCkNCmFmdGVyIHRoZSAtRUVYSVNUIGNhc2UuDQoNCg0KSnVlcmdlbg0K
--------------oh10exoWoyLLAwwSKsINQC6l
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-----

--------------oh10exoWoyLLAwwSKsINQC6l--

--------------VvILjMkBX5lM01rk369AgU7j--

--------------a3tcmIthmmlNBa0m1S4JBYwb
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/Ey8FAmdhZ6AFAwAAAAAACgkQsN6d1ii/Ey97
Wwf/Y77M4zphV+LssDNJNIr4Nf5fgQxrA/RiNJEh4g+6GY2Tyv+CpH5a7PG50Nc44rGoIbplGJiP
t1urGHoRWRZ++FbHl4KtBXf8isARGt/70nzYmDODkXG/+TWqUyC/dbaDRKfDxXeV3t7/rfwjjpwU
62jINR3oQQ5iQCWeZOeRw/lBjICfStLEYIKigA4FYc9XmrDKsmtg3m2Wnra4gVaDu+uKzZYzZIEs
wHqA/EX78v7Oerm/RBZbllF/6agKZH5B/ERfo3LZ1d0AT9O7ZaTNXUZ42boz7Kya1yu4oNiKOvgc
DtGr31NPaC+5JD485ddQWFrrQSeukPl0YLbaLrajCQ==
=a9EA
-----END PGP SIGNATURE-----

--------------a3tcmIthmmlNBa0m1S4JBYwb--


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 12:18:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 12:18:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858916.1271167 (Exim 4.92)
	(envelope-from )
	id 1tNWXN-0002wm-LE; Tue, 17 Dec 2024 12:18:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858916.1271167; Tue, 17 Dec 2024 12:18: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 1tNWXN-0002wf-Ij; Tue, 17 Dec 2024 12:18:53 +0000
Received: by outflank-mailman (input) for mailman id 858916;
 Tue, 17 Dec 2024 12:18: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 1tNWXM-0002GC-Eo
 for xen-devel@lists.xen.org; Tue, 17 Dec 2024 12:18:52 +0000
Received: from mail.xenproject.org (mail.xenproject.org [104.130.215.37])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 10800b33-bc71-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 13:18:48 +0100 (CET)
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1tNWXC-0081kR-16;
 Tue, 17 Dec 2024 12:18:42 +0000
Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.96)
 (envelope-from ) id 1tNWXC-00E24k-1b;
 Tue, 17 Dec 2024 12:18: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: 10800b33-bc71-11ef-a0d6-8be0dac302b0
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.510 (Entity 5.510)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
 xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team 
CC: Xen.org security team 
Subject: Xen Security Advisory 465 v3 (CVE-2024-53240) - Backend can crash
 Linux netfront
Message-Id: 
Date: Tue, 17 Dec 2024 12:18:42 +0000

--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

             Xen Security Advisory CVE-2024-53240 / XSA-465
                                version 3

                   Backend can crash Linux netfront

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

After a suspend/resume cycle of a Linux guest (e.g. via "virsh dompmsuspend"/
"virsh dompmwakeup") a malicious network backend can crash the guest via a
NULL-pointer dereference in the guest's xen-netfront driver.

During the resume operation the xen-netfront driver will release some data
structures used for communication with the backend, in order to reallocate
these data structures with possibly different parameters specified by the
backend. If the backend is triggering a network device removal in the
guest before any network I/O has happened, the NULL-pointer dereference
may happen, causing a crash of the guest.

IMPACT
======

In setups with non-trusted network backends (e.g. when using untrusted
network driver domains) suspend/resume cycles of guests can result in
those guests being crashed by a malicious network backend.

VULNERABLE SYSTEMS
==================

Only systems with non-trusted network backends are vulnerable.

As far as known only Linux guests with the fix for CVE-2022-48969 applied
are vulnerable (this includes all kernel versions from 6.1 onwards).

All guest types (x86 PV, x86 PVH/HVM and Arm32/Arm64) are vulnerable.

MITIGATION
==========

Not doing guest suspend/resume cycles will avoid the vulnerability.

Using emulated NICs instead of PV ones will avoid the vulnerability.

CREDITS
=======

This issue was discovered by Marek Marczykowski-Górecki of Invisible Things Lab.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa465-linux.patch     Linux

$ sha256sum xsa465*
7207a22e1e70d0b00278d90e797313bee9d72a968ddd38464b90f0612667826e  xsa465-linux.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of patches or mitigations is NOT permitted (except where
all the affected systems and VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List).  Specifically, deployment on public cloud systems
is NOT permitted.

This is because the patches need to be applied to the guests and using
emulated NICs is a guest visible configuration change.

Deployment is permitted only AFTER the embargo ends.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmdhaw0MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZ1kYH/3u0RtjvoOLf2CTFAPhBfgVXZ0nbaQAVeVY14OXL
3WAOQzrspobwSJtVUqRCg14NllEkM2ityeAlussY++b9BFW7nqxji9yL/rSMpuPh
vsH/sDByBSUYxpaw/LgbkZVvhRq3vbK6E7fnXCw8BO9LYA+uTZRf4P6PRe0JeQtz
t0IyHsECXaPoSWzX18OtSrg1JFYhgBqB9vK4rKMvMjPpqZDIKlEgIpFwNlywZ6jx
H6T3CCKUPUZqmVegxJtXIof3STEr9bzd4StPaUrRXfToOg5ZsknUkari0Nr8xW27
mcTZaFVWgWwfI0irMs9jTp2agfQ6T+yptA8ZfM3J7kGvGcc=
=+A6o
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa465-linux.patch"
Content-Disposition: attachment; filename="xsa465-linux.patch"
Content-Transfer-Encoding: base64

RnJvbSBmOTI0NGZiNTVmMzczNTZmNzVjNzM5YzU3MzIzZDk0MjJkN2FhMGY4
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKdWVyZ2VuIEdyb3Nz
IDxqZ3Jvc3NAc3VzZS5jb20+CkRhdGU6IFRodSwgNyBOb3YgMjAyNCAxNjox
NzowMCArMDEwMApTdWJqZWN0OiB4ZW4vbmV0ZnJvbnQ6IGZpeCBjcmFzaCB3
aGVuIHJlbW92aW5nIGRldmljZQpNSU1FLVZlcnNpb246IDEuMApDb250ZW50
LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9VVRGLTgKQ29udGVudC1UcmFu
c2Zlci1FbmNvZGluZzogOGJpdAoKV2hlbiByZW1vdmluZyBhIG5ldGZyb250
IGRldmljZSBkaXJlY3RseSBhZnRlciBhIHN1c3BlbmQvcmVzdW1lIGN5Y2xl
Cml0IG1pZ2h0IGhhcHBlbiB0aGF0IHRoZSBxdWV1ZXMgaGF2ZSBub3QgYmVl
biBzZXR1cCBhZ2FpbiwgY2F1c2luZyBhCmNyYXNoIGR1cmluZyB0aGUgYXR0
ZW1wdCB0byBzdG9wIHRoZSBxdWV1ZXMgYW5vdGhlciB0aW1lLgoKRml4IHRo
YXQgYnkgY2hlY2tpbmcgdGhlIHF1ZXVlcyBhcmUgZXhpc3RpbmcgYmVmb3Jl
IHRyeWluZyB0byBzdG9wCnRoZW0uCgpUaGlzIGlzIFhTQS00NjUgLyBDVkUt
MjAyNC01MzI0MC4KClJlcG9ydGVkLWJ5OiBNYXJlayBNYXJjenlrb3dza2kt
R8OzcmVja2kgPG1hcm1hcmVrQGludmlzaWJsZXRoaW5nc2xhYi5jb20+CkZp
eGVzOiBkNTBiNzkxNGZhZTAgKCJ4ZW4tbmV0ZnJvbnQ6IEZpeCBOVUxMIHNy
aW5nIGFmdGVyIGxpdmUgbWlncmF0aW9uIikKU2lnbmVkLW9mZi1ieTogSnVl
cmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPgotLS0KIGRyaXZlcnMvbmV0
L3hlbi1uZXRmcm9udC5jIHwgNSArKysrLQogMSBmaWxlIGNoYW5nZWQsIDQg
aW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQoKZGlmZiAtLWdpdCBhL2Ry
aXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jIGIvZHJpdmVycy9uZXQveGVuLW5l
dGZyb250LmMKaW5kZXggNDI2NWMxY2QwZmY3Li42M2ZlNTFkMGU2NGQgMTAw
NjQ0Ci0tLSBhL2RyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jCisrKyBiL2Ry
aXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jCkBAIC04NjcsNyArODY3LDcgQEAg
c3RhdGljIG5ldGRldl90eF90IHhlbm5ldF9zdGFydF94bWl0KHN0cnVjdCBz
a19idWZmICpza2IsIHN0cnVjdCBuZXRfZGV2aWNlICpkZXYKIHN0YXRpYyBp
bnQgeGVubmV0X2Nsb3NlKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpCiB7CiAJ
c3RydWN0IG5ldGZyb250X2luZm8gKm5wID0gbmV0ZGV2X3ByaXYoZGV2KTsK
LQl1bnNpZ25lZCBpbnQgbnVtX3F1ZXVlcyA9IGRldi0+cmVhbF9udW1fdHhf
cXVldWVzOworCXVuc2lnbmVkIGludCBudW1fcXVldWVzID0gbnAtPnF1ZXVl
cyA/IGRldi0+cmVhbF9udW1fdHhfcXVldWVzIDogMDsKIAl1bnNpZ25lZCBp
bnQgaTsKIAlzdHJ1Y3QgbmV0ZnJvbnRfcXVldWUgKnF1ZXVlOwogCW5ldGlm
X3R4X3N0b3BfYWxsX3F1ZXVlcyhucC0+bmV0ZGV2KTsKQEAgLTg4Miw2ICs4
ODIsOSBAQCBzdGF0aWMgdm9pZCB4ZW5uZXRfZGVzdHJveV9xdWV1ZXMoc3Ry
dWN0IG5ldGZyb250X2luZm8gKmluZm8pCiB7CiAJdW5zaWduZWQgaW50IGk7
CiAKKwlpZiAoIWluZm8tPnF1ZXVlcykKKwkJcmV0dXJuOworCiAJZm9yIChp
ID0gMDsgaSA8IGluZm8tPm5ldGRldi0+cmVhbF9udW1fdHhfcXVldWVzOyBp
KyspIHsKIAkJc3RydWN0IG5ldGZyb250X3F1ZXVlICpxdWV1ZSA9ICZpbmZv
LT5xdWV1ZXNbaV07CiAKLS0gCjIuNDMuMAoK

--=separator--


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 12:18:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 12:18:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.858918.1271184 (Exim 4.92)
	(envelope-from )
	id 1tNWXQ-0003Ev-A8; Tue, 17 Dec 2024 12:18:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 858918.1271184; Tue, 17 Dec 2024 12:18: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 1tNWXQ-0003EC-1v; Tue, 17 Dec 2024 12:18:56 +0000
Received: by outflank-mailman (input) for mailman id 858918;
 Tue, 17 Dec 2024 12:18: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 1tNWXO-0002GC-F9
 for xen-devel@lists.xen.org; Tue, 17 Dec 2024 12:18:54 +0000
Received: from mail.xenproject.org (mail.xenproject.org [104.130.215.37])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1324b242-bc71-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 13:18:51 +0100 (CET)
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1tNWXG-0081kk-23;
 Tue, 17 Dec 2024 12:18:46 +0000
Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.96)
 (envelope-from ) id 1tNWXG-00E268-2p;
 Tue, 17 Dec 2024 12:18: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: 1324b242-bc71-11ef-a0d6-8be0dac302b0
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.510 (Entity 5.510)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
 xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team 
CC: Xen.org security team 
Subject: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
Message-Id: 
Date: Tue, 17 Dec 2024 12:18:46 +0000

--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

             Xen Security Advisory CVE-2024-53241 / XSA-466
                                version 3

         Xen hypercall page unsafe against speculative attacks

UPDATES IN VERSION 3
====================

Update of patch 5, public release.

ISSUE DESCRIPTION
=================

Xen guests need to use different processor instructions to make explicit
calls into the Xen hypervisor depending on guest type and/or CPU
vendor. In order to hide those differences, the hypervisor can fill a
hypercall page with the needed instruction sequences, allowing the guest
operating system to call into the hypercall page instead of having to
choose the correct instructions.

The hypercall page contains whole functions, which are written by the
hypervisor and executed by the guest. With the lack of an interface
between the guest OS and the hypervisor specifying how a potential
modification of those functions should look like, the Xen hypervisor has
no knowledge how any potential mitigation should look like or which
hardening features should be put into place.

This results in potential vulnerabilities if the guest OS is using any
speculative mitigation that performs a compiler transform on "ret"
instructions in order to work (e.g. the Linux kernel rethunk or safe-ret
mitigations).

Furthermore, the hypercall page has no provision for Control-flow
Integrity schemes (e.g. kCFI/CET-IBT/FineIBT), and will simply
malfunction in such configurations.

IMPACT
======

Some mitigations for hardware vulnerabilities the guest OS is relying on to
work might not be fully functional, resulting in e.g. guest user processes
being able to read data they ought not have access to.

VULNERABLE SYSTEMS
==================

Only x86 systems are potentially vulnerable, Arm systems are not vulnerable.

All guest types (PV, PVH and HVM) are potentially vulnerable.

Linux guests are known to be vulnerable, guests using other operating
systems might be vulnerable, too.

MITIGATION
==========

Running only Linux guest kernels not relying on "ret" assembler instruction
patching (kernel config option CONFIG_MITIGATION_RETHUNK/CONFIG_RETHUNK
disabled) will avoid the vulnerability, as long as this option isn't
required to be safe on the underlying hardware.

CREDITS
=======

This issue was discovered by Andrew Cooper of XenServer.

RESOLUTION
==========

Applying the set of attached patches resolves this issue.

The patch to Xen is simply a documentation update to clarify that an OS author
might not want to use a hypercall page.

xsa466-linux-*.patch    Linux
xsa466-xen.patch        xen-unstable

$ sha256sum xsa466*
498fb2538f650d694bbd6b7d2333dcf9a12d0bdfcba65257a7d14c88f5b86801  xsa466-linux-01.patch
1e0d5f68d1cb4a0ef8914ae6bdeb4e18bae94c6d19659708ad707da784c0aa5c  xsa466-linux-02.patch
b3056b34c1565f901cb4ba11c03a51d4f045b5de7cd16c6e510e0bcee8cc6cd7  xsa466-linux-03.patch
0215e56739ab5b0d0ec0125f3d1806c3a0a0dcb3f562014f59b5145184a41467  xsa466-linux-04.patch
314e67060ab4f47883cf2b124d54ce3cd4b0363f0545ad907a7b754a4405aacd  xsa466-linux-05.patch
adbef75416379d96ebb72463872f993e9d8b7d119091480ad1e70fd448481733  xsa466-linux-06.patch
36874014cee5d5213610a6ffdd0e3e67d0258d28f2587b8470fdd0cef96e5013  xsa466-linux-07.patch
367f981ef8adc11b99cc6999b784305bcdcd55db0358fd6a2171509bf7f64345  xsa466-xen.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of patches or mitigations is NOT permitted (except where
all the affected systems and VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List).  Specifically, deployment on public cloud systems
is NOT permitted.

This is because the mitigation or patches need to be applied to the guests.

Deployment is permitted only AFTER the embargo ends.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmdhaxAMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZUeMH/0Qkn9G8iQWJ0fHMCxvd1lcr3RNWK5GfXqlAZvuJ
YRQMDslYCzuvzrkLnoe/P/zSSs+omEYMcOVsJCBkTqePs8yIdqwBvBfZ79I1htIu
IdyJt8SE5+b70ZlumQJ8ef1Za3lp8bxvEZVa8GIokOu0Ef1iqUKNl7tQgIoQjOUH
bV/1sFN5MNFsUshOW5DnLiRrE8j0/0nfbzHPu5H9S2B4eN38oPmTabvZG/IHky8R
VFyTvqFrKZONDDhdxyFE9PBOtP6Bu3EV+Emmxb3Q84l2oEIqgab0Xxj4QGBTuLMn
PPcU5/D6Giqx3jBMdrkMAXtBuXBYO/inqsX1IJLic9W13+A=
=wlOW
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa466-linux-01.patch"
Content-Disposition: attachment; filename="xsa466-linux-01.patch"
Content-Transfer-Encoding: base64

RnJvbSBlZmJjZDYxZDliZWJiNzcxYzgzNmEzYjhiZmNlZDgxNjU2MzNkYjdj
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKdWVyZ2VuIEdyb3Nz
IDxqZ3Jvc3NAc3VzZS5jb20+CkRhdGU6IFRodSwgMTcgT2N0IDIwMjQgMDg6
Mjk6NDggKzAyMDAKU3ViamVjdDogeDg2OiBtYWtlIGdldF9jcHVfdmVuZG9y
KCkgYWNjZXNzaWJsZSBmcm9tIFhlbiBjb2RlCgpJbiBvcmRlciB0byBiZSBh
YmxlIHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiBBTUQgYW5kIEludGVsIGJh
c2VkCnN5c3RlbXMgZm9yIHZlcnkgZWFybHkgaHlwZXJjYWxscyB3aXRob3V0
IGhhdmluZyB0byByZWx5IG9uIHRoZSBYZW4KaHlwZXJjYWxsIHBhZ2UsIG1h
a2UgZ2V0X2NwdV92ZW5kb3IoKSBub24tc3RhdGljLgoKUmVmYWN0b3IgZWFy
bHlfY3B1X2luaXQoKSBmb3IgdGhlIHNhbWUgcmVhc29uIGJ5IHNwbGl0dGlu
ZyBvdXQgdGhlCmxvb3AgaW5pdGlhbGl6aW5nIGNwdV9kZXZzKCkgaW50byBh
biBleHRlcm5hbGx5IGNhbGxhYmxlIGZ1bmN0aW9uLgoKVGhpcyBpcyBwYXJ0
IG9mIFhTQS00NjYgLyBDVkUtMjAyNC01MzI0MS4KClJlcG9ydGVkLWJ5OiBB
bmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpTaWdu
ZWQtb2ZmLWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+Ci0t
LQogYXJjaC94ODYvaW5jbHVkZS9hc20vcHJvY2Vzc29yLmggfCAgMiArKwog
YXJjaC94ODYva2VybmVsL2NwdS9jb21tb24uYyAgICAgfCAzOCArKysrKysr
KysrKysrKysrKystLS0tLS0tLS0tLS0tLQogMiBmaWxlcyBjaGFuZ2VkLCAy
NCBpbnNlcnRpb25zKCspLCAxNiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQg
YS9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9wcm9jZXNzb3IuaCBiL2FyY2gveDg2
L2luY2x1ZGUvYXNtL3Byb2Nlc3Nvci5oCmluZGV4IGMwOTc1ODE1OTgwYy4u
MjBlNjAwOTM4MWVkIDEwMDY0NAotLS0gYS9hcmNoL3g4Ni9pbmNsdWRlL2Fz
bS9wcm9jZXNzb3IuaAorKysgYi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9wcm9j
ZXNzb3IuaApAQCAtMjMwLDYgKzIzMCw4IEBAIHN0YXRpYyBpbmxpbmUgdW5z
aWduZWQgbG9uZyBsb25nIGwxdGZfcGZuX2xpbWl0KHZvaWQpCiAJcmV0dXJu
IEJJVF9VTEwoYm9vdF9jcHVfZGF0YS54ODZfY2FjaGVfYml0cyAtIDEgLSBQ
QUdFX1NISUZUKTsKIH0KIAordm9pZCBpbml0X2NwdV9kZXZzKHZvaWQpOwor
dm9pZCBnZXRfY3B1X3ZlbmRvcihzdHJ1Y3QgY3B1aW5mb194ODYgKmMpOwog
ZXh0ZXJuIHZvaWQgZWFybHlfY3B1X2luaXQodm9pZCk7CiBleHRlcm4gdm9p
ZCBpZGVudGlmeV9zZWNvbmRhcnlfY3B1KHN0cnVjdCBjcHVpbmZvX3g4NiAq
KTsKIGV4dGVybiB2b2lkIHByaW50X2NwdV9pbmZvKHN0cnVjdCBjcHVpbmZv
X3g4NiAqKTsKZGlmZiAtLWdpdCBhL2FyY2gveDg2L2tlcm5lbC9jcHUvY29t
bW9uLmMgYi9hcmNoL3g4Ni9rZXJuZWwvY3B1L2NvbW1vbi5jCmluZGV4IGE1
YzI4OTc1YzYwOC4uM2U5MDM3NjkwODE0IDEwMDY0NAotLS0gYS9hcmNoL3g4
Ni9rZXJuZWwvY3B1L2NvbW1vbi5jCisrKyBiL2FyY2gveDg2L2tlcm5lbC9j
cHUvY29tbW9uLmMKQEAgLTg2Nyw3ICs4NjcsNyBAQCBzdGF0aWMgdm9pZCBj
cHVfZGV0ZWN0X3RsYihzdHJ1Y3QgY3B1aW5mb194ODYgKmMpCiAJCXRsYl9s
bGRfNG1bRU5UUklFU10sIHRsYl9sbGRfMWdbRU5UUklFU10pOwogfQogCi1z
dGF0aWMgdm9pZCBnZXRfY3B1X3ZlbmRvcihzdHJ1Y3QgY3B1aW5mb194ODYg
KmMpCit2b2lkIGdldF9jcHVfdmVuZG9yKHN0cnVjdCBjcHVpbmZvX3g4NiAq
YykKIHsKIAljaGFyICp2ID0gYy0+eDg2X3ZlbmRvcl9pZDsKIAlpbnQgaTsK
QEAgLTE2NDksMTUgKzE2NDksMTEgQEAgc3RhdGljIHZvaWQgX19pbml0IGVh
cmx5X2lkZW50aWZ5X2NwdShzdHJ1Y3QgY3B1aW5mb194ODYgKmMpCiAJZGV0
ZWN0X25vcGwoKTsKIH0KIAotdm9pZCBfX2luaXQgZWFybHlfY3B1X2luaXQo
dm9pZCkKK3ZvaWQgX19pbml0IGluaXRfY3B1X2RldnModm9pZCkKIHsKIAlj
b25zdCBzdHJ1Y3QgY3B1X2RldiAqY29uc3QgKmNkZXY7CiAJaW50IGNvdW50
ID0gMDsKIAotI2lmZGVmIENPTkZJR19QUk9DRVNTT1JfU0VMRUNUCi0JcHJf
aW5mbygiS0VSTkVMIHN1cHBvcnRlZCBjcHVzOlxuIik7Ci0jZW5kaWYKLQog
CWZvciAoY2RldiA9IF9feDg2X2NwdV9kZXZfc3RhcnQ7IGNkZXYgPCBfX3g4
Nl9jcHVfZGV2X2VuZDsgY2RldisrKSB7CiAJCWNvbnN0IHN0cnVjdCBjcHVf
ZGV2ICpjcHVkZXYgPSAqY2RldjsKIApAQCAtMTY2NSwyMCArMTY2MSwzMCBA
QCB2b2lkIF9faW5pdCBlYXJseV9jcHVfaW5pdCh2b2lkKQogCQkJYnJlYWs7
CiAJCWNwdV9kZXZzW2NvdW50XSA9IGNwdWRldjsKIAkJY291bnQrKzsKKwl9
Cit9CiAKK3ZvaWQgX19pbml0IGVhcmx5X2NwdV9pbml0KHZvaWQpCit7CiAj
aWZkZWYgQ09ORklHX1BST0NFU1NPUl9TRUxFQ1QKLQkJewotCQkJdW5zaWdu
ZWQgaW50IGo7Ci0KLQkJCWZvciAoaiA9IDA7IGogPCAyOyBqKyspIHsKLQkJ
CQlpZiAoIWNwdWRldi0+Y19pZGVudFtqXSkKLQkJCQkJY29udGludWU7Ci0J
CQkJcHJfaW5mbygiICAlcyAlc1xuIiwgY3B1ZGV2LT5jX3ZlbmRvciwKLQkJ
CQkJY3B1ZGV2LT5jX2lkZW50W2pdKTsKLQkJCX0KLQkJfQorCXVuc2lnbmVk
IGludCBpLCBqOworCisJcHJfaW5mbygiS0VSTkVMIHN1cHBvcnRlZCBjcHVz
OlxuIik7CiAjZW5kaWYKKworCWluaXRfY3B1X2RldnMoKTsKKworI2lmZGVm
IENPTkZJR19QUk9DRVNTT1JfU0VMRUNUCisJZm9yIChpID0gMDsgaSA8IFg4
Nl9WRU5ET1JfTlVNICYmIGNwdV9kZXZzW2ldOyBpKyspIHsKKwkJZm9yIChq
ID0gMDsgaiA8IDI7IGorKykgeworCQkJaWYgKCFjcHVfZGV2c1tpXS0+Y19p
ZGVudFtqXSkKKwkJCQljb250aW51ZTsKKwkJCXByX2luZm8oIiAgJXMgJXNc
biIsIGNwdV9kZXZzW2ldLT5jX3ZlbmRvciwKKwkJCQljcHVfZGV2c1tpXS0+
Y19pZGVudFtqXSk7CisJCX0KIAl9CisjZW5kaWYKKwogCWVhcmx5X2lkZW50
aWZ5X2NwdSgmYm9vdF9jcHVfZGF0YSk7CiB9CiAKLS0gCjIuNDMuMAoK

--=separator
Content-Type: application/octet-stream; name="xsa466-linux-02.patch"
Content-Disposition: attachment; filename="xsa466-linux-02.patch"
Content-Transfer-Encoding: base64

RnJvbSBkZGEwMTRiYTU5MzMxZGVlNGYzYjc3M2EwMjBlMTA5OTMyZjRiZDI0
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKdWVyZ2VuIEdyb3Nz
IDxqZ3Jvc3NAc3VzZS5jb20+CkRhdGU6IEZyaSwgMjkgTm92IDIwMjQgMTU6
NDc6NDkgKzAxMDAKU3ViamVjdDogb2JqdG9vbC94ODY6IGFsbG93IHN5c2Nh
bGwgaW5zdHJ1Y3Rpb24KClRoZSBzeXNjYWxsIGluc3RydWN0aW9uIGlzIHVz
ZWQgaW4gWGVuIFBWIG1vZGUgZm9yIGRvaW5nIGh5cGVyY2FsbHMuCkFsbG93
IHN5c2NhbGwgdG8gYmUgdXNlZCBpbiB0aGUga2VybmVsIGluIGNhc2UgaXQg
aXMgdGFnZ2VkIHdpdGggYW4KdW53aW5kIGhpbnQgZm9yIG9ianRvb2wuCgpU
aGlzIGlzIHBhcnQgb2YgWFNBLTQ2NiAvIENWRS0yMDI0LTUzMjQxLgoKUmVw
b3J0ZWQtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJp
eC5jb20+ClNpZ25lZC1vZmYtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0Bz
dXNlLmNvbT4KQ28tZGV2ZWxvcGVkLWJ5OiBQZXRlciBaaWpsc3RyYSA8cGV0
ZXJ6QGluZnJhZGVhZC5vcmc+Ci0tLQogdG9vbHMvb2JqdG9vbC9jaGVjay5j
IHwgOSArKysrKystLS0KIDEgZmlsZSBjaGFuZ2VkLCA2IGluc2VydGlvbnMo
KyksIDMgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvdG9vbHMvb2JqdG9v
bC9jaGVjay5jIGIvdG9vbHMvb2JqdG9vbC9jaGVjay5jCmluZGV4IDRjZTE3
NmFkNDExZi4uNzYwNjBkYTc1NWI1IDEwMDY0NAotLS0gYS90b29scy9vYmp0
b29sL2NoZWNrLmMKKysrIGIvdG9vbHMvb2JqdG9vbC9jaGVjay5jCkBAIC0z
ODIwLDkgKzM4MjAsMTIgQEAgc3RhdGljIGludCB2YWxpZGF0ZV9icmFuY2go
c3RydWN0IG9ianRvb2xfZmlsZSAqZmlsZSwgc3RydWN0IHN5bWJvbCAqZnVu
YywKIAkJCWJyZWFrOwogCiAJCWNhc2UgSU5TTl9DT05URVhUX1NXSVRDSDoK
LQkJCWlmIChmdW5jICYmICghbmV4dF9pbnNuIHx8ICFuZXh0X2luc24tPmhp
bnQpKSB7Ci0JCQkJV0FSTl9JTlNOKGluc24sICJ1bnN1cHBvcnRlZCBpbnN0
cnVjdGlvbiBpbiBjYWxsYWJsZSBmdW5jdGlvbiIpOwotCQkJCXJldHVybiAx
OworCQkJaWYgKGZ1bmMpIHsKKwkJCQlpZiAoIW5leHRfaW5zbiB8fCAhbmV4
dF9pbnNuLT5oaW50KSB7CisJCQkJCVdBUk5fSU5TTihpbnNuLCAidW5zdXBw
b3J0ZWQgaW5zdHJ1Y3Rpb24gaW4gY2FsbGFibGUgZnVuY3Rpb24iKTsKKwkJ
CQkJcmV0dXJuIDE7CisJCQkJfQorCQkJCWJyZWFrOwogCQkJfQogCQkJcmV0
dXJuIDA7CiAKLS0gCjIuNDMuMAoK

--=separator
Content-Type: application/octet-stream; name="xsa466-linux-03.patch"
Content-Disposition: attachment; filename="xsa466-linux-03.patch"
Content-Transfer-Encoding: base64

RnJvbSAwZWY4MDQ3YjczN2Q3NDgwYTVkNGM0NmQ5NTZlOTdjMTkwZjEzMDUw
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKdWVyZ2VuIEdyb3Nz
IDxqZ3Jvc3NAc3VzZS5jb20+CkRhdGU6IEZyaSwgMjkgTm92IDIwMjQgMTY6
MTU6NTQgKzAxMDAKU3ViamVjdDogeDg2L3N0YXRpYy1jYWxsOiBwcm92aWRl
IGEgd2F5IHRvIGRvIHZlcnkgZWFybHkKIHN0YXRpYy1jYWxsIHVwZGF0ZXMK
CkFkZCBzdGF0aWNfY2FsbF91cGRhdGVfZWFybHkoKSBmb3IgdXBkYXRpbmcg
c3RhdGljLWNhbGwgdGFyZ2V0cyBpbgp2ZXJ5IGVhcmx5IGJvb3QuCgpUaGlz
IHdpbGwgYmUgbmVlZGVkIGZvciBzdXBwb3J0IG9mIFhlbiBndWVzdCB0eXBl
IHNwZWNpZmljIGh5cGVyY2FsbApmdW5jdGlvbnMuCgpUaGlzIGlzIHBhcnQg
b2YgWFNBLTQ2NiAvIENWRS0yMDI0LTUzMjQxLgoKUmVwb3J0ZWQtYnk6IEFu
ZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClNpZ25l
ZC1vZmYtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4KQ28t
ZGV2ZWxvcGVkLWJ5OiBQZXRlciBaaWpsc3RyYSA8cGV0ZXJ6QGluZnJhZGVh
ZC5vcmc+CkNvLWRldmVsb3BlZC1ieTogSm9zaCBQb2ltYm9ldWYgPGpwb2lt
Ym9lQHJlZGhhdC5jb20+Ci0tLQogYXJjaC94ODYvaW5jbHVkZS9hc20vc3Rh
dGljX2NhbGwuaCB8IDE1ICsrKysrKysrKysrKwogYXJjaC94ODYvaW5jbHVk
ZS9hc20vc3luY19jb3JlLmggICB8ICA2ICsrLS0tCiBhcmNoL3g4Ni9rZXJu
ZWwvc3RhdGljX2NhbGwuYyAgICAgIHwgIDkgKysrKysrKysKIGluY2x1ZGUv
bGludXgvY29tcGlsZXIuaCAgICAgICAgICAgfCAzNyArKysrKysrKysrKysr
KysrKysrKystLS0tLS0tLS0KIGluY2x1ZGUvbGludXgvc3RhdGljX2NhbGwu
aCAgICAgICAgfCAgMSArCiBrZXJuZWwvc3RhdGljX2NhbGxfaW5saW5lLmMg
ICAgICAgIHwgIDIgKy0KIDYgZmlsZXMgY2hhbmdlZCwgNTUgaW5zZXJ0aW9u
cygrKSwgMTUgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvYXJjaC94ODYv
aW5jbHVkZS9hc20vc3RhdGljX2NhbGwuaCBiL2FyY2gveDg2L2luY2x1ZGUv
YXNtL3N0YXRpY19jYWxsLmgKaW5kZXggMTI1YzQwN2UyYWJlLi40MTUwMmJk
MmFmZDYgMTAwNjQ0Ci0tLSBhL2FyY2gveDg2L2luY2x1ZGUvYXNtL3N0YXRp
Y19jYWxsLmgKKysrIGIvYXJjaC94ODYvaW5jbHVkZS9hc20vc3RhdGljX2Nh
bGwuaApAQCAtNjUsNCArNjUsMTkgQEAKIAogZXh0ZXJuIGJvb2wgX19zdGF0
aWNfY2FsbF9maXh1cCh2b2lkICp0cmFtcCwgdTggb3AsIHZvaWQgKmRlc3Qp
OwogCitleHRlcm4gdm9pZCBfX3N0YXRpY19jYWxsX3VwZGF0ZV9lYXJseSh2
b2lkICp0cmFtcCwgdm9pZCAqZnVuYyk7CisKKyNkZWZpbmUgc3RhdGljX2Nh
bGxfdXBkYXRlX2Vhcmx5KG5hbWUsIF9mdW5jKQkJCQlcCisoewkJCQkJCQkJ
CVwKKwl0eXBlb2YoJlNUQVRJQ19DQUxMX1RSQU1QKG5hbWUpKSBfX0YgPSAo
X2Z1bmMpOwkJCVwKKwlpZiAoc3RhdGljX2NhbGxfaW5pdGlhbGl6ZWQpIHsJ
CQkJCVwKKwkJX19zdGF0aWNfY2FsbF91cGRhdGUoJlNUQVRJQ19DQUxMX0tF
WShuYW1lKSwJCVwKKwkJCQkgICAgIFNUQVRJQ19DQUxMX1RSQU1QX0FERFIo
bmFtZSksIF9fRik7XAorCX0gZWxzZSB7CQkJCQkJCVwKKwkJV1JJVEVfT05D
RShTVEFUSUNfQ0FMTF9LRVkobmFtZSkuZnVuYywgX2Z1bmMpOwkJXAorCQlf
X3N0YXRpY19jYWxsX3VwZGF0ZV9lYXJseShTVEFUSUNfQ0FMTF9UUkFNUF9B
RERSKG5hbWUpLFwKKwkJCQkJICAgX19GKTsJCQlcCisJfQkJCQkJCQkJXAor
fSkKKwogI2VuZGlmIC8qIF9BU01fU1RBVElDX0NBTExfSCAqLwpkaWZmIC0t
Z2l0IGEvYXJjaC94ODYvaW5jbHVkZS9hc20vc3luY19jb3JlLmggYi9hcmNo
L3g4Ni9pbmNsdWRlL2FzbS9zeW5jX2NvcmUuaAppbmRleCBhYjczODJmOTJh
ZmYuLjk2YmRhNDM1MzhlZSAxMDA2NDQKLS0tIGEvYXJjaC94ODYvaW5jbHVk
ZS9hc20vc3luY19jb3JlLmgKKysrIGIvYXJjaC94ODYvaW5jbHVkZS9hc20v
c3luY19jb3JlLmgKQEAgLTgsNyArOCw3IEBACiAjaW5jbHVkZSA8YXNtL3Nw
ZWNpYWxfaW5zbnMuaD4KIAogI2lmZGVmIENPTkZJR19YODZfMzIKLXN0YXRp
YyBpbmxpbmUgdm9pZCBpcmV0X3RvX3NlbGYodm9pZCkKK3N0YXRpYyBfX2Fs
d2F5c19pbmxpbmUgdm9pZCBpcmV0X3RvX3NlbGYodm9pZCkKIHsKIAlhc20g
dm9sYXRpbGUgKAogCQkicHVzaGZsXG5cdCIKQEAgLTE5LDcgKzE5LDcgQEAg
c3RhdGljIGlubGluZSB2b2lkIGlyZXRfdG9fc2VsZih2b2lkKQogCQk6IEFT
TV9DQUxMX0NPTlNUUkFJTlQgOiA6ICJtZW1vcnkiKTsKIH0KICNlbHNlCi1z
dGF0aWMgaW5saW5lIHZvaWQgaXJldF90b19zZWxmKHZvaWQpCitzdGF0aWMg
X19hbHdheXNfaW5saW5lIHZvaWQgaXJldF90b19zZWxmKHZvaWQpCiB7CiAJ
dW5zaWduZWQgaW50IHRtcDsKIApAQCAtNTUsNyArNTUsNyBAQCBzdGF0aWMg
aW5saW5lIHZvaWQgaXJldF90b19zZWxmKHZvaWQpCiAgKiBMaWtlIGFsbCBv
ZiBMaW51eCdzIG1lbW9yeSBvcmRlcmluZyBvcGVyYXRpb25zLCB0aGlzIGlz
IGEKICAqIGNvbXBpbGVyIGJhcnJpZXIgYXMgd2VsbC4KICAqLwotc3RhdGlj
IGlubGluZSB2b2lkIHN5bmNfY29yZSh2b2lkKQorc3RhdGljIF9fYWx3YXlz
X2lubGluZSB2b2lkIHN5bmNfY29yZSh2b2lkKQogewogCS8qCiAJICogVGhl
IFNFUklBTElaRSBpbnN0cnVjdGlvbiBpcyB0aGUgbW9zdCBzdHJhaWdodGZv
cndhcmQgd2F5IHRvCmRpZmYgLS1naXQgYS9hcmNoL3g4Ni9rZXJuZWwvc3Rh
dGljX2NhbGwuYyBiL2FyY2gveDg2L2tlcm5lbC9zdGF0aWNfY2FsbC5jCmlu
ZGV4IDRlZWZhYWM2NGM2Yy4uOWVlZDBjMTQ0ZGFkIDEwMDY0NAotLS0gYS9h
cmNoL3g4Ni9rZXJuZWwvc3RhdGljX2NhbGwuYworKysgYi9hcmNoL3g4Ni9r
ZXJuZWwvc3RhdGljX2NhbGwuYwpAQCAtMTcyLDYgKzE3MiwxNSBAQCB2b2lk
IGFyY2hfc3RhdGljX2NhbGxfdHJhbnNmb3JtKHZvaWQgKnNpdGUsIHZvaWQg
KnRyYW1wLCB2b2lkICpmdW5jLCBib29sIHRhaWwpCiB9CiBFWFBPUlRfU1lN
Qk9MX0dQTChhcmNoX3N0YXRpY19jYWxsX3RyYW5zZm9ybSk7CiAKK25vaW5z
dHIgdm9pZCBfX3N0YXRpY19jYWxsX3VwZGF0ZV9lYXJseSh2b2lkICp0cmFt
cCwgdm9pZCAqZnVuYykKK3sKKwlCVUdfT04oc3lzdGVtX3N0YXRlICE9IFNZ
U1RFTV9CT09USU5HKTsKKwlCVUdfT04oIWVhcmx5X2Jvb3RfaXJxc19kaXNh
YmxlZCk7CisJQlVHX09OKHN0YXRpY19jYWxsX2luaXRpYWxpemVkKTsKKwlf
X3RleHRfZ2VuX2luc24odHJhbXAsIEpNUDMyX0lOU05fT1BDT0RFLCB0cmFt
cCwgZnVuYywgSk1QMzJfSU5TTl9TSVpFKTsKKwlzeW5jX2NvcmUoKTsKK30K
KwogI2lmZGVmIENPTkZJR19NSVRJR0FUSU9OX1JFVEhVTksKIC8qCiAgKiBU
aGlzIGlzIGNhbGxlZCBieSBhcHBseV9yZXR1cm5zKCkgdG8gZml4IHVwIHN0
YXRpYyBjYWxsIHRyYW1wb2xpbmVzLApkaWZmIC0tZ2l0IGEvaW5jbHVkZS9s
aW51eC9jb21waWxlci5oIGIvaW5jbHVkZS9saW51eC9jb21waWxlci5oCmlu
ZGV4IDQ2OWE2NGRkNjQ5NS4uMjQwYzYzMmM1Yjk1IDEwMDY0NAotLS0gYS9p
bmNsdWRlL2xpbnV4L2NvbXBpbGVyLmgKKysrIGIvaW5jbHVkZS9saW51eC9j
b21waWxlci5oCkBAIC0yMTYsMjggKzIxNiw0MyBAQCB2b2lkIGZ0cmFjZV9s
aWtlbHlfdXBkYXRlKHN0cnVjdCBmdHJhY2VfbGlrZWx5X2RhdGEgKmYsIGlu
dCB2YWwsCiAKICNlbmRpZiAvKiBfX0tFUk5FTF9fICovCiAKKy8qKgorICog
b2Zmc2V0X3RvX3B0ciAtIGNvbnZlcnQgYSByZWxhdGl2ZSBtZW1vcnkgb2Zm
c2V0IHRvIGFuIGFic29sdXRlIHBvaW50ZXIKKyAqIEBvZmY6CXRoZSBhZGRy
ZXNzIG9mIHRoZSAzMi1iaXQgb2Zmc2V0IHZhbHVlCisgKi8KK3N0YXRpYyBp
bmxpbmUgdm9pZCAqb2Zmc2V0X3RvX3B0cihjb25zdCBpbnQgKm9mZikKK3sK
KwlyZXR1cm4gKHZvaWQgKikoKHVuc2lnbmVkIGxvbmcpb2ZmICsgKm9mZik7
Cit9CisKKyNlbmRpZiAvKiBfX0FTU0VNQkxZX18gKi8KKworI2lmZGVmIENP
TkZJR182NEJJVAorI2RlZmluZSBBUkNIX1NFTChhLGIpIGEKKyNlbHNlCisj
ZGVmaW5lIEFSQ0hfU0VMKGEsYikgYgorI2VuZGlmCisKIC8qCiAgKiBGb3Jj
ZSB0aGUgY29tcGlsZXIgdG8gZW1pdCAnc3ltJyBhcyBhIHN5bWJvbCwgc28g
dGhhdCB3ZSBjYW4gcmVmZXJlbmNlCiAgKiBpdCBmcm9tIGlubGluZSBhc3Nl
bWJsZXIuIE5lY2Vzc2FyeSBpbiBjYXNlICdzeW0nIGNvdWxkIGJlIGlubGlu
ZWQKICAqIG90aGVyd2lzZSwgb3IgZWxpbWluYXRlZCBlbnRpcmVseSBkdWUg
dG8gbGFjayBvZiByZWZlcmVuY2VzIHRoYXQgYXJlCiAgKiB2aXNpYmxlIHRv
IHRoZSBjb21waWxlci4KICAqLwotI2RlZmluZSBfX19BRERSRVNTQUJMRShz
eW0sIF9fYXR0cnMpIFwKLQlzdGF0aWMgdm9pZCAqIF9fdXNlZCBfX2F0dHJz
IFwKKyNkZWZpbmUgX19fQUREUkVTU0FCTEUoc3ltLCBfX2F0dHJzKQkJCQkJ
CVwKKwlzdGF0aWMgdm9pZCAqIF9fdXNlZCBfX2F0dHJzCQkJCQkJXAogCV9f
VU5JUVVFX0lEKF9fUEFTVEUoX19hZGRyZXNzYWJsZV8sc3ltKSkgPSAodm9p
ZCAqKSh1aW50cHRyX3QpJnN5bTsKKwogI2RlZmluZSBfX0FERFJFU1NBQkxF
KHN5bSkgXAogCV9fX0FERFJFU1NBQkxFKHN5bSwgX19zZWN0aW9uKCIuZGlz
Y2FyZC5hZGRyZXNzYWJsZSIpKQogCi0vKioKLSAqIG9mZnNldF90b19wdHIg
LSBjb252ZXJ0IGEgcmVsYXRpdmUgbWVtb3J5IG9mZnNldCB0byBhbiBhYnNv
bHV0ZSBwb2ludGVyCi0gKiBAb2ZmOgl0aGUgYWRkcmVzcyBvZiB0aGUgMzIt
Yml0IG9mZnNldCB2YWx1ZQotICovCi1zdGF0aWMgaW5saW5lIHZvaWQgKm9m
ZnNldF90b19wdHIoY29uc3QgaW50ICpvZmYpCi17Ci0JcmV0dXJuICh2b2lk
ICopKCh1bnNpZ25lZCBsb25nKW9mZiArICpvZmYpOwotfQorI2RlZmluZSBf
X0FERFJFU1NBQkxFX0FTTShzeW0pCQkJCQkJXAorCS5wdXNoc2VjdGlvbiAu
ZGlzY2FyZC5hZGRyZXNzYWJsZSwiYXciOwkJCQlcCisJLmFsaWduIEFSQ0hf
U0VMKDgsNCk7CQkJCQkJXAorCUFSQ0hfU0VMKC5xdWFkLCAubG9uZykgX19z
dHJpbmdpZnkoc3ltKTsJCQlcCisJLnBvcHNlY3Rpb247CiAKLSNlbmRpZiAv
KiBfX0FTU0VNQkxZX18gKi8KKyNkZWZpbmUgX19BRERSRVNTQUJMRV9BU01f
U1RSKHN5bSkgX19zdHJpbmdpZnkoX19BRERSRVNTQUJMRV9BU00oc3ltKSkK
IAogI2lmZGVmIF9fQ0hFQ0tFUl9fCiAjZGVmaW5lIF9fQlVJTERfQlVHX09O
X1pFUk9fTVNHKGUsIG1zZykgKDApCmRpZmYgLS1naXQgYS9pbmNsdWRlL2xp
bnV4L3N0YXRpY19jYWxsLmggYi9pbmNsdWRlL2xpbnV4L3N0YXRpY19jYWxs
LmgKaW5kZXggMTQxZTZiMTc2YTFiLi43ODU5ODBhZjg5NzIgMTAwNjQ0Ci0t
LSBhL2luY2x1ZGUvbGludXgvc3RhdGljX2NhbGwuaAorKysgYi9pbmNsdWRl
L2xpbnV4L3N0YXRpY19jYWxsLmgKQEAgLTEzOCw2ICsxMzgsNyBAQAogI2lm
ZGVmIENPTkZJR19IQVZFX1NUQVRJQ19DQUxMCiAjaW5jbHVkZSA8YXNtL3N0
YXRpY19jYWxsLmg+CiAKK2V4dGVybiBpbnQgc3RhdGljX2NhbGxfaW5pdGlh
bGl6ZWQ7CiAvKgogICogRWl0aGVyIEBzaXRlIG9yIEB0cmFtcCBjYW4gYmUg
TlVMTC4KICAqLwpkaWZmIC0tZ2l0IGEva2VybmVsL3N0YXRpY19jYWxsX2lu
bGluZS5jIGIva2VybmVsL3N0YXRpY19jYWxsX2lubGluZS5jCmluZGV4IDUy
NTljZGE0ODZkMC4uYmI3ZDA2NmE3YzM5IDEwMDY0NAotLS0gYS9rZXJuZWwv
c3RhdGljX2NhbGxfaW5saW5lLmMKKysrIGIva2VybmVsL3N0YXRpY19jYWxs
X2lubGluZS5jCkBAIC0xNSw3ICsxNSw3IEBAIGV4dGVybiBzdHJ1Y3Qgc3Rh
dGljX2NhbGxfc2l0ZSBfX3N0YXJ0X3N0YXRpY19jYWxsX3NpdGVzW10sCiBl
eHRlcm4gc3RydWN0IHN0YXRpY19jYWxsX3RyYW1wX2tleSBfX3N0YXJ0X3N0
YXRpY19jYWxsX3RyYW1wX2tleVtdLAogCQkJCSAgICBfX3N0b3Bfc3RhdGlj
X2NhbGxfdHJhbXBfa2V5W107CiAKLXN0YXRpYyBpbnQgc3RhdGljX2NhbGxf
aW5pdGlhbGl6ZWQ7CitpbnQgc3RhdGljX2NhbGxfaW5pdGlhbGl6ZWQ7CiAK
IC8qCiAgKiBNdXN0IGJlIGNhbGxlZCBiZWZvcmUgZWFybHlfaW5pdGNhbGwo
KSB0byBiZSBlZmZlY3RpdmUuCi0tIAoyLjQzLjAKCg==

--=separator
Content-Type: application/octet-stream; name="xsa466-linux-04.patch"
Content-Disposition: attachment; filename="xsa466-linux-04.patch"
Content-Transfer-Encoding: base64

RnJvbSBhMjc5NmRmZjYyZDZjNmJmYzVmYmViZGYyYmVlMGQ1YWMwNDM4OTA2
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKdWVyZ2VuIEdyb3Nz
IDxqZ3Jvc3NAc3VzZS5jb20+CkRhdGU6IFdlZCwgMTYgT2N0IDIwMjQgMTA6
NDA6MjYgKzAyMDAKU3ViamVjdDogeDg2L3hlbjogZG9uJ3QgZG8gUFYgaXJl
dCBoeXBlcmNhbGwgdGhyb3VnaCBoeXBlcmNhbGwKIHBhZ2UKCkluc3RlYWQg
b2YganVtcGluZyB0byB0aGUgWGVuIGh5cGVyY2FsbCBwYWdlIGZvciBkb2lu
ZyB0aGUgaXJldApoeXBlcmNhbGwsIGRpcmVjdGx5IGNvZGUgdGhlIHJlcXVp
cmVkIHNlcXVlbmNlIGluIHhlbi1hc20uUy4KClRoaXMgaXMgZG9uZSBpbiBw
cmVwYXJhdGlvbiBvZiBubyBsb25nZXIgdXNpbmcgaHlwZXJjYWxsIHBhZ2Ug
YXQgYWxsLAphcyBpdCBoYXMgc2hvd24gdG8gY2F1c2UgcHJvYmxlbXMgd2l0
aCBzcGVjdWxhdGlvbiBtaXRpZ2F0aW9ucy4KClRoaXMgaXMgcGFydCBvZiBY
U0EtNDY2IC8gQ1ZFLTIwMjQtNTMyNDEuCgpSZXBvcnRlZC1ieTogQW5kcmV3
IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KU2lnbmVkLW9m
Zi1ieTogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPgpSZXZpZXdl
ZC1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgotLS0KIGFy
Y2gveDg2L3hlbi94ZW4tYXNtLlMgfCAyNyArKysrKysrKysrKysrKysrKyst
LS0tLS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCAxOCBpbnNlcnRpb25zKCspLCA5
IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2FyY2gveDg2L3hlbi94ZW4t
YXNtLlMgYi9hcmNoL3g4Ni94ZW4veGVuLWFzbS5TCmluZGV4IDgzMTg5Y2Y1
Y2RjZS4uY2E2ZWRmZTRjMTRiIDEwMDY0NAotLS0gYS9hcmNoL3g4Ni94ZW4v
eGVuLWFzbS5TCisrKyBiL2FyY2gveDg2L3hlbi94ZW4tYXNtLlMKQEAgLTE3
Niw3ICsxNzYsNiBAQCBTWU1fQ09ERV9TVEFSVCh4ZW5fZWFybHlfaWR0X2hh
bmRsZXJfYXJyYXkpCiBTWU1fQ09ERV9FTkQoeGVuX2Vhcmx5X2lkdF9oYW5k
bGVyX2FycmF5KQogCV9fRklOSVQKIAotaHlwZXJjYWxsX2lyZXQgPSBoeXBl
cmNhbGxfcGFnZSArIF9fSFlQRVJWSVNPUl9pcmV0ICogMzIKIC8qCiAgKiBY
ZW42NCBpcmV0IGZyYW1lOgogICoKQEAgLTE4NiwxNyArMTg1LDI4IEBAIGh5
cGVyY2FsbF9pcmV0ID0gaHlwZXJjYWxsX3BhZ2UgKyBfX0hZUEVSVklTT1Jf
aXJldCAqIDMyCiAgKgljcwogICoJcmlwCQk8LS0gc3RhbmRhcmQgaXJldCBm
cmFtZQogICoKLSAqCWZsYWdzCisgKglmbGFncwkJPC0tIHhlbl9pcmV0IG11
c3QgcHVzaCBmcm9tIGhlcmUgb24KICAqCi0gKglyY3gJCX0KLSAqCXIxMQkJ
fTwtLSBwdXNoZWQgYnkgaHlwZXJjYWxsIHBhZ2UKLSAqIHJzcC0+cmF4CQl9
CisgKglyY3gKKyAqCXIxMQorICogcnNwLT5yYXgKICAqLworLm1hY3JvIHhl
bl9oeXBlcmNhbGxfaXJldAorCXB1c2hxICQwCS8qIEZsYWdzICovCisJcHVz
aCAlcmN4CisJcHVzaCAlcjExCisJcHVzaCAlcmF4CisJbW92ICAkX19IWVBF
UlZJU09SX2lyZXQsICVlYXgKKwlzeXNjYWxsCQkvKiBEbyB0aGUgSVJFVC4g
Ki8KKyNpZmRlZiBDT05GSUdfTUlUSUdBVElPTl9TTFMKKwlpbnQzCisjZW5k
aWYKKy5lbmRtCisKIFNZTV9DT0RFX1NUQVJUKHhlbl9pcmV0KQogCVVOV0lO
RF9ISU5UX1VOREVGSU5FRAogCUFOTk9UQVRFX05PRU5EQlIKLQlwdXNocSAk
MAotCWptcCBoeXBlcmNhbGxfaXJldAorCXhlbl9oeXBlcmNhbGxfaXJldAog
U1lNX0NPREVfRU5EKHhlbl9pcmV0KQogCiAvKgpAQCAtMzAxLDggKzMxMSw3
IEBAIFNZTV9DT0RFX1NUQVJUKHhlbl9lbnRyeV9TWVNFTlRFUl9jb21wYXQp
CiAJRU5EQlIKIAlsZWEgMTYoJXJzcCksICVyc3AJLyogc3RyaXAgJXJjeCwg
JXIxMSAqLwogCW1vdiAkLUVOT1NZUywgJXJheAotCXB1c2hxICQwCi0Jam1w
IGh5cGVyY2FsbF9pcmV0CisJeGVuX2h5cGVyY2FsbF9pcmV0CiBTWU1fQ09E
RV9FTkQoeGVuX2VudHJ5X1NZU0VOVEVSX2NvbXBhdCkKIFNZTV9DT0RFX0VO
RCh4ZW5fZW50cnlfU1lTQ0FMTF9jb21wYXQpCiAKLS0gCjIuNDMuMAoK

--=separator
Content-Type: application/octet-stream; name="xsa466-linux-05.patch"
Content-Disposition: attachment; filename="xsa466-linux-05.patch"
Content-Transfer-Encoding: base64

RnJvbSBiNDg0NWJiNjM4MzgyMWE5NTE2Y2UzMGFmM2EyN2RjODczZTM3ZmQ0
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKdWVyZ2VuIEdyb3Nz
IDxqZ3Jvc3NAc3VzZS5jb20+CkRhdGU6IFRodSwgMTcgT2N0IDIwMjQgMTE6
MDA6NTIgKzAyMDAKU3ViamVjdDogeDg2L3hlbjogYWRkIGNlbnRyYWwgaHlw
ZXJjYWxsIGZ1bmN0aW9ucwoKQWRkIGdlbmVyaWMgaHlwZXJjYWxsIGZ1bmN0
aW9ucyB1c2FibGUgZm9yIGFsbCBub3JtYWwgKGkuZS4gbm90IGlyZXQpCmh5
cGVyY2FsbHMuIERlcGVuZGluZyBvbiB0aGUgZ3Vlc3QgdHlwZSBhbmQgdGhl
IHByb2Nlc3NvciB2ZW5kb3IKZGlmZmVyZW50IGZ1bmN0aW9ucyBuZWVkIHRv
IGJlIHVzZWQgZHVlIHRvIHRoZSB0byBiZSB1c2VkIGluc3RydWN0aW9uCmZv
ciBlbnRlcmluZyB0aGUgaHlwZXJ2aXNvcjoKCi0gUFYgZ3Vlc3RzIG5lZWQg
dG8gdXNlIHN5c2NhbGwKLSBIVk0vUFZIIGd1ZXN0cyBvbiBJbnRlbCBuZWVk
IHRvIHVzZSB2bWNhbGwKLSBIVk0vUFZIIGd1ZXN0cyBvbiBBTUQgYW5kIEh5
Z29uIG5lZWQgdG8gdXNlIHZtbWNhbGwKCkFzIFBWSCBndWVzdHMgbmVlZCB0
byBpc3N1ZSBoeXBlcmNhbGxzIHZlcnkgZWFybHkgZHVyaW5nIGJvb3QsIHRo
ZXJlCmlzIGEgNHRoIGh5cGVyY2FsbCBmdW5jdGlvbiBuZWVkZWQgZm9yIEhW
TS9QVkggd2hpY2ggY2FuIGJlIHVzZWQgb24KSW50ZWwgYW5kIEFNRCBwcm9j
ZXNzb3JzLiBJdCB3aWxsIGNoZWNrIHRoZSB2ZW5kb3IgdHlwZSBhbmQgdGhl
biBzZXQKdGhlIEludGVsIG9yIEFNRCBzcGVjaWZpYyBmdW5jdGlvbiB0byB1
c2UgdmlhIHN0YXRpY19jYWxsKCkuCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTQ2
NiAvIENWRS0yMDI0LTUzMjQxLgoKUmVwb3J0ZWQtYnk6IEFuZHJldyBDb29w
ZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClNpZ25lZC1vZmYtYnk6
IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4KQ28tZGV2ZWxvcGVk
LWJ5OiBQZXRlciBaaWpsc3RyYSA8cGV0ZXJ6QGluZnJhZGVhZC5vcmc+Ci0t
LQogYXJjaC94ODYvaW5jbHVkZS9hc20veGVuL2h5cGVyY2FsbC5oIHwgIDMg
KwogYXJjaC94ODYveGVuL2VubGlnaHRlbi5jICAgICAgICAgICAgIHwgNjUg
KysrKysrKysrKysrKysrKysrKysrKwogYXJjaC94ODYveGVuL2VubGlnaHRl
bl9odm0uYyAgICAgICAgIHwgIDQgKysKIGFyY2gveDg2L3hlbi9lbmxpZ2h0
ZW5fcHYuYyAgICAgICAgICB8ICA0ICstCiBhcmNoL3g4Ni94ZW4veGVuLWFz
bS5TICAgICAgICAgICAgICAgfCAyMyArKysrKysrKwogYXJjaC94ODYveGVu
L3hlbi1oZWFkLlMgICAgICAgICAgICAgIHwgODMgKysrKysrKysrKysrKysr
KysrKysrKysrKysrKwogYXJjaC94ODYveGVuL3hlbi1vcHMuaCAgICAgICAg
ICAgICAgIHwgIDkgKysrCiA3IGZpbGVzIGNoYW5nZWQsIDE5MCBpbnNlcnRp
b25zKCspLCAxIGRlbGV0aW9uKC0pCgpkaWZmIC0tZ2l0IGEvYXJjaC94ODYv
aW5jbHVkZS9hc20veGVuL2h5cGVyY2FsbC5oIGIvYXJjaC94ODYvaW5jbHVk
ZS9hc20veGVuL2h5cGVyY2FsbC5oCmluZGV4IGEyZGQyNDk0N2ViOC4uNmI0
ZGQ0ZGUwOGE2IDEwMDY0NAotLS0gYS9hcmNoL3g4Ni9pbmNsdWRlL2FzbS94
ZW4vaHlwZXJjYWxsLmgKKysrIGIvYXJjaC94ODYvaW5jbHVkZS9hc20veGVu
L2h5cGVyY2FsbC5oCkBAIC04OCw2ICs4OCw5IEBAIHN0cnVjdCB4ZW5fZG1f
b3BfYnVmOwogCiBleHRlcm4gc3RydWN0IHsgY2hhciBfZW50cnlbMzJdOyB9
IGh5cGVyY2FsbF9wYWdlW107CiAKK3ZvaWQgeGVuX2h5cGVyY2FsbF9mdW5j
KHZvaWQpOworREVDTEFSRV9TVEFUSUNfQ0FMTCh4ZW5faHlwZXJjYWxsLCB4
ZW5faHlwZXJjYWxsX2Z1bmMpOworCiAjZGVmaW5lIF9fSFlQRVJDQUxMCQki
Y2FsbCBoeXBlcmNhbGxfcGFnZSslY1tvZmZzZXRdIgogI2RlZmluZSBfX0hZ
UEVSQ0FMTF9FTlRSWSh4KQkJCQkJCVwKIAlbb2Zmc2V0XSAiaSIgKF9fSFlQ
RVJWSVNPUl8jI3ggKiBzaXplb2YoaHlwZXJjYWxsX3BhZ2VbMF0pKQpkaWZm
IC0tZ2l0IGEvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jIGIvYXJjaC94ODYv
eGVuL2VubGlnaHRlbi5jCmluZGV4IDg0ZTVhZGJkMDkyNS4uMTg4NzQzNWFm
MmZiIDEwMDY0NAotLS0gYS9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMKKysr
IGIvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jCkBAIC0yLDYgKzIsNyBAQAog
CiAjaW5jbHVkZSA8bGludXgvY29uc29sZS5oPgogI2luY2x1ZGUgPGxpbnV4
L2NwdS5oPgorI2luY2x1ZGUgPGxpbnV4L2luc3RydW1lbnRhdGlvbi5oPgog
I2luY2x1ZGUgPGxpbnV4L2tleGVjLmg+CiAjaW5jbHVkZSA8bGludXgvbWVt
YmxvY2suaD4KICNpbmNsdWRlIDxsaW51eC9zbGFiLmg+CkBAIC0yMyw2ICsy
NCw5IEBACiAKIEVYUE9SVF9TWU1CT0xfR1BMKGh5cGVyY2FsbF9wYWdlKTsK
IAorREVGSU5FX1NUQVRJQ19DQUxMKHhlbl9oeXBlcmNhbGwsIHhlbl9oeXBl
cmNhbGxfaHZtKTsKK0VYUE9SVF9TVEFUSUNfQ0FMTF9UUkFNUCh4ZW5faHlw
ZXJjYWxsKTsKKwogLyoKICAqIFBvaW50ZXIgdG8gdGhlIHhlbl92Y3B1X2lu
Zm8gc3RydWN0dXJlIG9yCiAgKiAmSFlQRVJWSVNPUl9zaGFyZWRfaW5mby0+
dmNwdV9pbmZvW2NwdV0uIFNlZSB4ZW5faHZtX2luaXRfc2hhcmVkX2luZm8K
QEAgLTY4LDYgKzcyLDY3IEBAIEVYUE9SVF9TWU1CT0woeGVuX3N0YXJ0X2Zs
YWdzKTsKICAqLwogc3RydWN0IHNoYXJlZF9pbmZvICpIWVBFUlZJU09SX3No
YXJlZF9pbmZvID0gJnhlbl9kdW1teV9zaGFyZWRfaW5mbzsKIAorc3RhdGlj
IF9fcmVmIHZvaWQgeGVuX2dldF92ZW5kb3Iodm9pZCkKK3sKKwlpbml0X2Nw
dV9kZXZzKCk7CisJY3B1X2RldGVjdCgmYm9vdF9jcHVfZGF0YSk7CisJZ2V0
X2NwdV92ZW5kb3IoJmJvb3RfY3B1X2RhdGEpOworfQorCit2b2lkIHhlbl9o
eXBlcmNhbGxfc2V0ZnVuYyh2b2lkKQoreworCWlmIChzdGF0aWNfY2FsbF9x
dWVyeSh4ZW5faHlwZXJjYWxsKSAhPSB4ZW5faHlwZXJjYWxsX2h2bSkKKwkJ
cmV0dXJuOworCisJaWYgKChib290X2NwdV9kYXRhLng4Nl92ZW5kb3IgPT0g
WDg2X1ZFTkRPUl9BTUQgfHwKKwkgICAgIGJvb3RfY3B1X2RhdGEueDg2X3Zl
bmRvciA9PSBYODZfVkVORE9SX0hZR09OKSkKKwkJc3RhdGljX2NhbGxfdXBk
YXRlKHhlbl9oeXBlcmNhbGwsIHhlbl9oeXBlcmNhbGxfYW1kKTsKKwllbHNl
CisJCXN0YXRpY19jYWxsX3VwZGF0ZSh4ZW5faHlwZXJjYWxsLCB4ZW5faHlw
ZXJjYWxsX2ludGVsKTsKK30KKworLyoKKyAqIEV2YWx1YXRlIHByb2Nlc3Nv
ciB2ZW5kb3IgaW4gb3JkZXIgdG8gc2VsZWN0IHRoZSBjb3JyZWN0IGh5cGVy
Y2FsbAorICogZnVuY3Rpb24gZm9yIEhWTS9QVkggZ3Vlc3RzLgorICogTWln
aHQgYmUgY2FsbGVkIHZlcnkgZWFybHkgaW4gYm9vdCBiZWZvcmUgdmVuZG9y
IGhhcyBiZWVuIHNldCBieQorICogZWFybHlfY3B1X2luaXQoKS4KKyAqLwor
bm9pbnN0ciB2b2lkICpfX3hlbl9oeXBlcmNhbGxfc2V0ZnVuYyh2b2lkKQor
eworCXZvaWQgKCpmdW5jKSh2b2lkKTsKKworCS8qCisJICogWGVuIGlzIHN1
cHBvcnRlZCBvbmx5IG9uIENQVXMgd2l0aCBDUFVJRCwgc28gdGVzdGluZyBm
b3IKKwkgKiBYODZfRkVBVFVSRV9DUFVJRCBpcyBhIHRlc3QgZm9yIGVhcmx5
X2NwdV9pbml0KCkgaGF2aW5nIGJlZW4KKwkgKiBydW4uCisJICoKKwkgKiBO
b3RlIHRoYXQgX194ZW5faHlwZXJjYWxsX3NldGZ1bmMoKSBpcyBub2luc3Ry
IG9ubHkgZHVlIHRvIGEgbmFzdHkKKwkgKiBkZXBlbmRlbmN5IGNoYWluOiBp
dCBpcyBiZWluZyBjYWxsZWQgdmlhIHRoZSB4ZW5faHlwZXJjYWxsIHN0YXRp
YworCSAqIGNhbGwgd2hlbiBydW5uaW5nIGFzIGEgUFZIIG9yIEhWTSBndWVz
dC4gSHlwZXJjYWxscyBuZWVkIHRvIGJlCisJICogbm9pbnN0ciBkdWUgdG8g
UFYgZ3Vlc3RzIHVzaW5nIGh5cGVyY2FsbHMgaW4gbm9pbnN0ciBjb2RlLiBT
byB3ZQorCSAqIGNhbiBzYWZlbHkgdGFnIHRoZSBmdW5jdGlvbiBib2R5IGFz
ICJpbnN0cnVtZW50YXRpb24gb2siLCBzaW5jZQorCSAqIHRoZSBQViBndWVz
dCByZXF1aXJlbWVudCBpcyBub3Qgb2YgaW50ZXJlc3QgaGVyZSAoeGVuX2dl
dF92ZW5kb3IoKQorCSAqIGNhbGxzIG5vaW5zdHIgZnVuY3Rpb25zLCBhbmQg
c3RhdGljX2NhbGxfdXBkYXRlX2Vhcmx5KCkgbWlnaHQgZG8KKwkgKiBzbywg
dG9vKS4KKwkgKi8KKwlpbnN0cnVtZW50YXRpb25fYmVnaW4oKTsKKworCWlm
ICghYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX0NQVUlEKSkKKwkJeGVuX2dl
dF92ZW5kb3IoKTsKKworCWlmICgoYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9y
ID09IFg4Nl9WRU5ET1JfQU1EIHx8CisJICAgICBib290X2NwdV9kYXRhLng4
Nl92ZW5kb3IgPT0gWDg2X1ZFTkRPUl9IWUdPTikpCisJCWZ1bmMgPSB4ZW5f
aHlwZXJjYWxsX2FtZDsKKwllbHNlCisJCWZ1bmMgPSB4ZW5faHlwZXJjYWxs
X2ludGVsOworCisJc3RhdGljX2NhbGxfdXBkYXRlX2Vhcmx5KHhlbl9oeXBl
cmNhbGwsIGZ1bmMpOworCisJaW5zdHJ1bWVudGF0aW9uX2VuZCgpOworCisJ
cmV0dXJuIGZ1bmM7Cit9CisKIHN0YXRpYyBpbnQgeGVuX2NwdV91cF9vbmxp
bmUodW5zaWduZWQgaW50IGNwdSkKIHsKIAl4ZW5faW5pdF9sb2NrX2NwdShj
cHUpOwpkaWZmIC0tZ2l0IGEvYXJjaC94ODYveGVuL2VubGlnaHRlbl9odm0u
YyBiL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW5faHZtLmMKaW5kZXggMjRkMjk1
N2E0NzI2Li45NzNhNzRmYzk2NmEgMTAwNjQ0Ci0tLSBhL2FyY2gveDg2L3hl
bi9lbmxpZ2h0ZW5faHZtLmMKKysrIGIvYXJjaC94ODYveGVuL2VubGlnaHRl
bl9odm0uYwpAQCAtMzAwLDYgKzMwMCwxMCBAQCBzdGF0aWMgdWludDMyX3Qg
X19pbml0IHhlbl9wbGF0Zm9ybV9odm0odm9pZCkKIAlpZiAoeGVuX3B2X2Rv
bWFpbigpKQogCQlyZXR1cm4gMDsKIAorCS8qIFNldCBjb3JyZWN0IGh5cGVy
Y2FsbCBmdW5jdGlvbi4gKi8KKwlpZiAoeGVuX2RvbWFpbikKKwkJeGVuX2h5
cGVyY2FsbF9zZXRmdW5jKCk7CisKIAlpZiAoeGVuX3B2aF9kb21haW4oKSAm
JiBub3B2KSB7CiAJCS8qIEd1ZXN0IGJvb3RpbmcgdmlhIHRoZSBYZW4tUFZI
IGJvb3QgZW50cnkgZ29lcyBoZXJlICovCiAJCXByX2luZm8oIlwibm9wdlwi
IHBhcmFtZXRlciBpcyBpZ25vcmVkIGluIFBWSCBndWVzdFxuIik7CmRpZmYg
LS1naXQgYS9hcmNoL3g4Ni94ZW4vZW5saWdodGVuX3B2LmMgYi9hcmNoL3g4
Ni94ZW4vZW5saWdodGVuX3B2LmMKaW5kZXggZDY4MThjNmNhZmRhLi5hOGVi
N2UwYzQ3M2MgMTAwNjQ0Ci0tLSBhL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW5f
cHYuYworKysgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuX3B2LmMKQEAgLTEz
NDEsNiArMTM0MSw5IEBAIGFzbWxpbmthZ2UgX192aXNpYmxlIHZvaWQgX19p
bml0IHhlbl9zdGFydF9rZXJuZWwoc3RydWN0IHN0YXJ0X2luZm8gKnNpKQog
CiAJeGVuX2RvbWFpbl90eXBlID0gWEVOX1BWX0RPTUFJTjsKIAl4ZW5fc3Rh
cnRfZmxhZ3MgPSB4ZW5fc3RhcnRfaW5mby0+ZmxhZ3M7CisJLyogSW50ZXJy
dXB0cyBhcmUgZ3VhcmFudGVlZCB0byBiZSBvZmYgaW5pdGlhbGx5LiAqLwor
CWVhcmx5X2Jvb3RfaXJxc19kaXNhYmxlZCA9IHRydWU7CisJc3RhdGljX2Nh
bGxfdXBkYXRlX2Vhcmx5KHhlbl9oeXBlcmNhbGwsIHhlbl9oeXBlcmNhbGxf
cHYpOwogCiAJeGVuX3NldHVwX2ZlYXR1cmVzKCk7CiAKQEAgLTE0MzEsNyAr
MTQzNCw2IEBAIGFzbWxpbmthZ2UgX192aXNpYmxlIHZvaWQgX19pbml0IHhl
bl9zdGFydF9rZXJuZWwoc3RydWN0IHN0YXJ0X2luZm8gKnNpKQogCVdBUk5f
T04oeGVuX2NwdWhwX3NldHVwKHhlbl9jcHVfdXBfcHJlcGFyZV9wdiwgeGVu
X2NwdV9kZWFkX3B2KSk7CiAKIAlsb2NhbF9pcnFfZGlzYWJsZSgpOwotCWVh
cmx5X2Jvb3RfaXJxc19kaXNhYmxlZCA9IHRydWU7CiAKIAl4ZW5fcmF3X2Nv
bnNvbGVfd3JpdGUoIm1hcHBpbmcga2VybmVsIGludG8gcGh5c2ljYWwgbWVt
b3J5XG4iKTsKIAl4ZW5fc2V0dXBfa2VybmVsX3BhZ2V0YWJsZSgocGdkX3Qg
Kil4ZW5fc3RhcnRfaW5mby0+cHRfYmFzZSwKZGlmZiAtLWdpdCBhL2FyY2gv
eDg2L3hlbi94ZW4tYXNtLlMgYi9hcmNoL3g4Ni94ZW4veGVuLWFzbS5TCmlu
ZGV4IGNhNmVkZmU0YzE0Yi4uYjUxOGYzNmQxY2EyIDEwMDY0NAotLS0gYS9h
cmNoL3g4Ni94ZW4veGVuLWFzbS5TCisrKyBiL2FyY2gveDg2L3hlbi94ZW4t
YXNtLlMKQEAgLTIwLDkgKzIwLDMyIEBACiAKICNpbmNsdWRlIDxsaW51eC9p
bml0Lmg+CiAjaW5jbHVkZSA8bGludXgvbGlua2FnZS5oPgorI2luY2x1ZGUg
PGxpbnV4L29ianRvb2wuaD4KICNpbmNsdWRlIDwuLi9lbnRyeS9jYWxsaW5n
Lmg+CiAKIC5wdXNoc2VjdGlvbiAubm9pbnN0ci50ZXh0LCAiYXgiCisvKgor
ICogUFYgaHlwZXJjYWxsIGludGVyZmFjZSB0byB0aGUgaHlwZXJ2aXNvci4K
KyAqCisgKiBDYWxsZWQgdmlhIGlubGluZSBhc20oKSwgc28gYmV0dGVyIHBy
ZXNlcnZlICVyY3ggYW5kICVyMTEuCisgKgorICogSW5wdXQ6CisgKgklZWF4
OiBoeXBlcmNhbGwgbnVtYmVyCisgKgklcmRpLCAlcnNpLCAlcmR4LCAlcjEw
LCAlcjg6IGFyZ3MgMS4uNSBmb3IgdGhlIGh5cGVyY2FsbAorICogT3V0cHV0
OiAlcmF4CisgKi8KK1NZTV9GVU5DX1NUQVJUKHhlbl9oeXBlcmNhbGxfcHYp
CisJQU5OT1RBVEVfTk9FTkRCUgorCXB1c2ggJXJjeAorCXB1c2ggJXIxMQor
CVVOV0lORF9ISU5UX1NBVkUKKwlzeXNjYWxsCisJVU5XSU5EX0hJTlRfUkVT
VE9SRQorCXBvcCAlcjExCisJcG9wICVyY3gKKwlSRVQKK1NZTV9GVU5DX0VO
RCh4ZW5faHlwZXJjYWxsX3B2KQorCiAvKgogICogRGlzYWJsaW5nIGV2ZW50
cyBpcyBzaW1wbHkgYSBtYXR0ZXIgb2YgbWFraW5nIHRoZSBldmVudCBtYXNr
CiAgKiBub24temVyby4KZGlmZiAtLWdpdCBhL2FyY2gveDg2L3hlbi94ZW4t
aGVhZC5TIGIvYXJjaC94ODYveGVuL3hlbi1oZWFkLlMKaW5kZXggN2Y2YzY5
ZGJiODE2Li5jMTczYmE2NzQwZTkgMTAwNjQ0Ci0tLSBhL2FyY2gveDg2L3hl
bi94ZW4taGVhZC5TCisrKyBiL2FyY2gveDg2L3hlbi94ZW4taGVhZC5TCkBA
IC02LDkgKzYsMTEgQEAKIAogI2luY2x1ZGUgPGxpbnV4L2VsZm5vdGUuaD4K
ICNpbmNsdWRlIDxsaW51eC9pbml0Lmg+CisjaW5jbHVkZSA8bGludXgvaW5z
dHJ1bWVudGF0aW9uLmg+CiAKICNpbmNsdWRlIDxhc20vYm9vdC5oPgogI2lu
Y2x1ZGUgPGFzbS9hc20uaD4KKyNpbmNsdWRlIDxhc20vZnJhbWUuaD4KICNp
bmNsdWRlIDxhc20vbXNyLmg+CiAjaW5jbHVkZSA8YXNtL3BhZ2VfdHlwZXMu
aD4KICNpbmNsdWRlIDxhc20vcGVyY3B1Lmg+CkBAIC04Nyw2ICs4OSw4NyBA
QCBTWU1fQ09ERV9FTkQoeGVuX2NwdV9icmluZ3VwX2FnYWluKQogI2VuZGlm
CiAjZW5kaWYKIAorCS5wdXNoc2VjdGlvbiAubm9pbnN0ci50ZXh0LCAiYXgi
CisvKgorICogWGVuIGh5cGVyY2FsbCBpbnRlcmZhY2UgdG8gdGhlIGh5cGVy
dmlzb3IuCisgKgorICogSW5wdXQ6CisgKiAgICAgJWVheDogaHlwZXJjYWxs
IG51bWJlcgorICogICAzMi1iaXQ6CisgKiAgICAgJWVieCwgJWVjeCwgJWVk
eCwgJWVzaSwgJWVkaTogYXJncyAxLi41IGZvciB0aGUgaHlwZXJjYWxsCisg
KiAgIDY0LWJpdDoKKyAqICAgICAlcmRpLCAlcnNpLCAlcmR4LCAlcjEwLCAl
cjg6IGFyZ3MgMS4uNSBmb3IgdGhlIGh5cGVyY2FsbAorICogT3V0cHV0OiAl
W2VyXWF4CisgKi8KK1NZTV9GVU5DX1NUQVJUKHhlbl9oeXBlcmNhbGxfaHZt
KQorCUVOREJSCisJRlJBTUVfQkVHSU4KKwkvKiBTYXZlIGFsbCByZWxldmFu
dCByZWdpc3RlcnMgKGNhbGxlciBzYXZlIGFuZCBhcmd1bWVudHMpLiAqLwor
I2lmZGVmIENPTkZJR19YODZfMzIKKwlwdXNoICVlYXgKKwlwdXNoICVlYngK
KwlwdXNoICVlY3gKKwlwdXNoICVlZHgKKwlwdXNoICVlc2kKKwlwdXNoICVl
ZGkKKyNlbHNlCisJcHVzaCAlcmF4CisJcHVzaCAlcmN4CisJcHVzaCAlcmR4
CisJcHVzaCAlcmRpCisJcHVzaCAlcnNpCisJcHVzaCAlcjExCisJcHVzaCAl
cjEwCisJcHVzaCAlcjkKKwlwdXNoICVyOAorI2lmZGVmIENPTkZJR19GUkFN
RV9QT0lOVEVSCisJcHVzaHEgJDAJLyogRHVtbXkgcHVzaCBmb3Igc3RhY2sg
YWxpZ25tZW50LiAqLworI2VuZGlmCisjZW5kaWYKKwkvKiBTZXQgdGhlIHZl
bmRvciBzcGVjaWZpYyBmdW5jdGlvbi4gKi8KKwljYWxsIF9feGVuX2h5cGVy
Y2FsbF9zZXRmdW5jCisJLyogU2V0IFpGID0gMSBpZiBBTUQsIFJlc3RvcmUg
c2F2ZWQgcmVnaXN0ZXJzLiAqLworI2lmZGVmIENPTkZJR19YODZfMzIKKwls
ZWEgeGVuX2h5cGVyY2FsbF9hbWQsICVlYngKKwljbXAgJWVheCwgJWVieAor
CXBvcCAlZWRpCisJcG9wICVlc2kKKwlwb3AgJWVkeAorCXBvcCAlZWN4CisJ
cG9wICVlYngKKwlwb3AgJWVheAorI2Vsc2UKKwlsZWEgeGVuX2h5cGVyY2Fs
bF9hbWQoJXJpcCksICVyYngKKwljbXAgJXJheCwgJXJieAorI2lmZGVmIENP
TkZJR19GUkFNRV9QT0lOVEVSCisJcG9wICVyYXgJLyogRHVtbXkgcG9wLiAq
LworI2VuZGlmCisJcG9wICVyOAorCXBvcCAlcjkKKwlwb3AgJXIxMAorCXBv
cCAlcjExCisJcG9wICVyc2kKKwlwb3AgJXJkaQorCXBvcCAlcmR4CisJcG9w
ICVyY3gKKwlwb3AgJXJheAorI2VuZGlmCisJLyogVXNlIGNvcnJlY3QgaHlw
ZXJjYWxsIGZ1bmN0aW9uLiAqLworCWp6IHhlbl9oeXBlcmNhbGxfYW1kCisJ
am1wIHhlbl9oeXBlcmNhbGxfaW50ZWwKK1NZTV9GVU5DX0VORCh4ZW5faHlw
ZXJjYWxsX2h2bSkKKworU1lNX0ZVTkNfU1RBUlQoeGVuX2h5cGVyY2FsbF9h
bWQpCisJdm1tY2FsbAorCVJFVAorU1lNX0ZVTkNfRU5EKHhlbl9oeXBlcmNh
bGxfYW1kKQorCitTWU1fRlVOQ19TVEFSVCh4ZW5faHlwZXJjYWxsX2ludGVs
KQorCXZtY2FsbAorCVJFVAorU1lNX0ZVTkNfRU5EKHhlbl9oeXBlcmNhbGxf
aW50ZWwpCisJLnBvcHNlY3Rpb24KKwogCUVMRk5PVEUoWGVuLCBYRU5fRUxG
Tk9URV9HVUVTVF9PUywgICAgICAgLmFzY2l6ICJsaW51eCIpCiAJRUxGTk9U
RShYZW4sIFhFTl9FTEZOT1RFX0dVRVNUX1ZFUlNJT04sICAuYXNjaXogIjIu
NiIpCiAJRUxGTk9URShYZW4sIFhFTl9FTEZOT1RFX1hFTl9WRVJTSU9OLCAg
ICAuYXNjaXogInhlbi0zLjAiKQpkaWZmIC0tZ2l0IGEvYXJjaC94ODYveGVu
L3hlbi1vcHMuaCBiL2FyY2gveDg2L3hlbi94ZW4tb3BzLmgKaW5kZXggZTFi
NzgyZTgyM2U2Li42M2MxM2EyY2NmNTUgMTAwNjQ0Ci0tLSBhL2FyY2gveDg2
L3hlbi94ZW4tb3BzLmgKKysrIGIvYXJjaC94ODYveGVuL3hlbi1vcHMuaApA
QCAtMzI2LDQgKzMyNiwxMyBAQCBzdGF0aWMgaW5saW5lIHZvaWQgeGVuX3Nt
cF9pbnRyX2ZyZWVfcHYodW5zaWduZWQgaW50IGNwdSkge30KIHN0YXRpYyBp
bmxpbmUgdm9pZCB4ZW5fc21wX2NvdW50X2NwdXModm9pZCkgeyB9CiAjZW5k
aWYgLyogQ09ORklHX1NNUCAqLwogCisjaWZkZWYgQ09ORklHX1hFTl9QVgor
dm9pZCB4ZW5faHlwZXJjYWxsX3B2KHZvaWQpOworI2VuZGlmCit2b2lkIHhl
bl9oeXBlcmNhbGxfaHZtKHZvaWQpOwordm9pZCB4ZW5faHlwZXJjYWxsX2Ft
ZCh2b2lkKTsKK3ZvaWQgeGVuX2h5cGVyY2FsbF9pbnRlbCh2b2lkKTsKK3Zv
aWQgeGVuX2h5cGVyY2FsbF9zZXRmdW5jKHZvaWQpOwordm9pZCAqX194ZW5f
aHlwZXJjYWxsX3NldGZ1bmModm9pZCk7CisKICNlbmRpZiAvKiBYRU5fT1BT
X0ggKi8KLS0gCjIuNDMuMAoK

--=separator
Content-Type: application/octet-stream; name="xsa466-linux-06.patch"
Content-Disposition: attachment; filename="xsa466-linux-06.patch"
Content-Transfer-Encoding: base64

RnJvbSBiMWMyY2I4NmY0YTc4NjE0ODBhZDU0YmI5YTU4ZGYzY2JlYmY4ZTky
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKdWVyZ2VuIEdyb3Nz
IDxqZ3Jvc3NAc3VzZS5jb20+CkRhdGU6IFRodSwgMTcgT2N0IDIwMjQgMTQ6
NDc6MTMgKzAyMDAKU3ViamVjdDogeDg2L3hlbjogdXNlIG5ldyBoeXBlcmNh
bGwgZnVuY3Rpb25zIGluc3RlYWQgb2YgaHlwZXJjYWxsCiBwYWdlCgpDYWxs
IHRoZSBYZW4gaHlwZXJ2aXNvciB2aWEgdGhlIG5ldyB4ZW5faHlwZXJjYWxs
X2Z1bmMgc3RhdGljLWNhbGwKaW5zdGVhZCBvZiB0aGUgaHlwZXJjYWxsIHBh
Z2UuCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTQ2NiAvIENWRS0yMDI0LTUzMjQx
LgoKUmVwb3J0ZWQtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIz
QGNpdHJpeC5jb20+ClNpZ25lZC1vZmYtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpn
cm9zc0BzdXNlLmNvbT4KQ28tZGV2ZWxvcGVkLWJ5OiBQZXRlciBaaWpsc3Ry
YSA8cGV0ZXJ6QGluZnJhZGVhZC5vcmc+CkNvLWRldmVsb3BlZC1ieTogSm9z
aCBQb2ltYm9ldWYgPGpwb2ltYm9lQHJlZGhhdC5jb20+Ci0tLQogYXJjaC94
ODYvaW5jbHVkZS9hc20veGVuL2h5cGVyY2FsbC5oIHwgMzMgKysrKysrKysr
KysrKysrKystLS0tLS0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDIwIGluc2Vy
dGlvbnMoKyksIDEzIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2FyY2gv
eDg2L2luY2x1ZGUvYXNtL3hlbi9oeXBlcmNhbGwuaCBiL2FyY2gveDg2L2lu
Y2x1ZGUvYXNtL3hlbi9oeXBlcmNhbGwuaAppbmRleCA2YjRkZDRkZTA4YTYu
LjdkNWY4YWQ2Njc3NCAxMDA2NDQKLS0tIGEvYXJjaC94ODYvaW5jbHVkZS9h
c20veGVuL2h5cGVyY2FsbC5oCisrKyBiL2FyY2gveDg2L2luY2x1ZGUvYXNt
L3hlbi9oeXBlcmNhbGwuaApAQCAtMzksOSArMzksMTEgQEAKICNpbmNsdWRl
IDxsaW51eC9zdHJpbmcuaD4KICNpbmNsdWRlIDxsaW51eC90eXBlcy5oPgog
I2luY2x1ZGUgPGxpbnV4L3BndGFibGUuaD4KKyNpbmNsdWRlIDxsaW51eC9p
bnN0cnVtZW50YXRpb24uaD4KIAogI2luY2x1ZGUgPHRyYWNlL2V2ZW50cy94
ZW4uaD4KIAorI2luY2x1ZGUgPGFzbS9hbHRlcm5hdGl2ZS5oPgogI2luY2x1
ZGUgPGFzbS9wYWdlLmg+CiAjaW5jbHVkZSA8YXNtL3NtYXAuaD4KICNpbmNs
dWRlIDxhc20vbm9zcGVjLWJyYW5jaC5oPgpAQCAtOTEsOSArOTMsMTcgQEAg
ZXh0ZXJuIHN0cnVjdCB7IGNoYXIgX2VudHJ5WzMyXTsgfSBoeXBlcmNhbGxf
cGFnZVtdOwogdm9pZCB4ZW5faHlwZXJjYWxsX2Z1bmModm9pZCk7CiBERUNM
QVJFX1NUQVRJQ19DQUxMKHhlbl9oeXBlcmNhbGwsIHhlbl9oeXBlcmNhbGxf
ZnVuYyk7CiAKLSNkZWZpbmUgX19IWVBFUkNBTEwJCSJjYWxsIGh5cGVyY2Fs
bF9wYWdlKyVjW29mZnNldF0iCi0jZGVmaW5lIF9fSFlQRVJDQUxMX0VOVFJZ
KHgpCQkJCQkJXAotCVtvZmZzZXRdICJpIiAoX19IWVBFUlZJU09SXyMjeCAq
IHNpemVvZihoeXBlcmNhbGxfcGFnZVswXSkpCisjaWZkZWYgTU9EVUxFCisj
ZGVmaW5lIF9fQUREUkVTU0FCTEVfeGVuX2h5cGVyY2FsbAorI2Vsc2UKKyNk
ZWZpbmUgX19BRERSRVNTQUJMRV94ZW5faHlwZXJjYWxsIF9fQUREUkVTU0FC
TEVfQVNNX1NUUihfX1NDS19feGVuX2h5cGVyY2FsbCkKKyNlbmRpZgorCisj
ZGVmaW5lIF9fSFlQRVJDQUxMCQkJCQlcCisJX19BRERSRVNTQUJMRV94ZW5f
aHlwZXJjYWxsCQkJXAorCSJjYWxsIF9fU0NUX194ZW5faHlwZXJjYWxsIgor
CisjZGVmaW5lIF9fSFlQRVJDQUxMX0VOVFJZKHgpCSJhIiAoeCkKIAogI2lm
ZGVmIENPTkZJR19YODZfMzIKICNkZWZpbmUgX19IWVBFUkNBTExfUkVUUkVH
CSJlYXgiCkBAIC0xNTEsNyArMTYxLDcgQEAgREVDTEFSRV9TVEFUSUNfQ0FM
TCh4ZW5faHlwZXJjYWxsLCB4ZW5faHlwZXJjYWxsX2Z1bmMpOwogCV9fSFlQ
RVJDQUxMXzBBUkcoKTsJCQkJCQlcCiAJYXNtIHZvbGF0aWxlIChfX0hZUEVS
Q0FMTAkJCQkJXAogCQkgICAgICA6IF9fSFlQRVJDQUxMXzBQQVJBTQkJCQlc
Ci0JCSAgICAgIDogX19IWVBFUkNBTExfRU5UUlkobmFtZSkJCQkJXAorCQkg
ICAgICA6IF9fSFlQRVJDQUxMX0VOVFJZKF9fSFlQRVJWSVNPUl8gIyMgbmFt
ZSkJXAogCQkgICAgICA6IF9fSFlQRVJDQUxMX0NMT0JCRVIwKTsJCQkJXAog
CSh0eXBlKV9fcmVzOwkJCQkJCQlcCiB9KQpAQCAtMTYyLDcgKzE3Miw3IEBA
IERFQ0xBUkVfU1RBVElDX0NBTEwoeGVuX2h5cGVyY2FsbCwgeGVuX2h5cGVy
Y2FsbF9mdW5jKTsKIAlfX0hZUEVSQ0FMTF8xQVJHKGExKTsJCQkJCQlcCiAJ
YXNtIHZvbGF0aWxlIChfX0hZUEVSQ0FMTAkJCQkJXAogCQkgICAgICA6IF9f
SFlQRVJDQUxMXzFQQVJBTQkJCQlcCi0JCSAgICAgIDogX19IWVBFUkNBTExf
RU5UUlkobmFtZSkJCQkJXAorCQkgICAgICA6IF9fSFlQRVJDQUxMX0VOVFJZ
KF9fSFlQRVJWSVNPUl8gIyMgbmFtZSkJXAogCQkgICAgICA6IF9fSFlQRVJD
QUxMX0NMT0JCRVIxKTsJCQkJXAogCSh0eXBlKV9fcmVzOwkJCQkJCQlcCiB9
KQpAQCAtMTczLDcgKzE4Myw3IEBAIERFQ0xBUkVfU1RBVElDX0NBTEwoeGVu
X2h5cGVyY2FsbCwgeGVuX2h5cGVyY2FsbF9mdW5jKTsKIAlfX0hZUEVSQ0FM
TF8yQVJHKGExLCBhMik7CQkJCQlcCiAJYXNtIHZvbGF0aWxlIChfX0hZUEVS
Q0FMTAkJCQkJXAogCQkgICAgICA6IF9fSFlQRVJDQUxMXzJQQVJBTQkJCQlc
Ci0JCSAgICAgIDogX19IWVBFUkNBTExfRU5UUlkobmFtZSkJCQkJXAorCQkg
ICAgICA6IF9fSFlQRVJDQUxMX0VOVFJZKF9fSFlQRVJWSVNPUl8gIyMgbmFt
ZSkJXAogCQkgICAgICA6IF9fSFlQRVJDQUxMX0NMT0JCRVIyKTsJCQkJXAog
CSh0eXBlKV9fcmVzOwkJCQkJCQlcCiB9KQpAQCAtMTg0LDcgKzE5NCw3IEBA
IERFQ0xBUkVfU1RBVElDX0NBTEwoeGVuX2h5cGVyY2FsbCwgeGVuX2h5cGVy
Y2FsbF9mdW5jKTsKIAlfX0hZUEVSQ0FMTF8zQVJHKGExLCBhMiwgYTMpOwkJ
CQkJXAogCWFzbSB2b2xhdGlsZSAoX19IWVBFUkNBTEwJCQkJCVwKIAkJICAg
ICAgOiBfX0hZUEVSQ0FMTF8zUEFSQU0JCQkJXAotCQkgICAgICA6IF9fSFlQ
RVJDQUxMX0VOVFJZKG5hbWUpCQkJCVwKKwkJICAgICAgOiBfX0hZUEVSQ0FM
TF9FTlRSWShfX0hZUEVSVklTT1JfICMjIG5hbWUpCVwKIAkJICAgICAgOiBf
X0hZUEVSQ0FMTF9DTE9CQkVSMyk7CQkJCVwKIAkodHlwZSlfX3JlczsJCQkJ
CQkJXAogfSkKQEAgLTE5NSw3ICsyMDUsNyBAQCBERUNMQVJFX1NUQVRJQ19D
QUxMKHhlbl9oeXBlcmNhbGwsIHhlbl9oeXBlcmNhbGxfZnVuYyk7CiAJX19I
WVBFUkNBTExfNEFSRyhhMSwgYTIsIGEzLCBhNCk7CQkJCVwKIAlhc20gdm9s
YXRpbGUgKF9fSFlQRVJDQUxMCQkJCQlcCiAJCSAgICAgIDogX19IWVBFUkNB
TExfNFBBUkFNCQkJCVwKLQkJICAgICAgOiBfX0hZUEVSQ0FMTF9FTlRSWShu
YW1lKQkJCQlcCisJCSAgICAgIDogX19IWVBFUkNBTExfRU5UUlkoX19IWVBF
UlZJU09SXyAjIyBuYW1lKQlcCiAJCSAgICAgIDogX19IWVBFUkNBTExfQ0xP
QkJFUjQpOwkJCQlcCiAJKHR5cGUpX19yZXM7CQkJCQkJCVwKIH0pCkBAIC0y
MDksMTIgKzIxOSw5IEBAIHhlbl9zaW5nbGVfY2FsbCh1bnNpZ25lZCBpbnQg
Y2FsbCwKIAlfX0hZUEVSQ0FMTF9ERUNMUzsKIAlfX0hZUEVSQ0FMTF81QVJH
KGExLCBhMiwgYTMsIGE0LCBhNSk7CiAKLQlpZiAoY2FsbCA+PSBQQUdFX1NJ
WkUgLyBzaXplb2YoaHlwZXJjYWxsX3BhZ2VbMF0pKQotCQlyZXR1cm4gLUVJ
TlZBTDsKLQotCWFzbSB2b2xhdGlsZShDQUxMX05PU1BFQworCWFzbSB2b2xh
dGlsZShfX0hZUEVSQ0FMTAogCQkgICAgIDogX19IWVBFUkNBTExfNVBBUkFN
Ci0JCSAgICAgOiBbdGh1bmtfdGFyZ2V0XSAiYSIgKCZoeXBlcmNhbGxfcGFn
ZVtjYWxsXSkKKwkJICAgICA6IF9fSFlQRVJDQUxMX0VOVFJZKGNhbGwpCiAJ
CSAgICAgOiBfX0hZUEVSQ0FMTF9DTE9CQkVSNSk7CiAKIAlyZXR1cm4gKGxv
bmcpX19yZXM7Ci0tIAoyLjQzLjAKCg==

--=separator
Content-Type: application/octet-stream; name="xsa466-linux-07.patch"
Content-Disposition: attachment; filename="xsa466-linux-07.patch"
Content-Transfer-Encoding: base64

RnJvbSA3ZmEwZGE1MzczNjg1ZTdlZDI0OWFmM2ZhMzE3YWIxZTFiYThiMGE2
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKdWVyZ2VuIEdyb3Nz
IDxqZ3Jvc3NAc3VzZS5jb20+CkRhdGU6IFRodSwgMTcgT2N0IDIwMjQgMTU6
Mjc6MzEgKzAyMDAKU3ViamVjdDogeDg2L3hlbjogcmVtb3ZlIGh5cGVyY2Fs
bCBwYWdlCgpUaGUgaHlwZXJjYWxsIHBhZ2UgaXMgbm8gbG9uZ2VyIG5lZWRl
ZC4gSXQgY2FuIGJlIHJlbW92ZWQsIGFzIGZyb20gdGhlClhlbiBwZXJzcGVj
dGl2ZSBpdCBpcyBvcHRpb25hbC4KCkJ1dCwgZnJvbSBMaW51eCdzIHBlcnNw
ZWN0aXZlLCBpdCByZW1vdmVzIG5ha2VkIFJFVCBpbnN0cnVjdGlvbnMgdGhh
dAplc2NhcGUgdGhlIHNwZWN1bGF0aXZlIHByb3RlY3Rpb25zIHRoYXQgQ2Fs
bCBEZXB0aCBUcmFja2luZyBhbmQvb3IKVW50cmFpbiBSZXQgYXJlIHRyeWlu
ZyB0byBhY2hpZXZlLgoKVGhpcyBpcyBwYXJ0IG9mIFhTQS00NjYgLyBDVkUt
MjAyNC01MzI0MS4KClJlcG9ydGVkLWJ5OiBBbmRyZXcgQ29vcGVyIDxhbmRy
ZXcuY29vcGVyM0BjaXRyaXguY29tPgpTaWduZWQtb2ZmLWJ5OiBKdWVyZ2Vu
IEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+ClJldmlld2VkLWJ5OiBBbmRyZXcg
Q29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpSZXZpZXdlZC1i
eTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgotLS0KIGFyY2gv
eDg2L2luY2x1ZGUvYXNtL3hlbi9oeXBlcmNhbGwuaCB8ICAyIC0tCiBhcmNo
L3g4Ni9rZXJuZWwvY2FsbHRodW5rcy5jICAgICAgICAgfCAgNSAtLS0tLQog
YXJjaC94ODYva2VybmVsL3ZtbGludXgubGRzLlMgICAgICAgIHwgIDQgLS0t
LQogYXJjaC94ODYveGVuL2VubGlnaHRlbi5jICAgICAgICAgICAgIHwgIDIg
LS0KIGFyY2gveDg2L3hlbi9lbmxpZ2h0ZW5faHZtLmMgICAgICAgICB8ICA5
ICstLS0tLS0tLQogYXJjaC94ODYveGVuL2VubGlnaHRlbl9wdmguYyAgICAg
ICAgIHwgIDcgLS0tLS0tLQogYXJjaC94ODYveGVuL3hlbi1oZWFkLlMgICAg
ICAgICAgICAgIHwgMjQgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiA3IGZp
bGVzIGNoYW5nZWQsIDEgaW5zZXJ0aW9uKCspLCA1MiBkZWxldGlvbnMoLSkK
CmRpZmYgLS1naXQgYS9hcmNoL3g4Ni9pbmNsdWRlL2FzbS94ZW4vaHlwZXJj
YWxsLmggYi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS94ZW4vaHlwZXJjYWxsLmgK
aW5kZXggN2Q1ZjhhZDY2Nzc0Li45Nzc3MWI5ZDMzYWYgMTAwNjQ0Ci0tLSBh
L2FyY2gveDg2L2luY2x1ZGUvYXNtL3hlbi9oeXBlcmNhbGwuaAorKysgYi9h
cmNoL3g4Ni9pbmNsdWRlL2FzbS94ZW4vaHlwZXJjYWxsLmgKQEAgLTg4LDgg
Kzg4LDYgQEAgc3RydWN0IHhlbl9kbV9vcF9idWY7CiAgKiB0aGVyZSBhcmVu
J3QgbW9yZSB0aGFuIDUgYXJndW1lbnRzLi4uKQogICovCiAKLWV4dGVybiBz
dHJ1Y3QgeyBjaGFyIF9lbnRyeVszMl07IH0gaHlwZXJjYWxsX3BhZ2VbXTsK
LQogdm9pZCB4ZW5faHlwZXJjYWxsX2Z1bmModm9pZCk7CiBERUNMQVJFX1NU
QVRJQ19DQUxMKHhlbl9oeXBlcmNhbGwsIHhlbl9oeXBlcmNhbGxfZnVuYyk7
CiAKZGlmZiAtLWdpdCBhL2FyY2gveDg2L2tlcm5lbC9jYWxsdGh1bmtzLmMg
Yi9hcmNoL3g4Ni9rZXJuZWwvY2FsbHRodW5rcy5jCmluZGV4IDQ2NTY0NzQ1
Njc1My4uZjE3ZDE2NjA3ODgyIDEwMDY0NAotLS0gYS9hcmNoL3g4Ni9rZXJu
ZWwvY2FsbHRodW5rcy5jCisrKyBiL2FyY2gveDg2L2tlcm5lbC9jYWxsdGh1
bmtzLmMKQEAgLTE0MiwxMSArMTQyLDYgQEAgc3RhdGljIGJvb2wgc2tpcF9h
ZGRyKHZvaWQgKmRlc3QpCiAJaWYgKGRlc3QgPj0gKHZvaWQgKilyZWxvY2F0
ZV9rZXJuZWwgJiYKIAkgICAgZGVzdCA8ICh2b2lkKilyZWxvY2F0ZV9rZXJu
ZWwgKyBLRVhFQ19DT05UUk9MX0NPREVfTUFYX1NJWkUpCiAJCXJldHVybiB0
cnVlOwotI2VuZGlmCi0jaWZkZWYgQ09ORklHX1hFTgotCWlmIChkZXN0ID49
ICh2b2lkICopaHlwZXJjYWxsX3BhZ2UgJiYKLQkgICAgZGVzdCA8ICh2b2lk
KiloeXBlcmNhbGxfcGFnZSArIFBBR0VfU0laRSkKLQkJcmV0dXJuIHRydWU7
CiAjZW5kaWYKIAlyZXR1cm4gZmFsc2U7CiB9CmRpZmYgLS1naXQgYS9hcmNo
L3g4Ni9rZXJuZWwvdm1saW51eC5sZHMuUyBiL2FyY2gveDg2L2tlcm5lbC92
bWxpbnV4Lmxkcy5TCmluZGV4IGZhYjNhYzlhNDU3NC4uNmExNzM5NmM4MTc0
IDEwMDY0NAotLS0gYS9hcmNoL3g4Ni9rZXJuZWwvdm1saW51eC5sZHMuUwor
KysgYi9hcmNoL3g4Ni9rZXJuZWwvdm1saW51eC5sZHMuUwpAQCAtNTE5LDE0
ICs1MTksMTAgQEAgSU5JVF9QRVJfQ1BVKGlycV9zdGFja19iYWNraW5nX3N0
b3JlKTsKICAqIGxpbmtlciB3aWxsIG5ldmVyIG1hcmsgYXMgcmVsb2NhdGFi
bGUuIChVc2luZyBqdXN0IEFCU09MVVRFKCkgaXMgbm90CiAgKiBzdWZmaWNp
ZW50IGZvciB0aGF0KS4KICAqLwotI2lmZGVmIENPTkZJR19YRU4KICNpZmRl
ZiBDT05GSUdfWEVOX1BWCiB4ZW5fZWxmbm90ZV9lbnRyeV92YWx1ZSA9CiAJ
QUJTT0xVVEUoeGVuX2VsZm5vdGVfZW50cnkpICsgQUJTT0xVVEUoc3RhcnR1
cF94ZW4pOwogI2VuZGlmCi14ZW5fZWxmbm90ZV9oeXBlcmNhbGxfcGFnZV92
YWx1ZSA9Ci0JQUJTT0xVVEUoeGVuX2VsZm5vdGVfaHlwZXJjYWxsX3BhZ2Up
ICsgQUJTT0xVVEUoaHlwZXJjYWxsX3BhZ2UpOwotI2VuZGlmCiAjaWZkZWYg
Q09ORklHX1BWSAogeGVuX2VsZm5vdGVfcGh5czMyX2VudHJ5X3ZhbHVlID0K
IAlBQlNPTFVURSh4ZW5fZWxmbm90ZV9waHlzMzJfZW50cnkpICsgQUJTT0xV
VEUocHZoX3N0YXJ0X3hlbiAtIExPQURfT0ZGU0VUKTsKZGlmZiAtLWdpdCBh
L2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYyBiL2FyY2gveDg2L3hlbi9lbmxp
Z2h0ZW4uYwppbmRleCAxODg3NDM1YWYyZmIuLjQzZGNkOGM3YmFkYyAxMDA2
NDQKLS0tIGEvYXJjaC94ODYveGVuL2VubGlnaHRlbi5jCisrKyBiL2FyY2gv
eDg2L3hlbi9lbmxpZ2h0ZW4uYwpAQCAtMjIsOCArMjIsNiBAQAogCiAjaW5j
bHVkZSAieGVuLW9wcy5oIgogCi1FWFBPUlRfU1lNQk9MX0dQTChoeXBlcmNh
bGxfcGFnZSk7Ci0KIERFRklORV9TVEFUSUNfQ0FMTCh4ZW5faHlwZXJjYWxs
LCB4ZW5faHlwZXJjYWxsX2h2bSk7CiBFWFBPUlRfU1RBVElDX0NBTExfVFJB
TVAoeGVuX2h5cGVyY2FsbCk7CiAKZGlmZiAtLWdpdCBhL2FyY2gveDg2L3hl
bi9lbmxpZ2h0ZW5faHZtLmMgYi9hcmNoL3g4Ni94ZW4vZW5saWdodGVuX2h2
bS5jCmluZGV4IDk3M2E3NGZjOTY2YS4uZmU1N2ZmODVkMDA0IDEwMDY0NAot
LS0gYS9hcmNoL3g4Ni94ZW4vZW5saWdodGVuX2h2bS5jCisrKyBiL2FyY2gv
eDg2L3hlbi9lbmxpZ2h0ZW5faHZtLmMKQEAgLTEwNiwxNSArMTA2LDggQEAg
c3RhdGljIHZvaWQgX19pbml0IGluaXRfaHZtX3B2X2luZm8odm9pZCkKIAkv
KiBQVkggc2V0IHVwIGh5cGVyY2FsbCBwYWdlIGluIHhlbl9wcmVwYXJlX3B2
aCgpLiAqLwogCWlmICh4ZW5fcHZoX2RvbWFpbigpKQogCQlwdl9pbmZvLm5h
bWUgPSAiWGVuIFBWSCI7Ci0JZWxzZSB7Ci0JCXU2NCBwZm47Ci0JCXVpbnQz
Ml90IG1zcjsKLQorCWVsc2UKIAkJcHZfaW5mby5uYW1lID0gIlhlbiBIVk0i
OwotCQltc3IgPSBjcHVpZF9lYngoYmFzZSArIDIpOwotCQlwZm4gPSBfX3Bh
KGh5cGVyY2FsbF9wYWdlKTsKLQkJd3Jtc3Jfc2FmZShtc3IsICh1MzIpcGZu
LCAodTMyKShwZm4gPj4gMzIpKTsKLQl9CiAKIAl4ZW5fc2V0dXBfZmVhdHVy
ZXMoKTsKIApkaWZmIC0tZ2l0IGEvYXJjaC94ODYveGVuL2VubGlnaHRlbl9w
dmguYyBiL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW5fcHZoLmMKaW5kZXggYmY2
OGMzMjlmYzAxLi4wZTNkOTMwYmNiODkgMTAwNjQ0Ci0tLSBhL2FyY2gveDg2
L3hlbi9lbmxpZ2h0ZW5fcHZoLmMKKysrIGIvYXJjaC94ODYveGVuL2VubGln
aHRlbl9wdmguYwpAQCAtMTI5LDE3ICsxMjksMTAgQEAgc3RhdGljIHZvaWQg
X19pbml0IHB2aF9hcmNoX3NldHVwKHZvaWQpCiAKIHZvaWQgX19pbml0IHhl
bl9wdmhfaW5pdChzdHJ1Y3QgYm9vdF9wYXJhbXMgKmJvb3RfcGFyYW1zKQog
ewotCXUzMiBtc3I7Ci0JdTY0IHBmbjsKLQogCXhlbl9wdmggPSAxOwogCXhl
bl9kb21haW5fdHlwZSA9IFhFTl9IVk1fRE9NQUlOOwogCXhlbl9zdGFydF9m
bGFncyA9IHB2aF9zdGFydF9pbmZvLmZsYWdzOwogCi0JbXNyID0gY3B1aWRf
ZWJ4KHhlbl9jcHVpZF9iYXNlKCkgKyAyKTsKLQlwZm4gPSBfX3BhKGh5cGVy
Y2FsbF9wYWdlKTsKLQl3cm1zcl9zYWZlKG1zciwgKHUzMilwZm4sICh1MzIp
KHBmbiA+PiAzMikpOwotCiAJeDg2X2luaXQub2VtLmFyY2hfc2V0dXAgPSBw
dmhfYXJjaF9zZXR1cDsKIAl4ODZfaW5pdC5vZW0uYmFubmVyID0geGVuX2Jh
bm5lcjsKIApkaWZmIC0tZ2l0IGEvYXJjaC94ODYveGVuL3hlbi1oZWFkLlMg
Yi9hcmNoL3g4Ni94ZW4veGVuLWhlYWQuUwppbmRleCBjMTczYmE2NzQwZTku
LjkyNTI2NTJhZmU1OSAxMDA2NDQKLS0tIGEvYXJjaC94ODYveGVuL3hlbi1o
ZWFkLlMKKysrIGIvYXJjaC94ODYveGVuL3hlbi1oZWFkLlMKQEAgLTIyLDI4
ICsyMiw2IEBACiAjaW5jbHVkZSA8eGVuL2ludGVyZmFjZS94ZW4tbWNhLmg+
CiAjaW5jbHVkZSA8YXNtL3hlbi9pbnRlcmZhY2UuaD4KIAotLnB1c2hzZWN0
aW9uIC5ub2luc3RyLnRleHQsICJheCIKLQkuYmFsaWduIFBBR0VfU0laRQot
U1lNX0NPREVfU1RBUlQoaHlwZXJjYWxsX3BhZ2UpCi0JLnJlcHQgKFBBR0Vf
U0laRSAvIDMyKQotCQlVTldJTkRfSElOVF9GVU5DCi0JCUFOTk9UQVRFX05P
RU5EQlIKLQkJQU5OT1RBVEVfVU5SRVRfU0FGRQotCQlyZXQKLQkJLyoKLQkJ
ICogWGVuIHdpbGwgd3JpdGUgdGhlIGh5cGVyY2FsbCBwYWdlLCBhbmQgc29y
dCBvdXQgRU5EQlIuCi0JCSAqLwotCQkuc2tpcCAzMSwgMHhjYwotCS5lbmRy
Ci0KLSNkZWZpbmUgSFlQRVJDQUxMKG4pIFwKLQkuZXF1IHhlbl9oeXBlcmNh
bGxfIyNuLCBoeXBlcmNhbGxfcGFnZSArIF9fSFlQRVJWSVNPUl8jI24gKiAz
MjsgXAotCS50eXBlIHhlbl9oeXBlcmNhbGxfIyNuLCBAZnVuY3Rpb247IC5z
aXplIHhlbl9oeXBlcmNhbGxfIyNuLCAzMgotI2luY2x1ZGUgPGFzbS94ZW4t
aHlwZXJjYWxscy5oPgotI3VuZGVmIEhZUEVSQ0FMTAotU1lNX0NPREVfRU5E
KGh5cGVyY2FsbF9wYWdlKQotLnBvcHNlY3Rpb24KLQogI2lmZGVmIENPTkZJ
R19YRU5fUFYKIAlfX0lOSVQKIFNZTV9DT0RFX1NUQVJUKHN0YXJ0dXBfeGVu
KQpAQCAtMTk5LDggKzE3Nyw2IEBAIFNZTV9GVU5DX0VORCh4ZW5faHlwZXJj
YWxsX2ludGVsKQogI2Vsc2UKICMgZGVmaW5lIEZFQVRVUkVTX0RPTTAgMAog
I2VuZGlmCi0JRUxGTk9URShYZW4sIFhFTl9FTEZOT1RFX0hZUEVSQ0FMTF9Q
QUdFLCAuZ2xvYmwgeGVuX2VsZm5vdGVfaHlwZXJjYWxsX3BhZ2U7Ci0JCXhl
bl9lbGZub3RlX2h5cGVyY2FsbF9wYWdlOiBfQVNNX1BUUiB4ZW5fZWxmbm90
ZV9oeXBlcmNhbGxfcGFnZV92YWx1ZSAtIC4pCiAJRUxGTk9URShYZW4sIFhF
Tl9FTEZOT1RFX1NVUFBPUlRFRF9GRUFUVVJFUywKIAkJLmxvbmcgRkVBVFVS
RVNfUFYgfCBGRUFUVVJFU19QVkggfCBGRUFUVVJFU19ET00wKQogCUVMRk5P
VEUoWGVuLCBYRU5fRUxGTk9URV9MT0FERVIsICAgICAgICAgLmFzY2l6ICJn
ZW5lcmljIikKLS0gCjIuNDMuMAoK

--=separator
Content-Type: application/octet-stream; name="xsa466-xen.patch"
Content-Disposition: attachment; filename="xsa466-xen.patch"
Content-Transfer-Encoding: base64

RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv
bT4KU3ViamVjdDogZG9jcy9ndWVzdC1ndWlkZTogRGlzY3VzcyB3aGVuIG5v
dCB1c2UgYSBoeXBlcmNhbGwgcGFnZQoKVGhlIExpbnV4IHJldGh1bmsgYW5k
IHNhZmUtcmV0IHNwZWN1bGF0aXZlIHNhZmV0eSB0ZWNobmlxdWVzIGludm9s
dmUKdHJhbnNmb3JtaW5nIGByZXRgIHRvIGBqbXAgX194ODZfcmV0dXJuX3Ro
dW5rYCBhdCBjb21waWxlIHRpbWUuICBQbGFjaW5nIG5ha2VkCmByZXRgcyBi
YWNrIGluIGV4ZWN1dGFibGUgLnRleHQgYnJlYWtzIHRoZXNlIG1pdGlnYXRp
b25zLgoKQ0VULUlCVCByZXF1aXJlcyBFTkRCUiBpbnN0cnVjdGlvbnMsIGFu
ZCB3aGlsZSB3ZSBjb3VsZCBpbiBwcmluY2lwbGUgZml4IHRoYXQsCnRoZSBu
ZWVkIHRvIHNlbGVjdCBiZXR3ZWVuIEVOREJSMzIgb3IgRU5EQlI2NCBtZWFu
cyB0aGF0IHRoZSBjb250ZW50cyBvZiB0aGUKaHlwZXJjYWxsIHBhZ2Ugd291
bGQgbmVlZCB0byBiZWNvbWUgbW9yZSBtb2RlLXNwZWNpZmljIHRoYW4gaXQg
Y3VycmVudGx5CmlzIChIVk0gaHlwZXJjYWxsIHBhZ2VzIGFyZSBjdXJyZW50
bHkgMzJiaXQgYW5kIDY0Yml0IGNvbXBhdGJpbGUpLiAgSG93ZXZlciwKdGhl
cmUncyBubyBmZWFzaWJsZSB3YXkgdG8gbWFrZSBhIGh5cGVyY2FsbCBwYWdl
IGNvbXBhdGlibGUgd2l0aCBmaW5lLWdyYWluCkNGSSBzY2hlbWVzIHN1Y2gg
YXMgRmluZUlCVC4KCk9TZXMgd2hpY2ggY2FyZSBhYm91dCBlaXRoZXIgb2Yg
dGhlc2UgdGhpbmdzIGFyZSBiZXR0ZXIgb2ZmIGF2b2lkaW5nIHRoZQpoeXBl
cmNhbGwgcGFnZS4KClRoaXMgaXMgcGFydCBvZiBYU0EtNDY2LgoKU2lnbmVk
LW9mZi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4
LmNvbT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNl
LmNvbT4KCmRpZmYgLS1naXQgYS9kb2NzL2d1ZXN0LWd1aWRlL3g4Ni9oeXBl
cmNhbGwtYWJpLnJzdCBiL2RvY3MvZ3Vlc3QtZ3VpZGUveDg2L2h5cGVyY2Fs
bC1hYmkucnN0CmluZGV4IDgwMDQxMjJjYTQ5ZC4uNzQ1ZmJiYjY0YTI2IDEw
MDY0NAotLS0gYS9kb2NzL2d1ZXN0LWd1aWRlL3g4Ni9oeXBlcmNhbGwtYWJp
LnJzdAorKysgYi9kb2NzL2d1ZXN0LWd1aWRlL3g4Ni9oeXBlcmNhbGwtYWJp
LnJzdApAQCAtODIsNiArODIsMTMgQEAgVGhlIGh5cGVyY2FsbCBwYWdlIGlz
IGEgcGFnZSBvZiBndWVzdCBSQU0gaW50byB3aGljaCBYZW4gd2lsbCB3cml0
ZSBzdWl0YWJsZQogdHJhbnNmZXIgc3R1YnMuICBJdCBpcyBpbnRlbmRlZCBh
cyBhIGNvbnZlbmllbmNlIGZvciBndWVzdHMsIGJ1dCB1c2Ugb2YgdGhlCiBo
eXBlcmNhbGwgcGFnZSBpcyBub3QgbWFuZGF0b3J5IGZvciBtYWtpbmcgaHlw
ZXJjYWxscyB0byBYZW4uCiAKKy4uIG5vdGU6OgorCisgICBUaGVyZSBhcmUg
Y2FzZXMgd2hlcmUgYSBoeXBlcmNhbGwgcGFnZSBzaG91bGQgbm90IGJlIHVz
ZWQuICBJdCBjb250YWlucworICAgYGByZXRgYCBpbnN0cnVjdGlvbnMgd2hp
Y2ggYXJlIG5vdCBjb21wYXRpYmxlIHdpdGggY2VydGFpbiBzcGVjdWxhdGl2
ZQorICAgc2VjdXJpdHkgdGVjaG5pcXVlcywgYW5kIGl0IGRvZXMgbm90IGNv
bnRhaW4gYGBlbmRicmBgIGluc3RydWN0aW9ucyB3aGljaAorICAgYXJlIG5l
Y2Vzc2FyeSBmb3IgY2VydGFpbiBDb250cm9sLWZsb3cgSW50ZWdyaXR5IHNj
aGVtZXMuCisKIENyZWF0aW5nIGEgaHlwZXJjYWxsIHBhZ2UgaXMgYW4gaXNv
bGF0ZWQgb3BlcmF0aW9uIGZyb20gWGVuJ3MgcG9pbnQgb2Ygdmlldy4KIEl0
IGlzIHRoZSBndWVzdHMgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQg
dGhlIGh5cGVyY2FsbCBwYWdlLCBvbmNlCiB3cml0dGVuIGJ5IFhlbiwgaXMg
bWFwcGVkIHdpdGggZXhlY3V0YWJsZSBwZXJtaXNzaW9ucyBzbyBpdCBtYXkg
YmUgdXNlZC4K

--=separator--


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 12:42:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 12:42:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859076.1271223 (Exim 4.92)
	(envelope-from )
	id 1tNWu0-0002EZ-0z; Tue, 17 Dec 2024 12:42:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859076.1271223; Tue, 17 Dec 2024 12:42:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNWtz-0002ES-TN; Tue, 17 Dec 2024 12:42:15 +0000
Received: by outflank-mailman (input) for mailman id 859076;
 Tue, 17 Dec 2024 12:42:14 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1tNWty-0002EM-P4
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 12:42:14 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1tNWty-0082CS-0R;
 Tue, 17 Dec 2024 12:42:14 +0000
Received: from [89.27.170.32] (helo=[172.16.75.124])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1tNWty-00E4oT-0k;
 Tue, 17 Dec 2024 12:42: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" 
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=hxiQVjBSU1RtH1fXpA14/J9g3f4frsN07DrC7hrMxBo=; b=wHRLSwyAtS7ZKXxGodG4fr+rwj
	zDh6qwCEfVDOxs/HE3MiSgcOk3C45Ode/FXkD6TIrdpEQaOcgz+VG1fRkO/706+re2oc3SLkPM3Xq
	26zMKATpR8/R7UxdX9nH4YUbHFA6BybAYU9BtPqxGM5rwbFXN4n5d139F12HzVDNTEjQ=;
Message-ID: <4e437c60-4fee-40ed-9d2a-789bac0b36d9@xen.org>
Date: Tue, 17 Dec 2024 13:42:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
Content-Language: en-GB
To: Sergiy Kibrik , xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 "Daniel P. Smith" 
References: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
From: Julien Grall 
In-Reply-To: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Can you clarify why this is an RFC?

On 17/12/2024 11:47, Sergiy Kibrik wrote:
> Allow to build ARM configuration with support for initializing hardware domain.
> On ARM it is only possible to start hardware domain in multiboot mode, so
> dom0less support is required. This is reflected by dependency on DOM0LESS_BOOT
> instead of directly depending on ARM config option.

I am a bit confused with the explanation. We already have an hardware 
domain on Arm. It is dom0. So what are you trying to achieve? Is this 
remove some permissions from the hardware domain?

If so, why can't the hardware domain stay as dom0 and you remove the 
feature you don't want (e.g. control domain)?

Are you sure this patch is sufficient to use the late hwdom feature? 
Looking at the code, to enable the late hwdom, the user needs to provide 
a domid on the command line. But AFAICT, there is no way to provide a 
domain ID in the DOM0LESS case...

> 
> Signed-off-by: Sergiy Kibrik 
> ---
>   xen/common/Kconfig | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 90268d9249..7368ca8208 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -374,7 +374,7 @@ endchoice
>   config LATE_HWDOM
>   	bool "Dedicated hardware domain"
>   	default n
> -	depends on XSM && X86
> +	depends on XSM && (X86 || DOM0LESS_BOOT)

This will enable LATE_HWDOM for other arch. Is this what we want?

>   	help
>   	  Allows the creation of a dedicated hardware domain distinct from
>   	  domain 0 that manages devices without needing access to other

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 13:00:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 13:00:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859092.1271233 (Exim 4.92)
	(envelope-from )
	id 1tNXBb-0005DA-Ed; Tue, 17 Dec 2024 13:00:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859092.1271233; Tue, 17 Dec 2024 13:00: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 1tNXBb-0005D3-Bi; Tue, 17 Dec 2024 13:00:27 +0000
Received: by outflank-mailman (input) for mailman id 859092;
 Tue, 17 Dec 2024 13:00: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 1tNXBa-0005Cx-Lc
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 13:00:26 +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 e1141920-bc76-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 14:00:24 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-4361e89b6daso36854135e9.3
 for ; Tue, 17 Dec 2024 05:00: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-43625550563sm172103825e9.4.2024.12.17.05.00.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 05:00: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: e1141920-bc76-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734440423; x=1735045223; 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=x8qvu4o47wK/pytc4D/YTHNJcW8odwf9szi5sjyxz70=;
        b=BPUANYUGx3FiDbpNrsaIGyeLlP65LuBTRUsGH8s+BhRPmvqsvifJCLAWYxVQGs/di8
         9z+jnpsR5HJAsSV8DmGfZnrlB5mhzqnHMJshoOWvOj36/va95+owVzT3chXlADgNJ9i2
         N92vY7loG0Ja0SdqZRNajgj0UHr4eDQ7/bTHDjf3no46NIAjPudwPsIb+Nej4LfQ47xx
         rE4lpfgZQS/jle1lWZhJECrRsoRjOeIdldQwXHG+WG+wKFhufC9IjYLs8CmlqjIiyYn2
         s2d6vxA8bEbeIqFD0xAN8x9rQczBvrIiO9M7KARRGTsr3xb29c7XAKA1OGF/yAxjCi96
         cf6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734440423; x=1735045223;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=x8qvu4o47wK/pytc4D/YTHNJcW8odwf9szi5sjyxz70=;
        b=nHtS5vs1rwQdv6vsnCrBuSYsaIUMHykYiCuldpPlrSWE+gDR9MWt78woNFF/+7fDVK
         V2l/3rio9BCSu/h89/3QsdS85JhLCgprF+wJddgOyIlMfjksc9JgKuBICtUEn5B5XGbP
         4rSxpA8eZTK9//d7cve0sRAy+F3y7as/pii7PfNSXTw+TjMn7qN3gIN6JmH7MjzYytTd
         Bk2Eclc6CX1oduwlQMw7ciBFtLoiEExLH2jjyAfEHlpeYkHIzwsj7C5qIyyjqde7fJz2
         ZVD9tjFAh6k4OWYKxWdklWNkP9RGPOtTL7jHxAGcC3JWG+EcM/7GkPH2fep9St4cMaX7
         X7Og==
X-Forwarded-Encrypted: i=1; AJvYcCU+MFQvUfLYP0kLLGiR9qrNwdnGLjzUhHsVvIWbLU7dYzFf1iHAy3iW+RQxYi8ugb9vERQ1RI5r9dw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyu9U1uBLzviumfuGpVGb2mEWPYzgcHNt41T9PgqM9aC1f/Lhkf
	61K1GjW97Wk6S8L/lJ3fz0vGI58BHTjzac7JrJxLX5eBGRZdFO/HztRfF6D0Mg==
X-Gm-Gg: ASbGncvkOPW3Vq+LMDULNDGpVicv9xIOR876dbs2JroRa5mH8eLcaLiXFDIrDrkHTMj
	Ppm11CYVYTVNnfFTeNpOsrYUDNeMOXBRZ62hTVHq01VIQFddqRfbxdW8nrOAQNXyTD7F8G1mWgI
	E1NnBzOaATZsyYPeeBwkW2tRknbrtp1u1LPAObuVmRZlxD8flNc6GG83n+MdqBwumsBBrVNbmkM
	/RxGHmakigRVjgkaLxrpHB+vOH1xmyRh52DTT2eFY149e2SZKbn62gQLg9cw+eOH+Vi3weD5A/J
	X/AC32O3DSG3mkkjAJga4BHYrkoDySDT/q3DPDctrQ==
X-Google-Smtp-Source: AGHT+IGaC/QwC0kiOXCCN4qTrSsBt1V9zmm/0t6K2VNXvFsxgObj0RXZ9cMvJXHmM2VAKhZSIFt2eQ==
X-Received: by 2002:a05:600c:1da9:b0:434:9936:c823 with SMTP id 5b1f17b1804b1-4362aa3e32bmr159564375e9.18.1734440423517;
        Tue, 17 Dec 2024 05:00:23 -0800 (PST)
Message-ID: <4ef8626a-0ff9-4c02-a1bf-72e39b950e8a@suse.com>
Date: Tue, 17 Dec 2024 14:00:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v1] arm: introduce kconfig options to disable
 hypercalls
To: Sergiy Kibrik 
Cc: Stefano Stabellini ,
 Julien Grall , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241216114358.2845447-1-Sergiy_Kibrik@epam.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: <20241216114358.2845447-1-Sergiy_Kibrik@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16.12.2024 12:43, Sergiy Kibrik wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -516,4 +516,31 @@ config TRACEBUFFER
>  	  to be collected at run time for debugging or performance analysis.
>  	  Memory and execution overhead when not active is minimal.
>  
> +menu "Supported hypercall interfaces"
> +	visible if DOM0LESS_BOOT && EXPERT
> +
> +config SYSCTL
> +	bool "Enable sysctl hypercall"
> +	default y
> +
> +config DOMCTL
> +	bool "Enable domctl hypercalls"
> +	default y
> +
> +config HVM_OP
> +	bool "Enable HVM hypercalls"
> +	depends on HVM
> +	default y
> +
> +config PLATFORM_HYP
> +	bool "Enable platform hypercalls"
> +	depends on !PV_SHIM_EXCLUSIVE

Any reason you don't do the shim related conversion also for domctl and
sysctl?

Much like you have HVM_OP, may I suggest PLATFORM_OP here and ...

> +	default y
> +
> +config PHYSDEVOP
> +	bool "Enable physdev hypercall"
> +	default y

... PHYSDEV_OP here?

> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1053,7 +1053,9 @@ int domain_kill(struct domain *d)
>          d->is_dying = DOMDYING_dying;
>          rspin_barrier(&d->domain_lock);
>          argo_destroy(d);
> +#ifdef CONFIG_DOMCTL
>          vnuma_destroy(d->vnuma);
> +#endif

There is a stub already for this, just that right now it's shim-specific.

> --- a/xen/include/hypercall-defs.c
> +++ b/xen/include/hypercall-defs.c
> @@ -234,7 +234,7 @@ stack_switch                       do:2     do:2     -        -        -
>  set_callbacks                      compat   do       -        -        -
>  fpu_taskswitch                     do       do       -        -        -
>  sched_op_compat                    do       do       -        -        dep
> -#ifndef CONFIG_PV_SHIM_EXCLUSIVE
> +#if defined(CONFIG_PLATFORM_HYP)

Nit: Why not #ifdef, like it was, and like you have it ...

> @@ -247,7 +247,9 @@ set_timer_op                       compat   do       compat   do       -
>  event_channel_op_compat            do       do       -        -        dep
>  xen_version                        do       do       do       do       do
>  console_io                         do       do       do       do       do
> +#ifdef CONFIG_PHYSDEV
>  physdev_op_compat                  compat   do       -        -        dep
> +#endif
>  #if defined(CONFIG_GRANT_TABLE)
>  grant_table_op                     compat   do       hvm      hvm      do
>  #elif defined(CONFIG_PV_SHIM)
> @@ -269,14 +271,20 @@ callback_op                        compat   do       -        -        -
>  xenoprof_op                        compat   do       -        -        -
>  #endif
>  event_channel_op                   do       do       do:1     do:1     do:1
> +#ifdef CONFIG_PHYSDEVOP
>  physdev_op                         compat   do       hvm      hvm      do_arm
> -#ifdef CONFIG_HVM
> +#endif
> +#ifdef CONFIG_HVM_OP
>  hvm_op                             do       do       do       do       do
>  #endif
>  #ifndef CONFIG_PV_SHIM_EXCLUSIVE
> +#ifdef CONFIG_SYSCTL
>  sysctl                             do       do       do       do       do
> +#endif
> +#ifdef CONFIG_DOMCTL
>  domctl                             do       do       do       do       do
>  #endif
> +#endif
>  #ifdef CONFIG_KEXEC
>  kexec_op                           compat   do       -        -        -
>  #endif
> @@ -293,7 +301,9 @@ hypfs_op                           do       do       do       do       do
>  #endif
>  mca                                do       do       -        -        -
>  #ifndef CONFIG_PV_SHIM_EXCLUSIVE
> +#ifdef CONFIG_DOMCTL
>  paging_domctl_cont                 do       do       do       do       -
>  #endif
> +#endif

... everywhere else?

> --- a/xen/include/xen/hypercall.h
> +++ b/xen/include/xen/hypercall.h
> @@ -24,6 +24,18 @@
>  /* Needs to be after asm/hypercall.h. */
>  #include 
>  
> +#if !defined(CONFIG_DOMCTL) && !defined(CONFIG_DOM0LESS_BOOT)
> +#error "domctl and dom0less can't be disabled simultaneously"
> +#endif
> +
> +#if !defined(CONFIG_PHYSDEVOP) && !defined(CONFIG_DOM0LESS_BOOT)
> +#error "physdevop and dom0less can't be disabled simultaneously"
> +#endif
> +
> +#if !defined(CONFIG_SYSCTL) && !defined(CONFIG_DOM0LESS_BOOT)
> +#error "sysctl and dom0less can't be disabled simultaneously"
> +#endif

I'm puzzled by this: It covers only 3 of the 5, and it really only
re-checks what Kconfig already enforces.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 13:02:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 13:02:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859099.1271243 (Exim 4.92)
	(envelope-from )
	id 1tNXDu-0005l7-Rj; Tue, 17 Dec 2024 13:02:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859099.1271243; Tue, 17 Dec 2024 13:02: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 1tNXDu-0005l0-Ou; Tue, 17 Dec 2024 13:02:50 +0000
Received: by outflank-mailman (input) for mailman id 859099;
 Tue, 17 Dec 2024 13:02: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 1tNXDu-0005ks-41
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 13:02:50 +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 36fbe1ca-bc77-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 14:02:48 +0100 (CET)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-385d7f19f20so2652166f8f.1
 for ; Tue, 17 Dec 2024 05:02:48 -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-388c804d573sm10991914f8f.64.2024.12.17.05.02.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 05:02: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: 36fbe1ca-bc77-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734440568; x=1735045368; 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=7FBOKs1vwKmgkMl368FToP1FVr+qWeiLCajGPVa87uY=;
        b=e9fZ20SiGZBfYVQU5/6AbS/652GEHvuSHnGqPJW8fzNxqBkHbGZCZMxumbcOdNMj6k
         BVeA4FOEqaYr+39Ay+TzvYqBnNcFb4YlcEf2t8oAm8F0SEmpBlVTKS10sQwF8/Qfrjju
         JjF4ziogW4x7QthECyJXbdil2Y8W7bihE6heKTWHm+kGJlHiY41xr4fqfG76tM+61oKD
         Y8muyNlLsxkYfntdv259dnInVCakTAvP2BCRvKTvNug4tcyYTRdpRO5ghF2in6TW/xil
         yJlIR7pmbZuFP+Z+nFYizqyi3Uu3Oi0fV8L/FBK2dMgcnRi6BIkVsEyupdH+MIsndmbo
         XlJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734440568; x=1735045368;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=7FBOKs1vwKmgkMl368FToP1FVr+qWeiLCajGPVa87uY=;
        b=Z1bN4n7wNhtQTFAG0LzmRTWINxe42IkPayJ5wsno69UQ3sO/zYjApS/c5Rzu2ktNGo
         9S/o4lzFYK4zeyaGBZtE+oRMSst199GwPE8ykD4ItWMZhbQkmc/9HPEjiNEBfpfPHnqC
         uIImPb4JUBzhpcwYG6ljmZRu0o008oLluEkkDkTR1NE/egJkbIGy0NfeCmLxLwDGmT6O
         De54UchQ7/h4NuQC6Lwj4TOoRqKXUjbPHAv7ETg0u7OgMZa1TRnhoEDY6RWCIwdIw5xG
         w3Bzjm+2br5blRUYj8R1XdRuoTRiA54+Hxb5S+bvnsDlPhw3V+r478DfhqOr7c/4ECtp
         4JIQ==
X-Forwarded-Encrypted: i=1; AJvYcCWjA4C74lRAZnio9GKywkzQO3FQWGxrRfplxy/8AUR2BhtAGtnvUFtw0vHngdPgZMvpGwaZxDxpD44=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwjftrLCE6LA6TEQBKjcqrd08fejhxcNaTzEVXMTdrX3YN1PNNG
	xCqBV56InuWP6Bu6bBXk5lLw/nImjQJI7J6PuorhlEBb6SIw4FVeH7PFvwf2Qg==
X-Gm-Gg: ASbGncvxbMbCyaZXVcJ5aobqQs6UUbkBjwczZm0QBzslYh0MuzePIb/9tinY2e8Tqob
	0ICOkXvQ6v0LobCi9QAS812343klkcE0/sbiQ94g7AqV8tDI6grQ/85ikZGMqmQ0uMlJDocvoeV
	3tE6WQve4roCLONmVSbJA83agiciAuggmy24Rbw34g2rHzh9vAU8jnc83xRELyLtGbq/xjIdDLF
	2QNIfn6hGTEp+zIozf8cVuZv5Z5F00N1/WzO9ziWAMLlTPB3m2j4pItXwWOvt2YtIddWRQ56kdu
	pEAJVYnx9lAjc1+8FMTq8WeShZ195NSAF++CywQM3A==
X-Google-Smtp-Source: AGHT+IE7kKCjE+juJl70Fi2bSM4TW/DaJzGvutodi9e/4GxjmOLrdeftoOLuGr0Jx5sbZmuPyDYHnQ==
X-Received: by 2002:a05:6000:400b:b0:385:e30a:e0f7 with SMTP id ffacd0b85a97d-388da3940c6mr2973669f8f.22.1734440567346;
        Tue, 17 Dec 2024 05:02:47 -0800 (PST)
Message-ID: <9003a677-e78b-4cf8-b890-c6cf432d5837@suse.com>
Date: Tue, 17 Dec 2024 14:02:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
To: Sergiy Kibrik 
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: <20241217114719.2870676-1-Sergiy_Kibrik@epam.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: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.12.2024 12:47, Sergiy Kibrik wrote:
> Allow to build ARM configuration with support for initializing hardware domain.
> On ARM it is only possible to start hardware domain in multiboot mode, so
> dom0less support is required.

I don't follow this. Late hwdom is supposed to be started by a (minimal)
toolstack iirc.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 13:03:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 13:03:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859105.1271253 (Exim 4.92)
	(envelope-from )
	id 1tNXEz-0006Mk-4w; Tue, 17 Dec 2024 13:03:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859105.1271253; Tue, 17 Dec 2024 13:03: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 1tNXEz-0006Md-1P; Tue, 17 Dec 2024 13:03:57 +0000
Received: by outflank-mailman (input) for mailman id 859105;
 Tue, 17 Dec 2024 13:03: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 1tNXEx-0006MV-NX
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 13:03:55 +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 5e159de7-bc77-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 14:03:53 +0100 (CET)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-38789e5b6a7so2764944f8f.1
 for ; Tue, 17 Dec 2024 05:03: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-4362571765dsm172671005e9.39.2024.12.17.05.03.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 05:03: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: 5e159de7-bc77-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734440633; x=1735045433; 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=0Tx//nhSsC/rjBSOwoSPe589fRi2I/odBiAKV3gjhWE=;
        b=VpKuZIb3Bdhw5xRw1ljCqSPoTLOAPg+20B7AKn1HAiAN6Gt8gJSTreY2MZcyjiuVqo
         KOGfrOkTaTVhaZQwEIUf87Q5XU5U3+ElDKV3oLhl5B3isM3up5zGhrUP1hGE8UZ59u20
         5IWsLbTUPECehPuVP0wDWOtjDfY/LLlXvOL5Zi75DC2sd/vPdliBYEgZvrS8Gdk3cg1K
         blXzkT3fYw1N9FBOzsSQXKgqhNp6QoC12qjwh5Z5g42FtSAGjRbTPgfuaSlmViwhjSjz
         pUz+YjaSWAuMPzF9dw7G0MdF1xwx0spOac7zMAHkMWL4AZc9609knKP2/z7pbhOGUx6a
         n7tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734440633; x=1735045433;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=0Tx//nhSsC/rjBSOwoSPe589fRi2I/odBiAKV3gjhWE=;
        b=RphqrRND5uKWpkZlcFt5kcBm85BxLF+dUmeOthIhT7s0LDHGIEJIur89IAOU4m3NKm
         LAEtnt6h8UR4MLdwlzK/CrQoy7i0qaatvst7lGNIDh55rxMDt7dAx1VEd7h6TGDtoZ9m
         IRyMDzZyHnZQjloZI3u4LnvQZbKVcE4F225X+UBbBNqw0XP8FVDTc1eI3sdV4DCyuNl0
         UeAZiNXCgZaGr3dhNfdt/MjMxIsq6IAo3sPq6meSpdkYXf3WJfptyiVKL/oO9/QKrH6f
         +ZK9YiJxuvh+EFRHD39xlUObC4+YSue2zkBORPO5uApsRaqNwMW238Ii7gAYjaZbHthG
         e6Yw==
X-Forwarded-Encrypted: i=1; AJvYcCU0Yw8z8GkFC8lQJhGXP/F1n/GB7pkLrgJUG4v5gmj3SPl3dNd2viskRuOcVwxOyUzyiYbQzYqVTro=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwlWNLgxn/2BeLeTBtxGLEzrjMsddXxkRQZcjJqj2DJGrMJo+9J
	j6Dlzwyln2tVe6Q3I6xnawWPwVexgX9PypPYh8HMgAU0Iz4R4lKlmmDHfCOHjQ==
X-Gm-Gg: ASbGncvanKJEeTdrI2Jvh7yeuuS4Apou0nG6+Uus9sDszsF+t9XjyOCOkAaJqQS03Lp
	Z1Ctdsg8fR6SgknpGN581BcOcbZ/skaYcwyA+fYUaJFUHKb6afO/b5ZUar7s+tM/zXa/VlkXMTN
	7LLX3/ai/elgShgprkA6bz5k9GYdsMZfs7+A/jjJWj2drLhGUMIyti/4CZ0JN3VGF86Bk5ff2a8
	tcHkw3FWb4RArivPjQt8TtB5KehrKt36TS1ogOPhvaI7S8BLLS68b/SBTV2Zf9fkIdWg+c1UHYV
	zGkjfpbVVFRXgWgiqjFiMXGZgUOFZXsddN44W2TvwA==
X-Google-Smtp-Source: AGHT+IHPatGOwWRL7lQpVHYNQnI8RaSAJ71c693f+a3fXtP3DQJn/Wkbu823noYe0epWqTTa/RxnPA==
X-Received: by 2002:a05:6000:4710:b0:386:1cd3:8a0b with SMTP id ffacd0b85a97d-3888dcd467fmr12717208f8f.17.1734440633267;
        Tue, 17 Dec 2024 05:03:53 -0800 (PST)
Message-ID: <452794f6-e02c-4dcc-bca4-2147a0cfb512@suse.com>
Date: Tue, 17 Dec 2024 14:03:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 2/5] xen: add bitmap to indicate per-domain state
 changes
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
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: <20241217111247.2204-1-jgross@suse.com>
 <20241217111247.2204-3-jgross@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 17.12.2024 12:59, Jürgen Groß wrote:
> On 17.12.24 12:30, Jan Beulich wrote:
>> On 17.12.2024 12:12, Juergen Gross wrote:
>>> V4:
>>> - add __read_mostly (Jan Beulich)
>>> - use __set_biz() (Jan Beulich)
>>> - fix error handling in evtchn_bind_virq() (Jan Beulich)
>>
>> I'm sorry, I should have spotted a 2nd issue already when reviewing v3 (or
>> even an earlier version).
>>
>>> @@ -138,6 +139,60 @@ bool __read_mostly vmtrace_available;
>>>   
>>>   bool __read_mostly vpmu_is_available;
>>>   
>>> +static DEFINE_SPINLOCK(dom_state_changed_lock);
>>> +static unsigned long *__read_mostly dom_state_changed;
>>> +
>>> +int domain_init_states(void)
>>> +{
>>> +    const struct domain *d;
>>> +    int rc = -ENOMEM;
>>> +
>>> +    spin_lock(&dom_state_changed_lock);
>>> +
>>> +    if ( dom_state_changed )
>>> +        bitmap_zero(dom_state_changed, DOMID_FIRST_RESERVED);
>>
>> This needs to not happen when ...
>>
>>> @@ -485,11 +486,21 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
>>>       if ( (v = domain_vcpu(d, vcpu)) == NULL )
>>>           return -ENOENT;
>>>   
>>> +    if ( virq == VIRQ_DOM_EXC )
>>> +    {
>>> +        rc = domain_init_states();
>>> +        if ( rc )
>>> +            return rc;
>>> +
>>> +        deinit_if_err = true;
>>> +    }
>>> +
>>>       write_lock(&d->event_lock);
>>>   
>>>       if ( read_atomic(&v->virq_to_evtchn[virq]) )
>>>       {
>>>           rc = -EEXIST;
>>> +        deinit_if_err = false;
>>>           gdprintk(XENLOG_WARNING, "EVTCHNOP failure: error %d\n", rc);
>>>           goto out;
>>>       }
>>
>> ... we take this error path. Which I think calls for moving the
>> domain_init_states() invocation ...
>>
>>> @@ -527,6 +538,9 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
>>>    out:
>>>       write_unlock(&d->event_lock);
>>>   
>>> +    if ( rc && deinit_if_err )
>>> +        domain_deinit_states();
>>> +
>>>       return rc;
>>>   }
>>
>> ... somewhere here. It really doesn't need doing early, as the caller
>> may assume the bitmap was set up only when this hypercall returns
>> successfully.
> 
> OTOH this will require undoing the binding of the virq in case of an
> error returned by domain_init_states().
> 
> It would probably be best to place the call of domain_init_states()
> after the -EEXIST case.

Hmm, right.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 13:22:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 13:22:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859128.1271267 (Exim 4.92)
	(envelope-from )
	id 1tNXWO-0000wH-Dq; Tue, 17 Dec 2024 13:21:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859128.1271267; Tue, 17 Dec 2024 13: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 1tNXWO-0000wA-Aj; Tue, 17 Dec 2024 13:21:56 +0000
Received: by outflank-mailman (input) for mailman id 859128;
 Tue, 17 Dec 2024 13:21: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 1tNXWM-0000w4-EF
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 13:21:54 +0000
Received: from mail179-16.suw41.mandrillapp.com
 (mail179-16.suw41.mandrillapp.com [198.2.179.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e0cc4649-bc79-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 14:21:52 +0100 (CET)
Received: from pmta12.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail179-16.suw41.mandrillapp.com (Mailchimp) with ESMTP id
 4YCHXH3HbPzB5pL2L
 for ; Tue, 17 Dec 2024 13:21:51 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 650f076e19e44eb5947ea701a3f246be; Tue, 17 Dec 2024 13:21:51 +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: e0cc4649-bc79-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1734441711; x=1734702211;
	bh=rYIwv/TK1wI4Tb+V65fQt+ZmbiUsozT8p/Au4/qBMXs=;
	h=From:Subject:Message-Id:To:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=MH2Gd92OwhO5fCDZ0X4ZpU8x0bl7q3OcX0g/4KKHFCGX9VZspl05klEncvFPf2OVt
	 ZT6ai5mX/MBoEzdPlMrAHDF+Sp80bIFI2hLdKpV5g0G5ASr9RJ2bvvSxEfYahRaFFB
	 mwI2sew+Om+e4vQtkfdZUawK4MXLY4e0MLZWBynAz8hoq1kqKWBXMF7lE9wq6E0551
	 1qDL61Nrgod+k7FAjjp2W6FQuvhHCaG9u8iW3iLBrudX7zYex8xVZgmmgf9Mx68JTC
	 jQg/WcaTXiWmZrBg+SkJgLFOHUpIK37APkkNv3mrOVC4813KmOiLTo77e9rF213WAv
	 WVtx1DUC8BCYg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1734441711; x=1734702211; i=teddy.astie@vates.tech;
	bh=rYIwv/TK1wI4Tb+V65fQt+ZmbiUsozT8p/Au4/qBMXs=;
	h=From:Subject:Message-Id:To:References:In-Reply-To:Feedback-ID:
	 Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date:
	 Subject:From;
	b=ae223K+UN2eiUe68D0IqTl0zL4aQ1BNP+El6KwOg4c2aJBdqHbMjKN8rKWDMkKIId
	 /dTc/FV2OjMhA/ofizPA82INOZ+JZDTTnc4Vcg7WU8T4MotHYvVfdlkGcldiUUZk7y
	 T72ntZk0D0JdwpNh1o3lhSTei2gQ6+ugLrgAlelixNq27WNCMX7zvTnIppTsUroT3r
	 R5drZGgZU6CalXFP3KbbWNMrvZ4Z8WWmGFminWzDMkFRm5Am8nLVy/uiPStbsmGm6m
	 ZqJ6J0d0qNSiccbsGwULYVn4RxNMZZZ1BooJ1/0YJPJKLeMCq78LFwwbaxqZ9Asyxh
	 hSK3hNfs417BQ==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20Xen=20Security=20Advisory=20466=20v3=20(CVE-2024-53241)=20-=20Xen=20hypercall=20page=20unsafe=20against=20speculative=20attacks?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1734441710814
Message-Id: <96775ba9-19c6-4467-848a-5b4625c70583@vates.tech>
To: xen-devel@lists.xenproject.org
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.650f076e19e44eb5947ea701a3f246be?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20241217:md
Date: Tue, 17 Dec 2024 13:21:51 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello,

Le 17/12/2024 =C3=A0 13:18, Xen.org security team a =C3=A9crit :
> Xen guests need to use different processor instructions to make explicit
> calls into the Xen hypervisor depending on guest type and/or CPU
> vendor. In order to hide those differences, the hypervisor can fill a
> hypercall page with the needed instruction sequences, allowing the guest
> operating system to call into the hypercall page instead of having to
> choose the correct instructions.
> 
> The hypercall page contains whole functions, which are written by the
> hypervisor and executed by the guest. With the lack of an interface
> between the guest OS and the hypervisor specifying how a potential
> modification of those functions should look like, the Xen hypervisor has
> no knowledge how any potential mitigation should look like or which
> hardening features should be put into place.
> 

Should we consider adding a interface to know how to the guest is 
supposed to make hypercalls (what hypercall instruction/flavor) ? Such 
as the guest can have its own hypercall implementations but knows which 
one to use.

> This results in potential vulnerabilities if the guest OS is using any
> speculative mitigation that performs a compiler transform on "ret"
> instructions in order to work (e.g. the Linux kernel rethunk or safe-ret
> mitigations).
> 
> Furthermore, the hypercall page has no provision for Control-flow
> Integrity schemes (e.g. kCFI/CET-IBT/FineIBT), and will simply
> malfunction in such configurations.
> 
> IMPACT
> =3D=3D=3D=3D=3D=3D
> 
> Some mitigations for hardware vulnerabilities the guest OS is relying on =
to
> work might not be fully functional, resulting in e.g. guest user processe=
s
> being able to read data they ought not have access to.
> 
> VULNERABLE SYSTEMS
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 
> Only x86 systems are potentially vulnerable, Arm systems are not vulnerab=
le.
> 
> All guest types (PV, PVH and HVM) are potentially vulnerable.
> 
> Linux guests are known to be vulnerable, guests using other operating
> systems might be vulnerable, too.
> 
> MITIGATION
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 
> Running only Linux guest kernels not relying on "ret" assembler instructi=
on
> patching (kernel config option CONFIG_MITIGATION_RETHUNK/CONFIG_RETHUNK
> disabled) will avoid the vulnerability, as long as this option isn't
> required to be safe on the underlying hardware.
> 
> CREDITS
> =3D=3D=3D=3D=3D=3D=3D
> 
> This issue was discovered by Andrew Cooper of XenServer.
> 
> RESOLUTION
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 
> Applying the set of attached patches resolves this issue.
> 
> The patch to Xen is simply a documentation update to clarify that an OS a=
uthor
> might not want to use a hypercall page.
> 
> xsa466-linux-*.patch    Linux
> xsa466-xen.patch        xen-unstable
> 
> $ sha256sum xsa466*
> 498fb2538f650d694bbd6b7d2333dcf9a12d0bdfcba65257a7d14c88f5b86801  xsa466-=
linux-01.patch
> 1e0d5f68d1cb4a0ef8914ae6bdeb4e18bae94c6d19659708ad707da784c0aa5c  xsa466-=
linux-02.patch
> b3056b34c1565f901cb4ba11c03a51d4f045b5de7cd16c6e510e0bcee8cc6cd7  xsa466-=
linux-03.patch
> 0215e56739ab5b0d0ec0125f3d1806c3a0a0dcb3f562014f59b5145184a41467  xsa466-=
linux-04.patch
> 314e67060ab4f47883cf2b124d54ce3cd4b0363f0545ad907a7b754a4405aacd  xsa466-=
linux-05.patch
> adbef75416379d96ebb72463872f993e9d8b7d119091480ad1e70fd448481733  xsa466-=
linux-06.patch
> 36874014cee5d5213610a6ffdd0e3e67d0258d28f2587b8470fdd0cef96e5013  xsa466-=
linux-07.patch
> 367f981ef8adc11b99cc6999b784305bcdcd55db0358fd6a2171509bf7f64345  xsa466-=
xen.patch
> $
> 
> DEPLOYMENT DURING EMBARGO
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
> 
> Deployment of patches or mitigations is NOT permitted (except where
> all the affected systems and VMs are administered and used only by
> organisations which are members of the Xen Project Security Issues
> Predisclosure List).  Specifically, deployment on public cloud systems
> is NOT permitted.
> 
> This is because the mitigation or patches need to be applied to the guest=
s.
> 
> Deployment is permitted only AFTER the embargo ends.
> 
> (Note: this during-embargo deployment notice is retained in
> post-embargo publicly released Xen Project advisories, even though it
> is then no longer applicable.  This is to enable the community to have
> oversight of the Xen Project Security Team's decisionmaking.)
> 
> For more information about permissible uses of embargoed information,
> consult the Xen Project community's agreed Security Policy:
>    http://www.xenproject.org/security-policy.html


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 13:24:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 13:24:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859135.1271277 (Exim 4.92)
	(envelope-from )
	id 1tNXYy-0001We-Qp; Tue, 17 Dec 2024 13:24:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859135.1271277; Tue, 17 Dec 2024 13:24:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNXYy-0001WX-N6; Tue, 17 Dec 2024 13:24:36 +0000
Received: by outflank-mailman (input) for mailman id 859135;
 Tue, 17 Dec 2024 13:24: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 1tNXYw-0001WN-Vl
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 13:24:35 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3fabdf2e-bc7a-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 14:24:32 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 17 Dec 2024 14:24:30 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 3fabdf2e-bc7a-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734441872; x=1765977872;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=ZyXk/w6y7ozH21PqsR1QHKdKBhbv+9EmZViDXilyPrs=;
  b=JLkm2as8vUTY2Jx/ExnOVCg05y5axdtedY5H2AOz1aruxw41F4QBsnOV
   gnl4g10Dq2/0W8Y1qcFMQIMrrUXPB5EL+2x24t4aqm6qhUmMZnnyiE6AC
   qM0RD53sPs48f8Xd92il/K3d7h9g2z5yrr+4B1OxdHjKNsl+6FAQdVusm
   g=;
X-CSE-ConnectionGUID: AloIgMv7QPik1gFWDtDlrg==
X-CSE-MsgGUID: XkJt4LddRyOi8d6RFuqrQQ==
X-IronPort-AV: E=Sophos;i="6.12,241,1728943200"; 
   d="scan'208";a="28218447"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"
X-Forward: 149.5.228.1
References: <20241215154659.151158-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216235241.217642-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216235241.217642-2-Ariel.Otilibili-Anieli@eurecom.fr> 
Date: Tue, 17 Dec 2024 14:24:30 +0100
Cc: "Anthony PERARD" , xen-devel@lists.xenproject.org
To: "Jan Beulich" 
MIME-Version: 1.0
Message-ID: <2f7a89-67617b80-bf75-70827e80@196856502>
Subject: =?utf-8?q?Re=3A?= [PATCH v2 1/1] =?utf-8?q?tools/libacpi=3A?= clear ASL 
 warning about PCI0
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 4835

On Tuesday, December 17, 2024 10:29 CET, Jan Beulich  wrote:

> On 17.12.2024 00:50, Ariel Otilibili wrote:
> > iasl complains =5FHID and =5FADR cannot be used at the same time:
> >=20
> > ```
> > /usr/bin/iasl -vs -p tools/firmware/hvmloader/dsdt=5Fanycpu.tmp -tc=
 tools/firmware/hvmloader/dsdt=5Fanycpu.asl 2>&1 | grep -B10 HID
> >=20
> > tools/firmware/hvmloader/dsdt=5Fanycpu.asl     40:        Device (P=
CI0)
> > Warning  3073 -                                    Multiple types ^=
  (Device object requires either a =5FHID or =5FADR, but not both)
> > ```
> >=20
> > Per ACPI 2.0 (Jul. 27, 2000; Section 6.1, page 146), the configurat=
ion was legit:
> >=20
> > "A device object must contain either an =5FHID object or an =5FADR =
object,
> > but can contain both." [1]
> >=20
> > But, per ACPI 6.5 (Aug. 2022), this is no more legit:
> >=20
> > "A device object must contain either an =5FHID object or an =5FADR =
object,
> > but must not contain both." [2]
> >=20
> > Generally =5FHID devices are enumerated and have their drivers load=
ed
> > by ACPI ("ASL 2.0 Introduction and Overview", page 4).
> >=20
> > Removing =5FADR, the warning is cleared out.
> >=20
> > The change should be compatible down to OSes released after ACPI 2.=
0,
> > including Windows XP:
>=20
> So my earlier hint apparently wasn't clear enough. I really would hav=
e
> expected you to determine in what version the wording changed. Even 5=
.1
> still has the old wording, and that's more than 10 years newer than 2=
.0.
> And then in 6.0 the wording first changed to "but should not contain
> both."

I can do that, Jan; I'll research from where did the wording changed.
>=20
> With this I'm afraid considering just WinXP is insufficient. May I al=
so
> point you at a Win2K related comment in acpi=5Fbuild=5Ftables(), seem=
ingly
> suggesting that that still was a "ACPI 1.0 operating system"? Further
> in that function you'll find that apparently, besides the 1.0 special
> case, we only support ACPI revisions 4 and 5. Therefore the spec chan=
ge
> in v6 would become relevant only once we actually supported (and
> surfaced to guests) v6. At that point I'd further be of the opinion t=
hat
> unless it can be proven that =5FADR is unused by any OS we (ever) car=
e(d)
> about, we'd need to further split the set of DSDTs we may make use of=
.
> One (pair) for up to 5.x with =5FADR present, and another (pair) for =
6.0
> and newer with =5FADR absent.

Let me look into acpi=5Fbuild=5Ftables(). Thanks for the hints.
>=20
> I'm further afraid that ...
>=20
> > 1. The =5FHID kept in the DSDT files is the EISA ID "PNP0A03",
> > Microsoft recognizes it as PCI bus:
> >=20
> > ```
> > $ curl -k -s https://download.microsoft.com/download/1/6/1/161ba512=
-40e2-4cc9-843a-923143f3456c/devids.txt | grep PNP0A
> >=20
> > PNP0A00         ISA Bus
> > PNP0A01         EISA Bus
> > PNP0A02         MCA Bus
> > PNP0A03         PCI Bus
> > PNP0A04         VESA/VL Bus
> > PNP0A05         Generic ACPI Bus
> > PNP0A06         Generic ACPI Extended-IO Bus (EIO bus)
> > ```
> >=20
> > 2. Linux 6.12 uses also =5FHID for identifying PCI devices [3]:
>=20
> ... this fact alone means very little here. The more important questi=
on is
> whether there are / were OSes which use(d) =5FADR for any purpose eve=
n when
> =5FHID is there. With just looking at the surface of just Linux, I fi=
nd e.g.
> a library-like function acpi=5Fget=5Flocal=5Fu64=5Faddress(), all use=
rs of which
> would need auditing. Plus, once done, we'd then still only know the s=
tate
> of things in one specific Linux version.
>=20
> Bottom line: I wonder whether iasl has an option to suppress that war=
ning.
> Sadly I can't find a new enough iasl anywhere on the systems I have e=
asy
> access to, so I can't check myself. If there was no way to suppress t=
his
> warning, I'd wonder whether this wasn't a shortcoming of the tool, as=
 the
> warning is clearly inappropriate when dealing with tables for pre-v6
> configurations.

There are flags to remove warnings:

```
$ iasl -h | grep -i warn
Errors, Warnings, and Remarks:
  -va                 Disable all errors/warnings/remarks
  -ve                 Report only errors (ignore warnings and remarks)
  -vi                 Less verbose errors and warnings for use with IDE=
s
  -vw      Ignore specific error, warning or remark
  -vx      Expect a specific warning, remark, or error
  -w <1|2|3>          Set warning reporting level
  -we                 Report warnings as errors
  -ww      Report specific warning or remark as error

$ iasl -v=20

Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20240927
Copyright (c) 2000 - 2023 Intel Corporation
```

I am keeping you posted; I am compiling with warnings disabled.
Ariel
>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 13:26:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 13:26:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859144.1271287 (Exim 4.92)
	(envelope-from )
	id 1tNXaW-0002EU-38; Tue, 17 Dec 2024 13:26:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859144.1271287; Tue, 17 Dec 2024 13:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNXaW-0002EN-01; Tue, 17 Dec 2024 13:26:12 +0000
Received: by outflank-mailman (input) for mailman id 859144;
 Tue, 17 Dec 2024 13:26: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 1tNXaV-0002EH-42
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 13:26:11 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7a775f9f-bc7a-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 14:26:10 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 17 Dec 2024 14:26:09 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 7a775f9f-bc7a-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734441970; x=1765977970;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=Njae+Vsl2XA1tfc//Ve7NVHONOq0L0Ei91adjZe8SbI=;
  b=k2Rav9JCeHPEOrJjKzxG2UOBNLPcnQOlWYyW5W8R3K3MJTxmTorePz1S
   Dkhv5Y0caOg7+mWfP7bfoO4F0D5AD19xkOJEkWTD7jIIRrwjLUGNU/PjV
   /adhByegYpYhtzWxWssmmgUqW54b98tV174sO7sS8HniSyC8h/L2UemYY
   k=;
X-CSE-ConnectionGUID: 4bbj8gOQS0aw8yPq5Idi+g==
X-CSE-MsgGUID: OnzP+206QKm1NpThvlUmvg==
X-IronPort-AV: E=Sophos;i="6.12,241,1728943200"; 
   d="scan'208";a="28218467"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"
X-Forward: 149.5.228.1
References: <20241214161350.70515-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216231128.211648-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216231128.211648-2-Ariel.Otilibili-Anieli@eurecom.fr> 
Date: Tue, 17 Dec 2024 14:26:09 +0100
Cc: =?utf-8?q?xen-devel=40lists=2Exenproject=2Eorg?= , "Jan Beulich" , "Anthony PERARD" , "Andrew Cooper" 
To: "Luca Fancellu" 
MIME-Version: 1.0
Message-ID: <2f7a88-67617c00-f1a5-208cdcc@55733305>
Subject: =?utf-8?q?Re=3A?= [PATCH v2 1/1] =?utf-8?q?tools=2C?=
 =?utf-8?q?_xen/scripts=3A?= clear out Python syntax warnings
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 1406

On Tuesday, December 17, 2024 09:31 CET, Luca Fancellu  wrote:

> Hi Ariel,
>=20
> > On 16 Dec 2024, at 23:07, Ariel Otilibili  wrote:
> >=20
> > * since 3.12 invalid escape sequences generate SyntaxWarning
> > * in the future, these invalid sequences will generate SyntaxError
> > * therefore changed syntax to raw string notation.
> >=20
> > Link: https://docs.python.org/3/whatsnew/3.12.html#other-language-c=
hanges
> > Fixes: d8f3a67bf98 ("pygrub: further improve grub2 support")
> > Fixes: dd03048708a ("xen/pygrub: grub2/grub.cfg from RHEL 7 has new=
 commands in menuentry")
> > Fixes: d1b93ea2615 ("tools/pygrub: Make pygrub understand default e=
ntry in string format")
> > Fixes: 622e368758b ("Add ZFS libfsimage support patch")
> > Fixes: 02b26c02c7c ("xen/scripts: add cppcheck tool to the xen-anal=
ysis.py script")
> > Fixes: 56c0063f4e7 ("xen/misra: xen-analysis.py: Improve the cppche=
ck version check")
> >=20
> > Cc: Anthony PERARD 
> > Cc: Luca Fancellu 
> > Cc: Andrew Cooper 
> > Signed-off-by: Ariel Otilibili 
>=20
> For the xen=5Fanalysis tool:
>=20
> Reviewed-by: Luca Fancellu 

Awesome, Luca; thanks for review.

I am looking forward a feedback on the other hunks.
Ariel
>=20
>



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 13:28:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 13:28:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859153.1271297 (Exim 4.92)
	(envelope-from )
	id 1tNXcR-0002l6-Co; Tue, 17 Dec 2024 13:28:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859153.1271297; Tue, 17 Dec 2024 13:28: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 1tNXcR-0002kz-A5; Tue, 17 Dec 2024 13:28:11 +0000
Received: by outflank-mailman (input) for mailman id 859153;
 Tue, 17 Dec 2024 13:28: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 1tNXcQ-0002kt-N4
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 13:28:10 +0000
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com
 [2a00:1450:4864:20::443])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c1c91b73-bc7a-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 14:28:09 +0100 (CET)
Received: by mail-wr1-x443.google.com with SMTP id
 ffacd0b85a97d-385ef8b64b3so4685141f8f.0
 for ; Tue, 17 Dec 2024 05:28:09 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-436255800f6sm171026905e9.18.2024.12.17.05.28.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 05:28: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: c1c91b73-bc7a-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734442089; x=1735046889; darn=lists.xenproject.org;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=By+xU+4yaylIQcLr96UYPAPlnIkFPxS7w0WVWkZnN6o=;
        b=NBGWJdHM8UbxniT+f0+Fo0FNoErfNbEmCpriHp2ERIGuOnkDGJ+awJQu5tPUWQ6wBa
         unYopjGHY40z1eVxPXmy2B3fZ+yyzG2br2MoYejHIMBBXUniP0Gb0eTBRrNaA4Fw7xAN
         xoo6KINI8PgY1thvEPEtQqnDFfZmt/Bt0xqbA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734442089; x=1735046889;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:to:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=By+xU+4yaylIQcLr96UYPAPlnIkFPxS7w0WVWkZnN6o=;
        b=M9klhRoqZhgUoF+x/Wq1BeoZLJ2o3gkn9vXuzgM/wftuRZfysF1KpCi6WMzPzVljHS
         S69T2WVNjPxtw8v+RqOFuAxc3krI/vu2Kl8Xeu/jislvt5UnoZVIdvDyQu6covBSiRBT
         mLeKj5KpSUX3FCweRbnrR/lZEin1ene0spcttUT8ablhnJ7HimMmhOmGtlKx3Cas+3Sr
         QEnJiPQnWvljk0xjZlOBnebo/p34VtNwH6J8H44zxMLo7UWXUVi3blfnpGHwV88eLq03
         QfsRSUy182R51C4l7bQwApyD/cYHTdvfoaol0IlLUFVZjj2p4niGNpcPShdK91dOsA0w
         4aew==
X-Forwarded-Encrypted: i=1; AJvYcCUOaAZBmgt4LrggXtxMwzAYQ/WpkbJAXV8e7m+hBUjUeb4Fl6Mq439jx70KjkFJkVA237D8hYUClxw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw6FVqhcnkrytjBZokG65fSDuTBdyFJQaF1CY4nKiMYYHEYlkIK
	8grZwxQsVKEFw8Or/sHRKzAkpR/bTN6oaq40L08RQwvNVxdTnV21DA84M8C9x+NqnKarbhTFi7i
	GOnAq9g==
X-Gm-Gg: ASbGncukeBrTz6uJxUtuegOSIrPIwdQf3fL3oTu7Q/lpi5ZD6/ng0cWdr973dTt5k4P
	PlWVrl+QBp/8LInko+2dXJXsdMvqPraCR8zMSXWJ+Qf5LsphjyHOoy7lOFDvQAYApF9cfiOeDHC
	UWSamI8jqh3B4iuTxrEf/abn//S6R33UqnBRh858EcMBgGRzZJ5zqaT105Bl7X6j52FuVxwPXVM
	Pt/wh7wBprL/WcpUWLrq/lHnQFf+lVQzz8VcVstXbHjdy2lmgAWoBGOKn0DQrFDNrXqvmg9jCLS
	Q8mMokf4fiHsbxoZ3EnO
X-Google-Smtp-Source: AGHT+IHMAQWMtU+j+z1XP4jFAFdAmRnb8+tXD0bYZ6RLRB6CDTknczo1COThemPew/XiPwCBnNR/wg==
X-Received: by 2002:a5d:588e:0:b0:385:df63:4c49 with SMTP id ffacd0b85a97d-3888e0ae5c3mr13574150f8f.25.1734442088963;
        Tue, 17 Dec 2024 05:28:08 -0800 (PST)
Message-ID: 
Date: Tue, 17 Dec 2024 13:28:08 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
To: Teddy Astie , xen-devel@lists.xenproject.org
References: 
 <96775ba9-19c6-4467-848a-5b4625c70583@vates.tech>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <96775ba9-19c6-4467-848a-5b4625c70583@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 17/12/2024 1:21 pm, Teddy Astie wrote:
> Hello,
>
> Le 17/12/2024 à 13:18, Xen.org security team a écrit :
>> Xen guests need to use different processor instructions to make explicit
>> calls into the Xen hypervisor depending on guest type and/or CPU
>> vendor. In order to hide those differences, the hypervisor can fill a
>> hypercall page with the needed instruction sequences, allowing the guest
>> operating system to call into the hypercall page instead of having to
>> choose the correct instructions.
>>
>> The hypercall page contains whole functions, which are written by the
>> hypervisor and executed by the guest. With the lack of an interface
>> between the guest OS and the hypervisor specifying how a potential
>> modification of those functions should look like, the Xen hypervisor has
>> no knowledge how any potential mitigation should look like or which
>> hardening features should be put into place.
>>
> Should we consider adding a interface to know how to the guest is 
> supposed to make hypercalls (what hypercall instruction/flavor) ? Such 
> as the guest can have its own hypercall implementations but knows which 
> one to use.

Better enumeration is coming with the hypercall API/ABI changes, but a
guest already has enough information to correctly issue hypercalls to
the current ABI.  Hence why we didn't make this fix in Linux depend on
matching change in Xen.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 13:58:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 13:58:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859173.1271311 (Exim 4.92)
	(envelope-from )
	id 1tNY5o-0007V0-LS; Tue, 17 Dec 2024 13:58:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859173.1271311; Tue, 17 Dec 2024 13:58: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 1tNY5o-0007Ut-IZ; Tue, 17 Dec 2024 13:58:32 +0000
Received: by outflank-mailman (input) for mailman id 859173;
 Tue, 17 Dec 2024 13:58: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 1tNY5n-0007Un-3Q
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 13:58:31 +0000
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com
 [2a00:1450:4864:20::435])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id fd7768a9-bc7e-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 14:58:27 +0100 (CET)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-385f06d0c8eso2624743f8f.0
 for ; Tue, 17 Dec 2024 05:58: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-388e2780bcesm245530f8f.82.2024.12.17.05.58.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 05:58: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: fd7768a9-bc7e-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734443907; x=1735048707; 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=1FR/WHpi2MiU1+58BZ3C0sdX2xQgkgGBaIv3V2Ft7b8=;
        b=MJTKJCj7iEE27C2PsazBGswwjNVpPE/SvLd4f4fyw8Y2OjrerbzLJL4ixn40SZpPFp
         AfqAMEb733t0uy5ANVCKCcXkQwWdONTvotZtYbFjDItNrEzyHOI2gUArMKiQt9qRYMUd
         WLz6h7yAAm2JGMccJ4FOWSw7SqwWHQZMIlVruCdYl2ODD/5Cszm3EAcYEA56H/p+NREE
         aZkieIOC4KqTKXvPNNOMx09uSIWtPQm4mG4S8+5GOVc7gA3lSH+wFbF9yVirq5RuNjp1
         PRw44vc54LDIQB8jYqD6Qe6as5+MAw3KDr0LxdxR2QYTTUp8PV3emnAM9i3K42EvY1MU
         6ZhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734443907; x=1735048707;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=1FR/WHpi2MiU1+58BZ3C0sdX2xQgkgGBaIv3V2Ft7b8=;
        b=Keqt50wMtkZwInjhp0MH38bHg2dnUQ0dRneq453ZABwbvqlapR007vht0JKWsxyu0m
         Q0x8LjgG2sN4lNJ8DoZ2JEHAeegrFpEx+2nbeHlt8y1Q8aZ/Dsfa+Vk9hn+xStYi+JH+
         9kAJZKH1z3rKER16B3IRHXvvFjDk7xIasecVLikRgO2Dh24/exQiygqNllLEpuEzRC2E
         Y9gLP+jA67+1T5cHMlkPtTffJD1ZvvIhF/ZGWI45hUoUFMKPL3euEszPtgl6NyEt97uv
         ta1THGKw9KTw3ivhQteDaFBapUAMCUtVr0kDkFUMESiqybA8ogxqupEo36mcdP7Bas7E
         tIqw==
X-Forwarded-Encrypted: i=1; AJvYcCV9k5o9JbP4TDRzR8Xeo7ttpmRofdzwVeVsloivgXZSgCBYJqlVu/7iWsBHp/67DT9RhklR5RYR6oY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxi4bY+1ekclmh0Y7J+/OS4Wg8YoPeFNAb1TBI95cvBBWWUvzKK
	87c3XzziuwxkQnUYxtzt+h9o5zHYjIWFmaN4BfZPZiVCvFLi2epMI2h29h5gIA==
X-Gm-Gg: ASbGncvjJSBJG6T3vmxc6TqNF0fNgd73+D9aCvT6FT09luZpCmVOa39HQJIfc0T7f35
	1T5aEjYsUJxbILjmgdg8IGQZ/6cxDUyFGdMZ8U9YOshGVkYVUQ7jEYTgC/y525iDAGtFFOAognb
	1tcyY6913mCVe++hSweNTo8d8mFyyo6y7PBTUSSwr43veO5MRioUY0QaiUzJcOGOsmH8LLRc4AR
	9EPPWKJZ+7+3QcTbO6lTBvurXR5xAP4XmFwKAeYPglGoTPZWPSquXE7ne3j4X3KKqNjGLnTqaGi
	2wn9xlvhe3VJZf0YxXmEfGPiFE3hp0ZQy36cBD8kBQ==
X-Google-Smtp-Source: AGHT+IEKS6f5Y1Mgn3yb8LM04A5/dX7nqt9qxyDl1Wm649CUPrIbqtB9P+AwZxpgpFP71gEZXBp76g==
X-Received: by 2002:a05:6000:470a:b0:385:e22e:288b with SMTP id ffacd0b85a97d-3888e0c08dfmr13774990f8f.59.1734443907064;
        Tue, 17 Dec 2024 05:58:27 -0800 (PST)
Message-ID: <29640ca8-60eb-492e-9350-4fbc607bca63@suse.com>
Date: Tue, 17 Dec 2024 14:58:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/1] tools/libacpi: clear ASL warning about PCI0
To: Ariel Otilibili-Anieli 
Cc: Anthony PERARD , xen-devel@lists.xenproject.org
References: <20241215154659.151158-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216235241.217642-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216235241.217642-2-Ariel.Otilibili-Anieli@eurecom.fr>
 
 <2f7a89-67617b80-bf75-70827e80@196856502>
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: <2f7a89-67617b80-bf75-70827e80@196856502>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.12.2024 14:24, Ariel Otilibili-Anieli wrote:
> On Tuesday, December 17, 2024 10:29 CET, Jan Beulich  wrote:
> 
>> On 17.12.2024 00:50, Ariel Otilibili wrote:
>>> iasl complains _HID and _ADR cannot be used at the same time:
>>>
>>> ```
>>> /usr/bin/iasl -vs -p tools/firmware/hvmloader/dsdt_anycpu.tmp -tc tools/firmware/hvmloader/dsdt_anycpu.asl 2>&1 | grep -B10 HID
>>>
>>> tools/firmware/hvmloader/dsdt_anycpu.asl     40:        Device (PCI0)
>>> Warning  3073 -                                    Multiple types ^  (Device object requires either a _HID or _ADR, but not both)
>>> ```
>>>
>>> Per ACPI 2.0 (Jul. 27, 2000; Section 6.1, page 146), the configuration was legit:
>>>
>>> "A device object must contain either an _HID object or an _ADR object,
>>> but can contain both." [1]
>>>
>>> But, per ACPI 6.5 (Aug. 2022), this is no more legit:
>>>
>>> "A device object must contain either an _HID object or an _ADR object,
>>> but must not contain both." [2]
>>>
>>> Generally _HID devices are enumerated and have their drivers loaded
>>> by ACPI ("ASL 2.0 Introduction and Overview", page 4).
>>>
>>> Removing _ADR, the warning is cleared out.
>>>
>>> The change should be compatible down to OSes released after ACPI 2.0,
>>> including Windows XP:
>>
>> So my earlier hint apparently wasn't clear enough. I really would have
>> expected you to determine in what version the wording changed. Even 5.1
>> still has the old wording, and that's more than 10 years newer than 2.0.
>> And then in 6.0 the wording first changed to "but should not contain
>> both."
> 
> I can do that, Jan; I'll research from where did the wording changed.

Well, if you want to double check what I've done, feel free. As per above
I did already identify when the wording changed.

>> I'm further afraid that ...
>>
>>> 1. The _HID kept in the DSDT files is the EISA ID "PNP0A03",
>>> Microsoft recognizes it as PCI bus:
>>>
>>> ```
>>> $ curl -k -s https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/devids.txt | grep PNP0A
>>>
>>> PNP0A00         ISA Bus
>>> PNP0A01         EISA Bus
>>> PNP0A02         MCA Bus
>>> PNP0A03         PCI Bus
>>> PNP0A04         VESA/VL Bus
>>> PNP0A05         Generic ACPI Bus
>>> PNP0A06         Generic ACPI Extended-IO Bus (EIO bus)
>>> ```
>>>
>>> 2. Linux 6.12 uses also _HID for identifying PCI devices [3]:
>>
>> ... this fact alone means very little here. The more important question is
>> whether there are / were OSes which use(d) _ADR for any purpose even when
>> _HID is there. With just looking at the surface of just Linux, I find e.g.
>> a library-like function acpi_get_local_u64_address(), all users of which
>> would need auditing. Plus, once done, we'd then still only know the state
>> of things in one specific Linux version.
>>
>> Bottom line: I wonder whether iasl has an option to suppress that warning.
>> Sadly I can't find a new enough iasl anywhere on the systems I have easy
>> access to, so I can't check myself. If there was no way to suppress this
>> warning, I'd wonder whether this wasn't a shortcoming of the tool, as the
>> warning is clearly inappropriate when dealing with tables for pre-v6
>> configurations.
> 
> There are flags to remove warnings:
> 
> ```
> $ iasl -h | grep -i warn
> Errors, Warnings, and Remarks:
>   -va                 Disable all errors/warnings/remarks
>   -ve                 Report only errors (ignore warnings and remarks)
>   -vi                 Less verbose errors and warnings for use with IDEs
>   -vw      Ignore specific error, warning or remark
>   -vx      Expect a specific warning, remark, or error
>   -w <1|2|3>          Set warning reporting level
>   -we                 Report warnings as errors
>   -ww      Report specific warning or remark as error
> 
> $ iasl -v 
> 
> Intel ACPI Component Architecture
> ASL+ Optimizing Compiler/Disassembler version 20240927
> Copyright (c) 2000 - 2023 Intel Corporation
> ```
> 
> I am keeping you posted; I am compiling with warnings disabled.

Disabling warnings altogether is unlikely to be what we want. And the help
output above also doesn't suggest there's a control to suppress specifically
what we may want to suppress. Even suppressing warnings by  is
likely going to be too broad.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 14:22:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 14:22:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859209.1271333 (Exim 4.92)
	(envelope-from )
	id 1tNYSu-00040r-Qt; Tue, 17 Dec 2024 14:22:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859209.1271333; Tue, 17 Dec 2024 14:22: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 1tNYSu-00040k-O2; Tue, 17 Dec 2024 14:22:24 +0000
Received: by outflank-mailman (input) for mailman id 859209;
 Tue, 17 Dec 2024 14:22: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 1tNYSu-00040e-5N
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 14:22:24 +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 54535502-bc82-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 15:22:22 +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 6E62A1F7A2;
 Tue, 17 Dec 2024 14:22: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 0F05313AD8;
 Tue, 17 Dec 2024 14:22: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 sfb+AR2JYWdUDgAAD6G6ig
 (envelope-from ); Tue, 17 Dec 2024 14:22: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: 54535502-bc82-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734445341; 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=fi8wTsJxRWGXV0c43N7Ba5cd5OL3MOOHSvf+jJIMB3Y=;
	b=QZmEm/bAg6Za7yHBCDOfBLt3xVxGFxlWn/YrsOKh2x5PLh7ySuiEfYhzovgK6rAvrXfYxl
	FIl/dhb6Sf6GPbav8zXdy+JR4LFsYhGYw0bz5igV9PiMk8hEjXCK1nHj7vLKAR/OHbaoHt
	eIFEHv0DAZkDaulkmrfsRSOLX0p5Vu0=
Authentication-Results: smtp-out2.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734445341; 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=fi8wTsJxRWGXV0c43N7Ba5cd5OL3MOOHSvf+jJIMB3Y=;
	b=QZmEm/bAg6Za7yHBCDOfBLt3xVxGFxlWn/YrsOKh2x5PLh7ySuiEfYhzovgK6rAvrXfYxl
	FIl/dhb6Sf6GPbav8zXdy+JR4LFsYhGYw0bz5igV9PiMk8hEjXCK1nHj7vLKAR/OHbaoHt
	eIFEHv0DAZkDaulkmrfsRSOLX0p5Vu0=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	"Daniel P. Smith" ,
	Samuel Thibault 
Subject: [PATCH v5 0/5] remove libxenctrl usage from xenstored
Date: Tue, 17 Dec 2024 15:22:13 +0100
Message-ID: <20241217142218.24129-1-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
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];
	RCPT_COUNT_SEVEN(0.00)[11];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Score: -2.80
X-Spam-Flag: NO

Xenstored is using libxenctrl for only one purpose: to get information
about state of domains.

This patch series is removing that dependency by introducing a new
stable interface which can be used by xenstored instead.

There was a RFC series sent out 3 years ago, which I have taken as a
base and by addressing all comments from back then.

The main differences since that RFC series are:

- Instead of introducing an new main hypercall for a stable management
  interface I have just added a new domctl sub-op, as requested in 2021.

- I have added a new library libxenmanage for easy use of the new
  stable hypervisor interface. Main motivation for adding the library
  was the recent attempt to decouple oxenstored from the Xen git tree.
  By using the new library, oxenstored could benefit in the same way as
  xenstored from the new interface: it would be possible to rely on
  stable libraries only.

- Mini-OS has gained some more config options recently, so it was rather
  easy to make xenstore[pvh]-stubdom independent from libxenctrl, too.

- By moving the CPU barrier definitions out of xenctrl.h into a new
  dedicated header xenstored code no longer needs to #include xenctrl.h,
  thus removing any xenctrl reference from xenstored code.

Please note that the last patch can be committed only after the related
Mini-OS patch "config: add support for libxenmanage" has gone in AND
the Mini-OS commit-id has been updated in Config.mk accordingly! The
Mini-OS patch has been Acked already, so it can go in as soon as patch
4 of this series (the one introducing libxenmanage) has been committed.

Changes in V2:
- new patch 1
- former patch 5 mover earlier, now patch 2 (can go in without the rest
  of the series)
- addressed comments

Changes in V3:
- addressed comments

Changes in V4:
- patches 1 and 3 of V3 dropped, as already committed
- addressed comments

Changes in V5:
- addressed comments

Juergen Gross (5):
  tools: add a dedicated header file for barrier definitions
  xen: add bitmap to indicate per-domain state changes
  xen: add new domctl get_changed_domain
  tools/libs: add a new libxenmanage library
  tools/xenstored: use new stable interface instead of libxenctrl

 stubdom/Makefile                       |   8 +-
 stubdom/mini-os.mk                     |   1 +
 tools/9pfsd/io.c                       |   5 +-
 tools/flask/policy/modules/dom0.te     |   2 +-
 tools/flask/policy/modules/xen.if      |   4 +-
 tools/flask/policy/modules/xenstore.te |   1 +
 tools/include/xen-barrier.h            |  39 ++++++
 tools/include/xenctrl.h                |  28 +----
 tools/include/xenmanage.h              |  92 ++++++++++++++
 tools/libs/Makefile                    |   1 +
 tools/libs/ctrl/Makefile               |   2 +-
 tools/libs/manage/Makefile             |  10 ++
 tools/libs/manage/Makefile.common      |   3 +
 tools/libs/manage/core.c               | 168 +++++++++++++++++++++++++
 tools/libs/manage/libxenmanage.map     |   8 ++
 tools/libs/uselibs.mk                  |   2 +
 tools/xenstored/Makefile               |   2 +-
 tools/xenstored/Makefile.common        |   2 +-
 tools/xenstored/core.h                 |   1 -
 tools/xenstored/domain.c               |  52 +++-----
 tools/xenstored/lu.c                   |   1 +
 tools/xenstored/lu_daemon.c            |   1 +
 xen/common/domain.c                    | 127 +++++++++++++++++++
 xen/common/domctl.c                    |  18 ++-
 xen/common/event_channel.c             |  25 +++-
 xen/include/public/domctl.h            |  26 ++++
 xen/include/xen/event.h                |   7 ++
 xen/include/xen/sched.h                |   5 +
 xen/include/xsm/dummy.h                |   8 ++
 xen/include/xsm/xsm.h                  |   6 +
 xen/xsm/dummy.c                        |   1 +
 xen/xsm/flask/hooks.c                  |   7 ++
 xen/xsm/flask/policy/access_vectors    |   2 +
 33 files changed, 591 insertions(+), 74 deletions(-)
 create mode 100644 tools/include/xen-barrier.h
 create mode 100644 tools/include/xenmanage.h
 create mode 100644 tools/libs/manage/Makefile
 create mode 100644 tools/libs/manage/Makefile.common
 create mode 100644 tools/libs/manage/core.c
 create mode 100644 tools/libs/manage/libxenmanage.map

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 14:22:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 14:22:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859210.1271343 (Exim 4.92)
	(envelope-from )
	id 1tNYT0-0004Fz-0u; Tue, 17 Dec 2024 14:22:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859210.1271343; Tue, 17 Dec 2024 14:22: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 1tNYSz-0004Fs-UJ; Tue, 17 Dec 2024 14:22:29 +0000
Received: by outflank-mailman (input) for mailman id 859210;
 Tue, 17 Dec 2024 14:22: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 1tNYSz-0004FJ-DD
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 14:22:29 +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 5796f948-bc82-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 15:22:28 +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 0FBC2211F6;
 Tue, 17 Dec 2024 14:22:27 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id DA3B613AD8;
 Tue, 17 Dec 2024 14:22: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 zPqOMyKJYWdZDgAAD6G6ig
 (envelope-from ); Tue, 17 Dec 2024 14:22: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: 5796f948-bc82-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734445347; 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=G1G3ZUn7qm6OF894GcskQ6ITQ9bas9F9HnN7efD8s/8=;
	b=IaSTmQvjxCfoysJhPnRdTJmsqPz1KwQygsx2Cr+noZthJ7rgG+HmDJNNaY3qhrGBqCRclF
	X3elmQRaf9Rfd5bYhdYdnbqUfOX7MjAF9zgtjvBjgpDEHVd4rWlxoyTjdyR0aNjFjMLhwf
	Shf1rWSSACh4AiU80lD7N8oaDCigdWo=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734445347; 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=G1G3ZUn7qm6OF894GcskQ6ITQ9bas9F9HnN7efD8s/8=;
	b=IaSTmQvjxCfoysJhPnRdTJmsqPz1KwQygsx2Cr+noZthJ7rgG+HmDJNNaY3qhrGBqCRclF
	X3elmQRaf9Rfd5bYhdYdnbqUfOX7MjAF9zgtjvBjgpDEHVd4rWlxoyTjdyR0aNjFjMLhwf
	Shf1rWSSACh4AiU80lD7N8oaDCigdWo=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Anthony PERARD 
Subject: [PATCH v5 1/5] tools: add a dedicated header file for barrier definitions
Date: Tue, 17 Dec 2024 15:22:14 +0100
Message-ID: <20241217142218.24129-2-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217142218.24129-1-jgross@suse.com>
References: <20241217142218.24129-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-6.80 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:email,suse.com:mid];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Score: -6.80
X-Spam-Flag: NO

Instead of having to include xenctrl.h for getting definitions of cpu
barriers, add a dedicated header for that purpose.

Switch the xen-9pfsd daemon to use the new header instead of xenctrl.h.

This is in preparation of making Xenstore independent from libxenctrl.

Signed-off-by: Juergen Gross 
Reviewed-by: Anthony PERARD 
---
V1:
- new patch
V2:
- use SPDX
- modify guard define (Anthony PERARD)
- moved earlier in the series
V4:
- use LGPL-2.1-only SPDX identifier (Anthony PERARD)
---
 tools/9pfsd/io.c            |  5 ++++-
 tools/include/xen-barrier.h | 39 +++++++++++++++++++++++++++++++++++++
 tools/include/xenctrl.h     | 28 +-------------------------
 tools/libs/ctrl/Makefile    |  2 +-
 4 files changed, 45 insertions(+), 29 deletions(-)
 create mode 100644 tools/include/xen-barrier.h

diff --git a/tools/9pfsd/io.c b/tools/9pfsd/io.c
index 468e0241f5..14cfcaf568 100644
--- a/tools/9pfsd/io.c
+++ b/tools/9pfsd/io.c
@@ -13,15 +13,18 @@
 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
-#include            /* For cpu barriers. */
+#include 
 #include 
 
 #include "xen-9pfsd.h"
diff --git a/tools/include/xen-barrier.h b/tools/include/xen-barrier.h
new file mode 100644
index 0000000000..5c22ee112c
--- /dev/null
+++ b/tools/include/xen-barrier.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: LGPL-2.1-only */
+/******************************************************************************
+ * xen-barrier.h
+ *
+ * Definition of CPU barriers, part of libxenctrl.
+ *
+ * Copyright (c) 2003-2004, K A Fraser.
+ */
+
+#ifndef XEN_BARRIER_H
+#define XEN_BARRIER_H
+
+/*
+ *  DEFINITIONS FOR CPU BARRIERS
+ */
+
+#define xen_barrier() asm volatile ( "" : : : "memory")
+
+#if defined(__i386__)
+#define xen_mb()  asm volatile ( "lock addl $0, -4(%%esp)" ::: "memory" )
+#define xen_rmb() xen_barrier()
+#define xen_wmb() xen_barrier()
+#elif defined(__x86_64__)
+#define xen_mb()  asm volatile ( "lock addl $0, -32(%%rsp)" ::: "memory" )
+#define xen_rmb() xen_barrier()
+#define xen_wmb() xen_barrier()
+#elif defined(__arm__)
+#define xen_mb()   asm volatile ("dmb" : : : "memory")
+#define xen_rmb()  asm volatile ("dmb" : : : "memory")
+#define xen_wmb()  asm volatile ("dmb" : : : "memory")
+#elif defined(__aarch64__)
+#define xen_mb()   asm volatile ("dmb sy" : : : "memory")
+#define xen_rmb()  asm volatile ("dmb sy" : : : "memory")
+#define xen_wmb()  asm volatile ("dmb sy" : : : "memory")
+#else
+#error "Define barriers"
+#endif
+
+#endif /* XEN_BARRIER_H */
diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 29617585c5..ea57e9dbb9 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -48,6 +48,7 @@
 #include 
 
 #include "xentoollog.h"
+#include "xen-barrier.h"
 
 #if defined(__i386__) || defined(__x86_64__)
 #include 
@@ -61,33 +62,6 @@
 
 #define INVALID_MFN  (~0UL)
 
-/*
- *  DEFINITIONS FOR CPU BARRIERS
- */
-
-#define xen_barrier() asm volatile ( "" : : : "memory")
-
-#if defined(__i386__)
-#define xen_mb()  asm volatile ( "lock addl $0, -4(%%esp)" ::: "memory" )
-#define xen_rmb() xen_barrier()
-#define xen_wmb() xen_barrier()
-#elif defined(__x86_64__)
-#define xen_mb()  asm volatile ( "lock addl $0, -32(%%rsp)" ::: "memory" )
-#define xen_rmb() xen_barrier()
-#define xen_wmb() xen_barrier()
-#elif defined(__arm__)
-#define xen_mb()   asm volatile ("dmb" : : : "memory")
-#define xen_rmb()  asm volatile ("dmb" : : : "memory")
-#define xen_wmb()  asm volatile ("dmb" : : : "memory")
-#elif defined(__aarch64__)
-#define xen_mb()   asm volatile ("dmb sy" : : : "memory")
-#define xen_rmb()  asm volatile ("dmb sy" : : : "memory")
-#define xen_wmb()  asm volatile ("dmb sy" : : : "memory")
-#else
-#error "Define barriers"
-#endif
-
-
 #define XENCTRL_HAS_XC_INTERFACE 1
 /* In Xen 4.0 and earlier, xc_interface_open and xc_evtchn_open would
  * both return ints being the file descriptor.  In 4.1 and later, they
diff --git a/tools/libs/ctrl/Makefile b/tools/libs/ctrl/Makefile
index 5fe0bfad0c..acce8639d3 100644
--- a/tools/libs/ctrl/Makefile
+++ b/tools/libs/ctrl/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 include Makefile.common
 
-LIBHEADER := xenctrl.h xenctrl_compat.h
+LIBHEADER := xenctrl.h xenctrl_compat.h xen-barrier.h
 PKG_CONFIG_FILE := xencontrol.pc
 PKG_CONFIG_NAME := Xencontrol
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 14:22:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 14:22:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859211.1271353 (Exim 4.92)
	(envelope-from )
	id 1tNYT5-0004XF-9d; Tue, 17 Dec 2024 14:22:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859211.1271353; Tue, 17 Dec 2024 14:22:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNYT5-0004X8-5x; Tue, 17 Dec 2024 14:22:35 +0000
Received: by outflank-mailman (input) for mailman id 859211;
 Tue, 17 Dec 2024 14:22: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 1tNYT4-0004FJ-DB
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 14:22:34 +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 5b261a84-bc82-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 15:22:33 +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 D9B7A211ED;
 Tue, 17 Dec 2024 14:22: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 86CC913AD8;
 Tue, 17 Dec 2024 14:22: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 2S8JHyiJYWdeDgAAD6G6ig
 (envelope-from ); Tue, 17 Dec 2024 14:22: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: 5b261a84-bc82-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734445353; 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=F439o4t2R3fnvlqguzaWDYG4TZOg2B8z0xYoJ3vcrPg=;
	b=WnI73Ul/HoxG5Q1fonTYeU/l/NiKSkDwQVJCE0ncwldXg4Qsjg3IEwFMo98bcr5YBdKcQQ
	DatJ4wCr3ubmaS0ExCoUk5lBqUXDl4Tp3FNDEpShAmR731Iq09ep5FTtY1Bd/yjb/eSM+t
	V37JjpfpNjS2/LML1dmfhtkTBkAaL5c=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734445352; 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=F439o4t2R3fnvlqguzaWDYG4TZOg2B8z0xYoJ3vcrPg=;
	b=Qp3tRs2AA6G7R6XJcKmSGTPbVWITPk1X9pzefWrCqMyzlhXEhQvNkvKmuZiCLLGBdp5wQF
	/yl+A20RTeCEnZfLE4QyQZqI2LafuxCQxMnpXAuaTWg11oCFy9qBJBB7xArI9IpmT0U44u
	5wreJswpXt5FXHH8W02sOHHQTz3kISE=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v5 2/5] xen: add bitmap to indicate per-domain state changes
Date: Tue, 17 Dec 2024 15:22:15 +0100
Message-ID: <20241217142218.24129-3-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217142218.24129-1-jgross@suse.com>
References: <20241217142218.24129-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -6.80
X-Spamd-Result: default: False [-6.80 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_SEVEN(0.00)[9];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Level: 

Add a bitmap with one bit per possible domid indicating the respective
domain has changed its state (created, deleted, dying, crashed,
shutdown).

Registering the VIRQ_DOM_EXC event will result in setting the bits for
all existing domains and resetting all other bits.

As the usage of this bitmap is tightly coupled with the VIRQ_DOM_EXC
event, it is meant to be used only by a single consumer in the system,
just like the VIRQ_DOM_EXC event.

Resetting a bit will be done in a future patch.

This information is needed for Xenstore to keep track of all domains.

Signed-off-by: Juergen Gross 
---
V2:
- use DOMID_FIRST_RESERVED instead of DOMID_MASK + 1 (Jan Beulich)
- use const (Jan Beulich)
- move call of domain_reset_states() into evtchn_bind_virq() (Jan Beulich)
- dynamically allocate dom_state_changed bitmap (Jan Beulich)
V3:
- use xvzalloc_array() (Jan Beulich)
- don't rename existing label (Jan Beulich)
V4:
- add __read_mostly (Jan Beulich)
- use __set_biz() (Jan Beulich)
- fix error handling in evtchn_bind_virq() (Jan Beulich)
V5:
- domain_init_states() may be called only if evtchn_bind_virq() has been
  called validly (Jan Beulich)
---
 xen/common/domain.c        | 60 ++++++++++++++++++++++++++++++++++++++
 xen/common/event_channel.c | 16 ++++++++++
 xen/include/xen/sched.h    |  3 ++
 3 files changed, 79 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index e33a0a5a21..87633b1f7b 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -138,6 +139,60 @@ bool __read_mostly vmtrace_available;
 
 bool __read_mostly vpmu_is_available;
 
+static DEFINE_SPINLOCK(dom_state_changed_lock);
+static unsigned long *__read_mostly dom_state_changed;
+
+int domain_init_states(void)
+{
+    const struct domain *d;
+    int rc = -ENOMEM;
+
+    spin_lock(&dom_state_changed_lock);
+
+    if ( dom_state_changed )
+        bitmap_zero(dom_state_changed, DOMID_FIRST_RESERVED);
+    else
+    {
+        dom_state_changed = xvzalloc_array(unsigned long,
+                                           BITS_TO_LONGS(DOMID_FIRST_RESERVED));
+        if ( !dom_state_changed )
+            goto unlock;
+    }
+
+    rcu_read_lock(&domlist_read_lock);
+
+    for_each_domain ( d )
+        __set_bit(d->domain_id, dom_state_changed);
+
+    rcu_read_unlock(&domlist_read_lock);
+
+    rc = 0;
+
+ unlock:
+    spin_unlock(&dom_state_changed_lock);
+
+    return rc;
+}
+
+void domain_deinit_states(void)
+{
+    spin_lock(&dom_state_changed_lock);
+
+    XVFREE(dom_state_changed);
+
+    spin_unlock(&dom_state_changed_lock);
+}
+
+static void domain_changed_state(const struct domain *d)
+{
+    spin_lock(&dom_state_changed_lock);
+
+    if ( dom_state_changed )
+        __set_bit(d->domain_id, dom_state_changed);
+
+    spin_unlock(&dom_state_changed_lock);
+}
+
 static void __domain_finalise_shutdown(struct domain *d)
 {
     struct vcpu *v;
@@ -152,6 +207,7 @@ static void __domain_finalise_shutdown(struct domain *d)
             return;
 
     d->is_shut_down = 1;
+    domain_changed_state(d);
     if ( (d->shutdown_code == SHUTDOWN_suspend) && d->suspend_evtchn )
         evtchn_send(d, d->suspend_evtchn);
     else
@@ -839,6 +895,7 @@ struct domain *domain_create(domid_t domid,
      */
     domlist_insert(d);
 
+    domain_changed_state(d);
     memcpy(d->handle, config->handle, sizeof(d->handle));
 
     return d;
@@ -1104,6 +1161,7 @@ int domain_kill(struct domain *d)
         /* Mem event cleanup has to go here because the rings 
          * have to be put before we call put_domain. */
         vm_event_cleanup(d);
+        domain_changed_state(d);
         put_domain(d);
         send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
@@ -1293,6 +1351,8 @@ static void cf_check complete_domain_destroy(struct rcu_head *head)
 
     xfree(d->vcpu);
 
+    domain_changed_state(d);
+
     _domain_destroy(d);
 
     send_global_virq(VIRQ_DOM_EXC);
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 8db2ca4ba2..aa947efba7 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -469,6 +469,7 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
     struct domain *d = current->domain;
     int            virq = bind->virq, vcpu = bind->vcpu;
     int            rc = 0;
+    bool           deinit_if_err = false;
 
     if ( (virq < 0) || (virq >= ARRAY_SIZE(v->virq_to_evtchn)) )
         return -EINVAL;
@@ -494,6 +495,15 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
         goto out;
     }
 
+    if ( virq == VIRQ_DOM_EXC )
+    {
+        rc = domain_init_states();
+        if ( rc )
+            goto out;
+
+        deinit_if_err = true;
+    }
+
     port = rc = evtchn_get_port(d, port);
     if ( rc < 0 )
     {
@@ -527,6 +537,9 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
  out:
     write_unlock(&d->event_lock);
 
+    if ( rc && deinit_if_err )
+        domain_deinit_states();
+
     return rc;
 }
 
@@ -730,6 +743,9 @@ int evtchn_close(struct domain *d1, int port1, bool guest)
         struct vcpu *v;
         unsigned long flags;
 
+        if ( chn1->u.virq == VIRQ_DOM_EXC )
+            domain_deinit_states();
+
         v = d1->vcpu[virq_is_global(chn1->u.virq) ? 0 : chn1->notify_vcpu_id];
 
         write_lock_irqsave(&v->virq_lock, flags);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 711668e028..16684bbaf9 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -800,6 +800,9 @@ void domain_resume(struct domain *d);
 
 int domain_soft_reset(struct domain *d, bool resuming);
 
+int domain_init_states(void);
+void domain_deinit_states(void);
+
 int vcpu_start_shutdown_deferral(struct vcpu *v);
 void vcpu_end_shutdown_deferral(struct vcpu *v);
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 14:22:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 14:22:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859213.1271362 (Exim 4.92)
	(envelope-from )
	id 1tNYTC-0004uZ-Gp; Tue, 17 Dec 2024 14:22:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859213.1271362; Tue, 17 Dec 2024 14:22:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNYTC-0004uQ-Da; Tue, 17 Dec 2024 14:22:42 +0000
Received: by outflank-mailman (input) for mailman id 859213;
 Tue, 17 Dec 2024 14:22: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 1tNYTA-00040e-NV
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 14:22:40 +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 5e7421f9-bc82-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 15:22:39 +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 9EAB4211F7;
 Tue, 17 Dec 2024 14:22:38 +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 4E61113AD8;
 Tue, 17 Dec 2024 14:22:38 +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 JeiVES6JYWd0DgAAD6G6ig
 (envelope-from ); Tue, 17 Dec 2024 14: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: 5e7421f9-bc82-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734445358; 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=L42JpxKgM+awgd/V4RcNzFlMyLHPs1OH7yNVxFFGIZ0=;
	b=g8IY6RovwpYCQ9XPhd0498AjXKvlciGI4ZWN5X0AX3qrkDhxnH693+gq1xj/ior/onLKWe
	fNEGt11BSZ52z8vmIvOsWN3LOcOl2Xs0GWVtkvTh3eSViSIkp3pOK1StS1a3TFagkYxQax
	wsGePbg2lSsdzFn+ThuKR+WJyfzkCkQ=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734445358; 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=L42JpxKgM+awgd/V4RcNzFlMyLHPs1OH7yNVxFFGIZ0=;
	b=g8IY6RovwpYCQ9XPhd0498AjXKvlciGI4ZWN5X0AX3qrkDhxnH693+gq1xj/ior/onLKWe
	fNEGt11BSZ52z8vmIvOsWN3LOcOl2Xs0GWVtkvTh3eSViSIkp3pOK1StS1a3TFagkYxQax
	wsGePbg2lSsdzFn+ThuKR+WJyfzkCkQ=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	"Daniel P. Smith" ,
	Anthony PERARD ,
	Andrew Cooper ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v5 3/5] xen: add new domctl get_changed_domain
Date: Tue, 17 Dec 2024 15:22:16 +0100
Message-ID: <20241217142218.24129-4-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217142218.24129-1-jgross@suse.com>
References: <20241217142218.24129-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Score: -6.80
X-Spamd-Result: default: False [-6.80 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_SEVEN(0.00)[10];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Flag: NO
X-Spam-Level: 

Add a new domctl sub-function to get data of a domain having changed
state (this is needed by Xenstore).

The returned state just contains the domid, the domain unique id,
and some flags (existing, shutdown, dying).

In order to enable Xenstore stubdom being built for multiple Xen
versions, make this domctl stable.  For stable domctls the
interface_version is always 0.

Signed-off-by: Juergen Gross 
---
V1:
- use a domctl subop for the new interface (Jan Beulich)
V2:
- fix XSM hooks (Daniel P. Smith)
- remove versioning of stable sub-ops (Jan Beulich)
- use domctl.domain for retuning domid of a changed domain (Jan Beulich)
- simplify locking in get_domain_state() (Jan Beulich)
- undo stray change in event_channel.c (Jan Beulich)
V3:
- have disjunct states "dying" and "dead" (Jan Beulich)
- check padding fields to be 0 (Jan Beulich)
- drop memset() (Jan Beulich)
V4:
- add locking in get_domain_state() (Jan Beulich)
- only allow querying domain having changed state by domain receiving
  VIRQ_DOM_EXC events (Jan Beulich)
V5:
- use memset() (Jan Beulich)
---
 tools/flask/policy/modules/dom0.te     |  2 +-
 tools/flask/policy/modules/xen.if      |  4 +-
 tools/flask/policy/modules/xenstore.te |  1 +
 xen/common/domain.c                    | 67 ++++++++++++++++++++++++++
 xen/common/domctl.c                    | 18 ++++++-
 xen/common/event_channel.c             |  9 +++-
 xen/include/public/domctl.h            | 26 ++++++++++
 xen/include/xen/event.h                |  7 +++
 xen/include/xen/sched.h                |  2 +
 xen/include/xsm/dummy.h                |  8 +++
 xen/include/xsm/xsm.h                  |  6 +++
 xen/xsm/dummy.c                        |  1 +
 xen/xsm/flask/hooks.c                  |  7 +++
 xen/xsm/flask/policy/access_vectors    |  2 +
 14 files changed, 155 insertions(+), 5 deletions(-)

diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
index 16b8c9646d..6043c01b12 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -40,7 +40,7 @@ allow dom0_t dom0_t:domain {
 };
 allow dom0_t dom0_t:domain2 {
 	set_cpu_policy gettsc settsc setscheduler set_vnumainfo
-	get_vnumainfo psr_cmt_op psr_alloc get_cpu_policy
+	get_vnumainfo psr_cmt_op psr_alloc get_cpu_policy get_domain_state
 };
 allow dom0_t dom0_t:resource { add remove };
 
diff --git a/tools/flask/policy/modules/xen.if b/tools/flask/policy/modules/xen.if
index 11c1562aa5..2e06f3ed94 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -54,7 +54,7 @@ define(`create_domain_common', `
 	allow $1 $2:domain2 { set_cpu_policy settsc setscheduler setclaim
 			set_vnumainfo get_vnumainfo cacheflush
 			psr_cmt_op psr_alloc soft_reset
-			resource_map get_cpu_policy };
+			resource_map get_cpu_policy get_domain_state };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
@@ -94,7 +94,7 @@ define(`manage_domain', `
 			getaddrsize pause unpause trigger shutdown destroy
 			setaffinity setdomainmaxmem getscheduler resume
 			setpodtarget getpodtarget getpagingmempool setpagingmempool };
-    allow $1 $2:domain2 set_vnumainfo;
+    allow $1 $2:domain2 { set_vnumainfo get_domain_state };
 ')
 
 # migrate_domain_out(priv, target)
diff --git a/tools/flask/policy/modules/xenstore.te b/tools/flask/policy/modules/xenstore.te
index 519566ab81..49de53ebe2 100644
--- a/tools/flask/policy/modules/xenstore.te
+++ b/tools/flask/policy/modules/xenstore.te
@@ -13,6 +13,7 @@ allow dom0_t xenstore_t:domain set_virq_handler;
 allow xenstore_t xen_t:xen writeconsole;
 # Xenstore queries domaininfo on all domains
 allow xenstore_t domain_type:domain getdomaininfo;
+allow xenstore_t domain_type:domain2 get_domain_state;
 
 # As a shortcut, the following 3 rules are used instead of adding a domain_comms
 # rule between xenstore_t and every domain type that talks to xenstore
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 87633b1f7b..1580754b53 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -193,6 +193,73 @@ static void domain_changed_state(const struct domain *d)
     spin_unlock(&dom_state_changed_lock);
 }
 
+static void set_domain_state_info(struct xen_domctl_get_domain_state *info,
+                                  const struct domain *d)
+{
+    info->state = XEN_DOMCTL_GETDOMSTATE_STATE_EXIST;
+    if ( d->is_shut_down )
+        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN;
+    if ( d->is_dying == DOMDYING_dying )
+        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DYING;
+    if ( d->is_dying == DOMDYING_dead )
+        info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DEAD;
+    info->unique_id = d->unique_id;
+}
+
+int get_domain_state(struct xen_domctl_get_domain_state *info, struct domain *d,
+                     domid_t *domid)
+{
+    unsigned int dom;
+    int rc = -ENOENT;
+
+    if ( info->pad0 || info->pad1 )
+        return -EINVAL;
+
+    if ( d )
+    {
+        set_domain_state_info(info, d);
+
+        return 0;
+    }
+
+    /*
+     * Only domain registered for VIRQ_DOM_EXC event is allowed to query
+     * domains having changed state.
+     */
+    if ( !domain_handles_global_virq(current->domain, VIRQ_DOM_EXC) )
+        return -EACCES;
+
+    spin_lock(&dom_state_changed_lock);
+
+    if ( dom_state_changed )
+    {
+        dom = find_first_bit(dom_state_changed, DOMID_MASK + 1);
+        if ( dom < DOMID_FIRST_RESERVED )
+        {
+            __clear_bit(dom, dom_state_changed);
+
+            *domid = dom;
+
+            d = rcu_lock_domain_by_id(dom);
+
+            if ( d )
+            {
+                set_domain_state_info(info, d);
+
+                rcu_unlock_domain(d);
+            }
+            else
+                memset(info, 0, sizeof(*info));
+
+            rc = 0;
+        }
+    }
+
+    spin_unlock(&dom_state_changed_lock);
+
+    return rc;
+}
+
 static void __domain_finalise_shutdown(struct domain *d)
 {
     struct vcpu *v;
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 444e072fdc..802bd7596e 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -278,6 +278,11 @@ static struct vnuma_info *vnuma_init(const struct xen_domctl_vnuma *uinfo,
     return ERR_PTR(ret);
 }
 
+static bool is_stable_domctl(uint32_t cmd)
+{
+    return cmd == XEN_DOMCTL_get_domain_state;
+}
+
 long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 {
     long ret = 0;
@@ -288,7 +293,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
     if ( copy_from_guest(op, u_domctl, 1) )
         return -EFAULT;
 
-    if ( op->interface_version != XEN_DOMCTL_INTERFACE_VERSION )
+    if ( op->interface_version !=
+         (is_stable_domctl(op->cmd) ? 0 : XEN_DOMCTL_INTERFACE_VERSION) )
         return -EACCES;
 
     switch ( op->cmd )
@@ -309,6 +315,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
         fallthrough;
     case XEN_DOMCTL_test_assign_device:
     case XEN_DOMCTL_vm_event_op:
+    case XEN_DOMCTL_get_domain_state:
         if ( op->domain == DOMID_INVALID )
         {
             d = NULL;
@@ -866,6 +873,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
                 __HYPERVISOR_domctl, "h", u_domctl);
         break;
 
+    case XEN_DOMCTL_get_domain_state:
+        ret = xsm_get_domain_state(XSM_XS_PRIV, d);
+        if ( ret )
+            break;
+
+        copyback = 1;
+        ret = get_domain_state(&op->u.get_domain_state, d, &op->domain);
+        break;
+
     default:
         ret = arch_do_domctl(op, d, u_domctl);
         break;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index aa947efba7..9ff486d28e 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -992,6 +992,13 @@ void send_global_virq(uint32_t virq)
     send_guest_global_virq(global_virq_handlers[virq] ?: hardware_domain, virq);
 }
 
+bool domain_handles_global_virq(struct domain *d, uint32_t virq)
+{
+    ASSERT(virq_is_global(virq));
+
+    return global_virq_handlers[virq] == d;
+}
+
 int set_global_virq_handler(struct domain *d, uint32_t virq)
 {
     struct domain *old;
@@ -1001,7 +1008,7 @@ int set_global_virq_handler(struct domain *d, uint32_t virq)
     if (!virq_is_global(virq))
         return -EINVAL;
 
-    if (global_virq_handlers[virq] == d)
+    if ( domain_handles_global_virq(d, virq) )
         return 0;
 
     if (unlikely(!get_domain(d)))
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 353f831e40..13fe17ab0a 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -28,6 +28,7 @@
  * Pure additions (e.g. new sub-commands) or compatible interface changes
  * (e.g. adding semantics to 0-checked input fields or data to zeroed output
  * fields) don't require a change of the version.
+ * Stable ops are NOT covered by XEN_DOMCTL_INTERFACE_VERSION!
  *
  * Last version bump: Xen 4.19
  */
@@ -1236,7 +1237,30 @@ struct xen_domctl_dt_overlay {
 };
 #endif
 
+/*
+ * XEN_DOMCTL_get_domain_state (stable interface)
+ *
+ * Get state information of a domain.
+ *
+ * In case domain is DOMID_INVALID, return information about a domain having
+ * changed state and reset the state change indicator for that domain. This
+ * function is usable only by a domain having registered the VIRQ_DOM_EXC
+ * event (normally Xenstore).
+ * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
+ */
+struct xen_domctl_get_domain_state {
+    uint16_t state;
+#define XEN_DOMCTL_GETDOMSTATE_STATE_EXIST     0x0001  /* Domain is existing. */
+#define XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN  0x0002  /* Shutdown finished. */
+#define XEN_DOMCTL_GETDOMSTATE_STATE_DYING     0x0004  /* Domain dying. */
+#define XEN_DOMCTL_GETDOMSTATE_STATE_DEAD      0x0008  /* Domain dead. */
+    uint16_t pad0;           /* Must be 0 on input, returned as 0. */
+    uint32_t pad1;           /* Must be 0 on input, returned as 0. */
+    uint64_t unique_id;      /* Unique domain identifier. */
+};
+
 struct xen_domctl {
+/* Stable domctl ops: interface_version is required to be 0.  */
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
 #define XEN_DOMCTL_destroydomain                  2
@@ -1325,6 +1349,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_set_paging_mempool_size       86
 #define XEN_DOMCTL_dt_overlay                    87
 #define XEN_DOMCTL_gsi_permission                88
+#define XEN_DOMCTL_get_domain_state              89 /* stable interface */
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1391,6 +1416,7 @@ struct xen_domctl {
 #if defined(__arm__) || defined(__aarch64__)
         struct xen_domctl_dt_overlay        dt_overlay;
 #endif
+        struct xen_domctl_get_domain_state  get_domain_state;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 48b79f3d62..3a119505c6 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -36,6 +36,13 @@ void send_global_virq(uint32_t virq);
  */
 void send_guest_global_virq(struct domain *d, uint32_t virq);
 
+/*
+ * domain_handles_global_virq:
+ *  @d:        Suspected target domain for this VIRQ
+ *  @virq:     Virtual IRQ number (VIRQ_*), must be global
+ */
+bool domain_handles_global_virq(struct domain *d, uint32_t virq);
+
 /*
  * sent_global_virq_handler: Set a global VIRQ handler.
  *  @d:        New target domain for this VIRQ
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 16684bbaf9..5e9858c3ba 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -802,6 +802,8 @@ int domain_soft_reset(struct domain *d, bool resuming);
 
 int domain_init_states(void);
 void domain_deinit_states(void);
+int get_domain_state(struct xen_domctl_get_domain_state *info,
+                     struct domain *d, domid_t *domid);
 
 int vcpu_start_shutdown_deferral(struct vcpu *v);
 void vcpu_end_shutdown_deferral(struct vcpu *v);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index f8a3c4b81e..a1a5bb60e9 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -173,6 +173,7 @@ static XSM_INLINE int cf_check xsm_domctl(
     case XEN_DOMCTL_unbind_pt_irq:
         return xsm_default_action(XSM_DM_PRIV, current->domain, d);
     case XEN_DOMCTL_getdomaininfo:
+    case XEN_DOMCTL_get_domain_state:
         return xsm_default_action(XSM_XS_PRIV, current->domain, d);
     default:
         return xsm_default_action(XSM_PRIV, current->domain, d);
@@ -815,6 +816,13 @@ static XSM_INLINE int cf_check xsm_argo_send(
 
 #endif /* CONFIG_ARGO */
 
+static XSM_INLINE int cf_check xsm_get_domain_state(
+    XSM_DEFAULT_ARG struct domain *d)
+{
+    XSM_ASSERT_ACTION(XSM_XS_PRIV);
+    return xsm_default_action(action, current->domain, d);
+}
+
 #include 
 static XSM_INLINE int cf_check xsm_xen_version(XSM_DEFAULT_ARG uint32_t op)
 {
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 4dbff9d866..0689bf5c9f 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -200,6 +200,7 @@ struct xsm_ops {
     int (*argo_register_any_source)(const struct domain *d);
     int (*argo_send)(const struct domain *d, const struct domain *t);
 #endif
+    int (*get_domain_state)(struct domain *d);
 };
 
 #ifdef CONFIG_XSM
@@ -774,6 +775,11 @@ static inline int xsm_argo_send(const struct domain *d, const struct domain *t)
 
 #endif /* CONFIG_ARGO */
 
+static inline int xsm_get_domain_state(struct domain *d)
+{
+    return alternative_call(xsm_ops.get_domain_state, d);
+}
+
 #endif /* XSM_NO_WRAPPERS */
 
 #ifdef CONFIG_MULTIBOOT
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index e6ffa948f7..ce6fbdc6c5 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -148,6 +148,7 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
     .argo_register_any_source      = xsm_argo_register_any_source,
     .argo_send                     = xsm_argo_send,
 #endif
+    .get_domain_state              = xsm_get_domain_state,
 };
 
 void __init xsm_fixup_ops(struct xsm_ops *ops)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a79474ffe4..e110846ad9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -688,6 +688,7 @@ static int cf_check flask_domctl(struct domain *d, unsigned int cmd,
     case XEN_DOMCTL_memory_mapping:
     case XEN_DOMCTL_set_target:
     case XEN_DOMCTL_vm_event_op:
+    case XEN_DOMCTL_get_domain_state:
 
     /* These have individual XSM hooks (arch/../domctl.c) */
     case XEN_DOMCTL_bind_pt_irq:
@@ -1856,6 +1857,11 @@ static int cf_check flask_argo_send(
 
 #endif
 
+static int cf_check flask_get_domain_state(struct domain *d)
+{
+    return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GET_DOMAIN_STATE);
+}
+
 static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .set_system_active = flask_set_system_active,
     .security_domaininfo = flask_security_domaininfo,
@@ -1992,6 +1998,7 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
     .argo_register_any_source = flask_argo_register_any_source,
     .argo_send = flask_argo_send,
 #endif
+    .get_domain_state = flask_get_domain_state,
 };
 
 const struct xsm_ops *__init flask_init(
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index a35e3d4c51..c9a8eeda4e 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -251,6 +251,8 @@ class domain2
     resource_map
 # XEN_DOMCTL_get_cpu_policy
     get_cpu_policy
+# XEN_DOMCTL_get_domain_state
+    get_domain_state
 }
 
 # Similar to class domain, but primarily contains domctls related to HVM domains
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 14:22:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 14:22:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859217.1271373 (Exim 4.92)
	(envelope-from )
	id 1tNYTG-0005IQ-Tc; Tue, 17 Dec 2024 14:22:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859217.1271373; Tue, 17 Dec 2024 14:22: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 1tNYTG-0005IH-Q7; Tue, 17 Dec 2024 14:22:46 +0000
Received: by outflank-mailman (input) for mailman id 859217;
 Tue, 17 Dec 2024 14: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 1tNYTF-0004FJ-I6
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 14:22:45 +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 61dd795a-bc82-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 15:22:44 +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 373D2211ED;
 Tue, 17 Dec 2024 14:22:44 +0000 (UTC)
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 117E213AD8;
 Tue, 17 Dec 2024 14:22:44 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
 by imap1.dmz-prg2.suse.org with ESMTPSA id wd2iAjSJYWd8DgAAD6G6ig
 (envelope-from ); Tue, 17 Dec 2024 14:22: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: 61dd795a-bc82-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734445364; 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=nEj0rU7fUJdxnb+34yZOLrAkY9HqJgVtVSezjvYU+Qo=;
	b=b/OQJsURcmh1kBCL8IHULFzzGwYKUAEcK5z/qoTXfcvmR+Q+KnV9NDIkElyMsCj9x6fL0y
	31tCWUhJyB/yyspDQ2LAZp4pdsnKoKu3/pFfILQnwRhEXzdUe/4g7tNhOTaVBHa3sVszRS
	Qz1SNJQWGxz1ZWP9wOKOcMY99SDOmIM=
Authentication-Results: smtp-out1.suse.de;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1734445364; 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=nEj0rU7fUJdxnb+34yZOLrAkY9HqJgVtVSezjvYU+Qo=;
	b=b/OQJsURcmh1kBCL8IHULFzzGwYKUAEcK5z/qoTXfcvmR+Q+KnV9NDIkElyMsCj9x6fL0y
	31tCWUhJyB/yyspDQ2LAZp4pdsnKoKu3/pFfILQnwRhEXzdUe/4g7tNhOTaVBHa3sVszRS
	Qz1SNJQWGxz1ZWP9wOKOcMY99SDOmIM=
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Anthony PERARD 
Subject: [PATCH v5 4/5] tools/libs: add a new libxenmanage library
Date: Tue, 17 Dec 2024 15:22:17 +0100
Message-ID: <20241217142218.24129-5-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217142218.24129-1-jgross@suse.com>
References: <20241217142218.24129-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Level: 
X-Spamd-Result: default: False [-6.80 / 50.00];
	REPLY(-4.00)[];
	BAYES_HAM(-3.00)[100.00%];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	NEURAL_HAM_SHORT(-0.20)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	DKIM_SIGNED(0.00)[suse.com:s=susede1];
	FUZZY_BLOCKED(0.00)[rspamd.com];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DBL_BLOCKED_OPENRESOLVER(0.00)[gnu.org:url,suse.com:email,suse.com:mid];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-Spam-Score: -6.80
X-Spam-Flag: NO

In order to have a stable interface in user land for using stable
domctl and possibly later sysctl interfaces, add a new library
libxenmanage.

Signed-off-by: Juergen Gross 
Reviewed-by: Anthony PERARD 
---
V1:
- new patch
V2:
- define __XEN_TOOLS__ via Makefile (Anthony PERARD)
- use SPDX in header file (Anthony PERARD)
- change function name to xenmanage_poll_changed_domain() (Anthony PERARD)
- add short library description (Anthony PERARD)
- narrow scope of xen_domctl_get_domain_state pointer (Anthony PERARD)
V4:
- use LGPL-2.1-only SPDX identifier (Anthony PERARD)
---
 tools/include/xenmanage.h          |  92 ++++++++++++++++
 tools/libs/Makefile                |   1 +
 tools/libs/manage/Makefile         |  10 ++
 tools/libs/manage/Makefile.common  |   3 +
 tools/libs/manage/core.c           | 168 +++++++++++++++++++++++++++++
 tools/libs/manage/libxenmanage.map |   8 ++
 tools/libs/uselibs.mk              |   2 +
 7 files changed, 284 insertions(+)
 create mode 100644 tools/include/xenmanage.h
 create mode 100644 tools/libs/manage/Makefile
 create mode 100644 tools/libs/manage/Makefile.common
 create mode 100644 tools/libs/manage/core.c
 create mode 100644 tools/libs/manage/libxenmanage.map

diff --git a/tools/include/xenmanage.h b/tools/include/xenmanage.h
new file mode 100644
index 0000000000..956b7a0a44
--- /dev/null
+++ b/tools/include/xenmanage.h
@@ -0,0 +1,92 @@
+/* SPDX-License-Identifier: LGPL-2.1-only */
+/*
+ * Copyright (c) 2024 SUSE Software Solutions Germany GmbH
+ *
+ * Interfaces of libxenmanage.
+ *
+ * libxenmanage provides management functions for the host using stable
+ * hypercall interfaces.
+ */
+#ifndef XENMANAGE_H
+#define XENMANAGE_H
+
+#include 
+
+/* Avoid the need to #include  */
+struct xentoollog_logger;
+
+typedef struct xenmanage_handle xenmanage_handle;
+
+/*
+ * Open libxenmanage.
+ *
+ * Get a handle of the xenmanage library. The handle is required for all
+ * further operations of the library.
+ * Parameters:
+ *   logger:     Logging function to use. If NULL logging is done to stderr.
+ *   open_flags: Only 0 supported.
+ * Return value: Handle or NULL if error.
+ */
+xenmanage_handle *xenmanage_open(struct xentoollog_logger *logger,
+                                 unsigned int open_flags);
+
+/*
+ * Close libxenmanage.
+ *
+ * Return a handle of the xenmanage library.
+ * Parameters:
+ *    hdl: Handle obtained by xenmanage_open().
+ * Return value: always 0.
+ */
+int xenmanage_close(xenmanage_handle *hdl);
+
+#define XENMANAGE_GETDOMSTATE_STATE_EXIST     0x0001  /* Domain is existing. */
+#define XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN  0x0002  /* Shutdown finished. */
+#define XENMANAGE_GETDOMSTATE_STATE_DYING     0x0004  /* Domain dying. */
+#define XENMANAGE_GETDOMSTATE_STATE_DEAD      0x0008  /* Domain dead. */
+
+/*
+ * Return state information of an existing domain.
+ *
+ * Returns the domain state and unique id of the given domain.
+ * Parameters:
+ *   hdl:       handle returned by xenmanage_open()
+ *   domid:     domain id of the domain to get the information for
+ *   state:     where to store the state (XENMANAGE_GETDOMSTATE_STATE_ flags,
+ *              nothing stored if NULL)
+ *   unique_id: where to store the unique id of the domain (nothing stored if
+ *              NULL)
+ * Return value: 0 if information was stored, -1 else (errno is set)
+ */
+int xenmanage_get_domain_info(xenmanage_handle *hdl, unsigned int domid,
+                              unsigned int *state, uint64_t *unique_id);
+
+/*
+ * Return information of a domain having changed state recently.
+ *
+ * Returns the domain id, state and unique id of a domain having changed
+ * state (any of the state bits was modified) since the last time information
+ * for that domain was returned by this function. Only usable by callers who
+ * have registered the VIRQ_DOM_EXC event (normally Xenstore).
+ * Parameters:
+ *   hdl:       handle returned by xenmanage_open()
+ *   domid:     where to store the domid of the domain (not NULL)
+ *   state:     where to store the state (XENMANAGE_GETDOMSTATE_STATE_ flags,
+ *              nothing stored if NULL)
+ *   unique_id: where to store the unique id of the domain (nothing stored if
+ *              NULL)
+ * Return value: 0 if information was stored, -1 else (errno is set)
+ */
+int xenmanage_poll_changed_domain(xenmanage_handle *hdl, unsigned int *domid,
+                                  unsigned int *state, uint64_t *unique_id);
+#endif /* XENMANAGE_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libs/Makefile b/tools/libs/Makefile
index 1afcd12e2b..d39516c1b3 100644
--- a/tools/libs/Makefile
+++ b/tools/libs/Makefile
@@ -12,6 +12,7 @@ SUBDIRS-y += devicemodel
 SUBDIRS-y += ctrl
 SUBDIRS-y += guest
 SUBDIRS-y += hypfs
+SUBDIRS-y += manage
 SUBDIRS-y += store
 SUBDIRS-y += stat
 SUBDIRS-$(CONFIG_Linux) += vchan
diff --git a/tools/libs/manage/Makefile b/tools/libs/manage/Makefile
new file mode 100644
index 0000000000..dbfe70d259
--- /dev/null
+++ b/tools/libs/manage/Makefile
@@ -0,0 +1,10 @@
+XEN_ROOT = $(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+MAJOR    = 1
+MINOR    = 0
+version-script := libxenmanage.map
+
+include Makefile.common
+
+include $(XEN_ROOT)/tools/libs/libs.mk
diff --git a/tools/libs/manage/Makefile.common b/tools/libs/manage/Makefile.common
new file mode 100644
index 0000000000..533ba30fba
--- /dev/null
+++ b/tools/libs/manage/Makefile.common
@@ -0,0 +1,3 @@
+CFLAGS += -D__XEN_TOOLS__
+
+OBJS-y  += core.o
diff --git a/tools/libs/manage/core.c b/tools/libs/manage/core.c
new file mode 100644
index 0000000000..b5fa67b036
--- /dev/null
+++ b/tools/libs/manage/core.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright (c) 2024 SUSE Software Solutions Germany GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see .
+ */
+
+#define _GNU_SOURCE
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct xenmanage_handle {
+    xentoollog_logger *logger, *logger_tofree;
+    unsigned int flags;
+    xencall_handle *xcall;
+};
+
+xenmanage_handle *xenmanage_open(xentoollog_logger *logger,
+                                 unsigned open_flags)
+{
+    xenmanage_handle *hdl = calloc(1, sizeof(*hdl));
+    int saved_errno;
+
+    if ( !hdl )
+        return NULL;
+
+    if ( open_flags )
+    {
+        errno = EINVAL;
+        goto err;
+    }
+
+    hdl->flags = open_flags;
+    hdl->logger = logger;
+    hdl->logger_tofree = NULL;
+
+    if ( !hdl->logger )
+    {
+        hdl->logger = hdl->logger_tofree =
+            (xentoollog_logger *)
+            xtl_createlogger_stdiostream(stderr, XTL_PROGRESS, 0);
+        if ( !hdl->logger )
+            goto err;
+    }
+
+    hdl->xcall = xencall_open(hdl->logger, 0);
+    if ( !hdl->xcall )
+        goto err;
+
+    return hdl;
+
+err:
+    saved_errno = errno;
+    xenmanage_close(hdl);
+    errno = saved_errno;
+
+    return NULL;
+}
+
+int xenmanage_close(xenmanage_handle *hdl)
+{
+    if ( !hdl )
+        return 0;
+
+    xencall_close(hdl->xcall);
+    xtl_logger_destroy(hdl->logger_tofree);
+    free(hdl);
+    return 0;
+}
+
+static int xenmanage_do_domctl_get_domain_state(xenmanage_handle *hdl,
+                                                unsigned int domid_in,
+                                                unsigned int *domid_out,
+                                                unsigned int *state,
+                                                uint64_t *unique_id)
+{
+    struct xen_domctl *buf;
+    int saved_errno;
+    int ret;
+
+    buf = xencall_alloc_buffer(hdl->xcall, sizeof(*buf));
+    if ( !buf )
+    {
+        errno = ENOMEM;
+        return -1;
+    }
+
+    memset(buf, 0, sizeof(*buf));
+
+    buf->cmd = XEN_DOMCTL_get_domain_state;
+    buf->domain = domid_in;
+
+    ret = xencall1(hdl->xcall, __HYPERVISOR_domctl, (unsigned long)buf);
+    saved_errno = errno;
+    if ( !ret )
+    {
+        struct xen_domctl_get_domain_state *st = &buf->u.get_domain_state;
+
+        if ( domid_out )
+            *domid_out = buf->domain;
+        if ( state )
+        {
+            *state = 0;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_EXIST )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_EXIST;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_SHUTDOWN )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_DYING )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_DYING;
+            if ( st->state & XEN_DOMCTL_GETDOMSTATE_STATE_DEAD )
+                *state |= XENMANAGE_GETDOMSTATE_STATE_DEAD;
+        }
+        if ( unique_id )
+            *unique_id = st->unique_id;
+    }
+
+    xencall_free_buffer(hdl->xcall, buf);
+
+    errno = saved_errno;
+
+    return ret;
+}
+
+int xenmanage_get_domain_info(xenmanage_handle *hdl, unsigned int domid,
+                              unsigned int *state, uint64_t *unique_id)
+{
+    if ( !hdl || domid >= DOMID_FIRST_RESERVED )
+    {
+        errno = EINVAL;
+        return -1;
+    }
+
+    return xenmanage_do_domctl_get_domain_state(hdl, domid, NULL, state,
+                                                unique_id);
+}
+
+int xenmanage_poll_changed_domain(xenmanage_handle *hdl, unsigned int *domid,
+                                  unsigned int *state, uint64_t *unique_id)
+{
+    if ( !hdl || !domid )
+    {
+        errno = EINVAL;
+        return -1;
+    }
+
+    return xenmanage_do_domctl_get_domain_state(hdl, DOMID_INVALID, domid,
+                                                state, unique_id);
+}
diff --git a/tools/libs/manage/libxenmanage.map b/tools/libs/manage/libxenmanage.map
new file mode 100644
index 0000000000..64c793e603
--- /dev/null
+++ b/tools/libs/manage/libxenmanage.map
@@ -0,0 +1,8 @@
+VERS_1.0 {
+	global:
+		xenmanage_open;
+		xenmanage_close;
+		xenmanage_get_domain_info;
+		xenmanage_poll_changed_domain;
+	local: *; /* Do not expose anything by default */
+};
diff --git a/tools/libs/uselibs.mk b/tools/libs/uselibs.mk
index 7aa8d83e06..c0a234cfec 100644
--- a/tools/libs/uselibs.mk
+++ b/tools/libs/uselibs.mk
@@ -16,6 +16,8 @@ LIBS_LIBS += devicemodel
 USELIBS_devicemodel := toollog toolcore call
 LIBS_LIBS += hypfs
 USELIBS_hypfs := toollog toolcore call
+LIBS_LIBS += manage
+USELIBS_manage := toollog toolcore call
 LIBS_LIBS += ctrl
 USELIBS_ctrl := toollog call evtchn gnttab foreignmemory devicemodel
 LIBS_LIBS += guest
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 14:22:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 14:22:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859221.1271383 (Exim 4.92)
	(envelope-from )
	id 1tNYTM-0005mv-6e; Tue, 17 Dec 2024 14:22:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859221.1271383; Tue, 17 Dec 2024 14: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 1tNYTM-0005mo-2a; Tue, 17 Dec 2024 14:22:52 +0000
Received: by outflank-mailman (input) for mailman id 859221;
 Tue, 17 Dec 2024 14:22: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 1tNYTL-0004FJ-07
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 14:22:51 +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 65161c56-bc82-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 15:22:50 +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 CD888211ED;
 Tue, 17 Dec 2024 14:22:49 +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 9CAF513AD8;
 Tue, 17 Dec 2024 14:22:49 +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 tySbJDmJYWeKDgAAD6G6ig
 (envelope-from ); Tue, 17 Dec 2024 14:22: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: 65161c56-bc82-11ef-a0d6-8be0dac302b0
Authentication-Results: smtp-out1.suse.de;
	none
From: Juergen Gross 
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ,
	Anthony PERARD ,
	Samuel Thibault ,
	Julien Grall 
Subject: [PATCH v5 5/5] tools/xenstored: use new stable interface instead of libxenctrl
Date: Tue, 17 Dec 2024 15:22:18 +0100
Message-ID: <20241217142218.24129-6-jgross@suse.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217142218.24129-1-jgross@suse.com>
References: <20241217142218.24129-1-jgross@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Spamd-Result: default: False [-4.00 / 50.00];
	REPLY(-4.00)[]
X-Spam-Flag: NO
X-Spam-Score: -4.00
X-Rspamd-Queue-Id: CD888211ED
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Action: no action
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Level: 

Replace the current use of the unstable xc_domain_getinfo_single()
interface with the stable domctl XEN_DOMCTL_get_domain_state call
via the new libxenmanage library.

This will remove the last usage of libxenctrl by Xenstore, so update
the library dependencies accordingly.

For now only do a direct replacement without using the functionality
of obtaining information about domains having changed the state.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
V1:
- use library instead of direct hypercall, only replace current
  libxenctrl use case

Please note that this patch can be committed only after the related
Mini-OS patch "config: add support for libxenmanage" has gone in AND
the Mini-OS commit-id has been updated in Config.mk accordingly!

Signed-off-by: Juergen Gross 
---
 stubdom/Makefile                |  8 ++---
 stubdom/mini-os.mk              |  1 +
 tools/xenstored/Makefile        |  2 +-
 tools/xenstored/Makefile.common |  2 +-
 tools/xenstored/core.h          |  1 -
 tools/xenstored/domain.c        | 52 ++++++++++++---------------------
 tools/xenstored/lu.c            |  1 +
 tools/xenstored/lu_daemon.c     |  1 +
 8 files changed, 28 insertions(+), 40 deletions(-)

diff --git a/stubdom/Makefile b/stubdom/Makefile
index 2a81af28a1..ca800b243c 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -307,7 +307,7 @@ endif
 # libraries under tools/libs
 #######
 
-STUB_LIBS := toolcore toollog evtchn gnttab call foreignmemory devicemodel ctrl guest
+STUB_LIBS := toolcore toollog evtchn gnttab call foreignmemory devicemodel ctrl guest manage
 
 LIBDEP_guest := cross-zlib
 
@@ -465,7 +465,7 @@ grub: cross-polarssl grub-upstream $(CROSS_ROOT) grub-$(XEN_TARGET_ARCH)-minios-
 # xenstore
 ##########
 
-xenstore-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog ctrl
+xenstore-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog manage
 xenstore-minios.gen.cfg: xenstore-minios.cfg Makefile
 	$(GEN_config) >$@
 
@@ -480,7 +480,7 @@ xenstore: $(CROSS_ROOT) xenstore-minios-config.mk
 # xenstorepvh
 #############
 
-xenstorepvh-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog ctrl
+xenstorepvh-minios.gen.cfg: APP_LIBS = gnttab evtchn toollog manage
 xenstorepvh-minios.gen.cfg: xenstorepvh-minios.cfg Makefile
 	$(GEN_config) >$@
 
@@ -523,7 +523,7 @@ else
 pv-grub-if-enabled:
 endif
 
-XENSTORE_DEPS := libxenevtchn libxengnttab libxenctrl
+XENSTORE_DEPS := libxenevtchn libxengnttab libxenmanage
 
 .PHONY: xenstore-stubdom
 xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore $(XENSTORE_DEPS) xenstore
diff --git a/stubdom/mini-os.mk b/stubdom/mini-os.mk
index 7e4968e026..be32302f9e 100644
--- a/stubdom/mini-os.mk
+++ b/stubdom/mini-os.mk
@@ -13,5 +13,6 @@ GNTTAB_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/gnttab
 CALL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/call
 FOREIGNMEMORY_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/foreignmemory
 DEVICEMODEL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/devicemodel
+MANAGE_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/manage
 CTRL_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/ctrl
 GUEST_PATH = $(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/guest
diff --git a/tools/xenstored/Makefile b/tools/xenstored/Makefile
index 09adfe1d50..81c42838e0 100644
--- a/tools/xenstored/Makefile
+++ b/tools/xenstored/Makefile
@@ -5,7 +5,7 @@ include Makefile.common
 
 xenstored: LDLIBS += $(LDLIBS_libxenevtchn)
 xenstored: LDLIBS += $(LDLIBS_libxengnttab)
-xenstored: LDLIBS += $(LDLIBS_libxenctrl)
+xenstored: LDLIBS += $(LDLIBS_libxenmanage)
 xenstored: LDLIBS += -lrt
 xenstored: LDLIBS += $(SOCKET_LIBS)
 
diff --git a/tools/xenstored/Makefile.common b/tools/xenstored/Makefile.common
index 27fdb3b49e..271134fcc1 100644
--- a/tools/xenstored/Makefile.common
+++ b/tools/xenstored/Makefile.common
@@ -12,7 +12,7 @@ XENSTORED_OBJS-$(CONFIG_MiniOS) += minios.o lu_minios.o
 # Include configure output (config.h)
 CFLAGS += -include $(XEN_ROOT)/tools/config.h
 CFLAGS += $(CFLAGS_libxenevtchn)
-CFLAGS += $(CFLAGS_libxenctrl)
+CFLAGS += $(CFLAGS_libxenmanage)
 CFLAGS += $(CFLAGS_libxentoolcore)
 
 $(XENSTORED_OBJS-y): CFLAGS += $(CFLAGS_libxengnttab)
diff --git a/tools/xenstored/core.h b/tools/xenstored/core.h
index e58779e88c..632886cecf 100644
--- a/tools/xenstored/core.h
+++ b/tools/xenstored/core.h
@@ -19,7 +19,6 @@
 #ifndef _XENSTORED_CORE_H
 #define _XENSTORED_CORE_H
 
-#include 
 #include 
 
 #include 
diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c
index 64c8fd0cc3..a6506a5bb2 100644
--- a/tools/xenstored/domain.c
+++ b/tools/xenstored/domain.c
@@ -34,14 +34,15 @@
 #include "control.h"
 
 #include 
-#include 
+#include 
+#include 
 #include 
 
 #ifdef __MINIOS__
 #include 
 #endif
 
-static xc_interface **xc_handle;
+static xenmanage_handle *xm_handle;
 xengnttab_handle **xgt_handle;
 static evtchn_port_t virq_port;
 
@@ -619,32 +620,28 @@ static int destroy_domain(void *_domain)
 	return 0;
 }
 
-static bool get_domain_info(unsigned int domid, xc_domaininfo_t *dominfo)
-{
-	return xc_domain_getinfo_single(*xc_handle, domid, dominfo) == 0;
-}
-
 static int check_domain(const void *k, void *v, void *arg)
 {
-	xc_domaininfo_t dominfo;
+	unsigned int state;
 	struct connection *conn;
-	bool dom_valid;
+	int dom_invalid;
 	struct domain *domain = v;
 	bool *notify = arg;
 
-	dom_valid = get_domain_info(domain->domid, &dominfo);
+	dom_invalid = xenmanage_get_domain_info(xm_handle, domain->domid,
+						&state, NULL);
 	if (!domain->introduced) {
-		if (!dom_valid)
+		if (dom_invalid)
 			talloc_free(domain);
 		return 0;
 	}
-	if (dom_valid) {
-		if ((dominfo.flags & XEN_DOMINF_shutdown)
+	if (!dom_invalid) {
+		if ((state & XENMANAGE_GETDOMSTATE_STATE_SHUTDOWN)
 		    && !domain->shutdown) {
 			domain->shutdown = true;
 			*notify = true;
 		}
-		if (!(dominfo.flags & XEN_DOMINF_dying))
+		if (!(state & XENMANAGE_GETDOMSTATE_STATE_DEAD))
 			return 0;
 	}
 	if (domain->conn) {
@@ -786,10 +783,9 @@ static struct domain *find_or_alloc_domain(const void *ctx, unsigned int domid)
 static struct domain *find_or_alloc_existing_domain(unsigned int domid)
 {
 	struct domain *domain;
-	xc_domaininfo_t dominfo;
 
 	domain = find_domain_struct(domid);
-	if (!domain && get_domain_info(domid, &dominfo))
+	if (!domain && !xenmanage_get_domain_info(xm_handle, domid, NULL, NULL))
 		domain = alloc_domain(NULL, domid);
 
 	return domain;
@@ -1187,12 +1183,6 @@ int do_reset_watches(const void *ctx, struct connection *conn,
 	return 0;
 }
 
-static int close_xc_handle(void *_handle)
-{
-	xc_interface_close(*(xc_interface**)_handle);
-	return 0;
-}
-
 static int close_xgt_handle(void *_handle)
 {
 	xengnttab_close(*(xengnttab_handle **)_handle);
@@ -1258,15 +1248,9 @@ void domain_early_init(void)
 	if (!domhash)
 		barf_perror("Failed to allocate domain hashtable");
 
-	xc_handle = talloc(talloc_autofree_context(), xc_interface*);
-	if (!xc_handle)
-		barf_perror("Failed to allocate domain handle");
-
-	*xc_handle = xc_interface_open(0,0,0);
-	if (!*xc_handle)
-		barf_perror("Failed to open connection to hypervisor");
-
-	talloc_set_destructor(xc_handle, close_xc_handle);
+	xm_handle = xenmanage_open(NULL, 0);
+	if (!xm_handle)
+		barf_perror("Failed to open connection to libxenmanage");
 
 	xgt_handle = talloc(talloc_autofree_context(), xengnttab_handle*);
 	if (!xgt_handle)
@@ -1306,6 +1290,8 @@ void domain_deinit(void)
 {
 	if (virq_port)
 		xenevtchn_unbind(xce_handle, virq_port);
+
+	xenmanage_close(xm_handle);
 }
 
 /*
@@ -1335,13 +1321,13 @@ int domain_alloc_permrefs(struct node_perms *perms)
 {
 	unsigned int i, domid;
 	struct domain *d;
-	xc_domaininfo_t dominfo;
 
 	for (i = 0; i < perms->num; i++) {
 		domid = perms->p[i].id;
 		d = find_domain_struct(domid);
 		if (!d) {
-			if (!get_domain_info(domid, &dominfo))
+			if (xenmanage_get_domain_info(xm_handle, domid,
+						      NULL, NULL))
 				perms->p[i].perms |= XS_PERM_IGNORE;
 			else if (!alloc_domain(NULL, domid))
 				return ENOMEM;
diff --git a/tools/xenstored/lu.c b/tools/xenstored/lu.c
index bec2a84e10..4fccbbc195 100644
--- a/tools/xenstored/lu.c
+++ b/tools/xenstored/lu.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/tools/xenstored/lu_daemon.c b/tools/xenstored/lu_daemon.c
index 6df6c80a2a..88d8d9e1b3 100644
--- a/tools/xenstored/lu_daemon.c
+++ b/tools/xenstored/lu_daemon.c
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 #include 
 
 #include "talloc.h"
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 14:41:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 14:41:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859276.1271392 (Exim 4.92)
	(envelope-from )
	id 1tNYla-0001aS-NS; Tue, 17 Dec 2024 14:41:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859276.1271392; Tue, 17 Dec 2024 14: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 1tNYla-0001aL-Ky; Tue, 17 Dec 2024 14:41:42 +0000
Received: by outflank-mailman (input) for mailman id 859276;
 Tue, 17 Dec 2024 14:41: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 1tNYlY-0001aE-VY
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 14:41:41 +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 06038481-bc85-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 15:41:39 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-4361b0ec57aso52854935e9.0
 for ; Tue, 17 Dec 2024 06:41: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
 ffacd0b85a97d-388c80601desm11318680f8f.90.2024.12.17.06.41.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 06:41:38 -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: 06038481-bc85-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734446498; x=1735051298; 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=IGIiE5nXPSdxpWn1Ea/upPyLjrOSFuw1lO2GkhdBkEk=;
        b=HekXA5+FAAc18h5EObAS9Oxyx5bGekq4lnkSkYrqnyPiwufaPbYUt2Df/6CXV979l8
         dqmFTsvs8aS0FjovPOWI0W/aD6LnXMUEPk1CN29uOBkk9Fb1kzFOQr62+ITFltwjGmkt
         xHWhf374XLh/xMb1DweqamEqojPTYpW+XngcB53dzMTGnYYxjIWLfsd7HP4bqpCs9tJr
         BS9rfxe5NO6OZIW/OjyJOCsj4NnNHqS5FPht785T2yLLfxdlh2QUF7fOz06SVV3JTkCX
         mmuo8Hclz3xOyHX8CLIk0CsWKWI/Mwh0uWW5BPNLXkQshQHqsgMxd/clvnBOHyvMmxoF
         Vd0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734446498; x=1735051298;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=IGIiE5nXPSdxpWn1Ea/upPyLjrOSFuw1lO2GkhdBkEk=;
        b=PU/ubGBGIcuQ4+FySKFRFP5VkbNSnwA802KQDaCjgURbvSTD+LxHs8k6F3sk9AHQuU
         vEC+qkZSugDIHAD+f3J1HsGPVQBUIw5/EGItUxNaJ0PJk3tpJLWPYf0fkKL4T+m8YXAY
         L2aC6UdUUxRRUtfcp86N/vsTPLw7Pvr3WzThOsGvB5AbDOTHpk6pIumcVjALEwvfpG7R
         3Q9hckaS5vCmRfgkGLOZEDEB6OknwgQMThcntD5w3dVcB4iTyqHYYYYxNBNCrjOIzMX0
         s3Iitp7mmce4XXRTXoUerMBoZFrpqCmFGITuMqdVD5vVXv2ieYTqA2B9uwE8OHEAvr87
         EoFA==
X-Forwarded-Encrypted: i=1; AJvYcCXeQwoCGmQsBl+vIhzg8hgL2wyBqZVdV+H+hMpgIDMuRkgOBULWlXVRGbRBQ2iRuay0hVeLUOGRWvM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzsVy95juAoeEVlWC+anhhppECVCasJ+glt1of+gRlrM1InaYZf
	6jJKrwm7lOAw7B1k7C12AvGlYdD0BPUlFuSfNz7Wt5WlgV9/NdhSq07O2JjlEQ==
X-Gm-Gg: ASbGncu6b+rvTmRZuLz+dwVOh1nHH852gqV+YbagN8DXGSizc/IQE7jL0i/3OeroeBk
	B4QXdTIV1Uyhp93nuyeyTjMd8wCVRCOFD1D4PlTyJYjqpgx0XvgKiMVqgXrSl1IaXViPMhdB0mU
	Z755gXaGIU11+/TKMqwt5bOMsEu0cLngrRtTZqYTh8Xao35YKHr52fR0xkKbCuPPgFoN4VvK32t
	W6v49NmYP/A01uSHSfEeg6wv2/tnnEkrV0U304SBnzYRcKZFXi8iAM5Q2g3TRoooLSzSHeWwaUL
	FYi/eU9q2GCMpX9iKdQ2GmZzcr7GUv8rhu6XrXeLIg==
X-Google-Smtp-Source: AGHT+IFcmM7MFVmVdHBt5xSpXewNEV6y+O/CCUwYClWubnSAvJsT44J1wEL+QADxh74btqDbY/BU9A==
X-Received: by 2002:a05:600c:1da6:b0:434:a746:9c82 with SMTP id 5b1f17b1804b1-4362aa26e46mr123041945e9.5.1734446498520;
        Tue, 17 Dec 2024 06:41:38 -0800 (PST)
Message-ID: <6ee25017-db0f-4928-a07a-89558035a3f9@suse.com>
Date: Tue, 17 Dec 2024 15:41:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 3/5] xen: add new domctl get_changed_domain
To: Juergen Gross 
Cc: "Daniel P. Smith" ,
 Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241217142218.24129-1-jgross@suse.com>
 <20241217142218.24129-4-jgross@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: <20241217142218.24129-4-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.12.2024 15:22, Juergen Gross wrote:
> Add a new domctl sub-function to get data of a domain having changed
> state (this is needed by Xenstore).
> 
> The returned state just contains the domid, the domain unique id,
> and some flags (existing, shutdown, dying).
> 
> In order to enable Xenstore stubdom being built for multiple Xen
> versions, make this domctl stable.  For stable domctls the
> interface_version is always 0.
> 
> Signed-off-by: Juergen Gross 

As before:
Reviewed-by: Jan Beulich  # non-XSM/Flask




From xen-devel-bounces@lists.xenproject.org Tue Dec 17 15:13:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 15:13:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859299.1271429 (Exim 4.92)
	(envelope-from )
	id 1tNZG8-0006rW-O5; Tue, 17 Dec 2024 15:13:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859299.1271429; Tue, 17 Dec 2024 15:13:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNZG8-0006rN-Jb; Tue, 17 Dec 2024 15:13:16 +0000
Received: by outflank-mailman (input) for mailman id 859299;
 Tue, 17 Dec 2024 15:13:15 +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 1tNZG7-0006c0-B8
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 15:13:15 +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 6f2c8657-bc89-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 16:13:13 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-385e1fcb0e1so2974749f8f.2
 for ; Tue, 17 Dec 2024 07:13:13 -0800 (PST)
Received: from localhost.localdomain ([78.196.4.158])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c80162ddsm11384835f8f.37.2024.12.17.07.13.11
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 17 Dec 2024 07:13: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: 6f2c8657-bc89-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1734448393; x=1735053193; 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=FH/72suxrUOMAatoct7CthEOn0DQXdaIvd71YSiEkl8=;
        b=O+1iYhE5S5QxXTDTkArjshFQxaipY+fJw+RBQDG+1q317qF4VKyK1h6OQ3yuy3POMb
         5TqXq66FTMwZmk3lDGNqm2IoWBrCS/CrddTLx+HbCEuVc+WVksQHzZtBlJqEvvIkDD79
         VhaEpsZwonB1I0cIMRFJFqfDQAOMkSDzE0tBsKu5GVAUEi+Wb8mxVkuSghvDg6IRnWdQ
         tFntYyBIArjskZusRHIYDUQMt1BTTE8R2JMP1qAZidMz2zP4ZfoP3/lr5wmL2FQnkNPv
         18v9KZBvi2L+OgwgVc5UaEmVLMW/JW8AGkrsjdeVRJY3oSsp6tjbnigXkdAJGRod8Rkf
         y9AQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734448393; x=1735053193;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=FH/72suxrUOMAatoct7CthEOn0DQXdaIvd71YSiEkl8=;
        b=uhDMw9xKoRdaR7BpiLtwaepWvCQ4FIvRe59UHZ9/BNMmqN6tgPOPMRqnRFu6UyaTCd
         gZ9aDV6s0DdizaiWhQqP4YjWWJj9LC9lZjVZgVxsrjB8PRXVYybZQbgmbRHTe7AHU4MS
         P8yf7T0RzeLtQo4t4zUgYyW9+rn3Cd5jnxMX8ZYumvtiDp8Whg+NJFVOdd8Pq4OCSrkZ
         Goevq50ZaZY4bShiW9FdjMXhpOKaHUMXrt/xs9XiaR18PUVV3Maedt0xDgmNSKZDiRtm
         kIZhB7AzQdxjIqJRoAaIOGfIYyZOB1VXG3dwuo4XsxtneGnO8eFW/DsN5DhKOlbBOyWq
         JX2A==
X-Forwarded-Encrypted: i=1; AJvYcCUcUy+kATN8mi0uGcjsdqrLnbIFY4Kqj0z0ejrQSTjPpeQJ5A05LilTS2YCODrKuvYijm/8YxiJWkE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzEZBtxVKGfI2VrCnHCz1sQ8f4YHzZbKjuZpdpVg99SpdQIjZhN
	q64rZ/Z6ib1zpVzByK48ULq2p5TJmLLglOjOaKWVczyEi1J+HsHalC8+N+2Yfc4=
X-Gm-Gg: ASbGncsiBfedCnlRt1rPyVitZ886sxN+qUan0Imfhf7RvP0LJdx5LhkAkdNqtLUHjwb
	foyJ/q00vyPgB6AVxFUpKTqtSYB2s4E9MstrUn+++ES298aHSVmFJtOwq34gfX6anwiZKpfgmPx
	E8nlAeqf3upmjcMjLeLiodx47W5d6heEnOMhRlq9pQ7CKr+BT55AiaxZ+BCSYQTMnR0IkXu4YwC
	Mzug8RwJdpEEuRm0G7LcOyuNpedFlsidaOFvsU8omkHRyGNzpaI5XwM9VVUZ6LBDd4pdV49qQFR
	vs8c
X-Google-Smtp-Source: AGHT+IE3RmiEs/P0yDnumj2ykAGCoV0c6wATPDpTgTGtoE5l2Mfa/4IktujX2VH2nZS0c49GlFQyYw==
X-Received: by 2002:a05:6000:4715:b0:385:e1e5:fff3 with SMTP id ffacd0b85a97d-388da5b7cc2mr3362824f8f.57.1734448392938;
        Tue, 17 Dec 2024 07:13:12 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Zhao Liu ,
	"Edgar E. Iglesias" ,
	Paul Durrant ,
	Richard Henderson ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Yanan Wang ,
	Anton Johansson ,
	Anthony PERARD ,
	xen-devel@lists.xenproject.org
Subject: [PATCH 1/3] hw/xen: Remove unnecessary 'exec/cpu-common.h' header
Date: Tue, 17 Dec 2024 16:13:03 +0100
Message-ID: <20241217151305.29196-2-philmd@linaro.org>
X-Mailer: git-send-email 2.45.2
In-Reply-To: <20241217151305.29196-1-philmd@linaro.org>
References: <20241217151305.29196-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Nothing requires definitions from "exec/cpu-common.h",
do not include this header.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/xen/xen.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index ecb89ecfc14..e94c6e5a318 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -24,8 +24,6 @@
 #define __XEN_INTERFACE_VERSION__ 0x00040e00
 #endif
 
-#include "exec/cpu-common.h"
-
 /* xen-machine.c */
 enum xen_mode {
     XEN_DISABLED = 0, /* xen support disabled (default) */
-- 
2.45.2



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 15:13:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 15:13:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859298.1271419 (Exim 4.92)
	(envelope-from )
	id 1tNZG4-0006cF-H1; Tue, 17 Dec 2024 15:13:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859298.1271419; Tue, 17 Dec 2024 15:13: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 1tNZG4-0006c8-Co; Tue, 17 Dec 2024 15:13:12 +0000
Received: by outflank-mailman (input) for mailman id 859298;
 Tue, 17 Dec 2024 15:13: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 1tNZG3-0006c0-Lz
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 15:13:11 +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 6c1ff820-bc89-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 16:13:08 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-385e87b25f0so4266115f8f.0
 for ; Tue, 17 Dec 2024 07:13:08 -0800 (PST)
Received: from localhost.localdomain ([78.196.4.158])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c8060582sm11225037f8f.93.2024.12.17.07.13.06
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 17 Dec 2024 07:13: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: 6c1ff820-bc89-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1734448388; x=1735053188; 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=nhjwbb2cLaV8+g7K6eWDoGH3jLVsHMMck+CiKHhGFfc=;
        b=M9ctBrWjCHNsfOMZGep3NeEhxYv8ZsgHGr3SCmg0ou+pcBpyZUV5I4OGz5L+pcbvah
         I+ppmYJk3SrgOWylhNGkONOdPXDoGk8zsHEeLmhmsHT8evWHVHmd0Su42uu7wZNoXSDh
         J0KrTQGeOXf2LHoU1O6GLJpKdqx9bbeqCooc3yOyDPYQp7LolPKcOnynsEtlCtePFQfE
         8OULWa3EbEcOyRe+mcU+wm2T2DiQ5CQqJYqfDnp8Arh0gSP496hLMZf6w/CnHL/y5zn1
         gB6pKj/9kcb4XZPUamDfHCmVOL2+WgjRJA6OqCvESfrATLivrN5zkTSUmZxxV+71IPT5
         o+5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734448388; x=1735053188;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=nhjwbb2cLaV8+g7K6eWDoGH3jLVsHMMck+CiKHhGFfc=;
        b=n5kzvF3qP7tq9Aua+Dr8o96vQkC4G7/b8GZu3mgdnnjGhwE0KUA2rJXzxDfDKzOKv+
         90qiCsHSkIEVkojlmc1Ty1tA02HMyy8RTifYjefZmVJcjL+yZNua5z0+wvRnp9p4yIjL
         +OKJdUK8qZPO3NLKSOyO9EM7ZXuQyIyegBDcFYiQqn8GPPxGDcD1KgxpTYfqCE12/euK
         oLuG0L/6qV/W5W0PvG2b8CzoeNWSzcPJAKIDvKzTcssS0OmvMmmgCuCCKOm7K7P+wQF9
         o1H7WZUXIEuoFISRAMkD4sMLT/U/3Hals/S5iywrQLAW4atSThW9Gpo6m60wYh2Ic1gn
         k/Ug==
X-Forwarded-Encrypted: i=1; AJvYcCUCPJ7X04JyKWZZL+FhX01ayJBnInqHu05Kten13vWWqUB3LrwAqX25nr97DLhemf/W7qfSYyZdwz8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw08kvCue4VCf7abTA1pX+W7dQWCIRRVUd5Z5nR2yr96f57Z6RB
	ypdxVJE8rY0y2Mc6IRtxLjG2i2eIhyAeR3WdQOzV5KEdDgOKe4/s7OHdacUW2yU=
X-Gm-Gg: ASbGnctwnlEO6rUlK4kDHpaMIVO1wY3VcLElqDzC0CSyb+YebyMlDqXDeog7djyT69o
	M/mKRJ/G9CvxD1LMtbEYmwEAWe99rcBwvQhNC2QzPMZHVIICuTXYrxxcndwq0k7aHWDUYLOoUVp
	7yMTr6FeAxOfOPpk6DhxLkP5vllAYql5KPOnN0VG1d2LFBbqxODqJWkq4bOFU9gtyqq83HWWYWP
	gpnTelv8wZt/tywd7GLIjSRHc5RynLZsV6joaNUmutr9cjMqkswZS457gZCiyaMs4hS0MUvd5ne
	U6ii
X-Google-Smtp-Source: AGHT+IGhZvwcrecH/l3tzZxp/9lmRQKKnuH2G+g15sJ2oF8K5YoB0LcEYki3ScgNkajyj1I0/t17Gw==
X-Received: by 2002:adf:e0c6:0:b0:385:fa30:4f87 with SMTP id ffacd0b85a97d-388daf909b5mr3090065f8f.0.1734448387783;
        Tue, 17 Dec 2024 07:13:07 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Zhao Liu ,
	"Edgar E. Iglesias" ,
	Paul Durrant ,
	Richard Henderson ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Yanan Wang ,
	Anton Johansson ,
	Anthony PERARD ,
	xen-devel@lists.xenproject.org
Subject: [PATCH 0/3] include: Cleanups around 'exec/cpu-common.h' header
Date: Tue, 17 Dec 2024 16:13:02 +0100
Message-ID: <20241217151305.29196-1-philmd@linaro.org>
X-Mailer: git-send-email 2.45.2
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Do not include "exec/cpu-common.h" when we don't need it.

(I plan to merge this series myself).

Philippe Mathieu-Daudé (3):
  hw/xen: Remove unnecessary 'exec/cpu-common.h' header
  system/numa: Remove unnecessary 'exec/cpu-common.h' header
  system/accel-ops: Remove unnecessary 'exec/cpu-common.h' header

 include/hw/xen/xen.h       | 2 --
 include/sysemu/accel-ops.h | 2 +-
 include/sysemu/numa.h      | 1 -
 3 files changed, 1 insertion(+), 4 deletions(-)

-- 
2.45.2



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 15:13:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 15:13:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859300.1271438 (Exim 4.92)
	(envelope-from )
	id 1tNZGD-00078S-U4; Tue, 17 Dec 2024 15:13:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859300.1271438; Tue, 17 Dec 2024 15:13:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNZGD-00078J-R3; Tue, 17 Dec 2024 15:13:21 +0000
Received: by outflank-mailman (input) for mailman id 859300;
 Tue, 17 Dec 2024 15:13: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 1tNZGC-0006c0-6P
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 15:13:20 +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 7246274f-bc89-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 16:13:18 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-436202dd730so39118465e9.2
 for ; Tue, 17 Dec 2024 07:13:18 -0800 (PST)
Received: from localhost.localdomain ([78.196.4.158])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c8049facsm11612456f8f.79.2024.12.17.07.13.16
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 17 Dec 2024 07:13: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: 7246274f-bc89-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1734448398; x=1735053198; 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=S6S2xlttjp4VhpiTH5RBxnctIn3RW53HPZ3WyhXqjYw=;
        b=HvsB7Q21FpA0Tz9szeDYNBM0tG1RvTH18bFEc7AuLhOHD97bSLgK34nQEInpguMPps
         9WK2twMxq6CuLmScEh6j82LmtNsgyIPBOXtyAPsdngM0SrU/jBsQYWz/xBKS3M9T3NRb
         mSl1+XltjiQI6c7sw71WRH+mScsh6OB5xdDpzLDyRbSptXVZCZiJIbeqj/gGhuu4VOtw
         kWI8ESrnMB6yEMxk66OvRS3gzeAZ4NZKChYdRwq9DoZ6xZMrIXM1AMqkH1UXta1xLnB0
         dl4+yRXclOBUEKeRspyB/5L1xTr9qq8oHLoayBL0CriytF7wM37vclew6ir2rzAQ1Wfr
         sF5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734448398; x=1735053198;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=S6S2xlttjp4VhpiTH5RBxnctIn3RW53HPZ3WyhXqjYw=;
        b=CFNJTAW32Ph3q8GJQ3v8YNbNb3fayJ77zYhprG9No4B9ImbbOr4kV1kVQBRWEZtaje
         vCimro9MnDCoOSfHXm8LnZBJa03SCyQuRT8DS0DzXO2ogd8UUrl9y84wGZ8nh1DijOLX
         1tKptKApU72DLRG9CSoCmyDi07VQSe112yNh94Zy4QuASAgTZYGUW/6osXvXE4HE54Z/
         fZnCXLBRICvpkY6PmfYYZngruCJm2bi16FkAx5Z9j2YO3jntgL4Cu2kOAHVEZoxLyRvV
         qqL49n2cOBS5aiKVndZU2b75zZbOSHGWBtRAZ7td7Q48alQlMomejQidt6a6YnAZgksP
         Y2KA==
X-Forwarded-Encrypted: i=1; AJvYcCWR3wXhMSYtWilJ8pKF6r+b5JRYdFjxejeYevwReVmDNw5nnrr3QZ4nqRT4Cs8906+kOHLSwPt7TxE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw+TQKkGV9PeebeAUQDxxp2eKEXmbq9qA/IqP5Ob5d1x6uJifHA
	R+bRTL7lEOt7551l7+Ij8eFE0H/mtM1/tmkGohzIadpf7BX+fkN3IplRSW+dKPI=
X-Gm-Gg: ASbGncsM4+r4VgMJ9/jQmvVPbxa5OqVeodcZwCvblRu698O9Rl92WzKU48mTsz/NiA8
	g4rOaQAlgVowwi0+KC7oM0jAE0c1Q+O1kyOxPrY7PEbnqGpHbZ3rgNXt+rUH9GhknqknIk3MjT9
	vXadW2vG2MuPq7PeRWdcXgnMvRGvf0buwhhPput77uPJGF8seIoP97ZR88Z0UPDBLeX4nfNyfwV
	AxJwkCGz+JL7rVS2wHUSCrb5cubKfL3qzR4/Vuf9ETBH3PkyN5x5R79mcAa/09ZMqF8+uDu7/my
	ZY+P
X-Google-Smtp-Source: AGHT+IGcIc9C+9xF7u7hW0QxoRTcmmxZgIQEQHrG2A+QXqPWKTn7jmn5F5uLxS1c0rghk9D+Onu6dA==
X-Received: by 2002:a05:6000:4012:b0:385:f220:f788 with SMTP id ffacd0b85a97d-3888e0c0656mr14540012f8f.48.1734448397845;
        Tue, 17 Dec 2024 07:13:17 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Zhao Liu ,
	"Edgar E. Iglesias" ,
	Paul Durrant ,
	Richard Henderson ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Yanan Wang ,
	Anton Johansson ,
	Anthony PERARD ,
	xen-devel@lists.xenproject.org
Subject: [PATCH 2/3] system/numa: Remove unnecessary 'exec/cpu-common.h' header
Date: Tue, 17 Dec 2024 16:13:04 +0100
Message-ID: <20241217151305.29196-3-philmd@linaro.org>
X-Mailer: git-send-email 2.45.2
In-Reply-To: <20241217151305.29196-1-philmd@linaro.org>
References: <20241217151305.29196-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Nothing requires definitions from "exec/cpu-common.h",
do not include this header.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/sysemu/numa.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/sysemu/numa.h b/include/sysemu/numa.h
index 04676141470..1338db9502d 100644
--- a/include/sysemu/numa.h
+++ b/include/sysemu/numa.h
@@ -3,7 +3,6 @@
 
 #include "qemu/bitmap.h"
 #include "qapi/qapi-types-machine.h"
-#include "exec/cpu-common.h"
 
 struct CPUArchId;
 
-- 
2.45.2



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 15:13:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 15:13:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859301.1271448 (Exim 4.92)
	(envelope-from )
	id 1tNZGH-0007Pz-3x; Tue, 17 Dec 2024 15:13:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859301.1271448; Tue, 17 Dec 2024 15:13: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 1tNZGH-0007Pn-0x; Tue, 17 Dec 2024 15:13:25 +0000
Received: by outflank-mailman (input) for mailman id 859301;
 Tue, 17 Dec 2024 15:13: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 1tNZGG-0007OR-23
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 15:13:24 +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 74e72ba3-bc89-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 16:13:23 +0100 (CET)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-43621d27adeso38173355e9.2
 for ; Tue, 17 Dec 2024 07:13:23 -0800 (PST)
Received: from localhost.localdomain ([78.196.4.158])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4364a376846sm22805905e9.0.2024.12.17.07.13.21
 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
 Tue, 17 Dec 2024 07:13: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: 74e72ba3-bc89-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1734448402; x=1735053202; 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=/B5TIPsV17x+5MyZKSnFfy23Cjqmxw2Z95LPImc4y+o=;
        b=p+fRgeNPeuGy+uJEEGdMG1R4xeDzkH75yM4P4JDFluUtFKO6ZDF5XycU72b0equ1oc
         JyG7RwHofJT9RvA4t0SZlthddX1d9KmvDNMGeQ1e9m5lPsuSE7K916SEcFjlSJpGwiJl
         +1knn/uvzdVZ8UU7c3OWfrF17Kk2GcT4IY0DEzxpllEgXGPgAKmTaYd9RZYC8HvPHBPS
         hES/wOIaUIDJxegfPfvaeZ08IyOSfU9AtXikOdF0t0Pzj1E9XHD6dMyF8G9SCMy5m+2n
         nY0IlZXtGkRJVnVf76fPPYXwOd5l42rYhFvjkgcaf9I2YzDbEvcfec26WyYLyXsx0603
         hPEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734448402; x=1735053202;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=/B5TIPsV17x+5MyZKSnFfy23Cjqmxw2Z95LPImc4y+o=;
        b=RS9ya6THKuQ8ZrS/liZbbPUqeR9zhbsNNj13HBMeKUEVnFYMaXB2KQEI9+p4Onm2gY
         Ia9QRgWFXJx1G8ovr2130neGbnl3LmbVqzEcm4mVAGWaucXbkXAN68ZZ3TfDB1KvIfW6
         c8L4A/Tvg6ef0WX6iu3W8UehqI/fBCeZwOPepZTw3fYS9AHhsXgafv9x4CRqYQxwSrPH
         4Z3GTF11bhVivOMG6IR7SLhsvBzQohyHzFW151FOI7sVTdPV7aouN1kiB/Pe5N7Stsok
         tkOO+fVNMSOfgdPoDhJBxzcFpIm3/r24QArTOQm0N2kXd/0DoNFj77GSdWCEHmV+CEsL
         x3sA==
X-Forwarded-Encrypted: i=1; AJvYcCW6Lqyaew6/Pbgwr0OtnOFFGUNZpAnFSgE8WD3ilEFiRYdkS/TPFl5Xl0kEFYxoYdcgNYbOWEPMFq8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxgiacgl1JwGwPTUxIlgNqcGMhEWNXZWf50nTWOSJVBjcACrStF
	UDfuJKKy98vkTGxN8p2HFugKtWpfq3Rv28Rxmn0hiKaTCBh88jhEMqMk0tmYYAM=
X-Gm-Gg: ASbGncuVYVrfF56p9cjsxQCiy2lLejNDhHoQya53/DaOvuu3Vfts1wPGNmFKDO2WLZn
	HhZ/hp14Fqzm6CedXJCUaRDNrzvtYZWfwqs/+dQac0s0GTKT1MkV6zRfp/hrs5DpdENuKTV7uoR
	3ik8SLSZzQX1tVxBfDs3stIsFgmkZu9A+G+FgBDxqG+av5t/UrxzELCL5tBfUbwBA8pvSNBsp91
	oW4W8KCxFInL73uRyTi0B5w+NjHUaILMX3rcqPHDOIu+0hOckkg1ZIX7aPRwdbjT/7HzI2+tP3G
	0Dgu
X-Google-Smtp-Source: AGHT+IEfxORkyLYhuHxnONvt8y0GcoDDWqUCnUhwhZJaAe+AjTE0GlknrUlywXXPAdaaiQJ2vymGXQ==
X-Received: by 2002:a05:600c:b95:b0:434:f925:f5c9 with SMTP id 5b1f17b1804b1-4362aa28ddemr150403075e9.6.1734448402549;
        Tue, 17 Dec 2024 07:13:22 -0800 (PST)
From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
To: qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
	Zhao Liu ,
	"Edgar E. Iglesias" ,
	Paul Durrant ,
	Richard Henderson ,
	=?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= ,
	Yanan Wang ,
	Anton Johansson ,
	Anthony PERARD ,
	xen-devel@lists.xenproject.org
Subject: [PATCH 3/3] system/accel-ops: Remove unnecessary 'exec/cpu-common.h' header
Date: Tue, 17 Dec 2024 16:13:05 +0100
Message-ID: <20241217151305.29196-4-philmd@linaro.org>
X-Mailer: git-send-email 2.45.2
In-Reply-To: <20241217151305.29196-1-philmd@linaro.org>
References: <20241217151305.29196-1-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Since commit c4b3f46c151 ("include/exec: Move vaddr defines to
separate file") we only need to include "exec/vaddr.h" to get
the 'vaddr' type definition, no need for "exec/cpu-common.h".

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/sysemu/accel-ops.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/sysemu/accel-ops.h b/include/sysemu/accel-ops.h
index a0886722305..137fb96d444 100644
--- a/include/sysemu/accel-ops.h
+++ b/include/sysemu/accel-ops.h
@@ -10,7 +10,7 @@
 #ifndef ACCEL_OPS_H
 #define ACCEL_OPS_H
 
-#include "exec/cpu-common.h"
+#include "exec/vaddr.h"
 #include "qom/object.h"
 
 #define ACCEL_OPS_SUFFIX "-ops"
-- 
2.45.2



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 15:20:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 15:20:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859332.1271457 (Exim 4.92)
	(envelope-from )
	id 1tNZMc-0000QJ-PT; Tue, 17 Dec 2024 15:19:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859332.1271457; Tue, 17 Dec 2024 15:19:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNZMc-0000QC-Mw; Tue, 17 Dec 2024 15:19:58 +0000
Received: by outflank-mailman (input) for mailman id 859332;
 Tue, 17 Dec 2024 15:19: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 1tNZMa-0000Q6-S8
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 15:19:56 +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 5ec1baab-bc8a-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 16:19:55 +0100 (CET)
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-388cae9eb9fso1909044f8f.3
 for ; Tue, 17 Dec 2024 07:19:55 -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-388c80120bcsm11740695f8f.5.2024.12.17.07.19.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 07:19: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: 5ec1baab-bc8a-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734448795; x=1735053595; 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=NqnofJog/FYFBbWrp/1Y91hZaZwiLXYKdRCKViG3dGo=;
        b=CPzA6QK/flx/jyt42Yaf47LM2r21bpIdE3pFPwHFitcbZ2Mfx8mZtEL5915EG/o6yU
         WQyeOBU6LTJDdnLekHfRoiuGMd0O9HVZcWrPW6JeEmKRL6dqLSyjYi7GPz5ruZ9gDsbx
         7tBxwGcu8SioCK5lnrriZNxLvc3ip0GcAFj+KDwKxN3R0rNOtG1apZuh/xI0L+7KNiad
         gwrP5GUpfSk7H/7jd+E5kRHl2OFYUIJTwBrFLm52cFSUo2CfvxCZm/0KArAJIwusvpoB
         TBnDcIDGyFy8XWurxjV78TKuFWjBbiR6Hiu0ENjwf29nKxC1e6vGvNZ4/RALFXQ+CUXU
         I8hQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734448795; x=1735053595;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NqnofJog/FYFBbWrp/1Y91hZaZwiLXYKdRCKViG3dGo=;
        b=MYP6THufgOc/gEf3Ht0SBw8ZCOASLBEi5mMxxaq+CfIQiLOeKw9syAn5vzrYLqUcp6
         xq9eshoKNOExJH8+qSevYQB44hxNXJJv3wAYK0RO5tMkdOLaL4iqyCnzkRB8RDrJMysk
         gvZR4ZvX7PeebQkCUcPtNvMHRmx1nZm3A8fsxetjVaEcUnghcq6TP/zhc/JfmefKmB35
         b9naLAT4k0ejWb/jZE6FUK9z9B0OFlJoh+5FkIYeQNLByLESKTicQDwvqMlCVNcJldrv
         Aq9tLZYyAVS3R02bWn1eLgeJNhgTB3Pq/IINr25ThiaQ5b42lUZTRrEdANMR5E6xV+1n
         xKqQ==
X-Forwarded-Encrypted: i=1; AJvYcCUxsWM/P/E+Yz0hD1cRolelIsmKtGJVESiR7XIrXyj7JduTVV+bqK5F1ttiQIWoUj225ZnQ7ae2RQ0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzdjeLoCOObpr+2YJYfdox/G6d5LBs+u46L5DI6I9mWfr0g1k10
	gBSyUA5kezCRii6T4e3cLjZFDVE0P5M5+FK+aE27k64sOFDzjhtDjbK5AKHs6A==
X-Gm-Gg: ASbGncv7LE8RvHLA6XsYMM6JeYcHitsaOKJKT0kJqbAMfSNjWUAgUf7tuuB5CNnhwHU
	w+wLWzPuNLqerJAceebrQDS/tYST7ZBLDd0blEQ9/vWdlfVL+8I/ToCG/I03YwT2OUd2NNobUir
	nd9f8U33IwWwT5HNrQSUyfF4OQwdW+9bZbetAgzuqaQ2K1rZjr/JxwsibpxszWKsQ2Muf599RnU
	JlZiMeRntI3n2tGQWYprYci/bwcbvzY2dKUVyR5RP4VdGN61RJ7s+J/rQiIGvdzNJoC7TD3xg/k
	9Gmozq6t7KY50a7J7Mi6SDgOt+KohxDCULawDVT3Ug==
X-Google-Smtp-Source: AGHT+IFnbL5uExR/+8OImpsVwxPmpXezt/oPgBnVmOereBXluR+RTCkgaAe3X/VPj1FfFfMuM8Nssg==
X-Received: by 2002:a05:6000:4b12:b0:385:edb7:69ba with SMTP id ffacd0b85a97d-38880ac5f25mr15629992f8f.1.1734448794830;
        Tue, 17 Dec 2024 07:19:54 -0800 (PST)
Message-ID: 
Date: Tue, 17 Dec 2024 16:19:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 2/5] xen: add bitmap to indicate per-domain state
 changes
To: Juergen Gross 
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: <20241217142218.24129-1-jgross@suse.com>
 <20241217142218.24129-3-jgross@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: <20241217142218.24129-3-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.12.2024 15:22, Juergen Gross wrote:
> Add a bitmap with one bit per possible domid indicating the respective
> domain has changed its state (created, deleted, dying, crashed,
> shutdown).
> 
> Registering the VIRQ_DOM_EXC event will result in setting the bits for
> all existing domains and resetting all other bits.
> 
> As the usage of this bitmap is tightly coupled with the VIRQ_DOM_EXC
> event, it is meant to be used only by a single consumer in the system,
> just like the VIRQ_DOM_EXC event.

I'm sorry, but I need to come back to this. I thought I had got convinced
that only a single entity in the system can bind this vIRQ. Yet upon
checking I can't seem to find what would guarantee this. In particular
binding a vIRQ doesn't involve any XSM check. Hence an unprivileged entity
could, on the assumption that the interested privileged entity (xenstore)
is already up and running, bind and unbind this vIRQ, just to have the
global map freed. What am I overlooking (which would likely want stating
here)?

> V5:
> - domain_init_states() may be called only if evtchn_bind_virq() has been
>   called validly (Jan Beulich)

I now recall why I had first suggested the placement later in the handling:
You're now doing the allocation with yet another lock held. It's likely not
the end of the world, but ...

> @@ -138,6 +139,60 @@ bool __read_mostly vmtrace_available;
>  
>  bool __read_mostly vpmu_is_available;
>  
> +static DEFINE_SPINLOCK(dom_state_changed_lock);
> +static unsigned long *__read_mostly dom_state_changed;
> +
> +int domain_init_states(void)
> +{
> +    const struct domain *d;
> +    int rc = -ENOMEM;
> +
> +    spin_lock(&dom_state_changed_lock);
> +
> +    if ( dom_state_changed )
> +        bitmap_zero(dom_state_changed, DOMID_FIRST_RESERVED);
> +    else
> +    {
> +        dom_state_changed = xvzalloc_array(unsigned long,
> +                                           BITS_TO_LONGS(DOMID_FIRST_RESERVED));

... already this alone wasn't nice, and could be avoided (by doing the
allocation prior to acquiring the lock, which of course complicates the
logic some).

What's perhaps less desirable is that ...

> @@ -494,6 +495,15 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
>          goto out;
>      }
>  
> +    if ( virq == VIRQ_DOM_EXC )
> +    {
> +        rc = domain_init_states();
> +        if ( rc )
> +            goto out;
> +
> +        deinit_if_err = true;
> +    }
> +
>      port = rc = evtchn_get_port(d, port);
>      if ( rc < 0 )
>      {

... the placement here additionally introduces lock nesting when really
the two locks shouldn't have any relationship.

How about giving domain_init_states() a boolean parameter, such that it
can be called twice, with the first invocation moved back up where it
was, and the second one put ...

> @@ -527,6 +537,9 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
>   out:
>      write_unlock(&d->event_lock);
>  
> +    if ( rc && deinit_if_err )
> +        domain_deinit_states();
> +
>      return rc;
>  }

... down here, not doing any allocation at all (only the clearing), and
hence eliminating the need to deal with its failure? (Alternatively
there could of course be a split into an init and a reset function.)

There of course is the chance of races with such an approach. I'd like
to note though that with the placement of the call in the hunk above
there's a minor race, too (against ...

> @@ -730,6 +743,9 @@ int evtchn_close(struct domain *d1, int port1, bool guest)
>          struct vcpu *v;
>          unsigned long flags;
>  
> +        if ( chn1->u.virq == VIRQ_DOM_EXC )
> +            domain_deinit_states();

... this and the same remote vCPU then immediately binding the vIRQ
again). Hence yet another alternative would appear to be to drop the
new global lock and use d->event_lock for synchronization instead
(provided - see above - that only a single entity can actually set up
all of this). That would pretty much want to have the allocation kept
with the lock already held (which isn't nice, but as said is perhaps
tolerable), but would at least eliminate the undesirable lock nesting.

Re-use of the domain's event lock is at least somewhat justified by
the bit array being tied to VIRQ_DOM_EXEC.

Thoughts?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 15:36:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 15:36:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859347.1271468 (Exim 4.92)
	(envelope-from )
	id 1tNZcl-0003yn-8Q; Tue, 17 Dec 2024 15:36:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859347.1271468; Tue, 17 Dec 2024 15:36: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 1tNZcl-0003yg-5I; Tue, 17 Dec 2024 15:36:39 +0000
Received: by outflank-mailman (input) for mailman id 859347;
 Tue, 17 Dec 2024 15:36:38 +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 1tNZck-0003ya-Li
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 15:36:38 +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 b3819766-bc8c-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 16:36:36 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-4361a50e337so38439965e9.0
 for ; Tue, 17 Dec 2024 07:36:36 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4363602c92csm121305575e9.15.2024.12.17.07.36.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 07:36: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: b3819766-bc8c-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734449796; x=1735054596; 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=exsTwQflvieAUJwBUb+Cdk9u3jQBtU89XVwxx37fr9k=;
        b=TLJSNbUB5MlljHW/YBGJYStFX8TGcpL0A41zB1t0xbwkMYM4JZRMGC/kdg3aUGJsUI
         UYjt98lUYyItnc9zmnUXZ41N/9VeN6hSf6B7HCR8XDRzhge7sDqgbBXt1ALnlafX6lbr
         JDuezOqWh+V+kZFAYePJ1DJ2UAcpc1t4FussA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734449796; x=1735054596;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=exsTwQflvieAUJwBUb+Cdk9u3jQBtU89XVwxx37fr9k=;
        b=tBXw9gIaF8vQSSLf+WyVi9gzyCyWmps5/f3v34G1y9QSxpVOo6pw7UD7Eh10AhDhTQ
         GKFSJpFEH6vNX19w+ZhviKW0ybGdOvsXcfjmYaIZseEMkq3H4kNSIMhgKv9T0t9B8Tyh
         ruTrMpUoOWZJGftkYTrD/XvHpfSDOxuP4PUEflHcYNLZQBhv11LdMGyBItdxuL5iQgwH
         i5wT90MgyLNTmXxb5LMqmQKw6SJgJY6IXJJJrNR2VAq0R+FuCR2QOH32MAcLhE89Sgdl
         ikwgO+T8u3e7G0ZUXysSYG6B1/4EggLrp9scbTp1/hTg9erMMrh7A9j1WOp6YKKJGadP
         PNZA==
X-Forwarded-Encrypted: i=1; AJvYcCXW4m943EVp6H5wLAh2Ad+g7AApLXCe9dEUUtrZ4Cvw1QVJiHSIKqBCUUplcii3IvwWC8+9+5pRjw0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxfFXeAaARrt451RZRQXQVq1sbtsA4NbrGIs7Z97Ve/RpK4kFVy
	ZpnsfPBmOK8utehHvTLvfwC4j+yVTCNUXolnClnYFzqd+sy3/DiSDYBJ95lggX8=
X-Gm-Gg: ASbGnctbN6WPahvj4L9tnDg/uxDZVSF5KWmrS/k9MFZw1NhaSycC9Hc+9noCe+PH2cm
	7A2S4QBBila73ZJqXP5PnovPoadaSHQST3NfxPfjkTB8HEkmG/xm5j1XMF7Bg/6HeBI88DLjLHO
	KQvtK2mnktUKpC3BosHDtBy4sMg0lMqKC1Ni9l/DykNPNfnWsWRKxmUZqZxUk66eqdt4sWC73Az
	y9pNxW5HwbMfmxXe35QDXu8ERY7DbCJuPYmIoBPy8hfShFHpXPy1eiVSgUf/R8tBVz+nEH9ekgI
	Y/d+V9lOvnc8/T4PUUOr
X-Google-Smtp-Source: AGHT+IEg8qT7hS/mqmJF8icXteQl+7SMo3obWwMr/1D9VGGJKvqVQbT0U4eSZKHDUpqy5ecgEOUJyw==
X-Received: by 2002:a05:600c:b95:b0:434:f925:f5c9 with SMTP id 5b1f17b1804b1-4362aa28ddemr151275305e9.6.1734449796007;
        Tue, 17 Dec 2024 07:36:36 -0800 (PST)
Message-ID: <6052d06d-ba8f-4cb1-8fae-e79236abcf19@citrix.com>
Date: Tue, 17 Dec 2024 15:36:35 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] misra: add deviation for MISRA C Rule R11.8.
To: Alessandro Zucchelli ,
 xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com, Simone Ballarin ,
 Doug Goldstein ,
 Stefano Stabellini 
References: <202c8efa4f846018e463f6242d25eb10c015d835.1734367711.git.alessandro.zucchelli@bugseng.com>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <202c8efa4f846018e463f6242d25eb10c015d835.1734367711.git.alessandro.zucchelli@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 16/12/2024 4:57 pm, Alessandro Zucchelli wrote:
> Rule 11.8 states as following: "A cast shall not remove any `const' or
> `volatile' qualification from the type pointed to by a pointer".
>
> Function `__hvm_copy' in `xen/arch/x86/hvm/hvm.c' is a double-use
> function, where the parameter needs to not be const because it can be
> set for write or not. As it was decided a new const-only function will
> lead to more developer confusion than it is worth, this violation is
> addressed by deviating the function.

__hvm_copy() is a static function, and the public wrappers are const
where they ought to be.

No-one is expected to use __hvm_copy() directly.

All cases of casting away const-ness are accompanied with a comment
explaining why it's safe given the other flags passed in.

> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index 2f58f29203..5056669f16 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -393,6 +393,12 @@ Fixing this violation would require to increase code complexity and lower readab
>  -config=MC3R1.R11.8,reports+={safe,"any_area(any_loc(any_exp(macro(^container_of$))))"}
>  -doc_end
>  
> +-doc_begin="Function __hvm_copy in xen/arch/x86/hvm/hvm.c is a double-use
> +function, where the parameter needs to not be const because it can be set for
> +writeor not"

"write or".

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 15:48:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 15:48:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859356.1271478 (Exim 4.92)
	(envelope-from )
	id 1tNZnw-00060W-6v; Tue, 17 Dec 2024 15:48:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859356.1271478; Tue, 17 Dec 2024 15:48: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 1tNZnw-00060P-3d; Tue, 17 Dec 2024 15:48:12 +0000
Received: by outflank-mailman (input) for mailman id 859356;
 Tue, 17 Dec 2024 15:48: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 1tNZnv-00060J-4A
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 15:48:11 +0000
Received: from mail-oa1-x2b.google.com (mail-oa1-x2b.google.com
 [2001:4860:4864:20::2b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5065d83d-bc8e-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 16:48:10 +0100 (CET)
Received: by mail-oa1-x2b.google.com with SMTP id
 586e51a60fabf-29ff8053384so2883416fac.3
 for ; Tue, 17 Dec 2024 07:48:09 -0800 (PST)
Received: from [172.20.0.130] ([187.217.227.247])
 by smtp.gmail.com with ESMTPSA id
 586e51a60fabf-2a3d2928e81sm2820976fac.37.2024.12.17.07.48.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 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: 5065d83d-bc8e-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1734450488; x=1735055288; 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=f0mmYM+VbtglGVT88HwKy5Bu24H9an/svIIsHPSJEpQ=;
        b=P6FXLurWSAV7Y+bWGhGgFB7rEC49zaJjFNk7LGLfY4iwnndYBizP1gNoDF4J0a6Q4r
         E7fn0HYLHjXN4AVhDUE+I8P8ehDSE3mAAdGnMJG8ChjKyMzI9Vq7dSgv9VGsqg1UEnD7
         LDWjooGoFLd0vJJ1wzHYx2Gw8+PSGviU0BjKINXGnukUq973jQ+yyHBTNKpU+Ov1SAYk
         aWlGi7dtziCc46ArGlvari5qKJnpfMvy3PGbUm1N/z7VmfX2e6EFyg5tO+IL1/b9+Lf/
         9jBAFjhB19KIkaq4MlFM0wTQOLRdMAWnrL9Gn+LMCJ151sXkSScJnJow51ItV0/YSZqP
         SkYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734450488; x=1735055288;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=f0mmYM+VbtglGVT88HwKy5Bu24H9an/svIIsHPSJEpQ=;
        b=IUfqdsFw5quUaeC1/cQhlQF2V6hJcdXraj3EhmyToP0PUdyLUw9x97UH5ZbFTuEt9A
         MLaBw4yLrInbRSUcgNk02Rl2Z4JJh70K36BR3D6ticNcLF06E1Xq23K/dWr6tYszhFNb
         s0yVqFTEIkiwvyNJhRXkzc57c6MKldHKG+sTiKGI0+2YOjpbMKxlqIIybcX38VFP2Bv8
         cRC1iDgYOl2J8VxWNdxYxXVrtiJwzeB8QD+3C97VXnglNsasf744DFjWdPlBpL16nCdu
         sP/i2TaMbHRm7f8VR/2iJjxRx69VOsP0dOLq+69WvjO3Wvv/G2x3JR5ZgzUEdSqryEke
         Z9yw==
X-Forwarded-Encrypted: i=1; AJvYcCUSACmIbtYAOTMORdzMkBdwYfWZij7LyGdoM33kS5RnHaEXmZszx/w3KPkzXWfNqizAdtEj5DAqJOg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzYBPMy3uLJuhkg8Tx6FeN4yYrrzc5EVv3YU/rS327MmhhQGOdE
	IojTp8OoJXFTTzpjJGn2QF50T7FiSxJK4hT+d9392l1w2s+Admw2yxRI6nMBoxg=
X-Gm-Gg: ASbGncuUXas08c0etyoM+wZoUWUhd/1lgWx4swdiFjOjITw/MBfyypCZU4wXPGeOOo3
	maC2p7fhOEKZw0IhEGDgj7dJ/1hVF7E6Cmvz84zc2lScshndvL9KiSmZfEuq8cALCjm4V5WLgI3
	PaaRiBbVn8iMAvn7jNTbPtY+eiv4aMFI+CFianaJX++CbRYwNX/6J9nywz+ylxC4oi4AQtWTO7O
	GBjtCRL1bceGAWBfbjrjJIGqzTGQ2Oifqak/SLf2FgGxs8MO5oZwMsV43pWPoQnLCLaqER0SQ==
X-Google-Smtp-Source: AGHT+IGRz3A2ptnwB7Owk61+AP8XwGp3U+GE+iecH8uI4ib2xQbTKNBFAXxFrfg7epRGuva8qv6lLQ==
X-Received: by 2002:a05:6870:71c4:b0:27c:52a1:f311 with SMTP id 586e51a60fabf-2a3ac96d7cemr8441207fac.42.1734450488663;
        Tue, 17 Dec 2024 07:48:08 -0800 (PST)
Message-ID: 
Date: Tue, 17 Dec 2024 09:48:05 -0600
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/3] include: Cleanups around 'exec/cpu-common.h' header
To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= ,
 qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
 Zhao Liu , "Edgar E. Iglesias"
 , Paul Durrant ,
 Yanan Wang , Anton Johansson ,
 Anthony PERARD , xen-devel@lists.xenproject.org
References: <20241217151305.29196-1-philmd@linaro.org>
Content-Language: en-US
From: Richard Henderson 
In-Reply-To: <20241217151305.29196-1-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 12/17/24 09:13, Philippe Mathieu-Daudé wrote:
> Philippe Mathieu-Daudé (3):
>    hw/xen: Remove unnecessary 'exec/cpu-common.h' header
>    system/numa: Remove unnecessary 'exec/cpu-common.h' header
>    system/accel-ops: Remove unnecessary 'exec/cpu-common.h' header

Reviewed-by: Richard Henderson 

r~


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 15:56:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 15:56:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859363.1271487 (Exim 4.92)
	(envelope-from )
	id 1tNZvK-00082Y-S5; Tue, 17 Dec 2024 15:55:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859363.1271487; Tue, 17 Dec 2024 15:55: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 1tNZvK-00082R-PN; Tue, 17 Dec 2024 15:55:50 +0000
Received: by outflank-mailman (input) for mailman id 859363;
 Tue, 17 Dec 2024 15:55: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 1tNZvJ-00082J-7i
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 15:55:49 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 61511361-bc8f-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 16:55:47 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5d41848901bso9671443a12.0
 for ; Tue, 17 Dec 2024 07:55:47 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d652f2599fsm4377087a12.68.2024.12.17.07.55.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 07:55: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: 61511361-bc8f-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734450947; x=1735055747; 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=A1FJ2pBbOIfouCTKMcqgZiyKyvy9Yp0A06LNR1tI/H8=;
        b=Vmi78qtW/QxMehoCdlmlKRKIQ7VSSoFLuF+kRkwOv8pxoM90xiTXwgi54LttRX4xGR
         0Cw4A/W/2hY1P/xOj+3RdrR8c3WIp4KDdy18uz/Q3c8MRhYIB7qhI4vuoFnueYxnQdVg
         X//7cD1LsSKpAsxbJYxH8LHoDzGJGYx3uE2Rk2wiQfcunwfH19fHOvNlCAc5DV8407GD
         DV3xfu0P2Blfy/c1siqdwt4XgmgvthOA/PvRqKYRQ0BmYNnwbOK9+ud7VoMqsfLEQBKy
         hurA1VxwC9ghmAklIRmiPZDTqT6BPcoMW9aE2B75KbiVPpdtURkzqsKIs6CtNcziW9fT
         IA+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734450947; x=1735055747;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=A1FJ2pBbOIfouCTKMcqgZiyKyvy9Yp0A06LNR1tI/H8=;
        b=ntIZQR+npw4l/DAvwhgyZoMwTwQh/E+vvp0W8OsdVG4V8FCIu806lliiC+uaXYppN5
         YWHEUf81UWpSv+/1sNQ2rDxQp14PtiYqAntrRR/dtbX9eD7V9cuZVZNyjzmAb8gQHd5S
         Br+nCyCjI9zaWycxT+7Ybffgf3tFmPng1hyiRANtmaFCyH1cuhleSrCUBcdz+TwXA61E
         aAfEhYjlraUe0AOA+5nD2FK6g3uPgZ/s17rxBpZX6X8YmW+p6UdYRrz+B8dYTT6rIsxn
         WpJOEMM5Wz/OKszpUry9x8Ugf8E/zVJ7sjjw/RJmD6MWqOGeHHEyMXRbSO2Qc4Xu6FyA
         wYpQ==
X-Forwarded-Encrypted: i=1; AJvYcCWLnWhtU1B3sLim05QBkbnnKWqKHpaaROL9uOFP4NGm7AWD7RNYE1rSQu2zACm0o0XbTYylu+AoOoQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyvu8JBv9MJH7spvCtH8TexXdudWJOSE0YMr+Mta49IExc0FHgC
	KvylHBpk1fUTE4SlpWrN2iLKHT7xPojAgRKus2qc2tmqB1PiVXl22Xtbcdz9H7M=
X-Gm-Gg: ASbGncs+Qtkb/tkHixpXj3CG3OrajDGwlLWWxjq4V8SAM4y3tIQb3uRvVu/x02/pPjr
	Do2ooTRBs3Ya7uTa9OcSmSGDTWz5Yli33wbZXcm/inTnxDTwD1HCvirBS5uojyxaQ+owVSemPrC
	fqeC7I+JcOun0phsKfnrdNfabrQK5HdWzFBQkQdNYsrSRjjSkyMVVi9O87WamnGghuXKS/Ij93A
	BJi7DJj6v7eFnVZlgdfBWp7csDRcSo5nl9JfHVpmRgr+4j/09QdTZpONfZy7+BXV1K5AuXrGGpc
	iRQFXkh/Go/M22PglhWPUR+cRUC99nFI65Is/Ht3Umhl+KLUmBBiZ5t6jNApvl31DI9eiqEHBK0
	ZeW6uBg==
X-Google-Smtp-Source: AGHT+IEGcT1KuZPBOAL5DwZtvlbNZFE5JWyvbP/Ah7EejRGVzCbScH+7quOyl4RPYu64aRXLTr5KTg==
X-Received: by 2002:a05:6402:26c5:b0:5d0:96a:aa90 with SMTP id 4fb4d7f45d1cf-5d7d55e7578mr4042752a12.17.1734450946561;
        Tue, 17 Dec 2024 07:55:46 -0800 (PST)
Message-ID: 
Date: Tue, 17 Dec 2024 16:55:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 2/5] xen: add bitmap to indicate per-domain state
 changes
To: Jan Beulich 
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: <20241217142218.24129-1-jgross@suse.com>
 <20241217142218.24129-3-jgross@suse.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: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------eTXP0Wp7Mp3kxg3MRtVVou3G"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------eTXP0Wp7Mp3kxg3MRtVVou3G
Content-Type: multipart/mixed; boundary="------------9rekIVJhhd0PmixfbOwlJ49i";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
Message-ID: 
Subject: Re: [PATCH v5 2/5] xen: add bitmap to indicate per-domain state
 changes
References: <20241217142218.24129-1-jgross@suse.com>
 <20241217142218.24129-3-jgross@suse.com>
 
In-Reply-To: 
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------9rekIVJhhd0PmixfbOwlJ49i
Content-Type: multipart/mixed; boundary="------------zJjCejBRpRY5Ye51sfXtpEfq"

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

T24gMTcuMTIuMjQgMTY6MTksIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxNy4xMi4yMDI0
IDE1OjIyLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gQWRkIGEgYml0bWFwIHdpdGggb25l
IGJpdCBwZXIgcG9zc2libGUgZG9taWQgaW5kaWNhdGluZyB0aGUgcmVzcGVjdGl2ZQ0KPj4g
ZG9tYWluIGhhcyBjaGFuZ2VkIGl0cyBzdGF0ZSAoY3JlYXRlZCwgZGVsZXRlZCwgZHlpbmcs
IGNyYXNoZWQsDQo+PiBzaHV0ZG93bikuDQo+Pg0KPj4gUmVnaXN0ZXJpbmcgdGhlIFZJUlFf
RE9NX0VYQyBldmVudCB3aWxsIHJlc3VsdCBpbiBzZXR0aW5nIHRoZSBiaXRzIGZvcg0KPj4g
YWxsIGV4aXN0aW5nIGRvbWFpbnMgYW5kIHJlc2V0dGluZyBhbGwgb3RoZXIgYml0cy4NCj4+
DQo+PiBBcyB0aGUgdXNhZ2Ugb2YgdGhpcyBiaXRtYXAgaXMgdGlnaHRseSBjb3VwbGVkIHdp
dGggdGhlIFZJUlFfRE9NX0VYQw0KPj4gZXZlbnQsIGl0IGlzIG1lYW50IHRvIGJlIHVzZWQg
b25seSBieSBhIHNpbmdsZSBjb25zdW1lciBpbiB0aGUgc3lzdGVtLA0KPj4ganVzdCBsaWtl
IHRoZSBWSVJRX0RPTV9FWEMgZXZlbnQuDQo+IA0KPiBJJ20gc29ycnksIGJ1dCBJIG5lZWQg
dG8gY29tZSBiYWNrIHRvIHRoaXMuIEkgdGhvdWdodCBJIGhhZCBnb3QgY29udmluY2VkDQo+
IHRoYXQgb25seSBhIHNpbmdsZSBlbnRpdHkgaW4gdGhlIHN5c3RlbSBjYW4gYmluZCB0aGlz
IHZJUlEuIFlldCB1cG9uDQo+IGNoZWNraW5nIEkgY2FuJ3Qgc2VlbSB0byBmaW5kIHdoYXQg
d291bGQgZ3VhcmFudGVlIHRoaXMuIEluIHBhcnRpY3VsYXINCj4gYmluZGluZyBhIHZJUlEg
ZG9lc24ndCBpbnZvbHZlIGFueSBYU00gY2hlY2suIEhlbmNlIGFuIHVucHJpdmlsZWdlZCBl
bnRpdHkNCj4gY291bGQsIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGludGVyZXN0ZWQg
cHJpdmlsZWdlZCBlbnRpdHkgKHhlbnN0b3JlKQ0KPiBpcyBhbHJlYWR5IHVwIGFuZCBydW5u
aW5nLCBiaW5kIGFuZCB1bmJpbmQgdGhpcyB2SVJRLCBqdXN0IHRvIGhhdmUgdGhlDQo+IGds
b2JhbCBtYXAgZnJlZWQuIFdoYXQgYW0gSSBvdmVybG9va2luZyAod2hpY2ggd291bGQgbGlr
ZWx5IHdhbnQgc3RhdGluZw0KPiBoZXJlKT8NCg0KSSB0aGluayB5b3UgYXJlIG5vdCBvdmVy
bG9va2luZyBhbnl0aGluZy4NCg0KSSBndWVzcyB0aGlzIGNhbiBlYXNpbHkgYmUgaGFuZGxl
ZCBieSBjaGVja2luZyB0aGF0IHRoZSBWSVJRX0RPTV9FWEMgaGFuZGxpbmcNCmRvbWFpbiBp
cyB0aGUgY2FsbGluZyBvbmUgaW4gZG9tYWluX1tkZV1pbml0X3N0YXRlcygpLiBOb3RlIHRo
YXQgZ2xvYmFsIHZpcnFzDQphcmUgb25seSBldmVyIHNlbnQgdG8gdmNwdVswXSBvZiB0aGUg
aGFuZGxpbmcgZG9tYWluLCBzbyByZWJpbmRpbmcgdGhlIGV2ZW50DQp0byBhbm90aGVyIHZj
cHUgaXMgcG9zc2libGUsIGJ1dCBkb2Vzbid0IG1ha2Ugc2Vuc2UuDQoNCj4gDQo+PiBWNToN
Cj4+IC0gZG9tYWluX2luaXRfc3RhdGVzKCkgbWF5IGJlIGNhbGxlZCBvbmx5IGlmIGV2dGNo
bl9iaW5kX3ZpcnEoKSBoYXMgYmVlbg0KPj4gICAgY2FsbGVkIHZhbGlkbHkgKEphbiBCZXVs
aWNoKQ0KPiANCj4gSSBub3cgcmVjYWxsIHdoeSBJIGhhZCBmaXJzdCBzdWdnZXN0ZWQgdGhl
IHBsYWNlbWVudCBsYXRlciBpbiB0aGUgaGFuZGxpbmc6DQo+IFlvdSdyZSBub3cgZG9pbmcg
dGhlIGFsbG9jYXRpb24gd2l0aCB5ZXQgYW5vdGhlciBsb2NrIGhlbGQuIEl0J3MgbGlrZWx5
IG5vdA0KPiB0aGUgZW5kIG9mIHRoZSB3b3JsZCwgYnV0IC4uLg0KPiANCj4+IEBAIC0xMzgs
NiArMTM5LDYwIEBAIGJvb2wgX19yZWFkX21vc3RseSB2bXRyYWNlX2F2YWlsYWJsZTsNCj4+
ICAgDQo+PiAgIGJvb2wgX19yZWFkX21vc3RseSB2cG11X2lzX2F2YWlsYWJsZTsNCj4+ICAg
DQo+PiArc3RhdGljIERFRklORV9TUElOTE9DSyhkb21fc3RhdGVfY2hhbmdlZF9sb2NrKTsN
Cj4+ICtzdGF0aWMgdW5zaWduZWQgbG9uZyAqX19yZWFkX21vc3RseSBkb21fc3RhdGVfY2hh
bmdlZDsNCj4+ICsNCj4+ICtpbnQgZG9tYWluX2luaXRfc3RhdGVzKHZvaWQpDQo+PiArew0K
Pj4gKyAgICBjb25zdCBzdHJ1Y3QgZG9tYWluICpkOw0KPj4gKyAgICBpbnQgcmMgPSAtRU5P
TUVNOw0KPj4gKw0KPj4gKyAgICBzcGluX2xvY2soJmRvbV9zdGF0ZV9jaGFuZ2VkX2xvY2sp
Ow0KPj4gKw0KPj4gKyAgICBpZiAoIGRvbV9zdGF0ZV9jaGFuZ2VkICkNCj4+ICsgICAgICAg
IGJpdG1hcF96ZXJvKGRvbV9zdGF0ZV9jaGFuZ2VkLCBET01JRF9GSVJTVF9SRVNFUlZFRCk7
DQo+PiArICAgIGVsc2UNCj4+ICsgICAgew0KPj4gKyAgICAgICAgZG9tX3N0YXRlX2NoYW5n
ZWQgPSB4dnphbGxvY19hcnJheSh1bnNpZ25lZCBsb25nLA0KPj4gKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCSVRTX1RPX0xPTkdTKERPTUlEX0ZJUlNU
X1JFU0VSVkVEKSk7DQo+IA0KPiAuLi4gYWxyZWFkeSB0aGlzIGFsb25lIHdhc24ndCBuaWNl
LCBhbmQgY291bGQgYmUgYXZvaWRlZCAoYnkgZG9pbmcgdGhlDQo+IGFsbG9jYXRpb24gcHJp
b3IgdG8gYWNxdWlyaW5nIHRoZSBsb2NrLCB3aGljaCBvZiBjb3Vyc2UgY29tcGxpY2F0ZXMg
dGhlDQo+IGxvZ2ljIHNvbWUpLg0KPiANCj4gV2hhdCdzIHBlcmhhcHMgbGVzcyBkZXNpcmFi
bGUgaXMgdGhhdCAuLi4NCj4gDQo+PiBAQCAtNDk0LDYgKzQ5NSwxNSBAQCBpbnQgZXZ0Y2hu
X2JpbmRfdmlycShldnRjaG5fYmluZF92aXJxX3QgKmJpbmQsIGV2dGNobl9wb3J0X3QgcG9y
dCkNCj4+ICAgICAgICAgICBnb3RvIG91dDsNCj4+ICAgICAgIH0NCj4+ICAgDQo+PiArICAg
IGlmICggdmlycSA9PSBWSVJRX0RPTV9FWEMgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBy
YyA9IGRvbWFpbl9pbml0X3N0YXRlcygpOw0KPj4gKyAgICAgICAgaWYgKCByYyApDQo+PiAr
ICAgICAgICAgICAgZ290byBvdXQ7DQo+PiArDQo+PiArICAgICAgICBkZWluaXRfaWZfZXJy
ID0gdHJ1ZTsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gICAgICAgcG9ydCA9IHJjID0gZXZ0Y2hu
X2dldF9wb3J0KGQsIHBvcnQpOw0KPj4gICAgICAgaWYgKCByYyA8IDAgKQ0KPj4gICAgICAg
ew0KPiANCj4gLi4uIHRoZSBwbGFjZW1lbnQgaGVyZSBhZGRpdGlvbmFsbHkgaW50cm9kdWNl
cyBsb2NrIG5lc3Rpbmcgd2hlbiByZWFsbHkNCj4gdGhlIHR3byBsb2NrcyBzaG91bGRuJ3Qg
aGF2ZSBhbnkgcmVsYXRpb25zaGlwLg0KPiANCj4gSG93IGFib3V0IGdpdmluZyBkb21haW5f
aW5pdF9zdGF0ZXMoKSBhIGJvb2xlYW4gcGFyYW1ldGVyLCBzdWNoIHRoYXQgaXQNCj4gY2Fu
IGJlIGNhbGxlZCB0d2ljZSwgd2l0aCB0aGUgZmlyc3QgaW52b2NhdGlvbiBtb3ZlZCBiYWNr
IHVwIHdoZXJlIGl0DQo+IHdhcywgYW5kIHRoZSBzZWNvbmQgb25lIHB1dCAuLi4NCj4gDQo+
PiBAQCAtNTI3LDYgKzUzNyw5IEBAIGludCBldnRjaG5fYmluZF92aXJxKGV2dGNobl9iaW5k
X3ZpcnFfdCAqYmluZCwgZXZ0Y2huX3BvcnRfdCBwb3J0KQ0KPj4gICAgb3V0Og0KPj4gICAg
ICAgd3JpdGVfdW5sb2NrKCZkLT5ldmVudF9sb2NrKTsNCj4+ICAgDQo+PiArICAgIGlmICgg
cmMgJiYgZGVpbml0X2lmX2VyciApDQo+PiArICAgICAgICBkb21haW5fZGVpbml0X3N0YXRl
cygpOw0KPj4gKw0KPj4gICAgICAgcmV0dXJuIHJjOw0KPj4gICB9DQo+IA0KPiAuLi4gZG93
biBoZXJlLCBub3QgZG9pbmcgYW55IGFsbG9jYXRpb24gYXQgYWxsIChvbmx5IHRoZSBjbGVh
cmluZyksIGFuZA0KPiBoZW5jZSBlbGltaW5hdGluZyB0aGUgbmVlZCB0byBkZWFsIHdpdGgg
aXRzIGZhaWx1cmU/IChBbHRlcm5hdGl2ZWx5DQo+IHRoZXJlIGNvdWxkIG9mIGNvdXJzZSBi
ZSBhIHNwbGl0IGludG8gYW4gaW5pdCBhbmQgYSByZXNldCBmdW5jdGlvbi4pDQo+IA0KPiBU
aGVyZSBvZiBjb3Vyc2UgaXMgdGhlIGNoYW5jZSBvZiByYWNlcyB3aXRoIHN1Y2ggYW4gYXBw
cm9hY2guIEknZCBsaWtlDQo+IHRvIG5vdGUgdGhvdWdoIHRoYXQgd2l0aCB0aGUgcGxhY2Vt
ZW50IG9mIHRoZSBjYWxsIGluIHRoZSBodW5rIGFib3ZlDQo+IHRoZXJlJ3MgYSBtaW5vciBy
YWNlLCB0b28gKGFnYWluc3QgLi4uDQo+IA0KPj4gQEAgLTczMCw2ICs3NDMsOSBAQCBpbnQg
ZXZ0Y2huX2Nsb3NlKHN0cnVjdCBkb21haW4gKmQxLCBpbnQgcG9ydDEsIGJvb2wgZ3Vlc3Qp
DQo+PiAgICAgICAgICAgc3RydWN0IHZjcHUgKnY7DQo+PiAgICAgICAgICAgdW5zaWduZWQg
bG9uZyBmbGFnczsNCj4+ICAgDQo+PiArICAgICAgICBpZiAoIGNobjEtPnUudmlycSA9PSBW
SVJRX0RPTV9FWEMgKQ0KPj4gKyAgICAgICAgICAgIGRvbWFpbl9kZWluaXRfc3RhdGVzKCk7
DQo+IA0KPiAuLi4gdGhpcyBhbmQgdGhlIHNhbWUgcmVtb3RlIHZDUFUgdGhlbiBpbW1lZGlh
dGVseSBiaW5kaW5nIHRoZSB2SVJRDQo+IGFnYWluKS4gSGVuY2UgeWV0IGFub3RoZXIgYWx0
ZXJuYXRpdmUgd291bGQgYXBwZWFyIHRvIGJlIHRvIGRyb3AgdGhlDQo+IG5ldyBnbG9iYWwg
bG9jayBhbmQgdXNlIGQtPmV2ZW50X2xvY2sgZm9yIHN5bmNocm9uaXphdGlvbiBpbnN0ZWFk
DQo+IChwcm92aWRlZCAtIHNlZSBhYm92ZSAtIHRoYXQgb25seSBhIHNpbmdsZSBlbnRpdHkg
Y2FuIGFjdHVhbGx5IHNldCB1cA0KPiBhbGwgb2YgdGhpcykuIFRoYXQgd291bGQgcHJldHR5
IG11Y2ggd2FudCB0byBoYXZlIHRoZSBhbGxvY2F0aW9uIGtlcHQNCj4gd2l0aCB0aGUgbG9j
ayBhbHJlYWR5IGhlbGQgKHdoaWNoIGlzbid0IG5pY2UsIGJ1dCBhcyBzYWlkIGlzIHBlcmhh
cHMNCj4gdG9sZXJhYmxlKSwgYnV0IHdvdWxkIGF0IGxlYXN0IGVsaW1pbmF0ZSB0aGUgdW5k
ZXNpcmFibGUgbG9jayBuZXN0aW5nLg0KPiANCj4gUmUtdXNlIG9mIHRoZSBkb21haW4ncyBl
dmVudCBsb2NrIGlzIGF0IGxlYXN0IHNvbWV3aGF0IGp1c3RpZmllZCBieQ0KPiB0aGUgYml0
IGFycmF5IGJlaW5nIHRpZWQgdG8gVklSUV9ET01fRVhFQy4NCj4gDQo+IFRob3VnaHRzPw0K
DQpXaXRoIG15IHN1Z2dlc3Rpb24gYWJvdmUgSSB0aGluayB0aGVyZSBpcyBubyByYWNlLCBh
cyBvbmx5IHRoZSBkb21haW4gaGFuZGxpbmcNClZJUlFfRE9NX0VYQyBjb3VsZCBhbGxvYy9k
ZWFsbG9jIGRvbV9zdGF0ZV9jaGFuZ2VkLg0KDQpVc2luZyBkLT5ldmVudF9sb2NrIGZvciBz
eW5jaHJvbml6YXRpb24gaXMgbm90IGEgbmljZSBvcHRpb24gSU1PLCBhcyBpdCB3b3VsZA0K
cmVxdWlyZSB0byB0YWtlIHRoZSBldmVudF9sb2NrIG9mIHRoZSBkb21haW4gaGFuZGxpbmcg
VklSUV9ET01fRVhFQyB3aGVuIHRyeWluZw0KdG8gc2V0IGEgYml0IGZvciBhbm90aGVyIGRv
bWFpbiBjaGFuZ2luZyBzdGF0ZS4NCg0KDQpKdWVyZ2VuDQo=
--------------zJjCejBRpRY5Ye51sfXtpEfq
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-----

--------------zJjCejBRpRY5Ye51sfXtpEfq--

--------------9rekIVJhhd0PmixfbOwlJ49i--

--------------eTXP0Wp7Mp3kxg3MRtVVou3G
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/Ey8FAmdhnwEFAwAAAAAACgkQsN6d1ii/Ey8f
9AgAlUWmKjAMKfwze+GdX2gtvNPwuGn8HtGmgdpfvVu78EcZqaBPr+T00NM1+HpA0qriaZJdSDDd
aSlY8Y5lcnM0bDrNCgnaqu1AwX1r68aDIQ35fZvdWwypz2gsLCf1QAfXFRdJLU4Ob5KAi2YjjpAx
zwdjge4kMRcYNkfumyPcPTBsmJIPaZg6N7id1FZARRDs9Cqef62qpqESwW0e6Ob30lIabvFKQy4K
FpOL/oA37+oEZpTdB5x4Y6YkiR9CiAL6O7zjBCzwTgmDeAQvu4braO9fqKloc47Na9oxB+sDfNb3
dRuVI5bwlcRGd1xLysMKS0gYF6c1zphVi1ZshBHB/w==
=Lh7p
-----END PGP SIGNATURE-----

--------------eTXP0Wp7Mp3kxg3MRtVVou3G--


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 16:03:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 16:03:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859379.1271498 (Exim 4.92)
	(envelope-from )
	id 1tNa35-0002BM-NJ; Tue, 17 Dec 2024 16:03:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859379.1271498; Tue, 17 Dec 2024 16:03:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNa35-0002BF-KZ; Tue, 17 Dec 2024 16:03:51 +0000
Received: by outflank-mailman (input) for mailman id 859379;
 Tue, 17 Dec 2024 16:03: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 1tNa34-0002B9-F6
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 16:03:50 +0000
Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7ef1ff0b-bc90-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 17:03:48 +0100 (CET)
Received: from fmviesa003.fm.intel.com ([10.60.135.143])
 by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 17 Dec 2024 08:03:45 -0800
Received: from liuzhao-optiplex-7080.sh.intel.com (HELO localhost)
 ([10.239.160.39])
 by fmviesa003.fm.intel.com with ESMTP; 17 Dec 2024 08:03:43 -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: 7ef1ff0b-bc90-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1734451428; x=1765987428;
  h=date:from:to:cc:subject:message-id:references:
   mime-version:content-transfer-encoding:in-reply-to;
  bh=TZgosjBYR9y1uV0i86b2LUmldcCKBeHWtXQ+IUnVzHI=;
  b=b2eOY0HGMcWuGLRTPyM2ky4lY9zNGVzDV5NbILR7VG3s+3KGhb2ZWE/Y
   tsNGpaw1T/Y6vYaNkgZug2PjCUP0k1Tg+R/ZQQttugvmnjykpAH9UjYPr
   37ABh4hnlVLcFKZJq7LcTY12llNzeUXVSJyNOGWyaPpUn0FztWlqKcHl4
   p+LnOPeVQ90XbJzMFKPwZp0FlNBKoN7aQpbr7RtTCYH03lcYIaDFYW18Z
   dwzxWlAiezV7sQz1FzlQiMw3WOP05AP4WaRc6awDZbvGwNwnPzXvKb0KC
   A9EcRSNmJx5AIrk8orI57+FG57BOCoy6e6IHj6QXkN5MOc6JyU9ess7RH
   g==;
X-CSE-ConnectionGUID: Q6AExycdStynOgtVSYqCiQ==
X-CSE-MsgGUID: 3dDzCYeWS6mS6EIhB2Reaw==
X-IronPort-AV: E=McAfee;i="6700,10204,11288"; a="35038707"
X-IronPort-AV: E=Sophos;i="6.12,242,1728975600"; 
   d="scan'208";a="35038707"
X-CSE-ConnectionGUID: WDSSOHGXSqyEmnqsys0ufQ==
X-CSE-MsgGUID: vriFYFVBRV2y5UsKlcv87w==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; 
   d="scan'208";a="101715615"
Date: Wed, 18 Dec 2024 00:22:17 +0800
From: Zhao Liu 
To: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= 
Cc: qemu-devel@nongnu.org, Stefano Stabellini ,
	"Edgar E. Iglesias" ,
	Paul Durrant ,
	Richard Henderson ,
	Yanan Wang , Anton Johansson ,
	Anthony PERARD ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/3] hw/xen: Remove unnecessary 'exec/cpu-common.h' header
Message-ID: 
References: <20241217151305.29196-1-philmd@linaro.org>
 <20241217151305.29196-2-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20241217151305.29196-2-philmd@linaro.org>

On Tue, Dec 17, 2024 at 04:13:03PM +0100, Philippe Mathieu-Daudé wrote:
> Date: Tue, 17 Dec 2024 16:13:03 +0100
> From: Philippe Mathieu-Daudé 
> Subject: [PATCH 1/3] hw/xen: Remove unnecessary 'exec/cpu-common.h' header
> X-Mailer: git-send-email 2.45.2
> 
> Nothing requires definitions from "exec/cpu-common.h",
> do not include this header.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  include/hw/xen/xen.h | 2 --
>  1 file changed, 2 deletions(-)
> 

Reviewed-by: Zhao Liu 



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 16:05:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 16:05:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859384.1271508 (Exim 4.92)
	(envelope-from )
	id 1tNa4O-0002gJ-1j; Tue, 17 Dec 2024 16:05:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859384.1271508; Tue, 17 Dec 2024 16: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 1tNa4N-0002gC-VF; Tue, 17 Dec 2024 16:05:11 +0000
Received: by outflank-mailman (input) for mailman id 859384;
 Tue, 17 Dec 2024 16:05: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 1tNa4L-0002g4-Sg
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 16:05:09 +0000
Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ae80fa7f-bc90-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 17:05:07 +0100 (CET)
Received: from fmviesa004.fm.intel.com ([10.60.135.144])
 by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 17 Dec 2024 08:05:05 -0800
Received: from liuzhao-optiplex-7080.sh.intel.com (HELO localhost)
 ([10.239.160.39])
 by fmviesa004.fm.intel.com with ESMTP; 17 Dec 2024 08:05: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: ae80fa7f-bc90-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1734451508; x=1765987508;
  h=date:from:to:cc:subject:message-id:references:
   mime-version:content-transfer-encoding:in-reply-to;
  bh=bo86RRfkr3shVB+cRKwVtLE8HuM1MXjOYJ7K7zRqdXU=;
  b=G7GPLR3j32QgEQOX+OJnBHpxj9dvPXvmqgoiFbjnjuR7MYnpuHFs5cY7
   qxNqr26s60qWieL11wFDN32VNm4raNQrd7LK52W7TwJaJoR/mmtqRtHMy
   K5XRzWDYBrJYF4X/9hTl5fQIgs9mB/vjFKHvZF5Wmzd9lODMAgbAt4pkP
   uxyYV20qK7FrVwBiBp73rSjzhOKwfvo5Qmtzl+ZCLu9DUBDpLFhnjdqDX
   94KK7Yqivjpl4MVEdPPfpE0HbwF+9FS+rTYe9QAbBj52eOjEW1NlgL4hN
   0aqzw8WOiY+q+wypwLigRe196J95fMpd736nmLMP9oOMLSGSdKwL8dn8Q
   g==;
X-CSE-ConnectionGUID: MoS5oWUKScCG0YU/7t3AEw==
X-CSE-MsgGUID: pybr45qUR0KJIqcSO2XRJw==
X-IronPort-AV: E=McAfee;i="6700,10204,11288"; a="52294481"
X-IronPort-AV: E=Sophos;i="6.12,242,1728975600"; 
   d="scan'208";a="52294481"
X-CSE-ConnectionGUID: 1pLt2+9cR3y1jBA5/W6pxw==
X-CSE-MsgGUID: qZtreTkoSoyAj1VrHL4AjQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.12,242,1728975600"; 
   d="scan'208";a="102409761"
Date: Wed, 18 Dec 2024 00:23:42 +0800
From: Zhao Liu 
To: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= 
Cc: qemu-devel@nongnu.org, Stefano Stabellini ,
	"Edgar E. Iglesias" ,
	Paul Durrant ,
	Richard Henderson ,
	Yanan Wang , Anton Johansson ,
	Anthony PERARD ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/3] system/numa: Remove unnecessary 'exec/cpu-common.h'
 header
Message-ID: 
References: <20241217151305.29196-1-philmd@linaro.org>
 <20241217151305.29196-3-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20241217151305.29196-3-philmd@linaro.org>

On Tue, Dec 17, 2024 at 04:13:04PM +0100, Philippe Mathieu-Daudé wrote:
> Date: Tue, 17 Dec 2024 16:13:04 +0100
> From: Philippe Mathieu-Daudé 
> Subject: [PATCH 2/3] system/numa: Remove unnecessary 'exec/cpu-common.h'
>  header
> X-Mailer: git-send-email 2.45.2
> 
> Nothing requires definitions from "exec/cpu-common.h",
> do not include this header.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  include/sysemu/numa.h | 1 -
>  1 file changed, 1 deletion(-)

Reviewed-by: Zhao Liu 



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 16:11:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 16:11:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859393.1271517 (Exim 4.92)
	(envelope-from )
	id 1tNaAk-0004Y6-Lg; Tue, 17 Dec 2024 16:11:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859393.1271517; Tue, 17 Dec 2024 16:11: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 1tNaAk-0004Xz-J9; Tue, 17 Dec 2024 16:11:46 +0000
Received: by outflank-mailman (input) for mailman id 859393;
 Tue, 17 Dec 2024 16:11: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 1tNaAj-0004Xt-KP
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 16:11:45 +0000
Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 99e89e41-bc91-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 17:11:43 +0100 (CET)
Received: from fmviesa009.fm.intel.com ([10.60.135.149])
 by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 17 Dec 2024 08:06:08 -0800
Received: from liuzhao-optiplex-7080.sh.intel.com (HELO localhost)
 ([10.239.160.39])
 by fmviesa009.fm.intel.com with ESMTP; 17 Dec 2024 08:06:06 -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: 99e89e41-bc91-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1734451903; x=1765987903;
  h=date:from:to:cc:subject:message-id:references:
   mime-version:content-transfer-encoding:in-reply-to;
  bh=ADb5LrrPM45Iltt7daJmxHcrLCSyT/62xcSAmOFT7SE=;
  b=ZZp/Y33jjKvjGJyAnm6NS0z2IGe7DjzmyYgYcgTyKp6NwxfxZ4XLHYP5
   aiHuN92F2f2DR7o3BNSNBH2SsTrOZP5kvNJAy1R3T0NJkg/ETfYmXY3Wx
   +VWwccB30U+IYtQQe9+/quI84bavc2864VzLDFjzWe0aCqhCAe+A62Xg8
   q8lz1S3Hxo1AdASzbyhzfoCoFZ36WWlW3lK3d5Iuj7R/2SOhczvlPOkm/
   db1ZeGemtoCyNetgCzV8WpzVopnBvhhnZe9ohDIgy06vKT7nFLPUoamKh
   rQSsu4hab73b7npeQPmu+ZEO/zhotYvLbit7jr7wCB185clNB29Ltj37w
   w==;
X-CSE-ConnectionGUID: bA3ROYJ1RwOUBtZ/IJGwpQ==
X-CSE-MsgGUID: BMuf0eVcRbCoLkpxTNRtwA==
X-IronPort-AV: E=McAfee;i="6700,10204,11288"; a="34778439"
X-IronPort-AV: E=Sophos;i="6.12,242,1728975600"; 
   d="scan'208";a="34778439"
X-CSE-ConnectionGUID: rozFU8KBSmWf/b67cOyFeA==
X-CSE-MsgGUID: 8ivHx4rvS5SaWz8EmpyQAQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.12,242,1728975600"; 
   d="scan'208";a="98151026"
Date: Wed, 18 Dec 2024 00:24:45 +0800
From: Zhao Liu 
To: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= 
Cc: qemu-devel@nongnu.org, Stefano Stabellini ,
	"Edgar E. Iglesias" ,
	Paul Durrant ,
	Richard Henderson ,
	Yanan Wang , Anton Johansson ,
	Anthony PERARD ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 3/3] system/accel-ops: Remove unnecessary
 'exec/cpu-common.h' header
Message-ID: 
References: <20241217151305.29196-1-philmd@linaro.org>
 <20241217151305.29196-4-philmd@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20241217151305.29196-4-philmd@linaro.org>

On Tue, Dec 17, 2024 at 04:13:05PM +0100, Philippe Mathieu-Daudé wrote:
> Date: Tue, 17 Dec 2024 16:13:05 +0100
> From: Philippe Mathieu-Daudé 
> Subject: [PATCH 3/3] system/accel-ops: Remove unnecessary
>  'exec/cpu-common.h' header
> X-Mailer: git-send-email 2.45.2
> 
> Since commit c4b3f46c151 ("include/exec: Move vaddr defines to
> separate file") we only need to include "exec/vaddr.h" to get
> the 'vaddr' type definition, no need for "exec/cpu-common.h".
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  include/sysemu/accel-ops.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Zhao Liu 



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 16:12:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 16:12:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859399.1271527 (Exim 4.92)
	(envelope-from )
	id 1tNaBS-000547-Ta; Tue, 17 Dec 2024 16:12:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859399.1271527; Tue, 17 Dec 2024 16:12:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNaBS-000540-Qu; Tue, 17 Dec 2024 16:12:30 +0000
Received: by outflank-mailman (input) for mailman id 859399;
 Tue, 17 Dec 2024 16:12: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 1tNaBS-0004Xt-C7
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 16:12:30 +0000
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
 [2a00:1450:4864:20::42f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b625168e-bc91-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 17:12:28 +0100 (CET)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-3862df95f92so2802921f8f.2
 for ; Tue, 17 Dec 2024 08:12: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-388c80120dcsm11805797f8f.8.2024.12.17.08.12.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 08:12: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: b625168e-bc91-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734451948; x=1735056748; 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=nlCT9xubKhsVArmmCmXQLeMQkwVs3crBvROWCBas4+o=;
        b=Vda70zUCHlw2c0wVCIpcRvxV/GW+tQ/X9pzOLZYceOn0oH84FIDkYfyV9HCnKiTle/
         GA8IL21P7iZ6G0usyeHlC0pZz8hlZrlKgSk6xlcgwTWRSJ74XRAll01FbronCKQl/459
         ZrYMBnc0z8o/fb61po7xsYRXiMF/L2itqX7aXZOHccdk6UCUDSnKDjizMQ+CstJTGk91
         1sbVuXRucfadMi9xoyzAJz7vdpSxj7had2FAeT+4TSJGnAvVhafxBHtuWuTDga2hJ6L6
         mKRRWUSaaKBdV6TW18rPJL+lGHuEZb74ibKKBugyGHsJpZnKw40yhkx9KldK/Zt3YLBk
         oLXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734451948; x=1735056748;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nlCT9xubKhsVArmmCmXQLeMQkwVs3crBvROWCBas4+o=;
        b=L1OaXbbxR4RIZhJlHqJfqU7/XwEnN2b/CvfnjQRc7GZ9iAznf/pEp0VpnTBqMI88cc
         EIsubn4XSv09Vu8wmeAU+zBNS94UXxPGwg23SaGDGHORKK5SzkeR3Po5cneeDLUOpX0U
         fGS4mUf8xyLfjM5VJ2hT+ADrcGXnKbM+dt06B6hM7yua5GOKRg0O+9M+K7BVdzrsCsui
         WZYjBoE2GNCBx6x48Hik5Y5vfrkoNlBoUHC54hOy3Hro8wT1AjY5mQ9ogTFyLVHiS+oo
         ZWnyH5/3tRGq3IgAvd7y7FhVl2rG/bVWQkf0m5wX1c32YtaiISv0DtZzAVgj8KIO/tzd
         uhVw==
X-Forwarded-Encrypted: i=1; AJvYcCUpUhmrYlJGo/tlyNvA+yh8RQoE7g+c/qYThl04sjzPlzU0IJoL5ggWvvYmlYZSToWU3WKC/KkXCwM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw2J3QRQ1vTFKhDDyqOwHyRJCEAH++VAYVobEWv39grHJuwdeAL
	x+5Bi0azDny6x8D4jDftWdw+ENFUagrUn9QqTbtztfHLeCvJZAw8yJJ7Rfwb5A==
X-Gm-Gg: ASbGncsen+BZqHBc8PxIVWCf8Pw6fivpo69DMoF8lPZAzPMxFnpL3wxxgBUEMGSMQv2
	9xyFfxBoZugHcOzPyp1lYVfjWnbZRvBQUT5PhDxRXjR6HBMS3D56+3w61Q7LwDZeloWO2ZArYgD
	pWxHZItKhNoyrIFLVHVDojnbWhQ2I65gJyJTXa0BSW+ufwmlRAiy92tvwad2H2zwlz0uHegRTSH
	pNsk3QMhnw3whE77BNz127PJPnU93bCWgCrqskuwpvEUEX8D0+T8RTf1Lo0GQstHs9V5HzUE2H8
	h5uv+jQ9D+xcgJ+9rWH61qlphp0lhseM3LNYcnAXcg==
X-Google-Smtp-Source: AGHT+IEjJh0vLqU0xCZ7QrftBSB+LQjyh4IPIJn9lvaRwXH3fu2mwQcluMaPRcyjPhgJiHyhlqxuoA==
X-Received: by 2002:a5d:5984:0:b0:385:fc32:1ec6 with SMTP id ffacd0b85a97d-3888e0c081bmr13298391f8f.50.1734451947893;
        Tue, 17 Dec 2024 08:12:27 -0800 (PST)
Message-ID: 
Date: Tue, 17 Dec 2024 17:12:27 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 2/5] xen: add bitmap to indicate per-domain state
 changes
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
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: <20241217142218.24129-1-jgross@suse.com>
 <20241217142218.24129-3-jgross@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 17.12.2024 16:55, Jürgen Groß wrote:
> On 17.12.24 16:19, Jan Beulich wrote:
>> On 17.12.2024 15:22, Juergen Gross wrote:
>>> Add a bitmap with one bit per possible domid indicating the respective
>>> domain has changed its state (created, deleted, dying, crashed,
>>> shutdown).
>>>
>>> Registering the VIRQ_DOM_EXC event will result in setting the bits for
>>> all existing domains and resetting all other bits.
>>>
>>> As the usage of this bitmap is tightly coupled with the VIRQ_DOM_EXC
>>> event, it is meant to be used only by a single consumer in the system,
>>> just like the VIRQ_DOM_EXC event.
>>
>> I'm sorry, but I need to come back to this. I thought I had got convinced
>> that only a single entity in the system can bind this vIRQ. Yet upon
>> checking I can't seem to find what would guarantee this. In particular
>> binding a vIRQ doesn't involve any XSM check. Hence an unprivileged entity
>> could, on the assumption that the interested privileged entity (xenstore)
>> is already up and running, bind and unbind this vIRQ, just to have the
>> global map freed. What am I overlooking (which would likely want stating
>> here)?
> 
> I think you are not overlooking anything.
> 
> I guess this can easily be handled by checking that the VIRQ_DOM_EXC handling
> domain is the calling one in domain_[de]init_states(). Note that global virqs
> are only ever sent to vcpu[0] of the handling domain, so rebinding the event
> to another vcpu is possible, but doesn't make sense.

No, that's precluded by

    if ( virq_is_global(virq) && (vcpu != 0) )
        return -EINVAL;

afaict. That doesn't, however, preclude multiple vCPU-s from trying to bind
the vIRQ to vCPU 0.

>>> V5:
>>> - domain_init_states() may be called only if evtchn_bind_virq() has been
>>>    called validly (Jan Beulich)
>>
>> I now recall why I had first suggested the placement later in the handling:
>> You're now doing the allocation with yet another lock held. It's likely not
>> the end of the world, but ...
>>
>>> @@ -138,6 +139,60 @@ bool __read_mostly vmtrace_available;
>>>   
>>>   bool __read_mostly vpmu_is_available;
>>>   
>>> +static DEFINE_SPINLOCK(dom_state_changed_lock);
>>> +static unsigned long *__read_mostly dom_state_changed;
>>> +
>>> +int domain_init_states(void)
>>> +{
>>> +    const struct domain *d;
>>> +    int rc = -ENOMEM;
>>> +
>>> +    spin_lock(&dom_state_changed_lock);
>>> +
>>> +    if ( dom_state_changed )
>>> +        bitmap_zero(dom_state_changed, DOMID_FIRST_RESERVED);
>>> +    else
>>> +    {
>>> +        dom_state_changed = xvzalloc_array(unsigned long,
>>> +                                           BITS_TO_LONGS(DOMID_FIRST_RESERVED));
>>
>> ... already this alone wasn't nice, and could be avoided (by doing the
>> allocation prior to acquiring the lock, which of course complicates the
>> logic some).
>>
>> What's perhaps less desirable is that ...
>>
>>> @@ -494,6 +495,15 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
>>>           goto out;
>>>       }
>>>   
>>> +    if ( virq == VIRQ_DOM_EXC )
>>> +    {
>>> +        rc = domain_init_states();
>>> +        if ( rc )
>>> +            goto out;
>>> +
>>> +        deinit_if_err = true;
>>> +    }
>>> +
>>>       port = rc = evtchn_get_port(d, port);
>>>       if ( rc < 0 )
>>>       {
>>
>> ... the placement here additionally introduces lock nesting when really
>> the two locks shouldn't have any relationship.
>>
>> How about giving domain_init_states() a boolean parameter, such that it
>> can be called twice, with the first invocation moved back up where it
>> was, and the second one put ...
>>
>>> @@ -527,6 +537,9 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
>>>    out:
>>>       write_unlock(&d->event_lock);
>>>   
>>> +    if ( rc && deinit_if_err )
>>> +        domain_deinit_states();
>>> +
>>>       return rc;
>>>   }
>>
>> ... down here, not doing any allocation at all (only the clearing), and
>> hence eliminating the need to deal with its failure? (Alternatively
>> there could of course be a split into an init and a reset function.)
>>
>> There of course is the chance of races with such an approach. I'd like
>> to note though that with the placement of the call in the hunk above
>> there's a minor race, too (against ...
>>
>>> @@ -730,6 +743,9 @@ int evtchn_close(struct domain *d1, int port1, bool guest)
>>>           struct vcpu *v;
>>>           unsigned long flags;
>>>   
>>> +        if ( chn1->u.virq == VIRQ_DOM_EXC )
>>> +            domain_deinit_states();
>>
>> ... this and the same remote vCPU then immediately binding the vIRQ
>> again). Hence yet another alternative would appear to be to drop the
>> new global lock and use d->event_lock for synchronization instead
>> (provided - see above - that only a single entity can actually set up
>> all of this). That would pretty much want to have the allocation kept
>> with the lock already held (which isn't nice, but as said is perhaps
>> tolerable), but would at least eliminate the undesirable lock nesting.
>>
>> Re-use of the domain's event lock is at least somewhat justified by
>> the bit array being tied to VIRQ_DOM_EXEC.
>>
>> Thoughts?
> 
> With my suggestion above I think there is no race, as only the domain handling
> VIRQ_DOM_EXC could alloc/dealloc dom_state_changed.

Yet still it could be multiple vCPU-s therein to try to in parallel.

> Using d->event_lock for synchronization is not a nice option IMO, as it would
> require to take the event_lock of the domain handling VIRQ_DOM_EXEC when trying
> to set a bit for another domain changing state.

Well, yes, it's that domain's data that's to be modified, after all.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 16:24:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 16:24:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859412.1271537 (Exim 4.92)
	(envelope-from )
	id 1tNaN3-0006zb-TS; Tue, 17 Dec 2024 16:24:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859412.1271537; Tue, 17 Dec 2024 16:24: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 1tNaN3-0006zU-Qv; Tue, 17 Dec 2024 16:24:29 +0000
Received: by outflank-mailman (input) for mailman id 859412;
 Tue, 17 Dec 2024 16:24: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 1tNaN1-0006zO-M3
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 16:24:28 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6161773b-bc93-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 17:24:25 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.214])
 by support.bugseng.com (Postfix) with ESMTPSA id E593E4EE0738;
 Tue, 17 Dec 2024 17:24:23 +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: 6161773b-bc93-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1734452664; bh=nNvsqr0VCk5Pzf6ZRTEPm1/KB8uV5pXnIQ4aAQnURrc=;
	h=From:To:Cc:Subject:Date:From;
	b=QRoySKfSoF2LJ0bimMdwQ9nCCoIE3VfTm0/wG3dw3F28rqBZJMG2KnAVJAFv6yKUr
	 tlQu9y+P2ou3eN8oFSJJgQjG5PELqI5wEZr4USy1cCnQ3xrn9MvZf6ye7wO0YWPo2Z
	 zF5Kz81+110o8C3DC58xRS0IROVMFpiZeiK2ma8O+loJzoChWduFYt3GszlwG9hqfy
	 vX5noKywEu/4i+l6ebasHDWFWUYYcYk0sZWaB/nAU40uk/hYDayE5UdUo0EzJ6TM+I
	 GYPfx9kS6kTvdTPdJpvqGz1wnGz8BmXMtUrdpEQfhFBG15fw8zm2wFlmdRPJtzHR9l
	 s16txLjqm62xQ==
From: Nicola Vetrini 
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	Nicola Vetrini ,
	Simone Ballarin ,
	Doug Goldstein ,
	Andrew Cooper3 
Subject: [XEN PATCH] eclair-analysis: Add usage of varargs extension for C99
Date: Tue, 17 Dec 2024 17:24:20 +0100
Message-ID: 
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This extension name is missing from the current list of extension used
by Xen, therefore is must be added to that configuration in order to
avoid violations for MISRA C Rule 1.1.

Signed-off-by: Nicola Vetrini 
---
 automation/eclair_analysis/ECLAIR/toolchain.ecl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/toolchain.ecl b/automation/eclair_analysis/ECLAIR/toolchain.ecl
index 86e9a79b5231..9b419e562afa 100644
--- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
+++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
@@ -100,8 +100,8 @@
     ext_enum_value_not_int: non-documented GCC extension.
     ext_gnu_array_range: see Section \"6.29 Designated Initializers\" of "GCC_MANUAL".
 "
--config=STD.diag,behavior+={c99,GCC_ARM64,"^(ext_paste_comma|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_forward_ref_enum_def|ext_gnu_array_range)$"}
--config=STD.diag,behavior+={c99,GCC_X86_64,"^(ext_paste_comma|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_flexible_array_in_struct|ext_flexible_array_in_array|ext_enum_value_not_int|ext_gnu_array_range)$"}
+-config=STD.diag,behavior+={c99,GCC_ARM64,"^(ext_paste_comma|ext_c_missing_varargs_arg|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_forward_ref_enum_def|ext_gnu_array_range)$"}
+-config=STD.diag,behavior+={c99,GCC_X86_64,"^(ext_paste_comma|ext_c_missing_varargs_arg|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_flexible_array_in_struct|ext_flexible_array_in_array|ext_enum_value_not_int|ext_gnu_array_range)$"}
 -doc_end

 -doc_begin="The maximum size of an object is defined in the MAX_SIZE macro, and for a 32 bit architecture is 8MB.
--
2.43.0


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 16:26:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 16:26:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859416.1271548 (Exim 4.92)
	(envelope-from )
	id 1tNaPE-0007bv-8E; Tue, 17 Dec 2024 16:26:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859416.1271548; Tue, 17 Dec 2024 16:26:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNaPE-0007bo-5i; Tue, 17 Dec 2024 16:26:44 +0000
Received: by outflank-mailman (input) for mailman id 859416;
 Tue, 17 Dec 2024 16:26: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 1tNaPC-0007bh-NJ
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 16:26:42 +0000
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com
 [2a00:1450:4864:20::443])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b28e39f9-bc93-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 17:26:41 +0100 (CET)
Received: by mail-wr1-x443.google.com with SMTP id
 ffacd0b85a97d-385f06d0c8eso2752524f8f.0
 for ; Tue, 17 Dec 2024 08:26:41 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c8060862sm11410366f8f.100.2024.12.17.08.26.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 08:26: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: b28e39f9-bc93-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734452801; x=1735057601; 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=98J1ocuFRVQqxhJV1M2ul5KYu5m3q4S/ZBRYRLDAgtk=;
        b=Z+KrJSVmy8fY6nWRczhGTR1e3dtRka5n4Bbp3STmNAIAlzP0mnU6PiMNkcYdKJKC5k
         sAV5cfUzPb0RXK2y7sVYRNlQyftpYg0sCz3eYTXEM7dh9Geizd6Er2F/D2wCp5KgBcRn
         Mq1K+lH/ML8xz30DBMMCS6ZUCZI3hFmLmHpwc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734452801; x=1735057601;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=98J1ocuFRVQqxhJV1M2ul5KYu5m3q4S/ZBRYRLDAgtk=;
        b=Bsc89yATB/F5inq+T8IWrRwb94ilZshRQEjvJ4yHZHy9IS8wzg4cXaAQWDhtSduolQ
         3ZP+p26fl3C2HDeYEvNeGpCy5i5hXw9WjtPrC70NeiJuM7CeTQNwXWnLWTDY172r1Ww6
         sxObJ0AI4ikqxR+HGWGrIV1KM1D+5qGOGiCv8IIH92UqqvS0PhG2KfeY4Z4ZeCrrC74u
         ny2l5v5T0MBaTN64AIsQ7kuhTJjxOwp7Qvs+FJxQJDTOepXTnWk7ArhKoqVuIuU9uyXG
         0yNC8sNkCkbsA6Iv00hZTpjGzGDMrARA0icb+bpshk+2yNVr4506iugHX+a93R8rS+9T
         oymA==
X-Forwarded-Encrypted: i=1; AJvYcCVFHlsoiZ88lRRXyegt6HmdxaQuT8O5tOYGLR63CKjho+hV82wJ5VrEKGVcQJWXBEHFTLZAiNxW+dc=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzwV5TDMq2qWtACbWzUuR6bIwQ77iE0B7xaQx8rBGSw1IMUp2La
	DgFQJ4FmEnjzM/Bh8LRW8uNJMXrtBkZkxUVUvrXQiulBBp0t958bUVLn7ZFHmaM=
X-Gm-Gg: ASbGncsqV11cBO4kbsMdKodoPxEX27xcGlLPFcGloRpULdhCOmmnU7RlALocKLDeFs2
	K2TsW3PASSlvDXNNHgA8euOxZYb+5lIRExYdi4vB/MpBdh6RR7iQa8oSiM1xckCxRe2rnMV0Zs6
	9iPw2nzkQ5FDhwNnQKgmqbWJhu+E6IOdSFO8xBvgjOKmHPyZigKjpgjUNTphQ1kfuS1Z0O4+UP8
	e/io+1a+fbZ4kpW1AhJHfkQcChyChy1ODYQZzSVJTAuOtSqx/k0GK7HVYN2phlyPZcK6hqmhJtN
	X3qOL/nwLNNAp5Bu3Hyz
X-Google-Smtp-Source: AGHT+IEjZuxpCJWJF0Ml1kPBCCd/P5QNTqV7/NFAihWpsTRNzbBhXLtnADPMoJm1GzoyBBXROFe58g==
X-Received: by 2002:a05:6000:4b15:b0:385:fab3:c56d with SMTP id ffacd0b85a97d-3886c72384dmr15366118f8f.0.1734452800947;
        Tue, 17 Dec 2024 08:26:40 -0800 (PST)
Message-ID: 
Date: Tue, 17 Dec 2024 16:26:39 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/1] tools, xen/scripts: clear out Python syntax
 warnings
To: Ariel Otilibili ,
 xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
 Anthony PERARD ,
 Luca Fancellu 
References: <20241214161350.70515-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216231128.211648-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216231128.211648-2-Ariel.Otilibili-Anieli@eurecom.fr>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20241216231128.211648-2-Ariel.Otilibili-Anieli@eurecom.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 16/12/2024 11:07 pm, Ariel Otilibili wrote:
> * since 3.12 invalid escape sequences generate SyntaxWarning
> * in the future, these invalid sequences will generate SyntaxError
> * therefore changed syntax to raw string notation.
>
> Link: https://docs.python.org/3/whatsnew/3.12.html#other-language-changes
> Fixes: d8f3a67bf98 ("pygrub: further improve grub2 support")
> Fixes: dd03048708a ("xen/pygrub: grub2/grub.cfg from RHEL 7 has new commands in menuentry")
> Fixes: d1b93ea2615 ("tools/pygrub: Make pygrub understand default entry in string format")
> Fixes: 622e368758b ("Add ZFS libfsimage support patch")
> Fixes: 02b26c02c7c ("xen/scripts: add cppcheck tool to the xen-analysis.py script")
> Fixes: 56c0063f4e7 ("xen/misra: xen-analysis.py: Improve the cppcheck version check")
>
> Cc: Anthony PERARD 
> Cc: Luca Fancellu 
> Cc: Andrew Cooper 
> Signed-off-by: Ariel Otilibili 

Having poked about a bit more, this is all a big mess, but these do now
work with Py3.12.

leading \ for non-special characters are ignored in [], which is why ...

> ---
>  tools/pygrub/src/GrubConf.py                  | 4 ++--
>  tools/pygrub/src/pygrub                       | 6 +++---
>  xen/scripts/xen_analysis/cppcheck_analysis.py | 4 ++--
>  3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/GrubConf.py
> index 580c9628ca..904e7d5567 100644
> --- a/tools/pygrub/src/GrubConf.py
> +++ b/tools/pygrub/src/GrubConf.py
> @@ -320,7 +320,7 @@ class GrubConfigFile(_GrubConfigFile):
>  def grub2_handle_set(arg):
>      (com,arg) = grub_split(arg,2)
>      com="set:" + com
> -    m = re.match("([\"\'])(.*)\\1", arg)
> +    m = re.match(r"([\"\'])(.*)\1", arg)

... the \' works here.

Anyway, I've checked the others and they seem to work, so I suggest
taking this roughly this form.

Some notes about the commit message.  The subject ought to be:

tools: Fix syntax warnings with Python 3.12

The text should be a regular paragraph, rather than bullet points like this.

I can fix this all on commit if you're happy.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 16:33:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 16:33:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859438.1271598 (Exim 4.92)
	(envelope-from )
	id 1tNaVM-0002HP-0H; Tue, 17 Dec 2024 16:33:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859438.1271598; Tue, 17 Dec 2024 16: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 1tNaVL-0002HA-SE; Tue, 17 Dec 2024 16:33:03 +0000
Received: by outflank-mailman (input) for mailman id 859438;
 Tue, 17 Dec 2024 16:33: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 1tNaVK-0001J8-4y
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 16:33:02 +0000
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com
 [2a00:1450:4864:20::22d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 949a6394-bc94-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 17:33:00 +0100 (CET)
Received: by mail-lj1-x22d.google.com with SMTP id
 38308e7fff4ca-3022598e213so53711211fa.0
 for ; Tue, 17 Dec 2024 08:33:00 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-30344175b51sm13179021fa.69.2024.12.17.08.32.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 08: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: 949a6394-bc94-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734453179; x=1735057979; 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=COLAwTsK8KOA8E4uFs654fi6y7eVlKrSbKVPVTbpnco=;
        b=NaK7mWP6EZMPweL9iugUHTaLO+teOF83AGwg6IDibgUM0OHcD/vR6HCfQTSV5BrLCw
         HGIW1AANkmHhm4A5c2fuIXK/Svfu0VKvgxGbytXImW1MMuaaezVAe6gljQVsypU19tSz
         s9oWg3dwuZECs8As1WbnrLWjYQV61jzwyGlTGa09Pf7ypT/QpZnDypgSlQ7xpU7V0i59
         PPakavBmkyqM/nsSI8VzYmf/IN/MCM8VsfLrycUpx+B+I1btbnI5dzQUMpna05hwMDe5
         ufgFxN3uPSS5OTCjb9yNq36XGFmJZzBRBkCBKJozYcTInOJ63UD1tMLegAlbE7O62L+m
         fYvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734453179; x=1735057979;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=COLAwTsK8KOA8E4uFs654fi6y7eVlKrSbKVPVTbpnco=;
        b=J+w1YctXCundEK2PMJvqQwgtlZId6re9DptKp3L+IF/zvUdLnB5/XzjOCxHrNjgOom
         2oAthi1DjumyD1iXV2AkRcx59nxea3lU/vVSIE0APa8J7LBZCmxmmRgbpenWxo2GEVjz
         sl3CqCe5PaBdxGPMnW++K7efNm32Nss1la+tA+dlD48Chn2NnWs4QkUD7HSo61gDw5LB
         +5Jvb1Vgvaym39yRsuP2lfIrfPiYSFw9Wnk/kjDLrG1rvcF00MlWe2OaY0C0Xnpj3+UY
         YW3vkmkxdbJEuruKw2rpGnnKoNsiY/ApcZC3swP8fT6ANaxjG7BhJKCt/NNx5y0+Pnka
         HJWg==
X-Gm-Message-State: AOJu0Yzgjz1sSOZe/Q/CyW6ABt7EiHGLJW7GPaBVaufRFxljX1bkFrOs
	hCZqBYEwJSKTqARr6XKgDUyvO8RywWjpHp9Ot2TVDuLkiuKFh1Ns4RxQ4wc8
X-Gm-Gg: ASbGncv21dsGTVJit3hNcl3hXw8dfYWtY3c0PIb/5GtdjvUizhEJWKUozzTpNLuypwu
	WUMCxHTBw7StrUh8XImXIDAqBg9p6FzeqXDA5CHvSrDf6fvoPTRrj8XgOBpY1g3P25afCgDDyaO
	L1poEHn6nMtJiJtqmcs7fdhMAm1tPP/CJI5Rx0BLSSG7dJvopL+cLBpIco+azK27C0DdxdBocfO
	eVIkYVer9ZWHZLFgvFtCirQEWu5v5xDZ/qdRSbmyLnMa5zgH06DbrdjAQ==
X-Google-Smtp-Source: AGHT+IH72GX86NpSR4Ud+2h/3T7SlD9ypv7lg2VcJ8D2evWfj3ikKjxJXjIxUtwidPHtH/IE8TKVbg==
X-Received: by 2002:a2e:be25:0:b0:2ff:56a6:2992 with SMTP id 38308e7fff4ca-302544cd514mr49542241fa.37.1734453179235;
        Tue, 17 Dec 2024 08:32:59 -0800 (PST)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 4/7] xen/riscv: add {set,clear}_fixmap() functions for managing fixmap entries
Date: Tue, 17 Dec 2024 17:32:48 +0100
Message-ID: <46bd4f5cd2f41e8f0d00be3bdd9887e57dfdcdc2.1734452721.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce set_fixmap() and clear_fixmap() functions to manage mappings
in the fixmap region. The set_fixmap() function maps a 4k page ( as only L0
is expected to be updated; look at setup_fixmap_mappings() ) at a specified
fixmap entry using map_pages_to_xen(), while clear_fixmap() removes the
mapping from a fixmap entry by calling destroy_xen_mappings().

Both functions ensure that the operations succeed by asserting that their
respective calls (map_pages_to_xen() and destroy_xen_mappings()) return 0.
`BUG()` is added to trigger a failure if any issues occur during
the mapping or unmapping process.

Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V3:
 - Fix code style: ident if-condition properly.
---
Changes in V2:
 - Update the commit message.
 - drop local variables from {set, clear}_fixmap(); use if (... != 0) + BUG().
---
 xen/arch/riscv/include/asm/fixmap.h |  5 +++++
 xen/arch/riscv/pt.c                 | 16 ++++++++++++++++
 2 files changed, 21 insertions(+)

diff --git a/xen/arch/riscv/include/asm/fixmap.h b/xen/arch/riscv/include/asm/fixmap.h
index 818c8ce07b..e399a15f53 100644
--- a/xen/arch/riscv/include/asm/fixmap.h
+++ b/xen/arch/riscv/include/asm/fixmap.h
@@ -32,6 +32,11 @@
  */
 extern pte_t xen_fixmap[];
 
+/* Map a page in a fixmap entry */
+void set_fixmap(unsigned int map, mfn_t mfn, unsigned int flags);
+/* Remove a mapping from a fixmap entry */
+void clear_fixmap(unsigned int map);
+
 #define fix_to_virt(slot) ((void *)FIXMAP_ADDR(slot))
 
 static inline unsigned int virt_to_fix(vaddr_t vaddr)
diff --git a/xen/arch/riscv/pt.c b/xen/arch/riscv/pt.c
index 2ca23206f4..aea9f97a5a 100644
--- a/xen/arch/riscv/pt.c
+++ b/xen/arch/riscv/pt.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -433,3 +434,18 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns)
 {
     return pt_update(virt, INVALID_MFN, nr_mfns, PTE_POPULATE);
 }
+
+/* Map a 4k page in a fixmap entry */
+void set_fixmap(unsigned int map, mfn_t mfn, unsigned int flags)
+{
+    if ( map_pages_to_xen(FIXMAP_ADDR(map), mfn, 1, flags | PTE_SMALL) != 0 )
+        BUG();
+}
+
+/* Remove a mapping from a fixmap entry */
+void clear_fixmap(unsigned int map)
+{
+    if ( destroy_xen_mappings(FIXMAP_ADDR(map),
+                              FIXMAP_ADDR(map) + PAGE_SIZE) != 0 )
+        BUG();
+}
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 16:33:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 16:33:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859435.1271564 (Exim 4.92)
	(envelope-from )
	id 1tNaVI-0001Lx-B5; Tue, 17 Dec 2024 16:33:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859435.1271564; Tue, 17 Dec 2024 16:33: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 1tNaVI-0001Kq-3k; Tue, 17 Dec 2024 16:33:00 +0000
Received: by outflank-mailman (input) for mailman id 859435;
 Tue, 17 Dec 2024 16:32:59 +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 1tNaVH-0001J8-4j
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 16:32:59 +0000
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com
 [2a00:1450:4864:20::22f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 92487daf-bc94-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 17:32:56 +0100 (CET)
Received: by mail-lj1-x22f.google.com with SMTP id
 38308e7fff4ca-30229d5b229so53725561fa.0
 for ; Tue, 17 Dec 2024 08:32:56 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-30344175b51sm13179021fa.69.2024.12.17.08.32.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 08:32: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: 92487daf-bc94-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734453176; x=1735057976; 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=0ja52G4IQuA2xu4VoTss+DEM7hw7d/dQyOCwy0WEPHU=;
        b=YdhCBKQqsFn1nHgOR8gIODSDin+T7iluk03TWdD0092m1qTCCSv1udOneSkJ/xVFCA
         RX7xef35skqW8tnaQVyZ7tsCz/qxhVSm+yQgDgppcD2g8ikEa0sSMm2dXqXLhKXc3CKQ
         YR1epD6tqJXzzeEH1LN8CkYyxHpAIcNTK/AymiCNH2Mbz6mvIotCd+CjvEwQDwqSdwsZ
         guDvsTpepgecVBY36NYQQfiRYBJ0YTJoy2jSdJFOQZPt1C3l/WRPxJTtiOcKMbyYffVb
         A+yLb6ztzq+ix+bbkXC85OSzNMCHA1Yvp7/fLb3vXzGw5WJ6NesgWGQHLurzo1hNNMY4
         fi3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734453176; x=1735057976;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=0ja52G4IQuA2xu4VoTss+DEM7hw7d/dQyOCwy0WEPHU=;
        b=rDKNNTvl+/HuzPjOzJv8KD/5zgppgd+MJe2kZEgeGU0lhhfe8I3NKd2Dmfi+uB7R1G
         HmMG7Whd2VYaeS1l/vj10bFb6QnmmgRfNDRlqqUGzl7AqoBEnpUX5FR6Q24HR1AI6oJe
         FkBQIidqzYICnlV8JMu8vyRuqq7BCsHM6OZRDtWljk8aXlqDjCHjY1c6UaA0nwQnvgr6
         ccT8E/EEMqSt7rFwnjF4iHrze9y6PAXVM9LA0LEq3ZcFG3Rr4jUoH2cNk2tMXlht3cvk
         6XGyZgH9vldfeKJKJHxmZfdbbikHzvX8ylmtq0XP+zf8snxMOg9TJQUn/jqxCF1KUCO+
         9y8Q==
X-Gm-Message-State: AOJu0YxxznH4roI14Dr2ojQIGxnvXBXvYgoEdxzjYSP92+FVj2tnAk4l
	hOtUPH7jFhsSyBO+Uv9DKdXDa2hKZtOwWm8ooaa1FXx3dm3yMiMHO/ihsauP
X-Gm-Gg: ASbGncuXtHEvCze7FbLklGHpWNYZPIzdq6+OXIbyAd+q5HpCOoyjNXA0sDJefCr6CbV
	Z0fsrRmeN/2q3xg5l2GWI+2DSIK3aooIUkpLyeX+I/SEkWYdj0NtUi2Ylu50eRNNlzaTcMo/xmU
	Tjv93KxJGF0Fe4Ji+P9ZvO8oS4f6TCNceUpFHkqL2yAUitC4B0NphtNqSGMqnNIreATyaW+EV+r
	ZF9TP2NGa7JNZOwO9UDow/d7Tho8v0rPoNuXV8EZ//t/YkK+gMqC11plw==
X-Google-Smtp-Source: AGHT+IEgnG0nBK6Xz11aVTX4EQTfPpcm/ADBzlzfvN+UnBe64SwJYspZIQdu+3mLJg87eU8uKcOsFg==
X-Received: by 2002:a05:651c:19a4:b0:302:40ee:4c37 with SMTP id 38308e7fff4ca-3044cfeac6cmr648731fa.8.1734453175775;
        Tue, 17 Dec 2024 08:32:55 -0800 (PST)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 1/7] xen/riscv: update layout table in config.h
Date: Tue, 17 Dec 2024 17:32:45 +0100
Message-ID: 
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Make all upper bounds (end addresses) for areas inclusive to align
with the corresponding definitions.

For the Direct map region, the upper bound was calculated incorrectly
in efadb18dd58aba ("xen/riscv: add VM space layout"). It should be
0x7f80000000 (considering that the value is exclusive, instead of
0x7f40000000). Therefore, the inclusive upper bound for that region
is 0x7f80000000 - 1.

Signed-off-by: Oleksii Kurochko 
---
Changes in v2:
 - update the commit message: add explanation about direct map upper bound.
---
Changes in v2:
 - new patch
---
 xen/arch/riscv/include/asm/config.h | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/riscv/include/asm/config.h b/xen/arch/riscv/include/asm/config.h
index 4954677aff..826e5c7172 100644
--- a/xen/arch/riscv/include/asm/config.h
+++ b/xen/arch/riscv/include/asm/config.h
@@ -41,17 +41,17 @@
  * Start addr          | End addr         | Slot       | area description
  * ============================================================================
  *                   .....                 L2 511          Unused
- *  0xffffffffc0a00000  0xffffffffc0c00000 L2 511          Fixmap
+ *  0xffffffffc0a00000  0xffffffffc0bfffff L2 511          Fixmap
  *                   ..... ( 2 MB gap )
- *  0xffffffffc0400000  0xffffffffc0800000 L2 511          FDT
+ *  0xffffffffc0400000  0xffffffffc07fffff L2 511          FDT
  *                   ..... ( 2 MB gap )
- *  0xffffffffc0000000  0xffffffffc0200000 L2 511          Xen
+ *  0xffffffffc0000000  0xffffffffc01fffff L2 511          Xen
  *                   .....                 L2 510          Unused
- *  0x3200000000        0x7f40000000       L2 200-509      Direct map
+ *  0x3200000000        0x7f7fffffff       L2 200-509      Direct map
  *                   .....                 L2 199          Unused
- *  0x30c0000000        0x31c0000000       L2 195-198      Frametable
+ *  0x30c0000000        0x31bfffffff       L2 195-198      Frametable
  *                   .....                 L2 194          Unused
- *  0x3040000000        0x3080000000       L2 193          VMAP
+ *  0x3040000000        0x307fffffff       L2 193          VMAP
  *                   .....                 L2 0-192        Unused
 #elif RV_STAGE1_MODE == SATP_MODE_SV48
  * Memory layout is the same as for SV39 in terms of slots, so only start and
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 16:33:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 16:33:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859437.1271583 (Exim 4.92)
	(envelope-from )
	id 1tNaVJ-0001or-Oy; Tue, 17 Dec 2024 16:33:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859437.1271583; Tue, 17 Dec 2024 16:33: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 1tNaVJ-0001oA-Is; Tue, 17 Dec 2024 16:33:01 +0000
Received: by outflank-mailman (input) for mailman id 859437;
 Tue, 17 Dec 2024 16:33: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 1tNaVI-0001J8-4n
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 16:33:00 +0000
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com
 [2a00:1450:4864:20::230])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 92d7d980-bc94-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 17:32:57 +0100 (CET)
Received: by mail-lj1-x230.google.com with SMTP id
 38308e7fff4ca-3003e203acaso52208471fa.1
 for ; Tue, 17 Dec 2024 08:32:57 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-30344175b51sm13179021fa.69.2024.12.17.08.32.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 08:32:56 -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: 92d7d980-bc94-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734453177; x=1735057977; 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=B8fF4Ot/dFUzo2CoSRWH7wpyHlIxb6JWOqFio7Z7p/Y=;
        b=RgCZW4OaMBMl0hdncO/Lr2SI6Q1JTXTsOFdAS/A7zB4Ptp6zoe5YFlBVtqvJ42kR99
         Z2aj0Mz6xq86BBS3warbQG7r+8PjLOehRvp+n+3ItY0OTaBSjgYWcYJsM41nFRy4qNvT
         05ZQ6JedesrtgD0naA8pWB70PwHGB06bWPZlmZj+U9HhH09UqdzFTtmWggQYcpybUNAE
         FxJVgpxCnAHrpSPvgDNjjVITCSPTDuliknRjMeK/h7Nj7zYd5h7NIYRpGTMOvAKOoI3Q
         9MmNyjnqTvL2pFXhU8z+72tt7I+twYua7ptWjSi9L9CPj/j8lI8TJXa3lQXXxONNZG5y
         xBVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734453177; x=1735057977;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=B8fF4Ot/dFUzo2CoSRWH7wpyHlIxb6JWOqFio7Z7p/Y=;
        b=LBlenSV3de/7K9FnCVefNoSL+jdYtu9HAybEGmhE4I0W4WSOsRzfjwLZ7LS8RGeXX/
         gH/jSOrdFG1YNWAh5i5oDguMkX3NOB+fmWWE3I506GiPoRrPXswV/cSWVwQRe6hiW84i
         d66jcjkXi6/WhGECULwYlL+m+uc3fazU/WTqLCQvpImfhdd2OgnJdWsJwIW3T9iLQK5A
         rzwEaCtW5eqcONIqlE96/u5loc3i12cyU9EiWBE0zb87crug/j3LSgUCgYeDV0JRewH5
         jEePb52KyVIK1MpcheGpzxka4J4PSjlHuKz/inMax3VrPrJDBrw6iLqlpSj3MdEX1Q8E
         XT3w==
X-Gm-Message-State: AOJu0Yy20qqWxO2PmbWji8ayeS0zVehLqVMxwfc/KCVvd4o1fjizVwe1
	fxB6KcGnvhicR2HNtg8OBT8tNVcIisdjpg7wFe019vjkPLijoF5kCi0PxZlc
X-Gm-Gg: ASbGncvm802dhAQte35wM1JBg9AMm8F0OKW0rS37zsyV0UmJUpMvhIeT70pkExWOVW7
	IfOWU/LengzHdQ4N730jQqWdzDMLgikttMGxbtyZR3zlvkJo/bAeVVcmtGjVcfAXBsVfp+HRFLE
	DyGcnGATv8mtVSQiz86Hs/cTq1VLwY5f2yQt+Np7FUqw3mxv/D1VranjYMwXl+Uxf6uon9WyFCC
	KQKLqnR2zbLj/dPBANgXEg4N05yLkL0G+501Nt6tse3bJ1V1Vt/68C0kA==
X-Google-Smtp-Source: AGHT+IH2JOIKtRnNsomRm3tKEqH8lmP6boS2Fzn0jxvAbIOolpLhsFdfZkCNLix1IEEMZA1IFzEC0w==
X-Received: by 2002:a2e:a9a6:0:b0:302:1d7a:e09 with SMTP id 38308e7fff4ca-3044d29d399mr258061fa.31.1734453176861;
        Tue, 17 Dec 2024 08:32:56 -0800 (PST)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 2/7] xen/riscv: add destroy_xen_mappings() to remove mappings in Xen page tables
Date: Tue, 17 Dec 2024 17:32:46 +0100
Message-ID: <35f03b576d8423ca5b8764fdfe3251836f7b4a9a.1734452721.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce the destroy_xen_mappings() function, which removes page
mappings in Xen's page tables between a start address s and an end
address e.
The function ensures that both s and e are page-aligned
and verifies that the start address is less than or equal to the end
address before calling pt_update() to invalidate the mappings.
The pt_update() function is called with INVALID_MFN and PTE_VALID=0
in the flags, which tell pt_update() to remove mapping. No additional
ASSERT() is required to check these arguments, as they are hardcoded in
the call to pt_update() within destroy_xen_mappings().

Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V3:
 - Fix code style: drop blanks in condition part of ternary operation.
---
Changes in V2:
 - Drop ASSERT(s <= e).
 - Update implementation of destroy_xen_mappings() to avoid calling of
   pt_update() when start_addr >= end_addr and return -EINVAL.
 - Add Acked-by: Jan Beulich .
---
 xen/arch/riscv/mm.c | 6 ------
 xen/arch/riscv/pt.c | 8 ++++++++
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index 9359dc7f33..f2bf279bac 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -360,12 +360,6 @@ int xenmem_add_to_physmap_one(struct domain *d, unsigned int space,
     return 0;
 }
 
-int destroy_xen_mappings(unsigned long s, unsigned long e)
-{
-    BUG_ON("unimplemented");
-    return -1;
-}
-
 void share_xen_page_with_guest(struct page_info *page, struct domain *d,
                                enum XENSHARE_flags flags)
 {
diff --git a/xen/arch/riscv/pt.c b/xen/arch/riscv/pt.c
index d62aceb36c..2ca23206f4 100644
--- a/xen/arch/riscv/pt.c
+++ b/xen/arch/riscv/pt.c
@@ -421,6 +421,14 @@ int map_pages_to_xen(unsigned long virt,
     return pt_update(virt, mfn, nr_mfns, flags);
 }
 
+int destroy_xen_mappings(unsigned long s, unsigned long e)
+{
+    ASSERT(IS_ALIGNED(s, PAGE_SIZE));
+    ASSERT(IS_ALIGNED(e, PAGE_SIZE));
+
+    return (s < e) ? pt_update(s, INVALID_MFN, PFN_DOWN(e - s), 0) : -EINVAL;
+}
+
 int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns)
 {
     return pt_update(virt, INVALID_MFN, nr_mfns, PTE_POPULATE);
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 16:33:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 16:33:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859436.1271578 (Exim 4.92)
	(envelope-from )
	id 1tNaVJ-0001lp-Du; Tue, 17 Dec 2024 16:33:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859436.1271578; Tue, 17 Dec 2024 16:33: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 1tNaVJ-0001le-A3; Tue, 17 Dec 2024 16:33:01 +0000
Received: by outflank-mailman (input) for mailman id 859436;
 Tue, 17 Dec 2024 16:32: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 1tNaVH-0001JJ-TT
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 16:32:59 +0000
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com
 [2a00:1450:4864:20::234])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 93adbe3e-bc94-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 17:32:59 +0100 (CET)
Received: by mail-lj1-x234.google.com with SMTP id
 38308e7fff4ca-3035210e2d1so20865321fa.2
 for ; Tue, 17 Dec 2024 08:32:59 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-30344175b51sm13179021fa.69.2024.12.17.08.32.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 08:32: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: 93adbe3e-bc94-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734453178; x=1735057978; 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=fb3CJxLduaNMAXQ1eELP8V+rqebgsYEz60pn7CFsgqg=;
        b=FpKwOyoLUlok6FAxkP/E7fGiuzF4xcvNYVQTWA2M3mjUOfMxqxIx5FQcKdoeaK10nG
         pw8NdKG0Ut5W8FwpxuD3LnbX77sJIUXR/qPpziKSHJSMHNu5iF6sWJxORMMMyvWz+47l
         gTh9mvq9mavmynSK709DUlOalunRd2Mf7hIe9+rbzIVNJGcXn40zXm3oGoVAk0/VznXv
         KN/yUgivhOr1iXbN+0i7gy0BHzJFQPI9lDmubwRORQEGXETpPYPQQ/c9edLODbrUOS/K
         gSm/Oadwlxm9EQaOIsBgHx6ooPg4hhSIlHHA9TYl5VF6uXp3CdcBYhYYKrYNB1j95sNm
         nnyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734453178; x=1735057978;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=fb3CJxLduaNMAXQ1eELP8V+rqebgsYEz60pn7CFsgqg=;
        b=DM2TAIwkWbYkF7Erg9N6BMQPSVhQxvmwR7qnBQd73my+WDCuMtUjrY46HODHev8R05
         1oJ6cdo88sg09krLnYLspfxFCSBwDNCOSt1SLwGJb+H/u4qge5k76//ZCRXlF/JNImWE
         zedIwazmO1wsmMSKCNhd/Ma5C7h9ZZUXVHjnin8As5BI1CsRhqMqBuu06V+8ZU5qdydz
         zUhzXzcwuqywtwsT81b+sz4IFnEygyt2/E/6afXfbJztz89o7NRrjDUfNk3wInwTohGW
         kVsXig00EIQOqffZd3fePFkuruGXYnvxpfadaAqEqyNcGmii4jBNpUxIGE40Pfp07a1N
         pwMg==
X-Gm-Message-State: AOJu0YzMkqJ5iiy5QSb8jkAflY99H+COT2MB7OrD7xAOm9jbfxT3LPg3
	oCUzZ4HHwdLGVPDoMsgK30yQbAePPBR3ypwJFqbwxXaP/lW+MXvHveLY3fFe
X-Gm-Gg: ASbGncvq5WGljT/QKYjmB5fDcqrNUbpsvRJjDzFpJtPcFVkeyBA2V9keta6JdzGKT58
	Lr5YrZhv7thY/qt6022FsBSCl8zXCiQkPGgOonwgeRNeBxkcA2qTCUf+u/5lz5n2tNh4ezin4Le
	3S6zr502xv0W4+ZORkHdjPWu83R6Sa9V31OUHFKsU3Odcwn2mtRNfvNK2LSWRJLoswsVVosHAS+
	Co/pQiPZrM6EFFiZSVRMsVi0qUccW1+bVPN9FdtyvgJXIl2AzcvVobWkQ==
X-Google-Smtp-Source: AGHT+IE5d9AkQfD6oIrO10jKiy/DOZJAEQJQmmnmR31lI2oVKyWg+aeEH48bwisUyNXtC+DtvXhYUQ==
X-Received: by 2002:a2e:bc12:0:b0:300:1f12:bbc9 with SMTP id 38308e7fff4ca-302544cbdb2mr65416671fa.34.1734453177798;
        Tue, 17 Dec 2024 08:32:57 -0800 (PST)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 3/7] xen/riscv: reorder includes in asm/page.h alphabetically
Date: Tue, 17 Dec 2024 17:32:47 +0100
Message-ID: <467649699e9ae70fa1d933d7d44ab24e97f7ecb8.1734452721.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V3:
 - Nothing changed. Only rebase.
---
Changes in V2:
 - Add Acked-by: Jan Beulich 
---
 xen/arch/riscv/include/asm/page.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index 91b1194b55..bf3f75e85d 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -5,8 +5,8 @@
 
 #ifndef __ASSEMBLY__
 
-#include 
 #include 
+#include 
 #include 
 
 #include 
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 16:33:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 16:33:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859434.1271557 (Exim 4.92)
	(envelope-from )
	id 1tNaVI-0001JR-0G; Tue, 17 Dec 2024 16:33:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859434.1271557; Tue, 17 Dec 2024 16:32:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNaVH-0001JK-Sm; Tue, 17 Dec 2024 16:32:59 +0000
Received: by outflank-mailman (input) for mailman id 859434;
 Tue, 17 Dec 2024 16:32: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 1tNaVG-0001J8-EZ
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 16:32:58 +0000
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com
 [2a00:1450:4864:20::22d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9235cb1a-bc94-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 17:32:56 +0100 (CET)
Received: by mail-lj1-x22d.google.com with SMTP id
 38308e7fff4ca-3022484d4e4so62054671fa.1
 for ; Tue, 17 Dec 2024 08:32:56 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-30344175b51sm13179021fa.69.2024.12.17.08.32.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 08:32: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: 9235cb1a-bc94-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734453175; x=1735057975; 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=qQ1Jpu2IsZiWCTua2C+dL8+BptfxS3kI/G4frKryoZc=;
        b=Am0KGd9Cm6NIfg+bWEZ9TVF7FhHduG/oZvM9ZgRMqhZA9aXmDIx1IzUT0KFhXq8XaI
         HqFL/1+GZ7m4P3+q4SIfdLx7ldvNEN3FEXMn8W1+IdeKK9zFT91qYFx5BljLjLBr5QF7
         Vhkys3fTe/SC7R1ESFRMb09uY/aRHk+zvmOSWaHp+5FeTAHWwMVdTKYQIyAZ/WCXdJ3+
         k90DZJiqgGBZHYoaOl/BQ8VvW7s+TnfgkABZalrHuItPtY6d7kRZo299c4zah3ZDTl1c
         sh2k1TysdblaSH7vLlJoXP/wtuWz+c5SQdyMUse5AQJe6EZ9Osq/mdXechBHViF19Mtc
         0Nag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734453175; x=1735057975;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=qQ1Jpu2IsZiWCTua2C+dL8+BptfxS3kI/G4frKryoZc=;
        b=k5io1p0DKEHx2uYDQjlyhVhf+DjRFq05jVGNTprzeYmCSdARL1kdYr+ZETLOcSWVRj
         BzX1uQSJqJ/MQVkuHR3yojpEOu7xLR/6aCz8Y4adnYmI8lMMPmCD2+5lbvtD2kawRKij
         lxC1IN1nS3j8f+jn8a7xUhRRfdKI0D9rEaADHSAv1BCOHdZT+sKxu43vrDEqCeIVGcQ6
         TGYQ25OUWhHpKYUlKybQplVeI/1PO3ZeERGJH6TaLxr5mX3QOAlQKl2X/pj09fBsD/vX
         eDgp3kfnAnBpjBs/D5a9WKFxDyuTVXB8+yY1VT58N6Lwhi5W7Z5EQx61aZ3OZMsqLLgi
         /Acg==
X-Gm-Message-State: AOJu0Yw4TWWTkzNrb35SbuuUlzAyQDZ6eWoZVUi2P5w4LIQwK409PJAK
	PTpecjoSILtXkdwD58awmFCl/wMB/oXBUT3xTjTX8zMmC8kMetObtszVn/3a
X-Gm-Gg: ASbGncsgK3Zb9+7M2UotSiGJFi3UHezwYxKnLLWkiXfVO5+3FOK3uGT87k3izybQnjq
	fjpprTfUYvMg0kcNLkpsNyoCmHDWFwpW/SIa8qXdANV/j76/N/gB2e+XqZ2CYtWLHG8Ew7be5/b
	29Kr2anCTb7Z9QCBPX0gqgO1+QrM+ZdBxGnkjyGjssGyuLe1gmY1FftZmzNwWTVarT23xD4K/Hs
	vF49Z/V2EJ8C+0kLi34Gn+IUhU+7nkuTSJwjwphR4o1tBZdro1/62O1rQ==
X-Google-Smtp-Source: AGHT+IEx5mKuaTIp0f/NUxy7CGoF69F5ttJGVEhyTkjyv6+W8SbcosR4ZgQ94kddHWDk890ezpHxUw==
X-Received: by 2002:a2e:a781:0:b0:300:377d:2c36 with SMTP id 38308e7fff4ca-30443580621mr13670581fa.40.1734453174885;
        Tue, 17 Dec 2024 08:32:54 -0800 (PST)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 0/7] Unflattening and relocation of host device tree
Date: Tue, 17 Dec 2024 17:32:44 +0100
Message-ID: 
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The current patch series introduces the relocation of the host device tree file
to free up low memory and also it is expected that discard_initial_modules()
will be called sooner or later, it will discard the FDT boot module,
and remove_early_mappings() will destroy the early mappings.

In addition to relocation, unflattening is introduced to create the tree of
struct device_node for the host device tree.

To implement this, several things have been introduced:
 - destroy_xen_mappings() function, which removes page mappings from Xen's
   page tables. This is necessary for clear_fixmap().
 - {set,clear}_fixmap() functions to manage mappings in the fixmap region,
   which are expected to be used in copy_from_paddr() to copy the FDT to Xen's
   heap.
 - Introduce new config CONFIG_QEMU which is going to be used to cover changes
   connected to QEMU virtual board. It will be used during introduction of stubs
   for clean_and_invalidate_dcache_va_range() and clean_dcache_va_range(),
   which are expected to be used in copy_from_paddr() and flush_page_to_ram(),
   which in turn are expected to be used during the call to xvmalloc_array() in
   relocate_fdt().
   In case of QEMU cached related functions are implemented as returning 0 as
   QEMU doesn't model cache ( and so CMO extensions ). For others cases, it is
   introduced as -ENOSUPP as h/w could support CMO extension ( or hardware
   specific insertions ) and it will need to update implementation of the
   mentioned functions.
 - The introduction of copy_from_paddr() to copy the FDT to an address
   allocated in Xen's heap.

---
Changes in v3:
 - Add some Acks for the patches. All the patches are Acked except:
     [PATCH v3 1/7] xen/riscv: update layout table in config.h
     [PATCH v3 5/7] xen/riscv: implement data and instruction cache operations
 - Other changes please look at the specific patch.
---
Changes in v2:
 - Update the cover letter.
 - Introduce new patch with aligning of upper bounds in the layout table in
   config.h with the definitions below which are inclusive.
 - Other changes please look at the specific patch.
---

Oleksii Kurochko (7):
  xen/riscv: update layout table in config.h
  xen/riscv: add destroy_xen_mappings() to remove mappings in Xen page
    tables
  xen/riscv: reorder includes in asm/page.h alphabetically
  xen/riscv: add {set,clear}_fixmap() functions for managing fixmap
    entries
  xen/riscv: implement data and instruction cache operations
  xen/riscv: implement prereq for DTB relocation
  xen/riscv: relocating and unflattening host device tree

 xen/arch/riscv/Kconfig                  |  2 +
 xen/arch/riscv/configs/tiny64_defconfig |  1 +
 xen/arch/riscv/include/asm/config.h     | 12 +++---
 xen/arch/riscv/include/asm/fixmap.h     |  5 +++
 xen/arch/riscv/include/asm/mm.h         |  8 +++-
 xen/arch/riscv/include/asm/page.h       | 36 ++++++++++++++--
 xen/arch/riscv/include/asm/setup.h      |  4 ++
 xen/arch/riscv/mm.c                     |  6 ---
 xen/arch/riscv/platforms/Kconfig        |  5 +++
 xen/arch/riscv/pt.c                     | 24 +++++++++++
 xen/arch/riscv/setup.c                  | 57 ++++++++++++++++++++++++-
 11 files changed, 140 insertions(+), 20 deletions(-)
 create mode 100644 xen/arch/riscv/platforms/Kconfig

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 16:33:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 16:33:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859439.1271604 (Exim 4.92)
	(envelope-from )
	id 1tNaVM-0002LJ-Dt; Tue, 17 Dec 2024 16:33:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859439.1271604; Tue, 17 Dec 2024 16:33:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNaVM-0002K9-5u; Tue, 17 Dec 2024 16:33:04 +0000
Received: by outflank-mailman (input) for mailman id 859439;
 Tue, 17 Dec 2024 16:33: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 1tNaVK-0001JJ-Ry
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 16:33:02 +0000
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com
 [2a00:1450:4864:20::12d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 955e1109-bc94-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 17:33:02 +0100 (CET)
Received: by mail-lf1-x12d.google.com with SMTP id
 2adb3069b0e04-54025432becso5484100e87.1
 for ; Tue, 17 Dec 2024 08:33:02 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-30344175b51sm13179021fa.69.2024.12.17.08.32.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 08:32: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: 955e1109-bc94-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734453181; x=1735057981; 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=tDLe4QiaYJ6sYZAezMpOMgRYt5MBs/UEumukv4Av87A=;
        b=Ma/d7+UC8b5gzgfCxlP1Cf+kOEJ38lA8liQQ8ZOtzlH4I36o3M0P5WniV63dM5yx5i
         iRomXI3znVfE+fV1hFgk4N+X8X7swbdstXqZuc4aVNAE5fKQn0YA8BcvKHW0FmPRmmi9
         X8dX9nnGZqSXNM4f6S/6F3wrlaZ12rZv5qgHGDZGHgxj1PSvDLDK5ctCvxJl0n4cEW5V
         mFkX8Hv8M9qUdj0F6gaiyFTT6f00hSSMvO1x4ypNMMOPBp58rY+ch0rVgPTgKeFg/xzQ
         02Q4+aVfiYz+9LDl2QopLsD7vXJJXQFV98860L4rhsnaouFOpionb0nRMcljHS7MfFt8
         RVrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734453181; x=1735057981;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=tDLe4QiaYJ6sYZAezMpOMgRYt5MBs/UEumukv4Av87A=;
        b=QuRcUbGBaUKUPxAxI59dhyBQiv7cNhuv/K8+3+H/Xx11Lux5qdxEwUnfjUatSWgVH1
         ojMFIW4UwH3wlUcqNxs4vMHrWJ3chDoFMOBZHkyle61f2ncBqPGeMFeDVuDv3rh5L9bN
         cWTwYm5c951Y6tSIF/3E6u5xbMBhh2P52sk6UcY5mJ7Wyv07cUruoWaH0+afr0NuYEAT
         bB7SuhYktHUXWZgVe/TAbXfMVZco1KKjQ9TjDFJjXYM0J8rvWdb4oltv/iRnZbXV8Yrz
         vdv8Zx+X/hni+WWRRZ+0sDzX6NGUZolZsras9fO/PGG5ni7UWOdjgdSYgxOXu478/bZY
         RSsw==
X-Gm-Message-State: AOJu0Yxr1kTsRRQS3KLT+ZX03wANc7kKgpXOkQEXEAHmwU3jWlgRQPHZ
	YMF4X7QLBEhjkuMunz+YrXbCg0NTiucMBvZ/Jorvl+NQKw3dk34Y+/W5GgHZ
X-Gm-Gg: ASbGncs8w8YwU0MdMkNavGZKYeqg+1JqpVbOtzE+0S2QDVtuoXBgmA9280RRC1Jrcxw
	qYR+hJaL+rfsdf9aqppc/0dYy7JzWLyzXVtUd/RKm4SjeQ6tChKucANsCJqzJW/OY+zkY1pfeI7
	BZSpwC4g/CdssGQDzq19jjsMbpiA7EfDHKAy9LGnIkQY7hc8L9valuqOjD76cDZRsaQVDHY0inE
	0X1ySrjAeN0hHve3eFQgO1kM7ARUCO470+XUi5QWNNMnWNkQKVwz5ipbw==
X-Google-Smtp-Source: AGHT+IEPdci0ZNKck0TR0jo+A9MEoe5I81wJpKKE3dfSNwXYi/lMMdJyaI+LG2wOlwpsvEuylqdVjA==
X-Received: by 2002:a05:6512:3b26:b0:53e:350a:72a0 with SMTP id 2adb3069b0e04-54099b69aabmr6290771e87.51.1734453180798;
        Tue, 17 Dec 2024 08:33:00 -0800 (PST)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 5/7] xen/riscv: implement data and instruction cache operations
Date: Tue, 17 Dec 2024 17:32:49 +0100
Message-ID: <33cf536f15356db894be5bde557060585cc2e410.1734452721.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Implement following cache operations:
- clean_and_invalidate_dcache_va_range()
- clean_dcache_va_range()
- invalidate_icache()

The first two functions may require support for the CMO (Cache Management
Operations) extension and/or hardware-specific instructions.
Currently, only QEMU is supported, which does not model cache behavior.
Therefore, clean_and_invalidate_dcache_va_range() and clean_dcache_va_range()
are implemented to simply return 0. For other cases, generate compilation error
so a user won't miss to update this function if necessery.
If hardware supports CMO or hardware-specific instructions, these functions
should be updated accordingly. To support current implementation of these
function CONFIG_QEMU_PLATFORM is introduced.

invalidate_icache() is implemented using fence.i instruction as
mentioned in the unpriv spec:
  The FENCE.I instruction was designed to support a wide variety of
  implementations. A simple implementation can flush the local instruction
  cache and the instruction pipeline when the FENCE.I is executed.
  A more complex implementation might snoop the instruction (data) cache
  on every data (instruction) cache miss, or use an inclusive unified
  private L2 cache to invalidate lines from the primary instruction cache
  when they are being written by a local store instruction.
  If instruction and data caches are kept coherent in this way, or if the
  memory system consists of only uncached RAMs, then just the fetch pipeline
  needs to be flushed at a FENCE.I.
The FENCE.I instruction requires the presence of the Zifencei extension,
which might not always be available. However, Xen uses the RV64G ISA, which
guarantees the presence of the Zifencei extension. According to the
unprivileged ISA specification (version 20240411):
  One goal of the RISC-V project is that it be used as a stable software
  development target. For this purpose, we define a combination of a base ISA
  (RV32I or RV64I) plus selected standard extensions (IMAFD, Zicsr, Zifencei)
  as a "general-purpose" ISA, and we use the abbreviation G for the
  IMAFDZicsr_Zifencei combination of instruction-set extensions.

Set CONFIG_QEMU_PLATFORM=y in tiny64_defconfig to have proper implemtation of
clean_and_invalidate_dcache_va_range() and clean_dcache_va_range() for CI.

Signed-off-by: Oleksii Kurochko 
---
Changes in V3:
 - Updates for config QEMU:
   - Rename CONFIG_QEMU to CONFIG_QEMU_PLATFORM.
   - Drop "depends on RISCV_64" property for Config QEMU_PLATFORM.
   - Split help string.
 - Update implementation of the functions: clean_and_invalidate_dcache_va_range()
   and clean_dcache_va_range().
 - Minimal code style fixes: move second argument of clean_and_invalidate_dcache_va_range()
   to next line.
 - Update the commit message.
---
Changes in V2:
 - Update the commit message and subject:
   - drop information about HAS_CMO;
   - add information about Zifencei extension;
 - Introdce platforms directory and CONFIG_QEMU; update implementation of
   data/instruction cache operations as returning 0 for CONFIG_QEMU and for
   others - return -ENOTSUPP.
 - Drop HAS_CMO config.
---
 xen/arch/riscv/Kconfig                  |  2 ++
 xen/arch/riscv/configs/tiny64_defconfig |  1 +
 xen/arch/riscv/include/asm/page.h       | 22 +++++++++++++++++++++-
 xen/arch/riscv/platforms/Kconfig        |  5 +++++
 4 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/riscv/platforms/Kconfig

diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
index 1858004676..00f329054c 100644
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -52,6 +52,8 @@ config RISCV_ISA_C
 
 endmenu
 
+source "arch/riscv/platforms/Kconfig"
+
 source "common/Kconfig"
 
 source "drivers/Kconfig"
diff --git a/xen/arch/riscv/configs/tiny64_defconfig b/xen/arch/riscv/configs/tiny64_defconfig
index fc7a04872f..6af563bd73 100644
--- a/xen/arch/riscv/configs/tiny64_defconfig
+++ b/xen/arch/riscv/configs/tiny64_defconfig
@@ -10,3 +10,4 @@ CONFIG_RISCV_64=y
 CONFIG_DEBUG=y
 CONFIG_DEBUG_INFO=y
 CONFIG_EXPERT=y
+CONFIG_QEMU_PLATFORM=y
diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index bf3f75e85d..c82432dc67 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -148,9 +149,28 @@ static inline bool pte_is_mapping(pte_t p)
     return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK);
 }
 
+static inline int clean_and_invalidate_dcache_va_range(const void *p,
+                                                       unsigned long size)
+{
+#ifndef CONFIG_QEMU_PLATFORM
+    #error "should clean_and_invalidate_dcache_va_range() be updated?"
+#endif
+
+    return 0;
+}
+
+static inline int clean_dcache_va_range(const void *p, unsigned long size)
+{
+#ifndef CONFIG_QEMU_PLATFORM
+    #error "should clean_dcache_va_range() be updated?"
+#endif
+
+    return 0;
+}
+
 static inline void invalidate_icache(void)
 {
-    BUG_ON("unimplemented");
+    asm volatile ( "fence.i" ::: "memory" );
 }
 
 #define clear_page(page) memset((void *)(page), 0, PAGE_SIZE)
diff --git a/xen/arch/riscv/platforms/Kconfig b/xen/arch/riscv/platforms/Kconfig
new file mode 100644
index 0000000000..710423a59a
--- /dev/null
+++ b/xen/arch/riscv/platforms/Kconfig
@@ -0,0 +1,5 @@
+config QEMU_PLATFORM
+	bool "QEMU based platform support"
+	help
+	  Enable all the required drivers for QEMU riscv64
+	  virt emulated machine.
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 16:33:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 16:33:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859440.1271609 (Exim 4.92)
	(envelope-from )
	id 1tNaVM-0002Pr-Nl; Tue, 17 Dec 2024 16:33:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859440.1271609; Tue, 17 Dec 2024 16:33:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNaVM-0002Oh-Hx; Tue, 17 Dec 2024 16:33:04 +0000
Received: by outflank-mailman (input) for mailman id 859440;
 Tue, 17 Dec 2024 16:33: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 1tNaVL-0001JJ-SL
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 16:33:03 +0000
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com
 [2a00:1450:4864:20::22d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 95d0d1b0-bc94-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 17:33:02 +0100 (CET)
Received: by mail-lj1-x22d.google.com with SMTP id
 38308e7fff4ca-3003e203acaso52209231fa.1
 for ; Tue, 17 Dec 2024 08:33:02 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-30344175b51sm13179021fa.69.2024.12.17.08.33.00
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 08:33: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: 95d0d1b0-bc94-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734453182; x=1735057982; 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=8zJCydD52IvfuBY2R8KEd3EZvy2mjVloYZmx2VGVw6o=;
        b=fYCxt9PuTSXdm2ieCmnG7j8tTmCF+vL5P5UQYnz/TuejqawGQe4QKLE9/pSHAXkPdq
         dhOGFAGA9wTE2lYyxGXYrygA+qKgAT5orE5erkRJHosyLXPUs9DHx9IfQHrbRp0pLaLm
         rluM+SrD6LiLtB0Y8yaqqxG7U/P4dUCy6E04/HrECk0J3f3nF1dn5mPQACHZpvQACMQ2
         aWROD8hTsS9elOJe+iiG3mTauUPLrxfeW1+QKTDFBLsgGxPJEyomEejpD0uiYqcLAOq3
         OLBj+x1tG59alVcq9RpNpdem2guXi9VMqs8ghKYOmrFjMWQZLagxYGmA8ty0pHL4dUql
         GF4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734453182; x=1735057982;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=8zJCydD52IvfuBY2R8KEd3EZvy2mjVloYZmx2VGVw6o=;
        b=KAuVcuhJPPz3+v+DnZVeKJHU/AmtPRwbs2/BVHm60StR5HhAbInZgBOAihkyHos0F9
         TxAmZhUVaczvgX8DoIE0lZXfS0E0Jv9JxbLzV2bEyp1o6iCpepOrWbr2BhLtKW2QJ9GB
         Y//by6ozDmqLqEiArF9yRK9IN2orFs/k57Hk3nk2NT/oh1guv85LF+Zysh0FF4InGLOj
         Mru2KALbr88ZfQupZc6RWqeLxFC9/orQfjZ7ZRYH2dEfeFiL8QkoMQu0osU7RGrEzp27
         mkZUXmVsJLh5COrxYNoDWbTKmx973aG9UMx0t0SW4A2OTtZnOXC54RK89m2/+sLhXtfO
         VpzA==
X-Gm-Message-State: AOJu0Yw6K3U/Z1Q1Llkj0mKYls30FKECtP4XOPzrrU4DIqnA4zJMtokm
	t9iUT2cpqOb3sx6cUYRy7/44wAflNTx6jDkUzqAhLJqq8a+Afrt77ZjDFlLj
X-Gm-Gg: ASbGncvNZPUKPV0+gZt1YESqnAPHgQXjDDQNaIvVEAAafASannXXNzlSgKVhVfHiAUD
	6J9Hm3f9EbUIA6gQuX9HY1hzwDo+kIk4z4fIkE5FWV2ZtuCh1CYm0IINxduvq5yzBoveImLadI5
	4ymTtRsrJI5g8NEfQbJaBqjipTmnprhZhjrjESKPgWG0Uw6tKITeOtmL1vZHYLC/txE/QkNKQ+o
	5YRW1DL5X55dIbQCRsnTQuHP7iPjjQfrZfg5NfPwPr7WzMoZOURpGCqJQ==
X-Google-Smtp-Source: AGHT+IF/ywl5xmKCF/65QK9oCKKp8PnV+GsZVobG5aeoL61ppmef5h+bMXlo/IeRwhN0Kd+YKjaK8A==
X-Received: by 2002:a2e:a541:0:b0:300:15f1:cd5c with SMTP id 38308e7fff4ca-3044d063c32mr479601fa.17.1734453181771;
        Tue, 17 Dec 2024 08:33:01 -0800 (PST)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 6/7] xen/riscv: implement prereq for DTB relocation
Date: Tue, 17 Dec 2024 17:32:50 +0100
Message-ID: <79b7e0a4938e4be1f37d209ce01c859e5c208429.1734452721.git.oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

DTB relocatin in Xen heap requires the following functions which are
introduced in current patch:
- xvmalloc_array()
- copy_from_paddr()

For internal use of xvmalloc, the functions flush_page_to_ram() and
virt_to_page() are introduced. virt_to_page() is also required for
free_xenheap_pages().

Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V3:
 - Rewrite part of flush_page_to_ram() to use BUG() instead of BUG_ON().
 - Add Acked-by: Jan Beulich .
---
Changes in V2:
 - Drop variable directmap_virt_end.
 - Update ASSERT in virt_to_page() to use DIRECTMAP_VIRT_END instead of
   variable directmap_virt_end.
 - Declare local varibale v as const inside flush_page_to_ram().
 - Declare copy_from_paddr() in riscv/setup.h as in the future it will be
   used for copying kernel in guest memory.
 - Code style updates for copy_from_paddr().
 - Make l and s variable in copy_from_paddr() as the virables' initializers.
 - Drop call of clean_dcache_va_range(dst, l) in copy_from_paddr() as the
   necessiry of it is Arm-specific:
     After memcpy'ing the kernel in guest memory Arm need to flush the dcache
     to make sure that the data actually reaches the memory before we start
     executing guest code with caches disabled.
   RISC-V has caches always enabled thereby there is no such issue for RISC-V.
 - Make local variable src in copy_from_paddr() as const.
 - Update the commit message and subject: drop information of relocate_fdt()
   introduction and rename it to "prereq for DTB relocation".
 - Add BUG_ON() inside flush_page_to_ram() to check the return value of
   clean_and_invalidate_dcache_va_range().
 - Move relocate_fdt() introduction to the next patch to make this patch
   compilable.
---
 xen/arch/riscv/include/asm/mm.h    |  8 ++++++--
 xen/arch/riscv/include/asm/page.h  | 12 ++++++++++--
 xen/arch/riscv/include/asm/setup.h |  4 ++++
 xen/arch/riscv/setup.c             | 26 ++++++++++++++++++++++++++
 4 files changed, 46 insertions(+), 4 deletions(-)

diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 699ed23f0d..292aa48fc1 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -148,8 +149,11 @@ static inline void *page_to_virt(const struct page_info *pg)
 /* Convert between Xen-heap virtual addresses and page-info structures. */
 static inline struct page_info *virt_to_page(const void *v)
 {
-    BUG_ON("unimplemented");
-    return NULL;
+    unsigned long va = (unsigned long)v;
+
+    ASSERT((va >= DIRECTMAP_VIRT_START) && (va <= DIRECTMAP_VIRT_END));
+
+    return frametable_virt_start + PFN_DOWN(va - directmap_virt_start);
 }
 
 /*
diff --git a/xen/arch/riscv/include/asm/page.h b/xen/arch/riscv/include/asm/page.h
index c82432dc67..a1d54c7fb1 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -176,10 +177,17 @@ static inline void invalidate_icache(void)
 #define clear_page(page) memset((void *)(page), 0, PAGE_SIZE)
 #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
 
-/* TODO: Flush the dcache for an entire page. */
 static inline void flush_page_to_ram(unsigned long mfn, bool sync_icache)
 {
-    BUG_ON("unimplemented");
+    const void *v = map_domain_page(_mfn(mfn));
+
+    if ( clean_and_invalidate_dcache_va_range(v, PAGE_SIZE) )
+        BUG();
+
+    unmap_domain_page(v);
+
+    if ( sync_icache )
+        invalidate_icache();
 }
 
 /* Write a pagetable entry. */
diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/include/asm/setup.h
index 844a2f0ef1..c9d69cdf51 100644
--- a/xen/arch/riscv/include/asm/setup.h
+++ b/xen/arch/riscv/include/asm/setup.h
@@ -3,10 +3,14 @@
 #ifndef ASM__RISCV__SETUP_H
 #define ASM__RISCV__SETUP_H
 
+#include 
+
 #define max_init_domid (0)
 
 void setup_mm(void);
 
+void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
+
 #endif /* ASM__RISCV__SETUP_H */
 
 /*
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 9680332fee..bea3f27c4d 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -12,6 +12,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +27,31 @@ void arch_get_xen_caps(xen_capabilities_info_t *info)
 unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
     __aligned(STACK_SIZE);
 
+/**
+ * copy_from_paddr - copy data from a physical address
+ * @dst: destination virtual address
+ * @paddr: source physical address
+ * @len: length to copy
+ */
+void __init copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
+{
+    const void *src = (void *)FIXMAP_ADDR(FIX_MISC);
+
+    while ( len )
+    {
+        unsigned long s = paddr & (PAGE_SIZE - 1);
+        unsigned long l = min(PAGE_SIZE - s, len);
+
+        set_fixmap(FIX_MISC, maddr_to_mfn(paddr), PAGE_HYPERVISOR_RW);
+        memcpy(dst, src + s, l);
+        clear_fixmap(FIX_MISC);
+
+        paddr += l;
+        dst += l;
+        len -= l;
+    }
+}
+
 void __init noreturn start_xen(unsigned long bootcpu_id,
                                paddr_t dtb_addr)
 {
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 16:33:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 16:33:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859441.1271627 (Exim 4.92)
	(envelope-from )
	id 1tNaVO-00031Y-Jx; Tue, 17 Dec 2024 16:33:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859441.1271627; Tue, 17 Dec 2024 16:33: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 1tNaVO-0002zd-DY; Tue, 17 Dec 2024 16:33:06 +0000
Received: by outflank-mailman (input) for mailman id 859441;
 Tue, 17 Dec 2024 16:33: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 1tNaVN-0001J8-4v
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 16:33:05 +0000
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com
 [2a00:1450:4864:20::22a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 965f96c2-bc94-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 17:33:03 +0100 (CET)
Received: by mail-lj1-x22a.google.com with SMTP id
 38308e7fff4ca-3022598e213so53711771fa.0
 for ; Tue, 17 Dec 2024 08:33:03 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-30344175b51sm13179021fa.69.2024.12.17.08.33.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 08:33: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: 965f96c2-bc94-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734453183; x=1735057983; 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=nvts/S0YZI4SLhTFRZAtpUtbBID3pS74GNUhShT11II=;
        b=fl9vntodxbl3oqHHhQj73tke07P+h5m4Pjon9TPTe9juQ5KOny7ZvhK8sDciIqgW8g
         olml0Lf52im9WLNCyrDKQsxUQP+EictOakkiGwSC0yogBHko9veeALmrbrOD7mNKRuhC
         mj5SND6QKh9BlmK6jQxhopT/0kkV1jFhiP42iLPVCMsiUFg/Ea9BkdbHmzd2TLJoueGB
         54M5oBVs89EoZmIVhbVeygOqL11d992/1k5kM1SonOym3BPvMuxNG22ksr2pUeyir0YY
         aiQcEAS06RMnols1gKVHjBptLf5SGAc/tvEiC/cVsOhdyDjzFMHF3vuV9cMPA4yjegn/
         jUYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734453183; x=1735057983;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=nvts/S0YZI4SLhTFRZAtpUtbBID3pS74GNUhShT11II=;
        b=W5a99uS7SFxx2HuwWmoMfOSt6vh2QGhooEKwJBodFPmFC74gAO6axfj8vW9f8ngFES
         I5Erwtl/YwVIfC5jW17W+ymQrQxvIVEwcI/1KxndrcFX8Y6crnKi8tSJnpQuIbZaIP36
         jvqE2s9ljKPw8QZPUYVNA+YshCXzIwSPWLxA5tMlYEUxhIbegaUQxSYoSamcHWWePlac
         MXY/H8a79DqSRiwEIcQeGzfWQUe20H4kDgEi7P9BP/qmWoJRI/+PNaQEWlnE4Kp1kObV
         XwvqJNbtcrQGLU+p916Ol1DJYMTAMRebKkb/llZyLFQlmnRFX0ZO/nKPAVagG/5wQAFo
         I9qw==
X-Gm-Message-State: AOJu0YzZ5m4Q/fE4iKsh8xT9jJwx07D47aecpETPnDQaSHHXD54w9ZHk
	KpoxgcEJsBsG0eHEWekRRCc1b3rc4Cnh8bwUOaW13gLj7GdokwiWGiiFon+B
X-Gm-Gg: ASbGncudfFCTkI0hDhhqdDiXLwMO1Z6Zli/s6L/eVDKDlJ4ZLBhjJ0DjsvNFjKO6Gby
	jTDYg0M5x3weQ9PolTTrAfEVvWULR1OUaN+FmAiUfaxKc1P62/S58O1tSLByNIFOdrdQdMianTx
	D6R3awIQb48m095jGA5dEPPUhb3N/xPEydOW2P37M66zwkD6UVs3rWIn28/mmjMnWMCulEaVZis
	wisbvTlxn18vM01xvh2XG+EufzbpHiAqEneGsO/BIPujI0L9RyCjdh6PQ==
X-Google-Smtp-Source: AGHT+IGK3SASAd8pvE8rDMsmjQYwwLclRrQxWKa1slrklD1OqtzzYxJ/aPlDyDX1ouBW6UB4Szp3Kw==
X-Received: by 2002:a05:651c:212a:b0:304:4cac:d8f7 with SMTP id 38308e7fff4ca-3044cacdb1cmr1479351fa.13.1734453182815;
        Tue, 17 Dec 2024 08:33:02 -0800 (PST)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 7/7] xen/riscv: relocating and unflattening host device tree
Date: Tue, 17 Dec 2024 17:32:51 +0100
Message-ID: 
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Introduce relocate_fdt() and call it to relocate FDT to Xen heap
instead of using early mapping as it is expected that discard_initial_modules()
( is supposed to call in the future ) discards the FDT boot module and
remove_early_mappings() destroys the early mapping.

Unflatten a device tree, creating the tree of struct device_node.
It also fills the "name" and "type" pointers of the nodes so the normal
device-tree walking functions can be used.

Set device_tree_flattened to NULL in the case when acpi_disabled is
equal to false.

Signed-off-by: Oleksii Kurochko 
Acked-by: Jan Beulich 
---
Changes in V3:
 - Add Acked-by: Jan Beulich .
---
Changes in V2:
 - Move introduction of relocate_fdt() to the current patch with the following
   change:
    - use xvmalloc() instead of xmalloc_bytes() in relocate_fdt();
 - Drop the check of returned fdt_size from boot_fdt_info() to be in sync
   with Arm and boot_fdt_info() will panic anyway if something wrong with
   DTB.
 - Update the commit message.
---
 xen/arch/riscv/setup.c | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index bea3f27c4d..fb6bbba684 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -1,5 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
+#include 
 #include 
 #include 
 #include 
@@ -8,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -52,10 +54,24 @@ void __init copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
     }
 }
 
+/* Relocate the FDT in Xen heap */
+static void * __init relocate_fdt(paddr_t dtb_paddr, size_t dtb_size)
+{
+    void *fdt = xvmalloc_array(uint8_t, dtb_size);
+
+    if ( !fdt )
+        panic("Unable to allocate memory for relocating the Device-Tree.\n");
+
+    copy_from_paddr(fdt, dtb_paddr, dtb_size);
+
+    return fdt;
+}
+
 void __init noreturn start_xen(unsigned long bootcpu_id,
                                paddr_t dtb_addr)
 {
     const char *cmdline;
+    size_t fdt_size;
 
     remove_identity_mapping();
 
@@ -80,8 +96,7 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
                           _end - _start, false) )
         panic("Failed to add BOOTMOD_XEN\n");
 
-    if ( !boot_fdt_info(device_tree_flattened, dtb_addr) )
-        BUG();
+    fdt_size = boot_fdt_info(device_tree_flattened, dtb_addr);
 
     cmdline = boot_fdt_cmdline(device_tree_flattened);
     printk("Command line: %s\n", cmdline);
@@ -99,6 +114,18 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
      */
     system_state = SYS_STATE_boot;
 
+    if ( acpi_disabled )
+    {
+        printk("Booting using Device Tree\n");
+        device_tree_flattened = relocate_fdt(dtb_addr, fdt_size);
+        dt_unflatten_host_device_tree();
+    }
+    else
+    {
+        device_tree_flattened = NULL;
+        panic("Booting using ACPI isn't supported\n");
+    }
+
     printk("All set up\n");
 
     machine_halt();
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 16:36:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 16:36:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859492.1271638 (Exim 4.92)
	(envelope-from )
	id 1tNaYQ-0005ZA-4I; Tue, 17 Dec 2024 16:36:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859492.1271638; Tue, 17 Dec 2024 16:36: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 1tNaYQ-0005Z3-0s; Tue, 17 Dec 2024 16:36:14 +0000
Received: by outflank-mailman (input) for mailman id 859492;
 Tue, 17 Dec 2024 16:36: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 1tNaYP-0005Yv-0L
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 16:36:13 +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 05e811ef-bc95-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 17:36:10 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-4361d5dcf5bso60136265e9.3
 for ; Tue, 17 Dec 2024 08:36:10 -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-4363602c9d7sm122234165e9.16.2024.12.17.08.36.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 08:36:09 -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: 05e811ef-bc95-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734453370; x=1735058170; 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=JUGEkVyrqvqSF4KL5lb1zcyA71E+u6asaMgmp+ljBIE=;
        b=MVoXHqHT/VHwSNXF8IU4ouWrlT8gMyUJRuMqeMs5/M2BSAkq5yGDTr6zvHHlWPixy/
         1BjcI13jgzDybjss9kKHFoYn4XvgyipqNjkE98qynFhrY22pZ/v5PNunlNYY5Ry+a6Z1
         ebo45v2DIoxdkzFdnQSrlr4GFQLThi2mNW0rwbt33YjJn5x8mXQk/CMHnwjQ6XaYj4O1
         zGNc5QrgqXd1lu1tazBDdI2us2OjXAFW6+7Eord4mpZOUjBV6xLQb0AyPppuoRBqnka+
         MDW3T7z+ntlRDhTA/1XnX7h2TdKLj90sNAVV4n9vWl9ZY2RqCGWMksZSf7HYPdEjWgjj
         TbLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734453370; x=1735058170;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=JUGEkVyrqvqSF4KL5lb1zcyA71E+u6asaMgmp+ljBIE=;
        b=F2v8Ibej8KKEs73ceI0+EvffZVgAEptlxmHW5wmW8Thz/HWWTSxZHaBgamKxyZHfJc
         sKk4XHryOlcoQR7YTZ/m7/kPefKO/EVGu+THsIeCPf/dB79nSyOOaRqnKu4L09ebijuY
         P9oK76aHzqR2IU22ChIkPr+88AOwunfxXyKW3Z8gry5CCYAYA3ZE73OHkRJKlm/DqLzc
         Z27mIddyPelMu1Iq4CW+sCEWz30b1nnPqF09wvpS5qaAeAFbdS+/oBwHRL+Pa7Lw7tRM
         BUTOXWgoOB5h5EdDVXR9vccIp5ZcgHVW9GlZpPV7KMqp0vf2Fa61eXYJgmsh8LM2c/CX
         /2LA==
X-Forwarded-Encrypted: i=1; AJvYcCV08seUyOR1l3hhPlDHdj+QGIhQvNoCZM2YnhE3txgvckQ+Kxs3WlsaRLZqUXMyhOjgOJsgCWIpRpk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyOnZy5HpzHsHkYB+36HqI3UrUhcxbr5K5E7CIPmcjwRHtWjK/x
	YElT88E4yRzD3y4PEa0YWUrBdp2DWNzrPJDFyiu1AaqPM+4UprFY8xOAxMkpKg==
X-Gm-Gg: ASbGncuh03x+1jVUMVA+gFDVks1xbbfOMhNpAF4HjvdQtKj/rccXdr2KAqpiSe8YEJs
	1Zk6s2ecF01cnMN3AKA98Hjrkh7LMIu7w8d+7BEc/+sTiTE7k9WJvtLCYqj3UIoBi6S/nlFdTuH
	JFXM0ikqYiir4k66ooBB9T61ymI00VCYSxVsl+4RK3ZxpsdrPVpDxU6hbaRpmaURUmslDITpK+8
	fEk8gnMFmd1zSVBLWn+irzHDHC/GRxrZyXu98/PfE5ctOOtq8bEXzI4yZv4GRH7uBlfH8hcZ793
	GytddIlI4X0U4v9cioLhijOU7Raci8cjjsobGV/akg==
X-Google-Smtp-Source: AGHT+IGCnt9jTe2BOR8MnTpTMnQqxfmgG7pxkgcf+g+zJqEmiXXLrRXVIh3lhl48r9FRkTLhCquSjQ==
X-Received: by 2002:a05:600c:5029:b0:434:a815:2b5d with SMTP id 5b1f17b1804b1-4362aa93dc9mr137719375e9.24.1734453370218;
        Tue, 17 Dec 2024 08:36:10 -0800 (PST)
Message-ID: 
Date: Tue, 17 Dec 2024 17:36:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/7] Unflattening and relocation of host device tree
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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 17.12.2024 17:32, Oleksii Kurochko wrote:
> The current patch series introduces the relocation of the host device tree file
> to free up low memory and also it is expected that discard_initial_modules()
> will be called sooner or later, it will discard the FDT boot module,
> and remove_early_mappings() will destroy the early mappings.
> 
> In addition to relocation, unflattening is introduced to create the tree of
> struct device_node for the host device tree.
> 
> To implement this, several things have been introduced:
>  - destroy_xen_mappings() function, which removes page mappings from Xen's
>    page tables. This is necessary for clear_fixmap().
>  - {set,clear}_fixmap() functions to manage mappings in the fixmap region,
>    which are expected to be used in copy_from_paddr() to copy the FDT to Xen's
>    heap.
>  - Introduce new config CONFIG_QEMU which is going to be used to cover changes
>    connected to QEMU virtual board. It will be used during introduction of stubs
>    for clean_and_invalidate_dcache_va_range() and clean_dcache_va_range(),
>    which are expected to be used in copy_from_paddr() and flush_page_to_ram(),
>    which in turn are expected to be used during the call to xvmalloc_array() in
>    relocate_fdt().
>    In case of QEMU cached related functions are implemented as returning 0 as
>    QEMU doesn't model cache ( and so CMO extensions ). For others cases, it is
>    introduced as -ENOSUPP as h/w could support CMO extension ( or hardware
>    specific insertions ) and it will need to update implementation of the
>    mentioned functions.
>  - The introduction of copy_from_paddr() to copy the FDT to an address
>    allocated in Xen's heap.
> 
> ---
> Changes in v3:
>  - Add some Acks for the patches. All the patches are Acked except:
>      [PATCH v3 1/7] xen/riscv: update layout table in config.h
>      [PATCH v3 5/7] xen/riscv: implement data and instruction cache operations
>  - Other changes please look at the specific patch.
> ---
> Changes in v2:
>  - Update the cover letter.
>  - Introduce new patch with aligning of upper bounds in the layout table in
>    config.h with the definitions below which are inclusive.
>  - Other changes please look at the specific patch.
> ---
> 
> Oleksii Kurochko (7):
>   xen/riscv: update layout table in config.h
>   xen/riscv: add destroy_xen_mappings() to remove mappings in Xen page
>     tables
>   xen/riscv: reorder includes in asm/page.h alphabetically
>   xen/riscv: add {set,clear}_fixmap() functions for managing fixmap
>     entries

Please can you avoid re-posting patches that were already committed (the
latter three)?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 16:40:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 16:40:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859509.1271648 (Exim 4.92)
	(envelope-from )
	id 1tNacJ-0007DH-Lu; Tue, 17 Dec 2024 16:40:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859509.1271648; Tue, 17 Dec 2024 16:40:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNacJ-0007DA-J0; Tue, 17 Dec 2024 16:40:15 +0000
Received: by outflank-mailman (input) for mailman id 859509;
 Tue, 17 Dec 2024 16:40: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 1tNacH-0007D4-UO
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 16:40:13 +0000
Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com
 [2a00:1450:4864:20::343])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 960eafe6-bc95-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 17:40:12 +0100 (CET)
Received: by mail-wm1-x343.google.com with SMTP id
 5b1f17b1804b1-434b3e32e9dso60184845e9.2
 for ; Tue, 17 Dec 2024 08:40:12 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c806115asm11501922f8f.107.2024.12.17.08.40.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 08:40: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: 960eafe6-bc95-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734453612; x=1735058412; 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=+h5IHszmdCfJMa7GLGaIQ7wO/yzbbPzBB/DqRFfpn4Q=;
        b=PNKSIsDgheQZEEcrRF+rRS1scVBD1SsUcRf8WeNA4o/Ycgzod7S444x1SC4ePkNrTp
         AkZvPa/zgcqxhHdKDuGjcxmdtfeS/Ej0VAkBqmjl8HHSlmTJLuQtSZe0+0a6aYwb/Zrx
         E6jKZRoalz8RD6nKDVhB8AdRqAFKDTTNUCvvc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734453612; x=1735058412;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+h5IHszmdCfJMa7GLGaIQ7wO/yzbbPzBB/DqRFfpn4Q=;
        b=TDVAhqaucM8EsKTMtpAk2JPOmhdrpqtEDzyWfz9fyYCXqvjJZqA2tAcNr0fGFKz802
         1biXsAP61NbnjsbR8EQNzQP/0EcwlMA4yhQ+1Oik1n8qgJFq35s0+VYVAkZEBJ7ZdvvB
         P7+PEUfpyv1TgM9URK7X9+BKeTMUYP/Lj+t4w+GN/Ch/rnOQAs/f4r4eXGnAPNhcGhOC
         G6fjshnY4MfvakLH1iOI4Pu3yrJNfR8zjTOH4iCC6lB8+/BmuOXbhlh8RxykTvro69Se
         2JovGcC5tqcX74JOlf63rsS/KnvRW7yeh2rviOYB2DCtUUicBfaDl/PutM0GS0jW5+/e
         ixYA==
X-Forwarded-Encrypted: i=1; AJvYcCUAGi9Nl4AU9ytyNOVhRUlgN46YU3Ys5lGeMqZmah4lBXsbknwWiEw6azUJUGIOnObMMM15Xs79XUY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxEJ66e3L3wesJZasTbjwZbAbhLNqsL3phLlEVe61WzxlCPdES8
	xcedAum4pu3GcTWjQDgocmc/5r7a9xpQAgN+947iXKOYvPdAE38BRT3uy24/0vQ=
X-Gm-Gg: ASbGnctsTe3tr126lDO4bzhs7Pnrol2/aCkh0xWQ2Gq+xq9qg50K5N8FZF9rD7VYjYS
	Z1wQ688HtcL787/IQv8G6uRi6TZciHpERQsft30qfi9LlsTw2S5Gc5R8S81+hhBy/Z8Sk+DuZXh
	Nh2Cn699nceEgLqM+TSoPhZvO6G70yL3DYCaLzk0ucetM5AwQzOFKN1jmJGP1VNunMaRBVgWwTb
	T4rjsUSoWTZsygD9WPf+4fZ71M+O2g6s4OLT5txS6JsoYAX+QPRDFDK99Z7Mrszudfvb5TaAng2
	7HD6TTSL5dRwPlxKqsDW
X-Google-Smtp-Source: AGHT+IF/a8vsCCP6i5jBSOWNtlJm69++P7IWYOaxYwvgNgQ5Lizml7duMZpKUy12SjY85gqGbU1BEQ==
X-Received: by 2002:a05:600c:b95:b0:434:f218:e1a8 with SMTP id 5b1f17b1804b1-4362aa3d1d2mr140045925e9.19.1734453612122;
        Tue, 17 Dec 2024 08:40:12 -0800 (PST)
Message-ID: 
Date: Tue, 17 Dec 2024 16:40:11 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] eclair-analysis: Add usage of varargs extension for
 C99
To: Nicola Vetrini ,
 xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 Simone Ballarin ,
 Doug Goldstein 
References: 
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 17/12/2024 4:24 pm, Nicola Vetrini wrote:
> This extension name is missing from the current list of extension used
> by Xen, therefore is must be added to that configuration in order to
> avoid violations for MISRA C Rule 1.1.
>
> Signed-off-by: Nicola Vetrini 

Given CI is broken, I've put this in for testing:

https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1592826906

But, a question:

> ---
>  automation/eclair_analysis/ECLAIR/toolchain.ecl | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/automation/eclair_analysis/ECLAIR/toolchain.ecl b/automation/eclair_analysis/ECLAIR/toolchain.ecl
> index 86e9a79b5231..9b419e562afa 100644
> --- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
> +++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
> @@ -100,8 +100,8 @@
>      ext_enum_value_not_int: non-documented GCC extension.
>      ext_gnu_array_range: see Section \"6.29 Designated Initializers\" of "GCC_MANUAL".
>  "
> --config=STD.diag,behavior+={c99,GCC_ARM64,"^(ext_paste_comma|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_forward_ref_enum_def|ext_gnu_array_range)$"}
> --config=STD.diag,behavior+={c99,GCC_X86_64,"^(ext_paste_comma|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_flexible_array_in_struct|ext_flexible_array_in_array|ext_enum_value_not_int|ext_gnu_array_range)$"}
> +-config=STD.diag,behavior+={c99,GCC_ARM64,"^(ext_paste_comma|ext_c_missing_varargs_arg|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_forward_ref_enum_def|ext_gnu_array_range)$"}
> +-config=STD.diag,behavior+={c99,GCC_X86_64,"^(ext_paste_comma|ext_c_missing_varargs_arg|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_flexible_array_in_struct|ext_flexible_array_in_array|ext_enum_value_not_int|ext_gnu_array_range)$"}
>  -doc_end

We're adding ext_c_missing_varargs_arg to the list.  But there's also
ext_missing_varargs_arg.

What's the difference between the two?

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 16:40:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 16:40:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859510.1271658 (Exim 4.92)
	(envelope-from )
	id 1tNacQ-0007TS-Tg; Tue, 17 Dec 2024 16:40:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859510.1271658; Tue, 17 Dec 2024 16:40:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNacQ-0007TL-Qx; Tue, 17 Dec 2024 16:40:22 +0000
Received: by outflank-mailman (input) for mailman id 859510;
 Tue, 17 Dec 2024 16:40: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 1tNacP-0007Se-As
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 16:40:21 +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 9a03d5fc-bc95-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 17:40:19 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-43635796b48so22655155e9.0
 for ; Tue, 17 Dec 2024 08:40:19 -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-388c8016bdfsm11689929f8f.43.2024.12.17.08.40.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 08:40:18 -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: 9a03d5fc-bc95-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734453619; x=1735058419; 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=8b9qkerj1ruIrch9AF9tYMgh/cecoysqsxMEc+2yDlI=;
        b=VPTQU0Uwbe3uQffJVH9SwjI9h2RudUiV+6KIIquw2NS1+Q0qQUrjPUV4M0UXczts4t
         Eqd/+eNkrfBwGslDmZHqXu48ckZIfouKtUeO7355MPD3LIamv5dbPZg0aEIBzKwi2skd
         V2fYlJvqv65UMiz7ZUYmY73EIbQCIZk78OVxpoEMOC8wDjmzFStGxIIw379i7+aV7OIz
         2zMCdu9AO0gcFS0xZSDwt88pWesb76iqAuuYLO0XSVYGL5bbbFTVflNgsIvyenurANoh
         dZCuMECrqiubX4Fcy30/ol+9TujeYFBjVSIBck4FUjW328xdC5Qv/oxlm+w4H6mlKMHc
         ZF9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734453619; x=1735058419;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=8b9qkerj1ruIrch9AF9tYMgh/cecoysqsxMEc+2yDlI=;
        b=Qn2Xk3TbqOwF3v3T3ZmRDSflV8ejsAPkJcoOEToRjqc5fxX6bPyYIRlqANEP5nJ9uM
         ijyt8QxHpjV0TagyPGi3m5amICNoXXMs7vNkAjsC0A2aUeHPAvyqyCjRtLPSTNk0LR+5
         5EAhqRp98gLZHPNDd4DAkskxJEaYOg/OTWGWJKyasBVbFqI+UTJKya9EK0m5dlNQE0+u
         /3c3Srs2sEZCG6CLoZovTbhFK+vTA8Fpaz87hwcbPxsvrIsPPt13T5tBq6LPB0Gs/p3J
         QS1oha2lJNPJmf9j8OANICuIRE80uJPQwb7O8IBIHRcu/+w6QnxLfW9lVZM6Ljr6FEXK
         8e/A==
X-Forwarded-Encrypted: i=1; AJvYcCWChZ3WaoOcm9vmOU+sV5sjg6V0JMNEKSKpylDh69daViOHQUoyCf3zeTJA2hWb62p/L6kCQ2GezRk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy4BdRtA0iMarR/mcGNYsTy6C0j6VsvOKcVmeWVaYy6wKAtYeU8
	9WEuro/b1XuB4x1F7rStoblFqd6+5vDN9B4RstTYN6HTKKzInJYiHxHt8IZ8qw==
X-Gm-Gg: ASbGncvYsDqy4DoFA7eDCjyCitqHtDrquRqGsS0EmzxsjUzZr37UBrsUu8cOrz5jS7e
	3DiSpX2qeiuTN3+MRoEOykGtJ1amg4SXmekuROUKvkG7GhcxeDJt+vV5Dfmg+4xbbenq+Fm7Mqc
	1Rlse1kSq4htMfPtP2ZKic1b723qn0bJ2bkKdMV8QU6r4uAkaM4yyKE7076PfB7pGO9R5tOLT2g
	215rmdygAYVeRjrEQEZzWZCp6xMo2VH7mSTE8YJE3gyrFokrtGQiLjfTblMXqKxbooYLwzZ2x6N
	EHJf3+eODV8D7hopJnC8+1l/UxhOYOVDG2KZ7q05LQ==
X-Google-Smtp-Source: AGHT+IG6xgQgchLIoHEjDkZOrA4F/KplqVc9HWUxW9SVttr2AS0xNKXke0Gzhmmwf+RfTxUukG65Ew==
X-Received: by 2002:a05:600c:3c82:b0:42c:b8c9:16c8 with SMTP id 5b1f17b1804b1-4364817be68mr34382485e9.10.1734453618795;
        Tue, 17 Dec 2024 08:40:18 -0800 (PST)
Message-ID: 
Date: Tue, 17 Dec 2024 17:40:17 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] eclair-analysis: Add usage of varargs extension for
 C99
To: Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 Simone Ballarin ,
 Doug Goldstein ,
 Andrew Cooper3 , 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 17.12.2024 17:24, Nicola Vetrini wrote:
> This extension name is missing from the current list of extension used
> by Xen, therefore is must be added to that configuration in order to
> avoid violations for MISRA C Rule 1.1.

Which extension are we talking about here? I'm afraid ...

> --- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
> +++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
> @@ -100,8 +100,8 @@
>      ext_enum_value_not_int: non-documented GCC extension.
>      ext_gnu_array_range: see Section \"6.29 Designated Initializers\" of "GCC_MANUAL".
>  "
> --config=STD.diag,behavior+={c99,GCC_ARM64,"^(ext_paste_comma|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_forward_ref_enum_def|ext_gnu_array_range)$"}
> --config=STD.diag,behavior+={c99,GCC_X86_64,"^(ext_paste_comma|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_flexible_array_in_struct|ext_flexible_array_in_array|ext_enum_value_not_int|ext_gnu_array_range)$"}
> +-config=STD.diag,behavior+={c99,GCC_ARM64,"^(ext_paste_comma|ext_c_missing_varargs_arg|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_forward_ref_enum_def|ext_gnu_array_range)$"}
> +-config=STD.diag,behavior+={c99,GCC_X86_64,"^(ext_paste_comma|ext_c_missing_varargs_arg|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_flexible_array_in_struct|ext_flexible_array_in_array|ext_enum_value_not_int|ext_gnu_array_range)$"}
>  -doc_end

... ext_c_missing_varargs_arg doesn't tell me anything. Without this it's
hard to tell whether C-language-toolchain.rst might also need an edit; a
search for "varargs" in the file yields no hit.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 16:45:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 16:45:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859550.1271668 (Exim 4.92)
	(envelope-from )
	id 1tNahM-00013L-FQ; Tue, 17 Dec 2024 16:45:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859550.1271668; Tue, 17 Dec 2024 16:45: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 1tNahM-00013E-CP; Tue, 17 Dec 2024 16:45:28 +0000
Received: by outflank-mailman (input) for mailman id 859550;
 Tue, 17 Dec 2024 16:45: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 1tNahL-000138-D4
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 16:45:27 +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 50897f01-bc96-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 17:45:25 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-43634b570c1so27547895e9.0
 for ; Tue, 17 Dec 2024 08:45: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-436362c654asm120175705e9.37.2024.12.17.08.45.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 08:45: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: 50897f01-bc96-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734453925; x=1735058725; 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=KARgIs4hGluugSzQkm+g7woic7BzFqOEyx4oa2muXxo=;
        b=Bx7TWaR+GPbI6Hc/fQCPkfZRP45xbgXbicrQIaygo3dBJW1yLZ48EJhsyhrz+s604K
         6kAYhHwMYlD6rOFmGnu4J8SOw4bZwEFK+s+QJD5Y0yirl/YE8gIYns/QGck05wM8Pw+J
         Gyn0M2CS3dzIRNEVLMNQsp6Rf91Wrz0bCsXPs7GsZqVEyg4I5nmeO4J0L11/wV01at83
         7PW9IrmH88mUOdA6I3xvP/5JVp6bRL0Wd+OSzmdFqvyorKOHL8eX1Zj6vmc7lL+ERN//
         sNumzAkxCOy/jNnGxxjf111WjrnNW3GE1arDFI93CWLKW4DdYy1EL/5WuSpPC4VoHof7
         tz2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734453925; x=1735058725;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KARgIs4hGluugSzQkm+g7woic7BzFqOEyx4oa2muXxo=;
        b=WzaoJAuAKzrpudQjcpB0Pz+XE/0rdzlH96dw1mjoF7gFpPj+iKkZ7WtODSZmQQX6oi
         MhWNyAZT7mpa5lMGQiLxxn62rv3hmqbpTD/Vl1t9FQ/FnbuYD9WRWOE67/CZKwg6B/by
         SREdYRsor+lI+1DqJxMxMNuASle9/XyStojFubbaHak+yKsVHEg+6oBB+MeNNgn3kO5K
         ap229fCugNrtp48AJ10+GR/AFu/zyp2QoTTADenlVaRacL1hHSaVgBP3i+43rZRlPam4
         Qv20r3Ac2OU/0DxTikXg/JtbDZSuwBAL7z23bipSHEZnzqL7n+ncnLSELb0U+gufOHlh
         WAMg==
X-Forwarded-Encrypted: i=1; AJvYcCWciO9UfwxK2xmyqv8YqPfymNI+m4NATvbmTWpyYgQykFO7XvLVWV17IfXv54sSTiCvssjtYAD8Zm8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyZ2ZEXDEfPtwqkWevhDeae/wmHX252L0uHjjFggmRqyNBh6W2K
	tCk7aPY7lJW+K4OmWwIQVv7YrtOQFQjdue7h4CTGwbV5H6rwIgsqycQYU6jIMw==
X-Gm-Gg: ASbGncuF5Syj9hJss5nLQQMIsXRpQJIpWDh+vmTq4kZOUpkf6gVWvvinglYgXOXV4zH
	LjG+iJYkOJc2RJD7NpevQW9PfqkQKK2jjx+IYwTMbw3LtJthAGiPvAPYXygow7NfagGZiJpF6kk
	mc8p0dFte884zzqMHiAExEcRh2dYyUWhDntaKFvL5aZvY9xlhiRYJCaJvUBMEPxcYw8TVKUfLhs
	h4gZEwPsRC5Dkhgio3JGWOx6ZuKbIboJhOQ4Yode8L++TqT9bofq0PVfwT21ms5Hddv6UfrLnCU
	qkEjrKZWYioy5ajK71L0NwanUHX0ZspsPyT/tTBMAQ==
X-Google-Smtp-Source: AGHT+IGlC2R85c2pP0Wun4nZ80vV7yxO1ZYHf53H4kBBanlcLPQlVDrpUeCRe4fLULp59AIFv9F/yw==
X-Received: by 2002:a05:6000:156f:b0:385:e328:890a with SMTP id ffacd0b85a97d-3888e0c0520mr15397962f8f.49.1734453924961;
        Tue, 17 Dec 2024 08:45:24 -0800 (PST)
Message-ID: 
Date: Tue, 17 Dec 2024 17:45:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] eclair-analysis: Add usage of varargs extension for
 C99
To: Andrew Cooper ,
 Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 Simone Ballarin ,
 Doug Goldstein , 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 17.12.2024 17:40, Andrew Cooper wrote:
> On 17/12/2024 4:24 pm, Nicola Vetrini wrote:
>> This extension name is missing from the current list of extension used
>> by Xen, therefore is must be added to that configuration in order to
>> avoid violations for MISRA C Rule 1.1.
>>
>> Signed-off-by: Nicola Vetrini 
> 
> Given CI is broken, I've put this in for testing:
> 
> https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1592826906

If this was fixing an earlier commit, shouldn't it come with a Fixes: tag
anyway?

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 16:46:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 16:46:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859558.1271677 (Exim 4.92)
	(envelope-from )
	id 1tNaiH-0001a1-Nr; Tue, 17 Dec 2024 16:46:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859558.1271677; Tue, 17 Dec 2024 16:46: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 1tNaiH-0001Zu-LB; Tue, 17 Dec 2024 16:46:25 +0000
Received: by outflank-mailman (input) for mailman id 859558;
 Tue, 17 Dec 2024 16:46: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 1tNaiG-0001Zi-BF
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 16:46:24 +0000
Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com
 [2a00:1450:4864:20::341])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 726b196e-bc96-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 17:46:22 +0100 (CET)
Received: by mail-wm1-x341.google.com with SMTP id
 5b1f17b1804b1-4363dc916ceso16089895e9.0
 for ; Tue, 17 Dec 2024 08:46:22 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4363602c92csm122901245e9.15.2024.12.17.08.46.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 08:46: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: 726b196e-bc96-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734453982; x=1735058782; 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=IdGPcvFgwsVVkPk+FMas0OvqCO7S5xEsiFc1mcUlaNI=;
        b=v/PaD/4y/Soj8xBv3MfigHwTnMWBKRfgDE6TCBBFYK7//KRlGujZc4Td7a75+Pivy3
         GOYcbaKxjMpgYzn16iJcTPDNgmUPGnrT2NHmdAYXvLHzlPYdo5cDd0plWvC/l3/acBI7
         MXoLvdcGt7tlihTHGNVF2KSlThSH65Za+0Lfk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734453982; x=1735058782;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=IdGPcvFgwsVVkPk+FMas0OvqCO7S5xEsiFc1mcUlaNI=;
        b=PMKCmmkLtkmmVEz8GDc1Ahcy4did9PkO279kg2GDTzF3KZ7Y0hb7mLBxeoa+G+vf20
         KsHBa7pGI1HTrp8MozfPARsKcFMx0XKUiPFDKas8BJiEJoUIlz/pGI1gNyVV8XkDPtFy
         JIUHHxKFL3AwRBSHICWDLDwuGRlK6YjeRbpdnOyU120VuPiPBocBqAZuadZli2dnRv9x
         hMZ7F783yBBh6e3UdUpRBvV9NHI5/4QKbUlmW/cC0W/iBm4s+FrSsBbsLn12q+8Sm97J
         TAI+jr7/vS37/CqHmPb0ovdFGwgYP/iIR/SgNNebPXZuSwslbPoQWA7Ix/2RIk7OWKE+
         QL6g==
X-Forwarded-Encrypted: i=1; AJvYcCVOmEzVLTLEty8/opHwsqBXy6KfJDvNyjX2SmH0ap/Y6Nm5c+GBo3u/f2TPQkdyj6w0jNxNZjFYZvQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwfVB59CAuo63DkC9AOH0MRkm/uwjCIGOkpAA6Uy6tcbQtyw0aK
	G4PrqcqwxS8VcFL/vOipAq1MM1s6jZ6UuykLGly3Ox8f5YV2WTZm4dp0tnubk8w=
X-Gm-Gg: ASbGncuojOHpY9xgIFV4QPjT7m91R0RujVdTAoM05HkPmU5wvbtT561gVksZF86mB5E
	NqIXcUYfiBkNSCBFxFS0Gtx6KRGxQJLg8+EU7Kj+qOpPjOyN/y0hHRlmzZdE1Ddmp+KlCM5YzzI
	8Mt8sHMyarLwM33C/QWeZ2qqOTRFL1D4ZkIt3+fJdNa2Kzupyuqf4jB92ZAyi+IlpmTpGwDpDYz
	e/1Sek8flcE5rSfaKJTRxAHi/FkYoGMNwmVRVICiUng19oMd6Scir49s1+LYl9yRDGT9C22CbPL
	HT0l7M+4xanXEp+zcCmB
X-Google-Smtp-Source: AGHT+IGs0Dy670I+5I6M10PJSD4gvrDLEuGlkuCI1+1BGUEsgLsPUJmySRboAVwwAVp/x2hDtwd0qA==
X-Received: by 2002:a05:600c:1583:b0:434:e892:1033 with SMTP id 5b1f17b1804b1-4364812a08cmr35311475e9.2.1734453981871;
        Tue, 17 Dec 2024 08:46:21 -0800 (PST)
Message-ID: <8d59f2a1-8fc2-44d0-8c87-fbdf5bcc4d77@citrix.com>
Date: Tue, 17 Dec 2024 16:46:20 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] eclair-analysis: Add usage of varargs extension for
 C99
To: Jan Beulich ,
 Nicola Vetrini 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com,
 Simone Ballarin ,
 Doug Goldstein , xen-devel@lists.xenproject.org
References: 
 
 
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17/12/2024 4:45 pm, Jan Beulich wrote:
> On 17.12.2024 17:40, Andrew Cooper wrote:
>> On 17/12/2024 4:24 pm, Nicola Vetrini wrote:
>>> This extension name is missing from the current list of extension used
>>> by Xen, therefore is must be added to that configuration in order to
>>> avoid violations for MISRA C Rule 1.1.
>>>
>>> Signed-off-by: Nicola Vetrini 
>> Given CI is broken, I've put this in for testing:
>>
>> https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1592826906
> If this was fixing an earlier commit, shouldn't it come with a Fixes: tag
> anyway?

Yeah, it probably should have a Fixes, even if it is technically a
combined one with also changing the runner.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:06:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:06:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859577.1271728 (Exim 4.92)
	(envelope-from )
	id 1tNb20-00071M-Vw; Tue, 17 Dec 2024 17:06:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859577.1271728; Tue, 17 Dec 2024 17: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 1tNb20-0006zN-Ir; Tue, 17 Dec 2024 17:06:48 +0000
Received: by outflank-mailman (input) for mailman id 859577;
 Tue, 17 Dec 2024 17:06: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 1tNb1z-0006B0-Fj
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:06:47 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4c32b1cb-bc99-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 18:06:46 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-aa68b513abcso922175566b.0
 for ; Tue, 17 Dec 2024 09:06:46 -0800 (PST)
Received: from carlo-ubuntu.home.arpa
 (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab963910f7sm461362666b.166.2024.12.17.09.06.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 09:06: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: 4c32b1cb-bc99-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734455206; x=1735060006; 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=2S4/V5E4tJ5kPAHOqK5areTT6H+4uOWSSoM5Y54F91A=;
        b=kLKS3ZqO0+C1WxMX+JokFh0/ol3RC9DazhZAkAGkWH/AjZvjNZ8DQR3uB8dWDFB74q
         +6zAO2wjdZVJ4ntiko4f3jMUAkuaTvfnynCVMJnribqzfTcquNVibpm/bQtSU8+9osQX
         IATked7CPNzg5I9DrD7VYSiFWvCd1l5P1xYK7KVnNorNKQswR4aYYoOx+dvHw69VXwa1
         9H5Hqt900HtpjMW5yeOxkqRX5w8mBe0H3vfBezR2QLt3YUBwrm/67XKqw8gHYZt+ZTsR
         ebfwC9QlTJZm2f0AqVgJIeCKJm3DoNAmOINx+1vq6b5GY++2lcMAEU6pxaPKdDIhpWo6
         CVcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734455206; x=1735060006;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=2S4/V5E4tJ5kPAHOqK5areTT6H+4uOWSSoM5Y54F91A=;
        b=kO2uRMVnWEsDqBvolkhxDQCcunRtWWeIpxwefPqT4tE+YsK/VfMlV4hspEhIUvCWfl
         nFYr+l539i9P70d5yFx/Q+VofNKZH/4VrKNy/X1za8XLHavYqic/Ve1TSYChPFVgzjnp
         LnhoR4IvMxv6dimcoL74UJIzjvT6Y6RSlMrrEn3wn12rs0NDE4or6BB+fhP92CdGAhFX
         sirRJoMWW15VEr/mSHJE+J/MQlBeuX60HFWXeAecZO58P6BZvoAn6oSAcRRztluf2lTh
         EqzY6p9VjMFU+fmud3sAyNA4xPlSSnkYH6Au1pSvhEAy5w3aul2Dg7jDhzy9l1CWHt40
         jQcA==
X-Gm-Message-State: AOJu0YwdI3KJLcvCRcrmvzC+pBJBNUAHx/i//LtMnLnb7J4ty9gXtkDJ
	H09UxB8OySgjVrZEpsSIvaF+RoD1joyGFE9khaI9zMX9mu4T6x565rDLgNz7/LmafbR1cyu0B29
	5IWA=
X-Gm-Gg: ASbGncszokdC59ezyoXC24mr1IWK29wa2//izRkqn4m0XNyykpuNe7+egB4tzz5lepH
	/OcmWhC/oxM6O1/nR6GFwaPbtA1tgFOqS1N6JDbzm8Q+e3/XWBfMdSONn84e2xrbEV3bdgRNFuT
	aj9sMzUNFSrQe6pHn3f+xjD7Ti5ieNGerdIduAXaQhe+lMn44FggjJVRbHKvcI84Yb1NwWPS/ry
	ntqeiTsJDNRDdl+vidVGcfAKwZICGLYxT4kWgA57b7BbolEVD86xVzOqUFEr1SQA1TyhXDre3XM
	7Rtz8/Pn4YanqVNQzx6hjdCD0t9xztsVYp+w0P0DxlVJgPY1P9uBpWkom1g=
X-Google-Smtp-Source: AGHT+IExagnqRoh8QBrUeufotoNpy1yEQfm4ChjJPBuVBy8EYoooKITYLw1dG1jy7T5JMA1rOaQFgw==
X-Received: by 2002:a17:907:d15:b0:aa6:8f39:5c with SMTP id a640c23a62f3a-aab7792cff5mr2000325166b.17.1734455205778;
        Tue, 17 Dec 2024 09:06:45 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v13 05/12] xen: extend domctl interface for cache coloring
Date: Tue, 17 Dec 2024 18:06:30 +0100
Message-ID: <20241217170637.233097-6-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
References: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add a new domctl hypercall to allow the user to set LLC coloring
configurations. Colors can be set only once, just after domain creation,
since recoloring isn't supported.

Based on original work from: Luca Miccio 

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
Reviewed-by: Jan Beulich 
---
v13:
- no changes
v12:
- no changes
v11:
- minor changes
v10:
- fixed array type for colors parameter in check_colors()
v9:
- moved domain_llc_coloring_free() in next patch cause it's never used for dom0
v8:
- added bound check on dom0_num_colors
- default colors array set just once
v7:
- parse_color_config() doesn't accept leading/trailing commas anymore
- removed alloc_colors() helper
v6:
- moved domain_llc_coloring_free() in this patch
- removed domain_alloc_colors() in favor of a more explicit allocation
- parse_color_config() now accepts the size of the array to be filled
- allocate_memory() moved in another patch
v5:
- Carlo Nonato as the new author
- moved dom0 colors parsing (parse_colors()) in this patch
- added dom0_set_llc_colors() to set dom0 colors after creation
- moved color allocation and checking in this patch
- error handling when allocating color arrays
- FIXME: copy pasted allocate_memory() cause it got moved
v4:
- dom0 colors are dynamically allocated as for any other domain
  (colors are duplicated in dom0_colors and in the new array, but logic
  is simpler)
---
 xen/common/domain.c            |  3 ++
 xen/common/domctl.c            | 10 +++++++
 xen/common/llc-coloring.c      | 55 ++++++++++++++++++++++++++++++++--
 xen/include/public/domctl.h    |  9 ++++++
 xen/include/xen/llc-coloring.h |  5 ++++
 5 files changed, 79 insertions(+), 3 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index e33a0a5a21..0c4cc77111 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1303,6 +1304,8 @@ void domain_destroy(struct domain *d)
 {
     BUG_ON(!d->is_dying);
 
+    domain_llc_coloring_free(d);
+
     /* May be already destroyed, or get_domain() can race us. */
     if ( atomic_cmpxchg(&d->refcnt, 0, DOMAIN_DESTROYED) != 0 )
         return;
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 444e072fdc..05abb581a0 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -866,6 +867,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
                 __HYPERVISOR_domctl, "h", u_domctl);
         break;
 
+    case XEN_DOMCTL_set_llc_colors:
+        if ( op->u.set_llc_colors.pad )
+            ret = -EINVAL;
+        else if ( llc_coloring_enabled )
+            ret = domain_set_llc_colors(d, &op->u.set_llc_colors);
+        else
+            ret = -EOPNOTSUPP;
+        break;
+
     default:
         ret = arch_do_domctl(op, d, u_domctl);
         break;
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index 5984ae82e7..3dd1aaa4df 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -5,6 +5,7 @@
  * Copyright (C) 2024, Advanced Micro Devices, Inc.
  * Copyright (C) 2024, Minerva Systems SRL
  */
+#include 
 #include 
 #include 
 #include 
@@ -113,8 +114,7 @@ static void print_colors(const unsigned int colors[], unsigned int num_colors)
     printk(" }\n");
 }
 
-static bool __init check_colors(const unsigned int colors[],
-                                unsigned int num_colors)
+static bool check_colors(const unsigned int colors[], unsigned int num_colors)
 {
     unsigned int i;
 
@@ -196,7 +196,7 @@ void domain_dump_llc_colors(const struct domain *d)
     print_colors(d->llc_colors, d->num_llc_colors);
 }
 
-static void __init domain_set_default_colors(struct domain *d)
+static void domain_set_default_colors(struct domain *d)
 {
     printk(XENLOG_WARNING
            "LLC color config not found for %pd, using all colors\n", d);
@@ -233,6 +233,55 @@ int __init dom0_set_llc_colors(struct domain *d)
     return 0;
 }
 
+int domain_set_llc_colors(struct domain *d,
+                          const struct xen_domctl_set_llc_colors *config)
+{
+    unsigned int *colors;
+
+    if ( d->num_llc_colors )
+        return -EEXIST;
+
+    if ( !config->num_llc_colors )
+    {
+        domain_set_default_colors(d);
+        return 0;
+    }
+
+    if ( config->num_llc_colors > max_nr_colors )
+        return -EINVAL;
+
+    colors = xmalloc_array(unsigned int, config->num_llc_colors);
+    if ( !colors )
+        return -ENOMEM;
+
+    if ( copy_from_guest(colors, config->llc_colors, config->num_llc_colors) )
+    {
+        xfree(colors);
+        return -EFAULT;
+    }
+
+    if ( !check_colors(colors, config->num_llc_colors) )
+    {
+        printk(XENLOG_ERR "%pd: bad LLC color config\n", d);
+        xfree(colors);
+        return -EINVAL;
+    }
+
+    d->llc_colors = colors;
+    d->num_llc_colors = config->num_llc_colors;
+
+    return 0;
+}
+
+void domain_llc_coloring_free(struct domain *d)
+{
+    if ( !llc_coloring_enabled || d->llc_colors == default_colors )
+        return;
+
+    /* free pointer-to-const using __va(__pa()) */
+    xfree(__va(__pa(d->llc_colors)));
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 353f831e40..e2d392d1e5 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1236,6 +1236,13 @@ struct xen_domctl_dt_overlay {
 };
 #endif
 
+struct xen_domctl_set_llc_colors {
+    /* IN LLC coloring parameters */
+    uint32_t num_llc_colors;
+    uint32_t pad;
+    XEN_GUEST_HANDLE_64(uint32) llc_colors;
+};
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -1325,6 +1332,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_set_paging_mempool_size       86
 #define XEN_DOMCTL_dt_overlay                    87
 #define XEN_DOMCTL_gsi_permission                88
+#define XEN_DOMCTL_set_llc_colors                89
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -1391,6 +1399,7 @@ struct xen_domctl {
 #if defined(__arm__) || defined(__aarch64__)
         struct xen_domctl_dt_overlay        dt_overlay;
 #endif
+        struct xen_domctl_set_llc_colors    set_llc_colors;
         uint8_t                             pad[128];
     } u;
 };
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
index d29ebeb4c5..26353c808a 100644
--- a/xen/include/xen/llc-coloring.h
+++ b/xen/include/xen/llc-coloring.h
@@ -11,6 +11,7 @@
 #include 
 
 struct domain;
+struct xen_domctl_set_llc_colors;
 
 #ifdef CONFIG_LLC_COLORING
 extern bool llc_coloring_enabled;
@@ -18,17 +19,21 @@ extern bool llc_coloring_enabled;
 void llc_coloring_init(void);
 void dump_llc_coloring_info(void);
 void domain_dump_llc_colors(const struct domain *d);
+void domain_llc_coloring_free(struct domain *d);
 #else
 #define llc_coloring_enabled false
 
 static inline void llc_coloring_init(void) {}
 static inline void dump_llc_coloring_info(void) {}
 static inline void domain_dump_llc_colors(const struct domain *d) {}
+static inline void domain_llc_coloring_free(struct domain *d) {}
 #endif
 
 unsigned int get_llc_way_size(void);
 void arch_llc_coloring_init(void);
 int dom0_set_llc_colors(struct domain *d);
+int domain_set_llc_colors(struct domain *d,
+                          const struct xen_domctl_set_llc_colors *config);
 
 #endif /* __XEN_LLC_COLORING_H__ */
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:06:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:06:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859573.1271698 (Exim 4.92)
	(envelope-from )
	id 1tNb1x-0006PO-JT; Tue, 17 Dec 2024 17:06:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859573.1271698; Tue, 17 Dec 2024 17:06: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 1tNb1x-0006PH-GC; Tue, 17 Dec 2024 17:06:45 +0000
Received: by outflank-mailman (input) for mailman id 859573;
 Tue, 17 Dec 2024 17:06: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 1tNb1v-0006B0-Q1
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:06:43 +0000
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
 [2a00:1450:4864:20::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 49ce3bb5-bc99-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 18:06:42 +0100 (CET)
Received: by mail-ej1-x62c.google.com with SMTP id
 a640c23a62f3a-aa69077b93fso826752366b.0
 for ; Tue, 17 Dec 2024 09:06:42 -0800 (PST)
Received: from carlo-ubuntu.home.arpa
 (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab963910f7sm461362666b.166.2024.12.17.09.06.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 09:06: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: 49ce3bb5-bc99-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734455202; x=1735060002; 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=xHNrR+HjNxd8NEksH9lJNBl3N9ejsE80krMW4m0ypTg=;
        b=vZklG4MJM4w3WxvIQfu1K9qP1GNU2pR8c4zMTJ/CPp7LdPyTfb7tFJrbToU3M+Y036
         W4S1qEJXlmwSisQEBUn7Gtiycne8kKBOlIOTBhU/CXAet4dg90hMNOSFdcD1Sv0LDK8h
         kMWKuzjc1LsBW70xDZZJwBIpnB2LYqdbyfJfbbNSD4qiZjKW8LSKgjMrvRA7iMZKVys+
         waFvqg33LNjHgjXv6MkVefKeUmHMOvuS+aVnYv98lZQ8SNUSdZupC7kWxJGKEnW2oT+W
         l1uUHzpVDIZTgkjD3B+gH19gnI8Lo1cBNz89q3+3blrN7EQjUbEqBBQ4uYZngqLqQnS7
         8guQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734455202; x=1735060002;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=xHNrR+HjNxd8NEksH9lJNBl3N9ejsE80krMW4m0ypTg=;
        b=G+mvtAqImP06z6hkJ37cCkXLtV7xro95DY0LvhjltnVIJKzRukmzBDtwq7Pb6jYKvJ
         OT9IWwrvJCrGAcPbU+hqGjw8QoQwRHPA7eXIKfowHCKHeaW6RmYbX7asPJQ65MQ+Ytpn
         RAqvt0X27IR5Ds69IYMZvi1lB2Sm36655M2AyTzhn56OpecHgOKeeFnycB2cCGrZt6xM
         f155qIOg0jmrCLBKRMq+D3fRE/lJAMu6HLDaY8XD+qbVOV0Zc7hyqT+5/jkHcS8/EnZU
         dtmOKg9yCBvwWukhdXVP0HBfkTm188CNqeWGPKSk+2VYtM9TvQ/tKEtuVzxlkceinBps
         Bgxg==
X-Gm-Message-State: AOJu0YzzBVzkOG3+CN5Qjj4Z1MGOyyWPlT8m4+2Jx1lZ1K6RvN/O2qbk
	ksG2Dzhm84CHlHrTGAKZHHcLGm0SAtgejEaGp+/qYL/I5boeuqp4w9q0EVAI6nhVkr/7Ejv+8v5
	D//k=
X-Gm-Gg: ASbGnctIqmXi93vzKZoV5pOYi0rZu5JJR1fufo7T3pzh2uiWSO3Ixjq40e2ELqIwRKn
	VWft61KoJfM7yyZOztnkTCLZ/LEVF6KqctJ21WBP7NLuxP6b9Js2EoB4os4mAmUJZCZ78vZZZnb
	ea4wOo6lhxVuYhNiqyLpyXce00hiWn8nxsWo8cXGZUP4r1/rx/TFoBNObFM4GO3EXt1YwNO2R9M
	CMlnKBT1LBd+pxOYytxhy4zXARtGc9DAyPcdgTI+OX1Fz0o4M6tThZtpHUyi9ay+BDpqC0y4fKS
	0o0MiLXEZv7TwZ85bbLJHthizwrTghkLO4QmmeEWBUhcScRWVQnv0GWs5ng=
X-Google-Smtp-Source: AGHT+IGUs53RL/lkjj0WLexo2rboX2ZGZReEVmzmFyMksq9J60QIEuGrvJrV3cgmjA4pdLAJZWaX5g==
X-Received: by 2002:a17:906:709:b0:aab:dee6:a3a2 with SMTP id a640c23a62f3a-aabdee6a3femr317696166b.47.1734455201568;
        Tue, 17 Dec 2024 09:06:41 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v13 01/12] xen/common: add cache coloring common code
Date: Tue, 17 Dec 2024 18:06:26 +0100
Message-ID: <20241217170637.233097-2-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
References: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Last Level Cache (LLC) coloring allows to partition the cache in smaller
chunks called cache colors.

Since not all architectures can actually implement it, add a HAS_LLC_COLORING
Kconfig option.
LLC_COLORS_ORDER Kconfig option has a range maximum of 10 (2^10 = 1024)
because that's the number of colors that fit in a 4 KiB page when integers
are 4 bytes long.

LLC colors are a property of the domain, so struct domain has to be extended.

Based on original work from: Luca Miccio 

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
Acked-by: Michal Orzel 
---
v13:
- added note to cmdline docs for llc-nr-ways and llc-size shorthand precedence
v12:
- fixed build errors
- added opt_llc_coloring to improve readibility
- reverted llc_coloring_enabled type to bool
v11:
- __COLORING_H__ -> __XEN_LLC_COLORING_H__ in llc-coloring.h
- added SPDX tag to cache-coloring.rst
- llc-coloring=off now takes precedence over other cmdline options
- removed useless #includes
v10:
- fixed commit message to use LLC_COLORS_ORDER
- added documentation to index.rst
- moved check on CONFIG_NUMA in arch/arm/Kconfig (next patch)
- fixed copyright line
- fixed array type for colors parameter in print_colors()
- added check on (way_size & ~PAGE_MASK)
v9:
- dropped _MAX_ from CONFIG_MAX_LLC_COLORS_ORDER
v8:
- minor documentation fixes
- "llc-coloring=on" is inferred from "llc-nr-ways" and "llc-size" usage
- turned CONFIG_NR_LLC_COLORS to CONFIG_MAX_LLC_COLORS_ORDER, base-2 exponent
- moved Kconfig options to common/Kconfig
- don't crash if computed max_nr_colors is too large
v7:
- SUPPORT.md changes added to this patch
- extended documentation to better address applicability of cache coloring
- "llc-nr-ways" and "llc-size" params introduced in favor of "llc-way-size"
- moved dump_llc_coloring_info() call in 'm' keyhandler (pagealloc_info())
v6:
- moved almost all code in common
- moved documentation in this patch
- reintroduced range for CONFIG_NR_LLC_COLORS
- reintroduced some stub functions to reduce the number of checks on
  llc_coloring_enabled
- moved domain_llc_coloring_free() in same patch where allocation happens
- turned "d->llc_colors" to pointer-to-const
- llc_coloring_init() now returns void and panics if errors are found
v5:
- used - instead of _ for filenames
- removed domain_create_llc_colored()
- removed stub functions
- coloring domain fields are now #ifdef protected
v4:
- Kconfig options moved to xen/arch
- removed range for CONFIG_NR_LLC_COLORS
- added "llc_coloring_enabled" global to later implement the boot-time
  switch
- added domain_create_llc_colored() to be able to pass colors
- added is_domain_llc_colored() macro
---
 SUPPORT.md                        |   7 ++
 docs/index.rst                    |   1 +
 docs/misc/cache-coloring.rst      | 118 ++++++++++++++++++++++++++++
 docs/misc/xen-command-line.pandoc |  39 ++++++++++
 xen/common/Kconfig                |  21 +++++
 xen/common/Makefile               |   1 +
 xen/common/keyhandler.c           |   3 +
 xen/common/llc-coloring.c         | 124 ++++++++++++++++++++++++++++++
 xen/common/page_alloc.c           |   3 +
 xen/include/xen/llc-coloring.h    |  36 +++++++++
 xen/include/xen/sched.h           |   5 ++
 11 files changed, 358 insertions(+)
 create mode 100644 docs/misc/cache-coloring.rst
 create mode 100644 xen/common/llc-coloring.c
 create mode 100644 xen/include/xen/llc-coloring.h

diff --git a/SUPPORT.md b/SUPPORT.md
index 82239d0294..998faf5635 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -401,6 +401,13 @@ by maintaining multiple physical to machine (p2m) memory mappings.
     Status, x86 HVM: Tech Preview
     Status, ARM: Tech Preview
 
+### Cache coloring
+
+Allows to reserve Last Level Cache (LLC) partitions for Dom0, DomUs and Xen
+itself.
+
+    Status, Arm64: Experimental
+
 ## Resource Management
 
 ### CPU Pools
diff --git a/docs/index.rst b/docs/index.rst
index 1d44796d72..1bb8d02ea3 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -66,6 +66,7 @@ Documents in need of some rearranging.
    misc/xen-makefiles/makefiles
    misra/index
    fusa/index
+   misc/cache-coloring
 
 
 Miscellanea
diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
new file mode 100644
index 0000000000..371f21a0e7
--- /dev/null
+++ b/docs/misc/cache-coloring.rst
@@ -0,0 +1,118 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Xen cache coloring user guide
+=============================
+
+The cache coloring support in Xen allows to reserve Last Level Cache (LLC)
+partitions for Dom0, DomUs and Xen itself. Currently only ARM64 is supported.
+Cache coloring realizes per-set cache partitioning in software and is applicable
+to shared LLCs as implemented in Cortex-A53, Cortex-A72 and similar CPUs.
+
+To compile LLC coloring support set ``CONFIG_LLC_COLORING=y``.
+
+If needed, change the maximum number of colors with
+``CONFIG_LLC_COLORS_ORDER=``.
+
+Runtime configuration is done via `Command line parameters`_.
+
+Background
+**********
+
+Cache hierarchy of a modern multi-core CPU typically has first levels dedicated
+to each core (hence using multiple cache units), while the last level is shared
+among all of them. Such configuration implies that memory operations on one
+core (e.g. running a DomU) are able to generate interference on another core
+(e.g. hosting another DomU). Cache coloring realizes per-set cache-partitioning
+in software and mitigates this, guaranteeing more predictable performances for
+memory accesses.
+Software-based cache coloring is particularly useful in those situations where
+no hardware mechanisms (e.g., DSU-based way partitioning) are available to
+partition caches. This is the case for e.g., Cortex-A53, A57 and A72 CPUs that
+feature a L2 LLC cache shared among all cores.
+
+The key concept underlying cache coloring is a fragmentation of the memory
+space into a set of sub-spaces called colors that are mapped to disjoint cache
+partitions. Technically, the whole memory space is first divided into a number
+of subsequent regions. Then each region is in turn divided into a number of
+subsequent sub-colors. The generic i-th color is then obtained by all the
+i-th sub-colors in each region.
+
+::
+
+                            Region j            Region j+1
+                .....................   ............
+                .                     . .
+                .                       .
+            _ _ _______________ _ _____________________ _ _
+                |     |     |     |     |     |     |
+                | c_0 | c_1 |     | c_n | c_0 | c_1 |
+           _ _ _|_____|_____|_ _ _|_____|_____|_____|_ _ _
+                    :                       :
+                    :                       :...         ... .
+                    :                            color 0
+                    :...........................         ... .
+                                                :
+          . . ..................................:
+
+How colors are actually defined depends on the function that maps memory to
+cache lines. In case of physically-indexed, physically-tagged caches with linear
+mapping, the set index is found by extracting some contiguous bits from the
+physical address. This allows colors to be defined as shown in figure: they
+appear in memory as subsequent blocks of equal size and repeats themselves after
+``n`` different colors, where ``n`` is the total number of colors.
+
+If some kind of bit shuffling appears in the mapping function, then colors
+assume a different layout in memory. Those kind of caches aren't supported by
+the current implementation.
+
+**Note**: Finding the exact cache mapping function can be a really difficult
+task since it's not always documented in the CPU manual. As said Cortex-A53, A57
+and A72 are known to work with the current implementation.
+
+How to compute the number of colors
+###################################
+
+Given the linear mapping from physical memory to cache lines for granted, the
+number of available colors for a specific platform is computed using three
+parameters:
+
+- the size of the LLC.
+- the number of the LLC ways.
+- the page size used by Xen.
+
+The first two parameters can be found in the processor manual, while the third
+one is the minimum mapping granularity. Dividing the cache size by the number of
+its ways we obtain the size of a way. Dividing this number by the page size,
+the number of total cache colors is found. So for example an Arm Cortex-A53
+with a 16-ways associative 1 MiB LLC can isolate up to 16 colors when pages are
+4 KiB in size.
+
+Effective colors assignment
+###########################
+
+When assigning colors, if one wants to avoid cache interference between two
+domains, different colors needs to be used for their memory.
+
+Command line parameters
+***********************
+
+Specific documentation is available at `docs/misc/xen-command-line.pandoc`.
+
++----------------------+-------------------------------+
+| **Parameter**        | **Description**               |
++----------------------+-------------------------------+
+| ``llc-coloring``     | Enable coloring at runtime    |
++----------------------+-------------------------------+
+| ``llc-size``         | Set the LLC size              |
++----------------------+-------------------------------+
+| ``llc-nr-ways``      | Set the LLC number of ways    |
++----------------------+-------------------------------+
+
+Auto-probing of LLC specs
+#########################
+
+LLC size and number of ways are probed automatically by default.
+
+LLC specs can be manually set via the above command line parameters. This
+bypasses any auto-probing and it's used to overcome failing situations, such as
+flawed probing logic, or for debugging/testing purposes.
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 293dbc1a95..ca105ec559 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1708,6 +1708,45 @@ This option is intended for debugging purposes only.  Enable MSR_DEBUGCTL.LBR
 in hypervisor context to be able to dump the Last Interrupt/Exception To/From
 record with other registers.
 
+### llc-coloring (arm64)
+> `= `
+
+> Default: `false`
+
+Flag to enable or disable LLC coloring support at runtime. This option is
+available only when `CONFIG_LLC_COLORING` is enabled. See the general
+cache coloring documentation for more info.
+
+### llc-nr-ways (arm64)
+> `= `
+
+> Default: `Obtained from hardware`
+
+Specify the number of ways of the Last Level Cache. This option is available
+only when `CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are used
+to find the number of supported cache colors. By default the value is
+automatically computed by probing the hardware, but in case of specific needs,
+it can be manually set. Those include failing probing and debugging/testing
+purposes so that it's possible to emulate platforms with different number of
+supported colors. If set, also "llc-size" must be set, otherwise the default
+will be used. Note that using both options implies "llc-coloring=on" unless an
+earlier "llc-coloring=off" is there.
+
+### llc-size (arm64)
+> `= `
+
+> Default: `Obtained from hardware`
+
+Specify the size of the Last Level Cache. This option is available only when
+`CONFIG_LLC_COLORING` is enabled. LLC size and number of ways are used to find
+the number of supported cache colors. By default the value is automatically
+computed by probing the hardware, but in case of specific needs, it can be
+manually set. Those include failing probing and debugging/testing purposes so
+that it's possible to emulate platforms with different number of supported
+colors. If set, also "llc-nr-ways" must be set, otherwise the default will be
+used. Note that using both options implies "llc-coloring=on" unless an
+earlier "llc-coloring=off" is there.
+
 ### lock-depth-size
 > `= `
 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 90268d9249..b4ec6893be 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -71,6 +71,9 @@ config HAS_IOPORTS
 config HAS_KEXEC
 	bool
 
+config HAS_LLC_COLORING
+	bool
+
 config HAS_PIRQ
 	bool
 
@@ -516,4 +519,22 @@ config TRACEBUFFER
 	  to be collected at run time for debugging or performance analysis.
 	  Memory and execution overhead when not active is minimal.
 
+config LLC_COLORING
+	bool "Last Level Cache (LLC) coloring" if EXPERT
+	depends on HAS_LLC_COLORING
+
+config LLC_COLORS_ORDER
+	int "Maximum number of LLC colors (base-2 exponent)"
+	range 1 10
+	default 7
+	depends on LLC_COLORING
+	help
+	  Controls the build-time size of various arrays associated with LLC
+	  coloring. The value is a base-2 exponent. Refer to cache coloring
+	  documentation for how to compute the number of colors supported by the
+	  platform. This is only an upper bound. The runtime value is autocomputed
+	  or manually set via cmdline parameters.
+	  The default value corresponds to an 8 MiB 16-ways LLC, which should be
+	  more than what's needed in the general case.
+
 endmenu
diff --git a/xen/common/Makefile b/xen/common/Makefile
index b279b09bfb..cba3b32733 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -25,6 +25,7 @@ obj-y += keyhandler.o
 obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_KEXEC) += kimage.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
+obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
 obj-$(CONFIG_MEM_ACCESS) += mem_access.o
 obj-y += memory.o
 obj-y += multicall.o
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 6da291b34e..6ea54838d4 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -304,6 +305,8 @@ static void cf_check dump_domains(unsigned char key)
 
         arch_dump_domain_info(d);
 
+        domain_dump_llc_colors(d);
+
         rangeset_domain_printk(d);
 
         dump_pageframe_info(d);
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
new file mode 100644
index 0000000000..335a907296
--- /dev/null
+++ b/xen/common/llc-coloring.c
@@ -0,0 +1,124 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Last Level Cache (LLC) coloring common code
+ *
+ * Copyright (C) 2024, Advanced Micro Devices, Inc.
+ * Copyright (C) 2024, Minerva Systems SRL
+ */
+#include 
+#include 
+#include 
+
+#define NR_LLC_COLORS          (1U << CONFIG_LLC_COLORS_ORDER)
+
+/*
+ * -1: not specified (disabled unless llc-size and llc-nr-ways present)
+ *  0: explicitly disabled through cmdline
+ *  1: explicitly enabled through cmdline
+ */
+static int8_t __initdata opt_llc_coloring = -1;
+boolean_param("llc-coloring", opt_llc_coloring);
+
+static bool __ro_after_init llc_coloring_enabled;
+
+static unsigned int __initdata llc_size;
+size_param("llc-size", llc_size);
+static unsigned int __initdata llc_nr_ways;
+integer_param("llc-nr-ways", llc_nr_ways);
+/* Number of colors available in the LLC */
+static unsigned int __ro_after_init max_nr_colors;
+
+static void print_colors(const unsigned int colors[], unsigned int num_colors)
+{
+    unsigned int i;
+
+    printk("{ ");
+    for ( i = 0; i < num_colors; i++ )
+    {
+        unsigned int start = colors[i], end = start;
+
+        printk("%u", start);
+
+        for ( ; i < num_colors - 1 && end + 1 == colors[i + 1]; i++, end++ )
+            ;
+
+        if ( start != end )
+            printk("-%u", end);
+
+        if ( i < num_colors - 1 )
+            printk(", ");
+    }
+    printk(" }\n");
+}
+
+void __init llc_coloring_init(void)
+{
+    unsigned int way_size;
+
+    llc_coloring_enabled = (opt_llc_coloring >= 1);
+    if ( (opt_llc_coloring != 0) && llc_size && llc_nr_ways )
+    {
+        llc_coloring_enabled = true;
+        way_size = llc_size / llc_nr_ways;
+    }
+    else if ( !llc_coloring_enabled )
+        return;
+    else
+    {
+        way_size = get_llc_way_size();
+        if ( !way_size )
+            panic("LLC probing failed and 'llc-size' or 'llc-nr-ways' missing\n");
+    }
+
+    if ( way_size & ~PAGE_MASK )
+        panic("LLC way size must be a multiple of PAGE_SIZE\n");
+
+    /*
+     * The maximum number of colors must be a power of 2 in order to correctly
+     * map them to bits of an address.
+     */
+    max_nr_colors = way_size >> PAGE_SHIFT;
+
+    if ( max_nr_colors & (max_nr_colors - 1) )
+        panic("Number of LLC colors (%u) isn't a power of 2\n", max_nr_colors);
+
+    if ( max_nr_colors > NR_LLC_COLORS )
+    {
+        printk(XENLOG_WARNING
+               "Number of LLC colors (%u) too big. Using configured max %u\n",
+               max_nr_colors, NR_LLC_COLORS);
+        max_nr_colors = NR_LLC_COLORS;
+    }
+    else if ( max_nr_colors < 2 )
+        panic("Number of LLC colors %u < 2\n", max_nr_colors);
+
+    arch_llc_coloring_init();
+}
+
+void dump_llc_coloring_info(void)
+{
+    if ( !llc_coloring_enabled )
+        return;
+
+    printk("LLC coloring info:\n");
+    printk("    Number of LLC colors supported: %u\n", max_nr_colors);
+}
+
+void domain_dump_llc_colors(const struct domain *d)
+{
+    if ( !llc_coloring_enabled )
+        return;
+
+    printk("%u LLC colors: ", d->num_llc_colors);
+    print_colors(d->llc_colors, d->num_llc_colors);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 1f424333db..da505a79f6 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -126,6 +126,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2647,6 +2648,8 @@ static void cf_check pagealloc_info(unsigned char key)
     }
 
     printk("    Dom heap: %lukB free\n", total << (PAGE_SHIFT-10));
+
+    dump_llc_coloring_info();
 }
 
 static __init int cf_check pagealloc_keyhandler_init(void)
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
new file mode 100644
index 0000000000..0acd8d0ad6
--- /dev/null
+++ b/xen/include/xen/llc-coloring.h
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Last Level Cache (LLC) coloring common header
+ *
+ * Copyright (C) 2024, Advanced Micro Devices, Inc.
+ * Copyright (C) 2024, Minerva Systems SRL
+ */
+#ifndef __XEN_LLC_COLORING_H__
+#define __XEN_LLC_COLORING_H__
+
+struct domain;
+
+#ifdef CONFIG_LLC_COLORING
+void llc_coloring_init(void);
+void dump_llc_coloring_info(void);
+void domain_dump_llc_colors(const struct domain *d);
+#else
+static inline void llc_coloring_init(void) {}
+static inline void dump_llc_coloring_info(void) {}
+static inline void domain_dump_llc_colors(const struct domain *d) {}
+#endif
+
+unsigned int get_llc_way_size(void);
+void arch_llc_coloring_init(void);
+
+#endif /* __XEN_LLC_COLORING_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 711668e028..037c83fda2 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -640,6 +640,11 @@ struct domain
 
     /* Holding CDF_* constant. Internal flags for domain creation. */
     unsigned int cdf;
+
+#ifdef CONFIG_LLC_COLORING
+    unsigned int num_llc_colors;
+    const unsigned int *llc_colors;
+#endif
 };
 
 static inline struct page_list_head *page_to_list(
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:06:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:06:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859575.1271723 (Exim 4.92)
	(envelope-from )
	id 1tNb20-0006wO-Ea; Tue, 17 Dec 2024 17:06:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859575.1271723; Tue, 17 Dec 2024 17: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 1tNb20-0006uz-8u; Tue, 17 Dec 2024 17:06:48 +0000
Received: by outflank-mailman (input) for mailman id 859575;
 Tue, 17 Dec 2024 17: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 1tNb1y-0006gw-Km
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:06:46 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4ae9e4bd-bc99-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 18:06:44 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-aa6c0d1833eso984010766b.1
 for ; Tue, 17 Dec 2024 09:06:44 -0800 (PST)
Received: from carlo-ubuntu.home.arpa
 (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab963910f7sm461362666b.166.2024.12.17.09.06.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 09:06: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: 4ae9e4bd-bc99-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734455204; x=1735060004; 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=c1jVlKhA9VJnBdspkJfeB+eigkbC7mCy9c7Bxblk1nU=;
        b=jrWjG9Y6LGd8qEhCiJ+R+uFbnguX/MhHs01eFS4hhCrYrBtHM/tFj+WqXa80EGIpPL
         uK6Tvu+q29WRPQ/qYzvalw/nAUF2Px2OZq9Qyo+3MBG6ZaxIieiphzPbfypNgS46G5yH
         1nv4xqOaSQ623+QarUHoLxNtzuHkpIIbVYFQs6BvTWP2nEecx+p4q/YyRY4TU9k4uODa
         OuTdrNBb72YsVZWMsfHByD5MULcLcwgMKAxtC5qpHBtEB517rRHEoIC5M0Zx5eqoI3gw
         aEg4UbyOaL+QKI8Lgth9lPU9+IReXTZYa2bGfOwbqWIY3p4xob+n6E7SxHHWmL0iOW6B
         MCMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734455204; x=1735060004;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=c1jVlKhA9VJnBdspkJfeB+eigkbC7mCy9c7Bxblk1nU=;
        b=p9VpX0FN9ChWUsPPMvFtlZ9sTjlwrMWp6S1oMGqd1oACT/20W+SDOjzF0rSYCzrZa6
         ZcFnhmcC0k2eMDmdJ92ZG0MoV5mDu8HElCj3/LvJH0PCeZRO3A9baLn3aA+HL7jqE1MB
         UkexKsD0mfkuPA8IRwaslaacpVsirWUWY3HUP5Qe4Zt9vtqhZlUgqgMCJHSTX4J7A2oA
         lX8PhbC48jgMNg/I4nCKca2ir/HYLdRWQ7WDjvXYjpedMfsQBCqmSm5b5LjvkzDjud3L
         ZzHF0W1cGKQzcWt9Z7exvK7kCrKwosll/7WuPsmHHZihIlsrQfq9XhxHMUKWHIRaH/Qg
         siUA==
X-Gm-Message-State: AOJu0Ywb3SDCicjxQr5v6/y4/NMuzD2nHzj2E80jXjoBYz1XXGtQT28+
	JY6lZiFIidkdGwOAwew+YSjGH3+CwQTffIZ7W10ryCCIZfoWoyUBjedcxgjBg9V6oQ31WBpH5bK
	BFG4=
X-Gm-Gg: ASbGncu7rmHAyzoLXVDllR0WY932yKnmZ90G8yhehy2NUYsR5Z33uKWwEjLbIw2cBqn
	78eC+tXBwvDUXPp2/jTc0DESLOop+2rJBLi1uPDaeAhEu8jYNR+bQGvdTKufNH+g4KOG/TkDUjL
	yyc/vRUcLLgHwMVQKROHkIBdSNQewhIqOvk8crdDzdxaBZ+HwElSrTGd4AsN+gRoATQMdk4Bree
	w25JsumxrEb8RUat36TIyN/FigpW/YiKRXi0ATHmn8qvKp15LcadN4OxqqkcqTxKCgbiI0xNA1n
	kqnaqjfbZKP2UyNc6xKqwdBUvijR8XB0sJsuACyeNu/aYtx/WalGQLB31vc=
X-Google-Smtp-Source: AGHT+IHv8NfUVs+Q5cfXVQYQIcawUaVEn8Uu8aJJVoV3/NupeHNzvX8VUhUn2BY81HDLnv9Q63id4g==
X-Received: by 2002:a17:906:1313:b0:aab:dc3e:1c84 with SMTP id a640c23a62f3a-aabdc3e1f33mr396402066b.17.1734455203787;
        Tue, 17 Dec 2024 09:06:43 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v13 03/12] xen/arm: permit non direct-mapped Dom0 construction
Date: Tue, 17 Dec 2024 18:06:28 +0100
Message-ID: <20241217170637.233097-4-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
References: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Cache coloring requires Dom0 not to be direct-mapped because of its non
contiguous mapping nature, so allocate_memory() is needed in this case.
8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a separate module")
moved allocate_memory() in dom0less_build.c. In order to use it
in Dom0 construction bring it back to domain_build.c and declare it in
domain_build.h.

Adapt the implementation of allocate_memory() so that it uses the host
layout when called on the hwdom, via find_unallocated_memory().

Since gnttab information are needed in the process, move find_gnttab_region()
before allocate_memory() in construct_dom0().

Introduce add_hwdom_free_regions() callback to add hwdom banks in descending
order.

Signed-off-by: Carlo Nonato 
Reviewed-by: Michal Orzel 
---
v13:
- removed ASSERT(llc_coloring_enabled) from allocate_memory()
- mentioned the reordering of find_gnttab_region() in the commit msg
- fixed gnttab bank size assignment in allocate_memory()
v12:
- used the new generic find_unallocated_memory()
- added add_hwdom_free_regions() callback
v11:
- GUEST_RAM_BANKS instead of hardcoding the number of banks in allocate_memory()
- hwdom_ext_regions -> hwdom_free_mem in allocate_memory()
- added a comment in allocate_memory() when skipping small banks
v10:
- fixed a compilation bug that happened when dom0less support was disabled
v9:
- no changes
v8:
- patch adapted to new changes to allocate_memory()
v7:
- allocate_memory() now uses the host layout when called on the hwdom
v6:
- new patch
---
 xen/arch/arm/dom0less-build.c           |  44 -------
 xen/arch/arm/domain_build.c             | 156 +++++++++++++++++++++++-
 xen/arch/arm/include/asm/domain_build.h |   1 +
 3 files changed, 153 insertions(+), 48 deletions(-)

diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index d93a85434e..67b1503647 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -49,50 +49,6 @@ bool __init is_dom0less_mode(void)
     return ( !dom0found && domUfound );
 }
 
-static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
-{
-    struct membanks *mem = kernel_info_get_mem(kinfo);
-    unsigned int i;
-    paddr_t bank_size;
-
-    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
-           /* Don't want format this as PRIpaddr (16 digit hex) */
-           (unsigned long)(kinfo->unassigned_mem >> 20), d);
-
-    mem->nr_banks = 0;
-    bank_size = MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem);
-    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM0_BASE),
-                               bank_size) )
-        goto fail;
-
-    bank_size = MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem);
-    if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(GUEST_RAM1_BASE),
-                               bank_size) )
-        goto fail;
-
-    if ( kinfo->unassigned_mem )
-        goto fail;
-
-    for( i = 0; i < mem->nr_banks; i++ )
-    {
-        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
-               d,
-               i,
-               mem->bank[i].start,
-               mem->bank[i].start + mem->bank[i].size,
-               /* Don't want format this as PRIpaddr (16 digit hex) */
-               (unsigned long)(mem->bank[i].size >> 20));
-    }
-
-    return;
-
-fail:
-    panic("Failed to allocate requested domain memory."
-          /* Don't want format this as PRIpaddr (16 digit hex) */
-          " %ldKB unallocated. Fix the VMs configurations.\n",
-          (unsigned long)kinfo->unassigned_mem >> 10);
-}
-
 #ifdef CONFIG_VGICV2
 static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
 {
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index adf26f2778..17cc76b6f2 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -416,7 +417,6 @@ static void __init allocate_memory_11(struct domain *d,
     }
 }
 
-#ifdef CONFIG_DOM0LESS_BOOT
 bool __init allocate_domheap_memory(struct domain *d, paddr_t tot_size,
                                     alloc_domheap_mem_cb cb, void *extra)
 {
@@ -508,7 +508,6 @@ bool __init allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
 
     return true;
 }
-#endif
 
 /*
  * When PCI passthrough is available we want to keep the
@@ -900,6 +899,52 @@ int __init add_ext_regions(unsigned long s_gfn, unsigned long e_gfn,
     return 0;
 }
 
+static int __init add_hwdom_free_regions(unsigned long s_gfn,
+                                         unsigned long e_gfn, void *data)
+{
+    struct membanks *free_regions = data;
+    paddr_t start, size;
+    paddr_t s = pfn_to_paddr(s_gfn);
+    paddr_t e = pfn_to_paddr(e_gfn);
+    unsigned int i, j;
+
+    if ( free_regions->nr_banks >= free_regions->max_banks )
+        return 0;
+
+    /*
+     * Both start and size of the free region should be 2MB aligned to
+     * potentially allow superpage mapping.
+     */
+    start = (s + SZ_2M - 1) & ~(SZ_2M - 1);
+    if ( start > e )
+        return 0;
+
+    /*
+     * e is actually "end-1" because it is called by rangeset functions
+     * which are inclusive of the last address.
+     */
+    e += 1;
+    size = (e - start) & ~(SZ_2M - 1);
+
+    /* Find the insert position (descending order). */
+    for ( i = 0; i < free_regions->nr_banks ; i++ )
+        if ( size > free_regions->bank[i].size )
+            break;
+
+    /* Move the other banks to make space. */
+    for ( j = free_regions->nr_banks; j > i ; j-- )
+    {
+        free_regions->bank[j].start = free_regions->bank[j - 1].start;
+        free_regions->bank[j].size = free_regions->bank[j - 1].size;
+    }
+
+    free_regions->bank[i].start = start;
+    free_regions->bank[i].size = size;
+    free_regions->nr_banks++;
+
+    return 0;
+}
+
 /*
  * Find unused regions of Host address space which can be exposed to domain
  * using the host memory layout. In order to calculate regions we exclude every
@@ -977,6 +1022,106 @@ out:
     return res;
 }
 
+void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
+{
+    struct membanks *mem = kernel_info_get_mem(kinfo);
+    unsigned int i, nr_banks = GUEST_RAM_BANKS;
+    struct membanks *hwdom_free_mem = NULL;
+
+    printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
+           /* Don't want format this as PRIpaddr (16 digit hex) */
+           (unsigned long)(kinfo->unassigned_mem >> 20), d);
+
+    mem->nr_banks = 0;
+    /*
+     * Use host memory layout for hwdom. Only case for this is when LLC coloring
+     * is enabled.
+     */
+    if ( is_hardware_domain(d) )
+    {
+        struct membanks *gnttab = xzalloc_flex_struct(struct membanks, bank, 1);
+        /*
+         * Exclude the following regions:
+         * 1) Remove reserved memory
+         * 2) Grant table assigned to hwdom
+         */
+        const struct membanks *mem_banks[] = {
+            bootinfo_get_reserved_mem(),
+            gnttab,
+        };
+
+        if ( !gnttab )
+            goto fail;
+
+        gnttab->nr_banks = 1;
+        gnttab->bank[0].start = kinfo->gnttab_start;
+        gnttab->bank[0].size = kinfo->gnttab_size;
+
+        hwdom_free_mem = xzalloc_flex_struct(struct membanks, bank,
+                                             NR_MEM_BANKS);
+        if ( !hwdom_free_mem )
+            goto fail;
+
+        hwdom_free_mem->max_banks = NR_MEM_BANKS;
+
+        if ( find_unallocated_memory(kinfo, mem_banks, ARRAY_SIZE(mem_banks),
+                                     hwdom_free_mem, add_hwdom_free_regions) )
+            goto fail;
+
+        nr_banks = hwdom_free_mem->nr_banks;
+        xfree(gnttab);
+    }
+
+    for ( i = 0; kinfo->unassigned_mem > 0 && nr_banks > 0; i++, nr_banks-- )
+    {
+        paddr_t bank_start, bank_size;
+
+        if ( is_hardware_domain(d) )
+        {
+            bank_start = hwdom_free_mem->bank[i].start;
+            bank_size = hwdom_free_mem->bank[i].size;
+        }
+        else
+        {
+            const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
+            const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
+
+            if ( i >= GUEST_RAM_BANKS )
+                goto fail;
+
+            bank_start = bankbase[i];
+            bank_size = banksize[i];
+        }
+
+        bank_size = MIN(bank_size, kinfo->unassigned_mem);
+        if ( !allocate_bank_memory(kinfo, gaddr_to_gfn(bank_start), bank_size) )
+            goto fail;
+    }
+
+    if ( kinfo->unassigned_mem )
+        goto fail;
+
+    for( i = 0; i < mem->nr_banks; i++ )
+    {
+        printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
+               d,
+               i,
+               mem->bank[i].start,
+               mem->bank[i].start + mem->bank[i].size,
+               /* Don't want format this as PRIpaddr (16 digit hex) */
+               (unsigned long)(mem->bank[i].size >> 20));
+    }
+
+    xfree(hwdom_free_mem);
+    return;
+
+  fail:
+    panic("Failed to allocate requested domain memory."
+          /* Don't want format this as PRIpaddr (16 digit hex) */
+          " %ldKB unallocated. Fix the VMs configurations.\n",
+          (unsigned long)kinfo->unassigned_mem >> 10);
+}
+
 static int __init handle_pci_range(const struct dt_device_node *dev,
                                    uint64_t addr, uint64_t len, void *data)
 {
@@ -1235,7 +1380,7 @@ int __init make_hypervisor_node(struct domain *d,
 
         ext_regions->max_banks = NR_MEM_BANKS;
 
-        if ( is_domain_direct_mapped(d) )
+        if ( domain_use_host_layout(d) )
         {
             if ( !is_iommu_enabled(d) )
                 res = find_host_extended_regions(kinfo, ext_regions);
@@ -2164,8 +2309,11 @@ static int __init construct_dom0(struct domain *d)
     /* type must be set before allocate_memory */
     d->arch.type = kinfo.type;
 #endif
-    allocate_memory_11(d, &kinfo);
     find_gnttab_region(d, &kinfo);
+    if ( is_domain_direct_mapped(d) )
+        allocate_memory_11(d, &kinfo);
+    else
+        allocate_memory(d, &kinfo);
 
     rc = process_shm_chosen(d, &kinfo);
     if ( rc < 0 )
diff --git a/xen/arch/arm/include/asm/domain_build.h b/xen/arch/arm/include/asm/domain_build.h
index e712afbc7f..5d77af2e8b 100644
--- a/xen/arch/arm/include/asm/domain_build.h
+++ b/xen/arch/arm/include/asm/domain_build.h
@@ -11,6 +11,7 @@ bool allocate_domheap_memory(struct domain *d, paddr_t tot_size,
                              alloc_domheap_mem_cb cb, void *extra);
 bool allocate_bank_memory(struct kernel_info *kinfo, gfn_t sgfn,
                           paddr_t tot_size);
+void allocate_memory(struct domain *d, struct kernel_info *kinfo);
 int construct_domain(struct domain *d, struct kernel_info *kinfo);
 int domain_fdt_begin_node(void *fdt, const char *name, uint64_t unit);
 int make_chosen_node(const struct kernel_info *kinfo);
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:06:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:06:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859574.1271704 (Exim 4.92)
	(envelope-from )
	id 1tNb1x-0006Vj-Vi; Tue, 17 Dec 2024 17:06:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859574.1271704; Tue, 17 Dec 2024 17:06: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 1tNb1x-0006V4-S5; Tue, 17 Dec 2024 17:06:45 +0000
Received: by outflank-mailman (input) for mailman id 859574;
 Tue, 17 Dec 2024 17:06: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 1tNb1w-0006B0-K8
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:06:44 +0000
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com
 [2a00:1450:4864:20::536])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4a6bfb08-bc99-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 18:06:43 +0100 (CET)
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5d3bdccba49so9612786a12.1
 for ; Tue, 17 Dec 2024 09:06:43 -0800 (PST)
Received: from carlo-ubuntu.home.arpa
 (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab963910f7sm461362666b.166.2024.12.17.09.06.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 09:06: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: 4a6bfb08-bc99-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734455203; x=1735060003; 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=HRiXjScTKjjwC6ubbpUmf/5GyGMeNLHHwHKs6KCqd38=;
        b=T6BomwBXqEi05TR8U4IufFgmeqcFjTaAmxznVFo6TrfqdNTSbgzWPOSTA2bdL0vdht
         O1UhGcSbrQDqH5QYwDdtoOzDmEDkd9ubZoHNeBOYh06mE0N4EC9aCFW5QwZ6iZ81LSOK
         qDwNll9SnPV/EzBw/BAdlmhj4IfBR/JoVQ2g0UEtPRyP2SC/sPaHLWPkQY56zbfqMpFS
         W5mP/LbVdB1i0znVMiH/gYLUeNKTSntNZsI/XpjcUHGz3c7yx/u0J0QTYneb1JBLOsMc
         WsCu3pivm1i+8yAbfPrtNK+DDglpqKiPgkXKCxKTdcfmon63RDpEWNPCQ2URTpviXt6E
         B85A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734455203; x=1735060003;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=HRiXjScTKjjwC6ubbpUmf/5GyGMeNLHHwHKs6KCqd38=;
        b=Aqu26L1WFobo5SQwbT0E3gJp7jWGQ4txXE2NKjH8ILS7x3vBX0eLevf/5W7FeivwhR
         6FA7XVaWy2Q15T0kpLFoqsKv+cON+0QQp1xHInZR3mFwZCRU6HE5ecAj/lFUn5n8syOI
         97y0kpz2PkrIsMH3xrcuye00ikQwhWjQClIp+XZJRPW/juwKRyJW5kaYSZxdDfFO0Pjf
         x042tUP8Qg7qAF/9cTdB8KHFYaxKUHVpvaaST4vM1HQweIIy35hqeHUbVCJ92KnYEAns
         DKNMK22omE6h74V9lWX8ShqTrVK10s4OFtOpyyH4d1sQcozO7CyHZZDKhFfqMZntRxKC
         QF7g==
X-Gm-Message-State: AOJu0YwEWQfeJEBDNnX/J5DCr9wZTZoRlqMQiiocgSkriZFdAF9McFMS
	nWBB2osV5dIY9GfYqcyZMF3k0aUeGNnwGMF0cMfFnsYUCiOuZS5hE3BNx15YHYqOK63K085sRRQ
	oew4=
X-Gm-Gg: ASbGncvgMfuteaIfmTdHSIkmZw2jv9zelYjlfAQaNnHHCryH8B0u7ThBns/H9CwqtmF
	TL3UD8Zd7Nat48Rg1MDQll3pWt6gquxcF53//962EnA7vLhhpIdUo8i9fQiZM2dQZQCPdDbv69Z
	hUwDCih3xxZamvT3IpLoaT0jYnwVnjZe78F80mxBYcgYcbNRNN7Qy9MlP5Jxo8O6zxv91S3SPMW
	brXpQEY2GX1vY7NBA7e6YsP1BUfCqqlikv3zRpvY6KR+IcMbh+R78LI56aLNF3fn3DnegBOxjEB
	n9w9/k0omS5OHgWa47qIpazev4Jr3iD5jj38j4HvEE4sYyzSQB8Lix2drkw=
X-Google-Smtp-Source: AGHT+IG8/f8xMijmze2k8W3XnEhE7dCYgbw/N1p0uKnCR58cGxdUxzFjMwod1mbqor/6uSqlFXmRqg==
X-Received: by 2002:a17:907:2d8e:b0:aa6:a05c:b076 with SMTP id a640c23a62f3a-aabdb3be7d5mr449039966b.26.1734455202735;
        Tue, 17 Dec 2024 09:06:42 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: [PATCH v13 02/12] xen/arm: add initial support for LLC coloring on arm64
Date: Tue, 17 Dec 2024 18:06:27 +0100
Message-ID: <20241217170637.233097-3-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
References: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

LLC coloring needs to know the last level cache layout in order to make the
best use of it. This can be probed by inspecting the CLIDR_EL1 register,
so the Last Level is defined as the last level visible by this register.
Note that this excludes system caches in some platforms.

Static memory allocation and cache coloring are incompatible because static
memory can't be guaranteed to use only colors assigned to the domain.
Panic during DomUs creation when both are enabled.

Based on original work from: Luca Miccio 

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
Reviewed-by: Michal Orzel 
Acked-by: Jan Beulich 
---
v13:
- no changes
v12:
- fixed build errors
v11:
- removed useless #define from processor.h
v10:
- moved CONFIG_NUMA check in arch/arm/Kconfig
v9:
- no changes
v8:
- no changes
v7:
- only minor changes
v6:
- get_llc_way_size() now checks for at least separate I/D caches
v5:
- used - instead of _ for filenames
- moved static-mem check in this patch
- moved dom0 colors parsing in next patch
- moved color allocation and configuration in next patch
- moved check_colors() in next patch
- colors are now printed in short form
v4:
- added "llc-coloring" cmdline option for the boot-time switch
- dom0 colors are now checked during domain init as for any other domain
- fixed processor.h masks bit width
- check for overflow in parse_color_config()
- check_colors() now checks also that colors are sorted and unique
---
 docs/misc/cache-coloring.rst         | 14 +++++
 xen/arch/arm/Kconfig                 |  1 +
 xen/arch/arm/Makefile                |  1 +
 xen/arch/arm/dom0less-build.c        |  6 +++
 xen/arch/arm/include/asm/processor.h | 15 ++++++
 xen/arch/arm/llc-coloring.c          | 79 ++++++++++++++++++++++++++++
 xen/arch/arm/setup.c                 |  3 ++
 xen/common/llc-coloring.c            |  4 +-
 xen/include/xen/llc-coloring.h       |  6 +++
 9 files changed, 128 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/arm/llc-coloring.c

diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
index 371f21a0e7..12972dbb2c 100644
--- a/docs/misc/cache-coloring.rst
+++ b/docs/misc/cache-coloring.rst
@@ -113,6 +113,20 @@ Auto-probing of LLC specs
 
 LLC size and number of ways are probed automatically by default.
 
+In the Arm implementation, this is done by inspecting the CLIDR_EL1 register.
+This means that other system caches that aren't visible there are ignored.
+
 LLC specs can be manually set via the above command line parameters. This
 bypasses any auto-probing and it's used to overcome failing situations, such as
 flawed probing logic, or for debugging/testing purposes.
+
+Known issues and limitations
+****************************
+
+"xen,static-mem" isn't supported when coloring is enabled
+#########################################################
+
+In the domain configuration, "xen,static-mem" allows memory to be statically
+allocated to the domain. This isn't possible when LLC coloring is enabled,
+because that memory can't be guaranteed to use only colors assigned to the
+domain.
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 604aba4996..c5e7b74733 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -8,6 +8,7 @@ config ARM_64
 	depends on !ARM_32
 	select 64BIT
 	select HAS_FAST_MULTIPLY
+	select HAS_LLC_COLORING if !NUMA
 
 config ARM
 	def_bool y
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index e4ad1ce851..ccbfc61f88 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_IOREQ_SERVER) += ioreq.o
 obj-y += irq.o
 obj-y += kernel.init.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o
+obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
 obj-$(CONFIG_MEM_ACCESS) += mem_access.o
 obj-y += mm.o
 obj-y += monitor.o
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index f328a044e9..d93a85434e 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -890,7 +891,12 @@ void __init create_domUs(void)
             panic("No more domain IDs available\n");
 
         if ( dt_find_property(node, "xen,static-mem", NULL) )
+        {
+            if ( llc_coloring_enabled )
+                panic("LLC coloring and static memory are incompatible\n");
+
             flags |= CDF_staticmem;
+        }
 
         if ( dt_property_read_bool(node, "direct-map") )
         {
diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h
index 8e02410465..60b587db69 100644
--- a/xen/arch/arm/include/asm/processor.h
+++ b/xen/arch/arm/include/asm/processor.h
@@ -18,6 +18,21 @@
 #define CTR_IDC_SHIFT       28
 #define CTR_DIC_SHIFT       29
 
+/* CCSIDR Current Cache Size ID Register */
+#define CCSIDR_LINESIZE_MASK            _AC(0x7, UL)
+#define CCSIDR_NUMSETS_SHIFT            13
+#define CCSIDR_NUMSETS_MASK             _AC(0x3fff, UL)
+#define CCSIDR_NUMSETS_SHIFT_FEAT_CCIDX 32
+#define CCSIDR_NUMSETS_MASK_FEAT_CCIDX  _AC(0xffffff, UL)
+
+/* CSSELR Cache Size Selection Register */
+#define CSSELR_LEVEL_SHIFT 1
+
+/* CLIDR Cache Level ID Register */
+#define CLIDR_CTYPEn_SHIFT(n) (3 * ((n) - 1))
+#define CLIDR_CTYPEn_MASK     _AC(0x7, UL)
+#define CLIDR_CTYPEn_LEVELS   7
+
 #define ICACHE_POLICY_VPIPT  0
 #define ICACHE_POLICY_AIVIVT 1
 #define ICACHE_POLICY_VIPT   2
diff --git a/xen/arch/arm/llc-coloring.c b/xen/arch/arm/llc-coloring.c
new file mode 100644
index 0000000000..1c7b92bc45
--- /dev/null
+++ b/xen/arch/arm/llc-coloring.c
@@ -0,0 +1,79 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Last Level Cache (LLC) coloring support for ARM
+ *
+ * Copyright (C) 2024, Advanced Micro Devices, Inc.
+ * Copyright (C) 2024, Minerva Systems SRL
+ */
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* Return the LLC way size by probing the hardware */
+unsigned int __init get_llc_way_size(void)
+{
+    register_t ccsidr_el1;
+    register_t clidr_el1 = READ_SYSREG(CLIDR_EL1);
+    register_t csselr_el1 = READ_SYSREG(CSSELR_EL1);
+    register_t id_aa64mmfr2_el1 = READ_SYSREG(ID_AA64MMFR2_EL1);
+    uint32_t ccsidr_numsets_shift = CCSIDR_NUMSETS_SHIFT;
+    uint32_t ccsidr_numsets_mask = CCSIDR_NUMSETS_MASK;
+    unsigned int n, line_size, num_sets;
+
+    for ( n = CLIDR_CTYPEn_LEVELS; n != 0; n-- )
+    {
+        uint8_t ctype_n = (clidr_el1 >> CLIDR_CTYPEn_SHIFT(n)) &
+                           CLIDR_CTYPEn_MASK;
+
+        /* Unified cache (see Arm ARM DDI 0487J.a D19.2.27) */
+        if ( ctype_n == 0b100 )
+            break;
+    }
+
+    if ( n == 0 )
+        return 0;
+
+    WRITE_SYSREG((n - 1) << CSSELR_LEVEL_SHIFT, CSSELR_EL1);
+    isb();
+
+    ccsidr_el1 = READ_SYSREG(CCSIDR_EL1);
+
+    /* Arm ARM: (Log2(Number of bytes in cache line)) - 4 */
+    line_size = 1U << ((ccsidr_el1 & CCSIDR_LINESIZE_MASK) + 4);
+
+    /* If FEAT_CCIDX is enabled, CCSIDR_EL1 has a different bit layout */
+    if ( (id_aa64mmfr2_el1 >> ID_AA64MMFR2_CCIDX_SHIFT) & 0x7 )
+    {
+        ccsidr_numsets_shift = CCSIDR_NUMSETS_SHIFT_FEAT_CCIDX;
+        ccsidr_numsets_mask = CCSIDR_NUMSETS_MASK_FEAT_CCIDX;
+    }
+
+    /* Arm ARM: (Number of sets in cache) - 1 */
+    num_sets = ((ccsidr_el1 >> ccsidr_numsets_shift) & ccsidr_numsets_mask) + 1;
+
+    printk(XENLOG_INFO "LLC found: L%u (line size: %u bytes, sets num: %u)\n",
+           n, line_size, num_sets);
+
+    /* Restore value in CSSELR_EL1 */
+    WRITE_SYSREG(csselr_el1, CSSELR_EL1);
+    isb();
+
+    return line_size * num_sets;
+}
+
+void __init arch_llc_coloring_init(void)
+{
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 545702d8a3..5f1993ffed 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -334,6 +335,8 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr)
     printk("Command line: %s\n", cmdline);
     cmdline_parse(cmdline);
 
+    llc_coloring_init();
+
     setup_mm();
 
     vm_init();
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index 335a907296..b034c0169c 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -8,6 +8,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define NR_LLC_COLORS          (1U << CONFIG_LLC_COLORS_ORDER)
 
@@ -19,7 +21,7 @@
 static int8_t __initdata opt_llc_coloring = -1;
 boolean_param("llc-coloring", opt_llc_coloring);
 
-static bool __ro_after_init llc_coloring_enabled;
+bool __ro_after_init llc_coloring_enabled;
 
 static unsigned int __initdata llc_size;
 size_param("llc-size", llc_size);
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
index 0acd8d0ad6..a3ebb17186 100644
--- a/xen/include/xen/llc-coloring.h
+++ b/xen/include/xen/llc-coloring.h
@@ -8,13 +8,19 @@
 #ifndef __XEN_LLC_COLORING_H__
 #define __XEN_LLC_COLORING_H__
 
+#include 
+
 struct domain;
 
 #ifdef CONFIG_LLC_COLORING
+extern bool llc_coloring_enabled;
+
 void llc_coloring_init(void);
 void dump_llc_coloring_info(void);
 void domain_dump_llc_colors(const struct domain *d);
 #else
+#define llc_coloring_enabled false
+
 static inline void llc_coloring_init(void) {}
 static inline void dump_llc_coloring_info(void) {}
 static inline void domain_dump_llc_colors(const struct domain *d) {}
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:06:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:06:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859576.1271718 (Exim 4.92)
	(envelope-from )
	id 1tNb20-0006tX-5w; Tue, 17 Dec 2024 17:06:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859576.1271718; Tue, 17 Dec 2024 17: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 1tNb20-0006tK-2f; Tue, 17 Dec 2024 17:06:48 +0000
Received: by outflank-mailman (input) for mailman id 859576;
 Tue, 17 Dec 2024 17:06: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 1tNb1y-0006B0-LY
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:06:46 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4bbe35a4-bc99-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 18:06:45 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5d3e829ff44so11936217a12.0
 for ; Tue, 17 Dec 2024 09:06:45 -0800 (PST)
Received: from carlo-ubuntu.home.arpa
 (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab963910f7sm461362666b.166.2024.12.17.09.06.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 09:06: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: 4bbe35a4-bc99-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734455205; x=1735060005; 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=CtIKFLoM6ff7CtjdbQpOl+Sf+qsR3Tbe9ZtV5iZhVh4=;
        b=QYBhKQslzQbT3f48tSet/eHvKCD6uB/zXVywOC0YX6MxA32OditFSdLMQlFPM5lnkR
         Yyf58fYotW9wJP3boy7eaGgWpXzFIkJYNhxUDzH1Ef4wrlbR0Ehj2lfKS3Gir5OqFWH4
         Oj45I3KQNOtScup7teN9b3CEQURsOHk1HJtQ34SA263+jAtl9q1hcKOypHPSfVSfEKx/
         Q7Ug9XYrhGyzx9rSMUV/Uavgq4XjJSul1oKx3/iCERzTWV1GIsRstQpkiB2/f7UYQesQ
         JrcnmQ/QB3ybxqvUbCVPwjX7CiJhcHQctY6SFzyhRH2DfCQvcIHvMJgFqOp7SAFW1VT4
         NFcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734455205; x=1735060005;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=CtIKFLoM6ff7CtjdbQpOl+Sf+qsR3Tbe9ZtV5iZhVh4=;
        b=w9lWvvJCEBM1Q/+udjUmWpDElg7qpZ3q3K3U+7/vLaCfWmPRcmHDdclNCQoimbnQDM
         CEHVfHlb2JkmNA5cH3g5pq5XdR3Y/I+HwvklL4c4ZEEco3iANGhnsJ+FrXy7vGuT8DAj
         u3/10ZDkfLqZn28LBHe1+Qrq34zivl5HYHZF21lLmHlMhLWVT7WnvSBOBA+ky+V166nA
         surgoxGQnUcXEgvRdyBNhbuJNwSbToCwTsDY6zo8OpvuJsmSS29B+FVUBu0lH/L3Gre1
         ycsTPHgoJXnos5+LyeZc05z5x/AALbWSJXVVY2up/hCCfzIXJEpBH9bRy0U1trdxG4X2
         NksA==
X-Gm-Message-State: AOJu0YyGrhR25XzqMoOLR+PTbe3Z4Wjd2A64EkuGnC18v746e0EHPP4z
	L3HWm/DyiWL1Bn4R/b4Z6BaVQHt6SLhQlrlLa7qQEGqTO1IofQBHqxuFVWA1FY8mgq39zEDlAvv
	gYOc=
X-Gm-Gg: ASbGnctJdcTKD2Ta8r1T3ncwlRsqOpbhFA1gjXkBkBHxJvNkby7zbIIrZJB4xqcPBQ4
	kyhI2CUCCz+Hk0t75LAhY2bvuPYaLwbOC95NYIlVxYZholgLnkPfPocRxkrqSR/R8N7bV77rkL3
	lpfvBV8M+ZpJPzQcubkjewpUGSZ3pbSPGV0aBz3mr3n7QXaQh8NzWA1Sa5K4346N7pegg5oNS21
	GsnoeFTduBIKKpyufa2vRT388pK+9OkrlrdPZZREy64fxNYm0cu8USuyU5OCCk2rdVemdcx5OlT
	vaN3iUD5/ODZxwvcb1V6/Pxik3BJ1Df44KXiKin9lUP4lxanyEWFnq0yXqg=
X-Google-Smtp-Source: AGHT+IEsFLfarCLyU2p9IiihuOgyXSgr1SXUa4ThtBEQ+us37TZQxDMvYFBHTgf3inP8xmb9YfN9hA==
X-Received: by 2002:a17:907:a089:b0:aa6:8b4a:4695 with SMTP id a640c23a62f3a-aabdcb8265fmr398063866b.31.1734455204824;
        Tue, 17 Dec 2024 09:06:44 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: [PATCH v13 04/12] xen/arm: add Dom0 cache coloring support
Date: Tue, 17 Dec 2024 18:06:29 +0100
Message-ID: <20241217170637.233097-5-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
References: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add a command line parameter to allow the user to set the coloring
configuration for Dom0.
A common configuration syntax for cache colors is introduced and
documented.
Take the opportunity to also add:
 - default configuration notion.
 - function to check well-formed configurations.

Direct mapping Dom0 isn't possible when coloring is enabled, so
CDF_directmap flag is removed when creating it.

Based on original work from: Luca Miccio 

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
Reviewed-by: Jan Beulich 
Reviewed-by: Michal Orzel 
---
v13:
- no changes
v12:
- no changes
v11:
- minor changes
v10:
- fixed array type for colors parameter in check_colors()
v9:
- moved domain_llc_coloring_free() in next patch cause it's never used for dom0
v8:
- added bound check on dom0_num_colors
- default colors array set just once
v7:
- parse_color_config() doesn't accept leading/trailing commas anymore
- removed alloc_colors() helper
v6:
- moved domain_llc_coloring_free() in this patch
- removed domain_alloc_colors() in favor of a more explicit allocation
- parse_color_config() now accepts the size of the array to be filled
- allocate_memory() moved in another patch
v5:
- Carlo Nonato as the new author
- moved dom0 colors parsing (parse_colors()) in this patch
- added dom0_set_llc_colors() to set dom0 colors after creation
- moved color allocation and checking in this patch
- error handling when allocating color arrays
- FIXME: copy pasted allocate_memory() cause it got moved
v4:
- dom0 colors are dynamically allocated as for any other domain
  (colors are duplicated in dom0_colors and in the new array, but logic
  is simpler)
---
 docs/misc/cache-coloring.rst      |  29 ++++++++
 docs/misc/xen-command-line.pandoc |   9 +++
 xen/arch/arm/domain_build.c       |   9 ++-
 xen/common/llc-coloring.c         | 120 +++++++++++++++++++++++++++++-
 xen/include/xen/llc-coloring.h    |   1 +
 5 files changed, 166 insertions(+), 2 deletions(-)

diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
index 12972dbb2c..7b47d0ed92 100644
--- a/docs/misc/cache-coloring.rst
+++ b/docs/misc/cache-coloring.rst
@@ -107,6 +107,35 @@ Specific documentation is available at `docs/misc/xen-command-line.pandoc`.
 +----------------------+-------------------------------+
 | ``llc-nr-ways``      | Set the LLC number of ways    |
 +----------------------+-------------------------------+
+| ``dom0-llc-colors``  | Dom0 color configuration      |
++----------------------+-------------------------------+
+
+Colors selection format
+***********************
+
+Regardless of the memory pool that has to be colored (Xen, Dom0/DomUs),
+the color selection can be expressed using the same syntax. In particular a
+comma-separated list of colors or ranges of colors is used.
+Ranges are hyphen-separated intervals (such as `0-4`) and are inclusive on both
+sides.
+
+Note that:
+
+- no spaces are allowed between values.
+- no overlapping ranges or duplicated colors are allowed.
+- values must be written in ascending order.
+
+Examples:
+
++-------------------+-----------------------------+
+| **Configuration** | **Actual selection**        |
++-------------------+-----------------------------+
+| 1-2,5-8           | [1, 2, 5, 6, 7, 8]          |
++-------------------+-----------------------------+
+| 4-8,10,11,12      | [4, 5, 6, 7, 8, 10, 11, 12] |
++-------------------+-----------------------------+
+| 0                 | [0]                         |
++-------------------+-----------------------------+
 
 Auto-probing of LLC specs
 #########################
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index ca105ec559..be70d6af61 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -963,6 +963,15 @@ Controls for the dom0 IOMMU setup.
 
 Specify a list of IO ports to be excluded from dom0 access.
 
+### dom0-llc-colors (arm64)
+> `= List of [  | - ]`
+
+> Default: `All available LLC colors`
+
+Specify dom0 LLC color configuration. This option is available only when
+`CONFIG_LLC_COLORING` is enabled. If the parameter is not set, all available
+colors are used.
+
 ### dom0_max_vcpus
 
 Either:
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 17cc76b6f2..b072a16249 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2356,6 +2356,7 @@ void __init create_dom0(void)
         .max_maptrack_frames = -1,
         .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
     };
+    unsigned int flags = CDF_privileged;
     int rc;
 
     /* The vGIC for DOM0 is exactly emulating the hardware GIC */
@@ -2383,10 +2384,16 @@ void __init create_dom0(void)
             panic("SVE vector length error\n");
     }
 
-    dom0 = domain_create(0, &dom0_cfg, CDF_privileged | CDF_directmap);
+    if ( !llc_coloring_enabled )
+        flags |= CDF_directmap;
+
+    dom0 = domain_create(0, &dom0_cfg, flags);
     if ( IS_ERR(dom0) )
         panic("Error creating domain 0 (rc = %ld)\n", PTR_ERR(dom0));
 
+    if ( llc_coloring_enabled && (rc = dom0_set_llc_colors(dom0)) )
+        panic("Error initializing LLC coloring for domain 0 (rc = %d)\n", rc);
+
     if ( alloc_dom0_vcpu0(dom0) == NULL )
         panic("Error creating domain 0 vcpu0\n");
 
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index b034c0169c..5984ae82e7 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -29,6 +29,66 @@ static unsigned int __initdata llc_nr_ways;
 integer_param("llc-nr-ways", llc_nr_ways);
 /* Number of colors available in the LLC */
 static unsigned int __ro_after_init max_nr_colors;
+/* Default coloring configuration */
+static unsigned int __ro_after_init default_colors[NR_LLC_COLORS];
+
+static unsigned int __initdata dom0_colors[NR_LLC_COLORS];
+static unsigned int __initdata dom0_num_colors;
+
+/*
+ * Parse the coloring configuration given in the buf string, following the
+ * syntax below.
+ *
+ * COLOR_CONFIGURATION ::= COLOR | RANGE,...,COLOR | RANGE
+ * RANGE               ::= COLOR-COLOR
+ *
+ * Example: "0,2-6,15-16" represents the set of colors: 0,2,3,4,5,6,15,16.
+ */
+static int __init parse_color_config(const char *buf, unsigned int colors[],
+                                     unsigned int max_num_colors,
+                                     unsigned int *num_colors)
+{
+    const char *s = buf;
+
+    *num_colors = 0;
+
+    while ( *s != '\0' )
+    {
+        unsigned int color, start, end;
+
+        start = simple_strtoul(s, &s, 0);
+
+        if ( *s == '-' )    /* Range */
+        {
+            s++;
+            end = simple_strtoul(s, &s, 0);
+        }
+        else                /* Single value */
+            end = start;
+
+        if ( start > end || (end - start) > (UINT_MAX - *num_colors) ||
+             (*num_colors + (end - start)) >= max_num_colors )
+            return -EINVAL;
+
+        /* Colors are range checked in check_colors() */
+        for ( color = start; color <= end; color++ )
+            colors[(*num_colors)++] = color;
+
+        if ( *s == ',' )
+            s++;
+        else if ( *s != '\0' )
+            break;
+    }
+
+    return *s ? -EINVAL : 0;
+}
+
+static int __init parse_dom0_colors(const char *s)
+{
+    return parse_color_config(s, dom0_colors, ARRAY_SIZE(dom0_colors),
+                              &dom0_num_colors);
+}
+custom_param("dom0-llc-colors", parse_dom0_colors);
 
 static void print_colors(const unsigned int colors[], unsigned int num_colors)
 {
@@ -53,9 +113,27 @@ static void print_colors(const unsigned int colors[], unsigned int num_colors)
     printk(" }\n");
 }
 
+static bool __init check_colors(const unsigned int colors[],
+                                unsigned int num_colors)
+{
+    unsigned int i;
+
+    for ( i = 0; i < num_colors; i++ )
+    {
+        if ( colors[i] >= max_nr_colors )
+        {
+            printk(XENLOG_ERR "LLC color %u >= %u (max allowed)\n", colors[i],
+                   max_nr_colors);
+            return false;
+        }
+    }
+
+    return true;
+}
+
 void __init llc_coloring_init(void)
 {
-    unsigned int way_size;
+    unsigned int way_size, i;
 
     llc_coloring_enabled = (opt_llc_coloring >= 1);
     if ( (opt_llc_coloring != 0) && llc_size && llc_nr_ways )
@@ -94,6 +172,9 @@ void __init llc_coloring_init(void)
     else if ( max_nr_colors < 2 )
         panic("Number of LLC colors %u < 2\n", max_nr_colors);
 
+    for ( i = 0; i < max_nr_colors; i++ )
+        default_colors[i] = i;
+
     arch_llc_coloring_init();
 }
 
@@ -115,6 +196,43 @@ void domain_dump_llc_colors(const struct domain *d)
     print_colors(d->llc_colors, d->num_llc_colors);
 }
 
+static void __init domain_set_default_colors(struct domain *d)
+{
+    printk(XENLOG_WARNING
+           "LLC color config not found for %pd, using all colors\n", d);
+
+    d->llc_colors = default_colors;
+    d->num_llc_colors = max_nr_colors;
+}
+
+int __init dom0_set_llc_colors(struct domain *d)
+{
+    typeof(*dom0_colors) *colors;
+
+    if ( !dom0_num_colors )
+    {
+        domain_set_default_colors(d);
+        return 0;
+    }
+
+    if ( (dom0_num_colors > max_nr_colors) ||
+         !check_colors(dom0_colors, dom0_num_colors) )
+    {
+        printk(XENLOG_ERR "%pd:  bad LLC color config\n", d);
+        return -EINVAL;
+    }
+
+    colors = xmalloc_array(typeof(*dom0_colors), dom0_num_colors);
+    if ( !colors )
+        return -ENOMEM;
+
+    memcpy(colors, dom0_colors, sizeof(*colors) * dom0_num_colors);
+    d->llc_colors = colors;
+    d->num_llc_colors = dom0_num_colors;
+
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
index a3ebb17186..d29ebeb4c5 100644
--- a/xen/include/xen/llc-coloring.h
+++ b/xen/include/xen/llc-coloring.h
@@ -28,6 +28,7 @@ static inline void domain_dump_llc_colors(const struct domain *d) {}
 
 unsigned int get_llc_way_size(void);
 void arch_llc_coloring_init(void);
+int dom0_set_llc_colors(struct domain *d);
 
 #endif /* __XEN_LLC_COLORING_H__ */
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:06:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:06:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859572.1271688 (Exim 4.92)
	(envelope-from )
	id 1tNb1w-0006BI-DC; Tue, 17 Dec 2024 17:06:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859572.1271688; Tue, 17 Dec 2024 17:06: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 1tNb1w-0006BB-AJ; Tue, 17 Dec 2024 17:06:44 +0000
Received: by outflank-mailman (input) for mailman id 859572;
 Tue, 17 Dec 2024 17:06: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 1tNb1u-0006B0-Ry
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:06:43 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4907b7d2-bc99-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 18:06:41 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-a9a0ec0a94fso867686966b.1
 for ; Tue, 17 Dec 2024 09:06:41 -0800 (PST)
Received: from carlo-ubuntu.home.arpa
 (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab963910f7sm461362666b.166.2024.12.17.09.06.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 09:06: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: 4907b7d2-bc99-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734455201; x=1735060001; 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=vOKqlNthTDOE+oYLNQY9UFtYi227lhBRw4zHWIQH4gU=;
        b=P4N7lEI8Z2fLldaMvZaPfVWWO9XKTdc1SedGircjij5NNldgu9nAd2gPYOurHP5yXU
         Swdwr4kMpnal85rDsKJzyJb8GOBZWGVEcQXzuakJ/iTt2cJaIpoXwrKLLZH5Y0Apom40
         Ixaa/wu4uBSkdMdWajDFtsbhzPET9ai9mkKFFhWeW/t6Spx76x1IsmLwe+woIXJNUdc6
         r51yeH1Piwr84LQfxIRZpfDUhIi4kglC7nBYRRTO8uY/l5OvnEsQbtjkL3UpVL4zSB6b
         xa3SewqZYvroDOmKXDaEUUcMpIHpffskiKQm73+fkR8a3dUxKA9JnMP4i/HjH/HONwVs
         jcIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734455201; x=1735060001;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=vOKqlNthTDOE+oYLNQY9UFtYi227lhBRw4zHWIQH4gU=;
        b=ZBsoFgU6Uu9dvppt5AbehgpR7NL2zOctqkS4zKR+hIp5lvz44pZjBtc+U3ymRY8Rjx
         gV9U3M1omgeoYRkTzc1Zy7wQ+Fr60jf5EvJKpoYeV3wOtEQ0zY6/3eqJ5X64Gb/1MkHV
         XgU81AUfGGZ35pLfbz2xp2Mlcm4wD2/CoruJgcQRzAETj9giEvqkWFhUkVyyoFvWGFtl
         N7DoM2iLWaw3jBRExpu5CLjG4hVm0mQ/K4wyis/F2Az9bQDB/uQ24PSo4GSBPSjCvs5m
         y+ur4S2Ptt7BYN1gTEGNF1CbWTSigYnWZZ7yuuTcODLsa1Ao+pJVbAu1J1IoSxS3ZBj4
         HiIA==
X-Gm-Message-State: AOJu0YxXI2/FmhnOZxvaYN4UOTwk9mzRd52d7EygYQkln0iUp0/i1t5K
	fRO+j+n5htWGH94TIbWYdWKerd5fEUrJeZAG8IhsKkNEzoq91tAnNc0m9q7yBNYZXOB3/7UdsvJ
	Fnpk=
X-Gm-Gg: ASbGncvYBbAubGUw2MOkfK0ga2MacKA/Y/GfENja3BN/MBaX69aFtXmRRTIa3QcMl3u
	f5J+iTOjNZ3fD2NeCDP4IY/UWSWuj+bp0uCvmr0IUW1ZhLk9+qvFLNMxWbDn9DnAYNYfUhjqZmp
	m5x8qmcsLqroDV3SZWiShmVdSRRz+T4SnQOU0inKK08uDWCt+LKC/Ezz2miFajtPOc/3UyIk24z
	171/tfEqULwjf3Ybnh9Xs8N2f8fv36KgqFCAW1f31jwgkaByiMRldEm5OJ+zHQHncza9dB4OJ8F
	TPtIARIwfCg6keJpqZyhCPmR5qK5pFGDtJe6M73A58d9IxC+qBCM0Unhe4A=
X-Google-Smtp-Source: AGHT+IF3l4DsQWO7H9atQie2iK8cRV2i2eoJ2expI+32jW/kzjlCeDV1gnv66hit9cxWWrN8lExIxw==
X-Received: by 2002:a17:907:3e9f:b0:aa6:8a1b:8b7c with SMTP id a640c23a62f3a-aab778be690mr1609501666b.2.1734455200579;
        Tue, 17 Dec 2024 09:06:40 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Volodymyr Babchuk ,
	Nick Rosbrook ,
	George Dunlap ,
	Juergen Gross 
Subject: [PATCH v13 00/12] Arm cache coloring
Date: Tue, 17 Dec 2024 18:06:25 +0100
Message-ID: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Shared caches in multi-core CPU architectures represent a problem for
predictability of memory access latency. This jeopardizes applicability
of many Arm platform in real-time critical and mixed-criticality
scenarios. We introduce support for cache partitioning with page
coloring, a transparent software technique that enables isolation
between domains and Xen, and thus avoids cache interference.

When creating a domain, a simple syntax (e.g. `0-3` or `4-11`) allows
the user to define assignments of cache partitions ids, called colors,
where assigning different colors guarantees no mutual eviction on cache
will ever happen. This instructs the Xen memory allocator to provide
the i-th color assignee only with pages that maps to color i, i.e. that
are indexed in the i-th cache partition.

The proposed implementation supports the dom0less feature.
The proposed implementation doesn't support the static-mem feature.
The solution has been tested in several scenarios, including Xilinx Zynq
MPSoCs.

Carlo Nonato (11):
  xen/common: add cache coloring common code
  xen/arm: add initial support for LLC coloring on arm64
  xen/arm: permit non direct-mapped Dom0 construction
  xen/arm: add Dom0 cache coloring support
  xen: extend domctl interface for cache coloring
  tools: add support for cache coloring configuration
  xen/arm: add support for cache coloring configuration via device-tree
  xen/page_alloc: introduce preserved page flags macro
  xen: add cache coloring allocator for domains
  xen/arm: make consider_modules() available for xen relocation
  xen/arm: add cache coloring support for Xen image

Luca Miccio (1):
  xen/arm: add Xen cache colors command line parameter

 SUPPORT.md                              |   7 +
 docs/index.rst                          |   1 +
 docs/man/xl.cfg.5.pod.in                |   6 +
 docs/misc/arm/device-tree/booting.txt   |   5 +
 docs/misc/cache-coloring.rst            | 248 +++++++++++++++
 docs/misc/xen-command-line.pandoc       |  72 +++++
 tools/golang/xenlight/helpers.gen.go    |  16 +
 tools/golang/xenlight/types.gen.go      |   1 +
 tools/include/libxl.h                   |   5 +
 tools/include/xenctrl.h                 |   9 +
 tools/libs/ctrl/xc_domain.c             |  34 ++
 tools/libs/light/libxl_create.c         |  18 ++
 tools/libs/light/libxl_types.idl        |   1 +
 tools/xl/xl_parse.c                     |  38 ++-
 xen/arch/arm/Kconfig                    |   1 +
 xen/arch/arm/Makefile                   |   1 +
 xen/arch/arm/alternative.c              |  26 +-
 xen/arch/arm/arm32/mmu/mm.c             |  95 +-----
 xen/arch/arm/arm64/mmu/head.S           |  58 +++-
 xen/arch/arm/arm64/mmu/mm.c             |  34 ++
 xen/arch/arm/dom0less-build.c           |  60 +---
 xen/arch/arm/domain_build.c             | 165 +++++++++-
 xen/arch/arm/include/asm/domain_build.h |   1 +
 xen/arch/arm/include/asm/mm.h           |   5 +
 xen/arch/arm/include/asm/mmu/layout.h   |   3 +
 xen/arch/arm/include/asm/mmu/mm.h       |   1 +
 xen/arch/arm/include/asm/processor.h    |  15 +
 xen/arch/arm/include/asm/setup.h        |   3 +
 xen/arch/arm/llc-coloring.c             | 142 +++++++++
 xen/arch/arm/mmu/setup.c                | 201 +++++++++++-
 xen/arch/arm/setup.c                    |  13 +-
 xen/common/Kconfig                      |  29 ++
 xen/common/Makefile                     |   1 +
 xen/common/domain.c                     |   3 +
 xen/common/domctl.c                     |  10 +
 xen/common/keyhandler.c                 |   3 +
 xen/common/llc-coloring.c               | 393 ++++++++++++++++++++++++
 xen/common/page_alloc.c                 | 200 +++++++++++-
 xen/include/public/domctl.h             |   9 +
 xen/include/xen/llc-coloring.h          |  65 ++++
 xen/include/xen/sched.h                 |   5 +
 xen/include/xen/xmalloc.h               |  12 +
 42 files changed, 1846 insertions(+), 169 deletions(-)
 create mode 100644 docs/misc/cache-coloring.rst
 create mode 100644 xen/arch/arm/llc-coloring.c
 create mode 100644 xen/common/llc-coloring.c
 create mode 100644 xen/include/xen/llc-coloring.h

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:06:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:06:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859578.1271736 (Exim 4.92)
	(envelope-from )
	id 1tNb21-0007Do-FF; Tue, 17 Dec 2024 17:06:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859578.1271736; Tue, 17 Dec 2024 17:06:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNb21-0007Ao-7a; Tue, 17 Dec 2024 17:06:49 +0000
Received: by outflank-mailman (input) for mailman id 859578;
 Tue, 17 Dec 2024 17:06: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 1tNb20-0006B0-99
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:06:48 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4cb1fec7-bc99-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 18:06:47 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-aa6aad76beeso774557266b.2
 for ; Tue, 17 Dec 2024 09:06:47 -0800 (PST)
Received: from carlo-ubuntu.home.arpa
 (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab963910f7sm461362666b.166.2024.12.17.09.06.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 09:06: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: 4cb1fec7-bc99-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734455207; x=1735060007; 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=PKbMPc6hxIrj5w4kArM2ZAdbV73PCxtXLWMN/R1bwd0=;
        b=j8HzRT3z281SXi1UQbLirdumsLBSd7RWl/fNxUn4JCMxpzfh4Zn1bSvFHAstDGkIpC
         lhvz4/qWBXH/9WGIo2eVrGcpqrErFKSpP+fCEWMqeYAaKclfLmRik9+NazGlOkhpvEDa
         UaKn23dykypgqrDkjtLKZtuAKSHjKKaQbP84TnMiwD4rsSqQUsWMlBH1EgB82RrM2paE
         EX5opxpzdnAnUtQaUMY1ubAXY5EkCqGG13uRxebV+BjMI1dclQ5x6O7GDssyJ9DL/TW2
         0wWOUgJ30MNq+gulbPXDoRQsQio6uiuT4fZKm8P9h39m6DR3qp2BL0d0olmYYguCpss1
         xL9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734455207; x=1735060007;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=PKbMPc6hxIrj5w4kArM2ZAdbV73PCxtXLWMN/R1bwd0=;
        b=qlxFFSv7SbKWGP32HYKSb8mXzETxPmfOquiqksM/0lrikMu5MQZs5NB7/gV6P9Bvm0
         fNF72z2Fn2Dz0W8P0j4wOxJjrG6EGsGY9GPBbxl4JCqYdKrlaqCIulaRghf9rML0a4lV
         /3iAffmDvFLPktplEtfb8Ro8aGMeKnbQsSoI2i78uWzzQSGS2wMD/OS4AfcR/vi4dG9K
         dzy4rIXhx+DBQKHe6AYeQIyZvoPSXXtlo2EApu4f6cCbRXMq/DIu1KxxaUK0QqE5Y16K
         qsqknpChJEdQislccHyRMvF2GkyagpnxfkbGTdBB+gPyV/KupyldComfCe4YUGrOI3oq
         Da9w==
X-Gm-Message-State: AOJu0YyeLK7rGlWSXSOYRAA3hBy94u4jCRn4M/7b4kzER0jEhRAy2qxM
	Q2pHpxcCf9mTGYsuZAXRVAffi5h7ZSguHg71Fz91XgYDalCvfNWf8FWZ/53X+JMzk99sXBnW2jt
	un5g=
X-Gm-Gg: ASbGncsNT45nhPZDBvQaWa3O2JzI/bDQ0ERQNJ7LRN35j1tnD9QhCYT0k9ZDd6o7uGy
	lfm5AW+vHtYJHuUVF2I5sDrH5mc/G52KQMacHFqjyt7UlEO8qtTR3/L1Hn+RirDPWV4MDTDiHuw
	I0/Udx8BLx6nFFLJPYV/5Z4bNE+rXyvippq2QipvMUNkWPhtNe2BRj9OTZlSJcM+RNJjOhdgs3P
	v7iwi2/1drY9PWkz7mZ7dPXjv91rr9dpDXctC948ntsOVH9+5yTyklQbdFeIGg+Nybs1XgYUcHf
	z1LGj1G3aHumWPRHsn0viuhFpYMm/sWgy2Dm37pvv1RRNLEFR8lj1SztFvc=
X-Google-Smtp-Source: AGHT+IHxCmEWT1kjMcnNxE37KiANdTmbauEYGd7bI0JIgofbcW4hN4PsjcB7cmjsji5zjQocsURLtg==
X-Received: by 2002:a17:907:6d12:b0:aab:9607:b6b1 with SMTP id a640c23a62f3a-aabf1980db6mr11560966b.26.1734455206715;
        Tue, 17 Dec 2024 09:06:46 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Anthony PERARD ,
	Nick Rosbrook ,
	George Dunlap ,
	Juergen Gross 
Subject: [PATCH v13 06/12] tools: add support for cache coloring configuration
Date: Tue, 17 Dec 2024 18:06:31 +0100
Message-ID: <20241217170637.233097-7-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
References: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add a new "llc_colors" parameter that defines the LLC color assignment for
a domain. The user can specify one or more color ranges using the same
syntax used everywhere else for color config described in the
documentation.
The parameter is defined as a list of strings that represent the color
ranges.

Documentation is also added.
Golang bindings are regenerated.

Based on original work from: Luca Miccio 

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
Reviewed-by: Anthony PERARD 
---
v13:
- no changes
v12:
- no changes
v11:
- turned unsigned int to uint32_t in xc_domain_set_llc_colors()
- return -1 in case of error instead of ENOMEM in xc_domain_set_llc_colors()
- added regenerated go bindings
v10:
- no changes
v9:
- turned warning into error in case of coloring not enabled
v8:
- warn the user in case of coloring not supported at hypervisor level
v7:
- removed unneeded NULL check before xc_hypercall_buffer_free() in
  xc_domain_set_llc_colors()
v6:
- no edits
v5:
- added LIBXL_HAVE_BUILDINFO_LLC_COLORS
- moved color configuration in xc_domain_set_llc_colors() cause of the new
  hypercall
v4:
- removed overlapping color ranges checks during parsing
- moved hypercall buffer initialization in libxenctrl
---
 docs/man/xl.cfg.5.pod.in             |  6 +++++
 tools/golang/xenlight/helpers.gen.go | 16 ++++++++++++
 tools/golang/xenlight/types.gen.go   |  1 +
 tools/include/libxl.h                |  5 ++++
 tools/include/xenctrl.h              |  9 +++++++
 tools/libs/ctrl/xc_domain.c          | 34 +++++++++++++++++++++++++
 tools/libs/light/libxl_create.c      | 18 +++++++++++++
 tools/libs/light/libxl_types.idl     |  1 +
 tools/xl/xl_parse.c                  | 38 +++++++++++++++++++++++++++-
 9 files changed, 127 insertions(+), 1 deletion(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index ac3f88fd57..8e1422104e 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -3074,6 +3074,12 @@ raised.
 
 =over 4
 
+=item B
+
+Specify the Last Level Cache (LLC) color configuration for the guest.
+B can be either a single color value or a hypen-separated closed
+interval of colors (such as "0-4").
+
 =item B
 
 An optional integer parameter specifying the number of SPIs (Shared
diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go
index fe5110474d..90846ea8e8 100644
--- a/tools/golang/xenlight/helpers.gen.go
+++ b/tools/golang/xenlight/helpers.gen.go
@@ -1097,6 +1097,14 @@ if err := x.Iomem[i].fromC(&v); err != nil {
 return fmt.Errorf("converting field Iomem: %v", err) }
 }
 }
+x.LlcColors = nil
+if n := int(xc.num_llc_colors); n > 0 {
+cLlcColors := (*[1<<28]C.uint32_t)(unsafe.Pointer(xc.llc_colors))[:n:n]
+x.LlcColors = make([]uint32, n)
+for i, v := range cLlcColors {
+x.LlcColors[i] = uint32(v)
+}
+}
 if err := x.ClaimMode.fromC(&xc.claim_mode);err != nil {
 return fmt.Errorf("converting field ClaimMode: %v", err)
 }
@@ -1453,6 +1461,14 @@ return fmt.Errorf("converting field Iomem: %v", err)
 }
 }
 }
+if numLlcColors := len(x.LlcColors); numLlcColors > 0 {
+xc.llc_colors = (*C.uint32_t)(C.malloc(C.size_t(numLlcColors*numLlcColors)))
+xc.num_llc_colors = C.int(numLlcColors)
+cLlcColors := (*[1<<28]C.uint32_t)(unsafe.Pointer(xc.llc_colors))[:numLlcColors:numLlcColors]
+for i,v := range x.LlcColors {
+cLlcColors[i] = C.uint32_t(v)
+}
+}
 if err := x.ClaimMode.toC(&xc.claim_mode); err != nil {
 return fmt.Errorf("converting field ClaimMode: %v", err)
 }
diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go
index c9e45b306f..e7667f1ce3 100644
--- a/tools/golang/xenlight/types.gen.go
+++ b/tools/golang/xenlight/types.gen.go
@@ -575,6 +575,7 @@ SchedParams DomainSchedParams
 Ioports []IoportRange
 Irqs []uint32
 Iomem []IomemRange
+LlcColors []uint32
 ClaimMode Defbool
 EventChannels uint32
 Kernel string
diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index 8d32428ea9..f8fe4afd7d 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -1379,6 +1379,11 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, const libxl_mac *src);
  */
 #define LIBXL_HAVE_BUILDINFO_HVM_SYSTEM_FIRMWARE
 
+/*
+ * The libxl_domain_build_info has the llc_colors array.
+ */
+#define LIBXL_HAVE_BUILDINFO_LLC_COLORS 1
+
 /*
  * ERROR_REMUS_XXX error code only exists from Xen 4.5, Xen 4.6 and it
  * is changed to ERROR_CHECKPOINT_XXX in Xen 4.7
diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 29617585c5..d6d93a2e8f 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -2667,6 +2667,15 @@ int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t timeout, uint32
 int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
                          xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
 
+/*
+ * Set LLC colors for a domain.
+ * It can only be used directly after domain creation. An attempt to use it
+ * afterwards will result in an error.
+ */
+int xc_domain_set_llc_colors(xc_interface *xch, uint32_t domid,
+                             const uint32_t *llc_colors,
+                             uint32_t num_llc_colors);
+
 #if defined(__arm__) || defined(__aarch64__)
 int xc_dt_overlay(xc_interface *xch, void *overlay_fdt,
                   uint32_t overlay_fdt_size, uint8_t overlay_op);
diff --git a/tools/libs/ctrl/xc_domain.c b/tools/libs/ctrl/xc_domain.c
index e3538ec0ba..2ddc3f4f42 100644
--- a/tools/libs/ctrl/xc_domain.c
+++ b/tools/libs/ctrl/xc_domain.c
@@ -2195,6 +2195,40 @@ int xc_domain_soft_reset(xc_interface *xch,
     domctl.domain = domid;
     return do_domctl(xch, &domctl);
 }
+
+int xc_domain_set_llc_colors(xc_interface *xch, uint32_t domid,
+                             const uint32_t *llc_colors,
+                             uint32_t num_llc_colors)
+{
+    struct xen_domctl domctl = {};
+    DECLARE_HYPERCALL_BUFFER(uint32_t, local);
+    int ret = -1;
+
+    if ( num_llc_colors )
+    {
+        size_t bytes = sizeof(uint32_t) * num_llc_colors;
+
+        local = xc_hypercall_buffer_alloc(xch, local, bytes);
+        if ( local == NULL )
+        {
+            PERROR("Could not allocate LLC colors for set_llc_colors");
+            goto out;
+        }
+        memcpy(local, llc_colors, bytes);
+        set_xen_guest_handle(domctl.u.set_llc_colors.llc_colors, local);
+    }
+
+    domctl.cmd = XEN_DOMCTL_set_llc_colors;
+    domctl.domain = domid;
+    domctl.u.set_llc_colors.num_llc_colors = num_llc_colors;
+
+    ret = do_domctl(xch, &domctl);
+
+out:
+    xc_hypercall_buffer_free(xch, local);
+
+    return ret;
+}
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
index edeadd57ef..e03599ea99 100644
--- a/tools/libs/light/libxl_create.c
+++ b/tools/libs/light/libxl_create.c
@@ -747,6 +747,24 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
             /* A new domain now exists */
             *domid = local_domid;
 
+            ret = xc_domain_set_llc_colors(ctx->xch, local_domid,
+                                           b_info->llc_colors,
+                                           b_info->num_llc_colors);
+            if (ret < 0) {
+                if (errno == EOPNOTSUPP) {
+                    if (b_info->num_llc_colors > 0) {
+                        LOGED(ERROR, local_domid,
+                            "LLC coloring not enabled in the hypervisor");
+                        rc = ERROR_FAIL;
+                        goto out;
+                    }
+                } else {
+                    LOGED(ERROR, local_domid, "LLC colors allocation failed");
+                    rc = ERROR_FAIL;
+                    goto out;
+                }
+            }
+
             rc = libxl__is_domid_recent(gc, local_domid, &recent);
             if (rc)
                 goto out;
diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl
index 4e65e6fda5..bd4b8721ff 100644
--- a/tools/libs/light/libxl_types.idl
+++ b/tools/libs/light/libxl_types.idl
@@ -616,6 +616,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("ioports",          Array(libxl_ioport_range, "num_ioports")),
     ("irqs",             Array(uint32, "num_irqs")),
     ("iomem",            Array(libxl_iomem_range, "num_iomem")),
+    ("llc_colors",       Array(uint32, "num_llc_colors")),
     ("claim_mode",	     libxl_defbool),
     ("event_channels",   uint32),
     ("kernel",           string),
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index e3a4800f6e..3d85be7dd4 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -1296,7 +1296,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;
+                   *mca_caps, *smbios, *llc_colors;
     int num_ioports, num_irqs, num_iomem, num_cpus, num_viridian, num_mca_caps;
     int num_smbios;
     int pci_power_mgmt = 0;
@@ -1304,6 +1304,7 @@ void parse_config_data(const char *config_source,
     int pci_permissive = 0;
     int pci_seize = 0;
     int i, e;
+    int num_llc_colors;
     char *kernel_basename;
 
     libxl_domain_create_info *c_info = &d_config->c_info;
@@ -1447,6 +1448,41 @@ void parse_config_data(const char *config_source,
     if (!xlu_cfg_get_long (config, "maxmem", &l, 0))
         b_info->max_memkb = l * 1024;
 
+    if (!xlu_cfg_get_list(config, "llc_colors", &llc_colors, &num_llc_colors, 0)) {
+        int cur_index = 0;
+
+        b_info->num_llc_colors = 0;
+        for (i = 0; i < num_llc_colors; i++) {
+            uint32_t start = 0, end = 0, k;
+
+            buf = xlu_cfg_get_listitem(llc_colors, i);
+            if (!buf) {
+                fprintf(stderr,
+                        "xl: Can't get element %d in LLC color list\n", i);
+                exit(1);
+            }
+
+            if (sscanf(buf, "%" SCNu32 "-%" SCNu32, &start, &end) != 2) {
+                if (sscanf(buf, "%" SCNu32, &start) != 1) {
+                    fprintf(stderr, "xl: Invalid LLC color range: %s\n", buf);
+                    exit(1);
+                }
+                end = start;
+            } else if (start > end) {
+                fprintf(stderr,
+                        "xl: Start LLC color is greater than end: %s\n", buf);
+                exit(1);
+            }
+
+            b_info->num_llc_colors += (end - start) + 1;
+            b_info->llc_colors = (uint32_t *)realloc(b_info->llc_colors,
+                        sizeof(*b_info->llc_colors) * b_info->num_llc_colors);
+
+            for (k = start; k <= end; k++)
+                b_info->llc_colors[cur_index++] = k;
+        }
+    }
+
     if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         vcpus = l;
         if (libxl_cpu_bitmap_alloc(ctx, &b_info->avail_vcpus, l)) {
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:06:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:06:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859580.1271758 (Exim 4.92)
	(envelope-from )
	id 1tNb23-0007wa-SD; Tue, 17 Dec 2024 17:06:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859580.1271758; Tue, 17 Dec 2024 17:06: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 1tNb23-0007wM-LQ; Tue, 17 Dec 2024 17:06:51 +0000
Received: by outflank-mailman (input) for mailman id 859580;
 Tue, 17 Dec 2024 17:06: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 1tNb22-0006B0-22
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:06:50 +0000
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com
 [2a00:1450:4864:20::636])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4de667a8-bc99-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 18:06:49 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-aa689a37dd4so1053199566b.3
 for ; Tue, 17 Dec 2024 09:06:49 -0800 (PST)
Received: from carlo-ubuntu.home.arpa
 (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab963910f7sm461362666b.166.2024.12.17.09.06.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 09:06: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: 4de667a8-bc99-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734455209; x=1735060009; 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=TrreipUOqvu+e4eZhr8owwgZAEd1TzrMBSTgToeJEUs=;
        b=u5tVwYtQFHX0aTcLsu/aXOfStxknP2Af0R7Wi92nfYNeUDHIxpFSfW9gKVzMc2goAH
         wuUXan7318HACfcXb2fYQ0OxFHl59qdl8waAimMu3RcCMHjECA1+VuKSeod89SKjz/cP
         ICTI5MAQc01l5qjwSyyO7QGNxsEL6T4CHdJOZtYnyh86q6B77xkLOqspWEBcxb6WX+0S
         sySpJknP1oMi5lonnYj1Su7GO7ALwIJaDZ1NFmnBBCUMm36gAywvg3yvsb64DqDubUJ0
         2S9uPsU7F4lR7OSnSgCLxzTB9SVSAjuEQoBIMaS0m1FXG1nWOtXh0nr7IV3Yhk/WyCtH
         fXTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734455209; x=1735060009;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=TrreipUOqvu+e4eZhr8owwgZAEd1TzrMBSTgToeJEUs=;
        b=ODNbS5mf4AjbkPVUjGayu2g+38JANRpL1np7CtCVMbGHUwgmXjg4KpwtMq51zNnlLy
         rMda/nizn11NH9nT/lHQe6XyY7p9Md1zydFa+idcnX8e6CjADSBE2og6JPnqYig+y5/U
         7ae2iCvP7F/Gd2I45LegYPYrQ+hJEJew8OsXoaYQXF5FOOFzuCajp1M2wEI36xQ+4nr/
         ktgMe7IpDkMrSfw7LloSaPYSAtlQqsMOEJf2QDKLPQ6I6hjYqdfW+67GbmbSEIdhFEwQ
         lv8MB0Ewh1x07imWUBxI+Djo3thcA/HwqJQIrJIGjKCV49rEclY6zkNw0bRujw75rcCc
         qvSQ==
X-Gm-Message-State: AOJu0YwidKP2XkGC8JD1Lu1zuY0h6+LoWKQyLg2LPV/ufxoWbfwrYAvn
	EEFZm7eH3XBhMzZXYEpm4esNGNeOafl2wTAmVQTjE228jmyKSgec+Ia+s/WMGEld+uGPsIT/6ky
	Q+p4=
X-Gm-Gg: ASbGncsQ69F5bUj8miI/DZGU0KAZJZ0z5dtTkLz+Wvq5K69jRnYGS6/fWon98SS7rUH
	uNIBh7o+Fyfrs6KY9BFJP4d8H8ojYZ3tN8/hGpAuGv3mBdp7QPhRsSwdBC5X+RG9mZDnmuH+N9O
	19fVvLmErrn4ylj3KBgxJVGcJEa6ySXlXb3TnzMhWDSQi2LoGBXAIMw7XIL6DzL7t4fyWMOpzgc
	kNdfccmtxlGOyyO/ULZpyCT67wl5t7L91IfYFgzccA3DBgjlxWwmLI2AUP4oS6xIf+p4XCuqutu
	Z2Gb7Inyx3+IMXWM63gYyd9adIV4UcRwYWtYCn8+P7g2/6GSuGyYzkCyTZA=
X-Google-Smtp-Source: AGHT+IFuCSa53dAt3X2uYHYt3kSIWw1yJmJ/rrSQ+FLSFp9jh3JwOm6m4Wkm74+jmHFUlcpIQOHKYA==
X-Received: by 2002:a17:906:23e1:b0:aa6:96be:2bed with SMTP id a640c23a62f3a-aab77ee8ae6mr1461073066b.59.1734455208785;
        Tue, 17 Dec 2024 09:06:48 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v13 08/12] xen/page_alloc: introduce preserved page flags macro
Date: Tue, 17 Dec 2024 18:06:33 +0100
Message-ID: <20241217170637.233097-9-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
References: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

PGC_static and PGC_extra need to be preserved when assigning a page.
Define a new macro that groups those flags and use it instead of or'ing
every time.

Signed-off-by: Carlo Nonato 
Reviewed-by: Jan Beulich 
---
v13:
- no changes
v12:
- fixed wrong patch sent in v11
- added comment on PGC_preserved
v11:
- removed PGC_broken from PGC_preserved
- removed PGC preservation from mark_page_free()
v10:
- fixed commit message
v9:
- add PGC_broken to PGC_preserved
- clear PGC_extra in alloc_domheap_pages() only if MEMF_no_refcount is set
v8:
- fixed PGC_extra ASSERT fail in alloc_domheap_pages() by removing PGC_extra
  before freeing
v7:
- PGC_preserved used also in mark_page_free()
v6:
- preserved_flags renamed to PGC_preserved
- PGC_preserved is used only in assign_pages()
v5:
- new patch
---
 xen/common/page_alloc.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index da505a79f6..6dc8e0d5c9 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -161,6 +161,10 @@
 #endif
 
 #define PGC_no_buddy_merge PGC_static
+/*
+ * Flags that are preserved in assign_pages() (and only there)
+ */
+#define PGC_preserved (PGC_extra | PGC_static)
 
 #ifndef PGT_TYPE_INFO_INITIALIZER
 #define PGT_TYPE_INFO_INITIALIZER 0
@@ -2385,7 +2389,7 @@ int assign_pages(
 
         for ( i = 0; i < nr; i++ )
         {
-            ASSERT(!(pg[i].count_info & ~(PGC_extra | PGC_static)));
+            ASSERT(!(pg[i].count_info & ~PGC_preserved));
             if ( pg[i].count_info & PGC_extra )
                 extra_pages++;
         }
@@ -2445,7 +2449,7 @@ int assign_pages(
         page_set_owner(&pg[i], d);
         smp_wmb(); /* Domain pointer must be visible before updating refcnt. */
         pg[i].count_info =
-            (pg[i].count_info & (PGC_extra | PGC_static)) | PGC_allocated | 1;
+            (pg[i].count_info & PGC_preserved) | PGC_allocated | 1;
 
         page_list_add_tail(&pg[i], page_to_list(d, &pg[i]));
     }
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:06:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:06:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859581.1271762 (Exim 4.92)
	(envelope-from )
	id 1tNb24-00080e-7A; Tue, 17 Dec 2024 17:06:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859581.1271762; Tue, 17 Dec 2024 17:06: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 1tNb24-0007z5-2G; Tue, 17 Dec 2024 17:06:52 +0000
Received: by outflank-mailman (input) for mailman id 859581;
 Tue, 17 Dec 2024 17:06: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 1tNb22-0006gw-Ag
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:06:50 +0000
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [2a00:1450:4864:20::532])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4d63f883-bc99-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 18:06:48 +0100 (CET)
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5d3d0205bd5so7902468a12.3
 for ; Tue, 17 Dec 2024 09:06:48 -0800 (PST)
Received: from carlo-ubuntu.home.arpa
 (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab963910f7sm461362666b.166.2024.12.17.09.06.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 09:06: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: 4d63f883-bc99-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734455208; x=1735060008; 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=vsljsmkJSCPil0FUckH5NAu8dI/+5ZLlI9O6PG7m0uw=;
        b=GuhN/j/LmgHJgbMtPKI9IsvW2pCvo2Xe7zPOkFcL0L5b2ldnj9zeFV0w3+ZbziFoj6
         a+B2RgRqMLKCm56gr8uKrorcAbwT4L6zNWmbk3CMFbKmjiVMSrNZD37OywVGQG51xtXl
         TQxdKexZVhXQjPQJuJST2IOvTwwYGYQVE7o41VFTuZWsMQqqm3hqm381fybDRFl0tcwK
         u7MEMEEiTENUQQcVavEqMuW2pVGlf2uY2sAeD/Oan7xEWuZKt2BIjTHJdeNm7dBcK+CY
         DmTeVn1CEly/J1lkAbf0IxeV2Mzj9FzcWzhX7w4TufRaj/D6yt7ci7UCwBTHezQm47oQ
         aiFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734455208; x=1735060008;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=vsljsmkJSCPil0FUckH5NAu8dI/+5ZLlI9O6PG7m0uw=;
        b=GISx5fy3kkcKovTJjCeWTt2x3mvRfqC1RrcnxA9w1v+YLCZNvl9RmdOkEYZfvdxRhT
         Be0QLXqDxsJaGaTI7x1Mo4bdCg90tLYGZKbixT12m4EoGOWuEDbm6GqZT8wz/HcnMWKi
         Cl9M1Afgw1ot1DwqgI4HgwS7BID+1B2q8e1uzc6hYU6/EWZbvhQbqWq3teFhCvlK90zN
         eyUWey185Exzw720OxY44dzjUExzP04uTSXXYrSZr9ivlH4okKn61rPBhzb3c1tucCnw
         1axPqwaGGhsDefvabVnCTtvnB7CLzK1XOMqCfG/1haKO0fymr27pahmJQqW7Qw/7p1vl
         JwUQ==
X-Gm-Message-State: AOJu0Yzcg0qHFy69ZGDqcQ1K8BY+Q2qaHIrqTV8020SyMr+JPjocxPBn
	uuDiKJb8lioDYapdnIYnOOeDODedU3k9YCF/sA01GZgYY7QhFU1YC+76Is2qoJ93LrgXHXHufyT
	GF2c=
X-Gm-Gg: ASbGncvEElxDXEBpt5mSwAJ8N7chmwudEZwjKN0ubdWHzb9Obti+KRCePHZEHp00W+f
	MUaEJLHRr23KhIESmSERkX1FDjUFqxHsdbBxNSvhCR2d2sjhJxSeuZCG06ApVOiuRYLN5OYrnXg
	BYO4qGrEvp6ZD8iEC2s3SUVL37TO+o6ilXDbYYUwyGzhl23vMeUy+Yj+inI9/dzQZFBG8yaGyZL
	4uJrY5+6dUScHSlPUnGj6I9UnopLet/raPBIceg5e4Bi4GceCbkCUzmoyyJN9upBV5fKSafPpyQ
	/u3LXPkHu9NXgU/xsCp3tq4jkk+M6Ph1FvUD3NcGCDL/AT5GCoGuWAOCFaA=
X-Google-Smtp-Source: AGHT+IFGVoSRTy2RFPUBcqn7vq+gbGl6ReZMS0vT3I2961MFB8rp3RC9M1kHq5f65lA6Btxnmmqa7g==
X-Received: by 2002:a17:907:3f1b:b0:aa6:7165:504b with SMTP id a640c23a62f3a-aab779b3ff3mr2029549166b.31.1734455207774;
        Tue, 17 Dec 2024 09:06:47 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v13 07/12] xen/arm: add support for cache coloring configuration via device-tree
Date: Tue, 17 Dec 2024 18:06:32 +0100
Message-ID: <20241217170637.233097-8-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
References: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add the "llc-colors" Device Tree property to express DomUs and Dom0less
color configurations.

Based on original work from: Luca Miccio 

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
Reviewed-by: Jan Beulich  # non-Arm
Reviewed-by: Michal Orzel 
---
v13:
- no changes
v12:
- no changes
v11:
- made clear that llc-colors device-tree property is Arm64-only in booting.txt
v10:
- no changes
v9:
- use best-effort allocation in domain_set_llc_colors_from_str()
v8:
- fixed memory leak on error path of domain_set_llc_colors_from_str()
- realloc colors array after parsing from string to reduce memory usage
v7:
- removed alloc_colors() helper usage from domain_set_llc_colors_from_str()
v6:
- rewrote domain_set_llc_colors_from_str() to be more explicit
v5:
- static-mem check has been moved in a previous patch
- added domain_set_llc_colors_from_str() to set colors after domain creation
---
 docs/misc/arm/device-tree/booting.txt |  5 +++
 docs/misc/cache-coloring.rst          | 48 +++++++++++++++++++++++++++
 xen/arch/arm/dom0less-build.c         | 10 ++++++
 xen/common/llc-coloring.c             | 40 ++++++++++++++++++++++
 xen/include/xen/llc-coloring.h        |  1 +
 xen/include/xen/xmalloc.h             | 12 +++++++
 6 files changed, 116 insertions(+)

diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
index 3a04f5c57f..9c881baccc 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -162,6 +162,11 @@ with the following properties:
 
     An integer specifying the number of vcpus to allocate to the guest.
 
+- llc-colors
+    A string specifying the LLC color configuration for the guest.
+    Refer to docs/misc/cache_coloring.rst for syntax. This option is applicable
+    only to Arm64 guests.
+
 - vpl011
 
     An empty property to enable/disable a virtual pl011 for the guest to
diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
index 7b47d0ed92..e097e74032 100644
--- a/docs/misc/cache-coloring.rst
+++ b/docs/misc/cache-coloring.rst
@@ -14,6 +14,7 @@ If needed, change the maximum number of colors with
 ``CONFIG_LLC_COLORS_ORDER=``.
 
 Runtime configuration is done via `Command line parameters`_.
+For DomUs follow `DomUs configuration`_.
 
 Background
 **********
@@ -149,6 +150,53 @@ LLC specs can be manually set via the above command line parameters. This
 bypasses any auto-probing and it's used to overcome failing situations, such as
 flawed probing logic, or for debugging/testing purposes.
 
+DomUs configuration
+*******************
+
+DomUs colors can be set either in the ``xl`` configuration file (documentation
+at `docs/man/xl.cfg.pod.5.in`) or via Device Tree (documentation at
+`docs/misc/arm/device-tree/booting.txt`) using the ``llc-colors`` option.
+For example:
+
+::
+
+    xen,xen-bootargs = "console=dtuart dtuart=serial0 dom0_mem=1G dom0_max_vcpus=1 sched=null llc-coloring=on dom0-llc-colors=2-6";
+    xen,dom0-bootargs "console=hvc0 earlycon=xen earlyprintk=xen root=/dev/ram0"
+
+    dom0 {
+        compatible = "xen,linux-zimage" "xen,multiboot-module";
+        reg = <0x0 0x1000000 0x0 15858176>;
+    };
+
+    dom0-ramdisk {
+        compatible = "xen,linux-initrd" "xen,multiboot-module";
+        reg = <0x0 0x2000000 0x0 20638062>;
+    };
+
+    domU0 {
+        #address-cells = <0x1>;
+        #size-cells = <0x1>;
+        compatible = "xen,domain";
+        memory = <0x0 0x40000>;
+        llc-colors = "4-8,10,11,12";
+        cpus = <0x1>;
+        vpl011 = <0x1>;
+
+        module@2000000 {
+            compatible = "multiboot,kernel", "multiboot,module";
+            reg = <0x2000000 0xffffff>;
+            bootargs = "console=ttyAMA0";
+        };
+
+        module@30000000 {
+            compatible = "multiboot,ramdisk", "multiboot,module";
+            reg = <0x3000000 0xffffff>;
+        };
+    };
+
+**Note:** If no color configuration is provided for a domain, the default one,
+which corresponds to all available colors is used instead.
+
 Known issues and limitations
 ****************************
 
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
index 67b1503647..49d1f14d65 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch/arm/dom0less-build.c
@@ -817,6 +817,7 @@ void __init create_domUs(void)
     bool iommu = false;
     const struct dt_device_node *cpupool_node,
                                 *chosen = dt_find_node_by_path("/chosen");
+    const char *llc_colors_str = NULL;
 
     BUG_ON(chosen == NULL);
     dt_for_each_child_node(chosen, node)
@@ -965,6 +966,10 @@ void __init create_domUs(void)
 #endif
         }
 
+        dt_property_read_string(node, "llc-colors", &llc_colors_str);
+        if ( !llc_coloring_enabled && llc_colors_str )
+            panic("'llc-colors' found, but LLC coloring is disabled\n");
+
         /*
          * The variable max_init_domid is initialized with zero, so here it's
          * very important to use the pre-increment operator to call
@@ -975,6 +980,11 @@ void __init create_domUs(void)
             panic("Error creating domain %s (rc = %ld)\n",
                   dt_node_name(node), PTR_ERR(d));
 
+        if ( llc_coloring_enabled &&
+             (rc = domain_set_llc_colors_from_str(d, llc_colors_str)) )
+            panic("Error initializing LLC coloring for domain %s (rc = %d)\n",
+                  dt_node_name(node), rc);
+
         d->is_console = true;
         dt_device_set_used_by(node, d->domain_id);
 
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index 3dd1aaa4df..5a0e3bac59 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -282,6 +282,46 @@ void domain_llc_coloring_free(struct domain *d)
     xfree(__va(__pa(d->llc_colors)));
 }
 
+int __init domain_set_llc_colors_from_str(struct domain *d, const char *str)
+{
+    int err;
+    unsigned int *colors, num_colors;
+
+    if ( !str )
+    {
+        domain_set_default_colors(d);
+        return 0;
+    }
+
+    colors = xmalloc_array(unsigned int, max_nr_colors);
+    if ( !colors )
+        return -ENOMEM;
+
+    err = parse_color_config(str, colors, max_nr_colors, &num_colors);
+    if ( err )
+    {
+        printk(XENLOG_ERR "Error parsing LLC color configuration");
+        xfree(colors);
+        return err;
+    }
+
+    if ( !check_colors(colors, num_colors) )
+    {
+        printk(XENLOG_ERR "%pd: bad LLC color config\n", d);
+        xfree(colors);
+        return -EINVAL;
+    }
+
+    /* Adjust the size cause it was initially set to max_nr_colors */
+    d->llc_colors = xrealloc_array(colors, num_colors);
+    if ( !d->llc_colors )
+        d->llc_colors = colors;
+
+    d->num_llc_colors = num_colors;
+
+    return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
index 26353c808a..5d1355b3c9 100644
--- a/xen/include/xen/llc-coloring.h
+++ b/xen/include/xen/llc-coloring.h
@@ -34,6 +34,7 @@ void arch_llc_coloring_init(void);
 int dom0_set_llc_colors(struct domain *d);
 int domain_set_llc_colors(struct domain *d,
                           const struct xen_domctl_set_llc_colors *config);
+int domain_set_llc_colors_from_str(struct domain *d, const char *str);
 
 #endif /* __XEN_LLC_COLORING_H__ */
 
diff --git a/xen/include/xen/xmalloc.h b/xen/include/xen/xmalloc.h
index b903fa2e26..f0412fb4e0 100644
--- a/xen/include/xen/xmalloc.h
+++ b/xen/include/xen/xmalloc.h
@@ -37,6 +37,9 @@
     ((_type *)_xmalloc_array(sizeof(_type), __alignof__(_type), _num))
 #define xzalloc_array(_type, _num) \
     ((_type *)_xzalloc_array(sizeof(_type), __alignof__(_type), _num))
+#define xrealloc_array(_ptr, _num)                                  \
+    ((typeof(_ptr))_xrealloc_array(_ptr, sizeof(typeof(*(_ptr))),   \
+                                   __alignof__(typeof(*(_ptr))), _num))
 
 /* Allocate space for a structure with a flexible array of typed objects. */
 #define xzalloc_flex_struct(type, field, nr) \
@@ -98,6 +101,15 @@ static inline void *_xzalloc_array(
     return _xzalloc(size * num, align);
 }
 
+static inline void *_xrealloc_array(
+    void *ptr, unsigned long size, unsigned long align, unsigned long num)
+{
+    /* Check for overflow. */
+    if ( size && num > UINT_MAX / size )
+        return NULL;
+    return _xrealloc(ptr, size * num, align);
+}
+
 /*
  * Pooled allocator interface.
  */
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:06:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:06:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859585.1271777 (Exim 4.92)
	(envelope-from )
	id 1tNb25-0008TY-Te; Tue, 17 Dec 2024 17:06:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859585.1271777; Tue, 17 Dec 2024 17:06: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 1tNb25-0008Rw-Mh; Tue, 17 Dec 2024 17:06:53 +0000
Received: by outflank-mailman (input) for mailman id 859585;
 Tue, 17 Dec 2024 17:06: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 1tNb24-0006B0-Bg
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:06:52 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4f2c7e7a-bc99-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 18:06:51 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-aa67333f7d2so827497566b.0
 for ; Tue, 17 Dec 2024 09:06:51 -0800 (PST)
Received: from carlo-ubuntu.home.arpa
 (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab963910f7sm461362666b.166.2024.12.17.09.06.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 09:06: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: 4f2c7e7a-bc99-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734455211; x=1735060011; 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=+yFCjWByWBlLWohsvm0nzKlA6dcBQUEk8oUoZi9smWw=;
        b=ygsN4MQQdbZFfzJamLemuXmUg4Jtk0YHJLsPDcPLVBA1CsQPkNBgacxd9txHiiGVlZ
         1Q7XU/oziZHE8gW3pt/zqoE/9dymbAmHAj30Hlv99ugO1tQDVyLBEJHGiYzLXgujQxTZ
         3eS0EE3lF6qTESR2LsNsnpcIhcIHscgtO/iKSCcICyTkYJ4ebCJumCFKRcHI3Q3rwIsa
         OMWp+ouqtSUHUaiMYN0ltnvnvt4iL9h8fVtLkLJ8IVm98H7WDiXuaqvubQs6hTP0GaTM
         EjRE6Vv1XKBQG2GQWb5p8O+SVWc9s5Qv0xgckk8Tp8f1HP8lQlOjooiVuDVPO7uSDxFm
         hTew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734455211; x=1735060011;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=+yFCjWByWBlLWohsvm0nzKlA6dcBQUEk8oUoZi9smWw=;
        b=komAIIYbmppXpXuz50F5Hk2W53XEnXaX9cLDVdQp3PluK5UQCa66yWjhv+l7OfR8YT
         8BmYJ/ydLSYbf+yjdEvRhE7sYwnyfyR6EAu+uhYJzFd0L6lO/1Pk50SMUG/Jhd5nHvfy
         u1E/C63zGJJOdhVKuLtVWTAbztC9tVYkK9T7ztFQDx+87hVqj1MhKoXNsBOxe6FhxVWR
         e2MOyMqC1LzJEF7cq6YQXNENKxqQ4glqSPkQfu2/G9UaW4iUe6g2AoW0Omkey+pXEZRQ
         HUuOWoYSzqMyZAUYPj0t4sh8KAd6YkquVCm2c0r1kTWssUj+I8YXXeAj9fmNJGpDnqAn
         g3gA==
X-Gm-Message-State: AOJu0YyREIHe8Eu0OTRIZu0S4zZB16Z7OIgutMJPwJ6D+Z/RStJq52Ru
	DTOUMU63mS50A97VQPGdNyLYbw5KWIzP2Uj+JqrcG700oP/tjQyOup7bMPUFGBIrHFJ+ep2lf+7
	nfMw=
X-Gm-Gg: ASbGncv1idgT3CDKCtk5WRaMlraNU51Q+0TirWnmCtgIXEqJrRNXmtbEeIingXxngwf
	Lr1HLtI+l53bC4iusq/05Xe7zuBtFr2VlB3w3pSPCM3x8RDXcifCbxddTAsQxHhieP2Ymf8hxdv
	6siwChG/U3MVQIzU7FQQFN6VU97OLj/uXB6QL9bMX0dwLThN9XKwPA8EqhG9AlHQgrs8hPV9pjh
	P8KgsDt1SMLJ8K2yKuEFwZSWiO+dBUkAegRhX+3ecFXZZCW6F6H026NXJgFtJ4d8W0SZvjDgsUv
	dXCf0nYm/Nf0Bzu57BvW6k1Oyq+ntHJGzKVztQuhNJ+bp99ml3pV85f3ixI=
X-Google-Smtp-Source: AGHT+IHABKJ8nQpchEGx4HHrgDQ1znx3h1yf5DTmFdzEj9pREyPSZ0pPO4Cj5rldUVQkqa0/rsr9zQ==
X-Received: by 2002:a17:907:d24:b0:aa6:6b7c:8a62 with SMTP id a640c23a62f3a-aabf1c8552emr9481566b.38.1734455210924;
        Tue, 17 Dec 2024 09:06:50 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Luca Miccio ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Carlo Nonato 
Subject: [PATCH v13 10/12] xen/arm: add Xen cache colors command line parameter
Date: Tue, 17 Dec 2024 18:06:35 +0100
Message-ID: <20241217170637.233097-11-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
References: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Luca Miccio 

Add a new command line parameter to configure Xen cache colors.
These colors are dumped together with other coloring info.

Benchmarking the VM interrupt response time provides an estimation of
LLC usage by Xen's most latency-critical runtime task. Results on Arm
Cortex-A53 on Xilinx Zynq UltraScale+ XCZU9EG show that one color, which
reserves 64 KiB of L2, is enough to attain best responsiveness:
- Xen 1 color latency:  3.1 us
- Xen 2 color latency:  3.1 us

Since this is the most common target for Arm cache coloring, the default
amount of Xen colors is set to one.

More colors are instead very likely to be needed on processors whose L1
cache is physically-indexed and physically-tagged, such as Cortex-A57.
In such cases, coloring applies to L1 also, and there typically are two
distinct L1-colors. Therefore, reserving only one color for Xen would
senselessly partitions a cache memory that is already private, i.e.
underutilize it.

Signed-off-by: Luca Miccio 
Signed-off-by: Marco Solieri 
Signed-off-by: Carlo Nonato 
Reviewed-by: Jan Beulich 
---
v13:
- no changes
v12:
- no changes
v11:
- no changes
v10:
- no changes
v9:
- no changes
v8:
- added bound check on xen_colors in llc_coloring_init()
v7:
- removed XEN_DEFAULT_COLOR
- XEN_DEFAULT_NUM_COLORS is now used in a for loop to set xen default colors
---
 docs/misc/cache-coloring.rst      |  2 ++
 docs/misc/xen-command-line.pandoc | 10 ++++++++++
 xen/common/llc-coloring.c         | 29 +++++++++++++++++++++++++++++
 3 files changed, 41 insertions(+)

diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
index 5224b27afe..e156062aa2 100644
--- a/docs/misc/cache-coloring.rst
+++ b/docs/misc/cache-coloring.rst
@@ -115,6 +115,8 @@ Specific documentation is available at `docs/misc/xen-command-line.pandoc`.
 +----------------------+-------------------------------+
 | ``buddy-alloc-size`` | Buddy allocator reserved size |
 +----------------------+-------------------------------+
+| ``xen-llc-colors``   | Xen color configuration       |
++----------------------+-------------------------------+
 
 Colors selection format
 ***********************
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index de5d68a452..4f1fde84df 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2925,6 +2925,16 @@ mode.
 **WARNING: `x2apic_phys` is deprecated and superseded by `x2apic-mode`.
 The latter takes precedence if both are set.**
 
+### xen-llc-colors (arm64)
+> `= List of [  | - ]`
+
+> Default: `0: the lowermost color`
+
+Specify Xen LLC color configuration. This options is available only when
+`CONFIG_LLC_COLORING` is enabled.
+Two colors are most likely needed on platforms where private caches are
+physically indexed, e.g. the L1 instruction cache of the Arm Cortex-A57.
+
 ### xenheap_megabytes (arm32)
 > `= `
 
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index bebd6e2056..0cfaa77a2b 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -13,6 +13,7 @@
 #include 
 
 #define NR_LLC_COLORS          (1U << CONFIG_LLC_COLORS_ORDER)
+#define XEN_DEFAULT_NUM_COLORS 1
 
 /*
  * -1: not specified (disabled unless llc-size and llc-nr-ways present)
@@ -36,6 +37,9 @@ static unsigned int __ro_after_init default_colors[NR_LLC_COLORS];
 static unsigned int __initdata dom0_colors[NR_LLC_COLORS];
 static unsigned int __initdata dom0_num_colors;
 
+static unsigned int __ro_after_init xen_colors[NR_LLC_COLORS];
+static unsigned int __ro_after_init xen_num_colors;
+
 #define mfn_color_mask              (max_nr_colors - 1)
 #define mfn_to_color(mfn)           (mfn_x(mfn) & mfn_color_mask)
 
@@ -94,6 +98,13 @@ static int __init parse_dom0_colors(const char *s)
 }
 custom_param("dom0-llc-colors", parse_dom0_colors);
 
+static int __init parse_xen_colors(const char *s)
+{
+    return parse_color_config(s, xen_colors, ARRAY_SIZE(xen_colors),
+                              &xen_num_colors);
+}
+custom_param("xen-llc-colors", parse_xen_colors);
+
 static void print_colors(const unsigned int colors[], unsigned int num_colors)
 {
     unsigned int i;
@@ -178,6 +189,22 @@ void __init llc_coloring_init(void)
     for ( i = 0; i < max_nr_colors; i++ )
         default_colors[i] = i;
 
+    if ( !xen_num_colors )
+    {
+        unsigned int i;
+
+        xen_num_colors = MIN(XEN_DEFAULT_NUM_COLORS, max_nr_colors);
+
+        printk(XENLOG_WARNING
+               "Xen LLC color config not found. Using first %u colors\n",
+               xen_num_colors);
+        for ( i = 0; i < xen_num_colors; i++ )
+            xen_colors[i] = i;
+    }
+    else if ( xen_num_colors > max_nr_colors ||
+              !check_colors(xen_colors, xen_num_colors) )
+        panic("Bad LLC color config for Xen\n");
+
     arch_llc_coloring_init();
 }
 
@@ -188,6 +215,8 @@ void dump_llc_coloring_info(void)
 
     printk("LLC coloring info:\n");
     printk("    Number of LLC colors supported: %u\n", max_nr_colors);
+    printk("    Xen LLC colors (%u): ", xen_num_colors);
+    print_colors(xen_colors, xen_num_colors);
 }
 
 void domain_dump_llc_colors(const struct domain *d)
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:06:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:06:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859586.1271783 (Exim 4.92)
	(envelope-from )
	id 1tNb26-00008L-FM; Tue, 17 Dec 2024 17:06:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859586.1271783; Tue, 17 Dec 2024 17:06: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 1tNb26-00006U-5y; Tue, 17 Dec 2024 17:06:54 +0000
Received: by outflank-mailman (input) for mailman id 859586;
 Tue, 17 Dec 2024 17:06: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 1tNb24-0006gw-PN
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:06:52 +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 4eb8922c-bc99-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 18:06:51 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3862ca8e0bbso4776832f8f.0
 for ; Tue, 17 Dec 2024 09:06:51 -0800 (PST)
Received: from carlo-ubuntu.home.arpa
 (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab963910f7sm461362666b.166.2024.12.17.09.06.48
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 09:06: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: 4eb8922c-bc99-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734455210; x=1735060010; 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=gl0EWK+FsqsA8S/JacV6oWuRXTqVhZbd3MTd0ok1lAk=;
        b=OqWc9TGVVVLWMl/pOgNjo8+SexQ8XMbiR9DHGARq5IxPiRFPi1OdB+H2OR3inqFEFo
         Z6UVJs8q4Y1+A0ypBZou4fiPeA4T0pfF86CD3W3H4rK8EJ2zXpwTsj04D5Jg8wmhpPc/
         QgSncnMt5zyn5psPFY9fHS/n/1MjhuuEHMGZGPwGWbCLufjUDOLHgIEd3RNdo0WYA2zU
         nNR/gqox2ih+cdx9Z076VKdXqS0qVwnjrbTDHeJrJUSdhLiMvrN+x3lpsuACyp/Kj13n
         JoPSo34XAFTBG+Hu81z4QSG4oP4mjJtOW/Svx5sAwiAjep7S6xLznJ/ZDn187UUVTyRi
         H7bQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734455210; x=1735060010;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=gl0EWK+FsqsA8S/JacV6oWuRXTqVhZbd3MTd0ok1lAk=;
        b=mmXRJk5rW1LZCGtoIyYDTRCRyadmOm22P+Wyn8SEpblgg/WaViwTOp80Uw6Pv4cnUV
         UYSk4NexR4uxf2w8BuqwMqmme2s3bMCq7ILNO11M5JDPgAvfTMD7po07AlNmYPQWSniZ
         bW7e+AKUAk+xda9Lp8W7ENXlnRNsZfVErrZj44C7byT2IEx9xggm5RiVgXw7HqwTf7tK
         zsP5lzXScFPoGEGBaKkl+aUbb4XrrF4gD3IknzH7/W1w6rl9ZVnqLe7DQpBtOM3iDStn
         TPwUK6R7cZztZLOvbgd3mt4KhF0EWbMRtGdIOHlpG3w/SQxrtHmbRXSSf7KgDhUw+Zj0
         Fo7g==
X-Gm-Message-State: AOJu0Yzo4VPYzNNtJWxloEd4to7qvYA9XSjYAPQVFg/mtzWOH5pAIDj7
	nhW+uZ9Tn8Ykz3PqfLkN0bV4KpSIKNohZ2wOScAUlxWl5sJC0hI/v4QWLC6w2ME4qbjRhvyI0nI
	dMuU=
X-Gm-Gg: ASbGnctPCAWmXke5huvMS35a//SgUi+ywA7Xfl0lSuNbw4UhMeAttYfaTvlEhVhhuv7
	wnl5EQgzI7x+NE6Vy+HWRKqEGd+zq1+Z+AI6HEc6RqQ2VT4hRXw1YJETWTtJrWhGMFwrTTyJmHz
	/hwdtNkgYnSE9aKS1IyfFfRql4cJzuP7VFMYtiiNyX8NDES+XNSdGtIHo3Vbz27Te7m1K0sUGSw
	0McYsDz15QnsfxrViyfl+Ogbupab0jDJptWSq/xJ2Gho7Dnm8lg7TyJi1brD+j1KmzBD5a4hBHM
	E5O/XPejyzgEDJTuSmQbn2EfDEMRdAvmUsukUFWAiWdKtW6v0MzFbGc4VMg=
X-Google-Smtp-Source: AGHT+IEA6MIhAvKEwTYcmgKvX7UoPESWauyCPfWXwAADDZ9H4qmQygfaiBWhcPFXfMEQVZCURopTVg==
X-Received: by 2002:a05:6000:4028:b0:385:e2d5:cdf2 with SMTP id ffacd0b85a97d-38880ad9012mr15621029f8f.19.1734455209858;
        Tue, 17 Dec 2024 09:06:49 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: [PATCH v13 09/12] xen: add cache coloring allocator for domains
Date: Tue, 17 Dec 2024 18:06:34 +0100
Message-ID: <20241217170637.233097-10-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
References: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add a new memory page allocator that implements the cache coloring mechanism.
The allocation algorithm enforces equal frequency distribution of cache
partitions, following the coloring configuration of a domain. This allows
for an even utilization of cache sets for every domain.

Pages are stored in a color-indexed array of lists. Those lists are filled
by a simple init function which computes the color of each page.
When a domain requests a page, the allocator extracts the page from the list
with the maximum number of free pages among those that the domain can access,
given its coloring configuration.

The allocator can only handle requests of order-0 pages. This allows for
easier implementation and since cache coloring targets only embedded systems,
it's assumed not to be a major problem.

The buddy allocator must coexist with the colored one because the Xen heap
isn't colored. For this reason a new Kconfig option and a command line
parameter are added to let the user set the amount of memory reserved for
the buddy allocator. Even when cache coloring is enabled, this memory
isn't managed by the colored allocator.

Colored heap information is dumped in the dump_heap() debug-key function.

Based on original work from: Luca Miccio 

Signed-off-by: Marco Solieri 
Signed-off-by: Carlo Nonato 
Reviewed-by: Jan Beulich 
Acked-by: Michal Orzel 
---
v13:
- no changes
v12:
- fixed #ifdef CONFIG_LLC_COLORING in init_color_heap_pages()
v11:
- CONFIG_BUDDY_ALLOCATOR_SIZE depends on CONFIG_LLC_COLORING
- buddy_alloc_size is defined only if CONFIG_LLC_COLORING
- buddy-alloc-size param is parsed only if CONFIG_LLC_COLORING
v10:
- stated explicit dependency on CONFIG_LLC_COLORING for buddy-alloc-size
- fix for MISRA rule 20.7 parenthesis
v9:
- added ASSERT(order == 0) when freeing a colored page
- moved buddy_alloc_size initialization logic in Kconfig
v8:
- requests that uses MEMF_* flags that can't be served are now going to fail
- free_color_heap_page() is called directly from free_heap_pages()
v7:
- requests to alloc_color_heap_page() now fail if MEMF_bits is used
v6:
- colored allocator functions are now static
v5:
- Carlo Nonato as the new author
- the colored allocator balances color usage for each domain and it searches
  linearly only in the number of colors (FIXME removed)
- addedd scrub functionality
- removed stub functions (still requires some macro definition)
- addr_to_color turned to mfn_to_color for easier operations
- removed BUG_ON in init_color_heap_pages() in favor of panic()
- only non empty page lists are logged in dump_color_heap()
v4:
- moved colored allocator code after buddy allocator because it now has
  some dependencies on buddy functions
- buddy_alloc_size is now used only by the colored allocator
- fixed a bug that allowed the buddy to merge pages when they were colored
- free_color_heap_page() now calls mark_page_free()
- free_color_heap_page() uses of the frametable array for faster searches
- added FIXME comment for the linear search in free_color_heap_page()
- removed alloc_color_domheap_page() to let the colored allocator exploit
  some more buddy allocator code
- alloc_color_heap_page() now allocs min address pages first
- reduced the mess in end_boot_allocator(): use the first loop for
  init_color_heap_pages()
- fixed page_list_add_prev() (list.h) since it was doing the opposite of
  what it was supposed to do
- fixed page_list_add_prev() (non list.h) to check also for next existence
- removed unused page_list_add_next()
- moved p2m code in another patch
---
 docs/misc/cache-coloring.rst      |  37 ++++++
 docs/misc/xen-command-line.pandoc |  14 +++
 xen/arch/arm/include/asm/mm.h     |   5 +
 xen/common/Kconfig                |   8 ++
 xen/common/llc-coloring.c         |  13 ++
 xen/common/page_alloc.c           | 191 +++++++++++++++++++++++++++++-
 xen/include/xen/llc-coloring.h    |   3 +
 7 files changed, 267 insertions(+), 4 deletions(-)

diff --git a/docs/misc/cache-coloring.rst b/docs/misc/cache-coloring.rst
index e097e74032..5224b27afe 100644
--- a/docs/misc/cache-coloring.rst
+++ b/docs/misc/cache-coloring.rst
@@ -13,6 +13,9 @@ To compile LLC coloring support set ``CONFIG_LLC_COLORING=y``.
 If needed, change the maximum number of colors with
 ``CONFIG_LLC_COLORS_ORDER=``.
 
+If needed, change the buddy allocator reserved size with
+``CONFIG_BUDDY_ALLOCATOR_SIZE=``.
+
 Runtime configuration is done via `Command line parameters`_.
 For DomUs follow `DomUs configuration`_.
 
@@ -110,6 +113,8 @@ Specific documentation is available at `docs/misc/xen-command-line.pandoc`.
 +----------------------+-------------------------------+
 | ``dom0-llc-colors``  | Dom0 color configuration      |
 +----------------------+-------------------------------+
+| ``buddy-alloc-size`` | Buddy allocator reserved size |
++----------------------+-------------------------------+
 
 Colors selection format
 ***********************
@@ -197,6 +202,17 @@ For example:
 **Note:** If no color configuration is provided for a domain, the default one,
 which corresponds to all available colors is used instead.
 
+Colored allocator and buddy allocator
+*************************************
+
+The colored allocator distributes pages based on color configurations of
+domains so that each domains only gets pages of its own colors.
+The colored allocator is meant as an alternative to the buddy allocator because
+its allocation policy is by definition incompatible with the generic one. Since
+the Xen heap is not colored yet, we need to support the coexistence of the two
+allocators and some memory must be left for the buddy one. Buddy memory
+reservation is configured via Kconfig or via command-line.
+
 Known issues and limitations
 ****************************
 
@@ -207,3 +223,24 @@ In the domain configuration, "xen,static-mem" allows memory to be statically
 allocated to the domain. This isn't possible when LLC coloring is enabled,
 because that memory can't be guaranteed to use only colors assigned to the
 domain.
+
+Cache coloring is intended only for embedded systems
+####################################################
+
+The current implementation aims to satisfy the need of predictability in
+embedded systems with small amount of memory to be managed in a colored way.
+Given that, some shortcuts are taken in the development. Expect worse
+performances on larger systems.
+
+Colored allocator can only make use of order-0 pages
+####################################################
+
+The cache coloring technique relies on memory mappings and on the smallest
+mapping granularity to achieve the maximum number of colors (cache partitions)
+possible. This granularity is what is normally called a page and, in Xen
+terminology, the order-0 page is the smallest one. The fairly simple
+colored allocator currently implemented, makes use only of such pages.
+It must be said that a more complex one could, in theory, adopt higher order
+pages if the colors selection contained adjacent colors. Two subsequent colors,
+for example, can be represented by an order-1 page, four colors correspond to
+an order-2 page, etc.
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index be70d6af61..de5d68a452 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -270,6 +270,20 @@ and not running softirqs. Reduce this if softirqs are not being run frequently
 enough. Setting this to a high value may cause boot failure, particularly if
 the NMI watchdog is also enabled.
 
+### buddy-alloc-size (arm64)
+> `= `
+
+> Default: `64M`
+
+Amount of memory reserved for the buddy allocator when colored allocator is
+active. This option is available only when `CONFIG_LLC_COLORING` is enabled.
+The colored allocator is meant as an alternative to the buddy allocator,
+because its allocation policy is by definition incompatible with the generic
+one. Since the Xen heap systems is not colored yet, we need to support the
+coexistence of the two allocators for now. This parameter, which is optional
+and for expert only, it's used to set the amount of memory reserved to the
+buddy allocator.
+
 ### cet
     = List of [ shstk=, ibt= ]
 
diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
index 59b774b7b8..f91ff088f6 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -145,6 +145,11 @@ struct page_info
 #else
 #define PGC_static     0
 #endif
+#ifdef CONFIG_LLC_COLORING
+/* Page is cache colored */
+#define _PGC_colored      PG_shift(4)
+#define PGC_colored       PG_mask(1, 4)
+#endif
 /* ... */
 /* Page is broken? */
 #define _PGC_broken       PG_shift(7)
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index b4ec6893be..6166327f4d 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -537,4 +537,12 @@ config LLC_COLORS_ORDER
 	  The default value corresponds to an 8 MiB 16-ways LLC, which should be
 	  more than what's needed in the general case.
 
+config BUDDY_ALLOCATOR_SIZE
+	int "Buddy allocator reserved memory size (MiB)"
+	default "64"
+	depends on LLC_COLORING
+	help
+	  Amount of memory reserved for the buddy allocator to serve Xen heap,
+	  working alongside the colored one.
+
 endmenu
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index 5a0e3bac59..bebd6e2056 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -36,6 +36,9 @@ static unsigned int __ro_after_init default_colors[NR_LLC_COLORS];
 static unsigned int __initdata dom0_colors[NR_LLC_COLORS];
 static unsigned int __initdata dom0_num_colors;
 
+#define mfn_color_mask              (max_nr_colors - 1)
+#define mfn_to_color(mfn)           (mfn_x(mfn) & mfn_color_mask)
+
 /*
  * Parse the coloring configuration given in the buf string, following the
  * syntax below.
@@ -322,6 +325,16 @@ int __init domain_set_llc_colors_from_str(struct domain *d, const char *str)
     return 0;
 }
 
+unsigned int page_to_llc_color(const struct page_info *pg)
+{
+    return mfn_to_color(page_to_mfn(pg));
+}
+
+unsigned int get_max_nr_llc_colors(void)
+{
+    return max_nr_colors;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 6dc8e0d5c9..1bf070c8c5 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -139,6 +139,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -160,11 +161,15 @@
 #define PGC_static 0
 #endif
 
-#define PGC_no_buddy_merge PGC_static
+#ifndef PGC_colored
+#define PGC_colored 0
+#endif
+
+#define PGC_no_buddy_merge (PGC_static | PGC_colored)
 /*
  * Flags that are preserved in assign_pages() (and only there)
  */
-#define PGC_preserved (PGC_extra | PGC_static)
+#define PGC_preserved (PGC_extra | PGC_static | PGC_colored)
 
 #ifndef PGT_TYPE_INFO_INITIALIZER
 #define PGT_TYPE_INFO_INITIALIZER 0
@@ -1480,6 +1485,8 @@ static bool mark_page_free(struct page_info *pg, mfn_t mfn)
     return pg_offlined;
 }
 
+static void free_color_heap_page(struct page_info *pg, bool need_scrub);
+
 /* Free 2^@order set of pages. */
 static void free_heap_pages(
     struct page_info *pg, unsigned int order, bool need_scrub)
@@ -1504,6 +1511,15 @@ static void free_heap_pages(
             pg[i].count_info |= PGC_need_scrub;
             poison_one_page(&pg[i]);
         }
+
+        if ( pg->count_info & PGC_colored )
+        {
+            ASSERT(order == 0);
+
+            free_color_heap_page(pg, need_scrub);
+            spin_unlock(&heap_lock);
+            return;
+        }
     }
 
     avail[node][zone] += 1 << order;
@@ -1968,6 +1984,157 @@ static unsigned long avail_heap_pages(
     return free_pages;
 }
 
+/*************************
+ * COLORED SIDE-ALLOCATOR
+ *
+ * Pages are grouped by LLC color in lists which are globally referred to as the
+ * color heap. Lists are populated in end_boot_allocator().
+ * After initialization there will be N lists where N is the number of
+ * available colors on the platform.
+ */
+static struct page_list_head *__ro_after_init _color_heap;
+#define color_heap(color) (&_color_heap[color])
+
+static unsigned long *__ro_after_init free_colored_pages;
+
+#ifdef CONFIG_LLC_COLORING
+#define domain_num_llc_colors(d) ((d)->num_llc_colors)
+#define domain_llc_color(d, i)   ((d)->llc_colors[i])
+
+/* Memory required for buddy allocator to work with colored one */
+static unsigned long __initdata buddy_alloc_size =
+    MB(CONFIG_BUDDY_ALLOCATOR_SIZE);
+size_param("buddy-alloc-size", buddy_alloc_size);
+#else
+#define domain_num_llc_colors(d) 0
+#define domain_llc_color(d, i)   0
+#endif
+
+static void free_color_heap_page(struct page_info *pg, bool need_scrub)
+{
+    unsigned int color;
+
+    color = page_to_llc_color(pg);
+    free_colored_pages[color]++;
+    /*
+     * Head insertion allows re-using cache-hot pages in configurations without
+     * sharing of colors.
+     */
+    page_list_add(pg, color_heap(color));
+}
+
+static struct page_info *alloc_color_heap_page(unsigned int memflags,
+                                               const struct domain *d)
+{
+    struct page_info *pg = NULL;
+    unsigned int i, color = 0;
+    unsigned long max = 0;
+    bool need_tlbflush = false;
+    uint32_t tlbflush_timestamp = 0;
+    bool need_scrub;
+
+    if ( memflags & ~(MEMF_no_refcount | MEMF_no_owner | MEMF_no_tlbflush |
+                      MEMF_no_icache_flush | MEMF_no_scrub) )
+        return NULL;
+
+    spin_lock(&heap_lock);
+
+    for ( i = 0; i < domain_num_llc_colors(d); i++ )
+    {
+        unsigned long free = free_colored_pages[domain_llc_color(d, i)];
+
+        if ( free > max )
+        {
+            color = domain_llc_color(d, i);
+            pg = page_list_first(color_heap(color));
+            max = free;
+        }
+    }
+
+    if ( !pg )
+    {
+        spin_unlock(&heap_lock);
+        return NULL;
+    }
+
+    need_scrub = pg->count_info & PGC_need_scrub;
+    pg->count_info = PGC_state_inuse | (pg->count_info & PGC_colored);
+    free_colored_pages[color]--;
+    page_list_del(pg, color_heap(color));
+
+    if ( !(memflags & MEMF_no_tlbflush) )
+        accumulate_tlbflush(&need_tlbflush, pg, &tlbflush_timestamp);
+
+    init_free_page_fields(pg);
+
+    spin_unlock(&heap_lock);
+
+    if ( !(memflags & MEMF_no_scrub) )
+    {
+        if ( need_scrub )
+            scrub_one_page(pg);
+        else
+            check_one_page(pg);
+    }
+
+    if ( need_tlbflush )
+        filtered_flush_tlb_mask(tlbflush_timestamp);
+
+    flush_page_to_ram(mfn_x(page_to_mfn(pg)),
+                      !(memflags & MEMF_no_icache_flush));
+
+    return pg;
+}
+
+static void __init init_color_heap_pages(struct page_info *pg,
+                                         unsigned long nr_pages)
+{
+    unsigned long i;
+    bool need_scrub = opt_bootscrub == BOOTSCRUB_IDLE;
+
+#ifdef CONFIG_LLC_COLORING
+    if ( buddy_alloc_size >= PAGE_SIZE )
+    {
+        unsigned long buddy_pages = min(PFN_DOWN(buddy_alloc_size), nr_pages);
+
+        init_heap_pages(pg, buddy_pages);
+        nr_pages -= buddy_pages;
+        buddy_alloc_size -= buddy_pages << PAGE_SHIFT;
+        pg += buddy_pages;
+    }
+#endif
+
+    if ( !_color_heap )
+    {
+        unsigned int max_nr_colors = get_max_nr_llc_colors();
+
+        _color_heap = xvmalloc_array(struct page_list_head, max_nr_colors);
+        free_colored_pages = xvzalloc_array(unsigned long, max_nr_colors);
+        if ( !_color_heap || !free_colored_pages )
+            panic("Can't allocate colored heap. Buddy reserved size is too low");
+
+        for ( i = 0; i < max_nr_colors; i++ )
+            INIT_PAGE_LIST_HEAD(color_heap(i));
+    }
+
+    for ( i = 0; i < nr_pages; i++ )
+    {
+        pg[i].count_info = PGC_colored;
+        free_color_heap_page(&pg[i], need_scrub);
+    }
+}
+
+static void dump_color_heap(void)
+{
+    unsigned int color;
+
+    printk("Dumping color heap info\n");
+    for ( color = 0; color < get_max_nr_llc_colors(); color++ )
+        if ( free_colored_pages[color] > 0 )
+            printk("Color heap[%u]: %lu pages\n",
+                   color, free_colored_pages[color]);
+}
+
 void __init end_boot_allocator(void)
 {
     unsigned int i;
@@ -1987,7 +2154,13 @@ void __init end_boot_allocator(void)
     for ( i = nr_bootmem_regions; i-- > 0; )
     {
         struct bootmem_region *r = &bootmem_region_list[i];
-        if ( r->s < r->e )
+
+        if ( r->s >= r->e )
+            continue;
+
+        if ( llc_coloring_enabled )
+            init_color_heap_pages(mfn_to_page(_mfn(r->s)), r->e - r->s);
+        else
             init_heap_pages(mfn_to_page(_mfn(r->s)), r->e - r->s);
     }
     nr_bootmem_regions = 0;
@@ -2483,7 +2656,14 @@ struct page_info *alloc_domheap_pages(
     if ( memflags & MEMF_no_owner )
         memflags |= MEMF_no_refcount;
 
-    if ( !dma_bitsize )
+    /* Only domains are supported for coloring */
+    if ( d && llc_coloring_enabled )
+    {
+        /* Colored allocation must be done on 0 order */
+        if ( order || (pg = alloc_color_heap_page(memflags, d)) == NULL )
+            return NULL;
+    }
+    else if ( !dma_bitsize )
         memflags &= ~MEMF_no_dma;
     else if ( (dma_zone = bits_to_zone(dma_bitsize)) < zone_hi )
         pg = alloc_heap_pages(dma_zone + 1, zone_hi, order, memflags, d);
@@ -2686,6 +2866,9 @@ static void cf_check dump_heap(unsigned char key)
             continue;
         printk("Node %d has %lu unscrubbed pages\n", i, node_need_scrub[i]);
     }
+
+    if ( llc_coloring_enabled )
+        dump_color_heap();
 }
 
 static __init int cf_check register_heap_trigger(void)
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
index 5d1355b3c9..1216d1fbd4 100644
--- a/xen/include/xen/llc-coloring.h
+++ b/xen/include/xen/llc-coloring.h
@@ -11,6 +11,7 @@
 #include 
 
 struct domain;
+struct page_info;
 struct xen_domctl_set_llc_colors;
 
 #ifdef CONFIG_LLC_COLORING
@@ -35,6 +36,8 @@ int dom0_set_llc_colors(struct domain *d);
 int domain_set_llc_colors(struct domain *d,
                           const struct xen_domctl_set_llc_colors *config);
 int domain_set_llc_colors_from_str(struct domain *d, const char *str);
+unsigned int page_to_llc_color(const struct page_info *pg);
+unsigned int get_max_nr_llc_colors(void);
 
 #endif /* __XEN_LLC_COLORING_H__ */
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:06:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:06:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859589.1271798 (Exim 4.92)
	(envelope-from )
	id 1tNb2A-0000pl-59; Tue, 17 Dec 2024 17:06:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859589.1271798; Tue, 17 Dec 2024 17:06: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 1tNb29-0000pO-Ul; Tue, 17 Dec 2024 17:06:57 +0000
Received: by outflank-mailman (input) for mailman id 859589;
 Tue, 17 Dec 2024 17:06: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 1tNb27-0006gw-TH
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:06:56 +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 50847243-bc99-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 18:06:54 +0100 (CET)
Received: by mail-ej1-x636.google.com with SMTP id
 a640c23a62f3a-aa66c1345caso209845366b.3
 for ; Tue, 17 Dec 2024 09:06:54 -0800 (PST)
Received: from carlo-ubuntu.home.arpa
 (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab963910f7sm461362666b.166.2024.12.17.09.06.52
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 09:06: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: 50847243-bc99-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734455213; x=1735060013; 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=K9t6ImaeRttaisbzX9gWIlpV2Z0Ew1PDxnW05IrKzpA=;
        b=Q51WU3hGifrgevmiLHSnVqXMqoPImp+f7HpMsilpRDGSiFRFYoOE1+QXMhqrrTKZi6
         9Y24wptNmMUs7LQrGTYho3Wg5hsI6QIZ6R/W2YWQQ07V93fHFMMtKgoggfe8Fagc636B
         j+bRP77cqCXmAPphdj/iZlhJ41L5q8xm3WmgbDxa3gt5t4hO7PzFCW9kTCKA1CuUp4mR
         ZApjnyEWnlwZsFq2L3yXId+6yIafIFuUxK/Ft0pl9rFR0E8Wv5nROlUItoI1Vr701wHu
         msZO6+lNb/CTjMWu7Eshun4tVLxWv33d/eHdZsy1lIDikYS35hXiX8Wip/zEU6ZIm1QP
         EBcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734455213; x=1735060013;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=K9t6ImaeRttaisbzX9gWIlpV2Z0Ew1PDxnW05IrKzpA=;
        b=k1OmSNEXvsFz4an0unfsYYKMq8b1aHvGO2+nT2Q1CU0VFIUXM/2myiUG6jAJ5ki+5l
         OC7REkt3Wx25y9LCecbSDU62H4amX3q6vEo476PJFg6hzWg26AYUC+/owNQulMKAFxsj
         +Hi+5tLOJjQ+BNTeiZladc2wQs7opPkDy84Mb04VCWRCArQsCql4nACttC04DC7zqLA0
         tzM6Lk96SQDxSv61N/FfUbPeQkfDhkdVGNb1twXdX3wOieDJmBWxyw4L3zd8MC+ool/B
         nZiAoR57j/u3uIUXOs9EcS3LQtbY/EKjLAEzYykIU9GuM7FGv8vJGFlm09y4/Qj6T0+2
         zKXQ==
X-Gm-Message-State: AOJu0YzS93Tlt0ebtlFWqgqVazXCnNZAzwnr5nQlpJD2WiRYQkQVA+ZN
	2JsGvUHofEIfHrJyohbaY6q6o/q7bSCsaGiQDvELyvsl2pncaKVxk9bvUCi70xWr2lfENUj5A2T
	YKgs=
X-Gm-Gg: ASbGncsPR7F/+vOoo5qV/iZm0G1t7UVqoi4WC8gHtp5QXrMViKxdvTRHMk8EH869rq+
	M++Lxx8eIew9MoGFQN9mh3dehHxkxL1G1pbl5pwXVjAUgUwt4tB89W+N4HTM6mX3JVv5yAk7XEy
	iF4mZChaPzvGtglOg3gQG+PP3S4OEP9B2Gk0a3COwUGgFflM54Qq5YggO+TN5Gv1BADR97MEwCR
	ThaqGEbCdKt76lHSS6C5BaM6r5YVqbuLG53uBbG/PabPGYlFPwGJfLTZMlOFiM17HT/rzHtKmQJ
	HKktgDm5JfWwqMneyHEXB+MKMqXTtuRGV+KkHo7N+B5AZYHg5R+HYgb3JdA=
X-Google-Smtp-Source: AGHT+IGScJw9Sd0Pvm04BktSNQzqxYAna5DuBi7NfoxOj9YSlgw60A8Nuhpi4/g5zWSAxyjW3sslaw==
X-Received: by 2002:a17:907:7843:b0:aa6:8a1b:8b84 with SMTP id a640c23a62f3a-aab77ed7774mr1454364266b.57.1734455212968;
        Tue, 17 Dec 2024 09:06:52 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v13 12/12] xen/arm: add cache coloring support for Xen image
Date: Tue, 17 Dec 2024 18:06:37 +0100
Message-ID: <20241217170637.233097-13-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
References: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Xen image is relocated to a new colored physical space. Some relocation
functionalities must be brought back:
- the virtual address of the new space is taken from 0c18fb76323b
  ("xen/arm: Remove unused BOOT_RELOC_VIRT_START").
- relocate_xen() and get_xen_paddr() are taken from f60658c6ae47
  ("xen/arm: Stop relocating Xen").

setup_pagetables() must be adapted for coloring and for relocation. Runtime
page tables are used to map the colored space, but they are also linked in
boot tables so that the new space is temporarily available for relocation.
This implies that Xen protection must happen after the copy.

Finally, since the alternative framework needs to remap the Xen text and
inittext sections, this operation must be done in a coloring-aware way.
The function xen_remap_colored() is introduced for that.

Signed-off-by: Carlo Nonato 
Signed-off-by: Marco Solieri 
Reviewed-by: Jan Beulich  # common
---
v13:
- added stub and #ifdef CONFIG_LLC_COLORING for relocate_and_switch_ttbr()
v12:
- FUNC instead of ENTRY in head.S for relocate_xen
- dc cvau instead of dc cvav in relocate_xen()
- added relocate_and_switch_ttbr() to make setup_pagetables() code more clear
v11:
- else if -> if in xen_colored_mfn()
v10:
- no changes
v9:
- patch adapted to changes to setup_pagetables()
v8:
- moved xen_colored_map_size() to arm/llc-coloring.c
v7:
- added BUG_ON() checks to arch_llc_coloring_init() and
  create_llc_coloring_mappings()
v6:
- squashed with BOOT_RELOC_VIRT_START patch
- consider_modules() moved in another patch
- removed psci and smpboot code because of new idmap work already handles that
- moved xen_remap_colored() in alternative.c since it's only used there
- removed xen_colored_temp[] in favor of xen_xenmap[] usage for mapping
- use of boot_module_find_by_kind() to remove the need of extra parameter in
  setup_pagetables()
- moved get_xen_paddr() in arm/llc-coloring.c since it's only used there
v5:
- FIXME: consider_modules copy pasted since it got moved
v4:
- removed set_value_for_secondary() because it was wrongly cleaning cache
- relocate_xen() now calls switch_ttbr_id()
---
 xen/arch/arm/alternative.c            |  26 ++++++-
 xen/arch/arm/arm64/mmu/head.S         |  58 +++++++++++++-
 xen/arch/arm/arm64/mmu/mm.c           |  34 ++++++++
 xen/arch/arm/include/asm/mmu/layout.h |   3 +
 xen/arch/arm/include/asm/mmu/mm.h     |   1 +
 xen/arch/arm/llc-coloring.c           |  63 +++++++++++++++
 xen/arch/arm/mmu/setup.c              | 107 ++++++++++++++++++++++----
 xen/arch/arm/setup.c                  |  10 ++-
 xen/common/llc-coloring.c             |  18 +++++
 xen/include/xen/llc-coloring.h        |  13 ++++
 10 files changed, 313 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index fec7dbd2cd..2c1af6e7e4 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -191,6 +192,25 @@ static int __apply_alternatives_multi_stop(void *xenmap)
     return 0;
 }
 
+static void __init *xen_remap_colored(mfn_t xen_mfn, paddr_t xen_size)
+{
+    unsigned int i;
+    void *xenmap;
+    mfn_t *xen_colored_mfns, mfn;
+
+    xen_colored_mfns = xmalloc_array(mfn_t, xen_size >> PAGE_SHIFT);
+    if ( !xen_colored_mfns )
+        panic("Can't allocate LLC colored MFNs\n");
+
+    for_each_xen_colored_mfn ( xen_mfn, mfn, i )
+        xen_colored_mfns[i] = mfn;
+
+    xenmap = vmap(xen_colored_mfns, xen_size >> PAGE_SHIFT);
+    xfree(xen_colored_mfns);
+
+    return xenmap;
+}
+
 /*
  * This function should only be called during boot and before CPU0 jump
  * into the idle_loop.
@@ -209,7 +229,11 @@ void __init apply_alternatives_all(void)
      * The text and inittext section are read-only. So re-map Xen to
      * be able to patch the code.
      */
-    xenmap = vmap_contig(xen_mfn, 1U << xen_order);
+    if ( llc_coloring_enabled )
+        xenmap = xen_remap_colored(xen_mfn, xen_size);
+    else
+        xenmap = vmap_contig(xen_mfn, 1U << xen_order);
+
     /* Re-mapping Xen is not expected to fail during boot. */
     BUG_ON(!xenmap);
 
diff --git a/xen/arch/arm/arm64/mmu/head.S b/xen/arch/arm/arm64/mmu/head.S
index 665a51a337..634156f83d 100644
--- a/xen/arch/arm/arm64/mmu/head.S
+++ b/xen/arch/arm/arm64/mmu/head.S
@@ -428,6 +428,61 @@ FUNC_LOCAL(fail)
         b     1b
 END(fail)
 
+/*
+ * Copy Xen to new location and switch TTBR
+ * x0    ttbr
+ * x1    source address
+ * x2    destination address
+ * x3    length
+ *
+ * Source and destination must be word aligned, length is rounded up
+ * to a 16 byte boundary.
+ *
+ * MUST BE VERY CAREFUL when saving things to RAM over the copy
+ */
+FUNC(relocate_xen)
+        /*
+         * Copy 16 bytes at a time using:
+         *   x9: counter
+         *   x10: data
+         *   x11: data
+         *   x12: source
+         *   x13: destination
+         */
+        mov     x9, x3
+        mov     x12, x1
+        mov     x13, x2
+
+1:      ldp     x10, x11, [x12], #16
+        stp     x10, x11, [x13], #16
+
+        subs    x9, x9, #16
+        bgt     1b
+
+        /*
+         * Flush destination from dcache using:
+         *   x9: counter
+         *   x10: step
+         *   x11: vaddr
+         *
+         * This is to ensure data is visible to the instruction cache
+         */
+        dsb   sy
+
+        mov   x9, x3
+        ldr   x10, =dcache_line_bytes /* x10 := step */
+        ldr   x10, [x10]
+        mov   x11, x2
+
+1:      dc    cvau, x11
+
+        add   x11, x11, x10
+        subs  x9, x9, x10
+        bgt   1b
+
+        /* No need for dsb/isb because they are alredy done in switch_ttbr_id */
+        b switch_ttbr_id
+
 /*
  * Switch TTBR
  *
@@ -453,7 +508,8 @@ FUNC(switch_ttbr_id)
 
         /*
          * 5) Flush I-cache
-         * This should not be necessary but it is kept for safety.
+         * This should not be necessary in the general case, but it's needed
+         * for cache coloring because code is relocated in that case.
          */
         ic     iallu
         isb
diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c
index 671eaadbc1..26361c4fe4 100644
--- a/xen/arch/arm/arm64/mmu/mm.c
+++ b/xen/arch/arm/arm64/mmu/mm.c
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 
 #include 
+#include 
 #include 
 #include 
 
@@ -138,8 +139,41 @@ void update_boot_mapping(bool enable)
 }
 
 extern void switch_ttbr_id(uint64_t ttbr);
+extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len);
 
 typedef void (switch_ttbr_fn)(uint64_t ttbr);
+typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, size_t len);
+
+#ifdef CONFIG_LLC_COLORING
+void __init relocate_and_switch_ttbr(uint64_t ttbr)
+{
+    vaddr_t id_addr = virt_to_maddr(relocate_xen);
+    relocate_xen_fn *fn = (relocate_xen_fn *)id_addr;
+    lpae_t pte;
+
+    /* Enable the identity mapping in the boot page tables */
+    update_identity_mapping(true);
+
+    /* Enable the identity mapping in the runtime page tables */
+    pte = pte_of_xenaddr((vaddr_t)relocate_xen);
+    pte.pt.table = 1;
+    pte.pt.xn = 0;
+    pte.pt.ro = 1;
+    write_pte(&xen_third_id[third_table_offset(id_addr)], pte);
+
+    /* Relocate Xen and switch TTBR */
+    fn(ttbr, _start, (void *)BOOT_RELOC_VIRT_START, _end - _start);
+
+    /*
+     * Disable the identity mapping in the runtime page tables.
+     * Note it is not necessary to disable it in the boot page tables
+     * because they are not going to be used by this CPU anymore.
+     */
+    update_identity_mapping(false);
+}
+#else
+void __init relocate_and_switch_ttbr(uint64_t ttbr) {}
+#endif
 
 void __init switch_ttbr(uint64_t ttbr)
 {
diff --git a/xen/arch/arm/include/asm/mmu/layout.h b/xen/arch/arm/include/asm/mmu/layout.h
index a3b546465b..19c0ec63a5 100644
--- a/xen/arch/arm/include/asm/mmu/layout.h
+++ b/xen/arch/arm/include/asm/mmu/layout.h
@@ -30,6 +30,7 @@
  *  10M -  12M   Fixmap: special-purpose 4K mapping slots
  *  12M -  16M   Early boot mapping of FDT
  *  16M -  18M   Livepatch vmap (if compiled in)
+ *  16M -  24M   Cache-colored Xen text, data, bss (temporary, if compiled in)
  *
  *   1G -   2G   VMAP: ioremap and early_ioremap
  *
@@ -74,6 +75,8 @@
 #define BOOT_FDT_VIRT_START     (FIXMAP_VIRT_START + FIXMAP_VIRT_SIZE)
 #define BOOT_FDT_VIRT_SIZE      _AT(vaddr_t, MB(4))
 
+#define BOOT_RELOC_VIRT_START   (BOOT_FDT_VIRT_START + BOOT_FDT_VIRT_SIZE)
+
 #ifdef CONFIG_LIVEPATCH
 #define LIVEPATCH_VMAP_START    (BOOT_FDT_VIRT_START + BOOT_FDT_VIRT_SIZE)
 #define LIVEPATCH_VMAP_SIZE    _AT(vaddr_t, MB(2))
diff --git a/xen/arch/arm/include/asm/mmu/mm.h b/xen/arch/arm/include/asm/mmu/mm.h
index c5e03a66bf..f5a00558c4 100644
--- a/xen/arch/arm/include/asm/mmu/mm.h
+++ b/xen/arch/arm/include/asm/mmu/mm.h
@@ -31,6 +31,7 @@ void dump_pt_walk(paddr_t ttbr, paddr_t addr,
 
 /* Switch to a new root page-tables */
 extern void switch_ttbr(uint64_t ttbr);
+extern void relocate_and_switch_ttbr(uint64_t ttbr);
 
 #endif /* __ARM_MMU_MM_H__ */
 
diff --git a/xen/arch/arm/llc-coloring.c b/xen/arch/arm/llc-coloring.c
index 1c7b92bc45..99ac10b610 100644
--- a/xen/arch/arm/llc-coloring.c
+++ b/xen/arch/arm/llc-coloring.c
@@ -9,6 +9,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -64,8 +65,70 @@ unsigned int __init get_llc_way_size(void)
     return line_size * num_sets;
 }
 
+/*
+ * get_xen_paddr - get physical address to relocate Xen to
+ *
+ * Xen is relocated to as near to the top of RAM as possible and
+ * aligned to a XEN_PADDR_ALIGN boundary.
+ */
+static paddr_t __init get_xen_paddr(paddr_t xen_size)
+{
+    const struct membanks *mem = bootinfo_get_mem();
+    paddr_t min_size, paddr = 0;
+    unsigned int i;
+
+    min_size = ROUNDUP(xen_size, XEN_PADDR_ALIGN);
+
+    /* Find the highest bank with enough space. */
+    for ( i = 0; i < mem->nr_banks; i++ )
+    {
+        const struct membank *bank = &mem->bank[i];
+        paddr_t s, e;
+
+        if ( bank->size >= min_size )
+        {
+            e = consider_modules(bank->start, bank->start + bank->size,
+                                 min_size, XEN_PADDR_ALIGN, 0);
+            if ( !e )
+                continue;
+
+#ifdef CONFIG_ARM_32
+            /* Xen must be under 4GB */
+            if ( e > GB(4) )
+                e = GB(4);
+            if ( e < bank->start )
+                continue;
+#endif
+
+            s = e - min_size;
+
+            if ( s > paddr )
+                paddr = s;
+        }
+    }
+
+    if ( !paddr )
+        panic("Not enough memory to relocate Xen\n");
+
+    printk("Placing Xen at 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
+           paddr, paddr + min_size);
+
+    return paddr;
+}
+
+static paddr_t __init xen_colored_map_size(void)
+{
+    return ROUNDUP((_end - _start) * get_max_nr_llc_colors(), XEN_PADDR_ALIGN);
+}
+
 void __init arch_llc_coloring_init(void)
 {
+    struct bootmodule *xen_bootmodule = boot_module_find_by_kind(BOOTMOD_XEN);
+
+    BUG_ON(!xen_bootmodule);
+
+    xen_bootmodule->size = xen_colored_map_size();
+    xen_bootmodule->start = get_xen_paddr(xen_bootmodule->size);
 }
 
 /*
diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c
index 041e3fc1b6..30afe97781 100644
--- a/xen/arch/arm/mmu/setup.c
+++ b/xen/arch/arm/mmu/setup.c
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -20,6 +21,9 @@
 #undef virt_to_mfn
 #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
 
+#define virt_to_reloc_virt(virt) \
+    (((vaddr_t)(virt)) - XEN_VIRT_START + BOOT_RELOC_VIRT_START)
+
 /* Main runtime page tables */
 
 /*
@@ -69,6 +73,7 @@ static void __init __maybe_unused build_assertions(void)
     /* 2MB aligned regions */
     BUILD_BUG_ON(XEN_VIRT_START & ~SECOND_MASK);
     BUILD_BUG_ON(FIXMAP_ADDR(0) & ~SECOND_MASK);
+    BUILD_BUG_ON(BOOT_RELOC_VIRT_START & ~SECOND_MASK);
     /* 1GB aligned regions */
 #ifdef CONFIG_ARM_32
     BUILD_BUG_ON(XENHEAP_VIRT_START & ~FIRST_MASK);
@@ -138,6 +143,9 @@ static void __init __maybe_unused build_assertions(void)
 
 lpae_t __init pte_of_xenaddr(vaddr_t va)
 {
+    if ( llc_coloring_enabled )
+        va = virt_to_reloc_virt(va);
+
     return mfn_to_xen_entry(virt_to_mfn(va), MT_NORMAL);
 }
 
@@ -316,6 +324,32 @@ paddr_t __init consider_modules(paddr_t s, paddr_t e,
     return e;
 }
 
+static void __init create_llc_coloring_mappings(void)
+{
+    lpae_t pte;
+    unsigned int i;
+    struct bootmodule *xen_bootmodule = boot_module_find_by_kind(BOOTMOD_XEN);
+    mfn_t start_mfn = maddr_to_mfn(xen_bootmodule->start), mfn;
+
+    for_each_xen_colored_mfn ( start_mfn, mfn, i )
+    {
+        pte = mfn_to_xen_entry(mfn, MT_NORMAL);
+        pte.pt.table = 1; /* level 3 mappings always have this bit set */
+        xen_xenmap[i] = pte;
+    }
+
+    for ( i = 0; i < XEN_NR_ENTRIES(2); i++ )
+    {
+        vaddr_t va = BOOT_RELOC_VIRT_START + (i << XEN_PT_LEVEL_SHIFT(2));
+
+        pte = mfn_to_xen_entry(virt_to_mfn(xen_xenmap +
+                                           i * XEN_PT_LPAE_ENTRIES),
+                               MT_NORMAL);
+        pte.pt.table = 1;
+        write_pte(&boot_second[second_table_offset(va)], pte);
+    }
+}
+
 /*
  * Boot-time pagetable setup.
  * Changes here may need matching changes in head.S
@@ -326,6 +360,14 @@ void __init setup_pagetables(void)
     lpae_t pte, *p;
     int i;
 
+    /*
+     * In case of cache coloring, map the new physical space in the boot page
+     * tables. From now on, pte_of_xenaddr() will translate addresses to this
+     * new space.
+     */
+    if ( llc_coloring_enabled )
+        create_llc_coloring_mappings();
+
     arch_setup_page_tables();
 
 #ifdef CONFIG_ARM_64
@@ -353,13 +395,7 @@ void __init setup_pagetables(void)
             break;
         pte = pte_of_xenaddr(va);
         pte.pt.table = 1; /* third level mappings always have this bit set */
-        if ( is_kernel_text(va) || is_kernel_inittext(va) )
-        {
-            pte.pt.xn = 0;
-            pte.pt.ro = 1;
-        }
-        if ( is_kernel_rodata(va) )
-            pte.pt.ro = 1;
+        pte.pt.xn = 0; /* Permissions will be enforced later. Allow execution */
         xen_xenmap[i] = pte;
     }
 
@@ -379,19 +415,58 @@ void __init setup_pagetables(void)
     pte.pt.table = 1;
     xen_second[second_table_offset(FIXMAP_ADDR(0))] = pte;
 
-#ifdef CONFIG_ARM_64
-    ttbr = virt_to_maddr(xen_pgtable);
-#else
-    ttbr = virt_to_maddr(cpu0_pgtable);
+#ifdef CONFIG_ARM_32
+    per_cpu(xen_pgtable, 0) = cpu0_pgtable;
 #endif
 
-    switch_ttbr(ttbr);
+    if ( llc_coloring_enabled )
+    {
+        ttbr = virt_to_maddr(virt_to_reloc_virt(THIS_CPU_PGTABLE));
+        relocate_and_switch_ttbr(ttbr);
+    }
+    else
+    {
+        ttbr = virt_to_maddr(THIS_CPU_PGTABLE);
+        switch_ttbr(ttbr);
+    }
 
-    xen_pt_enforce_wnx();
+    /* Protect Xen */
+    for ( i = 0; i < XEN_NR_ENTRIES(3); i++ )
+    {
+        vaddr_t va = XEN_VIRT_START + (i << PAGE_SHIFT);
+        lpae_t *entry = xen_xenmap + i;
 
-#ifdef CONFIG_ARM_32
-    per_cpu(xen_pgtable, 0) = cpu0_pgtable;
-#endif
+        if ( !is_kernel(va) )
+            break;
+
+        pte = read_atomic(entry);
+
+        if ( is_kernel_text(va) || is_kernel_inittext(va) )
+        {
+            pte.pt.xn = 0;
+            pte.pt.ro = 1;
+        }
+        else if ( is_kernel_rodata(va) )
+        {
+            pte.pt.ro = 1;
+            pte.pt.xn = 1;
+        }
+        else
+        {
+            pte.pt.xn = 1;
+            pte.pt.ro = 0;
+        }
+
+        write_pte(entry, pte);
+    }
+
+    /*
+     * We modified live page-tables. Ensure the TLBs are invalidated
+     * before setting enforcing the WnX permissions.
+     */
+    flush_xen_tlb_local();
+
+    xen_pt_enforce_wnx();
 }
 
 void *__init arch_vmap_virt_end(void)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 5f1993ffed..68c1f30920 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -312,8 +312,6 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr)
     /* Initialize traps early allow us to get backtrace when an error occurred */
     init_traps();
 
-    setup_pagetables();
-
     smp_clear_cpu_maps();
 
     device_tree_flattened = early_fdt_map(fdt_paddr);
@@ -337,6 +335,14 @@ void asmlinkage __init start_xen(unsigned long fdt_paddr)
 
     llc_coloring_init();
 
+    /*
+     * Page tables must be setup after LLC coloring initialization because
+     * coloring info are required in order to create colored mappings
+     */
+    setup_pagetables();
+    /* Device-tree was mapped in boot page tables, remap it in the new tables */
+    device_tree_flattened = early_fdt_map(fdt_paddr);
+
     setup_mm();
 
     vm_init();
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index 0cfaa77a2b..a572f77a09 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -42,6 +42,8 @@ static unsigned int __ro_after_init xen_num_colors;
 
 #define mfn_color_mask              (max_nr_colors - 1)
 #define mfn_to_color(mfn)           (mfn_x(mfn) & mfn_color_mask)
+#define get_mfn_with_color(mfn, color) \
+    (_mfn((mfn_x(mfn) & ~mfn_color_mask) | (color)))
 
 /*
  * Parse the coloring configuration given in the buf string, following the
@@ -364,6 +366,22 @@ unsigned int get_max_nr_llc_colors(void)
     return max_nr_colors;
 }
 
+mfn_t __init xen_colored_mfn(mfn_t mfn)
+{
+    unsigned int i, color = mfn_to_color(mfn);
+
+    for ( i = 0; i < xen_num_colors; i++ )
+    {
+        if ( color == xen_colors[i] )
+            return mfn;
+        if ( color < xen_colors[i] )
+            return get_mfn_with_color(mfn, xen_colors[i]);
+    }
+
+    /* Jump to next color space (max_nr_colors mfns) and use the first color */
+    return get_mfn_with_color(mfn_add(mfn, max_nr_colors), xen_colors[0]);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/llc-coloring.h b/xen/include/xen/llc-coloring.h
index 1216d1fbd4..45f250f9f3 100644
--- a/xen/include/xen/llc-coloring.h
+++ b/xen/include/xen/llc-coloring.h
@@ -8,6 +8,7 @@
 #ifndef __XEN_LLC_COLORING_H__
 #define __XEN_LLC_COLORING_H__
 
+#include 
 #include 
 
 struct domain;
@@ -30,6 +31,17 @@ static inline void domain_dump_llc_colors(const struct domain *d) {}
 static inline void domain_llc_coloring_free(struct domain *d) {}
 #endif
 
+/*
+ * Iterate over each Xen mfn in the colored space.
+ * @start_mfn:  the first mfn that needs to be colored.
+ * @mfn:        the current mfn.
+ * @i:          loop index.
+ */
+#define for_each_xen_colored_mfn(start_mfn, mfn, i) \
+    for ( (i) = 0, (mfn) = xen_colored_mfn(start_mfn);  \
+          (i) < (_end - _start) >> PAGE_SHIFT;        \
+          (i)++, (mfn) = xen_colored_mfn(mfn_add(mfn, 1)) )
+
 unsigned int get_llc_way_size(void);
 void arch_llc_coloring_init(void);
 int dom0_set_llc_colors(struct domain *d);
@@ -38,6 +50,7 @@ int domain_set_llc_colors(struct domain *d,
 int domain_set_llc_colors_from_str(struct domain *d, const char *str);
 unsigned int page_to_llc_color(const struct page_info *pg);
 unsigned int get_max_nr_llc_colors(void);
+mfn_t xen_colored_mfn(mfn_t mfn);
 
 #endif /* __XEN_LLC_COLORING_H__ */
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:13:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:13:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859684.1271807 (Exim 4.92)
	(envelope-from )
	id 1tNb8f-00060I-UI; Tue, 17 Dec 2024 17:13:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859684.1271807; Tue, 17 Dec 2024 17:13: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 1tNb8f-00060B-RX; Tue, 17 Dec 2024 17:13:41 +0000
Received: by outflank-mailman (input) for mailman id 859684;
 Tue, 17 Dec 2024 17:13: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 1tNb8d-0005xd-ND
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:13:40 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 40e298da-bc9a-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 18:13:37 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 17 Dec 2024 18:13:36 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 40e298da-bc9a-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734455617; x=1765991617;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=FHWLiL11Zy6rSHgq+17T9boY/iUnomWJT6OT7/T4izs=;
  b=spiXS77tc6lRQmU21He6KOUSX1BVryTzfJcOi1FZDAE+1JSSOsmElYUJ
   iiOn09CtbwqqdxBR6ZsHuau7eMlj6J/j5d+EbG24aH4XIMXSFE22ErL3L
   zDNBLl2O8eUTz5Bbxvzq4h/aeQ1uDXwjITq5hyUe/h9FR69Cb7Hm/k4E4
   Y=;
X-CSE-ConnectionGUID: drW2AnqKROCPqSL3KZcewg==
X-CSE-MsgGUID: Eo+ffri8TIutMV2To6zqbg==
X-IronPort-AV: E=Sophos;i="6.12,242,1728943200"; 
   d="scan'208";a="28222177"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"
X-Forward: 149.5.228.1
References: <20241214161350.70515-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216231128.211648-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216231128.211648-2-Ariel.Otilibili-Anieli@eurecom.fr> 
Date: Tue, 17 Dec 2024 18:13:36 +0100
Cc: xen-devel@lists.xenproject.org, "Jan Beulich" , "Anthony PERARD" , "Luca Fancellu" 
To: "Andrew Cooper" 
MIME-Version: 1.0
Message-ID: <2f7a8a-6761b180-9a89-1d1363a0@43143421>
Subject: =?utf-8?q?Re=3A?= [PATCH v2 1/1] =?utf-8?q?tools=2C?=
 =?utf-8?q?_xen/scripts=3A?= clear out Python syntax warnings
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 2529

On Tuesday, December 17, 2024 17:26 CET, Andrew Cooper  wrote:

> On 16/12/2024 11:07 pm, Ariel Otilibili wrote:
> > * since 3.12 invalid escape sequences generate SyntaxWarning
> > * in the future, these invalid sequences will generate SyntaxError
> > * therefore changed syntax to raw string notation.
> >
> > Link: https://docs.python.org/3/whatsnew/3.12.html#other-language-c=
hanges
> > Fixes: d8f3a67bf98 ("pygrub: further improve grub2 support")
> > Fixes: dd03048708a ("xen/pygrub: grub2/grub.cfg from RHEL 7 has new=
 commands in menuentry")
> > Fixes: d1b93ea2615 ("tools/pygrub: Make pygrub understand default e=
ntry in string format")
> > Fixes: 622e368758b ("Add ZFS libfsimage support patch")
> > Fixes: 02b26c02c7c ("xen/scripts: add cppcheck tool to the xen-anal=
ysis.py script")
> > Fixes: 56c0063f4e7 ("xen/misra: xen-analysis.py: Improve the cppche=
ck version check")
> >
> > Cc: Anthony PERARD 
> > Cc: Luca Fancellu 
> > Cc: Andrew Cooper 
> > Signed-off-by: Ariel Otilibili 
>=20
> Having poked about a bit more, this is all a big mess, but these do n=
ow
> work with Py3.12.
>=20
> leading \ for non-special characters are ignored in [], which is why =
...
>=20
> > ---
> >  tools/pygrub/src/GrubConf.py                  | 4 ++--
> >  tools/pygrub/src/pygrub                       | 6 +++---
> >  xen/scripts/xen=5Fanalysis/cppcheck=5Fanalysis.py | 4 ++--
> >  3 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/GrubCo=
nf.py
> > index 580c9628ca..904e7d5567 100644
> > --- a/tools/pygrub/src/GrubConf.py
> > +++ b/tools/pygrub/src/GrubConf.py
> > @@ -320,7 +320,7 @@ class GrubConfigFile(=5FGrubConfigFile):
> >  def grub2=5Fhandle=5Fset(arg):
> >      (com,arg) =3D grub=5Fsplit(arg,2)
> >      com=3D"set:" + com
> > -    m =3D re.match("([\"\'])(.*)\\1", arg)
> > +    m =3D re.match(r"([\"\'])(.*)\1", arg)
>=20
> ... the \' works here.
>=20
> Anyway, I've checked the others and they seem to work, so I suggest
> taking this roughly this form.
>=20
> Some notes about the commit message.=C2=A0 The subject ought to be:
>=20
> tools: Fix syntax warnings with Python 3.12
>=20
> The text should be a regular paragraph, rather than bullet points lik=
e this.
>=20
> I can fix this all on commit if you're happy.

Thanks for the feedback, Andrew; I'm happy with your changes.
>=20
> ~Andrew



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:13:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:13:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859690.1271818 (Exim 4.92)
	(envelope-from )
	id 1tNb8t-0006Nv-6O; Tue, 17 Dec 2024 17:13:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859690.1271818; Tue, 17 Dec 2024 17:13:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNb8t-0006Nn-2f; Tue, 17 Dec 2024 17:13:55 +0000
Received: by outflank-mailman (input) for mailman id 859690;
 Tue, 17 Dec 2024 17:13: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 1tNb25-0006B0-EB
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:06:53 +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 4fc67774-bc99-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 18:06:52 +0100 (CET)
Received: by mail-ed1-x530.google.com with SMTP id
 4fb4d7f45d1cf-5d3e6f6cf69so2358997a12.1
 for ; Tue, 17 Dec 2024 09:06:52 -0800 (PST)
Received: from carlo-ubuntu.home.arpa
 (host-95-230-250-178.business.telecomitalia.it. [95.230.250.178])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab963910f7sm461362666b.166.2024.12.17.09.06.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 09:06: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: 4fc67774-bc99-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734455212; x=1735060012; 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=uCbAePzsxXQgANJpC00dfwQGE1Jow0ZuHgQ13Xppu60=;
        b=j/ZzIEnB4VV4cXfFGPY3ch1vkcWy38dNKUiCM9QKNGoItZH+9jU7zPpnbg3Mq6sPQI
         gBz8MUozu60sMbQsIlOawGf5dYunKKral3Hic8UVcbc3cO0UtvYoaamL1N/4TzQ/Rz9e
         OQU0kHptcZZH1kWE/dUbhp1OoybLCm+3qkhcX5jlNn8tau0bainmzTvk3/niDlUCPv2r
         dzocQnw21O7SKd/xAxUi5G9Fv6+JFHJnzEa3y2vhMfhxhUHAQ5hkS6vDvA9ztV5PjQ2l
         vo0uUq5cJh/FdsqXVzlgZIy2QAxFVFKndPX4Qt5ZzyqRgdeCuXQrX52qVFniPi8S2LGF
         ltxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734455212; x=1735060012;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=uCbAePzsxXQgANJpC00dfwQGE1Jow0ZuHgQ13Xppu60=;
        b=O76mdhAWM4Dv1AInCE7xfiCZ5RyA1FvZKJpzdP9RT5rDocQKLkYZArezk6B6lSWY4X
         mQxSwGksOdiKTATbE4K9NzNFFAKCm6Ea/G8cfYgWomHwJE8HpLxBTy7QnD5XSiPwz8Rj
         z/3mAbuthn4TcKKqa05t5UNhwOMt8MSMlJdBOK053SL9R43ky+jZ4mHkMRjEgqtiHpVT
         p0p97Vd5fWMvCBpZHopLynM/S9QDB9gmolUi83ceuLtu5cz9y4bJfrpfVkSEuANP7/CW
         Ln3SwPI0c/g8ME9mFLfNt95Ih/zA8jKZlNd4At8qk0+BNBB+LDgV4OCRPqnRa51dANXN
         p17g==
X-Gm-Message-State: AOJu0YxNPxVfgfdN+m32Wn4F+Npeytoi38VXSBAp+kR6Js5L+j/TMOtg
	AlqHALLwHhUKhC5Gg9fKui6YVRH5gqmY9TKe86xFS0a5KN0KCt+SmGPRnqYZyxZ78eFtWKHjUIi
	xCns=
X-Gm-Gg: ASbGnctKGWAPsC8NizkdhW2shxIySnpY4I1/KrLu7jFnQfTpAd3rAJgSjlxpgslrhOp
	GNydDNQbdyBeibKvraaKC9x9VQ7VRGXtUs/bi0ZQlDyQ5MZkWJ+n0aAXOuOpq//oBFAFbwUx6lp
	QsH1ggC9m0OPSrRTCi/FmC33ebcMIlQVwOOfVs9OAU1gkZ1Eu3yJUzWoV3VCXsgEBDrqd0EeJA5
	vJcpMxKBCKog3eKsXrQMXljmQ4bOMAfz8hGcg8Yi63BfU6NIlZWSaEYMnyIOK9ztql3ODe3Qq31
	PW2ewv6lFR/9cY2yDL9PsWHCtjyf/PSWPVxjuOSX3iw87J3FgeYIgbu7dHc=
X-Google-Smtp-Source: AGHT+IHANdNcEuSk3JUmNF8b1IphrGJ40kUtQEAyVIqtsJvzWh7W5bLvH9nHff5RehXKbMMNmLeUAA==
X-Received: by 2002:a17:907:3e1d:b0:aa6:800a:1292 with SMTP id a640c23a62f3a-aab779ab53dmr1811455166b.25.1734455211849;
        Tue, 17 Dec 2024 09:06:51 -0800 (PST)
From: Carlo Nonato 
To: xen-devel@lists.xenproject.org
Cc: andrea.bastoni@minervasys.tech,
	marco.solieri@minervasys.tech,
	Carlo Nonato ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v13 11/12] xen/arm: make consider_modules() available for xen relocation
Date: Tue, 17 Dec 2024 18:06:36 +0100
Message-ID: <20241217170637.233097-12-carlo.nonato@minervasys.tech>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
References: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Cache coloring must physically relocate Xen in order to color the hypervisor
and consider_modules() is a key function that is needed to find a new
available physical address.

672d67f339c0 ("xen/arm: Split MMU-specific setup_mm() and related code out")
moved consider_modules() under arm32. Move it to mmu/setup.c and make it
non-static so that it can be used outside.

Signed-off-by: Carlo Nonato 
Reviewed-by: Michal Orzel 
---
v13:
- no changes
v12:
- no changes
v11:
- removed useless #include
v10:
- no changes
v9:
- no changes
v8:
- patch adapted to new changes to consider_modules()
v7:
- moved consider_modules() to arm/mmu/setup.c
v6:
- new patch
---
 xen/arch/arm/arm32/mmu/mm.c      | 95 +-------------------------------
 xen/arch/arm/include/asm/setup.h |  3 +
 xen/arch/arm/mmu/setup.c         | 94 +++++++++++++++++++++++++++++++
 3 files changed, 98 insertions(+), 94 deletions(-)

diff --git a/xen/arch/arm/arm32/mmu/mm.c b/xen/arch/arm/arm32/mmu/mm.c
index 0824d61323..956693232a 100644
--- a/xen/arch/arm/arm32/mmu/mm.c
+++ b/xen/arch/arm/arm32/mmu/mm.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -31,100 +32,6 @@ static void __init setup_directmap_mappings(unsigned long base_mfn,
     directmap_virt_end = XENHEAP_VIRT_START + nr_mfns * PAGE_SIZE;
 }
 
-/*
- * Returns the end address of the highest region in the range s..e
- * with required size and alignment that does not conflict with the
- * modules from first_mod to nr_modules.
- *
- * For non-recursive callers first_mod should normally be 0 (all
- * modules and Xen itself) or 1 (all modules but not Xen).
- */
-static paddr_t __init consider_modules(paddr_t s, paddr_t e,
-                                       uint32_t size, paddr_t align,
-                                       int first_mod)
-{
-    const struct membanks *reserved_mem = bootinfo_get_reserved_mem();
-#ifdef CONFIG_STATIC_SHM
-    const struct membanks *shmem = bootinfo_get_shmem();
-#endif
-    const struct bootmodules *mi = &bootinfo.modules;
-    int i;
-    int nr;
-
-    s = (s+align-1) & ~(align-1);
-    e = e & ~(align-1);
-
-    if ( s > e ||  e - s < size )
-        return 0;
-
-    /* First check the boot modules */
-    for ( i = first_mod; i < mi->nr_mods; i++ )
-    {
-        paddr_t mod_s = mi->module[i].start;
-        paddr_t mod_e = mod_s + mi->module[i].size;
-
-        if ( s < mod_e && mod_s < e )
-        {
-            mod_e = consider_modules(mod_e, e, size, align, i+1);
-            if ( mod_e )
-                return mod_e;
-
-            return consider_modules(s, mod_s, size, align, i+1);
-        }
-    }
-
-    /*
-     * i is the current bootmodule we are evaluating, across all
-     * possible kinds of bootmodules.
-     *
-     * When retrieving the corresponding reserved-memory addresses, we
-     * need to index the reserved_mem bank starting from 0, and only counting
-     * the reserved-memory modules. Hence, we need to use i - nr.
-     */
-    nr = mi->nr_mods;
-    for ( ; i - nr < reserved_mem->nr_banks; i++ )
-    {
-        paddr_t r_s = reserved_mem->bank[i - nr].start;
-        paddr_t r_e = r_s + reserved_mem->bank[i - nr].size;
-
-        if ( s < r_e && r_s < e )
-        {
-            r_e = consider_modules(r_e, e, size, align, i + 1);
-            if ( r_e )
-                return r_e;
-
-            return consider_modules(s, r_s, size, align, i + 1);
-        }
-    }
-
-#ifdef CONFIG_STATIC_SHM
-    nr += reserved_mem->nr_banks;
-    for ( ; i - nr < shmem->nr_banks; i++ )
-    {
-        paddr_t r_s, r_e;
-
-        r_s = shmem->bank[i - nr].start;
-
-        /* Shared memory banks can contain INVALID_PADDR as start */
-        if ( INVALID_PADDR == r_s )
-            continue;
-
-        r_e = r_s + shmem->bank[i - nr].size;
-
-        if ( s < r_e && r_s < e )
-        {
-            r_e = consider_modules(r_e, e, size, align, i + 1);
-            if ( r_e )
-                return r_e;
-
-            return consider_modules(s, r_s, size, align, i + 1);
-        }
-    }
-#endif
-
-    return e;
-}
-
 /*
  * Find a contiguous region that fits in the static heap region with
  * required size and alignment, and return the end address of the region
diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index a5a80d9b47..6cf272c160 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -81,6 +81,9 @@ struct init_info
     unsigned int cpuid;
 };
 
+paddr_t consider_modules(paddr_t s, paddr_t e, uint32_t size, paddr_t align,
+                         int first_mod);
+
 #endif
 /*
  * Local variables:
diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c
index 8c87649bc8..041e3fc1b6 100644
--- a/xen/arch/arm/mmu/setup.c
+++ b/xen/arch/arm/mmu/setup.c
@@ -222,6 +222,100 @@ static void xen_pt_enforce_wnx(void)
     flush_xen_tlb_local();
 }
 
+/*
+ * Returns the end address of the highest region in the range s..e
+ * with required size and alignment that does not conflict with the
+ * modules from first_mod to nr_modules.
+ *
+ * For non-recursive callers first_mod should normally be 0 (all
+ * modules and Xen itself) or 1 (all modules but not Xen).
+ */
+paddr_t __init consider_modules(paddr_t s, paddr_t e,
+                                uint32_t size, paddr_t align,
+                                int first_mod)
+{
+    const struct membanks *reserved_mem = bootinfo_get_reserved_mem();
+#ifdef CONFIG_STATIC_SHM
+    const struct membanks *shmem = bootinfo_get_shmem();
+#endif
+    const struct bootmodules *mi = &bootinfo.modules;
+    int i;
+    int nr;
+
+    s = (s+align-1) & ~(align-1);
+    e = e & ~(align-1);
+
+    if ( s > e ||  e - s < size )
+        return 0;
+
+    /* First check the boot modules */
+    for ( i = first_mod; i < mi->nr_mods; i++ )
+    {
+        paddr_t mod_s = mi->module[i].start;
+        paddr_t mod_e = mod_s + mi->module[i].size;
+
+        if ( s < mod_e && mod_s < e )
+        {
+            mod_e = consider_modules(mod_e, e, size, align, i+1);
+            if ( mod_e )
+                return mod_e;
+
+            return consider_modules(s, mod_s, size, align, i+1);
+        }
+    }
+
+    /*
+     * i is the current bootmodule we are evaluating, across all
+     * possible kinds of bootmodules.
+     *
+     * When retrieving the corresponding reserved-memory addresses, we
+     * need to index the reserved_mem bank starting from 0, and only counting
+     * the reserved-memory modules. Hence, we need to use i - nr.
+     */
+    nr = mi->nr_mods;
+    for ( ; i - nr < reserved_mem->nr_banks; i++ )
+    {
+        paddr_t r_s = reserved_mem->bank[i - nr].start;
+        paddr_t r_e = r_s + reserved_mem->bank[i - nr].size;
+
+        if ( s < r_e && r_s < e )
+        {
+            r_e = consider_modules(r_e, e, size, align, i + 1);
+            if ( r_e )
+                return r_e;
+
+            return consider_modules(s, r_s, size, align, i + 1);
+        }
+    }
+
+#ifdef CONFIG_STATIC_SHM
+    nr += reserved_mem->nr_banks;
+    for ( ; i - nr < shmem->nr_banks; i++ )
+    {
+        paddr_t r_s, r_e;
+
+        r_s = shmem->bank[i - nr].start;
+
+        /* Shared memory banks can contain INVALID_PADDR as start */
+        if ( INVALID_PADDR == r_s )
+            continue;
+
+        r_e = r_s + shmem->bank[i - nr].size;
+
+        if ( s < r_e && r_s < e )
+        {
+            r_e = consider_modules(r_e, e, size, align, i + 1);
+            if ( r_e )
+                return r_e;
+
+            return consider_modules(s, r_s, size, align, i + 1);
+        }
+    }
+#endif
+
+    return e;
+}
+
 /*
  * Boot-time pagetable setup.
  * Changes here may need matching changes in head.S
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:30:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:30:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859728.1271827 (Exim 4.92)
	(envelope-from )
	id 1tNbOO-0001qh-H0; Tue, 17 Dec 2024 17:29:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859728.1271827; Tue, 17 Dec 2024 17:29:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNbOO-0001qa-E2; Tue, 17 Dec 2024 17:29:56 +0000
Received: by outflank-mailman (input) for mailman id 859728;
 Tue, 17 Dec 2024 17:29: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 1tNbOM-0001qT-TF
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:29:54 +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 86d18c29-bc9c-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 18:29:53 +0100 (CET)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-436202dd7f6so60804835e9.0
 for ; Tue, 17 Dec 2024 09:29:53 -0800 (PST)
Received: from andrewcoop.eng.citrite.net (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c8015f77sm11600774f8f.26.2024.12.17.09.29.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 09:29: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: 86d18c29-bc9c-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734456592; x=1735061392; 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=wB8oEjq9ZSqRoE9MS1vzGSMKSvz1WjieQBNGzyPq31E=;
        b=Zs9ywTdIGKGdklIOFYqIvLxiyQpQDFKc5NAVzx3jotzBkzrS/iY+mFzK5Vz1RMFQnl
         1F4be//5iCmzaMki2mOvhCY0slksC6/oM7etlZOS+jyVil7tGWY6W2bk7SYmaaofT9XC
         zFtcCFFXtTidH/QENYkPgbwICOheFKwd39R8E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734456592; x=1735061392;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=wB8oEjq9ZSqRoE9MS1vzGSMKSvz1WjieQBNGzyPq31E=;
        b=D5dCIqam9MNtFzzHTFlulQZMZ0H2/kxc1iDVweJfqz3YCuywJnTHMxgn14wFa+w88D
         ZS0KQLBKfd0blecBqY5wlu8V8GhPZ2bXr0g2qDQMRoplaKT/wQD5jsCvdAC232vVTA6W
         VJeGIqLEizFo+LFqG79uKgA1o6+vT92QBGTSHhKOjLBfMGVwcFvF5NHDA9KApwM+jtdn
         +IlYwhZ7JHEHFcFd864fHJ5EdoDlJNuzqSnCLw7WabxrIv60EtGtaH7+f254q2IqR+WX
         +UrIFBsfpUzTg2jGtizsAN/k+44vJTusVpV0J4I3C0eB0Ht+xGHbleAAYr9+2URP2R7I
         4QNA==
X-Gm-Message-State: AOJu0YyKmbFsc3Q+el7nqUwblJSDtTXwKUhM52kPo6VRQwM2C9F2N/wU
	ZSXBfV7PUMEISGOOcePw+WgOO9JLK9G63bFu3Zxz/I3LcDT4wy5KSV4XVyV3vghlKtgPY5d9oiL
	nkZo=
X-Gm-Gg: ASbGncsqE44IxT9lglGyTYQE7OXQuftzPIkxvw85u8CHis8EkmEdKpg41JckquwJS/G
	qZowcteC8k4WDw219qb0Q8IFo4NHaDjAvH7oPcct2tf3guwC26D6X3drZ3fPk43WLuZFlXP6gtN
	TuqlIRBya6QJHUGU8Ke6Iw9eNgKUonF/1mY3E6AV0rCmm2rACAIt0xiUJZ8mZrGcTW0rMyEB38f
	0FhjM6qsW0pGVUJsLYviGQKwDqPJh7UIciymbOsKEreOGD1Y6nHftgNVjIl6fI1UD1wjF/DJJn8
	bWmNu5ORYI+azPLlQRVY2LmFYyGfeTLnOyJA
X-Google-Smtp-Source: AGHT+IHUwydTs1PlYSTsVg1gLukHNq/4TvvejAgO9E/Szg76zWBzac9UdKJJULIz/pGn9zlC3tolow==
X-Received: by 2002:a05:600c:871b:b0:434:e9ee:c3d with SMTP id 5b1f17b1804b1-4362aa93cb0mr135506755e9.20.1734456592591;
        Tue, 17 Dec 2024 09:29:52 -0800 (PST)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	"consulting @ bugseng . com" ,
	Nicola Vetrini ,
	Alessandro Zucchelli 
Subject: [PATCH] MISRA: Unmark Rules 1.1 and 2.1 as clean following Eclair upgrade
Date: Tue, 17 Dec 2024 17:29:50 +0000
Message-Id: <20241217172950.43626-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

Updating the Eclair runner has had knock-on effects with previously-clean
rules now flagging violations:

 - x86:   Rule 1.1, 1940 violations
 - ARM64: Rule 1.1, 725 violations, Rule 2.1, 255 violations

Fixes: 631f535a3d4f ("xen: update ECLAIR service identifiers from MC3R1 to MC3A2.")
Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Jan Beulich 
CC: Julien Grall 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: consulting@bugseng.com 
CC: Nicola Vetrini 
CC: Alessandro Zucchelli 

This is a speculative fix, but is the most simple fallback.

Nicola has posted a patch to fix the R1.1 failure (I can drop that hunk if the
fix is ok), but I see nothing so easy for ARM's R2.1 failure.

Also Xen 4.18 needs extra backports in order to build.
---
 automation/eclair_analysis/ECLAIR/tagging.ecl | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
index b5243185915f..982f506cc7b6 100644
--- a/automation/eclair_analysis/ECLAIR/tagging.ecl
+++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
@@ -25,7 +25,6 @@ MC3A2.D2.1||
 MC3A2.D4.1||
 MC3A2.D4.11||
 MC3A2.D4.14||
-MC3A2.R1.1||
 MC3A2.R1.3||
 MC3A2.R1.4||
 MC3A2.R2.6||
@@ -116,7 +115,7 @@ if(string_equal(target,"x86_64"),
 )
 
 if(string_equal(target,"arm64"),
-    service_selector({"additional_clean_guidelines","MC3A2.R2.1||MC3A2.R5.3||MC3.R11.2||MC3A2.R16.6||MC3A2.R20.7"})
+    service_selector({"additional_clean_guidelines","MC3A2.R5.3||MC3.R11.2||MC3A2.R16.6||MC3A2.R20.7"})
 )
 
 -reports+={clean:added,"service(clean_guidelines_common||additional_clean_guidelines)"}

base-commit: 631f535a3d4ffd66a270672f0f787d79f3bf38f8
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:33:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:33:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859740.1271838 (Exim 4.92)
	(envelope-from )
	id 1tNbRo-0003rh-2q; Tue, 17 Dec 2024 17:33:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859740.1271838; Tue, 17 Dec 2024 17:33:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNbRo-0003ra-07; Tue, 17 Dec 2024 17:33:28 +0000
Received: by outflank-mailman (input) for mailman id 859740;
 Tue, 17 Dec 2024 17:33: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 1tNbRl-0003pw-Up
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:33:26 +0000
Received: from mail3-relais-sop.national.inria.fr
 (mail3-relais-sop.national.inria.fr [192.134.164.104])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 03b9c285-bc9d-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 18:33:23 +0100 (CET)
Received: from 231.85.89.92.rev.sfr.net (HELO hadrien) ([92.89.85.231])
 by mail3-relais-sop.national.inria.fr with
 ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Dec 2024 18:33:20 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 03b9c285-bc9d-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=inria.fr; s=dc;
  h=date:from:to:cc:subject:in-reply-to:message-id:
   references:mime-version;
  bh=04pTIo5ApWySSg1irLecWsNtdqZYhiDphbsaLsL2++E=;
  b=EaNS0yuhC4s6iN6WnIrnfVVUKM6YqvVWkIbgcSrxq8z6qdZxbvXYN/B4
   9evJrozXCky5ezt+egWk2fvFzCjCGhd/6dlOUNDuVRw1L3nJUFrUuyJTW
   ezsZJHG7RK8qkYyuGARiZzCMp891lCLljEEn1C5atxdbFGiHm+3aLIRi2
   4=;
Authentication-Results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=julia.lawall@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr
X-IronPort-AV: E=Sophos;i="6.12,242,1728943200"; 
   d="scan'208";a="104581457"
Date: Tue, 17 Dec 2024 18:33:18 +0100 (CET)
From: Julia Lawall 
X-X-Sender: jll@hadrien
To: Alexander Gordeev 
cc: Easwar Hariharan , 
    Pablo Neira Ayuso , 
    Jozsef Kadlecsik , 
    "David S. Miller" , 
    Eric Dumazet , Jakub Kicinski , 
    Paolo Abeni , Simon Horman , 
    Julia Lawall , 
    Nicolas Palix , Daniel Mack , 
    Haojian Zhuang , 
    Robert Jarzmik , 
    Russell King , Heiko Carstens , 
    Vasily Gorbik , 
    Christian Borntraeger , 
    Sven Schnelle , Ofir Bitton , 
    Oded Gabbay , 
    Lucas De Marchi , 
    =?ISO-8859-15?Q?Thomas_Hellstr=F6m?= , 
    Rodrigo Vivi , 
    Maarten Lankhorst , 
    Maxime Ripard , 
    Thomas Zimmermann , David Airlie , 
    Simona Vetter , Jeroen de Borst , 
    Praveen Kaligineedi , 
    Shailend Chand , Andrew Lunn , 
    James Smart , 
    Dick Kennedy , 
    "James E.J. Bottomley" , 
    "Martin K. Petersen" , 
    =?ISO-8859-15?Q?Roger_Pau_Monn=E9?= , 
    Jens Axboe , Kalle Valo , 
    Jeff Johnson , 
    Catalin Marinas , 
    Andrew Morton , 
    Jack Wang , 
    Marcel Holtmann , 
    Johan Hedberg , 
    Luiz Augusto von Dentz , 
    Greg Kroah-Hartman , 
    Florian Fainelli , 
    Ray Jui , Scott Branden , 
    Broadcom internal kernel review list , 
    Xiubo Li , Ilya Dryomov , 
    Josh Poimboeuf , Jiri Kosina , 
    Miroslav Benes , Petr Mladek , 
    Joe Lawrence , Jaroslav Kysela , 
    Takashi Iwai , Louis Peens , 
    Michael Ellerman , Nicholas Piggin , 
    Christophe Leroy , 
    Naveen N Rao , 
    Madhavan Srinivasan , netfilter-devel@vger.kernel.org, 
    coreteam@netfilter.org, netdev@vger.kernel.org, 
    linux-kernel@vger.kernel.org, cocci@inria.fr, 
    linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, 
    dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, 
    linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org, 
    linux-block@vger.kernel.org, linux-wireless@vger.kernel.org, 
    ath11k@lists.infradead.org, linux-mm@kvack.org, 
    linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev, 
    linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org, 
    live-patching@vger.kernel.org, linux-sound@vger.kernel.org, 
    oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, 
    Anna-Maria Behnsen 
Subject: Re: [PATCH v3 02/19] coccinelle: misc: Add secs_to_jiffies script
In-Reply-To: 
Message-ID: 
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com> <20241210-converge-secs-to-jiffies-v3-2-ddfefd7e9f2a@linux.microsoft.com> 
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII



On Tue, 17 Dec 2024, Alexander Gordeev wrote:

> On Tue, Dec 10, 2024 at 10:02:33PM +0000, Easwar Hariharan wrote:
>
> Hi Easwar,
>
> > This script finds and suggests conversions of timeout patterns that
> > result in seconds-denominated timeouts to use the new secs_to_jiffies()
> > API in include/linux/jiffies.h for better readability.
> >
> > Suggested-by: Anna-Maria Behnsen 
> > Signed-off-by: Easwar Hariharan 
> > ---
> >  scripts/coccinelle/misc/secs_to_jiffies.cocci | 22 ++++++++++++++++++++++
> >  1 file changed, 22 insertions(+)
> >
> > diff --git a/scripts/coccinelle/misc/secs_to_jiffies.cocci b/scripts/coccinelle/misc/secs_to_jiffies.cocci
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..8bbb2884ea5db939c63fd4513cf5ca8c977aa8cb
> > --- /dev/null
> > +++ b/scripts/coccinelle/misc/secs_to_jiffies.cocci
> > @@ -0,0 +1,22 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +///
> > +/// Find usages of:
> > +/// - msecs_to_jiffies(value*1000)
> > +/// - msecs_to_jiffies(value*MSEC_PER_SEC)
> > +///
> > +// Confidence: High
> > +// Copyright: (C) 2024 Easwar Hariharan, Microsoft
> > +// Keywords: secs, seconds, jiffies
> > +//
> > +
> > +virtual patch
> > +
> > +@depends on patch@ constant C; @@
> > +
> > +- msecs_to_jiffies(C * 1000)
> > ++ secs_to_jiffies(C)
> > +
> > +@depends on patch@ constant C; @@
> > +
> > +- msecs_to_jiffies(C * MSEC_PER_SEC)
> > ++ secs_to_jiffies(C)
>
> If you used this script only, then it did not seem to recognize line arch/s390/mm/cmm.c:207
>
> 	mod_timer(&cmm_timer, jiffies + msecs_to_jiffies(cmm_timeout_seconds * MSEC_PER_SEC));

There is the requirement that C is a constant, and cmm_timeout_seconds is
not considered to be a constant, ie it is not all capital letters.
Indeed, it doesn't seem to be a constant at all.  I don't know if the
requirement of being a comstant is really necessary.

julia

>
> Thanks!
>


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:33:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:33:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859741.1271848 (Exim 4.92)
	(envelope-from )
	id 1tNbRq-00047n-An; Tue, 17 Dec 2024 17:33:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859741.1271848; Tue, 17 Dec 2024 17:33: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 1tNbRq-00047g-6e; Tue, 17 Dec 2024 17:33:30 +0000
Received: by outflank-mailman (input) for mailman id 859741;
 Tue, 17 Dec 2024 17:33: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 1tNbRo-0003r3-FF
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:33:28 +0000
Received: from mail179-16.suw41.mandrillapp.com
 (mail179-16.suw41.mandrillapp.com [198.2.179.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 051caf4f-bc9d-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 18:33:26 +0100 (CET)
Received: from pmta12.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail179-16.suw41.mandrillapp.com (Mailchimp) with ESMTP id
 4YCP6X5Q7bzB5qYdJ
 for ; Tue, 17 Dec 2024 17:33:24 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 9ec811cf02754aa29e21200cfff0775a; Tue, 17 Dec 2024 17:33: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: 051caf4f-bc9d-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1734456804; x=1734717304;
	bh=h3ZT4OBhKIwyNI1UGD/oAXQV03lWDod1gteYPImIABU=;
	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=Ml2UbnncDqrMFuDSjgo+nPPwCm4NlsByxV/apRZ5vsiJSDqDDbsAh+/F8UqB5Ds6c
	 mcaF4TLTfhSPoXT9OCuK1h4E6K584dj9h/FhTGN/qAVtM7WeY2RCFBIKEyPQrC7Gj+
	 YPWsomK7DllcYir0iUbXNJZoLKTczMnpJ+10LRazP6vFy/iq0TuQI6Nkj5qoczpQFM
	 HWkdE98kuJLtLipFHFhy8UP1Uqa+jOUTOTLXeJpU7jICI93Ae0RrFbL7Dra34Ne22S
	 P8PVo+AusQSqQN1/gqfi/xgTC3AZODc2p/7erZDlJYFqLmr3RmfKlG11PEbRwR+DxC
	 lixEKwrFPcdfQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1734456804; x=1734717304; i=anthony.perard@vates.tech;
	bh=h3ZT4OBhKIwyNI1UGD/oAXQV03lWDod1gteYPImIABU=;
	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=xA5hBLA4Qe5AvroZgyAwNcEcYWcma4hBSbgt2Dg4aqYV0euAQ8ao55QdIXeHhoL9A
	 No3KD21UCMzfyFIFfFfveK32adqBKahjfAleQdN8+J+0+DlWA8FlTQ8bmpxtGRYGwJ
	 cz6sm4U1+YiUiVDw7rsF463HeTOqs4EUzXPvB60kwVBM/FXP0g22C4hXfupLN7/jv2
	 /TrwuU9fHlJWYRAN7ya2Og11DHuzXKjTvtmvDevacDt3IzFvbwPyOm28dXA5zOd7jP
	 SJHhCesQBC8GYav1dhITvzv++5cATDm2e+GY7PlnOGei0eekaqx1KuefCce/8GANdR
	 lOSYU4l2FUSQg==
From: "Anthony PERARD" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v5=205/5]=20tools/xenstored:=20use=20new=20stable=20interface=20instead=20of=20libxenctrl?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1734456803986
To: "Juergen Gross" 
Cc: xen-devel@lists.xenproject.org, "Samuel Thibault" , "Julien Grall" 
Message-Id: 
References: <20241217142218.24129-1-jgross@suse.com> <20241217142218.24129-6-jgross@suse.com>
In-Reply-To: <20241217142218.24129-6-jgross@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.9ec811cf02754aa29e21200cfff0775a?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20241217:md
Date: Tue, 17 Dec 2024 17:33:24 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On Tue, Dec 17, 2024 at 03:22:18PM +0100, Juergen Gross wrote:
> diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c
> index 64c8fd0cc3..a6506a5bb2 100644
> --- a/tools/xenstored/domain.c
> +++ b/tools/xenstored/domain.c
> @@ -1258,15 +1248,9 @@ void domain_early_init(void)
>  	if (!domhash)
>  		barf_perror("Failed to allocate domain hashtable");
>  
> -	xc_handle = talloc(talloc_autofree_context(), xc_interface*);
> -	if (!xc_handle)
> -		barf_perror("Failed to allocate domain handle");
> -
> -	*xc_handle = xc_interface_open(0,0,0);
> -	if (!*xc_handle)
> -		barf_perror("Failed to open connection to hypervisor");
> -
> -	talloc_set_destructor(xc_handle, close_xc_handle);
> +	xm_handle = xenmanage_open(NULL, 0);
> +	if (!xm_handle)
> +		barf_perror("Failed to open connection to libxenmanage");
>  
>  	xgt_handle = talloc(talloc_autofree_context(), xengnttab_handle*);
>  	if (!xgt_handle)
> @@ -1306,6 +1290,8 @@ void domain_deinit(void)
>  {
>  	if (virq_port)
>  		xenevtchn_unbind(xce_handle, virq_port);
> +
> +	xenmanage_close(xm_handle);

Is this the rigth place to free `xm_handle`? domain_deinit() seems to
only be called by the live update code. All the other initialisation
done in domain_early_init() are free via talloc_autofree() it seems,
which is called by atexit().

So, shouldn't `xm_handle` by handle with talloc like the others?

Thanks,

-- 

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:42:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:42:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859737.1271863 (Exim 4.92)
	(envelope-from )
	id 1tNbal-0007h4-BA; Tue, 17 Dec 2024 17:42:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859737.1271863; Tue, 17 Dec 2024 17:42: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 1tNbal-0007gd-7J; Tue, 17 Dec 2024 17:42:43 +0000
Received: by outflank-mailman (input) for mailman id 859737;
 Tue, 17 Dec 2024 17:32: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 1tNbQQ-0003Vk-JT
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:32:02 +0000
Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com
 [148.163.158.5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d1ffbd69-bc9c-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 18:32:00 +0100 (CET)
Received: from pps.filterd (m0353725.ppops.net [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BHE6H87020846;
 Tue, 17 Dec 2024 17:31:23 GMT
Received: from ppma11.dal12v.mail.ibm.com
 (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 43kas4s2rw-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 17 Dec 2024 17:31:23 +0000 (GMT)
Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1])
 by ppma11.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 4BHDwPa9014391;
 Tue, 17 Dec 2024 17:31:22 GMT
Received: from smtprelay05.fra02v.mail.ibm.com ([9.218.2.225])
 by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 43hq21kftu-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 17 Dec 2024 17:31:22 +0000
Received: from smtpav07.fra02v.mail.ibm.com (smtpav07.fra02v.mail.ibm.com
 [10.20.54.106])
 by smtprelay05.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 4BHHVImO33161492
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 17 Dec 2024 17:31:18 GMT
Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 7AC1320040;
 Tue, 17 Dec 2024 17:31:18 +0000 (GMT)
Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 3AC5E20043;
 Tue, 17 Dec 2024 17:31:17 +0000 (GMT)
Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown
 [9.155.204.135])
 by smtpav07.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Tue, 17 Dec 2024 17:31:17 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: d1ffbd69-bc9c-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=pp1; bh=Qku009jdAu0Sgq06JBD3twBP+vP3Pl
	e+4ZyDkim0IzU=; b=MTO/Z+o64j+lMdlSt7lwGrgEQppRaLzv9IemetXvJVf+eQ
	cDcMHOowL34r8UPq4AkzwJy+6AWYi1tChb1UBoo4veqGiPUdkwFr8rpVFiuN71m8
	4Wx9vkdpH3EtO5Hv3GdirgS69Lcr5+qFtZbefM2/H+mmJp/+ICb8xWKAOli3haFo
	9qNOCbrE9oWnu8acOVKIDOgwMbAarQxEacZSNkXgLjhk512BYMMs29gN0AV2mmsQ
	PdhP7cGWESbpvwRlQJc8Ko7koVPBuDV/7R/r8/lqWG+jNl3AtSdaRFKqfO/+GxUQ
	UlSlIuxSuvNJlTiWhAHsT2md7A5meFzErQ9cQ+1A==
Date: Tue, 17 Dec 2024 18:31:16 +0100
From: Alexander Gordeev 
To: Easwar Hariharan 
Cc: Pablo Neira Ayuso ,
        Jozsef Kadlecsik ,
        "David S. Miller" ,
        Eric Dumazet , Jakub Kicinski ,
        Paolo Abeni , Simon Horman ,
        Julia Lawall ,
        Nicolas Palix , Daniel Mack ,
        Haojian Zhuang ,
        Robert Jarzmik ,
        Russell King ,
        Heiko Carstens , Vasily Gorbik ,
        Christian Borntraeger ,
        Sven Schnelle , Ofir Bitton ,
        Oded Gabbay ,
        Lucas De Marchi ,
        Thomas =?iso-8859-1?Q?Hellstr=F6m?= ,
        Rodrigo Vivi ,
        Maarten Lankhorst ,
        Maxime Ripard ,
        Thomas Zimmermann ,
        David Airlie , Simona Vetter ,
        Jeroen de Borst ,
        Praveen Kaligineedi ,
        Shailend Chand ,
        Andrew Lunn ,
        James Smart ,
        Dick Kennedy ,
        "James E.J. Bottomley" ,
        "Martin K. Petersen" ,
        Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
        Jens Axboe , Kalle Valo ,
        Jeff Johnson ,
        Catalin Marinas ,
        Andrew Morton ,
        Jack Wang ,
        Marcel Holtmann ,
        Johan Hedberg ,
        Luiz Augusto von Dentz ,
        Greg Kroah-Hartman ,
        Florian Fainelli ,
        Ray Jui , Scott Branden ,
        Broadcom internal kernel review list ,
        Xiubo Li , Ilya Dryomov ,
        Josh Poimboeuf , Jiri Kosina ,
        Miroslav Benes , Petr Mladek ,
        Joe Lawrence ,
        Jaroslav Kysela , Takashi Iwai ,
        Louis Peens ,
        Michael Ellerman ,
        Nicholas Piggin ,
        Christophe Leroy ,
        Naveen N Rao ,
        Madhavan Srinivasan ,
        netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr,
        linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
        dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
        linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-block@vger.kernel.org, linux-wireless@vger.kernel.org,
        ath11k@lists.infradead.org, linux-mm@kvack.org,
        linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev,
        linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org,
        live-patching@vger.kernel.org, linux-sound@vger.kernel.org,
        oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org,
        Anna-Maria Behnsen 
Subject: Re: [PATCH v3 04/19] s390: kernel: Convert timeouts to use
 secs_to_jiffies()
Message-ID: 
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
 <20241210-converge-secs-to-jiffies-v3-4-ddfefd7e9f2a@linux.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-4-ddfefd7e9f2a@linux.microsoft.com>
X-TM-AS-GCONF: 00
X-Proofpoint-ORIG-GUID: FFAKPmsOF7TzSfPGY_r91-e9_TqDPMGg
X-Proofpoint-GUID: FFAKPmsOF7TzSfPGY_r91-e9_TqDPMGg
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1051,Hydra:6.0.680,FMLib:17.12.62.30
 definitions=2024-10-15_01,2024-10-11_01,2024-09-30_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 bulkscore=0
 mlxlogscore=999 mlxscore=0 impostorscore=0 lowpriorityscore=0
 priorityscore=1501 malwarescore=0 spamscore=0 clxscore=1011 phishscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.19.0-2411120000 definitions=main-2412170134

On Tue, Dec 10, 2024 at 10:02:35PM +0000, Easwar Hariharan wrote:
> Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
> secs_to_jiffies(). As the values here are a multiple of 1000, use
> secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
> 
> This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
> the following Coccinelle rules:
> 
> @@ constant C; @@
> 
> - msecs_to_jiffies(C * 1000)
> + secs_to_jiffies(C)
> 
> @@ constant C; @@
> 
> - msecs_to_jiffies(C * MSEC_PER_SEC)
> + secs_to_jiffies(C)
> 
> Signed-off-by: Easwar Hariharan 
> ---
>  arch/s390/kernel/lgr.c      | 2 +-
>  arch/s390/kernel/time.c     | 4 ++--
>  arch/s390/kernel/topology.c | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/s390/kernel/lgr.c b/arch/s390/kernel/lgr.c
> index 6652e54cf3db9fbdd8cfb06f8a0dc1d4c05ae7d7..6d1ffca5f798086160112990cb947ec8deed0659 100644
> --- a/arch/s390/kernel/lgr.c
> +++ b/arch/s390/kernel/lgr.c
> @@ -166,7 +166,7 @@ static struct timer_list lgr_timer;
>   */
>  static void lgr_timer_set(void)
>  {
> -	mod_timer(&lgr_timer, jiffies + msecs_to_jiffies(LGR_TIMER_INTERVAL_SECS * MSEC_PER_SEC));
> +	mod_timer(&lgr_timer, jiffies + secs_to_jiffies(LGR_TIMER_INTERVAL_SECS));
>  }
>  
>  /*
> diff --git a/arch/s390/kernel/time.c b/arch/s390/kernel/time.c
> index 34a65c141ea076ba97b3238f1f36f077b15961df..e9f47c3a61978a45c72aee23bc44dcb128113c8c 100644
> --- a/arch/s390/kernel/time.c
> +++ b/arch/s390/kernel/time.c
> @@ -662,12 +662,12 @@ static void stp_check_leap(void)
>  		if (ret < 0)
>  			pr_err("failed to set leap second flags\n");
>  		/* arm Timer to clear leap second flags */
> -		mod_timer(&stp_timer, jiffies + msecs_to_jiffies(14400 * MSEC_PER_SEC));
> +		mod_timer(&stp_timer, jiffies + secs_to_jiffies(14400));
>  	} else {
>  		/* The day the leap second is scheduled for hasn't been reached. Retry
>  		 * in one hour.
>  		 */
> -		mod_timer(&stp_timer, jiffies + msecs_to_jiffies(3600 * MSEC_PER_SEC));
> +		mod_timer(&stp_timer, jiffies + secs_to_jiffies(3600));
>  	}
>  }
>  
> diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
> index 4f9c301a705b63f8dd0e7bc33e7206ad1222e7a7..0fd56a1cadbd4f41a9876a3a3fec7f5dc08ac2db 100644
> --- a/arch/s390/kernel/topology.c
> +++ b/arch/s390/kernel/topology.c
> @@ -371,7 +371,7 @@ static void set_topology_timer(void)
>  	if (atomic_add_unless(&topology_poll, -1, 0))
>  		mod_timer(&topology_timer, jiffies + msecs_to_jiffies(100));
>  	else
> -		mod_timer(&topology_timer, jiffies + msecs_to_jiffies(60 * MSEC_PER_SEC));
> +		mod_timer(&topology_timer, jiffies + secs_to_jiffies(60));
>  }
>  
>  void topology_expect_change(void)

With this chunk added to the patch:

diff --git a/arch/s390/mm/cmm.c b/arch/s390/mm/cmm.c
index d01724a715d0..7bf0f691827b 100644
--- a/arch/s390/mm/cmm.c
+++ b/arch/s390/mm/cmm.c
@@ -204,7 +204,7 @@ static void cmm_set_timer(void)
 			del_timer(&cmm_timer);
 		return;
 	}
-	mod_timer(&cmm_timer, jiffies + msecs_to_jiffies(cmm_timeout_seconds * MSEC_PER_SEC));
+	mod_timer(&cmm_timer, jiffies + secs_to_jiffies(cmm_timeout_seconds));
 }
 
 static void cmm_timer_fn(struct timer_list *unused)


Acked-by: Alexander Gordeev 


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:42:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:42:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859735.1271858 (Exim 4.92)
	(envelope-from )
	id 1tNbal-0007fI-49; Tue, 17 Dec 2024 17:42:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859735.1271858; Tue, 17 Dec 2024 17:42: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 1tNbal-0007fB-1C; Tue, 17 Dec 2024 17:42:43 +0000
Received: by outflank-mailman (input) for mailman id 859735;
 Tue, 17 Dec 2024 17:30: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 1tNbP9-0001qT-Na
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:30:43 +0000
Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com
 [148.163.158.5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a399a174-bc9c-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 18:30:42 +0100 (CET)
Received: from pps.filterd (m0360072.ppops.net [127.0.0.1])
 by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BHHJOLq032407;
 Tue, 17 Dec 2024 17:29:15 GMT
Received: from ppma11.dal12v.mail.ibm.com
 (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219])
 by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 43k5g2jmnp-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 17 Dec 2024 17:29:14 +0000 (GMT)
Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1])
 by ppma11.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 4BHDmDdx014412;
 Tue, 17 Dec 2024 17:29:03 GMT
Received: from smtprelay03.fra02v.mail.ibm.com ([9.218.2.224])
 by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 43hq21kfhm-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Tue, 17 Dec 2024 17:29:03 +0000
Received: from smtpav06.fra02v.mail.ibm.com (smtpav06.fra02v.mail.ibm.com
 [10.20.54.105])
 by smtprelay03.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id
 4BHHT0u259441574
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Tue, 17 Dec 2024 17:29:00 GMT
Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id 0EEE820040;
 Tue, 17 Dec 2024 17:29:00 +0000 (GMT)
Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1])
 by IMSVA (Postfix) with ESMTP id E39DD2004B;
 Tue, 17 Dec 2024 17:28:58 +0000 (GMT)
Received: from li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com (unknown
 [9.155.204.135])
 by smtpav06.fra02v.mail.ibm.com (Postfix) with ESMTPS;
 Tue, 17 Dec 2024 17:28:58 +0000 (GMT)
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a399a174-bc9c-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc
	:content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to; s=pp1; bh=g1hrCVwsLDHFXBw9S8SSEtW44ND3hI
	e5hEs7mvzMcv0=; b=cl9r35o36KsL7jJKYCoj5LWAqgbCAwKQJ20PeY0lNPC00K
	Wb2kXbck5OilzEheJEhO1UdwI+su1vwZEx+ymJ0mFVZPhk383HWoO7VUfjl4QPyC
	NRZU5GuH7HUeI7pIrbgheTo3G3YyL9iJUTzTdJ2rQy11ZZUXxk/oz1ZsT4ro/HXW
	RF1p1weL++6yCLkAsXqi4doi+5uKWL9CuTqE9RqoY9qtQhM5eVDQSPo42O2F/pZf
	1E2hEAM56w/Zk8qrE4sU++MACbkaEvxnTnuSkGX19AfN+yNNhecbQM6ZfMsHhRv0
	9OFeYY0UtsvX1JEiQmcTgZp6vrtBDv/o0B5nndaw==
Date: Tue, 17 Dec 2024 18:28:57 +0100
From: Alexander Gordeev 
To: Easwar Hariharan 
Cc: Pablo Neira Ayuso ,
        Jozsef Kadlecsik ,
        "David S. Miller" ,
        Eric Dumazet , Jakub Kicinski ,
        Paolo Abeni , Simon Horman ,
        Julia Lawall ,
        Nicolas Palix , Daniel Mack ,
        Haojian Zhuang ,
        Robert Jarzmik ,
        Russell King ,
        Heiko Carstens , Vasily Gorbik ,
        Christian Borntraeger ,
        Sven Schnelle , Ofir Bitton ,
        Oded Gabbay ,
        Lucas De Marchi ,
        Thomas =?iso-8859-1?Q?Hellstr=F6m?= ,
        Rodrigo Vivi ,
        Maarten Lankhorst ,
        Maxime Ripard ,
        Thomas Zimmermann ,
        David Airlie , Simona Vetter ,
        Jeroen de Borst ,
        Praveen Kaligineedi ,
        Shailend Chand ,
        Andrew Lunn ,
        James Smart ,
        Dick Kennedy ,
        "James E.J. Bottomley" ,
        "Martin K. Petersen" ,
        Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
        Jens Axboe , Kalle Valo ,
        Jeff Johnson ,
        Catalin Marinas ,
        Andrew Morton ,
        Jack Wang ,
        Marcel Holtmann ,
        Johan Hedberg ,
        Luiz Augusto von Dentz ,
        Greg Kroah-Hartman ,
        Florian Fainelli ,
        Ray Jui , Scott Branden ,
        Broadcom internal kernel review list ,
        Xiubo Li , Ilya Dryomov ,
        Josh Poimboeuf , Jiri Kosina ,
        Miroslav Benes , Petr Mladek ,
        Joe Lawrence ,
        Jaroslav Kysela , Takashi Iwai ,
        Louis Peens ,
        Michael Ellerman ,
        Nicholas Piggin ,
        Christophe Leroy ,
        Naveen N Rao ,
        Madhavan Srinivasan ,
        netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr,
        linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
        dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
        linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org,
        linux-block@vger.kernel.org, linux-wireless@vger.kernel.org,
        ath11k@lists.infradead.org, linux-mm@kvack.org,
        linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev,
        linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org,
        live-patching@vger.kernel.org, linux-sound@vger.kernel.org,
        oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org,
        Anna-Maria Behnsen 
Subject: Re: [PATCH v3 02/19] coccinelle: misc: Add secs_to_jiffies script
Message-ID: 
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
 <20241210-converge-secs-to-jiffies-v3-2-ddfefd7e9f2a@linux.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20241210-converge-secs-to-jiffies-v3-2-ddfefd7e9f2a@linux.microsoft.com>
X-TM-AS-GCONF: 00
X-Proofpoint-ORIG-GUID: fnzByXeLFO0AZ_AJF8SbPJqhCHN_hCrL
X-Proofpoint-GUID: fnzByXeLFO0AZ_AJF8SbPJqhCHN_hCrL
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1051,Hydra:6.0.680,FMLib:17.12.62.30
 definitions=2024-10-15_01,2024-10-11_01,2024-09-30_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 bulkscore=0
 phishscore=0 clxscore=1011 priorityscore=1501 lowpriorityscore=0
 impostorscore=0 suspectscore=0 spamscore=0 mlxlogscore=985 malwarescore=0
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.19.0-2411120000 definitions=main-2412170134

On Tue, Dec 10, 2024 at 10:02:33PM +0000, Easwar Hariharan wrote:

Hi Easwar,

> This script finds and suggests conversions of timeout patterns that
> result in seconds-denominated timeouts to use the new secs_to_jiffies()
> API in include/linux/jiffies.h for better readability.
> 
> Suggested-by: Anna-Maria Behnsen 
> Signed-off-by: Easwar Hariharan 
> ---
>  scripts/coccinelle/misc/secs_to_jiffies.cocci | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/scripts/coccinelle/misc/secs_to_jiffies.cocci b/scripts/coccinelle/misc/secs_to_jiffies.cocci
> new file mode 100644
> index 0000000000000000000000000000000000000000..8bbb2884ea5db939c63fd4513cf5ca8c977aa8cb
> --- /dev/null
> +++ b/scripts/coccinelle/misc/secs_to_jiffies.cocci
> @@ -0,0 +1,22 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +///
> +/// Find usages of:
> +/// - msecs_to_jiffies(value*1000)
> +/// - msecs_to_jiffies(value*MSEC_PER_SEC)
> +///
> +// Confidence: High
> +// Copyright: (C) 2024 Easwar Hariharan, Microsoft
> +// Keywords: secs, seconds, jiffies
> +//
> +
> +virtual patch
> +
> +@depends on patch@ constant C; @@
> +
> +- msecs_to_jiffies(C * 1000)
> ++ secs_to_jiffies(C)
> +
> +@depends on patch@ constant C; @@
> +
> +- msecs_to_jiffies(C * MSEC_PER_SEC)
> ++ secs_to_jiffies(C)

If you used this script only, then it did not seem to recognize line arch/s390/mm/cmm.c:207

	mod_timer(&cmm_timer, jiffies + msecs_to_jiffies(cmm_timeout_seconds * MSEC_PER_SEC));

Thanks!


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 17:43:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 17:43:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859777.1271879 (Exim 4.92)
	(envelope-from )
	id 1tNbbe-0000Ib-Ng; Tue, 17 Dec 2024 17:43:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859777.1271879; Tue, 17 Dec 2024 17:43: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 1tNbbe-0000IU-Jf; Tue, 17 Dec 2024 17:43:38 +0000
Received: by outflank-mailman (input) for mailman id 859777;
 Tue, 17 Dec 2024 17:43: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 1tNbbd-0008Co-Qp
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 17:43:37 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTP
 id 70c6ed4a-bc9e-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 18:43:35 +0100 (CET)
Received: from [192.168.35.166] (c-73-118-245-227.hsd1.wa.comcast.net
 [73.118.245.227])
 by linux.microsoft.com (Postfix) with ESMTPSA id 4C1542171F87;
 Tue, 17 Dec 2024 09:43: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: 70c6ed4a-bc9e-11ef-99a3-01e77a169b0f
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 4C1542171F87
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1734457414;
	bh=qz8oz73s4rCDJSC1TgNUQNYJjOVU8exHA2BYkyw+ZD0=;
	h=Date:Cc:Subject:To:References:From:In-Reply-To:From;
	b=VkPXr4Q51kSzYXC6iV4Rnt0hdXMx9YWH59To4VTRyzVF/4SXLeJpUxO01knfWumzM
	 CzAbcmQnzc2Qsz94yaL1AgsNLmsei1LV793lD8Qkn1YDLJvzyEf9X476Tc2IwzAabU
	 HeEAso29uXPVkfVcznz9hizNBAvL5QWBolCDD9Qs=
Message-ID: 
Date: Tue, 17 Dec 2024 09:43:31 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Cc: eahariha@linux.microsoft.com, Pablo Neira Ayuso ,
 Jozsef Kadlecsik ,
 "David S. Miller" , Eric Dumazet ,
 Jakub Kicinski , Paolo Abeni ,
 Simon Horman , Nicolas Palix ,
 Daniel Mack , Haojian Zhuang ,
 Robert Jarzmik , Russell King
 , Heiko Carstens ,
 Vasily Gorbik ,
 Christian Borntraeger ,
 Sven Schnelle , Ofir Bitton ,
 Oded Gabbay , Lucas De Marchi
 ,
 =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= ,
 Rodrigo Vivi ,
 Maarten Lankhorst ,
 Maxime Ripard , Thomas Zimmermann ,
 David Airlie , Simona Vetter ,
 Jeroen de Borst ,
 Praveen Kaligineedi ,
 Shailend Chand , Andrew Lunn ,
 James Smart ,
 Dick Kennedy ,
 "James E.J. Bottomley" ,
 "Martin K. Petersen" ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Jens Axboe , Kalle Valo ,
 Jeff Johnson , Catalin Marinas
 , Andrew Morton ,
 Jack Wang , Marcel Holtmann
 , Johan Hedberg ,
 Luiz Augusto von Dentz ,
 Greg Kroah-Hartman ,
 Florian Fainelli , Ray Jui
 , Scott Branden ,
 Broadcom internal kernel review list
 , Xiubo Li ,
 Ilya Dryomov , Josh Poimboeuf ,
 Jiri Kosina , Miroslav Benes ,
 Petr Mladek , Joe Lawrence ,
 Jaroslav Kysela , Takashi Iwai ,
 Louis Peens , Michael Ellerman
 , Nicholas Piggin ,
 Christophe Leroy ,
 Naveen N Rao , Madhavan Srinivasan ,
 netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr,
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org,
 ath11k@lists.infradead.org, linux-mm@kvack.org,
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev,
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org,
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org,
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org,
 Anna-Maria Behnsen 
Subject: Re: [PATCH v3 02/19] coccinelle: misc: Add secs_to_jiffies script
To: Julia Lawall ,
 Alexander Gordeev 
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
 <20241210-converge-secs-to-jiffies-v3-2-ddfefd7e9f2a@linux.microsoft.com>
 
 
From: Easwar Hariharan 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12/17/2024 9:33 AM, Julia Lawall wrote:
> 
> 
> On Tue, 17 Dec 2024, Alexander Gordeev wrote:
> 
>> On Tue, Dec 10, 2024 at 10:02:33PM +0000, Easwar Hariharan wrote:
>>
>> Hi Easwar,
>>
>>> This script finds and suggests conversions of timeout patterns that
>>> result in seconds-denominated timeouts to use the new secs_to_jiffies()
>>> API in include/linux/jiffies.h for better readability.
>>>
>>> Suggested-by: Anna-Maria Behnsen 
>>> Signed-off-by: Easwar Hariharan 
>>> ---
>>>  scripts/coccinelle/misc/secs_to_jiffies.cocci | 22 ++++++++++++++++++++++
>>>  1 file changed, 22 insertions(+)
>>>
>>> diff --git a/scripts/coccinelle/misc/secs_to_jiffies.cocci b/scripts/coccinelle/misc/secs_to_jiffies.cocci
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..8bbb2884ea5db939c63fd4513cf5ca8c977aa8cb
>>> --- /dev/null
>>> +++ b/scripts/coccinelle/misc/secs_to_jiffies.cocci
>>> @@ -0,0 +1,22 @@
>>> +// SPDX-License-Identifier: GPL-2.0-only
>>> +///
>>> +/// Find usages of:
>>> +/// - msecs_to_jiffies(value*1000)
>>> +/// - msecs_to_jiffies(value*MSEC_PER_SEC)
>>> +///
>>> +// Confidence: High
>>> +// Copyright: (C) 2024 Easwar Hariharan, Microsoft
>>> +// Keywords: secs, seconds, jiffies
>>> +//
>>> +
>>> +virtual patch
>>> +
>>> +@depends on patch@ constant C; @@
>>> +
>>> +- msecs_to_jiffies(C * 1000)
>>> ++ secs_to_jiffies(C)
>>> +
>>> +@depends on patch@ constant C; @@
>>> +
>>> +- msecs_to_jiffies(C * MSEC_PER_SEC)
>>> ++ secs_to_jiffies(C)
>>
>> If you used this script only, then it did not seem to recognize line arch/s390/mm/cmm.c:207
>>
>> 	mod_timer(&cmm_timer, jiffies + msecs_to_jiffies(cmm_timeout_seconds * MSEC_PER_SEC));
> 
> There is the requirement that C is a constant, and cmm_timeout_seconds is
> not considered to be a constant, ie it is not all capital letters.
> Indeed, it doesn't seem to be a constant at all.  I don't know if the
> requirement of being a comstant is really necessary.
> 
> julia
> 
>>
>> Thanks!
>>

As the cover letter says, this is part 1. I intend to do further parts
that address the cases where the multiplicand is an expression, as well
as the cases where the timeout provided to msecs_to_jiffies() is
denominated in seconds (i.e. ends in 000)

Thanks,
Easwar


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 18:00:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 18:00:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859793.1271888 (Exim 4.92)
	(envelope-from )
	id 1tNbsH-0004RC-1t; Tue, 17 Dec 2024 18:00:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859793.1271888; Tue, 17 Dec 2024 18:00: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 1tNbsG-0004R5-VR; Tue, 17 Dec 2024 18:00:48 +0000
Received: by outflank-mailman (input) for mailman id 859793;
 Tue, 17 Dec 2024 18:00: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 1tNbsF-0004Qz-Mw
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 18:00:48 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d720ddc7-bca0-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 19:00:46 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 81C6C4EE0738;
 Tue, 17 Dec 2024 19:00:45 +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: d720ddc7-bca0-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1734458445; bh=71/gskfpgBPoy4Z86mD69zBglqccMoIEYMzNEEsRjFs=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=jSAxHdugSPdRW/gXo+pZZXZa8HbWaVFL9SpZ4duNFRMgYHgJ+bCyTVmZQRajfgndb
	 AGsXlTr7+t72gs492wXvtb62cGPLZanKcg7GmJfpZNkxrX5pYKGAe0GDMnuYy3nM0t
	 gPzpO/08nCH2ZEjz7PgVR/tnGKKS/9RktUpN0irj12LbIoSBjgCvUZnScFYib3O+oX
	 gD/zjbhXA2RmXpOmnOrKp8ZyR0yqw3OGHHlcVPCOGfY9sr0cL74EdCUUv3fy/m2Q37
	 H7++ajVu6e70rlzxWa2xFjtqY0nMYNB7OxfiBykFLfY9qf3m4Ka9rwna94VoiZ+zQG
	 Zbteq0yPg2gyw==
MIME-Version: 1.0
Date: Tue, 17 Dec 2024 19:00:45 +0100
From: Nicola Vetrini 
To: Andrew Cooper 
Cc: Jan Beulich , sstabellini@kernel.org,
 michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com,
 consulting@bugseng.com, Simone Ballarin , Doug
 Goldstein , xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH] eclair-analysis: Add usage of varargs extension for
 C99
In-Reply-To: <8d59f2a1-8fc2-44d0-8c87-fbdf5bcc4d77@citrix.com>
References: 
 
 
 <8d59f2a1-8fc2-44d0-8c87-fbdf5bcc4d77@citrix.com>
Message-ID: <8fcdb72f62008250faa392857a57202e@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-12-17 17:46, Andrew Cooper wrote:
> On 17/12/2024 4:45 pm, Jan Beulich wrote:
>> On 17.12.2024 17:40, Andrew Cooper wrote:
>>> On 17/12/2024 4:24 pm, Nicola Vetrini wrote:
>>>> This extension name is missing from the current list of extension 
>>>> used
>>>> by Xen, therefore is must be added to that configuration in order to
>>>> avoid violations for MISRA C Rule 1.1.
>>>> 
>>>> Signed-off-by: Nicola Vetrini 
>>> Given CI is broken, I've put this in for testing:
>>> 
>>> https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1592826906
>> If this was fixing an earlier commit, shouldn't it come with a Fixes: 
>> tag
>> anyway?
> 
> Yeah, it probably should have a Fixes, even if it is technically a
> combined one with also changing the runner.
> 

I agree. I did forget putting a fixes tag, that was a bit rushed. We can 
unmark R1.1 and R2.1 temporarily and then respin this to properly 
address both rules.

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 18:04:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 18:04:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859801.1271899 (Exim 4.92)
	(envelope-from )
	id 1tNbvP-0005hg-HX; Tue, 17 Dec 2024 18:04:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859801.1271899; Tue, 17 Dec 2024 18:04:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNbvP-0005hZ-D3; Tue, 17 Dec 2024 18:04:03 +0000
Received: by outflank-mailman (input) for mailman id 859801;
 Tue, 17 Dec 2024 18:04: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 1tNbvN-0005hT-RE
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 18:04:01 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4a8daec2-bca1-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 19:04:00 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id A6FE54EE0738;
 Tue, 17 Dec 2024 19:03:59 +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: 4a8daec2-bca1-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1734458639; bh=AV6w8JQfS3QlWoHTTvFX0U9KitTgAGD/rpSGmIDa9nQ=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=X4LHbCYwg0PZbdABDdZ4GbTLulv0A4V9bCy8KCekvdZ9qj+OmdAcQtqJK86BWJ/TL
	 lRoutQb7vzNXNBGJ+DmmvRsMAYDmUXUn3OS/vTWju4U4cIAlt4o9Du2mdcOTVibLYr
	 yQJNWtV9hCVeQYT4XGHvZBA5wDbG8gVn4hzF2yqkr32q29SNiBQ/Ji6T1mERbaiqEj
	 3xIeIyiE0DIGxUzSpZka8ZT5xnneSgcDJZhKdLmfGry7469YslgaF7Q6JvL23Veaxn
	 29tQvo8UgMSDV1W0XmojzIJMqjgO86cbgZuh/lt+Kt3rNEALuLjQ3TEpEW3k399Aky
	 Y582TkrrWnPwA==
MIME-Version: 1.0
Date: Tue, 17 Dec 2024 19:03:59 +0100
From: Nicola Vetrini 
To: Jan Beulich 
Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com,
 ayan.kumar.halder@amd.com, consulting@bugseng.com, Simone Ballarin
 , Doug Goldstein , Andrew
 Cooper3 , xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH] eclair-analysis: Add usage of varargs extension for
 C99
In-Reply-To: 
References: 
 
Message-ID: <143ba0299956e39a8e8e95f08908a812@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-12-17 17:40, Jan Beulich wrote:
> On 17.12.2024 17:24, Nicola Vetrini wrote:
>> This extension name is missing from the current list of extension used
>> by Xen, therefore is must be added to that configuration in order to
>> avoid violations for MISRA C Rule 1.1.
> 
> Which extension are we talking about here? I'm afraid ...
> 
>> --- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
>> @@ -100,8 +100,8 @@
>>      ext_enum_value_not_int: non-documented GCC extension.
>>      ext_gnu_array_range: see Section \"6.29 Designated Initializers\" 
>> of "GCC_MANUAL".
>>  "
>> --config=STD.diag,behavior+={c99,GCC_ARM64,"^(ext_paste_comma|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_forward_ref_enum_def|ext_gnu_array_range)$"}
>> --config=STD.diag,behavior+={c99,GCC_X86_64,"^(ext_paste_comma|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_flexible_array_in_struct|ext_flexible_array_in_array|ext_enum_value_not_int|ext_gnu_array_range)$"}
>> +-config=STD.diag,behavior+={c99,GCC_ARM64,"^(ext_paste_comma|ext_c_missing_varargs_arg|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_forward_ref_enum_def|ext_gnu_array_range)$"}
>> +-config=STD.diag,behavior+={c99,GCC_X86_64,"^(ext_paste_comma|ext_c_missing_varargs_arg|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_flexible_array_in_struct|ext_flexible_array_in_array|ext_enum_value_not_int|ext_gnu_array_range)$"}
>>  -doc_end
> 
> ... ext_c_missing_varargs_arg doesn't tell me anything. Without this 
> it's
> hard to tell whether C-language-toolchain.rst might also need an edit; 
> a
> search for "varargs" in the file yields no hit.
> 

It's related to section 6.21 of the gcc manual "Macros with a variable 
number of arguments".
The GCC extension (well, technically CPP) allowing zero arguments to a 
variadic macro, so it's already present in the comment above the 
configuration (out of context).


-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 18:14:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 18:14:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859812.1271908 (Exim 4.92)
	(envelope-from )
	id 1tNc5E-0008JD-Cw; Tue, 17 Dec 2024 18:14:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859812.1271908; Tue, 17 Dec 2024 18:14:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNc5E-0008J6-A6; Tue, 17 Dec 2024 18:14:12 +0000
Received: by outflank-mailman (input) for mailman id 859812;
 Tue, 17 Dec 2024 18:14: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 1tNc5C-0008Iz-Gp
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 18:14:10 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b50da9af-bca2-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 19:14:08 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 53D2F4EE0738;
 Tue, 17 Dec 2024 19:14:07 +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: b50da9af-bca2-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1734459247; bh=peixyu20lZBiwBYOV4bETS5+n2nZxrmOd3LMgofoid4=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=AUfAuyKyVREcOd3Vw6IuoFN1YxcjcTGM894F9k0dJEblnnlK0KoQAbJa2ypm3vO67
	 jJShSUBDnyprCk0rVPetLeUG+JL8WnlRocpja3ig0Vsxk46sXmQPxxUhRHo38+tdeh
	 FJDuNPh63/6n91WtN5DefuYp+sQ4RVjrpBss/BcLYtJqT5x17jNKtwuKinjEtH/Y2K
	 9DmaD0UG+NwkQlgdeQQDd0EYsgWkPjA7XN0UNmjaVzfkTwJhAV1mcWlyI5Y42Um9um
	 /8mcNlFUspErCcRzcrGqNddg2ro6pxKy68nDiQlD4ztnFk5QO5WyjWvvL18tubpird
	 4nyDc6+ldkLVw==
MIME-Version: 1.0
Date: Tue, 17 Dec 2024 19:14:07 +0100
From: Nicola Vetrini 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org,
 michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com,
 consulting@bugseng.com, Simone Ballarin , Doug
 Goldstein 
Subject: Re: [XEN PATCH] eclair-analysis: Add usage of varargs extension for
 C99
In-Reply-To: 
References: 
 
Message-ID: <47ecd470ebcb26ae13d3eafcde4fa618@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit

On 2024-12-17 17:40, Andrew Cooper wrote:
> On 17/12/2024 4:24 pm, Nicola Vetrini wrote:
>> This extension name is missing from the current list of extension used
>> by Xen, therefore is must be added to that configuration in order to
>> avoid violations for MISRA C Rule 1.1.
>> 
>> Signed-off-by: Nicola Vetrini 
> 
> Given CI is broken, I've put this in for testing:
> 
> https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1592826906
> 
> But, a question:
> 
>> ---
>>  automation/eclair_analysis/ECLAIR/toolchain.ecl | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/automation/eclair_analysis/ECLAIR/toolchain.ecl 
>> b/automation/eclair_analysis/ECLAIR/toolchain.ecl
>> index 86e9a79b5231..9b419e562afa 100644
>> --- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
>> @@ -100,8 +100,8 @@
>>      ext_enum_value_not_int: non-documented GCC extension.
>>      ext_gnu_array_range: see Section \"6.29 Designated Initializers\" 
>> of "GCC_MANUAL".
>>  "
>> --config=STD.diag,behavior+={c99,GCC_ARM64,"^(ext_paste_comma|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_forward_ref_enum_def|ext_gnu_array_range)$"}
>> --config=STD.diag,behavior+={c99,GCC_X86_64,"^(ext_paste_comma|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_flexible_array_in_struct|ext_flexible_array_in_array|ext_enum_value_not_int|ext_gnu_array_range)$"}
>> +-config=STD.diag,behavior+={c99,GCC_ARM64,"^(ext_paste_comma|ext_c_missing_varargs_arg|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_forward_ref_enum_def|ext_gnu_array_range)$"}
>> +-config=STD.diag,behavior+={c99,GCC_X86_64,"^(ext_paste_comma|ext_c_missing_varargs_arg|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_flexible_array_in_struct|ext_flexible_array_in_array|ext_enum_value_not_int|ext_gnu_array_range)$"}
>>  -doc_end
> 
> We're adding ext_c_missing_varargs_arg to the list.  But there's also
> ext_missing_varargs_arg.
> 
> What's the difference between the two?
> 

Actually on a closer look the second name can be dropped, so only 
"ext_c_missing_varargs_arg" is needed (and it's the same extension). 
I'll adjust the patch.

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 18:19:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 18:19:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859824.1271917 (Exim 4.92)
	(envelope-from )
	id 1tNcAC-0001D1-W4; Tue, 17 Dec 2024 18:19:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859824.1271917; Tue, 17 Dec 2024 18:19: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 1tNcAC-0001Cu-TU; Tue, 17 Dec 2024 18:19:20 +0000
Received: by outflank-mailman (input) for mailman id 859824;
 Tue, 17 Dec 2024 18:19: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 1tNcAC-0001Co-C3
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 18:19:20 +0000
Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com
 [2a00:1450:4864:20::443])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6e27a6af-bca3-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 19:19:18 +0100 (CET)
Received: by mail-wr1-x443.google.com with SMTP id
 ffacd0b85a97d-385e3621518so2896949f8f.1
 for ; Tue, 17 Dec 2024 10:19:18 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c801a87esm11697326f8f.59.2024.12.17.10.19.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 10:19: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: 6e27a6af-bca3-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734459558; x=1735064358; 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=+1Muv/DS2Nfn5FpgHtOfx1Dbvt8Dkxy/ZfhVvKd/pzk=;
        b=aCyurNMHCX5fp6jRiaLxyzQadLd2VLNfvYCAumgJ99L9DgiTHEr6UbjqKAi+FYtqnM
         /X7jgyn124SNKedfEQMhNlXQGeWfFxlBFNPue4ePutXacZG0CaAT176BdVi3VYLb7K9G
         LIaCzBwZ4M3/OX54YPgICRIrsae0RRCNpDICs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734459558; x=1735064358;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+1Muv/DS2Nfn5FpgHtOfx1Dbvt8Dkxy/ZfhVvKd/pzk=;
        b=RhkWADzGsrf3LwKpZn+SEph/hVzt6NtFLlidNnvGeWnRreOH2Hgv7hBUUR/FnQFBox
         GEW9NcJiPRAupgPjJPCzpY64g7lcfMJF8W0rRFBgBl/4Un7sxfDBg1s44x/TkVKqHbBe
         IBWbNLMQMiDQyXc2f3ycCgwp/qN61q2qVbU9aGmZS4A/2zfpuAp7D6NAOW0CCnxdcSRy
         tqeWAR7g4KfxPKvg7fjfszU3n4wBxcor0JlzJXB0TIeUMNaL3NhEDLgECJSUsEjJLELW
         U7sivUNUcfZ2dlhxgo/yGKDuHZ7GgNCvsoxx+ejJOMKLBgaBrQUKqe6uWrQGIu43uusP
         sqTg==
X-Gm-Message-State: AOJu0YwH8tRISgEm4BckO6o5zFEImrKXkS4MgNuwzMo3n1NhOFACpWPd
	OygpOcvQ1C6VGXpMSDlOQVdyXJTx2SJBuBQ5PdmgTdI21Z2V6bDicJdpBwaRDT8=
X-Gm-Gg: ASbGncul7v/ifgYfpmA657qWBmffYZhMRRaWehHwd7Lo+8F+x1XUZ0JJR/EOMCFQT/Q
	JIjDdcGXVHao0kc/0lq8cRx8etgA7gW0L38JkXXiGvgKLbiJzM1EY+oQJrfj56SecM4WV89QkML
	3PIKRhrb9JzxmB7NbjfpuidYeDBDQGcRWda/Bp/YhA+taq61QTh3gh/xVMgX/ZYdNtkwMO3fyvu
	BCSb5Af1BqkQYsyP8uHp/WVZ1gCHucRzZXphkucyLBe4G9aJnFImkiEw4ryc7qSLYVT7pVbRF7w
	IrV7D/blXnjttJhWbJ7z
X-Google-Smtp-Source: AGHT+IHrCxwBnpEH7YNo4DNnflpt+4kJy5SxEz68RSuNO+MCL+wib2NVro8hnRuN8aW6DtV66HBGgg==
X-Received: by 2002:a5d:5984:0:b0:385:fc32:1ec6 with SMTP id ffacd0b85a97d-3888e0c081bmr13729321f8f.50.1734459558012;
        Tue, 17 Dec 2024 10:19:18 -0800 (PST)
Message-ID: <1bf0a1f7-7b7f-45dc-9d38-3bfd46d00eb8@citrix.com>
Date: Tue, 17 Dec 2024 18:19:16 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] eclair-analysis: Add usage of varargs extension for
 C99
To: Nicola Vetrini 
Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org,
 michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com,
 consulting@bugseng.com, Simone Ballarin ,
 Doug Goldstein 
References: 
 
 <47ecd470ebcb26ae13d3eafcde4fa618@bugseng.com>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <47ecd470ebcb26ae13d3eafcde4fa618@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 17/12/2024 6:14 pm, Nicola Vetrini wrote:
> On 2024-12-17 17:40, Andrew Cooper wrote:
>> On 17/12/2024 4:24 pm, Nicola Vetrini wrote:
>>> This extension name is missing from the current list of extension used
>>> by Xen, therefore is must be added to that configuration in order to
>>> avoid violations for MISRA C Rule 1.1.
>>>
>>> Signed-off-by: Nicola Vetrini 
>>
>> Given CI is broken, I've put this in for testing:
>>
>> https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1592826906
>>
>> But, a question:
>>
>>> ---
>>>  automation/eclair_analysis/ECLAIR/toolchain.ecl | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/automation/eclair_analysis/ECLAIR/toolchain.ecl
>>> b/automation/eclair_analysis/ECLAIR/toolchain.ecl
>>> index 86e9a79b5231..9b419e562afa 100644
>>> --- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
>>> @@ -100,8 +100,8 @@
>>>      ext_enum_value_not_int: non-documented GCC extension.
>>>      ext_gnu_array_range: see Section \"6.29 Designated
>>> Initializers\" of "GCC_MANUAL".
>>>  "
>>> --config=STD.diag,behavior+={c99,GCC_ARM64,"^(ext_paste_comma|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_forward_ref_enum_def|ext_gnu_array_range)$"}
>>>
>>> --config=STD.diag,behavior+={c99,GCC_X86_64,"^(ext_paste_comma|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_flexible_array_in_struct|ext_flexible_array_in_array|ext_enum_value_not_int|ext_gnu_array_range)$"}
>>>
>>> +-config=STD.diag,behavior+={c99,GCC_ARM64,"^(ext_paste_comma|ext_c_missing_varargs_arg|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_forward_ref_enum_def|ext_gnu_array_range)$"}
>>>
>>> +-config=STD.diag,behavior+={c99,GCC_X86_64,"^(ext_paste_comma|ext_c_missing_varargs_arg|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_flexible_array_in_struct|ext_flexible_array_in_array|ext_enum_value_not_int|ext_gnu_array_range)$"}
>>>
>>>  -doc_end
>>
>> We're adding ext_c_missing_varargs_arg to the list.  But there's also
>> ext_missing_varargs_arg.
>>
>> What's the difference between the two?
>>
>
> Actually on a closer look the second name can be dropped, so only
> "ext_c_missing_varargs_arg" is needed (and it's the same extension).
> I'll adjust the patch.

If you're adjusting this, could you start by splitting this into
multiple lines like we have for the monitored and clean lists.

It will make it far more clear when adjusting one option in the middle
like this.

~Andrew


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 18:20:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 18:20:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859832.1271928 (Exim 4.92)
	(envelope-from )
	id 1tNcB6-0002ak-94; Tue, 17 Dec 2024 18:20:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859832.1271928; Tue, 17 Dec 2024 18:20:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNcB6-0002ad-5L; Tue, 17 Dec 2024 18:20:16 +0000
Received: by outflank-mailman (input) for mailman id 859832;
 Tue, 17 Dec 2024 18:20: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 1tNcB4-0002ZT-Oy
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 18:20: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 8eaee202-bca3-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 19:20:13 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-4361f664af5so61253005e9.1
 for ; Tue, 17 Dec 2024 10:20:13 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c801a47csm11911426f8f.44.2024.12.17.10.20.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Dec 2024 10:20: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: 8eaee202-bca3-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734459613; x=1735064413; 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=bMUANBqRM0yAGl6AgHLfacRt4Bq0MyoKLaRuWBwwDxU=;
        b=vBo7kJEURsP7LUk5I9q8r5T3toldI2Zdi8tdBBp9ch83zW+oZjrJyxFp1J1b6Qy/vp
         VwxStnIx1UK3dqR3iAHkbL3cKzSUZwN7ifBqBMw5hqQV6zZh8hqI4e5z7BwoDAXjvbBE
         /9wW8r+Xtvu1oTnS68Nf7JRg8wxALJeYt+/Ig=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734459613; x=1735064413;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=bMUANBqRM0yAGl6AgHLfacRt4Bq0MyoKLaRuWBwwDxU=;
        b=iZ7KEU7JRDIuSAtXCwBcy/rOpzx/oIX5cVm6ye9PUIQMmqp9Mj+8SA/K9HTDM7gxDH
         4HVdlSG6Cu+meyMnBCl/RJhPyQYx/bcA5rUkrIVKPx99TyKzp2sTeXxyTuOTUl+DIabI
         UYLRIvkjXG72hvITEtdHi1dznmuiBD/fWVPYVLxLytS0CYkgZ7FYRm+LpXZObPz/+b6D
         cfG/RbbcmyNmQfDr97A7GEGeoBmecQeQn8o7CYq7z8jCzL6rLKyrnlZNEnQ5QlAe9FVe
         cuJNvx6Xi1GZUaNam2lpoJKH+AzlXrJXu0nuaCfinqD5uXZWDpI4WiIAcUByJtnxsuBm
         iuTw==
X-Gm-Message-State: AOJu0YwuAWeYXbhrPP7v0yIGAPNYF/MaARJIFnmJNOXS+B6tn5tD9/TB
	DhcTVUNXXNHm/e4wA2Ok3++U7EajOYlnII3nQKKzfKVs67ZzrSQsI64eCXZElX8=
X-Gm-Gg: ASbGncsYP+LNgIyKo4UFS2qeZfyR44LH/7guqphaESTlYb3SxERCTb9N+81kXpQEYvD
	X+Ldr964FV8EytPsXCzb5NpActons3bt7pRPfkDTB0qH4f86iGIoe8B61s4zepm9O/H+9D7KsBG
	X33A4mXFWg7IDY/jF4buAkEQrz/dzcqXP9rPv1OvTZihmIStKaFHN5pUauG1Xa5zphoVJi6ScXc
	kxGL3UNedfUUgKT7oyLoQDY1LWHBltUAHanWNuh+0L9zBav4EQUbLFT/eaguAiGyFI=
X-Google-Smtp-Source: AGHT+IFIZTE0jnSsaJe5VKVG8C5So7Oa/HsT8HjigijWiCCgHNRUBhZbRC8tmZzAGuRtn7euDQjDnA==
X-Received: by 2002:a05:600c:c87:b0:431:5df7:b310 with SMTP id 5b1f17b1804b1-4362aa2771fmr140196005e9.8.1734459612671;
        Tue, 17 Dec 2024 10:20:12 -0800 (PST)
Date: Tue, 17 Dec 2024 19:20:11 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich , Julien Grall ,
	Stefano Stabellini ,
	"consulting @ bugseng . com" ,
	Nicola Vetrini ,
	Alessandro Zucchelli 
Subject: Re: [PATCH] MISRA: Unmark Rules 1.1 and 2.1 as clean following
 Eclair upgrade
Message-ID: 
References: <20241217172950.43626-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20241217172950.43626-1-andrew.cooper3@citrix.com>

On Tue, Dec 17, 2024 at 05:29:50PM +0000, Andrew Cooper wrote:
> Updating the Eclair runner has had knock-on effects with previously-clean
> rules now flagging violations:
> 
>  - x86:   Rule 1.1, 1940 violations
>  - ARM64: Rule 1.1, 725 violations, Rule 2.1, 255 violations
> 
> Fixes: 631f535a3d4f ("xen: update ECLAIR service identifiers from MC3R1 to MC3A2.")
> Signed-off-by: Andrew Cooper 

Acked-by: Roger Pau Monné 

Thanks.


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 18:25:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 18:25:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859845.1271937 (Exim 4.92)
	(envelope-from )
	id 1tNcGO-0004Pw-QA; Tue, 17 Dec 2024 18:25:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859845.1271937; Tue, 17 Dec 2024 18:25: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 1tNcGO-0004Pp-NX; Tue, 17 Dec 2024 18:25:44 +0000
Received: by outflank-mailman (input) for mailman id 859845;
 Tue, 17 Dec 2024 18:25: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 1tNcGO-0004Pj-1U
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 18:25:44 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5288ac2b-bca4-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 19:25:41 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id E9EF74EE0738;
 Tue, 17 Dec 2024 19:25:40 +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: 5288ac2b-bca4-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1734459941; bh=wticJJvSw3q1kpP6IT/EwwC+L+4SA5s66JhD/hxERU0=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=JBrrFc5XcpDuxsRBxEElZWAR+/Xvo+fZQKbCrCQeLDHgsF5zWZVtJaRZDauO8qwR9
	 F+Akc7Q3PEMFGCPTxXDkmdnn1ZYDzL6eEyAu0w/vr2oo8lsZyBh8Kg4TKxAZbaX1Uj
	 Oc055svwKAzIcLGbF88CKDWMfXFoYjrQ9YJYgYh6rSCM89Iy4Dn3Kk7X2iOgSoJwzq
	 ZjF/DcNgvb3dtwMBrBihjU6DWq+NMfdj0BAkhBvK7+qHdyNrPSY8FjnJHaYfICXqQH
	 3SAK0092xFRKlg3ZANVSGffdxFT5pS+mr54UKXGOvauN4waSy8Hzhp0M6YU3Q33OOV
	 N8By32zmySaWA==
MIME-Version: 1.0
Date: Tue, 17 Dec 2024 19:25:40 +0100
From: Nicola Vetrini 
To: Andrew Cooper 
Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org,
 michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com,
 consulting@bugseng.com, Simone Ballarin , Doug
 Goldstein 
Subject: Re: [XEN PATCH] eclair-analysis: Add usage of varargs extension for
 C99
In-Reply-To: <1bf0a1f7-7b7f-45dc-9d38-3bfd46d00eb8@citrix.com>
References: 
 
 <47ecd470ebcb26ae13d3eafcde4fa618@bugseng.com>
 <1bf0a1f7-7b7f-45dc-9d38-3bfd46d00eb8@citrix.com>
Message-ID: <0853c92d39890beb626aac0a7703b3b7@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit

On 2024-12-17 19:19, Andrew Cooper wrote:
> On 17/12/2024 6:14 pm, Nicola Vetrini wrote:
>> On 2024-12-17 17:40, Andrew Cooper wrote:
>>> On 17/12/2024 4:24 pm, Nicola Vetrini wrote:
>>>> This extension name is missing from the current list of extension 
>>>> used
>>>> by Xen, therefore is must be added to that configuration in order to
>>>> avoid violations for MISRA C Rule 1.1.
>>>> 
>>>> Signed-off-by: Nicola Vetrini 
>>> 
>>> Given CI is broken, I've put this in for testing:
>>> 
>>> https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1592826906
>>> 
>>> But, a question:
>>> 
>>>> ---
>>>>  automation/eclair_analysis/ECLAIR/toolchain.ecl | 4 ++--
>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>> 
>>>> diff --git a/automation/eclair_analysis/ECLAIR/toolchain.ecl
>>>> b/automation/eclair_analysis/ECLAIR/toolchain.ecl
>>>> index 86e9a79b5231..9b419e562afa 100644
>>>> --- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
>>>> +++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
>>>> @@ -100,8 +100,8 @@
>>>>      ext_enum_value_not_int: non-documented GCC extension.
>>>>      ext_gnu_array_range: see Section \"6.29 Designated
>>>> Initializers\" of "GCC_MANUAL".
>>>>  "
>>>> --config=STD.diag,behavior+={c99,GCC_ARM64,"^(ext_paste_comma|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_forward_ref_enum_def|ext_gnu_array_range)$"}
>>>> 
>>>> --config=STD.diag,behavior+={c99,GCC_X86_64,"^(ext_paste_comma|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_flexible_array_in_struct|ext_flexible_array_in_array|ext_enum_value_not_int|ext_gnu_array_range)$"}
>>>> 
>>>> +-config=STD.diag,behavior+={c99,GCC_ARM64,"^(ext_paste_comma|ext_c_missing_varargs_arg|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_forward_ref_enum_def|ext_gnu_array_range)$"}
>>>> 
>>>> +-config=STD.diag,behavior+={c99,GCC_X86_64,"^(ext_paste_comma|ext_c_missing_varargs_arg|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_flexible_array_in_struct|ext_flexible_array_in_array|ext_enum_value_not_int|ext_gnu_array_range)$"}
>>>> 
>>>>  -doc_end
>>> 
>>> We're adding ext_c_missing_varargs_arg to the list.  But there's also
>>> ext_missing_varargs_arg.
>>> 
>>> What's the difference between the two?
>>> 
>> 
>> Actually on a closer look the second name can be dropped, so only
>> "ext_c_missing_varargs_arg" is needed (and it's the same extension).
>> I'll adjust the patch.
> 
> If you're adjusting this, could you start by splitting this into
> multiple lines like we have for the monitored and clean lists.
> 
> It will make it far more clear when adjusting one option in the middle
> like this.
> 

Ack

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 18:40:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 18:40:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859856.1271948 (Exim 4.92)
	(envelope-from )
	id 1tNcUO-000810-Us; Tue, 17 Dec 2024 18:40:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859856.1271948; Tue, 17 Dec 2024 18:40: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 1tNcUO-00080t-SC; Tue, 17 Dec 2024 18:40:12 +0000
Received: by outflank-mailman (input) for mailman id 859856;
 Tue, 17 Dec 2024 18:40: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 1tNcUN-00080n-3b
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 18:40:11 +0000
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [2a00:1450:4864:20::52b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5753e448-bca6-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 19:40:08 +0100 (CET)
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-5d7e527becaso936919a12.3
 for ; Tue, 17 Dec 2024 10:40:08 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab96068a96sm475088766b.73.2024.12.17.10.40.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 10:40: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: 5753e448-bca6-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734460808; x=1735065608; 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=SR6YHJNa9owjTtl43jTu7TH1sEFYkOvFgGO5HaPjWtU=;
        b=b0H2rYKlBobbYY4Jw3fbPEddEgdMhNoNbM3dm2XgFnNuHNMquRuQ3oRESgWQxm+B85
         lq/JS4jYuKU4fmTD3y4t3Tl0SidvBrPLtvSfgLKMWegVORmHjg2J538nVfws07o+dvu6
         MKr14woSd1OtOCbZUb1aeI+iNoaK0Hwv1n4R3GXn/cI+5oBUYYkULslBWR/NEgw4ejdl
         PlIAcB0L22Qx1t/0uhWyjDE2KRnihyQy9zAIU9rlTdSNB9kNp3Yop40ksiPqW2Drz3y5
         8q6SOPT0ZqqFGshtpFPK6y+k5BhmJ+f7hAra7qC5xzU/khW6ihmOJydxg9/iXy6s2ZVE
         bxBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734460808; x=1735065608;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=SR6YHJNa9owjTtl43jTu7TH1sEFYkOvFgGO5HaPjWtU=;
        b=k9DzoNCtRGp1Bgd8ZVPak53itNIGKPT4bdj0Ym0gEXDem+ccpF+O7mEZjtinKjbs2y
         jQRaA588GLcnTPL/t6Z0pIhbUh4g9mXXhiPjhwq70HO5lNB1/qYOLDmFCJ/q5xsgjEAr
         yMbkr/UspAvdPOM757Lp8rYpi3FwCsyCC+HH1P5s8Ul3FJE7pe0hAL+FMCIh/eWbwqsv
         8Io2LLM5/yMcWwY9tKLdFdh/Z4tpvKHYagtGFnNBXojnmE6YCM0nYictUkF5/L7jg61Y
         0p6uAr3oP0eM3kk4VFKJwEe9H2qrNxtr+83q8Tenvm2oDjjcOy4ZG2lzo2vguwiS0We6
         uQgA==
X-Gm-Message-State: AOJu0YwScVK2ywcJ26aX5Nj4UC5G/O2i+X+tIa8M6i/iMLjO4/KBL20m
	+ThVf5sih2IIMpWM86p08BxckEcOUajhbWd0XJLioc/a2hNTpk81dNKtTMk1O0g=
X-Gm-Gg: ASbGncvJqoNU1GRO097Nkoc9T6CbY5WNpVBxhug+/5TF14nijSV/3Yy84dxSuKjeet+
	7ItdKomOCfb/Ru1hOP3OUBhCl7TkbLAQ15ptrJCu7B9CQvIxAkDdlT3OK5zWhodScKxR8zgKCmP
	3iRWtTI8PiqnGzVygHfZSjVgMmcZt62X7fAsgLiO0ZE3JD+Fbz0c/mBIcFrIyBFJkQxjcOjilaN
	jJnxos8QcuVG9VyuzUxg+j+42Qi2SJ+tjYkRtaMyowkxFGlaWayIVHwggkARf1J0vlQeUhqKBNo
	Xg3doXjbiJZEJxU1JzMvIqXpkfVxfGcr3PiTdYiCIH3OxPsafrsa2cj2ianCno2aH+Xc37lEF75
	z4LZllw==
X-Google-Smtp-Source: AGHT+IFzgAMZn5lovfApKMkBxc3pMRfMneV0ZUPlK+qZZTjoeMb9Vy/BeMDcxAs0c4PECpZXEqFrRg==
X-Received: by 2002:a05:6402:538a:b0:5d0:bf5e:eb8 with SMTP id 4fb4d7f45d1cf-5d7ee3ef4b2mr296979a12.23.1734460808266;
        Tue, 17 Dec 2024 10:40:08 -0800 (PST)
Message-ID: <450e9ba3-0df6-456b-a461-92c9d7652fd6@suse.com>
Date: Tue, 17 Dec 2024 19:40:07 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 5/5] tools/xenstored: use new stable interface instead
 of libxenctrl
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org,
 Samuel Thibault , Julien Grall 
References: <20241217142218.24129-1-jgross@suse.com>
 <20241217142218.24129-6-jgross@suse.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: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------sXmoc73SwPQ9NPYe4mB55ETj"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------sXmoc73SwPQ9NPYe4mB55ETj
Content-Type: multipart/mixed; boundary="------------hWTFOetRL0jvT5XUhYWBTDbu";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Anthony PERARD 
Cc: xen-devel@lists.xenproject.org,
 Samuel Thibault , Julien Grall 
Message-ID: <450e9ba3-0df6-456b-a461-92c9d7652fd6@suse.com>
Subject: Re: [PATCH v5 5/5] tools/xenstored: use new stable interface instead
 of libxenctrl
References: <20241217142218.24129-1-jgross@suse.com>
 <20241217142218.24129-6-jgross@suse.com> 
In-Reply-To: 

--------------hWTFOetRL0jvT5XUhYWBTDbu
Content-Type: multipart/mixed; boundary="------------0aBYkAgqG02IBWAdN0FTYyye"

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

T24gMTcuMTIuMjQgMTg6MzMsIEFudGhvbnkgUEVSQVJEIHdyb3RlOg0KPiBPbiBUdWUsIERl
YyAxNywgMjAyNCBhdCAwMzoyMjoxOFBNICswMTAwLCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0K
Pj4gZGlmZiAtLWdpdCBhL3Rvb2xzL3hlbnN0b3JlZC9kb21haW4uYyBiL3Rvb2xzL3hlbnN0
b3JlZC9kb21haW4uYw0KPj4gaW5kZXggNjRjOGZkMGNjMy4uYTY1MDZhNWJiMiAxMDA2NDQN
Cj4+IC0tLSBhL3Rvb2xzL3hlbnN0b3JlZC9kb21haW4uYw0KPj4gKysrIGIvdG9vbHMveGVu
c3RvcmVkL2RvbWFpbi5jDQo+PiBAQCAtMTI1OCwxNSArMTI0OCw5IEBAIHZvaWQgZG9tYWlu
X2Vhcmx5X2luaXQodm9pZCkNCj4+ICAgCWlmICghZG9taGFzaCkNCj4+ICAgCQliYXJmX3Bl
cnJvcigiRmFpbGVkIHRvIGFsbG9jYXRlIGRvbWFpbiBoYXNodGFibGUiKTsNCj4+ICAgDQo+
PiAtCXhjX2hhbmRsZSA9IHRhbGxvYyh0YWxsb2NfYXV0b2ZyZWVfY29udGV4dCgpLCB4Y19p
bnRlcmZhY2UqKTsNCj4+IC0JaWYgKCF4Y19oYW5kbGUpDQo+PiAtCQliYXJmX3BlcnJvcigi
RmFpbGVkIHRvIGFsbG9jYXRlIGRvbWFpbiBoYW5kbGUiKTsNCj4+IC0NCj4+IC0JKnhjX2hh
bmRsZSA9IHhjX2ludGVyZmFjZV9vcGVuKDAsMCwwKTsNCj4+IC0JaWYgKCEqeGNfaGFuZGxl
KQ0KPj4gLQkJYmFyZl9wZXJyb3IoIkZhaWxlZCB0byBvcGVuIGNvbm5lY3Rpb24gdG8gaHlw
ZXJ2aXNvciIpOw0KPj4gLQ0KPj4gLQl0YWxsb2Nfc2V0X2Rlc3RydWN0b3IoeGNfaGFuZGxl
LCBjbG9zZV94Y19oYW5kbGUpOw0KPj4gKwl4bV9oYW5kbGUgPSB4ZW5tYW5hZ2Vfb3BlbihO
VUxMLCAwKTsNCj4+ICsJaWYgKCF4bV9oYW5kbGUpDQo+PiArCQliYXJmX3BlcnJvcigiRmFp
bGVkIHRvIG9wZW4gY29ubmVjdGlvbiB0byBsaWJ4ZW5tYW5hZ2UiKTsNCj4+ICAgDQo+PiAg
IAl4Z3RfaGFuZGxlID0gdGFsbG9jKHRhbGxvY19hdXRvZnJlZV9jb250ZXh0KCksIHhlbmdu
dHRhYl9oYW5kbGUqKTsNCj4+ICAgCWlmICgheGd0X2hhbmRsZSkNCj4+IEBAIC0xMzA2LDYg
KzEyOTAsOCBAQCB2b2lkIGRvbWFpbl9kZWluaXQodm9pZCkNCj4+ICAgew0KPj4gICAJaWYg
KHZpcnFfcG9ydCkNCj4+ICAgCQl4ZW5ldnRjaG5fdW5iaW5kKHhjZV9oYW5kbGUsIHZpcnFf
cG9ydCk7DQo+PiArDQo+PiArCXhlbm1hbmFnZV9jbG9zZSh4bV9oYW5kbGUpOw0KPiANCj4g
SXMgdGhpcyB0aGUgcmlndGggcGxhY2UgdG8gZnJlZSBgeG1faGFuZGxlYD8gZG9tYWluX2Rl
aW5pdCgpIHNlZW1zIHRvDQo+IG9ubHkgYmUgY2FsbGVkIGJ5IHRoZSBsaXZlIHVwZGF0ZSBj
b2RlLiBBbGwgdGhlIG90aGVyIGluaXRpYWxpc2F0aW9uDQo+IGRvbmUgaW4gZG9tYWluX2Vh
cmx5X2luaXQoKSBhcmUgZnJlZSB2aWEgdGFsbG9jX2F1dG9mcmVlKCkgaXQgc2VlbXMsDQo+
IHdoaWNoIGlzIGNhbGxlZCBieSBhdGV4aXQoKS4NCj4gDQo+IFNvLCBzaG91bGRuJ3QgYHht
X2hhbmRsZWAgYnkgaGFuZGxlIHdpdGggdGFsbG9jIGxpa2UgdGhlIG90aGVycz8NCg0KTm8s
IEkgZG9uJ3QgdGhpbmsgc28uDQoNClRCSCwgSSdtIHF1ZXN0aW9uaW5nIHRoZSB0YWxsb2Mo
KSBhbGxvY2F0aW9uIG9mIHRoZSBvdGhlciBoYW5kbGVzLCB0b28uDQoNClRoZSBvbmx5IGNh
c2Ugd2hlcmUgeGVuc3RvcmVkIGlzIHN0b3BwZWQgSVMgdGhlIGxpdmUgdXBkYXRlIGNhc2Uu
IEFwYXJ0DQpmcm9tIGNyYXNoZXMsIG9mIGNvdXJzZSwgYnV0IHRob3NlIHdvbid0IGV4ZWN1
dGUgdGhlIGRlc3RydWN0b3JzIGVpdGhlci4NCg0KDQpKdWVyZ2VuDQo=
--------------0aBYkAgqG02IBWAdN0FTYyye
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-----

--------------0aBYkAgqG02IBWAdN0FTYyye--

--------------hWTFOetRL0jvT5XUhYWBTDbu--

--------------sXmoc73SwPQ9NPYe4mB55ETj
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/Ey8FAmdhxYcFAwAAAAAACgkQsN6d1ii/Ey9/
hggAlRbMZXGBugIzbv+P4aB/huwe2EbOLJrCF1R2THF4lqLuZFX3Ads+Y4b9Nw3zdqljGl+hyFfv
nJYKuWCgTSKlhrIgbG06FOULlJgkhPQkxwGAAV8KLsC7bT3Ds7EEwIJisg1+FLgsneiDL1KLwT3q
IOzyOd10Q+/jpGntDF6GA/KJ9YfzgA65AM0oEV16e4F+BshZfMG5MBqXaTKetWPihmb+vlH31wgg
5rsqLcfg1oNX6OGHuEyXVGEbjw8Sav/VlY51oCGVHQkjvECcMRJb3OJQF9VxYx2CTwO76ujt+cmL
wQNIYXp5yuOQL2CG94RMfa3rpirbf6MRv8iey4x40g==
=5z8B
-----END PGP SIGNATURE-----

--------------sXmoc73SwPQ9NPYe4mB55ETj--


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 20:53:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 20:53:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859880.1271957 (Exim 4.92)
	(envelope-from )
	id 1tNeZP-0003pW-4P; Tue, 17 Dec 2024 20:53:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859880.1271957; Tue, 17 Dec 2024 20:53: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 1tNeZP-0003pP-1X; Tue, 17 Dec 2024 20:53:31 +0000
Received: by outflank-mailman (input) for mailman id 859880;
 Tue, 17 Dec 2024 20:53: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 1tNeZN-0003pJ-Kn
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 20:53:29 +0000
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id f634788c-bcb8-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 21:53:27 +0100 (CET)
Received: from [192.168.35.166] (c-73-118-245-227.hsd1.wa.comcast.net
 [73.118.245.227])
 by linux.microsoft.com (Postfix) with ESMTPSA id 313DC2171F96;
 Tue, 17 Dec 2024 12:53: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: f634788c-bcb8-11ef-a0d6-8be0dac302b0
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 313DC2171F96
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1734468805;
	bh=aVc5gziW3F5u0OxTruXlabKnVm24GGvTVYzcdDQRKKI=;
	h=Date:Cc:Subject:To:References:From:In-Reply-To:From;
	b=PN+5X7vl8fqADT/aII8zIGfk60UMtxJ9pR+EBirm4pXAa4JZO11zP4etUexy4ZsF1
	 Hz5jBPkUY126l1G2C1Lf0cgYJmqJpx2Ac/wrr+Dl/I1W058j7FPkFRH8CsABxT6WHb
	 +lq4b3CWgOR3ojB2J6CV+93O4Hyq14ifZiz9VEy4=
Message-ID: <14ad0c08-7b3b-47b6-8cc1-8a4179238e5a@linux.microsoft.com>
Date: Tue, 17 Dec 2024 12:53:22 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Cc: eahariha@linux.microsoft.com, Pablo Neira Ayuso ,
 Jozsef Kadlecsik ,
 "David S. Miller" , Eric Dumazet ,
 Jakub Kicinski , Paolo Abeni ,
 Simon Horman , Julia Lawall ,
 Nicolas Palix , Daniel Mack ,
 Haojian Zhuang ,
 Robert Jarzmik , Russell King
 , Heiko Carstens ,
 Vasily Gorbik , Alexander Gordeev
 , Christian Borntraeger ,
 Sven Schnelle , Ofir Bitton ,
 Oded Gabbay , Lucas De Marchi
 ,
 =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= ,
 Rodrigo Vivi ,
 Maarten Lankhorst ,
 Maxime Ripard , Thomas Zimmermann ,
 David Airlie , Simona Vetter ,
 Jeroen de Borst ,
 Praveen Kaligineedi ,
 Shailend Chand , Andrew Lunn ,
 James Smart ,
 Dick Kennedy ,
 "James E.J. Bottomley" ,
 "Martin K. Petersen" ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Jens Axboe , Kalle Valo ,
 Jeff Johnson , Catalin Marinas
 , Jack Wang ,
 Marcel Holtmann ,
 Johan Hedberg ,
 Luiz Augusto von Dentz ,
 Greg Kroah-Hartman ,
 Florian Fainelli , Ray Jui
 , Scott Branden ,
 Broadcom internal kernel review list
 , Xiubo Li ,
 Ilya Dryomov , Josh Poimboeuf ,
 Jiri Kosina , Miroslav Benes ,
 Petr Mladek , Joe Lawrence ,
 Jaroslav Kysela , Takashi Iwai ,
 Louis Peens , Michael Ellerman
 , Nicholas Piggin ,
 Christophe Leroy ,
 Naveen N Rao , Madhavan Srinivasan ,
 netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
 netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cocci@inria.fr,
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org,
 ath11k@lists.infradead.org, linux-mm@kvack.org,
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev,
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org,
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org,
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org,
 Anna-Maria Behnsen ,
 Jeff Johnson , paul@paul-moore.com
Subject: Re: [PATCH v3 00/19] Converge on using secs_to_jiffies()
To: Andrew Morton 
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
 <20241210163520.95fa1c8aa83e1915004ed884@linux-foundation.org>
 <422470cd-84f0-469e-93c2-493c5091391d@linux.microsoft.com>
From: Easwar Hariharan 
Content-Language: en-US
In-Reply-To: <422470cd-84f0-469e-93c2-493c5091391d@linux.microsoft.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12/10/2024 5:00 PM, Easwar Hariharan wrote:
> On 12/10/2024 4:35 PM, Andrew Morton wrote:
>> On Tue, 10 Dec 2024 22:02:31 +0000 Easwar Hariharan  wrote:
>>
>>> This is a series that follows up on my previous series to introduce
>>> secs_to_jiffies() and convert a few initial users.
>>
>> Thanks, I added this to mm.git.  I suppressed the usual added-to-mm
>> emails because soooo many cc's!
>>
>> I'd ask relevant maintainers to send in any acks and I'll paste them
>> into the relevant changelogs.
> 
> Thank you, Andrew!
> 
> - Easwar

Hi Andrew,

There have been a couple of comments[1][2] that came in after you queued
the series to mm. Would you rather I send individual patches addressing
these, or just send a v4 of the entire series (-netdev of course) so you
can replace it wholesale?

Thanks,
Easwar

[1]
https://lore.kernel.org/all/07784753-6874-4dda-a080-2d2812f4a10a@csgroup.eu/
[2]
https://lore.kernel.org/all/Z2G1ZPL2cAlQOYlF@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com/


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 21:12:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 21:12:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859889.1271967 (Exim 4.92)
	(envelope-from )
	id 1tNerm-0006t2-F5; Tue, 17 Dec 2024 21:12:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859889.1271967; Tue, 17 Dec 2024 21:12:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNerm-0006sv-CW; Tue, 17 Dec 2024 21:12:30 +0000
Received: by outflank-mailman (input) for mailman id 859889;
 Tue, 17 Dec 2024 21:12: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 1tNerk-0006sp-QO
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 21:12:28 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9d6009c7-bcbb-11ef-99a3-01e77a169b0f;
 Tue, 17 Dec 2024 22:12:26 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 6C856A41FAF;
 Tue, 17 Dec 2024 21:10:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30F7CC4CED7;
 Tue, 17 Dec 2024 21:12:22 +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: 9d6009c7-bcbb-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org;
	s=korg; t=1734469944;
	bh=6wrZIip+47/78xZMxlKfy5iKCSXmDm0ozFscqh0XaL0=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=nmF/sQCS1D3KNHotz6/Uis21dHNJl7nLly6pcknq1IkDIafHawvIl5RaL9/QyQcZn
	 nyGQz6EdiI98Lm7qeFHMwWswlC3Qfefy9eWeYO8Zhv+gHExXCf5+0KsSm0kSj2kwOJ
	 8nof/rwPL6N6M8ZNuUmnLRmLS4svJ9udLDC6DdE4=
Date: Tue, 17 Dec 2024 13:12:21 -0800
From: Andrew Morton 
To: Easwar Hariharan 
Cc: Pablo Neira Ayuso , Jozsef Kadlecsik
 , "David S. Miller" , Eric
 Dumazet , Jakub Kicinski , Paolo
 Abeni , Simon Horman , Julia Lawall
 , Nicolas Palix , Daniel Mack
 , Haojian Zhuang , Robert
 Jarzmik , Russell King ,
 Heiko Carstens , Vasily Gorbik ,
 Alexander Gordeev , Christian Borntraeger
 , Sven Schnelle , Ofir
 Bitton , Oded Gabbay , Lucas De
 Marchi , Thomas =?ISO-8859-1?Q?Hellstr=F6m?=
 , Rodrigo Vivi ,
 Maarten Lankhorst , Maxime Ripard
 , Thomas Zimmermann , David Airlie
 , Simona Vetter , Jeroen de Borst
 , Praveen Kaligineedi ,
 Shailend Chand , Andrew Lunn ,
 James Smart , Dick Kennedy
 , "James E.J. Bottomley"
 , "Martin K. Petersen"
 , Roger Pau =?ISO-8859-1?Q?Monn=E9?=
 , Jens Axboe , Kalle Valo
 , Jeff Johnson , Catalin Marinas
 , Jack Wang , Marcel
 Holtmann , Johan Hedberg ,
 Luiz Augusto von Dentz , Greg Kroah-Hartman
 , Florian Fainelli
 , Ray Jui , Scott Branden
 , Broadcom internal kernel review list
 , Xiubo Li , Ilya
 Dryomov , Josh Poimboeuf , Jiri
 Kosina , Miroslav Benes , Petr Mladek
 , Joe Lawrence , Jaroslav Kysela
 , Takashi Iwai , Louis Peens
 , Michael Ellerman , Nicholas
 Piggin , Christophe Leroy ,
 Naveen N Rao , Madhavan Srinivasan
 , netfilter-devel@vger.kernel.org,
 coreteam@netfilter.org, netdev@vger.kernel.org,
 linux-kernel@vger.kernel.org, cocci@inria.fr,
 linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
 dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
 linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org,
 linux-block@vger.kernel.org, linux-wireless@vger.kernel.org,
 ath11k@lists.infradead.org, linux-mm@kvack.org,
 linux-bluetooth@vger.kernel.org, linux-staging@lists.linux.dev,
 linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org,
 live-patching@vger.kernel.org, linux-sound@vger.kernel.org,
 oss-drivers@corigine.com, linuxppc-dev@lists.ozlabs.org, Anna-Maria Behnsen
 , Jeff Johnson ,
 paul@paul-moore.com
Subject: Re: [PATCH v3 00/19] Converge on using secs_to_jiffies()
Message-Id: <20241217131221.e1b1262f97dc6a5d616ca8e7@linux-foundation.org>
In-Reply-To: <14ad0c08-7b3b-47b6-8cc1-8a4179238e5a@linux.microsoft.com>
References: <20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com>
	<20241210163520.95fa1c8aa83e1915004ed884@linux-foundation.org>
	<422470cd-84f0-469e-93c2-493c5091391d@linux.microsoft.com>
	<14ad0c08-7b3b-47b6-8cc1-8a4179238e5a@linux.microsoft.com>
X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 17 Dec 2024 12:53:22 -0800 Easwar Hariharan  wrote:

> There have been a couple of comments[1][2] that came in after you queued
> the series to mm. Would you rather I send individual patches addressing
> these, or just send a v4 of the entire series (-netdev of course) so you
> can replace it wholesale?

Individual small fixes would be preferable please.  Mainly to
preserve the validity of current review efforts.


From xen-devel-bounces@lists.xenproject.org Tue Dec 17 21:19:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 21:19:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859897.1271978 (Exim 4.92)
	(envelope-from )
	id 1tNeyQ-0007Wi-3O; Tue, 17 Dec 2024 21:19:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859897.1271978; Tue, 17 Dec 2024 21:19: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 1tNeyQ-0007Wb-0o; Tue, 17 Dec 2024 21:19:22 +0000
Received: by outflank-mailman (input) for mailman id 859897;
 Tue, 17 Dec 2024 21:19: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 1tNeyP-0007WV-3A
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 21:19:21 +0000
Received: from NAM12-MW2-obe.outbound.protection.outlook.com
 (mail-mw2nam12on20609.outbound.protection.outlook.com
 [2a01:111:f403:200a::609])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 92a244ec-bcbc-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 22:19:18 +0100 (CET)
Received: from BN9PR03CA0091.namprd03.prod.outlook.com (2603:10b6:408:fd::6)
 by SJ2PR12MB9137.namprd12.prod.outlook.com (2603:10b6:a03:562::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Tue, 17 Dec
 2024 21:19:13 +0000
Received: from BL6PEPF0001AB4B.namprd04.prod.outlook.com
 (2603:10b6:408:fd:cafe::c3) by BN9PR03CA0091.outlook.office365.com
 (2603:10b6:408:fd::6) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.14 via Frontend Transport; Tue,
 17 Dec 2024 21:19:12 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BL6PEPF0001AB4B.mail.protection.outlook.com (10.167.242.69) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Tue, 17 Dec 2024 21:19:12 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 17 Dec
 2024 15:19:11 -0600
Received: from amd-BIRMANPLUS.mshome.net (10.180.168.240) by
 SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39
 via Frontend Transport; Tue, 17 Dec 2024 15:19:10 -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: 92a244ec-bcbc-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CNYU6mEQ+Pwj/1CJAfTcpFuYaY6MNoBREdUsrX0UY23XUaHq5h7nGv4mC1KHpgF7c3xslwHccUgObkwoN3iOpUOwg2emXxQVwuuW13VZfkUMT20F34o9Yh0EcBWYMRVWiWDj0cgKb9JDVBtHmfh/NPoaGPJL4QsXriLXouVRZst1CYw9szEJRAEZ5bDsXcqWjLRU/iqxQ95vrOsiQRPo45eaw/7xaVDQv7B8fKXKzTgTDwyaVN14yLSAWCpU73L6iu3K111HL+uRuGzn2W5o4MrLX7R5fKbptPPOE4qfe9wna7j5QQ/UaImGNl/ZkMGhfZJKY3E/F9xCKS+Xke/5ig==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=j4uW22R7L//WOI3zTt03o+J5QXM2VE11hPWTrbGf9bc=;
 b=WfST7oHfqlQCSQePoSMjmlgicckyIuSb4a6oGp+yWbM8iOiltIilmS3KFOLBKbEQaZwNIwD0eBMvFS5CGik2kuE6/DvAjQqs3psaIhokB5pd81ZQAl1w12K5E0hKfkS269WY6aTP5fU8yKCGnJFFUN40CJiW9kYsucH6aLiBkr2fw2GSH3Ld9Mea0eAi6+i6ZogiXE+WZ2sMq4rjboyEnMnlFVoQsJyfkLaXPPl4ESUSMkezNE6Pfv5P0T/cCTeqz+I3hFujp/AVxCewxhJlcXA0DHlNLVvNIngP981ZeysHnQFy/GGaE+ivp7ZvEnmxmUEHpNg/YpRw/pjk1V6mfw==
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=j4uW22R7L//WOI3zTt03o+J5QXM2VE11hPWTrbGf9bc=;
 b=jtqBMJGe2QQJsTSsMCnU9VAuGMqFIYI4NaGsFniBabtEE3dmiLQM9+T4+tX7Gbm5t3sAngAFsCFd2xOAjB6c2Kj5z1IbK/Pmjk0mKNg/ryjQyCea13kgRLTEXuS6W5dfX6tnBOv282CQK/DpOLJdI/0M+EKQP966hTOtx/FkhhE=
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=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Stefano Stabellini , Michal Orzel
	, Jason Andryuk 
Subject: [ImageBuilder] Add zstd compression support
Date: Tue, 17 Dec 2024 16:19:03 -0500
Message-ID: <20241217211903.5945-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB4B:EE_|SJ2PR12MB9137:EE_
X-MS-Office365-Filtering-Correlation-Id: 210c1747-ea21-4cbe-d5a4-08dd1ee073cc
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?Ri93xrGitH+g1tMWTKciezeny4JMI2J71iphpGVhXp/ZS1Qmcgb1UU5Cr0ZE?=
 =?us-ascii?Q?aLEnDwuF4MHTxbCfKeQCiSErm5Yl9mHnj0zHrTdKsn2yyx1bMr4aLIPEwqvV?=
 =?us-ascii?Q?/rq5QkxcZ0fhMaWX3WXu0hkaRFAvpG//aBCEUwPzs+EutYcWut5R6ceiyk19?=
 =?us-ascii?Q?o4YdVNHkfeCoZH0dCn7lD9yovET9ZlzSzTL+U4aS5aCcX7N+RjBze61b8JIQ?=
 =?us-ascii?Q?ySxfc6jE/cqyBiCB2UVM+d/WZMpB8YzGKvjXZxgPIK6L0nCBdKxhy3wAl2z2?=
 =?us-ascii?Q?9r1krwJB83A8LdMFNNxz5AivKAzKaNnxqV2YLvIf/uY2/ImfEqWMkJnZwvnM?=
 =?us-ascii?Q?KG5QWnBs97zS4/Qdu50m4uAFI8i4c7IVJ0vHbVCWXY4zOK3P6vij3G7OkADC?=
 =?us-ascii?Q?GZQ7aNlvx2/8fUCjc/R7cOVq47BHXaCs+jc5Ia0T+jZQP01i4NixiXLBwTI5?=
 =?us-ascii?Q?5IqNLv4gWZ+4VeVjP9BoZVzD0+JgMbszSokjev2TBkZTjxPpz8HSo6rArXJv?=
 =?us-ascii?Q?RtJq9IQ8yeJHCRwRNmwlMdzpO6nLBI0Kckj0olhl09m+0vsXMncJHut/JbMw?=
 =?us-ascii?Q?6LiuOshE8y+eY6hY9gE7HJ78PyO2rggfEZZPhUhSXOvaNelAyWim6WmsVkKx?=
 =?us-ascii?Q?kRFiyUzClfVyIsheleGxHdNJKQ1VEw2KvF6sULBILqvZIKCx+Tmd/e3NPie2?=
 =?us-ascii?Q?XreKIDVNRkxepto1Q3YSzmJPbWwkYweSnhKfJf4O+m/gK2udWOZpLoPrd2cY?=
 =?us-ascii?Q?NfFORjzIcfEcknnMUT7+CKJalQmYD6yPiC8puO5tgXM8ORqzStPzbWQpxpd/?=
 =?us-ascii?Q?vEVjUDf12eNYBub7Y09HzwyMSzUlzESzioGhodFrT302j0jSGWL8dX9CnRoN?=
 =?us-ascii?Q?8GzeZgnqBc5HttagiCFFFRBTu8OjE3D3L7aTFSeBejgsFDr8ffTB20fuKGbO?=
 =?us-ascii?Q?v/QSBvFIoa0qK99IozA2+QsDJaDBwo/5YM6AjmqLTrum8fHbiK606yFQ8uhi?=
 =?us-ascii?Q?wbd3EewmDuYMFTxtxIjqVWYVaGbfXC1KYc1zzwkgk2RjXBWBam1ocYGRJgYn?=
 =?us-ascii?Q?ETbB9rXy2eG0CNcvdJs2RVVnPDMo+zVh32iHErS2pjHVuuImY2eUT1ZNnhM+?=
 =?us-ascii?Q?VNVOt3IB9k6ZNC+fZ7Y0NGY3sZ+l0n95TbWx8BwJAJu/BRYpTgY+0MDQmT3v?=
 =?us-ascii?Q?GE3JbUsA5jQ7ZAhbcdAVwIoGu8cQEj3jmVPYozN+Q0xQmM4m/CphYBU2lP2R?=
 =?us-ascii?Q?4Wqvnmme547sJh+fmUwVO4z5Mv6fKDb+dBOC2p5EeGv6szz0GjjTBGEy5l0R?=
 =?us-ascii?Q?iLAVaJX0A2VHlIAAQBh1mBV1Vqtr2fmXQOgFB5+pFshK5epkMot6W8/kBoc2?=
 =?us-ascii?Q?Iy5W5mOcv1OT1Tm3TTXp4LkhFfdh4bcImdphPEac09UjZ9/QQsIzHYBfTFTw?=
 =?us-ascii?Q?bbsdjQgC9sxWA6vFMXFZDzQbwq2fp3D8rq6YnYKfUQN0DiX8mM1EiAe/nYE/?=
 =?us-ascii?Q?KzPKLl7cBjPkrxY=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2024 21:19:12.0008
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 210c1747-ea21-4cbe-d5a4-08dd1ee073cc
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL6PEPF0001AB4B.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB9137

uboot-script-gen fails to process a zstd-compressed initramdisk, exiting
with:
Wrong file type initrd.img. It should be cpio archive, exiting.

Extend the existing approach to also check zstd.

Signed-off-by: Jason Andryuk 
---
 scripts/uboot-script-gen | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
index fc63702..db2c011 100755
--- a/scripts/uboot-script-gen
+++ b/scripts/uboot-script-gen
@@ -567,6 +567,7 @@ function check_compressed_file_type()
 {
     local filename=$1
     local type="$2"
+    local file_type
 
     if [ ! -f $filename ]
     then
@@ -574,13 +575,17 @@ function check_compressed_file_type()
         cleanup_and_return_err
     fi
 
-    file -L $filename | grep "gzip compressed data" &> /dev/null
-    if test $? == 0
-    then
+    file_type=$( file -L $filename )
+    if echo "$file_type" | grep -q "gzip compressed data" ; then
         local tmp=`mktemp`
         tmp_files+=($tmp)
         cat $filename | gunzip > $tmp
         filename=$tmp
+    elif echo "$file_type" | grep -q "Zstandard compressed data" ; then
+        local tmp=`mktemp`
+        tmp_files+=($tmp)
+        zstdcat $filename > $tmp
+        filename=$tmp
     fi
     check_file_type $filename "$type"
 }
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 22:25:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 22:25:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859913.1271999 (Exim 4.92)
	(envelope-from )
	id 1tNfzr-0000rK-LB; Tue, 17 Dec 2024 22:24:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859913.1271999; Tue, 17 Dec 2024 22:24: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 1tNfzr-0000rD-Id; Tue, 17 Dec 2024 22:24:55 +0000
Received: by outflank-mailman (input) for mailman id 859913;
 Tue, 17 Dec 2024 22:24: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 1tNfzq-0000r6-0L
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 22:24:54 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20630.outbound.protection.outlook.com
 [2a01:111:f403:2416::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bafbf2e5-bcc5-11ef-a0d6-8be0dac302b0;
 Tue, 17 Dec 2024 23:24:52 +0100 (CET)
Received: from BN1PR14CA0004.namprd14.prod.outlook.com (2603:10b6:408:e3::9)
 by DS0PR12MB7745.namprd12.prod.outlook.com (2603:10b6:8:13c::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Tue, 17 Dec
 2024 22:24:44 +0000
Received: from BN2PEPF000044AA.namprd04.prod.outlook.com
 (2603:10b6:408:e3:cafe::e9) by BN1PR14CA0004.outlook.office365.com
 (2603:10b6:408:e3::9) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.22 via Frontend Transport; Tue,
 17 Dec 2024 22:24:44 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN2PEPF000044AA.mail.protection.outlook.com (10.167.243.105) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Tue, 17 Dec 2024 22:24:44 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 17 Dec
 2024 16:24:43 -0600
Received: from amd-BIRMANPLUS.mshome.net (10.180.168.240) by
 SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39
 via Frontend Transport; Tue, 17 Dec 2024 16:24:42 -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: bafbf2e5-bcc5-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TJthO2heabp6ruxHX3uxtScD71O0mcMnc4ky6o7UfG0y/bip+7NHFdaNQto9d9/iiupH1PARUvNU87AlewG5qLcjxGKO4VDqYI6/jvmGAafVlybmmTJtVIuWipySkMVLkk1BBA3bc11YhqJeUzcF2dCs7lFFhQxZ6TWqLE6V/Cg5aamfjSue0RUoh/wZ0csD+vQq8WErVYQ6ZX65KZxNRtCVSkvucUR1TPC+TQddPFpUgIFysX/WxsunK8Q0YnHh9Wh7LJbi7Sz8hSH9s7mMxlzMo/ZW0Y0AmswZ11LqUsQ3YhdAtzRvG3bqXQJkFH7CzmPu3cNP1220pgzMyHCSzA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=L8xuwI0/yejCLIWz0+Qwjv4SG6qlHBSVP/vH0Ki1GMQ=;
 b=o1OsAFj71hsGW7QcXlLRZmIB4yGeS0MD0or7ECPyzxlCox9fedJ4+FrWhP6Gl4/T4plFOFBHP0lJAzZsWMo7E4cpVN5TBV2Fv66Z58PG4Y/uKTCjrQ2z9R6IxDI0GW3GbX1p5pVSHfAxvpHL2+2ZrVbI3q2JT7AmYLwHz4oxM+k6Pl5iY77kQxPfXyrFMNndbuGAU01iioS3htoeT/L575Mq07I3yhCxjCEcJ54hWLjjUisAJn+3TH2PpVMrOWRESpUFNyzs8qRIf96hIg4ENNuV3dG+O5xAcHoWHuNHEFN5mBxgPMH6j2gM3GgZlb4Ti3FRqziYNKs9UtSzadxG0Q==
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=L8xuwI0/yejCLIWz0+Qwjv4SG6qlHBSVP/vH0Ki1GMQ=;
 b=i97GbPu2l/fO/rXCM8vLFcZeL7wtRbwRilMClpJnFyAbxHYgj01hzCOi0amamttkkelwH8R5SVBHwQXdZppfWd0opabYzGr/v4gZ1n+Re/FcrWZd4iKs8hfx7MmDJjHnaGOQ0F0sGQbTvC3FG2q0DLUylCCuul4q/oT1XGNlRvA=
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=SATLEXMB03.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Anthony PERARD
	, Juergen Gross 
Subject: [RFC PATCH Hyperlaunch] xenconsole: Add connected flag
Date: Tue, 17 Dec 2024 17:24:24 -0500
Message-ID: <20241217222424.7632-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB03.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000044AA:EE_|DS0PR12MB7745:EE_
X-MS-Office365-Filtering-Correlation-Id: 9467866e-feb6-4b2b-eec9-08dd1ee99b97
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?JIxnA1Jwk7vnRyvyrAvEQB4vyF0hsUUeTr05VihN/x4Vkx88M8fmD92qW7nh?=
 =?us-ascii?Q?eVfpzW7yR/B3QBsSI4M9aDc8uZAPXLdjrQ/T3yWMkz+KcnAeC0tcwibY02t8?=
 =?us-ascii?Q?EIj7l0FJcW9tlXsi6O7yBsrTGZKwJhuqgk9kkQsGce0LiqFlIUtZL9Ry8PMm?=
 =?us-ascii?Q?P2ez2YkFRyv+1wVj1+DbvVldBl1qY1HimIYmmHIYrIvHghRCdS+n70HHw6Ai?=
 =?us-ascii?Q?x+8AVZaq7g6Hzy3elvWsyF0OcQyKviIiN0t1P5jqs4nnYNGigK9rsaW8/WWp?=
 =?us-ascii?Q?CebfPwcpfzMgtLJX/NjTp9A9obSIRu4SWaQHmI5YmPJnF6XOVVS0RWIU58jJ?=
 =?us-ascii?Q?zrPvaCVR3fR3zmeXrdPKh9Fh1qJHUTs3JgduksWAn05YIkHdnxctiCA2K1KW?=
 =?us-ascii?Q?/3Rc5vUns44DgSDQC5RuVz1MCZXtAJ6AwhbIyDrB5PcPv1JY99s8B+6NMKpz?=
 =?us-ascii?Q?o8HvLmcNh3CoaT9k6MvoQ/rxxHSigKIoIKYIPK4hy3d3nKwpY1n57pC0kcdI?=
 =?us-ascii?Q?LJHBBaZx8PPMU/CfZEBZIO/nCXrtSbpTRqsq9r2X9V9u9sAwKMW6uDv1PDDn?=
 =?us-ascii?Q?X0mAody8FJ2GsIYVvg1PLssWT5UbIVp8rkwLTsNy2INYQUtlqHFa/zyOigh2?=
 =?us-ascii?Q?OlsUL86fJqm28nFxdf2mJA9x9cwQZM0+Q8LHHvZQs+yPx0yf9Fh6pz34bkp6?=
 =?us-ascii?Q?e9avIX3au9ROB9qH+ZCI+pewECTa/nDUxMQUA7Q219RgzsN86ZdmnGFgq8c8?=
 =?us-ascii?Q?GRlEoLjvTvQRtyvhqkUcZxOMCmJFKb1peQqFjGinJrMIMAteS3QfDHhE4bZB?=
 =?us-ascii?Q?mOtQB1a+2mfwR7gmH7AnQi9Ifyz+P1bc9bmSpD0SVvd6XdnSi8b5Dgau4oPG?=
 =?us-ascii?Q?F5LiUC3FHRShodVDDgqu/Jwu4n6AxMHjc39Gvt5haOIPvKq0CM0VPshQA/Be?=
 =?us-ascii?Q?zmvZkgrBLOORkCIzVU2Lfs1x4n2ObUQiWxBiSzw/DegL3guOEZDmeCRLuzbf?=
 =?us-ascii?Q?Q7CL1MdLtPFqLbu+75Q1lR6ER2wsKf2T2PRaDzNf25EE22HVRFU6Yr8OZkIz?=
 =?us-ascii?Q?dsi4ocbP7gik7GzZBM52ialOQ8oDIk2fbid+BzCHEVIdaAx+nCuzzJka7sbG?=
 =?us-ascii?Q?578bq9VSR5YnnjEQF/0h1nobo5r2ImlDX9IVAAed6IITdP3pnjNISRgcAIP4?=
 =?us-ascii?Q?Nq99XBpyfE4bCi38HofSyLK2rzlbVvb4eYYT1vStpl6hDwHYHuoIxopy8NtQ?=
 =?us-ascii?Q?5/NxOU86ftBPpyNERu7yj7iiR+oKT6OJqL7IUmpmU1XdxLfnDIK4/Z8g1rk+?=
 =?us-ascii?Q?jqn6C5dtETmoLvow95v1mTQNEfgnMPkpv1RJbd/6Jwpb42UlCwdiEbidCqHW?=
 =?us-ascii?Q?iy4QOJ1VnA6u8xqNnyN017ImwRFbs+4HRhQQcJ6vn2WedRyQMiLV7WEYh1ep?=
 =?us-ascii?Q?/RmcUJK7osEx+urjl4Z4m6trfNyg0a9laTEi7moiYbI5rqKmkTxvEfMC1xl2?=
 =?us-ascii?Q?M+dpupDaoIt8saA=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2024 22:24:44.2492
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9467866e-feb6-4b2b-eec9-08dd1ee99b97
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000044AA.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7745

Linux will spin in hvc_xen.c:domU_write_console() when it fills its
console ring.  This blocks hyperlaunch parallel boot since the domU
won't progress until dom0 sets up xenconsoled and starts draining the
ring.

Add a flag to the console ring page.  zero-initialized, have xenconsoled
set to 1 when it connects.  Also send an event channel notification.

The linux domU side can keep using the console hypercalls and only
transition to the ring when it is connected and won't fill and block.

Signed-off-by: Jason Andryuk 
---
In domU_write_console(), __write_console returns 0 when the ring is
full.  This loops spins until xenconsoled starts emptying the ring: 

        while (len) {
                ssize_t sent = __write_console(cons, data, len);

                if (sent < 0)
                        return sent;

                data += sent;
                len -= sent;

                if (unlikely(len))
                        HYPERVISOR_sched_op(SCHEDOP_yield, NULL);
        }

This patch is similar to the xenstore late init (though the flag is
reversed).

The idea of the event channel notification is to let the domU receive an
indication that xenconsoled is connected.  For xenstore, the xenstore
driver owns the event channel/irq and can rebind it.  For hvc_xen, the
hvc subsystem owns the irq, so it isn't readily available for rebinding.

I had the idea for the kernel to use a static key and switch writing
from the hypercall to the PV ring once connected.  It didn't actually
work in my short attempt - I think changing the static key from within
an interupt was wrong.  I fell back to just checking the flag directly
without an optimization.  That would work and would make the event
channel notification unnecessary.

 tools/console/daemon/io.c       | 6 ++++++
 xen/include/public/io/console.h | 2 ++
 2 files changed, 8 insertions(+)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index bb739bdb8c..2a7ecc6369 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -731,6 +731,9 @@ static int console_create_ring(struct console *con)
 		con->ring_ref = ring_ref;
 	}
 
+	/* Mark the console as connected */
+	con->interface->flag = XENCONSOLE_CONNECTED;
+
 	/* Go no further if port has not changed and we are still bound. */
 	if (remote_port == con->remote_port) {
 		xc_evtchn_status_t status = {
@@ -780,6 +783,9 @@ static int console_create_ring(struct console *con)
 	if (log_guest && (con->log_fd == -1))
 		con->log_fd = create_console_log(con);
 
+	/* spurious notify to check flags field */
+	xenevtchn_notify(con->xce_handle, con->local_port);
+
  out:
 	return err;
 }
diff --git a/xen/include/public/io/console.h b/xen/include/public/io/console.h
index 4509b4b689..2b408f92a3 100644
--- a/xen/include/public/io/console.h
+++ b/xen/include/public/io/console.h
@@ -19,6 +19,8 @@ struct xencons_interface {
     char out[2048];
     XENCONS_RING_IDX in_cons, in_prod;
     XENCONS_RING_IDX out_cons, out_prod;
+    #define XENCONSOLE_CONNECTED 1
+    uint32_t flag;
 };
 
 #ifdef XEN_WANT_FLEX_CONSOLE_RING
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Tue Dec 17 23:04:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Dec 2024 23:04:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859928.1272009 (Exim 4.92)
	(envelope-from )
	id 1tNgcE-0006jV-Ka; Tue, 17 Dec 2024 23:04:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859928.1272009; Tue, 17 Dec 2024 23:04: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 1tNgcE-0006jO-HK; Tue, 17 Dec 2024 23:04:34 +0000
Received: by outflank-mailman (input) for mailman id 859928;
 Tue, 17 Dec 2024 23:04: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 1tNgcD-0006jI-Pr
 for xen-devel@lists.xenproject.org; Tue, 17 Dec 2024 23:04:33 +0000
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com
 [2a00:1450:4864:20::42c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 468530db-bccb-11ef-a0d6-8be0dac302b0;
 Wed, 18 Dec 2024 00:04:32 +0100 (CET)
Received: by mail-wr1-x42c.google.com with SMTP id
 ffacd0b85a97d-385e0e224cbso3038486f8f.2
 for ; Tue, 17 Dec 2024 15:04:32 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c8012170sm12355407f8f.14.2024.12.17.15.04.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 15:04: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: 468530db-bccb-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734476671; x=1735081471; 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=B9fleBbi7AT+mll+INXas1kteOqEJlUTlJ+YFTUzAZM=;
        b=RO+heLuhw60k1c/UBWV15/qBka4zMrAuJ1Vbae+3rGTwwcjemOgNjxI1Ti0JvWkEmU
         PhUNQKCSpyPXYAFr1Bf4ZWEsjAAUFMndKlGRmoEs+Z4X8KH+jn520meD16O0aa/QCE/p
         iO1YaAkV9dGoQNY9Ak1SV2cdpGHry9KoiU6a0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734476671; x=1735081471;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=B9fleBbi7AT+mll+INXas1kteOqEJlUTlJ+YFTUzAZM=;
        b=jrN8FxQDY5OehZLMjDMQb1x/kT4ZiZ9AH1Aiij2B1OnO1ITfqV0jiQXhCIFx1peAf0
         nI6+lEO6Rn61fpF7DdDnNx9CjkZn0c77UwlzCZ0JZXa2TJeLQ8YaTcAdw/4il1kX5A5C
         aCrP5MeKDn2HneqmwjvBvIg7yjePC6ALOve/U6HU9o312oVOuZZEkYxj06sgvONvZvHn
         XZXKHWdsKFOvvD/JamCs5E3TfPNlEaNwQD/DaHK9cqS9u12odNfZmBHsWlHLh5O98Hx7
         NOkAp6Mn8Kzad/8z8wa66gtvDiO429IeAvAqzH8+B0EoNEVk/us8vlW/fWJWT44fMVkK
         tM5A==
X-Forwarded-Encrypted: i=1; AJvYcCUO9RBbuAUbMSXJGlVURFmcfn9pNcd0iixSBVJ6ljbepjBMSkscYBlP+GVPOO9biiwj5Cg4WGCr++E=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy/wRQP0bYTCmCpwhYbO5Sk2ILp10STgplERDzDuLZmuYjH3WcO
	6DVUErsl35MHtmq/xPCiJkp5xYRTk8n9s8frcwXJcbEUA8Mvl8wEj1LC9Zx5X6Q=
X-Gm-Gg: ASbGncswfS65HHWdq1R/rCQBa3TUK6gCN+tG21wEMymcLEHITKnkz9pbj/Gha9IiN5r
	6keTrr0N6ZavVDVWx45OnqH5c8IBLhNRWr9c8/XkaHRBSO5I37Oe9R4SVKYrUwXCWUw5VEtQ/Lp
	toiKd39ja6uVahCkBPZynk1N42J2iPcFGOTF6C4DyY9p6StKIZ2kL+xkMWJ1Svqru76WhPveD/y
	Rm/tOAyFpjCI0i45DpK0Yy/nYqSKNYTStxktRb+LPGxiNAWHZoVBHvfVLKHj33T7Sdiz8KVoUb7
	j35U9H8rVoZTXfI+Az6B
X-Google-Smtp-Source: AGHT+IEKor1aYNm+uEgdu4KK/wowrIEfMRi85/Gmn2pCdQ01gV2E5gW1Ds+Ije2ACK9HFMMgZTgYew==
X-Received: by 2002:a05:6000:4b1c:b0:385:f4db:e33b with SMTP id ffacd0b85a97d-388e4d42923mr541812f8f.21.1734476671541;
        Tue, 17 Dec 2024 15:04:31 -0800 (PST)
Message-ID: <8e397404-9398-479b-8685-d2a680aced11@citrix.com>
Date: Tue, 17 Dec 2024 23:04:30 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH Hyperlaunch] xenconsole: Add connected flag
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
 Juergen Gross 
References: <20241217222424.7632-1-jason.andryuk@amd.com>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20241217222424.7632-1-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 17/12/2024 10:24 pm, Jason Andryuk wrote:
> This patch is similar to the xenstore late init (though the flag is
> reversed).

xenstore late init is fundamentally broken.  Do not copy it.

c/s fc2b57c9af462d67df871b080c0897156a616b7d broke the the ABI of that
bit by trying to repurpose it for an incompatible use.  Despite the
claims, it is not possible for a 3rd to be involved in any way in the
xenstore page.  This lead to some nasty state corruption issues in the
ring, which were simply papered over by repositioning the middle hunk,
and not fixed.

It causes cxenstored to have an incompatible ABI divergence of an
oxenstored feature.

The only reason I haven't reverted it is because it is my understanding
that Hyperlauch is going to need to revert it anyway.


The very first thing you need is a precise description of the semantics
of this bit, including how it is used by the client and the server.

I'll be dammed if I let a second spectacular breakage of a public
interface occur due to inadequate planning; one is bad enough.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 01:02:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 01:02:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859945.1272036 (Exim 4.92)
	(envelope-from )
	id 1tNiSO-0004PA-LW; Wed, 18 Dec 2024 01:02:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859945.1272036; Wed, 18 Dec 2024 01:02:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNiSO-0004P2-Gf; Wed, 18 Dec 2024 01:02:32 +0000
Received: by outflank-mailman (input) for mailman id 859945;
 Wed, 18 Dec 2024 01:02: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 1tNiSN-0004Ow-AL
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 01:02:31 +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 bf436489-bcdb-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 02:02:27 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1734483735898336.2131501847442;
 Tue, 17 Dec 2024 17:02: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: bf436489-bcdb-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1734483738; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=nzGZhSJyEtgi4a+pP6eCgEUjHIktoI7SS2rmdXhAKCn7RF8q0uNiVuA5nhkz/NKIuwLwt/YVHuLL2I8ui8hXWsM+RP/6tIMnSunfaF7kjsB6+s7Txax1hiZ5R3u0z9J1hxPfl5XLKii37h7MG7g30mJzEfn/VWwrSEGQmgClIjg=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1734483738; 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=al7Hvc5cQoUK6Q2+VqHu7nu8J1ScuhO7i/93I3DedLA=; 
	b=fPERXOofQkhuTqmraGjQq40Yi9ou5gF1XJiNfYnYDvygQ1nWutQ4bKSUzhHFopxhu1EY2QippdSM/q4j6Tv4h6MK6b59M3rN3kJnDpvHiF9OYdtcA5kjToK5SoYA5rMGwuqxqo254ZV6qovlJjQPwnf6GQD6zie/MojxfuJCSJs=
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=1734483738;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=al7Hvc5cQoUK6Q2+VqHu7nu8J1ScuhO7i/93I3DedLA=;
	b=bvqQJdTkqBItGVueS/ZIR5As1Rp4c+Bf+ZyXnJAv8/JN4wkNNV+Jh67eptYWN3TH
	TN/jQbHuD+oiYzSK3JzX84HcuRz4hLyvyob8JQX8+T+PeFYF/Mqci6nUlk+0HaPq+Wg
	E8qb72x/AiQo3ojrhLYMlf3FmOlEyiVweA465duI=
Message-ID: <94c494a2-863b-4597-a4df-c401fe7d5edf@apertussolutions.com>
Date: Tue, 17 Dec 2024 20:02:14 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 3/5] xen: add new domctl get_changed_domain
Content-Language: en-US
To: Juergen Gross , xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini 
References: <20241217111247.2204-1-jgross@suse.com>
 <20241217111247.2204-4-jgross@suse.com>
From: "Daniel P. Smith" 
Autocrypt: addr=dpsmith@apertussolutions.com; keydata=
 xsJuBFYrueARCACPWL3r2bCSI6TrkIE/aRzj4ksFYPzLkJbWLZGBRlv7HQLvs6i/K4y/b4fs
 JDq5eL4e9BdfdnZm/b+K+Gweyc0Px2poDWwKVTFFRgxKWq9R7McwNnvuZ4nyXJBVn7PTEn/Z
 G7D08iZg94ZsnUdeXfgYdJrqmdiWA6iX9u84ARHUtb0K4r5WpLUMcQ8PVmnv1vVrs/3Wy/Rb
 foxebZNWxgUiSx+d02e3Ad0aEIur1SYXXv71mqKwyi/40CBSHq2jk9eF6zmEhaoFi5+MMMgX
 X0i+fcBkvmT0N88W4yCtHhHQds+RDbTPLGm8NBVJb7R5zbJmuQX7ADBVuNYIU8hx3dF3AQCm
 601w0oZJ0jGOV1vXQgHqZYJGHg5wuImhzhZJCRESIwf+PJxik7TJOgBicko1hUVOxJBZxoe0
 x+/SO6tn+s8wKlR1Yxy8gYN9ZRqV2I83JsWZbBXMG1kLzV0SAfk/wq0PAppA1VzrQ3JqXg7T
 MZ3tFgxvxkYqUP11tO2vrgys+InkZAfjBVMjqXWHokyQPpihUaW0a8mr40w9Qui6DoJj7+Gg
 DtDWDZ7Zcn2hoyrypuht88rUuh1JuGYD434Q6qwQjUDlY+4lgrUxKdMD8R7JJWt38MNlTWvy
 rMVscvZUNc7gxcmnFUn41NPSKqzp4DDRbmf37Iz/fL7i01y7IGFTXaYaF3nEACyIUTr/xxi+
 MD1FVtEtJncZNkRn7WBcVFGKMAf+NEeaeQdGYQ6mGgk++i/vJZxkrC/a9ZXme7BhWRP485U5
 sXpFoGjdpMn4VlC7TFk2qsnJi3yF0pXCKVRy1ukEls8o+4PF2JiKrtkCrWCimB6jxGPIG3lk
 3SuKVS/din3RHz+7Sr1lXWFcGYDENmPd/jTwr1A1FiHrSj+u21hnJEHi8eTa9029F1KRfocp
 ig+k0zUEKmFPDabpanI323O5Tahsy7hwf2WOQwTDLvQ+eqQu40wbb6NocmCNFjtRhNZWGKJS
 b5GrGDGu/No5U6w73adighEuNcCSNBsLyUe48CE0uTO7eAL6Vd+2k28ezi6XY4Y0mgASJslb
 NwW54LzSSM0uRGFuaWVsIFAuIFNtaXRoIDxkcHNtaXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29t
 PsJ6BBMRCAAiBQJWK7ngAhsjBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBTc6WbYpR8
 KrQ9AP94+xjtFfJ8gj5c7PVx06Zv9rcmFUqQspZ5wSEkvxOuQQEAg6qEsPYegI7iByLVzNEg
 7B7fUG7pqWIfMqFwFghYhQzOwU0EViu54BAIAL6MXXNlrJ5tRUf+KMBtVz1LJQZRt/uxWrCb
 T06nZjnbp2UcceuYNbISOVHGXTzu38r55YzpkEA8eURQf+5hjtvlrOiHxvpD+Z6WcpV6rrMB
 kcAKWiZTQihW2HoGgVB3gwG9dCh+n0X5OzliAMiGK2a5iqnIZi3o0SeW6aME94bSkTkuj6/7
 OmH9KAzK8UnlhfkoMg3tXW8L6/5CGn2VyrjbB/rcrbIR4mCQ+yCUlocuOjFCJhBd10AG1IcX
 OXUa/ux+/OAV9S5mkr5Fh3kQxYCTcTRt8RY7+of9RGBk10txi94dXiU2SjPbassvagvu/hEi
 twNHms8rpkSJIeeq0/cAAwUH/jV3tXpaYubwcL2tkk5ggL9Do+/Yo2WPzXmbp8vDiJPCvSJW
 rz2NrYkd/RoX+42DGqjfu8Y04F9XehN1zZAFmCDUqBMa4tEJ7kOT1FKJTqzNVcgeKNBGcT7q
 27+wsqbAerM4A0X/F/ctjYcKwNtXck1Bmd/T8kiw2IgyeOC+cjyTOSwKJr2gCwZXGi5g+2V8
 NhJ8n72ISPnOh5KCMoAJXmCF+SYaJ6hIIFARmnuessCIGw4ylCRIU/TiXK94soilx5aCqb1z
 ke943EIUts9CmFAHt8cNPYOPRd20pPu4VFNBuT4fv9Ys0iv0XGCEP+sos7/pgJ3gV3pCOric
 p15jV4PCYQQYEQgACQUCViu54AIbDAAKCRBTc6WbYpR8Khu7AP9NJrBUn94C/3PeNbtQlEGZ
 NV46Mx5HF0P27lH3sFpNrwD/dVdZ5PCnHQYBZ287ZxVfVr4Zuxjo5yJbRjT93Hl0vMY=
In-Reply-To: <20241217111247.2204-4-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 12/17/24 06:12, Juergen Gross wrote:
> Add a new domctl sub-function to get data of a domain having changed
> state (this is needed by Xenstore).
> 
> The returned state just contains the domid, the domain unique id,
> and some flags (existing, shutdown, dying).
> 
> In order to enable Xenstore stubdom being built for multiple Xen
> versions, make this domctl stable.  For stable domctls the
> interface_version is always 0.
> 
> Signed-off-by: Juergen Gross 
> ---
> V1:
> - use a domctl subop for the new interface (Jan Beulich)
> V2:
> - fix XSM hooks (Daniel P. Smith)
> - remove versioning of stable sub-ops (Jan Beulich)
> - use domctl.domain for retuning domid of a changed domain (Jan Beulich)
> - simplify locking in get_domain_state() (Jan Beulich)
> - undo stray change in event_channel.c (Jan Beulich)
> V3:
> - have disjunct states "dying" and "dead" (Jan Beulich)
> - check padding fields to be 0 (Jan Beulich)
> - drop memset() (Jan Beulich)
> V4:
> - add locking in get_domain_state() (Jan Beulich)
> - only allow querying domain having changed state by domain receiving
>    VIRQ_DOM_EXC events (Jan Beulich)
> ---
>   tools/flask/policy/modules/dom0.te     |  2 +-
>   tools/flask/policy/modules/xen.if      |  4 +-
>   tools/flask/policy/modules/xenstore.te |  1 +
>   xen/common/domain.c                    | 70 ++++++++++++++++++++++++++
>   xen/common/domctl.c                    | 18 ++++++-
>   xen/common/event_channel.c             |  9 +++-
>   xen/include/public/domctl.h            | 26 ++++++++++
>   xen/include/xen/event.h                |  7 +++
>   xen/include/xen/sched.h                |  2 +
>   xen/include/xsm/dummy.h                |  8 +++
>   xen/include/xsm/xsm.h                  |  6 +++
>   xen/xsm/dummy.c                        |  1 +
>   xen/xsm/flask/hooks.c                  |  7 +++
>   xen/xsm/flask/policy/access_vectors    |  2 +
>   14 files changed, 158 insertions(+), 5 deletions(-)
> 


> diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
> index f8a3c4b81e..a1a5bb60e9 100644
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -173,6 +173,7 @@ static XSM_INLINE int cf_check xsm_domctl(
>       case XEN_DOMCTL_unbind_pt_irq:
>           return xsm_default_action(XSM_DM_PRIV, current->domain, d);
>       case XEN_DOMCTL_getdomaininfo:
> +    case XEN_DOMCTL_get_domain_state:
>           return xsm_default_action(XSM_XS_PRIV, current->domain, d);
>       default:
>           return xsm_default_action(XSM_PRIV, current->domain, d);
> @@ -815,6 +816,13 @@ static XSM_INLINE int cf_check xsm_argo_send(
>   
>   #endif /* CONFIG_ARGO */
>   
> +static XSM_INLINE int cf_check xsm_get_domain_state(
> +    XSM_DEFAULT_ARG struct domain *d)
> +{
> +    XSM_ASSERT_ACTION(XSM_XS_PRIV);
> +    return xsm_default_action(action, current->domain, d);
> +}
> +
>   #include 
>   static XSM_INLINE int cf_check xsm_xen_version(XSM_DEFAULT_ARG uint32_t op)
>   {
> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
> index 4dbff9d866..0689bf5c9f 100644
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -200,6 +200,7 @@ struct xsm_ops {
>       int (*argo_register_any_source)(const struct domain *d);
>       int (*argo_send)(const struct domain *d, const struct domain *t);
>   #endif
> +    int (*get_domain_state)(struct domain *d);
>   };
>   
>   #ifdef CONFIG_XSM
> @@ -774,6 +775,11 @@ static inline int xsm_argo_send(const struct domain *d, const struct domain *t)
>   
>   #endif /* CONFIG_ARGO */
>   
> +static inline int xsm_get_domain_state(struct domain *d)
> +{
> +    return alternative_call(xsm_ops.get_domain_state, d);
> +}
> +
>   #endif /* XSM_NO_WRAPPERS */
>   
>   #ifdef CONFIG_MULTIBOOT
> diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
> index e6ffa948f7..ce6fbdc6c5 100644
> --- a/xen/xsm/dummy.c
> +++ b/xen/xsm/dummy.c
> @@ -148,6 +148,7 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
>       .argo_register_any_source      = xsm_argo_register_any_source,
>       .argo_send                     = xsm_argo_send,
>   #endif
> +    .get_domain_state              = xsm_get_domain_state,
>   };
>   
>   void __init xsm_fixup_ops(struct xsm_ops *ops)
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index a79474ffe4..e110846ad9 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -688,6 +688,7 @@ static int cf_check flask_domctl(struct domain *d, unsigned int cmd,
>       case XEN_DOMCTL_memory_mapping:
>       case XEN_DOMCTL_set_target:
>       case XEN_DOMCTL_vm_event_op:
> +    case XEN_DOMCTL_get_domain_state:
>   
>       /* These have individual XSM hooks (arch/../domctl.c) */
>       case XEN_DOMCTL_bind_pt_irq:
> @@ -1856,6 +1857,11 @@ static int cf_check flask_argo_send(
>   
>   #endif
>   
> +static int cf_check flask_get_domain_state(struct domain *d)
> +{
> +    return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GET_DOMAIN_STATE);
> +}
> +
>   static const struct xsm_ops __initconst_cf_clobber flask_ops = {
>       .set_system_active = flask_set_system_active,
>       .security_domaininfo = flask_security_domaininfo,
> @@ -1992,6 +1998,7 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
>       .argo_register_any_source = flask_argo_register_any_source,
>       .argo_send = flask_argo_send,
>   #endif
> +    .get_domain_state = flask_get_domain_state,
>   };
>   
>   const struct xsm_ops *__init flask_init(
> diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
> index a35e3d4c51..c9a8eeda4e 100644
> --- a/xen/xsm/flask/policy/access_vectors
> +++ b/xen/xsm/flask/policy/access_vectors
> @@ -251,6 +251,8 @@ class domain2
>       resource_map
>   # XEN_DOMCTL_get_cpu_policy
>       get_cpu_policy
> +# XEN_DOMCTL_get_domain_state
> +    get_domain_state
>   }
>   
>   # Similar to class domain, but primarily contains domctls related to HVM domains

Acked-by: Daniel P. Smith 


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 01:18:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 01:18:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859956.1272046 (Exim 4.92)
	(envelope-from )
	id 1tNihb-0006C1-SO; Wed, 18 Dec 2024 01:18:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859956.1272046; Wed, 18 Dec 2024 01:18: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 1tNihb-0006Bu-Oa; Wed, 18 Dec 2024 01:18:15 +0000
Received: by outflank-mailman (input) for mailman id 859956;
 Wed, 18 Dec 2024 01:18: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 1tNiha-0006Bo-KR
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 01:18:14 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f2750665-bcdd-11ef-a0d6-8be0dac302b0;
 Wed, 18 Dec 2024 02:18:12 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1734484680941126.09502680922674;
 Tue, 17 Dec 2024 17:18: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: f2750665-bcdd-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1734484683; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=OlwyZYGa1mq/3VDfajyS++Yp+5w7Ipjalo4si8Inbh7jkt3zWj4i3AmVwEiF5WpyFAAKC9djCKnI3t+PbyksxLeYrcIou2yu4G1cg3wK2xi7aGEy5l6nQYt8FGHr618uNBMqIPFxoWztTSbzkrmAT49hR1wsfRHrx0oTgVG4TlQ=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1734484683; 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=RiIhbnhaflaM56sIlGro2lAxR4LzA574RtOKBMSOsyA=; 
	b=ESuNwwFYhvhE+dhNqgG0tji+ZIjQ9LmMeTIJU/mTlcDNI/Gax1hh1MYs00DU+2QoExVDSGseDsGjr+bYdbGf0hLYfaow8CMJfHxQhCtqEiHDciobOdv5wu9zEIJhVJc5LSb85v0al49h6HQLZZGlvr/xbIep/IQbNajeCwXfd7s=
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=1734484683;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=RiIhbnhaflaM56sIlGro2lAxR4LzA574RtOKBMSOsyA=;
	b=PIqqZrRf+rarrf8hZcRMQoEu0WJC9/tuoxtpNHPuux71sfuta+efZHJynHgjLl8b
	XQ6JQlTWpxWES+rW50pL/ov9FATBjg3MgwZaXaDJSfsoFc6JWIz8qc0i+NdeH+R9evM
	fQgCms1Pw1O5SVr1UKzxmJBo3EWrp5YG9HAETYIc=
Message-ID: <63b21760-7dea-423b-a9d8-64d213c40b2c@apertussolutions.com>
Date: Tue, 17 Dec 2024 20:17:59 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
Content-Language: en-US
To: Julien Grall , Sergiy Kibrik ,
 xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini 
References: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
 <4e437c60-4fee-40ed-9d2a-789bac0b36d9@xen.org>
From: "Daniel P. Smith" 
Autocrypt: addr=dpsmith@apertussolutions.com; keydata=
 xsJuBFYrueARCACPWL3r2bCSI6TrkIE/aRzj4ksFYPzLkJbWLZGBRlv7HQLvs6i/K4y/b4fs
 JDq5eL4e9BdfdnZm/b+K+Gweyc0Px2poDWwKVTFFRgxKWq9R7McwNnvuZ4nyXJBVn7PTEn/Z
 G7D08iZg94ZsnUdeXfgYdJrqmdiWA6iX9u84ARHUtb0K4r5WpLUMcQ8PVmnv1vVrs/3Wy/Rb
 foxebZNWxgUiSx+d02e3Ad0aEIur1SYXXv71mqKwyi/40CBSHq2jk9eF6zmEhaoFi5+MMMgX
 X0i+fcBkvmT0N88W4yCtHhHQds+RDbTPLGm8NBVJb7R5zbJmuQX7ADBVuNYIU8hx3dF3AQCm
 601w0oZJ0jGOV1vXQgHqZYJGHg5wuImhzhZJCRESIwf+PJxik7TJOgBicko1hUVOxJBZxoe0
 x+/SO6tn+s8wKlR1Yxy8gYN9ZRqV2I83JsWZbBXMG1kLzV0SAfk/wq0PAppA1VzrQ3JqXg7T
 MZ3tFgxvxkYqUP11tO2vrgys+InkZAfjBVMjqXWHokyQPpihUaW0a8mr40w9Qui6DoJj7+Gg
 DtDWDZ7Zcn2hoyrypuht88rUuh1JuGYD434Q6qwQjUDlY+4lgrUxKdMD8R7JJWt38MNlTWvy
 rMVscvZUNc7gxcmnFUn41NPSKqzp4DDRbmf37Iz/fL7i01y7IGFTXaYaF3nEACyIUTr/xxi+
 MD1FVtEtJncZNkRn7WBcVFGKMAf+NEeaeQdGYQ6mGgk++i/vJZxkrC/a9ZXme7BhWRP485U5
 sXpFoGjdpMn4VlC7TFk2qsnJi3yF0pXCKVRy1ukEls8o+4PF2JiKrtkCrWCimB6jxGPIG3lk
 3SuKVS/din3RHz+7Sr1lXWFcGYDENmPd/jTwr1A1FiHrSj+u21hnJEHi8eTa9029F1KRfocp
 ig+k0zUEKmFPDabpanI323O5Tahsy7hwf2WOQwTDLvQ+eqQu40wbb6NocmCNFjtRhNZWGKJS
 b5GrGDGu/No5U6w73adighEuNcCSNBsLyUe48CE0uTO7eAL6Vd+2k28ezi6XY4Y0mgASJslb
 NwW54LzSSM0uRGFuaWVsIFAuIFNtaXRoIDxkcHNtaXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29t
 PsJ6BBMRCAAiBQJWK7ngAhsjBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBTc6WbYpR8
 KrQ9AP94+xjtFfJ8gj5c7PVx06Zv9rcmFUqQspZ5wSEkvxOuQQEAg6qEsPYegI7iByLVzNEg
 7B7fUG7pqWIfMqFwFghYhQzOwU0EViu54BAIAL6MXXNlrJ5tRUf+KMBtVz1LJQZRt/uxWrCb
 T06nZjnbp2UcceuYNbISOVHGXTzu38r55YzpkEA8eURQf+5hjtvlrOiHxvpD+Z6WcpV6rrMB
 kcAKWiZTQihW2HoGgVB3gwG9dCh+n0X5OzliAMiGK2a5iqnIZi3o0SeW6aME94bSkTkuj6/7
 OmH9KAzK8UnlhfkoMg3tXW8L6/5CGn2VyrjbB/rcrbIR4mCQ+yCUlocuOjFCJhBd10AG1IcX
 OXUa/ux+/OAV9S5mkr5Fh3kQxYCTcTRt8RY7+of9RGBk10txi94dXiU2SjPbassvagvu/hEi
 twNHms8rpkSJIeeq0/cAAwUH/jV3tXpaYubwcL2tkk5ggL9Do+/Yo2WPzXmbp8vDiJPCvSJW
 rz2NrYkd/RoX+42DGqjfu8Y04F9XehN1zZAFmCDUqBMa4tEJ7kOT1FKJTqzNVcgeKNBGcT7q
 27+wsqbAerM4A0X/F/ctjYcKwNtXck1Bmd/T8kiw2IgyeOC+cjyTOSwKJr2gCwZXGi5g+2V8
 NhJ8n72ISPnOh5KCMoAJXmCF+SYaJ6hIIFARmnuessCIGw4ylCRIU/TiXK94soilx5aCqb1z
 ke943EIUts9CmFAHt8cNPYOPRd20pPu4VFNBuT4fv9Ys0iv0XGCEP+sos7/pgJ3gV3pCOric
 p15jV4PCYQQYEQgACQUCViu54AIbDAAKCRBTc6WbYpR8Khu7AP9NJrBUn94C/3PeNbtQlEGZ
 NV46Mx5HF0P27lH3sFpNrwD/dVdZ5PCnHQYBZ287ZxVfVr4Zuxjo5yJbRjT93Hl0vMY=
In-Reply-To: <4e437c60-4fee-40ed-9d2a-789bac0b36d9@xen.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

> On 17/12/2024 11:47, Sergiy Kibrik wrote:
>> Allow to build ARM configuration with support for initializing 
>> hardware domain.
>> On ARM it is only possible to start hardware domain in multiboot mode, so
>> dom0less support is required. This is reflected by dependency on 
>> DOM0LESS_BOOT
>> instead of directly depending on ARM config option.


Just to make sure my assumption is correct, you are looking to do a 
multi-domain construction at boot time, with at least two domains. One 
of those two domains is the "control domain" and one is the "hardware 
domain", aka late hwdom except it's not constructed "late".

If you want such a configuration, I would highly recommend you first 
enable setting flask labels via dom0less (assuming it is not there) 
before lighting this feature up. This is because the dummy/base policy 
has no support for differentiating between a "control domain" and a 
"hardware domain". What you really would end up with is two control 
domains, with one also having control over hardware.

v/r
dps


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 01:22:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 01:22:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859964.1272055 (Exim 4.92)
	(envelope-from )
	id 1tNilY-0007q2-Am; Wed, 18 Dec 2024 01:22:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859964.1272055; Wed, 18 Dec 2024 01: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 1tNilY-0007pu-89; Wed, 18 Dec 2024 01:22:20 +0000
Received: by outflank-mailman (input) for mailman id 859964;
 Wed, 18 Dec 2024 01:22: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 1tNilX-0007pn-06
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 01:22:19 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4e4b8d83-bcde-11ef-a0d6-8be0dac302b0;
 Wed, 18 Dec 2024 02:20:46 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1734484837587283.6589668641702;
 Tue, 17 Dec 2024 17:20: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: 4e4b8d83-bcde-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1734484839; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=gQUpWBrVc49H7PA0k6QxNjyNgzvy8+/x7lW5fliScBqWdkM/O3cGrj0RX5ezYWvJQ/SedKHQb/hIE6xEIMhWxZy6FjT21P5W4+tK0HYWzetlQlXXzqAwohNCb61boK3d27cwljP3hEZYZOUL8+9PvRWIEdkW6hXbteYinOEIHjM=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1734484839; 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=EM028ERgfmkIBJDimHiTLJSPlsk9iruciOdPPAzPn+4=; 
	b=HoyhFyNXSpQbfOX3kIsdc4csNvrLFxZlW5nZ0rgqWm0ItdFKgrtGw90tMLWyjx+pdD6BV//RNiZHkIfsWV3+HT8D1lmwK05kZewynWS5JWowzEWMWvQ5oxIe58OKuHPvi3XV4aVUEDyw+zEH4Rd6J9HR0njwv+Cx631qex1gIhY=
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=1734484839;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=EM028ERgfmkIBJDimHiTLJSPlsk9iruciOdPPAzPn+4=;
	b=rENnieHPNk4CBmEVoc5KMo6nwfNTKEYFoT9BL633ViV8C13nhIpkeaBV00Mmiw2Z
	QzRuxxLN5GmJvnsia7Cbe9pKq1Dsg7/oAQNL/YrWHttA+ytgN+JzVzg5aq0wiuwBHVQ
	1GtHrVykbYReGHrScW9ZEJN1oYbrLrdad/yy8Oeo=
Message-ID: 
Date: Tue, 17 Dec 2024 20:20:35 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 3/5] xen: add new domctl get_changed_domain
Content-Language: en-US
To: Juergen Gross , xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
 Andrew Cooper ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini 
References: <20241217142218.24129-1-jgross@suse.com>
 <20241217142218.24129-4-jgross@suse.com>
From: "Daniel P. Smith" 
Autocrypt: addr=dpsmith@apertussolutions.com; keydata=
 xsJuBFYrueARCACPWL3r2bCSI6TrkIE/aRzj4ksFYPzLkJbWLZGBRlv7HQLvs6i/K4y/b4fs
 JDq5eL4e9BdfdnZm/b+K+Gweyc0Px2poDWwKVTFFRgxKWq9R7McwNnvuZ4nyXJBVn7PTEn/Z
 G7D08iZg94ZsnUdeXfgYdJrqmdiWA6iX9u84ARHUtb0K4r5WpLUMcQ8PVmnv1vVrs/3Wy/Rb
 foxebZNWxgUiSx+d02e3Ad0aEIur1SYXXv71mqKwyi/40CBSHq2jk9eF6zmEhaoFi5+MMMgX
 X0i+fcBkvmT0N88W4yCtHhHQds+RDbTPLGm8NBVJb7R5zbJmuQX7ADBVuNYIU8hx3dF3AQCm
 601w0oZJ0jGOV1vXQgHqZYJGHg5wuImhzhZJCRESIwf+PJxik7TJOgBicko1hUVOxJBZxoe0
 x+/SO6tn+s8wKlR1Yxy8gYN9ZRqV2I83JsWZbBXMG1kLzV0SAfk/wq0PAppA1VzrQ3JqXg7T
 MZ3tFgxvxkYqUP11tO2vrgys+InkZAfjBVMjqXWHokyQPpihUaW0a8mr40w9Qui6DoJj7+Gg
 DtDWDZ7Zcn2hoyrypuht88rUuh1JuGYD434Q6qwQjUDlY+4lgrUxKdMD8R7JJWt38MNlTWvy
 rMVscvZUNc7gxcmnFUn41NPSKqzp4DDRbmf37Iz/fL7i01y7IGFTXaYaF3nEACyIUTr/xxi+
 MD1FVtEtJncZNkRn7WBcVFGKMAf+NEeaeQdGYQ6mGgk++i/vJZxkrC/a9ZXme7BhWRP485U5
 sXpFoGjdpMn4VlC7TFk2qsnJi3yF0pXCKVRy1ukEls8o+4PF2JiKrtkCrWCimB6jxGPIG3lk
 3SuKVS/din3RHz+7Sr1lXWFcGYDENmPd/jTwr1A1FiHrSj+u21hnJEHi8eTa9029F1KRfocp
 ig+k0zUEKmFPDabpanI323O5Tahsy7hwf2WOQwTDLvQ+eqQu40wbb6NocmCNFjtRhNZWGKJS
 b5GrGDGu/No5U6w73adighEuNcCSNBsLyUe48CE0uTO7eAL6Vd+2k28ezi6XY4Y0mgASJslb
 NwW54LzSSM0uRGFuaWVsIFAuIFNtaXRoIDxkcHNtaXRoQGFwZXJ0dXNzb2x1dGlvbnMuY29t
 PsJ6BBMRCAAiBQJWK7ngAhsjBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBTc6WbYpR8
 KrQ9AP94+xjtFfJ8gj5c7PVx06Zv9rcmFUqQspZ5wSEkvxOuQQEAg6qEsPYegI7iByLVzNEg
 7B7fUG7pqWIfMqFwFghYhQzOwU0EViu54BAIAL6MXXNlrJ5tRUf+KMBtVz1LJQZRt/uxWrCb
 T06nZjnbp2UcceuYNbISOVHGXTzu38r55YzpkEA8eURQf+5hjtvlrOiHxvpD+Z6WcpV6rrMB
 kcAKWiZTQihW2HoGgVB3gwG9dCh+n0X5OzliAMiGK2a5iqnIZi3o0SeW6aME94bSkTkuj6/7
 OmH9KAzK8UnlhfkoMg3tXW8L6/5CGn2VyrjbB/rcrbIR4mCQ+yCUlocuOjFCJhBd10AG1IcX
 OXUa/ux+/OAV9S5mkr5Fh3kQxYCTcTRt8RY7+of9RGBk10txi94dXiU2SjPbassvagvu/hEi
 twNHms8rpkSJIeeq0/cAAwUH/jV3tXpaYubwcL2tkk5ggL9Do+/Yo2WPzXmbp8vDiJPCvSJW
 rz2NrYkd/RoX+42DGqjfu8Y04F9XehN1zZAFmCDUqBMa4tEJ7kOT1FKJTqzNVcgeKNBGcT7q
 27+wsqbAerM4A0X/F/ctjYcKwNtXck1Bmd/T8kiw2IgyeOC+cjyTOSwKJr2gCwZXGi5g+2V8
 NhJ8n72ISPnOh5KCMoAJXmCF+SYaJ6hIIFARmnuessCIGw4ylCRIU/TiXK94soilx5aCqb1z
 ke943EIUts9CmFAHt8cNPYOPRd20pPu4VFNBuT4fv9Ys0iv0XGCEP+sos7/pgJ3gV3pCOric
 p15jV4PCYQQYEQgACQUCViu54AIbDAAKCRBTc6WbYpR8Khu7AP9NJrBUn94C/3PeNbtQlEGZ
 NV46Mx5HF0P27lH3sFpNrwD/dVdZ5PCnHQYBZ287ZxVfVr4Zuxjo5yJbRjT93Hl0vMY=
In-Reply-To: <20241217142218.24129-4-jgross@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 12/17/24 09:22, Juergen Gross wrote:
> Add a new domctl sub-function to get data of a domain having changed
> state (this is needed by Xenstore).
> 
> The returned state just contains the domid, the domain unique id,
> and some flags (existing, shutdown, dying).
> 
> In order to enable Xenstore stubdom being built for multiple Xen
> versions, make this domctl stable.  For stable domctls the
> interface_version is always 0.
> 
> Signed-off-by: Juergen Gross 
> ---
> V1:
> - use a domctl subop for the new interface (Jan Beulich)
> V2:
> - fix XSM hooks (Daniel P. Smith)
> - remove versioning of stable sub-ops (Jan Beulich)
> - use domctl.domain for retuning domid of a changed domain (Jan Beulich)
> - simplify locking in get_domain_state() (Jan Beulich)
> - undo stray change in event_channel.c (Jan Beulich)
> V3:
> - have disjunct states "dying" and "dead" (Jan Beulich)
> - check padding fields to be 0 (Jan Beulich)
> - drop memset() (Jan Beulich)
> V4:
> - add locking in get_domain_state() (Jan Beulich)
> - only allow querying domain having changed state by domain receiving
>    VIRQ_DOM_EXC events (Jan Beulich)
> V5:
> - use memset() (Jan Beulich)
> ---
>   tools/flask/policy/modules/dom0.te     |  2 +-
>   tools/flask/policy/modules/xen.if      |  4 +-
>   tools/flask/policy/modules/xenstore.te |  1 +
>   xen/common/domain.c                    | 67 ++++++++++++++++++++++++++
>   xen/common/domctl.c                    | 18 ++++++-
>   xen/common/event_channel.c             |  9 +++-
>   xen/include/public/domctl.h            | 26 ++++++++++
>   xen/include/xen/event.h                |  7 +++
>   xen/include/xen/sched.h                |  2 +
>   xen/include/xsm/dummy.h                |  8 +++
>   xen/include/xsm/xsm.h                  |  6 +++
>   xen/xsm/dummy.c                        |  1 +
>   xen/xsm/flask/hooks.c                  |  7 +++
>   xen/xsm/flask/policy/access_vectors    |  2 +
>   14 files changed, 155 insertions(+), 5 deletions(-)
> 


> diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
> index f8a3c4b81e..a1a5bb60e9 100644
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -173,6 +173,7 @@ static XSM_INLINE int cf_check xsm_domctl(
>       case XEN_DOMCTL_unbind_pt_irq:
>           return xsm_default_action(XSM_DM_PRIV, current->domain, d);
>       case XEN_DOMCTL_getdomaininfo:
> +    case XEN_DOMCTL_get_domain_state:
>           return xsm_default_action(XSM_XS_PRIV, current->domain, d);
>       default:
>           return xsm_default_action(XSM_PRIV, current->domain, d);
> @@ -815,6 +816,13 @@ static XSM_INLINE int cf_check xsm_argo_send(
>   
>   #endif /* CONFIG_ARGO */
>   
> +static XSM_INLINE int cf_check xsm_get_domain_state(
> +    XSM_DEFAULT_ARG struct domain *d)
> +{
> +    XSM_ASSERT_ACTION(XSM_XS_PRIV);
> +    return xsm_default_action(action, current->domain, d);
> +}
> +
>   #include 
>   static XSM_INLINE int cf_check xsm_xen_version(XSM_DEFAULT_ARG uint32_t op)
>   {
> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
> index 4dbff9d866..0689bf5c9f 100644
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -200,6 +200,7 @@ struct xsm_ops {
>       int (*argo_register_any_source)(const struct domain *d);
>       int (*argo_send)(const struct domain *d, const struct domain *t);
>   #endif
> +    int (*get_domain_state)(struct domain *d);
>   };
>   
>   #ifdef CONFIG_XSM
> @@ -774,6 +775,11 @@ static inline int xsm_argo_send(const struct domain *d, const struct domain *t)
>   
>   #endif /* CONFIG_ARGO */
>   
> +static inline int xsm_get_domain_state(struct domain *d)
> +{
> +    return alternative_call(xsm_ops.get_domain_state, d);
> +}
> +
>   #endif /* XSM_NO_WRAPPERS */
>   
>   #ifdef CONFIG_MULTIBOOT
> diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
> index e6ffa948f7..ce6fbdc6c5 100644
> --- a/xen/xsm/dummy.c
> +++ b/xen/xsm/dummy.c
> @@ -148,6 +148,7 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = {
>       .argo_register_any_source      = xsm_argo_register_any_source,
>       .argo_send                     = xsm_argo_send,
>   #endif
> +    .get_domain_state              = xsm_get_domain_state,
>   };
>   
>   void __init xsm_fixup_ops(struct xsm_ops *ops)
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index a79474ffe4..e110846ad9 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -688,6 +688,7 @@ static int cf_check flask_domctl(struct domain *d, unsigned int cmd,
>       case XEN_DOMCTL_memory_mapping:
>       case XEN_DOMCTL_set_target:
>       case XEN_DOMCTL_vm_event_op:
> +    case XEN_DOMCTL_get_domain_state:
>   
>       /* These have individual XSM hooks (arch/../domctl.c) */
>       case XEN_DOMCTL_bind_pt_irq:
> @@ -1856,6 +1857,11 @@ static int cf_check flask_argo_send(
>   
>   #endif
>   
> +static int cf_check flask_get_domain_state(struct domain *d)
> +{
> +    return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GET_DOMAIN_STATE);
> +}
> +
>   static const struct xsm_ops __initconst_cf_clobber flask_ops = {
>       .set_system_active = flask_set_system_active,
>       .security_domaininfo = flask_security_domaininfo,
> @@ -1992,6 +1998,7 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = {
>       .argo_register_any_source = flask_argo_register_any_source,
>       .argo_send = flask_argo_send,
>   #endif
> +    .get_domain_state = flask_get_domain_state,
>   };
>   
>   const struct xsm_ops *__init flask_init(
> diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
> index a35e3d4c51..c9a8eeda4e 100644
> --- a/xen/xsm/flask/policy/access_vectors
> +++ b/xen/xsm/flask/policy/access_vectors
> @@ -251,6 +251,8 @@ class domain2
>       resource_map
>   # XEN_DOMCTL_get_cpu_policy
>       get_cpu_policy
> +# XEN_DOMCTL_get_domain_state
> +    get_domain_state
>   }
>   
>   # Similar to class domain, but primarily contains domctls related to HVM domains

Apologies, I missed v5 when responding to v4 a moment ago. For good measure,

Acked-by: Daniel P. Smith 


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 07:16:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 07:16:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.859990.1272070 (Exim 4.92)
	(envelope-from )
	id 1tNoHS-0005YR-L6; Wed, 18 Dec 2024 07:15:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 859990.1272070; Wed, 18 Dec 2024 07:15: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 1tNoHS-0005YK-Hj; Wed, 18 Dec 2024 07:15:38 +0000
Received: by outflank-mailman (input) for mailman id 859990;
 Wed, 18 Dec 2024 07:15: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 1tNoHQ-0005YE-87
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 07:15:36 +0000
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [2a00:1450:4864:20::535])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id df440a2e-bd0f-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 08:15:34 +0100 (CET)
Received: by mail-ed1-x535.google.com with SMTP id
 4fb4d7f45d1cf-5d3d0205bd5so8701081a12.3
 for ; Tue, 17 Dec 2024 23:15:34 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab9638ecb7sm520980266b.155.2024.12.17.23.15.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 17 Dec 2024 23:15: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: df440a2e-bd0f-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734506133; x=1735110933; 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=SVwo/povEVBa7tvWJ84JOJO0aX6nITiFYWRQz/p5XW0=;
        b=QC4GkxpGlfzsQrOvAJsoZLTbLtOQn3jdCtnv3s7VwzNNuPF1bdXH3o3bWHLgtq12/W
         cQdCF/pym3eQ9MiefYTbBcEBmHZ+CBDKnuT09/MteMu5AMsDzaEKpJM5Uk4GjUaM7GZw
         LeE/D4R9ez0A0HSKTNAXsVNUYDCDF8wGC2HtXH5l3awC+V0ylw8UNYwCtnIjfJFfTfEL
         SyubmTMmeNn1dVVAybbe1f/H9GoiNyvVJz6swyybmm5Q7D2NT+RDP7rZwRkL5BQt8Vr5
         lYU2x2tR7QfwLxGgliOQV2z101Dv2A6w9VjEE9X1boHwleiK3D9HHPmD5T+mEdRz88kv
         3Rhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734506133; x=1735110933;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=SVwo/povEVBa7tvWJ84JOJO0aX6nITiFYWRQz/p5XW0=;
        b=X/aDqKeG9WgoK/HwkWacAoTcmRuugt04psvr1dOYTIRxYFow0kymTuu05oWko3w0ft
         hFqEE3EYhvc2tmVxCh8FOk/iW7/8r96E6lzV7ZbbyGvfDR72FuI80zojQh2pDgsLtdJY
         x8mRaEBY3Ox27Rx4ZhFNSNdkLHnj62TRvIZmuAr4oZZ9S1AzCN3lokLT+vt7RlrAyW4Q
         XEbXofdnS9JmS+Xb1q1lJkeUQwffGM7U82KXBTJsmjv8p0enNoj2zH64Chkq2vqUTUT4
         cKY40xvuRQ5jd0zxjHxa1LZ16/JP0/H6sW86r1art21B/4lJk5XYLAT7fRzHXF8nPZlu
         lrSA==
X-Forwarded-Encrypted: i=1; AJvYcCVJbvIaKHgkbkqXj61aj+3S4kzPpsvpXMFr+V/6V6BpcKvEaML7vBfmZqT2Cz+x9PPfrCeu8FBPMvE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyPGc9ef6lNCCMHKMn4KJkM23sncOHsZvHOjSaarJtWSq8jBjSV
	FOjT5XIdSWqPC35rk3Da7X0RtHZQi61B66WIUvfFqKSVmQnrO43sx8LtDk9gqco=
X-Gm-Gg: ASbGncvaSSaHtTLpFGWssORIt5wy3+hMkqtspRW0wTlfg0Tp7yu3d3FxQnzs66d7J+9
	HbNY0EFyae4afbQ6Ywn1NaeNelkBcqYT0crh4WhzQf0rup+xyW+aIWbwiFxSMi61XVZowKGtz56
	YxKUy+V/R+YzI+BOc3DrBNwdkcKCv1WJhQrDoET1PFjDxZWIoo9nopvuF3zw/BFOkAn/vZYw1cM
	aP22Y/V6DG6daysQLvq2utlBH8cY656rZZMqZjSSx+bn+k469KIOUyZNsH4r4l0S93oNVC/z73q
	vNYOlRc69Ipdx+eu6vtumFuCkK2zKWJh2QSH9aOhQhMW0unOwdhsJ4eR3oJIdKHR6AnyqIzAI8r
	KJLHRDA==
X-Google-Smtp-Source: AGHT+IEKLJjN3NYI9lbeSzuEvGZkWxGWL6BH/6FWVN7yJ1agSMnv0cqk4OctJIac/PDUQSOUwUYorw==
X-Received: by 2002:a17:907:3e1d:b0:aa6:8a1b:8b78 with SMTP id a640c23a62f3a-aabf471ff8dmr125407266b.6.1734506133372;
        Tue, 17 Dec 2024 23:15:33 -0800 (PST)
Message-ID: <2fa06b11-e7a0-4f57-9af0-af432d35820a@suse.com>
Date: Wed, 18 Dec 2024 08:15:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 2/5] xen: add bitmap to indicate per-domain state
 changes
To: Jan Beulich 
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: <20241217142218.24129-1-jgross@suse.com>
 <20241217142218.24129-3-jgross@suse.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: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------wy0qqVeRzNRn21eZh8BJP3Wg"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------wy0qqVeRzNRn21eZh8BJP3Wg
Content-Type: multipart/mixed; boundary="------------6EWgdWQk5ExBp58YTfCEh0Wb";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Jan Beulich 
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
Message-ID: <2fa06b11-e7a0-4f57-9af0-af432d35820a@suse.com>
Subject: Re: [PATCH v5 2/5] xen: add bitmap to indicate per-domain state
 changes
References: <20241217142218.24129-1-jgross@suse.com>
 <20241217142218.24129-3-jgross@suse.com>
 
 
 
In-Reply-To: 
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------6EWgdWQk5ExBp58YTfCEh0Wb
Content-Type: multipart/mixed; boundary="------------1OkYYJKIGx2nQcY88XbA7a7W"

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

T24gMTcuMTIuMjQgMTc6MTIsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxNy4xMi4yMDI0
IDE2OjU1LCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPj4gT24gMTcuMTIuMjQgMTY6MTksIEph
biBCZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDE3LjEyLjIwMjQgMTU6MjIsIEp1ZXJnZW4gR3Jv
c3Mgd3JvdGU6DQo+Pj4+IEFkZCBhIGJpdG1hcCB3aXRoIG9uZSBiaXQgcGVyIHBvc3NpYmxl
IGRvbWlkIGluZGljYXRpbmcgdGhlIHJlc3BlY3RpdmUNCj4+Pj4gZG9tYWluIGhhcyBjaGFu
Z2VkIGl0cyBzdGF0ZSAoY3JlYXRlZCwgZGVsZXRlZCwgZHlpbmcsIGNyYXNoZWQsDQo+Pj4+
IHNodXRkb3duKS4NCj4+Pj4NCj4+Pj4gUmVnaXN0ZXJpbmcgdGhlIFZJUlFfRE9NX0VYQyBl
dmVudCB3aWxsIHJlc3VsdCBpbiBzZXR0aW5nIHRoZSBiaXRzIGZvcg0KPj4+PiBhbGwgZXhp
c3RpbmcgZG9tYWlucyBhbmQgcmVzZXR0aW5nIGFsbCBvdGhlciBiaXRzLg0KPj4+Pg0KPj4+
PiBBcyB0aGUgdXNhZ2Ugb2YgdGhpcyBiaXRtYXAgaXMgdGlnaHRseSBjb3VwbGVkIHdpdGgg
dGhlIFZJUlFfRE9NX0VYQw0KPj4+PiBldmVudCwgaXQgaXMgbWVhbnQgdG8gYmUgdXNlZCBv
bmx5IGJ5IGEgc2luZ2xlIGNvbnN1bWVyIGluIHRoZSBzeXN0ZW0sDQo+Pj4+IGp1c3QgbGlr
ZSB0aGUgVklSUV9ET01fRVhDIGV2ZW50Lg0KPj4+DQo+Pj4gSSdtIHNvcnJ5LCBidXQgSSBu
ZWVkIHRvIGNvbWUgYmFjayB0byB0aGlzLiBJIHRob3VnaHQgSSBoYWQgZ290IGNvbnZpbmNl
ZA0KPj4+IHRoYXQgb25seSBhIHNpbmdsZSBlbnRpdHkgaW4gdGhlIHN5c3RlbSBjYW4gYmlu
ZCB0aGlzIHZJUlEuIFlldCB1cG9uDQo+Pj4gY2hlY2tpbmcgSSBjYW4ndCBzZWVtIHRvIGZp
bmQgd2hhdCB3b3VsZCBndWFyYW50ZWUgdGhpcy4gSW4gcGFydGljdWxhcg0KPj4+IGJpbmRp
bmcgYSB2SVJRIGRvZXNuJ3QgaW52b2x2ZSBhbnkgWFNNIGNoZWNrLiBIZW5jZSBhbiB1bnBy
aXZpbGVnZWQgZW50aXR5DQo+Pj4gY291bGQsIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhl
IGludGVyZXN0ZWQgcHJpdmlsZWdlZCBlbnRpdHkgKHhlbnN0b3JlKQ0KPj4+IGlzIGFscmVh
ZHkgdXAgYW5kIHJ1bm5pbmcsIGJpbmQgYW5kIHVuYmluZCB0aGlzIHZJUlEsIGp1c3QgdG8g
aGF2ZSB0aGUNCj4+PiBnbG9iYWwgbWFwIGZyZWVkLiBXaGF0IGFtIEkgb3Zlcmxvb2tpbmcg
KHdoaWNoIHdvdWxkIGxpa2VseSB3YW50IHN0YXRpbmcNCj4+PiBoZXJlKT8NCj4+DQo+PiBJ
IHRoaW5rIHlvdSBhcmUgbm90IG92ZXJsb29raW5nIGFueXRoaW5nLg0KPj4NCj4+IEkgZ3Vl
c3MgdGhpcyBjYW4gZWFzaWx5IGJlIGhhbmRsZWQgYnkgY2hlY2tpbmcgdGhhdCB0aGUgVklS
UV9ET01fRVhDIGhhbmRsaW5nDQo+PiBkb21haW4gaXMgdGhlIGNhbGxpbmcgb25lIGluIGRv
bWFpbl9bZGVdaW5pdF9zdGF0ZXMoKS4gTm90ZSB0aGF0IGdsb2JhbCB2aXJxcw0KPj4gYXJl
IG9ubHkgZXZlciBzZW50IHRvIHZjcHVbMF0gb2YgdGhlIGhhbmRsaW5nIGRvbWFpbiwgc28g
cmViaW5kaW5nIHRoZSBldmVudA0KPj4gdG8gYW5vdGhlciB2Y3B1IGlzIHBvc3NpYmxlLCBi
dXQgZG9lc24ndCBtYWtlIHNlbnNlLg0KPiANCj4gTm8sIHRoYXQncyBwcmVjbHVkZWQgYnkN
Cj4gDQo+ICAgICAgaWYgKCB2aXJxX2lzX2dsb2JhbCh2aXJxKSAmJiAodmNwdSAhPSAwKSAp
DQo+ICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPiANCj4gYWZhaWN0LiBUaGF0IGRvZXNu
J3QsIGhvd2V2ZXIsIHByZWNsdWRlIG11bHRpcGxlIHZDUFUtcyBmcm9tIHRyeWluZyB0byBi
aW5kDQo+IHRoZSB2SVJRIHRvIHZDUFUgMC4NCg0KSSBsZXQgbXlzZWxmIGZvb2wgYnkgdGhl
IGFiaWxpdHkgdG8gdXNlIEVWVENITk9QX2JpbmRfdmNwdSBmb3IgYSBnbG9iYWwNCnZpcnEu
IFdoaWxlIGl0IGlzIHBvc3NpYmxlIHRvIHNlbmQgdGhlIGV2ZW50IHRvIGFub3RoZXIgdmNw
dSwgaXQgaXMgc3RpbGwNCnZjcHVbMF0gd2hpY2ggaXMgdXNlZCBmb3IgdGhlIGJvb2trZWVw
aW5nLg0KDQo+IA0KPj4+PiBWNToNCj4+Pj4gLSBkb21haW5faW5pdF9zdGF0ZXMoKSBtYXkg
YmUgY2FsbGVkIG9ubHkgaWYgZXZ0Y2huX2JpbmRfdmlycSgpIGhhcyBiZWVuDQo+Pj4+ICAg
ICBjYWxsZWQgdmFsaWRseSAoSmFuIEJldWxpY2gpDQo+Pj4NCj4+PiBJIG5vdyByZWNhbGwg
d2h5IEkgaGFkIGZpcnN0IHN1Z2dlc3RlZCB0aGUgcGxhY2VtZW50IGxhdGVyIGluIHRoZSBo
YW5kbGluZzoNCj4+PiBZb3UncmUgbm93IGRvaW5nIHRoZSBhbGxvY2F0aW9uIHdpdGggeWV0
IGFub3RoZXIgbG9jayBoZWxkLiBJdCdzIGxpa2VseSBub3QNCj4+PiB0aGUgZW5kIG9mIHRo
ZSB3b3JsZCwgYnV0IC4uLg0KPj4+DQo+Pj4+IEBAIC0xMzgsNiArMTM5LDYwIEBAIGJvb2wg
X19yZWFkX21vc3RseSB2bXRyYWNlX2F2YWlsYWJsZTsNCj4+Pj4gICAgDQo+Pj4+ICAgIGJv
b2wgX19yZWFkX21vc3RseSB2cG11X2lzX2F2YWlsYWJsZTsNCj4+Pj4gICAgDQo+Pj4+ICtz
dGF0aWMgREVGSU5FX1NQSU5MT0NLKGRvbV9zdGF0ZV9jaGFuZ2VkX2xvY2spOw0KPj4+PiAr
c3RhdGljIHVuc2lnbmVkIGxvbmcgKl9fcmVhZF9tb3N0bHkgZG9tX3N0YXRlX2NoYW5nZWQ7
DQo+Pj4+ICsNCj4+Pj4gK2ludCBkb21haW5faW5pdF9zdGF0ZXModm9pZCkNCj4+Pj4gK3sN
Cj4+Pj4gKyAgICBjb25zdCBzdHJ1Y3QgZG9tYWluICpkOw0KPj4+PiArICAgIGludCByYyA9
IC1FTk9NRU07DQo+Pj4+ICsNCj4+Pj4gKyAgICBzcGluX2xvY2soJmRvbV9zdGF0ZV9jaGFu
Z2VkX2xvY2spOw0KPj4+PiArDQo+Pj4+ICsgICAgaWYgKCBkb21fc3RhdGVfY2hhbmdlZCAp
DQo+Pj4+ICsgICAgICAgIGJpdG1hcF96ZXJvKGRvbV9zdGF0ZV9jaGFuZ2VkLCBET01JRF9G
SVJTVF9SRVNFUlZFRCk7DQo+Pj4+ICsgICAgZWxzZQ0KPj4+PiArICAgIHsNCj4+Pj4gKyAg
ICAgICAgZG9tX3N0YXRlX2NoYW5nZWQgPSB4dnphbGxvY19hcnJheSh1bnNpZ25lZCBsb25n
LA0KPj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJJ
VFNfVE9fTE9OR1MoRE9NSURfRklSU1RfUkVTRVJWRUQpKTsNCj4+Pg0KPj4+IC4uLiBhbHJl
YWR5IHRoaXMgYWxvbmUgd2Fzbid0IG5pY2UsIGFuZCBjb3VsZCBiZSBhdm9pZGVkIChieSBk
b2luZyB0aGUNCj4+PiBhbGxvY2F0aW9uIHByaW9yIHRvIGFjcXVpcmluZyB0aGUgbG9jaywg
d2hpY2ggb2YgY291cnNlIGNvbXBsaWNhdGVzIHRoZQ0KPj4+IGxvZ2ljIHNvbWUpLg0KPj4+
DQo+Pj4gV2hhdCdzIHBlcmhhcHMgbGVzcyBkZXNpcmFibGUgaXMgdGhhdCAuLi4NCj4+Pg0K
Pj4+PiBAQCAtNDk0LDYgKzQ5NSwxNSBAQCBpbnQgZXZ0Y2huX2JpbmRfdmlycShldnRjaG5f
YmluZF92aXJxX3QgKmJpbmQsIGV2dGNobl9wb3J0X3QgcG9ydCkNCj4+Pj4gICAgICAgICAg
ICBnb3RvIG91dDsNCj4+Pj4gICAgICAgIH0NCj4+Pj4gICAgDQo+Pj4+ICsgICAgaWYgKCB2
aXJxID09IFZJUlFfRE9NX0VYQyApDQo+Pj4+ICsgICAgew0KPj4+PiArICAgICAgICByYyA9
IGRvbWFpbl9pbml0X3N0YXRlcygpOw0KPj4+PiArICAgICAgICBpZiAoIHJjICkNCj4+Pj4g
KyAgICAgICAgICAgIGdvdG8gb3V0Ow0KPj4+PiArDQo+Pj4+ICsgICAgICAgIGRlaW5pdF9p
Zl9lcnIgPSB0cnVlOw0KPj4+PiArICAgIH0NCj4+Pj4gKw0KPj4+PiAgICAgICAgcG9ydCA9
IHJjID0gZXZ0Y2huX2dldF9wb3J0KGQsIHBvcnQpOw0KPj4+PiAgICAgICAgaWYgKCByYyA8
IDAgKQ0KPj4+PiAgICAgICAgew0KPj4+DQo+Pj4gLi4uIHRoZSBwbGFjZW1lbnQgaGVyZSBh
ZGRpdGlvbmFsbHkgaW50cm9kdWNlcyBsb2NrIG5lc3Rpbmcgd2hlbiByZWFsbHkNCj4+PiB0
aGUgdHdvIGxvY2tzIHNob3VsZG4ndCBoYXZlIGFueSByZWxhdGlvbnNoaXAuDQo+Pj4NCj4+
PiBIb3cgYWJvdXQgZ2l2aW5nIGRvbWFpbl9pbml0X3N0YXRlcygpIGEgYm9vbGVhbiBwYXJh
bWV0ZXIsIHN1Y2ggdGhhdCBpdA0KPj4+IGNhbiBiZSBjYWxsZWQgdHdpY2UsIHdpdGggdGhl
IGZpcnN0IGludm9jYXRpb24gbW92ZWQgYmFjayB1cCB3aGVyZSBpdA0KPj4+IHdhcywgYW5k
IHRoZSBzZWNvbmQgb25lIHB1dCAuLi4NCj4+Pg0KPj4+PiBAQCAtNTI3LDYgKzUzNyw5IEBA
IGludCBldnRjaG5fYmluZF92aXJxKGV2dGNobl9iaW5kX3ZpcnFfdCAqYmluZCwgZXZ0Y2hu
X3BvcnRfdCBwb3J0KQ0KPj4+PiAgICAgb3V0Og0KPj4+PiAgICAgICAgd3JpdGVfdW5sb2Nr
KCZkLT5ldmVudF9sb2NrKTsNCj4+Pj4gICAgDQo+Pj4+ICsgICAgaWYgKCByYyAmJiBkZWlu
aXRfaWZfZXJyICkNCj4+Pj4gKyAgICAgICAgZG9tYWluX2RlaW5pdF9zdGF0ZXMoKTsNCj4+
Pj4gKw0KPj4+PiAgICAgICAgcmV0dXJuIHJjOw0KPj4+PiAgICB9DQo+Pj4NCj4+PiAuLi4g
ZG93biBoZXJlLCBub3QgZG9pbmcgYW55IGFsbG9jYXRpb24gYXQgYWxsIChvbmx5IHRoZSBj
bGVhcmluZyksIGFuZA0KPj4+IGhlbmNlIGVsaW1pbmF0aW5nIHRoZSBuZWVkIHRvIGRlYWwg
d2l0aCBpdHMgZmFpbHVyZT8gKEFsdGVybmF0aXZlbHkNCj4+PiB0aGVyZSBjb3VsZCBvZiBj
b3Vyc2UgYmUgYSBzcGxpdCBpbnRvIGFuIGluaXQgYW5kIGEgcmVzZXQgZnVuY3Rpb24uKQ0K
Pj4+DQo+Pj4gVGhlcmUgb2YgY291cnNlIGlzIHRoZSBjaGFuY2Ugb2YgcmFjZXMgd2l0aCBz
dWNoIGFuIGFwcHJvYWNoLiBJJ2QgbGlrZQ0KPj4+IHRvIG5vdGUgdGhvdWdoIHRoYXQgd2l0
aCB0aGUgcGxhY2VtZW50IG9mIHRoZSBjYWxsIGluIHRoZSBodW5rIGFib3ZlDQo+Pj4gdGhl
cmUncyBhIG1pbm9yIHJhY2UsIHRvbyAoYWdhaW5zdCAuLi4NCj4+Pg0KPj4+PiBAQCAtNzMw
LDYgKzc0Myw5IEBAIGludCBldnRjaG5fY2xvc2Uoc3RydWN0IGRvbWFpbiAqZDEsIGludCBw
b3J0MSwgYm9vbCBndWVzdCkNCj4+Pj4gICAgICAgICAgICBzdHJ1Y3QgdmNwdSAqdjsNCj4+
Pj4gICAgICAgICAgICB1bnNpZ25lZCBsb25nIGZsYWdzOw0KPj4+PiAgICANCj4+Pj4gKyAg
ICAgICAgaWYgKCBjaG4xLT51LnZpcnEgPT0gVklSUV9ET01fRVhDICkNCj4+Pj4gKyAgICAg
ICAgICAgIGRvbWFpbl9kZWluaXRfc3RhdGVzKCk7DQo+Pj4NCj4+PiAuLi4gdGhpcyBhbmQg
dGhlIHNhbWUgcmVtb3RlIHZDUFUgdGhlbiBpbW1lZGlhdGVseSBiaW5kaW5nIHRoZSB2SVJR
DQo+Pj4gYWdhaW4pLiBIZW5jZSB5ZXQgYW5vdGhlciBhbHRlcm5hdGl2ZSB3b3VsZCBhcHBl
YXIgdG8gYmUgdG8gZHJvcCB0aGUNCj4+PiBuZXcgZ2xvYmFsIGxvY2sgYW5kIHVzZSBkLT5l
dmVudF9sb2NrIGZvciBzeW5jaHJvbml6YXRpb24gaW5zdGVhZA0KPj4+IChwcm92aWRlZCAt
IHNlZSBhYm92ZSAtIHRoYXQgb25seSBhIHNpbmdsZSBlbnRpdHkgY2FuIGFjdHVhbGx5IHNl
dCB1cA0KPj4+IGFsbCBvZiB0aGlzKS4gVGhhdCB3b3VsZCBwcmV0dHkgbXVjaCB3YW50IHRv
IGhhdmUgdGhlIGFsbG9jYXRpb24ga2VwdA0KPj4+IHdpdGggdGhlIGxvY2sgYWxyZWFkeSBo
ZWxkICh3aGljaCBpc24ndCBuaWNlLCBidXQgYXMgc2FpZCBpcyBwZXJoYXBzDQo+Pj4gdG9s
ZXJhYmxlKSwgYnV0IHdvdWxkIGF0IGxlYXN0IGVsaW1pbmF0ZSB0aGUgdW5kZXNpcmFibGUg
bG9jayBuZXN0aW5nLg0KPj4+DQo+Pj4gUmUtdXNlIG9mIHRoZSBkb21haW4ncyBldmVudCBs
b2NrIGlzIGF0IGxlYXN0IHNvbWV3aGF0IGp1c3RpZmllZCBieQ0KPj4+IHRoZSBiaXQgYXJy
YXkgYmVpbmcgdGllZCB0byBWSVJRX0RPTV9FWEVDLg0KPj4+DQo+Pj4gVGhvdWdodHM/DQo+
Pg0KPj4gV2l0aCBteSBzdWdnZXN0aW9uIGFib3ZlIEkgdGhpbmsgdGhlcmUgaXMgbm8gcmFj
ZSwgYXMgb25seSB0aGUgZG9tYWluIGhhbmRsaW5nDQo+PiBWSVJRX0RPTV9FWEMgY291bGQg
YWxsb2MvZGVhbGxvYyBkb21fc3RhdGVfY2hhbmdlZC4NCj4gDQo+IFlldCBzdGlsbCBpdCBj
b3VsZCBiZSBtdWx0aXBsZSB2Q1BVLXMgdGhlcmVpbiB0byB0cnkgdG8gaW4gcGFyYWxsZWwu
DQoNCkJ1dCBpc24ndCB0aGlzIGFnYWluIHRoZSBuZWVkIGZvciB0cnVzdGluZyBvdGhlciBw
cm9jZXNzZXMgd2l0aGluIHRoZSBkb21haW4NCmhhdmluZyB0aGUgcmlnaHQgdG8gY29uc3Vt
ZSB0aGUgdmlycT8NCg0KSW4gdGhlIGVuZCBpdCBkb2Vzbid0IG1hdHRlciB3aGV0aGVyIHRo
ZXJlIGlzIHN1Y2ggYSByYWNlIG9yIG5vdC4gU29tZQ0KcHJvY2VzcyBpbiB0aGF0IGRvbWFp
biBoYXZpbmcgdGhlIHBvd2VyIHRvIGRvIGV2ZW50IGNoYW5uZWwgb3BlcmF0aW9ucyBjb3Vs
ZA0Kc2ltcGx5IGNsb3NlIHRoZSBldmVudCBjaGFubmVsLiBTbyBpdCBJUyByZWFsbHkgYWJv
dXQgdHJ1c3QuDQoNCj4gDQo+PiBVc2luZyBkLT5ldmVudF9sb2NrIGZvciBzeW5jaHJvbml6
YXRpb24gaXMgbm90IGEgbmljZSBvcHRpb24gSU1PLCBhcyBpdCB3b3VsZA0KPj4gcmVxdWly
ZSB0byB0YWtlIHRoZSBldmVudF9sb2NrIG9mIHRoZSBkb21haW4gaGFuZGxpbmcgVklSUV9E
T01fRVhFQyB3aGVuIHRyeWluZw0KPj4gdG8gc2V0IGEgYml0IGZvciBhbm90aGVyIGRvbWFp
biBjaGFuZ2luZyBzdGF0ZS4NCj4gDQo+IFdlbGwsIHllcywgaXQncyB0aGF0IGRvbWFpbidz
IGRhdGEgdGhhdCdzIHRvIGJlIG1vZGlmaWVkLCBhZnRlciBhbGwuDQoNClRydWUsIGJ1dCB1
c2luZyBkLT5ldmVudF9sb2NrIHdvdWxkIHByb2JhYmx5IGluY3JlYXNlIGxvY2sgY29udGVu
dGlvbiwgYXMgdGhpcw0KbG9jayBpcyB1c2VkIG11Y2ggbW9yZSBvZnRlbiB0aGFuIHRoZSBu
ZXcgbG9jayBpbnRyb2R1Y2VkIGJ5IG15IHBhdGNoLg0KDQoNCkp1ZXJnZW4NCg==
--------------1OkYYJKIGx2nQcY88XbA7a7W
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-----

--------------1OkYYJKIGx2nQcY88XbA7a7W--

--------------6EWgdWQk5ExBp58YTfCEh0Wb--

--------------wy0qqVeRzNRn21eZh8BJP3Wg
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/Ey8FAmdidpQFAwAAAAAACgkQsN6d1ii/Ey9q
Twf+IWDVlU1uUXxNIQeNNaGaW3NLBSwGcBYfrWE6Lrh9QRhTuTs28PcHxfRQUF2qqYlCFQrO9AkT
FYXXTOIDzqK1dtQIqL0kXbxv8uLXIF1sSuhJGK09lcwio2aDoc3hyaWEchDowi2HkhX079yi0kT6
L0ghw3axhHLbprZDQHbUe+rs+9a9bTzOT6epbVP+t7a80GKa63F3IecTSsvLh74F9qEAqWZknDGS
ktIBY3r871KSmnwh7r14ND3qAgFkh9wNEozqUiHbZAC78cUbvXZ6KiAZmhvBmEXMM+/8PggKhWWE
pMgQgngbiOszNKobMj0Dx2NgvekzBvNOPSkQuN3uVg==
=cO5Q
-----END PGP SIGNATURE-----

--------------wy0qqVeRzNRn21eZh8BJP3Wg--


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 07:28:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 07:28:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860000.1272080 (Exim 4.92)
	(envelope-from )
	id 1tNoTS-0007Ga-IB; Wed, 18 Dec 2024 07:28:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860000.1272080; Wed, 18 Dec 2024 07:28: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 1tNoTS-0007GT-FC; Wed, 18 Dec 2024 07:28:02 +0000
Received: by outflank-mailman (input) for mailman id 860000;
 Wed, 18 Dec 2024 07:28: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 1tNoTQ-0007GN-8f
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 07:28:00 +0000
Received: from EUR03-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur03on20612.outbound.protection.outlook.com
 [2a01:111:f403:260c::612])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9aaa46f1-bd11-11ef-a0d6-8be0dac302b0;
 Wed, 18 Dec 2024 08:27:59 +0100 (CET)
Received: from DU2PR04CA0258.eurprd04.prod.outlook.com (2603:10a6:10:28e::23)
 by DU5PR08MB10577.eurprd08.prod.outlook.com (2603:10a6:10:51a::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Wed, 18 Dec
 2024 07:27:51 +0000
Received: from DB1PEPF000509F0.eurprd03.prod.outlook.com
 (2603:10a6:10:28e:cafe::fc) by DU2PR04CA0258.outlook.office365.com
 (2603:10a6:10:28e::23) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.22 via Frontend Transport; Wed,
 18 Dec 2024 07:27:51 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DB1PEPF000509F0.mail.protection.outlook.com (10.167.242.74) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.15
 via Frontend Transport; Wed, 18 Dec 2024 07:27:50 +0000
Received: ("Tessian outbound 050b604d5e06:v528");
 Wed, 18 Dec 2024 07:27:50 +0000
Received: from L976997580e71.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 951AE95F-73DD-4202-8A37-788415438DB0.1; 
 Wed, 18 Dec 2024 07:27:43 +0000
Received: from EUR02-DB5-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 L976997580e71.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 18 Dec 2024 07:27:43 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by VI1PR08MB5438.eurprd08.prod.outlook.com (2603:10a6:803:12e::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Wed, 18 Dec
 2024 07:27:39 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 07:27: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: 9aaa46f1-bd11-11ef-a0d6-8be0dac302b0
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=LtWK3AAfTasLdYRgRZHavBU09ihSpEKN7Lf1gdOwfaZuDNPkKztB8+u/R7MCy3CGfQQx/apf6Zci6tv+RbYtPhf4UIORmkhdy0yONHqOFy2mjpFY5RaZxJB5Lig97uiyTqLPmuQ12d0qR1yguyfIKlIF3KjAxcty4DprGsg7abRu92roAXAKingsNecd5gt01vNgTrTuXox1iNObVrVGjugc8i/63f5wOx5t5FJ3uGKgDxEZ/FDv9FiHDCP2uqF5un75Kyn55B2ADPWg1Rhc62oxfvdFXV69nsm1biqWjsggCe0u+tOavSUADiIYDzHVc8BmysJVsjjIKC0hlw5Crg==
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=/ufWEjyvu8OJlYsuD40Ast3EWfXDmYIA0HMjgIc+JJ8=;
 b=N9sQkYvekAKhTMFWYXtv1zPbt8mzQxXqsjUkUaLWwFVwH6mx7CbJ5K72gywLddxg8oCqYsjlIqtFgYFKhgLZPpBGHV7u7K8Vg6/3k7Yu9QkrSh/ggSgXEV8WYIsJKZ6SPt+vDX1yF3l/Ic60uKPtvSQWtXgA3b4JCFSuzSs1G2K+awbcdPJ5jUFW0DjUO/5ubjeEJDwYVUbQEzowJYKFXkw7aPtpO05j67uz+gaGFVgoVnRtIqZ1189gMykoWcorsm2Bo1VFCyEPttxwJj4020l4EqvLerJ8oMI2VGdQ7YzFS0Yg8CW9Z0ognNsw5T3ixBWq7tkAN6CPHW9AbV0NBQ==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=/ufWEjyvu8OJlYsuD40Ast3EWfXDmYIA0HMjgIc+JJ8=;
 b=p1FgkWW+6SdoUyC+DE/9KVadnbUZbeyo/413+A+90wJ3r8STBX0CrnU48PFMTqkJ8QNcbXFyTic+vp/O5vpOkxhIX6lQ1jxOD2OIQwQTiA6ecM8WtnNg4Cwrw0/7RtFnb4b4O26UGsHXWaUGkFapbUwy3pYwUQajf39L1IYjRsk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 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
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 13d57d9ca674e19d
X-TessianGatewayMetadata: /tY+TLbrR9fdetigmNj3gsE3Deeydl/sbTvWX2mMCGORaJoVvkPKi5uys7HQLkQXNi3xkQm8SthJYKLXZyNuRclxNTtXtzjbNiyvJptim0dhF7dy1YEK1ljeWi/DYsxSJo5PGRjEvjI00mvSfydMvbP4gUKv5KHgPDMOX2wEr5k=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=fUNCVuBgv19P0yw1dhcrBkmZ1LiX4NaHZjGjc5hurIdh50N/9NoqSGUiiKc6qlERxMYHHM0nw0qOlb7++MI/xltpA/ooVUp4K4vwC96Fy3xZGwFaBvD8t5kCoP87e3Coprp0KRqvx4yOkGs1Y3AoKpRzhGQUeMw6pkCnz5sSU+aDzk8sElYKgDerdFKAryo5GeRE0VmaZ2lPaThQSdqqGxv7/n9ubX7VCJGHrPf/GT8R61HzaEc4r9pzdNovMnLMcxa3PXOPTAjpS1sT8HhibVnD2F4QUC+9pAQIfa8d+cuqtQJAU5dixC1GIVW1+4VnDBGvuAS10FX7QTpu1I8QQg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/ufWEjyvu8OJlYsuD40Ast3EWfXDmYIA0HMjgIc+JJ8=;
 b=LphmgGuftWYkLhnnakKm8RfzF8G4OllfU6gdjBLE5IxXg04tL62DLkEiMSlrE3JzNif3hvCxLJoZTWBGBD2CM/bCokiZKDBe3DoaMlUe1yLmd1i3PxFsZwA7pQr3lFyWnwoNLK5LY6siqw64gSV7gNOrE7rp6d2a7ukwXwqdtB9wCaoPkBUh0BbWu9e5Cu2EYxQpbtR0zazyKoV9Sx6Wn+Uw7si8fsxcASG33OINAi4kHJr7B+GkUB9Hlbp+QLrnlFSw1rrd7uAmX2052uTZV0MuwAhTknAJ7E3gldZm9XOTI9SQKGEIroX9G12H00chhJSw8+G5GDcOAVsu+yiSnQ==
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=/ufWEjyvu8OJlYsuD40Ast3EWfXDmYIA0HMjgIc+JJ8=;
 b=p1FgkWW+6SdoUyC+DE/9KVadnbUZbeyo/413+A+90wJ3r8STBX0CrnU48PFMTqkJ8QNcbXFyTic+vp/O5vpOkxhIX6lQ1jxOD2OIQwQTiA6ecM8WtnNg4Cwrw0/7RtFnb4b4O26UGsHXWaUGkFapbUwy3pYwUQajf39L1IYjRsk=
From: Bertrand Marquis 
To: Julien Grall 
CC: "xen-devel@lists.xenproject.org" ,
	"jens.wiklander@linaro.org" , Volodymyr Babchuk
	, Stefano Stabellini ,
	Michal Orzel 
Subject: Re: [PATCH v3 04/10] xen/arm: ffa: Fine granular call support
Thread-Topic: [PATCH v3 04/10] xen/arm: ffa: Fine granular call support
Thread-Index: AQHbQOahZBVDYXOcj0uVqGja5nIgjbLk4umAgAO+LICAAMjkAIACUM4A
Date: Wed, 18 Dec 2024 07:27:38 +0000
Message-ID: <5C9B583A-A48D-46E0-86BB-4081BBCFDF9A@arm.com>
References: 
 <1b02c9c1df9ff2230e076f25398a5de876f98a51.1732702210.git.bertrand.marquis@arm.com>
 <8d8ef7f9-d73f-4ff8-8af9-4e73cda97624@xen.org>
 <03D53BB9-1751-42DF-9AAD-41B25E915027@arm.com>
 <38870638-6d87-4a0d-843d-37cc55bb54a9@xen.org>
In-Reply-To: <38870638-6d87-4a0d-843d-37cc55bb54a9@xen.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|VI1PR08MB5438:EE_|DB1PEPF000509F0:EE_|DU5PR08MB10577:EE_
X-MS-Office365-Filtering-Correlation-Id: c171fa21-5915-4ebb-57d9-08dd1f357a86
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|366016|376014|1800799024|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?SHcHjaIX1e2ebCwo5/igywRLL4Nt/eGPDuY90IzMjHTWYYwkaGtgu6xS0dI0?=
 =?us-ascii?Q?+C6jJI+D0zasL1NRGC2zLGsPQDsC30mLNAYNk7ZADIW490l3/ZENeavSyLQ3?=
 =?us-ascii?Q?SkrZNWWYCWSrZP6L4xP0i5r5AdYuNFbePwC5xIrNSeuIbcWWD83Lk5aOsUjU?=
 =?us-ascii?Q?/7eoaZlOSowVJhVbqExmiE5x6WpHgHU5lFPx8H69khg2i6D2O9ZISmVt8zRh?=
 =?us-ascii?Q?coGztKPd2EmkqFuoaQ+uqfcilYoCAO7PAnEOP0xaAufVfaScYizj/AusjD/Y?=
 =?us-ascii?Q?Ogu4PjwtJ+bG6Ati7uSSqVkWNxi6mI7rTHdCyuYkirHPT7bmAkjp1fvceiqV?=
 =?us-ascii?Q?B9dlm3XcZjVppPKJyK2OPnHmkBr7IKQzksfD7MZe22zd1/vw8JQ91yB4Ljzv?=
 =?us-ascii?Q?KpmNo/j/+TJ3yMZGpfXd6PEKj5Sy7UG2lVTaxjqcNrNBZZ8P4T6RwUagmQGR?=
 =?us-ascii?Q?wORtDWRh5lLrhaNJZRljqDU1mI+ieEgDG5gDQItKzfkxqVlKGXzmd1cZiK7n?=
 =?us-ascii?Q?H6fq+fTVi7BLHtQ660kNiSpYwaxtHKy+8gG7YpDMpxn74kHRWaz3XRDBAjOl?=
 =?us-ascii?Q?4hMnMB0B4XeRD56kN72LC1LMCeauk8uRgiS9BQR7n+MM4V3EtybbH3B9hkQy?=
 =?us-ascii?Q?jPS4Q6ipxy3/qDyrbGgV+7UATGCUussCXP7dFByaH6ivjlAL5CBsXOJrR8IR?=
 =?us-ascii?Q?k+X+5r+XsK7pVtty7BtZ3Y/2KE91pgwtHapPZxXICqjBaq7PNNm/+OwgJfuo?=
 =?us-ascii?Q?ftWYp3o66LjzDZv0GuTYyJgbunGlBKEb2KX0dDgRyyxfDJJFjbFD7NnmRCuE?=
 =?us-ascii?Q?TgbbkznajYpMin5JTdiGMNqWxEAfso1ldltpBLgBc8o1yBGALLRyF/dQkRff?=
 =?us-ascii?Q?eVzLnsEoq/3NJP3RS+i2YmtLEAPinP/WsQH5q3j4PGGmEQHGXT5EFp0nDvFO?=
 =?us-ascii?Q?53aeR8BsziO8aopzEwk6/6eKFdkV6ezD8ZeuH+RdGAIMcgTnxgvh7PmZM28d?=
 =?us-ascii?Q?YHe0BBrtO56XkpNWbpWfHZk8tWKoCq+rftnbIq8vnQBZqKpreMvPI3aCPwxA?=
 =?us-ascii?Q?PWmgIZxACP58WVMKIYx0Yg+PxoCMD013X2OYueyYGQMtfCCQ6RE/9NFO7w8q?=
 =?us-ascii?Q?RH3asv8f0w1E7F9f/z1nHVcm88uYK1C0vj9iBuzHkdO3HcQwxZQA/H2a+fD0?=
 =?us-ascii?Q?vbDHXt2VEUChRmx+s7DQtit7SXFZ8F6aKC2ySgrWDdw4D2LKAflj/uaV9Zw4?=
 =?us-ascii?Q?ZDKsblSAX3PzxEFnw9eUtYXayGHEfrMlEn3hdcFaIutZX739N/aBKQtCKox6?=
 =?us-ascii?Q?XNYnV/ZOLUhfvLu1oOIZg3WmYrsTNe3eGCGoub2VG3CcopzLa1XflP+fxQsR?=
 =?us-ascii?Q?vPr5E/kV4VU7KS7zy2GFzwhzooxdOk9FvCIRdYADvE/EMHT1sC6UXizpdDqH?=
 =?us-ascii?Q?j/oyjG88qUIFPoT/2KcS/T40JbQiUey6?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB5438
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender:
 ip=[2603:10a6:10:25a::24];domain=DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB1PEPF000509F0.eurprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	1c4a5150-25dd-4954-cd93-08dd1f35738c
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|14060799003|1800799024|82310400026|35042699022|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?GeYfLYphUJ+rEsUZu1IBrpKgOzftE9vMUJUWKIW5z27g8qNJIB+UQjk6uCYQ?=
 =?us-ascii?Q?/uDm3lV6VMq2vBsRKlrfpOXyfBzB9sDETNCUQMflOBV8UhT2BnaL2nnYyrFR?=
 =?us-ascii?Q?fK1xZQj4vtkZSHANyCC6Mx4gql7Io1vt7q4nnG8QvVYxrgJ0lK3M9YYN8WMA?=
 =?us-ascii?Q?uclfDNNveMZhM4bkaV8GkcqYNf4nkd4Fb1gRZF6BRTEHHu67hYBoOHaeIuww?=
 =?us-ascii?Q?WMyWs/EbbZoaWKAnwll0xloeWLq36gFQbsh7htEOWI1fqEBfKJYY4m/0RiLv?=
 =?us-ascii?Q?jHjY4iM34frAG/I7v5Rv+4ojYDcSneoDu5nCW4cTOPImcDb9iSC28kD54Tve?=
 =?us-ascii?Q?rBGu9TnrtiT0+cUWBsylepz7v0GKPQCXo/eR3NpPGoBPcQL21M0O98S4Y27L?=
 =?us-ascii?Q?C4F7dJmaTUwWXHAQLVyhJ1O7VGZCvKdMK6o673BF+68beTvjoMipeDi5uRdm?=
 =?us-ascii?Q?yXe7a/SrCOPuQ148PiKPTlzDn9My3F8PMemDijBzyb8OGxDFFHHvJnqVZoNI?=
 =?us-ascii?Q?wvqkHu+ciO4MOckAu5FV7VcBvDPjqPolVUnXRnvaXG1NtsBRF1ThqgX6xdZ+?=
 =?us-ascii?Q?msNPRYltu+mcNj+QkpGvEE3uwq6v7LArh9+V0vFsPGH/PBsCCHTbEhRJPoGE?=
 =?us-ascii?Q?trtSMspgalR0qxj/JK63nfVLetZaaOkIbGbNbT7UTfHPhL3otKltoIFD+JMz?=
 =?us-ascii?Q?Yd4Y5Fp2ZyqHc3nBmeTyl3WgeMf3OyvDWfr+2G2REzquce1OIw2QG91q1dKX?=
 =?us-ascii?Q?A4EZothiWkB2ndJEzfFeqbZDTd60x71Mh1rwax0HvgT3UWIXFcapp7k0iJtL?=
 =?us-ascii?Q?ghfKbn7DZh0itR88pe4Bd79hI+hzkueyZJPmHL1vaXCdLrf1Ass5oD0wN4x2?=
 =?us-ascii?Q?25b6qejlQISG+cLZiHPuZdqWVnyJCgNcsZlzllqsc/HGR3DSjBAZtEvaP6IS?=
 =?us-ascii?Q?vHLs6ZwdiG9I9bSCldbaqJRhbjZS/iXtfK+8e7ClqLt6BhFc3Hez4hUNu0Ss?=
 =?us-ascii?Q?AVwGJFZPEvE6mUVi+phxXiTcf8XTYhM0AS2MBbxtZ2DLPFoemg3gUSE6eUmO?=
 =?us-ascii?Q?o6PYWU4p/uBT1U1lB9H5LyBpSURkh8SNAb1Kv833IEWj2S9bl2CNdJVWakYv?=
 =?us-ascii?Q?7ohCm97dMYmnr/bqM57/N2Fyd0cG+QrHvKaQcnfd61XHdBmkgpBdWaghDAie?=
 =?us-ascii?Q?1rnyWMdB/VKjihqtOIqbYOr3WxTL+0gdMe2JrMhbV8wCWjNGl6xSgNpHD429?=
 =?us-ascii?Q?L3tHKSSyyB3bsLk5Ja+PrcX32748MXa7y6YoxWk/ccbtKt2xdNZ60sCrxWbF?=
 =?us-ascii?Q?hKpVJ0dTFE+OfdP9VxC3X6uKPtesaTc9h2ATlTbSb9o0pBuj8C8A2MNopebR?=
 =?us-ascii?Q?k56CxfzUDGqPVOhzr2Rokt4ZV9x1ekph9nEKjRihwsPstaKYysDOw9BQZKmt?=
 =?us-ascii?Q?GLJw0xdAaxQYNBmtHxE5QcbTRGj3GzOMrX+aeBfUWyXiRJ+nCmcVrD+LZzxl?=
 =?us-ascii?Q?120KCHluurB/TuM=3D?=
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(14060799003)(1800799024)(82310400026)(35042699022)(376014)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 07:27:50.5518
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c171fa21-5915-4ebb-57d9-08dd1f357a86
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB1PEPF000509F0.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU5PR08MB10577

Hi,

> On 16 Dec 2024, at 21:05, Julien Grall  wrote:
>=20
>=20
>=20
> On 16/12/2024 08:06, Bertrand Marquis wrote:
>> Hi Julien,
>=20
> Hi Bertrand,
>=20
>>> On 13 Dec 2024, at 23:57, Julien Grall  wrote:
>>>=20
>>> Hi Bertrand,
>>>=20
>>> On 27/11/2024 16:07, Bertrand Marquis wrote:
>>>> Create a bitmap to store which feature is supported or not by the
>>>> firmware and use it to filter which calls are done to the firmware.
>>>> While there reoder ABI definition by numbers to easily find the min an=
d
>>>=20
>>> Typo (I can fix it while committing): s/reoder/reorder
>> Thanks for the finding.
>> Please fix on commit if that is ok for you.
>> There are also 2 minor findings on the patch 7 that could be fixed on co=
mmit.
>=20
> I think I fixed all the minor findings and it is now committed.

Thanks a lot.

Cheers
Bertrand

>=20
> Cheers,
>=20
> --=20
> Julien Grall




From xen-devel-bounces@lists.xenproject.org Wed Dec 18 08:27:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 08:27:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860019.1272089 (Exim 4.92)
	(envelope-from )
	id 1tNpOv-0006ta-RE; Wed, 18 Dec 2024 08:27:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860019.1272089; Wed, 18 Dec 2024 08:27: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 1tNpOv-0006tT-Oa; Wed, 18 Dec 2024 08:27:25 +0000
Received: by outflank-mailman (input) for mailman id 860019;
 Wed, 18 Dec 2024 08:27: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 1tNpOu-0006tN-Ej
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 08:27:24 +0000
Received: from DB3PR0202CU003.outbound.protection.outlook.com
 (mail-northeuropeazlp170110001.outbound.protection.outlook.com
 [2a01:111:f403:c200::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e776cee8-bd19-11ef-a0d6-8be0dac302b0;
 Wed, 18 Dec 2024 09:27:23 +0100 (CET)
Received: from DUZPR01CA0053.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:469::11) by AS8PR08MB10170.eurprd08.prod.outlook.com
 (2603:10a6:20b:63f::12) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Wed, 18 Dec
 2024 08:27:13 +0000
Received: from DB3PEPF00008859.eurprd02.prod.outlook.com
 (2603:10a6:10:469:cafe::45) by DUZPR01CA0053.outlook.office365.com
 (2603:10a6:10:469::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.23 via Frontend Transport; Wed,
 18 Dec 2024 08:27:12 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DB3PEPF00008859.mail.protection.outlook.com (10.167.242.4) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.15
 via Frontend Transport; Wed, 18 Dec 2024 08:27:11 +0000
Received: ("Tessian outbound 7762b28e8285:v528");
 Wed, 18 Dec 2024 08:27:10 +0000
Received: from Lf16dce637394.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 A3A9DCC4-E6F2-449E-94A1-79937F7EC93B.1; 
 Wed, 18 Dec 2024 08:27:04 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 Lf16dce637394.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 18 Dec 2024 08:27:04 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by VI1PR08MB9981.eurprd08.prod.outlook.com (2603:10a6:800:1c5::5)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Wed, 18 Dec
 2024 08:27:01 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 08:27: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: e776cee8-bd19-11ef-a0d6-8be0dac302b0
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=KgbXF4X7SiQ+gglKiw+44YuOqJpiTn7upw9VXnoJGt/a+EJedqm7vdVA73LtWi6pqSsSO5uQHaMe0jZhg6/LmhzVD2stMhqXczgAG85OEYROV69+GpsC38m+TRCD0dG15NwGWsfIT7z+K5eEwEp+ceKvrWGiw2XNzOb1CgMCKMiMsdDjZbrjV7I+9WBeI3pmagODVQZsQhYk5m3RQ0mRfAkKAJY3V/Hg1bqkL6aGCsGG9zerb0Vw3eEeZavMBro85dIBjJqzTS1mZobsGIrM5lBDJpImWZi0qNIJFGSInr4r8tXATWtlgN6MDJh5mg4D25KIgqe9tahKx78mdG5QXQ==
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=toBtqezZ82CRFAR74FnNEi+z7c7elFH7reaWejHxzdU=;
 b=SQn326/4cHdM91RrGoTaxEjbfinsYiVQw5+iu0PA5aYBQMNzhL+8TbIioz0Kkly3lYSxHK0I3lGpVGGG/KOer2NvgrnWa4MT9HS4G7TE0/JJKfTSjtanraHKADqhAmBZCxfriargxlXd5WtADkILzZd+9NkYN6P8F5rRRhCFYp3tRhLxx5iUCVQmHa/SRklNV1LO1V7xXMF7roOSy48JMiz/38wMolzH/l/BWpGaoszg3ogbz7iRTWTXBMvlK4XF+etSco/8p91o9PT51L2C4DCeqNFb8y2ub7nl3zyxJ4xQV1nAcJHQYRlExjfXNqdrl4OoPAnKeEME6XsyNVtB5w==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=toBtqezZ82CRFAR74FnNEi+z7c7elFH7reaWejHxzdU=;
 b=prP3GsI8iZ99X6k5z4YEd6y7It/lUn5FhKoBRXGCiR5GT+g18L5diiW+evLnZgtPdMqJlwphejVRzz1JxEFmRihh00PtJJw8H2ugFI9t8Pmc4DAQH1zcl2bkAleLCyuQWuxz7XB7OZWkun+Eew/kqf0m4G8+79OpzW/8ymY5q4g=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 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
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 1d5e4208821c43e0
X-TessianGatewayMetadata: qz4jRF9RsteyhxIxTjYqkm2G2ec5WDlF4akHeo+nknBje+1TE4Zu8fpADJqEui4UhbLPitvDByNTEYXMRmBbzEx25vHob84WJf+RofmXrVBuKf2sBDTtckrJod1x9LRZ9eyVYJu05LDpnc55fh0iH2GRgwnKaVXminQQsm1Zt5c=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ZwVsIRgu2vTgfqLenXMU1NaGBGscxguhWtNs3N8z+mwVw78f9q8/7E4fiA+s4hu8xfs000U4x2d+c2Y3/VDVX1JQ3VHUHd/LJkR+BUplTqxG/LbQ0RrvTD/ejU8G5QhgYxr1ummbE/zMy75K57E6k7yHJqvipV7HJe9EcPbVjS7FU9h6cjRUnkoon0avZZ7oulFlHoMeBDjQiTVCJhPSN+SXaeKfFgA7YJV0F/T/OxeEFxLWkT01BRwH2WTJ4X7LrFmVvsS3QdbX2teMIn4/YU0JVHshJzoWYH+JDroR6C8XjBSnkWSmIh6Y+4kgTARlTeD8jR8jZAU/8jmWmab49A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=toBtqezZ82CRFAR74FnNEi+z7c7elFH7reaWejHxzdU=;
 b=OWGKE1mBKIDML20lkJuF7E/bWf5x4MKLagNwzlt/hW1mk/eZ0dvinuOU2er1iN7Jbv9RaC4ixCbkaEBsHHgIJZJLRc6J/p0nQWafxpHCpyL8JJfIjddj3ifL52CJXFE4sodsljknCOvS3OgU44ckTucsSoMhlgBzJHSJuVuWn9wU+iY8DptXElBMyTUb0XvURIrMphHEMUEcK9dhKSIx0rKDc2uQ70VHlwr81vMSRNSkPoGf1dTLdUC0md9ENg+oTW64h0IIwI0An0YeOs5Z6WaN6xvL9273DxaF9gPDmpb6oBES2ycRBvqBy43V5RH/gc5XLi5n9jInIqVGWhpLiw==
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=toBtqezZ82CRFAR74FnNEi+z7c7elFH7reaWejHxzdU=;
 b=prP3GsI8iZ99X6k5z4YEd6y7It/lUn5FhKoBRXGCiR5GT+g18L5diiW+evLnZgtPdMqJlwphejVRzz1JxEFmRihh00PtJJw8H2ugFI9t8Pmc4DAQH1zcl2bkAleLCyuQWuxz7XB7OZWkun+Eew/kqf0m4G8+79OpzW/8ymY5q4g=
From: Bertrand Marquis 
To: Ayan Kumar Halder 
CC: "xen-devel@lists.xenproject.org" , Michal
 Orzel , Stefano Stabellini ,
	Artem Mygaiev 
Subject: Re: [PATCH v2] docs: fusa: Add dom0less domain configuration
 requirements
Thread-Topic: [PATCH v2] docs: fusa: Add dom0less domain configuration
 requirements
Thread-Index: AQHbTMiRgWsw6YUipkyfuZOmy7e9xLLrs5oA
Date: Wed, 18 Dec 2024 08:27:01 +0000
Message-ID: <779AFC45-3F8C-4065-A39E-9325F9C72AAD@arm.com>
References: <20241212190325.2130129-1-ayan.kumar.halder@amd.com>
In-Reply-To: <20241212190325.2130129-1-ayan.kumar.halder@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|VI1PR08MB9981:EE_|DB3PEPF00008859:EE_|AS8PR08MB10170:EE_
X-MS-Office365-Filtering-Correlation-Id: 915e162f-5d36-40e2-9edc-08dd1f3dc4bc
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|1800799024|366016|10070799003|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?/WHQQB1VOx1pqCG0bj3HV//kzOj28jVSO3vM1+s4zMo64SETEc7qZJ1Jahkg?=
 =?us-ascii?Q?8igULc2DsEGutYrVOlZZB5n2KUnIBHE3/WZH4Q2Q1JodjuqDta5O2GsTfUzq?=
 =?us-ascii?Q?W+08pNfM617eThHYwalSUO1kgronhWX+h2d34IqmYlZ+5ZmcgQ8W7Aa4QqFX?=
 =?us-ascii?Q?cSfCe284ETMGK8WkIEUQ1TBHvWu8TpHANDbvb+lvk/sCKTatKPDSLKPTxDvi?=
 =?us-ascii?Q?+QC7cVEcyPh5VnBU84bLMXBWjbbJBvlByBXtpzjXVUNTIfx8mTSfSgVnzzCN?=
 =?us-ascii?Q?JgmBU+9ZM4R7X07Pj/L+5GqnQ+RGPAUZ8jpRZYsyDjBWruR7nf2XbLJcvVdd?=
 =?us-ascii?Q?Cqoipyau7L7CmfQujROvIMnWxz/arV4c2ay85U05t5TpDkByaN/VMkcI6GXG?=
 =?us-ascii?Q?G2FS5zRF5rQ8iIFdJ2xtrF7upl5YFCleaaudtghCCgGqg3k8e8V0uJoWwWIL?=
 =?us-ascii?Q?EbX3O5o1LIzeL+JytHwaLLn31yJNox+EBg9P3cBiWS778eTvsc38kmglhZwX?=
 =?us-ascii?Q?O5iRh1SXn8HFdJfPIVzIYb9MNu3YnrgcKo5MgaYwGh9m1aqbsn9cVjoRGBY8?=
 =?us-ascii?Q?92OX8K083sNRs43BS/eJsB7mswnWoBRMA8japqQ5eZycIz6nhjsMzRx+yclZ?=
 =?us-ascii?Q?Az9h1pXB/G5QsMgxXA15RZzsilLfWAUKkiUG7WKG++VdJuVI0QOgpQ7gELp2?=
 =?us-ascii?Q?nuQ1muouN/h1aMExtLOmkeNVwmmIubFrvX0WmpsgJOGmrQKJQx1tYK7zJBvJ?=
 =?us-ascii?Q?nslmy1O7dNg5AV4GeNsxQhHMBUxW1vzDe5pUO0b6wNu9zWWQoIVRaiftUW2K?=
 =?us-ascii?Q?8q0ts9ClxiqwFvFqJw/ez7SoLYKJWI3KWlbSlNIw4axBb/SfvUo1a2FXk8TD?=
 =?us-ascii?Q?gxb/iaBLAJ5sMfyzrF4edUivzVsyF9EAgsDv/gBhJp57sUP3Dflxt/hmOnhE?=
 =?us-ascii?Q?4xG5ZZgX/QkewJEO4VLJP0LriG6P3hk8zErQzFifKtwwtffQl2gzGWjVQDcQ?=
 =?us-ascii?Q?BjJHrl4W3oy2i6ILje7pdMJLxkVIf/+hGmhByveVbhcrE7KeN4v3pUG23sI9?=
 =?us-ascii?Q?sANZPCeCRcB/nws0RUQhyjhU4JxDlXzfxi5Ws3EvHdC/IsoAm54WUZ8i6tQW?=
 =?us-ascii?Q?icdZzOydyoe3j40B4x0791eeuXkTTrjU1/o3PSd2lp1hs4ECjRFkNGdJYxV7?=
 =?us-ascii?Q?KfjrI8nNB4x+8r1u5VwNgVhFYoi4LI8sASxVJiFZJY8gAfpdJ6WR3R52jWvZ?=
 =?us-ascii?Q?MK3DWaKMhx4Sy/dAi8aUk/6Q7AAYQZMa1imQ1Lp2jRwKIcLjYR4ptBF/ro4e?=
 =?us-ascii?Q?0fHE70N+miojNyD/GQeA2Lr1/eiJViYU1fzhy1Xlr9l9lrFKhee7P8HLZYw5?=
 =?us-ascii?Q?Nv1p2R1/GjPgB5UO5wEflIVN8Ju2Y4IlXtC0517rGoClPDCnjQ=3D=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(10070799003)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB9981
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender:
 ip=[2603:10a6:10:25a::24];domain=DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB3PEPF00008859.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	3a1148a2-e6e2-469b-746c-08dd1f3dbf1c
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|14060799003|36860700013|1800799024|376014|82310400026|35042699022;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?3uNhSt0tpOL4HE2c5XWBPFcp90FmsoESN1d7V7V5EDRN8UtT2mLVYpVbUAHd?=
 =?us-ascii?Q?w/KkowaB834iSiGmgYBuKLdh7xAQAdYnUkgnACsm8bzXJF/O6OJknGRVKH4j?=
 =?us-ascii?Q?aDahiSo3U3HY/ldvkKTWQndeX7cFouAePDbDubXLXv/A8+2UvfCg8UK6W8T0?=
 =?us-ascii?Q?MJzNTRvvCOf84vTGrBPeqe3PumHbEAB5nk8XeO4loWG8Xxu9RXumDdOIhOAS?=
 =?us-ascii?Q?t+uxWwtwEylSAmvdW/hlOXxkX5Q5jQi7daTWjecvZoebMOf7ejO1Y1XKFFMR?=
 =?us-ascii?Q?FPOfMUYMGBm74s8AIzQEbyoqN/jkulzgO2Vf7MgL88suGW5FWMDMPUxuSatI?=
 =?us-ascii?Q?JL+lakWoT79bGa0XFdQwqdvLGnO9YDBZnubU2uZM7TuC1hzxtOWdEpPUuWfP?=
 =?us-ascii?Q?6Ck1DtOZgvOXchd7NA1pSie/bRkdTnhZkpkrKz0kcHF5Fglo5aq7cNsqfW/G?=
 =?us-ascii?Q?rbZJ+p5Xr1IHWy21rMhgjoZlVj9QZGX07qAX6JnWasndYv5M4YNw7D+bVZYf?=
 =?us-ascii?Q?BetnzOCytW7XVMskmGU1cADV0LGmSMI0ZnduBrBQXkjzdZBpAyEcZ4X5R2sf?=
 =?us-ascii?Q?IkhVrOaWqq2QcHoqxVPenQBtvp2nuXVJ+MrYVLc3wdh9bz5ITP7LpG7Gsh0U?=
 =?us-ascii?Q?k6WGEGV1rl1gDFw2MbYvKaIfAUEK/ZXqJUZWilhz8uhqRTP1/MgfvcZFcefV?=
 =?us-ascii?Q?XFszPT9V66rbHZc5JC7U10vWFR0By6M2TLE+zY2J3k2Twt6hwnxyyKrb9Xuf?=
 =?us-ascii?Q?OsRV8sSf+f3Hn1m52PPq/KqjKOrob6PWXSAuRsCErh3z5OI2dzeooIY5ieIr?=
 =?us-ascii?Q?vHUzlIyyObAfm6Cfzxsk3Hrdhy3IOvur5a9xdiK3KXnBmpPsZnPsLQaDmv9H?=
 =?us-ascii?Q?lO0XT89Q+acylJKWQZzQedIM4PQ6X4pzNf1+tMRDmGT2samVc+X2BeweAPTT?=
 =?us-ascii?Q?9HtISGg1IvMvM8/fiV/Y0ZO3kAvt5JOtcXoLFj/kv6eLN/7O/YcA4vncGKDJ?=
 =?us-ascii?Q?gBEczklaQ/9GkHX580UxdD7XuLZtBvlVrKLsrVoaEeUrtsT8jLhQOJeJ0KiZ?=
 =?us-ascii?Q?yGJO41l26QyLOSDf7KrIEQftpXkKsgrH5fExgT4GEUVz5Z9mJ1/qpP5+gV+H?=
 =?us-ascii?Q?6C4QxAJNMeTpHdnEKJuJnG8QMq9J5xboFKb80gMDfOZ/n5Df0c6tXe9M5/do?=
 =?us-ascii?Q?XojRuqZDrd0teRXKrnD4a1B4x8gwqFOjqbhkPkc4rLw2IzJnOwW7x9xT5l0k?=
 =?us-ascii?Q?/iR2AEMg0YuPh2VMRjWWVRBwoToCbtj/ZiryH+0LJ8pvaFDLbfyMlJ8DS0by?=
 =?us-ascii?Q?teUKux4xm7GgzutKqNTf2PRLSN1eDs1v4P6TXUBHnnr5CfFegXQd0hvSPLRL?=
 =?us-ascii?Q?VwVIFeg5mNXCUG5B0A4tYFQvAziYBpPaIm9TgdXQe3U37H0lbIWzk6AjJ90A?=
 =?us-ascii?Q?mtQfAoZ3mcADkpr2c7gVcNykAS6SGjsDrr59Brd3DQBb0/IrEPNCiA=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(14060799003)(36860700013)(1800799024)(376014)(82310400026)(35042699022);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 08:27:11.0327
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 915e162f-5d36-40e2-9edc-08dd1f3dc4bc
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB3PEPF00008859.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB10170

Hi Ayan,

> On 12 Dec 2024, at 20:03, Ayan Kumar Halder  w=
rote:
>=20
> From: Michal Orzel 
>=20
> Add requirements for dom0less domain creation.
>=20
> Signed-off-by: Michal Orzel 
> Signed-off-by: Ayan Kumar Halder 
> ---
> Changes from v1 :-
>=20
> 1. As the dom0less domain creation requirements specifies the dt properti=
es
> for creating domains, it has been moved to product requirements. Product
> requirements define the interface Xen exposes to other domains.
>=20
> 2. For the requirements which introduces new terms (like grant table, etc=
), I
> have provided the definition as part of the comments.
>=20
> 3. Introduced new market requirements to specify that Xen can assign iome=
m and
> irqs to domains.
>=20
> 4. The design requirements will be added later.
>=20
> docs/fusa/reqs/market-reqs/reqs.rst        |  16 ++
> docs/fusa/reqs/product-reqs/arm64/reqs.rst | 306 +++++++++++++++++++++
> 2 files changed, 322 insertions(+)
>=20
> diff --git a/docs/fusa/reqs/market-reqs/reqs.rst b/docs/fusa/reqs/market-=
reqs/reqs.rst
> index f456788d96..47e1b6ad61 100644
> --- a/docs/fusa/reqs/market-reqs/reqs.rst
> +++ b/docs/fusa/reqs/market-reqs/reqs.rst
> @@ -47,3 +47,19 @@ Comments:
>=20
> Needs:
>  - XenProd
> +
> +Static VM definition
> +--------------------
> +
> +`XenMkt~static_vm_definition~1`
> +
> +Description:
> +Xen shall support assigning peripherals to various domains.
> +
> +Rationale:
> +
> +Comments:
> +Peripheral implies an iomem (input output memory) and/or interrupts.
> +
> +Needs:
> + - XenProd
> diff --git a/docs/fusa/reqs/product-reqs/arm64/reqs.rst b/docs/fusa/reqs/=
product-reqs/arm64/reqs.rst
> index db91c47a02..66f2978733 100644
> --- a/docs/fusa/reqs/product-reqs/arm64/reqs.rst
> +++ b/docs/fusa/reqs/product-reqs/arm64/reqs.rst
> @@ -40,3 +40,309 @@ Covers:
>=20
> Needs:
>  - XenSwdgn
> +
> +Linux kernel image
> +------------------
> +
> +`XenProd~linux_kernel_image~1`
> +
> +Description:
> +Xen shall create a domain with a Arm64 Linux kernel image [1].

This shall be rephrased to mention that it shall be a binary with a header =
compliant with the Linux kernel image format.
We do not want to say that we can only boot Linux.

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Gzip Linux kernel image
> +-----------------------
> +
> +`XenProd~linux_kernel_gzip_image~1`
> +
> +Description:
> +Xen shall create a domain with a Arm64 Gzip compressed Linux kernel imag=
e.

Ditto.

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Kernel with uImage header
> +-------------------------
> +
> +`XenProd~kernel_uimage~1`
> +
> +Description:
> +Xen shall create a domain with a kernel containing uImage header [2].

I would remove kernel and say binary executable and add compatible or somet=
hing like that.

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Gzip kernel with uImage header
> +------------------------------
> +
> +`XenSwdgn~arm64_gzip_kernel_uimage~1`
> +
> +Description:
> +Xen shall create a domain with a Gzip compressed kernel containing uImag=
e
> +header [2].

Same

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Kernel command line arguments
> +-----------------------------
> +
> +`XenSwdgn~kernel_cmd_line_args~1`
> +
> +Description:
> +Xen shall pass kernel command line arguments to a domain.

I am a bit wondering if this one and the following are not a bit to generic=
.
Should we say through DT or ACPI header for example ?

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Ramdisk
> +-------
> +
> +`XenSwdgn~ramdisk~1`
> +
> +Description:
> +Xen shall provide initial ramdisk to a domain.

This should be mentioning that it is provided in memory and the address is =
provided through DT.

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Memory
> +------
> +
> +`XenSwdgn~memory~1`
> +
> +Description:
> +Xen shall create a domain with specified amount of memory.

I am missing the where this is specified here ? i guess this is also DT

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +vCPUs
> +-----
> +
> +`XenSwdgn~vcpus~1`
> +
> +Description:
> +Xen shall create a domain with a number of virtual CPUs.

number here is unprecise

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Credit2 CPU pool scheduler
> +--------------------------
> +
> +`XenSwdgn~credit2_cpu_pool_scheduler~1`
> +
> +Description:
> +Xen shall assign a Credit2 CPU pool scheduler [3] to a domain.

What is Credit2 ? this needs to be defined somewhere and in fact it
shall have product level requirements.

> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +NUL CPU pool scheduler
> +----------------------
> +
> +`XenSwdgn~nul_cpu_pool_scheduler~1`
> +
> +Description:
> +Xen shall assign a NUL CPU pool scheduler to a domain.

Same

> +
> +Rationale:
> +
> +Comments:
> +A NUL CPU pool scheduler maps a virtual cpu to a unique physical cpu.

This is a product requirement saying that Xen shall have a scheduler with s=
uch characteristics
and I think this is not enough to define it.

> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +SPIs
> +----
> +
> +`XenSwdgn~spis~1`
> +
> +Description:
> +Xen shall allocate a specified number of shared peripheral interrupts fo=
r a
> +domain.

This is very ambiguous. What do you mean here ?

> +
> +Rationale:
> +
> +Comments:
> +A shared peripheral interrupt is an interrupt generated by a peripheral =
that is
> +accessible across all the cpu cores.
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> + - `XenMkt~static_vm_definition~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Grant table frames
> +------------------
> +
> +`XenSwdgn~grant_table_frames~1`
> +
> +Description:
> +Xen shall create a domain with a specified number of grant table frames.

It is really weird to say that Xen shall create something specific without =
this being
linked to an higher level definition of the goal.

> +
> +Rationale:
> +
> +Comments:
> +Grant tables are a mechanism for sharing and transferring frames (memory=
 buffers)
> +between domains.
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Grant maptrack frames
> +---------------------
> +
> +`XenSwdgn~grant_maptrack_frames~1`
> +
> +Description:
> +Xen shall create a domain with a specified number of grant maptrack fram=
es.

Why is this needed ? what is the high level req for this ?

> +
> +Rationale:
> +
> +Comments:
> +Maptrack frame is the metadata for tracking the memory mapped into a dom=
ain.
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Virtual PL011
> +-------------
> +
> +`XenProd~virtual_pl011~1`
> +
> +Description:
> +Xen shall provide an "Arm PL011 UART" compliant device to the domains.
> +
> +Rationale:
> +
> +Comments:
> +
> +Covers:
> + - `XenMkt~run_arm64_domains~1`
> + - `XenMkt~provide_console_domains~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Assign iomem
> +------------
> +
> +`XenProd~assign_iomem~1`
> +
> +Description:
> +Xen shall support assigning iomem to a domain.
> +
> +Rationale:
> +
> +Comments:
> +
> +Rationale:
> +
> +Covers:
> + - `XenMkt~static_vm_definition~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +Forward interrupts
> +------------------
> +
> +`XenProd~forward_irqs~1`
> +
> +Description:
> +Xen shall support forwarding interrupts to a domain.
> +
> +Rationale:
> +
> +Comments:
> +
> +Rationale:
> +
> +Covers:
> + - `XenMkt~static_vm_definition~1`
> +
> +Needs:
> + - XenSwdgn
> +
> +| [1] https://github.com/torvalds/linux/blob/master/Documentation/arch/a=
rm64/booting.rst
> +| [2] https://source.denx.de/u-boot/u-boot/-/blob/master/include/image.h=
#L315
> +| [3] https://xenbits.xenproject.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3Ddo=
cs/features/sched_credit2.pandoc
> --=20
> 2.25.1
>=20



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 09:05:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 09:05:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860033.1272100 (Exim 4.92)
	(envelope-from )
	id 1tNpzA-0003VW-FE; Wed, 18 Dec 2024 09:04:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860033.1272100; Wed, 18 Dec 2024 09: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 1tNpzA-0003VP-BJ; Wed, 18 Dec 2024 09:04:52 +0000
Received: by outflank-mailman (input) for mailman id 860033;
 Wed, 18 Dec 2024 09: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 1tNpz8-0003VJ-RG
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 09:04:50 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 (mail-am6eur05on20607.outbound.protection.outlook.com
 [2a01:111:f403:2612::607])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 221edbd7-bd1f-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 10:04:48 +0100 (CET)
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11)
 by DB3PR0302MB8989.eurprd03.prod.outlook.com (2603:10a6:10:433::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Wed, 18 Dec
 2024 09:04:45 +0000
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::baa9:29b3:908:ed7d]) by AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::baa9:29b3:908:ed7d%4]) with mapi id 15.20.8251.008; Wed, 18 Dec 2024
 09:04:45 +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: 221edbd7-bd1f-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CxqLOaWRt4Z3dLzjIX16zByUcSBt7/4f2jQX4pd0lx4J4JnJCWL3ufgFAxMyTY67r/mAddXab0tcDo7TXz0uq1Pr280WzUepOMB3d9taBU3pWQuvkbRLlNvD5T5THlDxD3RigLR0iinNNeD4u9ACr5uVYiH4ztjz6SpCEL2xrgQRO0c4F+FGOT1G2FW+gWnXscBIV3YP7A7NrAEHuVlT1Z+hQGr5H6ksJDaOqccGYIzyM7mLvLdTpcznz6PdvMnY0XBrsBC95CByRVNuNtbSmF/p+JLxZ4bHFJXvBZbY39cwSojHDY3j7xRio5wASo4IO0HiTBdhriZpFKxLa740+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=joj87V4dVBXCPzIgqm8KkspSGXIaqaxBIO9gnzwpP2A=;
 b=p421KYIr44nUGqOpOZPyOCuvk1LKvSBHnhhGVb010c26PC9mP5PhyeYShERQ5AwR3ooIBeUyAk13YOL30TP+5rgnw39105DGeRm+Bw14OwqP3M8pCSu3qHzo/ZvPnpyhDmETG9i89vzvGn8rhsxjlWbyUS08otPeOqHCHOjAjwum7wa/jU5Ed3FpxMCRRARJLXY4Lmg58LG4tTWYVWtmy0lqCZZqELuuDXWP0s6lSZf8hgFtNajSj4gWJvZnHgRX89VqlzZnNywefNvEIfMoOVLxZY+duMtD8PSEhnsi+wrV/swzm7M8VlTGF4hGibcCCp08vDjUlTPQbnUGtLZomQ==
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=joj87V4dVBXCPzIgqm8KkspSGXIaqaxBIO9gnzwpP2A=;
 b=tn5OUB/Dwuqr4pOJRo5mSlHH4vvdPSBJrbd7KFbG+rS8VLanNfhr1hrU/jRLZ9UbJz2NRpEB3s3KDBn1WxL/jPnVikX+NtxQBTfwpiPkk/IqUrYew7W5Y3J0q4DAg35vxBgBHy3ExJ1DFpYOgw39ef/xrn9wuiQWGmiB7yoxmw0ZlzBqNUil09RhalrknwPIokF/bCLJgBZvq3cI1nJF9NeF8zRe6lXfU6egOhSGaHeb23/kSrV2IC/DKSwHcdceLTAr6G7lnTt/D1b3Eg5XI07WMgS3ITb+F2KDrBXGErYerjQoGE32wzvHqdkqN/fg2p93Gv56xOXKp4XHnUaf+g==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: 
Date: Wed, 18 Dec 2024 11:04:43 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v1] arm: introduce kconfig options to disable
 hypercalls
To: Jan Beulich 
Cc: Stefano Stabellini ,
 Julien Grall , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini , xen-devel@lists.xenproject.org
References: <20241216114358.2845447-1-Sergiy_Kibrik@epam.com>
 <4ef8626a-0ff9-4c02-a1bf-72e39b950e8a@suse.com>
Content-Language: en-US
From: Sergiy Kibrik 
In-Reply-To: <4ef8626a-0ff9-4c02-a1bf-72e39b950e8a@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: WA0P291CA0016.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::28) To AS8PR03MB9192.eurprd03.prod.outlook.com
 (2603:10a6:20b:5c0::11)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9192:EE_|DB3PR0302MB8989:EE_
X-MS-Office365-Filtering-Correlation-Id: 520bc497-f026-4cfb-9943-08dd1f430472
X-LD-Processed: b41b72d0-4e9f-4c26-8a69-f949f367c91d,ExtAddr
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|7416014|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?UXpraHo0QWdQRDF2WitELzBSM0ViZ3NDekF0dmxGemZEbG1GTFpIbE5UeWFz?=
 =?utf-8?B?dVp0T25kYnNMZUw2bUVmQmgyRSsvd1V0WHZuU0FBZXZSTkhkVkFUTktVN1pY?=
 =?utf-8?B?dWF5SnpTNUdUbVhNN3FPMHZxTU5WeGw5ejM2SnplUlltN2p4bTRObWxKT1Z1?=
 =?utf-8?B?aS9IemdET0h3K2dWczJzRzRsN3prdzJxWGU2ZXdld0J2d3JJRkQyZ0pxb2dw?=
 =?utf-8?B?S25HUU5WZG42TjJ4K0FoaFZKUDU3NTlEN21xN3Y4dUhDMEg4Qi95R29kRmZL?=
 =?utf-8?B?RXB0aVJCdlljWGJiREprOTJIUmkxOE5GMVVLVkx0emdWMGhFR2FQUlcrRjU5?=
 =?utf-8?B?UXVIQlgzMkIrV1F5Tm4rSGdKMi96ZTgySms4cFU2eGpoQjdWQlA3NUFPU214?=
 =?utf-8?B?eVFDRmQ5b1o3cGF2eFBocnd1dldGWXdVNitITDkxRjBPV3owMkNORTZUbFNS?=
 =?utf-8?B?eVhtMkg2cWtxR1hPVkhDaTZrd2d5b0ptS3puOFpCSHVmN05lWXViWnkyN2VP?=
 =?utf-8?B?KzJmUzRDT0dDb3ZmR2hmNjR3dkJGRGNpMit0cHU0Q2FwZ2IzZk03cG1JQlFv?=
 =?utf-8?B?T3R6ZVIyTjBzeHNVaThpRWNMaGtmc0NpKyt0NXJxdDczd0hRcGFxdFdJMi9j?=
 =?utf-8?B?WERxOGxvNjc3SCtodkRJZktyMTN3eHZ6RkNqR01uaVJlWnMwOE1wRzlSb094?=
 =?utf-8?B?NmJ6TE45OEx5dzZEOUxlbXEvRy9Gd2FYZng1QWlkVXYxb1Zyc3dWRDlXK2xw?=
 =?utf-8?B?Rm16ei90cjJKZitMMjBMTGlsUHlqbDgza0RxWEJ2Mk9JUmFSdEtZeklIYjBq?=
 =?utf-8?B?QUU3c1N4cHdmTDgyRElkSmhIOEorWFRLT3ZaQnJGZms2UHVEMkZsZmp1RUFr?=
 =?utf-8?B?OTNSYmczY2FkU3JOdWZIRDNLLzdZeFBGQU85SzBTT05QWk55UTZmV01sTG4z?=
 =?utf-8?B?N0NNVVJPNGM3cXFhaEI3TFpXWGF2UGtXZWIyUmpLUVE5YzlRMkpDYlp5d1Fq?=
 =?utf-8?B?MFZmbG8wVklGSi9EZlZlV1hwOHAzYXFmQUVveExKTEFJbTJ0R28xNTlPbVlF?=
 =?utf-8?B?VWZxaks1V1RSNVIweDExcU9BaUxtZVlvRFVuZlBUQmFtRDA2aTVDWTlrNHFv?=
 =?utf-8?B?RnB2WXVNaGxCSCs2WnpkczFPM1BxRFRBZnE5OWdHaXZ0RVZCQ0orWXE1QWQ1?=
 =?utf-8?B?d2xpK3JFV2ZINmRHNmw3NzhkYVF0alFJYzY3RFFGbXorNUcvd24raklETFAy?=
 =?utf-8?B?SU8vZzhKOWFNdkVFcHpkNGprSmxIaG5JNktRcGduWkVScEJnVms5eEtCV3RK?=
 =?utf-8?B?Ky9NMVUzMDlib0pWRDFmaVVCK2lxOTAva2FScllLWnE0bUk4N0hxeWZFTkZV?=
 =?utf-8?B?UGlFV2F6eVZJRXJoMGlOYmJCSGJEMFJ3SEpDRDl4WU9WWEs5RXBweXYrUkp2?=
 =?utf-8?B?ZitsTEdMVHpnTWhEb1B1ZzBpQXdocTNCVVlZNnQyK3hKcnEzakxUblo2eFZ0?=
 =?utf-8?B?WmxleGtaaFRpdndRcmFlbFNRd0pmaHp2UHczNnlDaTM4Z0g2ODlneCttVkp0?=
 =?utf-8?B?RWVsMG1kVXJpa2xoVU14bVczblVydGM1MHg3WTdyQUh5YzdUZklPUnJjajVI?=
 =?utf-8?B?UGM5ZnM3WWtJZkxFclFJQ2FLbnN1Vnl2Wm12ck9kMHJkZXpHaDhRZjdTQzBZ?=
 =?utf-8?B?WklyNkNLR2lRbmk3T1NkK1htZ0FTWmNObnBnWDhhMTd4YnRoTFN3bi9pa2hG?=
 =?utf-8?B?aU9VSEVLZVNXQTdlZngwbEFzTHZ6WGZJS2czOEYvM2gyTnRweHBhcVhyZ2s0?=
 =?utf-8?B?VEF2Mjk2M3ltTXlMWVB1MHJhL0FFY3FibjU4TVZCWDNTT3VNTERKQ0RCL09i?=
 =?utf-8?Q?NleE+tvA3QCKq?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9192.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(376014)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?aHhUc1QrZDFKUnJQeGhwZGNwK2N3b0tyR2RFdjB2dTRIRHN3VlV4cjFsdVZL?=
 =?utf-8?B?TWJKK00yN3VDMEc1TStqTWFxMDVUM0lWS1J4STZRTmxuMjVlTTVJK0YvS0pZ?=
 =?utf-8?B?TFZTTm1PWFRxcDI1c3hhNFdDcHl0Z1Z1OE1xVWgzaXhpK3FhUW50VlhFaDQ5?=
 =?utf-8?B?WlNybEZ3Q1NJeDh4eGdVdklWc1hRazdIYUgwVWtDQ0wyazlhTDFwKzBoSGtI?=
 =?utf-8?B?aHduQVJSb0hQNHBJTFhzb3NXQ3JIazdleGVtYkZ5bVg0SjZOWEdha1dWUSt0?=
 =?utf-8?B?aVNJT3FGSTVDdm04eEw1TmRhRXNsQ3Y4S2Vyd2NzMTdmUTFrRlYvdE13UVBL?=
 =?utf-8?B?MVFCOVJ1UE54ZVRkNVh6WmlpZ255VGZ2V2JjeEw0d0pEYnlzQlMwbjBLOVU5?=
 =?utf-8?B?dk5zdURsSmFuYzZ0TDNNbVRhdDlqbDZDQmFuRUt1TEs0clVmVFZvbCtTSzFO?=
 =?utf-8?B?SXljcUVPd2FDaitPazZLNm9pU2RVc1N1VElMRVNGdVVHcVlOb3ZCUERFSkpH?=
 =?utf-8?B?cWFtQkxMQWd1QW9EM1RleG5RakVjUEljejErVjRjMWdvY2x6bEtwZkhKUjJs?=
 =?utf-8?B?bnV3cktGUWUxTVNHb2hUV21NSFEvdS9WaVViWGliZmZaaFozZUF5RW9wV0Rk?=
 =?utf-8?B?MGxpYzE5UElzNHBsRGEzcHllSmR0VzI0TGY4UmdFNlNQQ3ZaYUFqS2pYQjVw?=
 =?utf-8?B?d0RPNmcwcm1jWE5pTzY3MGpUMFZZZDJReHZwYk9lb1d1L1A5bEhQNm9xU0NV?=
 =?utf-8?B?U1J6Y3lHb0RJemV4YVNXQm5pZm82TTJPK3RjRXRISmFuY0l0bXlsN0pObFpC?=
 =?utf-8?B?TXA3N0xITm9qbFFIY1RCQjZkbXByRHltT2Y2T0c3ZnJQbklCOUZMVFdHMnFh?=
 =?utf-8?B?UFRHc3VPRnJMSmF2LythTHE5UUplaHFOU0dxTnVGdFllOVZRUTR3NlN6WGJ5?=
 =?utf-8?B?U1dRTEo1c0hFVDNTbW1RTjgwbXZ1TG05QUJHVHpKME9salh1VGovdm5EUkRu?=
 =?utf-8?B?d2ExdkFkVjZjMEtRR1BxdnhjMU4zUWdQNzhid2VvS0VtaXFobnlzdHN4U1hl?=
 =?utf-8?B?YWdsR2tsNUYzWjJiTGtsNE1WSjhrK3hxY2pRNzRJR1J5SHpoTWhMaGc5OVlD?=
 =?utf-8?B?c0x6QVdHNnNERW9FY1AvNnlMS0tVeFVKWlkzSVhBdkhoS3lGSmQ5eEF1ZDIw?=
 =?utf-8?B?MGEwYTJDbU5mOVY2K29VNVg1cFNSTnhadzdjd04wYUNXS3pHNk44UmVxR1V0?=
 =?utf-8?B?NzNwTGU3NWRyNHNwWWczcldLcjlWRW9NWmY2dlZVUjRxR2UwcSsvK3NsYXhY?=
 =?utf-8?B?V0VINU1rVUhMUUZSVzlaU2tvaWNCTjc4UXVRcWpETzlZN3FCSVlhWUxseEtC?=
 =?utf-8?B?T2lxYTJrS2RIU0loSWN4QzF2UEp6QWVWV0hGZEtMbXVDejVMeUNJWlBtWjhV?=
 =?utf-8?B?bnpWNUF1TjlNcm9HWVZQVGc0K3Fvem9oN0VWRDBIOVpYT2d5SXd1TG9wV3Yx?=
 =?utf-8?B?VjI0WldHeW5rT24zVFFwbk1ITzc1c2ROQllncEF6Y1pWVlE1d0s0eElXVHE5?=
 =?utf-8?B?dUcyYjM2cmtENGV2S2t3VDZYd3FMd0drRjc4cEJEMGZMREg0ejNpbEUvZVhI?=
 =?utf-8?B?VVRPWVdBeWJOWEVRYjl0Vm5xWXRSVEh2NXp3SG8zN3ZHSUEzM251RFNCQjJk?=
 =?utf-8?B?VS8zakxMaSswZVJFRzE0cmxjdDlubGpDQm1nbGFiYm5xdlYrNURRWThxZlRL?=
 =?utf-8?B?V2U2aFgwZTI2c1hYc3V5RHNHaEpBeCtJaTJJQm1qeWpuUkp4dmJ4TVVpVjBW?=
 =?utf-8?B?NDhrNHdHeEExWkR4dXlDYjhKMFFJcTBEMWYrL1AxRkZybEZick12UTV6WTZx?=
 =?utf-8?B?MU11ejh6b2xESXVNeDJvdXMxdk52UmtqQVR5MVp5VklCM3pYOVRMK0kvTEFS?=
 =?utf-8?B?SUUxUWErN2ZlOFpVVkczTzdQVi9OS0lEUlBtQXBZZzdWRjhycmtYdkFFekl1?=
 =?utf-8?B?cFJoS241ekxRWlFlc1R3bGt4NTJIck5KdmgxWGNQY01lSHJzNmdlM1dlNE9r?=
 =?utf-8?B?ZGJEWG9uNVJ6Y213dUl3WFNGeFg1NExoSENXN0Y5NzU0WVdZZldaZE53ekRW?=
 =?utf-8?B?Wkx6Zk5RQWQ2eE5BV0N0MG1YbmN4RmpOTlNxaU5tWXY3RzlIMmhuZnBGZ2Nr?=
 =?utf-8?B?aVE9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 520bc497-f026-4cfb-9943-08dd1f430472
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9192.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 09:04:45.6264
 (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: wUay183UgEkbKefvOjo2Q3MguKN6/E2qRwBQmICL0j2ZSiUlCBhY5oRuz+3dW0bWzwh61g0P8I8E5bA8htrthw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0302MB8989

17.12.24 15:00, Jan Beulich:
> On 16.12.2024 12:43, Sergiy Kibrik wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -516,4 +516,31 @@ config TRACEBUFFER
>>   	  to be collected at run time for debugging or performance analysis.
>>   	  Memory and execution overhead when not active is minimal.
>>   
>> +menu "Supported hypercall interfaces"
>> +	visible if DOM0LESS_BOOT && EXPERT
>> +
>> +config SYSCTL
>> +	bool "Enable sysctl hypercall"
>> +	default y
>> +
>> +config DOMCTL
>> +	bool "Enable domctl hypercalls"
>> +	default y
>> +
>> +config HVM_OP
>> +	bool "Enable HVM hypercalls"
>> +	depends on HVM
>> +	default y
>> +
>> +config PLATFORM_HYP
>> +	bool "Enable platform hypercalls"
>> +	depends on !PV_SHIM_EXCLUSIVE
> 
> Any reason you don't do the shim related conversion also for domctl and
> sysctl?
> 

you're right, I'll do it in v2

> Much like you have HVM_OP, may I suggest PLATFORM_OP here and ...
> 
>> +	default y
>> +
>> +config PHYSDEVOP
>> +	bool "Enable physdev hypercall"
>> +	default y
> 
> ... PHYSDEV_OP here?
> 

yes, sure

>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -1053,7 +1053,9 @@ int domain_kill(struct domain *d)
>>           d->is_dying = DOMDYING_dying;
>>           rspin_barrier(&d->domain_lock);
>>           argo_destroy(d);
>> +#ifdef CONFIG_DOMCTL
>>           vnuma_destroy(d->vnuma);
>> +#endif
> 
> There is a stub already for this, just that right now it's shim-specific.
> >> --- a/xen/include/hypercall-defs.c
>> +++ b/xen/include/hypercall-defs.c
>> @@ -234,7 +234,7 @@ stack_switch                       do:2     do:2     -        -        -
>>   set_callbacks                      compat   do       -        -        -
>>   fpu_taskswitch                     do       do       -        -        -
>>   sched_op_compat                    do       do       -        -        dep
>> -#ifndef CONFIG_PV_SHIM_EXCLUSIVE
>> +#if defined(CONFIG_PLATFORM_HYP)
> 
> Nit: Why not #ifdef, like it was, and like you have it ...
> 
>> @@ -247,7 +247,9 @@ set_timer_op                       compat   do       compat   do       -
>>   event_channel_op_compat            do       do       -        -        dep
>>   xen_version                        do       do       do       do       do
>>   console_io                         do       do       do       do       do
>> +#ifdef CONFIG_PHYSDEV
>>   physdev_op_compat                  compat   do       -        -        dep
>> +#endif
>>   #if defined(CONFIG_GRANT_TABLE)
>>   grant_table_op                     compat   do       hvm      hvm      do
>>   #elif defined(CONFIG_PV_SHIM)
>> @@ -269,14 +271,20 @@ callback_op                        compat   do       -        -        -
>>   xenoprof_op                        compat   do       -        -        -
>>   #endif
>>   event_channel_op                   do       do       do:1     do:1     do:1
>> +#ifdef CONFIG_PHYSDEVOP
>>   physdev_op                         compat   do       hvm      hvm      do_arm
>> -#ifdef CONFIG_HVM
>> +#endif
>> +#ifdef CONFIG_HVM_OP
>>   hvm_op                             do       do       do       do       do
>>   #endif
>>   #ifndef CONFIG_PV_SHIM_EXCLUSIVE
>> +#ifdef CONFIG_SYSCTL
>>   sysctl                             do       do       do       do       do
>> +#endif
>> +#ifdef CONFIG_DOMCTL
>>   domctl                             do       do       do       do       do
>>   #endif
>> +#endif
>>   #ifdef CONFIG_KEXEC
>>   kexec_op                           compat   do       -        -        -
>>   #endif
>> @@ -293,7 +301,9 @@ hypfs_op                           do       do       do       do       do
>>   #endif
>>   mca                                do       do       -        -        -
>>   #ifndef CONFIG_PV_SHIM_EXCLUSIVE
>> +#ifdef CONFIG_DOMCTL
>>   paging_domctl_cont                 do       do       do       do       -
>>   #endif
>> +#endif
> 
> ... everywhere else?
> 

yes, will fix that

>> --- a/xen/include/xen/hypercall.h
>> +++ b/xen/include/xen/hypercall.h
>> @@ -24,6 +24,18 @@
>>   /* Needs to be after asm/hypercall.h. */
>>   #include 
>>   
>> +#if !defined(CONFIG_DOMCTL) && !defined(CONFIG_DOM0LESS_BOOT)
>> +#error "domctl and dom0less can't be disabled simultaneously"
>> +#endif
>> +
>> +#if !defined(CONFIG_PHYSDEVOP) && !defined(CONFIG_DOM0LESS_BOOT)
>> +#error "physdevop and dom0less can't be disabled simultaneously"
>> +#endif
>> +
>> +#if !defined(CONFIG_SYSCTL) && !defined(CONFIG_DOM0LESS_BOOT)
>> +#error "sysctl and dom0less can't be disabled simultaneously"
>> +#endif
> 
> I'm puzzled by this: It covers only 3 of the 5, and it really only
> re-checks what Kconfig already enforces.
> 

At some point I wasn't sure that kconfig will enforce this, because 
somehow I made kconfig produce configuration with both DOMCTL & 
DOM0LESS_BOOT being off. Anyway I can't reproduce it now, so will drop 
these checks in v2.

   -Sergiy


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 09:52:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 09:52:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860051.1272110 (Exim 4.92)
	(envelope-from )
	id 1tNqjE-0001IN-OV; Wed, 18 Dec 2024 09:52:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860051.1272110; Wed, 18 Dec 2024 09:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNqjE-0001IG-Kh; Wed, 18 Dec 2024 09:52:28 +0000
Received: by outflank-mailman (input) for mailman id 860051;
 Wed, 18 Dec 2024 09:52: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 1tNqjD-0001IA-LR
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 09:52:27 +0000
Received: from DB3PR0202CU003.outbound.protection.outlook.com
 (mail-northeuropeazlp170110001.outbound.protection.outlook.com
 [2a01:111:f403:c200::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c953ec6c-bd25-11ef-a0d6-8be0dac302b0;
 Wed, 18 Dec 2024 10:52:26 +0100 (CET)
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11)
 by GV1PR03MB8109.eurprd03.prod.outlook.com (2603:10a6:150:20::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.22; Wed, 18 Dec
 2024 09:52:23 +0000
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::baa9:29b3:908:ed7d]) by AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::baa9:29b3:908:ed7d%4]) with mapi id 15.20.8251.008; Wed, 18 Dec 2024
 09:52: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: c953ec6c-bd25-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=diKTDfMeiy8rqRgVT7q3cAAJp3EsaATU9GJci2GzwiCGL0rVwbsi3y9fFzhzvNOSs2/5Tr2KrbP0JrWwSq8rti5+8HFCYjsGHAztwhnufwS7x5woFvfeF32nmWwK7ev2IcjW+SJgRrI8K4me/dKiJLgCMqwc6+h9HegK2YqFynsRQqmE3+yaXrjOY6VShplKwhxht3qxp1TEJ1X8hQiqRvvObEdf1XPYoc9afi6Yb8wHwav8vuW9u/yF86n/IYoVZ3/etRSseWE/ZpJq7YvpQZR96kGtNyLVDifEXwt5TKRCYgBqEo3xtfoP30TwpKM7gNArcuf8hvhjvpY4mY8gDg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=IagAe6TxTOJFMUV2fa5E6nbHJ1PUjfJ/IsoMgwagsqk=;
 b=i+HGhzi9nJdej/SDqooev1M5cWMVLvuPkwY0+fOTsZY8UOl2is2GQpSbmQnwoUh3YfBrEi7CoxCRTZmfv0K58c4XgDdQVurShERPH3vNnpgWUkf/VI9O2BGQf98k9WsvyDQBwqH1wi2ZPzo9J4JWNNNC+lU+2q4w3HK3grxmZ9tU2BTh8PBGvfTssStq0xQ42zw3bSQlumgFPUoonE0JOIL1Tss4UOIKxFJhGqCgh4Juu5DzrBdLdfMJef+50MR4IMYZi2Imh+hT5s5oo1zA6JeklvBNv/yskp24Iti3EI5AA2KipCp/efDQV6j+2I/fx3C2ynNlElOIK54TgCpqJg==
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=IagAe6TxTOJFMUV2fa5E6nbHJ1PUjfJ/IsoMgwagsqk=;
 b=vLTVZ5QxY3e537FUWS/osqj0+prW/ULm7Kt+RdY2DZnSgaUIo0ccRVAV+zEGRf1N2WnPpE7OcGXWzF0em65W4otwRsSuifZFdZ35xWE9w1NpQBDMjz1sO2k7hdD3Dg+XIfZDf4mLkYsM2+6v5DaTx0JvABMb8AdzKR6LVxu2jBb/dxATC/nTU3RZtmDIjQe8rY2RtMq54eQlZHsXTXjE2ETneZjON+6n18v94oRI0P8ifbveR1b6Xw1Bcal5YKvV+xxkkHmJrvVqUulJytPhYKXZzZzNaxm49aqG7ojjlPPNElpLIV3xrNhzAd1IR+1+PFdnY+BkDDkRyGecgOLFjg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <5246aa98-d23c-41d5-ba14-c12b0a2ee9af@epam.com>
Date: Wed, 18 Dec 2024 11:52:21 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
To: Julien Grall , xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 "Daniel P. Smith" 
References: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
 <4e437c60-4fee-40ed-9d2a-789bac0b36d9@xen.org>
Content-Language: en-US
From: Sergiy Kibrik 
In-Reply-To: <4e437c60-4fee-40ed-9d2a-789bac0b36d9@xen.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: WA0P291CA0014.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::19) To AS8PR03MB9192.eurprd03.prod.outlook.com
 (2603:10a6:20b:5c0::11)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9192:EE_|GV1PR03MB8109:EE_
X-MS-Office365-Filtering-Correlation-Id: bdf0237e-3cf6-44ec-1a40-08dd1f49abe6
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:
	=?utf-8?B?SmlhZU42WVZmdnQyeE9FM3U1VTRFR214eWxrOHRKVGZPMGNDdWYxdG5IZE9O?=
 =?utf-8?B?LzQyWVA4TFFxaUNwZlladytuRnA1VFdZaUN3WnhFZGNtTkxFSVVPQU4wYzA4?=
 =?utf-8?B?b1RNV3pna0kvRGVuOTBhb3ZkS2lCRE5sdVcvWldZcDdxK000V1dwY1RPTUJJ?=
 =?utf-8?B?RDNVL0xka3o2cDZGY25iQm9MdTE5Wnp4WTlwdUdtUm1kV0V5ZDJkZExsb05y?=
 =?utf-8?B?MWhhaFBDdHNEQzJ0YlpidGcrbDVBdGRGTHg5clk5MWVCOEtqZlRHcC82MlRY?=
 =?utf-8?B?YzdNa1kyNGFvSFdRV3lYN1BRcW5FV1pzQ0F3RTMxZG0yWTN1UFZsT25xOGV0?=
 =?utf-8?B?VFFzUnpNanlaeDZzcGM3VnVaZnZkaURCWi9LaXhQMGNTY3ZGUEJTUDF4QUwr?=
 =?utf-8?B?WCtRSElOQmw0SlNaMTJyOWQxUjFSVFpwWFNDNllnQXh2T2hSK1hTU29RWEYz?=
 =?utf-8?B?NkVwcUJKaUJlRlc1SURadGhoQnE5a1hXV0JROVVpTlZzNGhMSnRRcGZ2M0ZI?=
 =?utf-8?B?TG93b05HWTZCS09ibW5JT2psSXYwSjJzQWovY0luUE05VjlZUDFtcmFBWXM5?=
 =?utf-8?B?dTk3Nk8xZGVBcE5tRENKSHNzc0F1ZFF6WGlwbVBYclYyZWNNeXVTSHhuTU12?=
 =?utf-8?B?Q1dGUjFsWjU3Z1ljd0VEUG4rc1g2cS9hbGV3V2tZaHpKQnBBNkRrT3ppVEhr?=
 =?utf-8?B?Z3B0YUZTNzg2ZW5kdzRHbjVmUU9BME93Sit0Z3FtYyt6WURKQ1U2dm03d1Nq?=
 =?utf-8?B?OExlNVRwM1h4THNQKzE5RCtzMnZaUkZvWDVJNUFHb2Y4RDUvWHdlQlpndmhi?=
 =?utf-8?B?YU5XTXNuSFVNOUk4bkhIblZTUFpNYjZmc0NuRW1Ea01CL2E3N1RoTGFrKzlV?=
 =?utf-8?B?cEo2ZFFGTmhwbVB6R3V2TEExUXpoVXRnSEExNDFiUlI1VzA0aXVZaXIwaHBK?=
 =?utf-8?B?ZytHZ1A5VE1SNzA3K25pYlpKOWVYMmY1czF2eWVnRHVXOWNMME9obFEyWWlO?=
 =?utf-8?B?SmZVSGVvWXlpRWJsbllGRndpRXZsRUJoR3Zob1VBcHJORjlFclpkUlg1ZVpH?=
 =?utf-8?B?Y2hNdEZNbzVsbEwwQjU5b3RRcjFnYi9odmlYSURIdXE4cFZrbkdrL042V0hu?=
 =?utf-8?B?SzBIZmxDaGRxcUpqTHdjb0s0VlRhMnJjdUc2QURDSncrZlRtS0tqWFZoczFo?=
 =?utf-8?B?QWlaV3BwUEZMVG9aU0traW5VWGVuaWZadDlJQU5wdEMxV2k0b3dWdEpMejVM?=
 =?utf-8?B?emZselkrWFpEdnVoYlBsdFVyV0dGRkhOS2dnL2U0cGhJc05yR0J4M04vL1lm?=
 =?utf-8?B?MUpOKzAzRHVyd2VVa1dTYzNQaHRRbXoxekszNjkrN2IxZ3UvaU1uOTVjME5N?=
 =?utf-8?B?a3IyRFFPYlBKVlk5LzFZRDZyTWpRSi9RdkY2UHMyZG9JOUxwaSt1RWhLQ2g0?=
 =?utf-8?B?dmJjYzdSU1NoWHpOUFdhNVVmTTB3Rmd6dGcrR0RWOTNYeGVIWExxSmZ1eHFm?=
 =?utf-8?B?THVESm1uS1Q1ZEdzeEpVMUFzY0wxTVpDODV1RGE0MmpoVjU4cnh0SWpYTmdO?=
 =?utf-8?B?b0ZEODFiaFovS1Y1OS9pbFMyTERNVER1NFNRN3EwcFVGV3E0dmtxSWFDR3FU?=
 =?utf-8?B?Rk01QkFFTW5Fd2o0SXovMnRaNk5ZRGJ6VzkvWFZ2T1p1TGIxdS9NRHh5OEdy?=
 =?utf-8?B?SXN4Rk8xU1ZmOEtkNkpDekQwektEWDlpSGhHRnFsRktLc2FsWmE0N2ZjOUNP?=
 =?utf-8?B?ZTl0T1g0THpRV3JnMVc1UUtqaWlOTGFzRStaMkx5NzZYOG5CYnJuQmc4OUgx?=
 =?utf-8?B?bklPSkRPZ3NRQ2NlN1RqcnIwdXVyWVB0MW1XTHFVQ0VCUnVHNU5DWTJDaWxp?=
 =?utf-8?Q?gFeCkws3oeqG0?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9192.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?cXdHRkp4SzRJWDAzbnovNEE5UXRibWZmeTBUV0VaMTUrZ2VZZGV1Vi9FUGRU?=
 =?utf-8?B?OTBsVFdUWU92NEoxNTY5anN3SUJaSVJ3SC8zMVdyb1M3dVNjZUNPeUxnemxv?=
 =?utf-8?B?b2djQ08xUVk3eFBEcVBWS1EvOERSTFp0cGN5SHFqMlRqZ3dTUGtaN0U3b0Rm?=
 =?utf-8?B?Z1EwYmNOU2ovMHh2blhINWFTbjk2TGVxV3RKcHVlUWNKNFZFbmxIblpmMlR3?=
 =?utf-8?B?UFZ1QUQvOVBwM1dLTjZTdGR2blhva1p1YzBYelBNcDJkZFhhU3NncGVGNzdT?=
 =?utf-8?B?RHNWWGJRQ0M0MlpnTE5KM3BvdFhUOTk3MlQ5S0g2NFRnLy9iMzJEZGs5bmhw?=
 =?utf-8?B?WGhyUFZRZGZwS2hPc2xyS2ZwMXlxOGpCL2o5bitVV3hpcEcxQStQSXRHZGt5?=
 =?utf-8?B?ZlNnbVNsbTNpcEVrMEwxQytrT0h0ODhaREp5Q25XWlYvMVRTWjliaHUybENL?=
 =?utf-8?B?T2gramR3ejZaaVJ2STl5aE41aUhyenFNdklrV0k5Ry9VSHlKSzl6QVRubVFN?=
 =?utf-8?B?ZzlWM010WEs1ZGNZSzI2MW13T2xrVFVHaVh0OE0yUGFiRThUOCttYmV4MCtG?=
 =?utf-8?B?ZTZsZFV4R0JqR2Ezdk9PV1pHckY3UmIrYnJjV1ZaYVhHOWJWaTRXNHU0RXZs?=
 =?utf-8?B?MjFaL0kyOVVseDRnZWt1ejJjMU94U2RXRVhvTzcwZzUySXJwdWYxbXVKVkxl?=
 =?utf-8?B?aGVWK2g2clRWSzFFZ09LNDdjMjZUbW5wTGpUZkt1elJsK0RwSC9nVWVxSHd2?=
 =?utf-8?B?UEtmZVJwRTN4aWZMeXJKOXhhWCsyYllvRDh0ZEovZVYyVm5DRmp6UXViY0p0?=
 =?utf-8?B?ZHkydUxzTUR3byttR2pWMFByQWF3d3NWdllmdEtQNlZRVDYyd091SVhHSzNi?=
 =?utf-8?B?WFFITitiME9ZL0Z0bzhJNmtXMDgzQmJKWXJBOFMvbEs0c2ZqN25odFNLUjRu?=
 =?utf-8?B?SGVreEg1TFR4bVRuM2lkL1RmZTRja2Z2eC8rTkM0UEk1SzNtcm9IcDJoTm8w?=
 =?utf-8?B?Z2pKQjNONWJLSEM0dTNWc0R0YmFQZis5M1NGZjZNK0x4MUlxSWpDNlp4Znpo?=
 =?utf-8?B?U01EVEpQV29UanZ1U1NsSjZrYmRTMWh2R0c3dTBEc3E3citXZzlzcXJyeTNa?=
 =?utf-8?B?L0NMNFczSUtpMTgzSjJsL0FEclVGL3VNamNpUWFjV2xuUElvOHVCbnpsVmF4?=
 =?utf-8?B?SzVjNmJmRWx4UmZqSnp1MlBnYlpaZDFTMGozS3FDK1Rubm8xTDYvWEl1UklF?=
 =?utf-8?B?ZjBOY09ySzl1Zm8xWHZGZmhlQVpadHozMXd2SFE4SVViU2Jrd28xeVFRVVJv?=
 =?utf-8?B?cFJha3JnSGl6VmhoMGlaUkpTQ2t0Q2VhcFBSNUJnakRGVG5nOE0zaTR6c2hL?=
 =?utf-8?B?QXVZMUJYUE8zY1F1N3ZXc1ZlYVJJc3Q1ZFhTelFiQ0dYN1M1MjZ2RVg5TGd6?=
 =?utf-8?B?OVNrV1pqaVA5RGxuU2ltRUFHSzBTZERjd1pueEhRdlJZeVJzNW1TdVovSzFl?=
 =?utf-8?B?b1NBNmU5SStQdnhEamQ2U1V6UkVuUjBPRkh6bVlEMUdtOXVOdkN0d3lqeEhR?=
 =?utf-8?B?OXhMTkJmT0tOWXFHRHZ3VTQwRHV5eEZpeHBmNXJCbnJ1TEdCblZYREYwWExE?=
 =?utf-8?B?b2VOY3YvQk9rKzdyWWlTbndjRUJKZm44S3NMQzF3NEMzNHA5eTVHL1V2WEpW?=
 =?utf-8?B?d0VrZVBROXIrenFaV2Q0SWdGMktYNXUxZVdTb09WM0N1dlF6WWJtbkFPam1u?=
 =?utf-8?B?V2NLODlFM3V5aWlDU294c0VuTHNaaHhVT0IzL0dVcTYyNmZtWUc5WFROTXJt?=
 =?utf-8?B?cWNCRFlUZzllT3VNVm10WnE4eERMZ01HcFd0MG5BUmJERTdxSzlVRTNFUVVX?=
 =?utf-8?B?VTEyL2VCV1plRlBtWmxHY2FNNU1vM3prTXZWa0U4SnVuWmxOUUc4dW04YlVk?=
 =?utf-8?B?aWxmL3JuanBoWm0rbzEvSUNMQkt2aFhjTTFCNWx1cE1zVlBuWVF6OFFuMFF2?=
 =?utf-8?B?NStLVHcyN2lFQ3JOb0E1aHRwRUMrSGZSTGhiR0lkamlwVFBFRmFrRDl3MFJl?=
 =?utf-8?B?SDN2cmN1dEM2bDAzMkk4WGNCYU9mcW9wODVaNGh4VWV1Y21NMXpNQzNnY0x3?=
 =?utf-8?B?d1JyYUVqM2J3eGxVT3M1Mks1SHpEY3FXb2FwNGdiRGR1OXJpdUNLVjUwU3Yy?=
 =?utf-8?B?Zmc9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bdf0237e-3cf6-44ec-1a40-08dd1f49abe6
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9192.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 09:52:23.4993
 (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: DFiMGsvqf3IPlmfujw29m1PH2iyRgLYfgKdGixwDiWx+oBnUKCMUUf+plsHFhPyOt3MLNXDFpUbR8f91nGfYLQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB8109

hi Julien,

17.12.24 14:42, Julien Grall:
> Hi,
> 
> Can you clarify why this is an RFC?
> 

The code for LATE_HWDOM support on ARM seems to be already in place and 
working, yet I'm not sure that such configuration is ready to be exposed 
for users (well, probably not ready yet, considering Daniel's comments 
regarding XSM later in this thread).


> On 17/12/2024 11:47, Sergiy Kibrik wrote:
>> Allow to build ARM configuration with support for initializing 
>> hardware domain.
>> On ARM it is only possible to start hardware domain in multiboot mode, so
>> dom0less support is required. This is reflected by dependency on 
>> DOM0LESS_BOOT
>> instead of directly depending on ARM config option.
> 
> I am a bit confused with the explanation. We already have an hardware 
> domain on Arm. It is dom0. So what are you trying to achieve? Is this 
> remove some permissions from the hardware domain?

I agree, it should have better description.
This is to split dom0 permissions into control-only and hardware-only 
domains, much like it can be done in x86.

> 
> If so, why can't the hardware domain stay as dom0 and you remove the 
> feature you don't want (e.g. control domain)?

control domain is still needed, but as a separate instance & without 
hardware access.

> 
> Are you sure this patch is sufficient to use the late hwdom feature? 
> Looking at the code, to enable the late hwdom, the user needs to provide 
> a domid on the command line. But AFAICT, there is no way to provide a 
> domain ID in the DOM0LESS case...
> 

I append "hardware_dom=1" to xen,xen-bootargs in host's device tree and 
it works.

>>
>> Signed-off-by: Sergiy Kibrik 
>> ---
>>   xen/common/Kconfig | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
>> index 90268d9249..7368ca8208 100644
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -374,7 +374,7 @@ endchoice
>>   config LATE_HWDOM
>>       bool "Dedicated hardware domain"
>>       default n
>> -    depends on XSM && X86
>> +    depends on XSM && (X86 || DOM0LESS_BOOT)
> 
> This will enable LATE_HWDOM for other arch. Is this what we want?

my assumption was that DOM0LESS_BOOT only available on ARM, hence other 
arch won't be affected.

   -Sergiy


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 10:01:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 10:01:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860061.1272119 (Exim 4.92)
	(envelope-from )
	id 1tNqrU-00030z-GX; Wed, 18 Dec 2024 10:01:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860061.1272119; Wed, 18 Dec 2024 10:01:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNqrU-00030s-Dy; Wed, 18 Dec 2024 10:01:00 +0000
Received: by outflank-mailman (input) for mailman id 860061;
 Wed, 18 Dec 2024 10:00: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 1tNqrS-00030i-Ld
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 10:00:58 +0000
Received: from EUR03-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur03on20624.outbound.protection.outlook.com
 [2a01:111:f403:260c::624])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f9673725-bd26-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 11:00:56 +0100 (CET)
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11)
 by DU5PR03MB10542.eurprd03.prod.outlook.com (2603:10a6:10:528::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Wed, 18 Dec
 2024 10:00:53 +0000
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::baa9:29b3:908:ed7d]) by AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::baa9:29b3:908:ed7d%4]) with mapi id 15.20.8251.008; Wed, 18 Dec 2024
 10:00: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: f9673725-bd26-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=NagCExrFI9hoXb/tcJvUBDNfOiwHTLNPWzMaBLBeg0uH8sG4nkXWnRYDYPOUGEyBfF6eA3ZZADjVLMOnUTo8PNVFw1XzSmqwzypBQW31tUb58WWCALaLqcgIwfYySpcgxMdKUy7XVrY2dZZrp8Agja1hLa4Wq6CfNgX8DSvlBoGFFZmqwpUcDo7dKqsKFnsJFtcInYO108mDKOwvbPA6cub66WSG/nMAITWWc01xjrarGk4XYPo2tnp8IqzWyGwUv/DXbbX9TYYfCAiN8GxguZepbz1zXLZ/mq8pJ7qm85+n1Ad/gtxPBWEdQeGyPVxdnUxqK5wRQbbQQmPNqp20Ag==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ggK9E33gzVgqYP1cvYu7rpiSSpPsHcS8R6I11iylhVE=;
 b=KYA/HCpX1INiszeGIycuGgv+669kbzT4uSjQ8WJ1jFzwnoVo+0kMM5ayA837WwdPvHTVYGJ2yz/GXAjDtvRM0GJOCkKXA1Nx0thhiRAqz9euWrHZHZO0h2VLcUwuW05e9YwfQwMmW6sKBn3L/8nKu28XzEa2kHmzu//RkGeCBAQq5ARW+4X3k2MTNJ4ucEavuGNzvRo1Ck8osHg5VfA1w8OWqhF+ut18zDwH9TO7c06BA05p1xcMo3F7SxGrHuiQEYbp2MxGs6IwQ4gF+QhAikRIyW5Hb0AiVe4GbgUVCGDn8VXmgLfmKWCznXUDccA2RuWNs21CBwqIGpRTmxtdAQ==
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=ggK9E33gzVgqYP1cvYu7rpiSSpPsHcS8R6I11iylhVE=;
 b=n/x+alhB0TCb8XRUFHYTrZX37WFqTDrEE/VPFNFpf316KInjtx0MO42DcWZ6BL28VyK24XdmKyktTS0VjXkdwoxNQU4zHLqA3lKAZxR9molMcKQS0SSVf49iQYgWOwSweo956Ccp02tAJL39i3Yt/TMf05v4Ijp8cb587V98n3YCJHR03PRvqph3xDIJAJgQxDIIdLccf4/4qDeKcZr/7UfL+rc2Ew4s7Y4tx6F0lKiaUXfqWc4QDwThoDXfXXhE6ueDj3ib0AL3w9BWiV5c8IznMto6WwKCtjszvGUdriWOYTIOUM1CMnV9nz1t0YTuS2rgbja8jXSG7pglKeVBmg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <858496ff-b8da-4dd9-abd1-679dc4f67b30@epam.com>
Date: Wed, 18 Dec 2024 12:00:51 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
To: Jan Beulich 
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: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
 <9003a677-e78b-4cf8-b890-c6cf432d5837@suse.com>
Content-Language: en-US
From: Sergiy Kibrik 
In-Reply-To: <9003a677-e78b-4cf8-b890-c6cf432d5837@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: WA0P291CA0009.POLP291.PROD.OUTLOOK.COM (2603:10a6:1d0:1::9)
 To AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9192:EE_|DU5PR03MB10542:EE_
X-MS-Office365-Filtering-Correlation-Id: 9f5f1ad2-08a7-490c-b91d-08dd1f4adc10
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:
	=?utf-8?B?TCthbTdCc2ZGS2plWXF5YVQ2eVZsdkhrTFVQcGEyV0FYV1NQQ053TXdJOWpj?=
 =?utf-8?B?MlNqeG9zcHpKcHNRa2R6TnhNeHNsbzUvbTZhQlZzYVpIVEVhU1cyL0ROLzY0?=
 =?utf-8?B?RUhOVW1uN1pPUGxUQnJCcEdBUUFMRGhMR0lwUWlLNGtsKy9xMGNmN2sxNXhS?=
 =?utf-8?B?ZXVRUUIwRW9CQ2daR29ib3RTTVB6eHROUnlEbnBxd2hqeHZrSjVYbWhYV05E?=
 =?utf-8?B?K2g5U1l5Q3dzSWp6Ukd3RW1oQ3ZNeDlLajdQMnBPVkdldTAvSFVCVEVDemV6?=
 =?utf-8?B?L2ZYeUh6M3g3SWRYMThmSlRFMEZCbkovQU81UGltRys1TzlIcURoUmtlVlFy?=
 =?utf-8?B?YzgwaFJiS291azBTMDExZW1nb05VNE11L2pDam1WVXIyZHN1MFZnb2V2Nm5w?=
 =?utf-8?B?OWh1bUJPaTBnT0ZFRTdpYWNiRHU2dXp1ZExqblJMd2tGb0x6UVRzMFlzNldB?=
 =?utf-8?B?b29sa1EyMDgyZEVLOTg1QkEyb2FTb1MzNDFaTldXbWtMT0hObUQzT2FHOTd6?=
 =?utf-8?B?aFhLUHh2UjcwRmZwUzNHeHlQSHd4T284KzFlSllNZ1FzblBMYkl1Q285TDZM?=
 =?utf-8?B?WU9obVJnb0tNczNxaXEyMi9ueDY3NEpIdzFzQWMzK2l5c1VCU1AwYWNuMzRH?=
 =?utf-8?B?NVA4SXBQcG9GYVlRNHliWUs4L0ZSb0FlRCtDbnhmMGhUTWNsSUxMeWtHTDAy?=
 =?utf-8?B?MmxaUmZoT3BpZy9BcGtJUCtLZGgyejI4K2Y0ZEFGSkh0OFh0UGFlMGhRZno3?=
 =?utf-8?B?U0piY1JCMXZEck9YUm1JRFF2MzBkTEpjUS8rUUV5dVZSbTZFZnNmQnN5WDhs?=
 =?utf-8?B?RnJJaUtXVU1HMEgzdnd3bXhGM3lkem9qVkpsS3Ayc3BLYVlqOUw2WHRwRVQr?=
 =?utf-8?B?SnNIdE4wTVcxeVBOVVg5Q2hMRDl4MjFwQkh6UzQ2M2x1U3ErYXk1TXhXN3pS?=
 =?utf-8?B?VVBWS0sxVUk5dzd6RHZDR0l4eHNvSEllT2pEeGJ1REtGNlBXTkdQOVpIdDlL?=
 =?utf-8?B?VWlBMGtGcG9WOEVnSVRsVUFNR3d1M3doeDlIdzV1QUZWbUxnRVl2S053TkRv?=
 =?utf-8?B?TzF5L0F5UXlvdGpOb1Y3SlkwSFRtYS9JU2lqdGZUS1lrSkhwMHUrMThmVGpE?=
 =?utf-8?B?UEZVTlV4MGZFYytpQU5IbmJRS01JQUJjWUNPdDNhSnBKZ295SVorL2s5Z1ZZ?=
 =?utf-8?B?eUxSRFlCdXh1dGRNOC83TTVSbHo1K21TNVN4SGJYcnJLSTNWdDlENjZ1Vi9u?=
 =?utf-8?B?bGQ3d1ZPVktqR3ZnZGxTTnBDMjU2MUhSMkhRbHNzOUpBUlZ6UUlyM2FBSlN1?=
 =?utf-8?B?ZktpaXpzUjFDZExJOG5YMzl3UnhWMEthbVZMSFgxUUpUWW9XUGlXUXRsOC85?=
 =?utf-8?B?RWRReHBHS1BlcFhUZVFuWTQrQ2JRNU92UzFNVlFQOTVwNGNzZzF0QXlwRS9i?=
 =?utf-8?B?RjYrU1BYakcrNnhXZGpWeG5Xa1NXa2pPdjNZS1VZSXF1UFNKaEx3R2dha0Jz?=
 =?utf-8?B?cUMxVnprZnFvdE1seG9nMDZNblBKUkJXV2FWc3llV0FlbTNlbFYrZnRwTEM5?=
 =?utf-8?B?UU8vN1BzQ3BZNWJpdXVZSnNucVdzcjBRQ0NOQmxCV01BMHhIVzhmcXJCVUFI?=
 =?utf-8?B?MGgrMjkvekY3WlhqQ0JhSk0zSVhKaTY2Z2hjdTRRUnZpSEoyaENOY0txME1U?=
 =?utf-8?B?UlNoWHI2TGRXS1gvN3JYeERiOVNYZWhPK0FiMWQxbHdHdWNhclBMRFZUb2t5?=
 =?utf-8?B?YjZZWTZYcnloUEZtQmxBWjFZYmVKcjlnaHg3Z1VzZXprVmNXZUF5V0FjeUlU?=
 =?utf-8?B?a3k3VmVWcVVJSjVYUnAxbkRnRTZYVlRwOW1nK0NHQVhlY0VXNFdpWldLU2Ry?=
 =?utf-8?Q?KO5sWQbcKhY0m?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9192.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Y0UraG01V3pOSEk3aitsL2llT1QzVy9iZUpqcE9ZMXNPc3l2aHAzSk12THMy?=
 =?utf-8?B?NFZURlo5MHczUnU3NG02VndFdmlzYnBSZTBOUkgvTldadDgvbXVsY2RHU1lX?=
 =?utf-8?B?THNET1pXMkl3TmZGWllPczV0M0hnU0V6T2JNbE9GUUE4cHBMdEQ3ajJkTncw?=
 =?utf-8?B?SkZxYlE2TS80VFVWaTdXSnJQZkkwQ3RaMUFnOHkzRWtYN3d5TzhmbzFIeUJZ?=
 =?utf-8?B?dEFzTUFERjliU1ZDNGsrRnJ3WWg3U3F3MC9DU3dUZ1lSblpFNmk2dGc4bXpa?=
 =?utf-8?B?YXBJZXMzQVZXN3p2WCtaUGtjS1Jjc1ZONUxZYW5uQmFWRkh1QlpUNkViaXpr?=
 =?utf-8?B?R0lHWG5ZUFdSNE1oSVFKK20zSFlnWHc2bzR1NHVGNDVMSlB0S0x1dDRGZTBL?=
 =?utf-8?B?aFJhZ082ZFZ2dlJsejU2TUlnRFVUcEpUMXhScnlBSWJvQWJpbEk5Z3hxL0JS?=
 =?utf-8?B?Sk9sZU9jb0RkeWM1bElzUHZYcVlrT1Z4R0EzUzI5MTNWU3JETmpMSDV0dlRM?=
 =?utf-8?B?Y3o0bHljZG5aY2tHZitNbG1tbG5SUEpERG0rbTZvWVdhaktRV2JhWFpTaitW?=
 =?utf-8?B?U2RyU2NiK000dUcwU0hlamt2emVnQXI0STR4NENsbGxScVliS0V3Y1FURjBk?=
 =?utf-8?B?WVVEZ29NMHRnK0gvUlRRbkFlOUVNelVUMklsREZqS1NNMU9UZEdoLzBKc3FL?=
 =?utf-8?B?S011emZwWTA0YmRIRlVmRW04K1lWSUdacHNyU0JEMHF1Z3lhZmVpUklad2Fx?=
 =?utf-8?B?R2FOZkFCMzFwMnVrUVZod2FLQ0Jxd29kR0R0Q0dvdncrc2FMZFZ1bVI2VmdT?=
 =?utf-8?B?WHFZWDdWU0pxR3lZaVM2eXVPRXZ6WGlUcXFVRnpEQzNxaldKNStnZTB4a25S?=
 =?utf-8?B?MUFwVUlYdkMwMGV2MUo1UVRuMi9wY1E3T2ZicktqeHVKOFk3cEZhMkZDWkVX?=
 =?utf-8?B?Q1g1M2RhRk5uUmVheGVMU2Y2MDNuSThoaEN5S0JKSFp3eWJWWGRkN25vL0k3?=
 =?utf-8?B?S3BtSW14T3Vic29ocGxkYkEwUzlsVnhDMGdvYVlxYlN0blRkaWJsaFpxMzlW?=
 =?utf-8?B?MG9LelRFRWRWc21USDhsRWdsdmdsbHkrNVAwbElmSTVLN2tialZReDBNc1ln?=
 =?utf-8?B?NWVqUDBCdFFqckZQZXBDcWtUL1lCWHBtbnpZcWxwQjhCRDQ2bm5HZ21lVWtI?=
 =?utf-8?B?SEtFK1V1WEsxNlphcTV3elZ4V1JkS0d5S3hYbm5PVitHU01MZ0s4VDJHYkxk?=
 =?utf-8?B?OCtmYjMrY1d3RDIxZWZHT09IVHlxaGswcW9TS3BsSDNNbE1LdWNZOXFBNGgz?=
 =?utf-8?B?VldZcHNyMUlBeGN3M0hjbHMrL2RRejh2NHR2aGptZ3I2NGRxL1FZL3ZzMnRM?=
 =?utf-8?B?MmhuQ014UTIvNTJKNWlmTllITjZ6akNWRW9ja0VpeVg4M1l1TkJDcVBDdUdQ?=
 =?utf-8?B?MzRnb1V0dlFnNWRLQVUxNTducVgvTnhkaFNzV29sdVdDNEh4R0JIa214dUFl?=
 =?utf-8?B?K3JiT3dWVC9kS3VBUG05djVBL2huOFRQc1RsMk8zOSs4bXNwKzUzMit1THVD?=
 =?utf-8?B?UHpGOVV0K1VVYjF5b1RDMVA0YVp1Y3ZyQy9FVUd1ZXdYMzRmUmFRYXMzK0ZJ?=
 =?utf-8?B?a0d1OXpNemVmOGtBTjg0Yk83dUNCbFVQdTZIYmY5THFZYXBxRDBrSnB3d3k4?=
 =?utf-8?B?SURhOGh5NWU3bUU4Rm4zQkNka3pCOGpRVUNBRWFYcytIRFdNS29kSUpIblRm?=
 =?utf-8?B?aEcwZmtaY3V0ZXAydktqZXJRajVsdXlKRkFvMWJzT1J2eXVkUzBnRUxwWXFh?=
 =?utf-8?B?QkVUMkpibU45cTRxaWhNRm1TcW1BUlJxdnp6RFNYZTl5Rlk5R0J2TE93LzNI?=
 =?utf-8?B?amd4MGlIWnlKdEVmZkc5MDVaN2FxNS9zQnBMWmw2a1RVVktMdzJYZkdSdFdT?=
 =?utf-8?B?UVNBQ3Y0ZXNUQ2NCMlMwZVluR3BSZUtUaEFmSnZ6TW9oNWZYdXg1c2lJbWlN?=
 =?utf-8?B?bEVuUGQ0Q3RyYmM0UkNLR2lNbGw3V3NKMFJEUnFJTkdGcXg1V2lQaEpNR3Bl?=
 =?utf-8?B?aURnb20zdEpXUnFYRVkxZ0lGVms1dytGYkJ5NWs3QjRZMW5VRnNCUTQ4bnA4?=
 =?utf-8?B?eVpqUXRKU0Y3NCtjbmMvdFV0MFh3QTVVZEcwYTY4S3paN3oxSEs1alJIRzhX?=
 =?utf-8?B?N3c9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9f5f1ad2-08a7-490c-b91d-08dd1f4adc10
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9192.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 10:00:53.7825
 (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: ZAvY+B7/vhneCDPiFjiolpp/kp+hq18ewyfQWP0e2zvjvD0vJsJCooZwAHHc39sLU+9FRU5yZUd9weuxkb6zIw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU5PR03MB10542

17.12.24 15:02, Jan Beulich:
> On 17.12.2024 12:47, Sergiy Kibrik wrote:
>> Allow to build ARM configuration with support for initializing hardware domain.
>> On ARM it is only possible to start hardware domain in multiboot mode, so
>> dom0less support is required.
> 
> I don't follow this. Late hwdom is supposed to be started by a (minimal)
> toolstack iirc.

Yes, on x86 it's started by toolstack. This is not supported on ARM.
However dom0less can already handle hardware domain initialization on 
ARM, without much of an additional changes.

   -Sergiy


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 10:04:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 10:04:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860071.1272130 (Exim 4.92)
	(envelope-from )
	id 1tNquc-0003c6-Uo; Wed, 18 Dec 2024 10:04:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860071.1272130; Wed, 18 Dec 2024 10:04: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 1tNquc-0003bz-Re; Wed, 18 Dec 2024 10:04:14 +0000
Received: by outflank-mailman (input) for mailman id 860071;
 Wed, 18 Dec 2024 10:04: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 1tNqub-0003bt-8i
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 10:04:13 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20613.outbound.protection.outlook.com
 [2a01:111:f403:2613::613])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6dfd5456-bd27-11ef-a0d6-8be0dac302b0;
 Wed, 18 Dec 2024 11:04:12 +0100 (CET)
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11)
 by DU0PR03MB9174.eurprd03.prod.outlook.com (2603:10a6:10:47a::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Wed, 18 Dec
 2024 10:04:10 +0000
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::baa9:29b3:908:ed7d]) by AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::baa9:29b3:908:ed7d%4]) with mapi id 15.20.8251.008; Wed, 18 Dec 2024
 10:04: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: 6dfd5456-bd27-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JYVmYhkpyp6+2yUM/UGfy2cvyeUIPLxupayKDb6erxwwcyNxPIgthdOxZhm1Noe2ROJhEUnQXTp8o0EGrH4DTVwRHmvjF/4p7p+QlG7tYr0sRRj6hyK5xowmHaMqNDjfQo71XHEUXmTVPuIm1LYqukVllqT6v5bNip2orCrzGY/+n7+xq4zVCa9ZyCG1BWfJYrq5X/3Lkg6X4GuwmKxcpAGQlHpYXSooQErFRHxTNa7KoV+HpbCiR1iSb506kd8Rs5DjNYw2MlmqwcV8Ix1UE8lZuHp+olSSOJ7sHHGpN154Dluh8/XTW2VF6BPyPgppnuto0uCNSFOoTAimV+lj8w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=W7gau3jRIy4sC0FretvcCveuZ8q2tedAxLma2rOCacE=;
 b=P1Uoh4V9+3S1eFGPQsNeApxV0aMbKJk6TSLxF7CM/vM6MkRbv4r8SxjmCkpcu4qKfBBVla1dgZx+vO6xXxxvf578uvmJVaFya65kM+5b5qMWJIfpGuJ3/NohORiYAm1zM6OpPpsRWzO73KWypVThEqFnRE76behKmOeJsAmszpDwLLSyrkc5Z6AzeGCM6o1COTSehElgX8w7FyjHep83X6D8543oQ/L+UvjK5SEqRS35Qu8feZSG0EO09418tW/K1+LjWQY8CYnZlqN8MWalP2+guCFs8c4nBccfhQ6A3ZMrxyKPP+yaDGMga0Ypy7VlvVEYb5RiehqP0zrDAyMxlA==
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=W7gau3jRIy4sC0FretvcCveuZ8q2tedAxLma2rOCacE=;
 b=Im80fvTw3U4DyySbeCI34s0N17D6ByOwqeIhFCDm+KcLIFTAVVjkj8+H7tLmImSUslbmu/nxubyHyKjkmgb1p9XC/EEh8qycWtZUyKCMcZ8SDEFT5a6cVtU2JaXpxRti2kWLn3OeF007kklxy45xV9oAyb6YGYekIfIWSG5Khm/kpV9/D4beResY6vm6LfqsHz2nrvMBQjdkSbn576cOrc+YYERyRfdLRlb+TPTTf6uashBhbLRT0CGTHv//dIa8Qgs4X9CUmthgZ90sRYj0bGBMQmY6z1bNlyRN4pogrx2jK97lU6Unp65f7iAn04YS74ZVuGwXSEsr3ty/JpSr2A==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <89e09a64-dafb-4665-adb5-be90fcc12646@epam.com>
Date: Wed, 18 Dec 2024 12:04:07 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
To: "Daniel P. Smith" ,
 xen-devel@lists.xenproject.org
Cc: Julien Grall , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini 
References: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
 <4e437c60-4fee-40ed-9d2a-789bac0b36d9@xen.org>
 <63b21760-7dea-423b-a9d8-64d213c40b2c@apertussolutions.com>
Content-Language: en-US
From: Sergiy Kibrik 
In-Reply-To: <63b21760-7dea-423b-a9d8-64d213c40b2c@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: WA0P291CA0008.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1::24) To AS8PR03MB9192.eurprd03.prod.outlook.com
 (2603:10a6:20b:5c0::11)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9192:EE_|DU0PR03MB9174:EE_
X-MS-Office365-Filtering-Correlation-Id: 74cf0cfd-2566-4af7-530e-08dd1f4b50be
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:
	=?utf-8?B?UzFwZmtFdGNCZzRqZ1lLWm4vUEMwQ0NzdGdjeXFpc2dkMldHSXByVHBzL0VW?=
 =?utf-8?B?cncwdDdTL1JaZGRLV21heCs0REk3eGp0S1NKeHlrdW10dTZXSEUzODZROVQ0?=
 =?utf-8?B?M2t1ZGpxaSsvc2F3NUpKa1lkNDJqKzEyOWcvTG1HSm9vemZZUHNmS3JyMlIy?=
 =?utf-8?B?M3h5b01LWGMxb3JGNmxIYldqTXZ5bU51WjBGL3RxTmtFTGs4eVBsZjUrV09N?=
 =?utf-8?B?RzExekxJSlhrWnhPWktENVdZcTA4MzNvZ2wxaW1TRVg3UkdoYjd4cWtzQk42?=
 =?utf-8?B?a3JDT1QzSy9MZUpRVm1zVi9mNGwxN3ZYOS85OEI5YzlHeFBXeUxKc0ZJdnhj?=
 =?utf-8?B?c3BNQUZoK1dRdUpBV2ptenpNV2hJK0cyRE5IVTg5dWZGYmpkY3RXQld6SmR4?=
 =?utf-8?B?VFZGOHBnTGxrQ0tuQnlPa0ZRVHNJZW5zRnhJME5JKzUxckZsNnRHRCs5QkFF?=
 =?utf-8?B?cnM5VEVBbGp6THZtdmZoVi9rNjlXbnBpN05WUkl1d0RkZCtEaVU5TUo2VGwx?=
 =?utf-8?B?MWF1dHZ1bWNHbnhabElLcWVudys1aVplMjJ2anJyYk5EQVk0RVl2YlhvV3Zj?=
 =?utf-8?B?YytJUURkZmQxZldKL0wrcGM3TDJqMVRUNUtIY0lOR1crRE9za2lrbHRQMU9R?=
 =?utf-8?B?N3VmaVphOHVCZkFkU3NtVXphN1ZoT0d0clc3aGZtaGxWak81MlJ3ZjMzenBX?=
 =?utf-8?B?ZnlkNC9vR1NrWVprMUZROXlQWWE2VmRmNG4renpPZDhJTXdQTzE5MG9UUXdp?=
 =?utf-8?B?TDNNWmhTOWQ1TU1KWUx2SjV1RjE4MDZZaUJFSUc4NFQ5RUEzbHB1Q0FJRWVh?=
 =?utf-8?B?amtNM0IzNmIzK01iZUpsTVlIZnhiYWFWN01sL1ByUWFhQnNkYjRkZEp0Z0hN?=
 =?utf-8?B?SGdpTWw1d3M1ME52TXIrSmtjeWZmbnVOVDVXdUtVRWUxWllWSGJsVmlXMWEx?=
 =?utf-8?B?RkhGZnp1WWxlczFKQlRRTlR3U09zTUtyN1p3Vm9yYVQzczI1eG5CZHZtdDZB?=
 =?utf-8?B?TG1UZmFVR0ZlZ3JpeVYvQVRpQy8vSnQwWGlqSy9NU0VONHVMcFpSRDBZVUxF?=
 =?utf-8?B?d2dsdVJXL1o3NEoyb0laZEQxUlNSQ041MXhEWEF1ejBYSURRZUVBZ3BLeVFE?=
 =?utf-8?B?cDZwcWc2TEtCUTluRm9CMmxwOTVMZUZTZWxlWm1ZdXFVWlh5UHpjd1pScXh6?=
 =?utf-8?B?dHd1QVE0dnpWUGZQZ3JpVHhIaThSelZIZUw2UnlPZW5zTmxDWDRrRWRHc2hI?=
 =?utf-8?B?dnNSY25VdVlXOGZ6VHNONlhjOStVdzJyR0lFM0FZNEFyTDQ1RUFhdFhkdktG?=
 =?utf-8?B?bmNvOThpWWQxaUs2NUNMbGdiWEp5REpuUEVvdllHZTdITldTM3dlSHBNNHdD?=
 =?utf-8?B?ZGhBNEV0OWlCcC9qeUdaQXowMnJ0RVZWWVdVdWJiSDBOa2hna3N5ZFZITkZm?=
 =?utf-8?B?NGh4VTY2SjEyRGhYMHFKVEVzeitCNXBIUmpzaTZWUzZtVUF0b3RaMTVTSmtr?=
 =?utf-8?B?SHJ0VHAwTFpLNno3cDJzRVFEMTE1V0FDZGsxZW1Mc3RVM1JvOW8wK0VNSEU0?=
 =?utf-8?B?ck1LVUpialgzeXR5aWxqY2ZWNkhkMXdJeTNad0FGL21tdEVhMStWNVhGZWpa?=
 =?utf-8?B?cWRlRWsyT3NNMU5weG1WVU5ETUtEYWpYTkN1MW5nTExxUWZzWUVJZmVoMkdz?=
 =?utf-8?B?bmxtanI5dWpCSFVsU1Q5RkpsWHQ5YjYxc3lrR09yT3pka0ZvMEF3M0xCQmJ0?=
 =?utf-8?B?eWlHMWZ1cHozaUdjTUFoejJlQTZIZHBiWWdTclpXaTRmMEsxdGgxQTZLLzlZ?=
 =?utf-8?B?MXRJakdJSmhFL01pM0RmdkZNdUFuOUJCTjlHQXBmOEVYNG9jNXc4T0lzTktl?=
 =?utf-8?Q?cSD/5kkPdxl6a?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9192.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?QUMyQnp4VmRxcllzbFpMWlZHeVlBTTBRejNNY0RxWmI4ODdLVTd2NDA1U1A0?=
 =?utf-8?B?UWpuZFQzSjREYkl2cUg1MERYcFAvOHpGTmpudk0yMmxqNzBmS0YyREwrVXpu?=
 =?utf-8?B?dDZSWE15MmZvaGpuR3RVNUVyd3RYYm5pQ212UFhlMDBVQUZIVGk5YkNSUUM1?=
 =?utf-8?B?OWMwN0t0MExnRWx3VWlxTENBRGhjaTNYOVl5M3YzVzhjdm13Z0tYR2lrZXl3?=
 =?utf-8?B?bVNPNW9ERHhQWkhJTTVWOFJoL2lsbm9kSXFwWDFlTXh4azE5U3o3MFczeDkx?=
 =?utf-8?B?QmtJZ2hXSWlaNzRIbjFGbW5razJGQTBkOTYrd0pIRHlXbHl2N3pBTGh6cDZh?=
 =?utf-8?B?OVFqVzZFL3Q2eTJ2K3pJVFZESDVoK3RyVW4vQkRWTnpuS0pzZnhJQ1Joa2la?=
 =?utf-8?B?OG1TZFVLd2orVXVKUHBRbWJhVGwrejV5QVhNaEVucmFXMHEydDNTTFFQSW9s?=
 =?utf-8?B?NkVJdUtNeUNzY0ZDSmVGQndmQStFS2xuSW5SM3B4R0JqK2FGNldPM2MvUy9y?=
 =?utf-8?B?TUFhc3dCWjhWNk1xTUlIbG4xOEFSYmpRL3JTdjFTWlNmalVrMi95ekV5UVFl?=
 =?utf-8?B?cTJDS1pyZG5RcG1mc2FScS9CRUdlRnhQdWhXdGd1TDgxUFFkRUhxKzY1Vk05?=
 =?utf-8?B?NTFRMkxEaWw1dDBHYTBWNDJYMU5Bck5uUUdBZXZMUEZ1UkVma2d1VnVLVGM4?=
 =?utf-8?B?TnV0ZUtIYVd5dWVkUXlnQmJNcXNXbjlta3JFc1BsNlJxWWtoWTkrL214QmhU?=
 =?utf-8?B?UW5ZbC9QTW12NXo2QjdNVXJ1dE81R1hkK3hHaXJYWEVlVzJjYmZMejRpSitC?=
 =?utf-8?B?dE5YbTR5Sk1SRzQxR01pa2NEMHA3emVlSEVvb09zKzcxNlAxcEhBdjQ0WGlq?=
 =?utf-8?B?UkNuQlhTTVRVaWpRakRVbFhVSkF4YkFXY3RLZ0NheTdTTU1wb01JckdtWVdI?=
 =?utf-8?B?Q0hocEp6Wk1MWXFzNlpuUS9Ja29yWExiU013eEppZFlNRnk0d1J3QU5xajNI?=
 =?utf-8?B?azFLeHQyVFEvTmpFOTNBdjYySVRiZUhOMEk1c3BPQ3l4eW91dFJScDR2cEFq?=
 =?utf-8?B?cGVuWVNqamIrakN1dmlBT2dDNFJBOHMrVDNxM3ZtRmdDbEZpWlIwNU5SUzlK?=
 =?utf-8?B?aThEbEZyWDcwRGFaYWkxRVNLaFJFL0c5TitQOWxIS2ZUdU1xRWcwWUs4aDdo?=
 =?utf-8?B?akNCY0x0Q3A1a3ZobTUxK1c0S2FWSHZRRnJpbnREL3Zta3Vma3d0MGE1Z0lo?=
 =?utf-8?B?TzMrdDJHWnZzL0JnS1EzRjhGQWF4Wmt5ZzIxdGQ0OEJ2K2k2cW9FandZWTdi?=
 =?utf-8?B?aytvMDJRRW9mcy8vMEV3bzZJcktGZ2s2bzJ6Tk45UnAvYm9rREMrSU5yS2Ja?=
 =?utf-8?B?d3RURXh3bmxvajZmb1NRTk84RExtWHFvbHBZNE5MZ0Vrallrd3dEN3REMnFu?=
 =?utf-8?B?T3NnY0JQaHhVR1B3R2dFNmdOWDRNcWJ1TzNJSmZWRktvRHlSRnNmZm9LWkNz?=
 =?utf-8?B?c1l2TjJWUTJEa3E3Y3I4dnYxVFk5TnJRdFZ1bHB5ZFltd3RwZWFSNXcySjhu?=
 =?utf-8?B?a1loaWFqTjlqaGd3bXRIeW1rNk42eWNEdVd0ajJ3SlUyU05KNVordFcwMzQr?=
 =?utf-8?B?aHlQaG9JbEtIR2V0UjFLSDJWakdLb3dxS0pXMDFpUGQ3Q2pqc0NPRjFMWVR4?=
 =?utf-8?B?WGs0aFZrSXNEclNmUVJnV1E3S2lwbGJiU21lTmRQRk1vNUVPNlhlZFoyQVc3?=
 =?utf-8?B?TVV3YWx0V29WQTc0UktSRmF4ZG5HUDBjeTdyUHZCVDJJdDQyZmFtK09ZT3R2?=
 =?utf-8?B?NE93MFliVStjOGYwOWZ3M0daRHh4NHgwcHlxam5QUml2cDVJZVBMaXFUdXdr?=
 =?utf-8?B?RGRBaUlqeThrR3dXK3NXWGVsYlJPTGhndWoxcGRhMHBBSTBvNXk3Q0c1Yks1?=
 =?utf-8?B?akZOdXhoTG1JQll2M1REeGUzUVlsR3FlaEd3RFVRVkhBczB2R3c1YmR3UEZU?=
 =?utf-8?B?NmxnaDkrY2kxUlFVeS9OODZQSERtU1VabUZBK1k4S0E3Wkt5YkVBeFBlYnNo?=
 =?utf-8?B?VjdGbWQwUkFoMlhjWW1xcmU1eW1YMWRSUzdyQjhsNFYzTndvQWY4NnpLWDMx?=
 =?utf-8?B?MHpwUFh1VnlJRkp3Szl1bytKenNvVHlROFZpZDlDa2NsN1J3bytta1JDdUNs?=
 =?utf-8?B?UkE9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 74cf0cfd-2566-4af7-530e-08dd1f4b50be
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9192.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 10:04:09.9020
 (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: 6i4mdV/jT6sLpLiyO4GjgwIIFG/7W4DcVnvzSvlD2/hZ+6SDU1ujkzEAi22GaVjkdRcluf9kN+kLTd+Nd8NL7w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB9174

18.12.24 03:17, Daniel P. Smith:
>> On 17/12/2024 11:47, Sergiy Kibrik wrote:
>>> Allow to build ARM configuration with support for initializing 
>>> hardware domain.
>>> On ARM it is only possible to start hardware domain in multiboot 
>>> mode, so
>>> dom0less support is required. This is reflected by dependency on 
>>> DOM0LESS_BOOT
>>> instead of directly depending on ARM config option.
> 
> 
> Just to make sure my assumption is correct, you are looking to do a 
> multi-domain construction at boot time, with at least two domains. One 
> of those two domains is the "control domain" and one is the "hardware 
> domain", aka late hwdom except it's not constructed "late".

yes, you're correct

> 
> If you want such a configuration, I would highly recommend you first 
> enable setting flask labels via dom0less (assuming it is not there) 
> before lighting this feature up. This is because the dummy/base policy 
> has no support for differentiating between a "control domain" and a 
> "hardware domain". What you really would end up with is two control 
> domains, with one also having control over hardware.
> 

will check this out, thank you for suggestion!

   -Sergiy


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 10:05:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 10:05:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860080.1272140 (Exim 4.92)
	(envelope-from )
	id 1tNqvp-0004BY-An; Wed, 18 Dec 2024 10:05:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860080.1272140; Wed, 18 Dec 2024 10:05: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 1tNqvp-0004BR-7v; Wed, 18 Dec 2024 10:05:29 +0000
Received: by outflank-mailman (input) for mailman id 860080;
 Wed, 18 Dec 2024 10:05:28 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1tNqvo-0004BK-3e
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 10:05:28 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1tNqvn-009gvn-1O;
 Wed, 18 Dec 2024 10:05:27 +0000
Received: from [89.27.170.32] (helo=[172.16.75.124])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1tNqvn-00Ggri-1S;
 Wed, 18 Dec 2024 10:05: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" 
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=dfP/b2R6O8bEuSAY7cnzLLcSfbF+1Zg+GmUC37MDKJs=; b=7FjU6kziKXFh2e52joGxlYoI2m
	Cfo/1g9f7gtiVE8lYO2Ld5vgwMHuVesRhwtwb00SSBpyxfMxENYQFSfA50QB6+BgdYpBRnhfKF7u4
	2dAgBPgVOSr7FiKuYEUTDgEzIK/MTVRqpXTF9P28V7KbMC3UJF4VFXICrE70lbtaiXi8=;
Message-ID: 
Date: Wed, 18 Dec 2024 11:05:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
Content-Language: en-GB
To: Sergiy Kibrik , xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 "Daniel P. Smith" 
References: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
 <4e437c60-4fee-40ed-9d2a-789bac0b36d9@xen.org>
 <5246aa98-d23c-41d5-ba14-c12b0a2ee9af@epam.com>
From: Julien Grall 
In-Reply-To: <5246aa98-d23c-41d5-ba14-c12b0a2ee9af@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



On 18/12/2024 09:52, Sergiy Kibrik wrote:
> hi Julien,
> 
> 17.12.24 14:42, Julien Grall:
>> Hi,
>>
>> Can you clarify why this is an RFC?
>>
> 
> The code for LATE_HWDOM support on ARM seems to be already in place and 
> working, yet I'm not sure that such configuration is ready to be exposed 
> for users (well, probably not ready yet, considering Daniel's comments 
> regarding XSM later in this thread).

Thanks. In the future, for RFCs, I would suggest to add a section after 
your commit message (generally after ---) to describe a bit more what 
you input you expect from the reviewers.

> 
> 
>> On 17/12/2024 11:47, Sergiy Kibrik wrote:
>>> Allow to build ARM configuration with support for initializing 
>>> hardware domain.
>>> On ARM it is only possible to start hardware domain in multiboot 
>>> mode, so
>>> dom0less support is required. This is reflected by dependency on 
>>> DOM0LESS_BOOT
>>> instead of directly depending on ARM config option.
>>
>> I am a bit confused with the explanation. We already have an hardware 
>> domain on Arm. It is dom0. So what are you trying to achieve? Is this 
>> remove some permissions from the hardware domain?
> 
> I agree, it should have better description.
> This is to split dom0 permissions into control-only and hardware-only 
> domains, much like it can be done in x86.

I don't believe you need the late_hwdom feature to do that on Arm. In 
the case of dom0less, you are creating the domains at boot, so at the 
point you can decide who does what.

You don't need to transfer the permissions (which seems odd in the 
context of dom0less) to a new domain after dom0 is created.

> 
>>
>> If so, why can't the hardware domain stay as dom0 and you remove the 
>> feature you don't want (e.g. control domain)?
> 
> control domain is still needed, but as a separate instance & without 
> hardware access.

Sure. But the control domain doesn't need to be dom0, it could be dom1, 
right?

> 
>>
>> Are you sure this patch is sufficient to use the late hwdom feature? 
>> Looking at the code, to enable the late hwdom, the user needs to 
>> provide a domid on the command line. But AFAICT, there is no way to 
>> provide a domain ID in the DOM0LESS case...
>>
> 
> I append "hardware_dom=1" to xen,xen-bootargs in host's device tree and 
> it works.

AFAIU, the domain needs to be explicitely created. How do you do that? 
Is it just describing the domain in the DT? If so, how does it work if 
there are multiple domain described in the DT?

> 
>>>
>>> Signed-off-by: Sergiy Kibrik 
>>> ---
>>>   xen/common/Kconfig | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
>>> index 90268d9249..7368ca8208 100644
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -374,7 +374,7 @@ endchoice
>>>   config LATE_HWDOM
>>>       bool "Dedicated hardware domain"
>>>       default n
>>> -    depends on XSM && X86
>>> +    depends on XSM && (X86 || DOM0LESS_BOOT)
>>
>> This will enable LATE_HWDOM for other arch. Is this what we want?
> 
> my assumption was that DOM0LESS_BOOT only available on ARM, hence other 
> arch won't be affected.

Well... There are effort to support dom0less_boot on other 
architectures. But to be honest, I am not convinced that we should 
enable LATE_HWDOM here.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 10:12:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 10:12:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860092.1272150 (Exim 4.92)
	(envelope-from )
	id 1tNr2Y-0005vM-09; Wed, 18 Dec 2024 10:12:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860092.1272150; Wed, 18 Dec 2024 10: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 1tNr2X-0005vF-TQ; Wed, 18 Dec 2024 10:12:25 +0000
Received: by outflank-mailman (input) for mailman id 860092;
 Wed, 18 Dec 2024 10:12: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 1tNr2W-0005v1-Dk
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 10:12:24 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20609.outbound.protection.outlook.com
 [2a01:111:f403:2613::609])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 93066323-bd28-11ef-a0d6-8be0dac302b0;
 Wed, 18 Dec 2024 11:12:23 +0100 (CET)
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com (2603:10a6:10:312::7)
 by VI1PR04MB10026.eurprd04.prod.outlook.com (2603:10a6:800:1df::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Wed, 18 Dec
 2024 10:12:20 +0000
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f]) by DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f%6]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 10:12:20 +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: 93066323-bd28-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mLVfvBLKVkIxfXImTp6E0/IQadpP7aD+Oa7dT2Sj9GQsFo13T3z8etTibfWzVnDiy9DbbWeYlQ7+Xs2z9u1QtPP9IBMNVr7EAItqEe2AJrtEoIuz34cmGrpifbZ8T94Uop4Eb7rTOT+5qTXuCz/jlDE4SlQmR+0RXFczuefmHnac87sUkQLXXiJqY+l17CQcgzzfnDEv2R89yy4wpPj0qR93mc3c/GBCOiy/7R1AhCmv/TsQZkhtSW8G6hwrKfk9zZER+6u5h1mTMeLQeZ21g6JgnPgbrIKWl7fUlSqy3VJcY8Kp8q+mzVMeG5NCc5z0RjImGyUnfHOD66Hzus6lNQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=PYBrGQDJpQbCT6auY/9vzMYsBF2jgRh4Xc/6g+axlVY=;
 b=vyStJ+hZHJuH1VvK+ttuK30cuia22pQJeqz44WkK7VW/T1utRP1hR2x2hZ9I4w9Ut732Evo7ixW/hzWhjriIGNw82QKWynhS1q99fFBYWWBNcADxJ3G4khEr2AHEODecARisP2K7wIQZ6cxARz7ZTAxN5Pe8UKJK9bWg2kIofGvQMXkOId8PIwU711AlL2Gt8IP276mP9Q2v3bNxYuB86/gGyY8Jd1UN4SwLJ3sn2MKET2eERFWiQFDDjP4RcscXol7ATc4JEsJTV84J1jLuKz/C5LF7omsLOondAx19M2wchPUpCG2yZzbWj8GI7g3fD3Vy9e1N4jURygZOulVlzg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com;
 dkim=pass header.d=oss.nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com;
 s=selector1-NXP1-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=PYBrGQDJpQbCT6auY/9vzMYsBF2jgRh4Xc/6g+axlVY=;
 b=W6cfRomqM6oUPiMrvVZx/RNtkQENnK5sCI+PU3mHTGK4ecDojJqhRlm0yS+XWkTfusiFGIc22zIdAou4lncJ6luIePg+s2l1vSM7MsEa5G6LROTzhZrThYp0gD7hude+xRrcKFktX/hba2B4FF5wE2mgY5lLkYHxbHa09afvpkRPKP+pQ7bL6f27A7bg8lP6dC7gt+Wa+6zXEMZCiGCI7c+XA7+LFd2sLHvXj1XBYEbUHtK+ZVzwapIMdQE5d17r1HO1rBXuHzS5YomrchZzRBif+QcjiNd4lvZ4Mbf5uqRQ69BFS3EgnQ5Jdizw3L9IvtysjLjf33kASQbMpbK6JA==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=oss.nxp.com;
From: "Andrei Cherechesu (OSS)" 
To: xen-devel@lists.xenproject.org
Cc: S32@nxp.com,
	andrei.cherechesu@oss.nxp.com,
	Andrei Cherechesu ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v3 0/6] xen/arm: Add support for S32CC platforms and LINFlexD UART
Date: Wed, 18 Dec 2024 12:11:35 +0200
Message-ID: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
X-Mailer: git-send-email 2.45.2
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: AM0PR02CA0228.eurprd02.prod.outlook.com
 (2603:10a6:20b:28f::35) To DU0PR04MB9561.eurprd04.prod.outlook.com
 (2603:10a6:10:312::7)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0PR04MB9561:EE_|VI1PR04MB10026:EE_
X-MS-Office365-Filtering-Correlation-Id: 135b3d05-a982-4359-9c63-08dd1f4c7525
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|7416014|1800799024|366016|52116014|38350700014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?NvguuPZOtzVv4277Sbv9gf1jV8ndwBt7HZeiuVQY7ahE7TGNnJgq5sAI+noA?=
 =?us-ascii?Q?94PM4jIc9Wh6FiTzVqfB0zWFp4651DPc97n2vfctiHJVrx5yu4IRODfMEaUY?=
 =?us-ascii?Q?W7pIXRPYh/ms9ipn4qGYSB9HupcDaPD70wCuLoVfjI7PadvM5YB8u+HyAFfb?=
 =?us-ascii?Q?+xV1rN2VjxF2/t+T7JL4I2FzGDA3xzaIUnLG9HBN1sZ1KvntQDLZHWl4k3jP?=
 =?us-ascii?Q?g59V+R4FS0IQWiGOsHye+OBOtl4HE+7UwnJEqJNz003ti6ReOmf0jHfGLdgJ?=
 =?us-ascii?Q?JDBsUdt9rQ2TeaBXpv4ih9eSihJAcnCrGbmTqhI7ic1GelDTtkKawQ5AnON8?=
 =?us-ascii?Q?jUkgy6wTJtPJWtOZnfqopMkzpKfGY9JaYHug9Bedp0P0sA5rH3mSxE5I3zPy?=
 =?us-ascii?Q?gccg53NJSngq6Gx7SCmxZfL9UVr5at0pxQO1QCkI0FElMmmDIfeyrquIEjSj?=
 =?us-ascii?Q?rvA28rAeAIOkrU2l00DBtsRc9ByK2qqvb7mDaXIrEzsj0WSZ0pa+BRonsdM0?=
 =?us-ascii?Q?2NS8FVIV/QGl/8XwGT0qASvnP7PhTX/2cDi6pdm3EG7CTsu7k4BuhMVl0Nar?=
 =?us-ascii?Q?ZeNsb/YjqlBkCxWAEbxHBQ2N1h4L7e9jQaGf2rVGBR4d/2mc+RS9WOOAFsRx?=
 =?us-ascii?Q?dkX5W66kw1U7qMcFgVUh69ZmhiJOY9miJax5aCRvKW5N66LiemrSpN5q/SWM?=
 =?us-ascii?Q?gmTS9AdNnSaK5T+Wc7MH5TzZLavetJDGkM2iRCdcuGFHvomfo7g8C1QvBDPy?=
 =?us-ascii?Q?M5tAcgCLdSLJhP73v+m6I02+5JiQpTqKXsulpJbjpIJCIssWcanbAocfVI0x?=
 =?us-ascii?Q?i6y03ny9h8fR4/x803Tu/o8z7zOY8JtjZxky1Y7hZF49JjF9yjvrbPVr7ULB?=
 =?us-ascii?Q?ejuXHdvUdgim02ZXHubRD8E+41Fch3ErDuct/U3IzbDO9P/grqnDgFvVkYZA?=
 =?us-ascii?Q?hDeUbzz3pCGHznFwj00OSU+GbB2PWrNEFlmqRunZg/2WjPK41lg4Y/v969/b?=
 =?us-ascii?Q?fmZIYVBI21wfIEYSs2mgJBs5Nk0cPPm+JNP38+20OnHaKHO/mCPIhjHuGZm6?=
 =?us-ascii?Q?ByXBoAE82vHhoy1jTYjNTSQAXbRrWMeKLyYV71c30BWIcJrJMVsr76ynk46j?=
 =?us-ascii?Q?pABvxQojJ1zELdo7BnnT5x1R2ulkAmi/K1AT49UEQB1A7iSkLkRdwBxd6/gW?=
 =?us-ascii?Q?2Zdw0r3NRK+/c1Xujrw2XnX2iuiXn0iZnQ4LQmGlIEsYBoPOfEM+kAUw8NPM?=
 =?us-ascii?Q?jNZe9Gs2tbhSLeeLekAU66ElFlZ3nZzJIBY/hA0ydSFg0PQPVh+2nCOgiq0+?=
 =?us-ascii?Q?ZuO/Ha5vG8D77B3Ws+kogZ7D1DdedgB4ZQnhyPDwYujRfvXH11nQJClPi645?=
 =?us-ascii?Q?87qdsDg66ClxRkKYiGpGb/Ngff7ERXAhcb5n4Fdj6pxQM7L9sUOJvAXliSCT?=
 =?us-ascii?Q?674KIdLmRbRta2Ipcjt8XcH57pddOmk1?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR04MB9561.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(366016)(52116014)(38350700014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?Uvl1P1FbwzuyMIyEfK01RO00BRyJD3RXXx6jlUNWsw4cdV/25sHd8WoOC1eN?=
 =?us-ascii?Q?2gh9eeTr9FvIw0hUQ6o7jtok/Vx7p6UcNRlN4qgO1ChgzmD9I/RLVEQlw5yB?=
 =?us-ascii?Q?T5eNkKFiSZkc2/TrOP1mOvDMm9hGtXOco+IzDmmUMffUkmigf6sprlpGs6dL?=
 =?us-ascii?Q?aVLAb6vu+qbrY/MrjBq2n/l0DyvbRNU492gX33PRvShqv6amnSPQr0Wo7jIr?=
 =?us-ascii?Q?Yme217m7udqwaGZ2ZmoqGDLC7IJ9vQUBNbolwt4wslOa0VvBRV9S9uYXMMDD?=
 =?us-ascii?Q?OXtDcFWRBwDR+d7dv/ZQ7wWvppU5jDuvVFMtyDzznxZkvk++bI4D/CTlWOLq?=
 =?us-ascii?Q?qEbFOJ7LAjFgONRW8B4f2n51w6jDyMvjZE5VXbPfU7m5OTsewHcNTA0uEWru?=
 =?us-ascii?Q?B35kfehHF/DbaGmeb5TDbPHtVnwstWLyX4PAlShXdYoAuXxMbb9+Zyy4yKS6?=
 =?us-ascii?Q?Lz3mwlE1YvQvBzcLZ//ZPgNZNtLlRtJ64RD3be5cJQ0+LveeV03tMw7c9wrh?=
 =?us-ascii?Q?yQAq96O2jKUkWoF5pyMWwvEnCD4xnhLTybxkm4QZUWDFD2jtP9L3ZVbPebbt?=
 =?us-ascii?Q?WmtYYRYyo1EfWEFMrcpujZT17ABgtqttZ+SIX8uaJbgVFh/ZPdL6+c8fyX3e?=
 =?us-ascii?Q?330ctzso09HfJOELrJn9Q3SKT/t0L+cxFQ6i0hfByFplVACS+hy5mYFOVob0?=
 =?us-ascii?Q?LSJDlSpW2MaW8SMtXidtsPIPjNdbmtnSc7sVLVUv8gfMTZ17L6kCqT1p09xr?=
 =?us-ascii?Q?Cuo+OPU8Y0RkE10q0p18IUFx1wl9W0bzEUkikcHc6Y0uejZNf/heDbc1gc/3?=
 =?us-ascii?Q?RETcBCqRTz9FDVGL/4aZUmetooUY33BtkRDSDq82CfEixok1Nc/gPiAsVwgQ?=
 =?us-ascii?Q?0CLUeUyw5QlEWqAuwrpru7MvIVaBoNHdKaBjG4IhnzBwYwPyL+K+uqHC/3jr?=
 =?us-ascii?Q?iHkasyPtg3eQ26Nrrxc6rW8rIT9+WfLXIoKNksn79W4KEIn10jB/0/TRocfG?=
 =?us-ascii?Q?BFE7LX7oj9EFHPnxv8qw6F3vp+RTU2CjkFn775KJzv29bxyrLXG5y6DCv1eO?=
 =?us-ascii?Q?YQ0lg7pjFPadQHnIW+WviGPMhJLO/K0GPvLbMT2Kj3lzDegOi9JWdVy3hReI?=
 =?us-ascii?Q?r1Fl+ZS8Xem2y4J2N1H2T+IZizmxd5zwxKhIUjfP91RHla/fQR+DbkKgNshs?=
 =?us-ascii?Q?AubRwUQ6YQwjq4P30P13gDKzyLlOLloCLOlR1NvEdytDT5Ki/UD9EolM9SIY?=
 =?us-ascii?Q?E6xE0mWsLCw75yUipPnhUvOeoQ+8UGjurqN1OWWc316KDEVvhG2n1+2WaJSr?=
 =?us-ascii?Q?Qy/vxX7UuBwJnIxLpcYUEpYmXBxPOqAPi0V/LT6VFNuDZ2AWLEpHFzoxv74y?=
 =?us-ascii?Q?GfStzQI/GTKY2M3hqLcaFBLI29oAJ42hojIkeJUDO3CJEALlHc3zOBUTXL3V?=
 =?us-ascii?Q?k0FvgzhSDYfVc+ldtxMQWfnqd/oZXS3XTRzNLZ2G/uAxx0dk5TlFlPt9mYI3?=
 =?us-ascii?Q?EpljzatQOtIGTTiY5G8fnXI86T9jayhTw7lW0Xb1iqc+LQDNsad6qKCocmKW?=
 =?us-ascii?Q?Ft8LNjzwMwrW5nUiY0HiaPbTQg9DNvorhM6UcVi7BIlSbeW0lTS7YnHmjLl7?=
 =?us-ascii?Q?pA=3D=3D?=
X-OriginatorOrg: oss.nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 135b3d05-a982-4359-9c63-08dd1f4c7525
X-MS-Exchange-CrossTenant-AuthSource: DU0PR04MB9561.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 10:12:20.2493
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: pqheX/60QfEk1YgUDekcWGpb2eymOOObfiJ5koQbKhmO4fjeB902lYmNLR3fio/19GrMRPHy4k9qLTWwkhz1v5cRkuoiN/vBIb/7wnnNL/U=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB10026

From: Andrei Cherechesu 

Targeting: Xen 4.20
This v3 version of this patch series finishes the work left to support NXP
S32G3 Processors [0], part of the NXP S32CC Family. The LINFlexD UART support
patches have been merged in v2. Platforms using S32G3 Processors are not
affected by the TLBI by VA erratum (discussed in v2), and are security
supported without a workaround needed in Xen or guests. The workaround needed
for S32G2/S32R45 will be addressed in future series.

The 1st patch introduces a generic mechanism for forwarding SCMI
over SMC calls to firmware running at EL3, selected via
CONFIG_SCMI_SMC. The 2nd patch refactors the SiP SMC handling in
vSMC mechanism, to rely firstly on `platform_smc()` if implemented,
then on the previously introduced generic SCMI handling/forwarding
mechanism if enabled.

The 3rd patch adds S32G3 platform config to enable the required drivers for
S32G3-based platforms.

The 4th, 5th and 6th patches modify the CHANGELOG.md, SUPPORT.md
and MAINTAINERS files, respectively, to add mentions about LINFlexD
UART support, S32G3 Processors support, and the new SCMI-SMC layer
introduced.

[0] https://www.nxp.com/products/S32G3

v2->v3:
  - linflex-uart (Patch [v2,1/8] and [v2,2/8], now dropped):
    - Patches merged in v2, no longer re-submitted
  - SCMI-SMC handling layer (Patch [v2,3/8], now [v3,1/6]):
    - Changed occurrences of calls coming from "Dom0", to "hwdom" or "hardware
      domain"
    - Made initialization part of initcall chain instead of presmp_initcall
    - Changed occurrences related to "Dom0 DT", to "Host DT"
    - Made `scmi_support` and `scmi_smc_id` variables __ro_after_init
    - Used `current->domain` to print domain ID (with `%pd` formatter)
    - Dropped usage of local string var `smc_id_prop` to store "arm,smc-id"
    - Added usage of XENLOG_* levels to all prints
    - Changed print in `scmi_check_smccc_ver()` to XENLOG_WARNING
    - If `scmi_check_smccc_ver()` fails, initialization fails silently (only
      printing a warning regarding no SMCCC support) since it's optional
    - Made `scmi_is_valid_smc_id()` private to the driver and used it in
      `scmi_handle_smc()` instead of requiring usage by its callers
    - Created a 'firmware' folder in xen/arch/arm, to store the SCMI related
      code, and moved the SCMI-SMC layer implementation there
  - Handling SiP as SCMI SMC (Patch [v2,4/8] now [v3,2/6]):
    - Dropped implementation-specific details in commit message and code
      comments
  - S32G3 platform config (Patch [v2,5/8] now [v3,3/6]):
    - As motivated at the beginning of this cover letter, changed the config
      name and description from S32CC to S32G3
    - Dropped the `s32cc.c` dummy platform code and the CONFIG_S32CC_PLATFORM
      used to enable its compilation
    - Dropped Stefano's "Reviewed-by", since patch had non-trivial changes.
      Please re-approve.
  - CHANGELOG.md (Patch [v2,6/8] now [v3,4/6]):
    - Changed 'dom0' to 'hwdom'
    - Changed S32CC to S32G3, as motivated at the beginning of the cover letter
    - Rephrased to drop the 'Add' word since the entries are already part of
      the 'Added' category
    - Dropped Stefano's and Oleksii's "Acked-by", since patch had non-trivial
      changes. Please re-approve.
  - SUPPORT.md (Patch [v2,7/8] now [v3,5/6]):
    - Changed 'dom0' to 'hwdom'
    - Changed 'Dom0 DT' to 'Host DT'
  - MAINTAINERS (Patch [v2,8/8] now [v3,6/6]):
    - Dropped `linflex-uart.c` driver from ARM Architecture list
    - Dropped `s32cc.c` platform file since it's been dropped from Patch
      [v3,3/6]
    - Changed S32CC to S32G3, as motivated at the beginning of the cover letter
    - Dropped Stefano's "Acked-by", since patch had non-trivial changes. Please
      re-approve.

v1->v2:
  - linflex-uart: 
    - Addressed coding style comments from Julien:
      - spaces vs. tabs
      - indentation
      - license issue
      - comments format
      - code reusage
      - misplaced loop exit
    - Made the pointer to struct linflex_uart const in most functions
    since it's not modified
    - Added support for customizable baud rate through console options,
    parsing what Xen gets in its bootargs. other parameters following
     are discarded for the moment.
  - SCMI SMC handling:
    - Added a generic `scmi-smc` layer (enabled by CONFIG_SCMI_SMC)
    to enable forwarding SCMI requests over SMC to EL3 FW if issued
    by Dom0. If the SCMI firmware node is not found in Dom0's DT during
    initialization, it fails silently as it's not mandatory.
    - Changed the handling for SiP SMCs in vsmc.c to firstly try
    the `platform_smc()` callback if implemented, then try to
    handle the SiP SMC as SCMI if enabled and SMC ID matches.
  - S32CC Platform support:
    - Added dependency on CONFIG_SCMI_SMC
    - Removed the S32CC platform-specific forwarding to EL3 mechanism.
    - Dropped unused headers
  - CHANGELOG.md:
    - Added mentions about S32CC support and SCMI-SMC layer.
  - SUPPORT.md:
    - Added SCMI over SMC forwarding to EL3 feature for Arm as supported.
  - MAINTAINERS:
    - Added myself as maintainer for S32CC platforms and NXP S32 Linux Team
    as reviewer list.

Andrei Cherechesu (6):
  xen/arm: firmware: Add SCMI over SMC calls handling layer
  xen/arm: vsmc: Enable handling SiP-owned SCMI SMC calls
  xen/arm: platforms: Add NXP S32G3 Processors config
  CHANGELOG.md: Add NXP S32G3 and SCMI-SMC layer support mentions
  SUPPORT.md: Describe SCMI-SMC layer feature
  MAINTAINERS: Add myself as maintainer for NXP S32G3

 CHANGELOG.md                                 |   3 +
 MAINTAINERS                                  |   6 +
 SUPPORT.md                                   |   8 +
 xen/arch/arm/Kconfig                         |   2 +
 xen/arch/arm/Makefile                        |   1 +
 xen/arch/arm/firmware/Kconfig                |  13 ++
 xen/arch/arm/firmware/Makefile               |   1 +
 xen/arch/arm/firmware/scmi-smc.c             | 166 +++++++++++++++++++
 xen/arch/arm/include/asm/firmware/scmi-smc.h |  46 +++++
 xen/arch/arm/platforms/Kconfig               |   8 +
 xen/arch/arm/vsmc.c                          |  16 +-
 11 files changed, 269 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/arm/firmware/Kconfig
 create mode 100644 xen/arch/arm/firmware/Makefile
 create mode 100644 xen/arch/arm/firmware/scmi-smc.c
 create mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h

-- 
2.45.2



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 10:12:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 10:12:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860094.1272160 (Exim 4.92)
	(envelope-from )
	id 1tNr2h-0006D1-7Z; Wed, 18 Dec 2024 10:12:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860094.1272160; Wed, 18 Dec 2024 10:12: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 1tNr2h-0006Cu-4W; Wed, 18 Dec 2024 10:12:35 +0000
Received: by outflank-mailman (input) for mailman id 860094;
 Wed, 18 Dec 2024 10:12: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 1tNr2f-0006CD-Oh
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 10:12:33 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 (mail-am6eur05on20614.outbound.protection.outlook.com
 [2a01:111:f403:2612::614])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 97903345-bd28-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 11:12:31 +0100 (CET)
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com (2603:10a6:10:312::7)
 by VI1PR04MB10026.eurprd04.prod.outlook.com (2603:10a6:800:1df::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Wed, 18 Dec
 2024 10:12:29 +0000
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f]) by DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f%6]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 10:12: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: 97903345-bd28-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=PN+MqymSlI49WUPgqu0UMsf90iJWixxnV/TApLDkkAI+brhX7DuuNCZOyCBHK19VN56ja0kP0YBWx2P0jMt2U+jYdF7OYxtMrjGk+/4x0C15O/htICiAd6KbCBxpYJdkQ5R8GDIKMrblhJOHmmBwa+whydBcyMO7YRrHq67mkYILs7vjyFiXh6NgPDz8wmWcVEiP83r2yrDC0StQDd8h+1ptRVLngy3p73m7G0PGGoqjjDjzXem8yJgxgx2PkCq9v3pYOIWlIVXVEiBplDSd0poHE8BoJMUOruYn9QfaD4LS6pHLKePs7oy7YIG2sI/bEqHiXEVOYHpKBGm/4ih3tg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=NVUhy4h/8vFnBvQQe+bcSOsEufOWVq0iIZoms1ECpf0=;
 b=H5X6781bZGqB7t5GnlSxRYKjUoPw/raAyp4HvHOokGmLQb+1YLmIxMdelVmc0HptQkZoK2JaZjKQos5hGCNYeQWeZ7r/6xpGvPuAIpt1qBaTcvZswWpj0w26dGe5PeHy4nRMWhKy/bJugoxnayR9aImKb2rhj7bgIiVVFcaU95kUfE/ITTfAJDava+u2BFArKCml+Znm34Lf2kRafoo8w4dJkkzrN5k0qDgf/okAQ3QKkzO9Hks4BU5IkK/eX66bhh/Y1yIj99x98sEdU0ylCz4l1cplvfEtlWYDrSFHIV1/jDha7IRpcgQptb/vp+spTqm6ABIqiU+enoMFzbNtzQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com;
 dkim=pass header.d=oss.nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com;
 s=selector1-NXP1-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=NVUhy4h/8vFnBvQQe+bcSOsEufOWVq0iIZoms1ECpf0=;
 b=Rz+qCCPjijjGKCBhnqbq1h8YNH03xMw5feJWtTdSuyLOT24iZfJObdSTGqqTglBAvnSuPmfTvSVf7V+R7gQv+0qkMusnMmtu5akdko83F6yHGnzcbHOqKU2gUSPEz3yv3eq5Fk+58SWCzyVwVP+khTJr566HfmWUt4+TTKxSzqHHFIJo3x32Zu6wgDlfQ6ykdSsmb3XIw/4AIQkb/6AJxnUJtaazTFTd6PmFF13Cj+sV2/LrY01HG7MYjGOf6pvu/PSwMDC9AGLb7T9NFT/1YxYEPs6E0KL4H64j3R2ofhVFWeChu3z3kYyRvmdFb7bToGTFnnPtdejJGRoDie0gXw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=oss.nxp.com;
From: "Andrei Cherechesu (OSS)" 
To: xen-devel@lists.xenproject.org
Cc: S32@nxp.com,
	andrei.cherechesu@oss.nxp.com,
	Andrei Cherechesu ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v3 1/6] xen/arm: firmware: Add SCMI over SMC calls handling layer
Date: Wed, 18 Dec 2024 12:11:36 +0200
Message-ID: <20241218101142.1552618-2-andrei.cherechesu@oss.nxp.com>
X-Mailer: git-send-email 2.45.2
In-Reply-To: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: AM0PR02CA0228.eurprd02.prod.outlook.com
 (2603:10a6:20b:28f::35) To DU0PR04MB9561.eurprd04.prod.outlook.com
 (2603:10a6:10:312::7)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0PR04MB9561:EE_|VI1PR04MB10026:EE_
X-MS-Office365-Filtering-Correlation-Id: 69c50f34-8999-4888-b1bf-08dd1f4c7a08
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|366016|52116014|38350700014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?22h9+N2vOk+m5zxQ9v2tZqcPKfgejn85RGhCYMeba0O6tLG1n9TN1LVolEka?=
 =?us-ascii?Q?wVJ1GZliyvzOS5YzgSDMrPMDYvEa/xuKyMt9phdBEfYe/7VA0QrfBCcl8Ose?=
 =?us-ascii?Q?dhGbk65jj7HLiEqN6VlSowaBffWPNWSJGyuzFeRWXNemsZ3i5fwx3rpggvU4?=
 =?us-ascii?Q?kb2HA4uB3kaMzatIw22CHLbSt5R7QjDy97xwli8DfDrGOSsjW6Wd+PwlBeEX?=
 =?us-ascii?Q?KvElwvFWxhvlM9SW4UCFtEdBbLqA54Il6lAnxhDnF3Tv+S/JmGRfT951+U9H?=
 =?us-ascii?Q?PlQrX1wUen2eXSk+9DdB38g1sGzHLSY4lshFocc4R6jgchELERqZp2UHgrY5?=
 =?us-ascii?Q?51NWDE8rCeBiRiwNcFY+Xj6L0eZBZGTZdt+2UEoK3+W4Elt4vACRnOVsy9Mo?=
 =?us-ascii?Q?7tgWukD+/XiGDzZ7oX7Wnc/g8b4CZNMsm8yUbukZ3aS2bhdt55BUpWJTP+dR?=
 =?us-ascii?Q?usl98Ao80D4I+o+qVTj3PnMm1BC4mbcHoK+I3MttDnVezWLyV4WzdPk9vyi3?=
 =?us-ascii?Q?PYREzeemxL8QOPFNYDRfTmZBBnV4zHQbONReYAyaHqZV5UHTVi8X1XTm1RQ5?=
 =?us-ascii?Q?EyMxx7o5AxX99Nb4s+/oa/mwkYt2FW5mCNEPfOA5lS9jF9XCwl99S/wMdZp8?=
 =?us-ascii?Q?wSC9W/P3SpmJAkNyKUFEZGXYpCAeyjs0AoQpDbgVbEnHHb0WI/d2ho8Qk1LC?=
 =?us-ascii?Q?OK6o0gh/mRcCcy0etdZ9FZXhXsDCJZYuQxW5MCu5Sneom/hJpaodSdYtIpWh?=
 =?us-ascii?Q?RbBNsxeDS8wrzrKrIuWb/6PZseGgbhfzHH+QHMClSRHraIApm/VhtLgdTZwg?=
 =?us-ascii?Q?O4Zo4IMQMSnmTGb9YhkhYGojR1j2gtOm/HiViqcsaJfJTnKD8p57DQkJU0dv?=
 =?us-ascii?Q?cszz38pXbAHz+6ve8VHWS91Sv0p2hIKoveQoINkCF+aV+46nkrihq6Ngg3pd?=
 =?us-ascii?Q?QMm6wvt07DlitSO7E9kQbIzZ/GzJIY0BTzPM2+JdjVJURaxNPqjUSwt9IwKL?=
 =?us-ascii?Q?sngQrDNFnvE8mknXU10D87FJz8oPv8K+jD82c89hEWrWkAEzOE+YgoAyg+hQ?=
 =?us-ascii?Q?HGVPulSmunC/9Ce38hyx0MG82lcnBPR5G6mRnzSVU59CydQllH93RlNPkT5V?=
 =?us-ascii?Q?OGyqo/ZKchscgHZ/KYvIE3DupCt0U3dFrC6mT3JoXFlZXtWEPovneEC3Cg1T?=
 =?us-ascii?Q?74Fd4iinxnZtU4GoYpIfl8BuMny4s587V1EMpjg680xlNQfQgGs9YyE7kf8u?=
 =?us-ascii?Q?C57IwRgGd9ZEeSJSFbBbWBLyrFU4Bn88HgFCx6QI4xggLW/jU2yO52Rv6oU0?=
 =?us-ascii?Q?zEgHpuxF4kMxA+qDhyg6d7oicM/BsTmMMcKPFoQluPaLq+rYRxEb+DT1Rdrp?=
 =?us-ascii?Q?SvzcDg9QDQF/qh+Cwq06+c9vqtoc7XsO0nHCJO6jx6JnxuZtTOs8XDPLpTy2?=
 =?us-ascii?Q?Ms7MnXb+EW5bPXN9eQybucMcttqu4ktl?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR04MB9561.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(52116014)(38350700014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?V45rHnrkYoYLWxltnV72iVzNfrs4nV/xTeiddqoPfJxyO/6K8DrWAN1E+Hq8?=
 =?us-ascii?Q?3RyMGU9CC/1fewmWBLVhGFRQ7n8+5Rehozw1upwQYp0QDh+GDG+zI3WQsjvt?=
 =?us-ascii?Q?Yy/qmoct2cTYBISSMg1lXQlanIgjwCgtk4KlnBtjMhctKPnkCh7T0TLeKVLr?=
 =?us-ascii?Q?NNi8tGU7R5bdmMiawtF8zpkWQaP3KBJFqcqkUA68PPQUH3UvNhEYBsdI2SeE?=
 =?us-ascii?Q?leOsnjK2MOybirXNSx1QWu/W6Lb07qEp3JqFfwci2kB8v7lLfPm1WkAtynhD?=
 =?us-ascii?Q?SLBhB3v4UsX09epHYB7FNrmXrVzFrgOpGtwlFLyTtW2ibyWUD89AvzUDnU7a?=
 =?us-ascii?Q?rAu+2dRy/VPmg67XbeHurgjNkhvawQOVWseo5jTBldCpt0Zo/rdQvE8kPTMa?=
 =?us-ascii?Q?7iHSjM0A+V8Q38o05JZctqvhjgvRCX3vpLpRq/PkfgOevAZyAopuFnpKLiEd?=
 =?us-ascii?Q?Z3YPbLQkqorIH0Hb3gjH5XzmvdE4oBufHSrQdqriu5ZU7+3OFXyeRN5RLw8p?=
 =?us-ascii?Q?lt8PxXp0MZ/RSuv2dQFTBeyEdAISPQ4pAdmZ3aUziqKwupY2YhnubPYA78w9?=
 =?us-ascii?Q?JCUPEHlQq3EWUMQcfTMAsv+SRTVx/5Bz5IbMLT2ubZlFx89SVdRvvNrmiwPE?=
 =?us-ascii?Q?iUO5T0eJ54+/DMB3X0jZqZl2CeHdaCxtPFjDtGTaqsSfpJgXN31gbkJb1e++?=
 =?us-ascii?Q?X3n4v3gjwvU9ygqJgjXCw+KWtHUFUoT+epGdrdUqaS8gvsLgFJRMF58mJQF4?=
 =?us-ascii?Q?gi2zyfQdrniQf0YmCdeigNEbr68JpD37A3R5FzKCmJHdC3ecjZpIeNRa69Nf?=
 =?us-ascii?Q?nAqzIh5/4e5fdkQqGVh1BMtZwTN4sqqRMRXmWZdLRJOX4EPDRJrnoSUD0AJB?=
 =?us-ascii?Q?S+2vdHc6+SSsXPLdrioSGr52nponOSTEZmcgMsx+7Mef+CNffNbQ3ZbkfM8W?=
 =?us-ascii?Q?5xJvmS1Q3Z6HNxLO1gf+lzj4Kv7yK8S1fnyAksg0weLqxvRJlJrcasoTff9t?=
 =?us-ascii?Q?fELW6yqXr6mVqCZ3fgYMMArLbzqw/0vNGc3aO9YfWwGeiZys75iJ8F/e8G4C?=
 =?us-ascii?Q?sVY21lNzPlLwOyqWFO2p8beMUfj8YsD4vm3aBM2zbW+MJm15puzohQyKULPU?=
 =?us-ascii?Q?ZXQB71ynlW3Yt+WUKr7gRILCadMLbnzDRFq3/0onxS9HZ167KTsXP8UoNRyT?=
 =?us-ascii?Q?wogyXNW9jkqtqHKfmfyb7l7++xN9MaTD0ft5ZbXwnBxg7yroVbD6m7oGMJVC?=
 =?us-ascii?Q?5gnX2A173fe17f2B0fmoBEXyHOrd/vYgOc9k6u3WoThfF6eAlW6HuiBiB8+Z?=
 =?us-ascii?Q?4l2W/EVGdfX1pP0If1O4pWaM34ZAuPc+jcHQPyBityDScA+sk6cDc2g118ly?=
 =?us-ascii?Q?LdU8RGrfx4q1Qyo8MQ0VqUQDmrA5crZrEV6BQM9TArAHIqQlwSG30F6OMxTk?=
 =?us-ascii?Q?Y7XiWHdTevg1d7wOWkKytZZEVEAwYdAoCawYYgXAqZG92iyPHxpR4HQETU40?=
 =?us-ascii?Q?J5HTUR0htFTZ2BnEI1HmmQCmn/fybuj0+GMSwN02XOJ0Cs0NrfdJ+FK4T76O?=
 =?us-ascii?Q?Ea0KfINNSylWW8wKmVL6XQhT4ef8Wo7b8PVinyuJjVqPh4df65dyQq8uxk5x?=
 =?us-ascii?Q?Kw=3D=3D?=
X-OriginatorOrg: oss.nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 69c50f34-8999-4888-b1bf-08dd1f4c7a08
X-MS-Exchange-CrossTenant-AuthSource: DU0PR04MB9561.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 10:12:28.3683
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: v4+PE+5P++M43Eci4BrXAi6MKYLKvz/233gPCdZMf9f8JHPANphJdvJSTj8c+N2uBNDHGh+ZB48R5krhFTCPRqZOXHLmzlgJWcB6l5vet9Q=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB10026

From: Andrei Cherechesu 

Introduce the SCMI-SMC layer to have some basic degree of
awareness about SCMI calls that are based on the ARM System
Control and Management Interface (SCMI) specification (DEN0056E).

The SCMI specification includes various protocols for managing
system-level resources, such as: clocks, pins, reset, system power,
power domains, performance domains, etc. The clients are named
"SCMI agents" and the server is named "SCMI platform".

Only support the shared-memory based transport with SMCs as
the doorbell mechanism for notifying the platform. Also, this
implementation only handles the "arm,scmi-smc" compatible,
requiring the following properties:
	- "arm,smc-id" (unique SMC ID)
	- "shmem" (one or more phandles pointing to shmem zones
	for each channel)

The initialization is done as initcall, since we need
SMCs, and PSCI should already probe EL3 FW for SMCCC support.
If no "arm,scmi-smc" compatible node is found in the host
DT, the initialization fails silently, as it's not mandatory.
Otherwise, we get the 'arm,smc-id' DT property from the node,
to know the SCMI SMC ID we handle. The 'shmem' memory ranges
are not validated, as the SMC calls are only passed through
to EL3 FW if coming from the hardware domain.

Create a new 'firmware' folder to keep the SCMI code separate
from the generic ARM code.

Signed-off-by: Andrei Cherechesu 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/Kconfig                         |   2 +
 xen/arch/arm/Makefile                        |   1 +
 xen/arch/arm/firmware/Kconfig                |  13 ++
 xen/arch/arm/firmware/Makefile               |   1 +
 xen/arch/arm/firmware/scmi-smc.c             | 166 +++++++++++++++++++
 xen/arch/arm/include/asm/firmware/scmi-smc.h |  46 +++++
 6 files changed, 229 insertions(+)
 create mode 100644 xen/arch/arm/firmware/Kconfig
 create mode 100644 xen/arch/arm/firmware/Makefile
 create mode 100644 xen/arch/arm/firmware/scmi-smc.c
 create mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 604aba4996..23dc7162a7 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -271,6 +271,8 @@ config PARTIAL_EMULATION
 	  not been emulated to their complete functionality. Enabling this might
 	  result in unwanted/non-spec compliant behavior.
 
+source "arch/arm/firmware/Kconfig"
+
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index e4ad1ce851..8c696c2011 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_HAS_PCI) += pci/
 ifneq ($(CONFIG_NO_PLAT),y)
 obj-y += platforms/
 endif
+obj-y += firmware/
 obj-$(CONFIG_TEE) += tee/
 obj-$(CONFIG_HAS_VPCI) += vpci.o
 
diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig
new file mode 100644
index 0000000000..817da745fd
--- /dev/null
+++ b/xen/arch/arm/firmware/Kconfig
@@ -0,0 +1,13 @@
+menu "Firmware Drivers"
+
+config SCMI_SMC
+	bool "Forward SCMI over SMC calls from hwdom to EL3 firmware"
+	default y
+	help
+	  This option enables basic awareness for SCMI calls using SMC as
+	  doorbell mechanism and Shared Memory for transport ("arm,scmi-smc"
+	  compatible only). The value of "arm,smc-id" DT property from SCMI
+	  firmware node is used to trap and forward corresponding SCMI SMCs
+	  to firmware running at EL3, for calls coming from the hardware domain.
+
+endmenu
diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefile
new file mode 100644
index 0000000000..a5e4542666
--- /dev/null
+++ b/xen/arch/arm/firmware/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SCMI_SMC) += scmi-smc.o
diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-smc.c
new file mode 100644
index 0000000000..62657308d6
--- /dev/null
+++ b/xen/arch/arm/firmware/scmi-smc.c
@@ -0,0 +1,166 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * xen/arch/arm/firmware/scmi-smc.c
+ *
+ * ARM System Control and Management Interface (SCMI) over SMC
+ * Generic handling layer
+ *
+ * Andrei Cherechesu 
+ * Copyright 2024 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define SCMI_SMC_ID_PROP   "arm,smc-id"
+
+static bool __ro_after_init scmi_support;
+static uint32_t __ro_after_init scmi_smc_id;
+
+/* Check if SCMI layer correctly initialized and can be used. */
+bool scmi_is_enabled(void)
+{
+    return scmi_support;
+}
+
+/*
+ * Check if provided SMC Function Identifier matches the one known by the SCMI
+ * layer, as read from DT prop 'arm,smc-id' during initialiation.
+ */
+static bool scmi_is_valid_smc_id(uint32_t fid)
+{
+    return (fid == scmi_smc_id);
+}
+
+/*
+ * Generic handler for SCMI-SMC requests, currently only forwarding the
+ * request to FW running at EL3 if it came from the hardware domain.
+ * Called from the vSMC layer for SiP SMCs, since SCMI calls are usually
+ * provided this way.
+ *
+ * Returns true if SMC was handled (regardless of response), false otherwise.
+ */
+bool scmi_handle_smc(struct cpu_user_regs *regs)
+{
+    uint32_t fid = (uint32_t)get_user_reg(regs, 0);
+    struct arm_smccc_res res;
+
+    if ( !scmi_is_valid_smc_id(fid) )
+        return false;
+
+    /* Only the hardware domain should use SCMI calls */
+    if ( !is_hardware_domain(current->domain) )
+    {
+        gprintk(XENLOG_ERR, "SCMI: Unprivileged %pd cannot use SCMI.\n",
+                current->domain);
+        return false;
+    }
+
+    /* For the moment, forward the SCMI Request to FW running at EL3 */
+    arm_smccc_1_1_smc(fid,
+                      get_user_reg(regs, 1),
+                      get_user_reg(regs, 2),
+                      get_user_reg(regs, 3),
+                      get_user_reg(regs, 4),
+                      get_user_reg(regs, 5),
+                      get_user_reg(regs, 6),
+                      get_user_reg(regs, 7),
+                      &res);
+
+    set_user_reg(regs, 0, res.a0);
+    set_user_reg(regs, 1, res.a1);
+    set_user_reg(regs, 2, res.a2);
+    set_user_reg(regs, 3, res.a3);
+
+    return true;
+}
+
+static int __init scmi_check_smccc_ver(void)
+{
+    if ( smccc_ver < ARM_SMCCC_VERSION_1_1 )
+    {
+        printk(XENLOG_WARNING
+               "SCMI: No SMCCC 1.1 support, SCMI calls forwarding disabled\n");
+        return -ENOSYS;
+    }
+
+    return 0;
+}
+
+static int __init scmi_dt_init_smccc(void)
+{
+    static const struct dt_device_match scmi_ids[] __initconst =
+    {
+        /* We only support "arm,scmi-smc" binding for now */
+        DT_MATCH_COMPATIBLE("arm,scmi-smc"),
+        { /* sentinel */ },
+    };
+    const struct dt_device_node *scmi_node;
+    int ret;
+
+    /* If no SCMI firmware node found, fail silently as it's not mandatory */
+    scmi_node = dt_find_matching_node(NULL, scmi_ids);
+    if ( !scmi_node )
+        return -EOPNOTSUPP;
+
+    ret = dt_property_read_u32(scmi_node, SCMI_SMC_ID_PROP, &scmi_smc_id);
+    if ( !ret )
+    {
+        printk(XENLOG_ERR "SCMI: No valid \"%s\" property in \"%s\" DT node\n",
+               SCMI_SMC_ID_PROP, scmi_node->full_name);
+        return -ENOENT;
+    }
+
+    scmi_support = true;
+
+    return 0;
+}
+
+/* Initialize the SCMI layer based on SMCs and Device-tree */
+static int __init scmi_init(void)
+{
+    int ret;
+
+    if ( !acpi_disabled )
+    {
+        printk(XENLOG_WARNING "SCMI is not supported when using ACPI\n");
+        return -EINVAL;
+    }
+
+    ret = scmi_check_smccc_ver();
+    if ( ret )
+        return ret;
+
+    ret = scmi_dt_init_smccc();
+    if ( ret == -EOPNOTSUPP )
+        return ret;
+    if ( ret )
+        goto err;
+
+    printk(XENLOG_INFO "Using SCMI with SMC ID: 0x%x\n", scmi_smc_id);
+
+    return 0;
+
+err:
+    printk(XENLOG_ERR "SCMI: Initialization failed (ret = %d)\n", ret);
+    return ret;
+}
+
+__initcall(scmi_init);
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/include/asm/firmware/scmi-smc.h b/xen/arch/arm/include/asm/firmware/scmi-smc.h
new file mode 100644
index 0000000000..57cc9eef86
--- /dev/null
+++ b/xen/arch/arm/include/asm/firmware/scmi-smc.h
@@ -0,0 +1,46 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * xen/arch/arm/include/asm/firmware/scmi-smc.h
+ *
+ * ARM System Control and Management Interface (SCMI) over SMC
+ * Generic handling layer
+ *
+ * Andrei Cherechesu 
+ * Copyright 2024 NXP
+ */
+
+#ifndef __ASM_SCMI_SMC_H__
+#define __ASM_SCMI_SMC_H__
+
+#include 
+#include 
+
+#ifdef CONFIG_SCMI_SMC
+
+bool scmi_is_enabled(void);
+bool scmi_handle_smc(struct cpu_user_regs *regs);
+
+#else
+
+static inline bool scmi_is_enabled(void)
+{
+    return false;
+}
+
+static inline bool scmi_handle_smc(struct cpu_user_regs *regs)
+{
+    return false;
+}
+
+#endif /* CONFIG_SCMI_SMC */
+
+#endif /* __ASM_SCMI_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.45.2



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 10:12:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 10:12:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860095.1272170 (Exim 4.92)
	(envelope-from )
	id 1tNr2i-0006SP-I8; Wed, 18 Dec 2024 10:12:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860095.1272170; Wed, 18 Dec 2024 10:12: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 1tNr2i-0006SI-Ex; Wed, 18 Dec 2024 10:12:36 +0000
Received: by outflank-mailman (input) for mailman id 860095;
 Wed, 18 Dec 2024 10:12: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 1tNr2h-0006CD-5Z
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 10:12:35 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 (mail-am6eur05on20614.outbound.protection.outlook.com
 [2a01:111:f403:2612::614])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 98d37f96-bd28-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 11:12:33 +0100 (CET)
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com (2603:10a6:10:312::7)
 by VI1PR04MB10026.eurprd04.prod.outlook.com (2603:10a6:800:1df::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Wed, 18 Dec
 2024 10:12:29 +0000
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f]) by DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f%6]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 10:12: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: 98d37f96-bd28-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=zPBKw+QBXayKwQJA1jzSdjayFgE0irfM2tBWNGDlUufLV9BsYEW2PJb7JhgGawgRFUuA6h1pjDshsuUyyNyjB5/wIRmk/6Okfj4IvExJ+uWjO3BqKDwKaWFURaLuy79PXwjWieq/FBZn/U9LSrDwg+IbAQkHqYvCvx5SjUX7zO9Wu2vC/xIaqHVoZZnXIhPiG8Z0+Bu6FaHCVdhbK05zVq0jeEB6G4XgdJPJLR05uscxnx1oguzCywCp57ccYMVVlv0Lw9yPv4fZx3b3mYrp9FPH24zSWkMLoIA8goj+ZJY8UPeiMm/n3Fo+jTNgoGSLtxhtLrvJaghDpYEFumHb3w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=TXpg2Ow88Eg+MIZFn0qzYuI7h2PxCnhsFX1nq8UccsY=;
 b=fbHAs1OmzPq+ZszFQiADe83xfl7cVaXDWFAWQm+vdafrG7QiOigVL+NPr3cj8BfiEvQ3XxdKDYjtQCuxmtd+gVqY5Cu0hc5njIBgv5EDt3fE8OoCiPZX5rWpfx1JnzbtC1raoKBg/lZFqOEzwIUSO9jyK5jTw6lEd4x/b8W/G6kpfEVJWsPqeJr+joY8oPqhQHMNkPUrV0wOtbiTc9Ci7JzSyqp1grPKhxqvd+xwKqeolxjDTVEhhX5dRMWIvCbwk/DpFdL8cppEVCevEJDDqtIIxGm0F4/0ajh+2Yy6XfqLRICUUar12zxCEI5bx2Gmd88pRGcV88c0h6T0aAFCTA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com;
 dkim=pass header.d=oss.nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com;
 s=selector1-NXP1-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=TXpg2Ow88Eg+MIZFn0qzYuI7h2PxCnhsFX1nq8UccsY=;
 b=KN/MJuhXzY0sBw8Ia5pbG73W337qVRd0PnyUWvzth9J6XXCVeewVFdaNmf+70EFKkKF9qdEGkh57TJPGgad+VfNRaJNjc9urE228bGnCTyuXxUFVRwb/GlEExe3KJwv77pvq3lijsVQ2MoOaDYbBWnlYOP5+VGPS6VV+tYT5RCG7tgAlqtUeKHxvMsHHTw3qaTqDzrs7yZPDxbSgmV+S8ditBjpUSMuD2dUs9vWugyL80uSImGVT9lO5WA1t8keejfO26TxT1q4Kja/16sq/15A/PCNP10T1smCZsBAyKpS04QfejeM6C0R0xlrBPFb/D0sw1PUzhWXfZdSUQJI6aw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=oss.nxp.com;
From: "Andrei Cherechesu (OSS)" 
To: xen-devel@lists.xenproject.org
Cc: S32@nxp.com,
	andrei.cherechesu@oss.nxp.com,
	Andrei Cherechesu ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Julien Grall 
Subject: [PATCH v3 2/6] xen/arm: vsmc: Enable handling SiP-owned SCMI SMC calls
Date: Wed, 18 Dec 2024 12:11:37 +0200
Message-ID: <20241218101142.1552618-3-andrei.cherechesu@oss.nxp.com>
X-Mailer: git-send-email 2.45.2
In-Reply-To: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: AM0PR02CA0228.eurprd02.prod.outlook.com
 (2603:10a6:20b:28f::35) To DU0PR04MB9561.eurprd04.prod.outlook.com
 (2603:10a6:10:312::7)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0PR04MB9561:EE_|VI1PR04MB10026:EE_
X-MS-Office365-Filtering-Correlation-Id: 6d762712-821b-475b-d510-08dd1f4c7ab4
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|366016|52116014|38350700014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?RAerRyetckqOUvIN7YJi4W5NlqPaA7h3kkg1fm1aOb7l0njs1OLT/A1GVlDk?=
 =?us-ascii?Q?bZqV4icz7R3gGdeRYUPb+vpWMGJk2ti/tvfd4ww/vSxlenyEYCPjcaVaHmwj?=
 =?us-ascii?Q?oaiLfiKVQS6/ew+m3FW1yrOknvw20MzDrZa6vvTKef/K3TJsc520DqEy0C0a?=
 =?us-ascii?Q?QyKYAHjbeUQ9uIQ/Xo9+iSDdi8D31+UJ4bZa++yJmwpzo/J8PkiWuKhEUvtO?=
 =?us-ascii?Q?xXNSdMLPrG5aHKljxB37YwKP687JVwmjhcSUqJXry9l7Zuhvv38++weW50Bm?=
 =?us-ascii?Q?s0hi1TXvsj4lt94jL2tzlP1gCXxqpSv9IKBSYRY2Jjx2+aa6I85Bva/fRQ5q?=
 =?us-ascii?Q?iaSXgOG6r46Tv+7Am2a4U7rr3Xx9J/fVMnMSW44/2nW6Wv8MWWyYLA/m+1js?=
 =?us-ascii?Q?U0jJOsmmPq9kzfaup4YQaduozaortBUdGoXctok7AcQTz+liGXbCpNFUtMZP?=
 =?us-ascii?Q?p1bDiYwqfbOVbmt9lDu6ioCMsawO1aZCjwqU11LAn8j+ROK0x/8ALqW0Bjw2?=
 =?us-ascii?Q?nWEemyGGCvAnoF4G0hdMHOyoeUC+ACT0cwx6BxTJImKRGn9RWqyARDfo3nlg?=
 =?us-ascii?Q?gO8TqH4v/aGMavfJeFVii9CmTX9p6aKS8GdTxpS1H2riITdGbZaiC5KtoFAX?=
 =?us-ascii?Q?5TBs0nd/stVGfrDy8yV17FObG/H8W3WeUAqqFmsuoL5S4cpZRIf8gst31/ud?=
 =?us-ascii?Q?R81BE1p5vx1dAMVbte/ViJOEbM3apsSctv/SX+dF6QqhdbRkNmkW6715SqR0?=
 =?us-ascii?Q?4TPZTIvIZRGkkW5Jnf48gk4U832qx40+q4B7xgsykpd2x43ZUOvVQDF29uCj?=
 =?us-ascii?Q?/aBq7EXXPZn+U/WUpK6QJD/1DEbVoBHAT8PyuBwFr189QltfBM183yux+heS?=
 =?us-ascii?Q?1YfRXkbC15UYs+SK4ioxnXtsKa0ZXVrA43XmbhKX3nh5WDyx4jpmi3kRE8YK?=
 =?us-ascii?Q?b9NxlmT54eM80uL/eLwRMyRoVjg/PI4l0GI4v0kXAqUPUI9dztle41FtOlDt?=
 =?us-ascii?Q?IB+vR1/c/wMqCZPBj4bBJE5jQJpcSSIRTONqqBtiONr/K3xEnKU/1nJ/rDkK?=
 =?us-ascii?Q?5kJgOvbTZ+YzzmH650vEBgdYGBHAb2ZrY6NksjfyY2j0OkFbDU4dJX/g5OJR?=
 =?us-ascii?Q?Tr5RCSOMlVaRBJsw7O90trI8wx+1K0UIM9VoIDPU41pIO/gBIgfeYr8BUuPT?=
 =?us-ascii?Q?2ketgd3RmILanYroB4ogNOcWg+QlRju8LJn8uNAKDf1Z8hHL3PhVz2R3iYLh?=
 =?us-ascii?Q?k3wovi1YRLH0wTeC0yMbuWFn2Vd33cYFebK764wJbvvQrAioj3mgad81CUU4?=
 =?us-ascii?Q?Obm0Drrr4SI5oIV+tqQc2/cTNiaJgRJzRTKQ+jXW76m0WYFM4iHhZB8GEpyi?=
 =?us-ascii?Q?B2XBFTbWP//v6AaO1o2et8pWVT1RQoxHNmAO6v6zz5TxBr4FK5NIV4p2Srvi?=
 =?us-ascii?Q?k02gxEYYxgY=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR04MB9561.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(52116014)(38350700014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?W0w03VaXg7RX7xINlexV8PcQ3wVFWDT22+WI9QQzFKqLvGHuLzcuxo2H6Q1q?=
 =?us-ascii?Q?ks8VMXaYvBdrqo9GJPc2GtUJ1Hz+LDq7TOsXmbugN0311iVujsjET+/l+Q76?=
 =?us-ascii?Q?6pOeoziT5PGlsBisaFcXnLRcxyblJQlCUM5fKn1BGWXeonawABA3LXapDQxz?=
 =?us-ascii?Q?AczuNqVirEj7QeLeZW4CTeBP+Sh3iynxBiaxp7D59EB6gZ1yugU8zuBqALq+?=
 =?us-ascii?Q?r2b8Msw7gbyvMX6U6C9RqdC5x4glviREQkcwc7rZ4BeduE1yQ0ZMhntWK4X2?=
 =?us-ascii?Q?2WiNy7FNfsOxPJuqkD9xMXnx4Lbaj7tX4XBZzyVFnI8TKPLXlpwSOHigai7w?=
 =?us-ascii?Q?n58HJQuzCF5PPQZVD9R6KZK0RPWncigEixsr+gJ0pUSh+QfNhrCaEpHaRTKT?=
 =?us-ascii?Q?24MUuLpxhxKgDnVh12AqFXXuM10C5X6RgS9nr7guIv2eNERKFHXsNJKjY719?=
 =?us-ascii?Q?Onxre3fsnMOdAD8O2NjAxG6cV98cLnuxG3E6b8HwXVYjbBG8eC+KisBt8COc?=
 =?us-ascii?Q?ehlL6HwV1VKj6+WUZbNi6ls/I6RLuyY6rtYALDgnWBH5cVE5KYrf+j5GzLuu?=
 =?us-ascii?Q?x40Nds5QYq7vRLsW6afwM1WRmjfpQ2E5BK/B9g0zzN0lJmUGz6QmabCiVQO+?=
 =?us-ascii?Q?L4b5xXDreclopoGSKeeBizvUcWYdKcTur9NP7BWuHB2gVoxTdwltswawpMa+?=
 =?us-ascii?Q?ux/qy6uhw8lpBdI2E0lPOdO5wRHp76vNsGcOapLf5uPuQUV0wUpdyrBZlzue?=
 =?us-ascii?Q?IzvDNtZ51VxwyRGO/Kx5K7Nkx3woRyvr07WsMpaWGw2FxoNSjagjPzng30Gk?=
 =?us-ascii?Q?mxjkeseISwiNyCg7IXqQPi5iHdeKEdjZJN+jxt8DhdqdzAwG36u+Lk7JeUgA?=
 =?us-ascii?Q?6YzvxSRA+1MewPgobNkIwZWwMBjrvaQYfA4PygXA10tTR4TJoCdhRHzI3cLT?=
 =?us-ascii?Q?cqyyJe0irE2DhI5n7tihjHQ9tSYgcnxvH5zsymKUZ+D2yM6ncdpbNVKpccwM?=
 =?us-ascii?Q?9HZ8Rssxp+85oZ41E7IEabriMz5ueuIVLW1B9RSMjyniZD0OzJi7WvkFAOwt?=
 =?us-ascii?Q?TA+tlp0/Uk839m8L9jgWT4wqvFsRY6AO5FgtLqtjJe2YoFU/kcL+ifuEytUu?=
 =?us-ascii?Q?rXh/X1tJmys3MHIkyBl2QKm80wyobQyRUHum/w+KZVSfPEK2btbgkQycH5pa?=
 =?us-ascii?Q?ZvoKVZPzLZlHLpGn2cMGb044ggoo8aqJkF662vJrnNggEANseO2g8a5KiXND?=
 =?us-ascii?Q?WAFOaSQ+BG35SUqdExKSjAQ/nOJ6C8EnVLcDqmu3K+gQmbgZ29qyuJayvFOr?=
 =?us-ascii?Q?xyXPMfUmMmRFCcPKw9ddK4TKl90iR8LLpd1eWoZNr0yVlKGK/oZEkaNLMhSX?=
 =?us-ascii?Q?VMxXXthSMJprbbOkogchPRymLAI0gSodh+NhkWZZDSCRd/ARx7wQnuvqbEDt?=
 =?us-ascii?Q?IO8ebyRQkYsX5Byz5cu2oDjIgsI6m9ejTKTE/tfzmGR9PMEws2QesMXKk+nn?=
 =?us-ascii?Q?3bpzcQwKD5IA4vAU6FJLOXV/KESa6GssfoTWeUOrLR+RvRld1w8a4PiJmxqt?=
 =?us-ascii?Q?tJoixcMzRLDxLK0ueqOGHO1hsYdHKQerOIMXc7dL2PK0tlPAFS4y5VYGAV5q?=
 =?us-ascii?Q?oQ=3D=3D?=
X-OriginatorOrg: oss.nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6d762712-821b-475b-d510-08dd1f4c7ab4
X-MS-Exchange-CrossTenant-AuthSource: DU0PR04MB9561.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 10:12:29.4744
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: CxAVD+5tjdDDXYp4sVR0U+eRIIv5q3asvbH3iUfKKEBBGHx0/fYb1x0vm+AQdsrfFu5yiwriv0b4JkZRiQqJkMpx9gaczZGfwt6SG6p7vfA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB10026

From: Andrei Cherechesu 

Change the handling of SiP SMC calls to be more generic,
instead of directly relying on the `platform_smc()` callback
implementation.

Try to handle the SiP SMC first through the `platform_smc()`
callback (if implemented). If not handled, check if the
SCMI layer is available and try to handle it as SCMI
message.

Signed-off-by: Andrei Cherechesu 
Reviewed-by: Stefano Stabellini 
Acked-by: Julien Grall 
---
 xen/arch/arm/vsmc.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index f679cced7f..c4d225c45c 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Number of functions currently supported by Hypervisor Service. */
 #define XEN_SMCCC_FUNCTION_COUNT 3
@@ -224,6 +225,19 @@ static bool handle_sssc(struct cpu_user_regs *regs)
     }
 }
 
+/* Secure Calls defined by the Silicon Provider (SiP) */
+static bool handle_sip(struct cpu_user_regs *regs)
+{
+    /* Firstly, let each platform define custom handling for these SMCs */
+    if ( platform_smc(regs) )
+        return true;
+
+    if ( scmi_is_enabled() )
+        return scmi_handle_smc(regs);
+
+    return false;
+}
+
 /*
  * vsmccc_handle_call() - handle SMC/HVC call according to ARM SMCCC.
  * returns true if that was valid SMCCC call (even if function number
@@ -288,7 +302,7 @@ static bool vsmccc_handle_call(struct cpu_user_regs *regs)
             handled = handle_sssc(regs);
             break;
         case ARM_SMCCC_OWNER_SIP:
-            handled = platform_smc(regs);
+            handled = handle_sip(regs);
             break;
         case ARM_SMCCC_OWNER_TRUSTED_APP ... ARM_SMCCC_OWNER_TRUSTED_APP_END:
         case ARM_SMCCC_OWNER_TRUSTED_OS ... ARM_SMCCC_OWNER_TRUSTED_OS_END:
-- 
2.45.2



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 10:12:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 10:12:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860097.1272181 (Exim 4.92)
	(envelope-from )
	id 1tNr2k-0006jI-Rb; Wed, 18 Dec 2024 10:12:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860097.1272181; Wed, 18 Dec 2024 10: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 1tNr2k-0006j5-Ly; Wed, 18 Dec 2024 10:12:38 +0000
Received: by outflank-mailman (input) for mailman id 860097;
 Wed, 18 Dec 2024 10:12: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 1tNr2i-0006CD-Ln
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 10:12:36 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 (mail-am6eur05on20614.outbound.protection.outlook.com
 [2a01:111:f403:2612::614])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 99db5b92-bd28-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 11:12:35 +0100 (CET)
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com (2603:10a6:10:312::7)
 by VI1PR04MB10026.eurprd04.prod.outlook.com (2603:10a6:800:1df::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Wed, 18 Dec
 2024 10:12:31 +0000
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f]) by DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f%6]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 10:12: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: 99db5b92-bd28-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=aLdTkwbiACPER+oNnFSZeB7O5o85zc6gDG4DzUA6btanyN1vBld5VB1kQ+rjt6cJfo/A+uKRcpLs61u/CjniwPrYfBoYob5kTjXNuFWyoHBnmGV7rNlH6WsCG0KAODhAm3XWQYDMBZ8atyNWXyZ82eSWnwoFTIdfb8H4nfwIEcvO8hDgsa0NSMHzra0V06PZd4uOPrG4wY5cNrS7eY/WIuqx0PkxxYVpQvE6dEp4aHmHS/89/fJmpS9G3kHn2bzEmDcnYOG+h8g3N60FKw71qAi1spcoZYju6nzerA0cM4TGAQNxyPgSJpzD5MXg870+He75Z5rjMXsETUeJ2QeMmw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=alPIWHc1qzA8rblJaAC2okTD6jSXkIMNBqCwCgtHwlc=;
 b=yHagXES3McaAkBEYsWMfDqwOGxPsfA8kXdhen0+DcXy5M9wMdENyfHg33bMRj8VcoPSbcYFp4N+GYAprApiEDhOaNuGasR39JRpK9ierL/kB0bqIhQHYGTAFwgpnq7i2pFtRmfUeWKve1abM4rFNMPW29DopS0vLlVoRKCoireWeMISow5r4nWGigQ7KXn94/riuMbcE/8tM15my5tbipB81LmjwpQyJYYt86lP//UPTOBfDoRYS1D3wy0mTJYlZpXvCFL19XKgvNTT0hRo41JLDBrTdeazNzHSnNkqu4O1mv3DDzzNrVYMH7ZIQDuH+OTh677OM+m5QYXC+cQhaFg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com;
 dkim=pass header.d=oss.nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com;
 s=selector1-NXP1-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=alPIWHc1qzA8rblJaAC2okTD6jSXkIMNBqCwCgtHwlc=;
 b=czUrLWgW56BAGl8Tdb6IveQiNPbcAdIHCayMgfPfkNPSJjDKJgNdaHdcqhNHvYvcgrJwKb4o0J6F7b8+lCarj9u1urR4CWdnspLjNW9o3Pc6soI4DelmMs1u0VmchYQplSpTNT/en6XqtMZWJstUZv8pyGlpt8rAvMDXmNgMDpyBQ/Lba4RKbofMSR5VxwSHclhYfYSeyJjodLuNHhji0oqBHxqN/2yEUbxG+1uKopkLRfhWKnPPJU+6kHesVY3P1iQ+HCvWh20NUERIkSbMxisQLSIcdYPGyo9u350SgFFXLCS4owRYBY1+LZS8QTWTKikv9JXOQeoETG4SHQQQQg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=oss.nxp.com;
From: "Andrei Cherechesu (OSS)" 
To: xen-devel@lists.xenproject.org
Cc: S32@nxp.com,
	andrei.cherechesu@oss.nxp.com,
	Andrei Cherechesu ,
	Oleksii Kurochko ,
	Community Manager 
Subject: [PATCH v3 4/6] CHANGELOG.md: Add NXP S32G3 and SCMI-SMC layer support mentions
Date: Wed, 18 Dec 2024 12:11:39 +0200
Message-ID: <20241218101142.1552618-5-andrei.cherechesu@oss.nxp.com>
X-Mailer: git-send-email 2.45.2
In-Reply-To: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: AM0PR02CA0228.eurprd02.prod.outlook.com
 (2603:10a6:20b:28f::35) To DU0PR04MB9561.eurprd04.prod.outlook.com
 (2603:10a6:10:312::7)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0PR04MB9561:EE_|VI1PR04MB10026:EE_
X-MS-Office365-Filtering-Correlation-Id: 665b6a2b-7a7d-4b29-41a7-08dd1f4c7bf9
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|366016|52116014|38350700014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?nQbn55WdSXG7RPFvC1cS3KlEsQ2morlX+LSRzK8whpqZYJTGSEHyW1FfTEy6?=
 =?us-ascii?Q?mdxxIKccVz5AkyHZr5WYs/36bXS5pqs4TdVOiJStGVHvZZ5E8qhTQfl/qknL?=
 =?us-ascii?Q?woXktPrKNBRDm9CyyE0H/vCtPKRLV1kksCIio9KIFGDckZxZ0cuWOWaHXLkK?=
 =?us-ascii?Q?q7TOXo88uGBJJKdAhPo/b/2u2Oo8+Sd1ysWSgj+YfHrAE01iB6s37QaLU3w2?=
 =?us-ascii?Q?RBXoabM7dMu4tdY57YfFMA29+YS8cfF6HN1gP/QAeu300qTbF5v6jpTHmoim?=
 =?us-ascii?Q?yWAnSRU+S24BdrwP+w+nAkoRiVhJxgw4AqeAbe5IBGK54eRyhz2afWM1E6A1?=
 =?us-ascii?Q?r6tedjWWF2lgBUvS7cBp4FscIfLOGGCoX3/fle+nDhvmA5kxn2/j2WICe5jF?=
 =?us-ascii?Q?TWbIXAZuyo1tTdKlUXxSaIpE0ogOT68Bu9t8wHJ2uu5EXhUKJVqPpzZKgveg?=
 =?us-ascii?Q?L3hVspK2qfzn+mFMhuMp+OFgESs7xNZoKiGg/cFlklq2oO7LFwPHtpDApgL3?=
 =?us-ascii?Q?2GbKd8lz6YxRTjPiyNOcUyDET5OOo726Etn4V5551I0DBOQjm2Ki4VLQMBuQ?=
 =?us-ascii?Q?MDMTI8luQVtOqpVk+khvKHizdD6uJ5oFT6m3GznMQETrYSGoXS4OgvQYiiVF?=
 =?us-ascii?Q?IhWZ+uv5qagvg2wZ3WSbuukGyvqgm/zMh6feda7uQkFpLvisNma+Uh6SwTjQ?=
 =?us-ascii?Q?DBA8jvMqMRBf70/x5E4yBAkbLBfYOVI+QUIOLc2sJSEmEGHkyU1BxtVDPfAw?=
 =?us-ascii?Q?NUr7H4ZBDldxmjBNgCOSTjigSiyK7SwqlewwZjLX/rOVWdxYhfkjmH+eaNqt?=
 =?us-ascii?Q?oPr2WrItgrSW3hcKSf0WiRK12NLYN+PJMDysfvf23ouLurFB+cZxoDu7P4bn?=
 =?us-ascii?Q?HCc0v4q+ax6KT8x81iyP85BDLtlbVC+AWiPc9Mljt6qd2mcCNQVK1dkuEMgW?=
 =?us-ascii?Q?fNHJV55qFJKir1+wd8P4J/VuQjHhgYiLHbGrS1EruoOhe3UAhp1Ui9NLhAee?=
 =?us-ascii?Q?7qpchDwtf2x0rNiQQEgrklN3H+ZoZ6GA4aDD6rOaK+GQ0ZWmEMOVciSuBMQh?=
 =?us-ascii?Q?raftNoYv/aLyiBWLFqwlSwdUzv6M/CE2i69QsB+pvlw9jXuYnAGxfSy8Svu7?=
 =?us-ascii?Q?6u7ZUa9SKOgIypiRnq5p2RrXYXlVnCQV+vqxcxSu0ucN2zPFjno1GZvn9I4S?=
 =?us-ascii?Q?WtDgTIOnfTAhmCpl4smG++zUY8OO3v4aX8MPA87vN+37WVqi1MQcNnwn+ze8?=
 =?us-ascii?Q?O3Gf6V4UF8BN+5cUozJX+pll/lwimRED6MzNCwaNU3V8n0H6cks0vUw+7y35?=
 =?us-ascii?Q?Ia3Ee4hU8XNGtR5NLpIyApssBu/gpUnR2615g5hbJ4kwRaHJSsxAWiZjVMh4?=
 =?us-ascii?Q?hik6ehuAWwoCQx8L/1sxLTz1l8e7?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR04MB9561.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(52116014)(38350700014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?2p9y69EEBOYVU+fLYRipmzUO/ZcS7Hphd1Tg63Vtx8uddm29cdR5c3UePh1G?=
 =?us-ascii?Q?N3EbzoGBLGl4W+QGNOo0u6k0C22EvKZtGM6PmW/vxpTvButaC9daNmlH4aU8?=
 =?us-ascii?Q?r83Z7nn7CX6wZkQrvmncvTJkQ7CLR01S2VPEjke8sOlsqcs2bfyUf5txDV00?=
 =?us-ascii?Q?7ZC5PdSpki3CwUE7kmc53kzqZODP/m7sObuogTS9f00Tfzn6JSr1T75j8cst?=
 =?us-ascii?Q?q8AhiYSnMPnNM48Bo0PD0dUp9j7sEJRLacp0DlHQ2FujwpKP3FY+na3KBGgw?=
 =?us-ascii?Q?/VOZ6vXIdFb4gZzvtB673u+0PA2Z6KbHNnQYt3DxCyyZhzpq1sVioddOditU?=
 =?us-ascii?Q?ZJd45YWM9V7ubhTgLYq1nhsdnLovPQwyACMLXweCaLcmfJkPzajcsyXQCiL9?=
 =?us-ascii?Q?aH74k/QMQ0UOH0wTlRxe6Jh8pBurgX2fmpAx+tt2INXBrgALmTTJCTJ7Kb/b?=
 =?us-ascii?Q?uggZZHf2AstP7nJcn2E5C8dU/Hk+m/57n1L0bBiYmO2V9wHEedazJvJzlQjH?=
 =?us-ascii?Q?fh34gVDdbyuHuQNxQ9TsWAfz0eMMHsJU09oiAokmqc1kIQb3qXyYdafC6R9C?=
 =?us-ascii?Q?q6IDJIhM2mqRW0PQjDOPyft1Da16p4lq+uu5A0TNjr/2CS3raFneTK0yTilT?=
 =?us-ascii?Q?3d9Q+s/0MuQ/HsmiAH3VkxbtqFRX70lQjNySfYrsOc9zkriWIvSSI6WBuvbm?=
 =?us-ascii?Q?3Z6x/dRwkBtoneVsiacezl/rMvxj0hxCrg8wMgsz+XOtwCqzc+ApYrJCUPZA?=
 =?us-ascii?Q?u3yIqvz8I6Wh04QtiaBBKW7b/jLL6oLpl+97RSEJ0NeGmbm9xXLSOcypkj8h?=
 =?us-ascii?Q?En0FDTL1qOvraL/k+x2NSypjCypUl09KuYhCj4L+8Q80l5nOPHlc9RzSeOrQ?=
 =?us-ascii?Q?xoqfy1mrIN0jebmQce+AOZRN/ZvLMJqXWFuoeKH/gt9S06cGTd5iOBHVp6lf?=
 =?us-ascii?Q?YYoETnzvhgltuP6W6TeUKWKqw+unlZAMWIAP5cXYkYrCfA7Yz3l/sg4cbr7a?=
 =?us-ascii?Q?hoVVAcBPvzo23zlj40hwBzDewdLX1kxAPCO0d1yXJUehiGi1C2eQ7iUB4s1h?=
 =?us-ascii?Q?Mo01mRObHPsNJ13kjDDD8Dr9MFj5WjyO29N9Hgyps8QxK7hwtGCcZ/VKB3e3?=
 =?us-ascii?Q?oZs0zLf5XHPIE/JNxT+KNDZuiGL94Bb9pDflaoNjCfK8i7pkb80vSqqFDJpC?=
 =?us-ascii?Q?9QJcL8Y6jC9iMpIRm3zA9gjOsFBldKf1F9XDDdtNqo4ANB4HqSKVmkwJWCZN?=
 =?us-ascii?Q?c79yw/9lFbCr8IPX5c/easlrAJUFbJ8o1ToAhSVi8YPSPLpwmMDLzOmdunAS?=
 =?us-ascii?Q?fsnBlmF8CvbeK3Dr2upez4FqgF2T2/pOzsfbHkmQmLc3pyl4iF6bxIdpdOXx?=
 =?us-ascii?Q?UgGOqBE9KNZ32lcC3d3RPDjtqiZ863g1tZC0DZDuWP66dbDwNaZ9x6cJ8u4q?=
 =?us-ascii?Q?eqUa9HUwytY4k1QENqsiMw1Oi6Ry4kILGl/3gR+06TKE8gjAfpD5q/HhDT2C?=
 =?us-ascii?Q?ToG6Jgz9bOyieXUIu5GwOURRY4zz3QqVgbMMersWKJeWKPgO3cs9MhiPrtox?=
 =?us-ascii?Q?AFCirBkaH+KoSU1BBvlZAmPMhAKdHSXjSFlgeXr2uVCEHo2YfW4JCVsy8b5u?=
 =?us-ascii?Q?4A=3D=3D?=
X-OriginatorOrg: oss.nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 665b6a2b-7a7d-4b29-41a7-08dd1f4c7bf9
X-MS-Exchange-CrossTenant-AuthSource: DU0PR04MB9561.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 10:12:31.6278
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: hgqf5pjCfIjPj8AwMqeK1CL5E91gh4pGMgozj5th6a7CAaa53QJuXmUovtllPD/I1uF6AIy9qI37T94AiVzWjWM1NcmpkQCUZxC108xHaPw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB10026

From: Andrei Cherechesu 

Signed-off-by: Andrei Cherechesu 
---
 CHANGELOG.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 15f681459f..bda43b1efb 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -16,6 +16,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 ### Added
  - On Arm:
    - Experimental support for Armv8-R.
+   - Support for NXP S32G3 Processors Family and NXP LINFlexD UART driver.
+   - Basic handling for SCMI requests over SMC using Shared Memory, by allowing
+     forwarding the calls to EL3 FW if coming from hwdom.
  - On x86:
    - xl suspend/resume subcommands.
 
-- 
2.45.2



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 10:12:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 10:12:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860098.1272185 (Exim 4.92)
	(envelope-from )
	id 1tNr2l-0006lx-5A; Wed, 18 Dec 2024 10:12:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860098.1272185; Wed, 18 Dec 2024 10:12: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 1tNr2k-0006kX-Tw; Wed, 18 Dec 2024 10:12:38 +0000
Received: by outflank-mailman (input) for mailman id 860098;
 Wed, 18 Dec 2024 10:12:38 +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 1tNr2k-0006CD-6G
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 10:12:38 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 (mail-am6eur05on20614.outbound.protection.outlook.com
 [2a01:111:f403:2612::614])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9ac266a9-bd28-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 11:12:36 +0100 (CET)
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com (2603:10a6:10:312::7)
 by VI1PR04MB10026.eurprd04.prod.outlook.com (2603:10a6:800:1df::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Wed, 18 Dec
 2024 10:12:30 +0000
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f]) by DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f%6]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 10:12: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: 9ac266a9-bd28-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=IbOIIHWVsdGMr/RzIBs4sX4aUakJNDG7i5Hdmxo8EBLRdoHX75yrQ6HcTaQHplrKZg8KjFSYcZ1RPXJYOqJuSB53tkJmLSq7J7wSEy2vB2t/b6HDYtkt/MYVzn6wm7bihVGMbP0ktPRFIT2xWhzI912U640mP40Rqw1/tvXGcSsVjGjKVUBbVC6g6RdvUmlGS6NvPsubAJ9Jdap5hh2Bb8us4rGbk9Z6oIVJ0SlpCPucOCzIylrvZcLm9NyyjcrsG3O/WeUNpvM+cQGeXdyZmPDasD9wakmMQR9+AHp4mJ234HNHxBHx7oKBV13wfoSWzmXxN2VWrwkMVUE40Y6oGw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LRb12Uxal/A5sZn+ymF9X7NeFCk+iQiwRZcfXUwRiQ8=;
 b=kA/Dk359FARQmcw4QaZe/S3+jTsjrFHrISb8mfRFWNRhtUjza4cDhwO/oKJPO6x8TWbIdDck716LS0rUwYECXgylJT5pHZGDjMFcFQm4/QdXw8rssWepzqMt67ZzttnU2+cS2/+teLvOXzwjfSgu7ZIHS0KsPCfzX26JdFTZU/bO10+JjZEEhoK8lDQtCDYXf5cKnDmUco+rR0vzPyB/QedZbre6QHT4t+qfk42IgXfzbC+w/wWQHn+j9rIOuVGN6ai8loBreNuuoGyM44WO3fF/yy0TGrg3EKGprC6j1RqeQUAQpmAUnNDvVqLNOvkMMmAvIQJaf/vF7zDoV+XhUw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com;
 dkim=pass header.d=oss.nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com;
 s=selector1-NXP1-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=LRb12Uxal/A5sZn+ymF9X7NeFCk+iQiwRZcfXUwRiQ8=;
 b=qUgjug18f2iqMT8w1IFgCRj3crjC7E63NtEPR4sUqPQklYsOpD2AttVP3RaMtC1bZmBYLPEnR/ObOLmzT3CO1ZhxOPKPZmUaiBDGh+qGFYs+n9PI81/hNxAr1w21GDeMU9CU0Jrj05uUYVDcU/x5PiomdRtrfJSemkajX0CrkwoxBHsoJEG5OGe3ejtlWMirFZMAtEiNAp4PERovM6JIKlQ3LXSmaQdUxSgBBRlU9UFFHHOMNMUBVEWhZYOFwnquqQ97sZclnPSvd08GM+7FOoR83CIriCvR0E5jIAQLa2ZndVFqV1DZKSFjAfl7mHvDKcqaxMAPTPbpSz9jz4gA7A==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=oss.nxp.com;
From: "Andrei Cherechesu (OSS)" 
To: xen-devel@lists.xenproject.org
Cc: S32@nxp.com,
	andrei.cherechesu@oss.nxp.com,
	Andrei Cherechesu ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v3 3/6] xen/arm: platforms: Add NXP S32G3 Processors config
Date: Wed, 18 Dec 2024 12:11:38 +0200
Message-ID: <20241218101142.1552618-4-andrei.cherechesu@oss.nxp.com>
X-Mailer: git-send-email 2.45.2
In-Reply-To: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: AM0PR02CA0228.eurprd02.prod.outlook.com
 (2603:10a6:20b:28f::35) To DU0PR04MB9561.eurprd04.prod.outlook.com
 (2603:10a6:10:312::7)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0PR04MB9561:EE_|VI1PR04MB10026:EE_
X-MS-Office365-Filtering-Correlation-Id: 291be8be-45a4-4c64-6e7a-08dd1f4c7b7e
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|366016|52116014|38350700014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?SlBRvxT23KSu13l9g76fDbE/tq5nO426Y3QM7S7I1BdCtqgxDTuvkKScGl4+?=
 =?us-ascii?Q?9qIiA9dIDSkV80bbzUnGy97tvHJxzGZkqrKK0rjSkG1jt67plQK6yY8lRf+3?=
 =?us-ascii?Q?GVjDUgEYNnVBfnJKLqEN7FmbVVWuFWnSbk4kfahU5v+rlmwQ7JfdYqesOYBO?=
 =?us-ascii?Q?ZoNX35r/UoARpyDDjhfoXsEEatg6Z+lJ1o7R+wLZ6PSj3ZzSTTuGCgjmQ9nc?=
 =?us-ascii?Q?gx/1HEom486u97/zMZxawx6MpcsRByG9v0MZrSRhYnDkTjVr1fLhftndf9rs?=
 =?us-ascii?Q?Z4lm/Of8jilS9JHo/OcP5QFnspadgFVZvgmwKPxCX2MMGJj1rviZdq3IZJmG?=
 =?us-ascii?Q?T0yU429V+ty+86q1jq9zGAIm0TRF6MPjgjYHtk255S6ABccw0rK1wEp9zLAT?=
 =?us-ascii?Q?aUReKLg5JjfgBWE2MKRTwwDysjeAtYJFc+A54i20FzTz+1tnw3EEuHPUT4b8?=
 =?us-ascii?Q?aRHFZZPZLso7fSexoThgaFNqdhrfl9XFLq0bXJJt2TmoRFLg15NGjPpGaImN?=
 =?us-ascii?Q?dy9eGQ6kGmqNZcr7KENrgLxiDBknNgNDAQp4+K/4AjWtBCPm6273QVmUzGu/?=
 =?us-ascii?Q?nhWDFE6v3wBA1RMmguwtrCCyKGneoIW28rQkijNKj+/fApkj+ZI6lnpwwNmz?=
 =?us-ascii?Q?qK5EjrUSATgth4wUBUc/T6KlsGu2RT4kqen3XrU27DlAnY+1lmhlSLqwJPni?=
 =?us-ascii?Q?/RUxNSCqYeUbPT1gFhswFvpOmDlfJQmlPWSkTlGETPDL3mqWK9cNle22QVBJ?=
 =?us-ascii?Q?a6UHm5c+5MHvkts6rsKzflFXHXmj6XjSpd59w6pxvS/aVNuUnvb0tDmXyd0D?=
 =?us-ascii?Q?VXsJtOGCKfB/faO7CPYLv195oFHHWBidBLVSZlRJyiQ8yC8Ta2yjK7HdeBWt?=
 =?us-ascii?Q?kgxq/DDGu3w4B7mdvDknZ1/0stkS5UT9pecMeRp7En0FnjOLPSRalec9lTrU?=
 =?us-ascii?Q?BDx9oKsVvUJ6Dt3UP5J7/fiJJG55d+aTeREj4ctwKtZpefSEEN4EZPRIm7zk?=
 =?us-ascii?Q?/jhnki8liofQA4VdUgse7cvJOY6Gn2SUNpVY9dx4KzPYZpZtYurXfAf6VBAy?=
 =?us-ascii?Q?BrrkHTWaD4P1jteBQ+YBYSWIlqcI8ruGgH9BoWA34BXuh/G5XQOl70hystDF?=
 =?us-ascii?Q?imgjr7pB09dc5ifekvGPQ+dLz70z8urTa9siNaK5gu1SsLyEtj1hygoeBaPM?=
 =?us-ascii?Q?Hcs2tWGJm8MPoiqaIpf2kzpQiISBWRz2Szo4NZewM1FbgnNQgegn/hsnpGOp?=
 =?us-ascii?Q?551TLfzwPz3QJDgKy0oaBpUWeP1xGVcM0fxYAkOHO0lnROhYQDVKCwZ9HaFA?=
 =?us-ascii?Q?a/0PnVyb/uRhoDqsGN9vTWkXpC2p4rGi9Pk64M+4nMiPXsnEw/cpK5SAnWda?=
 =?us-ascii?Q?UDfyMu2ycCZ2vEY1VJocjGFPiLnbHvyb4DsxDmIwIK9JAPyYdCEv5HJh44YZ?=
 =?us-ascii?Q?rHN3MKTKq/Hrb0XxCHMI8jhjVmD0k7Tt?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR04MB9561.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(52116014)(38350700014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?AUufk3eTSccV4vDLH1DcTcggEkLlWOjQEEZC+AJf+D6wFY24c9/CUgFMT+qF?=
 =?us-ascii?Q?pfHh3zEbR2rNHPaP4c2B/zTaq5i/7cCoOfzOJ0KuQy5G5ljVaLpirBQ32xNP?=
 =?us-ascii?Q?oIeZS0pocKAEtomDHL4Y+MaMsBz1ahnW+V2ki8/E45C7B+dOxwvxkc61hJAQ?=
 =?us-ascii?Q?AEgZVve3o1A8s/ICszoIobwOBMoPnXS81SfvS0l4nhV7G3IP1qtDAmHbcwUt?=
 =?us-ascii?Q?70lm04yYUjyAc1Acb6EvolZ/niKvoiMpVM20NWZngv2tt7hS6J/L12nEszai?=
 =?us-ascii?Q?u8RBa0fzaK3Z3OsrAYnBjUczeMVwFhnYUsdFAhZIAX0W7dRgm0+8+FjpDrhF?=
 =?us-ascii?Q?X35EOkeydbSxtIZAGaV1tdv4a58YH4NX5GYvc7sj/xJzE/Sf6IrMatPByAmU?=
 =?us-ascii?Q?LadQEjRnBtOzRi7Pg6aAwFfTzNYYIkn4H0tuFVvwlAnmBnpFQrzUklmlJIas?=
 =?us-ascii?Q?y2wU+SykZB5aW5ea7coF+vyCpOTb99xP6SDFDH9JOLvc7iL76Ut36de3PLxk?=
 =?us-ascii?Q?98b7JIK9p+FXKpURZ0logH6tzYirkqvBydl6L7Hw4bCUFVb4AKcVDNbiWsh1?=
 =?us-ascii?Q?uOAoMdeZS5HL5jQt2zlUEqM2qZAbe1SZtXTcDV88OAtpzHuUjPJKg5kFyYhC?=
 =?us-ascii?Q?KkNasRbO9MAdKNcADWo4yOAOuK3w7r5TTWY5e73IEnjKlxTdEesKKPahJ6YU?=
 =?us-ascii?Q?F3TrSAsWZ9KAsKoeRydMBIeD8avKKfPS7ru6U1gm6lCKjykDhXXS+fvWL2pA?=
 =?us-ascii?Q?ZvCRK3of8DgAEwG+JgooMvTiGeZ4Q2fMxlxpvBr+x8WIG7mp3C4NaFIVNv/M?=
 =?us-ascii?Q?rhkoAdu/beLPOACKGHlXVgG/5i9kxktQUYaz5B+XXxm03YlGpToNKMoFEQZU?=
 =?us-ascii?Q?rnGI1k0YxVXBFPg4Lo66npnH6HEVf0/uKHr+mlS9QFPRTRSh6KoD/Y06GMTa?=
 =?us-ascii?Q?cPJDhXk4/9qBf7GW+50bEKVe/M6QU8pVo1uIvLWc7iMJxzhv9h5TOBRTm1Ri?=
 =?us-ascii?Q?22Ww1y0Rye4EpqOsi0u5mWGJz4wu80BW7OaC0GrMTdrlkqPLya2jopqn9Mwy?=
 =?us-ascii?Q?i+Gg/Wr+PKQF8sE3iAytZoMowcOFoio4eAj4g5WNuz06ATzsgCARxNKzVvIV?=
 =?us-ascii?Q?inn+MAyGATGnb3o1vnJ8m1IHCcv9fjxuUht9J4gYar1w6XfVqFk9+ngbiltB?=
 =?us-ascii?Q?z4TlB7d4b02x01PhzSh2Huxs1Lfp7/K5AW1TJOoQeValIup/rSI8vSKDwxBr?=
 =?us-ascii?Q?5Xij63ECoAF5hnhzHn7UjjltTaTVaI1cI3fdn1Fh21Ikuihhfgm35xAmO9n7?=
 =?us-ascii?Q?xdc6fSuAQTcKp+P1698s3u3ssANRV6ygngyp0ih+uyWVpvSR30a1Mg7NKawL?=
 =?us-ascii?Q?j6aSbHTh1f+WK5I1zUibdfyq1Qv2GpgcPlBHQi/5U2Ai32Ww6olDg225Ldat?=
 =?us-ascii?Q?HfaOsW3HDOAT7BqGFmJkKjlMgBSc2pGLSwB3p0HtKe9YapXqRH2jNFwbDJ6i?=
 =?us-ascii?Q?O+uN4sSVfwGmYlRBI6p7V/F7EXM9HrIVC2Z3VYp1wzF1EmK9INnq6RB1e1rB?=
 =?us-ascii?Q?CtFpcq6XDsnZcpUQaR7oSlNXGRqMnSb+p0RNEkZLluaVWFAxYIEJRzjMHj85?=
 =?us-ascii?Q?lw=3D=3D?=
X-OriginatorOrg: oss.nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 291be8be-45a4-4c64-6e7a-08dd1f4c7b7e
X-MS-Exchange-CrossTenant-AuthSource: DU0PR04MB9561.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 10:12:30.7793
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 0UxvkFCU6kyZ1t6s5YrCv/qSCTEWvAF2kVSKDjSJKmXMKJIQ9RSOU1mzBpOulJJZLfRG5NIBzWRSggX+k9B/7pCRD8U28/OARfxnAWpKLZA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB10026

From: Andrei Cherechesu 

Platforms based on NXP S32G3 processors use the NXP LINFlexD
UART driver for console by default, and rely on Dom0 having
access to SCMI services for system-level resources from
firmware at EL3.

Signed-off-by: Andrei Cherechesu 
---
 xen/arch/arm/platforms/Kconfig | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
index 02322c259c..6dbf6ec87b 100644
--- a/xen/arch/arm/platforms/Kconfig
+++ b/xen/arch/arm/platforms/Kconfig
@@ -37,6 +37,14 @@ config MPSOC
 	help
 	Enable all the required drivers for Xilinx Ultrascale+ MPSoC
 
+config S32G3
+	bool "NXP S32G3 Processors support"
+	depends on ARM_64
+	select HAS_LINFLEX
+	select SCMI_SMC
+	help
+	Enable all the required drivers for NXP S32G3 Processors Family
+
 config NO_PLAT
 	bool "No Platforms"
 	help
-- 
2.45.2



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 10:12:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 10:12:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860100.1272200 (Exim 4.92)
	(envelope-from )
	id 1tNr2n-0007HH-IO; Wed, 18 Dec 2024 10:12:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860100.1272200; Wed, 18 Dec 2024 10:12:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNr2n-0007H4-EB; Wed, 18 Dec 2024 10:12:41 +0000
Received: by outflank-mailman (input) for mailman id 860100;
 Wed, 18 Dec 2024 10:12: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 1tNr2l-0006CD-Om
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 10:12:39 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 (mail-am6eur05on20614.outbound.protection.outlook.com
 [2a01:111:f403:2612::614])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9bad6762-bd28-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 11:12:38 +0100 (CET)
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com (2603:10a6:10:312::7)
 by VI1PR04MB10026.eurprd04.prod.outlook.com (2603:10a6:800:1df::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Wed, 18 Dec
 2024 10:12:32 +0000
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f]) by DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f%6]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 10:12: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: 9bad6762-bd28-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ny6XGApHiDdDryB5G5h0Z9ShP/LdK49pzE166PxW5OYVUgInUmUdf0YwbBc/qSXvA8fwtcZuiSACgTNYI4hlMAF3CEjI8s4JNq8EpaRqFln9ihWzV5u0W7Fv9xbm/zw5nwfvXALEtQJD5eadFqFSUg4NMEDOesc2s/7XJYpfi2EfpgqL2j0x1TGtlokr0wqFZYsX9SRrOLLeAV0nz9ltZwhEL7cpjnuarHOkjP1N40v8X0x/2fiTh9tzEVY4wFx1QYkijudkEG/a9ufqAu+Qqh+UquJzYScEfNyJ2jWcibhzkXjbJCbMp0SjvkE3qbfJ5Vwv/ObjYsPftBwAJ/cU6g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=+ny/wNuZoyr66v5NmfQ0ulf2O/bvCewWrWpPK80nxoY=;
 b=pCYC7wZqPKOFrAkEjhEdyk0x/yhsYjQ5+NtxRxCPBctQAsCdJsFAz+GJn46CPmD8jIQRANfPKLx/cJGCftJ9Vgqh7kZtZKCsCS0XZkTrsiYw9u/wYfMp4mz/9Y7LHFbicmndo+v6VTrhsctkYsIUBS6sFznmFnClAaAg9d0V2a26PqBxadnYgHTgvNstZffgBqBeLW1XUw+myXBdmUCXsLFTsltYfwkG3LYbPTKobUihLUU4Boow3l3znK66C/FjuMD/ax09ZfET7DtDpH1VCc3Nf3PDXJuObFNni7GgzGyhGPv0GgIxzix0iqJrPMJzUj6CvX8nx46a8pgFV6Sm0w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com;
 dkim=pass header.d=oss.nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com;
 s=selector1-NXP1-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=+ny/wNuZoyr66v5NmfQ0ulf2O/bvCewWrWpPK80nxoY=;
 b=iIHSX6dHOQJzhlMWx9UISqUwXvs5bdMu65SI+rI2eQTS28HDbP4uo/jfHyp0VF/1E+vsSxLeLhtOn8QlGuZnu8pUj+4S9LRpH6tfNCJapm/gSCQZv7krnOxugQO9nV/J71pQO9yxPxiPJ3XGUDcciZPgqaM2yCAAvf5g28v7YjPP3QP82nTIBrpu620EN97j0UmtCMiF5cGcFTONpx2Lx/duJJcBeCLaScn+ln9atmkjnP+zGcN4VstLyV89uxnvQfK3OlhZX+4+bS7EMPsBcsluH9d3y6mJ3iS14M1LWP8D+Po2aNNMnOpfznEcb01yO9t5519gUqtc2P03X6pHdg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=oss.nxp.com;
From: "Andrei Cherechesu (OSS)" 
To: xen-devel@lists.xenproject.org
Cc: S32@nxp.com,
	andrei.cherechesu@oss.nxp.com,
	Andrei Cherechesu ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 5/6] SUPPORT.md: Describe SCMI-SMC layer feature
Date: Wed, 18 Dec 2024 12:11:40 +0200
Message-ID: <20241218101142.1552618-6-andrei.cherechesu@oss.nxp.com>
X-Mailer: git-send-email 2.45.2
In-Reply-To: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: AM0PR02CA0228.eurprd02.prod.outlook.com
 (2603:10a6:20b:28f::35) To DU0PR04MB9561.eurprd04.prod.outlook.com
 (2603:10a6:10:312::7)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0PR04MB9561:EE_|VI1PR04MB10026:EE_
X-MS-Office365-Filtering-Correlation-Id: 564151a4-a3d4-4173-4e82-08dd1f4c7cad
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|366016|52116014|38350700014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?z3IcyEBC31btxwQ+ffsMwhvvRaSlI+jgaqOBDy4BtiVDYFyUVzvB+f64cjxp?=
 =?us-ascii?Q?7MtrIqADsnGM85iTvOCieB/A3DTd8dz8OQvLB1xdi5ZkblXAb1aBsV/jjjZD?=
 =?us-ascii?Q?MrG6yDRBuUHaNv3cUbNgXAGakIwaJ+1us5Zye9N5aRwXy6JRHOexE8s9Xuw3?=
 =?us-ascii?Q?tjQQdsNjtW6KEb2hz5Oh3x9YuBeuZYCNYXCDbfwPjPFZKJutQ4qoIu6gYZ1g?=
 =?us-ascii?Q?wAFGrmaBZvYc5UjfbhbGJ40LDuC6k7ix84bMWnQqgBBgz2UbhMBDv1h3gebt?=
 =?us-ascii?Q?d4EwB4eafsDObMTeZ89gQVC6//32bWAvoEzxYJnoAJQMZ2NXcMHEz1l5o3Kn?=
 =?us-ascii?Q?67J8UtbxujeQdsXAS6AfOsM+TrloC3QaJwTg9GeRfqzMEeAdgqKotoGXTZnF?=
 =?us-ascii?Q?wyB+Vpo8oqTavzyOmArT45OihNSn1tVWuWmqeuhRS8jURvCkHlb8cFUptqN1?=
 =?us-ascii?Q?Ao3AeJY1/oMdPhGbQ+xvhHfFka2rzikTZiqPTYpDpR8tIr7j4GDFgl3hcZ4M?=
 =?us-ascii?Q?RKJwIhGwxVXY2X/LL+phcdhrdYSGUGWTTEWVsQrE6OqcNVqNddWjlw3cTvE1?=
 =?us-ascii?Q?ni2654raNgL5JAHlum99Uxpb3JABu5pzIjUB8aUoM85CY8QfZdFgD4fzRDS7?=
 =?us-ascii?Q?PxZeTodqusuNuTieMLCRKhOM5+O1q5PaOxl1WYk0BvliCvC0FEUxa0BhtoO+?=
 =?us-ascii?Q?ugHi6uihcL7PgI3DJTmf6jRbPx8bI0uBL+3vbvkqLNlZ50l2Na3t9Kwj40uW?=
 =?us-ascii?Q?vOgmrzXpQDNt/VVdphA2dTO+pQmCt+ly2EuUnFTlRGpgSTjAY4a/KV6wSFU6?=
 =?us-ascii?Q?8AbFDfELqW2BYhB0EqyFaJq1OB6OBpyMqQSvPqMg+7OwJSAtf2FKsopktnrQ?=
 =?us-ascii?Q?0BYXShDyfgvvrRESgP6t0uq3A0jwJZ6wznazc6ENj2eMACqemN51rdRV0q8L?=
 =?us-ascii?Q?9byommmbN1cvf10iwS7Ev7R/7Fadp4pmRZpqaTs8bu7DC1FSKiL2SKN696Yz?=
 =?us-ascii?Q?5/x/3w5dy11bPjVipmi4/Hy+cCQIALMx8ZgaZMxuONJQUA6i+qJL6EV7su2A?=
 =?us-ascii?Q?41vU18qAaBQqUizduR7qIQKiHs9zhsZbvnTCqs+V2/K/85E4Z2umZ1Vvd+ne?=
 =?us-ascii?Q?G4PF/Pn1TpzooccWTME8bkzRfrN6q9BA4l2YgPFHNTd98GiT5AktROV4IofI?=
 =?us-ascii?Q?tKd0ZUQYhKwI+3kAMcQPgqil0FrfBoQsWaGb+p+mkXpeR6YWCozirAkOXmJ8?=
 =?us-ascii?Q?2oSR5YCNQU+3o39dE+qznYkoa/c4mcfGjAvjtUh6B3KRWKeGktxO3rNXJC0m?=
 =?us-ascii?Q?WKOaeDCPLDtWxYTmNPOBCnecFnWXwkE3VSe2Ek/ZjkRExTfAahAixYVHcBvD?=
 =?us-ascii?Q?VJfwnLjWzTpt5t6SzkQhDNSX0NieEKQh0Y91HOgaQJD9x/p0D7YSEVX99wr7?=
 =?us-ascii?Q?Jq0+Jzibth/LVhObj6nQPLmNI4wtuw5K?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR04MB9561.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(52116014)(38350700014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?slpDCEM4WducXOVAVtDgdDeo6mdju3hQSAdGe9F1iPi+2AKYTXkwBCDdyxzz?=
 =?us-ascii?Q?mJInXyl2AeyoGI9OzyVujXknqjfe9wH7OEhIkHI0953LBKYuSg7NZCS+/Dzk?=
 =?us-ascii?Q?pS/xyBuPprhJfjVetCvcgQznMCRUX//C66z+OXCnqJKzvwtPmdP9y+ElwbmH?=
 =?us-ascii?Q?8ZaK3gXUBMEdlUbGUhA+TvDezmzGUNfjMdW4zGR/dxbbmhLZyT30ZPmKnUgu?=
 =?us-ascii?Q?Gb66i7OpAInXSTtzms2EDNO4A0i4ZtP7Jg+d/V0uYrQIKUxPZazWRzeVuWud?=
 =?us-ascii?Q?hqpm5+wnbSMBs6xO5ZPWp9JQtSUN0igjpI6RVPJsFlcxSN2mG5+i+5pJl83O?=
 =?us-ascii?Q?mEMesgY8nE0hbU+od3etqK8Hg7Hp2ft5EoaAj294DTdczKyKVM9RasPckSqB?=
 =?us-ascii?Q?fKH798h+c2LRrZ/J95iNiKLEcjYOmB7WTn78YzHYoMM7Gw80Zd3Tw2a6GUoT?=
 =?us-ascii?Q?hluohvc5PTdd2YTuJ1SSaYOiFbbBn5+bRrzC2BqZRQhVUCejhNGeHNaIrX7F?=
 =?us-ascii?Q?/6AOZKe+Yn3qiOpzf4w61D52zLd8092J5wSkLquWkmjtJ6P5hl0zCqpWjmz9?=
 =?us-ascii?Q?0DATu9jukt4EI6XDqz7rnF1W4o14MmA44JaSg05e9B468eKYlEm+Oo5zR9UU?=
 =?us-ascii?Q?iJmxnfsuCOd66GpamlIJ1+rTw4WRJpeHvk9n/ITmzBOAUOFJAqNgQb4MS3F/?=
 =?us-ascii?Q?a6qgHcUHuW/JIqxfE3f1Px+M97FYxYHHz5IrKb/2XbC8MhDwzw5X77RZFK0h?=
 =?us-ascii?Q?TsTksJTbi9C+l8517oWXhK7nC8QVruLKYMGUcCi9WF7qi35rkDV2Bmx+nppy?=
 =?us-ascii?Q?ox2+gKAXmeVZe4va+feSar/qgnG2JeP8ukEjB7E8w5XtqHuzGirSvuoUeSyJ?=
 =?us-ascii?Q?9SEaMO2aR/GX50OP6NHFwpaWaLQh6/1ZfYkS/eJlmi9TxpF6SfJFDD2Cxitf?=
 =?us-ascii?Q?RgiElSHP0K+nFF56/YD+qvjV0miqmasme4VQiFAAq6bRSK6sNQbke6J7T7mu?=
 =?us-ascii?Q?CXGTsh6wrgWQxPj49vLkpIzrWTE+GP1Wbg1l8b5zshYmVZrOODPXawYAsG+I?=
 =?us-ascii?Q?ATI/VVRXX8nIQUTt1mSdIqt+xnaXZeg58QDsd5RKtXk96D4EUoAFDg4gA3qx?=
 =?us-ascii?Q?ckOMbDyj8ybVycs4ojvw2Ko5qtkh0H7QqY+HoqMGkH7vXlfZ2QxlaU2LJFMb?=
 =?us-ascii?Q?q3kPERgl10wEqefL6On7TN+1w2gU3MrifdGvSO1uMzBDPir/hRDSRpJQQJqs?=
 =?us-ascii?Q?T4rZrugex9yG5R5pop5MYhsZEpn5MxSYRWLimZXJcqKQbQi/mCd+cWq8pzHg?=
 =?us-ascii?Q?kJvOd1u7wHXu0JHVZC4g7a9ag1Y0WPebPHJbe3fd6H287Rd3HzUUtayI1fZw?=
 =?us-ascii?Q?UEjV7F/vO5AHVFBSYkuUEimEPFjsTVWoKEGCzFmxt1ij1/8adHlOo1TKxmGN?=
 =?us-ascii?Q?BgXrblHtYBT78SfUYxf+jcS/3J4EpNtBDuF+a3VkQW0GrGJpsPmHRG6TOVg9?=
 =?us-ascii?Q?aV2OYpfJqiclXnYDEZmGbHxnnb3La66DYefW14MI3YSDED1UJIpKB3hwkHPO?=
 =?us-ascii?Q?xUYPh4L5co3AuEFQ1Fg++FL+t+sZhZ0gWDT9g8FNtCY5Q0NDFFQj7t+697K+?=
 =?us-ascii?Q?Lg=3D=3D?=
X-OriginatorOrg: oss.nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 564151a4-a3d4-4173-4e82-08dd1f4c7cad
X-MS-Exchange-CrossTenant-AuthSource: DU0PR04MB9561.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 10:12:32.8270
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: PdD854vRjHxcVrurR5HHLj78dCWLYDnlM0IShip6H7zl92iKNs7ox1Dczmq7D2WtbYI7NSBwoXHXP2FLNEVSA23NA6LUb+AXouM1bX3B4SI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB10026

From: Andrei Cherechesu 

Describe the layer which enables SCMI over SMC calls forwarding
to EL3 FW if issued by the Hardware domain. If the SCMI firmware
node is not found in the Host DT during initialization, it fails
silently as it's not mandatory.

The SCMI SMCs trapping at EL2 now lets hwdom perform SCMI ops for
interacting with system-level resources almost as if it would be
running natively.

Signed-off-by: Andrei Cherechesu 
---
 SUPPORT.md | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index 82239d0294..1f7867bd32 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -928,6 +928,14 @@ Add/Remove device tree nodes using a device tree overlay binary (.dtbo).
 
     Status: Tech Preview
 
+### Arm: SCMI over SMC calls forwarding to EL3 Firmware
+
+Enable SCMI calls using SMC as doorbell mechanism and Shared Memory for
+transport ("arm,scmi-smc" compatible only) to reach EL3 Firmware if issued
+by hwdom. Some platforms use SCMI for access to system-level resources.
+
+    Status: Supported
+
 ## Virtual Hardware, QEMU
 
 This section describes supported devices available in HVM mode using a
-- 
2.45.2



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 10:12:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 10:12:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860101.1272211 (Exim 4.92)
	(envelope-from )
	id 1tNr2o-0007Y7-UU; Wed, 18 Dec 2024 10:12:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860101.1272211; Wed, 18 Dec 2024 10:12: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 1tNr2o-0007XG-Ot; Wed, 18 Dec 2024 10:12:42 +0000
Received: by outflank-mailman (input) for mailman id 860101;
 Wed, 18 Dec 2024 10:12: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 1tNr2n-0006CD-9B
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 10:12:41 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 (mail-am6eur05on20614.outbound.protection.outlook.com
 [2a01:111:f403:2612::614])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9c97bc98-bd28-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 11:12:39 +0100 (CET)
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com (2603:10a6:10:312::7)
 by VI1PR04MB10026.eurprd04.prod.outlook.com (2603:10a6:800:1df::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Wed, 18 Dec
 2024 10:12:34 +0000
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f]) by DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f%6]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 10:12: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: 9c97bc98-bd28-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wlCoSQqz3mzdGdJHIhxwnlmMGJYNYs2cO0iI4KDAkAx4g339+rfKPfTp4w+OjRtf1pwlplpact36mTIsZp8kZVDTucmyY3+AAPKLwdVjdWfBpwRFyJIF72YsmMHT9EVmuVtpdkr591bKFFUFV0dplB3gtjx0iVXbg5Vt0HmEH7fOTs9VpnoTPE6oeiPxh7vvgQljsQ77DNGrM5QCAXZvgBR/oFt//bLw4LVm45YdLdMyom8O9LIah91qzeeqGjD6i0n5HVZ0Oq68V8mz2CqaWR1eTOEsissx6ALnF3cm3rl3j0JLlJxmWkcpv2mcSyXhu2lVap2HOswvocJu74fHdA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XJpPySu7rJ3nqxUBq15kb8jVZtfuU9mQxzBBdWlN/io=;
 b=h5Hc5ZehWpsJeq12ymKGea6tyXK+zPOrYTi0fVlWnVKAxc+cXxKhdWV4OEZi7thOBkIAWJNAsvDpk6yX+kPd2gLAvgSnJT8rApbsBsKx3hG0qo9lNCb5rhinQs+AfRsa2LqnqXMto2ebYS7ZiIFu1Kl6mjledwu1uzRLD3QQfWg7xh50arlSkbfqHGkoa5EsdTgCzFFGfkFklhRJTSSP1vRQP+IVG0W/Hqt66ynWpCZROPWBkCsHvjSqv0NPXnGbAfPFbW174B9NrpD1I2qjSr/fr53VMf7VZ5ZOqh+/oxdvIcxuqtO5ghB/ZkiNbSEGSgY+h4xpcErvhfzpC6HU8g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com;
 dkim=pass header.d=oss.nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com;
 s=selector1-NXP1-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=XJpPySu7rJ3nqxUBq15kb8jVZtfuU9mQxzBBdWlN/io=;
 b=pY3w97SwhKsa7/nPhWZ8Y6K7rS4vCrRo8yAAKIXFQ8MOHYKTAIK++Hb6maUEcItoEM2OEjxJdN7Gjm+db5WqyaYUAp7RFmZK4WFbazQmot2qjAIg1SZxaUgO0nYS0kkoNO4ihLKhqz3QvZys+n7AYCvc8A4RPUgPQ18B/2EeDS6qvYdx3CUyAg+lvBpM2VCbTmIDXzYHEPd9ACy1fy8zHmYa1cncNXqGdKlpdp8cJZEVf29qKxGV/1MA8TMV33QX7RntQvwRq7a3T1SIyZdCsQ7J0/j0EmlyZ/CKCFfX7nhK7NzgenRhhOV9L5XOwtGh113bNxh/VHt4P/VSZ7qOAQ==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=oss.nxp.com;
From: "Andrei Cherechesu (OSS)" 
To: xen-devel@lists.xenproject.org
Cc: S32@nxp.com,
	andrei.cherechesu@oss.nxp.com,
	Andrei Cherechesu ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v3 6/6] MAINTAINERS: Add myself as maintainer for NXP S32G3
Date: Wed, 18 Dec 2024 12:11:41 +0200
Message-ID: <20241218101142.1552618-7-andrei.cherechesu@oss.nxp.com>
X-Mailer: git-send-email 2.45.2
In-Reply-To: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: AM0PR02CA0228.eurprd02.prod.outlook.com
 (2603:10a6:20b:28f::35) To DU0PR04MB9561.eurprd04.prod.outlook.com
 (2603:10a6:10:312::7)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0PR04MB9561:EE_|VI1PR04MB10026:EE_
X-MS-Office365-Filtering-Correlation-Id: a8fc64ad-e49d-4149-7a5d-08dd1f4c7d6c
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|366016|52116014|38350700014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?NllIbjJTQHbp+BYoLdkOg//O5hslMc4UxJijfwfREp7I5Xi9kq5VHENjcx6l?=
 =?us-ascii?Q?msMtP3mRi5WEE2IboyJ4NQjfc2z4QfEuQSS9uBRtpY21B/0KUEPlk2l8XN5g?=
 =?us-ascii?Q?RMgYEOVPmIVeYex4t1mUrQdNcXie0E3e7YYnuzHYcC4Ty/y1TalEvT4vp03F?=
 =?us-ascii?Q?ldJXiUWhHuiS3q35BHNFG6As6YN/oPqs4vJlzcqsixItDUcM3wSMqqBfE+Br?=
 =?us-ascii?Q?UDQ8aMM0mpDXUqISXuFNWVL+E41akg8IgiVQsgI0FNK4JXQ2ECyq+HtafvdL?=
 =?us-ascii?Q?nOC9kOKwnKPBH+khYaT+IgElfQBayDFSGulWIQNV4C+PjzbNyW53ku3uVRHp?=
 =?us-ascii?Q?Obd+929dFOeKs3lhykiaf3GzWHI86Q97YzGsMSU7AJBBeQKjOHHpfjPzcUan?=
 =?us-ascii?Q?TRrcOM06TxJon0cJtCRWzqIab1AbjksriV4ssavtwHVrC2T9H/zoHSVUtuFQ?=
 =?us-ascii?Q?qyx8RWiNCluJS40ITnBWYegX45zigKgBkoKlwX+iA9YxEklqB5Xi0My5IXBE?=
 =?us-ascii?Q?LNgQkAU5XfZbihiFIOlhi0gF0ett1R3l4n/7hKWH5JnfWAj9FztU4xY8A9xg?=
 =?us-ascii?Q?9B0CEwa2GnRlHaCFJ6CU2uu9lg28pIza/w7HL8gnmjv0asHVPW/UceVieMkB?=
 =?us-ascii?Q?r8dnGywrN/6v1pCiCz/SbkBmOPvgi2t3spAH1jsfg2CPfaUSC+kZbKygLZQU?=
 =?us-ascii?Q?Va88bgSxuTMNDdXuiJ85pmn2VaIqBNI3FFNtK1O0XGRBPHyDSX2mREnEJ/3b?=
 =?us-ascii?Q?50/OoF3QeQfMm8GqfJh60BQVCPbPF8Tf5kMGN8L9AtnsL4GgbVEhIcqIyjy3?=
 =?us-ascii?Q?MeK1U6a+/r9/IP1jjBIx3zzbjhNI1qi8N8IQqhC7AAeX+0XNJPxIxJpjC6AW?=
 =?us-ascii?Q?g115kqXEAEYx93NevMTXgrWlCzT27a9nIgmakHHHQF7IKKMQN48M6R6JZI8W?=
 =?us-ascii?Q?CWEG5MCDePDCsq4CMTT56PNrSqf7aJ9CI+qEHP9jlgSqi4v/eel+ehbYOnaB?=
 =?us-ascii?Q?tLaH5i5iAHs8v4N4lUINrlPwbdVAw4HKisn9ds9s3d5TVb4inLGme/s/uEn8?=
 =?us-ascii?Q?h1oVJsyaAuSiOzbe7MaknNPNkUD3B4WrakJGKi5lgUT6VjRi/QktlZSkDlpV?=
 =?us-ascii?Q?5oZe1/0gckwqw0DbDIuueu2L1QsR45ZnfnDmLmF8GbOCUk727WsjH8EwkxJY?=
 =?us-ascii?Q?nHZa8HPSwGfQZInLJn7vYEWPAYuEi8bP/+pcQpaG83bD4oyG5u5BD3l3pXFb?=
 =?us-ascii?Q?qDPsNPYp96DjkdLUxydGeAwwMqtZZMtLVY7noGNuVBj33v6BdIs3nZQ+R1cQ?=
 =?us-ascii?Q?pIJFgiciiY5pZNOchxaqbDNCsHeVfh61H3c8oEuCaWSibju6A9MFqQoD3V+n?=
 =?us-ascii?Q?YssJKvNG45kiRrJ+yuKwjU85XwMg?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR04MB9561.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(52116014)(38350700014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?+RdquEdzX4tg5fb8T6aI+/Ii8OqxlZkLMSln/DrWUhaOoozt4B7aMsrGhYNA?=
 =?us-ascii?Q?St1Z90juT5uH4e3ej2wSA3sy4kY7QtYbd6xd52eoiUrhP8NBAEwzMKxCTi38?=
 =?us-ascii?Q?Y6cxbQcqgQQgBNOhTlXYTuLEAjdZG47gmgMP91CI7B2RP1Lu4qjm8kNPNGlw?=
 =?us-ascii?Q?MOY8xR8jPR2Nnp71UaJXxu5e6tnbJCSwgS0/mQIiUA949NSOi6EiTVRQON9g?=
 =?us-ascii?Q?uttxu8uPAICiVTeSOkZEbsaIrO+w1aQUR1G4ZOvfKd2dTqBrTbdjZz1A/wz/?=
 =?us-ascii?Q?iI8Ar9SWsCOeV8QMjcuU/lDCZibU6BwKVjOYXQNeGsvaSGb/2Behbtxi5/2E?=
 =?us-ascii?Q?RmBRBDWNSSKZGwmQDwSmJ9woQvnoXR9ntGyzXZfKo6/VOAHPEDEJbPYpZ/b8?=
 =?us-ascii?Q?i3vWLHp7RreKTU51s2rUQQcXQt/znCGOlLCuOctFy/G0WrpqhU+Z5ayIaorZ?=
 =?us-ascii?Q?q0iCFs9eUvTpDQh9Ts93mkUHxRO3OiuivrojTcurU4u+ru0Xyqrh+hc1BqdW?=
 =?us-ascii?Q?ng1eBiGfwhpaReYHBXhs8jNb+vh8sf50hBUINR4N8vG+Po1NwHSqglNbCcd/?=
 =?us-ascii?Q?9Uxhc/K+KMIefFeO1yz4zqssnZyqHaioajxxB6huzGmLX90Tx8fxDWUd/cN6?=
 =?us-ascii?Q?isCyqqwCj2Bk+wIEuNvGorhdLUNMptDdiw6fXwgbb350N+kroQwLi4Sb2egv?=
 =?us-ascii?Q?bskb6azr/fReEYqtc3q4U4Av8I9tmrHJTQH6UqsWIibvdG0uPiqR6NhRZ+p+?=
 =?us-ascii?Q?UYNWzMdZD4tI+OSY7Meq/0epVmW5GE1RM82WkOiWkPJuhwcYNt0savkP1+h1?=
 =?us-ascii?Q?sKVeZpRvATuIRzDH14pvV+D9j8dH4LKpiHMp5Wa2JqR8CnqYnNXFSdJY2oMi?=
 =?us-ascii?Q?drM+ZxLS5LAYEFG/QrVdzDtc383KO8aiVNVLg14jPaecO8IGF0UyjUIY4aDh?=
 =?us-ascii?Q?zCDtlAaAsV5uNFnF1t6eIF5c6T0a+6guVFXkkrXXti7FIEP2u4Pbkm00gMCC?=
 =?us-ascii?Q?60/LXO1GZT5omdIBd1JLAMr2MG8e1a9yUZDXHiNl/DoxX9WJB5q1uOimQRFv?=
 =?us-ascii?Q?EB0sf0QdbqGjPcbrOFwBTZ4ROLUgVlBXuc+u0VKlRmZ+ceHChDHaEjS503DJ?=
 =?us-ascii?Q?xtAdjGnGWA9v/swcE5mwCaFjcz5YJQeCSXCsB/elqhje6qgylUFs9Jn1eJtI?=
 =?us-ascii?Q?YewtxknI8XxCtUv32ZLo48C5mj+tlghu1nr7oQEWsEz2VqgASaIPupnq1ltq?=
 =?us-ascii?Q?wsYRbGkGhh9qiQGTRxIXhP179ldVTONJXhj/NRqiZ0Q4jZmzddMbGhX+iB2W?=
 =?us-ascii?Q?1sKF6HXeLMvUt2ulNnrcWpExhKtOPW+/+DHJFyOXd9RRQmajonz4VHJu7/DL?=
 =?us-ascii?Q?DJxktMquR3hhjQHfzY9TDFpZrbiWrru/xB9s+y5F1c9zJ9frR1vlitVip8ZP?=
 =?us-ascii?Q?cEnpfuTHo0BREYFUtIJbnLJtSp5wK4i1YvPoT7sFAUWfPY9PKMHzxilwywAo?=
 =?us-ascii?Q?AEUdRAil5CEYQUP2FFeo9KzCdY+tDCu6jn5K3nJVarIjH/refZeHPNwK0E7o?=
 =?us-ascii?Q?9RjG+uWOp7712Mp55+qG1oxl7nK+FfEZ3Im4w47M356oWLhw2K3hXxDj/KCp?=
 =?us-ascii?Q?lw=3D=3D?=
X-OriginatorOrg: oss.nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a8fc64ad-e49d-4149-7a5d-08dd1f4c7d6c
X-MS-Exchange-CrossTenant-AuthSource: DU0PR04MB9561.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 10:12:34.0479
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: NlOAv3E6YJ4vKPctrhUKKUxXCg933q8HYhD5RyvlyY1To3m0yYcHexLb6wEDCtD9IGZOsmcVE8JvL+7Ul7QagXxn3/fR4UkTtt22KBmi7wo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB10026

From: Andrei Cherechesu 

Add myself as maintainer for NXP S32G3 SoCs Family,
and the S32 Linux Team as relevant reviewers list.

Signed-off-by: Andrei Cherechesu 
---
 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 34ad49bc39..392f780f76 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -426,6 +426,12 @@ L:	minios-devel@lists.xenproject.org
 T:	git https://xenbits.xenproject.org/git-http/mini-os.git
 F:	config/MiniOS.mk
 
+NXP S32G3 PROCESSORS FAMILY SUPPORT
+M:	Andrei Cherechesu 
+L:	NXP S32 Linux Team 
+F:	xen/arch/arm/include/asm/linflex-uart.h
+F:	xen/drivers/char/linflex-uart.c
+
 OCAML TOOLS
 M:	Christian Lindig 
 M:	David Scott 
-- 
2.45.2



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 10:23:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 10:23:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860165.1272221 (Exim 4.92)
	(envelope-from )
	id 1tNrDJ-0003Fr-Uj; Wed, 18 Dec 2024 10:23:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860165.1272221; Wed, 18 Dec 2024 10:23: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 1tNrDJ-0003Fk-QG; Wed, 18 Dec 2024 10:23:33 +0000
Received: by outflank-mailman (input) for mailman id 860165;
 Wed, 18 Dec 2024 10:23: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 1tNrDI-0003Fe-CQ
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 10:23:32 +0000
Received: from NAM04-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam04on20631.outbound.protection.outlook.com
 [2a01:111:f403:2408::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1fc2d9a9-bd2a-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 11:23:30 +0100 (CET)
Received: from BYAPR06CA0057.namprd06.prod.outlook.com (2603:10b6:a03:14b::34)
 by CY8PR12MB7756.namprd12.prod.outlook.com (2603:10b6:930:85::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Wed, 18 Dec
 2024 10:23:26 +0000
Received: from SN1PEPF00036F3E.namprd05.prod.outlook.com
 (2603:10b6:a03:14b:cafe::91) by BYAPR06CA0057.outlook.office365.com
 (2603:10b6:a03:14b::34) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.20 via Frontend Transport; Wed,
 18 Dec 2024 10:23:26 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SN1PEPF00036F3E.mail.protection.outlook.com (10.167.248.22) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Wed, 18 Dec 2024 10:23:25 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 18 Dec
 2024 04:23:24 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 18 Dec 2024 04:23: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: 1fc2d9a9-bd2a-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=M8W7i7pGLAEav1Vz4AtQX01Km4qDmEwk2wLyKOIeGsMrJieJMbMS+IYoU8aQfKGIrlmMYyootOpm7WA/jTTePq9rA2a8upniHdEM7uSOceZlC1hwUWVK4+cm5JrlEQyDYol7hZhSLiMo9Zj3nnxMK7uysFAqRxeNuwPOoRPBWBsZZ7xAtZYJ0J1N57R0kJCyoJCbzwxJz9e1ZZGQxGiY6UoXG7wQUGozfV8nCQrIb0MPZj3CfDfS2nsByUt0opbn28dvWvZvUhG5v/4hEJyCwnKwfV9tl3mBk0MgEV6ynhG6juyLJ4BQWTdplbby5i4UsbrNxNClj5hpsJuDk3Wkyw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=GIwXgD8LDZivLejsJkktFq+0L34VyBvvrz06ovUazmg=;
 b=jrtIyliumdEc+Jk6NOBFta0AUQJHQQp3mJ+zU7WIUZCfwvEVQBDXUTeRz5cIvmUsEXyBpDnAdiIeF038equrTiEj7Gl3ym1q/Jlchx/s+EgK1zJut3InTrZcZgFK3l1Oazo595LlUv+l4Tukia5hFYA8oZfs40YFPXEF5wwrLQcwwjuiKcWoWVvY8hBvSAg+cMCIE5IO+nlU1E8VPLAVgG5jFfqYLiwM5KYrigGWQ+2rizJKKXdsEIhKbb3f0PhDWbW4nhOWAK1cPvfUv7HUd19ypTV6S8/dYN/OmJtdUMTe1+kWIwLMlREvwlUbJVs6g82BCd1VO+pufT5BnjYnUg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=minervasys.tech smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=GIwXgD8LDZivLejsJkktFq+0L34VyBvvrz06ovUazmg=;
 b=mzRwkmfI3dfMLltopEYRFDQ+cs3B3m0EKMRlMsy6ThnK/OsZsl5hvo1KvZoem9ZG7UnLbE65O1z9Sbl99pTwjPBw8Fe2uCkLrXuEqmXZmLkaOLvHS3x5vwZL6QyW4MfA1FURJPFOblOqtswZK04oQzNBVhSzYaEjfnZ+BByCxFk=
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=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Wed, 18 Dec 2024 11:23:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v13 12/12] xen/arm: add cache coloring support for Xen
 image
To: Carlo Nonato ,
	
CC: , , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Volodymyr Babchuk
	, Andrew Cooper ,
	Anthony PERARD , Jan Beulich ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
 <20241217170637.233097-13-carlo.nonato@minervasys.tech>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <20241217170637.233097-13-carlo.nonato@minervasys.tech>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF00036F3E:EE_|CY8PR12MB7756:EE_
X-MS-Office365-Filtering-Correlation-Id: 119ed289-420e-4842-55ad-08dd1f4e01e4
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|7416014|1800799024|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?TEtxMkEwZVI2ZlJlWUJQS0t1d3dkS0JNM3k2RDBYT21TMm9vbkxxTnpyeWNU?=
 =?utf-8?B?VjFyQ3J6Q1V6VEFVaFFwdkJXQXZZR3BqeldsZExMdTM1QTVPZmtVRkZYNzlt?=
 =?utf-8?B?TnlQVG9tRWRPU2ZxSjNXSXBmSXg3Qmh3OWVlWi82NkNsNzlKajF6VlMyM3k3?=
 =?utf-8?B?N2RwMEsyeDhhcGVhQ2JuNzM4Snl1SVR6NVZkR3RIMnMyVjN6b3BDUU5EWG01?=
 =?utf-8?B?ZGZBVTN5OVh0a3NPUTVhU243bGd5S3lyUUdudHRlZWdiSmliWEJydExHYUx3?=
 =?utf-8?B?SS85SlFDTkRzcEJDNFhFTzRYblk4NEM3ekJXNkdiZ25aaTBjSVV1a0tyMzNi?=
 =?utf-8?B?MkFKYm5qUGFZYklCb0hMcC84SWZUMzkzc3IvbUJndkt3WU1tRmxHSExHZjBB?=
 =?utf-8?B?Q3loN09EU0tPVTQ4ZXk2KzlCK2ZSTzZ0a2tzY01JNWtYVlM3SHF4WGgwVUo2?=
 =?utf-8?B?R1VWRVAwa1QvRFEyWGE1NVF3Yk10SEllSnE4SHdQUXhzTWI4bEUrbU1yQnY3?=
 =?utf-8?B?YXZSekttY0dKWXp4UDFLMWR2MnZhVkRHZWhBS0xVS1dYVkxtN0h2QWJDSVNL?=
 =?utf-8?B?SnVIdGhUNDF2MHlyVmNWQzVpWnlHYTM3S2FNeDllZUxiNW9KeUs3MlBDMmh1?=
 =?utf-8?B?MFJRSHFzZGVqeXVFVXFaaWhBTzFBTUwzUXEwYU9uYzYzTm95TXVLeExXUURZ?=
 =?utf-8?B?V2dYSUY1Q2lSV1hGVUJhSXpjd0RjNW1ZUGZVblVETUtvaVdWSERORnBZRU1I?=
 =?utf-8?B?dm5wYWprRk8zSmRvMEtJVGNBYVlmVWVsRHdJOFEwMm11b3dlMHJuRmtTOFhn?=
 =?utf-8?B?ejJSaVp4RG91ZDk0aGkzNUorRFUvT3MyZm1yMHEzVmYzVzdabUFSNTNxV3Fo?=
 =?utf-8?B?SUV4djNSVGZseGZ3Q1ZPM1FXbWR1WmRXSWVpSGR0UVRCRXdDbURjbVdRYWQw?=
 =?utf-8?B?M29NbU5ERGNyVUVDZkdPU0orV0FoVS9ZRWtkbGpNR3lpSlVWcTBTWUpzWHE0?=
 =?utf-8?B?NU15KzNTcUczVFZwditWNW5qNVpYekxSUzd3d0JTZmlvZng1SUdKWkwwVytm?=
 =?utf-8?B?YTM2a1I1eW8xN1NIdzBkSlJoSkEwRGxFeUh4UG1xZ2pRYWJoL0FJQ3MzYUVi?=
 =?utf-8?B?TndmNjBjMGJhNFdRdE5jYWZZQ0dnbnBDV3JuNU5qNjBxdmhhNkhKM2xXWDZs?=
 =?utf-8?B?bEZueU92QStUMldtWmZIbnRaVDJLM0IzcENCcklYNWZXbmZpWGc4ODNmUUF6?=
 =?utf-8?B?ZVVidlhtZ2kybXFCZ1lWNTVVWXh1d21VMWR6NnNWSzZBTzE1emlPTFVyTmd4?=
 =?utf-8?B?YjQ1Z29oOG4wL3dXR0pCZG1Mb2k4aE51MkRqemVIQm82em5pTElwZGVyRTkw?=
 =?utf-8?B?OXRqWnZ0RDRKbDZTMmFCR1dSeFpHZUFpYmZaVjB6QUs3SmFiRWRBZXBQL1lq?=
 =?utf-8?B?N1NveGZ6K1BkK2F1R0VVZnpscE1ybWhHMUM2dTZNY0UvS21lQVg0eU5HN1ZC?=
 =?utf-8?B?UlYzQjZURDB6NHpVT3VuSy9lOTlMQm1kU3YycnJ2ZlM0UUg5UlR1SkhvYlFr?=
 =?utf-8?B?cHl1VFR2ZXFtRFIxYkQ3bUczbmYyR3oyamc5NTViTTdCT2lPZDV3TWVPNktt?=
 =?utf-8?B?L0V1M2x2RGEwb3lhdlVSMy9tWGlFWTMyS3diT2Zkc2NlT0xMenVCU0JXNUI0?=
 =?utf-8?B?a21GdjJDNktBMEZDY0p0bEg1SjFDQjV5WW9zTmRHaFVVMXNGWU5oK0c3aTJw?=
 =?utf-8?B?WTZMN0l5MU9XNXdTSmRVSHg2RWNPSjZ6VTNEQ083U09lanQycW1xTDFvbHBz?=
 =?utf-8?B?QU50THFZbWpkY1hoNzZ6U1paOVNQZUpmWEFCYzRzSDdxd0lKNFJtNXhMVEVl?=
 =?utf-8?B?ZmY0bXliRXhBc1ROMlpyS1VBQmNraGJVSWozWWRUR2FlS1d4eXR3Q01NZ1hx?=
 =?utf-8?B?akdaZTUrYnd5RWR0UjNmQXREdVRVWkpoNWlWZStpYkNSdENkUW1QNkxhSXJD?=
 =?utf-8?Q?/ZWp16YFuP8E7cWEOGF5z1cvjeuoiM=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(7416014)(1800799024)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 10:23:25.5348
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 119ed289-420e-4842-55ad-08dd1f4e01e4
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF00036F3E.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7756



On 17/12/2024 18:06, Carlo Nonato wrote:
> 
> 
> Xen image is relocated to a new colored physical space. Some relocation
> functionalities must be brought back:
> - the virtual address of the new space is taken from 0c18fb76323b
>   ("xen/arm: Remove unused BOOT_RELOC_VIRT_START").
> - relocate_xen() and get_xen_paddr() are taken from f60658c6ae47
>   ("xen/arm: Stop relocating Xen").
> 
> setup_pagetables() must be adapted for coloring and for relocation. Runtime
> page tables are used to map the colored space, but they are also linked in
> boot tables so that the new space is temporarily available for relocation.
> This implies that Xen protection must happen after the copy.
> 
> Finally, since the alternative framework needs to remap the Xen text and
> inittext sections, this operation must be done in a coloring-aware way.
> The function xen_remap_colored() is introduced for that.
> 
> Signed-off-by: Carlo Nonato 
> Signed-off-by: Marco Solieri 
> Reviewed-by: Jan Beulich  # common
Reviewed-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 10:24:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 10:24:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860173.1272230 (Exim 4.92)
	(envelope-from )
	id 1tNrDs-0003ms-8d; Wed, 18 Dec 2024 10:24:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860173.1272230; Wed, 18 Dec 2024 10:24: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 1tNrDs-0003ml-5i; Wed, 18 Dec 2024 10:24:08 +0000
Received: by outflank-mailman (input) for mailman id 860173;
 Wed, 18 Dec 2024 10:24: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 1tNrDq-0003bh-QW
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 10:24: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 35b2e2b9-bd2a-11ef-a0d6-8be0dac302b0;
 Wed, 18 Dec 2024 11:24:06 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-434e3953b65so44229605e9.1
 for ; Wed, 18 Dec 2024 02:24:05 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43656b01b15sm15680355e9.11.2024.12.18.02.24.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Dec 2024 02:24: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: 35b2e2b9-bd2a-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734517445; x=1735122245; 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=YS+5P/aX1yh02DWMDsvkBVuu4fo/DhWyk7tGFN9ATjw=;
        b=pVMBRpWcG/dmonXFxy2d86oAQjGIA5++boX09qj1etwMrZXJ2pMZBX54ry0iB7Q6Ji
         gQw85DnTacuPYoywn9jUG8KstyeeCrTg4T0nzFcP8xor0HRjN/NCKTKxl8mHWKKB1aqi
         uRbeOiwI/iWVNTFE5g5DTRhMU6rtI/r3UVUXI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734517445; x=1735122245;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=YS+5P/aX1yh02DWMDsvkBVuu4fo/DhWyk7tGFN9ATjw=;
        b=tSRs9Gy11+B0bpvzvkeEZcqfLeMGJKDndtEur67didiaJoCqfnFRWuiRF5CB0lJ5eE
         ExOd9r1KpBSQ/n3qprYJQ9EZcVIDU4s8UtPpcrux0RP9VDGCdBHtMZdP/nYcJFxi/+hZ
         uudvxUmMS/uQl/wS1dYNnfA1kl210w14b9GzXzs9uECtBrw+lIzQoBaNnBlBAbMJ6nZx
         hEF+JJNAS8Zido42QGnPDIDGQIMtvMB8vorNMJ9YJ+qS/jC9ELHuagJK58zm2zIPHOd+
         5ocGzUUiAB+2MONoGrxx/nztGKPGwfv2hkJu93DQZ6GewyOfrzF4H84I1es4Z9k0r2er
         +hAQ==
X-Forwarded-Encrypted: i=1; AJvYcCXBZOiCGX6mOGDkH/12AHj8L8pg9H5DkOHTF7XnMGfs725+rH6k2QKx4DrOULHpS9b3NtB4FoN2C0M=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzweF+GfBW0cdLtLTTCYqke04MISwSuedph5TztXPMQ8QGBi5AV
	L7FkJgIqVmQ6Zk431FkP7OnPRErssaR0SmV9N6CLDjt/RdgllaElolnpSJpF8CI=
X-Gm-Gg: ASbGncslYvM6/hRso/M4yu1EUL3xhHy8UoG1/FTcIwwMkMQesH/aWXafRLY7EfFXEb0
	/VQiPU3+a6tC52nycDw8qNWaKeJwzJA8lqWnoFoiwjMyIL+AhjNdD+qsTDCgBhpmDk4veHrwN/j
	tVNxRnOzeIYHeDgEgO2+FOqS1QosmIe93sM1CKnn3EJinFLAk7BEIVHFkjsBHx6T7gcSAlzwFrW
	7TKX8ASwaaOb9XixtLuunrxMWyrMy/Jnpf1GGNI8/v00pM4zfJBs4jE6VUqwGvcj3v8bZiRcb/N
	nY+c+Cgp9z4v1nax2IUm
X-Google-Smtp-Source: AGHT+IEjQXTDL20kKa43MEPyxK1Ekvd44FjJiLFz/QhS95Es/TgF4g+Hv25GrNTLsSY7dmT2KRwAPg==
X-Received: by 2002:a05:6000:2a4:b0:385:f13c:570a with SMTP id ffacd0b85a97d-388e4d6bb66mr1877408f8f.7.1734517445313;
        Wed, 18 Dec 2024 02:24:05 -0800 (PST)
Message-ID: <44db9406-f835-425f-b7b2-c86d14eb53d9@citrix.com>
Date: Wed, 18 Dec 2024 10:24:04 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
To: Sergiy Kibrik , xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 "Daniel P. Smith" 
References: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17/12/2024 11:47 am, Sergiy Kibrik wrote:
> Allow to build ARM configuration with support for initializing hardware domain.
> On ARM it is only possible to start hardware domain in multiboot mode, so
> dom0less support is required. This is reflected by dependency on DOM0LESS_BOOT
> instead of directly depending on ARM config option.
>
> Signed-off-by: Sergiy Kibrik 
> ---
>  xen/common/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 90268d9249..7368ca8208 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -374,7 +374,7 @@ endchoice
>  config LATE_HWDOM
>  	bool "Dedicated hardware domain"
>  	default n
> -	depends on XSM && X86
> +	depends on XSM && (X86 || DOM0LESS_BOOT)
>  	help
>  	  Allows the creation of a dedicated hardware domain distinct from
>  	  domain 0 that manages devices without needing access to other

To ask a questions not asked elsewhere on this thread.

We are expecting Hyperlaunch to supersede and entirely replace what is
currently x86's idea of split control/hwdom, to this point where this
symbol is even removed.

Has this plan changed?

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 10:28:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 10:28:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860186.1272240 (Exim 4.92)
	(envelope-from )
	id 1tNrIB-0004QA-Pa; Wed, 18 Dec 2024 10:28:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860186.1272240; Wed, 18 Dec 2024 10:28: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 1tNrIB-0004Q3-Lu; Wed, 18 Dec 2024 10:28:35 +0000
Received: by outflank-mailman (input) for mailman id 860186;
 Wed, 18 Dec 2024 10:28: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 1tNrIA-0004OL-8F
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 10:28:34 +0000
Received: from EUR02-AM0-obe.outbound.protection.outlook.com
 (mail-am0eur02on2060c.outbound.protection.outlook.com
 [2a01:111:f403:2606::60c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d476a0ea-bd2a-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 11:28:32 +0100 (CET)
Received: from DU2PR04CA0331.eurprd04.prod.outlook.com (2603:10a6:10:2b4::19)
 by DB9PR08MB6604.eurprd08.prod.outlook.com (2603:10a6:10:262::23)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.12; Wed, 18 Dec
 2024 10:28:28 +0000
Received: from DB5PEPF00014B89.eurprd02.prod.outlook.com
 (2603:10a6:10:2b4:cafe::fc) by DU2PR04CA0331.outlook.office365.com
 (2603:10a6:10:2b4::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.23 via Frontend Transport; Wed,
 18 Dec 2024 10:28:28 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DB5PEPF00014B89.mail.protection.outlook.com (10.167.8.197) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.15
 via Frontend Transport; Wed, 18 Dec 2024 10:28:28 +0000
Received: ("Tessian outbound 050b604d5e06:v528");
 Wed, 18 Dec 2024 10:28:28 +0000
Received: from L7bafaf49c52a.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 80CBF525-9593-4D91-A286-D5258F9015FE.1; 
 Wed, 18 Dec 2024 10:28:22 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 L7bafaf49c52a.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 18 Dec 2024 10:28:22 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by PAXPR08MB7441.eurprd08.prod.outlook.com (2603:10a6:102:2b9::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.20; Wed, 18 Dec
 2024 10:28:20 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 10:28: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: d476a0ea-bd2a-11ef-99a3-01e77a169b0f
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=Pi7IrmCl31VQKIvteV6R0IThvk2mzRAMJQEIznXTYlko8A1DIpHhfMiSyeDMXQGc33py7ieI97+mkGdKWOcf+8Psukuw2BW98tQ1BjcQDl+TEeYh+8PapnJcHDQt1G3B9ECrAy01vanNyYBEn6mkRNtj8jYl3G3rVyiC/2h7P1WL+e5ng38TSzt1W96NAUiXbYS3g9xT589U31GbERCHBYvij0JslLG5m6laWTPnraXUsjMMPbQRoy1E8Bl3Fd1PbNvoxEMCQPaHwgccikgYOL4gBEt+AwNJS7R3FzxqeQTeuwLxKcXpHnT3KvA9/OVIAh8jZSy7UXjJ8gnu8947wA==
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=Z/RxLuNM/Ln+yHAclQMwKgcB16Z9vIKT7b87KvtPl0I=;
 b=TYnEjmO7lC8mRy2PDwobH6MZR3OQ9YiX7pIzpE1m5jihKYU7X0rOOV56iVseCiLL2HykhGgPLbteHeBN4ZkFqo5s9NEdVNDPrgt0AlSDbTXgBTiV3+/MXYzXGrL/l0+Fj/MupzyAKNmEtWHxRckcOra3tqRbTUEqGESPrMQ0IAWfvNuL2YgQ9ESvPbF+r4IDltN6oj+zxhRRXtzfhgA6Ckptkd6/F02s9GCFJcUdFdkx299wphwtUropUngq7QyxqszkDD1etCuwJRwKco8dj83kB96OlLdEt5TtY2w2r1xtzD+PuNzwxEV7p1B+Ho05duW6QUElRtBaYKuU+U2JMg==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=Z/RxLuNM/Ln+yHAclQMwKgcB16Z9vIKT7b87KvtPl0I=;
 b=CP22rpCsg/h1t5vVSv0uu+87OuGUe7/znfLbtcZwuQFotVhdG0pvMk7tkOxt1j8gcKGk5wAA+PHHyNKTv2Nzbvt42d60lfqLMIeWbt9KgzTDbO6TMwkszS7zypUZVYbDOWwlq3bR/KvYCTKkY+F06k08YvLX8KTTb/1LSeb5K3Y=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 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
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 3561336bd54bcb67
X-TessianGatewayMetadata: UTg4N5+z8jB+N1nmw9i3bvNriw5jW64lMHdIykJLJH9As/yKlXvB2GFlPkO6L39yuYQTuN6hSzxCq8cEROg/UIWu/1eu0zlPKxSR1S/wIt62hns2y/MoINGJTh/7JVcYREzhWooKc/2T4drYQBdUTL/GtLThkkK24hfrjFIhOOU=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wryjcTlzezGyFkuGOGuf6Ff+ekeles0litPOQaIy+vYlFlnVIJCEj3ooBJxX/i2viJhxvkepw+h6iM7OM9IO3sbMMb2/tKqPPZsOF2U89DSf+UKLjxNjyL6QGmYCdc24N/qcx0ejo8MpX4+eMqtx5irVfRQEjyTrhEFghF01uW4ervnkj+2nDwzT4IVoWMLAZkI+E5rspHjTBfbTKfJG7mJ7UgHJ97D57mca7HoySJBQFtOdd8UHoWuzEbxDADB63N59Sb4St7Ms7lwkZ37/FFE1KuMrNFFEMxaheQ5Y/B8i+ZUu56/Kc31xxAJahxraCncW2SA3bb5wgpXI8PzsoQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Z/RxLuNM/Ln+yHAclQMwKgcB16Z9vIKT7b87KvtPl0I=;
 b=nnPZTH1be8gitKJ2ntRezDrNcVMLNdKmDyg2gnfgsg9NW/o31HMM8IPPTu0Az416LBlnT1i1BFLhJNAw5Kpzuio7DhyozZIpGN+ADNIH/xNEOXQr4wdKGHvErTn4x6EOwvQlY47Swvc3id3sALG+LTgcJ3tk3o6tnQCT7mXLvRA5PuqcYhyfnrEnVmqNZzhSVcXuM5t6foPGVujcrdq8H0JI0cqrzLFdZ6RdjfUfx+BHgV7klTBB8+LGoCcMQSNPVqQNKvlMN1EPk8kGWG2e8bFmnFD6NV7Ne/rFDUzk1b2/3E82X2p6UrE20cGMZim3jvdzRElS4ptfK3b9FViH8Q==
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=Z/RxLuNM/Ln+yHAclQMwKgcB16Z9vIKT7b87KvtPl0I=;
 b=CP22rpCsg/h1t5vVSv0uu+87OuGUe7/znfLbtcZwuQFotVhdG0pvMk7tkOxt1j8gcKGk5wAA+PHHyNKTv2Nzbvt42d60lfqLMIeWbt9KgzTDbO6TMwkszS7zypUZVYbDOWwlq3bR/KvYCTKkY+F06k08YvLX8KTTb/1LSeb5K3Y=
From: Bertrand Marquis 
To: "Andrei Cherechesu (OSS)" 
CC: "xen-devel@lists.xenproject.org" ,
	"S32@nxp.com" , Andrei Cherechesu ,
	Stefano Stabellini , Julien Grall ,
	Michal Orzel , Volodymyr Babchuk
	
Subject: Re: [PATCH v3 3/6] xen/arm: platforms: Add NXP S32G3 Processors
 config
Thread-Topic: [PATCH v3 3/6] xen/arm: platforms: Add NXP S32G3 Processors
 config
Thread-Index: AQHbUTVdoMCMlYyvB0KhW/HQpIvTvrLrzKWA
Date: Wed, 18 Dec 2024 10:28:19 +0000
Message-ID: <4A3FB0B9-DF46-46A9-9390-4281FF72DE4B@arm.com>
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
 <20241218101142.1552618-4-andrei.cherechesu@oss.nxp.com>
In-Reply-To: <20241218101142.1552618-4-andrei.cherechesu@oss.nxp.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|PAXPR08MB7441:EE_|DB5PEPF00014B89:EE_|DB9PR08MB6604:EE_
X-MS-Office365-Filtering-Correlation-Id: ce706027-0518-4ec8-21cc-08dd1f4eb654
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|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?wvV5FKHeEcIc6dXhjLNmWkD6I3Mch0PPDwpMwXSvaMyc2YmsIcZ/CKXxOzRR?=
 =?us-ascii?Q?JRy4qquSmEoV5a+RXDePG5BBAN1mTXe96y0LfUMWBlDyRkmHywjOLAUj2baN?=
 =?us-ascii?Q?tryrcv+vR4HcssXUNL2Nl7h66aTBCQGtvv/e8r7zWUbulmeEESwOHMOyvmdc?=
 =?us-ascii?Q?wT1BGIm14tqaNVCYP1N99krXhVL4sFh/+k+bE98JwOek3UPReaLa+6admPEW?=
 =?us-ascii?Q?GSkexbIThTggJF4R9C4yg949uvFBCWss1ebwHBbgWoaYj7BrofhAtTQ6BxW2?=
 =?us-ascii?Q?wmmkJYoBL85iWGvy9wsiKsL6Hygo0hqOkEYJZ1HGvz3QLmau9femIi/1OA3A?=
 =?us-ascii?Q?jRDGe8Uqu4sR5MJcyz+sHjwjpvC+5CLsi/6M8Nv7qX2hBwlp1/tESTRIZE6I?=
 =?us-ascii?Q?NtEJIwtBM682rio6dFG5ZER+svrCmKEg4gUpURMJhI/34Pla4BACpJeDp32H?=
 =?us-ascii?Q?zYaeFeQ78GqhMmC/7kHOncZoWy9s6lfB8Mz7LcgvdQR9/N6L8YWMT8Ck/Ikd?=
 =?us-ascii?Q?JtHMw0r1ua8iuwbitQjSgMCpqjPMsYTPmLWGo8wdmYq3+SOj4FU1Bit8lpbq?=
 =?us-ascii?Q?pBuv07p/izDps7F1zcNV9XIkP/GszcU5IeZ8uQq0zfnGYmXUVM3t85zKZaYt?=
 =?us-ascii?Q?73aBy7N/msdBZrh6gvnWjgA618GjH82SlS9iWtqPklV9eORXda7iB147tzMc?=
 =?us-ascii?Q?YPGf86c02iWFJG43rKpj93g/Ao5Pa3EqnlFc6JU6NDf2tP59TP4cwf4dJIoA?=
 =?us-ascii?Q?iG2oG73gO3+G0SpCnM5XnFRCfTQGvUjGrYeX8yax4/fC+7Tl+8rzrGyddjRo?=
 =?us-ascii?Q?NkiJlrEs3Kgi6DVFbUoSmEYsMs4Qh0HDH/OOa8AMgMmhWC0gVvK+lRPHnRNy?=
 =?us-ascii?Q?RN1yxFPYawUUSeJsJXzNJ1Z8Tbk9wRnltfGQzrP/GsmjdLkvhPByc9WpdZr7?=
 =?us-ascii?Q?fFsvKKBTxeZAMck1frpYvG7UladRC8gJMZjUb5AARmIGbg4pd8azepPxcouU?=
 =?us-ascii?Q?1IEd4RDjnX6yu3JvbAOpJ5E8MLkZklEh/1Pz9k8SUTIQ20FQ+hz8mwYoklH2?=
 =?us-ascii?Q?5NQuW95mFxqVR8fHMJEbjrYHVy9hTi7aPTuiVbTVcsgx26Nh+cQiucDXxirq?=
 =?us-ascii?Q?y87hUtFZ9jOi+yA25bP0EPShDp3ssRDf+ysPYpf9WpEQHhAXkiLJRAQtvRN0?=
 =?us-ascii?Q?9Hb+w0Xz1p06VbJk6PyVRMWnZ/DVaCl8EWdnA8i/XGgHOn9QBDzt9g/WtK+q?=
 =?us-ascii?Q?ZNvZLdbiCdc2LWNPk05htZh36sfnC2Flr0f8/Chc/Q4FMjPVU0T4GeId0fsZ?=
 =?us-ascii?Q?KFXZoTjUA76AJYDesgVoZbrMQGdgHaTX1C2Cn15zkqzxo4wJxsURbqReTFIq?=
 =?us-ascii?Q?1Av01VT3/Mg20r26/Alp1W4KMzMP3MYrBonB9H5b2yHJV3MDFcWMWrhHPF6e?=
 =?us-ascii?Q?0okp/l3HoVVjrWJDWXBuePsF5kz8mJRd?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <244BB12504C2644A8D643392A35F5E6D@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR08MB7441
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender:
 ip=[2603:10a6:10:25a::24];domain=DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB5PEPF00014B89.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	7b9e7244-8be3-45b9-b509-08dd1f4eb14f
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|14060799003|36860700013|35042699022|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?l6auXQTpLmtCHu4KDUORosg/nqa4dE4i31Fue8+iFcf+pkbB9qPmHNCsTr5x?=
 =?us-ascii?Q?6MZrNgeORIJcAmz5deZs8rTuL4XQJdHsXCuD8EmasmmPtPf+BtK8x63X4din?=
 =?us-ascii?Q?e47tLCUT8YMB6k+X/bkmYf9Fo+dYPBe1VGpQ1ZjvQfYcmIDxCJBkfKCCP1E0?=
 =?us-ascii?Q?zbILWnhAph/WCpXNM+MgqwIJeYsSZc1sDpRe1z+EkOepAilsQ+L8id35ToRx?=
 =?us-ascii?Q?OXlYYgB69JKIQjy0xznBOEkCr64kWT5tlJzqMgJobinz5tZiFg8bG68ASwKB?=
 =?us-ascii?Q?AxbkzFg9xtvOInRCaUjTV6gRN+s/orT2DS2wmXceUxI6ZOPy0X+zu+h1mafa?=
 =?us-ascii?Q?KQbN+vDoE+BQ3qj1NpLCQFqpe1FDsxo5laOI7aPAve3zLZwuTiZiXmcGhSnt?=
 =?us-ascii?Q?XbxMbRB9cw3Uip4ZoGt2aLu2iQu4fxD3kJ4lwm0S7qRcGy5uH1df88dZ4+Po?=
 =?us-ascii?Q?H1NqTVDVYlW5/I/iNt/x9TamdWy9tq8CiAJR8K32/Qgi4fimNiV6KDd1AEEa?=
 =?us-ascii?Q?3n1W/r8kyhKCO+79tMz+xTHZ97OX2rvMsP2Vy6qlQ1mia0l/E8c6WG7z4VPG?=
 =?us-ascii?Q?WWER39ctyod+Q+AZxEVHPU1yj0JJRiydwuRMkqAUg9olCJqoUflu6dP32u3o?=
 =?us-ascii?Q?KZWQ9/TfzpsJK1hGQn8xNFDtU6O6NxoQE3DlK50whdQmY9TP8zv/y16lIx+E?=
 =?us-ascii?Q?t2msa0W0LqaMtnDrN3UDLJFNo+all0yqw51lTEUmHv5qmqW9Ksgh95DpBfNo?=
 =?us-ascii?Q?Hy6WWDQivT6oIGVaxyQmdYD1CqbEG/KfJBuZDNZ5/cPdkhakahHlEvAPpxTx?=
 =?us-ascii?Q?qiV8oRt30opSUNzgHyqQn4sAxGzQZLDTnuQyNgqEEkxIJyydhGJm6Wm1xNnR?=
 =?us-ascii?Q?2AQQ4U9Iz4GRDYLIzYFbtAzS6Cjknq9D3/Y5fEqpw7XsU4fXBpv4PGWJThFC?=
 =?us-ascii?Q?3oJrPn9QKOiAQwJsCUgKpJCo317ZArKyidn9xOMXXOQZySWoVgEr2cxcrFE0?=
 =?us-ascii?Q?l2WhUhmZq6fIdOXHIV7+mXjM/zZcvwMoE2FUsZYI7DrCP7oWMX0KZNcO5gf7?=
 =?us-ascii?Q?vUTUhWmpUhupOUQN0xarm+tl4Is/4jkaNx01ySWlgU76Rt+fbZBOFELZgLL5?=
 =?us-ascii?Q?Sbpw9/T35SrcRIPen9pOcC47Rf4dcn2e5Ct0Sw1w4g7jTPJzy9Mmy8UEETkM?=
 =?us-ascii?Q?Ei1w/AiihAsh0rlWwha9KyHGPflLGgr7mohpYPOtg+J/1JtOFN79CZHqo1pC?=
 =?us-ascii?Q?ed7oK/nStENHk9a8ubxtikDzBfaO+iWN/zhyU6DB5heOWN3om2/CtvYedAHZ?=
 =?us-ascii?Q?8iXfTyLC0ymYcv++dONxZNpdI5Wtm48COS5hLCsUoyyMyCJ/8SyefdkEPZiB?=
 =?us-ascii?Q?uNpAolZxeFhP0TV9yjKDfoc9z02C80GoFS+qiJ66SbCedWHHExhgzqLMT0fd?=
 =?us-ascii?Q?qWWv4yBiluBn8qvZ8dib9va1L6NSMqTTgnNlihFVeG6mVxQ+bS9mC0ckvLUR?=
 =?us-ascii?Q?5uCn1nWycuttlu4=3D?=
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(1800799024)(376014)(14060799003)(36860700013)(35042699022)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 10:28:28.3199
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ce706027-0518-4ec8-21cc-08dd1f4eb654
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB5PEPF00014B89.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB6604

Hi Andrei,

> On 18 Dec 2024, at 11:11, Andrei Cherechesu (OSS)  wrote:
>=20
> From: Andrei Cherechesu 
>=20
> Platforms based on NXP S32G3 processors use the NXP LINFlexD
> UART driver for console by default, and rely on Dom0 having
> access to SCMI services for system-level resources from
> firmware at EL3.
>=20
> Signed-off-by: Andrei Cherechesu 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/arch/arm/platforms/Kconfig | 8 ++++++++
> 1 file changed, 8 insertions(+)
>=20
> diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kcon=
fig
> index 02322c259c..6dbf6ec87b 100644
> --- a/xen/arch/arm/platforms/Kconfig
> +++ b/xen/arch/arm/platforms/Kconfig
> @@ -37,6 +37,14 @@ config MPSOC
> help
> Enable all the required drivers for Xilinx Ultrascale+ MPSoC
>=20
> +config S32G3
> + bool "NXP S32G3 Processors support"
> + depends on ARM_64
> + select HAS_LINFLEX
> + select SCMI_SMC
> + help
> + Enable all the required drivers for NXP S32G3 Processors Family
> +
> config NO_PLAT
> bool "No Platforms"
> help
> --=20
> 2.45.2
>=20



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 10:30:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 10:30:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860195.1272250 (Exim 4.92)
	(envelope-from )
	id 1tNrJg-0005qF-37; Wed, 18 Dec 2024 10:30:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860195.1272250; Wed, 18 Dec 2024 10:30: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 1tNrJg-0005q8-0D; Wed, 18 Dec 2024 10:30:08 +0000
Received: by outflank-mailman (input) for mailman id 860195;
 Wed, 18 Dec 2024 10:30: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 1tNrJe-0005fS-1y
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 10:30:06 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 (mail-am7eur03on2061d.outbound.protection.outlook.com
 [2a01:111:f403:260e::61d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0afc0f53-bd2b-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 11:30:04 +0100 (CET)
Received: from AM6P193CA0081.EURP193.PROD.OUTLOOK.COM (2603:10a6:209:88::22)
 by DBBPR08MB10409.eurprd08.prod.outlook.com (2603:10a6:10:52c::15) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Wed, 18 Dec
 2024 10:30:00 +0000
Received: from AMS0EPF00000191.eurprd05.prod.outlook.com
 (2603:10a6:209:88:cafe::2e) by AM6P193CA0081.outlook.office365.com
 (2603:10a6:209:88::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8182.16 via Frontend Transport; Wed,
 18 Dec 2024 10:30:00 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 AMS0EPF00000191.mail.protection.outlook.com (10.167.16.216) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.15
 via Frontend Transport; Wed, 18 Dec 2024 10:29:59 +0000
Received: ("Tessian outbound a83af2b57fa1:v528");
 Wed, 18 Dec 2024 10:29:59 +0000
Received: from L5b45ef019223.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 A6AAE435-B818-46AB-8189-B2CE82B05F2C.1; 
 Wed, 18 Dec 2024 10:29:52 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 L5b45ef019223.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 18 Dec 2024 10:29:52 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by PAXPR08MB7441.eurprd08.prod.outlook.com (2603:10a6:102:2b9::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.20; Wed, 18 Dec
 2024 10:29:49 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 10:29: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: 0afc0f53-bd2b-11ef-99a3-01e77a169b0f
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=AEz+fc/gSDYGAy/j0pheN7JmZzUQ5WL1/9xqrvIeDv4Uk13hzJV0l7JkGTtKrYb50IdDhvMrLXHTWlLi26iHwLYIfBe4uiVMWvGVg76fYdtRAw+hZZpyYMT2dzha+jc/mLEOcIxGrSqKfOUD10i965DDq7hC0wec1uLo492F7Ld73hp1h7knGVMCvc2MNzt4kBHqkJT7rY/d/Rz6M6/lccDuCCYD+Ec5vWvr3cVbN6u9fMq+djAsEwpUBYTFVnT2VbapCcxs35rfFTusRKZSrcEUd2kAgueD4qbA8gJZ4iiOCgXgFpB+MInOUT4sEoSH9jopRObP2pmCbddh1VQ+bA==
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=KpY5ky/zBA/dTqQohAVQY34Oc6qNSC/Fm0xgCQXpXZs=;
 b=pOYD/KWO4N0F0rCQOBhPolhvAMl8gcBNKytvhcjXe/HsCwBaJsN4Kpv6TjewB/Oix2TV+7gKWE4HOBk/XZ/nSvamoB3rl1xZtqlHKHNYPnP8B6ajTPAYhWO7k5l4pWSRiN9muVYfCFVuHGDsuyPGxJBiM+O+e2E1bZk3lZE65RUh760cINDh4ouAXFBz7qlNS6x4WRmsHF5NG/OB+eL9EsUSs40wRqMXBUIQ1GxIblqloWXcHmmF44XTRPBIVPTI50rIUsx2am7Rh+m9zBHAHUNyMeVgzSa+LGc/bLKrQtXYWtLj9XsMmB73hxjhg9IqiH8BLHgQT2Wv5FDlWguqZg==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=KpY5ky/zBA/dTqQohAVQY34Oc6qNSC/Fm0xgCQXpXZs=;
 b=bi2MfO0vkLq0ppHgoEKKPdeT2auYzYp5O3Qx1B05fYrez4ObFyhavv3m3bkWBqUcedbPi1rMST26MCV4yc1CWAD4vU3+FfC8GbOS3Wvcd8BHpK1oXeFHGfhlsN02af4RSaCWAOJVLh2XnDxv7viiHBP1EwAMoF79908Q/BXHxYU=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 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
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: f3509fde17742701
X-TessianGatewayMetadata: 99Z9Zy9+RKyCQeaZPLRrj8eisSow9/umlEYLGS7pptPSqVBFxOVlj2uMIaUfRSN6p4unlpGMnUss6yaiUMubMRqUpQvZU1Em3lQHJHrm4YQp7qIG6mpbyFLhO/2mjy/iujNsGJVa30AcQAyMoEL5nRvTmFXjl4xphXC7x4mzMHE=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=itwKjtN03OJNOLGkKX4xKx2xJHwCMfmyARdqLfuMraKfIVTQ8rcInK84vCoBX6iS/kbuO+Rh3aHWr9+3uNvi0HEVrdhFNKzBS7DgqyTJRkg2+wUMHCmPIm0KvycYTb7g+exYIVS3HV6WcgO8zs5jCtM5hRf9Q4BlcMxI1FMh6qmZP+bIybLNug0McIo0czjRIlC2GitavT+mRA4sRRHvEnbm+d3lMDermN8JYLEGZQ9HXbOZTxKhs3nlwJ3Uq0jw0IQtkKgydNEQH6c5whFpqWD4pqZAG9bAxFsJ3Jxr9c8zFDnci/pYxFZc1eY9nkdv0bZynGFMdOsOrOhhysYzPA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=KpY5ky/zBA/dTqQohAVQY34Oc6qNSC/Fm0xgCQXpXZs=;
 b=bAcNHisddOCh76TSklvA0igONX6pHF93St+G7wRm0G/t7Q96oNVDYjNaWtI2Rx6bCcDvNwVjIiFAJaGcxuPGOudA0TbMIA6Z6c9PsNuTvUSJpHm3J9Z/6ENeMnUhLtqqk5nwfX+CnNFvymzSQb3rLLS10tbyO8HE80Izcto1WfGZAmaJG9y8h5vEN3QMNUG7goh1MaliG1ciykv8yuD1h2sXp5Ug6Kq3cR/4MQ50hkklJM/lWtXu9fa+tiANE6pIYS86jm3Qa0pzv31pMjXJku2pey0XdOSgaHHIm0Liqg90fCHN7zlpn3+kvtJMXcwaQcXkqtwYTlHB66BcpcDUag==
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=KpY5ky/zBA/dTqQohAVQY34Oc6qNSC/Fm0xgCQXpXZs=;
 b=bi2MfO0vkLq0ppHgoEKKPdeT2auYzYp5O3Qx1B05fYrez4ObFyhavv3m3bkWBqUcedbPi1rMST26MCV4yc1CWAD4vU3+FfC8GbOS3Wvcd8BHpK1oXeFHGfhlsN02af4RSaCWAOJVLh2XnDxv7viiHBP1EwAMoF79908Q/BXHxYU=
From: Bertrand Marquis 
To: "Andrei Cherechesu (OSS)" 
CC: "xen-devel@lists.xenproject.org" ,
	"S32@nxp.com" , Andrei Cherechesu ,
	Andrew Cooper , Anthony PERARD
	, Michal Orzel , Jan Beulich
	, Julien Grall ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini
	
Subject: Re: [PATCH v3 5/6] SUPPORT.md: Describe SCMI-SMC layer feature
Thread-Topic: [PATCH v3 5/6] SUPPORT.md: Describe SCMI-SMC layer feature
Thread-Index: AQHbUTVpexJk9aIxckuBUMUJS0lzQbLrzQ8A
Date: Wed, 18 Dec 2024 10:29:49 +0000
Message-ID: <9806AD58-30DD-41B8-BAC8-F408A9BB16D5@arm.com>
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
 <20241218101142.1552618-6-andrei.cherechesu@oss.nxp.com>
In-Reply-To: <20241218101142.1552618-6-andrei.cherechesu@oss.nxp.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|PAXPR08MB7441:EE_|AMS0EPF00000191:EE_|DBBPR08MB10409:EE_
X-MS-Office365-Filtering-Correlation-Id: 9fa02655-e0e6-4183-1916-08dd1f4eecd8
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|7416014|366016|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?iso-8859-1?Q?kOIRrPWzL0stOQcP6J0zVPCETOZ129wXdjtXqR+znkM0/LmLoV19hblFtq?=
 =?iso-8859-1?Q?nQCwGMZS5rlkQKkjZzkZwh8FD3lqqNP5YMe4fzILUQWPL5SSH6HdJ64RtB?=
 =?iso-8859-1?Q?ROcVFjq93UYlALTOaokXGkzQaDhbaE0AAuYhArL+GsrMyTgvQ+LGmwL2tk?=
 =?iso-8859-1?Q?LrLVAhMPMa/FlmzH7lasb6eo6EEywdgC9YpJjebHO9lcbDtFBmFTRSwgrj?=
 =?iso-8859-1?Q?+yFKT+IfSOXuT+eLrAA4A6YrjK5jOgn60nfbxcvNfZW5XAY209aR7PAD3E?=
 =?iso-8859-1?Q?1DyydEsFx+uroTfrr8Ng/RV4wUQS0hOLsRE+EsHiZXILhTloWenunQ3qhw?=
 =?iso-8859-1?Q?TdXujKqur29Ow/TO+ZZiEiZDYSlTKInmmsrq/F+d9QARX1A+628/7dMcY9?=
 =?iso-8859-1?Q?CGhtDuz0gydU63R/MN1lnmVUTTc3n6tD/4Oo45kzfDSuJSODiPrhivOq5G?=
 =?iso-8859-1?Q?Eh3S4XJoPpTjeWvP8TLgalt4maj5hntUBIWDNIpqMxn7A5fTc7WAa8PS4W?=
 =?iso-8859-1?Q?8iSfSa+Jc1td1q/uIjSsthSkRz4meuUbM/EUrUpmnqMya4a8DNOtT5j8Mq?=
 =?iso-8859-1?Q?Ts9F7iTBZAy5bPpIr9CGNfBebpzGitoE6HKZGbBw2jqZFgmGp5imNq1XA+?=
 =?iso-8859-1?Q?F+yThBJp4mxdeIc9gX5fIvxSAIAnQZGN0XLyLIHM8ldPuPl+c6Bufo4gGo?=
 =?iso-8859-1?Q?GiIoX0RIr7Ljo8ZAydy6OH1NgygbeuCQfrakBwpklsdhgtcKBVW8jv3ttr?=
 =?iso-8859-1?Q?TlezcNd8VZZHd9It3TnVny7zA/B1syGtGygv+ifTpSvDtYOmK/pPqd+Htn?=
 =?iso-8859-1?Q?iHH5fKvDxfIdM7uLlGJIZNG8XjlVGyWyOyU471CUijbuxL9f76WL0d7xxS?=
 =?iso-8859-1?Q?Poh9S7msYZY7UduYlm6hJKO0ZR3QsQfxr8zWCLB7nq7IesKM2TY0YItSjS?=
 =?iso-8859-1?Q?lXVvckV6girAYkHkbfPJnJab224Zm7RHzZGEvrIx3JjvkWLD3TZnAlJY51?=
 =?iso-8859-1?Q?h+aRfyLhCZf+TlXorkjVTb9mApf8JPWS7qwh3dUGGMBQwuAWg94Zj1aA18?=
 =?iso-8859-1?Q?DF/j7slHB/WzIBPe734JZcfreF/45KseL8nNBPHwrhjsmFqXwr/IMYCyE+?=
 =?iso-8859-1?Q?Tq4pxzn2E/k1KXujBxWqQTwZOV6mqxKkHP1zg7yPjiaS1YloMMAxZUFZhW?=
 =?iso-8859-1?Q?Bw7MDI6KyIVABsBs/9VJJ8RYt4AI4wTXSSf+ViO6OG95Cd8afFt41Ik+qH?=
 =?iso-8859-1?Q?oIw56zp+k5gkAZKsmlN1PTPvS0uz+z9DucOdx9SNbCJdM6J/Z6fVW6HD1G?=
 =?iso-8859-1?Q?thxSGhTmy596zCNIqe4j7hDoD+7CjlG7nbmyDeied+bG8M42bzPiHWgiGd?=
 =?iso-8859-1?Q?PJN8m4D1XDhbXfhevEmFirfpjKqYvxRNicnjjNIF/jHCQsr9gNXSmNrBOL?=
 =?iso-8859-1?Q?9jhoBP/E4I8WSce0tW5UW052cDRtbbW432IjVV9PfviBbb7shuEDklL1Yk?=
 =?iso-8859-1?Q?xCdwdIgLBmoYk3xEPS6rd5?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(1800799024)(376014)(7416014)(366016)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <2ABA8EC79B27EE4DBFEC565AF2A8E6C6@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR08MB7441
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender:
 ip=[2603:10a6:10:25a::24];domain=DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS0EPF00000191.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	81f1f598-35d7-4a09-7a80-08dd1f4ee685
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|35042699022|36860700013|14060799003|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?iso-8859-1?Q?jam3tIemTyklo25Pco0+408BQj0VKJIC+4C+BX2h9k3bakTxo0LAVu3MmP?=
 =?iso-8859-1?Q?tyBxtJSvJtDDaAbFdYDn6QH3I2me+LZhRUPiJs2TIhx6w2fqBYw+fGQodB?=
 =?iso-8859-1?Q?I1Oe450LrDX+v8sFmp4UMJTigb6y313+w5Y09qjfgtVmjVjInq0uhwK0Qw?=
 =?iso-8859-1?Q?xudFlBYgF7pXS4pYTk7WoKtq/twO4pQZpP6AF9kC0rJCBzJgp8hmPzG/0k?=
 =?iso-8859-1?Q?H6Riib0px6UYmMiyLUZRd4sIqY8e9/eRX/JVNLjKzA3HBfRKnvF/4orHYm?=
 =?iso-8859-1?Q?SeJ0jZbfpeSYfz47x1P3nCWJvN36y4jIIB+PlyPNGJHgRRmdbHAn3Kvafz?=
 =?iso-8859-1?Q?7ePrRgrkmHaTKNS05DQPLIC9eo5NJE1V0xf3jWiOhTr86AnK8ZDm77QPOw?=
 =?iso-8859-1?Q?rCabzIsBAyOT3Cv9rE1TxBw1cjC8LXbXrdZaE2PCWNZSIfejlFw89m29B8?=
 =?iso-8859-1?Q?brXC1Dwvmz65nwlhZdBscT08xpV9bxqodzZ0HF+brK2y9O9q0elJh4OJ46?=
 =?iso-8859-1?Q?olBJVjX0l0r48Gs/tmPIt+y40LLDRUBsRTgrpe5ZOPs3ZnWs3ldIuZCvqJ?=
 =?iso-8859-1?Q?74KZGwwZ7X0d3Bfv+ouzh7VXA3U3edspmqNWoS6ObsCPLgOkWLXp/Wy5hm?=
 =?iso-8859-1?Q?DfimWjGzYGiZcdVwbM+lVfyTwkV+XWi1vyHtYG6yzsGC0BHc4HWNwGXkk6?=
 =?iso-8859-1?Q?Hr7zOH3IQgxBs2sfayZQ+0f8ZkOC8YZjVl8JUGm6UqGswYeCXxNMciT3ma?=
 =?iso-8859-1?Q?NcuDe07ZC+7aa1lJzusd//xmUQQ6N19jT79GZBg/xqX/gbB35oFVRfCUsC?=
 =?iso-8859-1?Q?GumWmgQdeItopT68SR6S7N7tDqc8n7Behwi1VbbahJxG9UN80b2rytn3MR?=
 =?iso-8859-1?Q?AaRBVqpjSsrJfCRFnrj8Wi9rAZAb5T/Y0ufmw6GhEVw9lidW/qQHF8KNh+?=
 =?iso-8859-1?Q?pk96qCYWo07XY06ZuWej1VPiUwJsZRWXrNW3XC/IG2HFjpEDKomj4sDWOB?=
 =?iso-8859-1?Q?Bh1L1fw9l9rPYabjwtEBin+hvhG0GvhvYdKp0WcrZo2HJRYqiiTYjaF8Zh?=
 =?iso-8859-1?Q?s70x3lAYBK2MCFpR05qUDlTi0hxaW0aA+4Elyisij2Rm3dZVPshMb3Kh5B?=
 =?iso-8859-1?Q?krsKfriB7NWRN2+KLbGUK3eqFpb6snAxQSuzjHKxbI5mttLscR6qfSRdXQ?=
 =?iso-8859-1?Q?BLMjQKQ76Fo9Y2XpfTyiDIwp3Sgr5WPXxPOllArYQlluEyy2K9a4aKFwaw?=
 =?iso-8859-1?Q?tN64N9sKWRyrMVXFtoKzxy/7p7JmNhEzxW4fFSYWbwq8+1SFR5XLvqh6uy?=
 =?iso-8859-1?Q?vIECahMq+4OTsInsQIYBDZMl29lAEI2gsBGGnHvtNNSygnIHn8j9Ocxm+y?=
 =?iso-8859-1?Q?nkcSj3YAzpCDzQCydjM50ToZz780NPKhhU/ESU9kRXeTmLfD/mx4zf4qK9?=
 =?iso-8859-1?Q?hPSyA7kmUvbIH192gLLsq1uem0qzkmBnLSYVeTE5dl9YhXdP/gf0REE9Yg?=
 =?iso-8859-1?Q?oWtRIoJrkh2EwnAVR3k/I6ogCgIWy6+aXQTizSoLKDByb7tT1RAYDicShH?=
 =?iso-8859-1?Q?NCvErjk=3D?=
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(82310400026)(35042699022)(36860700013)(14060799003)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 10:29:59.6254
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9fa02655-e0e6-4183-1916-08dd1f4eecd8
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AMS0EPF00000191.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB10409

Hi Andrei,

> On 18 Dec 2024, at 11:11, Andrei Cherechesu (OSS)  wrote:
>=20
> From: Andrei Cherechesu 
>=20
> Describe the layer which enables SCMI over SMC calls forwarding
> to EL3 FW if issued by the Hardware domain. If the SCMI firmware
> node is not found in the Host DT during initialization, it fails
> silently as it's not mandatory.
>=20
> The SCMI SMCs trapping at EL2 now lets hwdom perform SCMI ops for
> interacting with system-level resources almost as if it would be
> running natively.
>=20
> Signed-off-by: Andrei Cherechesu 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand


> ---
> SUPPORT.md | 8 ++++++++
> 1 file changed, 8 insertions(+)
>=20
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 82239d0294..1f7867bd32 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -928,6 +928,14 @@ Add/Remove device tree nodes using a device tree ove=
rlay binary (.dtbo).
>=20
>     Status: Tech Preview
>=20
> +### Arm: SCMI over SMC calls forwarding to EL3 Firmware
> +
> +Enable SCMI calls using SMC as doorbell mechanism and Shared Memory for
> +transport ("arm,scmi-smc" compatible only) to reach EL3 Firmware if issu=
ed
> +by hwdom. Some platforms use SCMI for access to system-level resources.
> +
> +    Status: Supported
> +
> ## Virtual Hardware, QEMU
>=20
> This section describes supported devices available in HVM mode using a
> --=20
> 2.45.2
>=20
>=20



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 10:31:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 10:31:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860207.1272259 (Exim 4.92)
	(envelope-from )
	id 1tNrL5-00074i-H2; Wed, 18 Dec 2024 10:31:35 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860207.1272259; Wed, 18 Dec 2024 10:31: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 1tNrL5-00074b-EE; Wed, 18 Dec 2024 10:31:35 +0000
Received: by outflank-mailman (input) for mailman id 860207;
 Wed, 18 Dec 2024 10:31: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 1tNrL4-00073J-7p
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 10:31:34 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 (mail-am6eur05on20605.outbound.protection.outlook.com
 [2a01:111:f403:2612::605])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3f8a0126-bd2b-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 11:31:32 +0100 (CET)
Received: from AS9PR06CA0766.eurprd06.prod.outlook.com (2603:10a6:20b:484::22)
 by VE1PR08MB5808.eurprd08.prod.outlook.com (2603:10a6:800:1a1::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Wed, 18 Dec
 2024 10:31:27 +0000
Received: from AM3PEPF0000A795.eurprd04.prod.outlook.com
 (2603:10a6:20b:484:cafe::1d) by AS9PR06CA0766.outlook.office365.com
 (2603:10a6:20b:484::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.23 via Frontend Transport; Wed,
 18 Dec 2024 10:31:27 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 AM3PEPF0000A795.mail.protection.outlook.com (10.167.16.100) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.15
 via Frontend Transport; Wed, 18 Dec 2024 10:31:26 +0000
Received: ("Tessian outbound 7762b28e8285:v528");
 Wed, 18 Dec 2024 10:31:26 +0000
Received: from L8ead62827de2.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 6494DB7D-C8AB-44FE-9231-92A304A622F3.1; 
 Wed, 18 Dec 2024 10:31:19 +0000
Received: from EUR03-VI1-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 L8ead62827de2.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 18 Dec 2024 10:31:19 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by PA6PR08MB10596.eurprd08.prod.outlook.com (2603:10a6:102:3d2::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Wed, 18 Dec
 2024 10:31:17 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 10:31: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: 3f8a0126-bd2b-11ef-99a3-01e77a169b0f
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=y86I6R2MbDliKRzoTz3vf+HJaz+pEhUn1CdjpN9kNG0UsNHcaoYxkA+WdErtdCEbUIAO7EloQXVhz9rUgvu7ofZKOjw6cpe/nk9B2Vvkc0Tm87E4n7OivuKzjG2pZvOhsprL9NStq2lwz4HoazXP3rYB5hb3jj3KIYTPiuVv042XLYLo11ID6qNdVE6MirSiOOLsfnDOCD4A1bUSvQ62YnPoS9VhBUhyg5K7U+gl+sC7PPndxX7Nz6LXHBVU/UcOJCq8XYQL8DyHSb2T92KrT5kgH+cc27UGXEjnlsml4hGdf+tHkJWxXkO3XOkvuWBHph96yWttlP1ZAImP3RzQKA==
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=XvFb/YkbOfvCQQaqPS0KwmlWw53m68Z8ywAQu3takZo=;
 b=HZlcYzyJrJf7Am42kHtA7taRxy3oj/j5gvg9fbtPEDc8hGWtRfq+6JJtgf11rOJCsvRViDviDT4zw0WbTiYJK0emD+0CMimSOVxEBn2Ev9WS/6Bl34hpOtCLicxUPfQCyEuFibNqQBk5jOAKi/lgvpMKMDQbLS9Ox+FPKteuoJzdt9Mgp6BxPHbseonMn8I3EjMs/jMbmSRUQkwtn1TIqGGpFu4/6m5XVrimyuOE2lPAnMoZxi+7EomuLekZnE5zdgzQqhMDlE2wLkkVhn08sGrgiyY8x095g9nQ7dFe3RyqF8c8QFYUx4yovoxwkwfPo4hZeVxjF05NcTMhKDo3fQ==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=XvFb/YkbOfvCQQaqPS0KwmlWw53m68Z8ywAQu3takZo=;
 b=LRhEFFUL5Kcq8CwRazGPVMxMu030CtvdKioTsSnnW2n+Z518WhMrpKovrcYvH7eT/DQuk3NW1Jh2uBjDwZKcfGpw90GqwxkJF78KSyLsr+s5L8Yypq7+mtOVltLLRciZ6HA2pDPA4vdJIWyCkl+G6vuRxw/rQcwCy058IXAzXEk=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 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
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 2483c5e19d521824
X-TessianGatewayMetadata: E/oToG7MS6fAHhfzcDreG68O3G39OaxoQJIuun9UEoNOmAOJpMzR7EAz9cGx5XYQttPdauINh2iYzP/0/rIRiPyAM8jjy88WGNaHu+ukaj7L+hRFarKMRuIj/+8+X5ddhWdWe2evmSnbz2QYBXAS2bzK+BuBgICjr0ryFYEzDKE=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=kyIT9l9xZESCjxr5CmQdQSD4Pb6xo/RnzmNc/8pJ90ppSk7l4XvGb5jVWy8r4plpY2rvDJL1EaGqoJxbEWTg7BW2p7edcpyvk0hWZwYua9+8u0G0qOdAgepJA6LNhKMN/GaYle3/K10AbUM5UVE+6wIJDToZKAJgMHLW7y0RLeFPGiG0fX8n/9S+YohA/GA0AYndVMI9WyuA7AhB3HDU5Toy9rvoB6fHANflMIjIPt5qulVW9qaz5Dn/hMAZb2dAr8HSVqAMfsQg48wBX0TOVmPspfsCEkOvWwTO/ECff2pcbi0uWBhrNX4H+mmi3ONV41V1QZzpV0CYzK6dw7kaMA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XvFb/YkbOfvCQQaqPS0KwmlWw53m68Z8ywAQu3takZo=;
 b=SaChkPYmIcGlt8hEMwHzGuD0sjoV2c1ijEgXr+lbvBsytJVZ7cAEj3qb/NuS6J/7IRDI1lJuN3gaPcIDm+LpHDwASnlhCZEcoocg7dA14FB87RZ29BAFZaXD1TN0WJGYZiKF/tmNSeSrmaw1+UzujuWo4dSzHGU+H12QWZsJrGEOb7VucSnpwv/KJ1iowsbEAj/qxFr65Zkmbt/TFG3iXo4nUMIcUlazLW8W2ElfREBPIq8zMregmMWHpJCigUql6ggAKbEZNs1Q0nB8cWDNVIAmSIKFFDjmc5XZ4h9sfNyodzHCKDYNbBlb8C7WpYdL5jj07Sk2bUhg57gJMxnNxQ==
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=XvFb/YkbOfvCQQaqPS0KwmlWw53m68Z8ywAQu3takZo=;
 b=LRhEFFUL5Kcq8CwRazGPVMxMu030CtvdKioTsSnnW2n+Z518WhMrpKovrcYvH7eT/DQuk3NW1Jh2uBjDwZKcfGpw90GqwxkJF78KSyLsr+s5L8Yypq7+mtOVltLLRciZ6HA2pDPA4vdJIWyCkl+G6vuRxw/rQcwCy058IXAzXEk=
From: Bertrand Marquis 
To: "Andrei Cherechesu (OSS)" 
CC: "xen-devel@lists.xenproject.org" ,
	"S32@nxp.com" , Andrei Cherechesu ,
	Oleksii Kurochko , Community Manager
	
Subject: Re: [PATCH v3 4/6] CHANGELOG.md: Add NXP S32G3 and SCMI-SMC layer
 support mentions
Thread-Topic: [PATCH v3 4/6] CHANGELOG.md: Add NXP S32G3 and SCMI-SMC layer
 support mentions
Thread-Index: AQHbUTVpe1TKVZ0f70abV4SIRerMBbLrzWwA
Date: Wed, 18 Dec 2024 10:31:17 +0000
Message-ID: <81856AE8-57FE-403C-8986-2CDF4685D014@arm.com>
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
 <20241218101142.1552618-5-andrei.cherechesu@oss.nxp.com>
In-Reply-To: <20241218101142.1552618-5-andrei.cherechesu@oss.nxp.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|PA6PR08MB10596:EE_|AM3PEPF0000A795:EE_|VE1PR08MB5808:EE_
X-MS-Office365-Filtering-Correlation-Id: a357e087-478a-4928-408a-08dd1f4f20ae
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|1800799024|366016|10070799003|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?PZKvb5rMk52VMzbSL7Y8J5G9ZD29/8xfASiwaA2SsYBWd4zwhYi8P0ci/vwj?=
 =?us-ascii?Q?6ojnkLqwygxV8V8N3DJRLa9BJWfkloCbZjGv38KQV7Re+ckP8VCe19tKuaN8?=
 =?us-ascii?Q?lTapR1YvTDad33A9x8I8GDHsYJ5sWp7VvW3DLTLdZmNMEAOgpWcozYaRxh2B?=
 =?us-ascii?Q?Wkk+rywKbTa8BtVA8FFvVUFN1Ns+ol8KNb4cxx0OzVQiOgFhlIAgKQmYpV0m?=
 =?us-ascii?Q?HeWpB986RZ+7MZjTA+wznWm23NbeT9kqpzByQRsul9GkP+jbryV7estXoFGd?=
 =?us-ascii?Q?f6YlmAtOPkACtw1hBzUXU1hiyoAl7GesY7h13mGlgmuhp4SSWFbjNO80BMxu?=
 =?us-ascii?Q?N1NfiK8BE0G6zAXZ64lvC7O98pqeTxEcWKxqbZz4vM3CsebUXFv7qvrlfmBe?=
 =?us-ascii?Q?yyYVxjLL6MyTd4ZDtG0+NDbmT92xS77kWHaWJRt7wvTAYOz22y/kwHz2+Ukm?=
 =?us-ascii?Q?86Vjb4KgxE3xbgnFoEKq2p0H8rXk4KrrCrkiMcLx6Ga2QAvnXEA/qqtA8iHx?=
 =?us-ascii?Q?I7tvEzZZnheiEtP1Pcm+EF+n7mV/zdDGuk0nPVOiNGfcuegg5c1EvOr8cFNz?=
 =?us-ascii?Q?XsBE8reTpNz5tuHzWgGEJxBP/DmASlUIQQGzjVGmFbZwCn2VGUbg8MzN4g5o?=
 =?us-ascii?Q?qFkCKHaVhdsvmP0ZtlJegH8fsUGnLDUho+U5qxfCgkfe26q72GdT+4BZRz7F?=
 =?us-ascii?Q?oPnuKY7lFTRQutwGFpmPhaFBee49tnaDQZNQoa6ytq3jT2GFtiRjgD7kZQNe?=
 =?us-ascii?Q?DD0nOjXyLbYfmVLzK60GmceVFnomhR13z0hLYjWOd8MnN3G8FG+ESP7Ox264?=
 =?us-ascii?Q?gzKd95EtbzXUbN/O8xpMU/6B7u4LY39hvrMU4OWho65FzJKqvG9hTU05EsCx?=
 =?us-ascii?Q?DFNZiMMONxjslYFoOyqj+Xd950iYDU/48kq7TwJo6qMuOckEd53M+mTTWE0Q?=
 =?us-ascii?Q?vn60XNOhInifg4JfbFFtWXvMrjThH2r20Dpdx7mCKmETisPbYD1Z2/ASFNQP?=
 =?us-ascii?Q?1o+9JOAiL81+shokimG6RiqKHPNTQDZ2yE3GVR/Wpaonxdp+QqirQ+wz/6K2?=
 =?us-ascii?Q?nngsgcnJqWOLPTy7oluzuHMpuJn4O4Q8IeJKV6BlGOHq4/OKodyvYVVmey1s?=
 =?us-ascii?Q?AK1vNR2VtJfFSwADGr/SX+88rzDoBX+iUbkxf8zGUuQ78/+zkrFjI/Ei7WEg?=
 =?us-ascii?Q?kD0689by20ovRQyf6tfNujcnmyjHxySjBDZ50FvmK8rHlRHDhikjjLKy98Np?=
 =?us-ascii?Q?7lFiu2zn+JEWvNCscr0C4PSY+DHUaYJF1Cy8G1Iac2gADkNcsC8c2dx6RGbB?=
 =?us-ascii?Q?Ua61KTbCbDYGiKOj8a4w8WTkb5t/kDY74S652cK9Ym5Q4xiLqansihJIzHeQ?=
 =?us-ascii?Q?6oN2ZxCVBzPsn1I5PitkZG+5dnk4?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(10070799003)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA6PR08MB10596
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender:
 ip=[2603:10a6:10:25a::24];domain=DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AM3PEPF0000A795.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	fbd51403-df42-487d-bb55-08dd1f4f1b60
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|35042699022|14060799003|376014|82310400026|1800799024|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?9LVXPxV80FtyP/tr/JRG9oLKFrKlwgDFovqVV0m1oVD5VqUIddZYaAeuqI1j?=
 =?us-ascii?Q?MQxWgKVxttXdDh8/bwuTYk7K8aEhpX3QXJ0Sx3vqrPOSucmIiOyHKJIN1EgV?=
 =?us-ascii?Q?d9wH+xUMtEEVhRnPoPj4nsbX2/Qe43Nu3yZ3nTFV3gf021ko1vLpm93hKJVS?=
 =?us-ascii?Q?ZnlTM0I0U72z8UV4LO7CmmqEfCUE0lu3wejorAFPuOKxbLfdTOK8C2wMU55x?=
 =?us-ascii?Q?R0IGq5SzB17qn3UD3lp1Z9ZbMP5T5xDE86ZPQxPNcC9jOmRS3YuuQXuIRGGD?=
 =?us-ascii?Q?9xW5o6j8xyUR4rGMnfN7MGlrWRPzLeJn6nn29RQbOrQboxiapNFCiSb/VOEv?=
 =?us-ascii?Q?ZaD7tpEWJavAHjuTQD1Q6KOXCtewGS3OPch6LwznxYSvEAmI7T7iLX7QDnZf?=
 =?us-ascii?Q?J+rwA7BhErOwTNhCd+SZjlNs02bswenOrd7YNqRdlBFUAdsl9oHYEE0tsJ6n?=
 =?us-ascii?Q?bQLedVEBUOudjj/3b6QcTj3eMQjtAUpI4EXJd344iB1I7swUOIb5f+vXgqsy?=
 =?us-ascii?Q?/V5j4aO+TK2Fq4Efxc5eIv72RsP8Z68vlvkofRqRLPIv1bAd6NoW23SYQMBJ?=
 =?us-ascii?Q?rM46sAJH+wLqoCQM8xzqOhHIxHpxZ69++O7xV8/9jzL/1ra8p7VmYeZXc6Cu?=
 =?us-ascii?Q?1UUoEQw1Arh04FabeqNET8WEkWh8Y+h0fOrvkzkO2BNkDMFmHiGwHeWB9x4+?=
 =?us-ascii?Q?h4ZnzjNU4XOTLgVGnqj27s4+sP4ODyHg1SYSof5G/ty1VCM9EpzS2g4qaY6/?=
 =?us-ascii?Q?fcvLE4Ww0DxgX7n6hzsrJdcS+dy+wjq1Zp+zuLUA9VygKgA+g0b/IFLJ3XpQ?=
 =?us-ascii?Q?vkiY4KVGIrhFZSWf3PW65fEZzDpVzma8SebqfaMif+V2l12HxWuZUfx1C1o8?=
 =?us-ascii?Q?NdrpxnnqYIvnfT/ge+zHI+CZiixb9UivkWSRwtEDMTYg+db+VJzyl6YiMXqm?=
 =?us-ascii?Q?3C2Kp7osZpamZxueDfkdKtu0dxC30tz08VDxrymgBi8wu0fzkIJG22WGMtl8?=
 =?us-ascii?Q?1zCS8jG3hiZtPCSLs2pvYWxISjbWUCwd7gJj9AFbS/ShIltXwq/4M3Q8s9dE?=
 =?us-ascii?Q?0zRxg0DcjXY/bISaOE9xBE0UvirxcEDzRS37TmdvOaNq5IxrUa4/HBb7/JG9?=
 =?us-ascii?Q?WVBwnjefytH0zjoQLYnU+fq4RaLyTMkMgyv2PSdAsZ7hqc2d9UQBhq2m7vEj?=
 =?us-ascii?Q?HQo3t5h9pUid2vG5zgbW69kXCveOuUvuLLZQGj1ONd4CDGnAt9yniHfGLG1c?=
 =?us-ascii?Q?7EmbE0Rw9ZbayIsVHqG/oO0P0OQyeK50sRgvigxU2vwriw6YnAD7Tak2EpNt?=
 =?us-ascii?Q?livZi8iSa0httic50B17WMv25hudZ6/OAlir9iXjdGC8U260TWvjUqNHzeEC?=
 =?us-ascii?Q?eMautz/GfbWclH8VW55mI7faZzoyCL+11Bzn63dGfO1rQAdJJhkwQbcIvmm4?=
 =?us-ascii?Q?mvdQR3e9U+e/g96/29gMVJloba775ogS?=
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(35042699022)(14060799003)(376014)(82310400026)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 10:31:26.7021
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a357e087-478a-4928-408a-08dd1f4f20ae
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AM3PEPF0000A795.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5808

Hi Andrei,

> On 18 Dec 2024, at 11:11, Andrei Cherechesu (OSS)  wrote:
>=20
> From: Andrei Cherechesu 
>=20
> Signed-off-by: Andrei Cherechesu 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> CHANGELOG.md | 3 +++
> 1 file changed, 3 insertions(+)
>=20
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 15f681459f..bda43b1efb 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -16,6 +16,9 @@ The format is based on [Keep a Changelog](https://keepa=
changelog.com/en/1.0.0/)
> ### Added
>  - On Arm:
>    - Experimental support for Armv8-R.
> +   - Support for NXP S32G3 Processors Family and NXP LINFlexD UART drive=
r.
> +   - Basic handling for SCMI requests over SMC using Shared Memory, by a=
llowing
> +     forwarding the calls to EL3 FW if coming from hwdom.
>  - On x86:
>    - xl suspend/resume subcommands.
>=20
> --=20
> 2.45.2
>=20
>=20



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 10:31:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 10:31:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860214.1272270 (Exim 4.92)
	(envelope-from )
	id 1tNrLS-0007gL-Oe; Wed, 18 Dec 2024 10:31:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860214.1272270; Wed, 18 Dec 2024 10:31: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 1tNrLS-0007gE-Lo; Wed, 18 Dec 2024 10:31:58 +0000
Received: by outflank-mailman (input) for mailman id 860214;
 Wed, 18 Dec 2024 10:31: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 1tNrLR-0007ZH-4g
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 10:31:57 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20621.outbound.protection.outlook.com
 [2a01:111:f403:2613::621])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 4e3c1b16-bd2b-11ef-a0d6-8be0dac302b0;
 Wed, 18 Dec 2024 11:31:56 +0100 (CET)
Received: from AS4PR09CA0017.eurprd09.prod.outlook.com (2603:10a6:20b:5d4::11)
 by PAWPR08MB11014.eurprd08.prod.outlook.com (2603:10a6:102:46c::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Wed, 18 Dec
 2024 10:31:51 +0000
Received: from AMS0EPF000001B3.eurprd05.prod.outlook.com
 (2603:10a6:20b:5d4:cafe::8d) by AS4PR09CA0017.outlook.office365.com
 (2603:10a6:20b:5d4::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.22 via Frontend Transport; Wed,
 18 Dec 2024 10:31:51 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 AMS0EPF000001B3.mail.protection.outlook.com (10.167.16.167) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.15
 via Frontend Transport; Wed, 18 Dec 2024 10:31:51 +0000
Received: ("Tessian outbound b519d6c64997:v528");
 Wed, 18 Dec 2024 10:31:50 +0000
Received: from Lde0024bb5d6e.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 BFA3AF59-3423-4220-808F-33BF3B81EC32.1; 
 Wed, 18 Dec 2024 10:31:44 +0000
Received: from EUR03-AM7-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 Lde0024bb5d6e.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 18 Dec 2024 10:31:44 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by PA6PR08MB10596.eurprd08.prod.outlook.com (2603:10a6:102:3d2::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Wed, 18 Dec
 2024 10:31:41 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 10:31: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: 4e3c1b16-bd2b-11ef-a0d6-8be0dac302b0
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=ObLEyuxRWhB1lkELL09SyeW1o4Gndfi/r+kGO9B2Un9VtOHmODY80o+1+b2cdCBTZHxOKMkEnBwghMP62oFP+RbWFkdUW612rNwEaA/Wd8uCW0k0+8Nmh8TmrHEQvrwyH2hFYIi58uvZFjbraZT54qnmLWd45j52+iBvX1iv/kGtIYHlhZm0Q+rWJ4i57AYVCpvImpQtY0P9ge4ND0+HdN04JGIiuzbDooYbFBWR4/MIukubzCl2YsUdBlVgLdeT+2HugxNf/LqZGv/6D9Snx5tgS3EspaFtnydwUqazzHWPxKp4cfkEAJfKVARZAHRN+ycfeEq35n4fCouKTodAhA==
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=t9NO3Yll58klsWYsc7Yfogrf8i1iIfdmFWfjsnwcgCg=;
 b=nsMTTPqfmlAWSDC8PvKo+0tFVXq4d8YdR76MJpNzHv0HFgjqUrarzGVjdFhYvMEDcYcaAMwrwWw6AYpoZi0Cfrwg69KKzp1Lrtg1OXDIA688/2U/GsRMsSGI6Q5rvcjaB8tPEb7kPALeZqkgLdb5++Ip0ovJfTM3WZnlmoFG230zi1I8fQe3fvlr5GSYVQikzubod/+Ja1YQ59i7fUCoSo2L7z4luRz+5hdRKU+HDhrxECLLL0Aro10MsJwnivGz818A1tjNNr7WrLbemA0JhQu/fuYBEw2KQRMutB7b8fIb6rE/EWZpBH7rnIQwIHWM6BqA3vm5NYrla61xeJ1QuA==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=t9NO3Yll58klsWYsc7Yfogrf8i1iIfdmFWfjsnwcgCg=;
 b=rJ8V2nSGrAi/+xiGZDdby+Z4pZmebvr6bz8RUsQPobScMG/LDuyOP8IWSHbTMq8knzem/lgecaOxAv5gO8Y+NYL32M14m7kjEvhVgk8bR3Vgsj4otYsXBltPqP7UpH5otDFUCDXyoJToy2JwhmKbiw+g/IxrFLWlYanS+CEY8mc=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 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
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 2692d6dc6b5fb320
X-TessianGatewayMetadata: 9ENoPp9Ixky5j6WeDY69lb0faonl3F2HGauVML5yFvhJqX1dB0V2nRpEduqWBhnaMljCjArQLaPRszUvxEL2LWSrOazvBdaTw2C+WLX98e6jJQadvOOvIM7B7mkuIgEIMVjByCJMQ8cHlTSzhWKcYzwxCv6SZbXrn/rIxlL6d98=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=CaIOTe/w9mzQfE8qenhu+YJcS40zxXiovZV323gTorZ380/GgA1MxST+y0Lrvd/1mTX+Fkx329DU13okUVaUrYEW+K77T/Bcpa1XSEMl95nRv0ciwaO13qom8acerzPpMT3tQ2ZPhcOA7Mpp3/AlJCgIDbVHnYXmisuKPUAB+33ZizP7e7aLhhhwBVaNXHGUw4vfvvxplndILoyz9BX88ZJmWCWgv9vyupMh2F0DbPuZAiy7VIeIQfyysgp2b2ml+XDQKUv24PVhHB2lNHBoeoaUniicCzER1Wx8fug2gbTPqx06rEROfSmgcF9uGcUrOj/7L5u7Lf/8PjpqglkibQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=t9NO3Yll58klsWYsc7Yfogrf8i1iIfdmFWfjsnwcgCg=;
 b=yuPEnQiWaR31yIwfja5zw3nNssjVRTcA9U9AeE/06TeyvMpxAa1+ycvMxKatuoiRaYkQvZ8aKD4Jn0CAsgduh7JSF3ktwZR88h8HtqnR/9jixlyKQYRF/nDPxkq/HnfogyJQvxOuu2VXv9zH4gVF9mVARdE6bJTUMYqZG3D0Kblj3jBIDUxblpzFpBXCI7Nhx4VsSxY3srdKt2LXBKHyizMNVnEG4WwXKbUGZlvKu2o9mblrxzyiHGvY5IDZdbFRZDqtN6ylCldHe7aLP81z+afZIwCl2SN24kBCf/fA0A5tT2yn/el+8PKMnHJuGCHTRs8ZZBFjrXIuc23Pv668TQ==
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=t9NO3Yll58klsWYsc7Yfogrf8i1iIfdmFWfjsnwcgCg=;
 b=rJ8V2nSGrAi/+xiGZDdby+Z4pZmebvr6bz8RUsQPobScMG/LDuyOP8IWSHbTMq8knzem/lgecaOxAv5gO8Y+NYL32M14m7kjEvhVgk8bR3Vgsj4otYsXBltPqP7UpH5otDFUCDXyoJToy2JwhmKbiw+g/IxrFLWlYanS+CEY8mc=
From: Bertrand Marquis 
To: "Andrei Cherechesu (OSS)" 
CC: "xen-devel@lists.xenproject.org" ,
	"S32@nxp.com" , Andrei Cherechesu ,
	Andrew Cooper , Anthony PERARD
	, Michal Orzel , Jan Beulich
	, Julien Grall ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini
	
Subject: Re: [PATCH v3 6/6] MAINTAINERS: Add myself as maintainer for NXP
 S32G3
Thread-Topic: [PATCH v3 6/6] MAINTAINERS: Add myself as maintainer for NXP
 S32G3
Thread-Index: AQHbUTVvnKw37S+On0GrV1HlnzKNyLLrzZaA
Date: Wed, 18 Dec 2024 10:31:41 +0000
Message-ID: 
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
 <20241218101142.1552618-7-andrei.cherechesu@oss.nxp.com>
In-Reply-To: <20241218101142.1552618-7-andrei.cherechesu@oss.nxp.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|PA6PR08MB10596:EE_|AMS0EPF000001B3:EE_|PAWPR08MB11014:EE_
X-MS-Office365-Filtering-Correlation-Id: 5c0e7ace-a3b6-437a-c49e-08dd1f4f2f4e
x-checkrecipientrouted: true
nodisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted:
 BCL:0;ARA:13230040|376014|7416014|1800799024|366016|10070799003|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?iso-8859-1?Q?nvY0RyPlHuDnUMJZXhjosy3qivNxBRwDqTM63h2YvCZ3yeBs2fDKDehXEb?=
 =?iso-8859-1?Q?f9/oesI2W3y4e9qeW4V+AAGTB8bW7dU8cYvOyBEPkflMXVww+WaoopTfUb?=
 =?iso-8859-1?Q?Lg0YrJXZn+/cbbijTffbX0HoWmxlKb0TE3hbrQKWO7IUf9FLX3NrW5iri3?=
 =?iso-8859-1?Q?A9SOFrUBMA8D/A22WjtctEBOO/3mod7nfAcY498ENe+YSREzRGoR5bC74I?=
 =?iso-8859-1?Q?tgEN3ruY0tdG07VzLhSxSHEeB36Q/sN4RMQUNcL4YCw0NJhCpz5IZnRabH?=
 =?iso-8859-1?Q?ML/6ymbFJN3n+clG5A9RHbp5Rl2ZWJKe8roYPaKqHOs1P3psHTJUZkuPlZ?=
 =?iso-8859-1?Q?upvFrwO+x0qmWChd5dC4T7oMSMdedsKJzVNNSy6ZviIaDoXRqSStlxUiL5?=
 =?iso-8859-1?Q?5ohQ5/ZtzhdIOCc9IkwL09JrsLzkow0nTFa3ZBQV8PmtQThcU0aB6mbvH6?=
 =?iso-8859-1?Q?N10zs3ATOBZJ1ODxgNv6xrFvs6VNzKadj8T94cfDMRGj/ZXtV0ir+z+yFm?=
 =?iso-8859-1?Q?sTr+xaXRvDytZ5U1ufEQ6Yx99K9Uw1UNJ84ag2iZ1hfDMWBU1+AJfsgmYa?=
 =?iso-8859-1?Q?qXZvmMVRsz7A2o4BeiRMp2zjPNV9C/gV/hq3jSNXUj88yLYw93drrjjTig?=
 =?iso-8859-1?Q?lUE5Xhq9OHh6xKIHZPYnR+yMrKfQ7lUxUKX8OgAmvli5Q1nhirf8uhPves?=
 =?iso-8859-1?Q?mrL6kZonF61qJvmDDwLwdSb8HaVCORlv7iGZ7OvXOweKmcEsNCAoqasjSy?=
 =?iso-8859-1?Q?QpVUGTOPmfy8TxRq5VEKV4YaHIY3hBAynjq/Jv33djkN32heMxOaUTzt9i?=
 =?iso-8859-1?Q?6Iz5lXNwCx2/TsGcOtn3ThhEuG260GeLpy4BHZun1Rp09nVmw0Kq5TUk9u?=
 =?iso-8859-1?Q?+eoWztSaY0qJg08ncws77v76Omd+VmitdgWIIwK33i2h4QxjW0iG3a7nux?=
 =?iso-8859-1?Q?Vhpsec14PDawC96bRT0qQztRMBi/fvZ5A33xvX9xpAVnGt6IdGCOkfUZJ6?=
 =?iso-8859-1?Q?I7xmM0BP5+iqALXg36sOCIf/OCh4S075EmbLfRblbJAHuEBSMKeqRentYF?=
 =?iso-8859-1?Q?K2rWRyx7ngBJQqIAuNkIdsPYXFhpt+8sEmyqeRRG2FAvNm5kB/N3ingKsz?=
 =?iso-8859-1?Q?GhD5PrPPS6trq5WFegAStbAFAVC+hJbwyN8CzQvsk2UZCOFS6lKj9NByyq?=
 =?iso-8859-1?Q?ZAH+t5QcsMyAVmy9ZAqHSp9LWheTDbFOpfny1T2+I4lVFIaE3Jj4aCKA+d?=
 =?iso-8859-1?Q?/CdGjsrV6SLg7rVDeX3T1AuLXoWxSt4UcCkRsSIixcgZxuKHKld1fSz3nK?=
 =?iso-8859-1?Q?mS5yXzeWwfZzQMm3ZGa63n/fhPbw81T26vTRHjTZ6YcCgYgS1ZabwpAZ5v?=
 =?iso-8859-1?Q?rETBWb9+Nb9raEyPkYH1Ko7bfcJ1R8giBcpSm3KGy+ndFB2p3jLZBtU4O/?=
 =?iso-8859-1?Q?iKEfPm4t5CDLAHgg?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(366016)(10070799003)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <66E23108C7B297438C3E8423BD212314@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA6PR08MB10596
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender:
 ip=[2603:10a6:10:25a::24];domain=DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS0EPF000001B3.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	ae7c98e1-a03d-44ed-a896-08dd1f4f29a0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|35042699022|14060799003|1800799024|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?iso-8859-1?Q?ysQ/ZzfE5Ljpc7OSAs523ehnNsgY8pcOTX8NMptUJLxa4PVL8zSTkWo0mV?=
 =?iso-8859-1?Q?GoXrGRkaZZkqInRM/daeBrFvDQxufur4om/C9xNgMnRePAlzYKtHLRFbbd?=
 =?iso-8859-1?Q?DwEDovZZr06Mch5au3X68aPM+dty2xFyw5PkwZDWN2Kxixv79dQomy6kVm?=
 =?iso-8859-1?Q?jqEZoXzq77T1qDjEs1Qvk5PddsgRv6fprJFDFIXz888YoeGEWDKlOgusau?=
 =?iso-8859-1?Q?FCi4NMDfaCkP9ImXfWoniSXCBNZnmAoBcRnC/UsXvOX1JHVTnAGGlj0kt5?=
 =?iso-8859-1?Q?7ji8obJlS4y918qQLw9Gs7wLKgkw/zZHDxG7G0tdk8mD5spCTXlSylBY2t?=
 =?iso-8859-1?Q?KpfhIOzaqiFlcpzEL5bpR5+YT1y/Wsv/uxfhSowmcl9ogJ4bvRML+kO91R?=
 =?iso-8859-1?Q?ekSEGaxSS0JqHL+5WyYznoaHVnpmC+6oTSdMCsBI40aaOZ5dKu9+4I9TFi?=
 =?iso-8859-1?Q?oQKG+bIvEnJHfal/jR+y3s/uV8LsVbKpf3UdU06C1u/gpcsDYQ64hxzhuP?=
 =?iso-8859-1?Q?fvwBdS581k35aDxNP4cTqCiSyzQQZ2730qmBpUv4g2swE+CcYp2Wq6ZWaB?=
 =?iso-8859-1?Q?oiaAyJUmV1THRjsPL/KvXCNvTXfU866x01QeZ1l8P1sWkN3HhgEPl0q/4Y?=
 =?iso-8859-1?Q?ECGMwZRHFfSxCrZesWsIaeg+ZxvQjbDebXhSLwxtsuOxa5eXU4EUaDGpQ2?=
 =?iso-8859-1?Q?I9h+NE0+iuO10hYKQQTVmORCqYknJIlv118sDYnhgPT4nBQ21oXJkxdwyr?=
 =?iso-8859-1?Q?TV4j+oAEpuJ3DlKenIIzgi7qs5UbqRbK+9Aa8KgR1pBkDMhuRRV91VcwET?=
 =?iso-8859-1?Q?qlZqUmtsiUEH3ITE1b4nUqkyAWRxJzndnFjJwI859rH5BHNT3bQzNl/AsH?=
 =?iso-8859-1?Q?zsOpiz8dsBwpjtk+lXR++fbdvI5Hdcnjc5oOEB12jY4Lr1PKwkfM4e3Cgn?=
 =?iso-8859-1?Q?wXxObbNiel0IOq9fzRN9NlNOGwW5ANZCOu59Fe0nCnK9GisikrB3aAbI9W?=
 =?iso-8859-1?Q?0zAdpcX3tHQcmBH0AP+ERuJ4yV5ftdVOHC3TPnRGH8TWFhcrPQIWY1chRN?=
 =?iso-8859-1?Q?i/zKLVH4msWx9J+jR5WNeQL0zgkvAAg8A5T6y6NBzljuRcdpYfSEWMQcak?=
 =?iso-8859-1?Q?ELXZVy0rZ3g+tlrqduCJ/TTwgl9PeLRbfd1b1SG9Y8u3uJ6Mfo6KijSysO?=
 =?iso-8859-1?Q?ZP13ugA/V+DDKavOIWnVVLtrJMSXnQOhPFRYIwjGKwkOt/7sfCKPUN0DGz?=
 =?iso-8859-1?Q?PpUOWTvBDowrMgpc3z7bAyo+4Cmd+9sR51SMqVNerptdCuufMhIaBVgJ7X?=
 =?iso-8859-1?Q?UM24Vp8Fs+nCKVnXDjKyYTWka8oT6JqwQPM7ohv2npB7GgDuEaJmuu/J8u?=
 =?iso-8859-1?Q?hzID7RrdH+aWHZZqiinrfIbU2C73oWRjLdDYrPlUjVa6m/nEofAFoph85d?=
 =?iso-8859-1?Q?rQHHbASPvVzyyRLbo6v+Fsbi2C9Xfs1jA4wqVxRLhN51oeU4OQOCsZA/bx?=
 =?iso-8859-1?Q?HWAbIZ2RoIY5og2dqdcX7c?=
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(82310400026)(35042699022)(14060799003)(1800799024)(376014)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 10:31:51.2422
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5c0e7ace-a3b6-437a-c49e-08dd1f4f2f4e
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AMS0EPF000001B3.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB11014

Hi Andrei,

> On 18 Dec 2024, at 11:11, Andrei Cherechesu (OSS)  wrote:
>=20
> From: Andrei Cherechesu 
>=20
> Add myself as maintainer for NXP S32G3 SoCs Family,
> and the S32 Linux Team as relevant reviewers list.
>=20
> Signed-off-by: Andrei Cherechesu 

Acked-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> MAINTAINERS | 6 ++++++
> 1 file changed, 6 insertions(+)
>=20
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 34ad49bc39..392f780f76 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -426,6 +426,12 @@ L: minios-devel@lists.xenproject.org
> T: git https://xenbits.xenproject.org/git-http/mini-os.git
> F: config/MiniOS.mk
>=20
> +NXP S32G3 PROCESSORS FAMILY SUPPORT
> +M: Andrei Cherechesu 
> +L: NXP S32 Linux Team 
> +F: xen/arch/arm/include/asm/linflex-uart.h
> +F: xen/drivers/char/linflex-uart.c
> +
> OCAML TOOLS
> M: Christian Lindig 
> M: David Scott 
> --=20
> 2.45.2
>=20
>=20



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 10:38:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 10:38:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860231.1272280 (Exim 4.92)
	(envelope-from )
	id 1tNrRg-0000HT-Hh; Wed, 18 Dec 2024 10:38:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860231.1272280; Wed, 18 Dec 2024 10:38: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 1tNrRg-0000HL-E6; Wed, 18 Dec 2024 10:38:24 +0000
Received: by outflank-mailman (input) for mailman id 860231;
 Wed, 18 Dec 2024 10:38:22 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1tNrRe-0000HF-SQ
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 10:38:22 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1tNrRe-009hfj-0S;
 Wed, 18 Dec 2024 10:38:22 +0000
Received: from [89.27.170.32] (helo=[172.16.75.124])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1tNrRe-00Gke5-0j;
 Wed, 18 Dec 2024 10:38: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" 
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:
	References:Cc:To:From:Subject:MIME-Version:Date:Message-ID;
	bh=qePga/uqb9VCali/LSP1JbldBeI7QcN7v1NRQwrG9r8=; b=qNNSkL/D/mt9mDinYxD4ooQ0lp
	itNdT4hCPkq8BNJ6unB0m+GDkzqurA7TYcgu0s7V3hdivDLFLWy/0G4ueoofpEkio29cBsYGERrPY
	ex6YiZzH6Pcu4sCRRnoTwbzRUAi+4e2jXyCWQtXloNHZA0SZhld+dVsXDrXM4nQ6tQCY=;
Message-ID: <1f6381a0-a98a-4783-a9c0-7ec49303af6b@xen.org>
Date: Wed, 18 Dec 2024 11:38:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
Content-Language: en-GB
From: Julien Grall 
To: Sergiy Kibrik , xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 "Daniel P. Smith" 
References: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
 <4e437c60-4fee-40ed-9d2a-789bac0b36d9@xen.org>
 <5246aa98-d23c-41d5-ba14-c12b0a2ee9af@epam.com>
 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 18/12/2024 10:05, Julien Grall wrote:
> 
> 
> On 18/12/2024 09:52, Sergiy Kibrik wrote:
>> hi Julien,
>>
>> 17.12.24 14:42, Julien Grall:
>>> Hi,
>>>
>>> Can you clarify why this is an RFC?
>>>
>>
>> The code for LATE_HWDOM support on ARM seems to be already in place 
>> and working, yet I'm not sure that such configuration is ready to be 
>> exposed for users (well, probably not ready yet, considering Daniel's 
>> comments regarding XSM later in this thread).
> 
> Thanks. In the future, for RFCs, I would suggest to add a section after 
> your commit message (generally after ---) to describe a bit more what 
> you input you expect from the reviewers.
> 
>>
>>
>>> On 17/12/2024 11:47, Sergiy Kibrik wrote:
>>>> Allow to build ARM configuration with support for initializing 
>>>> hardware domain.
>>>> On ARM it is only possible to start hardware domain in multiboot 
>>>> mode, so
>>>> dom0less support is required. This is reflected by dependency on 
>>>> DOM0LESS_BOOT
>>>> instead of directly depending on ARM config option.
>>>
>>> I am a bit confused with the explanation. We already have an hardware 
>>> domain on Arm. It is dom0. So what are you trying to achieve? Is this 
>>> remove some permissions from the hardware domain?
>>
>> I agree, it should have better description.
>> This is to split dom0 permissions into control-only and hardware-only 
>> domains, much like it can be done in x86.
> 
> I don't believe you need the late_hwdom feature to do that on Arm. In 
> the case of dom0less, you are creating the domains at boot, so at the 
> point you can decide who does what.
> 
> You don't need to transfer the permissions (which seems odd in the 
> context of dom0less) to a new domain after dom0 is created.
> 
>>
>>>
>>> If so, why can't the hardware domain stay as dom0 and you remove the 
>>> feature you don't want (e.g. control domain)?
>>
>> control domain is still needed, but as a separate instance & without 
>> hardware access.
> 
> Sure. But the control domain doesn't need to be dom0, it could be dom1, 
> right?
> 
>>
>>>
>>> Are you sure this patch is sufficient to use the late hwdom feature? 
>>> Looking at the code, to enable the late hwdom, the user needs to 
>>> provide a domid on the command line. But AFAICT, there is no way to 
>>> provide a domain ID in the DOM0LESS case...
>>>
>>
>> I append "hardware_dom=1" to xen,xen-bootargs in host's device tree 
>> and it works.
> 
> AFAIU, the domain needs to be explicitely created. How do you do that? 
> Is it just describing the domain in the DT? If so, how does it work if 
> there are multiple domain described in the DT?

I just had a look at the code. I don't see how this change and simply 
adding "hardware_dom=X" is sufficient.

In addition to what I wrote above, Dom0 will be the first domain created 
and we will assign all the devices and mappings. When the hardware 
domain is created later on, dom0 will still have those mappings and 
devices. That's unless you list all the devices in the device-tree as 
not assigned to dom0 and then assign them manually to the hardware domain.

I would also expect that the hardware domain wants to use the same 
memory layout as the host. But that's not necessary for the control domain.

So surely you need something more in the device-tree?

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 10:41:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 10:41:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860241.1272290 (Exim 4.92)
	(envelope-from )
	id 1tNrUq-0002D3-Vo; Wed, 18 Dec 2024 10:41:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860241.1272290; Wed, 18 Dec 2024 10:41: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 1tNrUq-0002Cw-SB; Wed, 18 Dec 2024 10:41:40 +0000
Received: by outflank-mailman (input) for mailman id 860241;
 Wed, 18 Dec 2024 10:41: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 1tNrUp-0002AG-Ce
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 10:41:39 +0000
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com
 [2a00:1450:4864:20::22f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a85f2961-bd2c-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 11:41:37 +0100 (CET)
Received: by mail-lj1-x22f.google.com with SMTP id
 38308e7fff4ca-303489e8775so41144651fa.3
 for ; Wed, 18 Dec 2024 02:41:37 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-30343ea133esm15583311fa.0.2024.12.18.02.41.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Dec 2024 02:41: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: a85f2961-bd2c-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734518497; x=1735123297; 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=gIy474pgaZwdFN57z4t1lxSVi4NdufFWtGZHQvKna7I=;
        b=eBfX3qso4M+c7bQ7lGailxMtURdzN0U5IcxZ1O//51n9hMc63RlFXkLdjrhxSjVG8t
         VarXoyIQ7t8ho4VuF9JytUgX7bXklJ9HebhIQf7NsicV71macv6Jo60jRJLbU2ongj3P
         ji72hoGVMRRJoFpXbvMRXWPKeqNjs+gI9oysW6IvSqrLBNVU9jyP6jURtH1H7sViE1Ed
         sJOjis8f4KS/IK+qjr2d+xZqy8T9GSMl2B3ht7oCTYXWhWHd6g8S3lCFPVp3yzgpFWjK
         1R0AYgD615FHvtRTgbMU3ymNZxABAdA8F5HaszFv9dCrmjMOi2NSPWQ+NnAqYczH7RUM
         znXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734518497; x=1735123297;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=gIy474pgaZwdFN57z4t1lxSVi4NdufFWtGZHQvKna7I=;
        b=gHu4uD7pl7JllD1WDqMZlqYqBJPI9x5nTPypgIlQzdYpG37J9tdcCiqRNH1DgwC6Zm
         668qy1CRwlaqALK7PjViWpHaV/mmrKDh02eEHoMvbhJXJgYoQba4agCBSEPMptwGdd3N
         P39D9CFqDdBL+3dpmI3Gv3QNeqiLCM4PzSQu4xo2dBRlumX37AIVibDHC0envTsLxib0
         vLd7CMPg+Cy+Q0Bn+CEKSYdasl3O1geQcy8ybBHXlqKu0TMGu7Tb9WDDlUJDNhQZogXP
         fpRCwCI4aW//m8CgXRpX14Uf8D+Y/rnvtursBCRbixy1OTxf0DcgDKu4qG+M1taXS40g
         5b8A==
X-Forwarded-Encrypted: i=1; AJvYcCXJJHSMbHzqkbXFFdfJKZClzUrJ2At03GpkJBuX0VCCfFlKVkEU0FMcI4t1EiiYQiSyE149LpXOOec=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxtmHEb7Mo0zc0kak52gYX4SnvoyauUDt/xDBIL6sUfX9gKOtDM
	IO5xVqxqrqcQnuJYi+RniX1PNWyfT7U9tvi2OsllscF1jRk3AMXSzPmcjuaF
X-Gm-Gg: ASbGncsWEpKwWOHK+PLRC4c7+4wQb+gCPdSKX8NTx40lp4v7ni3sCTnfcY6lv8u8d1v
	I9Xk7q3ZCu1MqEf3rdFBxpFS2bH22Qi+6k4IDh+/hPKPfZhheUrzHdmQ5IHX70FAcz/+44a6Gv3
	q3pmVNUivBWmWZ1tHg7UtOCP4qul/K1Fxzy38nkHNvCzLBTT0L/mYQGtUo7v+uN/21occ1SSUgA
	r5FAaYaJJA9ZjeYFkJF5to7vy7QQRd9Mq8rhjsYAS91OjCvTI/RA+bdWQfMhE123dYamA==
X-Google-Smtp-Source: AGHT+IGQNxnwQ5uviSEP8/LRr2Xzl9a01p6tFroaZFQQTStWEfHHkCbza4zytC/51ZkOhXRyPgIZyw==
X-Received: by 2002:a05:651c:154a:b0:302:3356:7751 with SMTP id 38308e7fff4ca-3044db51faamr7203951fa.40.1734518496661;
        Wed, 18 Dec 2024 02:41:36 -0800 (PST)
Message-ID: <51d71dc5-8adc-4382-8218-ab4ee3061d78@gmail.com>
Date: Wed, 18 Dec 2024 11:41:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 4/6] CHANGELOG.md: Add NXP S32G3 and SCMI-SMC layer
 support mentions
To: "Andrei Cherechesu (OSS)" ,
 xen-devel@lists.xenproject.org
Cc: S32@nxp.com, Andrei Cherechesu ,
 Community Manager 
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
 <20241218101142.1552618-5-andrei.cherechesu@oss.nxp.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <20241218101142.1552618-5-andrei.cherechesu@oss.nxp.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 12/18/24 11:11 AM, Andrei Cherechesu (OSS) wrote:
> From: Andrei Cherechesu 
>
> Signed-off-by: Andrei Cherechesu 

Acked-by: Oleksii Kurochko 

~ Oleksii

> ---
>   CHANGELOG.md | 3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 15f681459f..bda43b1efb 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -16,6 +16,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>   ### Added
>    - On Arm:
>      - Experimental support for Armv8-R.
> +   - Support for NXP S32G3 Processors Family and NXP LINFlexD UART driver.
> +   - Basic handling for SCMI requests over SMC using Shared Memory, by allowing
> +     forwarding the calls to EL3 FW if coming from hwdom.
>    - On x86:
>      - xl suspend/resume subcommands.
>   


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 10:50:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 10:50:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860255.1272300 (Exim 4.92)
	(envelope-from )
	id 1tNrdI-0004Ov-PU; Wed, 18 Dec 2024 10:50:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860255.1272300; Wed, 18 Dec 2024 10:50:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNrdI-0004Oo-LE; Wed, 18 Dec 2024 10:50:24 +0000
Received: by outflank-mailman (input) for mailman id 860255;
 Wed, 18 Dec 2024 10:50: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 1tNrdG-0004Oi-I6
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 10:50:22 +0000
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com
 [2a00:1450:4864:20::22e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e0ea8f00-bd2d-11ef-a0d6-8be0dac302b0;
 Wed, 18 Dec 2024 11:50:21 +0100 (CET)
Received: by mail-lj1-x22e.google.com with SMTP id
 38308e7fff4ca-3022c61557cso68328231fa.0
 for ; Wed, 18 Dec 2024 02:50:21 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-30344045318sm15431471fa.30.2024.12.18.02.50.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Dec 2024 02:50:20 -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: e0ea8f00-bd2d-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734519021; x=1735123821; darn=lists.xenproject.org;
        h=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=N+tlWGjlt39XQldE9UijvlscC2vMAhgHkHiI91WqOOQ=;
        b=fAfsbwQ04iypfILjvxD0JnLwvzIpip1HYmaT2+J264OWTtgdV1gr2KkY3TOhMpm92D
         2UYqGxBcCSQb2KnDRb/8Wzst/rv6epFQ0bXDYOk+JvDb2uTvQTClQa86RDgXuwtDb0Yh
         anKNuaCCsjVk+WQ64Sh1jEX59ip1Onyg3P8kWFhqDq/wIjMP6vaFCojhC0TwS7b0qE7m
         4BFY64A1MpPInBJ/Y+t6m9IjWQakVQrbXbApTj1Ga245PFvTXsrqIeZBUCa99iLE4dCY
         HFxF+Msdwal0v00NodWLZtwQxMJ++RL2WUKNvIe6VSAv9EWpYTZzFFGS5QeHQrm+ZXEB
         /XMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734519021; x=1735123821;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=N+tlWGjlt39XQldE9UijvlscC2vMAhgHkHiI91WqOOQ=;
        b=nHNVRxTyQFS3GPNtU/P+TeBs6wJKt4ytBRY1YB+66E1uL3r3imVtT+Jn2cnYoKyqfM
         sZT3SShkUEZKWEHm/piZx+FEclFhooejuVRiLWmvkrHCvtKxL000HO0/0VglIl0EevXP
         6XcUshU9SxkR4SsjV6x1QZmNFay6E+GBfbmL/6N3RWM6U06DfU+Ta3wDtUtsHGBkYcIN
         WGAOPuMMelXrTyHGssghZYpKYvPxVYOm1LZFOXAjiPZ/8wrvGdRSIXao2VQzBbsXhSAL
         OYx54Yyhmz4wvnsKShFERrsc7/9OdLcLjgLmcOpJ8vB4b2ylYFCf2tXG0o89GgwH+T71
         jMfg==
X-Forwarded-Encrypted: i=1; AJvYcCV199ksuu2zy8OrHBjTwBEydaXZHtENutx0IzcSiU7CX8YM1TtqHGRVuzsH6Co3XNeIeE07FK4lFec=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxEk5NsqmVCTINUeKdbpZtETRH6G1+E9RHStBtBi6eONSuyfbbD
	j6zBar/ND02SDGNQXOtG24uPv6sqVwfYvn27xXicqhz/AcafXmdh
X-Gm-Gg: ASbGncuGP/PVH6CRwsu/9vrBI8bwsT7dymYvHloz9LypO58ekGinJEPo23j9Z8iGyLq
	9UwIDU2M/L6x6XisrWVXrAuICBA3xjJasPza89ixXsdrffUSiVoJSNqHEhPUL3bFM3phclu5qiS
	eGe40c/zG5WoC/roRMj9DE+7B1MwKm/RMQDd41fuAT5RyfZQTjLBl820nmFh6BKfoc6ibj2n06q
	yXSdLxWrC8amhQmCfnTgrmUwJRtJcqlQMvYBT3qOQd7LTudavLb+AWBjxvAmbJ/REQuyQ==
X-Google-Smtp-Source: AGHT+IHGjCnSRB2+5m76PVm1Dk2W8+RwC175kJFppSOZPtOdS0j1dufV1g7yON/nzx0j5Er6bQiAaA==
X-Received: by 2002:a2e:be9c:0:b0:304:4cac:d8ef with SMTP id 38308e7fff4ca-3044da8680dmr7557871fa.7.1734519020693;
        Wed, 18 Dec 2024 02:50:20 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------0q3TURiZYUsZTF1DtabbZLHm"
Message-ID: <941f37dc-2dd5-4a11-acf5-8b4e97f183e6@gmail.com>
Date: Wed, 18 Dec 2024 11:50:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/7] Unflattening and relocation of host device tree
To: Jan Beulich 
Cc: Alistair Francis ,
 Bob Eshleman , 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: Oleksii Kurochko 
In-Reply-To: 

This is a multi-part message in MIME format.
--------------0q3TURiZYUsZTF1DtabbZLHm
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 12/17/24 5:36 PM, Jan Beulich wrote:
> On 17.12.2024 17:32, Oleksii Kurochko wrote:
>> The current patch series introduces the relocation of the host device tree file
>> to free up low memory and also it is expected that discard_initial_modules()
>> will be called sooner or later, it will discard the FDT boot module,
>> and remove_early_mappings() will destroy the early mappings.
>>
>> In addition to relocation, unflattening is introduced to create the tree of
>> struct device_node for the host device tree.
>>
>> To implement this, several things have been introduced:
>>   - destroy_xen_mappings() function, which removes page mappings from Xen's
>>     page tables. This is necessary for clear_fixmap().
>>   - {set,clear}_fixmap() functions to manage mappings in the fixmap region,
>>     which are expected to be used in copy_from_paddr() to copy the FDT to Xen's
>>     heap.
>>   - Introduce new config CONFIG_QEMU which is going to be used to cover changes
>>     connected to QEMU virtual board. It will be used during introduction of stubs
>>     for clean_and_invalidate_dcache_va_range() and clean_dcache_va_range(),
>>     which are expected to be used in copy_from_paddr() and flush_page_to_ram(),
>>     which in turn are expected to be used during the call to xvmalloc_array() in
>>     relocate_fdt().
>>     In case of QEMU cached related functions are implemented as returning 0 as
>>     QEMU doesn't model cache ( and so CMO extensions ). For others cases, it is
>>     introduced as -ENOSUPP as h/w could support CMO extension ( or hardware
>>     specific insertions ) and it will need to update implementation of the
>>     mentioned functions.
>>   - The introduction of copy_from_paddr() to copy the FDT to an address
>>     allocated in Xen's heap.
>>
>> ---
>> Changes in v3:
>>   - Add some Acks for the patches. All the patches are Acked except:
>>       [PATCH v3 1/7] xen/riscv: update layout table in config.h
>>       [PATCH v3 5/7] xen/riscv: implement data and instruction cache operations
>>   - Other changes please look at the specific patch.
>> ---
>> Changes in v2:
>>   - Update the cover letter.
>>   - Introduce new patch with aligning of upper bounds in the layout table in
>>     config.h with the definitions below which are inclusive.
>>   - Other changes please look at the specific patch.
>> ---
>>
>> Oleksii Kurochko (7):
>>    xen/riscv: update layout table in config.h
>>    xen/riscv: add destroy_xen_mappings() to remove mappings in Xen page
>>      tables
>>    xen/riscv: reorder includes in asm/page.h alphabetically
>>    xen/riscv: add {set,clear}_fixmap() functions for managing fixmap
>>      entries
> Please can you avoid re-posting patches that were already committed (the
> latter three)?

Sure, I confused something when fetch upstream/staging so missed that some patches
were merged.

Sorry for inconvenience.

~ Oleksii

--------------0q3TURiZYUsZTF1DtabbZLHm
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  
    
  
  
    
On 12/17/24 5:36 PM, Jan Beulich wrote:

    

    

      
On 17.12.2024 17:32, Oleksii Kurochko wrote:


      

        
The current patch series introduces the relocation of the host device tree file
to free up low memory and also it is expected that discard_initial_modules()
will be called sooner or later, it will discard the FDT boot module,
and remove_early_mappings() will destroy the early mappings.

In addition to relocation, unflattening is introduced to create the tree of
struct device_node for the host device tree.

To implement this, several things have been introduced:
 - destroy_xen_mappings() function, which removes page mappings from Xen's
   page tables. This is necessary for clear_fixmap().
 - {set,clear}_fixmap() functions to manage mappings in the fixmap region,
   which are expected to be used in copy_from_paddr() to copy the FDT to Xen's
   heap.
 - Introduce new config CONFIG_QEMU which is going to be used to cover changes
   connected to QEMU virtual board. It will be used during introduction of stubs
   for clean_and_invalidate_dcache_va_range() and clean_dcache_va_range(),
   which are expected to be used in copy_from_paddr() and flush_page_to_ram(),
   which in turn are expected to be used during the call to xvmalloc_array() in
   relocate_fdt().
   In case of QEMU cached related functions are implemented as returning 0 as
   QEMU doesn't model cache ( and so CMO extensions ). For others cases, it is
   introduced as -ENOSUPP as h/w could support CMO extension ( or hardware
   specific insertions ) and it will need to update implementation of the
   mentioned functions.
 - The introduction of copy_from_paddr() to copy the FDT to an address
   allocated in Xen's heap.

---
Changes in v3:
 - Add some Acks for the patches. All the patches are Acked except:
     [PATCH v3 1/7] xen/riscv: update layout table in config.h
     [PATCH v3 5/7] xen/riscv: implement data and instruction cache operations
 - Other changes please look at the specific patch.
---
Changes in v2:
 - Update the cover letter.
 - Introduce new patch with aligning of upper bounds in the layout table in
   config.h with the definitions below which are inclusive.
 - Other changes please look at the specific patch.
---

Oleksii Kurochko (7):
  xen/riscv: update layout table in config.h
  xen/riscv: add destroy_xen_mappings() to remove mappings in Xen page
    tables
  xen/riscv: reorder includes in asm/page.h alphabetically
  xen/riscv: add {set,clear}_fixmap() functions for managing fixmap
    entries


      

      
Please can you avoid re-posting patches that were already committed (the
latter three)?

    

    
Sure, I confused something when fetch upstream/staging so missed that some patches
were merged.


    
Sorry for inconvenience.

~ Oleksii


  


--------------0q3TURiZYUsZTF1DtabbZLHm--


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 11:04:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 11:04:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860266.1272313 (Exim 4.92)
	(envelope-from )
	id 1tNrqq-00081n-TX; Wed, 18 Dec 2024 11:04:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860266.1272313; Wed, 18 Dec 2024 11:04: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 1tNrqq-00081g-R1; Wed, 18 Dec 2024 11:04:24 +0000
Received: by outflank-mailman (input) for mailman id 860266;
 Wed, 18 Dec 2024 11:04: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 1tNrqp-00081a-QB
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 11:04:23 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20614.outbound.protection.outlook.com
 [2a01:111:f403:2418::614])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d6144c79-bd2f-11ef-a0d6-8be0dac302b0;
 Wed, 18 Dec 2024 12:04:22 +0100 (CET)
Received: from SA9P221CA0002.NAMP221.PROD.OUTLOOK.COM (2603:10b6:806:25::7) by
 DS7PR12MB5960.namprd12.prod.outlook.com (2603:10b6:8:7f::14) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8272.13; Wed, 18 Dec 2024 11:04:17 +0000
Received: from SN1PEPF0002BA4D.namprd03.prod.outlook.com
 (2603:10b6:806:25:cafe::48) by SA9P221CA0002.outlook.office365.com
 (2603:10b6:806:25::7) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.23 via Frontend Transport; Wed,
 18 Dec 2024 11:04:17 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SN1PEPF0002BA4D.mail.protection.outlook.com (10.167.242.70) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Wed, 18 Dec 2024 11:04:16 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 18 Dec
 2024 05:04:16 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 18 Dec 2024 05:04:14 -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: d6144c79-bd2f-11ef-a0d6-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=vgxgkXDHz27Eb2cY8rrFXLoxjTElOKMZFgWLOj4/h5uHXla+RE4+KT5P0rVWpNb+RXkZnEsWArEtAEHsOhxXu65/7tjGQIwTP+uFrKeLuhtuxQVlMRCMNV7/5jvIgcqxQYYCi7MbcMXrRm3NG/npUGfZZKifFGUskIswWnPyYI2WvtRBjWEeV4o7TIXKe1oMWroL/MmPfsMdP4JdgrKUT+lBNgongav/ie3aB3SEkORBRFH+w6jOMmIbCUklIEHRHkkSjJCYAmoo6LjZHXIyYi55gju/L5N9Jmh8fUZk4Rstpthp2n2gnqvFuNi6Lxq00LNRVfDDag7xXqWNNKMX1w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=W6oyg3UAEEoS6KmfSIKZS/ox7qYB9qUdjW8ynVgWaGw=;
 b=bjtTvmyUnxrslL0ovYAC0L0liGA86qLET3++KgpmCZdVnQ8AXp7ZhDP8L10UFOFW/gp2OrtxRuVCUZW+oS3BWi5tLtZQM8f8JVJLluxT5pK9cwvBIwF/VaBnrXhM30zd71B6E0VWEY7nJxUIR/6+cExUlEMxVJhLZAWQxqyxddc6bKfXm71ByTpW3cRaGRw7djjnlP8X4/yQFQKdvfPI17svu5kJ/9vCn0yPyBi5XhnQvqWz+1ua9xnNHbgQhDBsdbGgsmpx+450nDm8ZtQVNaLVkxnK9ywuWQhlhF3mtqpZYtHhGTsRF4d92Mc/q27QWyG2AiaaO18B77ssICDX1Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=apertussolutions.com smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=W6oyg3UAEEoS6KmfSIKZS/ox7qYB9qUdjW8ynVgWaGw=;
 b=18IgHWZmvTYTKhlYlDFBYX+FkFKle5TDyom9AFRytHGsdwjpOe7cyCR5IROX0Asz+jxKCRZcJRBzi+g72xxMSu9klwQg2v+FRLKoQlc071AmSuiJnl5t9RII4pcqTZcfM2y1GJ7tibgx2nFm7mqXPbS35uMYH7ZaRS8V+W2h5do=
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=SATLEXMB03.amd.com; pr=C
Content-Type: multipart/mixed;
	boundary="------------TAN6g0S0GHYr0iX8Poz0G0UU"
Message-ID: <2423b111-0a3e-42f8-a11e-02d81fa75eb5@amd.com>
Date: Wed, 18 Dec 2024 12:04:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
To: "Daniel P. Smith" , Julien Grall
	, Sergiy Kibrik ,
	
CC: Andrew Cooper , Anthony PERARD
	, Jan Beulich ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini
	
References: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
 <4e437c60-4fee-40ed-9d2a-789bac0b36d9@xen.org>
 <63b21760-7dea-423b-a9d8-64d213c40b2c@apertussolutions.com>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <63b21760-7dea-423b-a9d8-64d213c40b2c@apertussolutions.com>
Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1PEPF0002BA4D:EE_|DS7PR12MB5960:EE_
X-MS-Office365-Filtering-Correlation-Id: 606575ed-327e-4e56-648c-08dd1f53b6fb
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?SWZLRzhtMitnczRXK3AxdWt2VTZ1Q0djTmZHMGZud01ISjRLcVBWOVRhMzF5?=
 =?utf-8?B?cW4vWTlMRzhhWHZvR0VyMmQvZll6ZHpQNzVNU3lwQlVWRFFTWWJSdGdabFMw?=
 =?utf-8?B?TE5FM0xpSGxGT1RVQWpJOW8vdEFhYTIvUXpycmNRL2J1b0plSTNsUXVZWjR6?=
 =?utf-8?B?WFR1QWk4ajNWTU1wTjcraTV5L1hud3MzbmxvaGl4eU1kYUlLT3R2S01KdkJK?=
 =?utf-8?B?Mm9obXJwR29UMU5OeWRLRnRTS1RBQ3UxcVhNdDhNU0JJcDQrTXNQYm5HZDhx?=
 =?utf-8?B?R3FvamltTm5qbDh6TjFqemdvMllTcVNwZ1dLTnk0cnVOTW1sRUF6SmZqR2xr?=
 =?utf-8?B?a0ZPWE1CajQ5dHdXOEpKOFU5Z2g5a1NRWmFLT1RqRGJjV2w4YnRDcFozK3Mx?=
 =?utf-8?B?Y3F0cnR2SDA2UWY0WDJINXVIT3FKQm40bUJGaDlibGNJR0l1UmFSMlRxY050?=
 =?utf-8?B?ZkM3UHdXREZJQ0t4V2I0bDUwVm92eGcwcXhzY003V0ZIdlcxNTZoY3BUck5i?=
 =?utf-8?B?MFNvTzZLcWZIcEw3WERvUDhFeVJCcmZNQzdMZWlnQWt4b1lWZXZUdThtYS9C?=
 =?utf-8?B?UFREaUtjR0JwQ0RSeCtEdHlKcVpVRmVycjR5ekVjQVprZkFKQjFETVQxOHd6?=
 =?utf-8?B?WEUzbHVVaU54eXA0YTczTUY4S3k3a2QvclBhMzYrdXNsemp3dURQVzc3ajJK?=
 =?utf-8?B?ZWVQZGdVaDZYelBsUWQ3TFdqRFU1MFlCczFGZkJrRDg4S292MTFCVlc5TEht?=
 =?utf-8?B?bGlkTFZKZ0VvaG83ZGhxUUNWUS91NmNqVzdLNlZCNk9WT1RvNVdISklCQ01l?=
 =?utf-8?B?bXRvLzhWTGNiVS9lT2RiblkyeG9wdWNvREtKWFppblN0WGxvN0Z6cXRhQ1hV?=
 =?utf-8?B?dTl2RDNiRlJZd2haNE5JVnB3NXo4dGo2YUdhTy9qRmpQejd1QWpVdk9vWDlI?=
 =?utf-8?B?Ynk2dmUzaUVuWUQ3UkxNM08vckUxdUFvZWdVbGR0NWNSRHVvMXlaekk3QytO?=
 =?utf-8?B?QS9EUHNwV3pxM20xZEtIZ0ovclhBd0J3ZDlMZDlzZEhQYkwvcWpTRjUyQnUw?=
 =?utf-8?B?Z0lqd2RCVjhrUzVuL2JoQ1ZKYTY5QnMrZWF6dXJ4dVNxNUNPRTcwRGVRNzFx?=
 =?utf-8?B?NVl2YUIzUTZycVM1YkhPYUYzU2lSTG9HeWhCejlveUJhd3Iva3lHT3VFRDkw?=
 =?utf-8?B?YTZrRFN1ZmlHNDU5RDlaajFja0h0QnRXcGN1Tzh2L1FTcHo3dFdpbTVaWTh1?=
 =?utf-8?B?TFBkT08wUXhXdUk0SXdURE1Zd0FqS09WZFRXaVVYWWk4cFM4bUtkdnoweU5w?=
 =?utf-8?B?aVMrV0FwM2ZKQ2hOYWo0Z0xDdFhQOXdhNGhnYk9tOFAyNFBhTmd4dUZlMk01?=
 =?utf-8?B?VlVsSElBVHJsMjhiN0hncG1tODdtcjBuQmRIR0ZjSm1lNTlOUTQ0NElxMGRJ?=
 =?utf-8?B?ekQ5WGRSU2d3L2J3ZHRJWmVPbzNmVHZ2Zk5wSE1KV1U0UzQzNDl4ZWVQRDFB?=
 =?utf-8?B?UEpCV3FYeDNHODBhYytVMU9FRG11Nm1PQUxBQm5qSnB1MDBBRkc3QmVRSUdx?=
 =?utf-8?B?NmdWOUdtOWUrSGZPTFZBVjJrS3dUcXNibS9IWmNPbXhDQkZ3TCtJQ2YyeWYy?=
 =?utf-8?B?SUFjNGs0NTBDS2R5WEt2VVNzUGJYK205amtTem5RMThXSGhWT1BqSjRWaEFw?=
 =?utf-8?B?a1BaRXRaanM1djI2N3ZuMFY2TmptbnkveDVJREt4VnB3QWFpWW5hUHpSUk9W?=
 =?utf-8?B?UFQxUnBab1FDQWtZRldTeE1Ed2J0aDZsWjliL2NXSHl3VDNZLy9pQ3l6MHVz?=
 =?utf-8?B?bW9TTCtZNno0UEdYc0x5V2dTSkdKRENOZmt0Z0prVzE4VGNFMVVqUk13UmlM?=
 =?utf-8?B?UmpBK1cvS1IrUVM5eUs4Q2d2YVJqL2NJVjNGSlVpeGFoWS9kSWRjUGtoU1dO?=
 =?utf-8?B?c0NqVWJYTzdkQWFGZTVXU0ZKeVAxei96WHV5TzNhS1ZmNXlDcWgyQ1JLNE5X?=
 =?utf-8?Q?bI0LW9aLsq8ow9sekQxB1oUineUOFI=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 11:04:16.8372
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 606575ed-327e-4e56-648c-08dd1f53b6fb
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SN1PEPF0002BA4D.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB5960

--------------TAN6g0S0GHYr0iX8Poz0G0UU
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Hi Daniel,

On 18/12/2024 02:17, Daniel P. Smith wrote:
> 
> 
>> On 17/12/2024 11:47, Sergiy Kibrik wrote:
>>> Allow to build ARM configuration with support for initializing
>>> hardware domain.
>>> On ARM it is only possible to start hardware domain in multiboot mode, so
>>> dom0less support is required. This is reflected by dependency on
>>> DOM0LESS_BOOT
>>> instead of directly depending on ARM config option.
> 
> 
> Just to make sure my assumption is correct, you are looking to do a
> multi-domain construction at boot time, with at least two domains. One
> of those two domains is the "control domain" and one is the "hardware
> domain", aka late hwdom except it's not constructed "late".
> 
> If you want such a configuration, I would highly recommend you first
> enable setting flask labels via dom0less (assuming it is not there)
Speaking about dom0less and FLASK. A year ago, I did sent you (privately, through
AMD hyperlaunch collab) my attempt to add minimal steps to enable setting FLASK policy
for dom0less domUs. You then told me that you have a slightly different vision on how it
should be done. Any update with that regard? TBH I though that you're going to add this
support together with other hyperlaunch patches.

For others reference, I attach my patch created back then allowing to specify FLASK labels
for boot-time domUs, which I used to assign different FLASK roles for them.

~Michal

--------------TAN6g0S0GHYr0iX8Poz0G0UU
Content-Type: text/plain; charset="UTF-8";
	name="dom0less-flask-support.patch"
Content-Disposition: attachment; filename="dom0less-flask-support.patch"
Content-Transfer-Encoding: base64

RnJvbSBmYWU3NWU5NDA2NDFkMTI0OGQyY2ZmZGU5ZWQ1NjhmMTIxYTc1NWY1IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogTWljaGFsIE9yemVsIDxtaWNoYWwub3J6ZWxAYW1k
LmNvbT4NCkRhdGU6IFR1ZSwgMTIgTWFyIDIwMjQgMTM6MDM6NDIgKzAxMDANClN1YmplY3Q6
IFtQQVRDSF0geGVuOiBBZGQgc3VwcG9ydCBmb3Igc3BlY2lmeWluZyBYU00gRkxBU0sgbGFi
ZWwgZm9yIGRvbTBsZXNzDQogZG9tVXMNCg0KQXQgdGhlIG1vbWVudCwgaXQgaXMgbm90IHBv
c3NpYmxlIHRvIGNyZWF0ZSBkb20wbGVzcyBkb21VcyB3aXRoIFhTTSBGTEFTSw0KcG9saWN5
IChlbmZvcmNpbmcpLiBUaGlzIGlzIGJlY2F1c2UgdGhleSBhcmUgbm90IGJlaW5nIGFzc2ln
bmVkIGFueQ0KdXNhYmxlIGRlZmF1bHQgbGFiZWwgKG5laXRoZXIgaW4gZmxhc2tfZG9tYWlu
X2FsbG9jX3NlY3VyaXR5KCkgbm9yIGJ5DQpzZXR0aW5nIGluaXRpYWwgc3NpZHJlZiBpbiBk
b21haW4gY3JlYXRpb24gZmxhZ3MpIGFuZCBhcyBzdWNoLCB0aGV5IGFyZQ0Kb2YgdHlwZSB1
bmxhYmVsZWRfdC4NCg0KSW50cm9kdWNlIGEgbmV3IFhTTSBvcCBjYWxsZWQgc2VjbGFiZWxf
dG9fc2lkIHRvZ2V0aGVyIHdpdGggaG9va3MNCnhzbV9zZWNsYWJlbF90b19zaWQoKSBhbmQg
Zmxhc2tfc2VjbGFiZWxfdG9fc2lkKCkuIEluIHRoZSBsYXR0ZXIgY2FzZSwNCnRoaXMgcmVz
dWx0cyBpbiBjYWxsaW5nIHNlY3VyaXR5X2NvbnRleHRfdG9fc2lkKCkgdGhhdCBjb252ZXJ0
cyBhIHNlY3VyaXR5DQpsYWJlbCBpbnRvIFNJRC4NCg0KQWRkIHN1cHBvcnQgZm9yIHNwZWNp
ZnlpbmcgYSBzZWN1cml0eSBsYWJlbCAoanVzdCBsaWtlIGluIHhsLmNmZykgZm9yDQpkb20w
bGVzcyBkb21VcyBieSBhZGRpbmcgYSBuZXcgZGV2aWNlIHRyZWUgc3RyaW5nIHByb3BlcnR5
ICdzZWNsYWJlbCcuDQoNClNpZ25lZC1vZmYtYnk6IE1pY2hhbCBPcnplbCA8bWljaGFsLm9y
emVsQGFtZC5jb20+DQotLS0NCiBkb2NzL21pc2MvYXJtL2RldmljZS10cmVlL2Jvb3Rpbmcu
dHh0IHwgIDYgKysrKysrDQogeGVuL2FyY2gvYXJtL2RvbTBsZXNzLWJ1aWxkLmMgICAgICAg
ICB8IDEyICsrKysrKysrKysrKw0KIHhlbi9pbmNsdWRlL3hzbS9kdW1teS5oICAgICAgICAg
ICAgICAgfCAgNiArKysrKysNCiB4ZW4vaW5jbHVkZS94c20veHNtLmggICAgICAgICAgICAg
ICAgIHwgIDcgKysrKysrKw0KIHhlbi94c20vZHVtbXkuYyAgICAgICAgICAgICAgICAgICAg
ICAgfCAgMSArDQogeGVuL3hzbS9mbGFzay9ob29rcy5jICAgICAgICAgICAgICAgICB8ICA3
ICsrKysrKysNCiA2IGZpbGVzIGNoYW5nZWQsIDM5IGluc2VydGlvbnMoKykNCg0KZGlmZiAt
LWdpdCBhL2RvY3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUvYm9vdGluZy50eHQgYi9kb2NzL21p
c2MvYXJtL2RldmljZS10cmVlL2Jvb3RpbmcudHh0DQppbmRleCBiYmQ5NTVlOWMyZjYuLjRl
YmEwNTI0YWQ0MSAxMDA2NDQNCi0tLSBhL2RvY3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUvYm9v
dGluZy50eHQNCisrKyBiL2RvY3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUvYm9vdGluZy50eHQN
CkBAIC0yNjAsNiArMjYwLDEyIEBAIHdpdGggdGhlIGZvbGxvd2luZyBwcm9wZXJ0aWVzOg0K
ICAgICB2YWx1ZSBzcGVjaWZpZWQgYnkgWGVuIGNvbW1hbmQgbGluZSBwYXJhbWV0ZXIgZ250
dGFiX21heF9tYXB0cmFja19mcmFtZXMNCiAgICAgKG9yIGl0cyBkZWZhdWx0IHZhbHVlIGlm
IHVuc3BlY2lmaWVkLCBpLmUuIDEwMjQpIGlzIHVzZWQuDQogDQorLSBzZWNsYWJlbA0KKw0K
KyAgICBPcHRpb25hbC4gQSBzdHJpbmcgcHJvcGVydHkgc3BlY2lmeWluZyBYU00gRkxBU0sg
c2VjdXJpdHkgbGFiZWwgZm9yDQorICAgIHRoZSBkb21haW4gaW4gZm9ybWF0IHVzZXI6cm9s
ZTp0eXBlIChlLmcuIHN5c3RlbV91OnN5c3RlbV9yOmRvbVVfdCkuDQorICAgIElmIHRoaXMg
cHJvcGVydHkgaXMgbWlzc2luZywgdGhlIGRvbWFpbiB3aWxsIGJlIG9mIHR5cGUgdW5sYWJl
bGVkX3QuDQorDQogVW5kZXIgdGhlICJ4ZW4sZG9tYWluIiBjb21wYXRpYmxlIG5vZGUsIG9u
ZSBvciBtb3JlIHN1Yi1ub2RlcyBhcmUgcHJlc2VudA0KIGZvciB0aGUgRG9tVSBrZXJuZWwg
YW5kIHJhbWRpc2suDQogDQpkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2RvbTBsZXNzLWJ1
aWxkLmMgYi94ZW4vYXJjaC9hcm0vZG9tMGxlc3MtYnVpbGQuYw0KaW5kZXggZmI2M2VjNmZk
MTExLi5iNmM3NjJkNmVlM2QgMTAwNjQ0DQotLS0gYS94ZW4vYXJjaC9hcm0vZG9tMGxlc3Mt
YnVpbGQuYw0KKysrIGIveGVuL2FyY2gvYXJtL2RvbTBsZXNzLWJ1aWxkLmMNCkBAIC0xMCw2
ICsxMCw4IEBADQogI2luY2x1ZGUgPHhlbi9zaXplcy5oPg0KICNpbmNsdWRlIDx4ZW4vdm1h
cC5oPg0KIA0KKyNpbmNsdWRlIDx4c20veHNtLmg+DQorDQogI2luY2x1ZGUgPGFzbS9hcm02
NC9zdmUuaD4NCiAjaW5jbHVkZSA8YXNtL2RvbTBsZXNzLWJ1aWxkLmg+DQogI2luY2x1ZGUg
PGFzbS9kb21haW5fYnVpbGQuaD4NCkBAIC04NjksNiArODcxLDcgQEAgdm9pZCBfX2luaXQg
Y3JlYXRlX2RvbVVzKHZvaWQpDQogICAgICAgICAgICAgLmdyYW50X29wdHMgPSBYRU5fRE9N
Q1RMX0dSQU5UX3ZlcnNpb24ob3B0X2dudHRhYl9tYXhfdmVyc2lvbiksDQogICAgICAgICB9
Ow0KICAgICAgICAgdW5zaWduZWQgaW50IGZsYWdzID0gMFU7DQorICAgICAgICBjb25zdCBj
aGFyICpzZWNsYWJlbDsNCiAgICAgICAgIHVpbnQzMl90IHZhbDsNCiAgICAgICAgIGludCBy
YzsNCiANCkBAIC05ODcsNiArOTkwLDE1IEBAIHZvaWQgX19pbml0IGNyZWF0ZV9kb21Vcyh2
b2lkKQ0KICNlbmRpZg0KICAgICAgICAgfQ0KIA0KKyAgICAgICAgaWYgKCAhZHRfcHJvcGVy
dHlfcmVhZF9zdHJpbmcobm9kZSwgInNlY2xhYmVsIiwgJnNlY2xhYmVsKSApDQorICAgICAg
ICB7DQorICAgICAgICAgICAgcmMgPSB4c21fc2VjbGFiZWxfdG9fc2lkKHNlY2xhYmVsLCBz
dHJsZW4oc2VjbGFiZWwpLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmZF9jZmcuc3NpZHJlZik7DQorICAgICAgICAgICAgaWYgKCByYyApDQorICAgICAgICAg
ICAgICAgIHBhbmljKCJDb3VsZCBub3QgY29udmVydCBzZWNsYWJlbCBcIiVzXCIgdG8gc2lk
ICglZClcbiIsDQorICAgICAgICAgICAgICAgICAgICAgIHNlY2xhYmVsLCByYyk7DQorICAg
ICAgICB9DQorDQogICAgICAgICAvKg0KICAgICAgICAgICogVGhlIHZhcmlhYmxlIG1heF9p
bml0X2RvbWlkIGlzIGluaXRpYWxpemVkIHdpdGggemVybywgc28gaGVyZSBpdCdzDQogICAg
ICAgICAgKiB2ZXJ5IGltcG9ydGFudCB0byB1c2UgdGhlIHByZS1pbmNyZW1lbnQgb3BlcmF0
b3IgdG8gY2FsbA0KZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hzbS9kdW1teS5oIGIveGVu
L2luY2x1ZGUveHNtL2R1bW15LmgNCmluZGV4IDg2NzFhZjFiYTRkMy4uNGI2M2I2YzM2MjQx
IDEwMDY0NA0KLS0tIGEveGVuL2luY2x1ZGUveHNtL2R1bW15LmgNCisrKyBiL3hlbi9pbmNs
dWRlL3hzbS9kdW1teS5oDQpAQCAtODE1LDYgKzgxNSwxMiBAQCBzdGF0aWMgWFNNX0lOTElO
RSBpbnQgY2ZfY2hlY2sgeHNtX2FyZ29fc2VuZCgNCiANCiAjZW5kaWYgLyogQ09ORklHX0FS
R08gKi8NCiANCitzdGF0aWMgWFNNX0lOTElORSBpbnQgY2ZfY2hlY2sgeHNtX3NlY2xhYmVs
X3RvX3NpZCgNCisgICAgY29uc3QgY2hhciAqc2VjbGFiZWwsIHNpemVfdCBsZW4sIHVpbnQz
Ml90ICpzaWQpDQorew0KKyAgICByZXR1cm4gLUVOT1NZUzsNCit9DQorDQogI2luY2x1ZGUg
PHB1YmxpYy92ZXJzaW9uLmg+DQogc3RhdGljIFhTTV9JTkxJTkUgaW50IGNmX2NoZWNrIHhz
bV94ZW5fdmVyc2lvbihYU01fREVGQVVMVF9BUkcgdWludDMyX3Qgb3ApDQogew0KZGlmZiAt
LWdpdCBhL3hlbi9pbmNsdWRlL3hzbS94c20uaCBiL3hlbi9pbmNsdWRlL3hzbS94c20uaA0K
aW5kZXggOGRhZDAzZmQzZDQ1Li41NzVhMTQxZWUyNmEgMTAwNjQ0DQotLS0gYS94ZW4vaW5j
bHVkZS94c20veHNtLmgNCisrKyBiL3hlbi9pbmNsdWRlL3hzbS94c20uaA0KQEAgLTIwMSw2
ICsyMDEsNyBAQCBzdHJ1Y3QgeHNtX29wcyB7DQogICAgIGludCAoKmFyZ29fcmVnaXN0ZXJf
YW55X3NvdXJjZSkoY29uc3Qgc3RydWN0IGRvbWFpbiAqZCk7DQogICAgIGludCAoKmFyZ29f
c2VuZCkoY29uc3Qgc3RydWN0IGRvbWFpbiAqZCwgY29uc3Qgc3RydWN0IGRvbWFpbiAqdCk7
DQogI2VuZGlmDQorICAgIGludCAoKnNlY2xhYmVsX3RvX3NpZCkoY29uc3QgY2hhciAqc2Vj
bGFiZWwsIHNpemVfdCBsZW4sIHVpbnQzMl90ICpzaWQpOw0KIH07DQogDQogI2lmZGVmIENP
TkZJR19YU00NCkBAIC03NzQsNiArNzc1LDEyIEBAIHN0YXRpYyBpbmxpbmUgaW50IHhzbV9h
cmdvX3NlbmQoY29uc3Qgc3RydWN0IGRvbWFpbiAqZCwgY29uc3Qgc3RydWN0IGRvbWFpbiAq
dCkNCiANCiAjZW5kaWYgLyogQ09ORklHX0FSR08gKi8NCiANCitzdGF0aWMgaW5saW5lIGlu
dCB4c21fc2VjbGFiZWxfdG9fc2lkKA0KKyAgICBjb25zdCBjaGFyICpzZWNsYWJlbCwgc2l6
ZV90IGxlbiwgdWludDMyX3QgKnNpZCkNCit7DQorICAgIHJldHVybiBhbHRlcm5hdGl2ZV9j
YWxsKHhzbV9vcHMuc2VjbGFiZWxfdG9fc2lkLCBzZWNsYWJlbCwgbGVuLCBzaWQpOw0KK30N
CisNCiAjZW5kaWYgLyogWFNNX05PX1dSQVBQRVJTICovDQogDQogI2lmZGVmIENPTkZJR19N
VUxUSUJPT1QNCmRpZmYgLS1naXQgYS94ZW4veHNtL2R1bW15LmMgYi94ZW4veHNtL2R1bW15
LmMNCmluZGV4IGU2ZmZhOTQ4ZjdjNS4uYmExYjNkZWY1MmRiIDEwMDY0NA0KLS0tIGEveGVu
L3hzbS9kdW1teS5jDQorKysgYi94ZW4veHNtL2R1bW15LmMNCkBAIC0xNDgsNiArMTQ4LDcg
QEAgc3RhdGljIGNvbnN0IHN0cnVjdCB4c21fb3BzIF9faW5pdGNvbnN0X2NmX2Nsb2JiZXIg
ZHVtbXlfb3BzID0gew0KICAgICAuYXJnb19yZWdpc3Rlcl9hbnlfc291cmNlICAgICAgPSB4
c21fYXJnb19yZWdpc3Rlcl9hbnlfc291cmNlLA0KICAgICAuYXJnb19zZW5kICAgICAgICAg
ICAgICAgICAgICAgPSB4c21fYXJnb19zZW5kLA0KICNlbmRpZg0KKyAgICAuc2VjbGFiZWxf
dG9fc2lkICAgICAgICAgICAgICAgPSB4c21fc2VjbGFiZWxfdG9fc2lkLA0KIH07DQogDQog
dm9pZCBfX2luaXQgeHNtX2ZpeHVwX29wcyhzdHJ1Y3QgeHNtX29wcyAqb3BzKQ0KZGlmZiAt
LWdpdCBhL3hlbi94c20vZmxhc2svaG9va3MuYyBiL3hlbi94c20vZmxhc2svaG9va3MuYw0K
aW5kZXggNzgyMjVmNjhjMTVjLi5iYzE1MjBiNGI1ZGQgMTAwNjQ0DQotLS0gYS94ZW4veHNt
L2ZsYXNrL2hvb2tzLmMNCisrKyBiL3hlbi94c20vZmxhc2svaG9va3MuYw0KQEAgLTE4Mzgs
NiArMTgzOCwxMiBAQCBzdGF0aWMgaW50IGNmX2NoZWNrIGZsYXNrX2FyZ29fc2VuZCgNCiAN
CiAjZW5kaWYNCiANCitzdGF0aWMgaW50IGNmX2NoZWNrIGZsYXNrX3NlY2xhYmVsX3RvX3Np
ZCgNCisgICAgY29uc3QgY2hhciAqc2VjbGFiZWwsIHNpemVfdCBsZW4sIHVpbnQzMl90ICpz
aWQpDQorew0KKyAgICByZXR1cm4gc2VjdXJpdHlfY29udGV4dF90b19zaWQoKGNoYXIgKilz
ZWNsYWJlbCwgbGVuLCBzaWQpOw0KK30NCisNCiBzdGF0aWMgY29uc3Qgc3RydWN0IHhzbV9v
cHMgX19pbml0Y29uc3RfY2ZfY2xvYmJlciBmbGFza19vcHMgPSB7DQogICAgIC5zZXRfc3lz
dGVtX2FjdGl2ZSA9IGZsYXNrX3NldF9zeXN0ZW1fYWN0aXZlLA0KICAgICAuc2VjdXJpdHlf
ZG9tYWluaW5mbyA9IGZsYXNrX3NlY3VyaXR5X2RvbWFpbmluZm8sDQpAQCAtMTk3NCw2ICsx
OTgwLDcgQEAgc3RhdGljIGNvbnN0IHN0cnVjdCB4c21fb3BzIF9faW5pdGNvbnN0X2NmX2Ns
b2JiZXIgZmxhc2tfb3BzID0gew0KICAgICAuYXJnb19yZWdpc3Rlcl9hbnlfc291cmNlID0g
Zmxhc2tfYXJnb19yZWdpc3Rlcl9hbnlfc291cmNlLA0KICAgICAuYXJnb19zZW5kID0gZmxh
c2tfYXJnb19zZW5kLA0KICNlbmRpZg0KKyAgICAuc2VjbGFiZWxfdG9fc2lkID0gZmxhc2tf
c2VjbGFiZWxfdG9fc2lkLA0KIH07DQogDQogY29uc3Qgc3RydWN0IHhzbV9vcHMgKl9faW5p
dCBmbGFza19pbml0KA0KLS0gDQoyLjI1LjENCg0K

--------------TAN6g0S0GHYr0iX8Poz0G0UU--


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 11:11:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 11:11:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860278.1272323 (Exim 4.92)
	(envelope-from )
	id 1tNry3-0001RB-O4; Wed, 18 Dec 2024 11:11:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860278.1272323; Wed, 18 Dec 2024 11:11: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 1tNry3-0001R4-LZ; Wed, 18 Dec 2024 11:11:51 +0000
Received: by outflank-mailman (input) for mailman id 860278;
 Wed, 18 Dec 2024 11:11: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 1tNry1-0001Pg-TJ
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 11:11:50 +0000
Received: from mail179-16.suw41.mandrillapp.com
 (mail179-16.suw41.mandrillapp.com [198.2.179.16])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id de7bb590-bd30-11ef-a0d6-8be0dac302b0;
 Wed, 18 Dec 2024 12:11:46 +0100 (CET)
Received: from pmta12.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail179-16.suw41.mandrillapp.com (Mailchimp) with ESMTP id
 4YCrbj1cchzB5qq16
 for ; Wed, 18 Dec 2024 11:11:45 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 f8a5024ce2f84d3684c581581389ef74; Wed, 18 Dec 2024 11:11:45 +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: de7bb590-bd30-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1734520305; x=1734780805;
	bh=/8fqitR2/EHOxodVcrJrpGxwijByXtGNn4eBet1vubU=;
	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=zGzCu7jd0jfactDQvjou7tKYs6MsQwvWvkRtiJJT8RMs+I40UVjPJ5p2nZVbEfT3P
	 12+B//UbIA8bc5WXCgCZrDxJLQBkuAW53OgaPXTsUFcNT1TG6W3sBIYVN0/wPz3+dK
	 Ea9zKjDbE5jVfmwt8HJgAJlLgPcYXQbhhL53m5sx0wQQij6DfjQOnBS3H1ZxHFrxSG
	 0SoDwzI1sQJ4c4sZiFf7LTPQvvQA+GhQNddRGAUBfEAbbyXiHEfJfOCZ8FTPUVWP9g
	 Epk01JhaSQ6Wagmz4ijunfIpjj+snAglQbeTCGTg9lxQVYxovEUEnfBbz7VaouQffU
	 XcPmheIeLovLA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1734520305; x=1734780805; i=thierry.escande@vates.tech;
	bh=/8fqitR2/EHOxodVcrJrpGxwijByXtGNn4eBet1vubU=;
	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=KAbiHN8vXnITtQslRLkX20Yb4/c17Wy/85a8Lydy3btihXpIVTtg0rfeXbhYBfMOF
	 xqg7+1nCDIoiwVndgvKXbIoajmdEze6r0wcRoZ4hC5unK4iv0bb1u+0UPzoeNfGB38
	 7j5Cl5PVCcyYmEQEVb6PIlag+ipOEi77I5h36e/8UIyEfiapgIe97mkdBarWxYU4en
	 LJpa2Oimk1ozYZEqMSX34rDKixDYqEIx2ZKoEr8UQ4hR/otyvlmn4dRV5Zigc6UsUH
	 OttG8HHIpFb/AL5U78dguR907KW61njd22EZx2UuE5AJEPBGifhufQVV2sEnX26ptZ
	 weXksq2m0WMeQ==
From: "Thierry Escande" 
Subject: =?utf-8?Q?Re:=20[PATCH]=20x86/xen/mmu:=20Increase=20MAX=5FCONTIG=5FORDER?=
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1734520304135
Message-Id: 
To: "Juergen Gross" , "Jan Beulich" 
Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
References: <20241204171346.458105-1-thierry.escande@vates.tech>    <8fb77778-b821-4e38-a835-54883ba14e4b@suse.com>
In-Reply-To: <8fb77778-b821-4e38-a835-54883ba14e4b@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.f8a5024ce2f84d3684c581581389ef74?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20241218:md
Date: Wed, 18 Dec 2024 11:11:45 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 12/12/2024 12:09, Juergen Gross wrote:
> On 12.12.24 11:22, Jan Beulich wrote:
>> On 11.12.2024 19:20, Thierry Escande wrote:
>>> Hi Jan,
>>>
>>> On 09/12/2024 11:04, Jan Beulich wrote:
>>>> On 04.12.2024 18:14, Thierry Escande wrote:
>>>>> With change 9f40ec84a797 (xen/swiotlb: add alignment check for dma
>>>>> buffers), the driver mpt3sas fails to load because it cannot allocate
>>>>> its DMA pool for an allocation size of ~2,3 MBytes. This is because
>>>>> the
>>>>> alignement check added by 9f40ec84a797 fails and
>>>>> xen_swiotlb_alloc_coherent() ends up calling
>>>>> xen_create_contiguous_region() with a size order of 10 which is too
>>>>> high
>>>>> for the current max value.
>>>>>
>>>>> This patch increases the MAX_CONTIG_ORDER from 9 to 10 (4MB) to allow
>>>>> such allocations.
>>>>>
>>>>> Signed-off-by: Thierry Escande 
>>>>> ---
>>>>> =C2=A0 arch/x86/xen/mmu_pv.c | 2 +-
>>>>> =C2=A0 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
>>>>> index 55a4996d0c04..7f110740e1a2 100644
>>>>> --- a/arch/x86/xen/mmu_pv.c
>>>>> +++ b/arch/x86/xen/mmu_pv.c
>>>>> @@ -2200,7 +2200,7 @@ void __init xen_init_mmu_ops(void)
>>>>> =C2=A0 }
>>>>> =C2=A0 =C2=A0 /* Protected by xen_reservation_lock. */
>>>>> -#define MAX_CONTIG_ORDER 9 /* 2MB */
>>>>> +#define MAX_CONTIG_ORDER 10 /* 4MB */
>>>>> =C2=A0 static unsigned long discontig_frames[1<>>>
>>>> While lacking respective commentary, bumping this value imo also
>>>> needs to
>>>> take into account Xen itself, at least commit-message-wise. The
>>>> bumping is
>>>> fine for Dom0 in any event. It is also fine for DomU-s with the
>>>> defaults
>>>> built into the hypervisor (orders 12 and 10 respectively for x86 and
>>>> Arm),
>>>> yet especially for Arm (and in the future PPC and RISC-V) any further
>>>> bumping would be less straightforward.
>>>
>>> Thanks for pointing this out. On the Xen side, CONFIG_CTLDOM_MAX_ORDER
>>> and CONFIG_HWDOM_MAX_ORDER seem big enough on all architectures. But I
>>> see CONFIG_DOMU_MAX_ORDER set to 9 (also all archs). Won't that be a
>>> problem for drivers trying to allocate more than that from a domU ?
>>
>> A driver assumes a (physical) device to be in the DomU, at which point i=
t
>> is CONFIG_PTDOM_MAX_ORDER which applies (PT standing for pass-through).
>>
>>>> However - does the driver really need this big a contiguous chunk? It
>>>> would seem far more desirable to me to break that up some, if possible=
.
>>>
>>> Since this works on bare metal I'm afraid the driver maintainer (mpt
>>> fusion driver) will just tell me to fix Xen.
>>
>> Well. The bigger such allocations, the larger the risk that on systems
>> that have been up for a while such allocations can't be fulfilled anymor=
e
>> even in the bare metal case.
> 
> Yes. I don't think we should just work around this issue without having
> even tried to get the driver fixed. In case they refuse to change it, we
> can still increase MAX_CONTIG_ORDER.

Thanks for the feedback. I'll try to have a look at the driver if I have
time to do so.

Regards,
Thierry



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 11:16:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 11:16:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860287.1272334 (Exim 4.92)
	(envelope-from )
	id 1tNs2K-0002e3-5n; Wed, 18 Dec 2024 11:16:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860287.1272334; Wed, 18 Dec 2024 11:16:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNs2K-0002dw-35; Wed, 18 Dec 2024 11:16:16 +0000
Received: by outflank-mailman (input) for mailman id 860287;
 Wed, 18 Dec 2024 11:16: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 1tNs2I-0002dq-T0
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 11:16:14 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7cec8837-bd31-11ef-a0d6-8be0dac302b0;
 Wed, 18 Dec 2024 12:16:12 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 759C3A425DE;
 Wed, 18 Dec 2024 11:14:20 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E306C4CECE;
 Wed, 18 Dec 2024 11:16: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: 7cec8837-bd31-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1734520570;
	bh=8LQdKHgIMt8+nTxW3buqBoq7RuwtnSvkJpu58iCjHh4=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:From;
	b=gSto4y30XFvFOiV6PC1rJG5gjDRdLoPIuQjKvMQ5EvBG+478Fo3HIdAc4NfRWq56Y
	 lr4t3KlpTF6r18Xabr0ATnfJQKQ7M9N3knKss0qOsBaLQkfHvOzSYe2+91lcDaX5ry
	 PTjKvAHqfl8eIvYrtIVCUgsSNA59gWNXjU6ctMSHh0A+1pT9ECuiV19TASNofU55rU
	 9wtYsikvbxKPHIaGOCLZZ3tjQm9g8p7Pnu3DzThNtdCOlRDR+e7y/JqtainSZfABTc
	 kr/jd5nQ9xewPPJ8ZPO5lKPuhQzZj+FCdJkxDg4rKpANUo2P1LKpw2VwHurXNgTpwS
	 5I1LpMIgOPdQQ==
Date: Wed, 18 Dec 2024 12:16:02 +0100 (CET)
From: Stefano Stabellini 
X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop
To: Jan Beulich 
cc: alessandro.zucchelli@bugseng.com, 
    Stefano Stabellini , consulting@bugseng.com, 
    Julien Grall , Bertrand Marquis , 
    Michal Orzel , 
    Volodymyr Babchuk , 
    Andrew Cooper , 
    =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
    xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen: address violation of MISRA C Rule 11.1
In-Reply-To: <3beb2c10-0cde-48e4-841c-5addd324626d@suse.com>
Message-ID: 
References: <7debd63f3900bad62bcbcc03081e4c04e6099135.1733914487.git.alessandro.zucchelli@bugseng.com>   <26600bb0-93af-45b5-a341-5771bad844a1@suse.com>
   <1ddb5bd7e8889da0e978bb1391072925@bugseng.com> <3beb2c10-0cde-48e4-841c-5addd324626d@suse.com>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Mon, 16 Dec 2024, Jan Beulich wrote:
> On 13.12.2024 15:02, Alessandro Zucchelli wrote:
> > On 2024-12-13 11:08, Jan Beulich wrote:
> >> On 13.12.2024 01:53, Stefano Stabellini wrote:
> >>> On Thu, 12 Dec 2024, Jan Beulich wrote:
> >>>> On 12.12.2024 03:27, Stefano Stabellini wrote:
> >>>>> On Wed, 11 Dec 2024, Jan Beulich wrote:
> >>>>>> On 11.12.2024 12:02, Alessandro Zucchelli wrote:
> >>>>>>> Rule 11.1 states as following: "Conversions shall not be performed
> >>>>>>> between a pointer to a function and any other type".
> >>>>>>>
> >>>>>>> Functions "__machine_restart" and "__machine_halt" in 
> >>>>>>> "x86/shutdown.c"
> >>>>>>> and "halt_this_cpu" in "arm/shutdown.c" are defined as noreturn
> >>>>>>> functions and subsequently passed as parameters to function calls.
> >>>>>>> This violates the rule in Clang, where the "noreturn" attribute is
> >>>>>>> considered part of the function"s type.
> >>>>>>
> >>>>>> I'm unaware of build issues with Clang, hence can you clarify how 
> >>>>>> Clang's
> >>>>>> view comes into play here? In principle various attributes ought to 
> >>>>>> be
> >>>>>> part of a function's type; iirc that's also the case for gcc. Yet 
> >>>>>> how
> >>>>>> that matters to Eclair is still entirely unclear to me.
> >>>>>>
> >>>>>>> By removing the "noreturn"
> >>>>>>> attribbute and replacing it with uses of the ASSERT_UNREACHABLE 
> >>>>>>> macro,
> >>>>>>> these violations are addressed.
> >>>>>>
> >>>>>> Papered over, I'd say. What about release builds, for example?
> >>>>>>
> >>>>>> Deleting the attribute also has a clear downside 
> >>>>>> documentation-wise. If
> >>>>>> we really mean to remove them from what the compiler gets to see, I 
> >>>>>> think
> >>>>>> we ought to still retain them in commented-out shape.
> >>>>>
> >>>>> Another option would be to #define noreturn to nothing for ECLAIR 
> >>>>> builds ?
> >>>>
> >>>> That again would feel like papering over things. Plus I don't know if 
> >>>> that's
> >>>> an option at all.
> >>>
> >>> What is "papering over" and what is a "nice solution" is often up to 
> >>> the
> >>> personal opinions.
> >>>
> >>> From my point of view, Alessandro's patch doesn't make the code worse.
> >>> The ASSERT_UNREACHABLE solution is OK. I do agree with you that it
> >>> should not be required for us to remove "noreturn", but I don't think 
> >>> we
> >>> have used it consistently anyway across the Xen codebase.
> >>> ASSERT_UNREACHABLE is also a form of documentation that the function
> >>> does not return.
> >>>
> >>> In conclusion, I think all three options are acceptable:
> >>> 1) this patch as is
> >>> 2) this patch plus /* noreturn */ as a comment
> >>> 3) #define noreturn to nothing just for ECLAIR builds
> >>>
> >>> I don't mind either way, maybe option 2) is the best compromise.
> >>
> >> The variant with least impact on what we currently have (generated code
> >> wise) is 3), though, which hence would be my preference (well, not 
> >> exactly
> >> a preference, but the least bad one).
> > 
> > Another option could be to encapsulate these function pointer casts as 
> > follows:
> > #define REMOVE_NORETURN(x) (void(*)(void*))(x)
> > This approach allows us to retain the noreturn attribute and the 
> > associated optimizations;
> > note that the encapsulating macro will need to be deviated then.
> 
> And then have one such macro for every attribute that may need zapping?
> What if there are multiple? Any macro may do, yet which one to use would
> be unclear. What if only some attributes need zapping, and some need
> retaining?

It is always a judgment call between addressing issues ad hoc and
developing generic solutions. In this case, since we are discussing only
one attribute, I do not think we should attempt to generalize it
further. 


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 11:24:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 11:24:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860297.1272344 (Exim 4.92)
	(envelope-from )
	id 1tNs9x-0004bX-Tj; Wed, 18 Dec 2024 11:24:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860297.1272344; Wed, 18 Dec 2024 11:24:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNs9x-0004bQ-Qb; Wed, 18 Dec 2024 11:24:09 +0000
Received: by outflank-mailman (input) for mailman id 860297;
 Wed, 18 Dec 2024 11:24: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 1tNs9w-0004bK-Ms
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 11:24:08 +0000
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com
 [2a00:1450:4864:20::630])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 989a86f4-bd32-11ef-a0d6-8be0dac302b0;
 Wed, 18 Dec 2024 12:24:07 +0100 (CET)
Received: by mail-ej1-x630.google.com with SMTP id
 a640c23a62f3a-a9a977d6cc7so854470766b.3
 for ; Wed, 18 Dec 2024 03:24:07 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d652ad15bfsm5388377a12.19.2024.12.18.03.24.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Dec 2024 03:24: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: 989a86f4-bd32-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734521047; x=1735125847; 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=rKADOUVSg3P6JzB3kuGfwq6CPirviwx4/LDew2MuPis=;
        b=Zi//wboW9GvrSr2CvGjRQPukMTMsv+vHytM90ZquRURsdj/ZopJFy3lylDMguOVJxg
         r2c+hVlV/90/0pqJwrupQMzRJo+sGfGQkV1xWncUxXTI+I/wDsQlUN4DtT4lPrEXHE2P
         vtkxiDHgn6xQgdNGk+WjUfd2doninx5tKnfOFgegMmw5Zf0SRD4MI0EOfejrqsJnjWSF
         T/JVo8j7ConZlUefkjMuCjWzQie4oueLJZo0Cufd6IcyeVkpU9bthzNMopSMcAqoPPC0
         ohTtNXMoQA7IfaEgLegWK6xkWwNjpgfiNBA2Jxkvx9W5/VXZ9eYB4cfKkUNK752wBENp
         loeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734521047; x=1735125847;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=rKADOUVSg3P6JzB3kuGfwq6CPirviwx4/LDew2MuPis=;
        b=KqPpULY2EKiNN0M7Q42FEFeIuRow0vk5cRfhMsbvGoQcMFRp4Hn/kbIZ7MJhxzmvcA
         yatxlg8/GSMAhJ4Kh24I6ovtc5hAwvsW1GLMOaj/f5dupYTmhHVcLHh4HOfv+830kBf1
         CM6nG2VuhtUTrmFuQj1F1C4SLBf0kXyVua0xPsoe9JslEBwrdw1kApqAVYHJkiecydtZ
         UOw4VvJ3QV2iIxKFMmFGWmtZnyQPciJNfY9sBrjwXRlTkm1WUsaMGHdgXVW+KYZiVzTr
         FOYzAzu4stAHO+J8vq9c+acycY033d128hMf9RHs9j4aOXPSbgNKDqJWBh7EliLEqOws
         kkKg==
X-Forwarded-Encrypted: i=1; AJvYcCU7evUNaEpghpzsM+weQcxTOjbTGVGG3dhyMUx7H3Rv31ziS6D8ix/d39MmgIkVUEewvseTesDv7PA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxjKiRfJXuPg2trc25IJ4n6InWRKaCoNxr4vnSy9VUe3Zyn9juB
	FDq4O4gk+JR4ECSSI/lBG3Mx7Ahh8ZgiisiwBW9rcz6J8dvzsn/lkniVjqB7y/c=
X-Gm-Gg: ASbGncuvcIq3OtYZG0fgVNfEzqzLCJW2/9IPUYGB1NK4oAD5Vt1oB2yT35oKlLKXxE5
	UiRriYW1+2TF8Ly1wUqOt4XQSRXKPnhCYTYcw06qgvX2/37JrKePVqarGoVYqkrNv52XiE1Xrq1
	MzDaO89x2X0Tsw9sVQtwuOE5eV2cFDyHmLfjBMELX+tPWjFHgf2eLjvd3AgQ4Ohdyi/lT5pKWPt
	tz+exmO5i0jfIpxwP4fGZAxg7IJlPU7snYOEcviYwIirD13kFWBcaaSAAeZK1pBE8u8xOS8xdEk
	69vvOJk4McSHDzn5VeR2E7zB9nle5xLPxm8ry30uZ5iATzEoNd32X+O/MjBpmces8tnSN/AZls4
	i5gOYbA==
X-Google-Smtp-Source: AGHT+IF5SQzsNXVV8lc2al1cGoEXz3poXNEhJy1XoWl32vyAo0iX4zGhBygZsl2dso92tKzUcImL7w==
X-Received: by 2002:a05:6402:3550:b0:5d0:c7a7:ac13 with SMTP id 4fb4d7f45d1cf-5d7ee3fde20mr5630156a12.34.1734521047034;
        Wed, 18 Dec 2024 03:24:07 -0800 (PST)
Message-ID: <733e95a6-dd33-422a-a25b-9f08cef5860e@suse.com>
Date: Wed, 18 Dec 2024 12:24:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/xen/mmu: Increase MAX_CONTIG_ORDER
To: Thierry Escande ,
 Jan Beulich 
Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
References: <20241204171346.458105-1-thierry.escande@vates.tech>
 
 
 
 <8fb77778-b821-4e38-a835-54883ba14e4b@suse.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: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------IU1rzrY1hP2GvmiIBYMdsg6k"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------IU1rzrY1hP2GvmiIBYMdsg6k
Content-Type: multipart/mixed; boundary="------------KONvUQBmacrsoI30Y0kRMJZz";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Thierry Escande ,
 Jan Beulich 
Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Message-ID: <733e95a6-dd33-422a-a25b-9f08cef5860e@suse.com>
Subject: Re: [PATCH] x86/xen/mmu: Increase MAX_CONTIG_ORDER
References: <20241204171346.458105-1-thierry.escande@vates.tech>
 
 
 
 <8fb77778-b821-4e38-a835-54883ba14e4b@suse.com>
 
In-Reply-To: 
Autocrypt-Gossip: addr=jbeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------KONvUQBmacrsoI30Y0kRMJZz
Content-Type: multipart/mixed; boundary="------------N004l0OXHZtI0hPekMD1aKf8"

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

T24gMTguMTIuMjQgMTI6MTEsIFRoaWVycnkgRXNjYW5kZSB3cm90ZToNCj4gDQo+IA0KPiBP
biAxMi8xMi8yMDI0IDEyOjA5LCBKdWVyZ2VuIEdyb3NzIHdyb3RlOg0KPj4gT24gMTIuMTIu
MjQgMTE6MjIsIEphbiBCZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDExLjEyLjIwMjQgMTk6MjAs
IFRoaWVycnkgRXNjYW5kZSB3cm90ZToNCj4+Pj4gSGkgSmFuLA0KPj4+Pg0KPj4+PiBPbiAw
OS8xMi8yMDI0IDExOjA0LCBKYW4gQmV1bGljaCB3cm90ZToNCj4+Pj4+IE9uIDA0LjEyLjIw
MjQgMTg6MTQsIFRoaWVycnkgRXNjYW5kZSB3cm90ZToNCj4+Pj4+PiBXaXRoIGNoYW5nZSA5
ZjQwZWM4NGE3OTcgKHhlbi9zd2lvdGxiOiBhZGQgYWxpZ25tZW50IGNoZWNrIGZvciBkbWEN
Cj4+Pj4+PiBidWZmZXJzKSwgdGhlIGRyaXZlciBtcHQzc2FzIGZhaWxzIHRvIGxvYWQgYmVj
YXVzZSBpdCBjYW5ub3QgYWxsb2NhdGUNCj4+Pj4+PiBpdHMgRE1BIHBvb2wgZm9yIGFuIGFs
bG9jYXRpb24gc2l6ZSBvZiB+MiwzIE1CeXRlcy4gVGhpcyBpcyBiZWNhdXNlDQo+Pj4+Pj4g
dGhlDQo+Pj4+Pj4gYWxpZ25lbWVudCBjaGVjayBhZGRlZCBieSA5ZjQwZWM4NGE3OTcgZmFp
bHMgYW5kDQo+Pj4+Pj4geGVuX3N3aW90bGJfYWxsb2NfY29oZXJlbnQoKSBlbmRzIHVwIGNh
bGxpbmcNCj4+Pj4+PiB4ZW5fY3JlYXRlX2NvbnRpZ3VvdXNfcmVnaW9uKCkgd2l0aCBhIHNp
emUgb3JkZXIgb2YgMTAgd2hpY2ggaXMgdG9vDQo+Pj4+Pj4gaGlnaA0KPj4+Pj4+IGZvciB0
aGUgY3VycmVudCBtYXggdmFsdWUuDQo+Pj4+Pj4NCj4+Pj4+PiBUaGlzIHBhdGNoIGluY3Jl
YXNlcyB0aGUgTUFYX0NPTlRJR19PUkRFUiBmcm9tIDkgdG8gMTAgKDRNQikgdG8gYWxsb3cN
Cj4+Pj4+PiBzdWNoIGFsbG9jYXRpb25zLg0KPj4+Pj4+DQo+Pj4+Pj4gU2lnbmVkLW9mZi1i
eTogVGhpZXJyeSBFc2NhbmRlIDx0aGllcnJ5LmVzY2FuZGVAdmF0ZXMudGVjaD4NCj4+Pj4+
PiAtLS0NCj4+Pj4+PiAgwqAgYXJjaC94ODYveGVuL21tdV9wdi5jIHwgMiArLQ0KPj4+Pj4+
ICDCoCAxIGZpbGUgY2hhbmdlZCwgMSBpbnNlcnRpb24oKyksIDEgZGVsZXRpb24oLSkNCj4+
Pj4+Pg0KPj4+Pj4+IGRpZmYgLS1naXQgYS9hcmNoL3g4Ni94ZW4vbW11X3B2LmMgYi9hcmNo
L3g4Ni94ZW4vbW11X3B2LmMNCj4+Pj4+PiBpbmRleCA1NWE0OTk2ZDBjMDQuLjdmMTEwNzQw
ZTFhMiAxMDA2NDQNCj4+Pj4+PiAtLS0gYS9hcmNoL3g4Ni94ZW4vbW11X3B2LmMNCj4+Pj4+
PiArKysgYi9hcmNoL3g4Ni94ZW4vbW11X3B2LmMNCj4+Pj4+PiBAQCAtMjIwMCw3ICsyMjAw
LDcgQEAgdm9pZCBfX2luaXQgeGVuX2luaXRfbW11X29wcyh2b2lkKQ0KPj4+Pj4+ICDCoCB9
DQo+Pj4+Pj4gIMKgIMKgIC8qIFByb3RlY3RlZCBieSB4ZW5fcmVzZXJ2YXRpb25fbG9jay4g
Ki8NCj4+Pj4+PiAtI2RlZmluZSBNQVhfQ09OVElHX09SREVSIDkgLyogMk1CICovDQo+Pj4+
Pj4gKyNkZWZpbmUgTUFYX0NPTlRJR19PUkRFUiAxMCAvKiA0TUIgKi8NCj4+Pj4+PiAgwqAg
c3RhdGljIHVuc2lnbmVkIGxvbmcgZGlzY29udGlnX2ZyYW1lc1sxPDxNQVhfQ09OVElHX09S
REVSXTsNCj4+Pj4+DQo+Pj4+PiBXaGlsZSBsYWNraW5nIHJlc3BlY3RpdmUgY29tbWVudGFy
eSwgYnVtcGluZyB0aGlzIHZhbHVlIGltbyBhbHNvDQo+Pj4+PiBuZWVkcyB0bw0KPj4+Pj4g
dGFrZSBpbnRvIGFjY291bnQgWGVuIGl0c2VsZiwgYXQgbGVhc3QgY29tbWl0LW1lc3NhZ2Ut
d2lzZS4gVGhlDQo+Pj4+PiBidW1waW5nIGlzDQo+Pj4+PiBmaW5lIGZvciBEb20wIGluIGFu
eSBldmVudC4gSXQgaXMgYWxzbyBmaW5lIGZvciBEb21VLXMgd2l0aCB0aGUNCj4+Pj4+IGRl
ZmF1bHRzDQo+Pj4+PiBidWlsdCBpbnRvIHRoZSBoeXBlcnZpc29yIChvcmRlcnMgMTIgYW5k
IDEwIHJlc3BlY3RpdmVseSBmb3IgeDg2IGFuZA0KPj4+Pj4gQXJtKSwNCj4+Pj4+IHlldCBl
c3BlY2lhbGx5IGZvciBBcm0gKGFuZCBpbiB0aGUgZnV0dXJlIFBQQyBhbmQgUklTQy1WKSBh
bnkgZnVydGhlcg0KPj4+Pj4gYnVtcGluZyB3b3VsZCBiZSBsZXNzIHN0cmFpZ2h0Zm9yd2Fy
ZC4NCj4+Pj4NCj4+Pj4gVGhhbmtzIGZvciBwb2ludGluZyB0aGlzIG91dC4gT24gdGhlIFhl
biBzaWRlLCBDT05GSUdfQ1RMRE9NX01BWF9PUkRFUg0KPj4+PiBhbmQgQ09ORklHX0hXRE9N
X01BWF9PUkRFUiBzZWVtIGJpZyBlbm91Z2ggb24gYWxsIGFyY2hpdGVjdHVyZXMuIEJ1dCBJ
DQo+Pj4+IHNlZSBDT05GSUdfRE9NVV9NQVhfT1JERVIgc2V0IHRvIDkgKGFsc28gYWxsIGFy
Y2hzKS4gV29uJ3QgdGhhdCBiZSBhDQo+Pj4+IHByb2JsZW0gZm9yIGRyaXZlcnMgdHJ5aW5n
IHRvIGFsbG9jYXRlIG1vcmUgdGhhbiB0aGF0IGZyb20gYSBkb21VID8NCj4+Pg0KPj4+IEEg
ZHJpdmVyIGFzc3VtZXMgYSAocGh5c2ljYWwpIGRldmljZSB0byBiZSBpbiB0aGUgRG9tVSwg
YXQgd2hpY2ggcG9pbnQgaXQNCj4+PiBpcyBDT05GSUdfUFRET01fTUFYX09SREVSIHdoaWNo
IGFwcGxpZXMgKFBUIHN0YW5kaW5nIGZvciBwYXNzLXRocm91Z2gpLg0KPj4+DQo+Pj4+PiBI
b3dldmVyIC0gZG9lcyB0aGUgZHJpdmVyIHJlYWxseSBuZWVkIHRoaXMgYmlnIGEgY29udGln
dW91cyBjaHVuaz8gSXQNCj4+Pj4+IHdvdWxkIHNlZW0gZmFyIG1vcmUgZGVzaXJhYmxlIHRv
IG1lIHRvIGJyZWFrIHRoYXQgdXAgc29tZSwgaWYgcG9zc2libGUuDQo+Pj4+DQo+Pj4+IFNp
bmNlIHRoaXMgd29ya3Mgb24gYmFyZSBtZXRhbCBJJ20gYWZyYWlkIHRoZSBkcml2ZXIgbWFp
bnRhaW5lciAobXB0DQo+Pj4+IGZ1c2lvbiBkcml2ZXIpIHdpbGwganVzdCB0ZWxsIG1lIHRv
IGZpeCBYZW4uDQo+Pj4NCj4+PiBXZWxsLiBUaGUgYmlnZ2VyIHN1Y2ggYWxsb2NhdGlvbnMs
IHRoZSBsYXJnZXIgdGhlIHJpc2sgdGhhdCBvbiBzeXN0ZW1zDQo+Pj4gdGhhdCBoYXZlIGJl
ZW4gdXAgZm9yIGEgd2hpbGUgc3VjaCBhbGxvY2F0aW9ucyBjYW4ndCBiZSBmdWxmaWxsZWQg
YW55bW9yZQ0KPj4+IGV2ZW4gaW4gdGhlIGJhcmUgbWV0YWwgY2FzZS4NCj4+DQo+PiBZZXMu
IEkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIGp1c3Qgd29yayBhcm91bmQgdGhpcyBpc3N1ZSB3
aXRob3V0IGhhdmluZw0KPj4gZXZlbiB0cmllZCB0byBnZXQgdGhlIGRyaXZlciBmaXhlZC4g
SW4gY2FzZSB0aGV5IHJlZnVzZSB0byBjaGFuZ2UgaXQsIHdlDQo+PiBjYW4gc3RpbGwgaW5j
cmVhc2UgTUFYX0NPTlRJR19PUkRFUi4NCj4gDQo+IFRoYW5rcyBmb3IgdGhlIGZlZWRiYWNr
LiBJJ2xsIHRyeSB0byBoYXZlIGEgbG9vayBhdCB0aGUgZHJpdmVyIGlmIEkgaGF2ZQ0KPiB0
aW1lIHRvIGRvIHNvLg0KDQpBbm90aGVyIHRob3VnaHQgd291bGQgYmUgdG8gY2hhbmdlIHRo
ZSBnZW5lcmljIERNQSBhbGxvY2F0aW9uIHRvIG5vdCByZXF1aXJlDQphbGlnbm1lbnQgYmFz
ZWQgb24gdGhlIHJvdW5kZWQgdXAgc2l6ZSwgYnV0IG9uIHRoZSBsYXJnZXN0IHBvd2VyLW9m
LTIgY2h1bmsNCmZpdHRpbmcgaW50byB0aGUgcmVxdWVzdGVkIHNpemUuDQoNCkkgZG9uJ3Qg
c2VlIHdoeSBhIDIuMyBNQiBtZW1vcnkgYWxsb2NhdGlvbiB3b3VsZCBuZWVkIHRvIGJlIDQg
TUIgYWxpZ25lZC4gSXQNCnNob3VsZCBiZSBwZXJmZWN0bHkgZmluZSB0byBhbGlnbiBpdCB0
byAyIE1CIG9ubHkuDQoNCg0KSnVlcmdlbg0K
--------------N004l0OXHZtI0hPekMD1aKf8
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-----

--------------N004l0OXHZtI0hPekMD1aKf8--

--------------KONvUQBmacrsoI30Y0kRMJZz--

--------------IU1rzrY1hP2GvmiIBYMdsg6k
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/Ey8FAmdisNYFAwAAAAAACgkQsN6d1ii/Ey/b
Pwf/Uq2jGlmTcfz+X1FzYRn6+X+tgSkBHBAYSArocNyfSZ39G0Kkp8y1i93yNO32ncU7Xd+DXGxa
Somn35DX7vZSeePMW6iLCcebaRr/HDrT5fVhMsUdhwpRJ21B0s8TNO/N5sLBfdLZJyaJH7dDPS8G
W62w1Zqhko9rgvpJejA/xZ7Vu8wtzNW8DSUqZtDdmGHQ7SL4GvqMta1DzLk3iAxxKsjBW0zkXWsq
i7FsRO4lFwtcMuhCXXVC+mlM4SN5xRNDULF7uMex0xVDGmuYx7zF3wIBfvtH0JrvYK54Oz3zpV0a
W7aXmKhaMN4r2xxSkWNUnbCvNHCTVQjYQ4wALRrCnQ==
=UJGJ
-----END PGP SIGNATURE-----

--------------IU1rzrY1hP2GvmiIBYMdsg6k--


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 11:35:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 11:35:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860311.1272353 (Exim 4.92)
	(envelope-from )
	id 1tNsKR-0007V4-0r; Wed, 18 Dec 2024 11:34:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860311.1272353; Wed, 18 Dec 2024 11:34: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 1tNsKQ-0007Ux-UZ; Wed, 18 Dec 2024 11:34:58 +0000
Received: by outflank-mailman (input) for mailman id 860311;
 Wed, 18 Dec 2024 11:34: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 1tNsKQ-0007Ur-DS
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 11:34:58 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2060d.outbound.protection.outlook.com
 [2a01:111:f403:2418::60d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1a1e150d-bd34-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 12:34:55 +0100 (CET)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by MN0PR12MB5835.namprd12.prod.outlook.com (2603:10b6:208:37a::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Wed, 18 Dec
 2024 11:34:50 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%6]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 11:34: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: 1a1e150d-bd34-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Ur9wSuNQZf2gkAt6e8Oc7GzX2KNzetNIKBPcbNOOqQ0X/WU9ztvlaUVsnGRPVcSRyud8nGemfg0L3ZePqzL7omN34tfva4UgZ2Gr+KUI16Q0KA7IPIox2IptB8BjJIjUYUfhv3t/Z1xMeEt5FDd54NmwtSdGYd+e3nK1asURGutzZjj++I2BxfpZ4aP1660Sd8txuJMBw4Xd5SqYZ7IOgQ8ig60+gg7QTx3EEGBe+q9ncUEuzUl2JO5j02bWueru/Y/Pvjq3IL5Trj3CQtYx37YACOjsE9qxJm/CxPYRMiVepripXFQgTURNOZjrmOB8GgFuQxbvB9NTrFDSs/fZhA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=4ko0wWBNIHISshnI6EwOczzUiYI6ife7vii1rLw/eGU=;
 b=t+dxw4Fo4QC/QthpILnMOk2HnfQgf0qwQUTNQF9RutNqV1qjWu8aHjXE44VeufCtA7QbS4jqCxxWke+sobhLYCO6BUzdGa9dOIEHj2xIWAlhm511mdXJFEDmy6Cf5rCWUgJ8cUESL/l9PP+aV1ObSZoeSQnoQjvJAkVHI6gq2qBn12qkAUaOnWOzsItrNg+Dxo8eX7flwVrcwb0R6nFIiPRmJjgpTZs2XbWQ1ibXA60eEOPQ6ha37QJ6ok0qC/kF1hWTX+vprMIg2It6bTeiUD4NFGPXUGz7rFgSzQeGJkyWghZfYGsoJpplgSpRT4FXXFBt2nxNLT7rHBYtQmlacg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=4ko0wWBNIHISshnI6EwOczzUiYI6ife7vii1rLw/eGU=;
 b=i1VHMXCX6yDRM70gIPIkYbxRTLrvJIKt4OiKUFkPyshWV5I2tN/9RyUm4zIIz99IpIEw/NpHf4RJf3IDpolgQV9NXoYm1jVMesRr4Xt7sB0Mm9wLO6HlEQNrzGRpaciTOlrxQbLELr+72UzpfRI3vePyp7sC3wdx5+9Ekxb00tU=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <2cf952f4-69cf-4eea-aace-4b7bf291b9f3@amd.com>
Date: Wed, 18 Dec 2024 11:34:44 +0000
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] docs: fusa: Add dom0less domain configuration
 requirements
Content-Language: en-GB
To: Bertrand Marquis ,
 Ayan Kumar Halder 
Cc: "xen-devel@lists.xenproject.org" ,
 Michal Orzel ,
 Stefano Stabellini ,
 Artem Mygaiev 
References: <20241212190325.2130129-1-ayan.kumar.halder@amd.com>
 <779AFC45-3F8C-4065-A39E-9325F9C72AAD@arm.com>
From: Ayan Kumar Halder 
In-Reply-To: <779AFC45-3F8C-4065-A39E-9325F9C72AAD@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P123CA0253.GBRP123.PROD.OUTLOOK.COM
 (2603:10a6:600:194::6) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|MN0PR12MB5835:EE_
X-MS-Office365-Filtering-Correlation-Id: 91896b7c-bf6f-4fde-6b10-08dd1f57fbbf
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:
	=?utf-8?B?dkhHVHNzZFJXbHdMNmYrU2lkakRrNWhGMStEUjZKUHN0YWNqcXZUc2VLelpa?=
 =?utf-8?B?SGVGYTNCT2ZIenlqdEdsRlZGSUNlM3FwNmx2MXdsUVc2UnRscEwzOG5Majl4?=
 =?utf-8?B?bVRReTN0QXBIbDdxZGVpSzVFUmd4TjFoaHE4clhCRWM5djVTWnE4c1Z6Y01l?=
 =?utf-8?B?ZElBU2huVll6eUUrR1lDVnpJcnJGM1FZeGp5YVUveDJJa2VUS0swVWNwQjlO?=
 =?utf-8?B?MXlSQmtwcGlDRVg4bVRJVy9peUJRSlBIaU9vdTJYUmZ1dGJWa3kvdHFBaGl2?=
 =?utf-8?B?dWoxUXZDVEQ5Vk5wU296YWhSQU40dllaRkFZTXZwK2ZpU2tYK1lWdWtZcDhM?=
 =?utf-8?B?RWJEcU1Bdyt1WWROd0hrUndIbzZYbk5lU0lWTkZzQ083NEtTVDhPU1JSdDRY?=
 =?utf-8?B?RkRSSGlnUFJCWG0yT3NLVGhZbkw3Rk1wSE94ZU0ybS9RdUJkZFdJVHRHRGZ3?=
 =?utf-8?B?eUgzY2sxRjVweVd4amcyVVVyd1EvWDN4WmNRTUZJaDl1K0FXanphUlBST0Nv?=
 =?utf-8?B?eUtQR1hFVjlJS1hxKzFGK0lVQjVjVDdlT1c1NEt0dW10dEI2Q1lwL1dmbW1L?=
 =?utf-8?B?RWRhTG85d2NCaHJ6VVpBaTlsZG9ueHdGMmxOU3FHYnV3cisxYmNCNUZ0blNj?=
 =?utf-8?B?SVpnTEZuZ1ZKUUdZc0tMb09TaEtKTU95U2YrNjBuZlR6TXlnZzhpTnhWS2xQ?=
 =?utf-8?B?SVRPZjJDQ2lQbE9ZMVJ3R1craHp3UG9hdmFHOFhhalhQdHJZV3BJME1zV1RV?=
 =?utf-8?B?ckdwbWlrWm4raXAvMk5UY0tsdXJxbjlEb21OQjhGSTladk5RU3NyT1d1bGdM?=
 =?utf-8?B?Q0FQdDNZUld6cnF4K1dZYnNYcXlWNmQ4WDdsTFRodjdodU9Od1NBVy9rYU9Y?=
 =?utf-8?B?MUJsQXdHNTlybWE5KzFLM3VVWmhYWjVxRElCVTk0ai8vOVJUUU4zeWZNUTdh?=
 =?utf-8?B?WklzL2x4dno0TkFZSVkwMHJwblViZFlYbmNXd1dxUVZLQ3VaZHg5Zlo5NXpK?=
 =?utf-8?B?SVdmUzJQNzc4bDlBeUUyZGJnM0pUQkVXelloQTRTZGQ0Y093V0RUNVZpMW1V?=
 =?utf-8?B?ejBNWkVLT2FFSVlwN2g1MGZXRVJDZGEwNkZlUFk4UzBiTDZJVlVNRFRBd2VD?=
 =?utf-8?B?SHdKSUtuWVFZRGR4ZGFWZzUxMi80QUlrb2hsOXZQeWthRUZWUHVTd3dsOFV0?=
 =?utf-8?B?akhnQnU4aSt0cFZRaFVKQWhVN0hUQ05IUEEyZ1hUYWRQQTFRM3htRWRKa0lB?=
 =?utf-8?B?Tk11WUVPajRKZjZlQVpPZFdSSDlOZUVzU0N0eGdybjBrejhtTStPakZaajhS?=
 =?utf-8?B?dEtkcVMxbFNTcHVvZVZ6djY0RXdvNEp6bXJsREFidDI3TVZ1dXRjbDFzemJq?=
 =?utf-8?B?OTE2NmpwMjlGU1llNDY2MU9BMVIva1dDRys5LytmZmg4a3F0VFJpajVPR25v?=
 =?utf-8?B?a2xoU1kray91ZmxCQlRsUWJOeGtHa1p0WkdoSDAxeUxPbzFJelJSVVoxQ3ht?=
 =?utf-8?B?NFNJR3IwZU1pYlhwS203N2FEWWRwU0F0elZiKzhqa2dJbkQ1bzVmRjFQeDZW?=
 =?utf-8?B?VldtTUJKcGdZajFDS2g1R2o2S3ZPZjc3Y0Rwam5ESjk4empCOC9Ec2FPM0M5?=
 =?utf-8?B?RHJOU01iMzhkaVVJeGR3ZzdzdEttWkdtUmNFSVlHSGVLelVpNmZ3QTRjajZK?=
 =?utf-8?B?NVk1QVc3a0RUNFJ4MmsxdGo5Q05Xa2pvZFFhcURwREp0Vkt6YlBkS3RpZGtV?=
 =?utf-8?B?R0xraGlHK0VOOHhZanljbk5WVWRrbzI2NW9YUUVGbmp5djB1MTdXWlpJSU1x?=
 =?utf-8?B?TXUrYXZPYzcrTEY4d2VRZz09?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH8PR12MB7326.namprd12.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?cy9oWmcyY3JaeGZ6L0NXMFd4dFI1cm51eUZTUjRsV0xvOUdycnJndXFRTlR0?=
 =?utf-8?B?UHNPVlhaMEVHRWFoUEc5c3FEalY0Um1GQWdta0VlaHEyRzd4aUdpOWhVQW5W?=
 =?utf-8?B?YVhUNlcxQ2tKMmVYOXVtYmZCcXU2d005T1FoTWQ2SW5sNTl5Tkp6WTVaOTAw?=
 =?utf-8?B?WTJZR2ZDVXR6aVZZVHpCNk1QOUZCTTdmdXRNRGRKdW40Lyt1alluc2lkdytO?=
 =?utf-8?B?cDNuNW51RnJ5SG5kUjkxWEUrZ2w0M2FIL0VYNzRpbFl5OHB2aDR0REI3emRI?=
 =?utf-8?B?V0VvN1owbmhSUmZwS25SVFJXaFNWeFFvSWFIVWorUkd2QTNpRGpRVis2L0lU?=
 =?utf-8?B?Ym9xV0FJaE5ieHZoSGphU3VpcS9QM0c0UVJwa29ic0tacE9GdVZOblN0Ri9w?=
 =?utf-8?B?aDlJMTA2YUFpOHU3azhkbHRHdEROR25ka1FKWTNYbFl2cmhIZ0tvNG9Dd3RB?=
 =?utf-8?B?azV6ZmJTaXQvemJ1cVk5RGdPamNoUWIwSDR0UGFybGlwaWdJS2QweFVkMWQr?=
 =?utf-8?B?Y1huZDBuemx2bEF2WmwwdUtlbHRzYllRS2VkOENDUUlLcnhIbjNhc0thZzl6?=
 =?utf-8?B?SFZpWjVRdGprcHlIL29pNkJZVTV4ZDVKSVY1ZWhvMHF5VDRnaXFGZDdXcGs0?=
 =?utf-8?B?dU8yOGNHQnJRZDRwc0lXWGtONGJCR3JZL3JSM0pHVThPSkFURmZMa0FHY3RU?=
 =?utf-8?B?ZGJOdzlGTUxPeHlhZEdqSVhCMFV5QkhhcXNkTU4zY3lZZFZ6WGlLeGJVS1Jh?=
 =?utf-8?B?NVZOcVg5cVlZR0RjREF6ZXkrWDZ0d1BzdFdSTVlrZG5zYTBjWlpOL0JpdTRR?=
 =?utf-8?B?QkNLZGFYYTlUWVg2MWs4Q1o4a256czE1bGhDSXArVCs5c0VKSllEN1hxK1BT?=
 =?utf-8?B?UkM4T2xsSTdhSXFpd0dwa1NPZUZGSkNRcWZMOFlZbzlES3ovYytadjJYV09Q?=
 =?utf-8?B?VmlUM29OZnZVMjBydWxPam9yUnFHRzFKbnBjY3BBZTE3R202Wm1BTHc0KzJI?=
 =?utf-8?B?dnBEdThzN1NYTFhEWjBvTkd0TjFnT01ScTVac1RwOFY1OHhLamxvb2ZRMFlh?=
 =?utf-8?B?dC9GVUwyWCtXUGhaVGozLzZZNTJKLzN0WlpOaTM4NCtEVGxsMTJnQUtrc0Fk?=
 =?utf-8?B?REJUTFpIWXlsWEhnb3BJUDRSNUN3RUl1YnNUWEFWMERMOFYvbk9VRDFXZDB4?=
 =?utf-8?B?TDZldFh4WlZGS3FxcWViaXBIcmtCcTFtMnJZMGk3bUU2ampnMEEySVY2cGVQ?=
 =?utf-8?B?MkV3V1dLOEJTalFKQjVPamgxTkhmbVZFVTBTRlJ6bk1Bb2pHTzlYRXlrYkpC?=
 =?utf-8?B?bmJwWUdFRi9OaVRZbW1zRlkvQi9MR0U1RjBEYTlRK1IzNXF6czhLZWFUMXRR?=
 =?utf-8?B?YUdEd3UxTlBDWXRUNzN1NGhBeDJxZlRtL3RxVW01azRWcDhBeS83L09rZ3Rn?=
 =?utf-8?B?SEhRSm5yMndvb2NjUzV5eURuZ0VmbWlaRkdBeVd2dXc5YWFvSzF5bjdHNCtt?=
 =?utf-8?B?UDFYL1RwSVRXaDV0cTFMaXBySFJ0OTJrRTB2T1M5KzhUbVN1ZGYyblM1UEZy?=
 =?utf-8?B?b2Z4Y2IvSHlHc1pBTUNmTWxxbFg0eG5QRmRpUWFvbjhaN1d2dDhYVzZ0VWRt?=
 =?utf-8?B?bkNqSlJxRUgxMnVxSDhjdjNYN1laM01SZUF3dGNjbFp3VDI0MTRLeWUwSnB4?=
 =?utf-8?B?dG5qb2xMY3U4YlZJMG51M1dBclVibkZTaWNxTzRPR1h6eWcwRnRxL3RDajVl?=
 =?utf-8?B?TTNlWkMvKzVsU09EWlV5dUJTa3Q4ekR4d0pJY29KdEpJUnpWK2lIVTRhYWNU?=
 =?utf-8?B?UDZtN053bnRiR0tmQTFrNUMyMTJRWmUva1dveUdsc1FSdGZ4NEFpbWNmQ011?=
 =?utf-8?B?ZzFnZGNyZGZadGFxWGo0Sm1ZUmUxZXh1YXowSUhMQUFIRmQ0TnByQ1lnRjFX?=
 =?utf-8?B?akcvT0ZjbHVvNDVJdDlsNG42Vk1KMFd2VVQ4ZmM5cFdMczg4TUFzNzJqa0ZI?=
 =?utf-8?B?eGFQZXJ1OEVRUVJjd0FMZkRwMThYU2VXSHJUbHBkQTZTMkRhM0s2L2NpTnI5?=
 =?utf-8?B?b2g4dkNDbWRkbTRSUkk0cTFKblYzdnNyTVFhaHBaendjdXZEM2diMzJwd3V0?=
 =?utf-8?Q?kUICnUugsApJO23zGVOt5f5n/?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 91896b7c-bf6f-4fde-6b10-08dd1f57fbbf
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 11:34:50.4036
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 6uWAmu0h9YOm3Keowb6fos2dBg6hEL+/EuUWdfa0YCp+IjpswZDnLqTR/RTv68T/Ey0Aa8Om9PmeGyzETHsfKQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5835


On 18/12/2024 08:27, Bertrand Marquis wrote:
> Hi Ayan,
Hi Bertrand,
>
>> On 12 Dec 2024, at 20:03, Ayan Kumar Halder  wrote:
>>
>> From: Michal Orzel 
>>
>> Add requirements for dom0less domain creation.
>>
>> Signed-off-by: Michal Orzel 
>> Signed-off-by: Ayan Kumar Halder 
>> ---
>> Changes from v1 :-
>>
>> 1. As the dom0less domain creation requirements specifies the dt properties
>> for creating domains, it has been moved to product requirements. Product
>> requirements define the interface Xen exposes to other domains.
>>
>> 2. For the requirements which introduces new terms (like grant table, etc), I
>> have provided the definition as part of the comments.
>>
>> 3. Introduced new market requirements to specify that Xen can assign iomem and
>> irqs to domains.
>>
>> 4. The design requirements will be added later.
>>
>> docs/fusa/reqs/market-reqs/reqs.rst        |  16 ++
>> docs/fusa/reqs/product-reqs/arm64/reqs.rst | 306 +++++++++++++++++++++
>> 2 files changed, 322 insertions(+)
>>
>> diff --git a/docs/fusa/reqs/market-reqs/reqs.rst b/docs/fusa/reqs/market-reqs/reqs.rst
>> index f456788d96..47e1b6ad61 100644
>> --- a/docs/fusa/reqs/market-reqs/reqs.rst
>> +++ b/docs/fusa/reqs/market-reqs/reqs.rst
>> @@ -47,3 +47,19 @@ Comments:
>>
>> Needs:
>>   - XenProd
>> +
>> +Static VM definition
>> +--------------------
>> +
>> +`XenMkt~static_vm_definition~1`
>> +
>> +Description:
>> +Xen shall support assigning peripherals to various domains.
>> +
>> +Rationale:
>> +
>> +Comments:
>> +Peripheral implies an iomem (input output memory) and/or interrupts.
>> +
>> +Needs:
>> + - XenProd
>> diff --git a/docs/fusa/reqs/product-reqs/arm64/reqs.rst b/docs/fusa/reqs/product-reqs/arm64/reqs.rst
>> index db91c47a02..66f2978733 100644
>> --- a/docs/fusa/reqs/product-reqs/arm64/reqs.rst
>> +++ b/docs/fusa/reqs/product-reqs/arm64/reqs.rst
>> @@ -40,3 +40,309 @@ Covers:
>>
>> Needs:
>>   - XenSwdgn
>> +
>> +Linux kernel image
>> +------------------
>> +
>> +`XenProd~linux_kernel_image~1`
>> +
>> +Description:
>> +Xen shall create a domain with a Arm64 Linux kernel image [1].
> This shall be rephrased to mention that it shall be a binary with a header compliant with the Linux kernel image format.
> We do not want to say that we can only boot Linux.
>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenMkt~run_arm64_domains~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +Gzip Linux kernel image
>> +-----------------------
>> +
>> +`XenProd~linux_kernel_gzip_image~1`
>> +
>> +Description:
>> +Xen shall create a domain with a Arm64 Gzip compressed Linux kernel image.
> Ditto.
>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenMkt~run_arm64_domains~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +Kernel with uImage header
>> +-------------------------
>> +
>> +`XenProd~kernel_uimage~1`
>> +
>> +Description:
>> +Xen shall create a domain with a kernel containing uImage header [2].
> I would remove kernel and say binary executable and add compatible or something like that.
>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenMkt~run_arm64_domains~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +Gzip kernel with uImage header
>> +------------------------------
>> +
>> +`XenSwdgn~arm64_gzip_kernel_uimage~1`
>> +
>> +Description:
>> +Xen shall create a domain with a Gzip compressed kernel containing uImage
>> +header [2].
> Same
Agreed with all the above.
>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenMkt~run_arm64_domains~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +Kernel command line arguments
>> +-----------------------------
>> +
>> +`XenSwdgn~kernel_cmd_line_args~1`
>> +
>> +Description:
>> +Xen shall pass kernel command line arguments to a domain.
> I am a bit wondering if this one and the following are not a bit to generic.
> Should we say through DT or ACPI header for example ?
Yes, I can say through device tree. And then I can explain device tree 
in the comments.
>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenMkt~run_arm64_domains~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +Ramdisk
>> +-------
>> +
>> +`XenSwdgn~ramdisk~1`
>> +
>> +Description:
>> +Xen shall provide initial ramdisk to a domain.
> This should be mentioning that it is provided in memory and the address is provided through DT.
Ack.
>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenMkt~run_arm64_domains~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +Memory
>> +------
>> +
>> +`XenSwdgn~memory~1`
>> +
>> +Description:
>> +Xen shall create a domain with specified amount of memory.
> I am missing the where this is specified here ? i guess this is also DT
Yes, this is also DT.
>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenMkt~run_arm64_domains~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +vCPUs
>> +-----
>> +
>> +`XenSwdgn~vcpus~1`
>> +
>> +Description:
>> +Xen shall create a domain with a number of virtual CPUs.
> number here is unprecise
Can I say with one or more number of virtual CPUS ? How would you want 
me to define.
>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenMkt~run_arm64_domains~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +Credit2 CPU pool scheduler
>> +--------------------------
>> +
>> +`XenSwdgn~credit2_cpu_pool_scheduler~1`
>> +
>> +Description:
>> +Xen shall assign a Credit2 CPU pool scheduler [3] to a domain.
> What is Credit2 ? this needs to be defined somewhere
I have provided a link to the credit2 documentation.

https://xenbits.xenproject.org/gitweb/?p=xen.git;a=blob;f=docs/features/sched_credit2.pandoc

Do I still need to define it as
"Credit2 is a scheduling mechanism where more than one virtual cpus shares a physical cpus based on a time sharing mechanism."

or should the requirement be rephrased as

"Xen shall have a scheduler where a physical cpu can be shared between more than one virtual cpu".

> and in fact it
> shall have product level requirements.
Do you mean this needs to be a product requirement ?
>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenMkt~run_arm64_domains~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +NUL CPU pool scheduler
>> +----------------------
>> +
>> +`XenSwdgn~nul_cpu_pool_scheduler~1`
>> +
>> +Description:
>> +Xen shall assign a NUL CPU pool scheduler to a domain.
> Same
>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +A NUL CPU pool scheduler maps a virtual cpu to a unique physical cpu.
> This is a product requirement saying that Xen shall have a scheduler with such characteristics
> and I think this is not enough to define it.
I don't understand this bit. Do you mean this should be product 
requirement written as "Xen shall have a scheduler where a virtual cpu 
is always assigned to a unique physical cpu".
>
>> +
>> +Covers:
>> + - `XenMkt~run_arm64_domains~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +SPIs
>> +----
>> +
>> +`XenSwdgn~spis~1`
>> +
>> +Description:
>> +Xen shall allocate a specified number of shared peripheral interrupts for a
>> +domain.
> This is very ambiguous. What do you mean here ?
Xen shall provide a way to specify the number of shared peripheral 
interrupts for a domain via the device tree .
>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +A shared peripheral interrupt is an interrupt generated by a peripheral that is
>> +accessible across all the cpu cores.
>> +
>> +Covers:
>> + - `XenMkt~run_arm64_domains~1`
>> + - `XenMkt~static_vm_definition~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +Grant table frames
>> +------------------
>> +
>> +`XenSwdgn~grant_table_frames~1`
>> +
>> +Description:
>> +Xen shall create a domain with a specified number of grant table frames.
> It is really weird to say that Xen shall create something specific without this being
> linked to an higher level definition of the goal.

ok, I will drop this and the following requirement for now.

When we have market requirement to specify that "Xen shall allow sharing 
of buffer with a domain", then we can add this and the following 
requirement.

>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +Grant tables are a mechanism for sharing and transferring frames (memory buffers)
>> +between domains.
>> +
>> +Covers:
>> + - `XenMkt~run_arm64_domains~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +Grant maptrack frames
>> +---------------------
>> +
>> +`XenSwdgn~grant_maptrack_frames~1`
>> +
>> +Description:
>> +Xen shall create a domain with a specified number of grant maptrack frames.
> Why is this needed ? what is the high level req for this ?
>
>> +
>> +Rationale:
>> +
>> +Comments:
>> +Maptrack frame is the metadata for tracking the memory mapped into a domain.
>> +
>> +Covers:
>> + - `XenMkt~run_arm64_domains~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +Virtual PL011
>> +-------------
>> +
>> +`XenProd~virtual_pl011~1`
>> +
>> +Description:
>> +Xen shall provide an "Arm PL011 UART" compliant device to the domains.
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Covers:
>> + - `XenMkt~run_arm64_domains~1`
>> + - `XenMkt~provide_console_domains~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +Assign iomem
>> +------------
>> +
>> +`XenProd~assign_iomem~1`
>> +
>> +Description:
>> +Xen shall support assigning iomem to a domain.
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Rationale:
>> +
>> +Covers:
>> + - `XenMkt~static_vm_definition~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +Forward interrupts
>> +------------------
>> +
>> +`XenProd~forward_irqs~1`
>> +
>> +Description:
>> +Xen shall support forwarding interrupts to a domain.
>> +
>> +Rationale:
>> +
>> +Comments:
>> +
>> +Rationale:
>> +
>> +Covers:
>> + - `XenMkt~static_vm_definition~1`
>> +
>> +Needs:
>> + - XenSwdgn
>> +
>> +| [1] https://github.com/torvalds/linux/blob/master/Documentation/arch/arm64/booting.rst
>> +| [2] https://source.denx.de/u-boot/u-boot/-/blob/master/include/image.h#L315
>> +| [3] https://xenbits.xenproject.org/gitweb/?p=xen.git;a=blob;f=docs/features/sched_credit2.pandoc
>> -- 
>> 2.25.1
>>
- Ayan


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 12:39:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 12:39:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860351.1272368 (Exim 4.92)
	(envelope-from )
	id 1tNtKF-0000d2-WD; Wed, 18 Dec 2024 12:38:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860351.1272368; Wed, 18 Dec 2024 12:38:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNtKF-0000cu-TN; Wed, 18 Dec 2024 12:38:51 +0000
Received: by outflank-mailman (input) for mailman id 860351;
 Wed, 18 Dec 2024 12:38: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 1tNtKE-0000cm-Ke
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 12:38:50 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 06fb9003-bd3d-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 13:38:48 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5d7e3f1fc01so3057121a12.2
 for ; Wed, 18 Dec 2024 04:38:48 -0800 (PST)
Received: from andrewcoop.eng.citrite.net (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d652ab4ff2sm5382268a12.9.2024.12.18.04.38.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 18 Dec 2024 04:38: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: 06fb9003-bd3d-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734525527; x=1735130327; 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=gl2sBU/KJugrx1gSriiA8QfWThH3/Rj0B4iEbbxvC7I=;
        b=svdXKCbp/REiL/UM5Mcsn84+sXD82/5upUjEPLuOHMGyAGXdZbcbVvV0wZWS0LHrb/
         RFN9U+hSLSrQr1wssMHjYuVhv1UlxqcsvbREfAbhV2Q8yrl61HjYJLpRuQuHphLZbXyF
         SQkFQ2JuJwJNZJEQy02tpeE2BXSRsIG79Npno=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734525527; x=1735130327;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=gl2sBU/KJugrx1gSriiA8QfWThH3/Rj0B4iEbbxvC7I=;
        b=KSRYSoISOc2RumOmRFECi6Z1KtwmBa8vyJINo1EGInFG3lhJ8lW7CzHvEil0l7Qm8s
         mjcadgX+38y61CePQsiXy+93TMAADumTBqhPkrQINNMfCzP0r00WfL+hvdZOfUWtSiqU
         DsjrqXvcKWCwNua+pcNC3JYCkxoAMsuBjY1UW/Exau40oDhkPftdImh5Tjjun6pJiu4d
         LPX6tjAuHlZlR/NoaaevIdkqKCerO8blZhu9l2vL0Y/cMOuFIKuu63h+PwqT3GaHT3b6
         ZsvPmhlJyrYF6YEoUfwdSxQNcfSdMO94b/nK8TvJJ0HeQcTrVd4II4C8hONyzlxsr6aN
         rUDw==
X-Gm-Message-State: AOJu0Yxvpxiv6PgrFbhiBXttnAv91nhHr8ulpUs/kRpbj3aISZMQbkr6
	IpGT27wl5k+W+b+GZNH0lWzC6imyFk0auhJwGewJjMjsNMQMzp4jHmk8CSH3bingXxHL871d/eI
	RHso=
X-Gm-Gg: ASbGncuxztqWeslkXHLJ1Tb+IC7G2VHof9BMKF4kkL8eZsp6in4LsygCwIJc1j0/V8y
	zn0d+cdvvsV/5/CDtwKa+vWA3+timeQASgQHL8RbbIe7GLgqO2+O99nuD6QWLzmoTFhA6P/ymix
	ABXFaxbHVBtKHL8CQY6CMIU2QZ//Z8TtWDZvntKBJMKDmrccrz6nQV3phgVEMSpPjiGj6Lvesmd
	nC+b4QV+RRn6kcnLUaPcdFnsKSZTIlDumPzJvQNXwM4/VvPI/+ZtPqj9hUUMbXagXT/bBLYpJXD
	vzUvsY94tXku0vuEI+MzKMN/LQpltnuwRs0m
X-Google-Smtp-Source: AGHT+IErdKWogH55PesY4lV95oEJT+pWLqP53Dt1q/63JRuFYM0enAhXlhdxLeOYxX4FoWCllF4Wzg==
X-Received: by 2002:a05:6402:5418:b0:5d3:c4a8:d259 with SMTP id 4fb4d7f45d1cf-5d7ee3cc788mr2356673a12.19.1734525527242;
        Wed, 18 Dec 2024 04:38:47 -0800 (PST)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH] x86/boot: Use printk_once() instead of opencoding it
Date: Wed, 18 Dec 2024 12:38:45 +0000
Message-Id: <20241218123845.58850-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

Adjust the message for brevity.  No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
---
 xen/arch/x86/setup.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 0a748e2c1412..decb566939dd 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1060,7 +1060,7 @@ void asmlinkage __init noreturn __start_xen(void)
     unsigned int initrdidx, num_parked = 0;
     struct boot_info *bi;
     unsigned long nr_pages, raw_max_page;
-    int i, j, e820_warn = 0, bytes = 0;
+    int i, j, bytes = 0;
     unsigned long eb_start, eb_end;
     bool acpi_boot_table_init_done = false, relocated = false;
     bool vm_init_done = false;
@@ -1297,12 +1297,8 @@ void asmlinkage __init noreturn __start_xen(void)
              */
             if ( (map->base_addr_high == 0) && (map->length_high != 0) )
             {
-                if ( !e820_warn )
-                {
-                    printk("WARNING: Buggy e820 map detected and fixed "
-                           "(truncated length fields).\n");
-                    e820_warn = 1;
-                }
+                printk_once(XENLOG_WARNING
+                            "WARNING: Buggy e820 map detected; truncated length\n");
                 map->length_high = 0;
             }
 

base-commit: 171cb318deaa0be786cc3af3599c72e8909e60f9
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 12:49:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 12:49:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860360.1272377 (Exim 4.92)
	(envelope-from )
	id 1tNtU9-0002MU-RF; Wed, 18 Dec 2024 12:49:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860360.1272377; Wed, 18 Dec 2024 12:49:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNtU9-0002MN-OY; Wed, 18 Dec 2024 12:49:05 +0000
Received: by outflank-mailman (input) for mailman id 860360;
 Wed, 18 Dec 2024 12:49: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 1tNtU8-0002MF-7B
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 12:49:04 +0000
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [2a00:1450:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 75b75e50-bd3e-11ef-a0d6-8be0dac302b0;
 Wed, 18 Dec 2024 13:49:03 +0100 (CET)
Received: by mail-ej1-x632.google.com with SMTP id
 a640c23a62f3a-aa543c4db92so13017466b.0
 for ; Wed, 18 Dec 2024 04:49:03 -0800 (PST)
Received: from andrewcoop.eng.citrite.net (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab96087b41sm550388966b.87.2024.12.18.04.49.01
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 18 Dec 2024 04:49: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: 75b75e50-bd3e-11ef-a0d6-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734526142; x=1735130942; 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=ECBT7XQea3ud/yVLfGyT/XfYKCyUP/SbpIhDz6Y3eF4=;
        b=IxHkks3pQ/Gqzn3Ghh3pm9oHyY404WfvbN/4N3W+fAnk4bgedPxJd+a/81hEIdySRv
         vPwfrMa8BY4BQSRspXQ6wMylhz2QWN+VNPLDfixJRyZwQR5Bkp1ckfTJY/ixDA6IcBNH
         88b0tF4j1+9fBn+VXFDorW88V8NFbyl4UJjRE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734526142; x=1735130942;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=ECBT7XQea3ud/yVLfGyT/XfYKCyUP/SbpIhDz6Y3eF4=;
        b=SSw0exnRJpomtd50mLohneRVuxLoJ2rkLCx8vWCsKSKKIYETIVCvS203fluT/9/+P6
         isHN3orNWb4gFPuV1f92/Ei540xksyYZQf+CAPPVWhUs3ThVLMw4IT6rlXHuUjzl8kfI
         e8hITV+2sH8J2qTVQFhstZ+7Yl4Zx4vN2/I5N9AS3avJrH4HcRNhz7pATz2jOzw2y9r6
         RP5Q2MWelk+dEy1OuqBVi1wxZGy8x/XJS3izlmPKCEQoHJBDBzLyKk+Z57NcgXvRdtr8
         FdydlaHoky1f9l6S7Fg8XRDbDDFL7XIKh5lHaDhChl/2LKOCM4nCAEsazFrvp6hXQDJl
         jA0w==
X-Gm-Message-State: AOJu0YzUISqubYadt4AXOYLZG/+46E7x8rpAIYAQ9XpR0i/uE/5gwajd
	+OSl3LJ3arjWFX00EAQkhSNXcjQub7IyOafpfViCLucNHxbuYDLOnjj1bCFdTvwmJxypCnsO7k1
	13pY=
X-Gm-Gg: ASbGncv118Vt6CHbUKxdvVvtctPXEQFh2Vbh09zP+sUoTyLXeyx6URflzOBNjbglFhA
	F5LnqIKmaColp91vkEZxti3mc5RnDn1OjSfvnmDZBCAcS+dEZaMuBjXIjt9UgOF0gUwqo+vb3G4
	PmHDy6EHDr8GQDPqFh1zvLjEr4Efmm81RclRchNfIocyY4eiufWt/cXoW1dbKdFHh1Q3eQo53xM
	+WK3NEbdr8FwHFWbV8TQr6KK4I3PdCn5d4/XwS6Yequ0JA9UqP3PvdRlMRTVmCfftfzlELCvhk0
	MWGN50Ro6RYmrJ1xySqFrdCSM9zDp3zg5eRQ
X-Google-Smtp-Source: AGHT+IFDESo+jhssZfxr8FAnOXlH8RtC8DVz39/Lb28PJg08KVN4PS8UwYuJIdcr1fDHan+HnQYCQw==
X-Received: by 2002:a17:906:bfea:b0:aa6:668b:2733 with SMTP id a640c23a62f3a-aabf47d7f69mr196732066b.33.1734526141921;
        Wed, 18 Dec 2024 04:49:01 -0800 (PST)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Julien Grall ,
	Volodymyr Babchuk ,
	Bertrand Marquis ,
	Michal Orzel ,
	Oleksii Kurochko ,
	Shawn Anastasio ,
	Juergen Gross 
Subject: [PATCH] xen/sched: Untangle credit2 vs cpu_nr_siblings()
Date: Wed, 18 Dec 2024 12:49:00 +0000
Message-Id: <20241218124900.60886-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

Credit2 has no buisness including asm/cpufeature.h or asm/processor.h.

This was caused by a bad original abstraction, and an even less wise attempt
to fix the build on my behalf.  It is also the sole reason why PPC and RISC-V
need cpufeature.h header.

Worst of all, cpu_data[cpu].x86_num_siblings doesn't even have the same
meaning between vendors on x86 CPUS.

Implement cpu_nr_siblings() locally in credit2.c, leaving behind a TODO.  Drop
the stub from each architecture.

Fixes: 8e2aa76dc167 ("xen: credit2: limit the max number of CPUs in a runqueue")
Fixes: ad33a573c009 ("xen/credit2: Fix build following c/s 8e2aa76dc (take 2)")
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Michal Orzel 
CC: Oleksii Kurochko 
CC: Shawn Anastasio 
CC: Juergen Gross 
---
 xen/arch/arm/include/asm/cpufeature.h   |  5 -----
 xen/arch/ppc/include/asm/cpufeature.h   | 10 ----------
 xen/arch/riscv/include/asm/cpufeature.h | 23 -----------------------
 xen/arch/x86/include/asm/processor.h    |  5 -----
 xen/common/sched/credit2.c              | 15 +++++++++++++--
 5 files changed, 13 insertions(+), 45 deletions(-)
 delete mode 100644 xen/arch/ppc/include/asm/cpufeature.h
 delete mode 100644 xen/arch/riscv/include/asm/cpufeature.h

diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h
index 969e043f5bda..50297e53d90e 100644
--- a/xen/arch/arm/include/asm/cpufeature.h
+++ b/xen/arch/arm/include/asm/cpufeature.h
@@ -98,11 +98,6 @@ static inline bool cpus_have_cap(unsigned int num)
     return test_bit(num, cpu_hwcaps);
 }
 
-static inline int cpu_nr_siblings(unsigned int cpu)
-{
-    return 1;
-}
-
 /* System capability check for constant cap */
 #define cpus_have_const_cap(num) ({                 \
         register_t __ret;                           \
diff --git a/xen/arch/ppc/include/asm/cpufeature.h b/xen/arch/ppc/include/asm/cpufeature.h
deleted file mode 100644
index 1c5946512bc5..000000000000
--- a/xen/arch/ppc/include/asm/cpufeature.h
+++ /dev/null
@@ -1,10 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-#ifndef __ASM_PPC_CPUFEATURE_H__
-#define __ASM_PPC_CPUFEATURE_H__
-
-static inline int cpu_nr_siblings(unsigned int cpu)
-{
-    return 1;
-}
-
-#endif /* __ASM_PPC_CPUFEATURE_H__ */
diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/include/asm/cpufeature.h
deleted file mode 100644
index 41a792b0b273..000000000000
--- a/xen/arch/riscv/include/asm/cpufeature.h
+++ /dev/null
@@ -1,23 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-#ifndef ASM__RISCV__CPUFEATURE_H
-#define ASM__RISCV__CPUFEATURE_H
-
-#ifndef __ASSEMBLY__
-
-static inline unsigned int cpu_nr_siblings(unsigned int cpu)
-{
-    return 1;
-}
-
-#endif /* __ASSEMBLY__ */
-
-#endif /* ASM__RISCV__CPUFEATURE_H */
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/arch/x86/include/asm/processor.h b/xen/arch/x86/include/asm/processor.h
index 877651212273..d247ef8dd226 100644
--- a/xen/arch/x86/include/asm/processor.h
+++ b/xen/arch/x86/include/asm/processor.h
@@ -118,11 +118,6 @@ extern void init_intel_cacheinfo(struct cpuinfo_x86 *c);
 
 unsigned int apicid_to_socket(unsigned int apicid);
 
-static inline int cpu_nr_siblings(unsigned int cpu)
-{
-    return cpu_data[cpu].x86_num_siblings;
-}
-
 /* Some CPUID calls want 'count' to be placed in ecx */
 static inline void cpuid_count(
     unsigned int op,
diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
index 76a273d4f6d5..4b2ef034ca84 100644
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -26,8 +26,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 
 #include "private.h"
 
@@ -35,6 +33,19 @@
 /* #define d2printk printk */
 #define d2printk(x...)
 
+/*
+ * TODO: Abstract this properly, and figure out what Credit2 wants to do with
+ *       the fact that x86_num_siblings doesn't even have the same meaning
+ *       between x86 vendors.
+ */
+static unsigned int cpu_nr_siblings(unsigned int cpu)
+{
+#ifdef CONFIG_X86
+    return cpu_data[cpu].x86_num_siblings;
+#else
+    return 1;
+#endif
+}
 
 /*
  * Credit2 tracing events ("only" 512 available!). Check
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 12:53:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 12:53:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860368.1272388 (Exim 4.92)
	(envelope-from )
	id 1tNtYP-00044S-Cp; Wed, 18 Dec 2024 12:53:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860368.1272388; Wed, 18 Dec 2024 12: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 1tNtYP-00044L-9f; Wed, 18 Dec 2024 12:53:29 +0000
Received: by outflank-mailman (input) for mailman id 860368;
 Wed, 18 Dec 2024 12: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 1tNtYO-00044F-MW
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 12:53:28 +0000
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com
 [2a00:1450:4864:20::62f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 12a83163-bd3f-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 13:53:26 +0100 (CET)
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-aa662795ca3so146515766b.1
 for ; Wed, 18 Dec 2024 04:53:26 -0800 (PST)
Received: from andrewcoop.eng.citrite.net (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab963b2611sm556257566b.174.2024.12.18.04.53.25
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 18 Dec 2024 04:53: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: 12a83163-bd3f-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734526406; x=1735131206; 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=X2xlLDmAW5VkqoRjII2hswvrZgARiX6RUzFU9LyTIe0=;
        b=vUHsAdOswEJGoTwPoflEOGUOdk1j409g1FfMVZCfrp/qarjfFLU//VPD08NW6K9t3K
         Tr5kgPswlkdwRMlCycB3ki9PUJt2EAgE7WLchTm6uCocWW85+Vr3n7yieGG0/lh3MjRj
         VnIfsiivYToM/Q8qNpqU2srgeWKcXtWl7ZKLw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734526406; x=1735131206;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=X2xlLDmAW5VkqoRjII2hswvrZgARiX6RUzFU9LyTIe0=;
        b=VplawRWEX7p4rjHoHms38gb7gNhu712/u1C7z5yRF4Pcf4GAG9dlFVCiuYDE2/WhPL
         Qk/LtypbeoFD1YSmIyanmjxx9LypbAz2jfCLLjO2sfxuvQZPitZMeTqZCiD6eUs0nbUI
         WmY5MPaNWPLPYyYqRjjO95HD3t60ZzgZjFLqCbqIv89bDx9u/4VpqKWA9Uxid2bmFQBW
         xq1udLQQ7F1hlGWzsj+dh8Kh5xnKa11cHPr6p1SXIo7R6Ac1mPDOBY8cMcLr8XUtVHQ0
         c4FGxtrd8mFUsvdo8xddfL2ckTOpnh2TUk3doe5/k9Ybm/sWZwlz7xwwcmfaGmBdXpu8
         60ZQ==
X-Gm-Message-State: AOJu0YwZRekYci90VCAduxH+UjTWDBVNRGu5DAIJmSZo2Yy8njQSdjKF
	F+6nJ7BhT6zh2tqeoazFp8IqiiBkf1wQ8IMrdKneSy0qRtby4YwMQjySIgikApReil9pfmusxFH
	0lDQ=
X-Gm-Gg: ASbGncuV9PS/8jjyjBWfVvfpVAEGxaGQvzZRxUlkTE1k+GVIBnSIPOFhJhtvbdOJ2Du
	RWQA37RJ69VpG4pjFyZofsHVaVBBOLHUMVhU3+DFu8ey7ZX1Ub1CFQSr9MTfiKL+WAGJFw3+6WH
	O3pAXcKIQHUqgt7NdVc8dzDxGV7y725Lfo1n4qgwLBkCwXlu/Hj1KNNNxiopl1U0+oF0hUlxb7l
	ODuo+McchU0BNUbOqftREQ457nqcv1kFuw5PRFE7pDkPyrnYeLNbNXrfcXCowmydtSWz5wBrsXM
	qH8HfcEFiuAGcW/IomD0UiXta9/Feyi5N5Mh
X-Google-Smtp-Source: AGHT+IGPD3ar8cxsXxCPl/UcUBZnHiuWl8jDPbPt97EL1xcYrBrCCQBNCcMWVOsORRMujI5huunmDQ==
X-Received: by 2002:a17:907:944a:b0:aa6:9dcf:e273 with SMTP id a640c23a62f3a-aabdc895a70mr707369466b.12.1734526405839;
        Wed, 18 Dec 2024 04:53:25 -0800 (PST)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Juergen Gross 
Subject: [PATCH] x86/sched: Drop unused includes from credit2.c
Date: Wed, 18 Dec 2024 12:53:24 +0000
Message-Id: <20241218125324.75973-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Sort the remaining includes.

Signed-off-by: Andrew Cooper 
---
CC: Juergen Gross 
---
 xen/common/sched/credit2.c | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
index 4b2ef034ca84..0a83f237259f 100644
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -10,22 +10,18 @@
  * Based on an earlier verson by Emmanuel Ackaouy.
  */
 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
-#include 
-#include 
+#include 
 #include 
-#include 
-#include 
+
+#include 
 
 #include "private.h"
 

base-commit: 171cb318deaa0be786cc3af3599c72e8909e60f9
prerequisite-patch-id: c484a8a8e245130614407e7d25fdc27ab2e62cd3
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 13:08:49 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 13:08:49 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860383.1272398 (Exim 4.92)
	(envelope-from )
	id 1tNtn7-00062b-Ju; Wed, 18 Dec 2024 13:08:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860383.1272398; Wed, 18 Dec 2024 13: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 1tNtn7-00062U-GZ; Wed, 18 Dec 2024 13:08:41 +0000
Received: by outflank-mailman (input) for mailman id 860383;
 Wed, 18 Dec 2024 13: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 1tNtn6-00062O-ME
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 13:08:40 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20619.outbound.protection.outlook.com
 [2a01:111:f403:2613::619])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 323be91d-bd41-11ef-a0d6-8be0dac302b0;
 Wed, 18 Dec 2024 14:08:39 +0100 (CET)
Received: from DB9PR06CA0019.eurprd06.prod.outlook.com (2603:10a6:10:1db::24)
 by GV2PR08MB9399.eurprd08.prod.outlook.com (2603:10a6:150:e3::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Wed, 18 Dec
 2024 13:08:30 +0000
Received: from DU6PEPF00009524.eurprd02.prod.outlook.com
 (2603:10a6:10:1db:cafe::35) by DB9PR06CA0019.outlook.office365.com
 (2603:10a6:10:1db::24) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.21 via Frontend Transport; Wed,
 18 Dec 2024 13:08:29 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DU6PEPF00009524.mail.protection.outlook.com (10.167.8.5) with
 Microsoft SMTP
 Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.15 via
 Frontend Transport; Wed, 18 Dec 2024 13:08:29 +0000
Received: ("Tessian outbound b519d6c64997:v528");
 Wed, 18 Dec 2024 13:08:28 +0000
Received: from L3d1ed4c79503.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 E344EAA4-045C-464E-9A38-6401ACDBDFDF.1; 
 Wed, 18 Dec 2024 13:08:22 +0000
Received: from EUR03-DBA-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 L3d1ed4c79503.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 18 Dec 2024 13:08:22 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by DU4PR08MB10936.eurprd08.prod.outlook.com (2603:10a6:10:571::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.22; Wed, 18 Dec
 2024 13:08:21 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 13:08: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: 323be91d-bd41-11ef-a0d6-8be0dac302b0
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=tA3u/fsHRqaeeZlpPa7Bc9CeY+3TwolEBl3NG8iEhJ+5MFDV4IzrhOrUnLwjkvSTk9128gNIJZEnznnqrYWzLnymqcF0k5x07iEeZKK7HwzeaC2Wik70X1qezIsC0lfKw9DYsH55PNuNwCFMEgx71QtGZl2tA48Yr450xmHBKAp/ULZ0T5PrSYNI+cK5gcFEGvQJAzqwHKLdAYKBnbyq3DLtVkpQ0DfOD5Q9q0OodTow9iTlIpE3vAenSt2FytsJVIZZUbllXc8vfV5qXL7QbKVNI5enf2pjCZgSJHrslyEl177E82ljKUpGSOuVCzGB40ZSRGLNARUhu8zCswGPrQ==
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=0ZYoBm6m95gAmdsMQxvE6yda/f+Z1taeLiM3vHdA1p4=;
 b=bTcm2PDZ7EONUOBwIlq0/EYrYps4AFHgEzh/0hqBjDWZWseRVQi6mz60eT+leX7K1EF5zPVwmKO0u8Rx+BuYBVlM2IuWoURm2ZcR/aWuuEjc8S+ikjLdx/CHzR4Zqamobje3WiItuURf4KFe1H8EDulugDSgl2oMd+LF6xOwnmA8M4hCSSEkGVJV29s8Z3lgJ6feKNkCFCaW7UKN0BZuTvhAAxy6E1i9/lWmK/5T0Ayx4DkBUmsV4llig+4GmkROlaOFuBP45982x4VQeVMNNmTE0E3MOGa8j7rEvtlzrEFks29hi9EKbtrqtpQd3HhpVEApDkFaskbF2E4XLv3MZg==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=0ZYoBm6m95gAmdsMQxvE6yda/f+Z1taeLiM3vHdA1p4=;
 b=UkbDu7DgCOLKpPKP8j+XVV/7jO/2BUQdo93UaClMsRMCJhz4zj5g6eg+VaMB5Hr2bnBvyJKAQMYaVgfGLAPfVqn3OqlilbrlOjyP34vZb3aL6w2/BgflizuzD9JV2Twiq3gMB849zIwD2d4hTaM2m/g8BmqvTyqt0VoG5RBIuN0=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 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
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 950a2b0261ecd124
X-TessianGatewayMetadata: ++6dKMBsRQjNOYKcPbfgSpld3IDgg9Uhp7f7NN66kz0lNzyFudxN4uDU4HYVExjVWreOnOj6pR5RH1uXGXwfYO69KN32DGg2Tc80kV6H6UnKooVm2tsKIcSYzhn7VQa9m03TkvLAz/NgUUZxA5XIwtf1k/uBY4nFcRZe0LfEjIs=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=lSxBPD1jzK50XNtl1MG9Pno6blsY7bq0vB3usVM0Vog5cfmWTrq3oXlpTdW9GAecbrKIGKBJBVIh7PUyHakCPlZ65eRpmVVeF7Ha93BfrxwZLlonvMCZg/vsn0c4MRgcy6l8Tferv3CXVrXOYwE0t80KVLX6+WSNucKJG6WOfyOJ4qIZwm772Gpqzlc1Vzn+njv5Pqqm4gfSlheeaIHO1dAwTCL5oLnT+UAsDE/prAT3eTibzVGGmvZ6jT2i+9mJnv2AP8VcV1dshr40RQ4cn42/igGBAW23OnGUR6F7W4IX3/DpKnVpWBkavlg4WAk8Mcl87bLIDfdW6Fi6g3tuUw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=0ZYoBm6m95gAmdsMQxvE6yda/f+Z1taeLiM3vHdA1p4=;
 b=ZDkjGq6n2e33teBn+C2VIqZ23pKNUrfUXPzw6dxVp9TZ0C8vt2kmto20EH3KKJ3NKhgmLH273YhdBeuSkd9P7INUvv7aWZ9f7VYx9V+vOODTNpaSmb4HqKb+XSoDMLTuKr6QO9lBqI+l9UNhKrEBeNMxDF1MlQ8OmJvrixZI0Bpvd9yVnJ/qAwvCtLX/L4fxGNzQC56eVPgiPP1a7vz3alK7MeSjKU22TO48FUEluJHRfvmhb0gpnYsdUb8udozX/1fx+uzrpC+5OLe5IhPC7jVY7PCL7/v1erbumVqw+9muzJtbcC4fvuO9d7v/vvBQQjZxihgbmtvID/97HhcAeg==
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=0ZYoBm6m95gAmdsMQxvE6yda/f+Z1taeLiM3vHdA1p4=;
 b=UkbDu7DgCOLKpPKP8j+XVV/7jO/2BUQdo93UaClMsRMCJhz4zj5g6eg+VaMB5Hr2bnBvyJKAQMYaVgfGLAPfVqn3OqlilbrlOjyP34vZb3aL6w2/BgflizuzD9JV2Twiq3gMB849zIwD2d4hTaM2m/g8BmqvTyqt0VoG5RBIuN0=
From: Bertrand Marquis 
To: Ayan Kumar Halder 
CC: Ayan Kumar Halder ,
	"xen-devel@lists.xenproject.org" , Michal
 Orzel , Stefano Stabellini ,
	Artem Mygaiev 
Subject: Re: [PATCH v2] docs: fusa: Add dom0less domain configuration
 requirements
Thread-Topic: [PATCH v2] docs: fusa: Add dom0less domain configuration
 requirements
Thread-Index: AQHbTMiRgWsw6YUipkyfuZOmy7e9xLLrs5oAgAA0fwCAABobAA==
Date: Wed, 18 Dec 2024 13:08:21 +0000
Message-ID: <983EB0F5-8C88-4063-9C97-EC8BB89AA5B0@arm.com>
References: <20241212190325.2130129-1-ayan.kumar.halder@amd.com>
 <779AFC45-3F8C-4065-A39E-9325F9C72AAD@arm.com>
 <2cf952f4-69cf-4eea-aace-4b7bf291b9f3@amd.com>
In-Reply-To: <2cf952f4-69cf-4eea-aace-4b7bf291b9f3@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|DU4PR08MB10936:EE_|DU6PEPF00009524:EE_|GV2PR08MB9399:EE_
X-MS-Office365-Filtering-Correlation-Id: 164e0ba8-2cf7-435d-0675-08dd1f6510cf
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|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?XiK0xkUc7XHG7MU5EceWlvHtfLYCtdyiJb6crCYYtxO78BAz+ygwPW/hypdU?=
 =?us-ascii?Q?zp06pnEPgAm3YphZ248mUdetHGRkhUtGt4bRl4d8BodBlbfGnnj/0+2C2c63?=
 =?us-ascii?Q?GK7cAXowsiFyOKZ0ia5p1fUvjyg1qIHsH6jBHJYnU8IHGKjRM86qsrkBVCdY?=
 =?us-ascii?Q?MbnRZZBlFfZ0rbOVei+zNVE3Ujck4J1hwkzfpktMOnHxmZnUCWCrOgGTAjsB?=
 =?us-ascii?Q?+5hryO2CeST5qFigRX7iDx2o7CRSE04M1NvDU6AN6cDwieMRJy5CBYcPm2va?=
 =?us-ascii?Q?WFkoJhqzi9tGPKQJmmbW+iSBaQd1CKWetqVpixKKH2g/aYYZYUNzzoBgm/nX?=
 =?us-ascii?Q?fqmPB6pst4mReoMsQq4pYDHmRmjNdQvsgNYPANkMqL98cy+3S5fEZyAegh9Z?=
 =?us-ascii?Q?WbAwDr1ZJzeDENpCltO5FnfaFdHerUlhBwz15wlCoTH4TeWEslJW8XNuKnGl?=
 =?us-ascii?Q?yaDxwr1RNuathDflhzO3fan7ei65dhY7TGRvT4yvmHvjuJsUTO9K3Q1vVXLV?=
 =?us-ascii?Q?aUIwwEBSfg8Rt5E7TNxz86RZuV2dSjl+B2qfDPRrgpzovVR60KZSvw0szmqR?=
 =?us-ascii?Q?j2aRSxbLBtlsQLVuSNVnxOhaa1v9/Wrx+j2vEN8MHRisVpH8DMRfuLEYNK1d?=
 =?us-ascii?Q?3Wb6fh1zx8UKiucVLdhdvT3W4P4ex10kYNmohSKIi//VHKu+jsqv0hijVBmn?=
 =?us-ascii?Q?pCxLauVIAVV5uw3jDlE7BlH3Czlz0j3vJy3nc3O7GIi8bIiWPhk4JcZsPZxz?=
 =?us-ascii?Q?KjxXQT85OtxuAMvXIZeqdiLB7ep/D8vKts0CoZngC155w60ohH1ZDV/TFVW1?=
 =?us-ascii?Q?3FdQ4eTMeyQ/a1CRSeiBELM8OvUa5wZ75dbZRLRoTaQ3EBj37rGrBNM9AeP/?=
 =?us-ascii?Q?ctegsCE4xV4mGgykbaU8MNPg2KPLqI1czdbxLhjZLtTmzIDa12CEtKHfFaBs?=
 =?us-ascii?Q?1eqcrHrz+hQhc7w0qXWt+Gjf7OqFGNExbFDejaxIEyAoy0g8J1G6ahTjFe59?=
 =?us-ascii?Q?5U4GnGBamjPGjf0iBx2NyYa34j5J2j4wtpR0U7sjhHTpLGfsgcCXuUZoZssP?=
 =?us-ascii?Q?S3/ZhGLyaRg8QEtR6OCDyGg987fZCn5ZBOO4kwsyHxcgGq4/kaxeFQtMl/X+?=
 =?us-ascii?Q?DkBkohzkgN6cKZzB9pOxhXiZGtiTx5wE3fxwFiZLsPJsiWnZmBXHygMoxhWu?=
 =?us-ascii?Q?dPMZ3dXzfuFIJYa6mr6lhFAp7zZPqPNsNEXhfL+jBbcV+6DV4MVeDnayhkpN?=
 =?us-ascii?Q?GOkAF/SYB+rVyFRCj5IYkGJi1VA9wR3CRognaZNqv00ayAIRzuLPPeuLU9uQ?=
 =?us-ascii?Q?RfjpdzvYcfDCWB8IljcdKr2wM8uYwAcl7p5pBFXsCIpMQO7a/4yNfQArmCuL?=
 =?us-ascii?Q?5o1so0tnRWLIzm2x/uhs1e6jLlx/SRd40CmhHSiRyt96p/myBQ=3D=3D?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1DA6DE5CB84AD14780717E32F2E3B54D@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR08MB10936
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender:
 ip=[2603:10a6:10:25a::24];domain=DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU6PEPF00009524.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	e4a54ff2-e393-4626-f00b-08dd1f650c1a
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|35042699022|82310400026|14060799003|1800799024|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?3v2qXW+tTR/8r9dEwd0z730EgxlinkF4Jjz2vsCK0llWCmzlkr5QhQ+wnp8j?=
 =?us-ascii?Q?sRCpO61H1u7C8QRXno0RpyS2uu/8wdE8E6R7Q5RDGJcBUdMpsWBqRXjcLQ3d?=
 =?us-ascii?Q?/8DBoGQSc7MukvbHTRq02x44eioRYWxciKbhyrqHaEZYNVr3aXEorQ+nthij?=
 =?us-ascii?Q?eTZ0k5BWuKsw5YJn7QEaYTmETbWdvbr8chKYdAAdMPl9/IyVsi41yBoTdACM?=
 =?us-ascii?Q?QWWSury8+/FyqJZoKQnj/KtxeawYQk/9VXQ0hH+q8ih/mKsKOfQsRU//1dGK?=
 =?us-ascii?Q?ORPiFJbB0jnJAfy2gofopyUa+uY16fKhX/3q+6jRCExjwr9YA4mcuhk3ZIg1?=
 =?us-ascii?Q?SiZtiI7Y5ZoMXwCC5T8wADtRO9PZgAczbiRFXD97LnBMsssflT4OIhNDmPV6?=
 =?us-ascii?Q?eoiPg+6S4aatUhe4c4wIxY3jskRwnCtgjgLE3DhqkjWj4F+OrzP8w2/iSao9?=
 =?us-ascii?Q?FZkwVmhGBbZP/46AidD0BahrWNQPcv4/rJ79V3EsqOQwu3D5WYAxxoqbxxKc?=
 =?us-ascii?Q?BRQJGWseNzlcSaboztj40PNJfhwVyl26K21EzHL6YNImEQcgzJoN1mXKhrck?=
 =?us-ascii?Q?4Yn0Hw10Exwm0BFssljb0rI39as3eSpkHQLRz5lQrHzWWHJKB+qQBpfge+nQ?=
 =?us-ascii?Q?6VjRnbSKUkCJ/fj+1Z/Ex7+O3bjyCT8k3+cvVirgBItSr8hv3bQWQeGS1qpa?=
 =?us-ascii?Q?0rQVIffWhusv5W3xubx6fB45JCwtpkqypr/h0JlTjaFVi2IkTyocZ+hm7OnF?=
 =?us-ascii?Q?FKxZYfCdTkXGewBfoFQZmf8PJOmTrzxHi1+dt+lNF+iK0HrrFBFQSn35sDKc?=
 =?us-ascii?Q?6AfjBFKLtjIqhqV5LFYsa9pH/bEPoz7ubqNQ0ymLF/5z4HureYbnC+1WUGps?=
 =?us-ascii?Q?BzGUzbWdnvGjotr4ov/nhHg2+QbTl8owt/dxyX68Z7Hn3NLfk/v7y7jxJ02I?=
 =?us-ascii?Q?ghfgbe0lhDCJowP8fSAogJA2ofTFkV+gGLA3C4ben1+0ZRFGyomrjKUYX9/u?=
 =?us-ascii?Q?H9nkA/9YUreMhRvMePwyQ3q3uPtCw5Iy176lU3OIG1wpEkU3IGZ5TQW6Iyg8?=
 =?us-ascii?Q?6ewGZvBnxk1eNIH1cylgp/2399S7Yb8OAizca9g6lT0CQXw45bYDFzRNrtHe?=
 =?us-ascii?Q?g3mgVcBsij7HBkSSuMj39s8cmXCkmEK8lAohO8oj6WqO0R0kitS/rVLFZBXC?=
 =?us-ascii?Q?iZcj9eqF+6WpuV8q1aZkozJJBKxFCIb+GezWE7mXVHyTA8qMz2qienhyyG0z?=
 =?us-ascii?Q?6BNJ24KHtizxxls41t+1e74+0yXASYZci8B0JaVMcOEzz82g3Q9M9BhGq4V0?=
 =?us-ascii?Q?hk4mJYfYR8vivDncsWBbgBtQFS4p/C2tZi7GRTQ6K7wRFYvu/q0yDml1xzZD?=
 =?us-ascii?Q?TFUtmh09oFm3RHPiBKzAFHzthzMnjgAa8f13+o/H7N2ClRVtEGWw2Y8YFD4/?=
 =?us-ascii?Q?GZLD5vo9XY+p80y/DOH6llqkQ9g5yPjXN88/KHU+Q47I96Egt0X+eg=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(35042699022)(82310400026)(14060799003)(1800799024)(376014)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 13:08:29.0483
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 164e0ba8-2cf7-435d-0675-08dd1f6510cf
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DU6PEPF00009524.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR08MB9399

Hi Ayan,

> On 18 Dec 2024, at 12:34, Ayan Kumar Halder  wrote:
>=20
>=20
> On 18/12/2024 08:27, Bertrand Marquis wrote:
>> Hi Ayan,
> Hi Bertrand,
>>=20
>>> On 12 Dec 2024, at 20:03, Ayan Kumar Halder =
 wrote:
>>>=20
>>> From: Michal Orzel 
>>>=20
>>> Add requirements for dom0less domain creation.
>>>=20
>>> Signed-off-by: Michal Orzel 
>>> Signed-off-by: Ayan Kumar Halder 
>>> ---
>>> Changes from v1 :-
>>>=20
>>> 1. As the dom0less domain creation requirements specifies the dt proper=
ties
>>> for creating domains, it has been moved to product requirements. Produc=
t
>>> requirements define the interface Xen exposes to other domains.
>>>=20
>>> 2. For the requirements which introduces new terms (like grant table, e=
tc), I
>>> have provided the definition as part of the comments.
>>>=20
>>> 3. Introduced new market requirements to specify that Xen can assign io=
mem and
>>> irqs to domains.
>>>=20
>>> 4. The design requirements will be added later.
>>>=20
>>> docs/fusa/reqs/market-reqs/reqs.rst        |  16 ++
>>> docs/fusa/reqs/product-reqs/arm64/reqs.rst | 306 +++++++++++++++++++++
>>> 2 files changed, 322 insertions(+)
>>>=20
>>> diff --git a/docs/fusa/reqs/market-reqs/reqs.rst b/docs/fusa/reqs/marke=
t-reqs/reqs.rst
>>> index f456788d96..47e1b6ad61 100644
>>> --- a/docs/fusa/reqs/market-reqs/reqs.rst
>>> +++ b/docs/fusa/reqs/market-reqs/reqs.rst
>>> @@ -47,3 +47,19 @@ Comments:
>>>=20
>>> Needs:
>>>  - XenProd
>>> +
>>> +Static VM definition
>>> +--------------------
>>> +
>>> +`XenMkt~static_vm_definition~1`
>>> +
>>> +Description:
>>> +Xen shall support assigning peripherals to various domains.
>>> +
>>> +Rationale:
>>> +
>>> +Comments:
>>> +Peripheral implies an iomem (input output memory) and/or interrupts.
>>> +
>>> +Needs:
>>> + - XenProd
>>> diff --git a/docs/fusa/reqs/product-reqs/arm64/reqs.rst b/docs/fusa/req=
s/product-reqs/arm64/reqs.rst
>>> index db91c47a02..66f2978733 100644
>>> --- a/docs/fusa/reqs/product-reqs/arm64/reqs.rst
>>> +++ b/docs/fusa/reqs/product-reqs/arm64/reqs.rst
>>> @@ -40,3 +40,309 @@ Covers:
>>>=20
>>> Needs:
>>>  - XenSwdgn
>>> +
>>> +Linux kernel image
>>> +------------------
>>> +
>>> +`XenProd~linux_kernel_image~1`
>>> +
>>> +Description:
>>> +Xen shall create a domain with a Arm64 Linux kernel image [1].
>> This shall be rephrased to mention that it shall be a binary with a head=
er compliant with the Linux kernel image format.
>> We do not want to say that we can only boot Linux.
>>=20
>>> +
>>> +Rationale:
>>> +
>>> +Comments:
>>> +
>>> +Covers:
>>> + - `XenMkt~run_arm64_domains~1`
>>> +
>>> +Needs:
>>> + - XenSwdgn
>>> +
>>> +Gzip Linux kernel image
>>> +-----------------------
>>> +
>>> +`XenProd~linux_kernel_gzip_image~1`
>>> +
>>> +Description:
>>> +Xen shall create a domain with a Arm64 Gzip compressed Linux kernel im=
age.
>> Ditto.
>>=20
>>> +
>>> +Rationale:
>>> +
>>> +Comments:
>>> +
>>> +Covers:
>>> + - `XenMkt~run_arm64_domains~1`
>>> +
>>> +Needs:
>>> + - XenSwdgn
>>> +
>>> +Kernel with uImage header
>>> +-------------------------
>>> +
>>> +`XenProd~kernel_uimage~1`
>>> +
>>> +Description:
>>> +Xen shall create a domain with a kernel containing uImage header [2].
>> I would remove kernel and say binary executable and add compatible or so=
mething like that.
>>=20
>>> +
>>> +Rationale:
>>> +
>>> +Comments:
>>> +
>>> +Covers:
>>> + - `XenMkt~run_arm64_domains~1`
>>> +
>>> +Needs:
>>> + - XenSwdgn
>>> +
>>> +Gzip kernel with uImage header
>>> +------------------------------
>>> +
>>> +`XenSwdgn~arm64_gzip_kernel_uimage~1`
>>> +
>>> +Description:
>>> +Xen shall create a domain with a Gzip compressed kernel containing uIm=
age
>>> +header [2].
>> Same
> Agreed with all the above.
>>=20
>>> +
>>> +Rationale:
>>> +
>>> +Comments:
>>> +
>>> +Covers:
>>> + - `XenMkt~run_arm64_domains~1`
>>> +
>>> +Needs:
>>> + - XenSwdgn
>>> +
>>> +Kernel command line arguments
>>> +-----------------------------
>>> +
>>> +`XenSwdgn~kernel_cmd_line_args~1`
>>> +
>>> +Description:
>>> +Xen shall pass kernel command line arguments to a domain.
>> I am a bit wondering if this one and the following are not a bit to gene=
ric.
>> Should we say through DT or ACPI header for example ?
> Yes, I can say through device tree. And then I can explain device tree in=
 the comments.

Ack

>>=20
>>> +
>>> +Rationale:
>>> +
>>> +Comments:
>>> +
>>> +Covers:
>>> + - `XenMkt~run_arm64_domains~1`
>>> +
>>> +Needs:
>>> + - XenSwdgn
>>> +
>>> +Ramdisk
>>> +-------
>>> +
>>> +`XenSwdgn~ramdisk~1`
>>> +
>>> +Description:
>>> +Xen shall provide initial ramdisk to a domain.
>> This should be mentioning that it is provided in memory and the address =
is provided through DT.
> Ack.
>>=20
>>> +
>>> +Rationale:
>>> +
>>> +Comments:
>>> +
>>> +Covers:
>>> + - `XenMkt~run_arm64_domains~1`
>>> +
>>> +Needs:
>>> + - XenSwdgn
>>> +
>>> +Memory
>>> +------
>>> +
>>> +`XenSwdgn~memory~1`
>>> +
>>> +Description:
>>> +Xen shall create a domain with specified amount of memory.
>> I am missing the where this is specified here ? i guess this is also DT
> Yes, this is also DT.
>>=20
>>> +
>>> +Rationale:
>>> +
>>> +Comments:
>>> +
>>> +Covers:
>>> + - `XenMkt~run_arm64_domains~1`
>>> +
>>> +Needs:
>>> + - XenSwdgn
>>> +
>>> +vCPUs
>>> +-----
>>> +
>>> +`XenSwdgn~vcpus~1`
>>> +
>>> +Description:
>>> +Xen shall create a domain with a number of virtual CPUs.
>> number here is unprecise
> Can I say with one or more number of virtual CPUS ? How would you want me=
 to define.

I start to wonder if we should create interface requirements from the guest=
 PoV:

A domain shall have a configurable number of vCPUs (1 to XX).

What do you think ?

>>=20
>>> +
>>> +Rationale:
>>> +
>>> +Comments:
>>> +
>>> +Covers:
>>> + - `XenMkt~run_arm64_domains~1`
>>> +
>>> +Needs:
>>> + - XenSwdgn
>>> +
>>> +Credit2 CPU pool scheduler
>>> +--------------------------
>>> +
>>> +`XenSwdgn~credit2_cpu_pool_scheduler~1`
>>> +
>>> +Description:
>>> +Xen shall assign a Credit2 CPU pool scheduler [3] to a domain.
>> What is Credit2 ? this needs to be defined somewhere
> I have provided a link to the credit2 documentation.
>=20
> https://xenbits.xenproject.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3Ddocs/feat=
ures/sched_credit2.pandoc
>=20
> Do I still need to define it as
> "Credit2 is a scheduling mechanism where more than one virtual cpus share=
s a physical cpus based on a time sharing mechanism."
>=20
> or should the requirement be rephrased as
>=20
> "Xen shall have a scheduler where a physical cpu can be shared between mo=
re than one virtual cpu".

Yes i think this rephrasing is right.

And we also need a market one saying that Xen shall provide multiple schedu=
lers (With the details of which and how at product level).

>=20
>> and in fact it
>> shall have product level requirements.
> Do you mean this needs to be a product requirement ?

Yes, this is visible to users, the design should say how the time share is =
done.

>>=20
>>> +
>>> +Rationale:
>>> +
>>> +Comments:
>>> +
>>> +Covers:
>>> + - `XenMkt~run_arm64_domains~1`
>>> +
>>> +Needs:
>>> + - XenSwdgn
>>> +
>>> +NUL CPU pool scheduler
>>> +----------------------
>>> +
>>> +`XenSwdgn~nul_cpu_pool_scheduler~1`
>>> +
>>> +Description:
>>> +Xen shall assign a NUL CPU pool scheduler to a domain.
>> Same
>>=20
>>> +
>>> +Rationale:
>>> +
>>> +Comments:
>>> +A NUL CPU pool scheduler maps a virtual cpu to a unique physical cpu.
>> This is a product requirement saying that Xen shall have a scheduler wit=
h such characteristics
>> and I think this is not enough to define it.
> I don't understand this bit. Do you mean this should be product requireme=
nt written as "Xen shall have a scheduler where a virtual cpu is always ass=
igned to a unique physical cpu".

Yes this is what i mean but be careful as this is not really what the NULL =
scheduler is doing.
What you mean is "pinning" here and the NULL scheduler is only about "what =
runs run as long as it is using the CPU".

>>=20
>>> +
>>> +Covers:
>>> + - `XenMkt~run_arm64_domains~1`
>>> +
>>> +Needs:
>>> + - XenSwdgn
>>> +
>>> +SPIs
>>> +----
>>> +
>>> +`XenSwdgn~spis~1`
>>> +
>>> +Description:
>>> +Xen shall allocate a specified number of shared peripheral interrupts =
for a
>>> +domain.
>> This is very ambiguous. What do you mean here ?
> Xen shall provide a way to specify the number of shared peripheral interr=
upts for a domain via the device tree .

I am lost in how you achieve such a thing in the configuration.
All you can do is assigned an interrupt to a domain, but the sharing part I=
 do not see what Xen has to do with it.

>>=20
>>> +
>>> +Rationale:
>>> +
>>> +Comments:
>>> +A shared peripheral interrupt is an interrupt generated by a periphera=
l that is
>>> +accessible across all the cpu cores.
>>> +
>>> +Covers:
>>> + - `XenMkt~run_arm64_domains~1`
>>> + - `XenMkt~static_vm_definition~1`
>>> +
>>> +Needs:
>>> + - XenSwdgn
>>> +
>>> +Grant table frames
>>> +------------------
>>> +
>>> +`XenSwdgn~grant_table_frames~1`
>>> +
>>> +Description:
>>> +Xen shall create a domain with a specified number of grant table frame=
s.
>> It is really weird to say that Xen shall create something specific witho=
ut this being
>> linked to an higher level definition of the goal.
>=20
> ok, I will drop this and the following requirement for now.
>=20
> When we have market requirement to specify that "Xen shall allow sharing =
of buffer with a domain", then we can add this and the following requiremen=
t.

ack

Bertrand

>=20
>>=20
>>> +
>>> +Rationale:
>>> +
>>> +Comments:
>>> +Grant tables are a mechanism for sharing and transferring frames (memo=
ry buffers)
>>> +between domains.
>>> +
>>> +Covers:
>>> + - `XenMkt~run_arm64_domains~1`
>>> +
>>> +Needs:
>>> + - XenSwdgn
>>> +
>>> +Grant maptrack frames
>>> +---------------------
>>> +
>>> +`XenSwdgn~grant_maptrack_frames~1`
>>> +
>>> +Description:
>>> +Xen shall create a domain with a specified number of grant maptrack fr=
ames.
>> Why is this needed ? what is the high level req for this ?
>>=20
>>> +
>>> +Rationale:
>>> +
>>> +Comments:
>>> +Maptrack frame is the metadata for tracking the memory mapped into a d=
omain.
>>> +
>>> +Covers:
>>> + - `XenMkt~run_arm64_domains~1`
>>> +
>>> +Needs:
>>> + - XenSwdgn
>>> +
>>> +Virtual PL011
>>> +-------------
>>> +
>>> +`XenProd~virtual_pl011~1`
>>> +
>>> +Description:
>>> +Xen shall provide an "Arm PL011 UART" compliant device to the domains.
>>> +
>>> +Rationale:
>>> +
>>> +Comments:
>>> +
>>> +Covers:
>>> + - `XenMkt~run_arm64_domains~1`
>>> + - `XenMkt~provide_console_domains~1`
>>> +
>>> +Needs:
>>> + - XenSwdgn
>>> +
>>> +Assign iomem
>>> +------------
>>> +
>>> +`XenProd~assign_iomem~1`
>>> +
>>> +Description:
>>> +Xen shall support assigning iomem to a domain.
>>> +
>>> +Rationale:
>>> +
>>> +Comments:
>>> +
>>> +Rationale:
>>> +
>>> +Covers:
>>> + - `XenMkt~static_vm_definition~1`
>>> +
>>> +Needs:
>>> + - XenSwdgn
>>> +
>>> +Forward interrupts
>>> +------------------
>>> +
>>> +`XenProd~forward_irqs~1`
>>> +
>>> +Description:
>>> +Xen shall support forwarding interrupts to a domain.
>>> +
>>> +Rationale:
>>> +
>>> +Comments:
>>> +
>>> +Rationale:
>>> +
>>> +Covers:
>>> + - `XenMkt~static_vm_definition~1`
>>> +
>>> +Needs:
>>> + - XenSwdgn
>>> +
>>> +| [1] https://github.com/torvalds/linux/blob/master/Documentation/arch=
/arm64/booting.rst
>>> +| [2] https://source.denx.de/u-boot/u-boot/-/blob/master/include/image=
.h#L315
>>> +| [3] https://xenbits.xenproject.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3D=
docs/features/sched_credit2.pandoc
>>> --=20
>>> 2.25.1
>>>=20
> - Ayan




From xen-devel-bounces@lists.xenproject.org Wed Dec 18 13:57:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 13:57:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860403.1272417 (Exim 4.92)
	(envelope-from )
	id 1tNuXl-0004SH-F7; Wed, 18 Dec 2024 13:56:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860403.1272417; Wed, 18 Dec 2024 13:56:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNuXl-0004SA-CO; Wed, 18 Dec 2024 13:56:53 +0000
Received: by outflank-mailman (input) for mailman id 860403;
 Wed, 18 Dec 2024 13:56: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 1tNuXk-0004S2-AL
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 13:56:52 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2060e.outbound.protection.outlook.com
 [2a01:111:f403:2009::60e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ecfca7c7-bd47-11ef-a0d7-8be0dac302b0;
 Wed, 18 Dec 2024 14:56:50 +0100 (CET)
Received: from BY1P220CA0018.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:5c3::8)
 by PH7PR12MB9175.namprd12.prod.outlook.com (2603:10b6:510:2e6::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Wed, 18 Dec
 2024 13:56:45 +0000
Received: from CY4PEPF0000E9D2.namprd03.prod.outlook.com
 (2603:10b6:a03:5c3:cafe::2f) by BY1P220CA0018.outlook.office365.com
 (2603:10b6:a03:5c3::8) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.24 via Frontend Transport; Wed,
 18 Dec 2024 13:56:45 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CY4PEPF0000E9D2.mail.protection.outlook.com (10.167.241.137) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Wed, 18 Dec 2024 13:56:44 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 18 Dec
 2024 07:56:43 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) 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, 18 Dec
 2024 07:56:43 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 18 Dec 2024 07:56:42 -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: ecfca7c7-bd47-11ef-a0d7-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iwWRNRBR10RGcjdKRk7MYL/Xh1Fk7DaeVdmJR1zh48f6LrvyQ9nois8Ejqd8Ing6yNbhURepWf/gICMkyapn2zcHPFrW+FOHZvOh/g8IclIhnY9u3ORV/OhwYRJMczLhVcY2gaXCY6AUt6Eo9KPtDcPIJXlCesG32A+TPDSjEshvdOpN4hK+jgaOvJr+p+cEDGz+UB3MxKZk5iwDx3joCMe8YeiNmy+iQjLsFyW98Nrs6ftCH05vNGG3wxDWHmN7ldCcUHq1057Wh2pQGGywq1l9rhw3366/SkYC1Ppv0jhhAmnYifngzV6uBpsz8cLVKMEYCFWngdaIpIjIXiNzkQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=v9Yxhx83rPdoTe+LiUW2tJalCkNIJlDcFhun7dGoSic=;
 b=hUN6VVFzYwhhZIRSIazrjPaqdFajsFJ4s9n3rUyqjgrsAp3fbn4iT3YQ88YxgGx3TXRjuLBnZIY+TAxqt4Ic+IRJaLkejCBM6a+/YYO1PkHcaMzWFyotT+ZRz9lFRV6N6DKTh7h4HUd4LA28DXYRNgJToatQpRQegPmItaE2zqFUb2WljymGuXaCXqTDmAWHkTURNciRD1LHtg44ppSqJgJMTjHA1kl0hd0MxIcnTDCXTZ7Wv9Uw5VkN2qeenlRBsv7mvF8MkbNqx3RPXS9IWsmTodeakTUZ/YvxU7dNksnNz1RUKxwhGodMMS5jkVr888bXcVQwtCn7e89tKPWgOg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=v9Yxhx83rPdoTe+LiUW2tJalCkNIJlDcFhun7dGoSic=;
 b=WqkjrpByCE7mGHYjA5g920rswdNSo3ydbfJPDHe3+hQAxdQcgJ7R+Oxe+rMfSymRm5mFLasrsUG8pW2ixaK/jtD2KR46XFDama/2ijMRtUmgAKeiZXy5vkSF+LstqL5eZkbnbzYG5FTZO5geSik4zzVveHMMKl9HiWgzTBlUIag=
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=SATLEXMB03.amd.com; pr=C
Message-ID: <3984b69d-e15f-4863-8af9-53b6cc0f6bd1@amd.com>
Date: Wed, 18 Dec 2024 14:56:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] docs: fusa: Add dom0less domain configuration
 requirements
To: Bertrand Marquis , Ayan Kumar Halder
	
CC: Ayan Kumar Halder ,
	"xen-devel@lists.xenproject.org" , "Stefano
 Stabellini" , Artem Mygaiev 
References: <20241212190325.2130129-1-ayan.kumar.halder@amd.com>
 <779AFC45-3F8C-4065-A39E-9325F9C72AAD@arm.com>
 <2cf952f4-69cf-4eea-aace-4b7bf291b9f3@amd.com>
 <983EB0F5-8C88-4063-9C97-EC8BB89AA5B0@arm.com>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <983EB0F5-8C88-4063-9C97-EC8BB89AA5B0@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D2:EE_|PH7PR12MB9175:EE_
X-MS-Office365-Filtering-Correlation-Id: 44930722-6623-48f0-0ce8-08dd1f6bcedf
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?aDRqYW55TGJmRmt4VGFyWllFOXRVM0ZvazdaS1oxNExIZ2lOWjBzOTN1akYx?=
 =?utf-8?B?SWpSdzNMb0VSRFROSEFNejJIeWU4OVJ6a3k2NFM3Z2xFKzUvNG5TNjJLR3B0?=
 =?utf-8?B?cnU1YzJtR2s3VkxNK3lkbm5MMzFqZXdMeGJBQi9NNk15MGNrUTNuVThpQkRX?=
 =?utf-8?B?TlQyUHVqYXVoZ054dit1akl1aUF5TGpVeGQramxLQ3dha3E3dGIxYnNGd3JQ?=
 =?utf-8?B?NTJaaEZxYjNlSVZsdWlRN3p6V0RUbTRrSmRBNTFUUHlndFpjWXEvb0xGekc3?=
 =?utf-8?B?dnd4LytEU29NY1dtSTFCTFQxZDhZTDRqeklkbXZMdjY0TUxOWkxITEl0ZEgz?=
 =?utf-8?B?Q0MwdWwvbzFudjlDOXZBOUJvM0tHRXBSaTExclZsd1FzL2l6WXMxbCtXYmg1?=
 =?utf-8?B?NWFDbVBoVURwcUl6Y1RXTTdhbDVGY3FPZlQvSmFDUkxqQ0lFNnp1VWNTSFJx?=
 =?utf-8?B?cTA2Y21GMEhFMmdsdlREY2VHYUR4d2g1ektCeGJrMmVkNVQ0UFA5K3pkU1ox?=
 =?utf-8?B?KzlRa1Z1NXIrMUUzRnA0YTNBQnNqYXQ5WTIwTzE1NFNQUXdSTHRIeFEzVGpu?=
 =?utf-8?B?UVd3emVPUDhxb3BhUTFEdnd1R3lMWDM1SysvUnBEMUU5ZnNjRzFwOTZNMUFJ?=
 =?utf-8?B?eFBtQVVqb2xpQXFrRWZNR1phUnc5OHV0WEpkMnNEclRuQVV3cnUyNkRrYVlZ?=
 =?utf-8?B?am92b1E3ZnJqTnZ6MkdrcXQvOFErZSs4K3lUUnRMaStUM2dKeFpoY01WVXRG?=
 =?utf-8?B?R1laeDJhMzVheCtuQWNGc2E4alBJdUVNcXJoVjVXSjlHVlJnQmN3bHNwSE1P?=
 =?utf-8?B?OE1MQXFNMTNEaDBHb0dxNTZpa29MTFE4SVJvNmFEYjAxR2ZFZDFVMkJ4VnJQ?=
 =?utf-8?B?QWJZOXZxL1hKajdBNGpuYVlMYTR1bWNKUnRQVkdLTTk1SGxXVnltU3NZY1BQ?=
 =?utf-8?B?NjNQRVN4QU1OMGFCWXp0QzlIVW15QTF5V0I4Q3dYZC9nSlcyUUtiN0RRcURw?=
 =?utf-8?B?Vi9ZM2NzaUd6K21hUVg2b1pMaWIyQ3pyT2RlODFzdGJKdGs2UjdGam5iVzZx?=
 =?utf-8?B?M3NDMmJRVXV0Zk53d3MyYm9rV0hFY3dZTnZNTW5WcmxTdTMxL1hzNGk4bFBR?=
 =?utf-8?B?Tk1CbnRrY2gzWmZkdkNMTzVRdWQraFJEbHpITjVRRm55dmJ3Z0Q2MmQyaVZp?=
 =?utf-8?B?YzVwSzdGc1FuN3Q3bHFuNXdsZmwxclYveFpiTDlPNnZleXRXTmxadlowaEVS?=
 =?utf-8?B?QXZpSjFzWnVBK2lEcnVHZDBSbmRHWHNwcVZlU29KVjV3ZGVuVEtXT2w1eGMv?=
 =?utf-8?B?bkg4WU0wWnNBZHpIVUNWcENubTZENmlsZVBFci94N3gycWZPL1k2SHdyU1Yx?=
 =?utf-8?B?WXAyMitwTHJKNEZSTGZOUXEwWWpMcjhyK1BQeDc2Rm1XRVZCWUhMM0Z2ZnJX?=
 =?utf-8?B?R3pIc2xvT1VQdTNrVUhGR0RPYllGRm92aFdTTFFpbW8ydEdyYmlXSnZuMUVs?=
 =?utf-8?B?MEdnM1VSSEU2TlVZMnFTbFl2OVRKOGJuSXNCNjRhR0RNeC9VVlRQank4bTdT?=
 =?utf-8?B?WG9KY29CYlJpZEM4NHFaTGl1RkpPRzkxejFIVDBpVzk0eHh4WUJBSjhIRVo3?=
 =?utf-8?B?SmFmUS9Pcmt2VU1JM01URXl2Vk5BcGh5cVIwM2l6T0pnajArRlUzc2txS3pS?=
 =?utf-8?B?Y0lmSlRjUDlXVUc5VnFlb2tIQmUzbVB3RGQ5b3FobGY1ZVFRdVpLUjhFSlhS?=
 =?utf-8?B?UXdlakszQlZBM3psSjRSM1VnMlRGcGNqY05NaTFEOGIyd0FuL2xCKzFlR25D?=
 =?utf-8?B?NEs2cVMycHRjWFRhbFE2QUhPcEpRUktnWE81WnBJWmdWdThDS1JzU0ozVWpY?=
 =?utf-8?B?cEFmVFA5bVZTanhKYkRQejU3TUh1VTY2UmpPeFJOVGp6ajJ5Y2Vic1pYQlA5?=
 =?utf-8?Q?iJL/vVKyXvg=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 13:56:44.7445
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 44930722-6623-48f0-0ce8-08dd1f6bcedf
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000E9D2.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB9175



On 18/12/2024 14:08, Bertrand Marquis wrote:
> 
> 
> Hi Ayan,
> 
>> On 18 Dec 2024, at 12:34, Ayan Kumar Halder  wrote:
>>
>>
>> On 18/12/2024 08:27, Bertrand Marquis wrote:
>>> Hi Ayan,
>> Hi Bertrand,
>>>
>>>> On 12 Dec 2024, at 20:03, Ayan Kumar Halder  wrote:
>>>>
>>>> From: Michal Orzel 
>>>>
>>>> Add requirements for dom0less domain creation.
>>>>
>>>> Signed-off-by: Michal Orzel 
>>>> Signed-off-by: Ayan Kumar Halder 
>>>> ---
[...]

>>>> +SPIs
>>>> +----
>>>> +
>>>> +`XenSwdgn~spis~1`
>>>> +
>>>> +Description:
>>>> +Xen shall allocate a specified number of shared peripheral interrupts for a
>>>> +domain.
>>> This is very ambiguous. What do you mean here ?
>> Xen shall provide a way to specify the number of shared peripheral interrupts for a domain via the device tree .
> 
> I am lost in how you achieve such a thing in the configuration.
> All you can do is assigned an interrupt to a domain, but the sharing part I do not see what Xen has to do with it.
This req is about Arm's SPIs (Shared Peripheral Interrupts) and the max number you can allocate to a domU.
You can see more here:
https://xenbits.xenproject.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;hb=HEAD#l172

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 14:00:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 14:00:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860409.1272427 (Exim 4.92)
	(envelope-from )
	id 1tNubH-00060l-TM; Wed, 18 Dec 2024 14:00:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860409.1272427; Wed, 18 Dec 2024 14: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 1tNubH-00060e-QX; Wed, 18 Dec 2024 14:00:31 +0000
Received: by outflank-mailman (input) for mailman id 860409;
 Wed, 18 Dec 2024 14: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 1tNubF-0005yr-Vc
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 14:00:30 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20604.outbound.protection.outlook.com
 [2a01:111:f403:2613::604])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 701c2d1c-bd48-11ef-a0d7-8be0dac302b0;
 Wed, 18 Dec 2024 15:00:29 +0100 (CET)
Received: from DB8PR03CA0031.eurprd03.prod.outlook.com (2603:10a6:10:be::44)
 by DBBPR08MB6283.eurprd08.prod.outlook.com (2603:10a6:10:1f7::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Wed, 18 Dec
 2024 14:00:26 +0000
Received: from DB5PEPF00014B8E.eurprd02.prod.outlook.com
 (2603:10a6:10:be:cafe::a9) by DB8PR03CA0031.outlook.office365.com
 (2603:10a6:10:be::44) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.22 via Frontend Transport; Wed,
 18 Dec 2024 14:00:26 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DB5PEPF00014B8E.mail.protection.outlook.com (10.167.8.202) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.15
 via Frontend Transport; Wed, 18 Dec 2024 14:00:24 +0000
Received: ("Tessian outbound 7d3f896333d7:v528");
 Wed, 18 Dec 2024 14:00:24 +0000
Received: from Le180e8ee348b.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 00E8E6C4-DBD8-465F-9A88-8D15164004E1.1; 
 Wed, 18 Dec 2024 14:00:17 +0000
Received: from DB3PR0202CU003.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 Le180e8ee348b.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 18 Dec 2024 14:00:17 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by AS1PR08MB7425.eurprd08.prod.outlook.com (2603:10a6:20b:4c6::16)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Wed, 18 Dec
 2024 14:00:14 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 14:00: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: 701c2d1c-bd48-11ef-a0d7-8be0dac302b0
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=d8aOEvIbcuxFS0sQuNVA2Wr4jZ+5m0/K2Nv4Ag2pyrWhGt0JPuqbzrHxkAwRpfmv/AnbuGh3RfScoQMEFEFRJa17el07jnFK3XAQsqliC7SeTpxcyNBVJ05f8MVQSEwfBYzuDxVnmpP6R0ezMZH8tp2DsO8y4/NKvPoJGFETzdTYtdNIGx9pSIrSomPTEvWC2Tovmj1aN/sFJ/StidtyY2VOHYtg4N3Xim1QMYS5Vo88iCx0Me6+kUdSuKHKTa10EAhQvOYrPP9WXSGI9R23fIM81mZgc57jlqe9r7to42nEEcAHM2xzhsmQEH+3huJrodE778GwNH7f6XzjzPpC5A==
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=mrmE7urZm9N7Q3fQ0vEe2bGV6jf0rkMmhZje/sh0Ipg=;
 b=X+zjPZRWPEsPCSMP1tn0t62PZlTkGshBPkMEZYG1XHn89BDVLfHLHaXQKDyttRJbzmeP1fLjLB26gh+Wb8i8vfIG/TtCIpOtwQz8cx6o6yTS6apXPbQpH566jGR88M2ut/KfszhALI5pypv6kyrF4lL2xXRsRBS919Ut4SWHyAjVtavxruSjJ+tUsVAslRakXHlehakOCpTYKYOffYk1g0psbKGsuKT0oQJYRKW/rXQtBxZCZc18Q7tmyw7HKrwImXIQ5r04bRsvw2O+GcBNPpbk9zcwBA4HRZBOHWlL8/FeRaMhVCOcNzkFkHpqsKuRBsfTD2skYakiEUWnbaIpWQ==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=mrmE7urZm9N7Q3fQ0vEe2bGV6jf0rkMmhZje/sh0Ipg=;
 b=Wq53cG4Gyq1dhHfPzq/XNFAfAbOW5DAQl8Dvf0lj/KgsJJvA/ywWbjWUkCKgBHYcUpHVXFozisvCUJXc7VafSp6Mu8uKOK8Vsgtzt4D0YfJsRFkKNSjSq3KSsLDC1UK0CX9wDTG3jCWU+4POTuckTH/AMj2jktJcw8ZU/AyQsPE=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 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
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 11ebc8e030fb296b
X-TessianGatewayMetadata: ck9zwL1E+nYAp4BzpHLzXE2YQ2IRaAHGRC5wbSvJn5SEwS1YQd9nrTH6D8vz0WdhEcxABLMmZkgXFzI33jWd2lrZnnbN4rr9U4/ukcHhJyk0qeV4uk3P5Ysr0S+smQzxhIEAsdMwEsIGKtUMIlCYzPcwO3ZeZuGGWuyPuSDM+gA=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xSd9cXHMCDIqbeNc2RLiE5bnSLngSnwgDEQ7I/n185RgJsbg7CGvbk6IF6SDhl9Mp4panqEY0iGaaWByC+r4cSmPUJ3dLQbDrZsWfDvxfUUYC+ABkdTWGG/79OgC+qJIiKnk7oigWO+O6uQ83bEFb5keLBkDNBdv2w0cQA5WKfPLVIn2/SI59NGEbB5aaHaYXL3BBhoRsVFJ2XZup+8rQwZGuUdkrkPRSnzFJ9EUaPofRA/opquclD6b79r+gwnWsEZeG6TunGx2VPY6EVeIfzXAyd1n4Icfosmul319+IeNZZ74gDaFlkVzjZjlOQF7/qqoDCUlUpVlf8AjkgEkQg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=mrmE7urZm9N7Q3fQ0vEe2bGV6jf0rkMmhZje/sh0Ipg=;
 b=YMmw8cAGfRIIACLXLYnUWL7tz7loTEC6QlZ5VLvzMzZQrTykmwlM7RuI6W9IU5t7zO7Dz19DKmNvbE+jLNtQdLYQwoEZbmDZM2yQew2I67f1E6zxDTWxG0MJNWdpe4Ge+JzGW/AwakEUcjDHAg4y4HhrMiVpjQloG5CmdRMiLt8xsX9/K8iiEbdECJJcyOnM1i3pLG5ugkX0r18TYOj+cns/OR3S7SSkYcJiwrSDLzpRf0yHCV0XzPUkjr8zkAUP0kZSVE5xEZycnV5JJX6w1jSlR02etjscRhL2hKfXI3Gma0obEjD5/2pfd1L95cPHF5cRd4W5WHQn8QaFXlmvkA==
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=mrmE7urZm9N7Q3fQ0vEe2bGV6jf0rkMmhZje/sh0Ipg=;
 b=Wq53cG4Gyq1dhHfPzq/XNFAfAbOW5DAQl8Dvf0lj/KgsJJvA/ywWbjWUkCKgBHYcUpHVXFozisvCUJXc7VafSp6Mu8uKOK8Vsgtzt4D0YfJsRFkKNSjSq3KSsLDC1UK0CX9wDTG3jCWU+4POTuckTH/AMj2jktJcw8ZU/AyQsPE=
From: Bertrand Marquis 
To: Michal Orzel 
CC: Ayan Kumar Halder , Ayan Kumar Halder
	, "xen-devel@lists.xenproject.org"
	, Stefano Stabellini
	, Artem Mygaiev 
Subject: Re: [PATCH v2] docs: fusa: Add dom0less domain configuration
 requirements
Thread-Topic: [PATCH v2] docs: fusa: Add dom0less domain configuration
 requirements
Thread-Index: AQHbTMiRgWsw6YUipkyfuZOmy7e9xLLrs5oAgAA0fwCAABobAIAADYkAgAAA9IA=
Date: Wed, 18 Dec 2024 14:00:12 +0000
Message-ID: 
References: <20241212190325.2130129-1-ayan.kumar.halder@amd.com>
 <779AFC45-3F8C-4065-A39E-9325F9C72AAD@arm.com>
 <2cf952f4-69cf-4eea-aace-4b7bf291b9f3@amd.com>
 <983EB0F5-8C88-4063-9C97-EC8BB89AA5B0@arm.com>
 <3984b69d-e15f-4863-8af9-53b6cc0f6bd1@amd.com>
In-Reply-To: <3984b69d-e15f-4863-8af9-53b6cc0f6bd1@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|AS1PR08MB7425:EE_|DB5PEPF00014B8E:EE_|DBBPR08MB6283:EE_
X-MS-Office365-Filtering-Correlation-Id: c1fd1366-0af1-4444-97d9-08dd1f6c51b9
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|1800799024|366016|10070799003|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?AsUBJ70BQLZ76O5/jcvfsvuX/4lTcGv/hlkwYJw+FnWzICDjPaZ37HV2SsdR?=
 =?us-ascii?Q?A4SCvBUs3YA9GpMFpFG4WL8YKlXmZ7bbP8TQIZZg6fWd7jCdN7Ow9RIGV2ku?=
 =?us-ascii?Q?btPBQhrcOxOqe/S7AghiUgG/ZChjvryHVHF91hJjuNb9fuaK9Q+me4/xMNBo?=
 =?us-ascii?Q?mFJdu55K04tv203vTPIwWUPa+nqX/ibwqEMHaE19f57eOwwqd7xzADwTUmYv?=
 =?us-ascii?Q?BAkIN2wf1B1koi7QnqGW+IuvNP1zAWTqSCt8edfxU/EGbX8lu2JAn5mv0JHG?=
 =?us-ascii?Q?LLLSQwHPFKsNvLsGjlSgqR9iSeA3VEklbA4P9KPiNVyJaNQx0uMaFer8RgLL?=
 =?us-ascii?Q?6DK570LJVjYKNVkKOVSUYwZxDAUG5wHGG2+gyQc8cUNTQzpmQAvs3/rPoxr2?=
 =?us-ascii?Q?b4gYa2IoEivRW2mxtoYDX2FljAu4rWjmDRtEv553yVMU9HfUs1rM9c97FbwC?=
 =?us-ascii?Q?Bu0l2OgwT3B6nSCbXVWRnsx/vyGDVvpiVSCFEv40LKP4SBePK5WNX1NdvfFo?=
 =?us-ascii?Q?qrpoewCsFyKByAxNZv4wAiNkoEKWrrMprMTh6GAnaZnQTCJsQ50bhRPpDuf5?=
 =?us-ascii?Q?zwNyA3eaaiB7S0oujisyebzeA1pqgXVDgFlfjtqbbqhNoVc12rUpGhv6p0so?=
 =?us-ascii?Q?nqM20gtc+Jfi8CexUwnhW8j7OlomxM/IhJrKF1GWw4VuEa6bU3MgqGuGyxaa?=
 =?us-ascii?Q?0T9QGKGjzQ+Uskurh9wlzhXpPTdv6bdI14FwNO35O7CxALLQkVGO1YwuY+IJ?=
 =?us-ascii?Q?F5VpawhLjDmi9xKjuoWLStIcyE/dTJtcF/dUVpmKDaUBneoplKiHdqZD4zos?=
 =?us-ascii?Q?yEj+TsCfLVLGep0CFGYqTy5ZRBd257sRuR5a5U0/GdI9X8VOXfLAymUjpVdy?=
 =?us-ascii?Q?wxsMhG8wNg1YWFPXp4IziJqozyCCSZ3KAV5EcZbTa/xkoYQoaG/cUQENpSjj?=
 =?us-ascii?Q?o36p94u+WSkU6lgg1esx4iWE+6/O/+hvwqIU4sJpYrk+6GlcnGqYawKT5run?=
 =?us-ascii?Q?gRBvjdTE1LxDa2UB+2nkucDW/lPaE/54QSNWAAtozkvIw2xbl9VAH/MlauLe?=
 =?us-ascii?Q?Z1bvCJ/VLaQ2XeUnPRP8ZS0viW7D5zq4DL0R/PLpvmz14+hRSu/mDLhC74zM?=
 =?us-ascii?Q?PXJ4fx42xENakGPmQN5sKSXlltKgdUEGRuMsD9YvT1cLWCFtYoM1PiOGNNsv?=
 =?us-ascii?Q?JvBPGGg/oL9o3e64RPWz722+ZrRhaFRcmAjYXNZjdiU6yiyg1PnevBnsGRcK?=
 =?us-ascii?Q?xXAHw46/anhsoqNUEq2VfgGUnfbQ8j/AxogOmOlet3s76U9Q6WKHNzh5Cqe2?=
 =?us-ascii?Q?mIkyS69BxlWIh6PUpt7QhORYuvtM4MqD7ugAcDAd1YyCJW6VCIkJnteWw6bG?=
 =?us-ascii?Q?dqgrT6SvwpbtLju3z6XzJ7OO+9/L?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(10070799003)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3342A1AB162BED4EA50DB60238FAF054@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS1PR08MB7425
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender:
 ip=[2603:10a6:10:25a::24];domain=DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DB5PEPF00014B8E.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	de500277-d4b9-4267-6a51-08dd1f6c4aa7
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024|35042699022|14060799003;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?P5Rpf/Kz8384VDfLz5aKcJXLDcIq3DyqNfeu+nMd2D11Z3GoZt10+Ze0nzlg?=
 =?us-ascii?Q?bq8SK9q91a2Q9b+d+8K0fDVd1LHXeoXd1G+lnE/YDyXmDlPFWs/VTfMVnCVt?=
 =?us-ascii?Q?3AJZYsuCNP3ex/1HLcHz1tMI//skFcdtHQJATHaqfHRXRYYEYf1HAUOxkuIV?=
 =?us-ascii?Q?U1qsgbyrGOf6novQObjeY71HBowJltbZkaLblgje0VDCIfQYD5XKChmmibE1?=
 =?us-ascii?Q?uhYtb4MVodTXu4u4YWyiyxe/2QGvXm1CGH5F6ODIoTVsr2t+gqNnVTc0DDEG?=
 =?us-ascii?Q?zcW5d41Nf7xUbehYS8alaVnlU9ZteJTI97pW26G8zYOAhfhNucdaNiG8H77h?=
 =?us-ascii?Q?LbOqBHtzNDWtR2tNSsXC6ARGOaUsl0UxbkINfcjO0hyetkxvqZdkVB566WPZ?=
 =?us-ascii?Q?0H7hqBpXEzaotfOFKu36sw86oDWW+SSjdZ+zrhNj0ShgPZILtWiFaIwAJw52?=
 =?us-ascii?Q?B76O3R0oM931lNpsud98XIGmU82j2akgH7KbhpoDpb53IVliH3oxBjcdEZ/X?=
 =?us-ascii?Q?9OeDbmXtXnTs/yXq3xUzlwIAWTf0ASmuYV2NkHvSiqZv4E6imUgMqCdfJeFe?=
 =?us-ascii?Q?xjSreTkgaE4WtnJ58ZGvSNYmI7KdGRTYIKvby9vIEvFP3H3izI04MICKT3GX?=
 =?us-ascii?Q?IILEkBf7QTpFv/7N6LVEazRzvJUNHm2A2jQ7SSgylzuZs9Zo4mbL0ZI7Wz53?=
 =?us-ascii?Q?RFwaKaSRsqaogNHidI7J9Ns5tppXqPdT+OS+IpOYHpzHbVzMTfYYA1zdG61+?=
 =?us-ascii?Q?ngjRTNxk2MxeZn+g0BM3wqZUqHH3rhefxgrUHIyer8yRgYRig/4SpBY0Zeuv?=
 =?us-ascii?Q?W8c97r0/zXQn18NVtRuVQT1pvOzb9CXETcNiA6Bs4OyjUq0Oju4YsMi99oU3?=
 =?us-ascii?Q?Cg7yMi1en9mqMRG06NF6xcq7A/rPUT3AvA0xLtwIbESQHne4KjGmXMEnWK+N?=
 =?us-ascii?Q?rf8d3oqIiGsyZ4FFK43Nw3BKfOWP2jtm74QojlTaw1GtzAsJnDP/pBQuQiSo?=
 =?us-ascii?Q?Q5WnJEiZItclCh5IluDmsJMsdywqvxgQEMEp2tij2QCXH43JZMc05BF7r9TL?=
 =?us-ascii?Q?45lZLtGmyVkm6szklBpNC5ngVMTElegl2SNeS2qCfL5Lh4EKWxMFNWlaWxm2?=
 =?us-ascii?Q?+QM3dzF3NCa2CAXEHUYZNhVXU3S5ob72J263Ys/BRzYCtCp/S2yusKsP421p?=
 =?us-ascii?Q?iIDXXu1pVdO19eC/cRQRj8ruXG1FXrROoMuHcGVRURrfYs+2U7ts2Xaq2+M5?=
 =?us-ascii?Q?8vru32CYrkUGQ9Kfbu0YGs+AkUIZZ61CDuhWlfQ0yzFd+3MSzvmh+9g/rIET?=
 =?us-ascii?Q?xJbni4HswvCbRciCuf1jTukPNinSrQ1s2fwXAjUGUC+HTHPvDOITMLJd064W?=
 =?us-ascii?Q?+ytcnoJY0XMm/piVuEle9A9rkzhdJB7JUjocz1Hs/6Uzw8wUtxh80oyYEjiE?=
 =?us-ascii?Q?K6uVy8k4o71M7k7gqLwofaz4fNEn9k6G?=
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024)(35042699022)(14060799003);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 14:00:24.4368
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c1fd1366-0af1-4444-97d9-08dd1f6c51b9
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DB5PEPF00014B8E.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB6283

Hi Michal,

> On 18 Dec 2024, at 14:56, Michal Orzel  wrote:
>=20
>=20
>=20
> On 18/12/2024 14:08, Bertrand Marquis wrote:
>>=20
>>=20
>> Hi Ayan,
>>=20
>>> On 18 Dec 2024, at 12:34, Ayan Kumar Halder  wrote:
>>>=20
>>>=20
>>> On 18/12/2024 08:27, Bertrand Marquis wrote:
>>>> Hi Ayan,
>>> Hi Bertrand,
>>>>=20
>>>>> On 12 Dec 2024, at 20:03, Ayan Kumar Halder  wrote:
>>>>>=20
>>>>> From: Michal Orzel 
>>>>>=20
>>>>> Add requirements for dom0less domain creation.
>>>>>=20
>>>>> Signed-off-by: Michal Orzel 
>>>>> Signed-off-by: Ayan Kumar Halder 
>>>>> ---
> [...]
>=20
>>>>> +SPIs
>>>>> +----
>>>>> +
>>>>> +`XenSwdgn~spis~1`
>>>>> +
>>>>> +Description:
>>>>> +Xen shall allocate a specified number of shared peripheral interrupt=
s for a
>>>>> +domain.
>>>> This is very ambiguous. What do you mean here ?
>>> Xen shall provide a way to specify the number of shared peripheral inte=
rrupts for a domain via the device tree .
>>=20
>> I am lost in how you achieve such a thing in the configuration.
>> All you can do is assigned an interrupt to a domain, but the sharing par=
t I do not see what Xen has to do with it.
> This req is about Arm's SPIs (Shared Peripheral Interrupts) and the max n=
umber you can allocate to a domU.
> You can see more here:
> https://xenbits.xenproject.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3Ddocs/misc=
/arm/device-tree/booting.txt;hb=3DHEAD#l172

Oh right, no idea how i came to shared interrupts instead of Arm SPIs.

Then this is Arm specific and we need to have a bit more context/clear up h=
ere (as comment or introduction).
And also this should have arm64 somewhere.

Bertrand

>=20
> ~Michal




From xen-devel-bounces@lists.xenproject.org Wed Dec 18 14:09:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 14:09:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860421.1272437 (Exim 4.92)
	(envelope-from )
	id 1tNuk2-0006pE-PG; Wed, 18 Dec 2024 14:09:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860421.1272437; Wed, 18 Dec 2024 14:09:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNuk2-0006p7-Ls; Wed, 18 Dec 2024 14:09:34 +0000
Received: by outflank-mailman (input) for mailman id 860421;
 Wed, 18 Dec 2024 14:09: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 1tNuk1-0006p1-9l
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 14:09:33 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2061f.outbound.protection.outlook.com
 [2a01:111:f403:2413::61f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b1d91847-bd49-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 15:09:30 +0100 (CET)
Received: from PH8PR12MB7326.namprd12.prod.outlook.com (2603:10b6:510:216::7)
 by PH7PR12MB6906.namprd12.prod.outlook.com (2603:10b6:510:1b8::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.12; Wed, 18 Dec
 2024 14:09:26 +0000
Received: from PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264]) by PH8PR12MB7326.namprd12.prod.outlook.com
 ([fe80::6d76:9c33:d230:8264%6]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 14:09: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: b1d91847-bd49-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ny1MiLY3iPyHXqux/cQt8iRztfrdWXrOp6g12iQ7nGqR0/QkjxO34ufyJHNAZM/jAVhQfEcyYTcSNRMIXe4HOzelJ57aDYKXu5D+t7BluhdsQwt3Vsuh0HzCdAr58jiPaxZtWNS/0BXEQUq0N+TFGRFnyVcZFByB5zdexDSGvFanyQzAioXZmBbMbljWldem/Ph4ft6qCKwsFlsoPoLa+QB9TyANK2chY9eRWTQudy10hOZufyR6XYW2xp6gX+Re8EhbuUHEz/WVMcyJEYbYQn71iHlauZYEGGQS1SMlaAnVcPa1aAeN1BKpYPg5xFzIWigQpIRBW44+6YBsM4782g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=kKNc5NkdTPQqWW7vUw2NbgVJoYbq4pEsTWQNDHUwrZM=;
 b=MWAmbIEXBncIqnk8bGJxC9OXBu2hSnfqptN9yBX2+nFaB6rXp+W4j78hpkL907ZZ6S9zEwyyas3FBmGYYpuFrYpMjtuQ7Pgs9DHff6qgjEsQVw81NtrCOUx67wzT4nBUpfJXC5VX/NSW7aU2vOu1Oby3Mcg5lg1/E94FVHdcYBz5naIaxyTAIxADb0VN3WgQ3o7VuU2cf48YVEM1R1CoVymgswy0dwk8BSXuBTbJ+bz2T+jP5ShKW12M0pIEcd6h+NH77vVui6onkl280XNm4fOBpvz58i9RNUa6j/II0+ZQ4FMMAronzv1V4+ANmzLGgqRkKbN4PmLoYFlw192Ffw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=kKNc5NkdTPQqWW7vUw2NbgVJoYbq4pEsTWQNDHUwrZM=;
 b=3DbHnSJ6lCoeXblwt3rXCbaTdYurVc6VCB1Bjhg5EMl9KilhVWflkQ6tZxuNkDBKUZu8uwJ6CeMEWsM4d4Ppd0qWuNRTH5SZj6voccBhQF06Tg08wWYsc6fmkpoGaTRiOTOww6esv9WIVsd7y9nncRRpd4+J+mhyKMBRbIVjQ2A=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <702f8ee6-e53d-4bde-b773-745a2aa5b4b4@amd.com>
Date: Wed, 18 Dec 2024 14:09:21 +0000
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] docs: fusa: Add dom0less domain configuration
 requirements
Content-Language: en-GB
To: Bertrand Marquis ,
 Michal Orzel 
Cc: Ayan Kumar Halder ,
 "xen-devel@lists.xenproject.org" ,
 Stefano Stabellini ,
 Artem Mygaiev 
References: <20241212190325.2130129-1-ayan.kumar.halder@amd.com>
 <779AFC45-3F8C-4065-A39E-9325F9C72AAD@arm.com>
 <2cf952f4-69cf-4eea-aace-4b7bf291b9f3@amd.com>
 <983EB0F5-8C88-4063-9C97-EC8BB89AA5B0@arm.com>
 <3984b69d-e15f-4863-8af9-53b6cc0f6bd1@amd.com>
 
From: Ayan Kumar Halder 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: PAZP264CA0159.FRAP264.PROD.OUTLOOK.COM
 (2603:10a6:102:1f9::23) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PH8PR12MB7326:EE_|PH7PR12MB6906:EE_
X-MS-Office365-Filtering-Correlation-Id: 8cb9f7ba-fd5e-4742-b785-08dd1f6d944e
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:
	=?utf-8?B?SFQxRE9RTnhPSWg0cWpXMGVtb2JaWGd3bGkyMnVtWExUR29GQlp0V3J1SU9n?=
 =?utf-8?B?eVEwNmxZdWxxTnlKSGNTWmdYMzI4Vm9qYkh2NVZ2SG1NempKSTZKZ2RFMDZh?=
 =?utf-8?B?dkRvSDZKcHhPYUh3T2Y4VVlRbFdoV2tPZ3lqYnJBOFlKQ2xhMVpJaVJ2QzFT?=
 =?utf-8?B?eVdsZzRVNndZN2lvdStaQVh2Z1ZhMGhVOXl5NUxtUGZpRTU0N2NESG1Nb2JO?=
 =?utf-8?B?ZGZkY2ttVEdVR2hnanRBdnNEYnFOM3QxNjd0RjUzYTJQOU91bVYybDVjMzlF?=
 =?utf-8?B?Zi9Zd0tGNkNEcW9PaDdCK2sxSW5OU3kvbitLY3E1M1BNNVhFaUxVb1VOOE9h?=
 =?utf-8?B?NWtYR1MwRUJTWmhpa0ZsSnBPWURHMC9wQnFFUU93T21BZmRSL3RyMHpIeVY5?=
 =?utf-8?B?SXBxRWM4elkwYjEvYTlFR1l0UDVJcGtFR3pMcnlXdWIrRmlFM2piSURONmU1?=
 =?utf-8?B?ak9BS1cvRFFjMlNBMG9xYy9xbG1VMWVIdHEzY3FzZGFZQVMrWHFOZnROWmYr?=
 =?utf-8?B?dmkxLzhIQ2lCL2NMeFRIeWtHZW4zdE5aSUNuTkpsdmRSVG1FVEVNWnl3K1RR?=
 =?utf-8?B?TURhcnhBK1lpeDQvQkQvNDV6RUNOODZDWWJrNkpLT2UzcGlKdXBEUVkwMWM3?=
 =?utf-8?B?dVdiRUxoTGgwMTRxb2xaWTJZakM5S1grZ3JILzlOR1FHWUtUZk4rdFJJTmZj?=
 =?utf-8?B?M05HYk1UQXhUMFhncGFCNVNNWDdIWXFGeXM0SEJhSjQraXhDdkh0TVJudjF6?=
 =?utf-8?B?VHRpaWRzcXNQK293MThzREIrekcwZ3N1b2tTZHJDMFd4WjVMcHB5U1hoM2hL?=
 =?utf-8?B?ZmZ1ZW9ZYThpejV4WjVNVFN5NU42V1Z0WTNwV2ttMW02emg1dDk3RmtyMDRM?=
 =?utf-8?B?R3B1Yis4c0lqSUFDeVlWTStkSFpKVHM1YTNNOTJHV0RuWXpXalU4ai9mTmdp?=
 =?utf-8?B?OEphM2VWN1Q0cEZpbEdpK0d4RUpOY0pXUlVPK3EvZ1kvYUkraUpoazBGQ3RS?=
 =?utf-8?B?a3ZZVVZWcVAwaS9qTzRMZFN1cWZHalErQXJJVUM0cnhCSm9iYTM4eGVWazdZ?=
 =?utf-8?B?TGlzeHhzaS9LeDc1L1A3Rmg0bzlZUTNRdHVOcEFWU3VEY1YwZHBzU0I1RXRJ?=
 =?utf-8?B?UURBdkg5TE1GWE14dGliSDFYZTc0RXYrSGtzeVJibkFabjlxVm1TTDE1UmlB?=
 =?utf-8?B?UFlOUnFVa1p5a21HVEk0TFZjVmFiT29DUHhkck1aRGNUQmFBR1J3NnBtb0hI?=
 =?utf-8?B?bmpPWHdEZUNKRWRQUGZxMUFxTTE1VXNMby9rN1R1eThlWCtVcGQ2YU5qMDBS?=
 =?utf-8?B?N25lVDBSbC9Da3pHYTJRNmpZRmZIOWViMTR2WUNzQ1p0NGZ2NEJqL3V3QzJG?=
 =?utf-8?B?b3ZkMUlGK2x1UDBDc2NuU0ZoelhyZHA3RzF0ekFuRU5RTmVlUzNZWFlzc1NK?=
 =?utf-8?B?NmVSaE5XdER2QU0wSytzcnY0Snh3amJrWkoyNFVsY3JHTlQvM3Blc2dSaXJk?=
 =?utf-8?B?M0tndHJILzNVYkt1NlNrNkVKbW1PYWFWTGJ1Q1I3cVFZczZoSkl6OExVaS8w?=
 =?utf-8?B?N1JXOE5yREl2dkRYQUxFWU43TjZLbEJqckRYZFNsNDhldzl6RGRsb3JIaGRu?=
 =?utf-8?B?N0ZLZG4zK2JZdjlOSUhlcU9Ea1M0NmJzSVBRaWVuWU41Vi8zU0VnMjg5bHBD?=
 =?utf-8?B?VmtUcmRFYTJIVDVjbGVBOFNTWXZWM0tXMldjTmU0dGJVVmxiNzhkNE1JUTdV?=
 =?utf-8?B?eHRYT29uZitPUW0vdkNLK0dhakZRR3ozMW1acndrMTBCZEJGTnNRUjU1bk1H?=
 =?utf-8?B?SkNBT3ZtVlRId29VZDFHZz09?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH8PR12MB7326.namprd12.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?NDAzdk9EY1pFWW9NUHVoY010aWdnZGtEbGZJUEprMzRURm56VDhpUjZKVGYv?=
 =?utf-8?B?ZHNMM1J0OFUzOS9xWEl5aWM3QzFzUzJUOGUxL09NemFYWmZLRTlaM2U2Q3BP?=
 =?utf-8?B?RzBra2Y2MlFMZkQ5RXQ2ZG1OS2VqOThBMFgyeCtPQTZreU10UkgxZjN3aHRX?=
 =?utf-8?B?a0xNMkNKTUlRWllnZUdNbDl6WVdWb2cwNVB4OVhhUnhKV0NsNENEVStXMUN6?=
 =?utf-8?B?NWZFcXorTXVVY01qOGxTckhHQVR5TkQwYUthZUhWWllEQWdIVU5oYW5yajRr?=
 =?utf-8?B?bTd1T0NkbmdtcWtvUER0SzNsWkRtQy94ZzRUNGtad2hVdEs4VWdJc3J3NVJm?=
 =?utf-8?B?OUY5L052SE13WEl3L0xrRTMzVmRaVlc5QytOSVNhc2h4NWhpMDRiUW1nYkVi?=
 =?utf-8?B?cHNBUmJGODVpYXpIemlYOWVheFFTTnJDU3lvN1pFN2gybURiQnpYelJidE5F?=
 =?utf-8?B?TUh1TW5kaE92c0NYSTdTMzlNVDF4c0JmTVRlbTRudEVqSmw1c09zMm5QWVVM?=
 =?utf-8?B?Y0lGc3lEa2VIbHpGQSs2R2cwS0ZxU1d2bmdGWWRKRGxRQjI4bHUyZzByUnhI?=
 =?utf-8?B?Q1FWazY0YWs0RGNqUTJvaTFlS3ZBaWt2bnhDaC9Pa0dMdURUenhWSnJuS3hU?=
 =?utf-8?B?NXkwcTU4UDdDcCtlTUU3NmFzcnpYcXNIbVAvMHcvQkNKSUFsUEt3ak1tdVVw?=
 =?utf-8?B?d1o5Wm5CU3hJSml1bWhNdUdPSmxBRGxKbVJyb2VJM1JkR0Z3QkpZLys4dUl1?=
 =?utf-8?B?OVgzaXJET3BGYStWSjYzY1JIcFNVRlA0Mm05T292WndKK3NleW1KUFpiNUJ6?=
 =?utf-8?B?WjNYMmZkM05SWSsxdkpPQjBQRFNqcnh4L2hiZmdYWkliWHVSeklnTUQ5dWtI?=
 =?utf-8?B?aXdXd1lkMG9acEQxaW1RMGpDdUNYYlArQlNwdnc4TTdYZForVVVRNE96RkR4?=
 =?utf-8?B?RFVQUVl6S0pVNjBPVDB0b2dDS0JpQUxNQ2tobnY4SytJTjBLRGlOSDJjUzlm?=
 =?utf-8?B?N1lIQkJubzI4dlo1ZjhRdzNpSnlhUlFCZVBZSUVmSWZLUFp5bzZCQlVUL2pw?=
 =?utf-8?B?R3JIOW9GV01abFdVYTlraXVDS3p1d1hMYjhzRFRkQ2NjZ3VwNW9IZzVpZGp1?=
 =?utf-8?B?UG9IWDVaZUZ6Mit2MW9MZUl1YmJqaVZEdEJDbVl6Vnd4M01zbFQ0Z293Z0tR?=
 =?utf-8?B?Z2VDQU5zQWtBa3BXQ2ZwL29iUDF3Nlp4RWlhcW1TdTBnQjlhNjFtVFA4MERK?=
 =?utf-8?B?bDM4SFl2NjB5TUVUTG43bGw1Y013bDVhZTBJa09qRDVHR1BFWW04b3FBN2pG?=
 =?utf-8?B?cXBIdVo3SktWR2psV3l1YWRFdTk3TzBJVW5UOUhqUFlkSkUzWitROGVTQmZF?=
 =?utf-8?B?ZW16MXJFTW4rbVIwalkxek5PU0hCSXBydkg4VXFGTklnd3ZOcWhVNzNTZ1cw?=
 =?utf-8?B?cjhCdlg4WHJwU3BhVUlhVzRwNVhRa1B1T2JIRWZZK1R3MHJuV0lseFZnaStN?=
 =?utf-8?B?VHJCS3BMenY5UTNFUGNnZy90NEh3ZUtGakJTSnFGMVA4cnczaDdjdGJuWExC?=
 =?utf-8?B?YjkrL1RmRmhXZnpLTDlvT29pYWY5OHRjcFYzbW9MTHpGems1dm1NS3JWYVRh?=
 =?utf-8?B?VVI2dGM0bHVFOGtMdnlDbkVsd3hNZ2d5MkZyWUM5bXBIc044aGd0ZFFQT0Yr?=
 =?utf-8?B?eU8wQXBtQ2RZazVwTExURVMybzZnbDVNYXYvRWQ2MzAvK2dWS2ZPQXJkMDB2?=
 =?utf-8?B?ank4aW4zN0dwUnllLzNlUXdidzRJU0Q2M1g4SmFkQ21qa0Q5NlMza2tzU1Fr?=
 =?utf-8?B?QnhKN1UrNTh6YXlmRFQwNG5RQml0clBqcTJNK0Rja3JSems1L3BzZ25hOVBt?=
 =?utf-8?B?Q2xuRDdBdENJdGl2akdZNHZyUEVzUGpRS1hwb2JQdGhiWVV4ZWhHZTVzR1Yv?=
 =?utf-8?B?N21WVEdDT0YyalpQZExvY1ZuOU1wTkhTbjdnOHU5U2pMZVRxMjkyTVZyOTFt?=
 =?utf-8?B?cDdLV01CQVV1M1JLK2tXai80YnQ2NHJDdGVmaHMrRmxJaXoycDRla1EvbmxB?=
 =?utf-8?B?ODRzYUYxd1RnR3dTNFN4UE9BTHVGTTNMdUYyQnZGYnVaWUM5aVpXMDBiUGEy?=
 =?utf-8?Q?GJ9VU0fjKxeyZf2bub9jsc5j3?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8cb9f7ba-fd5e-4742-b785-08dd1f6d944e
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 14:09:25.9101
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: QC5NOfEFyO6Bu5CLmQTV/5QHaHOl+OpqWEHdStrdpCBMlmyVESd9uyJvr7snfkSPQ2n81V1AdUHnG/cYHE9HoA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6906

Hi Bertrand/Michal,

On 18/12/2024 14:00, Bertrand Marquis wrote:
> Hi Michal,
>
>> On 18 Dec 2024, at 14:56, Michal Orzel  wrote:
>>
>>
>>
>> On 18/12/2024 14:08, Bertrand Marquis wrote:
>>>
>>> Hi Ayan,
>>>
>>>> On 18 Dec 2024, at 12:34, Ayan Kumar Halder  wrote:
>>>>
>>>>
>>>> On 18/12/2024 08:27, Bertrand Marquis wrote:
>>>>> Hi Ayan,
>>>> Hi Bertrand,
>>>>>> On 12 Dec 2024, at 20:03, Ayan Kumar Halder  wrote:
>>>>>>
>>>>>> From: Michal Orzel 
>>>>>>
>>>>>> Add requirements for dom0less domain creation.
>>>>>>
>>>>>> Signed-off-by: Michal Orzel 
>>>>>> Signed-off-by: Ayan Kumar Halder 
>>>>>> ---
>> [...]
>>
>>>>>> +SPIs
>>>>>> +----
>>>>>> +
>>>>>> +`XenSwdgn~spis~1`
>>>>>> +
>>>>>> +Description:
>>>>>> +Xen shall allocate a specified number of shared peripheral interrupts for a
>>>>>> +domain.
>>>>> This is very ambiguous. What do you mean here ?
>>>> Xen shall provide a way to specify the number of shared peripheral interrupts for a domain via the device tree .
>>> I am lost in how you achieve such a thing in the configuration.
>>> All you can do is assigned an interrupt to a domain, but the sharing part I do not see what Xen has to do with it.
>> This req is about Arm's SPIs (Shared Peripheral Interrupts) and the max number you can allocate to a domU.
>> You can see more here:
>> https://xenbits.xenproject.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;hb=HEAD#l172
> Oh right, no idea how i came to shared interrupts instead of Arm SPIs.
>
> Then this is Arm specific and we need to have a bit more context/clear up here (as comment or introduction).
> And also this should have arm64 somewhere.

ok, I can add Arm specific bits in the comments. Also, will put arm64 in 
the tag.

Thinking again, this should be a product requirement as it explains the 
interface to Xen (in this case a dt property), Is this correct 
understanding ?

Also, to your other comment :-

>>I start to wonder if we should create interface requirements from the guest PoV:

>>A domain shall have a configurable number of vCPUs (1 to XX).

This should be a product requirement as well. Correct ?

- Ayan



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 14:12:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 14:12:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860432.1272446 (Exim 4.92)
	(envelope-from )
	id 1tNumu-00009j-Ak; Wed, 18 Dec 2024 14:12:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860432.1272446; Wed, 18 Dec 2024 14:12: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 1tNumu-00009b-84; Wed, 18 Dec 2024 14:12:32 +0000
Received: by outflank-mailman (input) for mailman id 860432;
 Wed, 18 Dec 2024 14:12: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 1tNums-00009V-VC
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 14:12:31 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20605.outbound.protection.outlook.com
 [2a01:111:f403:2613::605])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 1d017927-bd4a-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 15:12:28 +0100 (CET)
Received: from DB3PR08CA0005.eurprd08.prod.outlook.com (2603:10a6:8::18) by
 DB5PR08MB10236.eurprd08.prod.outlook.com (2603:10a6:10:4a5::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Wed, 18 Dec
 2024 14:12:24 +0000
Received: from DU2PEPF0001E9C0.eurprd03.prod.outlook.com
 (2603:10a6:8:0:cafe::da) by DB3PR08CA0005.outlook.office365.com
 (2603:10a6:8::18) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.21 via Frontend Transport; Wed,
 18 Dec 2024 14:12:23 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DU2PEPF0001E9C0.mail.protection.outlook.com (10.167.8.69) with
 Microsoft SMTP
 Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.15 via
 Frontend Transport; Wed, 18 Dec 2024 14:12:23 +0000
Received: ("Tessian outbound 867970499bdc:v528");
 Wed, 18 Dec 2024 14:12:22 +0000
Received: from Lb8c52f79d2b9.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 08639C5D-EDC3-42E5-97BF-AA704E4AAA81.1; 
 Wed, 18 Dec 2024 14:12:16 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 Lb8c52f79d2b9.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 18 Dec 2024 14:12:15 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by DB9PR08MB8723.eurprd08.prod.outlook.com (2603:10a6:10:3d1::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.12; Wed, 18 Dec
 2024 14:12:12 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 14:12: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: 1d017927-bd4a-11ef-99a3-01e77a169b0f
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=T32/thXX0YSL2eSz/azH104uVIKKTcp+mlPsSzSYShQ4UfHC7rJnhPzgwiMprGFZ8sP5wUm3jb0oiz/JUYaimM3zI1fx5xqdg97rROx5f+vjhpoR0SfYhyhb1JPw/iRO8Awptu8AdVy5gQw1oyzzbJcgob3r0iFSsg6aJjYvHg6fpZrAep6cp3xG9DuxJhn7Bmf4yRZ0s0YvHzdkRfDNpWD0jPfcW79z188eiI+G0Gjxwbsv9FkDcaKQSQ3/e+Gb7IsD1haKFJgk6cbbM43F4GJ57dVewLiKvUWdOx/+flTTpeehk/RNEsy35ge+V4QLDnxh7cjTqBNNf370Doso9g==
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=U0YhzDvwP5sZj5QdxOC9wK73scv72qM2xljUF+C9HE8=;
 b=wRWG6HeuINq+cv+3d10rzlkAk1+8XIFoCErBUlE37vexfZhPOZ0nXv3EiXOMcaL8omjwyM9/4vsFss88nqdt3nP0pRm5wmo2oxYNtE27lhsmAQSjlA901YiTz0ObU32liCR6p2T+GZt5GnHrSiT7tKbF1LHEfam4mzq00NFYiPdKdsnhiuRLeazIIYASfWZyERdvdUUoXgCMkh+1o5LJcHwukDr8gpIx7iBAzmJ42TS0I93g3E3oertRKIWr35NHqJGobJmTOHQ14XwQELlBaNlOGU/dbEyIakFtfn9ehWHTnazyZoONO/d6jPYuvSGzzyeYGF6kdQnaxX05nBO5dg==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=U0YhzDvwP5sZj5QdxOC9wK73scv72qM2xljUF+C9HE8=;
 b=jRE+jCVUVAIV61SJ93coNEWXCSA+MsahpZ5SB7Il2bmZxUj7NeKHkBc17usDXN+FqLa2p11+AgdOCHsAuyZIux4RBhjHRPbzP7yxerE1+XTAzxdwW7EsunyYT4F8Fp1K6MbdkXDj7/Dpxzs/jvgBIyIHao1m1OqJR4LR/Nv++Uo=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 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
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: f30b15428fe8d3ed
X-TessianGatewayMetadata: 0ucLMFV8xNgefFxUgbvh7cg8S6q/zDtfjjLtao2Imapkf8woK5tArkiAzmctfhyOz+5rfDjuu8oM/b0c3IS3L43GbmixFYuNjKF0oTCdHhlNrgw8AdrGsRdvnnDs/Gn/jlogwr0BCM+FVPOI9a2c9yHs7c3DhT12+nvpTQNQdzs=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=I44KEua44pj+sSRtf5SGVE3vUXpzkZOGxzs/qNqTvGTEGka5i0Fn8Lg8eKa1kYcaSUDe17XOW+4ZDwRpZjSo8BgtNR5v/EW1Wkk6giVc55WmOwPlxZyXuidnaL2h3WwWgh+F1HcFjjh2aO8yf0J9oflYnbszPhDhT87Gl9Bjn7dJnbMb1C9ROimCiv9gb2R7K7eTTp9lDkpCZx+tGbbqjndZONpQEawDi3ognWQ+FNPReuv7B8LrTu5ZH2mnsglWaCGjmEbeKdvrrcilyF4QjD1LWqedT1zY5ILc4OKHNeqZpxkQa4scPe+QP3Wkwm4VQ8s/szcO3z3TkKUQ9aCh9A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=U0YhzDvwP5sZj5QdxOC9wK73scv72qM2xljUF+C9HE8=;
 b=RmbhaAR5Nb/dA2CUmuWjU+6vF+6tcZAbqhuMDTU7Eeocu6uVHAKIn1ryFyjuvNDfw00T6lZ5V/BHGG+usMjdTK5AALQLW9IQPE/Tf6zNtMJ2YWgCEKUDpGB9+IAIzoHktEiqnAEAXBouwDVbzbff3J/h4zwgIc9pNevaJxWHB9+if/3hJaf56enKvbWnEMR5MrJQby8BU/o+46LsN75PMxRFGYkmT4TXbeXpJiPjtL97IfoEF2i6r9EqUZxoPflk8pRA5neD/V0Bomq2XYuyE4xbYJfOfsR2WG3q62yN5pFDG5XDVqj/PLcye7wDCqvkysSQ9oz8pS3cXlyrS19tAQ==
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=U0YhzDvwP5sZj5QdxOC9wK73scv72qM2xljUF+C9HE8=;
 b=jRE+jCVUVAIV61SJ93coNEWXCSA+MsahpZ5SB7Il2bmZxUj7NeKHkBc17usDXN+FqLa2p11+AgdOCHsAuyZIux4RBhjHRPbzP7yxerE1+XTAzxdwW7EsunyYT4F8Fp1K6MbdkXDj7/Dpxzs/jvgBIyIHao1m1OqJR4LR/Nv++Uo=
From: Bertrand Marquis 
To: Ayan Kumar Halder 
CC: Michal Orzel , Ayan Kumar Halder
	, "xen-devel@lists.xenproject.org"
	, Stefano Stabellini
	, Artem Mygaiev 
Subject: Re: [PATCH v2] docs: fusa: Add dom0less domain configuration
 requirements
Thread-Topic: [PATCH v2] docs: fusa: Add dom0less domain configuration
 requirements
Thread-Index:
 AQHbTMiRgWsw6YUipkyfuZOmy7e9xLLrs5oAgAA0fwCAABobAIAADYkAgAAA9ICAAAKcgIAAAL6A
Date: Wed, 18 Dec 2024 14:12:12 +0000
Message-ID: <72439F83-3602-499A-92B9-C5DD60B89AD0@arm.com>
References: <20241212190325.2130129-1-ayan.kumar.halder@amd.com>
 <779AFC45-3F8C-4065-A39E-9325F9C72AAD@arm.com>
 <2cf952f4-69cf-4eea-aace-4b7bf291b9f3@amd.com>
 <983EB0F5-8C88-4063-9C97-EC8BB89AA5B0@arm.com>
 <3984b69d-e15f-4863-8af9-53b6cc0f6bd1@amd.com>
 
 <702f8ee6-e53d-4bde-b773-745a2aa5b4b4@amd.com>
In-Reply-To: <702f8ee6-e53d-4bde-b773-745a2aa5b4b4@amd.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|DB9PR08MB8723:EE_|DU2PEPF0001E9C0:EE_|DB5PR08MB10236:EE_
X-MS-Office365-Filtering-Correlation-Id: 7d153100-ed05-4966-34cc-08dd1f6dfe08
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|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?rA2Ca2Pn8dZ2vLW/VgDuUZ1sWgh54QP1yiN/ma91DgISGGzHoYUar1O1rdqI?=
 =?us-ascii?Q?1jAaicf29THNjaijWiK7c9pRjqZTTAO7iAgZzz/EeRtpaGP+M/080CEpbJx3?=
 =?us-ascii?Q?PHb0HeSyG3MXvqI2JF48qF8+VTQ8NO85ejHCsWtXZsvMOUHOPrDV/sRaBE1j?=
 =?us-ascii?Q?etaRdKLpdXlv21mBcvKuZ9un4PnZciROPGb6QgdQQUcPRC8qoS+ZA/cAcSJq?=
 =?us-ascii?Q?FsISNS8tFNSCE5kcqeIvBV5X+SIrEG9NjYgWgT7/jtGXfa4UiiCWL0ASxXUn?=
 =?us-ascii?Q?GCKWLORmNjYiYJm6DSzFL1pEB2XkX5rfnewRj3ENhMECvdYQVeDDqNousKiH?=
 =?us-ascii?Q?NCDDIbpFgklKVpNxgQ+TrqTWlB7CqKEJ7h4PTd5zOPa2N71xk+kg4szDiJmw?=
 =?us-ascii?Q?kHdfBoQfyUahWhWEtyaQA/Y7FDguI3op+G3v7UcqzeCcyEPC+pQuQwzYANYv?=
 =?us-ascii?Q?xndfcK5ZpglO2NFX1Fht5YbQoAHqdP4YcR/k44cDs57369z4U4uO8PGuIMWA?=
 =?us-ascii?Q?V94j+VwMyBXCY7sIb59HOHKx3Q5eTyoDFb4le0U9K1CrGcICZ7C29SA5h6ku?=
 =?us-ascii?Q?jnvke6+uUDlRFSbaSFmtAWTyYBWqeT/xXiiXZZHhxszWq3q7alc0dk+5Hx1u?=
 =?us-ascii?Q?MpvjOL2ZzejJMZg4623CMqTs8QVLL1zxnbGIIEb+p/LJNS+os0SYdBeYK9ed?=
 =?us-ascii?Q?ta5M8d5EaE2xBVMwT+xDy7KkHz+OaayNA+x+yDVrwlGm+nY0jRbZjmf34OrY?=
 =?us-ascii?Q?4grrJSj1DYuHQjc1rTwj6aAEffQ4CS3Wd20n6TbCLcnEDDJlTv6Ikcn8qipN?=
 =?us-ascii?Q?TYPjZtjHT564Qx+GgoDnKLx6M5LRaoSRH+jXPRad8vfHBSuufchxWdbNT3fq?=
 =?us-ascii?Q?55K4U9nG5pS1bGTj4tpFGCOSx7wsbUN0kk0wtxq5uCfQhWITBzSr4DIF1pCP?=
 =?us-ascii?Q?NvwW0pnPie+Jj0hxYb0fIZj3yQ+GXZwaG5k9wEGJwWzG/MTZ6Bry9fiDPdw0?=
 =?us-ascii?Q?wGLqqzFyUGRAJOF9+6ebdD/DCcjABy2gNyz1XzI/QdiAv5qdyhlFWDaKe8uY?=
 =?us-ascii?Q?V/uV2nfEBKkMVEExKKsSRQ20U5W+wGtfR3VF2eztQizQxn3G7/BpRTNDJ1Ji?=
 =?us-ascii?Q?wjYK/HbCeRRB759wV8+B8ZHz7tORQ+EsDYLot1GGFjaPHxH6mkg3BNYwv+of?=
 =?us-ascii?Q?EgWNu/rdip+m0l/bddj1JD45mIhDGdjr9vLsADAFOtmrtbiDo05U+lAhKMN/?=
 =?us-ascii?Q?sfdi/ObKhy2aqytTmOpQxkLZ42AWxFmEOYZ3qymyhKyF9K/VY2F7lWkJ4ieO?=
 =?us-ascii?Q?DUgB+fz+7u7lpZ0w1IRP/qlg9PpwvbxfIoE6e27EYz5T85CBRkLufQcv/2Hd?=
 =?us-ascii?Q?2j9hSeEw+SgNDnHnnkkzYtoZAQNr?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(10070799003)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB8723
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender:
 ip=[2603:10a6:10:25a::24];domain=DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU2PEPF0001E9C0.eurprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	a1d459cf-d94a-46a9-7213-08dd1f6df79c
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|14060799003|376014|36860700013|82310400026|35042699022;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?ZWrdBhkDARp0omhGzZA+Kh7W8FCLm/au6r8KZ66IGn5IDcN7ReMOHDZfqW7/?=
 =?us-ascii?Q?m6eMvVg+slaCxZfHsi5CjgmGYzXMkXTKuFwqHbs7tUlBeZJKGWgoFD3Ob91D?=
 =?us-ascii?Q?5v3tGrdIZ98d03U7cbL8h+x9X8n3f/Z9yfg/oKXXD01d03rKJ/rOiF/GKiTe?=
 =?us-ascii?Q?WD22uxMYCaSlRCRo1oHAc5nnjN03gCA6gDisNXq27zts8DD5oZX2onsPvksF?=
 =?us-ascii?Q?fSGCtnqnjKbTLPQ91kJFjO98SDif3anI1kvlHBF101Bf98Y0A4ej6Z512uLD?=
 =?us-ascii?Q?5Sk7DaHSLLQ/1tTx0cvDAslFivlm82SMDDWoBDUOpiWrstoL6Ls2CVSsGI9M?=
 =?us-ascii?Q?n5MD6zUkXLr9aeoPmQXJQLFOGVP5TOAgze4mebhG5qXSnAjGwsoKeJCH2rQw?=
 =?us-ascii?Q?LZiZKqtapU7YeJP6qCirY2zkSKC7ZhzRhY2nw84mfpgcamodDKhEurMUXZm8?=
 =?us-ascii?Q?kGjx37MmdTB5MjXEtrxVNBwcMFJqx2ockqVzIbWl5TjT/++bWHu827Mw0iG9?=
 =?us-ascii?Q?RxVTaCGNTlmFIAei7G8X7KsPtLtqtoake+iDGNfkT95LjTUDvKuCU5imdkbn?=
 =?us-ascii?Q?zMjMsJRMvMYjU7H9zXdv6foOWG7zcvicZqSSSvSsiU96zCU5a6TGvP6aARpL?=
 =?us-ascii?Q?YthqXZoO89NfEWOH8x+VCsT4/A4T/hDyNpLdLq6CKtQhy+oQQFSDTw6RGXG+?=
 =?us-ascii?Q?7sMGLRU5yLUVnwD8fzQLyCuDKq6xC6+Tur/04SD/xingM7J6SLyvQ3bv6h2y?=
 =?us-ascii?Q?fTUKgpAKeMTXdA/rZceMDGlYLxcmEdKMppMnAZUfsCNALVlWG6NttPc+wJfy?=
 =?us-ascii?Q?mCNhx5IApRTuXABhBlBXj+ufrzcddEXhB+NoZK8gE+M6OVBAl1AkVyZfCo7V?=
 =?us-ascii?Q?nV+mp8fObS6VtsUlgZofTHPazS4sOIqAHrmcbPQGxLk9BaxcbgHijLO/Fzkb?=
 =?us-ascii?Q?UGHlv7yRJWIprNQymUmngkxEO36DjenOsIk3wGVdUgCwdfAnAY/EXEHf3Hn2?=
 =?us-ascii?Q?FDG77n9XXI0omP1gDX8+kiUz95ntRT/hxa4cS/bCjAZAcE1dOkyVFdNpx67t?=
 =?us-ascii?Q?j+Z+VaVESPs5ew/+mJV8Whm2qQ73yOzZ53LS400wLuQFrQCJCrPv+9XrNNys?=
 =?us-ascii?Q?4PHOQp/l0qJDrPJ+f1t0m6orfWrhgyaw2A7kDK9/NgkfTmGIpenNbnGT8XXS?=
 =?us-ascii?Q?imEsbfpyTaLNwF3w8F1qi1ix0mWPqXNKy4WGPvxviJZuMvp/ImIIeaoTEEUM?=
 =?us-ascii?Q?6CxHsUriCM14YdqSJgV6cpt3jRjyv0jrmmozNEZjY8+8a4cTNOkoqg0NgeCI?=
 =?us-ascii?Q?bQVft/I1n0tl57F7gF/nWC5IZq+3Tmkdn2Mt46bLHbwvmu8jCslpL5s95uuo?=
 =?us-ascii?Q?2aXXqKapFx2Qd3chYZhGWXFPyKdfQnUJgX8WZiq3XZZCufzkUufThKHAXqYV?=
 =?us-ascii?Q?pOJ6GNHZz3SLWHv64IfkEZ27/bV1/4t5?=
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(1800799024)(14060799003)(376014)(36860700013)(82310400026)(35042699022);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 14:12:23.0169
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7d153100-ed05-4966-34cc-08dd1f6dfe08
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DU2PEPF0001E9C0.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR08MB10236

Hi,

> On 18 Dec 2024, at 15:09, Ayan Kumar Halder  wrote:
>=20
> Hi Bertrand/Michal,
>=20
> On 18/12/2024 14:00, Bertrand Marquis wrote:
>> Hi Michal,
>>=20
>>> On 18 Dec 2024, at 14:56, Michal Orzel  wrote:
>>>=20
>>>=20
>>>=20
>>> On 18/12/2024 14:08, Bertrand Marquis wrote:
>>>>=20
>>>> Hi Ayan,
>>>>=20
>>>>> On 18 Dec 2024, at 12:34, Ayan Kumar Halder  wrote:
>>>>>=20
>>>>>=20
>>>>> On 18/12/2024 08:27, Bertrand Marquis wrote:
>>>>>> Hi Ayan,
>>>>> Hi Bertrand,
>>>>>>> On 12 Dec 2024, at 20:03, Ayan Kumar Halder  wrote:
>>>>>>>=20
>>>>>>> From: Michal Orzel 
>>>>>>>=20
>>>>>>> Add requirements for dom0less domain creation.
>>>>>>>=20
>>>>>>> Signed-off-by: Michal Orzel 
>>>>>>> Signed-off-by: Ayan Kumar Halder 
>>>>>>> ---
>>> [...]
>>>=20
>>>>>>> +SPIs
>>>>>>> +----
>>>>>>> +
>>>>>>> +`XenSwdgn~spis~1`
>>>>>>> +
>>>>>>> +Description:
>>>>>>> +Xen shall allocate a specified number of shared peripheral interru=
pts for a
>>>>>>> +domain.
>>>>>> This is very ambiguous. What do you mean here ?
>>>>> Xen shall provide a way to specify the number of shared peripheral in=
terrupts for a domain via the device tree .
>>>> I am lost in how you achieve such a thing in the configuration.
>>>> All you can do is assigned an interrupt to a domain, but the sharing p=
art I do not see what Xen has to do with it.
>>> This req is about Arm's SPIs (Shared Peripheral Interrupts) and the max=
 number you can allocate to a domU.
>>> You can see more here:
>>> https://xenbits.xenproject.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3Ddocs/mi=
sc/arm/device-tree/booting.txt;hb=3DHEAD#l172
>> Oh right, no idea how i came to shared interrupts instead of Arm SPIs.
>>=20
>> Then this is Arm specific and we need to have a bit more context/clear u=
p here (as comment or introduction).
>> And also this should have arm64 somewhere.
>=20
> ok, I can add Arm specific bits in the comments. Also, will put arm64 in =
the tag.
>=20
> Thinking again, this should be a product requirement as it explains the i=
nterface to Xen (in this case a dt property), Is this correct understanding=
 ?

Yes it should.

>=20
> Also, to your other comment :-
>=20
>>> I start to wonder if we should create interface requirements from the g=
uest PoV:
>=20
>>> A domain shall have a configurable number of vCPUs (1 to XX).
>=20
> This should be a product requirement as well. Correct ?

Correct.

Cheers
Bertrand

>=20
> - Ayan




From xen-devel-bounces@lists.xenproject.org Wed Dec 18 14:15:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 14:15:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860442.1272457 (Exim 4.92)
	(envelope-from )
	id 1tNuq5-0000jy-Og; Wed, 18 Dec 2024 14:15:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860442.1272457; Wed, 18 Dec 2024 14: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 1tNuq5-0000jr-M0; Wed, 18 Dec 2024 14:15:49 +0000
Received: by outflank-mailman (input) for mailman id 860442;
 Wed, 18 Dec 2024 14:15: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 1tNuq4-0000jg-GS
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 14:15:48 +0000
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com
 [2a00:1450:4864:20::52c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 92f2df13-bd4a-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 15:15:46 +0100 (CET)
Received: by mail-ed1-x52c.google.com with SMTP id
 4fb4d7f45d1cf-5d3f65844deso10789048a12.0
 for ; Wed, 18 Dec 2024 06:15: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: 92f2df13-bd4a-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloud.com; s=cloud; t=1734531345; x=1735136145; darn=lists.xenproject.org;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=7BnpisuMaAEwGQgH0Urzk5wgzIfUAJbgOtTfBe2eaTo=;
        b=LI1NhTpYp6tuI7oIvEETQ3fVUH43q3DynaYo8Pn3zhnizq+IQcyTiiT/eBfoaGqWKz
         tzRF8i7EPhtV6/eJQjmp5INOMwGs+HWS828dWll5Wm+raXPIyl0R/QuLKeHy/Cvk4Jom
         7zWKX+ZfXTFhl35ddiIi6auXpPxzi87lR6bMI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734531345; x=1735136145;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=7BnpisuMaAEwGQgH0Urzk5wgzIfUAJbgOtTfBe2eaTo=;
        b=QljOmJu4ahWN6D6W4t2PDZg2d1+A/r/QheedxiZO5N7uKZcf3EdT3cInnlRK0kghlD
         EN3scTSOxzOUqQ5H1J7wIlIcvEf1UyojucZOflWn7HksxsSIktl3ygZGeAD+ptNDPtbG
         JaCPWNto3rzQ4898fLg+RDnBaZDM1vr2h9rBe2R9UPMIqnWw/ThKYaMR5ZkpOC7dR1QD
         rAAgyOpL5EOtfXF57twEvvHoYXZGJ5EZ9r3raeHXyv/wVpCFX9SlZj1eW4WzbGoz2q0w
         E6G8bD/wv60DrGT38p7j5MP5jHdSsz6kc97X9sfjSrClO+pmlZqwNpLzPOk2bOYNu+jk
         RxPQ==
X-Gm-Message-State: AOJu0Ywx+K2GvnY9E6Onfy6liKTGIjnT7JMEWO4xDOUJ4SWXZdSl3Iny
	L7kl7ZjeV/SXO+OSuyU+JJAn7AjXyClbh3/K1ltAPk0VmWyVBr7nn1kg7FoRxQ/iMNrDl94Q9gZ
	Li4VJPK/HBd1RoBxo4mBgpkze5O8wz093MTLNVoFOcIxDjlNA
X-Gm-Gg: ASbGncsBgFG4/cLU1w8vbubx5sK0+0XBLlAdqztX41ifpD+EfRrLHCERLaTsEt1IGB/
	4UjQOK5YRgpaI8YbbnvXaU5ZrFmzMVjHe7EDSGF9xXOUuXqceJXl5+P+M9yjVFDJLBjty00rm
X-Google-Smtp-Source: AGHT+IGeFKN9PCECWNun/i2tvqIjtjjyCGbL8/EBOQlAuGPB6p0yF8vP9E78ZLia1lzKVABSn2mCmlRdqNH4p6ag3jc=
X-Received: by 2002:a05:6402:434b:b0:5d4:34a5:e2f4 with SMTP id
 4fb4d7f45d1cf-5d7ee404944mr2741543a12.31.1734531345268; Wed, 18 Dec 2024
 06:15:45 -0800 (PST)
MIME-Version: 1.0
From: Kelly Choi 
Date: Wed, 18 Dec 2024 14:15:09 +0000
Message-ID: 
Subject: January 2025 community call postponed by a week
To: xen-devel 
Content-Type: multipart/alternative; boundary="000000000000afdd9a06298c0c80"

--000000000000afdd9a06298c0c80
Content-Type: text/plain; charset="UTF-8"

Hi all,

Please note the next community on Thursday 2nd January will be
postponed to *Thursday
9th January 2025.*

Thanks,
Kelly Choi
Community Manager
Xen Project 

--000000000000afdd9a06298c0c80
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi all,

Please note the next=
 community on Thursday 2nd January will be postponed to Thursday 9th Jan=
uary 2025.

Thanks,
Kelly Choi
Comm=
unity Manager


--000000000000afdd9a06298c0c80--


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 14:21:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 14:21:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860450.1272467 (Exim 4.92)
	(envelope-from )
	id 1tNuvT-0002Tu-C7; Wed, 18 Dec 2024 14:21:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860450.1272467; Wed, 18 Dec 2024 14:21:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNuvT-0002Tn-8k; Wed, 18 Dec 2024 14:21:23 +0000
Received: by outflank-mailman (input) for mailman id 860450;
 Wed, 18 Dec 2024 14:21: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 1tNuvS-0002Th-Bj
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 14:21:22 +0000
Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com
 [2a00:1450:4864:20::442])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 59eccc90-bd4b-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 15:21:20 +0100 (CET)
Received: by mail-wr1-x442.google.com with SMTP id
 ffacd0b85a97d-3863703258fso548758f8f.1
 for ; Wed, 18 Dec 2024 06:21:20 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c80162ddsm14130504f8f.37.2024.12.18.06.21.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Dec 2024 06:21: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: 59eccc90-bd4b-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734531680; x=1735136480; 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=+JCJbP22T+5Ze5D++3EQHBYcNqmIdBZ+yjTivXT8QXc=;
        b=KEhKl6gN4X7iYxox+XK4LdBPrTFTemF34Rvmxw3v2SStdI0CegMtM8H+vg8kPO7AWu
         X/ufMaQ0VVoCDrmvVDlBusHFkOckNMbHGpNPDzrYFIM6BX/FuLD49Cmzr4Xcuzb1aY3C
         z1L3ubZZqGdvHDy+b0LsU2sSKY08xf6G/nqLQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734531680; x=1735136480;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=+JCJbP22T+5Ze5D++3EQHBYcNqmIdBZ+yjTivXT8QXc=;
        b=hrS8t1bf55SQqk5z5FCFMFJoNxIRGyGXoKAGxiMD5/fXT6SPc4yKxA1xCuU5cslFO5
         rsEnkLeyB1xWdV3gVmMw54ttfUk4j6DanpDg1DnbPJmfnbzCtENpFOCugj0HmT+jXYrl
         JCF27d1z7opLdl8WSPjaRN+7vMKoJZjDhjb19ucrnMb9Ms/EakGYEUIMMzHoR3opnaCa
         9QFExCZsjQsWwnqTMz3NFp5TRqxbCHMiEeby+4gt3B8ZkSnOLRnAVkVh0JgSh05tNUy0
         ecRpHeKXWVu3RoaasPxyzDaVIdKZrfpYfmD85GFVz+YToArNH/gUbPFKyJiKytIGIB5U
         VawQ==
X-Gm-Message-State: AOJu0Yzs8WgHeDd/PV/7a/5xGzYU78+Cocy2AP9iCrRjyQmXdmcVmOUU
	GfWhdxa0iohhqDQDKMtpV6uDfohn3cZRtjSvjyWyk3zepHjK7qPAzzVdtroLlKI=
X-Gm-Gg: ASbGncs5EwS8yLjmg0HKNt2Fk/EU4kxGDngidWz7uDVzjUkjLlGgiZC+bKIgh18FkPs
	t4S7zBtUNr0+Joxc5qzvAc3f3MIl3FlB0mmprA9thLywFcK30pC2y1rupot9UN1qVxrWozHd6W0
	vCpnX0URxNESzrrbCAytGh/I3hXL5O7lRVLNrLiXef7RcbNifw8wNrtof1VzvxQQne666fx4w9z
	rUAmpbtqOqK0GbbLTwRhbUBz3V0kTuIk6lRpdbz7IzQT+D6+2gjI5daHpX56T6zGRNGABKknAIP
	3o7zr1GsX/Id0Oz/xvXM
X-Google-Smtp-Source: AGHT+IEmjv/CThFXYLbcra63lHMJXGXEZXM3wKP0ZKOC5XdhRbga8lAxTQRU3UPJAElO635LHLJVfQ==
X-Received: by 2002:a5d:59ae:0:b0:382:45db:6a1e with SMTP id ffacd0b85a97d-388e4e3cdc3mr2677343f8f.14.1734531679623;
        Wed, 18 Dec 2024 06:21:19 -0800 (PST)
Message-ID: 
Date: Wed, 18 Dec 2024 14:21:18 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/1] tools, xen/scripts: clear out Python syntax
 warnings
To: Ariel Otilibili-Anieli 
Cc: xen-devel@lists.xenproject.org, Jan Beulich ,
 Anthony PERARD ,
 Luca Fancellu 
References: <20241214161350.70515-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216231128.211648-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216231128.211648-2-Ariel.Otilibili-Anieli@eurecom.fr>
 
 <2f7a8a-6761b180-9a89-1d1363a0@43143421>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <2f7a8a-6761b180-9a89-1d1363a0@43143421>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 17/12/2024 5:13 pm, Ariel Otilibili-Anieli wrote:
> On Tuesday, December 17, 2024 17:26 CET, Andrew Cooper  wrote:
>
>> On 16/12/2024 11:07 pm, Ariel Otilibili wrote:
>>> * since 3.12 invalid escape sequences generate SyntaxWarning
>>> * in the future, these invalid sequences will generate SyntaxError
>>> * therefore changed syntax to raw string notation.
>>>
>>> Link: https://docs.python.org/3/whatsnew/3.12.html#other-language-changes
>>> Fixes: d8f3a67bf98 ("pygrub: further improve grub2 support")
>>> Fixes: dd03048708a ("xen/pygrub: grub2/grub.cfg from RHEL 7 has new commands in menuentry")
>>> Fixes: d1b93ea2615 ("tools/pygrub: Make pygrub understand default entry in string format")
>>> Fixes: 622e368758b ("Add ZFS libfsimage support patch")
>>> Fixes: 02b26c02c7c ("xen/scripts: add cppcheck tool to the xen-analysis.py script")
>>> Fixes: 56c0063f4e7 ("xen/misra: xen-analysis.py: Improve the cppcheck version check")
>>>
>>> Cc: Anthony PERARD 
>>> Cc: Luca Fancellu 
>>> Cc: Andrew Cooper 
>>> Signed-off-by: Ariel Otilibili 
>> Having poked about a bit more, this is all a big mess, but these do now
>> work with Py3.12.
>>
>> leading \ for non-special characters are ignored in [], which is why ...
>>
>>> ---
>>>  tools/pygrub/src/GrubConf.py                  | 4 ++--
>>>  tools/pygrub/src/pygrub                       | 6 +++---
>>>  xen/scripts/xen_analysis/cppcheck_analysis.py | 4 ++--
>>>  3 files changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/GrubConf.py
>>> index 580c9628ca..904e7d5567 100644
>>> --- a/tools/pygrub/src/GrubConf.py
>>> +++ b/tools/pygrub/src/GrubConf.py
>>> @@ -320,7 +320,7 @@ class GrubConfigFile(_GrubConfigFile):
>>>  def grub2_handle_set(arg):
>>>      (com,arg) = grub_split(arg,2)
>>>      com="set:" + com
>>> -    m = re.match("([\"\'])(.*)\\1", arg)
>>> +    m = re.match(r"([\"\'])(.*)\1", arg)
>> ... the \' works here.
>>
>> Anyway, I've checked the others and they seem to work, so I suggest
>> taking this roughly this form.
>>
>> Some notes about the commit message.  The subject ought to be:
>>
>> tools: Fix syntax warnings with Python 3.12
>>
>> The text should be a regular paragraph, rather than bullet points like this.
>>
>> I can fix this all on commit if you're happy.
> Thanks for the feedback, Andrew; I'm happy with your changes.

And committed.

https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=826a9eb072d449cb777d71f52923e6f5f20cefbe

Thankyou for your patch.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 14:25:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 14:25:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860471.1272486 (Exim 4.92)
	(envelope-from )
	id 1tNuzZ-0003OX-2y; Wed, 18 Dec 2024 14:25:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860471.1272486; Wed, 18 Dec 2024 14:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNuzY-0003OQ-V6; Wed, 18 Dec 2024 14:25:36 +0000
Received: by outflank-mailman (input) for mailman id 860471;
 Wed, 18 Dec 2024 14:25: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 1tNuzW-0003OJ-AC
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 14:25:34 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f025c815-bd4b-11ef-a0d7-8be0dac302b0;
 Wed, 18 Dec 2024 15:25:33 +0100 (CET)
Received: from delta.homenet.telecomitalia.it
 (host-82-59-161-229.retail.telecomitalia.it [82.59.161.229])
 by support.bugseng.com (Postfix) with ESMTPSA id 182C34EE0738;
 Wed, 18 Dec 2024 15:25:29 +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: f025c815-bd4b-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1734531931; bh=nz5SGNzKkrBDkmuzBCerTpwM3pMGyf0Iax1l74zOG2I=;
	h=From:To:Cc:Subject:Date:From;
	b=RSaMPaaq3GVx98PSPjTh2rPLHwwvGBagjZel0BQswfdYZkmZp6un+YF0hG23IWOOY
	 qhHyv7Ub/El9bU08ZOK8eP3dvOa36UB2PTm9sA07UtWi47NJx7n1tDkxFN4WTxJx8h
	 26+MD3ZbipVItAhrtsVdMYXNX+SseMmnNGpHySOs9l/8ebJOEgfUZCX9C1cbaKgtgv
	 zuW/I+TzZ0OMnFo3NJiGz4Fwn8J32O3dG+Ie8M6nJh51C4oO9jq45C1o6vlaY78a1n
	 sQR9ZnHeK1C7+aJmJCT8DldGZGE78OuYZU/jiM3qwLtPZYhK2/Tn3/5WX7MIjC1Z6S
	 4ltda9VLyXFJg==
From: Alessandro Zucchelli 
To: xen-devel@lists.xenproject.org
Cc: consulting@bugseng.com,
	Alessandro Zucchelli ,
	Simone Ballarin ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: [PATCH v2] misra: add deviation for MISRA C Rule R11.8.
Date: Wed, 18 Dec 2024 15:25:10 +0100
Message-ID: <7e4f836606d72769a80299c5451f6f7241471d8a.1734530952.git.alessandro.zucchelli@bugseng.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Rule 11.8 states as following: "A cast shall not remove any `const' or
`volatile' qualification from the type pointed to by a pointer".

Function `__hvm_copy' in `xen/arch/x86/hvm/hvm.c' is a double-use
function, where the parameter needs to not be const because it can be
set for write or not. As it was decided a new const-only function will
lead to more developer confusion than it's worth, this violation is
addressed by deviating the function.
All cases of casting away const-ness are accompanied with a comment
explaining why it is safe given the other flags passed in; such comment is used
by the deviation in order to match the appropriate function call.

No functional change.

Signed-off-by: Alessandro Zucchelli 
---
As this patch introduces a deviation for service MC3A2.R11.8, it
depends on the following patch and shall not be applied prior to its
application.
https://lore.kernel.org/xen-devel/cf13be4779f15620e94b99b3b91f9cb040319989.1733826952.git.alessandro.zucchelli@bugseng.com/T/#u

Changes from V1:
The deviation has been refined to specify that every instance of casting away
const-ness is accompanied by a comment explaining why it is safe.
This comment is a requirement that has been incorporated into the text defining
the deviation.
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 2f58f29203..c9d06b44f4 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -393,6 +393,12 @@ Fixing this violation would require to increase code complexity and lower readab
 -config=MC3R1.R11.8,reports+={safe,"any_area(any_loc(any_exp(macro(^container_of$))))"}
 -doc_end
 
+-doc_begin="Function __hvm_copy in xen/arch/x86/hvm/hvm.c is a double-use
+function, where the parameter needs to not be const because it can be set for
+write or not"
+-config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(text(^.*__hvm_copy.*HVMCOPY_to_guest doesn't modify.*$)))"}
+-doc_end
+
 -doc_begin="This construct is used to check if the type is scalar, and for this purpose the use of 0 as a null pointer constant is deliberate."
 -config=MC3R1.R11.9,reports+={deliberate, "any_area(any_loc(any_exp(macro(^__ACCESS_ONCE$))))"
 }
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 14:26:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 14:26:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860478.1272495 (Exim 4.92)
	(envelope-from )
	id 1tNv0N-0003tp-AR; Wed, 18 Dec 2024 14:26:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860478.1272495; Wed, 18 Dec 2024 14:26: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 1tNv0N-0003ti-7O; Wed, 18 Dec 2024 14:26:27 +0000
Received: by outflank-mailman (input) for mailman id 860478;
 Wed, 18 Dec 2024 14:26: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 1tNv0M-0003sB-33
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 14:26:26 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20610.outbound.protection.outlook.com
 [2a01:111:f403:2414::610])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0d6fea5e-bd4c-11ef-a0d7-8be0dac302b0;
 Wed, 18 Dec 2024 15:26:25 +0100 (CET)
Received: from MN0P222CA0003.NAMP222.PROD.OUTLOOK.COM (2603:10b6:208:531::13)
 by PH8PR12MB7027.namprd12.prod.outlook.com (2603:10b6:510:1be::19)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Wed, 18 Dec
 2024 14:26:17 +0000
Received: from BL6PEPF0001AB59.namprd02.prod.outlook.com
 (2603:10b6:208:531:cafe::d7) by MN0P222CA0003.outlook.office365.com
 (2603:10b6:208:531::13) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.23 via Frontend Transport; Wed,
 18 Dec 2024 14:26:17 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 BL6PEPF0001AB59.mail.protection.outlook.com (10.167.241.11) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Wed, 18 Dec 2024 14:26:17 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) 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; Wed, 18 Dec
 2024 08:26:15 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 18 Dec 2024 08:26:13 -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: 0d6fea5e-bd4c-11ef-a0d7-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Y0TvbE8rJKXcQ7dyrNl3QoE9vLyZeLClReTLY1J0y7zyE5p20LzQT4tqU94KXmzEoA0hkIDL7zQKtpoA3I0Y6t+hPoG0BRPgRMGFc73rNFz25Ch1ZHbal5MVHJUvHGdX34s5njAN691vJvke/hr3spa0kZENlxaQsCjyHM3aOiwKnJU8Q218GeB4oQyrrPdjDVeG/aTAh0jZRPW2ahXkI9zGseM8XGteF9FWDCy3N6wB7tx6cGJpFeTx+rAqtPVTR+8zze+Ju2vQfPUzOTFQdEqd0+opoDOddVmYTFH9iIzyAjel/lQxR3GfiWfJ8Af2660ok9MoAOltIOPy7qivgw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=05SOyKmzutmcKPhgk89AiitgH5Cz57v5pmXECL8+GiA=;
 b=BGdDKM/Cup5pPzxt9xAYrovQ37946CktMKElqrGsBXGeH4EI70PJ4/eWMEXuAm7cvVKR53Nx8k4zdlUjt1tKfMUrQg11BN0DMeDuNRoKaDQYkBq6rYtBoFX8T4pyf+sCr1e76MQcgOloFRFhVZRngxHA0UQhV4PAcllvU48+wEBKCEgfbnFfMEhDaWL/wLVAkuGbu/C+qQ5mQO0FGYcur/NDsL79YrAE9uZuWg6La6oo/ZUMOd9OZ1vM7rzYVA4Q5+crsupy/Go028GRrLtubNAPvqbPcBmcCQZWykybflhptGSTJYMgEmKhL4Pk9rRf93ZGVDyumfWKPUGg2hSBJA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=oss.nxp.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=05SOyKmzutmcKPhgk89AiitgH5Cz57v5pmXECL8+GiA=;
 b=a2irqtk8t+lKbgpBuHgwOt2M+IzAhPJZI9bDWi8/oGVLEKzKTEFQGP82+WXYc7erRcdyt+J724wY9V7ihem9AJ9h9AxrMMzBfw5Ap6nQPyYLjs/jLmH4sK0ZQmQ036B1WYGBl/NQ3d5c2IjJyeG98vFmTtiqWSh5YGRD2c1VuSI=
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=SATLEXMB04.amd.com; pr=C
Message-ID: <60d4ac08-c5e8-4a38-bfc9-2b73e6cf5ec7@amd.com>
Date: Wed, 18 Dec 2024 15:26:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/6] xen/arm: firmware: Add SCMI over SMC calls
 handling layer
To: "Andrei Cherechesu (OSS)" ,
	
CC: , Andrei Cherechesu , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Volodymyr Babchuk
	
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
 <20241218101142.1552618-2-andrei.cherechesu@oss.nxp.com>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <20241218101142.1552618-2-andrei.cherechesu@oss.nxp.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB59:EE_|PH8PR12MB7027:EE_
X-MS-Office365-Filtering-Correlation-Id: df53d78e-2a03-41fd-1f6b-08dd1f6fef59
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|376014|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?U3k5NzlKTGpQNExQU1FjMFhNc1Q1WURUeWEybVlZbDNjU2lGRWtwMFlCV1pj?=
 =?utf-8?B?cXZBQ0Fwd3JSRnRDN0NZcmo4aGJJcFBHZy9tdEFMaTI4YU5MYXduNUFjTUZP?=
 =?utf-8?B?WHFmVnY3VVhKRHdJdlM1aW43bjk5dFF2VTBwbUVRSjl1SGNEUXhYSXlTa0R1?=
 =?utf-8?B?ZUtVMERjSWUwMmdFTXY5UXVsRHVpSURGM1RybTFkNnhwanZYOEtmTlV3S2xr?=
 =?utf-8?B?cHJFajJMYkRINS9JNjk2RC8vL2ljYm1mRHNLdkpSY3J1MHJIY09CTjBaZXZu?=
 =?utf-8?B?ZXV5SHNqcTdHZnAyZVNGNFI4azJuRWROM05XVTkrTlZQUTg2WEN6eXFqUUN0?=
 =?utf-8?B?K25XbThPcnJOU21CTGw0VldZRU8vNEwxalFqS3lyeHFjOHRDOWRBK3NtR1dH?=
 =?utf-8?B?TEp4MTRCQUVLM0JTVXh5RzNQYWxYNUtXRWRBS2VvakI1MzNyLzRFYmgyZTFz?=
 =?utf-8?B?N0R0TW5GTTlPWjl4eTNrQTZCM1VNc3FXQ3l4OWlUekNZZXVCMXdCbVIxWEQ3?=
 =?utf-8?B?Z1BUSGhMV28ySzNqSjZXQjhZWjkrQ2UvNkd5dEl5OXByR0s4dUwrbUovUldw?=
 =?utf-8?B?OHV3RTBvcGpUcXRyTVBvNTNJUVdLalROK0hhRjRaRzFvR1E3MklrYVI5RDVo?=
 =?utf-8?B?NTRpcHo2NUNYTVE4ZFVxSzc2VEpWcnlwSXVGQkNHaFJRSHNBRW53L1FDTlJH?=
 =?utf-8?B?dW41c3QrekZDSndwTzJBY0F3a2dZSDRCWGpFMm5NZnF3KzJrQWJoMXg4RFMw?=
 =?utf-8?B?RjBHRkNERGhOTjNYL2xtZFA4b1FDeCtrdmYyZ3hyNkZyYmlXMGw3SHJoWFl2?=
 =?utf-8?B?ZTdtblA2NkVOUC93SVJ3WXMvTFg2RkhkalMvME0wMHJxWVVjOFRQRk11Z0Zr?=
 =?utf-8?B?ZFdkNUxqS21NNy9wZWVDd3M5TWNPWFpGWVg3TFh0cWFiNjFSR3BZYkxrUGpD?=
 =?utf-8?B?VDZhMzRPb2ZjSGxtamVtcFp2WWd4UHZOSG9LakVLWDVFWlVXYmF1SUh6cm8y?=
 =?utf-8?B?R1VEL0R1LzlTNVN5TEZCU2FtWW9hNVpxVFZSVEplck05QS9lSDFvVm02bElL?=
 =?utf-8?B?dFdpTEJmNUZQSnB6U0ZKVnlVaTYwV0xyOG5mc1publBKdkMxd0ZKMWo3cTJ4?=
 =?utf-8?B?RlR2QW1la1ExM1ppME1xOVRvVlJXeVR1NnNEeEllenNxR1FZUkxqbXFQT2s3?=
 =?utf-8?B?UitBOUU1cFFyWStHbmJWc0F4cjB5djdtdGtuZFRyKzc3ZjBKczc5djN6YmxM?=
 =?utf-8?B?ZEFjVHZsdHNIcFJFajNLREc0TFdMNXg4alJqc3BGb0tOUWhlbWFCWmVEL2xS?=
 =?utf-8?B?dlkxL1BqT0l4cDRXdHJHa2lvYlllazZoZUw3SXNYZU4zcHdzOEZPNmZJejR5?=
 =?utf-8?B?S3ZJYVRjbVd6UDFab0lZOUluL2s4dFd5S25Ra2N3ZnJTOSsyWkxxMTRYNkxI?=
 =?utf-8?B?REd1bEEyWGZVMExDK0REWUNsbjNMODZNZmEvQTBLdUxRYkVUWmYwWGxMOXgw?=
 =?utf-8?B?eEt0SGQxSENZZDlYU0RDMlM0c2ZRVGZMTDRSOC9PQ1lKUFBjLzVXcHdDSE1o?=
 =?utf-8?B?NWkrWU80cnZYbTdodGIwZWhCbTRjUW01T25xeWlJaU15TllvQ2J2dXhpaE93?=
 =?utf-8?B?VEFNWHc1N3pJV25vM0hxYVRMVUNsWVNLZ2tYTnpKV2E1YXFTdVJGbnhBVjlP?=
 =?utf-8?B?M0h2Vk04RSsvYTdDN3JOaHRGOXlvUXBGNzJXZEI1anl3Z0hSN2JPTWJiNVpx?=
 =?utf-8?B?QkN0MC80VkZQM3FXWHdMSU45WlN5R3l2OVRnNExrNTJmZFhKUm9Sb0w3OFdL?=
 =?utf-8?B?RUNvVzBVTXRDaW1XWi9qUnh6SmhHeXVmLzZrM0trWGdyOTdSVTdUcG9tYkJY?=
 =?utf-8?B?Q2lXVGlBdEZjeFlDZGJXa1QzMlgvZkRUZ21QUVJ3UDR0UStjdEI1UFB4c2NB?=
 =?utf-8?B?V2U5RjJMMU1GdXJCQ3l5R1FSRUFuUVZMME9qZ1lVMnhjWi81cVdtSlRqZ1BO?=
 =?utf-8?Q?Z37dT53xixjpWIlH8PLoEBltigSpFw=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 14:26:17.3279
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: df53d78e-2a03-41fd-1f6b-08dd1f6fef59
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BL6PEPF0001AB59.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7027



On 18/12/2024 11:11, Andrei Cherechesu (OSS) wrote:
> 
> 
> From: Andrei Cherechesu 
> 
> Introduce the SCMI-SMC layer to have some basic degree of
> awareness about SCMI calls that are based on the ARM System
> Control and Management Interface (SCMI) specification (DEN0056E).
> 
> The SCMI specification includes various protocols for managing
> system-level resources, such as: clocks, pins, reset, system power,
> power domains, performance domains, etc. The clients are named
> "SCMI agents" and the server is named "SCMI platform".
> 
> Only support the shared-memory based transport with SMCs as
> the doorbell mechanism for notifying the platform. Also, this
> implementation only handles the "arm,scmi-smc" compatible,
> requiring the following properties:
>         - "arm,smc-id" (unique SMC ID)
>         - "shmem" (one or more phandles pointing to shmem zones
>         for each channel)
> 
> The initialization is done as initcall, since we need
> SMCs, and PSCI should already probe EL3 FW for SMCCC support.
> If no "arm,scmi-smc" compatible node is found in the host
> DT, the initialization fails silently, as it's not mandatory.
> Otherwise, we get the 'arm,smc-id' DT property from the node,
> to know the SCMI SMC ID we handle. The 'shmem' memory ranges
> are not validated, as the SMC calls are only passed through
> to EL3 FW if coming from the hardware domain.
> 
> Create a new 'firmware' folder to keep the SCMI code separate
> from the generic ARM code.
> 
> Signed-off-by: Andrei Cherechesu 
> Reviewed-by: Stefano Stabellini 
> ---
>  xen/arch/arm/Kconfig                         |   2 +
>  xen/arch/arm/Makefile                        |   1 +
>  xen/arch/arm/firmware/Kconfig                |  13 ++
>  xen/arch/arm/firmware/Makefile               |   1 +
>  xen/arch/arm/firmware/scmi-smc.c             | 166 +++++++++++++++++++
>  xen/arch/arm/include/asm/firmware/scmi-smc.h |  46 +++++
>  6 files changed, 229 insertions(+)
>  create mode 100644 xen/arch/arm/firmware/Kconfig
>  create mode 100644 xen/arch/arm/firmware/Makefile
>  create mode 100644 xen/arch/arm/firmware/scmi-smc.c
>  create mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 604aba4996..23dc7162a7 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -271,6 +271,8 @@ config PARTIAL_EMULATION
>           not been emulated to their complete functionality. Enabling this might
>           result in unwanted/non-spec compliant behavior.
> 
> +source "arch/arm/firmware/Kconfig"
> +
>  endmenu
> 
>  menu "ARM errata workaround via the alternative framework"
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index e4ad1ce851..8c696c2011 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_HAS_PCI) += pci/
>  ifneq ($(CONFIG_NO_PLAT),y)
>  obj-y += platforms/
>  endif
> +obj-y += firmware/
>  obj-$(CONFIG_TEE) += tee/
>  obj-$(CONFIG_HAS_VPCI) += vpci.o
> 
> diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig
> new file mode 100644
> index 0000000000..817da745fd
> --- /dev/null
> +++ b/xen/arch/arm/firmware/Kconfig
> @@ -0,0 +1,13 @@
> +menu "Firmware Drivers"
> +
> +config SCMI_SMC
> +       bool "Forward SCMI over SMC calls from hwdom to EL3 firmware"
> +       default y
> +       help
> +         This option enables basic awareness for SCMI calls using SMC as
> +         doorbell mechanism and Shared Memory for transport ("arm,scmi-smc"
> +         compatible only). The value of "arm,smc-id" DT property from SCMI
> +         firmware node is used to trap and forward corresponding SCMI SMCs
> +         to firmware running at EL3, for calls coming from the hardware domain.
> +
> +endmenu
> diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefile
> new file mode 100644
> index 0000000000..a5e4542666
> --- /dev/null
> +++ b/xen/arch/arm/firmware/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_SCMI_SMC) += scmi-smc.o
> diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-smc.c
> new file mode 100644
> index 0000000000..62657308d6
> --- /dev/null
> +++ b/xen/arch/arm/firmware/scmi-smc.c
> @@ -0,0 +1,166 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * xen/arch/arm/firmware/scmi-smc.c
> + *
> + * ARM System Control and Management Interface (SCMI) over SMC
> + * Generic handling layer
> + *
> + * Andrei Cherechesu 
> + * Copyright 2024 NXP
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#define SCMI_SMC_ID_PROP   "arm,smc-id"
> +
> +static bool __ro_after_init scmi_support;
I don't understand the need for this variable. IMO it's useless, given that in next patch you do:

...
if ( scmi_is_enabled() )
    return scmi_handle_smc(regs);

return false;

which could simply be changed to:
...
return scmi_handle_smc(regs);

and the variable, functions for it, etc. could be removed which would simplify the code.

[...]

> +err:
CODING_STYLE: this should be indented with one space.

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 14:33:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 14:33:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860490.1272506 (Exim 4.92)
	(envelope-from )
	id 1tNv7W-0005ue-4V; Wed, 18 Dec 2024 14:33:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860490.1272506; Wed, 18 Dec 2024 14: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 1tNv7V-0005uX-VQ; Wed, 18 Dec 2024 14:33:49 +0000
Received: by outflank-mailman (input) for mailman id 860490;
 Wed, 18 Dec 2024 14: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 1tNv7U-0005uR-8g
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 14:33:48 +0000
Received: from NAM10-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam10on2061d.outbound.protection.outlook.com
 [2a01:111:f403:2413::61d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 15d8fc54-bd4d-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 15:33:46 +0100 (CET)
Received: from CH2PR14CA0001.namprd14.prod.outlook.com (2603:10b6:610:60::11)
 by DM6PR12MB4434.namprd12.prod.outlook.com (2603:10b6:5:2ad::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Wed, 18 Dec
 2024 14:33:41 +0000
Received: from CH2PEPF00000143.namprd02.prod.outlook.com
 (2603:10b6:610:60:cafe::9b) by CH2PR14CA0001.outlook.office365.com
 (2603:10b6:610:60::11) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.22 via Frontend Transport; Wed,
 18 Dec 2024 14:33:41 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH2PEPF00000143.mail.protection.outlook.com (10.167.244.100) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Wed, 18 Dec 2024 14:33:41 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 18 Dec
 2024 08:33:40 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 18 Dec 2024 08:33: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: 15d8fc54-bd4d-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Wq8lb3c6nWOflW7DCHv9YCe8BTbf9a6qS53YFkjeua6FXSr5KYbUDrWLWw4FOp7f1dKZ3HU++mPc55wDnMXLmpLOlDC8HE0+8a/ZdigprDO4otrhiYoe84FNb86O0qvkV2ldau+QeVyH9gkYMiTJZA8RE75oWloKEl0OhUGlGg30H8XifYfznx6oqq8XnHn207P3NNdov9GgYa/c8kfW8AWnv+LBtYvBsP2KAoOu+9MQi4ohchSb7sA3YwiyzYVE2mWKM4WapRqNt9ncZB6k8RAo9jHYudRCPgrN44c0X6UpHGedaXdJs45j5pFsMLLI5scgLu0hSn3LN6FY33I35A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=MHiEYzmaPPql9175PNmfWDDddZ+K5Nc9EIMG1jrdtNE=;
 b=Q/4v2v+l0nqqmrszTH3E6yUXvIjZ52pwCIHFZxrQ8rfBmyN9edyIlmToZort+UvbdgUap5/gLq8d/3cwmGQ4dDSPxBHKf8M/qVH2bBPgNiH3Nt2xZw80ss+PRDXRu3lUR65dKWrfh3BT6aCo/gtW6vn+VyLJbSZJFFJZ+OBdNgIcNbi9Ojbvgr04wwD6nKE+5k2MbDzU5SH4WtuZ+h2Qn//DIw5gsgufgeFIKDOOJ5r3lhwm0xppPRydFo7h6m1lsb0RUphuSci6kacJhxs8SpjCjmp5nuqZAP1vT+jn52HFiHaagOY9xNEsAFWmKaWYxtx2CuIj2MXvAL/UWowEBg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=MHiEYzmaPPql9175PNmfWDDddZ+K5Nc9EIMG1jrdtNE=;
 b=AJK+LFmSABsiiFEnweOnnw1xDajsTG5L6f1GAqOiR8A6WcChgayETkwC6w8y/xJDP5czaQqxMHn/nJK9PcWH31uaCwWZRKMHMzFeE4O47yZOmxxPJ2ZV7F3C4LwnhiyxmJtMlS0dPuyrgg0Yy+uZd8zear9Lk8/KuzkifSDx4f8=
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=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Wed, 18 Dec 2024 15:33:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 5/6] SUPPORT.md: Describe SCMI-SMC layer feature
To: Bertrand Marquis , "Andrei Cherechesu (OSS)"
	
CC: "xen-devel@lists.xenproject.org" ,
	"S32@nxp.com" , Andrei Cherechesu ,
	Andrew Cooper , Anthony PERARD
	, Jan Beulich , Julien Grall
	, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
	Stefano Stabellini 
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
 <20241218101142.1552618-6-andrei.cherechesu@oss.nxp.com>
 <9806AD58-30DD-41B8-BAC8-F408A9BB16D5@arm.com>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <9806AD58-30DD-41B8-BAC8-F408A9BB16D5@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000143:EE_|DM6PR12MB4434:EE_
X-MS-Office365-Filtering-Correlation-Id: 56bee664-e0b6-4c92-872b-08dd1f70f82b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|7416014|376014|1800799024|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?bTc5bDVGSHBZZTViOWJIQklqRkM3T3dmTkxqYy9OZ1VkNU5YSCtoSXJsbFVT?=
 =?utf-8?B?ZTU2THVkeUJ0THNZVFBNaFFjbFlJb0twSkc4S3ZKUVkxY0tFdU9SZDdJR20z?=
 =?utf-8?B?OTFkclRLVXJwVEl1RjhhMlR2L3dBNld0KzF3WXR6aVIyYzhNN0NNRllUT0hB?=
 =?utf-8?B?cGJrL2o2Ti9FNll2RmJIa1NjWTlWOXFGMmJncVRLY1liZmg5MFpWYWxYdS9S?=
 =?utf-8?B?UVlCYmxmZTg1cS9od01JbDdsc1o1NHorcHIvWkxSYTd5TUlWMEdNZGY4dEgx?=
 =?utf-8?B?MmpISkZBcFd5cE1teHpRWE1uV0NnN3dxUEpwVjg0L1pseEtPMFErMEVwR3l3?=
 =?utf-8?B?d2hqUVEvY2ZkRVpzVTMrWExvd2FqKyt6U3VQTlM4bEF5WmJxNGZ1dFZBdzll?=
 =?utf-8?B?MDAvR080d3dtOVVGRERCcWVnbHAxenFuRzFia3VkbThRZEdHblZvdDZKeVdo?=
 =?utf-8?B?M2NuWk9iQVJiY2tOUHVNK2I4WkZIa0VCSzNETWlqdmJva3dxWFVnSkh4ZjYr?=
 =?utf-8?B?ZDQzaWZtdkhMTm5JeUUxekx0UXlkMDNFYmY5S3dra2tnb2xJMlZwOXFKZEd1?=
 =?utf-8?B?Q2c2aDZVeVoyeDU5NlR2QlRrVHdjbzdQemtDbEp2ZzFZOXBpdy9GTjhGbE5s?=
 =?utf-8?B?K1FSQ0ZWSi9EUGI2ZTdTYW5Uckhxa1BWUzdsY1F3U0pFbTNUSDYvRW82QmlB?=
 =?utf-8?B?SlNhN3hKM1ZyclY0U2VjR3VVYWhNb1g3dWF0Vi9ha2NtUW1GeGZ0WnpSOUxP?=
 =?utf-8?B?YmhUNnh6dXh0V0twTWJOMmcwYVA4bGVPYXQrTU1OODg4c0t3SHE2bUFwUVk2?=
 =?utf-8?B?MnZoTUZlSGZ3cXlTeExVeHI5TitKd2c0dm5lTE5uVHoyalZYUG1jK0xyRWVv?=
 =?utf-8?B?Wm85TFdoOFhGTmYxOHdQQTRHOTl0NWRkTFkySzJCN0RyZkQwcTF3R3YxUFR3?=
 =?utf-8?B?Um90MUxaZnNnMTZCTUZWZGhXb0Q3ejRmTFdCNHA5QzAwYUhXMkNOQjdQcFVt?=
 =?utf-8?B?dURLV2ZaZWgrZE5Wa3VIWExMdEhWS2xBamNrY1BldjBjaGhudGQwVUIrK3lh?=
 =?utf-8?B?b0gyN3MxOC9mYWdkWkJ1NG1QeTd0bVAwZU5vS1lhbnByWnZFL3Z2YmM1QTBW?=
 =?utf-8?B?cEg4dmRmV20yaGY3T1o3ZjM1ajlGbWNYWWpFZ0w5UmNwWmh0NkxOTEtQZkpp?=
 =?utf-8?B?Nitselo0SU5nRjlibEFnY1pWSmhLSkdkcld3R015NmF3ZWZqdG5LWGl1bTcx?=
 =?utf-8?B?bDBkY2oxTFpWN2hranA2V28zamtZY25iS21QejV0VXdyYkd6Uzh0cGQ4TnI0?=
 =?utf-8?B?M2hBL0dobGV3RHJ5Z3RuUW5xSENISUtvK0haTHh3SFp0eVY2U0FkQkJpdkla?=
 =?utf-8?B?QmpZd3hodWxGc3EyQWZEVTVRSjF3MDFRMmgxOXpGQlRLK2hIcmhIY1NaMjh3?=
 =?utf-8?B?R0M4WjZuQnBZWjR5UmFkSnYwanZsWUZxOHBoVE9jb1UxVFBKWkJ5RzA2bjZR?=
 =?utf-8?B?YlJhaWwvM2s3cVNjUGtIdWxYZTJyWktjT0g3VTdCc0t2ZFJyVGJTMGZ2UStW?=
 =?utf-8?B?YXBsWUlEYlFRalJpOEpHbDdOWCtWMmdHL0hzZ2RtT1hlRnpRdmhxM2pnYmNk?=
 =?utf-8?B?VDVIMW5VT0lsd3hJNHV5RUwwaXFPWFRpTFYvL1gyMS9QQzcxOFBNMHd4blVN?=
 =?utf-8?B?WXh2aVB1dlN2aU5zNGpLZXB3R1BkUGF0dU9NRjUzenpjamxnakkza1NtSDJG?=
 =?utf-8?B?ZXdPeWpkdTB5cXk0ZU5UMTZuQXpxUEVWRFdzOUUzYWhyRC9WcUVrKzhGSXVK?=
 =?utf-8?B?bGZ2akNVSGVaNlR2THVQZ1dwL1lsc0YrRlhFeVdyeGZMZlJRRFpCOHVBWHFY?=
 =?utf-8?B?a1hvNkRyMWJsbjh2ZE1URHJaOHVCMmdOMzBrU3hGQXpzaG1wSmV1Y2E1OVJP?=
 =?utf-8?B?V2JqZkRTSEJWR2NlMUV5RGd2cUJrZjFqeW02aWdsN2tyRGwyYW1DbUNZRzFK?=
 =?utf-8?Q?Pj7X1dlXFcjcTYRkiFBgx16eg8/meY=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(7416014)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 14:33:41.5941
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 56bee664-e0b6-4c92-872b-08dd1f70f82b
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF00000143.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4434



On 18/12/2024 11:29, Bertrand Marquis wrote:
> 
> 
> Hi Andrei,
> 
>> On 18 Dec 2024, at 11:11, Andrei Cherechesu (OSS)  wrote:
>>
>> From: Andrei Cherechesu 
>>
>> Describe the layer which enables SCMI over SMC calls forwarding
>> to EL3 FW if issued by the Hardware domain. If the SCMI firmware
>> node is not found in the Host DT during initialization, it fails
>> silently as it's not mandatory.
>>
>> The SCMI SMCs trapping at EL2 now lets hwdom perform SCMI ops for
>> interacting with system-level resources almost as if it would be
>> running natively.
>>
>> Signed-off-by: Andrei Cherechesu 
> 
> Reviewed-by: Bertrand Marquis 
Acked-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 14:34:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 14:34:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860498.1272515 (Exim 4.92)
	(envelope-from )
	id 1tNv8U-0006Tx-Fi; Wed, 18 Dec 2024 14:34:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860498.1272515; Wed, 18 Dec 2024 14: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 1tNv8U-0006Tq-DF; Wed, 18 Dec 2024 14:34:50 +0000
Received: by outflank-mailman (input) for mailman id 860498;
 Wed, 18 Dec 2024 14:34: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 1tNv8S-0006I2-Ug
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 14:34:48 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2060e.outbound.protection.outlook.com
 [2a01:111:f403:2416::60e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3b89213a-bd4d-11ef-a0d7-8be0dac302b0;
 Wed, 18 Dec 2024 15:34:48 +0100 (CET)
Received: from CH2PR18CA0040.namprd18.prod.outlook.com (2603:10b6:610:55::20)
 by MN0PR12MB6030.namprd12.prod.outlook.com (2603:10b6:208:3ce::6)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Wed, 18 Dec
 2024 14:34:44 +0000
Received: from CH3PEPF0000000C.namprd04.prod.outlook.com
 (2603:10b6:610:55:cafe::af) by CH2PR18CA0040.outlook.office365.com
 (2603:10b6:610:55::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.21 via Frontend Transport; Wed,
 18 Dec 2024 14:34:43 +0000
Received: from SATLEXMB04.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_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Wed, 18 Dec 2024 14:34:43 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) 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; Wed, 18 Dec
 2024 08:34:43 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 18 Dec 2024 08:34: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: 3b89213a-bd4d-11ef-a0d7-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=obs4VhEfsgovlc1+4PMXQoWaZIEcS4KlxNR45vRvDyaip3Fqw161O0gAE1BqcGfq4puU+TNRpY+QJPWpxQnPNCjprey7VHtcUQ2+Dts6iUzEemEh2lkCcxSDCO1RAsQ5z4RDoBzziDojIqbzbhteRRCH20BNdC8ZIzXmzqyUuUzyk1vFv46DlpRllHAQZ/Jjs5z+VMxf+m11wq+r4TM72JQ9Yqwfmr1bfnCBguNXFWSeTqoOt0X18CNDwczN9h0ECsXMXT8u6KNVV7+OWob81cOeTrdr/K5dEx+eC6uQAiI9xNXInFfPxrwRr+NtLoDkS4oEbqqaWnaXULBzCK5Qzw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=CuiXPf3UIvijiiKu4KZpVObm0FRznRijDnzj9F5gtfw=;
 b=jojnW89FrD1+DXEG5+lYA0H+tOukfXYfNcjSZ/qBHqd+ZxCFzdCVXjpqDOnYOeGpMuea0GTQntoWLdldpDN1k1MnpA58T4P087tGZxPtvRznEOc2Y0+c96ndNfu18PsQijHFPdytUeYHZfkWSIBTdNjf8Q1uu2weXxlmefYRuhWQrtN9fvvAYBWbyR20cDylZ06+bZZTarcKVDl8d68gfXM4kJiYNrM9fw71Y1T9FHR9RirobtgVtwYT0rDQ7De3EtNmU+bXod3ytws8dd2Q4pf3VDW0pR74FdG26iyq4NE61NVZe5dzuxsARiXU8PiwBhsf8M2qy6XfLuouiOp5VQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=CuiXPf3UIvijiiKu4KZpVObm0FRznRijDnzj9F5gtfw=;
 b=vVolaHj5Vsb+8IGsla/Jn4caXBPTbjeTjWZyYalBHKTbQ8vgI7EorQ7bEWddCIgnJnxFUjYGMVSHqiLEGvfZxH/7tG8Nh9GtjhSlxCXp9jnRf5+nMwQfbz2P06cDhWXkdfsxU38FDuLXAAIpnuyPw3AxmaMW+5yqz5NLV4AmyBE=
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=SATLEXMB04.amd.com; pr=C
Message-ID: 
Date: Wed, 18 Dec 2024 15:34:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 6/6] MAINTAINERS: Add myself as maintainer for NXP
 S32G3
To: Bertrand Marquis , "Andrei Cherechesu (OSS)"
	
CC: "xen-devel@lists.xenproject.org" ,
	"S32@nxp.com" , Andrei Cherechesu ,
	Andrew Cooper , Anthony PERARD
	, Jan Beulich , Julien Grall
	, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
	Stefano Stabellini 
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
 <20241218101142.1552618-7-andrei.cherechesu@oss.nxp.com>
 
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PEPF0000000C:EE_|MN0PR12MB6030:EE_
X-MS-Office365-Filtering-Correlation-Id: 72e8c438-cf08-4301-6eb6-08dd1f711d27
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|376014|1800799024|7416014|36860700013|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?YUJLWUZKR1BSblZ5TUF3SjB6QnVhemFaSzhwVkFod3NsV3UxS2FxdVpZcGw1?=
 =?utf-8?B?SUloOWNrNUs0ZkFCVDVPN0p1NjB1RXNveDhMZ3FIUEJRRWI0WkI5WXZYZUI5?=
 =?utf-8?B?MEw1WXdONGpJYytQUWNrM3laYTRtNHVMUWp0cit2TGx5RVkvdFo4UXFyUWJK?=
 =?utf-8?B?eGNGVEc3aThxMkVIZUNXN0ZzOHBjaVo5SjFnQ3NNQ3MvZFNCSXJPeW9xdFVB?=
 =?utf-8?B?bjRwRWFPMEtsWGZjbS9TTzdjZHZUcmFvRExHMUNUZnIrOWE1NnYwM3V4U3pS?=
 =?utf-8?B?cnpId0xkb2FQWnMwU2NrODlscWhyc0tiL0VKY25DZlp1bkliWFExVFd0Y1Zo?=
 =?utf-8?B?OGV5eXRaRTllTzc0dmEySnA4dzVXZTB4SlZhUGVFdUtDVFo4QjVDVFRDSXVx?=
 =?utf-8?B?SkpoendTRWVEMXJKeGIxc3EybWM3R211WGNpTUVaV3ZCY0FocXVCdTM0OHU1?=
 =?utf-8?B?UUprOFhjK2tSM1U3eTN0VEVDbGJrTHVwNHkxdW1lZ1FadUFDSzhhSWY3MHhI?=
 =?utf-8?B?OENPbHRiaFhpb2lpOTBMd2xXbGZNQ0I4dkMvcFVlemFIQVM3TUpMR3dWU0Ur?=
 =?utf-8?B?cm9iSWxFYkM4TWpEY3F6WUpmNW5SMDVIdzR3cmFrcHhnR2tkaTlUNDFVbVA0?=
 =?utf-8?B?K2h3UVo4elpCVXYxVFhRUFU0MTBYcW1RWHlXTVROMnZMcEdnUFdGdTRXR0sw?=
 =?utf-8?B?djJyd2JsWCtqZ3lkTUFJZ20weEZXRGd6ZHFtMXVFaEh1R3pRc0pubXgwa08y?=
 =?utf-8?B?NlFIQXlJSy8vNlF5elZ6dk9GTGprL2U1TDQrUXNYR0tHSU0yY0dMUmZwL09l?=
 =?utf-8?B?cnBNVUlnTnlyZzJodXlKTEVsWEV2ZDJlYWlGL1hyVHQ3VGkzaDI5Vkl4ZklJ?=
 =?utf-8?B?Y0o1MHZOdUYwMy9LZXZtc2FPR1lXcC9Mekx1ak5GOU9oQjdGWW84ZEY3NXVL?=
 =?utf-8?B?eUlFbTVmc04ydERPb3l5cnhHVDUrVkJDRUVHTmQ0K3lLM1UwRHN3aVNjVXVr?=
 =?utf-8?B?ZS8vdWZ2S2thTFUzSUhxdlBlbk1FSTZSS1lwczhOZnVZa3MrS3MrTkU3OC9X?=
 =?utf-8?B?Zm02d1F0V3pZRXVDcE9peTVLeklzeHFqMXBjWlBKNktCRzFkY0MxSDZXNXd1?=
 =?utf-8?B?WXJ2TmM4OU92Q1RIZHVqZFBEdm9WV2VtUm14TlBaSENWc2xWemhOVFdwZkVT?=
 =?utf-8?B?S2ZBSGRGNHhOZTZlRU0yTzlGQWlhUlN5VGx4TVh4RWxCWThIQWxaRk0zaGhw?=
 =?utf-8?B?dlMvL2xwbDNoeHptUjJLVzY3Y1hvWnhSMlplM1JBMm50eWtpZnBKVUtTbHdh?=
 =?utf-8?B?cDRhSDh4bFBTdDVQaVdEMi9IUFF2Y1pzcFVzUFJUNGZhRXdIODUrOCtqT1Vm?=
 =?utf-8?B?VEh0eXdBb3lobExXTURIODlaRU40bTduRUFiM3hyOFZJc1cwekQ4MklvVWJn?=
 =?utf-8?B?bC9RZnRLVkUwQ01OMVY5dW5icGVmVXQ1SVdENU9GVTdGZ3JqTFhyTkNVSHlZ?=
 =?utf-8?B?d0VFME5xRDNWY0h0bnMranFiUjdhb2xtUmxRWlhTaDE3MVRoc2kvV25wbjhu?=
 =?utf-8?B?U0lNWTdVOUtPWFIwK2RnSk1Ua1hsYkpMOTllU0ZsL2ZBN3dveXhGQXJRd3U2?=
 =?utf-8?B?WHdnS2lsK1FIVTdJRmNmU3VWTEZMKzcwaXFHV2Q0UlBVd1BjUlJFcitEeExX?=
 =?utf-8?B?Ly9lSExQQ21GTndwVXVEL3BVcHdwTjlJMmV4cFFJNzN3TUtWVHZKOHd1a3Bu?=
 =?utf-8?B?cm1KN1RSNzltOFUyVUZlYTY5NzhzL1hSb0ZvemUrT3VUNStaamp0NldtNVFT?=
 =?utf-8?B?T2wyMFE1bXVIdytkeERRQWwvSDZKQkVTdU9RWXMwT2J6TU1TaUdCNUZoUFp4?=
 =?utf-8?B?Ujk5MWsyWHVXTU5KY1hCMWhuMGkwRWFGMHdsNTVPSjNWVlBuVDVJOWUvbHM0?=
 =?utf-8?B?aXo0V2NMa3c3cjhKLzhVVHpLL2wwdTFLL1JpdW05R3dJTzZ3bWdQV0ZSc0dG?=
 =?utf-8?Q?bbmr6X22PXP3YLOwB5v11YEMKDsHAQ=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(1800799024)(7416014)(36860700013)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 14:34:43.6429
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 72e8c438-cf08-4301-6eb6-08dd1f711d27
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=[SATLEXMB04.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: MN0PR12MB6030



On 18/12/2024 11:31, Bertrand Marquis wrote:
> 
> 
> Hi Andrei,
> 
>> On 18 Dec 2024, at 11:11, Andrei Cherechesu (OSS)  wrote:
>>
>> From: Andrei Cherechesu 
>>
>> Add myself as maintainer for NXP S32G3 SoCs Family,
>> and the S32 Linux Team as relevant reviewers list.
>>
>> Signed-off-by: Andrei Cherechesu 
> 
> Acked-by: Bertrand Marquis 
Acked-by: Michal Orzel 

~Michal



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 14:57:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 14:57:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860512.1272524 (Exim 4.92)
	(envelope-from )
	id 1tNvUW-0001hl-5q; Wed, 18 Dec 2024 14:57:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860512.1272524; Wed, 18 Dec 2024 14:57: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 1tNvUW-0001he-2p; Wed, 18 Dec 2024 14:57:36 +0000
Received: by outflank-mailman (input) for mailman id 860512;
 Wed, 18 Dec 2024 14:57: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 1tNvUU-0001hP-AG
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 14:57:34 +0000
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [2a00:1450:4864:20::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 673c8f52-bd50-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 15:57:30 +0100 (CET)
Received: by mail-ej1-x62e.google.com with SMTP id
 a640c23a62f3a-aa1e6ecd353so902163466b.1
 for ; Wed, 18 Dec 2024 06:57:30 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d652ab5077sm5485822a12.17.2024.12.18.06.57.28
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Dec 2024 06:57: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: 673c8f52-bd50-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734533849; x=1735138649; 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=XhzGeo4oqoNOgqgC0vx9o2pyKCL8/bwBJyFRCefXgJA=;
        b=L+8o2xAPOtimFQgOEdr9SoBoNiZu+KUR825Ls4bwdEz4p/7EVrADT+5b/lCjrMcN+r
         XTrlqKc2Ju8DpuJkqNmke927LBNNJcunQwf2vLz0UUh2eMDdelQ7W+wliKa+8CVASRmg
         cnzlzzHRKEVC93dvrY28OsmSCD2vIuCAmBUNOYqyAS2+eGQ4dk1ttUdzi4U92IByT9xV
         DXdRRiqhUpShPoTjRl2QOlueYV4XOGsKOw2h6dUb0XQZ6yfF8hBla4AYHsyIG4o8onxo
         V90RoJ7o3wuPn3SzDK4xGpX9eozKZu6JhqYF2XJfxNJhUCt/tnGtDPeGdL0vZ0rjUBsJ
         +EtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734533849; x=1735138649;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=XhzGeo4oqoNOgqgC0vx9o2pyKCL8/bwBJyFRCefXgJA=;
        b=D3GM0uh8iGofRUSXaZOPd1JoOZmMlrra1TKQhWE5rJ/DI4AKR5dYoxflncxyVGlLmZ
         iOFL9A4ZWZVVD5ArkAnXhVxNsYT9CUCpu/AlP4hbO/iGaJPQhXbUmPwsCD55SCdmf1KZ
         EElySJ99q2hwDWE/XaUO/7GvJ/94R2GaWQtKH7pAJtoPkfzn2tz5pQQMuqGLnRrZEe8z
         ojXuQerILDmIiCREdeTF4z6ZQCOYXmInX8RXcJ20CEGY/Kwb/ELuMvuCX8pilxGe1FEY
         Cnoqd1vQzLGtodJZsliXFJI8e/cb1mIObLvsqbeZNh6uxUvh+lL0T73LBTmtexUSosYe
         m9Qg==
X-Forwarded-Encrypted: i=1; AJvYcCURKyBN2RS76LH/zrkhCkeufiH5PTb0F101TTmq+KCdnuQKJSeQSsSalnX/LSPdzL1s2vBaOAM3xDc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy5/QDnyW0x7dc7HbLAPeBFB6bIwcu18XkBJeouksKcZc5FrZy8
	MfAWpeXCbqbWgnthf1US0n5SIo3NU9n0v53X1VTcBIL8RqfW14FGC6RGZN74Hsk=
X-Gm-Gg: ASbGncuSGGxZ5ZiNKrqikArfgkkHKN2Bu+cXOkp0GT4gUgmoBzK0+f7WzRbmxJuj94z
	Fq46yJjh8pw7VquIUkfJl9cyeAf1SYJVGXoaRJDMH0eKJR9g/BEl5DA3e6Xa6+SslZgcJcHsgV4
	RNpjFrdxbJ0izB+cCbXWa0La5vx+FHJyarOggl2JieCEF10vlxzj0oU7VytewOUroXDHlgaUyK9
	ooihIxyT/W9odEwHz9LstxzAzCbUxDzLN7z/2IjTd7V4d5BIft0UiPhwaSaDmQD9ISo/HJRuUA8
	XmijtBRdq+8qhIbBYc/SL3w0nRq3UbmXCL2wPcOZKEIc34mUuRanQoaVP0/aH9nDHzN+131CK8W
	GEWOM+g==
X-Google-Smtp-Source: AGHT+IHUCNdnqvum6EYV7Xed4kEu7GbOxjQJaYPVHBcDqNps/hNJZ0pVAfTrkGfUMgHFM2VMAw7Smg==
X-Received: by 2002:a05:6402:3814:b0:5d3:ff93:f5f9 with SMTP id 4fb4d7f45d1cf-5d7ee3b6194mr7735353a12.20.1734533849381;
        Wed, 18 Dec 2024 06:57:29 -0800 (PST)
Message-ID: 
Date: Wed, 18 Dec 2024 15:57:28 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/sched: Untangle credit2 vs cpu_nr_siblings()
To: Andrew Cooper ,
 Xen-devel 
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio 
References: <20241218124900.60886-1-andrew.cooper3@citrix.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: <20241218124900.60886-1-andrew.cooper3@citrix.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------4PoHlfyIT00FO0qBQQCTx0Ga"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------4PoHlfyIT00FO0qBQQCTx0Ga
Content-Type: multipart/mixed; boundary="------------hurtdKyja73I8o3Itj3kvF3p";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Andrew Cooper ,
 Xen-devel 
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Shawn Anastasio 
Message-ID: 
Subject: Re: [PATCH] xen/sched: Untangle credit2 vs cpu_nr_siblings()
References: <20241218124900.60886-1-andrew.cooper3@citrix.com>
In-Reply-To: <20241218124900.60886-1-andrew.cooper3@citrix.com>
Autocrypt-Gossip: addr=JBeulich@suse.com; keydata=
 xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk
 hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK
 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD
 /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py
 O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl
 MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP
 nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo
 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp
 Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJ3BBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC
 AwECHgECF4AAIQkQoDSui/t3IH4WIQQ+pJkfkcoLMCa4X6CgNK6L+3cgfgn7AJ9DmMd0SMJE
 ePbc7/m22D2v04iu7ACffXTdZQhNl557tJuDXZSBxDmW/tLOwU0EWTecRBAIAIK5OMKMU5R2
 Lk2bbjgX7vyQuCFFyKf9rC/4itNwhYWFSlKzVj3WJBDsoi2KvPm7AI+XB6NIkNAkshL5C0kd
 pcNd5Xo0jRR5/WE/bT7LyrJ0OJWS/qUit5eNNvsO+SxGAk28KRa1ieVLeZi9D03NL0+HIAtZ
 tecfqwgl3Y72UpLUyt+r7LQhcI/XR5IUUaD4C/chB4Vq2QkDKO7Q8+2HJOrFIjiVli4lU+Sf
 OBp64m//Y1xys++Z4ODoKh7tkh5DxiO3QBHG7bHK0CSQsJ6XUvPVYubAuy1XfSDzSeSBl//C
 v78Fclb+gi9GWidSTG/4hsEzd1fY5XwCZG/XJJY9M/sAAwUH/09Ar9W2U1Qm+DwZeP2ii3Ou
 14Z9VlVVPhcEmR/AFykL9dw/OV2O/7cdi52+l00reUu6Nd4Dl8s4f5n8b1YFzmkVVIyhwjvU
 jxtPyUgDOt6DRa+RaDlXZZmxQyWcMv2anAgYWGVszeB8Myzsw8y7xhBEVV1S+1KloCzw4V8Z
 DSJrcsZlyMDoiTb7FyqxwQnM0f6qHxWbmOOnbzJmBqpNpFuDcz/4xNsymJylm6oXiucHQBAP
 Xb/cE1YNHpuaH4SRhIxwQilCYEznWowQphNAbJtEKOmcocY7EbSt8VjXTzmYENkIfkrHRyXQ
 dUm5AoL51XZljkCqNwrADGkTvkwsWSvCSQQYEQIACQUCWTecRAIbDAAKCRCgNK6L+3cgfuef
 AJ9wlZQNQUp0KwEf8Tl37RmcxCL4bQCcC5alCSMzUBJ5DBIcR4BY+CyQFAs=

--------------hurtdKyja73I8o3Itj3kvF3p
Content-Type: multipart/mixed; boundary="------------ZW02jYcg6TbVqeDm0g7pTEWB"

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

T24gMTguMTIuMjQgMTM6NDksIEFuZHJldyBDb29wZXIgd3JvdGU6DQo+IENyZWRpdDIgaGFz
IG5vIGJ1aXNuZXNzIGluY2x1ZGluZyBhc20vY3B1ZmVhdHVyZS5oIG9yIGFzbS9wcm9jZXNz
b3IuaC4NCj4gDQo+IFRoaXMgd2FzIGNhdXNlZCBieSBhIGJhZCBvcmlnaW5hbCBhYnN0cmFj
dGlvbiwgYW5kIGFuIGV2ZW4gbGVzcyB3aXNlIGF0dGVtcHQNCj4gdG8gZml4IHRoZSBidWls
ZCBvbiBteSBiZWhhbGYuICBJdCBpcyBhbHNvIHRoZSBzb2xlIHJlYXNvbiB3aHkgUFBDIGFu
ZCBSSVNDLVYNCj4gbmVlZCBjcHVmZWF0dXJlLmggaGVhZGVyLg0KPiANCj4gV29yc3Qgb2Yg
YWxsLCBjcHVfZGF0YVtjcHVdLng4Nl9udW1fc2libGluZ3MgZG9lc24ndCBldmVuIGhhdmUg
dGhlIHNhbWUNCj4gbWVhbmluZyBiZXR3ZWVuIHZlbmRvcnMgb24geDg2IENQVVMuDQo+IA0K
PiBJbXBsZW1lbnQgY3B1X25yX3NpYmxpbmdzKCkgbG9jYWxseSBpbiBjcmVkaXQyLmMsIGxl
YXZpbmcgYmVoaW5kIGEgVE9ETy4gIERyb3ANCj4gdGhlIHN0dWIgZnJvbSBlYWNoIGFyY2hp
dGVjdHVyZS4NCj4gDQo+IEZpeGVzOiA4ZTJhYTc2ZGMxNjcgKCJ4ZW46IGNyZWRpdDI6IGxp
bWl0IHRoZSBtYXggbnVtYmVyIG9mIENQVXMgaW4gYSBydW5xdWV1ZSIpDQo+IEZpeGVzOiBh
ZDMzYTU3M2MwMDkgKCJ4ZW4vY3JlZGl0MjogRml4IGJ1aWxkIGZvbGxvd2luZyBjL3MgOGUy
YWE3NmRjICh0YWtlIDIpIikNCj4gU2lnbmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8YW5k
cmV3LmNvb3BlcjNAY2l0cml4LmNvbT4NCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3Mg
PGpncm9zc0BzdXNlLmNvbT4NCg0KDQpKdWVyZ2VuDQo=
--------------ZW02jYcg6TbVqeDm0g7pTEWB
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-----

--------------ZW02jYcg6TbVqeDm0g7pTEWB--

--------------hurtdKyja73I8o3Itj3kvF3p--

--------------4PoHlfyIT00FO0qBQQCTx0Ga
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/Ey8FAmdi4tgFAwAAAAAACgkQsN6d1ii/Ey8f
/ggAgDO2VlJKZDM7K137nvqrCxhW10QOChSraZ2krmAcuKS6D0qwtQ7cjyC6nrZn97P4Z1OsPHiP
9MUdPObnGjYpDPPG45hicjzhNNIs4p/K48SXyoYB96MUT0h6ZEaRZ0shpm0Co7zOpbI8aQo7T94F
XYSfDniMchharX38Jrlo2zzzhe35PwvcETKwoCmBWvo+9PlgEcLD9MswbqIdf8+05jsKbtperdzO
BKs8Q0kuFiyZcbToh0SFwHDuC3J2h2jjiQQDRUMhRjMsVkgl1UQkJ+gpYEw2ErhT+BqMvL3wr6eL
uCN/Nyf/RuiqqakqPhdF9lRMLukGkMbqJt4i9aMe/A==
=6Rzz
-----END PGP SIGNATURE-----

--------------4PoHlfyIT00FO0qBQQCTx0Ga--


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 14:58:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 14:58:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860517.1272535 (Exim 4.92)
	(envelope-from )
	id 1tNvUy-00027b-DH; Wed, 18 Dec 2024 14:58:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860517.1272535; Wed, 18 Dec 2024 14: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 1tNvUy-00027R-Ab; Wed, 18 Dec 2024 14:58:04 +0000
Received: by outflank-mailman (input) for mailman id 860517;
 Wed, 18 Dec 2024 14: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 1tNvUx-0001hP-JC
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 14:58:03 +0000
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [2a00:1450:4864:20::52d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7a574a95-bd50-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 15:58:02 +0100 (CET)
Received: by mail-ed1-x52d.google.com with SMTP id
 4fb4d7f45d1cf-5d0ac27b412so9090398a12.1
 for ; Wed, 18 Dec 2024 06:58:02 -0800 (PST)
Received: from ?IPV6:2003:e5:8731:2800:842d:42a0:5992:3595?
 (p200300e587312800842d42a059923595.dip0.t-ipconnect.de.
 [2003:e5:8731:2800:842d:42a0:5992:3595])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d652f35859sm5479277a12.72.2024.12.18.06.58.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Dec 2024 06:58: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: 7a574a95-bd50-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734533881; x=1735138681; darn=lists.xenproject.org;
        h=in-reply-to:autocrypt:from:content-language:references:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=S0414ug4zrbmvVXRiGshRo+sKjpj1Xm1Q6Ek/T4Y41s=;
        b=Pr614sIIA1J/kapT8hF0H5xrPgvFg2Md8ImdYTrzkQSnuaTcmheU2EXCMeDKp0U167
         tzJMJDIaqfAQm4Tys4m1jDDY3hDQLtyOclfdgQxOTPP8QtXK6MiC1nlavdSlN5DeAPJe
         gK3oKU/7m2jzTXwGOR8FXCTKNpZS2D5xbuWrHc7VCIZPjIrO0HajmnX00xTqat3d1c2S
         zo9bW3E1xZelTRJ1ZiZA2IYJWFWQJ6NnMojQqw6Bg5Mwc/QyMugJmI32W58MpsRDZoLf
         yIZtaIpyjTrfemc4M/HLmKca9xB8gH3Fb1JA2Z0pk+BJouCj9L7VX6qy7iw7+5L2kkeO
         XWAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734533881; x=1735138681;
        h=in-reply-to:autocrypt:from:content-language:references:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=S0414ug4zrbmvVXRiGshRo+sKjpj1Xm1Q6Ek/T4Y41s=;
        b=wU+BvPCh/bi2WPJg6iXPNc5FuNBIqX+RcVe6gEFw57/e0IJ+Pwm5dJ3+F5CErZN1Cc
         3I35JUBmbSsuYWgDsXsfeald4k00qMZekNIT39AUhF/rGuiDHJYrvNYvg371gHhgta61
         WmLUVX0E3N452ZiUx51a2tp8QCCuoSohEN05p2LxGwFqz+Rxigj/vHY4b9XlgQZ0iT2y
         ZmC/tcBP3qzv/zlfeyQdgolMEDmYFKss7xnG1/Ehdg2Ptvtfm7+dLqU4dKYPU3UnwIDc
         bWNjLHeMg2VRQ0QgMdU0oXUJP+/bJjKevE8K//FPgSH3GtX9NDhMe9HqhKJ4/e1ZcC9j
         OjjQ==
X-Forwarded-Encrypted: i=1; AJvYcCWQT6xaBxxYodMcW3wY0RBqOjEZ+U/6/zidQPNO7NhNjJTE7zmlwVg7p9J2xifrVG4gZR/Ijpg+sSw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxsCHxtpM+wpRp+t93HPWnLnAHcnDB0cVGLIWO5chF2S5Tj/2YO
	I59sXzlLV4m8NHUDd/mfMkv5fmS6Ar+55pSA3XZQX4k5pr5trVVFX0v5JXEhIDTrKerOvB9zUW5
	2P50=
X-Gm-Gg: ASbGncvRdXJpKD8hyOC1jg9u9rgjrQ8eB/orOHgFlevC3YLEsHIFrv6/sLs5vx/DLIh
	Vd7mIjpqxM/+e36H9uesYz5DNJL9chIZA90tdhAucWl4uclWqydrvf+ILs3hMmr8iMDJgLBFl0V
	37fRW/Mb+2XHgUowWP5dudbKoz6Fm/K+S31TiKIM1KE6/2WpBPpmyGKvdhflp8E/wM0sVDDWu+L
	IgFpOCQydB/JfHuHz6MnXe/Q4s1fz6k5Lz+zFT+/a6YhjawNzropREXLJNekoyStLEYzhX8Iweo
	KU0sTCUe92FwoIXIQCIeCbZwKnKSIYtNGahnshdTyL0cmLrmG0FkZSi6HsKGypxE+jjhYelxhmK
	epxVKUQ==
X-Google-Smtp-Source: AGHT+IEmkClt6WvwiWJVQCboYGd7vON3/aiCj0I79IBz/fwFR/pwo9/pmAFOHldvMOLXtHfHXmTBpw==
X-Received: by 2002:a05:6402:414f:b0:5d0:e877:764e with SMTP id 4fb4d7f45d1cf-5d7ee40604cmr3054407a12.24.1734533881433;
        Wed, 18 Dec 2024 06:58:01 -0800 (PST)
Message-ID: <91a58202-8dc2-4a0a-b0e8-cf24809c8bbc@suse.com>
Date: Wed, 18 Dec 2024 15:58:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/sched: Drop unused includes from credit2.c
To: Andrew Cooper ,
 Xen-devel 
References: <20241218125324.75973-1-andrew.cooper3@citrix.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: <20241218125324.75973-1-andrew.cooper3@citrix.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------SriG06JeLmmPbu2qA03aZGCl"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------SriG06JeLmmPbu2qA03aZGCl
Content-Type: multipart/mixed; boundary="------------ZXGqNVbM05RfbEohfBOjoqH5";
 protected-headers="v1"
From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
To: Andrew Cooper ,
 Xen-devel 
Message-ID: <91a58202-8dc2-4a0a-b0e8-cf24809c8bbc@suse.com>
Subject: Re: [PATCH] x86/sched: Drop unused includes from credit2.c
References: <20241218125324.75973-1-andrew.cooper3@citrix.com>
In-Reply-To: <20241218125324.75973-1-andrew.cooper3@citrix.com>

--------------ZXGqNVbM05RfbEohfBOjoqH5
Content-Type: multipart/mixed; boundary="------------FTHjmvO60iWioOLwzCHapUEU"

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

T24gMTguMTIuMjQgMTM6NTMsIEFuZHJldyBDb29wZXIgd3JvdGU6DQo+IFNvcnQgdGhlIHJl
bWFpbmluZyBpbmNsdWRlcy4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIg
PGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+DQoNCkFja2VkLWJ5OiBKdWVyZ2VuIEdyb3Nz
IDxqZ3Jvc3NAc3VzZS5jb20+DQoNCg0KSnVlcmdlbg0K
--------------FTHjmvO60iWioOLwzCHapUEU
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-----

--------------FTHjmvO60iWioOLwzCHapUEU--

--------------ZXGqNVbM05RfbEohfBOjoqH5--

--------------SriG06JeLmmPbu2qA03aZGCl
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/Ey8FAmdi4vgFAwAAAAAACgkQsN6d1ii/Ey+E
hwf+JGKx3SJt7GHzqUgMKTKY7Cz3XkBFHUwhQT+BiQdQt56BmnIsZr9BHPCxdkcSXyf2V96su3hk
QfY9U5iEowzsE2uvby9RZhV22rmRksG6nOiDeH1sPEynqlVcbpVDu0iCUlbBqFn0dbu6Iai8Ud0q
iytw61ODHg46Z0cwnlqv+5kPdV67mDH1ImiXcry5vB8PNknwimUaCvYLfyp6eBGz2GEf0oDxBtUR
1Bjh3HLofIad4QLtPjn3OHvPhu5Tl0YFurOBmw2NqoNXrONzWILmOyt+/nL/anvd9xO9gCjOMrQ3
v8CCE21ZJ/RTHca5f+QrvMkgYxzLsz4FzmYcl6SWaw==
=AtV3
-----END PGP SIGNATURE-----

--------------SriG06JeLmmPbu2qA03aZGCl--


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 14:58:56 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 14:58:56 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860527.1272545 (Exim 4.92)
	(envelope-from )
	id 1tNvVm-0002lj-QY; Wed, 18 Dec 2024 14:58:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860527.1272545; Wed, 18 Dec 2024 14:58:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNvVm-0002lc-Mf; Wed, 18 Dec 2024 14:58:54 +0000
Received: by outflank-mailman (input) for mailman id 860527;
 Wed, 18 Dec 2024 14:58: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 1tNvVl-0001hS-48
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 14:58:53 +0000
Received: from DUZPR83CU001.outbound.protection.outlook.com
 (mail-northeuropeazlp170130004.outbound.protection.outlook.com
 [2a01:111:f403:c200::4])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 981106b0-bd50-11ef-a0d7-8be0dac302b0;
 Wed, 18 Dec 2024 15:58:52 +0100 (CET)
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com (2603:10a6:10:312::7)
 by AM9PR04MB8811.eurprd04.prod.outlook.com (2603:10a6:20b:40a::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.22; Wed, 18 Dec
 2024 14:58:49 +0000
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f]) by DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f%6]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 14:58: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: 981106b0-bd50-11ef-a0d7-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mYJSsrj+ohRUtKj7l4JpXSksbHOnEiytKUWfPSaR/pvHGyM8uIkFWoJMfP3HP9chR/BM6gYS6YK0NCDyjoMqocd/IkxTWtopVQZP2TnQOvLSJThYBiIFe3Nz/jQtKA42OFk+M5slBCCtEry6eAHE21LmtQeGvoQm7ioe+94bi4quh/Hk60qeCoIsp6e6im3GI/Jkr0/kFhKv7HofS2vSwWbOg8T/rMWDxgSJL/On5LK71nBlQk3fOmLy9glD77Em/MJSvtfeT9erDDF/i3xAxV9EB2YZ6PeBTxOHW3sopIpJ7N72VGhb1+AUM9RU+DOyyPpK+BEj4tcQyk9oIh/4HQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=J5nD//b0JavtJ6znmFnqrPWjCj/MU+Fht37nAkphZo4=;
 b=hukkzkvor4DIRyOC4dXuhI0FCIEdvc5i7wKpAzct76xJCAqZu9zOau/3XuoWkhdfhOL8qTjdpUt7SrlV2jRwu2vHIR1OXMlmvClvZFA9Zv0wjRhTyyaFUlBYCU0yGcfYlWkoveWkLBdCfaPgV7mVf3O47/Cl7Zr1eOECDVv7Br3cHZ4jfwhtiSv/mKjOKlYrvHGcYAaSEElItjYygoACNDO5aDnlA/EInCMhLAHoeI2PDjHJg3m6PbQMm0DKtE1z9G3im45sQ38WP9i/Pem7GvCDv+IqLO4wE25vZM4rUxw9joqdWh5clJ/W/O3O9/pwlnlVb+PJtbnThDT/Ccn2lg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com;
 dkim=pass header.d=oss.nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com;
 s=selector1-NXP1-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=J5nD//b0JavtJ6znmFnqrPWjCj/MU+Fht37nAkphZo4=;
 b=ixukpN8mKCGECA+7xop93T+KAxCeBZ47a00KyvM0hRrLFGyocgTqtoia01W+D4DaIMTC367oO9G6qHFPpWNowDkBC0j2h+w5HwfRnzwkl9nmMwVJ0KQQknt8jPa0NhnaLsRh+C7+TRqNBM5FkrXwf9bFcx7m0iBpPsnBR84Fyt/5J6a5DpbNLpL1sKxqe19CcJxvTsXSb6eb6FWFUFU3BBP6CCRJb9WFgk5e9CM2jz6dI2rp4kmusaXqHD6pRpcQEikt0kwGOUKpIpf3wz722ioUJ8UBYgMmUrzmFivu060mj9C1/nq2JSwcZRYJV7x6NSBkUo9X1XvnqgK7tS6zUQ==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=oss.nxp.com;
Message-ID: 
Date: Wed, 18 Dec 2024 16:58:47 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/6] xen/arm: firmware: Add SCMI over SMC calls
 handling layer
To: Michal Orzel , xen-devel@lists.xenproject.org
Cc: S32@nxp.com, Andrei Cherechesu ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
 <20241218101142.1552618-2-andrei.cherechesu@oss.nxp.com>
 <60d4ac08-c5e8-4a38-bfc9-2b73e6cf5ec7@amd.com>
Content-Language: en-US
From: Andrei Cherechesu 
In-Reply-To: <60d4ac08-c5e8-4a38-bfc9-2b73e6cf5ec7@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: AS4P190CA0035.EURP190.PROD.OUTLOOK.COM
 (2603:10a6:20b:5d1::11) To DU0PR04MB9561.eurprd04.prod.outlook.com
 (2603:10a6:10:312::7)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0PR04MB9561:EE_|AM9PR04MB8811:EE_
X-MS-Office365-Filtering-Correlation-Id: c232b71c-5441-4da1-0bb0-08dd1f747abc
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
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:
	=?utf-8?B?QmhEZkVubWw2b1VEbTNkMUxzcFZGdHFXeFRLUGk2Z3k2YlJCdFloVkk4SFlj?=
 =?utf-8?B?VnhKTTlxWVJVZEJFZWdGVXVINitIWTIxblU5RDNxZmM1c0VWUmpJS1JyRkZw?=
 =?utf-8?B?UHJKekRHQVdHQWhNelprekxnVUZDYlNsT3FzTkYxVVhDRVB0WHRTTG9HRjVp?=
 =?utf-8?B?eGpLVXZpVHFuc1ZWaTh0eWdLTzlabHptcE1LKytieWZUUU9ZVGp5YWUrZEMz?=
 =?utf-8?B?TE4zdDE2YVJua0xqVitBWlptZkpaL2lIZEltcFdIdUFZQzhkTkt2SCtQTnhp?=
 =?utf-8?B?ZktMV1hhdTJiMi9uZnFvQno3aGJ3NmhGL1JNU240TFRmeTE4MGZZWDk4UWpT?=
 =?utf-8?B?aHVRODcxVEx5T1oyT0JIc1RXQUlnMG1xclpBUlRJS2QwWllFRkt4dklGd3VJ?=
 =?utf-8?B?VzRGRjNmYktOaW1KWkgzQVprRm9PcGJ0bStDYnNIcm96WTIxUjc2ZlJxUDBY?=
 =?utf-8?B?Y1NOcG5GL1NJMFJOSGw3ZWF5YmsvMk5wdUpPRFJHWlBwR3FNOGlXL2x6MU95?=
 =?utf-8?B?ak5IOUlhSjEvYklBUDlxbmVjWGpBcUgrSVhramNHcVFtZHF6eHdCTGhvN0tD?=
 =?utf-8?B?M3BwZjlmS2pzZVVlYXhYVVBvZWtkNEkwWS83ejU0anZudG1qNXBiVHQvanZU?=
 =?utf-8?B?MUpoSXM2US9GbHhhRFdCeEFWOFpGWFRKVmtrZURmNHlra1dNSEo4RG82TFZR?=
 =?utf-8?B?ODJOcXJyZ3c4VURMM09sK1VXUW5FQklEZFI5eXZab3o5b2l3QkdmSzQ0NlhT?=
 =?utf-8?B?bHV6ZlhPVDFIci9PaDdQWE1IZ2hxOEVHellyMnBaUEFtLzhvRWc2bFAxblVQ?=
 =?utf-8?B?UVNuZzArYTdQUnpROVNEOFBSYzZXak9MQ3F1WkhTdjlwemV6SEp5aklVVE5C?=
 =?utf-8?B?Y3ZCcXNaL1BZaG5YdW9SMnpybHdVZUZ5TnQyTlk0TGQxZ1dOTTgrVUthTGFl?=
 =?utf-8?B?VG1FQUVTM1UwUnlZUm1YQnRyakF2VEZybEVFeWh6TjE4OG9xY2xzRHNpS2hK?=
 =?utf-8?B?endWUHlmTUdGZExYdE5rdlp1RFVhRHZjc2JvS1cxa1R2bUJFN3FMK3FycEFl?=
 =?utf-8?B?eG54TkFpNzZIbVJlQXJjUjg1ejlBZ3VWRXU1dUZYL1JadzhQWEg1MjdsdGxT?=
 =?utf-8?B?Q0l6TFpwQUp3VnpOYWp2SzJsMkJQWk4xTjlYN0lsL2JkTnVRRnlOSUF3dkg1?=
 =?utf-8?B?Wk5jcHAzM0JwRjFlbWR3d3Ryak96bkdSWHdYbzFraXkzYzExdk11dnpyVDU2?=
 =?utf-8?B?RGRGVWJodlBSMDNackhoTW0xOURQZER5bnhpZlNONHlPUUFtZ1ZKWTBUZHR1?=
 =?utf-8?B?cmtTVGU3S25ueHVLYkFxdGRyb3lXZmpqa3dwV3VicnNhZURrbHRPSWNHc2tW?=
 =?utf-8?B?WHBCOUhvczhDOE9oakFac1dsdXI5R2F6WjE2Si9tM2g2K2VSUFZsa0NVc1dF?=
 =?utf-8?B?N1BxU0lsNmhLbjB3Z0xlbUE0MHJJNlJJNU5OTXhqdkxhWnEvWHkvMVJ5aWVa?=
 =?utf-8?B?aEJXaUZMSjhEZTZxSmpqODFTblJybUpROC82b1BuOUpIV0Mva0h6dnAvckNh?=
 =?utf-8?B?TnlGbWhPekdQeGV1bGx3cUswWEpMYUxFbjBJZnYvL2Z4WVRXdHovN2JLS09M?=
 =?utf-8?B?U1IzZEIzWjhUc1k3VjFLVzNybXBGWDV2RHM4KzNOWC9Sam04Y2VzbWc1Q0sy?=
 =?utf-8?B?b2pTUXVZRTNiVjBsUmhKWTBYekhYSk1Ld2s4MDBXMzhrcngzVDgzbHFJbDBH?=
 =?utf-8?B?YUJSYnBKMHFlOTBGZWZ0RGJ0L1FSNjQrNXJQOEdTV0phd2lzNjBFV3U4WkI1?=
 =?utf-8?B?MFJqZTQ1VzhjcjRPT2dYWlZoZ2JFOVl5K1k1TnhKNXFmTWZvWEVoeGFMcktT?=
 =?utf-8?Q?Kjs5ejJcD0c+s?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR04MB9561.eurprd04.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?STZhaTB3MVhDVnBES21JVUJaakhoVTdVQm9rTHZhUHhsVGk2WG5xSlNNT0Nr?=
 =?utf-8?B?b3MyMTd2cHNtZUhQT0ZIZDZYbWxoWUExRVRyTUtXVFI0MEhJbU54b1RhRWNz?=
 =?utf-8?B?cXJ2WEExTHFzZTg5OGFjZTVwZUk0UmpSeVplUGdWWWNYTndFNHhGbTdkQlh2?=
 =?utf-8?B?am9FRFZOSzlFTnptNjFtVzAvUi9qdzJvODRobnBEcDlKRGJ5cHZvNnp0TEdu?=
 =?utf-8?B?dnFHVm1sQWN1NUdnMFBWblNDeEhxTnVBZjdLTUhaK3ZQVjRTaGVjSnRXZjR5?=
 =?utf-8?B?QW96ayszclptWjZVOW1CU1RqWXI0Q1Aydmd0MmY0cHJLUUNEV2xpaGs5RHVr?=
 =?utf-8?B?dlEyekZrUHo4bXdWZ091cmUrVnFtRHBBbnE4eDB2T0FiYTBZeGFaWTJoWGJl?=
 =?utf-8?B?eTZQeXA1OHhwT0Z0Wkc3MkdvckdvS1hqelp0WEpsck8zRm4zOTJrK3ZneXhp?=
 =?utf-8?B?QmdDdXA3UWgxNGIwVlNjSHNNYWVGRFpZSUpCRlV5NGJ1eXJtQmV4SElwNnMr?=
 =?utf-8?B?eWNkaWM5U2lMZDNOZExUbnJQRVhEUGg0c3V0Snd5bnZ5d3E3cGRNL3dFdUox?=
 =?utf-8?B?czRoZGJuSEkxdWdWVmsyWVNXdUFhOXlTc1QrdXNxOHBkaXZUdDhEbEtNYXR6?=
 =?utf-8?B?ZFBaUzZMWjZJdTJUK2ZyR2RRL1dkVEtnN3NNRGIxSFdrVkQwVFFvVHB6MDJC?=
 =?utf-8?B?dUh5VndkWjBJTTQrLzZWejNxWXNaTHpWcEhuRjQ2L2tKVFltaGoreVhhbWFX?=
 =?utf-8?B?Q2FwQjNZL3UvWFIvYUk5d3MyUDltK3M0VTU4eXRQS3N1aWozSU9kMUZDaWRm?=
 =?utf-8?B?K1NlMkNZUkpMbml0aGFuZzJLNWpNajhpd1RJT3VOcVJxOTFkbFY0Qkl2VHoz?=
 =?utf-8?B?bWNmRHE1ZllyYVAyK24wYzFQZXpiZGNsclliS1A0dW5kQkJ6YzBTRndJQzFH?=
 =?utf-8?B?Q2FTK0FJTEo3dFZPV1A2RHd5VG9vdk9EQUZ2ZTRMZjBjQm5XbVhSUkM5Z1Zk?=
 =?utf-8?B?OExiSHdHNHFmRlhOSHVXa3lBby9qVFYyQm91SlhDbUtLSkJIeTJncFBVM3ZY?=
 =?utf-8?B?Z0JWb2dROXIvRUpOTDJ5My8vN0V2dkNOSnoyaGEvMGUwejQ1Wjh6VlErZmNu?=
 =?utf-8?B?cEw1bjFZY3N4UWdjRVBMQjkva3lhN2IvUmpVRlBYYkRJcmRQWXdvRVVOUGRh?=
 =?utf-8?B?NlBmVm9pWVVvcGJBSGJGN3B2OWdQZysrUnJkYVNDNk0wdTA2L1ZpdGY4NnA1?=
 =?utf-8?B?UlZKU3dBN3U3emlVQ3Rha09rM2NNSFJ0aXU3Z0h5eWphTXNEdFdXNTdxSmVR?=
 =?utf-8?B?aTRNK0g5UjVqTXhsYjZYOTRUcUFTWXF2SzhPdWpDQmFSMzdrRWVIdE5WWFhn?=
 =?utf-8?B?N3FtckdORzdTWlhyTk1oazI1ZU84WGhxVG1oeTFHU2hZYXFNWVdjNkxQcENY?=
 =?utf-8?B?S2VEOGRwa1lNYTkrRkxsZmhDQmlkR05INW4yWjhGM05GUDR2VEIvVit1Ujl0?=
 =?utf-8?B?TkJoT1RScXF0YVc1Q21tUC9zSWtnRzlTYVRUVExQcm5nR1pLRlgybDF6VzdF?=
 =?utf-8?B?eUhOY29la0h2ekhiVVI2VTBPSUlWSzRuNVJQczlCL0VxTCtkZk5nUmpKZ0tm?=
 =?utf-8?B?SFpKVXNqTVVkWm5rVmJlMThMcnVSYS8rd0pZMU9ma2RyUTdYdUVtQUFoZ296?=
 =?utf-8?B?UEhqNkpvZmxSSzhkaDBMMU9iK1lwRkV0VVVmQXBPd3NsbG8vTmdVcjlmbUg3?=
 =?utf-8?B?cVRKMWk2TmxCdkREQ0d4dTVaeVZaRVFpNk4wbnZtU0tlMlJGdm04TGhSZkEw?=
 =?utf-8?B?T01CK1RzRVlraGdzZS9kZmUzYXBCekE5TTNmWnFSNWs1OE94TTB1U2g0YTkv?=
 =?utf-8?B?STRlNUZ4dWgvRHpoY0x1OVIweUh4UmE2NmJsM2V1akp5aHk0RkxSY3Y3dEpV?=
 =?utf-8?B?Yzk4bkdUSVRpNy9BcVdIUUVpaHlDUmR4SEhwa1RDem9NdnM4ZHVWdTJFRVFK?=
 =?utf-8?B?a3lXMit3Qi9BZFNzSW9BRngyUFpnM0l0MzFlbWRiTk02UHBYNGtSUlI4UjZG?=
 =?utf-8?B?Rkhrd3BzSE1hRGl0RVcxTVMwcVEvSW9mbjMzbGMrTytZL0h4a25ESC9JT1B5?=
 =?utf-8?B?eW5DTUxNQzZMWUhIVjRMeWkwdVJNZU8vQUIxZWRscmh2WW8yN1hTcER6THdP?=
 =?utf-8?B?NEE9PQ==?=
X-OriginatorOrg: oss.nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c232b71c-5441-4da1-0bb0-08dd1f747abc
X-MS-Exchange-CrossTenant-AuthSource: DU0PR04MB9561.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 14:58:49.5868
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: cNA40Eq+vXiJL1Hu8PukRXtWKXSWPcLBJqV/CmQwe4kWoBbPL0ihaac8F2pNfkiJiZbworYJIetIKQ/8OUCyUhRo4RAAoNT3bOVY8TPuWg8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR04MB8811

Hi Michal,

Thank you for the review.

On 18/12/2024 16:26, Michal Orzel wrote:
>
> On 18/12/2024 11:11, Andrei Cherechesu (OSS) wrote:
>>
>> From: Andrei Cherechesu 
>>
>> Introduce the SCMI-SMC layer to have some basic degree of
>> awareness about SCMI calls that are based on the ARM System
>> Control and Management Interface (SCMI) specification (DEN0056E).
>>
>> The SCMI specification includes various protocols for managing
>> system-level resources, such as: clocks, pins, reset, system power,
>> power domains, performance domains, etc. The clients are named
>> "SCMI agents" and the server is named "SCMI platform".
>>
>> Only support the shared-memory based transport with SMCs as
>> the doorbell mechanism for notifying the platform. Also, this
>> implementation only handles the "arm,scmi-smc" compatible,
>> requiring the following properties:
>>         - "arm,smc-id" (unique SMC ID)
>>         - "shmem" (one or more phandles pointing to shmem zones
>>         for each channel)
>>
>> The initialization is done as initcall, since we need
>> SMCs, and PSCI should already probe EL3 FW for SMCCC support.
>> If no "arm,scmi-smc" compatible node is found in the host
>> DT, the initialization fails silently, as it's not mandatory.
>> Otherwise, we get the 'arm,smc-id' DT property from the node,
>> to know the SCMI SMC ID we handle. The 'shmem' memory ranges
>> are not validated, as the SMC calls are only passed through
>> to EL3 FW if coming from the hardware domain.
>>
>> Create a new 'firmware' folder to keep the SCMI code separate
>> from the generic ARM code.
>>
>> Signed-off-by: Andrei Cherechesu 
>> Reviewed-by: Stefano Stabellini 
>> ---
>>  xen/arch/arm/Kconfig                         |   2 +
>>  xen/arch/arm/Makefile                        |   1 +
>>  xen/arch/arm/firmware/Kconfig                |  13 ++
>>  xen/arch/arm/firmware/Makefile               |   1 +
>>  xen/arch/arm/firmware/scmi-smc.c             | 166 +++++++++++++++++++
>>  xen/arch/arm/include/asm/firmware/scmi-smc.h |  46 +++++
>>  6 files changed, 229 insertions(+)
>>  create mode 100644 xen/arch/arm/firmware/Kconfig
>>  create mode 100644 xen/arch/arm/firmware/Makefile
>>  create mode 100644 xen/arch/arm/firmware/scmi-smc.c
>>  create mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h
>>
>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>> index 604aba4996..23dc7162a7 100644
>> --- a/xen/arch/arm/Kconfig
>> +++ b/xen/arch/arm/Kconfig
>> @@ -271,6 +271,8 @@ config PARTIAL_EMULATION
>>           not been emulated to their complete functionality. Enabling this might
>>           result in unwanted/non-spec compliant behavior.
>>
>> +source "arch/arm/firmware/Kconfig"
>> +
>>  endmenu
>>
>>  menu "ARM errata workaround via the alternative framework"
>> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
>> index e4ad1ce851..8c696c2011 100644
>> --- a/xen/arch/arm/Makefile
>> +++ b/xen/arch/arm/Makefile
>> @@ -6,6 +6,7 @@ obj-$(CONFIG_HAS_PCI) += pci/
>>  ifneq ($(CONFIG_NO_PLAT),y)
>>  obj-y += platforms/
>>  endif
>> +obj-y += firmware/
>>  obj-$(CONFIG_TEE) += tee/
>>  obj-$(CONFIG_HAS_VPCI) += vpci.o
>>
>> diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig
>> new file mode 100644
>> index 0000000000..817da745fd
>> --- /dev/null
>> +++ b/xen/arch/arm/firmware/Kconfig
>> @@ -0,0 +1,13 @@
>> +menu "Firmware Drivers"
>> +
>> +config SCMI_SMC
>> +       bool "Forward SCMI over SMC calls from hwdom to EL3 firmware"
>> +       default y
>> +       help
>> +         This option enables basic awareness for SCMI calls using SMC as
>> +         doorbell mechanism and Shared Memory for transport ("arm,scmi-smc"
>> +         compatible only). The value of "arm,smc-id" DT property from SCMI
>> +         firmware node is used to trap and forward corresponding SCMI SMCs
>> +         to firmware running at EL3, for calls coming from the hardware domain.
>> +
>> +endmenu
>> diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefile
>> new file mode 100644
>> index 0000000000..a5e4542666
>> --- /dev/null
>> +++ b/xen/arch/arm/firmware/Makefile
>> @@ -0,0 +1 @@
>> +obj-$(CONFIG_SCMI_SMC) += scmi-smc.o
>> diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-smc.c
>> new file mode 100644
>> index 0000000000..62657308d6
>> --- /dev/null
>> +++ b/xen/arch/arm/firmware/scmi-smc.c
>> @@ -0,0 +1,166 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>> +/*
>> + * xen/arch/arm/firmware/scmi-smc.c
>> + *
>> + * ARM System Control and Management Interface (SCMI) over SMC
>> + * Generic handling layer
>> + *
>> + * Andrei Cherechesu 
>> + * Copyright 2024 NXP
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +
>> +#define SCMI_SMC_ID_PROP   "arm,smc-id"
>> +
>> +static bool __ro_after_init scmi_support;
> I don't understand the need for this variable. IMO it's useless, given that in next patch you do:
>
> ...
> if ( scmi_is_enabled() )
>     return scmi_handle_smc(regs);
>
> return false;
>
> which could simply be changed to:
> ...
> return scmi_handle_smc(regs);
>
> and the variable, functions for it, etc. could be removed which would simplify the code.
>
> [...]

Well, I agree that the code would maybe be simpler, but
that means we would call `scmi_handle_smc()` both when
SCMI-SMC layer is initialized and when it is not.

That then means that if `scmi_handle_smc()` returns false,
we won't know in the caller if the SCMI-SMC layer is not
initialized at all or if it is initialized, but the SMC
request is invalid (it does not have the SMC ID we expect).
Do we need to, though?

But even if we're not exporting the internal status of the
SCMI layer (enabled/disabled), the driver itself needs to
have an internal state to to know if it's been correctly
initialized or not, right? Otherwise, how would we know
internally if we can actually handle a SCMI request or not?

Well, we could manage to base this mechanism entirely on the
`scmi_smc_id` variable (i.e., if `scmi_smc_id` is not 0,
then we know the SCMI-SMC layer is initialized). This could
work as long as this handler is not called in a situation
where the ID of the SMC we're trapping could actually be 0.
And it currently would be not, since FID == 0 is reserved
for Arm Architecture SMCs.

So, I agree that it makes the code simpler in some sense,
but it will add some underlying assumptions and make it
less explicit.

I'm happy to implement your suggested changes. But I need to
know that I understood correctly your comments and that you
agree with the implications I've stated above.

>
>> +err:
> CODING_STYLE: this should be indented with one space.

Will fix.

>
> ~Michal
>

Regards,
Andrei Cherechesu



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 15:11:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 15:11:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860542.1272554 (Exim 4.92)
	(envelope-from )
	id 1tNvhk-000694-Q8; Wed, 18 Dec 2024 15:11:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860542.1272554; Wed, 18 Dec 2024 15:11:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNvhk-00068x-NM; Wed, 18 Dec 2024 15:11:16 +0000
Received: by outflank-mailman (input) for mailman id 860542;
 Wed, 18 Dec 2024 15:11: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 1tNvhi-00067Y-VW
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 15:11:15 +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 5272a0c2-bd52-11ef-a0d7-8be0dac302b0;
 Wed, 18 Dec 2024 16:11:14 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-43635796b48so6053205e9.0
 for ; Wed, 18 Dec 2024 07:11:14 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43656b01fefsm23752915e9.18.2024.12.18.07.11.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Dec 2024 07:11: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: 5272a0c2-bd52-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734534673; x=1735139473; 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=ESBXjJKdyeviMwknJZQygCKQt0UNyn+8eReM75yQv4c=;
        b=RCc2q0+9exQ3dNBuN2DbLD83wvukwoVwHQEEPUDK17/sZ03YRsyOOrwpvzC7Dq57Nq
         a8F0Xd+JOuYH3htV+NwzbPT3+aiRLIjIxoZ2xkxTZPeQY6OOHKTQ6X+kl9+3+xJv07NW
         eOrjTGyzmfEyFEzAQWzAzi9aASWirchl484uw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734534673; x=1735139473;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ESBXjJKdyeviMwknJZQygCKQt0UNyn+8eReM75yQv4c=;
        b=HXXugFqSllaL5JBNWw2VVXhZF2vRv8ThvA23RK9zn6KaasUVGGI2GvBiSoFMmASka1
         ALKzPJUw9cN+oLSnl52qmfjkkt4dDwAJbwFKgESd1kAoXjGIdSURGPCJEw1rn2iQNdPd
         eivdfYg1VXC1OK2EDt3Ma3Z5x5Li6Rtyi9EoA0M8bHAFmkbggh+0ZF880Ik+nhJZ9fPr
         dfkWZ2fMgKqKv25WzNqg3DJF7hHm215FWVTBy8FjtgQrwZtqBPA2f8qMlzhjiS1mBQmq
         g/iYKCuhcYssa5URBYpvn/QP1mdM/vmNKrGRzb8AzrKEGPTB2aTeaWJzylFySogvVW/6
         WfUg==
X-Forwarded-Encrypted: i=1; AJvYcCXjt4DRfTZVUuXg7wjNHOiLojfWkHygx3pVE9JIztWKnaesClUz3sOc9/wXbOQDTjJfKc7wChW/oxg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyaPlBdLwJVOko4ZAxdJMwaVVUBJjcXbNjoF/ODszkJlknp/tom
	Aw/h/xubEyyObnD44Fy+vmCbEla6dwClfXWzBZlK3F9PJGFzFDLPSULh6Yv40r8=
X-Gm-Gg: ASbGnctCGEf5w3TLjKqOf32cY7MvKgvHA49M3nJD0PGRU+MoYoYhHY6HNVLwUXs23FF
	MYl2pihTK6MuKsiUjuh8fn0r50Odxlltjs1ROZfQBPA54aDbNVEnVj7lK2hwkoEo+/GqrIyrPXi
	3IH2H1LBuf5Hh45MJxqZV65LnXsCOI7/M+YW2nWKvbGEBQ4O9CtoSVqDkKlyhlOftKthaMz76gd
	iBQkpo+v5A+AfZKVdhXku1m1o9wtQEJFqkHLLF3lfdNn27nDvoS/52aaOVPMEzd8KGYKz8Th8sz
	KqACxSVxq7jjNkXHlVY4
X-Google-Smtp-Source: AGHT+IEkXbYqqTzpwF8+hUdcb9z1RfX42EMnjNLzupu3pnyxOnZ/xbsl8qTb54brQ58lnD0Uvz+bdg==
X-Received: by 2002:a05:600c:4686:b0:436:1b86:f05 with SMTP id 5b1f17b1804b1-4365537640emr29113215e9.11.1734534673342;
        Wed, 18 Dec 2024 07:11:13 -0800 (PST)
Message-ID: 
Date: Wed, 18 Dec 2024 15:11:12 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/6] xen/arm: firmware: Add SCMI over SMC calls
 handling layer
To: "Andrei Cherechesu (OSS)" ,
 xen-devel@lists.xenproject.org
Cc: S32@nxp.com, Andrei Cherechesu ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
 <20241218101142.1552618-2-andrei.cherechesu@oss.nxp.com>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20241218101142.1552618-2-andrei.cherechesu@oss.nxp.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 18/12/2024 10:11 am, Andrei Cherechesu (OSS) wrote:
> diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-smc.c
> new file mode 100644
> index 0000000000..62657308d6
> --- /dev/null
> +++ b/xen/arch/arm/firmware/scmi-smc.c
> +bool scmi_handle_smc(struct cpu_user_regs *regs)
> +{
> +    uint32_t fid = (uint32_t)get_user_reg(regs, 0);
> +    struct arm_smccc_res res;
> +
> +    if ( !scmi_is_valid_smc_id(fid) )
> +        return false;
> +
> +    /* Only the hardware domain should use SCMI calls */
> +    if ( !is_hardware_domain(current->domain) )
> +    {
> +        gprintk(XENLOG_ERR, "SCMI: Unprivileged %pd cannot use SCMI.\n",
> +                current->domain);

Minor points.

gprintk() already renders current at the start of the line, so you don't
need the extra %pd.

I'd suggest simply XENLOG_WARNING "SCMI: Unprivileged access attempt\n".

A double "SCMI", and trailing punctuation is not useful in the log.

However, I'd also suggest using gdprintk() because this is guest
trigger-able and not interesting to see in a release build.

> diff --git a/xen/arch/arm/include/asm/firmware/scmi-smc.h b/xen/arch/arm/include/asm/firmware/scmi-smc.h
> new file mode 100644
> index 0000000000..57cc9eef86
> --- /dev/null
> +++ b/xen/arch/arm/include/asm/firmware/scmi-smc.h
> +#ifndef __ASM_SCMI_SMC_H__
> +#define __ASM_SCMI_SMC_H__
> +
> +#include 
> +#include 

You can remove the include of asm/regs.h, and simply declare:

struct cpu_user_regs;

here.  Nothing in this file needs to deference the pointer.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 15:20:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 15:20:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860556.1272565 (Exim 4.92)
	(envelope-from )
	id 1tNvqE-0007F3-HK; Wed, 18 Dec 2024 15:20:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860556.1272565; Wed, 18 Dec 2024 15:20:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNvqE-0007EY-Ed; Wed, 18 Dec 2024 15:20:02 +0000
Received: by outflank-mailman (input) for mailman id 860556;
 Wed, 18 Dec 2024 15:20: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 1tNvqC-0006zz-Me
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 15:20:00 +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 8be80132-bd53-11ef-a0d7-8be0dac302b0;
 Wed, 18 Dec 2024 16:20:00 +0100 (CET)
Received: by mail-wr1-x431.google.com with SMTP id
 ffacd0b85a97d-38637614567so3086237f8f.3
 for ; Wed, 18 Dec 2024 07:19:59 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c8046ca6sm14535710f8f.83.2024.12.18.07.19.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Dec 2024 07:19: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: 8be80132-bd53-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734535199; x=1735139999; 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=If0d0ZTvsDsHdpOWQjvwSqEk84/R6f2ktCgvtQ4+QmA=;
        b=prjbC4ompzs1fDyOtWcNy59T3ZK6CEwMPjl1gHyHgbalgWStezpq/jozs5pkBMoFAP
         WQU3DQUuIKko+HV4ywcHKn8Dcr/WNfm5V7lfC6t5fT9IAZyM3KVXrwTUXaHiawpsW4op
         ItQC1uXMTSGZyKzGKCXljjPP9M9YT4QzAUamM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734535199; x=1735139999;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=If0d0ZTvsDsHdpOWQjvwSqEk84/R6f2ktCgvtQ4+QmA=;
        b=qc6azL6tWbnI458N+iDjafRA8Y7hUQel7jEmMZ6xO2kTeJonamsl6Kl/0/Xy2y1D2v
         XIkNwXsyNXSZngqoD4PRvnCOFWW/tSy7HjzMlsa05vLOiwxkDfKLkXbLQTv2sPTCHu6z
         YEChJv7IbRfkFpged6WI0RvC/2lxOvJKhEVtfrLmhStd3Ti1Ru5HLyTC7b2BqD1Rknln
         VxkZCPnWYip2JEwQXb/vyNndfIe1OYbzXF9dNwxd7DO9juH/HxUehRFVkYg6np72WWZS
         8YH096M4MfDwJasw10/0OUR2klxo55+pGMdLtXi03g9b+nqNptKiQQ7dg6wHBSGCP4IP
         Z/jw==
X-Forwarded-Encrypted: i=1; AJvYcCWVivI8Bm/a8wuQmFK81slSu5QomIXr739jUJev8nBs0tu6zsxugp7P8a785JGBLYsNRgBXUrPLUM8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzDfUpDIpfUhsDuba5CVCbtCUEKVerdksWwgGlSF8isgjj/1TI7
	ZCuoIzHZmWc1wdU9Pz8KnMRaVBZKzFTKNrUKH4qAmg1SKmSZjgv1qDi8hquorS0=
X-Gm-Gg: ASbGncvttFftheXsHLNYdExqUMif/G++zjWMI/VJhuobakDSWvI1biq8yex4jOyQF3H
	zm6J/BZ+Yz1cyDBw0ySYXJLlR/88vLey0gPpM69baeRGIJKiQ9LeGapmhGf5tGCcurYp486PtmU
	zrNkfjO2HJBU1m7ZIX+OQd6o85IS/daIp+CMIQ87gHsb658GaGAx4lZ5WCeS9EzUmgkifpQNiu8
	OXDYKIZU5qYwiV9dosEkBI+Xi52MVrQ5Hx43BqGc13x0rcmdL63gRPIb7/rh5d/yaDhNH66cKxG
	cXgKo7TmN3bFe/+k1zAy
X-Google-Smtp-Source: AGHT+IEMhMYUZNHcFSQJC4Q3OY5VOzk77Flnp60W6TsMV0R9ca17hwpmYCysQuSO2UXX1GjYfMIesQ==
X-Received: by 2002:a05:6000:18a5:b0:386:373f:47c4 with SMTP id ffacd0b85a97d-388e4d96cc2mr2900731f8f.49.1734535199373;
        Wed, 18 Dec 2024 07:19:59 -0800 (PST)
Message-ID: <8f1c342f-61d3-48f5-8311-a1162a20cb24@citrix.com>
Date: Wed, 18 Dec 2024 15:19:58 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3/6] xen/arm: platforms: Add NXP S32G3 Processors
 config
To: "Andrei Cherechesu (OSS)" ,
 xen-devel@lists.xenproject.org
Cc: S32@nxp.com, Andrei Cherechesu ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
 <20241218101142.1552618-4-andrei.cherechesu@oss.nxp.com>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20241218101142.1552618-4-andrei.cherechesu@oss.nxp.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 18/12/2024 10:11 am, Andrei Cherechesu (OSS) wrote:
> diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
> index 02322c259c..6dbf6ec87b 100644
> --- a/xen/arch/arm/platforms/Kconfig
> +++ b/xen/arch/arm/platforms/Kconfig
> @@ -37,6 +37,14 @@ config MPSOC
>  	help
>  	Enable all the required drivers for Xilinx Ultrascale+ MPSoC
>  
> +config S32G3
> +	bool "NXP S32G3 Processors support"
> +	depends on ARM_64
> +	select HAS_LINFLEX
> +	select SCMI_SMC
> +	help
> +	Enable all the required drivers for NXP S32G3 Processors Family

Minor point.  Help text should be intended by 1 tab and 2 spaces.  The
surrounding examples are wrong.

This can probably be fixed on commit if the series doesn't need a resend.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 15:20:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 15:20:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860558.1272574 (Exim 4.92)
	(envelope-from )
	id 1tNvqU-0008H2-Sg; Wed, 18 Dec 2024 15:20:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860558.1272574; Wed, 18 Dec 2024 15:20:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNvqU-0008Gv-Q0; Wed, 18 Dec 2024 15:20:18 +0000
Received: by outflank-mailman (input) for mailman id 860558;
 Wed, 18 Dec 2024 15:20: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 1tNvqS-0006zz-Ak
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 15:20:16 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 94463b92-bd53-11ef-a0d7-8be0dac302b0;
 Wed, 18 Dec 2024 16:20:14 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 18 Dec 2024 16:20:13 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 94463b92-bd53-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734535214; x=1766071214;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=5ZU7nivsx9rGmY87ls5w7v67pilxaQJXCsAGiyJzFhg=;
  b=m8r3ZjXYLJBj9mnk7WsINJWBR0uVeIwVBgiPffFgWafbFDcrXdt22ehS
   H5Gw92LCXO2Zy5UmmzqBmx8nN6mLlf7R09LFp+tkIQAQ8anLEve3dUoxz
   DvwshZkMKMsoUvzuJaowt9YX7cdP75/xow1mfXiagTZpWQT/PRByWX3lb
   w=;
X-CSE-ConnectionGUID: 9uTemquwRyWonSnk91icPQ==
X-CSE-MsgGUID: XwhabISzQgOr5jHEwoJx7Q==
X-IronPort-AV: E=Sophos;i="6.12,244,1728943200"; 
   d="scan'208";a="28234079"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"
X-Forward: 149.5.228.1
References: <20241214161350.70515-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216231128.211648-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241216231128.211648-2-Ariel.Otilibili-Anieli@eurecom.fr>
 
 <2f7a8a-6761b180-9a89-1d1363a0@43143421> 
Date: Wed, 18 Dec 2024 16:20:13 +0100
Cc: xen-devel@lists.xenproject.org, "Jan Beulich" , "Anthony PERARD" , "Luca Fancellu" 
To: "Andrew Cooper" 
MIME-Version: 1.0
Message-ID: <2f7a8a-6762e800-9b0f-1d1363a0@43215295>
Subject: =?utf-8?q?Re=3A?= [PATCH v2 1/1] =?utf-8?q?tools=2C?=
 =?utf-8?q?_xen/scripts=3A?= clear out Python syntax warnings
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 2987

On Wednesday, December 18, 2024 15:21 CET, Andrew Cooper  wrote:

> On 17/12/2024 5:13 pm, Ariel Otilibili-Anieli wrote:
> > On Tuesday, December 17, 2024 17:26 CET, Andrew Cooper  wrote:
> >
> >> On 16/12/2024 11:07 pm, Ariel Otilibili wrote:
> >>> * since 3.12 invalid escape sequences generate SyntaxWarning
> >>> * in the future, these invalid sequences will generate SyntaxErro=
r
> >>> * therefore changed syntax to raw string notation.
> >>>
> >>> Link: https://docs.python.org/3/whatsnew/3.12.html#other-language=
-changes
> >>> Fixes: d8f3a67bf98 ("pygrub: further improve grub2 support")
> >>> Fixes: dd03048708a ("xen/pygrub: grub2/grub.cfg from RHEL 7 has n=
ew commands in menuentry")
> >>> Fixes: d1b93ea2615 ("tools/pygrub: Make pygrub understand default=
 entry in string format")
> >>> Fixes: 622e368758b ("Add ZFS libfsimage support patch")
> >>> Fixes: 02b26c02c7c ("xen/scripts: add cppcheck tool to the xen-an=
alysis.py script")
> >>> Fixes: 56c0063f4e7 ("xen/misra: xen-analysis.py: Improve the cppc=
heck version check")
> >>>
> >>> Cc: Anthony PERARD 
> >>> Cc: Luca Fancellu 
> >>> Cc: Andrew Cooper 
> >>> Signed-off-by: Ariel Otilibili 
> >> Having poked about a bit more, this is all a big mess, but these d=
o now
> >> work with Py3.12.
> >>
> >> leading \ for non-special characters are ignored in [], which is w=
hy ...
> >>
> >>> ---
> >>>  tools/pygrub/src/GrubConf.py                  | 4 ++--
> >>>  tools/pygrub/src/pygrub                       | 6 +++---
> >>>  xen/scripts/xen=5Fanalysis/cppcheck=5Fanalysis.py | 4 ++--
> >>>  3 files changed, 7 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/Grub=
Conf.py
> >>> index 580c9628ca..904e7d5567 100644
> >>> --- a/tools/pygrub/src/GrubConf.py
> >>> +++ b/tools/pygrub/src/GrubConf.py
> >>> @@ -320,7 +320,7 @@ class GrubConfigFile(=5FGrubConfigFile):
> >>>  def grub2=5Fhandle=5Fset(arg):
> >>>      (com,arg) =3D grub=5Fsplit(arg,2)
> >>>      com=3D"set:" + com
> >>> -    m =3D re.match("([\"\'])(.*)\\1", arg)
> >>> +    m =3D re.match(r"([\"\'])(.*)\1", arg)
> >> ... the \' works here.
> >>
> >> Anyway, I've checked the others and they seem to work, so I sugges=
t
> >> taking this roughly this form.
> >>
> >> Some notes about the commit message.=C2=A0 The subject ought to be=
:
> >>
> >> tools: Fix syntax warnings with Python 3.12
> >>
> >> The text should be a regular paragraph, rather than bullet points =
like this.
> >>
> >> I can fix this all on commit if you're happy.
> > Thanks for the feedback, Andrew; I'm happy with your changes.
>=20
> And committed.

Awesome, Andrew! Thanks to you!=20
>=20
> https://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dcommitdiff;h=3D826a9e=
b072d449cb777d71f52923e6f5f20cefbe
>=20
> Thankyou for your patch.
>=20
> ~Andrew



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 15:24:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 15:24:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860577.1272584 (Exim 4.92)
	(envelope-from )
	id 1tNvuh-00014q-EU; Wed, 18 Dec 2024 15:24:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860577.1272584; Wed, 18 Dec 2024 15:24:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNvuh-00014j-Bq; Wed, 18 Dec 2024 15:24:39 +0000
Received: by outflank-mailman (input) for mailman id 860577;
 Wed, 18 Dec 2024 15:24:38 +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 1tNvug-00014d-50
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 15:24:38 +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 2f41b763-bd54-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 16:24:35 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1734535465032784.0309698241986;
 Wed, 18 Dec 2024 07:24: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: 2f41b763-bd54-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1734535467; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=eHs31qdRs+en4moz92y5KoYh63NAklrVpF04eyNd8ZJSxV4WiM6r4rWbII6yDdGVKU5tLuXd5GEPuhlGtwTErgp7TIpRN+HSpazmR1eEhO5rybbCmsvZfSPfrsr5+QoOX9DketNzCwLL+GMQzZpzw4zc88f85WPwgAXfJ+8OaOU=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1734535467; 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=nzekv+dagWiXVVPf1hyvvkKH7M5iejRXQcHziW3FD00=; 
	b=RfgKrBNQACeJolQNk5xmU/qwk9KE6uFeNERlUMe5Gf/6uI3mZTkToHJvXb3mANqVGpO+D9bT2Q8SB2hl999eCYk/GNIUeOIHk/2QmxMPNDrOMjSsCBmfJmKFusORTzyRU5XrDR10gSFr5JBU40nQfO4VXlLAaWjY+Hgz/ShdXZA=
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=1734535467;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=nzekv+dagWiXVVPf1hyvvkKH7M5iejRXQcHziW3FD00=;
	b=vO13785I6IYEIMtsK+vOxIYt4o7CTc5OBrXFMCvSyMS851ApOjSt1CHF9LXTk4zQ
	WfLOKFOj2L7NeeuQEJxWsveS4BjffF93VEkHWRhn1Q2mxl9S688IDv5bXf35sbIk8Ll
	sGLffp2L2fdNLh1UMZext0uL+FnHhDACGDTeVrw4=
Message-ID: 
Date: Wed, 18 Dec 2024 10:24:22 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
To: Sergiy Kibrik , xen-devel@lists.xenproject.org
Cc: Julien Grall , Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini 
References: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
 <4e437c60-4fee-40ed-9d2a-789bac0b36d9@xen.org>
 <63b21760-7dea-423b-a9d8-64d213c40b2c@apertussolutions.com>
 <89e09a64-dafb-4665-adb5-be90fcc12646@epam.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <89e09a64-dafb-4665-adb5-be90fcc12646@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 12/18/24 05:04, Sergiy Kibrik wrote:
> 18.12.24 03:17, Daniel P. Smith:
>>> On 17/12/2024 11:47, Sergiy Kibrik wrote:
>>>> Allow to build ARM configuration with support for initializing 
>>>> hardware domain.
>>>> On ARM it is only possible to start hardware domain in multiboot 
>>>> mode, so
>>>> dom0less support is required. This is reflected by dependency on 
>>>> DOM0LESS_BOOT
>>>> instead of directly depending on ARM config option.
>>
>>
>> Just to make sure my assumption is correct, you are looking to do a 
>> multi-domain construction at boot time, with at least two domains. One 
>> of those two domains is the "control domain" and one is the "hardware 
>> domain", aka late hwdom except it's not constructed "late".
> 
> yes, you're correct
> 
>>
>> If you want such a configuration, I would highly recommend you first 
>> enable setting flask labels via dom0less (assuming it is not there) 
>> before lighting this feature up. This is because the dummy/base policy 
>> has no support for differentiating between a "control domain" and a 
>> "hardware domain". What you really would end up with is two control 
>> domains, with one also having control over hardware.
>>
> 
> will check this out, thank you for suggestion!

Apologies, one minor correction. You would get a control domain and a 
domU with the hardware mapped into its address space, not two control 
domains. I was not thinking about the fact that dom0less builds a single 
dom0, if defined, and all the domain definitions are built as domU.

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 15:28:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 15:28:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860587.1272594 (Exim 4.92)
	(envelope-from )
	id 1tNvyB-0001dB-Su; Wed, 18 Dec 2024 15:28:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860587.1272594; Wed, 18 Dec 2024 15:28: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 1tNvyB-0001d4-QM; Wed, 18 Dec 2024 15:28:15 +0000
Received: by outflank-mailman (input) for mailman id 860587;
 Wed, 18 Dec 2024 15:28: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 1tNvyB-0001cy-2o
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 15:28:15 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b1180822-bd54-11ef-a0d7-8be0dac302b0;
 Wed, 18 Dec 2024 16:28:13 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1734535682440665.1168973887374;
 Wed, 18 Dec 2024 07:28: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: b1180822-bd54-11ef-a0d7-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1734535683; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=QbEyCQaNltU3ja0SNrrdCtt+739ev9qitNiiGK2ST4MfryDitVYcR8ogGk4/nZpOgH95Ek580WJvLO6fDNUFVHmMxoiTJ3Okwp6JJIXem7GgLSpH9N9eItjvuVKUa67h5BR+Voc5KRdeHF8rElgCQWTI6TgxeoW0Z63fKX1RHhY=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1734535683; 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=+Rqs0nzbS1vWrlNelABBlpbx4rCRCOleHHNNPrWHr6w=; 
	b=FiP/Gk5GRSavKf/zPWNKgrPQdpDz2eZWyFjFpB+DhbvttGo+0Sx/9xYmsY7+g+ozXo8AJbW8k/fay1jubbNiAF2Yv9JByITDgJJyDDBScN3SigPLt1oa92JQEkRKcnJct9MyecFp7HEU8oajKRK9IGYTzyzN4lSQ0t9+afQFqmU=
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=1734535683;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=+Rqs0nzbS1vWrlNelABBlpbx4rCRCOleHHNNPrWHr6w=;
	b=dplNTrnhllkp2iu55uu9kyEwhJeGVOjgSdIMRtADC54yyCq2g5bw6Mt7Se/eW0wu
	ohGBEABZQMrpHAroObi2eZBBNs7fxPvtdhmp+1lqjRt3zo/exBJhKfu1hEXjnLHZyju
	oqIc+mAsMvkQE8qLatsYjxfykfpi+bG86zcuVWQ0=
Message-ID: 
Date: Wed, 18 Dec 2024 10:27:59 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
To: Andrew Cooper ,
 Sergiy Kibrik , xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini 
References: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
 <44db9406-f835-425f-b7b2-c86d14eb53d9@citrix.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <44db9406-f835-425f-b7b2-c86d14eb53d9@citrix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

On 12/18/24 05:24, Andrew Cooper wrote:
> On 17/12/2024 11:47 am, Sergiy Kibrik wrote:
>> Allow to build ARM configuration with support for initializing hardware domain.
>> On ARM it is only possible to start hardware domain in multiboot mode, so
>> dom0less support is required. This is reflected by dependency on DOM0LESS_BOOT
>> instead of directly depending on ARM config option.
>>
>> Signed-off-by: Sergiy Kibrik 
>> ---
>>   xen/common/Kconfig | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
>> index 90268d9249..7368ca8208 100644
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -374,7 +374,7 @@ endchoice
>>   config LATE_HWDOM
>>   	bool "Dedicated hardware domain"
>>   	default n
>> -	depends on XSM && X86
>> +	depends on XSM && (X86 || DOM0LESS_BOOT)
>>   	help
>>   	  Allows the creation of a dedicated hardware domain distinct from
>>   	  domain 0 that manages devices without needing access to other
> 
> To ask a questions not asked elsewhere on this thread.
> 
> We are expecting Hyperlaunch to supersede and entirely replace what is
> currently x86's idea of split control/hwdom, to this point where this
> symbol is even removed.
> 
> Has this plan changed?

In the long term, no. In the short term, the multi-domain builder 
introduces the means to differentiate, but there is still discussion to 
be had around how the dummy policy should/would need to be updated.

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 15:33:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 15:33:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860597.1272605 (Exim 4.92)
	(envelope-from )
	id 1tNw3R-0003c5-HC; Wed, 18 Dec 2024 15:33:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860597.1272605; Wed, 18 Dec 2024 15:33: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 1tNw3R-0003by-Dr; Wed, 18 Dec 2024 15:33:41 +0000
Received: by outflank-mailman (input) for mailman id 860597;
 Wed, 18 Dec 2024 15:33: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 1tNw3P-0003bs-Ru
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 15:33:40 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20601.outbound.protection.outlook.com
 [2a01:111:f403:2613::601])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 72bd7f35-bd55-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 16:33:37 +0100 (CET)
Received: from DUZPR01CA0180.eurprd01.prod.exchangelabs.com
 (2603:10a6:10:4b3::14) by AS8PR08MB7943.eurprd08.prod.outlook.com
 (2603:10a6:20b:53b::21) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Wed, 18 Dec
 2024 15:33:34 +0000
Received: from DU2PEPF00028D10.eurprd03.prod.outlook.com
 (2603:10a6:10:4b3:cafe::21) by DUZPR01CA0180.outlook.office365.com
 (2603:10a6:10:4b3::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.21 via Frontend Transport; Wed,
 18 Dec 2024 15:33:34 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DU2PEPF00028D10.mail.protection.outlook.com (10.167.242.24) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.15
 via Frontend Transport; Wed, 18 Dec 2024 15:33:33 +0000
Received: ("Tessian outbound 7762b28e8285:v528");
 Wed, 18 Dec 2024 15:33:32 +0000
Received: from L6c2ca8def663.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 F5F8EA2C-0454-4610-B4F6-C9B7A214FD3C.1; 
 Wed, 18 Dec 2024 15:33:26 +0000
Received: from OSPPR02CU001.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 L6c2ca8def663.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 18 Dec 2024 15:33:26 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by PA4PR08MB5902.eurprd08.prod.outlook.com (2603:10a6:102:e0::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Wed, 18 Dec
 2024 15:33:23 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 15:33: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: 72bd7f35-bd55-11ef-99a3-01e77a169b0f
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=rHt0/fgkuR4mRojim33k9bP36lX2k8weuHfzt8Yx4caIZPir+HrQA1qXBWk7RZu5jZx5Yfe6/YKmwB5fxfD2JXOUQdSX5RZ/UGV73Obzm6+2gsM/1wlqh8broK7gJjD4Ol0vLlt3emXcWPFgULTcN7CmKWkIWoEjlvKFmSmT6paSbszJHWZpTSMt4R74CIVhHhXphLLz/KZuLT3PLsYC2HWZAygNMtKdw6qYAc/YJoNN3nVkpPo8G1UtyFSQ1alQXoYGpYmc2ppUdoy4QRoZ6FMLFc/dUcG89NyKNgEb15XvX2feTmYR2TLdZymVxmaRQnrhyjk784QhIaVPXVn/8g==
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=oeF69qxkFVgxp6FBZGWYzoDZGDPSxyXVHeQUalW1vBw=;
 b=MncqRTuSu83Mx+RKxQjyEUNRZQrEafxwb059y6lGsY4bcf8AwE2ZEg8Oslqy5a9FHgVESCy1zjuV8O/dCGfEgTSyd/Bcj0QhNqI4fomCWwOkEQb+S8bx4spESRKLJHyEPzACO28HvTQcQM8GG8LaffpO1HdeDovQK0UFUerD+K9uBvytyH6SY8agGhBnJB0o2INEli3ejnJ9g1caqz055ZpITFI1kifRTHuBKE0otL9lz8QimGyezh/oxF5rQEulbCB55+TGh3SwXaEjnFUzLvrhLTvaMXgkim1j87yNjoN4BbrYuQ2eZLSj0wwiQ6DEWu0chRKjIyUTe5bBV+nfhw==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=oeF69qxkFVgxp6FBZGWYzoDZGDPSxyXVHeQUalW1vBw=;
 b=bQBrKkPcJmJhO2/MxZfoyXM2w0jW0r88CwwZiK3TTdE7ZpV8gZojFUBiUfkbze0TAk7MZqtUXSpgiz4OEAXuinS4meqPiJIDEWyIC3oxCEBpW47IAKe3I87pJkgsGBlt7/N19rJ5PB2RQ3SEyF+gkfetLsxCsBENm23L0kFKC+E=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 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
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 83d89a49479e711d
X-TessianGatewayMetadata: QBZfLWm0Pb+bVbzVOVtsYXQwMDntwmEJwldjSGGum+ryoezT+OsgOfjyyKn0QlJr10UWG9ClM80MoGqj/cXPpUoXOJpB9u7hVOt/9SUhYu7zaDq+9RQyjoxKqGKCSccCbzQKkpic7nHPZlucfbtARa0iYVvmXIabpQ6ZJQ2aCXU=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=nM3drWsxZY9QuqOFzB9TYmO7f9poxOvhscZJ4u3g1lcTFBuxpQRsyzUt7Lj7vAhOYNqhcXG7vm6g7A62JBu8dFsSE/AmjE/ewXlwERbw+VX6XATiMvKim6/ArBk1pzF5QPOfb5dhBn0GwcS7Oaa8T5XAIpVwkBd5vqNxn773Y8vGL6LGGceBXpH9OMlz6UYO1ajXoV5ktjwB2TLt/GzxfSARd/oh0Soqv1+QHgp+T0SvCtSH+FvSILLga+DhS5AGJkXJbDy55kAq7ED75kX3gNq9FDC5H0ZE1K203jtTmP67jMdtxtizKij0O7SehXt6hG8nCmKBkHVUFmABg61vYA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=oeF69qxkFVgxp6FBZGWYzoDZGDPSxyXVHeQUalW1vBw=;
 b=isS/2QxL42jVd0/+sFAA9BvWsPPydqYM6lyZBTQ1YsjuLmAnqpUj40M5A44ZQ4kKxI33peV8lAKU0k/hJwOLCMyYTl8ZX38H9DVIiAPaZihI7pRJ5HiJnqd4YFb7UnpWt+Itb1ziAfiYyicbquvVmEXoaAsGwL9MqaCW6Z7+T4TudRdVEV/uT5inDrgEFpUK2+JAAxTR1MKiF9x20Q94UqYhglfMbSRB01xlL4t9URLbq0pI/j3x6blKGr5LCP9gF4E94mF7geGtJ37tinax+CEKRb/wgsgScQJqcF5CuBuki1Kg3TbofhJ4mC+8W8taYEB0LTEJZT33jZ3K//3qqA==
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=oeF69qxkFVgxp6FBZGWYzoDZGDPSxyXVHeQUalW1vBw=;
 b=bQBrKkPcJmJhO2/MxZfoyXM2w0jW0r88CwwZiK3TTdE7ZpV8gZojFUBiUfkbze0TAk7MZqtUXSpgiz4OEAXuinS4meqPiJIDEWyIC3oxCEBpW47IAKe3I87pJkgsGBlt7/N19rJ5PB2RQ3SEyF+gkfetLsxCsBENm23L0kFKC+E=
From: Bertrand Marquis 
To: Andrew Cooper 
CC: "Andrei Cherechesu (OSS)" ,
	"xen-devel@lists.xenproject.org" ,
	"S32@nxp.com" , Andrei Cherechesu ,
	Stefano Stabellini , Julien Grall ,
	Michal Orzel , Volodymyr Babchuk
	
Subject: Re: [PATCH v3 3/6] xen/arm: platforms: Add NXP S32G3 Processors
 config
Thread-Topic: [PATCH v3 3/6] xen/arm: platforms: Add NXP S32G3 Processors
 config
Thread-Index: AQHbUTVdoMCMlYyvB0KhW/HQpIvTvrLsHi4AgAADtIA=
Date: Wed, 18 Dec 2024 15:33:23 +0000
Message-ID: <3FDFACF4-C998-496C-806F-530CA3C87622@arm.com>
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
 <20241218101142.1552618-4-andrei.cherechesu@oss.nxp.com>
 <8f1c342f-61d3-48f5-8311-a1162a20cb24@citrix.com>
In-Reply-To: <8f1c342f-61d3-48f5-8311-a1162a20cb24@citrix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|PA4PR08MB5902:EE_|DU2PEPF00028D10:EE_|AS8PR08MB7943:EE_
X-MS-Office365-Filtering-Correlation-Id: 96d80059-d1bb-4d67-64cb-08dd1f7954f9
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|376014|1800799024|366016|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?ukTIn/yrSirP+pMqXa7heuHiRvVO3X55ReIB0oK/GQpebn2RNQQV8aPxv6/c?=
 =?us-ascii?Q?ZViptNehWjEFLBGycn/8yrrSGN90fmViqeNjZoRKrxLYgi1BYDQ2CzAG5+E3?=
 =?us-ascii?Q?ql1S5Lnsc6jsT/9sNq8cRBrhnv6pSM2/Kfj6ZZUVQTWqmWAhzzcshnQU6M1z?=
 =?us-ascii?Q?8bNrJVFnTuRCh+COv8W3VlAD/LkBExD7pUl7Kz7w/auCB7iDwjFRbUPWEWZv?=
 =?us-ascii?Q?PWnLsm8HkES00WDj0u70KAY1C35CvO68oZUKuBjgvYXcFJ1aLJ7uH7LgcxHP?=
 =?us-ascii?Q?X5D8F5x2yZ0w4o21YfKR8xv2S0LquXxp68/mS0DnzOSfTk1aBmkMqTdKyV//?=
 =?us-ascii?Q?oKjuSInW7sOGzmSfW2xUduoP7ApU64wRL9xGbxSjZRHu++pi8Fuy2Wx1rGPP?=
 =?us-ascii?Q?LzaCW/uMJPKN3il3tBy24eZmg4Q/GIIGNglpIMWBgJVY7WEUgTB0Zloeu6wU?=
 =?us-ascii?Q?hQ10oF1ufDJvSm3Lsqa8w5Sgz2qprHkZ66TcvaiSvaNHNvk7NuzhiUwQM8b/?=
 =?us-ascii?Q?3PDikP51Q3KPJwLFaTIUtuUO0/zWYXDbqal6gbg+NlpK9bf9bFeAYsQa0Fsi?=
 =?us-ascii?Q?j2IwLUhStCuRWzFdWlSONGCsgEpyzv6n0ku627JpNkq26IsNx131LQ9LN/lp?=
 =?us-ascii?Q?Ru8g3LOyYyqUC+bhSG7vPIZlQNNmAY6vnrghq13hBRVljTN7D9LRdz/nBREx?=
 =?us-ascii?Q?45RvRlNlzul2csHW7k/5nJGouU0Q06tngyYDvpN1dSFKpQIh4F27n/BdkOr0?=
 =?us-ascii?Q?7sXd/1hDjHZWpZPR7jKvWZG3UN8Vd9Jxt1HPtgc022RtnE4H3si4qHAQNSio?=
 =?us-ascii?Q?UoPHzDYFDILhOWT5aCOhUUa63CYc9UZPBvZk4j9x5bErHHCLevBZWlvmH0DY?=
 =?us-ascii?Q?gyUdwXNvtFit0vDkviIPSl3T8vb47YCt1cTG6zWFnbXwFPySsZRQMItada9k?=
 =?us-ascii?Q?ru87f10q8xwtRzA+Yfe29NRSJrTSP+R2LRfcMO3x9GvyZAvg8rXGup98cT6L?=
 =?us-ascii?Q?81iwGWOMvoASflUtwc/ODyc6o15YQKADLRP5+1Cakz3Jx9vq+IroWuZ40Ink?=
 =?us-ascii?Q?WYIZNwTezM+HnWK//Mb+WYJD4je3AS8jSRkE7+hBEkgJmp15+SyimSxDotai?=
 =?us-ascii?Q?bZq6BVTNnl97067zRSnQAAEGix228F36gYf3vKUWM8U2blOKlwFIW4xLaPcF?=
 =?us-ascii?Q?dBXtGjzzHakE9YwFcL78WsHrrWsHWoyIKvYZoLjYxdL8svNL6GKHgyTrIOzp?=
 =?us-ascii?Q?hsnf9E26+9xzKjbilBNA2+mLgACpJn4QFGhg6/2FFNm0/4CCBam/hApwqv5B?=
 =?us-ascii?Q?hUGoX9nWggLuutL88Uu9EW5AJliiXQR/50DFpG8vxF5nRduGEpIV5omifcXf?=
 =?us-ascii?Q?n3Hn8RDsdpxaytnqWr6p/8JKH2Eu+LpZ0OXskwxpWG+YYCvcDTj7uxIUedQf?=
 =?us-ascii?Q?s2u//NFt7JoEfQdMx99EJsUBx5xyXPs5?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1750856CE4D3D543BEE400ADABAB4F22@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB5902
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender:
 ip=[2603:10a6:10:25a::24];domain=DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU2PEPF00028D10.eurprd03.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	9610bfa9-088f-408a-106f-08dd1f794f42
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|35042699022|14060799003|376014|82310400026|1800799024|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?QkI5cE17kwVwNQfF7R1Q+NpzFjUu8Bn6VLvnO6c+8klmD4pYkToCz+ETaoia?=
 =?us-ascii?Q?VZhTUZf5YBzmybhhT1JJ66LBskTDYgtm62+n4nSqBR2/lLItfX3ORVcOV5gd?=
 =?us-ascii?Q?9+KgGpno5qam45u0aYYHBuRsBet5UMW79n/oFuqoCgBuP1dPS19GVaj6poXH?=
 =?us-ascii?Q?reTe2DF25M2GKCWvbv3TT+P+Ptmq35fUQTz7yN6ShllySQHE2E+zJ76MtpDE?=
 =?us-ascii?Q?XwaNC7cpL1l21WmEHYaQ7Sy17gNGxxzt2yS+vNbyw28hpbxOvD3wKecfs/m7?=
 =?us-ascii?Q?OgxAJpqKcyDULjXPaQCEkAkVpufY1Ituz6ltUrLjruLRbh935fcv6mIL6hsR?=
 =?us-ascii?Q?GEw4FS5vBQVG26XPaKKc4lrVRIbzZFfuIIEVk746Pp9p3d/pyk6cQgzxXqXr?=
 =?us-ascii?Q?kyqUKztAYZmxEWegU22Nd9VU+RQeihrBFqllv9jKdk32cPi1KnNYavfSgMeo?=
 =?us-ascii?Q?Dly7G3QU4E4JT7jGip51Zt3z4Z3MlxTzCxOEvggAkUumd7wsWE8uXJ1/DGQz?=
 =?us-ascii?Q?HZdt+qRVCRKkTMZiipg/rl+e6l7P5Og6VuHOK8/FuKvAqA9SBCx1Ya3IkzkS?=
 =?us-ascii?Q?aMNKOy+L3OCcV2pJj1rxyndvF5av+QmH+DXnu5cDnFaM6OMpSCYR/Rsf/BDW?=
 =?us-ascii?Q?+4m3bkzWsxr2F0I+hF5lbek9OrA4ViIVLGlGuslrKS35SbxVTS0WjSP6kXbL?=
 =?us-ascii?Q?CixptpYc15hrwdZJQSNH5+tQm5XryWmc4nLxVpI+7T3EnxexAtj5bTP6XKvy?=
 =?us-ascii?Q?nY4Y27mZD47/w/ooJ+4VKOsyN7LwpIzASPG4piOt/c7jEODJTLqzXPl+AufL?=
 =?us-ascii?Q?x65IdH4sYoA6daJkYpfYCUY7N0FuJPNC6Jvr6uyhCWahu9YZeMi1zd5C3BHT?=
 =?us-ascii?Q?IO9Fybwk1FBfNZZ+a8vfhz4jKpN+ZUtp1ujvXFIWZ5yrxL48lmarbM9NNfFb?=
 =?us-ascii?Q?MrIhjObpVhpReFCcgGwqw8mXa5V0p+sBu8tmYOLw1pbS2PEWbKEcMXRx7rSM?=
 =?us-ascii?Q?/Glhu9NOv/sZSoBNXb0MgtsvlnqZYcTPSNLuI5WjNrAxeLuwba3emX2VYzOW?=
 =?us-ascii?Q?Gv0DSG5liZ9SNE0mDVh68BxG2Olw144T8lyf1kOUHnWAI8wDfIArSngLOdZE?=
 =?us-ascii?Q?t8dnwHM+yN4LvQIQdI5hz6WPBW6OTll4ODJwb2zpatXypPmCyte76KcaPoRy?=
 =?us-ascii?Q?65EBI5rahTSS6SyuSK6OF2W4zu/bvcaGUDq1tPBfenFvGoJBGWFgN3+V+Dl/?=
 =?us-ascii?Q?KVE95BH7Zd30HuBn/wSIFOjAJLx2H0o8rpo+DbTHiJSqRhJYSIbNNStHAjal?=
 =?us-ascii?Q?SZANHt+IxfKpSkHOs31U4cN7bgGsI1yWj3KVG2QqrhAzHirsJcImlmIpSVaU?=
 =?us-ascii?Q?9zY+cL1EOIh5KCMG+Ek5ir8Wsz3YOj/bD+kY1/9nQZJPC37nlcKyaRlHA5c8?=
 =?us-ascii?Q?5gP1A2P7c4o0Y83mFwI3hNvnkq0f75y+YmqDV3fBI52k/QzjayPTYa7gbetT?=
 =?us-ascii?Q?1wR7K2ON4u0WxbA=3D?=
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(35042699022)(14060799003)(376014)(82310400026)(1800799024)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 15:33:33.3456
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 96d80059-d1bb-4d67-64cb-08dd1f7954f9
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DU2PEPF00028D10.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB7943

Hi Andrew,

> On 18 Dec 2024, at 16:19, Andrew Cooper  wrote=
:
>=20
> On 18/12/2024 10:11 am, Andrei Cherechesu (OSS) wrote:
>> diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kco=
nfig
>> index 02322c259c..6dbf6ec87b 100644
>> --- a/xen/arch/arm/platforms/Kconfig
>> +++ b/xen/arch/arm/platforms/Kconfig
>> @@ -37,6 +37,14 @@ config MPSOC
>> help
>> Enable all the required drivers for Xilinx Ultrascale+ MPSoC
>>=20
>> +config S32G3
>> + bool "NXP S32G3 Processors support"
>> + depends on ARM_64
>> + select HAS_LINFLEX
>> + select SCMI_SMC
>> + help
>> + Enable all the required drivers for NXP S32G3 Processors Family
>=20
> Minor point.  Help text should be intended by 1 tab and 2 spaces.  The
> surrounding examples are wrong.
>=20
> This can probably be fixed on commit if the series doesn't need a resend.

All entries in this file are actually wrong.
I did not mention it due to this fact and I thought of pushing one change t=
o fix them all=20
instead once this would have been commited.

Cheers
Bertrand

>=20
> ~Andrew



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 15:54:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 15:54:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860610.1272616 (Exim 4.92)
	(envelope-from )
	id 1tNwNq-00071K-A5; Wed, 18 Dec 2024 15:54:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860610.1272616; Wed, 18 Dec 2024 15: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 1tNwNq-00071D-5b; Wed, 18 Dec 2024 15:54:46 +0000
Received: by outflank-mailman (input) for mailman id 860610;
 Wed, 18 Dec 2024 15:54: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 1tNwNo-000717-Fx
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 15:54:44 +0000
Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com
 [2a00:1450:4864:20::344])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 65baed62-bd58-11ef-a0d7-8be0dac302b0;
 Wed, 18 Dec 2024 16:54:43 +0100 (CET)
Received: by mail-wm1-x344.google.com with SMTP id
 5b1f17b1804b1-4361f65ca01so64516255e9.1
 for ; Wed, 18 Dec 2024 07:54:43 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43656b11aecsm23911925e9.23.2024.12.18.07.54.41
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Dec 2024 07:54: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: 65baed62-bd58-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734537283; x=1735142083; 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=Es7/MA9fgAC/sB1c1opN7VEF0sUUcoPUIXBfj61v5BI=;
        b=gWT0fDApF08UpkcLhy5iBSw4rceLn+7bG9UB+Ho99VsXTHSewLt181BUNPpHcKavvr
         i++hem01VOtb2nUD/QAiWQ0HTrXN9atw0akoSFdkDbZKZmHeACMrBvLAC1MQwAuW/xF5
         0hlqNtv8msApWoZxJn3c8q2+5Or4jJCa157vA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734537283; x=1735142083;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=Es7/MA9fgAC/sB1c1opN7VEF0sUUcoPUIXBfj61v5BI=;
        b=ctQSgPC++4r3r/wwZ47lPmv4xxS5TFVi8yxlRQaX9G8voEieI26voutUBpMoSJVgVm
         5h3Y78Cr8d47kNAIbdWLM1lYWLZzoNwWgaD3D6Jso0ApcQ6qol6n0zTgWWlksF2CH+NI
         QL+ee8U9scSVXTccZc/3Is0cxvehXoIaTVYWHWQ4UBpAPpfieQGVjyjpZd5YMYIG/uHG
         nYaaGuhdvxkWXmEV/U3VdbP35jJSzaflwJfegxowo4yel7KalPTsFOOrS9rXxS0Z9DCl
         97q1as+M49oXkA282RvE1nzTk54lJdrTCyYt2ZxobMCoBQkefUy5IbmRrPBfemqhUVuF
         9sPA==
X-Forwarded-Encrypted: i=1; AJvYcCUsb7rWSPD0ugdS2fmvVyV2BWZfXuQj+WQxl7IA9uyDvpQSLkGQAINi3SDXhOEVXrmavvjnvT9RqJc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxy3fynHVQ/HyhN3AyNU++Eze0N4JyO2Q3uOeujReoCiI2Ya0oa
	two0xBT/EmT4DRz0vBEW/bShpk8FHYINxDX3tj+NXi/HXByFscQdViHGEiABpmM=
X-Gm-Gg: ASbGncvQ2LWd/6lNM4xF9Y/bcTH/B84QQUvptGcxiD4R5cyTEAH9vS+VhnfUiy6uvii
	uDnjKY3BPaPJrMuitS/uoajorZvrTJmC5nLMLEnBGbwRQmnYzx/88JKGSTnb84tWGGiqexdwuZC
	nRX9e8raygJeRdf82P/hIS0kqpLyX8RHdN32Q2WvVdXrpitXnl+gz9K1BxdN2dDcyngugMmDLEM
	NIwl+qPNdmTXN2gNigTPmJh4xAkC9FLZO8fDIcgLV4A11EXuKguRmnA5hyeeUfb2nKj2UREIpS0
	MScA7YwL6pl0y/WnCpah
X-Google-Smtp-Source: AGHT+IFtLq7UhjfAQK7npEkzA8q5zLQfBFEsJSd5RYyccJKpjAF8ByPLR0TOUQlByW/pjrLudLYQhw==
X-Received: by 2002:a05:600c:1382:b0:434:a75b:5f59 with SMTP id 5b1f17b1804b1-4365534140bmr32529155e9.3.1734537282722;
        Wed, 18 Dec 2024 07:54:42 -0800 (PST)
Message-ID: <6a0ee425-96ce-4361-ad23-7f21c3398694@citrix.com>
Date: Wed, 18 Dec 2024 15:54:41 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2] x86/hvm: Use constants for x86 modes
To: Teddy Astie , xen-devel@lists.xenproject.org
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Paul Durrant 
References: 
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 02/12/2024 9:49 am, Teddy Astie wrote:
> diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h
> index 02de18c7d4..dbc37e8b75 100644
> --- a/xen/arch/x86/include/asm/hvm/hvm.h
> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
> @@ -26,6 +26,12 @@ extern bool opt_hvm_fep;
>  #define opt_hvm_fep 0
>  #endif
>  
> +#define X86_MODE_REAL  0
> +#define X86_MODE_VM86  1
> +#define X86_MODE_16BIT 2
> +#define X86_MODE_32BIT 4
> +#define X86_MODE_64BIT 8
> +
>  /* Interrupt acknowledgement sources. */
>  enum hvm_intsrc {
>      hvm_intsrc_none,

We discussed this in the x86 meeting.  These want to live next to
hvm_guest_x86_mode() with a comment stating that they're not
architectural modes.

During your work, you seem to have only looked at the the VMX side of
things.

There are several callers of hvm_guest_x86_mode() and
svm_guest_x86_mode() missed.  Also an unnecessary include, and a couple
of overly long lines.

https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=commitdiff;h=4f8f63d49776d69ed9a978b6601c13c54c579a98
is the incremental fix on top of this patch.

Does this look reasonable?


I've just realised that the check in nvmx_handle_vmx_insn() is an
incredibly complicated way of expressing guest_cr[0].PE, and we've got
the same opencoded elsewhere, so I'll also prepare a patch prerequisite
patch to sort that out, then rebase this over it.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 15:56:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 15:56:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860618.1272624 (Exim 4.92)
	(envelope-from )
	id 1tNwPH-0007XT-Id; Wed, 18 Dec 2024 15:56:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860618.1272624; Wed, 18 Dec 2024 15:56: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 1tNwPH-0007XM-G5; Wed, 18 Dec 2024 15:56:15 +0000
Received: by outflank-mailman (input) for mailman id 860618;
 Wed, 18 Dec 2024 15:56: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 1tNwPH-0007XG-48
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 15:56:15 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 (mail-db8eur05on2061c.outbound.protection.outlook.com
 [2a01:111:f403:2614::61c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 99e508b5-bd58-11ef-a0d7-8be0dac302b0;
 Wed, 18 Dec 2024 16:56:11 +0100 (CET)
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com (2603:10a6:10:312::7)
 by GVXPR04MB10271.eurprd04.prod.outlook.com (2603:10a6:150:1ba::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Wed, 18 Dec
 2024 15:56:08 +0000
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f]) by DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f%6]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 15:56: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: 99e508b5-bd58-11ef-a0d7-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=F7esPi9PMGUtfiQVDYZ8N8MQdRMZsRYTzCBNTO6BrwTf9evVMRf6Z4JnxC51jGCVDDNIGaH2iEQThWhq2/OCDsrgsIiz74XVagTh7tFkjqx8rnLiG8Zj7lXumYRpfBz+OKNkHh8DazSJNuVUXwZE0+2FZzCQOE44FzyjMUFYE+Bx52y8tc5R4J9qrKSXrfZHH/DA2FPKW7CRRiKhFmsvL38lvclP2EQqVw+iX7gG8BKywPlakSkyPuhyMBnBnChZETlJfxE6kabJMCw9aYSMutSavSQsJY9qKHqpe6ZMKrHEhzKFmWz+qFpGdBN0ttH6AYCn83VteKZH/pCEeGqkwQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=4JyZOShfVQAJqhnlrx0QGPcJpdSXxYIrA6vIR1iKnVs=;
 b=taAzQ54OAQL60ywrF8T/bKIPaNMFklh6oWwEGtWmYGg58cJ6zXwcYQH1Tv86jTAyMpUPFpO9CD+ReIFPQZVr1+qZys8mhh1SGWTzEWG8U99W9JLP1ovsvASLAmwH7hRsd8JNlQCdCJ96N1HtxifkHw1VuYcP0rURgHQ87lzrz1SU6vHydRVJS5IarP0v3/iftX1mVxd06K3WUK/JuMlwrWUKjPtOuYPhD2ddvCeQ5YNxfl4fpxIxsrC0brToZfY/4XK95VpWqrlC2sVP4sJ+YzfOirqeXxNlhNgJMkbKlZerVbRRgaiCmfjOzECXGv7S3whgpYY1EdmQnYn4Qqkb3A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com;
 dkim=pass header.d=oss.nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com;
 s=selector1-NXP1-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=4JyZOShfVQAJqhnlrx0QGPcJpdSXxYIrA6vIR1iKnVs=;
 b=nRTBuYHORjMQi1WaBjSFDUuDA4aswVVaU3y4d70o8FX1po0VzcIA10jsH395ISxwszKQwUHXCs/l9clRCf5BxKAdXG96AZZU4NJV44E9RU5os2qLsVDpAZD3mRByJDc4kdAX39YXoNXxHIsqc6GCggohuo2gzZ5BYgdFXMY3zDO5vAibXK+EFL1lbXZnEbuGBsNNm/dYJ+XGbFoz+MKRwCjuME3lW/jz/WkF/TSmBcGifrGl+Wq77SWSLCIfg/Er0xIMLiU4BUDsvVN5a6lL1kor5YZQZw3rIMsD4A3SCiphfQRTvTVkxAUYqAMlWGJ0cQpsuz+Zv9W0miN1OrFLJg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=oss.nxp.com;
Message-ID: <17240d6a-42bf-45fb-bb8b-2ad5aa1e855f@oss.nxp.com>
Date: Wed, 18 Dec 2024 17:56:06 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3/6] xen/arm: platforms: Add NXP S32G3 Processors
 config
To: Bertrand Marquis ,
 Andrew Cooper 
Cc: "xen-devel@lists.xenproject.org" ,
 "S32@nxp.com" , Andrei Cherechesu ,
 Stefano Stabellini , Julien Grall ,
 Michal Orzel ,
 Volodymyr Babchuk 
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
 <20241218101142.1552618-4-andrei.cherechesu@oss.nxp.com>
 <8f1c342f-61d3-48f5-8311-a1162a20cb24@citrix.com>
 <3FDFACF4-C998-496C-806F-530CA3C87622@arm.com>
Content-Language: en-US
From: Andrei Cherechesu 
In-Reply-To: <3FDFACF4-C998-496C-806F-530CA3C87622@arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: AM0PR02CA0007.eurprd02.prod.outlook.com
 (2603:10a6:208:3e::20) To DU0PR04MB9561.eurprd04.prod.outlook.com
 (2603:10a6:10:312::7)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0PR04MB9561:EE_|GVXPR04MB10271:EE_
X-MS-Office365-Filtering-Correlation-Id: 02ea7016-de1b-4c56-836c-08dd1f7c7c57
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
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:
	=?utf-8?B?NVdnQ2FXa3AyUU9Wai9zQytCTWtEVE1BM3Vaekd0VkZ4Q2sxZUNvNzRYR2w2?=
 =?utf-8?B?Z3B3eEZoajhJdmhZYmg4VkZ0YTI1TWVSQlhTYlFEenVwdFZTS3d6MHRXVTJS?=
 =?utf-8?B?cnoxV0JIMUZCTVhDOVdNbTVWeFo1Z2Z1U3JRdFBHK0d4cGUvdHRvTmVwckly?=
 =?utf-8?B?UFNrdXdyK1d0NTBid1hSRmFTUXpWdUR2NTc4ZXNCUW9tZE5nSkpzVzRGdE81?=
 =?utf-8?B?TEF3RDlseEJOZmZCRGovd3BJcmJwcjNEM21nWWhJYmVQbHQrc28wZXBmTWty?=
 =?utf-8?B?UXNLU3NENDdZMFRvNmhwYnFyZW5uQTI0enNZOTRxdm5GWU8xOGlzdWoxcXRU?=
 =?utf-8?B?RjNrdHZFeHZnQjJ5c0V6WmJHTmpTT0ppbWhJQWdoamprNUUvSENhck85VEUw?=
 =?utf-8?B?aERJQnBjWW1wbnFCU0x2Q0JDTlJSVktUWHVZejZIM1U4aXVtVUsyWFNDaDA4?=
 =?utf-8?B?eFJKYkRFUi9Qa0pIRUpLV2srdU12WjdwQXlEM3pLTDJHb1M2QXEra2M1ek9q?=
 =?utf-8?B?S0x2REsweWx0dWVlVEZTTnIzZXN0SVZIcE5CbHg2YU5nMXkyWGY3L0I5ZlJV?=
 =?utf-8?B?S05JWlZxNllwVktLa2Z4UTloYjV2Q0xYYnFaaG9PZzZnY3dIVkJTMEtPVjd3?=
 =?utf-8?B?eUdBSjNmczZxZHdka1h2WFgyUEFJYjFucFp1WjluZjYxUSswVitUcG9ZNEwx?=
 =?utf-8?B?bkdVZlUzREVneUZJa2pVcHgvRFdqT3hYZzRBb2VVVC9jdVVteHp6RGVaZk5W?=
 =?utf-8?B?eS9Hb2x1YmFrOFBHeTBnODhYbXo5ZnlkZDBoaExCZDVNSWJFeXhYNXZPdzNR?=
 =?utf-8?B?QWhCMHk2bVIycDYzQVI1TXFROWdRL0lEQUNzZVFOTEFoUHRqcUs3MnZET0Fo?=
 =?utf-8?B?SlJielJIdXB5NzFmeDQvMnFDWGxUQXY1YkZITDExSWxhVjhGSmhIeG9sZmlR?=
 =?utf-8?B?eWlGTE9palcyR2F4WDRCNXRrMnE2SVF2ZFRaUjZFVXNUVWx1aEgzNHNYaEJ0?=
 =?utf-8?B?RnpkNS91VHhtVldHcDVETWZ3amJBVjFzSzBmV3RYZmRvbEVsL0pkdk95REdU?=
 =?utf-8?B?YXFtaGphOHFRSFVWYnQwNWFEQ2dVRDA1S0oxQ2x0dkhhVmlwLzFTdXdZelNQ?=
 =?utf-8?B?S2JEQzlzaVlaVVBadStqdjVoaFhyTjQxL1QyMk1WcXcxd0tDQitWOGh2Z25i?=
 =?utf-8?B?Tjd0MC96MnVQTkl5aE1xVjUzQkhDRUtObW9LbkF4T0tCSmhZUU1MY0IreFJ6?=
 =?utf-8?B?dVhpOXEzNXhIQkF1dlR4UDFCY1Erb2IxZGFHUitZL2N5NTE5SVk1VHZOSndH?=
 =?utf-8?B?VXZpSVFVM3Z0Tm11eU9xMUdpRGM2b1pkaTQwa2Zja3RxT2YvcitRV0V3b0My?=
 =?utf-8?B?SDQzZnJmWDU2MFR3YTVXRWZ4anF2eHBkR3htV2J1TUJGMk9HRzJlU0ZGVmtX?=
 =?utf-8?B?cXk0cDhXMG9yWDZUOU0vZnpzc08rSTJDcWJCTnpSaUNQWCtqc1djSXRaZjVt?=
 =?utf-8?B?VkJCM2JhT0YrUTlJOHdsK2lIRWhsR280RjJzZFlpcTNwSmU0U3I4ZUJsZ1Y3?=
 =?utf-8?B?blliY205a2JuVVB5VlRqalZ6aWp6ZUw4aU9XYkJWTnQ2cnFBelJDMWFDWHF2?=
 =?utf-8?B?VDY3d2c5NUhuRU0zZ3hHRm1VOTl4em0zUm9lNkhBVGhhTjh2U1cyNDNFVWlT?=
 =?utf-8?B?QldxanlvMi96WEx4cFZrS2ZQSDNsWHE5dDRJSWV6UitWNGRQSDRmV1g0Y1Zl?=
 =?utf-8?B?ejNIKzByZEVualNEbVFGbnZHWEpVTDdTNUZyc2IwZG5PUk4rVkd6SllQS0NP?=
 =?utf-8?B?c2xrT0wvQStLa0pnR3ZqdlZGWnhDb1R3cy80UFJtU2ZMT3o1Smt3VWdHR0Fa?=
 =?utf-8?Q?nsw3r2ny/nf9l?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR04MB9561.eurprd04.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?bW9zMEVOUUh5ZUk5MlpuKzJxTUJWVnNRa3o4ZzRYcklSWjVrd3RLMnVDZUtU?=
 =?utf-8?B?S3hTK2oySkVkS0NTV2h0OVBuSXVYQU9YRkcxdXVLeHhyWGNRVmRJZFpBWW8r?=
 =?utf-8?B?M0IwajAyeE8vUUQ0NEJMWG0yTS9tTkN2azAzZXUvMkpWVE10cDQ2RFg4TldT?=
 =?utf-8?B?bTluSG1KU1pSSTRGTTNvRndwWlhkWTUrODJpSlpmaUZkMmtES05GMER0K25X?=
 =?utf-8?B?SkU3SFpMS2k2Mlg4S0RrbGgrcGx1ZjFBYm5yaEU2TVNaMnFtWllSMy83QnUz?=
 =?utf-8?B?YUJNWFFRUmhYWDBBa243b05TR0hrZ3JzWVFUT01qK1M5TmxidUFRb1dOaXh3?=
 =?utf-8?B?S1hFNVNNeVR3UGMzMXA0Yjc2OFQ2NXFSSVRvdi85QXNzUlZWelNEQkJxUWRp?=
 =?utf-8?B?STNVM1lYY0plSWRhZ1RYeTRRUXg4WElYdnNaelNrK21XZjhNWnU5MkcvVTll?=
 =?utf-8?B?bzluNXhNclQ5SmkyWGRxQ3hkd2VPSXdtZ3p1TjFnaHJJREZabm1tTmNUTWY2?=
 =?utf-8?B?S0l1MlRVSVhITEhoTzNvcjVoeCtyNmFNV202cktSSVBkOTdNT1JQa3FOZU5n?=
 =?utf-8?B?a1BMck5kay9lRGczZ1V1MDlhUFNiOHBUR3lTb0NYdVRxcHl5U05oWFF0S1hq?=
 =?utf-8?B?OFlGMmdzbzBybUtLSnZwclZvN1N5YmI4OCtnOXFVNmtsVUFWK1dlbUttQ2Mw?=
 =?utf-8?B?SVpDRVpLQThHR2RTUW1NNXdtRjhuVkdpVmo0NHV5RHZiOVI5Q1pmVVlMejJp?=
 =?utf-8?B?b3VndHA2NVJrYmlUMjh6dzJ2bk14N0xDMk90aS9XNHpDSDVuNU0zUHVLWGxy?=
 =?utf-8?B?dmtMSFJTY1FDUTd2Q3o2VUlvS0wzOWxVTUhOOUhBVXdKV0dMbjFZNjBaOXVN?=
 =?utf-8?B?Q2Fqdit0dGZMYnVFUnpLZFYyN2lvditzbGFiaHRvTDBlTWNkSnN2aGF6OVBQ?=
 =?utf-8?B?L250M280Z1VrK3U4anVzNTRxOFVtaXJCWGxxa1BvT2xkNm1TeGhWRXNBcG5M?=
 =?utf-8?B?Wm1LaUU2cUxGL1g3SktwWGFubndzZDRJMmtndnlwWWh3Slh2RVlKODExU2xz?=
 =?utf-8?B?cmt0emZaamI0VUdCMms3eEdvcWJ0eDFGMXRPYWgxK09QV2FqVFNpM1V1UGlL?=
 =?utf-8?B?V3gzd0lwVnMvbFNBMG03amV4ekExRGl3ZDVQbUE4UGtPR25WVWdzeCtWaHpQ?=
 =?utf-8?B?SWd5bEpXcEttdUFENU5ZVUtzUW9ZMU9GbFgvQzBTSlMrZXJocUJjS3ljWGhr?=
 =?utf-8?B?c0RzZEw1YTBEOEJiT1krWFE1RjhWc3FJUDdSWU4xTmN4TEg0a2tqbnJPWVRZ?=
 =?utf-8?B?LzNhYVpoMW9PQURKdUFFZGZveVY0Q3NOV0dkaURBeDdGWDZLZG9BMUMyWjYv?=
 =?utf-8?B?YVFGZXd4cmNLKzJjTVdLR284OVU4WTJaTCtucllwVG5NNlhJNUY1SVluYWta?=
 =?utf-8?B?b25ocFJ4S1hLZkI4clU3TVpHVjZrMFhIenhtSFE1Mlk5R1FQNjYrN3grUDF0?=
 =?utf-8?B?QTlqVFRDNnhWbHZXeVpFRVpRL0VPdUZiekZueTFaV0IvSDAxQk5aV0czNGdE?=
 =?utf-8?B?aGNTbDBIekhiT3NZZElrVDZYb0hqS1hPWit2ZFZjOFA2Mk1za2J5NXJMSy9s?=
 =?utf-8?B?RWtZZ2ZmajFIUXZIdG9JRWczYThmOW9vdWU3d25vWnREc0ZvNzZmQXkvNk9a?=
 =?utf-8?B?LzVwaFV0MUpPQXljZVpMbDdUcmZyZlFldFFDOTczbVNaeUtZV2JKRGhLSWJZ?=
 =?utf-8?B?T3pHVkJ5ckUvZUJNY2hHQ2NxTHFZejJWayt3bi8reXZrNUE3Sk1kSFlXNEFm?=
 =?utf-8?B?NzZEejNaUytCSHBkdFc1TFI0Rm9SWkUrbnZlaWxoU05IVDBNZjJ5c3VjbjlC?=
 =?utf-8?B?ZFBIYlFzZStkYUM0OUlKK1NMdTIyUVN6Wk9mVkQ5K2ZPQWtrTWw0TUxoWlU3?=
 =?utf-8?B?UlJVL2tvb3YyRWlkOVJpNDI1MnZ3MXBLV2FTelpHZUxub3VHS09DVnhCWjNQ?=
 =?utf-8?B?bDEzeFJGd25HRTdvbmI5cDJTS01KTnRkYzlsSmV2UWE3d216OWlYMDBUeW5x?=
 =?utf-8?B?WVA0RHMyOFdVVkRtcnJHZjd0U2E1UlI2NlplUno2TVFBN1ZRZTB2ek4vV3Rt?=
 =?utf-8?B?c3d2VGVkTlZXclY5czVzTTg5SkZRY1hENmF6dkVBdkNzOWpzeEhxRXhuQ0tl?=
 =?utf-8?B?VXc9PQ==?=
X-OriginatorOrg: oss.nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 02ea7016-de1b-4c56-836c-08dd1f7c7c57
X-MS-Exchange-CrossTenant-AuthSource: DU0PR04MB9561.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 15:56:08.1268
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: qwXUho3lmHDSTwHe5ZhheGc4tlo2KicA6bGIAcGX8kzj5IrZvOuErLJylHjXVqoQOV/Mos5waskdHrTKfQofGuSwTjycvn/D+3vDBmtqVW8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR04MB10271

Hi Bertrand, Andrew,

On 18/12/2024 17:33, Bertrand Marquis wrote:
> Hi Andrew,
>
>> On 18 Dec 2024, at 16:19, Andrew Cooper  wrote:
>>
>> On 18/12/2024 10:11 am, Andrei Cherechesu (OSS) wrote:
>>> diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
>>> index 02322c259c..6dbf6ec87b 100644
>>> --- a/xen/arch/arm/platforms/Kconfig
>>> +++ b/xen/arch/arm/platforms/Kconfig
>>> @@ -37,6 +37,14 @@ config MPSOC
>>> help
>>> Enable all the required drivers for Xilinx Ultrascale+ MPSoC
>>>
>>> +config S32G3
>>> + bool "NXP S32G3 Processors support"
>>> + depends on ARM_64
>>> + select HAS_LINFLEX
>>> + select SCMI_SMC
>>> + help
>>> + Enable all the required drivers for NXP S32G3 Processors Family
>> Minor point.  Help text should be intended by 1 tab and 2 spaces.  The
>> surrounding examples are wrong.
>>
>> This can probably be fixed on commit if the series doesn't need a resend.
> All entries in this file are actually wrong.
> I did not mention it due to this fact and I thought of pushing one change to fix them all 
> instead once this would have been commited.

So, do you want me do address this individually in v4 (which I will send
anyway for other reasons), or would it be preferable that you make a
separate patch to fix them all afterwards?

>
> Cheers
> Bertrand
>
>> ~Andrew

Regards,
Andrei Cherechesu


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 15:58:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 15:58:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860627.1272634 (Exim 4.92)
	(envelope-from )
	id 1tNwQt-000857-TT; Wed, 18 Dec 2024 15:57:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860627.1272634; Wed, 18 Dec 2024 15:57: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 1tNwQt-000850-Qt; Wed, 18 Dec 2024 15:57:55 +0000
Received: by outflank-mailman (input) for mailman id 860627;
 Wed, 18 Dec 2024 15:57: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 1tNwQt-00084u-1c
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 15:57:55 +0000
Received: from DU2PR03CU002.outbound.protection.outlook.com
 (mail-northeuropeazlp170120003.outbound.protection.outlook.com
 [2a01:111:f403:c200::3])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d70fce40-bd58-11ef-a0d7-8be0dac302b0;
 Wed, 18 Dec 2024 16:57:53 +0100 (CET)
Received: from AS4P195CA0036.EURP195.PROD.OUTLOOK.COM (2603:10a6:20b:65a::29)
 by VI0PR08MB11018.eurprd08.prod.outlook.com (2603:10a6:800:253::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Wed, 18 Dec
 2024 15:57:48 +0000
Received: from AMS1EPF00000046.eurprd04.prod.outlook.com
 (2603:10a6:20b:65a:cafe::f) by AS4P195CA0036.outlook.office365.com
 (2603:10a6:20b:65a::29) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.22 via Frontend Transport; Wed,
 18 Dec 2024 15:57:48 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 AMS1EPF00000046.mail.protection.outlook.com (10.167.16.43) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.15
 via Frontend Transport; Wed, 18 Dec 2024 15:57:48 +0000
Received: ("Tessian outbound b519d6c64997:v528");
 Wed, 18 Dec 2024 15:57:47 +0000
Received: from L205f82375703.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 DB4F8DF5-4DF0-4487-B5BF-8ECC16515590.1; 
 Wed, 18 Dec 2024 15:57:39 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 L205f82375703.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 18 Dec 2024 15:57:38 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24)
 by DB4PR08MB8054.eurprd08.prod.outlook.com (2603:10a6:10:389::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.19; Wed, 18 Dec
 2024 15:57:36 +0000
Received: from DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a]) by DB9PR08MB6588.eurprd08.prod.outlook.com
 ([fe80::a8fc:ea0d:baf1:23a%4]) with mapi id 15.20.8251.015; Wed, 18 Dec 2024
 15:57: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: d70fce40-bd58-11ef-a0d7-8be0dac302b0
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=E823hqnuILMUxPsvLJvdbAPTpMI2JqN3HS2moD8zRxLPsSecm6rC91vSLCPicGANMHOEhANZSs8EXRZ4LKJfP8GTbYUPqE6ZBQiw9oF4cokzrvAYswbD7c+to0WyNXYETxPtUXH9MCNu7x4gni8IIRry4p9vaRim/iYteox398ivNGHmw2d/Ew1qw5aU6mRlJzo7w9ESjKI/NAN2TiLBl1BPa4AJyDBQMU9Esf8N3LT9kVL6RmsYNqrlMRTv1nCqFehID5OK5xMypmNZY0DNXcRyQ9OF8vXsZZ6gtLBqv5yacLof0lpq4XQM58zfqrwsSEQC1dHDCYBtfmEdr7pjjw==
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=Wva/7YXkcsAC6ZulTQNTl2G9Q0Iq2uJn12WHp4tfxtQ=;
 b=EZ4q5UqxXXPHTpM+g3H7jvnzvboJ6KCyRbfc6NBjekmA6PHpJmMOlIC7CORkEdfLn3AyN6kLXb6F6SuqvW8OX2Gk5Z4DPtyShl+TcsQ+SG/AVvlm0nqxC6no1tILShJHPKbeW9ARlf1ApaQsvJryedtN8l2+A7HFYWFiuVYnflm6fpqb8Ui8UW7NnfsU9JmTNmL6aGx8SHD1GS1a5xHNKBrT2Er4+5EpuZU9j5OS59/4Ob6znnv3T1XbATzydkppY3tifLeqcTSKYguNIPZFV0Ptb+tp/7/UynqkgBSmLAclSN9Nlwa9H0nUdRyykTA/UCYd/0WHEqL8amTqNpQwWw==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=Wva/7YXkcsAC6ZulTQNTl2G9Q0Iq2uJn12WHp4tfxtQ=;
 b=ARwZtGdFP1gZP6Eu+JpFkCJ1l4I0tiKBTMXXYGM+BHsqNJCUwYpRYGgwl1p5hHyJZ0QnpZxlSfm3ZjR9KXmFrG041w94GA4NaMQhBQ/EiLr2t0/M3DH21WivFObgPZC7/h4els7rIj3HKNrqM94lqclZ/+xmB09YTFUqCxJAsm8=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 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
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 5eaf24747635a21a
X-TessianGatewayMetadata: sq4CSfJCi2XjI4wYBuM8mHYeBCY8E4O6ey5+rAd7q1t51sVSWidC5nFHoq1o9FEtikcDVSjMCmsU54B29zhnDTzdysSsLylxvlmlJuq9a565FIo0VVwbl+nCilaEw0uGxwyWHWm0Z1BMSFRpOTB1nCy6C19OuGPvfxTD9jXv1Ic=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Ce09Cenn1ev86YflHNgytt+wEJ/t/+TS5D04OSEqf57WGNxQKi8J+eL9ESBGv0HjLj0MMn9Jah+cp273DU2q5TqoBJVb73kn/V3idl9PXsfDJusBzG2ZevYFJ8OXWnnzX41aRbFRqalY60SIjRK3W5NQtKASzDJhwn5afmGDuzRk20+EK5RFpRkGPVQdtzc38tK6K+Vu53WQPPq15V1+gs5fNlUK8F3ckUfQzZwYP3SwdX+oO2KnlkkeEjM1ZR2pvbHkQ2FA1j9vGqvxzFULTbsb5F9CEnJJ/xqkiiLH52Ps5WQPfYj0uRl8QLIMeMxyv5IpPVhY5hVFNzd1v0xjxw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Wva/7YXkcsAC6ZulTQNTl2G9Q0Iq2uJn12WHp4tfxtQ=;
 b=PqkhtE5oR9B5Lwk9uyOrti3ZXYTd+3ToMzX1HyLuE7fKn2B/Yxjk40oTnPiRT/5tf9WS15U4wvzUu6jM1AYReNOxQAd4uCJvqKHSC6kWVntwJn//VuNppQG2kaCCvP4d+vK9MuQRl07wPiF+oK4QXMtye+Wgs7wtCFn+rPTDIARm33n7FxNVkhJHdFaXLHZptCW6L5dgl01h+3e7mi+y9tId1gZ992kw0EmteuE3oLIGrgdAYmCIvc8s6+hMoEA4wpwIwLPHqyHR1RIpA+eU4d9jEaoL0jAcvdOfZUlNQtaqRNoS8TFcFJuqr7/zzgAdhNO8VAAhIE5ZWnmh0GiiRQ==
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=Wva/7YXkcsAC6ZulTQNTl2G9Q0Iq2uJn12WHp4tfxtQ=;
 b=ARwZtGdFP1gZP6Eu+JpFkCJ1l4I0tiKBTMXXYGM+BHsqNJCUwYpRYGgwl1p5hHyJZ0QnpZxlSfm3ZjR9KXmFrG041w94GA4NaMQhBQ/EiLr2t0/M3DH21WivFObgPZC7/h4els7rIj3HKNrqM94lqclZ/+xmB09YTFUqCxJAsm8=
From: Bertrand Marquis 
To: Andrei Cherechesu 
CC: Andrew Cooper ,
	"xen-devel@lists.xenproject.org" ,
	"S32@nxp.com" , Andrei Cherechesu ,
	Stefano Stabellini , Julien Grall ,
	Michal Orzel , Volodymyr Babchuk
	
Subject: Re: [PATCH v3 3/6] xen/arm: platforms: Add NXP S32G3 Processors
 config
Thread-Topic: [PATCH v3 3/6] xen/arm: platforms: Add NXP S32G3 Processors
 config
Thread-Index: AQHbUTVdoMCMlYyvB0KhW/HQpIvTvrLsHi4AgAADtICAAAZkAIAAAF6A
Date: Wed, 18 Dec 2024 15:57:36 +0000
Message-ID: <7B7E57E3-C196-4F7B-B855-78E04763C941@arm.com>
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
 <20241218101142.1552618-4-andrei.cherechesu@oss.nxp.com>
 <8f1c342f-61d3-48f5-8311-a1162a20cb24@citrix.com>
 <3FDFACF4-C998-496C-806F-530CA3C87622@arm.com>
 <17240d6a-42bf-45fb-bb8b-2ad5aa1e855f@oss.nxp.com>
In-Reply-To: <17240d6a-42bf-45fb-bb8b-2ad5aa1e855f@oss.nxp.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DB9PR08MB6588:EE_|DB4PR08MB8054:EE_|AMS1EPF00000046:EE_|VI0PR08MB11018:EE_
X-MS-Office365-Filtering-Correlation-Id: c1aa0feb-4623-4b28-f2f5-08dd1f7cb82e
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|376014|10070799003|366016|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?us-ascii?Q?xdQ4aYPBkPwcEx9MJXBsqt940xi002vRGQ9Sfv0geIj2WUYTrEoKMu0Mol4B?=
 =?us-ascii?Q?DnxQXR06nm3+ehcAFxBgwCFPzwMHq+oLKYKWHwOi+C3Vri9d5qJdb1J6N9Hp?=
 =?us-ascii?Q?kvmg719lZDa5AxtUT85SFybgtmgRtmF2zbjANnE8sZK3rBHSfTMvYngjMeNu?=
 =?us-ascii?Q?wwFgXTKE5pDln/AVMfAx3GQrDdTConNIy6I9XNZ7U4nVC09yuAG4VzZE3Zev?=
 =?us-ascii?Q?T3QPX4ME5dosF+i+6Q+EIGcO/Tf5dW/LNcWcYvB741fjiHhaNHvYFLCZBp7w?=
 =?us-ascii?Q?bgSaPnQFya2O0qZm+Y5edb4gQ5zLrWRhSNQb0uYJGJNYdbB0t2lLXguoqKIC?=
 =?us-ascii?Q?3s10gPJlSoNNOZgU5d6SdKM32fgV7B151G7Sp1nGXEJkHu3AUeIqXMmWXvpz?=
 =?us-ascii?Q?IJueFZuvFmT2CD61Y69Yw7I5CyJps06W/NdyKmfqHGKm4uCEk4oe2rx6+ZG3?=
 =?us-ascii?Q?JZR6Bx17E5ZZrW3320EIFYOvKyJzMzY4MMuBwDNQo1NWhPPznmzmIZ7BwcpN?=
 =?us-ascii?Q?+HSRGFcoaeWMz+4fF/Ls1iSXyb0S7LTLGyOUJDCl6WAFlxyw5fkYf+rDrglm?=
 =?us-ascii?Q?506QhKg90wqmT31HVR0zx9Kmt/LuE9b+EFGJyjTRJSwbQcO6r7IjPe6MBbsw?=
 =?us-ascii?Q?MsZ0Peqa/h1CjE+uxlHVvT47o7OMtSC42M1wuEuo3dQLgfQrtJ7gMCt9vIJm?=
 =?us-ascii?Q?1DEmz4/6p/Si9yPrdZyxGdEIjyR856W2ZRingmptGmI3HXECj9YU/ehKeVv9?=
 =?us-ascii?Q?CT81B+oXPFAw+CeZKAPIkvqYnRrGonvwD8GfBmQ3Pqi6WMc8kHbaLEsRA3OV?=
 =?us-ascii?Q?VAFGt1PAK1HFZoas932d30SMb/fls9vp9LZktdOfHSMxaHCeaZpuxbYoac5P?=
 =?us-ascii?Q?FYk/yUeFCjRvykg7B3BXMWZUdUly9uvdh9H7n6QUksw89vs7DBWtKAJFyj0M?=
 =?us-ascii?Q?/xH+PnUqzkyTmaWwwJWL3PX4eoTfeGyGqellc0aSt/FIrZBt2B2Nu33nWQT2?=
 =?us-ascii?Q?JlK2mQoYrgJubHgawskL1XeGzE8EMPl5GLgCVR+Rhf1bC/jH7DX/gS/sOfAz?=
 =?us-ascii?Q?Psf16a3q4noPmp4GokTUZ9gQr7YkADFCEMa3hpZCglOroDQe/0ViHMrYvQl5?=
 =?us-ascii?Q?0GUM9P+dqdcPSvBwqsP8PhS2RzA47LaCdlifT4RDGoakzcyH/GM33f9FOue/?=
 =?us-ascii?Q?5RB/+PWJCoSOaBS7UUGVpGOIHf/xRn7LNbptFi1mPhtPecrOHDgK/z6oI3Ye?=
 =?us-ascii?Q?VE5uFAKNsa5kRRBh4vdZAr7NnTW0QbW4Rzeg7BzZWOZ+C3e2Xa9ZJ1cTK7jB?=
 =?us-ascii?Q?ozr1FqaCSYTw6dA29PjZtho2CVpvSn0sRk8Woq6dQq9jfNtLaBZ6vNbPdXSl?=
 =?us-ascii?Q?XQF6KCQve7pxHLxshHXG94cZ+L1V3NC5TW4hC7taKeXEcnbq0ERYODQqHeur?=
 =?us-ascii?Q?FEwQdIpSuhzTIhxfRQm5EATf3XXmDQkS?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB9PR08MB6588.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(10070799003)(366016)(38070700018);DIR:OUT;SFP:1101;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <594535A8A4C9B248B7099FC5FDF2DEC5@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR08MB8054
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender:
 ip=[2603:10a6:10:25a::24];domain=DB9PR08MB6588.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS1EPF00000046.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	261989c2-1a61-4ce4-5523-08dd1f7cb106
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|14060799003|1800799024|36860700013|82310400026|35042699022;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?s0dNC9BIVJ9OI5xCx6I6Fm+O/kxkioM/iQPIn5HeJn+bmkKj706Ul6x6f/LP?=
 =?us-ascii?Q?JAJdSXokI1vY1jJq6Gz/rFpHo1aynXkOfu00OLAg1jmv4/NHoRuuiWo3TSCz?=
 =?us-ascii?Q?QWaVYcGEuHlvV8ANHy0M+UXBkzCR+ogL5oRXvEPG/fXvtvMFHZ5Sr9F1C1jz?=
 =?us-ascii?Q?ZX9kmVtEfIKGbqdBT1HmVwdEFxcDgc8Kk9daF/Jhg6FKJgzCjl5sDsos8MnS?=
 =?us-ascii?Q?HaUXW9dwNwgiZ/Km2R6RWuJ6tT49i05pnop5MJMtXPiLCqiV7AssUd3fGqe/?=
 =?us-ascii?Q?nv72jBx286cZTITNgHM9XRe4PK2Z5SvHnGQuW2xZsIXrS3aWmWWIsQo2VwaH?=
 =?us-ascii?Q?lcAUuNpTQBF8hmbN4mXPtV95YPG6HM/J1NM+n5jmWjT/qSrixOH1qsNouxTf?=
 =?us-ascii?Q?UB6VMaMP3BqiPamJGr/zHW/GSZwcDA8Z7Sy5p6JleARwr7fPRXVOENbiJatN?=
 =?us-ascii?Q?ZjfDH/iT/j9yyg+A696K/DNp6/+aU3oRf78sN4jcWnocwT460YL1O53UDiVZ?=
 =?us-ascii?Q?l4HBmgs4QteGsfET8Z5DTrsyc173PCdHyEv0W1Idpwbl1UmCqQu+IifQFkq6?=
 =?us-ascii?Q?Kyn3itDNnZl/hf7q2MZidrtHKSYTdQTgUPlYOWJE4RkuTVuOrMVf0GIFDVZj?=
 =?us-ascii?Q?MFCeGvbIfPKBmGsiPRkdB1Yxc2yG37WviCWwP5Eq7ICt830UPEwG3OU7XUq5?=
 =?us-ascii?Q?r2EWAkfEzz+aTQPFEJ1NKQHRaUSceQiNrWFrjj7xkZPCnywYpe0uTUaNgVUj?=
 =?us-ascii?Q?/OR34mPrpylCwvFPjw0IBpQfk1x/im4paanRvtepri0AmQYo2oOmLlV+OnAh?=
 =?us-ascii?Q?OIsOxDVSKV57pmv6fjkJe9I4222gf2Hw/MVsj0jLiMPJqLR/0p1KYoY2dBBi?=
 =?us-ascii?Q?iblbZvwagItSHMMh3edwufKkQ/JZhU/sVqYhxkXa0MKaydFtlGqcn+F2aU6c?=
 =?us-ascii?Q?lqnvwFw7Wx/e6etcphRlc4XZWFu2LHIAPNL0AQ151CLFcYbiaFo7QZ7CQork?=
 =?us-ascii?Q?VxDRCV9YI5SpEH5BafTB6zldPI5EZDBy87ZGds+UH3IhXR9uvc3AkXbRrHVr?=
 =?us-ascii?Q?61Xt/zt9aYYZbB0bFoiHRYh+mywxpgCNw5KC2XHX5wFzHn6ApvfgnEnm1fy1?=
 =?us-ascii?Q?+Ua0wj5tMfABAUKjQJKNSbCyPeWpR9DRdyAQy8JklhDtuNS82ZefU747Auld?=
 =?us-ascii?Q?K54ikhsAKKTNZtvp0TLKmx/SYTiC1/o24zRq4orfNft22aTa23ShaSySOtGo?=
 =?us-ascii?Q?vRd3wIK+KGATlV/27wXBRoAn6wrYUrASWEpAXelJs2XsB7tAM55slggSLOjb?=
 =?us-ascii?Q?WGI0AVRDzaui1bbkXz7Wmr3JmMl0BQptOSuydh9T7UNloG8fgR0CnjvY+A+r?=
 =?us-ascii?Q?3BHuB3nU5q10X5mJ83hX4RwZY33bofsO5E1LYEdEKBewkH1xPhvmYnQlGEkF?=
 =?us-ascii?Q?aaqY0Eb54xuAYL51u2noXSduSgRNFVDIKxx4QioLUMPYk9FpjOF/hGB1wvH8?=
 =?us-ascii?Q?+1XeNDZe6oeKieI=3D?=
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(376014)(14060799003)(1800799024)(36860700013)(82310400026)(35042699022);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 15:57:48.2500
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c1aa0feb-4623-4b28-f2f5-08dd1f7cb82e
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AMS1EPF00000046.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR08MB11018

Hi Andrei,

> On 18 Dec 2024, at 16:56, Andrei Cherechesu  wrote:
>=20
> Hi Bertrand, Andrew,
>=20
> On 18/12/2024 17:33, Bertrand Marquis wrote:
>> Hi Andrew,
>>=20
>>> On 18 Dec 2024, at 16:19, Andrew Cooper  wro=
te:
>>>=20
>>> On 18/12/2024 10:11 am, Andrei Cherechesu (OSS) wrote:
>>>> diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/K=
config
>>>> index 02322c259c..6dbf6ec87b 100644
>>>> --- a/xen/arch/arm/platforms/Kconfig
>>>> +++ b/xen/arch/arm/platforms/Kconfig
>>>> @@ -37,6 +37,14 @@ config MPSOC
>>>> help
>>>> Enable all the required drivers for Xilinx Ultrascale+ MPSoC
>>>>=20
>>>> +config S32G3
>>>> + bool "NXP S32G3 Processors support"
>>>> + depends on ARM_64
>>>> + select HAS_LINFLEX
>>>> + select SCMI_SMC
>>>> + help
>>>> + Enable all the required drivers for NXP S32G3 Processors Family
>>> Minor point.  Help text should be intended by 1 tab and 2 spaces.  The
>>> surrounding examples are wrong.
>>>=20
>>> This can probably be fixed on commit if the series doesn't need a resen=
d.
>> All entries in this file are actually wrong.
>> I did not mention it due to this fact and I thought of pushing one chang=
e to fix them all=20
>> instead once this would have been commited.
>=20
> So, do you want me do address this individually in v4 (which I will send
> anyway for other reasons), or would it be preferable that you make a
> separate patch to fix them all afterwards?

Do not address this one, I will handle it with an independent patch after t=
he release.

Cheers
Bertrand

>=20
>>=20
>> Cheers
>> Bertrand
>>=20
>>> ~Andrew
>=20
> Regards,
> Andrei Cherechesu




From xen-devel-bounces@lists.xenproject.org Wed Dec 18 16:23:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 16:23:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860644.1272644 (Exim 4.92)
	(envelope-from )
	id 1tNwpo-0004wv-Rg; Wed, 18 Dec 2024 16:23:40 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860644.1272644; Wed, 18 Dec 2024 16: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 1tNwpo-0004wo-P6; Wed, 18 Dec 2024 16:23:40 +0000
Received: by outflank-mailman (input) for mailman id 860644;
 Wed, 18 Dec 2024 16: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 1tNwpn-0004wi-8X
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 16:23:39 +0000
Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com
 [2a00:1450:4864:20::343])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6eedef73-bd5c-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 17:23:36 +0100 (CET)
Received: by mail-wm1-x343.google.com with SMTP id
 5b1f17b1804b1-4363ae65100so43925195e9.0
 for ; Wed, 18 Dec 2024 08:23:36 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43656b01c72sm24655885e9.15.2024.12.18.08.23.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Dec 2024 08:23: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: 6eedef73-bd5c-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734539016; x=1735143816; 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=oEIAagIF9OJNP006px3kTaeut4c8v+2sgXBVNhAMma8=;
        b=FIHhiS6uqw/51JfLthQJYIi8otc8n1LjHLW2QBPUm/Vd2/9hNdH751mBA3wANFrGe0
         EwHOrB6ompPJvPPWznx444gwAFzYir2reazINXp3hJUnxwllzHiCmWQeo9Oy+MKyCdQd
         SUHLfkzjEBkSDX3oLAn40+pSGtUdZ4SBqIfQc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734539016; x=1735143816;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=oEIAagIF9OJNP006px3kTaeut4c8v+2sgXBVNhAMma8=;
        b=ZVb4YVBzBhXiXd6SJfgnyUmXDT48krvtiey6Nx6R3GBHvEfyy1xCS761X/T/UG3hSJ
         uAFw+EorZMqvkUxMYROmWOtjtWmTeOIdq0Xx3rK5r/uS/m96TtffU8W82TNhOsONL2Qk
         R6M9DYu0HRczhpfucxlFA8iycs63fUCt6rUanAw1KhINXqZo1AEUIci6Qf+mxVv3wr/S
         jvIp38THDEttlO5CNAX5q5G1iuEHpyugpkx3WwMOe4lzcBRvhV3t9IOAV4FyWOPGnGJR
         rEpPzpGcT1alu9SVXh2fQIIKOfWX6tbPdQ0IzAF7FUFoNb3jTtVw1OkcHJaefpGul4QT
         +GBw==
X-Forwarded-Encrypted: i=1; AJvYcCXfW81Ly6oRbAcOiwhwdR+v5rBzJVoeYPIFKJZE46WIkYUUlMISMUo5akcCn4weI24K7BGrM4W4Axo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwLoi4O3VYPDbq35PR3u6RrZ7qnfJU50MrWlpEjRXrWfp5X6p2k
	w0d6ulVcpXdAY7JzY7Znkxa/BWNsAJM8a42o55NfrGqc8j9gZaYmlJ7ey5Bs2L0=
X-Gm-Gg: ASbGncs3ulzGElzPFzZajzcYOJuZr8aPauA0pC1maGYk8Aq2cidbDViK6O0HVuGpeld
	u5BxKa6CFxmV5JQU6BQes6R4D5CDfwpD0IiAwTYWsYJznFQnXS9meKvjCBsDS1nk7Ao2kdG2NVj
	psgAuf4ndr6ElQoAlN/VVmbXpZ0YkF1NQNE0RG04VeCOFbxYJVhlIifJ461H7jrWXjVlK8jVoiT
	ONUG4mLAlbiC5030zHy6KA+2X3551018Tdi6Ql1IpmxQIkmO+cvkzvFBmJjIefp09TCRAKJpmR+
	MjEL1pnA+cntj2nG9een
X-Google-Smtp-Source: AGHT+IHze0wmGYcdugNrGRa4bJuT5laGQO79WQoVtv7nVk3ZZ5Zo3H+FIoXHpwNvtksl9RkQD7dU2g==
X-Received: by 2002:a05:600c:314a:b0:434:f817:4492 with SMTP id 5b1f17b1804b1-436553ff1d2mr40203975e9.31.1734539016221;
        Wed, 18 Dec 2024 08:23:36 -0800 (PST)
Message-ID: 
Date: Wed, 18 Dec 2024 16:23:35 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2] x86/hvm: Use constants for x86 modes
From: Andrew Cooper 
To: Teddy Astie , xen-devel@lists.xenproject.org
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Paul Durrant 
References: 
 <6a0ee425-96ce-4361-ad23-7f21c3398694@citrix.com>
Content-Language: en-GB
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <6a0ee425-96ce-4361-ad23-7f21c3398694@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 18/12/2024 3:54 pm, Andrew Cooper wrote:
> On 02/12/2024 9:49 am, Teddy Astie wrote:
>> diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h
>> index 02de18c7d4..dbc37e8b75 100644
>> --- a/xen/arch/x86/include/asm/hvm/hvm.h
>> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
>> @@ -26,6 +26,12 @@ extern bool opt_hvm_fep;
>>  #define opt_hvm_fep 0
>>  #endif
>>  
>> +#define X86_MODE_REAL  0
>> +#define X86_MODE_VM86  1
>> +#define X86_MODE_16BIT 2
>> +#define X86_MODE_32BIT 4
>> +#define X86_MODE_64BIT 8
>> +
>>  /* Interrupt acknowledgement sources. */
>>  enum hvm_intsrc {
>>      hvm_intsrc_none,
> We discussed this in the x86 meeting.  These want to live next to
> hvm_guest_x86_mode() with a comment stating that they're not
> architectural modes.
>
> During your work, you seem to have only looked at the the VMX side of
> things.
>
> There are several callers of hvm_guest_x86_mode() and
> svm_guest_x86_mode() missed.  Also an unnecessary include, and a couple
> of overly long lines.
>
> https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=commitdiff;h=4f8f63d49776d69ed9a978b6601c13c54c579a98
> is the incremental fix on top of this patch.
>
> Does this look reasonable?

Bah, randconfig says this doesn't quite work. 
https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/8677688167  The
constants need to be available in the !HVM case too.

That will involve moving them higher into hvm.h and where they are in
this hunk is probably ok.  I'll move the comment too.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 16:26:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 16:26:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860653.1272655 (Exim 4.92)
	(envelope-from )
	id 1tNwsc-0005WL-8q; Wed, 18 Dec 2024 16:26:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860653.1272655; Wed, 18 Dec 2024 16:26: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 1tNwsc-0005WE-5h; Wed, 18 Dec 2024 16:26:34 +0000
Received: by outflank-mailman (input) for mailman id 860653;
 Wed, 18 Dec 2024 16:26: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 1tNwsa-0005W8-Up
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 16:26:32 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d637e279-bd5c-11ef-a0d7-8be0dac302b0;
 Wed, 18 Dec 2024 17:26:31 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1734539181203404.7330976319006;
 Wed, 18 Dec 2024 08:26: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: d637e279-bd5c-11ef-a0d7-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1734539184; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=PVJBldduZ/VLUmJfzEJt1zXQ2S+jdks7frJYUkBlpWTx0WFSXqtp3+nuTgiq4whs1LD+M0sihwCoI5oYvhg1blz9DHvR0BZBnoGuHg3e/YW+wzMxvJCliZb5waB4DeM/mCbUrF1tIuxpKXBAJgqPJKruOK8zVM2bPVZa+XG2ENI=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1734539184; 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=8zB+zX4DmURxURBLM6sSPJcsO4CAdsxHqlB+51YY/x8=; 
	b=L5oJ7Swr8B6jX+U80i26thV0vTS6vtZlj7Thj6WOnPn5PLjK9Lz6liw2PKJOmVosq6/MgEyE4jEJ7uix6O5ME0rNMvlxvHBov5Ne6mzTVSB4EzXRkn35S1pk4BG8S+/rOQNlWC6dEWDcGEGZCwCQJSyZg3QX38996ddhxYkD1GM=
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=1734539184;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=8zB+zX4DmURxURBLM6sSPJcsO4CAdsxHqlB+51YY/x8=;
	b=TQvHZPQK2RZmffA+zm35E39wO6tl0utvzlb4YHlc8e4MK9rARtknbIgVvK9RNxhg
	bUI9E5f/gMtAvGB3TfRkYfEhAaBEcDUDGvm4x8/A1Ko5jPT9Fv4xn1go1ksWAKpLsWT
	NtqI6elgOnKlZSO11xjGWmQUL7rYQD+iaEotfDGo=
Message-ID: <1f17eea5-c3cd-4a78-9973-b5996bb1dd1e@apertussolutions.com>
Date: Wed, 18 Dec 2024 11:26:18 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
To: Michal Orzel , Julien Grall ,
 Sergiy Kibrik , xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini 
References: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
 <4e437c60-4fee-40ed-9d2a-789bac0b36d9@xen.org>
 <63b21760-7dea-423b-a9d8-64d213c40b2c@apertussolutions.com>
 <2423b111-0a3e-42f8-a11e-02d81fa75eb5@amd.com>
Content-Language: en-US
From: "Daniel P. Smith" 
In-Reply-To: <2423b111-0a3e-42f8-a11e-02d81fa75eb5@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ZohoMailClient: External

Hey Michal,

On 12/18/24 06:04, Michal Orzel wrote:
> Hi Daniel,
> 
> On 18/12/2024 02:17, Daniel P. Smith wrote:
>>
>>
>>> On 17/12/2024 11:47, Sergiy Kibrik wrote:
>>>> Allow to build ARM configuration with support for initializing
>>>> hardware domain.
>>>> On ARM it is only possible to start hardware domain in multiboot mode, so
>>>> dom0less support is required. This is reflected by dependency on
>>>> DOM0LESS_BOOT
>>>> instead of directly depending on ARM config option.
>>
>>
>> Just to make sure my assumption is correct, you are looking to do a
>> multi-domain construction at boot time, with at least two domains. One
>> of those two domains is the "control domain" and one is the "hardware
>> domain", aka late hwdom except it's not constructed "late".
>>
>> If you want such a configuration, I would highly recommend you first
>> enable setting flask labels via dom0less (assuming it is not there)
> Speaking about dom0less and FLASK. A year ago, I did sent you (privately, through
> AMD hyperlaunch collab) my attempt to add minimal steps to enable setting FLASK policy
> for dom0less domUs. You then told me that you have a slightly different vision on how it
> should be done. Any update with that regard? TBH I though that you're going to add this
> support together with other hyperlaunch patches.

As I mentioned back in my March response, the concern I have with the 
patch you provided was with the layering violation. A security label is 
a flask-centric concept, at least currently, and thus not a concept you 
want to expose in the general XSM api. The correct way to get an XSM 
module's specific info, or translation, is to use the xsm_do_xsm_op(). I 
do feel that xsm_do_xsm_op() has a laying violation in its 
implementation, and is what I want to fix, it is still the correct 
interface. Priorities in meeting the core requirements AMD needs from 
hyperlaunch resulted in several abilities to fall to the wayside for the 
time being. I understand things need to move along, so I would prefer 
the use of existing interface that can be just updated when 
xsm_do_xsm_op() does get fixed up.

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 16:57:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 16:57:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860666.1272665 (Exim 4.92)
	(envelope-from )
	id 1tNxLw-0001uW-Gg; Wed, 18 Dec 2024 16:56:52 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860666.1272665; Wed, 18 Dec 2024 16:56:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNxLw-0001uP-DJ; Wed, 18 Dec 2024 16:56:52 +0000
Received: by outflank-mailman (input) for mailman id 860666;
 Wed, 18 Dec 2024 16:56: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 1tNxLv-0001uJ-BN
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 16:56:51 +0000
Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com
 [2a00:1450:4864:20::343])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 12b9216c-bd61-11ef-a0d7-8be0dac302b0;
 Wed, 18 Dec 2024 17:56:49 +0100 (CET)
Received: by mail-wm1-x343.google.com with SMTP id
 5b1f17b1804b1-4361b0ec57aso65246275e9.0
 for ; Wed, 18 Dec 2024 08:56:49 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c806b84esm14459654f8f.108.2024.12.18.08.56.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Dec 2024 08:56: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: 12b9216c-bd61-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734541009; x=1735145809; 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=rCfZYLFaL906dU0HrHmsxkV1Raijev2paNdLSI1zp74=;
        b=E3lX65mX8ujyxZFlvXbZDDzJFBV1prUkoIw8Iopt/88ozOswBzNmDUCPgi2+z5g7lE
         +PQKd/Q02vW4zG2aV00waJi0omlUA4K+aAci33U+02WHfi27X0A9ou951UopCV6YT/ro
         bca9rmL2R7st3Iu6yRC43hrzE1d3Wj4d0ozZw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734541009; x=1735145809;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=rCfZYLFaL906dU0HrHmsxkV1Raijev2paNdLSI1zp74=;
        b=ZWeFe1oiBKyLgkN9PB532U4ljDjppjRYNQ92LweVjPDWR/28vN2MF7HsMVoIj4Sq7D
         mbt6gf1qRyyQG5VHrAwm9A/WZBJrjnnFu/MOmrk8JZdylQ19ovhlIHDceMIErvojKrV7
         SO/kgcrYWZepiEF/3F3BwtlHfLN6M2Sz5xtZam4lczkVPATBnyEKeDlC8RCnKMj1AW4Z
         bzE0NRJuwtBrYkz7AFg7e2UUD20MjwpH1GPZq4nJfkvdsVO7svNznIEyiaAOzUA7K7p0
         ylr7cvKjrmTS9E1ILUwH4DyfOYiY5ZAWJ4PB6O54HwlLFyLMVnTwj4MbsSG3xU2pPkLl
         3F4g==
X-Forwarded-Encrypted: i=1; AJvYcCXa5+SsO6FMjG41vmi1cG8fsCXlF1uV3ZNeINWQJjVm46hhUKYsv9s9ERr2afJfhFTRoe9nAhBEBfk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yz2ROEIjwnWJ6hLsBed4W5f2iVPNNXPYagUBg6woooiUjooK9YB
	6A/5m6UKq+O4g+vrgKX1NBvCS/v3axHYYLcun/4ts8CCDMbYaPtPHbK8ykw3T0M=
X-Gm-Gg: ASbGnctCeiJHWqzcA0XmQPrjE5k1Tun/XsmyumhqOJxTI29Q4nzscr5fL/qlifjNeMC
	66r70DT/hVI/nuQFH4VG3RGW6KmAqeK8Tq58lpqmb7U3Y7K51Hpw3r49sRIMSzm8aRcJ6FvzRfa
	ZsZfMnvinvF68X48m4njuhQgen3OZcs9/jVf1Zrjed2BzXSoxBsAMgViXyzcI/uJ09JYdQaK4TY
	M6BifncqBFTXqYGH5Rq+IBv+mpO1MgLg1UsUoP3Op4lMxD/RW6TeK65P2fmtw7nJI6R1oIcZzVQ
	97CngjTFc/w/D7PS0/GH
X-Google-Smtp-Source: AGHT+IGscwqeBK6TMxnQR/IVvCuMDPqf8iBLq84ZeNG3j5sA5ANLXz+ooGObX1wf1VwjJkss0PDD1g==
X-Received: by 2002:a05:600c:1caa:b0:434:f5d1:f10f with SMTP id 5b1f17b1804b1-43655368679mr36784645e9.17.1734541009048;
        Wed, 18 Dec 2024 08:56:49 -0800 (PST)
Message-ID: <727d8945-42f5-4715-a5ff-818ea4bca6a0@citrix.com>
Date: Wed, 18 Dec 2024 16:56:47 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2] x86/hvm: Use constants for x86 modes
From: Andrew Cooper 
To: Teddy Astie , xen-devel@lists.xenproject.org
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Paul Durrant 
References: 
 <6a0ee425-96ce-4361-ad23-7f21c3398694@citrix.com>
Content-Language: en-GB
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <6a0ee425-96ce-4361-ad23-7f21c3398694@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 18/12/2024 3:54 pm, Andrew Cooper wrote:
> On 02/12/2024 9:49 am, Teddy Astie wrote:
>> diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h
>> index 02de18c7d4..dbc37e8b75 100644
>> --- a/xen/arch/x86/include/asm/hvm/hvm.h
>> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
>> @@ -26,6 +26,12 @@ extern bool opt_hvm_fep;
>>  #define opt_hvm_fep 0
>>  #endif
>>  
>> +#define X86_MODE_REAL  0
>> +#define X86_MODE_VM86  1
>> +#define X86_MODE_16BIT 2
>> +#define X86_MODE_32BIT 4
>> +#define X86_MODE_64BIT 8
>> +
>>  /* Interrupt acknowledgement sources. */
>>  enum hvm_intsrc {
>>      hvm_intsrc_none,
> We discussed this in the x86 meeting.  These want to live next to
> hvm_guest_x86_mode() with a comment stating that they're not
> architectural modes.
>
> During your work, you seem to have only looked at the the VMX side of
> things.
>
> There are several callers of hvm_guest_x86_mode() and
> svm_guest_x86_mode() missed.  Also an unnecessary include, and a couple
> of overly long lines.
>
> https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=commitdiff;h=4f8f63d49776d69ed9a978b6601c13c54c579a98
> is the incremental fix on top of this patch.
>
> Does this look reasonable?
>
>
> I've just realised that the check in nvmx_handle_vmx_insn() is an
> incredibly complicated way of expressing guest_cr[0].PE, and we've got
> the same opencoded elsewhere, so I'll also prepare a patch prerequisite
> patch to sort that out, then rebase this over it.

No.  It's subtly not (only) a PE check, so lets leave it as is for now.

I'll update the comment to say that some users rely on the order of
constants.

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 17:02:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 17:02:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860675.1272674 (Exim 4.92)
	(envelope-from )
	id 1tNxRQ-0003ec-37; Wed, 18 Dec 2024 17:02:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860675.1272674; Wed, 18 Dec 2024 17:02:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNxRQ-0003eV-0H; Wed, 18 Dec 2024 17:02:32 +0000
Received: by outflank-mailman (input) for mailman id 860675;
 Wed, 18 Dec 2024 17:02: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 1tNxRN-0003eP-Sh
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 17:02:29 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on20623.outbound.protection.outlook.com
 [2a01:111:f403:2418::623])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id dae6658b-bd61-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 18:02:26 +0100 (CET)
Received: from DM6PR03CA0001.namprd03.prod.outlook.com (2603:10b6:5:40::14) by
 CYYPR12MB8855.namprd12.prod.outlook.com (2603:10b6:930:bb::6) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8251.22; Wed, 18 Dec 2024 17:02:19 +0000
Received: from CY4PEPF0000EDD7.namprd03.prod.outlook.com
 (2603:10b6:5:40:cafe::16) by DM6PR03CA0001.outlook.office365.com
 (2603:10b6:5:40::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8158.17 via Frontend Transport; Wed,
 18 Dec 2024 17:02:19 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CY4PEPF0000EDD7.mail.protection.outlook.com (10.167.241.203) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Wed, 18 Dec 2024 17:02:19 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 18 Dec
 2024 11:02:17 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) 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, 18 Dec
 2024 11:02:17 -0600
Received: from [172.18.155.234] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Wed, 18 Dec 2024 11:02:16 -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: dae6658b-bd61-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=AFVa/vHc7lqhln4BJCZV8viCld7QIBKla/e6aN5hHstZJp9zdca8DLoJVdEfPeGB4XkW6GKI2N/o3pba9vwaeSZFRXArLz9N1rKLpZe5I0bobUep8T2Q1liuEM5gz1cRnU5bqkcRNDwdXE5UONZrdMrU+ogjAqvLYC/CObWaiQcdUCFZUB4ov4pxeWRKfrVFM8S/kAmOcLuVzX8dSvXGfRXWwJy2jpYJ38Hp6pLWs3yn34Ht7xINY5RHSNqGhg3TtYWR0pDglJRUz+Bfsnikd3NMFzfw+BEBYs66faxzVfLIIvwfq+QExmqiStw5rTebuwJHroM6foDLBlJ3QBpA+Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xWPi4XnMezOAj6zJKPnLBpd9iQiUqvY/JJJZS86mVa4=;
 b=fAeKr3wX46RhomxpgNxBPVC/Gwnen+ORgxrulA5EpISOBzODpE1kLyaXilZwual4CG2iHUi046Q6+9nXOhrPV7+KeaQw89xa1jaVTy+fwaSzPMCw/vW8+o53AeDIeIO1g9lo/smK6v+86ESnXuUvjRWkwQUIc6fVwO9i5oCpHpDRDvCL2z8TEv73qDMCpzyR8REjlbhYCQXrb9UqUZz9opy9r1Nhlvxg1BpFGWjgqEn5vuprWfQP0EdNwZieK9p+yquKmkeXVBNEx8Jx4dzAbYkLCDcjRVP4eiv6jG/chMpAbEMJrYbCpALBOlfXkb183nuYAsz0Dwt/sdrzB9OJlQ==
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=xWPi4XnMezOAj6zJKPnLBpd9iQiUqvY/JJJZS86mVa4=;
 b=5G6mRzutQborC1JZrqRy6ePKK7+NVfr8HLpcafnXiMxK+eWyYaLC5bZuZyMaH40lyZr47KEueI2U3R1lwZjcdTm57Y+RFS9SETpgIuYjZxq0VO8DHOdGU3H3AgLquaX4LolMe3nbphFGWgzK2beazvq0+D1m3E4RRi9g5uh3e/0=
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=SATLEXMB03.amd.com; pr=C
Message-ID: <48b45ce4-b966-49e2-93e4-4b66d9ad170c@amd.com>
Date: Wed, 18 Dec 2024 12:02:17 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/boot: Use printk_once() instead of opencoding it
To: Andrew Cooper , Xen-devel
	
CC: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	
References: <20241218123845.58850-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: <20241218123845.58850-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EDD7:EE_|CYYPR12MB8855:EE_
X-MS-Office365-Filtering-Correlation-Id: 712d8018-6849-475c-7e66-08dd1f85bb8a
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|36860700013|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?cFRrMGNseXFCZEh2YW91QUVIcXcxUS9JRGl2WjR1UmduRXQ2L1RqMHRVQU50?=
 =?utf-8?B?bEMwdHU5MmZycmM1elFDMUsyMHF2QXczTmdwU0V0WkFuY1EwMjB4cWdDMG45?=
 =?utf-8?B?bXVKMmZaTjNDMUo5M2VqK0FLM0R1NDk3K3liUTdrOFQwck5YZzNIQXhYQzhX?=
 =?utf-8?B?SEpqM0x6Q1BBa2hhNUZlVzdjWWxCdUZoLzJCUUNRZGRVLzhETFF3YXE1WGZu?=
 =?utf-8?B?aW82SDdvQThZMGZSenRqM2FHTStMTGN6RFpZbWNVYVQwQkFZVzVyQmJVWFlz?=
 =?utf-8?B?ZXFNdGhyUTVUVXFFZXFPQUNqYm9jck5penBmdlBWckVwd1luL0diU2VFSG5y?=
 =?utf-8?B?WWRWV3pLck1ka0VDUlBxYjJ3WitGQzg5M2s5eTFOT0QxQzFWR3dnSWFzTC9v?=
 =?utf-8?B?MC9zM3NtelI0QlRGWFpaOUFNRlVONnREY3l2TVFBaWwwamk2SThxbGxpMG0v?=
 =?utf-8?B?NTNrSnJjMy9veUN6QU9STzRTYWVhUWM2NlpRRXdMc1B6bk5rSmRFSmRtMTdp?=
 =?utf-8?B?amE1K2REMXFBVDlnMHEvWk5HV0ZjQ1dqcmdHcURncS9pQVVhWGJyeTFqYUJa?=
 =?utf-8?B?NU9kdEY3R3BqNlZWY3FxYTl0OUVFaytXVFp3RFRvcGE5eHNXYXlmSUNVd1JY?=
 =?utf-8?B?YkFQZndQMTk4Wk5manV5VE1RWUdJNURZaG0zdlBrclBvTndTODlNM2FaQUNV?=
 =?utf-8?B?Sm9sNlVSWStqOGx3b0U5V2RrNkFRc2NBd082Y3F5VG00QTFnRU5zeUxYZXNJ?=
 =?utf-8?B?ZnoyRng0QVQ5VEV6cFhDQzE5RGZiU2JTVENYaDJlZ2xHWk45d1h2UXdkVG0w?=
 =?utf-8?B?UnJWbXJ3bEQzNGd1M09NK0ZhbGFWaU1jcHFhOU5GejB6TVIxcXU2YnF2VzQw?=
 =?utf-8?B?dkNMcmJVRlVRNFhlZjVnL0ZKRzYzaTd4YWpnL0Z2Q3VjUW5WQ0ROdk5TTWVE?=
 =?utf-8?B?TjBzeDZxejBlVjIwNW9Zd2d0amhtdnBxQ2V3b3FsK2hybjNKV1lDUWJsYVVQ?=
 =?utf-8?B?WTN1NklTckJsUHU2M29zbWFZbFVydStvOW5uV0hDakczYkpBdW9PZGlEMzBs?=
 =?utf-8?B?RytVcWkwbFdUZjNXRHp5ekVOWHFmd3VzMWQ4K1d4c3JRUUhEb3BTa2E1alI0?=
 =?utf-8?B?RnRQVVp6NVJtaTlhMkJRTHFXTXIzN1FRUVlVeGtGTVMwZHhNb215amFDR0tB?=
 =?utf-8?B?ZUtvcU5mZVhNVk5pT2V6QXV4R1lWZEJSN3JGUXFuUGkwaVplMHZqNnBSVEdl?=
 =?utf-8?B?M1lybW1kRVRBRFpCYUl4anZHaTNodmFJTkpPUlBKeW1hSDFLRHNGS0JKb3Z2?=
 =?utf-8?B?UldrSktnZHN5S0xHejN1M25yVElpTDZGY29LRlpVd3JkT0VwZG5uVWs1QWFT?=
 =?utf-8?B?a20yN3dkblZUSGVRZHJpa2h0Q2dGUVJadjh3YVUyREhEZElUOEJ5VWZydUVM?=
 =?utf-8?B?WFo2T0RTRld0YlQ0LzJqbUtUTks0OHp0dlFjN2F2ZVI0YzlMWk40b2tkSloz?=
 =?utf-8?B?eFMrdjQrYndMcmR1bEpLeURpQkFCaXpBQUxmM09MSmdnaDgxMGw2ZUlOdFlo?=
 =?utf-8?B?QTMrUFM5aHNUZ2lScXFyQWpxTk9FOW9qZ2s0VHhGb05lUnVjLzlySmRpQzg5?=
 =?utf-8?B?Rm9URzhVZ1VWNXkzZXY4T1creDZwZ2Q3OW16RDZUMXpGQUppR3hMSDNQVGhv?=
 =?utf-8?B?b3hxVkpkanY0YUpxVnVPZW9mTzdYN240TXpjcDZZRlA4TXFZZUVLZ21iYWdM?=
 =?utf-8?B?QzgrU0grY0NrNFlhNXlla3hyOTlTcndBbWRDRE9RZkJYNC9WZi9IWU81bVMr?=
 =?utf-8?B?NDg2VzErSFBVNHpkaTk0R2MxNEJDd1hOdmROeW9KTFhFZm1qU2tVa1Qwd0V2?=
 =?utf-8?B?VW0zelVhNFNLLzdhZ0NOVnZjK3BsbXMrdzBkdzdSUXBMZXVjc01VMHZEL1Ni?=
 =?utf-8?B?TEMrZ2phclhqbDFSMUsrekljRUl3STRiQkYxTGZsUW9qNHRNRVJ4UHBMUkI5?=
 =?utf-8?Q?BzoFGkbdMf2yPAdzaOb7ATB7qud7l4=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(36860700013)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2024 17:02:19.2286
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 712d8018-6849-475c-7e66-08dd1f85bb8a
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000EDD7.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8855

On 2024-12-18 07:38, Andrew Cooper wrote:
> Adjust the message for brevity.  No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jason Andryuk 


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 17:08:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 17:08:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860689.1272684 (Exim 4.92)
	(envelope-from )
	id 1tNxX8-0004Ls-Qh; Wed, 18 Dec 2024 17:08:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860689.1272684; Wed, 18 Dec 2024 17:08:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tNxX8-0004Ll-O3; Wed, 18 Dec 2024 17:08:26 +0000
Received: by outflank-mailman (input) for mailman id 860689;
 Wed, 18 Dec 2024 17:08: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 1tNxX7-0004Lf-RF
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 17:08:25 +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 b02cdd37-bd62-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 18:08:23 +0100 (CET)
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-3862d16b4f5so754187f8f.0
 for ; Wed, 18 Dec 2024 09:08:23 -0800 (PST)
Received: from andrewcoop.eng.citrite.net (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c801acfdsm14382447f8f.57.2024.12.18.09.08.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 18 Dec 2024 09:08: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: b02cdd37-bd62-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734541702; x=1735146502; 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=YgYydg0CiacPidmMRJwjDtf5BUWwdAGRWZBI6A2JkQY=;
        b=POncgYuUZDm43T2zDKSNuBEwJKpObthj6vqmduSZwsF6ZWjczoJK32BOl7uq4NiUzY
         8BiItpN1eQHerP32LLni+0lRFS1G4xVxnoSXv8ScR80MBFpfhnvc/jI2n6ScQJmo1kIu
         gES6erbhZbT7DaidiP8T5MFrvfG9lu7i7I+Kc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734541702; x=1735146502;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=YgYydg0CiacPidmMRJwjDtf5BUWwdAGRWZBI6A2JkQY=;
        b=JzeA3YAGX8kZsBUfepL1o9OdEWH5dXq49MIZOkQvXctyoPxoO8yqTvyV6ODBl170ES
         P8OQzkVko3yMygjz07kYChKJbXdatxdapVpyN/KlCj3uWsgenP+1I1YV+oSLycx0g92Y
         1SVokUVhQ1CxdZGMOTbB2AUaFGWBah+TisYX8cyBhdE+uG089ZSJr1DdQpuUiOLsRyo0
         V2QOsxK+Ro1wQjJv31g1JuDm2ysfc7U1oEj5H+HF1ZdhWB7tv/+FgvMAIOa4NdFDsjQI
         WLZx+cYobHaUwubW1PIrt3vHfhJEQB491XCS3ewE5HNd3VtlLCaA4iDcMHY8JXRs6jeU
         HFvQ==
X-Gm-Message-State: AOJu0YwN9LSbIWxkCv/CalwRBx2/hGabHLg7+dWaVhEmUchfrUMQfbnQ
	Yc3nXJMZNub9dWOzorn9h1d0O/j3K7yvCjBq3/Kqd4IYQsoHUhM9qH/UW1fxIWz+SzmlDGx/R8I
	wokc=
X-Gm-Gg: ASbGnct2iDynoI2vOZM1cmL83qHJv1l1yqhIUNYY2R+w/zCPZ/547ctB++SfWK9VQ8j
	NvGu9Nfc1ARkDJPhJrAfHYua8A1eLzeatGItWFR9Au6MNuOtn8DVV8TMY8goSKzfzI2gwWwArUR
	GxYt6EBn3N3bPZ6da35/yvPLZwZK81+Nt32ieb+B0OI74KT5M3WA/4UQg568Ca9sLaX/oeWvft3
	ByXrS+ETomhyg2PR20Vveck0C6eCyUjp5VDhcIDiWpS5rVJPniDqK8ZGRm46m/xEj7MtElW/FsB
	F4V0rKiWwsapSkRaGMX0IjwQa4IyU5ZvYV+n
X-Google-Smtp-Source: AGHT+IEOsO6sV4MCY1Ac0WcFKaK+QhC44j8GWAIx8Y6sctbW9PkbKp23aIB6KVS5mQOgDmqcT3rPfQ==
X-Received: by 2002:a05:6000:2cc:b0:386:32ca:7b5e with SMTP id ffacd0b85a97d-38a1a2152c6mr78407f8f.16.1734541702198;
        Wed, 18 Dec 2024 09:08:22 -0800 (PST)
From: Andrew Cooper 
To: Xen-devel 
Cc: Teddy Astie ,
	Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v3] x86/hvm: Use constants for x86 modes
Date: Wed, 18 Dec 2024 17:08:20 +0000
Message-Id: <20241218170820.364253-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Teddy Astie 

In many places of x86 HVM code, constants integer are used to indicate in what mode is
running the CPU (real, vm86, 16-bits, 32-bits, 64-bits). However, these constants are
are written directly as integer which hides the actual meaning of these modes.

This patch introduces X86_MODE_* macros and replace those occurences with it.

Signed-off-by: Teddy Astie 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Teddy Astie 

v3:
 * Leave a comment behind explaining why these aren't all modes
 * Fix long lines
 * Convert more instances (svm_guest_x86_mode, hvm_latch_shinfo_size, xenoprof)
---
 xen/arch/x86/hvm/emulate.c           | 18 ++++++++++--------
 xen/arch/x86/hvm/hvm.c               |  4 +++-
 xen/arch/x86/hvm/hypercall.c         | 17 +++++++++--------
 xen/arch/x86/hvm/svm/svm.c           |  8 ++++----
 xen/arch/x86/hvm/viridian/viridian.c |  8 ++++----
 xen/arch/x86/hvm/vmx/vmx.c           |  9 +++++----
 xen/arch/x86/hvm/vmx/vvmx.c          |  5 +++--
 xen/arch/x86/include/asm/hvm/hvm.h   | 14 ++++++++++++++
 xen/arch/x86/oprofile/xenoprof.c     |  6 +++---
 9 files changed, 55 insertions(+), 34 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index d3006f094a69..76467b76c047 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2433,14 +2433,15 @@ static void cf_check hvmemul_put_fpu(
 
         switch ( mode )
         {
-        case 8:
+        case X86_MODE_64BIT:
             fpu_ctxt->fip.addr = aux->ip;
             if ( dval )
                 fpu_ctxt->fdp.addr = aux->dp;
             fpu_ctxt->x[FPU_WORD_SIZE_OFFSET] = 8;
             break;
 
-        case 4: case 2:
+        case X86_MODE_32BIT:
+        case X86_MODE_16BIT:
             fpu_ctxt->fip.offs = aux->ip;
             fpu_ctxt->fip.sel  = aux->cs;
             if ( dval )
@@ -2451,7 +2452,8 @@ static void cf_check hvmemul_put_fpu(
             fpu_ctxt->x[FPU_WORD_SIZE_OFFSET] = mode;
             break;
 
-        case 0: case 1:
+        case X86_MODE_REAL:
+        case X86_MODE_VM86:
             fpu_ctxt->fip.addr = aux->ip | (aux->cs << 4);
             if ( dval )
                 fpu_ctxt->fdp.addr = aux->dp | (aux->ds << 4);
@@ -2952,11 +2954,11 @@ static const char *guest_x86_mode_to_str(int mode)
 {
     switch ( mode )
     {
-    case 0:  return "Real";
-    case 1:  return "v86";
-    case 2:  return "16bit";
-    case 4:  return "32bit";
-    case 8:  return "64bit";
+    case X86_MODE_REAL:   return "Real";
+    case X86_MODE_VM86:   return "v86";
+    case X86_MODE_16BIT:  return "16bit";
+    case X86_MODE_32BIT:  return "32bit";
+    case X86_MODE_64BIT:  return "64bit";
     default: return "Unknown";
     }
 }
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 74e58c653e6f..922c9b3af64d 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3974,7 +3974,9 @@ static void hvm_latch_shinfo_size(struct domain *d)
      */
     if ( current->domain == d )
     {
-        d->arch.has_32bit_shinfo = (hvm_guest_x86_mode(current) != 8);
+        d->arch.has_32bit_shinfo =
+            hvm_guest_x86_mode(current) != X86_MODE_64BIT;
+
         /*
          * Make sure that the timebase in the shared info structure is correct.
          *
diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index 81883c8d4f60..6f8dfdff4ac6 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -112,23 +112,24 @@ int hvm_hypercall(struct cpu_user_regs *regs)
 
     switch ( mode )
     {
-    case 8:
+    case X86_MODE_64BIT:
         eax = regs->rax;
         fallthrough;
-    case 4:
-    case 2:
+    case X86_MODE_32BIT:
+    case X86_MODE_16BIT:
         if ( currd->arch.monitor.guest_request_userspace_enabled &&
-            eax == __HYPERVISOR_hvm_op &&
-            (mode == 8 ? regs->rdi : regs->ebx) == HVMOP_guest_request_vm_event )
+             eax == __HYPERVISOR_hvm_op &&
+             (mode == X86_MODE_64BIT ? regs->rdi : regs->ebx) ==
+             HVMOP_guest_request_vm_event )
             break;
 
         if ( likely(!hvm_get_cpl(curr)) )
             break;
         fallthrough;
-    default:
+    case X86_MODE_VM86:
         regs->rax = -EPERM;
         return HVM_HCALL_completed;
-    case 0:
+    case X86_MODE_REAL:
         break;
     }
 
@@ -198,7 +199,7 @@ enum mc_disposition hvm_do_multicall_call(struct mc_state *state)
 {
     struct vcpu *curr = current;
 
-    if ( hvm_guest_x86_mode(curr) == 8 )
+    if ( hvm_guest_x86_mode(curr) == X86_MODE_64BIT )
     {
         struct multicall_entry *call = &state->call;
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index b8f87aa1ed08..62905c2c7acd 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -571,12 +571,12 @@ static int cf_check svm_guest_x86_mode(struct vcpu *v)
     struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
 
     if ( unlikely(!(v->arch.hvm.guest_cr[0] & X86_CR0_PE)) )
-        return 0;
+        return X86_MODE_REAL;
     if ( unlikely(guest_cpu_user_regs()->eflags & X86_EFLAGS_VM) )
-        return 1;
+        return X86_MODE_VM86;
     if ( hvm_long_mode_active(v) && likely(vmcb->cs.l) )
-        return 8;
-    return likely(vmcb->cs.db) ? 4 : 2;
+        return X86_MODE_64BIT;
+    return vmcb->cs.db ? X86_MODE_32BIT : X86_MODE_16BIT;
 }
 
 static void cf_check svm_cpuid_policy_changed(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/viridian/viridian.c b/xen/arch/x86/hvm/viridian/viridian.c
index 21480d9ee700..33d54e587edf 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -933,13 +933,13 @@ int viridian_hypercall(struct cpu_user_regs *regs)
 
     switch ( mode )
     {
-    case 8:
+    case X86_MODE_64BIT:
         input.raw = regs->rcx;
         input_params_gpa = regs->rdx;
         output_params_gpa = regs->r8;
         break;
 
-    case 4:
+    case X86_MODE_32BIT:
         input.raw = (regs->rdx << 32) | regs->eax;
         input_params_gpa = (regs->rbx << 32) | regs->ecx;
         output_params_gpa = (regs->rdi << 32) | regs->esi;
@@ -1038,11 +1038,11 @@ int viridian_hypercall(struct cpu_user_regs *regs)
 
     switch ( mode )
     {
-    case 8:
+    case X86_MODE_64BIT:
         regs->rax = output.raw;
         break;
 
-    case 4:
+    case X86_MODE_32BIT:
         regs->rdx = output.raw >> 32;
         regs->rax = (uint32_t)output.raw;
         break;
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index b6885d0e2764..eee1d4b47a13 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -886,14 +886,15 @@ int cf_check vmx_guest_x86_mode(struct vcpu *v)
     unsigned long cs_ar_bytes;
 
     if ( unlikely(!(v->arch.hvm.guest_cr[0] & X86_CR0_PE)) )
-        return 0;
+        return X86_MODE_REAL;
     if ( unlikely(guest_cpu_user_regs()->eflags & X86_EFLAGS_VM) )
-        return 1;
+        return X86_MODE_VM86;
     __vmread(GUEST_CS_AR_BYTES, &cs_ar_bytes);
     if ( hvm_long_mode_active(v) &&
          likely(cs_ar_bytes & X86_SEG_AR_CS_LM_ACTIVE) )
-        return 8;
-    return (likely(cs_ar_bytes & X86_SEG_AR_DEF_OP_SIZE) ? 4 : 2);
+        return X86_MODE_64BIT;
+    return (likely(cs_ar_bytes & X86_SEG_AR_DEF_OP_SIZE)
+            ? X86_MODE_32BIT : X86_MODE_16BIT);
 }
 
 static void vmx_save_dr(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 78135ca23be8..cf47d61b1473 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -411,7 +411,7 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
     }
     else
     {
-        bool mode_64bit = (vmx_guest_x86_mode(v) == 8);
+        bool mode_64bit = vmx_guest_x86_mode(v) == X86_MODE_64BIT;
 
         decode->type = VMX_INST_MEMREG_TYPE_MEMORY;
 
@@ -2073,7 +2073,8 @@ int nvmx_handle_vmx_insn(struct cpu_user_regs *regs, unsigned int exit_reason)
 
     if ( !(curr->arch.hvm.guest_cr[4] & X86_CR4_VMXE) ||
          !nestedhvm_enabled(curr->domain) ||
-         (vmx_guest_x86_mode(curr) < (hvm_long_mode_active(curr) ? 8 : 2)) ||
+         (vmx_guest_x86_mode(curr) <
+          (hvm_long_mode_active(curr) ? X86_MODE_64BIT : X86_MODE_16BIT)) ||
          (exit_reason != EXIT_REASON_VMXON && !nvmx_vcpu_in_vmx(curr)) )
     {
         hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC);
diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h
index 02de18c7d4a8..124906a548da 100644
--- a/xen/arch/x86/include/asm/hvm/hvm.h
+++ b/xen/arch/x86/include/asm/hvm/hvm.h
@@ -26,6 +26,20 @@ extern bool opt_hvm_fep;
 #define opt_hvm_fep 0
 #endif
 
+/*
+ * Results for hvm_guest_x86_mode().
+ *
+ * Note, some callers depend on the order of these constants.
+ *
+ * TODO: Rework this helper to avoid implying mixing the architectural
+ * concepts of mode and operand size.
+ */
+#define X86_MODE_REAL  0
+#define X86_MODE_VM86  1
+#define X86_MODE_16BIT 2
+#define X86_MODE_32BIT 4
+#define X86_MODE_64BIT 8
+
 /* Interrupt acknowledgement sources. */
 enum hvm_intsrc {
     hvm_intsrc_none,
diff --git a/xen/arch/x86/oprofile/xenoprof.c b/xen/arch/x86/oprofile/xenoprof.c
index 247a0deca822..7f2525bfb4d6 100644
--- a/xen/arch/x86/oprofile/xenoprof.c
+++ b/xen/arch/x86/oprofile/xenoprof.c
@@ -86,11 +86,11 @@ int xenoprofile_get_mode(struct vcpu *curr, const struct cpu_user_regs *regs)
 
     switch ( hvm_guest_x86_mode(curr) )
     {
-    case 0: /* real mode */
+    case X86_MODE_REAL:
         return 1;
-    case 1: /* vm86 mode */
+    case X86_MODE_VM86:
         return 0;
-    default:
+    default: /* 16BIT | 32BIT | 64BIT */
         return hvm_get_cpl(curr) != 3;
     }
 }

base-commit: 826a9eb072d449cb777d71f52923e6f5f20cefbe
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 17:58:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 17:58:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860706.1272703 (Exim 4.92)
	(envelope-from )
	id 1tNyJb-0002oq-He; Wed, 18 Dec 2024 17:58:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860706.1272703; Wed, 18 Dec 2024 17:58: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 1tNyJb-0002oj-Es; Wed, 18 Dec 2024 17:58:31 +0000
Received: by outflank-mailman (input) for mailman id 860706;
 Wed, 18 Dec 2024 17:58:29 +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 1tNyJZ-0002oc-M0
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 17:58:29 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id aea523cb-bd69-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 18:58:27 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-aa69077b93fso1018220466b.0
 for ; Wed, 18 Dec 2024 09:58:27 -0800 (PST)
Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab96005f73sm581353066b.4.2024.12.18.09.58.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 18 Dec 2024 09:58: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: aea523cb-bd69-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734544706; x=1735149506; 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=0Vta22zvzKVvQJh7L1iAoOLDMNpOa2sF2ZKHPn3LP54=;
        b=NeLJq7EC3JPVVzWVB5+pIjax4EF9B70DmOVqDL9Jr9Wed/cDHrFh9wajxA5cm48+PL
         spKl1/FZFBF1qI9sGuCJDdyhWQsTzH9yHXMj4h2ysTcxy7/1EVnLnRi/nswn0OcwQPPa
         b5ISDEUUAldJBsKVPk4U9WuKsb6BIOV8MHIYM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734544706; x=1735149506;
        h=in-reply-to:content-transfer-encoding:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=0Vta22zvzKVvQJh7L1iAoOLDMNpOa2sF2ZKHPn3LP54=;
        b=h6DfhoZ5PM1kal5P7xI7anTzCN/Gh1gXoOpwE2mWPRoAboLSbrU9praLt6HKDcl8mz
         fUSqqlk9MExH9cbo73m+qFuUqk5exz53c7bsoWwsccDBkMH2eAj1wMTkFRgkymVy13GN
         +Ef/u+Q+zkTv2aXJxwrG8fCpeOpL1qYJ+8Q2+QcdfHF3tSRbi6ghiUxipB00yzZkRMhz
         ao/ikhz+7rIrxa1xegT3tEF9spxHoVjsqkOB6p7cSGMTxejfAy9dkvtTbkNOWd2Ds//p
         KIkSs7R1tnlVndfu2KMFUc2w+Cy2YCBgaNENR0NGMcB0dBgL1uXp2XzpqhSLCIxFSiJS
         rBhg==
X-Gm-Message-State: AOJu0YzanMz7hkEwLPjnu32MwPSxTm9gVXFCX3n+caEtCnHe7rXEyfkX
	ye5Xp2DmJXeVxG1d0FNb5PNIWasne018ubvpRPTBUq52fCLEEnSWRTMmxdWFrtsKS7rP6OpOGVe
	X
X-Gm-Gg: ASbGncvRks3hYFAyn6xNAlemIxTX6+j25rHRt0+DNeuAjnngHgeP5CNE7gLRPMWpJBZ
	Z/ohjwNlRGAT/xD06S06et+h82R7Sdxw1o7IuKfJ2EdG8m0ztEXh8MIG2YYRyVF+LKItq0nOGYm
	iVF0N9PwcQ5XNXrj/JAepQWUkHwAhkxntpw/0XZv1Ipl04sBPhBYxM0adbjV2wzUENGMAQs0ag+
	h1MFCj/rFUB7/sZnbtUr4Qe6JdAZBQ1ZNu7gWTUjasnjjxxmN8yP30qgAx6Ig==
X-Google-Smtp-Source: AGHT+IE36nF8Vv+G+Ax4cVHLopoSTV7V+o2MBiWGkwPzCvyFLheY7n76XyvgbEVyRB4BPQBJmPQA3g==
X-Received: by 2002:a17:907:7709:b0:aac:83f:e10a with SMTP id a640c23a62f3a-aac083fe1b6mr12356366b.19.1734544706513;
        Wed, 18 Dec 2024 09:58:26 -0800 (PST)
Date: Wed, 18 Dec 2024 18:58:25 +0100
From: Roger Pau =?utf-8?B?TW9ubsOp?= 
To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
Cc: xen-devel@lists.xenproject.org,
	Anthony PERARD ,
	Juergen Gross 
Subject: Re: [PATCH] tools/xg: increase LZMA_BLOCK_SIZE for uncompressing the
 kernel
Message-ID: 
References: <20241008213225.728922-1-marmarek@invisiblethingslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20241008213225.728922-1-marmarek@invisiblethingslab.com>

On Tue, Oct 08, 2024 at 11:32:23PM +0200, Marek Marczykowski-Górecki wrote:
> Linux 6.12-rc2 fails to decompress with the current 128MiB, contrary to
> the code comment. It results in a failure like this:
> 
>     domainbuilder: detail: xc_dom_kernel_file: filename="/var/lib/qubes/vm-kernels/6.12-rc2-1.1.fc37/vmlinuz"
>     domainbuilder: detail: xc_dom_malloc_filemap    : 12104 kB
>     domainbuilder: detail: xc_dom_module_file: filename="/var/lib/qubes/vm-kernels/6.12-rc2-1.1.fc37/initramfs"
>     domainbuilder: detail: xc_dom_malloc_filemap    : 7711 kB
>     domainbuilder: detail: xc_dom_boot_xen_init: ver 4.19, caps xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
>     domainbuilder: detail: xc_dom_parse_image: called
>     domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ...
>     domainbuilder: detail: loader probe failed
>     domainbuilder: detail: xc_dom_find_loader: trying HVM-generic loader ...
>     domainbuilder: detail: loader probe failed
>     domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ...
>     domainbuilder: detail: _xc_try_lzma_decode: XZ decompression error: Memory usage limit reached
>     xc: error: panic: xg_dom_bzimageloader.c:761: xc_dom_probe_bzimage_kernel unable to XZ decompress kernel: Invalid kernel
>     domainbuilder: detail: loader probe failed
>     domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ...
>     domainbuilder: detail: loader probe failed
>     xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader found: Invalid kernel
>     libxl: error: libxl_dom.c:566:libxl__build_dom: xc_dom_parse_image failed
> 
> The important part: XZ decompression error: Memory usage limit reached
> 
> This looks to be related to the following change in Linux:
> 8653c909922743bceb4800e5cc26087208c9e0e6 ("xz: use 128 MiB dictionary and force single-threaded mode")
> 
> Fix this by increasing the block size to 256MiB. And remove the
> misleading comment (from lack of better ideas).
> 
> Signed-off-by: Marek Marczykowski-Górecki 

Reviewed-by: Roger Pau Monné 

I assumed I already RB this, but it seems not.

Could we get an Ack from the tools or libs maintainer for this to go
in?  It's not the best solution, but we need to get this sorted in
time for 4.20, and backport to stable branches.

Thanks, Roger.


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 18:23:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 18:23:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860716.1272712 (Exim 4.92)
	(envelope-from )
	id 1tNyhP-0006xr-BF; Wed, 18 Dec 2024 18:23:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860716.1272712; Wed, 18 Dec 2024 18:23: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 1tNyhP-0006xk-8I; Wed, 18 Dec 2024 18:23:07 +0000
Received: by outflank-mailman (input) for mailman id 860716;
 Wed, 18 Dec 2024 18:23: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 1tNyhN-0006xO-L8
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 18:23:05 +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 1ea3ed7e-bd6d-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 19:23:03 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-436249df846so47593145e9.3
 for ; Wed, 18 Dec 2024 10:23:03 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-388c80473c6sm14892985f8f.80.2024.12.18.10.23.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Dec 2024 10:23: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: 1ea3ed7e-bd6d-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734546183; x=1735150983; 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=PrnorXnwpqmWEpMhBImRd1eafu9+696TUxmc4Va37CU=;
        b=czoCpH1RkBW1Z/gTW7dtLWgGA+oLb8o0ifzsFSQ3jXasi0k/allZzzifXnBUKgi4OA
         UhIuNzLYT+oxa33a4cmTWT2NyblqYfFgnV8joD7Lw7+Z+JEnr+/NFYXHnQABoufTiGok
         gBZJUsJ/Jl2XwXZ//KzxVMUS29WqJp7Q6G1Ho=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734546183; x=1735150983;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=PrnorXnwpqmWEpMhBImRd1eafu9+696TUxmc4Va37CU=;
        b=KeCx+LNjj3k4D908LW3VhZ9QZGbKenjvRWt6xKp6JNvVrR6QmqX/cepDxPzrOPjW8k
         Plh7kmBvhCmsf6qF0I1U5+Y9zMGarK66xD7GlGJ9GE1WJdBbktSOKjnLQ8hw/8bcSowe
         7skchNKiv+9VInk13LoyNxuNovTqdMRG35E6/1q0QgknBWnF5+hF6tPYKM5svyPAoKEA
         btAqg64ZpHruokywgQzfA0SVzx3xt5YyZbpMNsp2+MEPDfdj3WbrTJ3w18Dt/0nX8dba
         9yi4kireBBRhVLvvULgHHUXTcIPOvc6PAwZEh6O9SAvnBQo1JuokuZLjrbdgX+sfQ6PS
         Ateg==
X-Gm-Message-State: AOJu0YyI0ds7ZF+6vVq/XjCAnQpankJ5Ku+rXLDBxAvnDT/G5qQdC6Dk
	nes1+Kxjhxwapo08SBJ/dL15/hGCuFnn9u0NTg8ARxy+WkQIAt2KK+HZZTQLsZA=
X-Gm-Gg: ASbGncsAKMu125lxXr2YYwfAk1dIicabZWc2oWEE88cBPlpVmPhPR2qghMh4fRzEZt8
	WirBCxKkh5K0Mxslq/8v1zu0dlJAIWWmhRthAgfTqj6OEe4obPyh7jdcpEZAxdrIfWckmkn9ldY
	2PepwtKDCPrbFyubyq6KXBMnujlRTG91GMF8N6cn4UeopuGVgeDxscKuBs8fyvboRHJvUnGa/Me
	vjgd6TKif3wyoptsy4/8derkp7pm4JMRPRI8zzj+4nR1H1eJUfsxfdC/mS35A1a6nlK3iM3EcM/
	T5deAQ8cWzsIL0DFJlPi
X-Google-Smtp-Source: AGHT+IFKNfmczvTldmk/mLbelf9YoamougVEF6g+xmKT8yCQavS/iSuM6lb4KTCjNxN93ESRYOrGhA==
X-Received: by 2002:a05:6000:460b:b0:386:2e8c:e277 with SMTP id ffacd0b85a97d-38a19b48f11mr637909f8f.55.1734546182964;
        Wed, 18 Dec 2024 10:23:02 -0800 (PST)
Message-ID: 
Date: Wed, 18 Dec 2024 18:23:01 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] tools/xg: increase LZMA_BLOCK_SIZE for uncompressing the
 kernel
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
Cc: xen-devel@lists.xenproject.org, Anthony PERARD
 , Juergen Gross 
References: <20241008213225.728922-1-marmarek@invisiblethingslab.com>
 
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 18/12/2024 5:58 pm, Roger Pau Monné wrote:
> On Tue, Oct 08, 2024 at 11:32:23PM +0200, Marek Marczykowski-Górecki wrote:
>> Linux 6.12-rc2 fails to decompress with the current 128MiB, contrary to
>> the code comment. It results in a failure like this:
>>
>>     domainbuilder: detail: xc_dom_kernel_file: filename="/var/lib/qubes/vm-kernels/6.12-rc2-1.1.fc37/vmlinuz"
>>     domainbuilder: detail: xc_dom_malloc_filemap    : 12104 kB
>>     domainbuilder: detail: xc_dom_module_file: filename="/var/lib/qubes/vm-kernels/6.12-rc2-1.1.fc37/initramfs"
>>     domainbuilder: detail: xc_dom_malloc_filemap    : 7711 kB
>>     domainbuilder: detail: xc_dom_boot_xen_init: ver 4.19, caps xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
>>     domainbuilder: detail: xc_dom_parse_image: called
>>     domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ...
>>     domainbuilder: detail: loader probe failed
>>     domainbuilder: detail: xc_dom_find_loader: trying HVM-generic loader ...
>>     domainbuilder: detail: loader probe failed
>>     domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ...
>>     domainbuilder: detail: _xc_try_lzma_decode: XZ decompression error: Memory usage limit reached
>>     xc: error: panic: xg_dom_bzimageloader.c:761: xc_dom_probe_bzimage_kernel unable to XZ decompress kernel: Invalid kernel
>>     domainbuilder: detail: loader probe failed
>>     domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ...
>>     domainbuilder: detail: loader probe failed
>>     xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader found: Invalid kernel
>>     libxl: error: libxl_dom.c:566:libxl__build_dom: xc_dom_parse_image failed
>>
>> The important part: XZ decompression error: Memory usage limit reached
>>
>> This looks to be related to the following change in Linux:
>> 8653c909922743bceb4800e5cc26087208c9e0e6 ("xz: use 128 MiB dictionary and force single-threaded mode")
>>
>> Fix this by increasing the block size to 256MiB. And remove the
>> misleading comment (from lack of better ideas).
>>
>> Signed-off-by: Marek Marczykowski-Górecki 
> Reviewed-by: Roger Pau Monné 
>
> I assumed I already RB this, but it seems not.
>
> Could we get an Ack from the tools or libs maintainer for this to go
> in?  It's not the best solution, but we need to get this sorted in
> time for 4.20, and backport to stable branches.

I agree.  This isn't great, but it's far better than doing nothing, and
there's no other viable alternative proposed.

Acked-by: Andrew Cooper 

~Andrew


From xen-devel-bounces@lists.xenproject.org Wed Dec 18 18:55:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 18:55:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860730.1272723 (Exim 4.92)
	(envelope-from )
	id 1tNzCG-0002ez-Qc; Wed, 18 Dec 2024 18:55:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860730.1272723; Wed, 18 Dec 2024 18: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 1tNzCG-0002es-Na; Wed, 18 Dec 2024 18:55:00 +0000
Received: by outflank-mailman (input) for mailman id 860730;
 Wed, 18 Dec 2024 18:54:59 +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 1tNzCF-0002em-Ob
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 18:54:59 +0000
Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com
 [2a00:1450:4864:20::542])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 938fec8e-bd71-11ef-99a3-01e77a169b0f;
 Wed, 18 Dec 2024 19:54:57 +0100 (CET)
Received: by mail-ed1-x542.google.com with SMTP id
 4fb4d7f45d1cf-5d3e9f60bf4so10840473a12.3
 for ; Wed, 18 Dec 2024 10:54:57 -0800 (PST)
Received: from andrewcoop.eng.citrite.net (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aab9638feb1sm588614666b.148.2024.12.18.10.54.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 18 Dec 2024 10:54:56 -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: 938fec8e-bd71-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734548097; x=1735152897; 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=8103aj5lrJEj1q3pqVlywEA8Z37eSmoPB+FzM9bQTh8=;
        b=HRY5CAc7uNCS1Iwz/rZ42WjwdRMW7tM2lwksCREwY+w/Hc8odCqG6AskUW1FODDwIJ
         XSUupfDdtdo8xVT16YHmRLlolJXz1T0W5QeY3G2NIywUP19oaj0CJgdv2edVElzbBsh6
         jmNQr3yPUdKEFvNwCXt/nYAa7o9G7NlqPimhQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734548097; x=1735152897;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=8103aj5lrJEj1q3pqVlywEA8Z37eSmoPB+FzM9bQTh8=;
        b=SIOqSGvBOncTHBabo+KMDP6CXs/FE9glaxAsjwitpYC5HqIWh8xZiSH8J7pcnBUnz1
         3CzX4cyvZ1bYFFegWpn443OSH+mJWu80hpyS6gN9kI636t0x88IZVZJaEDC5nbl6elpD
         a+nByIooMkb5T2S6JLgYUD/GAvAsgzhY6cJS+f+fRGpOSBWQSHFw5i7rtEhcVBmsEi4E
         hOxrATtiyfPEWpCrZ/XCZOygGJgtjqJFy6p7o1pwetg6S5vOO8B6GSNj9C5mJDKAV+zw
         K4z5HxAHKhLP+cH2IRRkL5qXMhkocY/1gI9f+L3+DJUK694EbgJFz5z5nuQCLECt/fJ+
         Ur8w==
X-Gm-Message-State: AOJu0Yz6Ywrz+W9a57oqjw0tbVWMOtcgJTBmLw6HmPsjZIMdT13ZW/sQ
	W1jgFz8056G3OvPsWkYmlNL8ZXLEp7IlbD4Or/ncgcjrhhKn0SYOb479Mh+3yizSn2bA65wIcM0
	oEw7zjA==
X-Gm-Gg: ASbGncu9hjor7+7EsfYUELSwteNjB1fIvuPUoXL1YVkPHJhuDbIjoXv4gmse3WDadlO
	x1I/LEVDgNE3OahYFTnu9OEValc4/6BUYDLH2udnIRCFh5Ajf0Q6S9Wk/8vECnp4pPkfnsjblGq
	mCj8ViiusCWineLEQifLoEV3oO5h1PdKP/y9s/7c2E+l4pWO2Acf76UlFMQEp9oukjiYb2zXSOA
	+hExoSxtq1ZF7MEvm3Gb/9FsFyHu2rerfiGrVG7SpUbBe0v/G+z4t1NZINxmD2DNy904uB06kkb
	gLpn5ZHm9dNk7p/0SjpsADZ65h77+rHBYNCc
X-Google-Smtp-Source: AGHT+IFb8b5rHNPaCvAiuqhDQKGrarCxaxWTHbvgqoCNRFC4fy2Lf4hIylAxu3ecEWq6MRvxqxKyTw==
X-Received: by 2002:a17:906:dc95:b0:aa6:8a1b:8b7c with SMTP id a640c23a62f3a-aabf46faf75mr352865766b.2.1734548096662;
        Wed, 18 Dec 2024 10:54:56 -0800 (PST)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Anthony PERARD ,
	Juergen Gross ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Oleksii Kurochko 
Subject: [PATCH v2] tools/libxg: Don't gunzip the guests initrd
Date: Wed, 18 Dec 2024 18:54:53 +0000
Message-Id: <20241218185453.367465-1-andrew.cooper3@citrix.com>
X-Mailer: git-send-email 2.39.5
In-Reply-To: <20240904123121.3837140-1-andrew.cooper3@citrix.com>
References: <20240904123121.3837140-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Decompressing the kernel is necessary to inspect the ELF notes, but the
dombuilder will gunzip() secondary modules too.  Specifically gunzip(), no
other decompression algorithms.

This may have been necessary in the dim and distant past, but it is broken
today.  Linux specifically supports concatenating CPIO fragments of differing
compressions, and any attempt to interpret it with a single algorithm may
corrupt later parts.

This was an unexpected discovery while trying to test Xen's gunzip()
logic (Xen as a PVH guest, with a gzipped XTF kernel as dom0).

Intepreting secondary modules *should* be left as an exersize to the guest.
This reduces work done in dom0.

This is not expected to cause a practical different to guests these days.

Signed-off-by: Andrew Cooper 
---
CC: Anthony PERARD 
CC: Juergen Gross 
CC: Anthony PERARD 
CC: Michal Orzel 
CC: Jan Beulich 
CC: Julien Grall 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Oleksii Kurochko 

v2:
 * Rewrite the commit message.

If this does cause a problem, we can reintroduce it, but behind a config
option because it needs to not be on by default.

Linux's habit of prepending an uncompressed CPIO containing microcode is
likely to cause this logic to be skipped anyway.
---
 CHANGELOG.md                   |  2 ++
 tools/libs/guest/xg_dom_core.c | 40 ++++++----------------------------
 2 files changed, 9 insertions(+), 33 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 15f681459f22..61510e6a11c0 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -8,6 +8,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 
 ### Changed
  - Fixed blkif protocol specification for sector sizes different than 512b.
+ - The dombuilder in libxenguest no longer un-gzips secondary modules, instead
+   leaving this to the guest kernel to do in guest context.
  - On x86:
    - Prefer ACPI reboot over UEFI ResetSystem() run time service call.
    - Switched the xAPIC flat driver to use physical destination mode for external
diff --git a/tools/libs/guest/xg_dom_core.c b/tools/libs/guest/xg_dom_core.c
index f5521d528be1..595b0a667c03 100644
--- a/tools/libs/guest/xg_dom_core.c
+++ b/tools/libs/guest/xg_dom_core.c
@@ -980,37 +980,24 @@ int xc_dom_mem_init(struct xc_dom_image *dom, unsigned int mem_mb)
 
 static int xc_dom_build_module(struct xc_dom_image *dom, unsigned int mod)
 {
-    size_t unziplen, modulelen;
+    size_t modulelen;
     void *modulemap;
     char name[10];
 
-    if ( !dom->modules[mod].seg.vstart )
-        unziplen = xc_dom_check_gzip(dom->xch,
-                                     dom->modules[mod].blob, dom->modules[mod].size);
-    else
-        unziplen = 0;
+    modulelen = dom->modules[mod].size;
 
-    modulelen = max(unziplen, dom->modules[mod].size);
-    if ( dom->max_module_size )
+    if ( dom->max_module_size && modulelen > dom->max_module_size )
     {
-        if ( unziplen && modulelen > dom->max_module_size )
-        {
-            modulelen = min(unziplen, dom->modules[mod].size);
-            if ( unziplen > modulelen )
-                unziplen = 0;
-        }
-        if ( modulelen > dom->max_module_size )
-        {
-            xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
-                         "module %u image too large", mod);
-            goto err;
-        }
+        xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
+                     "module %u image too large", mod);
+        goto err;
     }
 
     snprintf(name, sizeof(name), "module%u", mod);
     if ( xc_dom_alloc_segment(dom, &dom->modules[mod].seg, name,
                               dom->modules[mod].seg.vstart, modulelen) != 0 )
         goto err;
+
     modulemap = xc_dom_seg_to_ptr(dom, &dom->modules[mod].seg);
     if ( modulemap == NULL )
     {
@@ -1018,21 +1005,8 @@ static int xc_dom_build_module(struct xc_dom_image *dom, unsigned int mod)
                   __FUNCTION__, mod);
         goto err;
     }
-    if ( unziplen )
-    {
-        if ( xc_dom_do_gunzip(dom->xch, dom->modules[mod].blob, dom->modules[mod].size,
-                              modulemap, unziplen) != -1 )
-            return 0;
-        if ( dom->modules[mod].size > modulelen )
-            goto err;
-    }
 
-    /* Fall back to handing over the raw blob. */
     memcpy(modulemap, dom->modules[mod].blob, dom->modules[mod].size);
-    /* If an unzip attempt was made, the buffer may no longer be all zero. */
-    if ( unziplen > dom->modules[mod].size )
-        memset(modulemap + dom->modules[mod].size, 0,
-               unziplen - dom->modules[mod].size);
 
     return 0;
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 23:38:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 23:38:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860749.1272732 (Exim 4.92)
	(envelope-from )
	id 1tO3cD-0007ct-UQ; Wed, 18 Dec 2024 23:38:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860749.1272732; Wed, 18 Dec 2024 23:38:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tO3cD-0007cm-Rv; Wed, 18 Dec 2024 23:38:05 +0000
Received: by outflank-mailman (input) for mailman id 860749;
 Wed, 18 Dec 2024 23:38: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 1tO3cB-0007cb-HN
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 23:38:03 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1e509b66-bd99-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 00:38:01 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 19 Dec 2024 00:38:00 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id 0DFCB220D;
 Thu, 19 Dec 2024 00:37:59 +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: 1e509b66-bd99-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734565081; x=1766101081;
  h=from:to:cc:subject:date:message-id:mime-version:
   content-transfer-encoding;
  bh=TbLPYOCWNBMuc69GXdHkTQIYIZddX/mOQ08vzXVrC4o=;
  b=y/Fd2gGY1l5DQTx/ROQamhbsYu+UC4xV/iNfrSfaBWai7S7a6HLE2uem
   HVGnfcg4GZ6yZM0/QdjGKfTXu0Lpt74Souqc/J2TEPORBNbq5DeMdJzBU
   WsOKFqZXVuX8Rqr9r5UPsCZ/j0PbL0WR2S0Dvj7QLkYxSEEIYXxzJkbVQ
   I=;
X-CSE-ConnectionGUID: lDmKyavMS2elcNs3yReexA==
X-CSE-MsgGUID: xeM/ET2ETRGL25cnclu7KA==
X-IronPort-AV: E=Sophos;i="6.12,246,1728943200"; 
   d="scan'208";a="28246236"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Ariel Otilibili ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH 0/1] xen/common: Remove dead code
Date: Thu, 19 Dec 2024 00:34:51 +0100
Message-ID: <20241218233659.573195-2-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

This patch fixes Coverity-ID 1055253. Its history says a fix was required.

Thank you,

Link: https://scan5.scan.coverity.com/#/project-view/63598/10426?selectedIssue=1055253

Ariel Otilibili (1):
  xen/common: Remove dead code

 xen/common/gzip/inflate.c | 2 --
 1 file changed, 2 deletions(-)

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Wed Dec 18 23:38:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Dec 2024 23:38:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860750.1272743 (Exim 4.92)
	(envelope-from )
	id 1tO3cF-0007qr-5I; Wed, 18 Dec 2024 23:38:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860750.1272743; Wed, 18 Dec 2024 23:38: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 1tO3cF-0007qk-25; Wed, 18 Dec 2024 23:38:07 +0000
Received: by outflank-mailman (input) for mailman id 860750;
 Wed, 18 Dec 2024 23:38: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 1tO3cD-0007cb-Kp
 for xen-devel@lists.xenproject.org; Wed, 18 Dec 2024 23:38:05 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 20c74b54-bd99-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 00:38:05 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 19 Dec 2024 00:38:04 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id A4113220E;
 Thu, 19 Dec 2024 00:38:04 +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: 20c74b54-bd99-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734565085; x=1766101085;
  h=from:to:cc:subject:date:message-id:in-reply-to:
   references:mime-version:content-transfer-encoding;
  bh=5QaKobd7b9odKGMX5HCBA+z80oGMre/u1pGcu2wcmn4=;
  b=gL8Vy3pxFnQ5qT2qJfNnC8WEeTf6AaIQyhm8c5dzrtqj8YJHEAVFE8+x
   mWDw2KEKPfEdn3M7GXqrYsHKQlrCZN/UpoduxOuaG+9vBj6Cn5OMIdWEp
   qloRiy9YKDU0heCdtIJj98mXM0cPdppTzTqZb99JTQw7rxJzyWmdeWjpP
   4=;
X-CSE-ConnectionGUID: S2Z35sNeRruTDq9YoVJcBg==
X-CSE-MsgGUID: 10mpN/WLSJSo2rKjFu0TZw==
X-IronPort-AV: E=Sophos;i="6.12,246,1728943200"; 
   d="scan'208";a="28246237"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Ariel Otilibili ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH 1/1] xen/common: Remove dead code
Date: Thu, 19 Dec 2024 00:34:52 +0100
Message-ID: <20241218233659.573195-3-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20241218233659.573195-2-Ariel.Otilibili-Anieli@eurecom.fr>
References: <20241218233659.573195-2-Ariel.Otilibili-Anieli@eurecom.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The if-statement tests `res` is non-zero; meaning the case zero is never reached.

Coverity-ID: 1055253
Fixes: e2b1ebf4de ("x86: Support booting a bzImage format domain 0 kernel.")
Signed-off-by: Ariel Otilibili 
--
Cc: Andrew Cooper 
Cc: Anthony PERARD 
Cc: Michal Orzel 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: "Roger Pau Monné" 
Cc: Stefano Stabellini 
---
 xen/common/gzip/inflate.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/xen/common/gzip/inflate.c b/xen/common/gzip/inflate.c
index b9a2d7a23a..cb146555c8 100644
--- a/xen/common/gzip/inflate.c
+++ b/xen/common/gzip/inflate.c
@@ -1164,8 +1164,6 @@ static int __init gunzip(struct gunzip_state *s)
     if ( (res = inflate(s)) )
     {
         switch (res) {
-        case 0:
-            break;
         case 1:
             error("invalid compressed format (err=1)");
             break;
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 00:21:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 00:21:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860768.1272753 (Exim 4.92)
	(envelope-from )
	id 1tO4Hk-0006Re-A9; Thu, 19 Dec 2024 00:21:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860768.1272753; Thu, 19 Dec 2024 00:21:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tO4Hk-0006RX-6c; Thu, 19 Dec 2024 00:21:00 +0000
Received: by outflank-mailman (input) for mailman id 860768;
 Thu, 19 Dec 2024 00:20: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 1tO4Hi-0006RN-Eu
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 00:20:58 +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 1dae5aee-bd9f-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 01:20:57 +0100 (CET)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3863494591bso136086f8f.1
 for ; Wed, 18 Dec 2024 16:20:57 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43661200ae5sm786175e9.17.2024.12.18.16.20.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Dec 2024 16:20: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: 1dae5aee-bd9f-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734567656; x=1735172456; 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=pxGK6h4H66Egfx0J8LK6VTpbKmkU4MTj87CRDk+DtAE=;
        b=CCV8p436AmcGnKaWjFQ7o3TsYP1HuQBCAOBVwcJXv0QwlB2wLnSLR0ojR1TXYwvIpL
         mjuxWn9wox3Dc/CktF337zBvoBVgrM/UKDkyBCXEuqTrOMD3zO/1u9wJbB84Ino4l+4J
         M3jJea1nmRwx5Lkcsy/E3rJLCnAr2J2kY3RFg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734567656; x=1735172456;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pxGK6h4H66Egfx0J8LK6VTpbKmkU4MTj87CRDk+DtAE=;
        b=cBeY+A1Vi+udHacEs7kK4ACnsZX5GR7f0AF3QToBioL+wDRcIaFQ7KlJTMRBz1lv9q
         aY/SYr24khosRYHFOmgZqGYZTOtSRUsFxxHJH5TVpjsZGcb6vkCT6xJi8r3+DDYh0InC
         MTQ+UpkwXRrkec9GVTeIxW9HUd7aexKaHUdVgl9bHcatGUNGv5hXTiVMxlj+e9ACrnMF
         sFkehrvOfuZc/OZ54N4kUlHfVXKTn147VC3WCM1ZN3/lKj783hAfhgYz/o2DJagOf7Mt
         dUs+haMvrWggssH1Ti4LcfiztzqKqr1o4ujM8qk7XsdBAc05fprUlRgiHKKgbRRhFoff
         TcKw==
X-Forwarded-Encrypted: i=1; AJvYcCXYu+ODE34V8SQQ4C39iOAuETMyBD2MTxcxi8JqLRU20K7UluEkaeuopFJa3GVbNGavtiP7rjGD8/0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzYhxs9W0dWRjoC0HitTnR0lI0foZzK+IJraiFXZ5osSbxu7fiN
	xFuFteV22YnR4khP+yivfLAkAqPGFEfSjLLj/NqWCu+oN9RBTGQS4Ouo7CtF1wY=
X-Gm-Gg: ASbGncspB9TxZgwjU+fF98cJLgJNUCfYygKdyPCl3rn5O+jIxJKfMSJ8puf5JGHVsXK
	ku/jG0BcSfZPOU4HTyDaxE5m23zT3/IOtBb1Nv8d6l5KPQmMgr1o6ig3C+rPQuQsbP+ISsJumQx
	C7ZhpxjF8/UOkxab37Flz77ARBRaED9yZWEOpp4jCCRpFOIzyBPUTkU7fYlol2b0n1nKD0ZzSZM
	o8+acLHTbkSeYEh7BUbNKF7zVWHr2Zpy/HXK0aofYMQ/Wmg64+aOdWCYVmk3CCf57Z/iAlLBGHu
	dQgZSUpw4BbM9Q3oTh9L
X-Google-Smtp-Source: AGHT+IGpB63hGH6bETDA1DwzQcggTb05+40DCH/gDr4iAOkyT8QBV6+Pg2nCxJMBM+zUJ4zEoGTfqQ==
X-Received: by 2002:a5d:6d09:0:b0:385:fd07:85f8 with SMTP id ffacd0b85a97d-38a19af2014mr1093330f8f.29.1734567656430;
        Wed, 18 Dec 2024 16:20:56 -0800 (PST)
Message-ID: 
Date: Thu, 19 Dec 2024 00:20:55 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/3] Add stack protector
To: Jan Beulich 
Cc: Julien Grall , Stefano Stabellini
 , Anthony PERARD ,
 Samuel Thibault ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Bertrand Marquis ,
 Michal Orzel ,
 "xen-devel@lists.xenproject.org" ,
 Volodymyr Babchuk 
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
  <87pllx3gib.fsf@epam.com>
 
 <9056a92d-8e91-4f2d-a8f3-5cde378f6c6f@suse.com>
 <7aea0e1d-f60c-4e82-8b63-c4e18cbcce85@suse.com>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <7aea0e1d-f60c-4e82-8b63-c4e18cbcce85@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 12/12/2024 4:52 pm, Jan Beulich wrote:
> On 12.12.2024 15:30, Jan Beulich wrote:
>> On 12.12.2024 02:17, Andrew Cooper wrote:
>>> (With the knowledge that this is a disputed Kconfig pattern, and will
>>> need rebasing), the way I want this to work is simply:
>>>
>>> diff --git a/xen/Makefile b/xen/Makefile
>>> index 0de0101fd0bf..5d0a88fb3c3f 100644
>>> --- a/xen/Makefile
>>> +++ b/xen/Makefile
>>> @@ -434,6 +434,9 @@ endif
>>>  
>>>  ifeq ($(CONFIG_STACK_PROTECTOR),y)
>>>  CFLAGS += -fstack-protector
>>> +ifeq ($(CONFIG_X86),y)
>>> +CFLAGS += -mstack-protector-guard=global
>>> +endif
>>>  else
>>>  CFLAGS += -fno-stack-protector
>>>  endif
>>> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
>>> index 9cdd04721afa..7951ca908b36 100644
>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -28,6 +28,7 @@ config X86
>>>         select HAS_PCI_MSI
>>>         select HAS_PIRQ
>>>         select HAS_SCHED_GRANULARITY
>>> +       select HAS_STACK_PROTECTOR if
>>> $(cc-option,-mstack-protector-guard=global)
>>>         select HAS_UBSAN
>>>         select HAS_VMAP
>>>         select HAS_VPCI if HVM
>>>
>>>
>>>
>>> Sadly, it doesn't build.  I get a handful of:
>>>
>>> prelink.o: in function `cmdline_parse':
>>> /home/andrew/xen.git/xen/common/kernel.c:216:(.init.text+0x20f2): failed
>>> to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
>>> --no-relax
>>> /home/andrew/xen.git/xen/common/kernel.c:230:(.init.text+0x246f): failed
>>> to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
>>> --no-relax
>>>
>>> which is more toolchain-whispering than I feel like doing tonight.
>> Imo the root of the problem is that the compiler doesn't itself mark
>> __stack_chk_guard hidden (it does so for __stack_chk_fail, albeit only for
>> 32-bit code), and hence finds it necessary to use @gotpcrel to access the
>> variable. Even if the linker managed to relax all of these, it would then
>> still be less efficient compared to direct RIP-relative accesses.
>>
>> I also can't see how we might be able to override the compiler's internal
>> declaration to mark it hidden (the same appears to be true for other items
>> the declares internally, like the retpoline thunks or even strcmp() et al).
>> Passing -fvisibility=hidden doesn't make a difference (just as another
>> data point).
>>
>> Playing with -fstack-protector* flavors, I observe:
>> - -fstack-protector causing several failures, like you observed, oddly
>>   enough exclusively from __init functions,
>> - -fstack-protector-all and -fstack-protector-strong each causing a single
>>   (but respectively different) failure, for apparently random non-__init
>>   functions.
>> Taking this together it very much smells like a linker issue. I'll see
>> about checking there further.
> The oddity with how many diags show up is down to internals of the linker.
> It processes a single input section in full (continuing over this specific
> type of error), but will stop processing afterwards if any such error was
> encountered.
>
> The issue itself is a wrong assumption in the linker: It believes that it
> would only ever build small-model code when encountering this kind of
> relocation, and when not linking a shared library or PIE. With this
> assumption it converts the relocation resulting from @gotpcrel to
> R_X86_64_32S (converting the MOV from GOT to MOV $imm), which of course
> overflows when later trying to actually resolve it. What I'm yet to
> understand is why it doesn't use R_X86_64_PC32 (also) in such a situation
> (it does e.g. when building a shared library).
>
> While so far I didn't try it, using --no-relax is presumably not an option,
> as I expect that it'll leave us with a non-empty .got. Plus I didn't even
> start looking into how the xen.efi linking would deal with the ELF-specific
> gotpcrel relocs; the concept of GOT doesn't exist in PE/COFF, after all.
>
> While the linker certainly wants fixing, I continue to think that getting
> the compiler side right would yield the better overall result.

Ok, so what precisely needs doing here?

For starters, I guess __stack_chk_guard wants to respect
-fvisibilty=hidden and/or #pragma.  I can see why it wouldn't want to in
regular userspace, but we're not that.

There's clearly also an LD error (bad assumptions about model).

How many other bugs need opening in the various bugzillas?

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 05:23:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 05:23:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860781.1272762 (Exim 4.92)
	(envelope-from )
	id 1tO8zu-0005e5-JX; Thu, 19 Dec 2024 05:22:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860781.1272762; Thu, 19 Dec 2024 05:22: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 1tO8zu-0005dy-Gk; Thu, 19 Dec 2024 05:22:54 +0000
Received: by outflank-mailman (input) for mailman id 860781;
 Thu, 19 Dec 2024 05:22: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 1tO8zt-0005ds-72
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 05:22:53 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20611.outbound.protection.outlook.com
 [2a01:111:f403:2416::611])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 49135207-bdc9-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 06:22:50 +0100 (CET)
Received: from CH2PR03CA0022.namprd03.prod.outlook.com (2603:10b6:610:59::32)
 by PH8PR12MB7231.namprd12.prod.outlook.com (2603:10b6:510:225::9)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.26; Thu, 19 Dec
 2024 05:22:44 +0000
Received: from DS3PEPF0000C381.namprd04.prod.outlook.com
 (2603:10b6:610:59:cafe::fe) by CH2PR03CA0022.outlook.office365.com
 (2603:10b6:610:59::32) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.23 via Frontend Transport; Thu,
 19 Dec 2024 05:22:43 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 DS3PEPF0000C381.mail.protection.outlook.com (10.167.23.11) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Thu, 19 Dec 2024 05:22:42 +0000
Received: from cjq-desktop.amd.com (10.180.168.240) 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; Wed, 18 Dec
 2024 23:22:13 -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: 49135207-bdc9-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wt59ojBgEtAnNcdqOCjNksoHI0g6e+t85GvJVD6g5QONqVNnQVvPz++n4tCe0sw4WjA0aMG87lfbD+H4E3JOPcyeYzNlThjh4rkOh203kFKFGVF9EJHXZ6HuAvi8o5YuIl25eRvG7AIiIzlgh1cf9EOqRc6nlecgH3cidtBPq734CTdNyQZiMPfcJxfcTPAe7K9+LJVOY+iY5Vs3R9WOE6ksAJer7zyjrmr0qInOHEoGtGn+ba5vVoK/4rbt8XLTcKPQ9ZuRQ39psEl5bYOkZArAvQW3mgoN9N0iBjD00BeeoTX2mY3sBkqh6diAM6uBDMWLSUqcFLYNsRRv0tcAWA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hhA8zEc1GzBWF4Mmn5/XFOVinFTnQH1rm9pmzCQVyrs=;
 b=HMGWMG54kMp8B35zXKiDiQeDxLBm3698Uk2Fl7Z5PkN2MMJVgBUIkJVkHlLLhWIGBDragscyu/gOgqokviKC2YohwrYybFYM/5po1RSWSZPOdtTjZ1drM0mXf2YCmFe/0Rfs96zUJf16VmrXgA5a+Rflis+qgd99ue9IguEvQjDE9l7ucm94N/Fc+4+ejIhpQhCgSjD1pr4cLkDKpAMhEomBRjsYnLCWRLEgjOhKOCO+kDaWgAwXaSBmsSGV3iuRwFPVhun13ZURJpC6tBWB2+ZA7GK9z5BG2qXpRFGOANnWXwB/SKMU5kI8OulZH3Oz/zfM5r/aUtyksC7JSBSO3g==
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=hhA8zEc1GzBWF4Mmn5/XFOVinFTnQH1rm9pmzCQVyrs=;
 b=p6D2mH/e6zJu2gcry1eI/2/SR64hu3puoaPc3v1SPdfoxMo4jWpxOZLKkUr+jimBF+bmSFwc/wKc2akRjiKE8a3EPStkhY0VlRRzFWHEsCnjDTgVxFeNlD+zlFu6gLPP724ysSishlFymL1VQbO2bk3GdCdnI8csuy6YFzh6Hhg=
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=SATLEXMB04.amd.com; pr=C
From: Jiqian Chen 
To: 
CC: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Andrew Cooper
	, Jan Beulich , Julien Grall
	, Stefano Stabellini , Huang Rui
	, Jiqian Chen 
Subject: [PATCH v4] vpci: Add resizable bar support
Date: Thu, 19 Dec 2024 13:21:43 +0800
Message-ID: <20241219052143.3161332-1-Jiqian.Chen@amd.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.180.168.240]
X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com
 (10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS3PEPF0000C381:EE_|PH8PR12MB7231:EE_
X-MS-Office365-Filtering-Correlation-Id: cc04a108-88f1-470c-852b-08dd1fed29c9
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:
	=?us-ascii?Q?vnS90XZ3T7XpWtiL4rJ965lkGtCMWHqh1kbmXXgv/qbhCeDhULA8lmygto31?=
 =?us-ascii?Q?g+y6WGAuo41H7ObCdW3glg4kM4Ydw6FNKdzirf5+8F43LWkYQDn92LFcdXqq?=
 =?us-ascii?Q?CoMv2b8usuHZh8awq9RSzTnZmoavZQO4eAu1lZORnedWJ95z9padhfAHECwv?=
 =?us-ascii?Q?pWgUgQLhJRO7d0S7L3Zp3NZfviidI4uRz1L6euOD84IPBD1RQuIOZ4F5aDQq?=
 =?us-ascii?Q?w5/J/r1k375JDZcF0MXg4GTvB6WyKFQK6LoaDqg8rIhntk8bdPVtnqISIJeD?=
 =?us-ascii?Q?AHrsJLHUuBBUaAWs3tBZgZ0ztFkyVyuBADv0JUFJdnumaui3sX95GEIX6Srx?=
 =?us-ascii?Q?esvuyef7HSb2a+MbAR+q3D4qhJwGHNa+uct7Iv9uekhYiNfhNQ3pMNGHFkrs?=
 =?us-ascii?Q?sYwz/osPSo2Sj5CNxZUEijycVRHnojjxN56+DNGziuxeW8prVdLJ/n67EIZ2?=
 =?us-ascii?Q?MmR36wBRBIGgpWu9jodW1fhwgnODCkPPD3nQ7Mt8E1iPF/c5eDA+/xO23T+C?=
 =?us-ascii?Q?33bxPUofGRtCrXJk4inMb5hxaWlaTnVdAXoQThU0N7SZ95Sc4k+qhKFyWhSz?=
 =?us-ascii?Q?W5yU7DWvuRjv26uA0yli4WJ92ZA7SR+D7woeMlEsG5UPH79MLoGQTz/J+pkM?=
 =?us-ascii?Q?dzNAYQ8/oJSG83iWNGA6Fo4MwFXK1FseHOZ1JnchbvMlMQsoIwuYp+zoo+6u?=
 =?us-ascii?Q?EuZI0M3J31a4MbX8mhCUv8s082jSzF5/NAz2UYI9mZVWFKb6ccAMZn7trBlq?=
 =?us-ascii?Q?D5c5EDBXU9gXtyWW+FLbE6izP56wfji4Jc25iYOiMbqbPRQeuZS1sfDnOppu?=
 =?us-ascii?Q?h3VI0QwvGcuwA4f1oXHAFU2ryDTOQ5Mac1bpBPGv59SqiwczayngR9ba/3WL?=
 =?us-ascii?Q?Oc0eZBx3XNVGI1S6wTCGhJHzBXnM3D40M2FtO2KgUGa27nOTC8ZKpNYuEOGq?=
 =?us-ascii?Q?zVNmtAzAh3+Ky3fdnDWryH7uE18eA2UN+mFiiZQ0QJjgQiZcpIsgzChDO9MO?=
 =?us-ascii?Q?sqMJePx70N1UGWLaEcZuZj6KYPpHB357s02ZbSvet0GTQaXSDzx4nHnJMUa/?=
 =?us-ascii?Q?NWjQI8crwyMPQM5s+4IoRfCtOBq0fhE/q4N5sVaQyQDlCpDr3wZx4K9Nd388?=
 =?us-ascii?Q?LzyLc8Ywg1HFy5YgDIfrr0uvd3lQX/Vv84QbMJbJTHkL+tlfPTN30u290GzM?=
 =?us-ascii?Q?ISyua4ELXqPVTQP/0Y1iyUwqpjB3dV9LKyFr/B269o19hmgP8xrO+oQ+AMHG?=
 =?us-ascii?Q?eE4xmIJD6A3BxJfwiq7DINP9cS4UzEXqvUBxEOI2FXNMIEskNNAMROzMD5Qj?=
 =?us-ascii?Q?aJbRbYU1EuavSH5DVmhwc3on+SnjYXbDxoEWSdhuovbowIMCi51Yffz8l1wy?=
 =?us-ascii?Q?IRcy047SxJj1sb92qJ6tQZcsVjstQPxor6fpD5lH+oSq8jNsK3GY9rxlrvl2?=
 =?us-ascii?Q?ugccgyBKTYZIP4mnFE7kpQ4yKt6aTvs4N7wxd+shfXBcoslEWmtCFW1uTxGr?=
 =?us-ascii?Q?wYJ8wC3r4KaV+8U=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(36860700013)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2024 05:22:42.4167
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cc04a108-88f1-470c-852b-08dd1fed29c9
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS3PEPF0000C381.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7231

Some devices, like discrete GPU of amd, support resizable bar
capability, but vpci of Xen doesn't support this feature, so
they fail to resize bars and then cause probing failure.

According to PCIe spec, each bar that supports resizing has
two registers, PCI_REBAR_CAP and PCI_REBAR_CTRL. So, add
handlers for them to support resizing the size of BARs.

Signed-off-by: Jiqian Chen 
---
Hi all,
v3->v4 changes:
* Removed PCI_REBAR_CAP_SIZES since it was not needed, and added
  PCI_REBAR_CAP_SHIFT and PCI_REBAR_CTRL_SIZES.
* Added parameter resizable_sizes to struct vpci_bar to cache the support resizable sizes and
  added the logic in init_rebar().
* Changed PCI_REBAR_CAP to PCI_REBAR_CAP(n) (4+8*(n)), changed PCI_REBAR_CTRL to
  PCI_REBAR_CTRL(n) (8+8*(n)).
* Added domain info of pci_dev to printings of init_rebar().

Best regards,
Jiqian Chen.

v2->v3 changes:
* Used "bar->enabled" to replace "pci_conf_read16(pdev->sbdf, PCI_COMMAND) & PCI_COMMAND_MEMORY",
  and added comments why it needs this check.
* Added "!is_hardware_domain(pdev->domain)" check in init_rebar() to return EOPNOTSUPP for domUs.
* Moved BAR type and index check into init_rebar(), then only need to check once.
* Added 'U' suffix for macro PCI_REBAR_CAP_SIZES.
* Added macro PCI_REBAR_SIZE_BIAS to represent 20.
TODO: need to hide ReBar capability from hardware domain when init_rebar() fails.

v1->v2 changes:
* In rebar_ctrl_write, to check if memory decoding is enabled, and added
  some checks for the type of Bar.
* Added vpci_hw_write32 to handle PCI_REBAR_CAP's write, since there is
  no write limitation of dom0.
* And has many other minor modifications as well.
---
 xen/drivers/vpci/Makefile  |   2 +-
 xen/drivers/vpci/rebar.c   | 131 +++++++++++++++++++++++++++++++++++++
 xen/drivers/vpci/vpci.c    |   6 ++
 xen/include/xen/pci_regs.h |  14 ++++
 xen/include/xen/vpci.h     |   3 +
 5 files changed, 155 insertions(+), 1 deletion(-)
 create mode 100644 xen/drivers/vpci/rebar.c

diff --git a/xen/drivers/vpci/Makefile b/xen/drivers/vpci/Makefile
index 1a1413b93e76..a7c8a30a8956 100644
--- a/xen/drivers/vpci/Makefile
+++ b/xen/drivers/vpci/Makefile
@@ -1,2 +1,2 @@
-obj-y += vpci.o header.o
+obj-y += vpci.o header.o rebar.o
 obj-$(CONFIG_HAS_PCI_MSI) += msi.o msix.o
diff --git a/xen/drivers/vpci/rebar.c b/xen/drivers/vpci/rebar.c
new file mode 100644
index 000000000000..bfc0e6eb0668
--- /dev/null
+++ b/xen/drivers/vpci/rebar.c
@@ -0,0 +1,131 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2024 Advanced Micro Devices, Inc. All Rights Reserved.
+ *
+ * Author: Jiqian Chen 
+ */
+
+#include 
+#include 
+
+static void cf_check rebar_ctrl_write(const struct pci_dev *pdev,
+                                      unsigned int reg,
+                                      uint32_t val,
+                                      void *data)
+{
+    struct vpci_bar *bar = data;
+    uint64_t size = PCI_REBAR_CTRL_SIZE(val);
+
+    if ( bar->enabled )
+    {
+        /*
+         * Refuse to resize a BAR while memory decoding is enabled, as
+         * otherwise the size of the mapped region in the p2m would become
+         * stale with the newly set BAR size, and the position of the BAR
+         * would be reset to undefined.  Note the PCIe specification also
+         * forbids resizing a BAR with memory decoding enabled.
+         */
+        if ( size != bar->size )
+            gprintk(XENLOG_ERR,
+                    "%pp: refuse to resize BAR with memory decoding enabled\n",
+                    &pdev->sbdf);
+        return;
+    }
+
+    if ( !((size >> PCI_REBAR_SIZE_BIAS) & bar->resizable_sizes) )
+        gprintk(XENLOG_WARNING,
+                "%pp: new size %#lx is not supported by hardware\n",
+                &pdev->sbdf, size);
+
+    bar->size = size;
+    bar->addr = 0;
+    bar->guest_addr = 0;
+    pci_conf_write32(pdev->sbdf, reg, val);
+}
+
+static int cf_check init_rebar(struct pci_dev *pdev)
+{
+    uint32_t ctrl;
+    unsigned int nbars;
+    unsigned int rebar_offset = pci_find_ext_capability(pdev->sbdf,
+                                                        PCI_EXT_CAP_ID_REBAR);
+
+    if ( !rebar_offset )
+        return 0;
+
+    if ( !is_hardware_domain(pdev->domain) )
+    {
+        printk(XENLOG_ERR "%pp: resizable BARs unsupported for unpriv %pd\n",
+               &pdev->sbdf, pdev->domain);
+        return -EOPNOTSUPP;
+    }
+
+    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
+    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
+
+    for ( unsigned int i = 0; i < nbars; i++ )
+    {
+        int rc;
+        struct vpci_bar *bar;
+        unsigned int index;
+
+        ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(i));
+        index = ctrl & PCI_REBAR_CTRL_BAR_IDX;;
+        if ( index >= PCI_HEADER_NORMAL_NR_BARS )
+        {
+            /*
+             * TODO: for failed pathes, need to hide ReBar capability
+             * from hardware domain instead of returning an error.
+             */
+            printk(XENLOG_ERR "%pd %pp: too big BAR number %u in REBAR_CTRL\n",
+                   pdev->domain, &pdev->sbdf, index);
+            return -EINVAL;
+        }
+
+        bar = &pdev->vpci->header.bars[index];
+        if ( bar->type != VPCI_BAR_MEM64_LO && bar->type != VPCI_BAR_MEM32 )
+        {
+            printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
+                   pdev->domain, &pdev->sbdf, index);
+            return -EINVAL;
+        }
+
+        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, vpci_hw_write32,
+                               rebar_offset + PCI_REBAR_CAP(i), 4, NULL);
+        if ( rc )
+        {
+            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CAP rc=%d\n",
+                   pdev->domain, &pdev->sbdf, rc);
+            return rc;
+        }
+
+        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rebar_ctrl_write,
+                               rebar_offset + PCI_REBAR_CTRL(i), 4, bar);
+        if ( rc )
+        {
+            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CTRL rc=%d\n",
+                   pdev->domain, &pdev->sbdf, rc);
+            return rc;
+        }
+
+        bar->resizable_sizes |=
+            (pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CAP(i)) >>
+             PCI_REBAR_CAP_SHIFT);
+        bar->resizable_sizes |=
+            ((uint64_t)MASK_EXTR(ctrl, PCI_REBAR_CTRL_SIZES) <<
+             (32 - PCI_REBAR_CAP_SHIFT));
+    }
+
+    return 0;
+}
+REGISTER_VPCI_INIT(init_rebar, VPCI_PRIORITY_LOW);
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 1e6aa5d799b9..3349b98389b8 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -232,6 +232,12 @@ void cf_check vpci_hw_write16(
     pci_conf_write16(pdev->sbdf, reg, val);
 }
 
+void cf_check vpci_hw_write32(
+    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
+{
+    pci_conf_write32(pdev->sbdf, reg, val);
+}
+
 int vpci_add_register_mask(struct vpci *vpci, vpci_read_t *read_handler,
                            vpci_write_t *write_handler, unsigned int offset,
                            unsigned int size, void *data, uint32_t ro_mask,
diff --git a/xen/include/xen/pci_regs.h b/xen/include/xen/pci_regs.h
index 250ba106dbd3..51fdab69fa74 100644
--- a/xen/include/xen/pci_regs.h
+++ b/xen/include/xen/pci_regs.h
@@ -459,6 +459,7 @@
 #define PCI_EXT_CAP_ID_ARI	14
 #define PCI_EXT_CAP_ID_ATS	15
 #define PCI_EXT_CAP_ID_SRIOV	16
+#define PCI_EXT_CAP_ID_REBAR	21	/* Resizable BAR */
 
 /* Advanced Error Reporting */
 #define PCI_ERR_UNCOR_STATUS	4	/* Uncorrectable Error Status */
@@ -541,6 +542,19 @@
 #define  PCI_VNDR_HEADER_REV(x)	(((x) >> 16) & 0xf)
 #define  PCI_VNDR_HEADER_LEN(x)	(((x) >> 20) & 0xfff)
 
+/* Resizable BARs */
+#define PCI_REBAR_SIZE_BIAS	20
+#define PCI_REBAR_CAP(n)    	(4 + 8 * (n))	/* capability register */
+#define  PCI_REBAR_CAP_SHIFT		4		/* shift for supported BAR sizes */
+#define PCI_REBAR_CTRL(n)   	(8 + 8 * (n))	/* control register */
+#define  PCI_REBAR_CTRL_BAR_IDX	0x00000007	/* BAR index */
+#define  PCI_REBAR_CTRL_NBAR_MASK	0x000000E0	/* # of resizable BARs */
+#define  PCI_REBAR_CTRL_BAR_SIZE	0x00001F00	/* BAR size */
+#define  PCI_REBAR_CTRL_SIZE(v) \
+            (1UL << (MASK_EXTR(v, PCI_REBAR_CTRL_BAR_SIZE) \
+                     + PCI_REBAR_SIZE_BIAS))
+#define  PCI_REBAR_CTRL_SIZES		0xFFFF0000U	/* supported BAR sizes */
+
 /*
  * Hypertransport sub capability types
  *
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index 41e7c3bc2791..9d47b8c1a50e 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -78,6 +78,8 @@ uint32_t cf_check vpci_hw_read32(
     const struct pci_dev *pdev, unsigned int reg, void *data);
 void cf_check vpci_hw_write16(
     const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data);
+void cf_check vpci_hw_write32(
+    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data);
 
 /*
  * Check for pending vPCI operations on this vcpu. Returns true if the vcpu
@@ -100,6 +102,7 @@ struct vpci {
             /* Guest address. */
             uint64_t guest_addr;
             uint64_t size;
+            uint64_t resizable_sizes;
             struct rangeset *mem;
             enum {
                 VPCI_BAR_EMPTY,
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 07:12:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 07:12:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860794.1272774 (Exim 4.92)
	(envelope-from )
	id 1tOAhs-0001KS-7f; Thu, 19 Dec 2024 07:12:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860794.1272774; Thu, 19 Dec 2024 07:12:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOAhs-0001KL-3W; Thu, 19 Dec 2024 07:12:24 +0000
Received: by outflank-mailman (input) for mailman id 860794;
 Thu, 19 Dec 2024 07:12: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 1tOAhq-0001KF-IP
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 07:12:22 +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 9662d34b-bdd8-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 08:12:20 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-43618283d48so2931235e9.1
 for ; Wed, 18 Dec 2024 23:12:20 -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-4366127c493sm8841105e9.28.2024.12.18.23.12.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Dec 2024 23:12: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: 9662d34b-bdd8-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734592340; x=1735197140; 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=gkuMAuZSIqyAgN1zpPUPQDsr+zfCXjOFW09VW94ZwaY=;
        b=EHkrD+3m0bRRK/PeKbesJiPY6sDWtbuNMbXvdRDmazx1wvcJOyTNfMgt+z/lXwT2Bo
         ee+pzUaR6pl58rWlj5wnKPVnwfApvjXPlxqqrXlA0oyRQZMA6SEb0m3g0GIR9b5kmlvX
         BACIIRZod4v/Rr+IcN1B3OByW8ZNZwBbah9P85K8w4wCCayanb7icPFVxnLaMFchJlmT
         rRSVFZJ796ZIjra1yGk8BmUGdZRFkJNz6tgP+FO0EWQ+N1PZ25Vvg9fB7kP/j6pZCAzK
         QE8flJs9naYAtO/xslsXQA4WJjvaBbOSqy7QGoIyTi3R3425yevnCfwX2MQfthDDA6bG
         0wGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734592340; x=1735197140;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=gkuMAuZSIqyAgN1zpPUPQDsr+zfCXjOFW09VW94ZwaY=;
        b=vpwvL27zhK6XOx6MXHMDUacBtxMbo5OVuhlPySS9JomfVOrmvOfQxaM625B5O0TTLT
         WHz2r6Ll7fQ2RNJIq5yp4g2QllRd7dHTBrMYTgfT4+2G6fzcIaDHvHxqrOVVCMWRu6Tz
         pUmKw8zAkLEiaaWVIgbIfHHgtbGhmGOr3PH8wIYeNWgmVO/wNknXepfL7gZpniAUK2PJ
         wErMd7iFJPhJdxmY1xWSEQ2bEycddQIaFg0/fmvVlv6vK0lYL/MrlkgoYPu8oduaGiQt
         OYMEpf+z3kBUGnRgZGSbwDIeDiUI5H57t/fv+xc/T30g6KlbCcJWh2wGPj+IIb6LRqwT
         k5gw==
X-Forwarded-Encrypted: i=1; AJvYcCV7ZZqQ5aImbFqP/bEY1YfrwgPwkItitI/ZnC9ZQqy7IB1tx6aLCNTWLRZIreuk2g3nLSUXhm8qJsY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YweR6pejg9EiPaf0O2KKA5MyvYtuDubelB+9FR3TFpdJxG3zqh2
	oqnrfr8i2iGZ8rP40e+g0N3MRntCSIUzEUyVwgnxHNJlHqXeJOjTeoBltYsRAA==
X-Gm-Gg: ASbGncsAKF+zoja14onHuQOcr0k17ACU6OUOZoGL1E0rC9ggxA7G43sQm7D5PCRJ4kV
	H3Op9IDnL10EmOpt6HeBY3fyLg2ueIFOeYys/HwGtQCAqUKt7x1KfYiUpbyypghFs0rZ+8jZxb0
	roS0Uz0vwMHnr91lu1cTUq1AUn63f2p3DIDGFBq3wsk8BGbvjntwaHxsM6CZOK3DuyJXtHs5L4+
	A6zBm5YYRhBRtdCFNlJWo3xlVWALzh0QCLxqkWJ0PfE2ChSSAxdvnWNQ560iX1XRCohMIdqWbO4
	ZH6FtScqrTDWklHHa+Xyv3PZfAt33tcswtopWhX5iQ==
X-Google-Smtp-Source: AGHT+IHtdHP3fwX5dSHFKl5Y6uCqmktGD5aMPmW5CruHMJqq40cB6k+kqq+bS+B53C1bIDa17ivwbQ==
X-Received: by 2002:a05:600c:3b9d:b0:434:a1e7:27b0 with SMTP id 5b1f17b1804b1-4365535ddedmr42076975e9.11.1734592340030;
        Wed, 18 Dec 2024 23:12:20 -0800 (PST)
Message-ID: <781a2f80-9ca6-4875-9b4a-ecef7694ae2e@suse.com>
Date: Thu, 19 Dec 2024 08:12:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] x86/xen/mmu: Increase MAX_CONTIG_ORDER
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
Cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com,
 xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
 Thierry Escande 
References: <20241204171346.458105-1-thierry.escande@vates.tech>
 
 
 
 <8fb77778-b821-4e38-a835-54883ba14e4b@suse.com>
 
 <733e95a6-dd33-422a-a25b-9f08cef5860e@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: <733e95a6-dd33-422a-a25b-9f08cef5860e@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 18.12.2024 12:24, Jürgen Groß wrote:
> On 18.12.24 12:11, Thierry Escande wrote:
>>
>>
>> On 12/12/2024 12:09, Juergen Gross wrote:
>>> On 12.12.24 11:22, Jan Beulich wrote:
>>>> On 11.12.2024 19:20, Thierry Escande wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On 09/12/2024 11:04, Jan Beulich wrote:
>>>>>> On 04.12.2024 18:14, Thierry Escande wrote:
>>>>>>> With change 9f40ec84a797 (xen/swiotlb: add alignment check for dma
>>>>>>> buffers), the driver mpt3sas fails to load because it cannot allocate
>>>>>>> its DMA pool for an allocation size of ~2,3 MBytes. This is because
>>>>>>> the
>>>>>>> alignement check added by 9f40ec84a797 fails and
>>>>>>> xen_swiotlb_alloc_coherent() ends up calling
>>>>>>> xen_create_contiguous_region() with a size order of 10 which is too
>>>>>>> high
>>>>>>> for the current max value.
>>>>>>>
>>>>>>> This patch increases the MAX_CONTIG_ORDER from 9 to 10 (4MB) to allow
>>>>>>> such allocations.
>>>>>>>
>>>>>>> Signed-off-by: Thierry Escande 
>>>>>>> ---
>>>>>>>    arch/x86/xen/mmu_pv.c | 2 +-
>>>>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
>>>>>>> index 55a4996d0c04..7f110740e1a2 100644
>>>>>>> --- a/arch/x86/xen/mmu_pv.c
>>>>>>> +++ b/arch/x86/xen/mmu_pv.c
>>>>>>> @@ -2200,7 +2200,7 @@ void __init xen_init_mmu_ops(void)
>>>>>>>    }
>>>>>>>      /* Protected by xen_reservation_lock. */
>>>>>>> -#define MAX_CONTIG_ORDER 9 /* 2MB */
>>>>>>> +#define MAX_CONTIG_ORDER 10 /* 4MB */
>>>>>>>    static unsigned long discontig_frames[1<>>>>>
>>>>>> While lacking respective commentary, bumping this value imo also
>>>>>> needs to
>>>>>> take into account Xen itself, at least commit-message-wise. The
>>>>>> bumping is
>>>>>> fine for Dom0 in any event. It is also fine for DomU-s with the
>>>>>> defaults
>>>>>> built into the hypervisor (orders 12 and 10 respectively for x86 and
>>>>>> Arm),
>>>>>> yet especially for Arm (and in the future PPC and RISC-V) any further
>>>>>> bumping would be less straightforward.
>>>>>
>>>>> Thanks for pointing this out. On the Xen side, CONFIG_CTLDOM_MAX_ORDER
>>>>> and CONFIG_HWDOM_MAX_ORDER seem big enough on all architectures. But I
>>>>> see CONFIG_DOMU_MAX_ORDER set to 9 (also all archs). Won't that be a
>>>>> problem for drivers trying to allocate more than that from a domU ?
>>>>
>>>> A driver assumes a (physical) device to be in the DomU, at which point it
>>>> is CONFIG_PTDOM_MAX_ORDER which applies (PT standing for pass-through).
>>>>
>>>>>> However - does the driver really need this big a contiguous chunk? It
>>>>>> would seem far more desirable to me to break that up some, if possible.
>>>>>
>>>>> Since this works on bare metal I'm afraid the driver maintainer (mpt
>>>>> fusion driver) will just tell me to fix Xen.
>>>>
>>>> Well. The bigger such allocations, the larger the risk that on systems
>>>> that have been up for a while such allocations can't be fulfilled anymore
>>>> even in the bare metal case.
>>>
>>> Yes. I don't think we should just work around this issue without having
>>> even tried to get the driver fixed. In case they refuse to change it, we
>>> can still increase MAX_CONTIG_ORDER.
>>
>> Thanks for the feedback. I'll try to have a look at the driver if I have
>> time to do so.
> 
> Another thought would be to change the generic DMA allocation to not require
> alignment based on the rounded up size, but on the largest power-of-2 chunk
> fitting into the requested size.
> 
> I don't see why a 2.3 MB memory allocation would need to be 4 MB aligned. It
> should be perfectly fine to align it to 2 MB only.

Yet that wouldn't make a difference here, would it? We'd still need a 4M
chunk of contiguous space, just with less alignment.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 07:39:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 07:39:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860808.1272782 (Exim 4.92)
	(envelope-from )
	id 1tOB8L-0004D5-AX; Thu, 19 Dec 2024 07:39:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860808.1272782; Thu, 19 Dec 2024 07:39:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOB8L-0004Cy-79; Thu, 19 Dec 2024 07:39:45 +0000
Received: by outflank-mailman (input) for mailman id 860808;
 Thu, 19 Dec 2024 07:39: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 1tOB8K-0004Cs-1H
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 07:39: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 690cbcf2-bddc-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 08:39:42 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-432d86a3085so2833125e9.2
 for ; Wed, 18 Dec 2024 23:39: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-4364b14f241sm65262655e9.1.2024.12.18.23.39.40
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Dec 2024 23:39: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: 690cbcf2-bddc-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734593982; x=1735198782; 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=NL/Dn4eeXHpUC+uka+GCUZoSmWhpqIRRTK/SA78XebA=;
        b=ggOgBC2/3bvO7Qx4tKW5dV6gu3fyX5gPvOBQ6IedzD1J1oFybfD9nmorkQrHYg2InM
         5QaocrhyIiBXxq+4x5+pVk+J6t26brqH7AC7m4H5e6GvZHNIzu81HIYpXLp7ALBNcsGj
         5WHjOSN11bcrHQ3Zz4qvHcuA5WOtoWd0dEwUmSE+xsikAL8M8SefGAAd5s+AOWjIahWW
         EWiuM4L/rohTtgrfPhKgKP3jhTm27jIP7ssKpunxD9jx6FlQ0rDkJrLMcvgVqgxbTyOI
         JErTA90N4kbYbBaGYS9BBLZNg0BXkg+006a3p6ylZrwr0iehlnPxzT8k1a4V+ydtIAVf
         w+gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734593982; x=1735198782;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NL/Dn4eeXHpUC+uka+GCUZoSmWhpqIRRTK/SA78XebA=;
        b=GXDwfEplm4NS/Dv2BTl5e9CsVvzM7ol1yhZbkydOXZPz4wBFLMmnTjgdsqadX0xSmX
         H4ZuEXtTIPM4pwzyzLkwQ6F4rhCKq6xkfY1dAIBT7u3rXuBs9lue1pdp315rtAN5cGNj
         pZqdPnDhVTpGUIgnzuunvjhFAM083ctJci7eGFqv8n2wFf83FFKnsj2fEixUdYOizFqY
         y385GnNtuV2Hi3bSid/iQcB3SjTB3DWOnhW+EhLVvpUO91R56LYy43UTOfX7oKcGtKRg
         ydKDqYHCF4gbc2S5vHXggFxusftkziYEJK0sYXrEhZWUL3HiPLJTPJXmZ/r4iqulf2JI
         IXcA==
X-Forwarded-Encrypted: i=1; AJvYcCXueX/eJVLMuq4yZNfeEIPIxkOt2Jp1HPyyQbJRz2VCFmfOr++bZOpc6/FilpyyGvDywd5eMLBtJpo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YymiHxhPUcMG+7Ihd0uC/OFSKhHrqQO/ujGGxRfqXlFZIxG6ULO
	Qbf5k4ROak8tAA7k5BbkEKFf6BC/LiP1+GnjVgWF6VfPYKsTglBrhbGjdqJVYA==
X-Gm-Gg: ASbGncv0vbghIAOIvRBAiojoqvSnTXE1Kkz0umGWW61IlanfiW9V4llvqUx/hM+8gRX
	4qj60xSv/6ZFAdEk/HCkyBE+QamNehSyk/6cq9xOkBvfh8+LGkrMI+0xZ/QtM6dwuSPC+budf0D
	JNsAi7KyV0DdfcHSk+/jvIZK5eArqr6Y/r8d8z36sxll99abArxNiDkp4qe88GbTUoCV/WbZt4K
	Q08/oD881ixTiPF3qZkw5XoGcI7BMy7b+38GS0Za5GzTg4H1RCXdQMAIaC8po5FFRRF4SkQzsWi
	lvINOeheEeKXaDID2KlxStHTUEfIplaY9UvqX3B6EQ==
X-Google-Smtp-Source: AGHT+IFaeye4akgm2Hh7STO9FWOYku9hI1tCYk0/UdlNWml1bCNoFs5TmLb8ChU1IoeqZ0MdbjzH7A==
X-Received: by 2002:a05:600c:3b88:b0:434:a315:19c with SMTP id 5b1f17b1804b1-4365c77e436mr18878925e9.3.1734593981959;
        Wed, 18 Dec 2024 23:39:41 -0800 (PST)
Message-ID: 
Date: Thu, 19 Dec 2024 08:39:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 0/3] Add stack protector
To: Andrew Cooper 
Cc: Julien Grall , Stefano Stabellini
 , Anthony PERARD ,
 Samuel Thibault ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Bertrand Marquis ,
 Michal Orzel ,
 "xen-devel@lists.xenproject.org" ,
 Volodymyr Babchuk 
References: <20241211020424.401614-1-volodymyr_babchuk@epam.com>
  <87pllx3gib.fsf@epam.com>
 
 <9056a92d-8e91-4f2d-a8f3-5cde378f6c6f@suse.com>
 <7aea0e1d-f60c-4e82-8b63-c4e18cbcce85@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 19.12.2024 01:20, Andrew Cooper wrote:
> On 12/12/2024 4:52 pm, Jan Beulich wrote:
>> On 12.12.2024 15:30, Jan Beulich wrote:
>>> On 12.12.2024 02:17, Andrew Cooper wrote:
>>>> (With the knowledge that this is a disputed Kconfig pattern, and will
>>>> need rebasing), the way I want this to work is simply:
>>>>
>>>> diff --git a/xen/Makefile b/xen/Makefile
>>>> index 0de0101fd0bf..5d0a88fb3c3f 100644
>>>> --- a/xen/Makefile
>>>> +++ b/xen/Makefile
>>>> @@ -434,6 +434,9 @@ endif
>>>>  
>>>>  ifeq ($(CONFIG_STACK_PROTECTOR),y)
>>>>  CFLAGS += -fstack-protector
>>>> +ifeq ($(CONFIG_X86),y)
>>>> +CFLAGS += -mstack-protector-guard=global
>>>> +endif
>>>>  else
>>>>  CFLAGS += -fno-stack-protector
>>>>  endif
>>>> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
>>>> index 9cdd04721afa..7951ca908b36 100644
>>>> --- a/xen/arch/x86/Kconfig
>>>> +++ b/xen/arch/x86/Kconfig
>>>> @@ -28,6 +28,7 @@ config X86
>>>>         select HAS_PCI_MSI
>>>>         select HAS_PIRQ
>>>>         select HAS_SCHED_GRANULARITY
>>>> +       select HAS_STACK_PROTECTOR if
>>>> $(cc-option,-mstack-protector-guard=global)
>>>>         select HAS_UBSAN
>>>>         select HAS_VMAP
>>>>         select HAS_VPCI if HVM
>>>>
>>>>
>>>>
>>>> Sadly, it doesn't build.  I get a handful of:
>>>>
>>>> prelink.o: in function `cmdline_parse':
>>>> /home/andrew/xen.git/xen/common/kernel.c:216:(.init.text+0x20f2): failed
>>>> to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
>>>> --no-relax
>>>> /home/andrew/xen.git/xen/common/kernel.c:230:(.init.text+0x246f): failed
>>>> to convert GOTPCREL relocation against '__stack_chk_guard'; relink with
>>>> --no-relax
>>>>
>>>> which is more toolchain-whispering than I feel like doing tonight.
>>> Imo the root of the problem is that the compiler doesn't itself mark
>>> __stack_chk_guard hidden (it does so for __stack_chk_fail, albeit only for
>>> 32-bit code), and hence finds it necessary to use @gotpcrel to access the
>>> variable. Even if the linker managed to relax all of these, it would then
>>> still be less efficient compared to direct RIP-relative accesses.
>>>
>>> I also can't see how we might be able to override the compiler's internal
>>> declaration to mark it hidden (the same appears to be true for other items
>>> the declares internally, like the retpoline thunks or even strcmp() et al).
>>> Passing -fvisibility=hidden doesn't make a difference (just as another
>>> data point).
>>>
>>> Playing with -fstack-protector* flavors, I observe:
>>> - -fstack-protector causing several failures, like you observed, oddly
>>>   enough exclusively from __init functions,
>>> - -fstack-protector-all and -fstack-protector-strong each causing a single
>>>   (but respectively different) failure, for apparently random non-__init
>>>   functions.
>>> Taking this together it very much smells like a linker issue. I'll see
>>> about checking there further.
>> The oddity with how many diags show up is down to internals of the linker.
>> It processes a single input section in full (continuing over this specific
>> type of error), but will stop processing afterwards if any such error was
>> encountered.
>>
>> The issue itself is a wrong assumption in the linker: It believes that it
>> would only ever build small-model code when encountering this kind of
>> relocation, and when not linking a shared library or PIE. With this
>> assumption it converts the relocation resulting from @gotpcrel to
>> R_X86_64_32S (converting the MOV from GOT to MOV $imm), which of course
>> overflows when later trying to actually resolve it. What I'm yet to
>> understand is why it doesn't use R_X86_64_PC32 (also) in such a situation
>> (it does e.g. when building a shared library).
>>
>> While so far I didn't try it, using --no-relax is presumably not an option,
>> as I expect that it'll leave us with a non-empty .got. Plus I didn't even
>> start looking into how the xen.efi linking would deal with the ELF-specific
>> gotpcrel relocs; the concept of GOT doesn't exist in PE/COFF, after all.
>>
>> While the linker certainly wants fixing, I continue to think that getting
>> the compiler side right would yield the better overall result.
> 
> Ok, so what precisely needs doing here?
> 
> For starters, I guess __stack_chk_guard wants to respect
> -fvisibilty=hidden and/or #pragma.  I can see why it wouldn't want to in
> regular userspace, but we're not that.

Yes, this is one of the things that may want reporting as a deficiency. Imo
it wants generalizing though, as it's not __stack_chk_guard alone which is
affected.

I'm not, btw, convinced the #pragma ought to have any effect. One might
consider it legitimate to have an effect if there's a subsequent re-
declaration. Yet one might also consider such an (incompatible) re-
declaration be an error.

> There's clearly also an LD error (bad assumptions about model).

I'm still in the process of collecting data for an eventual email or bug
report to be put together. For the purposes here I meanwhile think it is
largely irrelevant. That's because, as said, even if the linker was fixed
in this regard, there would still be the fact that we'd end up with a non-
empty .got (I did hack the linker enough to verify this). Whereas once the
compiler side was sorted, the linker issue wouldn't come into play anymore.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 07:55:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 07:55:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860819.1272793 (Exim 4.92)
	(envelope-from )
	id 1tOBNI-0006zS-Jz; Thu, 19 Dec 2024 07:55:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860819.1272793; Thu, 19 Dec 2024 07: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 1tOBNI-0006zL-Gd; Thu, 19 Dec 2024 07:55:12 +0000
Received: by outflank-mailman (input) for mailman id 860819;
 Thu, 19 Dec 2024 07:55: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 1tOBNG-0006zF-Ei
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 07:55:10 +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 90eef019-bdde-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 08:55:08 +0100 (CET)
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-4361fe642ddso4652905e9.2
 for ; Wed, 18 Dec 2024 23:55: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
 ffacd0b85a97d-38a1c832ec4sm895511f8f.26.2024.12.18.23.55.06
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 18 Dec 2024 23:55: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: 90eef019-bdde-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734594908; x=1735199708; 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=ZJp7w+mf3vnysHaUf7gQZHO0NY4fqBlb6ueDSPuhat4=;
        b=G+9l8Jsr1TITe6RvAUIwkymK2pM1hJeGG7D+6QqVC+vJgfC/SFdA3RN4IxR+FhM6G/
         bYIsy+tTHsVUY8FUDJqeqvZD8tYm7KZxX4MGixPNUgyX4UEeUwPP9l811U3+LI3IXNBS
         06AmhxMo+fTOIlIX5p1ini0xtrf4/ubY1E+NMXW74NPv/M33ZWt14lYrFIKS/AvSIz1r
         8KSR9eeyDej1uJI8HxsImMnXhmB4XvbzHHry1eqQ3n7Gy72rf3chEMvRJcY2ENi1PqZk
         k3+YeKbqt5d1XayvRDAXrcGdXdIbWFBd5KlKcdRiJFXhkvRb9TXgRfipf/G5SPi5VTzC
         snjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734594908; x=1735199708;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ZJp7w+mf3vnysHaUf7gQZHO0NY4fqBlb6ueDSPuhat4=;
        b=GGtcWaXiKUSVXK2LlwJr6jwZyYgupVTsp2GlZg7zA6k2XZcnRfQpmyAvcrYXhAhZcx
         fyjRkI5nT/V1nTwX2XjG6SwyuFjpjMnJomV0Ahr0azXd9yYb9ZufX5x1a9xzWHlL4YMx
         GtM5moIoRMURrvmlua6rfO9vQ2n0dtf7R2WgGtageYxgyTieCP1TPeZuQTCv8kRF6IjA
         0UnotENCNVLe7W48IkaQuPl1ilOasjO7l09FeoUdwGScjJL/3QbAPxaPzVogpskDmUaG
         4+BiEKj3WNyqQDzc8M2rHSikTqht98zpuIMUK+TxPuevS2xJuKaun9yEi/o7YC+mQV17
         JkFg==
X-Forwarded-Encrypted: i=1; AJvYcCWdgKjKR6UWVZpsmTTYpeY188wdSQf4A2K7ourBXRZARCfBvqh8Veo3DFXDP5z5IXNO5GrK3Ls0JmI=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy7iZ7Wo2qlcV458v+PZfLezXiFzuRY8f/ACHLCToeKgd0oPVjN
	hcBGq5wOXoCt8V4tglc9xEA/htxZo0Oaf7h/e8g03IuwTnhF70XPLnj0AxL5Qg==
X-Gm-Gg: ASbGncttppTzkTRFDTX1nzYhr9DRcSCDp2E8Y90R2XA+zWCLRYIeRHa70Pg7/dZ1+/q
	NhpDHwFQSA3YHKG16KmoegYkG0J5GDPZ9x2qZYQRElYtut9GxCdJ228wJzfW3CAAkIS6nNsYPDl
	YkYdLpVjiLlGL7wgGlURfWfnPb/o//VPThCTpil8gKJ60YI75xHi2u2fXLcUN7vuGzrSa9xFW3u
	6tgeBOJ4YU8yJLtyBXKR3Nc1TZZnpYVvyxXipYepChIOSF0QJI3Sy+LXOfgRXB6roG2Y2v6OhpQ
	ARf4BWQDMC2DQA4b6Ql9C011EfU0DFhvXm4VhQpHHg==
X-Google-Smtp-Source: AGHT+IGu8zKmxILKhViy32LkRnz7htuX2vIXctqry2GOPygmJYKufnVQ/q0E7Jg+TB3GjFgHvAy0cA==
X-Received: by 2002:a05:6000:1f89:b0:385:fd07:8616 with SMTP id ffacd0b85a97d-388e4c97076mr5793694f8f.0.1734594907867;
        Wed, 18 Dec 2024 23:55:07 -0800 (PST)
Message-ID: <6182abbf-7cc3-4075-9f13-55ebbdef6aef@suse.com>
Date: Thu, 19 Dec 2024 08:55:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
To: Sergiy Kibrik 
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: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
 <9003a677-e78b-4cf8-b890-c6cf432d5837@suse.com>
 <858496ff-b8da-4dd9-abd1-679dc4f67b30@epam.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: <858496ff-b8da-4dd9-abd1-679dc4f67b30@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.12.2024 11:00, Sergiy Kibrik wrote:
> 17.12.24 15:02, Jan Beulich:
>> On 17.12.2024 12:47, Sergiy Kibrik wrote:
>>> Allow to build ARM configuration with support for initializing hardware domain.
>>> On ARM it is only possible to start hardware domain in multiboot mode, so
>>> dom0less support is required.
>>
>> I don't follow this. Late hwdom is supposed to be started by a (minimal)
>> toolstack iirc.
> 
> Yes, on x86 it's started by toolstack. This is not supported on ARM.
> However dom0less can already handle hardware domain initialization on 
> ARM, without much of an additional changes.

Yet that's not "late hwdom" then, but "separate hwdom and ctrldom" or some
such.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 08:01:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 08:01:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860829.1272803 (Exim 4.92)
	(envelope-from )
	id 1tOBTe-0000lV-B2; Thu, 19 Dec 2024 08:01:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860829.1272803; Thu, 19 Dec 2024 08:01: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 1tOBTe-0000lO-7Y; Thu, 19 Dec 2024 08:01:46 +0000
Received: by outflank-mailman (input) for mailman id 860829;
 Thu, 19 Dec 2024 08:01: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 1tOBTd-0000l3-2V
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 08:01:45 +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 7cd5783e-bddf-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 09:01:44 +0100 (CET)
Received: by mail-wm1-x332.google.com with SMTP id
 5b1f17b1804b1-4361c705434so3210635e9.3
 for ; Thu, 19 Dec 2024 00:01: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-43656b013ecsm44439845e9.16.2024.12.19.00.01.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Dec 2024 00:01: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: 7cd5783e-bddf-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734595304; x=1735200104; 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=U07+G/ShjaYvwPy/lODKVWP+QdMhiAg8+R5YXTWup4o=;
        b=U7wwxZf9PfVm4CZHBcm/Y5JriQTSZxidai+Uj0+69aGx501wba0lggqKTnodyeGXJ6
         itsEInqvxD74+QZG7h0TNNyLwaO+dpgXrVQMKIaw6xY6EmwGeBpJEwpc+sWTl+q6HfhK
         ZdjhdII0QFxTk9gqIO337QhdHwvcaWN6/bzR6gZxziCimqqxn2ENYtbe8raYE8RiNAWB
         yAFOvk1xpVO7LZdqd5U6UEEMlvl8kt3eDVFoOvxA6L1+Z2BvvdNmydCvVvs96Tqz+jYh
         KYOH8Z/E8/j0evpMSHDwROEOO395+Jgseflws3wfTAYJiyXxaAwxiHYAW+nexJJU/rms
         SKLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734595304; x=1735200104;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=U07+G/ShjaYvwPy/lODKVWP+QdMhiAg8+R5YXTWup4o=;
        b=Cgb1fGXT4I1v9vUIOLFaO24CWgsIBQLPVBzCgGS/EQBgNqdKk1hMlGPF0O+PApLN+L
         cXV02T8ruz4nXAaYcDCOHWFbPI2u+kPxWDJsyeHzbNXnpz2faL/gfUNlKkvVCF6KQvM5
         INsy359HTiJ30WuPlJ+AX5+ghZZ5rp+J6Dci21ixjjUt0k59R91rg8oYz5XSYNWw8Iys
         om17bXmTmyYDqczMl/iR8xwkb/S3PAY8MnWu7vPmZRTnSRIDxFq0TGwlqW0i4fN01h8H
         +sLHmuMMQ7VKkurQOiUVFN8uOj5g8Qaf5Kh4uvnzGnf33dkulK8clUxpcv5AWigtt2fW
         I0Hg==
X-Forwarded-Encrypted: i=1; AJvYcCWrEepyFbFOf+HNWB6a9vRVZzoDTzbTvKj12xOeXPufXLGri9ObAuYynYf94+LbrOMhf7Ujed+Kf9c=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw+9MKvS9aRCxd9lbln/w0xFtV52dRgycX8RGRIiVEsY3V5fNcc
	42QhT8PFZIRZeMsXflq3PgxVyikNi3nPvPGxJ31YEEBno0+QTfnjsHVUrychLA==
X-Gm-Gg: ASbGncuAEP1l0AklUxTyCerLxOG8FYufQ10LfT3o0Wi+zpQHLHYvnBte/nwiZHIVP+I
	a8D0cziErpElivKbf5B4sZFln/yBvRPId98myuylH4GyhfvXwrowS4AjotU0FKqU7JXq1LGkKEt
	nTqAmbNM/1YaD0G/ZsJi2M/oY9/AgnIFpAadLytCLL5A+cc+eTTidELrcev/juGBVoysoPXd1Ty
	hly6+J7FA4Lw2m0eCzxN8CCdaQoa9zagsfyOq3OmJIfLTgg3gSBOY5JLlVidyv2tLiWfknA15g5
	azE+emTJ/3pYrnKQ1RTYtnpdBHbZcK/G9s78XOdhvw==
X-Google-Smtp-Source: AGHT+IEKSFXDhmBxA08GlxK6p5ukC4vu+4LcF7EI2NTPrmoi+kZsn/dqADYrSc9WVrpLGy7Sb9SU0w==
X-Received: by 2002:a05:600c:5251:b0:434:9934:575 with SMTP id 5b1f17b1804b1-4365536f024mr54430215e9.16.1734595303617;
        Thu, 19 Dec 2024 00:01:43 -0800 (PST)
Message-ID: <37d13114-91eb-4d0f-9404-e5fd6cfca256@suse.com>
Date: Thu, 19 Dec 2024 09:01:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 2/5] xen: add bitmap to indicate per-domain state
 changes
To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 
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: <20241217142218.24129-1-jgross@suse.com>
 <20241217142218.24129-3-jgross@suse.com>
 
 
 
 <2fa06b11-e7a0-4f57-9af0-af432d35820a@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: <2fa06b11-e7a0-4f57-9af0-af432d35820a@suse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 18.12.2024 08:15, Jürgen Groß wrote:
> On 17.12.24 17:12, Jan Beulich wrote:
>> On 17.12.2024 16:55, Jürgen Groß wrote:
>>> On 17.12.24 16:19, Jan Beulich wrote:
>>>> On 17.12.2024 15:22, Juergen Gross wrote:
>>>>> Add a bitmap with one bit per possible domid indicating the respective
>>>>> domain has changed its state (created, deleted, dying, crashed,
>>>>> shutdown).
>>>>>
>>>>> Registering the VIRQ_DOM_EXC event will result in setting the bits for
>>>>> all existing domains and resetting all other bits.
>>>>>
>>>>> As the usage of this bitmap is tightly coupled with the VIRQ_DOM_EXC
>>>>> event, it is meant to be used only by a single consumer in the system,
>>>>> just like the VIRQ_DOM_EXC event.
>>>>
>>>> I'm sorry, but I need to come back to this. I thought I had got convinced
>>>> that only a single entity in the system can bind this vIRQ. Yet upon
>>>> checking I can't seem to find what would guarantee this. In particular
>>>> binding a vIRQ doesn't involve any XSM check. Hence an unprivileged entity
>>>> could, on the assumption that the interested privileged entity (xenstore)
>>>> is already up and running, bind and unbind this vIRQ, just to have the
>>>> global map freed. What am I overlooking (which would likely want stating
>>>> here)?
>>>
>>> I think you are not overlooking anything.
>>>
>>> I guess this can easily be handled by checking that the VIRQ_DOM_EXC handling
>>> domain is the calling one in domain_[de]init_states(). Note that global virqs
>>> are only ever sent to vcpu[0] of the handling domain, so rebinding the event
>>> to another vcpu is possible, but doesn't make sense.
>>
>> No, that's precluded by
>>
>>      if ( virq_is_global(virq) && (vcpu != 0) )
>>          return -EINVAL;
>>
>> afaict. That doesn't, however, preclude multiple vCPU-s from trying to bind
>> the vIRQ to vCPU 0.
> 
> I let myself fool by the ability to use EVTCHNOP_bind_vcpu for a global
> virq. While it is possible to send the event to another vcpu, it is still
> vcpu[0] which is used for the bookkeeping.
> 
>>
>>>>> V5:
>>>>> - domain_init_states() may be called only if evtchn_bind_virq() has been
>>>>>     called validly (Jan Beulich)
>>>>
>>>> I now recall why I had first suggested the placement later in the handling:
>>>> You're now doing the allocation with yet another lock held. It's likely not
>>>> the end of the world, but ...
>>>>
>>>>> @@ -138,6 +139,60 @@ bool __read_mostly vmtrace_available;
>>>>>    
>>>>>    bool __read_mostly vpmu_is_available;
>>>>>    
>>>>> +static DEFINE_SPINLOCK(dom_state_changed_lock);
>>>>> +static unsigned long *__read_mostly dom_state_changed;
>>>>> +
>>>>> +int domain_init_states(void)
>>>>> +{
>>>>> +    const struct domain *d;
>>>>> +    int rc = -ENOMEM;
>>>>> +
>>>>> +    spin_lock(&dom_state_changed_lock);
>>>>> +
>>>>> +    if ( dom_state_changed )
>>>>> +        bitmap_zero(dom_state_changed, DOMID_FIRST_RESERVED);
>>>>> +    else
>>>>> +    {
>>>>> +        dom_state_changed = xvzalloc_array(unsigned long,
>>>>> +                                           BITS_TO_LONGS(DOMID_FIRST_RESERVED));
>>>>
>>>> ... already this alone wasn't nice, and could be avoided (by doing the
>>>> allocation prior to acquiring the lock, which of course complicates the
>>>> logic some).
>>>>
>>>> What's perhaps less desirable is that ...
>>>>
>>>>> @@ -494,6 +495,15 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
>>>>>            goto out;
>>>>>        }
>>>>>    
>>>>> +    if ( virq == VIRQ_DOM_EXC )
>>>>> +    {
>>>>> +        rc = domain_init_states();
>>>>> +        if ( rc )
>>>>> +            goto out;
>>>>> +
>>>>> +        deinit_if_err = true;
>>>>> +    }
>>>>> +
>>>>>        port = rc = evtchn_get_port(d, port);
>>>>>        if ( rc < 0 )
>>>>>        {
>>>>
>>>> ... the placement here additionally introduces lock nesting when really
>>>> the two locks shouldn't have any relationship.
>>>>
>>>> How about giving domain_init_states() a boolean parameter, such that it
>>>> can be called twice, with the first invocation moved back up where it
>>>> was, and the second one put ...
>>>>
>>>>> @@ -527,6 +537,9 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind, evtchn_port_t port)
>>>>>     out:
>>>>>        write_unlock(&d->event_lock);
>>>>>    
>>>>> +    if ( rc && deinit_if_err )
>>>>> +        domain_deinit_states();
>>>>> +
>>>>>        return rc;
>>>>>    }
>>>>
>>>> ... down here, not doing any allocation at all (only the clearing), and
>>>> hence eliminating the need to deal with its failure? (Alternatively
>>>> there could of course be a split into an init and a reset function.)
>>>>
>>>> There of course is the chance of races with such an approach. I'd like
>>>> to note though that with the placement of the call in the hunk above
>>>> there's a minor race, too (against ...
>>>>
>>>>> @@ -730,6 +743,9 @@ int evtchn_close(struct domain *d1, int port1, bool guest)
>>>>>            struct vcpu *v;
>>>>>            unsigned long flags;
>>>>>    
>>>>> +        if ( chn1->u.virq == VIRQ_DOM_EXC )
>>>>> +            domain_deinit_states();
>>>>
>>>> ... this and the same remote vCPU then immediately binding the vIRQ
>>>> again). Hence yet another alternative would appear to be to drop the
>>>> new global lock and use d->event_lock for synchronization instead
>>>> (provided - see above - that only a single entity can actually set up
>>>> all of this). That would pretty much want to have the allocation kept
>>>> with the lock already held (which isn't nice, but as said is perhaps
>>>> tolerable), but would at least eliminate the undesirable lock nesting.
>>>>
>>>> Re-use of the domain's event lock is at least somewhat justified by
>>>> the bit array being tied to VIRQ_DOM_EXEC.
>>>>
>>>> Thoughts?
>>>
>>> With my suggestion above I think there is no race, as only the domain handling
>>> VIRQ_DOM_EXC could alloc/dealloc dom_state_changed.
>>
>> Yet still it could be multiple vCPU-s therein to try to in parallel.
> 
> But isn't this again the need for trusting other processes within the domain
> having the right to consume the virq?
> 
> In the end it doesn't matter whether there is such a race or not. Some
> process in that domain having the power to do event channel operations could
> simply close the event channel. So it IS really about trust.

Well. What we do in Xen should be correct without regard to what a guest might
be doing. And it should be safe against any not-fully-privileged entity in the
system. Hence why I think such a race needs dealing with correctly, no matter
that it's not a sane thing to do for a guest.

>>> Using d->event_lock for synchronization is not a nice option IMO, as it would
>>> require to take the event_lock of the domain handling VIRQ_DOM_EXEC when trying
>>> to set a bit for another domain changing state.
>>
>> Well, yes, it's that domain's data that's to be modified, after all.
> 
> True, but using d->event_lock would probably increase lock contention, as this
> lock is used much more often than the new lock introduced by my patch.

On a system with extremely heavy domain creation / teardown activity there may
be an increase of contention, yes. Whether that's a price worth to pay to avoid
introducing an otherwise unnecessary relationship between two locks is
precisely what we're trying to determine in this discussion. If the two of us
are taking opposite positions here, we'll simply need a 3rd view.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 08:18:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 08:18:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860843.1272816 (Exim 4.92)
	(envelope-from )
	id 1tOBjb-0002g9-S4; Thu, 19 Dec 2024 08:18:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860843.1272816; Thu, 19 Dec 2024 08:18: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 1tOBjb-0002g2-OA; Thu, 19 Dec 2024 08:18:15 +0000
Received: by outflank-mailman (input) for mailman id 860843;
 Thu, 19 Dec 2024 08:18: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 1tOBja-0002fd-T3
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 08:18:14 +0000
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
 [2a00:1450:4864:20::42f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c92e2aac-bde1-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 09:18:11 +0100 (CET)
Received: by mail-wr1-x42f.google.com with SMTP id
 ffacd0b85a97d-38634c35129so375651f8f.3
 for ; Thu, 19 Dec 2024 00:18: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-38a1c8471dcsm949709f8f.48.2024.12.19.00.18.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Dec 2024 00:18: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: c92e2aac-bde1-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734596291; x=1735201091; 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=knXxuQVwoprSPpTNFZm+X8RG+WfI8NEnmWZQoeUT02o=;
        b=QLj41t5Vq8PC8NWwx0KeuNlcHm4uKSTdKkk/DaQxsnmUa6GC35sEnXzYrp0G+vO5ot
         RNqM8Uq988zJTUEc83pMBNFqzH/A5kHSm2/kiP8d9h3XSXhAx4Fnz3svvq8Z2CrFxU3P
         zaGj/axs74QLwedW91iv2s7KIchO2ZtQoWop/ZuHKuIK6Bro5DORCsA3yaqVctKN0Rws
         7CMRD9FUe69jr0FPmhkBfATYfrQhO+xA1SGI57xNA54iopjlTjDLmdR44UQepxd8Q4je
         BcUiudvIQsqYC7AOBy1HGQ18ArDLs5+dJcsbr9qXCfbdEXCeouyzPUzyvF8cPMErzvRR
         7iPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734596291; x=1735201091;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=knXxuQVwoprSPpTNFZm+X8RG+WfI8NEnmWZQoeUT02o=;
        b=P9782s0rOiFuzM0Xs3aDdk4PSQhwtFqJ4SHrdffvlhebS1CRDe9nLSYUoE+Bn4UAwm
         fE/COVbngI48jTnWpwPUHez9+uA0ntGop1MH/irniVtR3iR8uUleDo1OeDQZ3YKvvNlq
         r5lJ+u42E5H0jtCWrkzTWaT5lOwomS2ofvhk1tSbDVNGZlJAAO1cV30truhDJdAp2XRD
         uUNzE6jRPljge4ubw6MqFyV9jAA3KSRuzfQ+jK/diSpStR1SYTKb87q9hxG++jmLtRvP
         p3gB0IEAMUg+QVVbgq8hyKiSwt/2YwPM77KiLbEQg1pj6Byzq5XZ5kHBL7dfj9ZuhrCj
         +oGw==
X-Forwarded-Encrypted: i=1; AJvYcCUtrSmCYNiRSbLXnBm1oO23UFmgcWV+NnYrth/baMfUa/Ew2ii5CV9gHgUuCyePA6/ho0mJR6xiWKo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxJL3p5ZNYHavBqmA4rYt8fgtw0HdkaE4elhLOF5Qvj1hj1xtvy
	tjvosnyZg4N6BoYMwThBoGHsTMgSdP7QB3SUnmmkgJy8otvTXP56vTJAKHwdeg==
X-Gm-Gg: ASbGncuxrnWXdgvn+nClRRamj/biSnIjYaS8/MT3wXDW7gexUuVtiXglfr799Fov8oM
	XGOpdgAx7xcpy+YcPCpm1+T7jmRmPzpYY3JmfOtzpBQI8YUz6O1810BVpqweFF2l15YvkVM0O+m
	Tmf4bGh2CAKB1zBi+N0oBfw/n3j7wJ8dQOGvqkQqyWcSpzWae+THfJI/H/6TvkDzIRVjy8hjIqJ
	o4GfBoNyh9BUcOQhX+MgVHgmyfUE0GP2ucC1nVaLBmCfQpju/R4h5dg4/Ye4t0y8BfRWGfuNmuT
	sGTAdTuNyreLXGQZfVi2ri1pXguHjn0U0wWxi3IQBA==
X-Google-Smtp-Source: AGHT+IGTfHKvCWxa7goRkS9w9mSbwKq4VzgBZvmPQnOzeec4rfuxRzTSDie28mrC3+GK48mCn78BCg==
X-Received: by 2002:a05:6000:1882:b0:388:c61d:43e0 with SMTP id ffacd0b85a97d-388e4d9c259mr4539737f8f.48.1734596290797;
        Thu, 19 Dec 2024 00:18:10 -0800 (PST)
Message-ID: <0f9766d4-cbd2-4c05-8ab0-e18a9757be0b@suse.com>
Date: Thu, 19 Dec 2024 09:18:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] x86/hvm: Use constants for x86 modes
To: Andrew Cooper 
Cc: Teddy Astie ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Xen-devel 
References: 
 <20241218170820.364253-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: <20241218170820.364253-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.12.2024 18:08, Andrew Cooper wrote:
> @@ -2952,11 +2954,11 @@ static const char *guest_x86_mode_to_str(int mode)
>  {
>      switch ( mode )
>      {
> -    case 0:  return "Real";
> -    case 1:  return "v86";
> -    case 2:  return "16bit";
> -    case 4:  return "32bit";
> -    case 8:  return "64bit";
> +    case X86_MODE_REAL:   return "Real";
> +    case X86_MODE_VM86:   return "v86";

I did ask for the string literal to also become "vm86". I'm simply
unaware of "v86" being used anywhere in the vendor docs.

> --- a/xen/arch/x86/include/asm/hvm/hvm.h
> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
> @@ -26,6 +26,20 @@ extern bool opt_hvm_fep;
>  #define opt_hvm_fep 0
>  #endif
>  
> +/*
> + * Results for hvm_guest_x86_mode().
> + *
> + * Note, some callers depend on the order of these constants.
> + *
> + * TODO: Rework this helper to avoid implying mixing the architectural
> + * concepts of mode and operand size.
> + */
> +#define X86_MODE_REAL  0
> +#define X86_MODE_VM86  1
> +#define X86_MODE_16BIT 2
> +#define X86_MODE_32BIT 4
> +#define X86_MODE_64BIT 8

As this block is no longer adjacent to hvm_guest_x86_mode()'s decl, perhaps
s/this/that/ in the comment?

Preferably with these adjustments:
Reviewed-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 08:19:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 08:19:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860850.1272827 (Exim 4.92)
	(envelope-from )
	id 1tOBkW-0003Aj-3v; Thu, 19 Dec 2024 08:19:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860850.1272827; Thu, 19 Dec 2024 08:19: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 1tOBkW-0003Ac-1L; Thu, 19 Dec 2024 08:19:12 +0000
Received: by outflank-mailman (input) for mailman id 860850;
 Thu, 19 Dec 2024 08: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 1tOBkU-0002xG-4G
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 08:19:10 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20625.outbound.protection.outlook.com
 [2a01:111:f403:2414::625])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ebb012ed-bde1-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 09:19:09 +0100 (CET)
Received: from MW4P223CA0017.NAMP223.PROD.OUTLOOK.COM (2603:10b6:303:80::22)
 by CY8PR12MB7708.namprd12.prod.outlook.com (2603:10b6:930:87::19) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Thu, 19 Dec
 2024 08:19:05 +0000
Received: from CO1PEPF000075F4.namprd03.prod.outlook.com
 (2603:10b6:303:80:cafe::59) by MW4P223CA0017.outlook.office365.com
 (2603:10b6:303:80::22) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.23 via Frontend Transport; Thu,
 19 Dec 2024 08:19:05 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CO1PEPF000075F4.mail.protection.outlook.com (10.167.249.43) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Thu, 19 Dec 2024 08:19:04 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) 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; Thu, 19 Dec
 2024 02:19:01 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) 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; Thu, 19 Dec
 2024 02:19:01 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 19 Dec 2024 02:18:59 -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: ebb012ed-bde1-11ef-a0d7-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Q7FwgRc4HOLWIaSCg26SK8NxgUVYjVipevLfVSgsrpIOT1brh3pV5DW+q09WvjOZjXXGwSiHpKPQseipktmlUcKy8ed5cQX6umoTqGjcasx8CYX3lE2TAhV2Y5Ua48F9M2MVNh5foPVPGgk5R6dE+fsUdbIGp35u2sEVuGvS1JjQEfainZLg7NxD2qu+mEurqhrv7vb4lkK2OBq7FVaNuaHZzCerhXd5+zqG2gmQODhXiUD20mfYw1J2IZeirldWof3LXtiaKH6IZCbuSrV1qC7Vq9zz2WDr7g9ZIU4TTNY25h3eVCaAPO8Ktjg6HS45ceB4ZKfggo4ZUC+ch2kFcg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=mb0Jwr8ZAr5STYERUAS8FBU5YnufPumQ0+feLCaQuAs=;
 b=JLXuRCX9lmeNCAbSPE10vtNnSyOqd1bQBaVa7IZSRDYwYAJaTn2sv97iQ7zcNubCH2pssWcB7lGSUN5l2TIShNbCGWjJS3j8AljbGOJiyj44QNXzRqfqfVS131lJ02n1qdByjRAiNmD0iPYH6oogULz9EmS5J1JuONGhMtRpP71gfZXqVy06ujYkgnf83e5Q1N3u6koqPATTycUasg2AY40NYYQ2XbFLTmKNnIyGJ6k7E3dy+QxXGf+a0OzEzcQWsHm0mnnCJJgwMTh+QwBkcjIHkialYmXjJTq7uS2xxrDMe/ODxcNE4/3tnTtkwdq3NXmZT8KAOrM5gxohVPnm6w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=apertussolutions.com smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=mb0Jwr8ZAr5STYERUAS8FBU5YnufPumQ0+feLCaQuAs=;
 b=oHe8/9GTbmsmKv+DhSWnN2dRmhxF6rIRBKAj889ypIM1cwtC6J4aN8IDTiL6zmJwBGiIYPEQdOYX1XU5n7X2wMP7vm4Tbf1EoDRSS/AYm3+cs28myW5KhPXX4l6Rixys6wLKoHbRGAg1GK+UVnYX6yAspyKPKMwOIdfZirvt+2w=
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=SATLEXMB04.amd.com; pr=C
Message-ID: <76b582ab-ede7-4fcd-9de3-247265ca862d@amd.com>
Date: Thu, 19 Dec 2024 09:18:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
To: "Daniel P. Smith" , Julien Grall
	, Sergiy Kibrik ,
	
CC: Andrew Cooper , Anthony PERARD
	, Jan Beulich ,
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini
	
References: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
 <4e437c60-4fee-40ed-9d2a-789bac0b36d9@xen.org>
 <63b21760-7dea-423b-a9d8-64d213c40b2c@apertussolutions.com>
 <2423b111-0a3e-42f8-a11e-02d81fa75eb5@amd.com>
 <1f17eea5-c3cd-4a78-9973-b5996bb1dd1e@apertussolutions.com>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <1f17eea5-c3cd-4a78-9973-b5996bb1dd1e@apertussolutions.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000075F4:EE_|CY8PR12MB7708:EE_
X-MS-Office365-Filtering-Correlation-Id: 049d64cf-5048-4537-dc75-08dd2005cd5c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|1800799024|82310400026|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?Rm80V25DaDZBUW0vMHEvTGFEU2Q0Yll2ZWdwMXJIK29UWjRkVGJWMloya2hp?=
 =?utf-8?B?Kys0SWFSYjZKaVRQM0xxOVJIbzZOZlBIeG1lVEc4czhBaml5OXhvL0pmcDFl?=
 =?utf-8?B?bWY0cGlKN2ppNTVPaGVvYkNNNDluZHdRaHhWMVBzOUU4cHNtRnU0Qm1DZnh3?=
 =?utf-8?B?ay9BWjlmbGRzOUdNOW1SbGlyc3R4ZEpQaUszc1dFQUI1S3Fyc0ZQcEdtbWth?=
 =?utf-8?B?R1Ayd3VVUkE2Q0V4c3hTelhxQStmSWRSRWJVL2pLakVxb2Vzc2hjQ2NxTmFk?=
 =?utf-8?B?MGNCS1pDeWhXRDZ3RndtQUQwZmJvcHNETllPYW4ycEEwWTlqUmthLzAzWVdC?=
 =?utf-8?B?UnZpTlpkWDFDby9vaDM1ZEpUTFI2WUlHZVVkTkV1aFhPZ3hNMHE1QnRPclBr?=
 =?utf-8?B?bEJJUFFRaXhmUFVZb2xGaDg5dGVYT2NNQTFWZk44VW1MdnhvU2V0UExaOVp3?=
 =?utf-8?B?S0FsRDg3NmpPaGtyTHNtVjRvK3hqUmdjaW9rRXNJNmMrYWc0a3padGlGY2Vq?=
 =?utf-8?B?Q3p5bUhyZjhzNkNyRzh5Q2VJY0dOQ1FURUN4ZWlyQ0I3by9Yekd4SC9pa2hX?=
 =?utf-8?B?R2J3Z1ZkbEZWVldRdGNVVkVMTlJEQXJJU1ZGT3F3S1kxc2JPNWdFck1WNXJi?=
 =?utf-8?B?Y1pKeGVmWWQ1OEVlM1RNODBHVjE2b3lVSHdYRUxMa0doaVMyOW9Vd3FXT0xQ?=
 =?utf-8?B?cHN4eVdNSXZ5RG56Z3YyUDJnTmlPWDdpOTI0NzA2QUJvaktDYVNMbThPb3lG?=
 =?utf-8?B?NjhSVFJleENUeDRjRzdCK012NTdzdFRsK1o5V0JtS0pTUkR0TElNak0vWkpH?=
 =?utf-8?B?M2ZRbWhyeUYzL3pOaXhwUnVpLy81VDVEL2x5SHIyZzFEZHRMNzBwZmhPbzla?=
 =?utf-8?B?NFJGWTR2WUR0SVVkWFo0blFTUmFHMDA1OUtDL0R3NmxqUU9tWmpvVjZjbHZW?=
 =?utf-8?B?OXhZZmNNd1JKRFVyR29uWnlXU0tSeVNyV0hTd3pYRnZGVmlrTVRxRWhXUEhO?=
 =?utf-8?B?c0gxOXJ6TkNsVXhzbkxKeG1XYk5hcy82QU9jbklpSlhZVHZMZ3lUc0VPVDV2?=
 =?utf-8?B?RGVrR1pKZGdCU2g2M2M1QkhzV0s1ZVZqNldpV1QvTVNBbWhwSDVGTGVvSUxj?=
 =?utf-8?B?NHBIOHdMVHF0M0ZsVEZRcmU1M0FTNnRIV000bG9FR3c0TUZsNjNaOHA1dzlO?=
 =?utf-8?B?WDZZcWhCM2ZhSUQxUjVvOXRQUHpCMDdZWXI1M2owY3BLQjMvREFqVE1uNWd6?=
 =?utf-8?B?SlRtYVJKSnFjellPK05veUF5OW5jSmozZ1RlczNvWXRuY1h2Y3dZMGZpYXpJ?=
 =?utf-8?B?K1h4ZVZnL2RKUmtpa3c5clhETlJHWjg5MDVmRE9NNGdpb3BnbUowWTFOcUpS?=
 =?utf-8?B?eEkyWms3YnovU1BxYXpjQ09RVHNaVDFIQ01mZmdxQXF2eHphYkxjTCt0enEr?=
 =?utf-8?B?VWNZcDJsZFl1RncwekwzR0lac2hNUi8xT1QyU09uUCtPMkxNV0ZDand2V1lI?=
 =?utf-8?B?MW1lWURPOWk1bEhGVEZpOFpSM3ZMaXB5WmtNSW5WMHlobnZRU3g0b2hJc0Ix?=
 =?utf-8?B?R29neHVVNlU0eER5TGZBWGFSbDFyRTVuaHByNkJUQ1REYm02SUIxZWRrT3FC?=
 =?utf-8?B?OEZPM3ZrdkdxcTg0WUtVL1hpdkZpQmVXQkVIUldxb3c2a1ZNbUY3K1VwUGxr?=
 =?utf-8?B?R0tvamFDclRDVE5rN2h0Mlp2aGpDSGxDYTJGam1VYUZzT204SGVyZmtWVjBV?=
 =?utf-8?B?Y213U21QNHNBa3ovODZsejdaSHVaMTVjVXZNUjhzOHNGQSs1VjZkTW5iQzBl?=
 =?utf-8?B?NmFINW1xRnZZMWFkMmVyZVF2eXI2UDFvZ3djTXMwc3pRSnlBbk9GeW5ZN2NS?=
 =?utf-8?B?cklOTFNiZzdnZ0NhdzNHUXZwYXNYbHlNWU12VmIydW5iNnBPR21SaTF6dlRH?=
 =?utf-8?B?Y2xEK05BKy9OWklCUUNYbUdza29lVlhoQklTUEZUNGFkWVVySWtsRWhIY0lN?=
 =?utf-8?Q?tWBmBgyhZqI/RgIHenzWUc3fwJOEjc=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2024 08:19:04.7100
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 049d64cf-5048-4537-dc75-08dd2005cd5c
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000075F4.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7708



On 18/12/2024 17:26, Daniel P. Smith wrote:
> 
> 
> Hey Michal,
> 
> On 12/18/24 06:04, Michal Orzel wrote:
>> Hi Daniel,
>>
>> On 18/12/2024 02:17, Daniel P. Smith wrote:
>>>
>>>
>>>> On 17/12/2024 11:47, Sergiy Kibrik wrote:
>>>>> Allow to build ARM configuration with support for initializing
>>>>> hardware domain.
>>>>> On ARM it is only possible to start hardware domain in multiboot mode, so
>>>>> dom0less support is required. This is reflected by dependency on
>>>>> DOM0LESS_BOOT
>>>>> instead of directly depending on ARM config option.
>>>
>>>
>>> Just to make sure my assumption is correct, you are looking to do a
>>> multi-domain construction at boot time, with at least two domains. One
>>> of those two domains is the "control domain" and one is the "hardware
>>> domain", aka late hwdom except it's not constructed "late".
>>>
>>> If you want such a configuration, I would highly recommend you first
>>> enable setting flask labels via dom0less (assuming it is not there)
>> Speaking about dom0less and FLASK. A year ago, I did sent you (privately, through
>> AMD hyperlaunch collab) my attempt to add minimal steps to enable setting FLASK policy
>> for dom0less domUs. You then told me that you have a slightly different vision on how it
>> should be done. Any update with that regard? TBH I though that you're going to add this
>> support together with other hyperlaunch patches.
> 
> As I mentioned back in my March response, the concern I have with the
> patch you provided was with the layering violation. A security label is
> a flask-centric concept, at least currently, and thus not a concept you
> want to expose in the general XSM api. The correct way to get an XSM
> module's specific info, or translation, is to use the xsm_do_xsm_op(). I
> do feel that xsm_do_xsm_op() has a laying violation in its
> implementation, and is what I want to fix, it is still the correct
> interface. Priorities in meeting the core requirements AMD needs from
> hyperlaunch resulted in several abilities to fall to the wayside for the
> time being. I understand things need to move along, so I would prefer
> the use of existing interface that can be just updated when
> xsm_do_xsm_op() does get fixed up.
xsm_do_xsm_op() is made as an interface between a guest and Xen and is expected to be
called from within a guest, just like any other hypercall. In dom0less case, it's Xen who
needs to convert seclabel specified by the user to SID. How do you expect Xen to use
xsm_do_xsm_op()?

~Michal



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 08:25:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 08:25:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860863.1272836 (Exim 4.92)
	(envelope-from )
	id 1tOBqd-0004wT-OL; Thu, 19 Dec 2024 08:25:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860863.1272836; Thu, 19 Dec 2024 08:25: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 1tOBqd-0004wM-Li; Thu, 19 Dec 2024 08:25:31 +0000
Received: by outflank-mailman (input) for mailman id 860863;
 Thu, 19 Dec 2024 08:25: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 1tOBqb-0004wG-IC
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 08:25:29 +0000
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com
 [2607:f8b0:4864:20::430])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id cd3c6893-bde2-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 09:25:28 +0100 (CET)
Received: by mail-pf1-x430.google.com with SMTP id
 d2e1a72fcca58-7273967f2f0so630071b3a.1
 for ; Thu, 19 Dec 2024 00:25:28 -0800 (PST)
Received: from [157.82.203.37] ([157.82.203.37])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-72aad90b2dcsm731694b3a.171.2024.12.19.00.25.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Dec 2024 00:25: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: cd3c6893-bde2-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=daynix-com.20230601.gappssmtp.com; s=20230601; t=1734596727; x=1735201527; 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=o67QXlwUSaMvrSq2RNzS6auV65CBM03JHc8UWQQqHC0=;
        b=qkAUyzHa5X2C3WH9VCbeL21WWP83dxNkLC6vPnL5oXp6bbpZw35DOwjncaVMMasO9L
         E+vZPfxurjCPGKBq9LVAU+qUgBSecrex/BNoSqJ4jZbxhuCDihfeLo9RNOh9TlpI9ttI
         qm+yi9zDVTWPcSKGZuSlwbB3LG2Ve/DZKy27+F/Z164CS3604M6me37tv3DK7lxv3Xx4
         1JNYGtwVqSAkkfDJWbOLWwJeAb2/pidETbQC+7ZJ9QRi8HCdCU82J+cZ+xe904xAbh19
         6t1mufiH0Al5gedKFLEbhzBsX9giP0YR/uhtCP38k4kRhBCKS7+gDwUPsGBiwvs5ZjNj
         n5+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734596727; x=1735201527;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=o67QXlwUSaMvrSq2RNzS6auV65CBM03JHc8UWQQqHC0=;
        b=A2h9pXTlssW98k91GmyZEqMz8pI6CiFQXIeyiIJjyAaVIdfFpy0vTSmvcjMsE+WhBu
         wk0NGBnsPUoFy3Uo5Kz4FARZIyV0q/z50KhlmAVz0O9GouTSFX/gdC9CFJwRe1QjGZcf
         8qaG22Ohc/fVQQL8gms6PFEk1nDWJ/jwUxRPfG+FH21XSocSrL5pIN+2rhRzOl9UJmcU
         I1xXv8tw6pQ8zLMp8N7bgmkYXBVnnZ5Hb5lo+phkB4+1hFSLULaFjJcwga0FNbJ72zbi
         8WWr++RLSWBkxw02V7bg54YKnPKkzx0luMsnEg+mePJxemZqbB9SdYCHhBtHr1LGv+s+
         URsQ==
X-Forwarded-Encrypted: i=1; AJvYcCVCIefbw504tAiBiyoHVtJdlDiwVczDEHDU8ov8gbTvZwX2mM6VM+Tf5oJqQGua4tNq4mwksBH5hho=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzVy0Sejrds3A2yUwp5XljJwa5T9Dc1wkPB1tYFAmd1ta2RqOgC
	tawiE+OId2UTlRSEgEwrhT3C1FIEdpntdB8xe7nHLLc9yvxTVpjFl2oFbcHwYrA=
X-Gm-Gg: ASbGnct87fM0DYMo5w59NgydzA9yagqSCXDJM/I6XPg718bzVcT9tdkbyArGeTBr3gU
	qhAJ/91k+YH18SFdZLq0kVtSJEEhXsOm/8Bmlfc2nYKkSX7KBEonU3EygHuQSpG0lBPWBuLHSr1
	OKVMI4g171OmiHlN4DKjQpJWaXYDWmQfqJTYuupcOXOz11LIxJvpT5LJxI0NYWFCo5b7FA/l0FU
	ImEDcX+VVvZf1sFiOYdEM3cfthdziTo/pwizVEj4I9ddqqGRGdMGjqK0B2CZApHgD0=
X-Google-Smtp-Source: AGHT+IFQJijP415U6JCAjCp82uq02Rg1oj+u9Wub9o3NGSctFU+2+abvxdsWCEhdbfKwmOkWOvHyhA==
X-Received: by 2002:a05:6a20:7faa:b0:1e1:3970:d75a with SMTP id adf61e73a8af0-1e5c74f3244mr3839079637.9.1734596726802;
        Thu, 19 Dec 2024 00:25:26 -0800 (PST)
Message-ID: <6c0ed1a4-d416-4d52-bbfd-40faadac35c4@daynix.com>
Date: Thu, 19 Dec 2024 17:25:17 +0900
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 41/71] hw/net: Constify all Property
To: Richard Henderson , qemu-devel@nongnu.org
Cc: Beniamino Galvani ,
 Peter Maydell ,
 Strahinja Jankovic ,
 Jason Wang ,
 "Edgar E. Iglesias" ,
 Alistair Francis , Pavel Pisa
 , Francisco Iglesias ,
 Vikram Garhwal ,
 Dmitry Fleytman , Stefan Weil ,
 Bernhard Beschow , =?UTF-8?Q?C=C3=A9dric_Le_Goater?=
 , Steven Lee ,
 Troy Lee , Jamin Lin ,
 Andrew Jeffery , Joel Stanley ,
 Sriram Yagnaraman ,
 Helge Deller , Thomas Huth ,
 Aleksandar Rikalo ,
 Subbaraya Sundeep , Jan Kiszka ,
 Tyrone Ting , Hao Wu ,
 Max Filippov , Jiri Pirko ,
 Nicholas Piggin ,
 Daniel Henrique Barboza ,
 Harsh Prateek Bora ,
 Sven Schnelle , "Michael S. Tsirkin" ,
 Stefano Stabellini ,
 Anthony PERARD , Paul Durrant ,
 Rob Herring , "open list:Allwinner-a10"
 , "open list:e500" ,
 "open list:X86 Xen CPUs" 
References: <20241213190750.2513964-1-richard.henderson@linaro.org>
 <20241213190750.2513964-46-richard.henderson@linaro.org>
Content-Language: en-US
From: Akihiko Odaki 
In-Reply-To: <20241213190750.2513964-46-richard.henderson@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2024/12/14 4:07, Richard Henderson wrote:
> Signed-off-by: Richard Henderson 

Reviewed-by: Akihiko Odaki 


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 08:32:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 08:32:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860871.1272847 (Exim 4.92)
	(envelope-from )
	id 1tOBxD-0006hN-EV; Thu, 19 Dec 2024 08:32:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860871.1272847; Thu, 19 Dec 2024 08: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 1tOBxD-0006hG-BX; Thu, 19 Dec 2024 08:32:19 +0000
Received: by outflank-mailman (input) for mailman id 860871;
 Thu, 19 Dec 2024 08:32: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 1tOBxC-0006hA-RN
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 08:32:18 +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 c0fb8d79-bde3-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 09:32:16 +0100 (CET)
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-436326dcb1cso3310505e9.0
 for ; Thu, 19 Dec 2024 00:32: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
 ffacd0b85a97d-38a1c84840asm985818f8f.61.2024.12.19.00.32.15
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Dec 2024 00:32: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: c0fb8d79-bde3-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734597136; x=1735201936; 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=VCDnzvCnk8Cw0+AvSfr/bEeJ0BUJl6r1LDMdgz9q02A=;
        b=R6nNfkG+zwd7qTlpFv1cWkGDiBTM0zeVN4ELr9VKjgHRHMLitVzUK2D4KvWOgOAD0v
         SRiXR7e6Ws9Uyuy1/ZrzWJJrMbNMpTDTcZDRnA2A05OGVifk3O6uOx6ptJEzgxckNNpi
         PmE0ETZuWFzzmCQpBDcRUeGJpbWgrRhd+StSFzyvJBGutP9DjBmJSsVQ1hExtm51XZhK
         yAV/HfqIc7Xw67PXJNHXaQU5sYHZFgwWqfMgyd6t1TVsOyFRcxzzwNXX3qC5fzpIlP/c
         mlELSIH8GhCJI7Pt2HUMhriG0ccE+nQ4jIcaBKMkRE2sKpKP3qtRUoxegHPvMYwS1NAE
         MZkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734597136; x=1735201936;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=VCDnzvCnk8Cw0+AvSfr/bEeJ0BUJl6r1LDMdgz9q02A=;
        b=eJRx4oD+ePqca7LcP8Nv1IPOmRO1ZeK0z/SNviZptsi1nfd+EOkGsWxHHtDxPL5lgr
         8HdPKnerN488KPl0ZmBHowVSje90r3Vv7BrKcYKV/caRjKnm2vDs/xU7Nx9OVNTpCUML
         07FKCUaWlwulsa5V1pk+LdKWiwhMRuIW8BlbRVKP3Y0xoKAIyHAkSAIrQb9E9WQENWT4
         9qIbYdGIJQgH28/pcc4UO0RABSelAi/A2kGMUF7EEHiueNMMFwTeTnILVsbeVVCIGHZX
         6SFn0JcrcX4bNp5N5fv/c+fVIrwxIPHmK308jpgTnRsV735nIQzSKd14a4FDEEHYrm3M
         zFtA==
X-Forwarded-Encrypted: i=1; AJvYcCUOT9buoTeF7+Y7/6lEDLwOSUmctVVWXer87noUx78Lpd91jcUcyw0bMqhXJLkfUkwjuTjHl6PDsxc=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yzrsj2+fuwoVIl50WjbSBeO8v4xdSmpt6JOooaKAkKjmHK/ATcW
	MI18CsuPiwEWc1pirjQPOGMQBlGs8B3K23gjLRCl6fpXxtDM5fJ43lWVc0lZAQ==
X-Gm-Gg: ASbGnctrrPAS1SEVEpj4cVzntUaBbrR6CigHJ+7NoaJYu7JBhgtjxf3d5FiIsjM5dXI
	4ItwPnHWoaltGVK5sev0fZw/zxe0s4Qz4PYP0MhaxyDcZkXNsXxNnrA/acCOCdA4zfdBMm8lVd2
	sEpVKm4E1xJN/Pxjw29tj1KKNu2edS29z5jNQw+KsdR8EakGhUmvmjAqgmzNKDdckuz+J3Rt+2p
	2IfatshNLBns8JcwKigA+BvTmr6cbBZbX2ed/FTI+XdAwj8wuvbLJ0C1/ZkaKOtKzZ5uiK+q7rI
	tD80C5b8KqKNLH+RYcBZE6VPBDvbdqc9xKkxNSAVpQ==
X-Google-Smtp-Source: AGHT+IF8Y7DizhDr559L8TfXVQpLUmGFnq4E+QGHys2eH6hMkW5tFzczCO4XUM44YYPEqlB6QJsVLg==
X-Received: by 2002:a5d:588b:0:b0:385:f195:27f with SMTP id ffacd0b85a97d-38a19adee81mr2395669f8f.5.1734597136268;
        Thu, 19 Dec 2024 00:32:16 -0800 (PST)
Message-ID: <7587b503-b2ca-4476-8dc9-e9683d4ca5f0@suse.com>
Date: Thu, 19 Dec 2024 09:32:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/1] xen/common: Remove dead code
To: Ariel Otilibili 
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: <20241218233659.573195-2-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241218233659.573195-3-Ariel.Otilibili-Anieli@eurecom.fr>
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: <20241218233659.573195-3-Ariel.Otilibili-Anieli@eurecom.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.12.2024 00:34, Ariel Otilibili wrote:
> The if-statement tests `res` is non-zero; meaning the case zero is never reached.
> 
> Coverity-ID: 1055253
> Fixes: e2b1ebf4de ("x86: Support booting a bzImage format domain 0 kernel.")
> Signed-off-by: Ariel Otilibili 

I certainly agree with the change, especially if Coverity complains about it.
In fact I'd expect Eclair to complain too, for this being unreachable or dead
code (I'm never sure which one's which in their nomenclature). The Misra
violation addressed may therefore want mentioning, too.

However, the commit referenced says "xen/common/inflate.c is taken unmodified
from Linux v2.6.28." Therefore the preferred approach would be to correct the
original first, then pull in that patch to our tree. (And yes, the code is
still as was even in 6.13-rc3.)

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 08:35:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 08:35:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860881.1272856 (Exim 4.92)
	(envelope-from )
	id 1tOC0B-0007K7-VO; Thu, 19 Dec 2024 08:35:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860881.1272856; Thu, 19 Dec 2024 08:35: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 1tOC0B-0007K0-Sl; Thu, 19 Dec 2024 08:35:23 +0000
Received: by outflank-mailman (input) for mailman id 860881;
 Thu, 19 Dec 2024 08:35: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 1tOC0A-0007Ju-H8
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 08:35:22 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20629.outbound.protection.outlook.com
 [2a01:111:f403:2416::629])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2e1dceda-bde4-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 09:35:21 +0100 (CET)
Received: from BN0PR02CA0027.namprd02.prod.outlook.com (2603:10b6:408:e4::32)
 by CY8PR12MB8216.namprd12.prod.outlook.com (2603:10b6:930:78::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.21; Thu, 19 Dec
 2024 08:35:15 +0000
Received: from BN2PEPF000055E0.namprd21.prod.outlook.com
 (2603:10b6:408:e4:cafe::e3) by BN0PR02CA0027.outlook.office365.com
 (2603:10b6:408:e4::32) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.23 via Frontend Transport; Thu,
 19 Dec 2024 08:35:15 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 BN2PEPF000055E0.mail.protection.outlook.com (10.167.245.10) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8293.6 via Frontend Transport; Thu, 19 Dec 2024 08:35:15 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 19 Dec
 2024 02:35:14 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 19 Dec 2024 02:35:13 -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: 2e1dceda-bde4-11ef-a0d7-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=SEzPW8oj0xkJAK6mCQemGJeyECyXX20k8zPcvDOsC4mqRVk3u7mSsjFmPMbrrkuu++XEBtJOMuO+X7LPh7hAbYFuGRmqb+OiuxOmW6QQS6qBCAynogbJdNAs94nNic5DtDoIow4UqsQSSLAlf5xFbVdTqsqCYQEpfWg7TzEy0YT7+HccC9336ymUkRvJ57XXFMZtFjd5ftsJ8OEDiR9CDoMa2GmBxJEJjuLNTG2fZ5m2IHy6n4PFPJ11ahKvfYIdr/sDBFRRCyOLGT3i9fPYTfCD51DMZj7inlXrVuQ4XW2ZmqAUy+rJYcZl9OXeJpPHfV8QiZgoXmH7xDul7AUFxA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hAHrhjbA8ZxstVIvrjFVnAQVN2BasfbOEDxo27On6Lg=;
 b=idnMo1f8u/tskpTyLQRiMZh9C0dCfRXvBYjP2je9dBgtv47kR5n+pVb66RkwbI9cG1qfMLrJgEoY/khpNPbogbESwyOk8qZEJXHO6rFBeH7wnYUZbWjwyZkCVQwa0MLhQAyd000gZSHMMK6QO1XHu4e/1fnxSQ+RudatNkdKn4HfIWRT4J2GGkLxLu+xF9or82Ifee1rhwRr8LgqCsYAABz8odUXXc9emMFJyKDVoXeJIm4uwmclX6VevgadRIP0dTaSXbvpK6RxYn6sWK9RkU+LlveHQtJtATCd3FE8bi0TMoQzw0xV6c1N0WdneESWSoklOeDGOaun100IpgmtUQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=oss.nxp.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=hAHrhjbA8ZxstVIvrjFVnAQVN2BasfbOEDxo27On6Lg=;
 b=zkW7P4WmvTCEgzw3i9LqXYTgR3zaoQMpr0HV/CGwcE2O9FO+KDsvaEX52Nu3vbZtLefWGqhaRWjEFPJP6kVUJZKEAt8V6PWvPWNDqvqwupWRPrslyMv+xndMin3Niau+3fpUyliiOtgMocniRUXKW4ynnUOUVOPntx8m0UKllKY=
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=SATLEXMB03.amd.com; pr=C
Message-ID: <87aad119-a55e-4683-824c-606f681af60c@amd.com>
Date: Thu, 19 Dec 2024 09:35:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/6] xen/arm: firmware: Add SCMI over SMC calls
 handling layer
To: Andrei Cherechesu ,
	
CC: , Andrei Cherechesu , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Volodymyr Babchuk
	
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
 <20241218101142.1552618-2-andrei.cherechesu@oss.nxp.com>
 <60d4ac08-c5e8-4a38-bfc9-2b73e6cf5ec7@amd.com>
 
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN2PEPF000055E0:EE_|CY8PR12MB8216:EE_
X-MS-Office365-Filtering-Correlation-Id: fa6c8940-fbe7-4954-23bd-08dd20080fdd
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?WUgrWVNUclREcSthd0dlWFBXWjNIb3B1WndTaEh4Smk3a29QbGpweUwxNkxG?=
 =?utf-8?B?NWhVUG9ZMGErNm1SVXc4d3RkREFycys2UGdrRWxTM1hjU21pVlA2TUJHdVRE?=
 =?utf-8?B?cTBCMU1FYXhvc0w0bWpiTjQyOGxzc3FqNHQ3REpGU1Q3cng0cllqanFUZHA5?=
 =?utf-8?B?MWxhWG1Pdko3TnRTR0QvM1lkOFlHZmZpUnZhc1l5c0UvUytHYzlPSTF6NXNa?=
 =?utf-8?B?b1dZbHVSUit0ZDl4TGxjdkVQeWUxaHRmOEhBZnZiRkI5b09NU0JwTGhyeUNj?=
 =?utf-8?B?c245ZkYyUUJnVmhoNzg5TkVzMWtEb0xNTUNjaTloN3duNEVkenJYenJLeVkr?=
 =?utf-8?B?dVU5aHlqL1VXL1kvandUS25PYTkrS2VlRS91ZEdaSnF4N1NWQ3Y1QkFiZGhj?=
 =?utf-8?B?aWpnWWU3QUZLZjk2SE5MZkVvY052T2g1WU05cjFBbHNwR0kvT2FvM1RzZjZt?=
 =?utf-8?B?ZWxjdDRKcW81dXFoZXlWeGJ6RjNuVXRFcWJxL2ZMbGlnRFBjRGJZSFQwdmNl?=
 =?utf-8?B?cW5TUGpsVVUvTVZoYXZDMkhVS3gyK2pvbVZnemkvcllGRmhBelNxU01pUVA0?=
 =?utf-8?B?NmpXaGtZWENCRCtZNllWelVzVWNydXI4cDFnK1Via2NCa24weWNNR1FHNFR5?=
 =?utf-8?B?Q3EwMGR5NE8yQTFoYkxwYkI4V0pqUXlwMVl4dFM5anlnNFZFQXk1eUdhbUpn?=
 =?utf-8?B?TTZ6SS8vWXV5WCtSUnh2SEdNeU9PeUJIT2tUZVpaajMzS3E2TTNoRGFPeDhm?=
 =?utf-8?B?c3lpZWs2eGE3MTFPZDZManNTMkp5TUFNak10NUFiU1V3MUxnSlFtUkl6cDZS?=
 =?utf-8?B?eTNDS1NneUxseU9mRHc3RjkwV3pxN2VhbnBNcERqeElEZHpEZjJVdmkrMkpo?=
 =?utf-8?B?VjFTeVFMU0F5b2FMZDdLOGw2emtsSEdaUldyRUowWDJ3Lzk5VjQ2aGZOL0pI?=
 =?utf-8?B?dVBCN1dFbGtsdFlkWElTenlYSEZQWmVsQ2xRaWdUNlh0UlYyRTduQ0dlTmRB?=
 =?utf-8?B?QTRJKzVNaTQrVWIvOXdIbmwrZUVha0t4ME5ZSTNON0JtTTFUU3RRSDVDSmhm?=
 =?utf-8?B?QStXbkEwVEg0QVlZR3A2dGhuV0Foaml3MnlMYUtlbE5NaEN1LzVOSmtZWHd3?=
 =?utf-8?B?OFhOamthbzYrL2JXZXNJYjQ2MnhMOERPdlNhWnVaZDNQSzcyZmxuS1BEa3FF?=
 =?utf-8?B?eEFnaHg5VWVDR2VIRzh3bks1bDZYQmp5bTRRRS9Manl4TkZEdGZOcHZVUUN5?=
 =?utf-8?B?ckVkaEdVSlBmMTVyc25HWEZMa2xLaFhPMWFQMHJGQXRqRVdibm5yU21GNURo?=
 =?utf-8?B?R3RYbGxQblZteGlHSTRCOUE3UVJpOFUwYjBTN3lDci9JdzFSM01XQVJobUpU?=
 =?utf-8?B?UThHL01EajZXOTdDQStEOWNHS0JrKzRhNlNEL21qTE1vYkZwRXhwYk93dTBR?=
 =?utf-8?B?T0tkNWRXUEw1bzd3eWlWNTdQSjd3QkFFY1BtUjJJalQ0QlJnZlJ5MmZ6UlF4?=
 =?utf-8?B?ZE02VjFrK0lCM1diK29QRGFtRkVtV2FtSHVXNzBjZGt2ZThuN3dVenF2MXFJ?=
 =?utf-8?B?S2k5RWhYeEhaY1dKNGFROVBsaFRkSWE1dmVTK1Q1NzJrN05sRkh1Ty9EOGFp?=
 =?utf-8?B?VlBSS2owcHlYbksxNkN1MlZKOTJYYnoxSnYvNjhJeGdUQlVZazY0dm5JemVi?=
 =?utf-8?B?NjBXbHA0NkpZYXRWZGkvcUMwam9wU2RVU2huYWNOaWpzcTVTbmRqbE9Pai9O?=
 =?utf-8?B?Y0tQMm1MbDNCTk53d211dUdOQ0ZXL3NkOEVnem5MRmZEZUxxUWFpMWlQUkcv?=
 =?utf-8?B?QmJzWDR0NDY5UXJPK1lFZ2E2ZkF2ZG9aVWNOWDUxM3hra1BQaVptcWhZQnQw?=
 =?utf-8?B?ZEZHYno2bkQ5NnlJVDZjME1QdDNUbVlYNThZelBTODB4clF6VENIbmZhV3hJ?=
 =?utf-8?B?eTBuaXdlOFhRTzVtcmlETk4zY2dDRzU3QnNYQ2JJb1BYVktvZFNGNDhVbEx0?=
 =?utf-8?Q?sw1H5CdOqgz7tFZlU8mRJLAcm4HNl8=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2024 08:35:15.3831
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: fa6c8940-fbe7-4954-23bd-08dd20080fdd
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN2PEPF000055E0.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8216



On 18/12/2024 15:58, Andrei Cherechesu wrote:
> 
> 
> Hi Michal,
> 
> Thank you for the review.
> 
> On 18/12/2024 16:26, Michal Orzel wrote:
>>
>> On 18/12/2024 11:11, Andrei Cherechesu (OSS) wrote:
>>>
>>> From: Andrei Cherechesu 
>>>
>>> Introduce the SCMI-SMC layer to have some basic degree of
>>> awareness about SCMI calls that are based on the ARM System
>>> Control and Management Interface (SCMI) specification (DEN0056E).
>>>
>>> The SCMI specification includes various protocols for managing
>>> system-level resources, such as: clocks, pins, reset, system power,
>>> power domains, performance domains, etc. The clients are named
>>> "SCMI agents" and the server is named "SCMI platform".
>>>
>>> Only support the shared-memory based transport with SMCs as
>>> the doorbell mechanism for notifying the platform. Also, this
>>> implementation only handles the "arm,scmi-smc" compatible,
>>> requiring the following properties:
>>>         - "arm,smc-id" (unique SMC ID)
>>>         - "shmem" (one or more phandles pointing to shmem zones
>>>         for each channel)
>>>
>>> The initialization is done as initcall, since we need
>>> SMCs, and PSCI should already probe EL3 FW for SMCCC support.
>>> If no "arm,scmi-smc" compatible node is found in the host
>>> DT, the initialization fails silently, as it's not mandatory.
>>> Otherwise, we get the 'arm,smc-id' DT property from the node,
>>> to know the SCMI SMC ID we handle. The 'shmem' memory ranges
>>> are not validated, as the SMC calls are only passed through
>>> to EL3 FW if coming from the hardware domain.
>>>
>>> Create a new 'firmware' folder to keep the SCMI code separate
>>> from the generic ARM code.
>>>
>>> Signed-off-by: Andrei Cherechesu 
>>> Reviewed-by: Stefano Stabellini 
>>> ---
>>>  xen/arch/arm/Kconfig                         |   2 +
>>>  xen/arch/arm/Makefile                        |   1 +
>>>  xen/arch/arm/firmware/Kconfig                |  13 ++
>>>  xen/arch/arm/firmware/Makefile               |   1 +
>>>  xen/arch/arm/firmware/scmi-smc.c             | 166 +++++++++++++++++++
>>>  xen/arch/arm/include/asm/firmware/scmi-smc.h |  46 +++++
>>>  6 files changed, 229 insertions(+)
>>>  create mode 100644 xen/arch/arm/firmware/Kconfig
>>>  create mode 100644 xen/arch/arm/firmware/Makefile
>>>  create mode 100644 xen/arch/arm/firmware/scmi-smc.c
>>>  create mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h
>>>
>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>>> index 604aba4996..23dc7162a7 100644
>>> --- a/xen/arch/arm/Kconfig
>>> +++ b/xen/arch/arm/Kconfig
>>> @@ -271,6 +271,8 @@ config PARTIAL_EMULATION
>>>           not been emulated to their complete functionality. Enabling this might
>>>           result in unwanted/non-spec compliant behavior.
>>>
>>> +source "arch/arm/firmware/Kconfig"
>>> +
>>>  endmenu
>>>
>>>  menu "ARM errata workaround via the alternative framework"
>>> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
>>> index e4ad1ce851..8c696c2011 100644
>>> --- a/xen/arch/arm/Makefile
>>> +++ b/xen/arch/arm/Makefile
>>> @@ -6,6 +6,7 @@ obj-$(CONFIG_HAS_PCI) += pci/
>>>  ifneq ($(CONFIG_NO_PLAT),y)
>>>  obj-y += platforms/
>>>  endif
>>> +obj-y += firmware/
>>>  obj-$(CONFIG_TEE) += tee/
>>>  obj-$(CONFIG_HAS_VPCI) += vpci.o
>>>
>>> diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig
>>> new file mode 100644
>>> index 0000000000..817da745fd
>>> --- /dev/null
>>> +++ b/xen/arch/arm/firmware/Kconfig
>>> @@ -0,0 +1,13 @@
>>> +menu "Firmware Drivers"
>>> +
>>> +config SCMI_SMC
>>> +       bool "Forward SCMI over SMC calls from hwdom to EL3 firmware"
>>> +       default y
>>> +       help
>>> +         This option enables basic awareness for SCMI calls using SMC as
>>> +         doorbell mechanism and Shared Memory for transport ("arm,scmi-smc"
>>> +         compatible only). The value of "arm,smc-id" DT property from SCMI
>>> +         firmware node is used to trap and forward corresponding SCMI SMCs
>>> +         to firmware running at EL3, for calls coming from the hardware domain.
>>> +
>>> +endmenu
>>> diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefile
>>> new file mode 100644
>>> index 0000000000..a5e4542666
>>> --- /dev/null
>>> +++ b/xen/arch/arm/firmware/Makefile
>>> @@ -0,0 +1 @@
>>> +obj-$(CONFIG_SCMI_SMC) += scmi-smc.o
>>> diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-smc.c
>>> new file mode 100644
>>> index 0000000000..62657308d6
>>> --- /dev/null
>>> +++ b/xen/arch/arm/firmware/scmi-smc.c
>>> @@ -0,0 +1,166 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>>> +/*
>>> + * xen/arch/arm/firmware/scmi-smc.c
>>> + *
>>> + * ARM System Control and Management Interface (SCMI) over SMC
>>> + * Generic handling layer
>>> + *
>>> + * Andrei Cherechesu 
>>> + * Copyright 2024 NXP
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +#define SCMI_SMC_ID_PROP   "arm,smc-id"
>>> +
>>> +static bool __ro_after_init scmi_support;
>> I don't understand the need for this variable. IMO it's useless, given that in next patch you do:
>>
>> ...
>> if ( scmi_is_enabled() )
>>     return scmi_handle_smc(regs);
>>
>> return false;
>>
>> which could simply be changed to:
>> ...
>> return scmi_handle_smc(regs);
>>
>> and the variable, functions for it, etc. could be removed which would simplify the code.
>>
>> [...]
> 
> Well, I agree that the code would maybe be simpler, but
> that means we would call `scmi_handle_smc()` both when
> SCMI-SMC layer is initialized and when it is not.
> 
> That then means that if `scmi_handle_smc()` returns false,
> we won't know in the caller if the SCMI-SMC layer is not
> initialized at all or if it is initialized, but the SMC
> request is invalid (it does not have the SMC ID we expect).
> Do we need to, though?
Let me explain more:
scmi_handle_smc() is called from within handle_sip() that can result true/false.
If SCMI is disabled, we need to return false. If SCMI is enabled but request is
invalid we need to return false as well. If SCMI is enabled but not initialized
we also need to return false. I suggest to drop scmi_is_enabled() as exported
function and only use scmi_handle_smc() as global like I did in my example.
Now, this solves the part where SCMI is disabled since you have a stub returning
false and also the part where SCMI request is invalid. However, this does not
solve the part where SCMI is enabled but layer not initialized. To fix it, you
simply need to check inside scmi_handle_smc() if it's initialized. That's much
simpler than requiring to use another global function which is not nice.

Diff below:
diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-smc.c
index 62657308d61d..b3f34bdbb89b 100644
--- a/xen/arch/arm/firmware/scmi-smc.c
+++ b/xen/arch/arm/firmware/scmi-smc.c
@@ -24,12 +24,6 @@
 static bool __ro_after_init scmi_support;
 static uint32_t __ro_after_init scmi_smc_id;

-/* Check if SCMI layer correctly initialized and can be used. */
-bool scmi_is_enabled(void)
-{
-    return scmi_support;
-}
-
 /*
  * Check if provided SMC Function Identifier matches the one known by the SCMI
  * layer, as read from DT prop 'arm,smc-id' during initialiation.
@@ -52,6 +46,9 @@ bool scmi_handle_smc(struct cpu_user_regs *regs)
     uint32_t fid = (uint32_t)get_user_reg(regs, 0);
     struct arm_smccc_res res;

+    if ( !scmi_support )
+        return false;
+
     if ( !scmi_is_valid_smc_id(fid) )
         return false;

diff --git a/xen/arch/arm/include/asm/firmware/scmi-smc.h b/xen/arch/arm/include/asm/firmware/scmi-smc.h
index 57cc9eef8676..58730a8037c5 100644
--- a/xen/arch/arm/include/asm/firmware/scmi-smc.h
+++ b/xen/arch/arm/include/asm/firmware/scmi-smc.h
@@ -17,16 +17,10 @@

 #ifdef CONFIG_SCMI_SMC

-bool scmi_is_enabled(void);
 bool scmi_handle_smc(struct cpu_user_regs *regs);

 #else

-static inline bool scmi_is_enabled(void)
-{
-    return false;
-}
-
 static inline bool scmi_handle_smc(struct cpu_user_regs *regs)
 {
     return false;
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index c4d225c45cd3..62d8117a120c 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -232,10 +232,7 @@ static bool handle_sip(struct cpu_user_regs *regs)
     if ( platform_smc(regs) )
         return true;

-    if ( scmi_is_enabled() )
-        return scmi_handle_smc(regs);
-
-    return false;
+    return scmi_handle_smc(regs);
 }

 /*

~Michal



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 08:41:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 08:41:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860890.1272867 (Exim 4.92)
	(envelope-from )
	id 1tOC61-0000jt-I4; Thu, 19 Dec 2024 08:41:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860890.1272867; Thu, 19 Dec 2024 08:41: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 1tOC61-0000jl-FP; Thu, 19 Dec 2024 08:41:25 +0000
Received: by outflank-mailman (input) for mailman id 860890;
 Thu, 19 Dec 2024 08:41: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 1tOC60-0000jf-5j
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 08:41: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 0588d904-bde5-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 09:41:21 +0100 (CET)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3862d16b4f5so345715f8f.0
 for ; Thu, 19 Dec 2024 00:41:21 -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-38a1c833899sm1010308f8f.42.2024.12.19.00.41.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Dec 2024 00:41:20 -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: 0588d904-bde5-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734597681; x=1735202481; 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=6k/WBCkl7iCln5WNVAn5Y+/eeL+jo8CzgxPWBCK+wx0=;
        b=WoxSgaPJj8ZrH9nork8dE5/OtZsY085gks2m+v+ffM7MakZRQp8vF8UeMrYa0R/+8H
         ZWJE12wuPd9LbZ7FxWW7QcWTk33xspWZtU6XsOoXHUMUIW6V+9xMayyynZvAWxRY41/u
         VK/o5FCzev33k8Hs/XG9U3Eu7fUkXT+Mu1tOB6MTrO011vbHC/REG3ziBY7QoRyziqlO
         waukmJ7g1XB/Lgx+K5nGHuFA2LxlX62UJEYjfia0NoPf68PXgGVMWm2OrjkQOvLYN2tv
         qunDH8oMKA3TDjcZl7RItWusGZxUjYICxOZ1VzhaufC2wbGJ+oMuy5uLl4nU9n9h+kyD
         Ck4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734597681; x=1735202481;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6k/WBCkl7iCln5WNVAn5Y+/eeL+jo8CzgxPWBCK+wx0=;
        b=p+G+3g5H9VBBIJW7ZIopUL9YQ2khsM7qh7rI6axXQzWyUNgrvqvu+pvAtUAAcpt2sL
         sWKAwaMnpdBELYx8feQNEhqOLyyeRODxo3iMnWCZPb5oWBGZFRMwv3vn7kfm8FSPaZG2
         zoOYh2sSigpp2TMzNfGbtxNAmItTKEb6Kyo8MM9lhoOZ1mwJsw7IZ9GSWz62EX9zGfSM
         fZuHj2fd8I2PMIcSz5d4dx2mPmW2b91bt0orkcChWB0STOa2gV3yC5b1M4T8ulasQDAM
         eRPJja/yLkvlj2r5q8DduZGok/FEnQM0nURVubbwhv8/cGtDfwqCR+x2dz8BCRB2MAS+
         /Ozg==
X-Forwarded-Encrypted: i=1; AJvYcCX8YrtJQdrvsa9mBNMEF0n/BbWG16ucfqPKlE77rq6qrc9sZhBz/PJixpICmSGi2nceGfWZ6PF8Rbg=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyQs+XhcQUAnHrNiJIQCcX9PrAkLuU3sjFA0EsIGbFxqkzfBSTR
	NLCgpJE8G0UA/XLxOD2204vL38AI+6if9EQlhvb5mwbRxXaEiH08stpZikZW/A==
X-Gm-Gg: ASbGncsY8APQYA76+cAT367tovuxlxN7JouPLWUipd899Jxk2YkY8AMbj8CBFpN2XMK
	fSsID8pJbb9NkS27oa7u+M3usQVRU/Fge8VLj9JPiW8CkGmCaRyAl6t0pUFLqgs2JgzL0B3Hx6F
	uZ4tKtLNBroVFE1N3VrMXyq69YKdyYsrakbin3s/2EeVnMLMae8wNaOORN1rL4P57gJyWhr2hXG
	v+SJkjELDRp05Omnu38dLDLs1TJR6H4qBpVcLcVVvnIeHOR2fnE5JJmfz2yiV9axUYhAStacEEA
	jdshm4Q0RZbMFWaBvwA/mb1cBatGkBeITwfE+G7eCQ==
X-Google-Smtp-Source: AGHT+IHCiHf1/bPsT/BhRkoJk8oRl8joVnBCEud3zqc9X1KHn+PXDdDlgrJN1Gne4wds4QzlSt6qpg==
X-Received: by 2002:a5d:64e6:0:b0:385:e3e7:547b with SMTP id ffacd0b85a97d-38a1a237d53mr2230865f8f.25.1734597681081;
        Thu, 19 Dec 2024 00:41:21 -0800 (PST)
Message-ID: <224c0fde-a8c2-4d44-b1bb-48e7ed6daee5@suse.com>
Date: Thu, 19 Dec 2024 09:41:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/libxg: Don't gunzip the guests initrd
To: Andrew Cooper 
Cc: Anthony PERARD ,
 Juergen Gross , Michal Orzel ,
 Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Oleksii Kurochko ,
 Xen-devel 
References: <20240904123121.3837140-1-andrew.cooper3@citrix.com>
 <20241218185453.367465-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: <20241218185453.367465-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.12.2024 19:54, Andrew Cooper wrote:
> Decompressing the kernel is necessary to inspect the ELF notes, but the
> dombuilder will gunzip() secondary modules too.  Specifically gunzip(), no
> other decompression algorithms.
> 
> This may have been necessary in the dim and distant past, but it is broken
> today.  Linux specifically supports concatenating CPIO fragments of differing
> compressions, and any attempt to interpret it with a single algorithm may
> corrupt later parts.
> 
> This was an unexpected discovery while trying to test Xen's gunzip()
> logic (Xen as a PVH guest, with a gzipped XTF kernel as dom0).
> 
> Intepreting secondary modules *should* be left as an exersize to the guest.

Nit: "Interpreting" and "exercise" and ...

> This reduces work done in dom0.
> 
> This is not expected to cause a practical different to guests these days.

... "difference"?

Acked-by: Jan Beulich 

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 08:49:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 08:49:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860899.1272877 (Exim 4.92)
	(envelope-from )
	id 1tOCDu-0001Mn-AI; Thu, 19 Dec 2024 08:49:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860899.1272877; Thu, 19 Dec 2024 08:49:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOCDu-0001Mg-7N; Thu, 19 Dec 2024 08:49:34 +0000
Received: by outflank-mailman (input) for mailman id 860899;
 Thu, 19 Dec 2024 08:49: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 1tOCDs-0001Ma-V3
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 08:49:32 +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 29f6b1b0-bde6-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 09:49:31 +0100 (CET)
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-385e3621518so240599f8f.1
 for ; Thu, 19 Dec 2024 00:49: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-38a1c832e74sm1016182f8f.30.2024.12.19.00.49.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Dec 2024 00:49: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: 29f6b1b0-bde6-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734598171; x=1735202971; 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=pZha6CRepn+kvo6dN/6fOPku6KxKZxMF2UiC4SlhuBE=;
        b=QRbpdXBZ034XpDShQ8qD6wRUfPo3eCO26Ig4pwW5GzVR39dFr6DQWa0qIP1TGgYf+S
         oe3EZuPfC0NVDOe0PJmQGDTUenUBezNYwTceGcFsxEc+u1+i9i1sGjtFY75j6MckTb6R
         mxAOY8jc9ies7Gb4+LsYGhgVM7V6OLIqXkmKPmbzROjRjrsPA5ali+hVTPzuCerBz5wc
         g5Vd4wzf6yLu4aC0IWyrD8Lb8kkbdLZ8uGjykHeWe6b1M/8bnQJsct54rabbW8Ycp8IP
         ahs9tSGIxNuD2/3F4Dy47u5YCfrXv3IFHqQl3KgmMPxO0vrCeWxq7NBdYFNYoSk6+wCQ
         Eqyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734598171; x=1735202971;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pZha6CRepn+kvo6dN/6fOPku6KxKZxMF2UiC4SlhuBE=;
        b=cHQWZTWDijQ8/+oPsBTAL28hmEy+CZYaO9jfnoxF9ecnxwXp1k98/GrrAjmPeXh/Ko
         fhyNNns8OE5ie/qmUk2LoXLcJ7fSNhkVnZIWtKvXUBQKn/juOyY84EqcYKylclEqrFv0
         p4lEgKOPu2iCr08mqoanxiAWQmFdxKzPruRNW3XBwWgQHKP9gyanAPaww3s1llKIBoxX
         qh97rYyGF4CrxZxp3bYT17Io+/1T7QxB+DQkyQjJbbyZdIkSwYCkt1z9qUdHNOQpOkBb
         sVevzfsG2zjqkHhKlKNljtH7X+cZzgCDid2neIVPyLd5RQ95+PXGNX9i8lvAua8dEyQI
         OxzA==
X-Forwarded-Encrypted: i=1; AJvYcCU/n1HYbv5n6BtFmazRfGqrWEGSs8L9ModPB7z5Om5vshYvXtixYlmX5fz8xod39NjV0ZergWpr3NA=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxa8NJzUbSOITA2y8tsxuSrJGXYo6sORAygMc6F6Ljs34VSbWxp
	5IA1b8k143nM88VHwJk4mYvEfR7i7BuU3DmqZiLopcsPdZmBajHIvSDJP0Teow==
X-Gm-Gg: ASbGnctsW3B5qBsoRhkmpQrVOXS3rwFQs7St5tgy/Tj2McsNlI7I4x+eSEeUodoKup+
	zyInZ/3sSct2L1HQJUioLZ1AD/z9MDf59df7svmEJcSi0tKmdeUd9DN+Irw6pwgpLor5qG3QnCb
	ffX+nRRHooKFEFejIzrjOAe3gNaRdL5iEOJmq1XwUHs4ojpHCEx+B99220ISYW7lFJYM6LkM3Dc
	Cd65VoeJBAQbF5x1c+NBy1t71hSscBcN2V1iJWLpNDrz+VKf6w/wWLU64SvhwGcP2H6yRnvIRrH
	g0SF/Tzas2eFkfuGbqfdiTzR4NGxolwnnq+9NEqeug==
X-Google-Smtp-Source: AGHT+IE9VvPbXowUlGMR0NuKfIyu5U90knTcEPj1g1FEgcr7KAnezv9SNTJDeYwSZ42tdjNExquWRQ==
X-Received: by 2002:a05:6000:389:b0:382:5aae:87c7 with SMTP id ffacd0b85a97d-388e4d7a897mr6913011f8f.31.1734598171005;
        Thu, 19 Dec 2024 00:49:31 -0800 (PST)
Message-ID: 
Date: Thu, 19 Dec 2024 09:49:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] misra: add deviation for MISRA C Rule R11.8.
To: Alessandro Zucchelli 
Cc: consulting@bugseng.com, Simone Ballarin ,
 Doug Goldstein , xen-devel@lists.xenproject.org,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: <7e4f836606d72769a80299c5451f6f7241471d8a.1734530952.git.alessandro.zucchelli@bugseng.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: <7e4f836606d72769a80299c5451f6f7241471d8a.1734530952.git.alessandro.zucchelli@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 18.12.2024 15:25, Alessandro Zucchelli wrote:
> Rule 11.8 states as following: "A cast shall not remove any `const' or
> `volatile' qualification from the type pointed to by a pointer".
> 
> Function `__hvm_copy' in `xen/arch/x86/hvm/hvm.c' is a double-use
> function, where the parameter needs to not be const because it can be
> set for write or not. As it was decided a new const-only function will
> lead to more developer confusion than it's worth, this violation is
> addressed by deviating the function.
> All cases of casting away const-ness are accompanied with a comment
> explaining why it is safe given the other flags passed in; such comment is used
> by the deviation in order to match the appropriate function call.
> 
> No functional change.
> 
> Signed-off-by: Alessandro Zucchelli 
> ---
> As this patch introduces a deviation for service MC3A2.R11.8, it
> depends on the following patch and shall not be applied prior to its
> application.
> https://lore.kernel.org/xen-devel/cf13be4779f15620e94b99b3b91f9cb040319989.1733826952.git.alessandro.zucchelli@bugseng.com/T/#u

This wasn't applicable anymore at the time you posted the patch, I suppose?

> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -393,6 +393,12 @@ Fixing this violation would require to increase code complexity and lower readab
>  -config=MC3R1.R11.8,reports+={safe,"any_area(any_loc(any_exp(macro(^container_of$))))"}
>  -doc_end
>  
> +-doc_begin="Function __hvm_copy in xen/arch/x86/hvm/hvm.c is a double-use
> +function, where the parameter needs to not be const because it can be set for
> +write or not"
> +-config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(text(^.*__hvm_copy.*HVMCOPY_to_guest doesn't modify.*$)))"}

This is probably good enough for now, yet still: It constrains re-formatting
that we may want to do on such function calls. Personally I'd consider it
entirely unexpected if I ended up (re)introducing a violation just by re-
formatting one of those function calls to

    return __hvm_copy(
               (void *)buf /* HVMCOPY_to_guest doesn't modify */,
               addr, size, current, HVMCOPY_to_guest | HVMCOPY_linear,
               PFEC_page_present | PFEC_write_access | pfec, pfinfo);

yet aiui the pattern above would have this effect (I don't think .* matches
newlines; instead I expect such regex-es to be applied to individual lines
only). Thoughts anyone?

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 08:58:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 08:58:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860912.1272886 (Exim 4.92)
	(envelope-from )
	id 1tOCMG-0003N3-8J; Thu, 19 Dec 2024 08:58:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860912.1272886; Thu, 19 Dec 2024 08:58: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 1tOCMG-0003Mw-56; Thu, 19 Dec 2024 08:58:12 +0000
Received: by outflank-mailman (input) for mailman id 860912;
 Thu, 19 Dec 2024 08:58: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 1tOCME-0003Mq-Na
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 08:58:11 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5e53c79a-bde7-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 09:58:09 +0100 (CET)
Received: from support.bugseng.com (support.bugseng.com [162.55.131.47])
 by support.bugseng.com (Postfix) with ESMTPA id 0498E4EE073E;
 Thu, 19 Dec 2024 09:58:07 +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: 5e53c79a-bde7-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1734598688; bh=DJWjUrAB1oGSVS7h+LROqv3bN/0cH+/2/vj2UzHtJr4=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=upSLlDEpdjTJ6bveO3TRM0s68huj6WVUcXzdimqadjMv/xdMNt5YxzQqdtQjLCmVu
	 ZC6cI2kRZvla4JuoFPpyQo4cKP4REO+1N6YzTV90LiUcmSg2uiAdWE4TOzxhrh8rbE
	 FMI1F7zcus2eOLugBuJpvR5L8dJ+DjWWdM/NZL63T+ROPwhov+JoiKRnhJajsUt1dk
	 RBi3c1isvUSaMC+o1M1u4svx0J0OxiSvAG3Ibgc3WzVcE+Ds21jqGhpeGEq+uRcULc
	 Zzm/XvCbhRkAxbkxplf8ubysrsbSwP0IpQc1vqggER12KCeLbxJdUmGvqltFvRkvR9
	 Ri+Rp7MU2Yusg==
MIME-Version: 1.0
Date: Thu, 19 Dec 2024 09:58:07 +0100
From: Nicola Vetrini 
To: Jan Beulich 
Cc: Alessandro Zucchelli ,
 consulting@bugseng.com, Simone Ballarin , Doug
 Goldstein , xen-devel@lists.xenproject.org, Andrew Cooper
 , Julien Grall , Stefano
 Stabellini , Anthony PERARD
 , Michal Orzel ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Subject: Re: [PATCH v2] misra: add deviation for MISRA C Rule R11.8.
In-Reply-To: 
References: <7e4f836606d72769a80299c5451f6f7241471d8a.1734530952.git.alessandro.zucchelli@bugseng.com>
 
Message-ID: <58439457588e585b08b48931e94754b2@bugseng.com>
X-Sender: nicola.vetrini@bugseng.com
Organization: BUGSENG s.r.l.
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit

On 2024-12-19 09:49, Jan Beulich wrote:
> On 18.12.2024 15:25, Alessandro Zucchelli wrote:
>> Rule 11.8 states as following: "A cast shall not remove any `const' or
>> `volatile' qualification from the type pointed to by a pointer".
>> 
>> Function `__hvm_copy' in `xen/arch/x86/hvm/hvm.c' is a double-use
>> function, where the parameter needs to not be const because it can be
>> set for write or not. As it was decided a new const-only function will
>> lead to more developer confusion than it's worth, this violation is
>> addressed by deviating the function.
>> All cases of casting away const-ness are accompanied with a comment
>> explaining why it is safe given the other flags passed in; such 
>> comment is used
>> by the deviation in order to match the appropriate function call.
>> 
>> No functional change.
>> 
>> Signed-off-by: Alessandro Zucchelli 
>> ---

>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> @@ -393,6 +393,12 @@ Fixing this violation would require to increase 
>> code complexity and lower readab
>>  
>> -config=MC3R1.R11.8,reports+={safe,"any_area(any_loc(any_exp(macro(^container_of$))))"}
>>  -doc_end
>> 
>> +-doc_begin="Function __hvm_copy in xen/arch/x86/hvm/hvm.c is a 
>> double-use
>> +function, where the parameter needs to not be const because it can be 
>> set for
>> +write or not"
>> +-config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(text(^.*__hvm_copy.*HVMCOPY_to_guest 
>> doesn't modify.*$)))"}
> 
> This is probably good enough for now, yet still: It constrains 
> re-formatting
> that we may want to do on such function calls. Personally I'd consider 
> it
> entirely unexpected if I ended up (re)introducing a violation just by 
> re-
> formatting one of those function calls to
> 
>     return __hvm_copy(
>                (void *)buf /* HVMCOPY_to_guest doesn't modify */,
>                addr, size, current, HVMCOPY_to_guest | HVMCOPY_linear,
>                PFEC_page_present | PFEC_write_access | pfec, pfinfo);
> 
> yet aiui the pattern above would have this effect (I don't think .* 
> matches
> newlines; instead I expect such regex-es to be applied to individual 
> lines
> only). Thoughts anyone?
> 

Hi Jan,

we can simply drop the "__hvm_copy" part from the regex. The regex can 
be made multiline, or alternatively we can apply the search to a range 
of lines. By default it searches on the same location mentioned by the 
report, which in this case is the line containing __hvm_copy (range 
defaults to 0..0). However I would leave it either as is or without the 
__hvm_copy prefix.

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 09:00:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 09:00:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860918.1272898 (Exim 4.92)
	(envelope-from )
	id 1tOCO6-0004lO-Ng; Thu, 19 Dec 2024 09:00:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860918.1272898; Thu, 19 Dec 2024 09:00:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOCO6-0004lH-I3; Thu, 19 Dec 2024 09:00:06 +0000
Received: by outflank-mailman (input) for mailman id 860918;
 Thu, 19 Dec 2024 09:00: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 1tOCO6-0004fz-01
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 09:00: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 a367b2d4-bde7-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 10:00:05 +0100 (CET)
Received: by mail-wm1-x32f.google.com with SMTP id
 5b1f17b1804b1-43635796b48so3283435e9.0
 for ; Thu, 19 Dec 2024 01:00: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
 ffacd0b85a97d-38a1c89e219sm1050713f8f.84.2024.12.19.01.00.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Dec 2024 01:00: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: a367b2d4-bde7-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734598804; x=1735203604; 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=kQiQUgyKCisRHAMfx9IO5/2Zroj9JsEB2aEdSBKqYTk=;
        b=UgbHGKZsDsFwB3aG6tEqWaCk+sBgg9FhX9fuURWf1cvqGt/TdQeYIMEOvVtCzPaQCC
         XgI76LtuYaqmD8zLMfKjCgZNMpvltfvFegSfCKg1NiZDhm4yC4+Gv+gzqATx/cwjsG+B
         fGjZ6xBDzSzIZd1q7Qer/eX3dMPe6XVDV1eoTqJrhhqKOVOLfOgtdcL8Z3CLlsSemN2n
         nRreuR5hyMtkmRRdFx7/mKV9Cg00ant/nqSNqWyytAqDO7IhK6e6MDeAB4Z+zHdToGGa
         wYWzXQBtqH3yb/yc0Uat+GpkAIzoEvUNdNZNG1kFyb9kFlycRefPGKYveekaDhQorqUi
         K8eA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734598804; x=1735203604;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=kQiQUgyKCisRHAMfx9IO5/2Zroj9JsEB2aEdSBKqYTk=;
        b=plK5fyZkKF10d3ZvM6Urf3/HO/enzV9b35fXkx1jFL17WdqhCvsHyw1pvsYmlzgZES
         jKJ+KStdESBjZflpVdfufuPilGrdXngW/MmwP782JsHQTn10HeFyHLrUKpTR2RlgoiBV
         lBzoQ9zd7njuJvuCOEf6Hz40Qi7P6KIdWH20bT46UYYFpMVR6WRHlHgPQlZBWCqGVOWc
         4kqvscb1k3o+emhmlIDDRjaNQfuFv3LW2+h1dh1LX//SHHhamI+ARUkimUClJkJesxgi
         J4KkkJ69wEuHKeWuSVAgiP2ED2zZZx2ctU3qOHQsc64uS48nUycsapsS4K+7uJfMFOt8
         hPjw==
X-Forwarded-Encrypted: i=1; AJvYcCWRuHqVQEihwJwzNPx8ky9D9HX0GuXzTvPLx5dm7ZvbP0VO/Hg24o1tROGtR/8LRUUR2zdBPWa0M64=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzsT56nCKMtAfP2OtxX2q966NITxzCVALZzuwgRL0THALU8U6Vc
	b7ed36RearOBOEqeDo7kA/O02rdApGhIxZjeVaZpkvfyGP4kbWQfyX1aAzUqQw==
X-Gm-Gg: ASbGncvNx251YrNB096giqR9ju5Kcz+mawlKpnlpN5fAbgwo+bQHKQsUE295cMgv/65
	hpDe+pu9gzcViHrpFryKHHzbTbvuGjsMB7Y7Xo8xqg0X37dG4ECONNiBvcNIU+SA/uInvQtnVJk
	Opt9avCRqEiOPQ3CYmqP2HqlMktyWNFwQRtrNHUNyTIrAsTU8DYAXaylByWUEMv/CBEuFQqlteG
	ZNG8JSlUV4p4tspljTvXmL7mCh9uCC8GVUE+b9sKe9VmkorX/XbOwcB7WotmU/f3/9neGyQnu8N
	mAXLav2o3bqc77DAw+iBLhpOQZyxUxVxQHIKngtIEw==
X-Google-Smtp-Source: AGHT+IHBv+07Nnp3XhzssPGS4IlJ2EGtp6wPyQ68swDninOyrBRb5Cqd19AhilpXVlYK1qnYpNTETg==
X-Received: by 2002:a05:600c:594f:b0:434:9e17:190c with SMTP id 5b1f17b1804b1-4365c53d8a7mr18233595e9.0.1734598804402;
        Thu, 19 Dec 2024 01:00:04 -0800 (PST)
Message-ID: 
Date: Thu, 19 Dec 2024 10:00:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] misra: add deviation for MISRA C Rule R11.8.
To: Nicola Vetrini 
Cc: Alessandro Zucchelli ,
 consulting@bugseng.com, Simone Ballarin ,
 Doug Goldstein , xen-devel@lists.xenproject.org,
 Andrew Cooper , Julien Grall ,
 Stefano Stabellini ,
 Anthony PERARD ,
 Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: <7e4f836606d72769a80299c5451f6f7241471d8a.1734530952.git.alessandro.zucchelli@bugseng.com>
 
 <58439457588e585b08b48931e94754b2@bugseng.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: <58439457588e585b08b48931e94754b2@bugseng.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.12.2024 09:58, Nicola Vetrini wrote:
> On 2024-12-19 09:49, Jan Beulich wrote:
>> On 18.12.2024 15:25, Alessandro Zucchelli wrote:
>>> Rule 11.8 states as following: "A cast shall not remove any `const' or
>>> `volatile' qualification from the type pointed to by a pointer".
>>>
>>> Function `__hvm_copy' in `xen/arch/x86/hvm/hvm.c' is a double-use
>>> function, where the parameter needs to not be const because it can be
>>> set for write or not. As it was decided a new const-only function will
>>> lead to more developer confusion than it's worth, this violation is
>>> addressed by deviating the function.
>>> All cases of casting away const-ness are accompanied with a comment
>>> explaining why it is safe given the other flags passed in; such 
>>> comment is used
>>> by the deviation in order to match the appropriate function call.
>>>
>>> No functional change.
>>>
>>> Signed-off-by: Alessandro Zucchelli 
>>> ---
> 
>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> @@ -393,6 +393,12 @@ Fixing this violation would require to increase 
>>> code complexity and lower readab
>>>  
>>> -config=MC3R1.R11.8,reports+={safe,"any_area(any_loc(any_exp(macro(^container_of$))))"}
>>>  -doc_end
>>>
>>> +-doc_begin="Function __hvm_copy in xen/arch/x86/hvm/hvm.c is a 
>>> double-use
>>> +function, where the parameter needs to not be const because it can be 
>>> set for
>>> +write or not"
>>> +-config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(text(^.*__hvm_copy.*HVMCOPY_to_guest 
>>> doesn't modify.*$)))"}
>>
>> This is probably good enough for now, yet still: It constrains 
>> re-formatting
>> that we may want to do on such function calls. Personally I'd consider 
>> it
>> entirely unexpected if I ended up (re)introducing a violation just by 
>> re-
>> formatting one of those function calls to
>>
>>     return __hvm_copy(
>>                (void *)buf /* HVMCOPY_to_guest doesn't modify */,
>>                addr, size, current, HVMCOPY_to_guest | HVMCOPY_linear,
>>                PFEC_page_present | PFEC_write_access | pfec, pfinfo);
>>
>> yet aiui the pattern above would have this effect (I don't think .* 
>> matches
>> newlines; instead I expect such regex-es to be applied to individual 
>> lines
>> only). Thoughts anyone?
> 
> we can simply drop the "__hvm_copy" part from the regex. The regex can 
> be made multiline, or alternatively we can apply the search to a range 
> of lines. By default it searches on the same location mentioned by the 
> report, which in this case is the line containing __hvm_copy (range 
> defaults to 0..0). However I would leave it either as is or without the 
> __hvm_copy prefix.

Omitting the __hvm_copy part would again widen it too much for my taste.

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 09:08:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 09:08:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860933.1272907 (Exim 4.92)
	(envelope-from )
	id 1tOCWF-0005yQ-C5; Thu, 19 Dec 2024 09:08:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860933.1272907; Thu, 19 Dec 2024 09: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 1tOCWF-0005yJ-95; Thu, 19 Dec 2024 09:08:31 +0000
Received: by outflank-mailman (input) for mailman id 860933;
 Thu, 19 Dec 2024 09:08:29 +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 1tOCWD-0005yC-Ts
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 09:08:29 +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 cedec0b4-bde8-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 10:08:27 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-436341f575fso5551735e9.1
 for ; Thu, 19 Dec 2024 01:08: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-38a1c832e1bsm1061010f8f.31.2024.12.19.01.08.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Dec 2024 01:08: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: cedec0b4-bde8-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734599307; x=1735204107; 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=mmpDynHtq8wSEdcCqCRwFVa1y5+fN3kXG9Thuv6Zy6c=;
        b=Rtgb54eqTwL1qPUWn9QsJpKmBvHrMwKT0QXDwl1ho3iSAWQY2aH2wB7jBXiErWY3a8
         aJZhAbQ1WbB/20VLlsj2pGVE4mGyYOfD3zTZ9lBQi+8XdnLd31sFrvZEr8kyG4twYsbT
         Ilz1iP+pldT15vaRWSHv1fvowp031ooXm5OAv1w1aLVJhD2gemKb8NsWtRxo7uMeIKwF
         BKp9vFjDcIwU+pQ9hliCmAQ6tjef8o/lkfzXYb7f3xC22R/dGfPT2j36vym9XOytVEu9
         Jrb6Y7sqB1xFT+Jxt+tWl5FMnYb+Z2PrR6C7BPnrwbUcro2EcuT+/zo+W9w06dpoxfKw
         ZysQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734599307; x=1735204107;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=mmpDynHtq8wSEdcCqCRwFVa1y5+fN3kXG9Thuv6Zy6c=;
        b=PfjaO53xNdP2tODmkFnf0US+9tGQ2D+tEvAg4adeH9InOKFXQbJVyB8zkKFIa/bzav
         fdhSi6iH+rWyoemj8nVK/5ZRyFSAncTyHusX5sKjKhyxMyL52FViRxfTNGO/9dxJ0bGH
         B69LK+Tkbmmr8kiJDABMnT02Ta9veD8GyaIbiLx1okH/CAj6w2hZ7VeQejdGsGVirAwA
         g6/ew5NEc4NrtxSu7DvZOFTGpHVsKF4218mACP+kdA+Xre5cKXVoOTwqY0QRe4mPrlCo
         VizIcGIE6SNXqVpsgQbPpU6P0G951qXYHKzn3xLBLlwC9q1F0QdC4zrxh7o4PloSYU4M
         U65Q==
X-Forwarded-Encrypted: i=1; AJvYcCUQMTjYTbscxGP43KMqX0ndYVY5dCBfeAh2CvuvUtQ/Ohs7mob9vQxLNVoBj9hed7cQZr9QkFV3Y7g=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywbgyqjs1cLhZkywrxIKMx/EJ+ihPRVLq547mBZ3Hlvzj5AcxF6
	jt3974KUc4c5NdhUAKxcVWPW1+PuRzzEemHYevfo8ob2WPOxLI9uNHm0zXGA4w==
X-Gm-Gg: ASbGnct2Hs3dSKYYXFuaVgTIfGr1ym9wQTlLq1Jqgk4QkgxReXBpv4enmdaXaguFL7A
	x91xI+iuY+I1zaVvv1nTjBnE5snqAdvvPGolj6QKews+IDUCSDdODScUN238epkXAy0Gk1rAP3H
	03BtJ7VZPyU/Dfa8xLGpEDe8ZjFH+821lFueLTaqnm6KRe4p6QS9nHljThAGiVp6nscb0tSWyY7
	w2t73owYbZ8EylPwolu80umD3oSaW6f+jwT80wri8VSg68n9aCh0oYKN3gzlSFfOwAErbiFBu0S
	Qkek7WH9w6HIYSra4PRZ6CaSa6i0GXYuQZV7IEk0hQ==
X-Google-Smtp-Source: AGHT+IHIMs6kFOPzRksTaOhdZzSTJem0Ayft/07Kd285Rak/Nl/3Ywh+++FZ7IuMu2FutsZ1wvyR8Q==
X-Received: by 2002:a05:600c:1396:b0:434:a04d:1670 with SMTP id 5b1f17b1804b1-4365c55467bmr24149875e9.0.1734599307354;
        Thu, 19 Dec 2024 01:08:27 -0800 (PST)
Message-ID: 
Date: Thu, 19 Dec 2024 10:08:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/7] xen/riscv: update layout table in config.h
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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 17.12.2024 17:32, Oleksii Kurochko wrote:
> Make all upper bounds (end addresses) for areas inclusive to align
> with the corresponding definitions.
> 
> For the Direct map region, the upper bound was calculated incorrectly
> in efadb18dd58aba ("xen/riscv: add VM space layout"). It should be
> 0x7f80000000 (considering that the value is exclusive, instead of
> 0x7f40000000). Therefore, the inclusive upper bound for that region
> is 0x7f80000000 - 1.
> 
> Signed-off-by: Oleksii Kurochko 

Acked-by: Jan Beulich 




From xen-devel-bounces@lists.xenproject.org Thu Dec 19 09:10:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 09:10:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860939.1272917 (Exim 4.92)
	(envelope-from )
	id 1tOCXr-0007OP-LZ; Thu, 19 Dec 2024 09:10:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860939.1272917; Thu, 19 Dec 2024 09:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOCXr-0007OI-Ib; Thu, 19 Dec 2024 09:10:11 +0000
Received: by outflank-mailman (input) for mailman id 860939;
 Thu, 19 Dec 2024 09: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 1tOCXp-0007OA-ST
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 09:10:10 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 09f126c0-bde9-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 10:10:06 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 19 Dec 2024 10:10:07 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 09f126c0-bde9-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734599408; x=1766135408;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=bcH/ou5dglDfWbz9SgVwVxCz/5k2/XegF0leE85H0TE=;
  b=Dizn+17NyZHqHOS95QtFOBiOOOM58bzPZjpkOlngyAQHXudKeYsyoBAz
   4/Y2areEQ06d51J1/4+K2VDQ0V3R2raaq8GuTGYY/P4ew3Dd131iGx5dO
   8Qwgc9wP/B5NwhQBdV0X0XrhsA2rPYuaJwNePUqhZ4JxvhA2sZ98Bc9Hj
   E=;
X-CSE-ConnectionGUID: OyZOjpwbSnWkPF4aIXDGaA==
X-CSE-MsgGUID: 9flVPe7XSu6D0ht+ggr3cg==
X-IronPort-AV: E=Sophos;i="6.12,247,1728943200"; 
   d="scan'208";a="28251535"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: <7587b503-b2ca-4476-8dc9-e9683d4ca5f0@suse.com>
Content-Type: text/plain; charset="utf-8"
X-Forward: 88.183.119.157
References: <20241218233659.573195-2-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241218233659.573195-3-Ariel.Otilibili-Anieli@eurecom.fr> <7587b503-b2ca-4476-8dc9-e9683d4ca5f0@suse.com>
Date: Thu, 19 Dec 2024 10:10:06 +0100
Cc: "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Stefano Stabellini" , xen-devel@lists.xenproject.org
To: "Jan Beulich" 
MIME-Version: 1.0
Message-ID: <2f7a84-6763e300-4ca3-4ac1e700@170330858>
Subject: =?utf-8?q?Re=3A?= [PATCH 1/1] =?utf-8?q?xen/common=3A?= Remove dead code
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 1237

On Thursday, December 19, 2024 09:32 CET, Jan Beulich  wrote:

> On 19.12.2024 00:34, Ariel Otilibili wrote:
> > The if-statement tests `res` is non-zero; meaning the case zero is =
never reached.
> >=20
> > Coverity-ID: 1055253
> > Fixes: e2b1ebf4de ("x86: Support booting a bzImage format domain 0 =
kernel.")
> > Signed-off-by: Ariel Otilibili 
>=20
> I certainly agree with the change, especially if Coverity complains a=
bout it.
> In fact I'd expect Eclair to complain too, for this being unreachable=
 or dead
> code (I'm never sure which one's which in their nomenclature). The Mi=
sra
> violation addressed may therefore want mentioning, too.

I didn't know Eclair and Miscra could send warnings. Are they commands =
available for that?
>=20
> However, the commit referenced says "xen/common/inflate.c is taken un=
modified
> from Linux v2.6.28." Therefore the preferred approach would be to cor=
rect the
> original first, then pull in that patch to our tree. (And yes, the co=
de is
> still as was even in 6.13-rc3.)

So old a commit...

This approach makes sense, Jan; thanks for the feedback. I am sending t=
he patch to Linux.

And will keep you posted.
>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 09:16:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 09:16:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860952.1272935 (Exim 4.92)
	(envelope-from )
	id 1tOCdi-00009U-A5; Thu, 19 Dec 2024 09:16:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860952.1272935; Thu, 19 Dec 2024 09:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOCdi-00009N-78; Thu, 19 Dec 2024 09:16:14 +0000
Received: by outflank-mailman (input) for mailman id 860952;
 Thu, 19 Dec 2024 09:16: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 1tOCdg-00009H-G1
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 09:16:12 +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 e260c305-bde9-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 10:16:09 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-4361f796586so5511905e9.3
 for ; Thu, 19 Dec 2024 01:16:10 -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-38a1c847d7fsm1075441f8f.60.2024.12.19.01.16.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Dec 2024 01:16:09 -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: e260c305-bde9-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734599770; x=1735204570; 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=x8PtJheKGAJizy16xwiXTRbPJkfpd5ZfDqrbmGqCMc0=;
        b=EhJs8zrUFtfqGHL8yzEPS3Gncg3nYJ0s74Wz8xedCI/h+1Iyqn4PDKL57Z/hC+y7ws
         ZQr7HvlKwVNpCGdwSp6E8AhK8cl1LEXwTZuSR+q2cqC0r7gVKDvwF/AzEUz4Puma0Z1W
         LUpYBDCJEP5+pZf91OeeAKH1vprsXYsXPonNmEJwZv01SlgI2n5tocSC0pBoTxUNHZEn
         V6YdnCWRxC9QPXpo5ql+saMGCP5drMcWuwjRs2fIt36dqONtcgk31ZKqvtOHqJyzT3VZ
         lMRryAalchBjXP1awHP70G7RW5C7cSrvog/uqjHDr2kiPAtxVMxYySnTSlaWTlOmFSXU
         pAjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734599770; x=1735204570;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=x8PtJheKGAJizy16xwiXTRbPJkfpd5ZfDqrbmGqCMc0=;
        b=MF0Isuw4vyWgxrejTJQHXVrdoxt4JdY7HiqmuVDWep2COQdQL5Von3Y1iPlLkoBmQ0
         SgDy5vNSTc4aZy6M6UhEWF2VIQWUiVENn5jM2LZYfsS/JOFHB0NbMKJ76jeHogFRruFj
         qokBthDeGF1KQDIZkYdAPlkxXYDmWfu/XPG7Op2MmXnDuCyb5rqycIzmvtoOvM7lqS6S
         jaxYQrge4NHp+MTdjh9sRKX7evcFJVl654tjDIdedQkfdGYeqrPFy5hjsGC3UWVM7fCB
         03pwVUj4mUsFB2li58hM//Xtt7C3BnIaxWv2X49C66UPoR5Kyd5Wa3RJgE+cXICB5upF
         r7Og==
X-Forwarded-Encrypted: i=1; AJvYcCXsesnGOm8nyiCzvmrETFLD8FHxMGr8kCPW191CU/r6hPtwEG7kCuWGFyuZQzUiZIHT7dTrSUN1vks=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yys0jbm+9hBiKlM6DiDN+zPSAoRTXL46CKkxDcaY+MNHCMnu+U3
	SsYsiOSEsllHRl0VFwxME/KiTTextEj07ZqGNBGPcj7NatM5M4vP34af5HvB7g==
X-Gm-Gg: ASbGncvLQDx+KjtV+TmR0F2PXLqpdRsePSH1A2RgWhCSbKYqD3X9SMV4WDIKd5Ei/fB
	CIpNs2+NA9aMyiaUu9vuRp69PIRFDmG69a/NJtWr3kZmIwWG80/tR30dMNp9FLHJjh5hUkpmwgi
	sGVLwSwFvYtJe8LAbr8y5Tc7FBxUbh3RQ4BUu62BQnV9+PaKm7LLCZCxevj2o5tYQqxG5WTgmdv
	ODLnvOSSipNxFYWXNdIBKUHHxQ3RXDBbE+h2V/w2b9qyiiXCkGi3Oot5a373t45XkyidrpjMdKr
	5fyCQ2Hw0aa4tHwYeOafNgCQK62zp7NiG3qy/Z2j5g==
X-Google-Smtp-Source: AGHT+IFsirENDebIbdN+I0i90wNlh/UMOmm61p8TGFwzbDJ906klijr9PMAUnpxGGGD3sZJgPuoHrg==
X-Received: by 2002:a5d:64ee:0:b0:385:e2d5:cdf2 with SMTP id ffacd0b85a97d-38a19b05162mr2410144f8f.19.1734599769839;
        Thu, 19 Dec 2024 01:16:09 -0800 (PST)
Message-ID: 
Date: Thu, 19 Dec 2024 10:16:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 5/7] xen/riscv: implement data and instruction cache
 operations
To: Oleksii Kurochko 
Cc: Alistair Francis ,
 Bob Eshleman , 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: 
 <33cf536f15356db894be5bde557060585cc2e410.1734452721.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: <33cf536f15356db894be5bde557060585cc2e410.1734452721.git.oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 17.12.2024 17:32, Oleksii Kurochko wrote:
> Implement following cache operations:
> - clean_and_invalidate_dcache_va_range()
> - clean_dcache_va_range()
> - invalidate_icache()
> 
> The first two functions may require support for the CMO (Cache Management
> Operations) extension and/or hardware-specific instructions.
> Currently, only QEMU is supported, which does not model cache behavior.
> Therefore, clean_and_invalidate_dcache_va_range() and clean_dcache_va_range()
> are implemented to simply return 0. For other cases, generate compilation error
> so a user won't miss to update this function if necessery.
> If hardware supports CMO or hardware-specific instructions, these functions
> should be updated accordingly. To support current implementation of these
> function CONFIG_QEMU_PLATFORM is introduced.
> 
> invalidate_icache() is implemented using fence.i instruction as
> mentioned in the unpriv spec:
>   The FENCE.I instruction was designed to support a wide variety of
>   implementations. A simple implementation can flush the local instruction
>   cache and the instruction pipeline when the FENCE.I is executed.
>   A more complex implementation might snoop the instruction (data) cache
>   on every data (instruction) cache miss, or use an inclusive unified
>   private L2 cache to invalidate lines from the primary instruction cache
>   when they are being written by a local store instruction.
>   If instruction and data caches are kept coherent in this way, or if the
>   memory system consists of only uncached RAMs, then just the fetch pipeline
>   needs to be flushed at a FENCE.I.
> The FENCE.I instruction requires the presence of the Zifencei extension,
> which might not always be available. However, Xen uses the RV64G ISA, which
> guarantees the presence of the Zifencei extension. According to the
> unprivileged ISA specification (version 20240411):
>   One goal of the RISC-V project is that it be used as a stable software
>   development target. For this purpose, we define a combination of a base ISA
>   (RV32I or RV64I) plus selected standard extensions (IMAFD, Zicsr, Zifencei)
>   as a "general-purpose" ISA, and we use the abbreviation G for the
>   IMAFDZicsr_Zifencei combination of instruction-set extensions.
> 
> Set CONFIG_QEMU_PLATFORM=y in tiny64_defconfig to have proper implemtation of
> clean_and_invalidate_dcache_va_range() and clean_dcache_va_range() for CI.
> 
> Signed-off-by: Oleksii Kurochko 

I'm not entirely happy with this (and where it appears to be moving us), but
for the time being it's perhaps good enough, so
Acked-by: Jan Beulich 
Albeit with ...

> @@ -148,9 +149,28 @@ static inline bool pte_is_mapping(pte_t p)
>      return (p.pte & PTE_VALID) && (p.pte & PTE_ACCESS_MASK);
>  }
>  
> +static inline int clean_and_invalidate_dcache_va_range(const void *p,
> +                                                       unsigned long size)
> +{
> +#ifndef CONFIG_QEMU_PLATFORM
> +    #error "should clean_and_invalidate_dcache_va_range() be updated?"
> +#endif
> +
> +    return 0;
> +}
> +
> +static inline int clean_dcache_va_range(const void *p, unsigned long size)
> +{
> +#ifndef CONFIG_QEMU_PLATFORM
> +    #error "should clean_dcache_va_range() be updated?"
> +#endif
> +
> +    return 0;
> +}

... the #-es moved back to the 1st column, which I'll take the liberty of
doing while committing. Personally I wonder anyway why these aren't simply
BUILD_BUG_ON("unimplemented").

Jan



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 09:26:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 09:26:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860965.1272944 (Exim 4.92)
	(envelope-from )
	id 1tOCnt-0002L4-9d; Thu, 19 Dec 2024 09:26:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860965.1272944; Thu, 19 Dec 2024 09:26: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 1tOCnt-0002Kx-6T; Thu, 19 Dec 2024 09:26:45 +0000
Received: by outflank-mailman (input) for mailman id 860965;
 Thu, 19 Dec 2024 09:26: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 1tOCnr-0002Kr-7r
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 09:26:43 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 5b0ade88-bdeb-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 10:26:41 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 19 Dec 2024 10:26:41 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id 8C2852260;
 Thu, 19 Dec 2024 10:26:40 +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: 5b0ade88-bdeb-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734600402; x=1766136402;
  h=from:to:cc:subject:date:message-id:mime-version:
   content-transfer-encoding;
  bh=DxnzFmAuYsk81Rt5/vcHL2fXrilMEjK+UHr4qOKdwJg=;
  b=GgB2rqIvnbYZrDFHGegSE9OSghVdcp8ywR3cUL5GWrw1rXkh+Jnrr7Qa
   DhAe+63bDA8YwBWL1rWkIHEqJx0t1gJI+Y4OsF4vMJKa8Zlozf71hkdgp
   piNDay5kSIUGRbH9LGFVo+UWKjQOUw5jigat/C2/e/d48Qr0w6jXHTL6s
   4=;
X-CSE-ConnectionGUID: Zrg74N3NQ5KzGXDKrfriHA==
X-CSE-MsgGUID: TwDNy/uAQFqKGWAwhYEXZA==
X-IronPort-AV: E=Sophos;i="6.12,247,1728943200"; 
   d="scan'208";a="28251760"
From: Ariel Otilibili 
To: linux-kernel@vger.kernel.org
Cc: Ariel Otilibili ,
	Jan Beulich ,
	Andrew Morton ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?utf-8?q?Roger_Pau_Monn=C3=A9?= ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: [PATCH 0/1] lib: Remove dead code
Date: Thu, 19 Dec 2024 10:21:11 +0100
Message-ID: <20241219092615.644642-1-ariel.otilibili-anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hello,

This patch removes a dead code in lib/inflate.c; it follows from a discussion
in Xen.

The dead code is tracked by Coverity-ID 1055253 in Xen, was triggered by a file
taken unmodified from Linux.

Thank you,

Link: https://lore.kernel.org/all/7587b503-b2ca-4476-8dc9-e9683d4ca5f0@suse.com/

Ariel Otilibili (1):
  lib: Remove dead code

 lib/inflate.c | 2 --
 1 file changed, 2 deletions(-)

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 09:26:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 09:26:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860967.1272955 (Exim 4.92)
	(envelope-from )
	id 1tOCo6-0002cq-GM; Thu, 19 Dec 2024 09:26:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860967.1272955; Thu, 19 Dec 2024 09:26: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 1tOCo6-0002cj-Dl; Thu, 19 Dec 2024 09:26:58 +0000
Received: by outflank-mailman (input) for mailman id 860967;
 Thu, 19 Dec 2024 09:26: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 1tOCo5-0002Kr-JV
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 09:26:57 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 640e82b2-bdeb-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 10:26:56 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 19 Dec 2024 10:26:56 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id 040812261;
 Thu, 19 Dec 2024 10:26:55 +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: 640e82b2-bdeb-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734600417; x=1766136417;
  h=from:to:cc:subject:date:message-id:in-reply-to:
   references:mime-version:content-transfer-encoding;
  bh=2jNfMnSExzRCR4OB6itmTxmQqOry4/XL6zAEczHX97Y=;
  b=z0UujdVwDUvYch3lUOVw7F9d7UdwecwMtyHLw8DlhF7oEuIWu3DzeLms
   Oi0vfdyZYZ6TVJWHluTvndPa/L6qTRGoBfbcXL6UNT1gfl/MZffuo6L8Z
   OE1bXgBl/LDiH9QTMSYu778SHkWqbFCfpxDEe+5wIsR6OSfTo8b18QrNw
   c=;
X-CSE-ConnectionGUID: Inrs7WZ5SRi1wMWtl0LWkw==
X-CSE-MsgGUID: YJsDCe/SSh2uhrdXU3LRWQ==
X-IronPort-AV: E=Sophos;i="6.12,247,1728943200"; 
   d="scan'208";a="28251766"
From: Ariel Otilibili 
To: linux-kernel@vger.kernel.org
Cc: Ariel Otilibili ,
	Jan Beulich ,
	Andrew Morton ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?utf-8?q?Roger_Pau_Monn=C3=A9?= ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: [PATCH 1/1] lib: Remove dead code
Date: Thu, 19 Dec 2024 10:21:12 +0100
Message-ID: <20241219092615.644642-2-ariel.otilibili-anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20241219092615.644642-1-ariel.otilibili-anieli@eurecom.fr>
References: <20241219092615.644642-1-ariel.otilibili-anieli@eurecom.fr>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This is a follow up from a discussion in Xen:

The if-statement tests `res` is non-zero; meaning the case zero is never reached.

Link: https://lore.kernel.org/all/7587b503-b2ca-4476-8dc9-e9683d4ca5f0@suse.com/
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Suggested-by: Jan Beulich 
Signed-off-by: Ariel Otilibili 
--
Cc: Andrew Morton 
Cc: linux-kernel@vger.kernel.org
Cc: Andrew Cooper 
Cc: Anthony PERARD 
Cc: Michal Orzel 
Cc: Julien Grall 
Cc: =?utf-8?q?Roger_Pau_Monn=C3=A9?= 
Cc: Stefano Stabellini 
Cc: xen-devel@lists.xenproject.org
---
 lib/inflate.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/lib/inflate.c b/lib/inflate.c
index fbaf03c1748d..eab886baa1b4 100644
--- a/lib/inflate.c
+++ b/lib/inflate.c
@@ -1257,8 +1257,6 @@ static int INIT gunzip(void)
     /* Decompress */
     if ((res = inflate())) {
 	    switch (res) {
-	    case 0:
-		    break;
 	    case 1:
 		    error("invalid compressed format (err=1)");
 		    break;
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 09:29:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 09:29:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860979.1272964 (Exim 4.92)
	(envelope-from )
	id 1tOCqX-0003Q3-SY; Thu, 19 Dec 2024 09:29:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860979.1272964; Thu, 19 Dec 2024 09:29:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOCqX-0003Pw-Pr; Thu, 19 Dec 2024 09:29:29 +0000
Received: by outflank-mailman (input) for mailman id 860979;
 Thu, 19 Dec 2024 09: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 1tOCqW-0003Pq-6J
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 09:29:28 +0000
Received: from fforwardh-b4-smtp.messagingengine.com
 (fforwardh-b4-smtp.messagingengine.com [202.12.124.199])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bc7e070e-bdeb-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 10:29:26 +0100 (CET)
Received: from phl-compute-12.internal (phl-compute-12.phl.internal
 [10.202.2.52])
 by mailfforwardh.stl.internal (Postfix) with ESMTP id 1D9F01740301;
 Thu, 19 Dec 2024 04:29:24 -0500 (EST)
Received: from phl-frontend-01 ([10.202.2.160])
 by phl-compute-12.internal (MEProxy); Thu, 19 Dec 2024 04:29:24 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 19 Dec 2024 04:29:21 -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: bc7e070e-bdeb-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	: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=
	1734600563; x=1734686963; bh=nwmFgHahWexYFtoXDT8R32Ftn+nEypCwNBT
	ku56z0Cc=; b=0rFQl3hCaNN/FuTn4lhg69FpDetyHem/vngkor/RR0zYxN31VGu
	3JKdtYdHlJMhHgLM0EimFfq3MZU536Tmd5Y/h+4pPTzSmi4HM5HyYZfDD1SSqf4o
	dBx1iK4fO5uhBlaXpOY+Sak3/sQOLxQzZpibGyK8KY0l+L2VvsjF1cAqFfAGo6bR
	oVBTzZ2YujqaO1UPE/smyvzB4kw/mjHgfVJWBKgVMSd9eZjrm3ze9Wk3fTS/sqLT
	UEphrYhSNg/TqLpsApz6WY/KfB+TW/ebVYKYuxVWUvbqnTwaMn04jAmIDscnOEgg
	RlLAvp/7Je9a2eFNmutwXFWqdWDkVnCzy1Q==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddruddttddgtdefucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhephffvvefufffkofgggfestdekredtredttdenucfh
    rhhomhepufgvrhhgihihucfmihgsrhhikhcuoefuvghrghhihigpmfhisghrihhksegvph
    grmhdrtghomheqnecuggftrfgrthhtvghrnhepgedvfeefhfduvdetkeegleeggfelheek
    veeiuddufeehtdehleelhfekiedvvedvnecuffhomhgrihhnpehkvghrnhgvlhdrohhrgh
    enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsrghk
    ihgssegurghrkhhsthgrrhdrshhithgvpdhnsggprhgtphhtthhopeduvddpmhhouggvpe
    hsmhhtphhouhhtpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhp
    rhhojhgvtghtrdhorhhgpdhrtghpthhtohepshhtvghfrghnohdrshhtrggsvghllhhinh
    hisegrmhgurdgtohhmpdhrtghpthhtohepjhhulhhivghnseigvghnrdhorhhgpdhrtghp
    thhtohepsggvrhhtrhgrnhgurdhmrghrqhhuihhssegrrhhmrdgtohhmpdhrtghpthhtoh
    epmhhitghhrghlrdhorhiivghlsegrmhgurdgtohhmpdhrtghpthhtohepvhholhhougih
    mhihrhgpsggrsggthhhukhesvghprghmrdgtohhmpdhrtghpthhtoheprghnthhhohhnhi
    drphgvrhgrrhgusehvrghtvghsrdhtvggthhdprhgtphhtthhopehrohhgvghrrdhprghu
    segtihhtrhhigidrtghomhdprhgtphhtthhopehsshhtrggsvghllhhinhhisehkvghrnh
    gvlhdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: idddb55c8:Fastmail
From: Sergiy Kibrik 
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Anthony PERARD ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Sergiy Kibrik ,
	Andrew Cooper ,
	Jan Beulich 
Subject: [XEN PATCH v2] xen: introduce kconfig options to disable hypercalls
Date: Thu, 19 Dec 2024 11:29:17 +0200
Message-Id: <20241219092917.3006174-1-Sergiy_Kibrik@epam.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Stefano Stabellini 

It can be beneficial for some dom0less systems to further reduce Xen footprint
and disable some hypercalls handling code, which may not to be used & required
in such systems. Each hypercall has a separate option to keep configuration
flexible.

Options to disable hypercalls:
- domctl, sysctl
- hvm
- physdev
- platform

Some of these options are forced to be configurable only when DOM0LESS is
enabled, so that system won't become accidentally un-bootable when any hypercall
is disabled.
domctl/sysctl/platform hypercalls also disabled by PV_SHIM_EXCLUSIVE config
option, so this is reflected by a dependency in kconfig and Makefiles are
changed accordingly.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Sergiy Kibrik 
CC: Andrew Cooper 
CC: Jan Beulich 
---
changes in v2:
 - SYSCTL & DOMCTL config option dependency on !PV_SHIM_EXCLUSIVE
 - replace build checks for CONFIG_PV_SHIM_EXCLUSIVE
 - rename options PLATFORM_HYP -> PLATFORM_OP & PHYSDEV -> PHYSDEV_OP
 - removed "arm" from subj, as patch becomes not really ARM-specific
 - updated description

changes in v1:
 - incorporated PV_SHIM_EXCLUSIVE check in Kconfig
 - drop excessive ifeq from Makefile & #ifdef from code
 - drop checks for CONFIG_HVM_OP & CONFIG_PLATFORM_HYP being off when !DOM0LESS
 - description updated

v1 patch here: https://lore.kernel.org/xen-devel/20241216114358.2845447-1-Sergiy_Kibrik@epam.com/
---
 xen/arch/arm/Makefile        | 10 +++++-----
 xen/arch/x86/Makefile        |  6 +++---
 xen/common/Kconfig           | 29 +++++++++++++++++++++++++++++
 xen/common/Makefile          |  4 ++--
 xen/include/hypercall-defs.c | 24 +++++++++++++++++-------
 xen/include/xen/domain.h     |  2 +-
 6 files changed, 57 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index e4ad1ce851..265498fdd2 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_IOREQ_SERVER) += dm.o
 obj-$(CONFIG_DOM0LESS_BOOT) += dom0less-build.init.o
 obj-y += domain.o
 obj-y += domain_build.init.o
-obj-y += domctl.o
+obj-$(CONFIG_DOMCTL) += domctl.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 obj-y += efi/
 obj-y += gic.o
@@ -29,7 +29,7 @@ obj-$(CONFIG_HAS_ITS) += gic-v3-lpi.o
 obj-y += guestcopy.o
 obj-y += guest_atomics.o
 obj-y += guest_walk.o
-obj-y += hvm.o
+obj-$(CONFIG_HVM_OP) += hvm.o
 obj-y += io.o
 obj-$(CONFIG_IOREQ_SERVER) += ioreq.o
 obj-y += irq.o
@@ -40,8 +40,8 @@ obj-y += mm.o
 obj-y += monitor.o
 obj-y += p2m.o
 obj-y += platform.o
-obj-y += platform_hypercall.o
-obj-y += physdev.o
+obj-$(CONFIG_PLATFORM_OP) += platform_hypercall.o
+obj-$(CONFIG_PHYSDEV_OP) += physdev.o
 obj-y += processor.o
 obj-y += psci.o
 obj-y += setup.o
@@ -51,7 +51,7 @@ obj-y += smpboot.o
 obj-$(CONFIG_STATIC_EVTCHN) += static-evtchn.init.o
 obj-$(CONFIG_STATIC_MEMORY) += static-memory.init.o
 obj-$(CONFIG_STATIC_SHM) += static-shmem.init.o
-obj-y += sysctl.o
+obj-$(CONFIG_SYSCTL) += sysctl.o
 obj-y += time.o
 obj-y += traps.o
 obj-y += vcpreg.o
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index b35fd5196c..f623bddb1d 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -74,12 +74,12 @@ obj-y += hpet.o
 obj-y += vm_event.o
 obj-y += xstate.o
 
-ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
-obj-y += domctl.o
+obj-$(CONFIG_DOMCTL) += domctl.o
+ifeq ($(CONFIG_PLATFORM_OP),y)
 obj-y += platform_hypercall.o
 obj-$(CONFIG_COMPAT) += x86_64/platform_hypercall.o
-obj-y += sysctl.o
 endif
+obj-$(CONFIG_SYSCTL) += sysctl.o
 
 extra-y += asm-macros.i
 extra-y += xen.lds
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 90268d9249..fd5f54356f 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -516,4 +516,33 @@ config TRACEBUFFER
 	  to be collected at run time for debugging or performance analysis.
 	  Memory and execution overhead when not active is minimal.
 
+menu "Supported hypercall interfaces"
+	visible if DOM0LESS_BOOT && EXPERT
+
+config SYSCTL
+	bool "Enable sysctl hypercall"
+	depends on !PV_SHIM_EXCLUSIVE
+	default y
+
+config DOMCTL
+	bool "Enable domctl hypercalls"
+	depends on !PV_SHIM_EXCLUSIVE
+	default y
+
+config HVM_OP
+	bool "Enable HVM hypercalls"
+	depends on HVM
+	default y
+
+config PLATFORM_OP
+	bool "Enable platform hypercalls"
+	depends on !PV_SHIM_EXCLUSIVE
+	default y
+
+config PHYSDEV_OP
+	bool "Enable physdev hypercall"
+	default y
+
+endmenu
+
 endmenu
diff --git a/xen/common/Makefile b/xen/common/Makefile
index b279b09bfb..0893bed6ab 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -66,10 +66,10 @@ obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo un
 obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o)
 
 ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
-obj-y += domctl.o
 obj-y += monitor.o
-obj-y += sysctl.o
 endif
+obj-$(CONFIG_DOMCTL) += domctl.o
+obj-$(CONFIG_SYSCTL) += sysctl.o
 
 extra-y := symbols-dummy.o
 
diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c
index 7720a29ade..e4872e7e28 100644
--- a/xen/include/hypercall-defs.c
+++ b/xen/include/hypercall-defs.c
@@ -95,7 +95,7 @@ handle: const_char const char
 
 #ifdef CONFIG_COMPAT
 defhandle: multicall_entry_compat_t
-#ifndef CONFIG_PV_SHIM_EXCLUSIVE
+#ifdef CONFIG_PLATFORM_OP
 defhandle: compat_platform_op_t
 #endif
 #endif
@@ -150,7 +150,7 @@ update_va_mapping(unsigned int va, uint32_t lo, uint32_t hi, unsigned int flags)
 physdev_op_compat(physdev_op_compat_t *uop)
 update_va_mapping_otherdomain(unsigned int va, uint32_t lo, uint32_t hi, unsigned int flags, domid_t domid)
 #endif
-#ifndef CONFIG_PV_SHIM_EXCLUSIVE
+#ifdef CONFIG_PLATFORM_OP
 platform_op(compat_platform_op_t *u_xenpf_op)
 #endif
 #ifdef CONFIG_KEXEC
@@ -194,10 +194,14 @@ kexec_op(unsigned long op, void *uarg)
 #ifdef CONFIG_IOREQ_SERVER
 dm_op(domid_t domid, unsigned int nr_bufs, xen_dm_op_buf_t *bufs)
 #endif
-#ifndef CONFIG_PV_SHIM_EXCLUSIVE
+#ifdef CONFIG_SYSCTL
 sysctl(xen_sysctl_t *u_sysctl)
+#endif
+#ifdef CONFIG_DOMCTL
 domctl(xen_domctl_t *u_domctl)
 paging_domctl_cont(xen_domctl_t *u_domctl)
+#endif
+#ifdef CONFIG_PLATFORM_OP
 platform_op(xen_platform_op_t *u_xenpf_op)
 #endif
 #ifdef CONFIG_HVM
@@ -234,7 +238,7 @@ stack_switch                       do:2     do:2     -        -        -
 set_callbacks                      compat   do       -        -        -
 fpu_taskswitch                     do       do       -        -        -
 sched_op_compat                    do       do       -        -        dep
-#ifndef CONFIG_PV_SHIM_EXCLUSIVE
+#ifdef CONFIG_PLATFORM_OP
 platform_op                        compat   do       compat   do       do
 #endif
 set_debugreg                       do       do       -        -        -
@@ -247,7 +251,9 @@ set_timer_op                       compat   do       compat   do       -
 event_channel_op_compat            do       do       -        -        dep
 xen_version                        do       do       do       do       do
 console_io                         do       do       do       do       do
+#ifdef CONFIG_PHYSDEV_OP
 physdev_op_compat                  compat   do       -        -        dep
+#endif
 #if defined(CONFIG_GRANT_TABLE)
 grant_table_op                     compat   do       hvm      hvm      do
 #elif defined(CONFIG_PV_SHIM)
@@ -269,12 +275,16 @@ callback_op                        compat   do       -        -        -
 xenoprof_op                        compat   do       -        -        -
 #endif
 event_channel_op                   do       do       do:1     do:1     do:1
+#ifdef CONFIG_PHYSDEV_OP
 physdev_op                         compat   do       hvm      hvm      do_arm
-#ifdef CONFIG_HVM
+#endif
+#ifdef CONFIG_HVM_OP
 hvm_op                             do       do       do       do       do
 #endif
-#ifndef CONFIG_PV_SHIM_EXCLUSIVE
+#ifdef CONFIG_SYSCTL
 sysctl                             do       do       do       do       do
+#endif
+#ifdef CONFIG_DOMCTL
 domctl                             do       do       do       do       do
 #endif
 #ifdef CONFIG_KEXEC
@@ -292,7 +302,7 @@ dm_op                              compat   do       compat   do       do
 hypfs_op                           do       do       do       do       do
 #endif
 mca                                do       do       -        -        -
-#ifndef CONFIG_PV_SHIM_EXCLUSIVE
+#ifdef CONFIG_DOMCTL
 paging_domctl_cont                 do       do       do       do       -
 #endif
 
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 3de5635291..62b5d70a8a 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -161,7 +161,7 @@ struct vnuma_info {
     struct xen_vmemrange *vmemrange;
 };
 
-#ifndef CONFIG_PV_SHIM_EXCLUSIVE
+#ifdef CONFIG_DOMCTL
 void vnuma_destroy(struct vnuma_info *vnuma);
 #else
 static inline void vnuma_destroy(struct vnuma_info *vnuma) { ASSERT(!vnuma); }
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 09:39:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 09:39:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.860997.1272991 (Exim 4.92)
	(envelope-from )
	id 1tOD0M-0005hd-Va; Thu, 19 Dec 2024 09:39:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 860997.1272991; Thu, 19 Dec 2024 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 1tOD0M-0005hW-Rh; Thu, 19 Dec 2024 09:39:38 +0000
Received: by outflank-mailman (input) for mailman id 860997;
 Thu, 19 Dec 2024 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 1tOD0L-0005hQ-N8
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 09:39:37 +0000
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com
 [2a00:1450:4864:20::232])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 290bcac8-bded-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 10:39:36 +0100 (CET)
Received: by mail-lj1-x232.google.com with SMTP id
 38308e7fff4ca-30167f4c1deso6030051fa.1
 for ; Thu, 19 Dec 2024 01:39:36 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 38308e7fff4ca-3045b069de9sm1529201fa.78.2024.12.19.01.39.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Dec 2024 01:39: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: 290bcac8-bded-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734601176; x=1735205976; darn=lists.xenproject.org;
        h=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=1ew31f6DRFQAGT7nqGDKV8ogEvncpT8YkZ4hjyU/ItI=;
        b=SO+I13jKM9XGfjml0C6brXHsmBWeJjFIVBszCqpa289639kPb5/ZjNe1NZdjqmHFUq
         gRgkEn0+S1mGWjnmJ3BQzjQnJLH4P3/ni+0zfjIWyMX8eS+8AnqkiYxS/fxoazpLP3aw
         8sUPJ8SY7L7E74TD+bKdTcC6EhMc/HfifvE8BV3f4goUyPF1zhvou8E/uDgPewRrNoa5
         wJvfhStCH/RIyLZxi4b9uzQeQH41DsTBXpVfcBz4GvMNaAxV0XPtPts62m2kRmCbNnC5
         bLDzAI/2Yk0atj3XpU5JY5uQs/57Vj0CXVInQuTMLc9XDLxWYoLW3nvwUF16CHf0e/f9
         RtJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734601176; x=1735205976;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=1ew31f6DRFQAGT7nqGDKV8ogEvncpT8YkZ4hjyU/ItI=;
        b=Y6mnT/YJQF5N32sh82V9NneAt5AgjKk8byMGAxORyEwWL0TsRe3IeBC0SEpdJoVnRB
         /VonOcjE/+80YCN4h/rGx8qcUGP7d9WXLEo+S6EW5z8G3w4kZG47CkPuHR0yS90QqkmJ
         VlFWN5l5I3O3ZFvOohcRQVw8NUZbsQevaEmBpwLU9jU2/QSbWBW/6sh4FpoIyERs03NO
         2IriMzN/o19O8rt6zO4QrV3yRAKKKF0qStLN0o4T7qZPrE0iKwxif6inVxzdbYTcWYqr
         Vw0nhlYDEe4fsmtAe0W+9goL+tI8wYO35YMLQ0LNzXhFpaP4z7J9jQqtHCe6OjAk9yGL
         Nszg==
X-Forwarded-Encrypted: i=1; AJvYcCXl3MtHuS89kvfcJcu2sHNze4qhWpTOQktP6FVpWwjHMCWpsYCUdt6O9oATdjzxNheavmO2pEH1yQ4=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxggdh4QD4c4WYaVzGXnCLIk3koAj6o8ADcStTxMU19AgKXzwcF
	yQJfDZTVdFDi+JgYskViZgR3EoScad9JY8ujMYoJoHX9gkCGOBLd
X-Gm-Gg: ASbGncuqgCwDmH7KgEfClPLQTWNPFdVsVZu7AicTgtLMdjl8PTLgG0HV+9I/zTJWGBM
	25UY3dgR6mmH5WMq33FRTQtl2bZNQV3TC6ZgYlg9A75mBpgbSniLJeOyYSoEqHbqM6plwnVKzPT
	uwdjMaMtegX2K0pG6fOyMce/rCvM0ujfefKV4EoaAYqJmK98nH3lBtCrpBmEUaPhudSi75Cm2JX
	kCYHgkhu5KfbWcWI5+lvvRWqha0blUEGLqTkjY5x4KxAjXGdDFTidvvgRyelE9EyvOMaA==
X-Google-Smtp-Source: AGHT+IGC1AvI8MGG/LvUN9kmmrXkYXxxB5ptwzGXgUtmbYqwNTmuouuyIX4CmCUU02s0voZZn95nKw==
X-Received: by 2002:a05:651c:2110:b0:2fb:4abb:7001 with SMTP id 38308e7fff4ca-3044dab62afmr21401321fa.2.1734601175561;
        Thu, 19 Dec 2024 01:39:35 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------a0f6qF0oJIW6UM81mOaAriQS"
Message-ID: 
Date: Thu, 19 Dec 2024 10:39:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/sched: Untangle credit2 vs cpu_nr_siblings()
To: Andrew Cooper ,
 Xen-devel 
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Shawn Anastasio ,
 Juergen Gross 
References: <20241218124900.60886-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <20241218124900.60886-1-andrew.cooper3@citrix.com>

This is a multi-part message in MIME format.
--------------a0f6qF0oJIW6UM81mOaAriQS
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 12/18/24 1:49 PM, Andrew Cooper wrote:
> Credit2 has no buisness including asm/cpufeature.h or asm/processor.h.
>
> This was caused by a bad original abstraction, and an even less wise attempt
> to fix the build on my behalf.  It is also the sole reason why PPC and RISC-V
> need cpufeature.h header.
>
> Worst of all, cpu_data[cpu].x86_num_siblings doesn't even have the same
> meaning between vendors on x86 CPUS.
>
> Implement cpu_nr_siblings() locally in credit2.c, leaving behind a TODO.  Drop
> the stub from each architecture.
>
> Fixes: 8e2aa76dc167 ("xen: credit2: limit the max number of CPUs in a runqueue")
> Fixes: ad33a573c009 ("xen/credit2: Fix build following c/s 8e2aa76dc (take 2)")
> Signed-off-by: Andrew Cooper

Reviewed-By: Oleksii Kurochko 

Thanks.

~ Oleksii

> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Stefano Stabellini
> CC: Julien Grall
> CC: Volodymyr Babchuk
> CC: Bertrand Marquis
> CC: Michal Orzel
> CC: Oleksii Kurochko
> CC: Shawn Anastasio
> CC: Juergen Gross
> ---
>   xen/arch/arm/include/asm/cpufeature.h   |  5 -----
>   xen/arch/ppc/include/asm/cpufeature.h   | 10 ----------
>   xen/arch/riscv/include/asm/cpufeature.h | 23 -----------------------
>   xen/arch/x86/include/asm/processor.h    |  5 -----
>   xen/common/sched/credit2.c              | 15 +++++++++++++--
>   5 files changed, 13 insertions(+), 45 deletions(-)
>   delete mode 100644 xen/arch/ppc/include/asm/cpufeature.h
>   delete mode 100644 xen/arch/riscv/include/asm/cpufeature.h
>
> diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h
> index 969e043f5bda..50297e53d90e 100644
> --- a/xen/arch/arm/include/asm/cpufeature.h
> +++ b/xen/arch/arm/include/asm/cpufeature.h
> @@ -98,11 +98,6 @@ static inline bool cpus_have_cap(unsigned int num)
>       return test_bit(num, cpu_hwcaps);
>   }
>   
> -static inline int cpu_nr_siblings(unsigned int cpu)
> -{
> -    return 1;
> -}
> -
>   /* System capability check for constant cap */
>   #define cpus_have_const_cap(num) ({                 \
>           register_t __ret;                           \
> diff --git a/xen/arch/ppc/include/asm/cpufeature.h b/xen/arch/ppc/include/asm/cpufeature.h
> deleted file mode 100644
> index 1c5946512bc5..000000000000
> --- a/xen/arch/ppc/include/asm/cpufeature.h
> +++ /dev/null
> @@ -1,10 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0-only */
> -#ifndef __ASM_PPC_CPUFEATURE_H__
> -#define __ASM_PPC_CPUFEATURE_H__
> -
> -static inline int cpu_nr_siblings(unsigned int cpu)
> -{
> -    return 1;
> -}
> -
> -#endif /* __ASM_PPC_CPUFEATURE_H__ */
> diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/include/asm/cpufeature.h
> deleted file mode 100644
> index 41a792b0b273..000000000000
> --- a/xen/arch/riscv/include/asm/cpufeature.h
> +++ /dev/null
> @@ -1,23 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0-only */
> -#ifndef ASM__RISCV__CPUFEATURE_H
> -#define ASM__RISCV__CPUFEATURE_H
> -
> -#ifndef __ASSEMBLY__
> -
> -static inline unsigned int cpu_nr_siblings(unsigned int cpu)
> -{
> -    return 1;
> -}
> -
> -#endif /* __ASSEMBLY__ */
> -
> -#endif /* ASM__RISCV__CPUFEATURE_H */
> -
> -/*
> - * Local variables:
> - * mode: C
> - * c-file-style: "BSD"
> - * c-basic-offset: 4
> - * indent-tabs-mode: nil
> - * End:
> - */
> diff --git a/xen/arch/x86/include/asm/processor.h b/xen/arch/x86/include/asm/processor.h
> index 877651212273..d247ef8dd226 100644
> --- a/xen/arch/x86/include/asm/processor.h
> +++ b/xen/arch/x86/include/asm/processor.h
> @@ -118,11 +118,6 @@ extern void init_intel_cacheinfo(struct cpuinfo_x86 *c);
>   
>   unsigned int apicid_to_socket(unsigned int apicid);
>   
> -static inline int cpu_nr_siblings(unsigned int cpu)
> -{
> -    return cpu_data[cpu].x86_num_siblings;
> -}
> -
>   /* Some CPUID calls want 'count' to be placed in ecx */
>   static inline void cpuid_count(
>       unsigned int op,
> diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
> index 76a273d4f6d5..4b2ef034ca84 100644
> --- a/xen/common/sched/credit2.c
> +++ b/xen/common/sched/credit2.c
> @@ -26,8 +26,6 @@
>   #include 
>   #include 
>   #include 
> -#include 
> -#include 
>   
>   #include "private.h"
>   
> @@ -35,6 +33,19 @@
>   /* #define d2printk printk */
>   #define d2printk(x...)
>   
> +/*
> + * TODO: Abstract this properly, and figure out what Credit2 wants to do with
> + *       the fact that x86_num_siblings doesn't even have the same meaning
> + *       between x86 vendors.
> + */
> +static unsigned int cpu_nr_siblings(unsigned int cpu)
> +{
> +#ifdef CONFIG_X86
> +    return cpu_data[cpu].x86_num_siblings;
> +#else
> +    return 1;
> +#endif
> +}
>   
>   /*
>    * Credit2 tracing events ("only" 512 available!). Check
--------------a0f6qF0oJIW6UM81mOaAriQS
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    
On 12/18/24 1:49 PM, Andrew Cooper
      wrote:

    

    

      
Credit2 has no buisness including asm/cpufeature.h or asm/processor.h.

This was caused by a bad original abstraction, and an even less wise attempt
to fix the build on my behalf.  It is also the sole reason why PPC and RISC-V
need cpufeature.h header.

Worst of all, cpu_data[cpu].x86_num_siblings doesn't even have the same
meaning between vendors on x86 CPUS.

Implement cpu_nr_siblings() locally in credit2.c, leaving behind a TODO.  Drop
the stub from each architecture.

Fixes: 8e2aa76dc167 ("xen: credit2: limit the max number of CPUs in a runqueue")
Fixes: ad33a573c009 ("xen/credit2: Fix build following c/s 8e2aa76dc (take 2)")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

    

    
Reviewed-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>

    
Thanks.

    
~ Oleksii

    

    

      
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien@xen.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
CC: Bertrand Marquis <bertrand.marquis@arm.com>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
CC: Shawn Anastasio <sanastasio@raptorengineering.com>
CC: Juergen Gross <jgross@suse.com>
---
 xen/arch/arm/include/asm/cpufeature.h   |  5 -----
 xen/arch/ppc/include/asm/cpufeature.h   | 10 ----------
 xen/arch/riscv/include/asm/cpufeature.h | 23 -----------------------
 xen/arch/x86/include/asm/processor.h    |  5 -----
 xen/common/sched/credit2.c              | 15 +++++++++++++--
 5 files changed, 13 insertions(+), 45 deletions(-)
 delete mode 100644 xen/arch/ppc/include/asm/cpufeature.h
 delete mode 100644 xen/arch/riscv/include/asm/cpufeature.h

diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h
index 969e043f5bda..50297e53d90e 100644
--- a/xen/arch/arm/include/asm/cpufeature.h
+++ b/xen/arch/arm/include/asm/cpufeature.h
@@ -98,11 +98,6 @@ static inline bool cpus_have_cap(unsigned int num)
     return test_bit(num, cpu_hwcaps);
 }
 
-static inline int cpu_nr_siblings(unsigned int cpu)
-{
-    return 1;
-}
-
 /* System capability check for constant cap */
 #define cpus_have_const_cap(num) ({                 \
         register_t __ret;                           \
diff --git a/xen/arch/ppc/include/asm/cpufeature.h b/xen/arch/ppc/include/asm/cpufeature.h
deleted file mode 100644
index 1c5946512bc5..000000000000
--- a/xen/arch/ppc/include/asm/cpufeature.h
+++ /dev/null
@@ -1,10 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-#ifndef __ASM_PPC_CPUFEATURE_H__
-#define __ASM_PPC_CPUFEATURE_H__
-
-static inline int cpu_nr_siblings(unsigned int cpu)
-{
-    return 1;
-}
-
-#endif /* __ASM_PPC_CPUFEATURE_H__ */
diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/include/asm/cpufeature.h
deleted file mode 100644
index 41a792b0b273..000000000000
--- a/xen/arch/riscv/include/asm/cpufeature.h
+++ /dev/null
@@ -1,23 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-#ifndef ASM__RISCV__CPUFEATURE_H
-#define ASM__RISCV__CPUFEATURE_H
-
-#ifndef __ASSEMBLY__
-
-static inline unsigned int cpu_nr_siblings(unsigned int cpu)
-{
-    return 1;
-}
-
-#endif /* __ASSEMBLY__ */
-
-#endif /* ASM__RISCV__CPUFEATURE_H */
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/arch/x86/include/asm/processor.h b/xen/arch/x86/include/asm/processor.h
index 877651212273..d247ef8dd226 100644
--- a/xen/arch/x86/include/asm/processor.h
+++ b/xen/arch/x86/include/asm/processor.h
@@ -118,11 +118,6 @@ extern void init_intel_cacheinfo(struct cpuinfo_x86 *c);
 
 unsigned int apicid_to_socket(unsigned int apicid);
 
-static inline int cpu_nr_siblings(unsigned int cpu)
-{
-    return cpu_data[cpu].x86_num_siblings;
-}
-
 /* Some CPUID calls want 'count' to be placed in ecx */
 static inline void cpuid_count(
     unsigned int op,
diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c
index 76a273d4f6d5..4b2ef034ca84 100644
--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -26,8 +26,6 @@
 #include <xen/trace.h>
 #include <xen/cpu.h>
 #include <xen/keyhandler.h>
-#include <asm/cpufeature.h>
-#include <asm/processor.h>
 
 #include "private.h"
 
@@ -35,6 +33,19 @@
 /* #define d2printk printk */
 #define d2printk(x...)
 
+/*
+ * TODO: Abstract this properly, and figure out what Credit2 wants to do with
+ *       the fact that x86_num_siblings doesn't even have the same meaning
+ *       between x86 vendors.
+ */
+static unsigned int cpu_nr_siblings(unsigned int cpu)
+{
+#ifdef CONFIG_X86
+    return cpu_data[cpu].x86_num_siblings;
+#else
+    return 1;
+#endif
+}
 
 /*
  * Credit2 tracing events ("only" 512 available!). Check


    

  


--------------a0f6qF0oJIW6UM81mOaAriQS--


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 09:43:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 09:43:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861009.1273000 (Exim 4.92)
	(envelope-from )
	id 1tOD4Q-0007ib-Hg; Thu, 19 Dec 2024 09:43:50 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861009.1273000; Thu, 19 Dec 2024 09:43: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 1tOD4Q-0007iU-F8; Thu, 19 Dec 2024 09:43:50 +0000
Received: by outflank-mailman (input) for mailman id 861009;
 Thu, 19 Dec 2024 09:43: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 1tOD4P-0007iO-0q
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 09:43:49 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id beb74a95-bded-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 10:43:48 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 19 Dec 2024 10:43:47 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: beb74a95-bded-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734601428; x=1766137428;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=4NIs3X7B/yG8BRZfrqp3eruYt56MPk2acANApO1vzZE=;
  b=dhCRIo/jE1j4IPOnBm0EcaSU+DkSiluRwngfrKBn7d3LDhTa3v4VwGsO
   SvEioorT+m6rn7bxIy0qrA2wzK3Z20D2VYyAF4mgJoWgo5PBmteTVkxXo
   zOzJ6U3POQTiBjgZ0abeYADSA9adm9XzhGsi//Z8TzWT5+kTlhKyBIX94
   4=;
X-CSE-ConnectionGUID: 3ZC9paJcR4SrSexCQNLSeA==
X-CSE-MsgGUID: JUHga2kQSi6f4vKg7l26HA==
X-IronPort-AV: E=Sophos;i="6.12,247,1728943200"; 
   d="scan'208";a="28252061"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: <2f7a84-6763e300-4ca3-4ac1e700@170330858>
Content-Type: text/plain; charset="utf-8"
X-Forward: 88.183.119.157
References: <20241218233659.573195-2-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241218233659.573195-3-Ariel.Otilibili-Anieli@eurecom.fr> <7587b503-b2ca-4476-8dc9-e9683d4ca5f0@suse.com> <2f7a84-6763e300-4ca3-4ac1e700@170330858>
Date: Thu, 19 Dec 2024 10:43:47 +0100
Cc: "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Stefano Stabellini" , xen-devel@lists.xenproject.org
To: "Jan Beulich" 
MIME-Version: 1.0
Message-ID: <2f7a88-6763eb00-f2ed-208cdcc@256791574>
Subject: =?utf-8?q?Re=3A?= [PATCH 1/1] =?utf-8?q?xen/common=3A?= Remove dead code
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 1534

On Thursday, December 19, 2024 10:10 CET, "Ariel Otilibili-Anieli"  wrote:

> On Thursday, December 19, 2024 09:32 CET, Jan Beulich  wrote:
>=20
> > On 19.12.2024 00:34, Ariel Otilibili wrote:
> > > The if-statement tests `res` is non-zero; meaning the case zero i=
s never reached.
> > >=20
> > > Coverity-ID: 1055253
> > > Fixes: e2b1ebf4de ("x86: Support booting a bzImage format domain =
0 kernel.")
> > > Signed-off-by: Ariel Otilibili 
> >=20
> > I certainly agree with the change, especially if Coverity complains=
 about it.
> > In fact I'd expect Eclair to complain too, for this being unreachab=
le or dead
> > code (I'm never sure which one's which in their nomenclature). The =
Misra
> > violation addressed may therefore want mentioning, too.
>=20
> I didn't know Eclair and Miscra could send warnings. Are they command=
s available for that?
> >=20
> > However, the commit referenced says "xen/common/inflate.c is taken =
unmodified
> > from Linux v2.6.28." Therefore the preferred approach would be to c=
orrect the
> > original first, then pull in that patch to our tree. (And yes, the =
code is
> > still as was even in 6.13-rc3.)
>=20
> So old a commit...
>=20
> This approach makes sense, Jan; thanks for the feedback. I am sending=
 the patch to Linux.
>=20
> And will keep you posted.

The patch sent to Linux,
https://lore.kernel.org/lkml/20241219092615.644642-1-ariel.otilibili-an=
ieli@eurecom.fr/
> >=20
> > Jan



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 09:45:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 09:45:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861016.1273015 (Exim 4.92)
	(envelope-from )
	id 1tOD5b-0008Go-S7; Thu, 19 Dec 2024 09:45:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861016.1273015; Thu, 19 Dec 2024 09: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 1tOD5b-0008Gh-PD; Thu, 19 Dec 2024 09:45:03 +0000
Received: by outflank-mailman (input) for mailman id 861016;
 Thu, 19 Dec 2024 09:45: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 1tOD5b-0008Gb-Ax
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 09:45:03 +0000
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com
 [2a00:1450:4864:20::12c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id ea424fbf-bded-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 10:45:00 +0100 (CET)
Received: by mail-lf1-x12c.google.com with SMTP id
 2adb3069b0e04-540218726d5so461898e87.2
 for ; Thu, 19 Dec 2024 01:45:01 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-542238137e5sm121452e87.134.2024.12.19.01.44.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Dec 2024 01:44: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: ea424fbf-bded-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734601500; x=1735206300; darn=lists.xenproject.org;
        h=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=kuMsIvNropcp2fIWn9jDG/5G2IcB2qoWam1saEM0oPk=;
        b=GJjMLpuacuV7/1YlS6A2Fpw6gdTiSwOAvXISksnND7YmJgYPzPaHlWP+uJvYtc8LzP
         H4pfnbbx6YQuVOmDsxAUdERxAEJ1KRr9gNrD2cU13dOchXNgZTYy1EwCKkTGd+R2tsl0
         mkPRPB44LZaDzPx5wXXxAY7jzoSlfgsM4juoAiUVfzwTlLp5uVRNIDfgGPLP5/vZsljx
         NgXh4p0IttKx+ROnjYwPQ0WGHkBJsbSSr/QLPqc4MDkabR6gAeAqCb7t9VQ9196T2OJ4
         cdxIbKapx6ESUtu9iM7m3622S2G09FzsfFNx4tq+jDucNnw9UD/ImBUPmGHhWVNp8IYZ
         rhzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734601500; x=1735206300;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=kuMsIvNropcp2fIWn9jDG/5G2IcB2qoWam1saEM0oPk=;
        b=M4FVmkwfDMro/DK/FG6Oxke1w2YjGKQebkI74DxzYQZWv+dDz8Xa5p4bdGUZTw9Xp2
         jUXjiEs5uX3oiVy62qutpeyZcMiYqquLFZlyfi1YyFQSIzpghnn6LpH0kiBFmTDTgio2
         jtBj4yW0JALDRT0jBCdAPpY2xKDmrD+K4vW5wi00VWxISphZdScLjeCMlSyYf71yNDeZ
         uQZ5ZNQrmuTztIZ7rUJ8t++cracJFs+fviPolUJ8GfEys7BwBblQxVcHa1A2eTzocBvJ
         Y9VL4BanAG8n99MWwiJdw+kztC/kkRIO33XvpX08hpBujR5oewsOj8Oz3Rple96CaZ2/
         BWkA==
X-Forwarded-Encrypted: i=1; AJvYcCUCu7nc7u5eydq4aJRJ8HI9kKitbPNLnlDNc65j9gtKAq+BuAJ76Ntq21GcZ9vuKNzhN5jIDJccCIk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxfspSmEaEmshZ8mNu8r9n63bhBF4zz9K7CXka7r0v23NWTpdNH
	q0gPT9BFfSeS53CDNvjSIxEoLU0L6ZHfkYvhL1PPYT9fninE0osY
X-Gm-Gg: ASbGncssB5CgqgAOmULenaIIE5NpChv36jmsjAFiMPffWm4UIRStA5aIfYRK0GXd3hh
	31hgrFNf8egZc3SyEFSL3LcCV9tcu4EWhUohHCClXzQT7TRL/71zufhuUvLjLdS9+pMdSpzltZL
	6OI8yXhTPS7vezIJTVMIxkwH50c7y4JkEsIukidYkd/no9MpCNfrTkLWOYetNa6e3Fd5UGQdkNF
	KolQbiozxYp9L71xmqljXZdXYLk0cmX0iMcsLarcgkfN0+znfsnsPSCzGkZmz5y1x/5Jg==
X-Google-Smtp-Source: AGHT+IHb2igBfeR9uahGL3/F9kdoQBpsUt7W9QDauB1Tp6QbH6C1e9/YseR24+AfOBUjwMiKyW40Lg==
X-Received: by 2002:a05:6512:3087:b0:540:2ef4:9cf0 with SMTP id 2adb3069b0e04-541ed8ec076mr2465803e87.18.1734601500113;
        Thu, 19 Dec 2024 01:45:00 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------CVU5VXmeRdROzCYou6N0UNGN"
Message-ID: <5ce22b0d-ae01-404a-8bfe-d4891dd94555@gmail.com>
Date: Thu, 19 Dec 2024 10:44:59 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2] tools/libxg: Don't gunzip the guests initrd
To: Andrew Cooper ,
 Xen-devel 
Cc: Anthony PERARD ,
 Juergen Gross , Michal Orzel ,
 Jan Beulich , Julien Grall ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini 
References: <20240904123121.3837140-1-andrew.cooper3@citrix.com>
 <20241218185453.367465-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <20241218185453.367465-1-andrew.cooper3@citrix.com>

This is a multi-part message in MIME format.
--------------CVU5VXmeRdROzCYou6N0UNGN
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 12/18/24 7:54 PM, Andrew Cooper wrote:
> Decompressing the kernel is necessary to inspect the ELF notes, but the
> dombuilder will gunzip() secondary modules too.  Specifically gunzip(), no
> other decompression algorithms.
>
> This may have been necessary in the dim and distant past, but it is broken
> today.  Linux specifically supports concatenating CPIO fragments of differing
> compressions, and any attempt to interpret it with a single algorithm may
> corrupt later parts.
>
> This was an unexpected discovery while trying to test Xen's gunzip()
> logic (Xen as a PVH guest, with a gzipped XTF kernel as dom0).
>
> Intepreting secondary modules *should* be left as an exersize to the guest.
> This reduces work done in dom0.
>
> This is not expected to cause a practical different to guests these days.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Anthony PERARD
> CC: Juergen Gross
> CC: Anthony PERARD
> CC: Michal Orzel
> CC: Jan Beulich
> CC: Julien Grall
> CC: Roger Pau Monné
> CC: Stefano Stabellini
> CC: Oleksii Kurochko
>
> v2:
>   * Rewrite the commit message.
>
> If this does cause a problem, we can reintroduce it, but behind a config
> option because it needs to not be on by default.
>
> Linux's habit of prepending an uncompressed CPIO containing microcode is
> likely to cause this logic to be skipped anyway.
> ---
>   CHANGELOG.md                   |  2 ++

Acked-By: Oleksii Kurochko 

Thanks.

~ Oleksii


>   tools/libs/guest/xg_dom_core.c | 40 ++++++----------------------------
>   2 files changed, 9 insertions(+), 33 deletions(-)
>
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 15f681459f22..61510e6a11c0 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -8,6 +8,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>   
>   ### Changed
>    - Fixed blkif protocol specification for sector sizes different than 512b.
> + - The dombuilder in libxenguest no longer un-gzips secondary modules, instead
> +   leaving this to the guest kernel to do in guest context.
>    - On x86:
>      - Prefer ACPI reboot over UEFI ResetSystem() run time service call.
>      - Switched the xAPIC flat driver to use physical destination mode for external
> diff --git a/tools/libs/guest/xg_dom_core.c b/tools/libs/guest/xg_dom_core.c
> index f5521d528be1..595b0a667c03 100644
> --- a/tools/libs/guest/xg_dom_core.c
> +++ b/tools/libs/guest/xg_dom_core.c
> @@ -980,37 +980,24 @@ int xc_dom_mem_init(struct xc_dom_image *dom, unsigned int mem_mb)
>   
>   static int xc_dom_build_module(struct xc_dom_image *dom, unsigned int mod)
>   {
> -    size_t unziplen, modulelen;
> +    size_t modulelen;
>       void *modulemap;
>       char name[10];
>   
> -    if ( !dom->modules[mod].seg.vstart )
> -        unziplen = xc_dom_check_gzip(dom->xch,
> -                                     dom->modules[mod].blob, dom->modules[mod].size);
> -    else
> -        unziplen = 0;
> +    modulelen = dom->modules[mod].size;
>   
> -    modulelen = max(unziplen, dom->modules[mod].size);
> -    if ( dom->max_module_size )
> +    if ( dom->max_module_size && modulelen > dom->max_module_size )
>       {
> -        if ( unziplen && modulelen > dom->max_module_size )
> -        {
> -            modulelen = min(unziplen, dom->modules[mod].size);
> -            if ( unziplen > modulelen )
> -                unziplen = 0;
> -        }
> -        if ( modulelen > dom->max_module_size )
> -        {
> -            xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
> -                         "module %u image too large", mod);
> -            goto err;
> -        }
> +        xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
> +                     "module %u image too large", mod);
> +        goto err;
>       }
>   
>       snprintf(name, sizeof(name), "module%u", mod);
>       if ( xc_dom_alloc_segment(dom, &dom->modules[mod].seg, name,
>                                 dom->modules[mod].seg.vstart, modulelen) != 0 )
>           goto err;
> +
>       modulemap = xc_dom_seg_to_ptr(dom, &dom->modules[mod].seg);
>       if ( modulemap == NULL )
>       {
> @@ -1018,21 +1005,8 @@ static int xc_dom_build_module(struct xc_dom_image *dom, unsigned int mod)
>                     __FUNCTION__, mod);
>           goto err;
>       }
> -    if ( unziplen )
> -    {
> -        if ( xc_dom_do_gunzip(dom->xch, dom->modules[mod].blob, dom->modules[mod].size,
> -                              modulemap, unziplen) != -1 )
> -            return 0;
> -        if ( dom->modules[mod].size > modulelen )
> -            goto err;
> -    }
>   
> -    /* Fall back to handing over the raw blob. */
>       memcpy(modulemap, dom->modules[mod].blob, dom->modules[mod].size);
> -    /* If an unzip attempt was made, the buffer may no longer be all zero. */
> -    if ( unziplen > dom->modules[mod].size )
> -        memset(modulemap + dom->modules[mod].size, 0,
> -               unziplen - dom->modules[mod].size);
>   
>       return 0;
>   
--------------CVU5VXmeRdROzCYou6N0UNGN
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    


    

    
On 12/18/24 7:54 PM, Andrew Cooper
      wrote:

    

    

      
Decompressing the kernel is necessary to inspect the ELF notes, but the
dombuilder will gunzip() secondary modules too.  Specifically gunzip(), no
other decompression algorithms.

This may have been necessary in the dim and distant past, but it is broken
today.  Linux specifically supports concatenating CPIO fragments of differing
compressions, and any attempt to interpret it with a single algorithm may
corrupt later parts.

This was an unexpected discovery while trying to test Xen's gunzip()
logic (Xen as a PVH guest, with a gzipped XTF kernel as dom0).

Intepreting secondary modules *should* be left as an exersize to the guest.
This reduces work done in dom0.

This is not expected to cause a practical different to guests these days.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Anthony PERARD <anthony.perard@vates.tech>
CC: Juergen Gross <jgross@suse.com>
CC: Anthony PERARD <anthony.perard@vates.tech>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Julien Grall <julien@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>

v2:
 * Rewrite the commit message.

If this does cause a problem, we can reintroduce it, but behind a config
option because it needs to not be on by default.

Linux's habit of prepending an uncompressed CPIO containing microcode is
likely to cause this logic to be skipped anyway.
---
 CHANGELOG.md                   |  2 ++

    

    
Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>

    
Thanks.

    
~ Oleksii


    

    

      
 tools/libs/guest/xg_dom_core.c | 40 ++++++----------------------------
 2 files changed, 9 insertions(+), 33 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 15f681459f22..61510e6a11c0 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -8,6 +8,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 
 ### Changed
  - Fixed blkif protocol specification for sector sizes different than 512b.
+ - The dombuilder in libxenguest no longer un-gzips secondary modules, instead
+   leaving this to the guest kernel to do in guest context.
  - On x86:
    - Prefer ACPI reboot over UEFI ResetSystem() run time service call.
    - Switched the xAPIC flat driver to use physical destination mode for external
diff --git a/tools/libs/guest/xg_dom_core.c b/tools/libs/guest/xg_dom_core.c
index f5521d528be1..595b0a667c03 100644
--- a/tools/libs/guest/xg_dom_core.c
+++ b/tools/libs/guest/xg_dom_core.c
@@ -980,37 +980,24 @@ int xc_dom_mem_init(struct xc_dom_image *dom, unsigned int mem_mb)
 
 static int xc_dom_build_module(struct xc_dom_image *dom, unsigned int mod)
 {
-    size_t unziplen, modulelen;
+    size_t modulelen;
     void *modulemap;
     char name[10];
 
-    if ( !dom->modules[mod].seg.vstart )
-        unziplen = xc_dom_check_gzip(dom->xch,
-                                     dom->modules[mod].blob, dom->modules[mod].size);
-    else
-        unziplen = 0;
+    modulelen = dom->modules[mod].size;
 
-    modulelen = max(unziplen, dom->modules[mod].size);
-    if ( dom->max_module_size )
+    if ( dom->max_module_size && modulelen > dom->max_module_size )
     {
-        if ( unziplen && modulelen > dom->max_module_size )
-        {
-            modulelen = min(unziplen, dom->modules[mod].size);
-            if ( unziplen > modulelen )
-                unziplen = 0;
-        }
-        if ( modulelen > dom->max_module_size )
-        {
-            xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
-                         "module %u image too large", mod);
-            goto err;
-        }
+        xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
+                     "module %u image too large", mod);
+        goto err;
     }
 
     snprintf(name, sizeof(name), "module%u", mod);
     if ( xc_dom_alloc_segment(dom, &dom->modules[mod].seg, name,
                               dom->modules[mod].seg.vstart, modulelen) != 0 )
         goto err;
+
     modulemap = xc_dom_seg_to_ptr(dom, &dom->modules[mod].seg);
     if ( modulemap == NULL )
     {
@@ -1018,21 +1005,8 @@ static int xc_dom_build_module(struct xc_dom_image *dom, unsigned int mod)
                   __FUNCTION__, mod);
         goto err;
     }
-    if ( unziplen )
-    {
-        if ( xc_dom_do_gunzip(dom->xch, dom->modules[mod].blob, dom->modules[mod].size,
-                              modulemap, unziplen) != -1 )
-            return 0;
-        if ( dom->modules[mod].size > modulelen )
-            goto err;
-    }
 
-    /* Fall back to handing over the raw blob. */
     memcpy(modulemap, dom->modules[mod].blob, dom->modules[mod].size);
-    /* If an unzip attempt was made, the buffer may no longer be all zero. */
-    if ( unziplen > dom->modules[mod].size )
-        memset(modulemap + dom->modules[mod].size, 0,
-               unziplen - dom->modules[mod].size);
 
     return 0;
 


    

  


--------------CVU5VXmeRdROzCYou6N0UNGN--


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 09:53:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 09:53:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861028.1273025 (Exim 4.92)
	(envelope-from )
	id 1tODDq-0001qO-LE; Thu, 19 Dec 2024 09:53:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861028.1273025; Thu, 19 Dec 2024 09:53: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 1tODDq-0001qH-Hz; Thu, 19 Dec 2024 09:53:34 +0000
Received: by outflank-mailman (input) for mailman id 861028;
 Thu, 19 Dec 2024 09:53: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 1tODDp-0001qB-81
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 09:53:33 +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 1aeec5b7-bdef-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 10:53:32 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-436345cc17bso4155905e9.0
 for ; Thu, 19 Dec 2024 01:53: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
 5b1f17b1804b1-436611ea423sm13386275e9.2.2024.12.19.01.53.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Dec 2024 01:53: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: 1aeec5b7-bdef-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734602011; x=1735206811; 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=xnBj7g9EXA4Fi6c25soyyCh5M+GQH2hIk0HxhqA68PU=;
        b=gbxkqlVPWwVfqvEPBv1U3rJx6vWSqypkmJ+oo7o0NQ6RFPZcDueqZQ4Lp7pIQFUYlc
         6u9XK6FW8Hu9GBud+Fr/gJbfK8iabjkvMZyVy93c7moe+C0rUJQzOFb3xtPapN+tRoIx
         ZZwjYkECj5GCpwvsNp0JFcVbSVMWp8FmN3knffWDaBOt3dny+6HgjhXC7lQI75jQL+qB
         +WiEvOxJwGyQ90VdgTUxQWL8bb/i/r+HG611zu+1dVH9NbT99Yw8V2qLZ8AJGlyXEx5z
         8wubgiiShter4/nJlhdlD5xIjLk5ZE3T27XUPOoipGc3UMvvLLxaHh4xWSbGK5tBhX3J
         jVNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734602011; x=1735206811;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=xnBj7g9EXA4Fi6c25soyyCh5M+GQH2hIk0HxhqA68PU=;
        b=X750d1PP8Zd7Mq56KUGWNUABxuQx4UN2RcQCIN++xHoCdR94AmkLXRE8VsnvqvQscV
         2d+Mk1kr9hHcNWNnfN1EvkFOY+5nCQXpJX945fec+WqoUWur0aj4W2QVBIWHJA7sY3GC
         fmn9f3nH4Fo+HA5OZ0MKX2jVDayWxP+Rj86Ew1TWorQrorrsJS1sKtMsKYU+gMSWCKwj
         Om5bSF8ixi0/3cM4G3vGKJib35Ol7WoNbpjo1Q7uhU8Mon+giI7ybHgE+yZdkwaC2mni
         3W1PMThN2045Ai25/N8HN9xOvdKdcZYxzI1ub8yYRMIqCzPn3vTuAjHdk25VKdFf4Gc3
         DfVA==
X-Forwarded-Encrypted: i=1; AJvYcCVqM4QCCvCWRmFJSCcZx/zeULt8ObiA1T58Z6PxeAASIflAsXm3LSrL+WpJne978dkPJ6w94/vIizE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxF15Dq6dBiS7ISBbkLvaQTgRSFOYQpg/dXlyrqMVJBaRtS1VGz
	lfE6IwhWf7LjzAGG26rEyD3nCYqqowaqr89+Wvzy5J0UCicsoxvad4WcLqiXJg==
X-Gm-Gg: ASbGncueR2wqyChIHjof8OSMuO2i95Q6GIFniggzcHgz2RkJM++McN1QPwes7wAzoN8
	gEjRMEfD0O3PUZT4UbAxZI4CuPXUikdPQfsbT2d9ELK1OvlW2BPxWRycSUDHIdIiydONQqOf/eS
	c0on4xpOk1/23qndY9oYHvpS5ns61MF8lUGWVOlB+3p9axus2L+IsIh6GgFNoiQznWYyard8xn6
	aEXsK1sxZFwH249ma90zo8kBSK6p+oV8J6g5n8ktFjLPOZWQK0Cfxru6QXQ8A1DPLjqSzPk++xa
	RzbdvO1m8G3XjrE7eIyrZhzXjsLqLoz/oimKPLgsVQ==
X-Google-Smtp-Source: AGHT+IE4F1fMGI8LtO6gmgYDobrcMURYTh+L4zIDduP3WXSy6cIk07stKiGr5KPYYkCZbYse2H1fXA==
X-Received: by 2002:a05:600c:1549:b0:435:194:3cdf with SMTP id 5b1f17b1804b1-4365536fab4mr52308955e9.19.1734602011369;
        Thu, 19 Dec 2024 01:53:31 -0800 (PST)
Message-ID: <11dd98bf-c32f-43ce-9161-5dee68821ba1@suse.com>
Date: Thu, 19 Dec 2024 10:53:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen 4.20 Development Update [November]
To: Oleksii Kurochko 
Cc: committers@xenproject.org, kelly.choi@cloud.com,
 xen-devel@lists.xenproject.org
References: <20241204102035.22505-1-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: <20241204102035.22505-1-oleksii.kurochko@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04.12.2024 11:20, Oleksii Kurochko wrote:
> This email only tracks big items for xen.git tree. Please reply for items you
> would like to see in 4.20 so that people have an idea what is going on and
> prioritise accordingly.
> 
> You're welcome to provide description and use cases of the feature you're
> working on.
> 
> = Timeline =
> 
> * Last posting date: Nov 29, 2024
> ---> We are here
> * Feature freeze date: Dec 20, 2024
> * Hard code freeze: Jan 17, 2025
> * RC1: TBD
> * Release: Feb 21, 2025
> ( current release schedule: https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes )
> 
> All patches that wish to go into 4.20 must be posted no later than the last posting
> date. All patches posted after that date will be automatically queued
> into next release.
> If you would like your features included in this release, please ensure
> they are committed by the deadline.
> 
> RCs will be arranged immediately after freeze.
> 
> The following items ( the links for them could be found int the list below )
> were moved to completed:
> - Hypervisor:
>   * drivers/char: rename arm-uart.c to uart-init.c
>   * Move gic_preinit() to common code
>   * stubdom: reduce xenstore library dependencies
>   * xen/trace: Treewide API cleanup
> - x86:
>   * x86/HVM: drop stdvga caching mode
>   * Fix module-handling use-after-free's
>   * Reuse 32 bit C code more safely
>   * xen: address violations of MISRA C Rule 13.6
>   * x86/ucode: Simplify/fix loading paths further
>   * x86: address violations of MISRA C Rule 16.3
>   * iommu/x86: fixes/improvements for unity range checks
>   * x86/pvh: Support relocating dom0 kernel
> - Arm:
>   * xen/arm: Add emulation of Debug Data Transfer Registers
> - RISC-V:
>   * Setup memory management
> 
> 
> * Full list of items : *

While only a small single patch, what I think you may want to also keep an eye
on is "drop setting XEN_QEMU_CONSOLE_LIMIT in the environment".

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 10:03:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 10:03:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861039.1273035 (Exim 4.92)
	(envelope-from )
	id 1tODNC-0003ob-Gi; Thu, 19 Dec 2024 10:03:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861039.1273035; Thu, 19 Dec 2024 10:03:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tODNC-0003oU-Dy; Thu, 19 Dec 2024 10:03:14 +0000
Received: by outflank-mailman (input) for mailman id 861039;
 Thu, 19 Dec 2024 10:03: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 1tODNB-0003oO-06
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 10:03:13 +0000
Received: from EUR03-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur03on20611.outbound.protection.outlook.com
 [2a01:111:f403:260c::611])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 74282dce-bdf0-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 11:03:11 +0100 (CET)
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com (2603:10a6:10:312::7)
 by PA4PR04MB9590.eurprd04.prod.outlook.com (2603:10a6:102:26f::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.12; Thu, 19 Dec
 2024 10:03:07 +0000
Received: from DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f]) by DU0PR04MB9561.eurprd04.prod.outlook.com
 ([fe80::9808:be1a:b32:173f%6]) with mapi id 15.20.8251.015; Thu, 19 Dec 2024
 10:03: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: 74282dce-bdf0-11ef-a0d7-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ggz87eeGV5Q0vgMnhI0CJP5gcI8ifozUxtPDt5gaPzuOqJAe/TyapFe7o8CdJmnml6OVbLPjiUHJ5TyDIt7YLie1VyCTrIJhrNlx06dxX8SRddVJ4nn3kdi4j7srcHeYRR7LkKavgY5l8oxFXx0AN2mCmEVIbRQsRnBxm7bDQazwl6Y6K8/yviQV2GcpWiK2JfYKYzP6Vwk0rb3GnAKDbzOrn/DquBzHBVLU1SYcB2f7pGCEwh5vaOETDgHHAI3TwlZYXqo+y38+QKTbTt6bzwIuK22lcjEEFw58/ZkB+Vk30HkKPVYxZTSPhJcjJxEzqfRfyeiI06MuWLKQx2zBNw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=QK1C1SuFyM8QJxGneRzCFJCjyqz4CB8QTpVoXs1AB0E=;
 b=EPBtI9SJiSY5Hlf2wDoHicQudvswWE/XF/KyN3WCRhY0ls7Tctccogo3uUqk4CQK2WO9/UAaBavhg8AqzNYoz94tuNWuHDe3OlHB6DiLX5B71B23aEMce5Pxr+PhTki9pI44JcEgVGQjTHyvmcItuVDdWFtIXbECiiOyoHbtA/damRAgZ/3V5jHFvqv0O/r6BX52Ir4QW/tKa4//YeLk/UEFYC06FKGHXhw/aTQ8RjhumGKfjo3RTtUH1Fy8/+jsEqm0zseNfynVWxU+VRHjkvAAznahmTh4Xc+Qn7zRSg3A2KRpVyFgnTdImVXXX7CxUaPUr1E7JUSFzCMx8kmKsw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com;
 dkim=pass header.d=oss.nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com;
 s=selector1-NXP1-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=QK1C1SuFyM8QJxGneRzCFJCjyqz4CB8QTpVoXs1AB0E=;
 b=E+7Bkl97DwRhqMwMeo6PellWjSMSlpJAnM3kB0IA83qCKOSPvTyVAnIByoVKdLV/9Q1XB4ltOIGho3KKrWVyG8P22S4Seggo1CCBzFqLmv35hFdpMZUZteAss9IeBePh4HPyBCuvPsldxPduH9tDnicRI6jFRNjpxwV5NYPbl1UCSdm/ViCx+4wMyFeSE0sf4Xfs+TL1WY1VnfGCZCEbiSeF8xfrV15qxUbYfeng5g2+SphXWqKoSymjfKu0L+we8Uz+FTRWD21ljDRyNDjy9QKrcP+HNXrvp8UpUTgxxC9JB27OLtYcXhVo1ivsZCLjlU4mFRQYroiN2wqfqTxG0g==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=oss.nxp.com;
Message-ID: <21968a5d-9d81-4cbc-985a-6765a6dc090a@oss.nxp.com>
Date: Thu, 19 Dec 2024 12:02:47 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/6] xen/arm: firmware: Add SCMI over SMC calls
 handling layer
To: Michal Orzel , xen-devel@lists.xenproject.org
Cc: S32@nxp.com, Andrei Cherechesu ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20241218101142.1552618-1-andrei.cherechesu@oss.nxp.com>
 <20241218101142.1552618-2-andrei.cherechesu@oss.nxp.com>
 <60d4ac08-c5e8-4a38-bfc9-2b73e6cf5ec7@amd.com>
 
 <87aad119-a55e-4683-824c-606f681af60c@amd.com>
Content-Language: en-US
From: Andrei Cherechesu 
In-Reply-To: <87aad119-a55e-4683-824c-606f681af60c@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: AM0PR05CA0076.eurprd05.prod.outlook.com
 (2603:10a6:208:136::16) To DU0PR04MB9561.eurprd04.prod.outlook.com
 (2603:10a6:10:312::7)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0PR04MB9561:EE_|PA4PR04MB9590:EE_
X-MS-Office365-Filtering-Correlation-Id: 57fe8b48-32f9-4eab-547f-08dd20145640
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
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:
	=?utf-8?B?cFZOM3hZTnJHd21Nai9aTktibG4yOWQxcnlwNFRZVnRRcmo3YjVzWHAwK0hq?=
 =?utf-8?B?R251UHV4eU1GbGhqRjZ5UzlFTkhmL2h2dCtZT0tNbXR1WEVLUkUyL3JEMEVW?=
 =?utf-8?B?RUE1aEY4d2s1T2I0LzRhRmx1YnNaaHlYdTN3YTM5Skt6TXdiSlZNY1FBdW9M?=
 =?utf-8?B?cGwvbXF1bkhLR0lwSFdla1paVUpoS0dNMDVyRVl1RkdRdTc4MmhNTm05OHdk?=
 =?utf-8?B?aHgwUU1iMzVGMnIyNWNCcGJHZVN1dU51a3FhRFlBdTh6bGpVL09nNnJVdGww?=
 =?utf-8?B?THIyUDZ6WG0vRnRrYm5wNExPaE9rOEJLaGR3VUtrSCtqaVVrem52WGZHenB6?=
 =?utf-8?B?ZlhtWVV6VzFjbE9rUVg0anU5T3FzU2Z4cWlkOHVjQXEwSkx3c05LS1NhTUdC?=
 =?utf-8?B?M3pnOU9QcXdVMTN3djFuaDA5UUR2MzVCUjNkZ0JNSXNzRnl5VVFKZGxsUDBs?=
 =?utf-8?B?cDBoaWh5cVZuV0lDR0VkMjltYVdONHd4YzZPU1dQTURpU0dJVjhob3VCdEcr?=
 =?utf-8?B?K3R5T3NiWm9NSFlQdEFCYWhnL1FOVmJLSnpaN2RRNm40cUZrcHZEQmtaOTNO?=
 =?utf-8?B?dFF0azUvRFlZVWlIOTJ3STJacllUdXNEUHA5RUM3S3kzU3hDZGNZOUp6bmJ2?=
 =?utf-8?B?aXlHWG9OTkxZWHljV1dmTEhKd2wyTUR2VitFdXlFVGJZZlpxVm5LM3l4NGJX?=
 =?utf-8?B?bkxvTElMZGZlcUx5RUVJN3gwWUFTU3lPS2lMdEk5a0xtcC90akdlQlhRN2Zm?=
 =?utf-8?B?VmdVMnh5RndHbnZJNHJWN3ZLVXdwU0ppUDg0dzM5RHlHNGpVVDJVNWt6cno0?=
 =?utf-8?B?YjJmL2ovMjFCd2FTTUw1bys2bHdteGR0M09UZEdpTkU0ekR5akh4WERVVW04?=
 =?utf-8?B?Rms4Y0hieXpzRjhqM1RvZ0ZNbjhRcUlXTXhHcWpTaWs5U2ZkU3RJcWZzaXlw?=
 =?utf-8?B?dWZtT3QyY3hTVWtKa2t3V3ZXaVE1TEh1VldRbUdmYnBObzJQVS9lQ1JSaTB4?=
 =?utf-8?B?RDhwNGM4YURya3RZUlZpMnNsdkNncjI5WGtvK3NrU1hoZm52VWlmQnAzUjBQ?=
 =?utf-8?B?Zk1TeEZ0SWVnVmZadC8xZDBadWtIMXFpbFhLeE9ZclpRSndvOFZWNE5xRkJu?=
 =?utf-8?B?MDM2eHAxcDcvZUd4SUNXWE9rbEorK0pCdUpKSWdGQWg1aVltd2JmUHRNcFFC?=
 =?utf-8?B?ZVhxUG96ZndUZy9NVW1mdS8yMXd6bkNRV2lwN3g3ZzE2QXN2Mll5dnFMdWxz?=
 =?utf-8?B?WUpsYWlSblRnTkhnTWhUTm1WL3dBb0RmSUJiVE1TNGs0SkNHZC9rbWxtWHQw?=
 =?utf-8?B?MWVYY3h6WTI5cUdqQVorRjMwUktrZE5aNnRtM01XYjg4cW1GSWtJZTIzQVdP?=
 =?utf-8?B?eUthTUR3dGdjMmFaaHdNalQrdEp6dEZFNFFyamNTNkxad0FzczRMQVZQYWs5?=
 =?utf-8?B?RUJ1dFdWcVdKb2RvdjRpdHVJdzJyQ282QVpRQTFlL3plbHBiMG9xdUpodEsx?=
 =?utf-8?B?d1V0TXoyemthRUdRL1I0UTlKTnZxUEpUK1ArQkNzbzlLdExjOWtVZmpncEFi?=
 =?utf-8?B?SDlDdllZVGN3ZWV4TFlMTFJtNW9FMEhzOWZCTWV2alYwOWIyeXVjdmxYeHQy?=
 =?utf-8?B?OW00dENMMlFwQVZIaFYrVlgyZjBEOUdJa3Z1Z2Nja3kvSFJIRnR0Y1ZHYnpR?=
 =?utf-8?B?ZWs2dmpXMGdoZ2NsVGlqR1dOOUhQMzFscXV5VDZyMHM1bm1lSk9tWXRleEF0?=
 =?utf-8?B?S0tpNFkraTlsTktEMEpiNkt4c3YrTGttbFZOdVg1ekVLQXB2em1kYk5oeTlu?=
 =?utf-8?B?Zmc2TWVTSmpJOVlzUUFxaWVTcmNGTjBlVjJiZGs3Nzl6Y2NvQW5oTlc0TWE3?=
 =?utf-8?Q?AUqAPkGpS8AL1?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR04MB9561.eurprd04.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?bG1CeWZ4cm9UdlpxN0p3MGZWU1d0RTU3VnY0ZTgvVkpBQmt1cEZmejVpRk9F?=
 =?utf-8?B?MWZ4dVVQZHNrNGNWYlhrQ3kxbXA1aWZqVDhNTzF2a0V4QVM0NGFNR3A5UHVp?=
 =?utf-8?B?cXIvd21KZG9XZVVLMU9Lb1RKY01ndUN0cWRMVDY4SjhxZXdsNDdrbnRkOTk1?=
 =?utf-8?B?dWpsNDQrL2VnajIxUmV0VjlGN0pxU0dYUGJNdXpWRVA0N1F0L0VSYW5JRThw?=
 =?utf-8?B?azJzdEs4aHZZbjN5SHA2a3hjOXR0L3plMjFiTnFNOWpmaUIvRU5HSGt0NDNq?=
 =?utf-8?B?SmlEbHVkTUNURGNTMEhxeWhmU0puUmJnWGZscVIxclR3Qk55NmlFK0pnelhw?=
 =?utf-8?B?bFp2cjRPT3BWOGlaWCtBbEdiKzRhbk8rSkgrQzYzTFlFTEFXd2xveHpqWUtO?=
 =?utf-8?B?Yyt4ZTlyNWMvOFRpN0FYNDJiMnlsNjdSV2s2VzRjWktpVXJuVEVWcThIdUpv?=
 =?utf-8?B?SUF2Y3d2Qk5hdys5S21wS3g3K2lFS21kYTNtc0xzejd3ZkN5cHZEL2o0MWox?=
 =?utf-8?B?NEZDZDN1U3k1cUJzZ0tRQWNCZTRGbDlxT1VWdXZqTHZ4Z244c3pteGU4Rndr?=
 =?utf-8?B?bm5ZS052Y1pOYzdmV0xZOUJKbDVURFIrVHJZT1poa2Z1TnUwL3VwZS9oei9o?=
 =?utf-8?B?cldEVk5DV21GQXdXcEN5YWQ2bnlHdm0weEV3VjlzWituYm5ZZEl3S21kZG5Q?=
 =?utf-8?B?bDNPc3ZpRUZpUUdUMjZWZ1VsZEJGYldnTjNkQzU3Wk9zcUZHWGdpN293QlZZ?=
 =?utf-8?B?VTkyOC9JaEpscFU3UnRtMUlUa1RLTUcxUWFacUpXRHZpbGRvSlRHSHhwUkEr?=
 =?utf-8?B?MTRqUUlwKzdXSENlZ29Ia2dJeHpGeXIyM2JNL1Q3bFNjck5LVU11SExOVzUv?=
 =?utf-8?B?b0tMM3Q5dnl2V0RJL25ISjdjaWVaQzVFTjFEMnM1bjIzQnBLZjNoZHF3emQ0?=
 =?utf-8?B?K3A5VkF0aVRscGwxQnVrVE91VWtLR3JDeGN6Umw1WjB3bWh0NHg0Ri9mTldC?=
 =?utf-8?B?VWQ5V1ZmdGxMc1hDNm9ZMXlMcVdodnFVY1ViN1d2YXpDZW5QeUl0NEZtSjhI?=
 =?utf-8?B?VjNlREFJNkZDTVZxVTIreUp0RHdiQ1QxQlVJVHM4MFErNW1wV1RGeFZPanZE?=
 =?utf-8?B?cDU1Wklwc1JDMlVubm55NG9kd3pmazYzbUlYa0MxOCtWcE5xL3JKOUJxMUN3?=
 =?utf-8?B?aEE4bms5NHoxa2lxL2txV1M0dFBOR2orU2NJMklRQnpPbnNDc3ZSYmoyUkpi?=
 =?utf-8?B?a055bjRiZnFLazlXRUdnZjVxU3BPa01yTmxzdFI5SFZPVWVITGMwdDhXdEsr?=
 =?utf-8?B?YmdnUEVtdGdlc2s2VDVXcFFCYnZmbHVCZG1peXJXZXp1MkEvTmt5Wi9ZVHZF?=
 =?utf-8?B?WFZBTy9tTmlaSmlEWnZmWmxkRTZOZXdmMUJXc3lRekZ2c2lORGJOU0Jpd0VI?=
 =?utf-8?B?aHA2T0gyOURlVDhySzNQSy9aSTY0Ukg5b0kzckVYVjM5QnkwTjVlSGdyT2R4?=
 =?utf-8?B?WGx4R1I0Y1NSWEZjcDg0TFZER1k2cGVDZ0FKMjFpOHEveCtOWTk3bldyK0Qy?=
 =?utf-8?B?b2RKL1JhUlNIUnJHMWhSYnNkZzlsdy9nMjRTKzlMZElEVlpJQ3F4MWRLKzU0?=
 =?utf-8?B?UVU1WTN6ZVVKT3AwWERIbXIxUVJ5Y2dZSDk2Uk10endMYWZ6ejBxTE5qUzRB?=
 =?utf-8?B?aVZuOURMZnJSR2ltWnFyZ1FMdnU0SkdLaGhpWW5pVkVsVHhkTFI0am5SZWww?=
 =?utf-8?B?ZHRQNlhQOTVMbk42LzZKSU9qc2d6QmE5TUZVZTlRZjZXZkdBUTFYL3ZQRjZE?=
 =?utf-8?B?dTcxWi9rL0JFUmMxZTBsSUNyeVdSZkZpSkY2Wk5iN1V1NGMvWjBtdXBrSEJE?=
 =?utf-8?B?cHNjUUN6aFdrdUc3YlhKNW9uUHhuWG9BTjNRRlVBWXZDenNJUUFWV25RSUoz?=
 =?utf-8?B?K1UrMHJHY2M0ZWpzc0dhR2RTNGJGMlNxWlh1L1lZRml6eGlNZXR2TUU1RWIv?=
 =?utf-8?B?R3B0dm82MGd3VzM1YXBEdTRIaTRXaHRtQlBxTndhTE1DbEJpS0sybmt5MlRy?=
 =?utf-8?B?dldLU00xOTd4U3RobWhKZ0IxZ3RtTXIzY3ZiTUVyajM1TDNDcGZpNlh1bEJJ?=
 =?utf-8?B?c1Q0ZDZKUWUrQVptbG1JeHRaR2RaVDVsWlgxMDBsTEphOWR5ZHZMbEJYbjE3?=
 =?utf-8?B?Ync9PQ==?=
X-OriginatorOrg: oss.nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 57fe8b48-32f9-4eab-547f-08dd20145640
X-MS-Exchange-CrossTenant-AuthSource: DU0PR04MB9561.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2024 10:03:07.7852
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: AbQq8DMEW/lsvCuVo4oDhEpm5wRsjU2C15SLnx8FYRPmBxzg+BiDupnpU83llbGyplJskMe891iYkRI+WX4rp5Os2OOPxTEviCMAlgn9py4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR04MB9590

Hi Michal,

On 19/12/2024 10:35, Michal Orzel wrote:
>
> On 18/12/2024 15:58, Andrei Cherechesu wrote:
>>
>> Hi Michal,
>>
>> Thank you for the review.
>>
>> On 18/12/2024 16:26, Michal Orzel wrote:
>>> On 18/12/2024 11:11, Andrei Cherechesu (OSS) wrote:
>>>> From: Andrei Cherechesu 
>>>>
>>>> Introduce the SCMI-SMC layer to have some basic degree of
>>>> awareness about SCMI calls that are based on the ARM System
>>>> Control and Management Interface (SCMI) specification (DEN0056E).
>>>>
>>>> The SCMI specification includes various protocols for managing
>>>> system-level resources, such as: clocks, pins, reset, system power,
>>>> power domains, performance domains, etc. The clients are named
>>>> "SCMI agents" and the server is named "SCMI platform".
>>>>
>>>> Only support the shared-memory based transport with SMCs as
>>>> the doorbell mechanism for notifying the platform. Also, this
>>>> implementation only handles the "arm,scmi-smc" compatible,
>>>> requiring the following properties:
>>>>         - "arm,smc-id" (unique SMC ID)
>>>>         - "shmem" (one or more phandles pointing to shmem zones
>>>>         for each channel)
>>>>
>>>> The initialization is done as initcall, since we need
>>>> SMCs, and PSCI should already probe EL3 FW for SMCCC support.
>>>> If no "arm,scmi-smc" compatible node is found in the host
>>>> DT, the initialization fails silently, as it's not mandatory.
>>>> Otherwise, we get the 'arm,smc-id' DT property from the node,
>>>> to know the SCMI SMC ID we handle. The 'shmem' memory ranges
>>>> are not validated, as the SMC calls are only passed through
>>>> to EL3 FW if coming from the hardware domain.
>>>>
>>>> Create a new 'firmware' folder to keep the SCMI code separate
>>>> from the generic ARM code.
>>>>
>>>> Signed-off-by: Andrei Cherechesu 
>>>> Reviewed-by: Stefano Stabellini 
>>>> ---
>>>>  xen/arch/arm/Kconfig                         |   2 +
>>>>  xen/arch/arm/Makefile                        |   1 +
>>>>  xen/arch/arm/firmware/Kconfig                |  13 ++
>>>>  xen/arch/arm/firmware/Makefile               |   1 +
>>>>  xen/arch/arm/firmware/scmi-smc.c             | 166 +++++++++++++++++++
>>>>  xen/arch/arm/include/asm/firmware/scmi-smc.h |  46 +++++
>>>>  6 files changed, 229 insertions(+)
>>>>  create mode 100644 xen/arch/arm/firmware/Kconfig
>>>>  create mode 100644 xen/arch/arm/firmware/Makefile
>>>>  create mode 100644 xen/arch/arm/firmware/scmi-smc.c
>>>>  create mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h
>>>>
>>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>>>> index 604aba4996..23dc7162a7 100644
>>>> --- a/xen/arch/arm/Kconfig
>>>> +++ b/xen/arch/arm/Kconfig
>>>> @@ -271,6 +271,8 @@ config PARTIAL_EMULATION
>>>>           not been emulated to their complete functionality. Enabling this might
>>>>           result in unwanted/non-spec compliant behavior.
>>>>
>>>> +source "arch/arm/firmware/Kconfig"
>>>> +
>>>>  endmenu
>>>>
>>>>  menu "ARM errata workaround via the alternative framework"
>>>> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
>>>> index e4ad1ce851..8c696c2011 100644
>>>> --- a/xen/arch/arm/Makefile
>>>> +++ b/xen/arch/arm/Makefile
>>>> @@ -6,6 +6,7 @@ obj-$(CONFIG_HAS_PCI) += pci/
>>>>  ifneq ($(CONFIG_NO_PLAT),y)
>>>>  obj-y += platforms/
>>>>  endif
>>>> +obj-y += firmware/
>>>>  obj-$(CONFIG_TEE) += tee/
>>>>  obj-$(CONFIG_HAS_VPCI) += vpci.o
>>>>
>>>> diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig
>>>> new file mode 100644
>>>> index 0000000000..817da745fd
>>>> --- /dev/null
>>>> +++ b/xen/arch/arm/firmware/Kconfig
>>>> @@ -0,0 +1,13 @@
>>>> +menu "Firmware Drivers"
>>>> +
>>>> +config SCMI_SMC
>>>> +       bool "Forward SCMI over SMC calls from hwdom to EL3 firmware"
>>>> +       default y
>>>> +       help
>>>> +         This option enables basic awareness for SCMI calls using SMC as
>>>> +         doorbell mechanism and Shared Memory for transport ("arm,scmi-smc"
>>>> +         compatible only). The value of "arm,smc-id" DT property from SCMI
>>>> +         firmware node is used to trap and forward corresponding SCMI SMCs
>>>> +         to firmware running at EL3, for calls coming from the hardware domain.
>>>> +
>>>> +endmenu
>>>> diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefile
>>>> new file mode 100644
>>>> index 0000000000..a5e4542666
>>>> --- /dev/null
>>>> +++ b/xen/arch/arm/firmware/Makefile
>>>> @@ -0,0 +1 @@
>>>> +obj-$(CONFIG_SCMI_SMC) += scmi-smc.o
>>>> diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-smc.c
>>>> new file mode 100644
>>>> index 0000000000..62657308d6
>>>> --- /dev/null
>>>> +++ b/xen/arch/arm/firmware/scmi-smc.c
>>>> @@ -0,0 +1,166 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>>>> +/*
>>>> + * xen/arch/arm/firmware/scmi-smc.c
>>>> + *
>>>> + * ARM System Control and Management Interface (SCMI) over SMC
>>>> + * Generic handling layer
>>>> + *
>>>> + * Andrei Cherechesu 
>>>> + * Copyright 2024 NXP
>>>> + */
>>>> +
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +
>>>> +#include 
>>>> +#include 
>>>> +
>>>> +#define SCMI_SMC_ID_PROP   "arm,smc-id"
>>>> +
>>>> +static bool __ro_after_init scmi_support;
>>> I don't understand the need for this variable. IMO it's useless, given that in next patch you do:
>>>
>>> ...
>>> if ( scmi_is_enabled() )
>>>     return scmi_handle_smc(regs);
>>>
>>> return false;
>>>
>>> which could simply be changed to:
>>> ...
>>> return scmi_handle_smc(regs);
>>>
>>> and the variable, functions for it, etc. could be removed which would simplify the code.
>>>
>>> [...]
>> Well, I agree that the code would maybe be simpler, but
>> that means we would call `scmi_handle_smc()` both when
>> SCMI-SMC layer is initialized and when it is not.
>>
>> That then means that if `scmi_handle_smc()` returns false,
>> we won't know in the caller if the SCMI-SMC layer is not
>> initialized at all or if it is initialized, but the SMC
>> request is invalid (it does not have the SMC ID we expect).
>> Do we need to, though?
> Let me explain more:
> scmi_handle_smc() is called from within handle_sip() that can result true/false.
> If SCMI is disabled, we need to return false. If SCMI is enabled but request is
> invalid we need to return false as well. If SCMI is enabled but not initialized
> we also need to return false. 

Right, that's what I expressed my concern about too: that we're grouping up all
of these cases under a single return code of the same function. I'm fine with
that, though.

> I suggest to drop scmi_is_enabled() as exported
> function and only use scmi_handle_smc() as global like I did in my example.
> Now, this solves the part where SCMI is disabled since you have a stub returning
> false and also the part where SCMI request is invalid. However, this does not
> solve the part where SCMI is enabled but layer not initialized. To fix it, you
> simply need to check inside scmi_handle_smc() if it's initialized. That's much
> simpler than requiring to use another global function which is not nice.

Got it, my understanding was that you suggested to completely drop the `scmi_support`
variable and its associated function (`scmi_is_enabled()`), and decide internally
whether the SCMI layer is initialized based on another mechanism. That's why I suggested
`scmi_smc_id != 0` as mechanism and said that it simplifies the code, but
requires maybe some non-trivial assumptions (if `scmi_smc_id == 0` => SCMI not
initialized yet).
...

>
> Diff below:
> diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-smc.c
> index 62657308d61d..b3f34bdbb89b 100644
> --- a/xen/arch/arm/firmware/scmi-smc.c
> +++ b/xen/arch/arm/firmware/scmi-smc.c
> @@ -24,12 +24,6 @@
>  static bool __ro_after_init scmi_support;
>  static uint32_t __ro_after_init scmi_smc_id;
>
> -/* Check if SCMI layer correctly initialized and can be used. */
> -bool scmi_is_enabled(void)
> -{
> -    return scmi_support;
> -}
> -
>  /*
>   * Check if provided SMC Function Identifier matches the one known by the SCMI
>   * layer, as read from DT prop 'arm,smc-id' during initialiation.
> @@ -52,6 +46,9 @@ bool scmi_handle_smc(struct cpu_user_regs *regs)
>      uint32_t fid = (uint32_t)get_user_reg(regs, 0);
>      struct arm_smccc_res res;
>
> +    if ( !scmi_support )
> +        return false;
> +
>      if ( !scmi_is_valid_smc_id(fid) )
>          return false;
>
> diff --git a/xen/arch/arm/include/asm/firmware/scmi-smc.h b/xen/arch/arm/include/asm/firmware/scmi-smc.h
> index 57cc9eef8676..58730a8037c5 100644
> --- a/xen/arch/arm/include/asm/firmware/scmi-smc.h
> +++ b/xen/arch/arm/include/asm/firmware/scmi-smc.h
> @@ -17,16 +17,10 @@
>
>  #ifdef CONFIG_SCMI_SMC
>
> -bool scmi_is_enabled(void);
>  bool scmi_handle_smc(struct cpu_user_regs *regs);
>
>  #else
>
> -static inline bool scmi_is_enabled(void)
> -{
> -    return false;
> -}
> -
>  static inline bool scmi_handle_smc(struct cpu_user_regs *regs)
>  {
>      return false;
> diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
> index c4d225c45cd3..62d8117a120c 100644
> --- a/xen/arch/arm/vsmc.c
> +++ b/xen/arch/arm/vsmc.c
> @@ -232,10 +232,7 @@ static bool handle_sip(struct cpu_user_regs *regs)
>      if ( platform_smc(regs) )
>          return true;
>
> -    if ( scmi_is_enabled() )
> -        return scmi_handle_smc(regs);
> -
> -    return false;
> +    return scmi_handle_smc(regs);
>  }
>
>  /*

...
I understand now that your suggestions were not that restrictive :).

Thank you for the clarification!
v4 is on the way.
> ~Michal
>

Regards,
Andrei Cherechesu



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 10:46:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 10:46:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861062.1273054 (Exim 4.92)
	(envelope-from )
	id 1tOE2m-00011W-RH; Thu, 19 Dec 2024 10:46:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861062.1273054; Thu, 19 Dec 2024 10:46:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOE2m-00011P-MX; Thu, 19 Dec 2024 10:46:12 +0000
Received: by outflank-mailman (input) for mailman id 861062;
 Thu, 19 Dec 2024 10:46: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 1tOE2l-00011F-Mu
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 10:46:11 +0000
Received: from mail179-16.suw41.mandrillapp.com
 (mail179-16.suw41.mandrillapp.com [198.2.179.16])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 708206bb-bdf6-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 11:46:02 +0100 (CET)
Received: from pmta12.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1])
 by mail179-16.suw41.mandrillapp.com (Mailchimp) with ESMTP id
 4YDRzY10nhzB5prnf
 for ; Thu, 19 Dec 2024 10:46:01 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 e156fa47f682462a99a7ede69434c242; Thu, 19 Dec 2024 10:46: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: 708206bb-bdf6-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1734605161; x=1734865661;
	bh=02prROR4Wfm0ZSL770XYX4j/qzAOV4DcYYIBPMP7+T8=;
	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=SwZbz1ejMMCvTNVDABLDt2RK56733EY5J/oTGZ+TbJzmaClZ29nAOm5Q65Q/u3dPX
	 yg64Vob3DoHgoFbGxinis1yvPczE3lintkFS/Tg+YrWxK8gAZE39Kx6F1zrr1LF7Rl
	 PZ+xoU0H/i/8wiOjazfjhHAbEtxGd6RPOZXa/tZR89mL/49fd1DSSuUKlrRTIksvdw
	 8UtnKcN4zw7LOsdWD9N8wa+ZY1LupYc5SVPDyjfQoHn+sF+pA5qfoX9ehAUKf1ah7D
	 Th1GGp7ZDeSAauS9toeIM5qFhfU13m4JHu4m9HlJgWLkLX6flcmGqDHHHJ5klzNu0g
	 VFuK7X3renLqg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1734605161; x=1734865661; i=teddy.astie@vates.tech;
	bh=02prROR4Wfm0ZSL770XYX4j/qzAOV4DcYYIBPMP7+T8=;
	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=zQYO2XFe9J71bkKdXq5UmnTL7FeGUhq77qZEqFZa0QdjRVEak1ndDOhcqLlc3rqgD
	 7AC+hHCFB63U6EWAUaKFLxJMnehf5JpryWYbUnkQSG++w/704ret2VlHFSuiKyVyqe
	 U/3lJtxNtufdDNl/EV46VhE4CDfCXOvCzl2XSShWCjV6X7zUKExFSGsuPFaxDdimG0
	 VAtdO6MOE8l3iUr+9UHBCj+AJFM0DhHBVUQRRRl2bP4C5YDAbxW0I2Ar4gi+29VHkO
	 Fvg1v5DhafmlbgsvLT1tx00+3RCClHoTIuQfU5c2/DsFxW041nQauZAhb5zIX23of7
	 TnpWPGDZUt8RA==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v3]=20x86/hvm:=20Use=20constants=20for=20x86=20modes?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1734605160027
Message-Id: <2d6ce1c9-dac4-4b00-9157-07ab6987232f@vates.tech>
To: "Andrew Cooper" , Xen-devel 
Cc: "Jan Beulich" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
References:  <20241218170820.364253-1-andrew.cooper3@citrix.com>
In-Reply-To: <20241218170820.364253-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.e156fa47f682462a99a7ede69434c242?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20241219:md
Date: Thu, 19 Dec 2024 10:46:01 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello,

Le 18/12/2024 =C3=A0 18:08, Andrew Cooper a =C3=A9crit=C2=A0:
> From: Teddy Astie 
> 
> In many places of x86 HVM code, constants integer are used to indicate in=
 what mode is
> running the CPU (real, vm86, 16-bits, 32-bits, 64-bits). However, these c=
onstants are
> are written directly as integer which hides the actual meaning of these m=
odes.
> 
> This patch introduces X86_MODE_* macros and replace those occurences with=
 it.
> 
> Signed-off-by: Teddy Astie 
> Signed-off-by: Andrew Cooper 

Acked-by: Teddy Astie 

Thanks

> ---
> CC: Jan Beulich 
> CC: Roger Pau Monn=C3=A9 
> CC: Teddy Astie 
> 
> v3:
>   * Leave a comment behind explaining why these aren't all modes
>   * Fix long lines
>   * Convert more instances (svm_guest_x86_mode, hvm_latch_shinfo_size, xe=
noprof)
> ---
>   xen/arch/x86/hvm/emulate.c           | 18 ++++++++++--------
>   xen/arch/x86/hvm/hvm.c               |  4 +++-
>   xen/arch/x86/hvm/hypercall.c         | 17 +++++++++--------
>   xen/arch/x86/hvm/svm/svm.c           |  8 ++++----
>   xen/arch/x86/hvm/viridian/viridian.c |  8 ++++----
>   xen/arch/x86/hvm/vmx/vmx.c           |  9 +++++----
>   xen/arch/x86/hvm/vmx/vvmx.c          |  5 +++--
>   xen/arch/x86/include/asm/hvm/hvm.h   | 14 ++++++++++++++
>   xen/arch/x86/oprofile/xenoprof.c     |  6 +++---
>   9 files changed, 55 insertions(+), 34 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index d3006f094a69..76467b76c047 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -2433,14 +2433,15 @@ static void cf_check hvmemul_put_fpu(
>   
>           switch ( mode )
>           {
> -        case 8:
> +        case X86_MODE_64BIT:
>               fpu_ctxt->fip.addr =3D aux->ip;
>               if ( dval )
>                   fpu_ctxt->fdp.addr =3D aux->dp;
>               fpu_ctxt->x[FPU_WORD_SIZE_OFFSET] =3D 8;
>               break;
>   
> -        case 4: case 2:
> +        case X86_MODE_32BIT:
> +        case X86_MODE_16BIT:
>               fpu_ctxt->fip.offs =3D aux->ip;
>               fpu_ctxt->fip.sel  =3D aux->cs;
>               if ( dval )
> @@ -2451,7 +2452,8 @@ static void cf_check hvmemul_put_fpu(
>               fpu_ctxt->x[FPU_WORD_SIZE_OFFSET] =3D mode;
>               break;
>   
> -        case 0: case 1:
> +        case X86_MODE_REAL:
> +        case X86_MODE_VM86:
>               fpu_ctxt->fip.addr =3D aux->ip | (aux->cs << 4);
>               if ( dval )
>                   fpu_ctxt->fdp.addr =3D aux->dp | (aux->ds << 4);
> @@ -2952,11 +2954,11 @@ static const char *guest_x86_mode_to_str(int mode=
)
>   {
>       switch ( mode )
>       {
> -    case 0:  return "Real";
> -    case 1:  return "v86";
> -    case 2:  return "16bit";
> -    case 4:  return "32bit";
> -    case 8:  return "64bit";
> +    case X86_MODE_REAL:   return "Real";
> +    case X86_MODE_VM86:   return "v86";
> +    case X86_MODE_16BIT:  return "16bit";
> +    case X86_MODE_32BIT:  return "32bit";
> +    case X86_MODE_64BIT:  return "64bit";
>       default: return "Unknown";
>       }
>   }
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 74e58c653e6f..922c9b3af64d 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3974,7 +3974,9 @@ static void hvm_latch_shinfo_size(struct domain *d)
>        */
>       if ( current->domain =3D=3D d )
>       {
> -        d->arch.has_32bit_shinfo =3D (hvm_guest_x86_mode(current) !=3D 8=
);
> +        d->arch.has_32bit_shinfo =3D
> +            hvm_guest_x86_mode(current) !=3D X86_MODE_64BIT;
> +
>           /*
>            * Make sure that the timebase in the shared info structure is =
correct.
>            *
> diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
> index 81883c8d4f60..6f8dfdff4ac6 100644
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -112,23 +112,24 @@ int hvm_hypercall(struct cpu_user_regs *regs)
>   
>       switch ( mode )
>       {
> -    case 8:
> +    case X86_MODE_64BIT:
>           eax =3D regs->rax;
>           fallthrough;
> -    case 4:
> -    case 2:
> +    case X86_MODE_32BIT:
> +    case X86_MODE_16BIT:
>           if ( currd->arch.monitor.guest_request_userspace_enabled &&
> -            eax =3D=3D __HYPERVISOR_hvm_op &&
> -            (mode =3D=3D 8 ? regs->rdi : regs->ebx) =3D=3D HVMOP_guest_r=
equest_vm_event )
> +             eax =3D=3D __HYPERVISOR_hvm_op &&
> +             (mode =3D=3D X86_MODE_64BIT ? regs->rdi : regs->ebx) =3D=3D
> +             HVMOP_guest_request_vm_event )
>               break;
>   
>           if ( likely(!hvm_get_cpl(curr)) )
>               break;
>           fallthrough;
> -    default:
> +    case X86_MODE_VM86:
>           regs->rax =3D -EPERM;
>           return HVM_HCALL_completed;
> -    case 0:
> +    case X86_MODE_REAL:
>           break;
>       }
>   
> @@ -198,7 +199,7 @@ enum mc_disposition hvm_do_multicall_call(struct mc_s=
tate *state)
>   {
>       struct vcpu *curr =3D current;
>   
> -    if ( hvm_guest_x86_mode(curr) =3D=3D 8 )
> +    if ( hvm_guest_x86_mode(curr) =3D=3D X86_MODE_64BIT )
>       {
>           struct multicall_entry *call =3D &state->call;
>   
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index b8f87aa1ed08..62905c2c7acd 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -571,12 +571,12 @@ static int cf_check svm_guest_x86_mode(struct vcpu =
*v)
>       struct vmcb_struct *vmcb =3D v->arch.hvm.svm.vmcb;
>   
>       if ( unlikely(!(v->arch.hvm.guest_cr[0] & X86_CR0_PE)) )
> -        return 0;
> +        return X86_MODE_REAL;
>       if ( unlikely(guest_cpu_user_regs()->eflags & X86_EFLAGS_VM) )
> -        return 1;
> +        return X86_MODE_VM86;
>       if ( hvm_long_mode_active(v) && likely(vmcb->cs.l) )
> -        return 8;
> -    return likely(vmcb->cs.db) ? 4 : 2;
> +        return X86_MODE_64BIT;
> +    return vmcb->cs.db ? X86_MODE_32BIT : X86_MODE_16BIT;
>   }
>   
>   static void cf_check svm_cpuid_policy_changed(struct vcpu *v)
> diff --git a/xen/arch/x86/hvm/viridian/viridian.c b/xen/arch/x86/hvm/viri=
dian/viridian.c
> index 21480d9ee700..33d54e587edf 100644
> --- a/xen/arch/x86/hvm/viridian/viridian.c
> +++ b/xen/arch/x86/hvm/viridian/viridian.c
> @@ -933,13 +933,13 @@ int viridian_hypercall(struct cpu_user_regs *regs)
>   
>       switch ( mode )
>       {
> -    case 8:
> +    case X86_MODE_64BIT:
>           input.raw =3D regs->rcx;
>           input_params_gpa =3D regs->rdx;
>           output_params_gpa =3D regs->r8;
>           break;
>   
> -    case 4:
> +    case X86_MODE_32BIT:
>           input.raw =3D (regs->rdx << 32) | regs->eax;
>           input_params_gpa =3D (regs->rbx << 32) | regs->ecx;
>           output_params_gpa =3D (regs->rdi << 32) | regs->esi;
> @@ -1038,11 +1038,11 @@ int viridian_hypercall(struct cpu_user_regs *regs=
)
>   
>       switch ( mode )
>       {
> -    case 8:
> +    case X86_MODE_64BIT:
>           regs->rax =3D output.raw;
>           break;
>   
> -    case 4:
> +    case X86_MODE_32BIT:
>           regs->rdx =3D output.raw >> 32;
>           regs->rax =3D (uint32_t)output.raw;
>           break;
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index b6885d0e2764..eee1d4b47a13 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -886,14 +886,15 @@ int cf_check vmx_guest_x86_mode(struct vcpu *v)
>       unsigned long cs_ar_bytes;
>   
>       if ( unlikely(!(v->arch.hvm.guest_cr[0] & X86_CR0_PE)) )
> -        return 0;
> +        return X86_MODE_REAL;
>       if ( unlikely(guest_cpu_user_regs()->eflags & X86_EFLAGS_VM) )
> -        return 1;
> +        return X86_MODE_VM86;
>       __vmread(GUEST_CS_AR_BYTES, &cs_ar_bytes);
>       if ( hvm_long_mode_active(v) &&
>            likely(cs_ar_bytes & X86_SEG_AR_CS_LM_ACTIVE) )
> -        return 8;
> -    return (likely(cs_ar_bytes & X86_SEG_AR_DEF_OP_SIZE) ? 4 : 2);
> +        return X86_MODE_64BIT;
> +    return (likely(cs_ar_bytes & X86_SEG_AR_DEF_OP_SIZE)
> +            ? X86_MODE_32BIT : X86_MODE_16BIT);
>   }
>   
>   static void vmx_save_dr(struct vcpu *v)
> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
> index 78135ca23be8..cf47d61b1473 100644
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -411,7 +411,7 @@ static int decode_vmx_inst(struct cpu_user_regs *regs=
,
>       }
>       else
>       {
> -        bool mode_64bit =3D (vmx_guest_x86_mode(v) =3D=3D 8);
> +        bool mode_64bit =3D vmx_guest_x86_mode(v) =3D=3D X86_MODE_64BIT;
>   
>           decode->type =3D VMX_INST_MEMREG_TYPE_MEMORY;
>   
> @@ -2073,7 +2073,8 @@ int nvmx_handle_vmx_insn(struct cpu_user_regs *regs=
, unsigned int exit_reason)
>   
>       if ( !(curr->arch.hvm.guest_cr[4] & X86_CR4_VMXE) ||
>            !nestedhvm_enabled(curr->domain) ||
> -         (vmx_guest_x86_mode(curr) < (hvm_long_mode_active(curr) ? 8 : 2=
)) ||
> +         (vmx_guest_x86_mode(curr) <
> +          (hvm_long_mode_active(curr) ? X86_MODE_64BIT : X86_MODE_16BIT)=
) ||
>            (exit_reason !=3D EXIT_REASON_VMXON && !nvmx_vcpu_in_vmx(curr)=
) )
>       {
>           hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC);
> diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/as=
m/hvm/hvm.h
> index 02de18c7d4a8..124906a548da 100644
> --- a/xen/arch/x86/include/asm/hvm/hvm.h
> +++ b/xen/arch/x86/include/asm/hvm/hvm.h
> @@ -26,6 +26,20 @@ extern bool opt_hvm_fep;
>   #define opt_hvm_fep 0
>   #endif
>   
> +/*
> + * Results for hvm_guest_x86_mode().
> + *
> + * Note, some callers depend on the order of these constants.
> + *
> + * TODO: Rework this helper to avoid implying mixing the architectural
> + * concepts of mode and operand size.
> + */
> +#define X86_MODE_REAL  0
> +#define X86_MODE_VM86  1
> +#define X86_MODE_16BIT 2
> +#define X86_MODE_32BIT 4
> +#define X86_MODE_64BIT 8
> +
>   /* Interrupt acknowledgement sources. */
>   enum hvm_intsrc {
>       hvm_intsrc_none,
> diff --git a/xen/arch/x86/oprofile/xenoprof.c b/xen/arch/x86/oprofile/xen=
oprof.c
> index 247a0deca822..7f2525bfb4d6 100644
> --- a/xen/arch/x86/oprofile/xenoprof.c
> +++ b/xen/arch/x86/oprofile/xenoprof.c
> @@ -86,11 +86,11 @@ int xenoprofile_get_mode(struct vcpu *curr, const str=
uct cpu_user_regs *regs)
>   
>       switch ( hvm_guest_x86_mode(curr) )
>       {
> -    case 0: /* real mode */
> +    case X86_MODE_REAL:
>           return 1;
> -    case 1: /* vm86 mode */
> +    case X86_MODE_VM86:
>           return 0;
> -    default:
> +    default: /* 16BIT | 32BIT | 64BIT */
>           return hvm_get_cpl(curr) !=3D 3;
>       }
>   }
> 
> base-commit: 826a9eb072d449cb777d71f52923e6f5f20cefbe

Teddy


 | Vates 

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 10:57:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 10:57:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861072.1273062 (Exim 4.92)
	(envelope-from )
	id 1tOEDB-0002lA-NR; Thu, 19 Dec 2024 10:56:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861072.1273062; Thu, 19 Dec 2024 10:56: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 1tOEDB-0002l3-Kd; Thu, 19 Dec 2024 10:56:57 +0000
Received: by outflank-mailman (input) for mailman id 861072;
 Thu, 19 Dec 2024 10:56: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 1tOEDA-0002kx-Fs
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 10:56:56 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on2062c.outbound.protection.outlook.com
 [2a01:111:f403:2417::62c])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f55cb79f-bdf7-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 11:56:54 +0100 (CET)
Received: from MW4PR04CA0238.namprd04.prod.outlook.com (2603:10b6:303:87::33)
 by BY5PR12MB4276.namprd12.prod.outlook.com (2603:10b6:a03:20f::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8251.19; Thu, 19 Dec
 2024 10:56:48 +0000
Received: from SJ5PEPF000001F4.namprd05.prod.outlook.com
 (2603:10b6:303:87:cafe::15) by MW4PR04CA0238.outlook.office365.com
 (2603:10b6:303:87::33) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.25 via Frontend Transport; Thu,
 19 Dec 2024 10:56:48 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 SJ5PEPF000001F4.mail.protection.outlook.com (10.167.242.72) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Thu, 19 Dec 2024 10:56:47 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 19 Dec
 2024 04:56:46 -0600
Received: from xcbayankuma40.xilinx.com (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via
 Frontend Transport; Thu, 19 Dec 2024 04:56: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: f55cb79f-bdf7-11ef-a0d7-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=xupPMTkmreP5rxAsVhb4AeTlY6s1gNhaMFDa0ClPwM3caUI1S6z9vnC5MjecVEtstPJvmM6SJQHYmiyVw8sFiS2F8AEd1KCadDv6SCLi0NK30q2sEpYEY9tp0VJJfy1e60Kgi8GDT81kiUVwaFqlCB9p9esFdMXMcJrXKz7CR4jkZIPj6XdVRkkAkqZxOUHW2qRy04YLTnegXv/zo8M9HZgBubqYdYItkuj74XXkmW0QUR7Bs/hO64NCzIv2Vi7s8L+m5Blo1toM31nXSLaI53+YQKFML+9z5nAgSZzaCB2szy0p6jQ9eHiRPv8WtrhwZSlXmA1D88xJlp3tPZ4QSg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=UHxm5uHc+E/fYv0O9Kf7RJsADfa13CFCzAn9OV8Y1NI=;
 b=xFBduoTa3NTclCZZnVw3iJ9WMX/+fMDDP+X6W0pRGyfm7c8RHv1IJAcNticaebSXSH4VSm1Cby4dbw+UNL66gESKHRgZirMFq7b8AJcKxIHyrGpgruzn2jlJdXSAun50Yx2raZXfZLykhkHu4W2e8G9DkU0gR0vnoI7OorKSxX+QJBLO+k1r2PPFXD9zZDt5qEW2Vdb2o9tc/upWmo6qynDNlExre3/oQ/PRBEMDC25xeWcz0KIjXqrWE8d8UOMB8HGzGDbUzQ5tjhrVpm4QXKQxNmjtJYPY/nkGI5h5fEP3SfL3+O0wVWL8eHijzCOwO2jc7Vb+6kC2wqzEE5afUg==
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=UHxm5uHc+E/fYv0O9Kf7RJsADfa13CFCzAn9OV8Y1NI=;
 b=uW7URXeVgpdYQoFg/llVtkPiCK+PUO9sat22HcIkxChsPWvuDO8Z4r4TzgjvskAdBwqkz/j+jVlJH51OQE41+XE0OesEDCOFawGQ1bOvMaUk5rpuWX5BcPqrfcXoT6JhukOsNGBNNgr/KHhaGcjnwDy/99Kb113Yrz/g979mldA=
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=SATLEXMB03.amd.com; pr=C
From: Ayan Kumar Halder 
To: 
CC: Michal Orzel , Stefano Stabellini
	, Bertrand Marquis , "Ayan
 Kumar Halder" , Artem Mygaiev
	, Jason Andryuk 
Subject: [PATCH v3] docs: fusa: Add dom0less domain configuration requirements
Date: Thu, 19 Dec 2024 10:56:40 +0000
Message-ID: <20241219105640.3294591-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
Received-SPF: None (SATLEXMB03.amd.com: ayan.kumar.halder@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F4:EE_|BY5PR12MB4276:EE_
X-MS-Office365-Filtering-Correlation-Id: 7721285f-fbee-4560-3393-08dd201bd5cd
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?RfzB07/iBCULhiqzhghkJIohKTZyGU/Nbxu7qXOnpYFFGkKARCSzjKNbuUua?=
 =?us-ascii?Q?KR+KiTYzWzU/qrKAAGyW/PN/3s//+wiVINpDBKUI7EgNom+EpAt3D+kPhvBe?=
 =?us-ascii?Q?m+yMA8E+BFkmpmoiJsKoKZrdoZM1pR3cD8dH5jpswyLGVQxjI6a0+boLO/y+?=
 =?us-ascii?Q?5osT2mB6WhJhog/S7MJaIa0clO6Csq5Fw7fdP27vvrZey+bIPrQzVuN5rg8I?=
 =?us-ascii?Q?agUlwL1bq6XZ1LdaDnqtei/zOd7dz+W262zz2R3H6vPq5aRKR9Vymg16Flqp?=
 =?us-ascii?Q?TBBClyic5GRRnmfqy4PeI7LrEVWvCz0LUdLrpH1IYRACKZr7YHmtj8qTXDQ+?=
 =?us-ascii?Q?gw3SKkmZevX49yPk0IJyQfvErmhDMuSmj+I0MTOYw72OjI7qmt2WdobEAU4q?=
 =?us-ascii?Q?DvGrbiiB1zo3pWRbJcBJngER4UgI0FOqZHL5Xoh2LHB6JSFC+LlvELeerp7W?=
 =?us-ascii?Q?MmObhDcfZ9I26spbdBvPtJ5Omx/owM/ALSXR9Kt4M25NVp4kc+1Jv+hlC6cc?=
 =?us-ascii?Q?iZNSE+i/Hout1BclIiDx3MsJjXYbrf93ytVJv4HT2hWYHm264FCRRDr7WGL+?=
 =?us-ascii?Q?VnXJjCKiebvZtfbg9N36TRUWErp5OU1vwkqYXS3NDSXvtaW+TSSdDhHddgT3?=
 =?us-ascii?Q?wYV1R1NPyc4akwB2/1aKNK7O5xDnCAAEdQxfvK0Ay7klrFLujJoD/OPDkvhF?=
 =?us-ascii?Q?fAGWiD6lWw0d3yIzFJeNHgg+txIamIRN2gOa9C+YkJO6ML/OTeQ1jCARRJeS?=
 =?us-ascii?Q?vtF4GNjVCclj3xeqyR1FbJzmajXsFeOlEVHJomfPj+JGJwTAJzYe6lmOYrT5?=
 =?us-ascii?Q?iFqwMhKsZq7rb5jax9IsBJNBISR1CbftK2f4rpFf8LpGdenh/Q40VXQ+As++?=
 =?us-ascii?Q?R4JYXyfaxTDm6nYaKsDkOmwjUpoFt80vG/x1GY/GU1qqSgAPrtHp54yU4Kdb?=
 =?us-ascii?Q?iugKrKVYMWE5VM3Atx32y3nCADjdC2FuiMjmW1sC6W/p8+or7/w4dTJCj0WP?=
 =?us-ascii?Q?5QtlLBS9xbwR2ahFE0URWVduIjAmiNGO4QzJ2VaBG2JKIqHdoF6zegA0BKkM?=
 =?us-ascii?Q?B+lBpUzj86NFBIbHU8Rr7TQoiGqxJzUM3KKs7OnNdMicsXUCMtCcaYd/TIDG?=
 =?us-ascii?Q?cM9Us28y7eY73JvxqWGs8Ft+IJc6DWZS6Y82D7ToM5K9mhqM2NblSCbhDzFQ?=
 =?us-ascii?Q?GddPUIKY8SmZfY/o8QdPWvs2Fs2DN/+ODPZL/zWlT97q6TfIIO9k/549YGqb?=
 =?us-ascii?Q?ctqNw4dilj4W8TS/nu6C01DteCsDFOROCEbrKD3c/5GuBdsiLI3ycIAN8Hm8?=
 =?us-ascii?Q?wBhN/6E8O5Ckct18Etm97niYVVKbe8XvyRbVLFGFbRNKeZtTU/6/7MKnvApx?=
 =?us-ascii?Q?y637j1ebgbI+BvKFYDpeHxEEw+HDucXwDwz09U75dICt9TeG4Jt4alBDBPcH?=
 =?us-ascii?Q?wiYL2hiDZeI/VFLOWLCTtnYAGq95mUu+?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2024 10:56:47.8116
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7721285f-fbee-4560-3393-08dd201bd5cd
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SJ5PEPF000001F4.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4276

From: Michal Orzel 

Add requirements for dom0less domain creation.

Signed-off-by: Michal Orzel 
Signed-off-by: Ayan Kumar Halder 
---
Changes from -

v1 - 1. As the dom0less domain creation requirements specifies the dt properties
for creating domains, it has been moved to product requirements. Product
requirements define the interface Xen exposes to other domains.

2. For the requirements which introduces new terms (like grant table, etc), I
have provided the definition as part of the comments.

3. Introduced new market requirements to specify that Xen can assign iomem and
irqs to domains.

4. The design requirements will be added later.

v2 - 1. Rephrased the requirements as suggested.

2. Split the product requirements into arm64 specific and common.

3. The arm64 specific requirements have arm64_ prefixed to their tag names.

4. Grant table requirements have been dropped for now.

5. Added a market requirement to denote that Xen can support multiple schedulers.

6. Updated index.rst as we have a new file ie product-reqs/reqs.rst.

 docs/fusa/reqs/index.rst                   |   1 +
 docs/fusa/reqs/market-reqs/reqs.rst        |  31 ++++
 docs/fusa/reqs/product-reqs/arm64/reqs.rst | 128 +++++++++++++++-
 docs/fusa/reqs/product-reqs/reqs.rst       | 163 +++++++++++++++++++++
 4 files changed, 321 insertions(+), 2 deletions(-)
 create mode 100644 docs/fusa/reqs/product-reqs/reqs.rst

diff --git a/docs/fusa/reqs/index.rst b/docs/fusa/reqs/index.rst
index 8a4dae6fb2..1088a51d52 100644
--- a/docs/fusa/reqs/index.rst
+++ b/docs/fusa/reqs/index.rst
@@ -8,6 +8,7 @@ Requirements documentation
 
    intro
    market-reqs/reqs
+   product-reqs/reqs
    product-reqs/arm64/reqs
    design-reqs/arm64/generic-timer
    design-reqs/arm64/sbsa-uart
diff --git a/docs/fusa/reqs/market-reqs/reqs.rst b/docs/fusa/reqs/market-reqs/reqs.rst
index f456788d96..39b2714237 100644
--- a/docs/fusa/reqs/market-reqs/reqs.rst
+++ b/docs/fusa/reqs/market-reqs/reqs.rst
@@ -47,3 +47,34 @@ Comments:
 
 Needs:
  - XenProd
+
+Static VM definition
+--------------------
+
+`XenMkt~static_vm_definition~1`
+
+Description:
+Xen shall support assigning peripherals to various domains.
+
+Rationale:
+
+Comments:
+Peripheral implies an iomem (input output memory) and/or interrupts.
+
+Needs:
+ - XenProd
+
+Multiple schedulers
+-------------------
+
+`XenMkt~multiple_schedulers~1`
+
+Description:
+Xen shall provide different ways of scheduling virtual cpus onto physical cpus.
+
+Rationale:
+
+Comments:
+
+Needs:
+ - XenProd
diff --git a/docs/fusa/reqs/product-reqs/arm64/reqs.rst b/docs/fusa/reqs/product-reqs/arm64/reqs.rst
index db91c47a02..c8fee0e49f 100644
--- a/docs/fusa/reqs/product-reqs/arm64/reqs.rst
+++ b/docs/fusa/reqs/product-reqs/arm64/reqs.rst
@@ -6,7 +6,7 @@ Domain Creation And Runtime
 Emulated Timer
 --------------
 
-`XenProd~emulated_timer~1`
+`XenProd~arm64_emulated_timer~1`
 
 Description:
 Xen shall grant access to "Arm Generic Timer" for the domains.
@@ -25,7 +25,7 @@ Needs:
 Emulated UART
 -------------
 
-`XenProd~emulated_uart~1`
+`XenProd~arm64_emulated_uart~1`
 
 Description:
 Xen shall provide an "Arm SBSA UART" compliant device to the domains.
@@ -40,3 +40,127 @@ Covers:
 
 Needs:
  - XenSwdgn
+
+Linux kernel image
+------------------
+
+`XenProd~arm64_linux_kernel_image~1`
+
+Description:
+Xen shall create a domain with a binary containing header compliant with Arm64
+Linux kernel image [1].
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Gzip Linux kernel image
+-----------------------
+
+`XenProd~arm64_linux_kernel_gzip_image~1`
+
+Description:
+Xen shall create a domain with a Gzip compressed binary containing header
+compliant with Arm64 Linux kernel image [1].
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Kernel with uImage header
+-------------------------
+
+`XenProd~arm64_kernel_uimage~1`
+
+Description:
+Xen shall create a domain with a binary containing uImage header [2].
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Gzip kernel with uImage header
+------------------------------
+
+`XenProd~arm64_gzip_kernel_uimage~1`
+
+Description:
+Xen shall create a domain with a Gzip compressed binary containing uImage
+header [2].
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+SPIs
+----
+
+`XenProd~arm64_spis~1`
+
+Description:
+Xen shall create a domain with a number of shared peripheral interrupts as
+specified in the device tree.
+
+Rationale:
+
+Comments:
+Device tree is a data structure and language for describing hardware which is
+readable by an operating system [3].
+A shared peripheral interrupt is a peripheral interrupt that the Arm Generic
+Interrupt Controller's Distributor interface can route to any combination of
+processors [4].
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+ - `XenMkt~static_vm_definition~1`
+
+Needs:
+ - XenSwdgn
+
+Virtual PL011
+-------------
+
+`XenProd~arm64_virtual_pl011~1`
+
+Description:
+Xen shall provide an "Arm PL011 UART" compliant device to the domains.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+ - `XenMkt~provide_console_domains~1`
+
+Needs:
+ - XenSwdgn
+
+| [1] https://github.com/torvalds/linux/blob/master/Documentation/arch/arm64/booting.rst
+| [2] https://source.denx.de/u-boot/u-boot/-/blob/master/include/image.h#L315
+| [3] https://docs.kernel.org/devicetree/usage-model.html
+| [4] https://developer.arm.com/documentation/ihi0048/a/Introduction/Terminology/Interrupt-types?lang=en
diff --git a/docs/fusa/reqs/product-reqs/reqs.rst b/docs/fusa/reqs/product-reqs/reqs.rst
new file mode 100644
index 0000000000..9257fec713
--- /dev/null
+++ b/docs/fusa/reqs/product-reqs/reqs.rst
@@ -0,0 +1,163 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Domain Creation And Runtime
+===========================
+
+Kernel command line arguments
+-----------------------------
+
+`XenProd~kernel_cmd_line_args~1`
+
+Description:
+Xen shall pass kernel command line arguments to a domain via a device tree.
+
+Rationale:
+
+Comments:
+Device tree is a data structure and language for describing hardware which is
+readable by an operating system [1].
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Ramdisk
+-------
+
+`XenProd~ramdisk~1`
+
+Description:
+Xen shall provide the address of an initial ramdisk to a domain via a device
+tree.
+
+Rationale:
+
+Comments:
+The initial ramdisk is contained in memory.
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Memory
+------
+
+`XenProd~memory~1`
+
+Description:
+Xen shall create a domain with an amount of memory specified in a device tree.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+vCPUs
+-----
+
+`XenProd~vcpus~1`
+
+Description:
+A domain shall have a configurable number of virtual CPUs (1 to XX).
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+
+Needs:
+ - XenSwdgn
+
+Credit2 CPU pool scheduler
+--------------------------
+
+`XenProd~credit2_cpu_pool_scheduler~1`
+
+Description:
+Xen shall have a scheduler where a physical cpu can be shared between more than
+one virtual cpu.
+
+Rationale:
+
+Comments:
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+ - `XenMkt~multiple_schedulers~1`
+
+Needs:
+ - XenSwdgn
+
+NUL CPU pool scheduler
+----------------------
+
+`XenProd~nul_cpu_pool_scheduler~1`
+
+Description:
+Xen shall have a scheduler where the virtual cpu will be always running on its
+dedicated physical cpu.
+
+Rationale:
+
+Comments:
+A NUL CPU pool scheduler maps a virtual cpu to a unique physical cpu.
+
+Covers:
+ - `XenMkt~run_arm64_domains~1`
+ - `XenMkt~multiple_schedulers~1`
+
+Needs:
+ - XenSwdgn
+
+Assign iomem
+------------
+
+`XenProd~assign_iomem~1`
+
+Description:
+Xen shall support assigning iomem to a domain.
+
+Rationale:
+
+Comments:
+
+Rationale:
+
+Covers:
+ - `XenMkt~static_vm_definition~1`
+
+Needs:
+ - XenSwdgn
+
+Forward interrupts
+------------------
+
+`XenProd~forward_irqs~1`
+
+Description:
+Xen shall support forwarding interrupts to a domain.
+
+Rationale:
+
+Comments:
+
+Rationale:
+
+Covers:
+ - `XenMkt~static_vm_definition~1`
+
+Needs:
+ - XenSwdgn
+
+| [1] https://docs.kernel.org/devicetree/usage-model.html
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 11:13:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 11:13:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861089.1273074 (Exim 4.92)
	(envelope-from )
	id 1tOETJ-0005fD-6n; Thu, 19 Dec 2024 11:13:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861089.1273074; Thu, 19 Dec 2024 11:13:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOETJ-0005f6-2U; Thu, 19 Dec 2024 11:13:37 +0000
Received: by outflank-mailman (input) for mailman id 861089;
 Thu, 19 Dec 2024 11:13: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 1tOETH-0005f0-Nw
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 11:13:35 +0000
Received: from fforwardh-b1-smtp.messagingengine.com
 (fforwardh-b1-smtp.messagingengine.com [202.12.124.196])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 484d0bf8-bdfa-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 12:13:33 +0100 (CET)
Received: from phl-compute-04.internal (phl-compute-04.phl.internal
 [10.202.2.44])
 by mailfforwardh.stl.internal (Postfix) with ESMTP id AD85F174015E;
 Thu, 19 Dec 2024 06:13:31 -0500 (EST)
Received: from phl-frontend-02 ([10.202.2.161])
 by phl-compute-04.internal (MEProxy); Thu, 19 Dec 2024 06:13:31 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 19 Dec 2024 06:13: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: 484d0bf8-bdfa-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	: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=
	1734606811; x=1734693211; bh=EscSh3aArqHkcMCznEYltHV1sY9EFHqbKJX
	WGqeYTLE=; b=v8w0q5PBDhAbHZdIuL+KVlfajAoXlEqWmo/tOZsj1QSN/C0itCE
	8ufdqFu3S5OTQJDrwFD7GGo2K5PHgRiXOZb0wMkL+6yVGWz313etEqwMr6im+Rcc
	F0S2dTVAlY/QxArSM0vkFmdxcTgroJJ2knbUYNB+MZ1+aLYlRFVA03zZN4YqRgbL
	8WgLq+xMpC5wOCVojH5GFmtTzTEmky6WUOlDcuG2KODnrC8bI3HuI4kwCq3y2/q2
	xLKnKE8ID9UEV24AblyxAYgAvClylBooThP+cTn1Z29h8lXdEwMsaR3yvbD5KU0j
	AQQ155iV/MRKi0jmYyYJYThIa+zz6iQv14A==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddruddttddgvdegucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhephffvvefufffkofgggfestdekredtredttdenucfh
    rhhomhepufgvrhhgihihucfmihgsrhhikhcuoefuvghrghhihigpmfhisghrihhksegvph
    grmhdrtghomheqnecuggftrfgrthhtvghrnhepffffvdeifeeijefhheefuedvvedtheff
    jeeiveehgfettedvgedujefgudejgedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrg
    hrrghmpehmrghilhhfrhhomhepshgrkhhisgesuggrrhhkshhtrghrrdhsihhtvgdpnhgs
    pghrtghpthhtohepledpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepgigvnhdqug
    gvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohepshgv
    rhhgihihpghkihgsrhhikhesvghprghmrdgtohhmpdhrtghpthhtohepjhgsvghulhhitg
    hhsehsuhhsvgdrtghomhdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghi
    thhrihigrdgtohhmpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhrihigrdgtoh
    hmpdhrtghpthhtoheprghnthhhohhnhidrphgvrhgrrhgusehvrghtvghsrdhtvggthhdp
    rhgtphhtthhopehmihgthhgrlhdrohhriigvlhesrghmugdrtghomhdprhgtphhtthhope
    hjuhhlihgvnhesgigvnhdrohhrghdprhgtphhtthhopehsshhtrggsvghllhhinhhisehk
    vghrnhgvlhdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i5d798b77:Fastmail
From: Sergiy Kibrik 
To: xen-devel@lists.xenproject.org
Cc: Sergiy Kibrik ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [XEN PATCH] ioreq: fix check for CONFIG_ARCH_VCPU_IOREQ_COMPLETION
Date: Thu, 19 Dec 2024 13:13:26 +0200
Message-Id: <20241219111326.3031000-1-Sergiy_Kibrik@epam.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

It should be CONFIG_ARCH_VCPU_IOREQ_COMPLETION (as in Kconfig) and not
misspelled CONFIG_VCPU_ARCH_IOREQ_COMPLETION.
Bug introduced by:

979cfdd3e5 ioreq: do not build arch_vcpu_ioreq_completion() for non-VMX configurations

Signed-off-by: Sergiy Kibrik 
---
 xen/arch/x86/hvm/ioreq.c | 2 +-
 xen/include/xen/ioreq.h  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 5c3d0c69aa..d6491df8e7 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -29,7 +29,7 @@ bool arch_ioreq_complete_mmio(void)
     return handle_mmio();
 }
 
-#ifdef CONFIG_VCPU_ARCH_IOREQ_COMPLETION
+#ifdef CONFIG_ARCH_VCPU_IOREQ_COMPLETION
 bool arch_vcpu_ioreq_completion(enum vio_completion completion)
 {
     switch ( completion )
diff --git a/xen/include/xen/ioreq.h b/xen/include/xen/ioreq.h
index 29a17e8ff5..4f3c6b598d 100644
--- a/xen/include/xen/ioreq.h
+++ b/xen/include/xen/ioreq.h
@@ -112,7 +112,7 @@ int ioreq_server_dm_op(struct xen_dm_op *op, struct domain *d, bool *const_op);
 
 bool arch_ioreq_complete_mmio(void);
 
-#ifdef CONFIG_VCPU_ARCH_IOREQ_COMPLETION
+#ifdef CONFIG_ARCH_VCPU_IOREQ_COMPLETION
 bool arch_vcpu_ioreq_completion(enum vio_completion completion);
 #else
 static inline bool arch_vcpu_ioreq_completion(enum vio_completion completion)
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 11:18:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 11:18:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861098.1273083 (Exim 4.92)
	(envelope-from )
	id 1tOEYD-0006Fa-MN; Thu, 19 Dec 2024 11:18:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861098.1273083; Thu, 19 Dec 2024 11:18: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 1tOEYD-0006FT-Jj; Thu, 19 Dec 2024 11:18:41 +0000
Received: by outflank-mailman (input) for mailman id 861098;
 Thu, 19 Dec 2024 11:18: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 1tOEYB-0006FN-IS
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 11:18:39 +0000
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com
 [2a00:1450:4864:20::232])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fed494e9-bdfa-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 12:18:38 +0100 (CET)
Received: by mail-lj1-x232.google.com with SMTP id
 38308e7fff4ca-3011c7b39c7so8827421fa.1
 for ; Thu, 19 Dec 2024 03:18:38 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-5422360072fsm146401e87.102.2024.12.19.03.18.36
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 19 Dec 2024 03:18: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: fed494e9-bdfa-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734607117; x=1735211917; 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=49eg8s+krDtf0/1GEbBKxKE4dU89XCIcLayO0cwZhoM=;
        b=lasjnLTdmVN5LaMcQfDPjAiXODUavUVfW75HJzzlc6AYYiEra/AoGj1T9feYIHE3zC
         b407hsZVT2/T8SxrP6HhPHd/cUXn+YiVwsY322jDRmkiha+dK6Xt8qNebVPsnpJsOGi2
         gwS4T9BGP9cAoM0wPzJZRRc/iWB3SblabCWIrMHQmqZ8xPcX3vYy1s2uB3Fx/e9qXwYT
         CIrnUF/Iq9BO4Xoff+tjBk9cIVLCc7kPjVkdJI8lNukgP9f0VQqNHGyDUfiRoXItfGpb
         FgQBJdc5yiU3zzxWOL2xpGEZ5oFwUUo1FGfhtakRY1+2I9cFEMEiP78GZi/w/WjlKueT
         vpXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734607117; x=1735211917;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=49eg8s+krDtf0/1GEbBKxKE4dU89XCIcLayO0cwZhoM=;
        b=O5wdLcL9dp9kjRaSAiASSZFHbway48BgsfcwexCAyHwUryzYBEV6lFoSGy3nFh5yoL
         grW2Ey5wjZv593tm5reOjNeY6GTo6oRnXuYqEZUHZFuEbzDx2gT19/l06iSoAJI+Bgfq
         pCOR0AhsM55v8Q0WQAtFVBBeirA1QwttsB6fsUGq0REjZqli0tVOeoGYecHg9S/94PaP
         61ACYfG1PSWxFMSVRg/OAIfyV6UMpOP+E9MTKy7OOcKPx4Zgj47jVMlh7cj04ILE2Iea
         /xBgguxJvPXtJqGOK5TXWYnzuqsqE8dD21ZddegCbXIFOwFCr9Sz5Ja41dNtEbQUJB0R
         qzOw==
X-Gm-Message-State: AOJu0Yygz1AYKPijGFZNm/Uyybwsli6yY1WAOqwAQQn3axlO9oGxz7dx
	dslh1iGV6fIsviX7yr/XFWsEuSKGxAGgB8VCZsbewEhJojSoGucVdle+XxuG
X-Gm-Gg: ASbGncsY2dj29C5ieQch+Egai4R0Vn8+t04Kjs6FT15Bdjzu7gmRdW9b+Op83jIs0lq
	dU57o9WTbsfl+njLWLrA262fvrcEzEfXB/+PafisFYWtG9CNbLh8riNgjlCSuR4ePdnyv25sI7D
	uRKeIVta7yPnQwtj38n+Wdr/52p0b4i61q0B1Fy3LmFkYSowk+s7LhmJAGzqDJzSVRWSvNJ/NoE
	M4jmrkVEFlQmcXej3r5S0Xs2RQBPHvlNgi/U/9QHewasrUUBLDBqbMp2w==
X-Google-Smtp-Source: AGHT+IF4H7aeIiQQFZI0LvZ40oqVUe5ZLv8MMIFtsNxrCuny68UETI8s5sCNL3eTzqbGUu8i6zasqw==
X-Received: by 2002:a05:6512:e98:b0:540:1dca:52d3 with SMTP id 2adb3069b0e04-541e674c8b4mr2116649e87.29.1734607117080;
        Thu, 19 Dec 2024 03:18:37 -0800 (PST)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich ,
	Oleksii Kurochko ,
	Andrew Cooper ,
	Doug Goldstein ,
	Stefano Stabellini 
Subject: [PATCH] automation: pin down CONFIG_QEMU_PLATFORM for RISC-V's randconfig job
Date: Thu, 19 Dec 2024 12:18:31 +0100
Message-ID: <20241219111831.31736-1-oleksii.kurochko@gmail.com>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Except setting CONFIG_QEMU_PLATFORM=y in tiny64_defconfig,
CONFIG_QEMU_PLATFORM should be fixed for RISC-V's randconfig job.
Otherwise, an expected compilation error for RISC-V's randconfig job
will occur since clean_and_invalidate_dcache_va_range() and
clean_dcache_va_range() are currently implemented only for the QEMU
platform.

Additionally, sort the EXTRA_FIXED_RANDCONFIG list alphabetically.

Reported-by: Andrew Cooper 
Fixes: f92e2709bd ("xen/riscv: implement data and instruction cache operations")
Signed-off-by: Oleksii Kurochko 
---
 automation/gitlab-ci/build.yaml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index 1ca6764225..1b884cc81c 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -732,9 +732,10 @@ debian-12-riscv64-gcc:
       CONFIG_COVERAGE=n
       CONFIG_EXPERT=y
       CONFIG_GRANT_TABLE=n
+      CONFIG_LIVEPATCH=n
       CONFIG_MEM_ACCESS=n
       CONFIG_PERF_COUNTERS=n
-      CONFIG_LIVEPATCH=n
+      CONFIG_QEMU_PLATFORM=y
       CONFIG_XSM=n
 
 debian-12-riscv64-gcc-randconfig:
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 11:23:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 11:23:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861108.1273093 (Exim 4.92)
	(envelope-from )
	id 1tOEd1-0007yk-7z; Thu, 19 Dec 2024 11:23:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861108.1273093; Thu, 19 Dec 2024 11:23: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 1tOEd1-0007yd-4T; Thu, 19 Dec 2024 11:23:39 +0000
Received: by outflank-mailman (input) for mailman id 861108;
 Thu, 19 Dec 2024 11:23:38 +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 1tOEd0-0007yX-0t
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 11:23:38 +0000
Received: from DB3PR0202CU003.outbound.protection.outlook.com
 (mail-northeuropeazlp170110001.outbound.protection.outlook.com
 [2a01:111:f403:c200::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id af7940d9-bdfb-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 12:23:35 +0100 (CET)
Received: from PA4SPRMB0023.eurprd04.prod.outlook.com (2603:10a6:102:268::8)
 by PAWPR04MB9936.eurprd04.prod.outlook.com (2603:10a6:102:38b::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.15; Thu, 19 Dec
 2024 11:23:33 +0000
Received: from PA4SPRMB0023.eurprd04.prod.outlook.com
 ([fe80::fd16:4665:bad7:33ce]) by PA4SPRMB0023.eurprd04.prod.outlook.com
 ([fe80::fd16:4665:bad7:33ce%4]) with mapi id 15.20.8251.015; Thu, 19 Dec 2024
 11:23: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: af7940d9-bdfb-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ORhnqPVO5omPS9RZPbxSZB6JbseKltWhonR8uS8KSzhIF5BdH965/E8HUa8OVPChnv17Ea7DAz6kfsGAufazfV1EpghmWheu/x43eutCSIU3+h0hxScgZQkfs6mNO892iv/HWpLSj3r4fycArEKOzUlclj4330SUO2p4FuX+TAVtoXirqPNFvmHWjnv0S/hPwjMsZfC3dXU+yFVXwAWUCtHhFhdqjHRAkHg4te0POToKIwcYSuGOfHrl8x3HWY9wowgIcOsxLZZpOgdy+O0z5LjPUwaknnDUwbkb1QwYldqzSnmleqNj4m+Kn5PdD03oAZiF6VuEj8veMD+HtkRlTg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=/SF+E4oIztAo8DI6G23YZJyRkJ1MuJiwBlLoguKFGeE=;
 b=MWaxKjirP5KMRvguk2+GETFyjzbEFHNwZ0gF8OSEZKm/1iKfdJLxk2iDElaGQvtb3iH6kvA5j2pNCGbO5HBJ3dg81pV8Mfm2FQkH6Bj09d7mmtgbjNYonMVttKmxBzrS0nS8Bol0A/t5wr7cCPvzwpRLoimztoBbgXvqYiVCiq5nob/D0t+ScEr8VaRELk643DaiT6/YVX3yjNg7r5duZBcGx9HFxThylD6Ngolo4ofMON4ks7SEVhqJWr2pS1+L6aMEXijtYEzffL6zA+xMbEjnJH3KcNcgQIzO6iVOe5zMa2dFnnYD6fHYhH0SWO9/bX+oq3I8hVQnl3ivmzi4XQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com;
 dkim=pass header.d=oss.nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com;
 s=selector1-NXP1-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=/SF+E4oIztAo8DI6G23YZJyRkJ1MuJiwBlLoguKFGeE=;
 b=wC5qlVhhZoiUtxR3h/S81JnEz8qdT7oQQCidPTpm1zIJR1RxuezgzcAHp1cCR5fk9o5ImlKUQw4IoedtSCYC1Cg5Wm1h1KB+piNoiihvWsAB8/yyNwhyVX3SuHvn82tqdcuANLxstvniro9IrW/h5tPSh4+g5W3gUIgNhioSApj2raxB4QTMn8Wfo1Ue3cM4ubf1I08SNw5BWbsBPGvO0snK3/5aW3Y2+TiBvmyxddmtmHhxPMQIsEn+4h6k+Wd8fXj+dhFaK5i9BL7d5sVRFuo7TIazIQh3sDRx3GLaTLId6IJUnnKinxQZO0qKOWOHaDyuwQJSKPw5hRnXdYnC4w==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=oss.nxp.com;
From: "Andrei Cherechesu (OSS)" 
To: xen-devel@lists.xenproject.org
Cc: S32@nxp.com,
	andrei.cherechesu@oss.nxp.com,
	Andrei Cherechesu ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Oleksii Kurochko ,
	Community Manager ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v4 0/6] xen/arm: Add support for S32CC platforms and LINFlexD UART
Date: Thu, 19 Dec 2024 13:23:09 +0200
Message-ID: <20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com>
X-Mailer: git-send-email 2.45.2
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: AM0PR04CA0039.eurprd04.prod.outlook.com
 (2603:10a6:208:1::16) To PA4SPRMB0023.eurprd04.prod.outlook.com
 (2603:10a6:102:268::8)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PA4SPRMB0023:EE_|PAWPR04MB9936:EE_
X-MS-Office365-Filtering-Correlation-Id: a4b5fec7-ec94-4f4d-e63f-08dd201f9235
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|52116014|7416014|376014|1800799024|366016|38350700014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?VtFtU5nOcbquqNYV0JbF6RfvrxRgj3HmN47iJ+bk1kDJOJrCmwmveQwYsuJ4?=
 =?us-ascii?Q?NmrvvNRtmERcYKlXWEPpbxEHaU8lpO1Y6whs9a4dwx95NnlMuIBRAenpkLGV?=
 =?us-ascii?Q?Cpoz2Agsi2HC8gXExLws918pEaHLM6Q6m+WisJVilG6fJAy0/nWxh5L9DGpA?=
 =?us-ascii?Q?yWyVnYGhm66Ve6NOGd+kSt8MO3j5Gz+J1LCOigaTV64dUFjZ2jGtsX3cXmFQ?=
 =?us-ascii?Q?/UafmogewGKjHL2M8RRqrIaO9WBB+8dJoEeg9OKy1pbfwTigzvtsh3v/9Pbw?=
 =?us-ascii?Q?wOd8jMX1FUY56T3KPsCBKWsBGqbhRShq4UA0QdvbjHFJcU8+ySg8JzsBw7Gu?=
 =?us-ascii?Q?qDxMDgPVzZ/58K8l4VTzofhnU1CxWy1ABsnR+01xl7rft5TY1212c7bNm1V0?=
 =?us-ascii?Q?j5mFs+cX+tQl09ISU6Rp40+lUyeWWjUpJPdV9pDSLchPSqbK6o4f8Ax+xFHR?=
 =?us-ascii?Q?Ycjyvyh/3qnyDJiv8wZvDo5vt7fHYVzHV863cZZ67tq8B1HZQYpHdhKgk7mo?=
 =?us-ascii?Q?7PcVf6JmDlScE15xryttaiKnvODjrGhD96r4L/72nMwJXRhm7YsBel8qMTpX?=
 =?us-ascii?Q?6rCtX72fU2xuxpmMrIm3GujvI/QcQuTX3EfhDiGryBazNpjQLCQSj9WLvqd3?=
 =?us-ascii?Q?dNl185FfFFjeLxXmjfyT3vl5bjFDCzT4wOl4dH0DQx9MEM6bXUrLYMwLNvmZ?=
 =?us-ascii?Q?sPfwoyEuYv/+sOoqT4efcuKQqW3xTUbGjGvSaMXuZN1ImhGAIOJS8j7l09Gw?=
 =?us-ascii?Q?vY1oaqzFXPto3SQvNpHYvG632bYj59uqRfx3P2Hgnr78vBIR6DbfaMRmVRUe?=
 =?us-ascii?Q?iIMBdBkKmKWjF0TcNfLcyDCfOs2QWwUPxmXAKSQ6Z4aTgSGr3bK+l3srYl9n?=
 =?us-ascii?Q?qtLc21L820LGJBTNJ2O5SFBr7dtz384UDClp5mTg+mcVBXwXyAp17FWfIyqu?=
 =?us-ascii?Q?0XCCIXQY0KB/plCfdOJpGOoY+7fhgvAHJEKCe0jxODopsDnuXjGH6AAwz2Nk?=
 =?us-ascii?Q?X9YxaTXITc3ftoTivWlzONUE6VIMLsvzwEx7vq9tflE/7JGoQDfq8x+9ja0A?=
 =?us-ascii?Q?GEqd/hnIBRk1eM6WGCgsq9QGl9j+MwQQVaFoLQhvXHOhBiwbk1UgHcu+vTd6?=
 =?us-ascii?Q?nqRL/NKaF8KRGEnKrPgR6jtZRab0ScxcoyL6wzusbnqwsnDJ9pWATAr1q2Do?=
 =?us-ascii?Q?OH5jJiWkZ0dlXvLyZDqCXeD0KHyZrd+tl3sO+i7sFCdYoUamKzawHKluB9YY?=
 =?us-ascii?Q?o9HUNuUuLDr4fULhn1mDTfoyvYo67lbmmMV8A9QVQjF0etUSUMxlpO00Ps49?=
 =?us-ascii?Q?UTiPZAz0jm5TP+HtPV8yzrXnW07SfB2xT7LbX/9+W9upA3fNppssLh5QPXP9?=
 =?us-ascii?Q?JhrQZjXUZQFEutOPsdZVT01+92GZW7oGY8pdFXO+vZ33GWhz8Fx1xyOUd0V/?=
 =?us-ascii?Q?sMOvowaefjgtnxvq+W7jEMk/lh+rKQXa9pjs0e88fLh+xixiqp0Vrg=3D=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PA4SPRMB0023.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(52116014)(7416014)(376014)(1800799024)(366016)(38350700014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?J5jc2O/4upH09F9sGFZxLiTn1+n6mPoU4Hwfks6Ivzp5WDGFLC/KgocATvwq?=
 =?us-ascii?Q?Bj3oMkZ7CULpA341pVIHwfA0/05xlk0xnFRGQut+vKP3O6e1DVXZkiOLqyNv?=
 =?us-ascii?Q?2kXfIyVgmtszvrG1j5nUqoo3ScARWtYVmkcZGFKS3/IkfthBPE91YNgQPz96?=
 =?us-ascii?Q?G98xTp/p9P0pEWXFbFnF02J+dGyz403YxBPgYaDiRVfgxAXjeSBjwHigpVxD?=
 =?us-ascii?Q?gsDCniUVReJJrFoBWm5iNzR8P5zZPETXEXmdWHXxjPQk9ICpdxV8Xm9IwNZW?=
 =?us-ascii?Q?DriHA4pa9AeRm+aowN/NpKAqqx+S4Db4Ls8ohnP7WcoOlNZYXXOuBZiqP0kk?=
 =?us-ascii?Q?8lj+6mSa+ttZ2bi68gbLWnR1niUXdXruZkkHskM2b6jBOXMQ3MUS7DuQnh92?=
 =?us-ascii?Q?JM21LH79OINvpRY8cCD5uV58DlWi9OCHAZ3uXO4/Z1+Rag+//+y+A368YhQY?=
 =?us-ascii?Q?mGk05q5YCJa+O6/aVryaHDp/50br3Rv4sdl9TItQBKFO9Tefmt1RojurxszU?=
 =?us-ascii?Q?HgImNcKMjY4Q1ozaIxdguYcCEsswy2sI6S3DyeSO+1Bt4iWHWYDHWJkpUft7?=
 =?us-ascii?Q?mxO5WnXlQzaBy+BNNBArZi2S7+PjhWAI31f6bPqPsSQr47ofR1mDWXIS2s6s?=
 =?us-ascii?Q?LGfcQI166PCq1Hgf9JiDvLknDz1V1VhBbo0oE5xhTh3N2509Jzg2aYM9T88t?=
 =?us-ascii?Q?k21hfTRhHKI3DP2E8XmuS1VoCVF/YctUuKQSbwisVK1QRMPFdYpqyasG6Fhi?=
 =?us-ascii?Q?d5ypYJ1CIS6rJx3pFmVbjwQkO2MGglbjahnS8tSOGXOzIYleAQdH0PxrLh/V?=
 =?us-ascii?Q?z4iU+/EC53cYDRrfbl51y7l6Y56Xz5DZkpwlxMLELSWVi9iGQ3u8bSazShhv?=
 =?us-ascii?Q?CzbfRmNUztECr5UNmVCFo3dR9LM3LMggPO/80km5tUcPEN2DDpYig9zNMj9g?=
 =?us-ascii?Q?3HEISIM36RCyYlXAB4PkcsHsG1jlzN4c6bvKfuCC2O34tzEun91KBCb2tkwl?=
 =?us-ascii?Q?JIKfhnvZIrVUXV9y/1yuwwJ88zt8vfjm9OE5v7HUWFff/mMB+etN2rWVbaee?=
 =?us-ascii?Q?w6ZMV6FIxM9FSsdIaLPBIXzXxfjax3wSYFLdGERmT6/s6DykCafysYHx4F6x?=
 =?us-ascii?Q?AAmJEsc8J0CGnn1AE40kq0ffLiqnywET4Q2ewojH5XhOLHCSHJp8dGd3jomp?=
 =?us-ascii?Q?kgFh/4Jwb9Uhfuewe8qSwjtaskNNpD4YDMhf6UhBzPeDWzF2a5Kr/xB++kiZ?=
 =?us-ascii?Q?vjHMw6oRvG3G1siIUiatDI6Owg2WuqQI6AR2PjTYXskxbO2s24yPfFbqoi8I?=
 =?us-ascii?Q?NLyFwMN6okGTB0V52TUS83CytCGjbupFtVWiKbMdEGMAzZFkIz6IH0uihHP5?=
 =?us-ascii?Q?GXBascsslX9XD1xA0e9xXJNyOOh2USu/Z+NcOHaRZdrwJWaLuFrEm1qj4aHx?=
 =?us-ascii?Q?Rvgz9fVNJWOkvAta9xevAaSfFwgIPGIPy+cdI8dGt/HNF/rUdXpCDrfymksh?=
 =?us-ascii?Q?gDNGDT7Wm2EJ1oE8XbHcdi1gy/+ltOOPbdlHaK1C9TXNNu/0DLmRj+NYxNb2?=
 =?us-ascii?Q?Wlx+frokrQbZpTRj7ZfW2+LYfdb+r7+ErzqabRYYsmJMK4fQ2UN2X8ypA73q?=
 =?us-ascii?Q?HQ=3D=3D?=
X-OriginatorOrg: oss.nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a4b5fec7-ec94-4f4d-e63f-08dd201f9235
X-MS-Exchange-CrossTenant-AuthSource: PA4SPRMB0023.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2024 11:23:32.8993
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: qptugAHk+ht0b3SioQzrX0wK95CmmB+iTpGQmFmRleF97oIWcU9n5tN9vj7OS3D00CIyGOmT9kZ+W6NnCpBSAJOkFuCRJmR6d+5Gr54LAHs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR04MB9936

From: Andrei Cherechesu 

Targeting: Xen 4.20
This v4 version of this patch series finishes the work left to support NXP
S32G3 Processors [0], part of the NXP S32CC Family. The LINFlexD UART support
patches have been merged in v2. Platforms using S32G3 Processors are not
affected by the TLBI by VA erratum (discussed in v2), and are security
supported without a workaround needed in Xen or guests. The workaround needed
for S32G2 [1] / S32R45 [2] will be addressed in future series.

The 1st patch introduces a generic mechanism for forwarding SCMI
over SMC calls to firmware running at EL3, selected via
CONFIG_SCMI_SMC. The 2nd patch refactors the SiP SMC handling in
vSMC mechanism, to rely firstly on `platform_smc()` if implemented,
then on the previously introduced generic SCMI handling/forwarding
mechanism.

The 3rd patch adds S32G3 platform config to enable the required drivers for
S32G3-based platforms.

The 4th, 5th and 6th patches modify the CHANGELOG.md, SUPPORT.md
and MAINTAINERS files, respectively, to add mentions about LINFlexD
UART support, S32G3 Processors support, and the new SCMI-SMC layer
introduced.

[0] https://www.nxp.com/products/S32G3
[1] https://www.nxp.com/products/S32G2
[2] https://www.nxp.com/products/S32R45

v3->v4:
  - SCMI-SMC handling layer (Patch [v4,1/6]):
    - Changed license for scmi-smc.c and scmi-smc.h to GPLv2-only
    - Renamed `scmi_support` bool variable to `scmi_enabled`
    - Dropped `scmi_is_enabled()` public function. Driver's internal state is
      now managed internally and based on `scmi_enabled` var. The public
      stub `scmi_handle_smc()` checks first `scmi_enabled`, instead of letting
      callers do this work.
    - Dropped include statement for , replaced with forward
      declaration for `struct cpu_user_regs`
    - Addressed indentation issue for `err` label
    - Changed the `gprintk` from `scmi_handle_smc()` to `gdprintk`, and dropped
      redundant info in the print statement.
  - Handling SiP as SCMI SMC (Patch [v4,2/6]):
    - Dropped usage of `scmi_is_enabled()` since SCMI-SMC driver state is now
      managed internally

v2->v3:
  - linflex-uart (Patch [v2,1/8] and [v2,2/8], now dropped):
    - Patches merged in v2, no longer re-submitted
  - SCMI-SMC handling layer (Patch [v2,3/8], now [v3,1/6]):
    - Changed occurrences of calls coming from "Dom0", to "hwdom" or "hardware
      domain"
    - Made initialization part of initcall chain instead of presmp_initcall
    - Changed occurrences related to "Dom0 DT", to "Host DT"
    - Made `scmi_support` and `scmi_smc_id` variables __ro_after_init
    - Used `current->domain` to print domain ID (with `%pd` formatter)
    - Dropped usage of local string var `smc_id_prop` to store "arm,smc-id"
    - Added usage of XENLOG_* levels to all prints
    - Changed print in `scmi_check_smccc_ver()` to XENLOG_WARNING
    - If `scmi_check_smccc_ver()` fails, initialization fails silently (only
      printing a warning regarding no SMCCC support) since it's optional
    - Made `scmi_is_valid_smc_id()` private to the driver and used it in
      `scmi_handle_smc()` instead of requiring usage by its callers
    - Created a 'firmware' folder in xen/arch/arm, to store the SCMI related
      code, and moved the SCMI-SMC layer implementation there
  - Handling SiP as SCMI SMC (Patch [v2,4/8] now [v3,2/6]):
    - Dropped implementation-specific details in commit message and code
      comments
  - S32G3 platform config (Patch [v2,5/8] now [v3,3/6]):
    - As motivated at the beginning of this cover letter, changed the config
      name and description from S32CC to S32G3
    - Dropped the `s32cc.c` dummy platform code and the CONFIG_S32CC_PLATFORM
      used to enable its compilation
    - Dropped Stefano's "Reviewed-by", since patch had non-trivial changes.
      Please re-approve.
  - CHANGELOG.md (Patch [v2,6/8] now [v3,4/6]):
    - Changed 'dom0' to 'hwdom'
    - Changed S32CC to S32G3, as motivated at the beginning of the cover letter
    - Rephrased to drop the 'Add' word since the entries are already part of
      the 'Added' category
    - Dropped Stefano's and Oleksii's "Acked-by", since patch had non-trivial
      changes. Please re-approve.
  - SUPPORT.md (Patch [v2,7/8] now [v3,5/6]):
    - Changed 'dom0' to 'hwdom'
    - Changed 'Dom0 DT' to 'Host DT'
  - MAINTAINERS (Patch [v2,8/8] now [v3,6/6]):
    - Dropped `linflex-uart.c` driver from ARM Architecture list
    - Dropped `s32cc.c` platform file since it's been dropped from Patch
      [v3,3/6]
    - Changed S32CC to S32G3, as motivated at the beginning of the cover letter
    - Dropped Stefano's "Acked-by", since patch had non-trivial changes. Please
      re-approve.

v1->v2:
  - linflex-uart: 
    - Addressed coding style comments from Julien:
      - spaces vs. tabs
      - indentation
      - license issue
      - comments format
      - code reusage
      - misplaced loop exit
    - Made the pointer to struct linflex_uart const in most functions
    since it's not modified
    - Added support for customizable baud rate through console options,
    parsing what Xen gets in its bootargs. other parameters following
     are discarded for the moment.
  - SCMI SMC handling:
    - Added a generic `scmi-smc` layer (enabled by CONFIG_SCMI_SMC)
    to enable forwarding SCMI requests over SMC to EL3 FW if issued
    by Dom0. If the SCMI firmware node is not found in Dom0's DT during
    initialization, it fails silently as it's not mandatory.
    - Changed the handling for SiP SMCs in vsmc.c to firstly try
    the `platform_smc()` callback if implemented, then try to
    handle the SiP SMC as SCMI if enabled and SMC ID matches.
  - S32CC Platform support:
    - Added dependency on CONFIG_SCMI_SMC
    - Removed the S32CC platform-specific forwarding to EL3 mechanism.
    - Dropped unused headers
  - CHANGELOG.md:
    - Added mentions about S32CC support and SCMI-SMC layer.
  - SUPPORT.md:
    - Added SCMI over SMC forwarding to EL3 feature for Arm as supported.
  - MAINTAINERS:
    - Added myself as maintainer for S32CC platforms and NXP S32 Linux Team
    as reviewer list.

Andrei Cherechesu (6):
  xen/arm: firmware: Add SCMI over SMC calls handling layer
  xen/arm: vsmc: Enable handling SiP-owned SCMI SMC calls
  xen/arm: platforms: Add NXP S32G3 Processors config
  CHANGELOG.md: Add NXP S32G3 and SCMI-SMC layer support mentions
  SUPPORT.md: Describe SCMI-SMC layer feature
  MAINTAINERS: Add myself as maintainer for NXP S32G3

 CHANGELOG.md                                 |   3 +
 MAINTAINERS                                  |   6 +
 SUPPORT.md                                   |   8 +
 xen/arch/arm/Kconfig                         |   2 +
 xen/arch/arm/Makefile                        |   1 +
 xen/arch/arm/firmware/Kconfig                |  13 ++
 xen/arch/arm/firmware/Makefile               |   1 +
 xen/arch/arm/firmware/scmi-smc.c             | 162 +++++++++++++++++++
 xen/arch/arm/include/asm/firmware/scmi-smc.h |  41 +++++
 xen/arch/arm/platforms/Kconfig               |   8 +
 xen/arch/arm/vsmc.c                          |  13 +-
 11 files changed, 257 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/arm/firmware/Kconfig
 create mode 100644 xen/arch/arm/firmware/Makefile
 create mode 100644 xen/arch/arm/firmware/scmi-smc.c
 create mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h

-- 
2.45.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 11:23:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 11:23:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861109.1273102 (Exim 4.92)
	(envelope-from )
	id 1tOEd3-0008DD-EZ; Thu, 19 Dec 2024 11:23:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861109.1273102; Thu, 19 Dec 2024 11:23: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 1tOEd3-0008D6-Be; Thu, 19 Dec 2024 11:23:41 +0000
Received: by outflank-mailman (input) for mailman id 861109;
 Thu, 19 Dec 2024 11:23: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 1tOEd2-00089J-4T
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 11:23:40 +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 b1c334b2-bdfb-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 12:23:39 +0100 (CET)
Received: from PA4SPRMB0023.eurprd04.prod.outlook.com (2603:10a6:102:268::8)
 by PAWPR04MB9936.eurprd04.prod.outlook.com (2603:10a6:102:38b::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.15; Thu, 19 Dec
 2024 11:23:34 +0000
Received: from PA4SPRMB0023.eurprd04.prod.outlook.com
 ([fe80::fd16:4665:bad7:33ce]) by PA4SPRMB0023.eurprd04.prod.outlook.com
 ([fe80::fd16:4665:bad7:33ce%4]) with mapi id 15.20.8251.015; Thu, 19 Dec 2024
 11:23: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: b1c334b2-bdfb-11ef-a0d7-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=DsrQN2OvMcYslLacDdwejwCUYeQWyGjJZ3FA+nYjAK/SeLgNW+j+LL4/nxMMWsmGNl3Bh4eG17asEdGMOtb68bmAgsaE9DbS4YLG5ggdHQ5ofAFpT0r40S2I6T9nFlkUL5Hm71ygOlO0uNXwnZ4+TsAfQVszJkZczdAmtazqaxt1ML6fzDANoIMdAqDq1b66qSd1O+AC+tRyO/xXXumzCkcP86AgMj6BQxGrsCvfBPVtKphoCsDMgASrWjRwV6V/FCc84i42ZWvANIkFql9COVCoA9Mj1xUL4SczAfZ30+c9ktV6lfKf9F0NaG8izOSkDWL4CGxQXWPDvuflVTJgJg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=D1CbZ0U6+K5JDrnG9X+0y79bNYIpjNK/9pm/gAmFT+g=;
 b=xLLdVr7+ELiTmmUUY7lCW5yf20PbWVpCTrlcVg/KqFs3L/ri/KewWNpeudJOXNwEVQmFixj1so645QzVFJh/P8Zr8fhFFzqsMUME9wGBHAeLWLe+BY3gyV3VHvd3rWKvUF45Ok5ofuM4u0vNFvuYL4ido0kpCFxsHuBOhv8Dp26erOORWiuB79t7kFK3kkjYBUvKksGvGvmtoQZqgWkUEk6LBLlPo+UuGylwafLiFpST5FNtfdkVIWwJj8K/V7n0tqCc3Ldjdeqq9eJZLixnCc5mJ5ik0FVRjz1RAG7aQwbSDQGydX3dPZBkmxsxlLQL/k5vhm8yrLmhZ4AVNzFIFw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com;
 dkim=pass header.d=oss.nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com;
 s=selector1-NXP1-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=D1CbZ0U6+K5JDrnG9X+0y79bNYIpjNK/9pm/gAmFT+g=;
 b=Vxxe0GtS7kmxt3OmPJNR5YvGbWM6du51/GXdIdbMVbW0KzyNmb9A2PYUAv96H0ReCNRuTamtzKO/oTP5YigHMq0rQBbKn8p7Tv3cnte/DwtHUg5++/akba4P1COXq+BrufLOx5plFatyC4AYjnSGZPdagTfpozhHv1XEVtVgJrcU7MvsXW+nnQnAMQ3ipcswG9Mbvimb3YwpnZJdyQgoz1RMCiGcOkjzRC3L7kOp3Fg2siawIt1gA/g9B7ONqjYBp+9r0c5n+8rt8ay6QhqOB4eRMzRES94EVv5XLFTQdgrHQZuFdiaZszjJjSSQJ0jLyke2pbhHnNTi6R0axLiSVg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=oss.nxp.com;
From: "Andrei Cherechesu (OSS)" 
To: xen-devel@lists.xenproject.org
Cc: S32@nxp.com,
	andrei.cherechesu@oss.nxp.com,
	Andrei Cherechesu ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v4 1/6] xen/arm: firmware: Add SCMI over SMC calls handling layer
Date: Thu, 19 Dec 2024 13:23:10 +0200
Message-ID: <20241219112315.2461048-2-andrei.cherechesu@oss.nxp.com>
X-Mailer: git-send-email 2.45.2
In-Reply-To: <20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com>
References: <20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: AM0PR04CA0039.eurprd04.prod.outlook.com
 (2603:10a6:208:1::16) To PA4SPRMB0023.eurprd04.prod.outlook.com
 (2603:10a6:102:268::8)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PA4SPRMB0023:EE_|PAWPR04MB9936:EE_
X-MS-Office365-Filtering-Correlation-Id: 7bd80c8b-fe9e-468d-34bf-08dd201f9310
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|52116014|376014|1800799024|366016|38350700014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?079cA5k2B6NNOKVdYDdf2lu4RveChMdDwMTnR6gFHnoIJOZUOMR+m65/z5Su?=
 =?us-ascii?Q?WrP0JbYuIv1THCBT00IO1L9W5KmASwxutCkwfp6HJqnl96rEXCliYxEDwuAu?=
 =?us-ascii?Q?ZGDL8nvGmLVOePOuBN3BIPDszEka3aCQHeSYlM7MpWAkI5bqWUpDlHPiNxot?=
 =?us-ascii?Q?YK0wSeIgMD7ub1DryrzIL4XTZY7dcuVGGtNFMGeRc6BmVfFT3+m8JBpBUMdE?=
 =?us-ascii?Q?pRvivqAr7mlij/Kmw83jjoRxpvZGWjwYv4S2kAd2Y9gf0f58evi4VlUjIYoh?=
 =?us-ascii?Q?ivV1NhD+5mpjYN4vaMpHqAoWjeM2d+pDB45SrKg238o0Xe6c9Vvke4125KXz?=
 =?us-ascii?Q?QY6JuiyPe5y1cffbLIAJ/tAxWS1ky0TOdEwUVohKES8TwQ74EqPuTzE3n5ab?=
 =?us-ascii?Q?nR3e6enbcAc4HukbtufMzYJxJq2gC/K9GhS2cGJPi0PujkPYShnhrH7EfLVY?=
 =?us-ascii?Q?MHoyVZaf2KQl3Uk1IIYAezr5vSH3OgYNgwQnZK1+ch6hgeqLV9ojaVDXxmFJ?=
 =?us-ascii?Q?JUriXDnXZpfkh+Qel64/BiNr2I0fz/9DvURUyij+gZ/5RrH4VGBiOSpVGc0d?=
 =?us-ascii?Q?yiPFhhAJlnK6346/gfv+F8vxKvnk6PGL0yNLNn6mEOcqHRhi4D7E3pDTZKNI?=
 =?us-ascii?Q?r47RcvPRYR7B2jHicM/djW0kMdYBWzMTJjwQSR9+I3gaAB7aDKanFcwAeyTN?=
 =?us-ascii?Q?HA9XVdQ0NSBRoy0HdaENPdpXvX7ztOFR0kXOcIAuD5038Raloh4G9BpO9qPw?=
 =?us-ascii?Q?jAbFwCjQl0LZDOMJCOO0uBVSFDBCgJYPHujGAs9ZoA91bOaLRf7I8xC0TVr+?=
 =?us-ascii?Q?JtK2rJNMqztoaoq97OYgT8JnlVSiSG5CGFE2FfEimjYUrwApRcSZ0E7Agk2l?=
 =?us-ascii?Q?tJuK4Ao1ABDqRDPLpRnHfs7idYQVSa+GFUcIEWru/w7T8xl/24JQhLbYsoMe?=
 =?us-ascii?Q?scYwhnt1N0Mz8CR07ywV4tlDdORZJSAcvfzQoaD08F6Y78cclkqQB7L9Orva?=
 =?us-ascii?Q?G35oLgDoNiUG+TPx96lMERxJKpcy6Ehqf4MItYFCjzCUj+7NGLAjDax1hkPu?=
 =?us-ascii?Q?IIk7ZQ3qdHh688g26oiNFUOckfMxQtmP+S2mUz9CIsac2E61CKFT2cdfD10a?=
 =?us-ascii?Q?+kkb74kIMulMNB1pghN3sjU0pblriwcUOHyUfGrKzQ3IOYsHmlCaxRsNQ6JO?=
 =?us-ascii?Q?LtpnZpaSXxVeepS14Y1mZ6YDci+WAGNUoeDbuDl+7SsovnzNKhd6Qvt8tR0T?=
 =?us-ascii?Q?y8Bpe4S12h9HIYxKc2th+BRwrnx0U05QD3X5Y7pPmXVMz17+8oD4f6HvlZS3?=
 =?us-ascii?Q?Vfn7YV0m1xQ5Pw20B1nti5MKrXdH2qYVvNOJ+C6hwIyzW/vldu8G0yi7w9+j?=
 =?us-ascii?Q?Z/qn3LhK61N61c9/EunhiI7DtI3E7oFrozoYlmUZj9E4u3Bj3GkkKS2UAHUs?=
 =?us-ascii?Q?oAKcCVViubRQ9YNMX+IAeWm/JrmGNlbN?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PA4SPRMB0023.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(52116014)(376014)(1800799024)(366016)(38350700014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?tY8RuJXEi+eMHOHerqIBZ4Xk1bS+oJcEs52uhXruNJ/EbCaGJ4ZtzaGaAFR8?=
 =?us-ascii?Q?CeFpPcLckMuXA7eU4gCJeOZT2sXSWdT/HJ4YN/PyU8XZRqLArxcueTG9uMzl?=
 =?us-ascii?Q?JtDaOEOO2kWEWBHSMUHKWuFcJnTOZ1AHB17vj4tUkl6+zjsHMH2h/tFCwnXm?=
 =?us-ascii?Q?mqTPL01vifSlL3ChX/KDw1hB0+Te5oOpn33O0Ax0L48PLm32V31nqCG0RunI?=
 =?us-ascii?Q?XWdvmXzK/5jsvyn+1e6phZ3rZib0lt05lppuNuxAOYTuG+M6qOD1oh86eIds?=
 =?us-ascii?Q?AxURv8PfBuPtRuLWfVxiesz3NyzosXfPjTpxgju7YJjzisl3Hmkta8h+8udF?=
 =?us-ascii?Q?UcAk2sYr/ZHtiNImJdbaQk5ISLjXJL+mQyYt92td8oMI+MmWuijklTqTkSdA?=
 =?us-ascii?Q?HJlLifHydI80og+5DXHY63do/BOFlga5cdyHnW7K4dNrG+nfreCN523u5PqA?=
 =?us-ascii?Q?ZQAtl09cndYD9FQeG/eDPafch3flzsNCXAK3qWqILswK4uM2Sa/aLCrKiUd/?=
 =?us-ascii?Q?5D5QF7m7uZmoGmMJNv1XOW4NNpWe8N1/eiL+eI5ed4ZxII5OwpxXQbI08n1v?=
 =?us-ascii?Q?fYuwl/KKHrs1VMM4vnZphYugrYfOpAx7qYmgDaohhDsVB9nY/f/bQxsXm9+N?=
 =?us-ascii?Q?gmWctoMyR9vxEhQMAANklhq0rN2EN/A7UubTWUud1Bj+bLn++KEUR9aZcF7Z?=
 =?us-ascii?Q?KE9QIK3MGbMZetjPQI583+zADwy5Cch9kUO43V8+fF0VmKakGfWC8PKtGWSt?=
 =?us-ascii?Q?JvPXoMa8/KfRWDaBJjz436NAXC8f5aCACvuy+SAlyesQ6H9tfEXi+VvMXfTe?=
 =?us-ascii?Q?/kXAywztV9H/0BzdPzE4U9K4DZrKSTtCobMUPGh4c5cokd6pT9xn2s3Yh/g/?=
 =?us-ascii?Q?RGdp/zvWywq23ZVfLqXryPIGbL9+M30mlg04AqwT+Az2zC0amXmW7prcCV20?=
 =?us-ascii?Q?Vk99pyuVF600McM8PfZ1E17HWBEE1ScV41kzUVHn8wZo8r7RTBZsS2upWXkd?=
 =?us-ascii?Q?wafwJELCVDPAJIMNdEYk2CYENi6Jl8cDl5jbFlW3/7d45WFmjQAaOiwZRk8E?=
 =?us-ascii?Q?mkigCnS2YK0C9h+yL3XcvurqZN19kGkfbJiugmgMvKWm8sxpbJgM4I4+mHEB?=
 =?us-ascii?Q?cZa0Efmvj8A6CCH8/B6y2wiMHDUjv6jeIhlZWymntlIRZNqFlTt7bb7NLc6V?=
 =?us-ascii?Q?HvdPpieXWng7qAE5nkncn2NZO3tpP+sB/9Oc9EieMiwvBg1wMLFG14t8vEPe?=
 =?us-ascii?Q?MiCMv6oUJQHHaXx+EL73cwB6E7Rk52/PjPkiR8+H/71JdYzNu/P45juLCHBf?=
 =?us-ascii?Q?BMN1k3yd5sNhTVn7EB+Tc1WiaY0veZRyJKifm58oxqalth9k96wb7Q5ez9ay?=
 =?us-ascii?Q?Jkx8deF7bK9NZWdgZzN+IhAkNdSAY9KX7aMl6bmYaS0h/oU7aEHuwW4yK7RR?=
 =?us-ascii?Q?rB4IJUGm4ws76RB/DdZTCafMXgfhlXEYTOcmn3KRRO2mhcKurfVMaq6sbhlj?=
 =?us-ascii?Q?1UOdJHiz7UBIJC/v/OiwFRWI/+xBiLY7NI3m5LIxHgPUo8cQF7iWTh4joYpZ?=
 =?us-ascii?Q?+dVGoEDUsNimbu1qxvmCiqAh8ZZtQ2ycEp3kIYfDqFHxPsUrolit12JPZYQQ?=
 =?us-ascii?Q?gQ=3D=3D?=
X-OriginatorOrg: oss.nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7bd80c8b-fe9e-468d-34bf-08dd201f9310
X-MS-Exchange-CrossTenant-AuthSource: PA4SPRMB0023.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2024 11:23:34.1397
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: tYgIk0NJj2thMVHZtQ5vu+i3GMjVQ6iPLr1nBZbGkFxwieZY+QmmnEk7HyAlIZXIvIE2M2qBK1ZZ5s6fsqlMwwnYtjcPMRdTBI8OSdhUK0w=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR04MB9936

From: Andrei Cherechesu 

Introduce the SCMI-SMC layer to have some basic degree of
awareness about SCMI calls that are based on the ARM System
Control and Management Interface (SCMI) specification (DEN0056E).

The SCMI specification includes various protocols for managing
system-level resources, such as: clocks, pins, reset, system power,
power domains, performance domains, etc. The clients are named
"SCMI agents" and the server is named "SCMI platform".

Only support the shared-memory based transport with SMCs as
the doorbell mechanism for notifying the platform. Also, this
implementation only handles the "arm,scmi-smc" compatible,
requiring the following properties:
	- "arm,smc-id" (unique SMC ID)
	- "shmem" (one or more phandles pointing to shmem zones
	for each channel)

The initialization is done as initcall, since we need
SMCs, and PSCI should already probe EL3 FW for SMCCC support.
If no "arm,scmi-smc" compatible node is found in the host
DT, the initialization fails silently, as it's not mandatory.
Otherwise, we get the 'arm,smc-id' DT property from the node,
to know the SCMI SMC ID we handle. The 'shmem' memory ranges
are not validated, as the SMC calls are only passed through
to EL3 FW if coming from the hardware domain.

Create a new 'firmware' folder to keep the SCMI code separate
from the generic ARM code.

Signed-off-by: Andrei Cherechesu 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/Kconfig                         |   2 +
 xen/arch/arm/Makefile                        |   1 +
 xen/arch/arm/firmware/Kconfig                |  13 ++
 xen/arch/arm/firmware/Makefile               |   1 +
 xen/arch/arm/firmware/scmi-smc.c             | 162 +++++++++++++++++++
 xen/arch/arm/include/asm/firmware/scmi-smc.h |  41 +++++
 6 files changed, 220 insertions(+)
 create mode 100644 xen/arch/arm/firmware/Kconfig
 create mode 100644 xen/arch/arm/firmware/Makefile
 create mode 100644 xen/arch/arm/firmware/scmi-smc.c
 create mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 604aba4996..23dc7162a7 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -271,6 +271,8 @@ config PARTIAL_EMULATION
 	  not been emulated to their complete functionality. Enabling this might
 	  result in unwanted/non-spec compliant behavior.
 
+source "arch/arm/firmware/Kconfig"
+
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index e4ad1ce851..8c696c2011 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_HAS_PCI) += pci/
 ifneq ($(CONFIG_NO_PLAT),y)
 obj-y += platforms/
 endif
+obj-y += firmware/
 obj-$(CONFIG_TEE) += tee/
 obj-$(CONFIG_HAS_VPCI) += vpci.o
 
diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig
new file mode 100644
index 0000000000..817da745fd
--- /dev/null
+++ b/xen/arch/arm/firmware/Kconfig
@@ -0,0 +1,13 @@
+menu "Firmware Drivers"
+
+config SCMI_SMC
+	bool "Forward SCMI over SMC calls from hwdom to EL3 firmware"
+	default y
+	help
+	  This option enables basic awareness for SCMI calls using SMC as
+	  doorbell mechanism and Shared Memory for transport ("arm,scmi-smc"
+	  compatible only). The value of "arm,smc-id" DT property from SCMI
+	  firmware node is used to trap and forward corresponding SCMI SMCs
+	  to firmware running at EL3, for calls coming from the hardware domain.
+
+endmenu
diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefile
new file mode 100644
index 0000000000..a5e4542666
--- /dev/null
+++ b/xen/arch/arm/firmware/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SCMI_SMC) += scmi-smc.o
diff --git a/xen/arch/arm/firmware/scmi-smc.c b/xen/arch/arm/firmware/scmi-smc.c
new file mode 100644
index 0000000000..33473c04b1
--- /dev/null
+++ b/xen/arch/arm/firmware/scmi-smc.c
@@ -0,0 +1,162 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * xen/arch/arm/firmware/scmi-smc.c
+ *
+ * ARM System Control and Management Interface (SCMI) over SMC
+ * Generic handling layer
+ *
+ * Andrei Cherechesu 
+ * Copyright 2024 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define SCMI_SMC_ID_PROP   "arm,smc-id"
+
+static bool __ro_after_init scmi_enabled;
+static uint32_t __ro_after_init scmi_smc_id;
+
+/*
+ * Check if provided SMC Function Identifier matches the one known by the SCMI
+ * layer, as read from DT prop 'arm,smc-id' during initialiation.
+ */
+static bool scmi_is_valid_smc_id(uint32_t fid)
+{
+    return (fid == scmi_smc_id);
+}
+
+/*
+ * Generic handler for SCMI-SMC requests, currently only forwarding the
+ * request to FW running at EL3 if it came from the hardware domain.
+ * Called from the vSMC layer for SiP SMCs, since SCMI calls are usually
+ * provided this way.
+ *
+ * Returns true if SMC was handled (regardless of response), false otherwise.
+ */
+bool scmi_handle_smc(struct cpu_user_regs *regs)
+{
+    uint32_t fid = (uint32_t)get_user_reg(regs, 0);
+    struct arm_smccc_res res;
+
+    if ( !scmi_enabled )
+        return false;
+
+    if ( !scmi_is_valid_smc_id(fid) )
+        return false;
+
+    /* Only the hardware domain should use SCMI calls */
+    if ( !is_hardware_domain(current->domain) )
+    {
+        gdprintk(XENLOG_WARNING, "SCMI: Unprivileged access attempt\n");
+        return false;
+    }
+
+    /* For the moment, forward the SCMI Request to FW running at EL3 */
+    arm_smccc_1_1_smc(fid,
+                      get_user_reg(regs, 1),
+                      get_user_reg(regs, 2),
+                      get_user_reg(regs, 3),
+                      get_user_reg(regs, 4),
+                      get_user_reg(regs, 5),
+                      get_user_reg(regs, 6),
+                      get_user_reg(regs, 7),
+                      &res);
+
+    set_user_reg(regs, 0, res.a0);
+    set_user_reg(regs, 1, res.a1);
+    set_user_reg(regs, 2, res.a2);
+    set_user_reg(regs, 3, res.a3);
+
+    return true;
+}
+
+static int __init scmi_check_smccc_ver(void)
+{
+    if ( smccc_ver < ARM_SMCCC_VERSION_1_1 )
+    {
+        printk(XENLOG_WARNING
+               "SCMI: No SMCCC 1.1 support, SCMI calls forwarding disabled\n");
+        return -ENOSYS;
+    }
+
+    return 0;
+}
+
+static int __init scmi_dt_init_smccc(void)
+{
+    static const struct dt_device_match scmi_ids[] __initconst =
+    {
+        /* We only support "arm,scmi-smc" binding for now */
+        DT_MATCH_COMPATIBLE("arm,scmi-smc"),
+        { /* sentinel */ },
+    };
+    const struct dt_device_node *scmi_node;
+    int ret;
+
+    /* If no SCMI firmware node found, fail silently as it's not mandatory */
+    scmi_node = dt_find_matching_node(NULL, scmi_ids);
+    if ( !scmi_node )
+        return -EOPNOTSUPP;
+
+    ret = dt_property_read_u32(scmi_node, SCMI_SMC_ID_PROP, &scmi_smc_id);
+    if ( !ret )
+    {
+        printk(XENLOG_ERR "SCMI: No valid \"%s\" property in \"%s\" DT node\n",
+               SCMI_SMC_ID_PROP, scmi_node->full_name);
+        return -ENOENT;
+    }
+
+    scmi_enabled = true;
+
+    return 0;
+}
+
+/* Initialize the SCMI layer based on SMCs and Device-tree */
+static int __init scmi_init(void)
+{
+    int ret;
+
+    if ( !acpi_disabled )
+    {
+        printk(XENLOG_WARNING "SCMI is not supported when using ACPI\n");
+        return -EINVAL;
+    }
+
+    ret = scmi_check_smccc_ver();
+    if ( ret )
+        return ret;
+
+    ret = scmi_dt_init_smccc();
+    if ( ret == -EOPNOTSUPP )
+        return ret;
+    if ( ret )
+        goto err;
+
+    printk(XENLOG_INFO "Using SCMI with SMC ID: 0x%x\n", scmi_smc_id);
+
+    return 0;
+
+ err:
+    printk(XENLOG_ERR "SCMI: Initialization failed (ret = %d)\n", ret);
+    return ret;
+}
+
+__initcall(scmi_init);
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/include/asm/firmware/scmi-smc.h b/xen/arch/arm/include/asm/firmware/scmi-smc.h
new file mode 100644
index 0000000000..6b1a164a40
--- /dev/null
+++ b/xen/arch/arm/include/asm/firmware/scmi-smc.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * xen/arch/arm/include/asm/firmware/scmi-smc.h
+ *
+ * ARM System Control and Management Interface (SCMI) over SMC
+ * Generic handling layer
+ *
+ * Andrei Cherechesu 
+ * Copyright 2024 NXP
+ */
+
+#ifndef __ASM_SCMI_SMC_H__
+#define __ASM_SCMI_SMC_H__
+
+#include 
+
+struct cpu_user_regs;
+
+#ifdef CONFIG_SCMI_SMC
+
+bool scmi_handle_smc(struct cpu_user_regs *regs);
+
+#else
+
+static inline bool scmi_handle_smc(struct cpu_user_regs *regs)
+{
+    return false;
+}
+
+#endif /* CONFIG_SCMI_SMC */
+
+#endif /* __ASM_SCMI_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.45.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 11:23:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 11:23:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861110.1273109 (Exim 4.92)
	(envelope-from )
	id 1tOEd3-0008GY-Ps; Thu, 19 Dec 2024 11:23:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861110.1273109; Thu, 19 Dec 2024 11:23: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 1tOEd3-0008G3-JI; Thu, 19 Dec 2024 11:23:41 +0000
Received: by outflank-mailman (input) for mailman id 861110;
 Thu, 19 Dec 2024 11:23: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 1tOEd2-00089J-QL
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 11:23:40 +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 b2423776-bdfb-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 12:23:39 +0100 (CET)
Received: from PA4SPRMB0023.eurprd04.prod.outlook.com (2603:10a6:102:268::8)
 by PAWPR04MB9936.eurprd04.prod.outlook.com (2603:10a6:102:38b::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.15; Thu, 19 Dec
 2024 11:23:37 +0000
Received: from PA4SPRMB0023.eurprd04.prod.outlook.com
 ([fe80::fd16:4665:bad7:33ce]) by PA4SPRMB0023.eurprd04.prod.outlook.com
 ([fe80::fd16:4665:bad7:33ce%4]) with mapi id 15.20.8251.015; Thu, 19 Dec 2024
 11:23: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: b2423776-bdfb-11ef-a0d7-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=bXq0wmAxhELERVWndeEwt+Nj/om35zrQ+84GeuEKc5n9mcXm37B4Ojz5bsl71e8ph201BrHh5Kiaj9UTv2B/xMy7hquK7OfcL7cGjMtKe7xGWZRGreSfV48vbR+ltw6VgRzZ0pyGwK6qwvgKl0b7hIdpk/Neh01vW5A63XztwX0UY21q2fULiTKeDLzGTTaNpSNuINJIqey/Q+HOvldRN6yl+HKgCUgzqgH+hVw5bIakuri4NNF3bBOzvYypRfnohBHiEKsSkRt2XsZUxfGoIo/SbH1izIgo4lldx02qLas/Ps4nFKjvNS+o0hESXM8Rktc4zphGXAO+6Ili1he8aQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vl6a2ZFCdB7uSAUka3CQGXl5zPhfOlTYRKt+89VAhOE=;
 b=UnlXPIGAiagkfEFV9OSUSG9JR7i+b0mHEpuNpjAoai2UhoD8aFasckl/P2dpzQW2SmkwURYZwC/EcY/QmxxTsdGqZC1mF1pxiyVd+YrnLFFyB+epozl/DSlR2brI+o0ZQTWt2Nddefu57cMjgw9IopHvPnFm0yOykjXGzgiLIvTqV0CvWLRercDAPPnwl4mM0oCT5n1q2odMP7ual4i6XywKdjC5LTJOodKDwlfKB2nHke36vH2QimnijeTUJHBaisJRb/KhUgOoSouLMQllYIBHC3JUQr065n68kPqusvxczzd1r6o56s052PokfnHjA2Fg9rQ+xyutzqBp9biiMg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com;
 dkim=pass header.d=oss.nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com;
 s=selector1-NXP1-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=vl6a2ZFCdB7uSAUka3CQGXl5zPhfOlTYRKt+89VAhOE=;
 b=IrSZ20TEnqTZxX74TgBNTXBsIxapUBMi0VQVjgmxivTmCuOWZA8Td+f2//ceBxVDMLKxFLDUsaENJ/bA5i83F+a3GVGbNcOeSuYLTjAucm6fLRjvgE5A6Bf6WVDbppL7Fvo+1FFbY9CNqZTbKNgiO794ALK6ezqprpLpVtQ0L3qH0UFTWbuRfAnForxcTs+btPVBoPw2qdL43ApmDiRidUX63gnQX6ov7nJLQXwafIlS4dDT4k+IVD+FJ/cfFhGdHXh+sYFL/OhAcjag+mVSItHlQiU8QT4i7ygK4TbUdjta796WGRYWXKSdbdPGh/ju6qyIuQ1gGIJTUcbIr3hk3A==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=oss.nxp.com;
From: "Andrei Cherechesu (OSS)" 
To: xen-devel@lists.xenproject.org
Cc: S32@nxp.com,
	andrei.cherechesu@oss.nxp.com,
	Andrei Cherechesu ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Julien Grall 
Subject: [PATCH v4 2/6] xen/arm: vsmc: Enable handling SiP-owned SCMI SMC calls
Date: Thu, 19 Dec 2024 13:23:11 +0200
Message-ID: <20241219112315.2461048-3-andrei.cherechesu@oss.nxp.com>
X-Mailer: git-send-email 2.45.2
In-Reply-To: <20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com>
References: <20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: AM0PR04CA0039.eurprd04.prod.outlook.com
 (2603:10a6:208:1::16) To PA4SPRMB0023.eurprd04.prod.outlook.com
 (2603:10a6:102:268::8)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PA4SPRMB0023:EE_|PAWPR04MB9936:EE_
X-MS-Office365-Filtering-Correlation-Id: 09499d96-fb3d-45bb-fe50-08dd201f93a7
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|52116014|376014|1800799024|366016|38350700014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?9owx1PcL99jevXt75Sfru1/e5yXeizbiVeYLeIAVIEn4HGVSSY136cYlG2CF?=
 =?us-ascii?Q?43m5GXoU8xWlyLUknVchvC/kLJppChLeUqZ7y+d9lUZcKC3Npxn8oCjyXftN?=
 =?us-ascii?Q?zopNV///7cPJXlOZGy0SlaRRdLNZTf6IqF1d/wIGmhSEBsj3v5/97ce4Rn16?=
 =?us-ascii?Q?bEY/7EA4plwifJxvfHxmbEBEHsamxJ97ofWYMaPUAMLfRnZ3Wp3E+KxbgbEW?=
 =?us-ascii?Q?P0WEL0a6/YGB4dBZ193iPYhEgjXEbIBN8cCziZ4rBfNdss7nRXQQKvTlFPyJ?=
 =?us-ascii?Q?ZPDx7uvz7fXe0FbYctVa/a75lF8iyIIov+P1fZK42M0kHE0XRrtLPxt9IR3c?=
 =?us-ascii?Q?yFDgkcn7RTBVnfQebVAz24wM7ngOvrWQdPc9stDTsKaxqrzmN7SdS/I82R3f?=
 =?us-ascii?Q?YU/LqsMqHhKQcaJPw3hbx+HJAImDtAgtXPtLFcfFk769GuzMOlYz86lCH3Nz?=
 =?us-ascii?Q?LKocNZHj60DkIfxkWb7fZGskojk/VG+ab2f036a5yXYmC/XQRwEUrJ7Azwc+?=
 =?us-ascii?Q?VJr/gJWXdxwtK19ctbgdqboytTB2eKAwUywWk7gPZU/7fPAvGozNvE6HSdm8?=
 =?us-ascii?Q?TIqlsIyX2lddR1/QQXt3THSLoa3NBjaBhGj2j3/4F4Wxrf7c8U/oiu9UborV?=
 =?us-ascii?Q?mPVDkv4jq2Aq2+njAFWiYvhUBGc0K0CZXpL2RWVJpzDsulA3CZkFucUDjsY+?=
 =?us-ascii?Q?Vk9jB0R/q63c2HLVkAj4kOCUT6YjOxVNjiE5eXvxVnP2tn/gwFQJ0kTPaZKS?=
 =?us-ascii?Q?jaAFpC8zqlIdsZ6AYEe/WI12o81ph9jWXr5mUdSUgm+nfx+P8BQJxjjuTg8R?=
 =?us-ascii?Q?eUxenu1uD44Kd9dRCY2jrsyFkacv1WoEOCsrawsSfpZwj1wSrr+PtRxt+65K?=
 =?us-ascii?Q?AQYD0enpa94Pkd/Dr4BNaKlJJNM4NL7PgjUNycb4WMK4D8jpyl4tTrmi51/5?=
 =?us-ascii?Q?vzZBdMFumT1jw0DOxGq+v7zCS0uIHvC1i0aHJyf4HucefwI1jMzBp13uHa+I?=
 =?us-ascii?Q?rz48bcGxHXeBdndk5wljckDTlX8cRqNl0ZhiCGWJMcFHuXHjYLOpKzgx8su1?=
 =?us-ascii?Q?g7CIGJZvawfWayE3VOfsgSPvHHqsshf4okhTUM5bWGL0NNQ7X+LYz4LMTVMY?=
 =?us-ascii?Q?Gb91O5WdEYu9C2843TIqUXGnN3+DqwyRuEupBXyNqhByYkwZjBfF3l1Zz+uN?=
 =?us-ascii?Q?cSb5wwiWid6atbYTjJQXJVg5YWIF9DuGDsA6Ud26Ad54rA+04gAFRXuj991q?=
 =?us-ascii?Q?uRANuek9G3FNTMCosRANtUKePsVtz8msIJv4wD0apV9PLZPWNoBlUckSPC/E?=
 =?us-ascii?Q?KIUtyzRsO2klEw1e8sRdHDi0dmAhx1Pn7guJ5qC5/LagMJLhe7M53/Xiwgoj?=
 =?us-ascii?Q?ca1bYBX+aGsylH74EvUdKhEgcamSBPORfiw1HyA9OQCkp/03nZqHTfWOTTcB?=
 =?us-ascii?Q?J1Xy0NUnQrZYw7tJ3fxg2Ue5Farpt3Ew?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PA4SPRMB0023.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(52116014)(376014)(1800799024)(366016)(38350700014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?Agv5RufhN3Wy3eEeOzXVIycdXX3R6+Y1c6G1TwzTPzl9sfvYnBCCAWEFRk4J?=
 =?us-ascii?Q?5+OFS9uDe3/hA7XJwZGD6RaFHtVpG44wLti7HVzatGzRoV6bg7WrhySO3OMV?=
 =?us-ascii?Q?IVYQPNPH1HbGnvfWNx0P/+NLIGfEIRkB06vqDhE2DHeovoW4LH4+l3BT53Kj?=
 =?us-ascii?Q?7qRCp3B3jdCXG/spLCuyWsOrqvHTeoaxBVJPPIO3hlLGdR6+KB//2zTIBrCM?=
 =?us-ascii?Q?FkYht8eQEdN6xvGoayJlVnRNb8BK76b5Mw3g4e0NH7kts/ksf77FzA4DFBoB?=
 =?us-ascii?Q?nlxzRk1VMn84FXiX3Wi1QBCgYETxYnikrZxdouOVvIRAYtYR107QKJeJ5tRR?=
 =?us-ascii?Q?MBZLqwLW7Zkjxej5QvXWaTl1S8w9Hgan5OcwTPuSlbiTt0WFNJNEaoD3P131?=
 =?us-ascii?Q?ENIftydgkAQxKmYPN4uxVrPDWHnJZkav/IqNE9V9mOMhArNXmsLJ/hTLOweK?=
 =?us-ascii?Q?1K8QfpINBBSdvp4kVI0MYaVPT5kAuXRJcDRleP4i5hTDFls+xdXVgjC8mpgc?=
 =?us-ascii?Q?5iTe3T81eG2XeCHSwvp6vkye/hEDl9xiYn52adK/uHiea3CR5TIxHMh84l2+?=
 =?us-ascii?Q?pNbzVdj27HrZ/2U1BIZdloJkjsK05zLxmQOUXHnhfK5hpypWQQDcN2wlDNvd?=
 =?us-ascii?Q?CPQoVdyAICro8BouZ/Q1vux4fSZ7ZASBsV2o+/jOGCoRWe61wUcLo8TuBTX/?=
 =?us-ascii?Q?GC0N1yb6uQlEXpnnLYuxI9MSZCTUsf1Eryjj1DpfESlgfDh/7kd2DJc6NIOU?=
 =?us-ascii?Q?RlRj+IIr1yzrOZLYSNLV2LSl5WfHjrCmZvHwrWtI1994txU6EALKuEtwEQ5g?=
 =?us-ascii?Q?IIbVQcYy/9+lKD3lyajPxdupi+76626J73RBoYjSF3ZqsxEQ1k5fmYlD2Mlz?=
 =?us-ascii?Q?HtkGKAppQTebdf1AD9idSLBnpA5raDfKAI/900j5CIvbD1Gp3l2mdyuTZUnF?=
 =?us-ascii?Q?QqnR6tujcStGtC5IvU8OX4ys9DVLBSU5p6M9Jw/Fe/gszFWrYA2oOyRjHu1K?=
 =?us-ascii?Q?gF0ANoPV45XUxHhp9sXAZLt3K9YP0XagtzbXHySDfFH/BN0vvFFXEf0aKQQJ?=
 =?us-ascii?Q?xnOqpGg8hVYqwoGx4/zVBX7QoYlUG8vdt+xQD92bvCwJbSRTcQUWj1lbXoqW?=
 =?us-ascii?Q?mCszZKH41b8SWj3iwmcez0XMqbufmYaWS3RFKTgRNYvWne13ntIub8/M3Tc4?=
 =?us-ascii?Q?0OuKWmj+eGHihLjHZY3bWPbH4iDExHyfACh6HUDu6d7B3KnrY0d/jj654rIi?=
 =?us-ascii?Q?QBCEzyYZAsWnb57pgLhrC1IPfmfvPAIU+LRAjRrEkJeG6CEVZ+gPKiauAl7R?=
 =?us-ascii?Q?PTMvrDgex0FLifOpKD6K9dn1BcWS/V3VhbU7Wb+WdBHlrHukbKDtZcBj/HNs?=
 =?us-ascii?Q?zRAPJwi4vG67TDif42hhkgA+IsUIlRzVlbm4WpS6UNZ7mXcdzS+z9YUanjsK?=
 =?us-ascii?Q?8se7lPz6IIIr40TMgBIDAcPsUy55PosFh1A1Vty10RFW7nQMc7tcswLOYEDI?=
 =?us-ascii?Q?N7IWbwopL5H3Vgqils3c0nEWpU0D0f6qd8/p/P3EYh+dNrqNUxF3cHqxaeRp?=
 =?us-ascii?Q?0zqGoPgX+eefaMpEO4xhkhSj7kK+egmBxKI6TuDH0ukyifbyBB/cpeRFI0qN?=
 =?us-ascii?Q?ew=3D=3D?=
X-OriginatorOrg: oss.nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 09499d96-fb3d-45bb-fe50-08dd201f93a7
X-MS-Exchange-CrossTenant-AuthSource: PA4SPRMB0023.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2024 11:23:35.1356
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: yINuT/MC29Taswd4lu0pbGfsr53IdC5QOesUADz92PIj39aQaffeXz11m1S/5spg3rKLEkmABPL7iD43DDzLeIoNmtUcNuMK1AVpDuI52is=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR04MB9936

From: Andrei Cherechesu 

Change the handling of SiP SMC calls to be more generic,
instead of directly relying on the `platform_smc()` callback
implementation.

Try to handle the SiP SMC first through the `platform_smc()`
callback (if implemented). Otherwise, try to handle it as SCMI
message.

Signed-off-by: Andrei Cherechesu 
Reviewed-by: Stefano Stabellini 
Acked-by: Julien Grall 
---
 xen/arch/arm/vsmc.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index f679cced7f..62d8117a12 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Number of functions currently supported by Hypervisor Service. */
 #define XEN_SMCCC_FUNCTION_COUNT 3
@@ -224,6 +225,16 @@ static bool handle_sssc(struct cpu_user_regs *regs)
     }
 }
 
+/* Secure Calls defined by the Silicon Provider (SiP) */
+static bool handle_sip(struct cpu_user_regs *regs)
+{
+    /* Firstly, let each platform define custom handling for these SMCs */
+    if ( platform_smc(regs) )
+        return true;
+
+    return scmi_handle_smc(regs);
+}
+
 /*
  * vsmccc_handle_call() - handle SMC/HVC call according to ARM SMCCC.
  * returns true if that was valid SMCCC call (even if function number
@@ -288,7 +299,7 @@ static bool vsmccc_handle_call(struct cpu_user_regs *regs)
             handled = handle_sssc(regs);
             break;
         case ARM_SMCCC_OWNER_SIP:
-            handled = platform_smc(regs);
+            handled = handle_sip(regs);
             break;
         case ARM_SMCCC_OWNER_TRUSTED_APP ... ARM_SMCCC_OWNER_TRUSTED_APP_END:
         case ARM_SMCCC_OWNER_TRUSTED_OS ... ARM_SMCCC_OWNER_TRUSTED_OS_END:
-- 
2.45.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 11:23:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 11:23:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861114.1273152 (Exim 4.92)
	(envelope-from )
	id 1tOEd8-0000xR-Ct; Thu, 19 Dec 2024 11:23:46 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861114.1273152; Thu, 19 Dec 2024 11:23: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 1tOEd8-0000wy-6v; Thu, 19 Dec 2024 11:23:46 +0000
Received: by outflank-mailman (input) for mailman id 861114;
 Thu, 19 Dec 2024 11:23: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 1tOEd6-00089J-Ql
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 11:23:44 +0000
Received: from AM0PR83CU005.outbound.protection.outlook.com
 (mail-westeuropeazlp170100000.outbound.protection.outlook.com
 [2a01:111:f403:c201::])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b43a3612-bdfb-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 12:23:43 +0100 (CET)
Received: from PA4SPRMB0023.eurprd04.prod.outlook.com (2603:10a6:102:268::8)
 by PAWPR04MB9936.eurprd04.prod.outlook.com (2603:10a6:102:38b::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.15; Thu, 19 Dec
 2024 11:23:38 +0000
Received: from PA4SPRMB0023.eurprd04.prod.outlook.com
 ([fe80::fd16:4665:bad7:33ce]) by PA4SPRMB0023.eurprd04.prod.outlook.com
 ([fe80::fd16:4665:bad7:33ce%4]) with mapi id 15.20.8251.015; Thu, 19 Dec 2024
 11:23: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: b43a3612-bdfb-11ef-a0d7-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=urH1RkzBUk+6oYu9Sp+9O7VS9INPRNMrPcWOH4cUSzBbQnO2ece4LYHe9RKx/KXFvAqrd+Cgj1IXM/FieR2ixAZpG8dQ6x3eSO1D17Z1ZQpctkKQhUsUAc1byBiDPlruuYiYZAEVcYYJD4cMaHmUDs4FotlncNKmoAVg4B+DypqCVB730O+ciH9eUaRQgbyn5NO4nGssP79W0eBRckLagnKV+izhoX9np7zoLOxgnNKP+PhBW+SlimFVOP7h8NYXc2bxk7HaKirfY/YD+b7i/PRbnHH+rmJOZ4LZDF3NOwEdyTPBcJHsDRC1rnbSRsAEJezlADiuvFI27vNEn7OKHA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=1/W+hjvEQAfrqy6fE9YS8QKciaTcdeloCtPRibShYIg=;
 b=oIhCr1MjOVLE8ZLKBg+WbH/CfOvO9aUkYwY2URLduJG0V6O1D+Abkp9LD1AHtpHkNGJK5QD4l5iBufAA8GJ2QxB95ckA1ja4EUuv7OmC2AtBB9TfAq3hPzfc1FAAfoKuILZOPuQNWxxYVdeIOoUAuy7MwjfJnUrHJErcnAEDBAFviwS6VJHHJlMpewaOQMGjEifveJiI02Czmexhrr9/o21moYwL8xdnD+fY7YoJGeykq21U5PIdH/jucoTfjx+IDoYQa1M4Z27gV1GLBd4OsLhTzhyTQQPVnHDxHVIB16PGdHZxKAxPPd+fH+Bsb/M3Q5LVoXpefUPsSpl24g/mLg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com;
 dkim=pass header.d=oss.nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com;
 s=selector1-NXP1-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=1/W+hjvEQAfrqy6fE9YS8QKciaTcdeloCtPRibShYIg=;
 b=IOC+ylazakVlbPGLQ3LZU0v4IcE5VNeoCqlnqeigpgkeGCc3ZgipzSKUqOMkKTSsu7spBoTPEexomzTfogBOyefswgzXSHuKK4nLLLSI27VFFsxuDLG/i2wdlhuPgBwRWTfwlQsIqqniUgMwah5qqYa6DlBqPAhBYz30txB2hY36EoPSCaZOwoXpcV98r5YpaoV7o39c+yAPpgUp5zfDCOwT4eynuzlcqQ7dJkTauyIoYYAtnkok1qqV4k7umd+D3QCPrS0b6brT2YaRfObtwDW5qzcJXC0EI8367PhseOiMh/1gQj/OxAOvJZtPNLRskzxijohE1EdokANPd8+2iA==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=oss.nxp.com;
From: "Andrei Cherechesu (OSS)" 
To: xen-devel@lists.xenproject.org
Cc: S32@nxp.com,
	andrei.cherechesu@oss.nxp.com,
	Andrei Cherechesu ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH v4 3/6] xen/arm: platforms: Add NXP S32G3 Processors config
Date: Thu, 19 Dec 2024 13:23:12 +0200
Message-ID: <20241219112315.2461048-4-andrei.cherechesu@oss.nxp.com>
X-Mailer: git-send-email 2.45.2
In-Reply-To: <20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com>
References: <20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: AM0PR04CA0039.eurprd04.prod.outlook.com
 (2603:10a6:208:1::16) To PA4SPRMB0023.eurprd04.prod.outlook.com
 (2603:10a6:102:268::8)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PA4SPRMB0023:EE_|PAWPR04MB9936:EE_
X-MS-Office365-Filtering-Correlation-Id: 78eace15-e1aa-44d0-b28d-08dd201f9435
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|52116014|376014|1800799024|366016|38350700014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?C64+CwkbKASyhUzKmCrrl8EfEFFjBA20RmbxA7AHcxrh6qvlymEfgiBvK+/0?=
 =?us-ascii?Q?MqoatiQ9LyP+KSbeaUyIzNq3tCORlzJ+WzC1l0zYnUMVWOa+kk7QqUlUpHdC?=
 =?us-ascii?Q?Rhc9zO0ZeKm/9yHW+bVyPf4ov0RU+UL4soHUTnOiiKh9jfQOgdk9s63AL4J7?=
 =?us-ascii?Q?EnGdSXbzcGEJPsdm7L2VsATg0n3pep9wBmACRBOQKuIEPNS5h89s0heVQmOR?=
 =?us-ascii?Q?ry3i6V3YAkYF7bmt4+MKO/g2h+e9ZxG5SLNxv4Zoim8pbvyCQJJP+u+1AMh7?=
 =?us-ascii?Q?lG9zUQNFtDGF6ov45yp9JZ2M0UcO9ujodhkbB60r6Z3/Zv2DJDAQmFhS3/lo?=
 =?us-ascii?Q?KTulzL8AUsU4n+xz0Guo0aclc2AQai1FeH9qj845mO+9Ycha87BCFGQyMRkG?=
 =?us-ascii?Q?v3myFyMxJ436rl7t1hmmaACIJ7ZW6zwG1sJHUfYgwG9dg0fVF1LnWjNGPZQK?=
 =?us-ascii?Q?zF8yL5xWrIG/r+skPRft85rivzYKxoLAwjipVtdTCWfcDFF4xZFEk5nLLbKj?=
 =?us-ascii?Q?EB/7v4PMB0L+VpPH9qIFWUJXZwGnmDaVYIe40g8Tilt0s6JvOB9hZcczvC6t?=
 =?us-ascii?Q?Q0mYMOCs0oVbxENcQRbAjMuL+4zUEIfQL/jfWtf28MT+e7YsbiW6vMJ9Yw3r?=
 =?us-ascii?Q?5RMbxdQVl9hEpFFcG3HK1xyGGNyUgYPZYjAGnbgFHnKXU90oQsmF8HPp4nUx?=
 =?us-ascii?Q?j1tb736U9kqMDs6memiTnAL6abdI4MTqEUkU0b4KGyjPWUXagPPVqES5en3T?=
 =?us-ascii?Q?0ccQaz9+j7gxZ/8lqG2eKIAP9ETOjl8ovbtjaAw4j9xJhiJoN6mpUNLZ+Sg6?=
 =?us-ascii?Q?W+bM/9XbmazRWbeHR/rvB4z0X84O4jrx2EyeXMmQi2flBQutK3DfKkwMmGRu?=
 =?us-ascii?Q?Yr6GubVI7M/BRHiud6q/ASxV9/SdI6vsVbuSZi5dRoIs1fVIZm8AmZCjt3l7?=
 =?us-ascii?Q?1CqCG3zjt8bwzHKOEsIwkeMAVzkDCf2i9pb7S+7WcWK73wMWMIORyT1NP4h7?=
 =?us-ascii?Q?8x9jDlO42CUe9chDgOXb1WYvJTpo+4Ll9P0hpEMYqESAZqtj4Wwx9Nn+xZU3?=
 =?us-ascii?Q?d+fFYLPaci0hvdZz3pbX3puYD6WzkAXLbOQcAKyx+Xidbl3rP63+QeCrg+mF?=
 =?us-ascii?Q?Sfl+AMcMDHUkzt4eolEmNV9lTmZxIHODWJLtgcuJ3/M8gffmGnmLZrlL15AW?=
 =?us-ascii?Q?Pic165d/CeNFrWiELma/yREPWiiUXLJK8S1YhFCIElc2DRLKxZsR7yWd3Hxp?=
 =?us-ascii?Q?YndvbJqYG/uYkHSiT6bVCfkueTilGdf0hGlzumWCanRPpd26gpziHDyQPs6B?=
 =?us-ascii?Q?P9yduyGGCv5+tDRGu28TXlRRtrQSQY61jdR5JbkRvmj7bRbrkM29FGcdn74U?=
 =?us-ascii?Q?VZmKUBl86GaqSe//D3mC4IW17acAt1jYSwwBGYSWOUhm4VdNOObOMAo83Ryr?=
 =?us-ascii?Q?4bn0dMBtNqD78uIbPWpSTjV39Pt7PZK+?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PA4SPRMB0023.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(52116014)(376014)(1800799024)(366016)(38350700014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?4UxHNc9T3b5o6zHqgZ5ZpIuekFfTLaPbDSWycPKDjtD5HKyAL956ME76rUlh?=
 =?us-ascii?Q?A4I76uoSjot069A6j/bSxZArK001otST+cdYHqnNCGR+SywK8KYyy+OYI82J?=
 =?us-ascii?Q?JIkjNrsxZxBjz8yzvRuA+GkEReNBpDoJ/lDXin4aPuwPMIWjcfM+fv/yXAAr?=
 =?us-ascii?Q?fuSasgfwpPXECBzsfufBtGPx1yka0KjKwSISgRk1t48TFe0/lXOVlLNEmxzZ?=
 =?us-ascii?Q?+SdxN3nNUpurs7ObotgEPCJndaBW5vjF1iD+Ta/wyRpDdLh1Kk1LlFe9i4FI?=
 =?us-ascii?Q?Prq1hPj3ozGxqY5VOP+Mn8NvQStreRWMF/U+XTPlWplbxumPERi6Fgx4HzC4?=
 =?us-ascii?Q?F/zi0Yk5sclQsRnvMEEXvy0/qnS1JQ01yoxZUSFaWhW0rOhnHhWq4mydp77B?=
 =?us-ascii?Q?phwiTjqiz+9wHRWNvEz0BUcmI6k2SV6WY6cPkKKvTdkxAIIay4otkoI0Ff1x?=
 =?us-ascii?Q?PG2gOexVyPlh4333pEpbKD4qSRgFhfbP5stHgW/AQAsJWcUfOI0rYtI6Mwnh?=
 =?us-ascii?Q?AbCamcKOCfW5PyOHCs8Oqw0bbrchMQKG6gIdPp3S2kYjHieBDam+GJoWG92W?=
 =?us-ascii?Q?pDSXc/Dk9bmr2SPOpYsjdkTu833XVMSHeW1aCcU3FDOw7GYl4KUWwWJu99J/?=
 =?us-ascii?Q?xFch+z2bhPuMVlyAjHysEJ1smQzuWVMlfWlPzSWPabik8G/+SQuMM53Fw68L?=
 =?us-ascii?Q?Ml+0R3Dvl74qsfJLCQujGOyNj+GKoAnxpltcz/UX/qB5f9xIwACnian8xHs8?=
 =?us-ascii?Q?Hk8oRESfmOyrx89r0V8Wfy7eIdUBn75kKyeH4GrYj7Nhqwgwj7jG3ASxhVo8?=
 =?us-ascii?Q?6YtnpWdpo0yZs4lNFRvRj0YoULvgqsogJWhYlLrcqDiAkr4wrTFVeRerxtst?=
 =?us-ascii?Q?2w9z5+bDsAvVKej3mChohW2yC5gIx3x1DV+ULqXsBH6oBQPAqbXCUt7nhQvq?=
 =?us-ascii?Q?UnohUFXLRsirg4m6aL3IngmJVSRzOXPsdafv0w6wkW8JGB4S/wV33TW2W13J?=
 =?us-ascii?Q?OqK8268BmYdCbvXVvAZuc1a4ewUeRotvSDPwStNe6l7uqwyvno6h4pv+8Q/T?=
 =?us-ascii?Q?zkCuKaJKkonvOBESheb15sriTaqALv3GEIctxB1KiRQikDu1L11LU6kFV7bK?=
 =?us-ascii?Q?Pagq+pILQV22Fzgar+pMLU38jzuJYwgztLSJtiZUki+F0Na5N3bVeV/LoXyg?=
 =?us-ascii?Q?TBwnJsAtMsf0L/KyzAYpD8S0pqj0VJZGzkeklaMNePUMVKUmzTUcEG+BjIc3?=
 =?us-ascii?Q?EGMhenjbkD0vWHSbYI35GNNsi2wTN1Pl2fcRHgD7qmxogpwLOnLdungYrQuZ?=
 =?us-ascii?Q?LP+IjPM4rYMBI/oUVFND2fUfGKOEh/V9dkriAOCiBvOZOEe4YNrRGnqKGW6T?=
 =?us-ascii?Q?eXaspp+5ryrxx2aJze6cHVeN8iE7hEW5Jguq0bykL5Bc0qe2ExTPOUEJ8YkS?=
 =?us-ascii?Q?1XpHst3C5OOa1THCLc5vzdJHCH2qyD8T06yR6XWAWkK7GYaKLhxCOk6OCLcP?=
 =?us-ascii?Q?GPzbyZSk4BbBno38LXY0mKLIHmkkL91+rBm3NHdqJ68SGOH5rIQeTVTSM4cP?=
 =?us-ascii?Q?YUl9UyAdOCCQj2fPgNyq80AI7U+LG3D98wR8Si9VeRm7qxmNcve3uIsbRMwZ?=
 =?us-ascii?Q?SA=3D=3D?=
X-OriginatorOrg: oss.nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 78eace15-e1aa-44d0-b28d-08dd201f9435
X-MS-Exchange-CrossTenant-AuthSource: PA4SPRMB0023.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2024 11:23:36.0655
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Jg6FlOgjuR+ticnup6XPmxdGRNapzwBSh1cjy5KO68cUFRUQm/ohQtllV16D8swoC3/gPJNS2S0y39yMl2spbLz9cNuKusvMU5mmj6HphsY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR04MB9936

From: Andrei Cherechesu 

Platforms based on NXP S32G3 processors use the NXP LINFlexD
UART driver for console by default, and rely on Dom0 having
access to SCMI services for system-level resources from
firmware at EL3.

Signed-off-by: Andrei Cherechesu 
Reviewed-by: Bertrand Marquis 
---
 xen/arch/arm/platforms/Kconfig | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
index 02322c259c..6dbf6ec87b 100644
--- a/xen/arch/arm/platforms/Kconfig
+++ b/xen/arch/arm/platforms/Kconfig
@@ -37,6 +37,14 @@ config MPSOC
 	help
 	Enable all the required drivers for Xilinx Ultrascale+ MPSoC
 
+config S32G3
+	bool "NXP S32G3 Processors support"
+	depends on ARM_64
+	select HAS_LINFLEX
+	select SCMI_SMC
+	help
+	Enable all the required drivers for NXP S32G3 Processors Family
+
 config NO_PLAT
 	bool "No Platforms"
 	help
-- 
2.45.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 11:23:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 11:23:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861111.1273122 (Exim 4.92)
	(envelope-from )
	id 1tOEd6-0000IP-8E; Thu, 19 Dec 2024 11:23:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861111.1273122; Thu, 19 Dec 2024 11:23: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 1tOEd6-0000I2-5Q; Thu, 19 Dec 2024 11:23:44 +0000
Received: by outflank-mailman (input) for mailman id 861111;
 Thu, 19 Dec 2024 11:23: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 1tOEd3-00089J-Qg
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 11:23:41 +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 b278c8ef-bdfb-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 12:23:40 +0100 (CET)
Received: from PA4SPRMB0023.eurprd04.prod.outlook.com (2603:10a6:102:268::8)
 by PAWPR04MB9936.eurprd04.prod.outlook.com (2603:10a6:102:38b::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.15; Thu, 19 Dec
 2024 11:23:38 +0000
Received: from PA4SPRMB0023.eurprd04.prod.outlook.com
 ([fe80::fd16:4665:bad7:33ce]) by PA4SPRMB0023.eurprd04.prod.outlook.com
 ([fe80::fd16:4665:bad7:33ce%4]) with mapi id 15.20.8251.015; Thu, 19 Dec 2024
 11:23: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: b278c8ef-bdfb-11ef-a0d7-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WNKwD6UqSYkW/MZ6v3FY1+O3rCl+SF4ToaWdB8bLguFn5chHF6mSaOyedXnjG7UfYZe4WnVX3DN0gnJidRCECIsblMaq/cLf2mXq+G0AY4wa1tif9b6n8mugSscAAl9TrU99vw0gaGqa8InMhu5pauPu131r2SW+QSIwVHmp2euLGY8p0nOYUncqAcMwMz3K+K36JG3OqXPHkNTGIwuNw+eruwnn8/p2v0ColOEwGsWeT7tv25OkkTV3qqRuE6AgqFRpT9HJpnFYjk9+3OUfZvMPXy8Ho5GbrwrCZfkp6GzmKscaQgkSPtDQ/hiA1z9BAWaP3czxu+a7K+fl+2dg0w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=MMUaJq6ve1Tou6rEBX7gkP59r1mDg0K+CG0KwNKwM5I=;
 b=RFyWCFJ0Z4VtkQsap1BJvBPeZOETI3ueJKek8KU2W3QRbAiV3kvWEv9zQYKq0ZUf7nYFhqgDYgG13yI092sdDqrs8R4xVyEpwq4mS29vXMFrkDK4sjACaBIw7wK7ON1ksM6vIfImdEy1EVa0PkZFjR0NL12MEifE0mW40VjFmerBrcJ6/OYfVJ4bNH+Ey2dTgSAKTv53UsedY3w2GvFbbV3e3S6uQeQKlKNK0cigCM75gxH7IwN0NU0GBPbV1FFHVEzqAGQ6OkTnve1Bwt3N/+IZUBegSfUHDC2HMRecu46FNpd0oHPZDfPUn51b/c4BMHU1aTPS9mt2uJPz5SaIQw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com;
 dkim=pass header.d=oss.nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com;
 s=selector1-NXP1-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=MMUaJq6ve1Tou6rEBX7gkP59r1mDg0K+CG0KwNKwM5I=;
 b=NqzEBju8LouqijJTigN9UpM3Ps9rJRNWkGM/J4e635i0XVu2mBFNeEImo8qX6UsnH6MDQV6NnjBgjAA0nA9I2OffOCT7Lhd3dr52kmHWnf7ad6+I0tE4UabvTxn4ylI62q+VT+S0um+7bajNGvF3q9A8oc2gioxl8HMu5IZ1Hmnt8enrg8CPAuVa1WUvaCuFzfkKnVSkiNkxCKyWJrThdzkTFqJlQdA55DRG1QXqL02dBQdXdnn80jeawXnahErQMGN0LEh/Ytbev8TeR6d8SGmG4OnUtcVG39sq0hQHXpotFowOW5+/P+XOXvbUhlSNx8GRsvcvByDqbEerQuSX1A==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=oss.nxp.com;
From: "Andrei Cherechesu (OSS)" 
To: xen-devel@lists.xenproject.org
Cc: S32@nxp.com,
	andrei.cherechesu@oss.nxp.com,
	Andrei Cherechesu ,
	Oleksii Kurochko ,
	Community Manager ,
	Bertrand Marquis 
Subject: [PATCH v4 4/6] CHANGELOG.md: Add NXP S32G3 and SCMI-SMC layer support mentions
Date: Thu, 19 Dec 2024 13:23:13 +0200
Message-ID: <20241219112315.2461048-5-andrei.cherechesu@oss.nxp.com>
X-Mailer: git-send-email 2.45.2
In-Reply-To: <20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com>
References: <20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: AM0PR04CA0039.eurprd04.prod.outlook.com
 (2603:10a6:208:1::16) To PA4SPRMB0023.eurprd04.prod.outlook.com
 (2603:10a6:102:268::8)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PA4SPRMB0023:EE_|PAWPR04MB9936:EE_
X-MS-Office365-Filtering-Correlation-Id: 90ffc055-fad0-4332-b5d9-08dd201f94b4
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|52116014|376014|1800799024|366016|38350700014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?/eE8bZiKVFMNEkukrSrq4N10Unuyppeuzaix6fJ43ZbfHgTJ2HMvK4+QumGB?=
 =?us-ascii?Q?47fDlOXmES1UFNTm/lRFL0m85tpsz033nuHwpxtQ4BjieYYCrWEMO2ZVx87C?=
 =?us-ascii?Q?AqMfJt9/QPqkBii+fq/0rKhBgOh9JDDQqwGmzejmhb99ej8upz0hDM64cVjV?=
 =?us-ascii?Q?uUr4FDh6tiDLkwxTjs6tQzneAp+2QPc0309dRu+mLWcNH6QXc9na5WreFvV3?=
 =?us-ascii?Q?Q7yA76R4Ri+52DpFWxyzQfsMkJsBeW8enr/dyqzlMkdmY3bL7dDWA8WRFzTK?=
 =?us-ascii?Q?TlYUBKkZQ3su6zoYSp3i3R/KaysI4lUIx1jheyDQ2ApqeDsXRI5Hdv2soY1K?=
 =?us-ascii?Q?2idvHV5fIIiD48wbLXpzvWj/mpoQENIMYmMhw7I6rgxr9VCzk7yBvSYia3v3?=
 =?us-ascii?Q?zP+pmnm18Z7Ij2rVnuf6yg3EtlBOflaJP8gE2Q1DzjJsFPyxfKUlD6x2k1Ic?=
 =?us-ascii?Q?W32Trv5PZBI5bTFva4Zwc5BbgfXVpiXeCTeQkj2OLS9eYFuRA8VeuxLP+RwB?=
 =?us-ascii?Q?YdUER2nLhVtddMNn/VEr7kslTSmmArMrLvA6hXV6t+g6M02ySCxJfmAmZD2n?=
 =?us-ascii?Q?QtCpUzFv2HDsqE58z7BlLRiKsKnv/paZVO2IsecZvPmg5Z4Yt1GK9tqx3LOz?=
 =?us-ascii?Q?qjoUnAVCFm+Lkzz7oJeS+pdNDtMZvNQ9+uWq4DHpiiKqgxGYkonwXd1VbNrf?=
 =?us-ascii?Q?lMBbGno8ILqc+I4Y6TiKUqjeNaovd/AqUlDlv+GNge5gyg7IEML3Ir4tCDcA?=
 =?us-ascii?Q?QnbfYABCQK37DKqQkrnEn6akjpRgAyjIIGJ2kogk1PlhgIIh71ZF88AKGiE7?=
 =?us-ascii?Q?gWn3MLKrXYV8sh7xREkOO9Hp6UInxCrSycj3VfMRSw/JP6G8sHY8gCmG9qgG?=
 =?us-ascii?Q?DknL3WoGdwz/WYoaetHwPGvRhLCpZxxWxJlGCrZfzEr7Du5uWPOCD05EQTSM?=
 =?us-ascii?Q?0VtK1DUoNjYqPrpNZoQ73MrrlxbTnFnqbyF28tTDWsxEL3pkVsea+tbrU63e?=
 =?us-ascii?Q?EgdKS2SNAc/HX3JKHm8xLa4mNG3V5BziByJqNl3flLKxm8wV7Hngh6AGeoPM?=
 =?us-ascii?Q?B+7W1WTqbARctAmWHFli3HZT1xO68QD3SMokKzj59mZ8ZQDB6AmYF5MJWfP0?=
 =?us-ascii?Q?3gWosdTUIvKbrXbpNgYFogTDRg/OrlUVzbUNrg48MYfXby8hA00uMe+7NIIQ?=
 =?us-ascii?Q?vOoZdR95uoE7NdJiVpoWKVx0/vdyuDo+wkHxs6vlrQ+u+Tfxg31P7+IEuloq?=
 =?us-ascii?Q?AmXEFhcH7WMt5E93PwwNDbIo2TOva3YN9jraE2gR5NJ2k1Q0ORmRgOA2FB9t?=
 =?us-ascii?Q?Fv83a1D610/0ff6MqCw5cUapVCPsWjQSuXWTDe/UmEQU/ekMZcelqibfnH75?=
 =?us-ascii?Q?RUr30wW9FVTmF7sVlNQ02qkiXZCl?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PA4SPRMB0023.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(52116014)(376014)(1800799024)(366016)(38350700014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?AGutJgO7Gf+eqtnufWV3vVyZYA3+TZ4h6QTxt4/AtKKFn4argOgNYY8RZhrX?=
 =?us-ascii?Q?sknlHqcv7MeUNadMJcUL56Yzge99tk4lVSAInoGnAUXWE9xkff7/dI3nCyIf?=
 =?us-ascii?Q?+KAxLp3HGkMtARRMffeoRhMIh3KARh522uoKyh75LH4XMUROFyQVTPa9DQQd?=
 =?us-ascii?Q?sARolK+UDM6yIAaM6NCastq0UHtJizakP0UmU6pjjKjpAJ5GkaO1fwjfAP43?=
 =?us-ascii?Q?EaaJ9XS9GwuwZAyazLFWBEsC034hqZdsfpvQ8v9Lfni9pGlEyegmMR5bFknI?=
 =?us-ascii?Q?Md5/cVuZfO7RrM71RPfg27O70YX7JCwY/mJPV90vP9GpfOzowM5NiPSvq2tL?=
 =?us-ascii?Q?B2rWaJiUFPRJ78c5NSSoQfpHfxiBbhhP/lzXRADPnLjG4gXTdKjETfRbv+Q1?=
 =?us-ascii?Q?BrzUWuHx7zquaXPY0kXZbTpaQtWjFevaVemy+hyVr7CqZZ0h6N+KA6vAPHMZ?=
 =?us-ascii?Q?dYArXqpWnHzX+U8P1dmLxmsW8lv3Mu2bnkVHdR9HBlzowWoPyYs1KgUnROQ1?=
 =?us-ascii?Q?NSS2SKgp9J+3jz2HDLaqj3RG0p1iwd9eIL1lgIfvpkDLRiPPx4jx6pGpYC7D?=
 =?us-ascii?Q?Ohz+zQn80SRmm34sbNfWFfjSMpwyqSTZlHCCC51ZI9E4nQY3RrtM1a/d2k2F?=
 =?us-ascii?Q?uT+jvfuIUBbCJhI8QwefkqTOu1rE45fN98drrV8tnf0yb7zdsVnUg0u7uMfL?=
 =?us-ascii?Q?y0EunkzZsLhkMytu+jbGIh8vkfkQMRm/cgyviBzubJBlVXuIjsyjF38Yt16A?=
 =?us-ascii?Q?89Zkp5Zbq0aO6hYqVQJZM0ZSbdPLoreqEQZAfZVmgXs6dizuumAV8J+EBBms?=
 =?us-ascii?Q?VrliKVahEdhKEXLvQkcntzBtnFlq/xanuhDwG5nExGRdlNfATpGSgpPbY0tp?=
 =?us-ascii?Q?Rcphe7OEvvzSwvL0TLTEPVj3xLavpCfLS/lwwDVEEj1Mhr2onD9tySUSftki?=
 =?us-ascii?Q?rSPZUTWEaitEYm6xP528XYHKB1MwbyI6imWYGqy9lF0QmSY9iXyJYzyUFvOU?=
 =?us-ascii?Q?SohZw88ycoIIy/Cy6PJjYwsESdzUv4H6jbdXhiy82Hj6KFU1IapmAhm7jxZi?=
 =?us-ascii?Q?4cXKzfL3LhDZ5YfDYmYClaRubhhQbYnYexUrtivFLrTCsZxzezw6E6hlju1V?=
 =?us-ascii?Q?Qs9yYeFu3X5kMydsAus/C/MeV2j/hr+Rd3K13+xybl0js+Er0T61AG84xzQy?=
 =?us-ascii?Q?3CBytvgsgeth54xJ+OOmRK6kb/VNzKJJSn+GZVdchkYbLoppcFk5vuSGf14c?=
 =?us-ascii?Q?MkNDk8Nt6Dtrad5I/6V9OUJzwiSap3KJSQ0JiQeTaWWm7wOVidiy1GOwE+jq?=
 =?us-ascii?Q?Ev5uVDQl5STcWb+Pk/AZUYBDDY4gZKgoaCkwvHJy3Bhi8JkkgFeP4GyI9GiK?=
 =?us-ascii?Q?HyVJQXE3aZHXMpsc5HSN0Ivqg8UgY3Zo4kauUbsLG6wNMfRBzXvgrJSdjERp?=
 =?us-ascii?Q?KUJWLheIs0vS5RWVRSgwFmvfFjBoPUb9DqH7LKSfU2diRlA0CaYFCDxQj8rV?=
 =?us-ascii?Q?I7OSz5lVHQB2zgAoZsWh8oTvtm7stVL93Ncw83RStiVmO7xZl4P0dJR6o50P?=
 =?us-ascii?Q?q10TJcwdRRZdfmg8/hzp7LPRicgpnWXiCm/Z8Ii9B04jPbnF5JLFXHqJehj+?=
 =?us-ascii?Q?oA=3D=3D?=
X-OriginatorOrg: oss.nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 90ffc055-fad0-4332-b5d9-08dd201f94b4
X-MS-Exchange-CrossTenant-AuthSource: PA4SPRMB0023.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2024 11:23:36.8827
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Kmqnwft7PDrExYmMotRhpKZdWMMZmPlB2cMsQPPYJLsw4B+8Ftc5YIAUrxWTFP7+b0RfJp/rBjTpWATizhFTJX3TjGl/qh6JPgFfQfdjclo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR04MB9936

From: Andrei Cherechesu 

Signed-off-by: Andrei Cherechesu 
Reviewed-by: Bertrand Marquis 
Acked-by: Oleksii Kurochko 
---
 CHANGELOG.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 15f681459f..bda43b1efb 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -16,6 +16,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 ### Added
  - On Arm:
    - Experimental support for Armv8-R.
+   - Support for NXP S32G3 Processors Family and NXP LINFlexD UART driver.
+   - Basic handling for SCMI requests over SMC using Shared Memory, by allowing
+     forwarding the calls to EL3 FW if coming from hwdom.
  - On x86:
    - xl suspend/resume subcommands.
 
-- 
2.45.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 11:23:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 11:23:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861112.1273127 (Exim 4.92)
	(envelope-from )
	id 1tOEd6-0000LV-IB; Thu, 19 Dec 2024 11:23:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861112.1273127; Thu, 19 Dec 2024 11:23: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 1tOEd6-0000Kz-EJ; Thu, 19 Dec 2024 11:23:44 +0000
Received: by outflank-mailman (input) for mailman id 861112;
 Thu, 19 Dec 2024 11:23: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 1tOEd4-00089J-Qi
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 11:23:42 +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 b2ab163c-bdfb-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 12:23:40 +0100 (CET)
Received: from PA4SPRMB0023.eurprd04.prod.outlook.com (2603:10a6:102:268::8)
 by PAWPR04MB9936.eurprd04.prod.outlook.com (2603:10a6:102:38b::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.15; Thu, 19 Dec
 2024 11:23:38 +0000
Received: from PA4SPRMB0023.eurprd04.prod.outlook.com
 ([fe80::fd16:4665:bad7:33ce]) by PA4SPRMB0023.eurprd04.prod.outlook.com
 ([fe80::fd16:4665:bad7:33ce%4]) with mapi id 15.20.8251.015; Thu, 19 Dec 2024
 11:23: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: b2ab163c-bdfb-11ef-a0d7-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ROtRYIQ3PqmooNE8ejhwSyf7apZFqZ70NhrIZL/G6S0ACoGgdO4sp2oMctSZtGJ+dID/8YvygkWvWJt1NJXXMSRQ3uokPa3l/GGfAIBBnYzrudO/qC0nhvrjyLLvPy4zd44XRHHc8o965OZeRY6aTTRCfLL2j3UdccYfXkhu9pf4JuCGL3hAIFOg0ZQws1B+T7YQ0fHneqyH9hD4O/rSUhoP8RewR9pOAstdO6FHzBDAOuHyPbZVqrWVN2wHreUxrqyxdA0TNx3YHnW+N6uEjDzhDB4+Wy5pvMSxOjudDXu87jQrM4tbLDrjqtAWbdXi2uyKL9bvPvHrUj1GWSGQeA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=yuw7cnOM3mI8njSlNPRlEkwpuzbqcfYC3MCc/8dj7Xo=;
 b=v7xGyYWxbwBZT4s5qAP/p8tHqIM4q2ZGItoZ+q36BDRguyMn5fvYvtyc7KT7ZeVSalRsGdS9+D4u0T6PpOaFml9cu12LYdRqZxxi3lAIsAAKcb3whrfxX0wFVZUMtTn5/p9+fn4mW6Xa54jr5nY7XEEBxA8+8uP5furQ+lo1Zwdx0MrsuS0zMlD5LXiIHQYC5UGw8PCjF8UVFlad65fxF1lozbinxb9/qL0cRT6+jooN6/wLsp64j/TYIARhG2wS1wdJKpaapl+pDRrTyGO91qaBcZk+qIGx51p2z8UE56XeS5drEYb6im1XX/1evUzIBejoocL/LuyBLHi1OI6vTw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com;
 dkim=pass header.d=oss.nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com;
 s=selector1-NXP1-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=yuw7cnOM3mI8njSlNPRlEkwpuzbqcfYC3MCc/8dj7Xo=;
 b=UKwQ7S8wdL5cc7IW/J22zkostYVdG/KzUISzVbRqGxgJ2TlfuSjyibnm/1VU/wGQmmGF8cBY17w/gdnJqKKePdvzW8IwqBq4XkRhqMXU12TXmAA6zYHp73HVHvJ++vvXN1rQRG9zjtBrYyJpdDSYxC85R4cqOZz2t1Bikg7xBlFpqoEFbX7d6Df77UPhmuS2QmlMWlceSdYb48Gf+CWsWpJi2Dx/dHa5Erenj9ppCYe/HqJhK/XGNPS7OHTQqlQemVRCAy1tzfB/jBdGnQt9TiTLQ6TvoPayR7bX9Lv2qaPK9Koo3fqkVWYhHrRSis9DWX5FWaDQ0BukZEkcOx9Mlg==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=oss.nxp.com;
From: "Andrei Cherechesu (OSS)" 
To: xen-devel@lists.xenproject.org
Cc: S32@nxp.com,
	andrei.cherechesu@oss.nxp.com,
	Andrei Cherechesu ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Bertrand Marquis 
Subject: [PATCH v4 5/6] SUPPORT.md: Describe SCMI-SMC layer feature
Date: Thu, 19 Dec 2024 13:23:14 +0200
Message-ID: <20241219112315.2461048-6-andrei.cherechesu@oss.nxp.com>
X-Mailer: git-send-email 2.45.2
In-Reply-To: <20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com>
References: <20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: AM0PR04CA0039.eurprd04.prod.outlook.com
 (2603:10a6:208:1::16) To PA4SPRMB0023.eurprd04.prod.outlook.com
 (2603:10a6:102:268::8)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PA4SPRMB0023:EE_|PAWPR04MB9936:EE_
X-MS-Office365-Filtering-Correlation-Id: 147d0a65-5201-42f0-8741-08dd201f956b
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|52116014|376014|1800799024|366016|38350700014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?5Hl8bxjNXT6oLth6yT8TT7VQBxNQPzardcnuc6Iv+n7F3g4J6uSUPRPMl550?=
 =?us-ascii?Q?BElEA9Wo6iLtvXJUujvTrdXvqd/VRNXR14aszYhSDpUn9Y/IcaA0HDKeskCD?=
 =?us-ascii?Q?EtMh2ItG6LzFXqS7EdqjJFMqFi88zLfF+Ry+KJqqos5UC7eyEvYqpqjfqzWq?=
 =?us-ascii?Q?fWMKzKGq7w54YLhYS+sRCAbN53khkvmNOVen6OcO06KlHf//S2d3Xp5FEzIE?=
 =?us-ascii?Q?6eym2Lk9EgS2AXMYJFKlxxfNLjvIk5e/rzjCR7VtEh8giRzpqIJzTWlN9iBb?=
 =?us-ascii?Q?nWU00G7mig1EyTrc+R3jB8XhRBYre/rG0u+Rg3B2SZL/ENOyFbHtGWwDDuhx?=
 =?us-ascii?Q?eOcE9c9i5U9tA7aGI2KlAMfIr3xfSxdJvc8sSIeNF4CjifvjzvTEgE8iI7rG?=
 =?us-ascii?Q?5HkTSY+Lcma8ZMbmmn1ly5rkPusvit2QBirWyTd0hJs/1szZR7Ig6hZaAwbp?=
 =?us-ascii?Q?8ra11iskVjsVTl1R36JwVux7cg/KUF+6HTdt6TKuTUvPnhb/78Pp34vE/+0R?=
 =?us-ascii?Q?yR/ltz9yLfB8th8ilrt8bOvjCRCOHkN2GB+GkeRAtAe6cQbJZvM/BQjXHc69?=
 =?us-ascii?Q?arWupdxbTvIU9o6fY0kBGTUaGgMNc/yF6Eu8s2maz7a3jY+eZGNTjbkMoce+?=
 =?us-ascii?Q?U90R4bMRj+759QI92lDc8f/3abhdV7uzZM6ALJg+3JNM5s/jZG+ro847HnJe?=
 =?us-ascii?Q?zCDk4WfIGrn0HyRROUEq0xEhbvPyZakzFsAtEgsfTAEQovSRpyzXAfAFEHRA?=
 =?us-ascii?Q?/pTOW/04MiDRA49qSN4VDxSK4Symh7gpmO+unURxikCDzzp33eA0KXNVNX7p?=
 =?us-ascii?Q?tUBXWkGXMtomcrFp/DMzpHBs6PZDps0/tZDh1EdXZTDW/1HxaYTeQ0OLOOh7?=
 =?us-ascii?Q?OWBbk8t3RTBCdzV53RdJsArZNnjinvgSpPsW+SSbOCNSVnFBzxqsmWN7aVw2?=
 =?us-ascii?Q?eb9pvcHqf59g46C7HlN3k467WisnNedjQ+R+vieTPtCfZRJyyZR53Hd9Y10l?=
 =?us-ascii?Q?9KCwQoZGKvITUxwe3xmIIek2CCoQtsqe8dvtdW0CvmjxGzYK01yFUCfTKiU3?=
 =?us-ascii?Q?p7RT3RDKeYNKvybxDvTUNqqMn91gl78W4s/5R0AQ+nW5YERqg3GFpg/aPvH0?=
 =?us-ascii?Q?FnXgoJ9YFdZYbr9JFg0j/f0hC/dBVk6hGEMPD78tP3145H8HS/uzipF1j8l8?=
 =?us-ascii?Q?Mib5S4IWInMx9bpLTyNS6Rjrj8bc9lYloduHrT+37D/9SrsGsAdZLB+rx/L/?=
 =?us-ascii?Q?tRgvsqR5tAtnhPJvZs07QWllEVAyqkfOvOLmMN4Ac2kv8PLeQerJXkdX8IM9?=
 =?us-ascii?Q?DlLiBr50lAEqEh90KUMV1Ewyy979/djJvtR2VTuSFkDB7FJMmw2KNv2Dyrpz?=
 =?us-ascii?Q?Q6A4URcZyLSE5iEgqDzRxBX6isWoIZOpZpZJNPIbMDA8WSPaEGPJ+79IORas?=
 =?us-ascii?Q?jCy6zg/u7q18467MrYw67okaeLHJiQb8?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PA4SPRMB0023.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(52116014)(376014)(1800799024)(366016)(38350700014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?iMp3YRZa1Z0n1XEzbDBsJZXBidCwULkRxIiaY8wh6RtBGzbC8t07Ale0BEdU?=
 =?us-ascii?Q?5Elo2fXw8dNedThCv7G8sdrcnLUo07uwxtZFWL0VzZTIEXnbDJ51DRdLK8mG?=
 =?us-ascii?Q?3+fOwBc+GgqvUXEwWLIguhzE23KwqaYyn5yOg/JHkJhQUVYvTsAYtYbWeYdF?=
 =?us-ascii?Q?OFkoHzZ2wCyCBRkcO3sSajuDgtuPk4SaLvgf2MYS60f3Owt8brnrVEDBpM8n?=
 =?us-ascii?Q?NQ7kbMOaFXwG5z7FuarSkF4smRn3Dx+yaA+rKu7NNUN+ud/pF051/1UWKwVz?=
 =?us-ascii?Q?o8vGC8RyrAy83885TEqJVatyeJgS4T6Z5zEOyQLJ+54Vt8OW/lewOCVNCJBk?=
 =?us-ascii?Q?9YA26PndJy54bsxBbzpe+kDoiJO9eqY8Owmoxd8gLTOZ+pIeDGlPst96f9WJ?=
 =?us-ascii?Q?FhzE+a4bfeqeyxr/kdRtuXOlSI3XIvcca1tk0RHHfcOXdTCfPCixN8omkTU7?=
 =?us-ascii?Q?bgDTDPDMb/N5tja5RQTFPcqQBbI2v58YHazP2RX9W7tnOnrYvFk+a5eEw/Nk?=
 =?us-ascii?Q?qFY6asa89QcfepqzYuBgXWz3HybVa7sWFK8m6JPBn0OnSMSKyq5RtcI/QzNd?=
 =?us-ascii?Q?vahWw3XuAMHwalzUTAj54ch5jenqhlp8dVrArG4yXVyvoi3aqVVxoqAsg6tQ?=
 =?us-ascii?Q?cPvWO/KyAjKUXeQeevPk7q9043RRGH/t+TblIX/+76ENXoCGUXyMtRLP1hDN?=
 =?us-ascii?Q?dsL7TjFLvrHXAiJV9B9QL6do6uwSlRjHoHen995x4EL2wrh6sQh4PZFIrYiT?=
 =?us-ascii?Q?/MewElWwVkP8ECZfOxiIQAsrZ+Aulnp86/E1Dq8e/LNs92Qj5E/gHYw+rFso?=
 =?us-ascii?Q?ObL+fIHYdxP8Rh0cjXQFguwh3UpIPwy3hVnMgdnfMlvUr6I92knzaGm4GlkI?=
 =?us-ascii?Q?nJs/aLpfeQiDeGt2Kc8psCk5OZ+sKiFBNvMHpHfkItXUWNFqgW76q/aOYWSC?=
 =?us-ascii?Q?QZOFrJwkNfMeSQ0QnPkAApaNnCUq9SdMckznxDP7TzFeXSuYhyej9sbyjWFr?=
 =?us-ascii?Q?cXhwcYTrEmCAPJPmtCZQo2EgtrC9SvoWNm8cOpVAe1iNUZOwl/zBKrLNPdMT?=
 =?us-ascii?Q?l1ROm+sfmqDprApUs7TAbpgcCS7+BmLkcbBgiQPLjnk0UpQg2Aktr/Y0gdmh?=
 =?us-ascii?Q?NdZUhXoCrLvTpdD8Od3AyafwT7RC4HukLL01qYhTwAZzHb9Xv6GrvHamskm2?=
 =?us-ascii?Q?qOZ0gvA9ka0SdaoCwEqgSn3sn7BkJ0urwEYTMFfpK9+ru3lacDUh52t+eKMQ?=
 =?us-ascii?Q?6YG+2sw35SYIDeuf6lfJ/FbWMWyVkdWof2yqtmOG7bLGbFWEhmfI+URVAD21?=
 =?us-ascii?Q?RLlXWpHHQNVd76zhPPl6g4ZohUHLdE9XujbYak/raDnSRrUcko5C+1HKUbCc?=
 =?us-ascii?Q?f/CxyGfdZYJKYaunuUHiuK6dw3JJAORke4dYkbcgZCPBjkobSK88Zv8h7jsu?=
 =?us-ascii?Q?nYkp5E+Lmm8jPSJ/hlOmLzVo2XMYI+B58OnjpVJpNF2uv1hSqANpXBmo26g+?=
 =?us-ascii?Q?OYDyyq4xAxO++P/eDt3IqzFjldk5C4hwdmcIA8SY9CAfjl40xnf1kdJ8mIHR?=
 =?us-ascii?Q?kX7g4U9j/0kVhPdlNArYKu2G7/E4CBvAHxMy7Z7YYDUZI4FqUv4XHuFrxsfQ?=
 =?us-ascii?Q?NQ=3D=3D?=
X-OriginatorOrg: oss.nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 147d0a65-5201-42f0-8741-08dd201f956b
X-MS-Exchange-CrossTenant-AuthSource: PA4SPRMB0023.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2024 11:23:38.0989
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ZjRqoNVUn3UYS2KfLq9sKoiqL5ahLcsQ7XOQ7gTHNCYjwUmPVTmJCPy3akLpO1m2bNodo9e1OH941FA174ZSGvOxz2/7rkOFuZrF8VgIjE0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR04MB9936

From: Andrei Cherechesu 

Describe the layer which enables SCMI over SMC calls forwarding
to EL3 FW if issued by the Hardware domain. If the SCMI firmware
node is not found in the Host DT during initialization, it fails
silently as it's not mandatory.

The SCMI SMCs trapping at EL2 now lets hwdom perform SCMI ops for
interacting with system-level resources almost as if it would be
running natively.

Signed-off-by: Andrei Cherechesu 
Reviewed-by: Bertrand Marquis 
Acked-by: Michal Orzel 
---
 SUPPORT.md | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index 82239d0294..1f7867bd32 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -928,6 +928,14 @@ Add/Remove device tree nodes using a device tree overlay binary (.dtbo).
 
     Status: Tech Preview
 
+### Arm: SCMI over SMC calls forwarding to EL3 Firmware
+
+Enable SCMI calls using SMC as doorbell mechanism and Shared Memory for
+transport ("arm,scmi-smc" compatible only) to reach EL3 Firmware if issued
+by hwdom. Some platforms use SCMI for access to system-level resources.
+
+    Status: Supported
+
 ## Virtual Hardware, QEMU
 
 This section describes supported devices available in HVM mode using a
-- 
2.45.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 11:23:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 11:23:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861113.1273134 (Exim 4.92)
	(envelope-from )
	id 1tOEd7-0000UG-2Y; Thu, 19 Dec 2024 11:23:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861113.1273134; Thu, 19 Dec 2024 11:23: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 1tOEd6-0000S5-SG; Thu, 19 Dec 2024 11:23:44 +0000
Received: by outflank-mailman (input) for mailman id 861113;
 Thu, 19 Dec 2024 11:23: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 1tOEd5-00089J-Qh
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 11:23:43 +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 b2de0e23-bdfb-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 12:23:40 +0100 (CET)
Received: from PA4SPRMB0023.eurprd04.prod.outlook.com (2603:10a6:102:268::8)
 by PAWPR04MB9936.eurprd04.prod.outlook.com (2603:10a6:102:38b::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.15; Thu, 19 Dec
 2024 11:23:39 +0000
Received: from PA4SPRMB0023.eurprd04.prod.outlook.com
 ([fe80::fd16:4665:bad7:33ce]) by PA4SPRMB0023.eurprd04.prod.outlook.com
 ([fe80::fd16:4665:bad7:33ce%4]) with mapi id 15.20.8251.015; Thu, 19 Dec 2024
 11:23:39 +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: b2de0e23-bdfb-11ef-a0d7-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qLZTV45yvFyoOeTMoSY/TRfQOLfVzIrfDqgCRDVZsNyfvs5bS9Mw2wdpV30/YlAtMseOEwlBVBjyHJ3tDUEbJV2bulcU0xA1rYEwhPyCCeyWASMvbn2JK7WyDnTQcXDjImN/XJ3NoXp0uxdlAreIdIL6VsUE2/2va1lgUo2re+YhHFuuuDWpNH3dxcZJKCtEqt2E018QTPjLrqJKRua25iV7jTNbHB6+kfJgMGc+AsJpg+nrOmk9/2WW2p/Q5HmUt0kjodd+i4YbA9AI5PCQtNiTVbdl0xK2P7ZgAjUt6rnNfEhGhWILOG06wxgFNgXxW10DWhzcdq+bnRKDtvFwQw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=TE1ptO+swG0YleI2LOVgM8SYYL3IrYeRWVns++Tpy6o=;
 b=orhFQH/s1bNz6Mx7mV9Zy4wwQpIU2SY3lyN/pgXUkozN20fhGiUFCMWiSN8YlSIZLAO4X2O8zlzJg1fDr5W+QIhDAEHi3jqzqi+NOQ4BE2hBp4xYaYtMnhaOROL1iUNaK1K7Wl1GXgRdIc6LaTuaYzoMdAIp/11Qt853yaO4lbld24EDHuf9oiUrwUFaAhbqlKWSeuQJGzRkXskhsqwGE9t/IEIP8jAd93o3I5KADVwngNNXF3u3ZMpNRPTXIdqhHUfx3xP9CX0vkHh/Qv68Js/U0AKF7dPNiN8uiy6oEuEyEzQWVFmGaguGzVeHIXhxavmZFmcJT32G4QPHwKddqQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com;
 dkim=pass header.d=oss.nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com;
 s=selector1-NXP1-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=TE1ptO+swG0YleI2LOVgM8SYYL3IrYeRWVns++Tpy6o=;
 b=Pg2bSNHF6ZCY/IOIfk1mVt56ifZAv0aB2Cvydd82UK43ETA1BZ3SKHZAWjhXbfkx+ZY2H3viVzUD13j0lDQ1MpVLHPxRHWPv+d8evZRYi4RU6cE0xOShO04vUeLKP/HzEQOZpRs5gaWrGWU3KF2XM37cDaWH09jKJBx5leed+8WNp9bd+61sMs+EAuzFvgsXkfNd3GJN1+lt76d9/l45IVSRQ3XhrNDQBS/+rZVFlllxbG9y3lM5xizx/5X3nUZFy3EmQcKM35gfnd49gtWjq1GzF9gEPVJzSgpaW6DIKq5XnqRr+1lzzd/HJs7nA5B8bgS6h3Dm2xzEb8r5AOAfOw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=oss.nxp.com;
From: "Andrei Cherechesu (OSS)" 
To: xen-devel@lists.xenproject.org
Cc: S32@nxp.com,
	andrei.cherechesu@oss.nxp.com,
	Andrei Cherechesu ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Bertrand Marquis 
Subject: [PATCH v4 6/6] MAINTAINERS: Add myself as maintainer for NXP S32G3
Date: Thu, 19 Dec 2024 13:23:15 +0200
Message-ID: <20241219112315.2461048-7-andrei.cherechesu@oss.nxp.com>
X-Mailer: git-send-email 2.45.2
In-Reply-To: <20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com>
References: <20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: AM0PR04CA0039.eurprd04.prod.outlook.com
 (2603:10a6:208:1::16) To PA4SPRMB0023.eurprd04.prod.outlook.com
 (2603:10a6:102:268::8)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PA4SPRMB0023:EE_|PAWPR04MB9936:EE_
X-MS-Office365-Filtering-Correlation-Id: b608cb2a-591d-463d-9148-08dd201f9617
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|52116014|376014|1800799024|366016|38350700014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?BRMODXdnI4BtN/d2YjjS5js+PGDUEgq+pVLMwl5fr1HF1CQbgnKlR6cIoBH2?=
 =?us-ascii?Q?6TQ0QJldvvOz+MjIVGz0x8NvtibfNemjgVq+hi+K9+Y72DfF3fC13LtWG5a+?=
 =?us-ascii?Q?TBHb7e+ex0qbNdGAnjVw96W4VvZZ4Rgn0MhAHPnm0jlWnrt38ZXZ5rilb1Yg?=
 =?us-ascii?Q?pJS2b0kMUKzvuKqy5OpzaDoWHcca/STXyBGHrV0ba9N79VZSf7+nvWQrdAJq?=
 =?us-ascii?Q?BVeLZtWJJcJzAD08DcetyxyoD7jpk49hUEAUeXSiuyYOfKZoZEOn5Y5OEFbP?=
 =?us-ascii?Q?lawuuIit7V00VQkTw5HfPiKuMFpaSposgKuJYiOsvmZsPbwAW0zI9hLSevVy?=
 =?us-ascii?Q?a3ll46Vo7mZSAPr6s0TOscVuLfVGEajMX5RRgEzT7FaE6tHIE76SucpTlfhj?=
 =?us-ascii?Q?8WlJncWKkkeLMCXokc5jacugA5OvT5nZb99s+Z0Hp/6TTNNXU/yWT7sVWYbn?=
 =?us-ascii?Q?wM5vw97FTY3sx0mG2HhXJ2EE0FMXmGBBKUKFF1XEoF3HPVQjcAi2ii5/7h35?=
 =?us-ascii?Q?51IO/ijyfeNCMDrw0D/rLxfTjt2osIK9s0slKmqh5J+QnGOrAmetk2yE+U7i?=
 =?us-ascii?Q?G7EWYCmvPDIY4q1zX/RgDZmq9J24C3ZsSipghga3ywbQ48jSXdclhvX+SPJ0?=
 =?us-ascii?Q?xAtUc7diBUizCQgJghi3R3hqCi5ufVTkleiSZp6uk/3ng/YSGjnjS5UcizeW?=
 =?us-ascii?Q?NsaSnVASYDlMuF9+7VCaIoCLZ6bbhJP+nPySdMXVqoXfS/MAo3RmmdgpI9mn?=
 =?us-ascii?Q?a0/hHVHf86GhLtC5EIEIBat/Zyfs6hTyNNBK1M1VdXrt4Cc5eSIurkCyX9NL?=
 =?us-ascii?Q?GLExmUELtf7E/fQlbg01XSEAALlGfLlNkjuYAcHpiShEOTfLGaERV1kFkar6?=
 =?us-ascii?Q?wmNgunFxhm9Mn8ftFaqEGznF68c2y81Gd4X2ika9WZVNHhIrqqB2+8xrwrkc?=
 =?us-ascii?Q?FEy58DvortIT/eH+22FV3oUucZUNwQIxXhWqbSjS2rTmnpHTHzwoneJDyXmp?=
 =?us-ascii?Q?S7Sa776UV6nQXysZiGMkh7Bx6lpkWdkoXGnyRZBNUtIObkaHp31/bA1AYb/F?=
 =?us-ascii?Q?6rcOso7ySmDFTzWNLVptzYZLuTL9k8ex/YaVac7JCPGuabT1N5lMH2zQlp/H?=
 =?us-ascii?Q?FcGUKet1W5yfe0WwbuVIvX/Yq7IQR7sF1awAtl6WJUkW5Rn0SGr0ZTRbI/Y6?=
 =?us-ascii?Q?pFj//ne/kR7JHy9u0X8JFOJPVQMmQq8lNSO1/WfIKuaZOKQWmI/NsCN80zib?=
 =?us-ascii?Q?IaMEsojb0BE71cqK164557WiIDyLRLoaD+pIXaxXyOOXoYoBlOqFIGFHUrmt?=
 =?us-ascii?Q?OWYd8rOtRc2UU+g8owuTnFxWj/EDZCZ72d13go23tO43+SeV5y3zgrpM911A?=
 =?us-ascii?Q?eJcotmbX3L+6dUw9Xk3NSdIfEgXE?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PA4SPRMB0023.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(52116014)(376014)(1800799024)(366016)(38350700014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?cb4/heK7pNLDlYdgT+zgvM5wQeCxsV29scc4s+4jxa2eDw1YfbyglR5Esu6J?=
 =?us-ascii?Q?vcOcIykQx1eP22JkPw/GAnGnEHXv/nDkONG73Rv+YBJu88x4OP3rOrUKy6Ms?=
 =?us-ascii?Q?j+Jam0Ht2LAfNp7xbVgW3oHSS9HZD+CfIdq8CmfuG8Rm1djOxRfCmQ1aTzc/?=
 =?us-ascii?Q?xEDLjECqgayBXQokOgIgv5qy7UVIqCGrfUiaxrKXNaLr4UhDnRvuDi7qSL7z?=
 =?us-ascii?Q?tT6gfK+tKHOfHP4PALj+ZmQ3Q8SovbRLCco+Y/ihyXojTdRli9jSM9oIgHiq?=
 =?us-ascii?Q?UvdvWSArHPICH5Clr9j+4EtxFamvSVmgV9/pACk2xAN/DHyFV53WH8PDkn92?=
 =?us-ascii?Q?cDZe22CXJi6833vjHuKUM4Sla3Ziof9z6yCuFXtbQANia0G/5yUEJepek0pm?=
 =?us-ascii?Q?JzsWeEyQixgOSIE5oLWqs7/0i5ufDoH+8i4AeSuS0pCNSwUPSdVFTvzwRMgL?=
 =?us-ascii?Q?TlbrhbrBxTtJy3nHvkMYtrFWqm4zgL4Kub8tW7wg3Iaf6A+REDf8Ttsk/p45?=
 =?us-ascii?Q?XN2YuOhESmA2X7iZov7t3uVW99R0LMo8g0pwrek4z+JhaGAeKbU7Qbxq3sMb?=
 =?us-ascii?Q?r/Rb9IOi6eCU+3ZNxbPC2DIsBMMB1om2fQ4Xd5P+shU0WmaBJa+kLpsiAQDS?=
 =?us-ascii?Q?oBtart/UcNT3BjPfAAOBZlErbTYqy5D/gyuLoTt3nQt9iyPcNubRF5Ta62hp?=
 =?us-ascii?Q?GbIQS8840mqmHDS6pALiFe1eh567UKBP5tyooYQeEZ6BWOLVObn59q9yQ+fH?=
 =?us-ascii?Q?szi5zI8g0LH6XbFuxgLOmHv9NAvxhLaCVFE13mEoC++vhHFU7KyRf0sGbICP?=
 =?us-ascii?Q?qCwVIPx5jgA3cDp2gd4tQ+6w74z1T5w45nzfAs67kPSCjpVlpEqsFkpImi5A?=
 =?us-ascii?Q?nw+vZhleT5YN8XNj4MHFRArIS95mZb3d1dXF78UALFr0eriRVVr3unSx1g4V?=
 =?us-ascii?Q?hUoZG9bQy1Z2baQSd1yqBJBGKZeITDL6XTDGpwG9wgohrWky9PvR5b9Rg4Gj?=
 =?us-ascii?Q?3Ky/IXsW5NggROd0eqt/iv9nX3vfVjFUAAUois009oPbT2rn6Np9Kww80UT1?=
 =?us-ascii?Q?FyM9iDhEZshqSz6sqMKF1UHJj09TbyxBwVhU+m62fp4IY2wTj6vY6GZO0pLY?=
 =?us-ascii?Q?MNsf2bif+DibBox0Sqg3fMkcwWHd9KjsBXtF7k8qEf7VUHHnlBG2+21vDKIo?=
 =?us-ascii?Q?tZwaVGY86K80J6FNLE0HIDW3zI/tO1gV07fUz+UvC7gk+ap/zXjgePZYbRNz?=
 =?us-ascii?Q?BmnAoZk7Bejuck5QFFhwONG21ezRBe1dsBafSgK6nGRWlOZtIgGDZb6NfCu3?=
 =?us-ascii?Q?qcYC6MsRTXpSgf9HwduV5uPddWcYzKq15VkTN9tNJAEf3uY9W/2HZaRowBEC?=
 =?us-ascii?Q?5x/6KG4eKkCre3MYDGJqJ7Y3QlenmpIH3IEUnYdr5UfC+JjTFaWcNRL9FjGa?=
 =?us-ascii?Q?w2xr/LfMyrCgssls9ehkbuWv89H6SQp9+tnKbhKJTxeFZuaBsSbIGOLmO3I9?=
 =?us-ascii?Q?m0vLbjw8X6pwJc08cViBRVcriBPQ+rOb4lwJahGL4ecSy2BPRgeBIeS38ACq?=
 =?us-ascii?Q?KM3SXseVZu5CTUcXYT6/u2Bw+G2ypQoh9kBsNwlb8dpTQVqTQWopK/n8Fkr9?=
 =?us-ascii?Q?iQ=3D=3D?=
X-OriginatorOrg: oss.nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b608cb2a-591d-463d-9148-08dd201f9617
X-MS-Exchange-CrossTenant-AuthSource: PA4SPRMB0023.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2024 11:23:39.1998
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: k8cA3hu3tsd2/NqqQen9Q0Uwgc4c1zeeLMQsQzb8g/h2tSItpWyEU8qILeUZAhabdHZLhRXzZvFsKsdBZN3KsMx6t8/bnq0rnxumfbclgUE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR04MB9936

From: Andrei Cherechesu 

Add myself as maintainer for NXP S32G3 SoCs Family,
and the S32 Linux Team as relevant reviewers list.

Signed-off-by: Andrei Cherechesu 
Acked-by: Bertrand Marquis 
Acked-by: Michal Orzel 
---
 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 34ad49bc39..392f780f76 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -426,6 +426,12 @@ L:	minios-devel@lists.xenproject.org
 T:	git https://xenbits.xenproject.org/git-http/mini-os.git
 F:	config/MiniOS.mk
 
+NXP S32G3 PROCESSORS FAMILY SUPPORT
+M:	Andrei Cherechesu 
+L:	NXP S32 Linux Team 
+F:	xen/arch/arm/include/asm/linflex-uart.h
+F:	xen/drivers/char/linflex-uart.c
+
 OCAML TOOLS
 M:	Christian Lindig 
 M:	David Scott 
-- 
2.45.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 11:35:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 11:35:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861182.1273163 (Exim 4.92)
	(envelope-from )
	id 1tOEoQ-00059J-Dk; Thu, 19 Dec 2024 11:35:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861182.1273163; Thu, 19 Dec 2024 11:35: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 1tOEoQ-00059C-Aa; Thu, 19 Dec 2024 11:35:26 +0000
Received: by outflank-mailman (input) for mailman id 861182;
 Thu, 19 Dec 2024 11:35: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 1tOEoP-000596-48
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 11:35:25 +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 55e2121c-bdfd-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 12:35:23 +0100 (CET)
Received: by mail-wm1-x331.google.com with SMTP id
 5b1f17b1804b1-432d86a3085so4576955e9.2
 for ; Thu, 19 Dec 2024 03:35:23 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4366112e780sm15733395e9.0.2024.12.19.03.35.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Dec 2024 03:35: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: 55e2121c-bdfd-11ef-a0d7-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734608123; x=1735212923; 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=KOJblgNEYRjxP0OYgB505u61d61EOpJaBp9eHYxo0vc=;
        b=qAAff/a8vNPVC335xZUhgO5UAotX7tAd6nPZWP/TcIlTRe6oJJYR1K1FzeJME4KN0y
         av88zPRRbN+Q8IPN/AQX+9tkAIoEvYUVPh3sdpGNZIR+lacb8DSknqNF43Cf65eUg3bC
         SI5boYh84zi2oTocS6gAVVhLRFRbg8vVwU3pY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734608123; x=1735212923;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KOJblgNEYRjxP0OYgB505u61d61EOpJaBp9eHYxo0vc=;
        b=d62NdsIGp9zxCErzkSAV541xadMMYpcLRGp/HUPQyTG58exAhw1RqGfdP0wZoZIdeB
         0Rer3/ZprkV1ogHoXrj53edUEOZ+f+R258dbLbNeGGtwcTBLLilZPAB8H23mEYubng7A
         8cvDHoh9Rf5k/o38Clw8LwrXE9N8rwvDu6aCI2q7CKnlns4wuCZadLjXcY42aUDm4aD+
         cRTYHS+2ANSQrtQQlEWt+JsOq0lWvkg5n+vrVFVRR5gbFACtL+Za5HNgasAZUPQpFCFP
         VF5q0Iyrh6DlPtMiu0EtlPBatUk1NnWfkGNEAeJ3bvEZeQBtRTtAd/ZwEIJiMhp90iTx
         pDsw==
X-Forwarded-Encrypted: i=1; AJvYcCXTP9xg2nhzcFhP7vWRNS7NyLjJ2fxsHY/T6649fPl34mBXT8QkmLeLxk4w9Xs3mqOsrtPPUVu+bak=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxI/xavI1VYMTP3K8EJ4DON1gn6xSIeoLGxSbTaWU4tLvo8Zpwn
	eA5RnnRnExxk9Zv+WIgV31mp69JaOgIdOEAyJQYCu9RO+4hIw5vjdbGF/DcOcGY=
X-Gm-Gg: ASbGncvhDhxnUHFtK0iQ93s8y/n9cDNLM/9Xv6oB2cbuHExdjowX3DJJBAkK4U0XQQC
	J2LZm/Dvd8/Crqg3C5wNhkzB6YDy8yFclB/JzWY6zK60x+m5oPwOhZbdSTlT9vA4wDiIldM07Q0
	xC5GWNodqntFklkL1amVbHAvvyojP0BZ+C4nOoy0LY7gaZcmcywA7WeE6ZJcYp3xa40sL85ytes
	CjPvFMV02EM14zMtLt44auznpzvaYGxYOBb0NVeBobXKsojvaFrkhiXYEAuyRfQ+8J2zNBON2PI
	rdl9OKomAXLl0q4X5rkC
X-Google-Smtp-Source: AGHT+IGF2aSoovgPII+Q/Sfq8Y47kck4pzlxKC/7I9n9kpUMYPbqqOEc1DLZF0Ng9zHD0Png1bDJJQ==
X-Received: by 2002:a05:600c:5107:b0:434:ff9d:a370 with SMTP id 5b1f17b1804b1-4365c7415f9mr29994765e9.0.1734608123265;
        Thu, 19 Dec 2024 03:35:23 -0800 (PST)
Message-ID: 
Date: Thu, 19 Dec 2024 11:35:22 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] x86/hvm: Use constants for x86 modes
To: Teddy Astie ,
 Xen-devel 
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 
References: 
 <20241218170820.364253-1-andrew.cooper3@citrix.com>
 <2d6ce1c9-dac4-4b00-9157-07ab6987232f@vates.tech>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <2d6ce1c9-dac4-4b00-9157-07ab6987232f@vates.tech>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 19/12/2024 10:46 am, Teddy Astie wrote:
> Hello,
>
> Le 18/12/2024 à 18:08, Andrew Cooper a écrit :
>> From: Teddy Astie 
>>
>> In many places of x86 HVM code, constants integer are used to indicate in what mode is
>> running the CPU (real, vm86, 16-bits, 32-bits, 64-bits). However, these constants are
>> are written directly as integer which hides the actual meaning of these modes.
>>
>> This patch introduces X86_MODE_* macros and replace those occurences with it.
>>
>> Signed-off-by: Teddy Astie 
>> Signed-off-by: Andrew Cooper 
> Acked-by: Teddy Astie 

Thanks, but as you're not a maintainer of this code, Ack doesn't carry
any weight.  Reviewed-by OTOH would, if you're happy with that adjustment?

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 11:48:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 11:48:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861196.1273172 (Exim 4.92)
	(envelope-from )
	id 1tOF0t-0007YX-IW; Thu, 19 Dec 2024 11:48:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861196.1273172; Thu, 19 Dec 2024 11: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 1tOF0t-0007YQ-Fz; Thu, 19 Dec 2024 11:48:19 +0000
Received: by outflank-mailman (input) for mailman id 861196;
 Thu, 19 Dec 2024 11: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 1tOF0s-0007YK-G6
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 11:48:18 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on2062b.outbound.protection.outlook.com
 [2a01:111:f403:2415::62b])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 22a835f7-bdff-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 12:48:16 +0100 (CET)
Received: from BY5PR13CA0007.namprd13.prod.outlook.com (2603:10b6:a03:180::20)
 by SA0PR12MB4431.namprd12.prod.outlook.com (2603:10b6:806:95::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.15; Thu, 19 Dec
 2024 11:48:12 +0000
Received: from MWH0EPF000971E8.namprd02.prod.outlook.com
 (2603:10b6:a03:180:cafe::dd) by BY5PR13CA0007.outlook.office365.com
 (2603:10b6:a03:180::20) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8272.12 via Frontend Transport; Thu,
 19 Dec 2024 11:48:12 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 MWH0EPF000971E8.mail.protection.outlook.com (10.167.243.68) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Thu, 19 Dec 2024 11:48:11 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 19 Dec
 2024 05:48:11 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) 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; Thu, 19 Dec
 2024 05:48:10 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Thu, 19 Dec 2024 05:48:09 -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: 22a835f7-bdff-11ef-a0d7-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=TAPvNruc73mLo9i/lTjYNVO9VEisvy1fKxl5BXVxDAwKHxIRqISLdxl0QTQgJNSuw+IoINbq4wwuIEl0sjWQIL9Q3X/OWG0su5po6v9HUIV/4/HEdCr9h8CYEoozoyhxT/KsbFdwwBEC8aA1Hx9CHZ/n4dfBvhc9aZ63Y4D/ELmRrPgNOZreJdgbYJNFyKleNPqLsoo4BbjNnuTRU6+mQOmv9Xartqz4b9ZL54yTZDFoftT4Zky+5U8Qiux2Q+NO+G8HvwQaF0/KLkuA8vju0OONpuwxxfA4lhHNFPE3jG8Gq0TAnmdqrTcY19iDwv7mpGZHrNye7Yds3te/woctOw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Zyby56vWh5zGB3Pcac1H9OfoizXcHv8RILeAHEZ+O+Q=;
 b=okpMcGjPN8fe7aXjWJTqQXK7C5q17TsBhLGujk4plCOnsA1KdDNjNSF9dJTP4KzFDDZeqs27PqZVd3AhW9rdSlK5lRM2enjfdIIPTl0HB64rR6AzdCf9YkK8Wu/hQCw1aSWoyek/Mhzl7IeQ2b10YBDwiofjVxeH2kwZZl972CU+lsZvS4iVcaNMjtw6OATp4A1HbR4bBjRguF7hEidcqYSAgdSyLUaMEk/zWboqhbWPacmY4OvDmb5tf4OLGJ5GmdMAd9UcqcO4Hu9IJgFmfBPvnng3hKP6K3k/fgmp/qGbYUv/SpUq886o9WatrwvN2fx7hm3aRuNaEbkEGwL1WQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=oss.nxp.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=Zyby56vWh5zGB3Pcac1H9OfoizXcHv8RILeAHEZ+O+Q=;
 b=EYfy7gXfkBEenZeOMSiX450r1XJ6WGHo6/TYZs9oWYgRDUH1h/MkiRY7dxLg1j91p1r7QnokteKmDcVbRVpWvMje72Td8fb1P7+IEvIJriDLqp1xhWB+5iScWRkVp7hQr3Veu4bQx6nWqm6d0f9+jpYpl/UUNeJK9nDGZv4jmEw=
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=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Thu, 19 Dec 2024 12:48:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 1/6] xen/arm: firmware: Add SCMI over SMC calls
 handling layer
To: "Andrei Cherechesu (OSS)" ,
	
CC: , Andrei Cherechesu , "Stefano
 Stabellini" , Julien Grall ,
	"Bertrand Marquis" , Volodymyr Babchuk
	
References: <20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com>
 <20241219112315.2461048-2-andrei.cherechesu@oss.nxp.com>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <20241219112315.2461048-2-andrei.cherechesu@oss.nxp.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWH0EPF000971E8:EE_|SA0PR12MB4431:EE_
X-MS-Office365-Filtering-Correlation-Id: f4da8355-a6be-4e4d-56ce-08dd20230418
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?YjYzdGpTNGhnNHJRVktVNlZLUUNSemYzemRvaWtQTDFPdldmWVpoNnBQUmtE?=
 =?utf-8?B?ZUlsUzluWlVMY3JDdGcwVS9BbFQ4OVAxTlFFVjRvY1NCTXBidXByYm5zU3J3?=
 =?utf-8?B?WHE3RWtpcVM1NFVGQW5McTB3eW4vR1lCcHVGQXV4bnhIT2JHRU9hWHNkd3o2?=
 =?utf-8?B?V05DK1lYVkxiM0ovYTR1KzVaWEV0NDh0SC92WFJGak16L0Y2RDBrNWJRTDlH?=
 =?utf-8?B?a01SNDJkRTNJNmFIMWJFTjREOFZiU3F5Z2I2aWhEQVYvclRQOTNqYlpUbzFn?=
 =?utf-8?B?dVU5Sms0Q2lna1JnWVJIa28ycEZIOGIyVE9LWmxDRXhzMVR6OTJPNkZtTUh4?=
 =?utf-8?B?YkFWT0xjcG9SK25HQlJYekFYTTI1WTluREpzR1lGQTQxZ2xQQy91Rlc0TFJp?=
 =?utf-8?B?SG9lRVkvdU1hbmdzeC9OZjJvRmNpbG1Mbkk2NUdtNVZKOUErNlk0V2FMRzJ3?=
 =?utf-8?B?TTZMZEN0UjVVcDE0SUhPQnUrVWNFRDdNeGpOSTkvV2lmcXY5NUNvNG1EVS9x?=
 =?utf-8?B?V3R1TWJMQ2N5KzFjWVluOXhyUmpmc0lEb2ZQUTE1SlpGOExmSm5TYlgrUlU2?=
 =?utf-8?B?MUkvbVRSd0kyWWZ3blQ5c2Jtd1UwTE9nUUtjVFNBNlRhWE9CbUhhNy9JamNC?=
 =?utf-8?B?MkFSOG0yTTR2czlUM0JoN1NadG8yY09NNFU0dWY0aVVvYmFKQTZnVmtLYk1Q?=
 =?utf-8?B?THFJcUdFdUlKMjNHKyt3TElHODVGaWI4NDhsQ1FKeERuYklTUzM5bjB5M3d3?=
 =?utf-8?B?d1JPQVVGMTlHZFlLTHZQU3gyL29xZzFoNnZlWFlzWlZlMzRPaWNWOEFQZWU4?=
 =?utf-8?B?a0lVcnBXUS9oU3hYZytzUzd4WHFyNWtJbXFZU3U2MnJYeVhNM21ucVV5dFBO?=
 =?utf-8?B?cTk0T3lnMlVEMmZscEhLcWJWYzh5dURNSG5hdDhITElCYVpzeDBhN1IxVmdy?=
 =?utf-8?B?S0p4M2xLK3Yvb0NwbzlRbnBCUHJPV25RbXUyWlNGMDNnU2drYnF2aWdkdlNH?=
 =?utf-8?B?bFRYckVnYmVEcWlHNFJWaTBzUFpqT01rMHRkV1lZL0pidG10d0ZJS29QK3ZC?=
 =?utf-8?B?WjNHdnVhdC9zd2JMeGdrM0JaQStCQlRMWFUxaWNFMktEYUg3cko1bXNsMmhD?=
 =?utf-8?B?WVd5UzJkak1kUkxZMi9SYVdPekI0d28zeXByblA0SXRoTVBLM1ZtYnZ1a1JT?=
 =?utf-8?B?MVc4SlJPeU01ZEhDOFlDaWRHdkpFVEZJNTFpLzhydmVBWkh3UzNNbHVrSDFr?=
 =?utf-8?B?SWpXcGJlNFhnamZMbGRUeThQOHpGNGFGTHRsSWo3UVRGRUo1cDBDR2RaaHhQ?=
 =?utf-8?B?OXNFVTNzK2FWLzVwdkFGUjl4aWg5ZjdBMnl1WEZzaWpOcC9hVkwzT0szc3dw?=
 =?utf-8?B?Ykp5VmI0WG5LWkViNXVRMlNNZ284ZDc5clJZNnJMeVVIanlxUklCM0ZCaDlk?=
 =?utf-8?B?QitwYmI1OFBFU0k5TW1jZGhxQmhvU1FjVDkyV0NySEtnOG9JYWhLQjZTbHhl?=
 =?utf-8?B?aFpwa0JWYzd0Q25TTkpHNkErZ0F3TWxISWFadnp3SVFPZXVOaFNkV05Bcm1F?=
 =?utf-8?B?OEhLN0w0a2VCUmVuTkZwdDRFNDNwdmZpOXFaOUxXS2NObGNLS084ZGZPWUxG?=
 =?utf-8?B?L0M3WVJKOVFnc1F4SzZWcG5sL3lyRjE2WWZlTXNlRm1DY2htNFA4bDUyUXVi?=
 =?utf-8?B?WEVRRkp4NURtN2xTYWZ2Z3Bvb2FuRG9wd1BnKytKZFZvVmFrN3h1bTFTTEVF?=
 =?utf-8?B?c2pQQjkxdS8xRjBKYXUyeElHbEhEOGF3RjdmU2ZDZzA0dG5DYWw0MXROM3BK?=
 =?utf-8?B?akY5aGJJUzV4R2xyUkU4c1d2c0w3cHF1MVFndjhQL1JxWW01d24yRzNlM0di?=
 =?utf-8?B?Qm1rcUJ0OXBGYWJCUGJOaER0bTV5bU5sanl2dHdCNGlpVkltbUlmUENQcks0?=
 =?utf-8?B?U0RiMmhqMllONkxFZU16RHBDTkg2bmpDaE1PclZmT01PUzRnZEtQcllSZlVH?=
 =?utf-8?Q?4zVa/vNBxSgpGW+dBPdjc7S3HrGdLk=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(376014)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2024 11:48:11.9407
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f4da8355-a6be-4e4d-56ce-08dd20230418
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	MWH0EPF000971E8.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4431



On 19/12/2024 12:23, Andrei Cherechesu (OSS) wrote:
> 
> 
> From: Andrei Cherechesu 
> 
> Introduce the SCMI-SMC layer to have some basic degree of
> awareness about SCMI calls that are based on the ARM System
> Control and Management Interface (SCMI) specification (DEN0056E).
> 
> The SCMI specification includes various protocols for managing
> system-level resources, such as: clocks, pins, reset, system power,
> power domains, performance domains, etc. The clients are named
> "SCMI agents" and the server is named "SCMI platform".
> 
> Only support the shared-memory based transport with SMCs as
> the doorbell mechanism for notifying the platform. Also, this
> implementation only handles the "arm,scmi-smc" compatible,
> requiring the following properties:
>         - "arm,smc-id" (unique SMC ID)
>         - "shmem" (one or more phandles pointing to shmem zones
>         for each channel)
> 
> The initialization is done as initcall, since we need
> SMCs, and PSCI should already probe EL3 FW for SMCCC support.
> If no "arm,scmi-smc" compatible node is found in the host
> DT, the initialization fails silently, as it's not mandatory.
> Otherwise, we get the 'arm,smc-id' DT property from the node,
> to know the SCMI SMC ID we handle. The 'shmem' memory ranges
> are not validated, as the SMC calls are only passed through
> to EL3 FW if coming from the hardware domain.
> 
> Create a new 'firmware' folder to keep the SCMI code separate
> from the generic ARM code.
> 
> Signed-off-by: Andrei Cherechesu 
> Reviewed-by: Stefano Stabellini 
NIT for the future. If there are changes in-between the revisions, in general you should
drop the Rb/Ab tags. Here you incorporated my feedback, so:
Acked-by: Michal Orzel 

The series is ready to go in. I'll commit it today or tomorrow as I'm waiting for
staging to become "green" again. Thanks.

~Michal



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 11:53:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 11:53:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861206.1273182 (Exim 4.92)
	(envelope-from )
	id 1tOF5t-0001HE-4W; Thu, 19 Dec 2024 11:53:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861206.1273182; Thu, 19 Dec 2024 11: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 1tOF5t-0001H7-1f; Thu, 19 Dec 2024 11:53:29 +0000
Received: by outflank-mailman (input) for mailman id 861206;
 Thu, 19 Dec 2024 11:53: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 1tOF5r-0001GF-G9
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 11:53:27 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id dab86579-bdff-11ef-a0d7-8be0dac302b0;
 Thu, 19 Dec 2024 12:53:25 +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 3C3EC1477;
 Thu, 19 Dec 2024 03:53:53 -0800 (PST)
Received: from J2N7QTR9R3 (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A4C173F720;
 Thu, 19 Dec 2024 03:53: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: dab86579-bdff-11ef-a0d7-8be0dac302b0
Date: Thu, 19 Dec 2024 11:53:13 +0000
From: Mark Rutland 
To: Arnd Bergmann 
Cc: Ard Biesheuvel , linux-kernel@vger.kernel.org,
	Ard Biesheuvel , x86@kernel.org,
	"H. Peter Anvin" , Andy Lutomirski ,
	Peter Zijlstra ,
	Uros Bizjak , Dennis Zhou ,
	Tejun Heo , Christoph Lameter ,
	Mathieu Desnoyers ,
	Paolo Bonzini ,
	Vitaly Kuznetsov ,
	Juergen Gross ,
	Boris Ostrovsky ,
	Greg Kroah-Hartman ,
	Masahiro Yamada , Kees Cook ,
	Nathan Chancellor ,
	Keith Packard ,
	Justin Stitt ,
	Josh Poimboeuf ,
	Arnaldo Carvalho de Melo ,
	Namhyung Kim , Jiri Olsa ,
	Ian Rogers ,
	Adrian Hunter ,
	Kan Liang , linux-doc@vger.kernel.org,
	linux-pm@vger.kernel.org, kvm@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-efi@vger.kernel.org,
	Linux-Arch ,
	linux-sparse@vger.kernel.org, linux-kbuild@vger.kernel.org,
	linux-perf-users@vger.kernel.org, rust-for-linux@vger.kernel.org,
	llvm@lists.linux.dev
Subject: Re: [RFC PATCH 02/28] Documentation: Bump minimum GCC version to 8.1
Message-ID: 
References: <20240925150059.3955569-30-ardb+git@google.com>
 <20240925150059.3955569-32-ardb+git@google.com>
 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 

Hi Arnd,

On Wed, Sep 25, 2024 at 03:58:38PM +0000, Arnd Bergmann wrote:
> On Wed, Sep 25, 2024, at 15:01, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel 
> >
> > Bump the minimum GCC version to 8.1 to gain unconditional support for
> > referring to the per-task stack cookie using a symbol rather than
> > relying on the fixed offset of 40 bytes from %GS, which requires
> > elaborate hacks to support.
> >
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  Documentation/admin-guide/README.rst | 2 +-
> >  Documentation/process/changes.rst    | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> Acked-by: Arnd Bergmann 
> 
> As we discussed during plumbers, I think this is reasonable,
> both the gcc-8.1 version and the timing after the 6.12-LTS
> kernel.
> 
> We obviously need to go through all the other version checks
> to see what else can be cleaned up. I would suggest we also
> raise the binutils version to 2.30+, which is what RHEL8
> shipped alongside gcc-8. I have not found other distros that
> use older binutils in combination with gcc-8 or higher,
> Debian 10 uses binutils-2.31.
> I don't think we want to combine the additional cleanup with
> your series, but if we can agree on the version, we can do that
> in parallel.

Were you planning to send patches to that effect, or did you want
someone else to do that? I think we were largely agreed on making those
changes, but it wasn't clear to me who was actually going to send
patches, and I couldn't spot a subsequent thread on LKML.

Mark.


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 12:03:26 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 12:03:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861218.1273193 (Exim 4.92)
	(envelope-from )
	id 1tOFFR-0003Pp-4o; Thu, 19 Dec 2024 12:03:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861218.1273193; Thu, 19 Dec 2024 12:03: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 1tOFFR-0003Pi-1q; Thu, 19 Dec 2024 12:03:21 +0000
Received: by outflank-mailman (input) for mailman id 861218;
 Thu, 19 Dec 2024 12:03: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 1tOFFP-0003Pc-J5
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 12:03:19 +0000
Received: from flow-a8-smtp.messagingengine.com
 (flow-a8-smtp.messagingengine.com [103.168.172.143])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3aadad7c-be01-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 13:03:16 +0100 (CET)
Received: from phl-compute-10.internal (phl-compute-10.phl.internal
 [10.202.2.50])
 by mailflow.phl.internal (Postfix) with ESMTP id 716412004CE;
 Thu, 19 Dec 2024 07:03:15 -0500 (EST)
Received: from phl-imap-11 ([10.202.2.101])
 by phl-compute-10.internal (MEProxy); Thu, 19 Dec 2024 07:03:15 -0500
Received: by mailuser.phl.internal (Postfix, from userid 501)
 id 1C9372220072; Thu, 19 Dec 2024 07:03:14 -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: 3aadad7c-be01-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; 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=1734609795;
	 x=1734616995; bh=HsWGYit1QfbykpeRihgbuA09LwqwIdTOxzn2rND9d44=; b=
	hXPuViTWoL+d8uTD8HWKH6l9JI3Qeg2+RU0afqJ+27Me3anlO7iAkrJodDU6SDBN
	Q072WguaY7168vuinaZpdAtQ10DTGk5RYTaX/LadyRHQOzWPD3JbXXKn0mlciYNp
	/X0ieAaHbhoMwp3jLFOIUY9qD8vUGL6DA6lT6SSUUoc7L2j+JHlZHXtf+NE7YFbT
	eOs3kJAp5E5/dY87oP0aB928LrOITs5+5CDiuYcjTHYJJciZmW9Z0XBEYdV4CiNk
	Wx0h3kLrKDDoQBv9F7H04Cd/klAwrIBGOvI957eyJztC01JCmdqrxlQ1BlkaCsQa
	jWQXaNegO8DxO9+esrj5GA==
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=1734609795; x=
	1734616995; bh=HsWGYit1QfbykpeRihgbuA09LwqwIdTOxzn2rND9d44=; b=A
	i01Jq9/TVKRojX7wRVqPg0h5WKcLpoStUlzFB/1DKY70YpqmGkR7fHOcpORUn0um
	O3veblgy+PhgwTHKsaLsX62avtsXgZfoU3nI7C6pm24TvWQrJZfq+Rh9JerC4NLS
	ciJ2sAoN9cCbyrQeR85kewBkWKH6IQre7lcblf9ImmbyUTndDKyoIi7iBFB4FLD3
	0KT6+xxFdEY0omS5lwTLd8ccH+7S9mGeb77Qi1x6f+uVivOh3MspIan1aTLYH7mp
	jKgm3f81NG86TuM3m3J6GqmunKFMUSCLyYI+YxETM8+cFfzgpaomgMZfCdOwfBTG
	wCLqOyPW6qgnvCJJQUe3A==
X-ME-Sender: 
    
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddruddttddgfeegucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhepofggfffhvfevkfgjfhfutgfgsehtjeertdertddt
    necuhfhrohhmpedftehrnhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrd
    guvgeqnecuggftrfgrthhtvghrnhephfdthfdvtdefhedukeetgefggffhjeeggeetfefg
    gfevudegudevledvkefhvdeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe
    hmrghilhhfrhhomheprghrnhgusegrrhhnuggsrdguvgdpnhgspghrtghpthhtohepgedu
    pdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehmrghrkhdrrhhuthhlrghnugesrg
    hrmhdrtghomhdprhgtphhtthhopehmrghthhhivghurdguvghsnhhohigvrhhssegvfhhf
    ihgtihhoshdrtghomhdprhgtphhtthhopehusghiiihjrghksehgmhgrihhlrdgtohhmpd
    hrtghpthhtoheprghruggsodhgihhtsehgohhoghhlvgdrtghomhdprhgtphhtthhopehi
    rhhoghgvrhhssehgohhoghhlvgdrtghomhdprhgtphhtthhopehjuhhsthhinhhsthhith
    htsehgohhoghhlvgdrtghomhdprhgtphhtthhopehpvghtvghriiesihhnfhhrrgguvggr
    ugdrohhrghdprhgtphhtthhopegrughrihgrnhdrhhhunhhtvghrsehinhhtvghlrdgtoh
    hmpdhrtghpthhtohepkhgvihhthhhpsehkvghithhhphdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i56a14606:Fastmail
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
Date: Thu, 19 Dec 2024 13:02:46 +0100
From: "Arnd Bergmann" 
To: "Mark Rutland" 
Cc: "Ard Biesheuvel" , linux-kernel@vger.kernel.org,
 "Ard Biesheuvel" , x86@kernel.org,
 "H. Peter Anvin" , "Andy Lutomirski" ,
 "Peter Zijlstra" ,
 "Uros Bizjak" , "Dennis Zhou" ,
 "Tejun Heo" , "Christoph Lameter" ,
 "Mathieu Desnoyers" ,
 "Paolo Bonzini" ,
 "Vitaly Kuznetsov" ,
 "Juergen Gross" ,
 "Boris Ostrovsky" ,
 "Greg Kroah-Hartman" ,
 "Masahiro Yamada" , "Kees Cook" ,
 "Nathan Chancellor" ,
 "Keith Packard" ,
 "Justin Stitt" ,
 "Josh Poimboeuf" ,
 "Arnaldo Carvalho de Melo" ,
 "Namhyung Kim" , "Jiri Olsa" ,
 "Ian Rogers" ,
 "Adrian Hunter" ,
 "Kan Liang" , linux-doc@vger.kernel.org,
 linux-pm@vger.kernel.org, kvm@vger.kernel.org,
 xen-devel@lists.xenproject.org, linux-efi@vger.kernel.org,
 Linux-Arch , linux-sparse@vger.kernel.org,
 linux-kbuild@vger.kernel.org, linux-perf-users@vger.kernel.org,
 rust-for-linux@vger.kernel.org, llvm@lists.linux.dev
Message-Id: <0afeae21-a663-43c9-91ff-f0357f5ac06b@app.fastmail.com>
In-Reply-To: 
References: <20240925150059.3955569-30-ardb+git@google.com>
 <20240925150059.3955569-32-ardb+git@google.com>
 
 
Subject: Re: [RFC PATCH 02/28] Documentation: Bump minimum GCC version to 8.1
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Thu, Dec 19, 2024, at 12:53, Mark Rutland wrote:
> On Wed, Sep 25, 2024 at 03:58:38PM +0000, Arnd Bergmann wrote:
>> On Wed, Sep 25, 2024, at 15:01, Ard Biesheuvel wrote:
>> > From: Ard Biesheuvel 
>> 
>> We obviously need to go through all the other version checks
>> to see what else can be cleaned up. I would suggest we also
>> raise the binutils version to 2.30+, which is what RHEL8
>> shipped alongside gcc-8. I have not found other distros that
>> use older binutils in combination with gcc-8 or higher,
>> Debian 10 uses binutils-2.31.
>> I don't think we want to combine the additional cleanup with
>> your series, but if we can agree on the version, we can do that
>> in parallel.
>
> Were you planning to send patches to that effect, or did you want
> someone else to do that? I think we were largely agreed on making those
> changes, but it wasn't clear to me who was actually going to send
> patches, and I couldn't spot a subsequent thread on LKML.

I hadn't planned on doing that, but I could help (after my
vacation). As Ard already posted the the patch for gcc, I
was expecting that this one would get merged along with the
other patches in the series.

Ard, what is the status of your series, is this likely to
make it into 6.14, or should we have a separate patch to
just raise the minimum gcc and binutils version independent
of your work?

      Arnd


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 13:04:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 13:04:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861241.1273202 (Exim 4.92)
	(envelope-from )
	id 1tOGCO-000418-GL; Thu, 19 Dec 2024 13:04:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861241.1273202; Thu, 19 Dec 2024 13:04:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOGCO-000411-Dp; Thu, 19 Dec 2024 13:04:16 +0000
Received: by outflank-mailman (input) for mailman id 861241;
 Thu, 19 Dec 2024 13:04:15 +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 1tOGCM-00040v-P1
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 13:04:14 +0000
Received: from mail132-21.atl131.mandrillapp.com
 (mail132-21.atl131.mandrillapp.com [198.2.132.21])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bd8d9f71-be09-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 14:04:12 +0100 (CET)
Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail132-21.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4YDW2y4fstz1XLFNg
 for ; Thu, 19 Dec 2024 13:04:10 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 fb5187bdd4024b7cb86f6582bd936f4a; Thu, 19 Dec 2024 13: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: bd8d9f71-be09-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1734613450; x=1734873950;
	bh=nVJ8VvNsU8HHIJgIwu49gG2Hx+R/KL9Zo6XJNXdqpS0=;
	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=PSj5NwCmHCeIMlml+QT4FesIB84RdbJodbT4RgPjlT87Y8KX1yTNOODz0E9b0H9l0
	 /RJFv/8z03xEuQB4G4B7tcoQK8uv2L7uM2EDwSVhgzzir4IKbIo88o1YuBEHh6A6+N
	 jW+ABVLZaKzZxSqRM1PwGp3hR7xvlRKBUwovM8USJBqpNg0Pw8zUhqyAhAQkLdWh10
	 YL94+4OT26mYGk4L76YDNeCKlwdFH0e0Bp751OR1gRIjMKJPvCdYnPKmdrc4hGZYN7
	 U9iiJNvaMsSsSzefLmib8z0aA8SZGzlXL5CQ8W+24VUypbw1NB2ZA5U0y4mGIjMR3D
	 xV/05OWMj1YcA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1734613450; x=1734873950; i=teddy.astie@vates.tech;
	bh=nVJ8VvNsU8HHIJgIwu49gG2Hx+R/KL9Zo6XJNXdqpS0=;
	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=d8VAzqIgJqykjWpKq+u1FC4XfNiz1IBkF6sUWRF/Mcg5ZpZw+EV6898Bo6C2oYMap
	 WUM1nAVPI0WzKNb2EJT8Us9831msR3ljYbECAeN8JJqgXgaBzx+hkC2/BNKTZBlvwp
	 TfxE8GECHzW5jTI9ax2Ns+kecgRDPogrwtQgclqt6FCvxDVin3/cXLWBaJQY7rcVWW
	 VEiyj/Y+JU4+EAJK9n0S6F3D7M1/WQmTq+ZXg5oOw8j2m8p2V5SdLIk4p0sEAcgdvG
	 dBqadk9rljiIR65BJrmYBsKRylz0Cy/0RajwM6LYRrQp5vKZBnLbuNtI33E2XphthC
	 FTN3UG+BTk5cw==
From: "Teddy Astie" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v3]=20x86/hvm:=20Use=20constants=20for=20x86=20modes?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1734613447781
Message-Id: <2b9c9b05-a582-4e70-8246-fde4b37bc669@vates.tech>
To: "Andrew Cooper" , Xen-devel 
Cc: "Jan Beulich" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
References:  <20241218170820.364253-1-andrew.cooper3@citrix.com> <2d6ce1c9-dac4-4b00-9157-07ab6987232f@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.fb5187bdd4024b7cb86f6582bd936f4a?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20241219:md
Date: Thu, 19 Dec 2024 13:04:10 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 19/12/2024 =C3=A0 12:35, Andrew Cooper a =C3=A9crit=C2=A0:
> On 19/12/2024 10:46 am, Teddy Astie wrote:
>> Hello,
>>
>> Le 18/12/2024 =C3=A0 18:08, Andrew Cooper a =C3=A9crit=C2=A0:
>>> From: Teddy Astie 
>>>
>>> In many places of x86 HVM code, constants integer are used to indicate =
in what mode is
>>> running the CPU (real, vm86, 16-bits, 32-bits, 64-bits). However, these=
 constants are
>>> are written directly as integer which hides the actual meaning of these=
 modes.
>>>
>>> This patch introduces X86_MODE_* macros and replace those occurences wi=
th it.
>>>
>>> Signed-off-by: Teddy Astie 
>>> Signed-off-by: Andrew Cooper 
>> Acked-by: Teddy Astie 
> 
> Thanks, but as you're not a maintainer of this code, Ack doesn't carry
> any weight.=C2=A0 Reviewed-by OTOH would, if you're happy with that adjus=
tment?
> 
> ~Andrew

Yes, I meant Reviewed-by in my Acked-by.

So,

Reviewed-by: Teddy Astie 

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 Dec 19 14:58:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 14:58:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861274.1273212 (Exim 4.92)
	(envelope-from )
	id 1tOHyy-000823-6B; Thu, 19 Dec 2024 14:58:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861274.1273212; Thu, 19 Dec 2024 14:58: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 1tOHyy-00081w-3H; Thu, 19 Dec 2024 14:58:32 +0000
Received: by outflank-mailman (input) for mailman id 861274;
 Thu, 19 Dec 2024 14:58: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 1tOHyx-00081o-BW
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 14:58:31 +0000
Received: from mail133-1.atl131.mandrillapp.com
 (mail133-1.atl131.mandrillapp.com [198.2.133.1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b478ca21-be19-11ef-a0d8-8be0dac302b0;
 Thu, 19 Dec 2024 15:58:29 +0100 (CET)
Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail133-1.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4YDYZq3vvczBsTyWJ
 for ; Thu, 19 Dec 2024 14:58:27 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 e1d13329625f43c4b6e01dc0f7a977a2; Thu, 19 Dec 2024 14:58: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: b478ca21-be19-11ef-a0d8-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1734620307; x=1734880807;
	bh=LIcZ4kS6QwSkVcmgp4WEGadBISGt1CCixH2sTLJXo7c=;
	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=XyYfI2fHjYxxdBprm8ihIH9UoGEb+iog4OfFrJRMUZg/dVvTsZPe0L2iCu0BSV7FA
	 YUbGALNgG3JH3j+HxDfWVL/ipffTZAhtsHFuGBBVzw3X/3iwCWGqmEA+e2CvGGXJA9
	 u6Y4U9Hn/uZcT04DtsAzx22g9IQ3HsZMIBM4+7iwWgSG6A6g2SWXs3NBcMrZGdx+ah
	 hKTdo8PsecKjzbdasOjBL4I1t2kxOuO53rpSf5A1uvtz06qVUcPsdFYJgh4IGGF60T
	 cvdjqVzb1I/FXYLJo1jDdZY5kwOQUzty2SW568PpLQkfTn9viNPl0ScE/igahL17ZL
	 Z1PhtApSPGiMA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1734620307; x=1734880807; i=anthony.perard@vates.tech;
	bh=LIcZ4kS6QwSkVcmgp4WEGadBISGt1CCixH2sTLJXo7c=;
	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=bZplh9ECLJGE2Sg0aULtohZBIcCpSffTQhrgE4JoSK70w4FLGdYaQE6z2cjdq7ftH
	 PEectnuN3IXfF9OsbiCERiyUZ184GViGYqy/qhSGgiKTRux8NGF9UfU6UVt3DxFywI
	 dcqEn2/oI2ZBcf/cOXdpYxZYwyAaVnrwaF65yoy6UvTEcQAfsZ3E3JL5pleE+GQIJ2
	 OtOWYRE8kkuqkSLHhDeaIaWkGhaX8qLPoI1E0lsAU6+4uNRS1tdGEJIUylcwAzmsbR
	 lViI2fWMSL3jRcC7RqBGDbsKBS+r9UNDO9PZtdDxhHC911p8wfusz3DK56/gAk9CrE
	 c2MFaGGndJPOQ==
From: "Anthony PERARD" 
Subject: =?utf-8?Q?Re:=20[PATCH]=20tools/xg:=20increase=20LZMA=5FBLOCK=5FSIZE=20for=20uncompressing=20the=20kernel?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1734620306094
To: "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 
Cc: "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" , xen-devel@lists.xenproject.org, "Juergen Gross" 
Message-Id: 
References: <20241008213225.728922-1-marmarek@invisiblethingslab.com> 
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.e1d13329625f43c4b6e01dc0f7a977a2?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20241219:md
Date: Thu, 19 Dec 2024 14:58:27 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 18, 2024 at 06:58:25PM +0100, Roger Pau Monn=C3=A9 wrote:
> On Tue, Oct 08, 2024 at 11:32:23PM +0200, Marek Marczykowski-G=C3=B3recki=
 wrote:
> > Linux 6.12-rc2 fails to decompress with the current 128MiB, contrary to
> > the code comment. It results in a failure like this:
> > 
> >     domainbuilder: detail: xc_dom_kernel_file: filename=3D"/var/lib/qub=
es/vm-kernels/6.12-rc2-1.1.fc37/vmlinuz"
> >     domainbuilder: detail: xc_dom_malloc_filemap    : 12104 kB
> >     domainbuilder: detail: xc_dom_module_file: filename=3D"/var/lib/qub=
es/vm-kernels/6.12-rc2-1.1.fc37/initramfs"
> >     domainbuilder: detail: xc_dom_malloc_filemap    : 7711 kB
> >     domainbuilder: detail: xc_dom_boot_xen_init: ver 4.19, caps xen-3.0=
-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
> >     domainbuilder: detail: xc_dom_parse_image: called
> >     domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary =
loader ...
> >     domainbuilder: detail: loader probe failed
> >     domainbuilder: detail: xc_dom_find_loader: trying HVM-generic loade=
r ...
> >     domainbuilder: detail: loader probe failed
> >     domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loa=
der ...
> >     domainbuilder: detail: _xc_try_lzma_decode: XZ decompression error:=
 Memory usage limit reached
> >     xc: error: panic: xg_dom_bzimageloader.c:761: xc_dom_probe_bzimage_=
kernel unable to XZ decompress kernel: Invalid kernel
> >     domainbuilder: detail: loader probe failed
> >     domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loade=
r ...
> >     domainbuilder: detail: loader probe failed
> >     xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader =
found: Invalid kernel
> >     libxl: error: libxl_dom.c:566:libxl__build_dom: xc_dom_parse_image =
failed
> > 
> > The important part: XZ decompression error: Memory usage limit reached
> > 
> > This looks to be related to the following change in Linux:
> > 8653c909922743bceb4800e5cc26087208c9e0e6 ("xz: use 128 MiB dictionary a=
nd force single-threaded mode")
> > 
> > Fix this by increasing the block size to 256MiB. And remove the
> > misleading comment (from lack of better ideas).
> > 
> > Signed-off-by: Marek Marczykowski-G=C3=B3recki 
> 
> Reviewed-by: Roger Pau Monn=C3=A9 
> 
> I assumed I already RB this, but it seems not.
> 
> Could we get an Ack from the tools or libs maintainer for this to go
> in?  It's not the best solution, but we need to get this sorted in
> time for 4.20, and backport to stable branches.

Acked-by: Anthony PERARD 

Thanks,

-- 

 | Vates 

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 15:37:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 15:37:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861291.1273223 (Exim 4.92)
	(envelope-from )
	id 1tOIag-0004dx-1c; Thu, 19 Dec 2024 15:37:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861291.1273223; Thu, 19 Dec 2024 15: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 1tOIaf-0004dq-V4; Thu, 19 Dec 2024 15:37:29 +0000
Received: by outflank-mailman (input) for mailman id 861291;
 Thu, 19 Dec 2024 15:37: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 1tOIae-0004dk-QD
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 15:37:28 +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 2633e2c2-be1f-11ef-a0d8-8be0dac302b0;
 Thu, 19 Dec 2024 16:37:26 +0100 (CET)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-385d7f19f20so485792f8f.1
 for ; Thu, 19 Dec 2024 07:37: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-38a1c8acafesm1794280f8f.98.2024.12.19.07.37.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Dec 2024 07: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: 2633e2c2-be1f-11ef-a0d8-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734622646; x=1735227446; 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=WMTQ04gHAClsP3haFtxaUU6utsH1v3ss5HoocB+3fuI=;
        b=FN13dd7hzr5Nfwb5VXZUbP/4N77j0Mdl1xyjVQPj119vFDVSIDw24ZIbqD0ivDqrK+
         tj/8jPii49MYwAShEBw4Srl5UnJkyiFzcDsH4HdKmY8hULTpkNy8I/a5OXbXHdxd/Kyc
         5/WSsC8gC48NPP50c7BOVpDFA5EwcN/tp+V9iDld6CvnbRjHMP1P/hNvGpPHqolcsKkl
         0GzRoeDc2gL69G0IDHxtYHlT/nzQcIvNz6giQU1T8L8lKFcr5KwnbpSIVhweRXj+0ALU
         CeS18Jawn3IqJLPLhynbb2T7gBpnluX+S7k/CRqfgj3GeynUxPnj60njfH5YWg24Pv0R
         Rp7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734622646; x=1735227446;
        h=content-transfer-encoding:autocrypt:content-language:cc:to:subject
         :from:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=WMTQ04gHAClsP3haFtxaUU6utsH1v3ss5HoocB+3fuI=;
        b=v0BRm66XKhXcsmY7h2TvgI3RfcLnP3G+10CWhGRSrPHYAoBaof+ao03Vf1kO8Bc72Q
         uWuM1/Rng6/aNq3cLv8069hQSj+g9ovS7Io5M3ELHHcEoZVbVKWCRgswrzDkxULWR12/
         SGUmjm5+wDEula06VUZRdK08J4VXFY38Lu7b2RpbajgQubktfWxp7LkJaWhla5DSQoOw
         BTaqAB+IsHx0073HHr43sCBSMotjBhjVoQmIwkBLFSnYGUUqBH6Le2vf2t0QjwLN0tLk
         hr3EUwopz09lqRgjo/ODxNYkzFtDNUBHpddS4gtK1r/O+JuUaRr8mwKw8Lgji4vhH02V
         vsSw==
X-Gm-Message-State: AOJu0Yx4UGY/jZnZvU5WBqdWQs5So7Zps8ZT7udivIkgjjgyF2RY4y/U
	hdk7XLiRi43fKAAG+1Qf8nhN2hModJkoNwpVgT79JmsRPYbQS/PD8H+Jk6ENqzUmZl/7+ovvytA
	=
X-Gm-Gg: ASbGncuO0iC2bcN7115DqA1u901CSdEFwPeBfHOaMoP37lIpQcHUmppytyBA9zgFqkT
	ROTvSOiRwq2i1q+ZNEUnG2wbq/HdWFv4eUVOCZzOTvqcI2dq3A+xhOVBRuQp1kt8EjWQGIxI3IG
	miWgCAZEqbReLxRGg0+q99sg8Zo5ZabqyLqPP8WS6hYeBJOEkfqvbZCIIY/Ll+6lZRrMCMgY4dx
	MztrD2Tj9u4ao1Yxy6aaexbcssRyZZFoezO+9ikfd4jgoF4Bo5GWdKKS+Wy6Az9avJcVHieuroY
	GLYWVe/3S5afDU5QYoud4J6be7jsvgf7hcB4cRCa5g==
X-Google-Smtp-Source: AGHT+IHDeS9QZhu7pwcY7zwGyEnH5+gTgZ2/Fxt6Y3e0LhBdIOzMNwR1Ksva8eclwZo+WNPEK1qADw==
X-Received: by 2002:a05:6000:4b10:b0:388:da10:ea7e with SMTP id ffacd0b85a97d-388e4d4466cmr6433490f8f.24.1734622646463;
        Thu, 19 Dec 2024 07:37:26 -0800 (PST)
Message-ID: 
Date: Thu, 19 Dec 2024 16:37:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Jan Beulich 
Subject: Xen 4.18.4 released
To: xen-announce@lists.xenproject.org
Cc: "xen-devel@lists.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,

we're pleased to announce the release of another bug fixing Xen version.

Xen 4.18.4 is available from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.18
(tag RELEASE-4.18.4) or from the XenProject download page
https://xenproject.org/resources/downloads/.

We recommend all users of the 4.18 stable series to update to this
final full-support point release. The branch is moving into security-only
maintenance mode now.

Regards, Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 15:43:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 15:43:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861317.1273257 (Exim 4.92)
	(envelope-from )
	id 1tOIgU-0007Gw-7A; Thu, 19 Dec 2024 15:43:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861317.1273257; Thu, 19 Dec 2024 15:43: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 1tOIgU-0007Gp-3S; Thu, 19 Dec 2024 15:43:30 +0000
Received: by outflank-mailman (input) for mailman id 861317;
 Thu, 19 Dec 2024 15:43:29 +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 1tOIgT-0006zr-5o
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 15:43:29 +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 fcb8a468-be1f-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 16:43:27 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-4361d5dcf5bso10625755e9.3
 for ; Thu, 19 Dec 2024 07:43: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-43661219578sm21414355e9.20.2024.12.19.07.43.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Dec 2024 07:43: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: fcb8a468-be1f-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734623006; x=1735227806; 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=z88oIDxYFcxmf5Ec0JMWyA2Sht4xh4MyozFkoMes2aQ=;
        b=ftZY5KYKWpX7XRZmT1pB128R8N43OfJG8AWTGs3CcPZ19tJ3OEFknf7e3nUoJ+p2yL
         Y5WThMMLBab7ZB17jCIqiD24pu97IiSrbymcY1k30iKpB3MjJvEfk4aeZuPfqTpNG9sY
         kurxL2jmlWDSt+SNFGNmamBRvzjnqSmz80LeQAuG2YZe7WWnK9DoZ/tJ2CpNPFthFTJM
         69V5f7Y6y/5ppN0/yN5hZSO6X46YME4GKsJwe/AFv8dY7cePdgfZZUmwukfioimwZ4Zf
         Bdo8C3GngaXOzdYpgxnpaJGHkv/od5CvGb3Ax3zdWYPXwhUYyY+D8dWjENka54zvdRR9
         ct5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734623006; x=1735227806;
        h=content-transfer-encoding:in-reply-to:autocrypt:content-language
         :references:cc:to:from:subject:user-agent:mime-version:date
         :message-id:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=z88oIDxYFcxmf5Ec0JMWyA2Sht4xh4MyozFkoMes2aQ=;
        b=TW9/p6+arl0IV9Loy0Q9BPv4WyNAtdyhImq6F3ccOe3fM6q8vRjdxinHUX2XfeHZpU
         taLczuAMt20lhhfT/hEX6iuiQRvPz9w8FVtvTEJrsGvW2Pt9WlgTzJJqYZ6BvZugH2W6
         o4NwolWADbGcG451G1c7tAlHgdgpX57rgYecAHGTjA3bd+wxw8XbyO2EA5uRHFQcqsXW
         c/9rldSQ7w0YObqsmegO1a5QxpJoyePANxl7JgkzcargiXUmeTB3tcksTPUfjMXMORlE
         yC0IA1BWA78VCx+YmWLovEbFOUtRb/rjRPIjPOgl3V8SAUyNydKkMI9hRaq0mprX1GgW
         k4CA==
X-Gm-Message-State: AOJu0YxLk59JWeVIn+SKa1DcJKxGdDwZNcBzRoY9N2ugBNlD38cNJCC4
	UilhqWzpoEbWGeckgP5zKmqi1c3oh9YJLIhVgNZkq4iccAN87EyOq4E5H3r2gAPQcdSR3QSKMkI
	=
X-Gm-Gg: ASbGncv3BrNn/fA69q6KP6zwcIxTrCsqVito9+J4cRY8i3q+LHK+PKAmP2VXqigccjf
	D5018cc4R5yjulFxQ/gXFHxp9Q3+G8ggh/jp3PtTOEm3B2vyrrwckP0+uLZ5bV8VnEh8ghHecdU
	aKsjsh18gJZse7rRqTNN4itN9wFo0/xiYQTX4rbr2YAoptkbPZtjoZrmhu7PwiGct9hfLb96vHH
	WJRYUYIJ6tVuZLp37Vjns8bV1eHDBGzHfWBLaw3/FCR+Zl50jxIIcfmHwfJzY3AhqEQ9NBUbRKt
	DxHpWkO1bYN7Pq8oHYnvxxzoQLP3daOyn9GEwm4/UA==
X-Google-Smtp-Source: AGHT+IE5Mkrsu+DdJYMpcTRx83qAIFHWtG2uNNAhmCVVzZbKXQ3kr5fC60BOcxFWpHPvEEEQf8v0TA==
X-Received: by 2002:a05:600c:4f89:b0:434:fff1:1ade with SMTP id 5b1f17b1804b1-4365535b845mr66301465e9.13.1734623005959;
        Thu, 19 Dec 2024 07:43:25 -0800 (PST)
Message-ID: <827fa8dc-77ab-487d-9563-24e3f1411d6d@suse.com>
Date: Thu, 19 Dec 2024 16:43:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen 4.18.4 released
From: Jan Beulich 
To: xen-announce@lists.xenproject.org
Cc: "xen-devel@lists.xenproject.org" 
References: 
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: 7bit

On 19.12.2024 16:37, Jan Beulich wrote:
> Xen 4.18.4 is available from its git repository
> http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.18
> (tag RELEASE-4.18.4) or from the XenProject download page
> https://xenproject.org/resources/downloads/.
> 
> We recommend all users of the 4.18 stable series to update to this
> final full-support point release. The branch is moving into security-only
> maintenance mode now.

Apologies. I was under the strong impression that the above was true, but I
obviously should have checked before hitting the Send button. There are still
a few more months to go until the above is supposed to be happening (in mid
May 2025).

Jan


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 15:43:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 15:43:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861328.1273267 (Exim 4.92)
	(envelope-from )
	id 1tOIgw-0007wu-HF; Thu, 19 Dec 2024 15:43:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861328.1273267; Thu, 19 Dec 2024 15:43: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 1tOIgw-0007wn-E0; Thu, 19 Dec 2024 15:43:58 +0000
Received: by outflank-mailman (input) for mailman id 861328;
 Thu, 19 Dec 2024 15:43: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 1tOIgv-0006zr-0X
 for xen-devel@lists.xen.org; Thu, 19 Dec 2024 15:43:57 +0000
Received: from mail132-21.atl131.mandrillapp.com
 (mail132-21.atl131.mandrillapp.com [198.2.132.21])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0d78e4ba-be20-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 16:43:55 +0100 (CET)
Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1])
 by mail132-21.atl131.mandrillapp.com (Mailchimp) with ESMTP id
 4YDZbF5ghLz1XLG0y
 for ; Thu, 19 Dec 2024 15:43:53 +0000 (GMT)
Received: from [37.26.189.201] by mandrillapp.com id
 99022c5046724ff6be180145348941cd; Thu, 19 Dec 2024 15: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: 0d78e4ba-be20-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com;
	s=mte1; t=1734623033; x=1734883533;
	bh=qUDGz5E82gKROsWdV+bBULT6T54ZNSbNosmbh8YnBDA=;
	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=VowfkQdbv9i4smeqCAnXPsWz3L34fjJqO0x48Zc+JiUcH5tnmnQ6NPYRGmf/OTjoD
	 XxSDFFqhZRfkBll4AEySzfXzU7L6nohBjp91kUDsR54LFN2qVrqF85tA+N04q/QUg4
	 k1eB33A2vfKFcFlsE+xMUw6bRdQ2tQQC8VUUampt9+ETsDtu1gw7ursR+H0MD4Rnmd
	 67AmOz877b+ghbIY2Iock1FETdTog0o9lk0w4Yy/M9eF/pPTDChALJlLUtNwib4fxR
	 ByEV9ygWz9bKX1iV/UiNVJoY1p727V/8o+y5QIBxlvT3bru1vNl6rXrCr3QaTAS9zd
	 tyHqoTo4DwM9Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1;
	t=1734623033; x=1734883533; i=anthony.perard@vates.tech;
	bh=qUDGz5E82gKROsWdV+bBULT6T54ZNSbNosmbh8YnBDA=;
	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=iLSB3QOK0OcQfyAjzD1EBvJ73nMSc6UDg4onlSBio83hreg9hPfK/M/QwDBq0EDJW
	 8CIlLaljbrhn8Rw4bBt2k62olm6OL+WPdNZZQ5we/hVnCKs37G/7DDL77r9IX6Jlvl
	 gHbbaa4cwinQm6GXY7pN75xlSsHjZ7fNJ9rGyNVzETdtDE+SwGhVaCUdubPtR6vMct
	 aFjmQPoLkwJyk1xEleM1B63p4VGXnX8fIuoiP1CsW01RQWqcKASoiWz8YYGcVM7XAw
	 dPJ4Dd6OfK3bhq47Hr97JWjhYlT+nw4IMONAhVmqXWAZAeTeXmFQMUFWDRpPrBO3tc
	 fClVFT2kry/XA==
From: "Anthony PERARD" 
Subject: =?utf-8?Q?Re:=20[PATCH=20v2]=20drop=20setting=20XEN=5FQEMU=5FCONSOLE=5FLIMIT=20in=20the=20environment?=
X-Bm-Disclaimer: Yes
X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2
X-Bm-Transport-Timestamp: 1734623032984
To: "James Dingwall" 
Cc: xen-devel@lists.xen.org, "Jan Beulich" 
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.99022c5046724ff6be180145348941cd?=
X-Mandrill-User: md_30504962
Feedback-ID: 30504962:30504962.20241219:md
Date: Thu, 19 Dec 2024 15:43:53 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

> commit 7b89ea44dbcb965b6b67c8de5092ea2b95d4c6f9
> Author: James Dingwall 
> Date:   Tue Nov 5 11:16:20 2024 +0000
> 
>     libxl: drop setting XEN_QEMU_CONSOLE_LIMIT in the environment (XSA-180 / CVE-2014-3672)
>     
>     The corresponding code in the Xen qemu repository was not applied from
>     qemu-xen-4.18.0.
>     
>     Signed-off-by: James Dingwall 

Reviewed-by: Anthony PERARD 

Thanks,

-- 

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 16:15:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 16:15:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861353.1273277 (Exim 4.92)
	(envelope-from )
	id 1tOJB1-00050q-OH; Thu, 19 Dec 2024 16:15:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861353.1273277; Thu, 19 Dec 2024 16:15: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 1tOJB1-00050j-LI; Thu, 19 Dec 2024 16:15:03 +0000
Received: by outflank-mailman (input) for mailman id 861353;
 Thu, 19 Dec 2024 16:15: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 1tOJAz-00050d-Vh
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 16:15:02 +0000
Received: from fout-b2-smtp.messagingengine.com
 (fout-b2-smtp.messagingengine.com [202.12.124.145])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6414c78b-be24-11ef-a0d8-8be0dac302b0;
 Thu, 19 Dec 2024 17:14:58 +0100 (CET)
Received: from phl-compute-11.internal (phl-compute-11.phl.internal
 [10.202.2.51])
 by mailfout.stl.internal (Postfix) with ESMTP id 7B6AD1140162
 for ; Thu, 19 Dec 2024 11:14:57 -0500 (EST)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-11.internal (MEProxy); Thu, 19 Dec 2024 11:14:57 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Thu, 19 Dec 2024 11:14:56 -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: 6414c78b-be24-11ef-a0d8-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:content-type:content-type:date:date
	:from:from:in-reply-to:message-id:mime-version:reply-to:subject
	:subject:to:to; s=fm1; t=1734624897; x=1734711297; bh=+qZge1U3yN
	JTy1trbgqrNjkQxeSGxxlbu+AlcLUwwi8=; b=CvhQlTQsWjK4fLGVbBgfKVJHIs
	6dQbFUOWTQa8VOOZZ2WfIL9sY79wCOIvnTcjw1Vs0XYUIEnItIB0BTrJ0ffodJQ7
	0IRZ6vj22EGF56BvpXyY7Uw/t5/qgOmfcXd8QQF0kAJXU21irAj9LMR79WNcrzsM
	+d1Ob6/+NLZ2FfE7U7a0R/oJEza5Tme8Xm1H3ah7ZnIfqscPmAACoL71uArbJ4ar
	FpoaJTGmINUw3PANv8Dint6esHNJVdEVpwlu7/I5D7duDBXuBei0IH+dwWXh+Cq/
	4Il+lM5b5eWnHHRfM0CV5sAsiMGFfaOKEMxBdIndH6diCdD+UDfnVFmSWmvg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=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=1734624897; x=
	1734711297; bh=+qZge1U3yNJTy1trbgqrNjkQxeSGxxlbu+AlcLUwwi8=; b=M
	C6HBJX9XIQMySSjlPg7RD/bMgpt8f64kmlBTK2Sv7zKdXU+hZKzAxZudCgZ3zcHp
	+cZ8mFSPwF34QmmmZR6DU8IiPOsklcZEQPzoPz4kEW3GRfYZoH6dUW/yAsGn0AEt
	7IoYJ3YhGh5pRTEZNVyhQHOVH88WEVmxH+KcBWdZ5jyJkQPV0kWeC6cXt7B2WfIC
	aekeKC1Kd3Y6CBliaQF6QFP+dQSA+3X+G6IEJlUa2/mZEijPf0LtBnJMHZrpkw+1
	WK40W0RXU3Xvqi5nWjp61BxfcghZ78JgRlvlmES06FwOg4dyimzgs2DclYC8i91Y
	nPVz9JM43el1DL0lmY39A==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddruddttddgkeegucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuf
    fkgggtugesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihs
    khhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhngh
    hslhgrsgdrtghomheqnecuggftrfgrthhtvghrnheptddugfeuhfehfeetueeujeeiieeg
    gfdthfdtuedvudekjeetiedtfeejtedvjeejnecuffhomhgrihhnpehqvghmuhdrohhrgh
    dpqhhusggvshdqohhsrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm
    pehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslh
    grsgdrtghomhdpnhgspghrtghpthhtohepuddpmhhouggvpehsmhhtphhouhhtpdhrtghp
    thhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 19 Dec 2024 17:14:52 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel 
Subject: Linux 6.13-rc3 many different panics in Xen PV dom0
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="q36KIBHH+nmi0JO5"
Content-Disposition: inline


--q36KIBHH+nmi0JO5
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 19 Dec 2024 17:14:52 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel 
Subject: Linux 6.13-rc3 many different panics in Xen PV dom0

Hi,

It crashes on boot like below, most of the times. But sometimes (rarely)
it manages to stay alive. Below I'm pasting few of the crashes that look
distinctly different, if you follow the links, you can find more of
them. IMHO it looks like some memory corruption bug somewhere. I tested
also Linux 6.13-rc2 before, and it had very similar issue.

The traces below are all from nested virt (Xen inside KVM), tests with
Xen directly on the hardware are still in progress. But -rc2 failed all
of them too, so if it's the same issue, I guess they will looks similar.

Who should I CC here? The failures are all over the place... linux-mm?

[    1.743728] ------------[ cut here ]------------
[    1.744911] WARNING: CPU: 0 PID: 105 at arch/x86/xen/multicalls.c:188 xe=
n_mc_flush+0x226/0x4f0
[    1.746474] Modules linked in:
[    1.747093] CPU: 0 UID: 0 PID: 105 Comm: modprobe Not tainted 6.13.0-0.r=
c3.2.qubes.1.fc41.x86_64 #1
[    1.748722] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel=
-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014
[    1.750634] RIP: e030:xen_mc_flush+0x226/0x4f0
[    1.751484] Code: c0 48 c1 e0 05 48 05 00 70 3c 81 e8 d4 98 0e 01 48 89 =
45 18 48 85 c0 0f 89 b6 fe ff ff 44 8b b3 e0 f2 01 00 41 bf 01 00 00 00 <0f=
> 0b 65 8b 0d bd 34 d4 7f 44 89 f2 44 89 fe 48 c7 c7 70 0f d5 81
[    1.754715] RSP: e02b:ffffc900404e7978 EFLAGS: 00010086
[    1.755688] RAX: fffffffffffffff0 RBX: ffff88817fe00000 RCX: ffff88817fe=
1f2f0
[    1.756971] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff88817fe=
1faf0
[    1.758258] RBP: ffff88817fe1f2e0 R08: 0000000000000000 R09: ffff8881016=
95dc0
[    1.759540] R10: 0000000000007ff0 R11: 00000000000000e4 R12: 00000000000=
00042
[    1.760829] R13: 0000000000000000 R14: 0000000000000001 R15: 00000000000=
00001
[    1.762122] FS:  0000709a60dc5740(0000) GS:ffff88817fe00000(0000) knlGS:=
0000000000000000
[    1.763575] CS:  e030 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.764633] CR2: 00007ffd77bc48c8 CR3: 0000000100a22000 CR4: 00000000000=
50660
[    1.765921] Call Trace:
[    1.766431]  
[    1.766891]  ? show_trace_log_lvl+0x1b0/0x2f0
[    1.767726]  ? show_trace_log_lvl+0x1b0/0x2f0
[    1.768560]  ? xen_leave_lazy_mmu+0x15/0x60
[    1.769349]  ? xen_mc_flush+0x226/0x4f0
[    1.770093]  ? __warn.cold+0x93/0xf2
[    1.770795]  ? xen_mc_flush+0x226/0x4f0
[    1.771535]  ? report_bug+0xff/0x140
[    1.772236]  ? handle_bug+0x58/0x90
[    1.772924]  ? exc_invalid_op+0x17/0x70
[    1.773659]  ? asm_exc_invalid_op+0x1a/0x20
[    1.774448]  ? xen_mc_flush+0x226/0x4f0
[    1.775188]  ? xen_mc_flush+0x20c/0x4f0
[    1.775923]  ? xen_extend_mmu_update+0x4e/0xd0
[    1.776764]  xen_leave_lazy_mmu+0x15/0x60
[    1.777526]  set_ptes.constprop.0+0x1f/0x30
[    1.778322]  __text_poke+0x18c/0x4a0
[    1.779017]  ? __pfx_text_poke_memcpy+0x10/0x10
[    1.779877]  text_poke_copy_locked+0x63/0xa0
[    1.780696]  text_poke_copy+0x32/0x50
[    1.781408]  post_relocation+0xfd/0x190
[    1.782146]  load_module+0x480/0x810
[    1.782843]  init_module_from_file+0x86/0xc0
[    1.783661]  idempotent_init_module+0x115/0x310
[    1.784519]  __x64_sys_finit_module+0x65/0xc0
[    1.785351]  do_syscall_64+0x82/0x160
[    1.786064]  ? syscall_exit_to_user_mode+0x15/0x210
[    1.786975]  ? do_syscall_64+0x8e/0x160
[    1.787708]  ? xen_extend_mmu_update+0x4e/0xd0
[    1.788552]  ? xen_leave_lazy_mmu+0x15/0x60
[    1.789342]  ? set_ptes.isra.0+0x79/0x90
[    1.790100]  ? _raw_spin_unlock+0xe/0x30
[    1.790847]  ? do_anonymous_page+0x103/0x4a0
[    1.791664]  ? __handle_mm_fault+0x39a/0x6f0
[    1.796723]  ? do_syscall_64+0x8e/0x160
[    1.797457]  ? __count_memcg_events+0xc0/0x180
[    1.798310]  ? count_memcg_events.constprop.0+0x24/0x30
[    1.799274]  ? handle_mm_fault+0x20d/0x330
[    1.800055]  ? do_user_addr_fault+0x55a/0x7b0
[    1.800885]  ? exc_page_fault+0x83/0x180
[    1.801640]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[    1.802598] RIP: 0033:0x709a60ebca5d
[    1.803300] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 =
89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48=
> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 83 73 0f 00 f7 d8 64 89 01 48
[    1.806707] RSP: 002b:00007ffd77bc7868 EFLAGS: 00000246 ORIG_RAX: 000000=
0000000139
[    1.808096] RAX: ffffffffffffffda RBX: 0000644519919a00 RCX: 0000709a60e=
bca5d
[    1.809386] RDX: 0000000000000000 RSI: 00006444e143f715 RDI: 00000000000=
00000
[    1.810935] RBP: 00007ffd77bc7920 R08: 0000709a60fb4b20 R09: 00000000000=
00000
[    1.812182] R10: 0000644519919e50 R11: 0000000000000246 R12: 00006444e14=
3f715
[    1.813422] R13: 0000000000040000 R14: 0000644519919c40 R15: 00006445199=
19470
[    1.814662]  
[    1.815124] ---[ end trace 0000000000000000 ]---
[    1.815967] 1 of 1 multicall(s) failed: cpu 0
[    1.816769]   call  1: op=3D1 arg=3D[ffff88817fe1faf0] result=3D-16
[    1.817799] BUG: unable to handle page fault for address: 00006a042c1ac0=
00
[    1.818988] #PF: supervisor write access in kernel mode
[    1.819930] #PF: error_code(0x0002) - not-present page
[    1.820847] PGD 100085067 P4D 100085067 PUD 100086067 PMD 100087067 PTE 0
[    1.822021] Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI
[    1.822900] CPU: 0 UID: 0 PID: 105 Comm: modprobe Tainted: G        W   =
       6.13.0-0.rc3.2.qubes.1.fc41.x86_64 #1
[    1.824686] Tainted: [W]=3DWARN
[    1.825275] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel=
-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014
[    1.827109] RIP: e030:memcpy+0xc/0x20
[    1.827799] Code: 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 90 90 90 90 =
90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 48 89 f8 48 89 d1  a4 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 90 90
[    1.830926] RSP: e02b:ffffc900404e79f0 EFLAGS: 00010006
[    1.831859] RAX: 00006a042c1ac000 RBX: 0000000000001000 RCX: 00000000000=
01000
[    1.833091] RDX: 0000000000001000 RSI: ffffc900400c5000 RDI: 00006a042c1=
ac000
[    1.834324] RBP: ffffffffc0401000 R08: 0000000000000000 R09: 3120206c6c6=
16320
[    1.835559] R10: 0000000000007ff0 R11: 20206c6c61632020 R12: ffff8881000=
8f380
[    1.836792] R13: 0000000000000000 R14: 0000000000001000 R15: ffff8881000=
8d280
[    1.838029] FS:  0000709a60dc5740(0000) GS:ffff88817fe00000(0000) knlGS:=
0000000000000000
[    1.839461] CS:  e030 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.840591] CR2: 00006a042c1ac000 CR3: 0000000100082000 CR4: 00000000000=
50660
[    1.841834] Call Trace:
[    1.842328]  
[    1.842782]  ? show_trace_log_lvl+0x1b0/0x2f0
[    1.843588]  ? show_trace_log_lvl+0x1b0/0x2f0
[    1.844417]  ? __text_poke+0x250/0x4a0
[    1.845298]  ? __die_body.cold+0x8/0x12
[    1.846055]  ? page_fault_oops+0x146/0x160
[    1.846824]  ? exc_page_fault+0x7e/0x180
[    1.847584]  ? asm_exc_page_fault+0x26/0x30
[    1.848372]  ? memcpy+0xc/0x20
[    1.848977]  __text_poke+0x250/0x4a0
[    1.849647]  ? __pfx_text_poke_memcpy+0x10/0x10
[    1.850481]  text_poke_copy_locked+0x63/0xa0
[    1.851270]  text_poke_copy+0x32/0x50
[    1.851963]  post_relocation+0xfd/0x190
[    1.852675]  load_module+0x480/0x810
[    1.853353]  init_module_from_file+0x86/0xc0
[    1.854148]  idempotent_init_module+0x115/0x310
[    1.855022]  __x64_sys_finit_module+0x65/0xc0
[    1.855846]  do_syscall_64+0x82/0x160
[    1.856567]  ? syscall_exit_to_user_mode+0x15/0x210
[    1.857531]  ? do_syscall_64+0x8e/0x160
[    1.858247]  ? xen_extend_mmu_update+0x4e/0xd0
[    1.859062]  ? xen_leave_lazy_mmu+0x15/0x60
[    1.859830]  ? set_ptes.isra.0+0x79/0x90
[    1.860555]  ? _raw_spin_unlock+0xe/0x30
[    1.861277]  ? do_anonymous_page+0x103/0x4a0
[    1.862077]  ? __handle_mm_fault+0x39a/0x6f0
[    1.862873]  ? do_syscall_64+0x8e/0x160
[    1.863586]  ? __count_memcg_events+0xc0/0x180
[    1.864407]  ? count_memcg_events.constprop.0+0x24/0x30
[    1.865349]  ? handle_mm_fault+0x20d/0x330
[    1.866120]  ? do_user_addr_fault+0x55a/0x7b0
[    1.866947]  ? exc_page_fault+0x83/0x180
[    1.867674]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[    1.868591] RIP: 0033:0x709a60ebca5d
[    1.869271] Code: Unable to access opcode bytes at 0x709a60ebca33.
[    1.870358] RSP: 002b:00007ffd77bc7868 EFLAGS: 00000246 ORIG_RAX: 000000=
0000000139
[    1.871697] RAX: ffffffffffffffda RBX: 0000644519919a00 RCX: 0000709a60e=
bca5d
[    1.872938] RDX: 0000000000000000 RSI: 00006444e143f715 RDI: 00000000000=
00000
[    1.874178] RBP: 00007ffd77bc7920 R08: 0000709a60fb4b20 R09: 00000000000=
00000
[    1.875420] R10: 0000644519919e50 R11: 0000000000000246 R12: 00006444e14=
3f715
[    1.876656] R13: 0000000000040000 R14: 0000644519919c40 R15: 00006445199=
19470
[    1.877893]  
[    1.878348] Modules linked in:
[    1.878946] CR2: 00006a042c1ac000
[    1.879585] ---[ end trace 0000000000000000 ]---
[    1.880429] RIP: e030:memcpy+0xc/0x20
[    1.881112] Code: 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 90 90 90 90 =
90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 48 89 f8 48 89 d1  a4 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 90 90
[    1.884228] RSP: e02b:ffffc900404e79f0 EFLAGS: 00010006
[    1.885158] RAX: 00006a042c1ac000 RBX: 0000000000001000 RCX: 00000000000=
01000
[    1.886388] RDX: 0000000000001000 RSI: ffffc900400c5000 RDI: 00006a042c1=
ac000
[    1.887619] RBP: ffffffffc0401000 R08: 0000000000000000 R09: 3120206c6c6=
16320
[    1.888852] R10: 0000000000007ff0 R11: 20206c6c61632020 R12: ffff8881000=
8f380
[    1.890128] R13: 0000000000000000 R14: 0000000000001000 R15: ffff8881000=
8d280
[    1.891377] FS:  0000709a60dc5740(0000) GS:ffff88817fe00000(0000) knlGS:=
0000000000000000
[    1.892788] CS:  e030 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.893805] CR2: 00006a042c1ac000 CR3: 0000000100082000 CR4: 00000000000=
50660
[    1.895039] Kernel panic - not syncing: Fatal exception
[    1.895971] Kernel Offset: disabled

Full log:
https://openqa.qubes-os.org/tests/122879/logfile?filename=3Dserial0.txt

Another failure looks like this:

[    1.813118] BUG: unable to handle page fault for address: ffffea66666666=
48
[    1.814401] #PF: supervisor read access in kernel mode
[    1.815428] #PF: error_code(0x0000) - not-present page
[    1.816472] PGD 7f7d1067 P4D 7f7d1067 PUD 0=20
[    1.817286] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
[    1.818157] CPU: 0 UID: 0 PID: 214 Comm: modprobe Not tainted 6.13.0-0.r=
c3.2.qubes.1.fc41.x86_64 #1
[    1.819864] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel=
-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014
[    1.821711] RIP: e030:migration_entry_wait_on_locked+0x69/0x2e0
[    1.823058] Code: 00 48 c7 44 24 20 00 00 00 00 f3 48 ab e9 56 01 00 00 =
48 b8 ff ff ff ff ff 00 00 00 48 21 d0 48 c1 e0 06 48 03 05 0f 97 89 01 <48=
> 8b 48 08 49 89 c6 f6 c1 01 0f 85 39 02 00 00 0f 1f 44 00 00 48
[    1.826206] RSP: e02b:ffffc90041187940 EFLAGS: 00010282
[    1.827138] RAX: ffffea6666666640 RBX: ccccccccccccccc0 RCX: 00000000000=
00000
[    1.828377] RDX: 6401999999999999 RSI: ffffc90041187968 RDI: ffffc900411=
879a0
[    1.829631] RBP: 6401999999999999 R08: 0000000000000067 R09: ffffc900411=
87ad8
[    1.830885] R10: 0000000000000000 R11: 0000000000000000 R12: 02000000000=
00080
[    1.832143] R13: 0000000183689067 R14: 0000000000000af0 R15: ffff88810a5=
07660
[    1.833504] FS:  0000000000000000(0000) GS:ffff88817fe00000(0000) knlGS:=
0000000000000000
[    1.835186] CS:  e030 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.836379] CR2: ffffea6666666648 CR3: 0000000100a0e000 CR4: 00000000000=
50660
[    1.837763] Call Trace:
[    1.838316]  
[    1.838784]  ? show_trace_log_lvl+0x1b0/0x2f0
[    1.839652]  ? show_trace_log_lvl+0x1b0/0x2f0
[    1.840513]  ? migration_entry_wait+0xf0/0x100
[    1.841366]  ? __die_body.cold+0x8/0x12
[    1.842100]  ? page_fault_oops+0x146/0x160
[    1.842887]  ? exc_page_fault+0x170/0x180
[    1.843671]  ? asm_exc_page_fault+0x26/0x30
[    1.844466]  ? migration_entry_wait_on_locked+0x69/0x2e0
[    1.845436]  ? __raw_callee_save_xen_pmd_val+0x15/0x30
[    1.846431]  migration_entry_wait+0xf0/0x100
[    1.847227]  do_swap_page+0x4a9/0xeb0
[    1.847940]  ? xen_pmd_val+0x35/0x70
[    1.848615]  ? __raw_callee_save_xen_pmd_val+0x15/0x30
[    1.853785]  ? __pfx_default_wake_function+0x10/0x10
[    1.854676]  __handle_mm_fault+0x39a/0x6f0
[    1.855426]  ? mt_find+0x213/0x570
[    1.856074]  handle_mm_fault+0x115/0x330
[    1.856816]  do_user_addr_fault+0x1ca/0x7b0
[    1.857576]  exc_page_fault+0x7e/0x180
[    1.858280]  asm_exc_page_fault+0x26/0x30
[    1.859018] RIP: e030:elf_load+0x20f/0x240
[    1.859773] Code: 39 d9 73 16 41 f6 c4 02 0f 84 1a ff ff ff 49 c7 c5 f2 =
ff ff ff e9 4d fe ff ff 0f 1f 00 b9 00 10 00 00 48 89 df 48 29 c1 31 c0  aa 0f 1f 00 0f 1f 00 48 85 c9 75 0d 48 8b 75 28 48 8b 4d 20 e9
[    1.862907] RSP: e02b:ffffc90041187d08 EFLAGS: 00010246
[    1.863841] RAX: 0000000000000000 RBX: 000070b32bcc0104 RCX: 00000000000=
00efc
[    1.865081] RDX: 000070b32bcc02e0 RSI: 0000000000000000 RDI: 000070b32bc=
c0104
[    1.866321] RBP: ffff888108b59470 R08: ffff88810a506668 R09: 00000000000=
00035
[    1.867568] R10: 0000000000000000 R11: 0000000000000040 R12: 00000000000=
00003
[    1.868809] R13: 000070b32bcbd000 R14: ffff88810a750000 R15: 00000000000=
00000
[    1.870056]  ? elf_load+0xa8/0x240
[    1.870707]  load_elf_interp.isra.0+0x1b5/0x330
[    1.871542]  load_elf_binary+0xa35/0xf30
[    1.872268]  search_binary_handler+0xd3/0x260
[    1.873083]  exec_binprm+0x54/0x180
[    1.873750]  bprm_execve.part.0+0x144/0x1e0
[    1.874516]  kernel_execve+0x112/0x140
[    1.875215]  call_usermodehelper_exec_async+0xd0/0x190
[    1.876135]  ? __pfx_call_usermodehelper_exec_async+0x10/0x10
[    1.877167]  ret_from_fork+0x34/0x50
[    1.877847]  ? __pfx_call_usermodehelper_exec_async+0x10/0x10
[    1.878871]  ret_from_fork_asm+0x1a/0x30
[    1.879601]  
[    1.880056] Modules linked in:
[    1.880659] CR2: ffffea6666666648
[    1.881296] ---[ end trace 0000000000000000 ]---
[    1.882142] RIP: e030:migration_entry_wait_on_locked+0x69/0x2e0
[    1.883198] Code: 00 48 c7 44 24 20 00 00 00 00 f3 48 ab e9 56 01 00 00 =
48 b8 ff ff ff ff ff 00 00 00 48 21 d0 48 c1 e0 06 48 03 05 0f 97 89 01 <48=
> 8b 48 08 49 89 c6 f6 c1 01 0f 85 39 02 00 00 0f 1f 44 00 00 48
[    1.886323] RSP: e02b:ffffc90041187940 EFLAGS: 00010282
[    1.887258] RAX: ffffea6666666640 RBX: ccccccccccccccc0 RCX: 00000000000=
00000
[    1.888501] RDX: 6401999999999999 RSI: ffffc90041187968 RDI: ffffc900411=
879a0
[    1.889748] RBP: 6401999999999999 R08: 0000000000000067 R09: ffffc900411=
87ad8
[    1.890990] R10: 0000000000000000 R11: 0000000000000000 R12: 02000000000=
00080
[    1.892225] R13: 0000000183689067 R14: 0000000000000af0 R15: ffff88810a5=
07660
[    1.893468] FS:  0000000000000000(0000) GS:ffff88817fe00000(0000) knlGS:=
0000000000000000
[    1.894881] CS:  e030 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.895902] CR2: ffffea6666666648 CR3: 0000000100a0e000 CR4: 00000000000=
50660
[    1.897143] Kernel panic - not syncing: Fatal exception
[    1.898079] Kernel Offset: disabled

Full log:
https://openqa.qubes-os.org/tests/122881/logfile?filename=3Dserial0.txt

Or this:

[    1.672650] Kernel panic - not syncing: corrupted stack end detected ins=
ide scheduler
[    1.674030] CPU: 1 UID: 0 PID: 107 Comm: cryptomgr_test Not tainted 6.13=
=2E0-0.rc3.2.qubes.1.fc41.x86_64 #1
[    1.676339] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel=
-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014
[    1.678240] Call Trace:
[    1.678743]  
[    1.679185]  ? __pfx_cryptomgr_test+0x10/0x10
[    1.679998]  dump_stack_lvl+0x5d/0x80
[    1.680690]  panic+0x155/0x30f
[    1.681283]  schedule_debug.isra.0.cold+0xc/0xc
[    1.682151]  __schedule+0x6f/0x600
[    1.682819]  ? __pfx_cryptomgr_test+0x10/0x10
[    1.683616]  do_task_dead+0x42/0x50
[    1.684279]  do_exit+0x331/0x4a0
[    1.684902]  kthread_exit+0x28/0x30
[    1.685565]  __module_put_and_kthread_exit+0x1a/0x20
[    1.686458]  cryptomgr_test+0x3f/0x40
[    1.687195]  kthread+0xd2/0x100
[    1.687813]  ? __pfx_kthread+0x10/0x10
[    1.688545]  ret_from_fork+0x34/0x50
[    1.689299]  ? __pfx_kthread+0x10/0x10
[    1.690150]  ret_from_fork_asm+0x1a/0x30
[    1.690938]  
[    1.691417] Kernel Offset: disabled


Full log:
https://openqa.qubes-os.org/tests/122877/logfile?filename=3Dserial0.txt



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

--q36KIBHH+nmi0JO5
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmdkRn4ACgkQ24/THMrX
1yygWwf/XXE1g8GUkGOMnrWhA0DD11qZAcvPVA5qbBPbcxz80hbAfRwVbwxU68AF
JblGyM8VxBlqH9vHrLamFgu8WM45Hftyx4JqZTUyCbd5xWXIxH9InlyI6bpj3qrr
O+q2E8sWJoyg4lCpgnqlGLMXJkV5ufSnbSaPbDhqqWosewlaH69AAAnLLDkCj4bq
3qi+gn7BCZzIdqUU5UNYTol0eT5fuphgw7K5U1i0WYhaCF7Zw3z0IovVGhKJ5vKW
g4vGob7OpujERb/8By+txydUAGRKD0C752DplEJH6T9x630aqFGSfV2ppaDnEtQx
D3h7jiEAMRZ9PCaT3zR8ndQt0HRGxA==
=5fQ1
-----END PGP SIGNATURE-----

--q36KIBHH+nmi0JO5--


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 16:23:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 16:23:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861363.1273286 (Exim 4.92)
	(envelope-from )
	id 1tOJIu-0006oq-Gd; Thu, 19 Dec 2024 16:23:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861363.1273286; Thu, 19 Dec 2024 16:23:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOJIu-0006oj-E9; Thu, 19 Dec 2024 16:23:12 +0000
Received: by outflank-mailman (input) for mailman id 861363;
 Thu, 19 Dec 2024 16:23: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 1tOJIs-0006od-Br
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 16:23:10 +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 88d7b751-be25-11ef-a0d8-8be0dac302b0;
 Thu, 19 Dec 2024 17:23:09 +0100 (CET)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-385e0e224cbso578848f8f.2
 for ; Thu, 19 Dec 2024 08:23:09 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c832ec4sm1876678f8f.26.2024.12.19.08.23.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Dec 2024 08:23: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: 88d7b751-be25-11ef-a0d8-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734625388; x=1735230188; 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=2IR0BSZUAuTEhCbr7Bx0oDiQpGrG11L/9HjPZJOLtuQ=;
        b=BOojNmIPwfYWWPuWJpPZkFxVwtUqVuSrxxj2SqLJjHL4pxLcr9ev0kV+1DtSMOcTR6
         cDqSXeFF8lGbLXuy1J+seDSopVa0n2gBVjzrxwu0uZ/gM8lj/qdqvrnttIf7lBnqIMEe
         z/1AMjtBgMQXuxDGOqsxJmeSKikAqfbCw8UVk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734625388; x=1735230188;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=2IR0BSZUAuTEhCbr7Bx0oDiQpGrG11L/9HjPZJOLtuQ=;
        b=LXgH4QOo6CgvFQorPDt4fLaVsKvisA9Bwi19eg9bkXNW5KSLq/49HiUElgOc34gRiW
         y8qmJXwbNokWbNjtlkC6vE+Jpbtot+9+lVO0ZB7R3pq/xrAuJWLn8oTxCFLim0wcHtt3
         9KiRpv8o+vGOz8LidnKDOYcqFqMukZBk2wQx774pTMcVHiFskuu4YiW7uXbS0OXh7lOh
         QO/ix8qzZLlCVVbFcL2VGfRi9xz/Pk37d7Ceo9lr9fVj/y+R+Ajn4w/OaFR7YIgunLX3
         nwmhstE72I8Jsn7AQxTI8PjDjUQ1vI4gKScbQrXJPGHb78vq0GekpenpjD628EwEyq5+
         NxrA==
X-Forwarded-Encrypted: i=1; AJvYcCWVPVm4+EtzWpmMgKtej99zMMrk3anwlTW6g5kBAoWHRkZeVQLMjbojdbxFHJHX6MkCG0eDGKlQqZs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyWsZcMxElcKK1T2Ye62poGjxBc7SY8JTxw/L1zGsdfKpD8NsIF
	RG6aHrg8p9V/gJsVLGCKs7dwlS6mlPoLEYYTS//ldl0dOBjalDqp8cu+a8k7EYg=
X-Gm-Gg: ASbGncuFCZN+ziKO3B4dw1QhOtByznpG2LLSglildntgUEs18cftQrREJ35oY9AI79c
	dbDHUnXD8kbiNq8qh8YPPfJM46rQArg+q1P7jbZCvfPdQ4V+acNyXJmncl5MrRxKQBdsZw9ZeJI
	qt7ASBbxxtXWexdDrsiRo42KeLLqmBnG0HnBVU50N3zf+wblAcYlq+FtnCtlwPlfea5AZpx6qjN
	x5j2HWp9sbXZOo9CZzmoBgnZqGkuWKtkZCANq5eH0wfj86EBXvFL7vGm+tfdJUWdifi3E9QH65X
	PkWWLcpBLHczeva2YSke
X-Google-Smtp-Source: AGHT+IHU0VfoQ168XKixlo/NYDusxhd/+X6lg7FlEV1AY6H0fkNGzs194RCbVik1g4IqmlF+EqlrAA==
X-Received: by 2002:a5d:6d81:0:b0:388:caf4:e909 with SMTP id ffacd0b85a97d-38a19b15e97mr4242643f8f.25.1734625388606;
        Thu, 19 Dec 2024 08:23:08 -0800 (PST)
Message-ID: <40950813-58d1-4237-b3ae-96111b1b51ac@citrix.com>
Date: Thu, 19 Dec 2024 16:23:07 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH] ioreq: fix check for
 CONFIG_ARCH_VCPU_IOREQ_COMPLETION
To: Sergiy Kibrik , xen-devel@lists.xenproject.org
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Anthony PERARD ,
 Michal Orzel , Julien Grall ,
 Stefano Stabellini 
References: <20241219111326.3031000-1-Sergiy_Kibrik@epam.com>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <20241219111326.3031000-1-Sergiy_Kibrik@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19/12/2024 11:13 am, Sergiy Kibrik wrote:
> It should be CONFIG_ARCH_VCPU_IOREQ_COMPLETION (as in Kconfig) and not
> misspelled CONFIG_VCPU_ARCH_IOREQ_COMPLETION.
> Bug introduced by:
>
> 979cfdd3e5 ioreq: do not build arch_vcpu_ioreq_completion() for non-VMX configurations
>
> Signed-off-by: Sergiy Kibrik 

Acked-by: Andrew Cooper 


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 16:41:09 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 16:41:09 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861375.1273296 (Exim 4.92)
	(envelope-from )
	id 1tOJaC-0001Q3-1q; Thu, 19 Dec 2024 16:41:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861375.1273296; Thu, 19 Dec 2024 16:41:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOJaB-0001Pw-VN; Thu, 19 Dec 2024 16:41:03 +0000
Received: by outflank-mailman (input) for mailman id 861375;
 Thu, 19 Dec 2024 16:41: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 1tOJaB-0001Pq-2G
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 16:41:03 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 070a9ea8-be28-11ef-a0d8-8be0dac302b0;
 Thu, 19 Dec 2024 17:41:01 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1734626451692938.1409941269775;
 Thu, 19 Dec 2024 08:40: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: 070a9ea8-be28-11ef-a0d8-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1734626454; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=U5wZMZ0g/SdwI6yvxHda0QHqJbSglH/zuv6+Q1qmiNz5rtp8uQXotyvg5NB67cr/v8ZcHPMfJUtMlSH1Qm7juM1REvwDoI3nShCgwuGvzjqcIwrsvZYYbV+GBCw8fVURnBuDkMog1kgnEpfGU7l/VScm/7KF74lwtwmNdqt2Xdw=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1734626454; 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=Lxg3CIzptPf8GHQ8oRlHduu2/DUaDOMWS4If8u1uJHA=; 
	b=cYcyucBv9vDG+FJNimq0cBpV87jt7UvhG7PY6601J1pjerTfMj2HZ9Bpdk7MzugYrFwkIYWApm63wvaVryH1UIMwKmA8PY2li+Z//OsEEZj0YB86Mwu7ztOAct2YAsbi+seugUP9K0oj6SzWYPOngh2Ka2EurgQFtFEC52+rFlc=
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=1734626454;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:From:From:To:To:Cc:Cc:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=Lxg3CIzptPf8GHQ8oRlHduu2/DUaDOMWS4If8u1uJHA=;
	b=Pjcpd4aU5GLtJeRZBIaAGrVfMORh2VFHgInOku9nLJY8biFvSl5zjzfD1Tha4FfJ
	Q0/K07NBWixkI3YYFDglE1TbW/LO+r7pBMk8bq4g0YVJQHfw02MoF2zJmsTFmqjkxyl
	jobeOPBp9eHX5wip/W7Q64vppB+cHKjqfnvP3axE=
Message-ID: <1dbb232f-2a8d-4152-a9ba-215841307fb6@apertussolutions.com>
Date: Thu, 19 Dec 2024 11:40:49 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 11/15] x86/hyperlaunch: add domain id parsing to domain
 config
From: "Daniel P. Smith" 
To: Jan Beulich 
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
 stefano.stabellini@amd.com, Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-12-dpsmith@apertussolutions.com>
 <8a492a4d-cc9c-4756-8fb9-721626c295a6@suse.com>
 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

On 12/11/24 11:21, Daniel P. Smith wrote:
> On 12/2/24 07:02, Jan Beulich wrote:
>> On 23.11.2024 19:20, Daniel P. Smith wrote:
>>> --- a/xen/arch/x86/domain_builder/fdt.h
>>> +++ b/xen/arch/x86/domain_builder/fdt.h
>>> @@ -27,6 +27,24 @@ static inline int __init fdt_cell_as_u64(const 
>>> fdt32_t *cell, uint64_t *val)
>>>       return 0;
>>>   }
>>> +static inline int __init fdt_prop_as_u32(
>>> +    const struct fdt_property *prop, uint32_t *val)
>>> +{
>>> +    if ( !prop || fdt32_to_cpu(prop->len) < sizeof(u32) )
>>> +        return -EINVAL;
>>> +
>>> +    return fdt_cell_as_u32((fdt32_t *)prop->data, val);
>>> +}
>>> +
>>> +static inline bool __init match_fdt_property(
>>> +    const void *fdt, const struct fdt_property *prop, const char *s)
>>> +{
>>> +    int slen, len = strlen(s);
>>
>> Plain int isn't quite appropriate for strlen()'s return. It doesn't 
>> strictly
>> need to be size_t, but it should be at least unsigned int.
> 
> Ack.

I wanted to reply back on this one before posting the next version. By 
implementing Jason's recommendation to unroll this function, the 
strlen() call goes away and slen becomes name_len. But name_len remains 
plain int to align with the fdt_get_string() parameter type.

v/r,
dps


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 17:11:26 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 17:11:26 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861387.1273306 (Exim 4.92)
	(envelope-from )
	id 1tOK3S-0005w9-6q; Thu, 19 Dec 2024 17:11:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861387.1273306; Thu, 19 Dec 2024 17:11: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 1tOK3S-0005w2-4G; Thu, 19 Dec 2024 17:11:18 +0000
Received: by outflank-mailman (input) for mailman id 861387;
 Thu, 19 Dec 2024 17:11: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 1tOK3R-0005vw-2O
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 17:11:17 +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 40f75467-be2c-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 18:11:15 +0100 (CET)
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3862df95f92so616155f8f.2
 for ; Thu, 19 Dec 2024 09:11:15 -0800 (PST)
Received: from [192.168.1.67] ([78.196.4.158])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-43656af6c5bsm56868735e9.2.2024.12.19.09.11.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Dec 2024 09:11: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: 40f75467-be2c-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1734628274; x=1735233074; 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=TBkyLcSf+GGjx0/wEp5sNI3G9o82r4z7VP+tvGX1FFs=;
        b=p3XRUtXz5swqiBi8f3ySKX/uZTFSo3nEHKOLgYUrkLOGFIcLoQX4RrZjJ4wFb+0INg
         EVyx2995LV/Sn9s9GyqDrpN+3dELziNjwtvPO3Ubt3lRfYT2CuU54QectX2fm8hTtPs2
         OoL/wGq+wXXhV4RrzECY39rkG5+lPKaRGNcL7ecZ65P3g4218LAS5+ZrFW7GgdxhiV8F
         IyxavF0xHSLaWbZ9ZO6VltjQGXq/5dw8P2SjOy411A7R2tl16uOEbQFNf5Q2jKpFyqnq
         /3uU2yepNedE4dyG5GAjMogt+ja9NbqCypN5jNKtKkC5tk5VviPlL8TGmjtgWEvGjcNQ
         twzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734628274; x=1735233074;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=TBkyLcSf+GGjx0/wEp5sNI3G9o82r4z7VP+tvGX1FFs=;
        b=u7ldkuhU3WJUQYzTB/H/E5qUlqJG0FYm3/FQLlQdkyT3LciDQv6lH4bLR+XjgGFZcL
         YKZS6ON7DSSpUFjYph2mfEglcqQ6ZyXsmJ/F/wgBjwXuxgnnpn8WWhFLIuAxOgYuFMci
         eRyFjlkbV1bCFnn2DHP4BpvXF++K7/YqfSoaRU/VbuQuvNqE08xjdfJ/JVu9r0JRqoFE
         jFgU+RdP+3NFua86g0qdxVNN+JeLcbgUMAcxxXoroVvH+J/V2xSQNmxFRrAgDCBYZzd8
         1z3nNR5sUnosl2Cwc9wCRtO1UwKwYhP9kqQL9eipUhAQg70azcpaDuAzgOlkxfdsfvLQ
         CAkA==
X-Forwarded-Encrypted: i=1; AJvYcCXhCRuWIHxNoOeo2xe+YJcczaP0lGCBiGyD5wgmlp/9pNMeP1fQHN5t00taoIz0+h7gcdw9HxwNe3k=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yyl9o6fA0hxGBm52uxX4mM3IxfRDLDbQcNXzo2sHJJ4QhDLpziV
	oqWGYZ4xqcJ7/PZg77w7G2I7GWH+7yxuAlKQ0LXxsv4iNaWb5ImxjM1nss1inoI=
X-Gm-Gg: ASbGnctgrBmLAXV5RyvNGcH0HRqh16m7QOvGTv5rXhtelDPG7hDGBn+agrVkGlyNXo/
	qYpZxJ94yXwSirWBRc1VSZEFbCSuSYcZAsKqidjC7ZTCE2SpTUy6rpJBeG7wRLRr87HUFzTR4Tm
	9k48WQV8vwVY1IRm59hN4/Iu8QBVLBljjCg09TFqrfUj64SGF53Dx1b/EW9/3NTT7O/j3HHqu4r
	oaBZ45zFyIE89cNpvczN4r0FI3xH6JQBvLQFsLIHeqBGzmyq9o0ulvnVih8urleFUu2hUM=
X-Google-Smtp-Source: AGHT+IHpT4Cngp0M8WEaFs5xmzjkRHwEThdLD+vf8y+j4IJr4Ju/MTBQiPksoiGJOn+hCcIMUHT/9Q==
X-Received: by 2002:a5d:5846:0:b0:385:f417:ee3d with SMTP id ffacd0b85a97d-388e4d86e8amr7323979f8f.35.1734628274513;
        Thu, 19 Dec 2024 09:11:14 -0800 (PST)
Message-ID: <7f4b7cc0-a012-4243-a3bc-c678688f5ece@linaro.org>
Date: Thu, 19 Dec 2024 18:11:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/3] include: Cleanups around 'exec/cpu-common.h' header
To: qemu-devel@nongnu.org
Cc: Stefano Stabellini ,
 Zhao Liu , "Edgar E. Iglesias"
 , Paul Durrant ,
 Richard Henderson ,
 Yanan Wang , Anton Johansson ,
 Anthony PERARD , xen-devel@lists.xenproject.org
References: <20241217151305.29196-1-philmd@linaro.org>
Content-Language: en-US
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= 
In-Reply-To: <20241217151305.29196-1-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 17/12/24 16:13, Philippe Mathieu-Daudé wrote:

> Philippe Mathieu-Daudé (3):
>    hw/xen: Remove unnecessary 'exec/cpu-common.h' header
>    system/numa: Remove unnecessary 'exec/cpu-common.h' header
>    system/accel-ops: Remove unnecessary 'exec/cpu-common.h' header

Series queued.



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 17:28:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 17:28:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861396.1273317 (Exim 4.92)
	(envelope-from )
	id 1tOKJa-0007wo-Jb; Thu, 19 Dec 2024 17:27:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861396.1273317; Thu, 19 Dec 2024 17:27: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 1tOKJa-0007wh-Fo; Thu, 19 Dec 2024 17:27:58 +0000
Received: by outflank-mailman (input) for mailman id 861396;
 Thu, 19 Dec 2024 17:27: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 1tOKJZ-0007wb-1d
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 17:27:57 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 93a0fd07-be2e-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 18:27:54 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 0065982856FB;
 Thu, 19 Dec 2024 11:27:51 -0600 (CST)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id w19iV3ARoQ8o; Thu, 19 Dec 2024 11:27:51 -0600 (CST)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 2459E8287A8A;
 Thu, 19 Dec 2024 11:27:51 -0600 (CST)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id ESi0HsPSzz4d; Thu, 19 Dec 2024 11:27:50 -0600 (CST)
Received: from [10.11.0.2] (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id 6FD9882856FB;
 Thu, 19 Dec 2024 11:27:50 -0600 (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: 93a0fd07-be2e-11ef-99a3-01e77a169b0f
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 2459E8287A8A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1734629271; bh=M9wrowq2CUkU5CCHyLBb1ZE4jWfNKjh++NAz4V33aNg=;
	h=Message-ID:Date:MIME-Version:To:From;
	b=M3b7N24l795DrVVJ1Ab3+ipY3VCuOmBl4c9x9PI4NYq78wTyvE3P4jesUjCHU4s3t
	 mrxySO1vwQPZ5p5QKlpTYV/pfIofWChpScfm1DkvGwXt2uk0gSWkV+kk5/SJOyB2Dj
	 HmWt6VRw925F5aJjipJxtJvLQxB/odxdfSY65E1k=
X-Virus-Scanned: amavisd-new at rptsys.com
Message-ID: 
Date: Thu, 19 Dec 2024 11:27:49 -0600
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/sched: Untangle credit2 vs cpu_nr_siblings()
To: Andrew Cooper ,
 Xen-devel 
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Stefano Stabellini ,
 Julien Grall , Volodymyr Babchuk
 , Bertrand Marquis ,
 Michal Orzel ,
 Oleksii Kurochko ,
 Juergen Gross 
References: <20241218124900.60886-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Shawn Anastasio 
In-Reply-To: <20241218124900.60886-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi Andrew,

On 12/18/24 6:49 AM, Andrew Cooper wrote:
> Credit2 has no buisness including asm/cpufeature.h or asm/processor.h.
> 
> This was caused by a bad original abstraction, and an even less wise attempt
> to fix the build on my behalf.  It is also the sole reason why PPC and RISC-V
> need cpufeature.h header.
> 
> Worst of all, cpu_data[cpu].x86_num_siblings doesn't even have the same
> meaning between vendors on x86 CPUS.
> 
> Implement cpu_nr_siblings() locally in credit2.c, leaving behind a TODO.  Drop
> the stub from each architecture.
> 
> Fixes: 8e2aa76dc167 ("xen: credit2: limit the max number of CPUs in a runqueue")
> Fixes: ad33a573c009 ("xen/credit2: Fix build following c/s 8e2aa76dc (take 2)")
> Signed-off-by: Andrew Cooper 

Acked-by: Shawn Anastasio 

Thanks,
Shawn


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 18:14:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 18:14:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861415.1273358 (Exim 4.92)
	(envelope-from )
	id 1tOL2b-0006Vh-5J; Thu, 19 Dec 2024 18:14:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861415.1273358; Thu, 19 Dec 2024 18:14: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 1tOL2b-0006Va-2J; Thu, 19 Dec 2024 18:14:29 +0000
Received: by outflank-mailman (input) for mailman id 861415;
 Thu, 19 Dec 2024 18:14: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 1tOL2Z-0006VU-KF
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 18:14:27 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1475bb77-be35-11ef-a0d8-8be0dac302b0;
 Thu, 19 Dec 2024 19:14:26 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 19 Dec 2024 19:14:25 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id E2874234F;
 Thu, 19 Dec 2024 19:14:24 +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: 1475bb77-be35-11ef-a0d8-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734632066; x=1766168066;
  h=from:to:cc:subject:date:message-id:mime-version:
   content-transfer-encoding;
  bh=KH1lcKt8lRD2c9fpVmHrC09cC9OfF/qsIitMWvfTsi0=;
  b=sCHDjezyR9jZRN5NN+fuBIQMMjObuM1+HAk45RKzKEy8DN577vdRFRpE
   1U8H3/5fnj+qd9lm08A24jCwl/AQlX3kAvp2bElpMDlpgz/MQcsV1Ebng
   qjpChGAlas4G4tq1W5AxmHW1xMVm7EpA8XSeh6yNbVdfhVUEtGDVBwpt2
   c=;
X-CSE-ConnectionGUID: lkP41m0DRXSJ6NF2HI7NUA==
X-CSE-MsgGUID: FT5m/XyeR3+iRJKrSI067g==
X-IronPort-AV: E=Sophos;i="6.12,248,1728943200"; 
   d="scan'208";a="28259975"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Ariel Otilibili ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH 0/1] xen/scripts: Fix regex syntax warnings with Python 3.12
Date: Thu, 19 Dec 2024 19:10:42 +0100
Message-ID: <20241219181352.709315-1-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

This patch clears out this warning:

```
$ xen/scripts/xen-analysis.py
xen/scripts/xen_analysis/cppcheck_analysis.py:94: SyntaxWarning: invalid escape sequence '\*'
  comment_line_starts = re.match('^[ \t]*/\*.*$', line)
```

It is the same fix than commit 826a9eb072 (tools: Fix regex syntax warnings with
Python 3.12).

Thank you,

Ariel Otilibili (1):
  xen/scripts: Fix regex syntax warnings with Python 3.12

 xen/scripts/xen_analysis/cppcheck_analysis.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 18:14:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 18:14:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861416.1273368 (Exim 4.92)
	(envelope-from )
	id 1tOL2e-0006k9-Bz; Thu, 19 Dec 2024 18:14:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861416.1273368; Thu, 19 Dec 2024 18:14: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 1tOL2e-0006k2-9L; Thu, 19 Dec 2024 18:14:32 +0000
Received: by outflank-mailman (input) for mailman id 861416;
 Thu, 19 Dec 2024 18:14: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 1tOL2d-0006VU-BE
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 18:14:31 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1760b684-be35-11ef-a0d8-8be0dac302b0;
 Thu, 19 Dec 2024 19:14:30 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 19 Dec 2024 19:14:30 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id 26FD12350;
 Thu, 19 Dec 2024 19:14: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: 1760b684-be35-11ef-a0d8-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734632071; x=1766168071;
  h=from:to:cc:subject:date:message-id:in-reply-to:
   references:mime-version:content-transfer-encoding;
  bh=7LQgNvTdzlEhe7rJ7bWpvqG13yqZ7KAZK6TXTmWxmAQ=;
  b=VkHr3TU6raPZmR0tbZ3eLVIEztbOUPONjdbP2sEVvIJrZn+zz2aHuThp
   COSV8tQT/8JqLZmc/ZY4nkZgZzFPD2f9u3A4hAow5Ow6t9Ht1W1+xJVwz
   PdR1vBmylBFr6wgleikRU/jR91w0+jYPoinN+61h7Q85in9vWuHnDAP46
   c=;
X-CSE-ConnectionGUID: CFqTAF0LQ0O1tdTYlyC+ug==
X-CSE-MsgGUID: LsnL8uAoT7+smUHbG5PbaA==
X-IronPort-AV: E=Sophos;i="6.12,248,1728943200"; 
   d="scan'208";a="28259976"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Ariel Otilibili ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH 1/1] xen/scripts: Fix regex syntax warnings with Python 3.12
Date: Thu, 19 Dec 2024 19:10:43 +0100
Message-ID: <20241219181352.709315-2-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20241219181352.709315-1-Ariel.Otilibili-Anieli@eurecom.fr>
References: <20241219181352.709315-1-Ariel.Otilibili-Anieli@eurecom.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Same fix than commit 826a9eb072 (tools: Fix regex syntax warnings with Python 3.12).

It clears out the warning:

```
$ xen/scripts/xen-analysis.py
xen/scripts/xen_analysis/cppcheck_analysis.py:94: SyntaxWarning: invalid escape sequence '\*'
  comment_line_starts = re.match('^[ \t]*/\*.*$', line)
```

The  warning appears only the first time the command is run, then it disappears.

Fixes: 02b26c02c7 (xen/scripts: add cppcheck tool to the xen-analysis.py script)
Signed-off-by: Ariel Otilibili 
--
Cc: Andrew Cooper 
Cc: Anthony PERARD 
Cc: Michal Orzel 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: "Roger Pau Monné" 
Cc: Stefano Stabellini 
---
 xen/scripts/xen_analysis/cppcheck_analysis.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/scripts/xen_analysis/cppcheck_analysis.py b/xen/scripts/xen_analysis/cppcheck_analysis.py
index ce7bda91b6..532a14b0ad 100644
--- a/xen/scripts/xen_analysis/cppcheck_analysis.py
+++ b/xen/scripts/xen_analysis/cppcheck_analysis.py
@@ -91,7 +91,7 @@ def __generate_suppression_list(out_file):
                         line = header_content[tmp_line]
                         # Matches a line with just optional spaces/tabs and the
                         # start of a comment '/*'
-                        comment_line_starts = re.match('^[ \t]*/\*.*$', line)
+                        comment_line_starts = re.match(r'^[ \t]*/\*.*$', line)
                         # Matches a line with text and the end of a comment '*/'
                         comment_line_stops = re.match(r'^.*\*/$', line)
                         if (not comment_section) and comment_line_starts:
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 18:17:02 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 18:17:02 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861431.1273379 (Exim 4.92)
	(envelope-from )
	id 1tOL53-0007ZK-Pk; Thu, 19 Dec 2024 18:17:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861431.1273379; Thu, 19 Dec 2024 18:17: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 1tOL53-0007ZD-MF; Thu, 19 Dec 2024 18:17:01 +0000
Received: by outflank-mailman (input) for mailman id 861431;
 Thu, 19 Dec 2024 18:17: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 1tOL52-0007Z2-Kq
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 18:17:00 +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 702bb5d0-be35-11ef-a0d8-8be0dac302b0;
 Thu, 19 Dec 2024 19:16:59 +0100 (CET)
Received: by mail-wr1-x432.google.com with SMTP id
 ffacd0b85a97d-3862f11a13dso65861f8f.2
 for ; Thu, 19 Dec 2024 10:16:59 -0800 (PST)
Received: from lab.home
 (dynamic-2a00-1028-83a4-4bca-c0bb-96ff-feed-9d50.ipv6.o2.cz.
 [2a00:1028:83a4:4bca:c0bb:96ff:feed:9d50])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c8ac93csm2089713f8f.95.2024.12.19.10.16.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 19 Dec 2024 10:16: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: 702bb5d0-be35-11ef-a0d8-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734632219; x=1735237019; 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=l4LKRJak7JgaW1Ee5afpTsgw3p3Qau2b0vog00+IaPg=;
        b=fp3R1c01s1ipdqfsYgUL09dOdMFwBGZcp/Yu7WdDgJwHFV5oDNikqz5jHH81qe/Xxv
         Zacl5ABz2uz8Gd1j8Dj4974JcjeOHYRQIECBqAjhA5t3NJQKuCkFXcyZac4tlgPXSTUm
         P/xGDsJ+aftbS2e1UnCT6X51o3V6IMOXCrinQ8fYU+0YUkeF4Szeo9cQ0kT237Vxxlvu
         GYJqCHiGTJB/smMgAuk7TIpWwI1Z3X7Jgnx/QUzTohW+xm2mUF9Znb8F2y3mNJD3aU2y
         pWyd65i5t2t3qxsKgrygPr4JpHTr+pcCeKJoK/BZQoyt5dW9vDGseN3eQ52eXSUVmvDm
         TgpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734632219; x=1735237019;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=l4LKRJak7JgaW1Ee5afpTsgw3p3Qau2b0vog00+IaPg=;
        b=e6giEniiIsly59YCLtWKALN2CJzITFWtPyYj8CBtKQFmsZCvsDtHj+O1N+ST0m1XOj
         iQOcgfAf4LxV6hqrT0PuA3hLVr+C6D+kukwsdpsV8I/uslD3wiUdojzGBm8/itva+qal
         CfGZFv/y+cpaxoHwa3t1JfsiJWRbZj19m782tmMXlyEclMm5feeY6Za2xq6sKwxQcJLO
         SKALDbc4CRqcFnYDoIzCS4Cba1KB2BAhD/+2fo+pPtp2w+z4v9kQ617kwZQlmBaWe8re
         15NwRdZqcXaOO2wL2OmbQCWrMyxj6eoh5DqEJSJI+EBuZsteAXnUlppgcRU5+xAzLGL+
         t4rg==
X-Gm-Message-State: AOJu0Yz2uHW6MP5YgjhjYFgfc2dtZRy4YNj/vsyzJ9pM99SlNJQMZ8dB
	d1OX7+rhb8yg6D3Q+01Hbu0Qo6A9QQGfMnFJlD1z+Wgk0wg4TYgeTyBong==
X-Gm-Gg: ASbGncv0IdL9Jlx4kLbgu8TMu/vRO3gAqOhwsPrhFaFR9fJys72WuoCCs7eQvZ80vND
	pnZbDKANqKwTsb+uY6bQzOtpg71yVP1MglWIqbvM2ZNIcMTYtcnAg8NUMNt9pIz/RRXWFILUY97
	lrS5uap5s6R/E/cczAeA5BBeKnKBdkSQbVfWlRF2MH0jvjNUSUcxsjcyVAFJMn5BvAJIumxUO7K
	G2I/8dnv3UFzHPFFn2OKS/gRpO1eeEPLJxOHfOPqDvWLGDM/UMZtVPJS/SuSt96CbQidC0OSab5
	kg1Xlyf3Do2Ik8EQAzyYp78k77zKwiueUyLu2p7kDl5LzwFDTrrc03x4
X-Google-Smtp-Source: AGHT+IEBH2Iy2i8mC8lK9kMsZD8IIVnupvhGnHC7oAkQLKPT/UepIk8gmf748Gnr5HgQOn+mJ4jC2w==
X-Received: by 2002:a05:600c:3d0b:b0:436:488f:4e4 with SMTP id 5b1f17b1804b1-4365540ef7emr31660585e9.8.1734632218430;
        Thu, 19 Dec 2024 10:16:58 -0800 (PST)
From: "=?UTF-8?q?Petr=20Bene=C5=A1?=" 
X-Google-Original-From: =?UTF-8?q?Petr=20Bene=C5=A1?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Petr=20Bene=C5=A1?= ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Tamas K Lengyel ,
	Alexandru Isaila ,
	Petre Pircalabu ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Anthony PERARD 
Subject: [PATCH 0/2] x86: Add Support for Paging-Write Feature
Date: Thu, 19 Dec 2024 18:16:50 +0000
Message-Id: 
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Petr Beneš 

This patch introduces a new XENMEM_access_r_pw permission. Functionally, it is similar to XENMEM_access_r, but for processors with TERTIARY_EXEC_EPT_PAGING_WRITE support (Intel 12th Gen/Alder Lake and later), it also permits the CPU to write to the page during guest page-table walks (e.g., updating A/D bits) without triggering an EPT violation.

This behavior works by both enabling the EPT paging-write feature and setting the EPT paging-write flag in the EPT leaf entry.

This feature provides a significant performance boost for introspection tools that monitor guest page-table updates. Previously, every page-table modification by the guest—including routine updates like setting A/D bits—triggered an EPT violation, adding unnecessary overhead. The new XENMEM_access_r_pw permission allows these "uninteresting" updates to occur without EPT violations, improving efficiency.

Additionally, this feature simplifies the handling of race conditions in scenarios where an introspection tool:

- Sets an "invisible breakpoint" in the altp2m view for a function F
- Monitors guest page-table updates to track whether the page containing F is paged out
- Encounters a cleared Access (A) bit on the page containing F while the guest is about to execute the breakpoint

In the current implementation:

- If xc_monitor_inguest_pagefault() is enabled, the introspection tool must emulate both the breakpoint and the setting of the Access bit.
- If xc_monitor_inguest_pagefault() is disabled, Xen handles the EPT violation without notifying the introspection tool, setting the Access bit and emulating the instruction. However, Xen fetches the instruction from the default view instead of the altp2m view, potentially causing the breakpoint to be missed.

With this patch, setting XENMEM_access_r_pw for monitored guest page-tables prevents EPT violations in these cases. This change enhances performance and reduces complexity for introspection tools, ensuring seamless breakpoint handling while tracking guest page-table updates.

Petr Beneš (2):
  x86: Rename _rsvd field to pw and move it to the bit 58
  x86/EPT: Add Support for Paging-Write Feature

 xen/arch/arm/mem_access.c               | 4 ++++
 xen/arch/arm/mmu/p2m.c                  | 1 +
 xen/arch/x86/hvm/hvm.c                  | 1 +
 xen/arch/x86/hvm/monitor.c              | 1 +
 xen/arch/x86/hvm/vmx/vmcs.c             | 4 +++-
 xen/arch/x86/include/asm/hvm/vmx/vmcs.h | 3 +++
 xen/arch/x86/include/asm/hvm/vmx/vmx.h  | 4 ++--
 xen/arch/x86/include/asm/p2m.h          | 1 +
 xen/arch/x86/mm/hap/nested_hap.c        | 3 +++
 xen/arch/x86/mm/mem_access.c            | 3 +++
 xen/arch/x86/mm/p2m-ept.c               | 4 ++++
 xen/include/public/memory.h             | 9 +++++++++
 xen/include/xen/mem_access.h            | 6 ++++++
 13 files changed, 41 insertions(+), 3 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 18:17:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 18:17:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861432.1273389 (Exim 4.92)
	(envelope-from )
	id 1tOL55-0007oS-52; Thu, 19 Dec 2024 18:17:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861432.1273389; Thu, 19 Dec 2024 18:17: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 1tOL55-0007oL-0K; Thu, 19 Dec 2024 18:17:03 +0000
Received: by outflank-mailman (input) for mailman id 861432;
 Thu, 19 Dec 2024 18:17: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 1tOL53-0007Z2-AM
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 18:17:01 +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 7091889a-be35-11ef-a0d8-8be0dac302b0;
 Thu, 19 Dec 2024 19:17:00 +0100 (CET)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3862e2c9bb5so51056f8f.0
 for ; Thu, 19 Dec 2024 10:17:00 -0800 (PST)
Received: from lab.home
 (dynamic-2a00-1028-83a4-4bca-c0bb-96ff-feed-9d50.ipv6.o2.cz.
 [2a00:1028:83a4:4bca:c0bb:96ff:feed:9d50])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c8ac93csm2089713f8f.95.2024.12.19.10.16.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 19 Dec 2024 10:16: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: 7091889a-be35-11ef-a0d8-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734632219; x=1735237019; 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=EnMObdzqB9wbB+o0eN1Xm+k8F+r8zSvzJLNdA4kFbng=;
        b=Joj+NZ2Loyra5MlajJ/tabfepxD/t7zHIpe2vrlmw1UzJzZ4+/ZXa3jsXQCQN8zLYG
         GX8laOz158uMHZgHRdq917ZHxyG02/s/CQci3V8Z8yw+ht66tqqjWsG/lfnTCQgVgPoI
         Qh94Xnh8L5qMwthxcA275zvWM/W3+3P3VPpH/61cuH/JNOan2N2XfhlBbVYKzTblTT10
         FCMdSkAvVpbW/1lQDEOIKqyOuxNGTTJTFcjd/eh7qL60+G1RqUD/qeXjzQnpUB4nJrC0
         trse0I3BF2n0iU8tzxMeOOoIDYRPX5+A4tZWBGdw6Y8s69lVtlzTKOVECvKCa6Gg8181
         pw1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734632219; x=1735237019;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=EnMObdzqB9wbB+o0eN1Xm+k8F+r8zSvzJLNdA4kFbng=;
        b=dc4XD9bP9lgtTGYQ6kyDC8RFnu++JFFoLzYMyqfUsaRovG2l5IcCFQ0OKOu0GgxZAE
         +geQ7SiekkXM+pWnWQFaWv1eOjAMApBd2ppj1pWZWdo+380/PSGUTnJu2HFPJxu9vmv9
         0mMtwhw7tl3Tz51skzdLhXkmM1hapovAM66GH6v1N6rJPVFtehD2/pXMXcK0d/7fnYbE
         QcPSBQzjO+zqeqL+Yqhp6buAMVPtXtr5Jwv6hPYlFSaXTSQEyo4Z48vP81r1ZvGiebU9
         B3CC3dcqXl7dBd0EWbc2+lRCVYi9BvjKzgD4MNQUyZNIzlrDqkPa+3RYKi9mFBNkqj9i
         ihuw==
X-Gm-Message-State: AOJu0YwMRnoDqf85uib2PHgwER57CkPAF9Ni2nZ8z7GpOzRspQnCFXz6
	igdSEMlc7mJZYZPzRWsR6YSF57faLdqh6fBIF+6EEL8aXr8KmanwKflcQQ==
X-Gm-Gg: ASbGncvt1sQ8BxN68p/NQVp1Nqqy99t3CtF37VCb0+rymGzV5zllZSXLoH/gtsYp79C
	zVZGN/Uy2IKgxWUGqfBvN/O021yxmMV5bDCzMZgyyFx6F/1Nf/NJ2H66AUqTAgJx6uHRGUG24SC
	eQc/JUsADK1/l3Ae/0TVP2Zz05CcrONZuua+Z36ei2UwNjLSYif4wny3ZVlaMmWmE4kNOqLAjMe
	6OyzjAeSBopo2kFyv+a9T5HAiRAjj5Wec+CvVFioTvfRGAFUNXmX9mOhCgUI8ivLjA4g+b43AgJ
	vWJqPdEqMa3Z4O8cuQ2foQC3vbZlH6mB/EeobkTB7i07aoi3Vs7JzutD
X-Google-Smtp-Source: AGHT+IGSVwMNND5G4399cEUQkcWaN/r5PHt6nJp3Jf80hKVdIkSXRxvQe1/Gt/0oJ347EtbZBmS18Q==
X-Received: by 2002:a5d:5f8f:0:b0:385:fd31:ca24 with SMTP id ffacd0b85a97d-38a223f5bdcmr27252f8f.12.1734632219246;
        Thu, 19 Dec 2024 10:16:59 -0800 (PST)
From: "=?UTF-8?q?Petr=20Bene=C5=A1?=" 
X-Google-Original-From: =?UTF-8?q?Petr=20Bene=C5=A1?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Petr=20Bene=C5=A1?= ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH 1/2] x86: Rename _rsvd field to pw and move it to the bit 58
Date: Thu, 19 Dec 2024 18:16:51 +0000
Message-Id: <2cee46969dcad25ccc4b00c80742e21770375e08.1734631969.git.w1benny@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Petr Beneš 

The EPT Paging-write feature (when enabled by the TERTIARY_EXEC_EPT_PAGING_WRITE bit) uses bit 58 of the EPT entry to indicate that guest paging may update the page, even if the W access is not set.

This patch is a preparation for the EPT Paging-write feature.
---
 xen/arch/x86/include/asm/hvm/vmx/vmx.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
index f0ec459622..d920de96b7 100644
--- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
@@ -34,8 +34,8 @@ typedef union {
                                EPT/VT-d usage */
         mfn         :   40, /* bits 51:12 - Machine physical frame number */
         sa_p2mt     :   6,  /* bits 57:52 - Software available 2 */
-        access      :   4,  /* bits 61:58 - p2m_access_t */
-        _rsvd       :   1,  /* bit 62 - reserved */
+        pw          :   1,  /* bit 58 - Paging-write access */
+        access      :   4,  /* bits 62:59 - p2m_access_t */
         suppress_ve :   1;  /* bit 63 - suppress #VE */
     };
     u64 epte;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 18:17:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 18:17:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861433.1273399 (Exim 4.92)
	(envelope-from )
	id 1tOL56-00083a-BF; Thu, 19 Dec 2024 18:17:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861433.1273399; Thu, 19 Dec 2024 18: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 1tOL56-00083R-7Q; Thu, 19 Dec 2024 18:17:04 +0000
Received: by outflank-mailman (input) for mailman id 861433;
 Thu, 19 Dec 2024 18:17: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 1tOL54-0007Z2-AV
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 18:17:02 +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 7139613e-be35-11ef-a0d8-8be0dac302b0;
 Thu, 19 Dec 2024 19:17:01 +0100 (CET)
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-385d851e7c3so47936f8f.3
 for ; Thu, 19 Dec 2024 10:17:01 -0800 (PST)
Received: from lab.home
 (dynamic-2a00-1028-83a4-4bca-c0bb-96ff-feed-9d50.ipv6.o2.cz.
 [2a00:1028:83a4:4bca:c0bb:96ff:feed:9d50])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c8ac93csm2089713f8f.95.2024.12.19.10.16.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 19 Dec 2024 10:17: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: 7139613e-be35-11ef-a0d8-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734632220; x=1735237020; 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=r7rrd3s6trX0PM3fTY21ALz1gAXhr7UFRn3XH1zFrF0=;
        b=QquTd7fi2AEqSYwsun0yHQ95ExkeEUxLcckXS82LxIWRTL5BlkNXvoDGnKsTh9SZ7T
         /qb1jc/uIHFk3TGH4dLf1d/iAqs3nwS2GW0fzxnvMfS3LDa5EQI7+1JzL75/ThNAefjn
         UXVk2nJFevY59mLAceqx//u+usbpRtCULp4i1kIN6bnUNzETgnb9YSiSezdU2ttWZmYf
         poE57b6rKzasHtb7Z3wcjmDIR3ZArBzVwpOT+SdyJhkb8/L3wJiKrtlDIvliHOD4MwJO
         w+38OhQBrV5x3apRHXEWv/PXZtnWh9GuhkByFQaVdvSQatIImTwShEyAtmsJn73lwrKX
         Hm/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734632220; x=1735237020;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=r7rrd3s6trX0PM3fTY21ALz1gAXhr7UFRn3XH1zFrF0=;
        b=IV4HIkry0acxDqatB3rumlAp/Ih6SWbS36G/iVz20Z+TzO5uHJg4vxKLKKAts51HFy
         8aEbKnqnGMHqKsVENHohEceokCTMJzJfzrd+jhiojmt0o4GbH9wgUHOzALebMP9Lpa0e
         oDhjLE8RSZtXIMsEo2TPU2AvYekSrKpJIlISXZuvcDxM3BdgGbBpQ9+ykFbzzbBka1PT
         XSbnhYao5qQUdbc1UB3gjUxDY3AQYwsF6WMz4+YwosfaIw0aUeNk0L5qYObr5ZzPxnHl
         KAmcI+Ctajmhjtguses3+thd2SMjVRn7xMTwFECgYBUTZhsnbTAOKWNUBo6nXdSgTGVd
         oo1Q==
X-Gm-Message-State: AOJu0Yyzp67CnCCnynbomY0lI+Jom+KZ6sgS10CdPhz+/CuDt0A9IX5i
	Y1iXNi9IhmVhKXmGK7+o/TutQzq0Rm0q6pZc+ty3uaxj0GsPYa83fOS0+w==
X-Gm-Gg: ASbGncumK05103qsiWezt3DiQ0wkQiQ0+dgaXxpvbePrjwibcCW1azeaXG9LVYOv4Xc
	6u1K42mcPOHFw2kzMYfbdgLDP/bm9UUw2iFlVj1UG845YYxHnEYLJj2ejEC1PsHl6IK2xGif/DZ
	DRtK0UF/v2i3F7lekwGEe7BsP7Wr8mL5d5R7HSyUvQn09m8qobC1Sj+AwvDvSyA3UKrmbowiXce
	SPTuTeaNbcppnnO3jHITbpBdIYljh2MxHP55F4hi6dRZ5ZGYBZxbBegWZExVde3vtDEFI3N3Mvx
	5cF5NYJ4+RMrFFTUrChqci1PadO8+UtQtBh384Jvh4ibYYD7UgRFB/1m
X-Google-Smtp-Source: AGHT+IG6sGvgaupsPXBbHAqlSjnaWCcGO41VPto1cfnUSpDsBERruG5IodVRx03AcjtikwrKPSh/TA==
X-Received: by 2002:a05:6000:71b:b0:385:ea11:dd8f with SMTP id ffacd0b85a97d-38a221f780bmr34159f8f.7.1734632220360;
        Thu, 19 Dec 2024 10:17:00 -0800 (PST)
From: "=?UTF-8?q?Petr=20Bene=C5=A1?=" 
X-Google-Original-From: =?UTF-8?q?Petr=20Bene=C5=A1?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Petr=20Bene=C5=A1?= ,
	Tamas K Lengyel ,
	Alexandru Isaila ,
	Petre Pircalabu ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH 2/2] x86: Add Support for Paging-Write Feature
Date: Thu, 19 Dec 2024 18:16:52 +0000
Message-Id: <95580d02390056ea10eb80439f9d3ef9d2297ecc.1734631969.git.w1benny@gmail.com>
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Petr Beneš 

This patch introduces a new XENMEM_access_r_pw permission. Functionally, it is similar to XENMEM_access_r, but for processors with TERTIARY_EXEC_EPT_PAGING_WRITE support (Intel 12th Gen/Alder Lake and later), it also permits the CPU to write to the page during guest page-table walks (e.g., updating A/D bits) without triggering an EPT violation.

This behavior works by both enabling the EPT paging-write feature and setting the EPT paging-write flag in the EPT leaf entry.

This feature provides a significant performance boost for introspection tools that monitor guest page-table updates. Previously, every page-table modification by the guest—including routine updates like setting A/D bits—triggered an EPT violation, adding unnecessary overhead. The new XENMEM_access_r_pw permission allows these "uninteresting" updates to occur without EPT violations, improving efficiency.

Additionally, this feature simplifies the handling of race conditions in scenarios where an introspection tool:

- Sets an "invisible breakpoint" in the altp2m view for a function F
- Monitors guest page-table updates to track whether the page containing F is paged out
- Encounters a cleared Access (A) bit on the page containing F while the guest is about to execute the breakpoint

In the current implementation:

- If xc_monitor_inguest_pagefault() is enabled, the introspection tool must emulate both the breakpoint and the setting of the Access bit.
- If xc_monitor_inguest_pagefault() is disabled, Xen handles the EPT violation without notifying the introspection tool, setting the Access bit and emulating the instruction. However, Xen fetches the instruction from the default view instead of the altp2m view, potentially causing the breakpoint to be missed.

With this patch, setting XENMEM_access_r_pw for monitored guest page-tables prevents EPT violations in these cases. This change enhances performance and reduces complexity for introspection tools, ensuring seamless breakpoint handling while tracking guest page-table updates.
---
 xen/arch/arm/mem_access.c               | 4 ++++
 xen/arch/arm/mmu/p2m.c                  | 1 +
 xen/arch/x86/hvm/hvm.c                  | 1 +
 xen/arch/x86/hvm/monitor.c              | 1 +
 xen/arch/x86/hvm/vmx/vmcs.c             | 4 +++-
 xen/arch/x86/include/asm/hvm/vmx/vmcs.h | 3 +++
 xen/arch/x86/include/asm/p2m.h          | 1 +
 xen/arch/x86/mm/hap/nested_hap.c        | 3 +++
 xen/arch/x86/mm/mem_access.c            | 3 +++
 xen/arch/x86/mm/p2m-ept.c               | 4 ++++
 xen/include/public/memory.h             | 9 +++++++++
 xen/include/xen/mem_access.h            | 6 ++++++
 12 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
index 0ec3462364..2af92bb402 100644
--- a/xen/arch/arm/mem_access.c
+++ b/xen/arch/arm/mem_access.c
@@ -32,6 +32,7 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
             ACCESS(rwx),
             ACCESS(rx2rw),
             ACCESS(n2rwx),
+            ACCESS(r_pw),
 #undef ACCESS
     };
 
@@ -172,6 +173,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned long flag,
             break;
         else
             goto err;
+    case XENMEM_access_r_pw:
     case XENMEM_access_rx2rw:
     case XENMEM_access_rx:
     case XENMEM_access_r:
@@ -253,6 +255,7 @@ bool p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct npfec npfec)
         violation = npfec.read_access || npfec.insn_fetch;
         break;
     case XENMEM_access_r:
+    case XENMEM_access_r_pw:
         violation = npfec.write_access || npfec.insn_fetch;
         break;
     default:
@@ -361,6 +364,7 @@ long p2m_set_mem_access(struct domain *d, gfn_t gfn, uint32_t nr,
         ACCESS(rwx),
         ACCESS(rx2rw),
         ACCESS(n2rwx),
+        ACCESS(r_pw),
 #undef ACCESS
     };
 
diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c
index 28df6e5d03..7642dbc7c5 100644
--- a/xen/arch/arm/mmu/p2m.c
+++ b/xen/arch/arm/mmu/p2m.c
@@ -597,6 +597,7 @@ static void p2m_set_permission(lpae_t *e, p2m_type_t t, p2m_access_t a)
         e->p2m.read = 0;
         break;
     case p2m_access_r:
+    case p2m_access_r_pw:
         e->p2m.write = 0;
         e->p2m.xn = 1;
         break;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 74e58c653e..495c8290ca 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1897,6 +1897,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
             violation = npfec.read_access || npfec.write_access || npfec.insn_fetch;
             break;
         case p2m_access_r:
+        case p2m_access_r_pw:
             violation = npfec.write_access || npfec.insn_fetch;
             break;
         case p2m_access_w:
diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index 74621000b2..523586ca98 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -295,6 +295,7 @@ bool hvm_monitor_check_p2m(unsigned long gla, gfn_t gfn, uint32_t pfec,
 
     case XENMEM_access_r:
     case XENMEM_access_n:
+    case XENMEM_access_r_pw:
         if ( pfec & PFEC_write_access )
             req.u.mem_access.flags |= MEM_ACCESS_R | MEM_ACCESS_W;
         if ( pfec & PFEC_insn_fetch )
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 147e998371..8c0ea789c1 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -203,6 +203,7 @@ static void __init vmx_display_features(void)
     P(cpu_has_vmx_bus_lock_detection, "Bus Lock Detection");
     P(cpu_has_vmx_notify_vm_exiting, "Notify VM Exit");
     P(cpu_has_vmx_virt_spec_ctrl, "Virtualize SPEC_CTRL");
+    P(cpu_has_vmx_ept_paging_write, "EPT Paging-Write");
 #undef P
 
     if ( !printed )
@@ -366,7 +367,8 @@ static int vmx_init_vmcs_config(bool bsp)
 
     if ( _vmx_cpu_based_exec_control & CPU_BASED_ACTIVATE_TERTIARY_CONTROLS )
     {
-        uint64_t opt = TERTIARY_EXEC_VIRT_SPEC_CTRL;
+        uint64_t opt = (TERTIARY_EXEC_VIRT_SPEC_CTRL |
+                        TERTIARY_EXEC_EPT_PAGING_WRITE);
 
         _vmx_tertiary_exec_control = adjust_vmx_controls2(
             "Tertiary Exec Control", 0, opt,
diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
index 939b87eb50..e1d3398141 100644
--- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
@@ -273,6 +273,9 @@ extern uint64_t vmx_tertiary_exec_control;
 #define cpu_has_vmx_virt_spec_ctrl \
      (vmx_tertiary_exec_control & TERTIARY_EXEC_VIRT_SPEC_CTRL)
 
+#define cpu_has_vmx_ept_paging_write \
+     (vmx_tertiary_exec_control & TERTIARY_EXEC_EPT_PAGING_WRITE)
+
 #define VMX_EPT_EXEC_ONLY_SUPPORTED                         0x00000001
 #define VMX_EPT_WALK_LENGTH_4_SUPPORTED                     0x00000040
 #define VMX_EPT_MEMORY_TYPE_UC                              0x00000100
diff --git a/xen/arch/x86/include/asm/p2m.h b/xen/arch/x86/include/asm/p2m.h
index e6de37f108..aa1bf7c9d0 100644
--- a/xen/arch/x86/include/asm/p2m.h
+++ b/xen/arch/x86/include/asm/p2m.h
@@ -980,6 +980,7 @@ static inline unsigned int p2m_access_to_iommu_flags(p2m_access_t p2ma)
     case p2m_access_r:
     case p2m_access_rx:
     case p2m_access_rx2rw:
+    case p2m_access_r_pw:
         return IOMMUF_readable;
 
     case p2m_access_w:
diff --git a/xen/arch/x86/mm/hap/nested_hap.c b/xen/arch/x86/mm/hap/nested_hap.c
index cc7bc6e5ea..255fba7e1c 100644
--- a/xen/arch/x86/mm/hap/nested_hap.c
+++ b/xen/arch/x86/mm/hap/nested_hap.c
@@ -213,6 +213,9 @@ int nestedhvm_hap_nested_page_fault(
     case p2m_access_n2rwx:
         p2ma_10 = p2m_access_n;
         break;
+    case p2m_access_r_pw:
+        p2ma_10 = p2m_access_r;
+        break;
     default:
         p2ma_10 = p2m_access_n;
         /* For safety, remove all permissions. */
diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index 60a0cce68a..21b5b7ecda 100644
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -45,6 +45,7 @@ static int _p2m_get_mem_access(struct p2m_domain *p2m, gfn_t gfn,
             ACCESS(rwx),
             ACCESS(rx2rw),
             ACCESS(n2rwx),
+            ACCESS(r_pw),
 #undef ACCESS
     };
 
@@ -94,6 +95,7 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
             break;
 
         case XENMEM_access_r:
+        case XENMEM_access_r_pw:
             violation = data->flags & MEM_ACCESS_WX;
             break;
 
@@ -312,6 +314,7 @@ bool xenmem_access_to_p2m_access(const struct p2m_domain *p2m,
         ACCESS(rwx),
         ACCESS(rx2rw),
         ACCESS(n2rwx),
+        ACCESS(r_pw),
 #undef ACCESS
     };
 
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 21728397f9..5ad78ae4b5 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -176,6 +176,10 @@ static void ept_p2m_type_to_flags(const struct p2m_domain *p2m,
             break;           
         case p2m_access_rwx:
             break;
+        case p2m_access_r_pw:
+            entry->w = entry->x = 0;
+            entry->pw = !!cpu_has_vmx_ept_paging_write;
+            break;
     }
     
     /*
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 5e545ae9a4..bd9fc37b52 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -426,6 +426,15 @@ typedef enum {
      * pausing the vcpu
      */
     XENMEM_access_n2rwx,
+
+    /*
+     * Same as XENMEM_access_r, but on processors with
+     * the TERTIARY_EXEC_EPT_PAGING_WRITE support,
+     * CPU-initiated page-table walks can still
+     * write to it (e.g., update A/D bits)
+     */
+    XENMEM_access_r_pw,
+
     /* Take the domain default */
     XENMEM_access_default
 } xenmem_access_t;
diff --git a/xen/include/xen/mem_access.h b/xen/include/xen/mem_access.h
index 87d93b31f6..2231341b5d 100644
--- a/xen/include/xen/mem_access.h
+++ b/xen/include/xen/mem_access.h
@@ -64,6 +64,12 @@ typedef enum {
                            * generates an event but does not pause the
                            * vcpu */
 
+    p2m_access_r_pw = 10, /* Special: same as R, but on processors with
+                           * the TERTIARY_EXEC_EPT_PAGING_WRITE support,
+                           * CPU-initiated page-table walks can still
+                           * write to it (e.g., update A/D bits)
+                           */
+
     /* NOTE: Assumed to be only 4 bits right now on x86. */
 } p2m_access_t;
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 18:23:59 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 18:23:59 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861464.1273409 (Exim 4.92)
	(envelope-from )
	id 1tOLBh-0002FE-WC; Thu, 19 Dec 2024 18:23:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861464.1273409; Thu, 19 Dec 2024 18:23: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 1tOLBh-0002F7-SF; Thu, 19 Dec 2024 18:23:53 +0000
Received: by outflank-mailman (input) for mailman id 861464;
 Thu, 19 Dec 2024 18:23: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 1tOLBg-0002F1-RZ
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 18:23:52 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 65ba395a-be36-11ef-a0d8-8be0dac302b0;
 Thu, 19 Dec 2024 19:23:52 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 19 Dec 2024 19:23:51 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 65ba395a-be36-11ef-a0d8-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734632632; x=1766168632;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=0MMCRQQgQP0hcUZdIoSvKURLWTborcRPf60ZUkozNo4=;
  b=RaqRRgWMSbXa/Z7vMZgkkzcu0D6Fh96PTfrqumyCPThVkfLHMAoTLUEv
   5WRz5L5jZvLtu0aWaiYZbAb6F5I6a2an+Qs5OPHJP2TeRhKoAaQJirfQu
   FH7bPK2L0aVTT7ht+r/KdLJ24etg+eZkysp1eH5SPDm32MsFTDvUsB4hR
   o=;
X-CSE-ConnectionGUID: Qrt+G3QqTWe3Bg/aDeuLdg==
X-CSE-MsgGUID: dEr/JcmFRwm6jI5f44ETEQ==
X-IronPort-AV: E=Sophos;i="6.12,248,1728943200"; 
   d="scan'208";a="28260046"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: <20241219181352.709315-2-Ariel.Otilibili-Anieli@eurecom.fr>
Content-Type: text/plain; charset="utf-8"
X-Forward: 88.183.119.157
References: <20241219181352.709315-1-Ariel.Otilibili-Anieli@eurecom.fr> <20241219181352.709315-2-Ariel.Otilibili-Anieli@eurecom.fr>
Date: Thu, 19 Dec 2024 19:23:51 +0100
Cc: xen-devel@lists.xenproject.org, "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Jan Beulich" , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Stefano Stabellini" , "Luca Fancellu" 
To: "Ariel Otilibili" 
MIME-Version: 1.0
Message-ID: <2f7a83-67646480-a2b5-5cf12280@53972861>
Subject: =?utf-8?q?Re=3A?= [PATCH 1/1] =?utf-8?q?xen/scripts=3A?= Fix regex syntax 
 warnings with Python =?utf-8?q?3=2E12?=
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 2158

CCing Luca Fancellu.

On Thursday, December 19, 2024 19:10 CET, Ariel Otilibili  wrote:

> Same fix than commit 826a9eb072 (tools: Fix regex syntax warnings wit=
h Python 3.12).
>=20
> It clears out the warning:
>=20
> ```
> $ xen/scripts/xen-analysis.py
> xen/scripts/xen=5Fanalysis/cppcheck=5Fanalysis.py:94: SyntaxWarning: =
invalid escape sequence '\*'
>   comment=5Fline=5Fstarts =3D re.match('^[ \t]*/\*.*$', line)
> ```
>=20
> The  warning appears only the first time the command is run, then it =
disappears.
>=20
> Fixes: 02b26c02c7 (xen/scripts: add cppcheck tool to the xen-analysis=
.py script)
> Signed-off-by: Ariel Otilibili 
> --
> Cc: Andrew Cooper 
> Cc: Anthony PERARD 
> Cc: Michal Orzel 
> Cc: Jan Beulich 
> Cc: Julien Grall 
> Cc: "Roger Pau Monn=C3=A9" 
> Cc: Stefano Stabellini 
> ---
>  xen/scripts/xen=5Fanalysis/cppcheck=5Fanalysis.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>=20
> diff --git a/xen/scripts/xen=5Fanalysis/cppcheck=5Fanalysis.py b/xen/=
scripts/xen=5Fanalysis/cppcheck=5Fanalysis.py
> index ce7bda91b6..532a14b0ad 100644
> --- a/xen/scripts/xen=5Fanalysis/cppcheck=5Fanalysis.py
> +++ b/xen/scripts/xen=5Fanalysis/cppcheck=5Fanalysis.py
> @@ -91,7 +91,7 @@ def =5F=5Fgenerate=5Fsuppression=5Flist(out=5Ffile)=
:
>                          line =3D header=5Fcontent[tmp=5Fline]
>                          # Matches a line with just optional spaces/t=
abs and the
>                          # start of a comment '/*'
> -                        comment=5Fline=5Fstarts =3D re.match('^[ \t]=
*/\*.*$', line)
> +                        comment=5Fline=5Fstarts =3D re.match(r'^[ \t=
]*/\*.*$', line)
>                          # Matches a line with text and the end of a =
comment '*/'
>                          comment=5Fline=5Fstops =3D re.match(r'^.*\*/=
$', line)
>                          if (not comment=5Fsection) and comment=5Flin=
e=5Fstarts:
> --=20
> 2.47.1
>



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 22:32:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 22:32:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861497.1273467 (Exim 4.92)
	(envelope-from )
	id 1tOP4K-0005cj-D3; Thu, 19 Dec 2024 22:32:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861497.1273467; Thu, 19 Dec 2024 22:32: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 1tOP4K-0005cc-9u; Thu, 19 Dec 2024 22:32:32 +0000
Received: by outflank-mailman (input) for mailman id 861497;
 Thu, 19 Dec 2024 22:32: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 1tOP4J-0005cW-0T
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 22:32:31 +0000
Received: from NAM11-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam11on20601.outbound.protection.outlook.com
 [2a01:111:f403:2414::601])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 20282f73-be59-11ef-a0d8-8be0dac302b0;
 Thu, 19 Dec 2024 23:32:28 +0100 (CET)
Received: from CH0P221CA0044.NAMP221.PROD.OUTLOOK.COM (2603:10b6:610:11d::27)
 by CH3PR12MB8935.namprd12.prod.outlook.com (2603:10b6:610:169::17)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.14; Thu, 19 Dec
 2024 22:32:22 +0000
Received: from CH3PEPF0000000E.namprd04.prod.outlook.com
 (2603:10b6:610:11d:cafe::80) by CH0P221CA0044.outlook.office365.com
 (2603:10b6:610:11d::27) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.24 via Frontend Transport; Thu,
 19 Dec 2024 22:32:22 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CH3PEPF0000000E.mail.protection.outlook.com (10.167.244.42) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Thu, 19 Dec 2024 22:32:21 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) 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; Thu, 19 Dec
 2024 16:32:21 -0600
Received: from amd-BIRMANPLUS.mshome.net (10.180.168.240) by
 SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39
 via Frontend Transport; Thu, 19 Dec 2024 16:32:20 -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: 20282f73-be59-11ef-a0d8-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WxSEgbKs4HyUnK5Ug4Pctyy2ghD6L4HJxntrHraZQJCy3gkWuUbIG9lzzDRxpg+pmck74kW3ZF3oBSxCuAdx9paiRkAAZM2oIC0IHpejf7pRBCkJ9MSs4WGAj0KIoYuPjiTfg3sWbj44WQxMdJPlsMDA4dXpzcw5iX/5nR6wfYh2ULoKc506D6nifE4LhmQTmrBiJM5PE26+cVX0GmNS+ssjNylZ4DiaoKgPoXtUX3ldYqd5GSbXUxJDq4HNNM3pDY66NAbACrAqrwOL7BmoiA2wxUPjCHouNHPci7eBl9t9dJb/JsC38RtS/QV1Jdbje9CckmOuuiaLDPmNnWGDzA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Wa60DCOikA3QB2mlRsATu5N4pHRCgyKw8HMeXV1f3as=;
 b=ihk1fzJxADw4l1X1WYXm7WADc+chnYP2cftXRg1ysOZNOZsHws4hpuOUjt3PRemQfkpsRkLA7NHc+rgjfsJLSGpCWr1p/drUmAweDXwTsL16iOR/uEF0qZ/Lg7BVPLVUibBje7VQofvctfWnOmfAqW5wVqm3dYilj8xiIz2E+NQctfyrXvFEUdGAf0ncuTOw1VG2tN4DukxPD45OWqtHWo9gIJva+15TgevsDt/vzSu8ur5eF4Y21IQ4WHaFpibtfPRTFSGY2uAUCsWN5hVRPL9QtbtSNOGT+p9UFUZLicLYr9JsY/JkWivrhQMIxWy0mQ9vv60qkUItz/Gyf8/yqA==
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=Wa60DCOikA3QB2mlRsATu5N4pHRCgyKw8HMeXV1f3as=;
 b=MbwnLdwaiGwawE6CVvuR8CC3gBUOKA8akvGtUknUHFQ9WleRg1KqkFF6ih/E4yAGL2LNncA1Zb5L7+3V/ITRHZAvMVoWshtZj9FMmTktDJLzupU9go7oIatZkBrg8+d219ZP0Rko9LvZLh5Xd8crA09fvx0B0K8u2f/56ybQU1Y=
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=SATLEXMB04.amd.com; pr=C
From: Jason Andryuk 
To: 
CC: Jason Andryuk , Anthony PERARD
	, Juergen Gross 
Subject: [RFC PATCH Hyperlaunch v2] xenconsole: Add connected flag
Date: Thu, 19 Dec 2024 17:32:22 -0500
Message-ID: <20241219223222.2211-1-jason.andryuk@amd.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PEPF0000000E:EE_|CH3PR12MB8935:EE_
X-MS-Office365-Filtering-Correlation-Id: e49d25d3-2906-4ec9-ceaf-08dd207d0124
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|36860700013|82310400026|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?kURVRQdQh6e+3ir9myjcOTEFayYV1Biqpg7phNqFbTvBz/GpCU5JXvXviE4Y?=
 =?us-ascii?Q?qq2DZ3x4u/WYIrm9T7ES2ZekNpkGy8alY8R9W5i/K4rzbv20iKmh4AWkYRqI?=
 =?us-ascii?Q?NEfYO5iusv3PeJkSXxsa80g8/ejPykoFyyiBE1dtUymqnM2toKnSeXHMRfiv?=
 =?us-ascii?Q?HTnLTq+SQdVMrTDgnWkenhCTqyI8p3fj6mZrMCDdodNRZEc4oKxf70m6Y5cG?=
 =?us-ascii?Q?MNDPl4N+3OPaLzvi4f4XV7trx2g/htKvoxlKwsQtBCQv7wjlxezfyM4rix7s?=
 =?us-ascii?Q?JpIdfhOeHzmLPTtK8jaftBmrd9nIk2K/lnkJTg/lcNoJj9VhUymuTBCx73Ki?=
 =?us-ascii?Q?PMYOihKlXs+KrLybjaBPTfulbtKhr36r9gNUaimDxtKDIwXFrKGo5GKs1aLP?=
 =?us-ascii?Q?BBymGnjLwzhqx9txoQRJL1EWcaVbWnEs7GjQXtnrrDBIt9FJHGtWa00JhQpQ?=
 =?us-ascii?Q?p+kT+U8b3vQ1gm2ItXBxoxxiCovvlLuZOtmxJwOqMG5xaSxNdwxz82jU9TLj?=
 =?us-ascii?Q?h5lqHnUMimVBTbGUU2LR6mcsi1UpwNYhybu34K81dh+EVjKw4PAwe7zeMkj9?=
 =?us-ascii?Q?n6G+xKB/79mTANspPMG7LzhZfJBOO3VdfyxRtE057HBeMIBvqu6IBQKrICC4?=
 =?us-ascii?Q?RYswOdrmisxyufiSztYMU/8AXICceTupgUusGqAocF+WiEYgC3ZlBvekm0IU?=
 =?us-ascii?Q?C/bPgMl7sENSg5fdNtXKeEiB/SYSsO9FKMoc7gM6OU9574qKlcr3aP6q+dk8?=
 =?us-ascii?Q?JV9Xs5CEyS9ONNQpE9zDPsYxTgK0U0xT4yTgZ/2lRDrWqVKgvKVxClVX2XJB?=
 =?us-ascii?Q?tbMJ0q8tRRg1QuEJBCCPXBq7cmBPUlw9mvE9HHS+gGzLN8u9nXD1LCe+HNo5?=
 =?us-ascii?Q?hNtWiiFtkqbvxDUHKP2OChObx36ZkzFHWAFwrV8M9qGn1lzTyJwqTUIyfqjn?=
 =?us-ascii?Q?/tYmYLU9fT6721232L+NsUerSqjH2g6aTBsUvEYBpj0u6xFv3eJmxipcDCFh?=
 =?us-ascii?Q?kbBo+X1eEV8Po5oKIYfUABBl5mKt6yA00FWSJtH3jk7P9Wa6BaAjC19NKq1+?=
 =?us-ascii?Q?RoqPVh1dwTjw8WhQw6knKs+wRwnR+P07busvAG6V+yO5FjXCTumUyUattKI9?=
 =?us-ascii?Q?gccl+T/m8XCgSv0eNTaCyqjef9vmNzXE7qg6eQZGu4DmSYZQHo+dukrVc66V?=
 =?us-ascii?Q?YG6Wm8vS0BsWEeX6ZjDRsEAP4SWgdYahS+lpTHrg8Hmgu9wmRuYNN3ve7HCG?=
 =?us-ascii?Q?fFvIFFs8sGlvXB8W32r+4d6Gx9QPmPfgSVNPATkr+EXnfBk6kREbgHF7djM5?=
 =?us-ascii?Q?QnLcTVZ0heqjgn9FBVQbM615Y8+eZML4cMOb6rtuYRmHby4SDGJO/bF/ZAI4?=
 =?us-ascii?Q?GiYFzhgUAZmeFGpcwkrnCMS+yYuzZGc+3iJ8b7SW8kYmK23BT2AT1b4GdDGN?=
 =?us-ascii?Q?1GM6cwQ42En2r8CgiHCkUr+7keyaGeOjbSmIpFYMnnHQ2hF6cN1H5SKCJ5hH?=
 =?us-ascii?Q?cZ1uIeRoNsZny6c=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2024 22:32:21.7887
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e49d25d3-2906-4ec9-ceaf-08dd207d0124
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH3PEPF0000000E.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8935

Sending again with an expanded description.  RFC to have a discussion
about the approach.

With hyperlaunch, a domU can start before its console ring is connected
by xenconsoled.  With nothing emptying the ring, it can quickly fill
during boot.  In domU_write_console(), __write_console returns 0 when
the ring is full.  This loops spins until xenconsoled starts emptying
the ring:

        while (len) {
                ssize_t sent = __write_console(cons, data, len);

                if (sent < 0)
                        return sent;

                data += sent;
                len -= sent;

                if (unlikely(len))
                        HYPERVISOR_sched_op(SCHEDOP_yield, NULL);
        }

The goal of this patch is to add a way for the frontend to know when a
console is connected.  This patch adds a new flag to the end of the
console ring structure.  It is used for the backend to indicate that it
has connected and started servicing the page.  The initial value is
XENCONSOLE_DISCONNECTED (0), which matches a zero-initialized page
value.  XENCONSOLE_DISCONNECTED indicates to the guest that ring is
disconnected, so it will not be serviced.

Once the backend (xenconsoled) maps and starts servicing the
console, the flag will be set to XENCONSOLE_CONNECTED (1) to indicate
the backend state to the frontend.

A domU can use console hypercalls and only transition to the ring when
it is connected and won't fill and block.

With the flag change, the backend sends an event channel notification so
the frontend can check the state.  Though this is not strictly
necessary.

Signed-off-by: Jason Andryuk 
---
This patch is similar to the xenstore late init in that it indicates
whether the backend is usable.  This patch is not changing existing
meaning of flags.

This does assume that existing frontends are not using the flag space
for some other use.  Also, it assumes zero-initialized memory for the
page used by xencons_interface structure.  Or at least the 32bit flag
value being not XENCONSOLE_CONNECTED.  However, this only matters for a
hyperlaunched guest - xenconsoled will normally readily connect the
console and set the value.

Disconnecting and reconnecting would not be supported.  I don't think
that is supported today, but I could be wrong.  Does soft_reset
disconnect and reconnect, or does xenconsoled maintain the connection?
The backend could set the flag to DISCONNECTED before unmapping on
garceful disconnect.  A crash would not be handled.

The idea of the event channel notification is to let the domU receive an
indication that xenconsoled is connected.  For xenstore, the xenstore
driver owns the event channel/irq and can rebind it.  For hvc_xen, the
hvc subsystem owns the irq, so it isn't readily available for rebinding.

I had the idea for the kernel to use a static key and switch writing
from the hypercall to the PV ring once connected.  It didn't actually
work in my short attempt - I think changing the static key from within
an interupt was wrong.  I fell back to just checking the flag directly
without an optimization.  That would work and would make the event
channel notification unnecessary.
---
 tools/console/daemon/io.c       |  6 ++++++
 xen/include/public/io/console.h | 13 +++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index bb739bdb8c..2a7ecc6369 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -731,6 +731,9 @@ static int console_create_ring(struct console *con)
 		con->ring_ref = ring_ref;
 	}
 
+	/* Mark the console as connected. */
+	con->interface->flag = XENCONSOLE_CONNECTED;
+
 	/* Go no further if port has not changed and we are still bound. */
 	if (remote_port == con->remote_port) {
 		xc_evtchn_status_t status = {
@@ -780,6 +783,9 @@ static int console_create_ring(struct console *con)
 	if (log_guest && (con->log_fd == -1))
 		con->log_fd = create_console_log(con);
 
+	/* Notify to check flags field. */
+	xenevtchn_notify(con->xce_handle, con->local_port);
+
  out:
 	return err;
 }
diff --git a/xen/include/public/io/console.h b/xen/include/public/io/console.h
index 4509b4b689..d847aa080f 100644
--- a/xen/include/public/io/console.h
+++ b/xen/include/public/io/console.h
@@ -19,6 +19,19 @@ struct xencons_interface {
     char out[2048];
     XENCONS_RING_IDX in_cons, in_prod;
     XENCONS_RING_IDX out_cons, out_prod;
+/*
+ * Flag values signaling from backend to frontend whether the console is
+ * connected.  i.e. Whether it will be serviced and emptied.
+ *
+ * The flag starts as disconnected.
+ */
+#define XENCONSOLE_DISCONNECTED 0
+/*
+ * The flag is set to connected when the backend connects and the console
+ * will be serviced.
+ */
+#define XENCONSOLE_CONNECTED    1
+    uint32_t flag;
 };
 
 #ifdef XEN_WANT_FLEX_CONSOLE_RING
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 22:47:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 22:47:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861510.1273477 (Exim 4.92)
	(envelope-from )
	id 1tOPIZ-0007QP-MZ; Thu, 19 Dec 2024 22:47:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861510.1273477; Thu, 19 Dec 2024 22:47: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 1tOPIZ-0007QI-IL; Thu, 19 Dec 2024 22:47:15 +0000
Received: by outflank-mailman (input) for mailman id 861510;
 Thu, 19 Dec 2024 22:47: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 1tOPIY-0007QC-22
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 22:47:14 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 2f011f5c-be5b-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 23:47:11 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 19 Dec 2024 23:47:10 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id 407792397;
 Thu, 19 Dec 2024 23:47:10 +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: 2f011f5c-be5b-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734648431; x=1766184431;
  h=from:to:cc:subject:date:message-id:in-reply-to:
   references:mime-version:content-transfer-encoding;
  bh=twcOgW39ORCy6kaIQzutC0BWyK65sKKIGGvefmUpGtk=;
  b=V6u9HNUVPLEbp60jfAA1N/ittrGnq3281VqNAwcTPB/QIcYmwRH1aBDO
   OVAfptc213torSwb6iAplWXxY/mB/T6fJvgP3wO72mV0FVzNFK/HahIOU
   3metn7VYxTXrGKhS72tGADHTpL+HrZ0KJsbYK3AX+l1jA8Q5lzkWtiv68
   E=;
X-CSE-ConnectionGUID: MVYnHboYSxmeIGDqDZlqVA==
X-CSE-MsgGUID: 3M+NuwlYT6WjxfuyxFg5LA==
X-IronPort-AV: E=Sophos;i="6.12,248,1728943200"; 
   d="scan'208";a="28263085"
From: Ariel Otilibili 
To: linux-kernel@vger.kernel.org
Cc: Ariel Otilibili ,
	stable@vger.kernel.org,
	Andrew Morton ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?utf-8?q?Roger_Pau_Monn=C3=A9?= ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 0/1] lib: Remove dead code
Date: Thu, 19 Dec 2024 23:45:00 +0100
Message-ID: <20241219224645.749233-1-ariel.otilibili-anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20241219092615.644642-1-ariel.otilibili-anieli@eurecom.fr>
References: <20241219092615.644642-1-ariel.otilibili-anieli@eurecom.fr>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hello,

This patch removes a dead code in lib/inflate.c; it follows from a discussion
in Xen.

The dead code is tracked by Coverity-ID 1055253 in Xen, was triggered by a file
taken unmodified from Linux.

Thank you,

Link: https://lore.kernel.org/all/7587b503-b2ca-4476-8dc9-e9683d4ca5f0@suse.com/
--
v2:
* Cc stable

Ariel Otilibili (1):
  lib: Remove dead code

 lib/inflate.c | 2 --
 1 file changed, 2 deletions(-)

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 22:47:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 22:47:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861511.1273486 (Exim 4.92)
	(envelope-from )
	id 1tOPIb-0007f0-Sm; Thu, 19 Dec 2024 22:47:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861511.1273486; Thu, 19 Dec 2024 22:47: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 1tOPIb-0007et-QC; Thu, 19 Dec 2024 22:47:17 +0000
Received: by outflank-mailman (input) for mailman id 861511;
 Thu, 19 Dec 2024 22:47: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 1tOPIa-0007QC-U0
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 22:47:16 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 317a875e-be5b-11ef-99a3-01e77a169b0f;
 Thu, 19 Dec 2024 23:47:15 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 19 Dec 2024 23:47:15 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id C93A12398;
 Thu, 19 Dec 2024 23:47:14 +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: 317a875e-be5b-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734648435; x=1766184435;
  h=from:to:cc:subject:date:message-id:in-reply-to:
   references:mime-version:content-transfer-encoding;
  bh=V8sVQh2GzpjQPMrZ4BpJcSrIaxPFuHtvHMLSHRGfOx4=;
  b=lKeNSTDbklN+wt7z+1X1p0KSPxWiQQ0znsVtDNe/MV1TPhopYAtGw1Q5
   VlnFmm17EVRujatLXjr+iX9fSQTynTg+LcMr/MASkftNUNj6XHInP2Nky
   sw3KmHlEmVFv4VgoqIf0Zh8kM3n4S6KXvV4+fhmphu/lyWJ22b4sseEDm
   g=;
X-CSE-ConnectionGUID: tVhKrNPLRYGLnSmy3ws9Xw==
X-CSE-MsgGUID: oAtabZZKTP+dUb54DWNQuA==
X-IronPort-AV: E=Sophos;i="6.12,248,1728943200"; 
   d="scan'208";a="28263088"
From: Ariel Otilibili 
To: linux-kernel@vger.kernel.org
Cc: Ariel Otilibili ,
	Jan Beulich ,
	stable@vger.kernel.org,
	Andrew Morton ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	=?utf-8?q?Roger_Pau_Monn=C3=A9?= ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: [PATCH v2 1/1] lib: Remove dead code
Date: Thu, 19 Dec 2024 23:45:01 +0100
Message-ID: <20241219224645.749233-2-ariel.otilibili-anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20241219224645.749233-1-ariel.otilibili-anieli@eurecom.fr>
References: <20241219092615.644642-1-ariel.otilibili-anieli@eurecom.fr>
 <20241219224645.749233-1-ariel.otilibili-anieli@eurecom.fr>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This is a follow up from a discussion in Xen:

The if-statement tests `res` is non-zero; meaning the case zero is never reached.

Link: https://lore.kernel.org/all/7587b503-b2ca-4476-8dc9-e9683d4ca5f0@suse.com/
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Suggested-by: Jan Beulich 
Signed-off-by: Ariel Otilibili 
--
Cc: stable@vger.kernel.org
Cc: Andrew Morton 
Cc: linux-kernel@vger.kernel.org
Cc: Andrew Cooper 
Cc: Anthony PERARD 
Cc: Michal Orzel 
Cc: Julien Grall 
Cc: =?utf-8?q?Roger_Pau_Monn=C3=A9?= 
Cc: Stefano Stabellini 
Cc: xen-devel@lists.xenproject.org
---
 lib/inflate.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/lib/inflate.c b/lib/inflate.c
index fbaf03c1748d..eab886baa1b4 100644
--- a/lib/inflate.c
+++ b/lib/inflate.c
@@ -1257,8 +1257,6 @@ static int INIT gunzip(void)
     /* Decompress */
     if ((res = inflate())) {
 	    switch (res) {
-	    case 0:
-		    break;
 	    case 1:
 		    error("invalid compressed format (err=1)");
 		    break;
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 23:31:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 23:31:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861531.1273497 (Exim 4.92)
	(envelope-from )
	id 1tOPz3-00066k-3f; Thu, 19 Dec 2024 23:31:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861531.1273497; Thu, 19 Dec 2024 23: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 1tOPz3-00066d-0u; Thu, 19 Dec 2024 23:31:09 +0000
Received: by outflank-mailman (input) for mailman id 861531;
 Thu, 19 Dec 2024 23: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 1tOPz1-00066X-97
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 23:31:07 +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 512cccbb-be61-11ef-a0d8-8be0dac302b0;
 Fri, 20 Dec 2024 00:31:05 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-4361f664af5so14869765e9.1
 for ; Thu, 19 Dec 2024 15:31:05 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4364b0532a6sm90498725e9.1.2024.12.19.15.31.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Dec 2024 15:31: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: 512cccbb-be61-11ef-a0d8-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734651065; x=1735255865; 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=uJ8bJilLUMHhGPiQmNgfzkalz0eG45Ag+CdTIDcQU2U=;
        b=ScQ0rc2wC5UoHHy27YE20uwX3mNDGi7aVR/drJYmgB1Gflq6KVpyD4FM+93H9/uB/T
         8+/7GpBUXO6xcYX8cLxuvoMgyehXNMmLFSmY/4oFmjQ/xdmTgIX+8Qnnh0WnZKOThXkB
         MtRJ/MNloCvYk0gQDgVPm4QVdSyph+3aXNxqo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734651065; x=1735255865;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=uJ8bJilLUMHhGPiQmNgfzkalz0eG45Ag+CdTIDcQU2U=;
        b=VyBLt6bD7rHN/IRneprO9Tv31FOfhOCPPFPqHdFhx5zDn3VREdrlNdoyofxPtxvLO0
         dqH6gROPpYFEXZXKp8HRQTHWXGCZ85j/jV6MkbqKiYqy+XXCnPUnUQf8VziUvts429vC
         wYSj6vQvJZ/OcazMMeXQETYgm2pjurpMGLQwW5R73w1oRd4d4m7K5qXI1PYBLoStlNu5
         y3PUiue4r1tmfPnRhq3QaGJeHqMypYdr8DFo3xtxY02meJ+U7roBlQ1oayBAjajfWbqm
         Ah69FTHYiiJzEff8CpBP3NghFC1moHogZgI48M+BEhMfXi7IeSdn9IKiI7lkGv69ZpIa
         kJZA==
X-Forwarded-Encrypted: i=1; AJvYcCVHwicFv11Dn6Jms2EXYEgg0O+nCstFi4ggrMZkWPfGGuJoXuUX1LmWLEqq64wj6Jng99mgjIdGHVw=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw55SNr4DrYfQ4/qHGuUoDyIoSbS5x0k5snQmvX8G3tUmepHPS8
	or8YR1YjpUFxZTs0xq43//j+d0OA0E/egnsAaDSwz2Oxf3sLszqvc4x9aXTtSC0=
X-Gm-Gg: ASbGncskqjXY8Gcalj770gsxca3UgJ/QNTlR+KKDLaQ+D0fYSUrJyM7fz01gxVFiQpc
	pif/yW2C3/j+wJd31c1B/KH8M9V/BHvE4N+bc0K4cY4WmtaJ6nnZWjFtUcofnBdUMVT1YRnjsnU
	iQcwXYIo8CpNRTX7myQA62Zi3lq+C85ek3TWDyQgWAxC9+KmzK60sTzMNVJEXmfvKwe4bZB1UqG
	gwzzGvij+eYgtVaVk/xuKd0N92hn9eBvb2uxBqwY3cSZBsGOsZqkUsA+zpydJHdd+392SFmLqk9
	AUu+7cHXDHDeuIQ+6JgQ
X-Google-Smtp-Source: AGHT+IF8A95+qGoEVGkNn/CsYU4bQ0SKBGBgamHY2X1wqAOeeXkjDUhCVM65skz13t42A7n4TGrgiA==
X-Received: by 2002:a05:600c:310a:b0:434:fddf:5bfa with SMTP id 5b1f17b1804b1-4366854bfc0mr4916025e9.2.1734651064899;
        Thu, 19 Dec 2024 15:31:04 -0800 (PST)
Message-ID: <94a1fccb-5edc-4670-b1d0-48e3bdf17a12@citrix.com>
Date: Thu, 19 Dec 2024 23:31:03 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/2] x86: Add Support for Paging-Write Feature
To: =?UTF-8?Q?Petr_Bene=C5=A1?= ,
 xen-devel@lists.xenproject.org
Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Tamas K Lengyel ,
 Alexandru Isaila ,
 Petre Pircalabu ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Anthony PERARD 
References: 
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 19/12/2024 6:16 pm, Petr Beneš wrote:
> From: Petr Beneš 
>
> This patch introduces a new XENMEM_access_r_pw permission. Functionally, it is similar to XENMEM_access_r, but for processors with TERTIARY_EXEC_EPT_PAGING_WRITE support (Intel 12th Gen/Alder Lake and later), it also permits the CPU to write to the page during guest page-table walks (e.g., updating A/D bits) without triggering an EPT violation.
>
> This behavior works by both enabling the EPT paging-write feature and setting the EPT paging-write flag in the EPT leaf entry.
>
> This feature provides a significant performance boost for introspection tools that monitor guest page-table updates. Previously, every page-table modification by the guest—including routine updates like setting A/D bits—triggered an EPT violation, adding unnecessary overhead. The new XENMEM_access_r_pw permission allows these "uninteresting" updates to occur without EPT violations, improving efficiency.
>
> Additionally, this feature simplifies the handling of race conditions in scenarios where an introspection tool:
>
> - Sets an "invisible breakpoint" in the altp2m view for a function F
> - Monitors guest page-table updates to track whether the page containing F is paged out
> - Encounters a cleared Access (A) bit on the page containing F while the guest is about to execute the breakpoint
>
> In the current implementation:
>
> - If xc_monitor_inguest_pagefault() is enabled, the introspection tool must emulate both the breakpoint and the setting of the Access bit.
> - If xc_monitor_inguest_pagefault() is disabled, Xen handles the EPT violation without notifying the introspection tool, setting the Access bit and emulating the instruction. However, Xen fetches the instruction from the default view instead of the altp2m view, potentially causing the breakpoint to be missed.
>
> With this patch, setting XENMEM_access_r_pw for monitored guest page-tables prevents EPT violations in these cases. This change enhances performance and reduces complexity for introspection tools, ensuring seamless breakpoint handling while tracking guest page-table updates.
>
> Petr Beneš (2):
>   x86: Rename _rsvd field to pw and move it to the bit 58
>   x86/EPT: Add Support for Paging-Write Feature

We're past final posting date for 4.20 now.

CC Oleksii as release manager.

However, it's a small patch series, and comes urgently on the back of
Intel ceasing all EPT-SPP support in November.

Given the timelines of the release, and how simple the series is, I'd
like to make an argument for including it at this juncture.

~Andrew


From xen-devel-bounces@lists.xenproject.org Thu Dec 19 23:55:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 23:55:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861545.1273527 (Exim 4.92)
	(envelope-from )
	id 1tOQMf-00017o-Hx; Thu, 19 Dec 2024 23:55:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861545.1273527; Thu, 19 Dec 2024 23:55: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 1tOQMf-00017h-Ep; Thu, 19 Dec 2024 23:55:33 +0000
Received: by outflank-mailman (input) for mailman id 861545;
 Thu, 19 Dec 2024 23:55: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 1tOQMd-00016S-Rc
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 23:55:31 +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 b9cddfc5-be64-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 00:55:29 +0100 (CET)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3862c78536bso77221f8f.2
 for ; Thu, 19 Dec 2024 15:55:29 -0800 (PST)
Received: from lab.home
 (dynamic-2a00-1028-83a4-4bca-c0bb-96ff-feed-9d50.ipv6.o2.cz.
 [2a00:1028:83a4:4bca:c0bb:96ff:feed:9d50])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c8a6dd3sm2628996f8f.96.2024.12.19.15.55.25
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 19 Dec 2024 15:55: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: b9cddfc5-be64-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734652529; x=1735257329; 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=CthQh3wSpepsh3Cctkm5dObyUxYj1SWrfSt1ki0rtiY=;
        b=gqGIgxnd6GARtXYxhqI3vS0r/INNvAbiIGVpUGD4OKZNg1BmlAmK78aZcZGut0j6bk
         cbYHlvTD191gjtMHl6ce1jtSCvP/SYJzvKGVpRb6gHPqcZ56L11x069zVYJPgCAHTz/8
         sZai2Vaob6Xf4exDww3M1spzlLGmeilLBqvsLtXsHHnntKvdH3kkVV8HVND4GlDhnwpY
         yOsJvqRAtQgqaZ60LEdKv/kc+HC5IRoyaWrAfa/O6KpIMMHmvnVzwrNQ04YJfaNg8/to
         +0vBczKUaHuuDoZsqFl9Ejp/MHuUWPffmEUa5+tJbxd3/L3QXR3pXjn7bzD0tslJGYo9
         sNwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734652529; x=1735257329;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=CthQh3wSpepsh3Cctkm5dObyUxYj1SWrfSt1ki0rtiY=;
        b=AdBCbyw2xPNA0K7dulcvZqcUs02FNqhrW8oxU5irsOH3WoNhsmKjIymYXEsOyMZwTf
         Bh8b8+Tllv/iZ0ZDnAUawu9Gwtc7JEMPeZUNISlh3ESv9ae507ItHcqpAlc9NJI321JV
         LKfwKTfrjHlTrGwHvF3dPkuPx2m6oX5ree7gERm91kiGBUhrtvsbVvkoHfZo6nTvmMnf
         Cu/mGbY+7eTjAlMxbpQ76RxcC7UzGDFW81iESa4Zk5YL09ZeagxLBxHCywDzbzlWWEO8
         Ke3T/hS6tc9dxq/dpzTAKmhqD7pKEtr0LPJiGlQ4fdTV+0lq/MLD7paK3fEk5Fevij7b
         7qAA==
X-Gm-Message-State: AOJu0YzFAKqAqVS++dt+OrBv8+IsNqbJ4yogmcS6TKmd5MHP4zy88mbn
	PGtK+xPkADjSzmEYZSpYySHR5WaDaTRBx8ZWFUQ1idshnzcK/xCAy6N78Q==
X-Gm-Gg: ASbGncuFKm1X/e+cOaZyAqvhAkISSC3Vy8DANXtHczn0eS4GyNxtigApM0Xz8Pg9+oC
	qtADm9gvqYL7721OgSOSj7BnEdntNABFSwoT1HyGtoC6Y5hCh0mIIBnMGvZIayKIU8pSlFbCSZ/
	ZMa3wBKC+7dfRV8ub+qVL50E/aJ1rjM2GCL62T+A4rn9yMMVZngt72ug+qZsSiWwCJov5rkiZa3
	zXmZFsWtZ5Gd9ZBMb2dVmUgVOxHq9aq3mkif1GxVTGnIhHaUGFbIlOZ3UIzJ7KZy6clbTjGteJC
	N7V7HfXZFvAxd23JbuGr7SNTm5sSZBskVILhU95rqnT7p6b4RCUto5az
X-Google-Smtp-Source: AGHT+IE/8a0ry3uqyDjAC+jYpZW0CgQsBhha5nzrX9tfdLm2bVQZrt9P4T8yqm54s9do75rDp9Lwwg==
X-Received: by 2002:a05:600c:3b18:b0:434:ff85:dd77 with SMTP id 5b1f17b1804b1-436686431e0mr2276825e9.3.1734652528424;
        Thu, 19 Dec 2024 15:55:28 -0800 (PST)
From: "=?UTF-8?q?Petr=20Bene=C5=A1?=" 
X-Google-Original-From: =?UTF-8?q?Petr=20Bene=C5=A1?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Petr=20Bene=C5=A1?= ,
	Tamas K Lengyel ,
	Alexandru Isaila ,
	Petre Pircalabu ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 2/2] x86: Add Support for Paging-Write Feature
Date: Thu, 19 Dec 2024 23:55:02 +0000
Message-Id: 
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Petr Beneš 

This patch introduces a new XENMEM_access_r_pw permission. Functionally, it is similar to XENMEM_access_r, but for processors with TERTIARY_EXEC_EPT_PAGING_WRITE support (Intel 12th Gen/Alder Lake and later), it also permits the CPU to write to the page during guest page-table walks (e.g., updating A/D bits) without triggering an EPT violation.

This behavior works by both enabling the EPT paging-write feature and setting the EPT paging-write flag in the EPT leaf entry.

This feature provides a significant performance boost for introspection tools that monitor guest page-table updates. Previously, every page-table modification by the guest—including routine updates like setting A/D bits—triggered an EPT violation, adding unnecessary overhead. The new XENMEM_access_r_pw permission allows these "uninteresting" updates to occur without EPT violations, improving efficiency.

Additionally, this feature simplifies the handling of race conditions in scenarios where an introspection tool:

- Sets an "invisible breakpoint" in the altp2m view for a function F
- Monitors guest page-table updates to track whether the page containing F is paged out
- Encounters a cleared Access (A) bit on the page containing F while the guest is about to execute the breakpoint

In the current implementation:

- If xc_monitor_inguest_pagefault() is enabled, the introspection tool must emulate both the breakpoint and the setting of the Access bit.
- If xc_monitor_inguest_pagefault() is disabled, Xen handles the EPT violation without notifying the introspection tool, setting the Access bit and emulating the instruction. However, Xen fetches the instruction from the default view instead of the altp2m view, potentially causing the breakpoint to be missed.

With this patch, setting XENMEM_access_r_pw for monitored guest page-tables prevents EPT violations in these cases. This change enhances performance and reduces complexity for introspection tools, ensuring seamless breakpoint handling while tracking guest page-table updates.

Signed-off-by: Petr Beneš 
---
 xen/arch/arm/mem_access.c               | 4 ++++
 xen/arch/arm/mmu/p2m.c                  | 1 +
 xen/arch/x86/hvm/hvm.c                  | 1 +
 xen/arch/x86/hvm/monitor.c              | 1 +
 xen/arch/x86/hvm/vmx/vmcs.c             | 4 +++-
 xen/arch/x86/include/asm/hvm/vmx/vmcs.h | 3 +++
 xen/arch/x86/include/asm/p2m.h          | 1 +
 xen/arch/x86/mm/hap/nested_hap.c        | 3 +++
 xen/arch/x86/mm/mem_access.c            | 3 +++
 xen/arch/x86/mm/p2m-ept.c               | 4 ++++
 xen/include/public/memory.h             | 9 +++++++++
 xen/include/xen/mem_access.h            | 6 ++++++
 12 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
index 0ec3462364..2af92bb402 100644
--- a/xen/arch/arm/mem_access.c
+++ b/xen/arch/arm/mem_access.c
@@ -32,6 +32,7 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
             ACCESS(rwx),
             ACCESS(rx2rw),
             ACCESS(n2rwx),
+            ACCESS(r_pw),
 #undef ACCESS
     };
 
@@ -172,6 +173,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned long flag,
             break;
         else
             goto err;
+    case XENMEM_access_r_pw:
     case XENMEM_access_rx2rw:
     case XENMEM_access_rx:
     case XENMEM_access_r:
@@ -253,6 +255,7 @@ bool p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct npfec npfec)
         violation = npfec.read_access || npfec.insn_fetch;
         break;
     case XENMEM_access_r:
+    case XENMEM_access_r_pw:
         violation = npfec.write_access || npfec.insn_fetch;
         break;
     default:
@@ -361,6 +364,7 @@ long p2m_set_mem_access(struct domain *d, gfn_t gfn, uint32_t nr,
         ACCESS(rwx),
         ACCESS(rx2rw),
         ACCESS(n2rwx),
+        ACCESS(r_pw),
 #undef ACCESS
     };
 
diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c
index 28df6e5d03..7642dbc7c5 100644
--- a/xen/arch/arm/mmu/p2m.c
+++ b/xen/arch/arm/mmu/p2m.c
@@ -597,6 +597,7 @@ static void p2m_set_permission(lpae_t *e, p2m_type_t t, p2m_access_t a)
         e->p2m.read = 0;
         break;
     case p2m_access_r:
+    case p2m_access_r_pw:
         e->p2m.write = 0;
         e->p2m.xn = 1;
         break;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 74e58c653e..495c8290ca 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1897,6 +1897,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
             violation = npfec.read_access || npfec.write_access || npfec.insn_fetch;
             break;
         case p2m_access_r:
+        case p2m_access_r_pw:
             violation = npfec.write_access || npfec.insn_fetch;
             break;
         case p2m_access_w:
diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index 74621000b2..523586ca98 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -295,6 +295,7 @@ bool hvm_monitor_check_p2m(unsigned long gla, gfn_t gfn, uint32_t pfec,
 
     case XENMEM_access_r:
     case XENMEM_access_n:
+    case XENMEM_access_r_pw:
         if ( pfec & PFEC_write_access )
             req.u.mem_access.flags |= MEM_ACCESS_R | MEM_ACCESS_W;
         if ( pfec & PFEC_insn_fetch )
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 147e998371..8c0ea789c1 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -203,6 +203,7 @@ static void __init vmx_display_features(void)
     P(cpu_has_vmx_bus_lock_detection, "Bus Lock Detection");
     P(cpu_has_vmx_notify_vm_exiting, "Notify VM Exit");
     P(cpu_has_vmx_virt_spec_ctrl, "Virtualize SPEC_CTRL");
+    P(cpu_has_vmx_ept_paging_write, "EPT Paging-Write");
 #undef P
 
     if ( !printed )
@@ -366,7 +367,8 @@ static int vmx_init_vmcs_config(bool bsp)
 
     if ( _vmx_cpu_based_exec_control & CPU_BASED_ACTIVATE_TERTIARY_CONTROLS )
     {
-        uint64_t opt = TERTIARY_EXEC_VIRT_SPEC_CTRL;
+        uint64_t opt = (TERTIARY_EXEC_VIRT_SPEC_CTRL |
+                        TERTIARY_EXEC_EPT_PAGING_WRITE);
 
         _vmx_tertiary_exec_control = adjust_vmx_controls2(
             "Tertiary Exec Control", 0, opt,
diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
index 939b87eb50..e1d3398141 100644
--- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
@@ -273,6 +273,9 @@ extern uint64_t vmx_tertiary_exec_control;
 #define cpu_has_vmx_virt_spec_ctrl \
      (vmx_tertiary_exec_control & TERTIARY_EXEC_VIRT_SPEC_CTRL)
 
+#define cpu_has_vmx_ept_paging_write \
+     (vmx_tertiary_exec_control & TERTIARY_EXEC_EPT_PAGING_WRITE)
+
 #define VMX_EPT_EXEC_ONLY_SUPPORTED                         0x00000001
 #define VMX_EPT_WALK_LENGTH_4_SUPPORTED                     0x00000040
 #define VMX_EPT_MEMORY_TYPE_UC                              0x00000100
diff --git a/xen/arch/x86/include/asm/p2m.h b/xen/arch/x86/include/asm/p2m.h
index e6de37f108..aa1bf7c9d0 100644
--- a/xen/arch/x86/include/asm/p2m.h
+++ b/xen/arch/x86/include/asm/p2m.h
@@ -980,6 +980,7 @@ static inline unsigned int p2m_access_to_iommu_flags(p2m_access_t p2ma)
     case p2m_access_r:
     case p2m_access_rx:
     case p2m_access_rx2rw:
+    case p2m_access_r_pw:
         return IOMMUF_readable;
 
     case p2m_access_w:
diff --git a/xen/arch/x86/mm/hap/nested_hap.c b/xen/arch/x86/mm/hap/nested_hap.c
index cc7bc6e5ea..255fba7e1c 100644
--- a/xen/arch/x86/mm/hap/nested_hap.c
+++ b/xen/arch/x86/mm/hap/nested_hap.c
@@ -213,6 +213,9 @@ int nestedhvm_hap_nested_page_fault(
     case p2m_access_n2rwx:
         p2ma_10 = p2m_access_n;
         break;
+    case p2m_access_r_pw:
+        p2ma_10 = p2m_access_r;
+        break;
     default:
         p2ma_10 = p2m_access_n;
         /* For safety, remove all permissions. */
diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index 60a0cce68a..21b5b7ecda 100644
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -45,6 +45,7 @@ static int _p2m_get_mem_access(struct p2m_domain *p2m, gfn_t gfn,
             ACCESS(rwx),
             ACCESS(rx2rw),
             ACCESS(n2rwx),
+            ACCESS(r_pw),
 #undef ACCESS
     };
 
@@ -94,6 +95,7 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
             break;
 
         case XENMEM_access_r:
+        case XENMEM_access_r_pw:
             violation = data->flags & MEM_ACCESS_WX;
             break;
 
@@ -312,6 +314,7 @@ bool xenmem_access_to_p2m_access(const struct p2m_domain *p2m,
         ACCESS(rwx),
         ACCESS(rx2rw),
         ACCESS(n2rwx),
+        ACCESS(r_pw),
 #undef ACCESS
     };
 
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 21728397f9..5ad78ae4b5 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -176,6 +176,10 @@ static void ept_p2m_type_to_flags(const struct p2m_domain *p2m,
             break;           
         case p2m_access_rwx:
             break;
+        case p2m_access_r_pw:
+            entry->w = entry->x = 0;
+            entry->pw = !!cpu_has_vmx_ept_paging_write;
+            break;
     }
     
     /*
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 5e545ae9a4..bd9fc37b52 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -426,6 +426,15 @@ typedef enum {
      * pausing the vcpu
      */
     XENMEM_access_n2rwx,
+
+    /*
+     * Same as XENMEM_access_r, but on processors with
+     * the TERTIARY_EXEC_EPT_PAGING_WRITE support,
+     * CPU-initiated page-table walks can still
+     * write to it (e.g., update A/D bits)
+     */
+    XENMEM_access_r_pw,
+
     /* Take the domain default */
     XENMEM_access_default
 } xenmem_access_t;
diff --git a/xen/include/xen/mem_access.h b/xen/include/xen/mem_access.h
index 87d93b31f6..2231341b5d 100644
--- a/xen/include/xen/mem_access.h
+++ b/xen/include/xen/mem_access.h
@@ -64,6 +64,12 @@ typedef enum {
                            * generates an event but does not pause the
                            * vcpu */
 
+    p2m_access_r_pw = 10, /* Special: same as R, but on processors with
+                           * the TERTIARY_EXEC_EPT_PAGING_WRITE support,
+                           * CPU-initiated page-table walks can still
+                           * write to it (e.g., update A/D bits)
+                           */
+
     /* NOTE: Assumed to be only 4 bits right now on x86. */
 } p2m_access_t;
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 23:55:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 23:55:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861544.1273516 (Exim 4.92)
	(envelope-from )
	id 1tOQMa-0000qj-63; Thu, 19 Dec 2024 23:55:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861544.1273516; Thu, 19 Dec 2024 23:55:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOQMa-0000qc-3R; Thu, 19 Dec 2024 23:55:28 +0000
Received: by outflank-mailman (input) for mailman id 861544;
 Thu, 19 Dec 2024 23:55: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 1tOQMZ-0000c1-C6
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 23:55:27 +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 b814a902-be64-11ef-a0d8-8be0dac302b0;
 Fri, 20 Dec 2024 00:55:26 +0100 (CET)
Received: by mail-wr1-x430.google.com with SMTP id
 ffacd0b85a97d-3862e2c9bb5so86479f8f.0
 for ; Thu, 19 Dec 2024 15:55:26 -0800 (PST)
Received: from lab.home
 (dynamic-2a00-1028-83a4-4bca-c0bb-96ff-feed-9d50.ipv6.o2.cz.
 [2a00:1028:83a4:4bca:c0bb:96ff:feed:9d50])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c8a6dd3sm2628996f8f.96.2024.12.19.15.55.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 19 Dec 2024 15:55: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: b814a902-be64-11ef-a0d8-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734652526; x=1735257326; 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=e4D++oBXK5nnYb4cn7GeUmCP5459fQygu93iRr5qfas=;
        b=AKU4fV4pcNIYmnyDhL+T2a2tfNP30UAF2dU/C64JOFRYiMFq0NydvCUD+omHSmabJw
         uEgodVl8+Jy2wlOczzY5oVqXvVKt1rUJ57/DY8z7idP0GpCR42mmyKOYgGIr28NZzHN4
         YRPhQNFUnoVbv+E1p4QVPdt2fKCuAevKoDu7C1zkygThdt+AhBDIn6vBXPCuxst4Y9KG
         OEwQffRWjPNFfLRwA2p1mYwFKLJC37Ylt5DMtYXhwK3j2LQJReSEdF20HOyEl+ZKVQfk
         MKGr+MIFdGOGiMI+zL5PJUm+gx6swmGt/r3lvwLZdw+O5Siqf4ty0bzw9GJ5r98SSeQR
         8hIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734652526; x=1735257326;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=e4D++oBXK5nnYb4cn7GeUmCP5459fQygu93iRr5qfas=;
        b=S+ZJgkIT4qNqQcr8QlMAQ9bkoD3I7qV78h9z1okLAaeqNUmtjDoI16FMTyeX8V69ph
         +DFtQnKGxOi49SvM3sCI5IqVW2jHnGt2PX4mxwtw1BpgQWw/9YjW1HeeYXfquBkwJXr+
         gX0q8Pbk/TgCuQF7RUV8HJAbmp8nK8FxdAXEqLxkt7pHxTWa4+eQaWpGwbkfrWcG/xOL
         kkAEpn9UHmy/GllEkrLLklAbtgEyHISHLdfRRuhnH/2Pc2RxtMPokxBJrsqq2pQvqsIv
         k1i8Fnm+9yTSBpPtFr4QfnWUd205q3T2113JNn3wY9wT6mSm0OEQ12MVruW2UV/wiI+6
         ayTw==
X-Gm-Message-State: AOJu0YwMPIJm3tQX4Kh617R/1+sU/IZtI92lIHacipHmRakyLyL8L7XI
	/4/ppmAEybGl7R8uE1/S5CIu6bpbTVLY64CQOc4zPMWzOcjkzYCh10U59Q==
X-Gm-Gg: ASbGncvK0w/t/zn5fAx4jIF2Zmk3y8M/56V06UaHPJ0+JzkfZSBihxIHXlqbPqoIhzB
	skWnoeXN0OFQsNV2DNBCgI2qUp43WtB67cx9paNYTRwsfrye+qtZfjmfK0Rsin42Tg+/sAccChm
	ZeTGfhtClhFP3cwqzcLtbyOcuzYkI6rZSudOd+ZWNSOnnvY8AYblieTjTk8RyYG5EjwdMR6OTgO
	4CXzKHR1VQlW8gP/qDqTbpAzhgEQh2DORjEVxQkHNdC+tbvVlWOE3jMS/xLEwOTKXuG/ooUb+aD
	mDVhVN6512t8oMc/9hUtpojST69ud8Mbx1PN4sNON1hwSNjteJVVNSBl
X-Google-Smtp-Source: AGHT+IExPdJoDGnroTJOpIyAQALEK/cHEbyLaeZGfeJwiY7mRsUAu5D1LiA9hpAIXQXdI1f/hamcJQ==
X-Received: by 2002:a05:600c:a0a:b0:42c:aeee:e604 with SMTP id 5b1f17b1804b1-43668b93b4fmr2109995e9.8.1734652525548;
        Thu, 19 Dec 2024 15:55:25 -0800 (PST)
From: "=?UTF-8?q?Petr=20Bene=C5=A1?=" 
X-Google-Original-From: =?UTF-8?q?Petr=20Bene=C5=A1?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Petr=20Bene=C5=A1?= ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 1/2] x86: Rename _rsvd field to pw and move it to the bit 58
Date: Thu, 19 Dec 2024 23:55:01 +0000
Message-Id: 
X-Mailer: git-send-email 2.34.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Petr Beneš 

The EPT Paging-write feature (when enabled by the TERTIARY_EXEC_EPT_PAGING_WRITE bit) uses bit 58 of the EPT entry to indicate that guest paging may update the page, even if the W access is not set.

This patch is a preparation for the EPT Paging-write feature.

Signed-off-by: Petr Beneš 
---
 xen/arch/x86/include/asm/hvm/vmx/vmx.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmx.h b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
index f0ec459622..d920de96b7 100644
--- a/xen/arch/x86/include/asm/hvm/vmx/vmx.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmx.h
@@ -34,8 +34,8 @@ typedef union {
                                EPT/VT-d usage */
         mfn         :   40, /* bits 51:12 - Machine physical frame number */
         sa_p2mt     :   6,  /* bits 57:52 - Software available 2 */
-        access      :   4,  /* bits 61:58 - p2m_access_t */
-        _rsvd       :   1,  /* bit 62 - reserved */
+        pw          :   1,  /* bit 58 - Paging-write access */
+        access      :   4,  /* bits 62:59 - p2m_access_t */
         suppress_ve :   1;  /* bit 63 - suppress #VE */
     };
     u64 epte;
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Thu Dec 19 23:55:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Dec 2024 23:55:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861543.1273506 (Exim 4.92)
	(envelope-from )
	id 1tOQMY-0000ci-Vc; Thu, 19 Dec 2024 23:55:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861543.1273506; Thu, 19 Dec 2024 23:55: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 1tOQMY-0000cb-T2; Thu, 19 Dec 2024 23:55:26 +0000
Received: by outflank-mailman (input) for mailman id 861543;
 Thu, 19 Dec 2024 23:55: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 1tOQMY-0000c1-A7
 for xen-devel@lists.xenproject.org; Thu, 19 Dec 2024 23:55:26 +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 b763e244-be64-11ef-a0d8-8be0dac302b0;
 Fri, 20 Dec 2024 00:55:25 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-3862f11a13dso106700f8f.2
 for ; Thu, 19 Dec 2024 15:55:25 -0800 (PST)
Received: from lab.home
 (dynamic-2a00-1028-83a4-4bca-c0bb-96ff-feed-9d50.ipv6.o2.cz.
 [2a00:1028:83a4:4bca:c0bb:96ff:feed:9d50])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c8a6dd3sm2628996f8f.96.2024.12.19.15.55.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 19 Dec 2024 15:55: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: b763e244-be64-11ef-a0d8-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734652525; x=1735257325; 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=R344QuDchp2T4urLkcV5o0R8WnBSuoK+n3GnVVOAnuE=;
        b=MKJIhEEXEMjQk78+JDxD7r6yCbJ6HDFJvL8yApzbpKkb/7XgPLKWQ4bR68/P+Nghm3
         1stuNNyz4mV/NsE39O9thHfa3ul7uQRBpZnz8alXJam6OrXuKbR3wIsULYxUR/VmvJlH
         QE6xeQWrvTzmjmrZr6r8YmObZUq42WjLBxsnI8dMYmZ9ByUvuAS4zWx8gJzaLZDUC7RO
         WYQS8ZQyP5AVfs6iP402915UoNJnxLuIuhnohiXrQNSTkRC/ZtKIinNK/pDtZEl8/zhT
         IZlnQ/jsJdFyeHkHiCuCTw0nM02Q39OlOOFCsCNnjpyYY1uvnI32VBxRh17YSpB7boW3
         Pfig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734652525; x=1735257325;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=R344QuDchp2T4urLkcV5o0R8WnBSuoK+n3GnVVOAnuE=;
        b=gcLSmR0NOde/bFX1FvtIjJP+IB+gf9uqG7RIX1CvNI3ST7lUM4ExXZJzG153SUNLfc
         gXHOn+Jz0pjgedI/DYQGONv3wTFCdoChMrx2NS7Unv8ZSsSt1WTBetNIcknOoqS3wSii
         aQYb/G2wr8FJbIuoS3j8DuqQaorrv+xeFTg8eoqUTQUpf2Ec4zBNw9KqWYxfZG1Kpmp6
         af2qTDTgWOJosSmUfQv/RqfCvksDY0n1GfbSBC49BkmTVdyvcQJBGZPGypG81g4U1IMg
         D4EnMwtJZVAA28jIOzySG8myteFHXa+M5VNyeKusERnAe4h9Ll+6fmb1yzRUs1/RvVBp
         Hgmw==
X-Gm-Message-State: AOJu0YxOBI8f7AJ1I+S8w3ZP1aheXcJnSBMaOxV5VQ0Q9v85JAe+y8pQ
	kiuagIA7MXdWEY+0IxXr364es0XSFf8rokuAwchS7AW7wiOAMDs4YMIGQg==
X-Gm-Gg: ASbGnctbz0otx77j2GoxCeEODbznQNrf8V+31zkYxJZO0HJ3W5YAsQYF5gENAk2yBq1
	o2rOJsKvUe+uD78ffVMlbRPovryP5NUTAdaR2WEkbm67BDL3Z6M8OLEKc9chf7Nh2GW2fdu4KUF
	RSZ1IrjNQ2zeruyWF39j6gV5oeJ1XoQY6GrztXiPQTho7a5mkkkiNlbQxqodNTtUjWwNV5Kjekc
	xMT/hQBah3EuCsH/gxM213lsOqfSQqdpYkjPlf5b/4A8J35ntFZdk0Xxz8M7UxI0eWNsuAk5PmM
	ScMbo483xjO9xnzbA2XKG+xMLWGAh/sBWAgn/I/ZXtvi1UnyL4V9PUSR
X-Google-Smtp-Source: AGHT+IGMAvQQlpb3pXPTVIMpPYz3tMugaW0YO2HTh+q1S2+CAHasQgYWxTPEhvmUpCFPu57koazZKA==
X-Received: by 2002:a5d:6487:0:b0:385:de67:229e with SMTP id ffacd0b85a97d-38a223f74f7mr240619f8f.11.1734652523093;
        Thu, 19 Dec 2024 15:55:23 -0800 (PST)
From: "=?UTF-8?q?Petr=20Bene=C5=A1?=" 
X-Google-Original-From: =?UTF-8?q?Petr=20Bene=C5=A1?= 
To: xen-devel@lists.xenproject.org
Cc: =?UTF-8?q?Petr=20Bene=C5=A1?= ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Tamas K Lengyel ,
	Alexandru Isaila ,
	Petre Pircalabu ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Anthony PERARD 
Subject: [PATCH v2 0/2] x86: Add Support for Paging-Write Feature
Date: Thu, 19 Dec 2024 23:55:00 +0000
Message-Id: 
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Petr Beneš 

Changes since v1:
- Added signed-off-by tags

This patch introduces a new XENMEM_access_r_pw permission. Functionally, it is similar to XENMEM_access_r, but for processors with TERTIARY_EXEC_EPT_PAGING_WRITE support (Intel 12th Gen/Alder Lake and later), it also permits the CPU to write to the page during guest page-table walks (e.g., updating A/D bits) without triggering an EPT violation.

This behavior works by both enabling the EPT paging-write feature and setting the EPT paging-write flag in the EPT leaf entry.

This feature provides a significant performance boost for introspection tools that monitor guest page-table updates. Previously, every page-table modification by the guest—including routine updates like setting A/D bits—triggered an EPT violation, adding unnecessary overhead. The new XENMEM_access_r_pw permission allows these "uninteresting" updates to occur without EPT violations, improving efficiency.

Additionally, this feature simplifies the handling of race conditions in scenarios where an introspection tool:

- Sets an "invisible breakpoint" in the altp2m view for a function F
- Monitors guest page-table updates to track whether the page containing F is paged out
- Encounters a cleared Access (A) bit on the page containing F while the guest is about to execute the breakpoint

In the current implementation:

- If xc_monitor_inguest_pagefault() is enabled, the introspection tool must emulate both the breakpoint and the setting of the Access bit.
- If xc_monitor_inguest_pagefault() is disabled, Xen handles the EPT violation without notifying the introspection tool, setting the Access bit and emulating the instruction. However, Xen fetches the instruction from the default view instead of the altp2m view, potentially causing the breakpoint to be missed.

With this patch, setting XENMEM_access_r_pw for monitored guest page-tables prevents EPT violations in these cases. This change enhances performance and reduces complexity for introspection tools, ensuring seamless breakpoint handling while tracking guest page-table updates.

Petr Beneš (2):
  x86: Rename _rsvd field to pw and move it to the bit 58
  x86: Add Support for Paging-Write Feature

 xen/arch/arm/mem_access.c               | 4 ++++
 xen/arch/arm/mmu/p2m.c                  | 1 +
 xen/arch/x86/hvm/hvm.c                  | 1 +
 xen/arch/x86/hvm/monitor.c              | 1 +
 xen/arch/x86/hvm/vmx/vmcs.c             | 4 +++-
 xen/arch/x86/include/asm/hvm/vmx/vmcs.h | 3 +++
 xen/arch/x86/include/asm/hvm/vmx/vmx.h  | 4 ++--
 xen/arch/x86/include/asm/p2m.h          | 1 +
 xen/arch/x86/mm/hap/nested_hap.c        | 3 +++
 xen/arch/x86/mm/mem_access.c            | 3 +++
 xen/arch/x86/mm/p2m-ept.c               | 4 ++++
 xen/include/public/memory.h             | 9 +++++++++
 xen/include/xen/mem_access.h            | 6 ++++++
 13 files changed, 41 insertions(+), 3 deletions(-)

-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Dec 20 01:08:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 01:08:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861574.1273536 (Exim 4.92)
	(envelope-from )
	id 1tORV4-0001yB-Gm; Fri, 20 Dec 2024 01:08:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861574.1273536; Fri, 20 Dec 2024 01: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 1tORV4-0001y4-Do; Fri, 20 Dec 2024 01:08:18 +0000
Received: by outflank-mailman (input) for mailman id 861574;
 Fri, 20 Dec 2024 01:08: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 1tORV3-0001xy-UP
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 01:08:17 +0000
Received: from sender4-op-o12.zoho.com (sender4-op-o12.zoho.com
 [136.143.188.12]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e1d7e04c-be6e-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 02:08:13 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1734656889090276.85725902574586;
 Thu, 19 Dec 2024 17:08:09 -0800 (PST)
Received: by mail-yw1-f170.google.com with SMTP id
 00721157ae682-6ef81222aaaso11915847b3.3
 for ; Thu, 19 Dec 2024 17:08: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: e1d7e04c-be6e-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1734656890; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=nUMoqtNrkLiY2fr723A/5ix9WqZLEEUT6yoqsGFdoR5RPMDCuB4rVEC6OAlBoHCPRyMIOw24wBbRMeQjVnxc58GrNV7dG8Djwlhy5DFGxU7AZwujMA3Psd24vfQXvJG4fJHcHrxY/C/eMzP53TqAaq85MAE1dKjwwCPO8fbRPi0=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1734656890; 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=mpYogTiX0TPPOuB1caBYMoaxkBiu2LrwlS8Vkn57nrs=; 
	b=GC5nCSuKrhzkpq7e+PSwyaN2r6E19AUPuSX043h5tJkfeXb+Z2KGfHTNLVLqGGmVP2HB8SpxgJ5BWq/K9N6vvC6KRKnxLqg7TvxJ4t/+EWzBkm/Yr7LB2Qy45kUPfbg67jAvrjeGWQ+vmDqe/26ntbNc6R3mfTwitm5TY4yy6JA=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=tklengyel.com;
	spf=pass  smtp.mailfrom=tamas@tklengyel.com;
	dmarc=pass header.from=
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1734656890;
	s=zmail; d=tklengyel.com; i=tamas@tklengyel.com;
	h=MIME-Version:References:In-Reply-To:From:From:Date:Date:Message-ID:Subject:Subject:To:To:Cc:Cc:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=mpYogTiX0TPPOuB1caBYMoaxkBiu2LrwlS8Vkn57nrs=;
	b=RWw1NPA4NZbZqRLnjpvJHc9w+EtkmC68+z3P3R5STPAGfv+TZHe+qX25FvIRlkyn
	xcfTIoxvA6O9r6PnMBvBfYt+GSLVRfxoaJRy5BEgyCJ/eTV1DPzOEYxMvj4tevRjJTZ
	ongcygHPnfj8+fubxOMjo3i9LsTKoMoWFAQvNE/E=
X-Gm-Message-State: AOJu0YygKkJxq5gLs7qbIVZ7mEYLNCy3vjnj7tN2erA5yNfG6k2PlvFK
	3nyEKBpT7ip5FmfL0lh5Rlnqu43iy5VcY3mvmGI1hB806pbBfMk50uffa+UlXNcWRZHMjY8XvIX
	ggHduYzhYx+8H/AhBhTVq0b4m5Yc=
X-Google-Smtp-Source: AGHT+IHeEHW5Oy4aQBUVHup6lEWaEpNSayL/xuto9lHnSwmAwBWJ6uSIJXLZ7tLSkV6HiuM48tkxxNbbGTzZCpCv18Q=
X-Received: by 2002:a05:690c:498b:b0:6f2:8dde:b66 with SMTP id
 00721157ae682-6f3f8114d8fmr7807387b3.12.1734656888075; Thu, 19 Dec 2024
 17:08:08 -0800 (PST)
MIME-Version: 1.0
References:  <95580d02390056ea10eb80439f9d3ef9d2297ecc.1734631969.git.w1benny@gmail.com>
In-Reply-To: <95580d02390056ea10eb80439f9d3ef9d2297ecc.1734631969.git.w1benny@gmail.com>
From: Tamas K Lengyel 
Date: Thu, 19 Dec 2024 20:07:31 -0500
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: [PATCH 2/2] x86: Add Support for Paging-Write Feature
To: =?UTF-8?Q?Petr_Bene=C5=A1?= 
Cc: xen-devel@lists.xenproject.org, Alexandru Isaila , 
	Petre Pircalabu , Stefano Stabellini , 
	Julien Grall , Bertrand Marquis , 
	Michal Orzel , Volodymyr Babchuk , 
	Andrew Cooper , Anthony PERARD , 
	Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 19, 2024 at 1:17=E2=80=AFPM Petr Bene=C5=A1 =
 wrote:
>
> From: Petr Bene=C5=A1 
>
> This patch introduces a new XENMEM_access_r_pw permission. Functionally, =
it is similar to XENMEM_access_r, but for processors with TERTIARY_EXEC_EPT=
_PAGING_WRITE support (Intel 12th Gen/Alder Lake and later), it also permit=
s the CPU to write to the page during guest page-table walks (e.g., updatin=
g A/D bits) without triggering an EPT violation.
>
> This behavior works by both enabling the EPT paging-write feature and set=
ting the EPT paging-write flag in the EPT leaf entry.
>
> This feature provides a significant performance boost for introspection t=
ools that monitor guest page-table updates. Previously, every page-table mo=
dification by the guest=E2=80=94including routine updates like setting A/D =
bits=E2=80=94triggered an EPT violation, adding unnecessary overhead. The n=
ew XENMEM_access_r_pw permission allows these "uninteresting" updates to oc=
cur without EPT violations, improving efficiency.
>
> Additionally, this feature simplifies the handling of race conditions in =
scenarios where an introspection tool:
>
> - Sets an "invisible breakpoint" in the altp2m view for a function F
> - Monitors guest page-table updates to track whether the page containing =
F is paged out
> - Encounters a cleared Access (A) bit on the page containing F while the =
guest is about to execute the breakpoint
>
> In the current implementation:
>
> - If xc_monitor_inguest_pagefault() is enabled, the introspection tool mu=
st emulate both the breakpoint and the setting of the Access bit.
> - If xc_monitor_inguest_pagefault() is disabled, Xen handles the EPT viol=
ation without notifying the introspection tool, setting the Access bit and =
emulating the instruction. However, Xen fetches the instruction from the de=
fault view instead of the altp2m view, potentially causing the breakpoint t=
o be missed.

I'm glad to see this mystery resolved! \o/

> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> index 21728397f9..5ad78ae4b5 100644
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -176,6 +176,10 @@ static void ept_p2m_type_to_flags(const struct p2m_d=
omain *p2m,
>              break;
>          case p2m_access_rwx:
>              break;
> +        case p2m_access_r_pw:
> +            entry->w =3D entry->x =3D 0;
> +            entry->pw =3D !!cpu_has_vmx_ept_paging_write;

I don't see ept_entry_t having a pw field. What's the deal there?

Tamas


From xen-devel-bounces@lists.xenproject.org Fri Dec 20 01:13:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 01:13:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861583.1273547 (Exim 4.92)
	(envelope-from )
	id 1tORZu-0003Yg-31; Fri, 20 Dec 2024 01:13:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861583.1273547; Fri, 20 Dec 2024 01:13: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 1tORZt-0003YZ-VB; Fri, 20 Dec 2024 01:13:17 +0000
Received: by outflank-mailman (input) for mailman id 861583;
 Fri, 20 Dec 2024 01:13: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 1tORZs-0003YT-Je
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 01:13:16 +0000
Received: from sender4-op-o12.zoho.com (sender4-op-o12.zoho.com
 [136.143.188.12]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 95c05bb6-be6f-11ef-a0d8-8be0dac302b0;
 Fri, 20 Dec 2024 02:13:15 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1734657190105953.2702589204604;
 Thu, 19 Dec 2024 17:13:10 -0800 (PST)
Received: by mail-yb1-f171.google.com with SMTP id
 3f1490d57ef6-e4a6b978283so2087469276.0
 for ; Thu, 19 Dec 2024 17:13:09 -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: 95c05bb6-be6f-11ef-a0d8-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1734657192; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=YKvlKlLA/OsXWuewv+PPH8Xt1abTzeMxZ+WX/ZAFgUUbisLi+oRzMp1WS8jrmmKEuHrTgoeLekO0cyHSz19vmTqOEF1Da7BjtCbTv4G9cfpWkQeWVe4c1m+RBViQ5pGCyYcUHA+wi1gacxTV8nyRbstAytW6la/S1mx9MLWwDWc=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1734657192; h=Content-Type:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=BDy45s2GE6WB60raklLil7NEQFGJcGEiXJs7NnWN944=; 
	b=gI/VUpAnqpfGxMny2hTKauYPNDa3xzkJ2SLFmOXasNIYaom2g5CMiuadRhKCIoiuPRB+Zbo6m5Pwv0Qv8cV8kXSULJFpBsljCh6wlsarosebHBBHRX3mrav6sOQTKjiPPml5vvAdw3lhfoChkh+WQIImjujpiRmoIZteTYvEAeM=
ARC-Authentication-Results: i=1; mx.zohomail.com;
	dkim=pass  header.i=tklengyel.com;
	spf=pass  smtp.mailfrom=tamas@tklengyel.com;
	dmarc=pass header.from=
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1734657192;
	s=zmail; d=tklengyel.com; i=tamas@tklengyel.com;
	h=MIME-Version:References:In-Reply-To:From:From:Date:Date:Message-ID:Subject:Subject:To:To:Cc:Cc:Content-Type:Message-Id:Reply-To;
	bh=BDy45s2GE6WB60raklLil7NEQFGJcGEiXJs7NnWN944=;
	b=gco+wsKqGYz90CYDxneVlPqPtaepoXwf04ENbGcWycfD+FXmVrVQdjoQgMl3moMh
	jYVgYBQFAGOvFPey2wz+c1BBPJwg/2FqOCT4cBNmB+C8GjY4sM5oT+KIo6D08sUpUSZ
	K/ksJmFvI3+NyMEGXtXiWFkonF0Pbo94MpX+E9ms=
X-Gm-Message-State: AOJu0YzCCSm2uopQGnVWUVZ7aX/uSsTXLeTlSj+HI/dkbTrYP/8dkd3x
	ke2hQMc71WiZOF10J+x/TVpWVahAlW6WWghNfNRqnZ0eUU+yBS/I1R+1ejnbffCoIeybea8p6zO
	sgVIP6qHQbYf9L5rJE5W6xzCK8FA=
X-Google-Smtp-Source: AGHT+IHsya+yY7zOzXQQK8lNsRHTXhGgW0yFUIq9HnLGgh620KIZn/RWee2IWz369nUH4wF9mWtc1dWhxmHcS0anCT8=
X-Received: by 2002:a05:690c:734a:b0:6ea:7fa3:ab22 with SMTP id
 00721157ae682-6f3f7e1f3e3mr7157867b3.8.1734657189225; Thu, 19 Dec 2024
 17:13:09 -0800 (PST)
MIME-Version: 1.0
References:  <95580d02390056ea10eb80439f9d3ef9d2297ecc.1734631969.git.w1benny@gmail.com>
 
In-Reply-To: 
From: Tamas K Lengyel 
Date: Thu, 19 Dec 2024 20:12:32 -0500
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: [PATCH 2/2] x86: Add Support for Paging-Write Feature
To: =?UTF-8?Q?Petr_Bene=C5=A1?= 
Cc: xen-devel@lists.xenproject.org, Alexandru Isaila , 
	Petre Pircalabu , Stefano Stabellini , 
	Julien Grall , Bertrand Marquis , 
	Michal Orzel , Volodymyr Babchuk , 
	Andrew Cooper , Anthony PERARD , 
	Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
Content-Type: text/plain; charset="UTF-8"

> > diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> > index 21728397f9..5ad78ae4b5 100644
> > --- a/xen/arch/x86/mm/p2m-ept.c
> > +++ b/xen/arch/x86/mm/p2m-ept.c
> > @@ -176,6 +176,10 @@ static void ept_p2m_type_to_flags(const struct p2m_domain *p2m,
> >              break;
> >          case p2m_access_rwx:
> >              break;
> > +        case p2m_access_r_pw:
> > +            entry->w = entry->x = 0;
> > +            entry->pw = !!cpu_has_vmx_ept_paging_write;
>
> I don't see ept_entry_t having a pw field. What's the deal there?

Never mind, I see it in the 1/2 patch, for some reason my mail client
bundled 2/2 under the cover email so I read the patches out-of-order.

Acked-by: Tamas K Lengyel 


From xen-devel-bounces@lists.xenproject.org Fri Dec 20 01:39:19 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 01:39:19 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861595.1273557 (Exim 4.92)
	(envelope-from )
	id 1tORyz-0006WW-1D; Fri, 20 Dec 2024 01:39:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861595.1273557; Fri, 20 Dec 2024 01:39:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tORyy-0006WP-Us; Fri, 20 Dec 2024 01:39:12 +0000
Received: by outflank-mailman (input) for mailman id 861595;
 Fri, 20 Dec 2024 01:39: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 1tORyx-0006WJ-Vc
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 01:39:12 +0000
Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com
 [2a00:1450:4864:20::343])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 35510a9a-be73-11ef-a0d8-8be0dac302b0;
 Fri, 20 Dec 2024 02:39:09 +0100 (CET)
Received: by mail-wm1-x343.google.com with SMTP id
 5b1f17b1804b1-4361f796586so15085325e9.3
 for ; Thu, 19 Dec 2024 17:39:09 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4366120088esm31993515e9.13.2024.12.19.17.39.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 19 Dec 2024 17:39: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: 35510a9a-be73-11ef-a0d8-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734658749; x=1735263549; 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=4ebt9RfFNlU+kCB4CV1j8AEPPTxXG9SHQgcbE7oz8Lc=;
        b=gPbIC4lkHDk/xKvpdkRgvRJ4N0Y0mh9SFELSOJDTS94nOcuZ1/dRC92qP4IiW3ztU+
         jZAk7DUrLDSnCOqfjMokSYHYRUAqQ7x+YbmxMOvb34C4HoJaN6mNKE0JRvOX4yNCVQaD
         JYIxqApGA8ORPHOOasfd3/Bc5d7/fs+rOQuEs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734658749; x=1735263549;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=4ebt9RfFNlU+kCB4CV1j8AEPPTxXG9SHQgcbE7oz8Lc=;
        b=xBH1J5Z1i5UNTNcoDJJFEqWdXly0SFphYTAKkYXD7oS8RZ6iuaiX2ciQmo+/637hq+
         WOdtMpAhiZ0s1zbPVY+5a0IItRrjoyRMSYbfUszNRL03emtgBII42j2GSx5QTfgG53QU
         YMuzYd+a5ncLCoFyl53x368uvRn8pnTNrN0mULrPT+phshR+VWyREeRAGwGeMdZYDNAO
         /89yogtzhhpfC0DWiv5qoS4EAmSWTHnGlNbG99W95u/fnsBn7EqDEXGXN4Fo/b8V9DIm
         J/g5ZPyHuHBLSKJbq7uk4WXWfsRUvITxGqplgMrgPJzF+/E5OPS5qX/YaNbQ6eHgdfYI
         m1Ag==
X-Forwarded-Encrypted: i=1; AJvYcCXI4RZWGL8SPoHgL78pYfii/w68P8RnqP6PgP/2LY9EaEHO9UxpeohM3/Y1ZIECZwhFT0o8lpuYYUM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyHhgtEL/AYRyv0ojkZ+AI0tuetnG2acjJhPePr+oevG9ux6vve
	gJGBeP3/PiEEsPyO9JLUbpBCeoeInIJYy/c39uvI35VK9xpiJ5T7/s07vhG1Eps=
X-Gm-Gg: ASbGncsj36ThWI9C6GiqEwoS56hZ2QJ8qG2LCmlA6S2a/C8DHGxGxTlVIqegRCynWrP
	qSTRkVp3VMM6nnwMVBltAQGjaP/rtiAX7tv2b2RJJEKv4gniSeM63kCJMhyl1aMjlEkBGl2gvgm
	sYUP6T40DJA6eHXv3mCWtsBvsn1kpeB10KI88R2o1vEGtyMUX5T1qU2oql2op0J0hizTPPrai1x
	cbW7VX5S/nueRdA2Zm0WjxQMIlr1bkKUHevjsFyBmsy+WNSeXzpCn+H4fXqPxPj0QbHm2l0GnKI
	oh1cWIwJ7d+GoXBt71Vk
X-Google-Smtp-Source: AGHT+IEaM6MkZFZl3KmiAg6nD02zKSlYWnEyf/5dVUkNhm+rsElC7GOnheMem/9YEpGNrUbt2mLwbQ==
X-Received: by 2002:a05:600c:4fd3:b0:431:54f3:11ab with SMTP id 5b1f17b1804b1-43668b600c9mr5900845e9.33.1734658749151;
        Thu, 19 Dec 2024 17:39:09 -0800 (PST)
Message-ID: <43166e29-ff2d-4a9d-8c1b-41b5e247974b@citrix.com>
Date: Fri, 20 Dec 2024 01:39:07 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [Linux-6.12.y] XEN: CVE-2024-53241 / XSA-466 and Clang-kCFI
To: sedat.dilek@gmail.com
Cc: Juergen Gross , Peter Zijlstra ,
 Sami Tolvanen , Jan Beulich ,
 Josh Poimboeuf ,
 Linus Torvalds ,
 Greg Kroah-Hartman ,
 Sasha Levin , linux-kernel@vger.kernel.org,
 stable@vger.kernel.org, Kees Cook ,
 Nathan Chancellor , llvm@lists.linux.dev,
 xen-devel 
References: 
 <099d3a80-4fdb-49a7-9fd0-207d7386551f@citrix.com>
 
 
 <90640a5d-ff17-4555-adc6-ae9e21e24ebd@citrix.com>
 
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20/12/2024 12:27 am, Sedat Dilek wrote:
> On Fri, Dec 20, 2024 at 12:26 AM Andrew Cooper
>  wrote:
>> On 19/12/2024 11:10 pm, Sedat Dilek wrote:
>>> On Thu, Dec 19, 2024 at 6:07 PM Sedat Dilek  wrote:
>>>> On Thu, Dec 19, 2024 at 5:44 PM Andrew Cooper  wrote:
>>>>> On 19/12/2024 4:14 pm, Sedat Dilek wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Linux v6.12.6 will include XEN CVE fixes from mainline.
>>>>>>
>>>>>> Here, I use Debian/unstable AMD64 and the SLIM LLVM toolchain 19.1.x
>>>>>> from kernel.org.
>>>>>>
>>>>>> What does it mean in ISSUE DESCRIPTION...
>>>>>>
>>>>>> Furthermore, the hypercall page has no provision for Control-flow
>>>>>> Integrity schemes (e.g. kCFI/CET-IBT/FineIBT), and will simply
>>>>>> malfunction in such configurations.
>>>>>>
>>>>>> ...when someone uses Clang-kCFI?
>>>>> The hypercall page has functions of the form:
>>>>>
>>>>>     MOV $x, %eax
>>>>>     VMCALL / VMMCALL / SYSCALL
>>>>>     RET
>>>>>
>>>>> There are no ENDBR instructions, and no prologue/epilogue for hash-based
>>>>> CFI schemes.
>>>>>
>>>>> This is because it's code provided by Xen, not code provided by Linux.
>>>>>
>>>>> The absence of ENDBR instructions will yield #CP when CET-IBT is active,
>>>>> and the absence of hash prologue/epilogue lets the function be used in a
>>>>> type-confused manor that CFI should have caught.
>>>>>
>>>>> ~Andrew
>>>> Thanks for the technical explanation, Andrew.
>>>>
>>>> Hope that helps the folks of "CLANG CONTROL FLOW INTEGRITY SUPPORT".
>>>>
>>>> I am not an active user of XEN in the Linux-kernel but I am willing to
>>>> test when Linux v6.12.6 is officially released and give feedback.
>>>>
>>> https://wiki.xenproject.org/wiki/Testing_Xen#Presence_test
>>> https://wiki.xenproject.org/wiki/Testing_Xen#Commands_for_presence_testing
>>>
>>> # apt install -t unstable xen-utils-4.17 -y
>>>
>>> # xl list
>>> Name                                        ID   Mem VCPUs      State   Time(s)
>>> Domain-0                                     0  7872     4     r-----     398.2
>>>
>>> Some basic tests LGTM - see also attached stuff.
>>>
>>> If you have any tests to recommend, let me know.
>> That itself is good enough as a smoke test.  Thankyou for trying it out.
>>
>> If you want something a bit more thorough, try
>> https://xenbits.xen.org/docs/xtf/  (Xen's self-tests)
>>
>> Grab and build it, and `./xtf-runner -aqq --host` will run a variety of
>> extra codepaths in dom0, without the effort of making/running full guests.
>>
>> ~Andrew
> Run on Debian 6.12.5 and my selfmade 6.12.5 and 6.12.6.
> All tests lead to a reboot in case of Debian or in my kernels to a shutdown.
>
> Can you recommend a specific test?

Oh, that's distinctly less good.

Start with just "example".  It's literally a hello world microkernel,
but the symptoms you're seeing is a dom0 crash, so it will likely
provoke it.

Do you have serial to the machine?  If so, boot Xen with `console=com1
com1=115200,8n1` (or com2, as appropriate).

If not and you've only got a regular screen, boot Xen with `vga=,keep
noreboot` (comma is important) which might leave enough information on
screen to get an idea of what's going on.

Full command line docs at
https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html

> dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner --list functional xsa | grep xsa-4
> test-pv64-xsa-444
> test-hvm64-xsa-451
> test-hvm64-xsa-454
>
> Is there no xsa-466 test?

No.  XSA-466 is really "well don't do that then if it matters".

More generally, not all XSAs are amenable to testing in this way.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Dec 20 01:49:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 01:49:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861606.1273566 (Exim 4.92)
	(envelope-from )
	id 1tOS8q-0008Fv-1O; Fri, 20 Dec 2024 01:49:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861606.1273566; Fri, 20 Dec 2024 01:49:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOS8p-0008Fo-Uq; Fri, 20 Dec 2024 01:49:23 +0000
Received: by outflank-mailman (input) for mailman id 861606;
 Fri, 20 Dec 2024 01:49: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 1tOS8o-0008Fg-9R
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 01:49:22 +0000
Received: from fout-a4-smtp.messagingengine.com
 (fout-a4-smtp.messagingengine.com [103.168.172.147])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9fe39b15-be74-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 02:49:18 +0100 (CET)
Received: from phl-compute-02.internal (phl-compute-02.phl.internal
 [10.202.2.42])
 by mailfout.phl.internal (Postfix) with ESMTP id 5F19C1380193
 for ; Thu, 19 Dec 2024 20:49:17 -0500 (EST)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-02.internal (MEProxy); Thu, 19 Dec 2024 20:49:17 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Thu, 19 Dec 2024 20:49:16 -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: 9fe39b15-be74-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=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=1734659357;
	 x=1734745757; bh=g14WTCMBoTbKiC3sBIPswkQshMBVMEBAMyalDlYrpzM=; b=
	hEK6Ijd+52TWbJIa+aEoikpmsfTPXENR+PkaBbIsu+szccQq/5/zY6ErXh0XvEeh
	b1GjFRiv9ghdiMW1R7LCN4HJUxvyM/F+JWRBo+8vOF3gyPnF9/3H4GrAd936PvI/
	QhlsL9Oj8kctUs+HLubHUO+pyqPD/XZREyBVIodL6VOQf7tynSKVhaT0ss02reGK
	U/Pm1BVOwwsqJNGrbiVMWEsk0r1RONCnujj9nAv6aMac0lqUCax9QqwqpVPM6ieo
	rYcR91z5p7C1WeJaBPZBI2QYgJ4wikFcTdFEkwvKlJg6xM4Qy+H0NLI2tTXGR1WX
	vRpLSFgl+nwETlRZt1GtDw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=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=
	1734659357; x=1734745757; bh=g14WTCMBoTbKiC3sBIPswkQshMBVMEBAMya
	lDlYrpzM=; b=DJaVvbNwUM7ns9+EaXl5MkX1XlVTpIgX3mzUPI2Nh/fnB/qRUO7
	LwaMfl7br7x2sjNkpxrwf1Ni5AT5+4MIH7ByDTwptnBynY36dZBre4G4SzvymUR/
	WPxUruacOUOBAhNXi7kFienOW5P5OoECJV0S1qroE2+qIhBDue6c/s5Lz2UHzxvB
	p6eR8YbtTLmyx6aGogibQxbPHt5Dafw+MpZrkvp3GFYdkPUIrpo0H22xL9Xtu8LO
	ISXdrdfNvO6WUmFQUs0b6WJo72q+xxI8gOiKnUuJZOS5wzIHG3mGRaV5T3eP5G4U
	wxefC+idDOAZQ2ZVCPSAOz70xIpFoxr/+gg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddruddtuddgfeekucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuf
    fkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhho
    fihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhih
    hnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepteevffeigffhkefhgfegfeff
    hfegveeikeettdfhheevieehieeitddugeefteffnecuvehluhhsthgvrhfuihiivgeptd
    enucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgv
    thhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepuddpmhhouggvpehsmhhtph
    houhhtpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgv
    tghtrdhorhhg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Fri, 20 Dec 2024 02:48:52 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel 
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0
Message-ID: 
References: 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="zbwhSu/fNdCZgdzp"
Content-Disposition: inline
In-Reply-To: 


--zbwhSu/fNdCZgdzp
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 20 Dec 2024 02:48:52 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel 
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0

On Thu, Dec 19, 2024 at 05:14:52PM +0100, Marek Marczykowski-G=C3=B3recki w=
rote:
> Hi,
>=20
> It crashes on boot like below, most of the times. But sometimes (rarely)
> it manages to stay alive. Below I'm pasting few of the crashes that look
> distinctly different, if you follow the links, you can find more of
> them. IMHO it looks like some memory corruption bug somewhere. I tested
> also Linux 6.13-rc2 before, and it had very similar issue.
>=20
> The traces below are all from nested virt (Xen inside KVM), tests with
> Xen directly on the hardware are still in progress. But -rc2 failed all
> of them too, so if it's the same issue, I guess they will looks similar.

Yes, on real hardware it crashes too.

I tried to enable KASAN, but that didn't worked out:

(XEN) d0 has maximum 416 PIRQs
(XEN) *** Building a PV Dom0 ***
(XEN)  Xen  kernel: 64-bit, lsb
(XEN)  Dom0 kernel: 64-bit, lsb, paddr 0x200000 -> 0x7600000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000260000000->0000000268000000 (1005377 pages to =
be allocated)
(XEN)  Init. ramdisk: 000000027d741000->000000027ffff207
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff80200000->ffffffff87600000
(XEN)  Phys-Mach map: 0000008000000000->0000008000800000
(XEN)  Start info:    ffffffff87600000->ffffffff876004b8
(XEN)  Page tables:   ffffffff87601000->ffffffff87640000
(XEN)  Boot stack:    ffffffff87640000->ffffffff87641000
(XEN)  TOTAL:         ffffffff80000000->ffffffff87800000
(XEN)  ENTRY ADDRESS: ffffffff8615da50
(XEN) Dom0 has maximum 2 VCPUs
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Scrubbing Free RAM in background
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input)
(XEN) Freed 684kB init memory
(XEN) d0v0 Unhandled: vec 14, #PF[0002]
(XEN) Pagetable walk from fffffbfff0900fc6:
(XEN)  L4[0x1f7] =3D 0000000000000000 ffffffffffffffff
(XEN) domain_crash_sync called from entry.S: fault at ffff82d0402ebdec x86_=
64/entry.S#create_bounce_frame+0x14c/0x170
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-4.19.0  x86_64  debug=3Dn  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e033:[]
(XEN) RFLAGS: 0000000000000286   EM: 1   CONTEXT: pv guest (d0v0)
(XEN) rax: ffffffff860d8000   rbx: ffffffff87600000   rcx: 00000000c0000101
(XEN) rdx: 3be9e05ee5ed7ef7   rsi: ffffffff87600000   rdi: fffffbfff0900fc6
(XEN) rbp: ffffffff84807f48   rsp: ffffffff84807df0   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: dffffc0000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 0000000000340660
(XEN) cr3: 0000000267601000   cr2: fffffbfff0900fc6
(XEN) fsb: 0000000000000000   gsb: ffffffff860d8000   gss: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=3Dffffffff84807df0:
(XEN)    00000000c0000101 0000000000000000 0000000000000002 ffffffff8614ff32
(XEN)    000000010000e030 0000000000010086 ffffffff84807e30 000000000000e02b
(XEN)    0000000041b58ab3 ffffffff845f8030 ffffffff8614fed0 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    ffffffff8615da6f 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000
(XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
(XEN) Resetting with ACPI MEMORY or I/O RESET_REG.

> Who should I CC here? The failures are all over the place... linux-mm?

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

--zbwhSu/fNdCZgdzp
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmdkzQQACgkQ24/THMrX
1ywbwAf+KGtSOL+7T1Z1s20XvozsBxcfgNEB2B/vBMva72uhAKPZV397RerlQcvK
SndSj4PmUrraltBC6qSPLU1juUnY9kgFLtzu12LfXn1Zss4IeiOsVxXYgKTOPbBv
rp2j5BmOaxvq33FoSgUUKMgzTNfH0W1bhg5Ihhd0/DbNiwxCOsc1VzVWVZqaIDgN
5gZTHqxXQ/VNaF1lvV7CN79CR9UX6FvO0a7+SulMpb2a580TE04j8t9cpUfbIU0k
MxOn6hziAlOmM8CJB+aNy8828XB85Dobl8Qpi1IYYXjYGXloAy0fddPEjo7RTSJZ
0/6sX1V2DU6z1vdqEI9NhSPdVHRLYw==
=Rl2t
-----END PGP SIGNATURE-----

--zbwhSu/fNdCZgdzp--


From xen-devel-bounces@lists.xenproject.org Fri Dec 20 06:06:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 06:06:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861615.1273577 (Exim 4.92)
	(envelope-from )
	id 1tOW9Y-0003vz-N5; Fri, 20 Dec 2024 06:06:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861615.1273577; Fri, 20 Dec 2024 06:06:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOW9Y-0003vs-Jm; Fri, 20 Dec 2024 06:06:24 +0000
Received: by outflank-mailman (input) for mailman id 861615;
 Fri, 20 Dec 2024 06:06: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 1tOW9W-0003vm-IX
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 06:06:23 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 8768f5d4-be98-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 07:06:19 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 20 Dec 2024 07:06:19 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 8768f5d4-be98-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734674780; x=1766210780;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=2RbFRUgw/qI9zihNzLR2Q2ojXC2qlL4c3ZQfciTB1hI=;
  b=caV6+td2pxVRTRTLgnUsLywWWvIxmv6NIFGQ0OkwcuZGM5oHIkPl/yM0
   H4bATC4cBSp+oPEdDU5X5s/PPUP7TRbXX/LwuNEN4+L5d9bpp/MLWCTSM
   8M9Tuw5oo44VjjWI2HYACt/u8y5wjmKs312Kwwneo6ppt2stdVB2OgehK
   0=;
X-CSE-ConnectionGUID: x7KDBgJ+RDmCofNbz/mOcQ==
X-CSE-MsgGUID: cat6bxRdT9+Hz3AwkC8aKA==
X-IronPort-AV: E=Sophos;i="6.12,249,1728943200"; 
   d="scan'208";a="28265590"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: <20241219231352.579D5C4CECE@smtp.kernel.org>
Content-Type: text/plain; charset="utf-8"
X-Forward: 88.183.119.157
References: <20241219231352.579D5C4CECE@smtp.kernel.org>
Date: Fri, 20 Dec 2024 07:06:18 +0100
Cc: mm-commits@vger.kernel.org, sstabellini@kernel.org, roger.pau@citrix.com, michal.orzel@amd.com, julien@xen.org, jbeulich@suse.com, anthony.perard@vates.tech, andrew.cooper3@citrix.com, stable@vger.kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
To: "Andrew Morton" 
MIME-Version: 1.0
Message-ID: <2f7a83-67650980-a2c7-5cf12280@54007280>
Subject: =?utf-8?q?Re=3A?= + =?utf-8?q?lib-remove-dead-code=2Epatch?= added to 
 mm-nonmm-unstable branch
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 2898

On Friday, December 20, 2024 00:13 CET, Andrew Morton  wrote:

>=20
> The patch titled
>      Subject: lib/inflate.c: remove dead code
> has been added to the -mm mm-nonmm-unstable branch.  Its filename is
>      lib-remove-dead-code.patch
>=20
> This patch will shortly appear at
>      https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/=
tree/patches/lib-remove-dead-code.patch
>=20
> This patch will later appear in the mm-nonmm-unstable branch at
>     git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
>=20
> Before you just go and hit "reply", please:
>    a) Consider who else should be cc'ed

Hello Andrew,

Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Cc: xen-devel@lists.xenproject.org

https://lore.kernel.org/lkml/20241219224645.749233-1-ariel.otilibili-an=
ieli@eurecom.fr/

Thank you,
Ariel
>    b) Prefer to cc a suitable mailing list as well
>    c) Ideally: find the original patch on the mailing list and do a
>       reply-to-all to that, adding suitable additional cc's
>=20
> *** Remember to use Documentation/process/submit-checklist.rst when t=
esting your code ***
>=20
> The -mm tree is included into linux-next via the mm-everything
> branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> and is updated there every 2-3 working days
>=20
> ------------------------------------------------------
> From: Ariel Otilibili 
> Subject: lib/inflate.c: remove dead code
> Date: Thu, 19 Dec 2024 10:21:12 +0100
>=20
> This is a follow up from a discussion in Xen:
>=20
> The if-statement tests that `res` is non-zero; meaning the case zero =
is
> never reached.
>=20
> Link: https://lore.kernel.org/all/7587b503-b2ca-4476-8dc9-e9683d4ca5f=
0@suse.com/
> Link: https://lkml.kernel.org/r/20241219092615.644642-2-ariel.otilibi=
li-anieli@eurecom.fr
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Ariel Otilibili 
> Suggested-by: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Anthony PERARD 
> Cc: Michal Orzel 
> Cc: Julien Grall 
> Cc: Roger Pau Monn=C3=A9 
> Cc: Stefano Stabellini 
> Signed-off-by: Andrew Morton 
> ---
>=20
>  lib/inflate.c |    2 --
>  1 file changed, 2 deletions(-)
>=20
> --- a/lib/inflate.c~lib-remove-dead-code
> +++ a/lib/inflate.c
> @@ -1257,8 +1257,6 @@ static int INIT gunzip(void)
>      /* Decompress */
>      if ((res =3D inflate())) {
>  	    switch (res) {
> -	    case 0:
> -		    break;
>  	    case 1:
>  		    error("invalid compressed format (err=3D1)");
>  		    break;
> =5F
>=20
> Patches currently in -mm which might be from ariel.otilibili-anieli@e=
urecom.fr are
>=20
> lib-remove-dead-code.patch
>



From xen-devel-bounces@lists.xenproject.org Fri Dec 20 07:10:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 07:10:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861622.1273587 (Exim 4.92)
	(envelope-from )
	id 1tOX9H-0003kC-2j; Fri, 20 Dec 2024 07:10:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861622.1273587; Fri, 20 Dec 2024 07:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOX9G-0003k5-Vl; Fri, 20 Dec 2024 07:10:10 +0000
Received: by outflank-mailman (input) for mailman id 861622;
 Fri, 20 Dec 2024 07: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 1tOX9F-0003gj-7c
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 07:10:09 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6f73a216-bea1-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 08:10:05 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 5B6545C596A;
 Fri, 20 Dec 2024 07:09:21 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5FF46C4CECD;
 Fri, 20 Dec 2024 07:10:02 +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: 6f73a216-bea1-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1734678603;
	bh=+Qa20dpz1k2c9j6vQ8UiCWd2lz481p5oFDkSS/B0hoA=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=J5NxcrqoUXs+GvMI+39Hg4JYtrYykJ4MertG5+Rp/4KqLmsmqf3i0g4Bsg2psaayn
	 igOHH0/xTMHnNuP4BeyO7QiLqh6oFhaVbzHRCb6Vi0c3m/A23xtwctJ6ymZ22lJkse
	 fa0qX/sqE5IeGXO3xSvmqLCOUx6IMHrMB7vA3Taw=
Date: Fri, 20 Dec 2024 08:09:59 +0100
From: Greg KH 
To: Ariel Otilibili 
Cc: linux-kernel@vger.kernel.org, Jan Beulich ,
	stable@vger.kernel.org, Andrew Morton ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 1/1] lib: Remove dead code
Message-ID: <2024122042-guidable-overhand-b8a9@gregkh>
References: <20241219092615.644642-1-ariel.otilibili-anieli@eurecom.fr>
 <20241219224645.749233-1-ariel.otilibili-anieli@eurecom.fr>
 <20241219224645.749233-2-ariel.otilibili-anieli@eurecom.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20241219224645.749233-2-ariel.otilibili-anieli@eurecom.fr>

On Thu, Dec 19, 2024 at 11:45:01PM +0100, Ariel Otilibili wrote:
> This is a follow up from a discussion in Xen:
> 
> The if-statement tests `res` is non-zero; meaning the case zero is never reached.
> 
> Link: https://lore.kernel.org/all/7587b503-b2ca-4476-8dc9-e9683d4ca5f0@suse.com/
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Suggested-by: Jan Beulich 
> Signed-off-by: Ariel Otilibili 
> --
> Cc: stable@vger.kernel.org

Why is "removing dead code" a stable kernel thing?

confused,

greg k-h


From xen-devel-bounces@lists.xenproject.org Fri Dec 20 07:33:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 07:33:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861629.1273598 (Exim 4.92)
	(envelope-from )
	id 1tOXVF-0006a6-RQ; Fri, 20 Dec 2024 07:32:53 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861629.1273598; Fri, 20 Dec 2024 07:32: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 1tOXVF-0006Zz-N9; Fri, 20 Dec 2024 07:32:53 +0000
Received: by outflank-mailman (input) for mailman id 861629;
 Fri, 20 Dec 2024 07:32: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 1tOXVE-0006Zt-60
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 07:32:52 +0000
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam02on2062e.outbound.protection.outlook.com
 [2a01:111:f403:2405::62e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9d6fb508-bea4-11ef-a0d8-8be0dac302b0;
 Fri, 20 Dec 2024 08:32:50 +0100 (CET)
Received: from SA1P222CA0043.NAMP222.PROD.OUTLOOK.COM (2603:10b6:806:2d0::17)
 by LV3PR12MB9236.namprd12.prod.outlook.com (2603:10b6:408:1a5::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.16; Fri, 20 Dec
 2024 07:32:47 +0000
Received: from SA2PEPF00003AEB.namprd02.prod.outlook.com
 (2603:10b6:806:2d0:cafe::4c) by SA1P222CA0043.outlook.office365.com
 (2603:10b6:806:2d0::17) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.24 via Frontend Transport; Fri,
 20 Dec 2024 07:32:47 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SA2PEPF00003AEB.mail.protection.outlook.com (10.167.248.11) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Fri, 20 Dec 2024 07:32:46 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) 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, 20 Dec
 2024 01:32:46 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 20 Dec 2024 01:32: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: 9d6fb508-bea4-11ef-a0d8-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=FxNPFgsauePVW0vzuiU3pGnuKEaYaYH3izg2OvoCKN4eb8K+/7wh7ULxCrxJ8Qh9DxcEOwwZEAMqI38UmFEOaku2MS1TT5LH4y0gQ4hKM5c2r9Nvg2Cx9C8ZZmu4U1Psq2rYWuw6ogwgPGOkZQx4hbhQdx2juXiFrNDs6i5wr8HbxrPkDUUF1EjuyqgotqOSCScrk5aIhuVUhTy63D3VxfKKc5AR0NqGua+H1pL9kRcsvBQ51oceu9yIiVMZQ46okhvYFehMcnieenzdRXTmvzaU/tL1bhCibgb07Fr0AqgGgx4IOkh0y9VZSpiLDjYaGNXfb1L+qX2h42DlD/vvvw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Wn0j2ifLlH9A9NOXGHhC/TuPhOJHo9dP+Mts/DDRek4=;
 b=JAfFaKjWIDk8LxABN/f3jsqM27vig3mHZQA3JQAIgaEfPPHV1zNJFEiK55Pgkj1vtN48nTwwj768OtrcJPSDvVx3Pq2/aZB+3UIJIAkcmBCYVy6xE5ol46UnJ2BEtBf6B2yBXVMSJ6nBoTNxZ4fzE7YFveKj7X78xR9mADChFtsXhT78maj2TIrcp7b5GSMDTEejDSyyc7hA/j7592mnLD568Bdmb7HaSq5dgPAQz1PH0QXm2sUtgXU30nC2eGDEQgkx3RVLMwoZGMcdNojj6/2YmUQRKzroh9lj2ipdbBb5E7FqKrZnCzFciTR0+fibtlEddtsbYHwRHDfGPc+vaQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=oss.nxp.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=Wn0j2ifLlH9A9NOXGHhC/TuPhOJHo9dP+Mts/DDRek4=;
 b=Nn0/rt7noTpEw9AX9FFxTWWapG/y2cLXjuUWxw/iiof+hPJv2OBon7qH+JZv1dGxcvETBTtCnFRgE0G07aJgccrNNZQbGiG6600Mt5/nrLT5B6UNDUSCFHvLpdeUm4wV1bbAC3i9VKiFBGjoKaa8XOrWs9Gn0Vtz1SySeLzCYuQ=
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=SATLEXMB04.amd.com; pr=C
Message-ID: <1b85e268-a06b-4e40-b652-99ffc874e10b@amd.com>
Date: Fri, 20 Dec 2024 08:32:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 0/6] xen/arm: Add support for S32CC platforms and
 LINFlexD UART
To: "Andrei Cherechesu (OSS)" ,
	
CC: , Andrei Cherechesu , Stefano
 Stabellini , Julien Grall , Bertrand
 Marquis , Volodymyr Babchuk
	, Oleksii Kurochko ,
	Community Manager , Andrew Cooper
	, Anthony PERARD , Jan
 Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
	
References: <20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF00003AEB:EE_|LV3PR12MB9236:EE_
X-MS-Office365-Filtering-Correlation-Id: 03409c1a-e05a-4c30-6efe-08dd20c88002
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|7416014|376014|36860700013|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?S2hiNmJPZzNlRkdNMHlKbUd4SjBhay9MSDZiTDFHUkZZaWkwWldQU3ZOQklP?=
 =?utf-8?B?a3RYMTV5RWtsb1hnS3Q1WGhVbklJVFpJamM1VmFFNFMrMW5BaFl6aU56aVRL?=
 =?utf-8?B?alE2NFprcTFyZmI5OGlZM1pIK1Q3UDc1ZnNINmtKTG5aQzhLWWZSREY3Vlhz?=
 =?utf-8?B?cG1VMlFvT1BvUkhMaG9XNkd0bEVqN1ZMMmtzV1BJMFlYMWhKZ01qdmJHTHRG?=
 =?utf-8?B?M0VqYXYvT0hMclk4Mnl1NUsvSTkzTG5od3IxWkdLb0tyUlFrL2l1T1BrditZ?=
 =?utf-8?B?dlRsdm1maTE3dkFySzhLdW1ZTlk4UFBIa1IzUy9yMC9nVEhPQVJwL0NFUFZT?=
 =?utf-8?B?Nkwyb0g1SzFvUmxPMVVJYzJSR1JidXZ1ZWY1VlVjazByQU5YRXYzVXdiSUxI?=
 =?utf-8?B?djNFYXVDc3p0MEQyQ1pwaHBjOE01RnBMT1FwL1RUMS9oWVFnVCsvSVoyT1Bu?=
 =?utf-8?B?STJ5ajNacHpHNkEwWllFY0Y2bUdOUGRPRlkwQndKZnZOUEI2UERDZVVNOE5z?=
 =?utf-8?B?Wm1laGJCNUtIcHg5aHlTZGNOUGh1V2xPcWdCN2s5VXRmY3YzbHRDWitabnVJ?=
 =?utf-8?B?Y3ZxNFZ2SlRNRGl4VklHRTFzalNXWGkyK0pmOU9rUDd6b3hOZGxZN2IwaExm?=
 =?utf-8?B?YlhaWitsK0R2WWNuUXdGQXE2SGxLNTVBZ1JWU2RnRnVpYTVVQk9uL0gxeFVu?=
 =?utf-8?B?SmhPQXdMb2p6WlhwM2hUNUhRTkdWRTlLWksyT2NwaGhWRG16Z3ZzRUdNNFZT?=
 =?utf-8?B?dEhsZFJlZklFdnJYMXVxYTFEOHFuOExOV25rZVMzTW9Fa2RRWkJ3T1I1cWho?=
 =?utf-8?B?VE0xNGxBZjR3ek55S1pXWmVOMG52MzUwK29veGZxOHRHOHZ4MzFQbExnRXFm?=
 =?utf-8?B?ZDFCK3U0ZFd3cmc1WGtqckk4RXRaVXhDUHlIS3ZQeDNsMHpiSjI1SW5HenhE?=
 =?utf-8?B?VW0ySGxwbTlWNWhROVErT0d5TC9TZUlsdFRjYkRWeWlsRjUzMndIamV3SHEz?=
 =?utf-8?B?OFBWN3JrcGxLZCtCcHZMYURHeDVqWDl1eEJJd0JIL3pDVHBlaHJyd3VtOXpp?=
 =?utf-8?B?WkUyUlVmRkZETFcwM0xPZUVUU1BTOUhjd1hJTXl0UzVvQXJNMzI4cmRZZWg3?=
 =?utf-8?B?NmNvaUpSbHYwazNGeVh0UFJjNjhXNElocWNOTGdGaC9kZ011Rk1jRnRoOG1P?=
 =?utf-8?B?SEVvMzgyajhYZXhMeWdwZjJXVTczbVA5RU9iZzlYdTNteXpJZUhGVzRhcDY3?=
 =?utf-8?B?ekF1a0d4cXYwd0V3Y3dyN3BuS09obkhpNHh3SkdiTk5yZSs4Z1Z3ajVvdzk4?=
 =?utf-8?B?NStsY0EyYldDazd0Zkk3dkRuSEplOUZ1elJGNCtvS1R6YjlySk1sR0xqVFdB?=
 =?utf-8?B?VWZXdThBVkxxeisvNnVMS3p1eFlCazB3Ui9ZRlVoQ1Z4SzYrQTI0eWtBdU02?=
 =?utf-8?B?VitCQVFKQzM4ekwxK21uci81TVJ0Ulp3NkdFRk9Wc2ZOOUhUNGQwTmZBUkRZ?=
 =?utf-8?B?UUZIK0V4TnNvSEE4a0hzYzcrODJtb1ZWTC9FOWVQeEZIQmsvNGx6am5YekJU?=
 =?utf-8?B?Tkp4ZlZrU21tWjdZd1R3SlNkMHFWR1ZySjlMZU5aVlNuUGtERnJoWkRWM1Y1?=
 =?utf-8?B?eEpya0FsbmI1YTJWV1JHaUlUVTlOdERHR0FyR3p2eW9jWmFzVjJQVTlEYXFC?=
 =?utf-8?B?anAyVHZWUVVYQjhvcGxLY3hwakhSVGtBN2hQN1JONWlyV2VocEYxaVNxTFlV?=
 =?utf-8?B?c05hZ1I0dWtGTzl1THRqbUVIM2hlSGJoenoxYk9zc045OEdxaFJmeXBETld2?=
 =?utf-8?B?cHZGRjE4dHZtYzNNWXpkVmQyaDhjMHdpcEZGcEJhOEdBcTY1WGsybDNwcmVC?=
 =?utf-8?B?cHpldmJrTHEyeUxDTHhKNnE3TmpMWi9lbXVHU2dtWkUvVm1wYjZmNXVBK1ZJ?=
 =?utf-8?B?Q2NhNGh6eTJ6NElac0ZrWFZCZkFVUG5pUVlKaVM2VmN3WCtMa0xqeCswNEdu?=
 =?utf-8?Q?QtnpHxeadhADE4gT8YuS+0eHUPlRok=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(376014)(36860700013)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Dec 2024 07:32:46.8732
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 03409c1a-e05a-4c30-6efe-08dd20c88002
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SA2PEPF00003AEB.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9236



On 19/12/2024 12:23, Andrei Cherechesu (OSS) wrote:
> 
> 
> From: Andrei Cherechesu 
> 
> Targeting: Xen 4.20
> This v4 version of this patch series finishes the work left to support NXP
> S32G3 Processors [0], part of the NXP S32CC Family. The LINFlexD UART support
> patches have been merged in v2. Platforms using S32G3 Processors are not
> affected by the TLBI by VA erratum (discussed in v2), and are security
> supported without a workaround needed in Xen or guests. The workaround needed
> for S32G2 [1] / S32R45 [2] will be addressed in future series.
> 
> The 1st patch introduces a generic mechanism for forwarding SCMI
> over SMC calls to firmware running at EL3, selected via
> CONFIG_SCMI_SMC. The 2nd patch refactors the SiP SMC handling in
> vSMC mechanism, to rely firstly on `platform_smc()` if implemented,
> then on the previously introduced generic SCMI handling/forwarding
> mechanism.
> 
> The 3rd patch adds S32G3 platform config to enable the required drivers for
> S32G3-based platforms.
> 
> The 4th, 5th and 6th patches modify the CHANGELOG.md, SUPPORT.md
> and MAINTAINERS files, respectively, to add mentions about LINFlexD
> UART support, S32G3 Processors support, and the new SCMI-SMC layer
> introduced.
> 
> [0] https://www.nxp.com/products/S32G3
> [1] https://www.nxp.com/products/S32G2
> [2] https://www.nxp.com/products/S32R45
> 
The series is now committed. Thanks.

~Michal



From xen-devel-bounces@lists.xenproject.org Fri Dec 20 07:34:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 07:34:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861652.1273651 (Exim 4.92)
	(envelope-from )
	id 1tOXXC-0007fH-Rs; Fri, 20 Dec 2024 07:34:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861652.1273651; Fri, 20 Dec 2024 07:34: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 1tOXXC-0007fA-PB; Fri, 20 Dec 2024 07:34:54 +0000
Received: by outflank-mailman (input) for mailman id 861652;
 Fri, 20 Dec 2024 07:34: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 1tOXXB-0007eu-S5
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 07:34:53 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on2062e.outbound.protection.outlook.com
 [2a01:111:f403:2416::62e])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e52c4494-bea4-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 08:34:51 +0100 (CET)
Received: from SN7PR04CA0161.namprd04.prod.outlook.com (2603:10b6:806:125::16)
 by IA1PR12MB6459.namprd12.prod.outlook.com (2603:10b6:208:3a9::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.14; Fri, 20 Dec
 2024 07:34:43 +0000
Received: from SA2PEPF00003AE7.namprd02.prod.outlook.com
 (2603:10b6:806:125:cafe::94) by SN7PR04CA0161.outlook.office365.com
 (2603:10b6:806:125::16) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8272.16 via Frontend Transport; Fri,
 20 Dec 2024 07:34:43 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SA2PEPF00003AE7.mail.protection.outlook.com (10.167.248.7) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Fri, 20 Dec 2024 07:34:42 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) 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, 20 Dec
 2024 01:34:42 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 20 Dec 2024 01:34: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: e52c4494-bea4-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=UzcVewO9216oveH4SvJ4dD6sBm/wILbaCZn71G0/RuwICuG4BCjhccmWbjdJy932zk1XC+BTHbjIHdbDDyYnvGJg2ufzOFetMLymmDHiVutqxFvElUTX57yG4Fw+5cqSEA+cAWGfCPBLFyXQpL0ILQvI4JFG466oT4ggqUINYUKS8RYMPKl8J2I0LRaJlBRbLl3j5AMyJMbRv4ehZsylXpMEuA5erWNHHLVj72aR2IGH60hkESZsh4J3VptAfuB+KeIqxkqw3Vm+5UV2ZpX7fNWC9nLJSy6IUu3LFJ6MfBjwWici6FQwDxnsTzOycMstPbjvrEYsASfKRKsEm+R4yg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2VMEixpDlPajZnnEZsgtj9QhLL0VDGS22c/b5M3I8ck=;
 b=HNJu+HqrIDvuqFlNNz52VJ/kRtzBPKZUQ3Oo6X2JUh20LUmfcnUMgYM+R4HqJUAX5kmuezG9pvM8vhiIDnNLBYZ1lMDebL9UvIFA4FMY/wpNCn08l+0QBFEgyX8hD61WE6CD064BUpYDiX0/130CWEKgHzUdMXcwUuGK0q79ncX9kjgNny68qj2PGhQ6RfzJznIavNnN3TdZ730TV0zp99U2M3mTXVdwVtYu3/smomSbTxVZ5Sl4Ipz2PgjiB2s7tcXDo/095AY8iUZgNoHav2C6p2B0sghq/bNHirFOFcM1i76PUDgblRhHt90GERnyKM80qNlXKiRhrqgWhe9TPA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=minervasys.tech smtp.mailfrom=amd.com;
 dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
 header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=2VMEixpDlPajZnnEZsgtj9QhLL0VDGS22c/b5M3I8ck=;
 b=kuT+FfZay3qGmk4xNQZ1X3xs7oz714Q220HldOCp/UDSVp1mK4PGu/TcftvFj/geyWzHux/nh3dNgFEZYz+3D/zdnk+iry8x8UwcM49edOaI6S1vvO1XqhFOjCkXRBA+YJdmHqzmDl+9aQuSdfU+iP2nwnu12LJ1x6ecpZQn5aY=
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=SATLEXMB04.amd.com; pr=C
Message-ID: <143392d7-220d-48e4-8565-8ecdba9111e9@amd.com>
Date: Fri, 20 Dec 2024 08:34:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v13 00/12] Arm cache coloring
To: Carlo Nonato ,
	
CC: , , Andrew
 Cooper , Anthony PERARD
	, Jan Beulich , Julien Grall
	, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
	Stefano Stabellini , Bertrand Marquis
	, Volodymyr Babchuk ,
	Nick Rosbrook , George Dunlap ,
	Juergen Gross 
References: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <20241217170637.233097-1-carlo.nonato@minervasys.tech>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF00003AE7:EE_|IA1PR12MB6459:EE_
X-MS-Office365-Filtering-Correlation-Id: 3791b7b5-7daa-442e-d8e6-08dd20c8c511
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|36860700013|376014|7416014|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?OEliS2kwTDhrTHd4Y3FmMzdIZzY4eTMyQ09GK3R1Y2Jaa0ppSTNIV1dXd0gz?=
 =?utf-8?B?bVA0MGlXaHJtUUZPYjR4TGNFUmxMbGJGVnBjaVgxVWhLUjBUWXhwMnhqQzNK?=
 =?utf-8?B?bzRRcEQvcmFRQVQ3SnlRc3QrUGN4WW9mUGFvcFBYdTBnQjlxZ28rWWxpUFgv?=
 =?utf-8?B?eFFsZUMySDdsckpQOHFnaFNYRUFMWTc3UXY2Zkg5VjNFMlpVa2MwajVjRmdK?=
 =?utf-8?B?enF3NG1ZZFozcWY2TjFpTFFxUzB0d1Bjb1h3SXJURStmVnZDWE9zREwvb0p1?=
 =?utf-8?B?amNiVjRTZkJWTThlbUVoTWw5ang1dHY1UjFoQkpQTFhiM3NiVjMzRFBqTkMy?=
 =?utf-8?B?OWd3a2V1aUJacFRrSldKWFNEZ3hQNTN2NlVyRUwvZ1VTTGFMU05uSlZYQnMz?=
 =?utf-8?B?R3pKZDNvcVBrbERPdzlCZGV0QlpXZ3VmZms2K0J1WkZHQ0hWVEx5KzNsZEZo?=
 =?utf-8?B?ZjBSTEpNdldmTkRnMkJvV083cllyQVNyQ3FZLzVnNGdBYjJnOWN1WncwZm90?=
 =?utf-8?B?ajVLb1JlRHZ4S2lBR1hXZ1cwOVUwQVlJZGxjSHkyS1VNYVFKL0t6ZjZvN3d1?=
 =?utf-8?B?d3hkc1NqdG1WQ0sxckxyZTlNbTJHSGlLVXo0SDE3K1pNUWw1RlE1Yy96V0R3?=
 =?utf-8?B?QVQ1SDdreDNwdk5RWkpPMlQyRHZvb044RVVhSHpDVXozMlh6KzVPQkxZZDFB?=
 =?utf-8?B?RXBsSnBZU0dJdXlvMTEwSnE4cy9LTmF6UmltNWppZjhIOTQ3SnYxMTJmR29I?=
 =?utf-8?B?b2tLenhZWTdHL0hzSDdKU2VVT2RiMTJ3d2o2c3pMbG5LZlJ4UmJuTk9wS2pv?=
 =?utf-8?B?TVVzSmJQREpieHBHbU8vRzBTb05OVlY5M1YwN0NNM3NQY3VGV0ZEQnBYL1R6?=
 =?utf-8?B?cXh0QXJxK05zSE84RkdNcFdnNUdZL0M5ZTJLQXI1ZEV6YkJ2RElVdENqYjBW?=
 =?utf-8?B?NCt6S0dCaGFhQVhGNW1EM1c0WjZodmxKR3FPU2lKSk01NjJ1SFZnVlFRK21Q?=
 =?utf-8?B?eEYyemZ2ZlpQMDRoTFJ0NCtuWlJkcmZaU3grQU41S20vUVlLNEVMR0lXekZn?=
 =?utf-8?B?U0daSDRwdm1ENUh3YjNHYWkwYVUrNjhtNC9GVVRiYzlCdE1jYkQwOWQwdXFn?=
 =?utf-8?B?RVVvL1FPN1htbVN6VkgwM1VCRUF6TXIvTHdwcEtJRkt1dHI1WjFUaDVocWxE?=
 =?utf-8?B?M1hlVVM3YzRvQThPSDBZZC93WUNkUGFubWp0c085T0RhTVhXOXF3MzcwZ1dR?=
 =?utf-8?B?aEJMaGxEQUlTaUdhZ2hXZ3lBZXpFSmpmd3ppT2x4T2p1UHlDRFFMdm8xSkZU?=
 =?utf-8?B?T3lRcUpndDVxZlBpdVhQVENRMkdBZ1g1ZUdjUVBBM1BZdHlVSURVZ2cyYjNt?=
 =?utf-8?B?dUUwaEJDV2ZXOHRhSDBkblVxcFo2WVNxR2FxVnNTLzQ3UENCWHhLS1FvRUli?=
 =?utf-8?B?SlFjeUh4cVNFbHJMMWpEZFNZdzRBQ044OWNwQjYrQTMzYU45a0c2N1g5ZVZW?=
 =?utf-8?B?a3RlZUYxMGlvUTUxY1I4SDF4UmpDMFZIY0RzaEZOYS82b0ptSGZqeEtDakJE?=
 =?utf-8?B?OGxRWFZ0L0hzTGFSQ2V3L0tEVkZDS1I1KzlkUUhWbVUrZWtjRXlYWmNrOGFn?=
 =?utf-8?B?SGFwdllLWUJCTzlBMWx4czNCYW0ySnZuaG5kVmtWUUowN1ZNSmhiUXZKV09H?=
 =?utf-8?B?dk9YeXRJV3NxVlJDbG5sYlk1Vng4aHBlbDRFT3RWdGJrUEtCVXB4TDJCeWl5?=
 =?utf-8?B?cnJJMUVwQWczUTNOanlNeTNkNVFkSjhkSktTZkZ3NGl0K1oyUTJpQzROaWdX?=
 =?utf-8?B?dTI4bnlwU1pUcGhiT1FONFdCWWVZUml1SkMxejRzcTBBNDF3VjNteGxvV2Zx?=
 =?utf-8?B?UTZSVjg5RzJtaWFpeXB5d0JvdFhMTFRWMWVnYmdGbkhvcyt0Q1FjZW9TRFNE?=
 =?utf-8?B?dFBDanVKY1RVL2p4U3hNeG1TdUxmQ1BRM0d5WmJVNFNJUHQ3Y1N6VTJWSzFr?=
 =?utf-8?Q?9GaZeeToHNSZPnG3qOgqjpLhCJksN0=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(7416014)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Dec 2024 07:34:42.7526
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3791b7b5-7daa-442e-d8e6-08dd20c8c511
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SA2PEPF00003AE7.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6459



On 17/12/2024 18:06, Carlo Nonato wrote:
> 
> 
> Shared caches in multi-core CPU architectures represent a problem for
> predictability of memory access latency. This jeopardizes applicability
> of many Arm platform in real-time critical and mixed-criticality
> scenarios. We introduce support for cache partitioning with page
> coloring, a transparent software technique that enables isolation
> between domains and Xen, and thus avoids cache interference.
> 
> When creating a domain, a simple syntax (e.g. `0-3` or `4-11`) allows
> the user to define assignments of cache partitions ids, called colors,
> where assigning different colors guarantees no mutual eviction on cache
> will ever happen. This instructs the Xen memory allocator to provide
> the i-th color assignee only with pages that maps to color i, i.e. that
> are indexed in the i-th cache partition.
> 
> The proposed implementation supports the dom0less feature.
> The proposed implementation doesn't support the static-mem feature.
> The solution has been tested in several scenarios, including Xilinx Zynq
> MPSoCs.
> 
> Carlo Nonato (11):
>   xen/common: add cache coloring common code
>   xen/arm: add initial support for LLC coloring on arm64
>   xen/arm: permit non direct-mapped Dom0 construction
>   xen/arm: add Dom0 cache coloring support
>   xen: extend domctl interface for cache coloring
>   tools: add support for cache coloring configuration
>   xen/arm: add support for cache coloring configuration via device-tree
>   xen/page_alloc: introduce preserved page flags macro
>   xen: add cache coloring allocator for domains
>   xen/arm: make consider_modules() available for xen relocation
>   xen/arm: add cache coloring support for Xen image
> 
> Luca Miccio (1):
>   xen/arm: add Xen cache colors command line parameter
The series is now committed. Thanks.

It's definitely a change that wants mentioning in CHANGELOG. I'll send a patch
to add a note shortly.

~Michal



From xen-devel-bounces@lists.xenproject.org Fri Dec 20 08:20:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 08:20:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861675.1273685 (Exim 4.92)
	(envelope-from )
	id 1tOYEm-0005Ry-Dv; Fri, 20 Dec 2024 08:19:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861675.1273685; Fri, 20 Dec 2024 08:19:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOYEm-0005Rr-At; Fri, 20 Dec 2024 08:19:56 +0000
Received: by outflank-mailman (input) for mailman id 861675;
 Fri, 20 Dec 2024 08:19: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 1tOYEl-0005Rl-0L
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 08:19:55 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam11on20613.outbound.protection.outlook.com
 [2a01:111:f403:2416::613])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 2fa3e12f-beab-11ef-a0d8-8be0dac302b0;
 Fri, 20 Dec 2024 09:19:53 +0100 (CET)
Received: from CH2PR19CA0025.namprd19.prod.outlook.com (2603:10b6:610:4d::35)
 by BY5PR12MB4275.namprd12.prod.outlook.com (2603:10b6:a03:20a::18)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.14; Fri, 20 Dec
 2024 08:19:48 +0000
Received: from CH2PEPF0000009A.namprd02.prod.outlook.com
 (2603:10b6:610:4d:cafe::45) by CH2PR19CA0025.outlook.office365.com
 (2603:10b6:610:4d::35) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.23 via Frontend Transport; Fri,
 20 Dec 2024 08:19:48 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH2PEPF0000009A.mail.protection.outlook.com (10.167.244.22) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Fri, 20 Dec 2024 08:19:47 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 20 Dec
 2024 02:19:46 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) 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; Fri, 20 Dec
 2024 02:19:46 -0600
Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by
 SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39
 via Frontend Transport; Fri, 20 Dec 2024 02:19: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: 2fa3e12f-beab-11ef-a0d8-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=eFum/HCCOlr8MgfWgyTHRY9qJCFCOp6O6o2lWOcrjBQlMu7fn6k3wTg2mSX6rO+8I8MwR1o+gA4hp7Ag0lVCDwfgl5CBy0Kj+tnMApjNbacG5+F0BPw0EP8C71YQWo5u+I2ojQBgJy5kNF2MrSw/3DqsR1NvIy13UfavnWGZ7mOEEUumz4TFfE8x9CRPFSbISZhSxLwCpTeeY6QHWdxQ+okWS6lf00BIn2iu0A/yUuX3D/D9R1WA/K9IHsxgxxLFYNuoqaPaZC/qJOSnye7L7OKTjssAfU5dfy+S5d/YNIot47Y/3neA0ZhiNrEpFL3nvpZgIJUOxxoCuecHQVKlZA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sjFwPdlJKALonDUST0I3yiYbwt/LgZZy+CdxllRTzJo=;
 b=ZQ8dhbu7EkXCC59UOSemS2dAW6Bxd8lcdwNJBdKR73DTfKEegoxcvblrQiiJZf3nz6UDySBN8hDrFI3ASzIT19vl894nyHfMRZ9k6ZRSZC211IVY29INk/o5XajJyunbBMAZVbRR71hYw5UeZdITR/uKCSPT0VjWrC4aSTnSfh81urD0X5UQBMfKLoQSE985oICkV1oHKHE22900nUe5tiQSnED7/RSOXg/H+T6O+6Fr4sDN42LcBdCrRFZqVZ/6k5G3La5NiNvr3mbPUhKgcQrWpOJjVOET88LRZUzsXk7NThsq+yB43y+wDEXeOhGjFeSTWc0ALPsE25y/VXdjvg==
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=sjFwPdlJKALonDUST0I3yiYbwt/LgZZy+CdxllRTzJo=;
 b=2U3O2wgdcjVlQtEwnWyv6fog5VJPVd1ozFlZ6mYa32CIs5YKGYUw3JpsLmW023EehyKk/WRhNHO+ZcEwhSmCyqg9lTmZzOQrQmOmk/kWNWbFmMv+fJQjueN9ATdF6s2Y/TftD6+1vIjVfO/leOh3s4SH9vkhIWKZtqO0RZkcsLs=
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=SATLEXMB03.amd.com; pr=C
From: Michal Orzel 
To: 
CC: Michal Orzel , Oleksii Kurochko
	, , "Community
 Manager" 
Subject: [PATCH] CHANGELOG: Mention LLC coloring feature on Arm
Date: Fri, 20 Dec 2024 09:19:40 +0100
Message-ID: <20241220081940.7954-1-michal.orzel@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: CH2PEPF0000009A:EE_|BY5PR12MB4275:EE_
X-MS-Office365-Filtering-Correlation-Id: e610a6b0-993c-44cd-1b25-08dd20cf1137
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|82310400026|1800799024;
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?RFyu7mWm+YP7d7c2FUPzgkmAuFiBs2n7XTzYoptb5GsEgpp1hpj8A/mQa9GI?=
 =?us-ascii?Q?r6HR5V7xKygDY1L/c9uWNqVLw5nLdiQ8vMi7xvsdjNFY0t14zqfnDBqmeNu+?=
 =?us-ascii?Q?zOEtdlSs+IycLIvl02nH+G5kV17ykj852b7xBky4gtmoeTjIEJwioUvj6Fay?=
 =?us-ascii?Q?DGkaReurTMfANwn1Wt+gQOhXA4v+wyPy16rn4rW4p1cnOxwPigYQfaslzeYZ?=
 =?us-ascii?Q?DCBscQWkf5akx4v5Sdj0iTxDaeh5mEnc619/xBmBPM5qQXkpYgVXhwL86Kzx?=
 =?us-ascii?Q?vbOl587WozrOOMOYywdI7C/L0lZRHlKnSprfl3DIEvJxYXn56RStj6+p+I3B?=
 =?us-ascii?Q?UBl1UmChvMyZ1vVGZVIHAMEsq5M4jdxtDHnSqHS/WZSWRJx2XXvTnUzQwpcH?=
 =?us-ascii?Q?QZhhqc8500zGqlbaogOaCGRm2ChfhyRp1ezN5U2w3YPai0GMGE581QZ+b8PV?=
 =?us-ascii?Q?8P67wGpUZNUnVM2PXBFxz2FReQB4l0KdAyvYBNcj9Hv8YM/40ydlz//Ae/cR?=
 =?us-ascii?Q?Z2oiPOKS1XATI8TNmgk6cehj4IoL2OMBAUadxC0scemYJ1dfQ38gcVQCBQVS?=
 =?us-ascii?Q?/f6QqgfWywueQ3gN/ulK7DvlyafgsRtDwhZUb5mtvpRph2IxA1JAY2RhV94O?=
 =?us-ascii?Q?vTVDhPfDXeT0fNzIoITlu4F2Pj4HlnxZDOZyoYDV0Jpl+vcldgOHPKvOG0Sc?=
 =?us-ascii?Q?MI6SN3gXaxNYtyGreWyIF6iZ2rseTtft7WDjdRLzjMKUpTKrH/jv+aNaoiKb?=
 =?us-ascii?Q?9Jy8swEvzqi1BMl59D7ai/qLMWctuHJuovDUfY6rksbKIaH3lt4608ruLHuj?=
 =?us-ascii?Q?Fxa65muePT9ZQ8PLwAiW3f3R0nhjqONbNLx+hxLZOzIxi/nh7cm5hK/nG9/y?=
 =?us-ascii?Q?JHGpUvsRbA9MfDb2SfYMlCUH+8SEX0LWnL9Z/qIwCL6P8s3+KcN59zsW0qDf?=
 =?us-ascii?Q?gdSchB3FBEpu8ycbU5wciCsqMw2IWhxjg1Z+pz8WI9JdC8iGGRer+ZveeK5R?=
 =?us-ascii?Q?EYDoSzBDWM7c8huTWzpdIcYrhpfOJjktP8n2W77sU71PKzqbDO/1lyJiZkdD?=
 =?us-ascii?Q?fqJwBl5ZxI9deq3X5cn8xdZ//FKnNY4j1O4ZQ7m5rm2vVUARmTRnSPmj19Cd?=
 =?us-ascii?Q?jAqxa34jwDTyks5h0fftiiOKi9cEh0wMSOREpdQEWz4/VIYLaHEchM0vnn6h?=
 =?us-ascii?Q?24ps8BPTb785AjRJCdgd7AzfX2fapdCx/T6jkpHLWWbiov3N0yPXRwNGp83h?=
 =?us-ascii?Q?lHBcfeTQL+1rqdhh/ERXkZChujYJzjt8rmdA94EmIy9IfdgnN6N18nE+FPuK?=
 =?us-ascii?Q?qrJJpMX8s7XSK8Vd7dpC/K5H2tueOWhS+D4emgSWnpsQu3jk9m6kp9AoXPFw?=
 =?us-ascii?Q?T/WSAoio2S8/SSMacj4NDJ5DFATDdbx6OEYld9Dh4kN0Kz0UW6NjzWhJmG4Z?=
 =?us-ascii?Q?4GcNQoiBIyc=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(82310400026)(1800799024);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Dec 2024 08:19:47.4840
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e610a6b0-993c-44cd-1b25-08dd20cf1137
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF0000009A.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4275

It's definitely worth mentioning as one of the most notable feature on
Arm this release.

Signed-off-by: Michal Orzel 
---
 CHANGELOG.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index fe6c4cf9432e..8507e6556a56 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -21,6 +21,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    - Support for NXP S32G3 Processors Family and NXP LINFlexD UART driver.
    - Basic handling for SCMI requests over SMC using Shared Memory, by allowing
      forwarding the calls to EL3 FW if coming from hwdom.
+   - Support for LLC (Last Level Cache) coloring.
  - On x86:
    - xl suspend/resume subcommands.
 
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri Dec 20 08:27:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 08:27:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861699.1273762 (Exim 4.92)
	(envelope-from )
	id 1tOYM2-0007sr-VT; Fri, 20 Dec 2024 08:27:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861699.1273762; Fri, 20 Dec 2024 08:27: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 1tOYM2-0007sk-Sy; Fri, 20 Dec 2024 08:27:26 +0000
Received: by outflank-mailman (input) for mailman id 861699;
 Fri, 20 Dec 2024 08:27: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 1tOYM1-0007se-Td
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 08:27:26 +0000
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com
 [2a00:1450:4864:20::131])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 3d044658-beac-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 09:27:24 +0100 (CET)
Received: by mail-lf1-x131.google.com with SMTP id
 2adb3069b0e04-53df6322ea7so1944861e87.0
 for ; Fri, 20 Dec 2024 00:27:24 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-542238216ffsm406145e87.209.2024.12.20.00.27.22
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 20 Dec 2024 00:27: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: 3d044658-beac-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734683243; x=1735288043; 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=+g8j/yNIC3Ej+QWktUVcZXAr/OOGVXyE4CaI5JDFJms=;
        b=GkHxpA5WJyV1dtanQL38nXzQzagFuSp3r3ZCLvudPUylrHnHt+T4hXPPpX+7j/TDSU
         4Ap+1LqU5N1k4AlTaqqRfCKcnVIi3FFSGZRmuGDzf1TaBqzG63EXC1aXcBoF4ARwTkl9
         /ivPEZUwEWkUh6x+yimgeAgxO1ZDWox6CglqTY8wcHPAktLNbdVDfNHNv2j03EBQ0WxV
         2H1sZ8bbNxxMqkA3MfczTUZAw93YaWQVmmBbsNxOQ4JuClhShEr1h0xUGh7WeJx9a8EN
         ATUaLVMY7+OJMURt7/eJG1U/NzDORRuLhAVBw3/XvAu6qqmRlJvNT9TaMqaq34KpJFHe
         5lkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734683243; x=1735288043;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=+g8j/yNIC3Ej+QWktUVcZXAr/OOGVXyE4CaI5JDFJms=;
        b=UJtqi7815KREUH9gqkRpn/zukN3KWHeo9x9yQksEp6vzwu9XA9qQYkUD8xVeSNEZgL
         nHcUheqCrrCRAf0sKkDq4yQ+oNcY2KUL7DOrwVEVa1F1SsX4Wc/VPHQfclPu8uE363cz
         b5lhSy/VVOXeQBYUsWaKeRfMMZZt076f/R7C/l5nFlDtw0oaXWg6eZQWUYQayIa0JLX3
         Hg/r8JqKPoiXR73AiJnd+DauU7HF19tpYi4K32qykIIKTrb4+nOKI5nxHVv803mKZz3W
         X6u7f2LCxP97nXZvU7N5mbKz7SRLQcZV4z92JII/I994uZmnDnnIi9tTe9DhEWFOj3NI
         DCsg==
X-Forwarded-Encrypted: i=1; AJvYcCUiwD17MyHjYzpc+RhoqGBryKXuKA9Ze71mDlufjSeGbKPimDjRAiBmj3cs04eylMGf9kjOMJhQYXs=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwNDk2epMTHj7pa/GSrfqqWmGISxBJkJFW9YRWe7XQwdlRRSNVw
	o5Kc1WrxoVUmQOpiufF5LTaqBJPYqLp962PBJgBfHxj7DLn33hvH
X-Gm-Gg: ASbGncsA4mWLyRi1c+gYmpwZEI6LWvD/+MavpNqFLhWOiuYsRZ1ghpKK24SLDgbJf3H
	stQAj8dx2DLRW/N9trzdkjcPzS/CZ9SjlEH+qbEI9nCdQm133pgm+PLj6EG/4+PiOHtuAG8EIIX
	gQLCTQ2g/o1SeYJNDjtRAW1oE+K4m95fklTn1Yq4igQUNZwE6X+kR8ylM84apVbnO6be9ku2XtA
	S1PmFPFfUc6V7bhPVQnqmHSSGw/0ISpIlXCw9VzJnPedgVztpx/NcDOw81Mz7bT37uLKQ==
X-Google-Smtp-Source: AGHT+IFnMzDMq7dkcD5KzBUoya9u+7oxp1nZQe2rogPWFf3lnl0/hfFvTmS4rgyXGbjyVgwGKsuY2w==
X-Received: by 2002:a05:6512:ba3:b0:540:2542:d89a with SMTP id 2adb3069b0e04-5422959cf51mr469517e87.52.1734683243046;
        Fri, 20 Dec 2024 00:27:23 -0800 (PST)
Message-ID: 
Date: Fri, 20 Dec 2024 09:27:22 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] CHANGELOG: Mention LLC coloring feature on Arm
To: Michal Orzel , xen-devel@lists.xenproject.org
Cc: carlo.nonato@minervasys.tech,
 Community Manager 
References: <20241220081940.7954-1-michal.orzel@amd.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <20241220081940.7954-1-michal.orzel@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 12/20/24 9:19 AM, Michal Orzel wrote:
> It's definitely worth mentioning as one of the most notable feature on
> Arm this release.

Totally agree with that.

Acked-by: Oleksii Kurochko 


Thanks.


~ Oleksii

>
> Signed-off-by: Michal Orzel 
> ---
>   CHANGELOG.md | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index fe6c4cf9432e..8507e6556a56 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -21,6 +21,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>      - Support for NXP S32G3 Processors Family and NXP LINFlexD UART driver.
>      - Basic handling for SCMI requests over SMC using Shared Memory, by allowing
>        forwarding the calls to EL3 FW if coming from hwdom.
> +   - Support for LLC (Last Level Cache) coloring.
>    - On x86:
>      - xl suspend/resume subcommands.
>   


From xen-devel-bounces@lists.xenproject.org Fri Dec 20 08:43:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 08:43:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861709.1273772 (Exim 4.92)
	(envelope-from )
	id 1tOYbN-0002UD-7A; Fri, 20 Dec 2024 08:43:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861709.1273772; Fri, 20 Dec 2024 08:43:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOYbN-0002U6-4T; Fri, 20 Dec 2024 08:43:17 +0000
Received: by outflank-mailman (input) for mailman id 861709;
 Fri, 20 Dec 2024 08:43: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 1tOYbM-0002U0-3A
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 08:43:16 +0000
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com
 [2607:f8b0:4864:20::d35])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 729f5915-beae-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 09:43:13 +0100 (CET)
Received: by mail-io1-xd35.google.com with SMTP id
 ca18e2360f4ac-84435dbda4bso96000939f.0
 for ; Fri, 20 Dec 2024 00:43:13 -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: 729f5915-beae-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1734684192; x=1735288992; 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=KZ8Lj6sL9X1MkJsL21Fctkn6bIT0AaBSOcCMGB/RwrQ=;
        b=xL5TV3SGBPHg5f+S8fQOJGw/2uyxk5yoJKSDFAf0NDMFxBlIaX+GGA5qv4eMSo8ukd
         +6MLN5IZwHB53pgfklIfnVyAP6QwYDZ5plEPOnmYsDoVySjucF5DoiBNVR21fYi3na0X
         X4OYZv+eD+uUjXsMDKylWC0rYspb79iY3aUDbRapaYyrHTMF5v3FLItWVGTToWz6GKQl
         qpNYGzHQrjA8TiGGqQgvN7xho4JYocChNTSAcnMkIS6W3NTpguWmiCo4IVZ6wQ1y47DK
         OweijcoxnkifszO1zXaBpWqB+38SS1VQno/BiLJtrdZnQ0FR0xChUBAdC1PeApkLha4R
         kXPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734684192; x=1735288992;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=KZ8Lj6sL9X1MkJsL21Fctkn6bIT0AaBSOcCMGB/RwrQ=;
        b=SNUR1xgoWS+z0FGm6NbFimMkmCmcMStPuogn3MGJUMic8xZmJquLU/smkbrPIwIFRD
         tP2GcWe2fI6LzW6TvNBLgHC0XGmUZGvHnOh8Wc+FvRGmOn4yWi1DcvnpW/nDOReiDgeP
         eyLkccrZLwTJCM65/tqUv4KTJdo3pef/hlCK2/wIfSm+mgm7gKROkt8qXG6+GH/MZkN9
         gxrt0XJhLzPjpkMTOfgDviO538SY0K8JvNZtyXxIgutHvB//AyzHvCQhsCkH3NTekvr0
         XHx5S+xH4EOK0nXHR+DdhFWRy/Adn8ZZdZQS3lGpC1F9QwNF0VUj4MhNnEm2vM46tyMn
         ZKzw==
X-Gm-Message-State: AOJu0Yw72L9r/eQp3fAR3X5aMQ97N5TVRW/UQPnSJ4W0j1aP6qeUkWBn
	zNUjycaMJi68hYBOyAQYeNSz31ChfjZfzW4LJEYSwosADCzdZyXE6/tcAxgWfycWWv1bXip1PjH
	dGah1zHJiRwAY7RB+HueERXB9QuYgXxrJsSXw1Q==
X-Gm-Gg: ASbGncvCPCHa4fXCMbZIZaPYEBxzrPAeICDFbFM6HtI4A8zbURpXm+qHoCxpEtjYiBi
	bDSRc3ED3GPK9K6OTmIrwqYUZWjk2EcH0GJvH8A==
X-Google-Smtp-Source: AGHT+IGYhumv0jtFb1tOThICjXnTv5BJinzxcXGE+38KQo78+Ccc+/q1aSllvM9RF8DCpPkXcG9LoZKCEmjrknBv0OA=
X-Received: by 2002:a05:6e02:190a:b0:3a7:e786:afb4 with SMTP id
 e9e14a558f8ab-3c2fe53a57cmr13835145ab.2.1734684192227; Fri, 20 Dec 2024
 00:43:12 -0800 (PST)
MIME-Version: 1.0
References: <20241217170637.233097-1-carlo.nonato@minervasys.tech> <143392d7-220d-48e4-8565-8ecdba9111e9@amd.com>
In-Reply-To: <143392d7-220d-48e4-8565-8ecdba9111e9@amd.com>
From: Carlo Nonato 
Date: Fri, 20 Dec 2024 09:43:01 +0100
Message-ID: 
Subject: Re: [PATCH v13 00/12] Arm cache coloring
To: Michal Orzel 
Cc: xen-devel@lists.xenproject.org, andrea.bastoni@minervasys.tech, 
	marco.solieri@minervasys.tech, Andrew Cooper , 
	Anthony PERARD , Jan Beulich , 
	Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	Stefano Stabellini , Bertrand Marquis , 
	Volodymyr Babchuk , Nick Rosbrook , 
	George Dunlap , Juergen Gross 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 20, 2024 at 8:34=E2=80=AFAM Michal Orzel =
 wrote:
>
> On 17/12/2024 18:06, Carlo Nonato wrote:
> >
> > Shared caches in multi-core CPU architectures represent a problem for
> > predictability of memory access latency. This jeopardizes applicability
> > of many Arm platform in real-time critical and mixed-criticality
> > scenarios. We introduce support for cache partitioning with page
> > coloring, a transparent software technique that enables isolation
> > between domains and Xen, and thus avoids cache interference.
> >
> > When creating a domain, a simple syntax (e.g. `0-3` or `4-11`) allows
> > the user to define assignments of cache partitions ids, called colors,
> > where assigning different colors guarantees no mutual eviction on cache
> > will ever happen. This instructs the Xen memory allocator to provide
> > the i-th color assignee only with pages that maps to color i, i.e. that
> > are indexed in the i-th cache partition.
> >
> > The proposed implementation supports the dom0less feature.
> > The proposed implementation doesn't support the static-mem feature.
> > The solution has been tested in several scenarios, including Xilinx Zyn=
q
> > MPSoCs.
> >
> > Carlo Nonato (11):
> >   xen/common: add cache coloring common code
> >   xen/arm: add initial support for LLC coloring on arm64
> >   xen/arm: permit non direct-mapped Dom0 construction
> >   xen/arm: add Dom0 cache coloring support
> >   xen: extend domctl interface for cache coloring
> >   tools: add support for cache coloring configuration
> >   xen/arm: add support for cache coloring configuration via device-tree
> >   xen/page_alloc: introduce preserved page flags macro
> >   xen: add cache coloring allocator for domains
> >   xen/arm: make consider_modules() available for xen relocation
> >   xen/arm: add cache coloring support for Xen image
> >
> > Luca Miccio (1):
> >   xen/arm: add Xen cache colors command line parameter
> The series is now committed. Thanks.
>
> It's definitely a change that wants mentioning in CHANGELOG. I'll send a =
patch
> to add a note shortly.

Grazie (thanks in italian), to you and the other maintainers that helped.

- Carlo


From xen-devel-bounces@lists.xenproject.org Fri Dec 20 08:44:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 08:44:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861717.1273783 (Exim 4.92)
	(envelope-from )
	id 1tOYcc-00034i-L3; Fri, 20 Dec 2024 08:44:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861717.1273783; Fri, 20 Dec 2024 08:44:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOYcc-00034b-H7; Fri, 20 Dec 2024 08:44:34 +0000
Received: by outflank-mailman (input) for mailman id 861717;
 Fri, 20 Dec 2024 08:44: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 1tOYcb-00033z-IP
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 08:44:33 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a1d5a6e9-beae-11ef-a0d8-8be0dac302b0;
 Fri, 20 Dec 2024 09:44:32 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 20 Dec 2024 09:44:31 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: a1d5a6e9-beae-11ef-a0d8-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734684272; x=1766220272;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=MhFL34B+Wvm9oSwNNFdcMDYglsbCPPNQyJ/6awuEq94=;
  b=0dUuxBZHU2FvXzzjp0mY/PJmRyvM0yrkeOb69nX+a4URc6XEGRhJPMzv
   HLx+RumhOHp/kWVNHQ+FmKSIAeHUoTlpXO86YlgakCA5FD7CNVe7BXnsL
   PyLOT5uw5vdyLFv7jQ+lxDvlUTh2MR8TbcO8PkHBZRIbN1+yvPIXlv/S3
   k=;
X-CSE-ConnectionGUID: 3lLPQu7pSRCtQmZ3lBE9rQ==
X-CSE-MsgGUID: F0kXtgcrRpeBqb+3wzvApQ==
X-IronPort-AV: E=Sophos;i="6.12,250,1728943200"; 
   d="scan'208";a="28266527"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: <2024122042-guidable-overhand-b8a9@gregkh>
Content-Type: text/plain; charset="utf-8"
X-Forward: 88.183.119.157
References: <20241219092615.644642-1-ariel.otilibili-anieli@eurecom.fr>
 <20241219224645.749233-1-ariel.otilibili-anieli@eurecom.fr>
 <20241219224645.749233-2-ariel.otilibili-anieli@eurecom.fr> <2024122042-guidable-overhand-b8a9@gregkh>
Date: Fri, 20 Dec 2024 09:44:31 +0100
Cc: linux-kernel@vger.kernel.org, "Jan Beulich" , stable@vger.kernel.org, "Andrew Morton" , "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Stefano Stabellini" , xen-devel@lists.xenproject.org
To: "Greg KH" 
MIME-Version: 1.0
Message-ID: <2f7a82-67652e80-9181-6eae3780@215109797>
Subject: =?utf-8?q?Re=3A?= [PATCH v2 1/1] =?utf-8?q?lib=3A?= Remove dead code
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 1024

On Friday, December 20, 2024 08:09 CET, Greg KH  wrote:

> On Thu, Dec 19, 2024 at 11:45:01PM +0100, Ariel Otilibili wrote:
> > This is a follow up from a discussion in Xen:
> >=20
> > The if-statement tests `res` is non-zero; meaning the case zero is =
never reached.
> >=20
> > Link: https://lore.kernel.org/all/7587b503-b2ca-4476-8dc9-e9683d4ca=
5f0@suse.com/
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Suggested-by: Jan Beulich 
> > Signed-off-by: Ariel Otilibili 
> > --
> > Cc: stable@vger.kernel.org
>=20
> Why is "removing dead code" a stable kernel thing?

Hello Greg,

It is what I understood from the process:

"Attaching a Fixes: tag does not subvert the stable kernel rules proces=
s nor the requirement to Cc: stable@vger.kernel.org on all stable patch=
 candidates." [1]

Does my understanding make sense?

Regards,
Ariel

[1] https://docs.kernel.org/process/submitting-patches.html

>=20
> confused,
>=20
> greg k-h



From xen-devel-bounces@lists.xenproject.org Fri Dec 20 08:50:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 08:50:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861727.1273793 (Exim 4.92)
	(envelope-from )
	id 1tOYi6-0004bC-77; Fri, 20 Dec 2024 08:50:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861727.1273793; Fri, 20 Dec 2024 08:50: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 1tOYi6-0004b5-3w; Fri, 20 Dec 2024 08:50:14 +0000
Received: by outflank-mailman (input) for mailman id 861727;
 Fri, 20 Dec 2024 08:50: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 1tOYi4-0004az-8Z
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 08:50:12 +0000
Received: from EUR03-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur03on20631.outbound.protection.outlook.com
 [2a01:111:f403:260c::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 6ac64e9e-beaf-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 09:50:09 +0100 (CET)
Received: from AS4P191CA0005.EURP191.PROD.OUTLOOK.COM (2603:10a6:20b:5d5::15)
 by AS8PR08MB8898.eurprd08.prod.outlook.com (2603:10a6:20b:5b7::13)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.14; Fri, 20 Dec
 2024 08:50:01 +0000
Received: from AMS1EPF00000047.eurprd04.prod.outlook.com
 (2603:10a6:20b:5d5:cafe::c8) by AS4P191CA0005.outlook.office365.com
 (2603:10a6:20b:5d5::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8272.16 via Frontend Transport; Fri,
 20 Dec 2024 08:50:01 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 AMS1EPF00000047.mail.protection.outlook.com (10.167.16.135) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.15
 via Frontend Transport; Fri, 20 Dec 2024 08:50:00 +0000
Received: ("Tessian outbound b519d6c64997:v528");
 Fri, 20 Dec 2024 08:50:00 +0000
Received: from L5bc7a9b73624.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 BC1296F0-96CE-4501-B409-44085C090B53.1; 
 Fri, 20 Dec 2024 08:49:53 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 L5bc7a9b73624.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Fri, 20 Dec 2024 08:49:53 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21)
 by PAWPR08MB10133.eurprd08.prod.outlook.com (2603:10a6:102:35f::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.13; Fri, 20 Dec
 2024 08:49:50 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632%5]) with mapi id 15.20.8272.013; Fri, 20 Dec 2024
 08:49: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: 6ac64e9e-beaf-11ef-99a3-01e77a169b0f
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=DK9TU9Xh/fPsCzeSSIc9jXdNi+S+NjGFVfEalAhoSirka9mGG5VteRcNnWSglAufyJYhf8ZGB2xljK47xsW9AmMT0A3wMNRBpTuAN3Xf42cd+AZMFF/S6nPCICgy9nzCg9pUmTmqyYgjFVYJWSQWBJ/XzFJOkvdrOiO30E7jJzGs+pVIJS+40JywDfpWt0sRPdNmJNPiqn5xrR5MEF1Dj8Ub0/FhTYHW0geggNFflnuUStIX57zSU3uLqZrvGl+Fqy4rSwi8Es9yR7JqTsHdL2AVHLmlvj8fji6RcyrJHXs8P45bQAf3gc2/+l3Ae34Zn/9W9IrHucMfS/Ey3OiS2g==
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=QmQpkR0AEin+7tb6Wnmg7LIRuhQlCkBvckwQ+tD+vYQ=;
 b=pCKQCnazkCnGYhsHLH+Zf8Ebh9j80PBTe09MINPKV6KwKbBFodnZ3z3f8K5X/lxBy5XjvuCpawcctPzcrALsgIGqrqhBo/DHDLzvi8tYO7+ZB3IyCVOGEL81cFdOVZkbd2y8QYnleD8oxVAB6iL/SeUrCPv6EDI4Ii9JpdIm9PWfi84eyx4CwL17Ew2aMboBvaGexW1zOwUQohrDT4sdC/Ir7HJyvwAIeABl5AVb7OgfZQC+VIaf1U0eGqyjseg0v33aHqznCmDMjwUGD/6LnEv9uUC8jOOF7qadJOQqAkTIIBQcdZr/NfPh5msFhBeKrNneOpXMqvE8NQJUGuoz9g==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=QmQpkR0AEin+7tb6Wnmg7LIRuhQlCkBvckwQ+tD+vYQ=;
 b=GyEl2rx33GDTysGi5b4HMYR4mqaD1um3c1b4pe6SWZvY1P4jEdYkcPopjAJBFW6G0LSJCiWyRtUB8OGT8UQtw8kTxELKftD1Dr0zKuWKZ+6xvD6Uu7q87NY0uJjcb1EB1PNL7m2OlVpAkmj18QBwfHFtJ1tje7ldK6fj1ncIRh4=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 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
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: fcc5c4b0c51ceaf1
X-TessianGatewayMetadata: f9GqCU7sblO9KIwp4jXWHEu8rR18zd4c9wlfE/OcU4+/7odhJFh3pU0Jl9rmMpUxQPic9+XaxcO3EIAqy42aZx3uRxxu/GXbD3DH3HGJ85r5+yJAjFYY7RNwiVtOBOZi1eTII02CYKNgI0tgP/Zmw8rt4Fwsc1Wsox2QdfTdy3s=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=tWkEJOro20v7gOR+b71uK5yW/BvA9Pa1kje+vMq5WiDviAo8iC1QB3UfpHbsVsLgSt8B0YolOw0h6cGeb942psfe6jGzPax2mT5In1HBnxtQiTn9Imh4AD0MRlofjJup70elPXO7ezqhGyPvgt8i9O+BYT9kQhyHkv0hWzE7f1/oaVjfs/HvxaQGkh6VukZOcN51kN2Op4em2ReJSaH4QPvmGLvpdIsc2QHLuSGDPshS5kI04AJ+iatjNc3sunjA5WnWioInwemNAR+rdLrXRZdymojGog7eRKbLv18WJVdohJOGDUefmLFkASwcRf3hVjYW1teAGgl4WQH+9DDvcQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=QmQpkR0AEin+7tb6Wnmg7LIRuhQlCkBvckwQ+tD+vYQ=;
 b=BW3iRoEFkABnm2//0Q4BaqL/f/2GR6gVGb8Sm8ZWqWpHRUSADzy8o0/fb4UoNXPKG+TdWazTBBng4msBl5TEwI5z1hQgORZGLMSaYKrTlaVHrcNyecUNIcHmbmI4KpJaBlc0DuO3GLVxIe5URgVuoaQVYYQP/VRoNRGZWvnN+WMKsWPsof2cnPWU2fOZ+lka/sZaHr4zwnM5Aa9nlcS9UdB3+nLY/Z2V5RmM3n9dgghlMsXKKWuKuxWdhYpCctpK6IJY/MLGD9eupGjpr3kZiYswL51uIsRUBaSVND2SzAO+IhJBhKmef5V0D8S78+JSQWuboINLdGZsTXY8XSg4Cg==
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=QmQpkR0AEin+7tb6Wnmg7LIRuhQlCkBvckwQ+tD+vYQ=;
 b=GyEl2rx33GDTysGi5b4HMYR4mqaD1um3c1b4pe6SWZvY1P4jEdYkcPopjAJBFW6G0LSJCiWyRtUB8OGT8UQtw8kTxELKftD1Dr0zKuWKZ+6xvD6Uu7q87NY0uJjcb1EB1PNL7m2OlVpAkmj18QBwfHFtJ1tje7ldK6fj1ncIRh4=
From: Luca Fancellu 
To: Ariel Otilibili 
CC: "xen-devel@lists.xenproject.org" , Andrew
 Cooper , Anthony PERARD
	, Michal Orzel , Jan Beulich
	, Julien Grall ,
	=?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini
	
Subject: Re: [PATCH 1/1] xen/scripts: Fix regex syntax warnings with Python
 3.12
Thread-Topic: [PATCH 1/1] xen/scripts: Fix regex syntax warnings with Python
 3.12
Thread-Index: AQHbUkHipcR29N12QU6rggjFP3R+rbLu05mA
Date: Fri, 20 Dec 2024 08:49:50 +0000
Message-ID: 
References: <20241219181352.709315-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241219181352.709315-2-Ariel.Otilibili-Anieli@eurecom.fr>
In-Reply-To: <20241219181352.709315-2-Ariel.Otilibili-Anieli@eurecom.fr>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DBAPR08MB5798:EE_|PAWPR08MB10133:EE_|AMS1EPF00000047:EE_|AS8PR08MB8898:EE_
X-MS-Office365-Filtering-Correlation-Id: 64e77cb8-8411-40b6-3221-08dd20d349e6
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|1800799024|366016|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?iso-8859-1?Q?T52eJknb3JnhiNBysMGC/xG3X/KlqLNZIOkq2dJvTRfKzITLlnrfVHWlCX?=
 =?iso-8859-1?Q?FByBIW3x7zXjtTyexPWqLVbgYu/zMD5eKnWf8xr69X8oVjBY9eQJwJ/vA1?=
 =?iso-8859-1?Q?cA00Xa15xePzXXu5AjKuDBOgDh8EXOdSmaKqYpH6pejYhz4IP55iYYD1e2?=
 =?iso-8859-1?Q?gTpubJXhsRvUO5rSbmZKIoUPV6JsD7i1kQXLE/jRp2E9CvowZ/lLw07EyC?=
 =?iso-8859-1?Q?BtHehKE+0W7heTjRA8bF8em9Gk+8GANDxLaov23qraPOJ4SE/ZyPyLMHGT?=
 =?iso-8859-1?Q?kdhx9sBTGz16a2iEG93lY+A37knTUC5W0TcnASIbV0x/8a86wMW1NUkWly?=
 =?iso-8859-1?Q?jjeHsRn2CK0+4hEw3oyXO5F4hIYwvVutbpvCXYQwjzjGt5iERIthsa0g/j?=
 =?iso-8859-1?Q?JhnMevzoEnFF7OyxnC51303eoUxVU/vZistRnE+g4m8r/OgBfhU4goofjb?=
 =?iso-8859-1?Q?LoGEX0L8uYUXug2E2Ew96kmjKppJlPrWnbJ7ZeE6LSOg3iYRv2YhFYVhNj?=
 =?iso-8859-1?Q?v0mDJPobWPi3aEYwA0We6P/qtpExr+x4+t4WApBxAMCTe40aXK6xBP6LfY?=
 =?iso-8859-1?Q?P81XzH8G3XdFscyleW1vPAqZ1XazXQ56Rg7oZOJ3pQGLcbuWaMrNJlFl8/?=
 =?iso-8859-1?Q?5gQ2AGWfTjK50n86w5oIi48x2H+BPK93+pint7wnrf+lNxI+Z2KK2B/J+M?=
 =?iso-8859-1?Q?tWYHbZVqwbdOOMciFqvNeQHQ60bKFAT6CupHChisl86hua3u/OTmqLVR2V?=
 =?iso-8859-1?Q?/AMxqJL29x6Yz8XI32TfBIwQVYwa6KLs4TETb7HVFaWoKyx245zOKcire4?=
 =?iso-8859-1?Q?oAQ/CJI5yHRPev40kpAKcmzBcaITIVtBorhWpcWiBqikNK4xN2WPiVatOt?=
 =?iso-8859-1?Q?hm26CccZ2Mn5YxkVxNNtmXa+RovyjojsKMHpBxQePKZuZtC1gErPZOZ0Yq?=
 =?iso-8859-1?Q?ub6/eqIPLowqWcHS6BzkWn5A9vJDZBMY3aZjmmn7TsoyxzcIBaLkMbQgMh?=
 =?iso-8859-1?Q?6rb2Pn8ka27tgghPp4Ov1lMGDb8f+jO6LnZWFpGjB3UGTDc6yef13N/6zF?=
 =?iso-8859-1?Q?ILImD6W+TaN0PGsBivxcHOfOf1osGCKTZKdr3PRRPJt72vIvkB5/W/kWKQ?=
 =?iso-8859-1?Q?zqSV4cBmUiRl4jLviVHLJTSV6XlSYMozn0nU7lQNfbBu5OvRp654mF96vV?=
 =?iso-8859-1?Q?NZ8VuWPpXPJmpJbdxA1KHTW0DMPYSOnjKpZB+jR7OjLQJfjx+G4VHR+/Fg?=
 =?iso-8859-1?Q?bnIxVacvIdz4ypwuF5Dy4wsVypN+bsX9K4KQ158tiWtghXKeBdOeC609fv?=
 =?iso-8859-1?Q?C8f34Ei11xXJj8vMne4vTlIWmaIYmf17mk5CxZXMWxxKlMg6GXkDIkBjuZ?=
 =?iso-8859-1?Q?AkWS9gNWIkRLAsVumWfBVMndiwpcvVb6ItCRPavBn3oxm2eMBHMuS2JF1p?=
 =?iso-8859-1?Q?vywHgrIw44u6jY89UZxNMUk15AsKjGwZvE9zl/NlecIOUGoXWRfbm3ZKKN?=
 =?iso-8859-1?Q?pwpC0WZUcd6ndxvsnmDbO1?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);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: PAWPR08MB10133
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender:
 ip=[2603:10a6:10:1a6::21];domain=DBAPR08MB5798.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 AMS1EPF00000047.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	0edfd94f-4ef9-419e-f082-08dd20d343ad
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|35042699022|14060799003|82310400026|36860700013|1800799024|376014;
X-Microsoft-Antispam-Message-Info:
	=?iso-8859-1?Q?Zjmz56l0eCRdNYFCVm6nibpaMMLBi5DbLs+MmRAQQmv4h+9S9q4BfIBCZ1?=
 =?iso-8859-1?Q?siewldO4Ht1W5UdbwG/INkS5xuchg2VYbWhT2yeI/AF7e6UOSIcmo8AIPq?=
 =?iso-8859-1?Q?e9nuC2+gYw06vXaQyrzP88Vebsl14XPwpR9p5uifHxQBYZqoqDbAyw3+oj?=
 =?iso-8859-1?Q?Z4OS+4qs3lXPl1v7j7YLDfhehVFxxmr4oqmOv3IhXtOtBbHna62uvi0id3?=
 =?iso-8859-1?Q?HrPNdwZWAxZsBaxy8yS+57GaCFE3AiYLDKovvMuAQ8FqvVim5ja5/atHvl?=
 =?iso-8859-1?Q?gXKn+qXAtVe4gCCOqukL76XuFFXN2+oFlNeXMpwxqulVpkfgH5O2IwK/Oc?=
 =?iso-8859-1?Q?NNvmOSX88zXY+kYc1PhpDvXl4q6zQtnhgMqBgGJAXvt6Rr6X553sQqZVBA?=
 =?iso-8859-1?Q?SIgzgx5hFIhQNYeq8obF9qfyha621u+oGdspfv++Y30TeVkpRrF8EXmGLH?=
 =?iso-8859-1?Q?1Mw5NEAFTF7+bWhH0iSfAaGWWzn3PSYJ7W3cBvPsyB9mn3xBVLhckads27?=
 =?iso-8859-1?Q?Boc/lPaGND2/9AkYq7h/B/niRfGrQSJJFbjaJVcSI/wnGxXXCZGOhI39Lf?=
 =?iso-8859-1?Q?B9ONG2C/e6s6Iy1X0dg/9gMDDtB23nRcMFw9a+c85tR//OYfJ3NfskIR9E?=
 =?iso-8859-1?Q?9xmA8tu/uBty/jMn1BR8QSmJuyJLn1frVaBXQIsje9TEVEXWpOGSmwiEKo?=
 =?iso-8859-1?Q?jlc7nGrMFpZDz5Ld7UA/B0u2/VLxncX8ZNsr70BWjHKg4nexJr0eQl61TH?=
 =?iso-8859-1?Q?jedLb/nV517i24p8S8yh9XN4yGWIu/gafpaaAQjTzDSyvOD5ZLzWis9lnK?=
 =?iso-8859-1?Q?+bCZkD0iBGNDEeVW1K023HtgYvmtmsMhlTFLkD3bwqigyT48FP+zDYViNe?=
 =?iso-8859-1?Q?Xk4CCcIrbfSybBXd/a46aN1k8RALGUqDCsq76aYhqhEwpJOk9cLqGOV+Qc?=
 =?iso-8859-1?Q?dfTjoiIllqDkf06E1G/exuo9gjgAXnA9VoHDmcB3GwG+OK3YohEdpWshp0?=
 =?iso-8859-1?Q?hx1Qs6eAkULMrc5cYHTSeIzcdPQlPGWZ1KzMXYeUDsdu9/22oxgOoG0zy0?=
 =?iso-8859-1?Q?PSkvikheQm6UvgRLQqyl5HsSyN7t2Rl3i8ixXXzQzrItjo8wXRRyJVV88A?=
 =?iso-8859-1?Q?V4n2gxJpJDp3R+6gcn5zttmw6pFcGhTGSjaC5My84HZ0u2gQua/Yq8AaZi?=
 =?iso-8859-1?Q?qQbsVgpHLfII2e3JjI153VK3SvaZ+nPyDhNl+QvSY+JUgtsnqZbbL8l+OP?=
 =?iso-8859-1?Q?dWXkPhnLw6G2mx7Sg+NKY/RegXCEyGZaIfXYniHt9WaBxvOTZMG0XWs8bU?=
 =?iso-8859-1?Q?GCpuZ/fyIqAMeBn0LjSXCzsQfXdpJ1MTzkGAlhPcsYoIo48vDaANDabSgE?=
 =?iso-8859-1?Q?CTR0rt0OuURlrePy0rhH0EQwLIrX45fMSLRXA93DT9lB3MGaQvKSSYMoYb?=
 =?iso-8859-1?Q?ngthtMHUTfTwmqTbAXMiKw8miSJ6dpy2FIyL7Mxpdq2ce0D4G7Gp+75UWT?=
 =?iso-8859-1?Q?p6rAvBoRdkyMVq4aix7sucuKJUxDyp5Y3jiBk2PnUIscT9uCAu4JlwEP8P?=
 =?iso-8859-1?Q?k3fJVLk=3D?=
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(35042699022)(14060799003)(82310400026)(36860700013)(1800799024)(376014);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Dec 2024 08:50:00.6020
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 64e77cb8-8411-40b6-3221-08dd20d349e6
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	AMS1EPF00000047.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB8898

Hi Ariel,

> On 19 Dec 2024, at 18:10, Ariel Otilibili  wrote:
>=20
> Same fix than commit 826a9eb072 (tools: Fix regex syntax warnings with Py=
thon 3.12).
>=20
> It clears out the warning:
>=20
> ```
> $ xen/scripts/xen-analysis.py
> xen/scripts/xen_analysis/cppcheck_analysis.py:94: SyntaxWarning: invalid =
escape sequence '\*'
>  comment_line_starts =3D re.match('^[ \t]*/\*.*$', line)
> ```
>=20
> The  warning appears only the first time the command is run, then it disa=
ppears.
>=20
> Fixes: 02b26c02c7 (xen/scripts: add cppcheck tool to the xen-analysis.py =
script)
> Signed-off-by: Ariel Otilibili 
> --

Reviewed-by: Luca Fancellu 




From xen-devel-bounces@lists.xenproject.org Fri Dec 20 08:53:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 08:53:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861733.1273803 (Exim 4.92)
	(envelope-from )
	id 1tOYl2-0005SY-JW; Fri, 20 Dec 2024 08:53:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861733.1273803; Fri, 20 Dec 2024 08: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 1tOYl2-0005SR-Go; Fri, 20 Dec 2024 08:53:16 +0000
Received: by outflank-mailman (input) for mailman id 861733;
 Fri, 20 Dec 2024 08:53: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 1tOYl0-0005SL-B6
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 08:53:14 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d7995324-beaf-11ef-a0d8-8be0dac302b0;
 Fri, 20 Dec 2024 09:53:12 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 14F5F5C0267;
 Fri, 20 Dec 2024 08:52:29 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43266C4CED6;
 Fri, 20 Dec 2024 08:53:10 +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: d7995324-beaf-11ef-a0d8-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
	s=korg; t=1734684790;
	bh=P1OC0d+7eswfuTcqYH0V8dMNSAezRS37ZcjQlhmq96U=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=aV6+K+XuIZikyNRaQ9AbkeqbOhOyXCH6ROjrjwtbZOUuaHWAiH4vm259qK3TeJPPG
	 lRW4JsJH6QVDqoVxYOTDtMPmxAJyQLein7z01dl3TxB6vOAw0T6T3V/ncIilRBp4Yi
	 26ki35QMqg/k4Uxv+M/DH/WOkzbcUeVtfQ1S4foU=
Date: Fri, 20 Dec 2024 09:53:07 +0100
From: Greg KH 
To: Ariel Otilibili-Anieli 
Cc: linux-kernel@vger.kernel.org, Jan Beulich ,
	stable@vger.kernel.org, Andrew Morton ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel , Julien Grall ,
	Roger Pau =?iso-8859-1?Q?Monn=E9?= ,
	Stefano Stabellini ,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 1/1] lib: Remove dead code
Message-ID: <2024122052-laurel-showbiz-4d7b@gregkh>
References: <20241219092615.644642-1-ariel.otilibili-anieli@eurecom.fr>
 <20241219224645.749233-1-ariel.otilibili-anieli@eurecom.fr>
 <20241219224645.749233-2-ariel.otilibili-anieli@eurecom.fr>
 <2024122042-guidable-overhand-b8a9@gregkh>
 <2f7a82-67652e80-9181-6eae3780@215109797>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2f7a82-67652e80-9181-6eae3780@215109797>

On Fri, Dec 20, 2024 at 09:44:31AM +0100, Ariel Otilibili-Anieli wrote:
> On Friday, December 20, 2024 08:09 CET, Greg KH  wrote:
> 
> > On Thu, Dec 19, 2024 at 11:45:01PM +0100, Ariel Otilibili wrote:
> > > This is a follow up from a discussion in Xen:
> > > 
> > > The if-statement tests `res` is non-zero; meaning the case zero is never reached.
> > > 
> > > Link: https://lore.kernel.org/all/7587b503-b2ca-4476-8dc9-e9683d4ca5f0@suse.com/
> > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > Suggested-by: Jan Beulich 
> > > Signed-off-by: Ariel Otilibili 
> > > --
> > > Cc: stable@vger.kernel.org
> > 
> > Why is "removing dead code" a stable kernel thing?
> 
> Hello Greg,
> 
> It is what I understood from the process:
> 
> "Attaching a Fixes: tag does not subvert the stable kernel rules process nor the requirement to Cc: stable@vger.kernel.org on all stable patch candidates." [1]
> 
> Does my understanding make sense?

I'm confused, what are you expecting to happen here?  Why is this even
marked as a "fix"?

> [1] https://docs.kernel.org/process/submitting-patches.html

Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html

for the stable kernel rules.

Again, you have a "cc: stable@..." in your patch, why?

thanks,

greg k-h


From xen-devel-bounces@lists.xenproject.org Fri Dec 20 09:01:31 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 09:01:31 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861743.1273813 (Exim 4.92)
	(envelope-from )
	id 1tOYsv-0007B9-BT; Fri, 20 Dec 2024 09:01:25 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861743.1273813; Fri, 20 Dec 2024 09:01:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOYsv-0007B2-8Y; Fri, 20 Dec 2024 09:01:25 +0000
Received: by outflank-mailman (input) for mailman id 861743;
 Fri, 20 Dec 2024 09:01: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 1tOYst-0007An-Cz
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 09:01:23 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fbd9c6e7-beb0-11ef-a0d8-8be0dac302b0;
 Fri, 20 Dec 2024 10:01:22 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 20 Dec 2024 10:01:21 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: fbd9c6e7-beb0-11ef-a0d8-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734685282; x=1766221282;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=3cDZTH3cvRhkQzEcJFEiStos4UDvJ0eUCTYXRT9Ws1k=;
  b=ulFwtttF04iv8AJWk8EAndxkqoSWg2iQgFSCj9XftXf7og52tbKQvru5
   F9GPylcmWp8w+rvaMECwSnUCxV5rBiYqhHI0xMUeEbxg0skafd7gstvk9
   payVaOIV+nG5arX1GemVNj3OuPA7YSD0WAvsGibDo+PKe0+tIveoI5z9h
   s=;
X-CSE-ConnectionGUID: iv3DghtwRHS6pJQXUjVQ6A==
X-CSE-MsgGUID: rgbF/hAgTNiEl2a9YjEAiw==
X-IronPort-AV: E=Sophos;i="6.12,250,1728943200"; 
   d="scan'208";a="28266625"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: <2024122052-laurel-showbiz-4d7b@gregkh>
Content-Type: text/plain; charset="utf-8"
X-Forward: 88.183.119.157
References: <20241219092615.644642-1-ariel.otilibili-anieli@eurecom.fr>
 <20241219224645.749233-1-ariel.otilibili-anieli@eurecom.fr>
 <20241219224645.749233-2-ariel.otilibili-anieli@eurecom.fr>
 <2024122042-guidable-overhand-b8a9@gregkh>
 <2f7a82-67652e80-9181-6eae3780@215109797> <2024122052-laurel-showbiz-4d7b@gregkh>
Date: Fri, 20 Dec 2024 10:01:21 +0100
Cc: linux-kernel@vger.kernel.org, "Jan Beulich" , "Andrew Morton" , "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Stefano Stabellini" , xen-devel@lists.xenproject.org
To: "Greg KH" 
MIME-Version: 1.0
Message-ID: <2f7a83-67653280-a2f5-5cf12280@54008765>
Subject: =?utf-8?q?Re=3A?= [PATCH v2 1/1] =?utf-8?q?lib=3A?= Remove dead code
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 1650

On Friday, December 20, 2024 09:53 CET, Greg KH  wrote:

> On Fri, Dec 20, 2024 at 09:44:31AM +0100, Ariel Otilibili-Anieli wrot=
e:
> > On Friday, December 20, 2024 08:09 CET, Greg KH  wrote:
> >=20
> > > On Thu, Dec 19, 2024 at 11:45:01PM +0100, Ariel Otilibili wrote:
> > > > This is a follow up from a discussion in Xen:
> > > >=20
> > > > The if-statement tests `res` is non-zero; meaning the case zero=
 is never reached.
> > > >=20
> > > > Link: https://lore.kernel.org/all/7587b503-b2ca-4476-8dc9-e9683=
d4ca5f0@suse.com/
> > > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > > Suggested-by: Jan Beulich 
> > > > Signed-off-by: Ariel Otilibili 
> > > > --
> > > > Cc: stable@vger.kernel.org
> > >=20
> > > Why is "removing dead code" a stable kernel thing?
> >=20
> > Hello Greg,
> >=20
> > It is what I understood from the process:
> >=20
> > "Attaching a Fixes: tag does not subvert the stable kernel rules pr=
ocess nor the requirement to Cc: stable@vger.kernel.org on all stable p=
atch candidates." [1]
> >=20
> > Does my understanding make sense?
>=20
> I'm confused, what are you expecting to happen here?  Why is this eve=
n
> marked as a "fix"?
>=20
> > [1] https://docs.kernel.org/process/submitting-patches.html
>=20
> Please read:
>     https://www.kernel.org/doc/html/latest/process/stable-kernel-rule=
s.html

I am, Greg; thanks for the heads up.
>=20
> for the stable kernel rules.
>=20
> Again, you have a "cc: stable@..." in your patch, why?

Removed stable from the thread.
>=20
> thanks,
>=20
> greg k-h



From xen-devel-bounces@lists.xenproject.org Fri Dec 20 09:03:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 09:03:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861748.1273823 (Exim 4.92)
	(envelope-from )
	id 1tOYvL-0007ve-Oc; Fri, 20 Dec 2024 09:03:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861748.1273823; Fri, 20 Dec 2024 09:03: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 1tOYvL-0007vX-LD; Fri, 20 Dec 2024 09:03:55 +0000
Received: by outflank-mailman (input) for mailman id 861748;
 Fri, 20 Dec 2024 09:03: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 1tOYvK-0007vR-QZ
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 09:03:54 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 55785b75-beb1-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 10:03:52 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 20 Dec 2024 10:03:52 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 55785b75-beb1-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734685432; x=1766221432;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=STwzG7BvSs4BgHI3CfMNlpUO8/6REUgVlfpM909l1YQ=;
  b=eppYADWhSnRBnKxp2Ij0IU98syDbXZKpRfHNW3nNzzp8B5kLeSloy4Q7
   lVn1mVl/1hgjeCnERiSTCG6wNQx3W21G/dtivm1RPhpvYphwFCiNkFz2H
   AW/H7DQxE2/+5buGe1omR/YQKOSkmR7qPVXHr6CcF+fzLZ9cWQYAmxiC5
   4=;
X-CSE-ConnectionGUID: Xba9ydXCSO+nBS2GlrY4MA==
X-CSE-MsgGUID: sdCdrdC0S0ytfhVkAl0/Ug==
X-IronPort-AV: E=Sophos;i="6.12,250,1728943200"; 
   d="scan'208";a="28266652"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"
X-Forward: 88.183.119.157
References: <20241219181352.709315-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241219181352.709315-2-Ariel.Otilibili-Anieli@eurecom.fr> 
Date: Fri, 20 Dec 2024 10:03:52 +0100
Cc: =?utf-8?q?xen-devel=40lists=2Exenproject=2Eorg?= , "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Jan Beulich" , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Stefano Stabellini" 
To: "Luca Fancellu" 
MIME-Version: 1.0
Message-ID: <2f7a88-67653300-f333-208cdcc@256863547>
Subject: =?utf-8?q?Re=3A?= [PATCH 1/1] =?utf-8?q?xen/scripts=3A?= Fix regex syntax 
 warnings with Python =?utf-8?q?3=2E12?=
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 926

On Friday, December 20, 2024 09:49 CET, Luca Fancellu  wrote:

> Hi Ariel,
>=20
> > On 19 Dec 2024, at 18:10, Ariel Otilibili  wrote:
> >=20
> > Same fix than commit 826a9eb072 (tools: Fix regex syntax warnings w=
ith Python 3.12).
> >=20
> > It clears out the warning:
> >=20
> > ```
> > $ xen/scripts/xen-analysis.py
> > xen/scripts/xen=5Fanalysis/cppcheck=5Fanalysis.py:94: SyntaxWarning=
: invalid escape sequence '\*'
> >  comment=5Fline=5Fstarts =3D re.match('^[ \t]*/\*.*$', line)
> > ```
> >=20
> > The  warning appears only the first time the command is run, then i=
t disappears.
> >=20
> > Fixes: 02b26c02c7 (xen/scripts: add cppcheck tool to the xen-analys=
is.py script)
> > Signed-off-by: Ariel Otilibili 
> > --
>=20
> Reviewed-by: Luca Fancellu 

Hi Luca; thanks for the feedback.
>=20
>



From xen-devel-bounces@lists.xenproject.org Fri Dec 20 09:35:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 09:35:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861767.1273832 (Exim 4.92)
	(envelope-from )
	id 1tOZPo-00049u-9P; Fri, 20 Dec 2024 09:35:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861767.1273832; Fri, 20 Dec 2024 09: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 1tOZPo-00049n-65; Fri, 20 Dec 2024 09:35:24 +0000
Received: by outflank-mailman (input) for mailman id 861767;
 Fri, 20 Dec 2024 09: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 1tOZPn-00049h-91
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 09:35:23 +0000
Received: from fforwardh-a4-smtp.messagingengine.com
 (fforwardh-a4-smtp.messagingengine.com [103.168.172.199])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id baffb1b6-beb5-11ef-a0d8-8be0dac302b0;
 Fri, 20 Dec 2024 10:35:21 +0100 (CET)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfforwardh.phl.internal (Postfix) with ESMTP id 4730929203AB;
 Fri, 20 Dec 2024 04:35:20 -0500 (EST)
Received: from phl-frontend-01 ([10.202.2.160])
 by phl-compute-06.internal (MEProxy); Fri, 20 Dec 2024 04:35:20 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 20 Dec 2024 04:35:18 -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: baffb1b6-beb5-11ef-a0d8-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	: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=
	1734687320; x=1734773720; bh=LzTGkTHoecYoA/dqJZrgdRgbPpIb3Oy/ciY
	AfsPJtq0=; b=YaSJ7XaUy6o/0GhnLXJXCTbw1/0VWlcY9ScVzAcZFrqF41as126
	p4Aus+uJD5VcDo/BajFTfbe8lDdTSO/aHX8pKYheXYc0+9NckFZrI6uQuePhoGXs
	PinFZRSrfUmkE5Y6TAW0tkTvG9SYtL+1+X4Wo4NxjF4fS4K8jPAjIpSJ9dwjhQB/
	9Z9qKXwO1IezcYEN5vxQyBvrp+m5rHZQQfnE8atgpUaeHSLahh3yKNykQDcxOVG1
	Ic0f58uI/le5yGxiifW8FbzJZjKP7GEvXsTOyRo/WJ9UanXuTxK6qlFjCpoBe8Hx
	hlH3xdu0vxveRfzQluelsncof4kfnnM8w1w==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddruddtvddgtdefucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhephffvvefufffkofgggfestdekredtredttdenucfh
    rhhomhepufgvrhhgihihucfmihgsrhhikhcuoefuvghrghhihigpmfhisghrihhksegvph
    grmhdrtghomheqnecuggftrfgrthhtvghrnhepgedvfeefhfduvdetkeegleeggfelheek
    veeiuddufeehtdehleelhfekiedvvedvnecuffhomhgrihhnpehkvghrnhgvlhdrohhrgh
    enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsrghk
    ihgssegurghrkhhsthgrrhdrshhithgvpdhnsggprhgtphhtthhopeelpdhmohguvgepsh
    hmthhpohhuthdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhr
    ohhjvggtthdrohhrghdprhgtphhtthhopehsvghrghhihigpkhhisghrihhksegvphgrmh
    drtghomhdprhgtphhtthhopehjsggvuhhlihgthhesshhushgvrdgtohhmpdhrtghpthht
    oheprghnughrvgifrdgtohhophgvrhefsegtihhtrhhigidrtghomhdprhgtphhtthhope
    hrohhgvghrrdhprghusegtihhtrhhigidrtghomhdprhgtphhtthhopegrnhhthhhonhih
    rdhpvghrrghrugesvhgrthgvshdrthgvtghhpdhrtghpthhtohepmhhitghhrghlrdhorh
    iivghlsegrmhgurdgtohhmpdhrtghpthhtohepjhhulhhivghnseigvghnrdhorhhgpdhr
    tghpthhtohepshhsthgrsggvlhhlihhniheskhgvrhhnvghlrdhorhhg
X-ME-Proxy: 
    
    
    
    
Feedback-ID: id72fffdc:Fastmail
From: Sergiy Kibrik 
To: xen-devel@lists.xenproject.org
Cc: Sergiy Kibrik ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Anthony PERARD ,
	Michal Orzel ,
	Julien Grall ,
	Stefano Stabellini 
Subject: [XEN PATCH v1] ioreq: allow arch_vcpu_ioreq_completion() to signal an error
Date: Fri, 20 Dec 2024 11:35:14 +0200
Message-Id: <20241220093514.3094521-1-Sergiy_Kibrik@epam.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Return false from arch_vcpu_ioreq_completion() when completion is not handled.
According to coding-best-practices.pandoc an error should be propagated to
caller, if caller is expecting to handle it, which seems to the case for
callers of arch_vcpu_ioreq_completion().

Suggested-by: Jan Beulich 
Signed-off-by: Sergiy Kibrik 
---
This change has been suggested by Jan some time ago during review of another
series, here's link to discussion:
https://lore.kernel.org/xen-devel/952701cd-83d8-4c1f-9f38-ee63ba582d66@suse.com/
---
 xen/arch/x86/hvm/ioreq.c | 2 +-
 xen/include/xen/ioreq.h  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 5c3d0c69aa..9b1592d505 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -47,7 +47,7 @@ bool arch_vcpu_ioreq_completion(enum vio_completion completion)
 
     default:
         ASSERT_UNREACHABLE();
-        break;
+        return false;
     }
 
     return true;
diff --git a/xen/include/xen/ioreq.h b/xen/include/xen/ioreq.h
index 29a17e8ff5..2583eca0d5 100644
--- a/xen/include/xen/ioreq.h
+++ b/xen/include/xen/ioreq.h
@@ -118,7 +118,7 @@ bool arch_vcpu_ioreq_completion(enum vio_completion completion);
 static inline bool arch_vcpu_ioreq_completion(enum vio_completion completion)
 {
     ASSERT_UNREACHABLE();
-    return true;
+    return false;
 }
 #endif
 
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Fri Dec 20 09:36:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 09:36:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861773.1273844 (Exim 4.92)
	(envelope-from )
	id 1tOZRI-0004fV-Kc; Fri, 20 Dec 2024 09:36:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861773.1273844; Fri, 20 Dec 2024 09:36: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 1tOZRI-0004fO-Gg; Fri, 20 Dec 2024 09:36:56 +0000
Received: by outflank-mailman (input) for mailman id 861773;
 Fri, 20 Dec 2024 09:36: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 1tOZRH-0004fI-Ct
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 09:36:55 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f28238db-beb5-11ef-a0d8-8be0dac302b0;
 Fri, 20 Dec 2024 10:36:54 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 20 Dec 2024 10:36:53 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: f28238db-beb5-11ef-a0d8-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734687414; x=1766223414;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=VH4YGcgb9p64u5EEltPGqnwSQiOBvYjcKhF+XUbUJ8M=;
  b=s+JqHj3agyGpgeFFAxpvVj66Dgr+tUVsOC6fWawj2NZpeLN6nkS1lfkl
   X+jK4EySBAz3VpGK1EFz6gokCkCx8ZsppD3Ox0a97yXfnhE48P2+ZfbW9
   SsvdvGzUcu97dMjFBuJyxwMAuok6qq+xVZO0h5Gtz6/LseD2LiKFGIfom
   c=;
X-CSE-ConnectionGUID: PdNeQV8xRfqy8xfPiJnWAg==
X-CSE-MsgGUID: fpJ+SUzHQVaLbXaCME9h6Q==
X-IronPort-AV: E=Sophos;i="6.12,250,1728943200"; 
   d="scan'208";a="28267110"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: <2f7a83-67653280-a2f5-5cf12280@54008765>
Content-Type: text/plain; charset="utf-8"
X-Forward: 88.183.119.157
References: <20241219092615.644642-1-ariel.otilibili-anieli@eurecom.fr>
 <20241219224645.749233-1-ariel.otilibili-anieli@eurecom.fr>
 <20241219224645.749233-2-ariel.otilibili-anieli@eurecom.fr>
 <2024122042-guidable-overhand-b8a9@gregkh>
 <2f7a82-67652e80-9181-6eae3780@215109797> <2024122052-laurel-showbiz-4d7b@gregkh> <2f7a83-67653280-a2f5-5cf12280@54008765>
Date: Fri, 20 Dec 2024 10:36:53 +0100
Cc: linux-kernel@vger.kernel.org, "Jan Beulich" , "Andrew Morton" , "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Stefano Stabellini" , xen-devel@lists.xenproject.org
To: "Greg KH" 
MIME-Version: 1.0
Message-ID: <2f7a89-67653a80-c09b-70827e80@197000382>
Subject: =?utf-8?q?Re=3A?= [PATCH v2 1/1] =?utf-8?q?lib=3A?= Remove dead code
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 2408

On Friday, December 20, 2024 10:01 CET, "Ariel Otilibili-Anieli"  wrote:

> On Friday, December 20, 2024 09:53 CET, Greg KH  wrote:
>=20
> > On Fri, Dec 20, 2024 at 09:44:31AM +0100, Ariel Otilibili-Anieli wr=
ote:
> > > On Friday, December 20, 2024 08:09 CET, Greg KH  wrote:
> > >=20
> > > > On Thu, Dec 19, 2024 at 11:45:01PM +0100, Ariel Otilibili wrote=
:
> > > > > This is a follow up from a discussion in Xen:
> > > > >=20
> > > > > The if-statement tests `res` is non-zero; meaning the case ze=
ro is never reached.
> > > > >=20
> > > > > Link: https://lore.kernel.org/all/7587b503-b2ca-4476-8dc9-e96=
83d4ca5f0@suse.com/
> > > > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > > > Suggested-by: Jan Beulich 
> > > > > Signed-off-by: Ariel Otilibili 
> > > > > --
> > > > > Cc: stable@vger.kernel.org
> > > >=20
> > > > Why is "removing dead code" a stable kernel thing?
> > >=20
> > > Hello Greg,
> > >=20
> > > It is what I understood from the process:
> > >=20
> > > "Attaching a Fixes: tag does not subvert the stable kernel rules =
process nor the requirement to Cc: stable@vger.kernel.org on all stable=
 patch candidates." [1]
> > >=20
> > > Does my understanding make sense?
> >=20
> > I'm confused, what are you expecting to happen here?  Why is this e=
ven
> > marked as a "fix"?

My understanding was that, for one-liners, the reference commit should =
be included; and CC stable.
> >=20
> > > [1] https://docs.kernel.org/process/submitting-patches.html
> >=20
> > Please read:
> >     https://www.kernel.org/doc/html/latest/process/stable-kernel-ru=
les.html
>=20
> I am, Greg; thanks for the heads up.

Now I got the procedure; thank you.
> >=20
> > for the stable kernel rules.
> >=20
> > Again, you have a "cc: stable@..." in your patch, why?
>=20
> Removed stable from the thread.

Hello again, Greg;

I should have said it upfront, for us to understand one another.
I have just checked, this thread is about v2 of the patch (with stable =
in CC); and v1 (without) was already accepted by  Andrew Morton [1].

If anything else I need to do, let me know.

Have a good day,
Ariel

[1] https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tre=
e/patches/lib-remove-dead-code.patch
> >=20
> > thanks,
> >=20
> > greg k-h



From xen-devel-bounces@lists.xenproject.org Fri Dec 20 13:00:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 13:00:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861815.1273853 (Exim 4.92)
	(envelope-from )
	id 1tOccE-0003vp-Rr; Fri, 20 Dec 2024 13:00:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861815.1273853; Fri, 20 Dec 2024 13: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 1tOccE-0003vg-Mz; Fri, 20 Dec 2024 13:00:26 +0000
Received: by outflank-mailman (input) for mailman id 861815;
 Fri, 20 Dec 2024 13: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 1tOccD-0003va-7J
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 13:00:25 +0000
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com
 [2a00:1450:4864:20::42d])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 5e007789-bed2-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 14:00:20 +0100 (CET)
Received: by mail-wr1-x42d.google.com with SMTP id
 ffacd0b85a97d-3862df95f92so995705f8f.2
 for ; Fri, 20 Dec 2024 05:00:20 -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-38a1c828897sm3968143f8f.20.2024.12.20.05.00.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 20 Dec 2024 05:00: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: 5e007789-bed2-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734699620; x=1735304420; 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=G8bTt3a6xJSUtBaN/B9wHGoJndpCmEEqHD4Q3cCZBzY=;
        b=GRWF2NiMtAhO1HVPAz00mociY5FSsyDNBXQ0yb6dsO0cCjrJCqca/SYLLK6WdLqWw8
         2usKsDU9CLSHrnfYRjmKRrsK49oAIO1ouH3Fl0eIu72fnutUM3lsdMG9IamYwZvnjcXX
         Ftyzdt4grw6JXCSwhOxpk8yxwDA/e/XpytdXE2sVom0JOjBDdSvXwawJMfimffONtPlw
         1dKdQ4jfEbL2y4fwFYSkPzcMKrq9Z/v+7vzVmsUNoQeove5T5SuN+fZGqdL+LQ22ppHt
         7Gz9c+LbH1NhvvWvf/wmq8DhBmm/XxCm0UXZzyfp5lpcjOB+Ox/QJ6t6LAU4k1fcD/lM
         nbDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734699620; x=1735304420;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=G8bTt3a6xJSUtBaN/B9wHGoJndpCmEEqHD4Q3cCZBzY=;
        b=g+RYQwUI5Yoeby2pH2GQpJWzQl7iE7iwdS+rNpWmQ7e7BoreuhtcQlrM7F57yv3vPQ
         +nn3HfF/wGWf2zLoKUJytMMl8chjCvJ+sl7xoUeXPxonoYyP5HT4ajeC8uuIem/bjjMh
         Ks2bWGwXhcFtq7MAWHhmVFtaMgAKRGCYYvX4jkruCAVKEIUGERdfR5WNo9AmjUjjXDB5
         ovBR4dUC8RPbCCcC+YXik5nviYybZgRH3bXN42WzRNQXMvghGIbMRenaA/ZWMdpZj+Eq
         6ZDFrkJfIqQN5JzRezY5HbVUnTmquPdVzW/tyCLErm1HwGvpRCotAWhm1r6aaF9WsQ9V
         BawA==
X-Forwarded-Encrypted: i=1; AJvYcCVb1lcGgxA68ann8eXTfscke9z8J0307PAkXdZ0liqthoJgIIotNxtFw2NsWvQKpH/mvpXc7WCV0r0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxcFcXMXCUXHA/k9vy4HYFxNeu+EpCFZ6ZMJnRYFxhvLb01l+KZ
	kJlNh8NRAMhYowHGUrPsdRFP8mQgnUpXriIKowTBGCio7AF9MA34Nzo+FCwhgQ==
X-Gm-Gg: ASbGncvDR7XQ+4Qt6nvgmkJ5zw3x/9PzBU5Viqe2dEERbdvZJ9SpLhh29oW4QQiSE5A
	zTUG8qy6bwDOqcUwYlPfhpPUykF0hIJms/bgHuC6vQEnXMJRK9zveqxwq0wYnLob05bwUBhFifE
	7sDQHlzl11VDnEW6P6UKxlKIA1odq//2gfon44JPcnegPvur1IDpDOjMh3VOuvM1veLdCD4TRQo
	sPqIC1zd9o3aj7ue+bqatbuzsrtAQsT3wtznmJE1DSh2hdl63kFc5pffN9GwhyGV4B0yI8b2XVe
	DHhJfztebHfD1x8RWBkzAdTDZN0HXYnlBumnWzgJew==
X-Google-Smtp-Source: AGHT+IFBNILU62rwTeZDAXaLSx+iich6k4MPhoAWwkIrkns5TX+LzOGaugxTE7GiTu14DvNxonh2Gw==
X-Received: by 2002:a05:6000:4021:b0:385:fa26:f0d8 with SMTP id ffacd0b85a97d-38a221e2f95mr3039150f8f.8.1734699619651;
        Fri, 20 Dec 2024 05:00:19 -0800 (PST)
Message-ID: 
Date: Fri, 20 Dec 2024 14:00:18 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH Hyperlaunch v2] xenconsole: Add connected flag
To: Jason Andryuk 
Cc: Anthony PERARD ,
 Juergen Gross , xen-devel@lists.xenproject.org
References: <20241219223222.2211-1-jason.andryuk@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: <20241219223222.2211-1-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.12.2024 23:32, Jason Andryuk wrote:
> --- a/xen/include/public/io/console.h
> +++ b/xen/include/public/io/console.h
> @@ -19,6 +19,19 @@ struct xencons_interface {
>      char out[2048];
>      XENCONS_RING_IDX in_cons, in_prod;
>      XENCONS_RING_IDX out_cons, out_prod;
> +/*
> + * Flag values signaling from backend to frontend whether the console is
> + * connected.  i.e. Whether it will be serviced and emptied.
> + *
> + * The flag starts as disconnected.
> + */
> +#define XENCONSOLE_DISCONNECTED 0
> +/*
> + * The flag is set to connected when the backend connects and the console
> + * will be serviced.
> + */
> +#define XENCONSOLE_CONNECTED    1
> +    uint32_t flag;
>  };

Given no other information, how would a guest know that it can actually
expect the flag to (eventually) become set?

Jan



From xen-devel-bounces@lists.xenproject.org Fri Dec 20 13:09:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 13:09:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861823.1273862 (Exim 4.92)
	(envelope-from )
	id 1tOckj-0004by-Hc; Fri, 20 Dec 2024 13:09:13 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861823.1273862; Fri, 20 Dec 2024 13: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 1tOckj-0004br-Es; Fri, 20 Dec 2024 13:09:13 +0000
Received: by outflank-mailman (input) for mailman id 861823;
 Fri, 20 Dec 2024 13:09: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 1tOckh-0004bl-Qc
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 13:09:11 +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 99aa9e5e-bed3-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 14:09:09 +0100 (CET)
Received: by mail-wm1-x330.google.com with SMTP id
 5b1f17b1804b1-43635796b48so12124455e9.0
 for ; Fri, 20 Dec 2024 05:09: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-43656b119b6sm80811795e9.22.2024.12.20.05.09.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 20 Dec 2024 05:09:09 -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: 99aa9e5e-bed3-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1734700149; x=1735304949; 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=/DbzH+G5ALaJjfb6JUJuM0SmHhzstkfyXiRu1blFeAc=;
        b=Gsby8QdQkJ77NV6Q/Flh0n9MdmmqDydAyGnAJf3oTbvdHSShn+sbcxm7wS9Xfze4mQ
         F2Y6OJCGjGLH0nsn2ajtw0yZhacphlfaoTaSt4tbzZYzRaWO6rKKeg7z3/jHFXJ4wHi9
         pKgiMj3HDy6zAVYmVDbtXn1zfrpO0X4osZiDLOSCvmKuf0eWzBNIg7U2n+Az3N98ZRFl
         UPQ+8LScAW9HpF6MlY6tZDHI8k8WviPe+t1Uz8BHQidYGEEs6s4T4z0BB6agnVVJBzlu
         OM38jBC38NIWantq1tq4I3C9isADpCHXZaT7ofxUn6h2JbOjxpxWZIbTMtpLkfs+FXDP
         Y2KA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734700149; x=1735304949;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/DbzH+G5ALaJjfb6JUJuM0SmHhzstkfyXiRu1blFeAc=;
        b=pvr0TBTXtadfxtA+NrLShVmVJJxGseVFZUr+dJ750MRX4fsU5eCSzmUa3pcmlsAAne
         3kHV7+JYZNSuzRfKXdBYP4AR8elLU70yXOF5aEqzhvtck40o+UvmUXs/TP5K5i8m8Sz6
         /5jkbgqMscM7Bf+h5DwLNDdExaad/TJFpJA+w9VGrKSmxjBAPXiN/03voRNQd+hpxbOX
         cU5m229ByA4cGFJtxGxhSqsfcrylgX15zxPrW2RmhpeYlID5kY4OAsj7teezpSVOv9Hs
         pjI6WDcvABGWQXS5WqAEToSfYY1M3Hv66giZo7Lu9QnUVMlmHkU+TfsWNf9QdmnNgozL
         U0zw==
X-Forwarded-Encrypted: i=1; AJvYcCWESnuhM24ChAKdWJ2Cn0r1OA95SUD56a2roWKk+xPY9PODBuVnJV6sAcWGuxJCyzdSCrMrGAVVpwA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyVHoRpBjk4NJnlgKp8gWVENrHwtfJqUMXIjQWFBCfhqe/7KLiT
	iAPiHraM3NhDbynRvWu9H5fnn89IYZjhMWalU+amZujaj5uSwFVxxCsDXtuoEg==
X-Gm-Gg: ASbGncv8Y6GJU+2rMgjbsV9z9F3KfTkha3JYZrDKZKDFZqeJz8BijDrD9qRLPUyqtC1
	2DjwJPgV/PCY6nAISczCqHEvF7U4ZeCQu+aHkLrv4xb5Vld27rlCYch+dzYMWD0yhLJh3exns7X
	IprxxZWzOu+RtJSzdbS7ITH8+AhFujRAnQyqwNH2mu/bfJrGSkBGxSGFqK2b2Qd6mveBm7zwYsO
	Wg8xs1HQQ/f1vyvY7TUm2/fJzV/N8EWIffvgqMkcv8yJlQY7Pj70DBjX6VGMZgKhnVaMdl6MUe+
	IMOSTQUbJaEiAPDpCWg+uX3muRTy2Mt+39b/gSNXAg==
X-Google-Smtp-Source: AGHT+IEsm+RdyLje2bhcs7m+lKtD6L3chMQuhqOKsMYTxp1pOATRpfX5VLv09AZk7R2/ppq/E18pAQ==
X-Received: by 2002:a05:600c:1506:b0:434:e65e:457b with SMTP id 5b1f17b1804b1-4365c763d36mr68676395e9.3.1734700149300;
        Fri, 20 Dec 2024 05:09:09 -0800 (PST)
Message-ID: <258c4e83-4379-4212-b80a-4fe909849e66@suse.com>
Date: Fri, 20 Dec 2024 14:09:07 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] x86: Add Support for Paging-Write Feature
To: =?UTF-8?Q?Petr_Bene=C5=A1?= 
Cc: Tamas K Lengyel ,
 Alexandru Isaila ,
 Petre Pircalabu ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 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 20.12.2024 00:55, Petr Beneš wrote:
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -176,6 +176,10 @@ static void ept_p2m_type_to_flags(const struct p2m_domain *p2m,
>              break;           
>          case p2m_access_rwx:
>              break;
> +        case p2m_access_r_pw:
> +            entry->w = entry->x = 0;
> +            entry->pw = !!cpu_has_vmx_ept_paging_write;
> +            break;
>      }

To avoid the flag becoming "sticky", I think you need to clear it ahead of
this switch() (or right at the start of the function).

Jan


From xen-devel-bounces@lists.xenproject.org Fri Dec 20 13:32:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 13:32:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861831.1273872 (Exim 4.92)
	(envelope-from )
	id 1tOd7E-0008Rd-67; Fri, 20 Dec 2024 13:32:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861831.1273872; Fri, 20 Dec 2024 13:32:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOd7E-0008RW-3R; Fri, 20 Dec 2024 13:32:28 +0000
Received: by outflank-mailman (input) for mailman id 861831;
 Fri, 20 Dec 2024 13:32: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 1tOd7C-0008RQ-39
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 13:32:26 +0000
Received: from EUR05-DB8-obe.outbound.protection.outlook.com
 (mail-db8eur05on20619.outbound.protection.outlook.com
 [2a01:111:f403:2614::619])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d87e1329-bed6-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 14:32:24 +0100 (CET)
Received: from AS1PR04MB9559.eurprd04.prod.outlook.com (2603:10a6:20b:483::21)
 by GV1PR04MB10846.eurprd04.prod.outlook.com (2603:10a6:150:210::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.14; Fri, 20 Dec
 2024 13:32:20 +0000
Received: from AS1PR04MB9559.eurprd04.prod.outlook.com
 ([fe80::4fdc:8a62:6d92:3123]) by AS1PR04MB9559.eurprd04.prod.outlook.com
 ([fe80::4fdc:8a62:6d92:3123%5]) with mapi id 15.20.8272.005; Fri, 20 Dec 2024
 13:32:20 +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: d87e1329-bed6-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=mxvovRCyCB/8pZqTcy7kDlyrtnv1UWELGc9BDKd5NBMPB+qVASvEtuIFOKnIde6cdsCwUwKmlpnG4jge7xfrxsQzV0ownRwFHWE4e3eUkpcPNpRNSnCjTRqX6qsAT3UTVG06FxmbvQnKdTuqrBEI+KXLmhlJkgMrT2xtqlWD7w+oEm9c6UM95Tx4QPXEELFzlYORnBBEfCl3N7Rks7NwqvPr9cwi1FiLi91tkgzrjyXWMChdU/oNO6kxefcugxtq0lYXVaNPeaylrBgSUTbLIzTO36PXOcQt+unzmRJznOQl3qh1Edg0z3R3VdIh0fiDfOJNlouuJr9Cbi9mo7UQHA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lkpKWXgrjBo35LV9AFHyMdkFzsVCheOvl2eBB0UNrZo=;
 b=ve1oWyp4yClwqABeVFQtuV+VY883+Ai0S2SNRHOsU78TWUe61N8PyFFyglDTD16FtTh7vQ3eoTrRH7ExXEgBa3GsgqW+nQZRuzX0veH6qCoYMi3E/8Xei7ryrwMzZUV0W6hbT6IHrp1E9g6T9wpK4FU+GEKs07H7BMGlg/MrU7LnN1cJHJ4PgZD2teEVnYuLiyNR9zNjhPC5ffzJCNCxSjb1xAMSmkd9js7gu6DgeIzVAKP2hn5Y22w8COAx091fDjFkdpVj+McAeYel2MEHKxqC0pt40Dn/jZEg37dG+b8vyeRi4+YttmC+CuDWUSkcLrxzg5DdO+FqBB+1B99lbg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com;
 dkim=pass header.d=oss.nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com;
 s=selector1-NXP1-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=lkpKWXgrjBo35LV9AFHyMdkFzsVCheOvl2eBB0UNrZo=;
 b=u1iniY9a5oUCePPCkM7S+umRz7CCq57VFtpTNG/DyeL34Illuv91rqThGyvH0pHBikojjTB6iRVC82T2kx0kZQZo1Z9H+thp5Dpc712rDYaA5Q5y/c6IUX3FYUejAANyqXItEwx8soKGDltdO/cEnS5gP7q+LYxkT/br+H8IXiYeyOAfpkcSALyrQF/77OtQT8wruMLUdVeC1QKx1xiUCMhPYh9jhGYP0dXqYs1l/Zce20bU9jp1IwT+uWZG+Mzs5gDbrfPeE8lrcuUug1+UBnyzSsljrtUczt6u0dx7ej/Arb992uoYevKVqD9c9iwFaafQ8+wWHtrhH9rQbdQGnA==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=oss.nxp.com;
Message-ID: <6b8593e4-cbb8-47e6-b56c-111c89136bbb@oss.nxp.com>
Date: Fri, 20 Dec 2024 15:31:52 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 0/6] xen/arm: Add support for S32CC platforms and
 LINFlexD UART
To: Michal Orzel , xen-devel@lists.xenproject.org
Cc: S32@nxp.com, Andrei Cherechesu ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Oleksii Kurochko ,
 Community Manager ,
 Andrew Cooper ,
 Grygorii Strashko 
References: <20241219112315.2461048-1-andrei.cherechesu@oss.nxp.com>
 <1b85e268-a06b-4e40-b652-99ffc874e10b@amd.com>
Content-Language: en-US
From: Andrei Cherechesu 
In-Reply-To: <1b85e268-a06b-4e40-b652-99ffc874e10b@amd.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: AS4P189CA0020.EURP189.PROD.OUTLOOK.COM
 (2603:10a6:20b:5db::9) To AS1PR04MB9559.eurprd04.prod.outlook.com
 (2603:10a6:20b:483::21)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS1PR04MB9559:EE_|GV1PR04MB10846:EE_
X-MS-Office365-Filtering-Correlation-Id: b98a5458-34a2-4a5a-29b3-08dd20faba5f
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
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:
	=?utf-8?B?a0V0bjJkZEU4VDVqaC8xOGFSY3lXOGZFNjVkd3gvSXNSOVVZci9jVVhJTjZ0?=
 =?utf-8?B?eFBRMkg2MmFxVTlEellPZmdTcFlqV08yOC83MTlWQWVFNDN3ZmJBR01JcENC?=
 =?utf-8?B?MjJFaUpJTEkzeXNIVG9SRDlGcW94SURVT3pBcHNTaVFRNDJkazZNOW9GK0NV?=
 =?utf-8?B?VlpScXdvQnNFRXRkOXBFL1FTbnlDQ3FvWEJFMWdROGtLZFBnbGt0OFZHcEhX?=
 =?utf-8?B?UElzWEFHMm9GU2JjRWxPMmNyYUxXZzBiS0NRZ2E5MEpEM1VKaFJ2WGo0OWhE?=
 =?utf-8?B?cnRmV3JmQW5jRHgzb3pQMDNXU2lUVEVrajIvcjFOdEJBdXEvZzFsS3d3b0hG?=
 =?utf-8?B?YUVOQXRVQnVKYkV4cERFRGVoQ2V0dUlVT0JZOG84L0NDdEhXN2NKeUl4cWJ3?=
 =?utf-8?B?dWVQUjU2MFl4Rm5vOGRjSEgwdmhuZkxUWlpJMEZOdDVVS0xrSE1WS0w4MXBH?=
 =?utf-8?B?MzY4T2NpS0JyOXh5QzlNSTVhUUdBb1hWRXZjMUhTOFN1UHlJSzhaWmZzZWp4?=
 =?utf-8?B?WkZNVXNDNHV1YjQ1Nld2b0twZ2NWM3FySm5jQjFlcmk2QnUrdG1LaW5EdE9s?=
 =?utf-8?B?aGhBQ3RhUG9pY1dKQ2VzSmw1TElEa0NSeldqbnBzSnZEMllJVHl4Vkc4Ulc3?=
 =?utf-8?B?b1AxeGJhaVNFSUtsMnhnSzE3VmFGQkxQbDhBdktIWk5NSUJkWGRxR05teFls?=
 =?utf-8?B?N3VlUFBuanFMdjR2TFBJYThZMHFQQXNsOTJKenhnekoyMlpMdno0K3ZEUnlG?=
 =?utf-8?B?cmhPS0VtRVNzK1VTa1AyUzdxZlI5WWxpcTBVeGVLcXFDTFYxZVNnOHBPRVNz?=
 =?utf-8?B?b3h6a1k4OUx6NzU0V2Uwc1JyQ0twYnJiM012U3V6MjJ1RHRyNk95em1TemxZ?=
 =?utf-8?B?azFjNU1mU3ZUdHZMTGh6UzRMZFY4QzJadVd6aWFlM095aldjTkRIWnBCOVRy?=
 =?utf-8?B?RWpBekRPK1VnWVE3T1d0WDd2Y1dydXE0eWxqR09RZEZzSFdvemtvOEsyYVJD?=
 =?utf-8?B?MzVBdlhMSDRyTEtRK3VOQmRRQ0UxdGJDNnA2WDJRQmZrY0RHWWZGRVFWd2VW?=
 =?utf-8?B?a2haOW84RmZ0Tlpka2ZWWDc2N0xDSFBPZTFvVGlPMjBaSXFYaVlycHhMVU14?=
 =?utf-8?B?a2Yvd05IeXU5d1NYSUowK2xaZWFULzZHcndja2NFa1RHaTNUTXZjeCs4VHZl?=
 =?utf-8?B?U3ZMQnRkNzBJN1o0UnVjWURIZkZUN21XVms5eXQrb3dDZWdRTXg2UmRZbWFw?=
 =?utf-8?B?YmNQQ3I2cCtLK0w0bzdrOGFqcEZPMDFyUFR1bWdQaDl0V1BjeFJ4WWdFOFFj?=
 =?utf-8?B?UmZ3bFRxMmlaQWd1azlKVEYxWHA1Z2hFVG5MRTh2SlJ3c01BbHlEMVBGT1hI?=
 =?utf-8?B?aHVMTUw4Uk5PRTlxQVY4TUFmT3JvVlFNQmx2Z1AzbEJ3R09ZL0FjZkNOcUlJ?=
 =?utf-8?B?K29wRzlEMnluUWp1bE4rb1NITUY5K0JoeEhnc3djZlRKRE0rUndab1Bod0xs?=
 =?utf-8?B?cVB0a3NDRytlK3AvS3BVbGFvaXpudFczR096SlRqVk9oS25yRjBnSlRkVFpX?=
 =?utf-8?B?aE1kUmh4bFRkNzdOWUNIMCtVVGN5a2dDUGlrY2p3eVJXTEVTRXNQdlVFVDdt?=
 =?utf-8?B?SXlIanVCcmpzL21vdDE0N3pXQlNRWkJ1RnlmZEhFeXR0VUlUdk9va2FiSmlo?=
 =?utf-8?B?VnBsUnpkRFp0bTU2OHNpcmFzOFlMWXhLTHFzWEs0OWVoZHBhZmVEQ216R2sv?=
 =?utf-8?B?WVlsNERWdGVGbTRaVWJUNXBuMGJqQzZsaFM3Mkx6ci9DR0I5ZWdqRUVMRDZY?=
 =?utf-8?B?b3F2STdVWlBtQno3TGFxeGhLRWVPWXNSclhobkU3TitoODgxNk1WNXB2eUtW?=
 =?utf-8?B?U1ltNG1tUTJPTWNuMmJ5WEt5ZXdkQ2djYW5lS1YraGt5dnc9PQ==?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS1PR04MB9559.eurprd04.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?ZHpsa0dXSld6cXN5LzR1amE0NmppQnNiNGZIdkJ1WUh1cXQra3JZY1FmWFdx?=
 =?utf-8?B?SE1KWDNkQ3d0ZGVROEZGazYrOW0vVHByMzNBbFNaT2hCaG1WR3JDSDBGbmFZ?=
 =?utf-8?B?Rk5CZHVPT1N5akRLMWRwVTkrTW1oalJSQkc5NGk4SE94b285N0pJQjVDbkpj?=
 =?utf-8?B?U25SYXZFN08ramV1eTllRG1XWkVlaUc5dlNwaEMyN2VSZmNUUHJnOWxjK0dX?=
 =?utf-8?B?S3lvL09HcGZPOC85dEp4SEdlbjQ4WFkweElUT3krWUlheXJFNXVXRjR2akFn?=
 =?utf-8?B?WElGaDhuMHl5TVFVbjl2bFk0SGw3SS9WellqSFYxT0NZNzMyL2ROUEk0dXNz?=
 =?utf-8?B?TFVpV2Qzb2tyUm03UlhVQUdkSmZ4K05DL0VWTS9XaWZMVkh3dGpvYWQ4RTZN?=
 =?utf-8?B?eGhTZVlhSXdhazdJVlk4NGFnQ2lWd2YzeENGeHFKbXcvUDExemVHQURSRERz?=
 =?utf-8?B?aUIxS1dqTHh6ZmRVVUJ6RFNVMnVKcE1EMWMybzhMOXJYTUVHQkZWYkw4Vld0?=
 =?utf-8?B?K0V5a2FjT0pwWCtVb0owZmxSUnBvZlRjbmlLWUFPRTZLTFlHTjliSmYralo1?=
 =?utf-8?B?c3JSM0xrOXlINmFEazNpbHo1aVZXMVlZM3ZnREx6ekJzS2FUR0FmQ2dPL0JM?=
 =?utf-8?B?QzZPRGxRdE5HNmx2OHlISWNJVUxhQUI0bURJc3pnb3Y2WXVsaWQrcldZakZj?=
 =?utf-8?B?UDNUcUdJOW91Z0doZGdrOWFTNy9JZ1VoN05RUm9OLy9RdWc4Y1loSHRHOE1w?=
 =?utf-8?B?elpOakxwWVNBTnpUNVlGY3VFNS9vSEdqeXVKR0JrWHdLZU1YVFlBZU4ySUZ4?=
 =?utf-8?B?dCtOTHhKVmFnMzZDMDVCUkdGQzAvNXZsbE1heHZUNEdPdlJVRml5NlRrdHVx?=
 =?utf-8?B?TEFuTC9iL0RvVVNnUEVJdkpVVk1CblBqd2xiTTE0UkdwdjVNY2xkbDVJaXJr?=
 =?utf-8?B?U3IzREQ2QXpVaUhrWW5jMU1VbkplMm56ODBrYUd5aUltVjE5Y2JPelhwQjdK?=
 =?utf-8?B?WGM5c0xOSFhPK2hEVEhTQzVOOThBS2NQYnFpTXhJTGdQY01FVnRHQWxzbXBR?=
 =?utf-8?B?T21WOExHYnBKZkcrM01qMU5NREJOS0lCLzRQTUZFUENkOXJkTGJvQm5oelFD?=
 =?utf-8?B?Z1cwVmY3anZSSXZ1c2sxOWlERmpya0hnQnJLdUMxazVnTkNCempvWCtLWFll?=
 =?utf-8?B?NEJkWUNuVUlJRGJkYXpRSDZYWnhMODVzWTNXVDhzT2YrRGNGZUlpenJ3QmdH?=
 =?utf-8?B?MVZwcS9ubzhuMS9tZk1TbnByVW1ZcWllWnFhZzlCclpwMUhJVFJKRTcrUFZw?=
 =?utf-8?B?bS9HMzU3anBhNGVhUjBOKzk2U1RVV0dkdXNoNVREeDlQSGtJL1RlODhlZmtq?=
 =?utf-8?B?eXE0Tys1OGtWVkFhRGVnZVpyTXQ0T3d6VU5vSHJtSGUwWTUvaGp5ZElFL3JQ?=
 =?utf-8?B?TG8wQmxMMnpFSkxWWnJqMG04eUZoUlkzVFlFTjUzZG9ZeHhocXg4ZXJYTlc2?=
 =?utf-8?B?eURxNHRuOEozdk5OcktBRlpnVUliSmNOWFF1V3lmaVZ2Mkh1V0taSm5xQkxD?=
 =?utf-8?B?SVJVY1RYVzl0alBMRWRNa0NXWHdHRDB2ZE1mbGF2dkZJZWVON0ZDYm8zVm5w?=
 =?utf-8?B?eXpKTVMyVDFJdnhsM1Bkdlg4a2VvNHNUM1JPd1ljaGhZSVFNZ0YwWHZDb2hu?=
 =?utf-8?B?d2p0VVQ4a2duQVNPc012Q1FBaFBQejBKbW9tWmtnWHpOR3VCakVYc3lyUWFY?=
 =?utf-8?B?QklIUnl3RWxocUhpZ1FYSXJ6U0ROUjhxdk5xeDRmY3FUUVlFc3ltdkRXR2dY?=
 =?utf-8?B?RmFXRWZSMGxFaWN6U2lNbys5QXNHZDFseEVoaG9qMmN6YXdtWVBsYmZoVjlh?=
 =?utf-8?B?UU5ibit2SFdCbWFwSDAydWlIYmJINnR0cHhGVlN1UDdOT1BiaWxYUzJGV2Q0?=
 =?utf-8?B?SEo0eURiSmsrVldpek92Z2ZKbmVxaGl2UVpSYVdzL3JCUms2a2ZnZ0krdjJ3?=
 =?utf-8?B?UU1IU0lrbDZZUlUxVVBaZ3VyMXZjdWpiL3NQYkZ2TUhySWkzc0lZempucldW?=
 =?utf-8?B?MHpCdVo1VU5tTnBWdlhFNEpEWWF4dHdqUDl4MDdhWXJXZ2FUL1o4dlVneVBH?=
 =?utf-8?B?TW0wdjJWaTNrWHVZbEZVdVpqVndJUVQzV0gvNHMxZm95MUdUTVB0cHRWQkRG?=
 =?utf-8?B?QlE9PQ==?=
X-OriginatorOrg: oss.nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b98a5458-34a2-4a5a-29b3-08dd20faba5f
X-MS-Exchange-CrossTenant-AuthSource: AS1PR04MB9559.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Dec 2024 13:32:20.0494
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: SpFp3LJGq6cTQvK9nEETORMjYnLLt7QFacoY8F2FN5PtkGszx8nj6bYPEA3iJ7BfU3vv8XWybFcNDegUWSJHXTMucVW6GnlSfA/vWEvdv8o=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR04MB10846

Hi,


On 20/12/2024 09:32, Michal Orzel wrote:
>
> On 19/12/2024 12:23, Andrei Cherechesu (OSS) wrote:
>>
>> From: Andrei Cherechesu 
>>
>> Targeting: Xen 4.20
>> This v4 version of this patch series finishes the work left to support NXP
>> S32G3 Processors [0], part of the NXP S32CC Family. The LINFlexD UART support
>> patches have been merged in v2. Platforms using S32G3 Processors are not
>> affected by the TLBI by VA erratum (discussed in v2), and are security
>> supported without a workaround needed in Xen or guests. The workaround needed
>> for S32G2 [1] / S32R45 [2] will be addressed in future series.
>>
>> The 1st patch introduces a generic mechanism for forwarding SCMI
>> over SMC calls to firmware running at EL3, selected via
>> CONFIG_SCMI_SMC. The 2nd patch refactors the SiP SMC handling in
>> vSMC mechanism, to rely firstly on `platform_smc()` if implemented,
>> then on the previously introduced generic SCMI handling/forwarding
>> mechanism.
>>
>> The 3rd patch adds S32G3 platform config to enable the required drivers for
>> S32G3-based platforms.
>>
>> The 4th, 5th and 6th patches modify the CHANGELOG.md, SUPPORT.md
>> and MAINTAINERS files, respectively, to add mentions about LINFlexD
>> UART support, S32G3 Processors support, and the new SCMI-SMC layer
>> introduced.
>>
>> [0] https://www.nxp.com/products/S32G3
>> [1] https://www.nxp.com/products/S32G2
>> [2] https://www.nxp.com/products/S32R45
>>
> The series is now committed. Thanks.
>
> ~Michal

Thank you too, Michal, for all the quick feedback you provided!
Glad we've been able to get this in despite the busy period right
before FF for you guys.

I also wanted to thank Julien, Stefano, Grygorii, Oleksii, Bertrand,
Andrew and everyone else who spent time and effort on this series :)

Wish you all relaxing and happy Holidays!

Best regards,
Andrei Cherechesu

>



From xen-devel-bounces@lists.xenproject.org Fri Dec 20 15:20:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 15:20:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861853.1273882 (Exim 4.92)
	(envelope-from )
	id 1tOenE-0003S4-Eb; Fri, 20 Dec 2024 15:19:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861853.1273882; Fri, 20 Dec 2024 15:19:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOenE-0003Rx-Bu; Fri, 20 Dec 2024 15:19:56 +0000
Received: by outflank-mailman (input) for mailman id 861853;
 Fri, 20 Dec 2024 15:19: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 1tOenD-0003Rr-6V
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 15:19:55 +0000
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTP
 id dcb54b76-bee5-11ef-a0d9-8be0dac302b0;
 Fri, 20 Dec 2024 16:19:54 +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 D43231480;
 Fri, 20 Dec 2024 07:20:20 -0800 (PST)
Received: from e125770.cambridge.arm.com (e125770.arm.com [10.1.199.43])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 95E123F528;
 Fri, 20 Dec 2024 07:19: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: dcb54b76-bee5-11ef-a0d9-8be0dac302b0
From: Luca Fancellu 
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk 
Subject: [PATCH] xen/arm: Initialise memory type for struct kernel_info
Date: Fri, 20 Dec 2024 15:19:41 +0000
Message-Id: <20241220151941.4192864-1-luca.fancellu@arm.com>
X-Mailer: git-send-email 2.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Commit a14593e3995a ("xen/device-tree: Allow region overlapping with
/memreserve/ ranges") introduced a type in the 'struct membanks_hdr'
but forgot to update the 'struct kernel_info' initialiser, while
it doesn't lead to failures because the field is not currently
used while managing kernel_info structures, it's good to have it
for completeness.

Fixes: a14593e3995a ("xen/device-tree: Allow region overlapping with /memreserve/ ranges")
Signed-off-by: Luca Fancellu 
---
 xen/arch/arm/include/asm/kernel.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h
index 7e6e3c82a477..de3f945ae54c 100644
--- a/xen/arch/arm/include/asm/kernel.h
+++ b/xen/arch/arm/include/asm/kernel.h
@@ -92,7 +92,9 @@ kernel_info_get_mem_const(const struct kernel_info *kinfo)
 }
 
 #ifdef CONFIG_STATIC_SHM
-#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_SHMEM_BANKS,
+#define KERNEL_INFO_SHM_MEM_INIT                \
+    .shm_mem.common.max_banks = NR_SHMEM_BANKS, \
+    .shm_mem.common.type = STATIC_SHARED_MEMORY,
 #else
 #define KERNEL_INFO_SHM_MEM_INIT
 #endif
@@ -100,6 +102,7 @@ kernel_info_get_mem_const(const struct kernel_info *kinfo)
 #define KERNEL_INFO_INIT                        \
 {                                               \
     .mem.common.max_banks = NR_MEM_BANKS,       \
+    .mem.common.type = MEMORY,                  \
     KERNEL_INFO_SHM_MEM_INIT                    \
 }
 
-- 
2.34.1



From xen-devel-bounces@lists.xenproject.org Fri Dec 20 15:40:03 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 15:40:03 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861864.1273893 (Exim 4.92)
	(envelope-from )
	id 1tOf6c-00068G-3y; Fri, 20 Dec 2024 15:39:58 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861864.1273893; Fri, 20 Dec 2024 15:39: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 1tOf6c-000689-0w; Fri, 20 Dec 2024 15:39:58 +0000
Received: by outflank-mailman (input) for mailman id 861864;
 Fri, 20 Dec 2024 15:39: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 1tOf6a-000682-TV
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 15:39:56 +0000
Received: from NAM11-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam11on20615.outbound.protection.outlook.com
 [2a01:111:f403:2415::615])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a97ced52-bee8-11ef-a0d9-8be0dac302b0;
 Fri, 20 Dec 2024 16:39:55 +0100 (CET)
Received: from SA9P221CA0010.NAMP221.PROD.OUTLOOK.COM (2603:10b6:806:25::15)
 by MW6PR12MB7072.namprd12.prod.outlook.com (2603:10b6:303:238::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.17; Fri, 20 Dec
 2024 15:39:46 +0000
Received: from SA2PEPF00003AE4.namprd02.prod.outlook.com
 (2603:10b6:806:25:cafe::58) by SA9P221CA0010.outlook.office365.com
 (2603:10b6:806:25::15) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8251.24 via Frontend Transport; Fri,
 20 Dec 2024 15:39:46 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 SA2PEPF00003AE4.mail.protection.outlook.com (10.167.248.4) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8251.15 via Frontend Transport; Fri, 20 Dec 2024 15:39:45 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) 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, 20 Dec
 2024 09:39:45 -0600
Received: from [172.18.155.234] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Fri, 20 Dec 2024 09:39:44 -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: a97ced52-bee8-11ef-a0d9-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=n78cBcXrDnzcRg/oKgp08JlxHj78HFjtFkLfW2KWZPJJ/+BuY++lGXNcuC4Pn68mzN3xYtKuQJW/YjSz8pYy4IJVcmbvPJ/ZLFUjFTzk8Gx7DmBrqofqPuoEFXmZ5U8yfaO0Nye4f5qf0XA02BJ0NG2qMGHTGhLMyOhH9J+Py20QOI/TmoxlQPCPn8qNPrr5jbufVcJMJg6KgwfgvaQZrzoA+OLx8fi6gPcIGMlhyKFPVagysqYBTnd9z5ZbyUs8+cOK2zCUZUAkaIfQF0BrWheKUYU5PYQ1UDcRvg9a37sBIBjFrmqmiV6TrOnG/sDce4uKRHgI40LTHxIND9lFbQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xpOFmIDrrLM3gcmeYZK6B8PRv3c0B1xLvAXUsFbFV/I=;
 b=FtzbzS7brfjw5BJympC4lukdAvSFUKSV/0usb2/F9wGq9BVMuXUpjveisVyww1xLuPr/ZFILVILgh3T2ZVKOqw73nI/SG+TuU589kXdbZkmx7wz1/7SdwIE+kusvO7e2NaGWbrM/uPmSR2oGF5aQr6SrPViYu34YgOI9iWBfV4cqr8vW0ujIyRgLENmeHKmYkGQEIY6UpvfWd3Zqza5zXzn2nBDEqsXkqQcsbBvKpPoJpzIQDhSBZuwF0+qiErd4A7mwyBdt4T4SwLa3o/pytH3UkKqEwqkq+X+gNQkyQvwKDMQRll6LA7YC2iTXQScGX35HlYx4x4+u3Am9rwlmew==
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=xpOFmIDrrLM3gcmeYZK6B8PRv3c0B1xLvAXUsFbFV/I=;
 b=5i02Zq8LRG3L9/KSKfibpnNDovj2cSoy89H9jhwU/iEhCmKshT+A621eReoh0LUxptfiW1juTBTogC0QNAYkNbjVbkTRv9Bax2vIYPe3X6VQnzsDB+eO8bjQ1aTX64IrUsRBn+QYGz128JMVUMjaDHmsGr9wCo7+0y4zO+L0Ecc=
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=SATLEXMB04.amd.com; pr=C
Message-ID: 
Date: Fri, 20 Dec 2024 10:38:24 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH Hyperlaunch v2] xenconsole: Add connected flag
To: Jan Beulich 
CC: Anthony PERARD , Juergen Gross
	, 
References: <20241219223222.2211-1-jason.andryuk@amd.com>
 
Content-Language: en-US
From: Jason Andryuk 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SA2PEPF00003AE4:EE_|MW6PR12MB7072:EE_
X-MS-Office365-Filtering-Correlation-Id: e1c85d27-ecf1-497e-93b1-08dd210c87e3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?M1VjWnhyOHFYL01TUXpkUmZCSWw1ekFSazBmS3QwbTdmc1daelIvN1loSVNE?=
 =?utf-8?B?ZkJxb0xSVE9EWi94MWpGdjV2ZEE2cTlGZERjNjNpeVhzWVJaUTVST3ZPRU8z?=
 =?utf-8?B?SituNVR4OWZQQ25IUFRLNTcrU0lyZXV1Yks1bFgrcldaeFpya1RoWURzZmp1?=
 =?utf-8?B?Tks4RXVEMzlWUU1ZRDNLNU00VWNRRWNNNm1BNmF4WTJXSTdnK2JxdmZoOUFp?=
 =?utf-8?B?emtHMURzRU1DWkdmcDVFbi9WZHlvT2pjZnpmc3VHL1c3YThsOU4zVFlxNUwy?=
 =?utf-8?B?SnBOUktLMDRDbStVR2Z2SHFIN3I2Z1dyNGxqWnhsaDlUSnRFajR2ZU1hN216?=
 =?utf-8?B?YUVyTEM2Sks1aVJ6Z0J3SEFrT2FkeWl4bGoydFlkV0FmRkRJT2FWMFhWNlJT?=
 =?utf-8?B?U3d6ODFWdVRCWlM5VFdnM0hYbEY1WEE3cWpENDQxd1AyR3ViK0tSUWJBUW40?=
 =?utf-8?B?L3l4M3FnVlZZRWVHbVJOS21ZQ2FnZ1dNN0lyWjMzYWU3RUVqRUJsb1BYT052?=
 =?utf-8?B?UEJrVTBsRzh2V3lXQUJMZy8vSzdNVHo0OXp2M2lYZzJZL0FTTmcwZXgrVFhQ?=
 =?utf-8?B?a2pUQUZZNlpyTm5aNlUxYTVoQ3l2ZHl5VEVrM1VVT2VrM3VlbkF2V3p4bVdH?=
 =?utf-8?B?RW50b29XUTR0OWZPbVozbFcvYitxakhScWhvVm5lVkQ3OHp3ZjNzQlRlNExH?=
 =?utf-8?B?alNOSmxvYi9YR2tXRVVaVUdkaUVsMzJaS0RyR0ErVjhWQWc0aHdvMmZkbEZn?=
 =?utf-8?B?MnJvRGVYbWhUb1czVXNJeFR5NnhmTUV3MFNIaHFINFpJRTQ0N3pHZGsxQzJG?=
 =?utf-8?B?RUYyaU15QjQ3dFBsZHBQTTJ0Q0l2WVBVMVZ1d2svdzc4RkpIWXYxOUh0U0li?=
 =?utf-8?B?ZDVkSjQrVUhhYi82NkxXV0pUQ2RpWjVHNE1uUDVvNmpjSzBscHcybDczTCtw?=
 =?utf-8?B?RDRKdjdLTk1vUGZDeHlJVXhuOUlpaEluekNuZnYvRG12ZUJmdGxQZlA3OWdu?=
 =?utf-8?B?cldCdTM5enVjT3k1b0FZOWhra0tyVWpDczZ3RmE4YlJGd2NwTlBuTW9HenFP?=
 =?utf-8?B?eklUK0hJdUJkWkV5Ti94TjFvTytsaGRtOENvd0lPUG9qQnk1bkw1WUQrVFpV?=
 =?utf-8?B?L25WWGg0MW1qcFZ1YU41dVVid0FJbGZSWGwzOEFWVmUwdnE4c3VYcytPa3Zw?=
 =?utf-8?B?WXNVeXBCOUF0SWZlUlhFWHNadm9JMUI3MW5zaGphdlM0VTJFbzNBc25FNnJq?=
 =?utf-8?B?UzhwOVFvdldWYW9uQ1hFcEJQNUhoV3RLOVRaTjFjZnRJNGNsSDhpOW1Td3ox?=
 =?utf-8?B?TDdhUlU2ZTBucitkUXVkMHdLS281ZjBPZjFrYTFVSGt2STdXUldyVTlJQWFT?=
 =?utf-8?B?YTh5ZitwMU0xNU1TdWFNeTAzLzdKRmtLNnN1WEdFbnVBMm9EOU1UU0JDeXh5?=
 =?utf-8?B?UkhFWjRxNm5wcWlBZE1BakYwQWRDME00VTBEcGRnNDMwcGlSL0YyY0tRbW92?=
 =?utf-8?B?ZThmbnhBM0E2ZkwyT0ZlS0w2MkY5cmVUSjROUTUyNHFwdGNyRzJKL3dNVjFW?=
 =?utf-8?B?enN0clBMSU5xVGZHRzFwMkdZYTExY1grc3NyVU5MTTBuaVl0N1VnNmNwczdZ?=
 =?utf-8?B?VW11amtJVS9Bbk5WaEw3Z2FjZzl1cFVtYlhnN21xWXlCZ3hwamR1V2RtM3pB?=
 =?utf-8?B?YmQ5RnhIVTF3M3ZlSmFzMzZ0WmRLMTBweU9jMUg3VW9yU21BdTRJSFVha21E?=
 =?utf-8?B?bXE1Q3ltbSt3L2NGdmQ0MkdWVkxQRnZFb1BDQ0ZkTXpWWUtFRFNSak9qMEps?=
 =?utf-8?B?cHNMNVZqRVpOYW1jZXJTcHB1ZVZSZEpjODZTa3VmdXpmVVBYSDlOL0h3VFdl?=
 =?utf-8?B?aGxCS1Zyc1hjK2wrTFRRRUl6OGt3Y0xKdFNUVHZxK2NvU2pDVlMyOWFlZ0xE?=
 =?utf-8?B?ci8rOU4wamtORG5EN3JlajFYSm1tSDluNDMyY2RaWTZzKzJqT3Jvc1lYYWFL?=
 =?utf-8?Q?stQPAVeKVTgQOefkpCyZ/DRP4qOjI8=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Dec 2024 15:39:45.8703
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e1c85d27-ecf1-497e-93b1-08dd210c87e3
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SA2PEPF00003AE4.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB7072

On 2024-12-20 08:00, Jan Beulich wrote:
> On 19.12.2024 23:32, Jason Andryuk wrote:
>> --- a/xen/include/public/io/console.h
>> +++ b/xen/include/public/io/console.h
>> @@ -19,6 +19,19 @@ struct xencons_interface {
>>       char out[2048];
>>       XENCONS_RING_IDX in_cons, in_prod;
>>       XENCONS_RING_IDX out_cons, out_prod;
>> +/*
>> + * Flag values signaling from backend to frontend whether the console is
>> + * connected.  i.e. Whether it will be serviced and emptied.
>> + *
>> + * The flag starts as disconnected.
>> + */
>> +#define XENCONSOLE_DISCONNECTED 0
>> +/*
>> + * The flag is set to connected when the backend connects and the console
>> + * will be serviced.
>> + */
>> +#define XENCONSOLE_CONNECTED    1
>> +    uint32_t flag;
>>   };
> 
> Given no other information, how would a guest know that it can actually
> expect the flag to (eventually) become set?

You mean that without some other flag to indicate the presence of this 
flag, the guest wouldn't know whether this field should change?  Yes, 
that is a good point.

Non-hyperlaunch, a new xenconsoled would set the flag ~before the guest 
starts.  AIUI, there is no explicit synchronization between the 
toolstack and xenconsoled that the console is connected before the guest 
is unpaused.

Old kernels without checking the flag will just use the console.

A new kernel, with an old xenconsoled, would never see the flag set and 
would never use the console.

Thanks,
Jason


From xen-devel-bounces@lists.xenproject.org Fri Dec 20 16:35:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 16:35:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861875.1273903 (Exim 4.92)
	(envelope-from )
	id 1tOfxZ-0005MB-Pk; Fri, 20 Dec 2024 16:34:41 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861875.1273903; Fri, 20 Dec 2024 16:34: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 1tOfxZ-0005M4-M8; Fri, 20 Dec 2024 16:34:41 +0000
Received: by outflank-mailman (input) for mailman id 861875;
 Fri, 20 Dec 2024 16:34: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 1tOfxY-0005Ly-Bv
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 16:34:40 +0000
Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com
 [2607:f8b0:4864:20::22a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4cbf1d52-bef0-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 17:34:36 +0100 (CET)
Received: by mail-oi1-x22a.google.com with SMTP id
 5614622812f47-3eb96351ba1so172580b6e.0
 for ; Fri, 20 Dec 2024 08:34: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: 4cbf1d52-bef0-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734712475; x=1735317275; 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=k0Pq3MeH68M1UvmnuofFPSaKmyzx82nizriI91/fVz8=;
        b=Ug/qZC6NxfAehI4MuAgYs+BGFmFnSqj/ov4azlZjVx3NexjQilqCjxqIuY1XAUB5VO
         qfKIoWvnojdiyqpLUWdm1Cvn5joCllj6ETcG4+dgD9nMsmZZnLCh3m8zN6ImVYYJlSzA
         TE+NqbVtsZWFEOaEJwsp6ZxYJNDXZoqb/SH6+qvPN7GgzXgs9tmIqzp87Kj+OYqtyCpU
         qNSKw29ATx0EWqcUEINO66PaE26hcW6t3IaoVHJqjIPI5LcdijUjkDmpJI2grYT1Odta
         HpspvlKQYWVV8BYdrgb7xrbYpKbKbrn4pSWD3ElV4FWHCMT0Kxx80xE1CZDg7Wv09O0K
         8v1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734712475; x=1735317275;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=k0Pq3MeH68M1UvmnuofFPSaKmyzx82nizriI91/fVz8=;
        b=XelNc/AUSKoJiu8ORU6zyFdULzI2rSs9F60qq5A2NLpb9UvfY30tvT7nMYSasbPLwA
         nJnUC7nBl9RVXmx+7qO/7FQcGHLMfIi9gxx8EzODZBrZ0kgmrRxx3gsNzZoT0+Im9GuE
         Ozsl9M9jYkc5AGFckYTdzg4GJzxb3eSp1j65ijlw7WvppGy/eK4F0S1j3LEN+3nsk85X
         amKxA9LQnP2XlwwxpZyCZQbFAjboCvfbeJBY/NHPdr8KkuiKn3atFWxZsFnIfjncm87+
         ftvJm4e2IKrLsLnAbbw3eHakHxSqLAA2ZUf0z9cTP5bhnqy1vSr2gcECPbV5jrUVGH9m
         JarA==
X-Forwarded-Encrypted: i=1; AJvYcCXa0BJVuAwh7/irCg1U3HZ6fwLfncQpb20/9oNs58vR05COmMpS/DHrZrTDwg9cdQ46ep/cLmSGAg0=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyUPUEBugyzqrSLgACr+8PgSMzybr5uhw5OCEykwRDazHCbMbhM
	xaOFrcmdexUS3VhWe491qxVYTGPFT3VVkEkpA8uM0sGM+chrKxI9zO+j13Ov70VEZvP9JfDNrWh
	R3SyXD/Dj/ap++yQSgNcYfymbiTM=
X-Gm-Gg: ASbGncue3vgjCK1BhFGjytF5PO52GVNWgS1mRRrFxo0+ythZeEP+0FV0UxR4JUpYySh
	+w5j5dngvd4CRpAGxQDaQ+7+lnj86YU7Hq0qrqyLsqtdJKIS0nA+ZpHPlUOKxvHuKB+PMqYV6
X-Google-Smtp-Source: AGHT+IF7T3v9F20EhB0c5dTGDsFetVEVgBnpzgiCQxXsPUZfuz5TOqJzJZ+NpYnUfsyUZTWAMwpYzE8q7yBAg80xQyY=
X-Received: by 2002:a05:6871:d10a:b0:29e:5f79:21b4 with SMTP id
 586e51a60fabf-2a7fb423b4fmr725224fac.13.1734712475453; Fri, 20 Dec 2024
 08:34:35 -0800 (PST)
MIME-Version: 1.0
References:  
 <258c4e83-4379-4212-b80a-4fe909849e66@suse.com>
In-Reply-To: <258c4e83-4379-4212-b80a-4fe909849e66@suse.com>
From: =?UTF-8?Q?Petr_Bene=C5=A1?= 
Date: Fri, 20 Dec 2024 17:34:22 +0100
Message-ID: 
Subject: Re: [PATCH v2 2/2] x86: Add Support for Paging-Write Feature
To: Jan Beulich 
Cc: Tamas K Lengyel , Alexandru Isaila , 
	Petre Pircalabu , Stefano Stabellini , 
	Julien Grall , Bertrand Marquis , 
	Michal Orzel , Volodymyr Babchuk , 
	Andrew Cooper , Anthony PERARD , 
	=?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , 
	xen-devel@lists.xenproject.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 20, 2024 at 2:09=E2=80=AFPM Jan Beulich  wro=
te:
>
> To avoid the flag becoming "sticky", I think you need to clear it ahead o=
f
> this switch() (or right at the start of the function).
>
> Jan

When thinking about it now, wouldn't it make sense to only reset it in
the p2m_ram_rw case above? I mean, where else would be guest
page-tables located.

P.


From xen-devel-bounces@lists.xenproject.org Fri Dec 20 16:59:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 16:59:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861886.1273922 (Exim 4.92)
	(envelope-from )
	id 1tOgLD-0008Qk-Ob; Fri, 20 Dec 2024 16:59:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861886.1273922; Fri, 20 Dec 2024 16:59: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 1tOgLD-0008Qd-Lt; Fri, 20 Dec 2024 16:59:07 +0000
Received: by outflank-mailman (input) for mailman id 861886;
 Fri, 20 Dec 2024 16:59: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 1tOgLC-0008Bw-Da
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 16:59:06 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b814d637-bef3-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 17:59:04 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 20 Dec 2024 17:59:04 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id 4EA3C249C;
 Fri, 20 Dec 2024 17:59:04 +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: b814d637-bef3-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734713944; x=1766249944;
  h=from:to:cc:subject:date:message-id:in-reply-to:
   references:mime-version:content-transfer-encoding;
  bh=4i2tjOWPEe+/kqhdo4JieYd+715XS4qCn1BWn9RgnsE=;
  b=aKILMVjJcSP+tXzoGnssk9IJKKwuOT4YnuWKa05rr3CSX0aqzvJySQry
   uaMPAIrxca1W3cA2icpObEoDksBCAGE9ue5CgOU+pHsHZ8+AuR0bmNh3O
   3YaDvbUTC1xZxH6+5kQeLeu3Qz8ghpueSzloSeZg4A1fD6WLBYHoV2zqp
   U=;
X-CSE-ConnectionGUID: YaCuNDfVTTqxD/b62A41jQ==
X-CSE-MsgGUID: a8VQNH35ThW9kSqhvOiLnA==
X-IronPort-AV: E=Sophos;i="6.12,251,1728943200"; 
   d="scan'208";a="28280239"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Ariel Otilibili ,
	Anthony PERARD ,
	Juergen Gross ,
	"Daniel P. Smith" 
Subject: [PATCH 1/2] tools/libs: remove dead code
Date: Fri, 20 Dec 2024 17:55:01 +0100
Message-ID: <20241220165837.937976-2-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20241220165837.937976-1-Ariel.Otilibili-Anieli@eurecom.fr>
References: <20241220165837.937976-1-Ariel.Otilibili-Anieli@eurecom.fr>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Default switch cases skip these steps; these instructions are never reached.

Coverity-IDs: 1056148, 1056149
Fixes: 0a69ea908d ("libxl: ao: convert libxl__spawn_*")
Fixes: 643b106b40 ("libxl: do not use tap disk backend other than for raw and vhd")
Signed-off-by: Ariel Otilibili 
--
Cc: Anthony PERARD 
Cc: Juergen Gross 
Cc: "Daniel P. Smith" 
---
 tools/libs/light/libxl_create.c | 1 -
 tools/libs/light/libxl_device.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
index e03599ea99..d0271bef7e 100644
--- a/tools/libs/light/libxl_create.c
+++ b/tools/libs/light/libxl_create.c
@@ -1890,7 +1890,6 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *multidev,
         ret = ERROR_INVAL;
         goto error_out;
     }
-    abort(); /* not reached */
 
  error_out:
     assert(ret);
diff --git a/tools/libs/light/libxl_device.c b/tools/libs/light/libxl_device.c
index 4faa5fa3bd..96046803e1 100644
--- a/tools/libs/light/libxl_device.c
+++ b/tools/libs/light/libxl_device.c
@@ -392,7 +392,6 @@ static int disk_try_backend(disk_try_backend_args *a,
         return 0;
 
     }
-    abort(); /* notreached */
 
  bad_format:
     LOG(DEBUG, "Disk vdev=%s, backend %s unsuitable due to format %s",
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Fri Dec 20 16:59:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 16:59:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861885.1273913 (Exim 4.92)
	(envelope-from )
	id 1tOgLB-0008Ca-IK; Fri, 20 Dec 2024 16:59:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861885.1273913; Fri, 20 Dec 2024 16:59: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 1tOgLB-0008CT-F8; Fri, 20 Dec 2024 16:59:05 +0000
Received: by outflank-mailman (input) for mailman id 861885;
 Fri, 20 Dec 2024 16:59: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 1tOgL9-0008Bw-9w
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 16:59:04 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b52dad4b-bef3-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 17:59:00 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 20 Dec 2024 17:58:59 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id EAAAF249B;
 Fri, 20 Dec 2024 17:58:58 +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: b52dad4b-bef3-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734713940; x=1766249940;
  h=from:to:cc:subject:date:message-id:mime-version:
   content-transfer-encoding;
  bh=6ayZlOYbibzJJ0P/4FSByg1LP3Aw1qXMWugsZckGMwU=;
  b=IOJEdC2Ae8pEQA48j2xpeetc99fUgKsHN5SizhRSahKRJJpnjyokln3S
   OJqzX0nsXZp+NT9lzBmlpjUXvK9A3scHUMdEHfMrhSOeV46b2Efw2e548
   51gDpz/lh5vP32Ur9Frf7VZCUtNt61ZgSGzVKySJqE1W8oIH9cRumgOQG
   E=;
X-CSE-ConnectionGUID: ABl+VTsURsqIcznGdeA1sg==
X-CSE-MsgGUID: pyKCtXeXQrKPT36fqiP3Bg==
X-IronPort-AV: E=Sophos;i="6.12,251,1728943200"; 
   d="scan'208";a="28280238"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Ariel Otilibili ,
	Doug Goldstein ,
	Anthony PERARD ,
	Juergen Gross ,
	"Daniel P. Smith" 
Subject: [PATCH 0/2] tools/libs,xen/tools: remove dead code
Date: Fri, 20 Dec 2024 17:55:00 +0100
Message-ID: <20241220165837.937976-1-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hello,

This series addresses the Coverity IDs 1056148, 1056149, & 1458052.

Thank you,

Ariel Otilibili (2):
  tools/libs: remove dead code
  xen/tools: remove dead code

 tools/libs/light/libxl_create.c | 1 -
 tools/libs/light/libxl_device.c | 1 -
 xen/tools/kconfig/expr.c        | 2 --
 3 files changed, 4 deletions(-)

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Fri Dec 20 16:59:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 16:59:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861887.1273933 (Exim 4.92)
	(envelope-from )
	id 1tOgLQ-0000N6-0d; Fri, 20 Dec 2024 16:59:20 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861887.1273933; Fri, 20 Dec 2024 16:59: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 1tOgLP-0000Mw-Sn; Fri, 20 Dec 2024 16:59:19 +0000
Received: by outflank-mailman (input) for mailman id 861887;
 Fri, 20 Dec 2024 16:59: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 1tOgLP-0008Bw-AQ
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 16:59:19 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bfb58e36-bef3-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 17:59:17 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 20 Dec 2024 17:59:17 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id 2BD21249D;
 Fri, 20 Dec 2024 17:59:17 +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: bfb58e36-bef3-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734713957; x=1766249957;
  h=from:to:cc:subject:date:message-id:in-reply-to:
   references:mime-version:content-transfer-encoding;
  bh=zjQnlMsaSGWfGsQEe6M09GEFyw9td1gDFl+U5txZ89s=;
  b=QNQl3IpmWOzv3WWYmpsaaSdWT+2j/hiYC/YrZt4bDwYQU26+zNXAoQ1T
   /u1baMrzmM+giPrR4waWhw75hM9tjmWhHEEnm9BpCDzNZ5cCuSzfQT/Zf
   btRZZOpFQUq0Rcq9C/Li4z2FBeKkeYte6Gz4eXGxk1T+lWu/S5ZGhpsNJ
   I=;
X-CSE-ConnectionGUID: QKe6ummCS/WzZkNaNCWGTQ==
X-CSE-MsgGUID: +PZQN/0yRXq89cbRwlaFoQ==
X-IronPort-AV: E=Sophos;i="6.12,251,1728943200"; 
   d="scan'208";a="28280241"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Ariel Otilibili ,
	Doug Goldstein 
Subject: [PATCH 2/2] xen/tools: remove dead code
Date: Fri, 20 Dec 2024 17:55:02 +0100
Message-ID: <20241220165837.937976-3-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20241220165837.937976-1-Ariel.Otilibili-Anieli@eurecom.fr>
References: <20241220165837.937976-1-Ariel.Otilibili-Anieli@eurecom.fr>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Default switch case exits directly; these instructions are never reached.

The file was taken from Linux; the copies have diverged a lot since:

```
$ diff -u xen/xen/tools/kconfig/expr.c linux/scripts/kconfig/expr.c | wc -l
984
```

Therefore the change is only applied locally.

Coverity-ID: 1458052
Fixes: 8c271b7584 ("build: import Kbuild/Kconfig from Linux 4.3")
Signed-off-by: Ariel Otilibili 
--
Cc: Doug Goldstein 
---
 xen/tools/kconfig/expr.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/xen/tools/kconfig/expr.c b/xen/tools/kconfig/expr.c
index 77ffff3a05..be1400cdaf 100644
--- a/xen/tools/kconfig/expr.c
+++ b/xen/tools/kconfig/expr.c
@@ -1125,8 +1125,6 @@ static int expr_compare_type(enum expr_type t1, enum expr_type t2)
 	default:
 		return -1;
 	}
-	printf("[%dgt%d?]", t1, t2);
-	return 0;
 }
 
 void expr_print(struct expr *e,
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Fri Dec 20 17:53:47 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 17:53:47 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861917.1273942 (Exim 4.92)
	(envelope-from )
	id 1tOhBq-0000JB-Jd; Fri, 20 Dec 2024 17:53:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861917.1273942; Fri, 20 Dec 2024 17:53: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 1tOhBq-0000J3-Gg; Fri, 20 Dec 2024 17:53:30 +0000
Received: by outflank-mailman (input) for mailman id 861917;
 Fri, 20 Dec 2024 17:53:29 +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 1tOhBp-0000Ix-QG
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 17:53:29 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4ef1943d-befb-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 18:53:25 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 7B8A18287D0A;
 Fri, 20 Dec 2024 11:53:23 -0600 (CST)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id tdhroVnxOWiB; Fri, 20 Dec 2024 11:53:21 -0600 (CST)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id A3CC382882BA;
 Fri, 20 Dec 2024 11:53:21 -0600 (CST)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id vF4WhFnpxmz2; Fri, 20 Dec 2024 11:53:21 -0600 (CST)
Received: from raptor-ewks-026.2lan (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id AC8258287D0A;
 Fri, 20 Dec 2024 11:53:20 -0600 (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: 4ef1943d-befb-11ef-99a3-01e77a169b0f
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com A3CC382882BA
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1734717201; bh=1M30qCu70QxS1iS2rTkvPc0MtDhcU1c98G6UK6Sk2C4=;
	h=From:To:Date:Message-Id:MIME-Version;
	b=X4gDPENodgEGwi7okwG/XK+eYr9nF2dlQwuNnnrWmR4V8wi0RFChT/xSFwyurrVXc
	 G1VQATPfngCZ0kf/0evUoP7Oz7D2v1UEXlRKKa01l382yOKViGVuo4MYQb7zfxZ7aa
	 Fh9f4kKa4BOloQco5QS/Zk4BErO0nOqrnAP+lzFE=
X-Virus-Scanned: amavisd-new at rptsys.com
From: Shawn Anastasio 
To: xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com,
	Shawn Anastasio ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Oleksii Kurochko ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH] xen/mm: Update page APIs to use unsigned long flags
Date: Fri, 20 Dec 2024 11:53:09 -0600
Message-Id: <7e3cd1dc48e30f19f2ac97794e21d1b78bc0c082.1734717055.git.sanastasio@raptorengineering.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Xen's memory management APIs map_pages_to_xen, modify_xen_mappings,
set_fixmap, ioremap_attr, and __vmap all use an unsigned int to
represent architecture-dependent page table entry flags. This assumption
does not work on PPC/radix where some flags go past 32-bits, so update
these APIs to use unsigned long for flags instead.

Signed-off-by: Shawn Anastasio 
---
 xen/arch/arm/include/asm/fixmap.h   | 2 +-
 xen/arch/arm/include/asm/mm.h       | 2 +-
 xen/arch/arm/mmu/pt.c               | 8 ++++----
 xen/arch/ppc/mm-radix.c             | 2 +-
 xen/arch/riscv/include/asm/fixmap.h | 2 +-
 xen/arch/riscv/pt.c                 | 4 ++--
 xen/arch/x86/mm.c                   | 4 ++--
 xen/common/efi/boot.c               | 4 ++--
 xen/common/vmap.c                   | 2 +-
 xen/include/xen/mm.h                | 4 ++--
 xen/include/xen/vmap.h              | 2 +-
 11 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/include/asm/fixmap.h b/xen/arch/arm/include/asm/fixmap.h
index 0cb5d54d1c..96361e670f 100644
--- a/xen/arch/arm/include/asm/fixmap.h
+++ b/xen/arch/arm/include/asm/fixmap.h
@@ -30,7 +30,7 @@
 extern lpae_t xen_fixmap[XEN_PT_LPAE_ENTRIES];
 
 /* Map a page in a fixmap entry */
-extern void set_fixmap(unsigned int map, mfn_t mfn, unsigned int flags);
+extern void set_fixmap(unsigned int map, mfn_t mfn, unsigned long flags);
 /* Remove a mapping from a fixmap entry */
 extern void clear_fixmap(unsigned int map);
 
diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
index 59b774b7b8..4cfd71538b 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -209,7 +209,7 @@ extern int prepare_secondary_mm(int cpu);
 /* Map a frame table to cover physical addresses ps through pe */
 extern void setup_frametable_mappings(paddr_t ps, paddr_t pe);
 /* map a physical range in virtual memory */
-void __iomem *ioremap_attr(paddr_t start, size_t len, unsigned int attributes);
+void __iomem *ioremap_attr(paddr_t start, size_t len, unsigned long attributes);
 
 static inline void __iomem *ioremap_nocache(paddr_t start, size_t len)
 {
diff --git a/xen/arch/arm/mmu/pt.c b/xen/arch/arm/mmu/pt.c
index da28d669e7..f8967fca01 100644
--- a/xen/arch/arm/mmu/pt.c
+++ b/xen/arch/arm/mmu/pt.c
@@ -189,7 +189,7 @@ lpae_t mfn_to_xen_entry(mfn_t mfn, unsigned int attr)
 }
 
 /* Map a 4k page in a fixmap entry */
-void set_fixmap(unsigned int map, mfn_t mfn, unsigned int flags)
+void set_fixmap(unsigned int map, mfn_t mfn, unsigned long flags)
 {
     int res;
 
@@ -210,7 +210,7 @@ void clear_fixmap(unsigned int map)
  * This function should only be used to remap device address ranges
  * TODO: add a check to verify this assumption
  */
-void *ioremap_attr(paddr_t start, size_t len, unsigned int attributes)
+void *ioremap_attr(paddr_t start, size_t len, unsigned long attributes)
 {
     mfn_t mfn = _mfn(PFN_DOWN(start));
     unsigned int offs = start & (PAGE_SIZE - 1);
@@ -701,7 +701,7 @@ static int xen_pt_update(unsigned long virt,
 int map_pages_to_xen(unsigned long virt,
                      mfn_t mfn,
                      unsigned long nr_mfns,
-                     unsigned int flags)
+                     unsigned long flags)
 {
     return xen_pt_update(virt, mfn, nr_mfns, flags);
 }
@@ -719,7 +719,7 @@ int destroy_xen_mappings(unsigned long s, unsigned long e)
     return xen_pt_update(s, INVALID_MFN, (e - s) >> PAGE_SHIFT, 0);
 }
 
-int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
+int modify_xen_mappings(unsigned long s, unsigned long e, unsigned long nf)
 {
     ASSERT(IS_ALIGNED(s, PAGE_SIZE));
     ASSERT(IS_ALIGNED(e, PAGE_SIZE));
diff --git a/xen/arch/ppc/mm-radix.c b/xen/arch/ppc/mm-radix.c
index 1ca3bcba7f..fa326a159b 100644
--- a/xen/arch/ppc/mm-radix.c
+++ b/xen/arch/ppc/mm-radix.c
@@ -285,7 +285,7 @@ int destroy_xen_mappings(unsigned long s, unsigned long e)
 int map_pages_to_xen(unsigned long virt,
                      mfn_t mfn,
                      unsigned long nr_mfns,
-                     unsigned int flags)
+                     unsigned long flags)
 {
     BUG_ON("unimplemented");
 }
diff --git a/xen/arch/riscv/include/asm/fixmap.h b/xen/arch/riscv/include/asm/fixmap.h
index e399a15f53..7302a5c052 100644
--- a/xen/arch/riscv/include/asm/fixmap.h
+++ b/xen/arch/riscv/include/asm/fixmap.h
@@ -33,7 +33,7 @@
 extern pte_t xen_fixmap[];
 
 /* Map a page in a fixmap entry */
-void set_fixmap(unsigned int map, mfn_t mfn, unsigned int flags);
+void set_fixmap(unsigned int map, mfn_t mfn, unsigned long flags);
 /* Remove a mapping from a fixmap entry */
 void clear_fixmap(unsigned int map);
 
diff --git a/xen/arch/riscv/pt.c b/xen/arch/riscv/pt.c
index a703e0f1bd..4334db8cce 100644
--- a/xen/arch/riscv/pt.c
+++ b/xen/arch/riscv/pt.c
@@ -405,7 +405,7 @@ static int pt_update(vaddr_t virt, mfn_t mfn,
 int map_pages_to_xen(unsigned long virt,
                      mfn_t mfn,
                      unsigned long nr_mfns,
-                     unsigned int flags)
+                     unsigned long flags)
 {
     /*
      * Ensure that flags has PTE_VALID bit as map_pages_to_xen() is supposed
@@ -436,7 +436,7 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns)
 }
 
 /* Map a 4k page in a fixmap entry */
-void set_fixmap(unsigned int map, mfn_t mfn, unsigned int flags)
+void set_fixmap(unsigned int map, mfn_t mfn, unsigned long flags)
 {
     if ( map_pages_to_xen(FIXMAP_ADDR(map), mfn, 1, flags | PTE_SMALL) != 0 )
         BUG();
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index fa21903eb2..a5b74dad38 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5469,7 +5469,7 @@ int map_pages_to_xen(
     unsigned long virt,
     mfn_t mfn,
     unsigned long nr_mfns,
-    unsigned int flags)
+    unsigned long flags)
 {
     bool locking = system_state > SYS_STATE_boot;
     l3_pgentry_t *pl3e = NULL, ol3e;
@@ -5887,7 +5887,7 @@ int __init populate_pt_range(unsigned long virt, unsigned long nr_mfns)
  *
  * It is an error to call with present flags over an unpopulated range.
  */
-int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
+int modify_xen_mappings(unsigned long s, unsigned long e, unsigned long nf)
 {
     bool locking = system_state > SYS_STATE_boot;
     l3_pgentry_t *pl3e = NULL;
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index efbec00af9..76215cb6b9 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1656,7 +1656,7 @@ void __init efi_init_memory(void)
     struct rt_extra {
         struct rt_extra *next;
         unsigned long smfn, emfn;
-        unsigned int prot;
+        unsigned long prot;
     } *extra, *extra_head = NULL;
 
     free_ebmalloc_unused_mem();
@@ -1671,7 +1671,7 @@ void __init efi_init_memory(void)
         EFI_MEMORY_DESCRIPTOR *desc = efi_memmap + i;
         u64 len = desc->NumberOfPages << EFI_PAGE_SHIFT;
         unsigned long smfn, emfn;
-        unsigned int prot = PAGE_HYPERVISOR_RWX;
+        unsigned long prot = PAGE_HYPERVISOR_RWX;
         paddr_t mem_base;
         unsigned long mem_npages;
 
diff --git a/xen/common/vmap.c b/xen/common/vmap.c
index 47225fecc0..c2d86fff74 100644
--- a/xen/common/vmap.c
+++ b/xen/common/vmap.c
@@ -222,7 +222,7 @@ static void vm_free(const void *va)
 }
 
 void *__vmap(const mfn_t *mfn, unsigned int granularity,
-             unsigned int nr, unsigned int align, unsigned int flags,
+             unsigned int nr, unsigned int align, unsigned long flags,
              enum vmap_region type)
 {
     void *va = vm_alloc(nr * granularity, align, type);
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 16f733281a..9efddc51bc 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -113,9 +113,9 @@ int map_pages_to_xen(
     unsigned long virt,
     mfn_t mfn,
     unsigned long nr_mfns,
-    unsigned int flags);
+    unsigned long flags);
 /* Alter the permissions of a range of Xen virtual address space. */
-int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf);
+int modify_xen_mappings(unsigned long s, unsigned long e, unsigned long nf);
 void modify_xen_mappings_lite(unsigned long s, unsigned long e,
                               unsigned int nf);
 int destroy_xen_mappings(unsigned long s, unsigned long e);
diff --git a/xen/include/xen/vmap.h b/xen/include/xen/vmap.h
index 26c831757a..65403c77e9 100644
--- a/xen/include/xen/vmap.h
+++ b/xen/include/xen/vmap.h
@@ -57,7 +57,7 @@ void vm_init_type(enum vmap_region type, void *start, void *end);
  * @return Pointer to the mapped area on success; NULL otherwise.
  */
 void *__vmap(const mfn_t *mfn, unsigned int granularity, unsigned int nr,
-             unsigned int align, unsigned int flags, enum vmap_region type);
+             unsigned int align, unsigned long flags, enum vmap_region type);
 
 /*
  * Map an array of pages contiguously into the VMAP_DEFAULT vmap region
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Fri Dec 20 18:23:57 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 18:23:57 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861931.1273953 (Exim 4.92)
	(envelope-from )
	id 1tOhfB-0004Xy-To; Fri, 20 Dec 2024 18:23:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861931.1273953; Fri, 20 Dec 2024 18:23:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOhfB-0004Xr-R8; Fri, 20 Dec 2024 18:23:49 +0000
Received: by outflank-mailman (input) for mailman id 861931;
 Fri, 20 Dec 2024 18:23: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 1tOhfB-0004Xl-01
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 18:23:49 +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 8d41a8b5-beff-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 19:23:46 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-38789e5b6a7so1273429f8f.1
 for ; Fri, 20 Dec 2024 10:23:46 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c828989sm4660911f8f.18.2024.12.20.10.23.45
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 20 Dec 2024 10:23: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: 8d41a8b5-beff-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734719026; x=1735323826; 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=aclACXu6lovA0hOGI1H1FOsblWrNiu+UaJFlPU9U2hw=;
        b=BEssFw1Xh6ne+hMi1ZDcd9CVEbGY5zU2OMz9uheQZhPaECfQG1TnOQZyPOrIBqiTuj
         Se8YKnwJ5CQwyp3WXAHwO2JVqxSzq7ibXyfOJJw2012PifZQ48Xgja8UYmx0LxZWybj2
         XNnttA6/SQRqlRkH4KujMwRdvTfunCkR58PFo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734719026; x=1735323826;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=aclACXu6lovA0hOGI1H1FOsblWrNiu+UaJFlPU9U2hw=;
        b=ZQxCw29cYff9ZdMEMegeF16qnWik/VbbB108iJh0TqlLrBNL7PILX9yQT1S2wi+pyD
         yCAqk0sOGrKEVQZQ5YfrQPEzOdF1Y60+vNKGPXFBJuNB+Y08L4UTc0RhTQP8R9WZ0Klc
         wnOs+XSRNTbWGk3R+0/2lqydULZTCBluiWWP+6HDkapanCPd/ZxYQDvKzEgyhkJ5RJ20
         0ztwDV++fwwAq8V5FPNoyzUoAByg1RrqVeG1Bsg02dRBo6yXwSJIMK4m8Jz6NaJCboXU
         j53Qp6OqJyehw8Xw6NPnukQbxZxxDqLpbwazR4y818g67mqmgfAJAr0uUKlxtKE0Mx0c
         4NMw==
X-Forwarded-Encrypted: i=1; AJvYcCV0PLQr3Pr5AipvqHH7tPDiORx2rjduejpRaxY5gComELq8jjnk+zi6sKwTwY2FZYIz8lxCJQbHrl8=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyCbgkwjY92vkyjNgaXNXa8eJTJj4dAqGzKgHwmMYVLiVubWyAg
	AKzdz+RmdKGRBBnamHF0GZSyy6XEuPnwIaoVCct5C3Ex0LS0aGm5ZSbmMD5ZhFQ=
X-Gm-Gg: ASbGncu/7JcVC3FFBlyLBEzL/yQML7NiMi3cQB+dxBl/43H6zHtwabSLYjQzKSLWLmr
	DddCdhXY6sfj1YubhdpRyKapFGl8toeo3+1yWSmvYL/rkpv4A/ufwQFswCkK4G0iUcmSmb4aVOi
	mp9mekHmRBTAclLS84TndtcOXYA4tJ04Fw6UrhUzD4axTaBvN/Kb6gTttrO0iyp7mZaPC475ERN
	JG5pQrD9DwvKUrecNKpnd8zqztbLK3OmDZmmX8MiwVC4nZFpUeZerywAL510DIXZyVnN+avw9oF
	iMYJZyWZWyMjnDELRcxK
X-Google-Smtp-Source: AGHT+IEiKtAdVad+DE5kVaHk6lQKK+u6uQ4RsTLJxHKqZJEiAvfzzx+RFXT3+sYtuqXv6NGzZYOmSQ==
X-Received: by 2002:a05:6000:154f:b0:385:ef2f:92ad with SMTP id ffacd0b85a97d-38a221e181cmr4329900f8f.10.1734719026321;
        Fri, 20 Dec 2024 10:23:46 -0800 (PST)
Message-ID: 
Date: Fri, 20 Dec 2024 18:23:44 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/mm: Update page APIs to use unsigned long flags
To: Shawn Anastasio ,
 xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Oleksii Kurochko ,
 "Daniel P. Smith" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
References: <7e3cd1dc48e30f19f2ac97794e21d1b78bc0c082.1734717055.git.sanastasio@raptorengineering.com>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <7e3cd1dc48e30f19f2ac97794e21d1b78bc0c082.1734717055.git.sanastasio@raptorengineering.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20/12/2024 5:53 pm, Shawn Anastasio wrote:
> Xen's memory management APIs map_pages_to_xen, modify_xen_mappings,
> set_fixmap, ioremap_attr, and __vmap all use an unsigned int to
> represent architecture-dependent page table entry flags. This assumption
> does not work on PPC/radix where some flags go past 32-bits, so update
> these APIs to use unsigned long for flags instead.
>
> Signed-off-by: Shawn Anastasio 

Funnily enough, the same is true on x86 too.  NX and ProtKey bits are
from bit 63 downwards.

x86 funnels all PTE flags through {get,put}_pte_flags() which compresses
a 64bit PTE's flags (top and bottom 12 bits) into a 24 bit number.

This was allegedly for the benefit of 32bit builds of Xen with PAE
paging.  I'm not convinced this claim was backed up evidence, even in
the 32bit days, because the areas of code working on flags separately
from a 64bit PTE are minimal.

Nevertheless, it's been 11 years since we dropped x86_32, and it's
definitely tech debt and unnecessary overhead in x86_64.


I firmly support making this adjustment.  It's been on my todo list for
years, but never high enough to get started.

However, instead of just a plain unsigned long, perhaps we should have a
concrete type, perhaps pte_attr_t ?

This lets different architectures handle things differently, and also
lets us make it TYPE_SAFE() like mfn and friends.

Most importantly though, it makes it less likely that we're going to end
up with paths that accidentally have some long->int truncation.

Thoughts?

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Dec 20 18:52:10 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 18:52:10 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861945.1273962 (Exim 4.92)
	(envelope-from )
	id 1tOi6V-0008Mw-1a; Fri, 20 Dec 2024 18:52:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861945.1273962; Fri, 20 Dec 2024 18:52: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 1tOi6U-0008Mp-VL; Fri, 20 Dec 2024 18:52:02 +0000
Received: by outflank-mailman (input) for mailman id 861945;
 Fri, 20 Dec 2024 18:52: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 1tOi6T-0008Mi-EG
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 18:52:01 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 7da1dad0-bf03-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 19:51:59 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id D8C668287F4B;
 Fri, 20 Dec 2024 12:51:57 -0600 (CST)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id l37Pon1itDYr; Fri, 20 Dec 2024 12:51:57 -0600 (CST)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id F0B7D8287F7B;
 Fri, 20 Dec 2024 12:51:56 -0600 (CST)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id lN1He4_pV2pG; Fri, 20 Dec 2024 12:51:56 -0600 (CST)
Received: from [10.11.0.2] (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id 29ABB8287F4B;
 Fri, 20 Dec 2024 12:51:56 -0600 (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: 7da1dad0-bf03-11ef-99a3-01e77a169b0f
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com F0B7D8287F7B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1734720717; bh=oC83UZQmLWfaSJ1UzK3vR0Kcl/4T8SUXq0jOz1leuRM=;
	h=Message-ID:Date:MIME-Version:To:From;
	b=K2w7LFjZAd/MKLfCdZbqOZU7nkfbbZ54h83Cie1EzNN82t5IoiOyzkWpM52uPBSRP
	 xavArstb54c527yOPW2qozHEPPACX/2ZqPq0xO02q+KldyauZRpctpVll666eBY7zd
	 Yd3qtWcdUMq76mQUG4eIXE7oi5w0hW44v2S6QDGk=
X-Virus-Scanned: amavisd-new at rptsys.com
Message-ID: 
Date: Fri, 20 Dec 2024 12:51:55 -0600
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/mm: Update page APIs to use unsigned long flags
To: Andrew Cooper , xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Oleksii Kurochko ,
 "Daniel P. Smith" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
References: <7e3cd1dc48e30f19f2ac97794e21d1b78bc0c082.1734717055.git.sanastasio@raptorengineering.com>
 
Content-Language: en-US
From: Shawn Anastasio 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi Andrew,

On 12/20/24 12:23 PM, Andrew Cooper wrote:
> On 20/12/2024 5:53 pm, Shawn Anastasio wrote:
>> Xen's memory management APIs map_pages_to_xen, modify_xen_mappings,
>> set_fixmap, ioremap_attr, and __vmap all use an unsigned int to
>> represent architecture-dependent page table entry flags. This assumption
>> does not work on PPC/radix where some flags go past 32-bits, so update
>> these APIs to use unsigned long for flags instead.
>>
>> Signed-off-by: Shawn Anastasio 
> 
> Funnily enough, the same is true on x86 too.  NX and ProtKey bits are
> from bit 63 downwards.
> 
> x86 funnels all PTE flags through {get,put}_pte_flags() which compresses
> a 64bit PTE's flags (top and bottom 12 bits) into a 24 bit number.
> 
> This was allegedly for the benefit of 32bit builds of Xen with PAE
> paging.  I'm not convinced this claim was backed up evidence, even in
> the 32bit days, because the areas of code working on flags separately
> from a 64bit PTE are minimal.
>
> Nevertheless, it's been 11 years since we dropped x86_32, and it's
> definitely tech debt and unnecessary overhead in x86_64.

Interesting -- I wasn't aware that x86 was running into this issue too,
and that approach to solving it definitely seems a bit dubious from an
overhead standpoint.

> I firmly support making this adjustment.  It's been on my todo list for
> years, but never high enough to get started.
> 
> However, instead of just a plain unsigned long, perhaps we should have a
> concrete type, perhaps pte_attr_t ?
> 
> This lets different architectures handle things differently, and also
> lets us make it TYPE_SAFE() like mfn and friends.
>

I fully agree that introducing a TYPE_SAFE per-arch type for this is the
more robust solution. I went with this approach as it requires the least
invasive changes to other architectures, but if there's sufficient
buy-in from everyone then I think that this would be the better route.

One other consideration with that approach would be the ergonomics of
using the TYPE_SAFE macros for these flags which are often OR'd
together.  I know mfn addresses this by offering mfn_{add,max,min,eq}
helper functions, so introducing similar bitwise helpers for the new
pte_attr_t type could work. typesafe.h could even be expanded to include
macros to generate these helper functions for numeric types to reduce
duplication if you think that'd be reasonable.

> Most importantly though, it makes it less likely that we're going to end
> up with paths that accidentally have some long->int truncation.

In this patch some of those paths are explicitly present, for example
in arm's pt.c. The thinking was that these architectures already
obviously have no issue with 32-bit pte flags, so the truncation won't
cause any issues, but I agree it's not ideal. At the very least, it
presents a potential pitfall if architectures like x86 transition to
using the full 64-bit field in the future.



From xen-devel-bounces@lists.xenproject.org Fri Dec 20 19:22:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 19:22:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861966.1273972 (Exim 4.92)
	(envelope-from )
	id 1tOia5-0003xb-5Z; Fri, 20 Dec 2024 19:22:37 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861966.1273972; Fri, 20 Dec 2024 19:22:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOia5-0003xU-2u; Fri, 20 Dec 2024 19:22:37 +0000
Received: by outflank-mailman (input) for mailman id 861966;
 Fri, 20 Dec 2024 19:22: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 1tOia3-0003xO-0N
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 19:22:35 +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 c27c0a71-bf07-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 20:22:32 +0100 (CET)
Received: by mail-wm1-x334.google.com with SMTP id
 5b1f17b1804b1-43622267b2eso22833755e9.0
 for ; Fri, 20 Dec 2024 11:22:32 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4366128a44fsm53090345e9.43.2024.12.20.11.22.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 20 Dec 2024 11:22: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: c27c0a71-bf07-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734722551; x=1735327351; 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=bVjHd0/0ywe10HByXomswP6Y7iAKPeiI1PZPjKZ2HkA=;
        b=XIENb8DFzwjt7VcOkdKd3LlWZdm6CaD+/noLeqsfKNJtTE+lDbB6TqFae7lKx/QZ6r
         /uvdQzi0egXjMBW3ed9uIulhOOQucNNxU09hQP0tY/jWNoGKNqEf4w4gh2JhCe7pb48u
         0UgJqPy5LgcG5/bPpaltet89ua7xUquqhzc+w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734722551; x=1735327351;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=bVjHd0/0ywe10HByXomswP6Y7iAKPeiI1PZPjKZ2HkA=;
        b=qS5UnlwJ6LopAh7WRqOJ6V0IESr0Wvc5wf+PF+KbeYqS1dpRz5dWn0bbnC1ueuXMsb
         8M18rWT21LJBW1YZXo7e3Zko6xY4yP0MgAC2UldeBrDb0997RGgD8J4147suFaXPWzxF
         L2R3OAVAggI3P3fAZAHZ4pBO65UmsFgoPTazD3zMUaWAEV4L2OQ/0fs66608tub+w6qv
         +SJ9K3kg4dKLZUPVfyMWHfgAS3COyfOu+F4IP4FGx3fL2ycxZR1YiMWvHDCzDFTS0YsJ
         QHOKMa9Id1ILu2BEaMyc/FpZYyvdLSL+x9irfQKF9MjvbZEyxnCiwls5BEFtDdmtAjlE
         xucQ==
X-Forwarded-Encrypted: i=1; AJvYcCWZAwZKERP7hT1+vEuyeHH5oOJAnxkNNgU9iTZVLKe2GwNuCcBDtmbdtTVPa9ET/v7Gmjt2231vCcM=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyRKSPvLtg7Jc2LiANwL44oGeLSPrkRfWZMBYWZAtAR/NJGXzZV
	ZuvnjB2xF5uPdsNxu1Bh9WW8OE3Ngtl2KqSvZ1bC/GYrvdUSd4B2lJ/mOFXPIpc=
X-Gm-Gg: ASbGncsbOVhWtuva1zhnAbmfI1DEhMMaTKxunzRVu5PJ1dyFWQ8Ce5pIkl9IZxTpNT+
	mbVaKybWvCIYeH/rH5L4jT0UEMlfx1jqvDjTA5TDImGXJMP1OxIRoBUYkul/bgJ/6BVpm0V6m67
	XJjP3e3bZpw15B1M0P45eh6JBULHt9fqOC63smSz0X8aNLnXcBnwleppkgNeTgve3EUR7dUX3Ni
	VWAWId0vH5TRAqABBGEucTM4srAPu7viQGqGsKbgELa31YBOGYD2U246++e2bUkkOAiNIZEjLcF
	QYEmO/U2SnN4vEK1UOH0
X-Google-Smtp-Source: AGHT+IHmIXR20tZrwwMEz3x4n7QenphXZXgUnosSJCHpvvmHTXLyRlpZq3SlrOh0GLDZ+dD9I7OT6w==
X-Received: by 2002:a05:600c:3c9b:b0:434:ff30:a159 with SMTP id 5b1f17b1804b1-4366790f1a3mr44073225e9.0.1734722551533;
        Fri, 20 Dec 2024 11:22:31 -0800 (PST)
Message-ID: <5d662133-6cdc-427d-bdc9-ba1da5eb83c3@citrix.com>
Date: Fri, 20 Dec 2024 19:22:30 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/mm: Update page APIs to use unsigned long flags
To: Shawn Anastasio ,
 xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Anthony PERARD , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Alistair Francis ,
 Bob Eshleman , Connor Davis
 , Oleksii Kurochko ,
 "Daniel P. Smith" ,
 =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= 
References: <7e3cd1dc48e30f19f2ac97794e21d1b78bc0c082.1734717055.git.sanastasio@raptorengineering.com>
 
 
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20/12/2024 6:51 pm, Shawn Anastasio wrote:
> Hi Andrew,
>
> On 12/20/24 12:23 PM, Andrew Cooper wrote:
>> On 20/12/2024 5:53 pm, Shawn Anastasio wrote:
>>> Xen's memory management APIs map_pages_to_xen, modify_xen_mappings,
>>> set_fixmap, ioremap_attr, and __vmap all use an unsigned int to
>>> represent architecture-dependent page table entry flags. This assumption
>>> does not work on PPC/radix where some flags go past 32-bits, so update
>>> these APIs to use unsigned long for flags instead.
>>>
>>> Signed-off-by: Shawn Anastasio 
>> Funnily enough, the same is true on x86 too.  NX and ProtKey bits are
>> from bit 63 downwards.
>>
>> x86 funnels all PTE flags through {get,put}_pte_flags() which compresses
>> a 64bit PTE's flags (top and bottom 12 bits) into a 24 bit number.
>>
>> This was allegedly for the benefit of 32bit builds of Xen with PAE
>> paging.  I'm not convinced this claim was backed up evidence, even in
>> the 32bit days, because the areas of code working on flags separately
>> from a 64bit PTE are minimal.
>>
>> Nevertheless, it's been 11 years since we dropped x86_32, and it's
>> definitely tech debt and unnecessary overhead in x86_64.
> Interesting -- I wasn't aware that x86 was running into this issue too,
> and that approach to solving it definitely seems a bit dubious from an
> overhead standpoint.

It is history and inertia most likely.

Original paging in x86 had 32bit PTEs with attributes in the low 12 bits
only.

PSE and PSE36 paging were next but not interesting in this context.

PAE paging changed to 64bit PTEs, and the NX bit was added in bit 63. 
This is where the upper 12 bits got introduced.

However, using uint64_t's in 32bit code is somewhat unergonomic and Xen
had a bunch of optimisations to use 32bit frames (== 44 bits addressable
memory).  To this day, we've still got this limitation with a __pdx_t
which dictates the size of the frametable (and CONFIG_BIGMEM to switch
to something larger).

x86_64 has a hard dependency on PAE paging, and added other bits into
the upper 12 range, but at least now a PTE isn't larger than the GPR size.

>> I firmly support making this adjustment.  It's been on my todo list for
>> years, but never high enough to get started.
>>
>> However, instead of just a plain unsigned long, perhaps we should have a
>> concrete type, perhaps pte_attr_t ?
>>
>> This lets different architectures handle things differently, and also
>> lets us make it TYPE_SAFE() like mfn and friends.
>>
> I fully agree that introducing a TYPE_SAFE per-arch type for this is the
> more robust solution. I went with this approach as it requires the least
> invasive changes to other architectures, but if there's sufficient
> buy-in from everyone then I think that this would be the better route.
>
> One other consideration with that approach would be the ergonomics of
> using the TYPE_SAFE macros for these flags which are often OR'd
> together.  I know mfn addresses this by offering mfn_{add,max,min,eq}
> helper functions, so introducing similar bitwise helpers for the new
> pte_attr_t type could work. typesafe.h could even be expanded to include
> macros to generate these helper functions for numeric types to reduce
> duplication if you think that'd be reasonable.

I was thinking of TYPE_SAFE() as a second step.  I'm certainly not
asking you to do make it happen in this patch/series.

But yes, the ergonomics aren't completely great given how many bit
operations we do.


>> Most importantly though, it makes it less likely that we're going to end
>> up with paths that accidentally have some long->int truncation.
> In this patch some of those paths are explicitly present, for example
> in arm's pt.c. The thinking was that these architectures already
> obviously have no issue with 32-bit pte flags, so the truncation won't
> cause any issues, but I agree it's not ideal. At the very least, it
> presents a potential pitfall if architectures like x86 transition to
> using the full 64-bit field in the future.

Ok, in which case you want to start by introducing a per-arch typedef
defaulting to unsigned int.

Then rearrange the code necessary for PPC, and then change PPC to use
unsigned long.

This results no changes to other architectures until they take explicit
action to switch fully over to the new typedef.

~Andrew


From xen-devel-bounces@lists.xenproject.org Fri Dec 20 19:34:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 19:34:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861979.1273983 (Exim 4.92)
	(envelope-from )
	id 1tOila-0005gJ-3j; Fri, 20 Dec 2024 19:34:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861979.1273983; Fri, 20 Dec 2024 19:34:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOila-0005gC-1F; Fri, 20 Dec 2024 19:34:30 +0000
Received: by outflank-mailman (input) for mailman id 861979;
 Fri, 20 Dec 2024 19:34: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 1tOilZ-0005fx-14
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 19:34:29 +0000
Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com
 [2a00:1450:4864:20::341])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 6d4507cf-bf09-11ef-a0d9-8be0dac302b0;
 Fri, 20 Dec 2024 20:34:28 +0100 (CET)
Received: by mail-wm1-x341.google.com with SMTP id
 5b1f17b1804b1-4367239aa86so1165105e9.3
 for ; Fri, 20 Dec 2024 11:34:28 -0800 (PST)
Received: from andrewcoop.eng.citrite.net (host-92-26-98-202.as13285.net.
 [92.26.98.202]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c847714sm4781098f8f.54.2024.12.20.11.34.26
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 20 Dec 2024 11:34: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: 6d4507cf-bf09-11ef-a0d9-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734723267; x=1735328067; 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=Mky7eLb3n5mZ2068+P/iwev5K4JT9Bq7pfyqahXFqws=;
        b=KUv60qPea2g/ZajgkDr8ibLWxSB7uRB4iw7qoS5WaBwcs+wLJ+5/2tycSuVEQxCU9P
         L7ZfOns43bqkcp8APRcNXB1b2n6dsHU9oolflsxMOnNSNOo9XmtnFlaHrBufXhJsoHyJ
         LyfDgjoW4F3vmQ75zGdYtzf7HHJnFPNz2+/wE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734723267; x=1735328067;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Mky7eLb3n5mZ2068+P/iwev5K4JT9Bq7pfyqahXFqws=;
        b=XyAIfxcavUmVWzWzQp+GRR/EHYMc1b/6d7lg7u+xXgbQJKVLSs2R7F9+PFI8JGLNiu
         rVFavlSFnfT5VHDkcMv+DczoRMCOESL4LKQ5pFNINkan8DGpn7IsGttEgdPshrfFFaJx
         k64eHXpAGn4UrDWhfsSlaQC/C0enIfBYs8SkxK4DHuu0sqScGX1XIEQZMHdQv4K8cPCO
         6RgLvIkI6/jubuyIm1Of+NQJHbyF06PBp4g5Bh++MdA8ES1D5s4vkanAT/7UiEkoA2Vc
         qYir5cUeyEotJ+qapqV2xxdoLi9LfnHXwYhuU5i7PvOmwu1x2+uVxknTFaN5n1lCdYf7
         /oDw==
X-Gm-Message-State: AOJu0Yw1tfiChsREOLPDFgl1IVofU55/Tts7XmksSBxnGopX89GGwaL0
	rTQZcVe1qwRXOvzue5T4oHws6DQJY9RVqKOr6/MBl9PFexTmJjjhNmskCHCbHkHk2JA4RnS+fb3
	48dp4aA==
X-Gm-Gg: ASbGnctc7n+55Pk0drPvw9jKTcwH2VROoGEFgIYElZv88zRuc7KhCaOPdtGyBnhzSgW
	E4xZJTdUNfYAWrfANLJkdFU9kwGto6cOb1814cYZlB7/EpRVZmELg8M0RYmB9JHC3UDj4rZaGlC
	Hk2HkGUBVt7znwdP9F4P/cOntqFXMWByweubRq7mXZSfPGOJs7CigAbOg5qCrW7szfqT/0Z64/0
	7UVjzei7Zz7Q3Y04Pgkanb6JDuScTt+3Mz2K//87AwKk1ernWxveE447DfIWFOAF+/2hdoiaUJF
	3wIIlqL/5DiOcgBtns4fKD3EoC7AuqKqCG4E
X-Google-Smtp-Source: AGHT+IGB9M9mglklY9PuZn5OXTekzNIUwwTZ41byV4I7Qdfq/Jx4fWH+yX9uO2RDhBNixj9alu5DPQ==
X-Received: by 2002:a5d:584d:0:b0:386:3918:16cd with SMTP id ffacd0b85a97d-38a224034d2mr3994827f8f.59.1734723267011;
        Fri, 20 Dec 2024 11:34:27 -0800 (PST)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Jan Beulich ,
	Oleksii Kurochko 
Subject: [PATCH v3] x86/spec-ctrl: Support for SRSO_U/S_NO and SRSO_MSR_FIX
Date: Fri, 20 Dec 2024 19:34:24 +0000
Message-Id: <20241220193424.470994-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

AMD have updated the SRSO whitepaper[1] with further information.  These
features exist on AMD Zen5 CPUs and are necessary for Xen to use.

The two features are in principle unrelated:

 * SRSO_U/S_NO is an enumeration saying that SRSO attacks can't cross the
   User(CPL3) / Supervisor(CPL<3) boundary.  i.e. Xen don't need to use
   IBPB-on-entry for PV64.  PV32 guests are explicitly unsupported for
   speculative issues, and excluded from consideration for simplicity.

 * SRSO_MSR_FIX is an enumeration identifying that the BP_SPEC_REDUCE bit is
   available in MSR_BP_CFG.  When set, SRSO attacks can't cross the host/guest
   boundary.  i.e. Xen don't need to use IBPB-on-entry for HVM.

Extend ibpb_calculations() to account for these when calculating
opt_ibpb_entry_{pv,hvm} defaults.  Add a `bp-spec-reduce=` option to
control the use of BP_SPEC_REDUCE, with it active by default.

Because MSR_BP_CFG is core-scoped with a race condition updating it, repurpose
amd_check_erratum_1485() into amd_check_bp_cfg() and calculate all updates at
once.

Xen also needs to to advertise SRSO_U/S_NO to guests to allow the guest kernel
to skip SRSO mitigations too:

 * This is trivial for HVM guests.  It is also is accurate for PV32 guests
   too, but we have already excluded them from consideration, and do so again
   here to simplify the policy logic.

 * As written, SRSO_U/S_NO does not help for the PV64 user->kernel boundary.
   However, after discussing with AMD, an implementation detail of having
   BP_SPEC_REDUCE active causes the PV64 user->kernel boundary to have the
   property described by SRSO_U/S_NO, so we can advertise SRSO_U/S_NO to
   guests when the BP_SPEC_REDUCE precondition is met.

Finally, fix a typo in the SRSO_NO's comment.

[1] https://www.amd.com/content/dam/amd/en/documents/corporate/cr/speculative-return-stack-overflow-whitepaper.pdf
Signed-off-by: Andrew Cooper 
Reviewed-by: Roger Pau Monné 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Oleksii Kurochko 

I cannot say anything more about the SRSO_U/S_NO vs SRSO_MSR_FIX interactions
in public.  The safety for PV guests depends on details not covered in the
whitepaper.

v3:
 * Rewrite commit message and comments quite a lot.

This patch was originally for-4.19.  Zen5 CPUs are now in the world and Xen is
unsafe on them without this patch.

I technically have enough tags to commit it, and it's long overdue, but I
think it would be wise to see if the new wording is clearer to others.
---
 docs/misc/xen-command-line.pandoc           |  9 +++-
 xen/arch/x86/cpu-policy.c                   | 21 +++++++++
 xen/arch/x86/cpu/amd.c                      | 29 +++++++++---
 xen/arch/x86/include/asm/msr-index.h        |  1 +
 xen/arch/x86/include/asm/spec_ctrl.h        |  1 +
 xen/arch/x86/spec_ctrl.c                    | 51 ++++++++++++++++-----
 xen/include/public/arch-x86/cpufeatureset.h |  4 +-
 7 files changed, 96 insertions(+), 20 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 1dd8f714d3a2..08b0053f9ced 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2456,7 +2456,7 @@ By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
 >              {ibrs,ibpb,ssbd,psfd,
 >              eager-fpu,l1d-flush,branch-harden,srb-lock,
 >              unpriv-mmio,gds-mit,div-scrub,lock-harden,
->              bhi-dis-s}= ]`
+>              bhi-dis-s,bp-spec-reduce}= ]`
 
 Controls for speculative execution sidechannel mitigations.  By default, Xen
 will pick the most appropriate mitigations based on compiled in support,
@@ -2605,6 +2605,13 @@ boolean can be used to force or prevent Xen from using speculation barriers to
 protect lock critical regions.  This mitigation won't be engaged by default,
 and needs to be explicitly enabled on the command line.
 
+On hardware supporting SRSO_MSR_FIX, the `bp-spec-reduce=` option can be used
+to force or prevent Xen from using MSR_BP_CFG.BP_SPEC_REDUCE to mitigate the
+SRSO (Speculative Return Stack Overflow) vulnerability.  Xen will use
+bp-spec-reduce when available, as it is preferable to using `ibpb-entry=hvm`
+to mitigate SRSO for HVM guests, and because it is a prerequisite to advertise
+SRSO_U/S_NO to PV guests.
+
 ### sync_console
 > `= `
 
diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c
index 78bc9872b09a..2e8a5ecb5e7b 100644
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct cpu_policy __read_mostly       raw_cpu_policy;
@@ -625,6 +626,26 @@ static void __init calculate_pv_max_policy(void)
         __clear_bit(X86_FEATURE_IBRS, fs);
     }
 
+    /*
+     * SRSO_U/S_NO means that the CPU is not vulnerable to SRSO attacks across
+     * the User (CPL3)/Supervisor (CPL<3) boundary.
+     *
+     * PV32 guests are unsupported for speculative issues, and excluded from
+     * consideration for simplicity.
+     *
+     * The PV64 user/kernel boundary is CPL3 on both sides, so SRSO_U/S_NO
+     * won't convey the meaning that a PV kernel expects.
+     *
+     * After discussions with AMD, an implementation detail of having
+     * BP_SPEC_REDUCE active causes the PV64 user/kernel boundary to have a
+     * property compatible with the meaning of SRSO_U/S_NO.
+     *
+     * If BP_SPEC_REDUCE isn't active, remove SRSO_U/S_NO from the PV max
+     * policy, which will cause it to filter out of PV default too.
+     */
+    if ( !boot_cpu_has(X86_FEATURE_SRSO_MSR_FIX) || !opt_bp_spec_reduce )
+        __clear_bit(X86_FEATURE_SRSO_US_NO, fs);
+
     guest_common_max_feature_adjustments(fs);
     guest_common_feature_adjustments(fs);
 
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 7da04230393a..597b0f073d55 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -1009,16 +1009,33 @@ static void cf_check fam17_disable_c6(void *arg)
 	wrmsrl(MSR_AMD_CSTATE_CFG, val & mask);
 }
 
-static void amd_check_erratum_1485(void)
+static void amd_check_bp_cfg(void)
 {
-	uint64_t val, chickenbit = (1 << 5);
+	uint64_t val, new = 0;
 
-	if (cpu_has_hypervisor || boot_cpu_data.x86 != 0x19 || !is_zen4_uarch())
+	/*
+	 * AMD Erratum #1485.  Set bit 5, as instructed.
+	 */
+	if (!cpu_has_hypervisor && boot_cpu_data.x86 == 0x19 && is_zen4_uarch())
+		new |= (1 << 5);
+
+	/*
+	 * On hardware supporting SRSO_MSR_FIX, activate BP_SPEC_REDUCE by
+	 * default.  This lets us do two things:
+	 *
+	 * 1) Avoid IBPB-on-entry to mitigate SRSO attacks from HVM guests.
+	 * 2) Advertise SRSO_US_NO to PV guests.
+	 */
+	if (boot_cpu_has(X86_FEATURE_SRSO_MSR_FIX) && opt_bp_spec_reduce)
+		new |= BP_CFG_SPEC_REDUCE;
+
+	/* Avoid reading BP_CFG if we don't intend to change anything. */
+	if (!new)
 		return;
 
 	rdmsrl(MSR_AMD64_BP_CFG, val);
 
-	if (val & chickenbit)
+	if ((val & new) == new)
 		return;
 
 	/*
@@ -1027,7 +1044,7 @@ static void amd_check_erratum_1485(void)
 	 * same time before the chickenbit is set. It's benign because the
 	 * value being written is the same on both.
 	 */
-	wrmsrl(MSR_AMD64_BP_CFG, val | chickenbit);
+	wrmsrl(MSR_AMD64_BP_CFG, val | new);
 }
 
 static void cf_check init_amd(struct cpuinfo_x86 *c)
@@ -1297,7 +1314,7 @@ static void cf_check init_amd(struct cpuinfo_x86 *c)
 		disable_c1_ramping();
 
 	amd_check_zenbleed();
-	amd_check_erratum_1485();
+	amd_check_bp_cfg();
 
 	if (fam17_c6_disabled)
 		fam17_disable_c6(NULL);
diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
index 9cdb5b262566..22d9e76e5521 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -412,6 +412,7 @@
 #define AMD64_DE_CFG_LFENCE_SERIALISE	(_AC(1, ULL) << 1)
 #define MSR_AMD64_EX_CFG		0xc001102cU
 #define MSR_AMD64_BP_CFG		0xc001102eU
+#define  BP_CFG_SPEC_REDUCE		(_AC(1, ULL) <<  4)
 #define MSR_AMD64_DE_CFG2		0xc00110e3U
 
 #define MSR_AMD64_DR0_ADDRESS_MASK	0xc0011027U
diff --git a/xen/arch/x86/include/asm/spec_ctrl.h b/xen/arch/x86/include/asm/spec_ctrl.h
index 72347ef2b959..077225418956 100644
--- a/xen/arch/x86/include/asm/spec_ctrl.h
+++ b/xen/arch/x86/include/asm/spec_ctrl.h
@@ -90,6 +90,7 @@ extern int8_t opt_xpti_hwdom, opt_xpti_domu;
 
 extern bool cpu_has_bug_l1tf;
 extern int8_t opt_pv_l1tf_hwdom, opt_pv_l1tf_domu;
+extern bool opt_bp_spec_reduce;
 
 /*
  * The L1D address mask, which might be wider than reported in CPUID, and the
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 75a4177a75d2..ced84750015c 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -83,6 +83,7 @@ static bool __initdata opt_unpriv_mmio;
 static bool __ro_after_init opt_verw_mmio;
 static int8_t __initdata opt_gds_mit = -1;
 static int8_t __initdata opt_div_scrub = -1;
+bool __ro_after_init opt_bp_spec_reduce = true;
 
 static int __init cf_check parse_spec_ctrl(const char *s)
 {
@@ -145,6 +146,7 @@ static int __init cf_check parse_spec_ctrl(const char *s)
             opt_unpriv_mmio = false;
             opt_gds_mit = 0;
             opt_div_scrub = 0;
+            opt_bp_spec_reduce = false;
         }
         else if ( val > 0 )
             rc = -EINVAL;
@@ -365,6 +367,8 @@ static int __init cf_check parse_spec_ctrl(const char *s)
             opt_gds_mit = val;
         else if ( (val = parse_boolean("div-scrub", s, ss)) >= 0 )
             opt_div_scrub = val;
+        else if ( (val = parse_boolean("bp-spec-reduce", s, ss)) >= 0 )
+            opt_bp_spec_reduce = val;
         else
             rc = -EINVAL;
 
@@ -507,7 +511,7 @@ static void __init print_details(enum ind_thunk thunk)
      * Hardware read-only information, stating immunity to certain issues, or
      * suggestions of which mitigation to use.
      */
-    printk("  Hardware hints:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
+    printk("  Hardware hints:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
            (caps & ARCH_CAPS_RDCL_NO)                        ? " RDCL_NO"        : "",
            (caps & ARCH_CAPS_EIBRS)                          ? " EIBRS"          : "",
            (caps & ARCH_CAPS_RSBA)                           ? " RSBA"           : "",
@@ -531,10 +535,11 @@ static void __init print_details(enum ind_thunk thunk)
            (e8b  & cpufeat_mask(X86_FEATURE_BTC_NO))         ? " BTC_NO"         : "",
            (e8b  & cpufeat_mask(X86_FEATURE_IBPB_RET))       ? " IBPB_RET"       : "",
            (e21a & cpufeat_mask(X86_FEATURE_IBPB_BRTYPE))    ? " IBPB_BRTYPE"    : "",
-           (e21a & cpufeat_mask(X86_FEATURE_SRSO_NO))        ? " SRSO_NO"        : "");
+           (e21a & cpufeat_mask(X86_FEATURE_SRSO_NO))        ? " SRSO_NO"        : "",
+           (e21a & cpufeat_mask(X86_FEATURE_SRSO_US_NO))     ? " SRSO_US_NO"     : "");
 
     /* Hardware features which need driving to mitigate issues. */
-    printk("  Hardware features:%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
+    printk("  Hardware features:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
            (e8b  & cpufeat_mask(X86_FEATURE_IBPB)) ||
            (_7d0 & cpufeat_mask(X86_FEATURE_IBRSB))          ? " IBPB"           : "",
            (e8b  & cpufeat_mask(X86_FEATURE_IBRS)) ||
@@ -553,7 +558,8 @@ static void __init print_details(enum ind_thunk thunk)
            (caps & ARCH_CAPS_FB_CLEAR_CTRL)                  ? " FB_CLEAR_CTRL"  : "",
            (caps & ARCH_CAPS_GDS_CTRL)                       ? " GDS_CTRL"       : "",
            (caps & ARCH_CAPS_RFDS_CLEAR)                     ? " RFDS_CLEAR"     : "",
-           (e21a & cpufeat_mask(X86_FEATURE_SBPB))           ? " SBPB"           : "");
+           (e21a & cpufeat_mask(X86_FEATURE_SBPB))           ? " SBPB"           : "",
+           (e21a & cpufeat_mask(X86_FEATURE_SRSO_MSR_FIX))   ? " SRSO_MSR_FIX"   : "");
 
     /* Compiled-in support which pertains to mitigations. */
     if ( IS_ENABLED(CONFIG_INDIRECT_THUNK) || IS_ENABLED(CONFIG_SHADOW_PAGING) ||
@@ -1113,7 +1119,7 @@ static void __init div_calculations(bool hw_smt_enabled)
 
 static void __init ibpb_calculations(void)
 {
-    bool def_ibpb_entry = false;
+    bool def_ibpb_entry_pv = false, def_ibpb_entry_hvm = false;
 
     /* Check we have hardware IBPB support before using it... */
     if ( !boot_cpu_has(X86_FEATURE_IBRSB) && !boot_cpu_has(X86_FEATURE_IBPB) )
@@ -1138,22 +1144,43 @@ static void __init ibpb_calculations(void)
          * Confusion.  Mitigate with IBPB-on-entry.
          */
         if ( !boot_cpu_has(X86_FEATURE_BTC_NO) )
-            def_ibpb_entry = true;
+            def_ibpb_entry_pv = def_ibpb_entry_hvm = true;
 
         /*
-         * Further to BTC, Zen3/4 CPUs suffer from Speculative Return Stack
-         * Overflow in most configurations.  Mitigate with IBPB-on-entry if we
-         * have the microcode that makes this an effective option.
+         * In addition to BTC, Zen3 and later CPUs suffer from Speculative
+         * Return Stack Overflow in most configurations.  If we have microcode
+         * that makes IBPB-on-entry an effective mitigation, see about using
+         * it.
          */
         if ( !boot_cpu_has(X86_FEATURE_SRSO_NO) &&
              boot_cpu_has(X86_FEATURE_IBPB_BRTYPE) )
-            def_ibpb_entry = true;
+        {
+            /*
+             * SRSO_U/S_NO is a subset of SRSO_NO, identifying that SRSO isn't
+             * possible across the User (CPL3) / Supervisor (CPL<3) boundary.
+             *
+             * Ignoring PV32 (not security supported for speculative issues),
+             * this means we only need to use IBPB-on-entry for PV guests on
+             * hardware which doesn't enumerate SRSO_US_NO.
+             */
+            if ( !boot_cpu_has(X86_FEATURE_SRSO_US_NO) )
+                def_ibpb_entry_pv = true;
+
+            /*
+             * SRSO_MSR_FIX enumerates that we can use MSR_BP_CFG.SPEC_REDUCE
+             * to mitigate SRSO across the host/guest boundary.  We only need
+             * to use IBPB-on-entry for HVM guests if we haven't enabled this
+             * control.
+             */
+            if ( !boot_cpu_has(X86_FEATURE_SRSO_MSR_FIX) || !opt_bp_spec_reduce )
+                def_ibpb_entry_hvm = true;
+        }
     }
 
     if ( opt_ibpb_entry_pv == -1 )
-        opt_ibpb_entry_pv = IS_ENABLED(CONFIG_PV) && def_ibpb_entry;
+        opt_ibpb_entry_pv = IS_ENABLED(CONFIG_PV) && def_ibpb_entry_pv;
     if ( opt_ibpb_entry_hvm == -1 )
-        opt_ibpb_entry_hvm = IS_ENABLED(CONFIG_HVM) && def_ibpb_entry;
+        opt_ibpb_entry_hvm = IS_ENABLED(CONFIG_HVM) && def_ibpb_entry_hvm;
 
     if ( opt_ibpb_entry_pv )
     {
diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h
index 8fa3fb711a8d..16207e3817bb 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -325,7 +325,9 @@ XEN_CPUFEATURE(FSRSC,              11*32+19) /*A  Fast Short REP SCASB */
 XEN_CPUFEATURE(AMD_PREFETCHI,      11*32+20) /*A  PREFETCHIT{0,1} Instructions */
 XEN_CPUFEATURE(SBPB,               11*32+27) /*A  Selective Branch Predictor Barrier */
 XEN_CPUFEATURE(IBPB_BRTYPE,        11*32+28) /*A  IBPB flushes Branch Type predictions too */
-XEN_CPUFEATURE(SRSO_NO,            11*32+29) /*A  Hardware not vulenrable to Speculative Return Stack Overflow */
+XEN_CPUFEATURE(SRSO_NO,            11*32+29) /*A  Hardware not vulnerable to Speculative Return Stack Overflow */
+XEN_CPUFEATURE(SRSO_US_NO,         11*32+30) /*A! Hardware not vulnerable to SRSO across the User/Supervisor boundary */
+XEN_CPUFEATURE(SRSO_MSR_FIX,       11*32+31) /*   MSR_BP_CFG.BP_SPEC_REDUCE available */
 
 /* Intel-defined CPU features, CPUID level 0x00000007:1.ebx, word 12 */
 XEN_CPUFEATURE(INTEL_PPIN,         12*32+ 0) /*   Protected Processor Inventory Number */
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Fri Dec 20 23:06:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Dec 2024 23:06:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862073.1273994 (Exim 4.92)
	(envelope-from )
	id 1tOm4l-0004Cj-Lo; Fri, 20 Dec 2024 23:06:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862073.1273994; Fri, 20 Dec 2024 23:06:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOm4l-0004Cc-H9; Fri, 20 Dec 2024 23:06:31 +0000
Received: by outflank-mailman (input) for mailman id 862073;
 Fri, 20 Dec 2024 23:06: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 1tOm4k-0004C9-J2
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 23:06:30 +0000
Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 0aef41b6-bf27-11ef-99a3-01e77a169b0f;
 Sat, 21 Dec 2024 00:06:28 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by nyc.source.kernel.org (Postfix) with ESMTP id 0B8B0A4281D;
 Fri, 20 Dec 2024 23:04:37 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 51D4DC4CECD;
 Fri, 20 Dec 2024 23:06: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: 0aef41b6-bf27-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org;
	s=korg; t=1734735987;
	bh=rDnT4CiiEQHDei+WTY8t89wAldSK7/wzy9hzuNQ2FY0=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=ko0NoC85TGcP1IppTBQ7r5GFZyBBTG2SpQ0tFrc/AJkG+/T9Itx2K+hPhmLUjOFT3
	 W/JopMsDfKdWQ+Sgte/CaZu5u4oCC9X7AhqHTGt1/QNG5SKrdk/OmLPnondMcorXOq
	 YK2sRjfqtNIqcRTWYGNAXSYWTaR7HQTBx80wOGXo=
Date: Fri, 20 Dec 2024 15:06:23 -0800
From: Andrew Morton 
To: Guo Weikang 
Cc: Mike Rapoport , Dennis Zhou , Tejun
 Heo , Christoph Lameter , Thomas Bogendoerfer
 , Sam Creasey , Geert
 Uytterhoeven , Huacai Chen ,
 Will Deacon , Catalin Marinas ,
 Oreoluwa Babatunde , rafael.j.wysocki@intel.com,
 Palmer Dabbelt , Hanjun Guo ,
 Easwar Hariharan , Johannes Berg
 , Ingo Molnar , Dave Hansen
 , Christian Brauner , KP Singh
 , Richard Henderson ,
 Matt Turner , Russell King ,
 WANG Xuerui , Michael Ellerman ,
 Jonas Bonn , Stefan Kristiansson
 , Stafford Horne ,
 Helge Deller , Nicholas Piggin ,
 Christophe Leroy , Naveen N Rao
 , Madhavan Srinivasan , Geoff
 Levand , Paul Walmsley ,
 Palmer Dabbelt , Albert Ou ,
 Andrey Ryabinin , Alexander Potapenko
 , Andrey Konovalov , Dmitry Vyukov
 , Vincenzo Frascino , Heiko
 Carstens , Vasily Gorbik , Alexander
 Gordeev , Christian Borntraeger
 , Sven Schnelle , Yoshinori
 Sato , Rich Felker , John Paul
 Adrian Glaubitz , Andreas Larsson
 , Richard Weinberger , Anton Ivanov
 , Johannes Berg
 , Thomas Gleixner , Ingo
 Molnar , Borislav Petkov , Dave Hansen
 , x86@kernel.org, Len Brown ,
 Juergen Gross , Boris Ostrovsky
 , Chris Zankel , Max Filippov
 , Tero Kristo , Michael Turquette
 , Stephen Boyd , Rob Herring
 , Saravana Kannan , Pavel Machek
 , Yury Norov , Rasmus Villemoes
 , Marco Elver , Al Viro
 , Arnd Bergmann ,
 linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
 linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
 linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
 linux-openrisc@vger.kernel.org, linux-parisc@vger.kernel.org,
 linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
 kasan-dev@googlegroups.com, linux-s390@vger.kernel.org,
 linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
 linux-um@lists.infradead.org, linux-acpi@vger.kernel.org,
 xen-devel@lists.xenproject.org, linux-omap@vger.kernel.org,
 linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-mm@kvack.org,
 linux-pm@vger.kernel.org
Subject: Re: [PATCH] mm/memblock: Add memblock_alloc_or_panic interface
Message-Id: <20241220150623.278e8fa9f073b66dc81edfe6@linux-foundation.org>
In-Reply-To: <20241220092638.2611414-1-guoweikang.kernel@gmail.com>
References: <20241220092638.2611414-1-guoweikang.kernel@gmail.com>
X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri, 20 Dec 2024 17:26:38 +0800 Guo Weikang  wrote:

> Before SLUB initialization, various subsystems used memblock_alloc to
> allocate memory. In most cases, when memory allocation fails, an immediate
> panic is required. To simplify this behavior and reduce repetitive checks,
> introduce `memblock_alloc_or_panic`. This function ensures that memory
> allocation failures result in a panic automatically, improving code
> readability and consistency across subsystems that require this behavior.
> 

Seems nice.

> ...
>
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -417,6 +417,19 @@ static __always_inline void *memblock_alloc(phys_addr_t size, phys_addr_t align)
>  				      MEMBLOCK_ALLOC_ACCESSIBLE, NUMA_NO_NODE);
>  }
>  
> +static __always_inline void *memblock_alloc_or_panic(phys_addr_t size, phys_addr_t align)

We lost the printing of the function name, but it's easy to retain with
something like

#define memblock_alloc_or_panic(size, align)	\
		__memblock_alloc_or_panic(size, align, __func__)

> +{
> +	void *addr = memblock_alloc(size, align);
> +
> +	if (unlikely(!addr))
> +#ifdef CONFIG_PHYS_ADDR_T_64BIT
> +		panic("%s: Failed to allocate %llu bytes\n", __func__, size);

Won't this always print "memblock_alloc_or_panic: Failed ..."?  Not
very useful.

> +#else
> +		panic("%s: Failed to allocate %u bytes\n", __func__, size);
> +#endif

We can avoid the ifdef with printk's "%pap"?

> +	return addr;
> +}



From xen-devel-bounces@lists.xenproject.org Sat Dec 21 10:45:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Dec 2024 10:45:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862330.1274087 (Exim 4.92)
	(envelope-from )
	id 1tOwzD-0007hr-4E; Sat, 21 Dec 2024 10:45:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862330.1274087; Sat, 21 Dec 2024 10: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 1tOwzC-0007hB-VY; Sat, 21 Dec 2024 10:45:30 +0000
Received: by outflank-mailman (input) for mailman id 862330;
 Sat, 21 Dec 2024 09:59: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 1tOwH7-0002K8-1e
 for xen-devel@lists.xenproject.org; Sat, 21 Dec 2024 09:59:57 +0000
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com
 [2607:f8b0:4864:20::b2c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 53dc8297-bf82-11ef-99a3-01e77a169b0f;
 Sat, 21 Dec 2024 10:59:55 +0100 (CET)
Received: by mail-yb1-xb2c.google.com with SMTP id
 3f1490d57ef6-e3983426f80so2194042276.1
 for ; Sat, 21 Dec 2024 01:59: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: 53dc8297-bf82-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734775194; x=1735379994; 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=egHprya5wIN6bGofZtv4dfpbBXKQe0iUzhyvNvr/kt4=;
        b=fm9GSEqxDaRkxv/jpFp3CwPuhBUW9yE0neW4OCm4kQMVA8qkxLqqdmnLnI59LBnouL
         MhSefT23twmYIihd0I1ENiTnpqznJcFs7RLuyagE1MVDtiW7xbJ52wLWg3X//p80V5o7
         tsfeH0dC07a4M3ujeSaHiv13AevRKF67k8iv7dzzs/KguGCrPg6xoqImGiTBSRrn6cHY
         vKmmct1UINXKAzYv1Ee3NU+sEbCVmhHHYrOuBdecCN31wS/z1Rtobsmzd6Io4lnTRQER
         zVfczuTmml3EFmU3yF7QRd8Oeq8vDkpf4pnj52XpNvrHiCX41jvyUZhpVGBQJt3Dhw9d
         gYaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734775194; x=1735379994;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=egHprya5wIN6bGofZtv4dfpbBXKQe0iUzhyvNvr/kt4=;
        b=na8iB697bJnRJB1yfrWddyJsRd4LsUS8mQQN6siO96rCeeWsgRXgs5LZI85yfpKArk
         XqZpmnMxTj7Vw1uIY6cVHhZRyRTRDehOXV+6YQOd/bb/DurehumQUl5F8ckc6klyQz4z
         fZ3aPM11oFu6zcMasUihewhEZt4zyg0kFxXH26qp/xXHHn+09VgzUPZFjCr5PsiufvGE
         OAP0nPCoHGLoc5j+vXMYRla3Nj1CZpVLXn7tjnbGlr0XBGPglDL9LbEV39hTgi4Dz4UZ
         hy9W/BbEYkI3GoUVBs0U05VXCmAJTd1JO1CeQZKQJ0wel0gdgQHZf/OODyUduZhznHvX
         rSIQ==
X-Forwarded-Encrypted: i=1; AJvYcCVoW9gujuz2tKV1o0318w7562PoHg5cJxRmW6i3PFRhr2gnvmUP99joBmEmtDy4kkbo9Wt/tHGMkjw=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwHTLyFF7sO24qKro/IctPhMhvKGBjlPvbvNgJTzu8Ogb+9YTex
	yE3rivAooJf9D/6aHOZ7fxg7siBZN8kOti+G5h0EIIBmhoflypjIASVCCZIgwhOsUsYQbwry/AL
	QL9FOq+xo92kH41bDpwgAW1i2Hmk=
X-Gm-Gg: ASbGnct77yC4Iu0jeRob9d79VHTBoM/K2l4lMqAmL6E87W90RyY+Mgzrfn8cy1lrZXQ
	4QntiTVz0uZlMhFOD8/LhaR9GTRtwRP18k2LpplA=
X-Google-Smtp-Source: AGHT+IG9hgHXPNsbBNiOuY+6OAJ+D2q82bPj4v1OfjOz7h337kMTVjsW2qLUpiuBZXc33tZc49lNKi5hOGaIXzFbkh0=
X-Received: by 2002:a05:690c:4b13:b0:6ef:7036:3b25 with SMTP id
 00721157ae682-6f3f8216b3cmr49229327b3.31.1734775193934; Sat, 21 Dec 2024
 01:59:53 -0800 (PST)
MIME-Version: 1.0
References: <20241220092638.2611414-1-guoweikang.kernel@gmail.com> <20241220150623.278e8fa9f073b66dc81edfe6@linux-foundation.org>
In-Reply-To: <20241220150623.278e8fa9f073b66dc81edfe6@linux-foundation.org>
From: Weikang Guo 
Date: Sat, 21 Dec 2024 17:59:43 +0800
Message-ID: 
Subject: Re: [PATCH] mm/memblock: Add memblock_alloc_or_panic interface
To: Andrew Morton 
Cc: Mike Rapoport , Dennis Zhou , Tejun Heo , 
	Christoph Lameter , Thomas Bogendoerfer , Sam Creasey , 
	Geert Uytterhoeven , Huacai Chen , 
	Will Deacon , Catalin Marinas , 
	Oreoluwa Babatunde , rafael.j.wysocki@intel.com, 
	Palmer Dabbelt , Hanjun Guo , 
	Easwar Hariharan , Johannes Berg , 
	Ingo Molnar , Dave Hansen , 
	Christian Brauner , KP Singh , 
	Richard Henderson , Matt Turner , 
	Russell King , WANG Xuerui , 
	Michael Ellerman , Jonas Bonn , 
	Stefan Kristiansson , Stafford Horne , 
	Helge Deller , Nicholas Piggin , 
	Christophe Leroy , Naveen N Rao , 
	Madhavan Srinivasan , Geoff Levand , 
	Paul Walmsley , Palmer Dabbelt , 
	Albert Ou , Andrey Ryabinin , 
	Alexander Potapenko , Andrey Konovalov , 
	Dmitry Vyukov , Vincenzo Frascino , 
	Heiko Carstens , Vasily Gorbik , 
	Alexander Gordeev , Christian Borntraeger , 
	Sven Schnelle , Yoshinori Sato , 
	Rich Felker , John Paul Adrian Glaubitz , 
	Andreas Larsson , Richard Weinberger , 
	Anton Ivanov , Johannes Berg , 
	Thomas Gleixner , Ingo Molnar , Borislav Petkov , 
	Dave Hansen , x86@kernel.org, Len Brown , 
	Juergen Gross , Boris Ostrovsky , 
	Chris Zankel , Max Filippov , Tero Kristo , 
	Michael Turquette , Stephen Boyd , 
	Rob Herring , Saravana Kannan , Pavel Machek , 
	Yury Norov , Rasmus Villemoes , 
	Marco Elver , Al Viro , 
	Arnd Bergmann , linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, 
	linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, 
	linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, 
	linux-openrisc@vger.kernel.org, linux-parisc@vger.kernel.org, 
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, 
	kasan-dev@googlegroups.com, linux-s390@vger.kernel.org, 
	linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, 
	linux-um@lists.infradead.org, linux-acpi@vger.kernel.org, 
	xen-devel@lists.xenproject.org, linux-omap@vger.kernel.org, 
	linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-mm@kvack.org, 
	linux-pm@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Andrew Morton  wrote on Saturday, 21
December 2024 07:06:
>
> On Fri, 20 Dec 2024 17:26:38 +0800 Guo Weikang  wrote:
>
> > Before SLUB initialization, various subsystems used memblock_alloc to
> > allocate memory. In most cases, when memory allocation fails, an immedi=
ate
> > panic is required. To simplify this behavior and reduce repetitive chec=
ks,
> > introduce `memblock_alloc_or_panic`. This function ensures that memory
> > allocation failures result in a panic automatically, improving code
> > readability and consistency across subsystems that require this behavio=
r.
> >
>
> Seems nice.
>
> > ...
> >
> > --- a/include/linux/memblock.h
> > +++ b/include/linux/memblock.h
> > @@ -417,6 +417,19 @@ static __always_inline void *memblock_alloc(phys_a=
ddr_t size, phys_addr_t align)
> >                                     MEMBLOCK_ALLOC_ACCESSIBLE, NUMA_NO_=
NODE);
> >  }
> >
> > +static __always_inline void *memblock_alloc_or_panic(phys_addr_t size,=
 phys_addr_t align)
>
> We lost the printing of the function name, but it's easy to retain with
> something like
>
> #define memblock_alloc_or_panic(size, align)    \
>                 __memblock_alloc_or_panic(size, align, __func__)
>
You're absolutely right, this was an oversight on my part. I=E2=80=99ll mak=
e
sure to update it with the correct function name.
> > +{
> > +     void *addr =3D memblock_alloc(size, align);
> > +
> > +     if (unlikely(!addr))
> > +#ifdef CONFIG_PHYS_ADDR_T_64BIT
> > +             panic("%s: Failed to allocate %llu bytes\n", __func__, si=
ze);
>
> Won't this always print "memblock_alloc_or_panic: Failed ..."?  Not
> very useful.
>
As mentioned above.
> > +#else
> > +             panic("%s: Failed to allocate %u bytes\n", __func__, size=
);
> > +#endif
>
> We can avoid the ifdef with printk's "%pap"?
>
I appreciate you pointing this out. I wasn=E2=80=99t aware of this approach=
,
but it=E2=80=99s a great idea. It definitely simplifies things, and I=E2=80=
=99ve
learned something new in the process. I'll incorporate this into the
code.
> > +     return addr;
> > +}
>


From xen-devel-bounces@lists.xenproject.org Sat Dec 21 10:45:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Dec 2024 10:45:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862347.1274093 (Exim 4.92)
	(envelope-from )
	id 1tOwzD-0007oC-Cd; Sat, 21 Dec 2024 10:45:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862347.1274093; Sat, 21 Dec 2024 10: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 1tOwzD-0007lu-8H; Sat, 21 Dec 2024 10:45:31 +0000
Received: by outflank-mailman (input) for mailman id 862347;
 Sat, 21 Dec 2024 10:43: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 1tOwxH-0007es-3h
 for xen-devel@lists.xenproject.org; Sat, 21 Dec 2024 10:43:31 +0000
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com
 [2607:f8b0:4864:20::62a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 68caa803-bf88-11ef-a0d9-8be0dac302b0;
 Sat, 21 Dec 2024 11:43:27 +0100 (CET)
Received: by mail-pl1-x62a.google.com with SMTP id
 d9443c01a7336-218c8aca5f1so30546005ad.0
 for ; Sat, 21 Dec 2024 02:43:27 -0800 (PST)
Received: from localhost.localdomain ([36.110.106.149])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-219dc9704dbsm42354905ad.98.2024.12.21.02.43.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 21 Dec 2024 02:43: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: 68caa803-bf88-11ef-a0d9-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734777806; x=1735382606; 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=fwXAi9iqIDIzfAU5c18r8JoVOb4Qest9HXa1Rz14pp4=;
        b=kVIbCZjRrr0ckQb26umUuJMKrdojTb3uJ7TEa28V4y1PzME5HcE0UbrVGAoTJ5KWq8
         CI7OF2IShGvePaym8ZR6cFqbfBC768CxwV/PCvJP/o/ujkhO7csdZBFNLoFXDG58L15W
         yxVThWN0Yows39/NG4ICGAZB9fkEXERqlxWI4tCmMRmJpkOwGnreZTCdlippDpDi1mT0
         bnKcwizhW7ABDLstvlE3EwSlNSFeoG1wsyBNlcdA9S9aO7+5RWYchms+28pYZzN/GrSv
         k6sz2AmV7QzrFGnhG99z90TQj2ooeEhIPp2NK8QrL6dHP5RZGi5okR2sGbSNKxw+YGwc
         ysJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734777806; x=1735382606;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=fwXAi9iqIDIzfAU5c18r8JoVOb4Qest9HXa1Rz14pp4=;
        b=s8cwjSVf4EWE4Nrr9jouE2UL+/5YXYCqUEc2V3pVtDH1nWcApk/4kGRZy6+CiYMgTR
         LR4oyfT9w+kVprWCLvUAnwkDbLvxYB070eGUNKo2vpkJU5uvNckQKbuuc8oaskO616x4
         43jWhZaA9q5Hs5GWkvSy+sfuivhJQT6uCUTf4AJlFj7zDrRHUrqEtR22D64avjp/2RPO
         jTqB9iIQhFmlvMioI/sm25faw55VAONmmGxrG31Q5kPIzgRAE+kcBWLgp89uACjI7VRO
         jChsPKsi4rU6JK6HVqPOjahV80ko5A6evNAFREnNgYSgy2+F9oxvVU70y49jU46YmzWz
         eHiA==
X-Forwarded-Encrypted: i=1; AJvYcCVptmTwNY0YSMVFFe9ID8aTXns9aRnJrk3XTWJcciheMQec9y7L93kjPYY45k+HPjCuewFC3yonRNo=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzgymbhDBQ0YLmLwo82lsaNUX+z9b2qUxm4onGxyOdTrkapKpwO
	2IyYomGfVPN27F0jOtyYiE+FSDTjvJ8Oo0sZIO+8O9zGIJRZPy2b
X-Gm-Gg: ASbGncv0ohIyZZjkQvtktwGnLvqpvdPupRuy79vNUaNmI4VYqeyvKkQ87bzJRsZuMyv
	tFHoEFGIONT9RAERNZi8+yRZbltSBbSmrajCV8sKqlD3sPCodntzWV7+mr6YD1RiqE211EsfdGz
	Me5K1ap6dED6M23t/goQJ3efzuA+DbKl/YmLW4gzm9jbI7N++bN3/2StCsBuILd6+RX0pLh8yBB
	b32jSa32xUaRKDQTn1LfgsjXyvhKLH1hsuw/yfQkp7p2I77KlJg0SZz6GtB9QlEgCS0I4SUdxOC
	palG
X-Google-Smtp-Source: AGHT+IH37l44gpKN2SMczTfkkhGh1+7up1lLyaDTGOpGW1HNfaVrgbfX7D+DmPYZwZJ6oMWsW+z7+Q==
X-Received: by 2002:a17:902:ea11:b0:216:4016:5aea with SMTP id d9443c01a7336-219e6ebaf1amr79593505ad.29.1734777805547;
        Sat, 21 Dec 2024 02:43:25 -0800 (PST)
From: Guo Weikang 
To: Andrew Morton ,
	Mike Rapoport ,
	Guo Weikang 
Cc: Dennis Zhou ,
	Tejun Heo ,
	Christoph Lameter ,
	Thomas Bogendoerfer ,
	Sam Creasey ,
	Geert Uytterhoeven ,
	Huacai Chen ,
	Will Deacon ,
	Catalin Marinas ,
	Oreoluwa Babatunde ,
	rafael.j.wysocki@intel.com,
	Palmer Dabbelt ,
	Hanjun Guo ,
	Easwar Hariharan ,
	Johannes Berg ,
	Ingo Molnar ,
	Dave Hansen ,
	Christian Brauner ,
	KP Singh ,
	Richard Henderson ,
	Matt Turner ,
	Russell King ,
	WANG Xuerui ,
	Michael Ellerman ,
	Stefan Kristiansson ,
	Stafford Horne ,
	Helge Deller ,
	Nicholas Piggin ,
	Christophe Leroy ,
	Naveen N Rao ,
	Madhavan Srinivasan ,
	Geoff Levand ,
	Paul Walmsley ,
	Palmer Dabbelt ,
	Albert Ou ,
	Andrey Ryabinin ,
	Alexander Potapenko ,
	Andrey Konovalov ,
	Dmitry Vyukov ,
	Vincenzo Frascino ,
	Heiko Carstens ,
	Vasily Gorbik ,
	Alexander Gordeev ,
	Christian Borntraeger ,
	Sven Schnelle ,
	Yoshinori Sato ,
	Rich Felker ,
	John Paul Adrian Glaubitz ,
	Andreas Larsson ,
	Richard Weinberger ,
	Anton Ivanov ,
	Johannes Berg ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	x86@kernel.org,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-m68k@lists.linux-m68k.org,
	linux-mips@vger.kernel.org,
	linux-openrisc@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org,
	kasan-dev@googlegroups.com,
	linux-s390@vger.kernel.org,
	linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org,
	linux-um@lists.infradead.org,
	linux-acpi@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-omap@vger.kernel.org,
	linux-clk@vger.kernel.org,
	devicetree@vger.kernel.org,
	linux-mm@kvack.org,
	linux-pm@vger.kernel.org
Subject: [PATCH v2] mm/memblock: Add memblock_alloc_or_panic interface
Date: Sat, 21 Dec 2024 18:43:04 +0800
Message-Id: <20241221104304.2655909-1-guoweikang.kernel@gmail.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Before SLUB initialization, various subsystems used memblock_alloc to
allocate memory. In most cases, when memory allocation fails, an immediate
panic is required. To simplify this behavior and reduce repetitive checks,
introduce `memblock_alloc_or_panic`. This function ensures that memory
allocation failures result in a panic automatically, improving code
readability and consistency across subsystems that require this behavior.

Signed-off-by: Guo Weikang 
---
 arch/alpha/kernel/core_cia.c            |  5 +-
 arch/alpha/kernel/core_marvel.c         | 10 +---
 arch/alpha/kernel/pci.c                 | 13 +----
 arch/alpha/kernel/pci_iommu.c           | 10 +---
 arch/arm/kernel/setup.c                 | 10 +---
 arch/arm/mm/mmu.c                       | 17 ++----
 arch/arm/mm/nommu.c                     |  5 +-
 arch/arm64/kernel/setup.c               |  4 +-
 arch/loongarch/kernel/setup.c           |  2 +-
 arch/loongarch/mm/init.c                | 13 ++---
 arch/m68k/mm/init.c                     |  5 +-
 arch/m68k/mm/mcfmmu.c                   | 10 +---
 arch/m68k/mm/motorola.c                 |  5 +-
 arch/m68k/mm/sun3mmu.c                  | 10 +---
 arch/m68k/sun3/sun3dvma.c               |  6 +--
 arch/mips/kernel/setup.c                |  5 +-
 arch/openrisc/mm/ioremap.c              |  5 +-
 arch/parisc/mm/init.c                   | 20 ++-----
 arch/powerpc/kernel/dt_cpu_ftrs.c       | 10 ++--
 arch/powerpc/kernel/pci_32.c            |  5 +-
 arch/powerpc/kernel/setup-common.c      |  5 +-
 arch/powerpc/kernel/setup_32.c          |  8 +--
 arch/powerpc/mm/book3s32/mmu.c          |  5 +-
 arch/powerpc/mm/book3s64/pgtable.c      |  6 +--
 arch/powerpc/mm/kasan/init_book3e_64.c  |  8 +--
 arch/powerpc/mm/kasan/init_book3s_64.c  |  2 +-
 arch/powerpc/mm/nohash/mmu_context.c    | 16 ++----
 arch/powerpc/mm/pgtable_32.c            |  7 +--
 arch/powerpc/platforms/powermac/nvram.c |  5 +-
 arch/powerpc/platforms/powernv/opal.c   |  5 +-
 arch/powerpc/platforms/ps3/setup.c      |  5 +-
 arch/powerpc/sysdev/msi_bitmap.c        |  5 +-
 arch/riscv/kernel/setup.c               |  4 +-
 arch/riscv/mm/kasan_init.c              | 14 ++---
 arch/s390/kernel/numa.c                 |  5 +-
 arch/s390/kernel/setup.c                | 20 ++-----
 arch/s390/kernel/smp.c                  |  9 ++--
 arch/s390/kernel/topology.c             | 10 +---
 arch/sh/mm/init.c                       | 10 +---
 arch/sparc/kernel/prom_32.c             |  4 +-
 arch/sparc/mm/srmmu.c                   | 14 ++---
 arch/um/drivers/net_kern.c              |  5 +-
 arch/um/drivers/vector_kern.c           |  5 +-
 arch/um/kernel/load_file.c              |  4 +-
 arch/x86/coco/sev/core.c                |  4 +-
 arch/x86/kernel/acpi/boot.c             |  5 +-
 arch/x86/kernel/apic/io_apic.c          |  9 +---
 arch/x86/kernel/e820.c                  |  5 +-
 arch/x86/platform/olpc/olpc_dt.c        |  6 +--
 arch/x86/xen/p2m.c                      |  8 +--
 arch/xtensa/mm/kasan_init.c             |  6 +--
 drivers/clk/ti/clk.c                    |  5 +-
 drivers/macintosh/smu.c                 |  6 +--
 drivers/of/fdt.c                        |  8 +--
 drivers/of/unittest.c                   |  8 +--
 include/linux/memblock.h                | 14 +++++
 init/main.c                             | 18 ++-----
 kernel/power/snapshot.c                 |  5 +-
 lib/cpumask.c                           |  5 +-
 mm/kmsan/shadow.c                       |  8 +--
 mm/numa.c                               |  8 +--
 mm/percpu.c                             | 70 +++++--------------------
 mm/sparse.c                             |  5 +-
 63 files changed, 131 insertions(+), 423 deletions(-)

diff --git a/arch/alpha/kernel/core_cia.c b/arch/alpha/kernel/core_cia.c
index ca3d9c732b61..6e577228e175 100644
--- a/arch/alpha/kernel/core_cia.c
+++ b/arch/alpha/kernel/core_cia.c
@@ -331,10 +331,7 @@ cia_prepare_tbia_workaround(int window)
 	long i;
 
 	/* Use minimal 1K map. */
-	ppte = memblock_alloc(CIA_BROKEN_TBIA_SIZE, 32768);
-	if (!ppte)
-		panic("%s: Failed to allocate %u bytes align=0x%x\n",
-		      __func__, CIA_BROKEN_TBIA_SIZE, 32768);
+	ppte = memblock_alloc_or_panic(CIA_BROKEN_TBIA_SIZE, 32768);
 	pte = (virt_to_phys(ppte) >> (PAGE_SHIFT - 1)) | 1;
 
 	for (i = 0; i < CIA_BROKEN_TBIA_SIZE / sizeof(unsigned long); ++i)
diff --git a/arch/alpha/kernel/core_marvel.c b/arch/alpha/kernel/core_marvel.c
index b22248044bf0..b1bfbd11980d 100644
--- a/arch/alpha/kernel/core_marvel.c
+++ b/arch/alpha/kernel/core_marvel.c
@@ -81,10 +81,7 @@ mk_resource_name(int pe, int port, char *str)
 	char *name;
 	
 	sprintf(tmp, "PCI %s PE %d PORT %d", str, pe, port);
-	name = memblock_alloc(strlen(tmp) + 1, SMP_CACHE_BYTES);
-	if (!name)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      strlen(tmp) + 1);
+	name = memblock_alloc_or_panic(strlen(tmp) + 1, SMP_CACHE_BYTES);
 	strcpy(name, tmp);
 
 	return name;
@@ -119,10 +116,7 @@ alloc_io7(unsigned int pe)
 		return NULL;
 	}
 
-	io7 = memblock_alloc(sizeof(*io7), SMP_CACHE_BYTES);
-	if (!io7)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*io7));
+	io7 = memblock_alloc_or_panic(sizeof(*io7), SMP_CACHE_BYTES);
 	io7->pe = pe;
 	raw_spin_lock_init(&io7->irq_lock);
 
diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
index 4458eb7f44f0..8e9b4ac86b7e 100644
--- a/arch/alpha/kernel/pci.c
+++ b/arch/alpha/kernel/pci.c
@@ -391,10 +391,7 @@ alloc_pci_controller(void)
 {
 	struct pci_controller *hose;
 
-	hose = memblock_alloc(sizeof(*hose), SMP_CACHE_BYTES);
-	if (!hose)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*hose));
+	hose = memblock_alloc_or_panic(sizeof(*hose), SMP_CACHE_BYTES);
 
 	*hose_tail = hose;
 	hose_tail = &hose->next;
@@ -405,13 +402,7 @@ alloc_pci_controller(void)
 struct resource * __init
 alloc_resource(void)
 {
-	void *ptr = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct resource));
-
-	return ptr;
+	return memblock_alloc_or_panic(sizeof(struct resource), SMP_CACHE_BYTES);
 }
 
 
diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index 7fcf3e9b7103..681f56089d9c 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -71,14 +71,8 @@ iommu_arena_new_node(int nid, struct pci_controller *hose, dma_addr_t base,
 	if (align < mem_size)
 		align = mem_size;
 
-	arena = memblock_alloc(sizeof(*arena), SMP_CACHE_BYTES);
-	if (!arena)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*arena));
-	arena->ptes = memblock_alloc(mem_size, align);
-	if (!arena->ptes)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, mem_size, align);
+	arena = memblock_alloc_or_panic(sizeof(*arena), SMP_CACHE_BYTES);
+	arena->ptes = memblock_alloc_or_panic(mem_size, align);
 
 	spin_lock_init(&arena->lock);
 	arena->hose = hose;
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index e6a857bf0ce6..a41c93988d2c 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -880,10 +880,7 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 		 */
 		boot_alias_start = phys_to_idmap(start);
 		if (arm_has_idmap_alias() && boot_alias_start != IDMAP_INVALID_ADDR) {
-			res = memblock_alloc(sizeof(*res), SMP_CACHE_BYTES);
-			if (!res)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, sizeof(*res));
+			res = memblock_alloc_or_panic(sizeof(*res), SMP_CACHE_BYTES);
 			res->name = "System RAM (boot alias)";
 			res->start = boot_alias_start;
 			res->end = phys_to_idmap(res_end);
@@ -891,10 +888,7 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 			request_resource(&iomem_resource, res);
 		}
 
-		res = memblock_alloc(sizeof(*res), SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      sizeof(*res));
+		res = memblock_alloc_or_panic(sizeof(*res), SMP_CACHE_BYTES);
 		res->name  = "System RAM";
 		res->start = start;
 		res->end = res_end;
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index f5b7a16c5803..f02f872ea8a9 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -726,13 +726,8 @@ EXPORT_SYMBOL(phys_mem_access_prot);
 
 static void __init *early_alloc(unsigned long sz)
 {
-	void *ptr = memblock_alloc(sz, sz);
+	return memblock_alloc_or_panic(sz, sz);
 
-	if (!ptr)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, sz, sz);
-
-	return ptr;
 }
 
 static void *__init late_alloc(unsigned long sz)
@@ -1027,10 +1022,7 @@ void __init iotable_init(struct map_desc *io_desc, int nr)
 	if (!nr)
 		return;
 
-	svm = memblock_alloc(sizeof(*svm) * nr, __alignof__(*svm));
-	if (!svm)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, sizeof(*svm) * nr, __alignof__(*svm));
+	svm = memblock_alloc_or_panic(sizeof(*svm) * nr, __alignof__(*svm));
 
 	for (md = io_desc; nr; md++, nr--) {
 		create_mapping(md);
@@ -1052,10 +1044,7 @@ void __init vm_reserve_area_early(unsigned long addr, unsigned long size,
 	struct vm_struct *vm;
 	struct static_vm *svm;
 
-	svm = memblock_alloc(sizeof(*svm), __alignof__(*svm));
-	if (!svm)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, sizeof(*svm), __alignof__(*svm));
+	svm = memblock_alloc_or_panic(sizeof(*svm), __alignof__(*svm));
 
 	vm = &svm->vm;
 	vm->addr = (void *)addr;
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index c415f3859b20..1a8f6914ee59 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -162,10 +162,7 @@ void __init paging_init(const struct machine_desc *mdesc)
 	mpu_setup();
 
 	/* allocate the zero page. */
-	zero_page = (void *)memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	zero_page = (void *)memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	bootmem_init();
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 4f613e8e0745..85104587f849 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -223,9 +223,7 @@ static void __init request_standard_resources(void)
 
 	num_standard_resources = memblock.memory.cnt;
 	res_size = num_standard_resources * sizeof(*standard_resources);
-	standard_resources = memblock_alloc(res_size, SMP_CACHE_BYTES);
-	if (!standard_resources)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, res_size);
+	standard_resources = memblock_alloc_or_panic(res_size, SMP_CACHE_BYTES);
 
 	for_each_mem_region(region) {
 		res = &standard_resources[i++];
diff --git a/arch/loongarch/kernel/setup.c b/arch/loongarch/kernel/setup.c
index 56934fe58170..edcfdfcad7d2 100644
--- a/arch/loongarch/kernel/setup.c
+++ b/arch/loongarch/kernel/setup.c
@@ -431,7 +431,7 @@ static void __init resource_init(void)
 
 	num_standard_resources = memblock.memory.cnt;
 	res_size = num_standard_resources * sizeof(*standard_resources);
-	standard_resources = memblock_alloc(res_size, SMP_CACHE_BYTES);
+	standard_resources = memblock_alloc_or_panic(res_size, SMP_CACHE_BYTES);
 
 	for_each_mem_region(region) {
 		res = &standard_resources[i++];
diff --git a/arch/loongarch/mm/init.c b/arch/loongarch/mm/init.c
index 188b52bbb254..ca5aa5f46a9f 100644
--- a/arch/loongarch/mm/init.c
+++ b/arch/loongarch/mm/init.c
@@ -174,9 +174,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 	pmd_t *pmd;
 
 	if (p4d_none(p4dp_get(p4d))) {
-		pud = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pud)
-			panic("%s: Failed to allocate memory\n", __func__);
+		pud = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		p4d_populate(&init_mm, p4d, pud);
 #ifndef __PAGETABLE_PUD_FOLDED
 		pud_init(pud);
@@ -185,9 +183,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 
 	pud = pud_offset(p4d, addr);
 	if (pud_none(pudp_get(pud))) {
-		pmd = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pmd)
-			panic("%s: Failed to allocate memory\n", __func__);
+		pmd = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 #ifndef __PAGETABLE_PMD_FOLDED
 		pmd_init(pmd);
@@ -198,10 +194,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 	if (!pmd_present(pmdp_get(pmd))) {
 		pte_t *pte;
 
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate memory\n", __func__);
-
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, pte);
 		kernel_pte_init(pte);
 	}
diff --git a/arch/m68k/mm/init.c b/arch/m68k/mm/init.c
index 1b47bec15832..8b11d0d545aa 100644
--- a/arch/m68k/mm/init.c
+++ b/arch/m68k/mm/init.c
@@ -68,10 +68,7 @@ void __init paging_init(void)
 
 	high_memory = (void *) end_mem;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	max_zone_pfn[ZONE_DMA] = end_mem >> PAGE_SHIFT;
 	free_area_init(max_zone_pfn);
 }
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index 9a6fa342e872..19a75029036c 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -42,20 +42,14 @@ void __init paging_init(void)
 	unsigned long max_zone_pfn[MAX_NR_ZONES] = { 0 };
 	int i;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	pg_dir = swapper_pg_dir;
 	memset(swapper_pg_dir, 0, sizeof(swapper_pg_dir));
 
 	size = num_pages * sizeof(pte_t);
 	size = (size + PAGE_SIZE) & ~(PAGE_SIZE-1);
-	next_pgtable = (unsigned long) memblock_alloc(size, PAGE_SIZE);
-	if (!next_pgtable)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, PAGE_SIZE);
+	next_pgtable = (unsigned long) memblock_alloc_or_panic(size, PAGE_SIZE);
 
 	pg_dir += PAGE_OFFSET >> PGDIR_SHIFT;
 
diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
index c1761d309fc6..795dd1f2b24f 100644
--- a/arch/m68k/mm/motorola.c
+++ b/arch/m68k/mm/motorola.c
@@ -491,10 +491,7 @@ void __init paging_init(void)
 	 * initialize the bad page table and bad page to point
 	 * to a couple of allocated pages
 	 */
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	/*
 	 * Set up SFC/DFC registers
diff --git a/arch/m68k/mm/sun3mmu.c b/arch/m68k/mm/sun3mmu.c
index 494739c1783e..1ecf6bdd08bf 100644
--- a/arch/m68k/mm/sun3mmu.c
+++ b/arch/m68k/mm/sun3mmu.c
@@ -44,10 +44,7 @@ void __init paging_init(void)
 	unsigned long max_zone_pfn[MAX_NR_ZONES] = { 0, };
 	unsigned long size;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	address = PAGE_OFFSET;
 	pg_dir = swapper_pg_dir;
@@ -57,10 +54,7 @@ void __init paging_init(void)
 	size = num_pages * sizeof(pte_t);
 	size = (size + PAGE_SIZE) & ~(PAGE_SIZE-1);
 
-	next_pgtable = (unsigned long)memblock_alloc(size, PAGE_SIZE);
-	if (!next_pgtable)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, PAGE_SIZE);
+	next_pgtable = (unsigned long)memblock_alloc_or_panic(size, PAGE_SIZE);
 	bootmem_end = (next_pgtable + size + PAGE_SIZE) & PAGE_MASK;
 
 	/* Map whole memory from PAGE_OFFSET (0x0E000000) */
diff --git a/arch/m68k/sun3/sun3dvma.c b/arch/m68k/sun3/sun3dvma.c
index 6ebf52740ad7..225fc735e466 100644
--- a/arch/m68k/sun3/sun3dvma.c
+++ b/arch/m68k/sun3/sun3dvma.c
@@ -252,12 +252,8 @@ void __init dvma_init(void)
 
 	list_add(&(hole->list), &hole_list);
 
-	iommu_use = memblock_alloc(IOMMU_TOTAL_ENTRIES * sizeof(unsigned long),
+	iommu_use = memblock_alloc_or_panic(IOMMU_TOTAL_ENTRIES * sizeof(unsigned long),
 				   SMP_CACHE_BYTES);
-	if (!iommu_use)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      IOMMU_TOTAL_ENTRIES * sizeof(unsigned long));
-
 	dvma_unmap_iommu(DVMA_START, DVMA_SIZE);
 
 	sun3_dvma_init();
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 12a1a4ffb602..fbfe0771317e 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -704,10 +704,7 @@ static void __init resource_init(void)
 	for_each_mem_range(i, &start, &end) {
 		struct resource *res;
 
-		res = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      sizeof(struct resource));
+		res = memblock_alloc_or_panic(sizeof(struct resource), SMP_CACHE_BYTES);
 
 		res->start = start;
 		/*
diff --git a/arch/openrisc/mm/ioremap.c b/arch/openrisc/mm/ioremap.c
index f59ea4c10b0f..8e63e86251ca 100644
--- a/arch/openrisc/mm/ioremap.c
+++ b/arch/openrisc/mm/ioremap.c
@@ -38,10 +38,7 @@ pte_t __ref *pte_alloc_one_kernel(struct mm_struct *mm)
 	if (likely(mem_init_done)) {
 		pte = (pte_t *)get_zeroed_page(GFP_KERNEL);
 	} else {
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	}
 
 	return pte;
diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index 96970fa75e4a..61c0a2477072 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -377,10 +377,8 @@ static void __ref map_pages(unsigned long start_vaddr,
 
 #if CONFIG_PGTABLE_LEVELS == 3
 		if (pud_none(*pud)) {
-			pmd = memblock_alloc(PAGE_SIZE << PMD_TABLE_ORDER,
+			pmd = memblock_alloc_or_panic(PAGE_SIZE << PMD_TABLE_ORDER,
 					     PAGE_SIZE << PMD_TABLE_ORDER);
-			if (!pmd)
-				panic("pmd allocation failed.\n");
 			pud_populate(NULL, pud, pmd);
 		}
 #endif
@@ -388,9 +386,7 @@ static void __ref map_pages(unsigned long start_vaddr,
 		pmd = pmd_offset(pud, vaddr);
 		for (tmp1 = start_pmd; tmp1 < PTRS_PER_PMD; tmp1++, pmd++) {
 			if (pmd_none(*pmd)) {
-				pg_table = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-				if (!pg_table)
-					panic("page table allocation failed\n");
+				pg_table = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 				pmd_populate_kernel(NULL, pmd, pg_table);
 			}
 
@@ -648,9 +644,7 @@ static void __init pagetable_init(void)
 	}
 #endif
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("zero page allocation failed.\n");
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 }
 
@@ -687,19 +681,15 @@ static void __init fixmap_init(void)
 
 #if CONFIG_PGTABLE_LEVELS == 3
 	if (pud_none(*pud)) {
-		pmd = memblock_alloc(PAGE_SIZE << PMD_TABLE_ORDER,
+		pmd = memblock_alloc_or_panic(PAGE_SIZE << PMD_TABLE_ORDER,
 				     PAGE_SIZE << PMD_TABLE_ORDER);
-		if (!pmd)
-			panic("fixmap: pmd allocation failed.\n");
 		pud_populate(NULL, pud, pmd);
 	}
 #endif
 
 	pmd = pmd_offset(pud, addr);
 	do {
-		pte_t *pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("fixmap: pte allocation failed.\n");
+		pte_t *pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 		pmd_populate_kernel(&init_mm, pmd, pte);
 
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 1bee15c013e7..3af6c06af02f 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -1087,12 +1087,10 @@ static int __init dt_cpu_ftrs_scan_callback(unsigned long node, const char
 	/* Count and allocate space for cpu features */
 	of_scan_flat_dt_subnodes(node, count_cpufeatures_subnodes,
 						&nr_dt_cpu_features);
-	dt_cpu_features = memblock_alloc(sizeof(struct dt_cpu_feature) * nr_dt_cpu_features, PAGE_SIZE);
-	if (!dt_cpu_features)
-		panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
-		      __func__,
-		      sizeof(struct dt_cpu_feature) * nr_dt_cpu_features,
-		      PAGE_SIZE);
+	dt_cpu_features =
+		memblock_alloc_or_panic(
+			sizeof(struct dt_cpu_feature) * nr_dt_cpu_features,
+			PAGE_SIZE);
 
 	cpufeatures_setup_start(isa);
 
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index ce0c8623e563..f8a3bd8cfae4 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -213,11 +213,8 @@ pci_create_OF_bus_map(void)
 	struct property* of_prop;
 	struct device_node *dn;
 
-	of_prop = memblock_alloc(sizeof(struct property) + 256,
+	of_prop = memblock_alloc_or_panic(sizeof(struct property) + 256,
 				 SMP_CACHE_BYTES);
-	if (!of_prop)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct property) + 256);
 	dn = of_find_node_by_path("/");
 	if (dn) {
 		memset(of_prop, -1, sizeof(struct property) + 256);
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 6fa179448c33..f3ea1329c566 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -458,11 +458,8 @@ void __init smp_setup_cpu_maps(void)
 
 	DBG("smp_setup_cpu_maps()\n");
 
-	cpu_to_phys_id = memblock_alloc(nr_cpu_ids * sizeof(u32),
+	cpu_to_phys_id = memblock_alloc_or_panic(nr_cpu_ids * sizeof(u32),
 					__alignof__(u32));
-	if (!cpu_to_phys_id)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, nr_cpu_ids * sizeof(u32), __alignof__(u32));
 
 	for_each_node_by_type(dn, "cpu") {
 		const __be32 *intserv;
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 75dbf3e0d9c4..5a1bf501fbe1 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -140,13 +140,7 @@ arch_initcall(ppc_init);
 
 static void *__init alloc_stack(void)
 {
-	void *ptr = memblock_alloc(THREAD_SIZE, THREAD_ALIGN);
-
-	if (!ptr)
-		panic("cannot allocate %d bytes for stack at %pS\n",
-		      THREAD_SIZE, (void *)_RET_IP_);
-
-	return ptr;
+	return memblock_alloc_or_panic(THREAD_SIZE, THREAD_ALIGN);
 }
 
 void __init irqstack_early_init(void)
diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/mmu.c
index 6978344edcb4..be9c4106e22f 100644
--- a/arch/powerpc/mm/book3s32/mmu.c
+++ b/arch/powerpc/mm/book3s32/mmu.c
@@ -377,10 +377,7 @@ void __init MMU_init_hw(void)
 	 * Find some memory for the hash table.
 	 */
 	if ( ppc_md.progress ) ppc_md.progress("hash:find piece", 0x322);
-	Hash = memblock_alloc(Hash_size, Hash_size);
-	if (!Hash)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, Hash_size, Hash_size);
+	Hash = memblock_alloc_or_panic(Hash_size, Hash_size);
 	_SDR1 = __pa(Hash) | SDR1_LOW_BITS;
 
 	pr_info("Total memory = %lldMB; using %ldkB for hash table\n",
diff --git a/arch/powerpc/mm/book3s64/pgtable.c b/arch/powerpc/mm/book3s64/pgtable.c
index 374542528080..0b1f419b7404 100644
--- a/arch/powerpc/mm/book3s64/pgtable.c
+++ b/arch/powerpc/mm/book3s64/pgtable.c
@@ -330,11 +330,7 @@ void __init mmu_partition_table_init(void)
 	unsigned long ptcr;
 
 	/* Initialize the Partition Table with no entries */
-	partition_tb = memblock_alloc(patb_size, patb_size);
-	if (!partition_tb)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, patb_size, patb_size);
-
+	partition_tb = memblock_alloc_or_panic(patb_size, patb_size);
 	ptcr = __pa(partition_tb) | (PATB_SIZE_SHIFT - 12);
 	set_ptcr_when_no_uv(ptcr);
 	powernv_set_nmmu_ptcr(ptcr);
diff --git a/arch/powerpc/mm/kasan/init_book3e_64.c b/arch/powerpc/mm/kasan/init_book3e_64.c
index 43c03b84ff32..60c78aac0f63 100644
--- a/arch/powerpc/mm/kasan/init_book3e_64.c
+++ b/arch/powerpc/mm/kasan/init_book3e_64.c
@@ -40,19 +40,19 @@ static int __init kasan_map_kernel_page(unsigned long ea, unsigned long pa, pgpr
 	pgdp = pgd_offset_k(ea);
 	p4dp = p4d_offset(pgdp, ea);
 	if (kasan_pud_table(*p4dp)) {
-		pudp = memblock_alloc(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
+		pudp = memblock_alloc_or_panic(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
 		memcpy(pudp, kasan_early_shadow_pud, PUD_TABLE_SIZE);
 		p4d_populate(&init_mm, p4dp, pudp);
 	}
 	pudp = pud_offset(p4dp, ea);
 	if (kasan_pmd_table(*pudp)) {
-		pmdp = memblock_alloc(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
+		pmdp = memblock_alloc_or_panic(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
 		memcpy(pmdp, kasan_early_shadow_pmd, PMD_TABLE_SIZE);
 		pud_populate(&init_mm, pudp, pmdp);
 	}
 	pmdp = pmd_offset(pudp, ea);
 	if (kasan_pte_table(*pmdp)) {
-		ptep = memblock_alloc(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
+		ptep = memblock_alloc_or_panic(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
 		memcpy(ptep, kasan_early_shadow_pte, PTE_TABLE_SIZE);
 		pmd_populate_kernel(&init_mm, pmdp, ptep);
 	}
@@ -74,7 +74,7 @@ static void __init kasan_init_phys_region(void *start, void *end)
 	k_start = ALIGN_DOWN((unsigned long)kasan_mem_to_shadow(start), PAGE_SIZE);
 	k_end = ALIGN((unsigned long)kasan_mem_to_shadow(end), PAGE_SIZE);
 
-	va = memblock_alloc(k_end - k_start, PAGE_SIZE);
+	va = memblock_alloc_or_panic(k_end - k_start, PAGE_SIZE);
 	for (k_cur = k_start; k_cur < k_end; k_cur += PAGE_SIZE, va += PAGE_SIZE)
 		kasan_map_kernel_page(k_cur, __pa(va), PAGE_KERNEL);
 }
diff --git a/arch/powerpc/mm/kasan/init_book3s_64.c b/arch/powerpc/mm/kasan/init_book3s_64.c
index 3fb5ce4f48f4..7d959544c077 100644
--- a/arch/powerpc/mm/kasan/init_book3s_64.c
+++ b/arch/powerpc/mm/kasan/init_book3s_64.c
@@ -32,7 +32,7 @@ static void __init kasan_init_phys_region(void *start, void *end)
 	k_start = ALIGN_DOWN((unsigned long)kasan_mem_to_shadow(start), PAGE_SIZE);
 	k_end = ALIGN((unsigned long)kasan_mem_to_shadow(end), PAGE_SIZE);
 
-	va = memblock_alloc(k_end - k_start, PAGE_SIZE);
+	va = memblock_alloc_or_panic(k_end - k_start, PAGE_SIZE);
 	for (k_cur = k_start; k_cur < k_end; k_cur += PAGE_SIZE, va += PAGE_SIZE)
 		map_kernel_page(k_cur, __pa(va), PAGE_KERNEL);
 }
diff --git a/arch/powerpc/mm/nohash/mmu_context.c b/arch/powerpc/mm/nohash/mmu_context.c
index 0b181da40ddb..a1a4e697251a 100644
--- a/arch/powerpc/mm/nohash/mmu_context.c
+++ b/arch/powerpc/mm/nohash/mmu_context.c
@@ -385,21 +385,11 @@ void __init mmu_context_init(void)
 	/*
 	 * Allocate the maps used by context management
 	 */
-	context_map = memblock_alloc(CTX_MAP_SIZE, SMP_CACHE_BYTES);
-	if (!context_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      CTX_MAP_SIZE);
-	context_mm = memblock_alloc(sizeof(void *) * (LAST_CONTEXT + 1),
+	context_map = memblock_alloc_or_panic(CTX_MAP_SIZE, SMP_CACHE_BYTES);
+	context_mm = memblock_alloc_or_panic(sizeof(void *) * (LAST_CONTEXT + 1),
 				    SMP_CACHE_BYTES);
-	if (!context_mm)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(void *) * (LAST_CONTEXT + 1));
 	if (IS_ENABLED(CONFIG_SMP)) {
-		stale_map[boot_cpuid] = memblock_alloc(CTX_MAP_SIZE, SMP_CACHE_BYTES);
-		if (!stale_map[boot_cpuid])
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      CTX_MAP_SIZE);
-
+		stale_map[boot_cpuid] = memblock_alloc_or_panic(CTX_MAP_SIZE, SMP_CACHE_BYTES);
 		cpuhp_setup_state_nocalls(CPUHP_POWERPC_MMU_CTX_PREPARE,
 					  "powerpc/mmu/ctx:prepare",
 					  mmu_ctx_cpu_prepare, mmu_ctx_cpu_dead);
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 787b22206386..15276068f657 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -50,13 +50,8 @@ notrace void __init early_ioremap_init(void)
 
 void __init *early_alloc_pgtable(unsigned long size)
 {
-	void *ptr = memblock_alloc(size, size);
+	return memblock_alloc_or_panic(size, size);
 
-	if (!ptr)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, size);
-
-	return ptr;
 }
 
 pte_t __init *early_pte_alloc_kernel(pmd_t *pmdp, unsigned long va)
diff --git a/arch/powerpc/platforms/powermac/nvram.c b/arch/powerpc/platforms/powermac/nvram.c
index fe2e0249cbc2..a112d26185a0 100644
--- a/arch/powerpc/platforms/powermac/nvram.c
+++ b/arch/powerpc/platforms/powermac/nvram.c
@@ -514,10 +514,7 @@ static int __init core99_nvram_setup(struct device_node *dp, unsigned long addr)
 		printk(KERN_ERR "nvram: no address\n");
 		return -EINVAL;
 	}
-	nvram_image = memblock_alloc(NVRAM_SIZE, SMP_CACHE_BYTES);
-	if (!nvram_image)
-		panic("%s: Failed to allocate %u bytes\n", __func__,
-		      NVRAM_SIZE);
+	nvram_image = memblock_alloc_or_panic(NVRAM_SIZE, SMP_CACHE_BYTES);
 	nvram_data = ioremap(addr, NVRAM_SIZE*2);
 	nvram_naddrs = 1; /* Make sure we get the correct case */
 
diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
index 5d0f35bb917e..09bd93464b4f 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -180,10 +180,7 @@ int __init early_init_dt_scan_recoverable_ranges(unsigned long node,
 	/*
 	 * Allocate a buffer to hold the MC recoverable ranges.
 	 */
-	mc_recoverable_range = memblock_alloc(size, __alignof__(u64));
-	if (!mc_recoverable_range)
-		panic("%s: Failed to allocate %u bytes align=0x%lx\n",
-		      __func__, size, __alignof__(u64));
+	mc_recoverable_range = memblock_alloc_or_panic(size, __alignof__(u64));
 
 	for (i = 0; i < mc_recoverable_range_len; i++) {
 		mc_recoverable_range[i].start_addr =
diff --git a/arch/powerpc/platforms/ps3/setup.c b/arch/powerpc/platforms/ps3/setup.c
index 5144f11359f7..150c09b58ae8 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -115,10 +115,7 @@ static void __init prealloc(struct ps3_prealloc *p)
 	if (!p->size)
 		return;
 
-	p->address = memblock_alloc(p->size, p->align);
-	if (!p->address)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, p->size, p->align);
+	p->address = memblock_alloc_or_panic(p->size, p->align);
 
 	printk(KERN_INFO "%s: %lu bytes at %p\n", p->name, p->size,
 	       p->address);
diff --git a/arch/powerpc/sysdev/msi_bitmap.c b/arch/powerpc/sysdev/msi_bitmap.c
index 0b6e37f3ffb8..456a4f64ae0a 100644
--- a/arch/powerpc/sysdev/msi_bitmap.c
+++ b/arch/powerpc/sysdev/msi_bitmap.c
@@ -124,10 +124,7 @@ int __ref msi_bitmap_alloc(struct msi_bitmap *bmp, unsigned int irq_count,
 	if (bmp->bitmap_from_slab)
 		bmp->bitmap = kzalloc(size, GFP_KERNEL);
 	else {
-		bmp->bitmap = memblock_alloc(size, SMP_CACHE_BYTES);
-		if (!bmp->bitmap)
-			panic("%s: Failed to allocate %u bytes\n", __func__,
-			      size);
+		bmp->bitmap = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 		/* the bitmap won't be freed from memblock allocator */
 		kmemleak_not_leak(bmp->bitmap);
 	}
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 45010e71df86..f1793630fc51 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -147,9 +147,7 @@ static void __init init_resources(void)
 	res_idx = num_resources - 1;
 
 	mem_res_sz = num_resources * sizeof(*mem_res);
-	mem_res = memblock_alloc(mem_res_sz, SMP_CACHE_BYTES);
-	if (!mem_res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, mem_res_sz);
+	mem_res = memblock_alloc_or_panic(mem_res_sz, SMP_CACHE_BYTES);
 
 	/*
 	 * Start by adding the reserved regions, if they overlap
diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index c301c8d291d2..41c635d6aca4 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -32,7 +32,7 @@ static void __init kasan_populate_pte(pmd_t *pmd, unsigned long vaddr, unsigned
 	pte_t *ptep, *p;
 
 	if (pmd_none(pmdp_get(pmd))) {
-		p = memblock_alloc(PTRS_PER_PTE * sizeof(pte_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PTE * sizeof(pte_t), PAGE_SIZE);
 		set_pmd(pmd, pfn_pmd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -54,7 +54,7 @@ static void __init kasan_populate_pmd(pud_t *pud, unsigned long vaddr, unsigned
 	unsigned long next;
 
 	if (pud_none(pudp_get(pud))) {
-		p = memblock_alloc(PTRS_PER_PMD * sizeof(pmd_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PMD * sizeof(pmd_t), PAGE_SIZE);
 		set_pud(pud, pfn_pud(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -85,7 +85,7 @@ static void __init kasan_populate_pud(p4d_t *p4d,
 	unsigned long next;
 
 	if (p4d_none(p4dp_get(p4d))) {
-		p = memblock_alloc(PTRS_PER_PUD * sizeof(pud_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PUD * sizeof(pud_t), PAGE_SIZE);
 		set_p4d(p4d, pfn_p4d(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -116,7 +116,7 @@ static void __init kasan_populate_p4d(pgd_t *pgd,
 	unsigned long next;
 
 	if (pgd_none(pgdp_get(pgd))) {
-		p = memblock_alloc(PTRS_PER_P4D * sizeof(p4d_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_P4D * sizeof(p4d_t), PAGE_SIZE);
 		set_pgd(pgd, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -385,7 +385,7 @@ static void __init kasan_shallow_populate_pud(p4d_t *p4d,
 		next = pud_addr_end(vaddr, end);
 
 		if (pud_none(pudp_get(pud_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_pud(pud_k, pfn_pud(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
@@ -405,7 +405,7 @@ static void __init kasan_shallow_populate_p4d(pgd_t *pgd,
 		next = p4d_addr_end(vaddr, end);
 
 		if (p4d_none(p4dp_get(p4d_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_p4d(p4d_k, pfn_p4d(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
@@ -424,7 +424,7 @@ static void __init kasan_shallow_populate_pgd(unsigned long vaddr, unsigned long
 		next = pgd_addr_end(vaddr, end);
 
 		if (pgd_none(pgdp_get(pgd_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_pgd(pgd_k, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
diff --git a/arch/s390/kernel/numa.c b/arch/s390/kernel/numa.c
index ddc1448ea2e1..a33e20f73330 100644
--- a/arch/s390/kernel/numa.c
+++ b/arch/s390/kernel/numa.c
@@ -22,10 +22,7 @@ void __init numa_setup(void)
 	node_set(0, node_possible_map);
 	node_set_online(0);
 	for (nid = 0; nid < MAX_NUMNODES; nid++) {
-		NODE_DATA(nid) = memblock_alloc(sizeof(pg_data_t), 8);
-		if (!NODE_DATA(nid))
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(pg_data_t), 8);
+		NODE_DATA(nid) = memblock_alloc_or_panic(sizeof(pg_data_t), 8);
 	}
 	NODE_DATA(0)->node_spanned_pages = memblock_end_of_DRAM() >> PAGE_SHIFT;
 	NODE_DATA(0)->node_id = 0;
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index 0ce550faf073..1298f0860733 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -376,11 +376,7 @@ static unsigned long __init stack_alloc_early(void)
 {
 	unsigned long stack;
 
-	stack = (unsigned long)memblock_alloc(THREAD_SIZE, THREAD_SIZE);
-	if (!stack) {
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, THREAD_SIZE, THREAD_SIZE);
-	}
+	stack = (unsigned long)memblock_alloc_or_panic(THREAD_SIZE, THREAD_SIZE);
 	return stack;
 }
 
@@ -504,10 +500,7 @@ static void __init setup_resources(void)
 	bss_resource.end = __pa_symbol(__bss_stop) - 1;
 
 	for_each_mem_range(i, &start, &end) {
-		res = memblock_alloc(sizeof(*res), 8);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(*res), 8);
+		res = memblock_alloc_or_panic(sizeof(*res), 8);
 		res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
 
 		res->name = "System RAM";
@@ -526,10 +519,7 @@ static void __init setup_resources(void)
 			    std_res->start > res->end)
 				continue;
 			if (std_res->end > res->end) {
-				sub_res = memblock_alloc(sizeof(*sub_res), 8);
-				if (!sub_res)
-					panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-					      __func__, sizeof(*sub_res), 8);
+				sub_res = memblock_alloc_or_panic(sizeof(*sub_res), 8);
 				*sub_res = *std_res;
 				sub_res->end = res->end;
 				std_res->start = res->end + 1;
@@ -816,9 +806,7 @@ static void __init setup_randomness(void)
 {
 	struct sysinfo_3_2_2 *vmms;
 
-	vmms = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!vmms)
-		panic("Failed to allocate memory for sysinfo structure\n");
+	vmms = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	if (stsi(vmms, 3, 2, 2) == 0 && vmms->count)
 		add_device_randomness(&vmms->vm, sizeof(vmms->vm[0]) * vmms->count);
 	memblock_free(vmms, PAGE_SIZE);
diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
index 822d8e6f8717..d77aaefb59bd 100644
--- a/arch/s390/kernel/smp.c
+++ b/arch/s390/kernel/smp.c
@@ -611,9 +611,9 @@ void __init smp_save_dump_ipl_cpu(void)
 	if (!dump_available())
 		return;
 	sa = save_area_alloc(true);
-	regs = memblock_alloc(512, 8);
-	if (!sa || !regs)
+	if (!sa)
 		panic("could not allocate memory for boot CPU save area\n");
+	regs = memblock_alloc_or_panic(512, 8);
 	copy_oldmem_kernel(regs, __LC_FPREGS_SAVE_AREA, 512);
 	save_area_add_regs(sa, regs);
 	memblock_free(regs, 512);
@@ -792,10 +792,7 @@ void __init smp_detect_cpus(void)
 	u16 address;
 
 	/* Get CPU information */
-	info = memblock_alloc(sizeof(*info), 8);
-	if (!info)
-		panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-		      __func__, sizeof(*info), 8);
+	info = memblock_alloc_or_panic(sizeof(*info), 8);
 	smp_get_core_info(info, 1);
 	/* Find boot CPU type */
 	if (sclp.has_core_type) {
diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
index 0fd56a1cadbd..cf5ee6032c0b 100644
--- a/arch/s390/kernel/topology.c
+++ b/arch/s390/kernel/topology.c
@@ -548,10 +548,7 @@ static void __init alloc_masks(struct sysinfo_15_1_x *info,
 		nr_masks *= info->mag[TOPOLOGY_NR_MAG - offset - 1 - i];
 	nr_masks = max(nr_masks, 1);
 	for (i = 0; i < nr_masks; i++) {
-		mask->next = memblock_alloc(sizeof(*mask->next), 8);
-		if (!mask->next)
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(*mask->next), 8);
+		mask->next = memblock_alloc_or_panic(sizeof(*mask->next), 8);
 		mask = mask->next;
 	}
 }
@@ -569,10 +566,7 @@ void __init topology_init_early(void)
 	}
 	if (!MACHINE_HAS_TOPOLOGY)
 		goto out;
-	tl_info = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!tl_info)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	tl_info = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	info = tl_info;
 	store_topology(info);
 	pr_info("The CPU configuration topology of the machine is: %d %d %d %d %d %d / %d\n",
diff --git a/arch/sh/mm/init.c b/arch/sh/mm/init.c
index 2a88b0c9e70f..289a2fecebef 100644
--- a/arch/sh/mm/init.c
+++ b/arch/sh/mm/init.c
@@ -137,10 +137,7 @@ static pmd_t * __init one_md_table_init(pud_t *pud)
 	if (pud_none(*pud)) {
 		pmd_t *pmd;
 
-		pmd = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pmd)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pmd = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 		BUG_ON(pmd != pmd_offset(pud, 0));
 	}
@@ -153,10 +150,7 @@ static pte_t * __init one_page_table_init(pmd_t *pmd)
 	if (pmd_none(*pmd)) {
 		pte_t *pte;
 
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, pte);
 		BUG_ON(pte != pte_offset_kernel(pmd, 0));
 	}
diff --git a/arch/sparc/kernel/prom_32.c b/arch/sparc/kernel/prom_32.c
index 3df960c137f7..a67dd67f10c8 100644
--- a/arch/sparc/kernel/prom_32.c
+++ b/arch/sparc/kernel/prom_32.c
@@ -28,9 +28,7 @@ void * __init prom_early_alloc(unsigned long size)
 {
 	void *ret;
 
-	ret = memblock_alloc(size, SMP_CACHE_BYTES);
-	if (!ret)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, size);
+	ret = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 
 	prom_early_allocated += size;
 
diff --git a/arch/sparc/mm/srmmu.c b/arch/sparc/mm/srmmu.c
index 9df51a62333d..e36c2a0ff748 100644
--- a/arch/sparc/mm/srmmu.c
+++ b/arch/sparc/mm/srmmu.c
@@ -277,19 +277,13 @@ static void __init srmmu_nocache_init(void)
 
 	bitmap_bits = srmmu_nocache_size >> SRMMU_NOCACHE_BITMAP_SHIFT;
 
-	srmmu_nocache_pool = memblock_alloc(srmmu_nocache_size,
+	srmmu_nocache_pool = memblock_alloc_or_panic(srmmu_nocache_size,
 					    SRMMU_NOCACHE_ALIGN_MAX);
-	if (!srmmu_nocache_pool)
-		panic("%s: Failed to allocate %lu bytes align=0x%x\n",
-		      __func__, srmmu_nocache_size, SRMMU_NOCACHE_ALIGN_MAX);
 	memset(srmmu_nocache_pool, 0, srmmu_nocache_size);
 
 	srmmu_nocache_bitmap =
-		memblock_alloc(BITS_TO_LONGS(bitmap_bits) * sizeof(long),
+		memblock_alloc_or_panic(BITS_TO_LONGS(bitmap_bits) * sizeof(long),
 			       SMP_CACHE_BYTES);
-	if (!srmmu_nocache_bitmap)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      BITS_TO_LONGS(bitmap_bits) * sizeof(long));
 	bit_map_init(&srmmu_nocache_map, srmmu_nocache_bitmap, bitmap_bits);
 
 	srmmu_swapper_pg_dir = __srmmu_get_nocache(SRMMU_PGD_TABLE_SIZE, SRMMU_PGD_TABLE_SIZE);
@@ -452,9 +446,7 @@ static void __init sparc_context_init(int numctx)
 	unsigned long size;
 
 	size = numctx * sizeof(struct ctx_list);
-	ctx_list_pool = memblock_alloc(size, SMP_CACHE_BYTES);
-	if (!ctx_list_pool)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, size);
+	ctx_list_pool = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 
 	for (ctx = 0; ctx < numctx; ctx++) {
 		struct ctx_list *clist;
diff --git a/arch/um/drivers/net_kern.c b/arch/um/drivers/net_kern.c
index 75d04fb4994a..d5a9c5aabaec 100644
--- a/arch/um/drivers/net_kern.c
+++ b/arch/um/drivers/net_kern.c
@@ -636,10 +636,7 @@ static int __init eth_setup(char *str)
 		return 1;
 	}
 
-	new = memblock_alloc(sizeof(*new), SMP_CACHE_BYTES);
-	if (!new)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*new));
+	new = memblock_alloc_or_panic(sizeof(*new), SMP_CACHE_BYTES);
 
 	INIT_LIST_HEAD(&new->list);
 	new->index = n;
diff --git a/arch/um/drivers/vector_kern.c b/arch/um/drivers/vector_kern.c
index 64c09db392c1..85b129e2b70b 100644
--- a/arch/um/drivers/vector_kern.c
+++ b/arch/um/drivers/vector_kern.c
@@ -1694,10 +1694,7 @@ static int __init vector_setup(char *str)
 				 str, error);
 		return 1;
 	}
-	new = memblock_alloc(sizeof(*new), SMP_CACHE_BYTES);
-	if (!new)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*new));
+	new = memblock_alloc_or_panic(sizeof(*new), SMP_CACHE_BYTES);
 	INIT_LIST_HEAD(&new->list);
 	new->unit = n;
 	new->arguments = str;
diff --git a/arch/um/kernel/load_file.c b/arch/um/kernel/load_file.c
index 5cecd0e291fb..cb9d178ab7d8 100644
--- a/arch/um/kernel/load_file.c
+++ b/arch/um/kernel/load_file.c
@@ -48,9 +48,7 @@ void *uml_load_file(const char *filename, unsigned long long *size)
 		return NULL;
 	}
 
-	area = memblock_alloc(*size, SMP_CACHE_BYTES);
-	if (!area)
-		panic("%s: Failed to allocate %llu bytes\n", __func__, *size);
+	area = memblock_alloc_or_panic(*size, SMP_CACHE_BYTES);
 
 	if (__uml_load_file(filename, area, *size)) {
 		memblock_free(area, *size);
diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index 499b41953e3c..fa218270c1db 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -1567,9 +1567,7 @@ static void __init alloc_runtime_data(int cpu)
 		struct svsm_ca *caa;
 
 		/* Allocate the SVSM CA page if an SVSM is present */
-		caa = memblock_alloc(sizeof(*caa), PAGE_SIZE);
-		if (!caa)
-			panic("Can't allocate SVSM CA page\n");
+		caa = memblock_alloc_or_panic(sizeof(*caa), PAGE_SIZE);
 
 		per_cpu(svsm_caa, cpu) = caa;
 		per_cpu(svsm_caa_pa, cpu) = __pa(caa);
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 3a44a9dc3fb7..7c15d6e83c37 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -911,11 +911,8 @@ static int __init acpi_parse_hpet(struct acpi_table_header *table)
 	 * the resource tree during the lateinit timeframe.
 	 */
 #define HPET_RESOURCE_NAME_SIZE 9
-	hpet_res = memblock_alloc(sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE,
+	hpet_res = memblock_alloc_or_panic(sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE,
 				  SMP_CACHE_BYTES);
-	if (!hpet_res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE);
 
 	hpet_res->name = (void *)&hpet_res[1];
 	hpet_res->flags = IORESOURCE_MEM;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 1029ea4ac8ba..a57d3fa7c6b6 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2503,9 +2503,7 @@ static struct resource * __init ioapic_setup_resources(void)
 	n = IOAPIC_RESOURCE_NAME_SIZE + sizeof(struct resource);
 	n *= nr_ioapics;
 
-	mem = memblock_alloc(n, SMP_CACHE_BYTES);
-	if (!mem)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, n);
+	mem = memblock_alloc_or_panic(n, SMP_CACHE_BYTES);
 	res = (void *)mem;
 
 	mem += sizeof(struct resource) * nr_ioapics;
@@ -2564,11 +2562,8 @@ void __init io_apic_init_mappings(void)
 #ifdef CONFIG_X86_32
 fake_ioapic_page:
 #endif
-			ioapic_phys = (unsigned long)memblock_alloc(PAGE_SIZE,
+			ioapic_phys = (unsigned long)memblock_alloc_or_panic(PAGE_SIZE,
 								    PAGE_SIZE);
-			if (!ioapic_phys)
-				panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-				      __func__, PAGE_SIZE, PAGE_SIZE);
 			ioapic_phys = __pa(ioapic_phys);
 		}
 		io_apic_set_fixmap(idx, ioapic_phys);
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 4893d30ce438..82b96ed9890a 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1146,11 +1146,8 @@ void __init e820__reserve_resources(void)
 	struct resource *res;
 	u64 end;
 
-	res = memblock_alloc(sizeof(*res) * e820_table->nr_entries,
+	res = memblock_alloc_or_panic(sizeof(*res) * e820_table->nr_entries,
 			     SMP_CACHE_BYTES);
-	if (!res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*res) * e820_table->nr_entries);
 	e820_res = res;
 
 	for (i = 0; i < e820_table->nr_entries; i++) {
diff --git a/arch/x86/platform/olpc/olpc_dt.c b/arch/x86/platform/olpc/olpc_dt.c
index 74ebd6882690..cf5dca2dbb91 100644
--- a/arch/x86/platform/olpc/olpc_dt.c
+++ b/arch/x86/platform/olpc/olpc_dt.c
@@ -136,11 +136,7 @@ void * __init prom_early_alloc(unsigned long size)
 		 * fast enough on the platforms we care about while minimizing
 		 * wasted bootmem) and hand off chunks of it to callers.
 		 */
-		res = memblock_alloc(chunk_size, SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      chunk_size);
-		BUG_ON(!res);
+		res = memblock_alloc_or_panic(chunk_size, SMP_CACHE_BYTES);
 		prom_early_allocated += chunk_size;
 		memset(res, 0, chunk_size);
 		free_mem = chunk_size;
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index b52d3e17e2c1..56914e21e303 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -178,13 +178,7 @@ static void p2m_init_identity(unsigned long *p2m, unsigned long pfn)
 static void * __ref alloc_p2m_page(void)
 {
 	if (unlikely(!slab_is_available())) {
-		void *ptr = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-
-		if (!ptr)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
-
-		return ptr;
+		return memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	}
 
 	return (void *)__get_free_page(GFP_KERNEL);
diff --git a/arch/xtensa/mm/kasan_init.c b/arch/xtensa/mm/kasan_init.c
index f00d122aa806..f39c4d83173a 100644
--- a/arch/xtensa/mm/kasan_init.c
+++ b/arch/xtensa/mm/kasan_init.c
@@ -39,11 +39,7 @@ static void __init populate(void *start, void *end)
 	unsigned long i, j;
 	unsigned long vaddr = (unsigned long)start;
 	pmd_t *pmd = pmd_off_k(vaddr);
-	pte_t *pte = memblock_alloc(n_pages * sizeof(pte_t), PAGE_SIZE);
-
-	if (!pte)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, n_pages * sizeof(pte_t), PAGE_SIZE);
+	pte_t *pte = memblock_alloc_or_panic(n_pages * sizeof(pte_t), PAGE_SIZE);
 
 	pr_debug("%s: %p - %p\n", __func__, start, end);
 
diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
index f2117fef7c7d..9c75dcc9a534 100644
--- a/drivers/clk/ti/clk.c
+++ b/drivers/clk/ti/clk.c
@@ -449,10 +449,7 @@ void __init omap2_clk_legacy_provider_init(int index, void __iomem *mem)
 {
 	struct clk_iomap *io;
 
-	io = memblock_alloc(sizeof(*io), SMP_CACHE_BYTES);
-	if (!io)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*io));
+	io = memblock_alloc_or_panic(sizeof(*io), SMP_CACHE_BYTES);
 
 	io->mem = mem;
 
diff --git a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
index a01bc5090cdf..a1534cc6c641 100644
--- a/drivers/macintosh/smu.c
+++ b/drivers/macintosh/smu.c
@@ -492,11 +492,7 @@ int __init smu_init (void)
 		goto fail_np;
 	}
 
-	smu = memblock_alloc(sizeof(struct smu_device), SMP_CACHE_BYTES);
-	if (!smu)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct smu_device));
-
+	smu = memblock_alloc_or_panic(sizeof(struct smu_device), SMP_CACHE_BYTES);
 	spin_lock_init(&smu->lock);
 	INIT_LIST_HEAD(&smu->cmd_list);
 	INIT_LIST_HEAD(&smu->cmd_i2c_list);
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 4b1e9f101ce3..809135e2c7f5 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1126,13 +1126,7 @@ void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
 
 static void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
 {
-	void *ptr = memblock_alloc(size, align);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %llu bytes align=0x%llx\n",
-		      __func__, size, align);
-
-	return ptr;
+	return memblock_alloc_or_panic(size, align);
 }
 
 bool __init early_init_dt_verify(void *dt_virt, phys_addr_t dt_phys)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index e50570629dc0..837eafa81636 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -3675,13 +3675,7 @@ static struct device_node *overlay_base_root;
 
 static void * __init dt_alloc_memory(u64 size, u64 align)
 {
-	void *ptr = memblock_alloc(size, align);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %llu bytes align=0x%llx\n",
-		      __func__, size, align);
-
-	return ptr;
+	return memblock_alloc_or_panic(size, align);
 }
 
 /*
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 673d5cae7c81..4aa4590ef9af 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -417,6 +417,20 @@ static __always_inline void *memblock_alloc(phys_addr_t size, phys_addr_t align)
 				      MEMBLOCK_ALLOC_ACCESSIBLE, NUMA_NO_NODE);
 }
 
+static __always_inline void *__memblock_alloc_or_panic(phys_addr_t size,
+						       phys_addr_t align,
+						       const char *func)
+{
+	void *addr = memblock_alloc(size, align);
+
+	if (unlikely(!addr))
+		panic("%s: Failed to allocate %llu bytes\n", func, size);
+	return addr;
+}
+
+#define memblock_alloc_or_panic(size, align)    \
+	 __memblock_alloc_or_panic(size, align, __func__)
+
 static inline void *memblock_alloc_raw(phys_addr_t size,
 					       phys_addr_t align)
 {
diff --git a/init/main.c b/init/main.c
index 893cb77aef22..2a1757826397 100644
--- a/init/main.c
+++ b/init/main.c
@@ -640,15 +640,11 @@ static void __init setup_command_line(char *command_line)
 
 	len = xlen + strlen(boot_command_line) + ilen + 1;
 
-	saved_command_line = memblock_alloc(len, SMP_CACHE_BYTES);
-	if (!saved_command_line)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, len);
+	saved_command_line = memblock_alloc_or_panic(len, SMP_CACHE_BYTES);
 
 	len = xlen + strlen(command_line) + 1;
 
-	static_command_line = memblock_alloc(len, SMP_CACHE_BYTES);
-	if (!static_command_line)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, len);
+	static_command_line = memblock_alloc_or_panic(len, SMP_CACHE_BYTES);
 
 	if (xlen) {
 		/*
@@ -1146,16 +1142,10 @@ static int __init initcall_blacklist(char *str)
 		str_entry = strsep(&str, ",");
 		if (str_entry) {
 			pr_debug("blacklisting initcall %s\n", str_entry);
-			entry = memblock_alloc(sizeof(*entry),
+			entry = memblock_alloc_or_panic(sizeof(*entry),
 					       SMP_CACHE_BYTES);
-			if (!entry)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, sizeof(*entry));
-			entry->buf = memblock_alloc(strlen(str_entry) + 1,
+			entry->buf = memblock_alloc_or_panic(strlen(str_entry) + 1,
 						    SMP_CACHE_BYTES);
-			if (!entry->buf)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, strlen(str_entry) + 1);
 			strcpy(entry->buf, str_entry);
 			list_add(&entry->next, &blacklisted_initcalls);
 		}
diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
index 30894d8f0a78..c9fb559a6399 100644
--- a/kernel/power/snapshot.c
+++ b/kernel/power/snapshot.c
@@ -1011,11 +1011,8 @@ void __init register_nosave_region(unsigned long start_pfn, unsigned long end_pf
 		}
 	}
 	/* This allocation cannot fail */
-	region = memblock_alloc(sizeof(struct nosave_region),
+	region = memblock_alloc_or_panic(sizeof(struct nosave_region),
 				SMP_CACHE_BYTES);
-	if (!region)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct nosave_region));
 	region->start_pfn = start_pfn;
 	region->end_pfn = end_pfn;
 	list_add_tail(®ion->list, &nosave_regions);
diff --git a/lib/cpumask.c b/lib/cpumask.c
index e77ee9d46f71..57274ba8b6d9 100644
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@ -83,10 +83,7 @@ EXPORT_SYMBOL(alloc_cpumask_var_node);
  */
 void __init alloc_bootmem_cpumask_var(cpumask_var_t *mask)
 {
-	*mask = memblock_alloc(cpumask_size(), SMP_CACHE_BYTES);
-	if (!*mask)
-		panic("%s: Failed to allocate %u bytes\n", __func__,
-		      cpumask_size());
+	*mask = memblock_alloc_or_panic(cpumask_size(), SMP_CACHE_BYTES);
 }
 
 /**
diff --git a/mm/kmsan/shadow.c b/mm/kmsan/shadow.c
index 9c58f081d84f..1bb505a08415 100644
--- a/mm/kmsan/shadow.c
+++ b/mm/kmsan/shadow.c
@@ -280,12 +280,8 @@ void __init kmsan_init_alloc_meta_for_range(void *start, void *end)
 
 	start = (void *)PAGE_ALIGN_DOWN((u64)start);
 	size = PAGE_ALIGN((u64)end - (u64)start);
-	shadow = memblock_alloc(size, PAGE_SIZE);
-	origin = memblock_alloc(size, PAGE_SIZE);
-
-	if (!shadow || !origin)
-		panic("%s: Failed to allocate metadata memory for early boot range of size %llu",
-		      __func__, size);
+	shadow = memblock_alloc_or_panic(size, PAGE_SIZE);
+	origin = memblock_alloc_or_panic(size, PAGE_SIZE);
 
 	for (u64 addr = 0; addr < size; addr += PAGE_SIZE) {
 		page = virt_to_page_or_null((char *)start + addr);
diff --git a/mm/numa.c b/mm/numa.c
index e2eec07707d1..f1787d7713a6 100644
--- a/mm/numa.c
+++ b/mm/numa.c
@@ -37,13 +37,7 @@ void __init alloc_node_data(int nid)
 void __init alloc_offline_node_data(int nid)
 {
 	pg_data_t *pgdat;
-
-	pgdat = memblock_alloc(sizeof(*pgdat), SMP_CACHE_BYTES);
-	if (!pgdat)
-		panic("Cannot allocate %zuB for node %d.\n",
-		      sizeof(*pgdat), nid);
-
-	node_data[nid] = pgdat;
+	node_data[nid] = memblock_alloc_or_panic(sizeof(*pgdat), SMP_CACHE_BYTES);
 }
 
 /* Stub functions: */
diff --git a/mm/percpu.c b/mm/percpu.c
index d8dd31a2e407..ac61e3fc5f15 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1359,10 +1359,7 @@ static struct pcpu_chunk * __init pcpu_alloc_first_chunk(unsigned long tmp_addr,
 	/* allocate chunk */
 	alloc_size = struct_size(chunk, populated,
 				 BITS_TO_LONGS(region_size >> PAGE_SHIFT));
-	chunk = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	INIT_LIST_HEAD(&chunk->list);
 
@@ -1374,24 +1371,14 @@ static struct pcpu_chunk * __init pcpu_alloc_first_chunk(unsigned long tmp_addr,
 	region_bits = pcpu_chunk_map_bits(chunk);
 
 	alloc_size = BITS_TO_LONGS(region_bits) * sizeof(chunk->alloc_map[0]);
-	chunk->alloc_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->alloc_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk->alloc_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size =
 		BITS_TO_LONGS(region_bits + 1) * sizeof(chunk->bound_map[0]);
-	chunk->bound_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->bound_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk->bound_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = pcpu_chunk_nr_blocks(chunk) * sizeof(chunk->md_blocks[0]);
-	chunk->md_blocks = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->md_blocks)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
-
+	chunk->md_blocks = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 #ifdef NEED_PCPUOBJ_EXT
 	/* first chunk is free to use */
 	chunk->obj_exts = NULL;
@@ -2595,28 +2582,16 @@ void __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
 
 	/* process group information and build config tables accordingly */
 	alloc_size = ai->nr_groups * sizeof(group_offsets[0]);
-	group_offsets = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!group_offsets)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	group_offsets = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = ai->nr_groups * sizeof(group_sizes[0]);
-	group_sizes = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!group_sizes)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	group_sizes = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = nr_cpu_ids * sizeof(unit_map[0]);
-	unit_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!unit_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	unit_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = nr_cpu_ids * sizeof(unit_off[0]);
-	unit_off = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!unit_off)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	unit_off = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	for (cpu = 0; cpu < nr_cpu_ids; cpu++)
 		unit_map[cpu] = UINT_MAX;
@@ -2685,12 +2660,9 @@ void __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
 	pcpu_free_slot = pcpu_sidelined_slot + 1;
 	pcpu_to_depopulate_slot = pcpu_free_slot + 1;
 	pcpu_nr_slots = pcpu_to_depopulate_slot + 1;
-	pcpu_chunk_lists = memblock_alloc(pcpu_nr_slots *
+	pcpu_chunk_lists = memblock_alloc_or_panic(pcpu_nr_slots *
 					  sizeof(pcpu_chunk_lists[0]),
 					  SMP_CACHE_BYTES);
-	if (!pcpu_chunk_lists)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      pcpu_nr_slots * sizeof(pcpu_chunk_lists[0]));
 
 	for (i = 0; i < pcpu_nr_slots; i++)
 		INIT_LIST_HEAD(&pcpu_chunk_lists[i]);
@@ -3155,25 +3127,19 @@ void __init __weak pcpu_populate_pte(unsigned long addr)
 	pmd_t *pmd;
 
 	if (pgd_none(*pgd)) {
-		p4d = memblock_alloc(P4D_TABLE_SIZE, P4D_TABLE_SIZE);
-		if (!p4d)
-			goto err_alloc;
+		p4d = memblock_alloc_or_panic(P4D_TABLE_SIZE, P4D_TABLE_SIZE);
 		pgd_populate(&init_mm, pgd, p4d);
 	}
 
 	p4d = p4d_offset(pgd, addr);
 	if (p4d_none(*p4d)) {
-		pud = memblock_alloc(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
-		if (!pud)
-			goto err_alloc;
+		pud = memblock_alloc_or_panic(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
 		p4d_populate(&init_mm, p4d, pud);
 	}
 
 	pud = pud_offset(p4d, addr);
 	if (pud_none(*pud)) {
-		pmd = memblock_alloc(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
-		if (!pmd)
-			goto err_alloc;
+		pmd = memblock_alloc_or_panic(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 	}
 
@@ -3181,16 +3147,11 @@ void __init __weak pcpu_populate_pte(unsigned long addr)
 	if (!pmd_present(*pmd)) {
 		pte_t *new;
 
-		new = memblock_alloc(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
-		if (!new)
-			goto err_alloc;
+		new = memblock_alloc_or_panic(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, new);
 	}
 
 	return;
-
-err_alloc:
-	panic("%s: Failed to allocate memory\n", __func__);
 }
 
 /**
@@ -3237,10 +3198,7 @@ int __init pcpu_page_first_chunk(size_t reserved_size, pcpu_fc_cpu_to_node_fn_t
 	/* unaligned allocations can't be freed, round up to page size */
 	pages_size = PFN_ALIGN(unit_pages * num_possible_cpus() *
 			       sizeof(pages[0]));
-	pages = memblock_alloc(pages_size, SMP_CACHE_BYTES);
-	if (!pages)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      pages_size);
+	pages = memblock_alloc_or_panic(pages_size, SMP_CACHE_BYTES);
 
 	/* allocate pages */
 	j = 0;
diff --git a/mm/sparse.c b/mm/sparse.c
index 13b6624d3562..133b033d0cba 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -257,10 +257,7 @@ static void __init memblocks_present(void)
 
 		size = sizeof(struct mem_section *) * NR_SECTION_ROOTS;
 		align = 1 << (INTERNODE_CACHE_SHIFT);
-		mem_section = memblock_alloc(size, align);
-		if (!mem_section)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, size, align);
+		mem_section = memblock_alloc_or_panic(size, align);
 	}
 #endif
 
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Sat Dec 21 10:45:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Dec 2024 10:45:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.861762.1274083 (Exim 4.92)
	(envelope-from )
	id 1tOwzC-0007gu-Ub; Sat, 21 Dec 2024 10:45:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 861762.1274083; Sat, 21 Dec 2024 10:45:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tOwzC-0007gm-O9; Sat, 21 Dec 2024 10:45:30 +0000
Received: by outflank-mailman (input) for mailman id 861762;
 Fri, 20 Dec 2024 09:27: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 1tOZHo-0002rl-G1
 for xen-devel@lists.xenproject.org; Fri, 20 Dec 2024 09:27:08 +0000
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com
 [2607:f8b0:4864:20::435])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 921f86fb-beb4-11ef-99a3-01e77a169b0f;
 Fri, 20 Dec 2024 10:27:03 +0100 (CET)
Received: by mail-pf1-x435.google.com with SMTP id
 d2e1a72fcca58-728e78c4d7bso1309507b3a.0
 for ; Fri, 20 Dec 2024 01:27:03 -0800 (PST)
Received: from localhost.localdomain ([36.110.106.149])
 by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-842b85f00f9sm2476345a12.43.2024.12.20.01.26.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 20 Dec 2024 01:27: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: 921f86fb-beb4-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734686822; x=1735291622; 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=fv95yFRm1pZ1t8bjewPUXwQNxqgkbbAOERHyHPMPyNk=;
        b=WKv2WnXbSoDEfW0hg9QgVwJdUK9kjJ5ZvOoVCtKEDNRMOG+ZMmbN5N79dTGtP/WyLz
         QAzSADYYaJia4PTjriqOysHRFDTKjCTQLGgDC0igetmGqtMrCPDhb4w8LSaJitzO4opq
         eXJi0eyPWUn3GKzpL5lfM5x1/uo7B+3cxb46afpyJcD8bH7K0lHeBRLORhdDOBavwogT
         lMDBCPZaU1nzK7BLjLdxdRok2HVyKoN41S9hLQkV8gDXyJ4kTxoRJbHOuzfHPHLhEMRG
         Ih6JCCXbEYftFlhkFzx6Nz/8GiQP27Iz9dJ3VSMnAH2efIBUs+Hv3d92khAhiCMtQ0eD
         Hlzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734686822; x=1735291622;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=fv95yFRm1pZ1t8bjewPUXwQNxqgkbbAOERHyHPMPyNk=;
        b=wMOZWu7t6elfDD4X+J5m7IxiWv1Oi7W/8s5DX1VZ5b6NC5FewTU2CNwb+2940E8Cnc
         Lmse6jNG41BzqfQBQPwBkEVVSMkYj13sEaWO/JQ6/3+Uod/OlrHr8Zskr8IR7PjE7wqs
         w4KwwLflDr8J2emYbK8LTVXj0f2XfBal6zbmtHy81FzTTRaxdc0TCvjgqnWw/q7xb1n6
         v65ABO9etogpvYrqulEGAjy/h27/O/tPE+0qnZ7MGbnH+NuVhtTcdxXBeGaYzTu05ZTD
         OjcMKJW5HUn7qSzbavzgwmf6GfBZtFrqBBg4I2DCTnSzwY7o67UaNgqg/yB2a8488QsU
         oexg==
X-Forwarded-Encrypted: i=1; AJvYcCXBhTRZqV+Nig8V1fQmZXvOZysRGP2g59wR7sf+5gNsmY5LheC+xfGH+Sdtw1YGryOyepWQG3M+Z48=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzHr2m+LA90DiIT1X9K99qBTzeESQeP4SI9hJrM7STRNXC2wQJb
	Dy7pN8Z1+APj9+y90t/eM01stNP0xLpkZoN9zSCpy2+C6d4z1coN
X-Gm-Gg: ASbGnct2HfhA0SHSDjuCqug0gPUE6u6pZ8ikQNRvZ1lZr3EdVPrwTbQflFePPFRFLWL
	+qd/JwyEI5Es9Owrn6kPHiwsxagYlx9uGJCBt04trI8OkA17lxIQ+InNoYusjgx5Udw+ozxxNIy
	uxYqj0KNYBCEgokRY30sNLLGXdUhOPOirefxErgntdt6IGv3rEb1qMadSVqOCQLP47/gEZeJWjT
	/De8pUKD9mBxKLMdO2V87kaADGCyeP7RBiX7wY8R+xVdwEUL7l5UtY6sUKIejksfz8vv1Lt0KtS
	2u0A
X-Google-Smtp-Source: AGHT+IH/qyoq6gkcTnpo7ohRXihVc7FAZQUsZPTG9leiexZnchzzE6SREdKqSmsRVszfucZ7QcKYTQ==
X-Received: by 2002:a05:6a00:820c:b0:725:ce39:4516 with SMTP id d2e1a72fcca58-72aa9a3edc8mr8431954b3a.7.1734686821716;
        Fri, 20 Dec 2024 01:27:01 -0800 (PST)
From: Guo Weikang 
To: Mike Rapoport ,
	Andrew Morton ,
	Dennis Zhou ,
	Tejun Heo ,
	Christoph Lameter ,
	Thomas Bogendoerfer ,
	Sam Creasey ,
	Geert Uytterhoeven ,
	Huacai Chen ,
	Will Deacon ,
	Catalin Marinas ,
	Guo Weikang 
Cc: Oreoluwa Babatunde ,
	rafael.j.wysocki@intel.com,
	Palmer Dabbelt ,
	Hanjun Guo ,
	Easwar Hariharan ,
	Johannes Berg ,
	Ingo Molnar ,
	Dave Hansen ,
	Christian Brauner ,
	KP Singh ,
	Richard Henderson ,
	Matt Turner ,
	Russell King ,
	WANG Xuerui ,
	Michael Ellerman ,
	Jonas Bonn ,
	Stefan Kristiansson ,
	Stafford Horne ,
	Helge Deller ,
	Nicholas Piggin ,
	Christophe Leroy ,
	Naveen N Rao ,
	Madhavan Srinivasan ,
	Geoff Levand ,
	Paul Walmsley ,
	Palmer Dabbelt ,
	Albert Ou ,
	Andrey Ryabinin ,
	Alexander Potapenko ,
	Andrey Konovalov ,
	Dmitry Vyukov ,
	Vincenzo Frascino ,
	Heiko Carstens ,
	Vasily Gorbik ,
	Alexander Gordeev ,
	Christian Borntraeger ,
	Sven Schnelle ,
	Yoshinori Sato ,
	Rich Felker ,
	John Paul Adrian Glaubitz ,
	Andreas Larsson ,
	Richard Weinberger ,
	Anton Ivanov ,
	Johannes Berg ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	x86@kernel.org,
	Len Brown ,
	Juergen Gross ,
	Boris Ostrovsky ,
	Chris Zankel ,
	Max Filippov ,
	Tero Kristo ,
	Michael Turquette ,
	Stephen Boyd ,
	Rob Herring ,
	Saravana Kannan ,
	Pavel Machek ,
	Yury Norov ,
	Rasmus Villemoes ,
	Marco Elver ,
	Al Viro ,
	Arnd Bergmann ,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-m68k@lists.linux-m68k.org,
	linux-mips@vger.kernel.org,
	linux-openrisc@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org,
	kasan-dev@googlegroups.com,
	linux-s390@vger.kernel.org,
	linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org,
	linux-um@lists.infradead.org,
	linux-acpi@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-omap@vger.kernel.org,
	linux-clk@vger.kernel.org,
	devicetree@vger.kernel.org,
	linux-mm@kvack.org,
	linux-pm@vger.kernel.org
Subject: [PATCH] mm/memblock: Add memblock_alloc_or_panic interface
Date: Fri, 20 Dec 2024 17:26:38 +0800
Message-Id: <20241220092638.2611414-1-guoweikang.kernel@gmail.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Before SLUB initialization, various subsystems used memblock_alloc to
allocate memory. In most cases, when memory allocation fails, an immediate
panic is required. To simplify this behavior and reduce repetitive checks,
introduce `memblock_alloc_or_panic`. This function ensures that memory
allocation failures result in a panic automatically, improving code
readability and consistency across subsystems that require this behavior.

Signed-off-by: Guo Weikang 
---
 arch/alpha/kernel/core_cia.c            |  5 +-
 arch/alpha/kernel/core_marvel.c         | 10 +---
 arch/alpha/kernel/pci.c                 | 13 +----
 arch/alpha/kernel/pci_iommu.c           | 10 +---
 arch/arm/kernel/setup.c                 | 10 +---
 arch/arm/mm/mmu.c                       | 17 ++----
 arch/arm/mm/nommu.c                     |  5 +-
 arch/arm64/kernel/setup.c               |  4 +-
 arch/loongarch/kernel/setup.c           |  2 +-
 arch/loongarch/mm/init.c                | 13 ++---
 arch/m68k/mm/init.c                     |  5 +-
 arch/m68k/mm/mcfmmu.c                   | 10 +---
 arch/m68k/mm/motorola.c                 |  5 +-
 arch/m68k/mm/sun3mmu.c                  | 10 +---
 arch/m68k/sun3/sun3dvma.c               |  6 +--
 arch/mips/kernel/setup.c                |  5 +-
 arch/openrisc/mm/ioremap.c              |  5 +-
 arch/parisc/mm/init.c                   | 20 ++-----
 arch/powerpc/kernel/dt_cpu_ftrs.c       | 10 ++--
 arch/powerpc/kernel/pci_32.c            |  5 +-
 arch/powerpc/kernel/setup-common.c      |  5 +-
 arch/powerpc/kernel/setup_32.c          |  8 +--
 arch/powerpc/mm/book3s32/mmu.c          |  5 +-
 arch/powerpc/mm/book3s64/pgtable.c      |  6 +--
 arch/powerpc/mm/kasan/init_book3e_64.c  |  8 +--
 arch/powerpc/mm/kasan/init_book3s_64.c  |  2 +-
 arch/powerpc/mm/nohash/mmu_context.c    | 16 ++----
 arch/powerpc/mm/pgtable_32.c            |  7 +--
 arch/powerpc/platforms/powermac/nvram.c |  5 +-
 arch/powerpc/platforms/powernv/opal.c   |  5 +-
 arch/powerpc/platforms/ps3/setup.c      |  5 +-
 arch/powerpc/sysdev/msi_bitmap.c        |  5 +-
 arch/riscv/kernel/setup.c               |  4 +-
 arch/riscv/mm/kasan_init.c              | 14 ++---
 arch/s390/kernel/numa.c                 |  5 +-
 arch/s390/kernel/setup.c                | 20 ++-----
 arch/s390/kernel/smp.c                  |  9 ++--
 arch/s390/kernel/topology.c             | 10 +---
 arch/sh/mm/init.c                       | 10 +---
 arch/sparc/kernel/prom_32.c             |  4 +-
 arch/sparc/mm/srmmu.c                   | 14 ++---
 arch/um/drivers/net_kern.c              |  5 +-
 arch/um/drivers/vector_kern.c           |  5 +-
 arch/um/kernel/load_file.c              |  4 +-
 arch/x86/coco/sev/core.c                |  4 +-
 arch/x86/kernel/acpi/boot.c             |  5 +-
 arch/x86/kernel/apic/io_apic.c          |  9 +---
 arch/x86/kernel/e820.c                  |  5 +-
 arch/x86/platform/olpc/olpc_dt.c        |  6 +--
 arch/x86/xen/p2m.c                      |  8 +--
 arch/xtensa/mm/kasan_init.c             |  6 +--
 drivers/clk/ti/clk.c                    |  5 +-
 drivers/macintosh/smu.c                 |  6 +--
 drivers/of/fdt.c                        |  8 +--
 drivers/of/unittest.c                   |  8 +--
 include/linux/memblock.h                | 13 +++++
 init/main.c                             | 18 ++-----
 kernel/power/snapshot.c                 |  5 +-
 lib/cpumask.c                           |  5 +-
 mm/kmsan/shadow.c                       |  8 +--
 mm/numa.c                               |  8 +--
 mm/percpu.c                             | 70 +++++--------------------
 mm/sparse.c                             |  5 +-
 63 files changed, 130 insertions(+), 423 deletions(-)

diff --git a/arch/alpha/kernel/core_cia.c b/arch/alpha/kernel/core_cia.c
index ca3d9c732b61..6e577228e175 100644
--- a/arch/alpha/kernel/core_cia.c
+++ b/arch/alpha/kernel/core_cia.c
@@ -331,10 +331,7 @@ cia_prepare_tbia_workaround(int window)
 	long i;
 
 	/* Use minimal 1K map. */
-	ppte = memblock_alloc(CIA_BROKEN_TBIA_SIZE, 32768);
-	if (!ppte)
-		panic("%s: Failed to allocate %u bytes align=0x%x\n",
-		      __func__, CIA_BROKEN_TBIA_SIZE, 32768);
+	ppte = memblock_alloc_or_panic(CIA_BROKEN_TBIA_SIZE, 32768);
 	pte = (virt_to_phys(ppte) >> (PAGE_SHIFT - 1)) | 1;
 
 	for (i = 0; i < CIA_BROKEN_TBIA_SIZE / sizeof(unsigned long); ++i)
diff --git a/arch/alpha/kernel/core_marvel.c b/arch/alpha/kernel/core_marvel.c
index b22248044bf0..b1bfbd11980d 100644
--- a/arch/alpha/kernel/core_marvel.c
+++ b/arch/alpha/kernel/core_marvel.c
@@ -81,10 +81,7 @@ mk_resource_name(int pe, int port, char *str)
 	char *name;
 	
 	sprintf(tmp, "PCI %s PE %d PORT %d", str, pe, port);
-	name = memblock_alloc(strlen(tmp) + 1, SMP_CACHE_BYTES);
-	if (!name)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      strlen(tmp) + 1);
+	name = memblock_alloc_or_panic(strlen(tmp) + 1, SMP_CACHE_BYTES);
 	strcpy(name, tmp);
 
 	return name;
@@ -119,10 +116,7 @@ alloc_io7(unsigned int pe)
 		return NULL;
 	}
 
-	io7 = memblock_alloc(sizeof(*io7), SMP_CACHE_BYTES);
-	if (!io7)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*io7));
+	io7 = memblock_alloc_or_panic(sizeof(*io7), SMP_CACHE_BYTES);
 	io7->pe = pe;
 	raw_spin_lock_init(&io7->irq_lock);
 
diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
index 4458eb7f44f0..8e9b4ac86b7e 100644
--- a/arch/alpha/kernel/pci.c
+++ b/arch/alpha/kernel/pci.c
@@ -391,10 +391,7 @@ alloc_pci_controller(void)
 {
 	struct pci_controller *hose;
 
-	hose = memblock_alloc(sizeof(*hose), SMP_CACHE_BYTES);
-	if (!hose)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*hose));
+	hose = memblock_alloc_or_panic(sizeof(*hose), SMP_CACHE_BYTES);
 
 	*hose_tail = hose;
 	hose_tail = &hose->next;
@@ -405,13 +402,7 @@ alloc_pci_controller(void)
 struct resource * __init
 alloc_resource(void)
 {
-	void *ptr = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct resource));
-
-	return ptr;
+	return memblock_alloc_or_panic(sizeof(struct resource), SMP_CACHE_BYTES);
 }
 
 
diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index 7fcf3e9b7103..681f56089d9c 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -71,14 +71,8 @@ iommu_arena_new_node(int nid, struct pci_controller *hose, dma_addr_t base,
 	if (align < mem_size)
 		align = mem_size;
 
-	arena = memblock_alloc(sizeof(*arena), SMP_CACHE_BYTES);
-	if (!arena)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*arena));
-	arena->ptes = memblock_alloc(mem_size, align);
-	if (!arena->ptes)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, mem_size, align);
+	arena = memblock_alloc_or_panic(sizeof(*arena), SMP_CACHE_BYTES);
+	arena->ptes = memblock_alloc_or_panic(mem_size, align);
 
 	spin_lock_init(&arena->lock);
 	arena->hose = hose;
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index e6a857bf0ce6..a41c93988d2c 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -880,10 +880,7 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 		 */
 		boot_alias_start = phys_to_idmap(start);
 		if (arm_has_idmap_alias() && boot_alias_start != IDMAP_INVALID_ADDR) {
-			res = memblock_alloc(sizeof(*res), SMP_CACHE_BYTES);
-			if (!res)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, sizeof(*res));
+			res = memblock_alloc_or_panic(sizeof(*res), SMP_CACHE_BYTES);
 			res->name = "System RAM (boot alias)";
 			res->start = boot_alias_start;
 			res->end = phys_to_idmap(res_end);
@@ -891,10 +888,7 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 			request_resource(&iomem_resource, res);
 		}
 
-		res = memblock_alloc(sizeof(*res), SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      sizeof(*res));
+		res = memblock_alloc_or_panic(sizeof(*res), SMP_CACHE_BYTES);
 		res->name  = "System RAM";
 		res->start = start;
 		res->end = res_end;
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index f5b7a16c5803..f02f872ea8a9 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -726,13 +726,8 @@ EXPORT_SYMBOL(phys_mem_access_prot);
 
 static void __init *early_alloc(unsigned long sz)
 {
-	void *ptr = memblock_alloc(sz, sz);
+	return memblock_alloc_or_panic(sz, sz);
 
-	if (!ptr)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, sz, sz);
-
-	return ptr;
 }
 
 static void *__init late_alloc(unsigned long sz)
@@ -1027,10 +1022,7 @@ void __init iotable_init(struct map_desc *io_desc, int nr)
 	if (!nr)
 		return;
 
-	svm = memblock_alloc(sizeof(*svm) * nr, __alignof__(*svm));
-	if (!svm)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, sizeof(*svm) * nr, __alignof__(*svm));
+	svm = memblock_alloc_or_panic(sizeof(*svm) * nr, __alignof__(*svm));
 
 	for (md = io_desc; nr; md++, nr--) {
 		create_mapping(md);
@@ -1052,10 +1044,7 @@ void __init vm_reserve_area_early(unsigned long addr, unsigned long size,
 	struct vm_struct *vm;
 	struct static_vm *svm;
 
-	svm = memblock_alloc(sizeof(*svm), __alignof__(*svm));
-	if (!svm)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, sizeof(*svm), __alignof__(*svm));
+	svm = memblock_alloc_or_panic(sizeof(*svm), __alignof__(*svm));
 
 	vm = &svm->vm;
 	vm->addr = (void *)addr;
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index c415f3859b20..1a8f6914ee59 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -162,10 +162,7 @@ void __init paging_init(const struct machine_desc *mdesc)
 	mpu_setup();
 
 	/* allocate the zero page. */
-	zero_page = (void *)memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	zero_page = (void *)memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	bootmem_init();
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 4f613e8e0745..85104587f849 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -223,9 +223,7 @@ static void __init request_standard_resources(void)
 
 	num_standard_resources = memblock.memory.cnt;
 	res_size = num_standard_resources * sizeof(*standard_resources);
-	standard_resources = memblock_alloc(res_size, SMP_CACHE_BYTES);
-	if (!standard_resources)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, res_size);
+	standard_resources = memblock_alloc_or_panic(res_size, SMP_CACHE_BYTES);
 
 	for_each_mem_region(region) {
 		res = &standard_resources[i++];
diff --git a/arch/loongarch/kernel/setup.c b/arch/loongarch/kernel/setup.c
index 56934fe58170..edcfdfcad7d2 100644
--- a/arch/loongarch/kernel/setup.c
+++ b/arch/loongarch/kernel/setup.c
@@ -431,7 +431,7 @@ static void __init resource_init(void)
 
 	num_standard_resources = memblock.memory.cnt;
 	res_size = num_standard_resources * sizeof(*standard_resources);
-	standard_resources = memblock_alloc(res_size, SMP_CACHE_BYTES);
+	standard_resources = memblock_alloc_or_panic(res_size, SMP_CACHE_BYTES);
 
 	for_each_mem_region(region) {
 		res = &standard_resources[i++];
diff --git a/arch/loongarch/mm/init.c b/arch/loongarch/mm/init.c
index 188b52bbb254..ca5aa5f46a9f 100644
--- a/arch/loongarch/mm/init.c
+++ b/arch/loongarch/mm/init.c
@@ -174,9 +174,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 	pmd_t *pmd;
 
 	if (p4d_none(p4dp_get(p4d))) {
-		pud = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pud)
-			panic("%s: Failed to allocate memory\n", __func__);
+		pud = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		p4d_populate(&init_mm, p4d, pud);
 #ifndef __PAGETABLE_PUD_FOLDED
 		pud_init(pud);
@@ -185,9 +183,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 
 	pud = pud_offset(p4d, addr);
 	if (pud_none(pudp_get(pud))) {
-		pmd = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pmd)
-			panic("%s: Failed to allocate memory\n", __func__);
+		pmd = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 #ifndef __PAGETABLE_PMD_FOLDED
 		pmd_init(pmd);
@@ -198,10 +194,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 	if (!pmd_present(pmdp_get(pmd))) {
 		pte_t *pte;
 
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate memory\n", __func__);
-
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, pte);
 		kernel_pte_init(pte);
 	}
diff --git a/arch/m68k/mm/init.c b/arch/m68k/mm/init.c
index 1b47bec15832..8b11d0d545aa 100644
--- a/arch/m68k/mm/init.c
+++ b/arch/m68k/mm/init.c
@@ -68,10 +68,7 @@ void __init paging_init(void)
 
 	high_memory = (void *) end_mem;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	max_zone_pfn[ZONE_DMA] = end_mem >> PAGE_SHIFT;
 	free_area_init(max_zone_pfn);
 }
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index 9a6fa342e872..19a75029036c 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -42,20 +42,14 @@ void __init paging_init(void)
 	unsigned long max_zone_pfn[MAX_NR_ZONES] = { 0 };
 	int i;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	pg_dir = swapper_pg_dir;
 	memset(swapper_pg_dir, 0, sizeof(swapper_pg_dir));
 
 	size = num_pages * sizeof(pte_t);
 	size = (size + PAGE_SIZE) & ~(PAGE_SIZE-1);
-	next_pgtable = (unsigned long) memblock_alloc(size, PAGE_SIZE);
-	if (!next_pgtable)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, PAGE_SIZE);
+	next_pgtable = (unsigned long) memblock_alloc_or_panic(size, PAGE_SIZE);
 
 	pg_dir += PAGE_OFFSET >> PGDIR_SHIFT;
 
diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
index c1761d309fc6..795dd1f2b24f 100644
--- a/arch/m68k/mm/motorola.c
+++ b/arch/m68k/mm/motorola.c
@@ -491,10 +491,7 @@ void __init paging_init(void)
 	 * initialize the bad page table and bad page to point
 	 * to a couple of allocated pages
 	 */
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	/*
 	 * Set up SFC/DFC registers
diff --git a/arch/m68k/mm/sun3mmu.c b/arch/m68k/mm/sun3mmu.c
index 494739c1783e..1ecf6bdd08bf 100644
--- a/arch/m68k/mm/sun3mmu.c
+++ b/arch/m68k/mm/sun3mmu.c
@@ -44,10 +44,7 @@ void __init paging_init(void)
 	unsigned long max_zone_pfn[MAX_NR_ZONES] = { 0, };
 	unsigned long size;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	address = PAGE_OFFSET;
 	pg_dir = swapper_pg_dir;
@@ -57,10 +54,7 @@ void __init paging_init(void)
 	size = num_pages * sizeof(pte_t);
 	size = (size + PAGE_SIZE) & ~(PAGE_SIZE-1);
 
-	next_pgtable = (unsigned long)memblock_alloc(size, PAGE_SIZE);
-	if (!next_pgtable)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, PAGE_SIZE);
+	next_pgtable = (unsigned long)memblock_alloc_or_panic(size, PAGE_SIZE);
 	bootmem_end = (next_pgtable + size + PAGE_SIZE) & PAGE_MASK;
 
 	/* Map whole memory from PAGE_OFFSET (0x0E000000) */
diff --git a/arch/m68k/sun3/sun3dvma.c b/arch/m68k/sun3/sun3dvma.c
index 6ebf52740ad7..225fc735e466 100644
--- a/arch/m68k/sun3/sun3dvma.c
+++ b/arch/m68k/sun3/sun3dvma.c
@@ -252,12 +252,8 @@ void __init dvma_init(void)
 
 	list_add(&(hole->list), &hole_list);
 
-	iommu_use = memblock_alloc(IOMMU_TOTAL_ENTRIES * sizeof(unsigned long),
+	iommu_use = memblock_alloc_or_panic(IOMMU_TOTAL_ENTRIES * sizeof(unsigned long),
 				   SMP_CACHE_BYTES);
-	if (!iommu_use)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      IOMMU_TOTAL_ENTRIES * sizeof(unsigned long));
-
 	dvma_unmap_iommu(DVMA_START, DVMA_SIZE);
 
 	sun3_dvma_init();
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 12a1a4ffb602..fbfe0771317e 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -704,10 +704,7 @@ static void __init resource_init(void)
 	for_each_mem_range(i, &start, &end) {
 		struct resource *res;
 
-		res = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      sizeof(struct resource));
+		res = memblock_alloc_or_panic(sizeof(struct resource), SMP_CACHE_BYTES);
 
 		res->start = start;
 		/*
diff --git a/arch/openrisc/mm/ioremap.c b/arch/openrisc/mm/ioremap.c
index f59ea4c10b0f..8e63e86251ca 100644
--- a/arch/openrisc/mm/ioremap.c
+++ b/arch/openrisc/mm/ioremap.c
@@ -38,10 +38,7 @@ pte_t __ref *pte_alloc_one_kernel(struct mm_struct *mm)
 	if (likely(mem_init_done)) {
 		pte = (pte_t *)get_zeroed_page(GFP_KERNEL);
 	} else {
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	}
 
 	return pte;
diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index 96970fa75e4a..61c0a2477072 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -377,10 +377,8 @@ static void __ref map_pages(unsigned long start_vaddr,
 
 #if CONFIG_PGTABLE_LEVELS == 3
 		if (pud_none(*pud)) {
-			pmd = memblock_alloc(PAGE_SIZE << PMD_TABLE_ORDER,
+			pmd = memblock_alloc_or_panic(PAGE_SIZE << PMD_TABLE_ORDER,
 					     PAGE_SIZE << PMD_TABLE_ORDER);
-			if (!pmd)
-				panic("pmd allocation failed.\n");
 			pud_populate(NULL, pud, pmd);
 		}
 #endif
@@ -388,9 +386,7 @@ static void __ref map_pages(unsigned long start_vaddr,
 		pmd = pmd_offset(pud, vaddr);
 		for (tmp1 = start_pmd; tmp1 < PTRS_PER_PMD; tmp1++, pmd++) {
 			if (pmd_none(*pmd)) {
-				pg_table = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-				if (!pg_table)
-					panic("page table allocation failed\n");
+				pg_table = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 				pmd_populate_kernel(NULL, pmd, pg_table);
 			}
 
@@ -648,9 +644,7 @@ static void __init pagetable_init(void)
 	}
 #endif
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("zero page allocation failed.\n");
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 }
 
@@ -687,19 +681,15 @@ static void __init fixmap_init(void)
 
 #if CONFIG_PGTABLE_LEVELS == 3
 	if (pud_none(*pud)) {
-		pmd = memblock_alloc(PAGE_SIZE << PMD_TABLE_ORDER,
+		pmd = memblock_alloc_or_panic(PAGE_SIZE << PMD_TABLE_ORDER,
 				     PAGE_SIZE << PMD_TABLE_ORDER);
-		if (!pmd)
-			panic("fixmap: pmd allocation failed.\n");
 		pud_populate(NULL, pud, pmd);
 	}
 #endif
 
 	pmd = pmd_offset(pud, addr);
 	do {
-		pte_t *pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("fixmap: pte allocation failed.\n");
+		pte_t *pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 		pmd_populate_kernel(&init_mm, pmd, pte);
 
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 1bee15c013e7..3af6c06af02f 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -1087,12 +1087,10 @@ static int __init dt_cpu_ftrs_scan_callback(unsigned long node, const char
 	/* Count and allocate space for cpu features */
 	of_scan_flat_dt_subnodes(node, count_cpufeatures_subnodes,
 						&nr_dt_cpu_features);
-	dt_cpu_features = memblock_alloc(sizeof(struct dt_cpu_feature) * nr_dt_cpu_features, PAGE_SIZE);
-	if (!dt_cpu_features)
-		panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
-		      __func__,
-		      sizeof(struct dt_cpu_feature) * nr_dt_cpu_features,
-		      PAGE_SIZE);
+	dt_cpu_features =
+		memblock_alloc_or_panic(
+			sizeof(struct dt_cpu_feature) * nr_dt_cpu_features,
+			PAGE_SIZE);
 
 	cpufeatures_setup_start(isa);
 
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index ce0c8623e563..f8a3bd8cfae4 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -213,11 +213,8 @@ pci_create_OF_bus_map(void)
 	struct property* of_prop;
 	struct device_node *dn;
 
-	of_prop = memblock_alloc(sizeof(struct property) + 256,
+	of_prop = memblock_alloc_or_panic(sizeof(struct property) + 256,
 				 SMP_CACHE_BYTES);
-	if (!of_prop)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct property) + 256);
 	dn = of_find_node_by_path("/");
 	if (dn) {
 		memset(of_prop, -1, sizeof(struct property) + 256);
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 6fa179448c33..f3ea1329c566 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -458,11 +458,8 @@ void __init smp_setup_cpu_maps(void)
 
 	DBG("smp_setup_cpu_maps()\n");
 
-	cpu_to_phys_id = memblock_alloc(nr_cpu_ids * sizeof(u32),
+	cpu_to_phys_id = memblock_alloc_or_panic(nr_cpu_ids * sizeof(u32),
 					__alignof__(u32));
-	if (!cpu_to_phys_id)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, nr_cpu_ids * sizeof(u32), __alignof__(u32));
 
 	for_each_node_by_type(dn, "cpu") {
 		const __be32 *intserv;
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 75dbf3e0d9c4..5a1bf501fbe1 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -140,13 +140,7 @@ arch_initcall(ppc_init);
 
 static void *__init alloc_stack(void)
 {
-	void *ptr = memblock_alloc(THREAD_SIZE, THREAD_ALIGN);
-
-	if (!ptr)
-		panic("cannot allocate %d bytes for stack at %pS\n",
-		      THREAD_SIZE, (void *)_RET_IP_);
-
-	return ptr;
+	return memblock_alloc_or_panic(THREAD_SIZE, THREAD_ALIGN);
 }
 
 void __init irqstack_early_init(void)
diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/mmu.c
index 6978344edcb4..be9c4106e22f 100644
--- a/arch/powerpc/mm/book3s32/mmu.c
+++ b/arch/powerpc/mm/book3s32/mmu.c
@@ -377,10 +377,7 @@ void __init MMU_init_hw(void)
 	 * Find some memory for the hash table.
 	 */
 	if ( ppc_md.progress ) ppc_md.progress("hash:find piece", 0x322);
-	Hash = memblock_alloc(Hash_size, Hash_size);
-	if (!Hash)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, Hash_size, Hash_size);
+	Hash = memblock_alloc_or_panic(Hash_size, Hash_size);
 	_SDR1 = __pa(Hash) | SDR1_LOW_BITS;
 
 	pr_info("Total memory = %lldMB; using %ldkB for hash table\n",
diff --git a/arch/powerpc/mm/book3s64/pgtable.c b/arch/powerpc/mm/book3s64/pgtable.c
index 374542528080..0b1f419b7404 100644
--- a/arch/powerpc/mm/book3s64/pgtable.c
+++ b/arch/powerpc/mm/book3s64/pgtable.c
@@ -330,11 +330,7 @@ void __init mmu_partition_table_init(void)
 	unsigned long ptcr;
 
 	/* Initialize the Partition Table with no entries */
-	partition_tb = memblock_alloc(patb_size, patb_size);
-	if (!partition_tb)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, patb_size, patb_size);
-
+	partition_tb = memblock_alloc_or_panic(patb_size, patb_size);
 	ptcr = __pa(partition_tb) | (PATB_SIZE_SHIFT - 12);
 	set_ptcr_when_no_uv(ptcr);
 	powernv_set_nmmu_ptcr(ptcr);
diff --git a/arch/powerpc/mm/kasan/init_book3e_64.c b/arch/powerpc/mm/kasan/init_book3e_64.c
index 43c03b84ff32..60c78aac0f63 100644
--- a/arch/powerpc/mm/kasan/init_book3e_64.c
+++ b/arch/powerpc/mm/kasan/init_book3e_64.c
@@ -40,19 +40,19 @@ static int __init kasan_map_kernel_page(unsigned long ea, unsigned long pa, pgpr
 	pgdp = pgd_offset_k(ea);
 	p4dp = p4d_offset(pgdp, ea);
 	if (kasan_pud_table(*p4dp)) {
-		pudp = memblock_alloc(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
+		pudp = memblock_alloc_or_panic(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
 		memcpy(pudp, kasan_early_shadow_pud, PUD_TABLE_SIZE);
 		p4d_populate(&init_mm, p4dp, pudp);
 	}
 	pudp = pud_offset(p4dp, ea);
 	if (kasan_pmd_table(*pudp)) {
-		pmdp = memblock_alloc(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
+		pmdp = memblock_alloc_or_panic(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
 		memcpy(pmdp, kasan_early_shadow_pmd, PMD_TABLE_SIZE);
 		pud_populate(&init_mm, pudp, pmdp);
 	}
 	pmdp = pmd_offset(pudp, ea);
 	if (kasan_pte_table(*pmdp)) {
-		ptep = memblock_alloc(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
+		ptep = memblock_alloc_or_panic(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
 		memcpy(ptep, kasan_early_shadow_pte, PTE_TABLE_SIZE);
 		pmd_populate_kernel(&init_mm, pmdp, ptep);
 	}
@@ -74,7 +74,7 @@ static void __init kasan_init_phys_region(void *start, void *end)
 	k_start = ALIGN_DOWN((unsigned long)kasan_mem_to_shadow(start), PAGE_SIZE);
 	k_end = ALIGN((unsigned long)kasan_mem_to_shadow(end), PAGE_SIZE);
 
-	va = memblock_alloc(k_end - k_start, PAGE_SIZE);
+	va = memblock_alloc_or_panic(k_end - k_start, PAGE_SIZE);
 	for (k_cur = k_start; k_cur < k_end; k_cur += PAGE_SIZE, va += PAGE_SIZE)
 		kasan_map_kernel_page(k_cur, __pa(va), PAGE_KERNEL);
 }
diff --git a/arch/powerpc/mm/kasan/init_book3s_64.c b/arch/powerpc/mm/kasan/init_book3s_64.c
index 3fb5ce4f48f4..7d959544c077 100644
--- a/arch/powerpc/mm/kasan/init_book3s_64.c
+++ b/arch/powerpc/mm/kasan/init_book3s_64.c
@@ -32,7 +32,7 @@ static void __init kasan_init_phys_region(void *start, void *end)
 	k_start = ALIGN_DOWN((unsigned long)kasan_mem_to_shadow(start), PAGE_SIZE);
 	k_end = ALIGN((unsigned long)kasan_mem_to_shadow(end), PAGE_SIZE);
 
-	va = memblock_alloc(k_end - k_start, PAGE_SIZE);
+	va = memblock_alloc_or_panic(k_end - k_start, PAGE_SIZE);
 	for (k_cur = k_start; k_cur < k_end; k_cur += PAGE_SIZE, va += PAGE_SIZE)
 		map_kernel_page(k_cur, __pa(va), PAGE_KERNEL);
 }
diff --git a/arch/powerpc/mm/nohash/mmu_context.c b/arch/powerpc/mm/nohash/mmu_context.c
index 0b181da40ddb..a1a4e697251a 100644
--- a/arch/powerpc/mm/nohash/mmu_context.c
+++ b/arch/powerpc/mm/nohash/mmu_context.c
@@ -385,21 +385,11 @@ void __init mmu_context_init(void)
 	/*
 	 * Allocate the maps used by context management
 	 */
-	context_map = memblock_alloc(CTX_MAP_SIZE, SMP_CACHE_BYTES);
-	if (!context_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      CTX_MAP_SIZE);
-	context_mm = memblock_alloc(sizeof(void *) * (LAST_CONTEXT + 1),
+	context_map = memblock_alloc_or_panic(CTX_MAP_SIZE, SMP_CACHE_BYTES);
+	context_mm = memblock_alloc_or_panic(sizeof(void *) * (LAST_CONTEXT + 1),
 				    SMP_CACHE_BYTES);
-	if (!context_mm)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(void *) * (LAST_CONTEXT + 1));
 	if (IS_ENABLED(CONFIG_SMP)) {
-		stale_map[boot_cpuid] = memblock_alloc(CTX_MAP_SIZE, SMP_CACHE_BYTES);
-		if (!stale_map[boot_cpuid])
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      CTX_MAP_SIZE);
-
+		stale_map[boot_cpuid] = memblock_alloc_or_panic(CTX_MAP_SIZE, SMP_CACHE_BYTES);
 		cpuhp_setup_state_nocalls(CPUHP_POWERPC_MMU_CTX_PREPARE,
 					  "powerpc/mmu/ctx:prepare",
 					  mmu_ctx_cpu_prepare, mmu_ctx_cpu_dead);
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 787b22206386..15276068f657 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -50,13 +50,8 @@ notrace void __init early_ioremap_init(void)
 
 void __init *early_alloc_pgtable(unsigned long size)
 {
-	void *ptr = memblock_alloc(size, size);
+	return memblock_alloc_or_panic(size, size);
 
-	if (!ptr)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, size);
-
-	return ptr;
 }
 
 pte_t __init *early_pte_alloc_kernel(pmd_t *pmdp, unsigned long va)
diff --git a/arch/powerpc/platforms/powermac/nvram.c b/arch/powerpc/platforms/powermac/nvram.c
index fe2e0249cbc2..a112d26185a0 100644
--- a/arch/powerpc/platforms/powermac/nvram.c
+++ b/arch/powerpc/platforms/powermac/nvram.c
@@ -514,10 +514,7 @@ static int __init core99_nvram_setup(struct device_node *dp, unsigned long addr)
 		printk(KERN_ERR "nvram: no address\n");
 		return -EINVAL;
 	}
-	nvram_image = memblock_alloc(NVRAM_SIZE, SMP_CACHE_BYTES);
-	if (!nvram_image)
-		panic("%s: Failed to allocate %u bytes\n", __func__,
-		      NVRAM_SIZE);
+	nvram_image = memblock_alloc_or_panic(NVRAM_SIZE, SMP_CACHE_BYTES);
 	nvram_data = ioremap(addr, NVRAM_SIZE*2);
 	nvram_naddrs = 1; /* Make sure we get the correct case */
 
diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
index 5d0f35bb917e..09bd93464b4f 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -180,10 +180,7 @@ int __init early_init_dt_scan_recoverable_ranges(unsigned long node,
 	/*
 	 * Allocate a buffer to hold the MC recoverable ranges.
 	 */
-	mc_recoverable_range = memblock_alloc(size, __alignof__(u64));
-	if (!mc_recoverable_range)
-		panic("%s: Failed to allocate %u bytes align=0x%lx\n",
-		      __func__, size, __alignof__(u64));
+	mc_recoverable_range = memblock_alloc_or_panic(size, __alignof__(u64));
 
 	for (i = 0; i < mc_recoverable_range_len; i++) {
 		mc_recoverable_range[i].start_addr =
diff --git a/arch/powerpc/platforms/ps3/setup.c b/arch/powerpc/platforms/ps3/setup.c
index 5144f11359f7..150c09b58ae8 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -115,10 +115,7 @@ static void __init prealloc(struct ps3_prealloc *p)
 	if (!p->size)
 		return;
 
-	p->address = memblock_alloc(p->size, p->align);
-	if (!p->address)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, p->size, p->align);
+	p->address = memblock_alloc_or_panic(p->size, p->align);
 
 	printk(KERN_INFO "%s: %lu bytes at %p\n", p->name, p->size,
 	       p->address);
diff --git a/arch/powerpc/sysdev/msi_bitmap.c b/arch/powerpc/sysdev/msi_bitmap.c
index 0b6e37f3ffb8..456a4f64ae0a 100644
--- a/arch/powerpc/sysdev/msi_bitmap.c
+++ b/arch/powerpc/sysdev/msi_bitmap.c
@@ -124,10 +124,7 @@ int __ref msi_bitmap_alloc(struct msi_bitmap *bmp, unsigned int irq_count,
 	if (bmp->bitmap_from_slab)
 		bmp->bitmap = kzalloc(size, GFP_KERNEL);
 	else {
-		bmp->bitmap = memblock_alloc(size, SMP_CACHE_BYTES);
-		if (!bmp->bitmap)
-			panic("%s: Failed to allocate %u bytes\n", __func__,
-			      size);
+		bmp->bitmap = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 		/* the bitmap won't be freed from memblock allocator */
 		kmemleak_not_leak(bmp->bitmap);
 	}
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 45010e71df86..f1793630fc51 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -147,9 +147,7 @@ static void __init init_resources(void)
 	res_idx = num_resources - 1;
 
 	mem_res_sz = num_resources * sizeof(*mem_res);
-	mem_res = memblock_alloc(mem_res_sz, SMP_CACHE_BYTES);
-	if (!mem_res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, mem_res_sz);
+	mem_res = memblock_alloc_or_panic(mem_res_sz, SMP_CACHE_BYTES);
 
 	/*
 	 * Start by adding the reserved regions, if they overlap
diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index c301c8d291d2..41c635d6aca4 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -32,7 +32,7 @@ static void __init kasan_populate_pte(pmd_t *pmd, unsigned long vaddr, unsigned
 	pte_t *ptep, *p;
 
 	if (pmd_none(pmdp_get(pmd))) {
-		p = memblock_alloc(PTRS_PER_PTE * sizeof(pte_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PTE * sizeof(pte_t), PAGE_SIZE);
 		set_pmd(pmd, pfn_pmd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -54,7 +54,7 @@ static void __init kasan_populate_pmd(pud_t *pud, unsigned long vaddr, unsigned
 	unsigned long next;
 
 	if (pud_none(pudp_get(pud))) {
-		p = memblock_alloc(PTRS_PER_PMD * sizeof(pmd_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PMD * sizeof(pmd_t), PAGE_SIZE);
 		set_pud(pud, pfn_pud(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -85,7 +85,7 @@ static void __init kasan_populate_pud(p4d_t *p4d,
 	unsigned long next;
 
 	if (p4d_none(p4dp_get(p4d))) {
-		p = memblock_alloc(PTRS_PER_PUD * sizeof(pud_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PUD * sizeof(pud_t), PAGE_SIZE);
 		set_p4d(p4d, pfn_p4d(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -116,7 +116,7 @@ static void __init kasan_populate_p4d(pgd_t *pgd,
 	unsigned long next;
 
 	if (pgd_none(pgdp_get(pgd))) {
-		p = memblock_alloc(PTRS_PER_P4D * sizeof(p4d_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_P4D * sizeof(p4d_t), PAGE_SIZE);
 		set_pgd(pgd, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -385,7 +385,7 @@ static void __init kasan_shallow_populate_pud(p4d_t *p4d,
 		next = pud_addr_end(vaddr, end);
 
 		if (pud_none(pudp_get(pud_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_pud(pud_k, pfn_pud(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
@@ -405,7 +405,7 @@ static void __init kasan_shallow_populate_p4d(pgd_t *pgd,
 		next = p4d_addr_end(vaddr, end);
 
 		if (p4d_none(p4dp_get(p4d_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_p4d(p4d_k, pfn_p4d(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
@@ -424,7 +424,7 @@ static void __init kasan_shallow_populate_pgd(unsigned long vaddr, unsigned long
 		next = pgd_addr_end(vaddr, end);
 
 		if (pgd_none(pgdp_get(pgd_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_pgd(pgd_k, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
diff --git a/arch/s390/kernel/numa.c b/arch/s390/kernel/numa.c
index ddc1448ea2e1..a33e20f73330 100644
--- a/arch/s390/kernel/numa.c
+++ b/arch/s390/kernel/numa.c
@@ -22,10 +22,7 @@ void __init numa_setup(void)
 	node_set(0, node_possible_map);
 	node_set_online(0);
 	for (nid = 0; nid < MAX_NUMNODES; nid++) {
-		NODE_DATA(nid) = memblock_alloc(sizeof(pg_data_t), 8);
-		if (!NODE_DATA(nid))
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(pg_data_t), 8);
+		NODE_DATA(nid) = memblock_alloc_or_panic(sizeof(pg_data_t), 8);
 	}
 	NODE_DATA(0)->node_spanned_pages = memblock_end_of_DRAM() >> PAGE_SHIFT;
 	NODE_DATA(0)->node_id = 0;
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index 0ce550faf073..1298f0860733 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -376,11 +376,7 @@ static unsigned long __init stack_alloc_early(void)
 {
 	unsigned long stack;
 
-	stack = (unsigned long)memblock_alloc(THREAD_SIZE, THREAD_SIZE);
-	if (!stack) {
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, THREAD_SIZE, THREAD_SIZE);
-	}
+	stack = (unsigned long)memblock_alloc_or_panic(THREAD_SIZE, THREAD_SIZE);
 	return stack;
 }
 
@@ -504,10 +500,7 @@ static void __init setup_resources(void)
 	bss_resource.end = __pa_symbol(__bss_stop) - 1;
 
 	for_each_mem_range(i, &start, &end) {
-		res = memblock_alloc(sizeof(*res), 8);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(*res), 8);
+		res = memblock_alloc_or_panic(sizeof(*res), 8);
 		res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
 
 		res->name = "System RAM";
@@ -526,10 +519,7 @@ static void __init setup_resources(void)
 			    std_res->start > res->end)
 				continue;
 			if (std_res->end > res->end) {
-				sub_res = memblock_alloc(sizeof(*sub_res), 8);
-				if (!sub_res)
-					panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-					      __func__, sizeof(*sub_res), 8);
+				sub_res = memblock_alloc_or_panic(sizeof(*sub_res), 8);
 				*sub_res = *std_res;
 				sub_res->end = res->end;
 				std_res->start = res->end + 1;
@@ -816,9 +806,7 @@ static void __init setup_randomness(void)
 {
 	struct sysinfo_3_2_2 *vmms;
 
-	vmms = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!vmms)
-		panic("Failed to allocate memory for sysinfo structure\n");
+	vmms = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	if (stsi(vmms, 3, 2, 2) == 0 && vmms->count)
 		add_device_randomness(&vmms->vm, sizeof(vmms->vm[0]) * vmms->count);
 	memblock_free(vmms, PAGE_SIZE);
diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
index 822d8e6f8717..d77aaefb59bd 100644
--- a/arch/s390/kernel/smp.c
+++ b/arch/s390/kernel/smp.c
@@ -611,9 +611,9 @@ void __init smp_save_dump_ipl_cpu(void)
 	if (!dump_available())
 		return;
 	sa = save_area_alloc(true);
-	regs = memblock_alloc(512, 8);
-	if (!sa || !regs)
+	if (!sa)
 		panic("could not allocate memory for boot CPU save area\n");
+	regs = memblock_alloc_or_panic(512, 8);
 	copy_oldmem_kernel(regs, __LC_FPREGS_SAVE_AREA, 512);
 	save_area_add_regs(sa, regs);
 	memblock_free(regs, 512);
@@ -792,10 +792,7 @@ void __init smp_detect_cpus(void)
 	u16 address;
 
 	/* Get CPU information */
-	info = memblock_alloc(sizeof(*info), 8);
-	if (!info)
-		panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-		      __func__, sizeof(*info), 8);
+	info = memblock_alloc_or_panic(sizeof(*info), 8);
 	smp_get_core_info(info, 1);
 	/* Find boot CPU type */
 	if (sclp.has_core_type) {
diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
index 0fd56a1cadbd..cf5ee6032c0b 100644
--- a/arch/s390/kernel/topology.c
+++ b/arch/s390/kernel/topology.c
@@ -548,10 +548,7 @@ static void __init alloc_masks(struct sysinfo_15_1_x *info,
 		nr_masks *= info->mag[TOPOLOGY_NR_MAG - offset - 1 - i];
 	nr_masks = max(nr_masks, 1);
 	for (i = 0; i < nr_masks; i++) {
-		mask->next = memblock_alloc(sizeof(*mask->next), 8);
-		if (!mask->next)
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(*mask->next), 8);
+		mask->next = memblock_alloc_or_panic(sizeof(*mask->next), 8);
 		mask = mask->next;
 	}
 }
@@ -569,10 +566,7 @@ void __init topology_init_early(void)
 	}
 	if (!MACHINE_HAS_TOPOLOGY)
 		goto out;
-	tl_info = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!tl_info)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	tl_info = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	info = tl_info;
 	store_topology(info);
 	pr_info("The CPU configuration topology of the machine is: %d %d %d %d %d %d / %d\n",
diff --git a/arch/sh/mm/init.c b/arch/sh/mm/init.c
index 2a88b0c9e70f..289a2fecebef 100644
--- a/arch/sh/mm/init.c
+++ b/arch/sh/mm/init.c
@@ -137,10 +137,7 @@ static pmd_t * __init one_md_table_init(pud_t *pud)
 	if (pud_none(*pud)) {
 		pmd_t *pmd;
 
-		pmd = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pmd)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pmd = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 		BUG_ON(pmd != pmd_offset(pud, 0));
 	}
@@ -153,10 +150,7 @@ static pte_t * __init one_page_table_init(pmd_t *pmd)
 	if (pmd_none(*pmd)) {
 		pte_t *pte;
 
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, pte);
 		BUG_ON(pte != pte_offset_kernel(pmd, 0));
 	}
diff --git a/arch/sparc/kernel/prom_32.c b/arch/sparc/kernel/prom_32.c
index 3df960c137f7..a67dd67f10c8 100644
--- a/arch/sparc/kernel/prom_32.c
+++ b/arch/sparc/kernel/prom_32.c
@@ -28,9 +28,7 @@ void * __init prom_early_alloc(unsigned long size)
 {
 	void *ret;
 
-	ret = memblock_alloc(size, SMP_CACHE_BYTES);
-	if (!ret)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, size);
+	ret = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 
 	prom_early_allocated += size;
 
diff --git a/arch/sparc/mm/srmmu.c b/arch/sparc/mm/srmmu.c
index 9df51a62333d..e36c2a0ff748 100644
--- a/arch/sparc/mm/srmmu.c
+++ b/arch/sparc/mm/srmmu.c
@@ -277,19 +277,13 @@ static void __init srmmu_nocache_init(void)
 
 	bitmap_bits = srmmu_nocache_size >> SRMMU_NOCACHE_BITMAP_SHIFT;
 
-	srmmu_nocache_pool = memblock_alloc(srmmu_nocache_size,
+	srmmu_nocache_pool = memblock_alloc_or_panic(srmmu_nocache_size,
 					    SRMMU_NOCACHE_ALIGN_MAX);
-	if (!srmmu_nocache_pool)
-		panic("%s: Failed to allocate %lu bytes align=0x%x\n",
-		      __func__, srmmu_nocache_size, SRMMU_NOCACHE_ALIGN_MAX);
 	memset(srmmu_nocache_pool, 0, srmmu_nocache_size);
 
 	srmmu_nocache_bitmap =
-		memblock_alloc(BITS_TO_LONGS(bitmap_bits) * sizeof(long),
+		memblock_alloc_or_panic(BITS_TO_LONGS(bitmap_bits) * sizeof(long),
 			       SMP_CACHE_BYTES);
-	if (!srmmu_nocache_bitmap)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      BITS_TO_LONGS(bitmap_bits) * sizeof(long));
 	bit_map_init(&srmmu_nocache_map, srmmu_nocache_bitmap, bitmap_bits);
 
 	srmmu_swapper_pg_dir = __srmmu_get_nocache(SRMMU_PGD_TABLE_SIZE, SRMMU_PGD_TABLE_SIZE);
@@ -452,9 +446,7 @@ static void __init sparc_context_init(int numctx)
 	unsigned long size;
 
 	size = numctx * sizeof(struct ctx_list);
-	ctx_list_pool = memblock_alloc(size, SMP_CACHE_BYTES);
-	if (!ctx_list_pool)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, size);
+	ctx_list_pool = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 
 	for (ctx = 0; ctx < numctx; ctx++) {
 		struct ctx_list *clist;
diff --git a/arch/um/drivers/net_kern.c b/arch/um/drivers/net_kern.c
index 75d04fb4994a..d5a9c5aabaec 100644
--- a/arch/um/drivers/net_kern.c
+++ b/arch/um/drivers/net_kern.c
@@ -636,10 +636,7 @@ static int __init eth_setup(char *str)
 		return 1;
 	}
 
-	new = memblock_alloc(sizeof(*new), SMP_CACHE_BYTES);
-	if (!new)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*new));
+	new = memblock_alloc_or_panic(sizeof(*new), SMP_CACHE_BYTES);
 
 	INIT_LIST_HEAD(&new->list);
 	new->index = n;
diff --git a/arch/um/drivers/vector_kern.c b/arch/um/drivers/vector_kern.c
index 64c09db392c1..85b129e2b70b 100644
--- a/arch/um/drivers/vector_kern.c
+++ b/arch/um/drivers/vector_kern.c
@@ -1694,10 +1694,7 @@ static int __init vector_setup(char *str)
 				 str, error);
 		return 1;
 	}
-	new = memblock_alloc(sizeof(*new), SMP_CACHE_BYTES);
-	if (!new)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*new));
+	new = memblock_alloc_or_panic(sizeof(*new), SMP_CACHE_BYTES);
 	INIT_LIST_HEAD(&new->list);
 	new->unit = n;
 	new->arguments = str;
diff --git a/arch/um/kernel/load_file.c b/arch/um/kernel/load_file.c
index 5cecd0e291fb..cb9d178ab7d8 100644
--- a/arch/um/kernel/load_file.c
+++ b/arch/um/kernel/load_file.c
@@ -48,9 +48,7 @@ void *uml_load_file(const char *filename, unsigned long long *size)
 		return NULL;
 	}
 
-	area = memblock_alloc(*size, SMP_CACHE_BYTES);
-	if (!area)
-		panic("%s: Failed to allocate %llu bytes\n", __func__, *size);
+	area = memblock_alloc_or_panic(*size, SMP_CACHE_BYTES);
 
 	if (__uml_load_file(filename, area, *size)) {
 		memblock_free(area, *size);
diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index 499b41953e3c..fa218270c1db 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -1567,9 +1567,7 @@ static void __init alloc_runtime_data(int cpu)
 		struct svsm_ca *caa;
 
 		/* Allocate the SVSM CA page if an SVSM is present */
-		caa = memblock_alloc(sizeof(*caa), PAGE_SIZE);
-		if (!caa)
-			panic("Can't allocate SVSM CA page\n");
+		caa = memblock_alloc_or_panic(sizeof(*caa), PAGE_SIZE);
 
 		per_cpu(svsm_caa, cpu) = caa;
 		per_cpu(svsm_caa_pa, cpu) = __pa(caa);
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 3a44a9dc3fb7..7c15d6e83c37 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -911,11 +911,8 @@ static int __init acpi_parse_hpet(struct acpi_table_header *table)
 	 * the resource tree during the lateinit timeframe.
 	 */
 #define HPET_RESOURCE_NAME_SIZE 9
-	hpet_res = memblock_alloc(sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE,
+	hpet_res = memblock_alloc_or_panic(sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE,
 				  SMP_CACHE_BYTES);
-	if (!hpet_res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE);
 
 	hpet_res->name = (void *)&hpet_res[1];
 	hpet_res->flags = IORESOURCE_MEM;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 1029ea4ac8ba..a57d3fa7c6b6 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2503,9 +2503,7 @@ static struct resource * __init ioapic_setup_resources(void)
 	n = IOAPIC_RESOURCE_NAME_SIZE + sizeof(struct resource);
 	n *= nr_ioapics;
 
-	mem = memblock_alloc(n, SMP_CACHE_BYTES);
-	if (!mem)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, n);
+	mem = memblock_alloc_or_panic(n, SMP_CACHE_BYTES);
 	res = (void *)mem;
 
 	mem += sizeof(struct resource) * nr_ioapics;
@@ -2564,11 +2562,8 @@ void __init io_apic_init_mappings(void)
 #ifdef CONFIG_X86_32
 fake_ioapic_page:
 #endif
-			ioapic_phys = (unsigned long)memblock_alloc(PAGE_SIZE,
+			ioapic_phys = (unsigned long)memblock_alloc_or_panic(PAGE_SIZE,
 								    PAGE_SIZE);
-			if (!ioapic_phys)
-				panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-				      __func__, PAGE_SIZE, PAGE_SIZE);
 			ioapic_phys = __pa(ioapic_phys);
 		}
 		io_apic_set_fixmap(idx, ioapic_phys);
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 4893d30ce438..82b96ed9890a 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1146,11 +1146,8 @@ void __init e820__reserve_resources(void)
 	struct resource *res;
 	u64 end;
 
-	res = memblock_alloc(sizeof(*res) * e820_table->nr_entries,
+	res = memblock_alloc_or_panic(sizeof(*res) * e820_table->nr_entries,
 			     SMP_CACHE_BYTES);
-	if (!res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*res) * e820_table->nr_entries);
 	e820_res = res;
 
 	for (i = 0; i < e820_table->nr_entries; i++) {
diff --git a/arch/x86/platform/olpc/olpc_dt.c b/arch/x86/platform/olpc/olpc_dt.c
index 74ebd6882690..cf5dca2dbb91 100644
--- a/arch/x86/platform/olpc/olpc_dt.c
+++ b/arch/x86/platform/olpc/olpc_dt.c
@@ -136,11 +136,7 @@ void * __init prom_early_alloc(unsigned long size)
 		 * fast enough on the platforms we care about while minimizing
 		 * wasted bootmem) and hand off chunks of it to callers.
 		 */
-		res = memblock_alloc(chunk_size, SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      chunk_size);
-		BUG_ON(!res);
+		res = memblock_alloc_or_panic(chunk_size, SMP_CACHE_BYTES);
 		prom_early_allocated += chunk_size;
 		memset(res, 0, chunk_size);
 		free_mem = chunk_size;
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index b52d3e17e2c1..56914e21e303 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -178,13 +178,7 @@ static void p2m_init_identity(unsigned long *p2m, unsigned long pfn)
 static void * __ref alloc_p2m_page(void)
 {
 	if (unlikely(!slab_is_available())) {
-		void *ptr = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-
-		if (!ptr)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
-
-		return ptr;
+		return memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	}
 
 	return (void *)__get_free_page(GFP_KERNEL);
diff --git a/arch/xtensa/mm/kasan_init.c b/arch/xtensa/mm/kasan_init.c
index f00d122aa806..f39c4d83173a 100644
--- a/arch/xtensa/mm/kasan_init.c
+++ b/arch/xtensa/mm/kasan_init.c
@@ -39,11 +39,7 @@ static void __init populate(void *start, void *end)
 	unsigned long i, j;
 	unsigned long vaddr = (unsigned long)start;
 	pmd_t *pmd = pmd_off_k(vaddr);
-	pte_t *pte = memblock_alloc(n_pages * sizeof(pte_t), PAGE_SIZE);
-
-	if (!pte)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, n_pages * sizeof(pte_t), PAGE_SIZE);
+	pte_t *pte = memblock_alloc_or_panic(n_pages * sizeof(pte_t), PAGE_SIZE);
 
 	pr_debug("%s: %p - %p\n", __func__, start, end);
 
diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
index f2117fef7c7d..9c75dcc9a534 100644
--- a/drivers/clk/ti/clk.c
+++ b/drivers/clk/ti/clk.c
@@ -449,10 +449,7 @@ void __init omap2_clk_legacy_provider_init(int index, void __iomem *mem)
 {
 	struct clk_iomap *io;
 
-	io = memblock_alloc(sizeof(*io), SMP_CACHE_BYTES);
-	if (!io)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*io));
+	io = memblock_alloc_or_panic(sizeof(*io), SMP_CACHE_BYTES);
 
 	io->mem = mem;
 
diff --git a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
index a01bc5090cdf..a1534cc6c641 100644
--- a/drivers/macintosh/smu.c
+++ b/drivers/macintosh/smu.c
@@ -492,11 +492,7 @@ int __init smu_init (void)
 		goto fail_np;
 	}
 
-	smu = memblock_alloc(sizeof(struct smu_device), SMP_CACHE_BYTES);
-	if (!smu)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct smu_device));
-
+	smu = memblock_alloc_or_panic(sizeof(struct smu_device), SMP_CACHE_BYTES);
 	spin_lock_init(&smu->lock);
 	INIT_LIST_HEAD(&smu->cmd_list);
 	INIT_LIST_HEAD(&smu->cmd_i2c_list);
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 4b1e9f101ce3..809135e2c7f5 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1126,13 +1126,7 @@ void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
 
 static void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
 {
-	void *ptr = memblock_alloc(size, align);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %llu bytes align=0x%llx\n",
-		      __func__, size, align);
-
-	return ptr;
+	return memblock_alloc_or_panic(size, align);
 }
 
 bool __init early_init_dt_verify(void *dt_virt, phys_addr_t dt_phys)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index e50570629dc0..837eafa81636 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -3675,13 +3675,7 @@ static struct device_node *overlay_base_root;
 
 static void * __init dt_alloc_memory(u64 size, u64 align)
 {
-	void *ptr = memblock_alloc(size, align);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %llu bytes align=0x%llx\n",
-		      __func__, size, align);
-
-	return ptr;
+	return memblock_alloc_or_panic(size, align);
 }
 
 /*
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 673d5cae7c81..40a1c85a0bef 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -417,6 +417,19 @@ static __always_inline void *memblock_alloc(phys_addr_t size, phys_addr_t align)
 				      MEMBLOCK_ALLOC_ACCESSIBLE, NUMA_NO_NODE);
 }
 
+static __always_inline void *memblock_alloc_or_panic(phys_addr_t size, phys_addr_t align)
+{
+	void *addr = memblock_alloc(size, align);
+
+	if (unlikely(!addr))
+#ifdef CONFIG_PHYS_ADDR_T_64BIT
+		panic("%s: Failed to allocate %llu bytes\n", __func__, size);
+#else
+		panic("%s: Failed to allocate %u bytes\n", __func__, size);
+#endif
+	return addr;
+}
+
 static inline void *memblock_alloc_raw(phys_addr_t size,
 					       phys_addr_t align)
 {
diff --git a/init/main.c b/init/main.c
index 893cb77aef22..2a1757826397 100644
--- a/init/main.c
+++ b/init/main.c
@@ -640,15 +640,11 @@ static void __init setup_command_line(char *command_line)
 
 	len = xlen + strlen(boot_command_line) + ilen + 1;
 
-	saved_command_line = memblock_alloc(len, SMP_CACHE_BYTES);
-	if (!saved_command_line)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, len);
+	saved_command_line = memblock_alloc_or_panic(len, SMP_CACHE_BYTES);
 
 	len = xlen + strlen(command_line) + 1;
 
-	static_command_line = memblock_alloc(len, SMP_CACHE_BYTES);
-	if (!static_command_line)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, len);
+	static_command_line = memblock_alloc_or_panic(len, SMP_CACHE_BYTES);
 
 	if (xlen) {
 		/*
@@ -1146,16 +1142,10 @@ static int __init initcall_blacklist(char *str)
 		str_entry = strsep(&str, ",");
 		if (str_entry) {
 			pr_debug("blacklisting initcall %s\n", str_entry);
-			entry = memblock_alloc(sizeof(*entry),
+			entry = memblock_alloc_or_panic(sizeof(*entry),
 					       SMP_CACHE_BYTES);
-			if (!entry)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, sizeof(*entry));
-			entry->buf = memblock_alloc(strlen(str_entry) + 1,
+			entry->buf = memblock_alloc_or_panic(strlen(str_entry) + 1,
 						    SMP_CACHE_BYTES);
-			if (!entry->buf)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, strlen(str_entry) + 1);
 			strcpy(entry->buf, str_entry);
 			list_add(&entry->next, &blacklisted_initcalls);
 		}
diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
index 30894d8f0a78..c9fb559a6399 100644
--- a/kernel/power/snapshot.c
+++ b/kernel/power/snapshot.c
@@ -1011,11 +1011,8 @@ void __init register_nosave_region(unsigned long start_pfn, unsigned long end_pf
 		}
 	}
 	/* This allocation cannot fail */
-	region = memblock_alloc(sizeof(struct nosave_region),
+	region = memblock_alloc_or_panic(sizeof(struct nosave_region),
 				SMP_CACHE_BYTES);
-	if (!region)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct nosave_region));
 	region->start_pfn = start_pfn;
 	region->end_pfn = end_pfn;
 	list_add_tail(®ion->list, &nosave_regions);
diff --git a/lib/cpumask.c b/lib/cpumask.c
index e77ee9d46f71..57274ba8b6d9 100644
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@ -83,10 +83,7 @@ EXPORT_SYMBOL(alloc_cpumask_var_node);
  */
 void __init alloc_bootmem_cpumask_var(cpumask_var_t *mask)
 {
-	*mask = memblock_alloc(cpumask_size(), SMP_CACHE_BYTES);
-	if (!*mask)
-		panic("%s: Failed to allocate %u bytes\n", __func__,
-		      cpumask_size());
+	*mask = memblock_alloc_or_panic(cpumask_size(), SMP_CACHE_BYTES);
 }
 
 /**
diff --git a/mm/kmsan/shadow.c b/mm/kmsan/shadow.c
index 9c58f081d84f..1bb505a08415 100644
--- a/mm/kmsan/shadow.c
+++ b/mm/kmsan/shadow.c
@@ -280,12 +280,8 @@ void __init kmsan_init_alloc_meta_for_range(void *start, void *end)
 
 	start = (void *)PAGE_ALIGN_DOWN((u64)start);
 	size = PAGE_ALIGN((u64)end - (u64)start);
-	shadow = memblock_alloc(size, PAGE_SIZE);
-	origin = memblock_alloc(size, PAGE_SIZE);
-
-	if (!shadow || !origin)
-		panic("%s: Failed to allocate metadata memory for early boot range of size %llu",
-		      __func__, size);
+	shadow = memblock_alloc_or_panic(size, PAGE_SIZE);
+	origin = memblock_alloc_or_panic(size, PAGE_SIZE);
 
 	for (u64 addr = 0; addr < size; addr += PAGE_SIZE) {
 		page = virt_to_page_or_null((char *)start + addr);
diff --git a/mm/numa.c b/mm/numa.c
index e2eec07707d1..f1787d7713a6 100644
--- a/mm/numa.c
+++ b/mm/numa.c
@@ -37,13 +37,7 @@ void __init alloc_node_data(int nid)
 void __init alloc_offline_node_data(int nid)
 {
 	pg_data_t *pgdat;
-
-	pgdat = memblock_alloc(sizeof(*pgdat), SMP_CACHE_BYTES);
-	if (!pgdat)
-		panic("Cannot allocate %zuB for node %d.\n",
-		      sizeof(*pgdat), nid);
-
-	node_data[nid] = pgdat;
+	node_data[nid] = memblock_alloc_or_panic(sizeof(*pgdat), SMP_CACHE_BYTES);
 }
 
 /* Stub functions: */
diff --git a/mm/percpu.c b/mm/percpu.c
index d8dd31a2e407..ac61e3fc5f15 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1359,10 +1359,7 @@ static struct pcpu_chunk * __init pcpu_alloc_first_chunk(unsigned long tmp_addr,
 	/* allocate chunk */
 	alloc_size = struct_size(chunk, populated,
 				 BITS_TO_LONGS(region_size >> PAGE_SHIFT));
-	chunk = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	INIT_LIST_HEAD(&chunk->list);
 
@@ -1374,24 +1371,14 @@ static struct pcpu_chunk * __init pcpu_alloc_first_chunk(unsigned long tmp_addr,
 	region_bits = pcpu_chunk_map_bits(chunk);
 
 	alloc_size = BITS_TO_LONGS(region_bits) * sizeof(chunk->alloc_map[0]);
-	chunk->alloc_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->alloc_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk->alloc_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size =
 		BITS_TO_LONGS(region_bits + 1) * sizeof(chunk->bound_map[0]);
-	chunk->bound_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->bound_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk->bound_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = pcpu_chunk_nr_blocks(chunk) * sizeof(chunk->md_blocks[0]);
-	chunk->md_blocks = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->md_blocks)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
-
+	chunk->md_blocks = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 #ifdef NEED_PCPUOBJ_EXT
 	/* first chunk is free to use */
 	chunk->obj_exts = NULL;
@@ -2595,28 +2582,16 @@ void __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
 
 	/* process group information and build config tables accordingly */
 	alloc_size = ai->nr_groups * sizeof(group_offsets[0]);
-	group_offsets = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!group_offsets)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	group_offsets = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = ai->nr_groups * sizeof(group_sizes[0]);
-	group_sizes = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!group_sizes)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	group_sizes = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = nr_cpu_ids * sizeof(unit_map[0]);
-	unit_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!unit_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	unit_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = nr_cpu_ids * sizeof(unit_off[0]);
-	unit_off = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!unit_off)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	unit_off = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	for (cpu = 0; cpu < nr_cpu_ids; cpu++)
 		unit_map[cpu] = UINT_MAX;
@@ -2685,12 +2660,9 @@ void __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
 	pcpu_free_slot = pcpu_sidelined_slot + 1;
 	pcpu_to_depopulate_slot = pcpu_free_slot + 1;
 	pcpu_nr_slots = pcpu_to_depopulate_slot + 1;
-	pcpu_chunk_lists = memblock_alloc(pcpu_nr_slots *
+	pcpu_chunk_lists = memblock_alloc_or_panic(pcpu_nr_slots *
 					  sizeof(pcpu_chunk_lists[0]),
 					  SMP_CACHE_BYTES);
-	if (!pcpu_chunk_lists)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      pcpu_nr_slots * sizeof(pcpu_chunk_lists[0]));
 
 	for (i = 0; i < pcpu_nr_slots; i++)
 		INIT_LIST_HEAD(&pcpu_chunk_lists[i]);
@@ -3155,25 +3127,19 @@ void __init __weak pcpu_populate_pte(unsigned long addr)
 	pmd_t *pmd;
 
 	if (pgd_none(*pgd)) {
-		p4d = memblock_alloc(P4D_TABLE_SIZE, P4D_TABLE_SIZE);
-		if (!p4d)
-			goto err_alloc;
+		p4d = memblock_alloc_or_panic(P4D_TABLE_SIZE, P4D_TABLE_SIZE);
 		pgd_populate(&init_mm, pgd, p4d);
 	}
 
 	p4d = p4d_offset(pgd, addr);
 	if (p4d_none(*p4d)) {
-		pud = memblock_alloc(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
-		if (!pud)
-			goto err_alloc;
+		pud = memblock_alloc_or_panic(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
 		p4d_populate(&init_mm, p4d, pud);
 	}
 
 	pud = pud_offset(p4d, addr);
 	if (pud_none(*pud)) {
-		pmd = memblock_alloc(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
-		if (!pmd)
-			goto err_alloc;
+		pmd = memblock_alloc_or_panic(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 	}
 
@@ -3181,16 +3147,11 @@ void __init __weak pcpu_populate_pte(unsigned long addr)
 	if (!pmd_present(*pmd)) {
 		pte_t *new;
 
-		new = memblock_alloc(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
-		if (!new)
-			goto err_alloc;
+		new = memblock_alloc_or_panic(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, new);
 	}
 
 	return;
-
-err_alloc:
-	panic("%s: Failed to allocate memory\n", __func__);
 }
 
 /**
@@ -3237,10 +3198,7 @@ int __init pcpu_page_first_chunk(size_t reserved_size, pcpu_fc_cpu_to_node_fn_t
 	/* unaligned allocations can't be freed, round up to page size */
 	pages_size = PFN_ALIGN(unit_pages * num_possible_cpus() *
 			       sizeof(pages[0]));
-	pages = memblock_alloc(pages_size, SMP_CACHE_BYTES);
-	if (!pages)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      pages_size);
+	pages = memblock_alloc_or_panic(pages_size, SMP_CACHE_BYTES);
 
 	/* allocate pages */
 	j = 0;
diff --git a/mm/sparse.c b/mm/sparse.c
index 13b6624d3562..133b033d0cba 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -257,10 +257,7 @@ static void __init memblocks_present(void)
 
 		size = sizeof(struct mem_section *) * NR_SECTION_ROOTS;
 		align = 1 << (INTERNODE_CACHE_SHIFT);
-		mem_section = memblock_alloc(size, align);
-		if (!mem_section)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, size, align);
+		mem_section = memblock_alloc_or_panic(size, align);
 	}
 #endif
 
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Sat Dec 21 10:51:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Dec 2024 10:51:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862380.1274113 (Exim 4.92)
	(envelope-from )
	id 1tOx4X-0002Ic-Dp; Sat, 21 Dec 2024 10:51:01 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862380.1274113; Sat, 21 Dec 2024 10: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 1tOx4X-0002IV-9k; Sat, 21 Dec 2024 10:51:01 +0000
Received: by outflank-mailman (input) for mailman id 862380;
 Sat, 21 Dec 2024 10:51: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 1tOx4W-0002IP-3e
 for xen-devel@lists.xenproject.org; Sat, 21 Dec 2024 10:51:00 +0000
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com
 [2607:f8b0:4864:20::632])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 74b5cbb0-bf89-11ef-a0d9-8be0dac302b0;
 Sat, 21 Dec 2024 11:50:57 +0100 (CET)
Received: by mail-pl1-x632.google.com with SMTP id
 d9443c01a7336-21680814d42so24894945ad.2
 for ; Sat, 21 Dec 2024 02:50:56 -0800 (PST)
Received: from localhost.localdomain ([36.110.106.149])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-219dc9f7e49sm42164475ad.217.2024.12.21.02.50.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 21 Dec 2024 02:50: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: 74b5cbb0-bf89-11ef-a0d9-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734778255; x=1735383055; 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=FMtuukiXGUthXESLw6zTM/MFRRzwuQ+pkPa0ANA6jII=;
        b=lFkWsynAOAYE+nARnV3StTncfZxB3FNDmSgiHHzP9tOquLkOlcGpvqNARtzqZEj5qS
         VrdtRWypZm9sJSeXgFdHOEBus/XksLSBEBcnAhWrWofcg6Ci2jXjbrzrHkZnk/dmauF5
         bS5VhQ09bSw6BpvyEfryuk3YUH+Q4g5dxruw3BHPBoXMPY/qrJdEC66qgjm3AaikWUQl
         y0Aq4m36MiLz5BeoV7Iyw6pZy+ftpnbv7nhyvj8+OBzvUfQ75YOvRMeTkpbchwWWLPN4
         Vca6q2hyDsh26vSoN1UvWKZuSFQbjAcniduFnTweZbR0RIv0ZT18XKquFvn6ONfNpug4
         eV9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734778255; x=1735383055;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=FMtuukiXGUthXESLw6zTM/MFRRzwuQ+pkPa0ANA6jII=;
        b=IElzg1D3ovRyJCb9hxCjSEXGSRHnnqzA6HceOjKajsl42JtKotqE7A2hnL9TMXafEy
         u/cXO0FsuMkKVpe1PzbesTGLYIWXuhV9dzdgPYpDlFgeE+qdiIy3rBXYkq1kgASNnhx8
         +L8wo3onHdwjN9ZizJLPe20eX6pKc6tYzwzvyKpYunwkUS8IVX2K2bD6lotE57XtVs4n
         wJNuLnxuBobfkfz3d5K9PquAcfcsiniK1kdh8fjzfZksOZbA8Pg3TkRihgeKb7SLx2ut
         898E5VmP3qvpC9P9owFeWtPQHprHtLA2rHuA70u8MMUTbXUFjiw7tmB9dYW3Ysj+jUvy
         vWaQ==
X-Forwarded-Encrypted: i=1; AJvYcCXPxiLfM3wzh5xgy4IuN2XHe5g0vafN7EocppaWxZoNhLC5Sf+U5XgymC++TwUxeaKQ9ZANvEiCPWM=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy30Cgnm/EOOZ1LQapdexMNLzKf4WrQxe3C5+8hDmjmJvr0Z/lN
	TgdJUJRn9wCYund2UChonlrYXe43RtCp6R+xhF6kdANBWyI29B7O
X-Gm-Gg: ASbGncsMBbbIhdKnm1ywVdc6kdAwA4mbUOZDXr0WhpnAOAB1DCVLRX76Rl0VwdSKJn5
	vy4TEM/bNgHRbFQPZNe2qo6+MxPDUv2Xd85GecqOIKX3m+TPgzX3gdrVMMWVniVd9Imdpo/CxKP
	s1o6HTOaKHPdxZl0gJlqIrK38r6uFDaz7WWQ6HKeUqlJxaYR6zoUmYxLuPJU3BbXQYOw2fSivah
	ZiQvVan7k/m4vkZ7pMXd7HqRglBi9nm6fbxPAVDiVBs7HF3LtMCbsIL20rZ9PMQhV6L2hS5CGRs
	LDZP
X-Google-Smtp-Source: AGHT+IEcfdQZnOgpe4T7a55Eg82ftcD6jzd8oQZMCW61mp8xBQbLU3lm6j6/UBVOJ4rmiSs4u196sw==
X-Received: by 2002:a17:902:ecc7:b0:215:401b:9535 with SMTP id d9443c01a7336-219e70dbe4bmr81691825ad.47.1734778255055;
        Sat, 21 Dec 2024 02:50:55 -0800 (PST)
From: Guo Weikang 
To: Andrew Morton ,
	Mike Rapoport ,
	Guo Weikang 
Cc: Dennis Zhou ,
	Tejun Heo ,
	Christoph Lameter ,
	Thomas Bogendoerfer ,
	Sam Creasey ,
	Geert Uytterhoeven ,
	Huacai Chen ,
	Will Deacon ,
	Catalin Marinas ,
	Oreoluwa Babatunde ,
	rafael.j.wysocki@intel.com,
	Palmer Dabbelt ,
	Hanjun Guo ,
	Easwar Hariharan ,
	Johannes Berg ,
	Ingo Molnar ,
	Dave Hansen ,
	Christian Brauner ,
	KP Singh ,
	Richard Henderson ,
	Matt Turner ,
	Russell King ,
	WANG Xuerui ,
	Michael Ellerman ,
	Stefan Kristiansson ,
	Stafford Horne ,
	Helge Deller ,
	Nicholas Piggin ,
	Christophe Leroy ,
	Naveen N Rao ,
	Madhavan Srinivasan ,
	Geoff Levand ,
	Paul Walmsley ,
	Palmer Dabbelt ,
	Albert Ou ,
	Andrey Ryabinin ,
	Alexander Potapenko ,
	Andrey Konovalov ,
	Dmitry Vyukov ,
	Vincenzo Frascino ,
	Heiko Carstens ,
	Vasily Gorbik ,
	Alexander Gordeev ,
	Christian Borntraeger ,
	Sven Schnelle ,
	Yoshinori Sato ,
	Rich Felker ,
	John Paul Adrian Glaubitz ,
	Andreas Larsson ,
	Richard Weinberger ,
	Anton Ivanov ,
	Johannes Berg ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	x86@kernel.org,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-m68k@lists.linux-m68k.org,
	linux-mips@vger.kernel.org,
	linux-openrisc@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org,
	kasan-dev@googlegroups.com,
	linux-s390@vger.kernel.org,
	linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org,
	linux-um@lists.infradead.org,
	linux-acpi@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-omap@vger.kernel.org,
	linux-clk@vger.kernel.org,
	devicetree@vger.kernel.org,
	linux-mm@kvack.org,
	linux-pm@vger.kernel.org
Subject: [PATCH v3] mm/memblock: Add memblock_alloc_or_panic interface
Date: Sat, 21 Dec 2024 18:50:19 +0800
Message-Id: <20241221105019.2665369-1-guoweikang.kernel@gmail.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Before SLUB initialization, various subsystems used memblock_alloc to
allocate memory. In most cases, when memory allocation fails, an immediate
panic is required. To simplify this behavior and reduce repetitive checks,
introduce `memblock_alloc_or_panic`. This function ensures that memory
allocation failures result in a panic automatically, improving code
readability and consistency across subsystems that require this behavior.

Signed-off-by: Guo Weikang 
---
 arch/alpha/kernel/core_cia.c            |  5 +-
 arch/alpha/kernel/core_marvel.c         | 10 +---
 arch/alpha/kernel/pci.c                 | 13 +----
 arch/alpha/kernel/pci_iommu.c           | 10 +---
 arch/arm/kernel/setup.c                 | 10 +---
 arch/arm/mm/mmu.c                       | 17 ++----
 arch/arm/mm/nommu.c                     |  5 +-
 arch/arm64/kernel/setup.c               |  4 +-
 arch/loongarch/kernel/setup.c           |  2 +-
 arch/loongarch/mm/init.c                | 13 ++---
 arch/m68k/mm/init.c                     |  5 +-
 arch/m68k/mm/mcfmmu.c                   | 10 +---
 arch/m68k/mm/motorola.c                 |  5 +-
 arch/m68k/mm/sun3mmu.c                  | 10 +---
 arch/m68k/sun3/sun3dvma.c               |  6 +--
 arch/mips/kernel/setup.c                |  5 +-
 arch/openrisc/mm/ioremap.c              |  5 +-
 arch/parisc/mm/init.c                   | 20 ++-----
 arch/powerpc/kernel/dt_cpu_ftrs.c       | 10 ++--
 arch/powerpc/kernel/pci_32.c            |  5 +-
 arch/powerpc/kernel/setup-common.c      |  5 +-
 arch/powerpc/kernel/setup_32.c          |  8 +--
 arch/powerpc/mm/book3s32/mmu.c          |  5 +-
 arch/powerpc/mm/book3s64/pgtable.c      |  6 +--
 arch/powerpc/mm/kasan/init_book3e_64.c  |  8 +--
 arch/powerpc/mm/kasan/init_book3s_64.c  |  2 +-
 arch/powerpc/mm/nohash/mmu_context.c    | 16 ++----
 arch/powerpc/mm/pgtable_32.c            |  7 +--
 arch/powerpc/platforms/powermac/nvram.c |  5 +-
 arch/powerpc/platforms/powernv/opal.c   |  5 +-
 arch/powerpc/platforms/ps3/setup.c      |  5 +-
 arch/powerpc/sysdev/msi_bitmap.c        |  5 +-
 arch/riscv/kernel/setup.c               |  4 +-
 arch/riscv/mm/kasan_init.c              | 14 ++---
 arch/s390/kernel/numa.c                 |  5 +-
 arch/s390/kernel/setup.c                | 20 ++-----
 arch/s390/kernel/smp.c                  |  9 ++--
 arch/s390/kernel/topology.c             | 10 +---
 arch/sh/mm/init.c                       | 10 +---
 arch/sparc/kernel/prom_32.c             |  4 +-
 arch/sparc/mm/srmmu.c                   | 14 ++---
 arch/um/drivers/net_kern.c              |  5 +-
 arch/um/drivers/vector_kern.c           |  5 +-
 arch/um/kernel/load_file.c              |  4 +-
 arch/x86/coco/sev/core.c                |  4 +-
 arch/x86/kernel/acpi/boot.c             |  5 +-
 arch/x86/kernel/apic/io_apic.c          |  9 +---
 arch/x86/kernel/e820.c                  |  5 +-
 arch/x86/platform/olpc/olpc_dt.c        |  6 +--
 arch/x86/xen/p2m.c                      |  8 +--
 arch/xtensa/mm/kasan_init.c             |  6 +--
 drivers/clk/ti/clk.c                    |  5 +-
 drivers/macintosh/smu.c                 |  6 +--
 drivers/of/fdt.c                        |  8 +--
 drivers/of/unittest.c                   |  8 +--
 include/linux/memblock.h                | 14 +++++
 init/main.c                             | 18 ++-----
 kernel/power/snapshot.c                 |  5 +-
 lib/cpumask.c                           |  5 +-
 mm/kmsan/shadow.c                       |  8 +--
 mm/numa.c                               |  8 +--
 mm/percpu.c                             | 70 +++++--------------------
 mm/sparse.c                             |  5 +-
 63 files changed, 131 insertions(+), 423 deletions(-)

diff --git a/arch/alpha/kernel/core_cia.c b/arch/alpha/kernel/core_cia.c
index ca3d9c732b61..6e577228e175 100644
--- a/arch/alpha/kernel/core_cia.c
+++ b/arch/alpha/kernel/core_cia.c
@@ -331,10 +331,7 @@ cia_prepare_tbia_workaround(int window)
 	long i;
 
 	/* Use minimal 1K map. */
-	ppte = memblock_alloc(CIA_BROKEN_TBIA_SIZE, 32768);
-	if (!ppte)
-		panic("%s: Failed to allocate %u bytes align=0x%x\n",
-		      __func__, CIA_BROKEN_TBIA_SIZE, 32768);
+	ppte = memblock_alloc_or_panic(CIA_BROKEN_TBIA_SIZE, 32768);
 	pte = (virt_to_phys(ppte) >> (PAGE_SHIFT - 1)) | 1;
 
 	for (i = 0; i < CIA_BROKEN_TBIA_SIZE / sizeof(unsigned long); ++i)
diff --git a/arch/alpha/kernel/core_marvel.c b/arch/alpha/kernel/core_marvel.c
index b22248044bf0..b1bfbd11980d 100644
--- a/arch/alpha/kernel/core_marvel.c
+++ b/arch/alpha/kernel/core_marvel.c
@@ -81,10 +81,7 @@ mk_resource_name(int pe, int port, char *str)
 	char *name;
 	
 	sprintf(tmp, "PCI %s PE %d PORT %d", str, pe, port);
-	name = memblock_alloc(strlen(tmp) + 1, SMP_CACHE_BYTES);
-	if (!name)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      strlen(tmp) + 1);
+	name = memblock_alloc_or_panic(strlen(tmp) + 1, SMP_CACHE_BYTES);
 	strcpy(name, tmp);
 
 	return name;
@@ -119,10 +116,7 @@ alloc_io7(unsigned int pe)
 		return NULL;
 	}
 
-	io7 = memblock_alloc(sizeof(*io7), SMP_CACHE_BYTES);
-	if (!io7)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*io7));
+	io7 = memblock_alloc_or_panic(sizeof(*io7), SMP_CACHE_BYTES);
 	io7->pe = pe;
 	raw_spin_lock_init(&io7->irq_lock);
 
diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
index 4458eb7f44f0..8e9b4ac86b7e 100644
--- a/arch/alpha/kernel/pci.c
+++ b/arch/alpha/kernel/pci.c
@@ -391,10 +391,7 @@ alloc_pci_controller(void)
 {
 	struct pci_controller *hose;
 
-	hose = memblock_alloc(sizeof(*hose), SMP_CACHE_BYTES);
-	if (!hose)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*hose));
+	hose = memblock_alloc_or_panic(sizeof(*hose), SMP_CACHE_BYTES);
 
 	*hose_tail = hose;
 	hose_tail = &hose->next;
@@ -405,13 +402,7 @@ alloc_pci_controller(void)
 struct resource * __init
 alloc_resource(void)
 {
-	void *ptr = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct resource));
-
-	return ptr;
+	return memblock_alloc_or_panic(sizeof(struct resource), SMP_CACHE_BYTES);
 }
 
 
diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index 7fcf3e9b7103..681f56089d9c 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -71,14 +71,8 @@ iommu_arena_new_node(int nid, struct pci_controller *hose, dma_addr_t base,
 	if (align < mem_size)
 		align = mem_size;
 
-	arena = memblock_alloc(sizeof(*arena), SMP_CACHE_BYTES);
-	if (!arena)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*arena));
-	arena->ptes = memblock_alloc(mem_size, align);
-	if (!arena->ptes)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, mem_size, align);
+	arena = memblock_alloc_or_panic(sizeof(*arena), SMP_CACHE_BYTES);
+	arena->ptes = memblock_alloc_or_panic(mem_size, align);
 
 	spin_lock_init(&arena->lock);
 	arena->hose = hose;
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index e6a857bf0ce6..a41c93988d2c 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -880,10 +880,7 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 		 */
 		boot_alias_start = phys_to_idmap(start);
 		if (arm_has_idmap_alias() && boot_alias_start != IDMAP_INVALID_ADDR) {
-			res = memblock_alloc(sizeof(*res), SMP_CACHE_BYTES);
-			if (!res)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, sizeof(*res));
+			res = memblock_alloc_or_panic(sizeof(*res), SMP_CACHE_BYTES);
 			res->name = "System RAM (boot alias)";
 			res->start = boot_alias_start;
 			res->end = phys_to_idmap(res_end);
@@ -891,10 +888,7 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 			request_resource(&iomem_resource, res);
 		}
 
-		res = memblock_alloc(sizeof(*res), SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      sizeof(*res));
+		res = memblock_alloc_or_panic(sizeof(*res), SMP_CACHE_BYTES);
 		res->name  = "System RAM";
 		res->start = start;
 		res->end = res_end;
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index f5b7a16c5803..f02f872ea8a9 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -726,13 +726,8 @@ EXPORT_SYMBOL(phys_mem_access_prot);
 
 static void __init *early_alloc(unsigned long sz)
 {
-	void *ptr = memblock_alloc(sz, sz);
+	return memblock_alloc_or_panic(sz, sz);
 
-	if (!ptr)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, sz, sz);
-
-	return ptr;
 }
 
 static void *__init late_alloc(unsigned long sz)
@@ -1027,10 +1022,7 @@ void __init iotable_init(struct map_desc *io_desc, int nr)
 	if (!nr)
 		return;
 
-	svm = memblock_alloc(sizeof(*svm) * nr, __alignof__(*svm));
-	if (!svm)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, sizeof(*svm) * nr, __alignof__(*svm));
+	svm = memblock_alloc_or_panic(sizeof(*svm) * nr, __alignof__(*svm));
 
 	for (md = io_desc; nr; md++, nr--) {
 		create_mapping(md);
@@ -1052,10 +1044,7 @@ void __init vm_reserve_area_early(unsigned long addr, unsigned long size,
 	struct vm_struct *vm;
 	struct static_vm *svm;
 
-	svm = memblock_alloc(sizeof(*svm), __alignof__(*svm));
-	if (!svm)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, sizeof(*svm), __alignof__(*svm));
+	svm = memblock_alloc_or_panic(sizeof(*svm), __alignof__(*svm));
 
 	vm = &svm->vm;
 	vm->addr = (void *)addr;
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index c415f3859b20..1a8f6914ee59 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -162,10 +162,7 @@ void __init paging_init(const struct machine_desc *mdesc)
 	mpu_setup();
 
 	/* allocate the zero page. */
-	zero_page = (void *)memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	zero_page = (void *)memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	bootmem_init();
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 4f613e8e0745..85104587f849 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -223,9 +223,7 @@ static void __init request_standard_resources(void)
 
 	num_standard_resources = memblock.memory.cnt;
 	res_size = num_standard_resources * sizeof(*standard_resources);
-	standard_resources = memblock_alloc(res_size, SMP_CACHE_BYTES);
-	if (!standard_resources)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, res_size);
+	standard_resources = memblock_alloc_or_panic(res_size, SMP_CACHE_BYTES);
 
 	for_each_mem_region(region) {
 		res = &standard_resources[i++];
diff --git a/arch/loongarch/kernel/setup.c b/arch/loongarch/kernel/setup.c
index 56934fe58170..edcfdfcad7d2 100644
--- a/arch/loongarch/kernel/setup.c
+++ b/arch/loongarch/kernel/setup.c
@@ -431,7 +431,7 @@ static void __init resource_init(void)
 
 	num_standard_resources = memblock.memory.cnt;
 	res_size = num_standard_resources * sizeof(*standard_resources);
-	standard_resources = memblock_alloc(res_size, SMP_CACHE_BYTES);
+	standard_resources = memblock_alloc_or_panic(res_size, SMP_CACHE_BYTES);
 
 	for_each_mem_region(region) {
 		res = &standard_resources[i++];
diff --git a/arch/loongarch/mm/init.c b/arch/loongarch/mm/init.c
index 188b52bbb254..ca5aa5f46a9f 100644
--- a/arch/loongarch/mm/init.c
+++ b/arch/loongarch/mm/init.c
@@ -174,9 +174,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 	pmd_t *pmd;
 
 	if (p4d_none(p4dp_get(p4d))) {
-		pud = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pud)
-			panic("%s: Failed to allocate memory\n", __func__);
+		pud = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		p4d_populate(&init_mm, p4d, pud);
 #ifndef __PAGETABLE_PUD_FOLDED
 		pud_init(pud);
@@ -185,9 +183,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 
 	pud = pud_offset(p4d, addr);
 	if (pud_none(pudp_get(pud))) {
-		pmd = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pmd)
-			panic("%s: Failed to allocate memory\n", __func__);
+		pmd = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 #ifndef __PAGETABLE_PMD_FOLDED
 		pmd_init(pmd);
@@ -198,10 +194,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 	if (!pmd_present(pmdp_get(pmd))) {
 		pte_t *pte;
 
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate memory\n", __func__);
-
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, pte);
 		kernel_pte_init(pte);
 	}
diff --git a/arch/m68k/mm/init.c b/arch/m68k/mm/init.c
index 1b47bec15832..8b11d0d545aa 100644
--- a/arch/m68k/mm/init.c
+++ b/arch/m68k/mm/init.c
@@ -68,10 +68,7 @@ void __init paging_init(void)
 
 	high_memory = (void *) end_mem;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	max_zone_pfn[ZONE_DMA] = end_mem >> PAGE_SHIFT;
 	free_area_init(max_zone_pfn);
 }
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index 9a6fa342e872..19a75029036c 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -42,20 +42,14 @@ void __init paging_init(void)
 	unsigned long max_zone_pfn[MAX_NR_ZONES] = { 0 };
 	int i;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	pg_dir = swapper_pg_dir;
 	memset(swapper_pg_dir, 0, sizeof(swapper_pg_dir));
 
 	size = num_pages * sizeof(pte_t);
 	size = (size + PAGE_SIZE) & ~(PAGE_SIZE-1);
-	next_pgtable = (unsigned long) memblock_alloc(size, PAGE_SIZE);
-	if (!next_pgtable)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, PAGE_SIZE);
+	next_pgtable = (unsigned long) memblock_alloc_or_panic(size, PAGE_SIZE);
 
 	pg_dir += PAGE_OFFSET >> PGDIR_SHIFT;
 
diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
index c1761d309fc6..795dd1f2b24f 100644
--- a/arch/m68k/mm/motorola.c
+++ b/arch/m68k/mm/motorola.c
@@ -491,10 +491,7 @@ void __init paging_init(void)
 	 * initialize the bad page table and bad page to point
 	 * to a couple of allocated pages
 	 */
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	/*
 	 * Set up SFC/DFC registers
diff --git a/arch/m68k/mm/sun3mmu.c b/arch/m68k/mm/sun3mmu.c
index 494739c1783e..1ecf6bdd08bf 100644
--- a/arch/m68k/mm/sun3mmu.c
+++ b/arch/m68k/mm/sun3mmu.c
@@ -44,10 +44,7 @@ void __init paging_init(void)
 	unsigned long max_zone_pfn[MAX_NR_ZONES] = { 0, };
 	unsigned long size;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	address = PAGE_OFFSET;
 	pg_dir = swapper_pg_dir;
@@ -57,10 +54,7 @@ void __init paging_init(void)
 	size = num_pages * sizeof(pte_t);
 	size = (size + PAGE_SIZE) & ~(PAGE_SIZE-1);
 
-	next_pgtable = (unsigned long)memblock_alloc(size, PAGE_SIZE);
-	if (!next_pgtable)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, PAGE_SIZE);
+	next_pgtable = (unsigned long)memblock_alloc_or_panic(size, PAGE_SIZE);
 	bootmem_end = (next_pgtable + size + PAGE_SIZE) & PAGE_MASK;
 
 	/* Map whole memory from PAGE_OFFSET (0x0E000000) */
diff --git a/arch/m68k/sun3/sun3dvma.c b/arch/m68k/sun3/sun3dvma.c
index 6ebf52740ad7..225fc735e466 100644
--- a/arch/m68k/sun3/sun3dvma.c
+++ b/arch/m68k/sun3/sun3dvma.c
@@ -252,12 +252,8 @@ void __init dvma_init(void)
 
 	list_add(&(hole->list), &hole_list);
 
-	iommu_use = memblock_alloc(IOMMU_TOTAL_ENTRIES * sizeof(unsigned long),
+	iommu_use = memblock_alloc_or_panic(IOMMU_TOTAL_ENTRIES * sizeof(unsigned long),
 				   SMP_CACHE_BYTES);
-	if (!iommu_use)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      IOMMU_TOTAL_ENTRIES * sizeof(unsigned long));
-
 	dvma_unmap_iommu(DVMA_START, DVMA_SIZE);
 
 	sun3_dvma_init();
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 12a1a4ffb602..fbfe0771317e 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -704,10 +704,7 @@ static void __init resource_init(void)
 	for_each_mem_range(i, &start, &end) {
 		struct resource *res;
 
-		res = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      sizeof(struct resource));
+		res = memblock_alloc_or_panic(sizeof(struct resource), SMP_CACHE_BYTES);
 
 		res->start = start;
 		/*
diff --git a/arch/openrisc/mm/ioremap.c b/arch/openrisc/mm/ioremap.c
index f59ea4c10b0f..8e63e86251ca 100644
--- a/arch/openrisc/mm/ioremap.c
+++ b/arch/openrisc/mm/ioremap.c
@@ -38,10 +38,7 @@ pte_t __ref *pte_alloc_one_kernel(struct mm_struct *mm)
 	if (likely(mem_init_done)) {
 		pte = (pte_t *)get_zeroed_page(GFP_KERNEL);
 	} else {
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	}
 
 	return pte;
diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index 96970fa75e4a..61c0a2477072 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -377,10 +377,8 @@ static void __ref map_pages(unsigned long start_vaddr,
 
 #if CONFIG_PGTABLE_LEVELS == 3
 		if (pud_none(*pud)) {
-			pmd = memblock_alloc(PAGE_SIZE << PMD_TABLE_ORDER,
+			pmd = memblock_alloc_or_panic(PAGE_SIZE << PMD_TABLE_ORDER,
 					     PAGE_SIZE << PMD_TABLE_ORDER);
-			if (!pmd)
-				panic("pmd allocation failed.\n");
 			pud_populate(NULL, pud, pmd);
 		}
 #endif
@@ -388,9 +386,7 @@ static void __ref map_pages(unsigned long start_vaddr,
 		pmd = pmd_offset(pud, vaddr);
 		for (tmp1 = start_pmd; tmp1 < PTRS_PER_PMD; tmp1++, pmd++) {
 			if (pmd_none(*pmd)) {
-				pg_table = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-				if (!pg_table)
-					panic("page table allocation failed\n");
+				pg_table = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 				pmd_populate_kernel(NULL, pmd, pg_table);
 			}
 
@@ -648,9 +644,7 @@ static void __init pagetable_init(void)
 	}
 #endif
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("zero page allocation failed.\n");
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 }
 
@@ -687,19 +681,15 @@ static void __init fixmap_init(void)
 
 #if CONFIG_PGTABLE_LEVELS == 3
 	if (pud_none(*pud)) {
-		pmd = memblock_alloc(PAGE_SIZE << PMD_TABLE_ORDER,
+		pmd = memblock_alloc_or_panic(PAGE_SIZE << PMD_TABLE_ORDER,
 				     PAGE_SIZE << PMD_TABLE_ORDER);
-		if (!pmd)
-			panic("fixmap: pmd allocation failed.\n");
 		pud_populate(NULL, pud, pmd);
 	}
 #endif
 
 	pmd = pmd_offset(pud, addr);
 	do {
-		pte_t *pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("fixmap: pte allocation failed.\n");
+		pte_t *pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 		pmd_populate_kernel(&init_mm, pmd, pte);
 
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 1bee15c013e7..3af6c06af02f 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -1087,12 +1087,10 @@ static int __init dt_cpu_ftrs_scan_callback(unsigned long node, const char
 	/* Count and allocate space for cpu features */
 	of_scan_flat_dt_subnodes(node, count_cpufeatures_subnodes,
 						&nr_dt_cpu_features);
-	dt_cpu_features = memblock_alloc(sizeof(struct dt_cpu_feature) * nr_dt_cpu_features, PAGE_SIZE);
-	if (!dt_cpu_features)
-		panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
-		      __func__,
-		      sizeof(struct dt_cpu_feature) * nr_dt_cpu_features,
-		      PAGE_SIZE);
+	dt_cpu_features =
+		memblock_alloc_or_panic(
+			sizeof(struct dt_cpu_feature) * nr_dt_cpu_features,
+			PAGE_SIZE);
 
 	cpufeatures_setup_start(isa);
 
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index ce0c8623e563..f8a3bd8cfae4 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -213,11 +213,8 @@ pci_create_OF_bus_map(void)
 	struct property* of_prop;
 	struct device_node *dn;
 
-	of_prop = memblock_alloc(sizeof(struct property) + 256,
+	of_prop = memblock_alloc_or_panic(sizeof(struct property) + 256,
 				 SMP_CACHE_BYTES);
-	if (!of_prop)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct property) + 256);
 	dn = of_find_node_by_path("/");
 	if (dn) {
 		memset(of_prop, -1, sizeof(struct property) + 256);
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 6fa179448c33..f3ea1329c566 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -458,11 +458,8 @@ void __init smp_setup_cpu_maps(void)
 
 	DBG("smp_setup_cpu_maps()\n");
 
-	cpu_to_phys_id = memblock_alloc(nr_cpu_ids * sizeof(u32),
+	cpu_to_phys_id = memblock_alloc_or_panic(nr_cpu_ids * sizeof(u32),
 					__alignof__(u32));
-	if (!cpu_to_phys_id)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, nr_cpu_ids * sizeof(u32), __alignof__(u32));
 
 	for_each_node_by_type(dn, "cpu") {
 		const __be32 *intserv;
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 75dbf3e0d9c4..5a1bf501fbe1 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -140,13 +140,7 @@ arch_initcall(ppc_init);
 
 static void *__init alloc_stack(void)
 {
-	void *ptr = memblock_alloc(THREAD_SIZE, THREAD_ALIGN);
-
-	if (!ptr)
-		panic("cannot allocate %d bytes for stack at %pS\n",
-		      THREAD_SIZE, (void *)_RET_IP_);
-
-	return ptr;
+	return memblock_alloc_or_panic(THREAD_SIZE, THREAD_ALIGN);
 }
 
 void __init irqstack_early_init(void)
diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/mmu.c
index 6978344edcb4..be9c4106e22f 100644
--- a/arch/powerpc/mm/book3s32/mmu.c
+++ b/arch/powerpc/mm/book3s32/mmu.c
@@ -377,10 +377,7 @@ void __init MMU_init_hw(void)
 	 * Find some memory for the hash table.
 	 */
 	if ( ppc_md.progress ) ppc_md.progress("hash:find piece", 0x322);
-	Hash = memblock_alloc(Hash_size, Hash_size);
-	if (!Hash)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, Hash_size, Hash_size);
+	Hash = memblock_alloc_or_panic(Hash_size, Hash_size);
 	_SDR1 = __pa(Hash) | SDR1_LOW_BITS;
 
 	pr_info("Total memory = %lldMB; using %ldkB for hash table\n",
diff --git a/arch/powerpc/mm/book3s64/pgtable.c b/arch/powerpc/mm/book3s64/pgtable.c
index 374542528080..0b1f419b7404 100644
--- a/arch/powerpc/mm/book3s64/pgtable.c
+++ b/arch/powerpc/mm/book3s64/pgtable.c
@@ -330,11 +330,7 @@ void __init mmu_partition_table_init(void)
 	unsigned long ptcr;
 
 	/* Initialize the Partition Table with no entries */
-	partition_tb = memblock_alloc(patb_size, patb_size);
-	if (!partition_tb)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, patb_size, patb_size);
-
+	partition_tb = memblock_alloc_or_panic(patb_size, patb_size);
 	ptcr = __pa(partition_tb) | (PATB_SIZE_SHIFT - 12);
 	set_ptcr_when_no_uv(ptcr);
 	powernv_set_nmmu_ptcr(ptcr);
diff --git a/arch/powerpc/mm/kasan/init_book3e_64.c b/arch/powerpc/mm/kasan/init_book3e_64.c
index 43c03b84ff32..60c78aac0f63 100644
--- a/arch/powerpc/mm/kasan/init_book3e_64.c
+++ b/arch/powerpc/mm/kasan/init_book3e_64.c
@@ -40,19 +40,19 @@ static int __init kasan_map_kernel_page(unsigned long ea, unsigned long pa, pgpr
 	pgdp = pgd_offset_k(ea);
 	p4dp = p4d_offset(pgdp, ea);
 	if (kasan_pud_table(*p4dp)) {
-		pudp = memblock_alloc(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
+		pudp = memblock_alloc_or_panic(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
 		memcpy(pudp, kasan_early_shadow_pud, PUD_TABLE_SIZE);
 		p4d_populate(&init_mm, p4dp, pudp);
 	}
 	pudp = pud_offset(p4dp, ea);
 	if (kasan_pmd_table(*pudp)) {
-		pmdp = memblock_alloc(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
+		pmdp = memblock_alloc_or_panic(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
 		memcpy(pmdp, kasan_early_shadow_pmd, PMD_TABLE_SIZE);
 		pud_populate(&init_mm, pudp, pmdp);
 	}
 	pmdp = pmd_offset(pudp, ea);
 	if (kasan_pte_table(*pmdp)) {
-		ptep = memblock_alloc(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
+		ptep = memblock_alloc_or_panic(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
 		memcpy(ptep, kasan_early_shadow_pte, PTE_TABLE_SIZE);
 		pmd_populate_kernel(&init_mm, pmdp, ptep);
 	}
@@ -74,7 +74,7 @@ static void __init kasan_init_phys_region(void *start, void *end)
 	k_start = ALIGN_DOWN((unsigned long)kasan_mem_to_shadow(start), PAGE_SIZE);
 	k_end = ALIGN((unsigned long)kasan_mem_to_shadow(end), PAGE_SIZE);
 
-	va = memblock_alloc(k_end - k_start, PAGE_SIZE);
+	va = memblock_alloc_or_panic(k_end - k_start, PAGE_SIZE);
 	for (k_cur = k_start; k_cur < k_end; k_cur += PAGE_SIZE, va += PAGE_SIZE)
 		kasan_map_kernel_page(k_cur, __pa(va), PAGE_KERNEL);
 }
diff --git a/arch/powerpc/mm/kasan/init_book3s_64.c b/arch/powerpc/mm/kasan/init_book3s_64.c
index 3fb5ce4f48f4..7d959544c077 100644
--- a/arch/powerpc/mm/kasan/init_book3s_64.c
+++ b/arch/powerpc/mm/kasan/init_book3s_64.c
@@ -32,7 +32,7 @@ static void __init kasan_init_phys_region(void *start, void *end)
 	k_start = ALIGN_DOWN((unsigned long)kasan_mem_to_shadow(start), PAGE_SIZE);
 	k_end = ALIGN((unsigned long)kasan_mem_to_shadow(end), PAGE_SIZE);
 
-	va = memblock_alloc(k_end - k_start, PAGE_SIZE);
+	va = memblock_alloc_or_panic(k_end - k_start, PAGE_SIZE);
 	for (k_cur = k_start; k_cur < k_end; k_cur += PAGE_SIZE, va += PAGE_SIZE)
 		map_kernel_page(k_cur, __pa(va), PAGE_KERNEL);
 }
diff --git a/arch/powerpc/mm/nohash/mmu_context.c b/arch/powerpc/mm/nohash/mmu_context.c
index 0b181da40ddb..a1a4e697251a 100644
--- a/arch/powerpc/mm/nohash/mmu_context.c
+++ b/arch/powerpc/mm/nohash/mmu_context.c
@@ -385,21 +385,11 @@ void __init mmu_context_init(void)
 	/*
 	 * Allocate the maps used by context management
 	 */
-	context_map = memblock_alloc(CTX_MAP_SIZE, SMP_CACHE_BYTES);
-	if (!context_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      CTX_MAP_SIZE);
-	context_mm = memblock_alloc(sizeof(void *) * (LAST_CONTEXT + 1),
+	context_map = memblock_alloc_or_panic(CTX_MAP_SIZE, SMP_CACHE_BYTES);
+	context_mm = memblock_alloc_or_panic(sizeof(void *) * (LAST_CONTEXT + 1),
 				    SMP_CACHE_BYTES);
-	if (!context_mm)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(void *) * (LAST_CONTEXT + 1));
 	if (IS_ENABLED(CONFIG_SMP)) {
-		stale_map[boot_cpuid] = memblock_alloc(CTX_MAP_SIZE, SMP_CACHE_BYTES);
-		if (!stale_map[boot_cpuid])
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      CTX_MAP_SIZE);
-
+		stale_map[boot_cpuid] = memblock_alloc_or_panic(CTX_MAP_SIZE, SMP_CACHE_BYTES);
 		cpuhp_setup_state_nocalls(CPUHP_POWERPC_MMU_CTX_PREPARE,
 					  "powerpc/mmu/ctx:prepare",
 					  mmu_ctx_cpu_prepare, mmu_ctx_cpu_dead);
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 787b22206386..15276068f657 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -50,13 +50,8 @@ notrace void __init early_ioremap_init(void)
 
 void __init *early_alloc_pgtable(unsigned long size)
 {
-	void *ptr = memblock_alloc(size, size);
+	return memblock_alloc_or_panic(size, size);
 
-	if (!ptr)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, size);
-
-	return ptr;
 }
 
 pte_t __init *early_pte_alloc_kernel(pmd_t *pmdp, unsigned long va)
diff --git a/arch/powerpc/platforms/powermac/nvram.c b/arch/powerpc/platforms/powermac/nvram.c
index fe2e0249cbc2..a112d26185a0 100644
--- a/arch/powerpc/platforms/powermac/nvram.c
+++ b/arch/powerpc/platforms/powermac/nvram.c
@@ -514,10 +514,7 @@ static int __init core99_nvram_setup(struct device_node *dp, unsigned long addr)
 		printk(KERN_ERR "nvram: no address\n");
 		return -EINVAL;
 	}
-	nvram_image = memblock_alloc(NVRAM_SIZE, SMP_CACHE_BYTES);
-	if (!nvram_image)
-		panic("%s: Failed to allocate %u bytes\n", __func__,
-		      NVRAM_SIZE);
+	nvram_image = memblock_alloc_or_panic(NVRAM_SIZE, SMP_CACHE_BYTES);
 	nvram_data = ioremap(addr, NVRAM_SIZE*2);
 	nvram_naddrs = 1; /* Make sure we get the correct case */
 
diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
index 5d0f35bb917e..09bd93464b4f 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -180,10 +180,7 @@ int __init early_init_dt_scan_recoverable_ranges(unsigned long node,
 	/*
 	 * Allocate a buffer to hold the MC recoverable ranges.
 	 */
-	mc_recoverable_range = memblock_alloc(size, __alignof__(u64));
-	if (!mc_recoverable_range)
-		panic("%s: Failed to allocate %u bytes align=0x%lx\n",
-		      __func__, size, __alignof__(u64));
+	mc_recoverable_range = memblock_alloc_or_panic(size, __alignof__(u64));
 
 	for (i = 0; i < mc_recoverable_range_len; i++) {
 		mc_recoverable_range[i].start_addr =
diff --git a/arch/powerpc/platforms/ps3/setup.c b/arch/powerpc/platforms/ps3/setup.c
index 5144f11359f7..150c09b58ae8 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -115,10 +115,7 @@ static void __init prealloc(struct ps3_prealloc *p)
 	if (!p->size)
 		return;
 
-	p->address = memblock_alloc(p->size, p->align);
-	if (!p->address)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, p->size, p->align);
+	p->address = memblock_alloc_or_panic(p->size, p->align);
 
 	printk(KERN_INFO "%s: %lu bytes at %p\n", p->name, p->size,
 	       p->address);
diff --git a/arch/powerpc/sysdev/msi_bitmap.c b/arch/powerpc/sysdev/msi_bitmap.c
index 0b6e37f3ffb8..456a4f64ae0a 100644
--- a/arch/powerpc/sysdev/msi_bitmap.c
+++ b/arch/powerpc/sysdev/msi_bitmap.c
@@ -124,10 +124,7 @@ int __ref msi_bitmap_alloc(struct msi_bitmap *bmp, unsigned int irq_count,
 	if (bmp->bitmap_from_slab)
 		bmp->bitmap = kzalloc(size, GFP_KERNEL);
 	else {
-		bmp->bitmap = memblock_alloc(size, SMP_CACHE_BYTES);
-		if (!bmp->bitmap)
-			panic("%s: Failed to allocate %u bytes\n", __func__,
-			      size);
+		bmp->bitmap = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 		/* the bitmap won't be freed from memblock allocator */
 		kmemleak_not_leak(bmp->bitmap);
 	}
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 45010e71df86..f1793630fc51 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -147,9 +147,7 @@ static void __init init_resources(void)
 	res_idx = num_resources - 1;
 
 	mem_res_sz = num_resources * sizeof(*mem_res);
-	mem_res = memblock_alloc(mem_res_sz, SMP_CACHE_BYTES);
-	if (!mem_res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, mem_res_sz);
+	mem_res = memblock_alloc_or_panic(mem_res_sz, SMP_CACHE_BYTES);
 
 	/*
 	 * Start by adding the reserved regions, if they overlap
diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index c301c8d291d2..41c635d6aca4 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -32,7 +32,7 @@ static void __init kasan_populate_pte(pmd_t *pmd, unsigned long vaddr, unsigned
 	pte_t *ptep, *p;
 
 	if (pmd_none(pmdp_get(pmd))) {
-		p = memblock_alloc(PTRS_PER_PTE * sizeof(pte_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PTE * sizeof(pte_t), PAGE_SIZE);
 		set_pmd(pmd, pfn_pmd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -54,7 +54,7 @@ static void __init kasan_populate_pmd(pud_t *pud, unsigned long vaddr, unsigned
 	unsigned long next;
 
 	if (pud_none(pudp_get(pud))) {
-		p = memblock_alloc(PTRS_PER_PMD * sizeof(pmd_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PMD * sizeof(pmd_t), PAGE_SIZE);
 		set_pud(pud, pfn_pud(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -85,7 +85,7 @@ static void __init kasan_populate_pud(p4d_t *p4d,
 	unsigned long next;
 
 	if (p4d_none(p4dp_get(p4d))) {
-		p = memblock_alloc(PTRS_PER_PUD * sizeof(pud_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PUD * sizeof(pud_t), PAGE_SIZE);
 		set_p4d(p4d, pfn_p4d(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -116,7 +116,7 @@ static void __init kasan_populate_p4d(pgd_t *pgd,
 	unsigned long next;
 
 	if (pgd_none(pgdp_get(pgd))) {
-		p = memblock_alloc(PTRS_PER_P4D * sizeof(p4d_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_P4D * sizeof(p4d_t), PAGE_SIZE);
 		set_pgd(pgd, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -385,7 +385,7 @@ static void __init kasan_shallow_populate_pud(p4d_t *p4d,
 		next = pud_addr_end(vaddr, end);
 
 		if (pud_none(pudp_get(pud_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_pud(pud_k, pfn_pud(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
@@ -405,7 +405,7 @@ static void __init kasan_shallow_populate_p4d(pgd_t *pgd,
 		next = p4d_addr_end(vaddr, end);
 
 		if (p4d_none(p4dp_get(p4d_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_p4d(p4d_k, pfn_p4d(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
@@ -424,7 +424,7 @@ static void __init kasan_shallow_populate_pgd(unsigned long vaddr, unsigned long
 		next = pgd_addr_end(vaddr, end);
 
 		if (pgd_none(pgdp_get(pgd_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_pgd(pgd_k, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
diff --git a/arch/s390/kernel/numa.c b/arch/s390/kernel/numa.c
index ddc1448ea2e1..a33e20f73330 100644
--- a/arch/s390/kernel/numa.c
+++ b/arch/s390/kernel/numa.c
@@ -22,10 +22,7 @@ void __init numa_setup(void)
 	node_set(0, node_possible_map);
 	node_set_online(0);
 	for (nid = 0; nid < MAX_NUMNODES; nid++) {
-		NODE_DATA(nid) = memblock_alloc(sizeof(pg_data_t), 8);
-		if (!NODE_DATA(nid))
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(pg_data_t), 8);
+		NODE_DATA(nid) = memblock_alloc_or_panic(sizeof(pg_data_t), 8);
 	}
 	NODE_DATA(0)->node_spanned_pages = memblock_end_of_DRAM() >> PAGE_SHIFT;
 	NODE_DATA(0)->node_id = 0;
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index 0ce550faf073..1298f0860733 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -376,11 +376,7 @@ static unsigned long __init stack_alloc_early(void)
 {
 	unsigned long stack;
 
-	stack = (unsigned long)memblock_alloc(THREAD_SIZE, THREAD_SIZE);
-	if (!stack) {
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, THREAD_SIZE, THREAD_SIZE);
-	}
+	stack = (unsigned long)memblock_alloc_or_panic(THREAD_SIZE, THREAD_SIZE);
 	return stack;
 }
 
@@ -504,10 +500,7 @@ static void __init setup_resources(void)
 	bss_resource.end = __pa_symbol(__bss_stop) - 1;
 
 	for_each_mem_range(i, &start, &end) {
-		res = memblock_alloc(sizeof(*res), 8);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(*res), 8);
+		res = memblock_alloc_or_panic(sizeof(*res), 8);
 		res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
 
 		res->name = "System RAM";
@@ -526,10 +519,7 @@ static void __init setup_resources(void)
 			    std_res->start > res->end)
 				continue;
 			if (std_res->end > res->end) {
-				sub_res = memblock_alloc(sizeof(*sub_res), 8);
-				if (!sub_res)
-					panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-					      __func__, sizeof(*sub_res), 8);
+				sub_res = memblock_alloc_or_panic(sizeof(*sub_res), 8);
 				*sub_res = *std_res;
 				sub_res->end = res->end;
 				std_res->start = res->end + 1;
@@ -816,9 +806,7 @@ static void __init setup_randomness(void)
 {
 	struct sysinfo_3_2_2 *vmms;
 
-	vmms = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!vmms)
-		panic("Failed to allocate memory for sysinfo structure\n");
+	vmms = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	if (stsi(vmms, 3, 2, 2) == 0 && vmms->count)
 		add_device_randomness(&vmms->vm, sizeof(vmms->vm[0]) * vmms->count);
 	memblock_free(vmms, PAGE_SIZE);
diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
index 822d8e6f8717..d77aaefb59bd 100644
--- a/arch/s390/kernel/smp.c
+++ b/arch/s390/kernel/smp.c
@@ -611,9 +611,9 @@ void __init smp_save_dump_ipl_cpu(void)
 	if (!dump_available())
 		return;
 	sa = save_area_alloc(true);
-	regs = memblock_alloc(512, 8);
-	if (!sa || !regs)
+	if (!sa)
 		panic("could not allocate memory for boot CPU save area\n");
+	regs = memblock_alloc_or_panic(512, 8);
 	copy_oldmem_kernel(regs, __LC_FPREGS_SAVE_AREA, 512);
 	save_area_add_regs(sa, regs);
 	memblock_free(regs, 512);
@@ -792,10 +792,7 @@ void __init smp_detect_cpus(void)
 	u16 address;
 
 	/* Get CPU information */
-	info = memblock_alloc(sizeof(*info), 8);
-	if (!info)
-		panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-		      __func__, sizeof(*info), 8);
+	info = memblock_alloc_or_panic(sizeof(*info), 8);
 	smp_get_core_info(info, 1);
 	/* Find boot CPU type */
 	if (sclp.has_core_type) {
diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
index 0fd56a1cadbd..cf5ee6032c0b 100644
--- a/arch/s390/kernel/topology.c
+++ b/arch/s390/kernel/topology.c
@@ -548,10 +548,7 @@ static void __init alloc_masks(struct sysinfo_15_1_x *info,
 		nr_masks *= info->mag[TOPOLOGY_NR_MAG - offset - 1 - i];
 	nr_masks = max(nr_masks, 1);
 	for (i = 0; i < nr_masks; i++) {
-		mask->next = memblock_alloc(sizeof(*mask->next), 8);
-		if (!mask->next)
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(*mask->next), 8);
+		mask->next = memblock_alloc_or_panic(sizeof(*mask->next), 8);
 		mask = mask->next;
 	}
 }
@@ -569,10 +566,7 @@ void __init topology_init_early(void)
 	}
 	if (!MACHINE_HAS_TOPOLOGY)
 		goto out;
-	tl_info = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!tl_info)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	tl_info = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	info = tl_info;
 	store_topology(info);
 	pr_info("The CPU configuration topology of the machine is: %d %d %d %d %d %d / %d\n",
diff --git a/arch/sh/mm/init.c b/arch/sh/mm/init.c
index 2a88b0c9e70f..289a2fecebef 100644
--- a/arch/sh/mm/init.c
+++ b/arch/sh/mm/init.c
@@ -137,10 +137,7 @@ static pmd_t * __init one_md_table_init(pud_t *pud)
 	if (pud_none(*pud)) {
 		pmd_t *pmd;
 
-		pmd = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pmd)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pmd = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 		BUG_ON(pmd != pmd_offset(pud, 0));
 	}
@@ -153,10 +150,7 @@ static pte_t * __init one_page_table_init(pmd_t *pmd)
 	if (pmd_none(*pmd)) {
 		pte_t *pte;
 
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, pte);
 		BUG_ON(pte != pte_offset_kernel(pmd, 0));
 	}
diff --git a/arch/sparc/kernel/prom_32.c b/arch/sparc/kernel/prom_32.c
index 3df960c137f7..a67dd67f10c8 100644
--- a/arch/sparc/kernel/prom_32.c
+++ b/arch/sparc/kernel/prom_32.c
@@ -28,9 +28,7 @@ void * __init prom_early_alloc(unsigned long size)
 {
 	void *ret;
 
-	ret = memblock_alloc(size, SMP_CACHE_BYTES);
-	if (!ret)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, size);
+	ret = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 
 	prom_early_allocated += size;
 
diff --git a/arch/sparc/mm/srmmu.c b/arch/sparc/mm/srmmu.c
index 9df51a62333d..e36c2a0ff748 100644
--- a/arch/sparc/mm/srmmu.c
+++ b/arch/sparc/mm/srmmu.c
@@ -277,19 +277,13 @@ static void __init srmmu_nocache_init(void)
 
 	bitmap_bits = srmmu_nocache_size >> SRMMU_NOCACHE_BITMAP_SHIFT;
 
-	srmmu_nocache_pool = memblock_alloc(srmmu_nocache_size,
+	srmmu_nocache_pool = memblock_alloc_or_panic(srmmu_nocache_size,
 					    SRMMU_NOCACHE_ALIGN_MAX);
-	if (!srmmu_nocache_pool)
-		panic("%s: Failed to allocate %lu bytes align=0x%x\n",
-		      __func__, srmmu_nocache_size, SRMMU_NOCACHE_ALIGN_MAX);
 	memset(srmmu_nocache_pool, 0, srmmu_nocache_size);
 
 	srmmu_nocache_bitmap =
-		memblock_alloc(BITS_TO_LONGS(bitmap_bits) * sizeof(long),
+		memblock_alloc_or_panic(BITS_TO_LONGS(bitmap_bits) * sizeof(long),
 			       SMP_CACHE_BYTES);
-	if (!srmmu_nocache_bitmap)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      BITS_TO_LONGS(bitmap_bits) * sizeof(long));
 	bit_map_init(&srmmu_nocache_map, srmmu_nocache_bitmap, bitmap_bits);
 
 	srmmu_swapper_pg_dir = __srmmu_get_nocache(SRMMU_PGD_TABLE_SIZE, SRMMU_PGD_TABLE_SIZE);
@@ -452,9 +446,7 @@ static void __init sparc_context_init(int numctx)
 	unsigned long size;
 
 	size = numctx * sizeof(struct ctx_list);
-	ctx_list_pool = memblock_alloc(size, SMP_CACHE_BYTES);
-	if (!ctx_list_pool)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, size);
+	ctx_list_pool = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 
 	for (ctx = 0; ctx < numctx; ctx++) {
 		struct ctx_list *clist;
diff --git a/arch/um/drivers/net_kern.c b/arch/um/drivers/net_kern.c
index 75d04fb4994a..d5a9c5aabaec 100644
--- a/arch/um/drivers/net_kern.c
+++ b/arch/um/drivers/net_kern.c
@@ -636,10 +636,7 @@ static int __init eth_setup(char *str)
 		return 1;
 	}
 
-	new = memblock_alloc(sizeof(*new), SMP_CACHE_BYTES);
-	if (!new)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*new));
+	new = memblock_alloc_or_panic(sizeof(*new), SMP_CACHE_BYTES);
 
 	INIT_LIST_HEAD(&new->list);
 	new->index = n;
diff --git a/arch/um/drivers/vector_kern.c b/arch/um/drivers/vector_kern.c
index 64c09db392c1..85b129e2b70b 100644
--- a/arch/um/drivers/vector_kern.c
+++ b/arch/um/drivers/vector_kern.c
@@ -1694,10 +1694,7 @@ static int __init vector_setup(char *str)
 				 str, error);
 		return 1;
 	}
-	new = memblock_alloc(sizeof(*new), SMP_CACHE_BYTES);
-	if (!new)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*new));
+	new = memblock_alloc_or_panic(sizeof(*new), SMP_CACHE_BYTES);
 	INIT_LIST_HEAD(&new->list);
 	new->unit = n;
 	new->arguments = str;
diff --git a/arch/um/kernel/load_file.c b/arch/um/kernel/load_file.c
index 5cecd0e291fb..cb9d178ab7d8 100644
--- a/arch/um/kernel/load_file.c
+++ b/arch/um/kernel/load_file.c
@@ -48,9 +48,7 @@ void *uml_load_file(const char *filename, unsigned long long *size)
 		return NULL;
 	}
 
-	area = memblock_alloc(*size, SMP_CACHE_BYTES);
-	if (!area)
-		panic("%s: Failed to allocate %llu bytes\n", __func__, *size);
+	area = memblock_alloc_or_panic(*size, SMP_CACHE_BYTES);
 
 	if (__uml_load_file(filename, area, *size)) {
 		memblock_free(area, *size);
diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index 499b41953e3c..fa218270c1db 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -1567,9 +1567,7 @@ static void __init alloc_runtime_data(int cpu)
 		struct svsm_ca *caa;
 
 		/* Allocate the SVSM CA page if an SVSM is present */
-		caa = memblock_alloc(sizeof(*caa), PAGE_SIZE);
-		if (!caa)
-			panic("Can't allocate SVSM CA page\n");
+		caa = memblock_alloc_or_panic(sizeof(*caa), PAGE_SIZE);
 
 		per_cpu(svsm_caa, cpu) = caa;
 		per_cpu(svsm_caa_pa, cpu) = __pa(caa);
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 3a44a9dc3fb7..7c15d6e83c37 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -911,11 +911,8 @@ static int __init acpi_parse_hpet(struct acpi_table_header *table)
 	 * the resource tree during the lateinit timeframe.
 	 */
 #define HPET_RESOURCE_NAME_SIZE 9
-	hpet_res = memblock_alloc(sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE,
+	hpet_res = memblock_alloc_or_panic(sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE,
 				  SMP_CACHE_BYTES);
-	if (!hpet_res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE);
 
 	hpet_res->name = (void *)&hpet_res[1];
 	hpet_res->flags = IORESOURCE_MEM;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 1029ea4ac8ba..a57d3fa7c6b6 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2503,9 +2503,7 @@ static struct resource * __init ioapic_setup_resources(void)
 	n = IOAPIC_RESOURCE_NAME_SIZE + sizeof(struct resource);
 	n *= nr_ioapics;
 
-	mem = memblock_alloc(n, SMP_CACHE_BYTES);
-	if (!mem)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, n);
+	mem = memblock_alloc_or_panic(n, SMP_CACHE_BYTES);
 	res = (void *)mem;
 
 	mem += sizeof(struct resource) * nr_ioapics;
@@ -2564,11 +2562,8 @@ void __init io_apic_init_mappings(void)
 #ifdef CONFIG_X86_32
 fake_ioapic_page:
 #endif
-			ioapic_phys = (unsigned long)memblock_alloc(PAGE_SIZE,
+			ioapic_phys = (unsigned long)memblock_alloc_or_panic(PAGE_SIZE,
 								    PAGE_SIZE);
-			if (!ioapic_phys)
-				panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-				      __func__, PAGE_SIZE, PAGE_SIZE);
 			ioapic_phys = __pa(ioapic_phys);
 		}
 		io_apic_set_fixmap(idx, ioapic_phys);
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 4893d30ce438..82b96ed9890a 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1146,11 +1146,8 @@ void __init e820__reserve_resources(void)
 	struct resource *res;
 	u64 end;
 
-	res = memblock_alloc(sizeof(*res) * e820_table->nr_entries,
+	res = memblock_alloc_or_panic(sizeof(*res) * e820_table->nr_entries,
 			     SMP_CACHE_BYTES);
-	if (!res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*res) * e820_table->nr_entries);
 	e820_res = res;
 
 	for (i = 0; i < e820_table->nr_entries; i++) {
diff --git a/arch/x86/platform/olpc/olpc_dt.c b/arch/x86/platform/olpc/olpc_dt.c
index 74ebd6882690..cf5dca2dbb91 100644
--- a/arch/x86/platform/olpc/olpc_dt.c
+++ b/arch/x86/platform/olpc/olpc_dt.c
@@ -136,11 +136,7 @@ void * __init prom_early_alloc(unsigned long size)
 		 * fast enough on the platforms we care about while minimizing
 		 * wasted bootmem) and hand off chunks of it to callers.
 		 */
-		res = memblock_alloc(chunk_size, SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      chunk_size);
-		BUG_ON(!res);
+		res = memblock_alloc_or_panic(chunk_size, SMP_CACHE_BYTES);
 		prom_early_allocated += chunk_size;
 		memset(res, 0, chunk_size);
 		free_mem = chunk_size;
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index b52d3e17e2c1..56914e21e303 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -178,13 +178,7 @@ static void p2m_init_identity(unsigned long *p2m, unsigned long pfn)
 static void * __ref alloc_p2m_page(void)
 {
 	if (unlikely(!slab_is_available())) {
-		void *ptr = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-
-		if (!ptr)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
-
-		return ptr;
+		return memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	}
 
 	return (void *)__get_free_page(GFP_KERNEL);
diff --git a/arch/xtensa/mm/kasan_init.c b/arch/xtensa/mm/kasan_init.c
index f00d122aa806..f39c4d83173a 100644
--- a/arch/xtensa/mm/kasan_init.c
+++ b/arch/xtensa/mm/kasan_init.c
@@ -39,11 +39,7 @@ static void __init populate(void *start, void *end)
 	unsigned long i, j;
 	unsigned long vaddr = (unsigned long)start;
 	pmd_t *pmd = pmd_off_k(vaddr);
-	pte_t *pte = memblock_alloc(n_pages * sizeof(pte_t), PAGE_SIZE);
-
-	if (!pte)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, n_pages * sizeof(pte_t), PAGE_SIZE);
+	pte_t *pte = memblock_alloc_or_panic(n_pages * sizeof(pte_t), PAGE_SIZE);
 
 	pr_debug("%s: %p - %p\n", __func__, start, end);
 
diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
index f2117fef7c7d..9c75dcc9a534 100644
--- a/drivers/clk/ti/clk.c
+++ b/drivers/clk/ti/clk.c
@@ -449,10 +449,7 @@ void __init omap2_clk_legacy_provider_init(int index, void __iomem *mem)
 {
 	struct clk_iomap *io;
 
-	io = memblock_alloc(sizeof(*io), SMP_CACHE_BYTES);
-	if (!io)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*io));
+	io = memblock_alloc_or_panic(sizeof(*io), SMP_CACHE_BYTES);
 
 	io->mem = mem;
 
diff --git a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
index a01bc5090cdf..a1534cc6c641 100644
--- a/drivers/macintosh/smu.c
+++ b/drivers/macintosh/smu.c
@@ -492,11 +492,7 @@ int __init smu_init (void)
 		goto fail_np;
 	}
 
-	smu = memblock_alloc(sizeof(struct smu_device), SMP_CACHE_BYTES);
-	if (!smu)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct smu_device));
-
+	smu = memblock_alloc_or_panic(sizeof(struct smu_device), SMP_CACHE_BYTES);
 	spin_lock_init(&smu->lock);
 	INIT_LIST_HEAD(&smu->cmd_list);
 	INIT_LIST_HEAD(&smu->cmd_i2c_list);
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 4b1e9f101ce3..809135e2c7f5 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1126,13 +1126,7 @@ void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
 
 static void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
 {
-	void *ptr = memblock_alloc(size, align);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %llu bytes align=0x%llx\n",
-		      __func__, size, align);
-
-	return ptr;
+	return memblock_alloc_or_panic(size, align);
 }
 
 bool __init early_init_dt_verify(void *dt_virt, phys_addr_t dt_phys)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index e50570629dc0..837eafa81636 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -3675,13 +3675,7 @@ static struct device_node *overlay_base_root;
 
 static void * __init dt_alloc_memory(u64 size, u64 align)
 {
-	void *ptr = memblock_alloc(size, align);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %llu bytes align=0x%llx\n",
-		      __func__, size, align);
-
-	return ptr;
+	return memblock_alloc_or_panic(size, align);
 }
 
 /*
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 673d5cae7c81..03bd00d3ae1f 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -417,6 +417,20 @@ static __always_inline void *memblock_alloc(phys_addr_t size, phys_addr_t align)
 				      MEMBLOCK_ALLOC_ACCESSIBLE, NUMA_NO_NODE);
 }
 
+static __always_inline void *__memblock_alloc_or_panic(phys_addr_t size,
+						       phys_addr_t align,
+						       const char *func)
+{
+	void *addr = memblock_alloc(size, align);
+
+	if (unlikely(!addr))
+		panic("%s: Failed to allocate %pap bytes\n", func, &size);
+	return addr;
+}
+
+#define memblock_alloc_or_panic(size, align)    \
+	 __memblock_alloc_or_panic(size, align, __func__)
+
 static inline void *memblock_alloc_raw(phys_addr_t size,
 					       phys_addr_t align)
 {
diff --git a/init/main.c b/init/main.c
index 893cb77aef22..2a1757826397 100644
--- a/init/main.c
+++ b/init/main.c
@@ -640,15 +640,11 @@ static void __init setup_command_line(char *command_line)
 
 	len = xlen + strlen(boot_command_line) + ilen + 1;
 
-	saved_command_line = memblock_alloc(len, SMP_CACHE_BYTES);
-	if (!saved_command_line)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, len);
+	saved_command_line = memblock_alloc_or_panic(len, SMP_CACHE_BYTES);
 
 	len = xlen + strlen(command_line) + 1;
 
-	static_command_line = memblock_alloc(len, SMP_CACHE_BYTES);
-	if (!static_command_line)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, len);
+	static_command_line = memblock_alloc_or_panic(len, SMP_CACHE_BYTES);
 
 	if (xlen) {
 		/*
@@ -1146,16 +1142,10 @@ static int __init initcall_blacklist(char *str)
 		str_entry = strsep(&str, ",");
 		if (str_entry) {
 			pr_debug("blacklisting initcall %s\n", str_entry);
-			entry = memblock_alloc(sizeof(*entry),
+			entry = memblock_alloc_or_panic(sizeof(*entry),
 					       SMP_CACHE_BYTES);
-			if (!entry)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, sizeof(*entry));
-			entry->buf = memblock_alloc(strlen(str_entry) + 1,
+			entry->buf = memblock_alloc_or_panic(strlen(str_entry) + 1,
 						    SMP_CACHE_BYTES);
-			if (!entry->buf)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, strlen(str_entry) + 1);
 			strcpy(entry->buf, str_entry);
 			list_add(&entry->next, &blacklisted_initcalls);
 		}
diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
index 30894d8f0a78..c9fb559a6399 100644
--- a/kernel/power/snapshot.c
+++ b/kernel/power/snapshot.c
@@ -1011,11 +1011,8 @@ void __init register_nosave_region(unsigned long start_pfn, unsigned long end_pf
 		}
 	}
 	/* This allocation cannot fail */
-	region = memblock_alloc(sizeof(struct nosave_region),
+	region = memblock_alloc_or_panic(sizeof(struct nosave_region),
 				SMP_CACHE_BYTES);
-	if (!region)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct nosave_region));
 	region->start_pfn = start_pfn;
 	region->end_pfn = end_pfn;
 	list_add_tail(®ion->list, &nosave_regions);
diff --git a/lib/cpumask.c b/lib/cpumask.c
index e77ee9d46f71..57274ba8b6d9 100644
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@ -83,10 +83,7 @@ EXPORT_SYMBOL(alloc_cpumask_var_node);
  */
 void __init alloc_bootmem_cpumask_var(cpumask_var_t *mask)
 {
-	*mask = memblock_alloc(cpumask_size(), SMP_CACHE_BYTES);
-	if (!*mask)
-		panic("%s: Failed to allocate %u bytes\n", __func__,
-		      cpumask_size());
+	*mask = memblock_alloc_or_panic(cpumask_size(), SMP_CACHE_BYTES);
 }
 
 /**
diff --git a/mm/kmsan/shadow.c b/mm/kmsan/shadow.c
index 9c58f081d84f..1bb505a08415 100644
--- a/mm/kmsan/shadow.c
+++ b/mm/kmsan/shadow.c
@@ -280,12 +280,8 @@ void __init kmsan_init_alloc_meta_for_range(void *start, void *end)
 
 	start = (void *)PAGE_ALIGN_DOWN((u64)start);
 	size = PAGE_ALIGN((u64)end - (u64)start);
-	shadow = memblock_alloc(size, PAGE_SIZE);
-	origin = memblock_alloc(size, PAGE_SIZE);
-
-	if (!shadow || !origin)
-		panic("%s: Failed to allocate metadata memory for early boot range of size %llu",
-		      __func__, size);
+	shadow = memblock_alloc_or_panic(size, PAGE_SIZE);
+	origin = memblock_alloc_or_panic(size, PAGE_SIZE);
 
 	for (u64 addr = 0; addr < size; addr += PAGE_SIZE) {
 		page = virt_to_page_or_null((char *)start + addr);
diff --git a/mm/numa.c b/mm/numa.c
index e2eec07707d1..f1787d7713a6 100644
--- a/mm/numa.c
+++ b/mm/numa.c
@@ -37,13 +37,7 @@ void __init alloc_node_data(int nid)
 void __init alloc_offline_node_data(int nid)
 {
 	pg_data_t *pgdat;
-
-	pgdat = memblock_alloc(sizeof(*pgdat), SMP_CACHE_BYTES);
-	if (!pgdat)
-		panic("Cannot allocate %zuB for node %d.\n",
-		      sizeof(*pgdat), nid);
-
-	node_data[nid] = pgdat;
+	node_data[nid] = memblock_alloc_or_panic(sizeof(*pgdat), SMP_CACHE_BYTES);
 }
 
 /* Stub functions: */
diff --git a/mm/percpu.c b/mm/percpu.c
index d8dd31a2e407..ac61e3fc5f15 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1359,10 +1359,7 @@ static struct pcpu_chunk * __init pcpu_alloc_first_chunk(unsigned long tmp_addr,
 	/* allocate chunk */
 	alloc_size = struct_size(chunk, populated,
 				 BITS_TO_LONGS(region_size >> PAGE_SHIFT));
-	chunk = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	INIT_LIST_HEAD(&chunk->list);
 
@@ -1374,24 +1371,14 @@ static struct pcpu_chunk * __init pcpu_alloc_first_chunk(unsigned long tmp_addr,
 	region_bits = pcpu_chunk_map_bits(chunk);
 
 	alloc_size = BITS_TO_LONGS(region_bits) * sizeof(chunk->alloc_map[0]);
-	chunk->alloc_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->alloc_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk->alloc_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size =
 		BITS_TO_LONGS(region_bits + 1) * sizeof(chunk->bound_map[0]);
-	chunk->bound_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->bound_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk->bound_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = pcpu_chunk_nr_blocks(chunk) * sizeof(chunk->md_blocks[0]);
-	chunk->md_blocks = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->md_blocks)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
-
+	chunk->md_blocks = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 #ifdef NEED_PCPUOBJ_EXT
 	/* first chunk is free to use */
 	chunk->obj_exts = NULL;
@@ -2595,28 +2582,16 @@ void __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
 
 	/* process group information and build config tables accordingly */
 	alloc_size = ai->nr_groups * sizeof(group_offsets[0]);
-	group_offsets = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!group_offsets)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	group_offsets = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = ai->nr_groups * sizeof(group_sizes[0]);
-	group_sizes = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!group_sizes)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	group_sizes = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = nr_cpu_ids * sizeof(unit_map[0]);
-	unit_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!unit_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	unit_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = nr_cpu_ids * sizeof(unit_off[0]);
-	unit_off = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!unit_off)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	unit_off = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	for (cpu = 0; cpu < nr_cpu_ids; cpu++)
 		unit_map[cpu] = UINT_MAX;
@@ -2685,12 +2660,9 @@ void __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
 	pcpu_free_slot = pcpu_sidelined_slot + 1;
 	pcpu_to_depopulate_slot = pcpu_free_slot + 1;
 	pcpu_nr_slots = pcpu_to_depopulate_slot + 1;
-	pcpu_chunk_lists = memblock_alloc(pcpu_nr_slots *
+	pcpu_chunk_lists = memblock_alloc_or_panic(pcpu_nr_slots *
 					  sizeof(pcpu_chunk_lists[0]),
 					  SMP_CACHE_BYTES);
-	if (!pcpu_chunk_lists)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      pcpu_nr_slots * sizeof(pcpu_chunk_lists[0]));
 
 	for (i = 0; i < pcpu_nr_slots; i++)
 		INIT_LIST_HEAD(&pcpu_chunk_lists[i]);
@@ -3155,25 +3127,19 @@ void __init __weak pcpu_populate_pte(unsigned long addr)
 	pmd_t *pmd;
 
 	if (pgd_none(*pgd)) {
-		p4d = memblock_alloc(P4D_TABLE_SIZE, P4D_TABLE_SIZE);
-		if (!p4d)
-			goto err_alloc;
+		p4d = memblock_alloc_or_panic(P4D_TABLE_SIZE, P4D_TABLE_SIZE);
 		pgd_populate(&init_mm, pgd, p4d);
 	}
 
 	p4d = p4d_offset(pgd, addr);
 	if (p4d_none(*p4d)) {
-		pud = memblock_alloc(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
-		if (!pud)
-			goto err_alloc;
+		pud = memblock_alloc_or_panic(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
 		p4d_populate(&init_mm, p4d, pud);
 	}
 
 	pud = pud_offset(p4d, addr);
 	if (pud_none(*pud)) {
-		pmd = memblock_alloc(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
-		if (!pmd)
-			goto err_alloc;
+		pmd = memblock_alloc_or_panic(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 	}
 
@@ -3181,16 +3147,11 @@ void __init __weak pcpu_populate_pte(unsigned long addr)
 	if (!pmd_present(*pmd)) {
 		pte_t *new;
 
-		new = memblock_alloc(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
-		if (!new)
-			goto err_alloc;
+		new = memblock_alloc_or_panic(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, new);
 	}
 
 	return;
-
-err_alloc:
-	panic("%s: Failed to allocate memory\n", __func__);
 }
 
 /**
@@ -3237,10 +3198,7 @@ int __init pcpu_page_first_chunk(size_t reserved_size, pcpu_fc_cpu_to_node_fn_t
 	/* unaligned allocations can't be freed, round up to page size */
 	pages_size = PFN_ALIGN(unit_pages * num_possible_cpus() *
 			       sizeof(pages[0]));
-	pages = memblock_alloc(pages_size, SMP_CACHE_BYTES);
-	if (!pages)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      pages_size);
+	pages = memblock_alloc_or_panic(pages_size, SMP_CACHE_BYTES);
 
 	/* allocate pages */
 	j = 0;
diff --git a/mm/sparse.c b/mm/sparse.c
index 13b6624d3562..133b033d0cba 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -257,10 +257,7 @@ static void __init memblocks_present(void)
 
 		size = sizeof(struct mem_section *) * NR_SECTION_ROOTS;
 		align = 1 << (INTERNODE_CACHE_SHIFT);
-		mem_section = memblock_alloc(size, align);
-		if (!mem_section)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, size, align);
+		mem_section = memblock_alloc_or_panic(size, align);
 	}
 #endif
 
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Sat Dec 21 14:10:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Dec 2024 14:10:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862456.1274122 (Exim 4.92)
	(envelope-from )
	id 1tP0BN-0003J1-Qf; Sat, 21 Dec 2024 14:10:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862456.1274122; Sat, 21 Dec 2024 14:10: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 1tP0BN-0003Iu-Nx; Sat, 21 Dec 2024 14:10:17 +0000
Received: by outflank-mailman (input) for mailman id 862456;
 Sat, 21 Dec 2024 14:10: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 1tP0BM-0003Io-PG
 for xen-devel@lists.xenproject.org; Sat, 21 Dec 2024 14:10:16 +0000
Received: from mail-oo1-f50.google.com (mail-oo1-f50.google.com
 [209.85.161.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4c283ad1-bfa5-11ef-99a3-01e77a169b0f;
 Sat, 21 Dec 2024 15:10:14 +0100 (CET)
Received: by mail-oo1-f50.google.com with SMTP id
 006d021491bc7-5f31b3db5ecso1257156eaf.0
 for ; Sat, 21 Dec 2024 06:10:14 -0800 (PST)
Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com.
 [209.85.210.41]) by smtp.gmail.com with ESMTPSA id
 586e51a60fabf-2a7d77f6475sm1523437fac.53.2024.12.21.06.10.12
 for 
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 21 Dec 2024 06:10:12 -0800 (PST)
Received: by mail-ot1-f41.google.com with SMTP id
 46e09a7af769-71ded02b779so1443596a34.2
 for ; Sat, 21 Dec 2024 06:10: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: 4c283ad1-bfa5-11ef-99a3-01e77a169b0f
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734790213; x=1735395013;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=GpBog1LJdntPo57cyHdGkHydPz04prdcJbkki5MzpWU=;
        b=Y9Rw8fFw073Hc5OGAxYS0wK+ioDb6VVHjZ1i9xADLnVF8kBksUbU46qwQClYVR3GQV
         Kw8oskTpHLfvD1EaCltt1StfTnpcVBAnCin2Lecqfjc70R5KuWpGcOZd5BOoQzvJoVBE
         eD8uB8UP6oxmXAyNbxwP0tBL9OyPd+1iB787KKwGAb3iNn1wvs5I3xE11gQGRL3kxKa7
         DBb1YYujUfHFkrHvBbj7FLKOQ5g0h1YuDS3cpQp/kCHALHgzMuorz8LNQCdTD8Uqf73Q
         BCAuZTrQjPsZ9qcLWWtf4Sq1M5PBrhpjN2OQX42Ay+yK6Bf7oShUBmDJgxtAPXw8TZ2B
         l7WQ==
X-Forwarded-Encrypted: i=1; AJvYcCUatEZOGGVlJv3VblDuaE1fv5TM9FvWZ6kk7oLq04kNn5tW50cJ7PFzJb6gL2KYIJfQTg4BzEV1I2E=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy5wfnb3w9u+xWv4o5Z1FEWOGsFfuMFwiLnqQXOyR7+8fbBQ3P2
	IKVWkmc+4iLWSeKPSs5nKlLDcj/2P9CCpxyTCq/IeekuQQIIfajZCXPbXgnK
X-Gm-Gg: ASbGncv8Q9J/IEhkETHrs5UPiu1Ry3kGc5uBH9Gva4S0emAGH1tfD39cpc0ML4V8Fia
	mpeCDb5eVeulQRlFjaVYPxdBRzwqUwMSwIOVn562Qb10E4AeGmC71f7hdY2L8TnnUM+O+ge6oN+
	QjcgX+67/ZwY978WPY+771M4EIZ+O6JHe1VAx5pldlJzWDl5mRDYttsxBS2ggGCFH1+alv48Kqs
	TuEqsBt4tz5RjhFA9ZVsGepTTyRD9WSRc+6I1sZD7MZaJqQgt+Dx945b/6JayadnaHBkyqg4r8p
	/xXajvMRoTkpm8Cj7hY=
X-Google-Smtp-Source: AGHT+IHGfbHj2RRCV9qNWtvJ6wAEwPp6E9L3SjVN8cnDX99rqmzS6pslwpBDDY0Tqgn6FWmVqiQjRQ==
X-Received: by 2002:a05:6870:8928:b0:29e:6814:19d with SMTP id 586e51a60fabf-2a7fb18a63emr3991618fac.9.1734790213108;
        Sat, 21 Dec 2024 06:10:13 -0800 (PST)
X-Forwarded-Encrypted: i=1; AJvYcCWl/5A7PtbT9OTF7aoJAenR9qKg1wmZAunJGzKu/SUje8jVr4OpCTg9+x2kHns/lc32XrfC6oIIjLY=@lists.xenproject.org
X-Received: by 2002:a05:6102:cc8:b0:4af:ef85:dae4 with SMTP id
 ada2fe7eead31-4b2cc313a2cmr7064126137.5.1734789822327; Sat, 21 Dec 2024
 06:03:42 -0800 (PST)
MIME-Version: 1.0
References: <20241221104304.2655909-1-guoweikang.kernel@gmail.com>
In-Reply-To: <20241221104304.2655909-1-guoweikang.kernel@gmail.com>
From: Geert Uytterhoeven 
Date: Sat, 21 Dec 2024 15:03:30 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: [PATCH v2] mm/memblock: Add memblock_alloc_or_panic interface
To: Guo Weikang 
Cc: Andrew Morton , Mike Rapoport , 
	Dennis Zhou , Tejun Heo , Christoph Lameter , 
	Thomas Bogendoerfer , Sam Creasey , 
	Huacai Chen , Will Deacon , 
	Catalin Marinas , Oreoluwa Babatunde , 
	rafael.j.wysocki@intel.com, Palmer Dabbelt , 
	Hanjun Guo , Easwar Hariharan , 
	Johannes Berg , Ingo Molnar , 
	Dave Hansen , Christian Brauner , 
	KP Singh , Richard Henderson , 
	Matt Turner , Russell King , 
	WANG Xuerui , Michael Ellerman , 
	Stefan Kristiansson , Stafford Horne , 
	Helge Deller , Nicholas Piggin , 
	Christophe Leroy , Naveen N Rao , 
	Madhavan Srinivasan , Geoff Levand , 
	Paul Walmsley , Palmer Dabbelt , 
	Albert Ou , Andrey Ryabinin , 
	Alexander Potapenko , Andrey Konovalov , 
	Dmitry Vyukov , Vincenzo Frascino , 
	Heiko Carstens , Vasily Gorbik , 
	Alexander Gordeev , Christian Borntraeger , 
	Sven Schnelle , Yoshinori Sato , 
	Rich Felker , John Paul Adrian Glaubitz , 
	Andreas Larsson , Richard Weinberger , 
	Anton Ivanov , Johannes Berg , 
	Thomas Gleixner , Ingo Molnar , Borislav Petkov , 
	Dave Hansen , x86@kernel.org, linux-alpha@vger.kernel.org, 
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org, 
	linux-mips@vger.kernel.org, linux-openrisc@vger.kernel.org, 
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, 
	linux-riscv@lists.infradead.org, kasan-dev@googlegroups.com, 
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, 
	sparclinux@vger.kernel.org, linux-um@lists.infradead.org, 
	linux-acpi@vger.kernel.org, xen-devel@lists.xenproject.org, 
	linux-omap@vger.kernel.org, linux-clk@vger.kernel.org, 
	devicetree@vger.kernel.org, linux-mm@kvack.org, linux-pm@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Guo,

On Sat, Dec 21, 2024 at 11:43=E2=80=AFAM Guo Weikang
 wrote:
> Before SLUB initialization, various subsystems used memblock_alloc to
> allocate memory. In most cases, when memory allocation fails, an immediat=
e
> panic is required. To simplify this behavior and reduce repetitive checks=
,
> introduce `memblock_alloc_or_panic`. This function ensures that memory
> allocation failures result in a panic automatically, improving code
> readability and consistency across subsystems that require this behavior.
>
> Signed-off-by: Guo Weikang 

Thanks for your patch!

> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -417,6 +417,20 @@ static __always_inline void *memblock_alloc(phys_add=
r_t size, phys_addr_t align)
>                                       MEMBLOCK_ALLOC_ACCESSIBLE, NUMA_NO_=
NODE);
>  }
>
> +static __always_inline void *__memblock_alloc_or_panic(phys_addr_t size,
> +                                                      phys_addr_t align,
> +                                                      const char *func)
> +{
> +       void *addr =3D memblock_alloc(size, align);
> +
> +       if (unlikely(!addr))
> +               panic("%s: Failed to allocate %llu bytes\n", func, size);
> +       return addr;
> +}

Please make this out-of-line, and move it to mm/memblock.c, so we have
just a single copy in the final binary.

> +
> +#define memblock_alloc_or_panic(size, align)    \
> +        __memblock_alloc_or_panic(size, align, __func__)
> +
>  static inline void *memblock_alloc_raw(phys_addr_t size,
>                                                phys_addr_t align)
>  {
> diff --git a/init/main.c b/init/main.c

Gr{oetje,eeting}s,

                        Geert

--=20
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org

In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
                                -- Linus Torvalds


From xen-devel-bounces@lists.xenproject.org Sat Dec 21 19:45:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Dec 2024 19:45:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862508.1274144 (Exim 4.92)
	(envelope-from )
	id 1tP5Pv-00065K-2v; Sat, 21 Dec 2024 19:45:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862508.1274144; Sat, 21 Dec 2024 19:45: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 1tP5Pu-00064F-UV; Sat, 21 Dec 2024 19:45:38 +0000
Received: by outflank-mailman (input) for mailman id 862508;
 Sat, 21 Dec 2024 18:26: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 1tP4BN-0005uw-M1
 for xen-devel@lists.xenproject.org; Sat, 21 Dec 2024 18:26:33 +0000
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com
 [2a00:1450:4864:20::12c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 19da3029-bfc9-11ef-99a3-01e77a169b0f;
 Sat, 21 Dec 2024 19:26:31 +0100 (CET)
Received: by mail-lf1-x12c.google.com with SMTP id
 2adb3069b0e04-53df6322ea7so3805420e87.0
 for ; Sat, 21 Dec 2024 10:26: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: 19da3029-bfc9-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734805591; x=1735410391; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=Ug+2S38akg/OGmu5JFa1fwvkZP6FmAvIFxWtE1sypCI=;
        b=P/OdeVdh1j99xVvKwf0QPaIZsIpn+rDRKOD6Mz+Uhmv3sHcQDXQJFhcjo88NHCv0ZN
         No1a+CXh9VwDUAdEZ9eal8w7/QyAUvV/X6mcOO5q7+8623GlKbF6ckpNeX//gWQzna8V
         gTJ8ysoSVaOuLGIOenvcowZyBeGjcYNarbbQ8uKe6OM1ZhtYya5Ru2T/iCiRDw59AuqL
         X6qVAv59NKVx7FeG9NZLT/5JqH97fPboOblJc78JYtAPnc23h7jqflzVvQwNuWrT983J
         UGPyl4F6Ea1xd6jVQU3tfXocWJnUmQ/1vp56jzHrbVuOc9947rUdh0ZW/qs6g+v/BgTc
         X7GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734805591; x=1735410391;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Ug+2S38akg/OGmu5JFa1fwvkZP6FmAvIFxWtE1sypCI=;
        b=FfhFHgELzyZ2cTOLfKWV1qRDHWiocWfHJN/JxBHOcNCoCyPZqwy3ZN+BD5Hf22bbQT
         7B23n5TeBadc5nida1LPk3p9797CnNksPtsnbVIOl7HMuiN7sH8BsIXKN3Si+G7748F9
         TSJizaTpyHbYWxFMwByDavXz0Q34H1lW8zkG2AUhx7cvASxI5EA+iWCX04qocHvCe5AC
         3bRsM9jxWVrAWj1EoO4CfTV84tdxxbzt+B57Ng4e14KtizCW2ukKpQlpd0+VLqhOULSX
         VVrTyhfIV07PIKx2LCiNZyTl1a/ywod+XhYlwqS+Jal+lC3Nl6D+gHazr2L3l6XMA4o0
         saDw==
X-Forwarded-Encrypted: i=1; AJvYcCVcrwrcZRGhZGePh0hn9hEY84kwrgQAqV1yXsqaSPyCqyrXJdJnIE4SB9F4GfTAnKIxyTRwat8RnmY=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy8a7J7ONqUUaa0JIaZMSE7gZvT0xcN6DoT/HF18zmofBpwo2nO
	0uSMYZaCyOUEFog5ooDjscGmlLYGs6nsxx0c0C9e/BjJvDdf5tB4nA0Bp4bpz3vRqde2qdtMTDL
	NrZoLUgzC91z++XIJEmU2zHJTn7k=
X-Gm-Gg: ASbGncu4zkUdQUjO6TSqDV/M2H8R0i34leeHe6tKI505QdmM6lu09yx+3yi2Ve4xi8I
	Da9W+ltoDMRW4HDfYUgiZbE5oRs1ALhFFezQ9AfCMKaCKm0Z9kg8oMtxIo7TN/qbLzBOW
X-Google-Smtp-Source: AGHT+IG/uxf+62mSAJV0vjaX5OOSPPXiQApbIfNWpW/j/U/azuxZEVr6AdlTIyiVOEKxrku3T2iYp/pg0hA3s2YrLws=
X-Received: by 2002:a05:6512:23a0:b0:540:75d3:95a4 with SMTP id
 2adb3069b0e04-54229538b24mr2653607e87.17.1734805590494; Sat, 21 Dec 2024
 10:26:30 -0800 (PST)
MIME-Version: 1.0
References: 
 <099d3a80-4fdb-49a7-9fd0-207d7386551f@citrix.com> 
 
 <90640a5d-ff17-4555-adc6-ae9e21e24ebd@citrix.com> 
 <43166e29-ff2d-4a9d-8c1b-41b5e247974b@citrix.com> 
In-Reply-To: 
Reply-To: sedat.dilek@gmail.com
From: Sedat Dilek 
Date: Sat, 21 Dec 2024 19:25:54 +0100
Message-ID: 
Subject: Re: [Linux-6.12.y] XEN: CVE-2024-53241 / XSA-466 and Clang-kCFI
To: Andrew Cooper 
Cc: Juergen Gross , Peter Zijlstra , 
	Sami Tolvanen , Jan Beulich , 
	Josh Poimboeuf , Linus Torvalds , 
	Greg Kroah-Hartman , Sasha Levin , 
	linux-kernel@vger.kernel.org, stable@vger.kernel.org, 
	Kees Cook , Nathan Chancellor , llvm@lists.linux.dev, 
	xen-devel 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 21, 2024 at 7:17=E2=80=AFPM Sedat Dilek =
 wrote:
>
> On Fri, Dec 20, 2024 at 2:39=E2=80=AFAM Andrew Cooper  wrote:
> >
> > On 20/12/2024 12:27 am, Sedat Dilek wrote:
> > > On Fri, Dec 20, 2024 at 12:26=E2=80=AFAM Andrew Cooper
> > >  wrote:
> > >> On 19/12/2024 11:10 pm, Sedat Dilek wrote:
> > >>> On Thu, Dec 19, 2024 at 6:07=E2=80=AFPM Sedat Dilek  wrote:
> > >>>> On Thu, Dec 19, 2024 at 5:44=E2=80=AFPM Andrew Cooper  wrote:
> > >>>>> On 19/12/2024 4:14 pm, Sedat Dilek wrote:
> > >>>>>> Hi,
> > >>>>>>
> > >>>>>> Linux v6.12.6 will include XEN CVE fixes from mainline.
> > >>>>>>
> > >>>>>> Here, I use Debian/unstable AMD64 and the SLIM LLVM toolchain 19=
.1.x
> > >>>>>> from kernel.org.
> > >>>>>>
> > >>>>>> What does it mean in ISSUE DESCRIPTION...
> > >>>>>>
> > >>>>>> Furthermore, the hypercall page has no provision for Control-flo=
w
> > >>>>>> Integrity schemes (e.g. kCFI/CET-IBT/FineIBT), and will simply
> > >>>>>> malfunction in such configurations.
> > >>>>>>
> > >>>>>> ...when someone uses Clang-kCFI?
> > >>>>> The hypercall page has functions of the form:
> > >>>>>
> > >>>>>     MOV $x, %eax
> > >>>>>     VMCALL / VMMCALL / SYSCALL
> > >>>>>     RET
> > >>>>>
> > >>>>> There are no ENDBR instructions, and no prologue/epilogue for has=
h-based
> > >>>>> CFI schemes.
> > >>>>>
> > >>>>> This is because it's code provided by Xen, not code provided by L=
inux.
> > >>>>>
> > >>>>> The absence of ENDBR instructions will yield #CP when CET-IBT is =
active,
> > >>>>> and the absence of hash prologue/epilogue lets the function be us=
ed in a
> > >>>>> type-confused manor that CFI should have caught.
> > >>>>>
> > >>>>> ~Andrew
> > >>>> Thanks for the technical explanation, Andrew.
> > >>>>
> > >>>> Hope that helps the folks of "CLANG CONTROL FLOW INTEGRITY SUPPORT=
".
> > >>>>
> > >>>> I am not an active user of XEN in the Linux-kernel but I am willin=
g to
> > >>>> test when Linux v6.12.6 is officially released and give feedback.
> > >>>>
> > >>> https://wiki.xenproject.org/wiki/Testing_Xen#Presence_test
> > >>> https://wiki.xenproject.org/wiki/Testing_Xen#Commands_for_presence_=
testing
> > >>>
> > >>> # apt install -t unstable xen-utils-4.17 -y
> > >>>
> > >>> # xl list
> > >>> Name                                        ID   Mem VCPUs      Sta=
te   Time(s)
> > >>> Domain-0                                     0  7872     4     r---=
--     398.2
> > >>>
> > >>> Some basic tests LGTM - see also attached stuff.
> > >>>
> > >>> If you have any tests to recommend, let me know.
> > >> That itself is good enough as a smoke test.  Thankyou for trying it =
out.
> > >>
> > >> If you want something a bit more thorough, try
> > >> https://xenbits.xen.org/docs/xtf/  (Xen's self-tests)
> > >>
> > >> Grab and build it, and `./xtf-runner -aqq --host` will run a variety=
 of
> > >> extra codepaths in dom0, without the effort of making/running full g=
uests.
> > >>
> > >> ~Andrew
> > > Run on Debian 6.12.5 and my selfmade 6.12.5 and 6.12.6.
> > > All tests lead to a reboot in case of Debian or in my kernels to a sh=
utdown.
> > >
> > > Can you recommend a specific test?
> >
> > Oh, that's distinctly less good.
> >
> > Start with just "example".  It's literally a hello world microkernel,
> > but the symptoms you're seeing is a dom0 crash, so it will likely
> > provoke it.
> >
> > Do you have serial to the machine?  If so, boot Xen with `console=3Dcom=
1
> > com1=3D115200,8n1` (or com2, as appropriate).
> >
> > If not and you've only got a regular screen, boot Xen with `vga=3D,keep
> > noreboot` (comma is important) which might leave enough information on
> > screen to get an idea of what's going on.
> >
>
> YES
>
> # xl info | grep xen_commandline
> xen_commandline        : placeholder vga=3D,keep noreboot
>
> > Full command line docs at
> > https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html
> >
> > > dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner --list functional xsa |=
 grep xsa-4
> > > test-pv64-xsa-444
> > > test-hvm64-xsa-451
> > > test-hvm64-xsa-454
> > >
> > > Is there no xsa-466 test?
> >
> > No.  XSA-466 is really "well don't do that then if it matters".
> >
> > More generally, not all XSAs are amenable to testing in this way.
> >
> > ~Andrew
>
> On Debian 6.12.6 kernel the TESTS stop with test-hvm64-xsa-454 -
> machine freezes - hard reboot.
>
> dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner -a --host
>
> root@iniza:/var/log/xen# LC_ALL=3DC ls -alth | head -20
> total 1.7M
> -rw-r--r--  1 root adm  1008K Dec 21 19:10 xenstored-access.log
> drwxr-xr-x 16 root root  4.0K Dec 21 18:59 ..
> -rw-r--r--  1 root adm     32 Dec 21 18:58 xenstored.log
> drwxr-s---  2 root adm    36K Dec 21 18:58 .
> -rw-r--r--  1 root adm    229 Dec 21 18:53 xl-test-hvm64-xsa-317.log
> -rw-r--r--  1 root adm     67 Dec 21 18:53 xl-test-hvm64-xsa-454.log
> -rw-r--r--  1 root adm    145 Dec 21 18:53 qemu-dm-test-hvm64-xsa-454.log
> -rw-r--r--  1 root adm    232 Dec 21 18:53 qemu-dm-test-hvm64-xsa-451.log
> -rw-r--r--  1 root adm    211 Dec 21 18:53 xl-test-hvm64-xsa-451.log
> -rw-r--r--  1 root adm    232 Dec 21 18:53 xl-test-hvm32pse-xsa-317.log
> -rw-r--r--  1 root adm    228 Dec 21 18:53 xl-test-pv64-xsa-444.log
> -rw-r--r--  1 root adm    228 Dec 21 18:53 xl-test-pv64-xsa-339.log
> -rw-r--r--  1 root adm    228 Dec 21 18:53 xl-test-pv64-xsa-333.log
> -rw-r--r--  1 root adm    228 Dec 21 18:53 xl-test-pv64-xsa-317.log
> -rw-r--r--  1 root adm    232 Dec 21 18:53 qemu-dm-test-hvm64-xsa-317.log
> -rw-r--r--  1 root adm    232 Dec 21 18:53 xl-test-hvm32pae-xsa-317.log
> -rw-r--r--  1 root adm    232 Dec 21 18:53 qemu-dm-test-hvm32pse-xsa-317.=
log
> -rw-r--r--  1 root adm    229 Dec 21 18:53 xl-test-hvm32-xsa-317.log
> -rw-r--r--  1 root adm    232 Dec 21 18:53 qemu-dm-test-hvm32pae-xsa-317.=
log
>
> root@iniza:/var/log/xen# cat qemu-dm-test-hvm64-xsa-454.log
> VNC server running on 127.0.0.1:5900
> xen-qemu-system-i386: failed to create 'console' device '0': declining to=
 handle
> console type 'xenconsoled'
>
> root@iniza:/var/log/xen# cat xl-test-hvm64-xsa-454.log
> Waiting for domain test-hvm64-xsa-454 (domid 94) to die [pid 4686]
>
> -Sedat-

With...

dileks@iniza:~/src/xtf/git$ mv tests/xsa-454 ../
dileks@iniza:~/src/xtf/git$ mv tests/xsa-consoleio-write ../

Combined test results:
test-hvm32-cpuid-faulting                SKIP
test-hvm32pae-cpuid-faulting             SKIP
test-hvm32pse-cpuid-faulting             SKIP
test-hvm64-cpuid-faulting                SKIP
test-pv64-cpuid-faulting                 SKIP
test-hvm64-fpu-exception-emulation       SKIP
test-hvm32-invlpg~hap                    SUCCESS
test-hvm32-invlpg~shadow                 SUCCESS
test-hvm32pae-invlpg~hap                 SUCCESS
test-hvm32pae-invlpg~shadow              SUCCESS
test-hvm64-invlpg~hap                    SUCCESS
test-hvm64-invlpg~shadow                 SUCCESS
test-hvm64-lbr-tsx-vmentry               SUCCESS
test-hvm32-livepatch-priv-check          SUCCESS
test-hvm64-livepatch-priv-check          SUCCESS
test-pv64-livepatch-priv-check           SUCCESS
test-hvm32-lm-ts                         SUCCESS
test-hvm64-lm-ts                         SUCCESS
test-hvm32pae-memop-seg                  SUCCESS
test-hvm64-memop-seg                     SUCCESS
test-pv64-memop-seg                      SUCCESS
test-hvm32pae-nmi-taskswitch-priv        SUCCESS
test-pv64-pv-fsgsbase                    SKIP
test-pv64-pv-iopl~hypercall              SUCCESS
test-pv64-pv-iopl~vmassist               SUCCESS
test-hvm32-swint-emulation               SKIP
test-hvm32pae-swint-emulation            SKIP
test-hvm32pse-swint-emulation            SKIP
test-hvm64-swint-emulation               SKIP
test-hvm32-umip                          SKIP
test-hvm64-umip                          SKIP
test-hvm32-xsa-122                       SUCCESS
test-hvm32pae-xsa-122                    SUCCESS
test-hvm32pse-xsa-122                    SUCCESS
test-hvm64-xsa-122                       SUCCESS
test-pv64-xsa-122                        SUCCESS
test-hvm32-xsa-123                       SKIP
test-pv64-xsa-167                        SKIP
test-hvm64-xsa-168~shadow                SUCCESS
test-hvm64-xsa-170                       SKIP
test-hvm64-xsa-173~shadow                SUCCESS
test-pv64-xsa-182                        SUCCESS
test-hvm32-xsa-186                       SKIP
test-hvm64-xsa-186                       SKIP
test-hvm32-xsa-188                       SUCCESS
test-hvm32pae-xsa-188                    SUCCESS
test-hvm32pse-xsa-188                    SUCCESS
test-hvm64-xsa-188                       SUCCESS
test-pv64-xsa-188                        SUCCESS
test-hvm32-xsa-191                       SKIP
test-hvm32-xsa-192                       SUCCESS
test-pv64-xsa-193                        SUCCESS
test-hvm64-xsa-195                       SUCCESS
test-hvm64-xsa-196                       SKIP
test-hvm32-xsa-200                       SKIP
test-hvm32-xsa-203                       SKIP
test-hvm64-xsa-204                       SKIP
test-pv64-xsa-212                        SUCCESS
test-pv64-xsa-213                        SUCCESS
test-hvm64-xsa-221                       SUCCESS
test-pv64-xsa-221                        SUCCESS
test-pv64-xsa-224                        SUCCESS
test-pv64-xsa-227                        SUCCESS
test-hvm64-xsa-231                       SUCCESS
test-pv64-xsa-231                        SUCCESS
test-hvm64-xsa-232                       SUCCESS
test-pv64-xsa-232                        SUCCESS
test-pv64-xsa-234                        SUCCESS
test-hvm32-xsa-239                       SUCCESS
test-pv64-xsa-255                        SUCCESS
test-pv64-xsa-259                        SUCCESS
test-pv64-xsa-260                        SUCCESS
test-hvm64-xsa-261                       SUCCESS
test-pv64-xsa-265                        SUCCESS
test-hvm64-xsa-269                       SUCCESS
test-hvm64-xsa-277                       SUCCESS
test-hvm64-xsa-278                       SUCCESS
test-pv64-xsa-279                        SUCCESS
test-pv64-xsa-286                        SUCCESS
test-pv64-xsa-296                        SUCCESS
test-pv64-xsa-298                        SUCCESS
test-hvm64-xsa-304                       SUCCESS
test-hvm64-xsa-308                       SUCCESS
test-pv64-xsa-316                        SUCCESS
test-hvm32-xsa-317                       SUCCESS
test-hvm32pae-xsa-317                    SUCCESS
test-hvm32pse-xsa-317                    SUCCESS
test-hvm64-xsa-317                       SUCCESS
test-pv64-xsa-317                        SUCCESS
test-pv64-xsa-333                        SUCCESS
test-pv64-xsa-339                        SUCCESS
test-pv64-xsa-444                        SKIP
test-hvm64-xsa-451                       SKIP

-Sedat-


From xen-devel-bounces@lists.xenproject.org Sat Dec 21 19:45:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Dec 2024 19:45:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862506.1274137 (Exim 4.92)
	(envelope-from )
	id 1tP5Pu-0005zp-Ps; Sat, 21 Dec 2024 19:45:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862506.1274137; Sat, 21 Dec 2024 19:45: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 1tP5Pu-0005yf-Ld; Sat, 21 Dec 2024 19:45:38 +0000
Received: by outflank-mailman (input) for mailman id 862506;
 Sat, 21 Dec 2024 18:17: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 1tP42s-0004si-5H
 for xen-devel@lists.xenproject.org; Sat, 21 Dec 2024 18:17:46 +0000
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com
 [2a00:1450:4864:20::129])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id df5154be-bfc7-11ef-99a3-01e77a169b0f;
 Sat, 21 Dec 2024 19:17:43 +0100 (CET)
Received: by mail-lf1-x129.google.com with SMTP id
 2adb3069b0e04-54025432becso3109505e87.1
 for ; Sat, 21 Dec 2024 10:17: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: df5154be-bfc7-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734805063; x=1735409863; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=Gww25uCrGB4X+QcRFH3IhcXrxha4JrH7h8gAWHNHg+E=;
        b=JCiPyjcyChvHvNfITu7HOyQns1ULZItXrXwUP6hx5A2GsCeVsddFExUoxpiWWxpEJt
         0MtKVX7marE0TOkC3oDBbR7BPM/Y9IByUhCyu6qpfPOwNnrn16f3BX/+viy4Kv1kRZfB
         3sj/VhkpO1U7Tp7EvlUkczHxG+XO4wgGOqX5WNLvG//ldWkGuIEEtz6C4A+iMNCAoCjM
         kvmhnRm5NMtFpruLzmB+zUY2PuYQT0AiM/8NyPWZ1e0/uvm3GE6sAAxHmnWwKhaIi2oY
         Kn3KWag5ZuSMiOPgL3d8Q+5ukHxScsBwryKJkm05eLBTtDjrmPUDvfAclY+m63rfMSH+
         LvLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734805063; x=1735409863;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Gww25uCrGB4X+QcRFH3IhcXrxha4JrH7h8gAWHNHg+E=;
        b=mXQbf4UThKQ0S2ZcUp3zmnWh6CqkP2+8xhr76eeyx/MTLjI/W3QVI5ns2xI1UnC8Bj
         BYo21NXZnt2B7O/PbNS48ryTjDv39e5PKRvvlUYCvMKlupZX31PdvVOu2fEnLo/j9rI4
         rPuF5NsuNIR8HBveadDskxq5KfF/TIZyvZlZoYAbDesTcby9b9PhyeaTPv/JLQgNnU9m
         p4PupgLOvF3WhDTcuszHOqMmxYf8i8+zLN88fi1ScaRF/X4u78MuPt+yidZthEMG8D3G
         tk00lPsXaoucZf+QZWL5IfbEnP3uEBLzwIb7CUmd7xPuAYXmobG1A2WZE5h2oPGaL7Yq
         QXiw==
X-Forwarded-Encrypted: i=1; AJvYcCXrM+wVIIwYchCgUiW/hKZ9RySngqr++7ntPpr0hLmUi/QBfFeRu5Io3WJMNWME0YKTFFRQfWyxuM4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyZS0JOV5jbw3wPmvA1e1zqYJLhv+sJV07Ng5dJdPHngWfiCtSq
	gNazF8NQX8dcxDOpgwrDNCXnko1x3w8BEBrgfr754JalueZOz+hApcANbTPwjImsPSsBH9Vs/TB
	8i3jZ6MqnNl6wWjs7NS+z6ivdTW8=
X-Gm-Gg: ASbGncvws2tJJ//sFSEd5KaxVfh2zFmZkcHG8cjmEGD4qLmrx59S00UVbtJqrbqEQhD
	5L+e3SzTrahHlCjz+cgXk4q3jHa4FO3TT4F6v0DCupu3EO2XNy4iSKx7M1MxOjbp2rRN7
X-Google-Smtp-Source: AGHT+IFbWOqrEDILJB7D/dZAXmHjad5/5gydpfde4ub7xLCzRPKhGigQWT8r2WIqnERkBGgVj5RjNd5ekYb5iXu0I/M=
X-Received: by 2002:a05:6512:683:b0:542:2f0f:66d9 with SMTP id
 2adb3069b0e04-5422f0f69d8mr919287e87.16.1734805062927; Sat, 21 Dec 2024
 10:17:42 -0800 (PST)
MIME-Version: 1.0
References: 
 <099d3a80-4fdb-49a7-9fd0-207d7386551f@citrix.com> 
 
 <90640a5d-ff17-4555-adc6-ae9e21e24ebd@citrix.com> 
 <43166e29-ff2d-4a9d-8c1b-41b5e247974b@citrix.com>
In-Reply-To: <43166e29-ff2d-4a9d-8c1b-41b5e247974b@citrix.com>
Reply-To: sedat.dilek@gmail.com
From: Sedat Dilek 
Date: Sat, 21 Dec 2024 19:17:05 +0100
Message-ID: 
Subject: Re: [Linux-6.12.y] XEN: CVE-2024-53241 / XSA-466 and Clang-kCFI
To: Andrew Cooper 
Cc: Juergen Gross , Peter Zijlstra , 
	Sami Tolvanen , Jan Beulich , 
	Josh Poimboeuf , Linus Torvalds , 
	Greg Kroah-Hartman , Sasha Levin , 
	linux-kernel@vger.kernel.org, stable@vger.kernel.org, 
	Kees Cook , Nathan Chancellor , llvm@lists.linux.dev, 
	xen-devel 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 20, 2024 at 2:39=E2=80=AFAM Andrew Cooper  wrote:
>
> On 20/12/2024 12:27 am, Sedat Dilek wrote:
> > On Fri, Dec 20, 2024 at 12:26=E2=80=AFAM Andrew Cooper
> >  wrote:
> >> On 19/12/2024 11:10 pm, Sedat Dilek wrote:
> >>> On Thu, Dec 19, 2024 at 6:07=E2=80=AFPM Sedat Dilek  wrote:
> >>>> On Thu, Dec 19, 2024 at 5:44=E2=80=AFPM Andrew Cooper  wrote:
> >>>>> On 19/12/2024 4:14 pm, Sedat Dilek wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Linux v6.12.6 will include XEN CVE fixes from mainline.
> >>>>>>
> >>>>>> Here, I use Debian/unstable AMD64 and the SLIM LLVM toolchain 19.1=
.x
> >>>>>> from kernel.org.
> >>>>>>
> >>>>>> What does it mean in ISSUE DESCRIPTION...
> >>>>>>
> >>>>>> Furthermore, the hypercall page has no provision for Control-flow
> >>>>>> Integrity schemes (e.g. kCFI/CET-IBT/FineIBT), and will simply
> >>>>>> malfunction in such configurations.
> >>>>>>
> >>>>>> ...when someone uses Clang-kCFI?
> >>>>> The hypercall page has functions of the form:
> >>>>>
> >>>>>     MOV $x, %eax
> >>>>>     VMCALL / VMMCALL / SYSCALL
> >>>>>     RET
> >>>>>
> >>>>> There are no ENDBR instructions, and no prologue/epilogue for hash-=
based
> >>>>> CFI schemes.
> >>>>>
> >>>>> This is because it's code provided by Xen, not code provided by Lin=
ux.
> >>>>>
> >>>>> The absence of ENDBR instructions will yield #CP when CET-IBT is ac=
tive,
> >>>>> and the absence of hash prologue/epilogue lets the function be used=
 in a
> >>>>> type-confused manor that CFI should have caught.
> >>>>>
> >>>>> ~Andrew
> >>>> Thanks for the technical explanation, Andrew.
> >>>>
> >>>> Hope that helps the folks of "CLANG CONTROL FLOW INTEGRITY SUPPORT".
> >>>>
> >>>> I am not an active user of XEN in the Linux-kernel but I am willing =
to
> >>>> test when Linux v6.12.6 is officially released and give feedback.
> >>>>
> >>> https://wiki.xenproject.org/wiki/Testing_Xen#Presence_test
> >>> https://wiki.xenproject.org/wiki/Testing_Xen#Commands_for_presence_te=
sting
> >>>
> >>> # apt install -t unstable xen-utils-4.17 -y
> >>>
> >>> # xl list
> >>> Name                                        ID   Mem VCPUs      State=
   Time(s)
> >>> Domain-0                                     0  7872     4     r-----=
     398.2
> >>>
> >>> Some basic tests LGTM - see also attached stuff.
> >>>
> >>> If you have any tests to recommend, let me know.
> >> That itself is good enough as a smoke test.  Thankyou for trying it ou=
t.
> >>
> >> If you want something a bit more thorough, try
> >> https://xenbits.xen.org/docs/xtf/  (Xen's self-tests)
> >>
> >> Grab and build it, and `./xtf-runner -aqq --host` will run a variety o=
f
> >> extra codepaths in dom0, without the effort of making/running full gue=
sts.
> >>
> >> ~Andrew
> > Run on Debian 6.12.5 and my selfmade 6.12.5 and 6.12.6.
> > All tests lead to a reboot in case of Debian or in my kernels to a shut=
down.
> >
> > Can you recommend a specific test?
>
> Oh, that's distinctly less good.
>
> Start with just "example".  It's literally a hello world microkernel,
> but the symptoms you're seeing is a dom0 crash, so it will likely
> provoke it.
>
> Do you have serial to the machine?  If so, boot Xen with `console=3Dcom1
> com1=3D115200,8n1` (or com2, as appropriate).
>
> If not and you've only got a regular screen, boot Xen with `vga=3D,keep
> noreboot` (comma is important) which might leave enough information on
> screen to get an idea of what's going on.
>

YES

# xl info | grep xen_commandline
xen_commandline        : placeholder vga=3D,keep noreboot

> Full command line docs at
> https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html
>
> > dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner --list functional xsa | g=
rep xsa-4
> > test-pv64-xsa-444
> > test-hvm64-xsa-451
> > test-hvm64-xsa-454
> >
> > Is there no xsa-466 test?
>
> No.  XSA-466 is really "well don't do that then if it matters".
>
> More generally, not all XSAs are amenable to testing in this way.
>
> ~Andrew

On Debian 6.12.6 kernel the TESTS stop with test-hvm64-xsa-454 -
machine freezes - hard reboot.

dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner -a --host

root@iniza:/var/log/xen# LC_ALL=3DC ls -alth | head -20
total 1.7M
-rw-r--r--  1 root adm  1008K Dec 21 19:10 xenstored-access.log
drwxr-xr-x 16 root root  4.0K Dec 21 18:59 ..
-rw-r--r--  1 root adm     32 Dec 21 18:58 xenstored.log
drwxr-s---  2 root adm    36K Dec 21 18:58 .
-rw-r--r--  1 root adm    229 Dec 21 18:53 xl-test-hvm64-xsa-317.log
-rw-r--r--  1 root adm     67 Dec 21 18:53 xl-test-hvm64-xsa-454.log
-rw-r--r--  1 root adm    145 Dec 21 18:53 qemu-dm-test-hvm64-xsa-454.log
-rw-r--r--  1 root adm    232 Dec 21 18:53 qemu-dm-test-hvm64-xsa-451.log
-rw-r--r--  1 root adm    211 Dec 21 18:53 xl-test-hvm64-xsa-451.log
-rw-r--r--  1 root adm    232 Dec 21 18:53 xl-test-hvm32pse-xsa-317.log
-rw-r--r--  1 root adm    228 Dec 21 18:53 xl-test-pv64-xsa-444.log
-rw-r--r--  1 root adm    228 Dec 21 18:53 xl-test-pv64-xsa-339.log
-rw-r--r--  1 root adm    228 Dec 21 18:53 xl-test-pv64-xsa-333.log
-rw-r--r--  1 root adm    228 Dec 21 18:53 xl-test-pv64-xsa-317.log
-rw-r--r--  1 root adm    232 Dec 21 18:53 qemu-dm-test-hvm64-xsa-317.log
-rw-r--r--  1 root adm    232 Dec 21 18:53 xl-test-hvm32pae-xsa-317.log
-rw-r--r--  1 root adm    232 Dec 21 18:53 qemu-dm-test-hvm32pse-xsa-317.lo=
g
-rw-r--r--  1 root adm    229 Dec 21 18:53 xl-test-hvm32-xsa-317.log
-rw-r--r--  1 root adm    232 Dec 21 18:53 qemu-dm-test-hvm32pae-xsa-317.lo=
g

root@iniza:/var/log/xen# cat qemu-dm-test-hvm64-xsa-454.log
VNC server running on 127.0.0.1:5900
xen-qemu-system-i386: failed to create 'console' device '0': declining to h=
andle
console type 'xenconsoled'

root@iniza:/var/log/xen# cat xl-test-hvm64-xsa-454.log
Waiting for domain test-hvm64-xsa-454 (domid 94) to die [pid 4686]

-Sedat-


From xen-devel-bounces@lists.xenproject.org Sat Dec 21 19:45:51 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Dec 2024 19:45:51 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862496.1274133 (Exim 4.92)
	(envelope-from )
	id 1tP5Pu-0005yI-Jw; Sat, 21 Dec 2024 19:45:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862496.1274133; Sat, 21 Dec 2024 19:45: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 1tP5Pu-0005yA-EI; Sat, 21 Dec 2024 19:45:38 +0000
Received: by outflank-mailman (input) for mailman id 862496;
 Sat, 21 Dec 2024 17:06: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 1tP2wB-0005v4-Iq
 for xen-devel@lists.xenproject.org; Sat, 21 Dec 2024 17:06:47 +0000
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com
 [2a00:1450:4864:20::12a])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f4c4ccf0-bfbd-11ef-99a3-01e77a169b0f;
 Sat, 21 Dec 2024 18:06:45 +0100 (CET)
Received: by mail-lf1-x12a.google.com with SMTP id
 2adb3069b0e04-5401b7f7141so2510770e87.1
 for ; Sat, 21 Dec 2024 09:06: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: f4c4ccf0-bfbd-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734800804; x=1735405604; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=agKbG4Ad2aFh5DQ9Ty8+oto7J07OzvutBur24QnJNbs=;
        b=UclJrBDpxLXUs9rBR8/MQN8dVn5FR2VzRjh98xes0WkBosmjSoe0Ci2ruT8tHeMCgc
         WJJevP9YUBx0wEcjXtPhFijHQm9yZlexGeKaxanm+LEnnsa0uOnIbIec+fQU+pvRUZCA
         XYnGq5S/T51fELtWTluFB06CzmtIWTnToc615yTrkO810IOlqvsOXE6CaLPBgryD4YMY
         uhJUJC5kCStUM+zA6s4PRbSV3kMzVAZSUXVcoUCd/X8FBinzRfIWP5E+fRG960taiZ8o
         0KA6bBq0WBWt69BtL99RR94sjtG3CzfnwGR3eg//EzRxwzF/FEHqM4AeKTOLBiYS3N/h
         biZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734800804; x=1735405604;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=agKbG4Ad2aFh5DQ9Ty8+oto7J07OzvutBur24QnJNbs=;
        b=OSUZH9CFnaNyKN1Id6JYTvyAu30C4cwLgRjTc/V5iKdgeX05R/bc4NTd9w2KnlaV8A
         V3Sy6qXvgGWfB/l75LQpB2YIRqpRLkHdYtoDvP2nrxd45Vwv+KR+CA5T6CkZjMjJRrmL
         zitLMLTJmrbHNhxf7nPDFqFrgmpMcqprS2chzASMDdeH8RjWqYhgnT1FhFNO5aScVjLH
         PzokdgGsXK0PeT7tngG10n9UVP8t6lo0mWAnCrl1S2JlswPxSrqrrjhZVpEFf9i+UVNj
         MfKc23fQ4xlOLgHDSoke4mVFzi5zBgbWmHL9d4y87hzSoeLVePeHR5qczdepSTVDXaNl
         IOSA==
X-Forwarded-Encrypted: i=1; AJvYcCVkqOR94rENKE4kBVBgGXBC48k03Be6pLR/8yxQQQe76kDSBNUsny/8QBjrRFycdoAcIuEiqccPICE=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy8gF0fq+thwNk5QyAtF4S8rOK+IuTD4hn6ImRPKrsnJNoTFFTu
	Ujw5Vgif7+7CW8KJCg4EPCE9ykL5c9mfoPthJ+ctlgUYfVPWPHYhHT2pbVu5ptaOcWbrT7gLb+A
	TV6Y+fz9Ni+8+3g6j+0D19c67sas=
X-Gm-Gg: ASbGncujW12ynu1RNA8ALruuSCVui5MDd7nkCHuG5i0XWAGiaDQ/wAVSr5iIg9VdJtP
	yqDTlG89a2ISWBTxyXHHuplddtxaqDarZBHk2+EJM12hWJRWGXW+yx4+jj8vYoqDlv+Qu
X-Google-Smtp-Source: AGHT+IFlbPcGmfsM9lCdXkpNmrdsNPjnuj/3oeIGySw+8+ouW9qKDdkS6zFmZVV0L0qLBb8weZW1jPVbzwqmFTzG3VQ=
X-Received: by 2002:a05:6512:2214:b0:53e:38df:672a with SMTP id
 2adb3069b0e04-5422956289amr2032769e87.36.1734800803975; Sat, 21 Dec 2024
 09:06:43 -0800 (PST)
MIME-Version: 1.0
References: 
 <099d3a80-4fdb-49a7-9fd0-207d7386551f@citrix.com> 
 
 <90640a5d-ff17-4555-adc6-ae9e21e24ebd@citrix.com> 
 <43166e29-ff2d-4a9d-8c1b-41b5e247974b@citrix.com>
In-Reply-To: <43166e29-ff2d-4a9d-8c1b-41b5e247974b@citrix.com>
Reply-To: sedat.dilek@gmail.com
From: Sedat Dilek 
Date: Sat, 21 Dec 2024 18:06:06 +0100
Message-ID: 
Subject: Re: [Linux-6.12.y] XEN: CVE-2024-53241 / XSA-466 and Clang-kCFI
To: Andrew Cooper 
Cc: Juergen Gross , Peter Zijlstra , 
	Sami Tolvanen , Jan Beulich , 
	Josh Poimboeuf , Linus Torvalds , 
	Greg Kroah-Hartman , Sasha Levin , 
	linux-kernel@vger.kernel.org, stable@vger.kernel.org, 
	Kees Cook , Nathan Chancellor , llvm@lists.linux.dev, 
	xen-devel 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 20, 2024 at 2:39=E2=80=AFAM Andrew Cooper  wrote:
>
> On 20/12/2024 12:27 am, Sedat Dilek wrote:
> > On Fri, Dec 20, 2024 at 12:26=E2=80=AFAM Andrew Cooper
> >  wrote:
> >> On 19/12/2024 11:10 pm, Sedat Dilek wrote:
> >>> On Thu, Dec 19, 2024 at 6:07=E2=80=AFPM Sedat Dilek  wrote:
> >>>> On Thu, Dec 19, 2024 at 5:44=E2=80=AFPM Andrew Cooper  wrote:
> >>>>> On 19/12/2024 4:14 pm, Sedat Dilek wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Linux v6.12.6 will include XEN CVE fixes from mainline.
> >>>>>>
> >>>>>> Here, I use Debian/unstable AMD64 and the SLIM LLVM toolchain 19.1=
.x
> >>>>>> from kernel.org.
> >>>>>>
> >>>>>> What does it mean in ISSUE DESCRIPTION...
> >>>>>>
> >>>>>> Furthermore, the hypercall page has no provision for Control-flow
> >>>>>> Integrity schemes (e.g. kCFI/CET-IBT/FineIBT), and will simply
> >>>>>> malfunction in such configurations.
> >>>>>>
> >>>>>> ...when someone uses Clang-kCFI?
> >>>>> The hypercall page has functions of the form:
> >>>>>
> >>>>>     MOV $x, %eax
> >>>>>     VMCALL / VMMCALL / SYSCALL
> >>>>>     RET
> >>>>>
> >>>>> There are no ENDBR instructions, and no prologue/epilogue for hash-=
based
> >>>>> CFI schemes.
> >>>>>
> >>>>> This is because it's code provided by Xen, not code provided by Lin=
ux.
> >>>>>
> >>>>> The absence of ENDBR instructions will yield #CP when CET-IBT is ac=
tive,
> >>>>> and the absence of hash prologue/epilogue lets the function be used=
 in a
> >>>>> type-confused manor that CFI should have caught.
> >>>>>
> >>>>> ~Andrew
> >>>> Thanks for the technical explanation, Andrew.
> >>>>
> >>>> Hope that helps the folks of "CLANG CONTROL FLOW INTEGRITY SUPPORT".
> >>>>
> >>>> I am not an active user of XEN in the Linux-kernel but I am willing =
to
> >>>> test when Linux v6.12.6 is officially released and give feedback.
> >>>>
> >>> https://wiki.xenproject.org/wiki/Testing_Xen#Presence_test
> >>> https://wiki.xenproject.org/wiki/Testing_Xen#Commands_for_presence_te=
sting
> >>>
> >>> # apt install -t unstable xen-utils-4.17 -y
> >>>
> >>> # xl list
> >>> Name                                        ID   Mem VCPUs      State=
   Time(s)
> >>> Domain-0                                     0  7872     4     r-----=
     398.2
> >>>
> >>> Some basic tests LGTM - see also attached stuff.
> >>>
> >>> If you have any tests to recommend, let me know.
> >> That itself is good enough as a smoke test.  Thankyou for trying it ou=
t.
> >>
> >> If you want something a bit more thorough, try
> >> https://xenbits.xen.org/docs/xtf/  (Xen's self-tests)
> >>
> >> Grab and build it, and `./xtf-runner -aqq --host` will run a variety o=
f
> >> extra codepaths in dom0, without the effort of making/running full gue=
sts.
> >>
> >> ~Andrew
> > Run on Debian 6.12.5 and my selfmade 6.12.5 and 6.12.6.
> > All tests lead to a reboot in case of Debian or in my kernels to a shut=
down.
> >
> > Can you recommend a specific test?
>
> Oh, that's distinctly less good.
>
> Start with just "example".  It's literally a hello world microkernel,
> but the symptoms you're seeing is a dom0 crash, so it will likely
> provoke it.
>
> Do you have serial to the machine?  If so, boot Xen with `console=3Dcom1
> com1=3D115200,8n1` (or com2, as appropriate).
>
> If not and you've only got a regular screen, boot Xen with `vga=3D,keep
> noreboot` (comma is important) which might leave enough information on
> screen to get an idea of what's going on.
>
> Full command line docs at
> https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html
>
> > dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner --list functional xsa | g=
rep xsa-4
> > test-pv64-xsa-444
> > test-hvm64-xsa-451
> > test-hvm64-xsa-454
> >
> > Is there no xsa-466 test?
>
> No.  XSA-466 is really "well don't do that then if it matters".
>
> More generally, not all XSAs are amenable to testing in this way.
>
> ~Andrew

RUN example tests on Debian's 6.12.6 kernel.

$ cat /proc/version
Linux version 6.12.6-amd64 (debian-kernel@lists.debian.org)
(x86_64-linux-gnu-gcc-14 (Debian 14.2.0-11) 14.2.0, GNU ld (GNU
Binutils for Debian) 2.43.50.20241215) #1 SMP PREEMPT_DYNAMIC Debian
6.12.6-1 (2024-12-21)

dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner --list example
test-hvm32-example
test-hvm32pae-example
test-hvm32pse-example
test-hvm64-example
test-pv32pae-example
test-pv64-example
dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner test-hvm32-example
Executing 'xl create -p tests/example/test-hvm32-example.cfg'
Executing 'xl console test-hvm32-example'
Executing 'xl unpause test-hvm32-example'
--- Xen Test Framework ---
Environment: HVM 32bit (No paging)
Hello World
Test result: SUCCESS

Combined test results:
test-hvm32-example                       SUCCESS
dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner test-hvm32pae-example
Executing 'xl create -p tests/example/test-hvm32pae-example.cfg'
Executing 'xl console test-hvm32pae-example'
Executing 'xl unpause test-hvm32pae-example'
--- Xen Test Framework ---
Environment: HVM 32bit (PAE 3 levels)
Hello World
Test result: SUCCESS

Combined test results:
test-hvm32pae-example                    SUCCESS
dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner test-hvm32pse-example
Executing 'xl create -p tests/example/test-hvm32pse-example.cfg'
Executing 'xl console test-hvm32pse-example'
Executing 'xl unpause test-hvm32pse-example'
--- Xen Test Framework ---
Environment: HVM 32bit (PSE 2 levels)
Hello World
Test result: SUCCESS

Combined test results:
test-hvm32pse-example                    SUCCESS
dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner test-hvm64-example
Executing 'xl create -p tests/example/test-hvm64-example.cfg'
Executing 'xl console test-hvm64-example'
Executing 'xl unpause test-hvm64-example'
--- Xen Test Framework ---
Environment: HVM 64bit (Long mode 4 levels)
Hello World
Test result: SUCCESS

Combined test results:
test-hvm64-example                       SUCCESS
dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner test-pv32pae-example
Combined test results:
test-pv32pae-example                     SKIP
dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner test-pv64-example
Executing 'xl create -p tests/example/test-pv64-example.cfg'
Executing 'xl console test-pv64-example'
Executing 'xl unpause test-pv64-example'
--- Xen Test Framework ---
Environment: PV 64bit (Long mode 4 levels)
Hello World
Test result: SUCCESS

Combined test results:
test-pv64-example                        SUCCESS

Thanks.

Best regards,
-Sedat-


From xen-devel-bounces@lists.xenproject.org Sat Dec 21 19:45:52 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Dec 2024 19:45:52 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862511.1274153 (Exim 4.92)
	(envelope-from )
	id 1tP5Pv-0006Dy-GV; Sat, 21 Dec 2024 19:45:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862511.1274153; Sat, 21 Dec 2024 19:45: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 1tP5Pv-0006Cy-74; Sat, 21 Dec 2024 19:45:39 +0000
Received: by outflank-mailman (input) for mailman id 862511;
 Sat, 21 Dec 2024 19:10: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 1tP4rq-0002fx-RK
 for xen-devel@lists.xenproject.org; Sat, 21 Dec 2024 19:10:26 +0000
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com
 [2a00:1450:4864:20::12d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3bdad759-bfcf-11ef-a0d9-8be0dac302b0;
 Sat, 21 Dec 2024 20:10:25 +0100 (CET)
Received: by mail-lf1-x12d.google.com with SMTP id
 2adb3069b0e04-53e399e3310so3315136e87.1
 for ; Sat, 21 Dec 2024 11:10: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: 3bdad759-bfcf-11ef-a0d9-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734808225; x=1735413025; darn=lists.xenproject.org;
        h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=DICSLitDkSZdoKgSJ3JkSamUIfZXy0wB9Dy+tZ/JX4o=;
        b=VGraXY34BkCwkRt3vN5XfRUgOLCG8kE3WkbN1d7+kTGf8B7sXDKVxxUM3Y4iaHCmDQ
         /0/5/Qy+5jghcS7SBJclPiANkXnt7O3mDzZEEDWi9Mc0dLe0NFsBSeDFkmGeioo6+Z0q
         yIFPTwTLtkkS4W86AJBsocHFFXwLiP32kdo2yuXX/nxBTZzNGom6dUQFsmdroLZJPdVt
         7kHz6gX6lfwiuYRSWtIMn1jP0je7E2cjjH7gPub1//O/piAoyPVzgCkMHHi+qCcOKl3V
         qEcvYedCMVHBYo0NRJrttWGpucY6o9EqzSW9wur8Aif1PgjLE4Ku79a6m6QvZQaLoyRv
         Rz0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734808225; x=1735413025;
        h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=DICSLitDkSZdoKgSJ3JkSamUIfZXy0wB9Dy+tZ/JX4o=;
        b=BwdQfU2FO9p6hhCz+13mUJ5HnWiHwLjzdXwtiyNBgbyLOUqoduBBQkqc87QwyIHtL8
         MXQJI4mLJhHozRgGAku+JC1Twf3jYOIcGWvVfdpqmCXgPMGzrCIaQ0sgllskciMlRTfE
         eai4IZmH4UWAszl5ufKQrm+L1BMfShUEAB4gujlajpdj2kKaSDQgnClUMSsWI/nSI4CA
         iL2ofF7jD5YtNP2enWxtJXIKQIv2f0He0DHZ4KqUG5qUHUpTklHs8hpRKjiEEEUMcQC6
         GdWiuDcxTsdgBM7pIVCyJWsPuuRHqKBpUjIykcO1gZ4XNWSRnFCyl2OOsql8ZB489cnU
         AGVQ==
X-Forwarded-Encrypted: i=1; AJvYcCU4g5ddCrim7IKh1zscpGNtlA5j3kktE9KM+OlXmaS6HQjen5Q4K4qfQQHXVpEG85MK8tSFpgAa6Ac=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yy3Sk5zm9Zt6JH9l6G1z2ZIqLozl5E++8FKdl6m783IudTsHp2G
	hXaL7K8INTu6KrtmRVY2KZnYioVmwAiuf6Z0GVY4ktuPyo37cjLXMyJpHhFnmnxJK4aSLqmNVQP
	dYBt4JCMe0YT6HpNJwLx6ndVH2lk=
X-Gm-Gg: ASbGncv9cXs1c1KJzZ5ilJwQ9DTR7Yi686xysIg12+RwfUp5zbNnBmTDau3s3AcV3Dt
	CdLenFe2uBVBwq1pwgmOPWng8DXGdqRJ8qZsyknImjtIKVkTAbxGD425hWRnu/1zvQvK5
X-Google-Smtp-Source: AGHT+IEe2LojPiPTBvWcFiJy0Wow6bjJvCnYTDrCzXg4UoYFG87UC6TJQDcIoRRxmiY1F2RYuqc9z090hwAo9aGKC5M=
X-Received: by 2002:a05:6512:2246:b0:542:2e04:edd1 with SMTP id
 2adb3069b0e04-5422e04f073mr879572e87.42.1734808224878; Sat, 21 Dec 2024
 11:10:24 -0800 (PST)
MIME-Version: 1.0
References: 
 <099d3a80-4fdb-49a7-9fd0-207d7386551f@citrix.com> 
 
 <90640a5d-ff17-4555-adc6-ae9e21e24ebd@citrix.com> 
 <43166e29-ff2d-4a9d-8c1b-41b5e247974b@citrix.com> 
 
In-Reply-To: 
Reply-To: sedat.dilek@gmail.com
From: Sedat Dilek 
Date: Sat, 21 Dec 2024 20:09:48 +0100
Message-ID: 
Subject: Re: [Linux-6.12.y] XEN: CVE-2024-53241 / XSA-466 and Clang-kCFI
To: Andrew Cooper 
Cc: Juergen Gross , Peter Zijlstra , 
	Sami Tolvanen , Jan Beulich , 
	Josh Poimboeuf , Linus Torvalds , 
	Greg Kroah-Hartman , Sasha Levin , 
	linux-kernel@vger.kernel.org, stable@vger.kernel.org, 
	Kees Cook , Nathan Chancellor , llvm@lists.linux.dev, 
	xen-devel 
Content-Type: text/plain; charset="UTF-8"

Run all SUCCESS tests on my selfmade kernel.

# xl info | egrep 'release|version|commandline|caps'
release                : 6.12.6-1-amd64-clang19-kcfi
version                : #1~trixie+dileks SMP PREEMPT_DYNAMIC 2024-12-19
hw_caps                :
bfebfbff:17bae3bf:28100800:00000001:00000001:00000000:00000000:00000100
virt_caps              : pv hvm hap shadow gnttab-v1 gnttab-v2
xen_version            : 4.17.4-pre
xen_caps               : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p
hvm-3.0-x86_64
xen_commandline        : placeholder vga=,keep noreboot

dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner --host $( grep SUCCESS
../TESTS-SUCCESS | awk '{ print $1 }' )
...
Combined test results:
test-hvm32-invlpg~hap                    SUCCESS
test-hvm32-invlpg~shadow                 SUCCESS
test-hvm32pae-invlpg~hap                 SUCCESS
test-hvm32pae-invlpg~shadow              SUCCESS
test-hvm64-invlpg~hap                    SUCCESS
test-hvm64-invlpg~shadow                 SUCCESS
test-hvm64-lbr-tsx-vmentry               SUCCESS
test-hvm32-livepatch-priv-check          SUCCESS
test-hvm64-livepatch-priv-check          SUCCESS
test-pv64-livepatch-priv-check           SUCCESS
test-hvm32-lm-ts                         SUCCESS
test-hvm64-lm-ts                         SUCCESS
test-hvm32pae-memop-seg                  SUCCESS
test-hvm64-memop-seg                     SUCCESS
test-pv64-memop-seg                      SUCCESS
test-hvm32pae-nmi-taskswitch-priv        SUCCESS
test-pv64-pv-iopl~hypercall              SUCCESS
test-pv64-pv-iopl~vmassist               SUCCESS
test-hvm32-xsa-122                       SUCCESS
test-hvm32pae-xsa-122                    SUCCESS
test-hvm32pse-xsa-122                    SUCCESS
test-hvm64-xsa-122                       SUCCESS
test-pv64-xsa-122                        SUCCESS
test-hvm64-xsa-168~shadow                SUCCESS
test-hvm64-xsa-173~shadow                SUCCESS
test-pv64-xsa-182                        SUCCESS
test-hvm32-xsa-188                       SUCCESS
test-hvm32pae-xsa-188                    SUCCESS
test-hvm32pse-xsa-188                    SUCCESS
test-hvm64-xsa-188                       SUCCESS
test-pv64-xsa-188                        SUCCESS
test-hvm32-xsa-192                       SUCCESS
test-pv64-xsa-193                        SUCCESS
test-hvm64-xsa-195                       SUCCESS
test-pv64-xsa-212                        SUCCESS
test-pv64-xsa-213                        SUCCESS
test-hvm64-xsa-221                       SUCCESS
test-pv64-xsa-221                        SUCCESS
test-pv64-xsa-224                        SUCCESS
test-pv64-xsa-227                        SUCCESS
test-hvm64-xsa-231                       SUCCESS
test-pv64-xsa-231                        SUCCESS
test-hvm64-xsa-232                       SUCCESS
test-pv64-xsa-232                        SUCCESS
test-pv64-xsa-234                        SUCCESS
test-hvm32-xsa-239                       SUCCESS
test-pv64-xsa-255                        SUCCESS
test-pv64-xsa-259                        SUCCESS
test-pv64-xsa-260                        SUCCESS
test-hvm64-xsa-261                       SUCCESS
test-pv64-xsa-265                        SUCCESS
test-hvm64-xsa-269                       SUCCESS
test-hvm64-xsa-277                       SUCCESS
test-hvm64-xsa-278                       SUCCESS
test-pv64-xsa-279                        SUCCESS
test-pv64-xsa-286                        SUCCESS
test-pv64-xsa-296                        SUCCESS
test-pv64-xsa-298                        SUCCESS
test-hvm64-xsa-304                       SUCCESS
test-hvm64-xsa-308                       SUCCESS
test-pv64-xsa-316                        SUCCESS
test-hvm32-xsa-317                       SUCCESS
test-hvm32pae-xsa-317                    SUCCESS
test-hvm32pse-xsa-317                    SUCCESS
test-hvm64-xsa-317                       SUCCESS
test-pv64-xsa-317                        SUCCESS
test-pv64-xsa-333                        SUCCESS
test-pv64-xsa-339                        SUCCESS

No CFI related stuff in dmesg seen after running XFT tests.

Best regards,
-Sedat-


From xen-devel-bounces@lists.xenproject.org Sat Dec 21 21:31:58 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Dec 2024 21:31:58 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862551.1274173 (Exim 4.92)
	(envelope-from )
	id 1tP74Y-0003xa-U1; Sat, 21 Dec 2024 21:31:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862551.1274173; Sat, 21 Dec 2024 21:31: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 1tP74Y-0003xT-Qk; Sat, 21 Dec 2024 21:31:42 +0000
Received: by outflank-mailman (input) for mailman id 862551;
 Sat, 21 Dec 2024 21:31: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 1tP74X-0003xN-PG
 for xen-devel@lists.xenproject.org; Sat, 21 Dec 2024 21:31:41 +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 f6458011-bfe2-11ef-a0d9-8be0dac302b0;
 Sat, 21 Dec 2024 22:31:39 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-43621d27adeso20640705e9.2
 for ; Sat, 21 Dec 2024 13:31:39 -0800 (PST)
Received: from [192.168.1.10] (host-92-26-98-202.as13285.net. [92.26.98.202])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c828cc8sm7363868f8f.17.2024.12.21.13.31.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 21 Dec 2024 13:31: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: f6458011-bfe2-11ef-a0d9-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1734816698; x=1735421498; 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=g80Xv9sdG8bld1hI5N8TIg0l0usJaOYYz4GMokDzByQ=;
        b=TJBg/CsNHogDUNIuF7KeHBntwavhntxi0LeNsbvsO/8iwjbDwPrsYBFIvnahDZ89y2
         uCzSTFpX45IPaMgjzsjRraIx0OY5GWxXRhQEN1VkrRkvcHJF2Qlwg3UnDfgVm31tMTBJ
         00LnxRhTLe1YEeC64KD5Li31ChG4Bmp8TAdRw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734816698; x=1735421498;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=g80Xv9sdG8bld1hI5N8TIg0l0usJaOYYz4GMokDzByQ=;
        b=C9+RcVH16oU+54MUo/kNq5fNc/wI1ZDylr2fGoI9sr7jtYV2MwXmwdzI59ur+A381f
         l89x1hvotrlEutYZMz5bX0anfsPQYY0FwONPC+G0mH4T8tz4ZYnLnsCtDt1BWkly/gqm
         wXZRvdDocwx1yDDq+c65v1gOVLNJos7Q4nHXMLOSGtVWmoeOHRe/JNm5Zwqd/on3bRYm
         utwAfdGctqJEp/HVLSE8TJdfHg2++ImdrMHsRW2wGFkOhaNNIAUTmdtw2EAwSKj7d/L7
         Wbqn9efEU7fSxMswsxHRjKM0bpoiNKt3b8v62z8jRKpqXhXM2C2ynTtOyq9HQ7CIq6/G
         J7bA==
X-Forwarded-Encrypted: i=1; AJvYcCW28Wj7FXdmSvo/Mc9fzM26dn1fnVfdqEFWzHpUg/G4zs/mpYgYaEikUh8LmbXHO2RIptKSOOWTY/4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwSHrqtijEANIRTeuInLZjkJFYUlMNhEsQGwcQatRHbO/FvIgPP
	umQAykp+d9LQ4OK/NloWeDANh9pBzCQpMqpy9MIo8CQRFWbYT1ij6B3jRDRfd8k=
X-Gm-Gg: ASbGncs3lPMJNw5vs1Dikx1MQ4Eb4uI+2YiSIYm8V0+L7YQDLl+ff05ZcEIOabOzoeW
	u54i19zSXmAFSP8+4HAc21xYXU+xavYFI8eXwjy4DrFtVTPMKiJTHhMY/qOocR7RQXEo3XmCm7w
	Tgzf+2Mh4i9HOaoeHzmN4w9yOkzzyhnkpvnyZ8YN9pzXVOt1x91dm+ynkcNNMTIn8wNjBd6v7ub
	SdpOZLHmSjVkmbiC3ZTcy3ajRrelR49uzgad3pXMYhA8g4Rd1EsXTZnxfeA0+/eObSeEC5St+Bz
	Fhy4/hdUfJZ2HP8s/S6s
X-Google-Smtp-Source: AGHT+IFrVlLP9YH10ZAu9oKbTiFL/KTq/9QViPYsupLF2ej43cn2G5wKtY+3Gp7pjqL4avgqCHPezA==
X-Received: by 2002:a05:6000:156f:b0:386:2aba:a7f6 with SMTP id ffacd0b85a97d-38a224071e3mr5767422f8f.49.1734816698193;
        Sat, 21 Dec 2024 13:31:38 -0800 (PST)
Message-ID: <698f48a0-b674-4d7f-9c47-f1f8bf86379e@citrix.com>
Date: Sat, 21 Dec 2024 21:31:36 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [Linux-6.12.y] XEN: CVE-2024-53241 / XSA-466 and Clang-kCFI
To: sedat.dilek@gmail.com
Cc: Juergen Gross , Peter Zijlstra ,
 Sami Tolvanen , Jan Beulich ,
 Josh Poimboeuf ,
 Linus Torvalds ,
 Greg Kroah-Hartman ,
 Sasha Levin , linux-kernel@vger.kernel.org,
 stable@vger.kernel.org, Kees Cook ,
 Nathan Chancellor , llvm@lists.linux.dev,
 xen-devel 
References: 
 <099d3a80-4fdb-49a7-9fd0-207d7386551f@citrix.com>
 
 
 <90640a5d-ff17-4555-adc6-ae9e21e24ebd@citrix.com>
 
 <43166e29-ff2d-4a9d-8c1b-41b5e247974b@citrix.com>
 
 
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 21/12/2024 6:25 pm, Sedat Dilek wrote:
> With...
>
> dileks@iniza:~/src/xtf/git$ mv tests/xsa-454 ../
> dileks@iniza:~/src/xtf/git$ mv tests/xsa-consoleio-write ../

That's completely bizzare.   There's nothing interestingly different
with those two tests vs the others.

I take it the crash is repeatable when using either of these?

~Andrew


From xen-devel-bounces@lists.xenproject.org Sun Dec 22 00:52:55 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Dec 2024 00:52:55 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862566.1274183 (Exim 4.92)
	(envelope-from )
	id 1tPACw-00015m-Ro; Sun, 22 Dec 2024 00:52:34 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862566.1274183; Sun, 22 Dec 2024 00:52: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 1tPACw-00015f-Oh; Sun, 22 Dec 2024 00:52:34 +0000
Received: by outflank-mailman (input) for mailman id 862566;
 Sun, 22 Dec 2024 00:52: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 1tPACv-00015Z-Fa
 for xen-devel@lists.xenproject.org; Sun, 22 Dec 2024 00:52:33 +0000
Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com
 [2607:f8b0:4864:20::1130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 026f7a4c-bfff-11ef-99a3-01e77a169b0f;
 Sun, 22 Dec 2024 01:52:25 +0100 (CET)
Received: by mail-yw1-x1130.google.com with SMTP id
 00721157ae682-6f2c8aea797so24963357b3.1
 for ; Sat, 21 Dec 2024 16:52: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: 026f7a4c-bfff-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734828744; x=1735433544; 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=G56dFj5BRaIttSoRxhRi+K83W3sP81bwdAaZ6QoaIrc=;
        b=h2iRdEQVKwMN72qAXi6xwR7Bpsw/b5d/kWL/m8dNgFGkaWTeOa7uH74e9Hw1S4k94b
         uckb1J5lRaUoSNuSF3anLQb09cyxACrtFBactGYJ49xanOAMZOKIpvfg+rjnNU20aBpW
         5/MRvkZ4KpRV+xDETwuoZVpQeRdushD5w/BwiDF4tkzTrT73JLNM7q7TnvHp3zMAna9o
         NAx5m29s+xRt3/OOOLYe/Wm8gMU1KrsYidSZVERZHJVdZtCS+j0U+bHZuC7tgEFKmebj
         WlF5JS5FmEvqpK6WP8P8XLpMTvSJlkFheqRlXYwAIOsDhw9uH5UK4kApWJcGVd2TLhLg
         hRuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734828744; x=1735433544;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=G56dFj5BRaIttSoRxhRi+K83W3sP81bwdAaZ6QoaIrc=;
        b=kIW4sfEiekkGltu2KrBQ4j6zWn/ehIpak/JhjQub8Vy2XTN3LZ2BG9zB3eBUYD6FLG
         HeI9cypUVxkwr4mk1J2Sp7KeIJL821EeM365g+1HmIiJm/ww2+Bsl2HEkAGLuZr07lXn
         8OE5CZwkLeXZTElVNCpa7bRbBuxT57vBkokyCGtT/ZcbECgMczEs1/QfUkkypsCI4e5/
         hOB3LZYfmmgc5Ef9LFq3HZ6effRWPrUs1TmMR028unrS5VCk+KfNRjPT4IpmR4v9LfMj
         HCuh4W9WvfWgSceaVsRXGo8o2Jos2Ea2sS12ae3qN/9AYy1QtZhDDrxuKfiWM/PlCyRu
         AL4w==
X-Forwarded-Encrypted: i=1; AJvYcCW4//rhs4dvLfXWBQwYNVA4V9wdNInW/LtnorpfS6vjeJeqZXKUkq2F0SSyOplBMNQ7p3MgZRtsdB8=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yx0iHhZGr1+O+hURecT1XRVLuAPBLCNSfQ7+gNrf+HGfZUl1A7f
	eFbP8zB+lU8aMR2CXs5pIVG4DEaJV0YiC8JSmLRO5lPmRwh4VpazX9s82UMmPd7M25auLGIGyo7
	0qoyik5i3lXe4J20jrs2SUIfIjvM=
X-Gm-Gg: ASbGnctWXddyyrA9Yoe9aoruwqC+IyvU7iUmnjcUSOqqEkEKO5eSNmEM4uijb14XuML
	f//3BnDaCV03IFFWRSI8DcaG/dNnPle0apFuX5RU=
X-Google-Smtp-Source: AGHT+IHH5gTAOmFubOYjlrK+2+jdIvePBlyZPYVyBZBy90RljxEGCQgcvHQMo3bTypvAoytVk58QJl8i95oeqQUdh1w=
X-Received: by 2002:a05:690c:4e82:b0:6f0:21d6:4497 with SMTP id
 00721157ae682-6f3f80d911amr42730727b3.9.1734828744363; Sat, 21 Dec 2024
 16:52:24 -0800 (PST)
MIME-Version: 1.0
References: <20241221104304.2655909-1-guoweikang.kernel@gmail.com> 
In-Reply-To: 
From: Weikang Guo 
Date: Sun, 22 Dec 2024 08:52:14 +0800
Message-ID: 
Subject: Re: [PATCH v2] mm/memblock: Add memblock_alloc_or_panic interface
To: Geert Uytterhoeven 
Cc: Andrew Morton , Mike Rapoport , 
	Dennis Zhou , Tejun Heo , Christoph Lameter , 
	Thomas Bogendoerfer , Sam Creasey , 
	Huacai Chen , Will Deacon , 
	Catalin Marinas , Oreoluwa Babatunde , 
	rafael.j.wysocki@intel.com, Palmer Dabbelt , 
	Hanjun Guo , Easwar Hariharan , 
	Johannes Berg , Ingo Molnar , 
	Dave Hansen , Christian Brauner , 
	KP Singh , Richard Henderson , 
	Matt Turner , Russell King , 
	WANG Xuerui , Michael Ellerman , 
	Stefan Kristiansson , Stafford Horne , 
	Helge Deller , Nicholas Piggin , 
	Christophe Leroy , Naveen N Rao , 
	Madhavan Srinivasan , Geoff Levand , 
	Paul Walmsley , Palmer Dabbelt , 
	Albert Ou , Andrey Ryabinin , 
	Alexander Potapenko , Andrey Konovalov , 
	Dmitry Vyukov , Vincenzo Frascino , 
	Heiko Carstens , Vasily Gorbik , 
	Alexander Gordeev , Christian Borntraeger , 
	Sven Schnelle , Yoshinori Sato , 
	Rich Felker , John Paul Adrian Glaubitz , 
	Andreas Larsson , Richard Weinberger , 
	Anton Ivanov , Johannes Berg , 
	Thomas Gleixner , Ingo Molnar , Borislav Petkov , 
	Dave Hansen , x86@kernel.org, linux-alpha@vger.kernel.org, 
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org, 
	linux-mips@vger.kernel.org, linux-openrisc@vger.kernel.org, 
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, 
	linux-riscv@lists.infradead.org, kasan-dev@googlegroups.com, 
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, 
	sparclinux@vger.kernel.org, linux-um@lists.infradead.org, 
	linux-acpi@vger.kernel.org, xen-devel@lists.xenproject.org, 
	linux-omap@vger.kernel.org, linux-clk@vger.kernel.org, 
	devicetree@vger.kernel.org, linux-mm@kvack.org, linux-pm@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Geert Uytterhoeven  wrote on Saturday, 21
December 2024 at 22:10
>
> Hi Guo,
>
> On Sat, Dec 21, 2024 at 11:43=E2=80=AFAM Guo Weikang
>  wrote:
> > Before SLUB initialization, various subsystems used memblock_alloc to
> > allocate memory. In most cases, when memory allocation fails, an immedi=
ate
> > panic is required. To simplify this behavior and reduce repetitive chec=
ks,
> > introduce `memblock_alloc_or_panic`. This function ensures that memory
> > allocation failures result in a panic automatically, improving code
> > readability and consistency across subsystems that require this behavio=
r.
> >
> > Signed-off-by: Guo Weikang 
>
> Thanks for your patch!
>
> > --- a/include/linux/memblock.h
> > +++ b/include/linux/memblock.h
> > @@ -417,6 +417,20 @@ static __always_inline void *memblock_alloc(phys_a=
ddr_t size, phys_addr_t align)
> >                                       MEMBLOCK_ALLOC_ACCESSIBLE, NUMA_N=
O_NODE);
> >  }
> >
> > +static __always_inline void *__memblock_alloc_or_panic(phys_addr_t siz=
e,
> > +                                                      phys_addr_t alig=
n,
> > +                                                      const char *func=
)
> > +{
> > +       void *addr =3D memblock_alloc(size, align);
> > +
> > +       if (unlikely(!addr))
> > +               panic("%s: Failed to allocate %llu bytes\n", func, size=
);
> > +       return addr;
> > +}
>
> Please make this out-of-line, and move it to mm/memblock.c, so we have
> just a single copy in the final binary.
>
Got it, I'll make the change
> > +
> > +#define memblock_alloc_or_panic(size, align)    \
> > +        __memblock_alloc_or_panic(size, align, __func__)
> > +
> >  static inline void *memblock_alloc_raw(phys_addr_t size,
> >                                                phys_addr_t align)
> >  {
> > diff --git a/init/main.c b/init/main.c
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m6=
8k.org
>
> In personal conversations with technical people, I call myself a hacker. =
But
> when I'm talking to journalists I just say "programmer" or something like=
 that.
>                                 -- Linus Torvalds

Best regards
             Guo


From xen-devel-bounces@lists.xenproject.org Sun Dec 22 01:27:11 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Dec 2024 01:27:11 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862582.1274193 (Exim 4.92)
	(envelope-from )
	id 1tPAkL-0004Wr-8r; Sun, 22 Dec 2024 01:27:05 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862582.1274193; Sun, 22 Dec 2024 01:27:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tPAkL-0004Wk-5c; Sun, 22 Dec 2024 01:27:05 +0000
Received: by outflank-mailman (input) for mailman id 862582;
 Sun, 22 Dec 2024 01:27: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 1tPAkJ-0004We-Mf
 for xen-devel@lists.xenproject.org; Sun, 22 Dec 2024 01:27:04 +0000
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com
 [2607:f8b0:4864:20::434])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d6e4c0aa-c003-11ef-99a3-01e77a169b0f;
 Sun, 22 Dec 2024 02:27:00 +0100 (CET)
Received: by mail-pf1-x434.google.com with SMTP id
 d2e1a72fcca58-728eedfca37so3395625b3a.2
 for ; Sat, 21 Dec 2024 17:27:00 -0800 (PST)
Received: from localhost.localdomain ([36.110.106.149])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-72aad816215sm5350653b3a.19.2024.12.21.17.26.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 21 Dec 2024 17:26: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: d6e4c0aa-c003-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734830819; x=1735435619; 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=R2ZWvShbKRHRjon0641iHEOPeMHgSL8jk5gB795H+V0=;
        b=b897wYXlJjaMzd9vKImIS/1bfW1Lkm3itXkc/bpeBon2bszBzNvTDZEAF1fa+Zaf+5
         bdDlIPaYEumLRa6MGpxun4vWrIpuI5vO2w9fFTkaniwAHv+nvlNfFvXepEEO19dIQJF+
         eo5kCSiugQ2G/vaCej8FlJ6Yn39iZUn7O+Ppv1oajsckXe9gaDxfqA9WI92iHTMhfRb2
         EpxDKZKVhWuwAk2pCN4U+Xk3uAW7+38kp8ytSe5QKuax/kR/BdWapqLjPVF/e5PdFI05
         3mqiiTkuTOOVL9ui2q7+VOeh7Lq+n/w/qAs4addJch/5eRfcXn+JuqpmoLffyFaT9eTB
         OtnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734830819; x=1735435619;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=R2ZWvShbKRHRjon0641iHEOPeMHgSL8jk5gB795H+V0=;
        b=wpgsxofBFKaDR2t9mh8EDfuzIQ8TmwuR/ePanR7eGVJ4+PJs4G5YwsllsULWL967iD
         36FR7OATyl3fVOH8foWesc/USKfovURVRNH4nM8APq61lx/FQ7cmnl541TA9NpNfKlpF
         zfvmIl4U1LMulRBuYbyAdHnmdiVsToJ/ieBzY/Xb7ZtJgQ85eTI4UndhMzs44sIf+gNQ
         9A+VsHwHwEdcQo5MxO/aAcSWLYwPUP88zWVwXH6uEwbHHUTmEQQ4X/LUYk0/dpO7Npri
         wKA/8CMYDIfKDr7zwpoVytomfPOFd6+7rdGsfmy9hoXLgkRnHAfEA6e81P7YAR4k8PsD
         7nEg==
X-Forwarded-Encrypted: i=1; AJvYcCWQrolEIaMrr8efFTG4xgEFE70X4ASUZJkFwnz989vHu3Hd+YRXky5f6wLoRrxT2oHwJ1+EsCF2A8s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YyiCqYfojS3mBAh0UQWrYhOUxEa/vEzcn/dzgMAiy6wh9xZOXtX
	iVH4m7pVs/zTY8H2ShvGshzCpMAhLD0kfGRjcwrUcfnZiIkgl3cx
X-Gm-Gg: ASbGncvbGFsArl9Q+TCrphzMFZBRzGGyEnmT+xloFvwmWXtsOk0GIw7JnoOWhDEoKhL
	Rq+JfxlObKN4X3nFopuh/TrFtbk8F1rJDC2bfMVyMBKkevqJs5RlTIGpvSbXs7AQHupY0uMK925
	4v/K3mLnn6cam9DX/6XIXcc/Kx7MjnWyGLoYwh8pKywfnCMSzXVdfijyhcbYFYY0Dvk4yMcLG/n
	V/+nZSskAy/x3gfl7cfg7+HwPRaEE+/xMA657SoKaggRIDM6xKbcRsBa5U6jiw3fg/2O8sJ6bYk
	U4l9
X-Google-Smtp-Source: AGHT+IFFssbriKBb3rjCkCTIhwfTSmHkJlrpVkm/iBeD6RNXWuBfOSDpm3O/LJJpp/yrt2Zcph743g==
X-Received: by 2002:a05:6a00:430d:b0:725:df1a:27c with SMTP id d2e1a72fcca58-72abde0d185mr11323615b3a.14.1734830818348;
        Sat, 21 Dec 2024 17:26:58 -0800 (PST)
From: Guo Weikang 
To: Andrew Morton ,
	Mike Rapoport ,
	Geert Uytterhoeven ,
	Guo Weikang 
Cc: Dennis Zhou ,
	Tejun Heo ,
	Christoph Lameter ,
	Thomas Bogendoerfer ,
	Sam Creasey ,
	Huacai Chen ,
	Will Deacon ,
	Catalin Marinas ,
	Oreoluwa Babatunde ,
	rafael.j.wysocki@intel.com,
	Palmer Dabbelt ,
	Hanjun Guo ,
	Easwar Hariharan ,
	Johannes Berg ,
	Ingo Molnar ,
	Dave Hansen ,
	Christian Brauner ,
	KP Singh ,
	Richard Henderson ,
	Matt Turner ,
	Russell King ,
	WANG Xuerui ,
	Michael Ellerman ,
	Stefan Kristiansson ,
	Stafford Horne ,
	Helge Deller ,
	Nicholas Piggin ,
	Christophe Leroy ,
	Naveen N Rao ,
	Madhavan Srinivasan ,
	Geoff Levand ,
	Paul Walmsley ,
	Palmer Dabbelt ,
	Albert Ou ,
	Andrey Ryabinin ,
	Alexander Potapenko ,
	Andrey Konovalov ,
	Dmitry Vyukov ,
	Vincenzo Frascino ,
	Heiko Carstens ,
	Vasily Gorbik ,
	Alexander Gordeev ,
	Christian Borntraeger ,
	Sven Schnelle ,
	Yoshinori Sato ,
	Rich Felker ,
	John Paul Adrian Glaubitz ,
	Andreas Larsson ,
	Richard Weinberger ,
	Anton Ivanov ,
	Johannes Berg ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	x86@kernel.org,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-m68k@lists.linux-m68k.org,
	linux-mips@vger.kernel.org,
	linux-openrisc@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org,
	kasan-dev@googlegroups.com,
	linux-s390@vger.kernel.org,
	linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org,
	linux-um@lists.infradead.org,
	linux-acpi@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-omap@vger.kernel.org,
	linux-clk@vger.kernel.org,
	devicetree@vger.kernel.org,
	linux-mm@kvack.org,
	linux-pm@vger.kernel.org
Subject: [PATCH v4] mm/memblock: Add memblock_alloc_or_panic interface
Date: Sun, 22 Dec 2024 09:26:28 +0800
Message-Id: <20241222012628.2703802-1-guoweikang.kernel@gmail.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Before SLUB initialization, various subsystems used memblock_alloc to
allocate memory. In most cases, when memory allocation fails, an immediate
panic is required. To simplify this behavior and reduce repetitive checks,
introduce `memblock_alloc_or_panic`. This function ensures that memory
allocation failures result in a panic automatically, improving code
readability and consistency across subsystems that require this behavior.

Signed-off-by: Guo Weikang 
---
 arch/alpha/kernel/core_cia.c            |  5 +-
 arch/alpha/kernel/core_marvel.c         | 10 +---
 arch/alpha/kernel/pci.c                 | 13 +----
 arch/alpha/kernel/pci_iommu.c           | 10 +---
 arch/arm/kernel/setup.c                 | 10 +---
 arch/arm/mm/mmu.c                       | 17 ++----
 arch/arm/mm/nommu.c                     |  5 +-
 arch/arm64/kernel/setup.c               |  4 +-
 arch/loongarch/kernel/setup.c           |  2 +-
 arch/loongarch/mm/init.c                | 13 ++---
 arch/m68k/mm/init.c                     |  5 +-
 arch/m68k/mm/mcfmmu.c                   | 10 +---
 arch/m68k/mm/motorola.c                 |  5 +-
 arch/m68k/mm/sun3mmu.c                  | 10 +---
 arch/m68k/sun3/sun3dvma.c               |  6 +--
 arch/mips/kernel/setup.c                |  5 +-
 arch/openrisc/mm/ioremap.c              |  5 +-
 arch/parisc/mm/init.c                   | 20 ++-----
 arch/powerpc/kernel/dt_cpu_ftrs.c       | 10 ++--
 arch/powerpc/kernel/pci_32.c            |  5 +-
 arch/powerpc/kernel/setup-common.c      |  5 +-
 arch/powerpc/kernel/setup_32.c          |  8 +--
 arch/powerpc/mm/book3s32/mmu.c          |  5 +-
 arch/powerpc/mm/book3s64/pgtable.c      |  6 +--
 arch/powerpc/mm/kasan/init_book3e_64.c  |  8 +--
 arch/powerpc/mm/kasan/init_book3s_64.c  |  2 +-
 arch/powerpc/mm/nohash/mmu_context.c    | 16 ++----
 arch/powerpc/mm/pgtable_32.c            |  7 +--
 arch/powerpc/platforms/powermac/nvram.c |  5 +-
 arch/powerpc/platforms/powernv/opal.c   |  5 +-
 arch/powerpc/platforms/ps3/setup.c      |  5 +-
 arch/powerpc/sysdev/msi_bitmap.c        |  5 +-
 arch/riscv/kernel/setup.c               |  4 +-
 arch/riscv/mm/kasan_init.c              | 14 ++---
 arch/s390/kernel/numa.c                 |  5 +-
 arch/s390/kernel/setup.c                | 20 ++-----
 arch/s390/kernel/smp.c                  |  9 ++--
 arch/s390/kernel/topology.c             | 10 +---
 arch/sh/mm/init.c                       | 10 +---
 arch/sparc/kernel/prom_32.c             |  4 +-
 arch/sparc/mm/srmmu.c                   | 14 ++---
 arch/um/drivers/net_kern.c              |  5 +-
 arch/um/drivers/vector_kern.c           |  5 +-
 arch/um/kernel/load_file.c              |  4 +-
 arch/x86/coco/sev/core.c                |  4 +-
 arch/x86/kernel/acpi/boot.c             |  5 +-
 arch/x86/kernel/apic/io_apic.c          |  9 +---
 arch/x86/kernel/e820.c                  |  5 +-
 arch/x86/platform/olpc/olpc_dt.c        |  6 +--
 arch/x86/xen/p2m.c                      |  8 +--
 arch/xtensa/mm/kasan_init.c             |  6 +--
 drivers/clk/ti/clk.c                    |  5 +-
 drivers/macintosh/smu.c                 |  6 +--
 drivers/of/fdt.c                        |  8 +--
 drivers/of/unittest.c                   |  8 +--
 include/linux/memblock.h                |  6 +++
 init/main.c                             | 18 ++-----
 kernel/power/snapshot.c                 |  5 +-
 lib/cpumask.c                           |  5 +-
 mm/kmsan/shadow.c                       |  8 +--
 mm/memblock.c                           | 20 +++++++
 mm/numa.c                               |  8 +--
 mm/percpu.c                             | 70 +++++--------------------
 mm/sparse.c                             |  5 +-
 64 files changed, 143 insertions(+), 423 deletions(-)

diff --git a/arch/alpha/kernel/core_cia.c b/arch/alpha/kernel/core_cia.c
index ca3d9c732b61..6e577228e175 100644
--- a/arch/alpha/kernel/core_cia.c
+++ b/arch/alpha/kernel/core_cia.c
@@ -331,10 +331,7 @@ cia_prepare_tbia_workaround(int window)
 	long i;
 
 	/* Use minimal 1K map. */
-	ppte = memblock_alloc(CIA_BROKEN_TBIA_SIZE, 32768);
-	if (!ppte)
-		panic("%s: Failed to allocate %u bytes align=0x%x\n",
-		      __func__, CIA_BROKEN_TBIA_SIZE, 32768);
+	ppte = memblock_alloc_or_panic(CIA_BROKEN_TBIA_SIZE, 32768);
 	pte = (virt_to_phys(ppte) >> (PAGE_SHIFT - 1)) | 1;
 
 	for (i = 0; i < CIA_BROKEN_TBIA_SIZE / sizeof(unsigned long); ++i)
diff --git a/arch/alpha/kernel/core_marvel.c b/arch/alpha/kernel/core_marvel.c
index b22248044bf0..b1bfbd11980d 100644
--- a/arch/alpha/kernel/core_marvel.c
+++ b/arch/alpha/kernel/core_marvel.c
@@ -81,10 +81,7 @@ mk_resource_name(int pe, int port, char *str)
 	char *name;
 	
 	sprintf(tmp, "PCI %s PE %d PORT %d", str, pe, port);
-	name = memblock_alloc(strlen(tmp) + 1, SMP_CACHE_BYTES);
-	if (!name)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      strlen(tmp) + 1);
+	name = memblock_alloc_or_panic(strlen(tmp) + 1, SMP_CACHE_BYTES);
 	strcpy(name, tmp);
 
 	return name;
@@ -119,10 +116,7 @@ alloc_io7(unsigned int pe)
 		return NULL;
 	}
 
-	io7 = memblock_alloc(sizeof(*io7), SMP_CACHE_BYTES);
-	if (!io7)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*io7));
+	io7 = memblock_alloc_or_panic(sizeof(*io7), SMP_CACHE_BYTES);
 	io7->pe = pe;
 	raw_spin_lock_init(&io7->irq_lock);
 
diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
index 4458eb7f44f0..8e9b4ac86b7e 100644
--- a/arch/alpha/kernel/pci.c
+++ b/arch/alpha/kernel/pci.c
@@ -391,10 +391,7 @@ alloc_pci_controller(void)
 {
 	struct pci_controller *hose;
 
-	hose = memblock_alloc(sizeof(*hose), SMP_CACHE_BYTES);
-	if (!hose)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*hose));
+	hose = memblock_alloc_or_panic(sizeof(*hose), SMP_CACHE_BYTES);
 
 	*hose_tail = hose;
 	hose_tail = &hose->next;
@@ -405,13 +402,7 @@ alloc_pci_controller(void)
 struct resource * __init
 alloc_resource(void)
 {
-	void *ptr = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct resource));
-
-	return ptr;
+	return memblock_alloc_or_panic(sizeof(struct resource), SMP_CACHE_BYTES);
 }
 
 
diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index 7fcf3e9b7103..681f56089d9c 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -71,14 +71,8 @@ iommu_arena_new_node(int nid, struct pci_controller *hose, dma_addr_t base,
 	if (align < mem_size)
 		align = mem_size;
 
-	arena = memblock_alloc(sizeof(*arena), SMP_CACHE_BYTES);
-	if (!arena)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*arena));
-	arena->ptes = memblock_alloc(mem_size, align);
-	if (!arena->ptes)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, mem_size, align);
+	arena = memblock_alloc_or_panic(sizeof(*arena), SMP_CACHE_BYTES);
+	arena->ptes = memblock_alloc_or_panic(mem_size, align);
 
 	spin_lock_init(&arena->lock);
 	arena->hose = hose;
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index e6a857bf0ce6..a41c93988d2c 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -880,10 +880,7 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 		 */
 		boot_alias_start = phys_to_idmap(start);
 		if (arm_has_idmap_alias() && boot_alias_start != IDMAP_INVALID_ADDR) {
-			res = memblock_alloc(sizeof(*res), SMP_CACHE_BYTES);
-			if (!res)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, sizeof(*res));
+			res = memblock_alloc_or_panic(sizeof(*res), SMP_CACHE_BYTES);
 			res->name = "System RAM (boot alias)";
 			res->start = boot_alias_start;
 			res->end = phys_to_idmap(res_end);
@@ -891,10 +888,7 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 			request_resource(&iomem_resource, res);
 		}
 
-		res = memblock_alloc(sizeof(*res), SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      sizeof(*res));
+		res = memblock_alloc_or_panic(sizeof(*res), SMP_CACHE_BYTES);
 		res->name  = "System RAM";
 		res->start = start;
 		res->end = res_end;
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index f5b7a16c5803..f02f872ea8a9 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -726,13 +726,8 @@ EXPORT_SYMBOL(phys_mem_access_prot);
 
 static void __init *early_alloc(unsigned long sz)
 {
-	void *ptr = memblock_alloc(sz, sz);
+	return memblock_alloc_or_panic(sz, sz);
 
-	if (!ptr)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, sz, sz);
-
-	return ptr;
 }
 
 static void *__init late_alloc(unsigned long sz)
@@ -1027,10 +1022,7 @@ void __init iotable_init(struct map_desc *io_desc, int nr)
 	if (!nr)
 		return;
 
-	svm = memblock_alloc(sizeof(*svm) * nr, __alignof__(*svm));
-	if (!svm)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, sizeof(*svm) * nr, __alignof__(*svm));
+	svm = memblock_alloc_or_panic(sizeof(*svm) * nr, __alignof__(*svm));
 
 	for (md = io_desc; nr; md++, nr--) {
 		create_mapping(md);
@@ -1052,10 +1044,7 @@ void __init vm_reserve_area_early(unsigned long addr, unsigned long size,
 	struct vm_struct *vm;
 	struct static_vm *svm;
 
-	svm = memblock_alloc(sizeof(*svm), __alignof__(*svm));
-	if (!svm)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, sizeof(*svm), __alignof__(*svm));
+	svm = memblock_alloc_or_panic(sizeof(*svm), __alignof__(*svm));
 
 	vm = &svm->vm;
 	vm->addr = (void *)addr;
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index c415f3859b20..1a8f6914ee59 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -162,10 +162,7 @@ void __init paging_init(const struct machine_desc *mdesc)
 	mpu_setup();
 
 	/* allocate the zero page. */
-	zero_page = (void *)memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	zero_page = (void *)memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	bootmem_init();
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 4f613e8e0745..85104587f849 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -223,9 +223,7 @@ static void __init request_standard_resources(void)
 
 	num_standard_resources = memblock.memory.cnt;
 	res_size = num_standard_resources * sizeof(*standard_resources);
-	standard_resources = memblock_alloc(res_size, SMP_CACHE_BYTES);
-	if (!standard_resources)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, res_size);
+	standard_resources = memblock_alloc_or_panic(res_size, SMP_CACHE_BYTES);
 
 	for_each_mem_region(region) {
 		res = &standard_resources[i++];
diff --git a/arch/loongarch/kernel/setup.c b/arch/loongarch/kernel/setup.c
index 56934fe58170..edcfdfcad7d2 100644
--- a/arch/loongarch/kernel/setup.c
+++ b/arch/loongarch/kernel/setup.c
@@ -431,7 +431,7 @@ static void __init resource_init(void)
 
 	num_standard_resources = memblock.memory.cnt;
 	res_size = num_standard_resources * sizeof(*standard_resources);
-	standard_resources = memblock_alloc(res_size, SMP_CACHE_BYTES);
+	standard_resources = memblock_alloc_or_panic(res_size, SMP_CACHE_BYTES);
 
 	for_each_mem_region(region) {
 		res = &standard_resources[i++];
diff --git a/arch/loongarch/mm/init.c b/arch/loongarch/mm/init.c
index 188b52bbb254..ca5aa5f46a9f 100644
--- a/arch/loongarch/mm/init.c
+++ b/arch/loongarch/mm/init.c
@@ -174,9 +174,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 	pmd_t *pmd;
 
 	if (p4d_none(p4dp_get(p4d))) {
-		pud = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pud)
-			panic("%s: Failed to allocate memory\n", __func__);
+		pud = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		p4d_populate(&init_mm, p4d, pud);
 #ifndef __PAGETABLE_PUD_FOLDED
 		pud_init(pud);
@@ -185,9 +183,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 
 	pud = pud_offset(p4d, addr);
 	if (pud_none(pudp_get(pud))) {
-		pmd = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pmd)
-			panic("%s: Failed to allocate memory\n", __func__);
+		pmd = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 #ifndef __PAGETABLE_PMD_FOLDED
 		pmd_init(pmd);
@@ -198,10 +194,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 	if (!pmd_present(pmdp_get(pmd))) {
 		pte_t *pte;
 
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate memory\n", __func__);
-
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, pte);
 		kernel_pte_init(pte);
 	}
diff --git a/arch/m68k/mm/init.c b/arch/m68k/mm/init.c
index 1b47bec15832..8b11d0d545aa 100644
--- a/arch/m68k/mm/init.c
+++ b/arch/m68k/mm/init.c
@@ -68,10 +68,7 @@ void __init paging_init(void)
 
 	high_memory = (void *) end_mem;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	max_zone_pfn[ZONE_DMA] = end_mem >> PAGE_SHIFT;
 	free_area_init(max_zone_pfn);
 }
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index 9a6fa342e872..19a75029036c 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -42,20 +42,14 @@ void __init paging_init(void)
 	unsigned long max_zone_pfn[MAX_NR_ZONES] = { 0 };
 	int i;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	pg_dir = swapper_pg_dir;
 	memset(swapper_pg_dir, 0, sizeof(swapper_pg_dir));
 
 	size = num_pages * sizeof(pte_t);
 	size = (size + PAGE_SIZE) & ~(PAGE_SIZE-1);
-	next_pgtable = (unsigned long) memblock_alloc(size, PAGE_SIZE);
-	if (!next_pgtable)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, PAGE_SIZE);
+	next_pgtable = (unsigned long) memblock_alloc_or_panic(size, PAGE_SIZE);
 
 	pg_dir += PAGE_OFFSET >> PGDIR_SHIFT;
 
diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
index c1761d309fc6..795dd1f2b24f 100644
--- a/arch/m68k/mm/motorola.c
+++ b/arch/m68k/mm/motorola.c
@@ -491,10 +491,7 @@ void __init paging_init(void)
 	 * initialize the bad page table and bad page to point
 	 * to a couple of allocated pages
 	 */
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	/*
 	 * Set up SFC/DFC registers
diff --git a/arch/m68k/mm/sun3mmu.c b/arch/m68k/mm/sun3mmu.c
index 494739c1783e..1ecf6bdd08bf 100644
--- a/arch/m68k/mm/sun3mmu.c
+++ b/arch/m68k/mm/sun3mmu.c
@@ -44,10 +44,7 @@ void __init paging_init(void)
 	unsigned long max_zone_pfn[MAX_NR_ZONES] = { 0, };
 	unsigned long size;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	address = PAGE_OFFSET;
 	pg_dir = swapper_pg_dir;
@@ -57,10 +54,7 @@ void __init paging_init(void)
 	size = num_pages * sizeof(pte_t);
 	size = (size + PAGE_SIZE) & ~(PAGE_SIZE-1);
 
-	next_pgtable = (unsigned long)memblock_alloc(size, PAGE_SIZE);
-	if (!next_pgtable)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, PAGE_SIZE);
+	next_pgtable = (unsigned long)memblock_alloc_or_panic(size, PAGE_SIZE);
 	bootmem_end = (next_pgtable + size + PAGE_SIZE) & PAGE_MASK;
 
 	/* Map whole memory from PAGE_OFFSET (0x0E000000) */
diff --git a/arch/m68k/sun3/sun3dvma.c b/arch/m68k/sun3/sun3dvma.c
index 6ebf52740ad7..225fc735e466 100644
--- a/arch/m68k/sun3/sun3dvma.c
+++ b/arch/m68k/sun3/sun3dvma.c
@@ -252,12 +252,8 @@ void __init dvma_init(void)
 
 	list_add(&(hole->list), &hole_list);
 
-	iommu_use = memblock_alloc(IOMMU_TOTAL_ENTRIES * sizeof(unsigned long),
+	iommu_use = memblock_alloc_or_panic(IOMMU_TOTAL_ENTRIES * sizeof(unsigned long),
 				   SMP_CACHE_BYTES);
-	if (!iommu_use)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      IOMMU_TOTAL_ENTRIES * sizeof(unsigned long));
-
 	dvma_unmap_iommu(DVMA_START, DVMA_SIZE);
 
 	sun3_dvma_init();
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 12a1a4ffb602..fbfe0771317e 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -704,10 +704,7 @@ static void __init resource_init(void)
 	for_each_mem_range(i, &start, &end) {
 		struct resource *res;
 
-		res = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      sizeof(struct resource));
+		res = memblock_alloc_or_panic(sizeof(struct resource), SMP_CACHE_BYTES);
 
 		res->start = start;
 		/*
diff --git a/arch/openrisc/mm/ioremap.c b/arch/openrisc/mm/ioremap.c
index f59ea4c10b0f..8e63e86251ca 100644
--- a/arch/openrisc/mm/ioremap.c
+++ b/arch/openrisc/mm/ioremap.c
@@ -38,10 +38,7 @@ pte_t __ref *pte_alloc_one_kernel(struct mm_struct *mm)
 	if (likely(mem_init_done)) {
 		pte = (pte_t *)get_zeroed_page(GFP_KERNEL);
 	} else {
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	}
 
 	return pte;
diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index 96970fa75e4a..61c0a2477072 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -377,10 +377,8 @@ static void __ref map_pages(unsigned long start_vaddr,
 
 #if CONFIG_PGTABLE_LEVELS == 3
 		if (pud_none(*pud)) {
-			pmd = memblock_alloc(PAGE_SIZE << PMD_TABLE_ORDER,
+			pmd = memblock_alloc_or_panic(PAGE_SIZE << PMD_TABLE_ORDER,
 					     PAGE_SIZE << PMD_TABLE_ORDER);
-			if (!pmd)
-				panic("pmd allocation failed.\n");
 			pud_populate(NULL, pud, pmd);
 		}
 #endif
@@ -388,9 +386,7 @@ static void __ref map_pages(unsigned long start_vaddr,
 		pmd = pmd_offset(pud, vaddr);
 		for (tmp1 = start_pmd; tmp1 < PTRS_PER_PMD; tmp1++, pmd++) {
 			if (pmd_none(*pmd)) {
-				pg_table = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-				if (!pg_table)
-					panic("page table allocation failed\n");
+				pg_table = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 				pmd_populate_kernel(NULL, pmd, pg_table);
 			}
 
@@ -648,9 +644,7 @@ static void __init pagetable_init(void)
 	}
 #endif
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("zero page allocation failed.\n");
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 }
 
@@ -687,19 +681,15 @@ static void __init fixmap_init(void)
 
 #if CONFIG_PGTABLE_LEVELS == 3
 	if (pud_none(*pud)) {
-		pmd = memblock_alloc(PAGE_SIZE << PMD_TABLE_ORDER,
+		pmd = memblock_alloc_or_panic(PAGE_SIZE << PMD_TABLE_ORDER,
 				     PAGE_SIZE << PMD_TABLE_ORDER);
-		if (!pmd)
-			panic("fixmap: pmd allocation failed.\n");
 		pud_populate(NULL, pud, pmd);
 	}
 #endif
 
 	pmd = pmd_offset(pud, addr);
 	do {
-		pte_t *pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("fixmap: pte allocation failed.\n");
+		pte_t *pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 		pmd_populate_kernel(&init_mm, pmd, pte);
 
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 1bee15c013e7..3af6c06af02f 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -1087,12 +1087,10 @@ static int __init dt_cpu_ftrs_scan_callback(unsigned long node, const char
 	/* Count and allocate space for cpu features */
 	of_scan_flat_dt_subnodes(node, count_cpufeatures_subnodes,
 						&nr_dt_cpu_features);
-	dt_cpu_features = memblock_alloc(sizeof(struct dt_cpu_feature) * nr_dt_cpu_features, PAGE_SIZE);
-	if (!dt_cpu_features)
-		panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
-		      __func__,
-		      sizeof(struct dt_cpu_feature) * nr_dt_cpu_features,
-		      PAGE_SIZE);
+	dt_cpu_features =
+		memblock_alloc_or_panic(
+			sizeof(struct dt_cpu_feature) * nr_dt_cpu_features,
+			PAGE_SIZE);
 
 	cpufeatures_setup_start(isa);
 
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index ce0c8623e563..f8a3bd8cfae4 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -213,11 +213,8 @@ pci_create_OF_bus_map(void)
 	struct property* of_prop;
 	struct device_node *dn;
 
-	of_prop = memblock_alloc(sizeof(struct property) + 256,
+	of_prop = memblock_alloc_or_panic(sizeof(struct property) + 256,
 				 SMP_CACHE_BYTES);
-	if (!of_prop)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct property) + 256);
 	dn = of_find_node_by_path("/");
 	if (dn) {
 		memset(of_prop, -1, sizeof(struct property) + 256);
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 6fa179448c33..f3ea1329c566 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -458,11 +458,8 @@ void __init smp_setup_cpu_maps(void)
 
 	DBG("smp_setup_cpu_maps()\n");
 
-	cpu_to_phys_id = memblock_alloc(nr_cpu_ids * sizeof(u32),
+	cpu_to_phys_id = memblock_alloc_or_panic(nr_cpu_ids * sizeof(u32),
 					__alignof__(u32));
-	if (!cpu_to_phys_id)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, nr_cpu_ids * sizeof(u32), __alignof__(u32));
 
 	for_each_node_by_type(dn, "cpu") {
 		const __be32 *intserv;
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 75dbf3e0d9c4..5a1bf501fbe1 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -140,13 +140,7 @@ arch_initcall(ppc_init);
 
 static void *__init alloc_stack(void)
 {
-	void *ptr = memblock_alloc(THREAD_SIZE, THREAD_ALIGN);
-
-	if (!ptr)
-		panic("cannot allocate %d bytes for stack at %pS\n",
-		      THREAD_SIZE, (void *)_RET_IP_);
-
-	return ptr;
+	return memblock_alloc_or_panic(THREAD_SIZE, THREAD_ALIGN);
 }
 
 void __init irqstack_early_init(void)
diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/mmu.c
index 6978344edcb4..be9c4106e22f 100644
--- a/arch/powerpc/mm/book3s32/mmu.c
+++ b/arch/powerpc/mm/book3s32/mmu.c
@@ -377,10 +377,7 @@ void __init MMU_init_hw(void)
 	 * Find some memory for the hash table.
 	 */
 	if ( ppc_md.progress ) ppc_md.progress("hash:find piece", 0x322);
-	Hash = memblock_alloc(Hash_size, Hash_size);
-	if (!Hash)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, Hash_size, Hash_size);
+	Hash = memblock_alloc_or_panic(Hash_size, Hash_size);
 	_SDR1 = __pa(Hash) | SDR1_LOW_BITS;
 
 	pr_info("Total memory = %lldMB; using %ldkB for hash table\n",
diff --git a/arch/powerpc/mm/book3s64/pgtable.c b/arch/powerpc/mm/book3s64/pgtable.c
index 374542528080..0b1f419b7404 100644
--- a/arch/powerpc/mm/book3s64/pgtable.c
+++ b/arch/powerpc/mm/book3s64/pgtable.c
@@ -330,11 +330,7 @@ void __init mmu_partition_table_init(void)
 	unsigned long ptcr;
 
 	/* Initialize the Partition Table with no entries */
-	partition_tb = memblock_alloc(patb_size, patb_size);
-	if (!partition_tb)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, patb_size, patb_size);
-
+	partition_tb = memblock_alloc_or_panic(patb_size, patb_size);
 	ptcr = __pa(partition_tb) | (PATB_SIZE_SHIFT - 12);
 	set_ptcr_when_no_uv(ptcr);
 	powernv_set_nmmu_ptcr(ptcr);
diff --git a/arch/powerpc/mm/kasan/init_book3e_64.c b/arch/powerpc/mm/kasan/init_book3e_64.c
index 43c03b84ff32..60c78aac0f63 100644
--- a/arch/powerpc/mm/kasan/init_book3e_64.c
+++ b/arch/powerpc/mm/kasan/init_book3e_64.c
@@ -40,19 +40,19 @@ static int __init kasan_map_kernel_page(unsigned long ea, unsigned long pa, pgpr
 	pgdp = pgd_offset_k(ea);
 	p4dp = p4d_offset(pgdp, ea);
 	if (kasan_pud_table(*p4dp)) {
-		pudp = memblock_alloc(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
+		pudp = memblock_alloc_or_panic(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
 		memcpy(pudp, kasan_early_shadow_pud, PUD_TABLE_SIZE);
 		p4d_populate(&init_mm, p4dp, pudp);
 	}
 	pudp = pud_offset(p4dp, ea);
 	if (kasan_pmd_table(*pudp)) {
-		pmdp = memblock_alloc(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
+		pmdp = memblock_alloc_or_panic(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
 		memcpy(pmdp, kasan_early_shadow_pmd, PMD_TABLE_SIZE);
 		pud_populate(&init_mm, pudp, pmdp);
 	}
 	pmdp = pmd_offset(pudp, ea);
 	if (kasan_pte_table(*pmdp)) {
-		ptep = memblock_alloc(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
+		ptep = memblock_alloc_or_panic(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
 		memcpy(ptep, kasan_early_shadow_pte, PTE_TABLE_SIZE);
 		pmd_populate_kernel(&init_mm, pmdp, ptep);
 	}
@@ -74,7 +74,7 @@ static void __init kasan_init_phys_region(void *start, void *end)
 	k_start = ALIGN_DOWN((unsigned long)kasan_mem_to_shadow(start), PAGE_SIZE);
 	k_end = ALIGN((unsigned long)kasan_mem_to_shadow(end), PAGE_SIZE);
 
-	va = memblock_alloc(k_end - k_start, PAGE_SIZE);
+	va = memblock_alloc_or_panic(k_end - k_start, PAGE_SIZE);
 	for (k_cur = k_start; k_cur < k_end; k_cur += PAGE_SIZE, va += PAGE_SIZE)
 		kasan_map_kernel_page(k_cur, __pa(va), PAGE_KERNEL);
 }
diff --git a/arch/powerpc/mm/kasan/init_book3s_64.c b/arch/powerpc/mm/kasan/init_book3s_64.c
index 3fb5ce4f48f4..7d959544c077 100644
--- a/arch/powerpc/mm/kasan/init_book3s_64.c
+++ b/arch/powerpc/mm/kasan/init_book3s_64.c
@@ -32,7 +32,7 @@ static void __init kasan_init_phys_region(void *start, void *end)
 	k_start = ALIGN_DOWN((unsigned long)kasan_mem_to_shadow(start), PAGE_SIZE);
 	k_end = ALIGN((unsigned long)kasan_mem_to_shadow(end), PAGE_SIZE);
 
-	va = memblock_alloc(k_end - k_start, PAGE_SIZE);
+	va = memblock_alloc_or_panic(k_end - k_start, PAGE_SIZE);
 	for (k_cur = k_start; k_cur < k_end; k_cur += PAGE_SIZE, va += PAGE_SIZE)
 		map_kernel_page(k_cur, __pa(va), PAGE_KERNEL);
 }
diff --git a/arch/powerpc/mm/nohash/mmu_context.c b/arch/powerpc/mm/nohash/mmu_context.c
index 0b181da40ddb..a1a4e697251a 100644
--- a/arch/powerpc/mm/nohash/mmu_context.c
+++ b/arch/powerpc/mm/nohash/mmu_context.c
@@ -385,21 +385,11 @@ void __init mmu_context_init(void)
 	/*
 	 * Allocate the maps used by context management
 	 */
-	context_map = memblock_alloc(CTX_MAP_SIZE, SMP_CACHE_BYTES);
-	if (!context_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      CTX_MAP_SIZE);
-	context_mm = memblock_alloc(sizeof(void *) * (LAST_CONTEXT + 1),
+	context_map = memblock_alloc_or_panic(CTX_MAP_SIZE, SMP_CACHE_BYTES);
+	context_mm = memblock_alloc_or_panic(sizeof(void *) * (LAST_CONTEXT + 1),
 				    SMP_CACHE_BYTES);
-	if (!context_mm)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(void *) * (LAST_CONTEXT + 1));
 	if (IS_ENABLED(CONFIG_SMP)) {
-		stale_map[boot_cpuid] = memblock_alloc(CTX_MAP_SIZE, SMP_CACHE_BYTES);
-		if (!stale_map[boot_cpuid])
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      CTX_MAP_SIZE);
-
+		stale_map[boot_cpuid] = memblock_alloc_or_panic(CTX_MAP_SIZE, SMP_CACHE_BYTES);
 		cpuhp_setup_state_nocalls(CPUHP_POWERPC_MMU_CTX_PREPARE,
 					  "powerpc/mmu/ctx:prepare",
 					  mmu_ctx_cpu_prepare, mmu_ctx_cpu_dead);
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 787b22206386..15276068f657 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -50,13 +50,8 @@ notrace void __init early_ioremap_init(void)
 
 void __init *early_alloc_pgtable(unsigned long size)
 {
-	void *ptr = memblock_alloc(size, size);
+	return memblock_alloc_or_panic(size, size);
 
-	if (!ptr)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, size);
-
-	return ptr;
 }
 
 pte_t __init *early_pte_alloc_kernel(pmd_t *pmdp, unsigned long va)
diff --git a/arch/powerpc/platforms/powermac/nvram.c b/arch/powerpc/platforms/powermac/nvram.c
index fe2e0249cbc2..a112d26185a0 100644
--- a/arch/powerpc/platforms/powermac/nvram.c
+++ b/arch/powerpc/platforms/powermac/nvram.c
@@ -514,10 +514,7 @@ static int __init core99_nvram_setup(struct device_node *dp, unsigned long addr)
 		printk(KERN_ERR "nvram: no address\n");
 		return -EINVAL;
 	}
-	nvram_image = memblock_alloc(NVRAM_SIZE, SMP_CACHE_BYTES);
-	if (!nvram_image)
-		panic("%s: Failed to allocate %u bytes\n", __func__,
-		      NVRAM_SIZE);
+	nvram_image = memblock_alloc_or_panic(NVRAM_SIZE, SMP_CACHE_BYTES);
 	nvram_data = ioremap(addr, NVRAM_SIZE*2);
 	nvram_naddrs = 1; /* Make sure we get the correct case */
 
diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
index 5d0f35bb917e..09bd93464b4f 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -180,10 +180,7 @@ int __init early_init_dt_scan_recoverable_ranges(unsigned long node,
 	/*
 	 * Allocate a buffer to hold the MC recoverable ranges.
 	 */
-	mc_recoverable_range = memblock_alloc(size, __alignof__(u64));
-	if (!mc_recoverable_range)
-		panic("%s: Failed to allocate %u bytes align=0x%lx\n",
-		      __func__, size, __alignof__(u64));
+	mc_recoverable_range = memblock_alloc_or_panic(size, __alignof__(u64));
 
 	for (i = 0; i < mc_recoverable_range_len; i++) {
 		mc_recoverable_range[i].start_addr =
diff --git a/arch/powerpc/platforms/ps3/setup.c b/arch/powerpc/platforms/ps3/setup.c
index 5144f11359f7..150c09b58ae8 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -115,10 +115,7 @@ static void __init prealloc(struct ps3_prealloc *p)
 	if (!p->size)
 		return;
 
-	p->address = memblock_alloc(p->size, p->align);
-	if (!p->address)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, p->size, p->align);
+	p->address = memblock_alloc_or_panic(p->size, p->align);
 
 	printk(KERN_INFO "%s: %lu bytes at %p\n", p->name, p->size,
 	       p->address);
diff --git a/arch/powerpc/sysdev/msi_bitmap.c b/arch/powerpc/sysdev/msi_bitmap.c
index 0b6e37f3ffb8..456a4f64ae0a 100644
--- a/arch/powerpc/sysdev/msi_bitmap.c
+++ b/arch/powerpc/sysdev/msi_bitmap.c
@@ -124,10 +124,7 @@ int __ref msi_bitmap_alloc(struct msi_bitmap *bmp, unsigned int irq_count,
 	if (bmp->bitmap_from_slab)
 		bmp->bitmap = kzalloc(size, GFP_KERNEL);
 	else {
-		bmp->bitmap = memblock_alloc(size, SMP_CACHE_BYTES);
-		if (!bmp->bitmap)
-			panic("%s: Failed to allocate %u bytes\n", __func__,
-			      size);
+		bmp->bitmap = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 		/* the bitmap won't be freed from memblock allocator */
 		kmemleak_not_leak(bmp->bitmap);
 	}
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 45010e71df86..f1793630fc51 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -147,9 +147,7 @@ static void __init init_resources(void)
 	res_idx = num_resources - 1;
 
 	mem_res_sz = num_resources * sizeof(*mem_res);
-	mem_res = memblock_alloc(mem_res_sz, SMP_CACHE_BYTES);
-	if (!mem_res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, mem_res_sz);
+	mem_res = memblock_alloc_or_panic(mem_res_sz, SMP_CACHE_BYTES);
 
 	/*
 	 * Start by adding the reserved regions, if they overlap
diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index c301c8d291d2..41c635d6aca4 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -32,7 +32,7 @@ static void __init kasan_populate_pte(pmd_t *pmd, unsigned long vaddr, unsigned
 	pte_t *ptep, *p;
 
 	if (pmd_none(pmdp_get(pmd))) {
-		p = memblock_alloc(PTRS_PER_PTE * sizeof(pte_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PTE * sizeof(pte_t), PAGE_SIZE);
 		set_pmd(pmd, pfn_pmd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -54,7 +54,7 @@ static void __init kasan_populate_pmd(pud_t *pud, unsigned long vaddr, unsigned
 	unsigned long next;
 
 	if (pud_none(pudp_get(pud))) {
-		p = memblock_alloc(PTRS_PER_PMD * sizeof(pmd_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PMD * sizeof(pmd_t), PAGE_SIZE);
 		set_pud(pud, pfn_pud(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -85,7 +85,7 @@ static void __init kasan_populate_pud(p4d_t *p4d,
 	unsigned long next;
 
 	if (p4d_none(p4dp_get(p4d))) {
-		p = memblock_alloc(PTRS_PER_PUD * sizeof(pud_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PUD * sizeof(pud_t), PAGE_SIZE);
 		set_p4d(p4d, pfn_p4d(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -116,7 +116,7 @@ static void __init kasan_populate_p4d(pgd_t *pgd,
 	unsigned long next;
 
 	if (pgd_none(pgdp_get(pgd))) {
-		p = memblock_alloc(PTRS_PER_P4D * sizeof(p4d_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_P4D * sizeof(p4d_t), PAGE_SIZE);
 		set_pgd(pgd, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -385,7 +385,7 @@ static void __init kasan_shallow_populate_pud(p4d_t *p4d,
 		next = pud_addr_end(vaddr, end);
 
 		if (pud_none(pudp_get(pud_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_pud(pud_k, pfn_pud(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
@@ -405,7 +405,7 @@ static void __init kasan_shallow_populate_p4d(pgd_t *pgd,
 		next = p4d_addr_end(vaddr, end);
 
 		if (p4d_none(p4dp_get(p4d_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_p4d(p4d_k, pfn_p4d(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
@@ -424,7 +424,7 @@ static void __init kasan_shallow_populate_pgd(unsigned long vaddr, unsigned long
 		next = pgd_addr_end(vaddr, end);
 
 		if (pgd_none(pgdp_get(pgd_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_pgd(pgd_k, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
diff --git a/arch/s390/kernel/numa.c b/arch/s390/kernel/numa.c
index ddc1448ea2e1..a33e20f73330 100644
--- a/arch/s390/kernel/numa.c
+++ b/arch/s390/kernel/numa.c
@@ -22,10 +22,7 @@ void __init numa_setup(void)
 	node_set(0, node_possible_map);
 	node_set_online(0);
 	for (nid = 0; nid < MAX_NUMNODES; nid++) {
-		NODE_DATA(nid) = memblock_alloc(sizeof(pg_data_t), 8);
-		if (!NODE_DATA(nid))
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(pg_data_t), 8);
+		NODE_DATA(nid) = memblock_alloc_or_panic(sizeof(pg_data_t), 8);
 	}
 	NODE_DATA(0)->node_spanned_pages = memblock_end_of_DRAM() >> PAGE_SHIFT;
 	NODE_DATA(0)->node_id = 0;
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index 0ce550faf073..1298f0860733 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -376,11 +376,7 @@ static unsigned long __init stack_alloc_early(void)
 {
 	unsigned long stack;
 
-	stack = (unsigned long)memblock_alloc(THREAD_SIZE, THREAD_SIZE);
-	if (!stack) {
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, THREAD_SIZE, THREAD_SIZE);
-	}
+	stack = (unsigned long)memblock_alloc_or_panic(THREAD_SIZE, THREAD_SIZE);
 	return stack;
 }
 
@@ -504,10 +500,7 @@ static void __init setup_resources(void)
 	bss_resource.end = __pa_symbol(__bss_stop) - 1;
 
 	for_each_mem_range(i, &start, &end) {
-		res = memblock_alloc(sizeof(*res), 8);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(*res), 8);
+		res = memblock_alloc_or_panic(sizeof(*res), 8);
 		res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
 
 		res->name = "System RAM";
@@ -526,10 +519,7 @@ static void __init setup_resources(void)
 			    std_res->start > res->end)
 				continue;
 			if (std_res->end > res->end) {
-				sub_res = memblock_alloc(sizeof(*sub_res), 8);
-				if (!sub_res)
-					panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-					      __func__, sizeof(*sub_res), 8);
+				sub_res = memblock_alloc_or_panic(sizeof(*sub_res), 8);
 				*sub_res = *std_res;
 				sub_res->end = res->end;
 				std_res->start = res->end + 1;
@@ -816,9 +806,7 @@ static void __init setup_randomness(void)
 {
 	struct sysinfo_3_2_2 *vmms;
 
-	vmms = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!vmms)
-		panic("Failed to allocate memory for sysinfo structure\n");
+	vmms = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	if (stsi(vmms, 3, 2, 2) == 0 && vmms->count)
 		add_device_randomness(&vmms->vm, sizeof(vmms->vm[0]) * vmms->count);
 	memblock_free(vmms, PAGE_SIZE);
diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
index 822d8e6f8717..d77aaefb59bd 100644
--- a/arch/s390/kernel/smp.c
+++ b/arch/s390/kernel/smp.c
@@ -611,9 +611,9 @@ void __init smp_save_dump_ipl_cpu(void)
 	if (!dump_available())
 		return;
 	sa = save_area_alloc(true);
-	regs = memblock_alloc(512, 8);
-	if (!sa || !regs)
+	if (!sa)
 		panic("could not allocate memory for boot CPU save area\n");
+	regs = memblock_alloc_or_panic(512, 8);
 	copy_oldmem_kernel(regs, __LC_FPREGS_SAVE_AREA, 512);
 	save_area_add_regs(sa, regs);
 	memblock_free(regs, 512);
@@ -792,10 +792,7 @@ void __init smp_detect_cpus(void)
 	u16 address;
 
 	/* Get CPU information */
-	info = memblock_alloc(sizeof(*info), 8);
-	if (!info)
-		panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-		      __func__, sizeof(*info), 8);
+	info = memblock_alloc_or_panic(sizeof(*info), 8);
 	smp_get_core_info(info, 1);
 	/* Find boot CPU type */
 	if (sclp.has_core_type) {
diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
index 0fd56a1cadbd..cf5ee6032c0b 100644
--- a/arch/s390/kernel/topology.c
+++ b/arch/s390/kernel/topology.c
@@ -548,10 +548,7 @@ static void __init alloc_masks(struct sysinfo_15_1_x *info,
 		nr_masks *= info->mag[TOPOLOGY_NR_MAG - offset - 1 - i];
 	nr_masks = max(nr_masks, 1);
 	for (i = 0; i < nr_masks; i++) {
-		mask->next = memblock_alloc(sizeof(*mask->next), 8);
-		if (!mask->next)
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(*mask->next), 8);
+		mask->next = memblock_alloc_or_panic(sizeof(*mask->next), 8);
 		mask = mask->next;
 	}
 }
@@ -569,10 +566,7 @@ void __init topology_init_early(void)
 	}
 	if (!MACHINE_HAS_TOPOLOGY)
 		goto out;
-	tl_info = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!tl_info)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	tl_info = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	info = tl_info;
 	store_topology(info);
 	pr_info("The CPU configuration topology of the machine is: %d %d %d %d %d %d / %d\n",
diff --git a/arch/sh/mm/init.c b/arch/sh/mm/init.c
index 2a88b0c9e70f..289a2fecebef 100644
--- a/arch/sh/mm/init.c
+++ b/arch/sh/mm/init.c
@@ -137,10 +137,7 @@ static pmd_t * __init one_md_table_init(pud_t *pud)
 	if (pud_none(*pud)) {
 		pmd_t *pmd;
 
-		pmd = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pmd)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pmd = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 		BUG_ON(pmd != pmd_offset(pud, 0));
 	}
@@ -153,10 +150,7 @@ static pte_t * __init one_page_table_init(pmd_t *pmd)
 	if (pmd_none(*pmd)) {
 		pte_t *pte;
 
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, pte);
 		BUG_ON(pte != pte_offset_kernel(pmd, 0));
 	}
diff --git a/arch/sparc/kernel/prom_32.c b/arch/sparc/kernel/prom_32.c
index 3df960c137f7..a67dd67f10c8 100644
--- a/arch/sparc/kernel/prom_32.c
+++ b/arch/sparc/kernel/prom_32.c
@@ -28,9 +28,7 @@ void * __init prom_early_alloc(unsigned long size)
 {
 	void *ret;
 
-	ret = memblock_alloc(size, SMP_CACHE_BYTES);
-	if (!ret)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, size);
+	ret = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 
 	prom_early_allocated += size;
 
diff --git a/arch/sparc/mm/srmmu.c b/arch/sparc/mm/srmmu.c
index 9df51a62333d..e36c2a0ff748 100644
--- a/arch/sparc/mm/srmmu.c
+++ b/arch/sparc/mm/srmmu.c
@@ -277,19 +277,13 @@ static void __init srmmu_nocache_init(void)
 
 	bitmap_bits = srmmu_nocache_size >> SRMMU_NOCACHE_BITMAP_SHIFT;
 
-	srmmu_nocache_pool = memblock_alloc(srmmu_nocache_size,
+	srmmu_nocache_pool = memblock_alloc_or_panic(srmmu_nocache_size,
 					    SRMMU_NOCACHE_ALIGN_MAX);
-	if (!srmmu_nocache_pool)
-		panic("%s: Failed to allocate %lu bytes align=0x%x\n",
-		      __func__, srmmu_nocache_size, SRMMU_NOCACHE_ALIGN_MAX);
 	memset(srmmu_nocache_pool, 0, srmmu_nocache_size);
 
 	srmmu_nocache_bitmap =
-		memblock_alloc(BITS_TO_LONGS(bitmap_bits) * sizeof(long),
+		memblock_alloc_or_panic(BITS_TO_LONGS(bitmap_bits) * sizeof(long),
 			       SMP_CACHE_BYTES);
-	if (!srmmu_nocache_bitmap)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      BITS_TO_LONGS(bitmap_bits) * sizeof(long));
 	bit_map_init(&srmmu_nocache_map, srmmu_nocache_bitmap, bitmap_bits);
 
 	srmmu_swapper_pg_dir = __srmmu_get_nocache(SRMMU_PGD_TABLE_SIZE, SRMMU_PGD_TABLE_SIZE);
@@ -452,9 +446,7 @@ static void __init sparc_context_init(int numctx)
 	unsigned long size;
 
 	size = numctx * sizeof(struct ctx_list);
-	ctx_list_pool = memblock_alloc(size, SMP_CACHE_BYTES);
-	if (!ctx_list_pool)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, size);
+	ctx_list_pool = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 
 	for (ctx = 0; ctx < numctx; ctx++) {
 		struct ctx_list *clist;
diff --git a/arch/um/drivers/net_kern.c b/arch/um/drivers/net_kern.c
index 75d04fb4994a..d5a9c5aabaec 100644
--- a/arch/um/drivers/net_kern.c
+++ b/arch/um/drivers/net_kern.c
@@ -636,10 +636,7 @@ static int __init eth_setup(char *str)
 		return 1;
 	}
 
-	new = memblock_alloc(sizeof(*new), SMP_CACHE_BYTES);
-	if (!new)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*new));
+	new = memblock_alloc_or_panic(sizeof(*new), SMP_CACHE_BYTES);
 
 	INIT_LIST_HEAD(&new->list);
 	new->index = n;
diff --git a/arch/um/drivers/vector_kern.c b/arch/um/drivers/vector_kern.c
index 64c09db392c1..85b129e2b70b 100644
--- a/arch/um/drivers/vector_kern.c
+++ b/arch/um/drivers/vector_kern.c
@@ -1694,10 +1694,7 @@ static int __init vector_setup(char *str)
 				 str, error);
 		return 1;
 	}
-	new = memblock_alloc(sizeof(*new), SMP_CACHE_BYTES);
-	if (!new)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*new));
+	new = memblock_alloc_or_panic(sizeof(*new), SMP_CACHE_BYTES);
 	INIT_LIST_HEAD(&new->list);
 	new->unit = n;
 	new->arguments = str;
diff --git a/arch/um/kernel/load_file.c b/arch/um/kernel/load_file.c
index 5cecd0e291fb..cb9d178ab7d8 100644
--- a/arch/um/kernel/load_file.c
+++ b/arch/um/kernel/load_file.c
@@ -48,9 +48,7 @@ void *uml_load_file(const char *filename, unsigned long long *size)
 		return NULL;
 	}
 
-	area = memblock_alloc(*size, SMP_CACHE_BYTES);
-	if (!area)
-		panic("%s: Failed to allocate %llu bytes\n", __func__, *size);
+	area = memblock_alloc_or_panic(*size, SMP_CACHE_BYTES);
 
 	if (__uml_load_file(filename, area, *size)) {
 		memblock_free(area, *size);
diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index 499b41953e3c..fa218270c1db 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -1567,9 +1567,7 @@ static void __init alloc_runtime_data(int cpu)
 		struct svsm_ca *caa;
 
 		/* Allocate the SVSM CA page if an SVSM is present */
-		caa = memblock_alloc(sizeof(*caa), PAGE_SIZE);
-		if (!caa)
-			panic("Can't allocate SVSM CA page\n");
+		caa = memblock_alloc_or_panic(sizeof(*caa), PAGE_SIZE);
 
 		per_cpu(svsm_caa, cpu) = caa;
 		per_cpu(svsm_caa_pa, cpu) = __pa(caa);
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 3a44a9dc3fb7..7c15d6e83c37 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -911,11 +911,8 @@ static int __init acpi_parse_hpet(struct acpi_table_header *table)
 	 * the resource tree during the lateinit timeframe.
 	 */
 #define HPET_RESOURCE_NAME_SIZE 9
-	hpet_res = memblock_alloc(sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE,
+	hpet_res = memblock_alloc_or_panic(sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE,
 				  SMP_CACHE_BYTES);
-	if (!hpet_res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE);
 
 	hpet_res->name = (void *)&hpet_res[1];
 	hpet_res->flags = IORESOURCE_MEM;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 1029ea4ac8ba..a57d3fa7c6b6 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2503,9 +2503,7 @@ static struct resource * __init ioapic_setup_resources(void)
 	n = IOAPIC_RESOURCE_NAME_SIZE + sizeof(struct resource);
 	n *= nr_ioapics;
 
-	mem = memblock_alloc(n, SMP_CACHE_BYTES);
-	if (!mem)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, n);
+	mem = memblock_alloc_or_panic(n, SMP_CACHE_BYTES);
 	res = (void *)mem;
 
 	mem += sizeof(struct resource) * nr_ioapics;
@@ -2564,11 +2562,8 @@ void __init io_apic_init_mappings(void)
 #ifdef CONFIG_X86_32
 fake_ioapic_page:
 #endif
-			ioapic_phys = (unsigned long)memblock_alloc(PAGE_SIZE,
+			ioapic_phys = (unsigned long)memblock_alloc_or_panic(PAGE_SIZE,
 								    PAGE_SIZE);
-			if (!ioapic_phys)
-				panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-				      __func__, PAGE_SIZE, PAGE_SIZE);
 			ioapic_phys = __pa(ioapic_phys);
 		}
 		io_apic_set_fixmap(idx, ioapic_phys);
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 4893d30ce438..82b96ed9890a 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1146,11 +1146,8 @@ void __init e820__reserve_resources(void)
 	struct resource *res;
 	u64 end;
 
-	res = memblock_alloc(sizeof(*res) * e820_table->nr_entries,
+	res = memblock_alloc_or_panic(sizeof(*res) * e820_table->nr_entries,
 			     SMP_CACHE_BYTES);
-	if (!res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*res) * e820_table->nr_entries);
 	e820_res = res;
 
 	for (i = 0; i < e820_table->nr_entries; i++) {
diff --git a/arch/x86/platform/olpc/olpc_dt.c b/arch/x86/platform/olpc/olpc_dt.c
index 74ebd6882690..cf5dca2dbb91 100644
--- a/arch/x86/platform/olpc/olpc_dt.c
+++ b/arch/x86/platform/olpc/olpc_dt.c
@@ -136,11 +136,7 @@ void * __init prom_early_alloc(unsigned long size)
 		 * fast enough on the platforms we care about while minimizing
 		 * wasted bootmem) and hand off chunks of it to callers.
 		 */
-		res = memblock_alloc(chunk_size, SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      chunk_size);
-		BUG_ON(!res);
+		res = memblock_alloc_or_panic(chunk_size, SMP_CACHE_BYTES);
 		prom_early_allocated += chunk_size;
 		memset(res, 0, chunk_size);
 		free_mem = chunk_size;
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index b52d3e17e2c1..56914e21e303 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -178,13 +178,7 @@ static void p2m_init_identity(unsigned long *p2m, unsigned long pfn)
 static void * __ref alloc_p2m_page(void)
 {
 	if (unlikely(!slab_is_available())) {
-		void *ptr = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-
-		if (!ptr)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
-
-		return ptr;
+		return memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	}
 
 	return (void *)__get_free_page(GFP_KERNEL);
diff --git a/arch/xtensa/mm/kasan_init.c b/arch/xtensa/mm/kasan_init.c
index f00d122aa806..f39c4d83173a 100644
--- a/arch/xtensa/mm/kasan_init.c
+++ b/arch/xtensa/mm/kasan_init.c
@@ -39,11 +39,7 @@ static void __init populate(void *start, void *end)
 	unsigned long i, j;
 	unsigned long vaddr = (unsigned long)start;
 	pmd_t *pmd = pmd_off_k(vaddr);
-	pte_t *pte = memblock_alloc(n_pages * sizeof(pte_t), PAGE_SIZE);
-
-	if (!pte)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, n_pages * sizeof(pte_t), PAGE_SIZE);
+	pte_t *pte = memblock_alloc_or_panic(n_pages * sizeof(pte_t), PAGE_SIZE);
 
 	pr_debug("%s: %p - %p\n", __func__, start, end);
 
diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
index f2117fef7c7d..9c75dcc9a534 100644
--- a/drivers/clk/ti/clk.c
+++ b/drivers/clk/ti/clk.c
@@ -449,10 +449,7 @@ void __init omap2_clk_legacy_provider_init(int index, void __iomem *mem)
 {
 	struct clk_iomap *io;
 
-	io = memblock_alloc(sizeof(*io), SMP_CACHE_BYTES);
-	if (!io)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*io));
+	io = memblock_alloc_or_panic(sizeof(*io), SMP_CACHE_BYTES);
 
 	io->mem = mem;
 
diff --git a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
index a01bc5090cdf..a1534cc6c641 100644
--- a/drivers/macintosh/smu.c
+++ b/drivers/macintosh/smu.c
@@ -492,11 +492,7 @@ int __init smu_init (void)
 		goto fail_np;
 	}
 
-	smu = memblock_alloc(sizeof(struct smu_device), SMP_CACHE_BYTES);
-	if (!smu)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct smu_device));
-
+	smu = memblock_alloc_or_panic(sizeof(struct smu_device), SMP_CACHE_BYTES);
 	spin_lock_init(&smu->lock);
 	INIT_LIST_HEAD(&smu->cmd_list);
 	INIT_LIST_HEAD(&smu->cmd_i2c_list);
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 4b1e9f101ce3..809135e2c7f5 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1126,13 +1126,7 @@ void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
 
 static void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
 {
-	void *ptr = memblock_alloc(size, align);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %llu bytes align=0x%llx\n",
-		      __func__, size, align);
-
-	return ptr;
+	return memblock_alloc_or_panic(size, align);
 }
 
 bool __init early_init_dt_verify(void *dt_virt, phys_addr_t dt_phys)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index e50570629dc0..837eafa81636 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -3675,13 +3675,7 @@ static struct device_node *overlay_base_root;
 
 static void * __init dt_alloc_memory(u64 size, u64 align)
 {
-	void *ptr = memblock_alloc(size, align);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %llu bytes align=0x%llx\n",
-		      __func__, size, align);
-
-	return ptr;
+	return memblock_alloc_or_panic(size, align);
 }
 
 /*
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 673d5cae7c81..c73727c5c2e1 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -417,6 +417,12 @@ static __always_inline void *memblock_alloc(phys_addr_t size, phys_addr_t align)
 				      MEMBLOCK_ALLOC_ACCESSIBLE, NUMA_NO_NODE);
 }
 
+void *__memblock_alloc_or_panic(phys_addr_t size, phys_addr_t align,
+				       const char *func)
+
+#define memblock_alloc_or_panic(size, align)    \
+	 __memblock_alloc_or_panic(size, align, __func__)
+
 static inline void *memblock_alloc_raw(phys_addr_t size,
 					       phys_addr_t align)
 {
diff --git a/init/main.c b/init/main.c
index 893cb77aef22..2a1757826397 100644
--- a/init/main.c
+++ b/init/main.c
@@ -640,15 +640,11 @@ static void __init setup_command_line(char *command_line)
 
 	len = xlen + strlen(boot_command_line) + ilen + 1;
 
-	saved_command_line = memblock_alloc(len, SMP_CACHE_BYTES);
-	if (!saved_command_line)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, len);
+	saved_command_line = memblock_alloc_or_panic(len, SMP_CACHE_BYTES);
 
 	len = xlen + strlen(command_line) + 1;
 
-	static_command_line = memblock_alloc(len, SMP_CACHE_BYTES);
-	if (!static_command_line)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, len);
+	static_command_line = memblock_alloc_or_panic(len, SMP_CACHE_BYTES);
 
 	if (xlen) {
 		/*
@@ -1146,16 +1142,10 @@ static int __init initcall_blacklist(char *str)
 		str_entry = strsep(&str, ",");
 		if (str_entry) {
 			pr_debug("blacklisting initcall %s\n", str_entry);
-			entry = memblock_alloc(sizeof(*entry),
+			entry = memblock_alloc_or_panic(sizeof(*entry),
 					       SMP_CACHE_BYTES);
-			if (!entry)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, sizeof(*entry));
-			entry->buf = memblock_alloc(strlen(str_entry) + 1,
+			entry->buf = memblock_alloc_or_panic(strlen(str_entry) + 1,
 						    SMP_CACHE_BYTES);
-			if (!entry->buf)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, strlen(str_entry) + 1);
 			strcpy(entry->buf, str_entry);
 			list_add(&entry->next, &blacklisted_initcalls);
 		}
diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
index 30894d8f0a78..c9fb559a6399 100644
--- a/kernel/power/snapshot.c
+++ b/kernel/power/snapshot.c
@@ -1011,11 +1011,8 @@ void __init register_nosave_region(unsigned long start_pfn, unsigned long end_pf
 		}
 	}
 	/* This allocation cannot fail */
-	region = memblock_alloc(sizeof(struct nosave_region),
+	region = memblock_alloc_or_panic(sizeof(struct nosave_region),
 				SMP_CACHE_BYTES);
-	if (!region)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct nosave_region));
 	region->start_pfn = start_pfn;
 	region->end_pfn = end_pfn;
 	list_add_tail(®ion->list, &nosave_regions);
diff --git a/lib/cpumask.c b/lib/cpumask.c
index e77ee9d46f71..57274ba8b6d9 100644
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@ -83,10 +83,7 @@ EXPORT_SYMBOL(alloc_cpumask_var_node);
  */
 void __init alloc_bootmem_cpumask_var(cpumask_var_t *mask)
 {
-	*mask = memblock_alloc(cpumask_size(), SMP_CACHE_BYTES);
-	if (!*mask)
-		panic("%s: Failed to allocate %u bytes\n", __func__,
-		      cpumask_size());
+	*mask = memblock_alloc_or_panic(cpumask_size(), SMP_CACHE_BYTES);
 }
 
 /**
diff --git a/mm/kmsan/shadow.c b/mm/kmsan/shadow.c
index 9c58f081d84f..1bb505a08415 100644
--- a/mm/kmsan/shadow.c
+++ b/mm/kmsan/shadow.c
@@ -280,12 +280,8 @@ void __init kmsan_init_alloc_meta_for_range(void *start, void *end)
 
 	start = (void *)PAGE_ALIGN_DOWN((u64)start);
 	size = PAGE_ALIGN((u64)end - (u64)start);
-	shadow = memblock_alloc(size, PAGE_SIZE);
-	origin = memblock_alloc(size, PAGE_SIZE);
-
-	if (!shadow || !origin)
-		panic("%s: Failed to allocate metadata memory for early boot range of size %llu",
-		      __func__, size);
+	shadow = memblock_alloc_or_panic(size, PAGE_SIZE);
+	origin = memblock_alloc_or_panic(size, PAGE_SIZE);
 
 	for (u64 addr = 0; addr < size; addr += PAGE_SIZE) {
 		page = virt_to_page_or_null((char *)start + addr);
diff --git a/mm/memblock.c b/mm/memblock.c
index 095c18b5c430..762eadd07d88 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1691,6 +1691,26 @@ void * __init memblock_alloc_try_nid(
 	return ptr;
 }
 
+/**
+ * __memblock_alloc_or_panic - Try to allocate memory and panic on failure
+ * @size: size of memory block to be allocated in bytes
+ * @align: alignment of the region and block's size
+ * @fuc: caller func name
+ *
+ * This function attempts to allocate memory using memblock_alloc,
+ * and in case of failure, it calls panic with the formatted message.
+ * This function should not be used directly, please use the macro memblock_alloc_or_panic.
+ */
+void *__init __memblock_alloc_or_panic(phys_addr_t size, phys_addr_t align,
+				       const char *func)
+{
+	void *addr = memblock_alloc(size, align);
+
+	if (unlikely(!addr))
+		panic("%s: Failed to allocate %pap bytes\n", func, &size);
+	return addr;
+}
+
 /**
  * memblock_free_late - free pages directly to buddy allocator
  * @base: phys starting address of the  boot memory block
diff --git a/mm/numa.c b/mm/numa.c
index e2eec07707d1..f1787d7713a6 100644
--- a/mm/numa.c
+++ b/mm/numa.c
@@ -37,13 +37,7 @@ void __init alloc_node_data(int nid)
 void __init alloc_offline_node_data(int nid)
 {
 	pg_data_t *pgdat;
-
-	pgdat = memblock_alloc(sizeof(*pgdat), SMP_CACHE_BYTES);
-	if (!pgdat)
-		panic("Cannot allocate %zuB for node %d.\n",
-		      sizeof(*pgdat), nid);
-
-	node_data[nid] = pgdat;
+	node_data[nid] = memblock_alloc_or_panic(sizeof(*pgdat), SMP_CACHE_BYTES);
 }
 
 /* Stub functions: */
diff --git a/mm/percpu.c b/mm/percpu.c
index d8dd31a2e407..ac61e3fc5f15 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1359,10 +1359,7 @@ static struct pcpu_chunk * __init pcpu_alloc_first_chunk(unsigned long tmp_addr,
 	/* allocate chunk */
 	alloc_size = struct_size(chunk, populated,
 				 BITS_TO_LONGS(region_size >> PAGE_SHIFT));
-	chunk = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	INIT_LIST_HEAD(&chunk->list);
 
@@ -1374,24 +1371,14 @@ static struct pcpu_chunk * __init pcpu_alloc_first_chunk(unsigned long tmp_addr,
 	region_bits = pcpu_chunk_map_bits(chunk);
 
 	alloc_size = BITS_TO_LONGS(region_bits) * sizeof(chunk->alloc_map[0]);
-	chunk->alloc_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->alloc_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk->alloc_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size =
 		BITS_TO_LONGS(region_bits + 1) * sizeof(chunk->bound_map[0]);
-	chunk->bound_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->bound_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk->bound_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = pcpu_chunk_nr_blocks(chunk) * sizeof(chunk->md_blocks[0]);
-	chunk->md_blocks = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->md_blocks)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
-
+	chunk->md_blocks = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 #ifdef NEED_PCPUOBJ_EXT
 	/* first chunk is free to use */
 	chunk->obj_exts = NULL;
@@ -2595,28 +2582,16 @@ void __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
 
 	/* process group information and build config tables accordingly */
 	alloc_size = ai->nr_groups * sizeof(group_offsets[0]);
-	group_offsets = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!group_offsets)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	group_offsets = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = ai->nr_groups * sizeof(group_sizes[0]);
-	group_sizes = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!group_sizes)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	group_sizes = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = nr_cpu_ids * sizeof(unit_map[0]);
-	unit_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!unit_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	unit_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = nr_cpu_ids * sizeof(unit_off[0]);
-	unit_off = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!unit_off)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	unit_off = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	for (cpu = 0; cpu < nr_cpu_ids; cpu++)
 		unit_map[cpu] = UINT_MAX;
@@ -2685,12 +2660,9 @@ void __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
 	pcpu_free_slot = pcpu_sidelined_slot + 1;
 	pcpu_to_depopulate_slot = pcpu_free_slot + 1;
 	pcpu_nr_slots = pcpu_to_depopulate_slot + 1;
-	pcpu_chunk_lists = memblock_alloc(pcpu_nr_slots *
+	pcpu_chunk_lists = memblock_alloc_or_panic(pcpu_nr_slots *
 					  sizeof(pcpu_chunk_lists[0]),
 					  SMP_CACHE_BYTES);
-	if (!pcpu_chunk_lists)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      pcpu_nr_slots * sizeof(pcpu_chunk_lists[0]));
 
 	for (i = 0; i < pcpu_nr_slots; i++)
 		INIT_LIST_HEAD(&pcpu_chunk_lists[i]);
@@ -3155,25 +3127,19 @@ void __init __weak pcpu_populate_pte(unsigned long addr)
 	pmd_t *pmd;
 
 	if (pgd_none(*pgd)) {
-		p4d = memblock_alloc(P4D_TABLE_SIZE, P4D_TABLE_SIZE);
-		if (!p4d)
-			goto err_alloc;
+		p4d = memblock_alloc_or_panic(P4D_TABLE_SIZE, P4D_TABLE_SIZE);
 		pgd_populate(&init_mm, pgd, p4d);
 	}
 
 	p4d = p4d_offset(pgd, addr);
 	if (p4d_none(*p4d)) {
-		pud = memblock_alloc(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
-		if (!pud)
-			goto err_alloc;
+		pud = memblock_alloc_or_panic(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
 		p4d_populate(&init_mm, p4d, pud);
 	}
 
 	pud = pud_offset(p4d, addr);
 	if (pud_none(*pud)) {
-		pmd = memblock_alloc(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
-		if (!pmd)
-			goto err_alloc;
+		pmd = memblock_alloc_or_panic(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 	}
 
@@ -3181,16 +3147,11 @@ void __init __weak pcpu_populate_pte(unsigned long addr)
 	if (!pmd_present(*pmd)) {
 		pte_t *new;
 
-		new = memblock_alloc(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
-		if (!new)
-			goto err_alloc;
+		new = memblock_alloc_or_panic(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, new);
 	}
 
 	return;
-
-err_alloc:
-	panic("%s: Failed to allocate memory\n", __func__);
 }
 
 /**
@@ -3237,10 +3198,7 @@ int __init pcpu_page_first_chunk(size_t reserved_size, pcpu_fc_cpu_to_node_fn_t
 	/* unaligned allocations can't be freed, round up to page size */
 	pages_size = PFN_ALIGN(unit_pages * num_possible_cpus() *
 			       sizeof(pages[0]));
-	pages = memblock_alloc(pages_size, SMP_CACHE_BYTES);
-	if (!pages)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      pages_size);
+	pages = memblock_alloc_or_panic(pages_size, SMP_CACHE_BYTES);
 
 	/* allocate pages */
 	j = 0;
diff --git a/mm/sparse.c b/mm/sparse.c
index 13b6624d3562..133b033d0cba 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -257,10 +257,7 @@ static void __init memblocks_present(void)
 
 		size = sizeof(struct mem_section *) * NR_SECTION_ROOTS;
 		align = 1 << (INTERNODE_CACHE_SHIFT);
-		mem_section = memblock_alloc(size, align);
-		if (!mem_section)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, size, align);
+		mem_section = memblock_alloc_or_panic(size, align);
 	}
 #endif
 
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Sun Dec 22 03:04:32 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Dec 2024 03:04:32 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862594.1274203 (Exim 4.92)
	(envelope-from )
	id 1tPCGM-0001AR-3N; Sun, 22 Dec 2024 03:04:14 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862594.1274203; Sun, 22 Dec 2024 03:04: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 1tPCGM-0001AK-0N; Sun, 22 Dec 2024 03:04:14 +0000
Received: by outflank-mailman (input) for mailman id 862594;
 Sun, 22 Dec 2024 03:04: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 1tPCGK-0001AE-Nf
 for xen-devel@lists.xenproject.org; Sun, 22 Dec 2024 03:04:13 +0000
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com
 [2607:f8b0:4864:20::436])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 68614cd9-c011-11ef-99a3-01e77a169b0f;
 Sun, 22 Dec 2024 04:04:07 +0100 (CET)
Received: by mail-pf1-x436.google.com with SMTP id
 d2e1a72fcca58-728ea1e0bdbso2926749b3a.0
 for ; Sat, 21 Dec 2024 19:04:07 -0800 (PST)
Received: from localhost.localdomain ([36.110.106.149])
 by smtp.gmail.com with ESMTPSA id
 d2e1a72fcca58-72aad90c112sm5415064b3a.198.2024.12.21.19.03.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 21 Dec 2024 19:04:05 -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: 68614cd9-c011-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734836646; x=1735441446; 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=bLwIVhlTf1b/URUp5p09XK9G7aK+ploAUOErazD1ENw=;
        b=IbDpKGVZtkP0VRzFa37GpzMFHSF4i57r+xmlaXOiXsh3t8CtMM90kAxmJFl1Hs2kQY
         7HJ7M8GSedYI5eFXAouB69HyxOwxd5Gobtr0vBltOE9P9W3DLIXeP+V34o/5knHmNx5n
         Mjjk0XTJpMGCpx0B58/H5mgJsFoAk0kYZ4Nks2krIAeEcOCPYD5bysttRXYoAtExPgqX
         Baw/94wgWNVQdU7PBA4dXUldKmup0NzHD0WNvCTMOuLTZ0MYQwPJ4Xv+sY16lw+u3C1x
         lwVml0Si0DqCzVHQHB8DTk7b+b6CwZe8VSKd0EVclmbgkeglMZmfW+65bEfN4E0cnSDM
         IuYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734836646; x=1735441446;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=bLwIVhlTf1b/URUp5p09XK9G7aK+ploAUOErazD1ENw=;
        b=AFlTsiidF7ENkgx/Lvv5krvnY5jYEBrgDr6UmjLGFbdwE7okMKiy7nzDh+cDVL7eXQ
         tK1eelx5l/NNBdt6KnTeaGANHT1leAHZVbCRIAG2+sSWu6Eh93p14A8WmN7zCDyN07F+
         RisySsK/0MiP1JAQwzwM5mDit4SskzerGdEzwmOrdvL75DEzloV4v29/RqP5U4eH98Se
         yzQ9db3ijVAZ8brns0IAewgjxbb2qNQNoi0w2bJ0VO75MTogqAFpmha5YhOeXymWWwK+
         1ENR9CTkys1flsae7mKBise+YSgfYOrTOTmG9CHYP/GeevoMLR2PswyirBqbBT7V+EWL
         FO/w==
X-Forwarded-Encrypted: i=1; AJvYcCXSBthVHq3PjR7JZsCFi4WXV3rAg50Z2/gNauZQMo5EOaTIDgFqbAbzIFj190rHPJaZANRxz0JNHJA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxBR2Sr53LpvsiGaE5DzP8B4D26rRoOm0KXQqCQTFO4EpB9f1Kz
	xcDcNfUD34hvrTKuZm3mvJoh/FZFBpzHguI/uvRbvNYDP+W4peTR
X-Gm-Gg: ASbGnctRm7Mz8nuuNoqVlxdE/aM86n65C4tDBcNqRObVHyb3pGaMCk7JGATL8x4V8LJ
	vNvZHWsLpwpQYGN1Ya3+HwVbi0FQ0p7TZkPNENXdFPcACiiwnjG0emZcSATuKXuKQ4jR0CA0ePA
	ZgHEafCR6EfsvaXiBCqz7uyJa0eUYwqH4i9RyzAtRcDv8TTgYAEdSPYTOBecxfWXbmCWkejQRU9
	jUmOPzx+HGgDJ9LvYQHRwgcCsFRd2wqHfIby6zgVYQk2TnfQg6eQ3R8UGSv3aFBzssqM3RV2jKi
	6T1n
X-Google-Smtp-Source: AGHT+IGEIrG1JtXc5z5cMox7Uha9/g1RZbcpsJzVDo5QUHRN78eE18poKknQIYmVHIO9ksCE0JNJKQ==
X-Received: by 2002:a05:6a20:2443:b0:1e1:ace6:c98 with SMTP id adf61e73a8af0-1e5e081cb7dmr14215452637.43.1734836645740;
        Sat, 21 Dec 2024 19:04:05 -0800 (PST)
From: Guo Weikang 
To: Andrew Morton ,
	Mike Rapoport ,
	Geert Uytterhoeven ,
	Guo Weikang 
Cc: Dennis Zhou ,
	Tejun Heo ,
	Christoph Lameter ,
	Thomas Bogendoerfer ,
	Sam Creasey ,
	Huacai Chen ,
	Will Deacon ,
	Catalin Marinas ,
	Oreoluwa Babatunde ,
	rafael.j.wysocki@intel.com,
	Palmer Dabbelt ,
	Hanjun Guo ,
	Easwar Hariharan ,
	Johannes Berg ,
	Ingo Molnar ,
	Dave Hansen ,
	Christian Brauner ,
	KP Singh ,
	Richard Henderson ,
	Matt Turner ,
	Russell King ,
	WANG Xuerui ,
	Michael Ellerman ,
	Stefan Kristiansson ,
	Stafford Horne ,
	Helge Deller ,
	Nicholas Piggin ,
	Christophe Leroy ,
	Naveen N Rao ,
	Madhavan Srinivasan ,
	Geoff Levand ,
	Paul Walmsley ,
	Palmer Dabbelt ,
	Albert Ou ,
	Andrey Ryabinin ,
	Alexander Potapenko ,
	Andrey Konovalov ,
	Dmitry Vyukov ,
	Vincenzo Frascino ,
	Heiko Carstens ,
	Vasily Gorbik ,
	Alexander Gordeev ,
	Christian Borntraeger ,
	Sven Schnelle ,
	Yoshinori Sato ,
	Rich Felker ,
	John Paul Adrian Glaubitz ,
	Andreas Larsson ,
	Richard Weinberger ,
	Anton Ivanov ,
	Johannes Berg ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	x86@kernel.org,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-m68k@lists.linux-m68k.org,
	linux-mips@vger.kernel.org,
	linux-openrisc@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org,
	kasan-dev@googlegroups.com,
	linux-s390@vger.kernel.org,
	linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org,
	linux-um@lists.infradead.org,
	linux-acpi@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-omap@vger.kernel.org,
	linux-clk@vger.kernel.org,
	devicetree@vger.kernel.org,
	linux-mm@kvack.org,
	linux-pm@vger.kernel.org
Subject: [PATCH v5] mm/memblock: Add memblock_alloc_or_panic interface
Date: Sun, 22 Dec 2024 11:03:31 +0800
Message-Id: <20241222030331.2704579-1-guoweikang.kernel@gmail.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Before SLUB initialization, various subsystems used memblock_alloc to
allocate memory. In most cases, when memory allocation fails, an immediate
panic is required. To simplify this behavior and reduce repetitive checks,
introduce `memblock_alloc_or_panic`. This function ensures that memory
allocation failures result in a panic automatically, improving code
readability and consistency across subsystems that require this behavior.

Signed-off-by: Guo Weikang 
---
 arch/alpha/kernel/core_cia.c            |  5 +-
 arch/alpha/kernel/core_marvel.c         | 10 +---
 arch/alpha/kernel/pci.c                 | 13 +----
 arch/alpha/kernel/pci_iommu.c           | 10 +---
 arch/arm/kernel/setup.c                 | 10 +---
 arch/arm/mm/mmu.c                       | 17 ++----
 arch/arm/mm/nommu.c                     |  5 +-
 arch/arm64/kernel/setup.c               |  4 +-
 arch/loongarch/kernel/setup.c           |  2 +-
 arch/loongarch/mm/init.c                | 13 ++---
 arch/m68k/mm/init.c                     |  5 +-
 arch/m68k/mm/mcfmmu.c                   | 10 +---
 arch/m68k/mm/motorola.c                 |  5 +-
 arch/m68k/mm/sun3mmu.c                  | 10 +---
 arch/m68k/sun3/sun3dvma.c               |  6 +--
 arch/mips/kernel/setup.c                |  5 +-
 arch/openrisc/mm/ioremap.c              |  5 +-
 arch/parisc/mm/init.c                   | 20 ++-----
 arch/powerpc/kernel/dt_cpu_ftrs.c       | 10 ++--
 arch/powerpc/kernel/pci_32.c            |  5 +-
 arch/powerpc/kernel/setup-common.c      |  5 +-
 arch/powerpc/kernel/setup_32.c          |  8 +--
 arch/powerpc/mm/book3s32/mmu.c          |  5 +-
 arch/powerpc/mm/book3s64/pgtable.c      |  6 +--
 arch/powerpc/mm/kasan/init_book3e_64.c  |  8 +--
 arch/powerpc/mm/kasan/init_book3s_64.c  |  2 +-
 arch/powerpc/mm/nohash/mmu_context.c    | 16 ++----
 arch/powerpc/mm/pgtable_32.c            |  7 +--
 arch/powerpc/platforms/powermac/nvram.c |  5 +-
 arch/powerpc/platforms/powernv/opal.c   |  5 +-
 arch/powerpc/platforms/ps3/setup.c      |  5 +-
 arch/powerpc/sysdev/msi_bitmap.c        |  5 +-
 arch/riscv/kernel/setup.c               |  4 +-
 arch/riscv/mm/kasan_init.c              | 14 ++---
 arch/s390/kernel/numa.c                 |  5 +-
 arch/s390/kernel/setup.c                | 20 ++-----
 arch/s390/kernel/smp.c                  |  9 ++--
 arch/s390/kernel/topology.c             | 10 +---
 arch/sh/mm/init.c                       | 10 +---
 arch/sparc/kernel/prom_32.c             |  4 +-
 arch/sparc/mm/srmmu.c                   | 14 ++---
 arch/um/drivers/net_kern.c              |  5 +-
 arch/um/drivers/vector_kern.c           |  5 +-
 arch/um/kernel/load_file.c              |  4 +-
 arch/x86/coco/sev/core.c                |  4 +-
 arch/x86/kernel/acpi/boot.c             |  5 +-
 arch/x86/kernel/apic/io_apic.c          |  9 +---
 arch/x86/kernel/e820.c                  |  5 +-
 arch/x86/platform/olpc/olpc_dt.c        |  6 +--
 arch/x86/xen/p2m.c                      |  8 +--
 arch/xtensa/mm/kasan_init.c             |  6 +--
 drivers/clk/ti/clk.c                    |  5 +-
 drivers/macintosh/smu.c                 |  6 +--
 drivers/of/fdt.c                        |  8 +--
 drivers/of/unittest.c                   |  8 +--
 include/linux/memblock.h                |  6 +++
 init/main.c                             | 18 ++-----
 kernel/power/snapshot.c                 |  5 +-
 lib/cpumask.c                           |  5 +-
 mm/kmsan/shadow.c                       |  8 +--
 mm/memblock.c                           | 20 +++++++
 mm/numa.c                               |  8 +--
 mm/percpu.c                             | 70 +++++--------------------
 mm/sparse.c                             |  5 +-
 64 files changed, 143 insertions(+), 423 deletions(-)

diff --git a/arch/alpha/kernel/core_cia.c b/arch/alpha/kernel/core_cia.c
index ca3d9c732b61..6e577228e175 100644
--- a/arch/alpha/kernel/core_cia.c
+++ b/arch/alpha/kernel/core_cia.c
@@ -331,10 +331,7 @@ cia_prepare_tbia_workaround(int window)
 	long i;
 
 	/* Use minimal 1K map. */
-	ppte = memblock_alloc(CIA_BROKEN_TBIA_SIZE, 32768);
-	if (!ppte)
-		panic("%s: Failed to allocate %u bytes align=0x%x\n",
-		      __func__, CIA_BROKEN_TBIA_SIZE, 32768);
+	ppte = memblock_alloc_or_panic(CIA_BROKEN_TBIA_SIZE, 32768);
 	pte = (virt_to_phys(ppte) >> (PAGE_SHIFT - 1)) | 1;
 
 	for (i = 0; i < CIA_BROKEN_TBIA_SIZE / sizeof(unsigned long); ++i)
diff --git a/arch/alpha/kernel/core_marvel.c b/arch/alpha/kernel/core_marvel.c
index b22248044bf0..b1bfbd11980d 100644
--- a/arch/alpha/kernel/core_marvel.c
+++ b/arch/alpha/kernel/core_marvel.c
@@ -81,10 +81,7 @@ mk_resource_name(int pe, int port, char *str)
 	char *name;
 	
 	sprintf(tmp, "PCI %s PE %d PORT %d", str, pe, port);
-	name = memblock_alloc(strlen(tmp) + 1, SMP_CACHE_BYTES);
-	if (!name)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      strlen(tmp) + 1);
+	name = memblock_alloc_or_panic(strlen(tmp) + 1, SMP_CACHE_BYTES);
 	strcpy(name, tmp);
 
 	return name;
@@ -119,10 +116,7 @@ alloc_io7(unsigned int pe)
 		return NULL;
 	}
 
-	io7 = memblock_alloc(sizeof(*io7), SMP_CACHE_BYTES);
-	if (!io7)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*io7));
+	io7 = memblock_alloc_or_panic(sizeof(*io7), SMP_CACHE_BYTES);
 	io7->pe = pe;
 	raw_spin_lock_init(&io7->irq_lock);
 
diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
index 4458eb7f44f0..8e9b4ac86b7e 100644
--- a/arch/alpha/kernel/pci.c
+++ b/arch/alpha/kernel/pci.c
@@ -391,10 +391,7 @@ alloc_pci_controller(void)
 {
 	struct pci_controller *hose;
 
-	hose = memblock_alloc(sizeof(*hose), SMP_CACHE_BYTES);
-	if (!hose)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*hose));
+	hose = memblock_alloc_or_panic(sizeof(*hose), SMP_CACHE_BYTES);
 
 	*hose_tail = hose;
 	hose_tail = &hose->next;
@@ -405,13 +402,7 @@ alloc_pci_controller(void)
 struct resource * __init
 alloc_resource(void)
 {
-	void *ptr = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct resource));
-
-	return ptr;
+	return memblock_alloc_or_panic(sizeof(struct resource), SMP_CACHE_BYTES);
 }
 
 
diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index 7fcf3e9b7103..681f56089d9c 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -71,14 +71,8 @@ iommu_arena_new_node(int nid, struct pci_controller *hose, dma_addr_t base,
 	if (align < mem_size)
 		align = mem_size;
 
-	arena = memblock_alloc(sizeof(*arena), SMP_CACHE_BYTES);
-	if (!arena)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*arena));
-	arena->ptes = memblock_alloc(mem_size, align);
-	if (!arena->ptes)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, mem_size, align);
+	arena = memblock_alloc_or_panic(sizeof(*arena), SMP_CACHE_BYTES);
+	arena->ptes = memblock_alloc_or_panic(mem_size, align);
 
 	spin_lock_init(&arena->lock);
 	arena->hose = hose;
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index e6a857bf0ce6..a41c93988d2c 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -880,10 +880,7 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 		 */
 		boot_alias_start = phys_to_idmap(start);
 		if (arm_has_idmap_alias() && boot_alias_start != IDMAP_INVALID_ADDR) {
-			res = memblock_alloc(sizeof(*res), SMP_CACHE_BYTES);
-			if (!res)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, sizeof(*res));
+			res = memblock_alloc_or_panic(sizeof(*res), SMP_CACHE_BYTES);
 			res->name = "System RAM (boot alias)";
 			res->start = boot_alias_start;
 			res->end = phys_to_idmap(res_end);
@@ -891,10 +888,7 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 			request_resource(&iomem_resource, res);
 		}
 
-		res = memblock_alloc(sizeof(*res), SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      sizeof(*res));
+		res = memblock_alloc_or_panic(sizeof(*res), SMP_CACHE_BYTES);
 		res->name  = "System RAM";
 		res->start = start;
 		res->end = res_end;
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index f5b7a16c5803..f02f872ea8a9 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -726,13 +726,8 @@ EXPORT_SYMBOL(phys_mem_access_prot);
 
 static void __init *early_alloc(unsigned long sz)
 {
-	void *ptr = memblock_alloc(sz, sz);
+	return memblock_alloc_or_panic(sz, sz);
 
-	if (!ptr)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, sz, sz);
-
-	return ptr;
 }
 
 static void *__init late_alloc(unsigned long sz)
@@ -1027,10 +1022,7 @@ void __init iotable_init(struct map_desc *io_desc, int nr)
 	if (!nr)
 		return;
 
-	svm = memblock_alloc(sizeof(*svm) * nr, __alignof__(*svm));
-	if (!svm)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, sizeof(*svm) * nr, __alignof__(*svm));
+	svm = memblock_alloc_or_panic(sizeof(*svm) * nr, __alignof__(*svm));
 
 	for (md = io_desc; nr; md++, nr--) {
 		create_mapping(md);
@@ -1052,10 +1044,7 @@ void __init vm_reserve_area_early(unsigned long addr, unsigned long size,
 	struct vm_struct *vm;
 	struct static_vm *svm;
 
-	svm = memblock_alloc(sizeof(*svm), __alignof__(*svm));
-	if (!svm)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, sizeof(*svm), __alignof__(*svm));
+	svm = memblock_alloc_or_panic(sizeof(*svm), __alignof__(*svm));
 
 	vm = &svm->vm;
 	vm->addr = (void *)addr;
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index c415f3859b20..1a8f6914ee59 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -162,10 +162,7 @@ void __init paging_init(const struct machine_desc *mdesc)
 	mpu_setup();
 
 	/* allocate the zero page. */
-	zero_page = (void *)memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	zero_page = (void *)memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	bootmem_init();
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 4f613e8e0745..85104587f849 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -223,9 +223,7 @@ static void __init request_standard_resources(void)
 
 	num_standard_resources = memblock.memory.cnt;
 	res_size = num_standard_resources * sizeof(*standard_resources);
-	standard_resources = memblock_alloc(res_size, SMP_CACHE_BYTES);
-	if (!standard_resources)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, res_size);
+	standard_resources = memblock_alloc_or_panic(res_size, SMP_CACHE_BYTES);
 
 	for_each_mem_region(region) {
 		res = &standard_resources[i++];
diff --git a/arch/loongarch/kernel/setup.c b/arch/loongarch/kernel/setup.c
index 56934fe58170..edcfdfcad7d2 100644
--- a/arch/loongarch/kernel/setup.c
+++ b/arch/loongarch/kernel/setup.c
@@ -431,7 +431,7 @@ static void __init resource_init(void)
 
 	num_standard_resources = memblock.memory.cnt;
 	res_size = num_standard_resources * sizeof(*standard_resources);
-	standard_resources = memblock_alloc(res_size, SMP_CACHE_BYTES);
+	standard_resources = memblock_alloc_or_panic(res_size, SMP_CACHE_BYTES);
 
 	for_each_mem_region(region) {
 		res = &standard_resources[i++];
diff --git a/arch/loongarch/mm/init.c b/arch/loongarch/mm/init.c
index 188b52bbb254..ca5aa5f46a9f 100644
--- a/arch/loongarch/mm/init.c
+++ b/arch/loongarch/mm/init.c
@@ -174,9 +174,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 	pmd_t *pmd;
 
 	if (p4d_none(p4dp_get(p4d))) {
-		pud = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pud)
-			panic("%s: Failed to allocate memory\n", __func__);
+		pud = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		p4d_populate(&init_mm, p4d, pud);
 #ifndef __PAGETABLE_PUD_FOLDED
 		pud_init(pud);
@@ -185,9 +183,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 
 	pud = pud_offset(p4d, addr);
 	if (pud_none(pudp_get(pud))) {
-		pmd = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pmd)
-			panic("%s: Failed to allocate memory\n", __func__);
+		pmd = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 #ifndef __PAGETABLE_PMD_FOLDED
 		pmd_init(pmd);
@@ -198,10 +194,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 	if (!pmd_present(pmdp_get(pmd))) {
 		pte_t *pte;
 
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate memory\n", __func__);
-
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, pte);
 		kernel_pte_init(pte);
 	}
diff --git a/arch/m68k/mm/init.c b/arch/m68k/mm/init.c
index 1b47bec15832..8b11d0d545aa 100644
--- a/arch/m68k/mm/init.c
+++ b/arch/m68k/mm/init.c
@@ -68,10 +68,7 @@ void __init paging_init(void)
 
 	high_memory = (void *) end_mem;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	max_zone_pfn[ZONE_DMA] = end_mem >> PAGE_SHIFT;
 	free_area_init(max_zone_pfn);
 }
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index 9a6fa342e872..19a75029036c 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -42,20 +42,14 @@ void __init paging_init(void)
 	unsigned long max_zone_pfn[MAX_NR_ZONES] = { 0 };
 	int i;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	pg_dir = swapper_pg_dir;
 	memset(swapper_pg_dir, 0, sizeof(swapper_pg_dir));
 
 	size = num_pages * sizeof(pte_t);
 	size = (size + PAGE_SIZE) & ~(PAGE_SIZE-1);
-	next_pgtable = (unsigned long) memblock_alloc(size, PAGE_SIZE);
-	if (!next_pgtable)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, PAGE_SIZE);
+	next_pgtable = (unsigned long) memblock_alloc_or_panic(size, PAGE_SIZE);
 
 	pg_dir += PAGE_OFFSET >> PGDIR_SHIFT;
 
diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
index c1761d309fc6..795dd1f2b24f 100644
--- a/arch/m68k/mm/motorola.c
+++ b/arch/m68k/mm/motorola.c
@@ -491,10 +491,7 @@ void __init paging_init(void)
 	 * initialize the bad page table and bad page to point
 	 * to a couple of allocated pages
 	 */
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	/*
 	 * Set up SFC/DFC registers
diff --git a/arch/m68k/mm/sun3mmu.c b/arch/m68k/mm/sun3mmu.c
index 494739c1783e..1ecf6bdd08bf 100644
--- a/arch/m68k/mm/sun3mmu.c
+++ b/arch/m68k/mm/sun3mmu.c
@@ -44,10 +44,7 @@ void __init paging_init(void)
 	unsigned long max_zone_pfn[MAX_NR_ZONES] = { 0, };
 	unsigned long size;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	address = PAGE_OFFSET;
 	pg_dir = swapper_pg_dir;
@@ -57,10 +54,7 @@ void __init paging_init(void)
 	size = num_pages * sizeof(pte_t);
 	size = (size + PAGE_SIZE) & ~(PAGE_SIZE-1);
 
-	next_pgtable = (unsigned long)memblock_alloc(size, PAGE_SIZE);
-	if (!next_pgtable)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, PAGE_SIZE);
+	next_pgtable = (unsigned long)memblock_alloc_or_panic(size, PAGE_SIZE);
 	bootmem_end = (next_pgtable + size + PAGE_SIZE) & PAGE_MASK;
 
 	/* Map whole memory from PAGE_OFFSET (0x0E000000) */
diff --git a/arch/m68k/sun3/sun3dvma.c b/arch/m68k/sun3/sun3dvma.c
index 6ebf52740ad7..225fc735e466 100644
--- a/arch/m68k/sun3/sun3dvma.c
+++ b/arch/m68k/sun3/sun3dvma.c
@@ -252,12 +252,8 @@ void __init dvma_init(void)
 
 	list_add(&(hole->list), &hole_list);
 
-	iommu_use = memblock_alloc(IOMMU_TOTAL_ENTRIES * sizeof(unsigned long),
+	iommu_use = memblock_alloc_or_panic(IOMMU_TOTAL_ENTRIES * sizeof(unsigned long),
 				   SMP_CACHE_BYTES);
-	if (!iommu_use)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      IOMMU_TOTAL_ENTRIES * sizeof(unsigned long));
-
 	dvma_unmap_iommu(DVMA_START, DVMA_SIZE);
 
 	sun3_dvma_init();
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 12a1a4ffb602..fbfe0771317e 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -704,10 +704,7 @@ static void __init resource_init(void)
 	for_each_mem_range(i, &start, &end) {
 		struct resource *res;
 
-		res = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      sizeof(struct resource));
+		res = memblock_alloc_or_panic(sizeof(struct resource), SMP_CACHE_BYTES);
 
 		res->start = start;
 		/*
diff --git a/arch/openrisc/mm/ioremap.c b/arch/openrisc/mm/ioremap.c
index f59ea4c10b0f..8e63e86251ca 100644
--- a/arch/openrisc/mm/ioremap.c
+++ b/arch/openrisc/mm/ioremap.c
@@ -38,10 +38,7 @@ pte_t __ref *pte_alloc_one_kernel(struct mm_struct *mm)
 	if (likely(mem_init_done)) {
 		pte = (pte_t *)get_zeroed_page(GFP_KERNEL);
 	} else {
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	}
 
 	return pte;
diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index 96970fa75e4a..61c0a2477072 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -377,10 +377,8 @@ static void __ref map_pages(unsigned long start_vaddr,
 
 #if CONFIG_PGTABLE_LEVELS == 3
 		if (pud_none(*pud)) {
-			pmd = memblock_alloc(PAGE_SIZE << PMD_TABLE_ORDER,
+			pmd = memblock_alloc_or_panic(PAGE_SIZE << PMD_TABLE_ORDER,
 					     PAGE_SIZE << PMD_TABLE_ORDER);
-			if (!pmd)
-				panic("pmd allocation failed.\n");
 			pud_populate(NULL, pud, pmd);
 		}
 #endif
@@ -388,9 +386,7 @@ static void __ref map_pages(unsigned long start_vaddr,
 		pmd = pmd_offset(pud, vaddr);
 		for (tmp1 = start_pmd; tmp1 < PTRS_PER_PMD; tmp1++, pmd++) {
 			if (pmd_none(*pmd)) {
-				pg_table = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-				if (!pg_table)
-					panic("page table allocation failed\n");
+				pg_table = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 				pmd_populate_kernel(NULL, pmd, pg_table);
 			}
 
@@ -648,9 +644,7 @@ static void __init pagetable_init(void)
 	}
 #endif
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("zero page allocation failed.\n");
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 }
 
@@ -687,19 +681,15 @@ static void __init fixmap_init(void)
 
 #if CONFIG_PGTABLE_LEVELS == 3
 	if (pud_none(*pud)) {
-		pmd = memblock_alloc(PAGE_SIZE << PMD_TABLE_ORDER,
+		pmd = memblock_alloc_or_panic(PAGE_SIZE << PMD_TABLE_ORDER,
 				     PAGE_SIZE << PMD_TABLE_ORDER);
-		if (!pmd)
-			panic("fixmap: pmd allocation failed.\n");
 		pud_populate(NULL, pud, pmd);
 	}
 #endif
 
 	pmd = pmd_offset(pud, addr);
 	do {
-		pte_t *pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("fixmap: pte allocation failed.\n");
+		pte_t *pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 		pmd_populate_kernel(&init_mm, pmd, pte);
 
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 1bee15c013e7..3af6c06af02f 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -1087,12 +1087,10 @@ static int __init dt_cpu_ftrs_scan_callback(unsigned long node, const char
 	/* Count and allocate space for cpu features */
 	of_scan_flat_dt_subnodes(node, count_cpufeatures_subnodes,
 						&nr_dt_cpu_features);
-	dt_cpu_features = memblock_alloc(sizeof(struct dt_cpu_feature) * nr_dt_cpu_features, PAGE_SIZE);
-	if (!dt_cpu_features)
-		panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
-		      __func__,
-		      sizeof(struct dt_cpu_feature) * nr_dt_cpu_features,
-		      PAGE_SIZE);
+	dt_cpu_features =
+		memblock_alloc_or_panic(
+			sizeof(struct dt_cpu_feature) * nr_dt_cpu_features,
+			PAGE_SIZE);
 
 	cpufeatures_setup_start(isa);
 
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index ce0c8623e563..f8a3bd8cfae4 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -213,11 +213,8 @@ pci_create_OF_bus_map(void)
 	struct property* of_prop;
 	struct device_node *dn;
 
-	of_prop = memblock_alloc(sizeof(struct property) + 256,
+	of_prop = memblock_alloc_or_panic(sizeof(struct property) + 256,
 				 SMP_CACHE_BYTES);
-	if (!of_prop)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct property) + 256);
 	dn = of_find_node_by_path("/");
 	if (dn) {
 		memset(of_prop, -1, sizeof(struct property) + 256);
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 6fa179448c33..f3ea1329c566 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -458,11 +458,8 @@ void __init smp_setup_cpu_maps(void)
 
 	DBG("smp_setup_cpu_maps()\n");
 
-	cpu_to_phys_id = memblock_alloc(nr_cpu_ids * sizeof(u32),
+	cpu_to_phys_id = memblock_alloc_or_panic(nr_cpu_ids * sizeof(u32),
 					__alignof__(u32));
-	if (!cpu_to_phys_id)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, nr_cpu_ids * sizeof(u32), __alignof__(u32));
 
 	for_each_node_by_type(dn, "cpu") {
 		const __be32 *intserv;
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 75dbf3e0d9c4..5a1bf501fbe1 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -140,13 +140,7 @@ arch_initcall(ppc_init);
 
 static void *__init alloc_stack(void)
 {
-	void *ptr = memblock_alloc(THREAD_SIZE, THREAD_ALIGN);
-
-	if (!ptr)
-		panic("cannot allocate %d bytes for stack at %pS\n",
-		      THREAD_SIZE, (void *)_RET_IP_);
-
-	return ptr;
+	return memblock_alloc_or_panic(THREAD_SIZE, THREAD_ALIGN);
 }
 
 void __init irqstack_early_init(void)
diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/mmu.c
index 6978344edcb4..be9c4106e22f 100644
--- a/arch/powerpc/mm/book3s32/mmu.c
+++ b/arch/powerpc/mm/book3s32/mmu.c
@@ -377,10 +377,7 @@ void __init MMU_init_hw(void)
 	 * Find some memory for the hash table.
 	 */
 	if ( ppc_md.progress ) ppc_md.progress("hash:find piece", 0x322);
-	Hash = memblock_alloc(Hash_size, Hash_size);
-	if (!Hash)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, Hash_size, Hash_size);
+	Hash = memblock_alloc_or_panic(Hash_size, Hash_size);
 	_SDR1 = __pa(Hash) | SDR1_LOW_BITS;
 
 	pr_info("Total memory = %lldMB; using %ldkB for hash table\n",
diff --git a/arch/powerpc/mm/book3s64/pgtable.c b/arch/powerpc/mm/book3s64/pgtable.c
index 374542528080..0b1f419b7404 100644
--- a/arch/powerpc/mm/book3s64/pgtable.c
+++ b/arch/powerpc/mm/book3s64/pgtable.c
@@ -330,11 +330,7 @@ void __init mmu_partition_table_init(void)
 	unsigned long ptcr;
 
 	/* Initialize the Partition Table with no entries */
-	partition_tb = memblock_alloc(patb_size, patb_size);
-	if (!partition_tb)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, patb_size, patb_size);
-
+	partition_tb = memblock_alloc_or_panic(patb_size, patb_size);
 	ptcr = __pa(partition_tb) | (PATB_SIZE_SHIFT - 12);
 	set_ptcr_when_no_uv(ptcr);
 	powernv_set_nmmu_ptcr(ptcr);
diff --git a/arch/powerpc/mm/kasan/init_book3e_64.c b/arch/powerpc/mm/kasan/init_book3e_64.c
index 43c03b84ff32..60c78aac0f63 100644
--- a/arch/powerpc/mm/kasan/init_book3e_64.c
+++ b/arch/powerpc/mm/kasan/init_book3e_64.c
@@ -40,19 +40,19 @@ static int __init kasan_map_kernel_page(unsigned long ea, unsigned long pa, pgpr
 	pgdp = pgd_offset_k(ea);
 	p4dp = p4d_offset(pgdp, ea);
 	if (kasan_pud_table(*p4dp)) {
-		pudp = memblock_alloc(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
+		pudp = memblock_alloc_or_panic(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
 		memcpy(pudp, kasan_early_shadow_pud, PUD_TABLE_SIZE);
 		p4d_populate(&init_mm, p4dp, pudp);
 	}
 	pudp = pud_offset(p4dp, ea);
 	if (kasan_pmd_table(*pudp)) {
-		pmdp = memblock_alloc(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
+		pmdp = memblock_alloc_or_panic(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
 		memcpy(pmdp, kasan_early_shadow_pmd, PMD_TABLE_SIZE);
 		pud_populate(&init_mm, pudp, pmdp);
 	}
 	pmdp = pmd_offset(pudp, ea);
 	if (kasan_pte_table(*pmdp)) {
-		ptep = memblock_alloc(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
+		ptep = memblock_alloc_or_panic(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
 		memcpy(ptep, kasan_early_shadow_pte, PTE_TABLE_SIZE);
 		pmd_populate_kernel(&init_mm, pmdp, ptep);
 	}
@@ -74,7 +74,7 @@ static void __init kasan_init_phys_region(void *start, void *end)
 	k_start = ALIGN_DOWN((unsigned long)kasan_mem_to_shadow(start), PAGE_SIZE);
 	k_end = ALIGN((unsigned long)kasan_mem_to_shadow(end), PAGE_SIZE);
 
-	va = memblock_alloc(k_end - k_start, PAGE_SIZE);
+	va = memblock_alloc_or_panic(k_end - k_start, PAGE_SIZE);
 	for (k_cur = k_start; k_cur < k_end; k_cur += PAGE_SIZE, va += PAGE_SIZE)
 		kasan_map_kernel_page(k_cur, __pa(va), PAGE_KERNEL);
 }
diff --git a/arch/powerpc/mm/kasan/init_book3s_64.c b/arch/powerpc/mm/kasan/init_book3s_64.c
index 3fb5ce4f48f4..7d959544c077 100644
--- a/arch/powerpc/mm/kasan/init_book3s_64.c
+++ b/arch/powerpc/mm/kasan/init_book3s_64.c
@@ -32,7 +32,7 @@ static void __init kasan_init_phys_region(void *start, void *end)
 	k_start = ALIGN_DOWN((unsigned long)kasan_mem_to_shadow(start), PAGE_SIZE);
 	k_end = ALIGN((unsigned long)kasan_mem_to_shadow(end), PAGE_SIZE);
 
-	va = memblock_alloc(k_end - k_start, PAGE_SIZE);
+	va = memblock_alloc_or_panic(k_end - k_start, PAGE_SIZE);
 	for (k_cur = k_start; k_cur < k_end; k_cur += PAGE_SIZE, va += PAGE_SIZE)
 		map_kernel_page(k_cur, __pa(va), PAGE_KERNEL);
 }
diff --git a/arch/powerpc/mm/nohash/mmu_context.c b/arch/powerpc/mm/nohash/mmu_context.c
index 0b181da40ddb..a1a4e697251a 100644
--- a/arch/powerpc/mm/nohash/mmu_context.c
+++ b/arch/powerpc/mm/nohash/mmu_context.c
@@ -385,21 +385,11 @@ void __init mmu_context_init(void)
 	/*
 	 * Allocate the maps used by context management
 	 */
-	context_map = memblock_alloc(CTX_MAP_SIZE, SMP_CACHE_BYTES);
-	if (!context_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      CTX_MAP_SIZE);
-	context_mm = memblock_alloc(sizeof(void *) * (LAST_CONTEXT + 1),
+	context_map = memblock_alloc_or_panic(CTX_MAP_SIZE, SMP_CACHE_BYTES);
+	context_mm = memblock_alloc_or_panic(sizeof(void *) * (LAST_CONTEXT + 1),
 				    SMP_CACHE_BYTES);
-	if (!context_mm)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(void *) * (LAST_CONTEXT + 1));
 	if (IS_ENABLED(CONFIG_SMP)) {
-		stale_map[boot_cpuid] = memblock_alloc(CTX_MAP_SIZE, SMP_CACHE_BYTES);
-		if (!stale_map[boot_cpuid])
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      CTX_MAP_SIZE);
-
+		stale_map[boot_cpuid] = memblock_alloc_or_panic(CTX_MAP_SIZE, SMP_CACHE_BYTES);
 		cpuhp_setup_state_nocalls(CPUHP_POWERPC_MMU_CTX_PREPARE,
 					  "powerpc/mmu/ctx:prepare",
 					  mmu_ctx_cpu_prepare, mmu_ctx_cpu_dead);
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 787b22206386..15276068f657 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -50,13 +50,8 @@ notrace void __init early_ioremap_init(void)
 
 void __init *early_alloc_pgtable(unsigned long size)
 {
-	void *ptr = memblock_alloc(size, size);
+	return memblock_alloc_or_panic(size, size);
 
-	if (!ptr)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, size);
-
-	return ptr;
 }
 
 pte_t __init *early_pte_alloc_kernel(pmd_t *pmdp, unsigned long va)
diff --git a/arch/powerpc/platforms/powermac/nvram.c b/arch/powerpc/platforms/powermac/nvram.c
index fe2e0249cbc2..a112d26185a0 100644
--- a/arch/powerpc/platforms/powermac/nvram.c
+++ b/arch/powerpc/platforms/powermac/nvram.c
@@ -514,10 +514,7 @@ static int __init core99_nvram_setup(struct device_node *dp, unsigned long addr)
 		printk(KERN_ERR "nvram: no address\n");
 		return -EINVAL;
 	}
-	nvram_image = memblock_alloc(NVRAM_SIZE, SMP_CACHE_BYTES);
-	if (!nvram_image)
-		panic("%s: Failed to allocate %u bytes\n", __func__,
-		      NVRAM_SIZE);
+	nvram_image = memblock_alloc_or_panic(NVRAM_SIZE, SMP_CACHE_BYTES);
 	nvram_data = ioremap(addr, NVRAM_SIZE*2);
 	nvram_naddrs = 1; /* Make sure we get the correct case */
 
diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
index 5d0f35bb917e..09bd93464b4f 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -180,10 +180,7 @@ int __init early_init_dt_scan_recoverable_ranges(unsigned long node,
 	/*
 	 * Allocate a buffer to hold the MC recoverable ranges.
 	 */
-	mc_recoverable_range = memblock_alloc(size, __alignof__(u64));
-	if (!mc_recoverable_range)
-		panic("%s: Failed to allocate %u bytes align=0x%lx\n",
-		      __func__, size, __alignof__(u64));
+	mc_recoverable_range = memblock_alloc_or_panic(size, __alignof__(u64));
 
 	for (i = 0; i < mc_recoverable_range_len; i++) {
 		mc_recoverable_range[i].start_addr =
diff --git a/arch/powerpc/platforms/ps3/setup.c b/arch/powerpc/platforms/ps3/setup.c
index 5144f11359f7..150c09b58ae8 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -115,10 +115,7 @@ static void __init prealloc(struct ps3_prealloc *p)
 	if (!p->size)
 		return;
 
-	p->address = memblock_alloc(p->size, p->align);
-	if (!p->address)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, p->size, p->align);
+	p->address = memblock_alloc_or_panic(p->size, p->align);
 
 	printk(KERN_INFO "%s: %lu bytes at %p\n", p->name, p->size,
 	       p->address);
diff --git a/arch/powerpc/sysdev/msi_bitmap.c b/arch/powerpc/sysdev/msi_bitmap.c
index 0b6e37f3ffb8..456a4f64ae0a 100644
--- a/arch/powerpc/sysdev/msi_bitmap.c
+++ b/arch/powerpc/sysdev/msi_bitmap.c
@@ -124,10 +124,7 @@ int __ref msi_bitmap_alloc(struct msi_bitmap *bmp, unsigned int irq_count,
 	if (bmp->bitmap_from_slab)
 		bmp->bitmap = kzalloc(size, GFP_KERNEL);
 	else {
-		bmp->bitmap = memblock_alloc(size, SMP_CACHE_BYTES);
-		if (!bmp->bitmap)
-			panic("%s: Failed to allocate %u bytes\n", __func__,
-			      size);
+		bmp->bitmap = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 		/* the bitmap won't be freed from memblock allocator */
 		kmemleak_not_leak(bmp->bitmap);
 	}
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 45010e71df86..f1793630fc51 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -147,9 +147,7 @@ static void __init init_resources(void)
 	res_idx = num_resources - 1;
 
 	mem_res_sz = num_resources * sizeof(*mem_res);
-	mem_res = memblock_alloc(mem_res_sz, SMP_CACHE_BYTES);
-	if (!mem_res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, mem_res_sz);
+	mem_res = memblock_alloc_or_panic(mem_res_sz, SMP_CACHE_BYTES);
 
 	/*
 	 * Start by adding the reserved regions, if they overlap
diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index c301c8d291d2..41c635d6aca4 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -32,7 +32,7 @@ static void __init kasan_populate_pte(pmd_t *pmd, unsigned long vaddr, unsigned
 	pte_t *ptep, *p;
 
 	if (pmd_none(pmdp_get(pmd))) {
-		p = memblock_alloc(PTRS_PER_PTE * sizeof(pte_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PTE * sizeof(pte_t), PAGE_SIZE);
 		set_pmd(pmd, pfn_pmd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -54,7 +54,7 @@ static void __init kasan_populate_pmd(pud_t *pud, unsigned long vaddr, unsigned
 	unsigned long next;
 
 	if (pud_none(pudp_get(pud))) {
-		p = memblock_alloc(PTRS_PER_PMD * sizeof(pmd_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PMD * sizeof(pmd_t), PAGE_SIZE);
 		set_pud(pud, pfn_pud(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -85,7 +85,7 @@ static void __init kasan_populate_pud(p4d_t *p4d,
 	unsigned long next;
 
 	if (p4d_none(p4dp_get(p4d))) {
-		p = memblock_alloc(PTRS_PER_PUD * sizeof(pud_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PUD * sizeof(pud_t), PAGE_SIZE);
 		set_p4d(p4d, pfn_p4d(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -116,7 +116,7 @@ static void __init kasan_populate_p4d(pgd_t *pgd,
 	unsigned long next;
 
 	if (pgd_none(pgdp_get(pgd))) {
-		p = memblock_alloc(PTRS_PER_P4D * sizeof(p4d_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_P4D * sizeof(p4d_t), PAGE_SIZE);
 		set_pgd(pgd, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -385,7 +385,7 @@ static void __init kasan_shallow_populate_pud(p4d_t *p4d,
 		next = pud_addr_end(vaddr, end);
 
 		if (pud_none(pudp_get(pud_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_pud(pud_k, pfn_pud(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
@@ -405,7 +405,7 @@ static void __init kasan_shallow_populate_p4d(pgd_t *pgd,
 		next = p4d_addr_end(vaddr, end);
 
 		if (p4d_none(p4dp_get(p4d_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_p4d(p4d_k, pfn_p4d(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
@@ -424,7 +424,7 @@ static void __init kasan_shallow_populate_pgd(unsigned long vaddr, unsigned long
 		next = pgd_addr_end(vaddr, end);
 
 		if (pgd_none(pgdp_get(pgd_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_pgd(pgd_k, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
diff --git a/arch/s390/kernel/numa.c b/arch/s390/kernel/numa.c
index ddc1448ea2e1..a33e20f73330 100644
--- a/arch/s390/kernel/numa.c
+++ b/arch/s390/kernel/numa.c
@@ -22,10 +22,7 @@ void __init numa_setup(void)
 	node_set(0, node_possible_map);
 	node_set_online(0);
 	for (nid = 0; nid < MAX_NUMNODES; nid++) {
-		NODE_DATA(nid) = memblock_alloc(sizeof(pg_data_t), 8);
-		if (!NODE_DATA(nid))
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(pg_data_t), 8);
+		NODE_DATA(nid) = memblock_alloc_or_panic(sizeof(pg_data_t), 8);
 	}
 	NODE_DATA(0)->node_spanned_pages = memblock_end_of_DRAM() >> PAGE_SHIFT;
 	NODE_DATA(0)->node_id = 0;
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index 0ce550faf073..1298f0860733 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -376,11 +376,7 @@ static unsigned long __init stack_alloc_early(void)
 {
 	unsigned long stack;
 
-	stack = (unsigned long)memblock_alloc(THREAD_SIZE, THREAD_SIZE);
-	if (!stack) {
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, THREAD_SIZE, THREAD_SIZE);
-	}
+	stack = (unsigned long)memblock_alloc_or_panic(THREAD_SIZE, THREAD_SIZE);
 	return stack;
 }
 
@@ -504,10 +500,7 @@ static void __init setup_resources(void)
 	bss_resource.end = __pa_symbol(__bss_stop) - 1;
 
 	for_each_mem_range(i, &start, &end) {
-		res = memblock_alloc(sizeof(*res), 8);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(*res), 8);
+		res = memblock_alloc_or_panic(sizeof(*res), 8);
 		res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
 
 		res->name = "System RAM";
@@ -526,10 +519,7 @@ static void __init setup_resources(void)
 			    std_res->start > res->end)
 				continue;
 			if (std_res->end > res->end) {
-				sub_res = memblock_alloc(sizeof(*sub_res), 8);
-				if (!sub_res)
-					panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-					      __func__, sizeof(*sub_res), 8);
+				sub_res = memblock_alloc_or_panic(sizeof(*sub_res), 8);
 				*sub_res = *std_res;
 				sub_res->end = res->end;
 				std_res->start = res->end + 1;
@@ -816,9 +806,7 @@ static void __init setup_randomness(void)
 {
 	struct sysinfo_3_2_2 *vmms;
 
-	vmms = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!vmms)
-		panic("Failed to allocate memory for sysinfo structure\n");
+	vmms = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	if (stsi(vmms, 3, 2, 2) == 0 && vmms->count)
 		add_device_randomness(&vmms->vm, sizeof(vmms->vm[0]) * vmms->count);
 	memblock_free(vmms, PAGE_SIZE);
diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
index 822d8e6f8717..d77aaefb59bd 100644
--- a/arch/s390/kernel/smp.c
+++ b/arch/s390/kernel/smp.c
@@ -611,9 +611,9 @@ void __init smp_save_dump_ipl_cpu(void)
 	if (!dump_available())
 		return;
 	sa = save_area_alloc(true);
-	regs = memblock_alloc(512, 8);
-	if (!sa || !regs)
+	if (!sa)
 		panic("could not allocate memory for boot CPU save area\n");
+	regs = memblock_alloc_or_panic(512, 8);
 	copy_oldmem_kernel(regs, __LC_FPREGS_SAVE_AREA, 512);
 	save_area_add_regs(sa, regs);
 	memblock_free(regs, 512);
@@ -792,10 +792,7 @@ void __init smp_detect_cpus(void)
 	u16 address;
 
 	/* Get CPU information */
-	info = memblock_alloc(sizeof(*info), 8);
-	if (!info)
-		panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-		      __func__, sizeof(*info), 8);
+	info = memblock_alloc_or_panic(sizeof(*info), 8);
 	smp_get_core_info(info, 1);
 	/* Find boot CPU type */
 	if (sclp.has_core_type) {
diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
index 0fd56a1cadbd..cf5ee6032c0b 100644
--- a/arch/s390/kernel/topology.c
+++ b/arch/s390/kernel/topology.c
@@ -548,10 +548,7 @@ static void __init alloc_masks(struct sysinfo_15_1_x *info,
 		nr_masks *= info->mag[TOPOLOGY_NR_MAG - offset - 1 - i];
 	nr_masks = max(nr_masks, 1);
 	for (i = 0; i < nr_masks; i++) {
-		mask->next = memblock_alloc(sizeof(*mask->next), 8);
-		if (!mask->next)
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(*mask->next), 8);
+		mask->next = memblock_alloc_or_panic(sizeof(*mask->next), 8);
 		mask = mask->next;
 	}
 }
@@ -569,10 +566,7 @@ void __init topology_init_early(void)
 	}
 	if (!MACHINE_HAS_TOPOLOGY)
 		goto out;
-	tl_info = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!tl_info)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	tl_info = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	info = tl_info;
 	store_topology(info);
 	pr_info("The CPU configuration topology of the machine is: %d %d %d %d %d %d / %d\n",
diff --git a/arch/sh/mm/init.c b/arch/sh/mm/init.c
index 2a88b0c9e70f..289a2fecebef 100644
--- a/arch/sh/mm/init.c
+++ b/arch/sh/mm/init.c
@@ -137,10 +137,7 @@ static pmd_t * __init one_md_table_init(pud_t *pud)
 	if (pud_none(*pud)) {
 		pmd_t *pmd;
 
-		pmd = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pmd)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pmd = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 		BUG_ON(pmd != pmd_offset(pud, 0));
 	}
@@ -153,10 +150,7 @@ static pte_t * __init one_page_table_init(pmd_t *pmd)
 	if (pmd_none(*pmd)) {
 		pte_t *pte;
 
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, pte);
 		BUG_ON(pte != pte_offset_kernel(pmd, 0));
 	}
diff --git a/arch/sparc/kernel/prom_32.c b/arch/sparc/kernel/prom_32.c
index 3df960c137f7..a67dd67f10c8 100644
--- a/arch/sparc/kernel/prom_32.c
+++ b/arch/sparc/kernel/prom_32.c
@@ -28,9 +28,7 @@ void * __init prom_early_alloc(unsigned long size)
 {
 	void *ret;
 
-	ret = memblock_alloc(size, SMP_CACHE_BYTES);
-	if (!ret)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, size);
+	ret = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 
 	prom_early_allocated += size;
 
diff --git a/arch/sparc/mm/srmmu.c b/arch/sparc/mm/srmmu.c
index 9df51a62333d..e36c2a0ff748 100644
--- a/arch/sparc/mm/srmmu.c
+++ b/arch/sparc/mm/srmmu.c
@@ -277,19 +277,13 @@ static void __init srmmu_nocache_init(void)
 
 	bitmap_bits = srmmu_nocache_size >> SRMMU_NOCACHE_BITMAP_SHIFT;
 
-	srmmu_nocache_pool = memblock_alloc(srmmu_nocache_size,
+	srmmu_nocache_pool = memblock_alloc_or_panic(srmmu_nocache_size,
 					    SRMMU_NOCACHE_ALIGN_MAX);
-	if (!srmmu_nocache_pool)
-		panic("%s: Failed to allocate %lu bytes align=0x%x\n",
-		      __func__, srmmu_nocache_size, SRMMU_NOCACHE_ALIGN_MAX);
 	memset(srmmu_nocache_pool, 0, srmmu_nocache_size);
 
 	srmmu_nocache_bitmap =
-		memblock_alloc(BITS_TO_LONGS(bitmap_bits) * sizeof(long),
+		memblock_alloc_or_panic(BITS_TO_LONGS(bitmap_bits) * sizeof(long),
 			       SMP_CACHE_BYTES);
-	if (!srmmu_nocache_bitmap)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      BITS_TO_LONGS(bitmap_bits) * sizeof(long));
 	bit_map_init(&srmmu_nocache_map, srmmu_nocache_bitmap, bitmap_bits);
 
 	srmmu_swapper_pg_dir = __srmmu_get_nocache(SRMMU_PGD_TABLE_SIZE, SRMMU_PGD_TABLE_SIZE);
@@ -452,9 +446,7 @@ static void __init sparc_context_init(int numctx)
 	unsigned long size;
 
 	size = numctx * sizeof(struct ctx_list);
-	ctx_list_pool = memblock_alloc(size, SMP_CACHE_BYTES);
-	if (!ctx_list_pool)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, size);
+	ctx_list_pool = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 
 	for (ctx = 0; ctx < numctx; ctx++) {
 		struct ctx_list *clist;
diff --git a/arch/um/drivers/net_kern.c b/arch/um/drivers/net_kern.c
index 75d04fb4994a..d5a9c5aabaec 100644
--- a/arch/um/drivers/net_kern.c
+++ b/arch/um/drivers/net_kern.c
@@ -636,10 +636,7 @@ static int __init eth_setup(char *str)
 		return 1;
 	}
 
-	new = memblock_alloc(sizeof(*new), SMP_CACHE_BYTES);
-	if (!new)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*new));
+	new = memblock_alloc_or_panic(sizeof(*new), SMP_CACHE_BYTES);
 
 	INIT_LIST_HEAD(&new->list);
 	new->index = n;
diff --git a/arch/um/drivers/vector_kern.c b/arch/um/drivers/vector_kern.c
index 64c09db392c1..85b129e2b70b 100644
--- a/arch/um/drivers/vector_kern.c
+++ b/arch/um/drivers/vector_kern.c
@@ -1694,10 +1694,7 @@ static int __init vector_setup(char *str)
 				 str, error);
 		return 1;
 	}
-	new = memblock_alloc(sizeof(*new), SMP_CACHE_BYTES);
-	if (!new)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*new));
+	new = memblock_alloc_or_panic(sizeof(*new), SMP_CACHE_BYTES);
 	INIT_LIST_HEAD(&new->list);
 	new->unit = n;
 	new->arguments = str;
diff --git a/arch/um/kernel/load_file.c b/arch/um/kernel/load_file.c
index 5cecd0e291fb..cb9d178ab7d8 100644
--- a/arch/um/kernel/load_file.c
+++ b/arch/um/kernel/load_file.c
@@ -48,9 +48,7 @@ void *uml_load_file(const char *filename, unsigned long long *size)
 		return NULL;
 	}
 
-	area = memblock_alloc(*size, SMP_CACHE_BYTES);
-	if (!area)
-		panic("%s: Failed to allocate %llu bytes\n", __func__, *size);
+	area = memblock_alloc_or_panic(*size, SMP_CACHE_BYTES);
 
 	if (__uml_load_file(filename, area, *size)) {
 		memblock_free(area, *size);
diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index 499b41953e3c..fa218270c1db 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -1567,9 +1567,7 @@ static void __init alloc_runtime_data(int cpu)
 		struct svsm_ca *caa;
 
 		/* Allocate the SVSM CA page if an SVSM is present */
-		caa = memblock_alloc(sizeof(*caa), PAGE_SIZE);
-		if (!caa)
-			panic("Can't allocate SVSM CA page\n");
+		caa = memblock_alloc_or_panic(sizeof(*caa), PAGE_SIZE);
 
 		per_cpu(svsm_caa, cpu) = caa;
 		per_cpu(svsm_caa_pa, cpu) = __pa(caa);
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 3a44a9dc3fb7..7c15d6e83c37 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -911,11 +911,8 @@ static int __init acpi_parse_hpet(struct acpi_table_header *table)
 	 * the resource tree during the lateinit timeframe.
 	 */
 #define HPET_RESOURCE_NAME_SIZE 9
-	hpet_res = memblock_alloc(sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE,
+	hpet_res = memblock_alloc_or_panic(sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE,
 				  SMP_CACHE_BYTES);
-	if (!hpet_res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE);
 
 	hpet_res->name = (void *)&hpet_res[1];
 	hpet_res->flags = IORESOURCE_MEM;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 1029ea4ac8ba..a57d3fa7c6b6 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2503,9 +2503,7 @@ static struct resource * __init ioapic_setup_resources(void)
 	n = IOAPIC_RESOURCE_NAME_SIZE + sizeof(struct resource);
 	n *= nr_ioapics;
 
-	mem = memblock_alloc(n, SMP_CACHE_BYTES);
-	if (!mem)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, n);
+	mem = memblock_alloc_or_panic(n, SMP_CACHE_BYTES);
 	res = (void *)mem;
 
 	mem += sizeof(struct resource) * nr_ioapics;
@@ -2564,11 +2562,8 @@ void __init io_apic_init_mappings(void)
 #ifdef CONFIG_X86_32
 fake_ioapic_page:
 #endif
-			ioapic_phys = (unsigned long)memblock_alloc(PAGE_SIZE,
+			ioapic_phys = (unsigned long)memblock_alloc_or_panic(PAGE_SIZE,
 								    PAGE_SIZE);
-			if (!ioapic_phys)
-				panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-				      __func__, PAGE_SIZE, PAGE_SIZE);
 			ioapic_phys = __pa(ioapic_phys);
 		}
 		io_apic_set_fixmap(idx, ioapic_phys);
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 4893d30ce438..82b96ed9890a 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1146,11 +1146,8 @@ void __init e820__reserve_resources(void)
 	struct resource *res;
 	u64 end;
 
-	res = memblock_alloc(sizeof(*res) * e820_table->nr_entries,
+	res = memblock_alloc_or_panic(sizeof(*res) * e820_table->nr_entries,
 			     SMP_CACHE_BYTES);
-	if (!res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*res) * e820_table->nr_entries);
 	e820_res = res;
 
 	for (i = 0; i < e820_table->nr_entries; i++) {
diff --git a/arch/x86/platform/olpc/olpc_dt.c b/arch/x86/platform/olpc/olpc_dt.c
index 74ebd6882690..cf5dca2dbb91 100644
--- a/arch/x86/platform/olpc/olpc_dt.c
+++ b/arch/x86/platform/olpc/olpc_dt.c
@@ -136,11 +136,7 @@ void * __init prom_early_alloc(unsigned long size)
 		 * fast enough on the platforms we care about while minimizing
 		 * wasted bootmem) and hand off chunks of it to callers.
 		 */
-		res = memblock_alloc(chunk_size, SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      chunk_size);
-		BUG_ON(!res);
+		res = memblock_alloc_or_panic(chunk_size, SMP_CACHE_BYTES);
 		prom_early_allocated += chunk_size;
 		memset(res, 0, chunk_size);
 		free_mem = chunk_size;
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index b52d3e17e2c1..56914e21e303 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -178,13 +178,7 @@ static void p2m_init_identity(unsigned long *p2m, unsigned long pfn)
 static void * __ref alloc_p2m_page(void)
 {
 	if (unlikely(!slab_is_available())) {
-		void *ptr = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-
-		if (!ptr)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
-
-		return ptr;
+		return memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	}
 
 	return (void *)__get_free_page(GFP_KERNEL);
diff --git a/arch/xtensa/mm/kasan_init.c b/arch/xtensa/mm/kasan_init.c
index f00d122aa806..f39c4d83173a 100644
--- a/arch/xtensa/mm/kasan_init.c
+++ b/arch/xtensa/mm/kasan_init.c
@@ -39,11 +39,7 @@ static void __init populate(void *start, void *end)
 	unsigned long i, j;
 	unsigned long vaddr = (unsigned long)start;
 	pmd_t *pmd = pmd_off_k(vaddr);
-	pte_t *pte = memblock_alloc(n_pages * sizeof(pte_t), PAGE_SIZE);
-
-	if (!pte)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, n_pages * sizeof(pte_t), PAGE_SIZE);
+	pte_t *pte = memblock_alloc_or_panic(n_pages * sizeof(pte_t), PAGE_SIZE);
 
 	pr_debug("%s: %p - %p\n", __func__, start, end);
 
diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
index f2117fef7c7d..9c75dcc9a534 100644
--- a/drivers/clk/ti/clk.c
+++ b/drivers/clk/ti/clk.c
@@ -449,10 +449,7 @@ void __init omap2_clk_legacy_provider_init(int index, void __iomem *mem)
 {
 	struct clk_iomap *io;
 
-	io = memblock_alloc(sizeof(*io), SMP_CACHE_BYTES);
-	if (!io)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*io));
+	io = memblock_alloc_or_panic(sizeof(*io), SMP_CACHE_BYTES);
 
 	io->mem = mem;
 
diff --git a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
index a01bc5090cdf..a1534cc6c641 100644
--- a/drivers/macintosh/smu.c
+++ b/drivers/macintosh/smu.c
@@ -492,11 +492,7 @@ int __init smu_init (void)
 		goto fail_np;
 	}
 
-	smu = memblock_alloc(sizeof(struct smu_device), SMP_CACHE_BYTES);
-	if (!smu)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct smu_device));
-
+	smu = memblock_alloc_or_panic(sizeof(struct smu_device), SMP_CACHE_BYTES);
 	spin_lock_init(&smu->lock);
 	INIT_LIST_HEAD(&smu->cmd_list);
 	INIT_LIST_HEAD(&smu->cmd_i2c_list);
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 4b1e9f101ce3..809135e2c7f5 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1126,13 +1126,7 @@ void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
 
 static void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
 {
-	void *ptr = memblock_alloc(size, align);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %llu bytes align=0x%llx\n",
-		      __func__, size, align);
-
-	return ptr;
+	return memblock_alloc_or_panic(size, align);
 }
 
 bool __init early_init_dt_verify(void *dt_virt, phys_addr_t dt_phys)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index e50570629dc0..837eafa81636 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -3675,13 +3675,7 @@ static struct device_node *overlay_base_root;
 
 static void * __init dt_alloc_memory(u64 size, u64 align)
 {
-	void *ptr = memblock_alloc(size, align);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %llu bytes align=0x%llx\n",
-		      __func__, size, align);
-
-	return ptr;
+	return memblock_alloc_or_panic(size, align);
 }
 
 /*
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 673d5cae7c81..73af7ca3fa1c 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -417,6 +417,12 @@ static __always_inline void *memblock_alloc(phys_addr_t size, phys_addr_t align)
 				      MEMBLOCK_ALLOC_ACCESSIBLE, NUMA_NO_NODE);
 }
 
+void *__memblock_alloc_or_panic(phys_addr_t size, phys_addr_t align,
+				       const char *func);
+
+#define memblock_alloc_or_panic(size, align)    \
+	 __memblock_alloc_or_panic(size, align, __func__)
+
 static inline void *memblock_alloc_raw(phys_addr_t size,
 					       phys_addr_t align)
 {
diff --git a/init/main.c b/init/main.c
index 893cb77aef22..2a1757826397 100644
--- a/init/main.c
+++ b/init/main.c
@@ -640,15 +640,11 @@ static void __init setup_command_line(char *command_line)
 
 	len = xlen + strlen(boot_command_line) + ilen + 1;
 
-	saved_command_line = memblock_alloc(len, SMP_CACHE_BYTES);
-	if (!saved_command_line)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, len);
+	saved_command_line = memblock_alloc_or_panic(len, SMP_CACHE_BYTES);
 
 	len = xlen + strlen(command_line) + 1;
 
-	static_command_line = memblock_alloc(len, SMP_CACHE_BYTES);
-	if (!static_command_line)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, len);
+	static_command_line = memblock_alloc_or_panic(len, SMP_CACHE_BYTES);
 
 	if (xlen) {
 		/*
@@ -1146,16 +1142,10 @@ static int __init initcall_blacklist(char *str)
 		str_entry = strsep(&str, ",");
 		if (str_entry) {
 			pr_debug("blacklisting initcall %s\n", str_entry);
-			entry = memblock_alloc(sizeof(*entry),
+			entry = memblock_alloc_or_panic(sizeof(*entry),
 					       SMP_CACHE_BYTES);
-			if (!entry)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, sizeof(*entry));
-			entry->buf = memblock_alloc(strlen(str_entry) + 1,
+			entry->buf = memblock_alloc_or_panic(strlen(str_entry) + 1,
 						    SMP_CACHE_BYTES);
-			if (!entry->buf)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, strlen(str_entry) + 1);
 			strcpy(entry->buf, str_entry);
 			list_add(&entry->next, &blacklisted_initcalls);
 		}
diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
index 30894d8f0a78..c9fb559a6399 100644
--- a/kernel/power/snapshot.c
+++ b/kernel/power/snapshot.c
@@ -1011,11 +1011,8 @@ void __init register_nosave_region(unsigned long start_pfn, unsigned long end_pf
 		}
 	}
 	/* This allocation cannot fail */
-	region = memblock_alloc(sizeof(struct nosave_region),
+	region = memblock_alloc_or_panic(sizeof(struct nosave_region),
 				SMP_CACHE_BYTES);
-	if (!region)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct nosave_region));
 	region->start_pfn = start_pfn;
 	region->end_pfn = end_pfn;
 	list_add_tail(®ion->list, &nosave_regions);
diff --git a/lib/cpumask.c b/lib/cpumask.c
index e77ee9d46f71..57274ba8b6d9 100644
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@ -83,10 +83,7 @@ EXPORT_SYMBOL(alloc_cpumask_var_node);
  */
 void __init alloc_bootmem_cpumask_var(cpumask_var_t *mask)
 {
-	*mask = memblock_alloc(cpumask_size(), SMP_CACHE_BYTES);
-	if (!*mask)
-		panic("%s: Failed to allocate %u bytes\n", __func__,
-		      cpumask_size());
+	*mask = memblock_alloc_or_panic(cpumask_size(), SMP_CACHE_BYTES);
 }
 
 /**
diff --git a/mm/kmsan/shadow.c b/mm/kmsan/shadow.c
index 9c58f081d84f..1bb505a08415 100644
--- a/mm/kmsan/shadow.c
+++ b/mm/kmsan/shadow.c
@@ -280,12 +280,8 @@ void __init kmsan_init_alloc_meta_for_range(void *start, void *end)
 
 	start = (void *)PAGE_ALIGN_DOWN((u64)start);
 	size = PAGE_ALIGN((u64)end - (u64)start);
-	shadow = memblock_alloc(size, PAGE_SIZE);
-	origin = memblock_alloc(size, PAGE_SIZE);
-
-	if (!shadow || !origin)
-		panic("%s: Failed to allocate metadata memory for early boot range of size %llu",
-		      __func__, size);
+	shadow = memblock_alloc_or_panic(size, PAGE_SIZE);
+	origin = memblock_alloc_or_panic(size, PAGE_SIZE);
 
 	for (u64 addr = 0; addr < size; addr += PAGE_SIZE) {
 		page = virt_to_page_or_null((char *)start + addr);
diff --git a/mm/memblock.c b/mm/memblock.c
index 095c18b5c430..762eadd07d88 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1691,6 +1691,26 @@ void * __init memblock_alloc_try_nid(
 	return ptr;
 }
 
+/**
+ * __memblock_alloc_or_panic - Try to allocate memory and panic on failure
+ * @size: size of memory block to be allocated in bytes
+ * @align: alignment of the region and block's size
+ * @fuc: caller func name
+ *
+ * This function attempts to allocate memory using memblock_alloc,
+ * and in case of failure, it calls panic with the formatted message.
+ * This function should not be used directly, please use the macro memblock_alloc_or_panic.
+ */
+void *__init __memblock_alloc_or_panic(phys_addr_t size, phys_addr_t align,
+				       const char *func)
+{
+	void *addr = memblock_alloc(size, align);
+
+	if (unlikely(!addr))
+		panic("%s: Failed to allocate %pap bytes\n", func, &size);
+	return addr;
+}
+
 /**
  * memblock_free_late - free pages directly to buddy allocator
  * @base: phys starting address of the  boot memory block
diff --git a/mm/numa.c b/mm/numa.c
index e2eec07707d1..f1787d7713a6 100644
--- a/mm/numa.c
+++ b/mm/numa.c
@@ -37,13 +37,7 @@ void __init alloc_node_data(int nid)
 void __init alloc_offline_node_data(int nid)
 {
 	pg_data_t *pgdat;
-
-	pgdat = memblock_alloc(sizeof(*pgdat), SMP_CACHE_BYTES);
-	if (!pgdat)
-		panic("Cannot allocate %zuB for node %d.\n",
-		      sizeof(*pgdat), nid);
-
-	node_data[nid] = pgdat;
+	node_data[nid] = memblock_alloc_or_panic(sizeof(*pgdat), SMP_CACHE_BYTES);
 }
 
 /* Stub functions: */
diff --git a/mm/percpu.c b/mm/percpu.c
index d8dd31a2e407..ac61e3fc5f15 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1359,10 +1359,7 @@ static struct pcpu_chunk * __init pcpu_alloc_first_chunk(unsigned long tmp_addr,
 	/* allocate chunk */
 	alloc_size = struct_size(chunk, populated,
 				 BITS_TO_LONGS(region_size >> PAGE_SHIFT));
-	chunk = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	INIT_LIST_HEAD(&chunk->list);
 
@@ -1374,24 +1371,14 @@ static struct pcpu_chunk * __init pcpu_alloc_first_chunk(unsigned long tmp_addr,
 	region_bits = pcpu_chunk_map_bits(chunk);
 
 	alloc_size = BITS_TO_LONGS(region_bits) * sizeof(chunk->alloc_map[0]);
-	chunk->alloc_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->alloc_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk->alloc_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size =
 		BITS_TO_LONGS(region_bits + 1) * sizeof(chunk->bound_map[0]);
-	chunk->bound_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->bound_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk->bound_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = pcpu_chunk_nr_blocks(chunk) * sizeof(chunk->md_blocks[0]);
-	chunk->md_blocks = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->md_blocks)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
-
+	chunk->md_blocks = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 #ifdef NEED_PCPUOBJ_EXT
 	/* first chunk is free to use */
 	chunk->obj_exts = NULL;
@@ -2595,28 +2582,16 @@ void __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
 
 	/* process group information and build config tables accordingly */
 	alloc_size = ai->nr_groups * sizeof(group_offsets[0]);
-	group_offsets = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!group_offsets)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	group_offsets = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = ai->nr_groups * sizeof(group_sizes[0]);
-	group_sizes = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!group_sizes)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	group_sizes = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = nr_cpu_ids * sizeof(unit_map[0]);
-	unit_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!unit_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	unit_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = nr_cpu_ids * sizeof(unit_off[0]);
-	unit_off = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!unit_off)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	unit_off = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	for (cpu = 0; cpu < nr_cpu_ids; cpu++)
 		unit_map[cpu] = UINT_MAX;
@@ -2685,12 +2660,9 @@ void __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
 	pcpu_free_slot = pcpu_sidelined_slot + 1;
 	pcpu_to_depopulate_slot = pcpu_free_slot + 1;
 	pcpu_nr_slots = pcpu_to_depopulate_slot + 1;
-	pcpu_chunk_lists = memblock_alloc(pcpu_nr_slots *
+	pcpu_chunk_lists = memblock_alloc_or_panic(pcpu_nr_slots *
 					  sizeof(pcpu_chunk_lists[0]),
 					  SMP_CACHE_BYTES);
-	if (!pcpu_chunk_lists)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      pcpu_nr_slots * sizeof(pcpu_chunk_lists[0]));
 
 	for (i = 0; i < pcpu_nr_slots; i++)
 		INIT_LIST_HEAD(&pcpu_chunk_lists[i]);
@@ -3155,25 +3127,19 @@ void __init __weak pcpu_populate_pte(unsigned long addr)
 	pmd_t *pmd;
 
 	if (pgd_none(*pgd)) {
-		p4d = memblock_alloc(P4D_TABLE_SIZE, P4D_TABLE_SIZE);
-		if (!p4d)
-			goto err_alloc;
+		p4d = memblock_alloc_or_panic(P4D_TABLE_SIZE, P4D_TABLE_SIZE);
 		pgd_populate(&init_mm, pgd, p4d);
 	}
 
 	p4d = p4d_offset(pgd, addr);
 	if (p4d_none(*p4d)) {
-		pud = memblock_alloc(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
-		if (!pud)
-			goto err_alloc;
+		pud = memblock_alloc_or_panic(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
 		p4d_populate(&init_mm, p4d, pud);
 	}
 
 	pud = pud_offset(p4d, addr);
 	if (pud_none(*pud)) {
-		pmd = memblock_alloc(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
-		if (!pmd)
-			goto err_alloc;
+		pmd = memblock_alloc_or_panic(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 	}
 
@@ -3181,16 +3147,11 @@ void __init __weak pcpu_populate_pte(unsigned long addr)
 	if (!pmd_present(*pmd)) {
 		pte_t *new;
 
-		new = memblock_alloc(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
-		if (!new)
-			goto err_alloc;
+		new = memblock_alloc_or_panic(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, new);
 	}
 
 	return;
-
-err_alloc:
-	panic("%s: Failed to allocate memory\n", __func__);
 }
 
 /**
@@ -3237,10 +3198,7 @@ int __init pcpu_page_first_chunk(size_t reserved_size, pcpu_fc_cpu_to_node_fn_t
 	/* unaligned allocations can't be freed, round up to page size */
 	pages_size = PFN_ALIGN(unit_pages * num_possible_cpus() *
 			       sizeof(pages[0]));
-	pages = memblock_alloc(pages_size, SMP_CACHE_BYTES);
-	if (!pages)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      pages_size);
+	pages = memblock_alloc_or_panic(pages_size, SMP_CACHE_BYTES);
 
 	/* allocate pages */
 	j = 0;
diff --git a/mm/sparse.c b/mm/sparse.c
index 13b6624d3562..133b033d0cba 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -257,10 +257,7 @@ static void __init memblocks_present(void)
 
 		size = sizeof(struct mem_section *) * NR_SECTION_ROOTS;
 		align = 1 << (INTERNODE_CACHE_SHIFT);
-		mem_section = memblock_alloc(size, align);
-		if (!mem_section)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, size, align);
+		mem_section = memblock_alloc_or_panic(size, align);
 	}
 #endif
 
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Sun Dec 22 05:44:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Dec 2024 05:44:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862606.1274213 (Exim 4.92)
	(envelope-from )
	id 1tPEl6-0004U8-25; Sun, 22 Dec 2024 05:44:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862606.1274213; Sun, 22 Dec 2024 05:44:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tPEl5-0004U0-TR; Sun, 22 Dec 2024 05:44:07 +0000
Received: by outflank-mailman (input) for mailman id 862606;
 Sun, 22 Dec 2024 05:44: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 1tPEl3-0004Tu-SO
 for xen-devel@lists.xenproject.org; Sun, 22 Dec 2024 05:44:06 +0000
Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com
 [2607:f8b0:4864:20::1031])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id be5ed564-c027-11ef-99a3-01e77a169b0f;
 Sun, 22 Dec 2024 06:44:01 +0100 (CET)
Received: by mail-pj1-x1031.google.com with SMTP id
 98e67ed59e1d1-2ee74291415so2393938a91.3
 for ; Sat, 21 Dec 2024 21:44:01 -0800 (PST)
Received: from localhost.localdomain ([36.110.106.149])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-2f454f58087sm4443412a91.11.2024.12.21.21.43.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 21 Dec 2024 21:43: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: be5ed564-c027-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734846239; x=1735451039; 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=NxCBSVvegpL4AXRrmCU+1dMPv/7znzdJDLKT63dDMTk=;
        b=QYU4hh21WxIdjMNWkI5mOPhWyXWa8nXktdMZPfQnULaQR6ilRS+LtEM4IoZHFVBzom
         3Kywm9gDmVMC43VXWLz+D6YOQpgYmPMvF53WImQJawc6kormt8Yxfx+Gw+e40ObdtzJs
         MkgOH27cBeBBFQBIgbOD4E3LhGQPLh1r8SL9/p+kjFknTntO+S6dsffdzss9MrWTvcB0
         Wn4ktLt0UlBnM6jZQt6eTJ+yAovqbPUWZr9ywJ+PDfGsCFoYSMtOsCnHccdqDs7y5XSL
         HmOxsKpePWWcShgahJi4WuFafn0I4ib/Q9wggOsQwwJUSquWPrA7fdHnGRkwAuaR3VsG
         M7HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734846239; x=1735451039;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=NxCBSVvegpL4AXRrmCU+1dMPv/7znzdJDLKT63dDMTk=;
        b=AHC3OIi6PEq69dLGN2CR62NvalsG6iCi5EEsSCSoH62GluK4SL9xaZ74v3TWsjpSL5
         qgTT8Ft9zNk7Vg+IOV+ITN0WGU99sQKa3uINNExQfziYsnfBAOnuwbNRhTZdmR/geC2y
         21aJ9qkApBWgebhK5sGY+4+vfBSM9r9A6bm8kO+/spWimTPwKGUG/wthto5aRx5P7bua
         y+tZUBYjzg6A7RvYHVOTNwUiaqqZu4XPCb/6jqS6tQ5kRMRNR/nZsS8OZptL14eCva5F
         9KKGvsAdnUUDhgaH6vwIO2JNZYjhDxyBces3jRSMrddPye7pDq8DifQ9J+RI+BkBMgyZ
         CuNA==
X-Forwarded-Encrypted: i=1; AJvYcCWWUhahFlpurRiRPvsj1AzdZCdh04QSUTuJ0c5QZPu06oCI8TJzLCUXzZ7E4AT2GPN3Pi2KMswoXus=@lists.xenproject.org
X-Gm-Message-State: AOJu0Ywr7SNapRsHLT1Mnz4TGtL7uK0HRvNLNEQBly62/fQ0jkMpTHXx
	eSZLdsUwBgILX2i8OUGnz7EySWWHnOHMCEJG0Gpov+is+zGv0fYt
X-Gm-Gg: ASbGncuB8QTNp6dqARQ50pjDmxjAwMDE47qtuGnSzpNjzpszhZ0ptvlOw9UzIa5s/Ca
	DsUSY8OKZWp8tEJ2HjQAhbilA/KTYDdZf15O2BSbFhqkXc2QxUn1ziBhFq+/rSE6rT7jjK+FoV8
	4T5MhmbH6AhhsNc8253HwothDkFB9r0m0T7eOGIqCykTpcZrjNESJrZrOkwjPoQqqmm7/gmbgIO
	BTHAVTe6YaRkDbJIrnD+KzQrbRpfohvG+Bv2GDmwUW+O92R8iM9UlJEl0fWNUBetHTexwFQ0mrV
	e7bJ
X-Google-Smtp-Source: AGHT+IE+f2wCNJicI2gTq3QVgpOdJtxfo8EYzaCZmYJXjsha0SzX5BS7lYqO8XSYzVbjevSjja++gA==
X-Received: by 2002:a17:90b:1b47:b0:2ee:bbd8:2b9d with SMTP id 98e67ed59e1d1-2f452eeb6c0mr11427615a91.34.1734846238978;
        Sat, 21 Dec 2024 21:43:58 -0800 (PST)
From: Guo Weikang 
To: Andrew Morton ,
	Mike Rapoport ,
	Geert Uytterhoeven ,
	Guo Weikang 
Cc: Dennis Zhou ,
	Tejun Heo ,
	Christoph Lameter ,
	Thomas Bogendoerfer ,
	Sam Creasey ,
	Huacai Chen ,
	Will Deacon ,
	Catalin Marinas ,
	Oreoluwa Babatunde ,
	rafael.j.wysocki@intel.com,
	Palmer Dabbelt ,
	Hanjun Guo ,
	Easwar Hariharan ,
	Johannes Berg ,
	Ingo Molnar ,
	Dave Hansen ,
	Christian Brauner ,
	KP Singh ,
	Richard Henderson ,
	Matt Turner ,
	Russell King ,
	WANG Xuerui ,
	Michael Ellerman ,
	Stefan Kristiansson ,
	Stafford Horne ,
	Helge Deller ,
	Nicholas Piggin ,
	Christophe Leroy ,
	Naveen N Rao ,
	Madhavan Srinivasan ,
	Geoff Levand ,
	Paul Walmsley ,
	Palmer Dabbelt ,
	Albert Ou ,
	Andrey Ryabinin ,
	Alexander Potapenko ,
	Andrey Konovalov ,
	Dmitry Vyukov ,
	Vincenzo Frascino ,
	Heiko Carstens ,
	Vasily Gorbik ,
	Alexander Gordeev ,
	Christian Borntraeger ,
	Sven Schnelle ,
	Yoshinori Sato ,
	Rich Felker ,
	John Paul Adrian Glaubitz ,
	Andreas Larsson ,
	Richard Weinberger ,
	Anton Ivanov ,
	Johannes Berg ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	x86@kernel.org,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-m68k@lists.linux-m68k.org,
	linux-mips@vger.kernel.org,
	linux-openrisc@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org,
	kasan-dev@googlegroups.com,
	linux-s390@vger.kernel.org,
	linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org,
	linux-um@lists.infradead.org,
	linux-acpi@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-omap@vger.kernel.org,
	linux-clk@vger.kernel.org,
	devicetree@vger.kernel.org,
	linux-mm@kvack.org,
	linux-pm@vger.kernel.org
Subject: [PATCH v6] mm/memblock: Add memblock_alloc_or_panic interface
Date: Sun, 22 Dec 2024 13:43:31 +0800
Message-Id: <20241222054331.2705948-1-guoweikang.kernel@gmail.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Before SLUB initialization, various subsystems used memblock_alloc to
allocate memory. In most cases, when memory allocation fails, an immediate
panic is required. To simplify this behavior and reduce repetitive checks,
introduce `memblock_alloc_or_panic`. This function ensures that memory
allocation failures result in a panic automatically, improving code
readability and consistency across subsystems that require this behavior.

Signed-off-by: Guo Weikang 
---
 arch/alpha/kernel/core_cia.c            |  5 +-
 arch/alpha/kernel/core_marvel.c         | 10 +---
 arch/alpha/kernel/pci.c                 | 13 +----
 arch/alpha/kernel/pci_iommu.c           | 10 +---
 arch/arm/kernel/setup.c                 | 10 +---
 arch/arm/mm/mmu.c                       | 17 ++----
 arch/arm/mm/nommu.c                     |  5 +-
 arch/arm64/kernel/setup.c               |  4 +-
 arch/loongarch/kernel/setup.c           |  2 +-
 arch/loongarch/mm/init.c                | 13 ++---
 arch/m68k/mm/init.c                     |  5 +-
 arch/m68k/mm/mcfmmu.c                   | 10 +---
 arch/m68k/mm/motorola.c                 |  5 +-
 arch/m68k/mm/sun3mmu.c                  | 10 +---
 arch/m68k/sun3/sun3dvma.c               |  6 +--
 arch/mips/kernel/setup.c                |  5 +-
 arch/openrisc/mm/ioremap.c              |  5 +-
 arch/parisc/mm/init.c                   | 20 ++-----
 arch/powerpc/kernel/dt_cpu_ftrs.c       | 10 ++--
 arch/powerpc/kernel/pci_32.c            |  5 +-
 arch/powerpc/kernel/setup-common.c      |  5 +-
 arch/powerpc/kernel/setup_32.c          |  8 +--
 arch/powerpc/mm/book3s32/mmu.c          |  5 +-
 arch/powerpc/mm/book3s64/pgtable.c      |  6 +--
 arch/powerpc/mm/kasan/init_book3e_64.c  |  8 +--
 arch/powerpc/mm/kasan/init_book3s_64.c  |  2 +-
 arch/powerpc/mm/nohash/mmu_context.c    | 16 ++----
 arch/powerpc/mm/pgtable_32.c            |  7 +--
 arch/powerpc/platforms/powermac/nvram.c |  5 +-
 arch/powerpc/platforms/powernv/opal.c   |  5 +-
 arch/powerpc/platforms/ps3/setup.c      |  5 +-
 arch/powerpc/sysdev/msi_bitmap.c        |  5 +-
 arch/riscv/kernel/setup.c               |  4 +-
 arch/riscv/mm/kasan_init.c              | 14 ++---
 arch/s390/kernel/numa.c                 |  5 +-
 arch/s390/kernel/setup.c                | 20 ++-----
 arch/s390/kernel/smp.c                  |  9 ++--
 arch/s390/kernel/topology.c             | 10 +---
 arch/sh/mm/init.c                       | 10 +---
 arch/sparc/kernel/prom_32.c             |  4 +-
 arch/sparc/mm/srmmu.c                   | 14 ++---
 arch/um/drivers/net_kern.c              |  5 +-
 arch/um/drivers/vector_kern.c           |  5 +-
 arch/um/kernel/load_file.c              |  4 +-
 arch/x86/coco/sev/core.c                |  4 +-
 arch/x86/kernel/acpi/boot.c             |  5 +-
 arch/x86/kernel/apic/io_apic.c          |  9 +---
 arch/x86/kernel/e820.c                  |  5 +-
 arch/x86/platform/olpc/olpc_dt.c        |  6 +--
 arch/x86/xen/p2m.c                      |  8 +--
 arch/xtensa/mm/kasan_init.c             |  6 +--
 drivers/clk/ti/clk.c                    |  5 +-
 drivers/macintosh/smu.c                 |  6 +--
 drivers/of/fdt.c                        |  8 +--
 drivers/of/unittest.c                   |  8 +--
 include/linux/memblock.h                |  6 +++
 init/main.c                             | 18 ++-----
 kernel/power/snapshot.c                 |  5 +-
 lib/cpumask.c                           |  5 +-
 mm/kmsan/shadow.c                       |  8 +--
 mm/memblock.c                           | 20 +++++++
 mm/numa.c                               |  8 +--
 mm/percpu.c                             | 70 +++++--------------------
 mm/sparse.c                             |  5 +-
 64 files changed, 143 insertions(+), 423 deletions(-)

diff --git a/arch/alpha/kernel/core_cia.c b/arch/alpha/kernel/core_cia.c
index ca3d9c732b61..6e577228e175 100644
--- a/arch/alpha/kernel/core_cia.c
+++ b/arch/alpha/kernel/core_cia.c
@@ -331,10 +331,7 @@ cia_prepare_tbia_workaround(int window)
 	long i;
 
 	/* Use minimal 1K map. */
-	ppte = memblock_alloc(CIA_BROKEN_TBIA_SIZE, 32768);
-	if (!ppte)
-		panic("%s: Failed to allocate %u bytes align=0x%x\n",
-		      __func__, CIA_BROKEN_TBIA_SIZE, 32768);
+	ppte = memblock_alloc_or_panic(CIA_BROKEN_TBIA_SIZE, 32768);
 	pte = (virt_to_phys(ppte) >> (PAGE_SHIFT - 1)) | 1;
 
 	for (i = 0; i < CIA_BROKEN_TBIA_SIZE / sizeof(unsigned long); ++i)
diff --git a/arch/alpha/kernel/core_marvel.c b/arch/alpha/kernel/core_marvel.c
index b22248044bf0..b1bfbd11980d 100644
--- a/arch/alpha/kernel/core_marvel.c
+++ b/arch/alpha/kernel/core_marvel.c
@@ -81,10 +81,7 @@ mk_resource_name(int pe, int port, char *str)
 	char *name;
 	
 	sprintf(tmp, "PCI %s PE %d PORT %d", str, pe, port);
-	name = memblock_alloc(strlen(tmp) + 1, SMP_CACHE_BYTES);
-	if (!name)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      strlen(tmp) + 1);
+	name = memblock_alloc_or_panic(strlen(tmp) + 1, SMP_CACHE_BYTES);
 	strcpy(name, tmp);
 
 	return name;
@@ -119,10 +116,7 @@ alloc_io7(unsigned int pe)
 		return NULL;
 	}
 
-	io7 = memblock_alloc(sizeof(*io7), SMP_CACHE_BYTES);
-	if (!io7)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*io7));
+	io7 = memblock_alloc_or_panic(sizeof(*io7), SMP_CACHE_BYTES);
 	io7->pe = pe;
 	raw_spin_lock_init(&io7->irq_lock);
 
diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
index 4458eb7f44f0..8e9b4ac86b7e 100644
--- a/arch/alpha/kernel/pci.c
+++ b/arch/alpha/kernel/pci.c
@@ -391,10 +391,7 @@ alloc_pci_controller(void)
 {
 	struct pci_controller *hose;
 
-	hose = memblock_alloc(sizeof(*hose), SMP_CACHE_BYTES);
-	if (!hose)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*hose));
+	hose = memblock_alloc_or_panic(sizeof(*hose), SMP_CACHE_BYTES);
 
 	*hose_tail = hose;
 	hose_tail = &hose->next;
@@ -405,13 +402,7 @@ alloc_pci_controller(void)
 struct resource * __init
 alloc_resource(void)
 {
-	void *ptr = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct resource));
-
-	return ptr;
+	return memblock_alloc_or_panic(sizeof(struct resource), SMP_CACHE_BYTES);
 }
 
 
diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index 7fcf3e9b7103..681f56089d9c 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -71,14 +71,8 @@ iommu_arena_new_node(int nid, struct pci_controller *hose, dma_addr_t base,
 	if (align < mem_size)
 		align = mem_size;
 
-	arena = memblock_alloc(sizeof(*arena), SMP_CACHE_BYTES);
-	if (!arena)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*arena));
-	arena->ptes = memblock_alloc(mem_size, align);
-	if (!arena->ptes)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, mem_size, align);
+	arena = memblock_alloc_or_panic(sizeof(*arena), SMP_CACHE_BYTES);
+	arena->ptes = memblock_alloc_or_panic(mem_size, align);
 
 	spin_lock_init(&arena->lock);
 	arena->hose = hose;
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index e6a857bf0ce6..a41c93988d2c 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -880,10 +880,7 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 		 */
 		boot_alias_start = phys_to_idmap(start);
 		if (arm_has_idmap_alias() && boot_alias_start != IDMAP_INVALID_ADDR) {
-			res = memblock_alloc(sizeof(*res), SMP_CACHE_BYTES);
-			if (!res)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, sizeof(*res));
+			res = memblock_alloc_or_panic(sizeof(*res), SMP_CACHE_BYTES);
 			res->name = "System RAM (boot alias)";
 			res->start = boot_alias_start;
 			res->end = phys_to_idmap(res_end);
@@ -891,10 +888,7 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 			request_resource(&iomem_resource, res);
 		}
 
-		res = memblock_alloc(sizeof(*res), SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      sizeof(*res));
+		res = memblock_alloc_or_panic(sizeof(*res), SMP_CACHE_BYTES);
 		res->name  = "System RAM";
 		res->start = start;
 		res->end = res_end;
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index f5b7a16c5803..f02f872ea8a9 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -726,13 +726,8 @@ EXPORT_SYMBOL(phys_mem_access_prot);
 
 static void __init *early_alloc(unsigned long sz)
 {
-	void *ptr = memblock_alloc(sz, sz);
+	return memblock_alloc_or_panic(sz, sz);
 
-	if (!ptr)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, sz, sz);
-
-	return ptr;
 }
 
 static void *__init late_alloc(unsigned long sz)
@@ -1027,10 +1022,7 @@ void __init iotable_init(struct map_desc *io_desc, int nr)
 	if (!nr)
 		return;
 
-	svm = memblock_alloc(sizeof(*svm) * nr, __alignof__(*svm));
-	if (!svm)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, sizeof(*svm) * nr, __alignof__(*svm));
+	svm = memblock_alloc_or_panic(sizeof(*svm) * nr, __alignof__(*svm));
 
 	for (md = io_desc; nr; md++, nr--) {
 		create_mapping(md);
@@ -1052,10 +1044,7 @@ void __init vm_reserve_area_early(unsigned long addr, unsigned long size,
 	struct vm_struct *vm;
 	struct static_vm *svm;
 
-	svm = memblock_alloc(sizeof(*svm), __alignof__(*svm));
-	if (!svm)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, sizeof(*svm), __alignof__(*svm));
+	svm = memblock_alloc_or_panic(sizeof(*svm), __alignof__(*svm));
 
 	vm = &svm->vm;
 	vm->addr = (void *)addr;
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index c415f3859b20..1a8f6914ee59 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -162,10 +162,7 @@ void __init paging_init(const struct machine_desc *mdesc)
 	mpu_setup();
 
 	/* allocate the zero page. */
-	zero_page = (void *)memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	zero_page = (void *)memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	bootmem_init();
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 4f613e8e0745..85104587f849 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -223,9 +223,7 @@ static void __init request_standard_resources(void)
 
 	num_standard_resources = memblock.memory.cnt;
 	res_size = num_standard_resources * sizeof(*standard_resources);
-	standard_resources = memblock_alloc(res_size, SMP_CACHE_BYTES);
-	if (!standard_resources)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, res_size);
+	standard_resources = memblock_alloc_or_panic(res_size, SMP_CACHE_BYTES);
 
 	for_each_mem_region(region) {
 		res = &standard_resources[i++];
diff --git a/arch/loongarch/kernel/setup.c b/arch/loongarch/kernel/setup.c
index 56934fe58170..edcfdfcad7d2 100644
--- a/arch/loongarch/kernel/setup.c
+++ b/arch/loongarch/kernel/setup.c
@@ -431,7 +431,7 @@ static void __init resource_init(void)
 
 	num_standard_resources = memblock.memory.cnt;
 	res_size = num_standard_resources * sizeof(*standard_resources);
-	standard_resources = memblock_alloc(res_size, SMP_CACHE_BYTES);
+	standard_resources = memblock_alloc_or_panic(res_size, SMP_CACHE_BYTES);
 
 	for_each_mem_region(region) {
 		res = &standard_resources[i++];
diff --git a/arch/loongarch/mm/init.c b/arch/loongarch/mm/init.c
index 188b52bbb254..ca5aa5f46a9f 100644
--- a/arch/loongarch/mm/init.c
+++ b/arch/loongarch/mm/init.c
@@ -174,9 +174,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 	pmd_t *pmd;
 
 	if (p4d_none(p4dp_get(p4d))) {
-		pud = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pud)
-			panic("%s: Failed to allocate memory\n", __func__);
+		pud = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		p4d_populate(&init_mm, p4d, pud);
 #ifndef __PAGETABLE_PUD_FOLDED
 		pud_init(pud);
@@ -185,9 +183,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 
 	pud = pud_offset(p4d, addr);
 	if (pud_none(pudp_get(pud))) {
-		pmd = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pmd)
-			panic("%s: Failed to allocate memory\n", __func__);
+		pmd = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 #ifndef __PAGETABLE_PMD_FOLDED
 		pmd_init(pmd);
@@ -198,10 +194,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 	if (!pmd_present(pmdp_get(pmd))) {
 		pte_t *pte;
 
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate memory\n", __func__);
-
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, pte);
 		kernel_pte_init(pte);
 	}
diff --git a/arch/m68k/mm/init.c b/arch/m68k/mm/init.c
index 1b47bec15832..8b11d0d545aa 100644
--- a/arch/m68k/mm/init.c
+++ b/arch/m68k/mm/init.c
@@ -68,10 +68,7 @@ void __init paging_init(void)
 
 	high_memory = (void *) end_mem;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	max_zone_pfn[ZONE_DMA] = end_mem >> PAGE_SHIFT;
 	free_area_init(max_zone_pfn);
 }
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index 9a6fa342e872..19a75029036c 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -42,20 +42,14 @@ void __init paging_init(void)
 	unsigned long max_zone_pfn[MAX_NR_ZONES] = { 0 };
 	int i;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	pg_dir = swapper_pg_dir;
 	memset(swapper_pg_dir, 0, sizeof(swapper_pg_dir));
 
 	size = num_pages * sizeof(pte_t);
 	size = (size + PAGE_SIZE) & ~(PAGE_SIZE-1);
-	next_pgtable = (unsigned long) memblock_alloc(size, PAGE_SIZE);
-	if (!next_pgtable)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, PAGE_SIZE);
+	next_pgtable = (unsigned long) memblock_alloc_or_panic(size, PAGE_SIZE);
 
 	pg_dir += PAGE_OFFSET >> PGDIR_SHIFT;
 
diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
index c1761d309fc6..795dd1f2b24f 100644
--- a/arch/m68k/mm/motorola.c
+++ b/arch/m68k/mm/motorola.c
@@ -491,10 +491,7 @@ void __init paging_init(void)
 	 * initialize the bad page table and bad page to point
 	 * to a couple of allocated pages
 	 */
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	/*
 	 * Set up SFC/DFC registers
diff --git a/arch/m68k/mm/sun3mmu.c b/arch/m68k/mm/sun3mmu.c
index 494739c1783e..1ecf6bdd08bf 100644
--- a/arch/m68k/mm/sun3mmu.c
+++ b/arch/m68k/mm/sun3mmu.c
@@ -44,10 +44,7 @@ void __init paging_init(void)
 	unsigned long max_zone_pfn[MAX_NR_ZONES] = { 0, };
 	unsigned long size;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	address = PAGE_OFFSET;
 	pg_dir = swapper_pg_dir;
@@ -57,10 +54,7 @@ void __init paging_init(void)
 	size = num_pages * sizeof(pte_t);
 	size = (size + PAGE_SIZE) & ~(PAGE_SIZE-1);
 
-	next_pgtable = (unsigned long)memblock_alloc(size, PAGE_SIZE);
-	if (!next_pgtable)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, PAGE_SIZE);
+	next_pgtable = (unsigned long)memblock_alloc_or_panic(size, PAGE_SIZE);
 	bootmem_end = (next_pgtable + size + PAGE_SIZE) & PAGE_MASK;
 
 	/* Map whole memory from PAGE_OFFSET (0x0E000000) */
diff --git a/arch/m68k/sun3/sun3dvma.c b/arch/m68k/sun3/sun3dvma.c
index 6ebf52740ad7..225fc735e466 100644
--- a/arch/m68k/sun3/sun3dvma.c
+++ b/arch/m68k/sun3/sun3dvma.c
@@ -252,12 +252,8 @@ void __init dvma_init(void)
 
 	list_add(&(hole->list), &hole_list);
 
-	iommu_use = memblock_alloc(IOMMU_TOTAL_ENTRIES * sizeof(unsigned long),
+	iommu_use = memblock_alloc_or_panic(IOMMU_TOTAL_ENTRIES * sizeof(unsigned long),
 				   SMP_CACHE_BYTES);
-	if (!iommu_use)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      IOMMU_TOTAL_ENTRIES * sizeof(unsigned long));
-
 	dvma_unmap_iommu(DVMA_START, DVMA_SIZE);
 
 	sun3_dvma_init();
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 12a1a4ffb602..fbfe0771317e 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -704,10 +704,7 @@ static void __init resource_init(void)
 	for_each_mem_range(i, &start, &end) {
 		struct resource *res;
 
-		res = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      sizeof(struct resource));
+		res = memblock_alloc_or_panic(sizeof(struct resource), SMP_CACHE_BYTES);
 
 		res->start = start;
 		/*
diff --git a/arch/openrisc/mm/ioremap.c b/arch/openrisc/mm/ioremap.c
index f59ea4c10b0f..8e63e86251ca 100644
--- a/arch/openrisc/mm/ioremap.c
+++ b/arch/openrisc/mm/ioremap.c
@@ -38,10 +38,7 @@ pte_t __ref *pte_alloc_one_kernel(struct mm_struct *mm)
 	if (likely(mem_init_done)) {
 		pte = (pte_t *)get_zeroed_page(GFP_KERNEL);
 	} else {
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	}
 
 	return pte;
diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index 96970fa75e4a..61c0a2477072 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -377,10 +377,8 @@ static void __ref map_pages(unsigned long start_vaddr,
 
 #if CONFIG_PGTABLE_LEVELS == 3
 		if (pud_none(*pud)) {
-			pmd = memblock_alloc(PAGE_SIZE << PMD_TABLE_ORDER,
+			pmd = memblock_alloc_or_panic(PAGE_SIZE << PMD_TABLE_ORDER,
 					     PAGE_SIZE << PMD_TABLE_ORDER);
-			if (!pmd)
-				panic("pmd allocation failed.\n");
 			pud_populate(NULL, pud, pmd);
 		}
 #endif
@@ -388,9 +386,7 @@ static void __ref map_pages(unsigned long start_vaddr,
 		pmd = pmd_offset(pud, vaddr);
 		for (tmp1 = start_pmd; tmp1 < PTRS_PER_PMD; tmp1++, pmd++) {
 			if (pmd_none(*pmd)) {
-				pg_table = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-				if (!pg_table)
-					panic("page table allocation failed\n");
+				pg_table = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 				pmd_populate_kernel(NULL, pmd, pg_table);
 			}
 
@@ -648,9 +644,7 @@ static void __init pagetable_init(void)
 	}
 #endif
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("zero page allocation failed.\n");
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 }
 
@@ -687,19 +681,15 @@ static void __init fixmap_init(void)
 
 #if CONFIG_PGTABLE_LEVELS == 3
 	if (pud_none(*pud)) {
-		pmd = memblock_alloc(PAGE_SIZE << PMD_TABLE_ORDER,
+		pmd = memblock_alloc_or_panic(PAGE_SIZE << PMD_TABLE_ORDER,
 				     PAGE_SIZE << PMD_TABLE_ORDER);
-		if (!pmd)
-			panic("fixmap: pmd allocation failed.\n");
 		pud_populate(NULL, pud, pmd);
 	}
 #endif
 
 	pmd = pmd_offset(pud, addr);
 	do {
-		pte_t *pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("fixmap: pte allocation failed.\n");
+		pte_t *pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 		pmd_populate_kernel(&init_mm, pmd, pte);
 
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 1bee15c013e7..3af6c06af02f 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -1087,12 +1087,10 @@ static int __init dt_cpu_ftrs_scan_callback(unsigned long node, const char
 	/* Count and allocate space for cpu features */
 	of_scan_flat_dt_subnodes(node, count_cpufeatures_subnodes,
 						&nr_dt_cpu_features);
-	dt_cpu_features = memblock_alloc(sizeof(struct dt_cpu_feature) * nr_dt_cpu_features, PAGE_SIZE);
-	if (!dt_cpu_features)
-		panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
-		      __func__,
-		      sizeof(struct dt_cpu_feature) * nr_dt_cpu_features,
-		      PAGE_SIZE);
+	dt_cpu_features =
+		memblock_alloc_or_panic(
+			sizeof(struct dt_cpu_feature) * nr_dt_cpu_features,
+			PAGE_SIZE);
 
 	cpufeatures_setup_start(isa);
 
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index ce0c8623e563..f8a3bd8cfae4 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -213,11 +213,8 @@ pci_create_OF_bus_map(void)
 	struct property* of_prop;
 	struct device_node *dn;
 
-	of_prop = memblock_alloc(sizeof(struct property) + 256,
+	of_prop = memblock_alloc_or_panic(sizeof(struct property) + 256,
 				 SMP_CACHE_BYTES);
-	if (!of_prop)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct property) + 256);
 	dn = of_find_node_by_path("/");
 	if (dn) {
 		memset(of_prop, -1, sizeof(struct property) + 256);
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 6fa179448c33..f3ea1329c566 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -458,11 +458,8 @@ void __init smp_setup_cpu_maps(void)
 
 	DBG("smp_setup_cpu_maps()\n");
 
-	cpu_to_phys_id = memblock_alloc(nr_cpu_ids * sizeof(u32),
+	cpu_to_phys_id = memblock_alloc_or_panic(nr_cpu_ids * sizeof(u32),
 					__alignof__(u32));
-	if (!cpu_to_phys_id)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, nr_cpu_ids * sizeof(u32), __alignof__(u32));
 
 	for_each_node_by_type(dn, "cpu") {
 		const __be32 *intserv;
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 75dbf3e0d9c4..5a1bf501fbe1 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -140,13 +140,7 @@ arch_initcall(ppc_init);
 
 static void *__init alloc_stack(void)
 {
-	void *ptr = memblock_alloc(THREAD_SIZE, THREAD_ALIGN);
-
-	if (!ptr)
-		panic("cannot allocate %d bytes for stack at %pS\n",
-		      THREAD_SIZE, (void *)_RET_IP_);
-
-	return ptr;
+	return memblock_alloc_or_panic(THREAD_SIZE, THREAD_ALIGN);
 }
 
 void __init irqstack_early_init(void)
diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/mmu.c
index 6978344edcb4..be9c4106e22f 100644
--- a/arch/powerpc/mm/book3s32/mmu.c
+++ b/arch/powerpc/mm/book3s32/mmu.c
@@ -377,10 +377,7 @@ void __init MMU_init_hw(void)
 	 * Find some memory for the hash table.
 	 */
 	if ( ppc_md.progress ) ppc_md.progress("hash:find piece", 0x322);
-	Hash = memblock_alloc(Hash_size, Hash_size);
-	if (!Hash)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, Hash_size, Hash_size);
+	Hash = memblock_alloc_or_panic(Hash_size, Hash_size);
 	_SDR1 = __pa(Hash) | SDR1_LOW_BITS;
 
 	pr_info("Total memory = %lldMB; using %ldkB for hash table\n",
diff --git a/arch/powerpc/mm/book3s64/pgtable.c b/arch/powerpc/mm/book3s64/pgtable.c
index 374542528080..0b1f419b7404 100644
--- a/arch/powerpc/mm/book3s64/pgtable.c
+++ b/arch/powerpc/mm/book3s64/pgtable.c
@@ -330,11 +330,7 @@ void __init mmu_partition_table_init(void)
 	unsigned long ptcr;
 
 	/* Initialize the Partition Table with no entries */
-	partition_tb = memblock_alloc(patb_size, patb_size);
-	if (!partition_tb)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, patb_size, patb_size);
-
+	partition_tb = memblock_alloc_or_panic(patb_size, patb_size);
 	ptcr = __pa(partition_tb) | (PATB_SIZE_SHIFT - 12);
 	set_ptcr_when_no_uv(ptcr);
 	powernv_set_nmmu_ptcr(ptcr);
diff --git a/arch/powerpc/mm/kasan/init_book3e_64.c b/arch/powerpc/mm/kasan/init_book3e_64.c
index 43c03b84ff32..60c78aac0f63 100644
--- a/arch/powerpc/mm/kasan/init_book3e_64.c
+++ b/arch/powerpc/mm/kasan/init_book3e_64.c
@@ -40,19 +40,19 @@ static int __init kasan_map_kernel_page(unsigned long ea, unsigned long pa, pgpr
 	pgdp = pgd_offset_k(ea);
 	p4dp = p4d_offset(pgdp, ea);
 	if (kasan_pud_table(*p4dp)) {
-		pudp = memblock_alloc(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
+		pudp = memblock_alloc_or_panic(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
 		memcpy(pudp, kasan_early_shadow_pud, PUD_TABLE_SIZE);
 		p4d_populate(&init_mm, p4dp, pudp);
 	}
 	pudp = pud_offset(p4dp, ea);
 	if (kasan_pmd_table(*pudp)) {
-		pmdp = memblock_alloc(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
+		pmdp = memblock_alloc_or_panic(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
 		memcpy(pmdp, kasan_early_shadow_pmd, PMD_TABLE_SIZE);
 		pud_populate(&init_mm, pudp, pmdp);
 	}
 	pmdp = pmd_offset(pudp, ea);
 	if (kasan_pte_table(*pmdp)) {
-		ptep = memblock_alloc(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
+		ptep = memblock_alloc_or_panic(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
 		memcpy(ptep, kasan_early_shadow_pte, PTE_TABLE_SIZE);
 		pmd_populate_kernel(&init_mm, pmdp, ptep);
 	}
@@ -74,7 +74,7 @@ static void __init kasan_init_phys_region(void *start, void *end)
 	k_start = ALIGN_DOWN((unsigned long)kasan_mem_to_shadow(start), PAGE_SIZE);
 	k_end = ALIGN((unsigned long)kasan_mem_to_shadow(end), PAGE_SIZE);
 
-	va = memblock_alloc(k_end - k_start, PAGE_SIZE);
+	va = memblock_alloc_or_panic(k_end - k_start, PAGE_SIZE);
 	for (k_cur = k_start; k_cur < k_end; k_cur += PAGE_SIZE, va += PAGE_SIZE)
 		kasan_map_kernel_page(k_cur, __pa(va), PAGE_KERNEL);
 }
diff --git a/arch/powerpc/mm/kasan/init_book3s_64.c b/arch/powerpc/mm/kasan/init_book3s_64.c
index 3fb5ce4f48f4..7d959544c077 100644
--- a/arch/powerpc/mm/kasan/init_book3s_64.c
+++ b/arch/powerpc/mm/kasan/init_book3s_64.c
@@ -32,7 +32,7 @@ static void __init kasan_init_phys_region(void *start, void *end)
 	k_start = ALIGN_DOWN((unsigned long)kasan_mem_to_shadow(start), PAGE_SIZE);
 	k_end = ALIGN((unsigned long)kasan_mem_to_shadow(end), PAGE_SIZE);
 
-	va = memblock_alloc(k_end - k_start, PAGE_SIZE);
+	va = memblock_alloc_or_panic(k_end - k_start, PAGE_SIZE);
 	for (k_cur = k_start; k_cur < k_end; k_cur += PAGE_SIZE, va += PAGE_SIZE)
 		map_kernel_page(k_cur, __pa(va), PAGE_KERNEL);
 }
diff --git a/arch/powerpc/mm/nohash/mmu_context.c b/arch/powerpc/mm/nohash/mmu_context.c
index 0b181da40ddb..a1a4e697251a 100644
--- a/arch/powerpc/mm/nohash/mmu_context.c
+++ b/arch/powerpc/mm/nohash/mmu_context.c
@@ -385,21 +385,11 @@ void __init mmu_context_init(void)
 	/*
 	 * Allocate the maps used by context management
 	 */
-	context_map = memblock_alloc(CTX_MAP_SIZE, SMP_CACHE_BYTES);
-	if (!context_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      CTX_MAP_SIZE);
-	context_mm = memblock_alloc(sizeof(void *) * (LAST_CONTEXT + 1),
+	context_map = memblock_alloc_or_panic(CTX_MAP_SIZE, SMP_CACHE_BYTES);
+	context_mm = memblock_alloc_or_panic(sizeof(void *) * (LAST_CONTEXT + 1),
 				    SMP_CACHE_BYTES);
-	if (!context_mm)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(void *) * (LAST_CONTEXT + 1));
 	if (IS_ENABLED(CONFIG_SMP)) {
-		stale_map[boot_cpuid] = memblock_alloc(CTX_MAP_SIZE, SMP_CACHE_BYTES);
-		if (!stale_map[boot_cpuid])
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      CTX_MAP_SIZE);
-
+		stale_map[boot_cpuid] = memblock_alloc_or_panic(CTX_MAP_SIZE, SMP_CACHE_BYTES);
 		cpuhp_setup_state_nocalls(CPUHP_POWERPC_MMU_CTX_PREPARE,
 					  "powerpc/mmu/ctx:prepare",
 					  mmu_ctx_cpu_prepare, mmu_ctx_cpu_dead);
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 787b22206386..15276068f657 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -50,13 +50,8 @@ notrace void __init early_ioremap_init(void)
 
 void __init *early_alloc_pgtable(unsigned long size)
 {
-	void *ptr = memblock_alloc(size, size);
+	return memblock_alloc_or_panic(size, size);
 
-	if (!ptr)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, size);
-
-	return ptr;
 }
 
 pte_t __init *early_pte_alloc_kernel(pmd_t *pmdp, unsigned long va)
diff --git a/arch/powerpc/platforms/powermac/nvram.c b/arch/powerpc/platforms/powermac/nvram.c
index fe2e0249cbc2..a112d26185a0 100644
--- a/arch/powerpc/platforms/powermac/nvram.c
+++ b/arch/powerpc/platforms/powermac/nvram.c
@@ -514,10 +514,7 @@ static int __init core99_nvram_setup(struct device_node *dp, unsigned long addr)
 		printk(KERN_ERR "nvram: no address\n");
 		return -EINVAL;
 	}
-	nvram_image = memblock_alloc(NVRAM_SIZE, SMP_CACHE_BYTES);
-	if (!nvram_image)
-		panic("%s: Failed to allocate %u bytes\n", __func__,
-		      NVRAM_SIZE);
+	nvram_image = memblock_alloc_or_panic(NVRAM_SIZE, SMP_CACHE_BYTES);
 	nvram_data = ioremap(addr, NVRAM_SIZE*2);
 	nvram_naddrs = 1; /* Make sure we get the correct case */
 
diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
index 5d0f35bb917e..09bd93464b4f 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -180,10 +180,7 @@ int __init early_init_dt_scan_recoverable_ranges(unsigned long node,
 	/*
 	 * Allocate a buffer to hold the MC recoverable ranges.
 	 */
-	mc_recoverable_range = memblock_alloc(size, __alignof__(u64));
-	if (!mc_recoverable_range)
-		panic("%s: Failed to allocate %u bytes align=0x%lx\n",
-		      __func__, size, __alignof__(u64));
+	mc_recoverable_range = memblock_alloc_or_panic(size, __alignof__(u64));
 
 	for (i = 0; i < mc_recoverable_range_len; i++) {
 		mc_recoverable_range[i].start_addr =
diff --git a/arch/powerpc/platforms/ps3/setup.c b/arch/powerpc/platforms/ps3/setup.c
index 5144f11359f7..150c09b58ae8 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -115,10 +115,7 @@ static void __init prealloc(struct ps3_prealloc *p)
 	if (!p->size)
 		return;
 
-	p->address = memblock_alloc(p->size, p->align);
-	if (!p->address)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, p->size, p->align);
+	p->address = memblock_alloc_or_panic(p->size, p->align);
 
 	printk(KERN_INFO "%s: %lu bytes at %p\n", p->name, p->size,
 	       p->address);
diff --git a/arch/powerpc/sysdev/msi_bitmap.c b/arch/powerpc/sysdev/msi_bitmap.c
index 0b6e37f3ffb8..456a4f64ae0a 100644
--- a/arch/powerpc/sysdev/msi_bitmap.c
+++ b/arch/powerpc/sysdev/msi_bitmap.c
@@ -124,10 +124,7 @@ int __ref msi_bitmap_alloc(struct msi_bitmap *bmp, unsigned int irq_count,
 	if (bmp->bitmap_from_slab)
 		bmp->bitmap = kzalloc(size, GFP_KERNEL);
 	else {
-		bmp->bitmap = memblock_alloc(size, SMP_CACHE_BYTES);
-		if (!bmp->bitmap)
-			panic("%s: Failed to allocate %u bytes\n", __func__,
-			      size);
+		bmp->bitmap = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 		/* the bitmap won't be freed from memblock allocator */
 		kmemleak_not_leak(bmp->bitmap);
 	}
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 45010e71df86..f1793630fc51 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -147,9 +147,7 @@ static void __init init_resources(void)
 	res_idx = num_resources - 1;
 
 	mem_res_sz = num_resources * sizeof(*mem_res);
-	mem_res = memblock_alloc(mem_res_sz, SMP_CACHE_BYTES);
-	if (!mem_res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, mem_res_sz);
+	mem_res = memblock_alloc_or_panic(mem_res_sz, SMP_CACHE_BYTES);
 
 	/*
 	 * Start by adding the reserved regions, if they overlap
diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index c301c8d291d2..41c635d6aca4 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -32,7 +32,7 @@ static void __init kasan_populate_pte(pmd_t *pmd, unsigned long vaddr, unsigned
 	pte_t *ptep, *p;
 
 	if (pmd_none(pmdp_get(pmd))) {
-		p = memblock_alloc(PTRS_PER_PTE * sizeof(pte_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PTE * sizeof(pte_t), PAGE_SIZE);
 		set_pmd(pmd, pfn_pmd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -54,7 +54,7 @@ static void __init kasan_populate_pmd(pud_t *pud, unsigned long vaddr, unsigned
 	unsigned long next;
 
 	if (pud_none(pudp_get(pud))) {
-		p = memblock_alloc(PTRS_PER_PMD * sizeof(pmd_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PMD * sizeof(pmd_t), PAGE_SIZE);
 		set_pud(pud, pfn_pud(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -85,7 +85,7 @@ static void __init kasan_populate_pud(p4d_t *p4d,
 	unsigned long next;
 
 	if (p4d_none(p4dp_get(p4d))) {
-		p = memblock_alloc(PTRS_PER_PUD * sizeof(pud_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PUD * sizeof(pud_t), PAGE_SIZE);
 		set_p4d(p4d, pfn_p4d(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -116,7 +116,7 @@ static void __init kasan_populate_p4d(pgd_t *pgd,
 	unsigned long next;
 
 	if (pgd_none(pgdp_get(pgd))) {
-		p = memblock_alloc(PTRS_PER_P4D * sizeof(p4d_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_P4D * sizeof(p4d_t), PAGE_SIZE);
 		set_pgd(pgd, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -385,7 +385,7 @@ static void __init kasan_shallow_populate_pud(p4d_t *p4d,
 		next = pud_addr_end(vaddr, end);
 
 		if (pud_none(pudp_get(pud_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_pud(pud_k, pfn_pud(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
@@ -405,7 +405,7 @@ static void __init kasan_shallow_populate_p4d(pgd_t *pgd,
 		next = p4d_addr_end(vaddr, end);
 
 		if (p4d_none(p4dp_get(p4d_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_p4d(p4d_k, pfn_p4d(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
@@ -424,7 +424,7 @@ static void __init kasan_shallow_populate_pgd(unsigned long vaddr, unsigned long
 		next = pgd_addr_end(vaddr, end);
 
 		if (pgd_none(pgdp_get(pgd_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_pgd(pgd_k, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
diff --git a/arch/s390/kernel/numa.c b/arch/s390/kernel/numa.c
index ddc1448ea2e1..a33e20f73330 100644
--- a/arch/s390/kernel/numa.c
+++ b/arch/s390/kernel/numa.c
@@ -22,10 +22,7 @@ void __init numa_setup(void)
 	node_set(0, node_possible_map);
 	node_set_online(0);
 	for (nid = 0; nid < MAX_NUMNODES; nid++) {
-		NODE_DATA(nid) = memblock_alloc(sizeof(pg_data_t), 8);
-		if (!NODE_DATA(nid))
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(pg_data_t), 8);
+		NODE_DATA(nid) = memblock_alloc_or_panic(sizeof(pg_data_t), 8);
 	}
 	NODE_DATA(0)->node_spanned_pages = memblock_end_of_DRAM() >> PAGE_SHIFT;
 	NODE_DATA(0)->node_id = 0;
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index 0ce550faf073..1298f0860733 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -376,11 +376,7 @@ static unsigned long __init stack_alloc_early(void)
 {
 	unsigned long stack;
 
-	stack = (unsigned long)memblock_alloc(THREAD_SIZE, THREAD_SIZE);
-	if (!stack) {
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, THREAD_SIZE, THREAD_SIZE);
-	}
+	stack = (unsigned long)memblock_alloc_or_panic(THREAD_SIZE, THREAD_SIZE);
 	return stack;
 }
 
@@ -504,10 +500,7 @@ static void __init setup_resources(void)
 	bss_resource.end = __pa_symbol(__bss_stop) - 1;
 
 	for_each_mem_range(i, &start, &end) {
-		res = memblock_alloc(sizeof(*res), 8);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(*res), 8);
+		res = memblock_alloc_or_panic(sizeof(*res), 8);
 		res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
 
 		res->name = "System RAM";
@@ -526,10 +519,7 @@ static void __init setup_resources(void)
 			    std_res->start > res->end)
 				continue;
 			if (std_res->end > res->end) {
-				sub_res = memblock_alloc(sizeof(*sub_res), 8);
-				if (!sub_res)
-					panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-					      __func__, sizeof(*sub_res), 8);
+				sub_res = memblock_alloc_or_panic(sizeof(*sub_res), 8);
 				*sub_res = *std_res;
 				sub_res->end = res->end;
 				std_res->start = res->end + 1;
@@ -816,9 +806,7 @@ static void __init setup_randomness(void)
 {
 	struct sysinfo_3_2_2 *vmms;
 
-	vmms = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!vmms)
-		panic("Failed to allocate memory for sysinfo structure\n");
+	vmms = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	if (stsi(vmms, 3, 2, 2) == 0 && vmms->count)
 		add_device_randomness(&vmms->vm, sizeof(vmms->vm[0]) * vmms->count);
 	memblock_free(vmms, PAGE_SIZE);
diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
index 822d8e6f8717..d77aaefb59bd 100644
--- a/arch/s390/kernel/smp.c
+++ b/arch/s390/kernel/smp.c
@@ -611,9 +611,9 @@ void __init smp_save_dump_ipl_cpu(void)
 	if (!dump_available())
 		return;
 	sa = save_area_alloc(true);
-	regs = memblock_alloc(512, 8);
-	if (!sa || !regs)
+	if (!sa)
 		panic("could not allocate memory for boot CPU save area\n");
+	regs = memblock_alloc_or_panic(512, 8);
 	copy_oldmem_kernel(regs, __LC_FPREGS_SAVE_AREA, 512);
 	save_area_add_regs(sa, regs);
 	memblock_free(regs, 512);
@@ -792,10 +792,7 @@ void __init smp_detect_cpus(void)
 	u16 address;
 
 	/* Get CPU information */
-	info = memblock_alloc(sizeof(*info), 8);
-	if (!info)
-		panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-		      __func__, sizeof(*info), 8);
+	info = memblock_alloc_or_panic(sizeof(*info), 8);
 	smp_get_core_info(info, 1);
 	/* Find boot CPU type */
 	if (sclp.has_core_type) {
diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
index 0fd56a1cadbd..cf5ee6032c0b 100644
--- a/arch/s390/kernel/topology.c
+++ b/arch/s390/kernel/topology.c
@@ -548,10 +548,7 @@ static void __init alloc_masks(struct sysinfo_15_1_x *info,
 		nr_masks *= info->mag[TOPOLOGY_NR_MAG - offset - 1 - i];
 	nr_masks = max(nr_masks, 1);
 	for (i = 0; i < nr_masks; i++) {
-		mask->next = memblock_alloc(sizeof(*mask->next), 8);
-		if (!mask->next)
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(*mask->next), 8);
+		mask->next = memblock_alloc_or_panic(sizeof(*mask->next), 8);
 		mask = mask->next;
 	}
 }
@@ -569,10 +566,7 @@ void __init topology_init_early(void)
 	}
 	if (!MACHINE_HAS_TOPOLOGY)
 		goto out;
-	tl_info = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!tl_info)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	tl_info = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	info = tl_info;
 	store_topology(info);
 	pr_info("The CPU configuration topology of the machine is: %d %d %d %d %d %d / %d\n",
diff --git a/arch/sh/mm/init.c b/arch/sh/mm/init.c
index 2a88b0c9e70f..289a2fecebef 100644
--- a/arch/sh/mm/init.c
+++ b/arch/sh/mm/init.c
@@ -137,10 +137,7 @@ static pmd_t * __init one_md_table_init(pud_t *pud)
 	if (pud_none(*pud)) {
 		pmd_t *pmd;
 
-		pmd = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pmd)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pmd = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 		BUG_ON(pmd != pmd_offset(pud, 0));
 	}
@@ -153,10 +150,7 @@ static pte_t * __init one_page_table_init(pmd_t *pmd)
 	if (pmd_none(*pmd)) {
 		pte_t *pte;
 
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, pte);
 		BUG_ON(pte != pte_offset_kernel(pmd, 0));
 	}
diff --git a/arch/sparc/kernel/prom_32.c b/arch/sparc/kernel/prom_32.c
index 3df960c137f7..a67dd67f10c8 100644
--- a/arch/sparc/kernel/prom_32.c
+++ b/arch/sparc/kernel/prom_32.c
@@ -28,9 +28,7 @@ void * __init prom_early_alloc(unsigned long size)
 {
 	void *ret;
 
-	ret = memblock_alloc(size, SMP_CACHE_BYTES);
-	if (!ret)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, size);
+	ret = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 
 	prom_early_allocated += size;
 
diff --git a/arch/sparc/mm/srmmu.c b/arch/sparc/mm/srmmu.c
index 9df51a62333d..e36c2a0ff748 100644
--- a/arch/sparc/mm/srmmu.c
+++ b/arch/sparc/mm/srmmu.c
@@ -277,19 +277,13 @@ static void __init srmmu_nocache_init(void)
 
 	bitmap_bits = srmmu_nocache_size >> SRMMU_NOCACHE_BITMAP_SHIFT;
 
-	srmmu_nocache_pool = memblock_alloc(srmmu_nocache_size,
+	srmmu_nocache_pool = memblock_alloc_or_panic(srmmu_nocache_size,
 					    SRMMU_NOCACHE_ALIGN_MAX);
-	if (!srmmu_nocache_pool)
-		panic("%s: Failed to allocate %lu bytes align=0x%x\n",
-		      __func__, srmmu_nocache_size, SRMMU_NOCACHE_ALIGN_MAX);
 	memset(srmmu_nocache_pool, 0, srmmu_nocache_size);
 
 	srmmu_nocache_bitmap =
-		memblock_alloc(BITS_TO_LONGS(bitmap_bits) * sizeof(long),
+		memblock_alloc_or_panic(BITS_TO_LONGS(bitmap_bits) * sizeof(long),
 			       SMP_CACHE_BYTES);
-	if (!srmmu_nocache_bitmap)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      BITS_TO_LONGS(bitmap_bits) * sizeof(long));
 	bit_map_init(&srmmu_nocache_map, srmmu_nocache_bitmap, bitmap_bits);
 
 	srmmu_swapper_pg_dir = __srmmu_get_nocache(SRMMU_PGD_TABLE_SIZE, SRMMU_PGD_TABLE_SIZE);
@@ -452,9 +446,7 @@ static void __init sparc_context_init(int numctx)
 	unsigned long size;
 
 	size = numctx * sizeof(struct ctx_list);
-	ctx_list_pool = memblock_alloc(size, SMP_CACHE_BYTES);
-	if (!ctx_list_pool)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, size);
+	ctx_list_pool = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 
 	for (ctx = 0; ctx < numctx; ctx++) {
 		struct ctx_list *clist;
diff --git a/arch/um/drivers/net_kern.c b/arch/um/drivers/net_kern.c
index 75d04fb4994a..d5a9c5aabaec 100644
--- a/arch/um/drivers/net_kern.c
+++ b/arch/um/drivers/net_kern.c
@@ -636,10 +636,7 @@ static int __init eth_setup(char *str)
 		return 1;
 	}
 
-	new = memblock_alloc(sizeof(*new), SMP_CACHE_BYTES);
-	if (!new)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*new));
+	new = memblock_alloc_or_panic(sizeof(*new), SMP_CACHE_BYTES);
 
 	INIT_LIST_HEAD(&new->list);
 	new->index = n;
diff --git a/arch/um/drivers/vector_kern.c b/arch/um/drivers/vector_kern.c
index 64c09db392c1..85b129e2b70b 100644
--- a/arch/um/drivers/vector_kern.c
+++ b/arch/um/drivers/vector_kern.c
@@ -1694,10 +1694,7 @@ static int __init vector_setup(char *str)
 				 str, error);
 		return 1;
 	}
-	new = memblock_alloc(sizeof(*new), SMP_CACHE_BYTES);
-	if (!new)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*new));
+	new = memblock_alloc_or_panic(sizeof(*new), SMP_CACHE_BYTES);
 	INIT_LIST_HEAD(&new->list);
 	new->unit = n;
 	new->arguments = str;
diff --git a/arch/um/kernel/load_file.c b/arch/um/kernel/load_file.c
index 5cecd0e291fb..cb9d178ab7d8 100644
--- a/arch/um/kernel/load_file.c
+++ b/arch/um/kernel/load_file.c
@@ -48,9 +48,7 @@ void *uml_load_file(const char *filename, unsigned long long *size)
 		return NULL;
 	}
 
-	area = memblock_alloc(*size, SMP_CACHE_BYTES);
-	if (!area)
-		panic("%s: Failed to allocate %llu bytes\n", __func__, *size);
+	area = memblock_alloc_or_panic(*size, SMP_CACHE_BYTES);
 
 	if (__uml_load_file(filename, area, *size)) {
 		memblock_free(area, *size);
diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index 499b41953e3c..fa218270c1db 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -1567,9 +1567,7 @@ static void __init alloc_runtime_data(int cpu)
 		struct svsm_ca *caa;
 
 		/* Allocate the SVSM CA page if an SVSM is present */
-		caa = memblock_alloc(sizeof(*caa), PAGE_SIZE);
-		if (!caa)
-			panic("Can't allocate SVSM CA page\n");
+		caa = memblock_alloc_or_panic(sizeof(*caa), PAGE_SIZE);
 
 		per_cpu(svsm_caa, cpu) = caa;
 		per_cpu(svsm_caa_pa, cpu) = __pa(caa);
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 3a44a9dc3fb7..7c15d6e83c37 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -911,11 +911,8 @@ static int __init acpi_parse_hpet(struct acpi_table_header *table)
 	 * the resource tree during the lateinit timeframe.
 	 */
 #define HPET_RESOURCE_NAME_SIZE 9
-	hpet_res = memblock_alloc(sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE,
+	hpet_res = memblock_alloc_or_panic(sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE,
 				  SMP_CACHE_BYTES);
-	if (!hpet_res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE);
 
 	hpet_res->name = (void *)&hpet_res[1];
 	hpet_res->flags = IORESOURCE_MEM;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 1029ea4ac8ba..a57d3fa7c6b6 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2503,9 +2503,7 @@ static struct resource * __init ioapic_setup_resources(void)
 	n = IOAPIC_RESOURCE_NAME_SIZE + sizeof(struct resource);
 	n *= nr_ioapics;
 
-	mem = memblock_alloc(n, SMP_CACHE_BYTES);
-	if (!mem)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, n);
+	mem = memblock_alloc_or_panic(n, SMP_CACHE_BYTES);
 	res = (void *)mem;
 
 	mem += sizeof(struct resource) * nr_ioapics;
@@ -2564,11 +2562,8 @@ void __init io_apic_init_mappings(void)
 #ifdef CONFIG_X86_32
 fake_ioapic_page:
 #endif
-			ioapic_phys = (unsigned long)memblock_alloc(PAGE_SIZE,
+			ioapic_phys = (unsigned long)memblock_alloc_or_panic(PAGE_SIZE,
 								    PAGE_SIZE);
-			if (!ioapic_phys)
-				panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-				      __func__, PAGE_SIZE, PAGE_SIZE);
 			ioapic_phys = __pa(ioapic_phys);
 		}
 		io_apic_set_fixmap(idx, ioapic_phys);
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 4893d30ce438..82b96ed9890a 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1146,11 +1146,8 @@ void __init e820__reserve_resources(void)
 	struct resource *res;
 	u64 end;
 
-	res = memblock_alloc(sizeof(*res) * e820_table->nr_entries,
+	res = memblock_alloc_or_panic(sizeof(*res) * e820_table->nr_entries,
 			     SMP_CACHE_BYTES);
-	if (!res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*res) * e820_table->nr_entries);
 	e820_res = res;
 
 	for (i = 0; i < e820_table->nr_entries; i++) {
diff --git a/arch/x86/platform/olpc/olpc_dt.c b/arch/x86/platform/olpc/olpc_dt.c
index 74ebd6882690..cf5dca2dbb91 100644
--- a/arch/x86/platform/olpc/olpc_dt.c
+++ b/arch/x86/platform/olpc/olpc_dt.c
@@ -136,11 +136,7 @@ void * __init prom_early_alloc(unsigned long size)
 		 * fast enough on the platforms we care about while minimizing
 		 * wasted bootmem) and hand off chunks of it to callers.
 		 */
-		res = memblock_alloc(chunk_size, SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      chunk_size);
-		BUG_ON(!res);
+		res = memblock_alloc_or_panic(chunk_size, SMP_CACHE_BYTES);
 		prom_early_allocated += chunk_size;
 		memset(res, 0, chunk_size);
 		free_mem = chunk_size;
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index b52d3e17e2c1..56914e21e303 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -178,13 +178,7 @@ static void p2m_init_identity(unsigned long *p2m, unsigned long pfn)
 static void * __ref alloc_p2m_page(void)
 {
 	if (unlikely(!slab_is_available())) {
-		void *ptr = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-
-		if (!ptr)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
-
-		return ptr;
+		return memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	}
 
 	return (void *)__get_free_page(GFP_KERNEL);
diff --git a/arch/xtensa/mm/kasan_init.c b/arch/xtensa/mm/kasan_init.c
index f00d122aa806..f39c4d83173a 100644
--- a/arch/xtensa/mm/kasan_init.c
+++ b/arch/xtensa/mm/kasan_init.c
@@ -39,11 +39,7 @@ static void __init populate(void *start, void *end)
 	unsigned long i, j;
 	unsigned long vaddr = (unsigned long)start;
 	pmd_t *pmd = pmd_off_k(vaddr);
-	pte_t *pte = memblock_alloc(n_pages * sizeof(pte_t), PAGE_SIZE);
-
-	if (!pte)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, n_pages * sizeof(pte_t), PAGE_SIZE);
+	pte_t *pte = memblock_alloc_or_panic(n_pages * sizeof(pte_t), PAGE_SIZE);
 
 	pr_debug("%s: %p - %p\n", __func__, start, end);
 
diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
index f2117fef7c7d..9c75dcc9a534 100644
--- a/drivers/clk/ti/clk.c
+++ b/drivers/clk/ti/clk.c
@@ -449,10 +449,7 @@ void __init omap2_clk_legacy_provider_init(int index, void __iomem *mem)
 {
 	struct clk_iomap *io;
 
-	io = memblock_alloc(sizeof(*io), SMP_CACHE_BYTES);
-	if (!io)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*io));
+	io = memblock_alloc_or_panic(sizeof(*io), SMP_CACHE_BYTES);
 
 	io->mem = mem;
 
diff --git a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
index a01bc5090cdf..a1534cc6c641 100644
--- a/drivers/macintosh/smu.c
+++ b/drivers/macintosh/smu.c
@@ -492,11 +492,7 @@ int __init smu_init (void)
 		goto fail_np;
 	}
 
-	smu = memblock_alloc(sizeof(struct smu_device), SMP_CACHE_BYTES);
-	if (!smu)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct smu_device));
-
+	smu = memblock_alloc_or_panic(sizeof(struct smu_device), SMP_CACHE_BYTES);
 	spin_lock_init(&smu->lock);
 	INIT_LIST_HEAD(&smu->cmd_list);
 	INIT_LIST_HEAD(&smu->cmd_i2c_list);
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 4b1e9f101ce3..809135e2c7f5 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1126,13 +1126,7 @@ void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
 
 static void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
 {
-	void *ptr = memblock_alloc(size, align);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %llu bytes align=0x%llx\n",
-		      __func__, size, align);
-
-	return ptr;
+	return memblock_alloc_or_panic(size, align);
 }
 
 bool __init early_init_dt_verify(void *dt_virt, phys_addr_t dt_phys)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index e50570629dc0..837eafa81636 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -3675,13 +3675,7 @@ static struct device_node *overlay_base_root;
 
 static void * __init dt_alloc_memory(u64 size, u64 align)
 {
-	void *ptr = memblock_alloc(size, align);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %llu bytes align=0x%llx\n",
-		      __func__, size, align);
-
-	return ptr;
+	return memblock_alloc_or_panic(size, align);
 }
 
 /*
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 673d5cae7c81..73af7ca3fa1c 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -417,6 +417,12 @@ static __always_inline void *memblock_alloc(phys_addr_t size, phys_addr_t align)
 				      MEMBLOCK_ALLOC_ACCESSIBLE, NUMA_NO_NODE);
 }
 
+void *__memblock_alloc_or_panic(phys_addr_t size, phys_addr_t align,
+				       const char *func);
+
+#define memblock_alloc_or_panic(size, align)    \
+	 __memblock_alloc_or_panic(size, align, __func__)
+
 static inline void *memblock_alloc_raw(phys_addr_t size,
 					       phys_addr_t align)
 {
diff --git a/init/main.c b/init/main.c
index 893cb77aef22..2a1757826397 100644
--- a/init/main.c
+++ b/init/main.c
@@ -640,15 +640,11 @@ static void __init setup_command_line(char *command_line)
 
 	len = xlen + strlen(boot_command_line) + ilen + 1;
 
-	saved_command_line = memblock_alloc(len, SMP_CACHE_BYTES);
-	if (!saved_command_line)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, len);
+	saved_command_line = memblock_alloc_or_panic(len, SMP_CACHE_BYTES);
 
 	len = xlen + strlen(command_line) + 1;
 
-	static_command_line = memblock_alloc(len, SMP_CACHE_BYTES);
-	if (!static_command_line)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, len);
+	static_command_line = memblock_alloc_or_panic(len, SMP_CACHE_BYTES);
 
 	if (xlen) {
 		/*
@@ -1146,16 +1142,10 @@ static int __init initcall_blacklist(char *str)
 		str_entry = strsep(&str, ",");
 		if (str_entry) {
 			pr_debug("blacklisting initcall %s\n", str_entry);
-			entry = memblock_alloc(sizeof(*entry),
+			entry = memblock_alloc_or_panic(sizeof(*entry),
 					       SMP_CACHE_BYTES);
-			if (!entry)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, sizeof(*entry));
-			entry->buf = memblock_alloc(strlen(str_entry) + 1,
+			entry->buf = memblock_alloc_or_panic(strlen(str_entry) + 1,
 						    SMP_CACHE_BYTES);
-			if (!entry->buf)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, strlen(str_entry) + 1);
 			strcpy(entry->buf, str_entry);
 			list_add(&entry->next, &blacklisted_initcalls);
 		}
diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
index 30894d8f0a78..c9fb559a6399 100644
--- a/kernel/power/snapshot.c
+++ b/kernel/power/snapshot.c
@@ -1011,11 +1011,8 @@ void __init register_nosave_region(unsigned long start_pfn, unsigned long end_pf
 		}
 	}
 	/* This allocation cannot fail */
-	region = memblock_alloc(sizeof(struct nosave_region),
+	region = memblock_alloc_or_panic(sizeof(struct nosave_region),
 				SMP_CACHE_BYTES);
-	if (!region)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct nosave_region));
 	region->start_pfn = start_pfn;
 	region->end_pfn = end_pfn;
 	list_add_tail(®ion->list, &nosave_regions);
diff --git a/lib/cpumask.c b/lib/cpumask.c
index e77ee9d46f71..57274ba8b6d9 100644
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@ -83,10 +83,7 @@ EXPORT_SYMBOL(alloc_cpumask_var_node);
  */
 void __init alloc_bootmem_cpumask_var(cpumask_var_t *mask)
 {
-	*mask = memblock_alloc(cpumask_size(), SMP_CACHE_BYTES);
-	if (!*mask)
-		panic("%s: Failed to allocate %u bytes\n", __func__,
-		      cpumask_size());
+	*mask = memblock_alloc_or_panic(cpumask_size(), SMP_CACHE_BYTES);
 }
 
 /**
diff --git a/mm/kmsan/shadow.c b/mm/kmsan/shadow.c
index 9c58f081d84f..1bb505a08415 100644
--- a/mm/kmsan/shadow.c
+++ b/mm/kmsan/shadow.c
@@ -280,12 +280,8 @@ void __init kmsan_init_alloc_meta_for_range(void *start, void *end)
 
 	start = (void *)PAGE_ALIGN_DOWN((u64)start);
 	size = PAGE_ALIGN((u64)end - (u64)start);
-	shadow = memblock_alloc(size, PAGE_SIZE);
-	origin = memblock_alloc(size, PAGE_SIZE);
-
-	if (!shadow || !origin)
-		panic("%s: Failed to allocate metadata memory for early boot range of size %llu",
-		      __func__, size);
+	shadow = memblock_alloc_or_panic(size, PAGE_SIZE);
+	origin = memblock_alloc_or_panic(size, PAGE_SIZE);
 
 	for (u64 addr = 0; addr < size; addr += PAGE_SIZE) {
 		page = virt_to_page_or_null((char *)start + addr);
diff --git a/mm/memblock.c b/mm/memblock.c
index 095c18b5c430..95af35fd1389 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1691,6 +1691,26 @@ void * __init memblock_alloc_try_nid(
 	return ptr;
 }
 
+/**
+ * __memblock_alloc_or_panic - Try to allocate memory and panic on failure
+ * @size: size of memory block to be allocated in bytes
+ * @align: alignment of the region and block's size
+ * @func: caller func name
+ *
+ * This function attempts to allocate memory using memblock_alloc,
+ * and in case of failure, it calls panic with the formatted message.
+ * This function should not be used directly, please use the macro memblock_alloc_or_panic.
+ */
+void *__init __memblock_alloc_or_panic(phys_addr_t size, phys_addr_t align,
+				       const char *func)
+{
+	void *addr = memblock_alloc(size, align);
+
+	if (unlikely(!addr))
+		panic("%s: Failed to allocate %pap bytes\n", func, &size);
+	return addr;
+}
+
 /**
  * memblock_free_late - free pages directly to buddy allocator
  * @base: phys starting address of the  boot memory block
diff --git a/mm/numa.c b/mm/numa.c
index e2eec07707d1..f1787d7713a6 100644
--- a/mm/numa.c
+++ b/mm/numa.c
@@ -37,13 +37,7 @@ void __init alloc_node_data(int nid)
 void __init alloc_offline_node_data(int nid)
 {
 	pg_data_t *pgdat;
-
-	pgdat = memblock_alloc(sizeof(*pgdat), SMP_CACHE_BYTES);
-	if (!pgdat)
-		panic("Cannot allocate %zuB for node %d.\n",
-		      sizeof(*pgdat), nid);
-
-	node_data[nid] = pgdat;
+	node_data[nid] = memblock_alloc_or_panic(sizeof(*pgdat), SMP_CACHE_BYTES);
 }
 
 /* Stub functions: */
diff --git a/mm/percpu.c b/mm/percpu.c
index d8dd31a2e407..ac61e3fc5f15 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1359,10 +1359,7 @@ static struct pcpu_chunk * __init pcpu_alloc_first_chunk(unsigned long tmp_addr,
 	/* allocate chunk */
 	alloc_size = struct_size(chunk, populated,
 				 BITS_TO_LONGS(region_size >> PAGE_SHIFT));
-	chunk = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	INIT_LIST_HEAD(&chunk->list);
 
@@ -1374,24 +1371,14 @@ static struct pcpu_chunk * __init pcpu_alloc_first_chunk(unsigned long tmp_addr,
 	region_bits = pcpu_chunk_map_bits(chunk);
 
 	alloc_size = BITS_TO_LONGS(region_bits) * sizeof(chunk->alloc_map[0]);
-	chunk->alloc_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->alloc_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk->alloc_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size =
 		BITS_TO_LONGS(region_bits + 1) * sizeof(chunk->bound_map[0]);
-	chunk->bound_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->bound_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk->bound_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = pcpu_chunk_nr_blocks(chunk) * sizeof(chunk->md_blocks[0]);
-	chunk->md_blocks = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->md_blocks)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
-
+	chunk->md_blocks = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 #ifdef NEED_PCPUOBJ_EXT
 	/* first chunk is free to use */
 	chunk->obj_exts = NULL;
@@ -2595,28 +2582,16 @@ void __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
 
 	/* process group information and build config tables accordingly */
 	alloc_size = ai->nr_groups * sizeof(group_offsets[0]);
-	group_offsets = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!group_offsets)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	group_offsets = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = ai->nr_groups * sizeof(group_sizes[0]);
-	group_sizes = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!group_sizes)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	group_sizes = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = nr_cpu_ids * sizeof(unit_map[0]);
-	unit_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!unit_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	unit_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = nr_cpu_ids * sizeof(unit_off[0]);
-	unit_off = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!unit_off)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	unit_off = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	for (cpu = 0; cpu < nr_cpu_ids; cpu++)
 		unit_map[cpu] = UINT_MAX;
@@ -2685,12 +2660,9 @@ void __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
 	pcpu_free_slot = pcpu_sidelined_slot + 1;
 	pcpu_to_depopulate_slot = pcpu_free_slot + 1;
 	pcpu_nr_slots = pcpu_to_depopulate_slot + 1;
-	pcpu_chunk_lists = memblock_alloc(pcpu_nr_slots *
+	pcpu_chunk_lists = memblock_alloc_or_panic(pcpu_nr_slots *
 					  sizeof(pcpu_chunk_lists[0]),
 					  SMP_CACHE_BYTES);
-	if (!pcpu_chunk_lists)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      pcpu_nr_slots * sizeof(pcpu_chunk_lists[0]));
 
 	for (i = 0; i < pcpu_nr_slots; i++)
 		INIT_LIST_HEAD(&pcpu_chunk_lists[i]);
@@ -3155,25 +3127,19 @@ void __init __weak pcpu_populate_pte(unsigned long addr)
 	pmd_t *pmd;
 
 	if (pgd_none(*pgd)) {
-		p4d = memblock_alloc(P4D_TABLE_SIZE, P4D_TABLE_SIZE);
-		if (!p4d)
-			goto err_alloc;
+		p4d = memblock_alloc_or_panic(P4D_TABLE_SIZE, P4D_TABLE_SIZE);
 		pgd_populate(&init_mm, pgd, p4d);
 	}
 
 	p4d = p4d_offset(pgd, addr);
 	if (p4d_none(*p4d)) {
-		pud = memblock_alloc(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
-		if (!pud)
-			goto err_alloc;
+		pud = memblock_alloc_or_panic(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
 		p4d_populate(&init_mm, p4d, pud);
 	}
 
 	pud = pud_offset(p4d, addr);
 	if (pud_none(*pud)) {
-		pmd = memblock_alloc(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
-		if (!pmd)
-			goto err_alloc;
+		pmd = memblock_alloc_or_panic(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 	}
 
@@ -3181,16 +3147,11 @@ void __init __weak pcpu_populate_pte(unsigned long addr)
 	if (!pmd_present(*pmd)) {
 		pte_t *new;
 
-		new = memblock_alloc(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
-		if (!new)
-			goto err_alloc;
+		new = memblock_alloc_or_panic(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, new);
 	}
 
 	return;
-
-err_alloc:
-	panic("%s: Failed to allocate memory\n", __func__);
 }
 
 /**
@@ -3237,10 +3198,7 @@ int __init pcpu_page_first_chunk(size_t reserved_size, pcpu_fc_cpu_to_node_fn_t
 	/* unaligned allocations can't be freed, round up to page size */
 	pages_size = PFN_ALIGN(unit_pages * num_possible_cpus() *
 			       sizeof(pages[0]));
-	pages = memblock_alloc(pages_size, SMP_CACHE_BYTES);
-	if (!pages)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      pages_size);
+	pages = memblock_alloc_or_panic(pages_size, SMP_CACHE_BYTES);
 
 	/* allocate pages */
 	j = 0;
diff --git a/mm/sparse.c b/mm/sparse.c
index 13b6624d3562..133b033d0cba 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -257,10 +257,7 @@ static void __init memblocks_present(void)
 
 		size = sizeof(struct mem_section *) * NR_SECTION_ROOTS;
 		align = 1 << (INTERNODE_CACHE_SHIFT);
-		mem_section = memblock_alloc(size, align);
-		if (!mem_section)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, size, align);
+		mem_section = memblock_alloc_or_panic(size, align);
 	}
 #endif
 
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Sun Dec 22 06:07:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Dec 2024 06:07:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862620.1274223 (Exim 4.92)
	(envelope-from )
	id 1tPF7b-0007Ym-0I; Sun, 22 Dec 2024 06:07:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862620.1274223; Sun, 22 Dec 2024 06:07: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 1tPF7a-0007Yf-SS; Sun, 22 Dec 2024 06:07:22 +0000
Received: by outflank-mailman (input) for mailman id 862620;
 Sun, 22 Dec 2024 06:07: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 1tPF7Z-0007YZ-U4
 for xen-devel@lists.xenproject.org; Sun, 22 Dec 2024 06:07:21 +0000
Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com
 [2607:f8b0:4864:20::1135])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 004fccef-c02b-11ef-99a3-01e77a169b0f;
 Sun, 22 Dec 2024 07:07:20 +0100 (CET)
Received: by mail-yw1-x1135.google.com with SMTP id
 00721157ae682-6ef66a7ac14so41123277b3.0
 for ; Sat, 21 Dec 2024 22:07: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: 004fccef-c02b-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734847639; x=1735452439; 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=htlpToW+3tDMXYk9LHSjN7kEjprwT0u1X/m/1Vl/oro=;
        b=IJX6seMLInE+5Uvyg82o76ZvJrLkq62xh4QkPbgTONUiPl0wBdvsRXBRNlCsBbfPEi
         D+WAE9XfW9WczuRDgmspXv2B5WZO6cOVzjDLeDCQhGV6epTxEVYibMnCdvcJ4rkYXr/N
         uuk+PPF/JioiyceP9q/T25fwuHOpSnG1yA99LBH6BihKxv56zQjA7aFUo5XrjaN/cCfn
         ZkzED/2zYEbnC726tfdIlnRUQEgEmdFuH0os4k0Z0OHxV/HC57GK/xLFGlUyCeiyZusX
         jbozbBDL+tpx9bh3balfZshiGCODksxR9DUBERYWMupJAnlB6xaiTL5bmr2C+wThvpBU
         PjRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734847639; x=1735452439;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=htlpToW+3tDMXYk9LHSjN7kEjprwT0u1X/m/1Vl/oro=;
        b=Nbq2xUk2MPuXlCn889tRVc2hEj3faIeW8EQssB52shxR9b84MEUIcWtkhfXzJ7f3Bu
         ouDJoJq/NbFHOuGu0gSQb1buDH+FSgTUw04swF3LG018yO9ITUuS4fllR+g8NyUpYc8v
         kKZ5uJkS12hz904Qg6eDoGlNJq4du34m2Li3pqV3y1Q0RCpf3b+sbB4g9lE+MT0mrtj+
         e78CH1X/0SQHW0xI/KBgYC5ZMjF/bBCY7i+4hKwDicXYTlYNGbyx+MY/+g/7eVTSfcv5
         cz0yP42YmqxotBkzP8iS5gh3GMdUq0pqrTapimPRSDdYTJOS4S0x+9yclhi14dmsjdSb
         QRrA==
X-Forwarded-Encrypted: i=1; AJvYcCVny3gIqnMA3owd7cBqMcIWQKr5D8RBOGTMHJR5Q09ITdP9tK675RQjbqZ9hsmPD+QeCf2J3vYKhpY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzVzIArkTiDEPuhpgZaYucY6gPiP1CJJG8eNS80fM8XstGqFfzo
	BsNIGSvY4eewdnsHeiTZ5Ab99nRwi5DjdeCMOMnJq1bk13IvTBXJw1/by7APqwuGJr8Fhfur8ev
	sqv1yO/N9oi7sLj3Akq7FdmnDxpw=
X-Gm-Gg: ASbGncsQQ5WLda7KGaYX1ReOPxrZL+a3oTYPDGEoJiIQvy18Yhche446S6tsEHrJ/m9
	/sju2EXJUPRZu0ZEQvJDKSpDqZuDWo9sMw4rgWtg=
X-Google-Smtp-Source: AGHT+IHTObibTWvFBx2RCqB+bk/1ZpT+xydtv33cOquvAas7ggMPQiaYSrqKqDsv5/UZU90VEPoAsSH6qDx1lw2KYn4=
X-Received: by 2002:a05:690c:6908:b0:664:74cd:5548 with SMTP id
 00721157ae682-6f3e2a65668mr105552167b3.1.1734847638651; Sat, 21 Dec 2024
 22:07:18 -0800 (PST)
MIME-Version: 1.0
References: <20241222054331.2705948-1-guoweikang.kernel@gmail.com> <02d042a6590ddb1fadb9f98d95de169c4683b9e7.camel@xry111.site>
In-Reply-To: <02d042a6590ddb1fadb9f98d95de169c4683b9e7.camel@xry111.site>
From: Weikang Guo 
Date: Sun, 22 Dec 2024 14:07:09 +0800
Message-ID: 
Subject: Re: [PATCH v6] mm/memblock: Add memblock_alloc_or_panic interface
To: Xi Ruoyao 
Cc: Andrew Morton , Mike Rapoport , 
	Geert Uytterhoeven , Dennis Zhou , Tejun Heo , 
	Christoph Lameter , Thomas Bogendoerfer , Sam Creasey , 
	Huacai Chen , Will Deacon , 
	Catalin Marinas , Oreoluwa Babatunde , 
	rafael.j.wysocki@intel.com, Palmer Dabbelt , 
	Hanjun Guo , Easwar Hariharan , 
	Johannes Berg , Ingo Molnar , 
	Dave Hansen , Christian Brauner , 
	KP Singh , Richard Henderson , 
	Matt Turner , Russell King , 
	WANG Xuerui , Michael Ellerman , 
	Stefan Kristiansson , Stafford Horne , 
	Helge Deller , Nicholas Piggin , 
	Christophe Leroy , Naveen N Rao , 
	Madhavan Srinivasan , Geoff Levand , 
	Paul Walmsley , Palmer Dabbelt , 
	Albert Ou , Andrey Ryabinin , 
	Alexander Potapenko , Andrey Konovalov , 
	Dmitry Vyukov , Vincenzo Frascino , 
	Heiko Carstens , Vasily Gorbik , 
	Alexander Gordeev , Christian Borntraeger , 
	Sven Schnelle , Yoshinori Sato , 
	Rich Felker , John Paul Adrian Glaubitz , 
	Andreas Larsson , Richard Weinberger , 
	Anton Ivanov , Johannes Berg , 
	Thomas Gleixner , Ingo Molnar , Borislav Petkov , 
	Dave Hansen , x86@kernel.org, linux-alpha@vger.kernel.org, 
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org, 
	linux-mips@vger.kernel.org, linux-openrisc@vger.kernel.org, 
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, 
	linux-riscv@lists.infradead.org, kasan-dev@googlegroups.com, 
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, 
	sparclinux@vger.kernel.org, linux-um@lists.infradead.org, 
	linux-acpi@vger.kernel.org, xen-devel@lists.xenproject.org, 
	linux-omap@vger.kernel.org, linux-clk@vger.kernel.org, 
	devicetree@vger.kernel.org, linux-mm@kvack.org, linux-pm@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"

Xi Ruoyao  wrote on Sunday, 22 December 2024 13:51:
>
> On Sun, 2024-12-22 at 13:43 +0800, Guo Weikang wrote:
> > Before SLUB initialization, various subsystems used memblock_alloc to
> > allocate memory. In most cases, when memory allocation fails, an immediate
> > panic is required. To simplify this behavior and reduce repetitive checks,
> > introduce `memblock_alloc_or_panic`. This function ensures that memory
> > allocation failures result in a panic automatically, improving code
> > readability and consistency across subsystems that require this behavior.
> >
> > Signed-off-by: Guo Weikang 
> > ---
>
>
> Please try to avoid bumping the patch revision number so quickly.
>
you are right,  I'll pay more attention to this in the future.
> And if you must do it, you should embed a ChangeLog of your patch (below
> this "---" line) so people can know what has been changed.
>
The update was indeed due to my problem. CI prompted me that there
were some compilation warnings that needed to be dealt with, so this
update was to fix the CI warnings. Refer to this:
- https://lore.kernel.org/oe-kbuild-all/202412221259.JuGNAUCq-lkp@intel.com/

> --
> Xi Ruoyao 
> School of Aerospace Science and Technology, Xidian University


From xen-devel-bounces@lists.xenproject.org Sun Dec 22 10:07:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Dec 2024 10:07:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862648.1274233 (Exim 4.92)
	(envelope-from )
	id 1tPIrX-0003Wq-5y; Sun, 22 Dec 2024 10:07:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862648.1274233; Sun, 22 Dec 2024 10:07: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 1tPIrX-0003Wh-1H; Sun, 22 Dec 2024 10:07:03 +0000
Received: by outflank-mailman (input) for mailman id 862648;
 Sun, 22 Dec 2024 10:07: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 1tPIrW-0003Wb-7X
 for xen-devel@lists.xenproject.org; Sun, 22 Dec 2024 10:07:02 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7bb255c3-c04c-11ef-a0da-8be0dac302b0;
 Sun, 22 Dec 2024 11:07:00 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id 018E35C4689;
 Sun, 22 Dec 2024 10:06:16 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7832C4CECD;
 Sun, 22 Dec 2024 10:06:32 +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: 7bb255c3-c04c-11ef-a0da-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1734862017;
	bh=sHCtg4von/olng1R4HlYChWVtzpfTivVlSvduFQtli4=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=s3+eZLw2H4fsTfYy7R26AMbxlUMiT45Y42thwzbQ7PzYcjCMV+xxnbiGc5SjcS8ee
	 N/pq6zKrdaTkA0THA/ohfrCjL8qwibt1MJ2o6NoUYUPkl8EkNQJF5tSH+SY+J1fE/8
	 Cvqm19I8xARPjWukujUbLNF0kg/VQ2JYfhr7BGGUm+m05r04yTqUEGCkxSjPDtezqD
	 tVCjBp4QZY5na1pptfRr8OCkrj7c6+qsi21cr2LJfacf2iXQzPcBvoG6AX6jq7P+Mk
	 T1nS6fK7nO7+rovxDAahs2X2IJBNreAhQtCCLuO9qzEwhrWBjbRlWnWXYxS/hWfdIV
	 u6Jyj1v1mllWg==
Date: Sun, 22 Dec 2024 12:06:22 +0200
From: Mike Rapoport 
To: Guo Weikang 
Cc: Andrew Morton ,
	Geert Uytterhoeven ,
	Dennis Zhou , Tejun Heo ,
	Christoph Lameter ,
	Thomas Bogendoerfer ,
	Sam Creasey , Huacai Chen ,
	Will Deacon ,
	Catalin Marinas ,
	Oreoluwa Babatunde ,
	rafael.j.wysocki@intel.com, Palmer Dabbelt ,
	Hanjun Guo ,
	Easwar Hariharan ,
	Johannes Berg ,
	Ingo Molnar , Dave Hansen ,
	Christian Brauner ,
	KP Singh ,
	Richard Henderson ,
	Matt Turner ,
	Russell King ,
	WANG Xuerui ,
	Michael Ellerman ,
	Stefan Kristiansson ,
	Stafford Horne , Helge Deller ,
	Nicholas Piggin ,
	Christophe Leroy ,
	Naveen N Rao ,
	Madhavan Srinivasan ,
	Geoff Levand ,
	Paul Walmsley ,
	Palmer Dabbelt ,
	Albert Ou ,
	Andrey Ryabinin ,
	Alexander Potapenko ,
	Andrey Konovalov ,
	Dmitry Vyukov ,
	Vincenzo Frascino ,
	Heiko Carstens ,
	Vasily Gorbik ,
	Alexander Gordeev ,
	Christian Borntraeger ,
	Sven Schnelle ,
	Yoshinori Sato ,
	Rich Felker ,
	John Paul Adrian Glaubitz ,
	Andreas Larsson ,
	Richard Weinberger ,
	Anton Ivanov ,
	Johannes Berg ,
	Thomas Gleixner ,
	Ingo Molnar , Borislav Petkov ,
	Dave Hansen , x86@kernel.org,
	linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
	linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
	linux-openrisc@vger.kernel.org, linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
	kasan-dev@googlegroups.com, linux-s390@vger.kernel.org,
	linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
	linux-um@lists.infradead.org, linux-acpi@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-omap@vger.kernel.org,
	linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
	linux-mm@kvack.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH v6] mm/memblock: Add memblock_alloc_or_panic interface
Message-ID: 
References: <20241222054331.2705948-1-guoweikang.kernel@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20241222054331.2705948-1-guoweikang.kernel@gmail.com>

On Sun, Dec 22, 2024 at 01:43:31PM +0800, Guo Weikang wrote:
> Before SLUB initialization, various subsystems used memblock_alloc to
> allocate memory. In most cases, when memory allocation fails, an immediate
> panic is required. To simplify this behavior and reduce repetitive checks,
> introduce `memblock_alloc_or_panic`. This function ensures that memory
> allocation failures result in a panic automatically, improving code
> readability and consistency across subsystems that require this behavior.
> 
> Signed-off-by: Guo Weikang 
> ---

...

> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 673d5cae7c81..73af7ca3fa1c 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -417,6 +417,12 @@ static __always_inline void *memblock_alloc(phys_addr_t size, phys_addr_t align)
>  				      MEMBLOCK_ALLOC_ACCESSIBLE, NUMA_NO_NODE);
>  }
>  
> +void *__memblock_alloc_or_panic(phys_addr_t size, phys_addr_t align,
> +				       const char *func);

Please align this line with the first parameter to the function.
Other than that

Acked-by: Mike Rapoport (Microsoft) 

> +
> +#define memblock_alloc_or_panic(size, align)    \
> +	 __memblock_alloc_or_panic(size, align, __func__)
> +
>  static inline void *memblock_alloc_raw(phys_addr_t size,
>  					       phys_addr_t align)
>  {


-- 
Sincerely yours,
Mike.


From xen-devel-bounces@lists.xenproject.org Sun Dec 22 10:23:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Dec 2024 10:23:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862657.1274243 (Exim 4.92)
	(envelope-from )
	id 1tPJ7E-0006J2-DV; Sun, 22 Dec 2024 10:23:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862657.1274243; Sun, 22 Dec 2024 10:23:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tPJ7E-0006Iv-AV; Sun, 22 Dec 2024 10:23:16 +0000
Received: by outflank-mailman (input) for mailman id 862657;
 Sun, 22 Dec 2024 10:23: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 1tPJ7D-0006Ip-F0
 for xen-devel@lists.xenproject.org; Sun, 22 Dec 2024 10:23:15 +0000
Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com
 [2607:f8b0:4864:20::1134])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id bfe62f31-c04e-11ef-a0da-8be0dac302b0;
 Sun, 22 Dec 2024 11:23:13 +0100 (CET)
Received: by mail-yw1-x1134.google.com with SMTP id
 00721157ae682-6f26c517979so23703337b3.2
 for ; Sun, 22 Dec 2024 02:23: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: bfe62f31-c04e-11ef-a0da-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734862993; x=1735467793; 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=/ONVNbxYIwyadSLDvwLNaPGVW+13KFD/yyNlBVYXNzc=;
        b=HGdrE8tSfXC/y5/gluqpJqYPgO8hMU/Gvo+IvxcttcvlCv15j2p2N5mwVTvXXJ9Rs7
         Ag1pidQuMQAl2xC58pfQRoPszEA0Y715qG0dQGkQEYHcQqJuONtF/1Be9Z2wO2pw5S5O
         PZjFKWBH8if9P/QvmOyEze9afxzl8ruYkVgCafKTbiBIRWNmqmQmREqRpZOsx44WfPJW
         mBv8J6O1K6RKNTdva20kFa7c15XSjnPVrlxY6I9YioAVTyBgCMbT2mQqJyCs57GAvCPy
         3BWArlY2wcfbGtVx5BD+Z2yWeanzxWawSt0ySBZbSaKOcvvc7KGXg7DLPqZp/Jqbmycq
         ZPaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734862993; x=1735467793;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=/ONVNbxYIwyadSLDvwLNaPGVW+13KFD/yyNlBVYXNzc=;
        b=CgX61tiTVjHj3PZ3xaEEwhmAja36aH5sI+YgShUaFvNn5GotuddpvCLK9maeizU5GE
         ECSvBK8YBsCaxamsk2Zh8LNd3Z0EfMb5631YHKhRu+niZ+q3P59YUsWDxwF3blD8i3lV
         zd6jKhuuOJt1R2vKyDQKJXV6dvmaGYRVPgfiqy+JdfuLiqn2RW8g7zJY4sGg4aB6M/Dj
         mZcB0NA6fPS8+5ybZbED4alHW4DqVfnAwaHOPZavdK6KK16lvMTdBxJyQXB4oCvrsP9z
         thxtpx+TCuqglDQcDAsYNw5bdRGD9EOrQOZtZGRv3P2A1U48DD4WAqcPWK+Cl9x2hEZj
         stZA==
X-Forwarded-Encrypted: i=1; AJvYcCWyjB9PSt60Bl2HASV88p3s7zGjPXg2WbvydyHLvBQzwTuQ1eifjFS0x1QAOHxUYokYC9WbLnCWT8Y=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxqpcw8nSXbELjLAtDqBs4X/u5fFT9RvKWeug1GY52LVAGuttNM
	CCMb1aGvHlWcOyrkOukH0PB2kGCBNprtpjtPNiyTh/9sHMULpeGv1kOXa0Ih9PiIGO7S71vEk2R
	7huxGOBnV29wuwZ+wF5eHaTYQsh8=
X-Gm-Gg: ASbGncv2cJH0f9KT2sn7JDvbttOjm9ZGdsiHv5bi5jaeIQxvGnnUUghEBBxSEc3NH6X
	TcZDyFKSWup1LThfB+BiqSqrTAL8Vy4iaFo1XfFY=
X-Google-Smtp-Source: AGHT+IHX0mjmsoNFu7Nk/P1ylkLtsHAmn22nfKbaHPnh1Btm1p2RULi24EAOG9MYK2JmawFo9lS/pEKQIPK2LOk3TLc=
X-Received: by 2002:a05:690c:360c:b0:6f2:9704:405c with SMTP id
 00721157ae682-6f3f8125edfmr74773997b3.15.1734862992817; Sun, 22 Dec 2024
 02:23:12 -0800 (PST)
MIME-Version: 1.0
References: <20241222054331.2705948-1-guoweikang.kernel@gmail.com> 
In-Reply-To: 
From: Weikang Guo 
Date: Sun, 22 Dec 2024 18:23:02 +0800
Message-ID: 
Subject: Re: [PATCH v6] mm/memblock: Add memblock_alloc_or_panic interface
To: Mike Rapoport 
Cc: Andrew Morton , Geert Uytterhoeven , 
	Dennis Zhou , Tejun Heo , Christoph Lameter , 
	Thomas Bogendoerfer , Sam Creasey , 
	Huacai Chen , Will Deacon , 
	Catalin Marinas , Oreoluwa Babatunde , 
	rafael.j.wysocki@intel.com, Palmer Dabbelt , 
	Hanjun Guo , Easwar Hariharan , 
	Johannes Berg , Ingo Molnar , 
	Dave Hansen , Christian Brauner , 
	KP Singh , Richard Henderson , 
	Matt Turner , Russell King , 
	WANG Xuerui , Michael Ellerman , 
	Stefan Kristiansson , Stafford Horne , 
	Helge Deller , Nicholas Piggin , 
	Christophe Leroy , Naveen N Rao , 
	Madhavan Srinivasan , Geoff Levand , 
	Paul Walmsley , Palmer Dabbelt , 
	Albert Ou , Andrey Ryabinin , 
	Alexander Potapenko , Andrey Konovalov , 
	Dmitry Vyukov , Vincenzo Frascino , 
	Heiko Carstens , Vasily Gorbik , 
	Alexander Gordeev , Christian Borntraeger , 
	Sven Schnelle , Yoshinori Sato , 
	Rich Felker , John Paul Adrian Glaubitz , 
	Andreas Larsson , Richard Weinberger , 
	Anton Ivanov , Johannes Berg , 
	Thomas Gleixner , Ingo Molnar , Borislav Petkov , 
	Dave Hansen , x86@kernel.org, linux-alpha@vger.kernel.org, 
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org, 
	linux-mips@vger.kernel.org, linux-openrisc@vger.kernel.org, 
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, 
	linux-riscv@lists.infradead.org, kasan-dev@googlegroups.com, 
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, 
	sparclinux@vger.kernel.org, linux-um@lists.infradead.org, 
	linux-acpi@vger.kernel.org, xen-devel@lists.xenproject.org, 
	linux-omap@vger.kernel.org, linux-clk@vger.kernel.org, 
	devicetree@vger.kernel.org, linux-mm@kvack.org, linux-pm@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"

Mike Rapoport  wrote on Sunday, 22 December 2024 18:06
>
> On Sun, Dec 22, 2024 at 01:43:31PM +0800, Guo Weikang wrote:
> > Before SLUB initialization, various subsystems used memblock_alloc to
> > allocate memory. In most cases, when memory allocation fails, an immediate
> > panic is required. To simplify this behavior and reduce repetitive checks,
> > introduce `memblock_alloc_or_panic`. This function ensures that memory
> > allocation failures result in a panic automatically, improving code
> > readability and consistency across subsystems that require this behavior.
> >
> > Signed-off-by: Guo Weikang 
> > ---
>
> ...
>
> > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > index 673d5cae7c81..73af7ca3fa1c 100644
> > --- a/include/linux/memblock.h
> > +++ b/include/linux/memblock.h
> > @@ -417,6 +417,12 @@ static __always_inline void *memblock_alloc(phys_addr_t size, phys_addr_t align)
> >                                     MEMBLOCK_ALLOC_ACCESSIBLE, NUMA_NO_NODE);
> >  }
> >
> > +void *__memblock_alloc_or_panic(phys_addr_t size, phys_addr_t align,
> > +                                    const char *func);
>
> Please align this line with the first parameter to the function.
> Other than that
>
> Acked-by: Mike Rapoport (Microsoft) 
>

Got it!  Thanks for the feedback!

> > +
> > +#define memblock_alloc_or_panic(size, align)    \
> > +      __memblock_alloc_or_panic(size, align, __func__)
> > +
> >  static inline void *memblock_alloc_raw(phys_addr_t size,
> >                                              phys_addr_t align)
> >  {
>
>
> --
> Sincerely yours,
> Mike.

Best regards.
Guo


From xen-devel-bounces@lists.xenproject.org Sun Dec 22 10:37:53 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Dec 2024 10:37:53 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862667.1274253 (Exim 4.92)
	(envelope-from )
	id 1tPJLH-00089C-Jd; Sun, 22 Dec 2024 10:37:47 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862667.1274253; Sun, 22 Dec 2024 10: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 1tPJLH-000895-H0; Sun, 22 Dec 2024 10:37:47 +0000
Received: by outflank-mailman (input) for mailman id 862667;
 Sun, 22 Dec 2024 10:37: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 1tPJLG-00088x-Ef
 for xen-devel@lists.xenproject.org; Sun, 22 Dec 2024 10:37:46 +0000
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com
 [2a00:1450:4864:20::22d])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c7815c04-c050-11ef-a0da-8be0dac302b0;
 Sun, 22 Dec 2024 11:37:44 +0100 (CET)
Received: by mail-lj1-x22d.google.com with SMTP id
 38308e7fff4ca-30225b2586cso46633801fa.0
 for ; Sun, 22 Dec 2024 02:37: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: c7815c04-c050-11ef-a0da-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734863865; x=1735468665; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=uAf4XYF+BN/cynPMUouPVnj1TJkDYFatX5sPirx1ssQ=;
        b=ApGwbnsDFe3PFltAqXa6RoJK+tGI1iUFNlixZxVMShaVftxnXh5PXgh23iybWIvCl9
         WnpEPqt+ttGzWZmXYaV2fd36ctnmoW8XY8/AWC+I0p/h/0XgW9d5yPfBVzKKhxKZQzeq
         C7v6Mc4zbRFDiHsLquQ+a1hiynfnSlXZGuVNnZldxj6nUB00sLRKn4nlSIleA7v6RyEe
         mQnh1EKx7G6yemm9X8MNETS6k4BLPEd3dVKechAmd8gTYCBo1LZ7crNaCRSQTl7rYTPM
         uTjZ6g/BOXHU1qRfvc0+BIFLheYKc3CZ7nNo1sTxa8ZIVeesECPD4zHqPS945aYERO2u
         nUIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734863865; x=1735468665;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=uAf4XYF+BN/cynPMUouPVnj1TJkDYFatX5sPirx1ssQ=;
        b=OlE6v8eqcGdzkOKIOdi1XAdRLud+200kXf6gbWX5dPW3grjAVOZSSiQhjwbOUB6QUZ
         HFJ3CQkzeb1nRQZwUiwLhMrgy3kgBoKfHDO0NOvm4WM7GBuihr7YPIJfxIhHW6/orEGd
         kVXqu0jxglAGjFkU+ade17ebz08QgzDE1JwGkmJXrYEQp3zvwweVuHccApdJedfdxQWq
         lK54r1cJRYlnlFdMnIX3jM+LE91Ci2IDl4c5BsYgewpyrV8hGG+x3AfC0+fxglF42cSN
         2J9zs32MYSTaAs9aeV5YgQoMF7QVFY7YVoJmNLuUhZfuOIoeHQWpXNvvWuCfnunTfZb/
         voWQ==
X-Forwarded-Encrypted: i=1; AJvYcCUx+ZN3VaHpRA2O8ACzZh0nPNCY8SKf25tTVwMozUqu5NNsx+v3/D1k7laWW8BJVzGUkiysON2EUUQ=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzYXQik/31+6UGf4WQIoYdXK/mNOeXQusuThsQ6FfP2Wf93flOI
	qXlJd/BTPCsvhR7wrzh3Oyg1RY6xRnKfRedRRzjhbfgQA4KoRoxorp+0yYHEqrvloyyK9RGGvq9
	liLdZWfZsKA6mm6429TwQ2ZaIo3g=
X-Gm-Gg: ASbGnctCEmL7uyW8ajh3x3cE2Pj0DFbJWaFebecs1aB364I6rBD3/Bkg0vJYw8MnpnJ
	XJHUWPZx+GVxPakyJASh8HvOiWV2Ft7RUiGELB1K4dR/7Lc76QzkdbzrphVNtwSyDUReF
X-Google-Smtp-Source: AGHT+IGJ4XnG6hPJJ83WUCPU4UF5z2bmt9KoMQ+xXAQfdQtvpcUiv3Qt3tZqeiwj1hLIlyJ3fx6mjYGevzp0orcU4bE=
X-Received: by 2002:a05:6512:3510:b0:542:2952:8848 with SMTP id
 2adb3069b0e04-54229529bb5mr1819462e87.3.1734863864768; Sun, 22 Dec 2024
 02:37:44 -0800 (PST)
MIME-Version: 1.0
References: 
 <099d3a80-4fdb-49a7-9fd0-207d7386551f@citrix.com> 
 
 <90640a5d-ff17-4555-adc6-ae9e21e24ebd@citrix.com> 
 <43166e29-ff2d-4a9d-8c1b-41b5e247974b@citrix.com> 
  <698f48a0-b674-4d7f-9c47-f1f8bf86379e@citrix.com>
In-Reply-To: <698f48a0-b674-4d7f-9c47-f1f8bf86379e@citrix.com>
Reply-To: sedat.dilek@gmail.com
From: Sedat Dilek 
Date: Sun, 22 Dec 2024 11:37:08 +0100
Message-ID: 
Subject: Re: [Linux-6.12.y] XEN: CVE-2024-53241 / XSA-466 and Clang-kCFI
To: Andrew Cooper 
Cc: Juergen Gross , Peter Zijlstra , 
	Sami Tolvanen , Jan Beulich , 
	Josh Poimboeuf , Linus Torvalds , 
	Greg Kroah-Hartman , Sasha Levin , 
	linux-kernel@vger.kernel.org, stable@vger.kernel.org, 
	Kees Cook , Nathan Chancellor , llvm@lists.linux.dev, 
	xen-devel 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 21, 2024 at 10:31=E2=80=AFPM Andrew Cooper
 wrote:
>
> On 21/12/2024 6:25 pm, Sedat Dilek wrote:
> > With...
> >
> > dileks@iniza:~/src/xtf/git$ mv tests/xsa-454 ../
> > dileks@iniza:~/src/xtf/git$ mv tests/xsa-consoleio-write ../
>
> That's completely bizzare.   There's nothing interestingly different
> with those two tests vs the others.
>
> I take it the crash is repeatable when using either of these?
>
> ~Andrew

This time I stopped SDDM and thus KDE-6/Wayland session.

Tested with Debian's officially 6.12.6-amd64 kernel in VT-3.

test-hvm32pae-xsa-consoleio-write SUCCESS <--- 1st time I tried, never
said this is not OK

test-hvm64-xsa-454 leads to FROZEN system and DATA LOSS (here: ext4).
Reproducibly as told many times.- in Debian and selfmade kernels version 6.=
12.6.

Stolen from the picture I took with my smartphone:

sudo ./xft-runner test-hvm64-xsa-454

Executing 'xl create -p tests/xsa-454/test-hvm64-xsa-454.cfg'
Executing 'xl console test-hvm64-xsa-454'
Executing 'xl unpause test-hvm64-xsa-454'

^^ System does NOT react!

I can send you the picture on request.

-Sedat-


From xen-devel-bounces@lists.xenproject.org Sun Dec 22 11:16:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Dec 2024 11:16:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862679.1274263 (Exim 4.92)
	(envelope-from )
	id 1tPJwM-0005a0-C9; Sun, 22 Dec 2024 11:16:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862679.1274263; Sun, 22 Dec 2024 11:16:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tPJwM-0005Zt-93; Sun, 22 Dec 2024 11:16:06 +0000
Received: by outflank-mailman (input) for mailman id 862679;
 Sun, 22 Dec 2024 11:16: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 1tPJwK-0005ZX-NJ
 for xen-devel@lists.xenproject.org; Sun, 22 Dec 2024 11:16:05 +0000
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com
 [2607:f8b0:4864:20::434])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1fdcbeba-c056-11ef-a0da-8be0dac302b0;
 Sun, 22 Dec 2024 12:16:01 +0100 (CET)
Received: by mail-pf1-x434.google.com with SMTP id
 d2e1a72fcca58-725ed193c9eso2900457b3a.1
 for ; Sun, 22 Dec 2024 03:16:01 -0800 (PST)
Received: from localhost.localdomain ([36.110.106.149])
 by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-842e25951c2sm5511753a12.71.2024.12.22.03.15.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 22 Dec 2024 03:15: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: 1fdcbeba-c056-11ef-a0da-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734866160; x=1735470960; 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=SeC6bQQxdK8aBJy4uBC70oPQwV/BtqL8fR6Vi5GDB30=;
        b=AYoF6T5Y8YjcGSEXx2vtikgF6JG17Tmf64nWkHt5LZFM/Jvn/tsezvWq1NP1hPoXy/
         ttCNzQ+2vsKIlrmgCdL6gVqWi0PXJxj9kqNn51tgZUNBaHTTPoFzQo9PiiXEWmap7Vgr
         8laqDLzto9vhCAL1e3vDVlX3Y7OkjKLLNK0fRltVDRDJirzW0nqv63oh8JTgumvvgrOL
         YvDbs2uhyXmCCKxb0oFrjUuRs7XVFmLvCsIjwvZXRe94NgHWB9rOxC9Xsqn9Ty6Lft0f
         vHicF5WM+VcgT7lexqq/kQQDpivGWhYpSg2ErZXt4EYDpGV+++7uQ5LeL98Hw2e6A5qX
         7GCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734866160; x=1735470960;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=SeC6bQQxdK8aBJy4uBC70oPQwV/BtqL8fR6Vi5GDB30=;
        b=N8qMglQYFSJxDy+tA+if3WTC4qwiX1CASuxxGi4GSvSFAJzddf6hQExf1MwFE2/lup
         nTEIx3YIwmYmGib8OFhhVgvrdaj5xYi735St0r6CHckXtnaB5z9iUEJWyo4hNHP2GKqR
         GQua3yTbs80Oz257MxVjUe5o4BeWjDyRP1Sh7kgGtOtCjlNANnMX+F++R502mwKWKAsa
         IZZEuhh467UryhMrAjjfLiXCxO3YQRHH9o8zcZIoiKFrdW9YPbzhjF69CayZcdj6CUf8
         sz+f1mupsM48e952qMfbbw417WdcJAQBPH3qM3wLdXX0F8cOqIWU8IjQ6BZ1QZty3uF9
         apdA==
X-Forwarded-Encrypted: i=1; AJvYcCWxqZ+zW/RM1Bsc236u11n0iV3dnt+9ilovi+1dzHbILIJqWaPielauCc5e9X/3A4BgNAdrAgPLBX4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwAa2txyi7aRn3BngSj0efStQWVgy1vj+fvKbXStANyzemovvCH
	CInvD8G2I7+czWVpERFw4kpWFjSzjh6//a2C/rdrU7Okr2MtDqbv
X-Gm-Gg: ASbGnctnoy6GC3BqyG1j5rZ9gmxRfaL/jGnr9y5qzNxnznuNvUp6bQa7ZGvzx+VS3Ob
	bJzP9E8k8HS0clMbTGtI0yXHYm+P2rM8djsAa8Ie7Uil5PeFrBOrZIwMPQvnuT1Ocv2qBl4+0pO
	WtteGGVRSuKesrDYqU72hK/pNiFbaqweWJP1NTMvpbqYVkvlOdO2TxiUHQYtryPy1Vk2e1H+HPT
	d/YLJIAAcV5oGgCccKbV2ynXQznHg8H1UNFFIqOBHV2L51XpSmSUxGH+5BxUeb6S3KqkREMyV9D
	7QzX
X-Google-Smtp-Source: AGHT+IHI/JMvlwrl0da0Ame6E1ZTyFkE5zonGKdIKc6/0G+/W4In6zlqr2lpYt4G5359RcnaBBobmQ==
X-Received: by 2002:a05:6a20:a127:b0:1e1:aa24:2e56 with SMTP id adf61e73a8af0-1e5e07ffd4bmr16632897637.30.1734866159305;
        Sun, 22 Dec 2024 03:15:59 -0800 (PST)
From: Guo Weikang 
To: Andrew Morton ,
	Mike Rapoport ,
	Geert Uytterhoeven ,
	Guo Weikang 
Cc: Dennis Zhou ,
	Tejun Heo ,
	Christoph Lameter ,
	Thomas Bogendoerfer ,
	Sam Creasey ,
	Huacai Chen ,
	Will Deacon ,
	Catalin Marinas ,
	Oreoluwa Babatunde ,
	rafael.j.wysocki@intel.com,
	Palmer Dabbelt ,
	Hanjun Guo ,
	Easwar Hariharan ,
	Johannes Berg ,
	Ingo Molnar ,
	Dave Hansen ,
	Christian Brauner ,
	KP Singh ,
	Richard Henderson ,
	Matt Turner ,
	Russell King ,
	WANG Xuerui ,
	Michael Ellerman ,
	Stefan Kristiansson ,
	Stafford Horne ,
	Helge Deller ,
	Nicholas Piggin ,
	Christophe Leroy ,
	Naveen N Rao ,
	Madhavan Srinivasan ,
	Geoff Levand ,
	Paul Walmsley ,
	Palmer Dabbelt ,
	Albert Ou ,
	Andrey Ryabinin ,
	Alexander Potapenko ,
	Andrey Konovalov ,
	Dmitry Vyukov ,
	Vincenzo Frascino ,
	Heiko Carstens ,
	Vasily Gorbik ,
	Alexander Gordeev ,
	Christian Borntraeger ,
	Sven Schnelle ,
	Yoshinori Sato ,
	Rich Felker ,
	John Paul Adrian Glaubitz ,
	Andreas Larsson ,
	Richard Weinberger ,
	Anton Ivanov ,
	Johannes Berg ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Borislav Petkov ,
	Dave Hansen ,
	x86@kernel.org,
	linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	loongarch@lists.linux.dev,
	linux-m68k@lists.linux-m68k.org,
	linux-mips@vger.kernel.org,
	linux-openrisc@vger.kernel.org,
	linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org,
	kasan-dev@googlegroups.com,
	linux-s390@vger.kernel.org,
	linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org,
	linux-um@lists.infradead.org,
	linux-acpi@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-omap@vger.kernel.org,
	linux-clk@vger.kernel.org,
	devicetree@vger.kernel.org,
	linux-mm@kvack.org,
	linux-pm@vger.kernel.org,
	Xi Ruoyao 
Subject: [PATCH v7] mm/memblock: Add memblock_alloc_or_panic interface
Date: Sun, 22 Dec 2024 19:15:37 +0800
Message-Id: <20241222111537.2720303-1-guoweikang.kernel@gmail.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Before SLUB initialization, various subsystems used memblock_alloc to
allocate memory. In most cases, when memory allocation fails, an immediate
panic is required. To simplify this behavior and reduce repetitive checks,
introduce `memblock_alloc_or_panic`. This function ensures that memory
allocation failures result in a panic automatically, improving code
readability and consistency across subsystems that require this behavior.

Changelog:
----------
v1: initial version
v2: add __memblock_alloc_or_panic support panic output caller
v3: panic output phys_addr_t use printk's %pap
v4: make __memblock_alloc_or_panic out-of-line, move to memblock.c
v6: Fix CI compile error
Links to CI: https://lore.kernel.org/oe-kbuild-all/202412221000.r1NzXJUO-lkp@intel.com/
v6: Fix CI compile warinigs
Links to CI: https://lore.kernel.org/oe-kbuild-all/202412221259.JuGNAUCq-lkp@intel.com/
v7: add chagelog and adjust function declaration alignment format
----------

Signed-off-by: Guo Weikang 
Reviewed-by: Andrew Morton 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Mike Rapoport (Microsoft) 
Acked-by: Xi Ruoyao 
---
 arch/alpha/kernel/core_cia.c            |  5 +-
 arch/alpha/kernel/core_marvel.c         | 10 +---
 arch/alpha/kernel/pci.c                 | 13 +----
 arch/alpha/kernel/pci_iommu.c           | 10 +---
 arch/arm/kernel/setup.c                 | 10 +---
 arch/arm/mm/mmu.c                       | 17 ++----
 arch/arm/mm/nommu.c                     |  5 +-
 arch/arm64/kernel/setup.c               |  4 +-
 arch/loongarch/kernel/setup.c           |  2 +-
 arch/loongarch/mm/init.c                | 13 ++---
 arch/m68k/mm/init.c                     |  5 +-
 arch/m68k/mm/mcfmmu.c                   | 10 +---
 arch/m68k/mm/motorola.c                 |  5 +-
 arch/m68k/mm/sun3mmu.c                  | 10 +---
 arch/m68k/sun3/sun3dvma.c               |  6 +--
 arch/mips/kernel/setup.c                |  5 +-
 arch/openrisc/mm/ioremap.c              |  5 +-
 arch/parisc/mm/init.c                   | 20 ++-----
 arch/powerpc/kernel/dt_cpu_ftrs.c       | 10 ++--
 arch/powerpc/kernel/pci_32.c            |  5 +-
 arch/powerpc/kernel/setup-common.c      |  5 +-
 arch/powerpc/kernel/setup_32.c          |  8 +--
 arch/powerpc/mm/book3s32/mmu.c          |  5 +-
 arch/powerpc/mm/book3s64/pgtable.c      |  6 +--
 arch/powerpc/mm/kasan/init_book3e_64.c  |  8 +--
 arch/powerpc/mm/kasan/init_book3s_64.c  |  2 +-
 arch/powerpc/mm/nohash/mmu_context.c    | 16 ++----
 arch/powerpc/mm/pgtable_32.c            |  7 +--
 arch/powerpc/platforms/powermac/nvram.c |  5 +-
 arch/powerpc/platforms/powernv/opal.c   |  5 +-
 arch/powerpc/platforms/ps3/setup.c      |  5 +-
 arch/powerpc/sysdev/msi_bitmap.c        |  5 +-
 arch/riscv/kernel/setup.c               |  4 +-
 arch/riscv/mm/kasan_init.c              | 14 ++---
 arch/s390/kernel/numa.c                 |  5 +-
 arch/s390/kernel/setup.c                | 20 ++-----
 arch/s390/kernel/smp.c                  |  9 ++--
 arch/s390/kernel/topology.c             | 10 +---
 arch/sh/mm/init.c                       | 10 +---
 arch/sparc/kernel/prom_32.c             |  4 +-
 arch/sparc/mm/srmmu.c                   | 14 ++---
 arch/um/drivers/net_kern.c              |  5 +-
 arch/um/drivers/vector_kern.c           |  5 +-
 arch/um/kernel/load_file.c              |  4 +-
 arch/x86/coco/sev/core.c                |  4 +-
 arch/x86/kernel/acpi/boot.c             |  5 +-
 arch/x86/kernel/apic/io_apic.c          |  9 +---
 arch/x86/kernel/e820.c                  |  5 +-
 arch/x86/platform/olpc/olpc_dt.c        |  6 +--
 arch/x86/xen/p2m.c                      |  8 +--
 arch/xtensa/mm/kasan_init.c             |  6 +--
 drivers/clk/ti/clk.c                    |  5 +-
 drivers/macintosh/smu.c                 |  6 +--
 drivers/of/fdt.c                        |  8 +--
 drivers/of/unittest.c                   |  8 +--
 include/linux/memblock.h                |  6 +++
 init/main.c                             | 18 ++-----
 kernel/power/snapshot.c                 |  5 +-
 lib/cpumask.c                           |  5 +-
 mm/kmsan/shadow.c                       |  8 +--
 mm/memblock.c                           | 20 +++++++
 mm/numa.c                               |  8 +--
 mm/percpu.c                             | 70 +++++--------------------
 mm/sparse.c                             |  5 +-
 64 files changed, 143 insertions(+), 423 deletions(-)

diff --git a/arch/alpha/kernel/core_cia.c b/arch/alpha/kernel/core_cia.c
index ca3d9c732b61..6e577228e175 100644
--- a/arch/alpha/kernel/core_cia.c
+++ b/arch/alpha/kernel/core_cia.c
@@ -331,10 +331,7 @@ cia_prepare_tbia_workaround(int window)
 	long i;
 
 	/* Use minimal 1K map. */
-	ppte = memblock_alloc(CIA_BROKEN_TBIA_SIZE, 32768);
-	if (!ppte)
-		panic("%s: Failed to allocate %u bytes align=0x%x\n",
-		      __func__, CIA_BROKEN_TBIA_SIZE, 32768);
+	ppte = memblock_alloc_or_panic(CIA_BROKEN_TBIA_SIZE, 32768);
 	pte = (virt_to_phys(ppte) >> (PAGE_SHIFT - 1)) | 1;
 
 	for (i = 0; i < CIA_BROKEN_TBIA_SIZE / sizeof(unsigned long); ++i)
diff --git a/arch/alpha/kernel/core_marvel.c b/arch/alpha/kernel/core_marvel.c
index b22248044bf0..b1bfbd11980d 100644
--- a/arch/alpha/kernel/core_marvel.c
+++ b/arch/alpha/kernel/core_marvel.c
@@ -81,10 +81,7 @@ mk_resource_name(int pe, int port, char *str)
 	char *name;
 	
 	sprintf(tmp, "PCI %s PE %d PORT %d", str, pe, port);
-	name = memblock_alloc(strlen(tmp) + 1, SMP_CACHE_BYTES);
-	if (!name)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      strlen(tmp) + 1);
+	name = memblock_alloc_or_panic(strlen(tmp) + 1, SMP_CACHE_BYTES);
 	strcpy(name, tmp);
 
 	return name;
@@ -119,10 +116,7 @@ alloc_io7(unsigned int pe)
 		return NULL;
 	}
 
-	io7 = memblock_alloc(sizeof(*io7), SMP_CACHE_BYTES);
-	if (!io7)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*io7));
+	io7 = memblock_alloc_or_panic(sizeof(*io7), SMP_CACHE_BYTES);
 	io7->pe = pe;
 	raw_spin_lock_init(&io7->irq_lock);
 
diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
index 4458eb7f44f0..8e9b4ac86b7e 100644
--- a/arch/alpha/kernel/pci.c
+++ b/arch/alpha/kernel/pci.c
@@ -391,10 +391,7 @@ alloc_pci_controller(void)
 {
 	struct pci_controller *hose;
 
-	hose = memblock_alloc(sizeof(*hose), SMP_CACHE_BYTES);
-	if (!hose)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*hose));
+	hose = memblock_alloc_or_panic(sizeof(*hose), SMP_CACHE_BYTES);
 
 	*hose_tail = hose;
 	hose_tail = &hose->next;
@@ -405,13 +402,7 @@ alloc_pci_controller(void)
 struct resource * __init
 alloc_resource(void)
 {
-	void *ptr = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct resource));
-
-	return ptr;
+	return memblock_alloc_or_panic(sizeof(struct resource), SMP_CACHE_BYTES);
 }
 
 
diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index 7fcf3e9b7103..681f56089d9c 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -71,14 +71,8 @@ iommu_arena_new_node(int nid, struct pci_controller *hose, dma_addr_t base,
 	if (align < mem_size)
 		align = mem_size;
 
-	arena = memblock_alloc(sizeof(*arena), SMP_CACHE_BYTES);
-	if (!arena)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*arena));
-	arena->ptes = memblock_alloc(mem_size, align);
-	if (!arena->ptes)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, mem_size, align);
+	arena = memblock_alloc_or_panic(sizeof(*arena), SMP_CACHE_BYTES);
+	arena->ptes = memblock_alloc_or_panic(mem_size, align);
 
 	spin_lock_init(&arena->lock);
 	arena->hose = hose;
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index e6a857bf0ce6..a41c93988d2c 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -880,10 +880,7 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 		 */
 		boot_alias_start = phys_to_idmap(start);
 		if (arm_has_idmap_alias() && boot_alias_start != IDMAP_INVALID_ADDR) {
-			res = memblock_alloc(sizeof(*res), SMP_CACHE_BYTES);
-			if (!res)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, sizeof(*res));
+			res = memblock_alloc_or_panic(sizeof(*res), SMP_CACHE_BYTES);
 			res->name = "System RAM (boot alias)";
 			res->start = boot_alias_start;
 			res->end = phys_to_idmap(res_end);
@@ -891,10 +888,7 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 			request_resource(&iomem_resource, res);
 		}
 
-		res = memblock_alloc(sizeof(*res), SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      sizeof(*res));
+		res = memblock_alloc_or_panic(sizeof(*res), SMP_CACHE_BYTES);
 		res->name  = "System RAM";
 		res->start = start;
 		res->end = res_end;
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index f5b7a16c5803..f02f872ea8a9 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -726,13 +726,8 @@ EXPORT_SYMBOL(phys_mem_access_prot);
 
 static void __init *early_alloc(unsigned long sz)
 {
-	void *ptr = memblock_alloc(sz, sz);
+	return memblock_alloc_or_panic(sz, sz);
 
-	if (!ptr)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, sz, sz);
-
-	return ptr;
 }
 
 static void *__init late_alloc(unsigned long sz)
@@ -1027,10 +1022,7 @@ void __init iotable_init(struct map_desc *io_desc, int nr)
 	if (!nr)
 		return;
 
-	svm = memblock_alloc(sizeof(*svm) * nr, __alignof__(*svm));
-	if (!svm)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, sizeof(*svm) * nr, __alignof__(*svm));
+	svm = memblock_alloc_or_panic(sizeof(*svm) * nr, __alignof__(*svm));
 
 	for (md = io_desc; nr; md++, nr--) {
 		create_mapping(md);
@@ -1052,10 +1044,7 @@ void __init vm_reserve_area_early(unsigned long addr, unsigned long size,
 	struct vm_struct *vm;
 	struct static_vm *svm;
 
-	svm = memblock_alloc(sizeof(*svm), __alignof__(*svm));
-	if (!svm)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, sizeof(*svm), __alignof__(*svm));
+	svm = memblock_alloc_or_panic(sizeof(*svm), __alignof__(*svm));
 
 	vm = &svm->vm;
 	vm->addr = (void *)addr;
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index c415f3859b20..1a8f6914ee59 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -162,10 +162,7 @@ void __init paging_init(const struct machine_desc *mdesc)
 	mpu_setup();
 
 	/* allocate the zero page. */
-	zero_page = (void *)memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	zero_page = (void *)memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	bootmem_init();
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 4f613e8e0745..85104587f849 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -223,9 +223,7 @@ static void __init request_standard_resources(void)
 
 	num_standard_resources = memblock.memory.cnt;
 	res_size = num_standard_resources * sizeof(*standard_resources);
-	standard_resources = memblock_alloc(res_size, SMP_CACHE_BYTES);
-	if (!standard_resources)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, res_size);
+	standard_resources = memblock_alloc_or_panic(res_size, SMP_CACHE_BYTES);
 
 	for_each_mem_region(region) {
 		res = &standard_resources[i++];
diff --git a/arch/loongarch/kernel/setup.c b/arch/loongarch/kernel/setup.c
index 56934fe58170..edcfdfcad7d2 100644
--- a/arch/loongarch/kernel/setup.c
+++ b/arch/loongarch/kernel/setup.c
@@ -431,7 +431,7 @@ static void __init resource_init(void)
 
 	num_standard_resources = memblock.memory.cnt;
 	res_size = num_standard_resources * sizeof(*standard_resources);
-	standard_resources = memblock_alloc(res_size, SMP_CACHE_BYTES);
+	standard_resources = memblock_alloc_or_panic(res_size, SMP_CACHE_BYTES);
 
 	for_each_mem_region(region) {
 		res = &standard_resources[i++];
diff --git a/arch/loongarch/mm/init.c b/arch/loongarch/mm/init.c
index 188b52bbb254..ca5aa5f46a9f 100644
--- a/arch/loongarch/mm/init.c
+++ b/arch/loongarch/mm/init.c
@@ -174,9 +174,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 	pmd_t *pmd;
 
 	if (p4d_none(p4dp_get(p4d))) {
-		pud = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pud)
-			panic("%s: Failed to allocate memory\n", __func__);
+		pud = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		p4d_populate(&init_mm, p4d, pud);
 #ifndef __PAGETABLE_PUD_FOLDED
 		pud_init(pud);
@@ -185,9 +183,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 
 	pud = pud_offset(p4d, addr);
 	if (pud_none(pudp_get(pud))) {
-		pmd = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pmd)
-			panic("%s: Failed to allocate memory\n", __func__);
+		pmd = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 #ifndef __PAGETABLE_PMD_FOLDED
 		pmd_init(pmd);
@@ -198,10 +194,7 @@ pte_t * __init populate_kernel_pte(unsigned long addr)
 	if (!pmd_present(pmdp_get(pmd))) {
 		pte_t *pte;
 
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate memory\n", __func__);
-
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, pte);
 		kernel_pte_init(pte);
 	}
diff --git a/arch/m68k/mm/init.c b/arch/m68k/mm/init.c
index 1b47bec15832..8b11d0d545aa 100644
--- a/arch/m68k/mm/init.c
+++ b/arch/m68k/mm/init.c
@@ -68,10 +68,7 @@ void __init paging_init(void)
 
 	high_memory = (void *) end_mem;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	max_zone_pfn[ZONE_DMA] = end_mem >> PAGE_SHIFT;
 	free_area_init(max_zone_pfn);
 }
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index 9a6fa342e872..19a75029036c 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -42,20 +42,14 @@ void __init paging_init(void)
 	unsigned long max_zone_pfn[MAX_NR_ZONES] = { 0 };
 	int i;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	pg_dir = swapper_pg_dir;
 	memset(swapper_pg_dir, 0, sizeof(swapper_pg_dir));
 
 	size = num_pages * sizeof(pte_t);
 	size = (size + PAGE_SIZE) & ~(PAGE_SIZE-1);
-	next_pgtable = (unsigned long) memblock_alloc(size, PAGE_SIZE);
-	if (!next_pgtable)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, PAGE_SIZE);
+	next_pgtable = (unsigned long) memblock_alloc_or_panic(size, PAGE_SIZE);
 
 	pg_dir += PAGE_OFFSET >> PGDIR_SHIFT;
 
diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
index c1761d309fc6..795dd1f2b24f 100644
--- a/arch/m68k/mm/motorola.c
+++ b/arch/m68k/mm/motorola.c
@@ -491,10 +491,7 @@ void __init paging_init(void)
 	 * initialize the bad page table and bad page to point
 	 * to a couple of allocated pages
 	 */
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	/*
 	 * Set up SFC/DFC registers
diff --git a/arch/m68k/mm/sun3mmu.c b/arch/m68k/mm/sun3mmu.c
index 494739c1783e..1ecf6bdd08bf 100644
--- a/arch/m68k/mm/sun3mmu.c
+++ b/arch/m68k/mm/sun3mmu.c
@@ -44,10 +44,7 @@ void __init paging_init(void)
 	unsigned long max_zone_pfn[MAX_NR_ZONES] = { 0, };
 	unsigned long size;
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 	address = PAGE_OFFSET;
 	pg_dir = swapper_pg_dir;
@@ -57,10 +54,7 @@ void __init paging_init(void)
 	size = num_pages * sizeof(pte_t);
 	size = (size + PAGE_SIZE) & ~(PAGE_SIZE-1);
 
-	next_pgtable = (unsigned long)memblock_alloc(size, PAGE_SIZE);
-	if (!next_pgtable)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, PAGE_SIZE);
+	next_pgtable = (unsigned long)memblock_alloc_or_panic(size, PAGE_SIZE);
 	bootmem_end = (next_pgtable + size + PAGE_SIZE) & PAGE_MASK;
 
 	/* Map whole memory from PAGE_OFFSET (0x0E000000) */
diff --git a/arch/m68k/sun3/sun3dvma.c b/arch/m68k/sun3/sun3dvma.c
index 6ebf52740ad7..225fc735e466 100644
--- a/arch/m68k/sun3/sun3dvma.c
+++ b/arch/m68k/sun3/sun3dvma.c
@@ -252,12 +252,8 @@ void __init dvma_init(void)
 
 	list_add(&(hole->list), &hole_list);
 
-	iommu_use = memblock_alloc(IOMMU_TOTAL_ENTRIES * sizeof(unsigned long),
+	iommu_use = memblock_alloc_or_panic(IOMMU_TOTAL_ENTRIES * sizeof(unsigned long),
 				   SMP_CACHE_BYTES);
-	if (!iommu_use)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      IOMMU_TOTAL_ENTRIES * sizeof(unsigned long));
-
 	dvma_unmap_iommu(DVMA_START, DVMA_SIZE);
 
 	sun3_dvma_init();
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 12a1a4ffb602..fbfe0771317e 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -704,10 +704,7 @@ static void __init resource_init(void)
 	for_each_mem_range(i, &start, &end) {
 		struct resource *res;
 
-		res = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      sizeof(struct resource));
+		res = memblock_alloc_or_panic(sizeof(struct resource), SMP_CACHE_BYTES);
 
 		res->start = start;
 		/*
diff --git a/arch/openrisc/mm/ioremap.c b/arch/openrisc/mm/ioremap.c
index f59ea4c10b0f..8e63e86251ca 100644
--- a/arch/openrisc/mm/ioremap.c
+++ b/arch/openrisc/mm/ioremap.c
@@ -38,10 +38,7 @@ pte_t __ref *pte_alloc_one_kernel(struct mm_struct *mm)
 	if (likely(mem_init_done)) {
 		pte = (pte_t *)get_zeroed_page(GFP_KERNEL);
 	} else {
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	}
 
 	return pte;
diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index 96970fa75e4a..61c0a2477072 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -377,10 +377,8 @@ static void __ref map_pages(unsigned long start_vaddr,
 
 #if CONFIG_PGTABLE_LEVELS == 3
 		if (pud_none(*pud)) {
-			pmd = memblock_alloc(PAGE_SIZE << PMD_TABLE_ORDER,
+			pmd = memblock_alloc_or_panic(PAGE_SIZE << PMD_TABLE_ORDER,
 					     PAGE_SIZE << PMD_TABLE_ORDER);
-			if (!pmd)
-				panic("pmd allocation failed.\n");
 			pud_populate(NULL, pud, pmd);
 		}
 #endif
@@ -388,9 +386,7 @@ static void __ref map_pages(unsigned long start_vaddr,
 		pmd = pmd_offset(pud, vaddr);
 		for (tmp1 = start_pmd; tmp1 < PTRS_PER_PMD; tmp1++, pmd++) {
 			if (pmd_none(*pmd)) {
-				pg_table = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-				if (!pg_table)
-					panic("page table allocation failed\n");
+				pg_table = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 				pmd_populate_kernel(NULL, pmd, pg_table);
 			}
 
@@ -648,9 +644,7 @@ static void __init pagetable_init(void)
 	}
 #endif
 
-	empty_zero_page = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!empty_zero_page)
-		panic("zero page allocation failed.\n");
+	empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 }
 
@@ -687,19 +681,15 @@ static void __init fixmap_init(void)
 
 #if CONFIG_PGTABLE_LEVELS == 3
 	if (pud_none(*pud)) {
-		pmd = memblock_alloc(PAGE_SIZE << PMD_TABLE_ORDER,
+		pmd = memblock_alloc_or_panic(PAGE_SIZE << PMD_TABLE_ORDER,
 				     PAGE_SIZE << PMD_TABLE_ORDER);
-		if (!pmd)
-			panic("fixmap: pmd allocation failed.\n");
 		pud_populate(NULL, pud, pmd);
 	}
 #endif
 
 	pmd = pmd_offset(pud, addr);
 	do {
-		pte_t *pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("fixmap: pte allocation failed.\n");
+		pte_t *pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 
 		pmd_populate_kernel(&init_mm, pmd, pte);
 
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 1bee15c013e7..3af6c06af02f 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -1087,12 +1087,10 @@ static int __init dt_cpu_ftrs_scan_callback(unsigned long node, const char
 	/* Count and allocate space for cpu features */
 	of_scan_flat_dt_subnodes(node, count_cpufeatures_subnodes,
 						&nr_dt_cpu_features);
-	dt_cpu_features = memblock_alloc(sizeof(struct dt_cpu_feature) * nr_dt_cpu_features, PAGE_SIZE);
-	if (!dt_cpu_features)
-		panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
-		      __func__,
-		      sizeof(struct dt_cpu_feature) * nr_dt_cpu_features,
-		      PAGE_SIZE);
+	dt_cpu_features =
+		memblock_alloc_or_panic(
+			sizeof(struct dt_cpu_feature) * nr_dt_cpu_features,
+			PAGE_SIZE);
 
 	cpufeatures_setup_start(isa);
 
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index ce0c8623e563..f8a3bd8cfae4 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -213,11 +213,8 @@ pci_create_OF_bus_map(void)
 	struct property* of_prop;
 	struct device_node *dn;
 
-	of_prop = memblock_alloc(sizeof(struct property) + 256,
+	of_prop = memblock_alloc_or_panic(sizeof(struct property) + 256,
 				 SMP_CACHE_BYTES);
-	if (!of_prop)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct property) + 256);
 	dn = of_find_node_by_path("/");
 	if (dn) {
 		memset(of_prop, -1, sizeof(struct property) + 256);
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 6fa179448c33..f3ea1329c566 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -458,11 +458,8 @@ void __init smp_setup_cpu_maps(void)
 
 	DBG("smp_setup_cpu_maps()\n");
 
-	cpu_to_phys_id = memblock_alloc(nr_cpu_ids * sizeof(u32),
+	cpu_to_phys_id = memblock_alloc_or_panic(nr_cpu_ids * sizeof(u32),
 					__alignof__(u32));
-	if (!cpu_to_phys_id)
-		panic("%s: Failed to allocate %zu bytes align=0x%zx\n",
-		      __func__, nr_cpu_ids * sizeof(u32), __alignof__(u32));
 
 	for_each_node_by_type(dn, "cpu") {
 		const __be32 *intserv;
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 75dbf3e0d9c4..5a1bf501fbe1 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -140,13 +140,7 @@ arch_initcall(ppc_init);
 
 static void *__init alloc_stack(void)
 {
-	void *ptr = memblock_alloc(THREAD_SIZE, THREAD_ALIGN);
-
-	if (!ptr)
-		panic("cannot allocate %d bytes for stack at %pS\n",
-		      THREAD_SIZE, (void *)_RET_IP_);
-
-	return ptr;
+	return memblock_alloc_or_panic(THREAD_SIZE, THREAD_ALIGN);
 }
 
 void __init irqstack_early_init(void)
diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/mmu.c
index 6978344edcb4..be9c4106e22f 100644
--- a/arch/powerpc/mm/book3s32/mmu.c
+++ b/arch/powerpc/mm/book3s32/mmu.c
@@ -377,10 +377,7 @@ void __init MMU_init_hw(void)
 	 * Find some memory for the hash table.
 	 */
 	if ( ppc_md.progress ) ppc_md.progress("hash:find piece", 0x322);
-	Hash = memblock_alloc(Hash_size, Hash_size);
-	if (!Hash)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, Hash_size, Hash_size);
+	Hash = memblock_alloc_or_panic(Hash_size, Hash_size);
 	_SDR1 = __pa(Hash) | SDR1_LOW_BITS;
 
 	pr_info("Total memory = %lldMB; using %ldkB for hash table\n",
diff --git a/arch/powerpc/mm/book3s64/pgtable.c b/arch/powerpc/mm/book3s64/pgtable.c
index 374542528080..0b1f419b7404 100644
--- a/arch/powerpc/mm/book3s64/pgtable.c
+++ b/arch/powerpc/mm/book3s64/pgtable.c
@@ -330,11 +330,7 @@ void __init mmu_partition_table_init(void)
 	unsigned long ptcr;
 
 	/* Initialize the Partition Table with no entries */
-	partition_tb = memblock_alloc(patb_size, patb_size);
-	if (!partition_tb)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, patb_size, patb_size);
-
+	partition_tb = memblock_alloc_or_panic(patb_size, patb_size);
 	ptcr = __pa(partition_tb) | (PATB_SIZE_SHIFT - 12);
 	set_ptcr_when_no_uv(ptcr);
 	powernv_set_nmmu_ptcr(ptcr);
diff --git a/arch/powerpc/mm/kasan/init_book3e_64.c b/arch/powerpc/mm/kasan/init_book3e_64.c
index 43c03b84ff32..60c78aac0f63 100644
--- a/arch/powerpc/mm/kasan/init_book3e_64.c
+++ b/arch/powerpc/mm/kasan/init_book3e_64.c
@@ -40,19 +40,19 @@ static int __init kasan_map_kernel_page(unsigned long ea, unsigned long pa, pgpr
 	pgdp = pgd_offset_k(ea);
 	p4dp = p4d_offset(pgdp, ea);
 	if (kasan_pud_table(*p4dp)) {
-		pudp = memblock_alloc(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
+		pudp = memblock_alloc_or_panic(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
 		memcpy(pudp, kasan_early_shadow_pud, PUD_TABLE_SIZE);
 		p4d_populate(&init_mm, p4dp, pudp);
 	}
 	pudp = pud_offset(p4dp, ea);
 	if (kasan_pmd_table(*pudp)) {
-		pmdp = memblock_alloc(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
+		pmdp = memblock_alloc_or_panic(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
 		memcpy(pmdp, kasan_early_shadow_pmd, PMD_TABLE_SIZE);
 		pud_populate(&init_mm, pudp, pmdp);
 	}
 	pmdp = pmd_offset(pudp, ea);
 	if (kasan_pte_table(*pmdp)) {
-		ptep = memblock_alloc(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
+		ptep = memblock_alloc_or_panic(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
 		memcpy(ptep, kasan_early_shadow_pte, PTE_TABLE_SIZE);
 		pmd_populate_kernel(&init_mm, pmdp, ptep);
 	}
@@ -74,7 +74,7 @@ static void __init kasan_init_phys_region(void *start, void *end)
 	k_start = ALIGN_DOWN((unsigned long)kasan_mem_to_shadow(start), PAGE_SIZE);
 	k_end = ALIGN((unsigned long)kasan_mem_to_shadow(end), PAGE_SIZE);
 
-	va = memblock_alloc(k_end - k_start, PAGE_SIZE);
+	va = memblock_alloc_or_panic(k_end - k_start, PAGE_SIZE);
 	for (k_cur = k_start; k_cur < k_end; k_cur += PAGE_SIZE, va += PAGE_SIZE)
 		kasan_map_kernel_page(k_cur, __pa(va), PAGE_KERNEL);
 }
diff --git a/arch/powerpc/mm/kasan/init_book3s_64.c b/arch/powerpc/mm/kasan/init_book3s_64.c
index 3fb5ce4f48f4..7d959544c077 100644
--- a/arch/powerpc/mm/kasan/init_book3s_64.c
+++ b/arch/powerpc/mm/kasan/init_book3s_64.c
@@ -32,7 +32,7 @@ static void __init kasan_init_phys_region(void *start, void *end)
 	k_start = ALIGN_DOWN((unsigned long)kasan_mem_to_shadow(start), PAGE_SIZE);
 	k_end = ALIGN((unsigned long)kasan_mem_to_shadow(end), PAGE_SIZE);
 
-	va = memblock_alloc(k_end - k_start, PAGE_SIZE);
+	va = memblock_alloc_or_panic(k_end - k_start, PAGE_SIZE);
 	for (k_cur = k_start; k_cur < k_end; k_cur += PAGE_SIZE, va += PAGE_SIZE)
 		map_kernel_page(k_cur, __pa(va), PAGE_KERNEL);
 }
diff --git a/arch/powerpc/mm/nohash/mmu_context.c b/arch/powerpc/mm/nohash/mmu_context.c
index 0b181da40ddb..a1a4e697251a 100644
--- a/arch/powerpc/mm/nohash/mmu_context.c
+++ b/arch/powerpc/mm/nohash/mmu_context.c
@@ -385,21 +385,11 @@ void __init mmu_context_init(void)
 	/*
 	 * Allocate the maps used by context management
 	 */
-	context_map = memblock_alloc(CTX_MAP_SIZE, SMP_CACHE_BYTES);
-	if (!context_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      CTX_MAP_SIZE);
-	context_mm = memblock_alloc(sizeof(void *) * (LAST_CONTEXT + 1),
+	context_map = memblock_alloc_or_panic(CTX_MAP_SIZE, SMP_CACHE_BYTES);
+	context_mm = memblock_alloc_or_panic(sizeof(void *) * (LAST_CONTEXT + 1),
 				    SMP_CACHE_BYTES);
-	if (!context_mm)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(void *) * (LAST_CONTEXT + 1));
 	if (IS_ENABLED(CONFIG_SMP)) {
-		stale_map[boot_cpuid] = memblock_alloc(CTX_MAP_SIZE, SMP_CACHE_BYTES);
-		if (!stale_map[boot_cpuid])
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      CTX_MAP_SIZE);
-
+		stale_map[boot_cpuid] = memblock_alloc_or_panic(CTX_MAP_SIZE, SMP_CACHE_BYTES);
 		cpuhp_setup_state_nocalls(CPUHP_POWERPC_MMU_CTX_PREPARE,
 					  "powerpc/mmu/ctx:prepare",
 					  mmu_ctx_cpu_prepare, mmu_ctx_cpu_dead);
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 787b22206386..15276068f657 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -50,13 +50,8 @@ notrace void __init early_ioremap_init(void)
 
 void __init *early_alloc_pgtable(unsigned long size)
 {
-	void *ptr = memblock_alloc(size, size);
+	return memblock_alloc_or_panic(size, size);
 
-	if (!ptr)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, size, size);
-
-	return ptr;
 }
 
 pte_t __init *early_pte_alloc_kernel(pmd_t *pmdp, unsigned long va)
diff --git a/arch/powerpc/platforms/powermac/nvram.c b/arch/powerpc/platforms/powermac/nvram.c
index fe2e0249cbc2..a112d26185a0 100644
--- a/arch/powerpc/platforms/powermac/nvram.c
+++ b/arch/powerpc/platforms/powermac/nvram.c
@@ -514,10 +514,7 @@ static int __init core99_nvram_setup(struct device_node *dp, unsigned long addr)
 		printk(KERN_ERR "nvram: no address\n");
 		return -EINVAL;
 	}
-	nvram_image = memblock_alloc(NVRAM_SIZE, SMP_CACHE_BYTES);
-	if (!nvram_image)
-		panic("%s: Failed to allocate %u bytes\n", __func__,
-		      NVRAM_SIZE);
+	nvram_image = memblock_alloc_or_panic(NVRAM_SIZE, SMP_CACHE_BYTES);
 	nvram_data = ioremap(addr, NVRAM_SIZE*2);
 	nvram_naddrs = 1; /* Make sure we get the correct case */
 
diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
index 5d0f35bb917e..09bd93464b4f 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -180,10 +180,7 @@ int __init early_init_dt_scan_recoverable_ranges(unsigned long node,
 	/*
 	 * Allocate a buffer to hold the MC recoverable ranges.
 	 */
-	mc_recoverable_range = memblock_alloc(size, __alignof__(u64));
-	if (!mc_recoverable_range)
-		panic("%s: Failed to allocate %u bytes align=0x%lx\n",
-		      __func__, size, __alignof__(u64));
+	mc_recoverable_range = memblock_alloc_or_panic(size, __alignof__(u64));
 
 	for (i = 0; i < mc_recoverable_range_len; i++) {
 		mc_recoverable_range[i].start_addr =
diff --git a/arch/powerpc/platforms/ps3/setup.c b/arch/powerpc/platforms/ps3/setup.c
index 5144f11359f7..150c09b58ae8 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -115,10 +115,7 @@ static void __init prealloc(struct ps3_prealloc *p)
 	if (!p->size)
 		return;
 
-	p->address = memblock_alloc(p->size, p->align);
-	if (!p->address)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, p->size, p->align);
+	p->address = memblock_alloc_or_panic(p->size, p->align);
 
 	printk(KERN_INFO "%s: %lu bytes at %p\n", p->name, p->size,
 	       p->address);
diff --git a/arch/powerpc/sysdev/msi_bitmap.c b/arch/powerpc/sysdev/msi_bitmap.c
index 0b6e37f3ffb8..456a4f64ae0a 100644
--- a/arch/powerpc/sysdev/msi_bitmap.c
+++ b/arch/powerpc/sysdev/msi_bitmap.c
@@ -124,10 +124,7 @@ int __ref msi_bitmap_alloc(struct msi_bitmap *bmp, unsigned int irq_count,
 	if (bmp->bitmap_from_slab)
 		bmp->bitmap = kzalloc(size, GFP_KERNEL);
 	else {
-		bmp->bitmap = memblock_alloc(size, SMP_CACHE_BYTES);
-		if (!bmp->bitmap)
-			panic("%s: Failed to allocate %u bytes\n", __func__,
-			      size);
+		bmp->bitmap = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 		/* the bitmap won't be freed from memblock allocator */
 		kmemleak_not_leak(bmp->bitmap);
 	}
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 45010e71df86..f1793630fc51 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -147,9 +147,7 @@ static void __init init_resources(void)
 	res_idx = num_resources - 1;
 
 	mem_res_sz = num_resources * sizeof(*mem_res);
-	mem_res = memblock_alloc(mem_res_sz, SMP_CACHE_BYTES);
-	if (!mem_res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, mem_res_sz);
+	mem_res = memblock_alloc_or_panic(mem_res_sz, SMP_CACHE_BYTES);
 
 	/*
 	 * Start by adding the reserved regions, if they overlap
diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index c301c8d291d2..41c635d6aca4 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -32,7 +32,7 @@ static void __init kasan_populate_pte(pmd_t *pmd, unsigned long vaddr, unsigned
 	pte_t *ptep, *p;
 
 	if (pmd_none(pmdp_get(pmd))) {
-		p = memblock_alloc(PTRS_PER_PTE * sizeof(pte_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PTE * sizeof(pte_t), PAGE_SIZE);
 		set_pmd(pmd, pfn_pmd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -54,7 +54,7 @@ static void __init kasan_populate_pmd(pud_t *pud, unsigned long vaddr, unsigned
 	unsigned long next;
 
 	if (pud_none(pudp_get(pud))) {
-		p = memblock_alloc(PTRS_PER_PMD * sizeof(pmd_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PMD * sizeof(pmd_t), PAGE_SIZE);
 		set_pud(pud, pfn_pud(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -85,7 +85,7 @@ static void __init kasan_populate_pud(p4d_t *p4d,
 	unsigned long next;
 
 	if (p4d_none(p4dp_get(p4d))) {
-		p = memblock_alloc(PTRS_PER_PUD * sizeof(pud_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_PUD * sizeof(pud_t), PAGE_SIZE);
 		set_p4d(p4d, pfn_p4d(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -116,7 +116,7 @@ static void __init kasan_populate_p4d(pgd_t *pgd,
 	unsigned long next;
 
 	if (pgd_none(pgdp_get(pgd))) {
-		p = memblock_alloc(PTRS_PER_P4D * sizeof(p4d_t), PAGE_SIZE);
+		p = memblock_alloc_or_panic(PTRS_PER_P4D * sizeof(p4d_t), PAGE_SIZE);
 		set_pgd(pgd, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 	}
 
@@ -385,7 +385,7 @@ static void __init kasan_shallow_populate_pud(p4d_t *p4d,
 		next = pud_addr_end(vaddr, end);
 
 		if (pud_none(pudp_get(pud_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_pud(pud_k, pfn_pud(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
@@ -405,7 +405,7 @@ static void __init kasan_shallow_populate_p4d(pgd_t *pgd,
 		next = p4d_addr_end(vaddr, end);
 
 		if (p4d_none(p4dp_get(p4d_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_p4d(p4d_k, pfn_p4d(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
@@ -424,7 +424,7 @@ static void __init kasan_shallow_populate_pgd(unsigned long vaddr, unsigned long
 		next = pgd_addr_end(vaddr, end);
 
 		if (pgd_none(pgdp_get(pgd_k))) {
-			p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+			p = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 			set_pgd(pgd_k, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
 			continue;
 		}
diff --git a/arch/s390/kernel/numa.c b/arch/s390/kernel/numa.c
index ddc1448ea2e1..a33e20f73330 100644
--- a/arch/s390/kernel/numa.c
+++ b/arch/s390/kernel/numa.c
@@ -22,10 +22,7 @@ void __init numa_setup(void)
 	node_set(0, node_possible_map);
 	node_set_online(0);
 	for (nid = 0; nid < MAX_NUMNODES; nid++) {
-		NODE_DATA(nid) = memblock_alloc(sizeof(pg_data_t), 8);
-		if (!NODE_DATA(nid))
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(pg_data_t), 8);
+		NODE_DATA(nid) = memblock_alloc_or_panic(sizeof(pg_data_t), 8);
 	}
 	NODE_DATA(0)->node_spanned_pages = memblock_end_of_DRAM() >> PAGE_SHIFT;
 	NODE_DATA(0)->node_id = 0;
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index 0ce550faf073..1298f0860733 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -376,11 +376,7 @@ static unsigned long __init stack_alloc_early(void)
 {
 	unsigned long stack;
 
-	stack = (unsigned long)memblock_alloc(THREAD_SIZE, THREAD_SIZE);
-	if (!stack) {
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, THREAD_SIZE, THREAD_SIZE);
-	}
+	stack = (unsigned long)memblock_alloc_or_panic(THREAD_SIZE, THREAD_SIZE);
 	return stack;
 }
 
@@ -504,10 +500,7 @@ static void __init setup_resources(void)
 	bss_resource.end = __pa_symbol(__bss_stop) - 1;
 
 	for_each_mem_range(i, &start, &end) {
-		res = memblock_alloc(sizeof(*res), 8);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(*res), 8);
+		res = memblock_alloc_or_panic(sizeof(*res), 8);
 		res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
 
 		res->name = "System RAM";
@@ -526,10 +519,7 @@ static void __init setup_resources(void)
 			    std_res->start > res->end)
 				continue;
 			if (std_res->end > res->end) {
-				sub_res = memblock_alloc(sizeof(*sub_res), 8);
-				if (!sub_res)
-					panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-					      __func__, sizeof(*sub_res), 8);
+				sub_res = memblock_alloc_or_panic(sizeof(*sub_res), 8);
 				*sub_res = *std_res;
 				sub_res->end = res->end;
 				std_res->start = res->end + 1;
@@ -816,9 +806,7 @@ static void __init setup_randomness(void)
 {
 	struct sysinfo_3_2_2 *vmms;
 
-	vmms = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!vmms)
-		panic("Failed to allocate memory for sysinfo structure\n");
+	vmms = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	if (stsi(vmms, 3, 2, 2) == 0 && vmms->count)
 		add_device_randomness(&vmms->vm, sizeof(vmms->vm[0]) * vmms->count);
 	memblock_free(vmms, PAGE_SIZE);
diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
index 822d8e6f8717..d77aaefb59bd 100644
--- a/arch/s390/kernel/smp.c
+++ b/arch/s390/kernel/smp.c
@@ -611,9 +611,9 @@ void __init smp_save_dump_ipl_cpu(void)
 	if (!dump_available())
 		return;
 	sa = save_area_alloc(true);
-	regs = memblock_alloc(512, 8);
-	if (!sa || !regs)
+	if (!sa)
 		panic("could not allocate memory for boot CPU save area\n");
+	regs = memblock_alloc_or_panic(512, 8);
 	copy_oldmem_kernel(regs, __LC_FPREGS_SAVE_AREA, 512);
 	save_area_add_regs(sa, regs);
 	memblock_free(regs, 512);
@@ -792,10 +792,7 @@ void __init smp_detect_cpus(void)
 	u16 address;
 
 	/* Get CPU information */
-	info = memblock_alloc(sizeof(*info), 8);
-	if (!info)
-		panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-		      __func__, sizeof(*info), 8);
+	info = memblock_alloc_or_panic(sizeof(*info), 8);
 	smp_get_core_info(info, 1);
 	/* Find boot CPU type */
 	if (sclp.has_core_type) {
diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
index 0fd56a1cadbd..cf5ee6032c0b 100644
--- a/arch/s390/kernel/topology.c
+++ b/arch/s390/kernel/topology.c
@@ -548,10 +548,7 @@ static void __init alloc_masks(struct sysinfo_15_1_x *info,
 		nr_masks *= info->mag[TOPOLOGY_NR_MAG - offset - 1 - i];
 	nr_masks = max(nr_masks, 1);
 	for (i = 0; i < nr_masks; i++) {
-		mask->next = memblock_alloc(sizeof(*mask->next), 8);
-		if (!mask->next)
-			panic("%s: Failed to allocate %zu bytes align=0x%x\n",
-			      __func__, sizeof(*mask->next), 8);
+		mask->next = memblock_alloc_or_panic(sizeof(*mask->next), 8);
 		mask = mask->next;
 	}
 }
@@ -569,10 +566,7 @@ void __init topology_init_early(void)
 	}
 	if (!MACHINE_HAS_TOPOLOGY)
 		goto out;
-	tl_info = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-	if (!tl_info)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, PAGE_SIZE, PAGE_SIZE);
+	tl_info = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	info = tl_info;
 	store_topology(info);
 	pr_info("The CPU configuration topology of the machine is: %d %d %d %d %d %d / %d\n",
diff --git a/arch/sh/mm/init.c b/arch/sh/mm/init.c
index 2a88b0c9e70f..289a2fecebef 100644
--- a/arch/sh/mm/init.c
+++ b/arch/sh/mm/init.c
@@ -137,10 +137,7 @@ static pmd_t * __init one_md_table_init(pud_t *pud)
 	if (pud_none(*pud)) {
 		pmd_t *pmd;
 
-		pmd = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pmd)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pmd = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 		BUG_ON(pmd != pmd_offset(pud, 0));
 	}
@@ -153,10 +150,7 @@ static pte_t * __init one_page_table_init(pmd_t *pmd)
 	if (pmd_none(*pmd)) {
 		pte_t *pte;
 
-		pte = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-		if (!pte)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
+		pte = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, pte);
 		BUG_ON(pte != pte_offset_kernel(pmd, 0));
 	}
diff --git a/arch/sparc/kernel/prom_32.c b/arch/sparc/kernel/prom_32.c
index 3df960c137f7..a67dd67f10c8 100644
--- a/arch/sparc/kernel/prom_32.c
+++ b/arch/sparc/kernel/prom_32.c
@@ -28,9 +28,7 @@ void * __init prom_early_alloc(unsigned long size)
 {
 	void *ret;
 
-	ret = memblock_alloc(size, SMP_CACHE_BYTES);
-	if (!ret)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, size);
+	ret = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 
 	prom_early_allocated += size;
 
diff --git a/arch/sparc/mm/srmmu.c b/arch/sparc/mm/srmmu.c
index 9df51a62333d..e36c2a0ff748 100644
--- a/arch/sparc/mm/srmmu.c
+++ b/arch/sparc/mm/srmmu.c
@@ -277,19 +277,13 @@ static void __init srmmu_nocache_init(void)
 
 	bitmap_bits = srmmu_nocache_size >> SRMMU_NOCACHE_BITMAP_SHIFT;
 
-	srmmu_nocache_pool = memblock_alloc(srmmu_nocache_size,
+	srmmu_nocache_pool = memblock_alloc_or_panic(srmmu_nocache_size,
 					    SRMMU_NOCACHE_ALIGN_MAX);
-	if (!srmmu_nocache_pool)
-		panic("%s: Failed to allocate %lu bytes align=0x%x\n",
-		      __func__, srmmu_nocache_size, SRMMU_NOCACHE_ALIGN_MAX);
 	memset(srmmu_nocache_pool, 0, srmmu_nocache_size);
 
 	srmmu_nocache_bitmap =
-		memblock_alloc(BITS_TO_LONGS(bitmap_bits) * sizeof(long),
+		memblock_alloc_or_panic(BITS_TO_LONGS(bitmap_bits) * sizeof(long),
 			       SMP_CACHE_BYTES);
-	if (!srmmu_nocache_bitmap)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      BITS_TO_LONGS(bitmap_bits) * sizeof(long));
 	bit_map_init(&srmmu_nocache_map, srmmu_nocache_bitmap, bitmap_bits);
 
 	srmmu_swapper_pg_dir = __srmmu_get_nocache(SRMMU_PGD_TABLE_SIZE, SRMMU_PGD_TABLE_SIZE);
@@ -452,9 +446,7 @@ static void __init sparc_context_init(int numctx)
 	unsigned long size;
 
 	size = numctx * sizeof(struct ctx_list);
-	ctx_list_pool = memblock_alloc(size, SMP_CACHE_BYTES);
-	if (!ctx_list_pool)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, size);
+	ctx_list_pool = memblock_alloc_or_panic(size, SMP_CACHE_BYTES);
 
 	for (ctx = 0; ctx < numctx; ctx++) {
 		struct ctx_list *clist;
diff --git a/arch/um/drivers/net_kern.c b/arch/um/drivers/net_kern.c
index 75d04fb4994a..d5a9c5aabaec 100644
--- a/arch/um/drivers/net_kern.c
+++ b/arch/um/drivers/net_kern.c
@@ -636,10 +636,7 @@ static int __init eth_setup(char *str)
 		return 1;
 	}
 
-	new = memblock_alloc(sizeof(*new), SMP_CACHE_BYTES);
-	if (!new)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*new));
+	new = memblock_alloc_or_panic(sizeof(*new), SMP_CACHE_BYTES);
 
 	INIT_LIST_HEAD(&new->list);
 	new->index = n;
diff --git a/arch/um/drivers/vector_kern.c b/arch/um/drivers/vector_kern.c
index 64c09db392c1..85b129e2b70b 100644
--- a/arch/um/drivers/vector_kern.c
+++ b/arch/um/drivers/vector_kern.c
@@ -1694,10 +1694,7 @@ static int __init vector_setup(char *str)
 				 str, error);
 		return 1;
 	}
-	new = memblock_alloc(sizeof(*new), SMP_CACHE_BYTES);
-	if (!new)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*new));
+	new = memblock_alloc_or_panic(sizeof(*new), SMP_CACHE_BYTES);
 	INIT_LIST_HEAD(&new->list);
 	new->unit = n;
 	new->arguments = str;
diff --git a/arch/um/kernel/load_file.c b/arch/um/kernel/load_file.c
index 5cecd0e291fb..cb9d178ab7d8 100644
--- a/arch/um/kernel/load_file.c
+++ b/arch/um/kernel/load_file.c
@@ -48,9 +48,7 @@ void *uml_load_file(const char *filename, unsigned long long *size)
 		return NULL;
 	}
 
-	area = memblock_alloc(*size, SMP_CACHE_BYTES);
-	if (!area)
-		panic("%s: Failed to allocate %llu bytes\n", __func__, *size);
+	area = memblock_alloc_or_panic(*size, SMP_CACHE_BYTES);
 
 	if (__uml_load_file(filename, area, *size)) {
 		memblock_free(area, *size);
diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index 499b41953e3c..fa218270c1db 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -1567,9 +1567,7 @@ static void __init alloc_runtime_data(int cpu)
 		struct svsm_ca *caa;
 
 		/* Allocate the SVSM CA page if an SVSM is present */
-		caa = memblock_alloc(sizeof(*caa), PAGE_SIZE);
-		if (!caa)
-			panic("Can't allocate SVSM CA page\n");
+		caa = memblock_alloc_or_panic(sizeof(*caa), PAGE_SIZE);
 
 		per_cpu(svsm_caa, cpu) = caa;
 		per_cpu(svsm_caa_pa, cpu) = __pa(caa);
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 3a44a9dc3fb7..7c15d6e83c37 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -911,11 +911,8 @@ static int __init acpi_parse_hpet(struct acpi_table_header *table)
 	 * the resource tree during the lateinit timeframe.
 	 */
 #define HPET_RESOURCE_NAME_SIZE 9
-	hpet_res = memblock_alloc(sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE,
+	hpet_res = memblock_alloc_or_panic(sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE,
 				  SMP_CACHE_BYTES);
-	if (!hpet_res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*hpet_res) + HPET_RESOURCE_NAME_SIZE);
 
 	hpet_res->name = (void *)&hpet_res[1];
 	hpet_res->flags = IORESOURCE_MEM;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 1029ea4ac8ba..a57d3fa7c6b6 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2503,9 +2503,7 @@ static struct resource * __init ioapic_setup_resources(void)
 	n = IOAPIC_RESOURCE_NAME_SIZE + sizeof(struct resource);
 	n *= nr_ioapics;
 
-	mem = memblock_alloc(n, SMP_CACHE_BYTES);
-	if (!mem)
-		panic("%s: Failed to allocate %lu bytes\n", __func__, n);
+	mem = memblock_alloc_or_panic(n, SMP_CACHE_BYTES);
 	res = (void *)mem;
 
 	mem += sizeof(struct resource) * nr_ioapics;
@@ -2564,11 +2562,8 @@ void __init io_apic_init_mappings(void)
 #ifdef CONFIG_X86_32
 fake_ioapic_page:
 #endif
-			ioapic_phys = (unsigned long)memblock_alloc(PAGE_SIZE,
+			ioapic_phys = (unsigned long)memblock_alloc_or_panic(PAGE_SIZE,
 								    PAGE_SIZE);
-			if (!ioapic_phys)
-				panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-				      __func__, PAGE_SIZE, PAGE_SIZE);
 			ioapic_phys = __pa(ioapic_phys);
 		}
 		io_apic_set_fixmap(idx, ioapic_phys);
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 4893d30ce438..82b96ed9890a 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1146,11 +1146,8 @@ void __init e820__reserve_resources(void)
 	struct resource *res;
 	u64 end;
 
-	res = memblock_alloc(sizeof(*res) * e820_table->nr_entries,
+	res = memblock_alloc_or_panic(sizeof(*res) * e820_table->nr_entries,
 			     SMP_CACHE_BYTES);
-	if (!res)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*res) * e820_table->nr_entries);
 	e820_res = res;
 
 	for (i = 0; i < e820_table->nr_entries; i++) {
diff --git a/arch/x86/platform/olpc/olpc_dt.c b/arch/x86/platform/olpc/olpc_dt.c
index 74ebd6882690..cf5dca2dbb91 100644
--- a/arch/x86/platform/olpc/olpc_dt.c
+++ b/arch/x86/platform/olpc/olpc_dt.c
@@ -136,11 +136,7 @@ void * __init prom_early_alloc(unsigned long size)
 		 * fast enough on the platforms we care about while minimizing
 		 * wasted bootmem) and hand off chunks of it to callers.
 		 */
-		res = memblock_alloc(chunk_size, SMP_CACHE_BYTES);
-		if (!res)
-			panic("%s: Failed to allocate %zu bytes\n", __func__,
-			      chunk_size);
-		BUG_ON(!res);
+		res = memblock_alloc_or_panic(chunk_size, SMP_CACHE_BYTES);
 		prom_early_allocated += chunk_size;
 		memset(res, 0, chunk_size);
 		free_mem = chunk_size;
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index b52d3e17e2c1..56914e21e303 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -178,13 +178,7 @@ static void p2m_init_identity(unsigned long *p2m, unsigned long pfn)
 static void * __ref alloc_p2m_page(void)
 {
 	if (unlikely(!slab_is_available())) {
-		void *ptr = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
-
-		if (!ptr)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, PAGE_SIZE, PAGE_SIZE);
-
-		return ptr;
+		return memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
 	}
 
 	return (void *)__get_free_page(GFP_KERNEL);
diff --git a/arch/xtensa/mm/kasan_init.c b/arch/xtensa/mm/kasan_init.c
index f00d122aa806..f39c4d83173a 100644
--- a/arch/xtensa/mm/kasan_init.c
+++ b/arch/xtensa/mm/kasan_init.c
@@ -39,11 +39,7 @@ static void __init populate(void *start, void *end)
 	unsigned long i, j;
 	unsigned long vaddr = (unsigned long)start;
 	pmd_t *pmd = pmd_off_k(vaddr);
-	pte_t *pte = memblock_alloc(n_pages * sizeof(pte_t), PAGE_SIZE);
-
-	if (!pte)
-		panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-		      __func__, n_pages * sizeof(pte_t), PAGE_SIZE);
+	pte_t *pte = memblock_alloc_or_panic(n_pages * sizeof(pte_t), PAGE_SIZE);
 
 	pr_debug("%s: %p - %p\n", __func__, start, end);
 
diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
index f2117fef7c7d..9c75dcc9a534 100644
--- a/drivers/clk/ti/clk.c
+++ b/drivers/clk/ti/clk.c
@@ -449,10 +449,7 @@ void __init omap2_clk_legacy_provider_init(int index, void __iomem *mem)
 {
 	struct clk_iomap *io;
 
-	io = memblock_alloc(sizeof(*io), SMP_CACHE_BYTES);
-	if (!io)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(*io));
+	io = memblock_alloc_or_panic(sizeof(*io), SMP_CACHE_BYTES);
 
 	io->mem = mem;
 
diff --git a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
index a01bc5090cdf..a1534cc6c641 100644
--- a/drivers/macintosh/smu.c
+++ b/drivers/macintosh/smu.c
@@ -492,11 +492,7 @@ int __init smu_init (void)
 		goto fail_np;
 	}
 
-	smu = memblock_alloc(sizeof(struct smu_device), SMP_CACHE_BYTES);
-	if (!smu)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct smu_device));
-
+	smu = memblock_alloc_or_panic(sizeof(struct smu_device), SMP_CACHE_BYTES);
 	spin_lock_init(&smu->lock);
 	INIT_LIST_HEAD(&smu->cmd_list);
 	INIT_LIST_HEAD(&smu->cmd_i2c_list);
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 4b1e9f101ce3..809135e2c7f5 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1126,13 +1126,7 @@ void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
 
 static void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
 {
-	void *ptr = memblock_alloc(size, align);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %llu bytes align=0x%llx\n",
-		      __func__, size, align);
-
-	return ptr;
+	return memblock_alloc_or_panic(size, align);
 }
 
 bool __init early_init_dt_verify(void *dt_virt, phys_addr_t dt_phys)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index e50570629dc0..837eafa81636 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -3675,13 +3675,7 @@ static struct device_node *overlay_base_root;
 
 static void * __init dt_alloc_memory(u64 size, u64 align)
 {
-	void *ptr = memblock_alloc(size, align);
-
-	if (!ptr)
-		panic("%s: Failed to allocate %llu bytes align=0x%llx\n",
-		      __func__, size, align);
-
-	return ptr;
+	return memblock_alloc_or_panic(size, align);
 }
 
 /*
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 673d5cae7c81..dee628350cd1 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -417,6 +417,12 @@ static __always_inline void *memblock_alloc(phys_addr_t size, phys_addr_t align)
 				      MEMBLOCK_ALLOC_ACCESSIBLE, NUMA_NO_NODE);
 }
 
+void *__memblock_alloc_or_panic(phys_addr_t size, phys_addr_t align,
+				const char *func);
+
+#define memblock_alloc_or_panic(size, align)    \
+	 __memblock_alloc_or_panic(size, align, __func__)
+
 static inline void *memblock_alloc_raw(phys_addr_t size,
 					       phys_addr_t align)
 {
diff --git a/init/main.c b/init/main.c
index 893cb77aef22..2a1757826397 100644
--- a/init/main.c
+++ b/init/main.c
@@ -640,15 +640,11 @@ static void __init setup_command_line(char *command_line)
 
 	len = xlen + strlen(boot_command_line) + ilen + 1;
 
-	saved_command_line = memblock_alloc(len, SMP_CACHE_BYTES);
-	if (!saved_command_line)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, len);
+	saved_command_line = memblock_alloc_or_panic(len, SMP_CACHE_BYTES);
 
 	len = xlen + strlen(command_line) + 1;
 
-	static_command_line = memblock_alloc(len, SMP_CACHE_BYTES);
-	if (!static_command_line)
-		panic("%s: Failed to allocate %zu bytes\n", __func__, len);
+	static_command_line = memblock_alloc_or_panic(len, SMP_CACHE_BYTES);
 
 	if (xlen) {
 		/*
@@ -1146,16 +1142,10 @@ static int __init initcall_blacklist(char *str)
 		str_entry = strsep(&str, ",");
 		if (str_entry) {
 			pr_debug("blacklisting initcall %s\n", str_entry);
-			entry = memblock_alloc(sizeof(*entry),
+			entry = memblock_alloc_or_panic(sizeof(*entry),
 					       SMP_CACHE_BYTES);
-			if (!entry)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, sizeof(*entry));
-			entry->buf = memblock_alloc(strlen(str_entry) + 1,
+			entry->buf = memblock_alloc_or_panic(strlen(str_entry) + 1,
 						    SMP_CACHE_BYTES);
-			if (!entry->buf)
-				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, strlen(str_entry) + 1);
 			strcpy(entry->buf, str_entry);
 			list_add(&entry->next, &blacklisted_initcalls);
 		}
diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
index 30894d8f0a78..c9fb559a6399 100644
--- a/kernel/power/snapshot.c
+++ b/kernel/power/snapshot.c
@@ -1011,11 +1011,8 @@ void __init register_nosave_region(unsigned long start_pfn, unsigned long end_pf
 		}
 	}
 	/* This allocation cannot fail */
-	region = memblock_alloc(sizeof(struct nosave_region),
+	region = memblock_alloc_or_panic(sizeof(struct nosave_region),
 				SMP_CACHE_BYTES);
-	if (!region)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      sizeof(struct nosave_region));
 	region->start_pfn = start_pfn;
 	region->end_pfn = end_pfn;
 	list_add_tail(®ion->list, &nosave_regions);
diff --git a/lib/cpumask.c b/lib/cpumask.c
index e77ee9d46f71..57274ba8b6d9 100644
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@ -83,10 +83,7 @@ EXPORT_SYMBOL(alloc_cpumask_var_node);
  */
 void __init alloc_bootmem_cpumask_var(cpumask_var_t *mask)
 {
-	*mask = memblock_alloc(cpumask_size(), SMP_CACHE_BYTES);
-	if (!*mask)
-		panic("%s: Failed to allocate %u bytes\n", __func__,
-		      cpumask_size());
+	*mask = memblock_alloc_or_panic(cpumask_size(), SMP_CACHE_BYTES);
 }
 
 /**
diff --git a/mm/kmsan/shadow.c b/mm/kmsan/shadow.c
index 9c58f081d84f..1bb505a08415 100644
--- a/mm/kmsan/shadow.c
+++ b/mm/kmsan/shadow.c
@@ -280,12 +280,8 @@ void __init kmsan_init_alloc_meta_for_range(void *start, void *end)
 
 	start = (void *)PAGE_ALIGN_DOWN((u64)start);
 	size = PAGE_ALIGN((u64)end - (u64)start);
-	shadow = memblock_alloc(size, PAGE_SIZE);
-	origin = memblock_alloc(size, PAGE_SIZE);
-
-	if (!shadow || !origin)
-		panic("%s: Failed to allocate metadata memory for early boot range of size %llu",
-		      __func__, size);
+	shadow = memblock_alloc_or_panic(size, PAGE_SIZE);
+	origin = memblock_alloc_or_panic(size, PAGE_SIZE);
 
 	for (u64 addr = 0; addr < size; addr += PAGE_SIZE) {
 		page = virt_to_page_or_null((char *)start + addr);
diff --git a/mm/memblock.c b/mm/memblock.c
index 095c18b5c430..95af35fd1389 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1691,6 +1691,26 @@ void * __init memblock_alloc_try_nid(
 	return ptr;
 }
 
+/**
+ * __memblock_alloc_or_panic - Try to allocate memory and panic on failure
+ * @size: size of memory block to be allocated in bytes
+ * @align: alignment of the region and block's size
+ * @func: caller func name
+ *
+ * This function attempts to allocate memory using memblock_alloc,
+ * and in case of failure, it calls panic with the formatted message.
+ * This function should not be used directly, please use the macro memblock_alloc_or_panic.
+ */
+void *__init __memblock_alloc_or_panic(phys_addr_t size, phys_addr_t align,
+				       const char *func)
+{
+	void *addr = memblock_alloc(size, align);
+
+	if (unlikely(!addr))
+		panic("%s: Failed to allocate %pap bytes\n", func, &size);
+	return addr;
+}
+
 /**
  * memblock_free_late - free pages directly to buddy allocator
  * @base: phys starting address of the  boot memory block
diff --git a/mm/numa.c b/mm/numa.c
index e2eec07707d1..f1787d7713a6 100644
--- a/mm/numa.c
+++ b/mm/numa.c
@@ -37,13 +37,7 @@ void __init alloc_node_data(int nid)
 void __init alloc_offline_node_data(int nid)
 {
 	pg_data_t *pgdat;
-
-	pgdat = memblock_alloc(sizeof(*pgdat), SMP_CACHE_BYTES);
-	if (!pgdat)
-		panic("Cannot allocate %zuB for node %d.\n",
-		      sizeof(*pgdat), nid);
-
-	node_data[nid] = pgdat;
+	node_data[nid] = memblock_alloc_or_panic(sizeof(*pgdat), SMP_CACHE_BYTES);
 }
 
 /* Stub functions: */
diff --git a/mm/percpu.c b/mm/percpu.c
index d8dd31a2e407..ac61e3fc5f15 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1359,10 +1359,7 @@ static struct pcpu_chunk * __init pcpu_alloc_first_chunk(unsigned long tmp_addr,
 	/* allocate chunk */
 	alloc_size = struct_size(chunk, populated,
 				 BITS_TO_LONGS(region_size >> PAGE_SHIFT));
-	chunk = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	INIT_LIST_HEAD(&chunk->list);
 
@@ -1374,24 +1371,14 @@ static struct pcpu_chunk * __init pcpu_alloc_first_chunk(unsigned long tmp_addr,
 	region_bits = pcpu_chunk_map_bits(chunk);
 
 	alloc_size = BITS_TO_LONGS(region_bits) * sizeof(chunk->alloc_map[0]);
-	chunk->alloc_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->alloc_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk->alloc_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size =
 		BITS_TO_LONGS(region_bits + 1) * sizeof(chunk->bound_map[0]);
-	chunk->bound_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->bound_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	chunk->bound_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = pcpu_chunk_nr_blocks(chunk) * sizeof(chunk->md_blocks[0]);
-	chunk->md_blocks = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!chunk->md_blocks)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
-
+	chunk->md_blocks = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 #ifdef NEED_PCPUOBJ_EXT
 	/* first chunk is free to use */
 	chunk->obj_exts = NULL;
@@ -2595,28 +2582,16 @@ void __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
 
 	/* process group information and build config tables accordingly */
 	alloc_size = ai->nr_groups * sizeof(group_offsets[0]);
-	group_offsets = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!group_offsets)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	group_offsets = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = ai->nr_groups * sizeof(group_sizes[0]);
-	group_sizes = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!group_sizes)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	group_sizes = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = nr_cpu_ids * sizeof(unit_map[0]);
-	unit_map = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!unit_map)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	unit_map = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	alloc_size = nr_cpu_ids * sizeof(unit_off[0]);
-	unit_off = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
-	if (!unit_off)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      alloc_size);
+	unit_off = memblock_alloc_or_panic(alloc_size, SMP_CACHE_BYTES);
 
 	for (cpu = 0; cpu < nr_cpu_ids; cpu++)
 		unit_map[cpu] = UINT_MAX;
@@ -2685,12 +2660,9 @@ void __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
 	pcpu_free_slot = pcpu_sidelined_slot + 1;
 	pcpu_to_depopulate_slot = pcpu_free_slot + 1;
 	pcpu_nr_slots = pcpu_to_depopulate_slot + 1;
-	pcpu_chunk_lists = memblock_alloc(pcpu_nr_slots *
+	pcpu_chunk_lists = memblock_alloc_or_panic(pcpu_nr_slots *
 					  sizeof(pcpu_chunk_lists[0]),
 					  SMP_CACHE_BYTES);
-	if (!pcpu_chunk_lists)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      pcpu_nr_slots * sizeof(pcpu_chunk_lists[0]));
 
 	for (i = 0; i < pcpu_nr_slots; i++)
 		INIT_LIST_HEAD(&pcpu_chunk_lists[i]);
@@ -3155,25 +3127,19 @@ void __init __weak pcpu_populate_pte(unsigned long addr)
 	pmd_t *pmd;
 
 	if (pgd_none(*pgd)) {
-		p4d = memblock_alloc(P4D_TABLE_SIZE, P4D_TABLE_SIZE);
-		if (!p4d)
-			goto err_alloc;
+		p4d = memblock_alloc_or_panic(P4D_TABLE_SIZE, P4D_TABLE_SIZE);
 		pgd_populate(&init_mm, pgd, p4d);
 	}
 
 	p4d = p4d_offset(pgd, addr);
 	if (p4d_none(*p4d)) {
-		pud = memblock_alloc(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
-		if (!pud)
-			goto err_alloc;
+		pud = memblock_alloc_or_panic(PUD_TABLE_SIZE, PUD_TABLE_SIZE);
 		p4d_populate(&init_mm, p4d, pud);
 	}
 
 	pud = pud_offset(p4d, addr);
 	if (pud_none(*pud)) {
-		pmd = memblock_alloc(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
-		if (!pmd)
-			goto err_alloc;
+		pmd = memblock_alloc_or_panic(PMD_TABLE_SIZE, PMD_TABLE_SIZE);
 		pud_populate(&init_mm, pud, pmd);
 	}
 
@@ -3181,16 +3147,11 @@ void __init __weak pcpu_populate_pte(unsigned long addr)
 	if (!pmd_present(*pmd)) {
 		pte_t *new;
 
-		new = memblock_alloc(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
-		if (!new)
-			goto err_alloc;
+		new = memblock_alloc_or_panic(PTE_TABLE_SIZE, PTE_TABLE_SIZE);
 		pmd_populate_kernel(&init_mm, pmd, new);
 	}
 
 	return;
-
-err_alloc:
-	panic("%s: Failed to allocate memory\n", __func__);
 }
 
 /**
@@ -3237,10 +3198,7 @@ int __init pcpu_page_first_chunk(size_t reserved_size, pcpu_fc_cpu_to_node_fn_t
 	/* unaligned allocations can't be freed, round up to page size */
 	pages_size = PFN_ALIGN(unit_pages * num_possible_cpus() *
 			       sizeof(pages[0]));
-	pages = memblock_alloc(pages_size, SMP_CACHE_BYTES);
-	if (!pages)
-		panic("%s: Failed to allocate %zu bytes\n", __func__,
-		      pages_size);
+	pages = memblock_alloc_or_panic(pages_size, SMP_CACHE_BYTES);
 
 	/* allocate pages */
 	j = 0;
diff --git a/mm/sparse.c b/mm/sparse.c
index 13b6624d3562..133b033d0cba 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -257,10 +257,7 @@ static void __init memblocks_present(void)
 
 		size = sizeof(struct mem_section *) * NR_SECTION_ROOTS;
 		align = 1 << (INTERNODE_CACHE_SHIFT);
-		mem_section = memblock_alloc(size, align);
-		if (!mem_section)
-			panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
-			      __func__, size, align);
+		mem_section = memblock_alloc_or_panic(size, align);
 	}
 #endif
 
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Sun Dec 22 14:04:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Dec 2024 14:04:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862699.1274273 (Exim 4.92)
	(envelope-from )
	id 1tPMZC-00020i-0m; Sun, 22 Dec 2024 14:04:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862699.1274273; Sun, 22 Dec 2024 14:04: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 1tPMZB-00020b-UB; Sun, 22 Dec 2024 14:04:21 +0000
Received: by outflank-mailman (input) for mailman id 862699;
 Sun, 22 Dec 2024 14:04: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 1tPMZA-00020V-IC
 for xen-devel@lists.xenproject.org; Sun, 22 Dec 2024 14:04:21 +0000
Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a140be90-c06d-11ef-99a3-01e77a169b0f;
 Sun, 22 Dec 2024 15:04:16 +0100 (CET)
Received: from nico.bugseng.com (unknown [46.228.253.214])
 by support.bugseng.com (Postfix) with ESMTPSA id 9C8B74EE076E;
 Sun, 22 Dec 2024 15:04:13 +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: a140be90-c06d-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail;
	t=1734876255; bh=eLfaVFeKpO33z15ACjtU4Vwf67q5saCpKCMCAwI9ctU=;
	h=From:To:Cc:Subject:Date:From;
	b=Tp4LvMtvDtqjyFzKHdphVWu2xE+xThCiZWkZ8mZFPXBR6vs8rJumzOzi0KMS94V/D
	 cMQYFlqCRJoyIqNXXS5OD90g9qWKnSu+PJ8FG4GkWxwYIflSGzIJUU/sG+glpTUm6z
	 GnewCtrpALDPR7v/k0JZ+yvzaKy8mlBubD1FxJX/FaZ0Mm/UD4OS/cWhhcUj6AuPvR
	 eTm1ei5L6befvfm7cJEbzNnJUM9X7HBvTur5SdlM+4q/9fgYrBD6F4jyXrTaDCRmiW
	 Kl+fNeYaq5JN+RUQYmfdm/gQoFUc9qTpE2i/+J1W4De1qN1Gny4afzIGBQ2elVsoCX
	 ICzJps441xi4g==
From: Nicola Vetrini 
To: xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org,
	michal.orzel@amd.com,
	xenia.ragiadakou@amd.com,
	ayan.kumar.halder@amd.com,
	consulting@bugseng.com,
	Nicola Vetrini ,
	Simone Ballarin ,
	Doug Goldstein ,
	Andrew Cooper3 
Subject: [XEN PATCH v2] eclair-analysis: tidy toolchain.ecl configuration and mark Rule 1.1 clean
Date: Sun, 22 Dec 2024 15:04:08 +0100
Message-ID: <01be894f3c24aa1d7aba528bd5d6f0a1d5a97504.1734876081.git.nicola.vetrini@bugseng.com>
X-Mailer: git-send-email 2.43.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Reformat the list of GNU extensions and non-standard tokens used by Xen
in the ECLAIR configuration to make it easier to review any changes to it.

The extension "ext_missing_varargs_arg", which captures the GNU extension that
allows variadic functions and macros not to require at least one named parameter
before C23 has been renamed to "ext_c_missing_varargs_arg" in the current version
of ECLAIR used in CI, therefore this resolves regressions on MISRA C Rule 1.1:

"The program shall contain no violations of the standard C syntax and constraints,
and shall not exceed the implementation's translation limits."

As a result, Rule 1.1 now has no violations and is tagged as such.

Remove two unused configurations, that were already commented out.

Signed-off-by: Nicola Vetrini 
Fixes: 631f535a3d4f ("xen: update ECLAIR service identifiers from MC3R1 to MC3A2.")
---
The __inline token is added to the list of accepted non-standard keywords
on arm64 to reduce verbosity (in this way, a single macher can be defined since
the sets of non-standard tokens were identical except for this one).

This change is a candidate for backporting into the 4.18 and 4.19 trees.

Changes in v2:
- drop the old name for the extension
- format the list of extensions and non-standard tokens to be on multiple
  lines, and sort the list
- remove unused, commmented-out, configurations
- tag R1.1 clean
---
 automation/eclair_analysis/ECLAIR/tagging.ecl |  1 +
 .../eclair_analysis/ECLAIR/toolchain.ecl      | 93 +++++++++++++++----
 2 files changed, 74 insertions(+), 20 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl b/automation/eclair_analysis/ECLAIR/tagging.ecl
index 982f506cc7b6..4a1d3b3a9898 100644
--- a/automation/eclair_analysis/ECLAIR/tagging.ecl
+++ b/automation/eclair_analysis/ECLAIR/tagging.ecl
@@ -25,6 +25,7 @@ MC3A2.D2.1||
 MC3A2.D4.1||
 MC3A2.D4.11||
 MC3A2.D4.14||
+MC3A2.R1.1||
 MC3A2.R1.3||
 MC3A2.R1.4||
 MC3A2.R2.6||
diff --git a/automation/eclair_analysis/ECLAIR/toolchain.ecl b/automation/eclair_analysis/ECLAIR/toolchain.ecl
index 86e9a79b5231..8ebf9f132cf2 100644
--- a/automation/eclair_analysis/ECLAIR/toolchain.ecl
+++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl
@@ -12,25 +12,47 @@
 -setq=C99_STD,"ISO/IEC 9899:1999"
 
 -doc_begin="
-    _Static_assert: see Section \"2.1 C Language\" of "GCC_MANUAL".
-    asm, __asm__: see Sections \"6.48 Alternate Keywords\" and \"6.47 How to Use Inline Assembly Language in C Code\" of "GCC_MANUAL".
-    __volatile__: see Sections \"6.48 Alternate Keywords\" and \"6.47.2.1 Volatile\" of "GCC_MANUAL".
-    __const__ : see Section \"6.48 Alternate Keywords\" of "GCC_MANUAL".
-    typeof, __typeof__: see Section \"6.7 Referring to a Type with typeof\" of "GCC_MANUAL".
     __alignof__, __alignof: see Sections \"6.48 Alternate Keywords\" and \"6.44 Determining the Alignment of Functions, Types or Variables\" of "GCC_MANUAL".
+    asm, __asm__: see Sections \"6.48 Alternate Keywords\" and \"6.47 How to Use Inline Assembly Language in C Code\" of "GCC_MANUAL".
     __attribute__: see Section \"6.39 Attribute Syntax\" of "GCC_MANUAL".
+    __builtin_offsetof: see Section \"6.53 Support for offsetof\" of "GCC_MANUAL".
     __builtin_types_compatible_p: see Section \"6.59 Other Built-in Functions Provided by GCC\" of "GCC_MANUAL".
     __builtin_va_arg: non-documented GCC extension.
-    __builtin_offsetof: see Section \"6.53 Support for offsetof\" of "GCC_MANUAL".
+    __const__, __inline__, __inline: see Section \"6.48 Alternate Keywords\" of "GCC_MANUAL".
+    _Static_assert: see Section \"2.1 C Language\" of "GCC_MANUAL".
+    typeof, __typeof__: see Section \"6.7 Referring to a Type with typeof\" of "GCC_MANUAL".
+    __volatile__: see Sections \"6.48 Alternate Keywords\" and \"6.47.2.1 Volatile\" of "GCC_MANUAL".
 "
--config=STD.tokenext,behavior+={c99, GCC_ARM64, "^(_Static_assert|asm|__asm__|__volatile__|__const__|typeof|__typeof__|__alignof__|__attribute__|__builtin_types_compatible_p|__builtin_va_arg|__builtin_offsetof)$"}
--config=STD.tokenext,behavior+={c99, GCC_X86_64, "^(_Static_assert|asm|__asm__|__volatile__|__const__|typeof|__typeof__|__alignof__|__alignof|__attribute__|__builtin_types_compatible_p|__builtin_va_arg|__builtin_offsetof)$"}
+-name_selector+={alignof, "^(__alignof__|__alignof)$"}
+-name_selector+={asm, "^(__asm__|asm)$"}
+-name_selector+={attribute, "^__attribute__$"}
+-name_selector+={builtin_offsetof, "^__builtin_offsetof$"}
+-name_selector+={builtin_types_p, "^__builtin_types_compatible_p$"}
+-name_selector+={builtin_va_arg, "^__builtin_va_arg$"}
+-name_selector+={const, "^__const__$"}
+-name_selector+={inline, "^(__inline__|__inline)$"}
+-name_selector+={static_assert, "^_Static_assert$"}
+-name_selector+={typeof, "^(__typeof__|typeof)$"}
+-name_selector+={volatile, "^__volatile__$"}
+
+-config=STD.tokenext,behavior+={c99, GCC_ARM64||GCC_X86_64,
+"alignof||
+asm||
+attribute||
+builtin_offsetof||
+builtin_types_p||
+builtin_va_arg||
+const||
+inline||
+static_assert||
+typeof||
+volatile"
+}
 -doc_end
 
 -doc_begin="Non-documented GCC extension."
 -config=STD.emptinit,behavior+={c99,GCC_ARM64,specified}
 -config=STD.emptinit,behavior+={c99,GCC_X86_64,specified}
-#-config=STD.emptinit,behavior+={c18,GCC_X86_64,specified}
 -doc_end
 
 -doc_begin="See Section \"6.24 Arithmetic on void- and Function-Pointers\" of "GCC_MANUAL"."
@@ -80,7 +102,6 @@
 -doc_begin="Non-documented GCC extension."
 -config=STD.pteincmp,behavior+={c99,GCC_ARM64,specified}
 -config=STD.pteincmp,behavior+={c99,GCC_X86_64,specified}
-#-config=STD.pteincmp,behavior+={c18,GCC_X86_64,specified}
 -doc_end
 
 -doc_begin="Non-documented GCC extension."
@@ -88,20 +109,52 @@
 -doc_end
 
 -doc_begin="
-    ext_paste_comma: see Section \"6.21 Macros with a Variable Number of Arguments\" of "GCC_MANUAL".
-    ext_missing_varargs_arg: see Section \"6.21 Macros with a Variable Number of Arguments\" of "GCC_MANUAL".
+    ext_c_missing_varargs_arg: see Section \"6.21 Macros with a Variable Number of Arguments\" of "GCC_MANUAL".
+    ext_enum_value_not_int: non-documented GCC extension.
+    ext_flexible_array_in_array: see Section \"6.18 Arrays of Length Zero\" of "GCC_MANUAL".
+    ext_flexible_array_in_struct: see Section \"6.18 Arrays of Length Zero\" of "GCC_MANUAL".
+    ext_forward_ref_enum_def: see Section \"6.49 Incomplete enum Types\" of "GCC_MANUAL".
+    ext_gnu_array_range: see Section \"6.29 Designated Initializers\" of "GCC_MANUAL".
+    ext_gnu_statement_expr_macro: see Section \"6.1 Statements and Declarations in Expressions\" of "GCC_MANUAL".
     ext_named_variadic_macro: see Section \"6.21 Macros with a Variable Number of Arguments\" of "GCC_MANUAL".
+    ext_paste_comma: see Section \"6.21 Macros with a Variable Number of Arguments\" of "GCC_MANUAL".
     ext_return_has_void_expr: see the documentation for -Wreturn-type in Section \"3.8 Options to Request or Suppress Warnings\" of "GCC_MANUAL".
-    ext_gnu_statement_expr_macro: see Section \"6.1 Statements and Declarations in Expressions\" of "GCC_MANUAL".
     ext_sizeof_alignof_void_type: see Section \"6.24 Arithmetic on void- and Function-Pointers\" of "GCC_MANUAL".
-    ext_forward_ref_enum_def: see Section \"6.49 Incomplete enum Types\" of "GCC_MANUAL".
-    ext_flexible_array_in_struct: see Section \"6.18 Arrays of Length Zero\" of "GCC_MANUAL".
-    ext_flexible_array_in_array: see Section \"6.18 Arrays of Length Zero\" of "GCC_MANUAL".
-    ext_enum_value_not_int: non-documented GCC extension.
-    ext_gnu_array_range: see Section \"6.29 Designated Initializers\" of "GCC_MANUAL".
 "
--config=STD.diag,behavior+={c99,GCC_ARM64,"^(ext_paste_comma|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_forward_ref_enum_def|ext_gnu_array_range)$"}
--config=STD.diag,behavior+={c99,GCC_X86_64,"^(ext_paste_comma|ext_missing_varargs_arg|ext_named_variadic_macro|ext_return_has_void_expr|ext_gnu_statement_expr_macro|ext_sizeof_alignof_void_type|ext_flexible_array_in_struct|ext_flexible_array_in_array|ext_enum_value_not_int|ext_gnu_array_range)$"}
+-name_selector+={ext_c_missing_varargs_arg, "^ext_c_missing_varargs_arg$"}
+-name_selector+={ext_enum_value_not_int, "^ext_enum_value_not_int$"}
+-name_selector+={ext_flexible_array_in_array, "^ext_flexible_array_in_array$"}
+-name_selector+={ext_flexible_array_in_struct, "^ext_flexible_array_in_struct$"}
+-name_selector+={ext_forward_ref_enum_def, "^ext_forward_ref_enum_def$"}
+-name_selector+={ext_gnu_array_range, "^ext_gnu_array_range$"}
+-name_selector+={ext_gnu_statement_expr_macro, "^ext_gnu_statement_expr_macro$"}
+-name_selector+={ext_named_variadic_macro, "^ext_named_variadic_macro$"}
+-name_selector+={ext_paste_comma, "^ext_paste_comma$"}
+-name_selector+={ext_return_has_void_expr, "^ext_return_has_void_expr$"}
+-name_selector+={ext_sizeof_alignof_void_type, "^ext_sizeof_alignof_void_type$"}
+
+-config=STD.diag,behavior+={c99,GCC_ARM64,
+"ext_c_missing_varargs_arg||
+ext_forward_ref_enum_def||
+ext_gnu_array_range||
+ext_gnu_statement_expr_macro||
+ext_named_variadic_macro||
+ext_paste_comma||
+ext_return_has_void_expr||
+ext_sizeof_alignof_void_type"
+}
+-config=STD.diag,behavior+={c99,GCC_X86_64,
+"ext_c_missing_varargs_arg||
+ext_enum_value_not_int||
+ext_flexible_array_in_array||
+ext_flexible_array_in_struct||
+ext_gnu_array_range||
+ext_gnu_statement_expr_macro||
+ext_named_variadic_macro||
+ext_paste_comma||
+ext_return_has_void_expr||
+ext_sizeof_alignof_void_type"
+}
 -doc_end
 
 -doc_begin="The maximum size of an object is defined in the MAX_SIZE macro, and for a 32 bit architecture is 8MB.
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Sun Dec 22 16:15:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Dec 2024 16:15:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862711.1274293 (Exim 4.92)
	(envelope-from )
	id 1tPObi-0000Be-T5; Sun, 22 Dec 2024 16:15:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862711.1274293; Sun, 22 Dec 2024 16:15:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tPObi-0000BX-QB; Sun, 22 Dec 2024 16:15:06 +0000
Received: by outflank-mailman (input) for mailman id 862711;
 Sun, 22 Dec 2024 16:15: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 1tPObh-0008OR-MN
 for xen-devel@lists.xenproject.org; Sun, 22 Dec 2024 16:15:05 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e77c0fe5-c07f-11ef-a0da-8be0dac302b0;
 Sun, 22 Dec 2024 17:15:04 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 22 Dec 2024 17:15:04 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id 877A225A7;
 Sun, 22 Dec 2024 17:15:04 +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: e77c0fe5-c07f-11ef-a0da-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734884105; x=1766420105;
  h=from:to:cc:subject:date:message-id:in-reply-to:
   references:mime-version:content-transfer-encoding;
  bh=eey0XVeri/nsLtW4COooiuqzSdIo6CGj8cotECliMN0=;
  b=d4qX6i5CkGAm633vmvfll/tXYJLLT23CJwhgMbJRuH+y6udOzrGJhZlu
   4leH88OSWBwzg4Y/UuzheG3bm+E5rbKXB7y8D+2sp5lXGsk0E2T2QHTCj
   hygP1UA3PJ6gppqzUeUE/ft0y3h3WP0N1DG0jLiawz0wlOHaN/LAwix8Y
   8=;
X-CSE-ConnectionGUID: rRauINs7Q4OPKd5ErFeOGw==
X-CSE-MsgGUID: EPAyPJxcQG+vCtQ8L3/hQQ==
X-IronPort-AV: E=Sophos;i="6.12,255,1728943200"; 
   d="scan'208";a="28291258"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Ariel Otilibili ,
	Jan Beulich ,
	Anthony PERARD 
Subject: [PATCH v3 1/1] libacpi/Makefile: clear ASL warning about PCI0
Date: Sun, 22 Dec 2024 17:10:35 +0100
Message-ID: <20241222161444.1558599-2-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
In-Reply-To: <20241222161444.1558599-1-Ariel.Otilibili-Anieli@eurecom.fr>
References: <20241222161444.1558599-1-Ariel.Otilibili-Anieli@eurecom.fr>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

iasl complains _HID and _ADR cannot be used at the same time:

```
iasl -vs -p tools/firmware/hvmloader/dsdt_anycpu.tmp -tc tools/firmware/hvmloader/dsdt_anycpu.asl 2>&1 | grep -B1 HID

tools/firmware/hvmloader/dsdt_anycpu.asl     40:        Device (PCI0)
Warning  3073 -                                    Multiple types ^  (Device object requires either a _HID or _ADR, but not both)
```

The usage of both _HID and _ADR has changed [1,2]:

>From ACPI 2.0 (Jul. 27, 2000; Section 6.1, page 146):

"A device object must contain either an _HID object or an _ADR object,
but can contain both." [3]

To ACPI 6.0 (April 2015; Section 6.1, page 278),

"A device object must contain either an _HID object or an _ADR object,
but should not contain both." [4]

And from ACPI 6.0 to ACPI 6.5 (Aug. 2022):

"A device object must contain either an _HID object or an _ADR object,
but must not contain both." [5]

Using its ID, the warning is now filtered.

```
$ iasl -vw3073 -vs -p ../firmware/hvmloader/dsdt_anycpu.tmp -tc ../firmware/hvmloader/dsdt_anycpu.asl 2>&1 | grep HID; echo $?
1
```

iasl has one ID per warning [6]; subsequent commits will address other ASL warnings.

```
$ awk 'NR>533 && NR<556 {print NR ":" $0}' source/compiler/aslmethod.c
534:    case PARSEOP_DEVICE:
535:
536:        /* Check usage of _HID and _ADR objects */
537:
538:        HidExists = ApFindNameInDeviceTree (METHOD_NAME__HID, Op);
539:        AdrExists = ApFindNameInDeviceTree (METHOD_NAME__ADR, Op);
540:
541:        if (!HidExists && !AdrExists)
542:        {
543:            AslError (ASL_ERROR, ASL_MSG_MISSING_DEPENDENCY, Op,
544:                "Device object requires a _HID or _ADR");
545:        }
546:        else if (HidExists && AdrExists)
547:        {
548:            /*
549:             * According to the ACPI spec, "A device object must contain
550:             * either an _HID object or an _ADR object, but should not contain
551:             * both".
552:             */
553:            AslError (ASL_WARNING, ASL_MSG_MULTIPLE_TYPES, Op,
554:                "Device object requires either a _HID or _ADR, but not both");
555:        }

$ awk 'NR>188 && NR<206 || NR==432 || /ASL_MSG_MULTIPLE_TYPES/ {print NR ":" $0}' source/compiler/aslmessages.h
189:/*
190: * Values (message IDs) for all compiler messages. There are currently
191: * three distinct blocks of error messages (so that they can be expanded
192: * individually):
193: *      Main ASL compiler
194: *      Data Table compiler
195: *      Preprocessor
196: *
197: * NOTE1: This list must match the tables of message strings in the file
198: * aslmessages.c exactly.
199: *
200: * NOTE2: With the introduction of the -vw option to disable specific
201: * messages, new messages should only be added to the end of these
202: * lists, so that values for existing messages are not disturbed.
203: */
204:typedef enum
205:{
280:    ASL_MSG_MULTIPLE_TYPES,
432:} ASL_MESSAGE_IDS;

$ git remote -v
origin  git@github.com:acpica/acpica.git (fetch)
origin  git@github.com:acpica/acpica.git (push)

$ git log --pretty='%h ("%s")' -n1
7dae72155 ("Logfile: Changes for version 20241212")
```

[1] https://uefi.org/acpi/specs
[2] https://uefi.org/specifications
[3] https://uefi.org/sites/default/files/resources/ACPI_2.pdf
[4] https://uefi.org/sites/default/files/resources/ACPI_6.0.pdf
[5] https://uefi.org/specs/ACPI/6.5/06_Device_Configuration.html?highlight=_hid#device-identification-objects
[6] https://github.com/acpica/acpica

Fixes: 5a8b28bfd4 ("tools/libacpi: cleanup Makefile, don't check for iasl binary")
Signed-off-by: Ariel Otilibili 
---
Cc: Jan Beulich 
Cc: Anthony PERARD 
---
 tools/libacpi/Makefile | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index b21a64c6b4..4668ecb365 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -21,6 +21,8 @@ H_SRC += $(addprefix $(ACPI_BUILD_DIR)/, ssdt_tpm.h ssdt_tpm2.h ssdt_laptop_slat
 MKDSDT_CFLAGS-$(CONFIG_ARM_64) = -DCONFIG_ARM_64
 MKDSDT_CFLAGS-$(CONFIG_X86) = -DCONFIG_X86
 
+IASL_WARNS=3073
+
 # Suffix for temporary files.
 #
 # We will also use this suffix to workaround a bug in older iasl
@@ -32,7 +34,7 @@ TMP_SUFFIX	= tmp
 all: $(C_SRC) $(H_SRC)
 
 $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl
-	$(IASL) -vs -p $(ACPI_BUILD_DIR)/$*.$(TMP_SUFFIX) -tc $<
+	$(IASL) $(IASL_WARNS:%=-vw%) -vs -p $(ACPI_BUILD_DIR)/$*.$(TMP_SUFFIX) -tc $<
 	sed -e 's/AmlCode/$*/g' -e 's/_aml_code//g' $(ACPI_BUILD_DIR)/$*.hex >$@
 	rm -f $(addprefix $(ACPI_BUILD_DIR)/, $*.aml $*.hex)
  
@@ -65,7 +67,7 @@ $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.asl: $(MK_DSDT)
 	mv -f $@.$(TMP_SUFFIX) $@
 
 $(C_SRC): $(ACPI_BUILD_DIR)/%.c: $(ACPI_BUILD_DIR)/%.asl
-	$(IASL) -vs -p $(ACPI_BUILD_DIR)/$*.$(TMP_SUFFIX) -tc $<
+	$(IASL) $(IASL_WARNS:%=-vw%) -vs -p $(ACPI_BUILD_DIR)/$*.$(TMP_SUFFIX) -tc $<
 	sed -e 's/AmlCode/$*/g' -e 's/_aml_code//g' $(ACPI_BUILD_DIR)/$*.hex > $@.$(TMP_SUFFIX)
 	echo "int $*_len=sizeof($*);" >> $@.$(TMP_SUFFIX)
 	mv -f $@.$(TMP_SUFFIX) $@
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Sun Dec 22 16:15:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Dec 2024 16:15:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862710.1274283 (Exim 4.92)
	(envelope-from )
	id 1tPObf-0008Oe-N6; Sun, 22 Dec 2024 16:15:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862710.1274283; Sun, 22 Dec 2024 16:15: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 1tPObf-0008OX-K8; Sun, 22 Dec 2024 16:15:03 +0000
Received: by outflank-mailman (input) for mailman id 862710;
 Sun, 22 Dec 2024 16:15: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 1tPObd-0008OR-P7
 for xen-devel@lists.xenproject.org; Sun, 22 Dec 2024 16:15:02 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id e3f99e6d-c07f-11ef-a0da-8be0dac302b0;
 Sun, 22 Dec 2024 17:14:59 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 22 Dec 2024 17:14:58 +0100
Received: from localhost.localdomain (88-183-119-157.subs.proxad.net
 [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id 549E725A6;
 Sun, 22 Dec 2024 17:14:58 +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: e3f99e6d-c07f-11ef-a0da-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1734884099; x=1766420099;
  h=from:to:cc:subject:date:message-id:mime-version:
   content-transfer-encoding;
  bh=m3E8c+gsHBg4UCtHBORqPVL0o0AgjXSh9rsGkkraBts=;
  b=iGnEVdsRVNyIWvgVxNorpLD0iMzyDKGM1+1a3D2wBAmgKa5F1ll6ccvh
   mkDts+z3gwnEoFxES4NCaIoOVg7aVcghzvWxIs8t5Fsv/vt6U/c5o+0Oe
   qdJTZuQgZla8UcejUBrla4RA1nHho3ttKcpz76XU4LrSMo3BGDdCkugNM
   I=;
X-CSE-ConnectionGUID: BQgVkaQ7RcO5+lXNDPL1vQ==
X-CSE-MsgGUID: ce8i8EFrT6yk0rKvcJrh/w==
X-IronPort-AV: E=Sophos;i="6.12,255,1728943200"; 
   d="scan'208";a="28291256"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Ariel Otilibili ,
	Jan Beulich ,
	Anthony PERARD 
Subject: [PATCH v3 0/1] libacpi/Makefile: clear ASL warning about PCI0
Date: Sun, 22 Dec 2024 17:10:34 +0100
Message-ID: <20241222161444.1558599-1-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.47.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hello,

This patch clears out an ASL warning; below is listed my configuration.

Your feedback is much appreciated.

Thank you,

```
$ iasl -v

Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20240927
Copyright (c) 2000 - 2023 Intel Corporation

$ gcc --version 
gcc (GCC) 14.2.1 20240910
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ uname -a
Linux arc 6.12.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Mon, 09 Dec 2024 14:31:57 +0000 x86_64 GNU/Linux
```
---
v3:
* instead of the DSTD, change done in the Makefile
* adressed feedback of Jan Beulich; the suppression per warning is fine enough

v2:
* stated reasons why the changes should be backward compatible
* see, https://lore.kernel.org/all/7f30f105-e13e-4e41-b432-82f9c12760d9@suse.com/

Ariel Otilibili (1):
  libacpi/Makefile: clear ASL warning about PCI0

 tools/libacpi/Makefile | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Mon Dec 23 07:13:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Dec 2024 07:13:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862746.1274302 (Exim 4.92)
	(envelope-from )
	id 1tPccZ-0004VL-FO; Mon, 23 Dec 2024 07:12:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862746.1274302; Mon, 23 Dec 2024 07:12: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 1tPccZ-0004VE-C8; Mon, 23 Dec 2024 07:12:55 +0000
Received: by outflank-mailman (input) for mailman id 862746;
 Mon, 23 Dec 2024 07:12: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 1tPccX-0004V8-RP
 for xen-devel@lists.xenproject.org; Mon, 23 Dec 2024 07:12:53 +0000
Received: from dfw.source.kernel.org (dfw.source.kernel.org
 [2604:1380:4641:c500::1])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 51c7866e-c0fd-11ef-a0da-8be0dac302b0;
 Mon, 23 Dec 2024 08:12:51 +0100 (CET)
Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])
 by dfw.source.kernel.org (Postfix) with ESMTP id C64ED5C4A8D;
 Mon, 23 Dec 2024 07:12:06 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2221C4CED4;
 Mon, 23 Dec 2024 07:12: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: 51c7866e-c0fd-11ef-a0da-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1734937968;
	bh=KiW6z79yHKtUcMEX/b8/Sp0F2L3XtvvNObnoy9wnwCI=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=PadoaIur+Bq/ska4dZ3htQaJQz4uazLSVowJVHucSNC53reVkWxd5YVJWY/8jYQei
	 G/2ikWxztSp4IduffOwXB0a3mVJH23t9Ex7EGVUz/CnbNl3iJwZRxMrSqxsyp7jx0f
	 g/t903ItkhiEVo2DrupFM7faoTX7/DPcXhBh/bkr20Ay+uNKYZumDkMyBSpawM5raK
	 Ut+5vnDGc2C1sPQD75jm/n63pJiamwi58eI2wR3M3lVdk6xTR5vMn3Ur4QTOlkun8B
	 BK41Buv9qow1NTThvM4tSiBT0cMpdhUu2SLkRibN1ROgpuegs2ZYg313l0II/8FbH3
	 cxXTeCHYfJOYg==
Date: Mon, 23 Dec 2024 09:12:14 +0200
From: Mike Rapoport 
To: Guo Weikang 
Cc: Andrew Morton ,
	Geert Uytterhoeven ,
	Dennis Zhou , Tejun Heo ,
	Christoph Lameter ,
	Thomas Bogendoerfer ,
	Sam Creasey , Huacai Chen ,
	Will Deacon ,
	Catalin Marinas ,
	Oreoluwa Babatunde ,
	rafael.j.wysocki@intel.com, Palmer Dabbelt ,
	Hanjun Guo ,
	Easwar Hariharan ,
	Johannes Berg ,
	Ingo Molnar , Dave Hansen ,
	Christian Brauner ,
	KP Singh ,
	Richard Henderson ,
	Matt Turner ,
	Russell King ,
	WANG Xuerui ,
	Michael Ellerman ,
	Stefan Kristiansson ,
	Stafford Horne , Helge Deller ,
	Nicholas Piggin ,
	Christophe Leroy ,
	Naveen N Rao ,
	Madhavan Srinivasan ,
	Geoff Levand ,
	Paul Walmsley ,
	Palmer Dabbelt ,
	Albert Ou ,
	Andrey Ryabinin ,
	Alexander Potapenko ,
	Andrey Konovalov ,
	Dmitry Vyukov ,
	Vincenzo Frascino ,
	Heiko Carstens ,
	Vasily Gorbik ,
	Alexander Gordeev ,
	Christian Borntraeger ,
	Sven Schnelle ,
	Yoshinori Sato ,
	Rich Felker ,
	John Paul Adrian Glaubitz ,
	Andreas Larsson ,
	Richard Weinberger ,
	Anton Ivanov ,
	Johannes Berg ,
	Thomas Gleixner ,
	Ingo Molnar , Borislav Petkov ,
	Dave Hansen , x86@kernel.org,
	linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
	linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
	linux-openrisc@vger.kernel.org, linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
	kasan-dev@googlegroups.com, linux-s390@vger.kernel.org,
	linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
	linux-um@lists.infradead.org, linux-acpi@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-omap@vger.kernel.org,
	linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
	linux-mm@kvack.org, linux-pm@vger.kernel.org,
	Xi Ruoyao 
Subject: Re: [PATCH v7] mm/memblock: Add memblock_alloc_or_panic interface
Message-ID: 
References: <20241222111537.2720303-1-guoweikang.kernel@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20241222111537.2720303-1-guoweikang.kernel@gmail.com>

On Sun, Dec 22, 2024 at 07:15:37PM +0800, Guo Weikang wrote:
> Before SLUB initialization, various subsystems used memblock_alloc to
> allocate memory. In most cases, when memory allocation fails, an immediate
> panic is required. To simplify this behavior and reduce repetitive checks,
> introduce `memblock_alloc_or_panic`. This function ensures that memory
> allocation failures result in a panic automatically, improving code
> readability and consistency across subsystems that require this behavior.
> 
> Changelog:
> ----------
> v1: initial version
> v2: add __memblock_alloc_or_panic support panic output caller
> v3: panic output phys_addr_t use printk's %pap
> v4: make __memblock_alloc_or_panic out-of-line, move to memblock.c
> v6: Fix CI compile error
> Links to CI: https://lore.kernel.org/oe-kbuild-all/202412221000.r1NzXJUO-lkp@intel.com/
> v6: Fix CI compile warinigs
> Links to CI: https://lore.kernel.org/oe-kbuild-all/202412221259.JuGNAUCq-lkp@intel.com/
> v7: add chagelog and adjust function declaration alignment format
> ----------
> 
> Signed-off-by: Guo Weikang 
> Reviewed-by: Andrew Morton 
> Reviewed-by: Geert Uytterhoeven 
> Reviewed-by: Mike Rapoport (Microsoft) 
> Acked-by: Xi Ruoyao 

If people commented on your patch it does not mean you should add
Reviewed-by or Acked-by tags for them. Wait for explicit tags from the
reviewers.

And don't respin that often, "Reviewers are busy people and may not get to
your patch right away" [1].

[1] https://docs.kernel.org/process/submitting-patches.html


-- 
Sincerely yours,
Mike.


From xen-devel-bounces@lists.xenproject.org Mon Dec 23 07:32:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Dec 2024 07:32:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862761.1274313 (Exim 4.92)
	(envelope-from )
	id 1tPcvK-0007RF-5O; Mon, 23 Dec 2024 07:32:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862761.1274313; Mon, 23 Dec 2024 07:32: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 1tPcvK-0007R8-2f; Mon, 23 Dec 2024 07:32:18 +0000
Received: by outflank-mailman (input) for mailman id 862761;
 Mon, 23 Dec 2024 07:32: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 1tPcvI-0007Qm-3W
 for xen-devel@lists.xenproject.org; Mon, 23 Dec 2024 07:32:16 +0000
Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com
 [2607:f8b0:4864:20::112b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 068b465b-c100-11ef-99a3-01e77a169b0f;
 Mon, 23 Dec 2024 08:32:13 +0100 (CET)
Received: by mail-yw1-x112b.google.com with SMTP id
 00721157ae682-6f277a1ecfdso28461527b3.2
 for ; Sun, 22 Dec 2024 23:32:13 -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: 068b465b-c100-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734939132; x=1735543932; 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=0v6aG1YFkKVxPZgrKFkppCnD7setaclMAdKcShBz7Ms=;
        b=RgJeAqJhmx19ynFZsGk09JQWQ5/EZzoOohZEKqsGrdCZsOwXQz14Bv/jujh9xXXdSA
         irBLj9uy4b1W9/QaVviaRp4faKZn80PIGc+noy6lpal4dLSzIV6t2JSe4DTiasSlmM0S
         jS8ifl5yxRrqhpjDL8lS8yaRw5ncgjkjGNqNweNBOeg2sy9EGQMuEfy+fIg5gzeisS29
         XGqVJVoDrLea3XV5iKKI8pVWIEYHvbNZ/mks30EvK1bK3lGsaLRNbiN1p5Sn2R58Mtzu
         WOx9drEPV7Yxws8Uq6LRJUmP4nh24BRhcxHUZr1nDA3NSZy+9idz96PWp1TVx/6NpVym
         pkcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734939132; x=1735543932;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=0v6aG1YFkKVxPZgrKFkppCnD7setaclMAdKcShBz7Ms=;
        b=Z1xyQi2ALwgpEkatyz5L60dLVDKXjobIqs5/l64oeyUL6Q/RtpFL8MVxMpHPXCtiwk
         DtvSwc48UV2Thqj8Zi/HJ9jx/vikDaUQp+GeblmIcMlUTlFoaISkRpcgV8irWHtanO1r
         6FFuup3w/93AbWoUnMJqTqiLnqML9LUMxf2SzMH2WMXqDw2rlToxkwtfuQ0uePVCLdrZ
         v/l1+f4sbZnEbsIblopOlRSfb4FUeEV0mS3DtLDi2/B+0FJcCuPFp5rge+RQmXpw4bGF
         MZ4H7RbJFffu+g2cDBod5X7DbfLRhYEhT2TQJTGIGzKBc1r5ravV44RGYgaB138DVwzw
         bMVQ==
X-Forwarded-Encrypted: i=1; AJvYcCVEGXUv9XQRQzG0EoTREyCAQYidLZ/5v5GgSvyb/cN9dxiJf3ZZKCAfA1UKP1p2+dwb1Sg6JECKf+4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxdNo+tXVw4XqVOFlF97Yxp7MF/ZNlrx5AaSBoBuVdxwwFEOvXb
	itGrnCU1/k5Mrh+P97AZi1Rp7RjK3k4XGZ28ANwxRoIMxA1UJHK3DhMJoEIGnawRCpmtTqoaRts
	hxj6xK6rklb8ZRVP+JL9fKT4lhdc=
X-Gm-Gg: ASbGncsHRp2bQ0jOSFydISz5GNenHSQ4gc+XQBZu8Xwr/CvXwxiD+1QGjfIQLyc3Bw1
	NKSrdntMuzfiTxnVQvwt7kQ98uQcL9tlFVJIw4dY=
X-Google-Smtp-Source: AGHT+IE9Zx6rrSxmo/TfVMJEMfCSEvv5kTOAJj2WU/ZWv6yREWR2EgA4NDWJv08ZAUMMHtBOTiCxaj5H+lZ0CIJRFqw=
X-Received: by 2002:a05:690c:6e0c:b0:6ef:6b56:fb46 with SMTP id
 00721157ae682-6f3f824cb08mr87351047b3.40.1734939131915; Sun, 22 Dec 2024
 23:32:11 -0800 (PST)
MIME-Version: 1.0
References: <20241222111537.2720303-1-guoweikang.kernel@gmail.com> 
In-Reply-To: 
From: Weikang Guo 
Date: Mon, 23 Dec 2024 15:32:01 +0800
Message-ID: 
Subject: Re: [PATCH v7] mm/memblock: Add memblock_alloc_or_panic interface
To: Mike Rapoport 
Cc: Andrew Morton , Geert Uytterhoeven , 
	Dennis Zhou , Tejun Heo , Christoph Lameter , 
	Thomas Bogendoerfer , Sam Creasey , 
	Huacai Chen , Will Deacon , 
	Catalin Marinas , Oreoluwa Babatunde , 
	rafael.j.wysocki@intel.com, Palmer Dabbelt , 
	Hanjun Guo , Easwar Hariharan , 
	Johannes Berg , Ingo Molnar , 
	Dave Hansen , Christian Brauner , 
	KP Singh , Richard Henderson , 
	Matt Turner , Russell King , 
	WANG Xuerui , Michael Ellerman , 
	Stefan Kristiansson , Stafford Horne , 
	Helge Deller , Nicholas Piggin , 
	Christophe Leroy , Naveen N Rao , 
	Madhavan Srinivasan , Geoff Levand , 
	Paul Walmsley , Palmer Dabbelt , 
	Albert Ou , Andrey Ryabinin , 
	Alexander Potapenko , Andrey Konovalov , 
	Dmitry Vyukov , Vincenzo Frascino , 
	Heiko Carstens , Vasily Gorbik , 
	Alexander Gordeev , Christian Borntraeger , 
	Sven Schnelle , Yoshinori Sato , 
	Rich Felker , John Paul Adrian Glaubitz , 
	Andreas Larsson , Richard Weinberger , 
	Anton Ivanov , Johannes Berg , 
	Thomas Gleixner , Ingo Molnar , Borislav Petkov , 
	Dave Hansen , x86@kernel.org, linux-alpha@vger.kernel.org, 
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org, 
	linux-mips@vger.kernel.org, linux-openrisc@vger.kernel.org, 
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, 
	linux-riscv@lists.infradead.org, kasan-dev@googlegroups.com, 
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, 
	sparclinux@vger.kernel.org, linux-um@lists.infradead.org, 
	linux-acpi@vger.kernel.org, xen-devel@lists.xenproject.org, 
	linux-omap@vger.kernel.org, linux-clk@vger.kernel.org, 
	devicetree@vger.kernel.org, linux-mm@kvack.org, linux-pm@vger.kernel.org, 
	Xi Ruoyao 
Content-Type: text/plain; charset="UTF-8"

Mike Rapoport  wrote on Monday 23 December 2024 at 15:12
>
> On Sun, Dec 22, 2024 at 07:15:37PM +0800, Guo Weikang wrote:
> > Before SLUB initialization, various subsystems used memblock_alloc to
> > allocate memory. In most cases, when memory allocation fails, an immediate
> > panic is required. To simplify this behavior and reduce repetitive checks,
> > introduce `memblock_alloc_or_panic`. This function ensures that memory
> > allocation failures result in a panic automatically, improving code
> > readability and consistency across subsystems that require this behavior.
> >
> > Changelog:
> > ----------
> > v1: initial version
> > v2: add __memblock_alloc_or_panic support panic output caller
> > v3: panic output phys_addr_t use printk's %pap
> > v4: make __memblock_alloc_or_panic out-of-line, move to memblock.c
> > v6: Fix CI compile error
> > Links to CI: https://lore.kernel.org/oe-kbuild-all/202412221000.r1NzXJUO-lkp@intel.com/
> > v6: Fix CI compile warinigs
> > Links to CI: https://lore.kernel.org/oe-kbuild-all/202412221259.JuGNAUCq-lkp@intel.com/
> > v7: add chagelog and adjust function declaration alignment format
> > ----------
> >
> > Signed-off-by: Guo Weikang 
> > Reviewed-by: Andrew Morton 
> > Reviewed-by: Geert Uytterhoeven 
> > Reviewed-by: Mike Rapoport (Microsoft) 
> > Acked-by: Xi Ruoyao 
>
> If people commented on your patch it does not mean you should add
> Reviewed-by or Acked-by tags for them. Wait for explicit tags from the
> reviewers.

First of all, thank you for your reminder and patience. In fact, this
is the first time I received a patch discussion when submitting a
patch.
About Reviewed-by or Acked-by tags, I will not add it myself in the
future. Regarding this patch, do I need to provide a new patch to
update it? Or will you modify it?  Looking forward to your reply

>
> And don't respin that often, "Reviewers are busy people and may not get to
> your patch right away" [1].
>

OK, I will be more patient and update after confirming that there are
no more comments.

> [1] https://docs.kernel.org/process/submitting-patches.html
>
>
> --
> Sincerely yours,
> Mike.


--
Best regards,
Guo


From xen-devel-bounces@lists.xenproject.org Mon Dec 23 07:58:54 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Dec 2024 07:58:54 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862776.1274322 (Exim 4.92)
	(envelope-from )
	id 1tPdKy-0002Pp-VW; Mon, 23 Dec 2024 07:58:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862776.1274322; Mon, 23 Dec 2024 07:58: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 1tPdKy-0002Pi-T0; Mon, 23 Dec 2024 07:58:48 +0000
Received: by outflank-mailman (input) for mailman id 862776;
 Mon, 23 Dec 2024 07:58: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 1tPdKx-0002Pc-2b
 for xen-devel@lists.xenproject.org; Mon, 23 Dec 2024 07:58:47 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20606.outbound.protection.outlook.com
 [2a01:111:f403:2417::606])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id bb51b16a-c103-11ef-99a3-01e77a169b0f;
 Mon, 23 Dec 2024 08:58:44 +0100 (CET)
Received: from DM6PR08CA0051.namprd08.prod.outlook.com (2603:10b6:5:1e0::25)
 by PH7PR12MB5806.namprd12.prod.outlook.com (2603:10b6:510:1d2::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.18; Mon, 23 Dec
 2024 07:58:35 +0000
Received: from DS1PEPF00017098.namprd05.prod.outlook.com
 (2603:10b6:5:1e0:cafe::cf) by DM6PR08CA0051.outlook.office365.com
 (2603:10b6:5:1e0::25) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8272.20 via Frontend Transport; Mon,
 23 Dec 2024 07:58:34 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 DS1PEPF00017098.mail.protection.outlook.com (10.167.18.102) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8293.12 via Frontend Transport; Mon, 23 Dec 2024 07:58:34 +0000
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 23 Dec
 2024 01:58:32 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 23 Dec 2024 01:58: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: bb51b16a-c103-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=L2djVaDPLVBaf6GQdK7AhSBIIyUysPMeo6bImlMwGPBdloSQUKPJ8GT1gE/ARKr4XQwl+tU3/GejK3xMbjN/3B2lqGSGfnFba07R4WP89Vfemg8aPLmNKUdWnJhB5zaUokgt1E9q69SrVzV4HGt5dGXBHsgprQN2Wwc8f/BSbm5jXrzToptfy9x2k0HsCwtgWMf1nRgmWzWDWuqFAwDcnXW+B+WDgXcUQKFJn72GV3gxtjB7aAOH1/uvKBRuFrfRM2uu49d3xnuh2Y1JRsdtyigTYsw1QUpA7DI4kiqiiZbmQgDlOiEglez8gzGypCXBO5mQgcmp3/E62lnqe95IlA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=OSNWnsO7qYRDox0AYIv661NFImBFH14dpdkcFo++nE8=;
 b=FzvlWfIbWOMGSe5qxGB9jpKmaRcghJ2T1OAit635rY2vashM3uat7/MeYj2bKzIonm6LTxW0epi6EJ74uvx3eirL8kfFoLV9kFUrD/MHZNugxojsdpRDa5FhPA7eQr9EzcHwbl0+3GVnHB75qGA6jO8nTnmEk2OX+yK+JnUn2R4grW1YpDU1gA8cwN9+kGmKH8lP/hhsuBT7l4dtBmdumj9/QK6Y5JX7pBG3O7r2BCCeiPtQA+s+5DjZUZNKoUrvlfjbvCkc6Vei6ROwwF8S4Ad5519smBxUCSxSLAy+w+x9lil906wv46bdN/kj6N+shfCso9NdF2MATdj6VCHA1g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=OSNWnsO7qYRDox0AYIv661NFImBFH14dpdkcFo++nE8=;
 b=CcFa4WW2BQvNImPljuTIco3UBvW46vlktt+3+Yudcme0bFX78s6pBEppynIoyM1zalFnUYoRqgfwreDEaVfoXyK6J0PUH2OIQjU/grWbSGUmU1XakXef09VLF2QuzjlBJVxf8DPQgoxca5JPDUwp0AIt+07zGl76xBOJ/luLYS4=
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=SATLEXMB03.amd.com; pr=C
Message-ID: <2a7ac358-7f43-4e32-9e1e-9ce1cd45304a@amd.com>
Date: Mon, 23 Dec 2024 08:58:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: Initialise memory type for struct kernel_info
To: Luca Fancellu , 
CC: Stefano Stabellini , Julien Grall
	, Bertrand Marquis , Volodymyr
 Babchuk 
References: <20241220151941.4192864-1-luca.fancellu@arm.com>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <20241220151941.4192864-1-luca.fancellu@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS1PEPF00017098:EE_|PH7PR12MB5806:EE_
X-MS-Office365-Filtering-Correlation-Id: 909b3bcb-79a8-4741-3af3-08dd232799b6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|1800799024|376014|36860700013|82310400026|7053199007;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?UHREVmJoYXZHd0tKOXZreWVQQU8zYisrSk9ZQWhLeXlCcktzYytYL2FQOGJq?=
 =?utf-8?B?clZBRCtVd0JnNzZvQjR0MnZkdklaYWlJdy9NcnlvU0VNWTg2dlBvRVkrWUM1?=
 =?utf-8?B?YTJNbEd2eUFadGVSd3hlS0d5TkpUZkRMQlFraVJpc0hhQnFRUVNqVFRQNzFE?=
 =?utf-8?B?blpkK1l1U2xDdytSOTFpZmpoNmJ1SFFNSmVPajNsVFUrUlNMb3NiZ08xSDFO?=
 =?utf-8?B?WStad2JGc3VZZlJaZ1BtdzNDS1hNY09xaUl4eHVzemZuQlc2c3pBRkovaG1O?=
 =?utf-8?B?U00vTmxxZC9uQjEwYnlhWldJWWpRdGkwUTRyamxhYTRwVDd2dkJ1NFcxaW4y?=
 =?utf-8?B?Z0hGUitCN3RzUXU2NmNNaG1RdUQyWURTcVVCOUJvSFlXblRKNG5uWUpKb0dF?=
 =?utf-8?B?MUV2cGNSbjRIZFBFOUZPYTFJZFl3b3BCQ0o2WG1sQ0dlR2NSMGxEUW9xdEwv?=
 =?utf-8?B?alAvTVNIWVA4MU1BVTF4c2d6NmUyU3ZIVjJvMW8xcFJDczhWcFhjMmNPVjdU?=
 =?utf-8?B?c3o4UzM4ZlZzUHV3ZHJnZmJNWE9xQmVVd0VRdnpLOHFNdzJWOUhidFp0VlFl?=
 =?utf-8?B?eDloaWY1dWhoVGdGWE9GWnZwTzBGRnpsR2RNOTE3QnVHTHhEalBuYlVNa2ND?=
 =?utf-8?B?LzZlMFNkM243dkVkSmxIRHNtY3FaQ2RndFBYQUQ1TFJPOUYvWlo2Wkt1Vmdu?=
 =?utf-8?B?aEJpdGpDOTBEK0duVGVSVUNxR3ZOZDZUUTFlUlVLUW5yektWN1hqditRc2lM?=
 =?utf-8?B?Q1pmU09Id3JvR082MDBmTnZta3FnZWlxVjVINHZBTE9zTmlKa253V1QvemMy?=
 =?utf-8?B?V3BWbUZ2YVNYTWFpUHh3ZTNzeTZ4dWc5RW1iYzNlbHh6dncyTGhIeG1VNmV2?=
 =?utf-8?B?czZzZUovY2lzakpuZkVZamRzQ2R5anVybS9jUUNCVkVnS0pWUU5CaEgrMHdU?=
 =?utf-8?B?NmhES2pvNWI4SFpXY25qWEtBRFVkZUs2Z2wyY0JhWDF2MWltWWxmdUlMT0ll?=
 =?utf-8?B?NzNaeGVycmxPUkdjV0JMUWJmRExGUjVmbzVUSEJaNWdQZjFjSmVLdU53cUxx?=
 =?utf-8?B?eHBsaHJmaUpLelJxWEpkaitNd2FlenQxbE11enpHR1FFSGlHaHRpLyt0UDJM?=
 =?utf-8?B?VXk0TlAyeUdGMWVmQklPeFlaOFhndFdjamhRVEN3NThrRDdaeGJZLzE5V1Vv?=
 =?utf-8?B?MTkzenFjaGVpajRjMDFad1VRWE9meEUyQXhVdjlLTEJsMlloSjh5NlF4VHZF?=
 =?utf-8?B?bjF2UWZuZW43REh6VVd6bysyMGZqaUN3VFdmWUdMTzFuZTlwWmh4cHJvcnJq?=
 =?utf-8?B?WUh4WU9nSnFwTjQzT09MS3NGb1VYQnFtMGxCbHZqZ05WNUdpWHZiZzZ5eG52?=
 =?utf-8?B?NzhNc1BSVk9WUmdCL0FuTjBiNTZsMTF6TGlxZW1BTFArSUhZaUZXZWo1ajMw?=
 =?utf-8?B?TE04SXhCMzZ5NUNTZlhOcVc1R2dPUDBEMm1GbEIyY0tla0ZTQjJlMzM0VXd0?=
 =?utf-8?B?VFQwN3dlL2FseVYvbEIzYTBhSXFocEtWNnNDYlE3Kzl0U1lsNDZZSVhGWXFR?=
 =?utf-8?B?eVhEcTZRa05LbGw1ZTF3WFEvMFhEOEJVbzlVSnRUcXNFakRFZUlLL0ducVlZ?=
 =?utf-8?B?dkpXNzV4QVJYTWFwUUFLUmhzcmh1b2JjcmdHS2MvNW5sQm9ITGI5RERRUGtN?=
 =?utf-8?B?bEtYMXJEUmtzVDFwOTY4cGwyS0Q2bGpFcVFFRVFYV3ZpbWcrVm1zdkIwRzBq?=
 =?utf-8?B?OXdOWW4rRTI4OU4wZ3BoOWlxcG5uWnQrRTBKRlAzb2JnRjN4dzVJVnNwK2RQ?=
 =?utf-8?B?V203RWJWUHR2Y09Rb2hVa1o4U2dwUWdISUtqR1RhaSs4bzhkMWYzZjJxZTh3?=
 =?utf-8?B?NFhJY1cvZEtlcjdldnhlOXJOUnhBdlphekU0UlhzSDJKS040VmhHbW16YXYr?=
 =?utf-8?B?MmVzWktVQkVzZlQyNTAzVWNzV3VmOWRMMnZ2UklqN01Xa3VWWnpMd2grRVla?=
 =?utf-8?Q?MgyZraObs3vKzd5lSrLmen1C2ZfKbE=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(36860700013)(82310400026)(7053199007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Dec 2024 07:58:34.4938
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 909b3bcb-79a8-4741-3af3-08dd232799b6
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS1PEPF00017098.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5806



On 20/12/2024 16:19, Luca Fancellu wrote:
> 
> 
> Commit a14593e3995a ("xen/device-tree: Allow region overlapping with
> /memreserve/ ranges") introduced a type in the 'struct membanks_hdr'
> but forgot to update the 'struct kernel_info' initialiser, while
> it doesn't lead to failures because the field is not currently
> used while managing kernel_info structures, it's good to have it
> for completeness.
The last part "good to have it" does not sound like we need a Fixes tag.
I'm in two minds here. At the moment we do have some consistency because
we use and therefore initialize .type member only for bootinfo related structures.

You suggest to expand this also to kernel_info. But what about other places using
struct membanks that, after all, is a useful generic structure? One example you can find
is static struct shm_heap_banks in static-shmem.c for which you do not set a type. Another
example is allocate_memory() or find_host_extended_regions() where we have to convert gnttab
region into struct membanks and there is no need to use the type at all. So, do you suggest
we should initialize (explicitly) .type only for *meminfo based structures or all the structures
using struct membanks?

> 
> Fixes: a14593e3995a ("xen/device-tree: Allow region overlapping with /memreserve/ ranges")
> Signed-off-by: Luca Fancellu 
> ---
>  xen/arch/arm/include/asm/kernel.h | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/include/asm/kernel.h b/xen/arch/arm/include/asm/kernel.h
> index 7e6e3c82a477..de3f945ae54c 100644
> --- a/xen/arch/arm/include/asm/kernel.h
> +++ b/xen/arch/arm/include/asm/kernel.h
> @@ -92,7 +92,9 @@ kernel_info_get_mem_const(const struct kernel_info *kinfo)
>  }
> 
>  #ifdef CONFIG_STATIC_SHM
> -#define KERNEL_INFO_SHM_MEM_INIT .shm_mem.common.max_banks = NR_SHMEM_BANKS,
> +#define KERNEL_INFO_SHM_MEM_INIT                \
> +    .shm_mem.common.max_banks = NR_SHMEM_BANKS, \
> +    .shm_mem.common.type = STATIC_SHARED_MEMORY,
>  #else
>  #define KERNEL_INFO_SHM_MEM_INIT
>  #endif
> @@ -100,6 +102,7 @@ kernel_info_get_mem_const(const struct kernel_info *kinfo)
>  #define KERNEL_INFO_INIT                        \
>  {                                               \
>      .mem.common.max_banks = NR_MEM_BANKS,       \
> +    .mem.common.type = MEMORY,                  \
>      KERNEL_INFO_SHM_MEM_INIT                    \
>  }
> 
> --
> 2.34.1
> 

~Michal




From xen-devel-bounces@lists.xenproject.org Mon Dec 23 08:00:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Dec 2024 08:00:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862789.1274332 (Exim 4.92)
	(envelope-from )
	id 1tPdMC-0003jy-Kz; Mon, 23 Dec 2024 08:00:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862789.1274332; Mon, 23 Dec 2024 08:00: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 1tPdMC-0003je-Ge; Mon, 23 Dec 2024 08:00:04 +0000
Received: by outflank-mailman (input) for mailman id 862789;
 Mon, 23 Dec 2024 08:00: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 1tPdMB-0003bi-Rx
 for xen-devel@lists.xenproject.org; Mon, 23 Dec 2024 08:00:03 +0000
Received: from mail.alien8.de (mail.alien8.de [2a01:4f9:3051:3f93::2])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e9442551-c103-11ef-99a3-01e77a169b0f;
 Mon, 23 Dec 2024 09:00:01 +0100 (CET)
Received: from localhost (localhost.localdomain [127.0.0.1])
 by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id D012140E0288; 
 Mon, 23 Dec 2024 07:59:59 +0000 (UTC)
Received: from mail.alien8.de ([127.0.0.1])
 by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id IM0pXPZd7px8; Mon, 23 Dec 2024 07:59:57 +0000 (UTC)
Received: from nazgul.tnic (2-228-221-6.ip193.fastwebnet.it [2.228.221.6])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest
 SHA256) (No client certificate requested)
 by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id C580D40E0286;
 Mon, 23 Dec 2024 07:58:32 +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: e9442551-c103-11ef-99a3-01e77a169b0f
X-Virus-Scanned: Debian amavisd-new at mail.alien8.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8;
	t=1734940795; bh=oLmiO6e1v7+WwnKur2gbXxPFrWqAvAvJYXOalhGYmh0=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=NwAS/XG2uaILqi2tnPoMceO1SFvcdwgB2eUP+lF0E3qtxPsrkKvNIAdwvcYOwYLbg
	 VvqRX9HbNopYUz0E8WqlR4+hwS4evjJxGuAOGasHGtlugkVJp9ywpiKC8EbDZ422zm
	 muU9ukFK3vu7hlaK35oICq0nKKtYMvBJQy2OPsR+mvKsFD61IL8Mw2MAlMJkEryItZ
	 Tzude+wGqe0Sw9wWIR9qCEh9iQ+cGYRJHeuycqd23zgYmnzkMpT5N1DW0p6NrAgCYf
	 olFh8rx2BkdY5or8KF6raR/v2Ni/IFGcDQKB5uSqrYJiXVWNpgp+jX4ZxJgjDbURJ4
	 cSrvSAzFi4ZxrvHZ1a2k5YfgSAP6AQYRPi9NLJBbrvSRcSIni8b7sSzt4BURfuxCE2
	 r4sJGrTU/6kz8jXjqNQu+e5JVOpZaEHuyoW5vdTmIKsc1KmSM8jxmKbimkXbQrlsIH
	 90+POUXhp51ZscIRGQuA125qI7jngipHuMx2xQIaDiLgkkm892NzJLWoWCASuUcIjP
	 t7xw06sq/JRCWhb65oG60xkW3rPq6o8p+BSEtePeDRS1FBXX3NANrTP8cZLWwcZ34D
	 4b4E4Fx232+BRVdx65v4LFgXYODS/oGKPtkkdO7V+2SrY5pMunLK7ADoymYz7xZnXg
	 ml+quzLMltF9PXnz4EArbLUs=
Date: Mon, 23 Dec 2024 08:58:11 +0100
From: Borislav Petkov 
To: Weikang Guo 
Cc: Mike Rapoport ,
	Andrew Morton ,
	Geert Uytterhoeven ,
	Dennis Zhou , Tejun Heo ,
	Christoph Lameter ,
	Thomas Bogendoerfer ,
	Sam Creasey , Huacai Chen ,
	Will Deacon ,
	Catalin Marinas ,
	Oreoluwa Babatunde ,
	rafael.j.wysocki@intel.com, Palmer Dabbelt ,
	Hanjun Guo ,
	Easwar Hariharan ,
	Johannes Berg ,
	Ingo Molnar , Dave Hansen ,
	Christian Brauner ,
	KP Singh ,
	Richard Henderson ,
	Matt Turner ,
	Russell King ,
	WANG Xuerui ,
	Michael Ellerman ,
	Stefan Kristiansson ,
	Stafford Horne , Helge Deller ,
	Nicholas Piggin ,
	Christophe Leroy ,
	Naveen N Rao ,
	Madhavan Srinivasan ,
	Geoff Levand ,
	Paul Walmsley ,
	Palmer Dabbelt ,
	Albert Ou ,
	Andrey Ryabinin ,
	Alexander Potapenko ,
	Andrey Konovalov ,
	Dmitry Vyukov ,
	Vincenzo Frascino ,
	Heiko Carstens ,
	Vasily Gorbik ,
	Alexander Gordeev ,
	Christian Borntraeger ,
	Sven Schnelle ,
	Yoshinori Sato ,
	Rich Felker ,
	John Paul Adrian Glaubitz ,
	Andreas Larsson ,
	Richard Weinberger ,
	Anton Ivanov ,
	Johannes Berg ,
	Thomas Gleixner ,
	Ingo Molnar ,
	Dave Hansen , x86@kernel.org,
	linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
	linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
	linux-openrisc@vger.kernel.org, linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
	kasan-dev@googlegroups.com, linux-s390@vger.kernel.org,
	linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
	linux-um@lists.infradead.org, linux-acpi@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-omap@vger.kernel.org,
	linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
	linux-mm@kvack.org, linux-pm@vger.kernel.org,
	Xi Ruoyao 
Subject: Re: [PATCH v7] mm/memblock: Add memblock_alloc_or_panic interface
Message-ID: <20241223075811.GAZ2kYEwZ93CYkatrD@fat_crate.local>
References: <20241222111537.2720303-1-guoweikang.kernel@gmail.com>
 
 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 23, 2024 at 03:32:01PM +0800, Weikang Guo wrote:
> First of all, thank you for your reminder and patience. In fact, this
> is the first time I received a patch discussion when submitting a
> patch.
> About Reviewed-by or Acked-by tags, I will not add it myself in the
> future. Regarding this patch, do I need to provide a new patch to
> update it? Or will you modify it?  Looking forward to your reply

It is all explained here:

https://kernel.org/doc/html/latest/process/development-process.html

Go read it while waiting instead of spamming everyone.

Lemme get your started on that reading:

"Don=E2=80=99t get discouraged - or impatient

After you have submitted your change, be patient and wait. Reviewers are
busy people and may not get to your patch right away.

Once upon a time, patches used to disappear into the void without
comment, but the development process works more smoothly than that now.
You should receive comments within a few weeks (typically 2-3); if that
does not happen, make sure that you have sent your patches to the right
place. Wait for a minimum of one week before resubmitting or pinging
reviewers - possibly longer during busy times like merge windows."

--=20
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette


From xen-devel-bounces@lists.xenproject.org Mon Dec 23 10:07:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Dec 2024 10:07:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862810.1274342 (Exim 4.92)
	(envelope-from )
	id 1tPfKt-00040L-6c; Mon, 23 Dec 2024 10:06:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862810.1274342; Mon, 23 Dec 2024 10:06: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 1tPfKt-00040E-3c; Mon, 23 Dec 2024 10:06:51 +0000
Received: by outflank-mailman (input) for mailman id 862810;
 Mon, 23 Dec 2024 10:06:50 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1tPfKs-000403-5n
 for xen-devel@lists.xenproject.org; Mon, 23 Dec 2024 10:06:50 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1tPfKr-000X7w-1G;
 Mon, 23 Dec 2024 10:06:49 +0000
Received: from [2a02:8012:3a1:0:ed95:e074:2d19:de59]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1tPfKr-00FF5U-1N;
 Mon, 23 Dec 2024 10:06: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" 
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=KNX5RKrqTIbir8pg+8ZJSKXL7NeP6ZV2OfAyXEPyr+g=; b=NcX8AowuSR6PrMaKVZxE3709+9
	B/mIRbK465dTJqgDwF0JrHdbcjJm7NihykoECJJwNkFdwsapyBXwwWoytP8TUjxgT2L8B5nKQc1wU
	PGWFz8aRrRl2K6xp9bvD06c91pc2283xkzH6wL6nzLOq5t6syQdCi9hhHCdXbYEDpVkI=;
Message-ID: 
Date: Mon, 23 Dec 2024 10:06:47 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: Initialise memory type for struct kernel_info
Content-Language: en-GB
To: Michal Orzel , Luca Fancellu
 , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20241220151941.4192864-1-luca.fancellu@arm.com>
 <2a7ac358-7f43-4e32-9e1e-9ce1cd45304a@amd.com>
From: Julien Grall 
In-Reply-To: <2a7ac358-7f43-4e32-9e1e-9ce1cd45304a@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Michal,

On 23/12/2024 07:58, Michal Orzel wrote:
> 
> 
> On 20/12/2024 16:19, Luca Fancellu wrote:
>>
>>
>> Commit a14593e3995a ("xen/device-tree: Allow region overlapping with
>> /memreserve/ ranges") introduced a type in the 'struct membanks_hdr'
>> but forgot to update the 'struct kernel_info' initialiser, while
>> it doesn't lead to failures because the field is not currently
>> used while managing kernel_info structures, it's good to have it
>> for completeness.
> The last part "good to have it" does not sound like we need a Fixes tag.

Reading the discussion, it sounds like ".type" is not always set and 
this is not properly documented. This means that in the future we may 
write a patch that requires to use ".type" and needs backported.

But this would depend on this patch which was not tagged appropriately. 
Therefore, I would argue it needs a fixes tag (even though this is a 
latent bug) or at least a backport request.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Dec 23 10:43:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Dec 2024 10:43:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862824.1274356 (Exim 4.92)
	(envelope-from )
	id 1tPftr-0000rc-Th; Mon, 23 Dec 2024 10:42:59 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862824.1274356; Mon, 23 Dec 2024 10:42: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 1tPftr-0000rV-QO; Mon, 23 Dec 2024 10:42:59 +0000
Received: by outflank-mailman (input) for mailman id 862824;
 Mon, 23 Dec 2024 10:42: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 1tPftp-0000rL-Ij
 for xen-devel@lists.xenproject.org; Mon, 23 Dec 2024 10:42:57 +0000
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
 (mail-dm6nam12on20626.outbound.protection.outlook.com
 [2a01:111:f403:2417::626])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a6398778-c11a-11ef-99a3-01e77a169b0f;
 Mon, 23 Dec 2024 11:42:48 +0100 (CET)
Received: from PH0PR07CA0074.namprd07.prod.outlook.com (2603:10b6:510:f::19)
 by CH3PR12MB9432.namprd12.prod.outlook.com (2603:10b6:610:1c7::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.20; Mon, 23 Dec
 2024 10:42:40 +0000
Received: from CY4PEPF0000EE35.namprd05.prod.outlook.com
 (2603:10b6:510:f:cafe::56) by PH0PR07CA0074.outlook.office365.com
 (2603:10b6:510:f::19) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8272.20 via Frontend Transport; Mon,
 23 Dec 2024 10:42:40 +0000
Received: from SATLEXMB04.amd.com (165.204.84.17) by
 CY4PEPF0000EE35.mail.protection.outlook.com (10.167.242.41) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8293.12 via Frontend Transport; Mon, 23 Dec 2024 10:42:39 +0000
Received: from SATLEXMB05.amd.com (10.181.40.146) 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; Mon, 23 Dec
 2024 04:42:38 -0600
Received: from SATLEXMB04.amd.com (10.181.40.145) by SATLEXMB05.amd.com
 (10.181.40.146) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 23 Dec
 2024 04:42:38 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB04.amd.com
 (10.181.40.145) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 23 Dec 2024 04:42:37 -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: a6398778-c11a-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=IW9a9yk8V3GWkD7OQHYH9QUol9Ea5R3zHaYPMXvbqQ0rP/5z4MSkQztGsGm+rdjw+n9Ez95FX2CMPvXibdo8B2hwRg6Awn3jegbgXIQ4ycZ56j4phYjGhRCm0SCubxFbjQq+2TZPYnk+lXuP9Vc5UAn43v97K4LXO9orwKU3KSPbVQVcsQTL8Or8ixCy8pD6SFkugv9dX+EyhlJhPYVpSi2g0T5eBpqYDkHjcHuiPanG4QTxmUGkXps3Oe9THokomCerpsLZQOAnuRa5cyzLbw84PXIvExYMvAhGaOhsjbGAeJudItS58NMd3hyWebvSpF8JWwYjsqQyNKIgl0b8CQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=FWkkmoCtOLjgPmIhIObeh7B6vcx3nKSdD+4LedPLgPo=;
 b=h7EgBnuxzxTaLQeC9lKUp08VaAXQ0qcbIIb+CYb05ghRXoFPhms/2VfjXotru6A0IUN4kyiaI8R/DlJv8XlnWmvzg1qQXI1VO+Qrup+e/LPhXHN+qpay4+fGLr8GuzpHhxMAnKYYwbhAGUQdXafY/UFE7U3Z7vlNgXxlRb8fli7aGW4qzMy8X2UZfnoWwt//q2PrVXJco0P/f7Q1kgl237czmnub1Wt1xQB4dH86/xid5m3EzSXVZonAtsPsKolqTs6Tyb8GDNjDQRyfNRMaASsKHnohAI2FWCCkiJ7Dwwt25NMegndFxm+oKHdsA4J5tRaQbiJ4pYODuSVWsbsw5g==
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=FWkkmoCtOLjgPmIhIObeh7B6vcx3nKSdD+4LedPLgPo=;
 b=ogRv98rF7aarWcZHCd6QD/5S11fniR/v/0dFRz8SHbbckcv55hRD41D/yL3ubqUzVNC/qDOGFV61RrRWTt7IOyxSe04JkGMn4RJIobiPl+mTHrvebXNRtiLiINOWRVFIHh9A25YB78rtmLVfmXP+4jBYkZN8lp2a19bvwa8HAQA=
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=SATLEXMB04.amd.com; pr=C
Message-ID: 
Date: Mon, 23 Dec 2024 11:42:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: Initialise memory type for struct kernel_info
To: Julien Grall , Luca Fancellu ,
	
CC: Stefano Stabellini , Bertrand Marquis
	, Volodymyr Babchuk 
References: <20241220151941.4192864-1-luca.fancellu@arm.com>
 <2a7ac358-7f43-4e32-9e1e-9ce1cd45304a@amd.com>
 
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB05.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EE35:EE_|CH3PR12MB9432:EE_
X-MS-Office365-Filtering-Correlation-Id: 65225624-1a47-45c5-1ac5-08dd233e859b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?b2plZ2MxcmwrLzY4WU16MlZtYXdWdzMvOUIvdzB1aVJ2SDJyYzJxRUUwNGlL?=
 =?utf-8?B?Tk1zOXpLQjhTRU90KzVTdElmdy83ckRiSnhyLzhGcjRmNnRRNXZxYVNvUG40?=
 =?utf-8?B?blNOZzVIU3hKb3BndEJhSlZ2YzU0WG0wTnZhSXVZSGQ3UlJxZklFSWJnemR6?=
 =?utf-8?B?Q0lEaVJvYktRcGpBL2Q3dzhJTlJicTZrSUtwRzJRS2RyTGd5M0cvSWRndTRK?=
 =?utf-8?B?M0FWczhRRE9YQmdDRDVNT091S01pdGcveXN4aThJeDEyV0V1NHZGenZRNk1q?=
 =?utf-8?B?ZzZqZGkybCtZWTd1Wjd6b2FNcGhqWWsxQkU0UXlORVBubEx2TUphK0drcFpj?=
 =?utf-8?B?aTVLSG0ySDNwdDdsSHlzTHZOZkw4YTlYb1dPL256SzVjdXUwMzYySXRwb2Vh?=
 =?utf-8?B?Qk1GTHZkMi9MWHBtM1ZiYTdyM3Y3NTB4Q0ZLb0o3amRCNW5TUXRXVWJxUTR1?=
 =?utf-8?B?N0VIMFpCelBDOWx3UmMxOHBLd0RCT3k0ejE5Y0twK2s2a2YyM0ZzYmp6VWlU?=
 =?utf-8?B?bGpTd0Y2UmdxMmZpQnlmSDZhellPNFhmTmxxSTRRTlRPMUVWVWplOE5KZHFm?=
 =?utf-8?B?THVBSTNMQTRqanpleFNyODNlS0oxck52YUdUNElZSkZXMGdXbGsvZzF4R09N?=
 =?utf-8?B?ck83cmVLMkdIdHVLYXhVVWNKZE5BRmZ0ZjExcHFoNU9zdVV0UGIweCtYbzEv?=
 =?utf-8?B?alR2NTdRTE9vSzhKUW9LSHJuQVdGVWkvOU5VZmNNWENnL1k5S1R0YzhmS3l0?=
 =?utf-8?B?eVRibXFCekg2cDZ4M2tzbC9YOFdJc0R6dnU4NHlJMnl1M1M0ZXlMbHZNSEcw?=
 =?utf-8?B?YTd6ckJTKzJLOXdOR0RqM1hzdDlwaDVYazNkU0MxUFZQYzFDMmVxOTJmeFhs?=
 =?utf-8?B?ZmpDb0lhSktwOVlVRFplQm13dzdwVTQrdW5qSWJPVHlvTzVoeThOSTlYd3Bp?=
 =?utf-8?B?MW5KVFB2ejdXYjBhdFk4VGgrZS9qM2ZkMDd0SmVKY2Y4Y1M3dDMzUHRsc3Yx?=
 =?utf-8?B?bDVKSjhqUklrczFCNHJveXNoRGtsb0xQRGhRTHl1Ry9aOEJEdnorWHV3Uk93?=
 =?utf-8?B?ZjZoUmFRZzhhV3BsSUh2V3EwbUIxWTdQOFlyZElES3h0ZG1FeDlGTGg4RDg0?=
 =?utf-8?B?RjlCOE1uaWtJUWt6NkNVNVZBVzdycHVGN1NITjRWMUVWdFpQUC85TStITVd2?=
 =?utf-8?B?N1FDRFJEdjlTMTU5Smo2QUlGaFlJUkRKWDcxQXYvUzBxbmJwckVHZU5Dd2ZK?=
 =?utf-8?B?WFE3TmtCL3UyTnlId2tmY29ZanVaUTY2cW5uZFhnZGNkWThQSCtRYjlnTXVw?=
 =?utf-8?B?OHF6QWhYU3ZWbjJ3WDYrL2JHVFB6UHh4bklBSmI2Mm1NUEtwUzZtTk50Szda?=
 =?utf-8?B?MjY3VTBWTjUwRG9mVERkOTVJZEJpWGFBcEsvRkdmS0MybnRBZzBIbWFmWjFz?=
 =?utf-8?B?RmlQRXU2ZkhlV0dPUVNPNlNZdGdWbTdSZVNIMkFMRDNMVlpWLzlwenNVeGRa?=
 =?utf-8?B?Tk1wdG9WSVUySEdzd25nSnljYUEzVTRweU5SMk1nRUNGd3NIWDNHKzltZ1Fh?=
 =?utf-8?B?UmNPN3AvRTdrRDU1STcxV1kwZitoNW9OOE1pcS9Jd3owamhMRjBHK0RqRFg3?=
 =?utf-8?B?aWVVR0laY0xDcDNSN2VyZjduRkRyS1k0Wkl4Q3J2d2IwVkJOYzVnS1Z5Qmlr?=
 =?utf-8?B?Y3ZrWStKdjl5VSs0QTFxNHpYZnVpOG5lUzMvSzAyck0rNEZTYy9GS0NRdEZy?=
 =?utf-8?B?bko2aC9vL25OMEtXa1UyLzZldDh2aVJmQmdXZ3M3aDVrOHl4UnpVbzQ4WnpH?=
 =?utf-8?B?WVBTTGZZbG1WbmxCdjFiWVR0aEpIc1hzbDVtUWNjWVFyZXcwT3FCcWZpZms4?=
 =?utf-8?B?bkk2SUp4MDJhWmpMMGgxS0VualRCbHNHeGQwRGFpK05sdGJXQlpVVUNOQlk5?=
 =?utf-8?B?cWIyWURyQVphOFptMEh6SkZOTjFXMEJhRGJsa0ZTeWVMVFRNSENvWXBOM1VB?=
 =?utf-8?Q?b4RplMX7Yx5VdRCkngFbtkCwv6shuc=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(376014)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Dec 2024 10:42:39.1395
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 65225624-1a47-45c5-1ac5-08dd233e859b
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=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CY4PEPF0000EE35.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9432



On 23/12/2024 11:06, Julien Grall wrote:
> 
> 
> Hi Michal,
> 
> On 23/12/2024 07:58, Michal Orzel wrote:
>>
>>
>> On 20/12/2024 16:19, Luca Fancellu wrote:
>>>
>>>
>>> Commit a14593e3995a ("xen/device-tree: Allow region overlapping with
>>> /memreserve/ ranges") introduced a type in the 'struct membanks_hdr'
>>> but forgot to update the 'struct kernel_info' initialiser, while
>>> it doesn't lead to failures because the field is not currently
>>> used while managing kernel_info structures, it's good to have it
>>> for completeness.
>> The last part "good to have it" does not sound like we need a Fixes tag.
> 
> Reading the discussion, it sounds like ".type" is not always set and
> this is not properly documented. This means that in the future we may
> write a patch that requires to use ".type" and needs backported.
> 
> But this would depend on this patch which was not tagged appropriately.
> Therefore, I would argue it needs a fixes tag (even though this is a
> latent bug) or at least a backport request.
Ok, sounds good. But first, let's settle on what we actually want to do here, if at all.
I would be ok with just documenting that .type field is for now only used with bootinfo
related structures (after all, today it's used only in one bootfdt function). Setting
explicitly a type for structures not requiring it, does not seem beneficial for me.

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Dec 23 10:45:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Dec 2024 10:45:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862832.1274368 (Exim 4.92)
	(envelope-from )
	id 1tPfwQ-0001Qb-AX; Mon, 23 Dec 2024 10:45:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862832.1274368; Mon, 23 Dec 2024 10:45: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 1tPfwQ-0001QU-62; Mon, 23 Dec 2024 10:45:38 +0000
Received: by outflank-mailman (input) for mailman id 862832;
 Mon, 23 Dec 2024 10:45:37 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1tPfwP-0001QM-HB
 for xen-devel@lists.xenproject.org; Mon, 23 Dec 2024 10:45:37 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1tPfwO-000Xw0-2W;
 Mon, 23 Dec 2024 10:45:37 +0000
Received: from [2a02:8012:3a1:0:ed95:e074:2d19:de59]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1tPfwO-00FJcY-2u;
 Mon, 23 Dec 2024 10:45: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" 
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=J1VyzV/Ne3aw5wEaILUlVH7egrpSzzGTxmc4mXrBQCI=; b=hhDslAD2wJL84SgwhWFGTVevc7
	X2WbFhgb8BSO5DI1RPcIUEppF7LAIYhxWz6/itsn6xTuf+ZTSR0REHFHyz1VYyd0qnFSS2WgIFuQn
	A+70FZw0hvOY6/4t3u4VjN9nsnBUNC1No4nV8sMwLGb8YOVnV82jBfyFmDhCVLDsya6o=;
Message-ID: <7b7d4606-86fe-45c1-9aa0-48ddfacabafb@xen.org>
Date: Mon, 23 Dec 2024 10:45:35 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: Initialise memory type for struct kernel_info
Content-Language: en-GB
To: Michal Orzel , Luca Fancellu
 , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20241220151941.4192864-1-luca.fancellu@arm.com>
 <2a7ac358-7f43-4e32-9e1e-9ce1cd45304a@amd.com>
 
 
From: Julien Grall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On 23/12/2024 10:42, Michal Orzel wrote:
> 
> 
> On 23/12/2024 11:06, Julien Grall wrote:
>>
>>
>> Hi Michal,
>>
>> On 23/12/2024 07:58, Michal Orzel wrote:
>>>
>>>
>>> On 20/12/2024 16:19, Luca Fancellu wrote:
>>>>
>>>>
>>>> Commit a14593e3995a ("xen/device-tree: Allow region overlapping with
>>>> /memreserve/ ranges") introduced a type in the 'struct membanks_hdr'
>>>> but forgot to update the 'struct kernel_info' initialiser, while
>>>> it doesn't lead to failures because the field is not currently
>>>> used while managing kernel_info structures, it's good to have it
>>>> for completeness.
>>> The last part "good to have it" does not sound like we need a Fixes tag.
>>
>> Reading the discussion, it sounds like ".type" is not always set and
>> this is not properly documented. This means that in the future we may
>> write a patch that requires to use ".type" and needs backported.
>>
>> But this would depend on this patch which was not tagged appropriately.
>> Therefore, I would argue it needs a fixes tag (even though this is a
>> latent bug) or at least a backport request.
> Setting explicitly a type for structures not requiring it, does not seem beneficial for me.

I have to disagree. If we set type everywhere, then the developer 
doesn't need to think whether ".type" is garbagge or not.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Mon Dec 23 10:50:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Dec 2024 10:50:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862842.1274377 (Exim 4.92)
	(envelope-from )
	id 1tPg0w-0002uo-Qz; Mon, 23 Dec 2024 10:50:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862842.1274377; Mon, 23 Dec 2024 10:50: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 1tPg0w-0002uh-Mv; Mon, 23 Dec 2024 10:50:18 +0000
Received: by outflank-mailman (input) for mailman id 862842;
 Mon, 23 Dec 2024 10:50: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 1tPg0v-0002uZ-Mr
 for xen-devel@lists.xenproject.org; Mon, 23 Dec 2024 10:50:18 +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 b16a45d1-c11b-11ef-a0da-8be0dac302b0;
 Mon, 23 Dec 2024 11:50:15 +0100 (CET)
Received: by mail-lj1-x235.google.com with SMTP id
 38308e7fff4ca-30039432861so43719351fa.2
 for ; Mon, 23 Dec 2024 02:50:15 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-542238135eesm1230276e87.120.2024.12.23.02.50.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Dec 2024 02:50: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: b16a45d1-c11b-11ef-a0da-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734951015; x=1735555815; darn=lists.xenproject.org;
        h=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=arWpeCYRiTBZbA6/WIfe1Q8rShHREAowQyDyV1as3EU=;
        b=d5C/KgCKiWoMdcA0XqgmauT/4PjBDki6WRzfBgq5MVWU8qs07bPwaTxt7w5j/gTTmr
         DkoSakfczpxWbpATPZAQvwtLII7S4gswLbPYE3ZIITpvnlHLmpJOy1Vcwwt2eLaO3cTr
         pGwQRR1eSnfqvIXBiT2MUOJJHOxo+XZY1XFKQ9rQbONnkLCCIXiFvI748FNgwJpyx05M
         EORXgRf1Bhtkxt/ntbWQsX0XpneiM5reAx37LaJ5kTPG/CMQL73fA9J92WWOfV+s2ARP
         GzYbXGYnBN6vnLrEgyBpZLEe0CnDfeem11oKhZASTLoFTv4LwAahnISPZNCpkNayTLHd
         szuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734951015; x=1735555815;
        h=in-reply-to:from:content-language:references:cc:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=arWpeCYRiTBZbA6/WIfe1Q8rShHREAowQyDyV1as3EU=;
        b=fFCySpo6hfgjDAk+dHKwPOrFSOnvpBPqjR6wnHOtdSry73NEfr4CBToad8sLc3RSlQ
         X0q1KBGXCLfT/ZKmvqDxpP1W/L9vrk2X9DqATwwpxmDMM92pPIfIiVUrIQ1LxTHn0eM2
         3yLX23toudER6eALHJ1KN7T9vC+802rvMipQTeXibAVN3nIGNUCmZ5Lc7cgiOmYkPp6y
         KAD/e8HAYythmhocRz4tvUWVNkemaexxQBIS6RPI/RwH866tyHv2t1ZfBqkRvjlU/KWa
         jVus+S1MPHbeRZIXLZ2S191aDatD+fyDy/kuLBTmfzZlFJeRxwShGgD+luxUiHAD2e4R
         XSpQ==
X-Forwarded-Encrypted: i=1; AJvYcCXfEfE4qtHXa+CfhQ1IVdw/6qfN1zIGVm8wIA+ygKA3mc+sgYb9d8qs0LqqVlnHNEOkbxoY6ixAR/s=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzdCUUdRetfovPKhDUpgCqN5X9u55R1BfTg655uuoqF+CMVQ7vq
	I7BNKYIDb8WSCKy7Z9fDripUDQKldTGJIrekSf/SEHEntyEdlI9h
X-Gm-Gg: ASbGncvqaVDZAv8B/XbTzArg7276/iBVb0s2TQVSvLDiED9TwunmEEPuGS9maXTYjkx
	+sozl9e0I5zUeIb283stWUtyw9SUQ+Vl8XaLCQtK8xEcmr5QzkVQ+HSM4r6DP5X35i/VmtZQ1PR
	ZzFfvap9DdVbnZxfVCki3dH6oxgt5c0ufaX40NFxPVg1ngJBs/ADDAkvNmumSsBV+mjI22htrUV
	ujvz834zmuKBycEeuIBlM6epC54ctkUfB+33akVqEJH/ODb3mgdtEfo3ApJ1grGAjfYKQ==
X-Google-Smtp-Source: AGHT+IEfg9BAyUXfantrm6AReCkTp1VsrAJuPshDPGQNZAq02K7cZGZzmEleIFnGVNoNNC11e0/W6Q==
X-Received: by 2002:ac2:4c48:0:b0:540:3579:f38f with SMTP id 2adb3069b0e04-542295821afmr4426567e87.37.1734951014780;
        Mon, 23 Dec 2024 02:50:14 -0800 (PST)
Content-Type: multipart/alternative;
 boundary="------------mMaUl8IcN65lWTAF9JtD7nl4"
Message-ID: 
Date: Mon, 23 Dec 2024 11:50:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] x86/spec-ctrl: Support for SRSO_U/S_NO and
 SRSO_MSR_FIX
To: Andrew Cooper ,
 Xen-devel 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Jan Beulich 
References: <20241220193424.470994-1-andrew.cooper3@citrix.com>
Content-Language: en-US
From: Oleksii Kurochko 
In-Reply-To: <20241220193424.470994-1-andrew.cooper3@citrix.com>

This is a multi-part message in MIME format.
--------------mMaUl8IcN65lWTAF9JtD7nl4
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 12/20/24 8:34 PM, Andrew Cooper wrote:
> AMD have updated the SRSO whitepaper[1] with further information.  These
> features exist on AMD Zen5 CPUs and are necessary for Xen to use.
>
> The two features are in principle unrelated:
>
>   * SRSO_U/S_NO is an enumeration saying that SRSO attacks can't cross the
>     User(CPL3) / Supervisor(CPL<3) boundary.  i.e. Xen don't need to use
>     IBPB-on-entry for PV64.  PV32 guests are explicitly unsupported for
>     speculative issues, and excluded from consideration for simplicity.
>
>   * SRSO_MSR_FIX is an enumeration identifying that the BP_SPEC_REDUCE bit is
>     available in MSR_BP_CFG.  When set, SRSO attacks can't cross the host/guest
>     boundary.  i.e. Xen don't need to use IBPB-on-entry for HVM.
>
> Extend ibpb_calculations() to account for these when calculating
> opt_ibpb_entry_{pv,hvm} defaults.  Add a `bp-spec-reduce=` option to
> control the use of BP_SPEC_REDUCE, with it active by default.
>
> Because MSR_BP_CFG is core-scoped with a race condition updating it, repurpose
> amd_check_erratum_1485() into amd_check_bp_cfg() and calculate all updates at
> once.
>
> Xen also needs to to advertise SRSO_U/S_NO to guests to allow the guest kernel
> to skip SRSO mitigations too:
>
>   * This is trivial for HVM guests.  It is also is accurate for PV32 guests
>     too, but we have already excluded them from consideration, and do so again
>     here to simplify the policy logic.
>
>   * As written, SRSO_U/S_NO does not help for the PV64 user->kernel boundary.
>     However, after discussing with AMD, an implementation detail of having
>     BP_SPEC_REDUCE active causes the PV64 user->kernel boundary to have the
>     property described by SRSO_U/S_NO, so we can advertise SRSO_U/S_NO to
>     guests when the BP_SPEC_REDUCE precondition is met.
>
> Finally, fix a typo in the SRSO_NO's comment.
>
> [1]https://www.amd.com/content/dam/amd/en/documents/corporate/cr/speculative-return-stack-overflow-whitepaper.pdf
> Signed-off-by: Andrew Cooper
> Reviewed-by: Roger Pau Monné
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Oleksii Kurochko
>
> I cannot say anything more about the SRSO_U/S_NO vs SRSO_MSR_FIX interactions
> in public.  The safety for PV guests depends on details not covered in the
> whitepaper.
>
> v3:
>   * Rewrite commit message and comments quite a lot.
>
> This patch was originally for-4.19.  Zen5 CPUs are now in the world and Xen is
> unsafe on them without this patch.
>
> I technically have enough tags to commit it, and it's long overdue, but I
> think it would be wise to see if the new wording is clearer to others.
> ---

I am not x86 expert but wording looks clear for me.

Shouldn't we mentioned in CHANGELOG support for SRSO_U/S_NO and SRSO_MSR_FIX is added to deal

with speculative return stack overflow vulnerability?

~ Oleksii

>   docs/misc/xen-command-line.pandoc           |  9 +++-
>   xen/arch/x86/cpu-policy.c                   | 21 +++++++++
>   xen/arch/x86/cpu/amd.c                      | 29 +++++++++---
>   xen/arch/x86/include/asm/msr-index.h        |  1 +
>   xen/arch/x86/include/asm/spec_ctrl.h        |  1 +
>   xen/arch/x86/spec_ctrl.c                    | 51 ++++++++++++++++-----
>   xen/include/public/arch-x86/cpufeatureset.h |  4 +-
>   7 files changed, 96 insertions(+), 20 deletions(-)
>
> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
> index 1dd8f714d3a2..08b0053f9ced 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -2456,7 +2456,7 @@ By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
>   >              {ibrs,ibpb,ssbd,psfd,
>   >              eager-fpu,l1d-flush,branch-harden,srb-lock,
>   >              unpriv-mmio,gds-mit,div-scrub,lock-harden,
> ->              bhi-dis-s}= ]`
> +>              bhi-dis-s,bp-spec-reduce}= ]`
>   
>   Controls for speculative execution sidechannel mitigations.  By default, Xen
>   will pick the most appropriate mitigations based on compiled in support,
> @@ -2605,6 +2605,13 @@ boolean can be used to force or prevent Xen from using speculation barriers to
>   protect lock critical regions.  This mitigation won't be engaged by default,
>   and needs to be explicitly enabled on the command line.
>   
> +On hardware supporting SRSO_MSR_FIX, the `bp-spec-reduce=` option can be used
> +to force or prevent Xen from using MSR_BP_CFG.BP_SPEC_REDUCE to mitigate the
> +SRSO (Speculative Return Stack Overflow) vulnerability.  Xen will use
> +bp-spec-reduce when available, as it is preferable to using `ibpb-entry=hvm`
> +to mitigate SRSO for HVM guests, and because it is a prerequisite to advertise
> +SRSO_U/S_NO to PV guests.
> +
>   ### sync_console
>   > `= `
>   
> diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c
> index 78bc9872b09a..2e8a5ecb5e7b 100644
> --- a/xen/arch/x86/cpu-policy.c
> +++ b/xen/arch/x86/cpu-policy.c
> @@ -14,6 +14,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   #include 
>   
>   struct cpu_policy __read_mostly       raw_cpu_policy;
> @@ -625,6 +626,26 @@ static void __init calculate_pv_max_policy(void)
>           __clear_bit(X86_FEATURE_IBRS, fs);
>       }
>   
> +    /*
> +     * SRSO_U/S_NO means that the CPU is not vulnerable to SRSO attacks across
> +     * the User (CPL3)/Supervisor (CPL<3) boundary.
> +     *
> +     * PV32 guests are unsupported for speculative issues, and excluded from
> +     * consideration for simplicity.
> +     *
> +     * The PV64 user/kernel boundary is CPL3 on both sides, so SRSO_U/S_NO
> +     * won't convey the meaning that a PV kernel expects.
> +     *
> +     * After discussions with AMD, an implementation detail of having
> +     * BP_SPEC_REDUCE active causes the PV64 user/kernel boundary to have a
> +     * property compatible with the meaning of SRSO_U/S_NO.
> +     *
> +     * If BP_SPEC_REDUCE isn't active, remove SRSO_U/S_NO from the PV max
> +     * policy, which will cause it to filter out of PV default too.
> +     */
> +    if ( !boot_cpu_has(X86_FEATURE_SRSO_MSR_FIX) || !opt_bp_spec_reduce )
> +        __clear_bit(X86_FEATURE_SRSO_US_NO, fs);
> +
>       guest_common_max_feature_adjustments(fs);
>       guest_common_feature_adjustments(fs);
>   
> diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
> index 7da04230393a..597b0f073d55 100644
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -1009,16 +1009,33 @@ static void cf_check fam17_disable_c6(void *arg)
>   	wrmsrl(MSR_AMD_CSTATE_CFG, val & mask);
>   }
>   
> -static void amd_check_erratum_1485(void)
> +static void amd_check_bp_cfg(void)
>   {
> -	uint64_t val, chickenbit = (1 << 5);
> +	uint64_t val, new = 0;
>   
> -	if (cpu_has_hypervisor || boot_cpu_data.x86 != 0x19 || !is_zen4_uarch())
> +	/*
> +	 * AMD Erratum #1485.  Set bit 5, as instructed.
> +	 */
> +	if (!cpu_has_hypervisor && boot_cpu_data.x86 == 0x19 && is_zen4_uarch())
> +		new |= (1 << 5);
> +
> +	/*
> +	 * On hardware supporting SRSO_MSR_FIX, activate BP_SPEC_REDUCE by
> +	 * default.  This lets us do two things:
> +	 *
> +	 * 1) Avoid IBPB-on-entry to mitigate SRSO attacks from HVM guests.
> +	 * 2) Advertise SRSO_US_NO to PV guests.
> +	 */
> +	if (boot_cpu_has(X86_FEATURE_SRSO_MSR_FIX) && opt_bp_spec_reduce)
> +		new |= BP_CFG_SPEC_REDUCE;
> +
> +	/* Avoid reading BP_CFG if we don't intend to change anything. */
> +	if (!new)
>   		return;
>   
>   	rdmsrl(MSR_AMD64_BP_CFG, val);
>   
> -	if (val & chickenbit)
> +	if ((val & new) == new)
>   		return;
>   
>   	/*
> @@ -1027,7 +1044,7 @@ static void amd_check_erratum_1485(void)
>   	 * same time before the chickenbit is set. It's benign because the
>   	 * value being written is the same on both.
>   	 */
> -	wrmsrl(MSR_AMD64_BP_CFG, val | chickenbit);
> +	wrmsrl(MSR_AMD64_BP_CFG, val | new);
>   }
>   
>   static void cf_check init_amd(struct cpuinfo_x86 *c)
> @@ -1297,7 +1314,7 @@ static void cf_check init_amd(struct cpuinfo_x86 *c)
>   		disable_c1_ramping();
>   
>   	amd_check_zenbleed();
> -	amd_check_erratum_1485();
> +	amd_check_bp_cfg();
>   
>   	if (fam17_c6_disabled)
>   		fam17_disable_c6(NULL);
> diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
> index 9cdb5b262566..22d9e76e5521 100644
> --- a/xen/arch/x86/include/asm/msr-index.h
> +++ b/xen/arch/x86/include/asm/msr-index.h
> @@ -412,6 +412,7 @@
>   #define AMD64_DE_CFG_LFENCE_SERIALISE	(_AC(1, ULL) << 1)
>   #define MSR_AMD64_EX_CFG		0xc001102cU
>   #define MSR_AMD64_BP_CFG		0xc001102eU
> +#define  BP_CFG_SPEC_REDUCE		(_AC(1, ULL) <<  4)
>   #define MSR_AMD64_DE_CFG2		0xc00110e3U
>   
>   #define MSR_AMD64_DR0_ADDRESS_MASK	0xc0011027U
> diff --git a/xen/arch/x86/include/asm/spec_ctrl.h b/xen/arch/x86/include/asm/spec_ctrl.h
> index 72347ef2b959..077225418956 100644
> --- a/xen/arch/x86/include/asm/spec_ctrl.h
> +++ b/xen/arch/x86/include/asm/spec_ctrl.h
> @@ -90,6 +90,7 @@ extern int8_t opt_xpti_hwdom, opt_xpti_domu;
>   
>   extern bool cpu_has_bug_l1tf;
>   extern int8_t opt_pv_l1tf_hwdom, opt_pv_l1tf_domu;
> +extern bool opt_bp_spec_reduce;
>   
>   /*
>    * The L1D address mask, which might be wider than reported in CPUID, and the
> diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
> index 75a4177a75d2..ced84750015c 100644
> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
> @@ -83,6 +83,7 @@ static bool __initdata opt_unpriv_mmio;
>   static bool __ro_after_init opt_verw_mmio;
>   static int8_t __initdata opt_gds_mit = -1;
>   static int8_t __initdata opt_div_scrub = -1;
> +bool __ro_after_init opt_bp_spec_reduce = true;
>   
>   static int __init cf_check parse_spec_ctrl(const char *s)
>   {
> @@ -145,6 +146,7 @@ static int __init cf_check parse_spec_ctrl(const char *s)
>               opt_unpriv_mmio = false;
>               opt_gds_mit = 0;
>               opt_div_scrub = 0;
> +            opt_bp_spec_reduce = false;
>           }
>           else if ( val > 0 )
>               rc = -EINVAL;
> @@ -365,6 +367,8 @@ static int __init cf_check parse_spec_ctrl(const char *s)
>               opt_gds_mit = val;
>           else if ( (val = parse_boolean("div-scrub", s, ss)) >= 0 )
>               opt_div_scrub = val;
> +        else if ( (val = parse_boolean("bp-spec-reduce", s, ss)) >= 0 )
> +            opt_bp_spec_reduce = val;
>           else
>               rc = -EINVAL;
>   
> @@ -507,7 +511,7 @@ static void __init print_details(enum ind_thunk thunk)
>        * Hardware read-only information, stating immunity to certain issues, or
>        * suggestions of which mitigation to use.
>        */
> -    printk("  Hardware hints:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
> +    printk("  Hardware hints:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
>              (caps & ARCH_CAPS_RDCL_NO)                        ? " RDCL_NO"        : "",
>              (caps & ARCH_CAPS_EIBRS)                          ? " EIBRS"          : "",
>              (caps & ARCH_CAPS_RSBA)                           ? " RSBA"           : "",
> @@ -531,10 +535,11 @@ static void __init print_details(enum ind_thunk thunk)
>              (e8b  & cpufeat_mask(X86_FEATURE_BTC_NO))         ? " BTC_NO"         : "",
>              (e8b  & cpufeat_mask(X86_FEATURE_IBPB_RET))       ? " IBPB_RET"       : "",
>              (e21a & cpufeat_mask(X86_FEATURE_IBPB_BRTYPE))    ? " IBPB_BRTYPE"    : "",
> -           (e21a & cpufeat_mask(X86_FEATURE_SRSO_NO))        ? " SRSO_NO"        : "");
> +           (e21a & cpufeat_mask(X86_FEATURE_SRSO_NO))        ? " SRSO_NO"        : "",
> +           (e21a & cpufeat_mask(X86_FEATURE_SRSO_US_NO))     ? " SRSO_US_NO"     : "");
>   
>       /* Hardware features which need driving to mitigate issues. */
> -    printk("  Hardware features:%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
> +    printk("  Hardware features:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
>              (e8b  & cpufeat_mask(X86_FEATURE_IBPB)) ||
>              (_7d0 & cpufeat_mask(X86_FEATURE_IBRSB))          ? " IBPB"           : "",
>              (e8b  & cpufeat_mask(X86_FEATURE_IBRS)) ||
> @@ -553,7 +558,8 @@ static void __init print_details(enum ind_thunk thunk)
>              (caps & ARCH_CAPS_FB_CLEAR_CTRL)                  ? " FB_CLEAR_CTRL"  : "",
>              (caps & ARCH_CAPS_GDS_CTRL)                       ? " GDS_CTRL"       : "",
>              (caps & ARCH_CAPS_RFDS_CLEAR)                     ? " RFDS_CLEAR"     : "",
> -           (e21a & cpufeat_mask(X86_FEATURE_SBPB))           ? " SBPB"           : "");
> +           (e21a & cpufeat_mask(X86_FEATURE_SBPB))           ? " SBPB"           : "",
> +           (e21a & cpufeat_mask(X86_FEATURE_SRSO_MSR_FIX))   ? " SRSO_MSR_FIX"   : "");
>   
>       /* Compiled-in support which pertains to mitigations. */
>       if ( IS_ENABLED(CONFIG_INDIRECT_THUNK) || IS_ENABLED(CONFIG_SHADOW_PAGING) ||
> @@ -1113,7 +1119,7 @@ static void __init div_calculations(bool hw_smt_enabled)
>   
>   static void __init ibpb_calculations(void)
>   {
> -    bool def_ibpb_entry = false;
> +    bool def_ibpb_entry_pv = false, def_ibpb_entry_hvm = false;
>   
>       /* Check we have hardware IBPB support before using it... */
>       if ( !boot_cpu_has(X86_FEATURE_IBRSB) && !boot_cpu_has(X86_FEATURE_IBPB) )
> @@ -1138,22 +1144,43 @@ static void __init ibpb_calculations(void)
>            * Confusion.  Mitigate with IBPB-on-entry.
>            */
>           if ( !boot_cpu_has(X86_FEATURE_BTC_NO) )
> -            def_ibpb_entry = true;
> +            def_ibpb_entry_pv = def_ibpb_entry_hvm = true;
>   
>           /*
> -         * Further to BTC, Zen3/4 CPUs suffer from Speculative Return Stack
> -         * Overflow in most configurations.  Mitigate with IBPB-on-entry if we
> -         * have the microcode that makes this an effective option.
> +         * In addition to BTC, Zen3 and later CPUs suffer from Speculative
> +         * Return Stack Overflow in most configurations.  If we have microcode
> +         * that makes IBPB-on-entry an effective mitigation, see about using
> +         * it.
>            */
>           if ( !boot_cpu_has(X86_FEATURE_SRSO_NO) &&
>                boot_cpu_has(X86_FEATURE_IBPB_BRTYPE) )
> -            def_ibpb_entry = true;
> +        {
> +            /*
> +             * SRSO_U/S_NO is a subset of SRSO_NO, identifying that SRSO isn't
> +             * possible across the User (CPL3) / Supervisor (CPL<3) boundary.
> +             *
> +             * Ignoring PV32 (not security supported for speculative issues),
> +             * this means we only need to use IBPB-on-entry for PV guests on
> +             * hardware which doesn't enumerate SRSO_US_NO.
> +             */
> +            if ( !boot_cpu_has(X86_FEATURE_SRSO_US_NO) )
> +                def_ibpb_entry_pv = true;
> +
> +            /*
> +             * SRSO_MSR_FIX enumerates that we can use MSR_BP_CFG.SPEC_REDUCE
> +             * to mitigate SRSO across the host/guest boundary.  We only need
> +             * to use IBPB-on-entry for HVM guests if we haven't enabled this
> +             * control.
> +             */
> +            if ( !boot_cpu_has(X86_FEATURE_SRSO_MSR_FIX) || !opt_bp_spec_reduce )
> +                def_ibpb_entry_hvm = true;
> +        }
>       }
>   
>       if ( opt_ibpb_entry_pv == -1 )
> -        opt_ibpb_entry_pv = IS_ENABLED(CONFIG_PV) && def_ibpb_entry;
> +        opt_ibpb_entry_pv = IS_ENABLED(CONFIG_PV) && def_ibpb_entry_pv;
>       if ( opt_ibpb_entry_hvm == -1 )
> -        opt_ibpb_entry_hvm = IS_ENABLED(CONFIG_HVM) && def_ibpb_entry;
> +        opt_ibpb_entry_hvm = IS_ENABLED(CONFIG_HVM) && def_ibpb_entry_hvm;
>   
>       if ( opt_ibpb_entry_pv )
>       {
> diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h
> index 8fa3fb711a8d..16207e3817bb 100644
> --- a/xen/include/public/arch-x86/cpufeatureset.h
> +++ b/xen/include/public/arch-x86/cpufeatureset.h
> @@ -325,7 +325,9 @@ XEN_CPUFEATURE(FSRSC,              11*32+19) /*A  Fast Short REP SCASB */
>   XEN_CPUFEATURE(AMD_PREFETCHI,      11*32+20) /*A  PREFETCHIT{0,1} Instructions */
>   XEN_CPUFEATURE(SBPB,               11*32+27) /*A  Selective Branch Predictor Barrier */
>   XEN_CPUFEATURE(IBPB_BRTYPE,        11*32+28) /*A  IBPB flushes Branch Type predictions too */
> -XEN_CPUFEATURE(SRSO_NO,            11*32+29) /*A  Hardware not vulenrable to Speculative Return Stack Overflow */
> +XEN_CPUFEATURE(SRSO_NO,            11*32+29) /*A  Hardware not vulnerable to Speculative Return Stack Overflow */
> +XEN_CPUFEATURE(SRSO_US_NO,         11*32+30) /*A! Hardware not vulnerable to SRSO across the User/Supervisor boundary */
> +XEN_CPUFEATURE(SRSO_MSR_FIX,       11*32+31) /*   MSR_BP_CFG.BP_SPEC_REDUCE available */
>   
>   /* Intel-defined CPU features, CPUID level 0x00000007:1.ebx, word 12 */
>   XEN_CPUFEATURE(INTEL_PPIN,         12*32+ 0) /*   Protected Processor Inventory Number */
--------------mMaUl8IcN65lWTAF9JtD7nl4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    


    

    
On 12/20/24 8:34 PM, Andrew Cooper
      wrote:

    

    

      
AMD have updated the SRSO whitepaper[1] with further information.  These
features exist on AMD Zen5 CPUs and are necessary for Xen to use.

The two features are in principle unrelated:

 * SRSO_U/S_NO is an enumeration saying that SRSO attacks can't cross the
   User(CPL3) / Supervisor(CPL<3) boundary.  i.e. Xen don't need to use
   IBPB-on-entry for PV64.  PV32 guests are explicitly unsupported for
   speculative issues, and excluded from consideration for simplicity.

 * SRSO_MSR_FIX is an enumeration identifying that the BP_SPEC_REDUCE bit is
   available in MSR_BP_CFG.  When set, SRSO attacks can't cross the host/guest
   boundary.  i.e. Xen don't need to use IBPB-on-entry for HVM.

Extend ibpb_calculations() to account for these when calculating
opt_ibpb_entry_{pv,hvm} defaults.  Add a `bp-spec-reduce=<bool>` option to
control the use of BP_SPEC_REDUCE, with it active by default.

Because MSR_BP_CFG is core-scoped with a race condition updating it, repurpose
amd_check_erratum_1485() into amd_check_bp_cfg() and calculate all updates at
once.

Xen also needs to to advertise SRSO_U/S_NO to guests to allow the guest kernel
to skip SRSO mitigations too:

 * This is trivial for HVM guests.  It is also is accurate for PV32 guests
   too, but we have already excluded them from consideration, and do so again
   here to simplify the policy logic.

 * As written, SRSO_U/S_NO does not help for the PV64 user->kernel boundary.
   However, after discussing with AMD, an implementation detail of having
   BP_SPEC_REDUCE active causes the PV64 user->kernel boundary to have the
   property described by SRSO_U/S_NO, so we can advertise SRSO_U/S_NO to
   guests when the BP_SPEC_REDUCE precondition is met.

Finally, fix a typo in the SRSO_NO's comment.

[1] https://www.amd.com/content/dam/amd/en/documents/corporate/cr/speculative-return-stack-overflow-whitepaper.pdf
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>

I cannot say anything more about the SRSO_U/S_NO vs SRSO_MSR_FIX interactions
in public.  The safety for PV guests depends on details not covered in the
whitepaper.

v3:
 * Rewrite commit message and comments quite a lot.

This patch was originally for-4.19.  Zen5 CPUs are now in the world and Xen is
unsafe on them without this patch.

I technically have enough tags to commit it, and it's long overdue, but I
think it would be wise to see if the new wording is clearer to others.
---

    

    
I am not x86 expert but wording looks clear for me.


    

    
Shouldn't we mentioned in CHANGELOG support for SRSO_U/S_NO and SRSO_MSR_FIX is added to deal

    
with speculative return stack overflow vulnerability?

    

    
~ Oleksii


    

      
 docs/misc/xen-command-line.pandoc           |  9 +++-
 xen/arch/x86/cpu-policy.c                   | 21 +++++++++
 xen/arch/x86/cpu/amd.c                      | 29 +++++++++---
 xen/arch/x86/include/asm/msr-index.h        |  1 +
 xen/arch/x86/include/asm/spec_ctrl.h        |  1 +
 xen/arch/x86/spec_ctrl.c                    | 51 ++++++++++++++++-----
 xen/include/public/arch-x86/cpufeatureset.h |  4 +-
 7 files changed, 96 insertions(+), 20 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 1dd8f714d3a2..08b0053f9ced 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2456,7 +2456,7 @@ By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
 >              {ibrs,ibpb,ssbd,psfd,
 >              eager-fpu,l1d-flush,branch-harden,srb-lock,
 >              unpriv-mmio,gds-mit,div-scrub,lock-harden,
->              bhi-dis-s}=<bool> ]`
+>              bhi-dis-s,bp-spec-reduce}=<bool> ]`
 
 Controls for speculative execution sidechannel mitigations.  By default, Xen
 will pick the most appropriate mitigations based on compiled in support,
@@ -2605,6 +2605,13 @@ boolean can be used to force or prevent Xen from using speculation barriers to
 protect lock critical regions.  This mitigation won't be engaged by default,
 and needs to be explicitly enabled on the command line.
 
+On hardware supporting SRSO_MSR_FIX, the `bp-spec-reduce=` option can be used
+to force or prevent Xen from using MSR_BP_CFG.BP_SPEC_REDUCE to mitigate the
+SRSO (Speculative Return Stack Overflow) vulnerability.  Xen will use
+bp-spec-reduce when available, as it is preferable to using `ibpb-entry=hvm`
+to mitigate SRSO for HVM guests, and because it is a prerequisite to advertise
+SRSO_U/S_NO to PV guests.
+
 ### sync_console
 > `= <boolean>`
 
diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c
index 78bc9872b09a..2e8a5ecb5e7b 100644
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -14,6 +14,7 @@
 #include <asm/msr-index.h>
 #include <asm/paging.h>
 #include <asm/setup.h>
+#include <asm/spec_ctrl.h>
 #include <asm/xstate.h>
 
 struct cpu_policy __read_mostly       raw_cpu_policy;
@@ -625,6 +626,26 @@ static void __init calculate_pv_max_policy(void)
         __clear_bit(X86_FEATURE_IBRS, fs);
     }
 
+    /*
+     * SRSO_U/S_NO means that the CPU is not vulnerable to SRSO attacks across
+     * the User (CPL3)/Supervisor (CPL<3) boundary.
+     *
+     * PV32 guests are unsupported for speculative issues, and excluded from
+     * consideration for simplicity.
+     *
+     * The PV64 user/kernel boundary is CPL3 on both sides, so SRSO_U/S_NO
+     * won't convey the meaning that a PV kernel expects.
+     *
+     * After discussions with AMD, an implementation detail of having
+     * BP_SPEC_REDUCE active causes the PV64 user/kernel boundary to have a
+     * property compatible with the meaning of SRSO_U/S_NO.
+     *
+     * If BP_SPEC_REDUCE isn't active, remove SRSO_U/S_NO from the PV max
+     * policy, which will cause it to filter out of PV default too.
+     */
+    if ( !boot_cpu_has(X86_FEATURE_SRSO_MSR_FIX) || !opt_bp_spec_reduce )
+        __clear_bit(X86_FEATURE_SRSO_US_NO, fs);
+
     guest_common_max_feature_adjustments(fs);
     guest_common_feature_adjustments(fs);
 
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 7da04230393a..597b0f073d55 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -1009,16 +1009,33 @@ static void cf_check fam17_disable_c6(void *arg)
 	wrmsrl(MSR_AMD_CSTATE_CFG, val & mask);
 }
 
-static void amd_check_erratum_1485(void)
+static void amd_check_bp_cfg(void)
 {
-	uint64_t val, chickenbit = (1 << 5);
+	uint64_t val, new = 0;
 
-	if (cpu_has_hypervisor || boot_cpu_data.x86 != 0x19 || !is_zen4_uarch())
+	/*
+	 * AMD Erratum #1485.  Set bit 5, as instructed.
+	 */
+	if (!cpu_has_hypervisor && boot_cpu_data.x86 == 0x19 && is_zen4_uarch())
+		new |= (1 << 5);
+
+	/*
+	 * On hardware supporting SRSO_MSR_FIX, activate BP_SPEC_REDUCE by
+	 * default.  This lets us do two things:
+	 *
+	 * 1) Avoid IBPB-on-entry to mitigate SRSO attacks from HVM guests.
+	 * 2) Advertise SRSO_US_NO to PV guests.
+	 */
+	if (boot_cpu_has(X86_FEATURE_SRSO_MSR_FIX) && opt_bp_spec_reduce)
+		new |= BP_CFG_SPEC_REDUCE;
+
+	/* Avoid reading BP_CFG if we don't intend to change anything. */
+	if (!new)
 		return;
 
 	rdmsrl(MSR_AMD64_BP_CFG, val);
 
-	if (val & chickenbit)
+	if ((val & new) == new)
 		return;
 
 	/*
@@ -1027,7 +1044,7 @@ static void amd_check_erratum_1485(void)
 	 * same time before the chickenbit is set. It's benign because the
 	 * value being written is the same on both.
 	 */
-	wrmsrl(MSR_AMD64_BP_CFG, val | chickenbit);
+	wrmsrl(MSR_AMD64_BP_CFG, val | new);
 }
 
 static void cf_check init_amd(struct cpuinfo_x86 *c)
@@ -1297,7 +1314,7 @@ static void cf_check init_amd(struct cpuinfo_x86 *c)
 		disable_c1_ramping();
 
 	amd_check_zenbleed();
-	amd_check_erratum_1485();
+	amd_check_bp_cfg();
 
 	if (fam17_c6_disabled)
 		fam17_disable_c6(NULL);
diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
index 9cdb5b262566..22d9e76e5521 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -412,6 +412,7 @@
 #define AMD64_DE_CFG_LFENCE_SERIALISE	(_AC(1, ULL) << 1)
 #define MSR_AMD64_EX_CFG		0xc001102cU
 #define MSR_AMD64_BP_CFG		0xc001102eU
+#define  BP_CFG_SPEC_REDUCE		(_AC(1, ULL) <<  4)
 #define MSR_AMD64_DE_CFG2		0xc00110e3U
 
 #define MSR_AMD64_DR0_ADDRESS_MASK	0xc0011027U
diff --git a/xen/arch/x86/include/asm/spec_ctrl.h b/xen/arch/x86/include/asm/spec_ctrl.h
index 72347ef2b959..077225418956 100644
--- a/xen/arch/x86/include/asm/spec_ctrl.h
+++ b/xen/arch/x86/include/asm/spec_ctrl.h
@@ -90,6 +90,7 @@ extern int8_t opt_xpti_hwdom, opt_xpti_domu;
 
 extern bool cpu_has_bug_l1tf;
 extern int8_t opt_pv_l1tf_hwdom, opt_pv_l1tf_domu;
+extern bool opt_bp_spec_reduce;
 
 /*
  * The L1D address mask, which might be wider than reported in CPUID, and the
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 75a4177a75d2..ced84750015c 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -83,6 +83,7 @@ static bool __initdata opt_unpriv_mmio;
 static bool __ro_after_init opt_verw_mmio;
 static int8_t __initdata opt_gds_mit = -1;
 static int8_t __initdata opt_div_scrub = -1;
+bool __ro_after_init opt_bp_spec_reduce = true;
 
 static int __init cf_check parse_spec_ctrl(const char *s)
 {
@@ -145,6 +146,7 @@ static int __init cf_check parse_spec_ctrl(const char *s)
             opt_unpriv_mmio = false;
             opt_gds_mit = 0;
             opt_div_scrub = 0;
+            opt_bp_spec_reduce = false;
         }
         else if ( val > 0 )
             rc = -EINVAL;
@@ -365,6 +367,8 @@ static int __init cf_check parse_spec_ctrl(const char *s)
             opt_gds_mit = val;
         else if ( (val = parse_boolean("div-scrub", s, ss)) >= 0 )
             opt_div_scrub = val;
+        else if ( (val = parse_boolean("bp-spec-reduce", s, ss)) >= 0 )
+            opt_bp_spec_reduce = val;
         else
             rc = -EINVAL;
 
@@ -507,7 +511,7 @@ static void __init print_details(enum ind_thunk thunk)
      * Hardware read-only information, stating immunity to certain issues, or
      * suggestions of which mitigation to use.
      */
-    printk("  Hardware hints:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
+    printk("  Hardware hints:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
            (caps & ARCH_CAPS_RDCL_NO)                        ? " RDCL_NO"        : "",
            (caps & ARCH_CAPS_EIBRS)                          ? " EIBRS"          : "",
            (caps & ARCH_CAPS_RSBA)                           ? " RSBA"           : "",
@@ -531,10 +535,11 @@ static void __init print_details(enum ind_thunk thunk)
            (e8b  & cpufeat_mask(X86_FEATURE_BTC_NO))         ? " BTC_NO"         : "",
            (e8b  & cpufeat_mask(X86_FEATURE_IBPB_RET))       ? " IBPB_RET"       : "",
            (e21a & cpufeat_mask(X86_FEATURE_IBPB_BRTYPE))    ? " IBPB_BRTYPE"    : "",
-           (e21a & cpufeat_mask(X86_FEATURE_SRSO_NO))        ? " SRSO_NO"        : "");
+           (e21a & cpufeat_mask(X86_FEATURE_SRSO_NO))        ? " SRSO_NO"        : "",
+           (e21a & cpufeat_mask(X86_FEATURE_SRSO_US_NO))     ? " SRSO_US_NO"     : "");
 
     /* Hardware features which need driving to mitigate issues. */
-    printk("  Hardware features:%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
+    printk("  Hardware features:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
            (e8b  & cpufeat_mask(X86_FEATURE_IBPB)) ||
            (_7d0 & cpufeat_mask(X86_FEATURE_IBRSB))          ? " IBPB"           : "",
            (e8b  & cpufeat_mask(X86_FEATURE_IBRS)) ||
@@ -553,7 +558,8 @@ static void __init print_details(enum ind_thunk thunk)
            (caps & ARCH_CAPS_FB_CLEAR_CTRL)                  ? " FB_CLEAR_CTRL"  : "",
            (caps & ARCH_CAPS_GDS_CTRL)                       ? " GDS_CTRL"       : "",
            (caps & ARCH_CAPS_RFDS_CLEAR)                     ? " RFDS_CLEAR"     : "",
-           (e21a & cpufeat_mask(X86_FEATURE_SBPB))           ? " SBPB"           : "");
+           (e21a & cpufeat_mask(X86_FEATURE_SBPB))           ? " SBPB"           : "",
+           (e21a & cpufeat_mask(X86_FEATURE_SRSO_MSR_FIX))   ? " SRSO_MSR_FIX"   : "");
 
     /* Compiled-in support which pertains to mitigations. */
     if ( IS_ENABLED(CONFIG_INDIRECT_THUNK) || IS_ENABLED(CONFIG_SHADOW_PAGING) ||
@@ -1113,7 +1119,7 @@ static void __init div_calculations(bool hw_smt_enabled)
 
 static void __init ibpb_calculations(void)
 {
-    bool def_ibpb_entry = false;
+    bool def_ibpb_entry_pv = false, def_ibpb_entry_hvm = false;
 
     /* Check we have hardware IBPB support before using it... */
     if ( !boot_cpu_has(X86_FEATURE_IBRSB) && !boot_cpu_has(X86_FEATURE_IBPB) )
@@ -1138,22 +1144,43 @@ static void __init ibpb_calculations(void)
          * Confusion.  Mitigate with IBPB-on-entry.
          */
         if ( !boot_cpu_has(X86_FEATURE_BTC_NO) )
-            def_ibpb_entry = true;
+            def_ibpb_entry_pv = def_ibpb_entry_hvm = true;
 
         /*
-         * Further to BTC, Zen3/4 CPUs suffer from Speculative Return Stack
-         * Overflow in most configurations.  Mitigate with IBPB-on-entry if we
-         * have the microcode that makes this an effective option.
+         * In addition to BTC, Zen3 and later CPUs suffer from Speculative
+         * Return Stack Overflow in most configurations.  If we have microcode
+         * that makes IBPB-on-entry an effective mitigation, see about using
+         * it.
          */
         if ( !boot_cpu_has(X86_FEATURE_SRSO_NO) &&
              boot_cpu_has(X86_FEATURE_IBPB_BRTYPE) )
-            def_ibpb_entry = true;
+        {
+            /*
+             * SRSO_U/S_NO is a subset of SRSO_NO, identifying that SRSO isn't
+             * possible across the User (CPL3) / Supervisor (CPL<3) boundary.
+             *
+             * Ignoring PV32 (not security supported for speculative issues),
+             * this means we only need to use IBPB-on-entry for PV guests on
+             * hardware which doesn't enumerate SRSO_US_NO.
+             */
+            if ( !boot_cpu_has(X86_FEATURE_SRSO_US_NO) )
+                def_ibpb_entry_pv = true;
+
+            /*
+             * SRSO_MSR_FIX enumerates that we can use MSR_BP_CFG.SPEC_REDUCE
+             * to mitigate SRSO across the host/guest boundary.  We only need
+             * to use IBPB-on-entry for HVM guests if we haven't enabled this
+             * control.
+             */
+            if ( !boot_cpu_has(X86_FEATURE_SRSO_MSR_FIX) || !opt_bp_spec_reduce )
+                def_ibpb_entry_hvm = true;
+        }
     }
 
     if ( opt_ibpb_entry_pv == -1 )
-        opt_ibpb_entry_pv = IS_ENABLED(CONFIG_PV) && def_ibpb_entry;
+        opt_ibpb_entry_pv = IS_ENABLED(CONFIG_PV) && def_ibpb_entry_pv;
     if ( opt_ibpb_entry_hvm == -1 )
-        opt_ibpb_entry_hvm = IS_ENABLED(CONFIG_HVM) && def_ibpb_entry;
+        opt_ibpb_entry_hvm = IS_ENABLED(CONFIG_HVM) && def_ibpb_entry_hvm;
 
     if ( opt_ibpb_entry_pv )
     {
diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h
index 8fa3fb711a8d..16207e3817bb 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -325,7 +325,9 @@ XEN_CPUFEATURE(FSRSC,              11*32+19) /*A  Fast Short REP SCASB */
 XEN_CPUFEATURE(AMD_PREFETCHI,      11*32+20) /*A  PREFETCHIT{0,1} Instructions */
 XEN_CPUFEATURE(SBPB,               11*32+27) /*A  Selective Branch Predictor Barrier */
 XEN_CPUFEATURE(IBPB_BRTYPE,        11*32+28) /*A  IBPB flushes Branch Type predictions too */
-XEN_CPUFEATURE(SRSO_NO,            11*32+29) /*A  Hardware not vulenrable to Speculative Return Stack Overflow */
+XEN_CPUFEATURE(SRSO_NO,            11*32+29) /*A  Hardware not vulnerable to Speculative Return Stack Overflow */
+XEN_CPUFEATURE(SRSO_US_NO,         11*32+30) /*A! Hardware not vulnerable to SRSO across the User/Supervisor boundary */
+XEN_CPUFEATURE(SRSO_MSR_FIX,       11*32+31) /*   MSR_BP_CFG.BP_SPEC_REDUCE available */
 
 /* Intel-defined CPU features, CPUID level 0x00000007:1.ebx, word 12 */
 XEN_CPUFEATURE(INTEL_PPIN,         12*32+ 0) /*   Protected Processor Inventory Number */


    

  


--------------mMaUl8IcN65lWTAF9JtD7nl4--


From xen-devel-bounces@lists.xenproject.org Mon Dec 23 10:52:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Dec 2024 10:52:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862857.1274387 (Exim 4.92)
	(envelope-from )
	id 1tPg36-0003f8-9n; Mon, 23 Dec 2024 10:52:32 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862857.1274387; Mon, 23 Dec 2024 10:52: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 1tPg36-0003f1-62; Mon, 23 Dec 2024 10:52:32 +0000
Received: by outflank-mailman (input) for mailman id 862857;
 Mon, 23 Dec 2024 10:52: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 1tPg34-0003dw-QL
 for xen-devel@lists.xenproject.org; Mon, 23 Dec 2024 10:52:31 +0000
Received: from EUR02-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur02on2061a.outbound.protection.outlook.com
 [2a01:111:f403:2607::61a])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 00c5e54d-c11c-11ef-a0da-8be0dac302b0;
 Mon, 23 Dec 2024 11:52:29 +0100 (CET)
Received: from DB8PR03CA0029.eurprd03.prod.outlook.com (2603:10a6:10:be::42)
 by AM9PR08MB6707.eurprd08.prod.outlook.com (2603:10a6:20b:305::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.21; Mon, 23 Dec
 2024 10:52:21 +0000
Received: from DU6PEPF0000B61D.eurprd02.prod.outlook.com
 (2603:10a6:10:be:cafe::48) by DB8PR03CA0029.outlook.office365.com
 (2603:10a6:10:be::42) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8272.20 via Frontend Transport; Mon,
 23 Dec 2024 10:52:21 +0000
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 DU6PEPF0000B61D.mail.protection.outlook.com (10.167.8.137) with
 Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8293.12
 via Frontend Transport; Mon, 23 Dec 2024 10:52:20 +0000
Received: ("Tessian outbound 050b604d5e06:v528");
 Mon, 23 Dec 2024 10:52:19 +0000
Received: from L5dc2c63ca0af.1
 by 64aa7808-outbound-1.mta.getcheckrecipient.com id
 210B986F-BAE1-47A0-A620-900E7CEC2479.1; 
 Mon, 23 Dec 2024 10:52:12 +0000
Received: from EUR03-VI1-obe.outbound.protection.outlook.com
 by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id
 L5dc2c63ca0af.1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Mon, 23 Dec 2024 10:52:12 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com (2603:10a6:10:1a6::21)
 by VE1PR08MB5662.eurprd08.prod.outlook.com (2603:10a6:800:1a9::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.20; Mon, 23 Dec
 2024 10:52:04 +0000
Received: from DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632]) by DBAPR08MB5798.eurprd08.prod.outlook.com
 ([fe80::4a66:d3e2:570:9632%5]) with mapi id 15.20.8272.013; Mon, 23 Dec 2024
 10:52: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: 00c5e54d-c11c-11ef-a0da-8be0dac302b0
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=vjS1o7mfTY+dHnvAT42PgLlPVutZ9t2p6tVDjJMaEqJ0QOfBZtNANU3zp230DrOlwofAogyu2yfDGGRm5IX5hXk3igL/H3n+xYAlOY43YpMeDpGnrwTae1PgEUV8oATzaQ2qVC8rFxuHq9x6QVNGwnHNeyHvkO+PwMRsNeKkoynxNZIo61AnZwZyZatZWmtLjFfLRWWQf4dSBsJCIIe8lVEXI+/2PzlLBtxMTupBQJDRuM9hVSfyqJk4kaIxr4BvdLa1L71rG8TX57RX7P4IFA4xGUtgnPVAcqWYeJr+z1PRsNU0Em4d9zbkN0yTbBuEt9vOJ6Zf8nf2gHjX3DeDdg==
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=+0hNmcfkxhNf9uJvhPoMncXyvLT95JISaNVPdYxZKWs=;
 b=Kr8+cAGP85jT5EEWNh6S2kaqy2tVyNoIZghvtRGzAvcFbAsRWqVgDeW5QBr3KeCom5FZstI8yygUWEyrpPFT42wGwCBbvY2kD9W2lpzh9sbOeXxsv9c2tKg103w9xRiuIQSicvHEJIINU1Gi9NWAexDZJgj9viEyn9Wkymp58BOr4YOUxUu5F7dDdq/iQYqUoGUSQXUBo1SmG0xO3MwhJdlZd9E/xqcQ1e5qwgUqZjQ3iUW9xbf1o0qkUUEBou/2ZumPVfvh/TJLS7yjXaCPoeUDDiqYE7W853VsLVVj+5TdVm7qssrRX6gwaHYCOkdJBWj6QH5INJlxygOxA8L0fg==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=+0hNmcfkxhNf9uJvhPoMncXyvLT95JISaNVPdYxZKWs=;
 b=UeKlOuLPg2Jp8S1oY5ksJ9SIFuZ4/mLX6T77TAo0E6DANopdPmoaLRJOUpDO7B7luBNvWt5D5XPp6ydpZ3TcxOfWsZqCKBoEgvm3ULP1qrYVlf/q0Ggo2xFip7iNwOaNHv5LiBv0k7p1eynicbfBPzFDfd+oBBMTnrQXXteHHDg=
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 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
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
 pr=C
X-CheckRecipientChecked: true
X-CR-MTA-CID: 710cbda58e1e9799
X-TessianGatewayMetadata: U2KjCPr6ayngDjWOWg9+x9sqzkQMHfwApNVKJkcqrQKqG4vKE+KMZcuHs9RmQ+OcfgmHywSwGlAq+8jvyTI5yNudIYZtQNUCw8j/+89S9GEvlgTcawZg2b7zrR28r5oZvuczJKrjSse1xZ9bFreVyxTPL5aDMFfEiUUNw4ntFMw=
X-CR-MTA-TID: 64aa7808
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ROWD37ZqyGjWEeu7uvCP2qZUHgw7AM1GokUo8xhD1Bk1AJFIVgp91dfX8c9K0vRPD3T0y0u5LyNzsShKxM71q/ZVzY7gZFp08EvhaZ9i4DSRasELOScOOAJkcGZzR3CfAGEqTEOQpPTiOCnrG5i5gwThmRuqc2xFljZs9YymeBEqVX2ucO1fzko2X36Nu//w6YUe+Z27u7GEwTvMPPlbTk4icQja8Rix/LGrlggNGa+ptCEEwsi8WOycHpuz4yi0HAuhgsxo1+dAms8vcBBl8kppphHTdJwVQZ1jmEkPy32JMzbRk3LGrV5VazFNrSLcY+9g9zlmRAozwF9MO1xEUg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=+0hNmcfkxhNf9uJvhPoMncXyvLT95JISaNVPdYxZKWs=;
 b=EtP6KsFuEvtkI1puWiQcJLqwX06uK8GHqNe0Ah04Ln9KdilfCdMbSbsmNrF/b0gGJJCYBDlAiQlngYbBQbqBLes/2GC8eRDKbg3Bez+BAF8xQOBK64AxvQi9k9uOZb65CgoK7/gc3F0fN76aGMGu8JLla4aq9k2883wT+PeUzwbzaAivVhzEFFCKMHn/vCXL0ImBqfDYVvCEQ9rSo0lkomDq5TdT7elMud92JcSP8KO0u4kAwahytBblc0Wr+iln/lGIgCZ/VRXeOkOj+7C8iAVvG1AerPdl/SkZudIJySBelUB9FRYDs/V5OFwir3r3gN2ZvKTl1s5TLcWvkp+Dyg==
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=+0hNmcfkxhNf9uJvhPoMncXyvLT95JISaNVPdYxZKWs=;
 b=UeKlOuLPg2Jp8S1oY5ksJ9SIFuZ4/mLX6T77TAo0E6DANopdPmoaLRJOUpDO7B7luBNvWt5D5XPp6ydpZ3TcxOfWsZqCKBoEgvm3ULP1qrYVlf/q0Ggo2xFip7iNwOaNHv5LiBv0k7p1eynicbfBPzFDfd+oBBMTnrQXXteHHDg=
From: Luca Fancellu 
To: Julien Grall 
CC: Michal Orzel , "xen-devel@lists.xenproject.org"
	, Stefano Stabellini
	, Bertrand Marquis ,
	Volodymyr Babchuk 
Subject: Re: [PATCH] xen/arm: Initialise memory type for struct kernel_info
Thread-Topic: [PATCH] xen/arm: Initialise memory type for struct kernel_info
Thread-Index: AQHbUvKnqvQwslwrpk6TiacMD2XmQ7LzewMAgAAj2ICAAAoCAIAAANWAgAABwIA=
Date: Mon, 23 Dec 2024 10:52:04 +0000
Message-ID: <3188C56B-6BF1-4488-9036-33014B469A01@arm.com>
References: <20241220151941.4192864-1-luca.fancellu@arm.com>
 <2a7ac358-7f43-4e32-9e1e-9ce1cd45304a@amd.com>
 
 
 <7b7d4606-86fe-45c1-9aa0-48ddfacabafb@xen.org>
In-Reply-To: <7b7d4606-86fe-45c1-9aa0-48ddfacabafb@xen.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3826.200.121)
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
x-ms-traffictypediagnostic:
	DBAPR08MB5798:EE_|VE1PR08MB5662:EE_|DU6PEPF0000B61D:EE_|AM9PR08MB6707:EE_
X-MS-Office365-Filtering-Correlation-Id: 6788680b-cbb2-404f-56f3-08dd233fdfc3
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|1800799024|366016|38070700018;
X-Microsoft-Antispam-Message-Info-Original:
 =?utf-8?B?Vmg3NFVZZkU5RlptNzB1ZTN2QmIrdmJjTjFHN0FNYTRoUnlrNUExVVZlVmE4?=
 =?utf-8?B?T0RtL002U050NmttbEhqOE1TMjJUZ3hwamVjZEhQcG5HM1lpK1pwb3BmUmJv?=
 =?utf-8?B?aHUzYVRvTWFFQ0Mva1U5RjZDSlJabmI0ZlJua05tbm5oTXhFMGVCQUVwNGNm?=
 =?utf-8?B?VkxzNnlHZGJPaXI3SFJ2MFFEeDBJR1VaM3RscjVpcXVjSHB3TWphWTg3YjNp?=
 =?utf-8?B?Tm1zN0puVldLQ3JXTW5ZOTBvR1NJeWVya2lpcWtYU2Q1a1hINkY5SDJKV2t1?=
 =?utf-8?B?MFI1RGNzdU83a0dxY3hxWjhxN2p2cTY3Y1AxdVZxVVhnbUZEbEJwQUFydEN5?=
 =?utf-8?B?dC9rb1FLZkdOUEJWcG5tUlVINmFXYi9STDRpUGcxZis5SFliR3MvTFZtbktJ?=
 =?utf-8?B?dTVTWktSY3A3bUdUZjZRcmJoT0lwUS9ScDh5TzFxZi9uS1BOMFFDZ05xMERn?=
 =?utf-8?B?S2xCa0tDYlprbnFUZy85N0VWdDNFNXJOaTdvTnE3T3FObzdUamtYMlpIYVBH?=
 =?utf-8?B?cFBod0xEZEczS3FNRG9HRURoQllreDNLS0hTcURDYkdmOEUzV0RxZXJQMGNj?=
 =?utf-8?B?a0V3K1RJSFp0Zk1kNmhra2hHUStJQ2p4ZzNLTXpDUEgyZTBTbUJjbXVHUXFF?=
 =?utf-8?B?ZTA4OVd4KzJIOThPMTh4RjMxQTBacVcvTkR1TllEcHh0TmtlN2lzdzNYWkYz?=
 =?utf-8?B?YU11aUd1dzhyZ0FZdjY3RUpDY1lMR1RzU0NKSURJanBJc3BYRzdHMEFET1VD?=
 =?utf-8?B?T0xVSmhEMEt0cjdwYklNa0FzU3Y0TXM3ampTM01IU2hFVkMwa1dvdDY5d3Rh?=
 =?utf-8?B?ME13bGliRVYybmlORm1MaDFud2pzcHBzS0hBdGhYN25uUU9FTFN6UHpnU240?=
 =?utf-8?B?dVNhWE9wYWp4R3M0OEhDdGlPZW5lbGNvUG95eWNYNkRrK2ZYNEU4cDlzRlpk?=
 =?utf-8?B?dVliMTZIVGxrdWRySWdQMDBYeEdRbmhvVjYyV01aTWFjQnJvSFFKMXlPM0l0?=
 =?utf-8?B?MTFQYnpwNFpaWXFMNXZFOEJqT3p5RFhLUEVzMlZ2VlpSaHBqNndZMUt0RFdw?=
 =?utf-8?B?dDk5WHFaampheml3ZVNFY0dleHd3YW9KaXZKVUYyR1NXbjBhdzNlOThyS2JH?=
 =?utf-8?B?a3BZVHNkcnNGSFRDVFBGRFo2TlJiSEJVMFVLZVdZRVhjZU9jYUFUMCswbXdl?=
 =?utf-8?B?U3FoUUVnNTMzWWpSMnFqWHNSSzhSdGROWUVUTzE1eThQUENnUVZKSXlId1NB?=
 =?utf-8?B?ZFBNWHZEVUdNOCtvUy9FeU05NU0vNXI0UTczTjIxTTVRL0RGaFRXR0tpQXc2?=
 =?utf-8?B?NlRWSVVNUXhVVW8yMk5MckN6eDIvS1BIeXR2eHE3UDNWTzAzalZ2U0t0d01Q?=
 =?utf-8?B?b1ZOakZLRUpMdWp5TXpQcU15MlFvdGs4clBlV1o3ZFdUQ3FWeVBTQVhMQUZY?=
 =?utf-8?B?K2pUbDA4OFRCQWZMNFV5WHlDOUNPakdQL3ovNlAvZkRNU3NScDZ5M0J2SWNC?=
 =?utf-8?B?RGJtSk1lWE0xbkU2RXBabzZHamNpZ1FTdlZqd2tWYzBkeGVyMnlYZ3doTHB3?=
 =?utf-8?B?TzVCKzB3U2ZkN0RHUVNCaU9PZE9vRGlOalZseEh6V3NYMytZTUkrcFd2Unpv?=
 =?utf-8?B?OGt5dy9VVEp1WnQ2amdadk5zMnVRYUpOZFNaZkZRUmM2VGd4YTQxdXhKNzRt?=
 =?utf-8?B?MDd2a2dqZ0hHR3FyNHBISkxDaGMrM0dvakxNY0FxUkJNOTJUOGZFbituaVlW?=
 =?utf-8?B?R1FBemIrVGROSS9NejhBVXBoMjV1MDBFL2F5bmZYWDNiOE5PMXpyUTBFV0Jo?=
 =?utf-8?B?T2VUWEFBNENxc1RWMG95OW0vWmgzV2dOQTVQdVNqUXdTNVBiUDRhUDZZbUJD?=
 =?utf-8?B?aGluT0p1UzhQSWZrVmxXcXY2OW9tTVM0V0hYSkE0NHhPQnh6eEY2ajNXOUlp?=
 =?utf-8?Q?gnKKw2lVegfxDStje6jc0x8rZaXV9zpX?=
X-Forefront-Antispam-Report-Untrusted:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5798.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);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: VE1PR08MB5662
Original-Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender:
 ip=[2603:10a6:10:1a6::21];domain=DBAPR08MB5798.eurprd08.prod.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DU6PEPF0000B61D.eurprd02.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
	dd9f2f6a-fec3-4057-746e-08dd233fd654
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|376014|14060799003|1800799024|36860700013|35042699022|82310400026;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?UVBQTDBPTE51eTNXdXVUcHNrNHp2U2FZV2VENTh2Rld0WDJpSm1USnkzdTZm?=
 =?utf-8?B?R0tKNlZ4b0ZGLzZ0L3lqSGpzYTdvRVc3bTQ3MW5BQk9oMW8zRTVkaFFpQzFF?=
 =?utf-8?B?U0NwKzhEVFF2Ky9saE52YW4wU1dEcmVjbHN4emEvdHdienZtU0owUytEN2Q1?=
 =?utf-8?B?ei9RL2dOV0xPVXVSVXh3Q1BSQ3BNKzh4NE50VDNueERDb3p0NE8ra0JPTmpC?=
 =?utf-8?B?amR4NFc3VnhsdkVCQVF6Q1ZHSFVnQ3lNNDZNM0JwZzkvOGJFM0xxWjNFT2dY?=
 =?utf-8?B?MjIxMHpzUXY0STZLSEx4M1Vha2RHaTZtbldMUHh4clB1Y2ltQnQyRitMcnZR?=
 =?utf-8?B?VUYvSC91WjZOMXp6cEwydVd1dUdneVV6ODlGOHZSTGhzRXBhQ2hJQndEM1Bm?=
 =?utf-8?B?NE5xaThBZ2czQ1F2b1pmeWtvemxIREdtSStKZ1l1Q3A3aVZsRE5UY2pMSER0?=
 =?utf-8?B?eU1TVnhsTEJ5Mm9HWlcwYzVGSzA2WG9DajdjS3pOMVF4NHlKRDBlNWZDTU13?=
 =?utf-8?B?a0VLTisyOENYTDFQZmJDdEh5eU9wTkJXUWdMaDJSaUxESHhsMThOQVc3MytG?=
 =?utf-8?B?ZlFEcWNxSGxnbWVHOE9Uc2NZVU42UE1uK0R2eU9pWE9ZaGpkWkdteG01Q0hR?=
 =?utf-8?B?Z09HUkhTa1VCZnBaVC9QY0tjTmZzMEo3R2NZVkU5azg3RE5FbjEya2c4dG9W?=
 =?utf-8?B?TlVON2lUMmE4WTR6Rmlrdm1pRUZkL2JNSFkyTkZpREpqZlV4eERKVzJpUjNK?=
 =?utf-8?B?V1ZmMXRjcVJaUUM2UW14Z0o3clJjT1FSdVhiTE9oZHM0V3JMQU8rTjVHVGJI?=
 =?utf-8?B?YVZOSzk1M0VRSEJoTnQxNUVaSXdYNElWRkhGaVBuQ3NFNExUNVVDNUtobThD?=
 =?utf-8?B?V2Exem05ajcyQmd6ZHh3RXRYeVVJZ0ZORmNiSDh5ay8xeEVEaGw0VFBadXNW?=
 =?utf-8?B?YUJ1OGZ1TllmQy9JanVadXBaZEh2SUFPa2F6MGpRNHR1b2dOQ3JlMGRKNG5L?=
 =?utf-8?B?QmU0RWZ2cWh1dTA4U2hCdGQ4bm00aWdSUGVRMGF3T2xXbGxkTEFZdUg4c0dN?=
 =?utf-8?B?YUxMRDJMWVVEQ28yVWlMd2NrckFtTG5UbHFMZlYwWVEyanowSUlDQzlSMzdm?=
 =?utf-8?B?OElFMk80dkNhQVFsSVNjRjJEejRpM0d1T21BK1IvMTlkWGZtczYrV0RkS0RL?=
 =?utf-8?B?Tmx3VC9LWEppdTkxSW0vTHp2QzJmbFJSUkFJd2VjUDErbDR2MjNMU1NUUkt1?=
 =?utf-8?B?UDc5K3dkbXFFVHZkZkk4Z3hSc25TdFQ1ZFZjTitOQ1NTYjN6b2E1ZS9yM29r?=
 =?utf-8?B?WmFBY200RDczYWd5Tm84QlM0VnloR0NhblZuMUdKSFJVMGtEU2s0NkxHclI2?=
 =?utf-8?B?QTVlbjJxVXFyWUlPYjdZTWpUejZxTnYwa1ptWFZNcTFWdXZ6akRaREZRYnMw?=
 =?utf-8?B?bU5CUGFScittL21mT0RIc3FKUmpaSlNyR1VNQTVITWJIaWNadTVJSkkvbHNC?=
 =?utf-8?B?SFBhYktQZ21ZRzB5TmMrMVY1MFVYaUJJTlJQNGs0YzlYVXdwTDBtZXVlQzZV?=
 =?utf-8?B?L2EreHFLdDRKOWdCb3phamN5Y01uUmZZS2J0YzNLSWRtbHdTNENBYWZMVmVl?=
 =?utf-8?B?ZVJYWHpTZUxQR0YraGptdzJUcGdUKzdmMWhrSzE0N0pKbk9lakgrTTVTY3dp?=
 =?utf-8?B?SFR1MEExdDFEbFpRUkVSWUt5R2hhSW9VanZnRnpSdU5BZ0NhaVZsM29RTkFW?=
 =?utf-8?B?UUI5eUNQWVpxVU5yWjVsWHBVYUswMjJIREk2OGtMa2xsemdrZkh6OVJ5WE1B?=
 =?utf-8?B?Y3UzbFdOVG5POSt0aitlcUJlYmM5azllTlB6end1c3dTWGhoRkV6cElFd2Rl?=
 =?utf-8?B?OEdGcmdXYklpYkVyOW96T08vc0pZYVY1VUtrcTR2TXY2VkpFM0VYZHhVZ09m?=
 =?utf-8?B?cUxRdlA5ZUVLd0tEQ1ljU3BQUE94V3VsQkNQZ0Jqcm9KRXVDdEgxdEZTZ3Ja?=
 =?utf-8?Q?Bn3Jov5nfPwnqBpiAiWI0riNfdkDng=3D?=
X-Forefront-Antispam-Report:
	CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:64aa7808-outbound-1.mta.getcheckrecipient.com;CAT:NONE;SFS:(13230040)(376014)(14060799003)(1800799024)(36860700013)(35042699022)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Dec 2024 10:52:20.0511
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 6788680b-cbb2-404f-56f3-08dd233fdfc3
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DU6PEPF0000B61D.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6707

SGkgSnVsaWVuIGFuZCBNaWNoYWwsDQoNCj4gT24gMjMgRGVjIDIwMjQsIGF0IDEwOjQ1LCBKdWxp
ZW4gR3JhbGwgPGp1bGllbkB4ZW4ub3JnPiB3cm90ZToNCj4gDQo+IEhpLA0KPiANCj4gT24gMjMv
MTIvMjAyNCAxMDo0MiwgTWljaGFsIE9yemVsIHdyb3RlOg0KPj4gT24gMjMvMTIvMjAyNCAxMTow
NiwgSnVsaWVuIEdyYWxsIHdyb3RlOg0KPj4+IA0KPj4+IA0KPj4+IEhpIE1pY2hhbCwNCj4+PiAN
Cj4+PiBPbiAyMy8xMi8yMDI0IDA3OjU4LCBNaWNoYWwgT3J6ZWwgd3JvdGU6DQo+Pj4+IA0KPj4+
PiANCj4+Pj4gT24gMjAvMTIvMjAyNCAxNjoxOSwgTHVjYSBGYW5jZWxsdSB3cm90ZToNCj4+Pj4+
IA0KPj4+Pj4gDQo+Pj4+PiBDb21taXQgYTE0NTkzZTM5OTVhICgieGVuL2RldmljZS10cmVlOiBB
bGxvdyByZWdpb24gb3ZlcmxhcHBpbmcgd2l0aA0KPj4+Pj4gL21lbXJlc2VydmUvIHJhbmdlcyIp
IGludHJvZHVjZWQgYSB0eXBlIGluIHRoZSAnc3RydWN0IG1lbWJhbmtzX2hkcicNCj4+Pj4+IGJ1
dCBmb3Jnb3QgdG8gdXBkYXRlIHRoZSAnc3RydWN0IGtlcm5lbF9pbmZvJyBpbml0aWFsaXNlciwg
d2hpbGUNCj4+Pj4+IGl0IGRvZXNuJ3QgbGVhZCB0byBmYWlsdXJlcyBiZWNhdXNlIHRoZSBmaWVs
ZCBpcyBub3QgY3VycmVudGx5DQo+Pj4+PiB1c2VkIHdoaWxlIG1hbmFnaW5nIGtlcm5lbF9pbmZv
IHN0cnVjdHVyZXMsIGl0J3MgZ29vZCB0byBoYXZlIGl0DQo+Pj4+PiBmb3IgY29tcGxldGVuZXNz
Lg0KPj4+PiBUaGUgbGFzdCBwYXJ0ICJnb29kIHRvIGhhdmUgaXQiIGRvZXMgbm90IHNvdW5kIGxp
a2Ugd2UgbmVlZCBhIEZpeGVzIHRhZy4NCj4+PiANCj4+PiBSZWFkaW5nIHRoZSBkaXNjdXNzaW9u
LCBpdCBzb3VuZHMgbGlrZSAiLnR5cGUiIGlzIG5vdCBhbHdheXMgc2V0IGFuZA0KPj4+IHRoaXMg
aXMgbm90IHByb3Blcmx5IGRvY3VtZW50ZWQuIFRoaXMgbWVhbnMgdGhhdCBpbiB0aGUgZnV0dXJl
IHdlIG1heQ0KPj4+IHdyaXRlIGEgcGF0Y2ggdGhhdCByZXF1aXJlcyB0byB1c2UgIi50eXBlIiBh
bmQgbmVlZHMgYmFja3BvcnRlZC4NCj4+PiANCj4+PiBCdXQgdGhpcyB3b3VsZCBkZXBlbmQgb24g
dGhpcyBwYXRjaCB3aGljaCB3YXMgbm90IHRhZ2dlZCBhcHByb3ByaWF0ZWx5Lg0KPj4+IFRoZXJl
Zm9yZSwgSSB3b3VsZCBhcmd1ZSBpdCBuZWVkcyBhIGZpeGVzIHRhZyAoZXZlbiB0aG91Z2ggdGhp
cyBpcyBhDQo+Pj4gbGF0ZW50IGJ1Zykgb3IgYXQgbGVhc3QgYSBiYWNrcG9ydCByZXF1ZXN0Lg0K
Pj4gU2V0dGluZyBleHBsaWNpdGx5IGEgdHlwZSBmb3Igc3RydWN0dXJlcyBub3QgcmVxdWlyaW5n
IGl0LCBkb2VzIG5vdCBzZWVtIGJlbmVmaWNpYWwgZm9yIG1lLg0KPiANCj4gSSBoYXZlIHRvIGRp
c2FncmVlLiBJZiB3ZSBzZXQgdHlwZSBldmVyeXdoZXJlLCB0aGVuIHRoZSBkZXZlbG9wZXIgZG9l
c24ndCBuZWVkIHRvIHRoaW5rIHdoZXRoZXIgIi50eXBlIiBpcyBnYXJiYWdnZSBvciBub3QuDQoN
ClNvLCBteSB0aG91Z2h0IHdhcyB0byBhdCBsZWFzdCBpbml0aWFsaXNlIGl0IG9uIHRoZSBzdHJ1
Y3R1cmVzIHRoYXQgZ29lcyBhcm91bmQgaW4gdGhlIGNvZGViYXNlLA0KZ250dGFiIGluIGZpbmRf
aG9zdF9leHRlbmRlZF9yZWdpb25zIGFuZCBzaG1faGVhcF9iYW5rcyBpbiBzdGF0aWMtc2htZW0u
YyB1c2FnZSBhcmUgbGVzcw0Kc3ByZWFkZWQuDQoNCkhvd2V2ZXIgSSBoYXZlIG5vIG9iamVjdGlv
biB0byBhbHdheXMgaW5pdGlhbGlzZSB0aGVtIGFsbCwgc28gdGhhdCBhbnlvbmUgc2VuZGluZyBw
YXRjaGVzIHRoYXQNCnVzZSB0aGVtLCBkb27igJl0IG5lZWQgdG8gdGhpbmsgaWYgdGhlIGZpZWxk
IGlzIGluaXRpYWxpc2VkIG9yIG5vdC4NCg0KSeKAmW0gY3VycmVudGx5IG9uIGxlYXZlLCBpcyBp
dCBvayB0byB3YWl0IHVudGlsIG5ldyB5ZWFyIGlmIGFueSBjaGFuZ2UgaXMgcmVxdWlyZWQ/DQoN
CkNoZWVycywNCkx1Y2E=


From xen-devel-bounces@lists.xenproject.org Mon Dec 23 11:11:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Dec 2024 11:11:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862869.1274400 (Exim 4.92)
	(envelope-from )
	id 1tPgLM-0006fM-Qj; Mon, 23 Dec 2024 11:11:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862869.1274400; Mon, 23 Dec 2024 11:11: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 1tPgLM-0006fF-Nm; Mon, 23 Dec 2024 11:11:24 +0000
Received: by outflank-mailman (input) for mailman id 862869;
 Mon, 23 Dec 2024 11:11: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 1tPgLL-0006f5-0A
 for xen-devel@lists.xenproject.org; Mon, 23 Dec 2024 11:11:23 +0000
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com
 [2a00:1450:4864:20::12f])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a3c6be30-c11e-11ef-a0da-8be0dac302b0;
 Mon, 23 Dec 2024 12:11:21 +0100 (CET)
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-54025432becso4281582e87.1
 for ; Mon, 23 Dec 2024 03:11:21 -0800 (PST)
Received: from [192.168.219.191] ([94.75.70.14])
 by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-542235f6089sm1238049e87.40.2024.12.23.03.11.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 23 Dec 2024 03:11:20 -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: a3c6be30-c11e-11ef-a0da-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734952281; x=1735557081; darn=lists.xenproject.org;
        h=content-transfer-encoding:subject:from:cc:to:content-language
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=aADORoeSZ5P/X9QlciiUFxdsMhSfUKXl+bCcdeuZmrY=;
        b=PrYqTCkBvYbJEkmf4W75gx/mI2OqiftkXq82eWSkDCYPsxcnx9HBY9e/tJF+jzfMYG
         27PlsYtFL88qWBcPLQEeGIwkdpV+GRW1N+j+E1BpwFM/MoQWzJ7T8yDFP6OkKkrPUSsR
         2kHVweISYgjmI5X4XN0bFkxRxSYNwIiSKUg1Ig4yNqVYZFnLQL0KJEuPCdrQz2hE4aa8
         2kHNnWYqFs9FjQs8lse7sTlfjM7ojY/fY1qY115rlIGW+BnoQ7gMb2jmwnNhWPgr+VCU
         IuO/YYUCqsFOgf6pnQG+QXu+pFI4yhx1xyonP6gNdJLv+MxziN8If5ASU9ubfO2sBL4a
         QU8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734952281; x=1735557081;
        h=content-transfer-encoding:subject:from:cc:to:content-language
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=aADORoeSZ5P/X9QlciiUFxdsMhSfUKXl+bCcdeuZmrY=;
        b=E8bSJYopduI//I430yRRhs5EfL+2gzek03785fnDti/ZJzsKEVs/hotuao+aARGUk+
         r85W4xllVZCNOFgFXJ+XrBppgH76nE3ljEH6oZBSrF2rK5EraY86FOhV++ZN+MCFqkkg
         y3gKOn8nSSHr02m7HETelk5e+lRIJqdzgCribySzlf8L+tbw/Y2qwfrTRyUgDx9+m5jA
         TZeXg+zwzbrOc2XVBm0tFRF/Xa8VwGOOTxiiCB6m4BlQmIdUp5rxb9gQuvbdYC1oM4V4
         i1ZXl2N9ofUhAJBC1gxWIIMkN0I79jRQ6fOuizoA6bhIY7SpKUdXQd1VU+b1VZS+3sSD
         m1gg==
X-Gm-Message-State: AOJu0YyksLkSouaQ5xBLwLrq6nRLcxBYXJ5e/uoMJAR5/U67kSlZ/JwS
	aNyi1/M3WjYf5EUztxLSmQazpyBEq5MPvtN0rtvQVKi7vfkYrgyknA8bYO22
X-Gm-Gg: ASbGncsuKxVuwO88DSX8TlbQlqVuakEQvglOXzbSLZbAxQkuG33i9Jby3xx0va+ggXW
	hnGD574xCqN5Q/q6LITJGLQrD7MbHT1I80sGQ47JkJp3RGfJiHUg0NvqDUbObvrYUIirn2/Yi6Z
	pWxyiCvG+1REfUYdEi3sbqm/2ofojc06WCaTLacdOLW0uP0fRM7ODhhS5h8Nbd9+MgE4y6zLGKc
	yMoI2NcS4X7k0azfg1NP4lNLtr7Ynkuhs18oYBHhKmpaNiJrA7g0NLIMqm+2Ux1ToeyMQ==
X-Google-Smtp-Source: AGHT+IHmsP3rC5aP/PQCVV1cWTCP7n2djNeR+NJo7/3X74+RCSp9gu5ftq2bozGxSIYLtbncocd1Rw==
X-Received: by 2002:a05:6512:3c83:b0:542:2e09:637b with SMTP id 2adb3069b0e04-5422e09638dmr2380126e87.11.1734952280428;
        Mon, 23 Dec 2024 03:11:20 -0800 (PST)
Message-ID: <73ce787b-5424-415c-a063-d996daab44ed@gmail.com>
Date: Mon, 23 Dec 2024 12:11:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Xen-devel 
Cc: Community Manager ,
 committers@xenproject.org
From: Oleksii Kurochko 
Subject: Code freeze date for Xen 4.20 is January 17, 2025
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello everyone,

The code freeze date for Xen 4.20 is January 17, 2025.

Straightforward bug fixes may continue to be accepted by maintainers
beyond this point. ( No release acknowledgment is needed until the start
of the hard code freeze which is going to start after January 17 )

Thanks and have a great week!

Best regards,
   Oleksii



From xen-devel-bounces@lists.xenproject.org Mon Dec 23 11:43:50 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Dec 2024 11:43:50 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862878.1274411 (Exim 4.92)
	(envelope-from )
	id 1tPgqe-0002Ke-61; Mon, 23 Dec 2024 11:43:44 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862878.1274411; Mon, 23 Dec 2024 11:43: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 1tPgqe-0002KX-35; Mon, 23 Dec 2024 11:43:44 +0000
Received: by outflank-mailman (input) for mailman id 862878;
 Mon, 23 Dec 2024 11:43: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 1tPgqb-0002KR-Sj
 for xen-devel@lists.xenproject.org; Mon, 23 Dec 2024 11:43:42 +0000
Received: from NAM02-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam02on20631.outbound.protection.outlook.com
 [2a01:111:f403:2406::631])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 254ef884-c123-11ef-99a3-01e77a169b0f;
 Mon, 23 Dec 2024 12:43:37 +0100 (CET)
Received: from CH0PR03CA0009.namprd03.prod.outlook.com (2603:10b6:610:b0::14)
 by MW4PR12MB7015.namprd12.prod.outlook.com (2603:10b6:303:218::10)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.20; Mon, 23 Dec
 2024 11:43:27 +0000
Received: from CH2PEPF0000009E.namprd02.prod.outlook.com
 (2603:10b6:610:b0:cafe::9) by CH0PR03CA0009.outlook.office365.com
 (2603:10b6:610:b0::14) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8207.12 via Frontend Transport; Mon,
 23 Dec 2024 11:43:27 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH2PEPF0000009E.mail.protection.outlook.com (10.167.244.27) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8293.12 via Frontend Transport; Mon, 23 Dec 2024 11:43:27 +0000
Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 23 Dec
 2024 05:43:26 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Mon, 23 Dec 2024 05:43:25 -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: 254ef884-c123-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=H5ZxpH8xpfHQAL1Hu/N+GPzLC2hClhEYG4ZJt0rPepWpbimmGB/knadr1Q+txYOgt2eY02n3a98bwBgtImrnH3BGbAJeHP3JiN/TLo1Q5dZIdOzbkgnjL+5LOMMRwCplxKK2kfF3vTwknbjkeHkbr5qN0ZLqmwl9d/n1gtipo1WhJ0jxVOeMFtni2reCSXNsu2z8G9Y7NtVKV6e9nlYvkGu90k9ixJnus/5e51/10BDuJWVAMsvkd/G4GpQ8Ca5n4Yrdci32yMLSnCHp+3tL1b0Zw9LJ8VLOPyaacovbrvNefeui0qU4dmnKU4Avx0r95Wnzhfs8X9xFdTIUTPUt5A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=4Quml13rmf6up0g8BqPhn79ieOGfKN8syZE/6HM6Pkw=;
 b=PROcQeBV4ZXYy0Fc3vm8j+ax9RwcEdyuEVvPnw7FPd875latskh/NW8c8/0UMWdW/fST4N3yGjxmXN3R/wvdWJMGSxv7nwwiymidLsm3GoFSCLuJc4vpdrUd/KQZBinK52NwBSPiG4Rjqf5td1aouoTQay6rFYNMCh+Cmz4NtrMrC9rrazOA8b/dGgKkDKkopuxCbiwkpHjmq7Fn7Z2LQmqnGic3mdQP7ndApVtT/MJb064z74hzXoVx0bikfikXJWrD6SfL/rpWmTltx546s2xmMXs6a6Z5W1tHXxso4dC7F709PLmPe3nnWvVqE5XJcAjsnMXo1uBQAti15ncwlA==
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=4Quml13rmf6up0g8BqPhn79ieOGfKN8syZE/6HM6Pkw=;
 b=ZBDv57SYYiEVxdGLMyFqiyssDUZacVMomOvuF9Qn+G9aMJcLhQRZMO5yD9nUNDZADD8ysgjjeOZK2Ungo3Vv7QlkcP1fejQ3TXTts3cQf+kIPpw7Nwxs1VXC5GACUikTPvCj8ioEeLa0KrjjaDc0fmaNHCJFYNyFQh7FNymym7U=
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=SATLEXMB03.amd.com; pr=C
Message-ID: <90072069-7776-4131-9409-9e74db9c87d9@amd.com>
Date: Mon, 23 Dec 2024 12:43:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: Initialise memory type for struct kernel_info
To: Julien Grall , Luca Fancellu ,
	
CC: Stefano Stabellini , Bertrand Marquis
	, Volodymyr Babchuk 
References: <20241220151941.4192864-1-luca.fancellu@arm.com>
 <2a7ac358-7f43-4e32-9e1e-9ce1cd45304a@amd.com>
 
 
 <7b7d4606-86fe-45c1-9aa0-48ddfacabafb@xen.org>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <7b7d4606-86fe-45c1-9aa0-48ddfacabafb@xen.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Received-SPF: None (SATLEXMB03.amd.com: michal.orzel@amd.com does not
 designate permitted sender hosts)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF0000009E:EE_|MW4PR12MB7015:EE_
X-MS-Office365-Filtering-Correlation-Id: c745df64-9503-44ca-eb26-08dd234703ee
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?M25IZnJCYXpHdG15Y1VTMmRCdUs5RjJsTUhYa1FRb0FQeW1LVnp6NVdWRlll?=
 =?utf-8?B?OVpFQ3lFamVMc3ppMWU2allwUldyVmx5VDlVMUF4SmZrOFEyMFZmTGlmcFZn?=
 =?utf-8?B?MTRaeTVaZGQ2U08wSDlheURaZjQrNVRnTG40VFQzaDdsN2Erdm90UzBUV2hh?=
 =?utf-8?B?RDVZanZ6K3o0bHdJWlZCOThId0U5c1ZzUUVPYVlqOWE2UVI0dWJlTkpoTk1C?=
 =?utf-8?B?dDBySTh1dEVzN2F1Yk02ZSswbTRCN05vUFMzRkVBMGFsdHVvb292cFpydVpa?=
 =?utf-8?B?ZjljbDlJSXlLOXNBd3h2c0VsMlVrcTltOXhzcGRPSWZKOVRPTTNMNUllMG5y?=
 =?utf-8?B?VGtTOWpLL3lGMms0ZFNkSklWOWM1TkdVWTM5MVZHSFlwYjBGRlZSK3l4bVFm?=
 =?utf-8?B?QWhhbWh1OC9IYUxzZ2FIbDNDbktGT0xFekJwdkpUUzlBRU4vZ1FXUzYzR2ZU?=
 =?utf-8?B?NDBmeUVCL2w1SDNuWTFtekJZdTlLeEIyai94VTduNjIvZjYwZDlkY0pnd2dE?=
 =?utf-8?B?NzdGL0N4V01oSEtwM096bkdPN1BvcHFUZlYraGxWSGlzNW9KbTJDZ0xHM2xJ?=
 =?utf-8?B?cVpuT1QvRndGMzVBbDJ2bnNRRCt6NnpvbUxFRHlYZzNyUGI4V1JwUmx1bVph?=
 =?utf-8?B?cWZDbHJwdUQ4eTNPazcxZm1LWEJoU09UNDdWM1A2V1Q4S28zSEllMzlnQWY2?=
 =?utf-8?B?aXloTFUzQTFQZldpT2djaEdtUWtZR0RGYUphNS9SbUdoRlVQYW5wTTNaWnpn?=
 =?utf-8?B?Qjd6OERuaExyVDdlc2hXWHM4NXZ5a0ZkdDFxUStrdUNMeTMyaXJ6UFA0NUhv?=
 =?utf-8?B?QzhTTEJCd2ZLaG5INGQ4UkhuMllyV1lxNExIeVh1TExhZHN3Y2ZiQnFoUGtw?=
 =?utf-8?B?L0JyNWlYcExNSktFaGFNYTFJSTlaZ28zclRSMkp0SHhXVXlZRXNKbXBmU2tX?=
 =?utf-8?B?VlRDaHdDMEtvZHZHR2kwdk0wYnhWS2lhdm5NZW8xQ0F1cEJBL0czOTU4aUt6?=
 =?utf-8?B?elhJRDFtSGovSFlzLzNtRHJBR1hDNGx5Zk0yUGJGRlRuWHFtTGJCREpaeVNU?=
 =?utf-8?B?dGZXay9hQk5iNFp5R0R4M3o3alJBNUREZy9hbkhVeXlYT0VRbzZqSFJOdVJo?=
 =?utf-8?B?Wk5zQlBHY0NjMHlXNTBtdTgrRmlkcGVvbDI3aXBQMHcwb3k4UlRuajQzTTV2?=
 =?utf-8?B?YUhvVFpFRGRLVTBRb0RpdXpEenArdGoxL0tmRHpxYjFLcS9scFRPd0xGcU1S?=
 =?utf-8?B?VE4wV3Z2aytDcENMc3NnRjMyMUF4dXVONDR0ejgvV2R4UXkyMDMramhaWkpR?=
 =?utf-8?B?dlMzSGt2WitFZmlsRzJPSkRZSHR0SXpnajRyeEF4Wnh2YlVJNmhQZk1XaHZ3?=
 =?utf-8?B?MFRIUGhqVVpsa0Z0L3NxTW1kUGxKY21kOC9Pb1R3eWhIbUl6ZkU4MStxWnBs?=
 =?utf-8?B?TW5MTFlvUjFibGZjbVlGUVJpR0kzNXVBVVpHMk92MHdRZUE2eEFMSm40NklI?=
 =?utf-8?B?LzgzQU44dzBydFhwV0RKaW1sTjJRT09NVk5wZjAzMXB4RnQ0cSsya0pRTXZi?=
 =?utf-8?B?Mk9mUW5yQjNZSUhiakhTbE5aRDc5eVR6OXFmcHJSZkpWbGtGZXNzU0h3Y3JN?=
 =?utf-8?B?ckxsTkFkbTBsaDdmTXQvVE1KZ0lYWGxWeUpCaldwZDRFSDhJR3ZuMTRKVnIz?=
 =?utf-8?B?ejZxeXFCdlEwaDN1ZVNlU2F5Sm8rTzNyQW42TzdjUTlLdFBMSHJtbnNja0R5?=
 =?utf-8?B?OUgyVWwvUkRtblpyNEJUVzF5UVloeko4VjBHMGlOVXdERFZCcjBTNmpNcDhX?=
 =?utf-8?B?c2ZmSGxrdWQ3MHIrQlRrMnliNUlVMll3TnZVNTRKZzNkaDRHYjZteFBTQlZq?=
 =?utf-8?B?ZityUW0xREJGYTV5eWFGU1hKcktCSlFjNWYzZ01adiszeWFyWlBaZ3QzSiti?=
 =?utf-8?B?d1VwVmJNMU9NQ3R6cHloMGd2S3VxcTNXbnJXMU85Ty81NHIrVWdBL1Y5TWg1?=
 =?utf-8?Q?04Jw7H7/Xtfw9MlnFc2aK5QWJoWhcc=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(376014)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Dec 2024 11:43:27.1180
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c745df64-9503-44ca-eb26-08dd234703ee
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF0000009E.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7015



On 23/12/2024 11:45, Julien Grall wrote:
> 
> 
> Hi,
> 
> On 23/12/2024 10:42, Michal Orzel wrote:
>>
>>
>> On 23/12/2024 11:06, Julien Grall wrote:
>>>
>>>
>>> Hi Michal,
>>>
>>> On 23/12/2024 07:58, Michal Orzel wrote:
>>>>
>>>>
>>>> On 20/12/2024 16:19, Luca Fancellu wrote:
>>>>>
>>>>>
>>>>> Commit a14593e3995a ("xen/device-tree: Allow region overlapping with
>>>>> /memreserve/ ranges") introduced a type in the 'struct membanks_hdr'
>>>>> but forgot to update the 'struct kernel_info' initialiser, while
>>>>> it doesn't lead to failures because the field is not currently
>>>>> used while managing kernel_info structures, it's good to have it
>>>>> for completeness.
>>>> The last part "good to have it" does not sound like we need a Fixes tag.
>>>
>>> Reading the discussion, it sounds like ".type" is not always set and
>>> this is not properly documented. This means that in the future we may
>>> write a patch that requires to use ".type" and needs backported.
>>>
>>> But this would depend on this patch which was not tagged appropriately.
>>> Therefore, I would argue it needs a fixes tag (even though this is a
>>> latent bug) or at least a backport request.
>> Setting explicitly a type for structures not requiring it, does not seem beneficial for me.
> 
> I have to disagree. If we set type everywhere, then the developer
> doesn't need to think whether ".type" is garbagge or not.
I see, I have nothing against this proposal. But in that case I do think that the same needs to apply to max_banks
member.

~Michal



From xen-devel-bounces@lists.xenproject.org Mon Dec 23 12:56:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Dec 2024 12:56:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862893.1274421 (Exim 4.92)
	(envelope-from )
	id 1tPhyP-00026p-Eo; Mon, 23 Dec 2024 12:55:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862893.1274421; Mon, 23 Dec 2024 12:55: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 1tPhyP-00026i-Bf; Mon, 23 Dec 2024 12:55:49 +0000
Received: by outflank-mailman (input) for mailman id 862893;
 Mon, 23 Dec 2024 12:55: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 1tPhyO-00026c-3I
 for xen-devel@lists.xenproject.org; Mon, 23 Dec 2024 12:55:48 +0000
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com
 [2a00:1450:4864:20::130])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 390d6f79-c12d-11ef-99a3-01e77a169b0f;
 Mon, 23 Dec 2024 13:55:44 +0100 (CET)
Received: by mail-lf1-x130.google.com with SMTP id
 2adb3069b0e04-5401bd6cdb4so4657849e87.2
 for ; Mon, 23 Dec 2024 04:55:44 -0800 (PST)
Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id
 2adb3069b0e04-54223832050sm1270484e87.250.2024.12.23.04.55.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 23 Dec 2024 04:55: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: 390d6f79-c12d-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1734958544; x=1735563344; 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=IQ/SnCbPbyKZZ+KRzbtTea38a8WUua4XwqRZo6AEYwA=;
        b=QwGSg+Rbhb2JR1qKjuWA90t0YKVC8DbwrbJmdi2kSkzFWZ/J55JElvcq78/V3fAZ6P
         Qg+Y9HzZZ6R3Q4X3lIDRNYFtCWEzHlTW04XeVcepvv7TeGMgnfvCC9BTNVKpL5Aonj8W
         m/y/nJLWqStRTCbmsTaZXbIz1PAIkjyPFQYAuUWvi9ARJOyjrOMOdxZTpjklLlUYzQrO
         SzT+Z6ZDB3398FJGiqqbIRhWnqBnqPq1iUmy7J6NU3ooMkHXpdI+W0yWHa4VPlXDPPLG
         RCbdc7sjUH+EoB9bYGPfU52+NUt6C3yW+GsuXWKq2Neh2q+ui6oAExeYP4u41/SMvfb4
         gxsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1734958544; x=1735563344;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=IQ/SnCbPbyKZZ+KRzbtTea38a8WUua4XwqRZo6AEYwA=;
        b=F5XrueiF+NoW4TdLHLrv7uWvepq4NZCaPLabVgPp8oCM+TeUqSer/ovndEZfHjYKPx
         4QIs21p0DbH/ustQBm5pjf+HJrhot0ikJI6nZUWJ7py8I0Zuz9AD7lQUYarxb4ChWQ6Z
         lsL3aRVu+dvJHp9NvitWHqF/EfUYqYY215g0aoY7zm8wW/pLcyQqf+0+8gpiCh151ryO
         Ilz85cfZ1SU8HSSzTQ9295vV4sYi06f1vi9wQfDfvIHT9/cPYddk0RqRV/1ccVoJ/ovp
         BnYThA3Y1+s+Txvwjb86GmULB0dp26QN94tW532n0/PwRHKd6VzYzJ6FvEfsXC0eZ/8l
         aARw==
X-Gm-Message-State: AOJu0Yy2o0MiVpqFJGMLBBJMx5+0WMQfpbGTPsNuMtcsEN+C39F9Uqz3
	YjqdPrZ4joU931XhR/wgY2DLWUUAyU+IfziZAOAlSkq+G7WDxx6ffr0ezhu7
X-Gm-Gg: ASbGncug93gV2dR5R7fsDO5kHXiMIkYmSLgxmbANlqO+b5J1PN23dPHwUIwhALVcMng
	aIpt3vDKdiUMVnKcJ2gEZihic99NJyEdcE3E0/7+ksswFGoStLp8SQJqKLHvxtNZ07+2r1cuENW
	gQ5fCR/1R0ULBCtiOP0ofGSHdmGovjlSH1RNWabixY+OR81KXMl+OjNxIntfSQGpJZdKpkOxRCe
	YbZXp3N4WsKRG8FQNn3yZYBJWBrq3AunwKu9QTlHxSKkIIwMzpwetxsoA==
X-Google-Smtp-Source: AGHT+IH1aKOh0uD1a1RooaRNTaGqLpVpvq2yb99DULlhH0EspzRb8TXcRlPHml5Jf5qN3VALsf7PIg==
X-Received: by 2002:a05:6512:6709:b0:542:297f:4f67 with SMTP id 2adb3069b0e04-542297f4f9amr2819474e87.0.1734958543526;
        Mon, 23 Dec 2024 04:55:43 -0800 (PST)
From: Oleksii Kurochko 
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko ,
	Alistair Francis ,
	Bob Eshleman ,
	Connor Davis ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH for 4.21 v1 1/1] xen/riscv: identify specific ISA supported by cpu
Date: Mon, 23 Dec 2024 13:55:40 +0100
Message-ID: 
X-Mailer: git-send-email 2.47.1
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Supported ISA extensions are specified in the device tree within the CPU
node, using two properties: `riscv,isa-extensions` and `riscv,isa`.

Currently, Xen does not support the `riscv,isa-extensions` property, as
all available device tree source (DTS) files in the Linux kernel (v6.12-rc3)
and DTBs generated by QEMU use only the `riscv,isa` property.
Therefore, only `riscv,isa` parsing is implemented.

The `riscv,isa` property is parsed for each CPU, and the common extensions
are stored in the `host_riscv_isa` bitmap.
This bitmap is then used by `riscv_isa_extension_available()` to check
if a specific extension is supported.

The current implementation is based on Linux kernel v6.12-rc3
implementation with the following changes:
 - Drop unconditional setting of {RISCV_ISA_EXT_ZICSR,
   RISCV_ISA_EXT_ZIFENCEI, RISCV_ISA_EXT_ZICNTR, RISCV_ISA_EXT_ZIHPM} as they
   are now part of the riscv,isa string.
 - Remove saving of the ISA for each CPU, only the common available ISA is
   saved.
 - Remove ACPI-related code as ACPI is not supported by Xen.
 - Drop handling of elf_hwcap, since Xen does not provide hwcap to
   userspace.
 - Replace of_cpu_device_node_get() API, which is not available in Xen,
   with a combination of dt_for_each_child_node(), dt_device_type_is_equal(),
   and dt_get_cpuid_from_node() to retrieve cpuid and riscv,isa in
   riscv_fill_hwcap_from_isa_string().
 - Rename arguments of __RISCV_ISA_EXT_DATA() from _name to ext_name, and
   _id to ext_id for clarity.
 - Replace instances of __RISCV_ISA_EXT_DATA with RISCV_ISA_EXT_DATA.
 - Replace instances of __riscv_isa_extension_available with
   riscv_isa_extension_available for consistency.
 - Redefine RISCV_ISA_EXT_DATA() to work only with ext_name and ext_id,
   as other fields are not used in Xen currently.
 - Add check of first 4 letters of riscv,isa string to
   riscv_isa_parse_string() as Xen doesn't do this check before so it is
   necessary to check correctness of riscv,isa string. ( it should start with
   rv{32,64} with taking into account upper and lower case of "rv").
 - Drop an argument of riscv_fill_hwcap() and riscv_fill_hwcap_from_isa_string()
   as it isn't used, at the moment.
 - Apply Xen coding style.
 - s/pr_info/printk.

Signed-off-by: Oleksii Kurochko 
---
 xen/arch/riscv/Makefile                 |   1 +
 xen/arch/riscv/cpufeature.c             | 466 ++++++++++++++++++++++++
 xen/arch/riscv/include/asm/cpufeature.h |  63 ++++
 xen/arch/riscv/setup.c                  |   3 +
 4 files changed, 533 insertions(+)
 create mode 100644 xen/arch/riscv/cpufeature.c
 create mode 100644 xen/arch/riscv/include/asm/cpufeature.h

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index a5eb2aed4b..b0c8270a99 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -1,3 +1,4 @@
+obj-y += cpufeature.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 obj-y += entry.o
 obj-y += mm.o
diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c
new file mode 100644
index 0000000000..52ec05bd03
--- /dev/null
+++ b/xen/arch/riscv/cpufeature.c
@@ -0,0 +1,466 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Taken for Linux kernel v6.12-rc3 and modified by
+ * Oleksii Kurochko :
+ *
+ * - Drop unconditional setting of {RISCV_ISA_EXT_ZICSR,
+ *   RISCV_ISA_EXT_ZIFENCEI, RISCV_ISA_EXT_ZICNTR, RISCV_ISA_EXT_ZIHPM} as they
+ *   are now part of the riscv,isa string.
+ * - Remove saving of the ISA for each CPU, only the common available ISA is
+ *   saved.
+ * - Remove ACPI-related code as ACPI is not supported by Xen.
+ * - Drop handling of elf_hwcap, since Xen does not provide hwcap to
+ *   userspace.
+ * - Replace of_cpu_device_node_get() API, which is not available in Xen,
+ *   with a combination of dt_for_each_child_node(), dt_device_type_is_equal(),
+ *   and dt_get_cpuid_from_node() to retrieve cpuid and riscv,isa in
+ *   riscv_fill_hwcap_from_isa_string().
+ * - Rename arguments of __RISCV_ISA_EXT_DATA() from _name to ext_name, and
+ *   _id to ext_id for clarity.
+ * - Replace instances of __RISCV_ISA_EXT_DATA with RISCV_ISA_EXT_DATA.
+ * - Replace instances of __riscv_isa_extension_available with
+ *   riscv_isa_extension_available for consistency.
+ * - Redefine RISCV_ISA_EXT_DATA() to work only with ext_name and ext_id,
+ *   as other fields are not used in Xen currently.
+ * - Add check of first 4 letters of riscv,isa string to
+ *   riscv_isa_parse_string() as Xen doesn't do this check before so it is
+ *   necessary to check correctness of riscv,isa string. ( it should start with
+ *   rv{32,64} with taking into account upper and lower case of "rv").
+ * - Drop an argument of riscv_fill_hwcap() and riscv_fill_hwcap_from_isa_string()
+ *   as it isn't used, at the moment.
+ * - s/pr_info/printk.
+ * - Apply Xen coding style.
+ *
+ * Copyright (C) 2015 ARM Ltd.
+ * Copyright (C) 2017 SiFive
+ * Copyright (C) 2024 Vates
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct riscv_isa_ext_data {
+    const unsigned int id;
+    const char *name;
+};
+
+#define RISCV_ISA_EXT_DATA(ext_name, ext_id)    \
+{                                               \
+    .id = ext_id,                               \
+    .name = #ext_name,                          \
+}
+
+/* Host ISA bitmap */
+static __read_mostly DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX);
+
+static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu)
+{
+    const __be32 *prop;
+    unsigned int reg_len;
+
+    if ( dt_n_size_cells(cpu) != 0 )
+        printk("cpu node `%s`: #size-cells %d\n",
+               dt_node_full_name(cpu), dt_n_size_cells(cpu));
+
+    prop = dt_get_property(cpu, "reg", ®_len);
+    if ( !prop )
+    {
+        printk("cpu node `%s`: has no reg property\n", dt_node_full_name(cpu));
+        return -EINVAL;
+    }
+
+    if ( reg_len < dt_cells_to_size(dt_n_addr_cells(cpu)) )
+    {
+        printk("cpu node `%s`: reg property too short\n",
+               dt_node_full_name(cpu));
+        return -EINVAL;
+    }
+
+    return dt_read_paddr(prop, dt_n_addr_cells(cpu));
+}
+
+/*
+ * The canonical order of ISA extension names in the ISA string is defined in
+ * chapter 27 of the unprivileged specification.
+ *
+ * Ordinarily, for in-kernel data structures, this order is unimportant but
+ * isa_ext_arr defines the order of the ISA string in /proc/cpuinfo.
+ *
+ * The specification uses vague wording, such as should, when it comes to
+ * ordering, so for our purposes the following rules apply:
+ *
+ * 1. All multi-letter extensions must be separated from other extensions by an
+ *    underscore.
+ *
+ * 2. Additional standard extensions (starting with 'Z') must be sorted after
+ *    single-letter extensions and before any higher-privileged extensions.
+ *
+ * 3. The first letter following the 'Z' conventionally indicates the most
+ *    closely related alphabetical extension category, IMAFDQLCBKJTPVH.
+ *    If multiple 'Z' extensions are named, they must be ordered first by
+ *    category, then alphabetically within a category.
+ *
+ * 3. Standard supervisor-level extensions (starting with 'S') must be listed
+ *    after standard unprivileged extensions.  If multiple supervisor-level
+ *    extensions are listed, they must be ordered alphabetically.
+ *
+ * 4. Standard machine-level extensions (starting with 'Zxm') must be listed
+ *    after any lower-privileged, standard extensions.  If multiple
+ *    machine-level extensions are listed, they must be ordered
+ *    alphabetically.
+ *
+ * 5. Non-standard extensions (starting with 'X') must be listed after all
+ *    standard extensions. If multiple non-standard extensions are listed, they
+ *    must be ordered alphabetically.
+ *
+ * An example string following the order is:
+ *    rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux
+ *
+ * New entries to this struct should follow the ordering rules described above.
+ */
+const struct riscv_isa_ext_data riscv_isa_ext[] = {
+    RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_i),
+    RISCV_ISA_EXT_DATA(m, RISCV_ISA_EXT_m),
+    RISCV_ISA_EXT_DATA(a, RISCV_ISA_EXT_a),
+    RISCV_ISA_EXT_DATA(f, RISCV_ISA_EXT_f),
+    RISCV_ISA_EXT_DATA(d, RISCV_ISA_EXT_d),
+    RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_q),
+    RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h),
+    RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR),
+    RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR),
+    RISCV_ISA_EXT_DATA(zifencei, RISCV_ISA_EXT_ZIFENCEI),
+    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
+    RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
+    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
+    RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA),
+    RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA),
+};
+
+static const struct riscv_isa_ext_data required_extensions[] = {
+    RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB),
+    RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
+};
+
+static const size_t riscv_isa_ext_count = ARRAY_SIZE(riscv_isa_ext);
+
+static void __init match_isa_ext(const char *name, const char *name_end, unsigned long *bitmap)
+{
+    for ( int i = 0; i < riscv_isa_ext_count; i++ )
+    {
+        const struct riscv_isa_ext_data *ext = &riscv_isa_ext[i];
+
+        if ( (name_end - name == strlen(ext->name)) &&
+             !strncasecmp(name, ext->name, name_end - name) )
+        {
+            set_bit(ext->id, bitmap);
+            break;
+        }
+    }
+}
+
+static int __init riscv_isa_parse_string(const char *isa, unsigned long *out_bitmap)
+{
+    if ( isa[0] != 'r' && isa[0] != 'R' )
+        return -EINVAL;
+
+    if ( isa[1] != 'v' && isa[1] != 'V' )
+        return -EINVAL;
+
+    if ( isa[2] != '3' && isa[3] != '2' &&
+         isa[2] != '6' && isa[3] != '4' )
+        return -EINVAL;
+
+    isa += 4;
+
+    while ( *isa )
+    {
+        const char *ext = isa++;
+        const char *ext_end = isa;
+        bool ext_err = false;
+
+        switch ( *ext )
+        {
+        case 'x':
+        case 'X':
+            if ( acpi_disabled )
+                printk_once("Vendor extensions are ignored in riscv,isa."
+                            "Use riscv,isa-extensions instead\n");
+            /*
+             * To skip an extension, we find its end.
+             * As multi-letter extensions must be split from other multi-letter
+             * extensions with an "_", the end of a multi-letter extension will
+             * either be the null character or the "_" at the start of the next
+             * multi-letter extension.
+             */
+            for ( ; *isa && *isa != '_'; ++isa)
+                ;
+            ext_err = true;
+            break;
+        case 's':
+            /*
+             * Workaround for invalid single-letter 's' & 'u' (QEMU).
+             * No need to set the bit in riscv_isa as 's' & 'u' are
+             * not valid ISA extensions. It works unless the first
+             * multi-letter extension in the ISA string begins with
+             * "Su" and is not prefixed with an underscore.
+             */
+            if ( ext[-1] != '_' && ext[1] == 'u' )
+            {
+                ++isa;
+                ext_err = true;
+                break;
+            }
+            fallthrough;
+        case 'S':
+        case 'z':
+        case 'Z':
+            /*
+             * Before attempting to parse the extension itself, we find its end.
+             * As multi-letter extensions must be split from other multi-letter
+             * extensions with an "_", the end of a multi-letter extension will
+             * either be the null character or the "_" at the start of the next
+             * multi-letter extension.
+             *
+             * Next, as the extensions version is currently ignored, we
+             * eliminate that portion. This is done by parsing backwards from
+             * the end of the extension, removing any numbers. This may be a
+             * major or minor number however, so the process is repeated if a
+             * minor number was found.
+             *
+             * ext_end is intended to represent the first character *after* the
+             * name portion of an extension, but will be decremented to the last
+             * character itself while eliminating the extensions version number.
+             * A simple re-increment solves this problem.
+             */
+            for ( ; *isa && *isa != '_'; ++isa)
+                if ( unlikely(!isalnum(*isa)) )
+                    ext_err = true;
+
+            ext_end = isa;
+            if ( unlikely(ext_err) )
+                break;
+
+            if ( !isdigit(ext_end[-1]) )
+                break;
+
+            while ( isdigit(*--ext_end) )
+                ;
+
+            if ( tolower(ext_end[0]) != 'p' || !isdigit(ext_end[-1]) )
+            {
+                ++ext_end;
+                break;
+            }
+
+            while ( isdigit(*--ext_end) )
+                ;
+
+            ++ext_end;
+            break;
+        default:
+            /*
+             * Things are a little easier for single-letter extensions, as they
+             * are parsed forwards.
+             *
+             * After checking that our starting position is valid, we need to
+             * ensure that, when isa was incremented at the start of the loop,
+             * that it arrived at the start of the next extension.
+             *
+             * If we are already on a non-digit, there is nothing to do. Either
+             * we have a multi-letter extension's _, or the start of an
+             * extension.
+             *
+             * Otherwise we have found the current extension's major version
+             * number. Parse past it, and a subsequent p/minor version number
+             * if present. The `p` extension must not appear immediately after
+             * a number, so there is no fear of missing it.
+             */
+            if ( unlikely(!isalpha(*ext)) )
+            {
+                ext_err = true;
+                break;
+            }
+
+            if ( !isdigit(*isa) )
+                break;
+
+            while ( isdigit(*++isa) )
+                ;
+
+            if ( tolower(*isa) != 'p' )
+                break;
+
+            if ( !isdigit(*++isa) )
+            {
+                --isa;
+                break;
+            }
+
+            while ( isdigit(*++isa) )
+                ;
+
+            break;
+        }
+
+        /*
+         * The parser expects that at the start of an iteration isa points to the
+         * first character of the next extension. As we stop parsing an extension
+         * on meeting a non-alphanumeric character, an extra increment is needed
+         * where the succeeding extension is a multi-letter prefixed with an "_".
+         */
+        if ( *isa == '_' )
+            ++isa;
+
+        if ( unlikely(ext_err) )
+            continue;
+
+        match_isa_ext(ext, ext_end, out_bitmap);
+    }
+
+    return 0;
+}
+
+static int __init riscv_fill_hwcap_from_ext_list(void)
+{
+    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
+    const struct dt_device_node *cpu;
+
+    if ( !cpus )
+    {
+        printk("Missing /cpus node in the device tree?\n");
+        return -EINVAL;
+    }
+
+    dt_for_each_child_node(cpus, cpu)
+    {
+        const char *isa;
+        int cpuid = 0;
+
+        if ( !dt_device_type_is_equal(cpu, "cpu") )
+            continue;
+
+        cpuid = dt_get_cpuid_from_node(cpu);
+        if ( cpuid < 0 )
+            continue;
+
+        if ( cpuid >= NR_CPUS )
+        {
+            printk_once("%s: dts has more cpu than NR_CPUs\n", __func__);
+            continue;
+        }
+
+        if ( dt_property_read_string(cpu, "riscv,isa-extensions", &isa) )
+        {
+            printk("Unable to find \"riscv,isa-extensions\" devicetree entry "
+                   "for cpu%d\n", cpuid);
+            continue;
+        }
+        else
+            printk("riscv,isa-extensions isnt supported\n");
+    }
+
+    return -EOPNOTSUPP;
+}
+
+static void __init riscv_fill_hwcap_from_isa_string(void)
+{
+    const char *isa;
+    const struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
+    const struct dt_device_node *cpu;
+    int cpuid = 0;
+
+    if ( !acpi_disabled )
+        panic("%s should be updated correspondingly to support ACPI\n", __func__);
+
+    if ( !cpus )
+    {
+        printk("Missing /cpus node in the device tree?\n");
+        return;
+    }
+
+    dt_for_each_child_node(cpus, cpu)
+    {
+        DECLARE_BITMAP(this_isa, RISCV_ISA_EXT_MAX);
+
+        if ( !dt_device_type_is_equal(cpu, "cpu") )
+            continue;
+
+        cpuid = dt_get_cpuid_from_node(cpu);
+        if ( cpuid < 0 )
+            continue;
+
+        if ( cpuid >= NR_CPUS )
+        {
+            printk_once("%s: dts has more cpu than NR_CPUs\n", __func__);
+            continue;
+        }
+
+        if ( acpi_disabled )
+        {
+            if ( dt_property_read_string(cpu, "riscv,isa", &isa) )
+            {
+                printk("Unable to find \"riscv,isa\" devicetree entry\n");
+                continue;
+            }
+        } else
+            panic("there is no support for ACPI\n");
+
+        riscv_isa_parse_string(isa, this_isa);
+
+        if ( bitmap_empty(riscv_isa, RISCV_ISA_EXT_MAX) )
+            bitmap_copy(riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
+        else
+            bitmap_and(riscv_isa, riscv_isa, this_isa, RISCV_ISA_EXT_MAX);
+    }
+}
+
+bool riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit)
+{
+    const unsigned long *bmap = (isa_bitmap) ? isa_bitmap : riscv_isa;
+
+    if (bit >= RISCV_ISA_EXT_MAX)
+        return false;
+
+    return test_bit(bit, bmap) ? true : false;
+}
+
+void __init riscv_fill_hwcap(void)
+{
+    unsigned int i;
+    size_t req_extns_amount = ARRAY_SIZE(required_extensions);
+    bool all_extns_available = true;
+
+    if ( !acpi_disabled )
+        riscv_fill_hwcap_from_isa_string();
+    else {
+        int ret = riscv_fill_hwcap_from_ext_list();
+
+        if ( ret )
+        {
+            printk("Falling back to deprecated \"riscv,isa\"\n");
+            riscv_fill_hwcap_from_isa_string();
+        }
+    }
+
+    for ( i = 0; i < req_extns_amount; i++ )
+    {
+        const struct riscv_isa_ext_data ext = required_extensions[i];
+
+        if ( !riscv_isa_extension_available(NULL, ext.id) )
+        {
+            printk("Xen requires extenstion: %s\n", ext.name);
+            all_extns_available = false;
+        }
+    }
+
+    if ( !all_extns_available )
+        panic("Look why the extenstions above are needed in booting.txt\n");
+}
diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/include/asm/cpufeature.h
new file mode 100644
index 0000000000..9b2ed1e914
--- /dev/null
+++ b/xen/arch/riscv/include/asm/cpufeature.h
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef ASM__RISCV__CPUFEATURE_H
+#define ASM__RISCV__CPUFEATURE_H
+
+#ifndef __ASSEMBLY__
+
+#define RISCV_ISA_EXT_a     ('a' - 'a')
+#define RISCV_ISA_EXT_c     ('c' - 'a')
+#define RISCV_ISA_EXT_d     ('d' - 'a')
+#define RISCV_ISA_EXT_f     ('f' - 'a')
+#define RISCV_ISA_EXT_h     ('h' - 'a')
+#define RISCV_ISA_EXT_i     ('i' - 'a')
+#define RISCV_ISA_EXT_m     ('m' - 'a')
+#define RISCV_ISA_EXT_q     ('q' - 'a')
+#define RISCV_ISA_EXT_v     ('v' - 'a')
+
+/*
+ * Increse this to higher value as kernel support more ISA extensions.
+ */
+#define RISCV_ISA_EXT_MAX   128
+
+#define RISCV_ISA_EXT_SxAIA     RISCV_ISA_EXT_SSAIA
+
+/*
+ * These macros represent the logical IDs of each multi-letter RISC-V ISA
+ * extension and are used in the ISA bitmap. The logical IDs start from
+ * RISCV_ISA_EXT_BASE, which allows the 0-25 range to be reserved for single
+ * letter extensions. The maximum, RISCV_ISA_EXT_MAX, is defined in order
+ * to allocate the bitmap and may be increased when necessary.
+ *
+ * New extensions should just be added to the bottom, rather than added
+ * alphabetically, in order to avoid unnecessary shuffling.
+ */
+#define RISCV_ISA_EXT_BASE  26
+
+enum riscv_isa_ext_id {
+    RISCV_ISA_EXT_ZICNTR = RISCV_ISA_EXT_BASE,
+    RISCV_ISA_EXT_ZICSR,
+    RISCV_ISA_EXT_ZIFENCEI,
+    RISCV_ISA_EXT_ZIHINTPAUSE,
+    RISCV_ISA_EXT_ZIHPM,
+    RISCV_ISA_EXT_ZBB,
+    RISCV_ISA_EXT_SMAIA,
+    RISCV_ISA_EXT_SSAIA,
+    RISCV_ISA_EXT_ID_MAX = RISCV_ISA_EXT_MAX,
+};
+
+void riscv_fill_hwcap(void);
+
+bool riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit);
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* ASM__RISCV__CPUFEATURE_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 38ca4f3baa..380461a054 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -13,6 +13,7 @@
 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -121,6 +122,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
         panic("Booting using ACPI isn't supported\n");
     }
 
+    riscv_fill_hwcap();
+
     printk("All set up\n");
 
     machine_halt();
-- 
2.47.1



From xen-devel-bounces@lists.xenproject.org Mon Dec 23 14:24:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Dec 2024 14:24:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862906.1274431 (Exim 4.92)
	(envelope-from )
	id 1tPjM8-0004En-Dr; Mon, 23 Dec 2024 14:24:24 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862906.1274431; Mon, 23 Dec 2024 14:24: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 1tPjM8-0004Eg-Az; Mon, 23 Dec 2024 14:24:24 +0000
Received: by outflank-mailman (input) for mailman id 862906;
 Mon, 23 Dec 2024 14:24: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 1tPjM6-0004EQ-AD
 for xen-devel@lists.xen.org; Mon, 23 Dec 2024 14:24:22 +0000
Received: from casper.infradead.org (casper.infradead.org
 [2001:8b0:10b:1236::1])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 950b4dd2-c139-11ef-99a3-01e77a169b0f;
 Mon, 23 Dec 2024 15:24:15 +0100 (CET)
Received: from 54-240-197-226.amazon.com ([54.240.197.226]
 helo=freeip.amazon.com)
 by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux))
 id 1tPjLw-0000000FeXG-06JL; Mon, 23 Dec 2024 14:24: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: 950b4dd2-c139-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References:
	In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=2k1YSapLUNBvQU7CZJmozDaJQTyQbwqeYmlBunuUZUQ=; b=mVhynl5x25Tshn1Y3YP2CDgmNy
	w0WC5QfJE56QUKY8dqpMCBSNn1yail0Y8KmYMONyOq0lFkc33c8+6btsOdY0CoPBCBwVzVlZhyzk+
	7Kq4UGxSXrbfq3u4AtgwuIjd91JKEjxuc1+Gc92VEbNAbEo5oAcr6MExHi1HLWjfercG0ehsA5XUc
	g1NQ1x9mAwA1WPBTc1srcf//YlDRyuxv1pZkHqUUkirUG9mksxLkZJu+tX2vRo0YVm6OWdBL4V5iM
	g3cH+Od80iSMq1I7rhNP800kg6OMdxGE8YUzDAvu8egGhtaePU0v9zaYTI32kNGe6A2oe+Cq0Emir
	0Sm7LS2A==;
Message-ID: <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
From: David Woodhouse 
To: "Xen.org security team" , xen-announce@lists.xen.org, 
	xen-devel@lists.xen.org, xen-users@lists.xen.org, 
	oss-security@lists.openwall.com
Cc: "Xen.org security team" 
Date: Mon, 23 Dec 2024 14:24:10 +0000
In-Reply-To: 
References: 
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature";
	boundary="=-2cuJts2lurvGX3hsXblo"
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from  by casper.infradead.org. See http://www.infradead.org/rpr.html


--=-2cuJts2lurvGX3hsXblo
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2024-12-17 at 12:18 +0000, Xen.org security team wrote:
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
Xen Security Advisory CVE-2024-53241 / XSA-466
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 version 3
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Xen hypercall page unsaf=
e against speculative attacks
>=20
> UPDATES IN VERSION 3
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Update of patch 5, public release.

Can't we even use the hypercall page early in boot? Surely we have to
know whether we're running on an Intel or AMD CPU before we get to the
point where we can enable any of the new control-flow integrity
support? Do we need to jump through those hoops do do that early
detection and setup?

Enabling the hypercall page is also one of the two points where Xen
will 'latch' that the guest is 64-bit, which affects the layout of the
shared_info, vcpu_info and runstate structures.

The other such latching point is when the guest sets
HVM_PARAM_CALLBACK_IRQ, and I *think* that should work in all
implementations of the Xen ABI (including QEMU/KVM and EC2). But would
want to test.

But perhaps it wouldn't hurt for maximal compatibility for Linux to set
the hypercall page *anyway*, even if Linux doesn't then use it =E2=80=94 or
only uses it during early boot?
=20

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

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEkQw
ggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqGSIb3DQEBDAUAMIGIMQswCQYDVQQG
EwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLSmVyc2V5IENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UEAxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAwMDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQG
EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYD
VQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50
aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAyjztlApB/975Rrno1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUf
ItMltrMaXqcESJuK8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeW
QcpGEGFUUd0kN+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YB
rf24k5Ee1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewD
ch/8kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU
U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4GA1Ud
DwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF
BQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2NybC51c2Vy
dHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHYGCCsGAQUF
BwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJT
QUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0G
CSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADdF9d6HBA4kMjjsb0XMZHztuOCtKF+
xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou74TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9
IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7
kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJJIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1
eoYV7lNwNBKpeHdNuO6Aacb533JlfeUHxvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4
KxaYIhvqPqUMWqRdWyn7crItNkZeroXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL
1Ygz3SBsyECa0waq4hOf/Z85F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQ
OZ1YL5ezMTX0ZSLwrymUE0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qod
x/PL+5jR87myx5uYdBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i
5ZgtwCLXgAIe5W8mybM2JzCCBhQwggT8oAMCAQICEQDGvhmWZ0DEAx0oURL6O6l+MA0GCSqGSIb3
DQEBCwUAMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD
VQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28g
UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTIyMDEwNzAw
MDAwMFoXDTI1MDEwNjIzNTk1OVowJDEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y
ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBALQ3GpC2bomUqk+91wLYBzDMcCj5C9m6
oZaHwvmIdXftOgTbCJXADo6G9T7BBAebw2JV38EINgKpy/ZHh7htyAkWYVoFsFPrwHounto8xTsy
SSePMiPlmIdQ10BcVSXMUJ3Juu16GlWOnAMJY2oYfEzmE7uT9YgcBqKCo65pTFmOnR/VVbjJk4K2
xE34GC2nAdUQkPFuyaFisicc6HRMOYXPuF0DuwITEKnjxgNjP+qDrh0db7PAjO1D4d5ftfrsf+kd
RR4gKVGSk8Tz2WwvtLAroJM4nXjNPIBJNT4w/FWWc/5qPHJy2U+eITZ5LLE5s45mX2oPFknWqxBo
bQZ8a9dsZ3dSPZBvE9ZrmtFLrVrN4eo1jsXgAp1+p7bkfqd3BgBEmfsYWlBXO8rVXfvPgLs32VdV
NZxb/CDWPqBsiYv0Hv3HPsz07j5b+/cVoWqyHDKzkaVbxfq/7auNVRmPB3v5SWEsH8xi4Bez2V9U
KxfYCnqsjp8RaC2/khxKt0A552Eaxnz/4ly/2C7wkwTQnBmdlFYhAflWKQ03Ufiu8t3iBE3VJbc2
5oMrglj7TRZrmKq3CkbFnX0fyulB+kHimrt6PIWn7kgyl9aelIl6vtbhMA+l0nfrsORMa4kobqQ5
C5rveVgmcIad67EDa+UqEKy/GltUwlSh6xy+TrK1tzDvAgMBAAGjggHMMIIByDAfBgNVHSMEGDAW
gBQJwPL8C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQUzMeDMcimo0oz8o1R1Nver3ZVpSkwDgYD
VR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2VjdGln
by5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20vU2VjdGln
b1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoGCCsGAQUFBwEB
BH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50
QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEFBQcwAYYXaHR0cDovL29j
c3Auc2VjdGlnby5jb20wHgYDVR0RBBcwFYETZHdtdzJAaW5mcmFkZWFkLm9yZzANBgkqhkiG9w0B
AQsFAAOCAQEAyW6MUir5dm495teKqAQjDJwuFCi35h4xgnQvQ/fzPXmtR9t54rpmI2TfyvcKgOXp
qa7BGXNFfh1JsqexVkIqZP9uWB2J+uVMD+XZEs/KYNNX2PvIlSPrzIB4Z2wyIGQpaPLlYflrrVFK
v9CjT2zdqvy2maK7HKOQRt3BiJbVG5lRiwbbygldcALEV9ChWFfgSXvrWDZspnU3Gjw/rMHrGnql
Htlyebp3pf3fSS9kzQ1FVtVIDrL6eqhTwJxe+pXSMMqFiN0whpBtXdyDjzBtQTaZJ7zTT/vlehc/
tDuqZwGHm/YJy883Ll+GP3NvOkgaRGWEuYWJJ6hFCkXYjyR9IzCCBhQwggT8oAMCAQICEQDGvhmW
Z0DEAx0oURL6O6l+MA0GCSqGSIb3DQEBCwUAMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBMB4XDTIyMDEwNzAwMDAwMFoXDTI1MDEwNjIzNTk1OVowJDEiMCAGCSqGSIb3DQEJ
ARYTZHdtdzJAaW5mcmFkZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBALQ3
GpC2bomUqk+91wLYBzDMcCj5C9m6oZaHwvmIdXftOgTbCJXADo6G9T7BBAebw2JV38EINgKpy/ZH
h7htyAkWYVoFsFPrwHounto8xTsySSePMiPlmIdQ10BcVSXMUJ3Juu16GlWOnAMJY2oYfEzmE7uT
9YgcBqKCo65pTFmOnR/VVbjJk4K2xE34GC2nAdUQkPFuyaFisicc6HRMOYXPuF0DuwITEKnjxgNj
P+qDrh0db7PAjO1D4d5ftfrsf+kdRR4gKVGSk8Tz2WwvtLAroJM4nXjNPIBJNT4w/FWWc/5qPHJy
2U+eITZ5LLE5s45mX2oPFknWqxBobQZ8a9dsZ3dSPZBvE9ZrmtFLrVrN4eo1jsXgAp1+p7bkfqd3
BgBEmfsYWlBXO8rVXfvPgLs32VdVNZxb/CDWPqBsiYv0Hv3HPsz07j5b+/cVoWqyHDKzkaVbxfq/
7auNVRmPB3v5SWEsH8xi4Bez2V9UKxfYCnqsjp8RaC2/khxKt0A552Eaxnz/4ly/2C7wkwTQnBmd
lFYhAflWKQ03Ufiu8t3iBE3VJbc25oMrglj7TRZrmKq3CkbFnX0fyulB+kHimrt6PIWn7kgyl9ae
lIl6vtbhMA+l0nfrsORMa4kobqQ5C5rveVgmcIad67EDa+UqEKy/GltUwlSh6xy+TrK1tzDvAgMB
AAGjggHMMIIByDAfBgNVHSMEGDAWgBQJwPL8C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQUzMeD
Mcimo0oz8o1R1Nver3ZVpSkwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYw
FAYIKwYBBQUHAwQGCCsGAQUFBwMCMEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYB
BQUHAgEWF2h0dHBzOi8vc2VjdGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9j
cmwuc2VjdGlnby5jb20vU2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h
aWxDQS5jcmwwgYoGCCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdv
LmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAj
BggrBgEFBQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wHgYDVR0RBBcwFYETZHdtdzJAaW5m
cmFkZWFkLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAyW6MUir5dm495teKqAQjDJwuFCi35h4xgnQv
Q/fzPXmtR9t54rpmI2TfyvcKgOXpqa7BGXNFfh1JsqexVkIqZP9uWB2J+uVMD+XZEs/KYNNX2PvI
lSPrzIB4Z2wyIGQpaPLlYflrrVFKv9CjT2zdqvy2maK7HKOQRt3BiJbVG5lRiwbbygldcALEV9Ch
WFfgSXvrWDZspnU3Gjw/rMHrGnqlHtlyebp3pf3fSS9kzQ1FVtVIDrL6eqhTwJxe+pXSMMqFiN0w
hpBtXdyDjzBtQTaZJ7zTT/vlehc/tDuqZwGHm/YJy883Ll+GP3NvOkgaRGWEuYWJJ6hFCkXYjyR9
IzGCBMcwggTDAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz
dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMT
NVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA
xr4ZlmdAxAMdKFES+jupfjANBglghkgBZQMEAgEFAKCCAeswGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMjQxMjIzMTQyNDEwWjAvBgkqhkiG9w0BCQQxIgQgLjoGuIHB
omRLJQwpN2tHqfuHO4jPYthyM3wmAiO5lnEwgb0GCSsGAQQBgjcQBDGBrzCBrDCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMa+GZZnQMQDHShREvo7qX4wgb8GCyqGSIb3
DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNl
Y3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAxr4Z
lmdAxAMdKFES+jupfjANBgkqhkiG9w0BAQEFAASCAgB2ROMHAW1CTw8/toCS+JWYqa5n6wjd5xfn
nZbcg7i3AUU6sBx9kqDWKI1YJeTYI1EdW4cPKSqdeHfidYyGLcJGaM+JeuvKK3xo5AKFQ2GGRzim
yiWbUPm9aFa9bxCtDWUgxPrRk0xLlrGSRa7U6iJMGXy+U0PF1sJ1c7V6E8YYl9Rbw9LeDsMzjg6E
hN0Yc2KO0bt/8hsGorjzZIQBWt+I0XLBX3MnfUs8BsKl1xBfer/T+36EHNW9BlWjbqPzLSzP8Bs4
g+R0rXMoZ61Uu1Qz9toBq1AlDv82qYRDJdaEEjxqLYAEHDAVljT3LP1zywDgJLAM36vgu3KJhW0n
n98ica56J0VFZtQLh9DYPlPmVwzNL+aMMBXPqqaslAV9U0k9cqBhPSGrsGspq2AXaDaLy26EE4dd
7p/QFGkSmsnYmaWMc+UN1l8zEL9id9M5S33JEN0Y4sr0cfRpRl9lEBFyxBDpmwMIfV0nL4ZkHJf5
RnZsGIpFAJJQncMsEVw5KChK35+X7v3g23ek+G+Riu/JynTVc5Xd1lVn2PLp6+fGQzaPVnjEBdKI
2v+o7hD5/U0GRAGgHufY4RLnUMj7AddZ+HsfjHNNFrMPELbyUmpdCwPDLYK4sKEcmx5sOaEva0FB
WUSQIRcflfFFqbC1SgAifWmi3HgorQl4lGllRd08/QAAAAAAAA==


--=-2cuJts2lurvGX3hsXblo--


From xen-devel-bounces@lists.xenproject.org Mon Dec 23 14:39:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Dec 2024 14:39:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862744.1274445 (Exim 4.92)
	(envelope-from )
	id 1tPjal-0005yX-8R; Mon, 23 Dec 2024 14:39:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862744.1274445; Mon, 23 Dec 2024 14:39: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 1tPjal-0005xD-4y; Mon, 23 Dec 2024 14:39:31 +0000
Received: by outflank-mailman (input) for mailman id 862744;
 Mon, 23 Dec 2024 03:18: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 1tPYy2-00049B-1a
 for xen-devel@lists.xenproject.org; Mon, 23 Dec 2024 03:18:50 +0000
Received: from mout.gmx.com (mout.gmx.com [74.208.4.200])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9efd8e73-c0dc-11ef-99a3-01e77a169b0f;
 Mon, 23 Dec 2024 04:18:47 +0100 (CET)
Received: from localhost.localdomain ([202.81.229.170]) by smtp.mail.com
 (mrgmxus004 [74.208.5.15]) with ESMTPSA (Nemesis) id
 0MWTs4-1t1rzC0zxy-00M7r3; Mon, 23 Dec 2024 04:18:44 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9efd8e73-c0dc-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.com;
	s=s1089575; t=1734923925; x=1735528725; i=hehongbo@mail.com;
	bh=eXjQDWaXpLEY9puH98Z0TBjr+nf7dLcr0LXLQmuMJr8=;
	h=X-UI-Sender-Class:From:To:Cc:Subject:Date:Message-Id:
	 MIME-Version:Content-Transfer-Encoding:cc:
	 content-transfer-encoding:content-type:date:from:message-id:
	 mime-version:reply-to:subject:to;
	b=R8DZRDeOo9jQi/pmsrCkRBfG4RqVpwPJiIDMcl8O+7R25kXpb6e1Shvg79knPV5Y
	 Ri7PCuak6G/cnOjSaE4dJdmrFoQZqb3X9ylxjaUq5AmmQqkKDaR69fmZsgmSYJtxq
	 4LNPsNsULdHy2GsJgOMt4y9B68LMZxBYPv6OE1sUPL8RW3HdgZjr2qncJIyOAjXie
	 8iZ5MwyY8+rA+ho7kUPYVAtPLOWxPm1yiCB+BG2gyf6sQ6Q1AtzxiWlaUPrxmRmRM
	 1FFPT83eitDvwR1ZihgWb47UfSOn0KuA1rDAbvAlRFHmLPl8Fg4ynlTha37S6n6ee
	 aiNDZskBWL6nlbfEvw==
X-UI-Sender-Class: f2cb72be-343f-493d-8ec3-b1efb8d6185a
From: Hongbo 
To: xen-devel@lists.xenproject.org
Cc: Hongbo ,
	Anthony PERARD ,
	Juergen Gross 
Subject: [XEN PATCH 1/1] tools/libxl: search PATH for QEMU if `QEMU_XEN_PATH` is not absolute
Date: Mon, 23 Dec 2024 11:17:53 +0800
Message-Id: <20241223031753.13709-1-hehongbo@mail.com>
X-Mailer: git-send-email 2.39.5 (Apple Git-154)
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:nyqOynpEIhEP3SWr866rrGH943lej5zvmPYXO1Tw0Gfb7ScdKUL
 4cbQ/bWk9n/TG9B6zmevRjru2Ml33eD+8xhQ9orgb1WXOUwxhLS5wAbFFL8Nx6Kw7RS8i3c
 TCHejwW6RfKXlVLZvNgUeU6LNSERzFTXKyEnX6b+/HfGk0KyJLi7YaG/VZDtXDSu0iPrrL0
 lqiAAtUySwul2VkqdRzQg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:37rkl4lZ3b0=;JXZdHxCSgB/RUNZkBvvi0D5OZp+
 /fuecYD0wN+mnutgQynoHIdzHXnoRSN7NRXo41w2fXxu+KURZqZ91+E68gDU2iLHaACgmMGSz
 NWca7OS8NvTZjD0C0NLf1CYX6uSHpi8QQ3KOjoIbx5HDkhd9jka9h1XrNZOBCRGnwea0l1nb1
 iRX+Y4DPqzJexEuWvktX+XqF7/JePtpG2sSBVvLrZghOQTLBHKW8WLyZyYG1o1XmabgYjsc97
 RmyiygYRr2WtiAEDjg6DpCy+IKWzBrZ7ZhOPLQcnL88CLBbK9BNAdj6RJkxf5raptRWtTkpUH
 Scd5N8jZnZ5rTlFT22E0j5HX4dWox/885iUDokWQFZxrEZXPNaeEubXXmLIOd3Ho1TcAANfLb
 5RGoHeD45I8KrFlNkfA3KJAREOEkF57vay9O8Yash7Nqfmb5wDERF6pLiuB47w1LyfehaOfhT
 teCP6pPrnJ8MuWcrTiVouWbMouog1/41NYykfYOUvhXTQ2I5Ue2pHj8qMuQCZVPOrzyB1toEQ
 n9dMfR78kuUDgmfeFnvJA9f+wfcMy6UGo5pxb2uKnXpB/xNUCbgvpQi0iD0V8pq2ddu+jUIYX
 uZPXsq/zmBB4ZKH42doJR94jmWKzIbKeLVLZF+sAHOFlNQiQQEnfIY7OH5gouM38QjPumJTrc
 AlYgc6n8gtODViBppn5nG6O2L/nmOwYAGkF3Bps+mpS6Lcw2gQ7MJ4hs0NhiR/ZuXjgFjjoN0
 y+oCe5JWrF5MXP24fJ5zvlimHUnnK3m5huFCR4+xNvuEbPf6rQ/Ru+Xa10zNUlnEDSwlFy5uO
 afrnXc3XQ6Z9z3/Ih6iTlWSET/u6tzGLQahP4p1AnXsgkLaFDHbnZIk3B+9OZWuulNH4suMIo
 m3r8ahhzGNwGd5N77iY3TVmRsE3FpXQ59CxEwWU5hnbc9yU1bvi0eJUnMLIrtTbbnVg6AqqCh
 qkLHqqhe8upEupKpUW2h8gj/aUtzr5HbgLM3ig4DDazKWruUiqUba8pZo3PSvaPV/7Pr0hlPe
 uPF5FKcuT3R0fZlwJGc9olj+GzeaAEfOhJOQb6T2+gscelNvVGONlZvbGiZKrUc7prOSEgZ9Z
 sx+p7vrywB43iXqRRHHhvVEQZPubzF

`QEMU_XEN_PATH` will be configured as `qemu-system-i386` with no clue wher=
e, if
`--with-system-qemu` is set without giving a path (as matched in the case =
`yes`
but not `*`). However, the existence of the executable is checked by `acce=
ss()`,
that will not look for anywhere in $PATH but the current directory. And si=
nce it
is possible for `qemu-system-i386` (or any other configured values) to be
executed from PATH later, we'd better find that in PATH and return the ful=
l path
for the caller to check against.

Signed-off-by: Hongbo 

=2D--

This patch is from the maintenance team of the Xen Project Hypervisor at N=
ixOS.
We encountered this and thought it was an edge case, and came up with this=
 while
maintaining the package and module of the Hypervisor at NixOS.

According to `xen.git/tools/configure.ac`, `QEMU_XEN_PATH` will be configu=
red as
`qemu-system-i386` (relative) if `--with-system-qemu` is set (as `yes`) bu=
t
without an absolute path. However, it will execute `qemu-system-i386` from=
 the
`PATH` only if a file is called `qemu-system-i386` in the *current directo=
ry*.
That is because the existence of the device model executable file, in this=
 case
`qemu-system-i386`, is checked via `access()` without concatenating it wit=
h
current PATHs. And `access()` is not tailored for executables, it will not
search for the PATHs for us.

See `libxl__domain_build_info_setdefault()` at
`xen.git/tools/libs/light/libxl_create.c`. It reads `dm` from
`libxl__domain_device_model()` and then uses `access()` on it. If that fai=
ls, it
will modify the `device_model_version` to qemu-traditional. Then, in
`libxl__spawn_local_dm()` at `xen.git/tools/lib/light/libxl_dm.c`, it read=
s from
`libxl__domain_device_model()` again, and `access()` is used again to dete=
ct the
file's existence. In my investigations, if I comment out these 2 existence
checks then it will run `qemu-system-i386` from the current PATH without i=
ssues.
I guess if it's not blocked by those 2 checks, it will finally reach
`libxl__exec()`. Then, inside the `libxl__exec()` the device model executa=
ble
will be executed by `execvp()`, which can certainly call the executable fr=
om
both absolute paths and current PATHs.

Since the device model executable will be checked twice, both of which wil=
l call
`libxl__domain_device_model()` to get its location, I think the preferred
solution would be patching the `libxl__domain_device_model()` function its=
elf to
tell if we're referring to an executable in PATHs, and resolve to the full=
 path
of it for the caller to check against.

It's indeed an edge case. But why would we need this? Because in Nix (the
package manager) and NixOS, we use Nix expressions to declare dependencies=
 on
the dependents, and we ran into the issue of circular dependency - to buil=
d
QEMU with Xen support, we should give the Xen header and libraries into th=
e
building process of QEMU, that makes Xen (`pkgs.xen`) a dependency of QEMU
(`pkgs.qemu_xen`), which prevents us from using `pkgs.qemu_xen` in the bui=
lding
process of Xen, and in `--with-system-qemu=3D` argument in particular. It =
is very
different compared to those distros and package managers that follow the
Filesystem Hierarchy Standard (FHS), in which Xen can be built with
`--with-system-qemu=3D` points to a non-existent FHS location of
`qemu-system-i386`, and then use these Xen libraries from the artifacts to=
 build
QEMU afterward. So we decide to build Xen with `--with-system-qemu` but no=
t
including an executable path, taking advantage of the fact that `QEMU_XEN_=
PATH`
can be configured as a relative `qemu-system-i386` when omitted, as declar=
ed as
the `yes` case in `xen.git/tools/configure.ac`, and that results in we fin=
ding
the aforementioned "current directory" issue, and submitting this patch.

In the patch, I'm using the existence of slash (`/`) to tell if `QEMU_XEN_=
PATH`
is relative, and begin to search in PATH if it is. I'm sort of iffy on thi=
s,
would it make more sense if we do this on inputs starting with a slash ins=
tead?
And should we notify the user if it's not found anywhere in the PATH thus
proceeding with the value configured in `QEMU_XEN_PATH` as-is?

Let me know if it's appropriate and if further changes are needed.

Best regards,
Hongbo

=2D--
CC: Anthony PERARD 
CC: Juergen Gross 
=2D--
 tools/libs/light/libxl_dm.c | 34 +++++++++++++++++++++++++++++++++-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/tools/libs/light/libxl_dm.c b/tools/libs/light/libxl_dm.c
index 1f2f5bd97a..db05f20a5b 100644
=2D-- a/tools/libs/light/libxl_dm.c
+++ b/tools/libs/light/libxl_dm.c
@@ -332,7 +332,39 @@ const char *libxl__domain_device_model(libxl__gc *gc,
             dm =3D libxl__abs_path(gc, "qemu-dm", libxl__private_bindir_p=
ath());
             break;
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-            dm =3D qemu_xen_path(gc);
+            const char *configured_dm =3D qemu_xen_path(gc);
+            if (strchr(configured_dm, '/'))
+                dm =3D libxl__strdup(gc, configured_dm);
+            else
+            {
+                const char *path_env =3D getenv("PATH");
+                if (!path_env)
+                    dm =3D libxl__strdup(gc, configured_dm);
+                else
+                {
+                    char *path_dup =3D libxl__strdup(gc, path_env);
+                    char *saveptr;
+
+                    char *path =3D strtok_r(path_dup, ":", &saveptr);
+                    char fullpath[PATH_MAX];
+                    bool dm_found =3D false;
+                    while (path)
+                    {
+                        snprintf(fullpath, sizeof(fullpath), "%s/%s", pat=
h,
+                                 configured_dm);
+                        if (access(fullpath, X_OK) =3D=3D 0)
+                        {
+                            dm =3D libxl__strdup(gc, fullpath);
+                            dm_found =3D true;
+                            break;
+                        }
+                        path =3D strtok_r(NULL, ":", &saveptr);
+                    }
+
+                    if (!dm_found)
+                        dm =3D libxl__strdup(gc, configured_dm);
+                }
+            }
             break;
         default:
             LOG(ERROR, "invalid device model version %d",
=2D-
2.39.5 (Apple Git-154)



From xen-devel-bounces@lists.xenproject.org Mon Dec 23 14:39:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Dec 2024 14:39:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862757.1274452 (Exim 4.92)
	(envelope-from )
	id 1tPjal-00065s-K0; Mon, 23 Dec 2024 14:39:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862757.1274452; Mon, 23 Dec 2024 14:39: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 1tPjal-00064P-EB; Mon, 23 Dec 2024 14:39:31 +0000
Received: by outflank-mailman (input) for mailman id 862757;
 Mon, 23 Dec 2024 07:16: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 1tPcfo-00056U-Uz
 for xen-devel@lists.xenproject.org; Mon, 23 Dec 2024 07:16:17 +0000
Received: from xry111.site (xry111.site [89.208.246.23])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id c9f788e8-c0fd-11ef-99a3-01e77a169b0f;
 Mon, 23 Dec 2024 08:16:13 +0100 (CET)
Received: from [127.0.0.1] (unknown [IPv6:2001:470:683e::1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (prime256v1) server-signature ECDSA (secp384r1)
 server-digest SHA384) (Client did not present a certificate)
 (Authenticated sender: xry111@xry111.site)
 by xry111.site (Postfix) with ESMTPSA id 1944F67671;
 Mon, 23 Dec 2024 02:15:35 -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: c9f788e8-c0fd-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xry111.site;
	s=default; t=1734938153;
	bh=ecGpjQJ+dPTMtl9IS6T8Zx3DPG9sUHrYzmuZ6ugsSWw=;
	h=Subject:From:To:Cc:Date:In-Reply-To:References:From;
	b=dYLhBandMXiOWoijdab1gHiwxN4eR/VOe1BsVjVz9qXmRVOFQ3esRLy431bdS1dZk
	 XfvgNo/mfzBUiJSkzYWjXUz9VNZqGIoxmAEmuMRQld4Umwy3a2m4Fwo8gIpR4U1JmC
	 QNQagNSSgXTyOhRij3RWOWxKAWCl+3mSvRV2S1v8=
Message-ID: <6ac0e0f71990e5a8dc52f00c737cdf56916e0d4e.camel@xry111.site>
Subject: Re: [PATCH v7] mm/memblock: Add memblock_alloc_or_panic interface
From: Xi Ruoyao 
To: Mike Rapoport , Guo Weikang
 
Cc: Andrew Morton , Geert Uytterhoeven	
 , Dennis Zhou , Tejun Heo
 ,  Christoph Lameter	 , Thomas Bogendoerfer
 , Sam Creasey	 , Huacai Chen
 , Will Deacon	 , Catalin Marinas
 , Oreoluwa Babatunde ,
 rafael.j.wysocki@intel.com, Palmer Dabbelt ,  Hanjun
 Guo , Easwar Hariharan
 , Johannes Berg	 ,
 Ingo Molnar , Dave Hansen	 ,
 Christian Brauner , KP Singh	 ,
 Richard Henderson , Matt Turner
 , Russell King , WANG Xuerui
 ,  Michael Ellerman , Stefan
 Kristiansson , Stafford Horne	
 , Helge Deller , Nicholas Piggin	
 , Christophe Leroy , Naveen
 N Rao , Madhavan Srinivasan , Geoff
 Levand	 , Paul Walmsley ,
 Palmer Dabbelt	 , Albert Ou ,
 Andrey Ryabinin	 , Alexander Potapenko
 , Andrey Konovalov , Dmitry Vyukov
 , Vincenzo Frascino	 , Heiko
 Carstens , Vasily Gorbik	 , Alexander
 Gordeev , Christian Borntraeger
 , Sven Schnelle , Yoshinori
 Sato	 , Rich Felker , John
 Paul Adrian Glaubitz , Andreas Larsson
 , Richard Weinberger	 , Anton Ivanov
 , Johannes Berg	
 , Thomas Gleixner , Ingo
 Molnar	 , Borislav Petkov , Dave Hansen	
 , x86@kernel.org, linux-alpha@vger.kernel.org,
 	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org, 
	linux-mips@vger.kernel.org, linux-openrisc@vger.kernel.org, 
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, 
	linux-riscv@lists.infradead.org, kasan-dev@googlegroups.com, 
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
 sparclinux@vger.kernel.org, 	linux-um@lists.infradead.org,
 linux-acpi@vger.kernel.org, 	xen-devel@lists.xenproject.org,
 linux-omap@vger.kernel.org, 	linux-clk@vger.kernel.org,
 devicetree@vger.kernel.org, linux-mm@kvack.org, 	linux-pm@vger.kernel.org
Date: Mon, 23 Dec 2024 15:15:34 +0800
In-Reply-To: 
References: <20241222111537.2720303-1-guoweikang.kernel@gmail.com>
	 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.54.2 
MIME-Version: 1.0

On Mon, 2024-12-23 at 09:12 +0200, Mike Rapoport wrote:
> On Sun, Dec 22, 2024 at 07:15:37PM +0800, Guo Weikang wrote:
> > Before SLUB initialization, various subsystems used memblock_alloc to
> > allocate memory. In most cases, when memory allocation fails, an immedi=
ate
> > panic is required. To simplify this behavior and reduce repetitive chec=
ks,
> > introduce `memblock_alloc_or_panic`. This function ensures that memory
> > allocation failures result in a panic automatically, improving code
> > readability and consistency across subsystems that require this behavio=
r.
> >=20
> > Changelog:
> > ----------
> > v1: initial version
> > v2: add __memblock_alloc_or_panic support panic output caller
> > v3: panic output phys_addr_t use printk's %pap
> > v4: make __memblock_alloc_or_panic out-of-line, move to memblock.c
> > v6: Fix CI compile error
> > Links to CI: https://lore.kernel.org/oe-kbuild-all/202412221000.r1NzXJU=
O-lkp@intel.com/
> > v6: Fix CI compile warinigs
> > Links to CI: https://lore.kernel.org/oe-kbuild-all/202412221259.JuGNAUC=
q-lkp@intel.com/
> > v7: add chagelog and adjust function declaration alignment format
> > ----------
> >=20
> > Signed-off-by: Guo Weikang 
> > Reviewed-by: Andrew Morton 
> > Reviewed-by: Geert Uytterhoeven 
> > Reviewed-by: Mike Rapoport (Microsoft) 
> > Acked-by: Xi Ruoyao 
>=20
> If people commented on your patch it does not mean you should add
> Reviewed-by or Acked-by tags for them. Wait for explicit tags from the
> reviewers.

And:

 - Acked-by: indicates an agreement by another developer (often a
   maintainer of the relevant code) that the patch is appropriate for
   inclusion into the kernel.=20

I'm not a maintainer so I even don't have the right to use Acked-by :).

--=20
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


From xen-devel-bounces@lists.xenproject.org Mon Dec 23 14:39:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Dec 2024 14:39:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862618.1274440 (Exim 4.92)
	(envelope-from )
	id 1tPjal-0005vW-0w; Mon, 23 Dec 2024 14:39:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862618.1274440; Mon, 23 Dec 2024 14:39: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 1tPjak-0005vP-Ue; Mon, 23 Dec 2024 14:39:30 +0000
Received: by outflank-mailman (input) for mailman id 862618;
 Sun, 22 Dec 2024 05:51: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 1tPEsR-0006D6-BF
 for xen-devel@lists.xenproject.org; Sun, 22 Dec 2024 05:51:43 +0000
Received: from xry111.site (xry111.site [89.208.246.23])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id d053e446-c028-11ef-a0da-8be0dac302b0;
 Sun, 22 Dec 2024 06:51:41 +0100 (CET)
Received: from [192.168.124.9] (unknown [113.200.174.52])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (prime256v1) server-signature ECDSA (secp384r1))
 (Client did not present a certificate)
 (Authenticated sender: xry111@xry111.site)
 by xry111.site (Postfix) with ESMTPSA id 16E7F1A3FB1;
 Sun, 22 Dec 2024 00:51:09 -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: d053e446-c028-11ef-a0da-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xry111.site;
	s=default; t=1734846684;
	bh=73Spy65y75EOyPTSc0iJv9YfbS1W2aMnBGueFT4LSeE=;
	h=Subject:From:To:Cc:Date:In-Reply-To:References:From;
	b=nZcUQW1TlcYe19vjpWVYF7BGYQbKeGDAvUbN+K0Gsvt9rhGMN7GsZfs/zdpj2lzl1
	 MbBsClXT3mJifINJ7gn7htQxIFD/roKSs0ciA+vaO6anVxMZbCRqy5Nv6Ocs9F+wxn
	 hZMWv9smlpVCNBPl3ehSuaSPQ+cU8zGg2WHY6b7I=
Message-ID: <02d042a6590ddb1fadb9f98d95de169c4683b9e7.camel@xry111.site>
Subject: Re: [PATCH v6] mm/memblock: Add memblock_alloc_or_panic interface
From: Xi Ruoyao 
To: Guo Weikang , Andrew Morton
	 , Mike Rapoport , Geert
 Uytterhoeven 
Cc: Dennis Zhou , Tejun Heo , Christoph
 Lameter , Thomas Bogendoerfer ,
 Sam Creasey	 , Huacai Chen , Will
 Deacon	 , Catalin Marinas ,
 Oreoluwa Babatunde , rafael.j.wysocki@intel.com,
 Palmer Dabbelt ,  Hanjun Guo ,
 Easwar Hariharan , Johannes Berg	
 , Ingo Molnar , Dave Hansen	
 , Christian Brauner , KP Singh	
 , Richard Henderson ,
 Matt Turner , Russell King ,
 WANG Xuerui ,  Michael Ellerman ,
 Stefan Kristiansson , Stafford Horne	
 , Helge Deller , Nicholas Piggin	
 , Christophe Leroy , Naveen
 N Rao , Madhavan Srinivasan , Geoff
 Levand	 , Paul Walmsley ,
 Palmer Dabbelt	 , Albert Ou ,
 Andrey Ryabinin	 , Alexander Potapenko
 , Andrey Konovalov , Dmitry Vyukov
 , Vincenzo Frascino	 , Heiko
 Carstens , Vasily Gorbik	 , Alexander
 Gordeev , Christian Borntraeger
 , Sven Schnelle , Yoshinori
 Sato	 , Rich Felker , John
 Paul Adrian Glaubitz , Andreas Larsson
 , Richard Weinberger	 , Anton Ivanov
 , Johannes Berg	
 , Thomas Gleixner , Ingo
 Molnar	 , Borislav Petkov , Dave Hansen	
 , x86@kernel.org, linux-alpha@vger.kernel.org,
 	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org, 
	linux-mips@vger.kernel.org, linux-openrisc@vger.kernel.org, 
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, 
	linux-riscv@lists.infradead.org, kasan-dev@googlegroups.com, 
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
 sparclinux@vger.kernel.org, 	linux-um@lists.infradead.org,
 linux-acpi@vger.kernel.org, 	xen-devel@lists.xenproject.org,
 linux-omap@vger.kernel.org, 	linux-clk@vger.kernel.org,
 devicetree@vger.kernel.org, linux-mm@kvack.org, 	linux-pm@vger.kernel.org
Date: Sun, 22 Dec 2024 13:51:08 +0800
In-Reply-To: <20241222054331.2705948-1-guoweikang.kernel@gmail.com>
References: <20241222054331.2705948-1-guoweikang.kernel@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.54.2 
MIME-Version: 1.0

On Sun, 2024-12-22 at 13:43 +0800, Guo Weikang wrote:
> Before SLUB initialization, various subsystems used memblock_alloc to
> allocate memory. In most cases, when memory allocation fails, an immediat=
e
> panic is required. To simplify this behavior and reduce repetitive checks=
,
> introduce `memblock_alloc_or_panic`. This function ensures that memory
> allocation failures result in a panic automatically, improving code
> readability and consistency across subsystems that require this behavior.
>=20
> Signed-off-by: Guo Weikang 
> ---


Please try to avoid bumping the patch revision number so quickly.

And if you must do it, you should embed a ChangeLog of your patch (below
this "---" line) so people can know what has been changed.

--=20
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University


From xen-devel-bounces@lists.xenproject.org Mon Dec 23 14:48:25 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Dec 2024 14:48:25 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862948.1274470 (Exim 4.92)
	(envelope-from )
	id 1tPjjH-0000GD-Ax; Mon, 23 Dec 2024 14:48:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862948.1274470; Mon, 23 Dec 2024 14: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 1tPjjH-0000G6-8T; Mon, 23 Dec 2024 14:48:19 +0000
Received: by outflank-mailman (input) for mailman id 862948;
 Mon, 23 Dec 2024 14:48:18 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1tPjjG-0000G0-4o
 for xen-devel@lists.xenproject.org; Mon, 23 Dec 2024 14:48:18 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1tPjjF-000d0e-0l;
 Mon, 23 Dec 2024 14:48:17 +0000
Received: from [2a02:8012:3a1:0:65a7:d8b5:e52b:9c0e]
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1tPjjF-00Flq1-0y;
 Mon, 23 Dec 2024 14:48: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" 
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=XAekPdDRmwIRIslDP0L6E6bggRDhoedZEharyQnDxSA=; b=0mwGr2lyWSRBzpUkvxeJuCVGmI
	TxLITQFOqGAm6VZnU9Fc6uEeGzvMqNWF7/DCunWwXdRGHUzW8++UoXGMCT8INa7bWj4/hdGouzJA2
	rQuyenvDtzwXRQBG1jnRX90n9VJTcDcNmrGESMIPN/PWlOY1E4h+Z4zrLNl8M84yLjbQ=;
Message-ID: <3eb1e65c-21f3-48c6-b4f5-1ae4d18e0d16@xen.org>
Date: Mon, 23 Dec 2024 14:48:15 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: Initialise memory type for struct kernel_info
Content-Language: en-GB
To: Michal Orzel , Luca Fancellu
 , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Bertrand Marquis ,
 Volodymyr Babchuk 
References: <20241220151941.4192864-1-luca.fancellu@arm.com>
 <2a7ac358-7f43-4e32-9e1e-9ce1cd45304a@amd.com>
 
 
 <7b7d4606-86fe-45c1-9aa0-48ddfacabafb@xen.org>
 <90072069-7776-4131-9409-9e74db9c87d9@amd.com>
From: Julien Grall 
In-Reply-To: <90072069-7776-4131-9409-9e74db9c87d9@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Michal,

On 23/12/2024 11:43, Michal Orzel wrote:
> 
> 
> On 23/12/2024 11:45, Julien Grall wrote:
>>
>>
>> Hi,
>>
>> On 23/12/2024 10:42, Michal Orzel wrote:
>>>
>>>
>>> On 23/12/2024 11:06, Julien Grall wrote:
>>>>
>>>>
>>>> Hi Michal,
>>>>
>>>> On 23/12/2024 07:58, Michal Orzel wrote:
>>>>>
>>>>>
>>>>> On 20/12/2024 16:19, Luca Fancellu wrote:
>>>>>>
>>>>>>
>>>>>> Commit a14593e3995a ("xen/device-tree: Allow region overlapping with
>>>>>> /memreserve/ ranges") introduced a type in the 'struct membanks_hdr'
>>>>>> but forgot to update the 'struct kernel_info' initialiser, while
>>>>>> it doesn't lead to failures because the field is not currently
>>>>>> used while managing kernel_info structures, it's good to have it
>>>>>> for completeness.
>>>>> The last part "good to have it" does not sound like we need a Fixes tag.
>>>>
>>>> Reading the discussion, it sounds like ".type" is not always set and
>>>> this is not properly documented. This means that in the future we may
>>>> write a patch that requires to use ".type" and needs backported.
>>>>
>>>> But this would depend on this patch which was not tagged appropriately.
>>>> Therefore, I would argue it needs a fixes tag (even though this is a
>>>> latent bug) or at least a backport request.
>>> Setting explicitly a type for structures not requiring it, does not seem beneficial for me.
>>
>> I have to disagree. If we set type everywhere, then the developer
>> doesn't need to think whether ".type" is garbagge or not.
> I see, I have nothing against this proposal. But in that case I do think that the same needs to apply to max_banks
> member.

I am fine with that.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Dec 24 03:42:27 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Dec 2024 03:42:27 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862976.1274481 (Exim 4.92)
	(envelope-from )
	id 1tPvo4-0001n2-GR; Tue, 24 Dec 2024 03:42:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862976.1274481; Tue, 24 Dec 2024 03:42: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 1tPvo4-0001mk-BU; Tue, 24 Dec 2024 03:42:04 +0000
Received: by outflank-mailman (input) for mailman id 862976;
 Tue, 24 Dec 2024 03:42: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 1tPvo3-0001me-B9
 for xen-devel@lists.xenproject.org; Tue, 24 Dec 2024 03:42:03 +0000
Received: from EUR03-DBA-obe.outbound.protection.outlook.com
 (mail-dbaeur03on20610.outbound.protection.outlook.com
 [2a01:111:f403:260d::610])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 05e46d45-c1a9-11ef-99a3-01e77a169b0f;
 Tue, 24 Dec 2024 04:41:58 +0100 (CET)
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com (2603:10a6:20b:5c0::11)
 by AS2PR03MB9877.eurprd03.prod.outlook.com (2603:10a6:20b:546::21)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.20; Tue, 24 Dec
 2024 03:41:50 +0000
Received: from AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::baa9:29b3:908:ed7d]) by AS8PR03MB9192.eurprd03.prod.outlook.com
 ([fe80::baa9:29b3:908:ed7d%4]) with mapi id 15.20.8251.008; Tue, 24 Dec 2024
 03:41: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: 05e46d45-c1a9-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=JxOX8w1FmHS1g/xM0nxnGZ8catj3+6Zmj/zUm+IPCYFNyesvr2ZZc9xdOBoEuZKuJMMZAaM9EdCULwCky8vMYyfl12MxCXC064qlppgpBRcetJ3o6Ozt/aTPv0QrFEfsSCDG04enAeUvOhws72BAkVzlzqGAV8n3AGfCvxkFHpnAloPCucb8G85Kgpvbtn7mXPUbdsAgDDzdo7wJpumfM7cvHlqMNjPov5CbqL1V3s8uPAbWwoDbNnh/jn08fz7QnHD7Z/hmwuA+0IA4PvU4e/crW8bxhQyAMJ+cjRilG6hIW6m54WTCkyGOUb5gv1V0f64vTAQkT7BT3Frtx4Tonw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=O93J0ZE6UWqtpepxBvByThnj1/RZPaYNApUG1BgiA6s=;
 b=X3eF+4+JFtphdgdKApOUiMpd9YjJd2LBv63vVHNoBa/ZRHrDaL5ltoO/38/E6jVszp1hfA4VtlMNTlcBo86ri6Y62P3OI/3qjKE+N57/irPs8ZBYJx4Gn7Advrocp7qhlJ8H4GXh8r8MD+5L/T6lpdycbv0oB8raBuQMjXwhK2gQiZI2oDbgBUYqLvVGTHsoKx+XDCmSKuyG3xUHCvWGM6E2Od2HF1wOfDsU/zx+oe9kWttIMaTPzIrwB9mXhBH0/7RqGtmd2NJED+9XeE1NSOaE3eILI5UKIsaK05aUtxBYMjbip3pKIsX9+F/pqruGe0lQQcXEVDhUQ8WId78hcw==
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=O93J0ZE6UWqtpepxBvByThnj1/RZPaYNApUG1BgiA6s=;
 b=jEsCQvRTtIYQpSjgoZnnew/FFdUIvB8+XdMjBy3mLRfw2OZgpUqd8GkDld/IzzvCRPC7vVygadJ7xisblspGV/FKv6qgkhety/E4prBsF0Nf6HcXctJgRKo83XPXOvZoCldNqKEnb9Trio2gYC3e7MXjZvGvG/OPh/GE/TDf1aygQCqGDZFOG7xLYWwqrZdtWUg39D7G387VrgbfSMXWOTcMyU+k7C8XnscwycIJMzmv7wh40cPGyzp0mndU1zhf9QGdmHxxfIECGXl0R6x0DP5CYORoe77ywx9/A4f+pX3WfB8nNW5NpyfTQQvQaSNw09z5PLNfHiW/BSkWD1APwQ==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: <16694707-ce8b-4c4e-a6ec-2190b8124735@epam.com>
Date: Tue, 24 Dec 2024 05:41:47 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
To: Julien Grall , xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 "Daniel P. Smith" 
References: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
 <4e437c60-4fee-40ed-9d2a-789bac0b36d9@xen.org>
 <5246aa98-d23c-41d5-ba14-c12b0a2ee9af@epam.com>
 
Content-Language: en-US
From: Sergiy Kibrik 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: WA2P291CA0017.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1e::17) To AS8PR03MB9192.eurprd03.prod.outlook.com
 (2603:10a6:20b:5c0::11)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS8PR03MB9192:EE_|AS2PR03MB9877:EE_
X-MS-Office365-Filtering-Correlation-Id: 1bfb939f-6125-4838-7c4c-08dd23cce677
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:
	=?utf-8?B?MUhPbmpxT0pDR1l2M3EzRG5xL0xiNEJzYjdBWjNVUVRhMUh3Tm16YzYxQW1L?=
 =?utf-8?B?ME5ZNjFUaEJxaGcvQytIUmJ5ZDRSMmhTSm8vRDVmbFBlK3hYaDZRUkl6SnhE?=
 =?utf-8?B?ekV2TUJ1NTVFWGNKNUMzU0J3R2J4VUJWbklZWnZZN2NFVEVCVXltdnovQW5w?=
 =?utf-8?B?VjBlUDhocFYvUWVTREFUNEM5VGxJV0h3VWFiSFFhU3VDSzV2NW1oL3lJMmdK?=
 =?utf-8?B?SmtyMVVFdHVjalFCblFHNnpMajRkSk5nUnYva2hOSGFrQjN6WGFaK3lwS0xh?=
 =?utf-8?B?ek8zQlZXcjh4bERiNm55ajFVK2dDbG1rWjRvSHBOWk11VDh5cXZPb0h6emdv?=
 =?utf-8?B?c1cwcHRMLzhabmtkQ2RlbUUrRC92bFA0UDlSMVQzU2ppSksyVWhWQThSUW9k?=
 =?utf-8?B?SjJWaUVYNk1qS0VueVNhbHc2N1lucEcyRVVYbjd5QTB2MEFQL0dkZVZISE1Y?=
 =?utf-8?B?MndOMGt1eVZja1F6WDBFR3NLOVdJUDA5eDZ4aG5SSi9iVTlQcXFuTWVKcWx4?=
 =?utf-8?B?TDNRc0dRWHgyTWtIUUVpZ1p4YkNaclRiS1BLcUs5TTByTnIzMVh1T3A4U1c4?=
 =?utf-8?B?cHBMbTIxT0kwam8ybnMxOC9uT3VFMXlnOTEzUjdZd2g2dXljSEUxa1BFdWt0?=
 =?utf-8?B?TklGZjRBeUVkS3hJRDF4NzQwcWlycWJVcHAwSmIrZFh4THlWVi9kVTI0Skt6?=
 =?utf-8?B?S2QwZDFwVktxNUhKVndzZncwRjNaWXl1UENxTTgrNWVjOXhHNE9Odkh0cTZ0?=
 =?utf-8?B?bUpVdCtNVHlPcndrMUx5b3ppYXRYNEV0VjNteWl4Rm9jZ3A5RHViVEVRNkxU?=
 =?utf-8?B?QnA0eWI5VFVqc25JQU5QWlovK1ZCVXRDenY4VnBoeEYvK0FoUUFkMWoyK3RU?=
 =?utf-8?B?T3d0cnE3ejgvRXdnTVN6Y2NCdmc4aGJVcEdhVDFnVmYwNHQvMDhSUG0reHpI?=
 =?utf-8?B?TDJENCtpK1JjUU5hbWRaQmhxa1hTZVVDdjhBdUZpNXV2L0xDQUdYWUNmaE1V?=
 =?utf-8?B?djYzR0hnNDJiVEZock56b0VSemlHUjVDS1d6Vm5Fd0ZmSkJrWHprVWtQdllk?=
 =?utf-8?B?REMxMHBoZHRJMmJTVFJLMFJZQmc5eklUMjJIT09mVzZzU2w4Q09QNmw0YzJZ?=
 =?utf-8?B?QWx2dlZ2elJieDFZMm9keTdJamMwbElDRE5yclJJOG8xMkJHK2psNkdHdUlh?=
 =?utf-8?B?Y2wwakk5UlZOd05zeUlVam52K0Y5OWppc09lb2xHTUlLYzFCUUR1NUtGdkZJ?=
 =?utf-8?B?clVvWlhZWSsrVEphMy9sdVlXUW1aNmZSTVhLZ2lmS0E0RlliZ1RqM2ZUMjhm?=
 =?utf-8?B?b0doL1Vic0FHbDU1VkxiNkk1a2p3T1JhVFhkOWUzeTJJalkwN0V4c2tmd3Rm?=
 =?utf-8?B?V1FreWlSMHpaUUdTeTR2YlJ6RVIzRUlsekhoYXJOMjh4ajgrYzltOVVSU2dj?=
 =?utf-8?B?RjZ3Rkk1Q3ZSa0pWTEhOSkl5aE9LREhidHpzNmFsenJhK0RZNEVkU0F6cHgv?=
 =?utf-8?B?UWdsVnBsOXBPRkNKNm9iSUljamRHeTZJaUlMNE5uNDcxam1wRFFVY0FYcHZo?=
 =?utf-8?B?T1pRRDA4Qm9KS1VrM1h5UFVSMnVWdmJ4ZEhHREMyRXNrYXNTYjBCUUpYaTJo?=
 =?utf-8?B?RlNPQmJHKzhHckJtMlM4Wnk3NVBnUVd5Zmc1dUlGMnYzMWE0NjA5bEtLUkw4?=
 =?utf-8?B?UERLM2F6aGRMRGxjNDNXT0t6NEF5SHBLdkNZUzE3RS93UHcyM1hvWUVqSFlo?=
 =?utf-8?B?SEZKSWNyVllodEFQUWlLN2pmbEtSZk9DcVQvSWZrOTlNQ3h5amN0MVBoaHps?=
 =?utf-8?B?bVVSRWxGeEtsenF6Vy9BN284U2ZDay9mZkcxMkhMVWdlcFI0eHNIbWczK3Bs?=
 =?utf-8?Q?EnaIzWPka7NEz?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR03MB9192.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?dU1oN0wzV2ZGN0FJemo2SE5iSkp6Tzh0WlF5TzU1UnpjY0Y5OFVHTTR0bjZm?=
 =?utf-8?B?dTliQm4xN2lOYjJuSVl2UFE2THdRV1F3T3ZsK294ckMybDZNbzd6bUE3RTRi?=
 =?utf-8?B?Mm1ham1ZR1FIZFU0WnpVRTFEckM4UTBYeEM5RXN2eGJKSDBOaEtwd2hwVmZt?=
 =?utf-8?B?KzFzbU91dE5nUDQwem5iQ1g2U0IzcTJKOGR0NHo3R3NaRTcxNUljSmZCMmZw?=
 =?utf-8?B?Q1ZqREw3bnZyTmlHL01NcDJQUExScFB1Y2ZzcVBzQmxUZWZ4YXQ0RjRlWC95?=
 =?utf-8?B?ME1aa3N0N25NUCszWm9LNVkvV3dNME1KbUJrWEwwUFkyWUdGSWwxeERYbzB6?=
 =?utf-8?B?L0s0NThJTzl4Y3c3T3JLZWZTT2lLdk0xM2FBTjhuNGs1a1ZDTE90MGpUS0JE?=
 =?utf-8?B?ODZvNG03OGhuaXZqM2NNbjduZkRtRHIrUlFhRjZFWXJWU1dCNVZRbkRhK3l4?=
 =?utf-8?B?QlQ3Z285UHRKQXhCVkRJeWgzWE5wMkVEazlDNVZtRkFNOTBEYVZwZkhXSDJC?=
 =?utf-8?B?V1NBOXk5R3gzeVJGZEhjSjEvQzlBRksxTm9RMGNETzhLa1RlVm93ektBRits?=
 =?utf-8?B?Yzd2T1V1bUVoeVpRcHMwc2RZZUtyVVpCR2ZTbXQvZmZOOUFIcVhSbnJpdzRm?=
 =?utf-8?B?WDZzRktsdlNLRFhZa2twbWhYWE94NWhFdmV2WmsyZWw0MFdKNHlkQ1FSM20r?=
 =?utf-8?B?T1JIT0pmTjAwenJwUjNUNk1ESVVqWnJmT3VVc0RrZnowdU5kdUxaK1A0SFNE?=
 =?utf-8?B?L2dJSS95M1ZuVjlsZERkcWkxVzU3bE8yQ1ZRREJKeTBsQmVISHFTNEFvMGtB?=
 =?utf-8?B?dnNVbGpJNkt4MmRyaDBhejlrNTVSN1UwQkJCUzJxQUlPUEhwTENWYSttM2pq?=
 =?utf-8?B?ZVhJc25XM1hkMFA0ckgvUVJaUFNyMTlOYTluc01qODZwcm1LSVViUTlFOWhL?=
 =?utf-8?B?Q0RkbUlzelVwVTMxWjkxRHBZVTVPZnhPWGppWlIvQy9SWDBMRlVvQkREQzFq?=
 =?utf-8?B?RFZTNzFqcUw5eExTbVBwUXdpWENqSnFENnFYek9oeW5wK3dNU2ZqOVdWZVdJ?=
 =?utf-8?B?TWdxYkhiN2dFanhxaTZMMDhVYURZRE9QWEFjdDJaSEhkZFA1OFJ5eEo5d1NJ?=
 =?utf-8?B?cTl3NUljQ1FUTlhBakNLMGNJNExnbExndHNlaVlWZ2NGaEJHaEt2aWt6Y2JU?=
 =?utf-8?B?TnBQWHAzUDZmM3grcFgzK0ZXSUVzUkcvaG5mY1AwOVVSL1dFanVvcGluSThh?=
 =?utf-8?B?WUJJWFRLZEx4eG9pQlVVRVRRUXYxWVVnenRGcUtvOVZTeTVOYUZtTWQ2cks1?=
 =?utf-8?B?Lzg0ZzBtdEFLZ3hiVlVIKytVd3BOZW9aaW44UU1wcHZBRTlBL1lRczRCbXE3?=
 =?utf-8?B?STRQSjRtbkprYXA5dko5Sm9pWWJRQXdQd0RqM21IMGk5L0Z3TjZrVzFJQVdX?=
 =?utf-8?B?c2pCL3dFR0dUYUhqb1ppWFJjb29pNFQ1c2hjR0ozekE0MlhwV2RJV1hYNWdY?=
 =?utf-8?B?bGZmNnNGa3hnYjg3cHppUVlQN0gzVDlMa3IrM25BVXV3YUhtNEhlanVQK1V5?=
 =?utf-8?B?Tm15WmIreDRXNUVhTW1HT2ZoTHdPTzVMSjdVclNJNW9TMFppcWJ2NURyaE5H?=
 =?utf-8?B?aG41N0pSNTZXNFdLcU85U1FrRlp3MzFjeWp3L3hkVGlBSS9vL1FvY2p2KzVU?=
 =?utf-8?B?NURTVlAzS2hSdUluUlhBbGhKOHY1amtSMlNEamlvMFAxcUpTeGhneGplUkVy?=
 =?utf-8?B?VkVxR3JZUEcxNi90bitVaGlBRmVoaTdhbWQzR3JSK2syd0w1NVF5cW95UVZK?=
 =?utf-8?B?dEdMRmRycGdXVUR2Zmkyay9VdHVlZnlOWUxJT2wyUXljcU1SYXlSTXVqTW9T?=
 =?utf-8?B?NVBLUDMxWnUwUFplR24rREZIYm01TWEyNTdQQXhVNE9JUXNUVGlnMnpXL0Vz?=
 =?utf-8?B?VTNIWFhuM0FqWHpkancyM3IwamFJMCtEaG1qT0x1MUdBUG5qaUx1Vzh0L3Qr?=
 =?utf-8?B?aVBqZUFxOFh1blFHY1VkWXl5M2NENURHVFJCcVNZeEg4ZTMyRmlaaTFSd2NM?=
 =?utf-8?B?Qjh0dHI4NWw5VlhKOS9JK2pVODRLSkJxR0dIaWpYZGpVZVJoY0xOWnptd3gr?=
 =?utf-8?B?ZHZOZ1FhTHRvUmkxM2pZY0piYmg2TlcxSkhydjBxQXhyRW5uOVRnaE9hS0Rp?=
 =?utf-8?B?RXc9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1bfb939f-6125-4838-7c4c-08dd23cce677
X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB9192.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Dec 2024 03:41:50.4636
 (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: G3xsODEj9+BcNto82rK2/ny8Cd8dg2KqU0PnTxYZJ/u7BY2AeyOhZ6q1BBUJPcNMsMLo9baiJf8WRMAJvjgZ1g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9877

18.12.24 12:05, Julien Grall:
> 
> 
> On 18/12/2024 09:52, Sergiy Kibrik wrote:
>> hi Julien,
>>
>> 17.12.24 14:42, Julien Grall:
>>> Hi,
>>>
>>> Can you clarify why this is an RFC?
>>>
>>
>> The code for LATE_HWDOM support on ARM seems to be already in place 
>> and working, yet I'm not sure that such configuration is ready to be 
>> exposed for users (well, probably not ready yet, considering Daniel's 
>> comments regarding XSM later in this thread).
> 
> Thanks. In the future, for RFCs, I would suggest to add a section after 
> your commit message (generally after ---) to describe a bit more what 
> you input you expect from the reviewers.
> 

yes, sure

>>> On 17/12/2024 11:47, Sergiy Kibrik wrote:
>>>> Allow to build ARM configuration with support for initializing 
>>>> hardware domain.
>>>> On ARM it is only possible to start hardware domain in multiboot 
>>>> mode, so
>>>> dom0less support is required. This is reflected by dependency on 
>>>> DOM0LESS_BOOT
>>>> instead of directly depending on ARM config option.
>>>
>>> I am a bit confused with the explanation. We already have an hardware 
>>> domain on Arm. It is dom0. So what are you trying to achieve? Is this 
>>> remove some permissions from the hardware domain?
>>
>> I agree, it should have better description.
>> This is to split dom0 permissions into control-only and hardware-only 
>> domains, much like it can be done in x86.
> 
> I don't believe you need the late_hwdom feature to do that on Arm. In 
> the case of dom0less, you are creating the domains at boot, so at the 
> point you can decide who does what.

I'm not sure which mechanism to use for this. Can it be done by XSM 
policy management?

>>
>>>
>>> If so, why can't the hardware domain stay as dom0 and you remove the 
>>> feature you don't want (e.g. control domain)?
>>
>> control domain is still needed, but as a separate instance & without 
>> hardware access.
> 
> Sure. But the control domain doesn't need to be dom0, it could be dom1, 
> right?
> 

I suppose it can. But again -- how do I make dom1 (or any other) a 
control domain instead of dom0?

>>
>>>
>>> Are you sure this patch is sufficient to use the late hwdom feature? 
>>> Looking at the code, to enable the late hwdom, the user needs to 
>>> provide a domid on the command line. But AFAICT, there is no way to 
>>> provide a domain ID in the DOM0LESS case...
>>>
>>
>> I append "hardware_dom=1" to xen,xen-bootargs in host's device tree 
>> and it works.
> 
> AFAIU, the domain needs to be explicitely created. How do you do that? 
> Is it just describing the domain in the DT? If so, how does it work if 
> there are multiple domain described in the DT?
> 

Indeed, in my case it works only because there's single domain 
description in DT.
If there're many domains in DT, we can't be sure which domain ID each of 
them would receive at boot, right?

  -Sergiy


From xen-devel-bounces@lists.xenproject.org Tue Dec 24 03:55:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Dec 2024 03:55:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862989.1274490 (Exim 4.92)
	(envelope-from )
	id 1tPw12-0003W2-Gl; Tue, 24 Dec 2024 03:55:28 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862989.1274490; Tue, 24 Dec 2024 03:55:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tPw12-0003Vv-EE; Tue, 24 Dec 2024 03:55:28 +0000
Received: by outflank-mailman (input) for mailman id 862989;
 Tue, 24 Dec 2024 03:55: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 1tPw11-0003Vn-0k
 for xen-devel@lists.xenproject.org; Tue, 24 Dec 2024 03:55:27 +0000
Received: from EUR03-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur03on20625.outbound.protection.outlook.com
 [2a01:111:f403:260c::625])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id e76c15d0-c1aa-11ef-99a3-01e77a169b0f;
 Tue, 24 Dec 2024 04:55:24 +0100 (CET)
Received: from DU0PR03MB9199.eurprd03.prod.outlook.com (2603:10a6:10:470::22)
 by PAVPR03MB10101.eurprd03.prod.outlook.com (2603:10a6:102:30e::12)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.21; Tue, 24 Dec
 2024 03:55:16 +0000
Received: from DU0PR03MB9199.eurprd03.prod.outlook.com
 ([fe80::3650:95ff:7db7:a5fe]) by DU0PR03MB9199.eurprd03.prod.outlook.com
 ([fe80::3650:95ff:7db7:a5fe%4]) with mapi id 15.20.8230.016; Tue, 24 Dec 2024
 03:55: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: e76c15d0-c1aa-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=ndyIKDi0p+2n/r17gaUJ3owaVLtjC6WmPba0/ndGf1VTpfar0PYelenNI5X5+ay9ers+SDqdmjkm8pYscDtewRUdjMeZWssI7FUygwKaSoyZjVvVxLbsNJwtAwHHKNuClETjztpXdY1zHp7XQg/B06ss9NFNyXajeB+wtyh/uuNcd4IZNcFJ/1oU3om+tHOemb+xk1mYZL/ltPIywrPLUITsUhdZKwL6gh8MqkoFMb/M8LOn0y7QsaJVXZcLXCE0szfTIRrmF1U7xpC6NpJyTk/IuBbI/uZua5m2Guj4pJlCgGaJyrjqe2/AdgtApAGXWiMi1EQQ+p1qZILE9plRUQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=hH4/d0I4p8N8xD8RENftgn2pBsiEpuAI//YY+y57N5Q=;
 b=QeLkidzbJ9gLmhKKijehx4wkXj+orqHFgIBhhd86tY6QmPyXBF52AzLOuzf03kgadX0+OpUMoLM4yfNjKYSRG+5PXGg2OVjqNmGVBCYgQl3hfKnAW4aXsXb+KWMWkh5iQtFDjYp/uaqRo6/5VK6Xl/d9tslWRm66tI3pdt+D/DGoSoDxDUG/98WRLnLCRITc5MEAZIOgQcYtP/hSnHtMpxljbRo5GkoF5oQ2O193yM728pNOIEetqYoa2qeCKlhO5tMgYov2yw3TQ68slscH8w8kIh50wkpg/QtkS66n7DC7EiQQOzeBVuL1ZXtB8mnUCc/1cbzOynltD2TobRsxNQ==
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=hH4/d0I4p8N8xD8RENftgn2pBsiEpuAI//YY+y57N5Q=;
 b=lok5Q/fJSFzlQHpSqeIcGF5Uwp7KQ/5u3Rf92SrThcVCxSymPT0/bxvvzg/CVdPI14cPcUjxa3hnm30hfMtuHeq7vpESygfTuKgdZr/urXpn9MtuiRQmhi6au4hUN9mxaymNvClRhS7O+f0m88085OY1y2HRWBJ5P4PF4ORwEbLlHiLPGuqHB5s5YyoOTJKkCjgCyNkmyt9PTs/gWI1UpGTzf09fa2tkz2r7xhXGT3ycKufdr9CPboaTyXRJbG/wCq/UK1nHp1/71v2VL9MJbEmbBd5zxo/CiHI5NC8i1zRTCel/nCPvTjPQkGDGKgn9sD0T5ihXaS1NI5cnYJCpCw==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: 
Date: Tue, 24 Dec 2024 05:55:14 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
To: Julien Grall , xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 "Daniel P. Smith" 
References: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
 <4e437c60-4fee-40ed-9d2a-789bac0b36d9@xen.org>
 <5246aa98-d23c-41d5-ba14-c12b0a2ee9af@epam.com>
 
 <1f6381a0-a98a-4783-a9c0-7ec49303af6b@xen.org>
Content-Language: en-US
From: Sergiy Kibrik 
In-Reply-To: <1f6381a0-a98a-4783-a9c0-7ec49303af6b@xen.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: WA2P291CA0035.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1f::11) To DU0PR03MB9199.eurprd03.prod.outlook.com
 (2603:10a6:10:470::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0PR03MB9199:EE_|PAVPR03MB10101:EE_
X-MS-Office365-Filtering-Correlation-Id: dc608127-565c-4159-19af-08dd23cec6a1
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:
	=?utf-8?B?UU5SYy9INm5zK3ZCN0k5TW1SMDdyRGNBb0FSQ3RzN0FBUDdOWlpYMWpoNVA4?=
 =?utf-8?B?a2E5dHBRd3RsVVJLZ2pGTnQ0UCtuMHRiQ1luRk1wUVpMbTl4QkZiRkRsaGpu?=
 =?utf-8?B?YjJQellHNFBNVk03NFBuUmRGZlQweCtkTzQ5MGRjay8yMm1sZDNYZUcycTB2?=
 =?utf-8?B?dHBCdHJjeFMwc3RwSUcrT2Nac2RzWGp2K2ROa2JKN3NpZkYwdHYydmpvTWsz?=
 =?utf-8?B?U3A4OHo4cDFUN05vOFEzVUdrS1NkYU5aVzgrNG1WV2NIT2FvMUJmN1pGcUsv?=
 =?utf-8?B?SlduL2RMRmVRQTlCSS9TaFlwYlBSQlRwYStnV1BvMVlEYmk3VUlmOGZTcGVa?=
 =?utf-8?B?T0V2RlFTcHVYK1FIelZibU1aSFdOSXRiQzNQOU9qZ3pkcUNrODVMM0tKL0dH?=
 =?utf-8?B?bFgxNmV5SEJ4aTN6amV1Vy9GSWhYOW5Valk3MTlLRUU5UDlGaXh0VGRMVys5?=
 =?utf-8?B?MnhGSXFxTmR1Zk80UzVobUZNWFMvR2JQenNZRmppeGFES2lkazdlTXdydUlW?=
 =?utf-8?B?SngzUm9VYnkvOStmOFQ4RjBKVUVqbVJHdVhSdUxzWVJOM1l3K3cwYzIvNVNP?=
 =?utf-8?B?V0hpeHoyb0hVK2JhOEtBemMwM3ZhY1FZSzUyVGRneU0xOXcyeXBlTWdobWdt?=
 =?utf-8?B?UjZkZStDbytoUGpuY1BZZThEaS96NGRwQm5TcWlzZ1VJaC9paG9EVVRHbHVq?=
 =?utf-8?B?M3lFd0JtTlV6Z0hHYjNzd3pPdHpic3dEOGgvVy9QcWlCZm5xKzJIVTREMENv?=
 =?utf-8?B?bllUYXg5V2NHZXRSTFpxVHRGZ3dwS1hBSzMxWkZkMWhSckJLZEJ6dlNXSHVn?=
 =?utf-8?B?aWFJUnVEY1laVW8vTndKSTFNRWQ1U3cwY1B3YndoVTkvOWFvbEpoV2lPVWpx?=
 =?utf-8?B?ZnJBU05DYzZ3OTl3dytDKzFCdG14ZCt1aUhyLzVHTjJiNFhzVWVMeXNlcDBZ?=
 =?utf-8?B?S2kxU1pObG9zNzRzVDRCbWh6SmQ3OVVJTE9hcUZuNDlGUkVSUzRIa3dLRkcx?=
 =?utf-8?B?STlrR3NQRDh4dGJIT0d4N1VWSnNZR2tlZ0U2VEFPeXBEcThydHpnRk9wVUVS?=
 =?utf-8?B?T05DL2NsWThmeUI0Sm9wb1c3QzZWdGZZRW5DNDRJTTFUaXF2Tk9CLytIb0d4?=
 =?utf-8?B?UGxHZEx3WCsyaU8zQXVwckd2RVEzcW1rekdNU1lyTWM4TUhpWlJNNE5ITjhs?=
 =?utf-8?B?aUJVWDJzdkZXcTA5Y2h3bEZNZSs5Z0U4cTdZMG4wRWRZelF0N0hGd3VEKzFk?=
 =?utf-8?B?YUJQallYNDlLbThxVTIvSVNnTTMzQXplaDM0cVNCcFA5bEllclV1L1FNaGRx?=
 =?utf-8?B?WlpDOGJRR0hnV0xUS2h0ZFZmM1UvbExudVhjK2xFVmdCd201NDB2anZFMyt5?=
 =?utf-8?B?Y0ZRa1dEVWF2d1JySmNkd3pjNUtBeFhYWUZHRXJ1YWo2KzFCaWE0RkkxandT?=
 =?utf-8?B?OThLaTQyNmZRdzA2dkpYMVpXR3BPenV4Q3dsVTlEbWRBUkZ0alFROEFhSDBk?=
 =?utf-8?B?QUtaTUVQTXhtWGtCd3M4dWh5QzVlazh0K3NNSzlhaHhWdzFkS0luVzg1SHN2?=
 =?utf-8?B?SnoxdytlZVoxQndyZHgzeE93UlgzK1dkcGN6ZnJaU1F5cmFnMS9KVWFXdy8w?=
 =?utf-8?B?RHlhOW9QbytFTXNzVHppSjUrc2RIeHl5ZGZTL1lyTWptYjF2UFJkYmN4NVlL?=
 =?utf-8?B?ekZQcmxhaEZhR0toeHp3S1FzT3VQNjdFTDNMREdhUTMxUWxDVWVvUllKUlIy?=
 =?utf-8?B?MVg2Q2VnTTJyUlI5cnpRUWhKUHZUWHJaZXMraEhiWEtBN2grSnRKMTdKRGhR?=
 =?utf-8?Q?MZNE0ZMjbHwlE84PkGW75OMiEKdB+8L2YbKRU=3D?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR03MB9199.eurprd03.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?THlXR2dvUFAySmFLTGVka2FLbVBwamNKRHEyeFRIOTBkWFFZNEhrWDViZFdx?=
 =?utf-8?B?aFJNWVhuNjlQTkV0QTVRRldWWUI5VTF1MEUyMmtXdkZSd0pJUWo3YW5Famho?=
 =?utf-8?B?VkdQdUNKbnM2WGVLSDREMWFIblhSRkJCUTNoVkRVbEg2N090TGZWZm1IOVJE?=
 =?utf-8?B?SnE3R0Q4SjlXcC9JblZDc1VHQzNYdmpOaTE4ZldhaVZiRkNDMFBOLzhXOE02?=
 =?utf-8?B?ZGhIdG4yV1N4bVp0WlhpeW1CUzUzQlR3aW51RXJSR3Z4d2tvYmFOZ1Q2ZlVy?=
 =?utf-8?B?REFKL050dXhOOTEwTEY2R05PUU1FOTJnZnpiK2tXK1VuOGxEcHBxMXl1RG5J?=
 =?utf-8?B?amFIdkFtbmkxRFk0N2xtSFhUdnkwSGVyaUhNWlphV1BhVVlvbTlINHg2QWF6?=
 =?utf-8?B?WXJQR1ZNS1hpaTk1emV6a0U2NmpyN1pLTUNRY3RSUEl3Q1BDYTlGL0xWV2ov?=
 =?utf-8?B?OGdSWHVRWjE2amhFNEN5UWRGMnFrQW5OOWRNQ0wzVWtmWWw2YW1FSVNyNTMr?=
 =?utf-8?B?a2dIRVpGUG5LeGsrQzFiMnVuN1dVanhPM1RhUm8rczJTZGVUNjliaXhvanV3?=
 =?utf-8?B?WEM5TFpKTzJaQmN6ZnpxL0FHV3ovb0VNTGVkUk4rS2lSM0pDTktkOWttNG5t?=
 =?utf-8?B?TUVzdVljeXQ0SWZWbVdMZ0NKNkJaaFk5UTBkazFHRVkzRzV4aFZPNXczT0s3?=
 =?utf-8?B?VG5FWGErOUM0aDBuL3ZxQUpjdk4zMVhoMy91VWJ4S25RbVFUYTBOMFBrZmJ2?=
 =?utf-8?B?T1haVmdPTU9UelNpNUQ1UTJwckZPTXM0MWlNcG80YnYzS05LaVdzZlhMTXhq?=
 =?utf-8?B?SHdlcXNWVEt2Uk9jWFQ0TVJPV1FXTytsNG9Vb1hKVmVXUDJtenRVYndiT1pP?=
 =?utf-8?B?aU9jRXh1MzlpbVAzb0t6T0xjVU9vMWNlcG1uVExKMURxc1cvbEh1N1lBcWI3?=
 =?utf-8?B?UUxpNFROSkpqbE5qaUVsYm1uUFFJVGxMNDEvTGgvc2tZNnRYSlZkejA0NS9E?=
 =?utf-8?B?cFdzWkhVeUxqSjc4dzJRUHJqd1pia0J5TDUyVHdmRkNnWUpaaUdwTERrcUpj?=
 =?utf-8?B?SUVtbWNxTTl4RElFWG1xQXR1Mm9Gd0cySU44cnVtY3VvMmtMK0s0YzhCbHUv?=
 =?utf-8?B?cGRHZVF5N0swY0NrK0hYZUIwWWxIZjQ5ZmtKWXZpQ3FWeHJYRml1VzJFRWts?=
 =?utf-8?B?UHpKaEpnZUJCNWRnNTNrMzlLQ3djajNJbWpKRDl5Q2FReE5qODBMVzhWa2t2?=
 =?utf-8?B?Y2JnKzFhREo1SjA2NTJva2I4Nk9MRmR3cVpGN1h4S2E1RW9CQkJUYjVMR1BD?=
 =?utf-8?B?a0JuTWdvd2paWG5uTHJoSnBxazcyZWdmTUI4WmYxVmNQbVJwUlZxTnY4TVNk?=
 =?utf-8?B?SG5ISm9obDJkRWxKRzZ1d2QrN3dVSy93V0VRQnpqd3lhblh0WWFWYlF4SUdL?=
 =?utf-8?B?VDRxSlM1V3A0NDJHOEpRamhqZlFRNHdzTDlkM3FKL3ZFbERLRlRPTmFVTkRa?=
 =?utf-8?B?Z1AwTzJpa3NGTzRKQ2JFQm1SdHllaG1wKzQ3NmsvbG5XTFk5ZUtieG93ckdE?=
 =?utf-8?B?alVlUHRUb1JpdUZrT2QxcDBtWlR3NXRBVGl1T3BNWDRxNUx0S2NoOHdzSElu?=
 =?utf-8?B?b3g3ckl1OGNBUTl2ZUF6MExzMG9yak9xcUxaMFA3Y0txejdEczlIVEdZR09W?=
 =?utf-8?B?em5RdFBOUTdOdUJUT2s0N2hRWWl3ajBsaDdpMW9xREZYVDFZS2czcjRPVTFx?=
 =?utf-8?B?VkpLcDlsVXBUVklQTytwMlJsQXBlWEhMUWowblRwTHBnUDM4a3dRaSt5dTFk?=
 =?utf-8?B?SGQ4UnkrZEl5b3VOUk9pK1RpMDh4Y3hSSitwMm91Q2xwLzBRdU5OMHJ3clAz?=
 =?utf-8?B?eDlzL3FCRXpWejQ5NUdXdkdXcUtwRGxWb1NCWHU1TmNmUWVpMTRpOW1HNkl0?=
 =?utf-8?B?a1BmTW5YRUw0Zy93UzJvcEoxQ0c5ZUpUK0p2RDEvWk0wMXhjMnFQeThOU3BB?=
 =?utf-8?B?cXNsRmN3bFFESXhEck1uM1FIeFJUWW1sYWFsSzdZVVlhWmU0WTFHVEpvTzVU?=
 =?utf-8?B?Q09CTzh0ZU9nNmN1ZGhwSm5OVnBYRTVtMHl2VVlmTC9OdmtJS1FNdUpCdElx?=
 =?utf-8?B?aC9yandNK3RSY0t6WUdpenFlY2d3L0ZiMUlEdW4zZ2Ird2QzZG1DVkhFRjl4?=
 =?utf-8?B?K3c9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dc608127-565c-4159-19af-08dd23cec6a1
X-MS-Exchange-CrossTenant-AuthSource: DU0PR03MB9199.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Dec 2024 03:55:16.0711
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b41b72d0-4e9f-4c26-8a69-f949f367c91d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: W+T0egVfXaDgzuNNxbNGnyJPyg7iPRjwqWDDD48AYaEQenPYPx08woYnTbn8uyLE1QYEZz8bqbQa3yCSuTUAdw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB10101

18.12.24 12:38, Julien Grall:
>>>>
>>>> Are you sure this patch is sufficient to use the late hwdom feature? 
>>>> Looking at the code, to enable the late hwdom, the user needs to 
>>>> provide a domid on the command line. But AFAICT, there is no way to 
>>>> provide a domain ID in the DOM0LESS case...
>>>>
>>>
>>> I append "hardware_dom=1" to xen,xen-bootargs in host's device tree 
>>> and it works.
>>
>> AFAIU, the domain needs to be explicitely created. How do you do that? 
>> Is it just describing the domain in the DT? If so, how does it work if 
>> there are multiple domain described in the DT?
> 
> I just had a look at the code. I don't see how this change and simply 
> adding "hardware_dom=X" is sufficient.
> 
> In addition to what I wrote above, Dom0 will be the first domain created 
> and we will assign all the devices and mappings. When the hardware 
> domain is created later on, dom0 will still have those mappings and 
> devices. That's unless you list all the devices in the device-tree as 
> not assigned to dom0 and then assign them manually to the hardware domain.
> 
> I would also expect that the hardware domain wants to use the same 
> memory layout as the host. But that's not necessary for the control domain.
> 
> So surely you need something more in the device-tree?

yes, I had to assign devices to hardware domain manually.

   -Sergiy


From xen-devel-bounces@lists.xenproject.org Tue Dec 24 04:03:41 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Dec 2024 04:03:41 +0000
Received: from list by lists.xenproject.org with outflank-mailman.862999.1274501 (Exim 4.92)
	(envelope-from )
	id 1tPw8u-0005Ht-8v; Tue, 24 Dec 2024 04:03:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 862999.1274501; Tue, 24 Dec 2024 04:03:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tPw8u-0005Hm-5C; Tue, 24 Dec 2024 04:03:36 +0000
Received: by outflank-mailman (input) for mailman id 862999;
 Tue, 24 Dec 2024 04:03: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 1tPw8s-0005Hg-Ty
 for xen-devel@lists.xenproject.org; Tue, 24 Dec 2024 04:03:34 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
 (mail-vi1eur05on20622.outbound.protection.outlook.com
 [2a01:111:f403:2613::622])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 0b25266b-c1ac-11ef-a0da-8be0dac302b0;
 Tue, 24 Dec 2024 05:03:34 +0100 (CET)
Received: from DU0PR03MB9199.eurprd03.prod.outlook.com (2603:10a6:10:470::22)
 by PA4PR03MB7309.eurprd03.prod.outlook.com (2603:10a6:102:102::20)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.21; Tue, 24 Dec
 2024 04:03:27 +0000
Received: from DU0PR03MB9199.eurprd03.prod.outlook.com
 ([fe80::3650:95ff:7db7:a5fe]) by DU0PR03MB9199.eurprd03.prod.outlook.com
 ([fe80::3650:95ff:7db7:a5fe%4]) with mapi id 15.20.8230.016; Tue, 24 Dec 2024
 04:03: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: 0b25266b-c1ac-11ef-a0da-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=k0eokMpPJBvXHvzxu6/mc/LyNgJVJZOUo6dgA/eNiV+475fcWVKuF20qDnOkiIDn0nuax/2xNgntY4eDAgesKIfSvihOcWc7wxonGSO0Yqq+QgiHUSEIIhFzCZWX2X5/+qLFP+H8NnqpLT8eTtnpKhGmTHTBVKguIsNpdwwfpbvCphvOdnRrBJHQI+2WNZY5RYcjqEReXH1+oxeBDIjEdtHHQKyt9vpcy1Wxk4kIYeoTSIOibXn0Ne+gNSGekwRWAHPqvSK7YvY0gBR+zv3UqPQNIrggArE7O1JRkM1WwkojpcAc6A/sqramK1yIT1MGNwxSzHUdkbDVCKv2Fq0pbg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=PxkUq2uyOraVRvPAP3nPyzvXgvL3W9dc+EYuJ+o0yE0=;
 b=hLfXuMTfHkbZHWxSw9B0/WdoIB5lCnv/jEz2h1lKTwGlzyUwYksO36r0hZu6lMDK+6aSFK84wwfbMsuvXg6leQjpG2WbRBte+nUhBqSi4pyalcWJzPRwQlUzeokPsbxRHSsitx9m/4phdeDFZIiPUD48DBm9Tjf5WPSIiUoqIx7AUZPuDjbLpGtp3p6PRNs9bEyHMxKD4u2DeW68QVHcU1kwcltrAwfdVurxLaCmZm+iDsJCrBqBRQE/k2pG/3rKxHg2wNoj52j4al9sP6jfbTfaiA8lYeJg9RsfZzEQULfnTE2MySE79OAX6H67HI1NgkX2wyA4MTYlCrr4vwFPiw==
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=PxkUq2uyOraVRvPAP3nPyzvXgvL3W9dc+EYuJ+o0yE0=;
 b=bxvqOtQ4nEkr1Uk7246tgZ27MWBztagNOqqZZ5AxjXjWyoqiFhjnhR9mygRmifomNayXBb5kXvLMiW9EX1ik3B3wwzPkV+8i4pxb3qcd8zagq14HDuLAmF0Rm2WuQwTsiYCIQj5X96Kl4+gJ53PzDPK5TJTuQbNnkkkEG5AEu8hi8b9H/02X1v4p67ex/1kJwGuAnAk+FojY/8/PkQTuJCvuWHpkpqV34PQp6NVmMDAxNA2XbKJERWl18mw5RS+g/HJC/nh8tZH8s+Jl5mnz6hPMksIokgtsnSYkQsCHF4Q/dsFYQYRuesVnrsAlTFqo2IlLtb+50BDuDADywvKTzA==
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=epam.com;
Message-ID: 
Date: Tue, 24 Dec 2024 06:03:24 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
To: Jan Beulich 
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: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
 <9003a677-e78b-4cf8-b890-c6cf432d5837@suse.com>
 <858496ff-b8da-4dd9-abd1-679dc4f67b30@epam.com>
 <6182abbf-7cc3-4075-9f13-55ebbdef6aef@suse.com>
Content-Language: en-US
From: Sergiy Kibrik 
In-Reply-To: <6182abbf-7cc3-4075-9f13-55ebbdef6aef@suse.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: WA2P291CA0038.POLP291.PROD.OUTLOOK.COM
 (2603:10a6:1d0:1f::8) To DU0PR03MB9199.eurprd03.prod.outlook.com
 (2603:10a6:10:470::22)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DU0PR03MB9199:EE_|PA4PR03MB7309:EE_
X-MS-Office365-Filtering-Correlation-Id: c8e1bcf2-6bf9-4922-74c0-08dd23cfeb7d
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:
	=?utf-8?B?cG1Da1YzTk92WDlhVkVVSnVDb0J2SnJRTm12amM3SzlmT0lvWXpXc0RMUzVV?=
 =?utf-8?B?NVROK1FOZDVMZ1lsQUgzcjlmOTZROWZJeDBlZUxmYkJKTnBBejRXNlZocThM?=
 =?utf-8?B?ZnBISGIrWkNMN0pIZnRjWExQN3BmMzdOeTdoN21oR1U4VUcwV0NsL1hsbFFK?=
 =?utf-8?B?UXUzSmZvSEtaZEx3aUtVeFV4aVBwNnJ5RXRJODE4VFEweGFCVUt5NFZQOW82?=
 =?utf-8?B?bUYrV1lYb0xZaHpVd205enlmakFqOEpGZkVSWndjNXFVR2ZtQU5CeC9ya2xt?=
 =?utf-8?B?VjdNWU5tdnl0a2swVFdWdC9vT2s4VWlBWjVWcGtTSG9vakdLZUtNR243ek05?=
 =?utf-8?B?N0FrQlMyeHZTeXN3V0twS3RaZWl2QWNHVldJWVhaeVZqWkZ4d3JuZndkbkZB?=
 =?utf-8?B?K0Q0YWRKWCtGN05hOHBWS1lOdWVZTTVOK3J5VnVXZDJTTk1CSEZTVGJSMTBs?=
 =?utf-8?B?OWRaakZjOUlvaVpRNU1iSUkybTBGTmZCd2VCVU9JZDFUWlE4ejFyckUvRUxn?=
 =?utf-8?B?bTQ1b0pzb1dxbkJacmgxZUo5akRBZFBYS0JwOE9xSjNkb0VzVzZOU1FGU05r?=
 =?utf-8?B?UmhyK2hOb2pSRi9YbjM5NlpHMTRQTW5IVGFYRGJWTUMvSURrUURuaEw0U0Va?=
 =?utf-8?B?aUhhbzVnZWI4aW9pZHdLSEJmNU1uOEJUVUMrOXpnazBIVTNwT3FoWFZEK01o?=
 =?utf-8?B?VmV4bmF3ZVpvTXY1ZFZZWlpESVZtemRrVkx0bm1SR3BWN2lyaGNTUDVqLy8y?=
 =?utf-8?B?Mjg3U1d2REhFMDZDU0JZTkY3VkpOaWxJV2t4YStjaUkwK1dXMFVIMS9tTjVm?=
 =?utf-8?B?d1R5eGJqT2pJR3dnUTRsTm9VUWFKQmJCOFk5YVBDUmtZcGNpZDFZeERDeTlw?=
 =?utf-8?B?RWorUUJmMWkzS2ZwRm45U001bUxobWQ5WjBsTjR1aW93M3ZBd0RmeEFvNFp6?=
 =?utf-8?B?eTdGdFlzVWNIUGJVUk9iWk9TdmZNMm9LYkl2VHd3Nm96Z2NoV1diVTc0NHR5?=
 =?utf-8?B?SDJyNzhlYlBKY3hxNmE1bnYzenJIZDZJTTFuLzBpVDZqYjdqa21HZVhzaEly?=
 =?utf-8?B?eHdmam5kZXFLTDJUVnppRktZVEVkZGpUZWJjQ0tnRVZqc0UyaEd2ZmYzUTdZ?=
 =?utf-8?B?cDRsbUFEYnh3dlB2QmYyR0V6YmpIbDMveU9ob2FRSDQxb09jNnExVFpxMXc5?=
 =?utf-8?B?WjNVOXhTSDJhcXZvQ0ZBWVdUcjNnU1pVQ2UwRDRJcmJFSUlaT3ZoWmgzSVBy?=
 =?utf-8?B?eldyY2xjUERsZkVNd0JpRmNjeHpCMEpjaG5TNm9QMUgvcGwzMm9NUjM0RlRF?=
 =?utf-8?B?aGc3Q3BMR2RwMkY4UFpvdmV6b2hZNGR4eXhZNTRENlByY3hpTXo5b0VTV1hk?=
 =?utf-8?B?VWQ2RlBwS2xHb2VCODZ1eHZ0cXFtQUZRYmpLTW9RU3VGdFpldmx3NEVlT2I0?=
 =?utf-8?B?N1VLd0JHMlM5Uk91U3FidjdyeXMvQWE0SGpZbE50NTFhWjVlTFhKUDZtV2cy?=
 =?utf-8?B?UVZvWldzVER4WFRIK2JaMS9lV2RVY1NsLzh5Q0lLbW1BeHI3aDJ6YkdwdFlR?=
 =?utf-8?B?OVFFSzVaODZTSFBKUWFrNE90b2lNQmtOdVVETmlycm1qOWVtTklDcXMraXp4?=
 =?utf-8?B?NHJDM1p4cVdsQTYvanYwSkxVTmsvb0NXdjRxcnVLMWNBSDBtUHZsVnNyVWNT?=
 =?utf-8?B?KzJnWk1UVWJKNGNyWnA3ckErdVVXOWR2Rllmbk5QS1MrUXhGQXNQdnF5US9E?=
 =?utf-8?B?TkNLL1ZHZWlwaWRmenk5c2dPTGk0cEhvWUVsZFdOTnJtYUJReDhTMTRIODRF?=
 =?utf-8?B?N1h2cmt2ZHhSOHE1Q2prK2pBY3NMZUhzU2hHT0lQdkF6QjdHRGJzc1pHREIr?=
 =?utf-8?Q?8yhAK+hTPZoKT?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR03MB9199.eurprd03.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?bitDTXRQQkQvTUVZbnVqRWFLdGxyUjRENmdLSDhaVnZXNUo0cENudm1ETFNJ?=
 =?utf-8?B?R0duZVZ0MjE0Vlo1Y3UzVWlNY2tlRjFPZWpFOHdRYVFKdmtoTlE5Z25zWVVD?=
 =?utf-8?B?L3N4emtmVzMxNmowalhHeWcwNVZxNnBuZmhsL2YyYkIxbEtNWlZwTmhDLzZi?=
 =?utf-8?B?ekFka1Q2ZEN2VnpqT2RDbkRrT3pmbERSRyt6Vkx0N3BBejR4OXVhaGU4clR6?=
 =?utf-8?B?Qm9hQjVET0l4RVFFbmtiOCsxekRlY09yZXFnWW1MYTdZSjZKdkJoR2FQRFpH?=
 =?utf-8?B?UmdTbFgwV3RaVjJCT21DalBKZGd3U0phKzAxcVIzeUNGSE1KV1FxeFRIS1VM?=
 =?utf-8?B?enkyNzQrZy8yMERRSlRnMEIvQjZCbWp1Q3ZKNWJVUmV6cm1hTklUNUM4UmVv?=
 =?utf-8?B?RVFiM0NNQlByZ2d1dVBFaUwraWxRdWdNcFI2L3JNcGM2VUVYMzRYaVprNXR2?=
 =?utf-8?B?bVJRbVZXc3Q5ZEhjclFkRkxjbVg2Zmh0bzlZeTY1UjNXMUlNcUgzSG9sSjQr?=
 =?utf-8?B?R054Uit4bGZ4WmdkSUlhSExsMTlQSEgvY2tMR3M4U2ZOTjRBT1JobzZPcjF6?=
 =?utf-8?B?S3RCSE8xNUtjVC9VTUZxYm9aNmhNaG9hdTdxWEdTR1NGUFh6TVlMakNIWWFo?=
 =?utf-8?B?QUlFQmFVMElybk53UVNPdk1ZNDBIUFZDVnhhd29odXFHYklZMmtoV0VNWXEv?=
 =?utf-8?B?WGh6WkV0WHV4SXZpSXpzbVdaZDFzQko0dUlHcWcyMDhOMm9lcTdFSTNBeTVO?=
 =?utf-8?B?Z1ozV2s0WU55RzFVNDFTL016dU8walZNQnJ1blNqU2hSNStOb0RweE1ZdXBZ?=
 =?utf-8?B?bEdQTVMvK25uTHcxWDhsSGl5T3duWDhLaFdZTDNTSTgxOENuMFhIb2xDOEF0?=
 =?utf-8?B?bDRaUzB4VTBRZm1GaXhXODRxVkNwc3pTQmNuNEd6MEpCNUd4OUxPemVBODlQ?=
 =?utf-8?B?SUtpYitYRUhpQXBweWk3cVlMOU5iODZYdmtCVnpUcTJjYWtvODRoWVAxbSts?=
 =?utf-8?B?UVpaZ0VWRlJnTmlhRUFVM1pXV2RZbWQ4SGQrMGE4emRDanRrdFArVXVjU3hy?=
 =?utf-8?B?MGdGa2dEQlBTb0EyM1BwbDIvZW05NFdCbS9LYkxJTHBrVXNSbmdPa1JieVFP?=
 =?utf-8?B?SHVGTkxCN2szN25sb0trOFRxZGZFa1pGMXpXWFFlWDlLZnUzNmExVmcrc1Js?=
 =?utf-8?B?cjF2dnp2R2NVU2NyaEZtcjdvNE04ZE9zTktScDNmVmhTRVh0cUtMcm4zeG8w?=
 =?utf-8?B?bWFVMWhrZ0xya3Q0L3hBRmE1V0Y5NXUzVDJMR0JuQTIyMXlMakdDTzYrOGd2?=
 =?utf-8?B?YWlHZ0VTSmM4N2cwclBRTnZWeStsK0RpSURETmVxSFhvSCtJd3FRcWd5L3Fy?=
 =?utf-8?B?TlpFZU93VkxwNm9UOUxzTVlpaG44REdlR2Jla0RJUXJYS0d4T2ZQOENwN1NB?=
 =?utf-8?B?YlhNdDJtTFNUZlo2cGZHaWRFc3hpSkZtMGR5ZTN5UlB2bW4vV1p0TXpJZmpx?=
 =?utf-8?B?QXRTeklHSXowWXZGVmdHQ0hic3h0bEFPN2RNTXpsUU83Z2ZYVWRMUXlMZGFt?=
 =?utf-8?B?cGRQVHlWa0VUMU8yaVlzTUdZLzlBMDMvbTdrUkIybWw0VEg4UkJvbEVhWlJK?=
 =?utf-8?B?NVpWT2JmNWlrNWptNk0wZjJuZWhaakJTV3lNcUxYWFRMU2dQK3paUkF6dEl3?=
 =?utf-8?B?L3R6Q0l4QStxYVNkZE5yc1JzZHFUOWVHblhUVXVkb3prQ1cveUF3Vkt4MjlP?=
 =?utf-8?B?Rk1rWUx0S3lEK0lsU2d3cWRWa01kTE9oQU1uSUZZaHVTeTdXdWhyaGk2VWFW?=
 =?utf-8?B?RU1OazJEOStUdncyTklPZGdKM1p4M2xNM1NkVVZ0cFBMY0t6RVFVN0UzNm9o?=
 =?utf-8?B?bUl1Z3Zwdmd6YXdLR0lhY0R2WFdHNkg0OFd4Y2plNzRuQWYyZThHMFVwcUhB?=
 =?utf-8?B?aEVFS01rR0d2cjhINCt5RUsyVGdqUXdGY0dOVUptNy81YmNoTmtmcmMxRmxp?=
 =?utf-8?B?OEVwZXhjd1hXNE5DaDgwdlkwVjZQNkg0OWdVQUpuNStwdDJOU2J6eURNYWpX?=
 =?utf-8?B?VjZNaDBBSTg3K3JmT3czMklqcXVFUzlPaEc5NWpVK1pIeWNYRkR3bXVmWmox?=
 =?utf-8?B?V3FnVEpmYWRidTF2QlVWZHpETCtsUldkY2ZGR01GZmlDVWJQMzdBbEJQc3pI?=
 =?utf-8?B?QVE9PQ==?=
X-OriginatorOrg: epam.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c8e1bcf2-6bf9-4922-74c0-08dd23cfeb7d
X-MS-Exchange-CrossTenant-AuthSource: DU0PR03MB9199.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Dec 2024 04:03:27.3877
 (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: 459CFsSCPfvWh9IcL05rNnt+awr2tXI/hx8eTRy5tKq4Jo+ylSQRiFBktqTh/qzpxRUUP3/MVO+GBx1125MBRA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB7309

19.12.24 09:55, Jan Beulich:
> On 18.12.2024 11:00, Sergiy Kibrik wrote:
>> 17.12.24 15:02, Jan Beulich:
>>> On 17.12.2024 12:47, Sergiy Kibrik wrote:
>>>> Allow to build ARM configuration with support for initializing hardware domain.
>>>> On ARM it is only possible to start hardware domain in multiboot mode, so
>>>> dom0less support is required.
>>>
>>> I don't follow this. Late hwdom is supposed to be started by a (minimal)
>>> toolstack iirc.
>>
>> Yes, on x86 it's started by toolstack. This is not supported on ARM.
>> However dom0less can already handle hardware domain initialization on
>> ARM, without much of an additional changes.
> 
> Yet that's not "late hwdom" then, but "separate hwdom and ctrldom" or some
> such.

indeed, "separate hwdom and ctrldom" more accurately represents what I 
was trying to do when using this late hwdom feature.

   -Sergiy


From xen-devel-bounces@lists.xenproject.org Tue Dec 24 08:20:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Dec 2024 08:20:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863015.1274511 (Exim 4.92)
	(envelope-from )
	id 1tQ08w-0000Ay-Qm; Tue, 24 Dec 2024 08:19:54 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863015.1274511; Tue, 24 Dec 2024 08:19:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tQ08w-0000Ar-No; Tue, 24 Dec 2024 08:19:54 +0000
Received: by outflank-mailman (input) for mailman id 863015;
 Tue, 24 Dec 2024 08:19: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 1tQ08u-0000Aj-H3
 for xen-devel@lists.xenproject.org; Tue, 24 Dec 2024 08:19:52 +0000
Received: from NAM02-BN1-obe.outbound.protection.outlook.com
 (mail-bn1nam02on20622.outbound.protection.outlook.com
 [2a01:111:f403:2407::622])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id d6ecb9a7-c1cf-11ef-99a3-01e77a169b0f;
 Tue, 24 Dec 2024 09:19:49 +0100 (CET)
Received: from CH0PR04CA0109.namprd04.prod.outlook.com (2603:10b6:610:75::24)
 by CH3PR12MB9283.namprd12.prod.outlook.com (2603:10b6:610:1cd::22)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8272.22; Tue, 24 Dec
 2024 08:19:40 +0000
Received: from CH2PEPF0000009D.namprd02.prod.outlook.com
 (2603:10b6:610:75:cafe::cb) by CH0PR04CA0109.outlook.office365.com
 (2603:10b6:610:75::24) with Microsoft SMTP Server (version=TLS1_3,
 cipher=TLS_AES_256_GCM_SHA384) id 15.20.8272.21 via Frontend Transport; Tue,
 24 Dec 2024 08:19:40 +0000
Received: from SATLEXMB03.amd.com (165.204.84.17) by
 CH2PEPF0000009D.mail.protection.outlook.com (10.167.244.25) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.20.8293.12 via Frontend Transport; Tue, 24 Dec 2024 08:19:40 +0000
Received: from SATLEXMB06.amd.com (10.181.40.147) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 24 Dec
 2024 02:19:39 -0600
Received: from SATLEXMB03.amd.com (10.181.40.144) 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; Tue, 24 Dec
 2024 02:19:39 -0600
Received: from [10.252.147.188] (10.180.168.240) by SATLEXMB03.amd.com
 (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.39 via Frontend
 Transport; Tue, 24 Dec 2024 02:19:37 -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: d6ecb9a7-c1cf-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=YsV+dursBR1/SezNDHnvcNzxmil0ZYBWodzakA1FuoxzV89UHphpmyx7UjMt8Xk/b8Mw6Ofvu7KtCbX5I69q0FmjNMlF55+eSIrSugpxUjMIF2rXxnlQCF6dl2ELUxCoTnq41ZjJk8tLuAHUQY3uqmC4HRPM1ma3BETimvRxzooIGqx6L+30To25LGERULEMaxn3OYCoBGZe4TmUVJF3lcYjlykOKeyqyzSHx2vOkrz3xjCGNxu3/bb14A/T30kte2Dcdc86GudLQ8mfJJVfVD0xEQRZ0g7ESAbtfF56VVaxjVeJIptf//cXTU9zO1sbyuIMOf+Pj3e1BtKhFlREQQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=IheoD8T6WcmNHBP/Bf8uWiJ8G5C3kdzfrXuT7wmxoJw=;
 b=T74uB5NzefsxTZOtO/fycWvIdpVLzFnAJ5CffQGsK0mzFEZ0d2XyQNZLsksSwXG6/8kUQoV9G8irqEA9nJ/PSzYfVLrfYE/eoCs11ktol+TiWTJ/wCbHEpCF0iI/En1kmbobChGRifkdIjfpN+PaB5opXfmctaY0kReA+Z+KM+QWnt/TlToPP70jl0QSDw11l2l8oNgzZrpYQGzob6we2HTClBQlcA11rHEF0jDNUAD/LQAPMhOcVWhqNLay1FGlykxQCmkBU5DkiCGaHykRMrTbzrjHt2tSwuXZ2ouwZfn0IfMnukbDCIBlQRHP8KU6vkg5BbGKxZ7vEdINV+V32g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass
 (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com;
 dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=IheoD8T6WcmNHBP/Bf8uWiJ8G5C3kdzfrXuT7wmxoJw=;
 b=lkSOYYzQcZ87/W8bdlr647Ngo6cl64oCq8dW6iNWc754Piub2yeBYBWT+iDj9DeRLOLn20fHeousWVjK1KS3UBxaIr+iQD2eJJBvrHuDDsXsRd15B4H5BTbqDxNxubFL4/GaxPp9gfa9Zs1pGefyX1N+IKBFjQIOz7Zo4x36WDY=
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=SATLEXMB03.amd.com; pr=C
Message-ID: 
Date: Tue, 24 Dec 2024 09:19:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] xen/arm: Initialise memory type for struct kernel_info
To: Luca Fancellu , Julien Grall 
CC: "xen-devel@lists.xenproject.org" ,
	"Stefano Stabellini" , Bertrand Marquis
	, Volodymyr Babchuk 
References: <20241220151941.4192864-1-luca.fancellu@arm.com>
 <2a7ac358-7f43-4e32-9e1e-9ce1cd45304a@amd.com>
 
 
 <7b7d4606-86fe-45c1-9aa0-48ddfacabafb@xen.org>
 <3188C56B-6BF1-4488-9036-33014B469A01@arm.com>
Content-Language: en-US
From: Michal Orzel 
In-Reply-To: <3188C56B-6BF1-4488-9036-33014B469A01@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF0000009D:EE_|CH3PR12MB9283:EE_
X-MS-Office365-Filtering-Correlation-Id: 439908a4-758a-4337-7a0d-08dd23f3b66d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
	BCL:0;ARA:13230040|82310400026|1800799024|376014|36860700013;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?MjhnMzRUQk56aU92aGxNbjl0dnJPK2o1amFpckdmZDl1RjlLalJmTzFDdHZm?=
 =?utf-8?B?bFl2MTloR2lKZXl6aXVXMDNJbFlYUThOU0I0WC84cFZwUHN6RG9VR0tjd2Vh?=
 =?utf-8?B?cTVHWUhJTm8vYjdFRGNLQzlPbTBsbVh0MWt6OVJFT3dJK2o2WmpuVmtUa2Zi?=
 =?utf-8?B?VUpTS1BJcEZzS1FFNDJpZzJmUEE1ZkRRL01tQmdRRkhaR3RQL0h1VlBLelRs?=
 =?utf-8?B?ZU9PMk10cTczOTlUbEZCM21QMFJXdk53Z2M3WlI5M242OSthTWlQMGxiRUd1?=
 =?utf-8?B?Q3Z5ZnVIZU5uS1NqODIvQ3lvdnFoQTFMQUIxcUcxeVZxckVxSmtQMTNFSWhl?=
 =?utf-8?B?SzBueGxseEcwbzgxNHpIeENPWStXVmpUOUlUWWN0ZFFZR0dKemJyZnZRZEF5?=
 =?utf-8?B?NUZ0czB1S2VTWGVPZzJJbGUraEhMUERBbVdOSjNyQlJBaVFQbENRWHQvVita?=
 =?utf-8?B?d2pmQXZ4MWZSdDlzTXF2U3dlNTgxb21idjNSVVk4S0x3S3lQcXZVZTl0SnhQ?=
 =?utf-8?B?UkZZZ3FGZGtXWnQyc3pGYXNackl5dlVkc3FITjh2WVh5aG5rVjZ5VU9kaE5Q?=
 =?utf-8?B?aG9DM0JEZHVTbUVyVEtTK3JCaDQ3YitHZ29ZL2FvWjd3U05WVCtKSEFpOTFY?=
 =?utf-8?B?ODZvcWJMYUZjbzV6K0FsVXVsc3JiNmdKTXc0bGRLbmNVbVR5VEowaURPbDVi?=
 =?utf-8?B?a3d5eG5WQWVraFVkMzh2OFlXSktPb2tJcFhmQXgweUEraGRFQU9laDd6M3h5?=
 =?utf-8?B?YzVqY1owRlQvY2FWaUhpUG5TOUhRQjl1ZmNrNC9CZ3VmUlZQWFFKZmJTL2xl?=
 =?utf-8?B?Wm1nRGwxR3EwcjB0aXFNTjFSNFVHKzZDTjYrbTVQU3ZuUUM3dXFsaVJWakF5?=
 =?utf-8?B?WTFqZGE0dGIya1pZVXR1blVuZVZUMkN6dERTT09mZ2t5WDJTV25FWkpLWTRB?=
 =?utf-8?B?eXNabWhvWFZOa1MwcVhyVU1ydEdHemk5V2srT2hRY09xY0NYVWtPTlF1WnJR?=
 =?utf-8?B?RHZ5ckQyd2NGN2p6V1ZtZEtXbFlKUExDRnFUM2N4c2l1VHVaL3dRWFRMOVJK?=
 =?utf-8?B?NmorbFhDNHFkTE84L0JublIrRTE2RWp0R3B6cVZLcWllVTBVOEp0ZHJQTDFZ?=
 =?utf-8?B?SE1vcXdxdlp5SGcvRk9mai9pT2g4SDhONVphc2w3MEJtSVl5d0R3WVh4dmhS?=
 =?utf-8?B?Q3R1Q3NGZXEwaWtSZTRkQkdNTitCOG4rcDlycm5uckZuclJFSFhTckh3Yjhw?=
 =?utf-8?B?Qm5ZOUNNZEp3Vk5sOEVrTUxtWG4xN3dhZ2h4RERUU2ZKcG42U2FiakhsV1Zp?=
 =?utf-8?B?QXJBNzFDMWNNaU9UNmdXS3lSekZZM1ZmZllmdExkMXJ1RERQUkd4QjVKaXBZ?=
 =?utf-8?B?MFh5K1p1Q1Rtb3h4MElMb2E3MUtpeDRPZ1Aybmo4NCt5WFY3cFl6TUVaS1lF?=
 =?utf-8?B?Zkprc3U3L2xEVWkxTWxVRGtYc3MvZUd2cFVpeWkzSFhUU2ZzZDloM2JETlNR?=
 =?utf-8?B?M2RzZ01vMWY1NkxoUXVYaEcwU2ptenNKc0prRXJhTWdNMGRTSmJ0SzIxVC93?=
 =?utf-8?B?Yms4VWQ5aVRLcit0TUNVWkFKdFg4alczUjJ4eDB0ODRlTmhrSjZFUmZIQUkw?=
 =?utf-8?B?TWxjVGJrSnhuMlVQVUtYVEJ1SUcyR3p0YVkwbUZKdjlaMDJzVnVudWNEV2pY?=
 =?utf-8?B?R0hGVTc5bWJUWFk3VDF0UkFnVk56VVhvazk3V2ExaEd4SWIyU1ZFR3hDLzdm?=
 =?utf-8?B?R3pJeTlmeHorUExhdStMT043cmYyQ1ZycGJaeXdUazN6Mm1HZmtxVmpzMzJs?=
 =?utf-8?B?SHJaYjVOK3premZNNjZ4ekZ6YTd1V1A3QS81U2EySmVURXBId1F5SUtaVlls?=
 =?utf-8?B?YVArczcyNHdidGdXZkdvWWFGUjZoWmh0dlNFODIxcXRuUEI0bzdoM3F1OW1B?=
 =?utf-8?B?TkZndXFaRm1wb1h1M2hJVi81K2JxaTdGOWFkc2lZdFMrZ0lPRU11eGN0Vlo2?=
 =?utf-8?Q?GfZZ/lq3XGyaZNyfELcHNB4MYw85w4=3D?=
X-Forefront-Antispam-Report:
	CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(376014)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Dec 2024 08:19:40.0193
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 439908a4-758a-4337-7a0d-08dd23f3b66d
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=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CH2PEPF0000009D.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9283



On 23/12/2024 11:52, Luca Fancellu wrote:
> 
> 
> Hi Julien and Michal,
> 
>> On 23 Dec 2024, at 10:45, Julien Grall  wrote:
>>
>> Hi,
>>
>> On 23/12/2024 10:42, Michal Orzel wrote:
>>> On 23/12/2024 11:06, Julien Grall wrote:
>>>>
>>>>
>>>> Hi Michal,
>>>>
>>>> On 23/12/2024 07:58, Michal Orzel wrote:
>>>>>
>>>>>
>>>>> On 20/12/2024 16:19, Luca Fancellu wrote:
>>>>>>
>>>>>>
>>>>>> Commit a14593e3995a ("xen/device-tree: Allow region overlapping with
>>>>>> /memreserve/ ranges") introduced a type in the 'struct membanks_hdr'
>>>>>> but forgot to update the 'struct kernel_info' initialiser, while
>>>>>> it doesn't lead to failures because the field is not currently
>>>>>> used while managing kernel_info structures, it's good to have it
>>>>>> for completeness.
>>>>> The last part "good to have it" does not sound like we need a Fixes tag.
>>>>
>>>> Reading the discussion, it sounds like ".type" is not always set and
>>>> this is not properly documented. This means that in the future we may
>>>> write a patch that requires to use ".type" and needs backported.
>>>>
>>>> But this would depend on this patch which was not tagged appropriately.
>>>> Therefore, I would argue it needs a fixes tag (even though this is a
>>>> latent bug) or at least a backport request.
>>> Setting explicitly a type for structures not requiring it, does not seem beneficial for me.
>>
>> I have to disagree. If we set type everywhere, then the developer doesn't need to think whether ".type" is garbagge or not.
> 
> So, my thought was to at least initialise it on the structures that goes around in the codebase,
> gnttab in find_host_extended_regions and shm_heap_banks in static-shmem.c usage are less
> spreaded.
> 
> However I have no objection to always initialise them all, so that anyone sending patches that
> use them, don’t need to think if the field is initialised or not.
> 
> I’m currently on leave, is it ok to wait until new year if any change is required?
Hi Luca, yes, please send a new revision once you're back.

~Michal



From xen-devel-bounces@lists.xenproject.org Tue Dec 24 08:40:01 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Dec 2024 08:40:01 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863028.1274520 (Exim 4.92)
	(envelope-from )
	id 1tQ0SK-0002y7-Ev; Tue, 24 Dec 2024 08:39:56 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863028.1274520; Tue, 24 Dec 2024 08:39: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 1tQ0SK-0002y0-CR; Tue, 24 Dec 2024 08:39:56 +0000
Received: by outflank-mailman (input) for mailman id 863028;
 Tue, 24 Dec 2024 08:39: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 1tQ0SJ-0002xu-4v
 for xen-devel@lists.xenproject.org; Tue, 24 Dec 2024 08:39:55 +0000
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com
 [2a00:1450:4864:20::52e])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a54972ac-c1d2-11ef-a0da-8be0dac302b0;
 Tue, 24 Dec 2024 09:39:53 +0100 (CET)
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5d437235769so2114729a12.2
 for ; Tue, 24 Dec 2024 00:39:53 -0800 (PST)
Received: from ?IPV6:2003:ca:b711:5c39:9cff:9fff:3d81:6f3c?
 (p200300cab7115c399cff9fff3d816f3c.dip0.t-ipconnect.de.
 [2003:ca:b711:5c39:9cff:9fff:3d81:6f3c])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5d80679f19fsm5846593a12.45.2024.12.24.00.39.51
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Dec 2024 00:39: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: a54972ac-c1d2-11ef-a0da-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1735029593; x=1735634393; 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=K/NoVEctWS4l3fPRjtycCBEAjYeRehZDCpHqeWxScuI=;
        b=LbAx8BNlBls9Q651OQdhr6mIZYRkDzMSx+bjtR15lrHuhd75gfJpoU8cy1CftZwBgA
         z6WetU8bqUeLZaF4Lus9PiUn/PV4fEU1p9+DdhH4baAtFHu628E/omxxaWceiNSjj/SU
         s5SQgpQa+rlOtG/beqomQJQqYjnX8fAx7mvCMkOyDSBhxToU6+NYv9NKfSgDrUkbf2ml
         jo8CV8gH1GLIPuLV9IWMssok6RvMiVSteX1YhOdmFH4nBzg+dwSWdkl09Hv27MZ8kmYw
         KWrTr4d/8HpJJ86Vzqino/nTXir9pywrVxR4oJkepT14ER43gJ2CPmosRWi2CeLxjONT
         HOMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735029593; x=1735634393;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=K/NoVEctWS4l3fPRjtycCBEAjYeRehZDCpHqeWxScuI=;
        b=p2pUPfChSkQ5kIdw3PE2aOwADUNgEe4KWcUR512jQjIh9esrEtmaDlFJKSwycB8Eqa
         Xy0jb1mZccsbiAs4AANmtG0ZHosZhw/XOteNyIH5BweavEdfuE4VYoOPXewH9/WDJAD5
         UEvfg/tCgQ7cq3XLxUWeSQmvBC3k0w60EfsCm31gS0MghAkpofMvUa0LyZNDCspPQwKk
         vkeLVSDKsWwjV8ESfnOrRKQDunap94L3FYJbpp80dHiHvtrj5WVV8Wo3X5sAe+oRQF/J
         xsLX2PpB2bxSTlVCMu2vR8fNUWb8Irnfv051g1EkVZVVj1NGqHL4O8danoOlwdybKYGd
         z5/w==
X-Forwarded-Encrypted: i=1; AJvYcCXqTFgrLVUf+bjXs/MzBpFm3zLpu7MYx7fKfhP1ficQKbaosa98MpPY9EkqRWf4Xinzxih6F7yPjNE=@lists.xenproject.org
X-Gm-Message-State: AOJu0YydL/CJMjkDbcatQobrfI3U8cNpVhH9jOptyAtnxB2xP/eOTBu1
	qnkvhMt5JFSGOm6R4GaKPcKW6h2bmafUdWx+GnN3rNwpCtL4sWJg4Pk/RvHd2w==
X-Gm-Gg: ASbGncvmW5YIYPcGV8/7s/yNOQrb32rp9V0ZpVCufOdIN61sHW6xTNXCzEajSnk4Nmb
	kXY+84VAE3Ezo4vPCvxcfUmAk05mJ61Jk5VdDMjcnYTemnnDh/8kTNhOhrZkRWLItfU/L+alA7P
	NStWAVf4pJuK2sbiBo702u2Qyohkf0Dd0/J2CMUaBFkFK/Wims5actp8/3PVTGBx2hNaevdatHp
	IWkLcriTsvrjxHXuO+87aaveW+WY4+U6VznEYkbMpGktq0lWf2Ksz4g9ArCINz7oozlSyFa4hSq
	CMzTgc80i1j/m2DkFQqYlQKc/7YouJVmU1mdf7F84ErdQwPSMWZ2WH94+fMn4lxnjZpiiRDShpj
	ehwo1lI70QrjHDk4=
X-Google-Smtp-Source: AGHT+IGwrvrSruFMWNSjdfkDS/bSYVPSM+sf1sqvz6Uj+qiFnpD6jANyFiuK0ykrHmUr0EcbJvc+Kg==
X-Received: by 2002:a05:6402:270d:b0:5d2:73b0:81e8 with SMTP id 4fb4d7f45d1cf-5d81dd820admr12901857a12.9.1735029592803;
        Tue, 24 Dec 2024 00:39:52 -0800 (PST)
Message-ID: <69b4de29-9de7-4ee3-a44b-bf4961bb19c2@suse.com>
Date: Tue, 24 Dec 2024 09:39:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] x86: Add Support for Paging-Write Feature
To: =?UTF-8?Q?Petr_Bene=C5=A1?= 
Cc: Tamas K Lengyel ,
 Alexandru Isaila ,
 Petre Pircalabu ,
 Stefano Stabellini , Julien Grall ,
 Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Andrew Cooper ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 xen-devel@lists.xenproject.org
References: 
 
 <258c4e83-4379-4212-b80a-4fe909849e66@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 20.12.2024 17:34, Petr Beneš wrote:
> On Fri, Dec 20, 2024 at 2:09 PM Jan Beulich  wrote:
>>
>> To avoid the flag becoming "sticky", I think you need to clear it ahead of
>> this switch() (or right at the start of the function).
> 
> When thinking about it now, wouldn't it make sense to only reset it in
> the p2m_ram_rw case above? I mean, where else would be guest
> page-tables located.

I'm afraid that unless you can prove otherwise, my general take on such is
"you never know".

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 24 08:43:07 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Dec 2024 08:43:07 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863035.1274530 (Exim 4.92)
	(envelope-from )
	id 1tQ0VO-0004Xy-Se; Tue, 24 Dec 2024 08:43:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863035.1274530; Tue, 24 Dec 2024 08:43:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tQ0VO-0004Xr-Q4; Tue, 24 Dec 2024 08:43:06 +0000
Received: by outflank-mailman (input) for mailman id 863035;
 Tue, 24 Dec 2024 08:43: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 1tQ0VN-0004Xf-7t
 for xen-devel@lists.xenproject.org; Tue, 24 Dec 2024 08:43:05 +0000
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [2a00:1450:4864:20::631])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 1718ee2c-c1d3-11ef-a0da-8be0dac302b0;
 Tue, 24 Dec 2024 09:43:04 +0100 (CET)
Received: by mail-ej1-x631.google.com with SMTP id
 a640c23a62f3a-aa6a92f863cso647554666b.1
 for ; Tue, 24 Dec 2024 00:43:04 -0800 (PST)
Received: from ?IPV6:2003:ca:b711:5c39:9cff:9fff:3d81:6f3c?
 (p200300cab7115c399cff9fff3d816f3c.dip0.t-ipconnect.de.
 [2003:ca:b711:5c39:9cff:9fff:3d81:6f3c])
 by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-aac0e89595fsm631741366b.66.2024.12.24.00.43.03
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 24 Dec 2024 00:43: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: 1718ee2c-c1d3-11ef-a0da-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1735029784; x=1735634584; 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=NRsv3Pew46/5knXCm23QGnN+W3B7FIWICmjnciREfFs=;
        b=bs90Ke1kRZ+hpAXWI8Kzg7B5mUY63i/QCppRaq3sv/gExv0lw0YGcFmkWzgn2ZTkPE
         gwSHgmyJHMxXzasOaQQTB6SBagZfxPFAaZFK0jyqfB+MnFDn+EvKFv50wOyWOwrk9us/
         9UuvnLV4s2+QzK6Q6Hbyjd/+9D8zF5GpvonowKaClZqaKsLuKxTgOg+/or60e56280s1
         fMlvXiZk2ZqFJQi0WdqzH1AOZfUliSYQ42/XHY0FFYmLELxMK6KfFah3uNuJRDSg5K7p
         MoOWhXXQH01eqPoJ0UKbS9jJIBIVL6mvj0PRzC0Mm+3QoSIVpJxa5QUe7Xw3zd2QDskJ
         sewQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735029784; x=1735634584;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=NRsv3Pew46/5knXCm23QGnN+W3B7FIWICmjnciREfFs=;
        b=sZ3px/0FG4+AQfGL2/VS1icMr7hojldgp++lxLZF0dNX4bB9tnLYfuOWw3PwSx3ZSD
         YZLJoxdd3ZiDoJjBoxfJDRI+QxdOrvJC+vCFI/p737TtXCTqbSt+Vc99g4oHV4B6pi4n
         tDzum7eXIyYOgS17ATCs2D7cg/qQkCm9hsq6EizFsSG8nN+AEZk6ytzWw5PSg7sniqsS
         nvYPUH2dUjhLYnbVElYL2s4pwStNxTHx3dVtHnD9ohCVvmh2nhqf+fej1zhyXz0htiYn
         0ZBCUtalMYzsD6Jev1/8mdD+shhdmx5dL6POkB8mwr1FfdcD54OR0y4bgrMBowb98Dpi
         9a9w==
X-Forwarded-Encrypted: i=1; AJvYcCUAP4xN/W2wqn93Xcy6efuTVsUM67K1fgVMH+V+QDyabOZd8tp4t+rsysFUSAFBUzBysEgkT6HJFJY=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxHPihwrl0KMZYBuoMS5OkAb9zH1fmAGjUWVwU8ebt/oNQtiyMs
	ciMTNXfjTgFqTgrY99b79tT+o41G1AD8TF8ICWChs2A3lTa6AuB298Jhvav9taFOvlSoV+yYzmo
	=
X-Gm-Gg: ASbGncuMqjewip2y1kWOZ4TEOUfe7a0w9QeYVSZOkA3yK2+OVjBnqVckzor/gDnaFov
	q/mGxPdKhqQ8B/YNb6qNvD7o+uQQwroqlYLDeD1GxewIxxsEGHEwNfPup7l83QPXQyr1t+HyMv5
	633B7GHLnqToLpKR73aQc0RRFA8KKNbIhK7g7yUgBT6/ubI8/z0gQx8dxwU1y+pDI7kYGGnQSsW
	EBgTNbU7LorsTdd3abnyQxIHezXe829OtKlMtVJgqmaqAqnq5ocrOeJ6hRz8WOX7P1kxOZk0Liz
	AuZ5bGZ35uo6qTXvq59RlDyxQXdVPZVL2ZsuMdOifJBPhDnVJvRxG1z8LUDtHOlOrMvzGh/VjnM
	DIXUIuL8jd9inoNw=
X-Google-Smtp-Source: AGHT+IGwV0VC/S8HtPY9g2kQXo/82KbmUQYoUrfGukndvNMNu3wTLeP0rEqGXCT8aXP2SePm3v07jg==
X-Received: by 2002:a17:907:3e90:b0:aa6:abb2:be12 with SMTP id a640c23a62f3a-aac3354ff4dmr1153566266b.37.1735029783718;
        Tue, 24 Dec 2024 00:43:03 -0800 (PST)
Message-ID: 
Date: Tue, 24 Dec 2024 09:43:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] xen/tools: remove dead code
To: Ariel Otilibili 
Cc: Doug Goldstein , xen-devel@lists.xenproject.org
References: <20241220165837.937976-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241220165837.937976-3-Ariel.Otilibili-Anieli@eurecom.fr>
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: <20241220165837.937976-3-Ariel.Otilibili-Anieli@eurecom.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 20.12.2024 17:55, Ariel Otilibili wrote:
> Default switch case exits directly; these instructions are never reached.
> 
> The file was taken from Linux; the copies have diverged a lot since:
> 
> ```
> $ diff -u xen/xen/tools/kconfig/expr.c linux/scripts/kconfig/expr.c | wc -l
> 984
> ```
> 
> Therefore the change is only applied locally.
> 
> Coverity-ID: 1458052
> Fixes: 8c271b7584 ("build: import Kbuild/Kconfig from Linux 4.3")
> Signed-off-by: Ariel Otilibili 

As the title of the commit referenced already clarifies - this is once
again code we took from elsewhere, so imo wants updating at the origin
first. Then import that commit into Xen.

Jan


From xen-devel-bounces@lists.xenproject.org Tue Dec 24 13:54:40 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Dec 2024 13:54:40 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863057.1274541 (Exim 4.92)
	(envelope-from )
	id 1tQ5MY-0004s9-Tc; Tue, 24 Dec 2024 13:54:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863057.1274541; Tue, 24 Dec 2024 13:54: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 1tQ5MY-0004s2-QZ; Tue, 24 Dec 2024 13:54:18 +0000
Received: by outflank-mailman (input) for mailman id 863057;
 Tue, 24 Dec 2024 13:54:17 +0000
Received: from mail.xenproject.org ([104.130.215.37])
 by lists.xenproject.org with esmtp (Exim 4.92)
 (envelope-from ) id 1tQ5MX-0004rw-FJ
 for xen-devel@lists.xenproject.org; Tue, 24 Dec 2024 13:54:17 +0000
Received: from xenbits.xenproject.org ([104.239.192.120])
 by mail.xenproject.org with esmtp (Exim 4.96)
 (envelope-from ) id 1tQ5MW-002Idi-2F;
 Tue, 24 Dec 2024 13:54:16 +0000
Received: from [15.248.2.30] (helo=[10.24.66.98])
 by xenbits.xenproject.org with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96)
 (envelope-from ) id 1tQ5MW-000vFd-21;
 Tue, 24 Dec 2024 13:54: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" 
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=nG9Jt/w7ebfIKWHcuFPsgeZVbjLuMvkAfS4xzTDtxGc=; b=fTXN0484EVnhWHtYvHxIslpfsc
	1IzsHrj1uZ0yZPLMWXJy/xdF0Zt49CC5cze8bNZKi30sSORv66EoFSw6MmQoVY2sVBkzNVRIiRUIy
	+hhERT3/tlyVZwQZE8PvCY5gSJa/sIPgCV380k9C+8mV0IoTDV+idK+BCcZTTyIxkaWI=;
Message-ID: <12f210d1-e117-4b72-a168-1acf47c99a6d@xen.org>
Date: Tue, 24 Dec 2024 13:54:14 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM
Content-Language: en-GB
To: Sergiy Kibrik , xen-devel@lists.xenproject.org
Cc: Andrew Cooper ,
 Anthony PERARD ,
 Michal Orzel , Jan Beulich ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 "Daniel P. Smith" 
References: <20241217114719.2870676-1-Sergiy_Kibrik@epam.com>
 <4e437c60-4fee-40ed-9d2a-789bac0b36d9@xen.org>
 <5246aa98-d23c-41d5-ba14-c12b0a2ee9af@epam.com>
 
 <16694707-ce8b-4c4e-a6ec-2190b8124735@epam.com>
From: Julien Grall 
In-Reply-To: <16694707-ce8b-4c4e-a6ec-2190b8124735@epam.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Replying your last two replies in the same thread.


On 24/12/2024 03:41, Sergiy Kibrik wrote:
> 18.12.24 12:05, Julien Grall:

 > yes, I had to assign devices to hardware domain manually.

I think it would be easier for the user to say "This is my hardware 
domain" and let Xen assign all the devices, generate the device-tree & co.

>>>> On 17/12/2024 11:47, Sergiy Kibrik wrote:
>>>>> Allow to build ARM configuration with support for initializing 
>>>>> hardware domain.
>>>>> On ARM it is only possible to start hardware domain in multiboot 
>>>>> mode, so
>>>>> dom0less support is required. This is reflected by dependency on 
>>>>> DOM0LESS_BOOT
>>>>> instead of directly depending on ARM config option.
>>>>
>>>> I am a bit confused with the explanation. We already have an 
>>>> hardware domain on Arm. It is dom0. So what are you trying to 
>>>> achieve? Is this remove some permissions from the hardware domain?
>>>
>>> I agree, it should have better description.
>>> This is to split dom0 permissions into control-only and hardware-only 
>>> domains, much like it can be done in x86.
>>
>> I don't believe you need the late_hwdom feature to do that on Arm. In 
>> the case of dom0less, you are creating the domains at boot, so at the 
>> point you can decide who does what.
> 
> I'm not sure which mechanism to use for this. Can it be done by XSM 
> policy management?

For hyperlaunch, Christopher and Daniel proposed to specify the domain 
permissions (e.g. control domain, hardware domain) in the device-tree. I 
think we could re-use a similar approach. See 
docs/designs/launch/hyperlaunch-devicetree.rst for more details.

> 
>>>
>>>>
>>>> If so, why can't the hardware domain stay as dom0 and you remove the 
>>>> feature you don't want (e.g. control domain)?
>>>
>>> control domain is still needed, but as a separate instance & without 
>>> hardware access.
>>
>> Sure. But the control domain doesn't need to be dom0, it could be 
>> dom1, right?
>>
> 
> I suppose it can. But again -- how do I make dom1 (or any other) a 
> control domain instead of dom0?

See above.

> 
>>>
>>>>
>>>> Are you sure this patch is sufficient to use the late hwdom feature? 
>>>> Looking at the code, to enable the late hwdom, the user needs to 
>>>> provide a domid on the command line. But AFAICT, there is no way to 
>>>> provide a domain ID in the DOM0LESS case...
>>>>
>>>
>>> I append "hardware_dom=1" to xen,xen-bootargs in host's device tree 
>>> and it works.
>>
>> AFAIU, the domain needs to be explicitely created. How do you do that? 
>> Is it just describing the domain in the DT? If so, how does it work if 
>> there are multiple domain described in the DT?
>>
> 
> Indeed, in my case it works only because there's single domain 
> description in DT.
> If there're many domains in DT, we can't be sure which domain ID each of 
> them would receive at boot, right?

Correct. We don't (and should not) make any guarantee on the ordering. 
If the domid matters, then we would need to introduce a new property 
specifying the domain.

Cheers,

-- 
Julien Grall



From xen-devel-bounces@lists.xenproject.org Tue Dec 24 14:52:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Dec 2024 14:52:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863071.1274551 (Exim 4.92)
	(envelope-from )
	id 1tQ6GJ-0003Sf-TA; Tue, 24 Dec 2024 14:51:55 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863071.1274551; Tue, 24 Dec 2024 14:51:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tQ6GJ-0003SY-PS; Tue, 24 Dec 2024 14:51:55 +0000
Received: by outflank-mailman (input) for mailman id 863071;
 Tue, 24 Dec 2024 14:51: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 1tQ6GI-0003SP-JP
 for xen-devel@lists.xenproject.org; Tue, 24 Dec 2024 14:51:54 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 9c41736c-c206-11ef-99a3-01e77a169b0f;
 Tue, 24 Dec 2024 15:51:52 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 24 Dec 2024 15:51:51 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 9c41736c-c206-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1735051912; x=1766587912;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=rtYfxr4IOwDyWz8niZH2jULR0f21TW0CSSGmypmbacs=;
  b=EInCkmrKxWEL6cRlGwTkWKAuB0tVXrb5VMfyv1t1NkC4giJiFnO4dIXI
   jL//sS6jh7koYDdMBAeummiKsVTH6dPHZl7/Gg0bJzvva/WX56a670IFo
   aVyf3rubXzYGLAa2uYqE0CkoAEUvHhcAYoyZC80PCH1+r3x2gbvodGiK1
   k=;
X-CSE-ConnectionGUID: t0abkAKgSKq4AkF4hhYuTA==
X-CSE-MsgGUID: A7wwEnwnQCGTnZE91y98ww==
X-IronPort-AV: E=Sophos;i="6.12,260,1728943200"; 
   d="scan'208";a="28312345"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"
X-Forward: 149.5.228.1
References: <20241220165837.937976-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241220165837.937976-3-Ariel.Otilibili-Anieli@eurecom.fr> 
Date: Tue, 24 Dec 2024 15:51:51 +0100
Cc: "Doug Goldstein" , xen-devel@lists.xenproject.org
To: "Jan Beulich" 
MIME-Version: 1.0
Message-ID: <2f7a8b-676aca80-518b-be99fc0@193695621>
Subject: =?utf-8?q?Re=3A?= [PATCH 2/2] =?utf-8?q?xen/tools=3A?= remove dead code
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 2802

On Tuesday, December 24, 2024 09:43 CET, Jan Beulich  wrote:

> On 20.12.2024 17:55, Ariel Otilibili wrote:
> > Default switch case exits directly; these instructions are never re=
ached.
> >=20
> > The file was taken from Linux; the copies have diverged a lot since=
:
> >=20
> > ```
> > $ diff -u xen/xen/tools/kconfig/expr.c linux/scripts/kconfig/expr.c=
 | wc -l
> > 984
> > ```
> >=20
> > Therefore the change is only applied locally.
> >=20
> > Coverity-ID: 1458052
> > Fixes: 8c271b7584 ("build: import Kbuild/Kconfig from Linux 4.3")
> > Signed-off-by: Ariel Otilibili 
>=20
> As the title of the commit referenced already clarifies - this is onc=
e
> again code we took from elsewhere, so imo wants updating at the origi=
n
> first. Then import that commit into Xen.

Indeed, Jan; thanks for the feedback. I am pushing a new series for thi=
s hunk; it was fixed in Linux.
I think in commits dfe8e56fc604 ("kconfig: add fallthrough comments to =
expr=5Fcompare=5Ftype()"), & 9ad86d747c46 ("kconfig: remove unreachable=
 printf()").

```
$ diff -u xen/xen/tools/kconfig/expr.c linux/scripts/kconfig/expr.c | s=
ed -ne '/expr=5Fcompare=5Ftype/,/return 0/{N;p}'
 static int expr=5Fcompare=5Ftype(enum expr=5Ftype t1, enum expr=5Ftype=
 t2)
 {
        if (t1 =3D=3D t2)
@@ -1106,30 +999,27 @@
        case E=5FGTH:
                if (t2 =3D=3D E=5FEQUAL || t2 =3D=3D E=5FUNEQUAL)
                        return 1;
+               /* fallthrough */
        case E=5FEQUAL:
        case E=5FUNEQUAL:
                if (t2 =3D=3D E=5FNOT)
                        return 1;
+               /* fallthrough */
        case E=5FNOT:
                if (t2 =3D=3D E=5FAND)
                        return 1;
+               /* fallthrough */
        case E=5FAND:
                if (t2 =3D=3D E=5FOR)
                        return 1;
-       case E=5FOR:
-               if (t2 =3D=3D E=5FLIST)
-                       return 1;
-       case E=5FLIST:
-               if (t2 =3D=3D 0)
-                       return 1;
+               /* fallthrough */
        default:
-               return -1;
+               break;
        }
-       printf("[%dgt%d?]", t1, t2);
        return 0;
 }

$ cd linux/;=20
$ git log --oneline -1 --pretty=3D'%h ("%s")'
8155b4ef3466 ("Add linux-next specific files for 20241220")
$ git remote -v=20
next    git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.g=
it (fetch)
next    git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.g=
it (push)

$ cd ../xen/
$ git log --oneline -1 --pretty=3D'%h ("%s")'
6419020270 ("CHANGELOG: Mention LLC coloring feature on Arm")

$ git remote -v=20
up      git://xenbits.xen.org/xen.git (fetch)
up      git://xenbits.xen.org/xen.git (push)
```
>=20
> Jan



From xen-devel-bounces@lists.xenproject.org Tue Dec 24 16:24:35 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Dec 2024 16:24:35 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863114.1274576 (Exim 4.92)
	(envelope-from )
	id 1tQ7hq-0006Zl-FY; Tue, 24 Dec 2024 16:24:26 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863114.1274576; Tue, 24 Dec 2024 16:24:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tQ7hq-0006Ze-Ct; Tue, 24 Dec 2024 16:24:26 +0000
Received: by outflank-mailman (input) for mailman id 863114;
 Tue, 24 Dec 2024 16:24: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 1tQ7ho-0006ZY-VM
 for xen-devel@lists.xenproject.org; Tue, 24 Dec 2024 16:24:25 +0000
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com
 [2a00:1450:4864:20::12c])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 88f56175-c213-11ef-99a3-01e77a169b0f;
 Tue, 24 Dec 2024 17:24:23 +0100 (CET)
Received: by mail-lf1-x12c.google.com with SMTP id
 2adb3069b0e04-53e389d8dc7so5487968e87.0
 for ; Tue, 24 Dec 2024 08:24: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: 88f56175-c213-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1735057462; x=1735662262; darn=lists.xenproject.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=4mkXKWmGiV5XXckoZsuAcHVdzO+pEYcGppRBWUinzmo=;
        b=XI8AAgQ5pEsPUdC32SY854gMsknziShgn9lOJAncx+MAgfNBktxNOWvKd4tknVGOfa
         6ZzfZuJ8ocoKh6c9SfC4s8DAbM/rtQMyV/Gj9B8HL7R/GDA1BzpOG7tDuyrAE3yV2Cg9
         ZqU/aNp42I005Tp8v1ngb3K+rmv3AnDzOBjw6pbWsrNlyB9Ke0B2e8NStVIMGV63d0aJ
         JOtzG0PpW8ksZx/6aEarqkFjkgIiG8QqSnNPNXxvsl4mXkeEPIGXGpw4XRBIcMunvK+R
         M7771vZfOyGx0GsYpZqrwWRZgcfoPoKYKA0vBaePxHTVScKi8OO5D6zid7MPa+zxZvRX
         sbVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735057462; x=1735662262;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=4mkXKWmGiV5XXckoZsuAcHVdzO+pEYcGppRBWUinzmo=;
        b=NpS9aEcK2sdPKXbEISZsRXUmrPq0uHJsp8sTZp5NPktOaPQNW1r7RbZI6ya+W/ZFCA
         RJqXGSrWNkYKCKQ7IVkJTVcCnDXElHkKtIPMkzwb2F9md/D4vPMtvb+FwEv5HVFuIYTh
         Q71iqJl9lSSzlR3A3iGOMfkFEiw5Ejq+wTpE84lsZUalGvB/xMJdwW9W/y7JpBeHivXk
         OEzp0Zd9Ea0GrdQw6Gr/+V+KU8GAXrN/zsMjLjjaSwS6mwTyQBo7cgPHaizRcGT+xo+a
         2bfrEyiopi2481aAA9vGm6Go2HCJFoElPU68pecrCD5/fK75h6a4cofkRBMgZ5u7d//Q
         H+ow==
X-Forwarded-Encrypted: i=1; AJvYcCX33SOovhD+HMy0+4bdsZUvWGQId46g1d9NwaAn30IQ1H+VdENngAq+V5yReVWqS5HV+MzOEMjst+o=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yw66JPHwgS0JE1oFDj5HJNzfcocVS1kW4plAOdD07vyLSck9DlU
	+PcdT/27snJBg9Iwq++ecsuTUpceSoU4SdIm0V4FpDXLkIKTwkQ2jy+7hWiasxR1+2Xw/nyKO/c
	MuCLGAcneINRvJyhEfXKGKTpOYNM=
X-Gm-Gg: ASbGnctz469/DjZJeV6yQZb/qE1qE+yxBcjmxrxyQhkA5HcrmrPMvYnPQJ8h5LW+Gbx
	f4Eaw2EvdRNlPSbiXnHfBoa+8zikyp44aKpAhoqRcveeFF/wQy0lX6C1Ijo54S0e7297f
X-Google-Smtp-Source: AGHT+IFeDcoH6FqGav3dMmPGh5sT6bY3h7jtuxBtb3J/jlYw3D77GN96q3f6d8YvDmECDxLlD6KL4j+bq6oD5HrXqmc=
X-Received: by 2002:a05:6512:1114:b0:53e:335e:774d with SMTP id
 2adb3069b0e04-5422957afc9mr4939338e87.56.1735057462100; Tue, 24 Dec 2024
 08:24:22 -0800 (PST)
MIME-Version: 1.0
References: 
 <099d3a80-4fdb-49a7-9fd0-207d7386551f@citrix.com> 
 
 <90640a5d-ff17-4555-adc6-ae9e21e24ebd@citrix.com> 
 <43166e29-ff2d-4a9d-8c1b-41b5e247974b@citrix.com> 
 
 <698f48a0-b674-4d7f-9c47-f1f8bf86379e@citrix.com> 
In-Reply-To: 
Reply-To: sedat.dilek@gmail.com
From: Sedat Dilek 
Date: Tue, 24 Dec 2024 17:23:45 +0100
Message-ID: 
Subject: Re: [Linux-6.12.y] XEN: CVE-2024-53241 / XSA-466 and Clang-kCFI
To: Andrew Cooper 
Cc: Juergen Gross , Peter Zijlstra , 
	Sami Tolvanen , Jan Beulich , 
	Josh Poimboeuf , Linus Torvalds , 
	Greg Kroah-Hartman , Sasha Levin , 
	linux-kernel@vger.kernel.org, stable@vger.kernel.org, 
	Kees Cook , Nathan Chancellor , llvm@lists.linux.dev, 
	xen-devel , 1091360@bugs.debian.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Dec 22, 2024 at 11:37=E2=80=AFAM Sedat Dilek  wrote:
>
> On Sat, Dec 21, 2024 at 10:31=E2=80=AFPM Andrew Cooper
>  wrote:
> >
> > On 21/12/2024 6:25 pm, Sedat Dilek wrote:
> > > With...
> > >
> > > dileks@iniza:~/src/xtf/git$ mv tests/xsa-454 ../
> > > dileks@iniza:~/src/xtf/git$ mv tests/xsa-consoleio-write ../
> >
> > That's completely bizzare.   There's nothing interestingly different
> > with those two tests vs the others.
> >
> > I take it the crash is repeatable when using either of these?
> >
> > ~Andrew
>
> This time I stopped SDDM and thus KDE-6/Wayland session.
>
> Tested with Debian's officially 6.12.6-amd64 kernel in VT-3.
>
> test-hvm32pae-xsa-consoleio-write SUCCESS <--- 1st time I tried, never
> said this is not OK
>
> test-hvm64-xsa-454 leads to FROZEN system and DATA LOSS (here: ext4).
> Reproducibly as told many times.- in Debian and selfmade kernels version =
6.12.6.
>
> Stolen from the picture I took with my smartphone:
>
> sudo ./xft-runner test-hvm64-xsa-454
>
> Executing 'xl create -p tests/xsa-454/test-hvm64-xsa-454.cfg'
> Executing 'xl console test-hvm64-xsa-454'
> Executing 'xl unpause test-hvm64-xsa-454'
>
> ^^ System does NOT react!
>
> I can send you the picture on request.
>
> -Sedat-

[ CC 1091360@bugs.debian.org ]

I upgraded to Xen version 4.19.1 in Debian/unstable AMD64.

# xl info | egrep 'release|version|commandline|caps'
release                : 6.12.6-amd64
version                : #1 SMP PREEMPT_DYNAMIC Debian 6.12.6-1 (2024-12-21=
)
hw_caps                :
bfebfbff:17bae3bf:28100800:00000001:00000001:00000000:00000000:00000100
virt_caps              : pv hvm hap shadow gnttab-v1 gnttab-v2
xen_version            : 4.19.1
xen_caps               : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p
hvm-3.0-x86_64
xen_commandline        : placeholder

dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner --host test-hvm64-xsa-454
Executing 'xl create -p tests/xsa-454/test-hvm64-xsa-454.cfg'
Executing 'xl console test-hvm64-xsa-454'
Executing 'xl unpause test-hvm64-xsa-454'
--- Xen Test Framework ---
Environment: HVM 64bit (Long mode 4 levels)
XSA-454 PoC
Success: Not vulnerable to XSA-454
Test result: SUCCESS

Combined test results:
test-hvm64-xsa-454                       SUCCESS

root@iniza:~# LC_ALL=3DC ll /var/log/xen/*xsa-454*.log
-rw-r--r-- 1 root adm 232 Dec 24 17:11
/var/log/xen/qemu-dm-test-hvm64-xsa-454.log
-rw-r--r-- 1 root adm 232 Dec 24 17:11 /var/log/xen/xl-test-hvm64-xsa-454.l=
og

root@iniza:~# cat /var/log/xen/qemu-dm-test-hvm64-xsa-454.log
VNC server running on 127.0.0.1:5900
xen-qemu-system-i386: failed to create 'console' device '0': declining
to handle console type 'xenconsoled'
xen-qemu-system-i386: terminating on signal 1 from pid 6302
(/usr/lib/xen-4.19/bin/xl)

root@iniza:~# cat /var/log/xen/xl-test-hvm64-xsa-454.log
Waiting for domain test-hvm64-xsa-454 (domid 144) to die [pid 6302]
Domain 144 has shut down, reason code 0 0x0
Action for shutdown reason code 0 is destroy
Domain 144 needs to be cleaned up: destroying the domain
Done. Exiting now

Due to Debian-Bug #1091360 ("qemu-system-xen: Build against libxen-dev
version 4.19.1-1") I am not able to do the full XFT tests.

-Sedat-

Link: https://bugs.debian.org/1091360


From xen-devel-bounces@lists.xenproject.org Tue Dec 24 19:16:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Dec 2024 19:16:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863124.1274587 (Exim 4.92)
	(envelope-from )
	id 1tQANp-000067-OO; Tue, 24 Dec 2024 19:15:57 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863124.1274587; Tue, 24 Dec 2024 19:15:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tQANp-000060-LV; Tue, 24 Dec 2024 19:15:57 +0000
Received: by outflank-mailman (input) for mailman id 863124;
 Tue, 24 Dec 2024 19:15: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 1tQANn-00005t-QG
 for xen-devel@lists.xenproject.org; Tue, 24 Dec 2024 19:15:56 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 7e1182fd-c22b-11ef-a0da-8be0dac302b0;
 Tue, 24 Dec 2024 20:15:53 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 24 Dec 2024 20:15:52 +0100
Received: from ntu.. (88-183-119-157.subs.proxad.net [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id A95672BBE;
 Tue, 24 Dec 2024 20:15:51 +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: 7e1182fd-c22b-11ef-a0da-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1735067753; x=1766603753;
  h=from:to:cc:subject:date:message-id:in-reply-to:
   references:mime-version:content-transfer-encoding;
  bh=IjBPtK2nebnguRv2GGeWqFRJGmRT1xbvSMljCMOpWZs=;
  b=LgyhpEiHtFws1QJgzXlKGHbnKNEz8P01cH/K0CHCaVSsAgOpCeXPDxLy
   0HY38u1Ln6GzO+9exew9CRdm4l6+yJGA1Ps98rIrfdds17zpVITL26IuJ
   72S1jL2i+x6nTdkq45Hs9PtqVMp/msvDXr0KrQjwTwkPX8eLZTVwiUQ8c
   k=;
X-CSE-ConnectionGUID: zjRU/MpoTJKPOMflce3LaA==
X-CSE-MsgGUID: xx9eUykzQRCnGl7yZAQiFA==
X-IronPort-AV: E=Sophos;i="6.12,261,1728943200"; 
   d="scan'208";a="28314859"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
	Ariel Otilibili ,
	Doug Goldstein ,
	Jan Beulich ,
	Juergen Gross ,
	"Daniel P. Smith" 
Subject: [PATCH v2 0/2] tools/libs,xen/tools: remove dead code
Date: Tue, 24 Dec 2024 20:13:53 +0100
Message-ID: <20241224191529.138119-1-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241220165837.937976-1-Ariel.Otilibili-Anieli@eurecom.fr>
References: <20241220165837.937976-1-Ariel.Otilibili-Anieli@eurecom.fr>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hello,

This series addresses the Coverity IDs 1056148, 1056149, & 1458052.

Thank you,
---
v2:
* addresse feedback of Jan Beulich on expr.c

Ariel Otilibili (2):
  tools/libs: remove dead code
  xen/tools: remove dead code

 tools/libs/light/libxl_create.c |  1 -
 tools/libs/light/libxl_device.c |  1 -
 xen/tools/kconfig/expr.c        | 13 +++++--------
 3 files changed, 5 insertions(+), 10 deletions(-)

-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 24 19:16:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Dec 2024 19:16:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863127.1274606 (Exim 4.92)
	(envelope-from )
	id 1tQAO3-0000dR-5q; Tue, 24 Dec 2024 19:16:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863127.1274606; Tue, 24 Dec 2024 19:16: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 1tQAO3-0000dK-3A; Tue, 24 Dec 2024 19:16:11 +0000
Received: by outflank-mailman (input) for mailman id 863127;
 Tue, 24 Dec 2024 19:16: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 1tQAO2-00005t-1W
 for xen-devel@lists.xenproject.org; Tue, 24 Dec 2024 19:16:10 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 880b1e13-c22b-11ef-a0da-8be0dac302b0;
 Tue, 24 Dec 2024 20:16:09 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 24 Dec 2024 20:16:09 +0100
Received: from ntu.. (88-183-119-157.subs.proxad.net [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id 0BBDB2BC0;
 Tue, 24 Dec 2024 20:16:09 +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: 880b1e13-c22b-11ef-a0da-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1735067769; x=1766603769;
  h=from:to:cc:subject:date:message-id:in-reply-to:
   references:mime-version:content-transfer-encoding;
  bh=p+XiT9wY1Ed3nislo24Z9ZFwlemo29xWJsjCkC72kpA=;
  b=WPUPx60prGHuBpP4//Vb2yeca9QdNeAhuNB//WefRft35P4Nmn7ZZcoc
   Mgn/2ttvia9ngE+CuLH7JFwA7XSmvkN/lHOppkVxyV59LedfJ/tS0vCNq
   NmL/uNFhXC87n6SRmaG0eJ9rE9Vbsan8VWL7K1nUM49c3ik/ZY/SfQX+i
   E=;
X-CSE-ConnectionGUID: W6qU7jSvSXCB1dz6r37o6A==
X-CSE-MsgGUID: bpSynhVWStGaiOLyAugljg==
X-IronPort-AV: E=Sophos;i="6.12,261,1728943200"; 
   d="scan'208";a="28314862"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
	Ariel Otilibili ,
	Doug Goldstein ,
	Jan Beulich 
Subject: [PATCH v2 2/2] xen/tools: remove dead code
Date: Tue, 24 Dec 2024 20:13:55 +0100
Message-ID: <20241224191529.138119-3-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241224191529.138119-1-Ariel.Otilibili-Anieli@eurecom.fr>
References: <20241220165837.937976-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241224191529.138119-1-Ariel.Otilibili-Anieli@eurecom.fr>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The original file was imported from Linux; patched the entire
expr_compare_type() with the diff from Linux.

Commits wherein it might have been fixed in Linux:
- dfe8e56fc604 ("kconfig: add fallthrough comments to expr_compare_type()")
- 9ad86d747c46 ("kconfig: remove unreachable printf()").

```
$ diff -u xen/xen/tools/kconfig/expr.c linux/scripts/kconfig/expr.c | \
    sed -ne '/expr_compare_type/,/return 0/{N;p}'

 static int expr_compare_type(enum expr_type t1, enum expr_type t2)
 {
        if (t1 == t2)
@@ -1106,30 +999,27 @@
        case E_GTH:
                if (t2 == E_EQUAL || t2 == E_UNEQUAL)
                        return 1;
+               /* fallthrough */
        case E_EQUAL:
        case E_UNEQUAL:
                if (t2 == E_NOT)
                        return 1;
+               /* fallthrough */
        case E_NOT:
                if (t2 == E_AND)
                        return 1;
+               /* fallthrough */
        case E_AND:
                if (t2 == E_OR)
                        return 1;
-       case E_OR:
-               if (t2 == E_LIST)
-                       return 1;
-       case E_LIST:
-               if (t2 == 0)
-                       return 1;
+               /* fallthrough */
        default:
-               return -1;
+               break;
        }
-       printf("[%dgt%d?]", t1, t2);
        return 0;
 }

$ cd linux/;
$ git log --oneline -1 --pretty='%h ("%s")'
8155b4ef3466 ("Add linux-next specific files for 20241220")

$ git remote -v
next    git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (fetch)
next    git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (push)

$ cd ../xen/
$ git log --oneline -1 --pretty='%h ("%s")'
6419020270 ("CHANGELOG: Mention LLC coloring feature on Arm")

$ git remote -v
up      git://xenbits.xen.org/xen.git (fetch)
up      git://xenbits.xen.org/xen.git (push)
```

Coverity-ID: 1458052
Fixes: 8c271b7584 ("build: import Kbuild/Kconfig from Linux 4.3")
Cc: Doug Goldstein 
Suggested-by: Jan Beulich 
Signed-off-by: Ariel Otilibili 
---
 xen/tools/kconfig/expr.c | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/xen/tools/kconfig/expr.c b/xen/tools/kconfig/expr.c
index 77ffff3a05..84af124626 100644
--- a/xen/tools/kconfig/expr.c
+++ b/xen/tools/kconfig/expr.c
@@ -1106,26 +1106,23 @@ static int expr_compare_type(enum expr_type t1, enum expr_type t2)
 	case E_GTH:
 		if (t2 == E_EQUAL || t2 == E_UNEQUAL)
 			return 1;
+		/* fallthrough */
 	case E_EQUAL:
 	case E_UNEQUAL:
 		if (t2 == E_NOT)
 			return 1;
+		/* fallthrough */
 	case E_NOT:
 		if (t2 == E_AND)
 			return 1;
+		/* fallthrough */
 	case E_AND:
 		if (t2 == E_OR)
 			return 1;
-	case E_OR:
-		if (t2 == E_LIST)
-			return 1;
-	case E_LIST:
-		if (t2 == 0)
-			return 1;
+		/* fallthrough */
 	default:
-		return -1;
+		break;
 	}
-	printf("[%dgt%d?]", t1, t2);
 	return 0;
 }
 
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 24 19:16:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Dec 2024 19:16:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863125.1274597 (Exim 4.92)
	(envelope-from )
	id 1tQAO0-0000NM-WC; Tue, 24 Dec 2024 19:16:09 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863125.1274597; Tue, 24 Dec 2024 19: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 1tQAO0-0000NF-Si; Tue, 24 Dec 2024 19:16:08 +0000
Received: by outflank-mailman (input) for mailman id 863125;
 Tue, 24 Dec 2024 19: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 1tQANy-00005t-Ur
 for xen-devel@lists.xenproject.org; Tue, 24 Dec 2024 19:16:06 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 86097919-c22b-11ef-a0da-8be0dac302b0;
 Tue, 24 Dec 2024 20:16:06 +0100 (CET)
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236])
 by drago1i.eurecom.fr with ESMTP; 24 Dec 2024 20:16:06 +0100
Received: from ntu.. (88-183-119-157.subs.proxad.net [88.183.119.157])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtps.eurecom.fr (Postfix) with ESMTPSA id A14892BBF;
 Tue, 24 Dec 2024 20:16: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: 86097919-c22b-11ef-a0da-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1735067766; x=1766603766;
  h=from:to:cc:subject:date:message-id:in-reply-to:
   references:mime-version:content-transfer-encoding;
  bh=3AbJ+S1D48+s3L5V4rG7JKluw1lLPGgBj5Py4O/wfeM=;
  b=gGuut6YAri5d73RVFOhsDFimrvo7a5o4lXmT1qHPF/uzrHbvqiLNFWNf
   qyNZ0bRZgnpy0z4gmXVlTO7M8crJx+xk7F6mZOw0TLtuAwO32ItwkBP/V
   A5/2qQnIqWLtxqz40i8eqQxZm6ITuSwC9GHTNwieITiMcZ75iXtSye2/d
   0=;
X-CSE-ConnectionGUID: ZIivuxDoRzum+HBN+8Zilw==
X-CSE-MsgGUID: VOJRqh9WSairvbFdcR7hEA==
X-IronPort-AV: E=Sophos;i="6.12,261,1728943200"; 
   d="scan'208";a="28314861"
From: Ariel Otilibili 
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
	Ariel Otilibili ,
	Juergen Gross ,
	"Daniel P. Smith" 
Subject: [PATCH v2 1/2] tools/libs: remove dead code
Date: Tue, 24 Dec 2024 20:13:54 +0100
Message-ID: <20241224191529.138119-2-Ariel.Otilibili-Anieli@eurecom.fr>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20241224191529.138119-1-Ariel.Otilibili-Anieli@eurecom.fr>
References: <20241220165837.937976-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241224191529.138119-1-Ariel.Otilibili-Anieli@eurecom.fr>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Default switch cases skip these steps; these instructions are never reached.

Coverity-IDs: 1056148, 1056149
Fixes: 0a69ea908d ("libxl: ao: convert libxl__spawn_*")
Fixes: 643b106b40 ("libxl: do not use tap disk backend other than for raw and vhd")
Signed-off-by: Ariel Otilibili 
--
Cc: Anthony PERARD 
Cc: Juergen Gross 
Cc: "Daniel P. Smith" 
---
 tools/libs/light/libxl_create.c | 1 -
 tools/libs/light/libxl_device.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
index e03599ea99..d0271bef7e 100644
--- a/tools/libs/light/libxl_create.c
+++ b/tools/libs/light/libxl_create.c
@@ -1890,7 +1890,6 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *multidev,
         ret = ERROR_INVAL;
         goto error_out;
     }
-    abort(); /* not reached */
 
  error_out:
     assert(ret);
diff --git a/tools/libs/light/libxl_device.c b/tools/libs/light/libxl_device.c
index 4faa5fa3bd..96046803e1 100644
--- a/tools/libs/light/libxl_device.c
+++ b/tools/libs/light/libxl_device.c
@@ -392,7 +392,6 @@ static int disk_try_backend(disk_try_backend_args *a,
         return 0;
 
     }
-    abort(); /* notreached */
 
  bad_format:
     LOG(DEBUG, "Disk vdev=%s, backend %s unsuitable due to format %s",
-- 
2.43.0



From xen-devel-bounces@lists.xenproject.org Tue Dec 24 21:58:06 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Dec 2024 21:58:06 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863156.1274616 (Exim 4.92)
	(envelope-from )
	id 1tQCuN-0002je-43; Tue, 24 Dec 2024 21:57:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863156.1274616; Tue, 24 Dec 2024 21:57: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 1tQCuN-0002jX-1I; Tue, 24 Dec 2024 21:57:43 +0000
Received: by outflank-mailman (input) for mailman id 863156;
 Tue, 24 Dec 2024 21: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 1tQCuL-0002j6-GS
 for xen-devel@lists.xenproject.org; Tue, 24 Dec 2024 21:57:41 +0000
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com
 [2a00:1450:4864:20::131])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 16cbc9be-c242-11ef-a0da-8be0dac302b0;
 Tue, 24 Dec 2024 22:57:38 +0100 (CET)
Received: by mail-lf1-x131.google.com with SMTP id
 2adb3069b0e04-54024aa9febso5894262e87.1
 for ; Tue, 24 Dec 2024 13:57:38 -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: 16cbc9be-c242-11ef-a0da-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1735077457; x=1735682257; darn=lists.xenproject.org;
        h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=ZbPCqk/DVvB78zsAYK9srunz1WN+hN0RoJRdIyLYCY4=;
        b=DeU5It0IkR+KLhfxzOW+hkYJOqrG1GZoeFOWoaQGqAsUBQ5BtUsDUfI/V5rDkdam5C
         04FIUMsrEBE3B4Kmn9deEJJl7Ql8xGVIfHMKFAFiUwcnwvyMnLqs6YMzuJOmGm+w/L2h
         TH3dgRNIFh9tiTF1hPGfjDnHKNn0FbgONVZ55ZVqBVOpfq7W5PhvjZtcuJGGlTKz+hOb
         vv9us9ULOrK2fhr5ymQdO2A3dduGf+xcsaPGa1QRjiHH7J4ctM4mgAkyc/lV+gjfuuFc
         ntHerLiYIg1H+2Z5Fj1qvWGgTU+4HE/pUJIfsFrqwsnOEmBHnv+kqrDQQ3X3eqd3LJAl
         pHLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735077457; x=1735682257;
        h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=ZbPCqk/DVvB78zsAYK9srunz1WN+hN0RoJRdIyLYCY4=;
        b=CKUzoJXI+4s5jxvkQOG1wBWh1RfkQiHQ7hMEPpi9S4rP89nPonTyndNe7RnMQfDb7t
         OdA6Ptr14hTEnFphRAdHPrNS+J9scR7auLXZ2izINIJK98oyeBaP/b/U0/s+VgvBOYrc
         x2SXCD/VqLrJprEZ7QTvD9hhn0+caoNxNoEwT7hXlBkoKgehiuyesi925TfgibKGYRST
         xK8SKdkoZYJsTxWBZ6MheOPfTIBy+Wimr68N0DByGP5ztfZ+BMnpzsHTg0MI1rZF6Njr
         PrTApyoAXfSq+i8RBr/vhFWXiXIQwxN2qoV2XH/uHG8nz71tBy402wsn9bCAQkTT7Amz
         aeIw==
X-Forwarded-Encrypted: i=1; AJvYcCUPrTbWsqAeFFbOnqqPmnGoO4a/2Ap7G2sOkdFF1dTnJiaNiK6LWrHc4npR27Qty26H7AaMZ2wqjLA=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwnL/LNYcLcUEGUkkmBKBCFOZRtv+BdBjXhxoW7lfRBuOUqbiPp
	/d+pQkdp1taWCCU9Byvy1c7RN8M7VEm41b5IXFg7dE14dWVkqvC0ekMfKJi9MJIB6w3Yc68nYbR
	nv1cQHTCl81UMM4njqWj04JZr2yc=
X-Gm-Gg: ASbGncu6oCawDDazo/stoKRl/mKU665OChzrKGiooq+NDU6RNqIZU84+fAu9TvFP22y
	P4zx/9FHMMj1hpBUEZ8lfm7BAEnoz246dfvRJB6D+NNdpXOsk/2eGjoLNW1HYfSvuMdLh
X-Google-Smtp-Source: AGHT+IFT13jLt/GfmU5pUvX0TVKGlwS3vaT5BtXg5VR9Mbaj2a1D6QRod7r0jNvqujpQ46FL6AiFIkdpu/wczpbqkIg=
X-Received: by 2002:a05:6512:b19:b0:542:2e09:639a with SMTP id
 2adb3069b0e04-5422e0963efmr4469706e87.10.1735077456979; Tue, 24 Dec 2024
 13:57:36 -0800 (PST)
MIME-Version: 1.0
References: 
 <099d3a80-4fdb-49a7-9fd0-207d7386551f@citrix.com> 
 
 <90640a5d-ff17-4555-adc6-ae9e21e24ebd@citrix.com> 
 <43166e29-ff2d-4a9d-8c1b-41b5e247974b@citrix.com> 
 
 <698f48a0-b674-4d7f-9c47-f1f8bf86379e@citrix.com> 
 
In-Reply-To: 
Reply-To: sedat.dilek@gmail.com
From: Sedat Dilek 
Date: Tue, 24 Dec 2024 22:56:59 +0100
Message-ID: 
Subject: Re: [Linux-6.12.y] XEN: CVE-2024-53241 / XSA-466 and Clang-kCFI
To: Andrew Cooper 
Cc: Juergen Gross , Peter Zijlstra , 
	Sami Tolvanen , Jan Beulich , 
	Josh Poimboeuf , Linus Torvalds , 
	Greg Kroah-Hartman , Sasha Levin , 
	linux-kernel@vger.kernel.org, stable@vger.kernel.org, 
	Kees Cook , Nathan Chancellor , llvm@lists.linux.dev, 
	xen-devel , 1091360@bugs.debian.org
Content-Type: multipart/mixed; boundary="0000000000007b4e3e062a0b33ad"

--0000000000007b4e3e062a0b33ad
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 24, 2024 at 5:23=E2=80=AFPM Sedat Dilek =
 wrote:
>
> On Sun, Dec 22, 2024 at 11:37=E2=80=AFAM Sedat Dilek  wrote:
> >
> > On Sat, Dec 21, 2024 at 10:31=E2=80=AFPM Andrew Cooper
> >  wrote:
> > >
> > > On 21/12/2024 6:25 pm, Sedat Dilek wrote:
> > > > With...
> > > >
> > > > dileks@iniza:~/src/xtf/git$ mv tests/xsa-454 ../
> > > > dileks@iniza:~/src/xtf/git$ mv tests/xsa-consoleio-write ../
> > >
> > > That's completely bizzare.   There's nothing interestingly different
> > > with those two tests vs the others.
> > >
> > > I take it the crash is repeatable when using either of these?
> > >
> > > ~Andrew
> >
> > This time I stopped SDDM and thus KDE-6/Wayland session.
> >
> > Tested with Debian's officially 6.12.6-amd64 kernel in VT-3.
> >
> > test-hvm32pae-xsa-consoleio-write SUCCESS <--- 1st time I tried, never
> > said this is not OK
> >
> > test-hvm64-xsa-454 leads to FROZEN system and DATA LOSS (here: ext4).
> > Reproducibly as told many times.- in Debian and selfmade kernels versio=
n 6.12.6.
> >
> > Stolen from the picture I took with my smartphone:
> >
> > sudo ./xft-runner test-hvm64-xsa-454
> >
> > Executing 'xl create -p tests/xsa-454/test-hvm64-xsa-454.cfg'
> > Executing 'xl console test-hvm64-xsa-454'
> > Executing 'xl unpause test-hvm64-xsa-454'
> >
> > ^^ System does NOT react!
> >
> > I can send you the picture on request.
> >
> > -Sedat-
>
> [ CC 1091360@bugs.debian.org ]
>
> I upgraded to Xen version 4.19.1 in Debian/unstable AMD64.
>
> # xl info | egrep 'release|version|commandline|caps'
> release                : 6.12.6-amd64
> version                : #1 SMP PREEMPT_DYNAMIC Debian 6.12.6-1 (2024-12-=
21)
> hw_caps                :
> bfebfbff:17bae3bf:28100800:00000001:00000001:00000000:00000000:00000100
> virt_caps              : pv hvm hap shadow gnttab-v1 gnttab-v2
> xen_version            : 4.19.1
> xen_caps               : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p
> hvm-3.0-x86_64
> xen_commandline        : placeholder
>
> dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner --host test-hvm64-xsa-454
> Executing 'xl create -p tests/xsa-454/test-hvm64-xsa-454.cfg'
> Executing 'xl console test-hvm64-xsa-454'
> Executing 'xl unpause test-hvm64-xsa-454'
> --- Xen Test Framework ---
> Environment: HVM 64bit (Long mode 4 levels)
> XSA-454 PoC
> Success: Not vulnerable to XSA-454
> Test result: SUCCESS
>
> Combined test results:
> test-hvm64-xsa-454                       SUCCESS
>
> root@iniza:~# LC_ALL=3DC ll /var/log/xen/*xsa-454*.log
> -rw-r--r-- 1 root adm 232 Dec 24 17:11
> /var/log/xen/qemu-dm-test-hvm64-xsa-454.log
> -rw-r--r-- 1 root adm 232 Dec 24 17:11 /var/log/xen/xl-test-hvm64-xsa-454=
.log
>
> root@iniza:~# cat /var/log/xen/qemu-dm-test-hvm64-xsa-454.log
> VNC server running on 127.0.0.1:5900
> xen-qemu-system-i386: failed to create 'console' device '0': declining
> to handle console type 'xenconsoled'
> xen-qemu-system-i386: terminating on signal 1 from pid 6302
> (/usr/lib/xen-4.19/bin/xl)
>
> root@iniza:~# cat /var/log/xen/xl-test-hvm64-xsa-454.log
> Waiting for domain test-hvm64-xsa-454 (domid 144) to die [pid 6302]
> Domain 144 has shut down, reason code 0 0x0
> Action for shutdown reason code 0 is destroy
> Domain 144 needs to be cleaned up: destroying the domain
> Done. Exiting now
>
> Due to Debian-Bug #1091360 ("qemu-system-xen: Build against libxen-dev
> version 4.19.1-1") I am not able to do the full XFT tests.
>
> -Sedat-
>
> Link: https://bugs.debian.org/1091360

With NEW qemu-system-xen/unstable (1:9.2.0+ds-3) both 6.12.6 kernel -
Debian and selfmade run with SUCCESS.

Nothing scary in dmesg-log.

Happy XMAS,
-Sedat-

--0000000000007b4e3e062a0b33ad
Content-Type: text/plain; charset="US-ASCII"; name="results_xen-4-19-1_dileks-6-12-6.txt"
Content-Disposition: attachment; 
	filename="results_xen-4-19-1_dileks-6-12-6.txt"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: f_m5309lk00

IyBjYXQgL3Byb2MvdmVyc2lvbiAKTGludXggdmVyc2lvbiA2LjEyLjYtMS1hbWQ2NC1jbGFuZzE5
LWtjZmkgKHNlZGF0LmRpbGVrQGdtYWlsLmNvbUBpbml6YSkgKENsYW5nQnVpbHRMaW51eCBjbGFu
ZyB2ZXJzaW9uIDE5LjEuNiAoaHR0cHM6Ly9naXRodWIuY29tL2xsdm0vbGx2bS1wcm9qZWN0Lmdp
dCBlMjFkYzRiZDU0NzRkMDRiOGU2MmQ3MzMxMzYyZWRjYzU2NDhkN2U1KSwgQ2xhbmdCdWlsdExp
bnV4IExMRCAxOS4xLjYgKGh0dHBzOi8vZ2l0aHViLmNvbS9sbHZtL2xsdm0tcHJvamVjdC5naXQg
ZTIxZGM0YmQ1NDc0ZDA0YjhlNjJkNzMzMTM2MmVkY2M1NjQ4ZDdlNSkpICMxfnRyaXhpZStkaWxl
a3MgU01QIFBSRUVNUFRfRFlOQU1JQyAyMDI0LTEyLTE5CgojIExDX0FMTD1DIGRtZXNnIC1UIHwg
Z3JlcCBrQ0ZJCltUdWUgRGVjIDI0IDIyOjM0OjUxIDIwMjRdIFNNUCBhbHRlcm5hdGl2ZXM6IFVz
aW5nIGtDRkkKCiMgeGwgaW5mbyB8IGVncmVwICdyZWxlYXNlfHZlcnNpb258Y29tbWFuZGxpbmV8
Y2FwcycKcmVsZWFzZSAgICAgICAgICAgICAgICA6IDYuMTIuNi0xLWFtZDY0LWNsYW5nMTkta2Nm
aQp2ZXJzaW9uICAgICAgICAgICAgICAgIDogIzF+dHJpeGllK2RpbGVrcyBTTVAgUFJFRU1QVF9E
WU5BTUlDIDIwMjQtMTItMTkKaHdfY2FwcyAgICAgICAgICAgICAgICA6IGJmZWJmYmZmOjE3YmFl
M2JmOjI4MTAwODAwOjAwMDAwMDAxOjAwMDAwMDAxOjAwMDAwMDAwOjAwMDAwMDAwOjAwMDAwMTAw
CnZpcnRfY2FwcyAgICAgICAgICAgICAgOiBwdiBodm0gaGFwIHNoYWRvdyBnbnR0YWItdjEgZ250
dGFiLXYyCnhlbl92ZXJzaW9uICAgICAgICAgICAgOiA0LjE5LjEKeGVuX2NhcHMgICAgICAgICAg
ICAgICA6IHhlbi0zLjAteDg2XzY0IGh2bS0zLjAteDg2XzMyIGh2bS0zLjAteDg2XzMycCBodm0t
My4wLXg4Nl82NCAKeGVuX2NvbW1hbmRsaW5lICAgICAgICA6IHBsYWNlaG9sZGVyCgojIGRwa2cg
LWwgfCBlZ3JlcCAncWVtdS1zeXN0ZW0teGVufGxpYnhlbm1pc2MnIHwgYXdrICcvXihpaXxoaXxy
Y3xwaSkvIHtwcmludCAkMSAiICIgJDIgIiAiICQzfScgfCBjb2x1bW4gLXQKaWkgIGxpYnhlbm1p
c2M0LjE5OmFtZDY0ICA0LjE5LjEtMQppaSAgcWVtdS1zeXN0ZW0teGVuICAgICAgIDE6OS4yLjAr
ZHMtMwoKZGlsZWtzQGluaXphOn4vc3JjL3h0Zi9naXQkIHN1ZG8gLi94dGYtcnVubmVyIC1hIC0t
aG9zdAoKLi4uCkV4ZWN1dGluZyAneGwgY3JlYXRlIC1wIHRlc3RzL3hzYS00NTQvdGVzdC1odm02
NC14c2EtNDU0LmNmZycKRXhlY3V0aW5nICd4bCBjb25zb2xlIHRlc3QtaHZtNjQteHNhLTQ1NCcK
RXhlY3V0aW5nICd4bCB1bnBhdXNlIHRlc3QtaHZtNjQteHNhLTQ1NCcKLS0tIFhlbiBUZXN0IEZy
YW1ld29yayAtLS0KRW52aXJvbm1lbnQ6IEhWTSA2NGJpdCAoTG9uZyBtb2RlIDQgbGV2ZWxzKQpY
U0EtNDU0IFBvQwpTdWNjZXNzOiBOb3QgdnVsbmVyYWJsZSB0byBYU0EtNDU0ClRlc3QgcmVzdWx0
OiBTVUNDRVNTCgpFeGVjdXRpbmcgJ3hsIGNyZWF0ZSAtcCB0ZXN0cy94c2EtY29uc29sZWlvLXdy
aXRlL3Rlc3QtaHZtMzJwYWUteHNhLWNvbnNvbGVpby13cml0ZS5jZmcnCkV4ZWN1dGluZyAneGwg
Y29uc29sZSB0ZXN0LWh2bTMycGFlLXhzYS1jb25zb2xlaW8td3JpdGUnCkV4ZWN1dGluZyAneGwg
dW5wYXVzZSB0ZXN0LWh2bTMycGFlLXhzYS1jb25zb2xlaW8td3JpdGUnCi0tLSBYZW4gVGVzdCBG
cmFtZXdvcmsgLS0tCkVudmlyb25tZW50OiBIVk0gMzJiaXQgKFBBRSAzIGxldmVscykKQ09OU09M
RUlPX3dyaXRlIHN0YWNrIG92ZXJmbG93IFBvQwpTdWNjZXNzOiBOb3QgdnVsbmVyYWJsZSB0byBD
T05TT0xFSU9fd3JpdGUgc3RhY2sgb3ZlcmZsb3cKVGVzdCByZXN1bHQ6IFNVQ0NFU1MKCkNvbWJp
bmVkIHRlc3QgcmVzdWx0czoKdGVzdC1odm0zMi1jcHVpZC1mYXVsdGluZyAgICAgICAgICAgICAg
ICBTS0lQCnRlc3QtaHZtMzJwYWUtY3B1aWQtZmF1bHRpbmcgICAgICAgICAgICAgU0tJUAp0ZXN0
LWh2bTMycHNlLWNwdWlkLWZhdWx0aW5nICAgICAgICAgICAgIFNLSVAKdGVzdC1odm02NC1jcHVp
ZC1mYXVsdGluZyAgICAgICAgICAgICAgICBTS0lQCnRlc3QtcHY2NC1jcHVpZC1mYXVsdGluZyAg
ICAgICAgICAgICAgICAgU0tJUAp0ZXN0LWh2bTY0LWZwdS1leGNlcHRpb24tZW11bGF0aW9uICAg
ICAgIFNLSVAKdGVzdC1odm0zMi1pbnZscGd+aGFwICAgICAgICAgICAgICAgICAgICBTVUNDRVNT
CnRlc3QtaHZtMzItaW52bHBnfnNoYWRvdyAgICAgICAgICAgICAgICAgU1VDQ0VTUwp0ZXN0LWh2
bTMycGFlLWludmxwZ35oYXAgICAgICAgICAgICAgICAgIFNVQ0NFU1MKdGVzdC1odm0zMnBhZS1p
bnZscGd+c2hhZG93ICAgICAgICAgICAgICBTVUNDRVNTCnRlc3QtaHZtNjQtaW52bHBnfmhhcCAg
ICAgICAgICAgICAgICAgICAgU1VDQ0VTUwp0ZXN0LWh2bTY0LWludmxwZ35zaGFkb3cgICAgICAg
ICAgICAgICAgIFNVQ0NFU1MKdGVzdC1odm02NC1sYnItdHN4LXZtZW50cnkgICAgICAgICAgICAg
ICBTVUNDRVNTCnRlc3QtaHZtMzItbGl2ZXBhdGNoLXByaXYtY2hlY2sgICAgICAgICAgU1VDQ0VT
Uwp0ZXN0LWh2bTY0LWxpdmVwYXRjaC1wcml2LWNoZWNrICAgICAgICAgIFNVQ0NFU1MKdGVzdC1w
djY0LWxpdmVwYXRjaC1wcml2LWNoZWNrICAgICAgICAgICBTVUNDRVNTCnRlc3QtaHZtMzItbG0t
dHMgICAgICAgICAgICAgICAgICAgICAgICAgU1VDQ0VTUwp0ZXN0LWh2bTY0LWxtLXRzICAgICAg
ICAgICAgICAgICAgICAgICAgIFNVQ0NFU1MKdGVzdC1odm0zMnBhZS1tZW1vcC1zZWcgICAgICAg
ICAgICAgICAgICBTVUNDRVNTCnRlc3QtaHZtNjQtbWVtb3Atc2VnICAgICAgICAgICAgICAgICAg
ICAgU1VDQ0VTUwp0ZXN0LXB2NjQtbWVtb3Atc2VnICAgICAgICAgICAgICAgICAgICAgIFNVQ0NF
U1MKdGVzdC1odm0zMnBhZS1ubWktdGFza3N3aXRjaC1wcml2ICAgICAgICBTVUNDRVNTCnRlc3Qt
cHY2NC1wdi1mc2dzYmFzZSAgICAgICAgICAgICAgICAgICAgU0tJUAp0ZXN0LXB2NjQtcHYtaW9w
bH5oeXBlcmNhbGwgICAgICAgICAgICAgIFNVQ0NFU1MKdGVzdC1wdjY0LXB2LWlvcGx+dm1hc3Np
c3QgICAgICAgICAgICAgICBTVUNDRVNTCnRlc3QtaHZtMzItc3dpbnQtZW11bGF0aW9uICAgICAg
ICAgICAgICAgU0tJUAp0ZXN0LWh2bTMycGFlLXN3aW50LWVtdWxhdGlvbiAgICAgICAgICAgIFNL
SVAKdGVzdC1odm0zMnBzZS1zd2ludC1lbXVsYXRpb24gICAgICAgICAgICBTS0lQCnRlc3QtaHZt
NjQtc3dpbnQtZW11bGF0aW9uICAgICAgICAgICAgICAgU0tJUAp0ZXN0LWh2bTMyLXVtaXAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFNLSVAKdGVzdC1odm02NC11bWlwICAgICAgICAgICAgICAg
ICAgICAgICAgICBTS0lQCnRlc3QtaHZtMzIteHNhLTEyMiAgICAgICAgICAgICAgICAgICAgICAg
U1VDQ0VTUwp0ZXN0LWh2bTMycGFlLXhzYS0xMjIgICAgICAgICAgICAgICAgICAgIFNVQ0NFU1MK
dGVzdC1odm0zMnBzZS14c2EtMTIyICAgICAgICAgICAgICAgICAgICBTVUNDRVNTCnRlc3QtaHZt
NjQteHNhLTEyMiAgICAgICAgICAgICAgICAgICAgICAgU1VDQ0VTUwp0ZXN0LXB2NjQteHNhLTEy
MiAgICAgICAgICAgICAgICAgICAgICAgIFNVQ0NFU1MKdGVzdC1odm0zMi14c2EtMTIzICAgICAg
ICAgICAgICAgICAgICAgICBTS0lQCnRlc3QtcHY2NC14c2EtMTY3ICAgICAgICAgICAgICAgICAg
ICAgICAgU0tJUAp0ZXN0LWh2bTY0LXhzYS0xNjh+c2hhZG93ICAgICAgICAgICAgICAgIFNVQ0NF
U1MKdGVzdC1odm02NC14c2EtMTcwICAgICAgICAgICAgICAgICAgICAgICBTS0lQCnRlc3QtaHZt
NjQteHNhLTE3M35zaGFkb3cgICAgICAgICAgICAgICAgU1VDQ0VTUwp0ZXN0LXB2NjQteHNhLTE4
MiAgICAgICAgICAgICAgICAgICAgICAgIFNVQ0NFU1MKdGVzdC1odm0zMi14c2EtMTg2ICAgICAg
ICAgICAgICAgICAgICAgICBTS0lQCnRlc3QtaHZtNjQteHNhLTE4NiAgICAgICAgICAgICAgICAg
ICAgICAgU0tJUAp0ZXN0LWh2bTMyLXhzYS0xODggICAgICAgICAgICAgICAgICAgICAgIFNVQ0NF
U1MKdGVzdC1odm0zMnBhZS14c2EtMTg4ICAgICAgICAgICAgICAgICAgICBTVUNDRVNTCnRlc3Qt
aHZtMzJwc2UteHNhLTE4OCAgICAgICAgICAgICAgICAgICAgU1VDQ0VTUwp0ZXN0LWh2bTY0LXhz
YS0xODggICAgICAgICAgICAgICAgICAgICAgIFNVQ0NFU1MKdGVzdC1wdjY0LXhzYS0xODggICAg
ICAgICAgICAgICAgICAgICAgICBTVUNDRVNTCnRlc3QtaHZtMzIteHNhLTE5MSAgICAgICAgICAg
ICAgICAgICAgICAgU0tJUAp0ZXN0LWh2bTMyLXhzYS0xOTIgICAgICAgICAgICAgICAgICAgICAg
IFNVQ0NFU1MKdGVzdC1wdjY0LXhzYS0xOTMgICAgICAgICAgICAgICAgICAgICAgICBTVUNDRVNT
CnRlc3QtaHZtNjQteHNhLTE5NSAgICAgICAgICAgICAgICAgICAgICAgU1VDQ0VTUwp0ZXN0LWh2
bTY0LXhzYS0xOTYgICAgICAgICAgICAgICAgICAgICAgIFNLSVAKdGVzdC1odm0zMi14c2EtMjAw
ICAgICAgICAgICAgICAgICAgICAgICBTS0lQCnRlc3QtaHZtMzIteHNhLTIwMyAgICAgICAgICAg
ICAgICAgICAgICAgU0tJUAp0ZXN0LWh2bTY0LXhzYS0yMDQgICAgICAgICAgICAgICAgICAgICAg
IFNLSVAKdGVzdC1wdjY0LXhzYS0yMTIgICAgICAgICAgICAgICAgICAgICAgICBTVUNDRVNTCnRl
c3QtcHY2NC14c2EtMjEzICAgICAgICAgICAgICAgICAgICAgICAgU1VDQ0VTUwp0ZXN0LWh2bTY0
LXhzYS0yMjEgICAgICAgICAgICAgICAgICAgICAgIFNVQ0NFU1MKdGVzdC1wdjY0LXhzYS0yMjEg
ICAgICAgICAgICAgICAgICAgICAgICBTVUNDRVNTCnRlc3QtcHY2NC14c2EtMjI0ICAgICAgICAg
ICAgICAgICAgICAgICAgU1VDQ0VTUwp0ZXN0LXB2NjQteHNhLTIyNyAgICAgICAgICAgICAgICAg
ICAgICAgIFNVQ0NFU1MKdGVzdC1odm02NC14c2EtMjMxICAgICAgICAgICAgICAgICAgICAgICBT
VUNDRVNTCnRlc3QtcHY2NC14c2EtMjMxICAgICAgICAgICAgICAgICAgICAgICAgU1VDQ0VTUwp0
ZXN0LWh2bTY0LXhzYS0yMzIgICAgICAgICAgICAgICAgICAgICAgIFNVQ0NFU1MKdGVzdC1wdjY0
LXhzYS0yMzIgICAgICAgICAgICAgICAgICAgICAgICBTVUNDRVNTCnRlc3QtcHY2NC14c2EtMjM0
ICAgICAgICAgICAgICAgICAgICAgICAgU1VDQ0VTUwp0ZXN0LWh2bTMyLXhzYS0yMzkgICAgICAg
ICAgICAgICAgICAgICAgIFNVQ0NFU1MKdGVzdC1wdjY0LXhzYS0yNTUgICAgICAgICAgICAgICAg
ICAgICAgICBTVUNDRVNTCnRlc3QtcHY2NC14c2EtMjU5ICAgICAgICAgICAgICAgICAgICAgICAg
U1VDQ0VTUwp0ZXN0LXB2NjQteHNhLTI2MCAgICAgICAgICAgICAgICAgICAgICAgIFNVQ0NFU1MK
dGVzdC1odm02NC14c2EtMjYxICAgICAgICAgICAgICAgICAgICAgICBTVUNDRVNTCnRlc3QtcHY2
NC14c2EtMjY1ICAgICAgICAgICAgICAgICAgICAgICAgU1VDQ0VTUwp0ZXN0LWh2bTY0LXhzYS0y
NjkgICAgICAgICAgICAgICAgICAgICAgIFNVQ0NFU1MKdGVzdC1odm02NC14c2EtMjc3ICAgICAg
ICAgICAgICAgICAgICAgICBTVUNDRVNTCnRlc3QtaHZtNjQteHNhLTI3OCAgICAgICAgICAgICAg
ICAgICAgICAgU1VDQ0VTUwp0ZXN0LXB2NjQteHNhLTI3OSAgICAgICAgICAgICAgICAgICAgICAg
IFNVQ0NFU1MKdGVzdC1wdjY0LXhzYS0yODYgICAgICAgICAgICAgICAgICAgICAgICBTVUNDRVNT
CnRlc3QtcHY2NC14c2EtMjk2ICAgICAgICAgICAgICAgICAgICAgICAgU1VDQ0VTUwp0ZXN0LXB2
NjQteHNhLTI5OCAgICAgICAgICAgICAgICAgICAgICAgIFNVQ0NFU1MKdGVzdC1odm02NC14c2Et
MzA0ICAgICAgICAgICAgICAgICAgICAgICBTVUNDRVNTCnRlc3QtaHZtNjQteHNhLTMwOCAgICAg
ICAgICAgICAgICAgICAgICAgU1VDQ0VTUwp0ZXN0LXB2NjQteHNhLTMxNiAgICAgICAgICAgICAg
ICAgICAgICAgIFNVQ0NFU1MKdGVzdC1odm0zMi14c2EtMzE3ICAgICAgICAgICAgICAgICAgICAg
ICBTVUNDRVNTCnRlc3QtaHZtMzJwYWUteHNhLTMxNyAgICAgICAgICAgICAgICAgICAgU1VDQ0VT
Uwp0ZXN0LWh2bTMycHNlLXhzYS0zMTcgICAgICAgICAgICAgICAgICAgIFNVQ0NFU1MKdGVzdC1o
dm02NC14c2EtMzE3ICAgICAgICAgICAgICAgICAgICAgICBTVUNDRVNTCnRlc3QtcHY2NC14c2Et
MzE3ICAgICAgICAgICAgICAgICAgICAgICAgU1VDQ0VTUwp0ZXN0LXB2NjQteHNhLTMzMyAgICAg
ICAgICAgICAgICAgICAgICAgIFNVQ0NFU1MKdGVzdC1wdjY0LXhzYS0zMzkgICAgICAgICAgICAg
ICAgICAgICAgICBTVUNDRVNTCnRlc3QtcHY2NC14c2EtNDQ0ICAgICAgICAgICAgICAgICAgICAg
ICAgU0tJUAp0ZXN0LWh2bTY0LXhzYS00NTEgICAgICAgICAgICAgICAgICAgICAgIFNLSVAKdGVz
dC1odm02NC14c2EtNDU0ICAgICAgICAgICAgICAgICAgICAgICBTVUNDRVNTCnRlc3QtaHZtMzJw
YWUteHNhLWNvbnNvbGVpby13cml0ZSAgICAgICAgU1VDQ0VTUwoKCi1kaWxla3MgLy8gMjQtRGVj
LTIwMjQK
--0000000000007b4e3e062a0b33ad
Content-Type: text/x-log; charset="US-ASCII"; name="qemu-dm-test-hvm64-xsa-454.log"
Content-Disposition: attachment; filename="qemu-dm-test-hvm64-xsa-454.log"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: f_m5309ptw1

Vk5DIHNlcnZlciBydW5uaW5nIG9uIDEyNy4wLjAuMTo1OTAwCnhlbi1xZW11LXN5c3RlbS1pMzg2
OiBmYWlsZWQgdG8gY3JlYXRlICdjb25zb2xlJyBkZXZpY2UgJzAnOiBkZWNsaW5pbmcgdG8gaGFu
ZGxlIGNvbnNvbGUgdHlwZSAneGVuY29uc29sZWQnCnhlbi1xZW11LXN5c3RlbS1pMzg2OiB0ZXJt
aW5hdGluZyBvbiBzaWduYWwgMSBmcm9tIHBpZCA0ODQ1ICgvdXNyL2xpYi94ZW4tNC4xOS9iaW4v
eGwpCg==
--0000000000007b4e3e062a0b33ad
Content-Type: text/x-log; charset="US-ASCII"; name="xl-test-hvm64-xsa-454.log"
Content-Disposition: attachment; filename="xl-test-hvm64-xsa-454.log"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: f_m5309ss22

V2FpdGluZyBmb3IgZG9tYWluIHRlc3QtaHZtNjQteHNhLTQ1NCAoZG9taWQgOTQpIHRvIGRpZSBb
cGlkIDQ4NDVdCkRvbWFpbiA5NCBoYXMgc2h1dCBkb3duLCByZWFzb24gY29kZSAwIDB4MApBY3Rp
b24gZm9yIHNodXRkb3duIHJlYXNvbiBjb2RlIDAgaXMgZGVzdHJveQpEb21haW4gOTQgbmVlZHMg
dG8gYmUgY2xlYW5lZCB1cDogZGVzdHJveWluZyB0aGUgZG9tYWluCkRvbmUuIEV4aXRpbmcgbm93
Cg==
--0000000000007b4e3e062a0b33ad--


From xen-devel-bounces@lists.xenproject.org Wed Dec 25 10:23:48 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Dec 2024 10:23:48 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863178.1274627 (Exim 4.92)
	(envelope-from )
	id 1tQOXz-0008Ot-Tv; Wed, 25 Dec 2024 10:23:23 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863178.1274627; Wed, 25 Dec 2024 10:23: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 1tQOXz-0008Ob-Of; Wed, 25 Dec 2024 10:23:23 +0000
Received: by outflank-mailman (input) for mailman id 863178;
 Wed, 25 Dec 2024 10:23: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 1tQOXy-0008OV-Jj
 for xen-devel@lists.xenproject.org; Wed, 25 Dec 2024 10:23:22 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com
 (mail-bn7nam10on2060b.outbound.protection.outlook.com
 [2a01:111:f403:2009::60b])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 41ea8786-c2aa-11ef-99a3-01e77a169b0f;
 Wed, 25 Dec 2024 11:23:18 +0100 (CET)
Received: from IA1PR12MB6532.namprd12.prod.outlook.com (2603:10b6:208:3a3::12)
 by CH3PR12MB9027.namprd12.prod.outlook.com (2603:10b6:610:120::15)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8293.14; Wed, 25 Dec
 2024 10:23:11 +0000
Received: from IA1PR12MB6532.namprd12.prod.outlook.com
 ([fe80::dc05:a63a:39fa:ff0b]) by IA1PR12MB6532.namprd12.prod.outlook.com
 ([fe80::dc05:a63a:39fa:ff0b%7]) with mapi id 15.20.8272.013; Wed, 25 Dec 2024
 10:23: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: 41ea8786-c2aa-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=DNw0ZdfBfNrssALkF9ip1krADmwOOPT/zhihKBc++Djo9G2mpVXyjY4QGWLvO6nm/3oTIrrDRAqxcLBq/vVGUKnvAG4VuZ3vb5EJ3lmX3Tp+2NHsGibDDBcp1Ix+1lfzoyEGNfpEEtQso29WTpK83u1g+k235JP3uofI2J2NGq/O9uljdRHIza0am+X0adzPojcNrBjeUXaX2bdumGtL4G5GMpSNtai6+TUYo8jxhvs+N+itLwKnIH+zeL7U6OMwr94H0SbGLbEURssya7Aw7/lWi8B+FYeo4H02RUUELNQuIqQf5AnvHOh6bZ9wBiwDruUZMkfK5yDcsTl2OQG5ag==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vXwxYgXhUXyibklzXUKFJjyQ15Y8tgPzIfP7eQWflyo=;
 b=XHYUkp9juUIvqNYMobcdOWg4SW87RFXQTnGMr++dqaT/Lc8BvVZS2kX8AkMWDgfo1WPYAPO6+WTJ57sJj4p918H5x/tgxlnJ/mhH6toK9V3UMAIDoI78LYyGVKPM5qVhlZ+50ojhvZiM+MVu7C276oR0kntowj2y0FwP9qCiMvI7ven3PZrKzuKe/Toa5QA3MxmORrYu+bBnkrVZ3xiQ0BnpPEwRBHHBrytSB7537pHVOwFTuYr6fbGaEtUOyMPhnt49RH/DH2YmDWg8VUpmdYd15h2Haz/xpmelhXss1FPF8OYJvoSEtQy4rwcl5/IM2uHfpXq0rHKZ6/rJ77upSw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=vXwxYgXhUXyibklzXUKFJjyQ15Y8tgPzIfP7eQWflyo=;
 b=ox/+86VhNtrAs6YdZ6ECXHj9azlTS2GYeeS0DcCzBwj1C1TkLhpLWB3EK0Fv4AtXd+W4erxjn5rb0cWQSTLjXTdUY1yBWXz9wE9CzVzYOtX1MmRCkzpQjI9YYypCyk3wj6B5I6Ojy4fusJFL98u1CPPrkcTZn9TKWL401Pcuqvc=
From: "Zhang, Julia" 
To: Jan Beulich , "Zhang, Julia" 
CC: "Deucher, Alexander" , "Koenig, Christian"
	, Xenia Ragiadakou , "Chen,
 Jiqian" , "Huang, Ray" , "Penny,
 Zheng" , "Zhu, Lingshan" , Paul
 Durrant , "Edgar E . Iglesias" ,
	"Michael S . Tsirkin" , Marcel Apfelbaum
	, Juergen Gross , Oleksandr
 Tyshchenko , Anthony PERARD
	, =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?=
	, "xen-devel@lists.xenproject.org"
	, Stefano Stabellini 
Subject: Re: [PATCH] xen: add privcmd ioctl to get p2pdma_distance
Thread-Topic: [PATCH] xen: add privcmd ioctl to get p2pdma_distance
Thread-Index:
 AQHbSJdDNMdfRsD4vkSvz8Ngpfn4L7LdjBaAgAuOxQD//4svAIAB3fOA//+tJwCADTGaAA==
Date: Wed, 25 Dec 2024 10:23:11 +0000
Message-ID:
 
References: <20241207105946.542491-1-julia.zhang@amd.com>
 <03504a1e-c801-47fc-ac66-ab7e10ab6695@suse.com>
 
 <0284d807-ae85-4d43-93b5-91fb29528d62@suse.com>
 
 <837391e6-5ffd-4f4a-9bc4-c4431b5b25a2@suse.com>
In-Reply-To: <837391e6-5ffd-4f4a-9bc4-c4431b5b25a2@suse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-imapappendstamp: IA1PR12MB6532.namprd12.prod.outlook.com
 (15.20.8272.000)
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: IA1PR12MB6532:EE_|CH3PR12MB9027:EE_
x-ms-office365-filtering-correlation-id: 52293a54-58ef-4929-65b9-08dd24ce225b
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
 BCL:0;ARA:13230040|376014|7416014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info:
 =?utf-8?B?c1d0Q21peEljTy9SbFNTMHc5RFNPRm8ycngvbGprT1dLejFIUkthcjdlL080?=
 =?utf-8?B?UTdvZVl0NUFtWDNKL05zY0doa1MwaWM4cFZvM1ZQd0QwVEp5SVVZVEk4bkt6?=
 =?utf-8?B?V1MwL2NqNHBhRTJZMmZ2T1NXL1ZzNnhrL01Mc1BZVVdhaWJtYW4xTG5naFZl?=
 =?utf-8?B?V0lWNzB4aXlpSlMrYlpVaVhNOG0vUTkzSkxJeW03V0IwaXRSR1JwbkkvaVdY?=
 =?utf-8?B?bXhTL0orSVlTK0RQTS9Vc0Z2UVZDZDFUY0xKckNwc2I2ejM1OE1xRTFyMGhk?=
 =?utf-8?B?V21TbVJRWWlqdFJRTHdjbHpVUU5UR285QzhSaWUvSVd1UHd2M2hNZy9LWUVL?=
 =?utf-8?B?bStpWGxweGJGLzA2Q0lxclhtQlhEd2ZWa0N3aE5tb2djbjZFd3B3dFBrczJV?=
 =?utf-8?B?eDdza1BVMzl0ZVo0ekl5ZWtZOFlaYjNwY2ljd24yR0JuTVJ0QW9EUnl5OW5U?=
 =?utf-8?B?dzMxbllCeFZVOUZ5SEhCMVZlenkyUHFmRFFDT2pFbHMxRmpIbXJReGt2MElM?=
 =?utf-8?B?RTBnMVRLS3c3QkhsTjN2WlRqRnEyRzlSaHFVRG9KWXBmMkFoeS9wTkZMaktF?=
 =?utf-8?B?WjQrQ2lBWTRRUkhKWjlqVTQ3Y0krckhFSUJNaG0zWEJYTzZzL3RpL1RHUGZ3?=
 =?utf-8?B?alZrTGZEcWlUNUs5aWFmRFNxR2lYcWJnbkJOb3Raem9lNUd3di9VTTJGeVZE?=
 =?utf-8?B?VkdRMGxQNi9DNkJYVThzMjJuVVBiK0lqc1I1ckNxTDlBYUp5clJyTDI0L21t?=
 =?utf-8?B?SHB0Y2gzMzh0SEZxbXNDUjVRK1hQdTdKTUZoN1hzSVozTE5tdVdlU0owWFdU?=
 =?utf-8?B?Q2hQRzNrVXk1dCtMSGs4VmxPbkFzdVd3Z3B3YmgxSUdPV3lTY1E4WUhlNlVr?=
 =?utf-8?B?SmdsQ0dUa3Y2VmpsOXpndlBIR0NucDdlcUJ2d3ljeW44VEVMSlk0eDY4QjNP?=
 =?utf-8?B?UnIwUEczLy9aSmRLeUFCSGIyeTk5N3NlcWc2WW1BNG8ydHJrclowK25RTllq?=
 =?utf-8?B?Q3ltbEwvT3cwTk9sZ2VKUWt0T253QXR1TUpodUlrK2FEQkZldW5VTmVHdnBX?=
 =?utf-8?B?WXptMGhYSG44RlR3VFU4QjB6ekZOT1VRV1ZVM3R1UWNJdi9CejcvSFZOVnpZ?=
 =?utf-8?B?N21VS0w0bElGUkFOVlpqc0lWRlY0cEh1Z3IvMWFSU1hqYlFYS1NCRU9oOTd5?=
 =?utf-8?B?Y1YrNGxmNlV1d2lFR2JKcFFiNHM3V3l0QUlrb0owcytBQzlISEJHcXU2VmhW?=
 =?utf-8?B?eHcvdW8xR25LT2NEOWI4em1IbVNzYVQwTWlMd1RjUzE3SytDVm45MlN4V0tv?=
 =?utf-8?B?ZGRNbkpjRzBFZERaTitGWlQyWkc0bHNGQzNIbFFoUjN4RmhWWngyWGkxUVJk?=
 =?utf-8?B?Q3MvRE1CcnZZcFovUXYrbE1BemExVWFST0JrdXBQMThXL0JZc1h4N2ZoazBz?=
 =?utf-8?B?cVp2UURrKzFUYzZ1SE9Bd0hQRjRKNjJCc3duK0RZci80YldZbnlwcGp0SXFu?=
 =?utf-8?B?c2JTY1lMWUVLZStyN2JxNnRyUkZIWTJoaTNKVVVqK0diV1NGQ1lWY3hRRUhC?=
 =?utf-8?B?UDIzY3ZGd1JzRWQzQXlMcUZFcWNFSzJwUHRlSE94Y2JOQkhsMUMzUldKTjh0?=
 =?utf-8?B?Mm0weit1NTU4UEpiMGZNY2s5ZW1JeUJhS2RicVJqSkt2bmRoK3ZQK2hHZDM5?=
 =?utf-8?B?bGN1VDhKbDJWZWpOYUxYRmxKU0lHZGFINzVkSGxZNzFBbCtRM1BMZkllZ0ow?=
 =?utf-8?B?d1N3TEl2WmxydlR6LzRja1JyVERueUNZalE1R0JNc3c3SlBJS051K3VoWUJq?=
 =?utf-8?B?YmswMUVBcnZJcWxzVWlHNXo2UElvaEdwdGdKWGhJWEl3blJxZGQwQnlnU2ts?=
 =?utf-8?B?d0VERGkyTm5nV1F1L29zS1BDcFBoVlhXTWJvNForckVIbjhuaDVXUXlYNTAx?=
 =?utf-8?Q?fgaEUAenMcDqBDZhbkDdJUUhVvG1fPXe?=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA1PR12MB6532.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?K1VwSUt1WmZONzlsZmZBY2pSWCtsbzE4dVhGZnJCbXFJSFpQcFhZU3o1amYy?=
 =?utf-8?B?a3hlQ1QrckdPbTZ6NW5QbkloejBSbytpZ3FrVXB5U1hnbTRUS2tQNjVKR1V5?=
 =?utf-8?B?QXFvTHptOUZVNDFWZW8xNEUrWEh4a1UrM2RBa1dXZ2hqam0rSFJDZEVFNWNE?=
 =?utf-8?B?TE9rdTIxNm1VVXZ1eCtFbGdkdzFva0Y2L0dWcmY0cnRTaEVXU0V6bVRtaEdI?=
 =?utf-8?B?ZXdHQzUrVnlKVHE4SnF6WTZISnV4ejBvd1JKU2JoRGhaTjRXelhud1JsOERo?=
 =?utf-8?B?SXY1ZEhrempnSjNSTG8zNDJkWTdJOHV5eE4rZzhmcFQvNTlmK1llT05LK1Uw?=
 =?utf-8?B?Q2NCVUFJdGM0bTI3Ty9oazJZSlYrM1NGQTcvTUpxQW00WjJCeWJHcGoxaHJu?=
 =?utf-8?B?cTdtUm9JRzhrYlFOdlpzd216eGpjMFZROEpqUXcyK1MxYlNUOUxIYjRuMGZC?=
 =?utf-8?B?R1NWV24rRFl4ZDV4UGJvc24ydzZmS1pHa0NQbE83Vzd2eXhRend4dE1IMjY2?=
 =?utf-8?B?a1RMa0xGZXJudzZHQkk3dEpYWU1iQkdRcFlLMmozaC9ZdUVNSFR6K2hiQVR6?=
 =?utf-8?B?Zng0U3lURHdhVXgyVU5hcUIva09tdWRjRFB4cHdwaHcrd05DdkI1VGJGRFVG?=
 =?utf-8?B?WTh5QS85enIzSXMvWTI4V3JMOFhZMGcvQjVpVVFqYUF6WnB5K3c4bmNnbnJa?=
 =?utf-8?B?UWNvWXp6RkovSDFQM1pjcktLVTYrRHRlaW5CT0c2NEY3MW1zb2xqMmVlQ0xI?=
 =?utf-8?B?NmZSODFITTVybFlCZFd5cTY4aDYvK005SmNOOXdNakdxZ1BBMHkzc0w0Ym1s?=
 =?utf-8?B?dkttLzhWQVpsQ1pxU0EvV21SSHI2MFpSQVRhTkZ6UEdEbVI2empRYXJuQWZB?=
 =?utf-8?B?Z21oaEw4Uk9aZktGa2w2WVloOEV4bTM5aGFVVXI2MFFmQU03dWZNdWVvaEti?=
 =?utf-8?B?TCt6VWdNR1ZUR2s0eGRQQ3VPSTFuU2U0T2V2YmFleGxUSkhWRmEvcEZYSHBG?=
 =?utf-8?B?YXFZY2lzZlBSVnhBVUgzV096aU1SK1pBdE1sdkJxV09vTXdwbG5KNmZ6b3hX?=
 =?utf-8?B?cnovMzUzOHQzRTVqNHhEQXZkUXNKUzF6MnJicUQwR3BOaWc1ZFA5Uy9SMDIw?=
 =?utf-8?B?b0lKaHRycUtwRHV6NGN6K2lpaTYyMGNpT2VNR1hGZmE2Uk1rcVdvU2V2cVdK?=
 =?utf-8?B?OE1RSlFHM09WUjNnMi9CcXVTbjVKYm9EakVoNW9kRlVuK3FydkNZZk9HWnZ2?=
 =?utf-8?B?alIwWjNFUHd3M3doRzgwVXBCSXRsK1pMYlpaRDdMbVlPUmE5a1J6bTU2cmQx?=
 =?utf-8?B?K09wVzcwZ3M5ZFlRVzYzaWYwelJ2Wm12K3UzS2d6SXlyeGNZdU5paktSdTFn?=
 =?utf-8?B?RkdwbW1NTXA0SkJhM3JLT2xwYVdtL3VqV3RCUlgzODV6NG9iYjJaSHRhd0JB?=
 =?utf-8?B?T0xVMGlWakpvYm10SXV4K095enJoOTd0eW9xdDFzNVVQNzJqQVY2cUduTlpP?=
 =?utf-8?B?bzF6Wm0yUUc0aEErVWZlcHo0MjdsZ1luaVduR3NSaWZaQzMwTjF0K2xDZ3E2?=
 =?utf-8?B?UFh5VVFwcjhMZ2pBeWFUd2xyR2EvVVczSWk0SmVHZElkSm9CR1hUOVQrcVIx?=
 =?utf-8?B?NzNkcEtiS1AzWTgzd2RJeTZpNTMxWWp3SktXZzRkY0VpRWM3RlB2UGg5WWZL?=
 =?utf-8?B?L3JKZjB1YXJzZ2NiYTJscEJnUmVldWFVT2dSZkQwelNyMFg2S1JKNEpBVHZM?=
 =?utf-8?B?M21TWEJ5dFFaNjFiaEppd2s2cTZPazQvNlI5WldSNzJUcFVTcXRDQjg2cnJ4?=
 =?utf-8?B?WDFIdkNmQTFBbkFpSGxYa0MzWFNENjNlc1dMQVNSL2ZDSmJqQ1JVL1VJMXh6?=
 =?utf-8?B?RnNTdElrajVkOHM0QVhMaUhZdjBBWWoxenY5L21jUUU2YVh0RXdrTEFtMmJI?=
 =?utf-8?B?dndhdnZMMXg1ZVhXYllNRkZkaDdHZ1lCeTBFVnI5UHF2S3BVL3Y5alY0T1BX?=
 =?utf-8?B?NGswTE9hc0ZVVkEzTWhDZnB2WWJ3WHhDMld1bXBWTzFOai9lYTdwS0ZtSFMw?=
 =?utf-8?B?YU93WFhYcXUrZGljN0tXUlQweGN6SE4wQi9pSm9OODM3V3FUSkZWazdjTDRF?=
 =?utf-8?Q?h8fY=3D?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: IA1PR12MB6532.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 52293a54-58ef-4929-65b9-08dd24ce225b
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Dec 2024 10:23:11.4218
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OC8c4K/53n62PKmK6yT9nF5ovqHe4L4FelHupvAWktpBC/p+EHuxH4hQQMEJ4O7OU9XWbxEh6N/Dvni2rCghIg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9027

DQoNCk9uIDIwMjQvMTIvMTcgMTY6NTMsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxNy4xMi4y
MDI0IDA2OjUzLCBaaGFuZywgSnVsaWEgd3JvdGU6DQo+Pg0KPj4NCj4+IE9uIDIwMjQvMTIvMTYg
MTc6MTksIEphbiBCZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDE2LjEyLjIwMjQgMDk6MTgsIFpoYW5n
LCBKdWxpYSB3cm90ZToNCj4+Pj4gT24gMjAyNC8xMi85IDE1OjQ3LCBKYW4gQmV1bGljaCB3cm90
ZToNCj4+Pj4gT24gMDcuMTIuMjAyNCAxMTo1OSwgSnVsaWEgWmhhbmcgd3JvdGU6DQo+Pj4NCj4+
PiBZZXQgYW5vdGhlciBmb3JtYWxpdHksIHNvcnJ5OiBQbGVhc2Ugc2VuZCBwbGFpbiB0ZXh0IGVt
YWlscy4gWW91J2xsIG5vdGUgdGhhdCB3aGF0DQo+Pj4gSSBzYWlkIGFuZCB3aHkgeW91IHNhaWQg
aXMgaW5kaXN0aW5ndWlzaGFibHkgaW50ZXJtaXhlZCBiZWxvdy4NCj4+DQo+PiBUaGFua3MgZm9y
IHJlbWluZGluZy4NCj4+DQo+Pj4NCj4+Pj4gLS0tIGEvdG9vbHMvaW5jbHVkZS94ZW4tc3lzL0xp
bnV4L3ByaXZjbWQuaA0KPj4+Pg0KPj4+PiArKysgYi90b29scy9pbmNsdWRlL3hlbi1zeXMvTGlu
dXgvcHJpdmNtZC5oDQo+Pj4+DQo+Pj4+IEBAIC0xMTAsNiArMTEwLDE2IEBAIHR5cGVkZWYgc3Ry
dWN0IHByaXZjbWRfbWFwX2h2YV90b19ncGZucyB7DQo+Pj4+DQo+Pj4+ICAgICAgaW50IGFkZF9t
YXBwaW5nOw0KPj4+Pg0KPj4+PiAgICB9IHByaXZjbWRfbWFwX2h2YV90b19ncGZuc190Ow0KPj4+
Pg0KPj4+Pg0KPj4+Pg0KPj4+PiArdHlwZWRlZiBzdHJ1Y3QgcHJpdmNtZF9wMnBkbWFfZGlzdGFu
Y2Ugew0KPj4+Pg0KPj4+PiArICBfX3UzMiBwcm92aWRlcl9idXM7DQo+Pj4+DQo+Pj4+ICsgIF9f
dTMyIHByb3ZpZGVyX3Nsb3Q7DQo+Pj4+DQo+Pj4+ICsgIF9fdTMyIHByb3ZpZGVyX2Z1bmM7DQo+
Pj4+DQo+Pj4+ICsgIF9fdTMyIGNsaWVudF9idXM7DQo+Pj4+DQo+Pj4+ICsgIF9fdTMyIGNsaWVu
dF9zbG90Ow0KPj4+Pg0KPj4+PiArICBfX3UzMiBjbGllbnRfZnVuYzsNCj4+Pj4NCj4+Pj4gKyAg
X191MzIgZGlzdGFuY2U7DQo+Pj4+DQo+Pj4+ICt9IHByaXZjbWRfcDJwZG1hX2Rpc3RhbmNlX3Q7
DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+ICJEaXN0YW5jZSIgdHlwaWNhbGx5IGlzIGEgc3ltbWV0
cmljIHRoaW5nLiBXaHkgdGhlIGFzeW1tZXRyeSBoZXJlPyBBbmQNCj4+Pj4NCj4+Pj4gd2h5IF9f
dTMyIHdoZW4gX191OCB3aWxsIGJlIGZpbmUgZm9yIG1vc3QgZmllbGRzPyBBbmQgd2hlcmUncyB0
aGUgc2VnbWVudA0KPj4+Pg0KPj4+PiBwYXJ0IG9mIHRoZSBkZXZpY2UgY29vcmRpbmF0ZXM/IEZp
bmFsbHksIHdpdGggaXQgYmVpbmcgbWVyZWx5IHN0dWINCj4+Pj4NCj4+Pj4gaW1wbGVtZW50YXRp
b25zIHRoYXQgeW91IGFkZCBoZXJlLCBhbGwgZGV0YWlscyBvbiB3aGVyZSB0aGUgbmVlZGVkIGlu
Zm8NCj4+Pj4NCj4+Pj4gaXMgdG8gY29tZSBmcm9tIGFyZSBtaXNzaW5nLg0KPj4+Pg0KPj4+PiAi
RGlzdGFuY2UiIGlzIHAycGRtYS1kaXN0YW5jZSBiZXR3ZWVuIHR3byBQQ0kgZGV2aWNlcywgaXQn
cyBjYWxjdWxhdGVkIGluIGtlcm5lbCBkcml2ZXIuSSBkb24ndCBnZXQgd2h5IGl0J3Mgc3ltbWV0
cmljPw0KPj4+DQo+Pj4gRGlzdGFuY2UgZnJvbSBBIHRvIEIgaXMgdXN1YWxseSB0aGUgc2FtZSBh
cyB0aGF0IGZyb20gQiB0byBBLiBCdXQgeWVzLA0KPj4+IG5vdCBuZWNlc3NhcmlseSBhbHdheXMg
KHRoaW5raW5nIG9mIGUuZy4gcmluZ3MpLiBZZXQgc3RpbGwgSSdtIHVuY2xlYXINCj4+PiBhYm91
dCB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBwcm92aWRlIGFuZCBjbGllbnQuDQo+Pg0KPj4gUHJv
dmlkZXIgLSBBIGRyaXZlciB3aGljaCBwcm92aWRlcyBvciBwdWJsaXNoZXMgUDJQIHJlc291cmNl
cy4NCj4+IENsaWVudCAtIEEgZHJpdmVyIHdoaWNoIG1ha2VzIHVzZSBvZiBhIHJlc291cmNlLg0K
Pj4NCj4+IEluIG91ciBjYXNlLCB3ZSB3YW50IHRvIHVzZSBwYXNzdGhyb3VnaCBkR1BVIHJlbmRl
ciBkYXRhLCBhbmQgdmlydGlvDQo+PiBpR1BVIGRpc3BsYXkgZGF0YS4gU28gZEdQVSBuZWVkIHRv
IGltcG9ydCBkaXNwbGF5IGJ1ZmZlciBvZiBpR1BVLiBpR1BVDQo+PiBpcyBwcm92aWRlciBhbmQg
ZEdQVSBpcyBjbGllbnQuDQo+IA0KPiBSaWdodCwgYnV0OiBJcyB0aGlzIGFycmFuZ2VtZW50IHJl
bGV2YW50IGZvciB0aGUgbmV3IGlvY3RsPyBBcmVuJ3QNCj4geW91IHNpbXBseSBhZnRlciB0aGUg
ZGlzdGFuY2UgYmV0d2VlbiB0d28gZGV2aWNlcywgb2Ygd2hpY2ggeW91cg0KPiBwcm92aWRlci9j
bGllbnQgbW9kZWwgaXMgbWVyZWx5IGEgc3BlY2lhbCBjYXNlPw0KDQpUaGUgbG9naWMgb2YgdGhp
cyBpb2N0bCBhYm91dCBwcm92aWRlci9jbGllbnQgaXMgdG90YWxseSBmb2xsb3dlZCANCnBjaV9w
MnBkbWFfZGlzdGFuY2UoKSBvZiBrZXJuZWwuIFNvIEkgdGhpbmsgb3VyIGNhc2UgaXMgbm90IGEg
c3BlY2lhbCBjYXNlLg0KDQpKdWxpYQ0KPiANCj4gSmFuDQo=


From xen-devel-bounces@lists.xenproject.org Thu Dec 26 16:16:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Dec 2024 16:16:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863226.1274637 (Exim 4.92)
	(envelope-from )
	id 1tQqX3-0005bz-Hj; Thu, 26 Dec 2024 16:16:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863226.1274637; Thu, 26 Dec 2024 16:16: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 1tQqX3-0005bh-Br; Thu, 26 Dec 2024 16:16:17 +0000
Received: by outflank-mailman (input) for mailman id 863226;
 Thu, 26 Dec 2024 16:16: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 1tQqX2-0005bb-4p
 for xen-devel@lists.xenproject.org; Thu, 26 Dec 2024 16:16:16 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b95ac171-c3a4-11ef-a0da-8be0dac302b0;
 Thu, 26 Dec 2024 17:16:14 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1735229765773367.7759362648453;
 Thu, 26 Dec 2024 08:16:05 -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: b95ac171-c3a4-11ef-a0da-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1735229767; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=a7B9U03m7oglKjoxJdzbsAqRmCNMdY715+dstrtLbYuIAmfWGHI38TjGikOtVcArZH5CuuJhNSsoUzTJZYG8MSbaoL5z8TmiF/xXSgdnnzMmK65FNcwO+T3pc8G8D+uJej/Ef4oPvXF8GHyud6wCPuw3YFE4ZaoqZnnErRwlqfc=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1735229767; 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=YqqKeyet+2uUgrlg44C8mno8IzfJtoe6MzUCfi5C2wo=; 
	b=gz8QZ3Gi3q72ZeSylQ3A62sfOi79i26LQgOcbvx4OE5eIooaeQz824NyA02ACLdB3pSluVar9BY3gjSdfR2zI7oov1faMxFsS13kQYTQeAktykVOO3hIAskb3VhGbzP+mN0al7nrPNDeZ2ar+sHZzWXCItCNlTbQ0D5Sl6K6CL0=
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=1735229767;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=Message-ID:Date:Date:MIME-Version:Subject:Subject:From:From:To:To:Cc:Cc:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To;
	bh=YqqKeyet+2uUgrlg44C8mno8IzfJtoe6MzUCfi5C2wo=;
	b=rNLlcdT4kXEBUbaFleHQSF3Ev6FJ2GbnLXFDaEHOGWsItNNqh5saxRc/ZTS+l1iW
	N/hjbg7VDFIxUvPuur0jdKHq1m3cjY7Xu88cVU9OXHSNgu+1ZBIiqTJEoR4e1/q4AnE
	kfkVlUpiOnmUHVREVb8OBTL7WOQslKiNC28ZjXuc=
Message-ID: <420a0920-cb18-4294-9dc6-3b564843ba89@apertussolutions.com>
Date: Thu, 26 Dec 2024 11:16:03 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 13/15] x86/hyperlaunch: add memory parsing to domain
 config
From: "Daniel P. Smith" 
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: christopher.w.clark@gmail.com, stefano.stabellini@amd.com,
 Jan Beulich , Andrew Cooper ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 
References: <20241123182044.30687-1-dpsmith@apertussolutions.com>
 <20241123182044.30687-14-dpsmith@apertussolutions.com>
 <4c4d8cf0-cc31-4042-8efb-892f56047d11@amd.com>
 <8072fa09-1e3c-43a7-a36c-4c965314ac22@apertussolutions.com>
Content-Language: en-US
In-Reply-To: <8072fa09-1e3c-43a7-a36c-4c965314ac22@apertussolutions.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

On 12/11/24 12:59, Daniel P. Smith wrote:
> On 11/25/24 19:03, Jason Andryuk wrote:
>> On 2024-11-23 13:20, Daniel P. Smith wrote:
>>> Add three properties, memory, mem-min, and mem-max, to the domain 
>>> node device
>>> tree parsing to define the memory allocation for a domain. All three 
>>> fields are
>>> expressed in kb and written as a u64 in the device tree entries.
>>>
>>> Signed-off-by: Daniel P. Smith 
>>> ---
>>
>>> diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
>>> index c231191faec7..1c3b7ff0e658 100644
>>> --- a/xen/arch/x86/dom0_build.c
>>> +++ b/xen/arch/x86/dom0_build.c
>>> @@ -609,6 +609,14 @@ int __init construct_dom0(struct boot_domain *bd)
>>>       process_pending_softirqs();
>>> +    /* If param dom0_size was not set and HL config provided memory 
>>> size */
>>> +    if ( !get_memsize(&dom0_size, LONG_MAX) && bd->mem_pages )
>>> +        dom0_size.nr_pages = bd->mem_pages;
>>> +    if ( !get_memsize(&dom0_min_size, LONG_MAX) && bd->min_pages )
>>> +        dom0_size.nr_pages = bd->min_pages;
>>> +    if ( !get_memsize(&dom0_max_size, LONG_MAX) && bd->max_pages )
>>> +        dom0_size.nr_pages = bd->max_pages;
>>> +
>>
>> This placement seems a little random.  Can this move into 
>> dom0_compute_nr_pages()?
> 
> As I started to rebase the multi-domain code around all the changes that 
> happened under the boot module review, dom0_compute_nr_pages() became a 
> mess to work with again. The result does see this drop in favor of 
> handling during dom_compute_nr_pages(). I will look to back port that 
> refactoring to here.

Before sending out v2, wanted to respond back that I did not see an 
immediate way to move this up to dom0_compute_nr_pages() without bring 
in a series of unrelated changes.

v/r,
dps



From xen-devel-bounces@lists.xenproject.org Thu Dec 26 16:58:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Dec 2024 16:58:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863236.1274657 (Exim 4.92)
	(envelope-from )
	id 1tQrBU-0002LP-Ha; Thu, 26 Dec 2024 16:58:04 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863236.1274657; Thu, 26 Dec 2024 16: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 1tQrBU-0002LE-Ey; Thu, 26 Dec 2024 16:58:04 +0000
Received: by outflank-mailman (input) for mailman id 863236;
 Thu, 26 Dec 2024 16: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 1tQrBT-00026T-Hd
 for xen-devel@lists.xenproject.org; Thu, 26 Dec 2024 16:58:03 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 90cdeefc-c3aa-11ef-a0da-8be0dac302b0;
 Thu, 26 Dec 2024 17:58:02 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1735232271045470.01366880994726;
 Thu, 26 Dec 2024 08:57: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: 90cdeefc-c3aa-11ef-a0da-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1735232272; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=NgzhDXiJG2mXhvHErwt9ZqhWeHKIomFe2B2HxnbWBp+5100uNqjMOVCHgHMk4pOJmeGarT7MJhd2hKbUw3lafh44DIgHAOd3pmkzHHhr0j6stIQW3xHLxJc8vsfQ4wQVnhzZ1+pNuRbVF5hJdAmqmKiTzissnh9porFs1YSNrZM=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1735232272; h=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=/JEBs+owbU9zKFMXeF6gl9Ekr8hZ2owuS8MfDWsoy0M=; 
	b=UwZcSTyd04VLLQIVhZ0E5B+jUyfwUq7KN8XIRHMzsQkz4ECRK6wW2jafh4XfofAqMXsvOm4OMgaRtPMvFx0bWtHDCahUOGWvqfi21/nQ7Hv6/6a/vDUJiAfXQFI57QyvBJJ4rpudvc3z8Ir+NwkPM3L0ERjR4yM7rArgAcIWRug=
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=1735232272;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=/JEBs+owbU9zKFMXeF6gl9Ekr8hZ2owuS8MfDWsoy0M=;
	b=T9LCCGVdlAVM1x1CMLBYcsUhzzdMe50AuAgWKQHWnL2aC0XYz/JVEOmP+9972XMJ
	Y1HGB9jXZF2v36P6pdO7G4Wiprea4ghW9XBG3RKEpQ9vzdiAg+rcj20EiC8jYkBz38u
	iGs6cZr1psDCAGTnrBm5mq7ID1evOXsIAi6z1qUo=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	christopher.w.clark@gmail.com,
	stefano.stabellini@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 01/15] x86/boot: introduce boot domain
Date: Thu, 26 Dec 2024 11:57:26 -0500
Message-Id: <20241226165740.29812-2-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20241226165740.29812-1-dpsmith@apertussolutions.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

To begin moving toward allowing the hypervisor to construct more than one
domain at boot, a container is needed for a domain's build information.
Introduce a new header, , that contains the initial
struct boot_domain that encapsulate the build information for a domain.

Add a kernel and ramdisk boot module reference along with a struct domain
reference to the new struct boot_domain. This allows a struct boot_domain
reference to be the only parameter necessary to pass down through the domain
construction call chain.

Signed-off-by: Daniel P. Smith 
Reviewed-by: Jason Andryuk 

---
Changes since dom0 device tree v1:
- dropped unnecessary forward declarations
- moved pvh_load_kernel() changes forward to this commit

Changes since boot modules v9
- dropped unlikely

Changes since v8:
- code style correction
---
 xen/arch/x86/dom0_build.c             |  8 +++++---
 xen/arch/x86/hvm/dom0_build.c         | 23 ++++++++--------------
 xen/arch/x86/include/asm/bootdomain.h | 28 +++++++++++++++++++++++++++
 xen/arch/x86/include/asm/bootinfo.h   |  5 +++++
 xen/arch/x86/include/asm/dom0_build.h |  6 +++---
 xen/arch/x86/include/asm/setup.h      |  4 ++--
 xen/arch/x86/pv/dom0_build.c          | 24 ++++++++---------------
 xen/arch/x86/setup.c                  | 24 ++++++++++-------------
 8 files changed, 69 insertions(+), 53 deletions(-)
 create mode 100644 xen/arch/x86/include/asm/bootdomain.h

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index e8f5bf5447bc..c231191faec7 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -13,6 +13,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -596,9 +597,10 @@ int __init dom0_setup_permissions(struct domain *d)
     return rc;
 }
 
-int __init construct_dom0(struct boot_info *bi, struct domain *d)
+int __init construct_dom0(struct boot_domain *bd)
 {
     int rc;
+    const struct domain *d = bd->d;
 
     /* Sanity! */
     BUG_ON(!pv_shim && d->domain_id != 0);
@@ -608,9 +610,9 @@ int __init construct_dom0(struct boot_info *bi, struct domain *d)
     process_pending_softirqs();
 
     if ( is_hvm_domain(d) )
-        rc = dom0_construct_pvh(bi, d);
+        rc = dom0_construct_pvh(bd);
     else if ( is_pv_domain(d) )
-        rc = dom0_construct_pv(bi, d);
+        rc = dom0_construct_pv(bd);
     else
         panic("Cannot construct Dom0. No guest interface available\n");
 
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index ce5b5c31b318..cbc365d678d2 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -644,9 +644,11 @@ static bool __init check_and_adjust_load_address(
 }
 
 static int __init pvh_load_kernel(
-    struct domain *d, struct boot_module *image, struct boot_module *initrd,
-    paddr_t *entry, paddr_t *start_info_addr)
+    struct boot_domain *bd, paddr_t *entry, paddr_t *start_info_addr)
 {
+    struct domain *d = bd->d;
+    struct boot_module *image = bd->kernel;
+    struct boot_module *initrd = bd->ramdisk;
     void *image_base = bootstrap_map_bm(image);
     void *image_start = image_base + image->headroom;
     unsigned long image_len = image->size;
@@ -1301,26 +1303,17 @@ static void __hwdom_init pvh_setup_mmcfg(struct domain *d)
     }
 }
 
-int __init dom0_construct_pvh(struct boot_info *bi, struct domain *d)
+int __init dom0_construct_pvh(struct boot_domain *bd)
 {
     paddr_t entry, start_info;
-    struct boot_module *image;
-    struct boot_module *initrd = NULL;
-    unsigned int idx;
+    struct domain *d = bd->d;
     int rc;
 
     printk(XENLOG_INFO "*** Building a PVH Dom%d ***\n", d->domain_id);
 
-    idx = first_boot_module_index(bi, BOOTMOD_KERNEL);
-    if ( idx >= bi->nr_modules )
+    if ( bd->kernel == NULL )
         panic("Missing kernel boot module for %pd construction\n", d);
 
-    image = &bi->mods[idx];
-
-    idx = first_boot_module_index(bi, BOOTMOD_RAMDISK);
-    if ( idx < bi->nr_modules )
-        initrd = &bi->mods[idx];
-
     if ( is_hardware_domain(d) )
     {
         /*
@@ -1358,7 +1351,7 @@ int __init dom0_construct_pvh(struct boot_info *bi, struct domain *d)
         return rc;
     }
 
-    rc = pvh_load_kernel(d, image, initrd, &entry, &start_info);
+    rc = pvh_load_kernel(bd, &entry, &start_info);
     if ( rc )
     {
         printk("Failed to load Dom0 kernel\n");
diff --git a/xen/arch/x86/include/asm/bootdomain.h b/xen/arch/x86/include/asm/bootdomain.h
new file mode 100644
index 000000000000..8d0e5c78d426
--- /dev/null
+++ b/xen/arch/x86/include/asm/bootdomain.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (c) 2024 Apertus Solutions, LLC
+ * Author: Daniel P. Smith 
+ * Copyright (c) 2024 Christopher Clark 
+ */
+
+#ifndef __XEN_X86_BOOTDOMAIN_H__
+#define __XEN_X86_BOOTDOMAIN_H__
+
+struct boot_domain {
+    struct boot_module *kernel;
+    struct boot_module *ramdisk;
+
+    struct domain *d;
+};
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index f8b422913063..9f65e2c8f62d 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -11,10 +11,14 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Max number of boot modules a bootloader can provide in addition to Xen */
 #define MAX_NR_BOOTMODS 63
 
+/* Max number of boot domains that Xen can construct */
+#define MAX_NR_BOOTDOMS 1
+
 /* Boot module binary type / purpose */
 enum bootmod_type {
     BOOTMOD_UNKNOWN,
@@ -78,6 +82,7 @@ struct boot_info {
 
     unsigned int nr_modules;
     struct boot_module mods[MAX_NR_BOOTMODS + 1];
+    struct boot_domain domains[MAX_NR_BOOTDOMS];
 };
 
 /*
diff --git a/xen/arch/x86/include/asm/dom0_build.h b/xen/arch/x86/include/asm/dom0_build.h
index 2d67b17213dc..8c94e87dc576 100644
--- a/xen/arch/x86/include/asm/dom0_build.h
+++ b/xen/arch/x86/include/asm/dom0_build.h
@@ -13,9 +13,9 @@ unsigned long dom0_compute_nr_pages(struct domain *d,
                                     unsigned long initrd_len);
 int dom0_setup_permissions(struct domain *d);
 
-struct boot_info;
-int dom0_construct_pv(struct boot_info *bi, struct domain *d);
-int dom0_construct_pvh(struct boot_info *bi, struct domain *d);
+struct boot_domain;
+int dom0_construct_pv(struct boot_domain *bd);
+int dom0_construct_pvh(struct boot_domain *bd);
 
 unsigned long dom0_paging_pages(const struct domain *d,
                                 unsigned long nr_pages);
diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h
index 5c2391a8684b..b517da6144de 100644
--- a/xen/arch/x86/include/asm/setup.h
+++ b/xen/arch/x86/include/asm/setup.h
@@ -26,8 +26,8 @@ void subarch_init_memory(void);
 
 void init_IRQ(void);
 
-struct boot_info;
-int construct_dom0(struct boot_info *bi, struct domain *d);
+struct boot_domain;
+int construct_dom0(struct boot_domain *bd);
 
 void setup_io_bitmap(struct domain *d);
 
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index f54d1da5c6f4..e0709a1c1a7a 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -355,7 +355,7 @@ static struct page_info * __init alloc_chunk(struct domain *d,
     return page;
 }
 
-static int __init dom0_construct(struct boot_info *bi, struct domain *d)
+static int __init dom0_construct(struct boot_domain *bd)
 {
     unsigned int i;
     int rc, order, machine;
@@ -371,14 +371,15 @@ static int __init dom0_construct(struct boot_info *bi, struct domain *d)
     struct page_info *page = NULL;
     unsigned int flush_flags = 0;
     start_info_t *si;
+    struct domain *d = bd->d;
     struct vcpu *v = d->vcpu[0];
 
-    struct boot_module *image;
-    struct boot_module *initrd = NULL;
+    struct boot_module *image = bd->kernel;
+    struct boot_module *initrd = bd->ramdisk;
     void *image_base;
     unsigned long image_len;
     void *image_start;
-    unsigned long initrd_len = 0;
+    unsigned long initrd_len = initrd ? initrd->size : 0;
 
     l4_pgentry_t *l4tab = NULL, *l4start = NULL;
     l3_pgentry_t *l3tab = NULL, *l3start = NULL;
@@ -416,22 +417,13 @@ static int __init dom0_construct(struct boot_info *bi, struct domain *d)
 
     printk(XENLOG_INFO "*** Building a PV Dom%d ***\n", d->domain_id);
 
-    i = first_boot_module_index(bi, BOOTMOD_KERNEL);
-    if ( i >= bi->nr_modules )
+    if ( !image )
         panic("Missing kernel boot module for %pd construction\n", d);
 
-    image = &bi->mods[i];
     image_base = bootstrap_map_bm(image);
     image_len = image->size;
     image_start = image_base + image->headroom;
 
-    i = first_boot_module_index(bi, BOOTMOD_RAMDISK);
-    if ( i < bi->nr_modules )
-    {
-        initrd = &bi->mods[i];
-        initrd_len = initrd->size;
-    }
-
     d->max_pages = ~0U;
 
     if ( (rc = bzimage_parse(image_base, &image_start, &image_len)) != 0 )
@@ -1078,7 +1070,7 @@ out:
     return rc;
 }
 
-int __init dom0_construct_pv(struct boot_info *bi, struct domain *d)
+int __init dom0_construct_pv(struct boot_domain *bd)
 {
     unsigned long cr4 = read_cr4();
     int rc;
@@ -1096,7 +1088,7 @@ int __init dom0_construct_pv(struct boot_info *bi, struct domain *d)
         write_cr4(cr4 & ~X86_CR4_SMAP);
     }
 
-    rc = dom0_construct(bi, d);
+    rc = dom0_construct(bd);
 
     if ( cr4 & X86_CR4_SMAP )
     {
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 8ebe5a9443f3..7e4529d6bfb2 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -989,16 +989,9 @@ static struct domain *__init create_dom0(struct boot_info *bi)
             .misc_flags = opt_dom0_msr_relaxed ? XEN_X86_MSR_RELAXED : 0,
         },
     };
+    struct boot_domain *bd = &bi->domains[0];
     struct domain *d;
     domid_t domid;
-    struct boot_module *image;
-    unsigned int idx;
-
-    idx = first_boot_module_index(bi, BOOTMOD_KERNEL);
-    if ( idx >= bi->nr_modules )
-        panic("Missing kernel boot module for building domain\n");
-
-    image = &bi->mods[idx];
 
     if ( opt_dom0_pvh )
     {
@@ -1025,11 +1018,11 @@ static struct domain *__init create_dom0(struct boot_info *bi)
         panic("Error creating d%uv0\n", domid);
 
     /* Grab the DOM0 command line. */
-    if ( image->cmdline_pa || bi->kextra )
+    if ( bd->kernel->cmdline_pa || bi->kextra )
     {
-        if ( image->cmdline_pa )
-            safe_strcpy(
-                cmdline, cmdline_cook(__va(image->cmdline_pa), bi->loader));
+        if ( bd->kernel->cmdline_pa )
+            safe_strcpy(cmdline,
+                        cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader));
 
         if ( bi->kextra )
             /* kextra always includes exactly one leading space. */
@@ -1051,10 +1044,11 @@ static struct domain *__init create_dom0(struct boot_info *bi)
             safe_strcat(cmdline, acpi_param);
         }
 
-        image->cmdline_pa = __pa(cmdline);
+        bd->kernel->cmdline_pa = __pa(cmdline);
     }
 
-    if ( construct_dom0(bi, d) != 0 )
+    bd->d = d;
+    if ( construct_dom0(bd) != 0 )
         panic("Could not construct domain 0\n");
 
     return d;
@@ -1261,6 +1255,7 @@ void asmlinkage __init noreturn __start_xen(void)
 
     /* Dom0 kernel is always first */
     bi->mods[0].type = BOOTMOD_KERNEL;
+    bi->domains[0].kernel = &bi->mods[0];
 
     if ( pvh_boot )
     {
@@ -2118,6 +2113,7 @@ void asmlinkage __init noreturn __start_xen(void)
     if ( initrdidx < MAX_NR_BOOTMODS )
     {
         bi->mods[initrdidx].type = BOOTMOD_RAMDISK;
+        bi->domains[0].ramdisk = &bi->mods[initrdidx];
         if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
             printk(XENLOG_WARNING
                    "Multiple initrd candidates, picking module #%u\n",
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 26 16:58:05 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Dec 2024 16:58:05 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863235.1274646 (Exim 4.92)
	(envelope-from )
	id 1tQrBQ-00026g-AU; Thu, 26 Dec 2024 16:58:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863235.1274646; Thu, 26 Dec 2024 16:58: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 1tQrBQ-00026Z-7c; Thu, 26 Dec 2024 16:58:00 +0000
Received: by outflank-mailman (input) for mailman id 863235;
 Thu, 26 Dec 2024 16:57: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 1tQrBP-00026T-0h
 for xen-devel@lists.xenproject.org; Thu, 26 Dec 2024 16:57:59 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 8d344f70-c3aa-11ef-a0da-8be0dac302b0;
 Thu, 26 Dec 2024 17:57:56 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1735232269626530.7045485100999;
 Thu, 26 Dec 2024 08:57: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: 8d344f70-c3aa-11ef-a0da-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1735232270; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=ENbSCjkzn2rYdwuAHr5dGskezSy5g8U2mMmRYV9bHZxIyoVRefBww2Q7kMAXX1LNqIZ037Nsm+NWeDoF3/9k0ErwxCTCJKa8WjpeVZG8Psmx5ZuPP1wasZ94CM1Q9Mg8Fno3DRAD5/YEEZBkub7Ld369yoLA7Jj+buPZEwSlMbs=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1735232270; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=nIHuSYK2rqiQJcqL0lovxzV4K0yQcvSsSbKym5BNNWY=; 
	b=j+IEelVi8Y5HoH98I/3di4emV+ocTXH5baFYM8KfWGhd+7BjSa4jhgqzCJBH1UouApb7WrcA1V06T5Lu2qYNaslW/dpTSimjBnx3pA0k7rz4SUuLu1XUK23I7U9u15o8P1DKxcH3bymhGnQ8rdTz7c6+dz4V5APPvYTqHOk+bfo=
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=1735232270;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=nIHuSYK2rqiQJcqL0lovxzV4K0yQcvSsSbKym5BNNWY=;
	b=G2Q86o5v/JMX+S/qTXSEkD1vEgyQLge6hrWy4VXPdUB2O8E2SmyDDg0ssgmn+gPt
	2AM/x8+pJIozcjVEPe3kbgPR2/qHZeEsJTjek9w68Bhegq+CULI0a4FYqFENq6r2m0z
	SZfpgM5PptdMgPoUrp+4OqmS439BhaxJAq6ORgHs=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	christopher.w.clark@gmail.com,
	stefano.stabellini@amd.com
Subject: [PATCH v2 00/15] Hyperlaunch device tree for dom0
Date: Thu, 26 Dec 2024 11:57:25 -0500
Message-Id: <20241226165740.29812-1-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

The Hyperlaunch device tree for dom0 series is the second split out for the
introduction of the Hyperlaunch domain builder logic. These changes focus on
introducing the ability to express a domain configuration that is then used to
populate the struct boot_domain structure for dom0. This ability to express a
domain configuration provides the next step towards a general domain builder.

The splitting of Hyperlaunch into a set of series are twofold, to reduce the
effort in reviewing a much larger series, and to reduce the effort in handling
the knock-on effects to the construction logic from requested review changes.

Much thanks to AMD for supporting this work.

Documentation on Hyperlaunch:
https://wiki.xenproject.org/wiki/Hyperlaunch

Original Hyperlaunch v1 patch series:
https://lists.xenproject.org/archives/html/xen-devel/2022-07/msg00345.html

V/r,
Daniel P. Smith

Daniel P. Smith (15):
  x86/boot: introduce boot domain
  x86/boot: introduce domid field to struct boot_domain
  x86/boot: add cmdline to struct boot_domain
  kconfig: introduce option to independently enable libfdt
  kconfig: introduce domain builder config option
  x86/hyperlaunch: introduce the domain builder
  x86/hyperlaunch: initial support for hyperlaunch device tree
  x86/hyperlaunch: locate dom0 kernel with hyperlaunch
  x86/hyperlaunch: obtain cmdline from device tree
  x86/hyperlaunch: locate dom0 initrd with hyperlaunch
  x86/hyperlaunch: add domain id parsing to domain config
  x86/hyperlaunch: specify dom0 mode with device tree
  x86/hyperlaunch: add memory parsing to domain config
  x86/hyperlaunch: add max vcpu parsing of hyperlaunch device tree
  x86/hyperlaunch: add capabilities to boot domain

 xen/arch/x86/Kconfig                     |   2 +
 xen/arch/x86/Makefile                    |   2 +
 xen/arch/x86/dom0_build.c                |  19 +-
 xen/arch/x86/domain-builder/Kconfig      |  15 +
 xen/arch/x86/domain-builder/Makefile     |   3 +
 xen/arch/x86/domain-builder/core.c       | 112 +++++++
 xen/arch/x86/domain-builder/fdt.c        | 389 +++++++++++++++++++++++
 xen/arch/x86/domain-builder/fdt.h        |  53 +++
 xen/arch/x86/hvm/dom0_build.c            |  37 +--
 xen/arch/x86/include/asm/bootdomain.h    |  49 +++
 xen/arch/x86/include/asm/bootinfo.h      |  15 +-
 xen/arch/x86/include/asm/dom0_build.h    |   6 +-
 xen/arch/x86/include/asm/domainbuilder.h |  12 +
 xen/arch/x86/include/asm/setup.h         |   4 +-
 xen/arch/x86/pv/dom0_build.c             |  28 +-
 xen/arch/x86/setup.c                     | 162 ++++++----
 xen/common/Kconfig                       |   4 +
 xen/common/Makefile                      |   2 +-
 xen/include/xen/libfdt/libfdt-xen.h      | 118 +++++++
 19 files changed, 922 insertions(+), 110 deletions(-)
 create mode 100644 xen/arch/x86/domain-builder/Kconfig
 create mode 100644 xen/arch/x86/domain-builder/Makefile
 create mode 100644 xen/arch/x86/domain-builder/core.c
 create mode 100644 xen/arch/x86/domain-builder/fdt.c
 create mode 100644 xen/arch/x86/domain-builder/fdt.h
 create mode 100644 xen/arch/x86/include/asm/bootdomain.h
 create mode 100644 xen/arch/x86/include/asm/domainbuilder.h

-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 26 16:58:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Dec 2024 16:58:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863240.1274667 (Exim 4.92)
	(envelope-from )
	id 1tQrBc-0002g3-PL; Thu, 26 Dec 2024 16:58:12 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863240.1274667; Thu, 26 Dec 2024 16:58: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 1tQrBc-0002fw-MB; Thu, 26 Dec 2024 16:58:12 +0000
Received: by outflank-mailman (input) for mailman id 863240;
 Thu, 26 Dec 2024 16:58: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 1tQrBb-00026T-UU
 for xen-devel@lists.xenproject.org; Thu, 26 Dec 2024 16:58:11 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 95e1c8de-c3aa-11ef-a0da-8be0dac302b0;
 Thu, 26 Dec 2024 17:58:11 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1735232272298956.4716909412124;
 Thu, 26 Dec 2024 08:57: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: 95e1c8de-c3aa-11ef-a0da-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1735232274; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=K/w2vq6EreekCze9dp3/gK9AfMDOPqxSLk8NTEMPVaWDFrRidtnoHkPyxzFJhB4EqZg7iaLym8Wc/wh3oQYwzt3vRHKk/VTGYYcabwdoESlrpwqSGHXL/WdEhbiBr2nFDEy0PJOjPlkxIogYb9Zk9BAoH6uxbeRaSCaX9B2H62A=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1735232274; h=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=Vny6kTLP1Zgh9pS1XObMWkggVqw9oNCU0me6bh/qKT0=; 
	b=hs9xJUPpT3W3Ht3QPOx96+ehkJQ7DJUEdbcZOq9sEfsdQaSOFXncBapqHjcs9jOfILH+Ch2YA6NgQlV1IvnMuaBGKxmud6IDw+dMn41r4vpb2gF4I3bYqkSyhHtdRkPyOkNe2JBYbgF2wCA5CR9/tPQhxXlnneuu4X1Vxha37pk=
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=1735232274;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=Vny6kTLP1Zgh9pS1XObMWkggVqw9oNCU0me6bh/qKT0=;
	b=e8s+QPuhbtWMPbLkTZbRs3RyEPdv5D7OTNFrShJvzHQTVXp7eoLHI/kCC8r4IJxy
	Eyl/7RtSyk4+O9k8+YvASIR4R2YDEV00ljjs0nmg9uLLCY/86nPRywXwjRyHgGyc5MG
	yxkzb+NxgooyN0plEGEdDZ/uDY9xq4+C9yT5ewy4=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	christopher.w.clark@gmail.com,
	stefano.stabellini@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 02/15] x86/boot: introduce domid field to struct boot_domain
Date: Thu, 26 Dec 2024 11:57:27 -0500
Message-Id: <20241226165740.29812-3-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20241226165740.29812-1-dpsmith@apertussolutions.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Add a domid field to struct boot_domain to hold the assigned domain id for the
domain. During initialization, ensure all instances of struct boot_domain have
the invalid domid to ensure that the domid must be set either by convention or
configuration.

Signed-off-by: Daniel P. Smith 
Reviewed-by: Jason Andryuk 
---
Changes since v1 dom0 device tree:
- made .domid part of the static init of xen_boot_info

Changes since v9 boot modules
- missing include for domid_t def
---
 xen/arch/x86/include/asm/bootdomain.h |  4 ++++
 xen/arch/x86/setup.c                  | 10 +++++-----
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/include/asm/bootdomain.h b/xen/arch/x86/include/asm/bootdomain.h
index 8d0e5c78d426..67be575fe781 100644
--- a/xen/arch/x86/include/asm/bootdomain.h
+++ b/xen/arch/x86/include/asm/bootdomain.h
@@ -5,10 +5,14 @@
  * Copyright (c) 2024 Christopher Clark 
  */
 
+#include 
+
 #ifndef __XEN_X86_BOOTDOMAIN_H__
 #define __XEN_X86_BOOTDOMAIN_H__
 
 struct boot_domain {
+    domid_t domid;
+
     struct boot_module *kernel;
     struct boot_module *ramdisk;
 
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 7e4529d6bfb2..27937a7f7aeb 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -292,6 +292,7 @@ static const char *cmdline_cook(const char *p, const char *loader_name);
 struct boot_info __initdata xen_boot_info = {
     .loader = "unknown",
     .cmdline = "",
+    .domains = { {.domid = DOMID_INVALID} },
 };
 
 static struct boot_info *__init multiboot_fill_boot_info(
@@ -991,7 +992,6 @@ static struct domain *__init create_dom0(struct boot_info *bi)
     };
     struct boot_domain *bd = &bi->domains[0];
     struct domain *d;
-    domid_t domid;
 
     if ( opt_dom0_pvh )
     {
@@ -1007,15 +1007,15 @@ static struct domain *__init create_dom0(struct boot_info *bi)
         dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
 
     /* Create initial domain.  Not d0 for pvshim. */
-    domid = get_initial_domain_id();
-    d = domain_create(domid, &dom0_cfg, pv_shim ? 0 : CDF_privileged);
+    bd->domid = get_initial_domain_id();
+    d = domain_create(bd->domid, &dom0_cfg, pv_shim ? 0 : CDF_privileged);
     if ( IS_ERR(d) )
-        panic("Error creating d%u: %ld\n", domid, PTR_ERR(d));
+        panic("Error creating d%u: %ld\n", bd->domid, PTR_ERR(d));
 
     init_dom0_cpuid_policy(d);
 
     if ( alloc_dom0_vcpu0(d) == NULL )
-        panic("Error creating d%uv0\n", domid);
+        panic("Error creating d%uv0\n", bd->domid);
 
     /* Grab the DOM0 command line. */
     if ( bd->kernel->cmdline_pa || bi->kextra )
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 26 16:58:21 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Dec 2024 16:58:21 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863245.1274676 (Exim 4.92)
	(envelope-from )
	id 1tQrBl-00039X-62; Thu, 26 Dec 2024 16:58:21 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863245.1274676; Thu, 26 Dec 2024 16:58: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 1tQrBl-00039K-3C; Thu, 26 Dec 2024 16:58:21 +0000
Received: by outflank-mailman (input) for mailman id 863245;
 Thu, 26 Dec 2024 16:58: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 1tQrBj-00026T-AB
 for xen-devel@lists.xenproject.org; Thu, 26 Dec 2024 16:58:19 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9a53d519-c3aa-11ef-a0da-8be0dac302b0;
 Thu, 26 Dec 2024 17:58:18 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1735232273654381.53674337156747;
 Thu, 26 Dec 2024 08:57: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: 9a53d519-c3aa-11ef-a0da-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1735232276; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=UqsHOLVe0cuGQXX8CRglyebO2vkr0qM81gyNDvroZvGJAhAbpnl9HB2xtS1Gr3Tw2DOwRzFA2MGIUa3H9/nUutGmUQQ1Nu9FTffwlowtu8iqFTQrwhgiJq+A/RGmbt9mungBVp3gM8yCzPtemZjJNaEjcfGf4gujxRjQ9nVO3Wo=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1735232276; h=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=fG1DwHOuY1y8Qw7V1e8eHce6xg4PlNOOzNk4YL76snY=; 
	b=cq6IaJCpcBseYLliQ/itw048FRybGhXj8IoV/Z7Jz0AZR9O9BaORPKRtob4pkIqEAoWnJ+28a4t8U/gkW5Nqm/M4FdKh/RPRFy+dAmWoub4e4hhEclRjHTRbSBBlP1jrjGGxfY7lGB4SuTQcRjlEBVDqMpGgN07MJXa3ZOR4/1M=
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=1735232276;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=fG1DwHOuY1y8Qw7V1e8eHce6xg4PlNOOzNk4YL76snY=;
	b=bZi0Q7nPT4qm7Ep7EOvW44uuj9xjEN8bb/YxnbLSzSVMcbUedatZcvWh7ZYp2GL2
	uvKzw94t4Rd4LLQzFngAanRxOmVAcLJrT9rdWbULsldZHFXROBUFaoWk/eCkTS/xKnR
	gA+ty1z302carQqk8muwzpng78NnfWgFj3YqrxRA=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	christopher.w.clark@gmail.com,
	stefano.stabellini@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 03/15] x86/boot: add cmdline to struct boot_domain
Date: Thu, 26 Dec 2024 11:57:28 -0500
Message-Id: <20241226165740.29812-4-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20241226165740.29812-1-dpsmith@apertussolutions.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Add a container for the "cooked" command line for a domain. This provides for
the backing memory to be directly associated with the domain being constructed.
This is done in anticipation that the domain construction path may need to be
invoked multiple times, thus ensuring each instance had a distinct memory
allocation.

Signed-off-by: Daniel P. Smith 
---
Changes since dom0 device tree v1:
- switched over to bd->cmdline in pvh_load_kernel
- moved cmdline processing under if, eliminating goto
- zero-ed cmdline_pa for kernel module after cmdline processing

Changes since v9 boot modules:
- convert pvh_load_kernel to boot domain to directly use cmdline
- adjustments to domain_cmdline_size
  - remove ASSERT and return 0 instead
  - use strlen() of values instead of hardcoded sizes
- update cmdline parsing check to inspect multiboot string and not just pointer
- add goto to skip cmdline processing if domain_cmdline_size returns 0
- drop updating cmdline_pa with dynamic buffer with change of its last consumer
  pvh_load_kernel

Changes since v8:
- switch to a dynamically allocated buffer
- dropped local cmdline var in pv dom0_construct()

Changes since v7:
- updated commit message to expand on intent and purpose
---
 xen/arch/x86/hvm/dom0_build.c         | 14 ++---
 xen/arch/x86/include/asm/bootdomain.h |  2 +
 xen/arch/x86/pv/dom0_build.c          |  4 +-
 xen/arch/x86/setup.c                  | 78 +++++++++++++++++++--------
 4 files changed, 66 insertions(+), 32 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index cbc365d678d2..47bc3e9ce858 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -653,7 +653,6 @@ static int __init pvh_load_kernel(
     void *image_start = image_base + image->headroom;
     unsigned long image_len = image->size;
     unsigned long initrd_len = initrd ? initrd->size : 0;
-    const char *cmdline = image->cmdline_pa ? __va(image->cmdline_pa) : NULL;
     struct elf_binary elf;
     struct elf_dom_parms parms;
     paddr_t last_addr;
@@ -717,9 +716,9 @@ static int __init pvh_load_kernel(
                             (initrd ? ROUNDUP(initrd_len, PAGE_SIZE) +
                                       sizeof(mod)
                                     : 0) +
-                            (cmdline ? ROUNDUP(strlen(cmdline) + 1,
-                                               elf_64bit(&elf) ? 8 : 4)
-                                     : 0));
+                            (bd->cmdline ? ROUNDUP(strlen(bd->cmdline) + 1,
+                                                   elf_64bit(&elf) ? 8 : 4)
+                                         : 0));
     if ( last_addr == INVALID_PADDR )
     {
         printk("Unable to find a memory region to load initrd and metadata\n");
@@ -759,9 +758,10 @@ static int __init pvh_load_kernel(
     /* Free temporary buffers. */
     free_boot_modules();
 
-    if ( cmdline != NULL )
+    if ( bd->cmdline != NULL )
     {
-        rc = hvm_copy_to_guest_phys(last_addr, cmdline, strlen(cmdline) + 1, v);
+        rc = hvm_copy_to_guest_phys(
+                last_addr, bd->cmdline, strlen(bd->cmdline) + 1, v);
         if ( rc )
         {
             printk("Unable to copy guest command line\n");
@@ -772,7 +772,7 @@ static int __init pvh_load_kernel(
          * Round up to 32/64 bits (depending on the guest kernel bitness) so
          * the modlist/start_info is aligned.
          */
-        last_addr += ROUNDUP(strlen(cmdline) + 1, elf_64bit(&elf) ? 8 : 4);
+        last_addr += ROUNDUP(strlen(bd->cmdline) + 1, elf_64bit(&elf) ? 8 : 4);
     }
     if ( initrd != NULL )
     {
diff --git a/xen/arch/x86/include/asm/bootdomain.h b/xen/arch/x86/include/asm/bootdomain.h
index 67be575fe781..101a0c643d74 100644
--- a/xen/arch/x86/include/asm/bootdomain.h
+++ b/xen/arch/x86/include/asm/bootdomain.h
@@ -11,6 +11,8 @@
 #define __XEN_X86_BOOTDOMAIN_H__
 
 struct boot_domain {
+    const char *cmdline;
+
     domid_t domid;
 
     struct boot_module *kernel;
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index e0709a1c1a7a..580f2703a154 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -972,8 +972,8 @@ static int __init dom0_construct(struct boot_domain *bd)
     }
 
     memset(si->cmd_line, 0, sizeof(si->cmd_line));
-    if ( image->cmdline_pa )
-        strlcpy((char *)si->cmd_line, __va(image->cmdline_pa), sizeof(si->cmd_line));
+    if ( bd->cmdline )
+        strlcpy((char *)si->cmd_line, bd->cmdline, sizeof(si->cmd_line));
 
 #ifdef CONFIG_VIDEO
     if ( !pv_shim && fill_console_start_info((void *)(si + 1)) )
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 27937a7f7aeb..a61131365477 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -975,10 +975,29 @@ static unsigned int __init copy_bios_e820(struct e820entry *map, unsigned int li
     return n;
 }
 
-static struct domain *__init create_dom0(struct boot_info *bi)
+static size_t __init domain_cmdline_size(
+    struct boot_info *bi, struct boot_domain *bd)
 {
-    static char __initdata cmdline[MAX_GUEST_CMDLINE];
+    size_t s = bi->kextra ? strlen(bi->kextra) : 0;
+
+    s += bd->kernel->cmdline_pa ? strlen(__va(bd->kernel->cmdline_pa)) : 0;
+
+    if ( s == 0 )
+        return s;
+
+    /*
+     * Certain parameters from the Xen command line may be added to the dom0
+     * command line. Add additional space for the possible cases along with one
+     * extra char to hold \0.
+     */
+    s += strlen(" noapic") + strlen(" acpi=") + sizeof(acpi_param) + 1;
 
+    return s;
+}
+
+static struct domain *__init create_dom0(struct boot_info *bi)
+{
+    char *cmdline = NULL;
     struct xen_domctl_createdomain dom0_cfg = {
         .flags = IS_ENABLED(CONFIG_TBOOT) ? XEN_DOMCTL_CDF_s3_integrity : 0,
         .max_evtchn_port = -1,
@@ -1018,39 +1037,52 @@ static struct domain *__init create_dom0(struct boot_info *bi)
         panic("Error creating d%uv0\n", bd->domid);
 
     /* Grab the DOM0 command line. */
-    if ( bd->kernel->cmdline_pa || bi->kextra )
+    if ( (bd->kernel->cmdline_pa &&
+          ((char *)__va(bd->kernel->cmdline_pa))[0]) ||
+         bi->kextra )
     {
-        if ( bd->kernel->cmdline_pa )
-            safe_strcpy(cmdline,
-                        cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader));
+        size_t cmdline_size = domain_cmdline_size(bi, bd);
+
+        if ( cmdline_size )
+        {
+            if ( !(cmdline = xzalloc_array(char, cmdline_size)) )
+                panic("Error allocating cmdline buffer for %pd\n", d);
 
-        if ( bi->kextra )
-            /* kextra always includes exactly one leading space. */
-            safe_strcat(cmdline, bi->kextra);
+            if ( bd->kernel->cmdline_pa )
+                strlcpy(cmdline,
+                        cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader),
+                        cmdline_size);
 
-        /* Append any extra parameters. */
-        if ( skip_ioapic_setup && !strstr(cmdline, "noapic") )
-            safe_strcat(cmdline, " noapic");
+            if ( bi->kextra )
+                /* kextra always includes exactly one leading space. */
+                strlcat(cmdline, bi->kextra, cmdline_size);
 
-        if ( (strlen(acpi_param) == 0) && acpi_disabled )
-        {
-            printk("ACPI is disabled, notifying Domain 0 (acpi=off)\n");
-            safe_strcpy(acpi_param, "off");
-        }
+            /* Append any extra parameters. */
+            if ( skip_ioapic_setup && !strstr(cmdline, "noapic") )
+                strlcat(cmdline, " noapic", cmdline_size);
 
-        if ( (strlen(acpi_param) != 0) && !strstr(cmdline, "acpi=") )
-        {
-            safe_strcat(cmdline, " acpi=");
-            safe_strcat(cmdline, acpi_param);
-        }
+            if ( (strlen(acpi_param) == 0) && acpi_disabled )
+            {
+                printk("ACPI is disabled, notifying Domain 0 (acpi=off)\n");
+                safe_strcpy(acpi_param, "off");
+            }
 
-        bd->kernel->cmdline_pa = __pa(cmdline);
+            if ( (strlen(acpi_param) != 0) && !strstr(cmdline, "acpi=") )
+            {
+                strlcat(cmdline, " acpi=", cmdline_size);
+                strlcat(cmdline, acpi_param, cmdline_size);
+            }
+            bd->kernel->cmdline_pa = 0;
+            bd->cmdline = cmdline;
+        }
     }
 
     bd->d = d;
     if ( construct_dom0(bd) != 0 )
         panic("Could not construct domain 0\n");
 
+    xfree(cmdline);
+
     return d;
 }
 
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 26 16:58:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Dec 2024 16:58:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863254.1274686 (Exim 4.92)
	(envelope-from )
	id 1tQrBx-0003nW-ED; Thu, 26 Dec 2024 16:58:33 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863254.1274686; Thu, 26 Dec 2024 16:58: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 1tQrBx-0003nO-BK; Thu, 26 Dec 2024 16:58:33 +0000
Received: by outflank-mailman (input) for mailman id 863254;
 Thu, 26 Dec 2024 16:58: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 1tQrBv-00026T-QV
 for xen-devel@lists.xenproject.org; Thu, 26 Dec 2024 16:58:31 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a166dfd6-c3aa-11ef-a0da-8be0dac302b0;
 Thu, 26 Dec 2024 17:58:30 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1735232275282537.8488659077085;
 Thu, 26 Dec 2024 08:57: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: a166dfd6-c3aa-11ef-a0da-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1735232278; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=W3DodgsazXFjX0SgC7QZPmQngljNi6P3X1Ga6aPmmqLyubSdmVWjkTTBkYcht06FJZ7FOZJLSRfuPKmV6bwsUdUbjpKrXhjymNJh0Q9VyRUJeHsekrFn0Fssm2r15UkUfUpYh/tyBAWZ/TDeeBJDlzNopnHqlZK6dSMd0XihsrA=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1735232278; h=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=x++da7MTBOqDP2KwlGntWaTQGzUq2g/NoStpY3TKCOk=; 
	b=KnsTPMZO8WNaI3N0W9CgbY8vgQvswWQZ+fquFXtRPYzeJHzaoKpp7dlWovIPdcWELAhl64umXCL/rOgtY8dlfeKBIXovKc8PIwRkaBunWy3eRgM69KtE9Abug4QURByXyY83a5Rt8xbZvhLMirFaMCiDcj9PQwGeuTaWR0fzQRE=
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=1735232278;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=x++da7MTBOqDP2KwlGntWaTQGzUq2g/NoStpY3TKCOk=;
	b=huWXxgNUFU9hytyQsge//J9qvUI1mnw7xIsSSmnZAX5i/Ntpz0LMUP/lngDLVUlh
	RSZsWYCje8sCmfil6MQemy1JsFNnRkZNCHDTiFWM3CKvdZswMx73En0skcxYdVlvXvv
	3fg62La3zTl2+UwwGuYUnHGmj5ZE5NBh3KrRySvM=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	christopher.w.clark@gmail.com,
	stefano.stabellini@amd.com,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini 
Subject: [PATCH v2 04/15] kconfig: introduce option to independently enable libfdt
Date: Thu, 26 Dec 2024 11:57:29 -0500
Message-Id: <20241226165740.29812-5-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20241226165740.29812-1-dpsmith@apertussolutions.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Currently, the inclusion of libfdt is controlled by the CONFIG_HAS_DEVICE_TREE
kconfig flag. This flag also changes behavior in a few places, such as boot
module processing for XSM. To support the ability to include libfdt without
changing these behaviors, introduce CONFIG_LIB_DEVICE_TREE. The inclusion of
libfdt is then moved under CONFIG_LIB_DEVICE_TREE.

Signed-off-by: Daniel P. Smith 
Reviewed-by: Jason Andryuk 
---
Changes since v1:
- grammar and spelling fixes to commit message
- corrected indentation to Kconfig format
- relocated LIB_DEVICE_TREE to alphabet ordered location
---
 xen/common/Kconfig  | 4 ++++
 xen/common/Makefile | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 6166327f4d14..028ed9c3631e 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -55,6 +55,7 @@ config HAS_COMPAT
 
 config HAS_DEVICE_TREE
 	bool
+	select LIB_DEVICE_TREE
 
 config HAS_DIT # Data Independent Timing
 	bool
@@ -89,6 +90,9 @@ config HAS_UBSAN
 config HAS_VMAP
 	bool
 
+config LIB_DEVICE_TREE
+	bool
+
 config MEM_ACCESS_ALWAYS_ON
 	bool
 
diff --git a/xen/common/Makefile b/xen/common/Makefile
index cba3b32733ba..3d29aef01155 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -79,7 +79,7 @@ obj-y += sched/
 obj-$(CONFIG_UBSAN) += ubsan/
 
 obj-$(CONFIG_NEEDS_LIBELF) += libelf/
-obj-$(CONFIG_HAS_DEVICE_TREE) += libfdt/
+obj-$(CONFIG_LIB_DEVICE_TREE) += libfdt/
 
 CONF_FILE := $(if $(patsubst /%,,$(KCONFIG_CONFIG)),$(objtree)/)$(KCONFIG_CONFIG)
 $(obj)/config.gz: $(CONF_FILE)
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 26 17:00:04 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Dec 2024 17:00:04 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863268.1274697 (Exim 4.92)
	(envelope-from )
	id 1tQrDO-000521-Ou; Thu, 26 Dec 2024 17:00:02 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863268.1274697; Thu, 26 Dec 2024 17:00: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 1tQrDO-00051a-Lm; Thu, 26 Dec 2024 17:00:02 +0000
Received: by outflank-mailman (input) for mailman id 863268;
 Thu, 26 Dec 2024 17:00: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 1tQrDN-0004jO-Ea
 for xen-devel@lists.xenproject.org; Thu, 26 Dec 2024 17:00:01 +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 d63973b0-c3aa-11ef-99a3-01e77a169b0f;
 Thu, 26 Dec 2024 17:59:59 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1735232283698320.3434638736318;
 Thu, 26 Dec 2024 08:58: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: d63973b0-c3aa-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1735232287; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=ijMgNeCTT+xj8yjpmZwQ/fAql3ZKsKdy3Y/i7OEnwbe1A6LLFtJ9Sm2Hoa8Tg9FGEDZqryhIznlzw2QS14sT4Vc69L+q66LCvFXyQ6Xb3zI6C5okVr6yJnwFYELxeFe22ACBu2yaKowy2wX6FSsovfu5pgQOFDXr2QHX0a21P2w=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1735232287; h=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=FcFHTvIehUz+pCAW6d935kvWaFMj2gZMq8dfpZ6OKRU=; 
	b=V76opvHZbjx0B5F+qFLAq6tiaVAzp2Cq1LSeQFo/MkjruwH5xEDIHurLraLnl2RppGZvKGcX2vNo1Delfj4BWlfJDYUlgWNJj22sZJC9ozXAnYeXG4eXu3o9rm/imerEtlgIYdnjTMH3elyyJwrq3c/ztmVJDVR1jCJM+podp6w=
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=1735232287;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=FcFHTvIehUz+pCAW6d935kvWaFMj2gZMq8dfpZ6OKRU=;
	b=tk8KiUFqogVIv/IkS1BHWxC1p39GfaV9IismgTdSk2RakH4MF2uHp6g2nWdvER2v
	G3OUBVu/55ow6aoASIk+UQJVmOMITA2p8AmuLJcwgITZUfwJ9sIFf1DOyJgP14sw5VJ
	VTXCN14kpphecT2SeaULz2s5c4er/Tx6VjOHH+gc=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	christopher.w.clark@gmail.com,
	stefano.stabellini@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 10/15] x86/hyperlaunch: locate dom0 initrd with hyperlaunch
Date: Thu, 26 Dec 2024 11:57:35 -0500
Message-Id: <20241226165740.29812-11-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20241226165740.29812-1-dpsmith@apertussolutions.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Look for a subnode of type `multiboot,ramdisk` within a domain node. If
found, process the reg property for the MB1 module index.

Signed-off-by: Daniel P. Smith 
---
Changes since v1:
- switch to nested else/if
- dropped ternary name selection
---
 xen/arch/x86/domain-builder/fdt.c | 26 +++++++++++++++++++++++
 xen/arch/x86/setup.c              | 35 +++++++++++++++++--------------
 2 files changed, 45 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/domain-builder/fdt.c b/xen/arch/x86/domain-builder/fdt.c
index 1094c8dc8838..27bc37ad45c9 100644
--- a/xen/arch/x86/domain-builder/fdt.c
+++ b/xen/arch/x86/domain-builder/fdt.c
@@ -119,6 +119,32 @@ static int __init process_domain_node(
                 if ( ret > 0 )
                     bd->kernel->fdt_cmdline = true;
             }
+
+            continue;
+        }
+        else if (
+            fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
+        {
+            int idx = dom0less_module_node(fdt, node, size_size, address_size);
+            if ( idx < 0 )
+            {
+                printk("  failed processing ramdisk module for domain %s\n",
+                       name);
+                return -EINVAL;
+            }
+
+            if ( idx > bi->nr_modules )
+            {
+                printk("  invalid ramdisk module index for domain node (%d)\n",
+                       bi->nr_domains);
+                return -EINVAL;
+            }
+
+            printk("  ramdisk: boot module %d\n", idx);
+            bi->mods[idx].type = BOOTMOD_RAMDISK;
+            bd->ramdisk = &bi->mods[idx];
+
+            continue;
         }
     }
 
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 3dd04b9afca7..25ff029ecdda 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1103,7 +1103,7 @@ void asmlinkage __init noreturn __start_xen(void)
     char *kextra;
     void *bsp_stack;
     struct cpu_info *info = get_cpu_info(), *bsp_info;
-    unsigned int initrdidx, num_parked = 0;
+    unsigned int num_parked = 0;
     struct boot_info *bi;
     unsigned long nr_pages, raw_max_page;
     int i, j, bytes = 0;
@@ -2141,22 +2141,25 @@ void asmlinkage __init noreturn __start_xen(void)
            cpu_has_nx ? XENLOG_INFO : XENLOG_WARNING "Warning: ",
            cpu_has_nx ? "" : "not ");
 
-    /*
-     * At this point all capabilities that consume boot modules should have
-     * claimed their boot modules. Find the first unclaimed boot module and
-     * claim it as the initrd ramdisk. Do a second search to see if there are
-     * any remaining unclaimed boot modules, and report them as unusued initrd
-     * candidates.
-     */
-    initrdidx = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
-    if ( initrdidx < MAX_NR_BOOTMODS )
+    if ( !bi->hyperlaunch_enabled )
     {
-        bi->mods[initrdidx].type = BOOTMOD_RAMDISK;
-        bi->domains[0].ramdisk = &bi->mods[initrdidx];
-        if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
-            printk(XENLOG_WARNING
-                   "Multiple initrd candidates, picking module #%u\n",
-                   initrdidx);
+        /*
+         * At this point all capabilities that consume boot modules should have
+         * claimed their boot modules. Find the first unclaimed boot module and
+         * claim it as the initrd ramdisk. Do a second search to see if there are
+         * any remaining unclaimed boot modules, and report them as unusued initrd
+         * candidates.
+         */
+        unsigned int initrdidx = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
+        if ( initrdidx < MAX_NR_BOOTMODS )
+        {
+            bi->mods[initrdidx].type = BOOTMOD_RAMDISK;
+            bi->domains[0].ramdisk = &bi->mods[initrdidx];
+            if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
+                printk(XENLOG_WARNING
+                       "Multiple initrd candidates, picking module #%u\n",
+                       initrdidx);
+        }
     }
 
     /*
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 26 17:00:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Dec 2024 17:00:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863269.1274707 (Exim 4.92)
	(envelope-from )
	id 1tQrDX-0005xo-Vf; Thu, 26 Dec 2024 17:00:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863269.1274707; Thu, 26 Dec 2024 17:00: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 1tQrDX-0005xh-SW; Thu, 26 Dec 2024 17:00:11 +0000
Received: by outflank-mailman (input) for mailman id 863269;
 Thu, 26 Dec 2024 17:00: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 1tQrDW-0004jO-KQ
 for xen-devel@lists.xenproject.org; Thu, 26 Dec 2024 17:00:10 +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 dbdf9205-c3aa-11ef-99a3-01e77a169b0f;
 Thu, 26 Dec 2024 18:00:08 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1735232285226312.33226760964567;
 Thu, 26 Dec 2024 08:58:05 -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: dbdf9205-c3aa-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1735232289; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=alYzYrV8sfRXiHHUPlqhlhrlh6i/cb6wtqTfUkTWwlrqacFGbx2fSB9+rC3IF5RJ9z3szvw9Sob4cKBzpn7FgQ0xHT77KpxNcdSqsc3zLjbX9NEjZ6a+KPkVnfVMj87IYjzE3p9RFoYTJQ1Grr8fdGBL9eud6TNbr4HEYN0MRhM=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1735232289; h=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=+3VU4l/0ipLKSYE0pW048JWQkTZXYcfFfQtanDIG30U=; 
	b=nzRcXdI0vSxNjSz+XvFb4lTgtxnF56fEYDLlLt2L6GfLarDvp1U09DFjjJydtaRiZhGJXrD2X0Rzo8AgS9T+bzckdArJvZGokoYi4W0HykuvybNw1kWT2xgkUvtoZ99G/FG5z+tkhyAJCXzxVc56uaTGI/gHb+FsEZYdRCF7N4o=
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=1735232289;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=+3VU4l/0ipLKSYE0pW048JWQkTZXYcfFfQtanDIG30U=;
	b=QD1XEnj7i2BhFh19jpZHoN32WCt8CZZs4DmM0CwPG6uQUaOrBCBENwbskRjNUXXO
	r5rqxyMagDb/7vZthgGgmOpT2Pc1E/6m8GMMIJWfMpiNGW5GoGZKG663rLTTi3Pn8FJ
	lzm49s/eAo38pFIEDJMEytHwvAmPB9+TBKhlWan8=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	christopher.w.clark@gmail.com,
	stefano.stabellini@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel 
Subject: [PATCH v2 11/15] x86/hyperlaunch: add domain id parsing to domain config
Date: Thu, 26 Dec 2024 11:57:36 -0500
Message-Id: <20241226165740.29812-12-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20241226165740.29812-1-dpsmith@apertussolutions.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Introduce the ability to specify the desired domain id for the domain
definition. The domain id will be populated in the domid property of the domain
node in the device tree configuration.

Signed-off-by: Daniel P. Smith 
---
Changes since v1
- coding style changes
- moved comment with code movement
- updated warning message
- unrolled match_fdt_property()
---
 xen/arch/x86/domain-builder/fdt.c   | 63 ++++++++++++++++++++++++++++-
 xen/arch/x86/setup.c                |  5 ++-
 xen/include/xen/libfdt/libfdt-xen.h |  9 +++++
 3 files changed, 73 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/domain-builder/fdt.c b/xen/arch/x86/domain-builder/fdt.c
index 27bc37ad45c9..efce0927c645 100644
--- a/xen/arch/x86/domain-builder/fdt.c
+++ b/xen/arch/x86/domain-builder/fdt.c
@@ -8,6 +8,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -61,10 +62,40 @@ static int __init dom0less_module_index(
 static int __init process_domain_node(
     struct boot_info *bi, void *fdt, int dom_node)
 {
-    int node;
+    int node, property;
     struct boot_domain *bd = &bi->domains[bi->nr_domains];
     const char *name = fdt_get_name(fdt, dom_node, NULL) ?: "unknown";
 
+    fdt_for_each_property_offset(property, fdt, dom_node)
+    {
+        const struct fdt_property *prop;
+        const char *prop_name;
+        int name_len;
+
+        prop = fdt_get_property_by_offset(fdt, property, NULL);
+        if ( !prop )
+            continue; /* silently skip */
+
+        prop_name = fdt_get_string(fdt, fdt32_to_cpu(prop->nameoff), &name_len);
+
+        if ( strncmp(prop_name, "domid", name_len) == 0 )
+        {
+            uint32_t val = DOMID_INVALID;
+            if ( fdt_prop_as_u32(prop, &val) != 0 )
+            {
+                printk("  failed processing domain id for domain %s\n", name);
+                return -EINVAL;
+            }
+            if ( val >= DOMID_FIRST_RESERVED )
+            {
+                printk("  invalid domain id for domain %s\n", name);
+                return -EINVAL;
+            }
+            bd->domid = (domid_t)val;
+            printk("  domid: %d\n", bd->domid);
+        }
+    }
+
     fdt_for_each_subnode(node, fdt, dom_node)
     {
         if ( fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
@@ -125,7 +156,29 @@ static int __init process_domain_node(
         else if (
             fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )
         {
-            int idx = dom0less_module_node(fdt, node, size_size, address_size);
+            unsigned int idx;
+            int ret = 0;
+
+            if ( bd->ramdisk )
+            {
+                printk(XENLOG_ERR "Duplicate ramdisk module for domain %s)\n",
+                       name);
+                continue;
+            }
+
+            /* Try hyperlaunch property, fall back to dom0less property. */
+            if ( hl_module_index(fdt, node, &idx) < 0 )
+            {
+                int address_size = fdt_address_cells(fdt, dom_node);
+                int size_size = fdt_size_cells(fdt, dom_node);
+
+                if ( address_size < 0 || size_size < 0 )
+                    ret = -EINVAL;
+                else
+                    ret = dom0less_module_index(
+                            fdt, node, size_size, address_size, &idx);
+            }
+
             if ( idx < 0 )
             {
                 printk("  failed processing ramdisk module for domain %s\n",
@@ -154,6 +207,12 @@ static int __init process_domain_node(
         return -EFAULT;
     }
 
+    if ( bd->domid == DOMID_INVALID )
+        bd->domid = get_initial_domain_id();
+    else if ( bd->domid != get_initial_domain_id() )
+        printk(XENLOG_WARNING
+               "WARN: Booting without initial domid not supported.\n");
+
     return 0;
 }
 
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 25ff029ecdda..027b224151d1 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1029,8 +1029,9 @@ static struct domain *__init create_dom0(struct boot_info *bi)
     if ( iommu_enabled )
         dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
 
-    /* Create initial domain.  Not d0 for pvshim. */
-    bd->domid = get_initial_domain_id();
+    if ( bd->domid == DOMID_INVALID )
+        /* Create initial domain.  Not d0 for pvshim. */
+        bd->domid = get_initial_domain_id();
     d = domain_create(bd->domid, &dom0_cfg, pv_shim ? 0 : CDF_privileged);
     if ( IS_ERR(d) )
         panic("Error creating d%u: %ld\n", bd->domid, PTR_ERR(d));
diff --git a/xen/include/xen/libfdt/libfdt-xen.h b/xen/include/xen/libfdt/libfdt-xen.h
index 0e54aeeb6cc2..2057030dda45 100644
--- a/xen/include/xen/libfdt/libfdt-xen.h
+++ b/xen/include/xen/libfdt/libfdt-xen.h
@@ -28,6 +28,15 @@ static inline int __init fdt_cell_as_u64(const fdt32_t *cell, uint64_t *val)
     return 0;
 }
 
+static inline int __init fdt_prop_as_u32(
+    const struct fdt_property *prop, uint32_t *val)
+{
+    if ( !prop || fdt32_to_cpu(prop->len) < sizeof(u32) )
+        return -EINVAL;
+
+    return fdt_cell_as_u32((fdt32_t *)prop->data, val);
+}
+
 static inline int __init fdt_get_prop_by_offset(
     const void *fdt, int node, const char *name, unsigned long *offset)
 {
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 26 17:00:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Dec 2024 17:00:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863281.1274716 (Exim 4.92)
	(envelope-from )
	id 1tQrDq-0006g6-Bm; Thu, 26 Dec 2024 17:00:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863281.1274716; Thu, 26 Dec 2024 17:00: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 1tQrDq-0006fz-9A; Thu, 26 Dec 2024 17:00:30 +0000
Received: by outflank-mailman (input) for mailman id 863281;
 Thu, 26 Dec 2024 17:00: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 1tQrCH-00026T-H5
 for xen-devel@lists.xenproject.org; Thu, 26 Dec 2024 16:58:53 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id aebecc99-c3aa-11ef-a0da-8be0dac302b0;
 Thu, 26 Dec 2024 17:58:53 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1735232277910815.1102165773889;
 Thu, 26 Dec 2024 08:57: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: aebecc99-c3aa-11ef-a0da-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1735232281; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=WYIn9XY6vpvXFT5X8bk8CqZfaq6m+vH6VR+LqpDtUylJ8CrfmGej/AHOigsDE2/oIALnm2MkWKFv0ln7NoFIvtPRZPEu7+J1e8qvUFMfu7GivZBdoyLh5dSAzIo9I4jVv/5dKL+Q8awyXUN4HgxYIlU04i2Bh7NiNiBTRmnTUtM=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1735232281; h=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=LG2YwRtPS1LBhMACiQKrmt4rkbz967gy6EJa6rK3Ja8=; 
	b=TcbymdHc2/avL3xTlTq3kMjj2x/Sc8amUCU7VD9roTH+ih43fp3lVW56/QpwAS86bA/jAc+I9LM55cSo7P10b2/qCPLFdpSXC779obFgTlofTRE2vEUH8qDtcNwyFPS0U4paQY9k+sQTgdiEx/FZk0mcguXKzpv1xSc7ChQR/wE=
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=1735232281;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=LG2YwRtPS1LBhMACiQKrmt4rkbz967gy6EJa6rK3Ja8=;
	b=UZN+CVPV/422zdyxIt3TB+cW9hp2YjYet50NMIlJfAlfu8JWWnsu3fI057L142iZ
	h4R8VioyUXZPRDWULFU6/6kwrX6gODUeduDYng6KwHDPiuPXLxj/wUGRZNyoLSXTDQC
	zuJxV86UBFS7xPOBIBKY0AAWUdtvIhkGrJQ9mWzg=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	christopher.w.clark@gmail.com,
	stefano.stabellini@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 06/15] x86/hyperlaunch: introduce the domain builder
Date: Thu, 26 Dec 2024 11:57:31 -0500
Message-Id: <20241226165740.29812-7-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20241226165740.29812-1-dpsmith@apertussolutions.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Introduce the domain builder which is capable of consuming a device tree as the
first boot module. If it finds a device tree as the first boot module, it will
set its type to BOOTMOD_FDT. This change only detects the boot module and
continues to boot with slight change to the boot convention that the dom0
kernel is no longer first boot module but is the second.

No functional change intended.

Signed-off-by: Daniel P. Smith 
Reviewed-by: Jason Andryuk 
---
Changes since v1:
- coding style compliance
- removed unnecessary include of rangeset.h
- fixed a missed change from 0 to i
- add missing const
- remove unnecessary first_boot_module_index() usages
---
 xen/arch/x86/Kconfig                     |  2 +-
 xen/arch/x86/Makefile                    |  2 +
 xen/arch/x86/domain-builder/Makefile     |  3 ++
 xen/arch/x86/domain-builder/core.c       | 57 ++++++++++++++++++++++++
 xen/arch/x86/domain-builder/fdt.c        | 37 +++++++++++++++
 xen/arch/x86/domain-builder/fdt.h        | 21 +++++++++
 xen/arch/x86/include/asm/bootinfo.h      |  3 ++
 xen/arch/x86/include/asm/domainbuilder.h |  8 ++++
 xen/arch/x86/setup.c                     | 17 ++++---
 9 files changed, 143 insertions(+), 7 deletions(-)
 create mode 100644 xen/arch/x86/domain-builder/Makefile
 create mode 100644 xen/arch/x86/domain-builder/core.c
 create mode 100644 xen/arch/x86/domain-builder/fdt.c
 create mode 100644 xen/arch/x86/domain-builder/fdt.h
 create mode 100644 xen/arch/x86/include/asm/domainbuilder.h

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 25b9b75423c5..50b4697da565 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -383,7 +383,7 @@ config ALTP2M
 
 	  If unsure, stay with defaults.
 
-source "arch/x86/domain_builder/Kconfig"
+source "arch/x86/domain-builder/Kconfig"
 
 endmenu
 
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index b35fd5196ce2..73b332dd471b 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -81,6 +81,8 @@ obj-$(CONFIG_COMPAT) += x86_64/platform_hypercall.o
 obj-y += sysctl.o
 endif
 
+obj-y += domain-builder/
+
 extra-y += asm-macros.i
 extra-y += xen.lds
 
diff --git a/xen/arch/x86/domain-builder/Makefile b/xen/arch/x86/domain-builder/Makefile
new file mode 100644
index 000000000000..309a0c4bdd9e
--- /dev/null
+++ b/xen/arch/x86/domain-builder/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_DOMAIN_BUILDER) += fdt.init.o
+obj-y += core.init.o
+
diff --git a/xen/arch/x86/domain-builder/core.c b/xen/arch/x86/domain-builder/core.c
new file mode 100644
index 000000000000..d6ae94f45c72
--- /dev/null
+++ b/xen/arch/x86/domain-builder/core.c
@@ -0,0 +1,57 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2024, Apertus Solutions, LLC
+ */
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "fdt.h"
+
+void __init builder_init(struct boot_info *bi)
+{
+    if ( IS_ENABLED(CONFIG_DOMAIN_BUILDER) )
+    {
+        int ret;
+
+        switch ( ret = has_hyperlaunch_fdt(bi) )
+        {
+        case 0:
+            printk("Hyperlaunch device tree detected\n");
+            bi->hyperlaunch_enabled = true;
+            bi->mods[0].type = BOOTMOD_FDT;
+            break;
+
+        case -EINVAL:
+            printk("Hyperlaunch device tree was not detected\n");
+            bi->hyperlaunch_enabled = false;
+            break;
+
+        case -ENOENT:
+        case -ENODATA:
+            printk("Device tree found, but not hyperlaunch (%d)\n", ret);
+            bi->hyperlaunch_enabled = false;
+            bi->mods[0].type = BOOTMOD_FDT;
+            break;
+
+        default:
+            printk("Unknown error (%d) occured checking for hyperlaunch device tree\n",
+                   ret);
+            bi->hyperlaunch_enabled = false;
+            break;
+        }
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/domain-builder/fdt.c b/xen/arch/x86/domain-builder/fdt.c
new file mode 100644
index 000000000000..4a3f80648f86
--- /dev/null
+++ b/xen/arch/x86/domain-builder/fdt.c
@@ -0,0 +1,37 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2024, Apertus Solutions, LLC
+ */
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "fdt.h"
+
+int __init has_hyperlaunch_fdt(struct boot_info *bi)
+{
+    int ret = 0;
+    const void *fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);
+
+    if ( fdt_check_header(fdt) < 0 )
+        ret = -EINVAL;
+
+    bootstrap_unmap();
+
+    return ret;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/domain-builder/fdt.h b/xen/arch/x86/domain-builder/fdt.h
new file mode 100644
index 000000000000..1c1569a9c633
--- /dev/null
+++ b/xen/arch/x86/domain-builder/fdt.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) */
+#ifndef __XEN_X86_FDT_H__
+#define __XEN_X86_FDT_H__
+
+#include 
+
+#include 
+
+/* hyperlaunch fdt is required to be module 0 */
+#define HYPERLAUNCH_MODULE_IDX 0
+
+#ifdef CONFIG_DOMAIN_BUILDER
+int has_hyperlaunch_fdt(struct boot_info *bi);
+#else
+static inline int __init has_hyperlaunch_fdt(struct boot_info *bi)
+{
+    return -EINVAL;
+}
+#endif
+
+#endif /* __XEN_X86_FDT_H__ */
diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index 9f65e2c8f62d..208bec90913d 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -27,6 +27,7 @@ enum bootmod_type {
     BOOTMOD_RAMDISK,
     BOOTMOD_MICROCODE,
     BOOTMOD_XSM_POLICY,
+    BOOTMOD_FDT,
 };
 
 struct boot_module {
@@ -80,6 +81,8 @@ struct boot_info {
     paddr_t memmap_addr;
     size_t memmap_length;
 
+    bool hyperlaunch_enabled;
+
     unsigned int nr_modules;
     struct boot_module mods[MAX_NR_BOOTMODS + 1];
     struct boot_domain domains[MAX_NR_BOOTDOMS];
diff --git a/xen/arch/x86/include/asm/domainbuilder.h b/xen/arch/x86/include/asm/domainbuilder.h
new file mode 100644
index 000000000000..aedc2b49f7c9
--- /dev/null
+++ b/xen/arch/x86/include/asm/domainbuilder.h
@@ -0,0 +1,8 @@
+#ifndef __XEN_X86_DOMBUILDER_H__
+#define __XEN_X86_DOMBUILDER_H__
+
+#include 
+
+void builder_init(struct boot_info *bi);
+
+#endif
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index a61131365477..e1aa9650d22e 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -33,6 +33,7 @@
 #endif
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1285,9 +1286,12 @@ void asmlinkage __init noreturn __start_xen(void)
                bi->nr_modules);
     }
 
-    /* Dom0 kernel is always first */
-    bi->mods[0].type = BOOTMOD_KERNEL;
-    bi->domains[0].kernel = &bi->mods[0];
+    builder_init(bi);
+
+    /* Find first unknown boot module to use as Dom0 kernel */
+    i = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
+    bi->mods[i].type = BOOTMOD_KERNEL;
+    bi->domains[0].kernel = &bi->mods[i];
 
     if ( pvh_boot )
     {
@@ -1470,8 +1474,9 @@ void asmlinkage __init noreturn __start_xen(void)
         xen->size  = __2M_rwdata_end - _stext;
     }
 
-    bi->mods[0].headroom =
-        bzimage_headroom(bootstrap_map_bm(&bi->mods[0]), bi->mods[0].size);
+    bi->domains[0].kernel->headroom =
+        bzimage_headroom(bootstrap_map_bm(bi->domains[0].kernel),
+                         bi->domains[0].kernel->size);
     bootstrap_unmap();
 
 #ifndef highmem_start
@@ -1595,7 +1600,7 @@ void asmlinkage __init noreturn __start_xen(void)
 #endif
     }
 
-    if ( bi->mods[0].headroom && !bi->mods[0].relocated )
+    if ( bi->domains[0].kernel->headroom && !bi->domains[0].kernel->relocated )
         panic("Not enough memory to relocate the dom0 kernel image\n");
     for ( i = 0; i < bi->nr_modules; ++i )
     {
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 26 17:00:30 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Dec 2024 17:00:30 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863282.1274721 (Exim 4.92)
	(envelope-from )
	id 1tQrDq-0006jA-LW; Thu, 26 Dec 2024 17:00:30 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863282.1274721; Thu, 26 Dec 2024 17:00: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 1tQrDq-0006hh-GQ; Thu, 26 Dec 2024 17:00:30 +0000
Received: by outflank-mailman (input) for mailman id 863282;
 Thu, 26 Dec 2024 17:00: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 1tQrDo-0004jO-NU
 for xen-devel@lists.xenproject.org; Thu, 26 Dec 2024 17:00:28 +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 e6b3e858-c3aa-11ef-99a3-01e77a169b0f;
 Thu, 26 Dec 2024 18:00:26 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1735232286454203.59311331231754;
 Thu, 26 Dec 2024 08:58: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: e6b3e858-c3aa-11ef-99a3-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; t=1735232291; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=P90n+tIGktjv3xZShWRRrejWe/HJ6Rq81+5MAzWjf9QaxZjbsE5AKH84oZCodLG8s8iQwi0iN3G/NV47C8QycNZslrDj8VWHbp8TcyHp3ucqO+1xoar4N+glIKcvFus71uKR+DGovv0z2x31FOXpNA7XcTgMseX7v36cW/Xx51s=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1735232291; h=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=ikPFYKTKplN0c3xIGklLy3D15rucauyk9qCtpxMJhbU=; 
	b=hszDpf2JJ7VQsMetB8M3LK4UkCP7rsdCzPhMvW9lH4nmDvXQ8rGVyfwWSBEILOdnDvfOTVlby897VvbkEZuDBjEm2jo9axjKqMSc8WpQ+IMsn2C7Bnjb3cjrH38ehsTvQBIWj/WxIEXaI+ne5BTYpGI/QfjW4fmK3nweO9ekMts=
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=1735232291;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=ikPFYKTKplN0c3xIGklLy3D15rucauyk9qCtpxMJhbU=;
	b=WcLEIFqT/hmgAmgcDIFeNGS7LXsVWtVTuISeySL3HCrzavpdsRatHARQN56uW2Xl
	lMHIEp1in7R+G+R1Yb57fXRaqh+xsSJE63MI3oBalPkkxOEDo5LLKUPtCKgyVwd+RHe
	NPQYWLCXGDUazPgahpK1aoTp21XbqiKcneG61qUo=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	christopher.w.clark@gmail.com,
	stefano.stabellini@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 12/15] x86/hyperlaunch: specify dom0 mode with device tree
Date: Thu, 26 Dec 2024 11:57:37 -0500
Message-Id: <20241226165740.29812-13-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20241226165740.29812-1-dpsmith@apertussolutions.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Enable selecting the mode in which the domain will be built and ran. This
includes:

- whether it will be either a 32/64 bit domain
- if it will be run as a PV or HVM domain
- and if it will require a device model (not applicable for dom0)

In the device tree, this will be represented as a bit map that will be carried
through into struct boot_domain.

Signed-off-by: Daniel P. Smith 
Reviewed-by: Jason Andryuk 
---
Changes since v1:
- switched to nested else if
- dropped ternary op for reporting domain name
- switch to strncmp for the check for mode prop
- drop BUILD_MODE_LONG until PV construction series
---
 xen/arch/x86/domain-builder/fdt.c     | 19 +++++++++++++++++++
 xen/arch/x86/include/asm/bootdomain.h |  5 +++++
 xen/arch/x86/setup.c                  |  3 ++-
 3 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/domain-builder/fdt.c b/xen/arch/x86/domain-builder/fdt.c
index efce0927c645..db584ba78e92 100644
--- a/xen/arch/x86/domain-builder/fdt.c
+++ b/xen/arch/x86/domain-builder/fdt.c
@@ -94,6 +94,25 @@ static int __init process_domain_node(
             bd->domid = (domid_t)val;
             printk("  domid: %d\n", bd->domid);
         }
+        else if ( strncmp(prop_name, "mode", name_len) == 0 )
+        {
+            if ( fdt_prop_as_u32(prop, &bd->mode) != 0 )
+            {
+                printk("  failed processing mode for domain %s\n", name);
+                return -EINVAL;
+            }
+
+            printk("  mode: ");
+            if ( !(bd->mode & BUILD_MODE_PARAVIRT) )
+            {
+                if ( bd->mode & BUILD_MODE_ENABLE_DM )
+                    printk("HVM\n");
+                else
+                    printk("PVH\n");
+            }
+            else
+                printk("PV\n");
+        }
     }
 
     fdt_for_each_subnode(node, fdt, dom_node)
diff --git a/xen/arch/x86/include/asm/bootdomain.h b/xen/arch/x86/include/asm/bootdomain.h
index 101a0c643d74..5918aaf6bb63 100644
--- a/xen/arch/x86/include/asm/bootdomain.h
+++ b/xen/arch/x86/include/asm/bootdomain.h
@@ -15,6 +15,11 @@ struct boot_domain {
 
     domid_t domid;
 
+                                          /* On     | Off    */
+#define BUILD_MODE_PARAVIRT      (1 << 0) /* PV     | PVH/HVM */
+#define BUILD_MODE_ENABLE_DM     (1 << 1) /* HVM    | PVH     */
+    uint32_t mode;
+
     struct boot_module *kernel;
     struct boot_module *ramdisk;
 
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 027b224151d1..a87e122b5a61 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1016,7 +1016,8 @@ static struct domain *__init create_dom0(struct boot_info *bi)
     struct boot_domain *bd = &bi->domains[0];
     struct domain *d;
 
-    if ( opt_dom0_pvh )
+    if ( opt_dom0_pvh ||
+         (bi->hyperlaunch_enabled && !(bd->mode & BUILD_MODE_PARAVIRT)) )
     {
         dom0_cfg.flags |= (XEN_DOMCTL_CDF_hvm |
                            ((hvm_hap_supported() && !opt_dom0_shadow) ?
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 26 17:00:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Dec 2024 17:00:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863289.1274737 (Exim 4.92)
	(envelope-from )
	id 1tQrDy-0007QO-S8; Thu, 26 Dec 2024 17:00:38 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863289.1274737; Thu, 26 Dec 2024 17: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 1tQrDy-0007QH-Ot; Thu, 26 Dec 2024 17:00:38 +0000
Received: by outflank-mailman (input) for mailman id 863289;
 Thu, 26 Dec 2024 17:00: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 1tQrDw-0005x0-Q3
 for xen-devel@lists.xenproject.org; Thu, 26 Dec 2024 17:00:36 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id ec3fc082-c3aa-11ef-a0da-8be0dac302b0;
 Thu, 26 Dec 2024 18:00:36 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1735232287974875.2271421466353;
 Thu, 26 Dec 2024 08:58: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: ec3fc082-c3aa-11ef-a0da-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1735232292; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=lAfxM47CKcNwo4zgMtfQIL0ekyx8y0H3HohdlAJPDAILxbXBPRpE3PTCGlhQzaVaT+i7NisTLOBkKsncLw3pvwmeY0TuZZXw/CamRAK+Wz/vI6P3JWrpVOTddWWfIq+fq16+EMgYaYoxU6HiaN5rifigzy2cwgX0EbsvogqCLm4=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1735232292; h=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=8524a/8T2VisnHlwnmnufZLPjAccP9s5FDSrPRklWJU=; 
	b=grdtl4e00u6mpMKVSsKSXPCRD5OvNa3Cmdz5d3E+ukF5kkKJlkyCxy0+/5gCaM4lNsKHw0QbZSA4Md9pKUCrqHqy/YwFZJMHCPwOvd295RDe+vkDHD7v7aolusBenIuqC3G/jsOFDSgKirLbR8YrjORb1kfn93RZ6BZ3Q+OmM38=
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=1735232292;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=8524a/8T2VisnHlwnmnufZLPjAccP9s5FDSrPRklWJU=;
	b=sM3x+Hf8Y8Y0OT2ykY+7cIpkwCJjMLni+j/bLu1vkYVpiBNCjpd1y/aTuJQESi0P
	mPwXw1/3oP7IAiJipG4RUCa1pBBcMlWBDCjnLUJG/WPYCogZHXLYM2YIMW2NEg676bU
	h2xM5aqWria8jaPJz9MyypPV0pFu0C+zLigp3s4g=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	christopher.w.clark@gmail.com,
	stefano.stabellini@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel 
Subject: [PATCH v2 13/15] x86/hyperlaunch: add memory parsing to domain config
Date: Thu, 26 Dec 2024 11:57:38 -0500
Message-Id: <20241226165740.29812-14-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20241226165740.29812-1-dpsmith@apertussolutions.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Add three properties, memory, mem-min, and mem-max, to the domain node device
tree parsing to define the memory allocation for a domain. All three fields are
expressed in kb and written as a u64 in the device tree entries.

Signed-off-by: Daniel P. Smith 
---
Changes since v1
- moved common fdt parsing to libfdt
- dropped ternary for name selection
- swtich over from match_fdt to strncmp
- change mem prints to kb
---
 xen/arch/x86/dom0_build.c             |  8 +++++++
 xen/arch/x86/domain-builder/fdt.c     | 34 +++++++++++++++++++++++++++
 xen/arch/x86/include/asm/bootdomain.h |  4 ++++
 xen/include/xen/libfdt/libfdt-xen.h   |  9 +++++++
 4 files changed, 55 insertions(+)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index c231191faec7..1c3b7ff0e658 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -609,6 +609,14 @@ int __init construct_dom0(struct boot_domain *bd)
 
     process_pending_softirqs();
 
+    /* If param dom0_size was not set and HL config provided memory size */
+    if ( !get_memsize(&dom0_size, LONG_MAX) && bd->mem_pages )
+        dom0_size.nr_pages = bd->mem_pages;
+    if ( !get_memsize(&dom0_min_size, LONG_MAX) && bd->min_pages )
+        dom0_size.nr_pages = bd->min_pages;
+    if ( !get_memsize(&dom0_max_size, LONG_MAX) && bd->max_pages )
+        dom0_size.nr_pages = bd->max_pages;
+
     if ( is_hvm_domain(d) )
         rc = dom0_construct_pvh(bd);
     else if ( is_pv_domain(d) )
diff --git a/xen/arch/x86/domain-builder/fdt.c b/xen/arch/x86/domain-builder/fdt.c
index db584ba78e92..aff1b8c3235d 100644
--- a/xen/arch/x86/domain-builder/fdt.c
+++ b/xen/arch/x86/domain-builder/fdt.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -113,6 +114,39 @@ static int __init process_domain_node(
             else
                 printk("PV\n");
         }
+        else if ( strncmp(prop_name, "memory", name_len) == 0 )
+        {
+            uint64_t kb;
+            if ( fdt_prop_as_u64(prop, &kb) != 0 )
+            {
+                printk("  failed processing memory for domain %s\n", name);
+                return -EINVAL;
+            }
+            bd->mem_pages = PFN_DOWN(kb * SZ_1K);
+            printk("  memory: %ld kb\n", kb);
+        }
+        else if ( strncmp(prop_name, "mem-min", name_len) == 0 )
+        {
+            uint64_t kb;
+            if ( fdt_prop_as_u64(prop, &kb) != 0 )
+            {
+                printk("  failed processing memory for domain %s\n", name);
+                return -EINVAL;
+            }
+            bd->min_pages = PFN_DOWN(kb * SZ_1K);
+            printk("  min memory: %ld kb\n", kb);
+        }
+        else if ( strncmp(prop_name, "mem-max", name_len) == 0 )
+        {
+            uint64_t kb;
+            if ( fdt_prop_as_u64(prop, &kb) != 0 )
+            {
+                printk("  failed processing memory for domain %s\n", name);
+                return -EINVAL;
+            }
+            bd->max_pages = PFN_DOWN(kb * SZ_1K);
+            printk("  max memory: %ld kb\n", kb);
+        }
     }
 
     fdt_for_each_subnode(node, fdt, dom_node)
diff --git a/xen/arch/x86/include/asm/bootdomain.h b/xen/arch/x86/include/asm/bootdomain.h
index 5918aaf6bb63..d7092bc32ad7 100644
--- a/xen/arch/x86/include/asm/bootdomain.h
+++ b/xen/arch/x86/include/asm/bootdomain.h
@@ -20,6 +20,10 @@ struct boot_domain {
 #define BUILD_MODE_ENABLE_DM     (1 << 1) /* HVM    | PVH     */
     uint32_t mode;
 
+    unsigned long mem_pages;
+    unsigned long min_pages;
+    unsigned long max_pages;
+
     struct boot_module *kernel;
     struct boot_module *ramdisk;
 
diff --git a/xen/include/xen/libfdt/libfdt-xen.h b/xen/include/xen/libfdt/libfdt-xen.h
index 2057030dda45..3b653e626842 100644
--- a/xen/include/xen/libfdt/libfdt-xen.h
+++ b/xen/include/xen/libfdt/libfdt-xen.h
@@ -37,6 +37,15 @@ static inline int __init fdt_prop_as_u32(
     return fdt_cell_as_u32((fdt32_t *)prop->data, val);
 }
 
+static inline int __init fdt_prop_as_u64(
+    const struct fdt_property *prop, uint64_t *val)
+{
+    if ( !prop || fdt32_to_cpu(prop->len) < sizeof(u64) )
+        return -EINVAL;
+
+    return fdt_cell_as_u64((fdt32_t *)prop->data, val);
+}
+
 static inline int __init fdt_get_prop_by_offset(
     const void *fdt, int node, const char *name, unsigned long *offset)
 {
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 26 17:00:42 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Dec 2024 17:00:42 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863299.1274747 (Exim 4.92)
	(envelope-from )
	id 1tQrE2-0007yy-4F; Thu, 26 Dec 2024 17:00:42 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863299.1274747; Thu, 26 Dec 2024 17:00: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 1tQrE2-0007yp-0L; Thu, 26 Dec 2024 17:00:42 +0000
Received: by outflank-mailman (input) for mailman id 863299;
 Thu, 26 Dec 2024 17:00: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 1tQrCo-00026T-NR
 for xen-devel@lists.xenproject.org; Thu, 26 Dec 2024 16:59:26 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id c281d457-c3aa-11ef-a0da-8be0dac302b0;
 Thu, 26 Dec 2024 17:59:26 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1735232282410325.37290437121055;
 Thu, 26 Dec 2024 08:58: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: c281d457-c3aa-11ef-a0da-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1735232286; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=RhWPoK4NIZjG4E6p6yzvJNhXjnhRAFyLWbXD1p759QmS2lQ4o+8HKYWJ+A0KaW3xHq1y6I4hpvEvH+uNpoa0e0Dp8TjGJByXcixe6KF4rWpaM7Yhj8DlO/M5vUWzfks/YwG43Jd9cnUXFVDYf3HL5UTBks7KFBJuEhHpM1ItkhY=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1735232286; h=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=52qJQbf7jF223erY8P2R8ITOq6qxtcd4OGVYfyMQ2rc=; 
	b=GncS5m+hbU/SzMPAasNByTvqrnpV4itEGqfvBJhsgOkofnxJYL2kPb+i9wXtMeOmZOAn22oPJ2SJULTJ+oJNhBEIBqq5kW9W3DNFQs3amjRgDsXDw8198CLrliKId+I7iSvBbDgqjBKHkcg0bnpT9SJnj0JKhlRimWMS8ZwUc/c=
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=1735232286;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=52qJQbf7jF223erY8P2R8ITOq6qxtcd4OGVYfyMQ2rc=;
	b=lOE1cm+9M1fTjj2O6PTdvk0lnczYdaSKhativ/JPZ9g4EBEOUCfBOSNu2SY3IaPK
	rxsWqwxkbhqDXuTAQJ8goejj0AOAbVlJjZPoGXuLJ6KdufWig6aA7LtSdQoIvxyXuW7
	zjI5bYOIZWq4tVO1TNK4ajz7lWQOyBeOUjadQe0c=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	christopher.w.clark@gmail.com,
	stefano.stabellini@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel 
Subject: [PATCH v2 09/15] x86/hyperlaunch: obtain cmdline from device tree
Date: Thu, 26 Dec 2024 11:57:34 -0500
Message-Id: <20241226165740.29812-10-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20241226165740.29812-1-dpsmith@apertussolutions.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

If a command line is not provided through the bootloader's mechanism, e.g.
muiltboot module string field, then use one from the device tree if present.
The device tree command line is located in the bootargs property of the
`multiboot,kernel` node.

Signed-off-by: Daniel P. Smith 
Reviewed-by: Jason Andryuk 
---
Changes since v1:
- moved common fdt functions to libfdt
- rename prop_as_offset to more correct prop_by_offset
---
 xen/arch/x86/domain-builder/core.c       | 28 ++++++++++++++++++++++++
 xen/arch/x86/domain-builder/fdt.c        | 10 +++++++++
 xen/arch/x86/domain-builder/fdt.h        | 24 ++++++++++++++++++++
 xen/arch/x86/include/asm/bootinfo.h      |  6 +++--
 xen/arch/x86/include/asm/domainbuilder.h |  4 ++++
 xen/arch/x86/setup.c                     | 15 +++++++++----
 xen/include/xen/libfdt/libfdt-xen.h      | 24 ++++++++++++++++++++
 7 files changed, 105 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/domain-builder/core.c b/xen/arch/x86/domain-builder/core.c
index eda7fa7a8ffa..91d1b7367e76 100644
--- a/xen/arch/x86/domain-builder/core.c
+++ b/xen/arch/x86/domain-builder/core.c
@@ -8,9 +8,37 @@
 #include 
 
 #include 
+#include 
 
 #include "fdt.h"
 
+size_t __init builder_get_cmdline_size(struct boot_info *bi, int offset)
+{
+#ifdef CONFIG_DOMAIN_BUILDER
+    const void *fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);
+    int size = fdt_cmdline_prop_size(fdt, offset);
+
+    bootstrap_unmap();
+    return size < 0 ? 0 : (size_t) size;
+#else
+    return 0;
+#endif
+}
+
+int __init builder_get_cmdline(
+    struct boot_info *bi, int offset, char *cmdline, size_t size)
+{
+#ifdef CONFIG_DOMAIN_BUILDER
+    const void *fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);
+    int ret = fdt_cmdline_prop_copy(fdt, offset, cmdline, size);
+
+    bootstrap_unmap();
+    return ret;
+#else
+    return 0;
+#endif
+}
+
 void __init builder_init(struct boot_info *bi)
 {
     if ( IS_ENABLED(CONFIG_DOMAIN_BUILDER) )
diff --git a/xen/arch/x86/domain-builder/fdt.c b/xen/arch/x86/domain-builder/fdt.c
index bcaee50689a6..1094c8dc8838 100644
--- a/xen/arch/x86/domain-builder/fdt.c
+++ b/xen/arch/x86/domain-builder/fdt.c
@@ -109,6 +109,16 @@ static int __init process_domain_node(
             printk("  kernel: boot module %d\n", idx);
             bi->mods[idx].type = BOOTMOD_KERNEL;
             bd->kernel = &bi->mods[idx];
+
+            /* If bootloader didn't set cmdline, see if FDT provides one. */
+            if ( bd->kernel->cmdline_pa &&
+                 !((char *)__va(bd->kernel->cmdline_pa))[0] )
+            {
+                int ret = fdt_get_prop_by_offset(
+                    fdt, node, "bootargs", &bd->kernel->cmdline_pa);
+                if ( ret > 0 )
+                    bd->kernel->fdt_cmdline = true;
+            }
         }
     }
 
diff --git a/xen/arch/x86/domain-builder/fdt.h b/xen/arch/x86/domain-builder/fdt.h
index 0be4ac771bc4..3938b0d2619b 100644
--- a/xen/arch/x86/domain-builder/fdt.h
+++ b/xen/arch/x86/domain-builder/fdt.h
@@ -13,6 +13,30 @@
 
 #ifdef CONFIG_DOMAIN_BUILDER
 
+static inline int __init fdt_cmdline_prop_size(const void *fdt, int offset)
+{
+    int ret;
+
+    fdt_get_property_by_offset(fdt, offset, &ret);
+
+    return ret;
+}
+
+static inline int __init fdt_cmdline_prop_copy(
+    const void *fdt, int offset, char *cmdline, size_t size)
+{
+    int ret;
+    const struct fdt_property *prop =
+        fdt_get_property_by_offset(fdt, offset, &ret);
+
+    if ( ret < 0 )
+        return ret;
+
+    ASSERT(size > ret);
+
+    return strlcpy(cmdline, prop->data, ret);
+}
+
 int has_hyperlaunch_fdt(struct boot_info *bi);
 int walk_hyperlaunch_fdt(struct boot_info *bi);
 #else
diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index 683ca9dbe2e0..433a0e66121b 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -35,11 +35,13 @@ struct boot_module {
 
     /*
      * Module State Flags:
-     *   relocated: indicates module has been relocated in memory.
-     *   released:  indicates module's pages have been freed.
+     *   relocated:   indicates module has been relocated in memory.
+     *   released:    indicates module's pages have been freed.
+     *   fdt_cmdline: indicates module's cmdline is in the FDT.
      */
     bool relocated:1;
     bool released:1;
+    bool fdt_cmdline:1;
 
     /*
      * A boot module may need decompressing by Xen.  Headroom is an estimate of
diff --git a/xen/arch/x86/include/asm/domainbuilder.h b/xen/arch/x86/include/asm/domainbuilder.h
index aedc2b49f7c9..21221d8df8ec 100644
--- a/xen/arch/x86/include/asm/domainbuilder.h
+++ b/xen/arch/x86/include/asm/domainbuilder.h
@@ -3,6 +3,10 @@
 
 #include 
 
+size_t __init builder_get_cmdline_size(struct boot_info *bi, int offset);
+int __init builder_get_cmdline(
+    struct boot_info *bi, int offset, char *cmdline, size_t size);
+
 void builder_init(struct boot_info *bi);
 
 #endif
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 71ce9315d3ac..3dd04b9afca7 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -981,7 +981,10 @@ static size_t __init domain_cmdline_size(
 {
     size_t s = bi->kextra ? strlen(bi->kextra) : 0;
 
-    s += bd->kernel->cmdline_pa ? strlen(__va(bd->kernel->cmdline_pa)) : 0;
+    if ( bd->kernel->fdt_cmdline )
+        s += builder_get_cmdline_size(bi, bd->kernel->cmdline_pa);
+    else
+        s += strlen(__va(bd->kernel->cmdline_pa));
 
     if ( s == 0 )
         return s;
@@ -1039,7 +1042,8 @@ static struct domain *__init create_dom0(struct boot_info *bi)
 
     /* Grab the DOM0 command line. */
     if ( (bd->kernel->cmdline_pa &&
-          ((char *)__va(bd->kernel->cmdline_pa))[0]) ||
+          (bd->kernel->fdt_cmdline ||
+           ((char *)__va(bd->kernel->cmdline_pa))[0])) ||
          bi->kextra )
     {
         size_t cmdline_size = domain_cmdline_size(bi, bd);
@@ -1049,9 +1053,12 @@ static struct domain *__init create_dom0(struct boot_info *bi)
             if ( !(cmdline = xzalloc_array(char, cmdline_size)) )
                 panic("Error allocating cmdline buffer for %pd\n", d);
 
-            if ( bd->kernel->cmdline_pa )
+            if ( bd->kernel->fdt_cmdline )
+                builder_get_cmdline(
+                    bi, bd->kernel->cmdline_pa, cmdline, cmdline_size);
+            else
                 strlcpy(cmdline,
-                        cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader),
+                        cmdline_cook(__va(bd->kernel->cmdline_pa),bi->loader),
                         cmdline_size);
 
             if ( bi->kextra )
diff --git a/xen/include/xen/libfdt/libfdt-xen.h b/xen/include/xen/libfdt/libfdt-xen.h
index 27d23df03af3..0e54aeeb6cc2 100644
--- a/xen/include/xen/libfdt/libfdt-xen.h
+++ b/xen/include/xen/libfdt/libfdt-xen.h
@@ -28,6 +28,30 @@ static inline int __init fdt_cell_as_u64(const fdt32_t *cell, uint64_t *val)
     return 0;
 }
 
+static inline int __init fdt_get_prop_by_offset(
+    const void *fdt, int node, const char *name, unsigned long *offset)
+{
+    int ret, poffset;
+    const char *pname;
+    size_t nsize = strlen(name);
+
+    fdt_for_each_property_offset(poffset, fdt, node)
+    {
+        fdt_getprop_by_offset(fdt, poffset, &pname, &ret);
+
+        if ( ret < 0 || strlen(pname) != nsize )
+            continue;
+
+        if ( !strncmp(pname, name, nsize) )
+        {
+            *offset = poffset;
+            return nsize;
+        }
+    }
+
+    return -ENOENT;
+}
+
 /*
  * Property: reg
  *
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 26 17:00:43 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Dec 2024 17:00:43 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863304.1274757 (Exim 4.92)
	(envelope-from )
	id 1tQrE3-0008LL-IU; Thu, 26 Dec 2024 17:00:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863304.1274757; Thu, 26 Dec 2024 17:00: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 1tQrE3-0008Kj-Et; Thu, 26 Dec 2024 17:00:43 +0000
Received: by outflank-mailman (input) for mailman id 863304;
 Thu, 26 Dec 2024 17:00: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 1tQrCP-00026T-KG
 for xen-devel@lists.xenproject.org; Thu, 26 Dec 2024 16:59:01 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b37db99d-c3aa-11ef-a0da-8be0dac302b0;
 Thu, 26 Dec 2024 17:59:00 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1735232279134554.1038478858385;
 Thu, 26 Dec 2024 08:57: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: b37db99d-c3aa-11ef-a0da-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1735232282; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=fhGuED3b+9JwfOn7hRYVcnYzUL01IFndlyCMN2Wxeo93W7iny9sMxjpM2R/YqL/m2OJRaFFWTYqCenY3p0FIKPQOxPg5cPFRvP5k8pCQVEHPUb+VR7bqJKaNI9S+gibLnmaTIs86xbuFMbhVb82C+T6zcGSyvYrCye+Uzghd/XU=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1735232282; h=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=l+K1+PF6tYPPI/bcF6jnw9iyso5PFiGOwV6wSVyGzFo=; 
	b=GyELEK1whqY5u+kDlK3kz6yhxnwgvd9zJeybyCNvf3HL8VZ8qElJHm3GWl9rHoMyl0+lsdNVOCV20xMPbPhCU2AqJcbXAk4FCDglzF3ht/jwO0Xti7VJ209MWQw0Wyqf8M8/88A7lygbPXPeqVjD7LCWJ8b9MPf9VW9dzDKhaqI=
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=1735232282;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=l+K1+PF6tYPPI/bcF6jnw9iyso5PFiGOwV6wSVyGzFo=;
	b=aF7r3pBsYUANy8qnqymROiM6burn8IsJCAIud6gNabC5tcOo3GvzY9QvaYPvRY/Z
	r+ZY0/5Uce4q7aXxVBkfprvICfANYeVGzUWPk7XpZyL8N6rQ25GgE2ReRnZ+rZNSIOa
	GxYfrE0PtzyDazkufBdwE/aFMpaVYbt0mGfTkEXc=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	christopher.w.clark@gmail.com,
	stefano.stabellini@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 07/15] x86/hyperlaunch: initial support for hyperlaunch device tree
Date: Thu, 26 Dec 2024 11:57:32 -0500
Message-Id: <20241226165740.29812-8-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20241226165740.29812-1-dpsmith@apertussolutions.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Add the ability to detect both a formal hyperlaunch device tree or a dom0less
device tree. If the hyperlaunch device tree is found, then count the number of
domain entries, reporting an error if more than one is found.

Signed-off-by: Daniel P. Smith 
---
Changes since v1:
- corrected typo in error message
- clarified commit message on "reporting"
- added missing inline decl
- code style
---
 xen/arch/x86/domain-builder/core.c  | 15 +++++++
 xen/arch/x86/domain-builder/fdt.c   | 65 ++++++++++++++++++++++++++++-
 xen/arch/x86/domain-builder/fdt.h   |  5 +++
 xen/arch/x86/include/asm/bootinfo.h |  1 +
 4 files changed, 85 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/domain-builder/core.c b/xen/arch/x86/domain-builder/core.c
index d6ae94f45c72..c50eff34fb68 100644
--- a/xen/arch/x86/domain-builder/core.c
+++ b/xen/arch/x86/domain-builder/core.c
@@ -44,6 +44,21 @@ void __init builder_init(struct boot_info *bi)
             break;
         }
     }
+
+    if ( bi->hyperlaunch_enabled )
+    {
+        int ret;
+
+        printk(XENLOG_INFO "Hyperlaunch configuration:\n");
+        if ( (ret = walk_hyperlaunch_fdt(bi)) < 0 )
+        {
+            printk(XENLOG_INFO "  walk of device tree failed (%d)\n", ret);
+            bi->hyperlaunch_enabled = false;
+            return;
+        }
+
+        printk(XENLOG_INFO "  Number of domains: %d\n", bi->nr_domains);
+    }
 }
 
 /*
diff --git a/xen/arch/x86/domain-builder/fdt.c b/xen/arch/x86/domain-builder/fdt.c
index 4a3f80648f86..5793bdc9fd47 100644
--- a/xen/arch/x86/domain-builder/fdt.c
+++ b/xen/arch/x86/domain-builder/fdt.c
@@ -13,14 +13,77 @@
 
 #include "fdt.h"
 
+static int __init find_hyperlaunch_node(const void *fdt)
+{
+    int hv_node = fdt_path_offset(fdt, "/chosen/hypervisor");
+
+    if ( hv_node >= 0 )
+    {
+        /* Anything other than zero indicates no match */
+        if ( fdt_node_check_compatible(fdt, hv_node, "hypervisor,xen") )
+            return -ENODATA;
+        else
+            return hv_node;
+    }
+    else
+    {
+        /* Lood for dom0less config */
+        int node, chosen_node = fdt_path_offset(fdt, "/chosen");
+        if ( chosen_node < 0 )
+            return -ENOENT;
+
+        fdt_for_each_subnode(node, fdt, chosen_node)
+        {
+            if ( fdt_node_check_compatible(fdt, node, "xen,domain") == 0 )
+                return chosen_node;
+        }
+    }
+
+    return -ENODATA;
+}
+
 int __init has_hyperlaunch_fdt(struct boot_info *bi)
 {
     int ret = 0;
     const void *fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);
 
-    if ( fdt_check_header(fdt) < 0 )
+    if ( !fdt || fdt_check_header(fdt) < 0 )
         ret = -EINVAL;
+    else
+        ret = find_hyperlaunch_node(fdt);
+
+    bootstrap_unmap();
+
+    return ret < 0 ? ret : 0;
+}
+
+int __init walk_hyperlaunch_fdt(struct boot_info *bi)
+{
+    int ret = 0, hv_node, node;
+    void *fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);
+
+    if ( unlikely(!fdt) )
+        return -EINVAL;
+
+    hv_node = find_hyperlaunch_node(fdt);
+    if ( hv_node < 0 )
+    {
+        ret = hv_node;
+        goto err_out;
+    }
+
+    fdt_for_each_subnode(node, fdt, hv_node)
+    {
+        ret = fdt_node_check_compatible(fdt, node, "xen,domain");
+        if ( ret == 0 )
+            bi->nr_domains++;
+    }
+
+    /* Until multi-domain construction is added, throw an error */
+    if ( !bi->nr_domains || bi->nr_domains > 1 )
+        printk(XENLOG_ERR "Hyperlaunch only supports dom0 construction\n");
 
+ err_out:
     bootstrap_unmap();
 
     return ret;
diff --git a/xen/arch/x86/domain-builder/fdt.h b/xen/arch/x86/domain-builder/fdt.h
index 1c1569a9c633..f5b89cb54b29 100644
--- a/xen/arch/x86/domain-builder/fdt.h
+++ b/xen/arch/x86/domain-builder/fdt.h
@@ -11,11 +11,16 @@
 
 #ifdef CONFIG_DOMAIN_BUILDER
 int has_hyperlaunch_fdt(struct boot_info *bi);
+int walk_hyperlaunch_fdt(struct boot_info *bi);
 #else
 static inline int __init has_hyperlaunch_fdt(struct boot_info *bi)
 {
     return -EINVAL;
 }
+static inline int __init walk_hyperlaunch_fdt(struct boot_info *bi)
+{
+    return -EINVAL;
+}
 #endif
 
 #endif /* __XEN_X86_FDT_H__ */
diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index 208bec90913d..683ca9dbe2e0 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -84,6 +84,7 @@ struct boot_info {
     bool hyperlaunch_enabled;
 
     unsigned int nr_modules;
+    unsigned int nr_domains;
     struct boot_module mods[MAX_NR_BOOTMODS + 1];
     struct boot_domain domains[MAX_NR_BOOTDOMS];
 };
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 26 17:00:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Dec 2024 17:00:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863305.1274762 (Exim 4.92)
	(envelope-from )
	id 1tQrE3-0008Pl-Uq; Thu, 26 Dec 2024 17:00:43 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863305.1274762; Thu, 26 Dec 2024 17:00: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 1tQrE3-0008O1-Ll; Thu, 26 Dec 2024 17:00:43 +0000
Received: by outflank-mailman (input) for mailman id 863305;
 Thu, 26 Dec 2024 17:00: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 1tQrCY-00026T-1D
 for xen-devel@lists.xenproject.org; Thu, 26 Dec 2024 16:59:10 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id b8856058-c3aa-11ef-a0da-8be0dac302b0;
 Thu, 26 Dec 2024 17:59:09 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1735232280794596.6459264057604;
 Thu, 26 Dec 2024 08:58: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: b8856058-c3aa-11ef-a0da-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1735232284; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=fNRrtQrI4DnLHPrEcf1U+eHVnfStHjVP44ovOqBH2sOpYuVnxB8iH8lGKPeahmO8iIq8bM9aXmWgLjfFfD2zCcqfdgTyjYJgSTTduZg+ZcAQS4YOSMXT3fxmRHkGik4DqT6+cWchfzFlp7OalGlC4O7MB2RtoznH1d/VOEbnj3M=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1735232284; h=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=mhot9LKP2slvPRYXK9WmRlmz+pSAHze4P+sLwHMCIo4=; 
	b=PiygxbmYUe/JmcDlQnBi6Veoy/MMasnF1vd85GYDBtVA3VAMIcbDNVR2jERNEIl7wVDWEs3m8ehuaLpbsK+FT4rCNPYtmH/y1A9rgiUScGEXAYpjbCb+zAu8d/gTNrydsm0V5qZha8K3TtALflXNkZFUttagnt9PxXcN1hei+mM=
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=1735232284;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=mhot9LKP2slvPRYXK9WmRlmz+pSAHze4P+sLwHMCIo4=;
	b=HJF5SrIgBMp8tPpth61zvRqaU+pZ4DjCS2NMyovsHNXnL+qoP3lNyGPQMbQ3oNvS
	UP+9ut71tRtTqU6Ow8B9/F1nMGXQSSLRT33mTaZykIuih2y5ebCRwrbRyGiOW47pxTI
	YsWURxWrjFd/NRbhfR9DmpkGeKQIKp16sHbQI+cs=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	christopher.w.clark@gmail.com,
	stefano.stabellini@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel 
Subject: [PATCH v2 08/15] x86/hyperlaunch: locate dom0 kernel with hyperlaunch
Date: Thu, 26 Dec 2024 11:57:33 -0500
Message-Id: <20241226165740.29812-9-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20241226165740.29812-1-dpsmith@apertussolutions.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Look for a subnode of type `multiboot,kernel` within a domain node. If found,
process the reg property for the MB1 module index. If the bootargs property is
present and there was not an MB1 string, then use the command line from the
device tree definition.

Signed-off-by: Daniel P. Smith 
Reviewed-by: Jason Andryuk 
---
Changes since v1:
- moved low-level fdt handlers to libfdt-xen.h
- coding style changes
- moved default to "unknown" up to a local declaration
- moved the general fdt parsing code out to libfdt
- reworked device tree property parsing for module index
  - reworked parsers to take index as parameter
  - parsers now return success or error value
- added check if kernel was already located, warn and continue
---
 xen/arch/x86/domain-builder/core.c  |  11 +++
 xen/arch/x86/domain-builder/fdt.c   | 118 ++++++++++++++++++++++++++++
 xen/arch/x86/domain-builder/fdt.h   |   3 +
 xen/arch/x86/setup.c                |   5 --
 xen/include/xen/libfdt/libfdt-xen.h |  76 ++++++++++++++++++
 5 files changed, 208 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/domain-builder/core.c b/xen/arch/x86/domain-builder/core.c
index c50eff34fb68..eda7fa7a8ffa 100644
--- a/xen/arch/x86/domain-builder/core.c
+++ b/xen/arch/x86/domain-builder/core.c
@@ -59,6 +59,17 @@ void __init builder_init(struct boot_info *bi)
 
         printk(XENLOG_INFO "  Number of domains: %d\n", bi->nr_domains);
     }
+    else
+    {
+        unsigned int i;
+
+        /* Find first unknown boot module to use as Dom0 kernel */
+        printk("Falling back to using first boot module as dom0\n");
+        i = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
+        bi->mods[i].type = BOOTMOD_KERNEL;
+        bi->domains[0].kernel = &bi->mods[i];
+        bi->nr_domains = 1;
+    }
 }
 
 /*
diff --git a/xen/arch/x86/domain-builder/fdt.c b/xen/arch/x86/domain-builder/fdt.c
index 5793bdc9fd47..bcaee50689a6 100644
--- a/xen/arch/x86/domain-builder/fdt.c
+++ b/xen/arch/x86/domain-builder/fdt.c
@@ -13,6 +13,114 @@
 
 #include "fdt.h"
 
+static int __init hl_module_index(void *fdt, int node, uint32_t *idx)
+{
+    int ret = 0;
+    const struct fdt_property *prop =
+        fdt_get_property(fdt, node, "module-index", &ret);
+
+    /* FDT error or bad idx pointer, translate to -EINVAL */
+    if ( ret < 0 || idx == NULL )
+        return -EINVAL;
+
+    fdt_cell_as_u32((fdt32_t *)prop->data, idx);
+
+    if ( *idx > MAX_NR_BOOTMODS )
+        return -ERANGE;
+
+    return 0;
+}
+
+static int __init dom0less_module_index(
+    void *fdt, int node, int size_size, int address_size, uint32_t *idx)
+{
+    uint64_t size = ~0UL, addr = ~0UL;
+    int ret =
+        fdt_get_reg_prop(fdt, node, address_size, size_size, &addr, &size, 1);
+
+    /* FDT error or bad idx pointer, translate to -EINVAL */
+    if ( ret < 0 || idx == NULL )
+        return -EINVAL;
+
+    /* Convention is that zero size indicates address is an index */
+    if ( size != 0 )
+        return -EOPNOTSUPP;
+
+    if ( addr > MAX_NR_BOOTMODS )
+        return -ERANGE;
+
+    /*
+     * MAX_NR_BOOTMODS cannot exceed the max for MB1, represented by a u32,
+     * thus the cast down to a u32 will be safe due to the prior check.
+     */
+    *idx = (uint32_t)addr;
+
+    return 0;
+}
+
+static int __init process_domain_node(
+    struct boot_info *bi, void *fdt, int dom_node)
+{
+    int node;
+    struct boot_domain *bd = &bi->domains[bi->nr_domains];
+    const char *name = fdt_get_name(fdt, dom_node, NULL) ?: "unknown";
+
+    fdt_for_each_subnode(node, fdt, dom_node)
+    {
+        if ( fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
+        {
+            unsigned int idx;
+            int ret = 0;
+
+            if ( bd->kernel )
+            {
+                printk(XENLOG_ERR "Duplicate kernel module for domain %s)\n",
+                       name);
+                continue;
+            }
+
+            /* Try hyperlaunch property, fall back to dom0less property. */
+            if ( hl_module_index(fdt, node, &idx) < 0 )
+            {
+                int address_size = fdt_address_cells(fdt, dom_node);
+                int size_size = fdt_size_cells(fdt, dom_node);
+
+                if ( address_size < 0 || size_size < 0 )
+                    ret = -EINVAL;
+                else
+                    ret = dom0less_module_index(
+                            fdt, node, size_size, address_size, &idx);
+            }
+
+            if ( ret < 0 )
+            {
+                printk("  failed processing kernel module for domain %s)\n",
+                       name);
+                return ret;
+            }
+
+            if ( idx > bi->nr_modules )
+            {
+                printk("  invalid kernel module index for domain node (%d)\n",
+                       bi->nr_domains);
+                return -EINVAL;
+            }
+
+            printk("  kernel: boot module %d\n", idx);
+            bi->mods[idx].type = BOOTMOD_KERNEL;
+            bd->kernel = &bi->mods[idx];
+        }
+    }
+
+    if ( !bd->kernel )
+    {
+        printk(XENLOG_ERR "ERR: no kernel assigned to domain\n");
+        return -EFAULT;
+    }
+
+    return 0;
+}
+
 static int __init find_hyperlaunch_node(const void *fdt)
 {
     int hv_node = fdt_path_offset(fdt, "/chosen/hypervisor");
@@ -74,9 +182,19 @@ int __init walk_hyperlaunch_fdt(struct boot_info *bi)
 
     fdt_for_each_subnode(node, fdt, hv_node)
     {
+        if ( bi->nr_domains >= MAX_NR_BOOTDOMS )
+        {
+            printk(XENLOG_WARNING "WARN: more domains defined than max allowed");
+            break;
+        }
+
         ret = fdt_node_check_compatible(fdt, node, "xen,domain");
         if ( ret == 0 )
+        {
+            if ( (ret = process_domain_node(bi, fdt, node)) < 0 )
+                break;
             bi->nr_domains++;
+        }
     }
 
     /* Until multi-domain construction is added, throw an error */
diff --git a/xen/arch/x86/domain-builder/fdt.h b/xen/arch/x86/domain-builder/fdt.h
index f5b89cb54b29..0be4ac771bc4 100644
--- a/xen/arch/x86/domain-builder/fdt.h
+++ b/xen/arch/x86/domain-builder/fdt.h
@@ -3,6 +3,8 @@
 #define __XEN_X86_FDT_H__
 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -10,6 +12,7 @@
 #define HYPERLAUNCH_MODULE_IDX 0
 
 #ifdef CONFIG_DOMAIN_BUILDER
+
 int has_hyperlaunch_fdt(struct boot_info *bi);
 int walk_hyperlaunch_fdt(struct boot_info *bi);
 #else
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index e1aa9650d22e..71ce9315d3ac 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1288,11 +1288,6 @@ void asmlinkage __init noreturn __start_xen(void)
 
     builder_init(bi);
 
-    /* Find first unknown boot module to use as Dom0 kernel */
-    i = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
-    bi->mods[i].type = BOOTMOD_KERNEL;
-    bi->domains[0].kernel = &bi->mods[i];
-
     if ( pvh_boot )
     {
         /* pvh_init() already filled in e820_raw */
diff --git a/xen/include/xen/libfdt/libfdt-xen.h b/xen/include/xen/libfdt/libfdt-xen.h
index a5340bc9f4e1..27d23df03af3 100644
--- a/xen/include/xen/libfdt/libfdt-xen.h
+++ b/xen/include/xen/libfdt/libfdt-xen.h
@@ -13,6 +13,82 @@
 
 #include 
 
+static inline int __init fdt_cell_as_u32(const fdt32_t *cell, uint32_t *val)
+{
+    *val = fdt32_to_cpu(*cell);
+
+    return 0;
+}
+
+static inline int __init fdt_cell_as_u64(const fdt32_t *cell, uint64_t *val)
+{
+    *val = ((uint64_t)fdt32_to_cpu(cell[0]) << 32) |
+           (uint64_t)fdt32_to_cpu(cell[1]);
+
+    return 0;
+}
+
+/*
+ * Property: reg
+ *
+ * Defined in Section 2.3.6 of the Device Tree Specification is the "reg"
+ * standard property. The property is a prop-encoded-array that is encoded as
+ * an arbitrary number of (address, length) pairs.
+ */
+static inline int __init fdt_get_reg_prop(
+    const void *fdt, int node, unsigned int asize, unsigned int ssize,
+    uint64_t *addr, uint64_t *size, unsigned int pairs)
+{
+    int ret;
+    unsigned int i, count;
+    const struct fdt_property *prop;
+    fdt32_t *cell;
+
+    /* FDT spec max size is 4 (128bit int), but largest arch int size is 64 */
+    if ( ssize > 2 || asize > 2 )
+        return -EINVAL;
+
+    prop = fdt_get_property(fdt, node, "reg", &ret);
+    if ( !prop || ret < sizeof(u32) )
+        return ret < 0 ? ret : -EINVAL;
+
+    /* Get the number of (addr, size) pairs and clamp down. */
+    count = fdt32_to_cpu(prop->len) / (ssize + asize);
+    count = count < pairs ? count : pairs;
+
+    cell = (fdt32_t *)prop->data;
+
+    for ( i = 0; i < count; i++ )
+    {
+        /* read address field */
+        if ( asize == 1 )
+        {
+            uint32_t val;
+            fdt_cell_as_u32(cell, &val);
+            addr[i] = val;
+        }
+        else
+            fdt_cell_as_u64(cell, &addr[i]);
+
+        /* read size field */
+        cell += asize;
+
+        if ( ssize == 1 )
+        {
+            uint32_t val;
+            fdt_cell_as_u32(cell, &val);
+            size[i] = val;
+        }
+        else
+            fdt_cell_as_u64(cell, &size[i]);
+
+        /* move to next pair */
+        cell += ssize;
+    }
+
+    return count;
+}
+
 static inline int fdt_get_mem_rsv_paddr(const void *fdt, int n,
                                         paddr_t *address,
                                         paddr_t *size)
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 26 17:00:45 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Dec 2024 17:00:45 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863307.1274775 (Exim 4.92)
	(envelope-from )
	id 1tQrE5-0000PY-4P; Thu, 26 Dec 2024 17:00:45 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863307.1274775; Thu, 26 Dec 2024 17:00: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 1tQrE4-0000OY-VL; Thu, 26 Dec 2024 17:00:44 +0000
Received: by outflank-mailman (input) for mailman id 863307;
 Thu, 26 Dec 2024 17:00: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 1tQrC9-00026T-2O
 for xen-devel@lists.xenproject.org; Thu, 26 Dec 2024 16:58:45 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id a9a917e4-c3aa-11ef-a0da-8be0dac302b0;
 Thu, 26 Dec 2024 17:58:44 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1735232276554498.6175530673062;
 Thu, 26 Dec 2024 08:57:56 -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: a9a917e4-c3aa-11ef-a0da-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1735232279; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=M7NNEHXQn2ArpWBIQxAC0ps93lMWSHGq5oSivwW0+R8gPtzYljK8+60SNKgxIKx8oWgAWsfNozgdVR/REUWoUcYBehp1Jl2TESlPzKnNJqDUl0mUgjrAD0NWL4XZvjv+tvbSFBJ19YFMyeq6fZxI8vIDtaFGZ1tkCDOGUqgdBxw=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1735232279; h=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=8yEFyhV1XLn4s2lQSWFXirGDySzcrcFW20gpc2BTrdE=; 
	b=Sjo7UcOJjZCiCDH7mVrwEr+aYJHgxVvMmktXLANiKegNebDK20xolGaiAvPan6+BOQk/KxLQaPPfWEIaAsXAdenkrD0ZBU3+t9jz7wzc9YEHZm88YKXsvGwAGkufLNcaYCshUHIIs2RS7gTuZfR3M4rOPhEK1gOqpbScs2f4j9Y=
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=1735232279;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=8yEFyhV1XLn4s2lQSWFXirGDySzcrcFW20gpc2BTrdE=;
	b=EuxeSErU3fDeUZdkR7CTZ02vOLwuQf8rDS1fVGLmwmfiqgwUGIyGWEENBxSz2PUQ
	QSacve/gwL+VOnH/lbV8gaSkVG2+JrADznjiDHodOejSoJ1RQHx03BTsONA5zVOcXPt
	AkhX9UDFEf0eY/liexwx7UDxTknbqoEii17s1mLQ=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	christopher.w.clark@gmail.com,
	stefano.stabellini@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 05/15] kconfig: introduce domain builder config option
Date: Thu, 26 Dec 2024 11:57:30 -0500
Message-Id: <20241226165740.29812-6-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20241226165740.29812-1-dpsmith@apertussolutions.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Hyperlaunch domain builder will be the consolidated boot time domain building
logic framework. Introduces the config option to enable this domain builder to
and turn on the ability to load the domain configuration via a flattened device
tree.

Signed-off-by: Daniel P. Smith 
---
Changes since v1:
- fixed Kconfig indentation
- change directory name to use - instead of _
---
 xen/arch/x86/Kconfig                |  2 ++
 xen/arch/x86/domain-builder/Kconfig | 15 +++++++++++++++
 2 files changed, 17 insertions(+)
 create mode 100644 xen/arch/x86/domain-builder/Kconfig

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 9cdd04721afa..25b9b75423c5 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -383,6 +383,8 @@ config ALTP2M
 
 	  If unsure, stay with defaults.
 
+source "arch/x86/domain_builder/Kconfig"
+
 endmenu
 
 source "common/Kconfig"
diff --git a/xen/arch/x86/domain-builder/Kconfig b/xen/arch/x86/domain-builder/Kconfig
new file mode 100644
index 000000000000..8ed493c3b545
--- /dev/null
+++ b/xen/arch/x86/domain-builder/Kconfig
@@ -0,0 +1,15 @@
+
+menu "Domain Builder Features"
+
+config DOMAIN_BUILDER
+	bool "Domain builder (UNSUPPORTED)" if UNSUPPORTED
+	select LIB_DEVICE_TREE
+	help
+	  Enables the domain builder capability to configure boot domain
+	  construction using a flattened device tree.
+
+	  This feature is currently experimental.
+
+	  If unsure, say N.
+
+endmenu
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 26 17:10:36 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Dec 2024 17:10:36 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863332.1274788 (Exim 4.92)
	(envelope-from )
	id 1tQrNX-0003Yh-4R; Thu, 26 Dec 2024 17:10:31 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863332.1274788; Thu, 26 Dec 2024 17:10: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 1tQrNX-0003Ya-09; Thu, 26 Dec 2024 17:10:31 +0000
Received: by outflank-mailman (input) for mailman id 863332;
 Thu, 26 Dec 2024 17:10: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 1tQrEE-0005x0-Te
 for xen-devel@lists.xenproject.org; Thu, 26 Dec 2024 17:00:54 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id f7093153-c3aa-11ef-a0da-8be0dac302b0;
 Thu, 26 Dec 2024 18:00:54 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 17352322892101014.8069874254229;
 Thu, 26 Dec 2024 08:58:09 -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: f7093153-c3aa-11ef-a0da-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1735232294; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=bEsb+5V8TjawamDf4z6EdBZYmMuMB8eV7fPNaaqsUTzeVgaDz+pQvztXqs8r6j8ey2D495Jd9DFUjQcv47Pb173T5J1wycjQXE0jjuSKFgCx/5RtiixRofKtLtFPnM9JrEKNDhie4HW03G0U880Gw1bzqp3ubiuXRtLi3taGa80=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1735232294; h=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=hXdbAJzSfNTcSeY3krNKNli9zbh1A0XPeYZ31pxiNfM=; 
	b=KkNlPFMSTV2k0JrSlbRi5SCLP6+BFG2AWtz5PGLF/o4GVKgjMb7wFOczd4h8hjLmrsr/fxS1kmdC9sYhsCdeUalbRqckAL7XHGnpZS3ZfSqVv9Ap7VelpXiYwA3ZOBwHHbhdqqajmuQtHC6tM+tiZd5PX+ZFERXjJiNRxkO/d7Y=
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=1735232294;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=hXdbAJzSfNTcSeY3krNKNli9zbh1A0XPeYZ31pxiNfM=;
	b=AHp9SqhMtXqFD/cwJHnmmy7w3dsFJpdG7fYX8NpgqugAiE3wa77MNYfsMaUmG39K
	EEoquxwGq46Tw4XuicLIogV4X9FfI9NdaMOTtIKbCILQkXynSrZqWm1bsg9MUB5be3R
	E7KN2YQ3/kU+BnQRaGmzSar8VAgiMYxtPNSXci68=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	christopher.w.clark@gmail.com,
	stefano.stabellini@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 14/15] x86/hyperlaunch: add max vcpu parsing of hyperlaunch device tree
Date: Thu, 26 Dec 2024 11:57:39 -0500
Message-Id: <20241226165740.29812-15-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20241226165740.29812-1-dpsmith@apertussolutions.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Introduce the `cpus` property, named as such for dom0less compatibility, that
represents the maximum number of vpcus to allocate for a domain. In the device
tree, it will be encoded as a u32 value.

Signed-off-by: Daniel P. Smith 
Reviewed-by: Jason Andryuk 
---
Changes since v1:
- switched from match_fdt to strncmp
- switched to nested else if
- dropped ternary for name selection
---
 xen/arch/x86/dom0_build.c             |  3 +++
 xen/arch/x86/domain-builder/fdt.c     | 11 +++++++++++
 xen/arch/x86/include/asm/bootdomain.h |  2 ++
 3 files changed, 16 insertions(+)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 1c3b7ff0e658..7ff052016bfd 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -617,6 +617,9 @@ int __init construct_dom0(struct boot_domain *bd)
     if ( !get_memsize(&dom0_max_size, LONG_MAX) && bd->max_pages )
         dom0_size.nr_pages = bd->max_pages;
 
+    if ( opt_dom0_max_vcpus_max == UINT_MAX && bd->max_vcpus )
+        opt_dom0_max_vcpus_max = bd->max_vcpus;
+
     if ( is_hvm_domain(d) )
         rc = dom0_construct_pvh(bd);
     else if ( is_pv_domain(d) )
diff --git a/xen/arch/x86/domain-builder/fdt.c b/xen/arch/x86/domain-builder/fdt.c
index aff1b8c3235d..70a793db199b 100644
--- a/xen/arch/x86/domain-builder/fdt.c
+++ b/xen/arch/x86/domain-builder/fdt.c
@@ -147,6 +147,17 @@ static int __init process_domain_node(
             bd->max_pages = PFN_DOWN(kb * SZ_1K);
             printk("  max memory: %ld kb\n", kb);
         }
+        else if ( strncmp(prop_name, "cpus", name_len) == 0 )
+        {
+            uint32_t val = UINT_MAX;
+            if ( fdt_prop_as_u32(prop, &val) != 0 )
+            {
+                printk("  failed processing max_vcpus for domain %s\n", name);
+                return -EINVAL;
+            }
+            bd->max_vcpus = val;
+            printk("  max vcpus: %d\n", bd->max_vcpus);
+        }
     }
 
     fdt_for_each_subnode(node, fdt, dom_node)
diff --git a/xen/arch/x86/include/asm/bootdomain.h b/xen/arch/x86/include/asm/bootdomain.h
index d7092bc32ad7..1a15273043f5 100644
--- a/xen/arch/x86/include/asm/bootdomain.h
+++ b/xen/arch/x86/include/asm/bootdomain.h
@@ -24,6 +24,8 @@ struct boot_domain {
     unsigned long min_pages;
     unsigned long max_pages;
 
+    unsigned int max_vcpus;
+
     struct boot_module *kernel;
     struct boot_module *ramdisk;
 
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 26 17:11:22 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Dec 2024 17:11:22 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863362.1274797 (Exim 4.92)
	(envelope-from )
	id 1tQrOM-0004im-G8; Thu, 26 Dec 2024 17:11:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863362.1274797; Thu, 26 Dec 2024 17:11: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 1tQrOM-0004if-DR; Thu, 26 Dec 2024 17:11:22 +0000
Received: by outflank-mailman (input) for mailman id 863362;
 Thu, 26 Dec 2024 17:11: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 1tQrEM-0005x0-35
 for xen-devel@lists.xenproject.org; Thu, 26 Dec 2024 17:01:02 +0000
Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com
 [136.143.188.51]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id fb622775-c3aa-11ef-a0da-8be0dac302b0;
 Thu, 26 Dec 2024 18:01:01 +0100 (CET)
Received: by mx.zohomail.com with SMTPS id 1735232290582938.4677206553228;
 Thu, 26 Dec 2024 08:58: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: fb622775-c3aa-11ef-a0da-8be0dac302b0
ARC-Seal: i=1; a=rsa-sha256; t=1735232296; cv=none; 
	d=zohomail.com; s=zohoarc; 
	b=fTx+RrBVql5Nk7YuBcEIige9Ew7ilaJgqad89L322VysMEZauUppeYqLmTSRtZ4zCd3j1CzQ62u82EFLQBWkXN6it0o86+d4lxZ+uzh8pjqkBO0+aVuMquMCcr9XMFUqM1kFjXc73r8A2mXHtQ62SIkn8moXvlTmQ7p0rTG3Wrs=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; 
	t=1735232296; h=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=ZIGHKNiDcj/HqTL/IBZMznrIHbY4YhPeFEesoRFQtNI=; 
	b=M0qUxiC1ouoi2PAeVimJd5aTTMRAX8BA2WkWIG5VtZSTyMjQxUDHl8a40gGap/KCRMKdPKckGd3cO5DnXSToslconFCgv/i8CWF1etC0KBFeiPRLFpoF9ERH4Oc/2f2LFg8T6Ol9rQ7CxLEPNggxCzOyjkRQhb7eXuESMcs1yMo=
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=1735232296;
	s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com;
	h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Reply-To;
	bh=ZIGHKNiDcj/HqTL/IBZMznrIHbY4YhPeFEesoRFQtNI=;
	b=dtZ2aAsqfLKFMwAS3FmW2ldAcmpPEHxEeOXqJ3RoFfT7Wg9E0AOzBidWuDvScR/h
	k4Jblh2ksmWmvaTJA2f1ho+tL/QuFtgFcADDU1JT9+e7Bu3n7hurTGxw3UK6I4Cxw/w
	wCttHrveFvzbUqybql8BX9WbCtrmEA5B1CoGsN3g=
From: "Daniel P. Smith" 
To: xen-devel@lists.xenproject.org
Cc: "Daniel P. Smith" ,
	jason.andryuk@amd.com,
	christopher.w.clark@gmail.com,
	stefano.stabellini@amd.com,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [PATCH v2 15/15] x86/hyperlaunch: add capabilities to boot domain
Date: Thu, 26 Dec 2024 11:57:40 -0500
Message-Id: <20241226165740.29812-16-dpsmith@apertussolutions.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20241226165740.29812-1-dpsmith@apertussolutions.com>
References: <20241226165740.29812-1-dpsmith@apertussolutions.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-ZohoMailClient: External

Introduce the ability to assign capabilities to a domain via its definition in
device tree. The first capability enabled to select is the control domain
capability. The capability property is a bitfield in both the device tree and
`struct boot_domain`.

Signed-off-by: Daniel P. Smith 
Reviewed-by: Jason Andryuk 
---
Changes since v1:
- switch to nested else if
- switch from match_fdt to strncmp
- drop ternary for name selection
- coding style changes
---
 xen/arch/x86/domain-builder/core.c    |  1 +
 xen/arch/x86/domain-builder/fdt.c     | 12 ++++++++++++
 xen/arch/x86/include/asm/bootdomain.h |  4 ++++
 xen/arch/x86/setup.c                  |  6 +++++-
 4 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/domain-builder/core.c b/xen/arch/x86/domain-builder/core.c
index 91d1b7367e76..589496b6a3e1 100644
--- a/xen/arch/x86/domain-builder/core.c
+++ b/xen/arch/x86/domain-builder/core.c
@@ -96,6 +96,7 @@ void __init builder_init(struct boot_info *bi)
         i = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
         bi->mods[i].type = BOOTMOD_KERNEL;
         bi->domains[0].kernel = &bi->mods[i];
+        bi->domains[0].capabilities |= BUILD_CAPS_CONTROL;
         bi->nr_domains = 1;
     }
 }
diff --git a/xen/arch/x86/domain-builder/fdt.c b/xen/arch/x86/domain-builder/fdt.c
index 70a793db199b..e90b230eeffe 100644
--- a/xen/arch/x86/domain-builder/fdt.c
+++ b/xen/arch/x86/domain-builder/fdt.c
@@ -158,6 +158,18 @@ static int __init process_domain_node(
             bd->max_vcpus = val;
             printk("  max vcpus: %d\n", bd->max_vcpus);
         }
+        else if ( strncmp(prop_name, "capabilities", name_len) == 0 )
+        {
+            if ( fdt_prop_as_u32(prop, &bd->capabilities) != 0 )
+            {
+                printk("  failed processing domain id for domain %s\n", name);
+                return -EINVAL;
+            }
+            printk("  caps: ");
+            if ( bd->capabilities & BUILD_CAPS_CONTROL )
+                printk("c");
+            printk("\n");
+        }
     }
 
     fdt_for_each_subnode(node, fdt, dom_node)
diff --git a/xen/arch/x86/include/asm/bootdomain.h b/xen/arch/x86/include/asm/bootdomain.h
index 1a15273043f5..67f43c13e905 100644
--- a/xen/arch/x86/include/asm/bootdomain.h
+++ b/xen/arch/x86/include/asm/bootdomain.h
@@ -15,6 +15,10 @@ struct boot_domain {
 
     domid_t domid;
 
+#define BUILD_CAPS_NONE          (0)
+#define BUILD_CAPS_CONTROL       (1 << 0)
+    uint32_t capabilities;
+
                                           /* On     | Off    */
 #define BUILD_MODE_PARAVIRT      (1 << 0) /* PV     | PVH/HVM */
 #define BUILD_MODE_ENABLE_DM     (1 << 1) /* HVM    | PVH     */
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index a87e122b5a61..0fb8572b7145 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1002,6 +1002,7 @@ static size_t __init domain_cmdline_size(
 static struct domain *__init create_dom0(struct boot_info *bi)
 {
     char *cmdline = NULL;
+    unsigned int create_flags = 0;
     struct xen_domctl_createdomain dom0_cfg = {
         .flags = IS_ENABLED(CONFIG_TBOOT) ? XEN_DOMCTL_CDF_s3_integrity : 0,
         .max_evtchn_port = -1,
@@ -1033,7 +1034,10 @@ static struct domain *__init create_dom0(struct boot_info *bi)
     if ( bd->domid == DOMID_INVALID )
         /* Create initial domain.  Not d0 for pvshim. */
         bd->domid = get_initial_domain_id();
-    d = domain_create(bd->domid, &dom0_cfg, pv_shim ? 0 : CDF_privileged);
+    if ( bd->capabilities & BUILD_CAPS_CONTROL )
+        create_flags |= CDF_privileged;
+    d = domain_create(bd->domid, &dom0_cfg,
+                      pv_shim ? 0 : create_flags);
     if ( IS_ERR(d) )
         panic("Error creating d%u: %ld\n", bd->domid, PTR_ERR(d));
 
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Thu Dec 26 18:48:46 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Dec 2024 18:48:46 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863383.1274808 (Exim 4.92)
	(envelope-from )
	id 1tQsuJ-0005UW-BK; Thu, 26 Dec 2024 18:48:27 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863383.1274808; Thu, 26 Dec 2024 18:48:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tQsuJ-0005UP-6i; Thu, 26 Dec 2024 18:48:27 +0000
Received: by outflank-mailman (input) for mailman id 863383;
 Thu, 26 Dec 2024 18:48: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 1tQsuH-0005TY-Ev
 for xen-devel@lists.xenproject.org; Thu, 26 Dec 2024 18:48:25 +0000
Received: from fhigh-a3-smtp.messagingengine.com
 (fhigh-a3-smtp.messagingengine.com [103.168.172.154])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f5672c49-c3b9-11ef-99a3-01e77a169b0f;
 Thu, 26 Dec 2024 19:48:13 +0100 (CET)
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 1D78F114016C
 for ; Thu, 26 Dec 2024 13:48:12 -0500 (EST)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-06.internal (MEProxy); Thu, 26 Dec 2024 13:48:12 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Thu, 26 Dec 2024 13:48:11 -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: f5672c49-c3b9-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=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=1735238892;
	 x=1735325292; bh=z6ILCZyKYEYu/+df/UDnQYY4VydKA+78DiVS/BSI4U8=; b=
	pqVNCawzbtaV2PCSU0fvKXkgFUPI9leZcixVVzZe9+gl31OVnY9kApjS7/bDgQuv
	FtaBcwhnJheupnRDiq1oW9WsPMOKgHbxWaLfBQiZL3FSARtfzsOWKUk6jqQJYVNW
	I6qf6nowqgpTL5D9gHU5thFvxHgMvyM7v8bMK0jleZ1Lp/ZaoNexbe+FN2OZXiKo
	mlvWDNOMoJz3cc/kUAFfniIIBlq1ns9XgTjB+TlnImrIDjp7H5IN9bVnG6Z49Ji6
	+vywJ1rCyaJEcFZQZI1PXVcYWIsX/cYnfSNSs8Bo4nt5Yt5z9/qMzVwXD+JiQDvE
	aukFjvcOSHwfUPHYsnUABw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=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=fm2; t=
	1735238892; x=1735325292; bh=z6ILCZyKYEYu/+df/UDnQYY4VydKA+78DiV
	S/BSI4U8=; b=i6vkS5R506QNXYDO4YaT+2cK/qjY8qznTfIguIZ9LGbf3eB0UVp
	bq84dBxV4BZODNQYZh4CZRv9oZV023g1mavlRgADHYrsc1Ur0/XWLFLk1QyTlXgZ
	pUV5DwB+ffva2tmt6c+yZ00vYzxQRcUDiQihe6SNXbr8c9zjvFWIbq9QvJ1ymH09
	hpIMQJlOYSCJ9ZzyVCNA0U36rsFQf1o6znez4imnCL8bobfTfuyJrGbH/G4tSynI
	xbieTweshlWT3v5jDBAISY3jfU2MnZPEEViSMAb+V7GmRjYaaWJ1bXykloB74vLN
	nRnViRmqhUtJmKJmLGhtZdHj7B7Mgyhhn7A==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddruddukedguddujecutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
    uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvf
    fukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghkucforghrtgiihihk
    ohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthh
    hinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeetveffiefghfekhffggeef
    fffhgeevieektedthfehveeiheeiiedtudegfeetffenucevlhhushhtvghrufhiiigvpe
    dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghl
    vghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopedupdhmohguvgepshhmth
    hpohhuthdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhj
    vggtthdrohhrgh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Thu, 26 Dec 2024 19:48:08 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel 
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0
Message-ID: 
References: 
 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="q8zuvRHPgZ9sUEen"
Content-Disposition: inline
In-Reply-To: 


--q8zuvRHPgZ9sUEen
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Thu, 26 Dec 2024 19:48:08 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: xen-devel 
Subject: Re: Linux 6.13-rc3 many different panics in Xen PV dom0

On Fri, Dec 20, 2024 at 02:48:52AM +0100, Marek Marczykowski-G=C3=B3recki w=
rote:
> On Thu, Dec 19, 2024 at 05:14:52PM +0100, Marek Marczykowski-G=C3=B3recki=
 wrote:
> > Hi,
> >=20
> > It crashes on boot like below, most of the times. But sometimes (rarely)
> > it manages to stay alive. Below I'm pasting few of the crashes that look
> > distinctly different, if you follow the links, you can find more of
> > them. IMHO it looks like some memory corruption bug somewhere. I tested
> > also Linux 6.13-rc2 before, and it had very similar issue.
> >=20
> > The traces below are all from nested virt (Xen inside KVM), tests with
> > Xen directly on the hardware are still in progress. But -rc2 failed all
> > of them too, so if it's the same issue, I guess they will looks similar.
>=20
> Yes, on real hardware it crashes too.

6.13-rc4 fails the same way.

> I tried to enable KASAN, but that didn't worked out:
>=20
> (XEN) d0 has maximum 416 PIRQs
> (XEN) *** Building a PV Dom0 ***
> (XEN)  Xen  kernel: 64-bit, lsb
> (XEN)  Dom0 kernel: 64-bit, lsb, paddr 0x200000 -> 0x7600000
> (XEN) PHYSICAL MEMORY ARRANGEMENT:
> (XEN)  Dom0 alloc.:   0000000260000000->0000000268000000 (1005377 pages t=
o be allocated)
> (XEN)  Init. ramdisk: 000000027d741000->000000027ffff207
> (XEN) VIRTUAL MEMORY ARRANGEMENT:
> (XEN)  Loaded kernel: ffffffff80200000->ffffffff87600000
> (XEN)  Phys-Mach map: 0000008000000000->0000008000800000
> (XEN)  Start info:    ffffffff87600000->ffffffff876004b8
> (XEN)  Page tables:   ffffffff87601000->ffffffff87640000
> (XEN)  Boot stack:    ffffffff87640000->ffffffff87641000
> (XEN)  TOTAL:         ffffffff80000000->ffffffff87800000
> (XEN)  ENTRY ADDRESS: ffffffff8615da50
> (XEN) Dom0 has maximum 2 VCPUs
> (XEN) Initial low memory virq threshold set at 0x4000 pages.
> (XEN) Scrubbing Free RAM in background
> (XEN) Std. Loglevel: All
> (XEN) Guest Loglevel: All
> (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input)
> (XEN) Freed 684kB init memory
> (XEN) d0v0 Unhandled: vec 14, #PF[0002]
> (XEN) Pagetable walk from fffffbfff0900fc6:
> (XEN)  L4[0x1f7] =3D 0000000000000000 ffffffffffffffff
> (XEN) domain_crash_sync called from entry.S: fault at ffff82d0402ebdec x8=
6_64/entry.S#create_bounce_frame+0x14c/0x170
> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) ----[ Xen-4.19.0  x86_64  debug=3Dn  Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    e033:[]
> (XEN) RFLAGS: 0000000000000286   EM: 1   CONTEXT: pv guest (d0v0)
> (XEN) rax: ffffffff860d8000   rbx: ffffffff87600000   rcx: 00000000c00001=
01
> (XEN) rdx: 3be9e05ee5ed7ef7   rsi: ffffffff87600000   rdi: fffffbfff0900f=
c6
> (XEN) rbp: ffffffff84807f48   rsp: ffffffff84807df0   r8:  00000000000000=
00
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 00000000000000=
00
> (XEN) r12: dffffc0000000000   r13: 0000000000000000   r14: 00000000000000=
00
> (XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000003406=
60
> (XEN) cr3: 0000000267601000   cr2: fffffbfff0900fc6
> (XEN) fsb: 0000000000000000   gsb: ffffffff860d8000   gss: 00000000000000=
00
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
> (XEN) Guest stack trace from rsp=3Dffffffff84807df0:
> (XEN)    00000000c0000101 0000000000000000 0000000000000002 ffffffff8614f=
f32
> (XEN)    000000010000e030 0000000000010086 ffffffff84807e30 000000000000e=
02b
> (XEN)    0000000041b58ab3 ffffffff845f8030 ffffffff8614fed0 0000000000000=
000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000=
000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000=
000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000=
000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000=
000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000=
000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000=
000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000=
000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000=
000
> (XEN)    ffffffff8615da6f 0000000000000000 0000000000000000 0000000000000=
000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000=
000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000=
000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000=
000
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000=
000
> (XEN)    0000000000000000 0000000000000000
> (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
> (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
>=20
> > Who should I CC here? The failures are all over the place... linux-mm?
>=20
> --=20
> Best Regards,
> Marek Marczykowski-G=C3=B3recki
> Invisible Things Lab



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

--q8zuvRHPgZ9sUEen
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmdtpOkACgkQ24/THMrX
1ywhsAgAluf3fe1wc+P+ETc/JmgZkJ94iuT2WlK3mqFd7ncRbd67LVSiiF2BHu7o
oz+km7wyBF8sUwcThh8UUqyipPudHii0hy0/lRIkVHiwIfcAfG5wdH4oo1yaEQhK
mPkbBnFBtaguA0MaSJwYxggKT715oxLQHDCFIo3YwWbxnfoGeXTLRSd4naqmF5fR
AIZGClv9xr8JpZL36LJKF41ku/8wqJt/wNNv2qGw70GkMeyVOF208PCsbMiPTySt
4spMh7Yj+rhITB3+5UU+buXmgEpBq3uXv4LUmZ6pChdBpjy3mRltIfmO7i9Je0ZR
bNmDQimmNApwUcljjnVrq/ZNwR8c5g==
=kA3n
-----END PGP SIGNATURE-----

--q8zuvRHPgZ9sUEen--


From xen-devel-bounces@lists.xenproject.org Fri Dec 27 09:30:29 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Dec 2024 09:30:29 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863402.1274817 (Exim 4.92)
	(envelope-from )
	id 1tR6fX-0002kQ-6z; Fri, 27 Dec 2024 09:30:07 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863402.1274817; Fri, 27 Dec 2024 09:30: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 1tR6fX-0002jw-47; Fri, 27 Dec 2024 09:30:07 +0000
Received: by outflank-mailman (input) for mailman id 863402;
 Fri, 27 Dec 2024 09:30: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 1tR6fW-0002ez-AW
 for xen-devel@lists.xenproject.org; Fri, 27 Dec 2024 09:30:06 +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 270dd5e8-c435-11ef-99a3-01e77a169b0f;
 Fri, 27 Dec 2024 10:30:04 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-4362f61757fso70667305e9.2
 for ; Fri, 27 Dec 2024 01:30: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-43661219a71sm257987925e9.26.2024.12.27.01.30.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 27 Dec 2024 01:30: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: 270dd5e8-c435-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1735291803; x=1735896603; 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=00WtuGiAjqszGQrq1V2bI3imru/l+J6htk/nOF9E2aw=;
        b=VHGqtXGYdiftfv01Kb6BNvGdLnRdt1kFOe7DDR5P0tOT4GcO5zYMWcGK4+sCqd6uvc
         3CCyAqmYy6tOK9TExOpIY5n80vMASWd7ZgCOFavnu3JeTM8liko/0xcODgha8obI6npN
         147z2oeYYsuPVo1T2En01k9L+QT6QGH0WnbZvwaoV/H4F0K6Qt+AJCLcK85/AWV5wsMY
         buQtUsZiJV9PjburYLpkvmY/XuCqKUMZZ1zoK3NPnkzF1W69r5wfJV9usozsJ4dxkRVL
         neTnq9o+Nwgv6oQSkDklWOu1FERzGK4ZWVx5B8QfjQAkEIlGgCghyhvsZ6uBY81ngqG3
         mvwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735291803; x=1735896603;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=00WtuGiAjqszGQrq1V2bI3imru/l+J6htk/nOF9E2aw=;
        b=YpH1EH+Fr260ZBQJNkbZ1rMmvLNYC2Hk1gfML66ZkNFjnDWPc/j7JPf/btY3dOdUTC
         nwnqLHkvT4/UAwhu49Mx0OqSZNWih+AJQKD2N41oy7+3u8i3xLa7dsMVv5SWWR5xx34Q
         SbARvWOa+NMc2ASusbrsHL5tiTvJCjfZs71SOcleZOboQW5sQDRW40hoq08eBuDeKYkj
         qM0RnWHZMWUevO4EozqmVP6IYxfxz6fyAO+FyX7L5WYB8fAp2QuYuGxjBRkpSlRHMDxI
         FQx83kuDC9unRYX23qX3pH8KChBqjcsTNo2PfWx58jChKkd1lVDCir947sifiKchyCM2
         hU0g==
X-Forwarded-Encrypted: i=1; AJvYcCVK7ZhEdwzr9mZsX457jiPd5Q4Hsj3iYzSF9v1cRD2EcrFUg137SWo+EQIREVj8bLgI41NwNfRLrZ4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzF0W1We1cKd/k0Kg/QKbLCDT4huGqFPINqn4FhReAenuAEMP6/
	Uj8Zlkg/+VVa2RxrR6cjQjNBsIWXMRrIJbkf/LrQ8PhxoY+SDbG1RaN8v/Rnbg==
X-Gm-Gg: ASbGncvWigRb1bFwQ8pgSnBhQJ43YmzMPOVDstd7VNAoF5eG6z196dMJyXCswWxEYbm
	JJDsQpbmNe0A24alvLtydIATGbCSTQoL/BNwfJ9k+e4zFfhrG3BQdhgOQcnwPkwHM+cxNDlLzkd
	ue83ZfVa++BmQCYLBbj+ezuzKP8gGNp0zP1apHg/+xUmnqQgoXD0sl+j1EI4RP2lmowfDbsfjR/
	e2dneq49Ou7s5cpC3f2UR1MPrnx7IGhU6mdrSqrgUF40EyT2v67t3GfCDBI4q+ytJqhMl8e4QYm
	Sq3KI9Ifv4MQluVzXTK70Vh5f/LOzj2jJ4Kobs0Ffg==
X-Google-Smtp-Source: AGHT+IEtZH4RUW59/GVQHHwhJhDiaBLwj1Elb048br2TV/p/6h1HTuWrtOhim9LxAVAs16vjMS20kQ==
X-Received: by 2002:a05:6000:186d:b0:386:1cd3:8a08 with SMTP id ffacd0b85a97d-38a221ed256mr24990055f8f.5.1735291803347;
        Fri, 27 Dec 2024 01:30:03 -0800 (PST)
Message-ID: 
Date: Fri, 27 Dec 2024 10:30:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] xen/tools: remove dead code
To: Ariel Otilibili 
Cc: Anthony PERARD ,
 Doug Goldstein , xen-devel@lists.xenproject.org
References: <20241220165837.937976-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241224191529.138119-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241224191529.138119-3-Ariel.Otilibili-Anieli@eurecom.fr>
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: <20241224191529.138119-3-Ariel.Otilibili-Anieli@eurecom.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24.12.2024 20:13, Ariel Otilibili wrote:
> The original file was imported from Linux; patched the entire
> expr_compare_type() with the diff from Linux.

I'm afraid that it's quite likely that taking changes to just an isolated
function will not work very well. What's worse, ...

> Commits wherein it might have been fixed in Linux:
> - dfe8e56fc604 ("kconfig: add fallthrough comments to expr_compare_type()")
> - 9ad86d747c46 ("kconfig: remove unreachable printf()").

... these references to Linux commits then don't really help, as the isolated
changes may have different effects, and hence ...

> ```
> $ diff -u xen/xen/tools/kconfig/expr.c linux/scripts/kconfig/expr.c | \
>     sed -ne '/expr_compare_type/,/return 0/{N;p}'
> 
>  static int expr_compare_type(enum expr_type t1, enum expr_type t2)
>  {
>         if (t1 == t2)
> @@ -1106,30 +999,27 @@
>         case E_GTH:
>                 if (t2 == E_EQUAL || t2 == E_UNEQUAL)
>                         return 1;
> +               /* fallthrough */
>         case E_EQUAL:
>         case E_UNEQUAL:
>                 if (t2 == E_NOT)
>                         return 1;
> +               /* fallthrough */
>         case E_NOT:
>                 if (t2 == E_AND)
>                         return 1;
> +               /* fallthrough */
>         case E_AND:
>                 if (t2 == E_OR)
>                         return 1;
> -       case E_OR:
> -               if (t2 == E_LIST)
> -                       return 1;
> -       case E_LIST:
> -               if (t2 == 0)
> -                       return 1;
> +               /* fallthrough */
>         default:
> -               return -1;
> +               break;
>         }
> -       printf("[%dgt%d?]", t1, t2);
>         return 0;
>  }
> 
> $ cd linux/;
> $ git log --oneline -1 --pretty='%h ("%s")'
> 8155b4ef3466 ("Add linux-next specific files for 20241220")
> 
> $ git remote -v
> next    git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (fetch)
> next    git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (push)
> 
> $ cd ../xen/
> $ git log --oneline -1 --pretty='%h ("%s")'
> 6419020270 ("CHANGELOG: Mention LLC coloring feature on Arm")
> 
> $ git remote -v
> up      git://xenbits.xen.org/xen.git (fetch)
> up      git://xenbits.xen.org/xen.git (push)
> ```
> 
> Coverity-ID: 1458052
> Fixes: 8c271b7584 ("build: import Kbuild/Kconfig from Linux 4.3")
> Cc: Doug Goldstein 
> Suggested-by: Jan Beulich 
> Signed-off-by: Ariel Otilibili 

... an actual description of the (effect of the) changes done _here_ is missing.
For example, ....

> --- a/xen/tools/kconfig/expr.c
> +++ b/xen/tools/kconfig/expr.c
> @@ -1106,26 +1106,23 @@ static int expr_compare_type(enum expr_type t1, enum expr_type t2)
>  	case E_GTH:
>  		if (t2 == E_EQUAL || t2 == E_UNEQUAL)
>  			return 1;
> +		/* fallthrough */
>  	case E_EQUAL:
>  	case E_UNEQUAL:
>  		if (t2 == E_NOT)
>  			return 1;
> +		/* fallthrough */
>  	case E_NOT:
>  		if (t2 == E_AND)
>  			return 1;
> +		/* fallthrough */
>  	case E_AND:
>  		if (t2 == E_OR)
>  			return 1;
> -	case E_OR:
> -		if (t2 == E_LIST)
> -			return 1;
> -	case E_LIST:
> -		if (t2 == 0)
> -			return 1;
> +		/* fallthrough */

... it's unclear to me why removing handling of E_OR and E_LIST is actually correct.

All of this said - this looks like a wording issue: You did actually take two full
commits (adding in - see below - at least one change of your own). May I suggest
that you take those commits individually, retaining their titles and descriptions,
merely adding necessary further tags (Origin: and your own S-o-b)?

>  	default:
> -		return -1;
> +		break;

This change isn't part of either of the mentioned commits.

>  	}
> -	printf("[%dgt%d?]", t1, t2);
>  	return 0;
>  }

The "Suggested-by:" also isn't quite right imo. If anything what I suggested was
to take commits from Linux. But that's whole commits, not fragments thereof, nor
multiple of them folded (unless there's a good reason to do so). And for such
straight importing I don't think "Suggested-by:" would be quite applicable.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Dec 27 09:34:37 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Dec 2024 09:34:37 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863410.1274827 (Exim 4.92)
	(envelope-from )
	id 1tR6js-0003pW-Nt; Fri, 27 Dec 2024 09:34:36 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863410.1274827; Fri, 27 Dec 2024 09: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 1tR6js-0003pP-L2; Fri, 27 Dec 2024 09:34:36 +0000
Received: by outflank-mailman (input) for mailman id 863410;
 Fri, 27 Dec 2024 09:34: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 1tR6jr-0003pC-81
 for xen-devel@lists.xenproject.org; Fri, 27 Dec 2024 09:34:35 +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 c7a34e96-c435-11ef-99a3-01e77a169b0f;
 Fri, 27 Dec 2024 10:34:33 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-43625c4a50dso47534195e9.0
 for ; Fri, 27 Dec 2024 01:34: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-4366e210cecsm223981735e9.2.2024.12.27.01.34.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 27 Dec 2024 01:34: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: c7a34e96-c435-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1735292073; x=1735896873; 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=ykhvyOHewNbrDgJmTnfvEQHtptra29c6/y+MVTkzqV8=;
        b=M4prf9TtvZ9xjuFdSEE5gTiE9FOa7qFCSUoU7ziM3KrESXwcZEvUHKPpOtyh1Jsyge
         5LTSl2Q+uJucRi5x0vs1c9bGYk7w20/yZ9BEH5DdxaumWqZRsdOI2OYFRNI4shPcFbXi
         A73J+3oae/Fyxv+aAbkmlJzYS3ndfY/U4w6RWtmYHl/NHlstWQ3TCfKhTHc2lRJbnWO+
         Sd39OZ4sMCPflI5cj9g5Svtdl8ITxeWpYM9QzaXUEqqlkAPLLCsfZl4PZz5NeuzsEGda
         V1RU8AQ6KQuH1pXNZBqYXs9F/+iHEX8RGbbNP2QscsDL+uCIVW1B7ZMoYAJLNRzBxllC
         DVsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735292073; x=1735896873;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ykhvyOHewNbrDgJmTnfvEQHtptra29c6/y+MVTkzqV8=;
        b=AznWWLpA/utGuP3GLhiT6eePKmvjEf6qC7wJ/7gw4/qpKnSeGsvpObk0OA+WI7rbPq
         QRaUk/5Wo3dhSq4lxFr0ZXo9ATJ+5C/OvkDURaCwEIyc6msC80Ytr4mQ2y5CvEn+VQao
         g3vifwRa51/zW0yt2DIhnhhoXFZL4D51foTadoVWga/nkgwrxTWdZg11UxT2qFG0v3v/
         9FdBSLyf+M4kPOPd7QKMrgB0piiFp1zI4Sb/i8/Wd5L2H+Dmm0QqirXekKbOaD9jsY5w
         AAU3PKdnviysci+m54P1Jcrg1Nf7D0ERQoPcWKruZnqtaTsi5z8lhms4X8JgsLDZUkiZ
         I7Hg==
X-Forwarded-Encrypted: i=1; AJvYcCWDERLLIR+SBD2ObNcEinMKrhM6x+eCDnuBWQSuBnEQP/sDxI+Naf3LTi+VANBN96spB79dgIxDXVk=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzEjqSbhG0SGbPr/YMkcZWO/kjv4m40x4HfgLIZBdDYvoO3Autz
	7ylY9zsrPO0u5aaWRbD9UwCeXRFBrylDUrdiHKONZ6RJeAlTl7TIoJPvlFHOs03ZSIXnKLADjWE
	=
X-Gm-Gg: ASbGncsyIxeovHaZfWlM/FGB4LNrEV7w34TOiyK/dxkN6U8DYMQTwE5rDTn3rYXwcRL
	igGSeDav3+vryROCedn51EKmeDT2l1o8WFlNEoCjT1w15DNex3pYLfwecRo6xcgUTxoH6hF/h7T
	rmhFqO+KX3GPIzIsPPZqKilsmTCCLsEtnTz6bLE0MhGGozeKo4Rw7jbU58k+oU+Y/e20hwcGGsI
	XiewIvMtaDdHiasOsklu//T858mpkOCLoKn4+Oy7BSKO6OxtRrV5/f0Jb4mV/h1DnwDM84p+x9H
	xgHX2jApz9YBncqEcB59EulNCv/nvVhpBlmINFwCYg==
X-Google-Smtp-Source: AGHT+IFMTvahqmi+mfJ6vdv8zj4sbZQpZdyy13XgxuG5nDmt9NhyncaOOtDL6yyC0PrdTbpAGjldhQ==
X-Received: by 2002:a05:600c:3b23:b0:431:60ec:7a96 with SMTP id 5b1f17b1804b1-43668b49950mr188242485e9.25.1735292072835;
        Fri, 27 Dec 2024 01:34:32 -0800 (PST)
Message-ID: <7503184b-58b7-4a07-86a6-b3d3eed0c587@suse.com>
Date: Fri, 27 Dec 2024 10:34:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3] x86/spec-ctrl: Support for SRSO_U/S_NO and
 SRSO_MSR_FIX
To: Andrew Cooper 
Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Oleksii Kurochko ,
 Xen-devel 
References: <20241220193424.470994-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: <20241220193424.470994-1-andrew.cooper3@citrix.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 20.12.2024 20:34, Andrew Cooper wrote:
> AMD have updated the SRSO whitepaper[1] with further information.  These
> features exist on AMD Zen5 CPUs and are necessary for Xen to use.
> 
> The two features are in principle unrelated:
> 
>  * SRSO_U/S_NO is an enumeration saying that SRSO attacks can't cross the
>    User(CPL3) / Supervisor(CPL<3) boundary.  i.e. Xen don't need to use
>    IBPB-on-entry for PV64.  PV32 guests are explicitly unsupported for
>    speculative issues, and excluded from consideration for simplicity.
> 
>  * SRSO_MSR_FIX is an enumeration identifying that the BP_SPEC_REDUCE bit is
>    available in MSR_BP_CFG.  When set, SRSO attacks can't cross the host/guest
>    boundary.  i.e. Xen don't need to use IBPB-on-entry for HVM.
> 
> Extend ibpb_calculations() to account for these when calculating
> opt_ibpb_entry_{pv,hvm} defaults.  Add a `bp-spec-reduce=` option to
> control the use of BP_SPEC_REDUCE, with it active by default.
> 
> Because MSR_BP_CFG is core-scoped with a race condition updating it, repurpose
> amd_check_erratum_1485() into amd_check_bp_cfg() and calculate all updates at
> once.
> 
> Xen also needs to to advertise SRSO_U/S_NO to guests to allow the guest kernel
> to skip SRSO mitigations too:
> 
>  * This is trivial for HVM guests.  It is also is accurate for PV32 guests
>    too, but we have already excluded them from consideration, and do so again
>    here to simplify the policy logic.
> 
>  * As written, SRSO_U/S_NO does not help for the PV64 user->kernel boundary.
>    However, after discussing with AMD, an implementation detail of having
>    BP_SPEC_REDUCE active causes the PV64 user->kernel boundary to have the
>    property described by SRSO_U/S_NO, so we can advertise SRSO_U/S_NO to
>    guests when the BP_SPEC_REDUCE precondition is met.
> 
> Finally, fix a typo in the SRSO_NO's comment.
> 
> [1] https://www.amd.com/content/dam/amd/en/documents/corporate/cr/speculative-return-stack-overflow-whitepaper.pdf
> Signed-off-by: Andrew Cooper 
> Reviewed-by: Roger Pau Monné 
> ---
> CC: Jan Beulich 
> CC: Roger Pau Monné 
> CC: Oleksii Kurochko 
> 
> I cannot say anything more about the SRSO_U/S_NO vs SRSO_MSR_FIX interactions
> in public.  The safety for PV guests depends on details not covered in the
> whitepaper.
> 
> v3:
>  * Rewrite commit message and comments quite a lot.
> 
> This patch was originally for-4.19.  Zen5 CPUs are now in the world and Xen is
> unsafe on them without this patch.
> 
> I technically have enough tags to commit it, and it's long overdue, but I
> think it would be wise to see if the new wording is clearer to others.

It is to me; thanks for making these adjustments.

As to said implementation detail: I suppose we can only hope that yet newer
implementations won't break this.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Dec 27 09:42:24 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Dec 2024 09:42:24 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863421.1274837 (Exim 4.92)
	(envelope-from )
	id 1tR6rL-0005w1-If; Fri, 27 Dec 2024 09:42:19 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863421.1274837; Fri, 27 Dec 2024 09:42: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 1tR6rL-0005vu-Ei; Fri, 27 Dec 2024 09:42:19 +0000
Received: by outflank-mailman (input) for mailman id 863421;
 Fri, 27 Dec 2024 09:42: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 1tR6rK-0005vn-FZ
 for xen-devel@lists.xen.org; Fri, 27 Dec 2024 09:42:18 +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 db959ba2-c436-11ef-99a3-01e77a169b0f;
 Fri, 27 Dec 2024 10:42:16 +0100 (CET)
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-43622267b2eso74928885e9.0
 for ; Fri, 27 Dec 2024 01:42: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-4366127c639sm257366265e9.31.2024.12.27.01.42.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 27 Dec 2024 01:42: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: db959ba2-c436-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1735292536; x=1735897336; darn=lists.xen.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=hMkg6nJm+8tDQOsqliPzeAtAuL0Dhm0Kvji69eQ02E4=;
        b=UYc7MwtI3EJUluSlaK2CBDGIQr82oGRlWlWJF+ESysJEnaRKzrVnqiapRbN+RU21tg
         Ubg3ga5oTmHV1ZGVFytAwDRj7pQKxkoi06UwKw0/jkfQUknqVghBTwyUpLXhSubTmTQ5
         +K5J7+Y0qlNhQZyn8hv7nV8PmPTgabKpzhnHxUyzTf+WWLvrTlmxW/TYz/QSttsOmzwS
         AXuOXnbiKfab2kHlWYjspzsIKH71VHHX/OabKcknnClWphiRmRo0U1J97d0IJK4MaVhP
         fvKJZiUjYyftLNiq4T7aNBHyRdVtVrpteNkR0O0I+eYvD0jfW52niRtGM8p7pf0TXsUB
         Eu1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735292536; x=1735897336;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=hMkg6nJm+8tDQOsqliPzeAtAuL0Dhm0Kvji69eQ02E4=;
        b=PDYL4QdZg4IPbbaVkwLjTw+ePY79kY/P94dwIDgoibNyWiAJgBREJK7GILYQiwbgYP
         u0oXaeposLSLCUK5yCAeDmL6QWtIcA494QVYFY7Wuvn0pUTZAtzo2JjpbCDbfVnuhox0
         Y162rc38HwAhCIyHaJXWUux47hZ0pDVTCQW4coZsjt+B6jymOJpAEn5uF1yXvM3F1vpe
         55zrLyFtYuX638q6RH+0VL6kSgRfRFoxfBlAP86Zr3kScL54czZqWlsCJQW7SA5LylGM
         YrFxSNzoN3ypGACBxszIU2Iumj7UVE0A91bQvE6e9PlfA1c3UU7Q+swApSjj1k869zYv
         izxw==
X-Gm-Message-State: AOJu0YwVZSujjRhzDq36I38XfadxFI3SMjIMrc35OygeMwkbGBH6wo4S
	zidii0hADeMsW7WALjM/tmEa0W53QSvZro6r27QOS9Mg8tli0kJfDDp/H+nWCA==
X-Gm-Gg: ASbGncvRHb0HAn0e6V60vYVlE5UZmLm9yfScrst6enC5lYqWfRHmfE3XYWlxojWHEAX
	sLUSEWI/V+luvvBLMyS5IV9Y8IXJ7VtGH0KZ5GCSzkD1em29mwSB6xxKs40JjlBtR7HBgmuh8YR
	6nHgeC+ECigEYeI65tyoha7rA9l7Ty5b4QfM5PP1+S4cYXGbUjTVfVY8rAUrlJxXMJMWsPoidOP
	XACLVRlpmqB6WEZhrlu+WdSCcthf3pdD0zJ9es1Q3QmdB6zJFWMjii862aaMjSiETG3LLBJWret
	rye519BLJMqGPAtyTCsNu8T1pC2UTXVMwnMb7dMIYA==
X-Google-Smtp-Source: AGHT+IFMAjKo2LJr8cildJj02etxFJ5+6YB577wdHuoxl46qaORGItyQP5gzW+g61a5aWmSi6Huo6w==
X-Received: by 2002:a05:6000:461e:b0:388:e377:8a1b with SMTP id ffacd0b85a97d-38a221f38b4mr20252778f8f.28.1735292535701;
        Fri, 27 Dec 2024 01:42:15 -0800 (PST)
Message-ID: <66f2784e-3b7c-4c54-96ca-bcaa58eba319@suse.com>
Date: Fri, 27 Dec 2024 10:42:14 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Xen Security Advisory 466 v3 (CVE-2024-53241) - Xen hypercall
 page unsafe against speculative attacks
To: David Woodhouse 
Cc: xen-devel@lists.xen.org, Juergen Gross 
References: 
 <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.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: <54c892eded2b4ebdda8ee1085c383178f44414ad.camel@infradead.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 23.12.2024 15:24, David Woodhouse wrote:
> On Tue, 2024-12-17 at 12:18 +0000, Xen.org security team wrote:
>>              Xen Security Advisory CVE-2024-53241 / XSA-466
>>                                 version 3
>>
>>          Xen hypercall page unsafe against speculative attacks
>>
>> UPDATES IN VERSION 3
>> ====================
>>
>> Update of patch 5, public release.
> 
> Can't we even use the hypercall page early in boot? Surely we have to
> know whether we're running on an Intel or AMD CPU before we get to the
> point where we can enable any of the new control-flow integrity
> support? Do we need to jump through those hoops do do that early
> detection and setup?

Yes, putting it e.g. in .init.text ought to be possible and not violate
security requirements.

> Enabling the hypercall page is also one of the two points where Xen
> will 'latch' that the guest is 64-bit, which affects the layout of the
> shared_info, vcpu_info and runstate structures.

Hmm, this is a side effect which I fear wasn't considered when putting
together all of this. Making ourselves dependent upon ...

> The other such latching point is when the guest sets
> HVM_PARAM_CALLBACK_IRQ, and I *think* that should work in all
> implementations of the Xen ABI (including QEMU/KVM and EC2). But would
> want to test.

... just this may end up too little, especially when considering
transitions between OSes / OS-like environments (boot loader -> OS,
OS -> kexec-ed OS).

> But perhaps it wouldn't hurt for maximal compatibility for Linux to set
> the hypercall page *anyway*, even if Linux doesn't then use it — or
> only uses it during early boot?

Indeed.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Dec 27 14:27:34 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Dec 2024 14:27:34 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863433.1274846 (Exim 4.92)
	(envelope-from )
	id 1tRBJ7-0005IR-UJ; Fri, 27 Dec 2024 14:27:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863433.1274846; Fri, 27 Dec 2024 14: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 1tRBJ7-0005IK-Rg; Fri, 27 Dec 2024 14:27:17 +0000
Received: by outflank-mailman (input) for mailman id 863433;
 Fri, 27 Dec 2024 14:27: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 1tRBJ5-0005IE-Vl
 for xen-devel@lists.xenproject.org; Fri, 27 Dec 2024 14:27:15 +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 a9b7699e-c45e-11ef-99a3-01e77a169b0f;
 Fri, 27 Dec 2024 15:27:12 +0100 (CET)
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3862f32a33eso3357943f8f.3
 for ; Fri, 27 Dec 2024 06:27: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-38a412f778esm7175399f8f.4.2024.12.27.06.27.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 27 Dec 2024 06:27: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: a9b7699e-c45e-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1735309632; x=1735914432; 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=BK+vgjvSDgpccyofTB5YeJUtbMDWpp/knxY+zLZnRZo=;
        b=A2Rm3PTUJnWHNm+2/FOJuwRzonTn53y7M0z1Xt1J2rI5Yh8Oaxuzkotv9uJrgwGUyJ
         rFPhypvfZieL47+p0BduV3X7tJJRcOr1HID4i9dx9EKpX5uYz5v1mGwTQUhtqswGQ2iM
         +uSyAhF4SX9W40jU2R4IfLyJfNtYXkLBJULAWYgssclVAkc449m1BHTUREv9G2yMtKp2
         e8nZFfgS/b/t5pslQxANlnv1OGXD3CiWBOTseunkkvYycQlxOOzxcxMz4YIiepn5kiZF
         IlH4odJ6kP1iy3eGhVgS+vJ1iuYjCP7FAEI4r7EeHVqr2UEMMFWX/qMLvLGibvyTJDoE
         gvXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735309632; x=1735914432;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=BK+vgjvSDgpccyofTB5YeJUtbMDWpp/knxY+zLZnRZo=;
        b=uJX350zlWMFXdRsKhgzu848llpey7ShHq8HMqpHQnkHhMYRsDYg8dwEWyfM6HVog5V
         F6dsPfE7vJYcrA/HTrLItjD2+HLK0w37ZDPx7phPIpBj2ZjFggz60kRZBtfiJIhHNx9K
         zAQE+0WIklk6dsqW2d9DgB9Ov1zuxLsRfFM2JOXJ99YeccD2HOJ2JjmKgD3G7Y2kSfZC
         70pCrBbTJOyRISFLvLYmfuUttw9LN41mE1OPXQVPwi/mKdEOMwA7UirxbMs8uLbfOAlk
         pYvhLbuq+e74gHpYCF1DSiFy0ZIiVAXEyQMcxfSYoH8gb9wqy7AXG0O0nWChGWQQ7RIg
         D3rg==
X-Forwarded-Encrypted: i=1; AJvYcCUrtq4NcxekVvGLcn1U3cspZvJa7s5rdR6HdJoGB2Gkvfem7z3wR0gDTR4b55VKuCoUwc6l4QgG07c=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxW1DIC79vuO7IbMIzK/tyM2BFvVBlYXswk1hAzfimK0Uus1iYr
	7MyAFgKiqaHwim4k+icTmPBsr4kKzsUxTJ1gLlE5Ax6PMZmKyKSSZU9U4g6dgw==
X-Gm-Gg: ASbGncsfkcG8xOWnhh4P1JbSVf0rp9tWSsKp/C0rZfKShBeXMjDC0OI31OOy0Tvhrrk
	kH2YKJkA8HtcttGlk7jkpiN9HeiUjYlCEyHK7lhvi38SdjlhiSAR160b6h+ZKoxpSCFpERUP+ly
	3Ss99LmPWV/DyvnITZFP1EFvHSrLuG8MaktMoXuuiLBLARO2GR+4tN3SVWDZw58BS1EEiq5pkah
	36AewATzuMQpT24cZgt+emUwvxJukV58bweI+RXI3mGFCSxFH4lOLIMXSebx6wdE09Ixxo3K4wK
	KniHDvWQPXUKbt0s5AtQ5m3arLTx9G/aD5hGFZAl2Q==
X-Google-Smtp-Source: AGHT+IFiNAXKez1faEYIXGDL18sVjFN/hLRyX3OJ2TAqTGLUg4jnHXRM8VvDgfkLaom2JPiyQmAglQ==
X-Received: by 2002:adf:b511:0:b0:38a:372b:ff2c with SMTP id ffacd0b85a97d-38a372bff53mr8533514f8f.17.1735309632065;
        Fri, 27 Dec 2024 06:27:12 -0800 (PST)
Message-ID: <65903263-efd3-48a3-8e71-909afaf0b6d6@suse.com>
Date: Fri, 27 Dec 2024 15:27:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/1] libacpi/Makefile: clear ASL warning about PCI0
To: Ariel Otilibili 
Cc: Anthony PERARD , xen-devel@lists.xenproject.org
References: <20241222161444.1558599-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241222161444.1558599-2-Ariel.Otilibili-Anieli@eurecom.fr>
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: <20241222161444.1558599-2-Ariel.Otilibili-Anieli@eurecom.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22.12.2024 17:10, Ariel Otilibili wrote:
> iasl has one ID per warning [6]; subsequent commits will address other ASL warnings.
> 
> ```
> $ awk 'NR>533 && NR<556 {print NR ":" $0}' source/compiler/aslmethod.c
> 534:    case PARSEOP_DEVICE:
> 535:
> 536:        /* Check usage of _HID and _ADR objects */
> 537:
> 538:        HidExists = ApFindNameInDeviceTree (METHOD_NAME__HID, Op);
> 539:        AdrExists = ApFindNameInDeviceTree (METHOD_NAME__ADR, Op);
> 540:
> 541:        if (!HidExists && !AdrExists)
> 542:        {
> 543:            AslError (ASL_ERROR, ASL_MSG_MISSING_DEPENDENCY, Op,
> 544:                "Device object requires a _HID or _ADR");
> 545:        }
> 546:        else if (HidExists && AdrExists)
> 547:        {
> 548:            /*
> 549:             * According to the ACPI spec, "A device object must contain
> 550:             * either an _HID object or an _ADR object, but should not contain
> 551:             * both".
> 552:             */
> 553:            AslError (ASL_WARNING, ASL_MSG_MULTIPLE_TYPES, Op,
> 554:                "Device object requires either a _HID or _ADR, but not both");
> 555:        }
> 
> $ awk 'NR>188 && NR<206 || NR==432 || /ASL_MSG_MULTIPLE_TYPES/ {print NR ":" $0}' source/compiler/aslmessages.h
> 189:/*
> 190: * Values (message IDs) for all compiler messages. There are currently
> 191: * three distinct blocks of error messages (so that they can be expanded
> 192: * individually):
> 193: *      Main ASL compiler
> 194: *      Data Table compiler
> 195: *      Preprocessor
> 196: *
> 197: * NOTE1: This list must match the tables of message strings in the file
> 198: * aslmessages.c exactly.
> 199: *
> 200: * NOTE2: With the introduction of the -vw option to disable specific
> 201: * messages, new messages should only be added to the end of these
> 202: * lists, so that values for existing messages are not disturbed.
> 203: */
> 204:typedef enum
> 205:{
> 280:    ASL_MSG_MULTIPLE_TYPES,
> 432:} ASL_MESSAGE_IDS;

>From this I can't conclude that the same message ID (ASL_MSG_MULTIPLE_TYPES
here) can't (in principle) be used in multiple places, for similar purposes.
Pretty certainly we want to avoid disabling unrelated warnings elsewhere
(including ones only to be surfaced by future versions of iasl).

> --- a/tools/libacpi/Makefile
> +++ b/tools/libacpi/Makefile
> @@ -21,6 +21,8 @@ H_SRC += $(addprefix $(ACPI_BUILD_DIR)/, ssdt_tpm.h ssdt_tpm2.h ssdt_laptop_slat
>  MKDSDT_CFLAGS-$(CONFIG_ARM_64) = -DCONFIG_ARM_64
>  MKDSDT_CFLAGS-$(CONFIG_X86) = -DCONFIG_X86
>  
> +IASL_WARNS=3073

If we were to go this route, the variable name better would make clear that
this is a list of warnings to be disabled.

And then instead of ...

> @@ -32,7 +34,7 @@ TMP_SUFFIX	= tmp
>  all: $(C_SRC) $(H_SRC)
>  
>  $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl
> -	$(IASL) -vs -p $(ACPI_BUILD_DIR)/$*.$(TMP_SUFFIX) -tc $<
> +	$(IASL) $(IASL_WARNS:%=-vw%) -vs -p $(ACPI_BUILD_DIR)/$*.$(TMP_SUFFIX) -tc $<
>  	sed -e 's/AmlCode/$*/g' -e 's/_aml_code//g' $(ACPI_BUILD_DIR)/$*.hex >$@
>  	rm -f $(addprefix $(ACPI_BUILD_DIR)/, $*.aml $*.hex)
>   
> @@ -65,7 +67,7 @@ $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.asl: $(MK_DSDT)
>  	mv -f $@.$(TMP_SUFFIX) $@
>  
>  $(C_SRC): $(ACPI_BUILD_DIR)/%.c: $(ACPI_BUILD_DIR)/%.asl
> -	$(IASL) -vs -p $(ACPI_BUILD_DIR)/$*.$(TMP_SUFFIX) -tc $<
> +	$(IASL) $(IASL_WARNS:%=-vw%) -vs -p $(ACPI_BUILD_DIR)/$*.$(TMP_SUFFIX) -tc $<
>  	sed -e 's/AmlCode/$*/g' -e 's/_aml_code//g' $(ACPI_BUILD_DIR)/$*.hex > $@.$(TMP_SUFFIX)
>  	echo "int $*_len=sizeof($*);" >> $@.$(TMP_SUFFIX)
>  	mv -f $@.$(TMP_SUFFIX) $@

... continuing to need to alter two places, I guess we'd be better off
introducing IASL_FLAGS or some such, where the -vs then could also go.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Dec 27 14:34:44 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Dec 2024 14:34:44 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863442.1274857 (Exim 4.92)
	(envelope-from )
	id 1tRBQF-0007Hq-KZ; Fri, 27 Dec 2024 14:34:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863442.1274857; Fri, 27 Dec 2024 14:34: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 1tRBQF-0007Hj-Gm; Fri, 27 Dec 2024 14:34:39 +0000
Received: by outflank-mailman (input) for mailman id 863442;
 Fri, 27 Dec 2024 14:34:38 +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 1tRBQE-0007Hd-9m
 for xen-devel@lists.xenproject.org; Fri, 27 Dec 2024 14:34:38 +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 b237b88c-c45f-11ef-99a3-01e77a169b0f;
 Fri, 27 Dec 2024 15:34:36 +0100 (CET)
Received: by mail-wr1-x434.google.com with SMTP id
 ffacd0b85a97d-385e3621518so3412489f8f.1
 for ; Fri, 27 Dec 2024 06:34:36 -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-38a1c848a47sm22075282f8f.62.2024.12.27.06.34.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 27 Dec 2024 06:34: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: b237b88c-c45f-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=suse.com; s=google; t=1735310076; x=1735914876; 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=6V3D5WZDehBaxCmvKw467CN62gjUjp0x+68Uq5ioTEQ=;
        b=dWDfcA9xHAY/7dobUKm7SU6rppb48sRCof+JOwUAy3wcvYgdTABYARUyD7OIQWXes6
         a1qYNIOhMS4UxFU4zy16Ff9Nd2+cLQaxRw5tsJqNqVv6q88rJYZxUKqmOimNYcM9wjZf
         SjLiJKkIQ29tKNkqXE0ET7OiTzFYEwrn1rWLpfjgfjPYpJAI3NI4HOsBbZTLkcrNu8ki
         sqRiht9LM/gCUiaIoMCBlw92y6wpqHnRIwr2taO/LF8rawhZUEoD8jrLLxONiTA4Va2v
         tnUDBGLZ2b5PidgbAKopdIbsWxW5rTdAW0u6eE5uvxmOSSwrL6Umv8OAv/oSUj4BPYRe
         FBrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735310076; x=1735914876;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6V3D5WZDehBaxCmvKw467CN62gjUjp0x+68Uq5ioTEQ=;
        b=GWydjeAllUHl3MiVSIiJqmJjnmeI+ZtYhzHhYEUzHKIyouheGLO7quliqo1gEJnwxO
         EQnymEC0YGs+RGfwBOV22vAbH09Hb+LcE9FyIuKZHIdEXFL8uDnthP7i5eqEUGNJQlW+
         Lp36lSYddq29RhpcPdGEJ4bAzzMnNRJn1Q5N+G8f9LvXo7t1gLo+DERYUmzH2J2RktWn
         GvUmE44FaAFfGmbV2IIL3D2sppISeTI+A9Bb1oCB/p/t+5JsxvvUNMAObvxVBpfcuJ/T
         QcGtuwHjD04OdyOKUp/qiMirU7vO+Ys7n+a5NKY7vH4zoRXGvREwgCxRk3WEs+NpX5UC
         JQwQ==
X-Forwarded-Encrypted: i=1; AJvYcCXh+dLrXuM4lRDuZICO8nStBBTCZ1wlUkJ4mMdMbhNx/HRjYc3+D5R+HK1WIUAmoC0h7qQLBtakiJk=@lists.xenproject.org
X-Gm-Message-State: AOJu0Yxvvp/CxGtHhMAYQ+4owAdmckgN/9KSkUQguUzSLs63ek/cF+8b
	VGjBGTUCkHRGt+XB0zMo+rCZ3czsG1i60RCtfKkcKUNXOe7hjGlPKNwL52sYEw==
X-Gm-Gg: ASbGnctbtPfRY/MpN3Ns3ASMTnUXO8gsxph635V/e0b5Azc5LOXRoM0g7Cu/r0AGpfb
	t3afoH0ruLu0mdwkIQYU5gn9sKFkTosIxS6EBAaiqKumfUI3Ro3mJzkVMcqCoJrDJeiRvXmb9kx
	kBbJomktroTSVQ5mbT9wbzgSOgB7H658eRBAB1cWoc5+xd20t6H69IwY6iPneXIommWaRbjVcuF
	Ox/l5tDQ2PJVa2aVJKn7/oRusONstZVR86QHdWV/Lrrapk1lq9k7wB0Ynym7/PYCuYAlJy7J/9X
	5tb93JEIecWs1C+V4fk/K5h5BR86CWO3eRtFcyzfEQ==
X-Google-Smtp-Source: AGHT+IEJoSEzBBK18680/01g1l2aUwqWvDl/KjPOloc2zIqE4/nwdSB6BwLD5+m9xuVjil/8r+NUkg==
X-Received: by 2002:a5d:6f01:0:b0:386:3dad:8147 with SMTP id ffacd0b85a97d-38a221f9ed6mr17745870f8f.32.1735310075685;
        Fri, 27 Dec 2024 06:34:35 -0800 (PST)
Message-ID: <735f8d30-5f42-4fa6-acb0-f82b5b759183@suse.com>
Date: Fri, 27 Dec 2024 15:34:33 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH v2] xen: introduce kconfig options to disable
 hypercalls
To: Sergiy Kibrik 
Cc: Stefano Stabellini ,
 Julien Grall , Bertrand Marquis ,
 Michal Orzel ,
 Volodymyr Babchuk ,
 Anthony PERARD ,
 =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= ,
 Stefano Stabellini ,
 Andrew Cooper , xen-devel@lists.xenproject.org
References: <20241219092917.3006174-1-Sergiy_Kibrik@epam.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: <20241219092917.3006174-1-Sergiy_Kibrik@epam.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.12.2024 10:29, Sergiy Kibrik wrote:
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -74,12 +74,12 @@ obj-y += hpet.o
>  obj-y += vm_event.o
>  obj-y += xstate.o
>  
> -ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
> -obj-y += domctl.o
> +obj-$(CONFIG_DOMCTL) += domctl.o
> +ifeq ($(CONFIG_PLATFORM_OP),y)
>  obj-y += platform_hypercall.o
>  obj-$(CONFIG_COMPAT) += x86_64/platform_hypercall.o
> -obj-y += sysctl.o
>  endif

Personally I'd prefer if we avoided ifeq here:

obj-$(CONFIG_PLATFORM_OP) += platform_hypercall.o
obj-$(filter $(CONFIG_COMPAT),$(CONFIG_PLATFORM_OP)) += x86_64/platform_hypercall.o

Yet I realize this (once again) may be contentious.

> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -516,4 +516,33 @@ config TRACEBUFFER
>  	  to be collected at run time for debugging or performance analysis.
>  	  Memory and execution overhead when not active is minimal.
>  
> +menu "Supported hypercall interfaces"
> +	visible if DOM0LESS_BOOT && EXPERT
> +
> +config SYSCTL
> +	bool "Enable sysctl hypercall"
> +	depends on !PV_SHIM_EXCLUSIVE
> +	default y
> +
> +config DOMCTL
> +	bool "Enable domctl hypercalls"
> +	depends on !PV_SHIM_EXCLUSIVE
> +	default y
> +
> +config HVM_OP
> +	bool "Enable HVM hypercalls"
> +	depends on HVM
> +	default y
> +
> +config PLATFORM_OP
> +	bool "Enable platform hypercalls"
> +	depends on !PV_SHIM_EXCLUSIVE
> +	default y

Just to re-iterate an earlier comment: Andrew (imo validly) raised concern of
such negative dependencies. As said before, imo we'd better resolve that before
extending the issue (whether by the patch I once sent or something else is then
secondary).

> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -66,10 +66,10 @@ obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo un
>  obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o)
>  
>  ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
> -obj-y += domctl.o
>  obj-y += monitor.o
> -obj-y += sysctl.o
>  endif
> +obj-$(CONFIG_DOMCTL) += domctl.o
> +obj-$(CONFIG_SYSCTL) += sysctl.o

These two then want to move back up into their normal slots.

Jan


From xen-devel-bounces@lists.xenproject.org Fri Dec 27 22:03:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Dec 2024 22:03:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863458.1274867 (Exim 4.92)
	(envelope-from )
	id 1tRIPw-0002K8-S3; Fri, 27 Dec 2024 22:02:48 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863458.1274867; Fri, 27 Dec 2024 22:02: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 1tRIPw-0002K0-Mv; Fri, 27 Dec 2024 22:02:48 +0000
Received: by outflank-mailman (input) for mailman id 863458;
 Fri, 27 Dec 2024 22:02: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 1tRIPv-0002Ju-53
 for xen-devel@lists.xenproject.org; Fri, 27 Dec 2024 22:02:47 +0000
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 4c4c76af-c49e-11ef-99a3-01e77a169b0f;
 Fri, 27 Dec 2024 23:02:44 +0100 (CET)
Received: from quovadis.eurecom.fr ([10.3.2.233])
 by drago1i.eurecom.fr with ESMTP; 27 Dec 2024 23:02:43 +0100
X-BeenThere: xen-devel@lists.xenproject.org
List-Id: Xen developer discussion 
List-Unsubscribe: ,
 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Errors-To: xen-devel-bounces@lists.xenproject.org
Precedence: list
Sender: "Xen-devel" 
X-Inumbo-ID: 4c4c76af-c49e-11ef-99a3-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=eurecom.fr; i=@eurecom.fr; q=dns/txt; s=default;
  t=1735336964; x=1766872964;
  h=from:in-reply-to:references:date:cc:to:mime-version:
   message-id:subject:content-transfer-encoding;
  bh=iWh9tFCT0lDPpRN72XPJ9AOSKZ+diQ9xBOEt7P/uiFI=;
  b=jnK5NQ41phAFe63Iok3Y+qSZXaGiu2LQTSTn7ab1HkoswYJPgG1F7Ubw
   uOhEY4+mPNqfjm2TyuDX+p8p1KX5SrBK2zxhogl6odZAPmkVA0PQGNkbk
   mCSvdhSMZgbaXB75T4vhthRSC71lsTIOe4vTogoPinIux8Lm9pzc50u7Z
   M=;
X-CSE-ConnectionGUID: 4ZXccBGDRxqMOj3qAAsBYg==
X-CSE-MsgGUID: a+HA1IRMTqSM0HFTboKd4Q==
X-IronPort-AV: E=Sophos;i="6.12,269,1728943200"; 
   d="scan'208";a="28331679"
From: "Ariel Otilibili-Anieli" 
In-Reply-To: <65903263-efd3-48a3-8e71-909afaf0b6d6@suse.com>
Content-Type: text/plain; charset="utf-8"
X-Forward: 88.183.119.157
References: <20241222161444.1558599-1-Ariel.Otilibili-Anieli@eurecom.fr>
 <20241222161444.1558599-2-Ariel.Otilibili-Anieli@eurecom.fr> <65903263-efd3-48a3-8e71-909afaf0b6d6@suse.com>
Date: Fri, 27 Dec 2024 23:02:43 +0100
Cc: "Anthony PERARD" , xen-devel@lists.xenproject.org
To: "Jan Beulich" 
MIME-Version: 1.0
Message-ID: <2f7a86-676f2400-8f41-26131fc0@197006440>
Subject: =?utf-8?q?Re=3A?= [PATCH v3 1/1] =?utf-8?q?libacpi/Makefile=3A?= clear ASL 
 warning about PCI0
User-Agent: SOGoMail 5.11.1
Content-Transfer-Encoding: quoted-printable
Content-Length: 4814

On Friday, December 27, 2024 15:27 CET, Jan Beulich =
 wrote:

> On 22.12.2024 17:10, Ariel Otilibili wrote:
> > iasl has one ID per warning [6]; subsequent commits will address ot=
her ASL warnings.
> >=20
> > ```
> > $ awk 'NR>533 && NR<556 {print NR ":" $0}' source/compiler/aslmetho=
d.c
> > 534:    case PARSEOP=5FDEVICE:
> > 535:
> > 536:        /* Check usage of =5FHID and =5FADR objects */
> > 537:
> > 538:        HidExists =3D ApFindNameInDeviceTree (METHOD=5FNAME=5F=5F=
HID, Op);
> > 539:        AdrExists =3D ApFindNameInDeviceTree (METHOD=5FNAME=5F=5F=
ADR, Op);
> > 540:
> > 541:        if (!HidExists && !AdrExists)
> > 542:        {
> > 543:            AslError (ASL=5FERROR, ASL=5FMSG=5FMISSING=5FDEPEND=
ENCY, Op,
> > 544:                "Device object requires a =5FHID or =5FADR");
> > 545:        }
> > 546:        else if (HidExists && AdrExists)
> > 547:        {
> > 548:            /*
> > 549:             * According to the ACPI spec, "A device object mus=
t contain
> > 550:             * either an =5FHID object or an =5FADR object, but=
 should not contain
> > 551:             * both".
> > 552:             */
> > 553:            AslError (ASL=5FWARNING, ASL=5FMSG=5FMULTIPLE=5FTYP=
ES, Op,
> > 554:                "Device object requires either a =5FHID or =5FA=
DR, but not both");
> > 555:        }
> >=20
> > $ awk 'NR>188 && NR<206 || NR=3D=3D432 || /ASL=5FMSG=5FMULTIPLE=5FT=
YPES/ {print NR ":" $0}' source/compiler/aslmessages.h
> > 189:/*
> > 190: * Values (message IDs) for all compiler messages. There are cu=
rrently
> > 191: * three distinct blocks of error messages (so that they can be=
 expanded
> > 192: * individually):
> > 193: *      Main ASL compiler
> > 194: *      Data Table compiler
> > 195: *      Preprocessor
> > 196: *
> > 197: * NOTE1: This list must match the tables of message strings in=
 the file
> > 198: * aslmessages.c exactly.
> > 199: *
> > 200: * NOTE2: With the introduction of the -vw option to disable sp=
ecific
> > 201: * messages, new messages should only be added to the end of th=
ese
> > 202: * lists, so that values for existing messages are not disturbe=
d.
> > 203: */
> > 204:typedef enum
> > 205:{
> > 280:    ASL=5FMSG=5FMULTIPLE=5FTYPES,
> > 432:} ASL=5FMESSAGE=5FIDS;
>=20
> From this I can't conclude that the same message ID (ASL=5FMSG=5FMULT=
IPLE=5FTYPES
> here) can't (in principle) be used in multiple places, for similar pu=
rposes.
> Pretty certainly we want to avoid disabling unrelated warnings elsewh=
ere
> (including ones only to be surfaced by future versions of iasl).
>=20

In principle, the same ID won=E2=80=99t be used twice. Though I will pu=
sh a PR to the project sometime next year. So far ASL=5FMSG=5FMULTIPLE=5F=
TYPES has been used once, I will ask the ID be made specific about =5FH=
ID and =5FADR.

I did open a PR that clarifies, from which has the MUST been enforced, =
ACPI 6.3 Errata A [1].

[1] https://github.com/acpica/acpica/pull/992
> > --- a/tools/libacpi/Makefile
> > +++ b/tools/libacpi/Makefile
> > @@ -21,6 +21,8 @@ H=5FSRC +=3D $(addprefix $(ACPI=5FBUILD=5FDIR)/, =
ssdt=5Ftpm.h ssdt=5Ftpm2.h ssdt=5Flaptop=5Fslat
> >  MKDSDT=5FCFLAGS-$(CONFIG=5FARM=5F64) =3D -DCONFIG=5FARM=5F64
> >  MKDSDT=5FCFLAGS-$(CONFIG=5FX86) =3D -DCONFIG=5FX86
> > =20
> > +IASL=5FWARNS=3D3073
>=20
> If we were to go this route, the variable name better would make clea=
r that
> this is a list of warnings to be disabled.

Sure, Jan.
>=20
> And then instead of ...
>=20
> > @@ -32,7 +34,7 @@ TMP=5FSUFFIX	=3D tmp
> >  all: $(C=5FSRC) $(H=5FSRC)
> > =20
> >  $(H=5FSRC): $(ACPI=5FBUILD=5FDIR)/%.h: %.asl
> > -	$(IASL) -vs -p $(ACPI=5FBUILD=5FDIR)/$*.$(TMP=5FSUFFIX) -tc $<
> > +	$(IASL) $(IASL=5FWARNS:%=3D-vw%) -vs -p $(ACPI=5FBUILD=5FDIR)/$*.=
$(TMP=5FSUFFIX) -tc $<
> >  	sed -e 's/AmlCode/$*/g' -e 's/=5Faml=5Fcode//g' $(ACPI=5FBUILD=5F=
DIR)/$*.hex >$@
> >  	rm -f $(addprefix $(ACPI=5FBUILD=5FDIR)/, $*.aml $*.hex)
> >  =20
> > @@ -65,7 +67,7 @@ $(ACPI=5FBUILD=5FDIR)/dsdt=5Fanycpu=5Farm.asl: $(=
MK=5FDSDT)
> >  	mv -f $@.$(TMP=5FSUFFIX) $@
> > =20
> >  $(C=5FSRC): $(ACPI=5FBUILD=5FDIR)/%.c: $(ACPI=5FBUILD=5FDIR)/%.asl
> > -	$(IASL) -vs -p $(ACPI=5FBUILD=5FDIR)/$*.$(TMP=5FSUFFIX) -tc $<
> > +	$(IASL) $(IASL=5FWARNS:%=3D-vw%) -vs -p $(ACPI=5FBUILD=5FDIR)/$*.=
$(TMP=5FSUFFIX) -tc $<
> >  	sed -e 's/AmlCode/$*/g' -e 's/=5Faml=5Fcode//g' $(ACPI=5FBUILD=5F=
DIR)/$*.hex > $@.$(TMP=5FSUFFIX)
> >  	echo "int $*=5Flen=3Dsizeof($*);" >> $@.$(TMP=5FSUFFIX)
> >  	mv -f $@.$(TMP=5FSUFFIX) $@
>=20
> ... continuing to need to alter two places, I guess we'd be better of=
f
> introducing IASL=5FFLAGS or some such, where the -vs then could also =
go.
>=20

Thanks for the feedback, Jan. Sometime next year I will push a new vers=
ion. My best regards to you and your dear ones.
> Jan



From xen-devel-bounces@lists.xenproject.org Mon Dec 30 06:31:38 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Dec 2024 06:31:38 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863498.1274877 (Exim 4.92)
	(envelope-from )
	id 1tS9It-0003Py-Gi; Mon, 30 Dec 2024 06:31:03 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863498.1274877; Mon, 30 Dec 2024 06:31: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 1tS9It-0003Pg-A5; Mon, 30 Dec 2024 06:31:03 +0000
Received: by outflank-mailman (input) for mailman id 863498;
 Mon, 30 Dec 2024 06:31: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 1tS9Is-0003PY-Ak
 for xen-devel@lists.xenproject.org; Mon, 30 Dec 2024 06:31:02 +0000
Received: from fforwardh-b1-smtp.messagingengine.com
 (fforwardh-b1-smtp.messagingengine.com [202.12.124.196])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id a13c5401-c677-11ef-99a4-01e77a169b0f;
 Mon, 30 Dec 2024 07:30:59 +0100 (CET)
Received: from phl-compute-03.internal (phl-compute-03.phl.internal
 [10.202.2.43])
 by mailfforwardh.stl.internal (Postfix) with ESMTP id 34C6D1740216;
 Mon, 30 Dec 2024 01:30:57 -0500 (EST)
Received: from phl-frontend-01 ([10.202.2.160])
 by phl-compute-03.internal (MEProxy); Mon, 30 Dec 2024 01:30:57 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 30 Dec 2024 01:30: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: a13c5401-c677-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	: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=fm2; t=
	1735540257; x=1735626657; bh=47jPvvLrAreNHOM7qNJpTbX/D3BrAJfjIZq
	o8xSBXtM=; b=OPtTCuxm5oHeN1+Tu4tCmEn4yWG9YooqkUqK5J2nfvceb4vA8Jm
	up5xP1rYU9w2e3tcGbfRFBSpspa6kt5lPWFP1UJmeMYy14gDeGbU0M/bJ/l4zpC/
	0e/4XYc2xkwFi3vKgs30UDDZoE11QYFhJaosdDWDenHzFSX/0k1tqn01dsheFbfc
	vUauj3T+IM3lEjlREaNImlg9331XsZDUYLpGigaKaayFYAwnmJW/Gskp46+a9Mj5
	NQ37WlGt8dDHUldXqs4129aLzM/GXHI5XgDS5OlQYsWDAbLwgBNjsT3NMWAZvrjs
	dg9Oth9P3UbQN2l9Wgmo86kDu15qka5eUHA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddruddvhedgleehucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
    rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
    htshculddquddttddmnecujfgurhephffvvefufffkofgggfestdekredtredttdenucfh
    rhhomhepufgvrhhgihihucfmihgsrhhikhcuoefuvghrghhihigpmfhisghrihhksegvph
    grmhdrtghomheqnecuggftrfgrthhtvghrnhepffffvdeifeeijefhheefuedvvedtheff
    jeeiveehgfettedvgedujefgudejgedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrg
    hrrghmpehmrghilhhfrhhomhepshgrkhhisgesuggrrhhkshhtrghrrdhsihhtvgdpnhgs
    pghrtghpthhtohepudehpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopeigvghnqd
    guvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopehs
    thgvfhgrnhhordhsthgrsggvlhhlihhnihesrghmugdrtghomhdprhgtphhtthhopehssh
    htrggsvghllhhinhhisehkvghrnhgvlhdrohhrghdprhgtphhtthhopehjuhhlihgvnhes
    gigvnhdrohhrghdprhgtphhtthhopegsvghrthhrrghnugdrmhgrrhhquhhishesrghrmh
    drtghomhdprhgtphhtthhopehmihgthhgrlhdrohhriigvlhesrghmugdrtghomhdprhgt
    phhtthhopehvohhlohguhihmhihrpggsrggstghhuhhksegvphgrmhdrtghomhdprhgtph
    htthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthht
    oheprghnthhhohhnhidrphgvrhgrrhgusehvrghtvghsrdhtvggthh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: if569265f:Fastmail
From: Sergiy Kibrik 
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
	Stefano Stabellini ,
	Julien Grall ,
	Bertrand Marquis ,
	Michal Orzel ,
	Volodymyr Babchuk ,
	Andrew Cooper ,
	Anthony PERARD ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Tamas K Lengyel ,
	Alexandru Isaila ,
	Petre Pircalabu ,
	Sergiy Kibrik 
Subject: [XEN PATCH v1] xen: mem_access: conditionally compile vm_event.c & monitor.c
Date: Mon, 30 Dec 2024 08:30:51 +0200
Message-Id: <20241230063051.3332332-1-Sergiy_Kibrik@epam.com>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Stefano Stabellini 

Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM events
and monitoring support optional.
This is to reduce code size on Arm when this option isn't enabled.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Sergiy Kibrik 
---
 xen/arch/arm/Makefile      |  4 ++--
 xen/arch/arm/vsmc.c        |  3 ++-
 xen/common/Makefile        |  4 ++--
 xen/include/xen/monitor.h  |  9 +++++++++
 xen/include/xen/vm_event.h | 14 +++++++++++---
 5 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 43ab5e8f25..8903eb0bf2 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -39,7 +39,7 @@ obj-$(CONFIG_LIVEPATCH) += livepatch.o
 obj-$(CONFIG_LLC_COLORING) += llc-coloring.o
 obj-$(CONFIG_MEM_ACCESS) += mem_access.o
 obj-y += mm.o
-obj-y += monitor.o
+obj-$(CONFIG_MEM_ACCESS) += monitor.o
 obj-y += p2m.o
 obj-y += platform.o
 obj-y += platform_hypercall.o
@@ -65,7 +65,7 @@ obj-$(CONFIG_VGICV2) += vgic-v2.o
 obj-$(CONFIG_GICV3) += vgic-v3.o
 obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
 endif
-obj-y += vm_event.o
+obj-$(CONFIG_MEM_ACCESS) += vm_event.o
 obj-y += vtimer.o
 obj-$(CONFIG_SBSA_VUART_CONSOLE) += vpl011.o
 obj-y += vsmc.o
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 62d8117a12..1c13326bdf 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -330,7 +330,8 @@ void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
     }
 
     /* If monitor is enabled, let it handle the call. */
-    if ( current->domain->arch.monitor.privileged_call_enabled )
+    if ( IS_ENABLED(CONFIG_MEM_ACCESS) &&
+         current->domain->arch.monitor.privileged_call_enabled )
         rc = monitor_smc();
 
     if ( rc == 1 )
diff --git a/xen/common/Makefile b/xen/common/Makefile
index cba3b32733..e3c6a857ab 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -54,7 +54,7 @@ obj-y += timer.o
 obj-$(CONFIG_TRACEBUFFER) += trace.o
 obj-y += version.o
 obj-y += virtual_region.o
-obj-y += vm_event.o
+obj-$(CONFIG_MEM_ACCESS) += vm_event.o
 obj-$(CONFIG_HAS_VMAP) += vmap.o
 obj-y += vsprintf.o
 obj-y += wait.o
@@ -68,7 +68,7 @@ obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o
 
 ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y)
 obj-y += domctl.o
-obj-y += monitor.o
+obj-$(CONFIG_MEM_ACCESS) += monitor.o
 obj-y += sysctl.o
 endif
 
diff --git a/xen/include/xen/monitor.h b/xen/include/xen/monitor.h
index 713d54f7c1..f1359abb94 100644
--- a/xen/include/xen/monitor.h
+++ b/xen/include/xen/monitor.h
@@ -27,8 +27,17 @@
 struct domain;
 struct xen_domctl_monitor_op;
 
+#ifdef CONFIG_MEM_ACCESS
 int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop);
 void monitor_guest_request(void);
+#else
+static inline int monitor_domctl(struct domain *d,
+                                 struct xen_domctl_monitor_op *mop)
+{
+    return -EINVAL;
+}
+static inline void monitor_guest_request(void) {}
+#endif
 
 int monitor_traps(struct vcpu *v, bool sync, vm_event_request_t *req);
 
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index 9a86358b42..72e720e378 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -50,9 +50,6 @@ struct vm_event_domain
     unsigned int last_vcpu_wake_up;
 };
 
-/* Clean up on domain destruction */
-void vm_event_cleanup(struct domain *d);
-
 /* Returns whether a ring has been set up */
 bool vm_event_check_ring(struct vm_event_domain *ved);
 
@@ -88,7 +85,18 @@ void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *ved);
 void vm_event_put_request(struct domain *d, struct vm_event_domain *ved,
                           vm_event_request_t *req);
 
+#ifdef CONFIG_MEM_ACCESS
+/* Clean up on domain destruction */
+void vm_event_cleanup(struct domain *d);
 int vm_event_domctl(struct domain *d, struct xen_domctl_vm_event_op *vec);
+#else
+static inline void vm_event_cleanup(struct domain *d) {}
+static inline int vm_event_domctl(struct domain *d,
+                                  struct xen_domctl_vm_event_op *vec)
+{
+    return -EINVAL;
+}
+#endif
 
 void vm_event_vcpu_pause(struct vcpu *v);
 void vm_event_vcpu_unpause(struct vcpu *v);
-- 
2.25.1



From xen-devel-bounces@lists.xenproject.org Mon Dec 30 11:11:08 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Dec 2024 11:11:08 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863516.1274887 (Exim 4.92)
	(envelope-from )
	id 1tSDfd-0000eT-S6; Mon, 30 Dec 2024 11:10:49 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863516.1274887; Mon, 30 Dec 2024 11:10: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 1tSDfd-0000eB-Ml; Mon, 30 Dec 2024 11:10:49 +0000
Received: by outflank-mailman (input) for mailman id 863516;
 Mon, 30 Dec 2024 11:10: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 1tSDfc-0000e5-8Y
 for xen-devel@lists.xenproject.org; Mon, 30 Dec 2024 11:10:48 +0000
Received: from NAM12-BN8-obe.outbound.protection.outlook.com
 (mail-bn8nam12on2061f.outbound.protection.outlook.com
 [2a01:111:f403:2418::61f])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id b64ba6c9-c69e-11ef-99a4-01e77a169b0f;
 Mon, 30 Dec 2024 12:10:44 +0100 (CET)
Received: from MW4PR12MB7334.namprd12.prod.outlook.com (2603:10b6:303:219::21)
 by PH7PR12MB5926.namprd12.prod.outlook.com (2603:10b6:510:1d9::8)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8293.18; Mon, 30 Dec
 2024 11:10:37 +0000
Received: from MW4PR12MB7334.namprd12.prod.outlook.com
 ([fe80::2e77:557:17d5:86f8]) by MW4PR12MB7334.namprd12.prod.outlook.com
 ([fe80::2e77:557:17d5:86f8%7]) with mapi id 15.20.8293.000; Mon, 30 Dec 2024
 11:10: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: b64ba6c9-c69e-11ef-99a4-01e77a169b0f
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rsq1FaqOgxoTzT0fDM/T3HCzu3uPtz2v5jRVVQTtSTV7K4oAt7dQKbGTwatugO2xJRqGYp+Ow+kZZIyiml+ujMXcanjjiayqDCWP6kYYaqP9Rd14VU8uMfiMUxTimLiwyIhdnn393XEbdZ8/jzr6t5zLoP0UEzcv1/+GCXHNBrd1wU6Ma0pTOMTDIYnnlHyrD6rHtvqwkq1t1C546sVhMlTCrqlC6GBcqUmdjUD7cGk9pwiPGbT1BEoPAEefsimVHHRKB+lmXsxIHlsjNb1qkc67f+hjFfZe/h8J7nkfRxrTnTT9t1mGloRDEZ+LDVL5CvMK611W9ZZA23llygq7UQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=5UVhejHqxEzhbFwNr0JP6tJ8LiLWKLfLpzm4C5uK/3k=;
 b=VVsuzcSOn93E+t/O1YphtkZJJMs9h0k9JJoEoBy1qjyHwzcPXfcK48mI05ap0CkyuyBKeUl4vinjEoayy/Jqt/VIccVrgEzfbY7e4swSnao570/CKymZm0/+K7B6Pgr0uVfsWPZiLFDfWm9UCFHz2WbxiD2P7buyMkKFrsjVBOXTfM6f0bPdkfpoztB5oxhYi6cYSmNgBESBSYg1LgTXPD4khH+O8x4KQc4MM9wGbWwKtp/kBtr1J213J1BF9JWtPZNp13VG7GleSrTMqfchIDoyNQPwPH02Lh+fLbXwuYQPz5fxkAp46L6gxC/MJP6/eeLTWC7c0CE+Z4+waHf46w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
 header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=5UVhejHqxEzhbFwNr0JP6tJ8LiLWKLfLpzm4C5uK/3k=;
 b=wa7nXXzWm8dqSAyyo+wbY5o//swrX2NL6+zclMrSwVcTcJZVtlSwp0b4MtvnltyoVz4RDA7LiyjvA0zEDXau/hui6+EURcl8yEeWu15QZwM++a6+9kwNm7b4raZ/iev7FM2f1ChzAht37Ljl1ZmTYwl1X0Djnf5HegQ0Yo+kW8A=
Authentication-Results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=amd.com;
Message-ID: <662dff5a-f494-4aaf-a2cd-5e95bf0e310b@amd.com>
Date: Mon, 30 Dec 2024 11:10:15 +0000
User-Agent: Mozilla Thunderbird
Subject: Re: [ImageBuilder] Add zstd compression support
To: Jason Andryuk , xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ,
 Michal Orzel 
References: <20241217211903.5945-1-jason.andryuk@amd.com>
Content-Language: en-GB
From: Ayan Kumar Halder 
In-Reply-To: <20241217211903.5945-1-jason.andryuk@amd.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: AM6PR04CA0050.eurprd04.prod.outlook.com
 (2603:10a6:20b:f0::27) To PH8PR12MB7326.namprd12.prod.outlook.com
 (2603:10b6:510:216::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MW4PR12MB7334:EE_|PH7PR12MB5926:EE_
X-MS-Office365-Filtering-Correlation-Id: fb2ef07d-beac-4577-c731-08dd28c28de2
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:
	=?utf-8?B?ajI3OVQvM3VING9oeGY4NGVxYlczcFFXcElWUEFZK1BncVZGR1hjcHFqV0ZW?=
 =?utf-8?B?ZlZ2ejNwcjR4Z3E0Uk5lUXAwcml6eUFSU05neVpHNVY1TFBRRDZJR2I4RDlh?=
 =?utf-8?B?ZDVhRFZwRGRVbUlRbDk3RC9HUHBCUUV5WU5hbTdST2VSdTJwb2tJWEtKNXY1?=
 =?utf-8?B?OG9MSzlidFphdFJKQUt1RmtYMEZYc0Yzd1RZM0hOdnhBRmw2Q0k2SFZwRjEr?=
 =?utf-8?B?S2c3aDhZeHNmcVBiSWtLM2ZzcmY3TXQ4NjZjQkdzaWtmNURRZXBVckJGNzN0?=
 =?utf-8?B?RW53cGVaV0JTVXpiK0hsWjVpaWxmdGlGVHpDSG1YdkthTkE0OHlPQlRvRXpv?=
 =?utf-8?B?WkJFVm9zT0JNQ29ZaGRHWlRGVDFHZWVNL0x3TXZWRUtpbFNYTVIxSmdaTGFQ?=
 =?utf-8?B?bkdXR3FQQkR6TkRPUFBjaDV5TG1WU2YxSXlsYXphaGZtRjRFUXVXR0Vvc0dG?=
 =?utf-8?B?cDlUeWtQa3VHajB4eVF4K3hteENHQlk5amExY3FhdTJLTldGckFhZGprclZa?=
 =?utf-8?B?M1Bmb3NacXZEdHJEaDQzOThhMnFGbGpXQkkwRlJtd3dCS1gyWUVoN3RRWW9B?=
 =?utf-8?B?TFV6UVNLYkZoK2dreGMyWkxZUTU1TUNOdGxyVFNYZzFxZlNNWXQvZGJydi9C?=
 =?utf-8?B?TU4yV2NHWk1lVDY5SWxiVHVmVG9ib3lIWGlzbGZUVTV1MUJQZk53RDZPT1Fv?=
 =?utf-8?B?VVhZVENNbDRrVllwQnJUd09vci8wUklNc3pkUXdxclIyV0VrYkt4Z0xsbkpM?=
 =?utf-8?B?OWpicnZlZlRYeHg4K0I2eG96WlhWS0dXczkrdVNucjJONE5lclV1cDlud2dG?=
 =?utf-8?B?UUtod2l2ZHBQTHBEK1ZxMWkzbTAxYkwwQW54ZG9mSHVDN1FqM1JYcHZwRExw?=
 =?utf-8?B?ZGdFZHA5UmVlMVdrUzBTYllBL3plV3BaeGIranREeGxqZkRwSHdsb1FYT3BK?=
 =?utf-8?B?c01kRzBnVjlyNTl1aGxaVEYxTzY1SFZadjlqV0ljdk5nbTJDMFZIREVKMHBH?=
 =?utf-8?B?TFJQVldOL0ZJaHhHdHVtb1FmajhNbXB5c3F1dE1TSUZQbUlkNTRKV1JNOWpC?=
 =?utf-8?B?NElKUjFYZXBtQjl0U094VEVNNjFidysvbDkyanFvSHBDSnZpNGVXNjZVdll2?=
 =?utf-8?B?K0FaSE9lN1dRejBLK0pMU0pDb1hQMzM0amdUVTRsWXBEQXR4TGUvMENURlli?=
 =?utf-8?B?TUJFOEFndmxnRW5MVndTYXo5QU9ScUp4K09qNUdaODRpYkJKRVpaMG1EdWJw?=
 =?utf-8?B?MmwrZHNVdlh4ajVGUENBTXQ5ZFkvQjVMMkM1L3RPR2d5aWtqNHE4ZlVJaU96?=
 =?utf-8?B?VkVVc3JSQTdwWEplNzloWmhMZE9OczF3V0lyaEFaTmlZRWc0S2IycGlkbkxC?=
 =?utf-8?B?cE5LM01lbCtoY1lGVG0ycjNFS1ZRYVg4NEVMRTNLSTNhd05vT3lLSWhod1Yy?=
 =?utf-8?B?Y0dQUWJQK2Y3OUxDVFVlM3U4dXFiOC9sM0xUaldBY2VKcStFMFdwakNaVFlB?=
 =?utf-8?B?RjJEaUozbUNUbGd1T1B4R0xZMFVrcXJpc0kvekpiTVpYUFpqcDFJUFZ5ZTdy?=
 =?utf-8?B?QkhKNWVPQjhKSWVQQTdZcndVQW5lczRzS2FrWHlUMEJzSlJRdTBDcnpnbmor?=
 =?utf-8?B?YXBPa1FKd3hSVFRZZUZCSm82YWtKNkhhMWlsOEtVbDNxVFMvSXZGMXdWa283?=
 =?utf-8?B?Yy9DQStjWU9TV0ltbUFFYVpuZjF2MStUenZPandQMjY1N1JCalpUN1l6SzRi?=
 =?utf-8?B?RWxwb0EvMWlCTkxwZHo1YS9VVFFEWEVIajVEVldQWGRjRWlBeXlxaUg2SmNM?=
 =?utf-8?B?bStqRVk3dWgrR3BFM0VvZz09?=
X-Forefront-Antispam-Report:
	CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW4PR12MB7334.namprd12.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?bHBwbHdnZ2dIeGNZQVlxMnFuSGhtQ3M5M0oyeW01R2QycEc5QXRocW1sazVj?=
 =?utf-8?B?YjJRc2R5WTlDdjBxenhwekNPR21ualRNQlltZUZlSjJUR0lQYUdOZlpiSFJi?=
 =?utf-8?B?LzhLaWxKR2djeHJEQVRCdE9hNlFZajMvZHNRdzdYbU9FdDJSV1lWbWVRQ3o1?=
 =?utf-8?B?amo2UHBvVENJdzM0U2dUOUVSOXR6WWxZS2J0U3Z4OEJCVVBOSkcxRTBBcGk0?=
 =?utf-8?B?N2srcjJpa0ZTOUJqcXJ3NzRHamZuL3hOT29nL28xaFZ2bTNvNEsySzE4YTln?=
 =?utf-8?B?TzR3d3FUMkcxUGVHKzBJTkNCeUpNV3JKVENLZ2FGR2NIZGlrZ0xLMmR6Y2dX?=
 =?utf-8?B?K0FRY0hYUFVmYU9MeW9aK0txdE5GSmNqd2FWaDNmNWYzZkVPbHRkMi9iaExZ?=
 =?utf-8?B?SEVqOE5kblZZeDNxTXVmSUxUNUV5VWRzL3FaSHZRRGQxaEV1TEtTRHVlRFlW?=
 =?utf-8?B?QUwyUnFrR2dFUjhWejZ0WkFZMW5vaFV4WWJMRUdYeHg1ZHNJVTI0N0ZwbnJm?=
 =?utf-8?B?ZThVbHh1aktkc0FkQ0w3UWVmMEE2WkpCQmRISWxRc2N3NGhQM1cwcE5McGht?=
 =?utf-8?B?ZUNndVA5Q3lxV1VjQjU2ZGU0bngzcnQ3VHZVNytGUjVRMjhrd2FYeUtsbWR2?=
 =?utf-8?B?cGFDZ1NlT2pkaTltTFM3M1JvOGpDZEczelE5bm9vU3VhcTBhdDYydjdzMENK?=
 =?utf-8?B?ZVJwdGJsRGhPeEVFZXBTSWFaeFE5QllSTHlvVzJ6bGxJZ01nNFB3VGxhN1hK?=
 =?utf-8?B?U0xRcjdwVFVadG5GeXY2bHN1OVRwNVV5OWIwTEhHeDVaY2NveGwvRTh5WEly?=
 =?utf-8?B?UStoSDBrc09qOU9pL0lLZTVNWlFLZndBUXpxdWlwWnkxQlNlOHl4OWJjd2k1?=
 =?utf-8?B?UkVSeHJDS2pPK2RKZDh0S2E0ZU0zV080b3g5WXpqdS9pbnUyQ1MwY0RPSmlr?=
 =?utf-8?B?cjdTdlZIUlJSMU5YTis5NlE1ZTl1SkgxWEcyaFlFM0ZXWUoxamVjd1FZb3VU?=
 =?utf-8?B?SnpWbTVHSU44Lzl6QVB5WlBzZVAraXYrTVIzc29TVlAyMHBHaEVtcEZDTDBh?=
 =?utf-8?B?eWNZQW1IVVJMaVA2eHpmYUx3eUlBYW5lTDFoNTQwRHAyZW9PcW9ET1loeHNu?=
 =?utf-8?B?Ri9qMjRHR3dqeXAwZWtJU2lsTGhmeE9KOWx2b3hOZFRNa1hLbmRjTHRYQ3Bt?=
 =?utf-8?B?bDBIK3BIUEV2Y20yTi9DbytmVkJrMlNIeUdrT1hiN05JTlM5SUJmR015aThJ?=
 =?utf-8?B?YTd3MSs5d0ZLNGFBOXlGRlVqdG9OOFAvWGhKWFMvU3F3QzF2dDBaZERERjhL?=
 =?utf-8?B?VnE5YUdkSFV3SlAyOFpaWDY2RGVhVVlzbW1PeHlkWkFPNUh5K28zblo4Wk10?=
 =?utf-8?B?dHN0OWRpZTBJYk1aTEFNY3lybGVjRWJ6NS84RkkzTCtRVk52RVZ4YVVWbm9q?=
 =?utf-8?B?QTBDbnRnaFVuUWVzUkRyRGpDelNiWXR0K2xiYXAyTVF0aGttaWxKZ1V1c1hT?=
 =?utf-8?B?N1hsZlAzNVMvYWJQNFRoSjh6QjlFeHNDWXhvYVlxOUxXOHhKbnA1K0JlTmRt?=
 =?utf-8?B?ZnQrMzlLR2ltTmtjNzhxc1cyLzN3WFVNbGhQVThxaXNrS3NKZGZuWTk1YmFO?=
 =?utf-8?B?cWNkbzFpUkJJcDI1VTVxaDBUT1hWRWpmV1pURWttK3JGVFlEQmVuN2xyL1U4?=
 =?utf-8?B?OTFWQjJSZlhlVDJCWGFsMlU3bTNmR1p0MGV0ZzBNRHEyZW9pbkhJU1p2VnpQ?=
 =?utf-8?B?Yy9FN0NNcUd2WHlnVHdpT2t5QmRsZ3F3ZCswS0lPVEZCYmh4OFlkSmIwemw2?=
 =?utf-8?B?T2RZVEJ6NFFBc0F0VGRFR2p0Rm1WN2svNDZWL3VlNSs4TDg3M0VEbXRWTTJq?=
 =?utf-8?B?R0Ywa0hDMkNOem9OdVJYSXZqNU44Rzl3aHY2djVzV052WnBqbzU3NUdoNmgv?=
 =?utf-8?B?MktkVzZLVWF5UFZlVi9sd2R6cEMxallaQzU0NWk2dE50UDNiczFyQmd0SzJP?=
 =?utf-8?B?ZVdXNUpwQUZBaUQ3UlEzd1EzbXd4eGh2NTNsdnVJdkV5TU55YWxNWjNFZnk2?=
 =?utf-8?B?Y2QxbWpHRjdnT0xrZVlBSjF3V0tHai9VR2JQeS9hLzI1ZmFDcWtFb1dUeTZm?=
 =?utf-8?Q?GXd65jorKOu6ks3R2yoOEwyuT?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fb2ef07d-beac-4577-c731-08dd28c28de2
X-MS-Exchange-CrossTenant-AuthSource: PH8PR12MB7326.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Dec 2024 11:10:37.0429
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: I5cd5QXQV+qRN0rdlJZ3cW+RIygAucctWcIIJ2ctpbCi9QC9ef10VW/Gn5T+yH4Tihsj98JxkofOZnU6QvgfIQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5926

Hi Jason

On 17/12/2024 21:19, Jason Andryuk wrote:
> uboot-script-gen fails to process a zstd-compressed initramdisk, exiting
> with:
> Wrong file type initrd.img. It should be cpio archive, exiting.
>
> Extend the existing approach to also check zstd.
>
> Signed-off-by: Jason Andryuk 
> ---
>   scripts/uboot-script-gen | 11 ++++++++---
>   1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
> index fc63702..db2c011 100755
> --- a/scripts/uboot-script-gen
> +++ b/scripts/uboot-script-gen
> @@ -567,6 +567,7 @@ function check_compressed_file_type()
>   {
>       local filename=$1
>       local type="$2"
> +    local file_type
>   
>       if [ ! -f $filename ]
>       then
> @@ -574,13 +575,17 @@ function check_compressed_file_type()
>           cleanup_and_return_err
>       fi
>   
> -    file -L $filename | grep "gzip compressed data" &> /dev/null
> -    if test $? == 0
> -    then
> +    file_type=$( file -L $filename )
> +    if echo "$file_type" | grep -q "gzip compressed data" ; then
>           local tmp=`mktemp`
>           tmp_files+=($tmp)
>           cat $filename | gunzip > $tmp
>           filename=$tmp
> +    elif echo "$file_type" | grep -q "Zstandard compressed data" ; then
> +        local tmp=`mktemp`
> +        tmp_files+=($tmp)
> +        zstdcat $filename > $tmp

I think you need to list zstd in |prog_req
|

|See 
https://gitlab.com/xen-project/imagebuilder/-/blob/master/scripts/uboot-script-gen?ref_type=heads#L5|

|Also you need to include this as a part of the dockerfiles like|

|https://gitlab.com/xen-project/xen/-/blob/staging/automation/tests-artifacts/qemu-system-aarch64/6.0.0-arm64v8.dockerfile?ref_type=heads|

|https://gitlab.com/xen-project/xen/-/blob/staging/automation/tests-artifacts/alpine/3.18-arm64v8.dockerfile?ref_type=heads
|

> +        filename=$tmp
>       fi
>       check_file_type $filename "$type"
>   }
- Ayan


From xen-devel-bounces@lists.xenproject.org Mon Dec 30 16:42:33 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Dec 2024 16:42:33 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863530.1274896 (Exim 4.92)
	(envelope-from )
	id 1tSIqO-0003DD-VH; Mon, 30 Dec 2024 16:42:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863530.1274896; Mon, 30 Dec 2024 16:42:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tSIqO-0003D6-Sg; Mon, 30 Dec 2024 16:42:16 +0000
Received: by outflank-mailman (input) for mailman id 863530;
 Mon, 30 Dec 2024 16:42: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 1tSIqM-0003Ck-OW
 for xen-devel@lists.xenproject.org; Mon, 30 Dec 2024 16:42:14 +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 033b5395-c6cd-11ef-99a4-01e77a169b0f;
 Mon, 30 Dec 2024 17:42:09 +0100 (CET)
Received: by mail-wm1-x32d.google.com with SMTP id
 5b1f17b1804b1-4361e89b6daso63219465e9.3
 for ; Mon, 30 Dec 2024 08:42:09 -0800 (PST)
Received: from [192.168.69.132] (88-187-86-199.subs.proxad.net.
 [88.187.86.199]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a457584bcsm12989464f8f.89.2024.12.30.08.42.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Dec 2024 08:42: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: 033b5395-c6cd-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google; t=1735576929; x=1736181729; 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=xeKnEKsR0+uOT+NFBKBAtZvitld2Kqz+mQfzQ7jeZOk=;
        b=GQCSsH441/oBh0IRtmrs5SmqrYnJVbRHvpHHU5KfrDrC78dktgaqSubd+CeEbqUz1Y
         8v0Q80XN1eBfXs/xFnzF8sDA2+WAmdWuJIWzToebywrQqSd7Ne+HGkyUga3tVhjoxo42
         ri2bnNKTNESoGGvRnI6+6Q4gM2GvqaoU6hzrsHDM4oYfit18J5W4a5lthg/D8hwQk6RW
         33bawgpLRvCI+l9oFpitNe5+ZTeue7YUqc4ASPW/XuMO4mNuJ2GFifol1Q6+588UPOnD
         I4XWUuroNZ4zmSne1X+1XkFmDcl5qEBKBf/hHy0kBmEY1DkdEB4JKXK5/kWGqiRoCrHR
         L0Bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735576929; x=1736181729;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:cc:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=xeKnEKsR0+uOT+NFBKBAtZvitld2Kqz+mQfzQ7jeZOk=;
        b=Gz0znwLSoOhhRNfjB6pdWj9FRozxweeNg2KhLdsDCOn0R972i0XioBHwIPYlJvUtuM
         n4yRBWA4lg81Mxd+rHqdNzL+SwKz3gDEimLpxXfX58iLCAuWbjgMQliChzAsTNX9dVJh
         Kxx097HE4wPEgTkXtj8kJCQVycsol2lgumHQ5JmD9THn9jHceVa9C3PQfWBbqO5Xzs6z
         vNRAscbLVnnNr1LGJO9y0Zt+eVRdhdrL5T1fwAVYNsJKOjQP2TIcWgVIvssJ9tjb87Bs
         afhbKajBH+sm1WY7UwASnokgVizvVtoT2ZOa3Oe1s+uiyzZgoAunAAQsy317Vo9BVfPT
         aCag==
X-Forwarded-Encrypted: i=1; AJvYcCUZ9R31LkCz/llF5syKqh7k3g42vHM6nObHcET5q42+Wefx8bTD8Ehe2NSFTxQVliGchOtHBWhG0w4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YzhKVlLqs+t5GSsTQ/hYo5XxXVU1wpk7Sz6MmX2Zb2dJbrl+/b6
	dP9F/grdZrwCLOwsoibT4cXdXrDu+GUVFmE3BjylgiI1/cPiyYYghaGkKX8qIKM=
X-Gm-Gg: ASbGncvCoQdNRE5kPOIY9xPCed5l0Ifs6OgikxLyfvOB+cm0Ld2m/HdtT1Eh9rLpkfW
	wmOnStai8qvaujbcuXmM0RK5wL1GYA2tcGGtwqrT4dYGi2OQwwEKiWlr1qWDzJvacT1oN2SON2S
	/h6lyWRkpeLpF6wAyd7PWI2b2qoRuRu5kuGZ5Q2IFzUT3ZOlKviWlNMliwocjcj7mEB5Ju0hooh
	Ie8wzy1lQYXhNSlggmWvM/QVsouVCA7M1mmm6/dS+CGiv1xqueCRNlLpZT8OEBjxniRjQeCJ540
	3qJTSEMNoePyxRfODIXUwv6L
X-Google-Smtp-Source: AGHT+IFSOfue9OZ0StQtjpEHd7pGzqC744lEPd6nwbKJP91hf+X3OX90JKPSuYktgpgVYlnNiexKGg==
X-Received: by 2002:a5d:47cf:0:b0:385:ee59:44eb with SMTP id ffacd0b85a97d-38a221fa9ffmr30615491f8f.33.1735576929176;
        Mon, 30 Dec 2024 08:42:09 -0800 (PST)
Message-ID: <20fbbcc8-bf6d-44c2-b904-be52debc1f8a@linaro.org>
Date: Mon, 30 Dec 2024 17:42:07 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/5] hw: Mark architecture specific devices with specific
 endianness
To: qemu-devel@nongnu.org
Cc: Artyom Tarasenko ,
 Stefano Stabellini ,
 Richard Henderson ,
 xen-devel@lists.xenproject.org, Paolo Bonzini ,
 Marcel Apfelbaum ,
 "Edgar E. Iglesias" ,
 Bastian Koppelmann ,
 Anthony PERARD ,
 Eduardo Habkost , Thomas Huth ,
 Jia Liu , Stafford Horne ,
 Paul Durrant , Mark Cave-Ayland
 , "Michael S. Tsirkin" 
References: <20241106184612.71897-1-philmd@linaro.org>
Content-Language: en-US
From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= 
In-Reply-To: <20241106184612.71897-1-philmd@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 6/11/24 19:46, Philippe Mathieu-Daudé wrote:
> When a device is only built for an architecture built for
> a particular endianness, we can simplify the device to not
> use the "target native endianness" definition and directly
> use the proper target endianness.
> 
> Philippe Mathieu-Daudé (5):
>    hw/i386: Mark devices as little-endian
>    hw/tricore: Mark devices as little-endian
>    hw/m68k: Mark devices as big-endian
>    hw/openrisc: Mark devices as big-endian
>    hw/sparc: Mark devices as big-endian

I'm queuing this series, better to test it early in the dev cycle.


From xen-devel-bounces@lists.xenproject.org Mon Dec 30 20:57:20 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Dec 2024 20:57:20 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863539.1274908 (Exim 4.92)
	(envelope-from )
	id 1tSMp0-0005Hg-E6; Mon, 30 Dec 2024 20:57:06 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863539.1274908; Mon, 30 Dec 2024 20:57:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tSMp0-0005HZ-9g; Mon, 30 Dec 2024 20:57:06 +0000
Received: by outflank-mailman (input) for mailman id 863539;
 Mon, 30 Dec 2024 20:57: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 1tSMoy-0005HT-34
 for xen-devel@lists.xenproject.org; Mon, 30 Dec 2024 20:57:05 +0000
Received: from mx1.somlen.de (typhoon.somlen.de [89.238.64.140])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 9d47714d-c6f0-11ef-a0db-8be0dac302b0;
 Mon, 30 Dec 2024 21:57:00 +0100 (CET)
Received: by mx1.somlen.de with ESMTPSA id C8D8E5030C1
 for ; Mon, 30 Dec 2024 21:56:58 +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: 9d47714d-c6f0-11ef-a0db-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daemonizer.de;
	s=202303; t=1735592219;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type;
	bh=sQmZIXfDs1rHvUaJNY5rFgMAdUz5F5EPTE6F/gXdKIA=;
	b=EhgIeV3JmrHAtbb/Ulf4ztjAsh118UHA9s0qfv16e7BFqPgKNieVHqmNn8g7IY1WhTeGdf
	8c6Wnog7lXoE0KeLESp+5REp06F3cCZhz6MmV2Vu6hciP+55n3LUWiqVvDvuw4TtfvvsEy
	x8K6mump6rnwnVlbZiF8Noj/crS9qkb/xAzKIGY1JZqSbO/6kweJXrX0DauDLqHqOjwCyt
	izCfBTd1jV3H8zYIMJ7AEXNRF3SVBETlra/u7xy9Tlcg8/h05XJLTceOIbrcbpm7HjzBZh
	z3+Y0r+Z5eQtw1dqeFRRuXWf7ZklhaHk/Dm391OzdzJSgMHeGM5OoIc7PXvU5w==
From: Maximilian Engelhardt 
To: xen-devel@lists.xenproject.org
Subject:
 Bug: Hyperlinks in generated documentation may point to the wrong
 architecture
Date: Mon, 30 Dec 2024 21:56:53 +0100
Message-ID: <2293976.iZASKD2KPV@localhost>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1990080.PYKUYFuaPT";
 micalg="pgp-sha512"; protocol="application/pgp-signature"

--nextPart1990080.PYKUYFuaPT
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"; protected-headers="v1"
From: Maximilian Engelhardt 
To: xen-devel@lists.xenproject.org
Date: Mon, 30 Dec 2024 21:56:53 +0100
Message-ID: <2293976.iZASKD2KPV@localhost>
MIME-Version: 1.0

Hello,

during working on packaging Xen in Debian I noticed the documentation becomes 
non-reproducible as hyperlinks may point to the wrong architecture.

Here an example as diff showing the problem:

/usr/share/doc/xen/html/hypercall/arm/include,public,arch-arm.h.html
@@ -313,15 +313,15 @@
     uint64_t sctlr;
     uint64_t ttbcr, ttbr0, ttbr1;
 };
 typedef struct vcpu_guest_context vcpu_guest_context_t;
 DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
 
 /*
- * struct xen_arch_domainconfig's ABI is covered by
+ * struct xen_arch_domainconfig's ABI is covered by
  * XEN_DOMCTL_INTERFACE_VERSION.
  */
 #define XEN_DOMCTL_CONFIG_GIC_NATIVE    0
 #define XEN_DOMCTL_CONFIG_GIC_V2        1
 #define XEN_DOMCTL_CONFIG_GIC_V3        2
 
 #define XEN_DOMCTL_CONFIG_TEE_NONE      0


As can be seen, the hyperlink in include,public,arch-arm.h.html points to 
include,public,arch-ppc.h.html while it should point to include,public,arch-
arm.h.html.
A similar problem can be found in many more places and files.

Corresponding to the problem described above, while building the documentation 
many messages similar to the last lines below can be seen in the build log:

/usr/bin/perl -w /build/reproducible-path/xen-4.19.1/docs/xen-headers -O html/hypercall/arm \
        -T 'arch-arm - Xen public headers' \
        -X arch-x86_32 -X arch-x86_64 \
        -X xen-x86_32 -X xen-x86_64 \
        -X arch-x86 \
        /build/reproducible-path/xen-4.19.1/docs/../xen include/public include/xen/errno.h
include/public/arch-ppc.h:91: multiple definitions of Typedef vcpu_guest_core_regs_t: include/public/arch-arm.h:300
include/public/arch-ppc.h:91: multiple definitions of Typedef vcpu_guest_core_regs_t: include/public/arch-ppc.h:85
include/public/arch-ppc.h:91: multiple definitions of Typedef vcpu_guest_core_regs_t: include/public/arch-arm.h:300
include/public/arch-ppc.h:91: multiple definitions of Typedef vcpu_guest_core_regs_t: include/public/arch-ppc.h:85
include/public/arch-ppc.h:95: multiple definitions of Struct vcpu_guest_context: include/public/arch-ppc.h:90
include/public/arch-ppc.h:95: multiple definitions of Struct vcpu_guest_context: include/public/arch-arm.h:305
include/public/arch-ppc.h:95: multiple definitions of Struct vcpu_guest_context: include/public/arch-ppc.h:90
include/public/arch-ppc.h:95: multiple definitions of Struct vcpu_guest_context: include/public/arch-arm.h:305
[...]


In Debian we worked around the problem for now by adding ppc and riscv to 
DOC_ARCHES in docs/Makefile as can be seen in [1]. This solves all the 
described problems and makes the build reproducible again. I assume another 
possible fix would be adding suitable ignore switches for ppc and riscv.

I did not send this as a patch as I'm not sure what the preferred upstream 
solution to this problem is, but can formally submit our fix as a patch if 
that's desired.

Thanks,
Maxi

[1] https://salsa.debian.org/xen-team/debian-xen/-/commit/d852c48d0df5c6ceba42d20652d1f9a05ad8989e 
--nextPart1990080.PYKUYFuaPT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

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

iQIzBAABCgAdFiEEQ8gZ7vwsPje0uPkIgepkfSQr0hUFAmdzCRUACgkQgepkfSQr
0hVXYA/9GsPUQGILV6vqzCbx+1SiVv1rnmARjCnnWREslj8UTwOBtkbaPuequFI9
t7+Xt+uKBqo5P+Bh9QU0Vc5RPjnWHTST69G3rxfxH4kvh5OAOxcyhhL3vmIt1LWi
mj7nqq87l/LeXzzphYdQOCLXxvMnUSnnkWBS1t2xEJ6p9bX7eUv7IDqskGniMKkY
2pcL/ifZw5RfBzCyw/uF2G8M0chSp5bS2JK3dDH+lflPfLOokX6ubEcOrezcBlmW
RAUvCZ5o3HGrEz7it/Rxk1gyUmLAacYQrIV/kXOMsJGk2AFSRbOlln39rzkrdKz3
439FhF8ow5PaYlUmaiC8cb/dpkQYhP0vW5mzYmaxVlUoxGWKMUDCv9iA3FkbvF0j
+IXoMbts4NzvvuNT04GvuhoiwGal55BkzniFfM8xuM9Hz4hfwbNIpexH/w8D1lWO
irdIci6KOzy4aduiB4yki8IhIbpBer3N4TxTIx6GuL7FvTsBdjTYcbdjqtR0pvFT
U7r+p/BpB4ZkSyvJyuPwiPDVC/0mzSqtBALRI9rZXST2WK28vkgF2UmvqJmsXRCz
75duE4pUBl7Apk9oJ3NxythSIH6saaYT+yHDYxTrp8ffIBOPkdSAgjPzb88jT3pL
u+r3r+jR0U7pPW5Qhoa/ED5ZisDo7gC+jdRkNWO7Lq2St5Jz+Nw=
=/gKh
-----END PGP SIGNATURE-----

--nextPart1990080.PYKUYFuaPT--





From xen-devel-bounces@lists.xenproject.org Mon Dec 30 21:01:13 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Dec 2024 21:01:13 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863548.1274917 (Exim 4.92)
	(envelope-from )
	id 1tSMsx-0006nx-TS; Mon, 30 Dec 2024 21:01:11 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863548.1274917; Mon, 30 Dec 2024 21:01:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tSMsx-0006nq-QJ; Mon, 30 Dec 2024 21:01:11 +0000
Received: by outflank-mailman (input) for mailman id 863548;
 Mon, 30 Dec 2024 21:01: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 1tSMsx-0006nk-Ci
 for xen-devel@lists.xenproject.org; Mon, 30 Dec 2024 21:01:11 +0000
Received: from mx1.somlen.de (breeze.somlen.de [2a00:1828:a019::100:0])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 317b91b3-c6f1-11ef-99a4-01e77a169b0f;
 Mon, 30 Dec 2024 22:01:09 +0100 (CET)
Received: by mx1.somlen.de with ESMTPSA id C999A5030C1;
 Mon, 30 Dec 2024 22:01:08 +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: 317b91b3-c6f1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daemonizer.de;
	s=202303; t=1735592469;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding;
	bh=kaZsUcyrxauv/BG4fpslcUCmMWSxyvETJhxN2crai+U=;
	b=Lng6gtH+CyHJo0IshZP3FjQQQellK9fvXDMYwV6w3/Gs7o1u5c7UJZU2KTtOPLGUESISYr
	ad+ZMsWY6tQk1lFJanLg3lgCQEXJbQGQR9tGyJmr9yvlS5Sze45gX7xmhZolJ4CEAEWpbM
	0OCTHfiy6wmWqnyYsvNAmIq+187f1eCiXSBTBhexxSJernfg0SUHh1+fibtFqZBPyEiAx/
	UYvOKbDFBqyJJOK3yJHZsk+MYGp1BzP8VRE5JW1vlKGtTVZ+5YtqA5FT9/k1d382sasvTw
	rqGnAG8CdMGp3mqUl4rPBQjcAxDIW6of6ajioHcg6aazPsrSi1HkrcUm6Z2bUg==
From: Maximilian Engelhardt 
To: xen-devel@lists.xenproject.org
Cc: Maximilian Engelhardt ,
	Anthony PERARD ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Juergen Gross 
Subject: [XEN PATCH 0/5] Fixes for reproducible builds and other small fixes
Date: Mon, 30 Dec 2024 22:00:28 +0100
Message-Id: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This series is a bunch of fixes we found while packaging Xen in Debian
and we believe they should be best addressed upstream.

We have been carrying the first patch for a long time in Debian, but it
seems it never was applied upstream. It's an addition to
"docs/man: Provide properly-formatted NAME sections"
(commit 423c4def1f7a01eeff56fa70564180640ef3af43).

Patch two and three are fixes for reproducibility issues that I found
using our testing gear in Debian.

The last two patches are trivial fixes correcting two common typos found
by Debian tools.

Thanks


Ian Jackson (1):
  docs/man/xen-vbd-interface.7: Provide properly-formatted NAME section

Maximilian Engelhardt (4):
  docs: set DATE to SOURCE_DATE_EPOCH if available
  xen/arch/x86: make objdump output user locale agnostic
  docs/man: fix typo: hexidecimal -> hexadecimal
  tools: fix typo: subsytem -> subsystem

 docs/Makefile                       | 8 +++++++-
 docs/man/xen-vbd-interface.7.pandoc | 5 +++++
 docs/man/xl-pci-configuration.5.pod | 2 +-
 tools/include/xenctrl.h             | 2 +-
 tools/misc/xen-memshare.c           | 2 +-
 xen/arch/x86/arch.mk                | 2 +-
 6 files changed, 16 insertions(+), 5 deletions(-)

-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Dec 30 21:01:15 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Dec 2024 21:01:15 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863549.1274927 (Exim 4.92)
	(envelope-from )
	id 1tSMt1-000740-2q; Mon, 30 Dec 2024 21:01:15 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863549.1274927; Mon, 30 Dec 2024 21:01: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 1tSMt1-00073p-04; Mon, 30 Dec 2024 21:01:15 +0000
Received: by outflank-mailman (input) for mailman id 863549;
 Mon, 30 Dec 2024 21:01: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 1tSMt0-00073D-FP
 for xen-devel@lists.xenproject.org; Mon, 30 Dec 2024 21:01:14 +0000
Received: from mx1.somlen.de (typhoon.somlen.de [89.238.64.140])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 3416d09c-c6f1-11ef-a0db-8be0dac302b0;
 Mon, 30 Dec 2024 22:01:13 +0100 (CET)
Received: by mx1.somlen.de with ESMTPSA id 3A4D45030E8;
 Mon, 30 Dec 2024 22:01:13 +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: 3416d09c-c6f1-11ef-a0db-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daemonizer.de;
	s=202303; t=1735592473;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=PMl7doOmmRwQcq+r6ytsB5DZXr1441bm/ek2YpkEhpg=;
	b=02s4tETFA/3dODyJqbV8n07g9zGuDfFQi43R7JGitkzK3iq8kJhwbOY4o0P6VGPkuz/g4a
	uAB44NyDFRVxk9wnSOCgwholvBgj2sCGydqqwYIGjeqGQyJzq0Wd2vVBk5Me6Ned2X7xJt
	J4xVU9TPSmjJWuXg64PrA3y35XP6FOVJJFuhd0WjpYqe1PqbfXHeDY4qIkghctpmtrbB9r
	IQ7HxFnT8/3MVB9kzgjJc8weSuROSOekrHaJFg12IuhKeenPzCJT2hgrKHjftHmRM6wFyw
	T+dH1WItXQKZwd2hwBxPMSK+/ovypRBjkA1CN7Yi6LC/nuBJcEVmwCD4qKsvMA==
From: Maximilian Engelhardt 
To: xen-devel@lists.xenproject.org
Cc: Maximilian Engelhardt ,
	Anthony PERARD 
Subject: [XEN PATCH 2/5] docs: set DATE to SOURCE_DATE_EPOCH if available
Date: Mon, 30 Dec 2024 22:00:30 +0100
Message-Id: <1ad1283052a580cbe7dbd7581b64f3cfd87cbf88.1735585600.git.maxi@daemonizer.de>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Use the solution described in [1] to replace the call to the 'date'
command with a version that uses SOURCE_DATE_EPOCH if available. This
is needed for reproducible builds.

The -d "@..." syntax was introduced in GNU date about 2005 (but only
added to the docuemntation in 2011), so I assume a version supporting
this syntax is available, if SOURCE_DATE_EPOCH is defined. If
SOURCE_DATE_EPOCH is not defined, nothing changes with respect to the
current behavior.

[1] https://reproducible-builds.org/docs/source-date-epoch/

Signed-off-by: Maximilian Engelhardt 
---
 docs/Makefile | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/docs/Makefile b/docs/Makefile
index b30cc619f8..beba02a94f 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -3,7 +3,13 @@ include $(XEN_ROOT)/Config.mk
 -include $(XEN_ROOT)/config/Docs.mk
 
 VERSION		:= $(shell $(MAKE) -C $(XEN_ROOT)/xen --no-print-directory xenversion)
-DATE		:= $(shell date +%Y-%m-%d)
+
+DATE_FMT	:= +%Y-%m-%d
+ifdef SOURCE_DATE_EPOCH
+DATE		:= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null || date -u "$(DATE_FMT)")
+else
+DATE		:= $(shell date "$(DATE_FMT)")
+endif
 
 DOC_ARCHES      := arm x86_32 x86_64
 MAN_SECTIONS    := 1 5 7 8
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Dec 30 21:01:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Dec 2024 21:01:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863550.1274937 (Exim 4.92)
	(envelope-from )
	id 1tSMt2-0007JW-9M; Mon, 30 Dec 2024 21:01:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863550.1274937; Mon, 30 Dec 2024 21:01: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 1tSMt2-0007JL-5k; Mon, 30 Dec 2024 21:01:16 +0000
Received: by outflank-mailman (input) for mailman id 863550;
 Mon, 30 Dec 2024 21:01: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 1tSMt0-0006nk-PH
 for xen-devel@lists.xenproject.org; Mon, 30 Dec 2024 21:01:14 +0000
Received: from mx1.somlen.de (breeze.somlen.de [2a00:1828:a019::100:0])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 33ed3423-c6f1-11ef-99a4-01e77a169b0f;
 Mon, 30 Dec 2024 22:01:13 +0100 (CET)
Received: by mx1.somlen.de with ESMTPSA id 0508D5030C1;
 Mon, 30 Dec 2024 22:01:12 +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: 33ed3423-c6f1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daemonizer.de;
	s=202303; t=1735592473;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=Y3IPyDYbEqLp9/TJelGNbhXNC7AXR4cBfozsJVQEaMM=;
	b=Cu1TnrCjzNMcMG3z7LLfOXIEO6ZD0EyWx3B5a41x/hzz8iigBwQOmrSaRxWC8gv3f/Ltfu
	0MdDmylqkefNg3VjuHLGsb1kRemVTdPiUPMJz7AOsRSH7XwiTakb1WI5u4u7aVXFPyM98M
	S0E4e076NgwXZXcGzQOFT+8BKmXM9Flnb8oGTzc1fZ7twkmG24oSqfZEI7MoMHe8r6j/9K
	GAY3kMMwungU4b7SrUIu21DgLV5irBxYjqZG7dW1cEz1BG2qRu1Kd7r/AYBmQQfuWnGvwR
	TBz3UsFu0r7wL+GiK9cbid+I2UnpxgQsgRm3UTmbMIaN5KWkLatwqhHV1KhPSg==
From: Maximilian Engelhardt 
To: xen-devel@lists.xenproject.org
Cc: Ian Jackson ,
	Anthony PERARD ,
	Maximilian Engelhardt 
Subject: [XEN PATCH 1/5] docs/man/xen-vbd-interface.7: Provide properly-formatted NAME section
Date: Mon, 30 Dec 2024 22:00:29 +0100
Message-Id: <9514c20c6982d65afc8ee53c4027f435d46d8056.1735585600.git.maxi@daemonizer.de>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

From: Ian Jackson 

This manpage was omitted from
   docs/man: Provide properly-formatted NAME sections
   (423c4def1f7a01eeff56fa70564180640ef3af43)
because I was previously building with markdown not installed.

Signed-off-by: Ian Jackson 
Tested-by: Maximilian Engelhardt 
---
 docs/man/xen-vbd-interface.7.pandoc | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/docs/man/xen-vbd-interface.7.pandoc b/docs/man/xen-vbd-interface.7.pandoc
index ba0d159dfa..2f18d5b72e 100644
--- a/docs/man/xen-vbd-interface.7.pandoc
+++ b/docs/man/xen-vbd-interface.7.pandoc
@@ -1,3 +1,8 @@
+Name
+----
+
+xen-vbd-interface - Xen paravirtualised block device protocol
+
 Xen guest interface
 -------------------
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Dec 30 21:01:16 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Dec 2024 21:01:16 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863551.1274943 (Exim 4.92)
	(envelope-from )
	id 1tSMt2-0007Ly-L4; Mon, 30 Dec 2024 21:01:16 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863551.1274943; Mon, 30 Dec 2024 21:01: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 1tSMt2-0007L1-DO; Mon, 30 Dec 2024 21:01:16 +0000
Received: by outflank-mailman (input) for mailman id 863551;
 Mon, 30 Dec 2024 21:01: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 1tSMt1-00073D-57
 for xen-devel@lists.xenproject.org; Mon, 30 Dec 2024 21:01:15 +0000
Received: from mx1.somlen.de (typhoon.somlen.de [89.238.64.140])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 343edaa2-c6f1-11ef-a0db-8be0dac302b0;
 Mon, 30 Dec 2024 22:01:13 +0100 (CET)
Received: by mx1.somlen.de with ESMTPSA id 6841F506D31;
 Mon, 30 Dec 2024 22:01:13 +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: 343edaa2-c6f1-11ef-a0db-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daemonizer.de;
	s=202303; t=1735592473;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=vNoycYF/AunNCbr33bPlfVZJJaaGcAgrVSlzFQ4oMMU=;
	b=Jd/ryk/mRGv4VnXHj3pLw18iO39jMHpJOXtH+LSHqrLZSQy1Kp6PNpTLMyv/UCxUqC0oM+
	Wc0AVSF/DR1vXdcfjAF7iXWLChWteN1+Hewq/vNohDVERwOX4SLUe49E3VmhF9PkpARXmP
	bIt5guaI5iSxwBg4xL16NO/gvhOyxFX9AnrfOrbi+rT1e2pgs+X5usSZ9I2m8h1Sc/m50U
	W39PRRlh3Wxyxt9gJlfPKvz8NZJOGRBShrXs42TEu+fzMcuvAFkYUw+1NN/romZ/Iy1U4L
	HTLUKXwjwMHcbwO9LSHnes6YmElHgwT+d0NuwhiwQbtqRsx0dYEvKiSelry0YA==
From: Maximilian Engelhardt 
To: xen-devel@lists.xenproject.org
Cc: Maximilian Engelhardt ,
	Jan Beulich ,
	Andrew Cooper ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= 
Subject: [XEN PATCH 3/5] xen/arch/x86: make objdump output user locale agnostic
Date: Mon, 30 Dec 2024 22:00:31 +0100
Message-Id: 
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The objdump output is fed to grep, so make sure it doesn't change with
different user locales and break the grep parsing.
This problem was identified while updating xen in Debian and the fix is
needed for generating reproducible builds in varying environments.

Signed-off-by: Maximilian Engelhardt 
---
 xen/arch/x86/arch.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/arch.mk b/xen/arch/x86/arch.mk
index 9dde8a5756..cb47d72991 100644
--- a/xen/arch/x86/arch.mk
+++ b/xen/arch/x86/arch.mk
@@ -109,7 +109,7 @@ endif
 ifeq ($(XEN_BUILD_PE),y)
 
 # Check if the linker produces fixups in PE by default
-efi-nr-fixups := $(shell $(OBJDUMP) -p $(efi-check).efi | grep '^[[:blank:]]*reloc[[:blank:]]*[0-9][[:blank:]].*DIR64$$' | wc -l)
+efi-nr-fixups := $(shell LC_ALL=C $(OBJDUMP) -p $(efi-check).efi | grep '^[[:blank:]]*reloc[[:blank:]]*[0-9][[:blank:]].*DIR64$$' | wc -l)
 
 ifeq ($(efi-nr-fixups),2)
 MKRELOC := :
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Dec 30 21:01:17 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Dec 2024 21:01:17 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863552.1274957 (Exim 4.92)
	(envelope-from )
	id 1tSMt3-0007m3-Pi; Mon, 30 Dec 2024 21:01:17 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863552.1274957; Mon, 30 Dec 2024 21: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 1tSMt3-0007lh-L9; Mon, 30 Dec 2024 21:01:17 +0000
Received: by outflank-mailman (input) for mailman id 863552;
 Mon, 30 Dec 2024 21:01:15 +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 1tSMt1-0006nk-PN
 for xen-devel@lists.xenproject.org; Mon, 30 Dec 2024 21:01:15 +0000
Received: from mx1.somlen.de (typhoon.somlen.de [89.238.64.140])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 344ec987-c6f1-11ef-99a4-01e77a169b0f;
 Mon, 30 Dec 2024 22:01:14 +0100 (CET)
Received: by mx1.somlen.de with ESMTPSA id A0742506D34;
 Mon, 30 Dec 2024 22:01:13 +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: 344ec987-c6f1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daemonizer.de;
	s=202303; t=1735592473;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=VKAAcZsb1zf/Sx09ApHUwHb6yPd9REXI9uLqVexVt6k=;
	b=EZfsna/WG9f6kP91AejpJsdQ7VK0QiUtVLhv5Sp6HtKy3F7uyqz4og5RhrBUli1Lmm0h/Z
	v0Ck/JjX0YVdygeJnrRK7YrA4PA81Jqg1zbW1XMQFB9sGSmeH0r94p7hKYSMzy+utqZmLb
	5LQLry8jvw/pkxOvG8IbGWvwKzVPokSMWp264GJvEr8CsaMfjnAfzQnNd4F6YagO/C3tZ3
	SW0VNSv0VIy3mjM2a7sIN5yyBjX1r5xO0ryT5G04iU3jSyjxm9HTilknbJ5oF1cuSOJk87
	wd4O1j0W36S4fXibXvAkgCiwuprUFiODabUuVdMcuay2BTOWxM0JChMWrebn5Q==
From: Maximilian Engelhardt 
To: xen-devel@lists.xenproject.org
Cc: Maximilian Engelhardt ,
	Anthony PERARD 
Subject: [XEN PATCH 4/5] docs/man: fix typo: hexidecimal -> hexadecimal
Date: Mon, 30 Dec 2024 22:00:32 +0100
Message-Id: <3a3f8f625af48fe2cac19bfab976c811c6cec6f4.1735585600.git.maxi@daemonizer.de>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This was found by the lintian tool (Debian package checker) during
packaging xen for Debian.

Signed-off-by: Maximilian Engelhardt 
---
 docs/man/xl-pci-configuration.5.pod | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/man/xl-pci-configuration.5.pod b/docs/man/xl-pci-configuration.5.pod
index db3360307c..ec76f590b7 100644
--- a/docs/man/xl-pci-configuration.5.pod
+++ b/docs/man/xl-pci-configuration.5.pod
@@ -89,7 +89,7 @@ device. For example, running L in a Linux guest where B
 was specified as C<8> would identify the device as C<00:08.0>. Virtual domain
 and bus numbers are always 0.
 
-B This parameter is always parsed as a hexidecimal value.
+B This parameter is always parsed as a hexadecimal value.
 
 =item Default Value
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Dec 30 21:01:18 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Dec 2024 21:01:18 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863553.1274964 (Exim 4.92)
	(envelope-from )
	id 1tSMt4-0007vU-A7; Mon, 30 Dec 2024 21:01:18 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863553.1274964; Mon, 30 Dec 2024 21:01:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tSMt4-0007ug-6K; Mon, 30 Dec 2024 21:01:18 +0000
Received: by outflank-mailman (input) for mailman id 863553;
 Mon, 30 Dec 2024 21:01: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 1tSMt2-0006nk-PL
 for xen-devel@lists.xenproject.org; Mon, 30 Dec 2024 21:01:16 +0000
Received: from mx1.somlen.de (typhoon.somlen.de [89.238.64.140])
 by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id 346fb3dc-c6f1-11ef-99a4-01e77a169b0f;
 Mon, 30 Dec 2024 22:01:14 +0100 (CET)
Received: by mx1.somlen.de with ESMTPSA id D7CBA506D3D;
 Mon, 30 Dec 2024 22:01:13 +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: 346fb3dc-c6f1-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daemonizer.de;
	s=202303; t=1735592474;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=h75DPoDEbFCJlydhUR/eRPZoEnhMbc8Ymd/flb1Kxes=;
	b=JMxcop1AVBmsy9zmgqrVah4uaCwV3KHJ4FM9H8+XHersdmP+Uwsz5J8VWhYyiXaEhaGDJR
	9HUAO+jyGZWnub5Wd1V/5knWeAdV42v9GGelvXGkKCygdNXkmZVLlDEnyZOXUPR7p6s9RW
	tOcr6pZqaFSWVLIZH2477hssqBrhZc2DW3KsHV1FnJGLxw9+88hGSAou8mGsVeju2nM1oY
	h3o3rD3QHD4QGPFjWc4f09dCJzh/p89xCrGWmgF21auh8TwBzx2jgQLJBfpVWAIaCi8Btz
	usx5Dx730NTneiahj0C3WGh58yHsBQzf0oUI7K8dwM5PZ1a87llMKuY52VNMkA==
From: Maximilian Engelhardt 
To: xen-devel@lists.xenproject.org
Cc: Maximilian Engelhardt ,
	Anthony PERARD ,
	Juergen Gross 
Subject: [XEN PATCH 5/5] tools: fix typo: subsytem -> subsystem
Date: Mon, 30 Dec 2024 22:00:33 +0100
Message-Id: 
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This was found by the lintian tool (Debian package checker) during
packaging xen for Debian.

Signed-off-by: Maximilian Engelhardt 
---
 tools/include/xenctrl.h   | 2 +-
 tools/misc/xen-memshare.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 5bb41c9c53..4955981231 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -2212,7 +2212,7 @@ int xc_memshr_domain_resume(xc_interface *xch,
  * May fail with:
  *  EINVAL if the gfn is not populated or not sharable (mmio, etc)
  *  ENOMEM if internal data structures cannot be allocated
- *  E2BIG if the page is being referenced by other subsytems (e.g. qemu)
+ *  E2BIG if the page is being referenced by other subsystems (e.g. qemu)
  *  ENOENT or EEXIST if there are internal hypervisor errors.
  */
 int xc_memshr_nominate_gfn(xc_interface *xch,
diff --git a/tools/misc/xen-memshare.c b/tools/misc/xen-memshare.c
index 8e5e22b9e9..ab30979ebc 100644
--- a/tools/misc/xen-memshare.c
+++ b/tools/misc/xen-memshare.c
@@ -30,7 +30,7 @@ static int usage(const char* prog)
     printf("  add-to-physmap     \n");
     printf("                          - Populate a page in a domain with a shared page.\n");
     printf("  debug-gfn   - Debug a particular domain and gfn.\n");
-    printf("  audit                   - Audit the sharing subsytem in Xen.\n");
+    printf("  audit                   - Audit the sharing subsystem in Xen.\n");
     return 1;
 }
 
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Mon Dec 30 21:38:39 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Dec 2024 21:38:39 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863606.1274976 (Exim 4.92)
	(envelope-from )
	id 1tSNT3-0006Sg-Od; Mon, 30 Dec 2024 21:38:29 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863606.1274976; Mon, 30 Dec 2024 21:38: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 1tSNT3-0006SZ-Lk; Mon, 30 Dec 2024 21:38:29 +0000
Received: by outflank-mailman (input) for mailman id 863606;
 Mon, 30 Dec 2024 21:38: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 1tSNT2-0006ST-Og
 for xen-devel@lists.xenproject.org; Mon, 30 Dec 2024 21:38: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 675c6320-c6f6-11ef-a0db-8be0dac302b0;
 Mon, 30 Dec 2024 22:38:27 +0100 (CET)
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-436281c8a38so68808765e9.3
 for ; Mon, 30 Dec 2024 13:38:27 -0800 (PST)
Received: from [192.168.86.29] ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4366e210cecsm331680555e9.2.2024.12.30.13.38.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Dec 2024 13:38: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: 675c6320-c6f6-11ef-a0db-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1735594706; x=1736199506; 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=oJffYIi5qutgzhH576unqR1diKIC1dYjPN9dS+C85B0=;
        b=uv1l77iqI5KxvnHfiI1voiyLHEBGMti0vndAwbzkHhHXK1qBNo+eIAKn5Uy0gr2fOp
         mu8IuJhZZIheZy7tZtkXDtX+hY/D6uQ6AEYeQGU3y8Y1CjqYW7Y4dVtkwsIP22xZ2+nx
         8oYzkHLzdIVS0tmXRZXCQscuLOnw1R0k8WP2I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735594706; x=1736199506;
        h=in-reply-to:autocrypt:from:content-language:references:cc:to
         :subject:user-agent:mime-version:date:message-id:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=oJffYIi5qutgzhH576unqR1diKIC1dYjPN9dS+C85B0=;
        b=aS6PmKOAAn0lmHMUuFy+Vxlj2FwFQRHDPkqgNQ8eQ8zSMT6/01g6IJq/zfMoEljeOD
         T2U3SrB7Phi/elKh69qV/Mgm7EEBNWBs81A032kulf28NrvgzT8ZGLr5USnYBiiWD0Dd
         hOvoBD6n4xL1ZhVtuhZLrfX/D06EvLyB8HcKoFcwftr5RHx3INQ70xqCqh5uUGlY/UxD
         e8Na3ySYHt/66wbab1lmGdsh+Qeme498j3jB5+aBWFrDKJTAV6lpr+xgpRLf64ByKDos
         sM2CCfHqlA8zNaPzLk7qZUSmASyKTfKz5SgIFyzlWpeYLpQP6yzvmA4Wq1hI9P7GE6TM
         SyVg==
X-Forwarded-Encrypted: i=1; AJvYcCVQhITSlqt7BLgk2UMdvGvvqI8x69wFiCG9Ay1RolNwOnSV42ofcD9/UWK53iZgeWg3UwwTRMePkiI=@lists.xenproject.org
X-Gm-Message-State: AOJu0YxQZp4h47WFwXN63CvqahsLX9EblktYFIuJab8Rga80mOexM814
	RINBf2KexMrKvOQNPLMYIByxYKlwO0WcM/GQyuIUpr/t6/y+67YWThogWoKwj3CN+DN0+eEc9RI
	LO1Y=
X-Gm-Gg: ASbGncstsB+nIbI7Fv8wL3MRMMpFwB1tSTg09YbDxJ8QOJmDEnRCyr0mR+4arUV1WGd
	jHqZyAJO512QLrdcplkWHgtvfzPjVsJ0Km7oEi1WE4Vl+Xu0WVK5eXiizuE6rjX0E8U2W5oHKoU
	XeGGdX6nRQh5S9rNCPHqEtZcpuaexqfAHmuh7gkKYNyrDKYt9OCzNYOEAJNt60DkDj5BHT43DGL
	+4f+1sWbC3eneQuEK7xl39o6SDmj1XLptYP0S5zkW+zrVJBKMZqBqtDwA8kaaiuY/M=
X-Google-Smtp-Source: AGHT+IEgZxHeICBm18wV8vgOeXFzikWq81a+bwNUZ6puMkZMQtTRhxxw4GISrYLG1JPwiUBld8k+Bg==
X-Received: by 2002:a05:600c:1d03:b0:434:a5bc:70fc with SMTP id 5b1f17b1804b1-43668642e70mr294021145e9.8.1735594706491;
        Mon, 30 Dec 2024 13:38:26 -0800 (PST)
Content-Type: multipart/mixed; boundary="------------wxhaatOR6HOj2e14hEB07Hvz"
Message-ID: <25f9fabf-1239-4465-92c9-484fc24fc4f7@citrix.com>
Date: Mon, 30 Dec 2024 21:38:24 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 2/5] docs: set DATE to SOURCE_DATE_EPOCH if available
To: Maximilian Engelhardt , xen-devel@lists.xenproject.org
Cc: Anthony PERARD 
References: 
 <1ad1283052a580cbe7dbd7581b64f3cfd87cbf88.1735585600.git.maxi@daemonizer.de>
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: <1ad1283052a580cbe7dbd7581b64f3cfd87cbf88.1735585600.git.maxi@daemonizer.de>

This is a multi-part message in MIME format.
--------------wxhaatOR6HOj2e14hEB07Hvz
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 30/12/2024 9:00 pm, Maximilian Engelhardt wrote:
> Use the solution described in [1] to replace the call to the 'date'
> command with a version that uses SOURCE_DATE_EPOCH if available. This
> is needed for reproducible builds.
>
> The -d "@..." syntax was introduced in GNU date about 2005 (but only
> added to the docuemntation in 2011), so I assume a version supporting
> this syntax is available, if SOURCE_DATE_EPOCH is defined. If
> SOURCE_DATE_EPOCH is not defined, nothing changes with respect to the
> current behavior.
>
> [1] https://reproducible-builds.org/docs/source-date-epoch/
>
> Signed-off-by: Maximilian Engelhardt 
> ---
>  docs/Makefile | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/docs/Makefile b/docs/Makefile
> index b30cc619f8..beba02a94f 100644
> --- a/docs/Makefile
> +++ b/docs/Makefile
> @@ -3,7 +3,13 @@ include $(XEN_ROOT)/Config.mk
>  -include $(XEN_ROOT)/config/Docs.mk
>  
>  VERSION		:= $(shell $(MAKE) -C $(XEN_ROOT)/xen --no-print-directory xenversion)
> -DATE		:= $(shell date +%Y-%m-%d)
> +
> +DATE_FMT	:= +%Y-%m-%d
> +ifdef SOURCE_DATE_EPOCH
> +DATE		:= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null || date -u "$(DATE_FMT)")
> +else
> +DATE		:= $(shell date "$(DATE_FMT)")
> +endif
>  
>  DOC_ARCHES      := arm x86_32 x86_64
>  MAN_SECTIONS    := 1 5 7 8

While this looks fine for docs, there's another (identical) use of date
in tools/firmware/hvmloader/Makefile, as well as some differing uses to
construct XEN_BUILD_{DATE,TIME}.  INSTALL talks about VGABIOS_REL_DATE too.

Does something like this work for you?  It seems to DTRT for SMBIOS.  It
needs adapting a bit more for vgabios and Xen, but I think having one
common $(date) is going to be better than ad-hoc ones over the tree.

~Andrew
--------------wxhaatOR6HOj2e14hEB07Hvz
Content-Type: text/x-patch; charset=UTF-8; name="SOURCE_DATE_EPOCH.patch"
Content-Disposition: attachment; filename="SOURCE_DATE_EPOCH.patch"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL0NvbmZpZy5tayBiL0NvbmZpZy5tawppbmRleCBmYTA0MTQwNTViOTMu
LjA5MzFlNzAyYjAyNSAxMDA2NDQKLS0tIGEvQ29uZmlnLm1rCisrKyBiL0NvbmZpZy5tawpA
QCAtMTQxLDYgKzE0MSwxNCBAQCBleHBvcnQgWEVOX0hBU19CVUlMRF9JRD15CiBidWlsZF9p
ZF9saW5rZXIgOj0gLS1idWlsZC1pZD1zaGExCiBlbmRpZgogCisjIFdyYXAgZGF0ZSgxKSB0
byB1c2UgU09VUkNFX0RBVEVfRVBPQ0ggaWYgc2V0IHRoZSBlbnZpcm9ubWVudC4KKyMgU2Vl
IGh0dHBzOi8vcmVwcm9kdWNpYmxlLWJ1aWxkcy5vcmcvZG9jcy9zb3VyY2UtZGF0ZS1lcG9j
aC8KK2lmZGVmIFNPVVJDRV9EQVRFX0VQT0NICitkYXRlID0gJChzaGVsbCBkYXRlIC11IC1k
ICJAJChTT1VSQ0VfREFURV9FUE9DSCkiICIkKDEpIiAyPi9kZXYvbnVsbCB8fCBkYXRlIC11
IC1yICIkKFNPVVJDRV9EQVRFX0VQT0NIKSIgIiQoMSkiIDI+L2Rldi9udWxsIHx8IGRhdGUg
LXUgIiQoMSkiKQorZWxzZQorZGF0ZSA9ICQoc2hlbGwgZGF0ZSAiJCgxKSIpCitlbmRpZgor
CiBkZWZpbmUgYnVpbGRtYWtldmFyczJzaGVsbHZhcnMKICAgICBleHBvcnQgUFJFRklYPSIk
KHByZWZpeCkiOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
XAogICAgIGV4cG9ydCBYRU5fU0NSSVBUX0RJUj0iJChYRU5fU0NSSVBUX0RJUikiOyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBcCmRpZmYgLS1naXQgYS9kb2NzL01ha2VmaWxlIGIv
ZG9jcy9NYWtlZmlsZQppbmRleCBiMzBjYzYxOWY4ZGQuLjk1ZGM4M2ZmOWM1OSAxMDA2NDQK
LS0tIGEvZG9jcy9NYWtlZmlsZQorKysgYi9kb2NzL01ha2VmaWxlCkBAIC0zLDcgKzMsNyBA
QCBpbmNsdWRlICQoWEVOX1JPT1QpL0NvbmZpZy5tawogLWluY2x1ZGUgJChYRU5fUk9PVCkv
Y29uZmlnL0RvY3MubWsKIAogVkVSU0lPTgkJOj0gJChzaGVsbCAkKE1BS0UpIC1DICQoWEVO
X1JPT1QpL3hlbiAtLW5vLXByaW50LWRpcmVjdG9yeSB4ZW52ZXJzaW9uKQotREFURQkJOj0g
JChzaGVsbCBkYXRlICslWS0lbS0lZCkKK0RBVEUJCTo9ICQoY2FsbCBkYXRlLCslWS0lbS0l
ZCkKIAogRE9DX0FSQ0hFUyAgICAgIDo9IGFybSB4ODZfMzIgeDg2XzY0CiBNQU5fU0VDVElP
TlMgICAgOj0gMSA1IDcgOApkaWZmIC0tZ2l0IGEvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVy
L01ha2VmaWxlIGIvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL01ha2VmaWxlCmluZGV4IGM3
YmM0MDA2NTc4YS4uMWU3N2IwMTRmNjE0IDEwMDY0NAotLS0gYS90b29scy9maXJtd2FyZS9o
dm1sb2FkZXIvTWFrZWZpbGUKKysrIGIvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL01ha2Vm
aWxlCkBAIC0yMyw3ICsyMyw3IEBAIGluY2x1ZGUgJChYRU5fUk9PVCkvdG9vbHMvZmlybXdh
cmUvUnVsZXMubWsKIGxkLW9wdGlvbiA9ICQoc2hlbGwgaWYgJChMRCkgLXYgJCgxKSA+L2Rl
di9udWxsIDI+JjE7IHRoZW4gZWNobyB5OyBlbHNlIGVjaG8gbjsgZmkpCiAKICMgU01CSU9T
IHNwZWMgcmVxdWlyZXMgZm9ybWF0IG1tL2RkL3l5eXkKLVNNQklPU19SRUxfREFURSA/PSAk
KHNoZWxsIGRhdGUgKyVtLyVkLyVZKQorU01CSU9TX1JFTF9EQVRFID89ICQoY2FsbCBkYXRl
LCslbS8lZC8lWSkKIAogQ0ZMQUdTICs9ICQoQ0ZMQUdTX3hlbmluY2x1ZGUpIC1mbm8tcGlj
IC1tcmVncGFybT0zCiAK

--------------wxhaatOR6HOj2e14hEB07Hvz--


From xen-devel-bounces@lists.xenproject.org Mon Dec 30 21:53:28 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Dec 2024 21:53:28 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863616.1274987 (Exim 4.92)
	(envelope-from )
	id 1tSNhS-0001RF-VU; Mon, 30 Dec 2024 21:53:22 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863616.1274987; Mon, 30 Dec 2024 21:53: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 1tSNhS-0001R8-Sh; Mon, 30 Dec 2024 21:53:22 +0000
Received: by outflank-mailman (input) for mailman id 863616;
 Mon, 30 Dec 2024 21:53: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 1tSNhR-0001R2-B7
 for xen-devel@lists.xenproject.org; Mon, 30 Dec 2024 21:53:21 +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 7b1ae4fc-c6f8-11ef-99a4-01e77a169b0f;
 Mon, 30 Dec 2024 22:53:19 +0100 (CET)
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-436341f575fso100115095e9.1
 for ; Mon, 30 Dec 2024 13:53:19 -0800 (PST)
Received: from [192.168.86.29] ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a1c848a47sm30712508f8f.62.2024.12.30.13.53.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Dec 2024 13:53:18 -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: 7b1ae4fc-c6f8-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1735595599; x=1736200399; 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=gZUi7UGwaKBR6JJvqimj61FdN9dv/1BvOOvYzpiO8mw=;
        b=GYtGnlT2BIJ1LaHBw6NBSTJa8aD8WVcMDsqwUnQ601cdw4T5HEzkJFiAfEu1dx1qs0
         gG4el5GWgia1Df0+F+2xBzW1slKfjKgcSAxt10c+1XFPJ5R4rApVxO/TZGINnaiotoJb
         kp9gpptLhwJA0SrLoaEwRRgrc+L2y4KEr7QQQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735595599; x=1736200399;
        h=content-transfer-encoding:in-reply-to:autocrypt:from
         :content-language:references:cc:to:subject:user-agent:mime-version
         :date:message-id:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=gZUi7UGwaKBR6JJvqimj61FdN9dv/1BvOOvYzpiO8mw=;
        b=XFMGTklkWORfH+6f3d8x1oz/7Rmnrqv9FV2lPJL1YdwM0wmN0ROs0As/zb2oqlbBkG
         cF9FVJv6cHTGvFDClhXlit51EyPPSw9XF/3H6iglmeG/vtA56PLMLlvjNDpb3cxChXMe
         160XSnGKAUjyc9CwZHz4QOEWCiXT722H/E80gcy1CGs8b3ZqPf3Rp7M3+lfb5n5jdGK4
         uExkH+YMNs7AO83b3aopmU6erSSY1IjdsvBr0a3qdx542Toa71e8emcn2Rje9UbROV4x
         SazglqYYPkk2yhGOhOguddnlnt081ggk18c/2ehWM6uKrWSzSAX/tRfx96SvmOFMF792
         buJg==
X-Forwarded-Encrypted: i=1; AJvYcCU3FJc0sQfwOyHYthPpOUAJkiE9PhavtfcSEkpcvLwCYxMh7JRtyt8Iv80h+X1VaVUjDtRGZ+qxMS4=@lists.xenproject.org
X-Gm-Message-State: AOJu0YwcPV59w4UJPSrqozwzlC33GasyHOk7w8fCe19xXboQLiW4g6DI
	ZOdlaziwXi9hRF07HcomoyLGhmjlOH2HUDG0VslNY3fTPacESWPIxLyGHnPzCtU=
X-Gm-Gg: ASbGncvmo/mYkSH40AG3q7dwFdKIZEsbYRZS5TafQKmlF8fkmwuF/cpooK+zBHJolrr
	5TZC+ChghV9ecPay4y3T6yD1oUkae6+92+L6M6+WnpLJxXgSGZsnuROGYSZ49qPfyjm6b/zQl6x
	lOWHFRjpN169fxrTclFC0FzB5R/vzgGiaUsGUaibQnZWIg2I3W5gRcaa1jlXbRQQEcyAnx/KdBB
	ys/qnvrs8H6KdElf1PHoK3MPcvRRbswI1Zp30IBa0ITQy80hqjLTsfJDVOuUgEde08=
X-Google-Smtp-Source: AGHT+IENve12XVoRefxMJ8ewLR1XlxsqmyqFV6gzFw1auS5A1JNTDhQ4BY9Ojmmyz2NUUBTH3aiSBg==
X-Received: by 2002:adf:a445:0:b0:38a:2b39:9205 with SMTP id ffacd0b85a97d-38a2b3993dfmr23487729f8f.33.1735595598673;
        Mon, 30 Dec 2024 13:53:18 -0800 (PST)
Message-ID: <5e4c9b33-7250-48b6-9a35-6ca4ee9342b8@citrix.com>
Date: Mon, 30 Dec 2024 21:53:17 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [XEN PATCH 0/5] Fixes for reproducible builds and other small
 fixes
To: Maximilian Engelhardt , xen-devel@lists.xenproject.org
Cc: Anthony PERARD ,
 Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?=
 , Juergen Gross 
References: 
Content-Language: en-GB
From: Andrew Cooper 
Autocrypt: addr=andrew.cooper3@citrix.com; keydata=
 xsFNBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp
 VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn
 srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR
 Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E
 ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5
 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe
 LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV
 e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5
 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ
 ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABzSlBbmRyZXcgQ29v
 cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPsLBegQTAQgAJAIbAwULCQgHAwUVCgkI
 CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO
 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh
 IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4
 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z
 JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK
 mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET
 ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy
 RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi
 dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF
 /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt
 TQTBLzDKXok86M7BTQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4
 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn
 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p
 vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU
 g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy
 wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd
 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i
 kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1
 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk
 uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAcLB
 XwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ
 HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd
 pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA
 vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk
 b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg
 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP
 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i
 nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ
 B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo
 d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs
 6+ahAA==
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 30/12/2024 9:00 pm, Maximilian Engelhardt wrote:
> This series is a bunch of fixes we found while packaging Xen in Debian
> and we believe they should be best addressed upstream.
>
> We have been carrying the first patch for a long time in Debian, but it
> seems it never was applied upstream. It's an addition to
> "docs/man: Provide properly-formatted NAME sections"
> (commit 423c4def1f7a01eeff56fa70564180640ef3af43).
>
> Patch two and three are fixes for reproducibility issues that I found
> using our testing gear in Debian.
>
> The last two patches are trivial fixes correcting two common typos found
> by Debian tools.

These are all very simple and obvious. I've summarily acked and taken
all patches other than 2, where I've got a question/suggestion.

https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1606875387

~Andrew


From xen-devel-bounces@lists.xenproject.org Mon Dec 30 22:29:12 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Dec 2024 22:29:12 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863625.1274996 (Exim 4.92)
	(envelope-from )
	id 1tSOFn-00066D-Et; Mon, 30 Dec 2024 22:28:51 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863625.1274996; Mon, 30 Dec 2024 22: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 1tSOFn-000666-CD; Mon, 30 Dec 2024 22:28:51 +0000
Received: by outflank-mailman (input) for mailman id 863625;
 Mon, 30 Dec 2024 22: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 1tSOFm-000660-00
 for xen-devel@lists.xenproject.org; Mon, 30 Dec 2024 22:28:50 +0000
Received: from mx1.somlen.de (typhoon.somlen.de [89.238.64.140])
 by se1-gles-sth1.inumbo.com (Halon) with ESMTPS
 id 70074a8e-c6fd-11ef-a0db-8be0dac302b0;
 Mon, 30 Dec 2024 23:28:48 +0100 (CET)
Received: by mx1.somlen.de with ESMTPSA id BB47C5030C1;
 Mon, 30 Dec 2024 23:28:45 +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: 70074a8e-c6fd-11ef-a0db-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daemonizer.de;
	s=202303; t=1735597727;
	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=+Ita93vdWUbvoarX6Q3Ge6UGZ9iYdaMP4K/oLl5RKmw=;
	b=jSupqSZyQnHrIPGAS/o6lQ9KS9pHIYJuWLuPM7lKzVDecwmIE5Mp4BQb0sYROkJcn6HEVn
	YR4HJKvfEysI9e0/pNqgu5rBgGbG2atv+fNND8W1Ei5AAY5Ndk/rS/ijsXkUioRwP4yDC3
	xPcieNSJaWNfn43E6V+pu2ZrPjaPeHh4obuYuUYRMUXYHJVxdVCHA4SEDE1dhZQ4xq20D4
	RBNWx6fWW8VgG0sGjPMko/exdowLTjACLXscwqsh6M5lBSnGbdpfPo36jhNQR1zS84j9ai
	Bmya8af4wjLVunpNrWeDR3VuO+4AB0X110Ozd90JNkC+K27mGKsEzhJmpoEEzw==
From: Maximilian Engelhardt 
To: xen-devel@lists.xenproject.org, Andrew Cooper 
Cc: Anthony PERARD 
Subject: Re: [XEN PATCH 2/5] docs: set DATE to SOURCE_DATE_EPOCH if available
Date: Mon, 30 Dec 2024 23:28:42 +0100
Message-ID: <2637960.Lt9SDvczpP@localhost>
In-Reply-To: <25f9fabf-1239-4465-92c9-484fc24fc4f7@citrix.com>
References:
 
 <1ad1283052a580cbe7dbd7581b64f3cfd87cbf88.1735585600.git.maxi@daemonizer.de>
 <25f9fabf-1239-4465-92c9-484fc24fc4f7@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4398195.ejJDZkT8p0";
 micalg="pgp-sha512"; protocol="application/pgp-signature"

--nextPart4398195.ejJDZkT8p0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"; protected-headers="v1"
From: Maximilian Engelhardt 
Cc: Anthony PERARD 
Date: Mon, 30 Dec 2024 23:28:42 +0100
Message-ID: <2637960.Lt9SDvczpP@localhost>
In-Reply-To: <25f9fabf-1239-4465-92c9-484fc24fc4f7@citrix.com>
MIME-Version: 1.0

On Montag, 30. Dezember 2024 22:38:24 CET Andrew Cooper wrote:
> On 30/12/2024 9:00 pm, Maximilian Engelhardt wrote:
> > Use the solution described in [1] to replace the call to the 'date'
> > command with a version that uses SOURCE_DATE_EPOCH if available. This
> > is needed for reproducible builds.
> > 
> > The -d "@..." syntax was introduced in GNU date about 2005 (but only
> > added to the docuemntation in 2011), so I assume a version supporting
> > this syntax is available, if SOURCE_DATE_EPOCH is defined. If
> > SOURCE_DATE_EPOCH is not defined, nothing changes with respect to the
> > current behavior.
> > 
> > [1] https://reproducible-builds.org/docs/source-date-epoch/
> > 
> > Signed-off-by: Maximilian Engelhardt 
> > ---
> > 
> >  docs/Makefile | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/docs/Makefile b/docs/Makefile
> > index b30cc619f8..beba02a94f 100644
> > --- a/docs/Makefile
> > +++ b/docs/Makefile
> > @@ -3,7 +3,13 @@ include $(XEN_ROOT)/Config.mk
> > 
> >  -include $(XEN_ROOT)/config/Docs.mk
> >  
> >  VERSION		:= $(shell $(MAKE) -C $(XEN_ROOT)/xen --no-print-directory
> >  xenversion)> 
> > -DATE		:= $(shell date +%Y-%m-%d)
> > +
> > +DATE_FMT	:= +%Y-%m-%d
> > +ifdef SOURCE_DATE_EPOCH
> > +DATE		:= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)"
> > 2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)"
> > 2>/dev/null || date -u "$(DATE_FMT)") +else
> > +DATE		:= $(shell date "$(DATE_FMT)")
> > +endif
> > 
> >  DOC_ARCHES      := arm x86_32 x86_64
> >  MAN_SECTIONS    := 1 5 7 8
> 
> While this looks fine for docs, there's another (identical) use of date
> in tools/firmware/hvmloader/Makefile, as well as some differing uses to
> construct XEN_BUILD_{DATE,TIME}.  INSTALL talks about VGABIOS_REL_DATE too.
> 
> Does something like this work for you?  It seems to DTRT for SMBIOS.  It
> needs adapting a bit more for vgabios and Xen, but I think having one
> common $(date) is going to be better than ad-hoc ones over the tree.
> 
> ~Andrew

Hi Andrew,

Thanks for your quick reply. Your patch looks fine to me. You can add my 
Tested-by.

We currently use "export XEN_BUILD_{DATE,TIME}=...", "export 
SMBIOS_REL_DATE=..." and "export VGABIOS_REL_DATE=..." for building xen in 
Debian, so we did not run into reproducibility problems with these. But having 
them combined to all use SOURCE_DATE_EPOCH if available sounds like a good 
idea and would also benefit other downstream users.

Maxi
--nextPart4398195.ejJDZkT8p0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

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

iQIzBAABCgAdFiEEQ8gZ7vwsPje0uPkIgepkfSQr0hUFAmdzHpoACgkQgepkfSQr
0hVIMQ/+KKq0VeyjhWQZJA1tY4t8aYU+DJavX6G9jTzJfYHUx3ZTx7sLoI4Ji9kb
YlAADW6VFvn4CDCJBaX/CbXHSlv4aX9xOBlwx1VlG05fmZ62WnsPy9xAcxBIXyEe
3DcSPVt5GOBmL+cwkXpdQqfE2Ffeftudq4gAfiwn5NiTZA/Mqf4n0Uij1eJgd316
MQAFvPPHqgDYFJQiBf2HbKwlvdhLuDUl0hGM7NUflyu9hzhChQRKTZZ/k32OcFMm
Q7y8Gvldv29RPPEKLxp4N/49ekBXkQ1BULM4I4dIh4cfF3rPPDWNaL1uLPhcDPZb
KCmLKfPJhcwT/R/HN3rTIUAJIRzhZzuxIh7QJsl/vpnjB8LsD3DQ0WqPfPPXNJxr
fjjP5nlQr6KsMjIhOcuphujYLGHkWLZtDlw5Fth1fkhfI5tVndJ40gVt8b4Hl3Cw
cFS0CKZMvijPPhlrWQFTQkOny7eUM8dQgaxXq5S9nMajdI4Dh6s3FbAEl5eVBBt2
yiXCuJK6Ez1loXH49lb97oW+YAOmVQdgt2+1NfnE5o02RyuQfeLGF59H6Q6eQW8x
IsnMxMurA4EroZ9+58eleJyaddGEVjpnGxlJTbLMveK9HBl/HipGaGFEg0AmtvsS
YzJc+aOjmDP0LzNmL+JvVtZxcFOMzoiaOKFt/GPScJKzQsvwDZI=
=xmWe
-----END PGP SIGNATURE-----

--nextPart4398195.ejJDZkT8p0--





From xen-devel-bounces@lists.xenproject.org Tue Dec 31 18:28:23 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Dec 2024 18:28:23 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863656.1275039 (Exim 4.92)
	(envelope-from )
	id 1tSgyG-0001ZW-41; Tue, 31 Dec 2024 18:28:00 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863656.1275039; Tue, 31 Dec 2024 18:28:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xenproject.org)
	by lists.xenproject.org with esmtp (Exim 4.92)
	(envelope-from )
	id 1tSgyF-0001ZJ-V5; Tue, 31 Dec 2024 18:27:59 +0000
Received: by outflank-mailman (input) for mailman id 863656;
 Tue, 31 Dec 2024 18:27: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 1tSgyE-0001ZD-R0
 for xen-devel@lists.xenproject.org; Tue, 31 Dec 2024 18:27:58 +0000
Received: from raptorengineering.com (mail.raptorengineering.com
 [23.155.224.40]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS
 id f303fbbb-c7a4-11ef-99a4-01e77a169b0f;
 Tue, 31 Dec 2024 19:27:55 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 1E280828748D;
 Tue, 31 Dec 2024 12:27:53 -0600 (CST)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id WQAJRjqvMRlD; Tue, 31 Dec 2024 12:27:52 -0600 (CST)
Received: from localhost (localhost [127.0.0.1])
 by mail.rptsys.com (Postfix) with ESMTP id 2259E8285AFA;
 Tue, 31 Dec 2024 12:27:52 -0600 (CST)
Received: from mail.rptsys.com ([127.0.0.1])
 by localhost (vali.starlink.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id Nlv6BOengAJj; Tue, 31 Dec 2024 12:27:52 -0600 (CST)
Received: from raptor-ewks-026.lan (5.edge.rptsys.com [23.155.224.38])
 by mail.rptsys.com (Postfix) with ESMTPSA id 264D182874CC;
 Tue, 31 Dec 2024 12:27:51 -0600 (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: f303fbbb-c7a4-11ef-99a4-01e77a169b0f
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.rptsys.com 2259E8285AFA
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=raptorengineering.com; s=B8E824E6-0BE2-11E6-931D-288C65937AAD;
	t=1735669672; bh=4YNY4+q8KFRGADVhrnvM+Q0mRQeZ0Go8N6ELKaJDOQs=;
	h=From:To:Date:Message-Id:MIME-Version;
	b=KznQE2G5Gj3byPVkCUPTQrajNjvteC2AmDZhSS0paaMRZPJeUwkHiDp1yKlnzr7yF
	 RVCKuuINONcSJ8kDMjHcgfbzSsUIMiercO6/Duq0a1/YiCKLteFPB3vy/eNzo3vG+Q
	 wxYphuygZsCII/BuFI1CHSyLwDUDE6zpIKfklP5c=
X-Virus-Scanned: amavisd-new at rptsys.com
From: Shawn Anastasio 
To: xen-devel@lists.xenproject.org
Cc: tpearson@raptorengineering.com,
	Shawn Anastasio ,
	Andrew Cooper ,
	Anthony PERARD ,
	Michal Orzel ,
	Jan Beulich ,
	Julien Grall ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Stefano Stabellini ,
	"Daniel P. Smith" ,
	=?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= 
Subject: [PATCH] xen/mm: Introduce per-arch pte_attr_t type for PTE flags
Date: Tue, 31 Dec 2024 12:27:44 -0600
Message-Id: <47babd3f9ec00c15738a81aa57926e8a1f08cbe6.1735669493.git.sanastasio@raptorengineering.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Xen's memory management APIs map_pages_to_xen, modify_xen_mappings,
set_fixmap, ioremap_attr, and __vmap all use an unsigned int to
represent architecture-dependent page table entry flags. This assumption
does not work on PPC/radix where some flags go past 32-bits, so
introduce the pte_attr_t type to allow architectures to opt in to larger
types to store PTE flags.

Suggested-by: Andrew Cooper 
Signed-off-by: Shawn Anastasio 
---
 xen/arch/ppc/Kconfig             | 1 +
 xen/arch/ppc/include/asm/types.h | 2 ++
 xen/arch/ppc/mm-radix.c          | 2 +-
 xen/common/Kconfig               | 3 +++
 xen/common/efi/boot.c            | 4 ++--
 xen/common/vmap.c                | 2 +-
 xen/include/xen/mm.h             | 8 ++++++--
 xen/include/xen/vmap.h           | 3 ++-
 8 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/xen/arch/ppc/Kconfig b/xen/arch/ppc/Kconfig
index 6db575a48d..3fae481117 100644
--- a/xen/arch/ppc/Kconfig
+++ b/xen/arch/ppc/Kconfig
@@ -3,6 +3,7 @@ config PPC
 	select FUNCTION_ALIGNMENT_4B
 	select HAS_DEVICE_TREE
 	select HAS_VMAP
+	select HAS_PTE_ATTR_T
 
 config PPC64
 	def_bool y
diff --git a/xen/arch/ppc/include/asm/types.h b/xen/arch/ppc/include/asm/types.h
index ffaf378a4d..a0b12f816a 100644
--- a/xen/arch/ppc/include/asm/types.h
+++ b/xen/arch/ppc/include/asm/types.h
@@ -8,4 +8,6 @@ typedef unsigned long vaddr_t;
 #define INVALID_PADDR (~0UL)
 #define PRIpaddr "016lx"
 
+typedef unsigned long pte_attr_t;
+
 #endif /* _ASM_PPC_TYPES_H */
diff --git a/xen/arch/ppc/mm-radix.c b/xen/arch/ppc/mm-radix.c
index 24232f3907..e02dffa7c5 100644
--- a/xen/arch/ppc/mm-radix.c
+++ b/xen/arch/ppc/mm-radix.c
@@ -265,7 +265,7 @@ int destroy_xen_mappings(unsigned long s, unsigned long e)
 int map_pages_to_xen(unsigned long virt,
                      mfn_t mfn,
                      unsigned long nr_mfns,
-                     unsigned int flags)
+                     pte_attr_t flags)
 {
     BUG_ON("unimplemented");
 }
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 6166327f4d..017075d667 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -80,6 +80,9 @@ config HAS_PIRQ
 config HAS_PMAP
 	bool
 
+config HAS_PTE_ATTR_T
+	bool
+
 config HAS_SCHED_GRANULARITY
 	bool
 
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index efbec00af9..c200a27523 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1656,7 +1656,7 @@ void __init efi_init_memory(void)
     struct rt_extra {
         struct rt_extra *next;
         unsigned long smfn, emfn;
-        unsigned int prot;
+        pte_attr_t prot;
     } *extra, *extra_head = NULL;
 
     free_ebmalloc_unused_mem();
@@ -1671,7 +1671,7 @@ void __init efi_init_memory(void)
         EFI_MEMORY_DESCRIPTOR *desc = efi_memmap + i;
         u64 len = desc->NumberOfPages << EFI_PAGE_SHIFT;
         unsigned long smfn, emfn;
-        unsigned int prot = PAGE_HYPERVISOR_RWX;
+        pte_attr_t prot = PAGE_HYPERVISOR_RWX;
         paddr_t mem_base;
         unsigned long mem_npages;
 
diff --git a/xen/common/vmap.c b/xen/common/vmap.c
index 47225fecc0..d6991421f3 100644
--- a/xen/common/vmap.c
+++ b/xen/common/vmap.c
@@ -222,7 +222,7 @@ static void vm_free(const void *va)
 }
 
 void *__vmap(const mfn_t *mfn, unsigned int granularity,
-             unsigned int nr, unsigned int align, unsigned int flags,
+             unsigned int nr, unsigned int align, pte_attr_t flags,
              enum vmap_region type)
 {
     void *va = vm_alloc(nr * granularity, align, type);
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 16f733281a..5386f931e7 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -70,6 +70,10 @@
 #include 
 #include 
 
+#ifndef CONFIG_HAS_PTE_ATTR_T
+typedef unsigned int pte_attr_t;
+#endif
+
 struct page_info;
 
 extern bool using_static_heap;
@@ -113,9 +117,9 @@ int map_pages_to_xen(
     unsigned long virt,
     mfn_t mfn,
     unsigned long nr_mfns,
-    unsigned int flags);
+    pte_attr_t flags);
 /* Alter the permissions of a range of Xen virtual address space. */
-int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf);
+int modify_xen_mappings(unsigned long s, unsigned long e, pte_attr_t nf);
 void modify_xen_mappings_lite(unsigned long s, unsigned long e,
                               unsigned int nf);
 int destroy_xen_mappings(unsigned long s, unsigned long e);
diff --git a/xen/include/xen/vmap.h b/xen/include/xen/vmap.h
index 26c831757a..9e2edd1252 100644
--- a/xen/include/xen/vmap.h
+++ b/xen/include/xen/vmap.h
@@ -8,6 +8,7 @@
 #ifndef __XEN_VMAP_H__
 #define __XEN_VMAP_H__
 
+#include 
 #include 
 #include 
 
@@ -57,7 +58,7 @@ void vm_init_type(enum vmap_region type, void *start, void *end);
  * @return Pointer to the mapped area on success; NULL otherwise.
  */
 void *__vmap(const mfn_t *mfn, unsigned int granularity, unsigned int nr,
-             unsigned int align, unsigned int flags, enum vmap_region type);
+             unsigned int align, pte_attr_t flags, enum vmap_region type);
 
 /*
  * Map an array of pages contiguously into the VMAP_DEFAULT vmap region
-- 
2.30.2



From xen-devel-bounces@lists.xenproject.org Tue Dec 31 19:20:14 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Dec 2024 19:20:14 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863668.1275048 (Exim 4.92)
	(envelope-from )
	id 1tShmi-00006C-Pd; Tue, 31 Dec 2024 19:20:08 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863668.1275048; Tue, 31 Dec 2024 19: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 1tShmi-000065-Mi; Tue, 31 Dec 2024 19:20:08 +0000
Received: by outflank-mailman (input) for mailman id 863668;
 Tue, 31 Dec 2024 19:20: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 1tShmh-0008Vq-BB
 for xen-devel@lists.xenproject.org; Tue, 31 Dec 2024 19:20:07 +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 3d9edc79-c7ac-11ef-a0db-8be0dac302b0;
 Tue, 31 Dec 2024 20:20:05 +0100 (CET)
Received: by mail-wm1-x336.google.com with SMTP id
 5b1f17b1804b1-4361f796586so106577315e9.3
 for ; Tue, 31 Dec 2024 11:20:05 -0800 (PST)
Received: from andrewcoop.lan ([83.105.36.37])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-38a47c9b2efsm14205348f8f.91.2024.12.31.11.20.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 31 Dec 2024 11: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: 3d9edc79-c7ac-11ef-a0db-8be0dac302b0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=citrix.com; s=google; t=1735672804; x=1736277604; 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=AKJNee8+koEDEhUpnEzgt+wwXlnSHYGx/h4AKjofkGI=;
        b=OuRPmN0/HW2wF4CDg2M4r8zcZaUULGWB0AqV4QLotGQBI6pCOyIpfwVejUhEEKYgDW
         0lA/evj/mDkQjO9XLzSyBNN9liYKO4WSD6ziTXXGQg6LR2cY6FMyhSmsLLhUtwDPC4zd
         Vkk03aK5BZvBgnrwSTwtsseF7WP2pCNK7ZEbA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1735672804; x=1736277604;
        h=content-transfer-encoding:mime-version:message-id:date:subject:cc
         :to:from:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=AKJNee8+koEDEhUpnEzgt+wwXlnSHYGx/h4AKjofkGI=;
        b=WAQSdKxCGjpKpbhFOdYP5g8GYqXV8u9lebTdQ5PfzqN5mTUDxtS58j5P9hhik4fH0E
         6rDXYbSAoxdskGmXWZQyGUDJQDIpXZLVrAfYiwpGhvJ1Rnbk6hdMl0UD+NAGfVBo2Q6v
         eMIqHebwvU2KbMOd8jBPjH80KdvsA4YjRiopi4fHTU69rG2HViEFk19U8xSucdBTudiC
         9H/Zq8INwU1E+uRt5pL1CtOT8mC8dLUFu8wICGqDTZUBqOA+GKtWhRL3wpA4oLMD+Qvv
         aSXqoCn5RNASajOYqJjG42+YEXjyRqYsLDaBbdds4pV5IqIwdGKbcQn6l2R3PhX4CUVY
         dwBQ==
X-Gm-Message-State: AOJu0YwI3txC5gURVQ9QiBqbyk4mQdmXEo6YTcL0uzAlgft/+/sdANRD
	p1XO5gJJRSbgxGx59N16LJkogmnHg0atvgaVboTAys/mbauOig455ILdcOWNsI2jBP75k5yzbul
	AMpJL5Q==
X-Gm-Gg: ASbGncv3efFbPA6ICaVPIiTedWkicNeQLEHnI0EFnknETvUN9q5zP3m4j7XdKHOqPB8
	+KRygLANmbje7aLyX053nIv3e7Gr6gqgITU29fYPhBGlUZPM4A2mbWX2ZgAcYB2MHs05chtg3LM
	D4eLuC2QoTqZutltIsoO7cJkeqSMTQY1uS0oJ4rWnwpJo/E7DhuthvebpO3n/8S6mvZMPjvuXXC
	v8kI5m6kqxZwG+1i8fai89RKJAkNkiHxOTtGD9pskOyLjW+1Ouu+zJ2el+aLpbdmQ==
X-Google-Smtp-Source: AGHT+IEY1BUSmaKkGxGmKlNStEWO7pTkgxGUBRc0nN73AsGWI10o4S/9qM60oFBsJq17gUGt4o0p9g==
X-Received: by 2002:a5d:6481:0:b0:385:e2d5:cdf2 with SMTP id ffacd0b85a97d-38a221eaba2mr31848737f8f.19.1735672804560;
        Tue, 31 Dec 2024 11:20:04 -0800 (PST)
From: Andrew Cooper 
To: Xen-devel 
Cc: Andrew Cooper ,
	Jan Beulich ,
	=?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= ,
	Oleksii Kurochko 
Subject: [PATCH for-4.20] x86/traps: Rework LER initialisation and support Zen5/Diamond Rapids
Date: Tue, 31 Dec 2024 19:20:02 +0000
Message-Id: <20241231192002.1753737-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

AMD have always used the architectural MSRs for LER.  As the first processor
to support LER was the K7 (which was 32bit), we can assume it's presence
unconditionally in 64bit mode.

Intel are about to run out of space in Family 6 and start using 19.  It is
only the Pentium 4 which uses non-architectural LER MSRs.

percpu_traps_init(), which runs on every CPU, contains a lot of code which
should be init-only, and is the only reason why opt_ler can't be in initdata.

Write a brand new init_ler() which expects all future Intel and AMD CPUs to
continue using the architectural MSRs, and does all setup together.  Call it
from trap_init(), and remove the setup logic percpu_traps_init() except for
the single path configuring MSR_IA32_DEBUGCTLMSR.

Leave behind a warning if the user asked for LER and Xen couldn't enable it.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Oleksii Kurochko 

For 4.20.  This is needed for Zen5 CPUs (already available) as well as Intel
CPUs coming shortly.  It also moves some non-init logic to being init-only.
---
 xen/arch/x86/traps.c | 86 ++++++++++++++++++++------------------------
 1 file changed, 39 insertions(+), 47 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index fd8a4448e3f7..377194d7b620 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -114,7 +114,7 @@ DEFINE_PER_CPU_PAGE_ALIGNED(struct tss_page, tss_page);
 static int debug_stack_lines = 20;
 integer_param("debug_stack_lines", debug_stack_lines);
 
-static bool __ro_after_init opt_ler;
+static bool __initdata opt_ler;
 boolean_param("ler", opt_ler);
 
 /* LastExceptionFromIP on this hardware.  Zero if LER is not in use. */
@@ -2092,56 +2092,10 @@ static void __init set_intr_gate(unsigned int n, void *addr)
     __set_intr_gate(n, 0, addr);
 }
 
-static unsigned int noinline __init calc_ler_msr(void)
-{
-    switch ( boot_cpu_data.x86_vendor )
-    {
-    case X86_VENDOR_INTEL:
-        switch ( boot_cpu_data.x86 )
-        {
-        case 6:
-            return MSR_IA32_LASTINTFROMIP;
-
-        case 15:
-            return MSR_P4_LER_FROM_LIP;
-        }
-        break;
-
-    case X86_VENDOR_AMD:
-        switch ( boot_cpu_data.x86 )
-        {
-        case 6:
-        case 0xf ... 0x19:
-            return MSR_IA32_LASTINTFROMIP;
-        }
-        break;
-
-    case X86_VENDOR_HYGON:
-        return MSR_IA32_LASTINTFROMIP;
-    }
-
-    return 0;
-}
-
 void percpu_traps_init(void)
 {
     subarch_percpu_traps_init();
 
-    if ( !opt_ler )
-        return;
-
-    if ( !ler_msr )
-    {
-        ler_msr = calc_ler_msr();
-        if ( !ler_msr )
-        {
-            opt_ler = false;
-            return;
-        }
-
-        setup_force_cpu_cap(X86_FEATURE_XEN_LBR);
-    }
-
     if ( cpu_has_xen_lbr )
         wrmsrl(MSR_IA32_DEBUGCTLMSR, IA32_DEBUGCTLMSR_LBR);
 }
@@ -2201,6 +2155,42 @@ void __init init_idt_traps(void)
         this_cpu(compat_gdt) = boot_compat_gdt;
 }
 
+static void __init init_ler(void)
+{
+    unsigned int msr = 0;
+
+    if ( !opt_ler )
+        return;
+
+    /*
+     * Intel Pentium 4 is the only known CPU to not use the architectural MSR
+     * indicies.
+     */
+    switch ( boot_cpu_data.x86_vendor )
+    {
+    case X86_VENDOR_INTEL:
+        if ( boot_cpu_data.x86 == 0xf )
+        {
+            ler_msr = MSR_P4_LER_FROM_LIP;
+            break;
+        }
+        fallthrough;
+    case X86_VENDOR_AMD:
+    case X86_VENDOR_HYGON:
+        ler_msr = MSR_IA32_LASTINTFROMIP;
+        break;
+    }
+
+    if ( msr == 0 )
+    {
+        printk(XENLOG_WARNING "LER disabled: failed to identy MSRs\n");
+        return;
+    }
+
+    ler_msr = msr;
+    setup_force_cpu_cap(X86_FEATURE_XEN_LBR);
+}
+
 extern void (*const autogen_entrypoints[X86_NR_VECTORS])(void);
 void __init trap_init(void)
 {
@@ -2226,6 +2216,8 @@ void __init trap_init(void)
         }
     }
 
+    init_ler();
+
     /* Cache {,compat_}gdt_l1e now that physically relocation is done. */
     this_cpu(gdt_l1e) =
         l1e_from_pfn(virt_to_mfn(boot_gdt), __PAGE_HYPERVISOR_RW);
-- 
2.39.5



From xen-devel-bounces@lists.xenproject.org Tue Dec 31 22:26:00 2024
Return-path: 
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Dec 2024 22:26:00 +0000
Received: from list by lists.xenproject.org with outflank-mailman.863679.1275059 (Exim 4.92)
	(envelope-from )
	id 1tSkgF-0002wJ-ES; Tue, 31 Dec 2024 22:25:39 +0000
X-Outflank-Mailman: Message body and most headers restored to incoming version
Received: by outflank-mailman (output) from mailman id 863679.1275059; Tue, 31 Dec 2024 22:25: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 1tSkgF-0002wC-BW; Tue, 31 Dec 2024 22:25:39 +0000
Received: by outflank-mailman (input) for mailman id 863679;
 Tue, 31 Dec 2024 22:25:38 +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 1tSkgE-0002w6-87
 for xen-devel@lists.xenproject.org; Tue, 31 Dec 2024 22:25:38 +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 25f1a222-c7c6-11ef-99a4-01e77a169b0f;
 Tue, 31 Dec 2024 23:25:33 +0100 (CET)
Received: from phl-compute-03.internal (phl-compute-03.phl.internal
 [10.202.2.43])
 by mailfout.stl.internal (Postfix) with ESMTP id E72C01140128;
 Tue, 31 Dec 2024 17:25:31 -0500 (EST)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-03.internal (MEProxy); Tue, 31 Dec 2024 17:25:32 -0500
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 31 Dec 2024 17:25:30 -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: 25f1a222-c7c6-11ef-99a4-01e77a169b0f
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=cc:cc:content-type:content-type:date
	:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
	:references:reply-to:subject:subject:to:to; s=fm2; t=1735683931;
	 x=1735770331; bh=JTYvv1OPwK4BF7/ea9Q0WGY/bCj2Y9mzyQeLFZdQUxU=; b=
	IHnslYvuopyM9QAXkATiLkNgs2Ux54QYKjxmouiQzQbhNC0p5XRbIfnpMI+M1IFQ
	jwquAkLyconwXYoZykwNubltf77oQQ/FaV3x/eezc/FMkd2PboaZCTQLV768cNcD
	G/fV/9T/pXboYKa2aT8jcaMNUv01KQw38T4/rJivpff34BSDtJrd2Y7YQSEI854M
	1XWonmcvpvtCjjOVYZEPw+TNo/euWXP22BxTH9XxlYJthtiVUJhw1O8Du/wz/C1l
	bI8TakUA/7GiqWoaz8yfE+Toy5Y+MD1EvgaVux/sau5vZMqQn7NfZWTFHTqvoJ1h
	kSM27LclBs4EEl4SIwoyAg==
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=fm2; t=
	1735683931; x=1735770331; bh=JTYvv1OPwK4BF7/ea9Q0WGY/bCj2Y9mzyQe
	LFZdQUxU=; b=qb+Dc4dBQlpy00QtTdgBI7jYA8UJvI1RiwqOaTG25C1WqYsOTFl
	5wIVZUstxOL7A1mHpP3stcdHkRrBKNBilvW144KrkZOl1GnEj6sl+hIZ3lBQVfer
	NHtR3LsAKVIyGwqqss68QYmLwA6csC6MtKbN5pg1tE7ICVg65zbZQeJUupKB8v7U
	Vm2cgbn5E8sqbQWpjTwdkFeqkX1S49pXDk/e+F/JgPNqnxsnz2pn3uIRRl+rhSUu
	wzHiBDcR9BZHh/7rLiZ+kcqJD8v5wyTSAqHsr45t8q3mVUARSsPvY0uz/EuE7xuB
	z5I00I26QoScy4iLw7WaO38JHQRDwtpn6Fw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddruddvkedgudeiudcutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
    uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg
    hnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdej
    necuhfhrohhmpeforghrvghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoe
    hmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucgg
    tffrrghtthgvrhhnpefgudelteefvefhfeehieetleeihfejhfeludevteetkeevtedtvd
    egueetfeejudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr
    ohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpd
    hnsggprhgtphhtthhopeehpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegrnhgu
    rhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthhtohepgigvnhdqug
    gvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohepjhgs
    vghulhhitghhsehsuhhsvgdrtghomhdprhgtphhtthhopehrohhgvghrrdhprghusegtih
    htrhhigidrtghomhdprhgtphhtthhopeholhgvkhhsihhirdhkuhhrohgthhhkohesghhm
    rghilhdrtghomh
X-ME-Proxy: 
    
    
    
    
Feedback-ID: i1568416f:Fastmail
Date: Tue, 31 Dec 2024 23:25:28 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Jan Beulich ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Oleksii Kurochko 
Subject: Re: [PATCH for-4.20] x86/traps: Rework LER initialisation and
 support Zen5/Diamond Rapids
Message-ID: 
References: <20241231192002.1753737-1-andrew.cooper3@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="+B+Fr2JDn72RbV1s"
Content-Disposition: inline
In-Reply-To: <20241231192002.1753737-1-andrew.cooper3@citrix.com>


--+B+Fr2JDn72RbV1s
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 31 Dec 2024 23:25:28 +0100
From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
To: Andrew Cooper 
Cc: Xen-devel ,
	Jan Beulich ,
	Roger Pau =?utf-8?B?TW9ubsOp?= ,
	Oleksii Kurochko 
Subject: Re: [PATCH for-4.20] x86/traps: Rework LER initialisation and
 support Zen5/Diamond Rapids

On Tue, Dec 31, 2024 at 07:20:02PM +0000, Andrew Cooper wrote:
> AMD have always used the architectural MSRs for LER.  As the first proces=
sor
> to support LER was the K7 (which was 32bit), we can assume it's presence
> unconditionally in 64bit mode.
>=20
> Intel are about to run out of space in Family 6 and start using 19.  It is
> only the Pentium 4 which uses non-architectural LER MSRs.
>=20
> percpu_traps_init(), which runs on every CPU, contains a lot of code which
> should be init-only, and is the only reason why opt_ler can't be in initd=
ata.
>=20
> Write a brand new init_ler() which expects all future Intel and AMD CPUs =
to
> continue using the architectural MSRs, and does all setup together.  Call=
 it
> from trap_init(), and remove the setup logic percpu_traps_init() except f=
or
> the single path configuring MSR_IA32_DEBUGCTLMSR.
>=20
> Leave behind a warning if the user asked for LER and Xen couldn't enable =
it.
>=20
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Roger Pau Monn=C3=A9 
> CC: Oleksii Kurochko 
>=20
> For 4.20.  This is needed for Zen5 CPUs (already available) as well as In=
tel
> CPUs coming shortly.  It also moves some non-init logic to being init-onl=
y.
> ---

=2E..

> @@ -2201,6 +2155,42 @@ void __init init_idt_traps(void)
>          this_cpu(compat_gdt) =3D boot_compat_gdt;
>  }
> =20
> +static void __init init_ler(void)
> +{
> +    unsigned int msr =3D 0;
> +
> +    if ( !opt_ler )
> +        return;
> +
> +    /*
> +     * Intel Pentium 4 is the only known CPU to not use the architectura=
l MSR
> +     * indicies.
> +     */
> +    switch ( boot_cpu_data.x86_vendor )
> +    {
> +    case X86_VENDOR_INTEL:
> +        if ( boot_cpu_data.x86 =3D=3D 0xf )
> +        {
> +            ler_msr =3D MSR_P4_LER_FROM_LIP;

msr =3D=20

and ...

> +            break;
> +        }
> +        fallthrough;
> +    case X86_VENDOR_AMD:
> +    case X86_VENDOR_HYGON:
> +        ler_msr =3D MSR_IA32_LASTINTFROMIP;

=2E.. here?

But also, why temporary variable? Is there something else that would set
non-zero value that should be preserved?

> +        break;
> +    }
> +
> +    if ( msr =3D=3D 0 )
> +    {
> +        printk(XENLOG_WARNING "LER disabled: failed to identy MSRs\n");
> +        return;
> +    }
> +
> +    ler_msr =3D msr;
> +    setup_force_cpu_cap(X86_FEATURE_XEN_LBR);
> +}
> +
>  extern void (*const autogen_entrypoints[X86_NR_VECTORS])(void);
>  void __init trap_init(void)
>  {
> @@ -2226,6 +2216,8 @@ void __init trap_init(void)
>          }
>      }
> =20
> +    init_ler();
> +
>      /* Cache {,compat_}gdt_l1e now that physically relocation is done. */
>      this_cpu(gdt_l1e) =3D
>          l1e_from_pfn(virt_to_mfn(boot_gdt), __PAGE_HYPERVISOR_RW);
> --=20
> 2.39.5
>=20
>=20

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

--+B+Fr2JDn72RbV1s
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmd0b1gACgkQ24/THMrX
1yyVeggAmwTLccLYJPqWeHZJeVsYN+ScgmS1fdJXJ/U5TYclQVo/nA/dtkB9LJPl
eKkVYrD628OgSA8FQGkwgBpNSTtYXfIPwCmUu6+RluSwT4M2bkB5vTGkqhnglJjm
9KV3DksIVqeeY2/cwB9RSS5jmDOzyuOJjrv/qNGqx/BkHpbCv+mxfIJvJQ+ZBYwS
R2IGIWawUyydxktpIuueavddpAP75j+i1lq9rR8OY1sXF/P17Bnd5uVqrWLjkRwe
XtbEdu91EUddXnlxK0gq2BICuferSVRPvWZIBD7a0TlNQbXDDPK8WW/qJje5mi/D
u2MU7SlBNlQgCZzYJiTAuBLjh7Q+kQ==
=mHi6
-----END PGP SIGNATURE-----

--+B+Fr2JDn72RbV1s--